EU年齢確認アプリ、２分でハックされる？！その内容と評価

欧州委員会委員長がEU年齢確認利用可能になったと発表

去る4月15日、EUのフォンデアライエン欧州委員会委員長がEU年齢確認アプリが利用可能になったとアナウンスしました。

ところが、それから程なくして、以下のような「２分でハックできる」というようなレポートが上がり始めました。

協力者あり攻撃

１つ目は協力者ありの本人による攻撃です。ポイントは、

1. 一度年齢確認用のクレデンシャルの発行を受けると、回数無制限で使えてしまう。
2. 使用にあたっては、PINや生体情報は特に必要ない。
3. （このクレデンシャルは、ハードウェアにもApp Instance にもバインドされておらず、他のスマホに持っていくこともできるという情報も…。まぁ、協力者あり攻撃の場合、攻撃者のスマホで協力者がクレデンシャルの発行を受ければよいので、これ自体はあまり重要ではないですが。）

です。なので、18歳以上の協力者を得た18歳未満の攻撃者は、18歳以上というクレデンシャルの発行を受けて、それを無制限に利用可能ということになります。電話をroot化していることなどが必要になりますが、本人がやるので、それはできてしまいますね。なので、脅威モデリング的には、本人も電話もウォレットアプリのインスタンスも信用できない前提でどうするか、ということなのですが、今回リリースされたものは、比例性の原則などから、そこには目をつぶる形になっているようです。

検証者における検証実装エラー

もう一つ上がってきたレポートは、検証者において年齢認証をバイパスできるというものでした。ただこれはどうなんですかね…。使っている「発行者 (issuer)」はサンプル用の発行者ですし、「検証者 (verifier)」もサンプル用です。流れ的には、

1. サンプル用発行者で、年齢確認用のmdoc/sd-jwtの発行を受ける。
2. これを使うと、年齢確認を必要とするサンプルサイトにログインできてしまう。

です。以下のデモをご覧ください。

なんですが、この発行者も検証者も成功したときにはこんなふうに動くよ、というデモをやっているだけのものに見えます。mdoc/sd-jwtの発行を受けるにも特に身分証明書の確認は必要無いようですし。検証者側も公開されているコードを見る限りちゃんと検証していません。具体的には、DocumentValidator.kt では一応署名検証はしていて、発行者がトラストリストに入っているかも検証しているようですが、それが失敗してもクレデンシャルに入っていた情報を詰めた trust_info というデータ構造を返し、その中に age_over_18 という claim が入っていれば、年齢確認成功としてしまうというふうになっているように見えます。

ただ、これはあくまでデモアプリの上でですからね。もちろんこのデモアプリのコードをそのまま流用して本番サイトを作ったらアウトですが、ちょっと騒ぎすぎな感じもします。

ただまぁ、くれぐれも実装される向きにおかれましては、

1. ちゃんと署名検証する
2. ちゃんと信頼できる発行者までのトラストチェーンの検証もする
3. この結果をアクセス管理に反映する

ことをお忘れなきように。これって、デジタル庁の「属性証明の課題整理に関する有識者会議」でも言い続けていたことなんですけどね。

あと、フォンデアライエン委員長の「子どもを守るのはプラットフォームではなく親だ」ということを実装しようとすると、親子関係の証明が必要なんですが、年齢確認だけではそれはできません。

更にもう一つ。ここで取り上げられている年齢確認アプリは、ISO/IEC 27566などでいう「年齢保障フレームワーク」とは異なります。「年齢保障フレームワーク」のうちの「年齢確認」コンポーネントの部分にあたります。

なお、チャッピーに4月16日時点のソースコードの解析をしてもらったので、以下に付録でつけておきます。内容が正しいかどうかは未検証です。（最初の方ちょっとだけ見たけど。）エンジニア各位におかれては、おかしなところなど見つかったらご教示いただければ幸いです。

付録A. ChatGPTによるOpenID4VP処理部分のソースコードの検証

