How to secure a Mifare key in a midlet?

[microchi]

Dear All

We try to use a midlet to read external Mifare tag.
We use the interface MFDataArea's read method to read block data.
When we use the method, it's need a key parameter.
The key parameter is plain byte array in our midlet.

How can we to secure the key byte array?
Does it's work if we put it in secure element?
The document of SDK say "If null then the device's default keys are used.".
Can we change default keys? Does it secure?

Please give we a hand. Thank you~

Timothy

[bvandewalle]

Hello,

I have exactly the same issue for my application.

Actually, If you want to read a card with a special key, at some point the phone needs to know that key. For me there are three options :

1) Put the key in clear in the Midlet code.
2) Put the key in the Secure Element.
3) Receive the key from the network after a remote authentication.

Obvisouly Option 1 is totally not secure,
Option 2 seems also not secure, since you also need to access the secure element to get the key, so you will need to encode in the midlet the key to the secure element, and it is then easy to retrieve the Mifare key.
Option 3 seems a little bit more secure, even if it would be easy to hack the phone, and retrieve the key, once received from the network.

So IMHO, there is no secure options, but the third one is the best one ( but then you have to access the network, and a remote server ).

Someone else has any suggestion for this issue ?

[geri-m]

Hello,

I have exactly the same issue for my application.

Actually, If you want to read a card with a special key, at some point the phone needs to know that key. For me there are three options :

1) Put the key in clear in the Midlet code.
2) Put the key in the Secure Element.
3) Receive the key from the network after a remote authentication.

Obvisouly Option 1 is totally not secure,
Option 2 seems also not secure, since you also need to access the secure element to get the key, so you will need to encode in the midlet the key to the secure element, and it is then easy to retrieve the Mifare key.
Option 3 seems a little bit more secure, even if it would be easy to hack the phone, and retrieve the key, once received from the network.

So IMHO, there is no secure options, but the third one is the best one ( but then you have to access the network, and a remote server ).

Someone else has any suggestion for this issue ?

