|
Oracle® Security Developer Tools Reference
10g Release 2 (10.1.2) B15975-01 |
|
 Previous |
 Next |
|
Oracle® Security Developer Tools Reference
10g Release 2 (10.1.2) B15975-01 |
|
|
Previous |
Next |
Security tools are a critical component for today's application development projects. Commercial requirements and government regulations dictate that sensitive data be kept confidential and protected from tampering or alteration.
Oracle Security Developer Tools provide you with the cryptographic building blocks necessary for developing robust security applications, ranging from basic tasks like secure messaging to more complex projects such as securely implementing a service-oriented architecture. The tools build upon the core foundations of cryptography, public key infrastructure, web services security, and federated identity management.
This chapter takes a closer look at these underlying security technologies and introduces the components of the Oracle Security Developer Tools. It covers these topics:
As data travels across untrusted communication channels, cryptography protects the transmitted messages from being intercepted (a passive attack) or modified (an active attack) by an intruder. To protect the message, an originator uses a cryptographic tool to convert plain, readable messages or plaintext into encrypted ciphertext. While the original text is present, its appearance changes into a form that is unintelligible if intercepted. The message recipient likewise uses a cryptographic tool to decrypt the ciphertext into its original readable format.
Cryptography secures communications over a network such as the internet by providing:
Authentication, which assures the receiver that the information is coming from a trusted source. Authentication is commonly achieved through the use of a Message Authentication Code (MAC), digital signature, and digital certificate.
Confidentiality, which ensures that only the intended receiver can read a message. Confidentiality is commonly attained through encryption.
Integrity, which ensures that the received message has not been altered from the original. Integrity is commonly ensured by using a cryptographic hash function.
Non-repudiation, which is a way to prove that a given sender actually sent a particular message. Non-repudiation is typically achieved through the use of digital signatures.
The mathematical operations used to map between plaintext and ciphertext are identified by a cryptographic algorithm (also known as a cipher). Cryptographic algorithms require the text to be mapped, and, at a minimum, require some value which controls the mapping process. This value is called a key.
Essentially, there are three types of cryptographic algorithms which can be categorized by the number of keys used for encryption and decryption, and by their application and usage. The basic types of cryptographic algorithms are:
Each type is optimized for certain applications. Hash functions are suited for ensuring data integrity. Symmetric cryptography is ideally suited for encrypting messages. Asymmetric cryptography is used for the secure exchange of keys, authentication, and non-repudiation. Asymmetric cryptography could also be used to encrypt messages, although this is rarely done. Symmetric cryptography operates about 1000 times faster, and is better suited for encryption than asymmetric cryptography.
A symmetric cryptography algorithm (also known as secret key cryptography) uses a single key for both encryption and decryption. The sender uses the key to encrypt the plaintext and sends the ciphertext to the receiver. The receiver applies the same key to decrypt the message and recover the plaintext. The key must be known to both the sender and receiver. The biggest problem with symmetric cryptography is the secure distribution of the key.
Symmetric cryptography schemes are generally categorized as being either a block cipher or stream cipher. A block cipher encrypts one fixed-size block of data (usually 64 bits) at a time using the same key on each block. Some common block ciphers used today include Blowfish, AES, DES, and 3DES.
Stream ciphers operate on a single bit at a time and implement some form of feedback mechanism so that the key is constantly changing. RC4 is an example of a stream cipher that is used for secure communications using the SSL protocol.
An asymmetric cryptography algorithm (also known as public key cryptography) uses one key to encrypt the plaintext and another key to decrypt the ciphertext. It does not matter which key is applied first, but both keys are required for the process to work.
In asymmetric cryptography, one of the keys is designated the public key and is made widely available. The other key is designated the private key and is never revealed to another party. To send messages under this scheme, the sender encrypts some information using the receiver's public key. The receiver then decrypts the ciphertext using her private key. This method can also be used to prove who sent a message (non-repudiation). The sender can encrypt some plaintext with her private key, and when the receiver decrypts the message with the sender's public key, the receiver knows that the message was indeed sent by that sender.
Some of the common asymmetric algorithms in use today are RSA, DSA, Diffie-Hellman, and Elliptic Curve Cryptography (ECC).
A hash function (also known as a message digest) is a one-way encryption algorithm that essentially uses no key. Instead, a fixed-length hash value is computed based upon the plaintext that makes it impossible for either the contents or length of the plaintext to be recovered. Hash algorithms are typically used to provide a digital fingerprint of a file's contents, often used to ensure that the file has not been altered by an intruder or virus. Hash functions are also commonly employed by many operating systems to encrypt passwords. Hash functions help preserve the integrity of a file. Some common hash functions include MD2, MD4, MD5 and SHA.
For more information, refer to the cryptography resources listed in Appendix A.
A public key infrastructure (PKI) is designed to enable secure communications over public and private networks. Besides secure transmission and storage of data, PKI enables secure e-mail, digital signatures, and data integrity.
These facilities are delivered using public key cryptography, a mathematical technique that uses a pair of related cryptographic keys to verify the identity of the sender (digital signature), or to ensure the privacy of a message (encryption). PKI facilities support secure information exchange over insecure networks, such as the Internet.
Critical elements for achieving the goals of PKI include:
Encryption algorithms and keys to secure communications
Digital certificates that associate a public key with the identity of its owner
Key distribution methods to permit widespread, secure use of encryption
A trusted entity, known as a Certificate Authority (CA), to vouch for the relationship between a key and its legitimate owner
A Registration Authority (RA) that is responsible for verifying the information supplied in requests for certificates made to the CA
Relying third parties use the certificates issued by the CA and the public keys contained therein to verify digital certificates and encrypt data.
Encryption techniques often use a text or number called a key, known only to the sender and recipient.
When both use the same key, the encryption scheme is called symmetric. Difficulties with relying on a symmetric system include getting that key to both parties without allowing an eavesdropper to get it, too; and the fact that a separate key is needed for every two people, so that each individual must maintain many keys, one for each recipient.
Public key cryptography uses a key pair of mathematically related cryptographic keys - the public key and the private key. For an explanation of the use of key pairs, see "Asymmetric Cryptographic Algorithms".
Table 1-1 summarizes who uses public and private keys and when:
A Certificate Authority (CA) is a trusted third party that vouches for the public key owner's identity. Oracle Certificate Authority is one such entity. Others include Verisign and Thawte.
The certification authority validates the public key's link to a particular entity by creating a digital certificate. This digital certificate contains the public key and information about the key holder and the signing certification authority. Using a PKI certificate to authenticate one's identity is analogous to identifying oneself with a driver's license or passport.
A number of standards and protocols support PKI certificate implementation.
Cryptographic Message Syntax
Cryptographic Message Syntax (CMS) is a general syntax for data protection developed by the Internet Engineering Task Force (IETF). It supports a wide variety of content types including signed data, enveloped data, digests, and encrypted data, among others. CMS allows multiple encapsulation so that, for example, previously signed data can be enveloped by a second party.
Values produced by CMS are encoded using X.509 Basic Encoding Rules (BER), meaning that the values are represented as octet strings.
Secure/Multipurpose Internet Mail Extension
Secure/Multipurpose Internet Mail Extension (S/MIME) is an Internet Engineering Task Force (IETF) standard for securing MIME data through the use of digital signatures and encryption.
S/MIME provides the following cryptographic security services for electronic messaging applications:
Authentication
Message integrity and non-repudiation of origin (using digital signatures)
Privacy and data security (using encryption)
Lightweight Directory Access Protocol
Lightweight Directory Access Protocol (LDAP) is the open standard for obtaining and posting information to commonly used directory servers. In a public key infrastructure (PKI) system, a user's digital certificate is often stored in an LDAP directory and accessed as needed by requesting applications and services.
Time Stamp Protocol
In a Time Stamp Protocol (TSP) system, a trusted third-party Time Stamp Authority (TSA) issues time stamps for digital messages. Time stamping proves that a message was sent by a particular entity at a particular time, providing non-repudiation for online transactions.
The Time Stamp Protocol, as specified in RFC 3161, defines the participating entities, the message formats, and the transport protocol involved in time stamping a digital message.
To see how a time-stamping system can work, suppose Sally signs a document and wants it time stamped. She computes a message digest of the document using a secure hash function and then sends the message digest (but not the document itself) to the TSA, which sends her in return a digital time stamp consisting of the message digest, the date and time it was received at the TSA server, and the signature of the TSA. Since the message digest does not reveal any information about the content of the document, the TSA cannot eavesdrop on the documents it time stamps. Later, Sally can present the document and time stamp together to prove when the document was written. A verifier computes the message digest of the document, makes sure it matches the digest in the time stamp, and then verifies the signature of the TSA on the time stamp.
Online Certificate Status Protocol
Online Certificate Status Protocol (OCSP) is one of two common schemes for checking the validity of digital certificates. The other, older method, which OCSP has superseded in some scenarios, is known as the certificate revocation list (CRL).
OCSP overcomes the chief limitation of CRL: the fact that updates must be frequently down-loaded to keep the list current at the client end. When a user attempts to access a server, OCSP sends a request for certificate status information. The server sends back a response of good, revoked, or unknown. The protocol specifies the syntax for communication between the server (which contains the certificate status) and the client application (which is informed of that status).
Certificate Management Protocol
The certificate management protocol (CMP) handles all relevant aspects of certificate creation and management. CMP supports interactions between public key infrastructure (PKI) components, such as Certificate Authorities (CAs), Registration Authorities (RAs), and end entities that are issued certificates.
PKI provides users with the following benefits:
Secure and reliable authentication of users
Reliable authentication relies on two factors. The first is proof of possession of the private key part of the public/private pair, which is verified by an automatic procedure that uses the public key. The second factor is validation by a certification authority that a public key belongs to a specific identity. A PKI-based digital certificate validates this identity connection based on the key pair.
Data integrity
Using the private key of a public/private key pair to sign digital transactions makes it difficult to alter the data in transit. This "digital signature" is a coded digest of the original message encrypted by the sender's private key. Recipients can readily use the sender's corresponding public key to verify who sent the message and the fact that it has not been altered. Any change to the message or the digest would have caused the attempted verification using the public key to fail, telling the recipient not to trust it.
Non-repudiation
PKI can also be used to prove who sent a message. The sender encrypts some plaintext with her private key to create a digital signature, and when the receiver decrypts the message with the sender's public key, the receiver knows that the message was indeed sent by that sender, making it difficult for the message originator to disown the message; this capability is known as non-repudiation.
Prevention of unauthorized access to transmitted or stored information
The time and effort required to derive the private key from the public key makes it unlikely that the message would be decrypted by anyone other than the key pair owner.
Web services provide a standard way for businesses and other organizations to integrate Web-based applications using open standards technologies such as XML, SOAP, and WSDL.
SOAP is a lightweight protocol for exchange of information in a service oriented environment. In such an environment, applications can expose selected functionality (business logic, for example) for use by other applications. SOAP provides the means by which applications supply and consume these services; it is an XML-based protocol for message transport in a distributed, decentralized Web Services application environment.
While the core SOAP specification solves many problems related to XML and Web Services, it does not provide a means to address message security requirements such as confidentiality, integrity, message authentication, and non-repudiation. The need for securing SOAP prompted OASIS to put forward the Web Services Security standard, which:
Specifies enhancements to allow signing and encryption of SOAP messages
Describes a general-purpose method for associating security tokens with messages
Provides additional means for describing the characteristics of tokens that are included with a message
Security Assertions Markup Language (SAML) is an XML-based framework for exchanging security information over the Internet. SAML enables the exchange of authentication and authorization information between various security services systems that otherwise would not be able to interoperate.
The SAML 1.0 specification was adopted by the Organization for the Advancement of Structured Information Standards (OASIS) in 2002. OASIS is a worldwide not-for-profit consortium that drives the development, convergence, and adoption of e-business standards.
SAML associates an identity (such as an e-mail address or a directory listing) with a subject (such as a user or system) and defines the access rights within a specific domain. Every SAML document contains an assertion element. SAML defines four kinds of assertions, which are declarations of one or more facts about a subject:
Subject assertions, which are used to identify a particular user or system.
Authentication assertions, which state that the user has proven his identity by a particular method at a specific time.
Attribute assertions, which contain specific details about the user such as an employee number or account number.
Authorization assertions, which state the resources a user can access and under what conditions.
Assertions are coded statements generated about events that have already occurred. While SAML makes assertions about credentials, it does not actually authenticate or authorize users. Example 1-1 shows a typical SAML authentication assertion wrapped in a SAMLP response message:
Example 1-1 Sample SAMLP Response Containing a SAML Authentication Assertion
<samlp:Response MajorVersion="1" MinorVersion="0" RequestID="128.14.234.20.90123456" InResponseTo="123.45.678.90.12345678" StatusCode="/features/2004/05/Success"> <saml:Assertion MajorVersion="1" MinorVersion="0" AssertionID="123.45.678.90.12345678" Issuer="IssuingAuthority.com" IssueInstant="2004-01-14T10:00:23Z" > <saml:Conditions NotBefore="2004-01-14T10:00:30Z" NotAfter="2004-01-14T10:15:00Z" /> <saml:AuthenticationStatement AuthenticationMethod="Password" AuthenticationInstant="2004-01-14T10:00: 20Z"> <saml:Subject> <saml:NameIdentifier SecurityDomain="RelyingParty.com" Name="john.smith" /> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion> </samlp:Response>
The authority that issues assertions is known as the issuing authority. An issuing authority can be a third-party service provider or an individual business that is serving as an issuing authority within a private federation of businesses. SAML-compliant applications and services, which trust the issuing authority and make use of its services, are called relying parties.
In a typical SAML cycle, the relying party, which needs to authenticate a specific client request, sends a SAML request to its issuing authority. The issuing authority responds with a SAML assertion, which supplies the relying party with the requested security information. This cyle is illustrated in Figure 1-1.
For example, when a user signs into a SAML-compliant service of a relying party, the service sends a "request for authentication assertion" to the issuing authority. The issuing authority returns an "authentication assertion" reference stating that the user was authenticated by a particular method at a specific time. The service can then pass this assertion reference to other relying party sites to validate the user's credentials. When the user accesses another SAML-compliant site that requires authentication, that site uses the reference to request the "authentication assertion" from the issuing authority, which states that the user has already been authenticated.
At the issuing authority, an assertion layer handles request and response messages using the SAML protocol, which can bind to various communication and transport protocols (HTTP, SOAP, and so on). Note that while the client always consumes assertions, the issuing authority can act as producer and consumer since it can both create and validate assertions.
SAML defines a protocol for requesting and obtaining assertions (SAMLP). Bindings define the standard way that SAML request and response messages are transported across the issuing authorities and relying parties by providing mappings between SAML messages and standard communication protocols. For example, the defined transport mechanism for SAML requests and responses is Simple Object Access Protocol (SOAP) over HTTP. This enables the exchange of SAML information across several Web services in a standard manner.
A profile describes how SAML assertions are embedded into and extracted out of standard frameworks and protocol. Web browser profiles for single sign-on and SOAP profiles for securing SOAP payloads are some of the profiles defined.
In addition, SAML was designed to integrate with XML Signature and XML Encryption, standards from the World Wide Web Consortium for embedding encrypted data or digital signatures within an XML document. This support for XML signatures allows SAML to handle not only authentication, but also message integrity and nonrepudiation of the sender. See Chapter 8 for more information about Oracle XML Security.
As global businesses strive for ever-closer relationships with suppliers and customers, they face challenges in creating more intimate, yet highly secure trading relationships.
Parties conducting a business transaction must be certain of the identity of the person or agent with whom they are dealing; they must also be assured that the other has the authority to act on behalf of the business with whom the transaction is being conducted.
Historically, in the course of doing business with partners, companies have resorted to acquiring names, responsibilities, and other pertinent information about all entities who might act on behalf of the partner company. With changing roles and responsibilities, and particularly in large enterprises, this can create significant logistical problems as the data quickly becomes very costly to maintain and manage.
Besides complexity, other challenges include cost control, enabling secure access to resources for employees and customers, and regulatory compliance, among others.
These requirements are driving the move toward Federated Identity Management, in which a federated relationship is established between parties when one party presents its credentials to the other using a process known as "assertions." The receiving party recognizes credentials issued by a trusted trading partner and in an agreed-upon format.
Key federation terminology includes:
Principal - the key actor in a federated environment, being an entity that performs an authorized business task
Identity Provider - a service that authenticates a Principal's identity
Service Provider - an entity that provides a service to a principal or another entity. For example, a travel agency can act as a Service Provider to a partner's employees (principals).
Single Sign-on - the Principal's ability to authenticate with one system entity (the Identity Provider), and have other entities (the Service Providers) honor that authentication
The Liberty Alliance is an open organization which establishes technology and business standards for Federated Identity Management to facilitate interoperable identity services.
To learn more about this topic, read the white paper Federated Identity Management, which is available on the Oracle Secure Federation Services page at http://www.oracle.com/technology/products/id_mgmt/osfs/index.html.
This section provides an introduction to Oracle Security Developer Tools, which are pure java tools that enable you to complete a wide range of security projects and tasks.
Figure 1-2 shows the components of the Oracle Security Developer Tools, arranged in layers with the fundamental building-blocks at the bottom layer; each additional layer utilizes and builds upon the previous layers to provide tools for specific security applications.
Oracle Crypto and Oracle Security Engine are the basic cryptographic tools of the set. The next layer consists of Oracle CMS for message syntax, Oracle XML Security for signature encryption, and Oracle PKI SDK, which is a suite of PKI tools consisting of Oracle PKI SDK LDAP, Oracle PKI SDK TSP, Oracle PKI SDK OCSP, and Oracle PKI SDK CMP. Oracle S/MIME exploits Oracle CMS to provide a toolset for secure e-mail. The next layer contains Oracle SAML and Oracle Liberty SDK, which provides structured assertion markup and federated identity management capabilities. Finally, Oracle Web Services Security provides web services security.
A description of each tool follows:
The Oracle Crypto toolkit provides the following features:
Public key cryptography algorithms such as RSA
Digital signature algorithms such as Digital Signature Algorithm (DSA), RSA, and Elliptic Curve Cryptography (ECC)
Key exchange algorithms such as Diffie-Hellman and Elliptic Curve Cryptography (ECC)
Symmetric cryptography algorithms such as Blowfish, AES, DES, 3DES, RC2, and RC4
Message digest algorithms such as MD2, MD4, MD5, SHA-1, SHA-256, SHA-384, and SHA-512
Methods for building and parsing ASN.1 objects
The Oracle Security Engine toolkit provides the following features:
X.509 Version 3 Certificates, as defined in RFC 3280
Full PKCS#12 support
PKCS#10 support for certificate requests
CRLs as defined in RFC 3280
Implementation of Signed Public Key And Challenge (SPKAC)
Support for X.500 Relative Distinguished Name
PKCS#7 support for wrapping X.509 certificates and CRLs
Implementation of standard X.509 certificates and CRL extensions
Oracle CMS provides an extensive set of tools for reading and writing CMS objects, and supporting tools for developing secure message envelopes.
Oracle CMS implements the IETF Cryptographic Message Syntax specified in RFC-2630. Oracle CMS implements all the RFC-2630 content types.
Oracle S/MIME provides the following Secure/Multipurpose Internet Mail Extension (S/MIME) features:
Oracle PKI SDK contains a set of tools for working with digital certificates, including access to LDAP directories, date stamping of digital messages, certificate validation, and certificate management. It includes the following toolkits:
Oracle PKI SDK LDAP provides facilities for accessing a digital certificate within an LDAP directory. Some of the tasks you can perform using the Oracle PKI SDK LDAP are:
Validating a user's certificate in an LDAP directory
Adding a certificate to an LDAP directory
Retrieving a certificate from an LDAP directory
Deleting a certificate from an LDAP directory
The Oracle PKI SDK TSP provides the following features and functionality:
Oracle PKI SDK TSP conforms to RFC 3161 and is compatible with other products that conform to this time stamp protocol (TSP) specification.
Oracle PKI SDK TSP provides an example implementation of a TSA server to use for testing TSP request messages, or as a basis for developing your own time stamping service.
The Oracle PKI SDK OCSP provides the following features and functionality:
The Oracle PKI SDK OCSP conforms to RFC 2560 and is compatible with other products that conform to this specification, such as Valicert's Validation Authority.
The Oracle PKI SDK OCSP API provides classes and methods for constructing OCSP request messages that can be sent through HTTP to any RFC 2560 compliant validation authority.
The Oracle PKI SDK OCSP API provides classes and methods for constructing responses to OCSP request messages, and an OCSP server implementation that you can use as a basis for developing your own OCSP server to check the validity of certificates you have issued.
The set of functions supported by certificate management protocol (CMP) messages are:
Registration of an entity, which takes place prior to issuing a certificate
Initialization, such as the generation of a key pair
Certification (issuing certificates)
Key pair recovery for reissuing lost keys
Key pair updates when a certificate expires and a new key pair and certificate needs to be generated
Revocation requests to the CA to include a certificate in a CRL
Cross-certification between two CAs
The Oracle PKI SDK CMP conforms to RFC 2510 and is compatible with other products that conform to this certificate management protocol (CMP) specification. In addition, it conforms to RFC 2511 and is compatible with other products that conform to this certificate request message format (CRMF) specification.
Java Cryptography Extension (JCE) from Sun Microsystems is a framework for implementing encryption, key generation and key agreement, and Message Authentication Code (MAC) algorithms.
The Oracle JCE Provider package supplies a concrete implementation of a subset of the cryptographic services defined in JCE.
XML Security refers to common data security requirements of XML documents, such as confidentiality, integrity, message authentication, and non-repudiation.
Oracle XML Security fulfills these needs by providing the following features:
Support for the W3C XML Signature standard
Support for the XML Encryption proposed standard
Support for the Decryption Transform proposed standard
Support for the XML Canonicalization standard
Support for the Exclusive XML Canonicalization standard
Compatibility with a wide range of JAXP 1.1 compliant XML parsers and XSLT engines
The Oracle SAML API provides tools and documentation to assist developers of SAML-compliant Java security services. You can integrate Oracle SAML into existing Java solutions, including applets, applications, EJBs, servlets, and JSPs.
Oracle SAML provides the following features:
Support for the SAML 1.0/1.1 specifications
Support for SAML-based single sign-on (SSO) and federated identity profiles, such as those specified by the Liberty Alliance project
Oracle Web Services Security provides an authentication and authorization framework based on OASIS specifications. Oracle Web Services Security provides the following features:
Support for the SOAP Message Security standard
Support for the Username Token Profile standard
Support for the X.509 Certificate Token Profile standard
Support for the SAML Assertion Token proposed standard (Draft 15)
Oracle Liberty SDK allows Java developers to design and develop single sign-on (SSO) and federated identity solutions based on the Liberty Alliance specifications. Oracle Liberty SDK, available in versions 1.1 and 1.2, aims to unify, simplify, and extend all aspects of development and integration of systems conforming to the Liberty Alliance 1.1 and 1.2 specifications.
Oracle Liberty SDK provides the following features:
Support for the Liberty Alliance Project version 1.1 and 1.2 specifications
Support for Liberty-based Single Sign-on and Federated Identity
|
Note: For additional information about the standards and specifications mentioned in this chapter, see Appendix A, "References". |
