[n7]FeliCa Lite用のライブラリを作ろう (2) : 片側認証編

「べ、別にFeliCa Liteのことが好きなわけじゃないんだから」というわけで(なんじゃこりゃ)、FeliCa Lite用ライブラリの続きを作ろう。

前回作ったのは、どちらかといえばNFC-Fの補足ライブラリのようなものであった。
今回は、個別化を移植しよう。

NfcAとNfcFのクラスライブラリは同じ水準かもしれない。
しかし、MifareUltralightがAndroidの標準にあって、Felicaがないのはよろしくない。
Felicaがないのなら、MifareUltraLightもあってはならない、と思うんだけどなあ。
いっそのこと、Type2TagとかType3Tagみたいなクラスにしてしまえばいいのに。

---

以前も、片側認証のための個別化カード鍵についていろいろ調べた。
特にはまったのが、3DESのエンディアン。
http://hiro99ma.blogspot.jp/2011/09/felica_04.html

FeliCa Liteのユーザーズマニュアル「5.1.1. MAC生成アルゴリズム」にも、添字の大きい方が上位、と書いてある。
なので、まあこれはいいとしよう。

 

それよりも困っているというか悩んでいるというか、個別化マスター鍵の値が1つ違っても、計算するMACの値が一致してしまうのだ。
FeliCa Liteは、IDブロックを読んだときのMACを使っている。
なにが悪いんだろう？

いろいろ調べていたが、DES暗号化は鍵が56bitだから、8byte(64bit)指定しても使われないビットが8bit分あるんじゃなかろうか、と思った。
「1つ違っても」で試したのは一番下のデータだったので、8byteのそれぞれ最下位ビットが使われないと考えるとつじつまが合いそうだ。

JavaでもC#でも同じように動いているということは、APIがだいたいそういうものということか。

 

http://www.arch.cs.kumamoto-u.ac.jp/~kuga/cad/crypt/des/
ここの説明に「パリティ」という説明があった。
使われないのではなく、パリティビットだったのか。。。
理屈はわかったが、「8byteの鍵」って書いてあると、ここまで気が回らないなあ。

---

そんなわけで、実装方法としては間違っていないようだ。
ただ、個別化マスター鍵の管理方法として、

• 鍵バージョンと個別化マスター鍵はきっちり管理すること
• 3DESなので、個別化マスター鍵のA[0～7]、B[8～15]、C[16～23]の各バイトの上位7bitが同じ値にならないようにすること(鍵Aで暗号化→それを鍵Bで復号化→それを鍵Cで暗号化、とするので、AとBが同じだと、Cで暗合しただけと同じになる)
• 3DESなので、新しい鍵バージョンを追加するときは過去の個別化マスター鍵と比較し、各バイトの上位7bitが一致しないことを確認すること

というような取り決めにした方がよいだろう。

 

ようやく、片側認証らしきものを追加した。
https://github.com/hirokuma/NfcTest4

知らない分野はまだまだいろいろあるな。