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."  | The OSS toolset is case-sensitive and, if you actually enter the values as shown here (i.e., "C=US, CN=mary"), you will have to ensure that you carry the upper/lowercase entries throughout the steps exactly as you have entered them initially. A much better approach would be to always use uppercase. | | | 
