Writen by Geoff Whittington
Introduction
In the 21st Century, information is being exchanged electronically at an ever-increasing rate. Financial markets, commerce, and communication between citizens of all nations are utilizing the Internet and proprietary networks to exchange sensitive information. In pace with this trend are those rogue persons increasingly intercepting this information or supplanting it with misleading or erroneous messages. To continue effectively in this space Java developers should be aware and capable of building components and architecting systems based on a reliable technology that can fit within a secure environment. An available technology for securing facets of systems is Cryptography.
Background
Sun recognized that their Java programming language was being used to develop e-commerce systems. To address the requirement for secrecy they offered the JCE to the Java community as a downloadable API from their website. When Sun acknowledged that systems were increasingly using this API, they bundled it with the SDK in 2002.
The JCE is a pluggable technology. Sun defined the JCE interface but the technology is quite flexible; it allows different entities to provide its implementation. This facility was largely motivated by the fact that cryptographic products are under US federal export controls. The US government maintained that cryptography products are "weapons" and mandated that they fall under federal export controls.
The strength of a JCE implementation is largely dependant on the key sizes that it supports. Sun's standard JCE implementation currently shipped with the SDK is in compliance with the US's export controls. This means any Java system utilizing Sun's JCE implementation can be exported outside the US. However, the cost of using this implementation means a reduction of the Java system's strength. The beauty of the JCE is that it is possible to develop a system honouring the JCE and plug in a stronger JCE implementation. One such JCE implementation is Cryptix[2], an open source solution being maintained and developed by developers from The Netherlands and around the world. The Cryptix solution is useful since the code is open, has an active community, and has deep experience writing cryptographic software.
Before a developer can take advantage of the JCE it is useful that he understand the technology on which it is based. To this end the document will establish a few definitions and continue with a disclosure of cipher systems and protocols. These will aid the reader with understanding the JCE as well as other documents related to cryptography.
Definitions
Secret Key: A secret piece of information which is shared by two parties and used when securely exchanging information. To be effective the secret key is smaller than the information to be shared. It is used in conjunction with a cryptographic algorithm to encrypt or decrypt sensitive data.
Encrypt: The method of scrambling information to secure it against onlookers. Encryption is used with a secret key that is known only by the sender and receiver of the sensitive information.
Decrypt: The method of descrambling information from a previous encryption. Decryption requires the knowledge of a secret key.
Cryptographic Algorithm: Method which describes how a secret key is utilized to encrypt or decrypt information. It is also known as cipher.
Plaintext: The information to be secured.
Ciphertext: The scrambled information after an encryption process using a cryptographic algorithm and a secret key.
The JCE includes an assortment of cryptographic algorithms to perform encryption and decryption. Assuming a correct implementation, the greater the size of a secret key supported by an algorithm, the more secure an algorithm can be made. Cryptographic algorithms are used in the context of two systems.
Cryptographic Systems
There are two systems used in cryptography: symmetric and asymmetric (or public-key). Symmetric cryptography deals with keeping information secure with a single key; whereas asymmetric cryptography can secure information utilizing two keys. In the case of public-key systems, information is secured with a publicly known key and decrypted only with the secret private key.
Symmetric cryptography has the advantage of being fast. The operations it performs are transposition and substitution; which can be effectively expressed in hardware or software. The problem with symmetric cryptography is that its secrecy relies on the privacy of the shared key. An example of a symmetric cryptosystem would be one utilizing the DES (Data Encryption Standard), Blowfish, AES (Rijndael)[3] algorithm.
Asymmetric cryptography requires two keys (one to be kept secret, and another which can be publicly known). This scheme is superior to symmetric systems because it can facilitate secure key exchange and authentication, but it does so at the cost of slower processing times. Public-key systems use hard mathematical problems for the basis of their security.[4]
With these two systems various cryptographic protocols can be expressed and utilized for sharing secrets.
Cryptographic Protocols
In line with other security texts the author will use the characters Alice, Bob, and Eve. The first two are representative of systems that want to engage in a secure information exchange. Eve represents an entity who wishes to intercept sensitive information or to pose as Alice or Bob.
Consider that Alice and Bob are both intelligence operatives. Alice wants to give Bob the coordinates of a valuable witness who is in a safe house. The witness must show up in 8 days to testify at a court in The Hague. Unfortunately both are on different continents: Alice lives in Toronto and Bob is located in Holland. Alice does not want anyone else, like Eve, to find out where the witness is located, because Eve would surely divulge the location to the Mafia – the organization against which the witness will testify. Eve is also interested in thwarting Bob's attempts to find the witness and will do whatever it takes to push him off course. Alice and Bob each have the use of the Internet and access to a Java development system, including a full strength implementation of the JCE.
Alice and Bob are knowledgeable in cryptography and Java development. Over an insecure means Alice and Bob determine they will use the Rijndael algorithm to scramble their information[5]. The next step is for each to consider a protocol with which both will use to securely and effectively exchange information.
Simple Symmetric Protocol
Alice may choose to use the simple symmetric protocol. It requires that Alice and Bob establish a secret key with which the location can be encrypted. The two need to somehow agree upon the secret key in a secure manner- like in a private conversation, for example. The steps to accommodate a secure exchange using a simple symmetric system would be:
1. Alice would type the witness' location into a simple text file using an editor.
2. Alice would use the Rijndael cipher from the JCE to scramble the text file using the secret key agreed upon with Bob.
3. Alice would send the output of step 2 to Bob using email.
4. Bob reads his email, expecting a scrambled bit of text from Alice, and uses his JCE decryption Java program to descramble the text using the secret key agreed upon with Alice. Bob would now have the location of the witness.
Simple Asymmetric Protocol
In the previous situation Alice and Bob needed to agree upon a secret key for their secure communication in person. However, in most circumstances it is not possible to establish the secret key. In fact, since Alice and Bob live in different countries it is unlikely that physically meeting up with one another is feasible. In these situations asymmetric or public key systems excel.
A public key system works in the following manner: Alice and Bob each have two keys, one of which is secret to themselves and the other which is publicly known. The publicly-known key is registered with a trusted entity. The property of a public key system is that the sender can encrypt a message using the intended recipient's public key, and the only key which can decrypt the message is the recipient's private key. Each person keeps their private key to themselves.
In our example Alice and Bob establish their public and private keys on the first day of their job at the intelligence agency, a trusted entity for both. The following describes the protocol undertaken for Alice to securely share the location of the witness to Bob.
1. Alice retrieves Bob's public key from a trusted source, from Bob himself or their employer. (It is important that the public key be gotten from a trusted source – or else Alice may inadvertently encrypt the location with Eve's public key).
2. Alice types in the location of the witness in a text file and scrambles it using Bob's public key
3. Alice sends the scrambled text file to Bob using his email address.
4. Bob opens up Alice's email and descrambles its content using his private key, which no one else knows. The location of the witness is revealed.
In this protocol an asymmetric cipher is required – such as RSA or ElGamal, two standard public key systems. Alice and Bob decide to use ElGamal.
The problem with this scenario is that the processing cost of securely exchanging information is high. Asymmetric systems are much slower than its symmetric counterpart. For high volume systems this is a real problem for CPU-restrained systems. For example, if Alice wanted to send a world map of the witness' movements the process would be quite slow for both Alice and Bob. A truly beneficial system would be one where Alice and Bob can securely agree upon a secret key through an insecure informational channel, without fear of Eve. With the established secret key Alice could scramble the sensitive map and securely send it to Bob using a symmetric algorithm.
Hybrid Symmetric/Asymmetric System
Utilizing an asymmetric cipher it is possible for Alice to securely send a secret key to only Bob. Eve could not determine it while it is in transit to Bob because it is encrypted with his public key (and the only way of decrypting such a message is with Bob's corresponding private key). Only Bob's private key will descramble the secret key. With the secret key known only to Alice and Bob, both can utilize their favorite symmetric algorithm, Rijndael, to securely exchange information.[6]
Alice and Bob decide upon this protocol and find no success in its use. Alice and Bob know that each are operating within a secure channel – but Bob is receiving a large number of emails from Alice. As Bob opens each one the contents are directing him to locations where the witness cannot be found.
After some false leads on the whereabouts of the witness, Bob is becoming more reluctant to trust the supposed encrypted emails from Alice. He is receiving a large number of emails from Alice offering the location of the witness, but he can't determine which one is correct. He suspects that Eve is using his public key and sending emails to him feigning to be Alice. There are only days left to find the witness before the important court appearance. To address this, Bob calls Alice up on the telephone and instructs Alice to sign her emails so he can authenticate the origin of the emails. Now, should Eve continue to try to send Bob off-track – Alice's email can be picked out from the other junk emails.
Signing Protocol
In addition to facilitating secure key exchanges, public key systems also support the ability to sign a message, the electronic equivalent of a person's written signature. Specifically, it is with one's private key that a person may electronically sign a document. To reduce the amount of processing and overhead with signing large documents, hash functions can be used to reduce the effort.
Hash Functions
Hash functions are one-way operations that accept data and output it to a smaller set of data, called a message digest. Only secure hash functions can be used with electronic signatures. Hash functions are considered secure when it is computationally infeasible to find two different input data that result in identical message digests. The SHA1 is one example of a secure hash function[7].
Alice can utilize the following steps to sign her email messages to Bob
1. Alice types in the location of the witness into a text file using an editor of her choice.
2. Alice performs a SHA-1 of the text file's contents and scrambles it with her private key. The hash function she uses is one that is highly secure and is known to Bob.
3. She includes the output of this scrambled data at the end of the text file
4. Alice encrypts the whole payload using Bob's public key and emails it to Bob using his email address.
To read the payload and verify that Alice sent him the message, Bob must do the following:
1. Open his email from Alice and descramble the contents using his private key.
2. Perform a hash of the supposed location of the witness using the same hash function Alice used.
3. Using Alice's public key Bob descrambles the latter end of Alice's email.
4. If the output from #2 and #3 match, Bob can be sure Alice sent the email and the location of the witness is true. Otherwise, Eve surely has tried again to lead him astray.
After receiving an authenticated email from Alice, Bob correctly finds out the whereabouts of the important witness. Bob safely takes the witness to court in The Hague so that the valuable evidence can be heard.
The JCE
Core Classes
The following is a description of the core classes that comprise the JCE.
Cipher Class
A Cipher is the main class with which encryption and decryption is performed. Around this class the JCE framework is built. An instance of the Cipher class embodies how information is scrambled or descrambled, as well as with what secret key it should use when doing its work.
A static factory method on the Cipher class is the means with which Cipher objects are created. When factorizing a Cipher object, its transformation name is essential. Additionally, it is possible to also specify the name of a JCE provider, in case there are two or more implementations available in the Java runtime environment.
A Cipher's transformation name follows the format: algorithm/mode/padding.
In our example above, Alice and Bob could create a Cipher class with the following,
Cipher cipher1 = Cipher.getInstance( "Rijndael" );
The mode describes how the cipher will scramble the information internally through its work. Standards dictate how a cipher ought to be used and in what context. Depending on the mode a Cipher instance may require an initialization vector (IV) which kick-starts the algorithm.
The padding describes how the information is padded when the plaintext is shorter than what is required by the cryptographic algorithm.
In each case, the provider of a JCE implementation will choose a default mode and padding if none are offered. In our example, Alice and Bob have agreed upon a specific implementation so they do not require the extra qualifiers for the Cipher object they wish to instantiate; the common code will choose the correct defaults.
Before working with a Cipher object, it must be initialized. The two oft-used modes are:
Cipher.ENCRYPT_MODE
Specifies that the Cipher object will be used for encryption.
Cipher.DECRYPT_MODE
Specifies that the Ciphert object will be used for decryption.
These modes are required because cryptographic algorithms behave differently in encryption and decryption mode. The other missing instantiation information is the Key. The Key can be any class that implements the java.security.Key interface, or from some certificate that contains the appropriate key.
There are other parameters that can be used with initializing a Cipher object. In all cases the parameters:
1. Specify how the algorithm will perform its work,
2. Embody a secret key with which the algorithm uses to perform its work, or
3. Reference a specific random number generator[8].
Cipher Stream Class
The Cipher Stream classes provide a Java developer the means with which to perform encryption or decryption on conventional streams.
KeyGenerator Class
Symmetric algorithms require the use of a key to scramble the plaintext into ciphertext. For systems that must create keys without user input, like SSL or PGP, some sort of key generator is required. Important to this process is the fact that symmetric algorithms each have their own definition of what constitutes a weak[9] or valid key. The KeyGenerator class solves the problem of automatically generating secure, acceptable keys.
Similar to the Cipher class, a KeyGenerator instance is created using:
KeyGenerator kg = KeyGenerator.getInstance("DES");
Using the factory method, getInstance, the above line of source code creates a KeyGenerator instance for the DES algorithm. Additionally, a JCE provider name could be added as a second parameter in case there are more than one provider offering KeyGenerator instances in its implementation. With an instance, the KeyGenerator instance must be initialized.
A KeyGenerator instance can be initialized by specifying the keysize, a random number generator, both, or some algorithm parameters. The keysize is an important parameter to consider when generating a key for an algorithm that supports many different key sizes. A developer should always be sure how strong the keys are when implementing cryptographic protocols.
With a KeyGenerator instance setup, a secret key can be made available by simply calling:
SecretKey sk = kg.generateKey();
With this SecretKey, sk, a Java developer can secure information.
In the adventures of Alice and Bob, the two could not reliably establish a secret key unless they were speaking to one another privately. Since both lived on separate continents it became harder to establish their secret key. To alleviate this they used an asymmetric cryptosystem to create a secure channel through which they would share their secret key. It is through the use of the KeyAgreement Class that Alice and Bob were able to securely share their secret key in an insecure environment.
KeyAgreement Class
Consistent with the JCE, the KeyAgreement class is available to a developer using its getInstance method. For example,
KeyAgreement ka = KeyAgreement.getInstance("DH");
creates a KeyAgreement instance utilizing the Diffie-Hellman algorithm[10]. The KeyAgreement instance requires initialization and this can be done using a user's private information. Additionally a developer can provide reference to a secure random generator, or some algorithm parameters.
Once the KeyAgreement instance is initialized the doPhase method must be called in order to establish a secure channel. The method is defined as:
public Key doPhase(Key key, boolean lastPhase);
For Alice and Bob, a single call to this method the other person's public key using in place of key and lastPhase=true, is sufficient. If there are more parties with whom the secret must be shared, then the generated Key must be shared with the participants and more doPhase invocations are required. Please refer to the JCE documentation for more details on the KeyAgreement.doPhase method.
After the single invocation, Alice and Bob will be able to extract the secret key,
byte[] establishedSecret = kg.generateSecret();
With establishedSecret Alice and Bob can securely exchange information utilizing it as their secretKey.
Mac Class
When exchanging information securely it is useful to determine if a rogue individual has intercepted the ciphertext and modified it. The JCE facilitates this through the Mac class.
Summary
Cryptography is a powerful technology that creates secure channels in an insecure environment. It allows intelligence agents, suppressed nationals, and businesses to exchange information securely with others. This technology is important in the development of systems that exchange sensitive information.
The JCE is an implementation of cryptography for Java systems. It empowers a Java developer to securely exchange keys, scramble information with a key and provide a means to descramble it. However, this provision operates within a larger context.
The technology on which the JCE is based can only claim with high confidence that the exchange will be secure: the JCE provides no guaranteed security.[11] For practical purposes I would not concern oneself with this comment. It is recommended to stay relatively current with cryptographic advances and re-address the security of a system at regular intervals. Pick secret keys that are appropriate for your application.[12]
It is also important to note that cryptography is not the silver bullet of system security. Well administered firewalls, a commitment to secure processes, and many other security measures are as important to securing a system as incorporating the latest cryptographic technologies and protocols.
Geoff leads Fireball Technology Group, Inc. - a Toronto-based software consulting firm specializing in Java and PHP web applications. Fireball uses its development abilities to maintain and enhance http://www.thelocalguru.com - Canada's first skill database that supports freelance and self-employed experts to connect with their local communities.
