セキュア・ファームウェア更新アーカイブ

IoT新汎用RL78/G23調査

2021年5月7日2021年11月6日 WithHappy

ルネサスエレクトロニクスが、2021年4月13日、新世代の汎用MCU RL78/G23を発表しました。RL78/G23は、弊社RL78/G1xテンプレートデバイスRL78/G13やRL78/G14の製造プロセスを改良し、IoT向き機能を強化した汎用MCUです。

新しいRL78/G23と従来RL78/G13を比較し、ルネサスIoT Edge MCU機能強化点と評価ボードを調べました。

新汎用RL78/G2xシリーズ位置づけ

ルネサスRL78ファミリパンフレット2021.04のp1記載RL78ロードマップから汎用MCUファミリを抜粋し、加筆したのが上図です。RL78/G23は、RL78/G13とG14性能の大部分をカバーした新しい汎用MCUであることが判ります（縦軸：性能、横軸：年代、橙色囲み：テンプレート対象RL78/G1xシリーズ）。

新汎用RL78/G23は、従来汎用RL78/G1xシリーズへIoTエッジ向き機能（製造プロセス、Snoozeモード・シーケンサ、高速オンチップオシレータ高速起動、中速オンチップオシレータ搭載など）を追加し、RL78/G1xシリーズと互換性があります。

RL78/G23のIoT Edge MCU機能強化点

RL78/G23は、RL78/G1x比、主に下記機能が強化されています。

Snoozeモード・シーケンサ搭載
RL78/G13比、30%低消費電力化
IoTエッジMCUセキュリティ強化

Snoozeモード・シーケンサ

Snoozeモード・シーケンサ（SMS）は、Snooze中のMCUを起動することなく、演算、分岐、周辺回路制御の順次処理が可能なMCU内蔵ハードウェアです。SMSはMCUよりも動作電流が少ないため、低電力動作になります。

従来のRL78/G13も、低電力動作用Snoozeモード（上図）を持っていました。Snoozeモード・シーケンサ（下図）は、周辺回路制御（Analog/Port settings）や、データ・トランスファー・コントローラ（DTC）の直接起動（USRT transmission）など、従来MCUの代わりに、予め設定した最大32個のシーケンシャル処理実行が可能です。

このSMSを活用すると、点線部分のMCU動作が不要となり、従来のRL78/G13よりも更に低電力処理が可能です。

30％低消費電力化

RL78/G13比、30％少ない低消費電力動作のRL78/G23（出展：ルネサスサイト）

前述のSMSや新製造プロセスなどにより、RL78/G13（64KB）比、30%の低消費電力化を達成しています。ROM容量が128KBと2倍での比較になる理由は、次章セキュリティ強化で説明します。

なお、RL78/G23最高動作周波数は32MHzで、従来RL78/G13と同じです。

IoTセキュリティ強化

RL78/G23新追加のSecure update and secure boot（出展：ルネサスRL78ファミリ）

IoTエッジMCUセキュリティ強化のため、RL78/G23には、RL78/G1xには無かったセキュア・ブートとセキュア・アップデート機能が実装されています。セキュア・アップデートには、実行中ROM領域に加え、書換え用ROM保存領域も必要になるため、従来比2倍のROM容量が必要です。

2倍詳細は、関連投稿：STM32G0/G4のRoot of Trust (1)～(3)、または、セキュア・ファームウェア更新：タグなどを参照してください。

RL78/G23 Fast Prototyping Board

従来のルネサス評価ボード（QB-R5F100LE-TBなど）は、開発時、別途E1/E2エミュレータが必須でした。新しいRL78/G23(32MHz、64ピン、ROM/128KB、RAM/16KB) Fast Prototyping Board（2590円）は、USB－シリアル変換器が搭載され、USB経由でデバッグとプログラミングが可能です。