I agree, that option '#3' is the best one. (but it does not allow you to do all the stuff in real time, as you always need to talk to your server ... you also may run into timing issues, as Mifare is quite sensive in this regard.

You could also store the Mifare-Key in the Midlet encrypted with a PIn, that needs to be entered to read a tag and the decrypted it on the file. The Key then is "plain-in-RAM", with is still unsecure. But you don't need the server then.

best, geri-m

[microchi]

I agree, that option '#3' is the best one. (but it does not allow you to do all the stuff in real time, as you always need to talk to your server ... you also may run into timing issues, as Mifare is quite sensive in this regard.

You could also store the Mifare-Key in the Midlet encrypted with a PIn, that needs to be entered to read a tag and the decrypted it on the file. The Key then is "plain-in-RAM", with is still unsecure. But you don't need the server then.

best, geri-m

Neither option #3 nor encrypted a key in midlet is secure.
Because midlets in a cell phone are easy to be copied and be decompiled.
Hackers can [easy] clone the way to get the key.

Dose Nokia 6212 use NXP PN532 chipset for NFC function?
Dose PN532 have secure non-volatile internal key memory like RC531?
Is there a way to set the key memory form a applet in Secrue Elemnet?

Thank you for your attention.

Timothy

[geri-m]

Neither option #3 nor encrypted a key in midlet is secure.
Because midlets in a cell phone are easy to be copied and be decompiled.
Hackers can [easy] clone the way to get the key.

Dose Nokia 6212 use NXP PN532 chipset for NFC function?
Dose PN532 have secure non-volatile internal key memory like RC531?
Is there a way to set the key memory form a applet in Secrue Elemnet?

Thank you for your attention.

Timothy

agree - transfering the key to the midlet is an issue, as it stays in RAM. And the proxy functionallity doesn't work either, as the cipher of the PN512 has to be used to access the mifare chip ... - double damm ;-) => use java Card instead.

It actually comes with a PN512. What do you actually mean by "key memory"?

best, geri-m

[microchi]

agree - transfering the key to the midlet is an issue, as it stays in RAM. And the proxy functionallity doesn't work either, as the cipher of the PN512 has to be used to access the mifare chip ... - double damm ;-) => use java Card instead.

It actually comes with a PN512. What do you actually mean by "key memory"?

best, geri-m

When we use a RC531 Mifare reader.
The reader's API often offer some commands that can load a key into RC531's key memory.
The key memory is non-readable, non-volatile, and it only work for card authentication.
(see 4.1.1 in http://www.nxp.com/acrobat_download2.../SFS067332.pdf)
If read has a SAM (Security Access Module) mechanism,
we can design a solution which use SAM loading a key into key memory.
The solution can protect the key and avoid hacking.

So Secure Element in 6212 can be the role of SAM.
If there is a way which useing an applet in secure element to load a key into key momory of PN512 in 6212.
We can protect the Mifare key and avoid hacking.

Is there a way to load a key into key memory form a applet in Secrue Elemnet?
Thank You

Timothy

[geri-m]

When we use a RC531 Mifare reader.
The reader's API often offer some commands that can load a key into RC531's key memory.
The key memory is non-readable, non-volatile, and it only work for card authentication.
(see 4.1.1 in http://www.nxp.com/acrobat_download2.../SFS067332.pdf)
If read has a SAM (Security Access Module) mechanism,
we can design a solution which use SAM loading a key into key memory.
The solution can protect the key and avoid hacking.

So Secure Element in 6212 can be the role of SAM.
If there is a way which useing an applet in secure element to load a key into key momory of PN512 in 6212.
We can protect the Mifare key and avoid hacking.

Is there a way to load a key into key memory form a applet in Secrue Elemnet?
Thank You

Timothy

no, that's not feasable for the current point of view. you would need "some" applcation to commicate the key between the SAM/secure element and the reader-ic. on the phone you would require a midlet to do so. => we have the "old" situtation. the key then is at some point in unprotected memory and there is the possibilty of attacking the system.

best, geri-m

[bvandewalle]

OK, this is well what I thought, there is no way to secure the key needed to access a Mifare card.

So for my application, I decided to let everyone write in the Mifare card (with the NDEF default keys)...
Another solution would be to ask a password to the user, and the remote server would only give the key if the password is correct. So we know that the key is stored in a "legit" phone.
Or another solution would be to use a key derived from a password ( with a hash function ? ) that the user provides...

In a second stage , I plan to use a javacard that will allow a remote authentication or something like that...

[juancarlosr]

Hi all,

So this implies that using an NFC phone as POS device is totally unsecurea and unpractical right? Nobody would do it for other than a pilot or demo?

I'm trying to think of a good way to secure this, but you are right, all of them seem to have a flaw. Have you guys thought of any intermediate solutions?

Thanks!!

[le sage]

Wait...
I think it depends on your scenario. How much do you need the key to be secured ? Is it for banking operations, ticketing operations, life depending operations ?
I agree option 1 is bad.
I don't have anything against option 2 & 3.
As for option 4 (encrypting the key in the MIDlet using a PIN as another key), I thing it's bad : the key will be brute-forced (remember 6 digits PINs are 20 bits of entropy).
If the key is loaded in the cellphone's RAM (I guess it has to at some point), then normally you should be able to erase it if it's a byte array.
I don't really agree on the fact that if the key is in the volatile RAM of the cellphone, then it is unsecure. I think for most applications this is just fine.
What do you think ?

[juancarlosr]

Hi Le Sage, yes it is something very important. It is for processing payments of tickets or fares, a case where if the cell phone gets lost, that'd be a tremendous issue.

Option 3 for me, has a big drawback and it's connectivity. Sometimes it would take more than 5 seconds to plug in to the network, and therefore it would be non practical.

As for option 4, I did not understand your position, you started saying it's bad, but ended up saying its good, so is it fine in the end?

I'm still trying to figure out the best way to do it (quick and secure)

Thank you!

[le sage]

Hey juancarlosr,
We should really make the different between the different memories used. A Java application can store data that can be retrived later (e.g. at a later restart) using the file system, or a local database (the RMS). This is persistent storage.
When an application is launched, some info is stored (temporarily) in the memory, & we can expect (roughly) that this information is deleted when the application is stopped. This is temporary memory.
I think options 2 & 3 are just fine for your problem, but you might have some reason to not want to use them.
Option 4 is definitely bad, because then it might be subject to a brute force attack.
So key may be used in the volatile memory, but should not be stored in persistent storage. Does it explain my previous message in a better way ?
My answer is : option 2 or 3. You could use option 4 only if you're sure that the password can't be brute forced, which in real life is impossible to assure. So option 4 is bad (according to me).

[mroland]

Hallo,

So this implies that using an NFC phone as POS device is totally unsecurea and unpractical right?

No, this only implies that accessing MIFARE Classic cards (and the internal MIFARE area of the secure element) through the phone is potentially unsafe. Whenever you want to access MIFARE sectors through a MIDlet you'll need to store the plain key in the phone's memory.

In my opinion, regarding security, there is hardly any difference between storing the MIFARE Classic keys in dedicated key memory or in the phone's memory. While MIFARE Classic is still good/well suited for many applications, the security mechanisms have been compomised. Consequently, an adversary could simply comute the keys by listening to the RF transmission between card and reader. No reverse engineering of MIDlets is needed for this.

Another (and more secure) option would be an APDU-based payment card (i.e. the JavaCard on the internal secure element or an external ISO 14443-4 smartcard). This way you could dirctly transmit (encrypted) APDUs between the card and a server. Therefore, no keys need to be stored in the phone's memory.

br,
Michael

[juancarlosr]

Hello Mroland, LeSage,

Those are really very interesting and helpful positions. I think this thread is very interesting. With your ideas, I can say I have a more critical point of view of this situation. One last thing, could any of you share some code on option 3 (storing keys in SE and accesing it). I'm new to SE access and that would save me a lot of time.

I will keep you posted on my advance.

Thanks a lot!

[alex782k]

I bumped into the same problem and unfortunately went to the same conclusion.
So basically there is NO way to secure a mifare card using an NFC phone, right ?


And what difference does it make if I'm using a Mifare card or a JavaCard to hold the data ? Because in both cases I'm gonna have to use a key to authenticate myself, right ? And then I'll bump into the issue of securing a key in the MIDlet...am I right ?