Root of Trust アーカイブ - IoT MCUのHappyTech

Arm TrustZone【組込み開発基本のキ】

2024年8月30日2024年8月30日 WithHappy

MCUセキュリティの2回目は、Arm TrustZoneについて解説します。前稿解説のセキュアブートは、MCU起動ソフトウェアの信頼検証を行います。Arm TrustZoneは、MCU実行中ソフトウェアの改ざん防御技術です。

TrustZoneもベンダやMCU毎にその実装が大きく異なりますので、TrustZone基本知識を解り易く説明後、実装例を示します。

※TrustZoneはセキュアブートも包含します。本稿はセキュアブート以外の内容を解説し、Summaryでまとめます。

Arm TrustZone基本

セキュアブート同様、Arm TrustZone（以下TrustZone）も専用ハードウェアで実行中MCUソフトウェアの改ざん防御やセキュリティ確保を行います。

TrustZoneは、気密性の高いデータ保存や重要周辺回路、処理ソフトウェアを保存する「セキュア領域」と、それ以外の「ノンセキュア領域」にMCUハードウェアを分離します。そして、ノンセキュア領域のソフトウェアは、予め決めた手続きに従わないと、セキュア領域へのアクセスができません。

つまり、ノンセキュアソフトウェアのセキュア領域直接アクセスが禁止です。これにより、セキュア領域の改ざん防御とセキュリティを確保します。

セキュア領域は、暗号鍵や機密データ、割込みハンドラなどの重要ソフトウェアを保存します。
ノンセキュア領域は、通常の周辺回路やアプリケーションソフトウェアを保存します。

TrustZoneセキュリティ違反検出時は、セキュリティ例外処理を実行します。この処理内容は、システム設計や実装により大きく異なります。例えば、MCU動作停止やセーフモードでの最小機能動作、ネットワーク経由での違反内容通知などがあります。

このようにTrustZoneは、様々なセキュリティレベルに柔軟に対応可能です。TrustZone対応Arm Cortex-Mコア一覧が下記です。Cortex-M33など新しい設計のArmv8-M MCUコアは、TrustZone内蔵です。

TrustZone対応Arm Cortex-M_Processor_Comparison_Tableに加筆（出典：ARM）

※Cortex-M7は、MPUで設計も古いためTrustZoneなし。TrustZone MPUは、Cortex-A35など。

TrustZone実装例

前章でTrustZoneの基本を解説しました。しかし、実際のTrustZoneは、もっと複雑です。

例えば、STマイクロ）STM32L5/U5 MCU（Cortex-M33コア）のTrustZoneウェビナー資料が、コチラからダウンロードできます。

I2C/SPIへのハッカー攻撃例（P10）とその防御（P11）、TrustZone分離例（P20）、セキュリティ違反検出方法（P21～23）、TrustZone初期設定フロー（P29）などが示されています。

また、TrustZoneにJTAGポート無効化やMCUパッケージ開封検出（タンパ検出）などの複数セキュリティ機能を重ね、セキュリティレベルを上げていることも判ります（P17）。

複数セキュリティを重ねセキュリティレベルを上げる（出典：STマイクロSTM32L5／U5 MCU TrustZoneウェビナー資料）

この実装例は、Secure User Memory（P15）格納の暗号鍵を使ってセキュアブート後、I2Cデバイス制御とSPI無線通信制御を重要ソフトウェアセキュア領域へ格納、ハッカー攻撃などセキュリティ違反検出時でも、これらセキュアソフトウェア処理は継続、かつ、セキュリティ違反検出内容を外部無線通知するMCUアプリだと推測します。

※ウェビナー資料でファームウェアと記述の箇所は、本稿のソフトウェアと解釈してください。

TrustZone開発の難しさ

TrustZoneを使うMCU開発は、通常開発に加え、

想定攻撃、脅威は何か
セキュリティ違反の例外処理をどうするか
例外処理デバッグはどう行うか
セキュア領域の重要ソフトウェア、周辺回路は何か
セキュア/ノンセキュア分離アプリの同時開発

など、多くの課題があります。また、セキュア/ノンセキュア分離前の通常アプリにバグが無いことも必要です。さらに、セキュリティ対策効果とリスク、開発コストに対し、費用対効果を顧客と相談する必要もあります。

TrustZone MCU開発は、高度なスキルが必要になると思います。

Summary：Arm TrustZone基本知識

