PRこの記事でわかること
これは、nRF5340を使う製品で、ファームウェア更新の受け入れ条件と復旧手順を設計するための記事です。nRF5340の無線機能や二つのコアの基本はnRF5340の基本解説で確認できます。ここで扱うのは、採用後に「誰が作った更新なら起動してよいか」を装置側で判定するための実装方針です。
セキュアブートとは、アプリケーションが動き始める前に、起動してよいイメージかを署名などで確かめる仕組みです。通信を暗号化すること、装置の全機能を自動的に安全にすること、デバッグを一律に禁止することと同義ではありません。署名の検証、鍵の保管、更新の失敗時に元へ戻す方法を別々に設計して初めて役に立ちます。
nRF5340でセキュアブートを導入する目的は、「署名されていない更新イメージを起動しない」ことです。これは暗号ライブラリを追加する作業ではなく、どのイメージを誰が署名し、どの鍵をどこで守り、失敗した更新からどう復旧するかを設計する作業です。最初の評価にはnRF5340 DKとZephyrの標準的なMCUboot構成を使うと、基板配線や独自ブートローダーの問題を混ぜずに検証できます。
先に結論
- 開発初期は、ZephyrのnRF5340 DK向け構成とMCUbootで、署名済みイメージが起動すること、未署名イメージが拒否されること、失敗時にデバッグ接続で復旧できることを別々に確認します。
- 鍵はソースコードや共有フォルダに置かず、開発用・検証用・出荷用を分けます。開発用鍵で成立した手順を、そのまま量産用鍵の運用にしないでください。
- Secure/Non-secureの区別、アプリケーションコアとネットワークコア、デバッグ保護は別の論点です。MCUbootを有効にしただけで全ての保護が完了するわけではありません。
最小構成で確認する順番
| 段階 | 確認すること | 成功の判断 |
|---|---|---|
| 1 | 通常のZephyrアプリをDKでビルド・書込み | シリアル出力とデバッグ接続が安定する |
| 2 | MCUbootを含むビルドへ変更 | ブートローダーとアプリが一緒に書き込まれる |
| 3 | 署名済みイメージで更新 | 正常に起動し、版番号を確認できる |
| 4 | 意図的に不正なイメージを検証環境で試す | 起動しないことを確認し、復旧手順が使える |
ZephyrのnRF5340 DK向け資料では、アプリケーションコア用の標準ボード指定とSecure状態での起動を確認できます。MCUbootを組み込む場合は、ビルド出力、イメージスロット、署名鍵の指定が変わります。最初から無線更新や暗号化まで同時に有効化せず、署名検証だけを再現可能にするのが安全です。
実装前に決めること
更新方式は有線書込み、外部記憶を使う更新、無線更新で必要な設計が異なります。記事やサンプルのコマンドをコピーする前に、次を表にしてください。
- 対象はアプリケーションコアだけか、ネットワークコアも更新するか
- 失敗した更新を何回まで再試行するか
- 署名鍵の保管者と、署名を実行できるCIまたは端末
- 製造・保守時にデバッグを許可する条件
- 物理的な復旧手段と、その作業者
よくある誤解
デバッグ保護を早期に固定すると、障害解析や製造検査ができなくなる場合があります。逆に、開発中だからといって出荷構成で保護を無効のままにすることも避けます。量産向けのアクセス保護や鍵の恒久設定は、評価ボードで復旧手順を実証してから、別の承認手順として扱ってください。
復旧手順は、担当者が実際に使える手段まで書き出します。たとえばデバッグ接続が許される評価段階なのか、物理的な書込み端子が残るのか、装置を回収しなければならないのかで、同じ「起動しない」でも対応が変わります。署名拒否を確認するテストと、正常なイメージへ戻すテストは必ず対にしてください。
公式資料
Amazonの検索結果
購入リンクにはアフィリエイトリンクを含む場合があります。仕様・在庫は購入前に販売ページとメーカー公式情報で確認してください。