Read an Excerpt
Chapter 8: Cryptography in Java
"I am fairly familiar with all forms of secret writings, and am myself the author of a trifling monograph upon the subject, in which I analyze one hundred and sixty separate ciphers, but I confess that this is entirely new to me. " Sherlock Holmes, The Adventure of the Dancing Men(A.Conan Doyle)
From JDK 1.1 onwards, Java provides general purpose APIs for cryptographic functions, collectively known as the Java Cryptography Architecture (JCA) and Java Cryptography Extensions (JCE). Signed applets, which we will discuss in the next chapter, are one specialized use of the JCA capabilities.
In this chapter we describe the sort of problems for which cryptography can provide solutions and then look in more detail at JCA and JCE.
8.1 Security Questions, Cryptographic Answers
We want to create secure applications, but "secure" means different things depending on what the application does and the environment in which it operates. In each case we need to understand what the requirements are, based on the following categories:Authentication How sure does the client need to be that the server really is who it claims to be? And does the server need to identify the client, or can he or she remain anonymous? Normally, authentication is based on either something you know (such as a password), or something you have (such as an encryption key or card). A developing form of authentication is based on something you are, including biometric measurements such as retinal scans or voice recognition.
Access control Having found out who is at the other end of the session, the next step is to decide whether they are allowed to do what they want to do.
Data integrity You want to be sure that data has not been altered
This is especially true if the application crosses an insecure network, such as the Internet, where a man-in-the-middle attack may be easily mounted,
Confidentiality If any of the data that you are sending is sensitive, you do not want an attacker to be able to read it in transit. To prevent this it needs to be encrypted.
Non-repudiation In a business application you often have to be able to prove that a particular transaction took place.
If we measure applet sandbox security against these requirements we find that the only one it helps us with is access control. The control is very strict: the security manager says "I can't authenticate the server that delivered this applet, so I will allow it to only do safe things."
As we mentioned in "Cryptographic Tools in Brief" on page 31, we have a trio of tools to answer the questions that these requirements pose, namely: symmetric key encryption, public key encryption and hashing/digital signatures.
Symmetric key, or bulk, encryption provides confidentiality, by making sure that a message can be read only if the recipient has the same key as the sender. But how to share the key in a secure manner? A common answer is to use public key encryption. This is too inefficient for general encryption of the whole data stream, but it is ideal for encrypting a small item, such as a bulk encryption key. The sender uses the receiver's public key to encrypt it, knowing that only the owner of the private half of the key pair, that is to say the receiver, will be able to decrypt it. Having secretly shared the bulk encryption key in this way, they can then use it to encrypt the real data that they want to keep private.
Digital signatures also use public key encryption, but the other way around. Figure 20 illustrates how they work.
The sender generates a digest from the data and then encrypts it with its private key. It then sends the result, together with the public key, along with the data. The receiver uses the public key to decrypt the signature and then performs the same hashing function on the data. If the digest obtained matches the result of the decryption, the receiver knows:
1. That the data has not been changed in transit (data integrity)
2. That it really was sent by the owner of the key pair (authentication)
8.1.1 Public Key Certificates
Whenever public key encryption is used, the owner of the key pair has to make the public key available to the session partner. But how can the session partner be sure of where the key really came from? The answer lies in public key certificates. Instead of sending a naked key, the owner sends a certificate, which is a message containing:
The public key
The expiry date of the certificate
Optionally, additional application-specific data
The whole message is digitally signed by a trusted third party, that is, an organization that is trusted by both sender and receiver (usually known as a Certificate Authority, or CA). The resulting certificate electronically ties the real identity of the user to the public key.
The international standard for public key certificates is called X.509. This has evolved over time and the latest version is V3. The most significant enhancement in X.509 V3 is the ability to add other, arbitrary, data in addition to the basic identity fields of the distinguished name. This is useful when constructing certificates for specific purposes (for example, a certificate could include a bank account number, or credit card information).