MCU for NFC transportation payment

[dizgah]

Hi every one
I'm working on a NFC-based payment system in the transportation field.
Because of it , I need a strong powerful MCU with a successful background in the same application implementation.
Electronic sections consist of :
1- NFC Tag reader, for transacting with a RFID tags
2-7" TFT LCD for GUI section
3-Strong MCU for driving above 2 parts

I have 2 choice for MCU:
1th is based on STM32F429 cortex m4 MCU from ST,general MCU(not secure),with a rich documents & examples & large user communities,Cheap & strong Evaluation board(discovery board) and debugger/programmer(built-in st-link),Internal LCD controller,software encryption engine (cryptographic algorithms),lack of EEPROM, Lack of hardware security features(for storing keys,secure boot & ...)

2th is based on LPC18S57JBD258 cortex m3 MCU from NXP,secure MCU,does not have so much documents & peripheral initialing examples,with a limit user community,internal LCD controller(I'm in doubt about it's capability in decoding 480*800 or less resolution video),hardware encryption engine(so faster than software engine),EEPROM memory,dozens of security features.

It's my pleasure to have you recommendations.
WBR,
Mahmoud

[free_electron]

Neither one. Both do not meet the requirements for financial transactions. You will never get this thing certified
Processors that are capable for this kind of work are not available in the open market.

It starts with first signing a bunch of NDA's. Actually, it doesn't:  it starts with obtaining certification that you are an approved developer for this kind of stuff from the financial industry. once you have that certification you can start signing NDA's.

[nctnico]

Neither one. Both do not meet the requirements for financial transactions. You will never get this thing certified

Where did you get that idea? NFC systems for transportation are leaky and flawed around the globe.

Edit: it sounds like nonsense to me. I suddenly recall a project I worked on which used a vanilla H8/300 microcontroller and that passed certification for financial transactions just fine for a similar purpose (but not over NFC). They don't even look at the controller, they look at how the security layers are implemented and for financial transactions systems encryption doesn't even really matter. If the incoming money and outgoing amount of services don't match then there is fraud which is easy to detect / trace back to the perpetrator.

[MT]

Are Iranian engineers even able to get hold of such MCU's? Was thinking about current trade blockades, IP etc?

[dizgah]

Neither one. Both do not meet the requirements for financial transactions. You will never get this thing certified
Processors that are capable for this kind of work are not available in the open market.

It starts with first signing a bunch of NDA's. Actually, it doesn't:  it starts with obtaining certification that you are an approved developer for this kind of stuff from the financial industry. once you have that certification you can start signing NDA's.

Everything Should Be Made as Simple as Possible, But Not Simpler,Albert Einstein

I'm not Einstein then I want to make this as secure as i can ,but not more secure 

Where did you get that idea? NFC systems for transportation are leaky and flawed around the globe.

Edit: it sounds like nonsense to me. I suddenly recall a project I worked on which used a vanilla H8/300 microcontroller and that passed certification for financial transactions just fine for a similar purpose (but not over NFC). They don't even look at the controller, they look at how the security layers are implemented and for financial transactions systems encryption doesn't even really matter. If the incoming money and outgoing amount of services don't match then there is fraud which is easy to detect / trace back to the perpetrator.

where is the thank button ?

Are Iranian engineers even able to get hold of such MCU's? Was thinking about current trade blockades, IP etc?

Here finding a simple IC or Transistor is very hard sometimes & much more expensive than other places,without any support ,example or responsibility  but usually dealers find some ways when you pay them more.
any way I'm very concern to know any technical comparison ,successful experiences or other recommendation about that.
WBR

[free_electron]

Where did you get that idea? NFC systems for transportation are leaky and flawed around the globe.

The OP post he clearly mentions PAYMENT SYSTEM. That means you will need to interact with a payment processor ( company processing the payment ). They have strict rules as to the transactions. You can forget interacting with the NFC chip in a VISA or AMEX card. Rolling your own is also a no-no. There are standards to be followed. You will be audited along the entire trail. You'll have to use a crypto NFC card approved for such purposes.

