encypting data to be sent using HTTP (MIDP 1.0)

[dihex]

Hi

I am developing a number of applications using J2ME. They run on mobile phones and need to be able to send data to a server. I need to encrypt this data as it contains personal information about the user. I cant use HTTPS because some of the applications use MIDP 1.0 and only support HTTP.

So I want to encrypt the data myself and I was wondering if you could help me with my approach and answer some questions...

I think the best way is to use RSA public/private keys in combination with a symmetric encrypting algorithm. So the mobile will have the public key part and the server will have the private key. The data will be encrypted using a symmetric algorithm. The key used in the encryption will then be encrypted using the public key. Both the encrypted key and the encrypted data will then be sent to the server. The server uses its private key to decrypt the key and then use the key to decrypt the data.

How does that sound? I will be using Bouncy Castle crypto. What is the best way to generate a public/private key pair? I then need to somehow include the public key with the application. Should I randomly generate the symmetric key myself?

Also what algorithm would you suggest for encrypting the data. Remember that it is on a resource constrained mobile device.

If you have any other comments I would like to hear them. Thanks for your time.

[moenglan]

I think the best way is to use RSA public/private keys in combination with a symmetric encrypting algorithm. So the mobile will have the public key part and the server will have the private key. The data will be encrypted using a symmetric algorithm. The key used in the encryption will then be encrypted using the public key. Both the encrypted key and the encrypted data will then be sent to the server. The server uses its private key to decrypt the key and then use the key to decrypt the data.

How does that sound?

This sounds perfectly reasonable; it's a standard technique. The term for the symmetric key used here is "session key." You're establishing a session key that only the server and client know by sending it across the wire(less) encrypted for the server's eyes only, then performing all encryption operations on data using your symmetric algorithm with the session key.

I will be using Bouncy Castle crypto. What is the best way to generate a public/private key pair? I then need to somehow include the public key with the application. Should I randomly generate the symmetric key myself?

You probably want to use RSA as your asymmetric key algorithm. The key pair can be generated using org.bouncycastle.crypto.generators.RSAKeyPairGenerator. To include the key with the app, just store it in the JAD file and read it using MIDlet.getAppProperty(). Obviously you'll have to encode it as a string (e.g., base64 or hex, look in org.bouncycastle.util.encoders). Yes, the session key should be randomly generated. You'll need to use bouncycastle's implementation of java.security.SecureRandom, which means you'll also need to use an obfuscator (since the Java doesn't like you providing your own version of anything in java.security).

Also what algorithm would you suggest for encrypting the data. Remember that it is on a resource constrained mobile device.

AES is a good choice; there are 3 versions of it provided by bouncycastle to fit your needs. If app size is an issue, consider AESLightEngine; if you want speed, there's AESFastEngine. Regular old AESEngine splits the difference. Bouncycastle provides plenty of choices though: AES, Blowfish, IDEA, Twofish, Serpent. If performance and/or size is a big concern, I'd suggest that you try several and compare.

[dihex]

Hey moenglan, thanks for the reply. It is very useful, glad to know I'm on the right track. What do you think of the following approach instead?

How about just using a symmetric algorithm to increase speed and do away with the public and private keys? The issue as I see it is that both client and server need to know the same key. Both already know the username and password of the user. A unique key could be generated by combining the username+password with a session parameter. The parameter could be created by a random number and a timestamp and could then be transmitted in a HTTP header. The client could then re-create the key used in the encryption by combining their username+password with the transmitted parameter.

This means that a different key is used every single time and it should be quicker because there is no extra encryption to hide the key.

[moenglan]

How about just using a symmetric algorithm to increase speed and do away with the public and private keys? The issue as I see it is that both client and server need to know the same key. Both already know the username and password of the user. A unique key could be generated by combining the username+password with a session parameter. The parameter could be created by a random number and a timestamp and could then be transmitted in a HTTP header. The client could then re-create the key used in the encryption by combining their username+password with the transmitted parameter.

This means that a different key is used every single time and it should be quicker because there is no extra encryption to hide the key.

I see two problems with the scheme you propose:

1. It requires the server and client to maintain some shared state (username and password). Depending on your app and its scalability requirements, this may be an issue. Since you talk about username/password I assume you're authenticating both parties (not just the server), so the server would need some kind of state anyway, so this is probably not a major problem.

2. This is the big problem: it's vulnerable to dictionary attacks. I only have to guess your password (and username, if that's not public information) in order to be able to read your messages and/or carry on conversations with the server where it thinks I'm you. These kinds of attacks are surprisingly easy, since people tend to pick terrible passwords. In the RSA-encrypted session key scheme, this is a non-issue.

