ルネサス エレクトロニクス株式会社 (Renesas Electronics Corporation)
検索

Root of Trust を実現する車載MCU RH850 および 車載SOC R-Car における Secure Boot の紹介 #1

Philip Lapczynski
Philip Lapczynski
Principal Engineer, S/W
掲載: 2021年12月8日

Secure Boot Introduction Blog

こんにちは。Renesas オートモーティブソリューション事業本部 Principaal Engineer Phil Lapczynskiです。私は10年以上、自動車セキュリティ、OTAソリューション、ブートローダー関連業務に従事しており、4年前からルネサスのセキュリティチームに参加しました。私はセキュアブートの概念を紹介する一連のブログ記事を通して、ルネサスの車載用MCUやSoCを用いてどのようにそれらが実現されているかを説明できることをうれしく思います。私からまずセキュアブートについて紹介します。このブログはこの3部構成のシリーズの第1部で、読者にセキュアブートとは何であり、なぜ必要なのかといった基本的な理解をしていただくことを目的としています。同僚の山中 聡氏と私からのセキュアブートのブログを楽しみにしてください。

1.    増大する課題

1960年代後半にマイクロプロセッサが車両アーキテクチャに導入されて以来、現代の自動車車両は複雑さを指数関数的に増大させてきました。当初、燃料噴射を電気的に制御するために導入された車両コンピュータは、現在ではシートの暖房から半自動運転まで、車両のあらゆる側面を制御しています。昨今の車両では1億行以上の実行コードを含む自動車用コンピュータが100台以上搭載されています。複雑さを考えると、1億個はマウスのような小動物のDNA塩基対の総数に近づいています。(人間はおよそ3兆3000億のベースペアを持つ)。将来の自動運転車両は3億行以上のコードを持つことになります。

fig1 Million Lines of Code

Figure 1 - http://www.informationisbeautiful.net/visualizations/million-lines-of-code/

この複雑さの増加に伴い、サイバーセキュリティは自動車設計における継続的な懸念事項となっています。運転制御をコンピュータが行うことになるにつれて、サイバーセキュリティインシデントの影響は複雑になっています。さらに問題を困難にすることに、セキュリティアーキテクトはプライバシーとセキュリティを機能安全要件とバランスさせる必要があります。車両内で実行されるコードが正当なものであり、変更されていないことが安全性とセキュリティにおいて不可欠です。これがセキュアブートが必要とされる理由です。セキュアブートは、「実行中のソフトウェアが正統であることをどう判断するのか?」と「実行中のソフトウェアが変更されていないことをどう知るのか?」という問題を解決します。

2.    セキュアブート ブートキャンプ

セキュアブートは、現在の多層組込みシステムセキュリティにおける基礎的な第一歩です。セキュアブートはソフトウェア実行前にその整合性と信頼性を検証するセキュリティメカニズムです。つまり、セキュアブートは組み込みデバイスのブート時に認証されていなソフトウェアや変更されたソフトウェアの検出を可能にします(また、実行を許可しない場合もあります)。セキュアブートはデバイス内における攻撃者の永続性を低下させます。

Fig2 Secure Boot Bootcamp

最も基本的なレベルでは、対象ソフトウェアが期待どおりでない場合、定義された一連のサンクション(制裁)が実行されます。サンクションには、暗号化用の鍵や周辺機器へのアクセスの禁止、CPU のリセット、フォールバックまたはデバイスリカバリプログラムの実行などが含まれます。最高レベルからするとこの概念は至極単純に思えますが、セキュアブートが適切に機能するようにするためのステップは多数あることを覚えてください。

3.    root-of-trustの構築

セキュアブートを実行するには、「root-of-trust」が必要です。これは本質的にすべての次に実行されるステップに対して「トラスト」を確立し、トラストチェーンを不変なものとして固定します。「root-of-trust」はときに「トラストアンカー(trust anchor)」とも呼ばれ、デバイスハードウェアの変更不可能な部分から成ります。この概念を実現するにはいくつかの方法がありますが、それらのすべてには一般的に2つの鍵となる特性があります。それは、1)リセットベクタが安全に制御できること。2) リセットベクタが指すコードはセキュアであることです。
リセット後に実行される一般的なソリューションは、次のものがあります。

  • 変更不可(プログラム固定)のマスクROM
  • プログラム書き込み済みかつロック済みのワンタイムプログラマブル(OTP)コードフラッシュ
  • 保護メモリと専用のセキュリティコア(ブートコア)で実行されるソフトウェア

