JAVA SECURITY – PACKAGES JCA/JCE - Part-I

In this tutorial, the author explains cryptography related concepts and packages in JDK. Many of the concepts and technical terms thus learnt will be useful in understanding the Cryptography API in MFC also.

There are three security related packages in JDK1.4. These are:
· JCA/JCE (Java Cryptography Architecture and Java Cryptography Extensions);
· JSSE (Java Secure-Sockets Extension); and
· JAAS (Java Authentication and Authorization Service).

NOTE: Prior to JDK1.4, many of these packages were not available within JDK and had to be separately installed and used. Now, JDK1.4 has incorporated all these within JDK itself.

Understanding the terminology of these important packages requires that we have some familiarity with the technical terms used in the field of Network Security. We can begin by saying that secure communication should ensure the following:

a. Integrity;
b. Confidentiality;
c. Authentication; and
d. Non-repudiation.

NOTE: There is also another requirement, i.e. Authorization. This is more to protect resources and programs from users, than with communicating the data. JAAS deals with that.

These are all standard terms used in Security. When a person, say, Sam, wants to send some information to Tom, it must be ensured that the information thus sent is not tampered with or altered on the way. This is known as Data Integrity.

Secondly, the information is meant only for Tom and so no one else should be able to understand the message. This is known as Confidentiality. There should be some indication that the message came from Sam and there should be some proof for that. This is Identification and Authentication. Such Authentication is achieved through Digital Signature. There should preferably be a trusted third party to vouchsafe for the identity and signature of Sam. This is achieved using Digital Certificate. Besides these, it is sometimes equally important that Sam should not be able to say later that he did not send the message to Tom and the message was actually sent by someone else, in his name. This is ensuring Non-repudiation. This purpose also is served by Digital signature. We will now see step-by-step the development of these concepts. Except 'Authorization', other things can be understood in the context of everyday exchange of information. 

Confidentiality is achieved using Cryptography techniques. For the sake of simple illustration, let us assume that Sam wants to send a message to Tom. (By convention, two persons Alice and Bob are chosen for illustration. Since the original thesis made use of these names, let us use Sam and Tom). Sam does not want his message to be understood by anybody else except Tom. So, he encrypts it. When Tom receives the encrypted message, he 'decrypts' it, so that he can read the original message. The original message is known as 'plaintext'. After Encryption, it becomes 'ciphertext'. The process of converting the ciphertext into the original plaintext is known as Decryption. A 'key' is used for controlling Encryption and Decryption.

There are two types of key based encryption algorithms – Symmetric algorithm and Asymmetric Algorithm.

Symmetric Algorithm

This algorithm employs the same key for encryption and decryption. This is also known as 'Secret key'.

In this scheme, when Sam wants to send a message to Tom, he encrypts the message by a mutually agreed secret key and then sends the ciphertext to Tom. Tom uses the same secret key and decrypts the message to read it.

Symmetric key system is faster than the Asymmetric system. However, problems associated with agreeing on a mutual secret key and preserving the secrecy of the key while communicating it over the network led to the development of Asymmetric key systems.

Some of the Symmetric key algorithms (Most of them are implemented in JCA/JCE) are as follows:

1. DES (Data-Encryption-Standard): was developed in 1970 and recommended by the US government. Though it is not foolproof, it is considered to be sufficiently safe and is in wide use.

It has different modes of operation, such as:
· Electronic Cook book (ECB);
· Cipher Block Chaining (CBC);
· Output Feedback Mode (OFB); and
· Cipher Feedback Mode (CFB).

2. TripleDES (also known as DESede): An improved and very safe method of DES.

3. IDEA (International Data Encryption Algorithm). This is used in PGP (Pretty-Good-Privacy method of secure Email).

An important advantage of Secret key algorithm is that a hardware-approach is possible. This results in very high-speed encryption. The hardware implementation by a VLSI chip can be about 20 times faster than the corresponding software implementation!

IDEA has been implemented in hardware.