Just what exactly are your speed requirements? If you design your protocol right, the session key exchange only happens once per session; encrypting a small amount of data (at most 192 bits for an AES key) with RSA is not that expensive on mobile devices -- definitely less than 100ms using Bouncycastle. Tests I did in the past showed RSA signing (which uses the private exponent) taking ~90ms on a 123Mhz ARM processor device (N6230); I suspect that public-exponent operations may be significantly faster, depending on how you select the public exponent (e.g., if it's simply the value "3").

[dihex]

I was just throwing that idea out to see what you thought. I do think that the first way is better. My main concern is speed but I reckon the best way is to see how long it actually takes on the devices. Am I right in thinking that it is much quicker to encrypt the data using a symmetric algorithm and then encrypt the key with a asymmetric algorithm rather than encrypting the whole lot using the asymmetric algorithm?

There won't be constant communication between user and server, the user is simply uploading a chunk of data everyday and also receiving a download.

Also, could the encrypted key for the transmission be sent in one of the HTTP headers?

I appreciate the time you are taking to reply to me

[moenglan]

I was just throwing that idea out to see what you thought. I do think that the first way is better. My main concern is speed but I reckon the best way is to see how long it actually takes on the devices. Am I right in thinking that it is much quicker to encrypt the data using a symmetric algorithm and then encrypt the key with a asymmetric algorithm rather than encrypting the whole lot using the asymmetric algorithm?

Yes, there is a significant speed advantage to using a symmetric algorithm on the lion's share of the data being transmitted. As long as you're transmitting a nontrivial amount of data (i.e., more than a few bytes), it's faster to use session keys than just using asymmetric encryption for the whole lot.

Also, could the encrypted key for the transmission be sent in one of the HTTP headers?

Well, there's no standard header for storing the session key. You may be able to sneak it in, but I don't see the advantage.

[dihex]

Hi

My implementation is coming along nicely, I'm using the standard AES algorithm for the bulk of the encryption. I am currently generating the RSA keys to encrypt/decrypt the session key. I can get them in the form:

        RSAKeyParameters privateKey = (RSAPrivateCrtKeyParameters) keyPair.getPrivate();
        RSAKeyParameters publicKey = (RSAKeyParameters) keyPair.getPublic();

What is the best way to save these to file? Should I just convert them to a byte array and then use base64 to convert them to strings. Or should I break them up into their parameters and save them one by one? I'm using bouncy castle API and there doesnt seem to be a key serialization API.

thanks

[moenglan]

What is the best way to save these to file? Should I just convert them to a byte array and then use base64 to convert them to strings. Or should I break them up into their parameters and save them one by one? I'm using bouncy castle API and there doesnt seem to be a key serialization API.

No, there is no key serialization API. The best way is to save their components (i.e., the arguments to their constructors) one by one. This is especially true of the private key, as the "extra" stuff (dP, dQ, qInv, p, q) are what allows the BC implementation to use chinese remaindering to speed up encryption. If you're using RMS (javax.microedition.rms), you don't need to convert them to strings, as records are just byte arrays (so use BigInteger.toByteArray()).