size=+0>
15.2 Ways to Authenticate Users
As we said in the previous section, keys are
actually parameters you reference when you run your program (algorithm) to
either encrypt or decrypt a message or a piece of data. Keys were first
used with algorithms to enable people to communicate electronically in a
more private manner. Originally, the same algorithm was used to both
encrypt and decrypt a message. But that approach often proved vulnerable
to the sophisticated computer programs hackers wrote to break the
encrypted messages. By necessity, keys have had to become more complex,
and their use and protection more secure. Different approaches have been
used to try to ensure that encrypted material cannot be decrypted by
anyone other than the intended receiver. This section describes some of
these approaches.
15.2.1 Private Keys
One way for two people who want to communicate
privately with each other to do so is for them to ensure that they each
have a copy of the same key, referred to as a private key, which
they use for both encryption and decryption of their message. But to use
this approach, they need to find a way to exchange the key information so
no one else can get the key.
If Mary and Ralph want to communicate, they will each need a copy of a
key to encrypt and decrypt their messages. Let's say that Ralph and Ed
also want to communicate privately. They will need a different key so that
Mary cannot read their messages. Now Ralph needs to maintain, protect, and
track two different keys — one for communication with Mary and one for
communication with Ed. If Ralph wants to communicate with a third or
fourth person, his key maintenance will quickly compound.
A number of commonly used cryptography approaches are based on the
notion of the sharing of private keys. Two of the best known private key
algorithms are the Data Encryption Standard (DES), published in 1975 by
the National Institute of Standards and Technology (NIST) and the
International Data Encryption Algorithm (IDEA), published in 1990.
15.2.1.1 The problem with private keys
On a company-wide basis, the need for users to get and maintain
multiple private keys becomes a managerial nightmare. As the number of
users grows, the number of possible keys required grows proportionally.
Some companies have implemented various forms of central key servers to
provide users with a place to obtain a key each time they want to
communicate with another user in a private manner. The problems with this
approach are that the centralized key server:
Both of these problems are really time-based. If everyone is relying on
obtaining their private keys from a centralized key server and that key
server crashes, no one will be able to obtain a key until the server is
back online and available. Without a backup server, secure communication
might have to be halted until the key server can be repaired or recovered.
Likewise, if a substantial number of users are obtaining private keys
frequently, the key server could become overwhelmed. Response times for
obtaining private keys could impact your system and user performance.
15.2.2 Public Keys
Another approach to encrypting secret
communications is to use a public key system. With public key systems,
each user has a set of two keys — a public key to which everyone can have
access, and a private key which is available to only the owner of that
key. The public key is made available to anyone who wants to communicate
in a secure manner with you. The public key is truly public — it can be
placed anywhere on a system, including a web page.
The public key is used to encrypt the plaintext message, while the
private key is used to decrypt the message. Anyone can use the public key
to encrypt a message, while only someone who has the corresponding private
key can decrypt it. The keys are generally complex enough that the private
key cannot be easily derived from the public key. Public key algorithms
are usually much larger than private key algorithms and, therefore, are
generally much slower to use.
The beauty of the public key/private key approach is that it provides
much greater security and privacy. Going back to our example earlier, if
Mary wants to communicate with Ralph, she will encrypt her message using
Ralph's public key. Since Ralph is the only one who has his private key
(we hope) Ralph will use his private key and easily decrypt Mary's
message. Likewise, if Ralph wants to communicate with Ed, Ralph will use
Ed's public key to encrypt the message.
15.2.2.1 Private keys, public keys, and authentication
In a reverse manner, with public key systems, private keys can be used
to authenticate a user — just as you proved you were who you said you were
by showing your birth certificate and driver's license to an official to
obtain a passport. Let's say that Mary encrypts a message using her
private key. Anyone who has Mary's public key can decrypt her message
since the keys can work in either order — public to private or private to
public. However, unless someone else has access to Mary's private key,
duplicating Mary's encryption would be very difficult.
15.2.2.2 Advantages of a public key system
Since each person maintains his or her own private key, there is no
single point of failure in a public key system. People have the ability to
authenticate themselves by using their own private key to encrypt
something that can be decrypted with their own public key. Key
distribution is simplified since private keys do not need to be shared
between two people to be useful.
Figure
15.2 shows an example of public key encryption and decryption.
Figure 15.2. Public key encryption and
decryption
15.2.3 Digital Signatures
In earlier times, when a military leader wanted to
communicate with his troops who were some distance away from him, the
leader would write his message, fold the paper, and affix a special wax
seal. The seal was recognized to be his alone. The seal was affixed to the
open edge of the message, thus both sealing the message closed so that no
one could read it without disturbing the seal, and authenticating the
message as having been sent by the leader personally. The seal was
recognized by the troops, and the directives within the message were
followed as if the military leader were present and issuing the orders
himself.
In a similar way, digital signatures have become a way to
authenticate that a message was sent by a specific user. The digital
signature is generated using a two-step process. First, the sender uses a
one-way hash function to generate a
specific-length number known as a message digest . The hash function can take a message of any length and
generate a fixed-length number. Next, the sender uses his or her private
key to encrypt the message digest. The digital signature — the encrypted
message digest — can be attached to any message.
When someone receives a message with a digital signature, the receiver
goes through a two-step process to decrypt the signature and verify that
the message was actually sent by the person who claimed to send the
message. The receiver would apply the same one-way hash function the
sender used to generate the message digest and then apply the sender's
public key to decrypt the received message digest. The result should be a
match of the sender's transmitted message digest. If it is a match, the
receiver can feel pretty comfortable that the message has not been
tampered with.
Figure
15.3 shows an example of using a digital signature.
Figure 15.3. Digital signature
15.2.4 Certificates of Authority
With a digital signature, the
person who receives a message takes responsibility for authenticating the
message. Another approach to security is to have a trusted entity,
referred to as a certificate authority (CA), validate that someone
is who he says he is. At the beginning of the chapter, we talked about a
government agency you go to when you need a passport issued. The CA, like
the government agency, validates that you are who you claim to be and
issues an appropriate credential, the certificate of authority, to
you.
A certificate of authority is an electronic message digitally
signed by the CA. It states that a public key belongs to a specific user
or process. The CA signs a certificate by using its private key to encrypt
the signature and place it on the certificate. Anyone or anything
receiving a certificate can decrypt the signature using the public key and
thereby verify the authenticity of the CA. Based on the trust in the CA,
the receiver can trust whoever presents a certificate from the CA.
Think back to our initial example of an agency issuing a passport and
the traveler then showing his passport to move from place to place in a
trusted manner. In similar fashion, the certificate that is electronically
signed by a CA can enable a user or process to be trusted and allowed to
move from system to system or to transact business in a trusted
manner.
The OSS provides the ability for a user or process to obtain a
certificate of authority to enable the process or person to perform one or
many transactions, with one or several databases, without having to use a
username and password for each interaction. The OSS supports a form of
certificates known as X.509 version 1 (a standard protocol). The OSS
places the certificate of authority, otherwise referred to as an X.509
certificate, along with a public and private key pair, into a
structure called a wallet .
15.2.4.1 Certificate format
An X.509 certificate has a standard format; here we
show the values generally used by the OSS:
- Version
Currently, this value for an OSS is always "0," which refers to the
X.509 version 1 certificates. In future releases, the OSS will support
X.509 version 3 certificates. These future certificates will use a
version value of "1."
- Serial number
A unique identifier for the certificate.
- Algorithm identifier
The algorithm the CA used and any necessary parameters for
validation.
- Issuer
The name of the CA.
- Period of validity
The range of dates over which the certificate is valid. Usually, it
is the range of dates requested by the certificate requester, which
would typically span the period from the date of creation to a specified
end time.
- Subject
Identifies to whom the certificate belongs.
- Subject's public key
This area includes the certificate owner's public key, identifies
which algorithm the CA used, and includes any necessary parameters.
- Signature
The digital signature of the CA.
As you can see, the information contained in a certificate is enough
for a receiver to validate the CA and the owner of the certificate.
15.2.4.2 Period of validity and revocation
The period of validity for a certificate (see the list of certificate
elements above) is the amount of time requested by the certificate owner
during which the certificate will be able to be accepted. At the end of
that period of time, the certificate becomes invalid. A certificate can
also be revoked (so it is no longer valid) before its period of validity
expires. Even though a certificate may still have a valid time period,
something might have happened to cause the CA to revoke the use of a
specific certificate.
There are a number of events that might cause the revocation of a
certificate. For example, the certificate owner's key or the CA's key
might have been compromised, or an event might have occurred that makes
the certificate owner no longer worthy of trust. Leaving the company would
generally be a reason for the CA to revoke a user's certificate before it
had automatically expired.
Periodically, the CA will issue, sign, and timestamp a list of
certificates which have been revoked. Referred to as a certificate revocation list (CRL), the list can be
checked by any receiver to verify the status of a certificate. However,
since checking the CRL can be a very slow process, verification against
the CRL is generally reserved for really important or critical documents
or might be used only infrequently to perform complete verification
checks.
15.2.4.3 Distinguished names
The concept of a distinguished name (DN) is used not only by Oracle Corporation for its OSS
product, but by other companies and products as well. For example,
Verisign Corporation, when issuing a digital identification for a server,
requires the server's distinguished name as part of the certification
process. In Verisign's case, the requirement is to present the server name
as the fully qualified domain name used for standard Internet DNS (Domain
Name System) lookups for a server location — like a web server address
(e.g., www.my_web_address.com).
In Oracle's case, the DN has a very specific structure: DN=([Country,][Organization,][OrganizationUnit,][State,][Locality,] CommonName)
The one mandatory value in the distinguished name definition is the
common name. The other values are optional, but the order in which the
values are entered is very important. The rules associated with a
distinguished name are the following:
A distinguished name must have at least the common name
All of the other elements, if used, must be in the specific listed
order: "C=,O=,OU=,S=,L=,CN="
All element labels used for a distinguished name must be uppercase,
though the elements can be upper/lower
The actual definition values must match exactly the values used in
the OSS identity
Elements in the distinguished name definition cannot have any spaces
between the elements
The elements in the distinguished name definition can only be
separated by a comma (,)
The order in which the values are entered when defining a distinguished
name becomes important when a "global user" definition is entered. (The
OSS global definitions are discussed in a later section.)
An example of a valid DN structure would be: DN='C=US,O=MyCompany,OU=MyDept,ST=VA,L=Vienna,CN=mary'
The only mandatory value in this example is the "CN=mary" at the end of
the string; this is the common name. The Country is "US"; the Organization
is "MyCompany"; the OrganizationUnit is "MyDept"; the State is "VA"; the
Locality is "Vienna"; and the CommonName is "mary."
border=0>
| 