Java Cryptography Architecture (JCA)

Provides basic cryptographic services and algorithms, which include support for digital signatures and message digests.

In J2SE, the JCA provides the Java platform with cryptographic services and algorithms to secure messages. JCA defines a notion of provider implementation and a generic API framework for accessing cryptographic services and implementing related functionalities. JCA is also designed to provide algorithm and implementation independence via a standardized API framework and provider implementation.

JCA provides support for various cryptographic algorithms by defining the types and functionalities of cryptographic services. The cryptographic services include support for message digests and digital signatures. JCA also ensures interoperability among the provider implementations using a standardized set of APIs, which implements those required cryptographic algorithms and services. For example, using the same algorithms, a key generated by one provider can be usable by another provider; likewise, a digital signature generated by one provider can be verified using another provider.

As part of the J2SE bundle, the JCA framework includes a default provider implementation named SUN, which provides the following features:

Supported cryptographic operations:

Java Cryptographic Extension (JCE)

Augments JCA functionalities with added cryptographic services that are subjected to U.S. export control regulations and includes support for encryption and decryption operations, secret key generation and agreement, and message authentication code (MAC) algorithms.

JCE was originally developed as an extension package to include APIs and implementations for cryptographic services that were subject to U.S. export control regulations. JCE provides a provider implementation and related set of API packages to provide support for encryption and decryption, secret key generation, and agreement and message authentication code (MAC) algorithms. The encryption and decryption support includes symmetric, asymmetric, block, and stream ciphers. JCE also provides support for secure streams and sealed objects.

JCE facilitates the Java platform with cryptographic services and algorithms by providing implementations and interfaces for the following:

Because JCE's design is based on the architectural principles of JCA, like JCA it allows for integration of Cryptographic Service Providers, which implements the JCE-defined cryptographic services from a vendor. JCE also facilitates a pluggable framework architecture that allows qualified JCE providers to be plugged in. As part of the J2SE bundle, the JCE framework provides a default provider implementation named SunJCE, which provides the following cryptographic services and algorithms:

Commonly applied JCE cryptographic operations:

Java Certification Path API (CertPath)

Provides the functionality of checking, verifying, and validating the authenticity of certificate chains.

CertPath provides a full-fledged API framework for application developers who wish to integrate the functionality of checking, verifying, and validating digital certificates into their applications.

Digital certificates play the role of establishing trust and credentials when conducting business or other transactions. Issued by a Certification Authority (CA), a digital certificate defines a binding data structure containing the holder name, a serial number, expiration dates, a public key, and the digital signature of the CA so that a recipient can verify the authenticity of the certificate. CAs usually obtain their certificates from their own higher-level authority. Typically in a certificate binding, a chain of certificates (referred to as a certification chain) starts from the certificate holder, is followed by zero or more certificates of intermediate CAs, and ends with a root-certificate of some top-level CA. So the process of reading, verifying, and validating certificate chains becomes important in PKI certificate-enabled applications and systems.

Java CertPath API Programming Model:

Java Secure Socket Extension (JSSE)

Facilitates secure communication by protecting the integrity and confidentiality of data exchanged using SSL/TLS protocols.

Protecting the integrity and confidentiality of data exchanged in network communications is one of the key security challenges of network security. During communication, the potential vulnerability is that the data exchanged can be accessed or modified by someone with a malicious intent or who is not an intended client recipient. Secure Socket Layer (SSL) and Transport Layer Security (TLS) are application-independent protocols developed by IETF that provide critical security features for end-to-end application communication by protecting the privacy and integrity of exchanged data. They establish authenticity, trust, and reliability between the communicating partners. SSL/TLS operates on top of the TCP/IP stack, which secures communication through features like data encryption, server authentication, message integrity, and optional client authentication. For data encryption, SSL uses both public-key and secret-key cryptography. It uses secret-key cryptography to bulk-encrypt the data exchanged between two applications.

JSSE enables end-to-end communication security for client/server-based network communications by providing a standardized API framework and mechanisms for client-server communications. JSSE provides support for SSL and TLS protocols and includes functionalities related to data encryption, message integrity, and peer authentication.

With JSSE, it is possible to develop client and server applications that use secure transport protocols, which include:

Java Authentication and Authorization Service (JAAS)

Provides the mechanisms to verify the identity of a user or a device to determine its accuracy and trustworthiness and then provide access rights and privileges depending on the requesting identity. It facilitates the adoption of pluggable authentication mechanisms and user-based authorization.

Authentication is the process of verifying the identity of a user or a device to determine its accuracy and trustworthiness. Authorization provides access rights and privileges depending on the requesting identity's granted permissions to access a resource or execute a required functionality.

Java Generic Secure Services (JGSS)

Provides functionalities to develop applications using a unified API to support a variety of authentication mechanisms such as Kerberos based authentication and also facilitates single sign-on.

