MiFare DESFire are iso14443A compliant contactless smartcards, and support all layers including iso14443-4. These cards are so-called “stored value” cards, so you cannot install and execute your own program code on DESFire cards. DESFire is like a memory card with access control.
Typical usage is within public transportation and access control.
DESFire cards are considered secure. Even though there are some theoretical security flaws, no public working hack has been published like there has been for Mifare classic (standard) cards. (The new DESFire EV1 cards are supposed to address the flaws found in v0.6).
Depending on the version of the card, a DESFire card might support commands in native, native-wrapped or iso7816-4 command set styles.
- Software version v0.4 does not support APDU (only native commands)
- v0.5 adds support for wrapping native commands inside ISO 7816 style APDUs
- v0.6 adds ISO/IEC 7816 command set compatibility.
New versions of DESFire cards (EV1) (v1.3) support extended APDU commands.
“Application” in DESFire terms is more like a DF (Directory File) in iso7816. DESFire AIDs (Application IDs) are 3 bytes long.
The command style of the first command determines the mode for the rest of the session. You cannot mix different command modes in the same session.
First, lets look at Native command mode.
Native Command mode:
Most of these commands are one byte long, and the card responds with “statusbyte + [optional data]“
00 : Command successful
af : More data (send command 'af' to fetch remaining data)
9d : Permission Denied
--> To card
<-- From card
Example using a blank DESFire v0.6 card:
--> 60
<-- af 04 01 01 00 02 18 05
--> af
<-- af 04 01 01 00 06 18 05
--> af
<-- 00 XX XX XX XX XX XX XX ZZ ZZ ZZ ZZ ZZ 05 06
The first response denotes the hardware releated data: version is 0.2 (00 02), and storage size is 18 (4096 bytes)
The second response denotes the software releated data: version is 0.6 (00 06), and storage size is 18 (4096 bytes)
The X’s are the 7-byte UID
The Z’s are the 5-byte batch number
05 = Calendar week of production
06 = Production year
--> 6a
<-- 00
No applications available (blank card)
--> 5a 00 00 00
<-- 00
OK
--> 6f
<-- 9d
Permission denied.
--> 45
<-- 00 0f 01
0f = All bits in the lower nibble are set, meaning configuration can be changed, CreateApplication/GetApplicationIDs/GetKeySettings can be performed without master key, and master key is changeable
01 = Only 1 key can exist for this application (the PICC application)
--> 64 00
<-- 00 00
The PICC master key version is 0×00
--> 0a 00
<-- af a2 be cd 03 d8 46 cb 33
--> af b0 cc bc ed 8f c8 38 c9 08 dc e2 4d 86 ca ec 3c
<-- 00 76 73 d9 49 71 3f f2 d1
This example only showed authentication with the PICC application. In a real world transaction, you would typicall select a specific AID (!= 00 00 00), authenticate, and then read/write to files within that application.
After a successful authentication, further communication with the card is done in plain/plain+MAC/encrypted+MAC, depending on the access bits for the particular file.
Authentication is done using DES or Triple-DES, depending on keysize. If key is 8 bytes: Single DES. If key is 16 bytes, and the first 8 bytes of the key are different from the last 8 bytes: Triple-DES. The card terminal (PCD) always use DECRYPT_MODE (both when recieving and sending encrypted data), and the card always uses ENCRYPT_MODE. However, the DESFire crypto is a bit different from the normal DES/CBC scheme: The PCD uses DES “send mode” when sending data (xor before DES), and the card uses DES “recieve mode” when recieving data (xor after DES). But when the PCD recieves data, it uses normal DES/CBC mode (xor after DES), and the card uses normal DES send mode when sending data (xor before DES).
| Send encrypted data | Recieve encrypted data | |
| PCD (DECRYPT) | DES/CBC “send mode” | Normal DES/CBC “recieve mode” |
| Card (ENCRYPT) | Normal DES/CBC “send mode” | DES/CBC “recieve mode” |
The last 2 modes are useful if you need to communicate with a DESFire card through PC/SC, or you need to emulate DESFire on Java Cards.
Native Wrapped command style:
In this mode, native commands are wrapped inside iso7816 style APDUs.
cls ins p1 p2 lc [data] le
90 [native ins] 00 00 lc [data] 00
SW1 SW2
91 [native status code]
--> 90 60 00 00 00 00
<-- 04 01 01 00 02 18 05 91 af
--> 90 af 00 00 00 00
<-- 04 01 01 00 06 18 05 91 af
--> 90 af 00 00 00 00
<-- 04 28 3b 61 5b 1b 80 8e 64 55 61 10 05 06 91 00
--> 90 6a 00 00 00 00
<-- 91 00
--> 90 5a 00 00 03 00 00 00 00
<-- 91 00
--> 90 6f 00 00 00 00
<-- 91 9d
--> 90 45 00 00 00 00
<-- 0f 01 91 00
--> 90 64 00 00 01 00 00
<-- 00 91 00
--> 90 0a 00 00 01 00 00
<-- a2 be cd 03 d8 46 cb 33 91 af
--> 90 af 00 00 10 b0 cc bc ed 8f c8 38 c9 08 dc e2 4d 86 ca ec 3c 00
<-- 76 73 d9 49 71 3f f2 d1 91 00
The last mode is the iso7816 command set mode:
Full support for these commands require DESFire v1.3 (EV1)
ISO SELECT (A4)
ISO GET CHALLENGE (84)
ISO EXTERNAL AUTHENTICATE (82)
ISO INTERNAL AUTHENTICATE (88)
ISO READ BINARY (B0)
ISO UPDATE BINARY (D6)
INS READ RECORDS (B2)
ISO APPEND RECORD (E2)
As you can see, not all functions are available using the iso7816 command set. If you need more functions, you must use native or native-wrapped mode.
September 29th, 2009 at 11:38
Hello.
and I assumed card responded on command “authenticate” ( 0x0A ) like in Your example “af a2 be cd 03 d8 46 cb 33″. So utilizing only autentication procedure and mentioned key value I should get APDU frame to card like in Your example again:
Nice example but I’m not able to do any autentication with Desfire card.
I was trying to authenticate accordingly to nxp documentation but still get 0xAE error ( authentication failed ).
Looking at Your example above ( I guesss You utilized master PICC transport key which value as I know is equal 0 or better all bytes are 0′es )
I was trying to forget about the card
af b0 cc bc ed 8f c8 38 c9 08 dc e2 4d 86 ca ec 3c
Unfortunately , I’m not able to achieve the same result. Could You describe me step by step operations that led You to above APDU frame ?
Regards
Jacek
September 29th, 2009 at 12:48
Hi,
Yes I used default DESFire key with all ’0′s.
The auth starts with host sending 0x0A + keyNumber to card.
Card responds with 0xAF + encrypted RANDOM_B (8 bytes)
Host DECRYPTS RANDOM_B using normal DES CBC recieve mode.
Host then creates new array ARRAY2 (length 16), and copies its own random data (RANDOM_A) to bytes 0-7.
Bytes 8-15 are the decrypted RANDOM_B, but with a 1 byte left shift. So ARRAY2[15] = RANDOM_B[0]
ARRAY2 is then DECRYPTED using CBC SEND mode (not a normal CBC mode, and you will probably not find a standard library that does this for you. You may have to implement this CBC mode yourself using Single DES + xor).
Host then sends the decypted ARRAY2 to card: 0xAF + decrypted ARRAY2.
Card ENCRYPTS ARRAY2, and if RANDOM_B is correct (after a 1 byte right shift), it then does a 1 byte left shift of RANDOM_A, and ENCRYPTS the result using normal CBC Send mode.
Card then responds with 0×00 (auth ok) + encrypted RANDOM_A (after 1 byte left shift).
Host then DECRYPTS the response using normal CBC recieve mode, and checks RANDOM_A (remember 1 byte right shift).
Auth finished.
Let me know if it works
Ridrix
September 29th, 2009 at 14:11
Thanks for fast response.
What exactly means xor operation here ? Xor given buffer with what ?
1) Itself – byte after byte ( ARRAY2[0] = ARRAY2[0]^ARRAY2[0], ARRAY2[1] = ARRAY2[1] ^ ARRAY2[1] and so on) .
2) With given number ? – All bytes xor’ed with 0xFF for example , so ARRAY2[0] = ARRAY2[0] ^ 0xFF, ARRAY2[1] = ARRAY2[1]^0xFF and so on.
Regards
Jacek
September 29th, 2009 at 15:53
Sorry, a little typo there, I meant you have to implement CBC mode yourself using _Triple_DES + xor.
XOR is a part of the CBC mode. See here how CBC works:
http://upload.wikimedia.org/wikipedia/commons/d/d3/Cbc_encryption.png
(The XOR operation is of course the circle with the cross inside.)
The CBC mode in this picture is the normal CBC send mode (as done by the card when sending data to host).
When receiving data, the card does the xor operation AFTER the “Block Cipher Encryption” step (but still using DES ENCRYPT).
Note that the card ALWAYS uses DES ENCRYPT mode (both when recieving and sending data). And the host ALWAYS uses DECRYPT mode.
September 30th, 2009 at 11:44
So , as I understood this modified 3DES CBC decryption it is 3DES CBC decryption but with schema as for encryption. In other words, in first step
I xor iv with first 8 bytes of cryptogram ( for encryption schema it is first 8 bytes of text ) and do 3DES decryption. In next step, previously 8 decrypted bytes I xor ( it is new iv ) with next 8 bytes of cryptogram and do next 3DES decryption.
September 30th, 2009 at 12:13
Uffff… Now it works for 0x0A for Your sample above. Now real card….
January 27th, 2010 at 14:45
Still fighting with CBC mode using _Triple_DES + xor.
…
RNDA and RNDB is combined. -> 16 bytes
What should be XOR and with what?
In java
byte keyBits[] = new byte[]{ (byte)0×00, (byte)0×00, (byte)0×00, (byte)0×00, (byte)0×00, (byte)0×00, (byte)0×00, (byte)0×00 };
Cipher c = null;
IvParameterSpec iv= new IvParameterSpec( new byte[]{ (byte)0×00, (byte)0×00, (byte)0×00, (byte)0×00,(byte)0×00, (byte)0×00, (byte)0×00, (byte)0×00 }, 0, 8 );
SecretKeySpec sks = new SecretKeySpec( keyBits, 0, keyBits.length, “DES” );
c.init( Cipher.DECRYPT_MODE, sks, iv);
c.doFinal(combinedArray, 0, tempSource.length, result, 0 );
January 28th, 2010 at 09:32
Also cipher algorithm is
c = Cipher.getInstance( “DES/CBC/NoPadding” );
December 24th, 2009 at 10:46
Hi Ridix,
Could you please send me the “3des source code in C” if possible.
I have an algo. which gives decrypted output {0×39,0×34,0×51,0x2a,0xb2,0x3d,0×55,0×05}for input{0xa2,0xbe,0xcd,0×03,0xd8,0×46,0xcb,0×33}.
Please check.
Thanks,
Bala.
September 29th, 2009 at 13:28
Oh, and I forgot, the Initialization Vector to the CBC is all ’0′s. (Which, by the way, is a possible security flaw).
September 30th, 2009 at 06:30
Hi can you please help me on How can I communicate with DESFire using the other type of commands. I have successfully done it using this type of commands. But I am having a hard time using the commands with the
cls ins p1 p2 lc [data] le
90 [native ins] 00 00 lc [data] 00
SW1 SW2
91 [native status code]
I dont know what to put in the instruction code and the p1 p2 area.
I have two different readers Omnikey 5121 and Omnikey 5321. The 5121 doesn’t accept Native commands.
Help will be appreciated.
Thanks
September 30th, 2009 at 12:40
Hello Baron.
I utilize Omnikey CardMan 5121.
It works without problems in ISO7816-4 mode. What problems You have with it ? As mentioned in documentation P1 and P2 are always 0.
LE = 0 must be at the end of APDU frame.
Jacek
September 30th, 2009 at 11:49
To avoid further misunderstandings, all DES oparations in 0x0A autentications are 3DES operations ?
September 30th, 2009 at 12:25
Weither the operation is 3DES or singleDES depends on the size and format of the key. But it’s better to always use the 3DES algorithm, because that will work both as 3DES and SingleDES, and a 3DES operation is usually pretty fast anyway. For example: If your key is 16 bytes, and the first 8 bytes are equal to the last 8 bytes, then the effecive encryption will be single DES, even if you are using 3DES. 3DES is Single DES done 3 times: ENCRYPTION (using key bytes 1-8), DECRYPTION (using key bytes 9-16), and ENCRYPTION (using key bytes 17-24). So use 3DES and create code to “expand” the key. Let’s say your 3DES algorithm wants 24 byte keys: if the key is 8 bytes, then repeat these 8 bytes 2 times (SingleDES). If the keys is 16 bytes, then copy the first 8 bytes into bytes 17-24.
October 7th, 2009 at 18:32
Hello,
I’m working on a project and i have to use mifare desfire but i don’t know anything and i couldn’t find any information about communication.
Can you give me document about how can i communication it.
thanks
October 8th, 2009 at 13:39
Hi,
To obtain the desfire documentation you will have to contact NXP. You will most likely have to sign NDAs (None Disclosure Agreements). I don’t have any documentation I can give away unfortunately. I haven’t signed any NDAs with NXP. All the information you can find in this blog is collected from other blogs and forums on the internet. What do you mean by “how can i communicate with it”? Do you have a card reader and know how to program against PC/SC? Make sure you have a contactless smartcard reader, like the Omnikey Cardman 5321 or similar which supports the PC/SC standard. Then write an application in C/Java (or other preferred language that has PC/SC bindings), and use the “native wrapped mode” or “ISO command set mode” to communicate with your Desfire card.
October 9th, 2009 at 13:54
Hello again.
A lot of work I have done with Desfire card so far but now but in front of me many serious problems concerned with secure messaging as always
First task – key changing
I created application with 5 3DES key on “good day”. Accordingly to documentation they should have 0′es values. Chnage mode to the keys I set in that way , key changing is possible if old key with the same number will be authenticated.
After application selection, I was trying to change key 1. Before operation I authenticated succesfully with old key 1 and in further step I issued “Change key” APDU sequence. Unfortunately , error 0x1E appeared.
What could went wrong ?
1) Autentication was succesfull so I assume session 3DES key I calculated ok
2) Myabe CRC16 ? I found different ways of calculating it even with the same generator. Could anybody confirm that CRC16 for 16 bytes, each of 0 value ( default value of old 3DES key ) , is equal 0xAFA9 ?
I put it 0xA9 0xAF in APDU buffer LSB MSB. Correct ?
3) 3DES calculation of data. It is normal 3DES encryption in CBC mode with IV = 0 ? ( data to be encrypted is “new key” || CRC16 || 0′s padding until 24 bytes )
Any suggestions ?
Regards
Jacek
October 19th, 2009 at 16:43
Hi, This has been a very useful article, thanks for publishing it.
I am looking at DESFire EV1, but cannot get a list of the command codes to use for the following functions.
Authenticate
Change KeySettings
Set Configuration
Change Key
Get KeyVersion
Create Application
Delete Application
Get Applications IDs
Free Memory
GetDFNames
Get KeySettings
Select Application
FormatPICC
Get Version
GetCardUID
Get FileIDs
Get FileSettings
Change FileSettings
Create StdDataFile
Create
BackupDataFile
Create ValueFile
Create
LinearRecordFile
Create
CyclicRecordFile
DeleteFile
Read Data
Write Data
Get Value
Credit
Debit
Limited Credit
Write Record
Read Records
Clear RecordFile
Commit Transaction
Abort Transaction
Do you have any links or other documentation I can read to help with this. I have tried NXP several times but they don’t respond!
Many thanks in anticipation
October 29th, 2009 at 17:29
I don’t have any document that describes all the commands unfortunately. I think such documents are only available under NDA’s. However, you can find many of the DESFire commands in the Nokia proprietary extension classes in the 6212 Java SDK. This SDK is free, but you need to register to download. Registration is of course also free.
http://www.forum.nokia.com/info/sw.nokia.com/id/5bcaee40-d2b2-4595-b5b5-4833d6a4cda1/S40_Nokia_6212_NFC_SDK.html
Install SDK and add to for example Netbeans.
Look in the package “com.nokia.nfc.nxp.desfire”.
These classes contain utility methods that help you construct native DESFire commands. I think most of the commands are described there.
June 8th, 2010 at 08:50
Hello,
I’m developing an application for a mifare DESFIRE card and a portable terminal from Ingenico (EFT930G Contactless).
I have done tests with SAM communications without problems (activating, selecting app, presenting the PIN…), I have also sent different commands to the card with good results: GetVersion (in order to get the card UID), GetApplicationIDs, SelectApplication…
My problem has appear when I’m trying to carry out the authentication process in order to get the session key.
I follow the first steps, but when I send the Authenticate Command to the card (with KeyID 0×01): 0×90, 0x0A, 0×00, 0×00, 0×01, 0×11, 0×00 the cards returns only 3 bytes, instead of 8.
I have tried many different things, as sending Additional Frame command (0×90, 0xAF, 0×00, 0×00, 0×00) in order to get the rest of the of the bytes, but the card always returns me the Command Aborted message: 91 CA
Please, can you help me with this issue?
Thank you very much in advance.
June 21st, 2010 at 14:50
This is beacause the length of card response is set to 3 bytes instead of 8. check this parameter.
June 21st, 2010 at 15:24
Thank you freeds,
It was exactly this issue…it wasn’t set to 3 bytes (null value) but it must be 8
June 20th, 2010 at 12:17
hi ridrix
i develope an application for Desfire card. the authentication with card is successfull and I can generate the session key.
bt I have a problem. How we can specify a key (rather than application master key) in the selected AID. osuppose that I want to set the value of key 1 to 0×00 0×11 0×22 0×33 0×44 0×55 0×66 0×77 0×00 0×11 0×22 0×33 0×44 0×55 0×66 0×77. and then set the access right of a data file to authenticated with this key. my question is general . how and when we can specify the application user file?
thanks in advance
Jafer
July 8th, 2010 at 05:00
Hi, I am a newbie and I am trying to communicate with a DESFire card using an OMNIKey 5321 reader on VB6. I am able to follow all the communication samples and I am also able to do authentication. I request assistance on how to create an application on a new card and subsequently write and read standard files into the application created. Any assistance will be greatly appreciated. Thanks.
July 9th, 2010 at 08:20
Hi guys.
I’ve a problem with desfire EV1 cards. I can send basic commands in ISO7816 wrapping mode such as GetVersion, Select Card Level and Authenticate by default TDES card level key (all ’0′). After that I’ve correctly generated the session key, I would to set an UID random by the setConfiguration command. Now, I don’t know on which data the CRC32 is evalued. In fac, following commands give me 811E error:
90 5c 00 00 09 00 Ek(02 CRC32(90 5c 00 00 02) 00 00 00) 00.
The result doesn’t change if I use CRC32(5c 00 02) or CRC32(all command). Help me, please!!
July 19th, 2010 at 13:13
Hi Ridrix,
Excellent examples
I am new one in the card development. and start working on desfire native mode using omnikey reader. Need some guides in change key command.
Here is my log
->CA 20 20 20 0F 0E( CREATE APPLICATION HAVING ID=202020 )
5A 20 20 20
0A 02
AF F8 07 5D C3 EA F3 CD 7C 68 2D F6 46 44 FF 34 6D
>0101020203030404
RANDOM B>>6B4B5908F93AA1E4
SESSION KEY>>010102026B4B590803030404F93AA1E4
String oldKey = “00000000000000000000000000000000″;
String newKey = “00112233445566778899aabbccddeeff”;
-> C4 02 DF 90 2F 3D 84 89 2D B9 13 20 EC 9D 98 F3 A6 47 B2 0E 71 B9 09 F0 29 69
<- AE
Need your guides in change key command
Hope this finds you all in the best of Good days and good luck.
Thank you
cheers
July 20th, 2010 at 10:18
Try authenticating using master key ->0A 00 before the change key.
Please let me know if it works.
Also could you kindly share the CRC for your new key. I am having difficulty myself generating the CRC for the change key command.
Goodluck, and hope to hear from you!
June 2nd, 2011 at 04:40
http://ctskinner.blogspot.com/2011/03/desfire-sam-crc16.html
June 2nd, 2011 at 04:42
Java crc32
http://ctskinner.blogspot.com/2011/03/crc32.html?showComment=1303100723901#c44434266748248545
July 22nd, 2010 at 11:45
Hi,
Looks like the CRC calculation is a problem. I have tried several versions with no success. I am fairly confident that the rest of the ChangeKey code is correct.
Can anyone with a known to be working CRC16 routine for DESFire supply a CRC16 value for the following example: AABBCCDDEE001122
Many thanks.
August 23rd, 2010 at 15:41
desfire uses iso14443a crc16 – here’s the python implementation i use:
August 31st, 2010 at 04:49
Hi Adam Laurie?
Do you have the CRC16 implementation in Java and C++?
I have already tested the implementation in Java, but why the result is different?..
Could you help me regarding this?
Thx
August 31st, 2010 at 13:45
I don’t have a Java implementation, but here’s one in C:
and BTW, the correct answer for the original example (AABBCCDDEE001122) is 7B09, so you need to be careful to use the correct byte order when passing on the short returned by this version.
August 31st, 2010 at 13:49
Hmmm… Something went horribly wring with cut & paste there!
August 31st, 2010 at 13:53
OK, so it;s not cut & paste but something in wordpress that’s screwing it up…
Function is here:
http://www.rfidiot.org/crc16.c
September 1st, 2010 at 03:41
Hi Adam Laurie
Thanks for the CRC16 in C implementation..
It works great!!..
But unfortunately, i’m still looking for CRC16 in Java implementation, and i’m still facing problem when convert it to Java..
Anyway, thanks for the example..
August 7th, 2010 at 10:39
hi Ridrix,
i have a Desfire MF3ICD41 card and wrote a C# program for authenticate with it; the default key is 0000000000000000
but i can’t authenticate with this card
may you give some test vector for my authenticate module (i sure that’s work correctly but i can’t authenticate yet)
please help me
regards
August 9th, 2010 at 08:58
hi ridrix
my desfire card is MF3ICD41 (Desfire EV1)
if authentication algorithm is different from that you describe??
regards
August 11th, 2010 at 12:57
Hi Ridrix
I am trying to create files and read and write those files.
I succeed with the Data files, but with the record file I am receiving error “0xBE”.
I’m creating record file and can write the record file. On the Read Record command I’m receiving this error.
Command I send:”bb 07 01 00 00 03 00 00″ – as I understand it’s file 7 from read 3 ercords starting from record 1. This file have 3 records.
What is wrong here?
regards
August 11th, 2010 at 13:58
I have one more question.
I can’t create value file. I receive error code 9E (parameter error).
command that I send:cc 01 00 42 f0 00 00 00 00 99 99 99 99 00 00 00 01 01
Thanks you
August 31st, 2010 at 04:17
Has anyone read and decrypted a key from ANY Mifare DESFire cards?
Specifically public transit systems?
August 31st, 2010 at 17:06
Hi, guys.
I’ve a question for you. I’m using nokia 6212 in order to read a DESFire EV1 card personalized in ISO7816 wrapping mode; but I’ve some problem because the phone doesn’t detect the card. I use this code in targetDetected method:
if (classes[i].equals(Class.forName(“com.nokia.nfc.nxp.desfire.DESFireConnection”))) {
String url = target.getUrl(classes[i]);
conn = (ISO14443Connection)Connector.open(url);
The method Connector.open(url) is not capable to establish a connection. In case of APDU commands native, I thing the connection work. In other words, I think that is not possible to use the specific features of Ev1 chip, that is AES authentication, UID random and ATS configurable. Is it so? If not, how can I connect my 6212 phone to the chip Ev1 card in order to use the EV1 features?
Thank you in advance.
September 2nd, 2010 at 08:49
Hi!
I’ve found that the nokia 6212 cannot open connection only if the uid of desfire ev1 card is set to “uid random”; when I use a desfire ev1 card with uid in plain, the connection is ok. Now, I think the problem is of phone because the uid random not change after the RF-reset but then I don’t know why connection fails. Have you some idea?
November 12th, 2010 at 06:27
Hi all
Iam new into card development.
I have dis Mifare 1K card.
iam able to get the UID but cannot get the authentication done.
I am trying read and write from the sectors but without authentication
it gives me 69 82 as response.
please help me
regards
November 14th, 2010 at 07:44
Hi Vaishali, This error means security status not satisfied.
You should first select application on the SAM and on the PICC, then authenticate this application, and only when applications will be authenticated you will be able to read and write records.
Try to authenticate with master key 0.
November 19th, 2010 at 10:47
Hi Ridix and another one!!
Thanks for your web!!
I have a question about the authentication. In the cbc encryption the Plaintext is the random numbers, the key is the codification key (0s in your example), but what is the initialization vector??
Thanks!
December 15th, 2010 at 17:24
Hi,
I am trying to change the keyno 1 of my application but I get a 911E error, what means that CRC or padding must be wrong. I can authenticate to the master key and get the session key. Here I post the output of my program.
Session Key: D8 15 60 CE 33 55 7D BC 3E F4 34 EA 1D FF F9 28
Old Key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
New Key: 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF
Key Data: 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF 69 CC 69 CC 00 00 00 00
Transmitted data: 71 66 0B 4C C6 EB A6 F9 D6 36 86 2F 6A ED 33 E5 D9 84 50 B0 04 6B A9 85
I Hope someone can help me.
December 23rd, 2010 at 10:56
The session key is wrong.You have to authenticate with the old key.The first eight bytes are equal to the second half , therefore you have to build
the session key in the same way.The first half of the session key must be
equal to the second half.
December 30th, 2010 at 11:28
Hi,
Thanks for your response.
So, what you mean is that if the random numbers are: D8 15 60 CE 3E F4 34 EA – 33 55 7D BC 1D FF F9 28, the key I have to use is: D8 15 60 CE 33 55 7D BC D8 15 60 CE 33 55 7D BC ???
Bye.
December 30th, 2010 at 12:02
Hi again,
I have a similar problem trying to send encrypted data, so I think that maybe the problem is not in the key, but in the way I encrypt the data when the data is more than 8 bytes.
For example if I try to write 00 01 02 03 04 05 I send the next command and everything is fine:
90 3D 0000 0F 06 000000 060000 + Encrypt(00 01 02 03 04 05 28 da) + 00 –> OK
But if I try to write more bytes it doesn´t work.
90 3D 0000 17 06 000000 0c0000 + Encrypt(00 01 02 03 00 01 02 03 00 01 02 03 62 20 00 00) + 00 –> FAIL
Here is a log:
Data: 00 01 02 03 00 01 02 03 00 01 02 03 62 20 00 00
Session Key: 43 D8 9D 37 3F 0F E1 BC
APDU: 90 3D 00 00 17 06 00 00 00 0C 00 00 3F 40 08 FC 1D 60 5D C8 B4 30 71 1D 03 E1 57 11 00
Does anyone know why fails when I try to write more than 8 bytes??
Thanks again.
December 20th, 2010 at 12:55
Hi,
Can any one have the CRC32 implementation in Java or C++?
Thank you,
December 23rd, 2010 at 22:23
Here is a C version:
http://www.rfidiot.org/crc32.c
December 23rd, 2010 at 09:38
Hello:
How to know the version of a DESFire card? (any Command?)
Thanks~
December 23rd, 2010 at 15:43
Hey,
I implemented almost the whole DESFire-spec in java and everything works fine (i.e. authentication with aes/des, create/delete aid, create/delete fids, write standard files) but I’m not able to change a key on application level. I’m creating an aid, a fid, standard file and write some bytes into it. Everything with standard key (i.e. 0×00…). Reading out the file does work also.
Now I implemented a changeKey-method which should work but always gives me 0x1E, i.e. “INTEGRITY_ERROR”. I’m using the standard java crc32 implementation. Authentication ist 0xAA, i.e. aes. But I also get 0x1E if I “corrupt” bytes of the ciphered key data block, so I’m not sure if my crc32 is not correct or the parameters are in the wrong order. According to the spec, its encrypt(aesKey(16), keyVersion(1), CRC32(4), padding(11)), right? Does java.util.zip.crc32 produce the correct crc? The exponents etc. should be correct, I even tried to XOR the bytes with 0xFF…
Any hints on this one? Thanks a lot!
May 3rd, 2011 at 09:47
Hello,
i’m developing a java application and i want to read files from a desfire ev1 card with AES protection. I began to reconstruct the way of authetification from the nxp application notes. i succesfuly can generate the reply from pcd (to picc’s) to the command 0×90 0xAA. Only problem is after i send (0×90 0xAF 0×00 0×00 0×32….) i get a IllegalArgumentException with “invalid apdu: length=38, b1=50″. In NXP documentation i read that length of command could be up to 64byte, so i think thats enough.
Thanks a lot for any help. And sorry for my english. If someone prefers german answer on my question thats no problem;)
May 4th, 2011 at 08:51
OK, i think i need a brake. only problem was 0×32 is not the same as 32 (int).0×20 in stead of 0×32 works perfectly;)
January 19th, 2011 at 08:11
Hi,
Can any one have the CRC32 implementation in Java according to Mifare Desfire specification
Thank you,
February 2nd, 2011 at 10:35
Hi,
You just have to copy the crc32_table and then create a new method where the crc is calculated:
public byte[] crc32(byte[] d) {
long temp;
long oldcrc=0xffffffff;
for(int i = 0; i > 8) & 0x00FFFFFF) ^ crc32_table[(int) temp];
}
byte [] b = new byte[4];
for(int i= 0; i >> (i * 8));
return b;
}
February 2nd, 2011 at 10:39
Arggg,
It seems there is a problem when trying to copy the code. Here is the code again. If it does not appear correctly please post your email and I will send you.
long len = data.length;
for(int i = 0; i > 8) & 0x00FFFFFF) ^ crc32_table[(int) temp];
}
byte [] b = new byte[4];
for(int i= 0; i >> (i * 8));
}
February 2nd, 2011 at 13:18
Hi,
I have been reading the Ev1 specification but I cannot undestand how the IV management works.
In the beginning we have Iv=0×00 … 0×00. Then we send something and the CMAC value gets a value, for example IV=0011223344556677. So how can I get the second part of the IV and get the new value IV=11223344556677XXXXXXXXXXXXXX ??????????
Thanks
February 2nd, 2011 at 15:03
Hi,
i am facing problem in changing card master key to AES.
Raw Text >>
000000000000000000000000000000000075450000000000
after native enciphering>>
91EC5552B50A73630000000000000000E97E894656A9F0F4(incorrect)
Can any explain desfire native TDES MODE enciphering for change master key case2?
My session key =b954afcbcf8c4e95b954afcbcf8c4e95b954afcbcf8c4e95
Thanks.
February 24th, 2011 at 04:27
with an omnikey 5321 I get
DESFire ATR 3B8180018080
UID 04 52 2E AA 47 23 80 90 00 [from apdu FFCA000000]
All other apdu give 917E unknown error
February 24th, 2011 at 17:50
Hi,
I don´t know what you are sending to your DESFire card, but the 917E means that:
0x7E LENGTH_ERROR Length of command string invalid
So, take a look at the length you are indicating in your commands because it mus be wrong.
Hope this helps.
Bye.
June 2nd, 2011 at 04:31
most apdu now working
but NOT ChangeKey <<<<<<<<<<<<<
which differs according to Native|Standard
may have iv pre-decrypt?
may require version ?
for key0 all zeros Session key 1sthalf=2ndhalf?
Standard uses crc32?
tried all, no changekey
working: MakeAID, read,write, even format works!
(I have a lot of test cards to play with!)
March 4th, 2011 at 02:11
Hi to all,
I’m new to the smartcard Desfire programming.
Following the samples in the forum I was able to get the UID of the desfire card, but no success in the nex steps. Basically I wanna do:
1) Create application (other than 000000)
2) Set a new Key to the application( use application level keys, not the master PICC)
3) Create a new file within the application
4) Being able to read the app/file created in the 1~3.
Can some body provide a source code in c/c++, so I can see how it is done?
Thank you in advance and any help is very welcome.
March 5th, 2011 at 03:21
Gorka
I am facing exactly same error mentioned in one of yours previous message (msg at the end).
I can successfully authenticate and create the session key. But I am not able to change PICC MASTER KEY.
Already tried Mustafa suggestion to use sessionkey with first 8 bytes equals to last 8 bytes. Same result (91 1E).
No idea what is the correct process to be able to debug/resolve this issue.
Have you been able to figure this out? If so, what was the problem?
Thank you ver very much!
I will post a new msg with the complete APDU log for my communication.
Thanks
Bruno
Slightly difference from your code is regarding the CRC16. I am appending only 2 bytes after the new key. And you are appending twice. Any problem with this? What is the correct way?
“##BEGIN##”
Gorka Says:
December 15, 2010 at 17:24
Hi,
I am trying to change the keyno 1 of my application but I get a 911E error, what means that CRC or padding must be wrong. I can authenticate to the master key and get the session key. Here I post the output of my program.
Session Key: D8 15 60 CE 33 55 7D BC 3E F4 34 EA 1D FF F9 28
Old Key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
New Key: 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF
Key Data: 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF 69 CC 69 CC 00 00 00 00
Transmitted data: 71 66 0B 4C C6 EB A6 F9 D6 36 86 2F 6A ED 33 E5 D9 84 50 B0 04 6B A9 85
I Hope someone can help me.
“” END “”
March 5th, 2011 at 04:08
Following my previous post, here is the complete communication with desfire ev1 8k card:
1. Select PICC App
APDUCommmand: [9 bytes, LC=3, LE=256]
–> 90 5A 00 00 03 00 00 00 00
90 0A 00 00 01 00 00 (Authentication with Key 00 – Request Random Number)
90 AF 00 00 10 22 95 75 18 68 13 46 31 44 8A 64 35 3F 15 06 BC 00
90 C4 00 00 19 00 AA 6D E2 CF 80 01 63 53 C0 94 8B 88 8C A7 44 51 51 93 04 1A F5 21 C1 9E 00
<– 91 1E [ERROR]
INTEGRITY_ERROR – CRC or MAC does not match data – Padding bytes not valid
The Error is the same as Gorka. No idea what to do to fix it. Can anybody help me with that?
Thanks
Bruno Bertechini
March 5th, 2011 at 04:10
Sorry , it seems like wordpress does not like copy & paste for big texts…
Will split in few posts.
March 5th, 2011 at 04:11
### POST 1 ###
1. Select PICC App
APDUCommmand: [9 bytes, LC=3, LE=256]
–> 90 5A 00 00 03 00 00 00 00
90 0A 00 00 01 00 00
90 AF 00 00 10 22 95 75 18 68 13 46 31 44 8A 64 35 3F 15 06 BC 00
<– 39 B4 6B 2B 05 45 3B 72 91 00
At this point, the Card decipher RndB, execute a left shit and compare with its own RndB.
If its okay, it decipher RndA, execute a left shit and cipher with same key (0×00).
So, the response is RndA (left-shifted) ciphered by the card:
RndA (left-shifted and ciphered) = 39 B4 6B 2B 05 45 3B 72
2.6 The program (my program) decipher RndA using key 0×00 and execute a right shift
RndA (deciphered) = 7B B7 CB F4 14 9F 01 07
RndA (deciphered and right-shifted) = B7 CB F4 14 9F 01 07 7B
March 5th, 2011 at 22:38
1.When you build the session key you must take care that the first eight
bytes are equal to the second byte.The reson is that the default key
all zeroes also has the first eight bytes equal with the last eight
bytes.
2.When you send the new key you have to use CBC with single DES
decryption.That Means: You have to exor the fisrt eight bytes of the
new key with IV=00 00 00 00 00 00 00 00,than single DES decrypt the
result(using the session key built like mentioned under point 1) and
send it to PICC ,than exor this result with the second eight bytes of
the new key and single DES decrypt it and send it to PICC, the
result you have to exor with two bytes CRC with padding zeroes (six
bytes) and single DES it and send it to the PICC.
March 6th, 2011 at 00:00
Hi Mustafa, Thanks for your response.
For Point #1 thats okay. already changed the code to make 16 bytes key with 8 first bytes (RndA 1st half + RndB 2nd half) equals to last 8 bytes.
For Point #2: What does that mean the exor? I am using a simple DES operation (decryption) on the new key. What do I need to do with the IV ?
Bruno
March 7th, 2011 at 06:51
Hi Bruno,
the reason is that DES decryption you can use on eight byte blocks only.When you change the key it is 16 bytes long plus you have to build CRC16 (two byts long) and you have to pad it to eight bytes with six zeroes.That means you have to send three blocks each eight bytes long to the PICC.To send three blocks you have to chain them (this method is called CBC chaining).
For this operation you need to logical XOR the result of the
plain data with the result of the foregoing decryption and then decrypt it (DES or 3 DES according key type).And at the first block you use the initial vector 00 00 00 00 00 00 00 00.
March 7th, 2011 at 09:39
Hi Bruno,
First of all, the key I had to change was the key #1 of my application. I tell you that because the CRC16 depends on the change you want to change. As you can read in the DESFire specification, it is not the same if the key you want to change is the one used in the authentication (that is your case since you are working with the master key) or it is another key from the keyset. In the first key you have to add only two CRC bytes and in the second one 4 bytes (I think it was that way, take a look at this point)
The problem I used to have was on the encryption. I was not encrypting the data in the correct way (you know, all the xor before DES thing). Once I corrected that, it worked. If you don´t know what I mean try to send more than 8 bytes of data over an encrypted channel. If you can´t do that, you probable are not doing that ok.
Good luck
Gorka.
March 7th, 2011 at 15:50
Thank you guys.
So, what exactly do I need to do now in order to change the master key from default (all 0s) to another key with 16bytes length to use 3DES.
1. Build Session Key using only 8 bytes? or Build session key using 16 bytes with last 8 equals first 8 bytes?
2. If it is 16 bytes DES key (with 1st half = 2nd half) do I need to do it in 3 steps right?
Mustafa, sorry for my newbie questions, but can you pls show me in a step-by-step examples with real bytes to help me understand? Im real stucked on this issue.
Gorka, I got what you said. My 1st goal here is to change the master key (to 3DES and later to AES). I have read on specs taht EV1 1.06 uses CMAC instead of CRC16. Is that correct?
Also, when you say ” I tell you that because the CRC16 depends on the change you want to change”. What does that mean?
Thanks for all your help guys!
Bruno
June 2nd, 2011 at 04:49
3 seperate sends of 90C4 with 8 bytes in each?
I’ve been trying 1 send of 24 bytes…
June 2nd, 2011 at 05:44
na, the card doesnt like it, it wants 24 bytes of data in 1 go.
I use key 0, keyvalue 0…0 version 0 so the order
doesnt matter, tried w * w/out version
keep getting that 911E
required:
[90C4 0000 19 data 00] where data is 24 decrypted bytes
since the card knows not the new key it MUST be a crc problem ( i dont believe a MAC is required)
March 7th, 2011 at 16:56
OK Bruno,
let mexplain more detailed.First of all the main thing is if the first half of the key you use is equal to the second half you use single DES for decryption.If the first half different from the second half you use triple DES for decryption.The first half of the default key all zeroes is practically equal to second half so you use single DES for decryption.Now assume your session key after successfully authentication is A4 24 63 B7 1C EC 85 0F (these are sample data and not real )and the key you want to use is : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F .
The CRC16 for this key is 77 F5 .Now you have to send following blocks to the PICC :
1. Block 00 01 02 03 04 05 06 07
2. Block 08 09 0A 0B 0C 0D 0E 0F
3. Block 77 F5 00 00 00 00 00 00
When sending you have to chain them together using CBC rules.You have to build logical XOR byte for byte with 00 00 00 00 00 00 00 00.The
result is the first block itself.This you have DES decrypt (single DES ,
decrypt only once).Build the XOR with the result of it and second block
(08 09 0A 0B 0C 0D 0E 0F).Then DES decrypt it (only once again).Build
the XOR with the rsult and last block (77 F5 00 00 00 00 00 00) and
Des decrypt it.Now you have to send thes data in the same sequence you
build them to the PICC.
March 7th, 2011 at 16:58
Thanks Mustafa. Just one question. The session key must be single DES right? Should it be 8 bytes long or 16 bytes with first half equals second half?
March 7th, 2011 at 17:33
Mustafa, I just authenticated to the card to get a “real” session key and provide mor information to validate my code for Decrypt using CBC.
After Authentication, I have the RandomA and RandomB (already validated with mutual auth).
Here they are:
RandomA = 9F CA 40 0F 3F AA 65 AC
RandomB = 21 82 A9 52 D0 C9 64 02
In order to change the master key from all 0s. What session key should be generated?
1. DES Key (RndA 1st half + RndB 1st half)
9F CA 40 0F D0 C9 64 02
Is that correct?
Need to figure this out first before go forward. I am also having problem to achieve the same CRC16 as you for the new key in your example (code is in C#). But I am forcing the CRC16 now and later on I will go through this.
Can you pls confirm if this is the session key I need to use?
Thanks!
Bruno
March 7th, 2011 at 18:24
Bruno,
you have written right thing (RndA 1st half + RndB 1st half) but
you made wrong thing , the session key for single des decryption
is : 9F CA 40 0F 21 82 A9 52.For building CRC don’t worry.There
are many codes on internet.
March 7th, 2011 at 18:36
Thanks Mustafa. Realy typo in there.
Okay, now I have the correct SessionKey. I will use for now the CRC16 as you mentioned and later on gather something from internet.
Moving forward:
Here I will get a new session key from the card and ask if you can help me to validate my single DES operations. I.E. I will send unenvrypted and encrypted data to check if you can get same results (to be able to validate my code).
1. Session Key = 93 C1 93 5B 60 5A AE E2
2. New Key Blocks =
1. Block 00 01 02 03 04 05 06 07
2. Block 08 09 0A 0B 0C 0D 0E 0F
3. Block 77 F5 00 00 00 00 00 00
3. Block1 XOR defaultKey (All 0s)
xorB1 = 00 01 02 03 04 05 06 07
4. Single DES Decrypt Operation using previous Session Key and IV = 0×00
xorB1Decrypted = B1 D0 01 AC 14 A6 BF 0F
Mustafa: Could you please validate this data? To make sure my “decrypt” process is okay?
5. Result#4 XOR Block2
xorB2 = B9 D9 0B A7 18 AB B1 00
6. Single DES Decrypt Operation using previous Session Key and IV (here is another question — Should I use the IV generated in previous step #4 ? Or should I use the result data (xorB1Decrypted) as IV?)
Here I am using the xorB1Decrypted as IV =
xorB2Decrypted = 7D 51 A6 D2 A3 56 40 D7
Same process for the 3rd block.
I would like to confirm these steps to make sure I am doing it in the right way…
Regards
Bruno
March 7th, 2011 at 19:03
Sorry Bruno,
I’am not in my office.Please write down the results of each step.Ican check them tomorrow and tell wether they are correct.
March 7th, 2011 at 19:05
This is what I have done for the ciphering process for block1 and block2
Will try to send you a complete process using my own keys…
Do you have an email/gtalk/msn or anything I cant get you in touch?
Bruno
P.S.: Many thanks in advance!
March 7th, 2011 at 19:07
If you could just validate what i’ve sent in previous post that will be great. There you have my session key and the operations results (which I need to match yours using my session key).
Thanks a lot!
Bruno
March 8th, 2011 at 07:14
Hi Bruno,
I think there is something wrong with your DES code.Here the results with
your data:
Session Key : 93 C1 93 5B 60 5A AE E2
New Key : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
1.Block XOR IV : 00 01 02 03 04 05 06 07
DES decrypted 1. Block : 9C 5F D6 AF 54 5B F3 CF
Decr.1.Block XOR 2.Block : 94 56 DC A4 58 56 FD C0
DES decrypted 2.Block : B4 75 3E 05 AA DD BF 14
Decr.2.Block XOR 3.Block : C3 80 3E 05 AA DD BF 14
Decr. 3.Block : F4 66 84 8B 21 0F CD C2
March 8th, 2011 at 19:05
Okay.
That’s what I was afraid of. I am using C# standard DES Provider using CreateEncryptor to get the result.
Will need to do some sort of research to achieve same results.
Mustafa, thanks for your results…
Regards
Bruno
P.S.: You are being able to change PICC master key for some card right?
Again, This CRC16 code is only for ID 40 (not EV1). I will try to fix the DES part and later move to EV1 ID41 (Desfire EV1 4K) and ID81 (Desfire EV1 8k).
Thank you very much!
Bruno
March 8th, 2011 at 19:36
Mustafa, did you implement the DES code yourself or are you using some library?
What language are you using?
Bruno
March 9th, 2011 at 05:45
Mustafa thanks again.
Previously you said: “Now you have to send thes data in the same sequence you
build them to the PICC.”
Based on the decrypted example (the last one) do I need to send one apdu to the card with 24bytes (the 3 blocks xor/decrypted) together ?
Thanks
Bruno
March 9th, 2011 at 06:22
Got it working and I am being able to achieve same results as yours. little more happy now
But, still having problems to change the PICC master Key. Pls have a look:
SessionKey
[5E 9D 67 5D E3 9F DA 4D]
Block1 : 00 01 02 03 04 05 06 07
Block2 : 08 09 0A 0B 0C 0D 0E 0F
Block3 : 77 F5 00 00 00 00 00 00
R1 = Block1 XOR DefaultKey
R2 = R1 Decrypted
R3 = R2 XOR Block2
R4 = R3 Decrypted
R5 = R4 XOR Block3
R6 = R5 Decrypted
R1: 00 01 02 03 04 05 06 07
R2: EA 69 9B 0F 14 10 F1 1E
R3: E2 60 91 04 18 1D FF 11
R4: A1 70 60 B2 D5 69 1A 52
R5: D6 85 60 B2 D5 69 1A 52
R6: BD 08 71 4B B4 05 D4 C0
–> 90 CA 00 00 19 00 EA 69 9B 0F 14 10 F1 1E A1 70 60 B2 D5 69 1A 52 BD 08 71 4B B4 05 D4 C0 00
<– 91 7E
With the wrong DES operation I was getting 911E and now i am having 917E (Length Error).
Do you have any idea on whats going on ?
Are my DES/XOR operations above correct now?
Thanks Again!
Bruno
March 9th, 2011 at 06:25
Hi Bruno,
I have written DES for myself and I used standard C and GNU compiler.
Following link may be useful (http://www.aci.net/kalliste/homepage.html).
I didn’t used APDU but I have sent native changekey command and the
three blocks.
Good luck
March 9th, 2011 at 06:32
Bruno your command code is wrong.CA is for create application.Change Key
command code is C4.
March 11th, 2011 at 04:27
Mustafa, typo and copy paste problem. Problem fixed! Key Changed and Card authenticated. Now I will move on to AES.
Note: I am using all desfire versions for tests Mifare Desfire 4K (ID40) Desfire EV1 4K (ID41) and Desfire EV1 8K (ID81)…and also (just for tests desfire ev1 2k).
Thank you very much for your help. Very soon i will post here some info on how I did it in C# to get it working with all credits for DES/CBC going to you
Thanks!
Bruno
March 9th, 2011 at 06:43
Hello,
I’m having some problems with the use of the session key.
What I am doing is reading a standard data file that has zeros for data, and trying to reproduce the generated MAC.
Here is a sample log of the commands I am sending
>905A00000301000300 //Select Application with AID:010003
900A0000010000 //Authenticate with key 0
B = BBBCF23D82B7AA2B
>90AF00001067CB1064A90A0BC5B705DB03C0EA7A4B00
//With A = 0011223344556677
906F000000
//Get File IDs
90F50000010200
//Get FIle Settings for file 02
90BD0000070200000008000000
//Read 8 bytes from file 2 starting at index 0
90BD0000070200000010000000
//Read 16 bytes from file 2 starting at index 0
<00000000000000000000000000000000D6ACE0D19100 //data:00000000000000000000000000000000 MAC: D6ACE0D1
Now, encrypting 0000000000000000 with DES Session Key gives: FA2B513202BD660A
And with the DES3 key gives: 3FA964A8211CDFA1
neither of these matches the given MAC 7CEC960D. what key should I use?
March 9th, 2011 at 06:48
The formatting didn’t show up right.
here is the log again:
PCD: 905A00000301000300
//Select Application with AID:010003
PICC: 9100
PCD: 900A0000010000
//Authenticate with key 0
PICC: 630A702C444BE34A91AF
//-> B = BBBCF23D82B7AA2B
PCD: 90AF00001067CB1064A90A0BC5B705DB03C0EA7A4B00
//With A = 0011223344556677
PICC: BA6EB2C23193EE8A9100
//Authentication Successful
Session key should be
DES: 00112233BBBCF23D
DES3: 00112233BBBCF23D4455667782B7AA2B
PCD: 906F000000
//Get File IDs
PICC: 03029100
//Files 03 and 02 present
PCD: 90F50000010200
//Get FIle Settings for file 02
PICC: 000100002000009100
//standard data file, MAC, all access only with master key, size 32 bytes
PCD: 90BD0000070200000008000000
//Read 8 bytes from file 2 starting at index 0
PICC: 00000000000000007CEC960D9100
//data: 0000000000000000 MAC: 7CEC960D
PCD: 90BD0000070200000010000000
//Read 16 bytes from file 2 starting at index 0
PICC: 00000000000000000000000000000000D6ACE0D19100
//data:00000000000000000000000000000000 MAC: D6ACE0D1
Now, encrypting 0000000000000000 with DES Session Key gives: FA2B513202BD660A
And with the DES3 key gives: 3FA964A8211CDFA1
neither of these matches the given MAC. what key should I use?
March 9th, 2011 at 11:36
Hi Felippe,
1.What is your key 0, is it the default key all zeroes.The general rule is
if the first half of the key is equal to the second half you use single DES.
If the fist half is different from the second half you have to use 3 DES.
2.When you send data to PICC you use DES or 3DES decryption because
PICC always make encryption.When you build MAC you have to use
DES or 3DES encryption.
3.When you want to build the MAC you have to chain eight byte long
blocks of data.You have to build the logical XOR of the first eight byte
with IV(00 00 00 00 00 00 00 00) then DES or 3DES encrypt it.Then
you have to build the logical XOR of the result with the the second eight
byte and DES or 3DES encrypt it.The first four bytes of the result is
your MAC.
March 9th, 2011 at 11:38
The key 0 is the default all zeroes. Could you look at my example and tell me what the session key is supposed to be?
March 9th, 2011 at 20:21
According the data you have given the session key should be
00112233BBBCF23D.To build MAC you should use single DES encrypt not
decrypt and you should chain the two blocks using CBC as mentioned before.
March 9th, 2011 at 21:20
When I send the PICC the command
PCD: 90BD0000070200000008000000
I am asking for 8 bytes, meaning that I should only receive 1 block. The response from the PICC is
PICC: 00000000000000007CEC960D9100
This, as I understand it, means that the data is 8 bytes of zeroes (1 block) followed by the 4 byte MAC which would be 7CEC960D.
This would mean that if I XOR the first and only block of data with the IV I would still get 0000000000000000. If I encrypt that with the session key, I receive 0xFA2B513202BD66A0, which does not match the received MAC. Could you please point to where I am making a mistake?
March 10th, 2011 at 04:59
I am new for desfire card.
Can someone explain how host DECRYPTS RANDOM_B when i first run the authentication. Use which IVector and Key to decrypt.
If there is a sample code in c#, it will be prefect.
Thanks a lot.
March 10th, 2011 at 21:11
Unfortunately there are few C# resources when it comes to DESFire.
Here is a short explanation of the authentication process.
The PICC will send the application an 8 byte random number encrypted with the master key. The default master key is 0000000000000000 0000000000000000. Because both halves are the same, it is a single DES key and the session key produced will also be a single DES key. The IV is 0000000000000000.
The tricky part with the authentication is to make sure the application decrpyts when sending the response. And make sure you use CBC-Send mode.
You will receive e(B). Then you will send a 2 block message containing A followed by B’.
Decrypted, the first block will be D1 = d(A xor B) followed by D2 = d(D1 xor B’).
The response from the PICC will be e(A’^B’).
March 15th, 2011 at 03:22
William,
Apparently I gave you the wrong answer and might have led you down a path of much frustration. So in hopes that you do read this, when you reply to the PICC’s first response to the 0A command, reset the IV to 0000000000000000.
So your transactions should look like this.
PCD: 0A00
PICC: AF e(B)
PCD: AF (e(A)) (e(e(A) xor B’))
PICC: 00 e(A’)
your session key will then be the first 4 bytes of A followed by the first four bytes of B.
March 16th, 2011 at 03:08
Dear Felipe,
Thanks for your reply and following up. Finally, i succeed to authentication step.
By the way, do you know the cmd/Auth/others difference between the desfire (D40) and desfire ev1 (D41). As i only can find the Specification of D40. Can i develop the program according this specification? Thanks.
March 16th, 2011 at 03:12
I haven’t been able to get the D41 functional spec either. You have to sign a NDA with NXP if you want those documents, and they can at times not be very helpful. However, you can find a lot of the details in the libfreefare source. http://code.google.com/p/nfc-tools/wiki/libfreefare
March 10th, 2011 at 14:12
Hi Felipe,
are you sure that the session key and MAC are belonging together.
Because with your data I’m getting the same result.
March 10th, 2011 at 23:48
Mustafa,
Have you been able to perform a change of key or any operation that uses the session key?
Could you please post a log of such a transaction starting with the authorization using master key zeroes?
Thank you
March 11th, 2011 at 04:25
Felipe, I am not at the office right now, but I will post something tomorrow regarding desfire/auth/change key etc..
I had a hard time but with Mustafa’s help now I am being able to change key and authenticate with the new one.
Will let you know tomorrow ok?
By the way, I presume you are also from Brazil
Bruno
March 11th, 2011 at 22:29
Bruno,
That would be a great help. Thanks in advance.
March 14th, 2011 at 10:56
There is an open source project that includes DESFire authentication and keychange examples written in C:
http://code.google.com/p/nfc-tools/wiki/libfreefare
March 14th, 2011 at 16:12
Can someone please help me. I have read every comment on this blog and other forums and still can’t seem to get anything that uses the session key working. I even looked through the libfreefare source and I could swear I am doing the exact same thing, but mine just doesn’t work.
Here is a log of an authentication process?
out: 5A 00 00 01
in 00
out 0A 00
in AF B2 F1 D2 8A D5 55 3C 35
out AF 86 71 3A E7 7C B7 C5 51 AF AF 66 4C 59 F4 8E 9A
in 00 6F A0 F0 1F 9B EB B5 C6
I think i might be interpreting my values of A and B wrong and therefore generating the wrong session key, so could someone please look over this and tell me what the session key from this authentication would be?
March 14th, 2011 at 16:43
Also, the key 00 is the original master key 0000000000000000
March 14th, 2011 at 19:17
Hi Felipe,
what do yo want to do with sessionkey?
I think your decryption algorithm is O.K.
Otherwise you wouldn’t be able to authenticate and
you wouldn’t get the answer: 00 6FA0F01F9BEBB5C6.
To build the session key you get first 4 bytes of
random A put first 4 bytes of random B then last 4
bytes of random A and last 4 bytes of random B.
If you wish send the complete data,I mean not only
data coming from the PICC also the single DES
decrypted data,so I can check them.
of
March 14th, 2011 at 19:30
Hi Mustafa,
I am still having the same problems from last week. No operation that uses the session key seems to work correctly. reading/writing encrypted or MACed data, changing keys, etc…
I am using the session key generated by combining the first halves of randA an randB. Here is another full trace where I create and then read 2 bytes from an encrypted file.
The card is a brand new Mifare DESFire EV1 with one application FFFFFF, max 5 keys, access rights EF in it.
The master key of application FF FF FF is the default, all zeroes.
PCD: 5A FF FF FF
PICC: 00
PCD: 0A 00
PICC: AF EA 18 DE FF 52 0E CD 90 //B = A42F3E842C5A2968 Please verify these numbers are correct
PCD: AF 04 30 D7 63 E8 0E 43 1A 3D 09 69 AF 44 A2 70 D2 //A = 0123456789ABCDEF Please verify.
PICC: 00 33 00 70 A7 4A DF 17 00
PCD: CD 01 03 00 00 20 00 00
PICC: 00
PCD: BD 01 00 00 00 02 00 00
PICC: 00 EC 3B 5D E6 C6 1F 88 21
As you can see, decrypting EC3B5DE6C61F8821 with key 01234567A42F3E84, gives 41C415038EFE212B. This is clearly wrong since the block should be bytes of data, followed by 2 bytes of CRC and then padded with zeros.
just in case it might be relevant, here is what I receive when I perform a getVersion command.
AF 04 01 01 01 00 1A 05
AF 04 01 01 01 03 1A 05
00 04 50 3B 81 33 26 80 CF B6 D4 66 90 53 08
March 14th, 2011 at 20:54
Felipe,
your B is correct,but there is something wrong with your decryption of A.Are you sure that you get:
0430D763E80E431A when you decrypt: 0123456789ABCDEF,
because I’m getting different data.
Another thing is that you have chain both blocks of
byte using CBC before sending them to thePICC.But
first try to fix the problem with decrypting of A.
For this I’m getting : 3B 73 A1 53 75 7B 1A D8
March 14th, 2011 at 20:58
Sorry Felipe,the correct data
I’m getting is : 80 B1 7A B4 00 B2 B9 37
March 15th, 2011 at 03:19
wow,
thank you so much mustafa.
Here is what I was doing wrong in case anyone out there is having the same issue.
The IV never carries over from previous messages sent, it is always reset to 00000000000000.
So after the first decryption of e(B), what I did was keep B as the IV, then sending D1 = d(A xor B) to the PICC followed by D2 = d(D1 xor B’). What is truly curious is that the PICC’s response, in my line of thinking was valid. What the PICC was actually responding was e(A’), but I thought the PICC was responding A’ ^ B’, since B’ was, i thought, the IV.
Now, A’ xor B’ = (A xor B)’.
March 15th, 2011 at 02:34
Authenticated “Standard” DESFire OK
Read & Write Standard & Backup files Plain Mode OK
So I decide to create a DES encrypted Linear File
File Created OK
Write Data NOT OK
CRC32 must be inverted and bytes reversed from usual OK
Padding: The Card complained so I tried 28 Bytes (+4 bytes = 32, OK for DES)
Sent the data, card replied AF (More please)
Sent the More block, wrapped in iso7816
Sent: 90AF00002700000000200000491E890DE9ACE9320AA0DF24E9FE9CECF5B9424D66190FFD9C0695F2AB5DD7BC00
got …917E LENGTH_ERROR Length of command string invalid…
the apdu is OK what can they mean by “command String”??
Previous 90AF sends to PLAIN files went OK
Whatever I put in the data I get 917E, ie its not a decryption problem…
March 22nd, 2011 at 14:33
c t skinner,
The CRC is CRC16, the implementation is a bit odd, you can find it in the ISO 14443-3 specification. That is probably what is giving you the error. Also, try first sending a small message so that you don’t have to send additional frames.
March 22nd, 2011 at 14:36
CRC16 is discussed earlier in this thread and sample code has been posted.
March 22nd, 2011 at 11:26
Hi,
After some time I am now back to DESFire and I want to do some tests with SAM modules, where the keys of the reader will be hosted. I already have some SAMv2 modules and readers ready to work with them.
I have completed many times DESFire authentications, so I know the procedure. I also have read the SAM specification and communicate with it sending for instance the GetVersion command and getting the correct answer. I also know how the DESFire_Authenticate command works.
So now, my problem is that I don´t know how to make the DESFire tag and the SAM module work together. What I want is that when the reader detects a new tag to try to authenticate it using the keys that are stores in the SAM module.
Just for you to know, I am using Gemalto´s GemProx PU reader, which has 2 SAM slots
Thanks,
Bye
March 22nd, 2011 at 14:43
Gorka,
Unfortunately, I can’t really help you. But I would like to know how you obtained the SAM functional specification. Did you sign an NDA with NXP? If not, could you please tell me where I can find it? I’ve been trying to get a copy of the spec from NXP but they have been less than helpful.
March 22nd, 2011 at 16:15
Hi Felipe,
Yes, I obtained the SAM specification from NXP and I had to sign and NDA with them before. So, I cannot send you the spec, sorry.
March 22nd, 2011 at 15:07
Hi Gorka,
it is similar like communicating with Desfire directly.
The only difference is that you don’t need to make all
the decryption work for yourself but let it make the SAM module.You send the authentication command to the Desfire card,the answer which is encrypted RndB you
forward to the SAM module.From the SAM module you
will get decrypted RndA+RndB’ which you forward to the
Desfire card.This goes on until you get from the
Desfire card that the authentication is complete.Now
if you want to communicate encrypted with the Desfire
card you have first to send the plain data to the SAM
module and get the encrypted data which you forward to
the Desfire card.And send the encrypted data to the
SAM module to let it decrypt by the SAM module.
March 22nd, 2011 at 16:20
Hi Mustafa,
Thanks for your response. Yes, I supposed it should be that way, the problem I have is that I don´t know how to forward the challenge I get from the tag to the SAM directly without having to type it by myself. I guess somehow I have to install a script or something in the reader.
Anyway, I guess that what I have to read about is the reader, and not the specs of the DESFire and the SAM, because the problem is not in the commands I have to send to them, but in the way to communicate with both at the same time.
Thanks again.
Bye.
March 22nd, 2011 at 17:01
Hi again,
I forgot something. I don´t know what reader have you used, but I guess the way to work should be similar. Right now I am using the GUI application they gave me. So what I do is to initialize the 14443-A and the SAM module and complete all the Select procedure. Next I send an authentication request command to the tag, I get the challenge and then I copy it and paste it inside the command I send to the SAM. I get the response, copy it and paste it to the 14443-A management page, etc.
What I want to do obviously is to make all this procedure automatic, so that I don´t have to copy the responses by myself. How can I do that, with some kind of script, or application in C++ using the API they gave me?? In that case, I guess I should have to connect to the COM port where the reader is and then start sending Request commands until I detect a tag and send all the commands from the tag to the SAM and viceversa. Is that correct?
Thanks a lot for your time.
Bye.
March 22nd, 2011 at 20:15
Hi Gorka ,
I have used my own reader and programmed the
microcontroller by myself.For you are using the Gemalto
reader you can communicate with it via com port.You
must have got a protocol containing the command with
which you can program the reader.
Good luck.
March 24th, 2011 at 03:58
hi,
I have some trouble while Read/Write data to a standard file on the Desfire Ev1 card. When i using the DES key (default key) to Read/Write a file with communication setting (0×03), it seems good. I can Read/Write though the DES encryption. But while i change the key to 3DES. There is a problem. Here is my log.
Session key: 689739801798A3C7F51474E391161AD0
-> F501
BD01000000080000
3D010000000800002d21b790a3206306d607b4601f751bb8
(Send 8 byte data “0102030405060708″)
<- 917E(?)
Thanks.
March 24th, 2011 at 04:25
William,
The message you are sending is correct. Which means that the session key you are using is not right. Could you post a log of the authentication, and the session key you believe you generate. Also, be aware that the formatting in these comments has some quirks, so try not to use less than and greater than signs.
March 24th, 2011 at 07:23
hi Felipe,
Here is log of my session key general procedure. It is the same way but not same session key.
Key: 00112233445566778899AABBCCDDEEFF
RndA: 73F84DA38F00C5F8
PCD: 0A00
PICC: AFC29197BF294F8D1E ( RndB = A9D9A650ED69BD05)
PCD: AF3FB4E85D80A263BA51CF1AEF94B9F325
PICC: 00FD755A5AF48B9032
Session Key: 73F84DA3A9D9A6508F00C5F8ED69BD05
PCD: F501
PICC: 000003EEEE000400
PCD: BD00000000080000
PICC: 0000000000000000 (Why not encrypted?)
PCD: 3D000000000800009452d9941cbded3a75629ac35d80e3a1
PICC: 7E (Lenght_Error?)
March 24th, 2011 at 17:41
William,
The reason you receive the data in plain mode when you read the file is because the access rights of the file are set to EEEE. This means that there is free access for to every operation on the file. Try setting the access rights to a specific key and you shouldn’t have a problem.
March 25th, 2011 at 02:33
Felips
It works. Thanks.
By the way, do you know how to use AES on the card?
March 25th, 2011 at 03:02
William,
I haven’t dealt with the new EV1 features in depth. I do know that when using AES, CRC32 is used instead of CRC16, and I believe CMAC is used instead of MAC.
If you do not have access to the documentation, your best resource is the libfreefare source code.
http://code.google.com/p/nfc-tools/source/browse/trunk/libfreefare/libfreefare/mifare_desfire.c
March 28th, 2011 at 13:27
Hi
My project is creating a mobile payment application with NFC.We bought a reader (Obid Classic-pro(HF) ID Cpr40.30-usb) and Mifare tags. I am using Mifare DESFire because i think it is the most adequate transponder for payment. My problem is i am not able to run the DESFire commands because of the crypto processing errors. According to my reader’s manual, the reason of error is transponder. Desfire error codes which i am getting is usually 0x9D, 0xA0, 0x1C. I am using AES keys for authentication. I will send a video to you (The link is below). I am doing the same things exactly with the man in the video but he can run read and write processes successfully, i can’t because of the errors that i mentioned before.
http://www.trikker.fi/downloads/Desfire EV1_Tutorial_640x480.mp4
If you have any idea about my problem and its solution, please contact and help me.
April 14th, 2011 at 13:40
how can i define a key for an application or file?
For example i am creating application with this APDU
CA 563412 0F 8D
I found it from somewhere i can’t remember. The explanation is
Create Application – ID=0×123456 – ApplikationMasterKey Settings=0x0F – AES encryption with 14 keys
I understand that 563412 is application id, i didn’t understand the meaning of 0f and 8d. i am using AES keys for reader.
And i am creating file with this APDU
CD 01 03 3412 FF0000
CreateStdDataFile : FileID = 1 – Communication Settings = 0×03 (AES Enryption) – AcessRights 0×34 0×12 [Read(Key)=1 Write(Key)=2 R/W=3 Acess=4] – Length = 255
Here 01 is file ID, 03 again i am not sure what is it, and i have no idea about access rights. I am using them for reading or writing the card as desfire key number. For reading 01, writing 02…
After all i am getting 1C error-illegal command code.
I don’t know where is the error but i guess it is about defining keys for the cards.
Are these APDU’s true? If it is true what should i do as an extra for defining keys to card.
I need your answer.
If anyone understand my problem, you can contact me from serayozdemir@hotmail.com or serayozdemir@gmail.com
April 14th, 2011 at 20:00
1. 8D means number of keys (it defines how many keys can
be stored within this application).
2. Meaning of application masterkey (0X0F) :
Bit7-Bit4 :
0X00 :Application masterkey
authentication is necessary to
change any key (default)
0X01-0X0D :Authentication with the specified
key is neccassary to change the key
0X0E :Authentication with the key to be
change is necessary to change the key
0X0F :All keys within this applications are
frozen
Bit 3 :
0 : configuration not changeable
anymore
1 : configuration changeable
Bit 2 :
0 : Create file and delete file
is permitted only with
authentification with appl.master
key
1 : Create and delete file without
authentification
Bit 1 :
0 : Application master key authentification
is necessary for GetFileID,
GetFileSettings and GetKeySettings
1 : Authentication not necassary to execute
the above commands
Bit 0 :
0 : Application master key nomore
changeable
1 : Application masterkey changeable
3. The meaning of communication settings :
0 : Plain communication
1 : Plain communication with DES/3DES
MACing
3 : Fully DES/3DES encrypted communication
June 3rd, 2011 at 06:58
Hello,
does anybody have some hints how to calculate a CMAC with AES Cipher in Java. I tried to follow an example from NXP with the SDK from bouncycastle but i wasn’t able to get the right values. I would be very grateful.
Stefan
June 21st, 2011 at 16:19
Hello
This blog is very interesting. I have found no more information on APDU commands on internet, thanks for your work.
I’m working on this kind of project. I need help. I hope you could read this.
Here are two file settings.
Get file setting for file 0C
– CLA=90, INS=F5, P1=00, P2=00, LC=01, LE=00
– DATA=0C
Response APDU:
– SW1=91, SW2=00
– DATA=0000317F200000
Get file setting for file 01
– CLA=90, INS=F5, P1=00, P2=00, LC=01, LE=00
– DATA=01
Response APDU:
– SW1=91, SW2=00
– DATA=0101417F800100
I am in the 108057 application (Transport NF).
I know that I have to authentificate with key 07 of this application.
So I do :
– CLA=90, INS=0A, P1=00, P2=00, LC=01, LE=00
– DATA=07
Response APDU:
– SW1=91, SW2=AF
– DATA=F7 9A BB 80 7C E4 85 BA
The problem is that I don’t understand what I must do after this. On your page, we writted this :
Authentication with key 00 (for PICC Application):
–> 0a 00
af b0 cc bc ed 8f c8 38 c9 08 dc e2 4d 86 ca ec 3c
f5 0c
bd 0c 00 00 00 10 00 00
<– 00 90 80 00 02 XX XX XX XX 6c 68 00 28 00 02 80 40
Could you tell me why there is " 00 00 00 10 00 00 " after0C, please ?
Thanks.
Marc
June 22nd, 2011 at 04:26
I don’t think you read the blog post correctly.
The authentication goes like this
Reader: 0a 00
Card: af a2 be cd 03 d8 46 cb 33
Reader: af b0 cc bc ed 8f c8 38 c9 08 dc e2 4d 86 ca ec 3c
Card: 00 76 73 d9 49 71 3f f2 d1
June 22nd, 2011 at 05:54
Oh sorry. My message isn’t clear.
There are two questions :
– concerning Authentification :
I don’t understand why it goes like
Reader: 0a 00
Card: af a2 be cd 03 d8 46 cb 33
->Reader: af b0 cc bc ed 8f c8 38 c9 08 dc e2 4d 86 ca ec 3c
can you tell me why this parameter ?
Card: 00 76 73 d9 49 71 3f f2 d1
- Moreover, when we want to read data in a file. I don’t understand the parameters.
bd 0c 00 00 00 10 00 00
<– 00 90 80 00 02 XX XX XX XX 6c 68 00 28 00 02 80 40
Thanks
June 22nd, 2011 at 06:29
lets say both the reader and the card have a shared DES3 key.
Remember that the card can only perform encryption.
Reader: 0a 00 (Authenticate with key 0)
Card: af a2 be cd 03 d8 46 cb 33 (sends e(B), where B is a random 8 byte number)
Reader: af b0 cc bc ed 8f c8 38 c9 08 dc e2 4d 86 ca ec 3c (reader generates random A and sends d(A) = b0 cc bc ed 8f c8 38 c9, followed by d(B’) using CBC = d(d(A) xor B’) = 08 dc e2 4d 86 ca ec 3c)
Card: 00 76 73 d9 49 71 3f f2 d1 (This is e(A’))
the reason why the card has to send e(A’) is to assure the reader that the card has the appropriate key. If someone were to be monitoring the communication between card and reader, they could use the same B (generated by the card) every time. And without knowing the key, complete a successful authentication. If the Card has to send e(B’) then knowledge of the key is necessary.
When reading data from a file
bd 0c 00 00 00 10 00 00 (0c specifies the file number, 00 00 00 specifies the starting index, 10 00 00 specifies the number of bytes to read. So this command reads 16 bytes from file 0x0C starting at index 0.)
<– 00 90 80 00 02 XX XX XX XX 6c 68 00 28 00 02 80 40
June 22nd, 2011 at 06:40
Thanks a lot.
So I have not the key #7 for this application.
I can’t read more concerning the file of this application.
What a pity.
June 23rd, 2011 at 09:08
hey
Just a little question more.
Do you think there is a error counter for the authentification ? I mean if I try wrong key for the authentification. There is no documentation about that.
I don’t want to block my card ^^
Thank.Bye.
June 23rd, 2011 at 11:34
No, it’s not documented and testing would appear to confirm that it’s OK to fail auth as often as you like. I just ran the following script:
$ while [ 42 ] ; do desfiretool.py 1 select 000000 auth 00 1122334455667788 ; done
which (repeatedly) gave the result:
Using reader: OMNIKEY CardMan 5×21 (OKCM0022602100142172731750393654) 00 01
Card UID: 80D9EB58
Selecting AID: 000000 (OK)
Authenticating against Key 00 with key: 1122334455667788 Failed: Authentication error
I then did:
$ desfiretool.py 1 select 000000 auth 00 0000000000000000
which gave:
Using reader: OMNIKEY CardMan 5×21 (OKCM0022602100142172731750393654) 00 01
Card UID: 80D9EB58
Selecting AID: 000000 (OK)
Authenticating against Key 00 with key: 0000000000000000 (OK)
So i guess you’re OK!
July 9th, 2011 at 17:02
Hi guys,
From beginning i would like to thank you all, especially Ridrix for all the information above. And of course I need help
. It’s about documentation, I have ISO 7816-1,4,6,7,8,9, I have access to the NXP documentation. About NXP documentation, I don’t know which documents are relevant for me. I’m working with DESFire EV1, and so far I consider being important on NXP just these documents:
from
http://www.nxp.com/#/homepage/cb=t=p,p=/53420/71108/53422/53450|pp=[t=pfp,i=53450]
just document MF3ICD4101DUD
and from
http://www.nxp.com/#/pip/pip=pip=MF3ICDX21_41_81_SDS,pfp=53450|pp=[t=pip,i=MF3ICDX21_41_81_SDS]
protected archives (at the bottom of the page)
- DESFire & DESFire SAM, Reader Software Library, Programmer’s Reference Manual
- DESFire ev1 Reader API
I suppose, there is much more, I just don’t know which ones. Could you guys post url’s of other relevant NXP documents(about authentication, creating application, …)
About ISO/IEC 14443, I suppose, I’m gonna need parts:
3 – here supposed to be information about cryptography and
4 – here supposed to be commands description
Is that right?
Other sources I could use are:
http://code.google.com/p/nfc-tools/wiki/libfreefare
http://www.developer.nokia.com/Resources/Learning/
http://www.nfc-forum.org/home/
http://www.cryptopp.com/
http://msdn.microsoft.com/en-us/library/aa924246.aspx
do you have any other useful sources?
Thanks
Jan
July 10th, 2011 at 17:26
Those links are not working, this hopefully is gonna:
http://www.nxp.com/#/ps/ps=i=53450|pp=[t=pfp,i=53450]
for second link you click on MF3ICD4101DUD document
or here is the path:
Identification and security / Smart card ICs / MIFARE smart card ICs / MIFARE DESFire
September 23rd, 2011 at 19:44
[...] Desfire cards to be used with PCSC readers. It is based on Desfire Functional Specification and this post has been very helpful. More news coming soon. Share this:TwitterFacebookLike this:LikeBe the [...]
September 26th, 2011 at 17:10
Hi.
First of all thanks for that blog that definitely helped me a lot.
Yet I still have an issue…
I’ve successfully performed an authentication (after PICC selection) with key-00, retrieved the key settings (0x0f) and I now would like to change it to 0x0e with the ChangeKeySettings command and I constantly get the INTEGRITY_ERROR (0x1e)… whatever I try.
Here is what I do:
* new key settings = 0e
* CRC16 = 80 b8 (0xb880)
* data buffer = 0e 80 b8 00 00 00 00 00
* decrypted data buffer (key-00) = 3c 5b 1b 80 4a 1d a0 1b
* data sent to card = 54 3c 5b 1b 80 4a 1d a0 1b
* card answer = 1e
I’ve been looking for days and can’t figure out what’s wrong with that.
Could you give me a hint?
Thanks,
Alex
September 27th, 2011 at 15:31
Hi Alex
it seems to be O.K. what you have done.Let me see your key and session key.Possibley they are not O.K.
Mustafa Moripek
September 27th, 2011 at 16:02
Oh… should I DES decrypt with the session key and not the key I’ve done the authentication with (key-00) ?
key-00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
sess. key: 88 ee b3 a9 4b 31 a3 20 64 3d 3e d0 ce e6 ca 6d
If I use the first half of the session key to DES decrypt the data buffer I get the following: b3 47 98 a6 35 63 21 99
Anyway… still get the integrity_error…
Thanks,
Alex
September 28th, 2011 at 15:59
Hi
Yes you should single DES encrypt with the session key.But your session key is wrong.
If the first half of the key you are authenticating with is equal to the second half of the key,you have to build your session key eight byte long.For you are using the default key all zeroes the first half is equal to the second half.For building the session key you have to put the first half of RndA and RndB together and use this session key for single DES
encrypting.
Good Lock.
Mustafa Moripek
September 29th, 2011 at 15:48
Problem fixed, thanks a lot for your information
October 12th, 2011 at 14:19
Hello everyone,
The information here is very helpful. And I really appreciate your great effort to aggregae useful information here. (many important notes, test vectors and links.)
BTW, I am writing a Desfire_lib in Java. And thanks to this blog, I am almost done except for two thing. KINDLY HELP ME!!!
I succeeded in Authentication, ChangeKeys, etc. in both DES and T-DES using NFC reader (ACR122U) in ADPU wrapping mode. (on Windows XP+PC/SC)
Issue-1
Read/Write to MACed file is OK.
But problem is, I need to send MAC data (4 bytes) in separate ADPU Write packet. (orginal msg and MAC) Why can’t I send it in ONE flame???
Issue-2
I cannot Read/Write DES file.
(Always result in “INTEGRITY_ERROR (CRC or MAC does not match.)”)
1) plaindata ={0×00 11 22 33 44 55 66 77 88 99}
2) CRC_16(plaindata)={0x 84 EB)
3) msg_w_pad = {0x 00 11 22 33 44 55 66 77 88 99 84 EB 00 00 00 00}
4) Decrypt_CBCSendMode(msg_w_pad, key {0x 01 23 45 67 89 AB CD EF}) /* Single DES in this case, key should be session key */
5) DES_msg ={0x 8C 77 40 7E 02 4F 66 AD 43 1F F2 01 FA C5 1F 5C}
Then send WriteData(DES_msg) ADUP paket.
BUT PICC still response “AF” for further data.
So I added zero_packet (0x 80 00 00 00 00 00 00 00), but it doesn’t work.
What is expected for the last packet??
Thank you very much for your kind guidance in advance!!!
November 3rd, 2011 at 09:54
Hi @all
this blog helped me a lot with my desfire implementation, but have some problems with desfire ev1 – AES Authentication. (des works fine, creating apps, file, etc). I always got AE – Authentication Error. I guess my encrypted Randoms are wrong but don’t see the problem. Maybe you can help: (Got a empty Card with Standardkeys.)
Select Application
=> 5A 00 00 01
AA 00
92 af 3c 21 9a 30 7d 66 74 ca 27 a2 c6 4d 9b 73
Then Leftshift by 8 Bit
=> af 3c 21 9a 30 7d 66 74 ca 27 a2 c6 4d 9b 73 92
Now “generate” RndA
=> 00010203040506070001020304050607
Now Encrypt RndA and RndB’
XOR after encryption with 16 x 0×00
crypto_1 => 26 16 77 8a db a8 4f 38 ee 32 87 9a 29 98 13 55
XOR after encryption with RndA
crypto_2 => 3f 0c c4 14 20 e1 9f 6f 1c b2 1c 5d 24 21 fd d6
Send enc(RndA || RndB’)
=> AF 26 16 77 8A DB A8 4F 38 EE 32 87 9A 29 98 13
55 3F 0C C4 14 20 E1 9F 6F 1C B2 1C 5D 24 21 FD
D6
<= AE
Any ideas?
November 10th, 2011 at 12:00
For your interest. I’ve found the problem: The not (or bad) document IV-handling. In DES Authentication you reset the IV always to 0×00. In AES your IV for your encryption is the Enc(RndB) and for Decryption of RndA’ u use crypto_2.
With the right session key generation my ChangeKey Command worked, too
November 22nd, 2011 at 14:07
Hi!
I’m playing with Desfire EV1. DES/3DES authentication and data handling is working perfect. I manage to change MasterKey to AES (for MasterKey it will be key no $80), but now I’m not able to login into my card anymore.
Please find attached my session with Desfire Ev1:
MasterKey: 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
>> AA 00
<< AF 70 3A C2 8A 14 25 27 07 5F BA 0E 9B D7 C9 87 E0
——–
Enc(RndB) = 70 3A C2 8A 14 25 27 07 5F BA 0E 9B D7 C9 87 E0
After DECRIPTION with AES 128 (IV=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00) – is IV correct?
RndB = 94 C8 15 B4 E9 D3 19 EF D0 4F 8A 33 CF 8D C3 93
Now I rotate left by 8 bits
RndB' = C8 15 B4 E9 D3 19 EF D0 4F 8A 33 CF 8D C3 93 94
My 'random' RndA will be:
RndA = 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Now I have to send to PICC following command:
AF enc(RndA) enc(RndB') – Is this correct?
enc(RndA) will be ENCRYPTED RndA with MasterKey, but what IV vector schould I use?
enc(RndB') will be ENCRYPTED RndB with MasterKey, and IV vector schould be enc(RndA). Is this correct?
Maybe someone can post full authentication session with AES key, so I can check my application.
Regards!
November 21st, 2011 at 13:46
Hi,
can anyone tell me how can i calculate the CMAC to be sent after a changekey command ?
thxs
November 26th, 2011 at 01:10
Hello there!
After a while without working on smartcards, here im back again with one (and night-skipping) doubt.
I am trying very hard to make a C# polling mechanism work together with the GetVersion APDU wrapped desfire command without success.
My scenario:
I am using C# and P/Invoke to access the reader and smartcard (Mifare DESFire EV1 2/4/8K).
I am using the APDU to wrap the GetVersion Command (90 60).
I can successfully execute the getversion againts the card. Even several times (I have tried a for loop with 500 requests). Everything is working fine.
My problem is: I need to implement a polling mechanism to monitor for card presented/removed events from reader.
I am running this “polling” on another thread (have tried new Thread, background worker, etc).
The problem is: When I run the GetVersion APDU command against the card while I am inside the polling mechanism, I receive a “91 1C” response from the card.
91 1C means: ILLEGAL_COMMAND_CODE (Command not supported).
This usually happens while sending the second frame of 0xAF (to retrieve more data).
Im getting tired of this error and have tried several tricks (lock, AutoResetEvent and many others on C# and .net) to avoid this problem without success.
I sincerely hope someone can help me on this!
Cheers budys!
Bruno
November 26th, 2011 at 16:43
Just to add one more heads up:
If I insert a Thread.Sleep of 400ms between the connecting to card (with SCardConnect) command and the DESFire GetVersion command it works like a charm!
Weird. Is that a expected behavior?
Bruno
November 30th, 2011 at 20:45
Hello: I’ve written a Python implementation (an example) of AES-128 simmetric key diversification as described in document AN10922. In case you think it might be useful, here’s the link: https://gist.github.com/1409585
December 31st, 2011 at 04:12
Hi all,
If you are working on Desfire EV1 AES authentication (i.e. 0XAA), you can follow the following algo and it works
http://books.google.com.hk/books?id=RptQEcaQtJ4C&lpg=PA196&dq=desfire%20aes&hl=zh-TW&pg=PA197#v=onepage&q=desfire%20aes&f=false
February 21st, 2012 at 09:05
Hi ridrix,
I have stucked with the Desfire Authentication Command.
I have shown below the APDUs
->0A 00
AF C5 34 FC 90 76 C6 4C 62 65 7A D2 9E 4D 4D CF 58
<- AE
Key : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
IV : 00 00 00 00 00 00 00 00
Can you tell me whats the wrong with this ?
Thanks
Amila