4. Blowfish: Bruce Schneier designed this algorithm. It is not patented and Schneier has placed the implementation in public domain.

5. There is also a method known as Password-based Encryption (PBE). We will have a brief description of this method, with a code example. 

Ready-made implementations for many of these algorithms are available in SunJCA/JCE and the programmer just chooses the desired algorithm and uses it. No deep knowledge of the mathematical theory of algorithms or how these algorithms are implemented is required. Such topics are highly mathematical and are dealt with in books on Cryptography.

Asymmetric Algorithms

This algorithm is also known as 'Public Key' algorithm. There are two keys in this scheme. One key is called 'public key' and the other key is named 'private key'. (It should be noted that 'secret key' does not mean 'private key'!)

Two research workers at Stanford University – Diffie and Hellman – developed the basic theory of public key cryptography in 1976. The DH algorithm is known as Key-Agreement method.

RSA algorithm is an implementation, named after the initials of the three academics who invented it — Rivest, Shamir and Adleman. RSA is the defacto standard.

Another asymmetric algorithm is DSA (Digital Signature Algorithm). Yet another algorithm is known as ECC (Elliptic-Curve Cryptography). It is reputed to be very efficient and fast. [However, SunJCA/JCE does not provide ready-made implementation for ECC.]

The public key and private key are known as 'keypair'. The public key and private key are mathematically related in the sense that if a message is encrypted using a particular public key, it can be decrypted by the corresponding private key and vice versa. However, the problem is that any person who knows Sam's public key can decrypt the message. As such, RSA system uses the public key of the recipient to encrypt data. (But, the private key cannot be derived from public key. Similarly, the public key cannot be derived from private key).

RSA method is the most widely used scheme. When Sam wants to send a secret message to Tom, he should know the public key of Tom, to begin with. (Just as we should know the mail-id of our friend first, if we want to send an email to him). Sam encrypts the message by using Tom's public key and sends it to Tom. At the receiving end, Tom uses his (Tom's) private key and decrypts the letter and reads it. The advantage of this scheme is that it ensures that only Tom will be able to read the message, as only his private-key can decrypt the message encrypted with his public key. A person's private key need never be known to anyone else and there is no sharing the key with another person. Only the public key needs to be informed to others. (Much like the difference in sharing our mail-id and sharing our password!). Thus, key-administration problem is less.

DigitalSignature and MessageDigest 
The Asymmetric system has another use as well. It can be used for creating the Digital Signature, to ensure that the message came from Sam. Though the message itself can be signed without creating a digest, the usual method is to sign the messagedigest, so that Integrity of data also can be ensured.

A 'Message Digest' is a digital fingerprint. It is often referred to simply as a digest (summary) or hash. It is a one-way process, i.e. it is impossible to reconstruct the original from the hash.

MD5 (MessageDigest-5) and SHA-1 (Secure Hash Algorithm) are two examples of such Digesting algorithms. These two are provided in the Sun security package. MD5 accepts some input and produces a 128-bit message digest. SHA-1 is more secure and produces a 160-bit message digest. 

When Sam wants to send a secure message, he passes the message through a MessageDigest engine. The result is a hash. He then encrypts the hash by using Sam's private key. (This encryption is done on the hash and not on the data.) We thus get the Digital Signature.

Finally, Sam encrypts the original message using Tom's Public key. After this, Sam sends the package to Tom.

