Encryption Question - Java, VB, Key sharing

zooo

Hello,

I have java app running a version of the TEA (Tiny Encryption Algorithm) and a VB version of the same TEA on a Server.

The two apps encrypt and decrypt data using a 128 bit Key.

The problem is: The key is stored in the Java App and must be stored on the Server. i.e.: The Same key is used to encrypt and decrypt the data.
To update the key i have to update the Java App on the client.

Is there a way I can send a portion of the Key along with the encrypted message, ( This means that the key can be changed regularly on the Server), perform some function on this key portion and a private key portion on the Java App.

Thanks,

zooo

Capt'n Midnight

zebedee is a handy app
- one use is the command line options -p and -P to generate private and pubic keys..

It's the old locked box problem - but since each end of the link can now generate it's own keys you can use them to copy the keys..

Trivial:
you could send the new keys encrypted under the old key
you could update the java ap via a 128 bit encrypted VPN...
you could use encrypted zip files to copy the app over ...

zooo

Thanks for that.

However it's actually more difficult. The Java App is on a phone. The updates happen over gprs using http ( because MIDP 2.0; that supports https has not been released onto any pnones yet).

How about if I keep a private key and a partial key on the Java App. Send a partail key thats encrypted from the server to the handset. Decrypt it with the Java Apps private key, Add it to the Java Apps partail key and encrypt the rest of the data in the session with the new key.

It still doesn't get around the problem of someone getting the Handsets private and partial key. Mind you once it's on the handset as a midlet i don't think they should be able to.

Kev

what about Diffie-Hellman

but why do you want to update the keys.

zooo

The keys need to be updated regularly, could be once a day, once a week, to ensure that the key has not been compromised.

The Diffie-Hellman process is prone to a man in the middle attack. The Java app could be talking to something pretending to be the server, and the server talking to something pretending to be the java app.

Capt'n Midnight

Key fobs that generate their own numbers - synched to the server - expensive (€70each + dedicated server needed too) but should bypass the man in the middle

GPRS should allow you to ID the physical location of the phone - this might be of some use.

Man in the Middle attact - you are saying that some can eaves drop on the phone - better make sure the beeps on key presses are turned off if you are that paranoid

You could also use biometrics - but they are easy to beat - and your phone don't support them yet (there's a neat way of stopping mobile phone theft...)

The other option is to had out passwords / tokens on a different system - eg: give them a pager ... get them to download passwords via the serial cable / infrared (eg: as phone book entries)


But what to do if a phone is stolen ????

flav0rflav

I'd suggets you start reading, this is a very common problem with a multitude of designed, implemented and tested solutions. Is this a commercial product!??

As one example look at IKE - Internet Key Exchange, exactly designed to regularly (and obviously securely) update key pairs between peers. It uses Diffie-Hellman after first doing authentication - to aviod man in the middle.

zooo

Thanks flavOrflav,

However what you don't understand is that MIDP midlets for Mobile Phones is very limited.

Anyone building MIDP applications are well aware of its current limitations.

1. ...the lack of floating-point number support, HTTP-only communications, and the limited UI components, no security API is currently included in the MID Profile. (ie no VPN connections, no sockets, no datagrams, no Https etc)

2. The Java App has to be compiled into a jar file which is downloaded OTA.

3. If the key is hardcode into the Jar then someone could intercept the jar file and extract the key.

4. It doesn't allow the use of SSL or certificates

Developers at Sun had created KSSL, a "small-footprint, client-side-only implementation of SSL v3.0 for handheld and wireless devices." but it's not available any more.

And flavOrflav, As everyone knows, that although J2ME great for mobile application development, its current capabilities, particularly in the J2ME MIDP, leave a lot to be desired when it comes to security.

MIDP version 2.0 addresses these problems with it's inclusion of HTTPS.

However none of the current phones implement MIDP 2.0. It was meant to be the third quarter of this year.

The most likely options are
1. to wait for MIDP 2.0 to be included by the phone manufacturers (which will probably be next year)

2. design a smaller version of SSL in Java, that will run on the mobile.