組込み開発基本のキとして、MCUハードウェアをセキュア領域とノンセキュア領域に分離し、ノンセキュアソフトウェアのセキュア領域直接アクセスを禁止することで、実行中のセキュア領域ソフトウェア改ざん防御とセキュリティ確保を行うArm TrustZoneの基本を示しました。

TrustZoneセキュリティ違反検出時は、セキュリティ例外処理を実行します。この例外処理内容は、システム設計や実装により大きく異なります。このセキュリティレベル多様性理解には、TrustZone基本知識が重要です。

前稿解説セキュアブートは、MCU起動ソフトウェア信頼性の検証を行います。セキュアブートとTrustZoneの併用で、起動/実行中のソフトウェア改ざん防御とセキュリティ確保ができます。TrustZoneが、セキュアブートを包含する理由がこれです。

Afterword1：自転車ロードレース競技中のハッキング

ワイヤレス技術利用制御系の潜在的脆弱性攻撃例が、コチラにあります。350ドル程度のソフトウェア無線機HackRFやRaspberry Piなどでも攻撃可能だそうです。本稿のTrustZone実装例が対策に使われたのかもしれません。ハッキング検出時でも、簡単に動作停止できない（しない）事例です。

Afterword2：MCUセキュリティまとめ

セキュアブートとTrustZoneから、MCUセキュリティを俯瞰したのが下記です。

攻撃対象ソフトをRoot of Trust（RoT）ハードで守るのがMCUセキュリティ
RoTハードでセキュリティ違反検出、例外処理ソフトで違反処理
セキュリティ実装はアプリや運用で大きく変わる。開発費用対効果の検討必須
Armv8-M以後の新しいMCUコアにRoT TrustZone内蔵

費用対効果には、セキュリティ全般知識も必要です。これは、セキュリティ実装開発とは別次元の難しい課題です。対策は、AI PCを使ったセキュリティコンサルタント育成などでしょうか？

ブログ右上検索窓へ「基本のキ」と入力し検索すると、様々なMCU開発者向け基本知識が得られます。ご活用ください。

MCUセキュアブート【組込み開発基本のキ】

2024年8月23日2024年8月23日 WithHappy

ランサムウェア攻撃による企業活動停止やWindowsブルースクリーン大規模障害など、重大セキュリティインシデントが急増中です。MCU開発者にとっても、他人事ではありません。

そこで、MCUセキュリティの基礎、MCUセキュアブートとArm TrustZoneを2回に分けて解説します。セキュアブート編が本稿です。

MCUセキュリティが判り難い原因は、ベンダ、MCU毎にセキュリティレベルや実装が大きく異なるからです。そこで、個別セキュリティの前に、基本知識としてMCUセキュアブート（本稿）とArm TrustZone（次稿）を解り易く示し、その後、実装例を示す2段構えの方法で解説します。

MCUセキュリティ背景

MCUソフトウェアは、悪意を持つ第3者による改ざんやウイルス感染などで書き換わる可能性があります。一方、改ざんの可能性が無く安全なのは、MCUハードウェアです。

従来のMCU開発は、サイバー攻撃などのソフトウェア書き換えは、想定外でした。

しかし、PCセキュリティトラブルやランサムウェア被害などが増え、MCUも攻撃対象となりました。特にIoT MCUは、ネットにつながるため防御が必須です。この防御全般がIoT MCUセキュリティ（以下MCUセキュリティ）です。

セキュリティリスクを下げるには、開発コストが上がる。MCU開発者は、費用対効果バランスも考える必要がある。

今後のMCU開発では、MCUセキュリティ対策が望まれます。しかし、ソフトウェアのみでは対処できないため、セキュリティレベルに応じた追加ハードウェアが必要です。また、セキュリティオーバーヘッドのため、通常のセキュリティ無しソフトウェアに比べ処理能力も低下します。

MCUセキュリティ開発は費用対効果、つまり、これら追加効果とセキュリティリスク、セキュリティ開発コストのバランスを、どう解決するかがポイントです。

実装セキュリティがベンダやMCU毎に異なるのは、このポイントにバラツキがあるためです。顧客が、起きるか起きないか判らないMCUセキュリティインシデントに対し、どの程度開発コストを負担するか不明なのと同じです。

MCUセキュアブート基本

セキュアブート解説の前に、通常のMCUブートを簡単に説明します。

