MCU for NFC transportation payment

[Jeroen3]

You store keys/settings in the backup ram. Because when tampered, they get erased.

[dizgah]

You store keys/settings in the backup ram. Because when tampered, they get erased.

Good approach(i think usually designers do this way),but if attacker can pass from tamper & make them ineffective(in the first one he learn tamper places & for second one he can them ineffective),then he can access to the external Ram & stole keys.whats the solution?

[nctnico]

I think Jeroen3 means internal backup SRAM. Some microcontrollers have an RTC (real-time-clock) which runs from a battery; this RTC usually has some battery powered SRAM which can be used to store settings. Still, people could erase the firmware and load new firmware to read the backup SRAM.

[ez24]

Since you're in Iran. Did you research if you can actually buy these products?

I think the OP said in so many words "where there is a will, there is a way".  Plus aren't the restrictions being lifted?  Maybe the OP is just getting ready for the big day.

Is this for a bus system, maybe a suburban system or inter-city system?  Maybe he will send us a sample card     Or at least a system map.

FYI  I spent one day (about 20 hours) in Tehran and met many nice people and had a good time.  Went to some hillside resort along a stream with some university students and my guess is it was to the north of the city.  I hope they are still alive, a bunch of really nice guys, they took me on a tour.  I cannot remember how I got around but since I usually hitchhiked or used the buses, that is what I assumed.  Dammed memory.  This was in the days of the Shah.

[dizgah]

thank nctnico for correcting me,
dear ez24 :
yest i want implementing something like that,in fact in Tehran & other Iran's metropolitan, RFID-based electronic ticketing is mainly used,but here in Guilan(one of the northern province) many virginal applications for this technology can be found.
Iran is still just as good as you remember(People in all governments are the same).
Best regards.

[Jeroen3]

, people could erase the firmware and load new firmware to read the backup SRAM.

No you can't. Crp will erase all memories when you want to flash new firmware. Unless you can decap and disable crp while preventing tamper.

But. Is it neccesary to have such top secret keys distributed? Wouldn't an public key system be as effective?

[nctnico]

, people could erase the firmware and load new firmware to read the backup SRAM.

No you can't. Crp will erase all memories when you want to flash new firmware. Unless you can decap and disable crp while preventing tamper.

Are you sure about that? It doesn't say in the documentation I have. In that it says only the contents of the RAM used by the flash routines may be lost during a reset.

[dizgah]

, people could erase the firmware and load new firmware to read the backup SRAM.

No you can't. Crp will erase all memories when you want to flash new firmware. Unless you can decap and disable crp while preventing tamper.

But. Is it neccesary to have such top secret keys distributed? Wouldn't an public key system be as effective?

Can youexplain more? key distributing is so important issue ,was in my last page of security tips,but i cant know how we can implement public key algourithm for this area,as you know we have some reader(PCD)     & some dozens of tags(PICC) that each reader must able to read & write each tags

[Jeroen3]

Public key isn't really suitable for rfid tags I think.
In the netherlands we have mifare technology chips for public transport, the encryption used was cracked within a few months. The only thing you can do is have the tags expire when the brute force time is over.
Or make the system better in checking using a different connection. Such as: Ask the server if the card is not fake.

You should know that car fobs are also cracked, yet only the leaky implementations are exploited.

[dizgah]

Public key isn't really suitable for rfid tags I think.
In the netherlands we have mifare technology chips for public transport, the encryption used was cracked within a few months. The only thing you can do is have the tags expire when the brute force time is over.
Or make the system better in checking using a different connection. Such as: Ask the server if the card is not fake.

You should know that car fobs are also cracked, yet only the leaky implementations are exploited.

Internet checking needs a lot of time delay and therefor is not suitable for electronic purse applications 
as i know current transportation applications used mifare desfire ev1 (integrated with aes engine) can you give me a link of that hack please?
--------
& about key distribution i am very concern to read your suggestions.


? ?? SM-G316HU? ?? ?? Tapatalk

[Jeroen3]

They used Mifare classic. The ones unsafe prior to release.
http://www.bright.nl/uitlegparty-hack-je-ov-chipkaart
They've changed cards a few times iirc correctly, but they are valid for 5 years.

[Marco]

NXP says the Mifare Plus S isn't export controlled, don't know about the library but there are some open source libraries out there.

US congress is almost certainly going to be total assholes about export regulations and for stuff like encryption EU might not think it's worth it to have different regulations (oil will flow and cars will trade regardless of US congress at this point). So it seems prudent to use something not export controlled, it still has AES-128 (it acts like Classic until you kick it to a higher security level).

PS. no protection against MitM attacks though, ie. time of flight, which is unfortunate.

[dizgah]

Yes but for public transportation is a bit more, As NXP recommends mifare desfire ev1 is completely enough,
Any way i dont have any idea for how securing keys stored in sram memory?
Best regards