The Generic Security Services API (GSS-API) is a standardized API developed by the Internet Engineering Task Force (IETF) to provide a generic authentication and secure messaging interface that supports a variety of pluggable security mechanisms. The GSS-API is also designed to insulate its users from the underlying security mechanisms by allowing the development of application authentication using a generic interface.

Sun introduced the Java GSS-API (JGSS) as an optional security package for J2SE 1.4 that provides the Java bindings for the GSS-API. This allows development of applications that enable uniform access to security services over a variety of underlying authentication mechanisms, including Kerberos.

One-Way Hash Function Algorithms

One-way hash functions are algorithms that take as input a message (any string of bytes, such as a text string, a Word document, a JPG file) and generate as output a fixed-size number referred to as the "hash value" or "message digest." The size of the hash value depends on the algorithm used, but it is usually between 128 and 256 bits.

The purpose of a one-way hash function is to create a short digest that can be used to verify the integrity of a message. In communication protocols such as TCP/IP, message integrity is often verified using a checksum or CRC (cyclic-redundancy check). The sender of the message calculates the checksum of the message and sends it along with the message, and the receiver recalculates the checksum and compares it to the checksum that was sent. If they do not match, the receiver assumes the message was corrupted during transit and requests that the sender resend the message. These methods are fine when the expected cause of the corruption is due to electronic glitches or some other natural phenomena, but if the expected cause is an intelligent adversary with malicious intent, something stronger is needed. That is where cryptographically strong one-way hash functions come in.

A cryptographically strong one-way hash function is designed in such a way that it is computationally infeasible to find two messages that compute to the same hash value. With a checksum, a modestly intelligent adversary can fairly easily alter the message so that the checksum calculates to the same value as the original message's checksum. Doing the same with a CRC is not much more difficult. But a cryptographically strong one-way hash function makes this task all but impossible.

Two examples of cryptographically strong one-way hash algorithms are MD5 and SHA-1. MD5 was created by Ron Rivest (of RSA fame) in 1992 [RFC1321] and produces a 128-bit hash value. SHA-1 was created by the National Institute of Standards and Technology (NIST) in 1995 [FIPS1801] and produces a 160-bit hash value. SHA-1 is slower to compute than MD5 but is considered stronger because it creates a larger hash value.

Symmetric Ciphers

Symmetric ciphers are mechanisms that transform text in order to conceal its meaning. Symmetric ciphers provide two functions: message encryption and message decryption. They are referred to as symmetric because both the sender and the receiver must share the SAME key to encrypt and then decrypt the data. The encryption function takes as input a message and a key value. It then generates as output a seemingly random sequence of bytes roughly the same length as the input message. The decryption function is just as important as the encryption function. The decryption function takes as input the same seemingly random sequence of bytes output by the first function and the same key value, and generates as output the original message. The term "symmetric" refers to the fact that the same key value used to encrypt the message must be used to successfully decrypt it.

The purpose of a symmetric cipher is to provide message confidentiality. For example, if Alice needs to send Bob a confidential document, she could use e-mail; however, e-mail messages have about the same privacy as a postcard. To prevent the message from being disclosed to parties unknown, Alice can encrypt the message using a symmetric cipher and an appropriate key value and e-mail that. Anyone looking at the message en route to Bob will see the aforementioned seemingly random sequence of bytes instead of the confidential document. When Bob receives the encrypted message, he feeds it and the same key value used by Alice into the decrypt function of the same symmetric cipher used by Alice, which will produce the original message the confidential document:

Some examples of symmetric ciphers include DES, IDEA, AES (Rijndael), Twofish, Blowfish and RC2.

Asymmetric Ciphers

Asymmetric ciphers provide the same two functions as symmetric ciphers: message encryption and message decryption. There are two major differences, however. First, the key value used in message decryption is different than the key value used for message encryption. Second, asymmetric ciphers are thousands of times slower than symmetric key ciphers. But asymmetric ciphers offer a phenomenal advantage in secure communications over symmetric ciphers.

The major advantage of the asymmetric cipher is that it uses TWO key values instead of one: one for message encryption and one for message decryption. The two keys are created during the same process and are known as a key pair. The one for message encryption is known as the public key; the one for message decryption is known as the private key. Messages encrypted with the public key can only be decrypted with its associated private key. The private key is kept secret by the owner and shared with no one. The public key, on the other hand, may be given out over an unsecured communication channel or published in a directory.

Using the earlier example of Alice needing to send Bob a confidential document via e-mail, we can show how the exchange works with an asymmetric cipher. First, Bob e-mails Alice his public key. Alice then encrypts the document with Bob's public key, and sends the encrypted message via e-mail to Bob. Because any message encrypted with Bob's public key can only be decrypted with Bob's private key, the message is secure from prying eyes, even if those prying eyes know Bob's public key. When Bob receives the encrypted message, he decrypts it using his private key and recovers the original document:

If Bob needs to send some edits on the document back to Alice, he can do so by having Alice send him her public key; he then encrypts the edited document using Alice's public key and e-mails the secured document back to Alice. Again, the message is secure from eavesdroppers, because only Alice's private key can decrypt the message, and only Alice has her private key.

Note the very important difference between using an asymmetric cipher and a symmetric cipher: No separate, secure channel is needed for Alice and Bob to exchange a key value to be used to secure the message. This solves the major problem of key management with symmetric ciphers: getting the key value communicated to the other party. With asymmetric ciphers, the key value used to send someone a message is published for all to see. This also solves another symmetric key management headache: having to exchange a key value with each party with whom one wishes to communicate. Anyone who wants to send a secure message to Alice uses Alice's public key.

Some examples of asymmetric ciphers are RSA, Elgamal, and ECC (elliptic-curve cryptography).

Recall that one of the differences between asymmetric and symmetric ciphers is that asymmetric ciphers are much slower, up to thousands of times slower. This issue is resolved in practice by using the asymmetric cipher to communicate an ephemeral symmetric key value and then using a symmetric cipher and the ephemeral key to encrypt the actual message. The symmetric key is referred to as ephemeral (meaning to last for a brief time) because it is only used once, for that exchange. It is not persisted or reused, the way traditional symmetric key mechanisms require. Going back to the earlier example of Alice e-mailing a confidential document to Bob, Alice would first create an ephemeral key value to encrypt the document with a symmetric cipher. Then she would create another message, encrypting the ephemeral key value with Bob's public key, and then send both messages to Bob. Upon receipt, Bob would first decrypt the ephemeral key value with his private key and then decrypt the secured document with the ephemeral key value (using the symmetric cipher) to recover the original document.

Digital Signature

Digital signatures are used to guarantee the integrity of the message sent to a recipient by representing the identity of the message sender. This is done by signing the message using a digital signature, which is the unique by-product of asymmetric ciphers. Although the public key of an asymmetric cipher generally performs message encryption and the private key generally performs message decryption, the reverse is also possible. The private key can be used to encrypt a message, which would require the public key to decrypt it. So, Alice could encrypt a message using her private key, and that message could be decrypted by anyone with access to Alice's public key. Obviously, this behavior does not secure the message; by definition, anyone has access to Alice's public key (it could be posted in a directory) so anyone can decrypt it. However, Alice's private key, by definition, is known to no one but Alice; therefore, a message that is decrypted with Alice's public key could not have come from anyone but Alice. This is the idea behind digital signatures.

The solution is to perform a one-way hash function on the message, and encrypt the hash value with the private key. For example, Alice wants to confirm a contract with Bob. Alice can edit the contract's dotted line with "I agree," then perform an MD5 hash on the documents, encrypt the MD5 hash value with her private key, and send the document with the encrypted hash value (the digital signature) to Bob.

Bob can verify that Alice has agreed to the documents by checking the digital signature; he also performs an MD5 hash on the document, and then he decrypts the digital signature with Alice's public key. If the MD5 hash value computed from the document contents equals the decrypted digital signature, then Bob has verified that it was Alice who digitally signed the document.

Moreover, Alice cannot say that she never signed the document; she cannot refute the signature, because only she holds the private key that could have produced the digital signature. This ensures non-repudiation.

Digital Certificates

A digital certificate is a document that uniquely identifies information about a party. It contains a party's public key plus other identification information that is digitally signed and issued by a trusted third party, also referred to as a Certificate Authority (CA). A digital certificate is also known as an X.509 certificate and is commonly used to solve problems associated with key management.

As explained earlier, the advent of asymmetric ciphers has greatly reduced the problem of key management. Instead of requiring that each party exchange a different key value with every other party with whom they wish to communicate over separate, secure communication channels, one simply exchanges public keys with the other parties or posts public keys in a directory.

However, another problem arises: How is one sure that the public key really belongs to Alice?

For example, assume Charlie is a third party that both Alice and Bob trust. Alice sends Charlie her public key, plus other identifying information such as her name, address, and Web site URL. Charlie verifies Alice's public key, perhaps by calling her on the phone and having her recite her public key fingerprint. Then Charlie creates a document that includes Alice's public key and identification, and digitally signs it using his private key, and sends it back to Alice. This signed document is the digital certificate of Alice's public key and identification, vouched for by Charlie.

Now, when Bob goes to Alice's Web site and wants to securely send his credit card number, Alice sends Bob her digital certificate. Bob verifies Charlie's signature on the certificate using Charlie's public key (assume Bob has already verified Charlie's public key), and if the signature is good, Bob can be assured that, according to Charlie, the public key within the certificate is associated with the identification within the certificate namely, Alice's name, address, and Web site URL. Bob can encrypt his credit card number using the public key with confidence that only Alice can decrypt it: