1

NXP MiFare Ultralight C で認証しようとしています。私の NFC タグ リーダーは Android フォン (Samsung Galaxy Express) ですが、Windows 7 マシンで C# と System.Security の関数を使用してすべての暗号化を行っています。 .暗号ネームスペース。

私はUltralight -C の完全なデータシート (NDA の下) を持っています。それらを理解することは私の問題ではありません（私は考えていません）-暗号機能から期待するものを取得していません。タグの詳細については少し慎重になる必要がありますが、タグは私の問題ではないと思います.

基本的に何が起こっているかというと、認証を開始し、タグから期待されるデータを取得します。私は自分の側で [もの] を行い、Android で Nfca.Transceive() を使用してタグに応答を送信します。その関数はすぐに「送受信失敗」例外をスローします。これは、タグが飛躍するように指示していることを意味します。Transceive() を使用するその他の試みは成功します (書き込み、認証の開始など)。

グーグルで見つけた唯一のテストベクトルを使用したときに、私のコードが期待したものを生成していないため、タグがそれをキックバックしていることは驚くことではありません.

NDAのため、それは秘密ではないので、おそらく3DES側に固執するのが最善です...これらは私がオンラインで見つけたテストデータからのものです:

ek(Data) が 63FC19906A77D13F で k が 49454D4B41455242214E4143554F5946 の場合、dk(Data) は c00c24ed61ea0f3e である必要があります

これは、基本的に次のようなコードから取得したものではありません。

byte[] key = new byte[16] 
                {                 
                    0x49, 0x45, 0x4D, 0x4B, 
                    0x41, 0x45, 0x52, 0x42, 
                    0x21, 0x4E, 0x41, 0x43, 
                    0x55, 0x4F, 0x59, 0x46
                };

byte[] initVector = new byte[8];

byte[] encrypted =  new byte[8] 
                {
                    0x63, 0xFC, 0x19, 0x90,
                    0x6A, 0x77, 0xD1, 0x3F
                }

byte[] result = DecryptSingleBlock(encrypted, key, ref initVector);

この時点で、結果にはテスト データからの結果が含まれていることを期待して c00c24ed61ea0f3e いますが、そうではありません。その値は次のとおりです。 5bdd317111226152

私の復号化機能:

public byte[] DecryptSingleBlock(byte[] input, byte[] key, ref byte[] initVector)
{


    using (var des = new TripleDESCryptoServiceProvider  
                         {
                             IV = initVector,   // all zeros this time
                             BlockSize = 64,
                             KeySize = 128,
                             Mode = CipherMode.CBC,
                             Padding = PaddingMode.None,
                             Key = key,
                         })
        {
            byte[] output = des.CreateDecryptor().TransformFinalBlock(input, 0, 8);

            return output;
        }
    }

私は持っている：

  • 暗号化されたデータのバイトの順序を逆にしました。
  • キーの最初の 8 バイトを 2 番目の 8 バイトと交換しました。
  • FeedbackSize をいじりました (ただし、NXP が何を期待しているか、またはこれが CBC モードに適用可能かどうかについては非常に不明です (それ自体は、この単一ブロックの復号化には適用されません)。
  • CreateDecryptor の代わりに CreateEncryptor を使用しました。
  • LibFreeFare コードの意味を理解しようとしましたが、それはより多くのことをカバーしています - 私はこのステップを乗り越えようとしています.

私は途方に暮れています。指定された入力とキーに対して「c00c24ed61ea0f3e」を返すために上記の関数に何をする必要があるか、誰かが知っていますか? NXP が行っていることを見落としているのか、.NET に 3DES を実装する特別な MS-tastic の方法の犠牲になっているのかはわかりません。私の直感は、エンディアンの問題がどこかにあることを教えてくれますが、私が試したこと以外に、どこで何をすべきかわかりません。

正直なところ、既知の優れたテスト ベクトル (A、B、K、ek(xx+xx)) を取得して、タグを混在させる前にコードを機能させることができれば幸いです。NXPにこれを依頼しましたが、彼らは8時間先なのでまだ応答がありません.とにかく、彼らの通常の応答がどれくらい長く、彼らが助けられるかどうかはわかりません.適切な人に。

別の方法として、ステップバイステップの認証アプリケーション ノートを知っている人がいる場合は、DocStore から入手できます。それも役に立ちます。繰り返しになりますが、私は Ultralight-C と DESFire の両方の NDA を締結しているので、何を求めればよいかがわかれば提供してくれると確信しています。

ありがとう！

4

1 に答える 1

3

さて、純粋なマネージド コードを使用して openSSL.NET 機能を再作成しようとしたときに誰かが抱えていた問題について読んだことで、これを理解しました。

TripleDESCryptoServiceProvider を作成するときは、上記のようにクラス初期化子にキーまたは IV を含めないでください。モード、ブロック サイズ、キー サイズなどを初期化する前にキーまたは IV を設定すると、キー、IV、またはその両方が壊れたり切り捨てられたりして、私が見た不安定な動作が発生します。何がどのように壊れたのかを確認するために、これ以上の実験はしていません。

修正されてよかったですが、約8時間かかりました...

これがその方法です。わかりやすくするために、他のコードは省略しました。

var des = new TripleDESCryptoServiceProvider  
{
    BlockSize = 64,
    KeySize = 128,
    Mode = CipherMode.CBC,
    Padding = PaddingMode.None,
};

// the important bit is that these properties are 
// being set last
des.IV = initVector;
des.Key = key;
于 2013-09-20T18:54:19.427 に答える