Security /w Bouncycastle in J2ME

[Svend Rost]

Hi all..

I hope you guys cna give me some feedback on the following:

Im working on an mobile app. which has to transfer secure information with
a server.

In order to make the post less abstract, consider the following: Students
will logon to a server via their mobile phone with a pw/username (e.g.
social security number) and if succesfull, receive a number of questions
(e.g. multiple choice) which they'll answer and send back to the server.

- The app. should work on MIDP 2 as well as MIDP 1 devices, which might
mean that I have to make two versions of the app.
- The app. will (most likely) be downloadable from various websites, which
makes the encoding of unique keys hard (or impossible?).
- Information should be secure both from and to the server.

I am considering the following:

For MIDP2 devices, I'll use a HttpsConnection instread of an HttpConnection
which should make the transaction secure, because of the SSL protocol.

For MIDP1 devices, I'll logon with the help of a digest (e.g. SHA1 from the
bouncycastle framework) and the let the rest of the communication be done
with another bouncycastle crypt. algorithm.

Onwards to my questions:
1) Is it correct, that the communication will be 100% secure because im using
SSL, and the information therefor is encrypted ?

2) Does anyone have any suggestions on suitable algorithms for the MIDP1
devices. As mentioned, since the app will be downloadable from website
it's hard if not impossible for me to generate a unique key.

Any advice, pointers ect. will be appreciated.

/Svend Rost

edit: Forgot a word..
[ May 27, 2005: Message edited by: Svend Rost ]

[Yuri Magrisso]

What do you understand by "unique key" and later "unique"?

[Svend Rost]

Anyone?

[Andrew Moores]

Svend, I'm no expert on MIDP but I have built an application that transfers sensitive data over the Internet.

A connection using https is not 100% secure (nothing is 100% secure). Using ssl the following happens: your data is encrypted, then sent over the internet, then decrypted and stored locally on the recipient. (This is a very simple view). The data is 'safe' during transmission but may not be safe on the source or recipient machine. If someone snoops your data during transmission they may not be able to read it straight away but over time they may be able to crack it. Your hope is that by the time someone cracks your encryption the data is useless or that it is of little value when measured against the cost of the effort of cracking the code.

The second question you ask needs some clarifying (I assume that MIDP1 precludes the use of https (ssl)):

Why do you need a unique key?
Your plan to allow a Java app to be downloaded to the phone and then used to connect back to your server and send data in an encrypted form?
Anyone will be able to download this application as it will be available on a web site?
You need to gain confidence that the person connecting to your server is really who they say they are and then to encrypt their data when transmitted?

[Svend Rost]

Thanks for replying Andrew.

As far as I can understand from your post, "im good" with SSL alone. It was
my hope, but I wasn't sure if further security was needed.

Onwards to your questions:

Yes, MIDP1 doesn't support HttpsConnection's, only HttpConnection.

Why do you need a unique key?

I might have to brush up on my crypto knowleadge, but I was under the
impression, that you need a unique key, k1, located on both sender and the
receiver in order to send encrypted data.

Your plan to allow a Java app to be downloaded to the phone and then used to connect back to your server and send data in an encrypted form?

Yes, the app. will be downloadable via the net. You then start the app.
and get access to the server. It's possible to send/receive data from the
server once the connection has been established.

Anyone will be able to download this application as it will be available on a web site?

Yes, from several websites.

You need to gain confidence that the person connecting to your server is really who they say they are and then to encrypt their data when transmitted?

Yes, first you have to logon and if succesfull the user will receive some
data. Obviously the transmission of username/pw. has to be secure. Furthermore
once the user has logged on, there will be some data communication which
also has to be secure.

/Svend Rost

[Andrew Moores]

Using you https connection will allow data to be encrypted while it is sent. It will not give you assurance that the data is valid or that it comes from a trusted person. On the server you will not be able to associate the data to a known source by any means other than the user name and password, provided after the https connection has been established (presumably you will use http authentication for this).

I think the solution for MIDP1 that you are looking for is something like the following:

1. Generate an asymmetric key pair on the server.
2. Include this public key in the phone software (the same key will be used by all phones).
3. When you establish connections from the phone create a new symmetric key on the phone and RSA encrypt it using the servers public key.
4. The server can then decrypt the symetric key using its private key and this key can then be used to encrypt data in both directions.

You then need to work out a sequence for sending the username and password from the phone to the server, the server responds with the questions and the answers follow after that.

The key will only be good for the life of the connection.

There are a number of drawbacks with this solution but it may suffice for what you are attempting.

Let me know if you need more information.

--Andrew