Using Asymmetric Cryptography in your ColdFusion Application - Security Series #16.10

A reader emailed me and asked:

I have a question re asymmetric encryption and the best way to achieve it....

I need to encrypt a CreditCard number on one server and store the encrypted string in a db and then 5 minutes later another server takes the card number off that DB and then needs to decrypt it. Any suggestions gratefully received :)

After an e-mail exchange we determined that we were NOT just talking about using SSL between ColdFusion and the DB and we determined that using a symmetric algorithm would not be acceptable to the credit card service. So it seems that this user really did need asymmetric encryption in his application.

Now this is not something I have dealt with before, so I have no experience with this. What I am about to outline is based on reading and research. I will try to point out the details that I am unclear on, both in the Java programming and in the cryptography aspect. If I make errors or do not explain something adequately, please let me know.

I have not yet discussed asymmetric cryptography in my security series, but I felt it was reasonable to skip ahead for this reader. Eventually I will go back and discuss asymmetric crypto in another post, so for now I will only very briefly discuss what asymmetric crypto is and why you would want to use it.

What is Asymmetric Cryptography?

Asymmetric cryptography, also known as Public Key Cryptography, is different from its counterpart, Symmetric Cryptography, in that it uses different keys for the encryption and decryption processes. Encryption is done with one key and decryption is done with another, whereas with symmetric encryption the same key is used for both encryption and decryption.

You may wonder why we would want to use asymmetric cryptography over symmetric cryptography. There are A LOT of reasons. But the reason we are looking at here is because we do not want to share a symmetric key with another machine. Whether it is because we do not trust the administrators of that other machine, or because we do not want the compromise of one machine to make the other machine vulnerable, or even if it is just because we are a control freak in a turtleneck sweater, it doesn't matter.

For the sake of having a reason, we'll say that we are doing it because we want to mitigate the risk of credit card information theft if our database server (the one holding the card data) is hacked or otherwise compromised.

Hypothetical situations are fun

Consider this situation:

We have an e-commerce site that stores and processes credit cards. We have two servers.

1. Database/Web Server
2. Credit Card Processing Server

The database server is where we store the encrypted credit card information.

If we are using symmetric encryption, then the credit cards are encrypted using the same key that we would use to decrypt them. Since the database server must have the key in order to perform the encryption, it means that if that machine is compromised, the key could be compromised, and that key could be used to decrypt the credit card information.

When the credit card processing server wants a credit card for processing, it either needs to request the unencrypted card from the database server, or it needs to have its own copy of the key to perform the decryption. There are a number of reasons we may not want this.

Hypothetical 2

Now consider the same situation, but this time, we'll use asymmetric cryptography.

When the database/web server receives the credit card information from the end user, it encrypts the data, just as it would have before, but this time it encrypts it using asymmetric cryptography and the PUBLIC KEY of the credit card processing server.

