EU年齢確認アプリ、暗号鍵のハードウェア紐付けを必須化。カスタムROM排除へ
EUが開発中の年齢確認アプリで、暗号鍵をデバイスのハードウェアに紐付ける設計が必須要件だと確認された。カスタムROMやLinuxからの利用に影響する。
EUが開発中の年齢確認アプリで、暗号鍵をデバイスのハードウェアに紐付ける設計が必須要件だと確認された。カスタムROMやLinuxからの利用に影響する。
「実装の詳細ではなく、要件だ」
EUの年齢確認アプリのAndroid版リポジトリで、ハードウェアアテステーションの必須化をめぐる議論が広がっている。
きっかけは4月末に立てられたIssueだ。暗号機能を特定のハードウェアに限定する設計では、オープンシステムへ移植できなくなると指摘していた。
これに対し、プロジェクトのコラボレーターであるマネッケ（manecke）氏が回答した。
Hardware-bound attestation is a requirement of this project, not an implementation detail we can simply drop.
プロジェクトの要件であり、単純に外せる実装の詳細ではないという回答だった。同氏はセキュリティレビューと脅威モデルをまもなく公開するとも述べている。
このアプリは、EUのデジタルサービス法第28条（未成年保護）に基づき欧州委員会が開発を主導しているオープンソースのリファレンス実装だ。EUDIウォレット（欧州デジタルIDウォレット）が各加盟国で本格稼働するまでの橋渡しで、正確な生年月日を明かさず「18歳以上である」とだけ証明する仕組みになっている。
仕様書が残した「利用可能な場合」の余白
問題を複雑にしているのは、プロジェクトの技術仕様書そのものに解釈の余地がある点だ。
仕様書のセクション4.2では、年齢確認アプリはデバイスのネイティブ暗号ハードウェアに依拠「しなければならない」（SHALL）と定めている。iOSならSecure Enclave、AndroidならTEE（信頼された実行環境）やStrongBoxが該当する。
ただし、その直後に「利用可能な場合」（when they are available）という条件が付く。
この「when they are available」は、ハードウェアが存在しないデバイスでは別の手段を許容するとも読める。GitHub Issueでも、あるユーザーがこの文言を引用し、ハードウェアに依存しなくてもよいケースが仕様上あるのではないかと指摘した。
さらに仕様書のセクション6.1では、ルート検出やアプリアテステーションチェックはリファレンス実装のスコープ外であり、各国の実装者が判断すると明記されている。つまり、Google Play IntegrityやApple App Attestのような独自の検証を組み込むかどうかは、EUが決めるのではなく各加盟国が決める構造になっている。
仕様書の文言とコラボレーターの回答の間にはギャップがある。仕様書は条件付きの「SHALL」を使い、コラボレーターは「要件だ」と断言した。実運用でどちらが優先されるかは、約束されたセキュリティレビューの公開まで確定しない。
Apple・Googleのインフラに依存するEUの矛盾
GitHub Issueで批判が集中したのは、技術仕様そのものよりもEUの政策との矛盾だった。
GrapheneOSは、Androidの標準ハードウェアアテステーションAPIに対応しており、プロジェクト初期からこの方式の採用を提案していた。このAPIはGoogleのサーバーを介さずデバイスの正当性を検証でき、代替OSの署名鍵をホワイトリストに登録することも可能だ。
一方、Google Play Integrityは事情が異なる。Googleが認定したデバイスとOSでなければパスしない仕組みであり、GrapheneOSのような代替OSは弾かれる。問題は、EU年齢確認アプリの各国版がこの2つのうちどちらを採用するかが実装者の裁量に委ねられている点にある。
| Android標準 hw attestation | Play Integrity | |
|---|---|---|
| 技術的な違い | ||
| Google依存 | 不要 | 必要 |
| 代替OS対応 | 対応 | 非対応 |
| GrapheneOS | ○ | × |
| 検証方式 | 端末を直接検証 | Googleの認定で判定 |
| EU規制との関係 | ||
| 仕様書の扱い | どちらも各国の実装者が選択 | |
| DMAとの関係 | 適合 | 抵触の指摘あり |
GitHub Issueでは、欧州委員会が「準拠アプリリスト」を管理し、アテステーション提供者はそのリストに載ったアプリにのみ年齢証明を発行できる仕組みも批判の対象になった。ソースコードがオープンでも、コミュニティがビルドした版がこのリストに載る保証はない。
あるコメントは、Apple・Googleのアテステーション基盤は米国政府の介入でサーバー側から無効化できると指摘した。年齢確認にこのインフラを使えば、EU市民のデジタルIDが外国政府の判断で機能停止するリスクを抱える。
この議論は、2026年6月に欧州委員会が発表した技術主権パッケージと正面から衝突する。EUはデジタル製品・サービス・インフラの80%超を域外に依存している現状を構造的リスクと認定し、Cloud and AI Development Actを含む政策群でこの依存を減らそうとしている。だが年齢確認の信頼基盤は、まさにそのApple・Googleの上に組み上がりつつある。
Linuxデスクトップとオープンシステムの位置
年齢確認アプリのネイティブLinux版は現時点で存在しない。仕様上はデスクトップからウェブブラウザ経由でアクセスし、モバイルウォレットのQRコードをスキャンする形が想定されている。
つまり、Linuxユーザーが年齢確認を行うには対応するモバイル端末を別途持っている必要がある。
GitHub Issueのコメントで、あるユーザーは「家族全員がLinux（子供たちはRaspberry Pi）を使っている。年齢確認にどうアクセスすればいいのか」と書き込んだ。
別のユーザーは代替案として、EU加盟国の既存IDカード（チップ付き）をUSBカードリーダーで読み取り、年齢証明を生成するオープンなプロトコルを提案した。国が発行した物理カードをそのまま使う方式なら、Apple・Googleのインフラに依存せず、デスクトップ環境からでも利用できる。
EUは自分自身の矛盾を解けるか
EUDIウォレットの法的な提供期限は2026年12月24日だが、4月時点の報告では試験に参加した加盟国は4分の1に届いておらず、全加盟国が期限に間に合う見通しは立っていない。年齢確認アプリはそのウォレットの先行版という位置づけだ。
まもなく公開されるとされるセキュリティレビューと脅威モデルが、ハードウェアアテステーションの具体的な要件を明確にするはずだ。Androidの標準ハードウェアアテステーションAPIを採用すればGrapheneOSとの互換性を確保でき、Play Integrityに依存すればカスタムROMは排除される。
その判断が各国の実装者の裁量に残されたまま展開されれば、ある国ではGrapheneOSが使え、別の国では弾かれる断片化が起きる。
デジタル主権を掲げるEUが、自国民の身元確認を米国企業のインフラで行う設計を容認するのか。それとも、オープンなハードウェアアテステーション標準をEU自身の手で規定するのか。約束されたセキュリティレビューの中身が、その答えの最初の手がかりになる。
