Friday, May 26, 2006

Establishing Trust

Java Security Series Part 4

Establishing trust is an essential ingredient when building reliable systems, as, based on trust the various access privileges are provided. And to establish trust we need to have a secure means to authenticate the trusted entity.

For example, the Java 2 security model works on providing access to trusted protection domain. As we saw in the previous parts in the series, a protection domain encapsulates among other things, code source which is nothing but a combination of codebase URL and its signers. So, if we trust code to be downloaded from sandeshudupa.blogspot.com and trust its author, then we need to make sure that when we download the code, it really is written by it trusted author and not an imposter. To perform this authentication, we use Digital Signatures.

Before we start off on digital signatures, we need to understand some basic concepts related to Crytpography.

Cryptography
This pertains to the technology of encoding and decoding information. Cryptoanalysis, on the other hand is the reverse of cryptography and deals with breaking secretly encoded information without the knowledge of encryption keys. Some of the commonly used cryptography concepts in security systems are -



  • One way hash functions
  • Symmetric Ciphers
  • Asymmetric Ciphers
One way hash functions and Message Digests
One way hash functions are used to help achieve data integrity. Two properties of one way hash functions aid in helping achieving data integrity -



  • It is easy to compute, but very difficult to reverse. Meaning given any information, computing one way hash is easy, but given the hash, it is difficult to get back the information.
  • No two pieces of information can have the same one way hash.
Using the above two features, information and its hash, also referred to as Message Digest can be sent to the user, and user could recompute the hash of the information. If the computed hash is the same as the hash that was sent along with the information, then that means that the information was not tampered with in its transit. So, one way hash provides a means to specify data/information integrity.



Data --> HashFunction --> HashValue (Message Digest)

However, providing only this means is not good enough. What if a dubious entity in the transit changed both the information and its digest. The receiving entity will get changed information and on using the one way hashing will confirm that the data integrity is not broken. But the problem is that the data received is totally different than what was sent. So, there has to be a means to prove the integrity of the message digest. This is done by Digitial Signatures.

Symmetric Ciphers
Symmetric ciphers transform input aka plaintext to output aka ciphertext using a secret key so that only those entities which know the secret key can convert back ciphertext to plaintext. These are also called Secret-key Ciphers as both the parties need to know the secret key. Some of the used Symmetric cipher technologies are Caesar Ciphers, DES (Data encryption standard) and AES (Advanced Encryption Standard).



PlainText --> EncipherEngine (SecretKey) --> CipherText

PlainText <-- DecipherEngine (SecretKey) <-- CipherText

A problem with symmetric ciphers is that the secret key needs to be safely shared between both the encrypting and decrypting entities. This problem is solved by Asymmetric Ciphers.

If the receiving party knows the secret key of the sending entity, then it knows for sure that the information received is from where it is expecting. The cipher text here is the digital signature of plaintext.

Asymmetric Ciphers
These ciphers are also used for the same means as that of symmetric ciphers, but instead of using a secret key, they use a pair of keys - Public/Private key pairs. These key pairs have a mathematical relationship between them such that given a private key, it is possible to deduce the public key, but the reverse is very difficult.

Using this property of these key pairs, it is then possible to encrypt plaintext to ciphertext using the public key and decipher the plaintext back from ciphertext using the private key. Another interesting point here is that some asymmetric keys also have the property that using the private key and decipher engine, plain text can be converted to ciphertext and then using the encipher engine and public key, the ciphertext can be converted to plaintext.



PlainText <--> EncipherEngine (PublicKey) <--> CipherText

PlainText <--> DecipherEngine (PrivateKey) <--> CipherText

So, the sending party can use the decipher engine and its private keys to create ciphertext. The recieving party using the public key of the sending party can get the plain text out of ciphertext. As with symmetric ciphers, the cipher text here is the digital signature of plaintext.

Some of the available asymmetric systems are (1) RSA named after its inventors (2) DSA (Digital Signature Algo)

Digitial Signatures
Using the above techniques, we can make sure that the information that we receive


  • is not changed in transit
  • is from the entity from where we expect the information.
