Release 2.0.3
A54088_01
 Library |
 Product |
 Contents |
 Index |
| Oracle Security Server Guide Release 2.0.3 A54088_01 |
|
This chapter describes basic concepts associated with the Oracle Security Server. The chapter includes the following sections:
The Oracle Security Server is a security product that supports centralized authorization and distributed authentication in an Oracle environment. Authentication provides assurance that the alleged identity of a party who wishes to access one or more Oracle database servers is valid. Authorization assures that a given party can only operate according to privileges that have been defined for that party by an administrator.
The Oracle Security Server is bundled with Oracle8 Server for use on any platform that supports that product. However, the Oracle Security Server can be used with an Oracle7 Server as well.
Cryptography is the science of providing security for information through the reversible transformation of data. It is a science of great antiquity. (Julius Caesar used a simple letter substitution cipher that still bears his name.) The development of digital computing revolutionized cryptography, and made today's highly complex and secure cryptographic systems possible.
A modern cryptographic system contains an algorithm and one or more keys. A cryptographic algorithm (also known as a cipher) is a general procedure for transforming data from plaintext (a usable, readable form) to ciphertext (a protected form) and back again. The former process is called encryption; the latter, decryption. The keys are variable parameters of the algorithm. In order to transform a given piece of plaintext into ciphertext, or ciphertext into plaintext, one needs both the algorithm and a key.
Modern algorithms are designed so that a user who knows the algorithm and the ciphertext, but not the key, cannot easily derive the plaintext from the corresponding ciphertext. Normally, algorithms are widely distributed or even public, while knowledge of keys is limited to the fewest users possible, since knowledge of the key provides access to the data encrypted with that key.
If an algorithm is well-designed, the size of the key is an indication of the algorithm's strength, which is the difficulty an attacker would have deriving the plaintext from the ciphertext without prior knowledge of the key.
Until relatively recently, cryptographic algorithms were designed so that the same key was used to both encrypt and decrypt data. Algorithms designed this way are referred to as "private-key," "secret-key," or "symmetric-key" algorithms.
As an example, if Alice and Bob wish to communicate, they must each know the secret key, and the key must be exchanged in such a way that its secrecy is preserved. If Bob and Steve also wish to communicate, they must obtain another secret key so that Alice cannot read their messages.
Prominent examples of secret-key algorithms include the Data Encryption Standard (DES), which the National Bureau of Standards (now the National Institute of Standards and Technology [NIST]) brought out in 1975, and the International Data Encryption Algorithm (IDEA), developed in 1990 by two men in Sweden.
There are certain problems associated with using secret-key cryptography in the enterprise. As the number of users (N) increases linearly, the number of possible "pairwise-secret" keys increases by a factor of N2. This causes the management and distribution of keys to become overwhelming. To deal with this problem, most large systems provide centralized key servers from which users must retrieve a new key for each communications session if they wish to establish a secure session. These centralized private-key servers are often the "Achilles heel" of a communications system, since a single failure can compromise the entire system.
In 1976, Whitfield Diffie and Martin Hellman proposed a new type of cryptographic algorithm, referred to as "public key," which greatly facilitates key distribution in a large user community.
In public-key cryptography (also known as "asymmetric" cryptography), the key used to encrypt plaintext into ciphertext is different from the key that decrypts ciphertext into plaintext. Each person gets a pair of keys: a public key and a private key. The public key is published, while the private key is kept secret.
The keys are related in that a message encrypted with the public key can only be decrypted with the corresponding private key, and a message encrypted with a private key can only be decrypted with the corresponding public key. Furthermore, the keys are designed so that the private key cannot, for all practical purposes, be deduced from the public key. For instance, cryptanalysis of the most famous public-key algorithm, RSA, requires the cryptanalyst to factor numbers that contain in excess of 100 digits each; the difficulty in factoring numbers of that magnitude is well-known in the computer science community.
Public-key cryptography provides confidentiality or data secrecy. For example: If Alice wishes to send a message to Bob that only Bob can read, she encrypts the message with Bob's public key, and Bob subsequently decrypts the message with his private key. Since only Bob has the private key that can decrypt the message, only Bob can read it. Anyone else wishing to send an encrypted message to Bob must also use his public key for encryption.
Public-key cryptography can also be used in authentication of senders of information. If Alice encrypts data with her private key, any other user can read it using Alice's public key, but no other user can duplicate Alice's encryption without access to Alice's private key.
Diffie and Hellman's paper [Diffie and Hellman] appeared in 1976; it is the original paper about public-key cryptography. Other good sources for information on this subject are RSA's Frequently Asked Questions document [RSA FAQ] (see http://www.rsa.com/PUBS) and Bruce Schneier's Applied Cryptography [Schneier] (see http://www.counterpoint.com).
In a practical security system, private- and public-key algorithms are used together. Public keys are typically much larger than private keys (a DES private key is 56 bits, while an RSA public key is usually 512 or 1024 bits), and public-key algorithms are generally much slower than private-key algorithms.
In a hybrid cryptosystem, two parties who wish to communicate with each other use a public-key encryption algorithm to authenticate each other and a more streamlined private-key algorithm to transmit bulk data. The steps involved in this process include the following:
In addition to the speed advantages that this provides over public-key cryptography, it is also better than private-key cryptography on its own, because key management is simplified and the keys are more secure.
Public-key cryptography simplifies key distribution by eliminating the need to share private keys. Holders of public keys can safely conduct business with parties whom they never see and with whom they had no previous relationship. In essence, the public-key encryption system becomes an effective substitute for face-to-face commerce.
Since private keys are only known to the owning party, public-key authentication eliminates the need for a server that manages the private keys for all the parties in a system. This eliminates all single points of failure, and considerably reduces and simplifies the management of keys. Keys can be used for longer periods of time than those used in secret-key encryption systems because private keys are never shared. Since the security for private keys is one of the most critical issues in any cryptographic system, simplifying private-key management not only simplifies the system, but it also makes it an order of magnitude more secure than previous security technologies.
Please note that although the Oracle Security Server uses cryptographic mechanisms to support authentication and authorization, it does not provide bulk encryption keys for data stream encryption. Data stream encryption is provided by the Oracle Advanced Networking Option encryption adapters (for example, RSA Data Security, Inc.'s RC4). Refer to the Oracle Advanced Networking Option Administrator's Guide for more information about encrypted data streams.
A digital signature is a quantity associated with a message that only someone with knowledge of an entity's private key could have generated, but which can be verified through knowledge of that entity's public key.
Digital signatures perform three very important functions:
The process of generating a digital signature for a particular document type involves two steps.
First, the sender uses a one-way hash function to generate a message digest. This hash function can take a message of any length and return a fixed-length (say, 128 bits) number (the message digest). The characteristics that make this kind of function valuable are as follows:
Second, the sender uses its private key to encrypt the message digest.
Thus, to sign something, in this context, means to create a message digest and encrypt it with a private key.
Figure 1-1 shows a typical E-mail message and what the associated digital signature might look like.
The receiver of a message can verify that message via a comparable two-step process:
If the newly computed message digest matches the one that was transmitted, the message was not altered in transit, and the receiver can be certain that it came from the expected sender.
A certification authority (CA) is a trusted entity that certifies that other entities are who they say they are.
The CA is something of an electronic notary service: it generates and validates electronic IDs, in the form of certificates (see the following section) that are the equivalent of driver's licenses and passports. The CA uses its private key to sign each certificate; an entity that receives a certificate can trust that signature just as a person in real life can trust the written signature of a notary.
A certificate is a message, signed by a CA, stating that a specified public key belongs to someone or something with a specified name.
Certificates prevent someone from using a phony key to impersonate a party, and also enable parties to exchange keys without contacting a CA for each authentication. Distributing keys in certificates is as reliable as if the keys were obtained directly from the CA. Certificate-based authentication works even when the security database server is temporarily unavailable.
Figure 1-2 shows the format of a typical certificate.
The elements of this certificate are as follows:
A subject that receives a certificate belonging to another subject will try to verify that the CA issued the certificate, by applying that CA's public key to the Signature. If the receiving subject can understand the resulting text, the certificate was indeed signed by the CA, and the receiver can trust that the public key contained within the certificate belongs to the other subject.
A certificate revocation list (CRL) is a data structure, signed and timestamped by a CA, that lists all of the certificates created by that CA that have not yet expired but are no longer valid.
A certificate may be revoked in response to any of several events:
A party retrieving a certificate from the CA can check one or more CRLs to see whether that certificate has been revoked. Note, though, that since checking a CRL incurs significant overhead, users may want to make these checks only for documents that are especially important, or they may want to limit themselves to periodic checks of CRLs.
The Oracle Security Server conforms to a number of security industry and Oracle standards to facilitate interfaces with other products and systems.
The Oracle Security Server supports a version of SKEME as its authentication protocol. (A paper about SKEME, written by Hugo Krawczyk of IBM [Krawczyk], is available at http://www.research.ibm.com/security/publ.html.)
The Oracle Security Server supports X.509 version 1 certificates. (The 0 in the Version area of the certificate, as described in the section "Certificates" that appears earlier in this chapter, refers to version 1. Future releases of the Oracle Security Server will support version 3 certificates, which correspond with the value 1 for Version.)
Three documents define the standards for X.509 certificates.
You can order all of these documents from the International Telecommunications Union (ITU) directly; see www.itu.ch/itudoc/itu-t/rec/x/x500up/.
The Oracle Security Server uses the RSA cryptographic algorithm and RSA's Message Digest 5 (MD5) one-way hash function in generating and verifying digital signatures. These algorithms are implemented in software, using functions in the RSA TIPEM and BSAFE security toolkits. (See http://www.rsa.com/rsa/PRODUCTS/TIPEM/ and http://www.rsa.com/rsa/prodspec/bsafe/bsafe_3_0_f.htm, respectively.)
The default version of the RSA algorithm is the 512-bit US-exportable version. Versions that use larger key sizes are available to eligible customers in accordance with applicable export and import regulations. MD5 produces a 128-bit hash value.
Two of the Public Key Cryptography Standards (PKCS) that RSA has defined are relevant to this discussion. PKCS #1 [PKCS1] describes a method for RSA encryption and decryption that is meant for use in conjunction with digital signatures, and also describes the syntax associated with the combination of RSA and MD5. PKCS #7 [PKCS7] describes the general syntax for data that may be signed with a digital signature. Both of these specifications are available at www.rsa.com/PUBS/. Ron Rivest's original paper about MD5 [MD5] contains technical details about that function.
The Oracle Security Server supports the X.509 standard for fully-qualified distinguished names (DNs) in certificates.
A fully-qualified DN is a string that uniquely identifies a subject. This string may also define a path. The subject names contained within X.509 certificates are defined by the X.500 standard.
The Oracle Security Server limits the syntax of DNs so that certificates conform to a more restricted format, as defined by the following template:
DN = ([Country,] [Organization,] [OrganizationUnit,] [State,] [Locality,] CommonName)
Within this template, each DN must have a Common Name, and all of the other values are optional.
| Note:
The order in which these values appear within a DN is important with regard to defining global users (see "Authorization of Entities" later in this chapter) to an Oracle8 Server. |
Table 1-1 provides an example of the information that one would enter in defining a DN for an entity that will be doing business with the Oracle Security Server.
The Oracle Security Server generates public/private key pairs using an RSA Data Security Inc. TIPEM library function. (See http://www.rsa.com/rsa/PRODUCTS/TIPEM/.)
The Oracle Security Server enables the use of public-key cryptographic technologies for Oracle and non-Oracle products. This technology provides:
The combined effect of these features is to enhance the security of any system. In particular, it enhances the security of those distributed systems that cannot control the number of users who can sign on to the system.
The Oracle Security Server enables an administrator to define identities for many types of subjects, including users, database servers, and Oracle WebServers. These identities, along with public keys, are captured in certificates that, used in conjunction with private keys, allow entities to authenticate themselves to each other using public-key cryptography (see "Authentication of Entities" below). Certificates can be revoked for entities that no longer belong to the enterprise.
The administrator can also define roles (collections of privileges) that can be used across databases (see "Authorization of Entities" below).
The Oracle Security Server also supports the implementation of single sign-on by replacing password authentication with certificate authentication.
The uniform management of enrollment and authorization of entities in large enterprises significantly improves the scalability of large distributed systems.
Authentication provides assurance that the alleged identity of a party who wishes to communicate with another party over a network is valid.
Once a certificate has been assigned to an entity, that entity can use its certificate to authenticate itself to other subjects with which it wishes to communicate. For instance, an Oracle8 Server can find out with a high degree of certainty that a given user is who she says she is, while the user can be sure that she is communicating with the correct server.
Authorization assures that a given entity can only operate according to privileges that have been defined for that entity, in the context of the Oracle Security Server, by an administrator.
Global users are users who need access to more than one Oracle8 Server using one set of credentials. Global roles (also known as globally identified roles) are roles that global users perform across Oracle8 Servers. The Oracle Security Server maintains the mapping of global users in a distributed Oracle8 enterprise to the globally identified roles that these users may perform for each database within that enterprise. (Note that the meaning of a globally identified role with regard to a specific Oracle8 Server remains the responsibility of that database's DBA.) See the Oracle8 Server Distributed Database Systems manual for more information about global users and global roles.