3. Transfer the Java Midlet using https over the internet, get the user to download the midlet to their machine, and then get them to transfer the midlet to their phone via a serial cable.

So as you can see I have done a lot of reading and would appreciate good constructive advice,

Thanks again,

zoo

Talliesin

Originally posted by Capt'n Midnight
Man in the Middle attact - you are saying that some can eaves drop on the phone - better make sure the beeps on key presses are turned off if you are that paranoid

Why bother encrypting at all if you don't think someone might be able to intercept. It's a lot easier than infering useful information by listening to key-press beeps.

zooo

Yea,

but remember the phone is always close to the person, the likely hood of someone getting the data of the phone is small.

Its the transfer OTA to the phone that is insecure. ( the jar file contains the key)

And as regards paranoia, if your MIDP involves passing around credit card numbers, or sensitive data then you should be concerned,

zooo

Kev

so why not do what you first suggested and keep a private key for key exchange, if you're worried about a man in the middle attack wouldn't any scheme be vulnerable unless a key was initially exchanged using an out of band path.

zooo

As you say,

I should use an out of band path to get the app onto the phone. The jar will never be compromised OTA then. Or else get the user to input a key at the setup stage, which is then stored in RMS on the device.

Just thought there might be some algo. for partial key exchange that was more secure than Diffie-Hellman.

Anyway,

Thanks for all the help,

zooo

flav0rflav

I presume you can get access to the SIM data? You can use this for authentication, then you can use DH.

Embedding the key in the app also means everyone has the same key. You only need one lapse and ...

zooo

No MIDP 1.0 won't allow access to any of the phone or sim data. It's a closed Sandbox syatem.

Also if a midlet (java app on the phone) writes data to the phone, this data can only be accessed by the midlet that wrote it.

flav0rflav

Hmm, that's unfortunate. You really want something unique on each phone so that it isn't the same key everywhere.

Securid works on the basis of pseudo-random number generators, in sync. Maybe that's an avenue worth exploring?

zooo

Thanks for that

I'll have a look into how securid works.

zooo

Another solution might be Session-key Encryption
using both secret key and public key encryption together to get the best of two worlds.

i.e.

When the app is started for the first time the user is asked to input a pin, from which the 128 bit private key is generated.

The secret key encrypts the message using TEA.
The secret key itself is encrypted using a public key of the server, using RSA.

or maybe

A One-Time Pads
Which It involves creating a completely random key that is exactly as long as the message, The key must be used once, and must be completely random. The only thing is that Secure communication beforehand for one-time pads needed. (Back to the drawing board)

or

Elliptic Curve Cryptography (ECC)
Different mathematical basis from RSA. It is faster and more secure than RSA
(Don't know if the phone can handle this)

Capt'n Midnight

matrix multiplication is also a one way operation

individual one time pads are very good if you can trust your users - like I suggested hide them in the phone book

Might be cheaper giving them a second phone, on a different network - and don't forget to use call back (from a different number to the one they dialled in.)

You could put the intelligence into a PDA too...

[edit - major typo]
You could put the intelligence into a PDC too... - eh ? yeah right ...

Gavin

What is the issue as regards generating an rsa keypair on the mobile phone ?

If the j2me doesn't support it, you could just code the algorithm yourself, it is actually quite simple.

The one time pad is a possibility, but to use it effectively, you will of course need to have the pad on both client and server, or if not the whole pad, at least some shared secret to seed a rng to provide the one time pad data. But you state that already.

Using a 4 digit number to generate a 128 key means you are effectively using 4 bit entropy.. ( possibly a bit more than 4 actually, but still easily breakable )correct me if i am wrong. You won't get the security of 128 bits.

The solution really is RSA. There's no need to pay attention to ecc, as it is simply another method of doing the same thing, unless the phone simply can't handle the number crunching required.

Diffie hellman alternatives are speke, which again you would probably have to implement yourself. Or for a faster alternative to speke

ftp://ftp.compapp.dcu.ie/pub/crypto/paper12.ps