Typically, to achieve this, the following is done by the sender


  • Create a message digest for the message being sent. This will ensure the message integrity.
  • Digitally sign the message digest with PrivateKey. This will ensure the integrity of the message digest.
  • Send the message, message digest and signature.
The receiving end will


  • Use the sender's PublicKey and encipher engine to get the message digest back. Compare the content of the message digest thus enciphered and the message digest sent. If they are the same, then the message digest was really sent by the entity from we were expecting.
  • Next compute the message digest of the actual message. If the computed message digest is the same as that sent, then the message itself has not been tampered with.
These same priciples are applied in Java, when trusting code and forms the basis of signing code.
JAR Signing

To establish trust in code, code needs to be signed and this is done by JAR signing. The following components in the JAR file allow for signing of JARs -
META-INF directory
This is a directory in the archive which contains other control related files.
MANIFEST.MF file
Contains sections for various files in the archive and each section is separated from one another by empty lines. All files that needs to be signed need to be listed in this file in a section using a name:value pair semantics. An entry with name Name and value path or URL to the actual file followed by another attribute with name of the message digest format and value message digest of the file. For example


Name: test/classes/ClassOne.class
SHA1-Digest: TD1GZt8G11dXY2p4olSZPc5Rj64=

Signature Instruction file
For each signer of JAR a signature instruction file and a corresponding signature block file is created. This file also contains entries like that in the MANIFEST.MF file, with a Name entry pointing to a file and an attribute entry with name being the message digest algorithm name and value being the message digest of the section in the manifest file for the named file. For example


Signature-Version: 1.0
SHA1-Digest-Manifest: h1yS+K9T7DyHtZrtI+LxvgqaMYM=
Created-By: SignatureFile JDK 1.2

Name: test/classes/ClassOne.class
SHA1-Digest: fcav7ShIG6i86xPepmitOVo4vWY=

Name: test/classes/ClassTwo.class
SHA1-Digest: xrQem9snnPhLySDiZyclMlsFdtM=

Name: test/images/ImageOne.gif
SHA1-Digest: kdHbE7kL9ZHLgK7akHttYV4XIa0=

Name: test/images/ImageTwo.gif
SHA1-Digest: mF0D5zpk68R4oaxEqoS9Q7nhm60=

Here the message digest is the digest of the manifest file entry for this file. Also, the digest of the entire manifest file is stored.
Signature Block file
A signature block file is created for evey signature instruction file with same name but extension dependent on the algorithm used to sign. The contents are the (1) digital signature of the Signature Information File and (2) public key and certificates

KeyTool and Jarsigner tools

Keytool utility is used to create the set of keys needed for signing. The generated keys and a self signed certificate are stored in a key store which is ofcourse password protected. The following command can create a keypair along with a self signed certificate with alias sandesh.

keytool -genkey -alias sandesh -keypass pass1 -validity 80
-keystore sandeshKeyStore -storepass pass2

Then a jar file, say sandesh.jar could be signed as follows -

jarsigner -keystore sandeshKeyStore -storepass pass2
-keypass pass1 -signedjar ssandesh.jar sandesh.jar sandesh

The signed jar could then be verified as follows -

jarsigner -verify ssandesh.jar

JAR Verification Proecess

Typically the following needs to occur while JAR verification. The steps may be optimized by the runtime, but in essence, this needs to happen -
  • Certificate/Certificate Path in the Signature Block file is first validated first to trust the Public Key of the Signer
  • Using the Public Key, the Digital Signature of the Signature Info File is decrypted. If the decrypted Sig Info is the same as the Sig Info file in the META-INF directory of the JAR, then the signature is considered verified.
  • Digest entry of each section in the MANIFEST.MF file is then computed and checked against the Digest entries present in the Sig Info file. If this comparison succeeds, then it means that the integrity of the file digests is not compromised.
  • Then the digests of each file is computed and compared against the digest value in entry in the manifest file.
If all the above pass, then the verification is considered successful.