通常のMCUブートは、リセット→動作クロック設定→RAMゼロクリア→RAM初期値設定などを経て、Flash格納ユーザアプリケーションを起動します。格納ソフトウェアに、ハッカー攻撃などの改ざんが無いことが大前提です。

※関連投稿3章に通常ブート説明。

一方セキュアブートでは、最初にFlash格納ソフトウェアに改ざんが無いことを、暗号化技術を使って検証します。このため暗号化アクセラレータや暗号鍵の専用ストレージが必要になります。

検証失敗時は、動作停止、またはリカバリーモードへ移行し、検証成功時のみ通常ブートを行います。つまり、起動ソフトウェアの信頼検証をハードウェアのみで行うのが、MCUセキュアブートです。

通常ブートと比べると、事前に改ざんソフトウェアの実行が防げますが、検証時間が余分に掛かります。このセキュアブートハードウェアをRoot of Trustと呼び、専用ハードウェアとしてMCUに内蔵されます。例えば、Arm Cortex-M33コアMCUなどがこれに相当します。

※Root of Trust（RoT）は、最も基本的なセキュリティ領域の保証概念。ここが信頼できることを前提にセキュリティが構築されるため、信頼根と呼ばれる。

高度車載セキュアブート実装例

前章でMCUセキュアブートの基本を解説しました。しかし、実際のセキュアブートは、もっと複雑です。

例えば、ルネサス車載MCU RH850セキュアブートが、コチラです。

高度なセキュリティレベルが求められる車載MCUのセキュアブート例で、豊富な図を使って解説しています。セキュリティ専門用語も多いため、用語や略称集も添付されています。

しかし、前章基本を理解していれば、高度車載MCUセキュアブートでも掲載図だけで概ね把握できると思います。

Summary：MCUセキュアブート基本知識

MCUセキュリティの実装は、セキュリティ対策効果とリスク、その開発コストにより大きく変わります。Root of Trustを持つCortex-M33コアの汎用MCUでさえ、アプリケーションや顧客要求に応じ実装セキュリティは変わります。

例えばセキュアブートは、MCU起動時処理のため常時運用など再起動が少ない場合は効果も期待薄です。

MCU開発者のセキュリティ実装を困難にする原因の１つが、この多様性です。

そこで、組込み開発基本のキを示す本稿は、MCUセキュリティ基本知識として、起動時ソフトウェア信頼検証をハードウェアのみで行うMCUセキュアブートと、そのセキュアブート実現基盤のRoot of Trustを解説しました。

基本知識があれば、様々なセキュリティ実装開発にも対応できるからです。

次回は、MCU運用中セキュリティを確保するArm TrustZoneを解説します。

Afterword：Windowsブルースクリーン記事

Windowsブルースクリーン記事や解説が、ITmediaにまとまっています。業務の合間などリフレッシュを兼ねて目を通してはいかがでしょうか？

STM32CubeMonitor

2020年4月24日2020年5月1日 WithHappy

STマイクロエレクトロニクスのSTM32MCU純正開発環境STM32Cubeツールファミリに新に追加されたSTM32CubeMonitorを解説します。

STM32CubeMonitor特徴１：変数リアルタイムモニタ

STM32MCUアプリケーション開発フローと、純正開発環境STM32Cubeツールファミリ：STM32CubeMX、STM32CubeIDE、STM32CubeProgrammer、 STM32CubeMonitorの機能配分が下図です（以下、各ツールの頭に付くSTM32は省略して記述します）。

STM純正 4 Software Development Toolsと機能（出典：STMサイト）

この1～4段階の開発フローを繰返すことでアプリケーション完成度が上がります。CubeMX、CubeIDE、CubeProgrammerの機能には重複部分がありますが、Monitoring機能を持つのは、CubeMonitorだけです。

通常のMCU開発は、CubeMXがビルトインされた4段階全てをカバーする統合開発環境：CubeIDEを使えば事足ります（CubeMXビルトインCubeIDEの詳細は、関連投稿の3章をご覧ください）。

CubeProgrammerは、MCUオプションバイト設定などCubeIDEではできないBinary Programmingの＋α機能を提供します。例えば、STM32G0/G4のRoot of Trust(3)の投稿で示したSBSFU書込みや消去などがこの機能に相当します。

CubeIDEでも、デバッガ上でアプリケーションの変数モニタは可能です。しかし、あくまでDebugging MCUの（開発者向け）変数モニタです。CubeMonitorは、アプリケーションを通常動作させたまま、変数をリアルタイム（ライブ）モニタができる点が、CubeIDEとは異なるMonitoring機能です。

STM32CubeMonitor特徴２：データ可視化

リアルタイムで取得したデータは、下図のようにPCダッシュボードに予め準備済みのChartや円グラフにして可視化することができます。しかも、これら表示が、PCだけでなく、スマホやタブレットへも出力可能です。

つまり、CubeMonitorを使えば、開発したアプリケーションのライブ動作を、あまり手間をかけずにビジュアル化し、エンドユーザの顧客が解るように見せることができる訳です。これが、一押しの特徴です。

文章で説明するよりも、コチラの動画を見ていただくと一目瞭然です。

組込みアプリケーションのビジュアル化

組込みアプリケーション開発も、自動車のADAS（Advanced Driver-Assistance Systems：先進運転支援システム）のおかげでビジュアル化がトレンドです。

もちろん、超高性能MCUやデュアルコアMCUで実現するアプローチが本流です。が、本稿で示した2020年3月発表のCubeMonitorを使えば、産業用MCUでも案外簡単にビジュアル表示出力が可能になりそうです。

組込みアプリケーションは、MCUで結構大変な処理を行っていても、外（顧客）からは単にMCUデバイスしか見えません。CubeMonitorで処理データを可視化するだけでも、複雑さや大変さを顧客へ示すツールにもなります。

STM32G0/G4のRoot of Trust(3)

2020年4月7日2020年4月7日 WithHappy

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とします。

STM32マイコンマンスリー・アップデート2020年3月号P4のX-CUBE-SBSFU説明

結局、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コアに依存しない流用性の高いアプリケーション開発が求められます。

STM32G0/G4のRoot of Trust(2)

2020年3月27日2020年5月31日 WithHappy

STM32G0/G4シリーズRoot of Trust実現の第2回目は、初めにRoot of Trustを実現するセキュア・ブートの説明にトライし、直にセキュア・ブートとセキュア・ファームウェア更新を実装するSTM32G4テンプレート開発環境の構築方法を示します。

セキュア・ブート説明をこまごま続けるよりも、具体的なRoot of Trust実現開発環境を示す方が、実務的（短絡的？）だからです。

セキュア・ブート

第1回紹介の日本語版UM2262、P1概要：セキュア・ブート説明を抜粋したのが以下です。

‘セキュア・ブート（信頼の起点となるサービス）は、システムリセット後に必ず実行される改変不可のコードで、無効なコードや悪意のあるコードを実行しないために、実行前に毎回STM32の静的保護を確認し、STM32実行時保護を有効化してから、ユーザアプリケーションコードの認証および整合性を検証します。’

英語直訳で難解です（各単語の事前理解が必要なセキュリティ関連説明は、殆どがこんな感じですが…）。

ただ、下線部：「必ず実行される改変不可のコード」なので、理解不足や多少間違って解釈しても、セキュア・ブートコードを実装すれば、それで十分かもしれません😅。

セキュア・ブート解釈

要は、ユーザが開発したアプリケーション実行前に、MCUが勝手に行うブート処理のセキュリティを高度にしたものがセキュア・ブート（SB）だと解釈します。

従来のブート処理は、リセット後、MCU内蔵クロック発振器の安定化待ちやRAM領域初期化などの処理を何の疑いもなく実行し、その後、ユーザ開発アプリケーションを起動していました。

セキュア・ブート処理は、前章のセキュア・ブート処理を行い（図1.①）、その結果をUM2262：9章の表6. 起動時エラーメッセージ（下表）で示すように認証し②、「エラーなし。成功。」時のみ、③ユーザ開発アプリケーションを起動します。

パソコンで例えると、従来ブートがBIOS起動、セキュア・ブートがUEFI起動に相当すると考えれば良いのかもしれません。

X-CUBE-SBSFUはHAL API補完

Root of Trust実現で使うSTM32Cube拡張パッケージ：X-CUBE-SBSFUは、STM32MCU間の移植性を重視しているためHAL（Hardware Abstraction Layer）ベースです。

弊社発売中のSTM32G0xテンプレート（Version1）は、高速性を活かすエキスパート向けLL（Low layer）APIが「主」、HAL APIは「従」としてSW4STM32で開発しました。しかし、STM32G0でのRoot of Trust実現には、HALベースのソフトウェア開発が適しています。

