12.1 PKCS Overview

 <  Day Day Up  >  

RSA and a consortium of companies developed the first portions of PKCS in 1991. The set of PKCS standards has expanded and matured to encompass everything from defining encryption techniques (PKCS#1 and PKCS#5) to the exchange of personal information (PKCS#12). The current set of standards from RSA also includes PKCS#7, which describes how signed and encrypted data should be presented; and PKCS#8, which defines the format for private keys, including encrypted private keys. PKCS#9 defines a set of attributes used by many of the PKCS standards.

PKCS is widely used in today's e-business transactions even if the application programmer is not aware of it. The primary PKCS standards that we have introduced here are useful in themselves but can be aggregated and expanded in a standard fashion to allow more complex application. For example, one way a user can request a certificate from a Certificate Authority is for that user to send his or her public key in a PKCS#10 object to the CA. [1] Once the request is approved, the CA issues a certificate that is wrapped in a PKCS#7-formatted object.

[1] A certificate request could be made using the Certificate Management Protocol (CMP) as well. CMP is defined in Request for Comments (RFC) 2510 at http://www.ietf.org/rfc/rfc2510.txt.

The Java Cryptography Architecture and the Java Cryptography Extension provide the basis for fundamental security operations, such as message digest, digital signature, encryption, and digital-certificate creation. These operations make heavy uses of PKCS. The PKCS standards give cryptographic service providers a formal framework to bring the right level of public-key technology and interoperability into JCA and JCE providers.

The following sections give a brief overview of the purpose of each of the relevant PKCS standards. This discussion is followed by scenarios showing how the PKCS standards are often used in practice in e-business applications.

12.1.1 PKCS#1: RSA Cryptography Standard

Two popular types of public-key algorithms are Digital Signature Algorithm (DSA) (see Section 10.3.3.2 on page 372) and RSA (see Section 10.3.3.1 on page 371). DSA can be used to sign messages by encrypting the hash of the data, although it cannot be used to encrypt data in general. In contrast, RSA provides a more general-purpose encryption solution, including a standard for using RSA public and private keys for encryption. DSA is not widely used today.

The fundamental building block for all public-key cryptography is PKCS#1, which defines a method for encrypting data using the RSA public-key cryptosystem. PKCS#1 describes RSA key generation, key syntax, the encryption process, the decryption process, signature algorithms, and object identifiers that can be implemented by various JCA and JCE providers. PKCS#1 is also used in the construction of digital signatures and digital envelopes, as described in PKCS#7. PKCS#1 describes a syntax that is very important for interoperability: the public-key syntax, used in certificates, and the private-key syntax, used typically in PKCS#8 private-key information.

12.1.2 PKCS#5: Password-Based Cryptography Standard

PKCS#5 is similar to PKCS#1 in that it describes a standard for encryption. However, instead of defining standards for public-key encryption, PKCS#5 describes standards for password-based encryption. In particular, PKCS#5 specifies how to use passwords or text to generate symmetric keys. Although not directly related to public keys, the algorithms introduced in PKCS#5 are used by other PKCS standards that use or store public and private key pairs, such as encrypting a private-key object with a password.

PKCS#5 defines how a password and a random number, known as a salt , are to be mixed together to form a symmetric key. In PKCS#5, the password and the salt are digested to produce 16 or 20 bytes of data. PKCS#5 also defines the password format.

PBE involves generating a symmetric key from a password and using it for encryption. Usually, though, a password does not have enough effective random bits to qualify as a candidate for a key or even a random seed to generate a key. For example, each character of an 8-byte alphanumeric password that also allows case-sensitive letters has the equivalent of slightly less than 6 bits of randomness. For 8-character passwords, this is far less than the required key size of a block cipher, such as DES.

Therefore, a good PBE implementation not only uses the password but also mixes in a salt to create the key. Normally, the mixing is a message digest. This makes the task of getting from password to key very time consuming for a hacker performing a dictionary attack. [2] Digesting a password with a salt helps thwart dictionary attacks. With a salt, the attacker has to create a dictionary of keys generated from each password, but each password then has to have a dictionary of each possible salt. Additionally, using an iterative function in the process of generating a symmetric key makes it more difficult for an attacker to find the key.

[2] In a dictionary attack , an attacker puts together a dictionary of keys generated from likely passwords and tries out each key on encrypted data. Using PBE without mixing in a salt would greatly reduce the amount of work to find the key and might make it feasible to recover encrypted material.

12.1.3 PKCS#7: Cryptographic Message Syntax Standard

A simple security operation, such as signing a message and verifying the signature, requires many attributes and objects. To name just a few, the signer and the verifier of the message must know the signature algorithm, signer's certificate, original message, and signature bytes. PKCS#7 specifies how to package this information in a standard format, allowing senders to encode the objects and receivers to decode the information in a predictable, interoperable way, using independent implementations .

This standard covers a variety of complex objects, including but not limited to SignedData and EnvelopedData , which are used for sending signed and encrypted data, respectively, to recipients in a trusted manner, as we will see in Section 12.3.1 on page 442. These objects can wrap each other, providing even more flexibility, extensibility, and functionality. For example, a message can be sealed, which involves creating a SignedData object with the data that in turn is encrypted within an EnvelopedData object. After decrypting and verifying the message, the recipient of a sealed message gets the security guarantees of both the signing and encryption processes, not just one or the other.

12.1.4 PKCS#8: Private-Key Information Syntax Standard

Public keys are meant to be shared freely . Certificates bare them for the world to view, as public keys are crucial to the verification process. Private keys, on the other hand, are meant to be hidden or stored securely. The owners of private keys should not store them unprotected for others to causally view or maliciously use. PKCS#8 provides standard definitions for encoding and decoding private keys either in raw form or, preferably, in an encrypted format.

12.1.5 PKCS#9: Selected Attribute Types

The various PKCS standards include many common attributes, such as ContentType and MessageDigest . PKCS#9 defines these common attributes.

12.1.6 PKCS#10: Certification Request Syntax Standard

Public keys form the basis of digital certificates, which are created by CAs. However, a standard format is needed for a user to request a certificate. PKCS#10 provides a standard to request certificates from a CA. In particular, PKCS#10 describes the format of a certificate request. The process is typically started by running a key-pair generator from within an application, such as a Web browser or a Java program. A key-pair generator creates a public- and private-key pair (see, for example, Section 11.2.6 on page 394). The application squirrels away the private key and bundles the public key and accompanying attributes into a PKCS#10 object, which is then sent to the CA as the formal certification request.

Interestingly, the CA leverages the PKCS#7 standard to send back the generated certificate to the user's application within a SignedData object, as PKCS#10 does not specify a return format. The application takes the certificate and associated private key and stores both into a certificate database, or keystore (see Section 11.2.7 on page 395).

12.1.7 PKCS#12: Personal Information Exchange Syntax Standard

Today, in many cases, keys are stored in a vendor-specific way. Therefore, applications need to be able to share the same keys while avoiding the use of proprietary formats. The solution is PKCS#12. This standard describes a transfer syntax for personal-identity information, including private keys, certificates, miscellaneous secrets, and extensions. This standard also allows applications to import, export, and exercise a single set of personal information. The personal information specified by a PKCS#12 standard is protected by privacy and/or integrity modes.

A browser stores trusted-parties certificates into a certificate database. These certificates are typically self-signed certificates belonging to trusted CAs. Popular browsers, such as Netscape Communicator and Microsoft Internet Explorer, also store users' key pairs and certificates in this database. The keys and certificates that are stored in a browser are for secure-transaction assurance in the Internet.

For instance, to authenticate the possessor of a Web site, the user of a Web browser can establish a successful SSL connection with server authentication between the Web browser and the Web server hosting the Web site (see Section 13.1 on page 449). Authenticating the server requires obtaining the server's certificate and verifying that it has been signed by a trusted party (see Section 13.1.2 on page 452). As another example, a user can authenticate a seller on the Internet, based on the seller's certificate. If the seller's certificate has been signed by a trusted party, the seller can be considered authenticated.

Sensitive information, such as passwords and credit card numbers , is protected by cryptographic means. However, the keys and certificates that are stored in the browser are limited for use only within the browser. Other applications generally do not have access to the information stored in a browser's keystore. Besides that limitation, keys and certificates are usually obtained from the Internet through a third party, such as VeriSign. A user cannot easily generate a key pair and be certified by a CA off line. Even if a user has a key in the browser's database, that key cannot be used without using the browser. This limits the use of the keys.

However, browsers implement key-import and key-export functions, and PKCS#12 is one of the formats that common browsers support. Using the PKCS#12 format, a browser can export protected keys and certificates to files. Applications can therefore obtain the necessary information from such files. Usually, the information is protected in PKCS#12 format by a password using PBE. This is similar to the concept of a Java keystore: In the J2SE reference implementaiton, keystores are protected by a password that only intended users possess (see Section 11.2.7 on page 395).

As PKCS#12 is a complex specification, implementing it in each application is not feasible. For that reason, instead of having a vendor-specific Java keystore, a Java keystore that implements the PKCS#12 specification greatly improves the usability and interoperability of keys and certificates stored in a browser.

PKCS#12 provides for the bundling of various object information into one object. Although PKCS#12 objects can be used for a variety of applications, Web browsers use this standard to export a certificate and its associated private key in a confidential yet standard-based fashion. The user can import the created PKCS#12 file into a different certificate database, such as that belonging to a user directory or another Web browser's certificate database. As the file includes the sensitive private key, users can encrypt and thus protect the PKCS#12 file with a key or with a password, leveraging the PBE-based algorithms defined in the PKCS#5 standard.

 <  Day Day Up  >  


Enterprise Java Security. Building Secure J2EE Applications
Enterprise Javaв„ў Security: Building Secure J2EEв„ў Applications
ISBN: 0321118898
EAN: 2147483647
Year: 2004
Pages: 164

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net