YubiKey 5シリーズを標的とするEUCLEAKサイドチャネル攻撃

 (ninjalab.io)
1 ポイント 投稿者 GN⁺ 2024-09-04 | 1件のコメント | WhatsAppで共有
  • セキュアエレメントは強力な認証の信頼基盤として使われているが、EUCLEAKはInfineonのECDSA実装から秘密鍵を抽出し、YubiKey 5Ciで実証されたサイドチャネル攻撃である
  • 中核となる脆弱性は、Infineon暗号ライブラリの定数時間ではないモジュラー逆元演算であり、14年間にわたり約80回の最高レベルCommon Criteria認証評価を通過してきた
  • 攻撃者はセキュアエレメントに物理的にアクセスする必要があり、ローカルな電磁測定を数回行い、高価な機材・専用ソフトウェア・技術的能力が必要だが、測定自体は数分で十分である
  • 影響範囲は、ファームウェア5.7未満のYubiKey 5 Seriesと、Infineon暗号ライブラリを実行するセキュアマイクロコントローラで、TPMも含まれる
  • FIDOではECDSA秘密鍵の抽出によりデバイス複製が可能になるが、フィッシング対策という観点では、影響を受ける製品でも使わないよりは依然として安全である

EUCLEAK攻撃が狙うポイント

  • セキュアエレメント（secure element）は、秘密値を生成・保存し、暗号演算を実行する小型マイクロコントローラで、Common Criteriaの最高レベルのセキュリティ評価を受けることが多い
  • FIDOハードウェアトークンはWebサービスへのログインに使われる強力な認証手段であり、FIDOプロトコルは主要な暗号プリミティブとしてECDSAを使用する
  • YubiKey 5 Seriesは広く使われているFIDOハードウェアトークンで、セキュアエレメントとしてInfineon SLE78を使用している
  • NinjaLabは、類似のInfineon SLE78ベースJavaCardオープンプラットフォームであるFeitian A22を用いてInfineon ECDSA実装を分析し、サイドチャネル脆弱性を利用した実際の攻撃を設計した
    • 攻撃はYubiKey 5Ciで実証された
    • より新しい製品であるInfineon Optiga Trust MおよびInfineon Optiga TPMセキュアマイクロコントローラにも脆弱性が広がる
  • 脆弱性の原因はInfineon Technologies暗号ライブラリの定数時間ではないモジュラー逆元にあり、14年間と約80回の最高レベルCommon Criteria認証評価の間、発見されなかった
  • 詳細な技術文書はDownload the Writeupで提供されている

影響製品と攻撃条件

  • 攻撃者はセキュアエレメントに物理的にアクセスする必要があり、ローカルな電磁サイドチャネル測定を数回行うことでECDSA秘密鍵を抽出できる
    • FIDOプロトコルでは、これによりFIDOデバイスの複製が可能になる
    • 攻撃には高価な機材、専用ソフトウェア、技術的能力が必要である
  • 影響を受ける製品は次のとおり
    • Infineon暗号ライブラリを内蔵した、すべての既存バージョンのInfineonセキュアマイクロコントローラ
    • 既存バージョンのInfineon TPM
    • ファームウェア5.7未満のすべてのYubiKey 5 Series
  • 該当するセキュアマイクロコントローラは、電子パスポート、暗号資産ハードウェアウォレット、スマートカー、スマートホームなど、ECDSAに依存するさまざまなセキュリティシステムに搭載されているが、EUCLEAKがこれらの製品に実際に適用できるかはまだ確認されていない
  • Feitian A22 JavaCardは研究に使用された旧製品で、現在は販売されていない
    • 現在Feitian Webストアで販売されているInfineonセキュアマイクロコントローラベースの製品は、Feitian独自の暗号ライブラリを使用しており、NinjaLabの把握する限り、この研究の影響は受けない