LL/HAL混在利用は、関連投稿：STM32CubeMXのLow-Layer API利用法 (2)の4章で示した注意が必要です。X-CUBE-SBSFUは、アプリケーション起動前のHAL利用で、起動後のユーザアプリケーションのLL利用の場合は、問題ないかもしれません。この点は、今後明らかにしていきます。

いずれにせよSTM32G0xテンプレートは、IDEをSW4STM32から新しいSTM32CubeIDEへ移設すると同時に、Root of Trust実現に向けHAL APIも「主」とし、STM32CubeIDEで「再開発」してVersion 2に改版する予定です。

セキュリティ関連の説明はここまでにして、STM32G4シリーズでRoot of Trust実現の具体的方法に移ります。

Root of Trust実現STM32G4テンプレート開発環境

Root of Trust実現にセキュア・ブート（SB）機能とセキュア・ファームウェア更新（SFU）機能を実装する汎用STM32G4シリーズのテンプレート開発環境は、以下とします。

統合開発環境：STM32CubeIDE v1.3.0、2020/02/26
STM32Cube拡張パッケージ：X-CUBE-SBSFU v2.3.0、2020/01/17
STM32G4評価ボード：NUCLEO-G474RE（Cortex-M4/170MHz、Flash/512KB、RAM/128KB）

この環境で実現するセキュリティ機能が、UM2262の6.1概要に記載されたものです。これら機能理解に不明確な部分もありますが、内容把握済み、これら機能実現ためX-CUBE-SBSFUを使うと割切ります。開発環境を使っているうちに、（多分）理解度が上がるでしょう😅。

なおUM2262日本語版は、英語版Rev5からの翻訳なのでサポートIDEにSW4STM32はありますが、新しいSTM32CubeIDEがありません。しかし、最新英語版UM2262 Rev6に、STM32CubeIDEが追加されましたので本ブログでもSTM32CubeIDEを使います。

また、セキュリティ機能をテストするNUCLEO-G474RE用サンプルアプリケーションもX-CUBE-SBSFUに添付されていますので、これを以降の説明に使います。

UM2262では、STM32CubeIDEを使ったRoot of Trust開発環境の構築手順が判りにくいので、以下に説明を加えます。

構築手順1：STM32CubeIDEへのRoot of Trust SW4STM32プロジェクトインポート

X-CUBE-SBSFU v2.3.0には、SW4STM32プロジェクトが添付されていますが、未だSTM32CubeIDEプロジェクトの添付はありません。

そこで、STM32CubeIDEのInformation CenterからImport SWSTM32 projectをクリックし、X-CUBE-SBSFU添付SW4STM32プロジェクトを変換（Import）し、STM32CubeIDEプロジェクトを新規作成します。

STM32G4評価ボード：NUCLEO-G474REのSW4STM32プロジェクト6個を、STM32CubeIDEへインポートする時のダイアログです。

Finishクリックで、プロジェクト毎に下図2回の同意を求められますので、OKをクリックします。

構築手順2：Root of Trustサンプルアプリケーションのコンパイル

インポートした6個のプロジェクトは、シングルファームウェアイメージ：NUCLEO-G474RE_1_Imageとデュアルファームウェアイメージ：NUCLEO-G474RE_2_Imageの2種類のサンプルアプリケーションです。

シングル/デュアルファームウェアイメージの違いは、次章で説明します。

このサンプルアプリケーションは、それぞれ図15のように、_SECoreBin、_SBSFU、_UserAppの順番でプロジェクトをコンパイルする必要があります。図示のように前段コンパイル生成出力を、次段コンパイル入力に使うからです。

この順番を守ってコンパイルした時のみ_UserAppの出力オブジェクトが生成されます。

Windowsセキュリティソフト（Avastなど）によっては、コンパイル途中でワーニングを出力することがありますが、暫く待つとコンパイルを継続します。

シングルファームウェアイメージとデュアルファームウェアイメージ

図15は、SBSFU処理後のFlashメモリ配置を示しています。

図15の右側黄色部分：アクティブなイメージ領域だけをSFU処理で使うサンプルアプリケーションが、シングルファームウェアイメージです。右側黄色部分の上側、イメージのダウンロード/バックアップ領域に、図2のネットワーク（②通信チャネル）経由の新しいファームウェアを一旦入れるのが、デュアルファームウェアイメージです。

