nRF52とは直接関係ないのだが、nRF5 SDK v12を試せるデバイスがうちにはnRF52832しかない。
今回は、Secure DFU bootloaderを調べよう。
micro-ecc
楕円曲線暗号ライブラリのmicro-eccをgithubから持ってくる。
cloneするフォルダも決まっているので、やり方はここら辺を読んでおくれ。
そして、nRF5_SDK_12.0.0_12f24da\external\micro-ecc\nrf52_armgcc\armgcc\でmakeする。
そうしたら、同じフォルダにmicro_ecc_lib_nrf52.aができる。
ビルド
nRF5_SDK_12.0.0_12f24da\examples\dfu\bootloader_secure\pca10040_debug\armgcc\でmakeする。
これはdebug版のフォルダなので、好きにしておくれ。
ビルドすると_buildの下に、えらく大きいbinファイルと、小さいhexファイルなどができる。
これで、ブートローダができた。
次は、DFUで送るファイルを作る。
説明ではInitパケットのことが書いてあるのだけど、後回しにしよう。
> nrfutil pkg generate [option] zipファイル名
optionでは、DFUするファイルも指定するが、--key-fileでPEM形式の秘密鍵を指定できるようになっている。
signとあるし、DFUするファイルを暗号化するのではなく、DFUファイルがいじられてませんよ、の署名として使うということか。
InitパケットのところにSignature typeがあるが、これがPEMで指定するのと一致しないとダメだろう。
このサンプルではECDSA_P256_SHA256だそうだ。
たぶん公開鍵はdfu_public_key.cとしてブートローダに埋め込むことになっている。
そして、検索した範囲ではPEMファイルがないので、自分ではこの公開鍵で使えるzipファイルを作ることはできないだろう。
DFUするファイルはzipになるだけだから、解凍すればHEXファイルが見えるだろう(binになるかも)。
DFUファイル自体を暗号化して、どういうことをやっているのか解析されないようにもできるとよいのだけど、さすがにそれはnRF側の負荷が重たいのか。
AESだったら、nRFも持っているからやりやすいかもしれんが、実現するにはいろいろ作らないとダメだよねぇ。
と、調査だけで今回は終わってしまった。
試すのは次回だ。
通信内容を暗号化する方法は、Bluetoothで規定されているので、それを使うべきなのでしょう。
返信削除AESを使うので、nRFにはAESのライブラリが付属しています。
楕円曲線暗号は非対称暗号化方式なので、DFUの改ざん防止として使われるはずです。
PCでDFUを作成した時に、バイナリのハッシュ値を計算し秘密鍵で暗号化してバイナリの最後に付加します。
ペリフェラル側は楕円曲線暗号ライブラリは公開鍵を持っていて、この公開鍵で復号化したハッシュと、DFUとして送られてきたバイナリのハッシュが一致すれば、改ざんなしと判断します。
秘密鍵はPCかUSBメモリに保存しますが、これが盗まれるとDFU改ざんが可能となってしまいます。
この方式は、AndroidかQualcommのセキュア・ブートローダで使われいます。
無線区間はnRFに任せるとして、HEXファイル自体を解析されたくないという要望があるので、暗号化できればよいな、というところですね。
削除