問題タブ [tlv]

非接触 EMV カードに送信される、正しくフォーマットされた GET PROCESSING OPTIONS コマンドを作成しようとしています。この投稿は非常に役に立ちましたが、もう少し詳しく知る必要があります。

PDOL を解析するとき、各タグの長さが 2 バイトで、その後に返されるデータのサイズが続くと想定しても安全ですか?

たとえば、PDOL9F66049F02069F37049F1A02は 、 などに分割され 9F66 04、9F02 06それぞれに 2 バイトのタグと、予想されるデータ値の長さの 1 バイトが含まれます。

解析時に各タグの長さが 2 バイトであると想定しても安全ですか?

に Telium アプリケーションを実装するために Ingedev に取り組んでいますC。

Ingenico デバイスとの非接触型 EMV カード トランザクションからアプリケーション プロトコル データ ユニット (APDU) を読み取るにはどうすればよいですか?

デバイスとカードの間で交換される TLV ツリー データから APDU を取得できますか? もしそうなら、これはどのように達成されますか？

Java Card (NXP JCOP J3D081、JCOP バージョン 2.4.2、Java Card バージョン 3.0.1 Classic) で TLV エンコードされた証明書を読みたいと思います。

cap ファイルは正常に作成されますが、カードにインストールしようとすると、gpshell エラーが発生します。

load() は 0x80206A80 を返します (6A80: 間違ったデータ / コマンド データの値が正しくありません。)

私は JCDK 3.0.3 の jar を使用していますが、これは通常、楕円曲線などで機能します。TLV のものと何が違うのでしょうか?

使用したアプレット コード (BERTLV を使用しない場合は正常にインストールされます):

次の ant build.xml を使用して cap ファイルを作成します。

使用される build.properties:

そのため、キャップが api_connected.jar でコンパイルされていると思われましたが、キットからファイルを削除しても何も変わりませんでした。

どんな助けでも大歓迎です。前もって感謝します、トーマス

次の検証シナリオを実装するための最良のパターン (可能であれば、4 本のギャングから) を考えています。

TLV (Type Length Value) と呼ばれるオブジェクトがあるとします。それは次のようになります。

このオブジェクトには、同じタイプのサブ オブジェクト、つまりサブ TLV を含めることができます。つまり、Value フィールドには、サブ TLV を含む可能性がある ByteBuffer があります。
ここで行う必要があるのは、特定のサブ TLV のみが既存の TLV の一部になる可能性があることを確認することです。つまり、メイン オブジェクト タイプに特定のサブタイプ、つまりサブ TLV のみを含めることができるというチェックを実装する必要があります。

TLV オブジェクトは、流体インターフェイスを使用して Builder パターンを使用して作成されます。その後、ツリーのようなもの、つまり tlv 内の tlv を構築するために Composite パターンを使用するというアイデアが生まれました。ただし、そのような構造を最適に検証する方法と、それが最適な設計であるかどうかについては、依然として疑問が残ります。

この質問は、適切な検証手法を実装する方法に関するものです。たとえば、統計的な関連付けを作成することを考えていました->各「タイプ」（整数）番号には、 List などのJava構造に静的に入力されたサブタイプ（整数）番号があります。次に、そのリストのクイック検索に基づいて、分析されたサブ TLV タイプが静的に事前に型指定されたリストにあるものと一致するかどうかを見つけることができます。これは機能しますが、TLVとJavaを使用するときに信頼できる、より優れた/よりスマートな検証設計パターン/手法があれば、私は好奇心旺盛でした。おそらく、他の人がその目的のためにすでに正確に使用しているパターンがあるでしょう。

私が最初にうまくいくと思った別の方法は、Java インターフェイスに依存し、クラスをある種のタグとしてタグ付けするためにそれらを使用し、サブ TLV の型を反復処理してそれらを構築し、それらが特定のインターフェイスを実装しているかどうかを調べることでした。これは、サポートするそれぞれの異なる TLV タイプを表す少なくとも 1 つのクラスを手動で作成する必要があることを意味します。私の場合、それらは何千もの可能性があり、悪夢になるコードになる可能性があるため、それは実現可能ではありません.

アイデア/テクニックは大歓迎です。

私は単純な JavaCard HelloWorld スクリプトを持っています。仮想リーダーを使用して JCIDE で実行し、pyapdutool から apdu コマンドを送信します。私の質問は、その応答の代わりに tlv 形式のデータを返すにはどうすればよいですか? 私はこれについて emv book 4.3 を調べていましたが、Google でも、javacard スクリプトで emv tlv タグを実装する単一の例が見つかりませんでした。誰かがこれを理解するために私を正しい道に導くことができますか?

要するに、次のような形式で応答を送信できるようにしたいのですが、次のようなものです。

Android デバイスの NFC ツール アプリを使用して (組み込みの NFC リーダーを介して)、Mifare Classic 1K タグにテキストを書き込みます。このテキストは「moretto」（私の名字）です。

次に、ACS が提供するライブラリで NFC リーダー ACR1255U を使用して、このテキスト (NDEF 形式) を読み取ろうとしています。

私は以下を得ることができます：

ブロック 4 の読み取り:FF B0 00 04 10応答:0000030ED1010A5402656E6D6F726574 9000

ブロック 5 の読み取り:FF B0 00 05 10応答:746FFE00000000000000000000000000 9000

私はそれFEがコンテンツの終わりを示し、6D6F726574746F私のテキストであることを知っています. しかし、テキストの開始位置を特定するにはどうすればよいでしょうか。NXP のドキュメントに記載されている TLV 形式を理解するのが困難です。