Release 2.0.3
A54082-01
 Library |
 Product |
 Contents |
 Index |
| Oracle
Cryptographic Toolkit Programmer's Guide Release 2.0.3 A54082-01 |
|
This chapter provides an overview of the Oracle Cryptographic Toolkit. The following topics are discussed:
The Oracle Security Server is a portable security service that provides a centralized global authentication and authorization framework. It provides enterprise security by using public key cryptography to authenticate users, control user access to data, and protect sensitive data. These functions are achieved through the use of public key cryptography for encryption, digital signatures, and user authentication.
The Oracle Security Server uses X.509 v1 certificates as its authentication mechanism. The X.509 v1 certificate is a standard format for digitally signed certificates that contain information such as a user's identity, authorizations, and public key information.
X.509 v1 certificates are used to access secure network systems. Users obtain certificates so they can identify themselves, present their access credentials, and obtain a secure network connection with other cryptographically secure users or systems.
The Oracle Security Server supports the following features.
Customers can create their own certificate authorities (CA), create certificates for their users, and manage user authorizations and roles using the Oracle Security Server.
A certificate authority is a trusted entity that certifies 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 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 from the CA 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 the 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 another 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.
The authentication mechanism used by the Oracle Security Server is based on the International Telecommunications Union (ITU) X.509 v1 certificates. X.509 is a standard format for digitally signed certificates. It conveys a user's identity and public key data.
A certificate revocation list (CRL) is a data structure, signed and timestamped by a CA, that lists all of the certificates created by the CA that have not yet expired but are no longer valid. CRLs are used to revoke security privileges and for compromise management.
A party retrieving a certificate from the CA can check one or more CRLs to see whether that certificate has been revoked. However, 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 only random, or periodic, checks of the CRLs.
The Oracle Security Server Manager provides the user with a graphical user interface that is used to create, store, and revoke certificates.
The Oracle Security Server Manager is implemented as an Oracle Enterprise Manager applet. This applet is a graphical user interface to the command line version of the Oracle Security Server Manager.
The Oracle Security Server Manager is also implemented as a set of command line tools. These command line tools give you access to the same Oracle Security Server features as the Oracle Enterprise Manager tool.
The Oracle Cryptographic Toolkit is an interface to the cryptographic services provided by the Oracle Security Server. It is intended to unify all cryptographic services, including the use, storage, retrieval, import, and export of credentials. This interface is used by both internal and external Oracle customers to add security enhancements to their applications. External customers can use either OCI or PL/SQL to access the Oracle Cryptographic Toolkit.
Refer to Figure 1-1, "Relationship between Toolkit and Services" below, for an overview of who uses the Oracle Security Server and the Oracle Cryptographic Toolkit and how the two are related.
The Oracle Cryptographic Toolkit presents an abstraction that hides keys and X.509 v1 certificates from the application. The application, then, works with wallets, trusted identities, and personas. A wallet is a storage abstraction that can be located on the file system, in a database, or in a hardware device; a trusted identity is similar to a certificate; and a persona is a combination of a certificate and its associated private key.
The Oracle Cryptographic Toolkit is comprised of four functional layers: an API layer, a Cryptographic Engine Functions layer, a Persona/Identity Functions layer, and a Wallet Functions layer. Refer to Figure 1-1, "Relationship between Toolkit and Services".
The API layer contains three interfaces, or points of entry, into the Oracle Cryptographic Toolkit. The three points of entry are OCI, PL/SQL, and raw C (for Oracle internal customers only). The OCI and PL/SQL interfaces are actually wrappers around the raw C interface.
The Cryptographic Services layer consists of all the cryptographic services available to the Oracle Security Server. These services include the use, storage, retrieval, import and export of credentials. This layer consists of two main components: a cryptographic engine and an abstract cryptographic engine.
Cryptographic engine functions are built on top of a set of primitives presented by the abstract cryptographic engine. The cryptographic engine issues a function call to the abstract cryptographic engine. After it issues the function call, the cryptographic engine verifies that the correct amount of memory is available for any output from the abstract cryptographic engine and that the cipher keys are available in the appropriate format. A cryptographic engine function provides a single interface to the application. Following is a list of cryptographic engine functions.
The signature generated from a message is attached to that message. The Oracle Cryptographic Toolkit:
The signature generated from a message is kept separate from that message. The Oracle Cryptographic Toolkit:
The message is encrypted, so only the owner of the private key can decrypt the message to read it. The Oracle Cryptographic Toolkit:
The combination of signing a message and PK encrypting it. This provides both sender verification and privacy. The Oracle Cryptographic Toolkit:
Symmetric key encryption processes. The Oracle Cryptographic Toolkit supports password based encryption (PBE) and both RC4 with PKCS padding and DES with PKCS padding.
The cryptographic checksum of an entity. Both MD5 and SHA hash algorithms are supported.
The cryptographic checksum of a message with an additional key folded in. Both MD5 and SHA hash algorithms are supported.
Pseudo random number generation. The Oracle Cryptographic Toolkit generates random integers, random sequences of bytes, and allows the application to change the seed value.
The Wallet provides storage and retrieval of personas and identities for use with various Cryptographic Engine functions. In order for an application to call the cryptographic engine functions, the wallet must contain at least one persona. The Oracle Cryptographic Toolkit relies on the persona to carry specific information about what cryptographic algorithm to use with a cryptographic engine function. The application configures the persona for a particular purpose and then uses one or more cryptographic engine functions. The application can therefore treat a persona as a set of security contexts: one for each cryptographic engine function.
The Wallet Functions layer implements one or more repositories referred to as wallets. A wallet implements a single way to store, retrieve, and use credentials that can be located on a file system, a database, or a hardware device. Applications access one or more of these wallets to select personas and identities.
The wallet provides location transparency in two ways. First, the wallet can be located on a file system, in a database, or in a hardware device. Second, each credential stored in a wallet can exist as a typed reference rather than as the actual credential.
The Oracle Cryptographic Toolkit wallet interface becomes a wrapper around the wallet style interface presented by hardware devices. File-based wallets can be treated like a wallet when the format of their credentials are well known. For example, Oracle proprietary, Netscape, and Spyglass file based wallets can be treated as wallets.
The Oracle Cryptographic Toolkit works with the following basic elements:
An identity is the public information for an entity. The identity of an object consists of the binding of a public key and other public information for that entity. Every identity has a type: for example, X.509 v1. Refer to Figure 1-2, "Identity", below for an illustration of the structure of an identity.
A trusted identity (or trust point) is an identity that is considered trustworthy. This trusted identity is then used to validate other identities. For example, an X.509 type trusted identity is a Certificate Authority.
A persona contains an identity, the private information for an entity, a list of actions that can be performed (e.g., DSS, RSA, or symmetric key encryption), a set of message formats, and a set of trusted identities. Each persona has a type that it inherits from its identity: e.g., X.509 v1.
Refer to Figure 1-3, "Persona", below for an illustration of a persona
The Oracle Cryptographic Toolkit also works with one or more repositories called wallets. Wallets are containers that store trusted identities and personas. Refer to Figure 1-4, "Wallet" below, for an overview of the relationship between these elements.
The Oracle Cryptographic Toolkit is accessed using the following types of interfaces: .
Oracle client programs use the Oracle call interface to access Oracle Security Server functions. Refer to Chapter 6, "OCI Functions for C", for detailed Oracle call interface programming information.
Oracle server programs use the Oracle PL/SQL interface to access Oracle Security Server functions. Refer to Chapter 7, "PL/SQL Functions", for detailed PL/SQL interface programming information.
|
 Copyright © 1997 Oracle Corporation. All Rights Reserved. |
|