At the receiving end, Tom uses his (Tom's) private key to decrypt the message. By using Sam's public key, he decrypts the digital signature and so gets the original hash (hash1). Using the same one-way hash algorithm on the text message, Tom creates another hash (hash2).

If hash2 matches hash1 exactly, it means that the data has not been altered in transit. Thus, we get assurance of Confidentiality and Data Integrity. It also ensures the identity of the sender, because hash1 was obtained using the public key of Sam to decrypt the package.

If the public key of Sam, used by Tom, has the added assurance from a certified authority that it really belongs to Sam, this is a clear-cut method with no problems except that it is not suitable if the message being encrypted is of large size. Besides satisfying the requirements of Authentication, Confidentiality, Integrity and Non-Repudiation, we should also ensure that the process is fast, in Enterprise level. The method outlined above is slow and so may not be suitable for large messages. Otherwise, it is a satisfactory method (We will describe a hybrid method used for large messages, shortly). 

At times, it may be enough if there is Authentication and Non-Repudiation, without confidentiality. In such cases, it is enough if Sam sends the message-digest encrypted by Sam's private key, along with the plaintext. 

Digital Certificate

Just now we saw that Tom made use of Sam's public key to verify his Digital Signature. How does Tom get to know the public key of Sam? Sam could have published his public key on the Internet or could have sent it to Tom, personally. A person's public key can be freely published and shared and for this reason, anybody can use it, not necessarily Sam. A Digital signature of Sam can be verified only if Sam's public key is available to Tom but as it is a public key, impersonation is possible. A trusted third party is required to certify that the said key is really Sam's public key. This is called Digital Certificate and an authority issuing such a certificate is know as the Certifying Authority (CA).

Public Key Infrastructure (PKI)

When Sam wants his public key to be certified by a CA, he generates a keypair and sends the public key to an appropriate CA with some proof of his identification.

The CA checks the identification and then, after satisfying that the key has not been modified in transit, issues a certificate relating the public key of Sam with his identity, by signing the public key of Sam with the private key of the CA. The standard format of issuing the certificate is known as X509.

Who is to attest the CA themselves? The CA is self-attested.

The PKI standard has been developed by RSA Security Systems in collaboration with Industry leaders like SUN, IBM and Microsoft and is the industry standard.

Certificate-Revocation

A certificate becomes invalid after the expiry of the validation period. Sometimes, the private key associated with a public key gets compromised, i.e. exposed, and in that case also, the certificate should be withdrawn (revoked). The owner of the private key also may like to change it. The CA publishes a list of such defunct certificates and Tom should verify that Sam's certificate is still valid, before important transactions.

Message-Authentication-Code (MAC)

Digital Signature makes use of Sam's private key to sign the hash. An alternative to Digital Signature is to use a secret key to encrypt the hash. By its very definition, secret key is common to both Sam and Tom. So Tom can use the secret key at his end and get back the hash. The code thus generated by mixing the hash and the secret key is known as MAC. Digital Signature is better than MAC because it does not need any 'secret' key. In the context of E-Commerce, where there are thousands of parties, secret key administration is always very difficult.

The scheme outlined above is suitable for most purposes. However, for very large amounts of data, encryption and decryption of data by public key systems becomes time-consuming and requires large resources. In such cases, it is preferred to use Symmetric Encryption systems with some modifications. Hybrid Systems make use of Asymmetric method for agreeing upon a secret key and the actual encryption and decryption of data is performed by this secret key. One such method is the usual Industrial practice. The Secret key used here is valid only for a particular instance of transmission of message and so is usually called 'session-key'. (This is not the 'session' as usually understood in servlets, because this is a one-time operation).

Digital Envelope

An illustration of Hybrid method is a Digital Envelope. In this scheme, Sam encrypts the message by a random Secret key, (known as DEK, i.e. Data-Encryption-key or session key). Next, Sam encrypts this session key with Tom's public key. At this stage, Sam sends both the encrypted message and the encrypted session key to Tom.

At the receiving end, Tom uses his private key to get the session key. Using this session key, Tom decrypts the message.

As Symmetric method is about 1000 times faster than Asymmetric method, this is a good combination. Though public key method also has been used here, it is only for encrypting the session key and not the message. This can be further improved by creating a hash of the message and signing it. Also, there is no permanent Secret key between Sam and Tom, and the required secret key is produced just as required and then discarded after the job. Thus, the method is fast and secure.

With this background information, let us now see some simple code examples, specific to JDK, in the next part of this article.