NFC通信 - Mifare DESFire EV1 - AES

我正在使用HID Omnikey 5321閱讀器與Mifare DESFire EV1標籤進行通信。我想在標準數據文件中寫入16個字節。我正在使用WinSCard DLL（C++）在ISO 7816 APDU消息結構中封裝Native DESFire命令。應用程序選擇和身份驗證已成功完成，但是我有Write Data命令的問題。該文件的通信設置被設置爲AES，完全加密。NFC通信 - Mifare DESFire EV1 - AES

File Nb   : 00 
Offset   : 00 00 00 
Length   : 10 00 00 (LSB first) 
Data (16 bytes) : 23 00 00 00 00 00 00 08 12 34 56 78 00 00 00 00

我從本地命令計算CRC：

Native command : 3D (File Nb) (Offset) (Length) (Data) 
CRC = 7B 8A 60 0F

然後我加密被與所述會話密鑰和IV組爲00：

32 bytes data to encipher : (Data) (CRC) 80 00 00 00 00 00 00 00 00 00 00 00

APDU sended：

90 3D 00 00 27 00 00 00 00 10 00 00 (32 bytes enciphered data) 00

對此，我得到一個「1 E「狀態碼，表示CRC或填充錯誤。我不知道問題在哪裏，AES加密算法似乎很好，因爲我設法讀取數據。

它可能是CRC或IV。我需要與CMAC的XOR數據嗎？

來源

2014-05-13 VTerrien

只是一個想法，可能是CRC有不同的字節順序？ –

libfreefare CRC計算給了我'30 D2 07 00'該命令+頭+數據。另外至少在數據手冊中說，具有已知數據長度的命令應該只使用'0x00'來填充（儘管我不得不承認數據手冊的不同部分在這裏是不明確的，但是它對於寫入命令是明確的）。 –

感謝您的幫助，我設法寫入數據：我改變了計算CRC的方式，它給了'30 D2 07 00'，我也填充了'0x00'。 – VTerrien

您使用的CRC是錯誤的。對於你在你的問題中顯示的命令，命令+標題+數據上的CRC應該是30 D2 07 00。

此外，小心你必須做填充的方式。 DESFire EV1數據表不明確。雖然關於AES加密的部分建議CMAC填充應始終與AES一起使用，但填充部分指出具有已知數據長度的命令應該用全零填充，而具有未知數據長度的命令應該用0x80填充，其後用零填充。最後，關於write命令的文檔明確指出write命令應該填充全零以進行加密（這就是你應該做的）。

來源

2014-05-16 20:57:28

我設法在現有文件中寫入數據，但是當我在應用程序中創建文件時，我會得到一個「1E」狀態碼。 – VTerrien

我認爲這可能是錯誤的IV。我應該如何計算它？它必須設置爲16 00 – VTerrien

你可能想看看[那個答案]（http://stackoverflow.com/questions/20503060/how-to-decrypt-the-first-message-sent-from-mifare-desfire -ev1/20504667＃20504667）如何初始化IV。此外，我建議您查看libfreefare實現，因爲這可能會提供大部分（所有？）所需的功能。 –

NFC通信 - Mifare DESFire EV1 - AES

回答

相關問題