タグ: セキュア・ファームウェア更新

STM32G0/G4シリーズRoot of Trust実現(3)は、第2回で示したSTM32G4評価ボード：NUCLEO-G474RE 利用STM32G4テンプレート開発環境と、デュアルファームウェアイメージのサンプルアプリケーションを使って、セキュア・ブート（SB）、セキュア・ファームウェア更新（SFU）のための準備、その具体的動作の説明をします。

初めに本稿（3）のまとめを示し、最後の章でRoot of Trust実現(1)～(3)全体のまとめを示します。

STM32G0/G4のRoot of Trust(3)まとめ

• セキュア・ブート（SB）、セキュア・ファームウェア更新（SFU）に、評価ボード毎にSTM32CubeProgrammerを使ったオプションバイト設定必要。
• Root of Trust（SBSFU）実装MCUは、VCP経由アクセスのみ可能。
• SBSFUローカルVCPダウンロードのために、Tera TermとYMODEM送信機能利用。
• STM32G4評価ボード：NUCLEO-G474REで、SBSFU実装デュアルファームウェアイメージアプリケーション動作説明。
• STM32G0評価ボード：NUCLEO-G071RBでも、STM32G4評価ボードと同じRoot of Trust（SBSFU）実装動作を確認。

STM32G4評価ボード準備

SB、SFUサンプルアプリケーションの動作確認のために評価ボード：NUCLEO-G474REの事前準備が必要です。これには、STM32CubeProgrammerを使います。STM32G4の場合は、UM2262 図18ですが、オプションバイト等の設定は不要（デバイスデフォルトOK）です。

8.1.3のFlash全消去（Full chip erase）処理をします。また、評価ボードのST-LinkファームウェアをV2J29以上に更新します。更新は、評価ボードとUSB接続後、STM32CubeProgrammerのFirmware Updateクリックで最新版ST-Linkファームウェアへ更新されます。

Root of Trust（SBSFU）準備

図17. ステップバイステップ実行から判るように、最初のStep1：SBSFUダウンロード以外は、全て評価ボードのVirtual COMポート（VCP）経由でアプリケーションをダウンロードします。STM32CubeIDEがプログラミングやデバッグで使うST-Link接続（SWD接続）は、外部からのMCU攻撃とSBSFUが解釈するからです。

セキュア・ブート（SB）が攻撃と判断した時は、当然、アプリケーションを起動しないためMCUは動作停止します（SB処理は、第2回2章を参照してください）。

つまり、ファームウェアイメージのアプリケーションがディアル/シングルに関係なくRoot of Trust（SBSFU）実装MCUは、VCP経由アクセスのみ可能となります。また、VCP経由でのアプリケーションデバッグは非効率なため、十分なデバッグ済みアプリケーションをダウンロードする必要もあります。

このVCP経由ダウンロードのために、Tera TermとそのYMODEM送信機能の準備が必要です。

SBSFUサンプルアプリケーション

図17. Step-by-stepを使ってデュアルファームウェアイメージのSBSFUサンプルアプリケーション動作を説明します。

Step1：Flash全消去後のNUCLEO-G474REに、STM32CubeIDEを使って第2回3章で示した順番でコンパイル済みのSBSFUプロジェクト出力（SBSFU.elf）を、STM32CubeIDEを使わずにSTM32CubeProgrammerでダウンロードします。

STM32CubeIDEでは、ダウンロード後自動的にデバッガ接続に変わるため、この時点でSBSFUが攻撃を受けたと判断し使用できません。

STM32CubeProgrammerを使うとNUCLEO-G474REのFlashに、セキュアエンジンとSBSFUが書込まれます。これ以降は、Tera TermのVCP経由MCUアクセスのみが可能です。
※従って、STM32CubeIDEを使ったST-Link経由MCUデバッグ開発へ戻る時は、STM32CubeProgrammerでSBSFUが入ったFlashを全消去する必要がありますので注意してください。

次に、パソコンとNUCLEO-G474RE接続中のUSBケーブルを、2回挿抜します。これで、ST-Linkに代わりSBSFUとTera TermのVCP通信が開始します。

Step2：NUCLEO-G474RE とTera Termは、8-Non-1 115200bpsでシリアル接続します。接続後、NUCLEO-G474REリセットボタン（黒ボタン）を押すと、SBSFUが図24（白黒反転済み）のWelcome画面をTera Termへ出力します。

Welcome画面を確認後、Tera Termのファイル(F)>転送(T)＞YMODEM＞送信(S)をクリックし、UserApp.sfb（暗号化ファームウェア）を選択します。
※UserApp.sfbは、NUCLEO-G474RE_2_Image _UserApp￥Binaryフォルダ内（UserApp オブジェクト出力先フォルダ）にあります。

プログレスバーは、1秒ほど動きません。この間は、SBSFUがダウンロードファームウエアヘッダの有効性を検証し、格納するFlashスロット＃0/#1領域を消去しているからです。

送信完了でNUCLEO-G474REのFlashが、Step2の状態になります。