[Jeroen3]

Using the tamper detect. Device opened, keys erased.

[dizgah]

Asume attacker succesfully passed from tampers,as i said before i only want to focus & check ways of securely key storing in sram
WBR

[dizgah]

Hi every one
3 key storing scenario :
1-Storing keys in the SRAM memory,in each booting sequence ,inject keys to the embedded MCU and store them in the SRAM memory. It is best way i think,then when MCU sense penetration(with tamper sensor or ...)it can erased SRAM quickly and reset itself. Disadvantage: if attacker success to pass tampers and access to device,how safe is SRAM memory (against code mining). I can't find any security ability for this memory in MCUs.

2-Generate keys and stored them in the flash memory in programming MCU. MCU flash memory's support CRP(code read protection) which prevent from code mining and with assist of its internal AES engine and RNG(random number generation) engine we can make a random key and encrypt flash memory and stored that random key in the OTP(one time programmable memory -a 128 bit encrypted memory),then in code execution we decode flash memory with RNG key and access to initial key and codes. Disadvantage: Keys stored in a non volatile memory ,Tampers will be useless and attacker have a lot of time to mine keys.

3-Stored key in the EEPROM memory,combination of 2 above approach,key stored in the non volatile memory but when tampers sense penetration EEPROM is erasable.

I consider LPC18S57FBD208(cortex m3 with 1MB of flash memory,180MHZ,136KB SRAM,16KB EEPROM and a TFT LCD controller which i need to drive a 7" TFT LCD and AES 128 bit crypto engine) for that is there any other better suggestion?
WBR

[dizgah]

connection between PCD (proximity coupling device or the card reader)  and MCU is based on SPI,Becouse of unsecure and un-encrypted connection between them ,each attacker can sniff the connection and achieve the keys used for reading and writing to the RFID tags.
what is your suggestion for this?
WBR

[nuhamind2]

Hi dizgah
You should reconsider how authentication is performed. Sniffing is only problem if the key is ever transmitted plainly. NXP Mifare Classic and NXP Desfire both use mutual authentication in which no party actually send the key plainly. Both PICC (the card) and the reader will exchange key that encrypted with RNG.AFter which the communication between PICC and reader is encrypted using session key derived from the RNG. Mifare Classic is considered unsafe because the RNG is predictable.

Scenario 2 might be the most practical.  Store the key in the internal flash and prevent it from being read, perform authentication with the PICC by transmitting the encrypted key. The exact algorithm depend on the PICC card. For Desfire I think you have choice between AES or DES or no encryption at all.

Or you can use separate secure access module to store the key. This module basically a secure MCU, can be in the shape of SIM card or normal IC. Getting access to this very likely require NDA. Use this solution if you really afraid someone decapsulate your MCU.

For additional security you can use key diversification.

I suggest getting the datasheet for NXP Desfire. Again, this will require an NDA, but will give you clearer idea how mutual authentication is performed.

[dizgah]

hi Nuhamind2,
i speak about connection between MCU and PCD,I know after challenge sequences and authentication ,connection between PCD and PICC will be encrypted,but problem is SPI connection between MCU and PCD is in plain mode and any man in the middle can sniff SPI and discover the accessing keys to tags content,then he/she can change tag's credit himself.
 

[nuhamind2]

I am aware of that. You don't transmit the key out of the MCU plainly. The PCD don't need to know it. The PCD do not perform any encryption on the keys. The MCU do that.

Transmitting the key plainly, as far as I know only needed on Mifare Classic. If you use Desfire, the key won't need to leave MCU plainly.

ps: I am working at a company that provide electronic ticketing system.

[dizgah]

Dear Nuhamind2,
thank you for replying me.
my descriptions was based on my experiences with Mifare classic.
can you give me more information about that security features?do you mean complete encrypted communication between MCU and PCD via SPI,I2C & etc is possible in desfire series ?I was read some thing about <<MIFARE SAM TM AV2>> but i could not understand completely it's meaning.

[nuhamind2]

I guess your setup is like this :

MCU <===> PCD  <===> PICC

Both of the MCU and PICC know the key to authenticate each other. The MCU and the PICC send the key encrypted with random number. SO, even if someone sniff the link between MCU and PCD or between PCD and PICC, what they get is some random data.

In this case the authentication is performed end-to-end, that is between the MCU and PICC. The PCD know nothing about the key.

I suggest getting the NDA for NXP Desfire datasheet, since I can't tell you in detail. Try google with "desfire apdu command", see what you got.

[Marco]

Why would you use the Desfire and risk running into export controls when you can use the Plus S?

[dizgah]

Dear Marco,Desfire EV1 was recommended by NXP for public transportation ,and used in the London oyster cards and ...

[Marco]

Was it recommended to you by NXP for use in Iran?

If not I'd get in contact with them at this point and ask what the situation is, especially for SDK access.