ドイツのeIDAS電子身元ウォレット、Apple・Googleアカウント基盤のデバイスセキュリティ検証構造

 (bmi.usercontent.opencode.de)
1 ポイント 投稿者 GN⁺ 24 일 전 | 1件のコメント | WhatsAppで共有
  • ドイツのNational EUDI Walletは、モバイルデバイスの**セキュリティ脆弱性管理（MDVM）**の仕組みにより、電子身元認証の完全性を維持する
  • MDVMはオペレーティングシステムとハードウェア鍵ストア（HKS）の脆弱性を検知し、リスクが高い場合は認証鍵の使用を遮断する
  • AndroidではGoogle Play Integrity APIとKeyAttestation、iOSではApple DeviceCheck・AppAttestを用いてデバイス完全性を検証する
  • この構造により、電子身元機能の利用時にはAppleまたはGoogleアカウント基盤の検証手順が必須で動作する
  • システム全体は、攻撃者による鍵の複製・悪用防止と高い保証レベルのeID認証維持を目的として設計されている

モバイルデバイス脆弱性管理の概念（Mobile Device Vulnerability Management, MDVM）

  • MDVMは、ドイツのNational EUDI Walletアーキテクチャ内で、ユーザーデバイスのセキュリティ脆弱性を継続的に監視し、認証手段の完全性を維持する仕組み
  • HKS（ハードウェア鍵ストア）およびオペレーティングシステム（OS）の既知の脆弱性を検知し、攻撃リスクが高い場合はRWSCA/RWSCD鍵の使用を遮断する
  • これにより、**電子本人確認（eID）**の過程で高い保証レベルを維持し、攻撃者による鍵の複製・悪用を防止する
  • MDVMは、デバイスおよびアプリのセキュリティ状態検証、デバイスクラス識別、脆弱性検証、利用判断の4つの機能で構成される

背景

  • Wallet Unitは、公開鍵/秘密鍵ペアを通じて複数の身元手段（PIDなど）に接続される認証手段を提供する
  • PID発行時、WB（Wallet Backend）はPP（Provider Party）に対し、その鍵が一定水準の攻撃耐性を備えた認証手段によって制御されていることをOpenID4VCI Key Attestationで確認する
  • ISO/IEC 18045およびEU規則 2015/1502により、高い保証レベルの電子本人確認には強力な認証手段が要求される
  • 認証手段は2つの保証を提供する
    1. 鍵ストアの複製および改ざん防止
    2. ユーザー認証メカニズムへの攻撃防止
  • 1つ目の保証はHSMベースのRWSCDで実装可能であり、ユーザーデバイスとは独立して達成できる
  • 2つ目の保証はユーザーデバイスのセキュリティに依存し、**所持要素（HKSベース）と知識要素（パスワードなど）**で構成される
  • モバイルデバイスのHKSやOSは、事前の脆弱性分析・認証を現実的に行うことが不可能であり、過去にも多数の脆弱性が報告されている
  • したがって、運用中の脆弱性監視体制（MDVM）によって攻撃可能性を下げ、セキュリティが不十分なデバイスではRWSCA/RWSCD鍵の使用を遮断する

MDVMの主な機能

機能 説明
デバイス/アプリのセキュリティ状態検証 デバイスおよびWalletアプリの完全性と真正性を検証し、プラットフォームのセキュリティ機能と**RASP（Runtime Application Self-Protection）**を活用
デバイスクラス識別 デバイスモデル、OSバージョンおよびパッチレベル、HKS情報を検証済みの方法で識別
デバイスクラス別の脆弱性検証 OSおよびHKSの最新の脆弱性情報を確認
デバイス/アプリの利用判断 セキュリティ状態と脆弱性情報に基づき、セキュリティが不十分なデバイスではOpenID4VCI Key Attestationの確認およびRWSCD鍵の使用を遮断

収集シグナル

  • 収集されたシグナルは、脅威対応、デバイスクラス識別、**妥当性検証（plausibility check）**に利用される

  • 主なシグナルソース: KeyAttestation、PlayIntegrity、DeviceCheck、RASP、LPADB、DCVDB

  • 概要

    シグナルソース 対応脅威 シナジー 備考
    KeyAttestation root化、ブートローダー解除、カスタムROM、アプリ改ざん、複製、エミュレーション、リプレイ攻撃など LPADB, RASP DCVDB入力として使用
    PlayIntegrity アプリ改ざん、リプレイ、root化、カスタムROM、GoogleバックエンドベースのMDVM判定、認証情報窃取ツール、オーバーレイ攻撃など KeyAttestation, RASP ブートローダー状態の確認が必要
    iOS DeviceCheck リプレイ、証明書改ざん、プロキシ攻撃、アプリ改ざん RASP デバイス完全性保証は不十分
    LPADB 公開されたKeyAttestation鍵を用いたroot化隠蔽 KeyAttestation -
    DCVDB 既知脆弱性ベースの危険なデバイス検知 KeyAttestation, RASP デバイスクラス識別精度が重要
    RASP アプリフッキング、デバッグ、root化、エミュレーション検知 - 実行中の完全性を継続監視

Android KeyAttestationシグナル

  • HKSベースのハードウェア検証情報を通じて、デバイスモデル、OSバージョン、パッチレベル、ブートローダー状態などを識別する
  • 主なシグナル項目
    • SecurityLevel: HKSタイプ識別（TrustedEnvironment, StrongBox）
    • attestationIdModel/Product/Device: デバイスモデル識別
    • osVersion / osPatchLevel: OSバージョンおよびセキュリティパッチレベル
    • RootOfTrust: ブートローダーおよびVerified Boot状態
    • AttestationApplicationId: アプリのパッケージ名、バージョン、署名証明書ハッシュ
  • GoogleのKey-Attestation証明書失効リストは更新が遅く、公開流出した鍵が依然として利用可能である
  • 一部デバイスでは特定の識別フィールドが欠落する場合があるため、3つのフィールドすべてを評価する必要がある

Android PlayIntegrity Verdictシグナル

  • Google Play Integrity APIを通じて、アプリおよびデバイス完全性を検証する
  • 主なシグナル項目
    • appRecognitionVerdict: アプリが正規版かどうか
    • deviceRecognitionVerdict: デバイス信頼レベル（例: MEETS_STRONG_INTEGRITY）
    • appLicensingVerdict: PlayStore経由でインストールされたかどうか
    • playProtectVerdict: Play Protectリスク評価
  • MEETS_STRONG_INTEGRITYは、直近12か月以内のセキュリティパッチ適用を要求する
  • シグナルの信頼性確保のため署名検証および復号が必要
  • Googleバックエンドの内部評価方式は公開されていない

Android RASP

  • 具体的なソリューションはまだ確定しておらず、要求機能を定義する段階
  • 検知機能
    • App Hooking/Debugging: 動的改変の検知（Frida, Xposedなど）
    • App Repackaging/Tampering: アプリ改ざんおよび再署名の検知
    • UD Rooting/Emulation: root化、仮想化、自動化環境の検知
  • RASPは実行中の完全性監視を提供し、Googleの失効リストとは別のブロックリストを維持して、流出鍵ベースの攻撃を防止する

iOS DCDeviceCheck.AppAttest Attestation

  • Secure EnclaveとAppleサーバーを通じたアプリ認証構造
  • 主なシグナル
    • attestationObject: App Attest鍵がSecure Enclaveで生成されたことを証明
    • credentialId: App Attest鍵識別子
    • RP ID: アプリのApp ID prefix + Bundle ID
  • **Appleのリスク指標（receipt metric）**はプロキシ攻撃の検知に活用可能だが、明確な基準がなく、Appleサーバーとの通信による個人情報露出リスクが存在する
  • iOSではデバイスモデル、OSバージョン/パッチレベルのハードウェアベース情報を提供できず、OS問い合わせでのみ確認可能

iOS DCDeviceCheck.AppAttest Assertions

  • App Attest鍵で生成された署名ベースの検証構造
  • 主なシグナル
    • assertionObject: チャレンジに対する署名を含む
    • keyId: App Attest鍵識別子
    • counter: 署名回数。単調増加でなければならない
  • カウンター値の急激な増加はプロキシ攻撃の可能性を、減少はリプレイ攻撃の可能性を示唆する

iOS RASP

  • Androidと類似した検知機能が求められる
    • App Hooking/Debugging、App Repackaging、App Tampering、UD Rooting、UD Emulation
  • AppleのApp Sandbox、Code Signing、System Integrity Protectionはインストール時点の保護しか提供せず、root化・フッキング・ランタイム改変の検知機能はない
  • RASPは実行中の完全性監視によってこれを補完する
  • Apple文書によれば、App Attestは「正常なデバイスで動作する改ざんアプリは有効なassertionを生成できない」と明記されている

