6

Nexus 4 と最新の Android API レベル 18 を使用して Mifare DESFire EV1 AES タグと通信すると、頭が痛くなります。このタイプのタグを読み書きするには、NXP ネイティブ プロトコルに従って、次の手順に従う必要があります。

  1. アプリケーションを選択
  2. 認証する
  3. 書き込みまたは読み取り

そのために、ISO 14443-4プロパティと I/O 操作へのアクセスを提供する Android のIsoDepクラスを使用します。非常に奇妙な点は、select application ネイティブ コマンドを送信すると、予期しない応答が返されることです。私がAIDを持っていると想像してください。F4013D

-> 5AF4013D
<- 6E00

考えられるすべての応答は、1 バイトの長さ (success0x00または error_code) である必要があり、2 バイト以上であってはなりません。したがって、0x6E成功応答の前はまったく予想外です。常に発生するとは限りません。発生せず正常に動作する場合、アプリケーションの選択と認証プロセスは正常に動作します。ただし、一度認証された書き込みコマンドは正しい動作をしません。すべての書き込みコマンド0xAFは、成功の代わりに PICC からの で終了します0x00。PICC は、予期しないときに余分なデータを予期しているようです (正しい長さのペイロードを送信します)。他のコマンドを送信すると、0xCA(Command Aborted) エラー コードが表示されます。

-> 5AF4013D
<- 00 /*Success*/
-> AA01
<- AFA8394ED57A5E83106B4EE72FD2BB0CC4
-> AF148F525E1DDE0AD6AB60B4B615552475C91F2E8D89B8523E4465113DD5BD19C6 
<- 0066D255C93F2F492AFE3715C88964F1BD /*Authentication success*/
-> 3D02000000030000222222 /*Write 3 bytes to file nº2*/
<- AF /*Unexpected, 0x00 was expected*/

通常、これらのタイプのコマンドを個人用リーダー (非 Android NFC) で送信すると、常に正常に動作します。Android NFC API の何かがおかしくなっているようです。データを解釈したり変更したりしない生のデータ トランスポーターである必要があります。

ISO 7816-4 APDU 構造でも試してみましたが、同じ結果が得られました。興味深いことに、Galaxy Nexus では select アプリケーションの奇妙な応答は発生しませんが、書き込みコマンドは常に 1 つです。

4

1 に答える 1

9

(1) ステータスコード 6E00 に関する最初の部分:

6E 00「奇妙なバイト0x6E+ 成功ステータス コード0x00」ではありません。代わりに、応答 APDU ステータス ワード6E 00(「クラスはサポートされていません」) です。これは、以前に APDU ベースのアクセスを使用したカードとの通信があったことを示しています (たとえば、Android 自体がカードを Type 4 タグとして読み取ろうとし、その後接続をリセットしませんでした)。したがって、カードは、以降のすべての通信が ISO 7816-4 APDU であると想定します。その場合 (つまり、 のような ISO 7816-4 ステータス コードを受け取った場合6E 00)、ネイティブ コマンドをラップするだけで、DESFire APDU でラップされたコマンドを引き続き使用できます。

編集:実際、これは NFC デバイスで想定される動作です。NFC デバイスは、NDEF メッセージの検出されたタグを自動的にスキャンするという考え方です。DESFire カードの場合、NFC デバイスはそのカードを潜在的なタイプ 4 タグとして検出します。したがって、NFC デバイスは、他のタイプ 4 タグに送信する場合と同様に、ISO 7816-4 APDU を送信します。したがって、NFC デバイスが、検出されたタグをアプリに渡す前にタグとの通信をリセットしない場合、アプリは ISO 7816-4 APDU を使用してのみ通信できます。ただし、これが同じデバイスの一部のアクティベーションでのみ発生するのはバグだと考えていることに注意してください。私の意見では、1 つの特定のデバイス モデルでの動作は一貫している必要があります。

編集:この動作をバグとは考えていませんが、実際には、Broadcom NFC コントローラーを搭載したデバイスの Android の NFC スタックの既知のバグ ( #58773 ) が原因です。影響を受けるデバイスでは、自動プレゼンス チェックにより一定の間隔で ISO 7816-4 APDU が送信され、DESFire カードが ISO 7816-4 APDU モードに切り替わります。

(2) (予期しない) 応答コード 0xAF に関する 2 番目の部分:

ファイルの通信設定が「MAC で保護されたプレーンな通信」または「完全に暗号化された通信」のいずれかに設定されている可能性がありますか? その場合、単に 3 つのデータ バイトを送信するだけでは十分ではありません。代わりに、プレーン データに MAC を加えたもの、または埋め込み、CRC、暗号化されたデータのいずれかを送信する必要があります。したがって、0xAFカードがさらにデータを期待していることを示します。

編集：以下のコメントを要約します。0xAFさらにバイトを送信した後 (受信したステータス コードごとに一度に 1 バイト: AF FF)、カードがさらに 8 バイトを予期していたことが判明しました。8 バイトは、AES 認証の CMAC のサイズとまったく同じです。したがって、通信設定は「MACingによって保護された平易な通信」に設定されました。

于 2013-10-25T15:03:00.827 に答える