コードの最初のブロックは、セキュアブート処理を実行する必要があります。その目的は、次のブートステージに向けたシステムを用意し、それを検証するためです。この重要なコードブロックは、開発段階で十分に検証され、複雑さを最小限に抑えておく必要があります。システムの変更不可能な部分として実装されるため、このセクションにあるコードの脆弱性やバグがハードウェアの交換によってのみ修復可能となることがよくあります。

4.    ソフトウェアイメージの検証

セキュアブート実装を構築する次のステップは、ソフトウェアイメージの検証です。セキュアブートでの信頼性と整合性のチェックには、通常2つの異なる方法が使用されます。どちらを選択するかは、設計要件または起動時間などの要因に依ります。

fig3 Verify Software Image

 

4.1    方法1: 対称アルゴリズムを使用したセキュアブート検証

ブートコードを検証する方法の1つとして、メッセージ認証コード(MAC: Message Authentication Code)と呼ばれる鍵付き対称暗号アルゴリズムを使用する方法があります。この方法の利点は、ハードウェアデバイスが使用アルゴリズムのアクセラレータを持つ場合にあります。また、CMACまたはHMACアルゴリズムを使用すると、起動時間が速くなる場合があります。このソリューションの最大の課題は暗号鍵の保存です。対称アルゴリズムに使用される秘密鍵は、HSM（Hardware Security Module）のような保護されたセキュリティ環境内に安全に（セキュアに）保存される必要があります。さらに、MAC生成と MAC検証に同じ鍵が使用されるため、否認不可(non-repudiation)特性は提供されません。この欠点を回避するためには、ハードウェアによる強制的なMAC生成またはMAC検証専用特性を持つよう鍵を設定します。

4.2    方法2: 非対称アルゴリズムを使用したセキュアブート検証

この方法では、非対称暗号アルゴリズム(公開鍵暗号とも呼ばれます)を使用してコードを検証します。非対称アルゴリズムは、一方向関数と言われる数学的な問題に基づいています。一般的にRSAとECDSA の2つのソリューションがあります。基礎となる数学とアルゴリズムは異なりますが、どちらのソリューションも公開鍵と秘密鍵のペアに依存します。

fig4 Asymmetric Algorithms

FlippyFlink, CC BY-SA 4.0, via Wikimedia Commons

イメージを検証するには、信頼できる機関により、秘密鍵を使用して署名機能によってイメージに署名する必要があります。これは、デバイスの外部で行われます。デバイスでは、セキュアブートコードが公開鍵を使用してイメージを検証します。公開鍵は一般に知られますが、秘密鍵は公開鍵を知っていても容易に導き出すことができないため、公開鍵の隠密性は要件とはなりません。公開鍵の隠密性は鍵のセキュリティには必要ありませんが、システムは認証なしに公開鍵を変更または交換できないようにする必要があります。

4.2.1    署名生成

署名を生成するために、入力データからメッセージダイジェスト（ハッシュ）を計算します。これは通常、組み込みデバイスの外部のエンタープライズ設定で作成されます。署名者はメッセージダイジェストを秘密鍵で暗号化します。暗号化されたダイジェストは署名と呼ばれます。署名のタイプは、アルゴリズムとパディングスキーム（RSA-PSS など）に依存します。元のイメージデータと署名がデバイスにプログラムされます。

Fig5 Signing-process (mod)

4.2.2    署名検証

署名検証は、完全性と真正性を確認するために、データとその署名を検証します。検証には、データのメッセージダイジェスト（ハッシュ）を計算し、復号化された署名と受信したダイジェストの比較が含まれます。

fig6 Verification process

5.    chain of trustの構築