Step3：NUCLEO-G474REが自動的に再起動し、SBSFUにより復号化されたUserAppが動作します。この時のTera Term出力が図27（白黒反転済み）です。NUCLEO-G474REのLD2は、ゆっくり点滅します。

画面のUser App #Aは、2_Images_UserApp＞main.cのL51：UserAppId = ‘A’の出力です。Main Menu：1/2/3は、インストールしたアプリケーションに記述されたSBSFUテスト機能です。

CN7真ん中よりやや下あたりを指で触るとTamper機能が動作し、ボードリセットが掛かります。

実際では、この段階で我々ユーザが開発したアプリケーションが動作中となります。

Step4：ユーザ開発アプリケーションに何らかのバグがあり、これをデバッグ済みの新しいアプリケーションへ更新（SFU）するのがこの段階です。

STM32CubeIDE でL51：UserAppId＝‘B’へ変更し、コンパイルします。ここでは、これをデバッグ済みの新しいアプリケーションとします。

再び、Tera Termのファイル(F)>転送(T)＞YMODEM＞送信(S)をクリックし、UserApp.sfb（UserAppId＝‘B’に変更し、コンパイルした暗号化ファームウェア）を選択し、ダウンロードします。ダウンロード完了でNUCLEO-G474REは再起動します。

Step5：再起動後の動作中アプリケーションは、図27の下線部が変更したUser App #Bに変わっていることで確認できます。

これで、新しいアプリケーションへの更新が完了しました。

＊　　＊　　＊

図17を使ってRoot of Trust実現STM32G4シリーズMCUのセキュア・ブート（SB）、セキュア・ファームウェア更新（SFU）ローカル動作例を説明しました。

実際は、この動作が図2. ②通信チャネル経由で行われます。

通信チャネル利用時は、本稿のローカル動作で使ったTera TermのYMODEM送信を誰が行うのか、鍵の管理やサーバ提供など、筆者がUM2262から読み切れない不明な部分があります。これらはいずれ、明らかにする予定です。

また、UM2262図18. 評価ボード準備とSTM32CubeProgrammer設定方法が解りづらく、単なるサンプルアプリケーション動作にかなり「苦戦」しました。この部分は、通常アプリケーション開発とRoot of Trust実現開発の切換えとなる重要ポイントです。STM32G4テンプレート発売時には、添付資料にもっと解りやすい説明を加えます。

UM2262 Rev6/5の評価ボード：NUCLEO-G474RE設定記述ミス

もう1つの「苦戦」理由は、UM2262 Rev6/5の8.1評価ボード：NUCLEO-G474RE設定記述に間違いがあるからです。

UM2262 8.1には、STM32G4のDBANKビット有効化と記述されていますが、これは「無効化が正しい」です。STM32CubeProgrammerで無効化に設定してください。

STM32G0評価ボード：NUCLEO-G071RBに関しては、記述にミスはありません。本稿の関連部分をNUCLEO-G071RBへ読替えると、全て正常動作します。

STM32G4シリーズは、STM32G0シリーズよりも約1年後に発売されました。新しいMCUのためUM2262に記述ミスがあるのだと思います。

STM32G0/G4のRoot of Trust全体まとめ

STM32G0/G4のRoot of Trust(1)～(3)、いかがでしたでしょうか？　セキュリティ機能の実装は、IoT MCUでは必須です。従来のMCU開発へ追加する機能や手間、セキュリティ知識も当然必要になります。

これら追加分は、一般的な開発者が、オリジナリティを加えるべき部分では無いと思います。そこで、これら追加分を、できるだけ簡潔に解り易く説明したつもりです。Root of Trust (1)～(3)で、下記STM32マイコンマンスリー・アップデート2020年3月号P4のX-CUBE-SBSFU説明内容が、より解り易くなれば先ずはOKとします。

結局、STM32G0/G4シリーズMCUの場合は、通常のMCUアプリケーション開発が第1段、次に、これをIoT MCU化し、Root of Trust機能（SBSFU）を追加実装するのが第2段という、2段階開発になりそうです。この第2段SBSFU実装時に、本稿で用いたデュアル/シングルファームウェアイメージのアプリケーションサンプルが、枠組みとして使えそうです。

STM32G4テンプレートも、弊社通常テンプレート同様、RTOSを使わない疑似マルチタスク実装用（第1段テンプレート）と、開発済みアプリケーションのRoot of Trust SBSFU実装用（第2段テンプレート）の2つに分けてパックで提供しようと考えています。

セキュリティ（盾）は、常に脅威（鉾）との競争です。STM32G0/G4シリーズよりも更にセキュリティを強化したSTM32L5シリーズ（Cortex-M33）など最新MCUの方が、IoT MCU開発には向いているのかもしれません。

この終わりなき競争が続いてセキュリティ時代遅れにならないように、開発中MCUのより早く、かつ、万一より強いセキュリティMCUが必須となった場合でも、MCUコアに依存しない流用性の高いアプリケーション開発が求められます。