従って、micro USBケーブルでPCと接続しさえすれば、エミュレータ無しでもプロトタイプ開発に着手できます。また、Arduinoコネクタも実装済みで、各種Arduinoシールドをスタック装着できる評価ボード形状になりました。

まとめ

RL78/G23は、RL78/G13互換性を重視し、IoTエッジ向き低電力性とセキュリティを強化した新世代の16ビット汎用MCUです。

エミュレータ不要でArduinoコネクタ実装済みRL78/G23評価ボード(32MHz、ROM/128KB、RAM/16KB)は、制御系載せ替えモジュール化が可能となり、競合他社MCUとの比較も容易です。

載せ替え制御系モジュールの詳細は、コチラの関連投稿3章：半導体不足時のMCU開発対策案を参照してください。

あとがき

久しぶりのRL78マイコンカテゴリ投稿でした。32ビットARM Cortex-M0+コア対抗のため、低消費電力化と評価ボード改善を図ったのが、RL78/G2xシリーズ第一弾：RL78/G23です。

その特徴を活かすには、新追加Snoozeモード・シーケンサ活用、つまり、ルネサスSxコア動作の休止に磨きをかけたソフトウェア開発（従来ソフトの一部SMSハード化）が必須です。

これは、Cortex-Mxコア低消費電力アプローチ：より高周波数の動作＋コア休止時間幅拡大とは、方向性が異なると感じました。ルネサスは、RL78/G1x顧客サーベイの結果、製造プロセス進化アドバンテージを、高周波数動作よりも、SMS追加や2倍メモリ増量へ配分したのでしょう。

このSMSを、ルネサス供給中のCortex-MxコアMCUへも搭載すると、差別化できるかもしれません。

STM32マンスリー・アップデートHTML化

2020年5月22日2020年5月31日 WithHappy

STマイクロエレクトロニクスのSTM32マンスリー・アップデートが、6月からスマホ閲覧に好適なHTML配信に変わります。2020年5月号が最後のメール配信でした。HTML配信はブラウザで「絵的」に見るのには確かに適していますが、「字的」な記憶や記録に残りにくい気がするので、個人的には残念です。

そこで、これまでのメール配信版の全マンスリー・アップデートから、5月30日発売のSTM32G0xテンプレートVersion2対象STM32G0シリーズ関連部分を忘れないようピックアップしました。

STM32G0シリーズ特徴

Dead Battery機能デフォルト有効（出典：マンスリー・アップデート2019年7月）

※テンプレートで使うNucleo-G071RBは、USB Power Delivery機能（Dead Battery機能）が「デフォルト無効」となっています。

STM32G042/G031/G030新登場（出典：マンスリー・アップデート2020年1月）

STM32マイコンでRoot of Trust実現のX-CUBE-SBSFU（出典：マンスリー・アップデート2020年3月）

報告は、A4で1枚以内にまとめろとOJTで学びました。今風に言うと、Twitterのような短文で報告せよということです。記事に、70nm新製造プロセス、64ピンパッケージでも1ペア電源ピン説明が無いのは、少し不満ですが、少ない文字量でSTM32G0特徴をまとめる良い見本になりました。

これは、読者にソフトウェア開発者が多いからでしょうか🤨？　黄色ハイライトは筆者加筆です。

STM32G0xテンプレートV2変更内容

さて、このSTM32G0シリーズ向けSTM32G0xテンプレートV2は、下記3項目がV1からの変更内容です。

IoT必須セキュアブート、セキュアFWアップデート実装STM32G0特徴を活用（詳細は、コチラの関連投稿を参照してください。V1は、この特徴を活かしきれていませんでした😂）
高性能専用LL API利用から、汎用HAL API利用アプリケーション開発用テンプレートへ変更
SW4STM32統合開発環境から、STM32CubeIDEへ変更

項目2と3をVersion2で対応します。余裕があれば項目1にも対応するかもしれません。

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だけでも次回上手く説明できるか自信がありません。結果は、次回のブログ更新で判ります。