デュアルファームウェアイメージは、SFU処理中に電源断で中断しても、電源復帰後にSFU継続が可能です。また、アクティブなイメージ領域で動作中アプリケーションと並行してダウンロードが可能です。

シングルファームウェアイメージは、新しいファームウェアを、アクティブなイメージ領域上へ直接更新します。

デュアルファームウェアイメージは、フェールセーフな分、Flash容量はシングル比、倍必要になります。一方、シングルファームウェアイメージは、ユーザが使えるFlash容量が大きいので、デュアルよりも大きなアプリケーション開発ができます。

※ここで使ったセキュリティ用語：ファームウェアイメージとは、STM32CubeIDEのコード生成ツールSTM32CubeMXがデバイス毎に用いるファームウェア（弊社ならFW_F0/F1/G0/G4）とは別物です。図15の黄色部分を示します。

＊　　＊　　＊

以上で、STM32CubeIDEを使ったRoot of Trust実現のセキュア・ブート（SB）、セキュア・ファームウェア更新（SFU）機能を持つSTM32G4テンプレート開発環境の構築と、SBSFUに使うシングル/デュアルファームウェアイメージの2種サンプルアプリケーションを説明しました。

次回、このSTM32G4テンプレート開発環境とデュアルファームウェアイメージのサンプルアプリケーションを使って、Root of Trust実現の動作説明を予定しています。

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

信頼の起点：セキュア・ブート（SB）は、リセット後に必ず実行される改変不可能コード。
SB処理後、エラーなし認証時のみ、ユーザアプリケーション起動。
STM32Cube拡張パッケージ：X-CUBE-SBSFUは、HAL API補完。
STM32CubeIDEでRoot of Trust実現のセキュア・ブート（SB）、セキュア・ファームウェア更新（SFU）機能実装STM32G4テンプレート開発環境と構築手順説明。
SBSFUアプリケーションのデュアルファームウェアイメージとシングルファームウェアイメージの特徴説明。

SB、SFU実現には、暗号化や図1/2/15掲載の鍵、セキュアエンジンなど、本稿で説明を省いた（すっ飛ばした）様々なセキュリティ処理が必要です。UM2262付録の章に、これら詳細が記載されています。

本質的なセキュリティ理解には、これら各処理の理解積重ねが必要だと思います。付録の章を一読しておくと、今後いろいろな場面で役立ちます。

STM32G0/G4のRoot of Trust(1)

2020年3月19日2020年3月27日 WithHappy

2020年3月号STM32マンスリー・アップデートのP4に、STM32マイコンでRoot of Trustを実現するセキュリティ・ソフトウェア・パッケージ：X-CUBE-SBSFUが紹介されています。

セキュア・ブート、セキュア・ファームウェア更新、Root of Trust…などIoT MCUセキュリティ用語満載で、投稿：総務省によるIoT機器アップデート機能義務化に関連しそうな内容です。

解りにくいこれらセキュリティ関連の用語解説と、本ブログ対象STマイクロエレクトロニクスのSTM32G0/G4シリーズのRoot of Trust実現方法を、今回から数回に分けて投稿します。

Root of Trust とX-CUBE-SBSFU、STM32G0/G4

マンスリー・アップデートの説明は、エッセンスのみを抽出した代物なので、リーフレットを使って説明します。

一言で言うと、「Root of Trust実現には、X-CUBE-SBSFUが必要で、対応中STM32MCUが下表」です。

Root of Trust対応中のSTM32マイコン一覧（出典：FLXCUBESBSFU0819J）

つまり、Root of Trustは全てのSTM32MCUで実現できる訳ではなく、表中のMCU、メインストリーム（汎用）・マイコンの場合は、STM32G0とSTM32G4がセキュア・ブート（SB）とセキュア・ファームウェア更新（SFB）に対応しておりRoot of Trustを実現しています。

X-CUBE-SBSFUの下線部SBはセキュア・ブート、SFUはセキュアFW更新を示します。X-CUBEは、STM純正ソフトウェアツールの総称です。

信頼性を実現するハードウェア/ソフトウェアの根幹部分を、Root of Trustと呼びます。

汎用MCUでRoot of Trustの実現には、ハードウェア/ソフトウェア両方に相応の能力が必要で、従来からある汎用STM32Fxシリーズではなく、新しい汎用STM32G0/G4にSBとSFUが実装されたのだと思います。

