STM32G0/G4のRoot of Trust(2)

MCU:マイコン,STM32マイコン,Cortex-M0+コア,Cortex-M4コアARMマイコン,Cortex-M0+,Cortex-M4,STM32MCU,STM32G0,STM32CubeIDE,STM32G4,Root of Trust,セキュア・ブート,セキュア・ファームウェア更新

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

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

セキュア・ブート

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

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

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

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

セキュア・ブート解釈

図1.セキュアブートの信頼の起点(出典:UM2262)
図1.セキュアブートの信頼の起点(出典:UM2262)

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

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

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

表6. セキュア・ブート起動時のエラーメッセージ(出典:UM2262)
表6. セキュア・ブート起動時のエラーメッセージ(出典:UM2262)

パソコンで例えると、従来ブートが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プロジェクトを新規作成します。

STM32CubeIDEのSW4STM32プロジェクトインポート
STM32CubeIDEのSW4STM32プロジェクトインポート

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

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

STM32CubeIDE Projects Converter
STM32CubeIDE Projects Converter

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

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

2種類のRoot of Trustサンプルアプリケーション
2種類のRoot of Trustサンプルアプリケーション

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

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

図15. アプリケーションのコンパイルステップ(出典:UM2262)
図15. アプリケーションのコンパイルステップ(出典:UM2262)

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

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

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

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

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

図2.セキュアファームウェア更新プロセス(出典:UM2262)
図2.セキュアファームウェア更新プロセス(出典:UM2262)

デュアルファームウェアイメージは、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付録の章に、これら詳細が記載されています。

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