結論

  • MDVMはデバイスのセキュリティ状態をリアルタイム評価し、攻撃可能性が高い環境で認証鍵の使用を遮断することで、電子身元認証システムの信頼性を維持する
  • AndroidとiOSの双方で、プラットフォームのセキュリティ機能とRASPベースの動的保護を組み合わせてデバイス完全性検証の仕組みを構成している
  • GoogleおよびAppleのバックエンド検証基盤への依存性が存在し、非公開の内部評価方式は潜在的な不確実性要因として残る

関連記事

1件のコメント

 
GN⁺ 24 일 전
Hacker News の意見

  • eIDAS 2.0 仕様は特定のハードウェアを要求していない
    単に検証可能な資格証明と暗号学的に署名された証明書を保存する構造である
    ドイツの実装チームは、「ユーザーが Wallet Unit の真正性を検証できるメカニズムを実装しなければならない」という条項を回避しようとしている怠慢に見える
    関連文書は EUDI Architecture and Reference Framework で確認できる

    • 参考実装を見ると、メンテナーたちはGoogle 依存を取り除こうとしていない
      理由は明確ではないが、理由もなく続くものには結局理由があるものだ
      GitHub リポジトリ 参照
    • 5.4 節の Attestation Rulebooks と Attestation Schemes の部分を見ると、関連ルールが明記されている

  • ドイツの実装担当者として言うと、eIDAS 実施規則に従ってattestation メカニズムを使わなければならない
    これは OS の支援なしには動作しない
    現状が Google/Android に限られているのは最善ではないと理解しており、GrapheneOS など他の OS への対応も計画している
    ただ今は優先順位の問題であるだけで、問題を認識していないわけではない

    • 米国企業 2 社の製品に依存するのは「よくない」程度ではなく深刻な問題である
      アカウントロックの事例は多く、こうした依存はむしろない方がましだ
    • アクセシビリティおよび eIDAS の精神に反するという点で違法な要素もある
      結局すべての市民が Google・Apple の利用規約に従属し、アカウント停止時には eID サービスにアクセスできなくなる
      技術的な代替手段は存在するのだから、そうした解決策を見つけるのはあなたの責任だ
    • ドイツ市民として尋ねたい。すべての市民に対して機能しないと分かっていながら、なぜ進めるのか？
      私は Google Play のない AOSP ベースの Android から Ubuntu Touch に移り、今後は postmarketOS へ移行する予定だ
    • Google アカウントへのアクセスを失うのはあまりに簡単だ。復旧も不可能だ
      こうした状況と地政学的リスクを考えれば、特定企業への依存は正当化できない
      「暫定措置ほど恒久的な解決策はない」というのは、開発者としての経験則でもある
    • eIDAS 1 のMobile-ID（SIM ベース）や Smart-ID（サーバー側鍵管理）ですでに解決されていた問題を、
      なぜわざわざ Wallet モデルに変えるのか疑問だ。米国企業 2 社のバックエンドに依存する理由はない

  • attestation そのものを廃止すべきだ
    アプリはどの端末で動いているかを知るべきではない
    ユーザーが自分の端末を自分で保護すればよく、開発者は推奨事項を示すだけで十分だ
    GrapheneOS、root 化、エミュレーター、Linux 互換レイヤーなど、どんな環境でも実行できるべきだ

    • その通り、自分の端末なのだから自分の好きなように使うべきだ
      アプリが米国ビッグテックの「認証」有無を自動で検査するのは不要だ
    • 端末の信頼という概念自体が幻想だ
      root 化されたコンソールやスマートフォンの歴史を見れば、完全なセキュリティなど存在しない
      ユーザーが望むなら、自分の身元を端末に結び付けられるよう任意の選択肢としておくのが望ましい
    • もちろん root 化や改変は自由だが、その結果も受け入れるべきだ
      アプリが自前の完全性を検証できなければ、一部の機能はセキュリティ上不可能になる
      物理的な身分証にも形状やサイズなどの制限があるように、一定の制約は必要だ
    • 現代コンピューティングの原罪は、「セキュア要素」がユーザーではなくメーカーのために設計されたことだ
      NGSCB の時代にこうした要素を法的に禁止しなかったことが問題の始まりだった

  • もし Google/Apple アカウントを失ったらどうなるのか？
    国際刑事裁判所の裁判官のように制裁対象になれば、eIDAS へのアクセスは不可能になる
    欧州社会が今なお米国企業依存の構造を維持しているのは矛盾した現実だ

    • 有名人でなくとも、自動化されたアカウント停止によって社会的排除の状態になり得る
      外国企業 2 社が監視と統制の権限を持つのは危険だ
    • 「ヨーロッパの首都がワシントンにあるなら」、こうしたことは当然なのかもしれない
    • そうなると Waymo にも乗れなくなる

  • このような政策に対する大衆の反対が少ないこと自体が衝撃的だ
    親として子どものインターネット利用を管理する必要性は理解できるが、
    結局は親がやるべきことを国家が代行し、自由とプライバシーを失っている

    • ほとんどの人は、これが自分の人生にどう影響するかを抽象的にしか理解していない
      「政府が私の WhatsApp メッセージを読む」のような具体的脅威でなければ反応しない
    • ドイツでは速度制限論争のような消耗的な話題に関心が分散している
      政治家たちはこうした混乱を利用して本質的な問題を覆い隠す
    • むしろ多くの親はオンラインアクセス制限に賛成している
      子どもたちが巨大企業による注意力の搾取から守られることを望んでいる
      現実世界に年齢制限があるように、オンラインも例外ではあり得ない
    • 人々は自分だけのフィルターバブルに閉じこもり、こうした問題を耳にすることすらない
      民主主義の未来を考えると非常に憂慮すべきだ
    • EU は事実上ロビー活動のプラットフォームとして機能している
      市民ロビーも可能ではあるが、費用と調整が必要なため大企業が主導する
      最近 EU のデジタルインフラがハッカー集団に侵害された事件もあった
      関連記事

  • 特定のハードウェア・ソフトウェア要件は不合理だ
    すべての市民は自分の望むコンピュータを使うべきだ
    認証はパスワードや鍵ペアだけで十分で、望むならTOTP やセキュリティキーを追加すればよい
    スマートフォン以外のコンピュータも存在するという事実を忘れているようだ

    • EU は VISA・MasterCard から独立した決済システムを作ると言うが、結局はアプリストア依存だ
      Apple・Google アカウントがなければデジタルユーロ決済も不可能になる
      政治家と銀行が 2、3 手先を見通せていないのには驚く
    • EU の政策は「ユーザーが自律的にリスク評価する」という方向ではなく、
      サービス提供者がユーザーを保護しなければならないという方向に進んでいる
      結果として対応プラットフォームの制限は避けられない
    • 「あらゆるコンピュータで動作すべきだ」というのは非現実的だ
      法的に Apple II でも動かなければならない、という意味ではないのだから

  • 制裁対象者や特定グループは Play Store へのアクセスが不可能なため、
    eIDAS アプリ自体をインストールできない可能性がある

    • アカウントが必要なら、そういうことになるだろう。
      最近の政治的反対者のアカウント削除事例を見ると、一部の当局にとってはむしろ歓迎すべきことかもしれない
    • しかし個人鍵の保護が核心だ
      スマートカードのようなセキュアデバイスが必要なので、完全に開かれた環境は危険だ
      「代替 Android を使いたい」という気持ちは理解できるが、それが非セキュアな環境であることは認識すべきだ

  • EU がこのようなシステムにどれほど多くの予算を浪費するのか疑問だ
    いったい誰がこれを必要としているのか分からない

  • Self Sovereign Identity(SSI) だけが真の解決策だ
    個人の身元は、いかなる機関や企業にも従属してはならない
    身元とは、ただ「自分自身」であるべきだ
    Google ID や Apple ID ではなく、自己主権型アイデンティティが必要だ

    • しかし「私はただ私だ」というのは現実的な本人確認ではない
      バーで身分証の代わりにそう言うことはできない
      社会的契約の中では機能的な本人確認が必要だ
    • EU はすでに 2019 年に ESSIF(European Self-Sovereign Identity Framework) を作っている
      7 年前からインフラは存在しているのだから、政府が無能だとだけは言えない

  • 「デジタル版ライヒスターク放火事件」が起きる時期なのかもしれない
    ドイツはいつになったら歴史を繰り返す癖をやめるのか、と問いたい