2016/04/17

[nrf]ECCは使えるのか?

無線だけじゃなくて、データ自体に暗号化を掛けてしまいたいときがある。
nRF51822はAES用のハードウェアとしてECBとかCCMとかが載っているようだ(使ったことない)。
128bitと書いてあるから、16バイト分。
20バイト以内だから、まあちょうどいいといえばちょうどいいサイズだ。

そういえば、SoftDeviceがS130v2とかS132v2とかになって、Bluetooth v4.2規格に対応したという話だ。
Production release of S130 & S132 v2.0 SoftDevices for the nRF51 and nRF52
これは2016年2月23日の記事なのだが、2番目に「LE Secure Connections」とあり、そこで楕円曲線暗号化(ECC)のことが出てくる。
ライブラリを再利用しているようなことが書かれているのだが、データを暗号化したいだけでも使えるのだろうか?


Experimental: BLE LE Secure Connections multirole example

これがサンプルのようだ。
S130/132とあるから、nRF51822でも使えるのだろう。
nRF52832のPS書を検索したが、ECCで引っかからなかったのでたぶんハードウェアで何か持っているというわけではないのだろう。

目立つ文字だけ眺めていると、Peer Managerというものが見えた。
なんとなく、Bonding Manager→Device Manager→Peer Managerと変遷しているのだろうか。
v10.0のときはExperimentalだったのだが、v11.0では消えているから、正式になったのだろう(DeviceManagerのページには「将来的にPeerManagerに置き換えられる」と書いてあった)。

 

さて、サンプルのソースをeccで検索すると、「ecc_p256_public_key_compute」のような名前が出てきた。
ファイルを見ると、中身はすかすかで、uECC_secp256r1()を呼んでいるだけのようだった。
そして、uECC_secp256r1()の実体がSDKの中にない。。。

ドキュメントを読むと、別ライブラリのこちらをGithubから取ってきて使うようだ。
kmackay/micro-ecc: ECDH and ECDSA for 8-bit, 32-bit, and 64-bit processors.


なんか深入りしすぎてしまいそうなので、ここでやめておこう。
ともかく、ECC自体はハードウェアの機能を使うのではなく、ソフトウェアとして動かすだけのようだから、きっとnRF51822でも動くのだろう。
SoftDeviceが新しくなってBLE v4.2に対応したのも、ECCに対応したというよりは、アプリ/SDKが作ったデータを「ECCですよ」といって流せるようにしたというところじゃなかろうか。
v4.2自体あまりわかってないので、想像ですが。。。

だから、アプリが自分のデータをECCで暗号化したいだけなら、SoftDeviceはS110のままでもよくて、単にライブラリを追加してアプリで実現させればよいはず。
ただ、うちのnRF51822はRAMが16KBなので、そこで動くのかどうかまではわからないな。
Compatibility Matrix v2.1でも、IC revision3で16KBのタイプも残っているから、動くと思いたい。

あとは、私がBLEv4.2だけでなく、ECCにもあまり詳しくないというところだが、そこはいいだろう(よくない)。

0 件のコメント:

コメントを投稿

コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。

注: コメントを投稿できるのは、このブログのメンバーだけです。