ということは、総務省のIoT機器アップデート機能義務化が実施されると、IoTエッジで使う汎用MCUは、必然的にSTM32G0/G4シリーズになるかもしれません。
※X-CUBE-SBSFUは、移植性の高いHAL API利用のため、従来汎用STM32Fxへも流用可能かもしれません。しかし、現時点では、表記STM32G0/G4のみ対応と解釈しています。

STM32汎用MCUラインナップ（出典：STM32 Mainsterm MCUsに加筆）

用語を説明したのみですが、Root of Trust とX-CUBE-SBSFU、汎用マイコンSTM32G0/G4の関係が、マンスリー・アップデートエッセンスより見えてきたと思いますがいかがでしょう。

さらに、一歩踏み込んで、STM32G0/G4のセキュア・ブート、セキュア・ファームウェア更新方法やセキュリティの背景などの詳細は、次回以降説明します。

X-CUBE-SBSFUユーザマニュアル：UM2262

次回以降の説明は、X-CUBE-SBSFUユーザマニュアル日本語版（2019 年 11 月14日）：UM2262を基に行います。

UM2262は、X-CUBE-SBSFU対応中の全てのSTM32マイコン（ハイパフォーマンス/超低消費電力/メインストリーム（汎用）/ワイヤレス）が併記されています。

そこで、STM32G0とSTM32G4関連のみを抜粋し、特にセキュア・ブート（SB）とセキュア・ファームウェア更新（SFU）の設定方法と背景を中心に説明します。販売中のSTM32G0xテンプレートと、開発予定のSTM32G4テンプレートに関連するからです。

本稿で示したRoot of Trustを、STM32G4テンプレートに実装するかは未定です。しかし、IoTエッジマイコンのSTM32G4らしさを出すには、Root of Trust実現は必須だと思います。

また、STM32G0xテンプレートは、まずVersion 2改版で新統合環境：STM32CubeIDE v1.3.0への対応を予定しております（現行版は、SW4STM32開発のVersion 1）。
※STM32G0関連の投稿は、本ブログ右上のSearch窓へ、“STM32G0”と入力すると、効率よく投稿が集まります。新汎用STM32G0の特徴、STM32G0xテンプレートのことが解ります。

STM32G0へのRoot of Trust実装も未定ですが、対応する場合でもVersion 2より後にするつもりです。

従って、具体的なRoot of Trust実現方法は、STM32G4シリーズで先行、その後にSTM32G0シリーズが続くという順番になります。

TrustZone対応STM32マイコン体験セミナー（セキュリティ編）

5月22日（品川）と7月31日（大阪）に、2020年2月発売STM32L5マイコン（Cortex-M33/110MHz）を使ったSTM主催、定員30名、4時間半のTrustZone対応STMマイコン体験セミナー（セキュリティ編）が開催されます。

STM32L5は、PSA Certifiedレベル2認証を取得済みのTrustZoneマイコンです。PSA認証は、関連投稿：ARM MCU変化の背景の2章の3：セキュリティ対応をご覧ください。STM32L5のTrustZone実現は、専用のSTM32Cube拡張パッケージ：STM32CubeL5を使っています。

セミナー概要の冒頭に、「IoTセキュリティに関する法令やガイドラインの整備が進んでいます」とあり、具体的にIoTセキュリティ機能のSTM32L5への実装と必要性が解ると思います。セミナーに参加し、エキスパートから色々な情報を仕入れたいのですが、COVIC-19の影響で出張ができるか？…、Webinarなら嬉しいのですがね😅。

評価ボード付き無料セミナーです。ご興味がある方は、参加してはいかがでしょう。

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

Root of Trust実現に、STM32Cube拡張パッケージ：X-CUBE-SBSFUが必要。Root of Trust対応中の汎用マイコンは、STM32G0/G4シリーズ。
信頼性実現のハードウェア/ソフトウェア根幹部分をRoot of Trustと呼ぶ。
IoT機器アップデート機能義務化なら、IoTエッジ汎用MCUは、STM32G0/G4シリーズになる可能性あり。
STM32G0/G4シリーズのRoot of Trust実現方法、SB（セキュア・ブート）とSFU（セキュア・ファームウェア更新）は、UM2262を使い次回以降説明。

ここまでは、比較的簡単にRoot of Trust、X-CUBE-SBSFU、STM32G0/G4が説明できたと思います。ここからが、セキュリティの難解なところで、SBだけでも次回上手く説明できるか自信がありません。結果は、次回のブログ更新で判ります。