Photon-Emission-Guided Laser Fault Injection Enables RP2350 Secure Debug
Photon-Emission-Guided Laser Fault Injection Enables RP2350 Secure Debug (donjon.ledger.com)
要約
本記事は、Raspberry PiのRP2350マイクロコントローラーにおいて、フォトンエミッション顕微鏡法を用いてデバッグ機能を有効にするレジスタを発見し、レーザーパルス攻撃によって永続的に無効化されていたデバッグアクセスを復旧した手法について解説しています。この手法により、チップのセキュアワールドへのアクセスが可能になり、ワンタイムプログラマブルメモリに保存されていた秘密情報を抽出することに成功しました。ただし、この攻撃には物理アクセスと高価な実験装置が必要です。
全文翻訳
Photon放射誘導レーザーフォールトインジェクションによるRP2350セキュアデバッグの実現
TL;DR
— フォトン放射顕微鏡により、Raspberry Piマイクロコントローラーのデバッグ機能を有効にするレジスタの位置を特定できました。
— 2つの近接した位置へのレーザーパルス照射により、チップのセキュアワールドへのデバッガーアクセスが復旧しました。これは、デバッグ機能が永続的に無効化されていたにもかかわらず可能でした。
— レスキューリセット後のそのアクセスを利用して、ワンタイムプログラマブルメモリから秘密情報を回収しました。リセットにより、ファームウェアが実行時ロックを適用する前にチップが停止したため、ページはセキュア読み取り可能なままでした。
— この攻撃には、物理アクセス、破壊的な準備、および約25万ドルの実験室設備が必要です。
RP2350のセキュリティモデル
RP2350はRaspberry Piのデュアルコアマイクロコントローラーです。各プロセッサソケットは、ブート時にArm Cortex-M33またはRISC-V Hazard3コアのいずれかを選択できます。そのハードウェアセキュリティ機能には以下が含まれます。
- セキュアブート:ワンタイムプログラマブルメモリ(OTP)にプロビジョニングされた公開鍵フィンガープリントに対して署名付きファームウェアを認証します。
- Armv8-M TrustZone:セキュア実行状態と非セキュア実行状態を分離します。
- 永続的なデバッグ無効設定。
- クロックまたは電源操作によるタイミングの乱れを検出するためのグリッチ検出器。
Raspberry Piは、RP2350ハッキングチャレンジを通じて、これらの保護機能を評価するよう研究者に積極的に呼びかけてきました。最初のチャレンジは2024年8月から12月にかけて、オリジナルのチップに対して実施されました。いくつかの発見に対処した後、Raspberry PiはA4リビジョンをリリースしました。これが我々がテストしたバージョンです。
永続的なセキュリティ設定とブート公開鍵フィンガープリントは、ワンタイムプログラマブル(OTP)メモリに格納されます。各ビットは一度だけ0から1に反転でき、元に戻すことはできないため、そこに書き込まれた内容はチップの寿命まで持続します。
OTPは、2つの永続的な、またはハードロック行によって保護された128バイトのページに編成されています。ページnの場合、PAGEn_LOCK0はオプションの読み書きキーとキーが入力されない場合の動作を設定し、PAGEn_LOCK1にはハードウェアで強制されるLOCK_SとLOCK_NSの権限が含まれます。これらの状態は、読み書き可能から読み取り専用またはアクセス不可へと進むことはできますが、より寛容になることはできません。
OTPサブシステムは、セキュリティ関連フィールドに冗長なエンコーディングを使用しています。RP2350データシートによると、クリティカルフラグは「8つの連続するOTP行にわたる3分の8の多数決でエンコード」され、OTPロックビットは「多数決によるトリプル冗長」です。
OTPリセット時に、永続的なLOCK_SとLOCK_NSの値は、ページごとのランタイムロック(ソフトロックとも呼ばれます)を初期化します。ファームウェアはこのロックを次のOTPリセットまで強化できますが、緩めることはできません。ランタイムの変更は、そのリセット後も持続しません。
外部デバッガーは、Armのシリアルワイヤデバッグ(SWD)インターフェースを介してRP2350と通信します。リクエストはまずシリアルワイヤデバッグポート(SW-DP)に到達し、その後アクセスポートにルーティングされます。ここで使用されているCortex-M33構成では、各コアにはシステムバスに接続されたメモリアクセスポート(Mem-AP)があります。有効化されたMem-APにより、デバッガーは許可されたメモリとペリフェラルを読み書きできます。別途常にオンのアクセスポートであるRP-APは、一連のリセットおよびリカバリ制御を公開します。
セキュアデバッグとは、セキュア属性を持つMem-APアクセスを指します。デバッガーは、アクセス制御ロジックが許可するセキュアメモリマップドリソースとトランザクションを実行し、セキュア状態で実行中のコアを停止または検査できます。
永続的なCRIT1.DEBUG_DISABLEフラグは、このパスを閉じることを目的としています。このフラグが設定されると、両コアのMem-APのイネーブル信号がゼロになり、「APがいかなるバスアクセスも実行できないようにする」と同時に、ファクトリテストJTAGインターフェースとRISC-Vデバッグモジュールのアクセスポートが無効になります。SW-DPとRP-APは応答し続けますが、どちらのコアのMem-APもシステムバスにアクセスできません。
ただし、オーバーライドが存在します。メモリマップドレジスタDEBUGENにより、セキュアソフトウェアは各コアのMem-AP、およびそれを介したセキュアアクセスを個別に再有効化できます。データシートには、DEBUG_DISABLEは「このレジスタのすべてのビットを設定することで完全にオーバーライドできる」と記載されています。
このエンフォースメントチェーンにおけるクリティカルなオーバーライドが、デバッグインターフェースを我々のターゲットにした理由です。Mem-APへのセキュアデバッグアクセスを取得することは、セキュアメモリの読み書き、コアの停止とシングルステップ、レジスタの検査のための汎用プリミティブです。そのレジスタがフォールトによって設定できるかどうかは、この投稿の残りの部分で回答する質問です。
実験セットアップ
ターゲット構成
Raspberry PiのRP2350ハッキングチャレンジでは、参加者にOTP[1]に格納された128ビットの秘密情報を抽出することが求められました。起動時に、署名付きチャレンジファームウェアは、ページ48が期待される永続ロックを持っていることを確認し、その後、次のOTPリセットまで秘密情報へのセキュアおよび非セキュアアクセスを拒否するランタイムロックを適用します。
我々は、このベンダー定義構成を、我々のA4リビジョンデバイスで再現しました。
- 我々の公開鍵のSHA-256フィンガープリントを
BOOTKEY0にプログラムしました。 BOOT_FLAGS1.KEY_VALIDを0x1、BOOT_FLAGS1.KEY_INVALIDを0xeに設定しました。- セキュアブートを有効にしました(
CRIT1.SECURE_BOOT_ENABLE = 1)。 - デバッグを永続的に無効にしました(
CRIT1.DEBUG_DISABLE = 1)。 - グリッチ検出器を最大感度で有効にしました(
CRIT1.GLITCH_DETECTOR_ENABLE = 1、CRIT1.GLITCH_DETECTOR_SENS = 3)。 - ページ1と2の永続ロックをチャレンジ構成に従って設定しました。
- ページ48の永続ロックを
PAGE48_LOCK1 = 0x3c3c3cに設定しました。これにより、非セキュアアクセスは拒否されました(LOCK_NS = INACCESSIBLE)が、セキュア読み書きアクセスは維持されました(LOCK_S = READ_WRITE)。
セキュアブートを有効にするとCortex-M33コアのみが許可されるため、両方のプロセッサソケットでこれらの実験にArmを使用しました。
サンプル準備とベンチ
デバイスは裏面デキャプスレーションされました。これにより、金属層で覆われた前面ではなく、シリコン基板を通して赤外線光がトランジスタに到達できるようになります。その後、チップをテスト中のデバイスの駆動と監視のためのLedger DonjonのオープンソースプラットフォームであるScaffoldに接続されたドーターボードに再ハンダ付けしました。チップ裏面のリードフレームを除去するとGND接続が切断されるため、銅線でこれを復元しました[2]。
[画像: 分析用ドーターボードに取り付けられた、裏面デキャプスレーション済みのRP2350]
[画像: 攻撃に使用された実験ベンチ]
DEBUGEN: 永続的なデバッグ無効化のオーバーライド
DEBUGENには5つの機能ビットがあります。
| ビット | 名前 | 効果 |
|---|---|---|
| 0 | PROC0 | コア0のメモリアクセスポートを有効にする |
| 1 | PROC0_SECURE | コア0のメモリアクセスポートを介したセキュアアクセスを許可する |
| 2 | PROC1 | コア1のメモリアクセスポートを有効にする |
| 3 | PROC1_SECURE | コア1のメモリアクセスポートを介したセキュアアクセスを許可する |
| 8 | MISC | クロストリガーインターフェースやRISC-Vデバッグアクセスポートを含む追加のデバッグコンポーネントを有効にする |
コアでのセキュアデバッグには、両方のビットが必要です。Mem-APを有効にするビットと、それを介したセキュアアクセスを許可するビットです。
OTPセキュリティフィールドに使用される冗長エンコーディングとは対照的に、データシートにはDEBUGENのビット冗長性、パリティ、または多数決に関する記載はありません。
したがって、我々はレーザーパルスが上記のセキュアデバイスでDEBUGENビットを設定できるかどうかをテストしました。
フォトン放射誘導による位置特定
そのテストでは、まずどこを狙うべきかを知る必要があります。個々のDEBUGENビットを設定するということは、単一レジスタビットのストレージにヒットすることを意味します。これは、多くのフリップフロップのいずれかを妨害するだけで同じスキップフォールトを生成できる、レーザーフォールトインジェクションにおける命令スキップフォールトよりも難しいターゲティング問題です。これは、ランダムスキャンでそれを見つけるのに十分な感度領域を広げます。1つのDEBUGENビットのブラインドスキャンは非現実的です。
トランジスタのスイッチングは、そのアクティビティと相関する微弱な近赤外光子を放出するため、その放出を繰り返し実行で収集することで、選択された制御が状態を変更する場所を明らかにできます。これにより、フォトン放射顕微鏡(PEM)はDEBUGENに適していました。メモリマップドレジスタであるため、セキュアソフトウェアはビットをループでトグルでき、測定に必要な繰り返し状態変更を駆動できます。我々はこれを最初の位置特定ステージとして使用し、結果のマッピングにより、後続のレーザースキャンを数マイクロメートルの領域に限定しました。
ターゲットとするビットが異なるだけで、選択されたDEBUGENビットを繰り返しトグルするループを比較しました。レジスタのフォトン放射は、カメラ自身のノイズや、温度のようなゆっくりとドリフトする周囲条件に敏感であるため、単一のフレームでは何も明らかになりません。各ループの多くのフレームを平均化することでランダムセンサーノイズが抑制され、2つの平均スタックを減算することで、共有されたすべてのものがキャンセルされました。静的背景、センサーオフセット、熱放射、および選択されたビットに関連しないスイッチングです。取得中に2つの値をインターリーブすることで、ゆっくりとしたドリフトがその減算を偏らせるのを防ぎました。残ったのは、選択されたビットを追跡する放射でした。
[画像: DEBUGENマスク0x3と0xcの200回のフルビューフォトン放射キャプチャの平均スタック、およびそれらの符号付き差分。]
マスク0x3とマスク0xcの全200回の取得の平均スタック、およびそれらの符号付き差分。赤は正、0x3の方が放射が大きいことを示します。青は負、0xcの方が放射が大きいことを示します。以下の位置特定マップは、取得順序をさらにバランスさせてから、一致した差分を結合します。
異なるビットマスク間での繰り返し比較により、カメラ視野の3つの領域にわたるDEBUGENビット0〜3に関連するコンパクトなサイトが露出しました。
[画像: ダイの赤外線概要図、3つのマークされた領域、およびそれらの領域のズームに色付きのDEBUGENビットサイトを重ねたもの。]
カメラ視野の赤外線概要図、3つのマークされた領域。色付きのピクセルはDEBUGENビット0〜3に関連するサイトを示しています。
これらのゾーンは、各DEBUGENビットに関連するスイッチングアクティビティを示していますが、ストレージセルを直接特定するものではありません。各ビットで観測された複数のホットスポットは、ストレージ要素または関連ロジックに由来する可能性があります。レイアウトデータがないため、両者を区別することはできません。しかし、これらのゾーンは依然として検索空間を大幅に削減します。
発見1 — DEBUGENのフォールトによるセキュアデバッグの実現
レーザーフォールトインジェクション(LFI)には、最大光出力2.97W、約40%(約1.2W)で動作する980nmのパルスレーザーを使用し、50x対物レンズを通して100nsのパルス幅で実行しました。各パルス後、SWD overでデバッグアクセスポートをプローブしました。PEMから見つかった領域内で、LFIスキャンを実行し、そのSWDフィードバックを使用して数マイクロメートル離れた2つの応答性の高い位置をキャリブレーションしました。1つの位置では、パルスがコア1のMem-APを介したバスアクセスを有効にし、PROC1が設定されたことを示しました。もう1つの位置では、Mem-APのControl/Status WordがSDeviceEn = 1を報告しました。これは、PROC1_SECUREが設定された可能性が高いことを示す信号でした。各パルス後に両方のインジケータを確認しました。
[画像: PEMビットサイトが左側、LFIフォールトポイントが右側にある、並置された赤外線ビュー。]
左: DEBUGENビットに関連するPEMサイト。右: LFI赤外線ビューのレーザーフォールトポイント。
1つのビットを設定するパルスがもう1つをクリアする可能性があるため、両方を設定するには反復シーケンスが必要でした。我々のスクリプトは、バスアクセスが可能になるまでPROC1位置をパルスし、次にSDeviceEn = 1になるまでPROC1_SECURE位置をパルスし、バスアクセスが失われるたびに最初の位置に戻りました。位置とパルスパラメータがキャリブレーションされると、シーケンスは数秒以内にセキュアデバッグを有効にしました。興味深いことに、20x対物レンズではこのシーケンスを再現できませんでした。2つの位置は数マイクロメートルしか離れていないため、より広いスポットはおそらくビットを設定する領域とクリアする領域の両方にヒットしたため、正しい値を得ることは不可能でした。
両方のビットが設定されると、それらはさらなるパルスやソフトウェア書き込みなしで設定されたままでした。コア1のMem-APを介してセキュア専用のDEBUGENレジスタを読み取ると、0xcが返されました。DEBUGENはセキュア専用であるため、その成功した読み取りはトランザクションがセキュア属性であったことを確認します。
コア1のMem-APを介したセキュアアクセスを有効にすると、デバッガーは、ACCESSCTRL権限がデバッガーをバスマネージャーとして許可し、ターゲット固有の制御がセキュアAHBトランザクションを許可するメモリマップドリソースを読み書きできるようになります。これらの直接読み取りとは別に、デバッガーはコアを停止およびシングルステップし、そのレジスタを検査または変更できます。これはTrustZoneランタイム分離をセキュアコアを介した抽出によって侵害します。これはブートROMに認証されていないファームウェアを受け入れさせるものではありません。ファームウェアが正常に起動する場合、セキュアブートは依然としてそれを認証しますが、検証後にデバッガーからアクセス可能なランタイム状態を保護することはできません。
ハッキングチャレンジ構成への適用
上記で説明したセキュア属性を持つMem-APアクセスは、セキュアランタイム状態を公開しますが、チャレンジのページ48ランタイムロックは、ファームウェアが実行された後も秘密情報へのアクセスを防ぎます。ページの永続ロックPAGE48_LOCK1 = 0x3c3c3cは非セキュア読み取りを拒否しますが、LOCK_SはREAD_WRITEのままなので、ランタイムロックが強化される前にセキュア属性を持つアクセスを介して読み取り可能でした。
各ブート中に、ファームウェアは最も制限的なバイナリ値0b1111をランタイムロックotp_hw->sw_lock[48]に書き込みます。その後、そのレジスタはページをセキュアデバッグを含むセキュアおよび非セキュアアクセスからアクセス不能にし、したがってMem-APからのセキュアトランザクションによる秘密情報の読み取りを防ぎます。
文書化されているように、ソフトウェアロックは「リセット時にOTPロックページから初期化」され、書き込みは「次のリセットまで」状態を進めます。OTPブロックのリセットは0b1111を破棄し、PAGE48_LOCK1から派生した値(LOCK_S = READ_WRITE)を復元します。
残る問題は、ファームウェアがランタイムロックを再適用するのを許さずに、ロックされたチップをリセットする方法です。RP-APは「外部デバッグが無効になっている場合でも常にアクセス可能」です。CTRL.RESCUE_RESTARTを設定すると、レスキューリセットがトリガーされます。これは完全なシステムリセットであり、ユーザーソフトウェアが実行される前に停止するようにブートROMにフラグを立てます。
ブートROMは、ウォッチドッグ、フラッシュ、またはUSBブートの前にPOWMAN_CHIP_RESET.RESCUE_FLAGをチェックし、それをクリアしてから、コア0を割り込み無効な待機ループに、コア1をベクトル待機パスに保持します[3]。データシートにはCTRL.RESCUE_RESTARTに対する制限は記載されていません。
以下のシーケンスで進めました。
- レスキューリセット。
CTRL.RESCUE_RESTARTを1に設定し、RP-APを介して0にクリアします。チップはリセットされ、ブートROMの待機パスに残ります。署名付きファームウェアは実行されないため、sw_lock[48]は強化されず、PAGE48_LOCK1から派生した寛容な値(LOCK_S = READ_WRITE)のままです。 DEBUGENを0xcにフォールト。 両コアがブートROM待機パスにある状態で、上記のようにPROC1とPROC1_SECUREを設定します。これら2つの設定ビットが値0xcを生成します。- コア1を停止。 セキュアになったMem-APを介して、デバッグ停止制御およびステータスレジスタ(
DHCSR)を通じて行います。 - 秘密情報を読み取る。 保護された読み取りインターフェースを介して、OTP行
0xc08–0xc0fから秘密情報を読み取ります。
テストしたデバイスでこのシーケンスを実行し、チャレンジ秘密情報全体を回収しました。
DEBUGEN_LOCKはレーザー誘発変更を防がない
DEBUGEN_LOCKは、対応するDEBUGENビットへのソフトウェア書き込みをブロックします。各ロックビットは「[…]
DEBUGENのビットをロックするには1を書き込みます。一度設定されるとクリアできません」。データシートでは、これを「偶発的な書き込みを回避する」方法として提示しています。
ターゲットDEBUGENビットが0でロックビットが1の場合のテストでは、ロックが1のままであるにもかかわらず、パルスは依然としてDEBUGENを設定できました。パルスは、対応するDEBUGENの変更の有無にかかわらず、ロックビットも設定しました。成功したシーケンスでは、PROC1とPROC1_SECUREの両方が設定された時点で、5つの機能ロックビットすべてが1でした。ロックビットが1から0に戻るのを見たことは一度もなく、したがって、フォールトが対応するロックを設定した後、後でDEBUGEN = 0を書き込んでも無効な状態を復元することはできません。
ソフトウェアベースの緩和策の限界
Mem-APを介したセキュアアクセスが有効になると、セキュア属性だけではデバッガーとセキュアファームウェアを分離できなくなります。このアクセスは、ハードOTPロックやペリフェラル固有の制御をオーバーライドしません。ACCESSCTRLは特定のターゲットへの直接デバッガーマネージャーのトランザクションをブロックできますが、それ自体ではセキュアコアを制御するデバッガーがコア生成アクセスを引き起こしたり、コアレジスタを介してロードされた値を抽出したりするのを防ぐことはできません。レスキューリセット後、ファームウェアが再構成する前に、ACCESSCTRLはすべてのアクセスを許可するリセット時のデフォルトに戻ります。したがって、ACCESSCTRLは直接Mem-APの露出を減らすのであり、スタンドアロンの機密境界を形成するものではありません。
それにもかかわらず、ファームウェアは、ACCESSCTRLで機密ターゲットへのアクセスを拒否し、次にデバッガートランザクションがそれらの権限を再オープンできないようにACCESSCTRL.LOCKでデバッガービットを設定することで、ポストブートの露出を減らすことができます。セキュアファームウェアは、DEBUGENを定期的にチェックし、予期しない値の場合は、プロセッサコールドリセットドメインをクリアするフェイルセーフリセットをトリガーすることもできます。これらの対策はベストエフォートのランタイム緩和策です。有効化されたデバッガーは、次のチェックの前にコアを停止する可能性があり、レスキューリセットはファームウェアがACCESSCTRLを構成したりモニターを実行したりする前に停止します。したがって、これらはファームウェア前の秘密情報の読み取りを防ぐことはできません。
RP2350の文書化された暗号化ブートフローは、ランタイムロックのファームウェア前の制限と、デバッガーマネージャーフィルタリングのポストブート制限を、2つの異なるマシン状態として示しています。レスキューリセット後、ブートROMは復号化前に停止します。プレーンテキストペイロードはまだ存在しませんが、OTPページの永続的な権限がセキュアアクセスを許可し、他のターゲット制御がトランザクションをブロックしない場合、復号化キーは直接読み取り可能になる可能性があります。通常の暗号化ブート後、プレーンテキストはSRAMに存在します。直接Mem-APの読み取りはACCESSCTRLのデバッガーマネージャー権限に依存しますが、セキュアコア制御は、直接読み取りが拒否された場合でも、コアを介した抽出を許可する可能性があります。これはアーキテクチャ分析であり、テストされた暗号化ブートの結果ではありません。暗号化ブートは、オフライン検査から外部フラッシュを引き続き保護します。
影響と攻撃要件
実証されたシーケンスは、セキュア属性を持つメモリアクセス、セキュアワールド実行の制御、およびランタイムページロックのリセット後のチャレンジ秘密情報へのアクセスを提供します。これには以下のリソースが必要です。
- 破壊的な物理アクセス。 裏面デキャプスレーションはパッケージを永続的に変更し、ダイを露出させます。
- 専門的な実験室設備。 上記の完全なセットアップは、約25万ドルかかります。
- ハードウェアセキュリティの専門知識。 手順には、サンプル準備、ダイナビゲーション、レーザーパラメータ選択、および調整されたレーザー制御、ステージ位置決め、SWD測定が必要です。
結論
RP2350は、OTPに冗長投票でクリティカルなデバッグ無効フラグをエンコードしますが、DEBUGENはそれらの効果をオーバーライドでき、データシートに文書化された同等の保護はありません。我々の実験では、DEBUGEN_LOCKにもかかわらず、レーザーパルスはDEBUGENを変更でき、ロックビットを設定して、ファームウェアが無効な値を復元するのを防ぐことができました。別途、RP-APレスキューリセットは、チャレンジのランタイムページロックを永続値に復元しつつ、ユーザーファームウェアの実行を防ぎました。ソフトウェア可視メカニズムはそれぞれ文書化された機能を実行しましたが、レーザーフォールトとの相互作用によりセキュアデバッグが有効になり、チャレンジ秘密情報が回収されました。差分PEMは最初にビット依存のDEBUGENアクティビティを分離し、誘導されたLFIは、その空間的なリードを永続的なセキュアデバッグに変換しました。システムレベルの教訓は、セキュリティ分析は、個々のメカニズムの孤立ではなく、そのパスに依存するため、永続的なOTP構成から変更可能な制御レジスタおよびリセット動作までの、完全なエンフォースメントパスをカバーする必要があるということです。
公開と謝辞
このフォールトは2026年7月28日にRaspberry Piに開示されました。開示に関する議論と、セキュリティリサーチに対する透明性の高いアプローチについて、Raspberry Piチームに感謝します。
Antoine Plin, Ledger Donjon ハードウェアセキュリティインターン
フットノート
- https://github.com/raspberrypi/rp2350_hacking_challenge RP2350ハッキングチャレンジリポジトリ。我々が再現した参照ロックダウン構成とファームウェアが含まれています。↩
- Courk, Laser Fault Injection on a Budget: RP2350 Edition。↩
- レスキューチェックは、
src/main/arm/varm_boot_path.cのコア0ブートパスのステップ1です。src/main/arm/arm8_bootrom_rt0.Sのvarm_wait_rescueは、割り込み無効なvarm_dead_quietWFIループに入り、コア1はブートROMのベクトル待機パスに残ります。↩