セキュアブート実行時にchain of trustを構築する方法はいくつかあります。どの方法を選択するのかは、主にブート時間要件によって決まります。 

fig7 Monolithic Secure Boot

セキュアブートの最も簡単な方法は、イメージ全体が最初のステージブートによって検証されるモノリシックアプローチです。これは簡潔ですが、ブート時間制約のために大抵の実システムでは機能しません。ほとんどの車載システムにおいて、内蔵デバイスはパワーオンリセットからミリ秒以内に起動して最初のタスクを実行する必要があります。このような場合は、段階的なアプローチが取られます。

fig8 Staged Secure Boot

より高度なソリューションでは実行と検証の一部が並列に実行されます。これは、マルチコアシステムで最も一般的な手法です。

fig9 Multicore Parallel Secure Boot

イメージのサイズと複雑さが増加するにつれて、タイミング要件を満たすために暗号ハードウェアアクセラレータが必要になってきます。

6.    幸せな道がそんなに幸せではない時…制裁

これまでは検証に成功したときの一般的な流れだけを紹介しましたが、ステージの1つが検証に失敗した場合はどうなるのでしょうか。この場合、サンクションを適用する必要があります。システム設計者は、検証が失敗したときの対処方法を決定する必要があります。そのステージやその他のシステム要件に応じて、1つ以上の可能なサンクションを発生させる必要があります。

  1. システムリセット
  2. たとえば、暗号鍵や特定のペリフェラルの使用の禁止。
  3. フォールバックまたは代替アプリケーションへの変更
    • このケースは、OTA やダイアグ更新が失敗した場合に特に役立ちます。
  4. 現在の起動ステージに留まる

7.    ソフトウェアの更新方法

ここまででセキュアブートはアプリケーションが正統で変更されないことを保証するためにあるということを理解していただいたと思いますが、新しい(正当な)ソフトウェアでデバイスを更新する必要性にはどのように対応しているのでしょうか？ソフトウェアの更新によって、新しい機能が使用可能となり、バグやセキュリティの脆弱性が修復できますが、重要なのはこれらの更新プログラムをセキュリティで保護することです。新しいソフトウェアがリリースされるたびに、新しいソフトウェアを再度署名する必要があります。リリースされたソフトウェアの署名は、正当なソフトウェア開発のビルド/リリースプロセスの一部である必要があります。このプロセスの複雑さとセキュリティに対処することは簡単ではありません。本稿では、ソフトウェアアップデートセキュリティについては取り上げませんが、TUFやUptaneなど、この話題に直接的に焦点を当てたプロジェクトがあります。また、今後はソフトウェア更新に関する詳細なブログのリリースを予定しています。

8.    結論

まとめると…

  1. セキュアブートは、chain of trustによるセキュアなシステムを作成するために不可欠です。
  2. セキュアブートは以下を提供します：
    • #1 - 認証(不正なイメージは実行が許可されません)
    • #2 - 完全性(イメージの「改ざん」が検出できます)
  3. 3)    セキュアブートでは、通常以下が使用されます：
    • デジタル署名
      • 認証と整合性の確保
      • 秘密鍵 -> 署名に使用
      • 共通鍵 -> 検証に使用
    • (オプション)イメージ/データ暗号化
      • 機密性のために使用
      • アンチクローニング/対偽造に使用
  4. 検証が失敗すると、サンクションが適用されます。
  5. セキュアブートは、ソフトウェアアップデート戦略と共存する必要があります。

Renesas がセキュアな組み込みシステムを構築するための信頼できるパートナーであることを認識いただければ幸いです。セキュアブートシリーズの第2部では、山中 聡氏がRH850 MCU デバイスにおけるセキュアブートコンセプトについて紹介しますので、ご期待ください。

9. 用語集