That stuff is not open. When i was at ST we had a whole group dedicated to that stuff (most of the chips in Visa cards are fabbed by ST) . Those guys are so anal that they even work in rooms without windows. Just so no guy with a telelens could make a picture of a computer screen where a chip layout may be visible....

[nctnico]

Well that is about the chip inside the cards which is likely to contain a complicated proprietary encryption system. Interfacing with such a chip from a payment terminal is an entire different scenario. Sure the payment provider will want to audit the system and some NDAs will be put in place but this isn't a painful process. As I recall the project I was involved in used a new way to have a multi-headed payment system which wasn't described in the standards yet but they got it certified.

[free_electron]

you can probably get away with it you use a precertified module. Meaning the NFC reader itself is precertified to do the transaction with the card and the modem. But building such an NFC reader itself ? They will never give you the protocols .

Dave did a teardown of a simply payment terminal a while ago. Look at how many anti-tamper mechanisms there are int he pcb design and the mechanical design alone. The 'keys' fur such terminals are stored in volatile memory. When a terminal is put into service it gets a set of unique keys identifying the terminal and its owner. Tamper with that terminal and these keys are wiped immediately.

In an ATM even the keypad itself has such a crypto engine. The cable between the keypad and the motherboard never transports the PIN code in cleartext. Stuff remains encrypted all the way.

And then there is this : would you trust your money to a payment system made by a guy that asks for help on an internet forum ? People that design these systems don't talk about it on forums. They already have access to the relevant information. ... And i haven't even mentioned country of origin ...

Then ask the question if the banks would ...

[nctnico]

You have to start somewhere... Just did some Googling... the protocols seems to described be in standards. Ofcourse a payment terminal needs anti-tamper protection but the goal of the terminal is to establish a secure link between the bank's server and the chip inside the card. The terminal itself is nothing more than a secure transport layer.

[free_electron]

You have to start somewhere...

yes you do, but do you really think the guys developing this do it on a public forum ?
That stuff is a very closed world. ST got a hold of it because they bouht the Bull systems CP-8  group. A lot of the payment card crypto was developed by Bull in the early 90's on request of the banking industry. Bull had a processor core ( i think it was an ST-6) specifically adapted with secure eeprom and a hardware crypto engine.

