Raspberry Pi のマイクロコントローラ RP2350 に対して、Ledger の研究チームがかなり手の込んだ物理攻撃を試し、永久に無効化されたはずの Secure debug を復活させた、というのが今回の話です。しかもやみくもにレーザーを当てたのではなく、まず photon-emission microscopy で狙う場所を絞り込み、そのあと laser fault injection で必要なビットを立てています。単に「壊せた」ではなく、どの防御がどこで崩れるかを丁寧に示した点が重要です。現実の脅威としてはかなり特殊ですが、ハードウェアの“永久設定”がどこまで頼れるのかを考える材料になります。
Ledger Donjon が扱ったのは、Raspberry Pi の RP2350 です。これは Arm Cortex-M33 か RISC-V Hazard3 のどちらかを起動時に選べるデュアルコア MCU で、Secure boot、Armv8-M TrustZone、永久の debug-disable 設定、そしてクロックや電源の乱れを検出する glitch detector などを備えています。研究チームは、RP2350 Hacking Challenge の設定を A4 revision の実機で再現しました。公開鍵の SHA-256 fingerprint を OTP に書き込み、Secure boot を有効にし、CRIT1.DEBUG_DISABLE = 1 で debug を永久無効化し、glitch detector も最大感度にしています。さらに、ページ 48 には Secure は read-write、Non-secure は inaccessible というロックを与えた状態を作りました。
攻撃の狙いは DEBUGEN という register です。RP2350 では、CRIT1.DEBUG_DISABLE が一見すると debug 経路を完全に閉じますが、Secure software から DEBUGEN の全ビットを立てると、その制限を上書きできると datasheet に書かれています。DEBUGEN には core ごとの Mem-AP を有効化するビットと、その Mem-AP から Secure access を許可するビットがあり、Secure debug を使うには両方が必要です。つまり、ここが崩れると Secure memory の読み書きや halt、single-step、register inspection まで通ることになります。
ただし、狙う場所を見つけるのが難しい。そこで最初に使ったのが photon-emission microscopy です。トランジスタの切り替えに伴う微弱な近赤外光をカメラで拾い、DEBUGEN のビットを交互に切り替えるループを繰り返し観測して、差分を取ることで発光の強い場所を絞りました。ノイズや温度変化を抑えるために多数のフレームを平均し、異なるビットマスクの差分を比較しています。その結果、DEBUGEN bits 0〜3 に対応するらしいホットスポットがカメラ視野内の3つの領域に見つかりました。ここで分かったのは「正確な記憶素子そのもの」ではなく、少なくともその近傍です。
その後、980 nm の pulsed laser を使った laser fault injection に移ります。最大 2.97 W のうち約 40%、つまりおよそ 1.2 W で、100 ns pulse を 50x objective 越しに照射しました。先ほどの PEM で絞った範囲をスキャンし、SWD からの応答を見ながら 2 か所の反応点を校正します。一方の位置に当てると core 1 の Mem-AP が有効になり、もう一方では SDeviceEn = 1 が返って Secure access が立った可能性を示しました。両方のビットを立てるには、片方が立つともう片方が落ちることもあるため、交互にパルスを当てて調整しています。最終的に Secure debug は数秒で有効化され、しかも一度立てたビットはそのまま残りました。20x objective では再現できなかったとあり、スポットが広すぎて「立てる場所」と「消してしまう場所」を同時に照らしていたのではないか、と説明されています。
研究チームはその後、Secure debug を使って OTP の secret を取り出します。challenge では起動時に署名済み firmware が page 48 を確認し、次に runtime lock をかけて Secure / Non-secure の両方から secret を読めなくします。ところがこの攻撃では、rescue reset を使って chip を止めることで、firmware が runtime lock をかける前に割り込めました。その結果、ページはまだ Secure-readable のままで、OTP 内の secret を回収できた、という筋書きです。攻撃には物理アクセスと破壊的な前処理、さらに約 25 万ドルの実験装置が必要だとされており、何でも突破できる万能技ではありません。それでも、永久 disable とされる設定にも、別の経路が残っていれば物理攻撃で戻されうることを示した形です。
この話でまず引っかかるのは、DEBUG_DISABLE があるのに DEBUGEN でひっくり返せる、という設計です。もちろん datasheet に書いてある以上、メーカーが隠していたわけではありません。ただ、一般的な印象では「永久無効化」は最後の砦に見えるので、その上に Secure software からの override を置くのは、かなり微妙なバランスだと思います。実運用では、製造時のテストやデバッグを残す都合があるのだろうし、完全封鎖は便利さを大きく犠牲にするのでしょう。それでも、攻撃者の立場から見ると「ここさえ立てれば戻る」という一点が存在するだけで、設計全体の印象はかなり変わります。セキュリティは、強い言葉より例外の少なさで評価されるのだと感じます。
もうひとつ面白いのは、今回の本丸が暗号アルゴリズムでもバグでもなく、物理層の細い穴だったことです。PEM で場所を探し、LFI でその近辺を突く、という流れはかなり研究者らしいのですが、同時に「この種の防御は、ソフトウェアの正しさとは別の次元で壊れる」という事実を突きつけています。DEBUGEN に冗長化や多数決が入っていないことも効いています。OTP 側には three-of-eight vote や majority vote があるのに、debug 側にはそれがない。そこに差がある以上、攻撃者はより脆い方を狙うでしょう。ハードウェア防御は全部を同じ強度で固めるのが難しく、結局は“どこが雑か”が露出します。今回の結果は、その典型に見えます。
この実験がそのまま一般ユーザーへの直接の危険かというと、そうではありません。約 25 万ドル級の装置、背面 decap、SWD を伴うベンチ、そして chip への物理アクセスが要るからです。だから「RP2350 は終わりだ」と騒ぐのは違うと思います。むしろ重要なのは、どの脅威を本当に想定するかです。端末を分解できる相手、研究機関レベルの装置を持つ相手、あるいは量産後の不正解析をする相手まで含めるなら、debug の扱いはもっと慎重であるべきだし、ログやファーム更新、OTP のロック手順まで含めて設計し直す必要が出てきます。
逆に言うと、こうした攻撃が成立する場面では、単に「Secure boot がある」「debug を無効化した」で安心してはいけません。攻撃の流れを見ると、最初に PEM で座標を絞り、次に LFI でビットを立て、最後は rescue reset のタイミングで runtime lock を先回りしています。防御側は、機能ごとの境界だけでなく、初期化順序や再起動の窓まで見ないといけない。ここはソフトウェアの secure coding と似ていて、仕様どおり動くことと、攻撃に強いことは同じではありません。今回の報告は、そのズレをはっきり見せた点で価値があると思います。
Raspberry Pi は RP2350 Hacking Challenge を通じて研究者に防御検証を促していました。そこは評価したいです。実機を相手にした指摘が出て、それが revision A4 に反映されたうえで、なお別の抜け道が見つかった。こういう往復があるからこそ、ハードウェアの防御は少しずつ固くなります。問題は、研究者が見つけた「抜け道」を、単なる面白いデモで終わらせるのか、それとも設計見直しの材料として扱うのかです。少なくとも今回のように、debug の上書き経路、OTP のロック順序、そして glitch detector の実効性が同じレイヤーで語られると、メーカー側は個別機能の修正だけでは済まなくなるはずです。
私が見るに、この報告の本質は「レーザーで壊した」ことより、「壊れた後に何が読めるかまで証明した」点にあります。Secure debug を開けただけなら、派手だが限定的です。そこから OTP の secret を取ったことで、攻撃の価値が一段上がった。つまり、デバッグ経路は単なる開発用インターフェースではなく、秘密領域へ続く実質的な鍵だということです。そう考えると、debug disable は見た目以上に重い設定で、設計者はその例外を極力減らすべきだと改めて思います。
参考: Photon-Emission-Guided Laser Fault Injection Enables RP2350 Secure Debug | Ledger Donjon