用語集用語  
ブートローダー 電源投入またはリセット後にMCUまたはSoCで他のソフトウェアの前に実行される最初のコード。ブートの次のソフトウェアの起動やロウレベルソフトウェアの更新などの一般的な機能のサポートなどでセキュアブートを容易にします。
root-of-trust 出典: NIST SP 800-172
特定の重要なセキュリティ機能を実行する、信頼性の高いハードウェア、ファームウェア、およびソフトウェアコンポーネント。root-of-trustは本質的に信頼されるため、設計上安全である必要があります。root of trustは、セキュリティと信頼を構築するための強固な基盤を提供します。
RSA 出典: NIST SP 800-15
RSAはPKCS #1で指定された公開鍵署名アルゴリズムです。リバーシブル公開鍵アルゴリズムとして暗号化にも使用できます。
セキュアブート コンピュータのプロセスでは、デジタル署名やMACを使用して、ブートソフトウェアの実行前に信頼性と整合性を検証します。
MaskROM アドレスとデータが集積回路に物理的にエンコードされる読み取り専用メモリの一種。フラッシュメモリは大部分のアプリケーションでMaskROMに取って代わりましたが、デバイスの初期起動にはMaskROMまたはOTPを使用するのが一般的です。
秘密鍵 (対称) 暗号アルゴリズム 出典: NIST SP 800-175B Rev. 1
操作とその補数 (暗号化と復号化など) に同じ秘密鍵を使用する暗号化アルゴリズム。鍵は秘密にされ、秘密鍵または対称鍵と呼ばれます。
公開鍵 (非対称) 暗号化 (PKC) 出典:
NIST SP 800-12 Rev. 1
NIST SP 800-56B Rev. 2
暗号化およびデジタル署名に公開鍵と秘密鍵のペアを使用する暗号化システム。公開鍵と秘密鍵の2つの関連キーを使用する暗号方式。公開鍵から秘密鍵を生成することは計算上不可能な特性があります。公開鍵暗号方式では、1つ以上のペア (公開鍵と秘密鍵) を使用することで、共有されている秘密鍵を使用せずに、異なる当事者間で安全にやりとりができるようになります。
メッセージ認証コード (MAC) 出典: NIST SP 800-108
対称鍵によってパラメータ化された暗号化アルゴリズム。各アルゴリズムは、任意の長さの入力データに対して、指定された長さの出力値(入力データのMACと呼ばれる)を生成することができます。MACアルゴリズムを使用して、データの発信元認証とデータ整合性を提供できます。
CMAC 出典: NIST SP 800-108
暗号ベースのメッセージ認証コード (NIST SP 800-38B で指定されているとおり)。
HMAC 出典: NIST SP 800-108
鍵付きハッシュ メッセージ認証コード (FIPS 198-1 で指定されているとおり)。
ハッシュ関数 出典: NIST SP 800-108
任意の長さのビット文字列を固定長ビットに変換する関数。承認されたハッシュ関数は以下の条件を満たすように設計されています。
特性：
  1. (一方向) 出力から入力値を推測することが計算上不可能。
  2. (衝突耐性) 2つの異なる入力値が同じ出力になることが計算上不可能。
FIPS 180-3 で承認済みのハッシュ関数が指定されています。
デジタル署名 出典: NIST SP 800-12 Rev. 1
適切に実装されたデータの暗号化変換は、1. 発行元の認証、2. データの整合性、および 3. 署名者の否認防止のサービスを提供します。
否認不可 出典: NIST SP 800-18 Rev. 1
情報の送信者が配信の証明を提供され、受信者が送信者の身元の証明を提供されることを保証するので、情報の処理を後で否定することもできません。
パディング (暗号化) 出典: https://en.wikipedia.org/wiki/Padding_(暗号)
パディングは、メッセージの先頭、中間、または末尾にデータを追加することを含む、暗号化操作を実行する前のいくつかの明確な手法のひとつです。

10. 略称

   
CMAC 暗号ベースのMAC
ECDSA 楕円曲線デジタル署名アルゴリズム
HMAC ハッシュベースのMAC
HSM ハードウェアセキュリティモジュール
ICU インテリジェント暗号ユニット
MAC メッセージ認証コード
MCU マイクロコントローラユニット
OTP 1回のみプログラム可能
ROM 読み取り専用メモリ
RSA Rivest, Shamir, Adelman (アルゴリズム)
SOC システムオンチップ
TUF 更新フレームワーク

この記事をシェアする