the banks wanted secound sources and there is a whole industry around these payment cards. But today this is still a close knit group where you can't simply step-in.
You can make a payment terminal if you buy the processing modules from an already approved source. Get the NFC card reader , get the modem ( the thing that connects the payment system with the network ,whether this is tcpip , phone line or whatever. and you can build the rest.

But trying to build the actual NFC reader that does the crypto ? Not a chance.

[nctnico]

See my edit. All the protocols are in public standards! Security by obscurity has been abandoned.

[free_electron]

Yes, the protocols are known, but you will still need to pass certification. they will check your anti tamper systems and you will have to go through an entire list of approvals before they will allow you to hook up to their network and before they will even hand you a set of keys.

Again : look at the teardown of that simple hand terminal : that was a magstripe. not even a smartcard reader.
And that thing was already full of asics.

You really think they will allow someone to make such a terminal with an arduino ? ( as a matter of speaking )
Start by picking a high security processor. There are a number of processors specifically made for the payment market with unique features.
But, be prepared to sign NDA to even get a datasheet or register map ... And then there's the development tools required...

Not an easy task.

[dizgah]

Tnx for answer.
Excuse me for lacking in the description.
There are no program to interact with international credit cards(like visa &...),not for connecting to the banking accounts.
we(a small group not a international company ) want to use it for electronic purse applications in the transportation field.
something like this :
we sell a RFID mifare tags with a specific charged credit,car drivers used it for paying parking fees(R/W tags with PCD chip like PN532),we collected credit data & charged tags when needed again.
as i said we want to implement this system as secure as we can & i will be really thankful if only discuss about technical information,we don't want bother others with problems is related with us(about ability to make this or not)
Best regards

[nctnico]

In the Netherlands they use such a system for public transport. The amount of money is stored on the card itself (the first release used Mifare card) because the terminals are not always online (the terminals check if someone has enough money on entrance and store where someone embarked / disembarked and send that to a central server). The central server then calculates how much money has to be withdrawn from the card which is updated later on when the card is used. It is rather complicated but at least it keeps working if the central server is down.

Because each card has a unique ID which cannot be altered it is possible to keep track of the amount of money which is put onto a card and the amount of money which is pulled from the card. If more money is pulled than being put onto the card  it means fraud and the card can be flagged in the system (police, arrest, pay fine, etc). That is the accounting part of the security system.

IMHO the biggest mistake they made in this system was putting the amount (and other data) onto the Mifare card as text/numbers without a hash code to sign it. That made the authentification/authorisation part of the system weak so people could use throw-away cards and use a mifare card reader/writer to put money on a card and travel for free.

If you can design the entire system by yourself it shouldn't be hard to build but you should understand security stands on three legs: accounting, authentification and authorisation. The system should be able to keep standing on one of these legs if it gets hacked. The accounting part is important for these kind of systems so you can flag fraud. If the information on the card is signed with a hash (SHA-256 for example) then it will be very hard to alter it using simple techniques if someone manages to read the NFC card.

[free_electron]

OK , that is a different animal.

What you are making is a keyless entry system. you rent parking stalls on a time base.

Get a HID card reader hook it up to your processor of choice and have him communicate with a cloud service that validates the card. The security sits on the cloud machine. All the local processor does is transmit card ID. the go/nogo and account management is done on the cloud server.

[Marco]

The OP post he clearly mentions PAYMENT SYSTEM. That means you will need to interact with a payment processor ( company processing the payment ).

All the card contains is tokens, all the tokens can pay for is fare. Sure there is a small amount of fraud possible by stealing tokens, but due to the limited convertibility it's not a terribly interesting avenue for fraud.

They can get get away with relatively little security without the banks blocking their ability to debit from accounts to auto-refill the tokens, because the simple fact is that they have.

PS. isn't stuff like MIFARE DESFire EV1 openly available with open protocols for initial programming and communication?

[dizgah]

Actually we designed initial non GUI version & it works ,now in second phase of development we want to solved its bugs,add TFT LCD & improve security capabilities if is require(like secure RTOS,secure mcu & ...).
I think  basically analysis will help more:

It's cheaper approach to use Mifare classic RFID CARD(instead of othe mifare family with strong crypto algorithms like mifare desfire & mifare pro ) as a tag but it used old unsecure algorithm(crypto1) which has some successful attacks,then i design this sequence for authenticity:
 
-First we separately encrypt plaintext(credit) to ciphertext in the mcu based on AES.
-As you know each tag has a Unique ID(UID) & we define a key for transacting data between tag & reader/writer chip that controlled by the mcu( PCD chip).
-When tag entered to PCD's operation field,pcd read tag's UID
-MCU make ENC_KEY with irregular combination of AES_INIT_KEY & uid (each tag will has seprate ENC_KEY)
-MCU calculate plaintext'hash with its hash function(TEXT_HASH).
-MCU encrypt plaintext based on AES with ENC_KEY(it makes CIPH_TEXT).
-MCU transfer & stored CIPH_TEXT & TEXT_HASH to the tag's (mifare classic) via mifare algorithm .

then if attacker dump a charged tag's  value to other tags it does not work because each tag's has unique key & same credit in different tags are not same CIPH_TEXT

I'm really concern to read your viewpoint about that.
tnx

[poorchava]

In the City where i live (Wroc?aw,  Poland) we have something called UrbanCard. It's a smartcard (not sure what type) which holds some data about tickets and passes one has purchased. The card can be charged with new passes and tickets online,  in ticket kiosks and in automatic ticket machines.

I've once seen a validator for this stuff taken apart (only ticket controllers carry those) and there wasn't any strong crypto,  just a PIC32 hooked up to an LCD,  card reader and some wireless data module.

Wys?ane z mojego HTC One M8s przy u?yciu Tapatalka

[nctnico]

Actually we designed initial non GUI version & it works ,now in second phase of development we want to solved its bugs,add TFT LCD & improve security capabilities if is require(like secure RTOS,secure mcu & ...).
I think  basically analysis will help more:

It's cheaper approach to use Mifare classic RFID CARD(instead of othe mifare family with strong crypto algorithms like mifare desfire & mifare pro ) as a tag but it used old unsecure algorithm(crypto1) which has some successful attacks,then i design this sequence for authenticity:
 
-First we separately encrypt plaintext(credit) to ciphertext in the mcu based on AES.
-As you know each tag has a Unique ID(UID) & we define a key for transacting data between tag & reader/writer chip that controlled by the mcu( PCD chip).
-When tag entered to PCD's operation field,pcd read tag's UID
-MCU make ENC_KEY with irregular combination of AES_INIT_KEY & uid (each tag will has seprate ENC_KEY)
-MCU calculate plaintext'hash with its hash function(TEXT_HASH).
-MCU encrypt plaintext based on AES with ENC_KEY(it makes CIPH_TEXT).
-MCU transfer & stored CIPH_TEXT & TEXT_HASH to the tag's (mifare classic) via mifare algorithm .

then if attacker dump a charged tag's  value to other tags it does not work because each tag's has unique key & same credit in different tags are not same CIPH_TEXT

I'm really concern to read your viewpoint about that.
tnx

This method will be easy to hack. I'd add a secret password to the encryption key. Also look at HMAC (https://en.wikipedia.org/wiki/Hash-based_message_authentication_code) to sign data instead of encrypting it. However encrypting the data may be a good idea anyway for privacy concerns.

[dizgah]

Really thanks for good information,
but i think why & how  can help better than it is secure or not (show how attacker can violate sequence)
Let's compare specifications of MCUs one by one to have better choice for same application(with reasonable grade of security):

1th threat : data  mining or code mining,its almost most important case,
LPC:
Code Read Protection - CRP,
CRP enables different levels of security so that access to the on-chip flash and use of the
JTAG and ISP can be restricted. CRP is invoked by programming a specific pattern into a
dedicated flash location.

STM32:
STM32 proprietary code protection overview-Global Read Out Protection (Global ROP):
IP code and end user code are protected
against direct reading (by debugger tools or RAM Trojan code) through STM32 ROP.
------------
Key storing:
LPC:
64 bit+ 256 bit of One-Time Programmable (OTP)  memories for AES key storage and customer use.One OTP memory
bank is encrypted.
STM32:
16 data block & each block consist of 32 Bytes-not encrypted
---------
memory protection unit:
both of them has built in MPU
-------
EEPROM:
LPC:
16KB which is ideal to storing events,security alarm bits,additional keys & ...
STM32:
does not have
------
Clock & power failure(in hardware attacks to )
LPC:
Brownout detect with four separate thresholds for interrupt and forced reset.
STM32:
something like LPC one
-----
Really I am interested in debated about above fields,which one is necessary & which one is useless.
What worries me is when attacker can extract & mind content of a giant companies product's like Segger/keil (jlink & ulink,i think they used atmel arm mcu ) & clone them, it's not impossible mining code & data from ARM chips.

[nctnico]

I think the internal eeprom in the LPC chip is important to have. You can use it to store data to detect tampering with the device. The OTP memory for encryption keys is also very handy. The eeprom can be read if the chip is erased but by then the firmware is gone.

[Jeroen3]

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

[dizgah]

is there any successful code minding in ARM cores especially Cortex m series ?

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

Currently finding STM32F429 discovery board is as simple as any other electronic devices from electronic markets or online shops,
Situation about secure MCUs like lpc18sxx is harder to find but not impossible.
any way i hope sanctions cancellation will be executed as soon as possible.
Best Regards. 

[MT]

STM32 do have OTP memory areas.

[dizgah]

STM32 do have OTP memory areas.

You are right,i will edit my above post,however in my STM32F429xx datasheet , searching "OTP" does not return any thing(DM00071990-2 revision 5 published on 19-Feb-2015 5 -it is last version)
tnx
---
OTP(on time programmable) memory seems really good to storing keys but there are problem too,
when you decide to change the keys-it is impossible to change or erase bytes.
However we can assign a small group of bits(for example 1 Byte) to figure out how many time keys changed-for example when we used our first key then we set first bit(next bit must be zero)-am i true?