緩和策と公式情報

  • YubiKeyファームウェア5.7は、2024年5月6日のアップデートでInfineon暗号ライブラリからYubicoの新しい暗号ライブラリへ切り替えた
    • NinjaLabの把握する限り、この新ライブラリはEUCLEAKの影響を受けない
  • Infineonは暗号ライブラリのパッチをすでに保有しているが、NinjaLabの把握する限り、まだCommon Criteria認証評価を通過していない
  • CVEリクエストは却下され、MITREは代わりにCVE-2024-45678を使用している
    • 説明更新のリクエストは保留中である
  • 公式見解は次の文書で確認できる

関連記事

1件のコメント

 
GN⁺ 2024-09-04
Hacker Newsの意見

  • Ars Technicaの記事によると、攻撃者にはユーザー名とパスワードだけでなく、キーへの物理的アクセスも必要で、デバイスを分解した後に返すには再組み立ても必要になるため、決して些細な攻撃ではない
    プラスチックの継ぎ目にマニキュアを少し塗っておけば、改ざんを知らせるカナリアとして使えそう
    ただし、FIDOトークンの弱点も明らかになった。どこに登録したかのリストを自分で管理しなければならず、トークンを紛失したり盗まれたりした場合は、登録済みのすべての場所で自分で失効させる必要がある

    • YubiKeyだけの問題ではない
      NinjaLabによると、Infineon暗号ライブラリを実行するすべてのInfineonセキュアマイクロコントローラは、知られている限り既存の全バージョンでこの攻撃に脆弱
      これには、米国・中国・インド・ブラジルおよび欧州・アジアの複数国の電子パスポートチップ、Samsung・OnePlus端末のセキュア領域、Ledger・Trezorのような暗号資産ハードウェアウォレット、SIMカード、Lenovo・Dell・HPノートPCのTPM、クレジットカード・デビットカードのEMVチップが含まれる
    • KeePassXCをパスワードマネージャーとして使い、ハードウェアキーを使うアカウントごとにタグを付けている
      そのため、キーを紛失したり盗まれたり故障したりしたときに、削除すべきサイトの一覧をすばやく取り出せる
      常に2本のキーを登録し、物理的に分けて保管しているので、1本を失ってもログインできるようにしている
    • この攻撃が些細ではないという点には同意するが、YubiKeyは時に非常に高リスクな環境で使われる
      暗号資産へのアクセスだけでなく、防衛産業企業のような、より深刻な状況も含まれる
      こうした場合、攻撃者はリソースも多く動機も強く、まさにそのような攻撃を防ぐためにYubiKeyを使っている
      したがってキーは依然としてフィッシング耐性のある認証を提供するが、一部のセキュリティ上の期待は崩れたと見るべき
    • リソースが十分な攻撃者なら、同じECDSAキーを入れたバックドア付きの交換キーを製造することもできる
    • 個人なら、このデバイスを中核サービスだけに使い、その他は適切なパスワード管理に頼る形に制限するのが答えかもしれない

  • いちばん面倒なのは、YubiKeyを単に交換できない点
    パスキーを使っていようが非発見可能キーを使っていようが、このキーを廃棄する前に各アカウントを一つずつ回って、脆弱でない新しいキーに切り替える必要がある
    非発見可能である点も問題で、以前どこでYubiKeyを使ったのか思い出せない
    Arsの記事 [0] にはPINの話も出ているが、これはYubiKey固有の機能ではなくFIDOの機能
    [0]: https://arstechnica.com/security/2024/09/yubikeys-are-vulner...
    [1]: https://new.reddit.com/r/yubikey/comments/12bv4sv/fido_pin_s...

    • もう一つの側面として、非発見可能FIDOキーの主な用途である2要素認証のせいでアカウントから締め出されることをより心配している
      以前、米国税関がYubiKeyを含む電子機器を留置したときに実際に経験した
      その後、メールを2要素認証または最終的な認証手段として受け入れてくれるアカウントは多く復旧できたが、AWSを含む一部はそうはいかなかった
      多くのWebサイトは、代替の認証手段やアクセス喪失の結果を明確に説明しないまま、2要素認証の登録を勧めている
    • パスワードマネージャーで追跡している
      YubiKeyが登録されたアカウントには「YubiKey (FIDO)」タグを付けている
    • GitHubのように常駐WebAuthnトークンを使うサイトでは、キーに既知のサイト一覧を表示できる
      ただし、この一連のフロー全体のユーザー体験はまだ期待水準に達していない
    • 個人用YubiKeyを複製したりバックアップしたりできない点がずっと嫌で、そのためあらゆる場所で使うのは避けてきた
    • FIDOデバイスを登録する際に、別の形の2要素認証設定を求めないサイトはまだ見たことがない
      自分の場合は、アプリに保存するTOTPを併用している

  • 「ファームウェア5.7未満のすべてのYubiKey 5 Seriesが影響を受ける」というなら、物理ハードウェアトークンのファームウェアを更新すればよいのだと思っていた
    ところが、YubiKeyのファームウェアはアップグレード不可とされている
    https://support.yubico.com/hc/en-us/articles/360013708760-Yu...
    それならYubicoは無償交換を提供するのだろう？ こういうYubiKeyが何本かあるのだが…

    • YubiKeyはフィッシング防止を目的に作られており、この攻撃には物理的アクセスが必要
      つまり、現実に直接標的にされるほど価値があるなら、そもそもYubiKeyを使うべきではない
      誰かが予備キーをすり替えることができ、手遅れになるまで気づかない可能性がある
    • 5.4.3の5C Nanoを使っているが、無償交換はなく緩和策だけがある
      https://support.yubico.com/hc/en-us/articles/15705749884444-...
    • 前回Infineonチップに暗号を破るバグがあったとき、エストニア国民は新しいIDカードを無償で受け取った
      一方、発売から2か月も経っていなかった自分のYubiKey 4は、ハードウェア証明PIVスマートカードとして動作しなくなった

  • 「定数時間ではないモジュラ逆元計算が原因」というのは、微細な電磁放射のような繊細なサイドチャネルではない
    秘密データによって時間が変わるかどうかは、サイドチャネル監査で最初に確認すべき項目に近い
    すべての演算がデータに依存せず常に同じクロックサイクル数を使うかを検証すればよく、エラーもデータに依存せず固定されたクロックサイクル後に発生しなければならない
    監査担当者がこれをどう見落としたのか疑問だ

    • 正確に言うと、そうした電磁放射サイドチャネルに近いように見える
      論文を正しく理解しているなら、定数時間ではないのはアルゴリズムの実行そのものではなく、外部から観測可能なRFサイドチャネルのデューティサイクルだ
      実行時間が本当に非定数だったなら、最悪の場合USBだけでも攻撃できたはずだが、Infineonの実装は純粋なタイミング攻撃には脆弱ではないようだ
      nonceブラインディングも実装されているが、楕円曲線のサイズよりはるかに小さい乗算マスクを使っているため、総当たりが可能になったのが問題だ
    • ECDSAのコードレビューで最初に確認するものの一つなので、Infineonにとっては恥ずかしいミスだ
    • 同意。もっと高度な攻撃を期待していたが、かっこいいプローブを付けた標準的なタイミング攻撃に近い
      それでもプローブ自体はかっこいい

  • 物理的にYubiKeyへアクセスしようとするほどなら、同じように摩耗していて同じような見た目のキーにすり替えればよい
    そうすれば被害者は自分のYubiKeyが壊れたと信じるか、攻撃者がYubiKeyを使う時間を十分に稼げる
    例えば私にはYubiKeyが2本あるが、誰かが家に忍び込んで予備キーをすり替えたら、私が予備キーを使うまで気づかない
    結局この攻撃は、標的が直接狙うほど価値がある場合にだけ意味があり、そうした標的ならYubiKeyよりもう少し安全なものを使っていそうだ

    • ykman listでYubiKeyの識別情報を確認できるので、キーが壊れたのか実際にすり替えられたのかを点検する手順は簡単に設けられる
      セキュリティ要件が高いなら定期的に確認するか、予備キーの物理的な保管場所を別途保護すればよい
      ハードウェア認証器の中でYubiKeyより安全なものが何なのかも気になる
    • アクセス権があるなら、キーを壊して動作する予備キーとすり替えるのは本当に簡単だ
    • 実際には、YubiKeyがチェーンの中で最も弱いリンクになることはほとんどないだろう
      攻撃者はデバイスを狙ったり、通信を傍受したり、データをホストしているサービスに令状を執行したり、密かに侵入したりできる

  • EUCLEAK説明PDF: https://ninjalab.io/wp-content/uploads/2024/09/20240903_eucl...
    Yubicoのブログ記事: https://www.yubico.com/support/security-advisories/ysa-2024-...

  • NinjaLabの研究は素晴らしい
    Yubicoの勧告で特に興味深いのは、このローカルな複製によってWebAuthnプロトコルのアテステーション（attestation） [1]も無効化される点だ
    このローカル複製攻撃により強く耐えられるようにプロトコルを設計できただろうか？
    「攻撃者は復元したアテステーションキーを使って偽のYubiKeyを作成できる。この場合、make credential中に有効なFIDOアテステーション文が生成され、影響を受けるYubiKeyバージョンに対する組織の認証器モデル選好制御を回避できる。」

    1. https://www.w3.org/TR/webauthn-2/#attestation
    • 攻撃者がリクエスト署名に使われる秘密値を複製する状況なら、その秘密値を持っている以上、複製品と元のデバイスを区別する方法はなさそうだ
      セキュアエレメントの全体的なセキュリティモデルは鍵抽出を防ぐことにあるが、それが可能になるなら、鍵をコンピュータのファイルに保存するのと変わらない
      もちろん鍵を得るにはデバイスを物理的に開ける必要があるので、実際に誰かがキーを持ち去らない限り、コンピュータに保存するよりは安全だ
    • 残念ながら現実的には難しい。アテステーションはほぼ常に、何らかのセキュアハードウェアが発行者により認証された秘密を守り、それによって信頼当事者に自分を認証し、派生・保存された秘密で信頼を継続する構造に依存している
      そのアテステーション秘密値が何らかの方法で抽出可能なら、攻撃者が本物のように振る舞わなくても不正なアテステーションを作る偽の認証器を作成することは防げない
      理論上は、間接アテステーションや認証器ごとの固有アテステーションキーを使って、単一のアテステーション秘密の漏えいによる影響を減らすことはできる
      YubiKeyのように数十万個の認証器が共有するアテステーションキーではなく、そうする方法だが、それでも確率的な緩和にとどまる可能性が高い

  • Yubicoのウェブサイトには、5.7以降は影響を受けないと書かれている
    別のYubico記事 [1] を見ると、5.7リリースの機能の一つが、RSAとECCの基盤となる暗号演算を実行するYubico独自の暗号ライブラリへの移行だとされている
    多くの人がレビューしていることを願う。今のように公開・非公開の実装が数多くある時代に、なぜ独自の暗号ライブラリを使おうとするのかよく分からない
    [1] https://www.yubico.com/blog/now-available-for-purchase-yubik...

    • サプライヤーが原因でセキュリティ問題が起きたのは今回が2度目で、前回はもっと深刻だったからだ
      会社全体が暗号を基盤にしているなら、十分な応用暗号学者を雇って自分たちの運命を自ら制御するのは実際に理にかなっている
    • 組み込みプラットフォームでは既存ライブラリが移植されていないことがあり、プラットフォームがあまりに異なるため移植が現実的でないこともある
      他の理由もあり得るし、非公開ソースでは経済的な考慮も大きい
      特に以前の非公開で、おそらくソース提供形式だったサプライヤー実装から社内実装へ移る場合ならなおさらだ
    • 5.7はいつリリースされたのだろう？

  • Infineonがまたやってくれた。7年前にもこういうことがあった: https://en.wikipedia.org/wiki/ROCA_vulnerability

  • 「Infineon にはすでに暗号ライブラリのパッチがあるが、知る限りまだ Common Criteria 認証評価を通過していない」とされているが、正直これはまったく重要ではない

    • 攻撃そのものとは別に見れば興味深い実験であり、公開する価値はあるが、実際には名目上脆弱なデバイスであっても現実世界への影響は大きくなさそう