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?

[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.

[dizgah]

In USA, CHINA, IRAN and even twenty thousand leagues under the sea, words have the same meaning ,I read that case on the mifare's website.
any way i think export controls are contain mifare plus too.
these companies does not provide any support to Iranian customers,then i will be appreciate you for any help in this field.
whats your meaning from SDK? PCD chip's SDK (NFCReaderLibrary)do you mean? or other SDK?

thank for your interest to this topic.

[Marco]

That library is a good start. There are export controlled versions of that library, is that the one you will need? Will they give it to you? When they recommend these cards for transportation they presumably factor in their own ecosystem, including stuff like SAM, which you won't necessarily have access to because of export restrictions (or maybe you do, ask NXP).

[dizgah]

whats differences there are between publicly published library and export controlled versions?is this differences ,effective in field of our interest?
As I said there are no support,no request answering and ....
Then i don't think they give us that export controlled version therefor SAM is a complete dream.

[dizgah]

Hi every one
I am using KEIL RTX RTOS which used pre-emptive round robin scheduler.I have a LCD for displaying data and a few tasks have access to this LCD(there are some other tasks also),These tasks need fixed time for handling the LCD(e.g. first task handle LCD for displaying it's data for 50 seconds and after 50 seconds,second task handle and displays it's data for 10 seconds). I know i must use mutex for managing accessing to LCD.but i dont know how i must manage its for fixed times?LCD tasks are in the lowest priority and if there are not any other task to execution these tasks will be execute for displaying messages.
EDIT:
Seems i must use virtual timers.

[nctnico]

I don't want to derail the technical content of this thread: I have been in London recently and over there you can use NFC enabled credit and debit cards to check in/out of the public transport. That works quite well so it could be any idea to consider. Perhaps a credit card company or bank can provide some leverage on getting something like this implemented.

[dizgah]

I don't want to derail the technical content of this thread: I have been in London recently and over there you can use NFC enabled credit and debit cards to check in/out of the public transport. That works quite well so it could be any idea to consider. Perhaps a credit card company or bank can provide some leverage on getting something like this implemented.

First you must prove yourself to them and without good knowledge and ready sample devices there is no chance,TNX for reply.

[dizgah]

I'm using K4S561632C 256Mbit SDRAM for increasing MCU's memory,but i found this lines in the SDRAM's initialing library which deliver  me with product:

    #define SDRAM_BASE_ADDR      0xA0000000
    #define SDRAM_SIZE           0x01000000   /* 16M 128Mbit 1024*1024*16 byte */                         

but as i said above it is 256Mbit memory while SDRAM_Size refer to 128Mbit memory.can any one please clear me ?