1. Wallet posts the response to /wallet/direct_post.
   The repo docs identify /wallet/direct_post as the wallet-response endpoint. The backend path that processes that response is PostWalletResponseLive.invoke at PostWalletResponse.kt:223-233, which calls doInvoke(...) at 235-265.
2. The response is submitted and each vp_token item is validated.
   In PostWalletResponse.kt:318-334, submit(...) converts the wallet payload with responseObject.toDomain(...). Inside AuthorisationResponseTO.verifiablePresentations(...), each VP element is passed to validateVerifiablePresentation(...).bind() at PostWalletResponse.kt:100-155, specifically 136-145.
3. For mso_mdoc, the backend takes the MSO mdoc validator path and stores trust info.
   In ValidateSdJwtVcOrMsoMdocVerifiablePresentation.kt:92-101, the Format.MsoMdoc branch calls validator.validateMsoMdocVerifiablePresentation(...) and then addTrustInfo(transactionId, trustInfo). The trust-info store helpers are at 54-68.
4. The backend does perform real chain and issuer-signature checks.
   In DocumentValidator.kt:80-105, ensureValidWithTrustInfo(document) runs the document validation sequence. The issuer signature check is ensureValidIssuerSignature(...) at 137-146. The chain-trust check is ensureValidChain(...) at 218-226. Trust metadata is assembled in buildTrustInfoFromResults(...) at 234-263.
5. But trust/signature failure is downgraded to trust_info, not enforced as rejection.
   The critical code is DeviceResponseValidator.kt:95-125. The comment at 95-98 says the method “does not fail due to trust issues.” At 104-118, if documentValidator.ensureValidWithTrustInfo(document) returns Left, the code creates defaultTrust with issuerInTrustedList=false, issuerNotExpired=false, and signatureValid=false, then still returns DocumentWithTrust(document, defaultTrust). At 122-125, it returns a successful DocumentValidationResult.
6. The presentation validator then accepts the VP anyway unless issuerAuth is missing.
   In ValidateSdJwtVcOrMsoMdocVerifiablePresentation.kt:159-182, validateMsoMdocVerifiablePresentation(...) calls ensureValidWithTrustInfo(...) at 166-171, extracts documents and trustInfos at 173-174, and then only enforces that document.issuerSigned.issuerAuth is present at 176-179. It does not require signatureValid, issuerInTrustedList, or isFullyTrusted to be true before returning success at 182.
7. Because of that, the wallet response is stored and the transaction moves to Submitted state.
   Back in PostWalletResponse.kt, submit(...) returns a Submitted presentation at 318-334, and doInvoke(...) stores it at 249-252. So the verifier backend accepts and stores the wallet response even when trust/signature failed in the permissive mdoc path above.
8. When the verifier UI polls /ui/presentations/{transactionId}, the backend attaches trust_info to the response.
   The repo docs identify GET /ui/presentations/{transactionId} as the verifier’s wallet-response endpoint. In GetWalletResponse.kt:119-132, found(...) gets the stored trust info with ValidateSdJwtVcOrMsoMdocVerifiablePresentation.getTrustInfo(...), copies it into the returned wallet response, then clears the store.
9. The frontend polls that endpoint and receives vp_token plus optional trust_info.
   In presentation.ts:68-114, GetPresentationState(transactionID) fetches GET /ui/presentations/${transactionID}.
10. The frontend sets trust_info, but independently decodes proof_of_age and uses its attributes as the success source.
    In App.tsx:178-191, if data.trust_info exists it is stored, but the code then decodes data.vp_token.proof_of_age and sets verifiedData from firstAttestation.attributes. Then at App.tsx:211-221, isAgeOver18 is computed only from whether verifiedData contains age_over_18=true.
11. The success message is driven by verifiedData, while trust is rendered separately.
    verification-texts.tsx:19-25 shows “You have successfully proven your age” purely from the eu.europa.ec.av.1:age_over_18 value. Separately, App.tsx:246-253 renders TrustInfoDisplay only as an additional component. In trust-info.tsx:78-145, that component shows a scorecard; it does not gate the success message.