With asymmetric encryption, any data encrypted with the public key can only be decrypted with the private key (with some algorithms, it works the opposite way too, we'll talk about that someday when we discuss digital signatures). So in this situation, our database/web server will encrypt with the public key, but it will not have, or need, a copy of the private key.

Since the database/web server should never need the credit card information again, it does not matter that it will be unable to decrypt the data. And in the event that the database server is compromised, the credit card information will be safe (provided a well-designed, strong algorithm is in place) because the key will be safely tucked away on the credit card processing machine (or somewhere else). And the fact that the public key will have been compromised is of little consequence (hence the reason it is called the public key, it can be made public without fear of revealing the private key).

Now, how do we do it?

ColdFusion has some awesome built in cryptography functions. Encrypt(), Decrypt(), EncryptBinary() and DecryptBinary() are great tools that we should all learn how to use. But ColdFusion's cryptography functions only support symmetric cryptography. If we want to use asymmetric crypto, we need to turn elsewhere. In my experimentation, I turned to Java, of course, and the Java Cryptography Extensions(JCE) to do the asymmetric encryption, but JCE does not include a provider to generate asymmetric cryptographic keys, so for that I turned to the Bouncy Castle Crypto API.

According to the Bouncy Castle website:

The Bouncy Castle Crypto package is a Java implementation of cryptographic algorithms, it was developed by the Legion of the Bouncy Castle - with a little help!

The package is organised so that it contains a light-weight API suitable for use in any environment with the additional infrastructure to conform the algorithms to the JCE framework.

With the help of some Googling, Java examples, and experimentation, I came up with the following working example in ColdFusion. Let's walk through it.

The Code

First, we need to add the Bouncy Castle jar file to our ColdFusion installation. You can do this by placing the Bouncy Castle .jar file (I used bcprov-jdk16-145.jar) into your ColdFusion's lib directory. Then restart ColdFusion.

NOTE: You could also use Mark's JavaLoader instead of placing the jar into the lib directly.

Once you have Bouncy Castle in place, we need to get at it using ColdFusion's fantastic ability to work with Java.

NOTE: My skillz with Java are "meh". Please feel free to correct my usage. I also did not architect a great solution here. This is just a bunch of procedural code from a single CFM file.

In the above code, we first get an instance of the KeyPairGenerator provider from Bouncy Castle, then we request an instance of the generator for the RSA algorithm. RSA is a common encryption algorithm that you can read more about here.

Once we have an instance of the KeyPairGenerator we need to initialize it by telling it how large a key we want and we need to pass in a Pseudo-Random Number Generator (PRNG). Since ColdFusion has SecureRandom built in, I used that.

I chose a key length of 2048 bits. This is probably the minimum you should consider using. Typical key lengths are 1024, 2048, and 4096. 1024 is still an acceptable size for now, but many experts agree that it will not be acceptable for too much longer and recommend going with at least 2048.

You might ask, "why not just do 4096 and call it awesome?", and I would answer you with some charts. This chart shows the execution time of generating a public and private key and then performing a single encryption and decryption operation of a 117 character string on my development machine (Intel Dual-Core with WinXP 32-bit).

Key Length		Speed in ms
1024	500-600
2048	1500-2500
4096	8000-20000

As you can see, the computation time with the larger key sizes can get ridiculous. Asymmetric encryption is EXTREMELY processor intense. Keep that in mind before you decide to implement it as a solution. Symmetric encryption is SMOKIN' fast compared to it.

Note that the times above do include creation of the Public and Private keys. That seems to be the most processor intensive part. If you use pre-generated keys, then the times for JUST encryption and decryption are much shorter.

Key Length		Speed in ms
1024	16
2048	30-32
4096	230-250

The 4096-bit key is still considerably slower than the other two. Consider the number of concurrent operations before you make your decision. If the encryption/decryption process does not happen very often, then perhaps 4096-bit key lengths will work for you. Also keep in mind how much data you are encrypting/decrypting.

After initializing my generator, I then requested that it generate a key pair. A key pair consists of a public key and a private key. These two keys are Java objects of type com.rsa.jsafe.provider.JSA_RSAPublicKey and com.rsa.jsafe.provider.JSA_RSAPrivateKey respectively.

Now, one thing I have not yet looked into is storing these keys. Once they are generated they need to be stored in a persistent (and safe way) for their entire cryptoperiod. I am not going to get heavily into key management here, but somehow any one who implements this needs to figure out how to store these keys and make them available for use on the respective machines. From a brief search it looks like you should be able to store them as Base64 encoded strings, if that is the case, you should be able to put them where ever you need to (database, text file, etc) keeping in mind that the PRIVATE KEY MUST BE SECURELY STORED.

Remember, ONLY the public key should be stored on the machine that is doing the encryption. In the example above, that would be our database/web server. The credit card processing server can have both keys, but the important one for it to have is the private key.

Also, remember that the safety of the key storage is imperative. Not only do you need to safeguard the private key from being stolen, but you also need to safeguard it from being lost. If you lose that key, you'll NEVER get your data back out.

One last thing on key management. Look into proper key management procedures, like key rotation, cryptoperiods, destruction, etc. etc. It's complicated and difficult, but important.

Using the public and private keys

Once you have generated and stored the keys you can now use them. Using them is actually quite simple. In the examples below, I am assuming that the keys have been loaded as the Java objects mention above into the ColdFusion application's APPLICATION scope.

Encrypting Data

Here is a possible function you could use to encrypt a string:

Now in theory, you should be able to encrypt anything. A string, number, object, file, etc. But they need to be converted to bytes first.

Also keep in mind that, at least with the RSA algorithm (I am not sure with other Asymmetric algorithms), that you can only encrypt messages that are N bytes smaller than the key length. N changes based on the padding used. For example, with the 2048-bit key that we used (using the default padding) we can only encrypt 245 bytes of data (2048 bits = 256 bytes and then 11 bytes are used for padding leaving 245 bytes). For a 1024 bit key you can encode 117 bytes and with a 4096-bit key you can encrypt 501 bytes.

If you need to encrypt more data than you have room for, you'll need to break up the data into smaller blocks and encrypt them separately. I do not have time to provide a sample of that right now. Keep in mind the slower speed of encryption and decryption when dealing with asymmetric crypto. They will get much slower if you must iterate over blocks of data and perform multiple encryption and decryption processes.

Decrypting Data

Decryption of the data is essentially a reversal of the encryption.

In this case, we pass in the encrypted bytes and the private key and set a Cipher object to DECRYPT mode. The decryption process then returns decrypted bytes that we can convert back to a string using ColdFusion's toString() function.

Conclusion

This experiment was a lot of fun, and I learned a lot by doing it. I hope it can benefit some people out there that may have needed this functionality. Again, if you have corrections or can add to this post in anyway, please speak up.