The original digest needs to be trusted to be valid in order for the receiver to validate its digest. A way to protect the access to the original digest is to set up a secure database and allow minimum access to it. Another way to protect the digest is by using a secret key called the message authentication code (MAC). A third way is to protect the digest by a key pair. Some of these methods can be used together. For instance, digests that are generated with a secret key could be stored in a secure file system and periodically verified with a secret key to check whether there has been tampering.
Understanding the MAC
The message authentication code has the capability to authenticate that the message came from a group of users that have a secret key. A piece of the message, or code, is encrypted with a secret key. Only those users having a copy of the secret key can decrypt the same message, and if the correct code is decrypted, only a member with the secret key could have encrypted it. The MAC technique authenticates that a user of the secret key created the message. To pass the secret key to other users, a key exchange must take place.
The key is passed in a one-way hash to build a hash message authentication code (HMAC). Only the users who have a copy of the secret key can generate the correct digest to compare the message. The digest can be changed, but anyone who generates the digest with a different key will generate a different digest. When a user passes in the correct secret key of an altered digest, the digests will validate differently.
An HMAC is useful for checking the integrity of a message over an unreliable medium such as a network. A form of a trusted medium is a digest stored in an LDAP server. If for any reason a form of trust is needed outside the LDAP server, protocols must be used to ensure trust. Users can share a secret key to check the validity of the message. Only those users with a copy of the secret key can check the message. If a hacker intercepts a secret key, he can alter the message digest. After the hacker alters the message, the digest can no longer be trusted. The trusted point for the HMAC is the secret key. The digest trust comes from the secret key that can generate it.
The motivation behind the HMAC is to add functionality to the message digests without modifying the algorithms. Other motivations of the HMAC are not to degrade the performance of the message digests algorithms, to provide simple means of handling the secret keys, and to allow an upgradeable implementation for future message digests.
The HMAC requires a message digest and a secret key; the message digest is used to hash the digest and the secret key to encrypt the digest. The message digest iterates through 64-byte blocks and returns a 16-byte array for the MD5 digest and a 20-byte array for the SHA-1 digest. The secret key that is used for authentication can be any size that will not exceed the normal length of the input block.
The suggested length of the secret key is that it be the same as the size of the digest because having the key the same length as the digest makes a more secure hash. Having a secret key of greater length than the digest length does not increase the security of the hash. The secret key will be more secure if the key is randomly chosen to avoid any pattern.
The input block of the message digest is normally 64 bytes and can be denoted as B. B is then the size of the secret key length. If the secret key length is less than B, it is appended with zeros. If the secret key is greater than B, it is hashed and the key is replaced with the digest. After the secret key is cleaned up, the key is changed into an inner pad. The inner pad is the first piece to be digested, and the last pad is the outer pad.
The secret key is passed in the init method and is modified into an inner pad. The inner pad starts out as the secret key and is XORed with an array the size of B filled with 0x36 bytes. The size of B, in this case, is 64 bytes. The inner and outer pads are filled and XORed to add more levels of complexity into the key. Having both an inner and outer pad XORed produces different permutations of the key. Having these padded keys digested at different times adds more complexity to the key and is a means to add more security at the interface into the message digests. After the inner pad is formed, it is added to the update method of the message digest.
During the operation of the javax.crypto.Mac class, updates of data can be added anywhere from the init to the doFinal methods. The update methods are similar to the update methods in the message digest; the difference is that the doFinal method is called in the end to add the final pad. When the doFinal method is called, a digest is created from the updates for temporary use. A new digest is then created with the outer pad and the temporary digest. The final result is the combination of the outer pad being XORed with a 64-byte array filled with 0x5C bytes.
The validation is done through the combination of a secret key and a message digest. The secret key is digested in between the actual message input. Only those users who pass in the same secret key can get the same digest, otherwise the data is considered compromised. If different data or a different key is passed in, the digest produced is different. Collisions occur when multiple messages can produce the same digest. MD5 is known to produce collisions, but is still considered by most as a valid algorithm to use. The algorithms used should be considered carefully. The HMAC classes are wrappers around a generic interface into the message digest that will use a secret key as part of the digest.