nRF Connect SDK:DFU(Ver. 2.3+)

集大成

過去に書いた記事は(その当時の苦労を汲み取る意味でも)ずっと残しておく方針です。バージョンアップで全く通用しなくなったり、あるいはその時点での理解が間違っていて変なことを書いているといった場合もしばしばあるのですが、それも含めての記録です。

昔はどんなのだったか、ってのも分かるしね・・・別に要らんけど(笑)

バージョンアップで簡単になった

つい先日、nRF Connect SDKがVer. 2.3にアップデートされました。リリースノートはこちら

ザーッと眺めていくとWorking with nRF52 Seriesの欄にFOTA用にKConfigを追加したという記載があるのを見かけました。お、これは早速試してみるしか！ということで試してみました。使用するサンプルプロジェクトは何でもよいのですが、あらかじめBluetooth部分が実装されているperipheral_XXXXというサンプルを使うと何も考えずに試すことができます。

今回はPeripheral_BMSとPeripheral_UARTを使っています。

実際の設定

まず、最初にMCUBootloaderを有効にします。

次に実装されたというDFU関連の設定を有効にします。OTA DFU over bluetoothをチェックすると全部強制チェックが入りますが依存関係的に正しいので大丈夫です。

そしてコンパイルしてダウンロードしてみると・・・。

あらま、なんともあっさりできてしまいました。こりゃ簡単ですね！最初のころに色んな設定を追加したり、ソースコードにDFU用の記述を追加したり、分からなくて英語のやりとりをひたすら読んだりとやっていたのがアホらしくなるくらい簡単です。いや、簡単であることに越したことはないのです。別に技術者だって好きで難しいことがやりたいわけではないのです。

たぶん・・・一部の変な人はそうじゃないかもね(笑)

再びSecure DFUに挑む

はて、何回挑戦しているのだろうか・・・(笑)
今回のバージョンアップでDFUが簡単に実装できるようになったのを機に、今度こそはSecure DFUを実装してみせると誓って再びドキュメントやNordic DevZoneを漁りまくりました・・・とその前に、これってやっぱりSecureじゃないよね、ということを念のため確かめることに。

過去にも説明していますが厳密にはNon Secureというモードは存在せず、秘密鍵を指定していないのでSDKに含まれているサンプルのECDSA-256を使うために秘密鍵がバレているという状態です。

やはりSecureではなかった(当たり前)

違うプロジェクト(Peripheral_UART)を作って・・・。

先ほどと同じ設定をしてコンパイルします。


nRF SDK時代はDFUパッケージを別スクリプトで作成するようになっていたのでDFU後のファームウェアがDFUの機能を持っていないということもできた(二度とDFUできなくなるので普通はそんなことしません)のですが、NCSではDFUを実装する設定をしないとコンパイラがapp_update.binやdfu_application.zipを生成してくれないのでDFUできません。

app_update.binとdfu_application.zipはどちらを使ってもいいのですが、nRF SDKからの流れでなんとなくzipファイルを使うのがいいかなと思っています。

完全に雰囲気です(笑)
dfu_application.zipはapp_update.binとmanifest.jsonを無圧縮zipしたものなのでほぼ同じです。

|
ちゃんと(？)DFUできました。接続名はBMSのままですがサービス名が変わっています。

ということで、やっぱりセキュアではありませんでした。そりゃ当たり前ですよね、だって何も設定していないんですもの・・・。

ここまで定期(笑)

不具合(？)が直っていることを期待して

前回のSecure DFUでは関連する設定と思われるCONFIG_MCUBOOT_SIGNATURE_KEY_FILEあたりが実は不具合でうまく動いていないのではないかと思っていました。なぜCONFIG_MCUBOOT_SIGNATURE_KEY_FILEじゃなくてCONFIG_BOOT_SIGNATURE_KEY_FILEを指定しろと出てくるのか意味が分からないからです。

画像は前回の使い回しです・・・

これが不具合だったとすればVer. 2.3ではもしかして直っているかも知らない！と少しだけ期待して動かしてみましたが・・・やはりダメでした。同じことを言われてしまいます。

とうとう見つけた！

となるとやっぱり根本的に何かが間違っているのだろうなと思ってひたすらこの関連で検索しまくりました。そしてついに！見つけました。

内容そのものはVer. 1.9.1のものなので若干古いのですが、Answerの部分にどうやって設定するかが記載されているのを見つけました。

CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=n
CONFIG_BOOT_SIGNATURE_TYPE_RSA=y

このあたりのコマンドは2.0以降は削除されています

設定するキーはCONFIG_BOOT_SIGNATURE_KEY_FILEで正しいようです。ただし設定の仕方が特殊な記述になるようで、child_imageフォルダを作ってその下にmcuboot.confという名前でファイルを作らなければいけないとのこと。また、上記コマンドは削除されているため、現在はECDSA-256固定となっており、またそのキーファイルのパスは絶対パス指定である必要があるみたいです。

そんなの分かんねーよ・・・orz

ということで早速作ってみます。



そしてコンパイルしてみると・・・。

おお！おおお？！
キーファイルを認識している！
ということは・・・。
これは・・・イったのか？

補足

キーファイルは最初の記事でも記載しましたが付属のスクリプトを使ってPythonで生成することができます。余談ですがECDSA-256なのでnRF SDK時代に作成した秘密鍵(nRF SDKでは一般的にprivate.keyという名前のファイル)でも使えます。

python keygen.py --private -o priv.pem

Secureになったのか確認

早速コンパイルしたイメージを書き込み、先ほど使ったPeripheral_UARTのdfu_application.zipでDFUを再び試みてみます。SecureになっていればNon SecureであるPeripheral_UARTのイメージには書き換わらないはずです。
|

！！！
書き換わっていない！
省略しますが、同じキーファイルを使ってコンパイルしたイメージでは当然DFUで書き換えることができます。

総括

長い闘いがやっと終わりました・・・。