2 ポイント 投稿者 GN⁺ 3 일 전 | 1件のコメント | WhatsAppで共有
  • 年齢のみを証明するプライバシー保護型認証として宣伝されているが、実際の配布構造は各国アプリと任意の経路に依存しており、単一のEUアプリとしては動作しない
  • 大手プラットフォームはEU walletの代わりに、パスポートのスキャンとliveness検査を行う一般的なKYC providerを使えるため、プライバシー保護の経路は必須要件ではなく選択肢にとどまる
  • 現在のreference実装の主経路はzero-knowledge proofsではなくISO 18013-5 mdoc with ES256を使用しており、unlinkabilityも強い数学的保証というよりウォレットの使い捨て資格情報のローテーション規則に依存している
  • アプリの完全性検証にhardware attestationが付くと、最終バイナリはGoogleまたはAppleが承認したコードと一致していなければならず、GrapheneOSやカスタムLinuxフォンのようなデバイスは排除されうる
  • relay attackは、すべての署名とattestationが正常でも防げず、この構造が年齢確認を超えてrevocable digital IDsの受け入れにつながりうるという警鐘も示されている

DSAの迂回経路とKYC代替

  • 特定のコンテンツを扱う大規模プラットフォームでは年齢確認が必要だが、必ずしもプライバシー志向のEUウォレットを使う必要はない
    • プラットフォームはEU walletを選ぶこともできる
    • 同時に、パスポート全体のスキャンやliveness検査などを行う一般的なKYC providerを組み込むこともできる
  • プライバシー機能は任意のままにとどまる
    • 宣伝はprivacy-preservingの側面に集中しているが、ルール上は秘匿性の弱い代替経路も許容される
  • 各国eIDを直接連携する道は、実務的には難しいものとして描かれている
    • 27か国の異なるnational eID systemsを統合するのは複雑である
    • KYC事業者は、物理身分証の外観データベースと写真ベースの手続きを維持するほうが安く、汎用的に機能する
  • 現在の相互運用性の準備状況も低いと評価されている
    • 公式のtrusted listには本番アプリが0件である
    • reference implementationもまだ未完成とされる
    • 2026年末までに27か国すべてで円滑な相互運用が整うという期待は非現実的とみなしている

実際の検証フローとデバイス統制

  • 主な高信頼経路はNFC passportを使用する
    • 顔写真ページ下部のMRZをスキャンしてNFCチップのデータを読み取り、復号鍵を得る
    • チップには署名済みデータと所持者のJPEG photoが入っている
    • 設計上、スマートフォンでリアルタイムの顔写真を撮影し、チップ内の写真とローカルで照合する
  • このローカル顔照合は、子どもが親のパスポートをスキャンして自分の資格情報を発行してもらうことを防ぐ目的だと記されている
  • アプリがオープンソースでも、実際の国家配布版でhardware attestationが強制されれば、任意の改変は防がれる
    • 本文時点では、reference codeでサーバー側のattestation検証はまだ接続されていない
    • ただし、各国配布版がこれを追加すべき構造になっていると記されている
    • 最終バイナリはGoogleまたはAppleが署名した正確なコードと一致しなければならない
  • このセキュリティモデルは特定のデバイスとOSを排除する
    • GrapheneOS、カスタムLinuxフォンは許可されない
    • Huawei端末は独自のhardware attestationは可能でも、Play Integrityを通過できないと記されている
    • 関連例として GrapheneOS attestation compatibility guide がリンクされている
  • より単純なMRZ-only経路もあるが、限界が大きい
    • NFC読み取りや顔照合なしで身分証写真だけを撮る経路である
    • 実際の国家アプリがこれをサポートするかは不明とされる
    • referenceは高信頼のチップベース経路を推奨している

宣伝される暗号技術と実際に搭載された暗号技術の差

  • 対外的な語りはzero-knowledge proofs中心だが、実際のreference Androidアプリの実行経路ではZK暗号は使われていない
  • 現在動作している方式はISO 18013-5 mdoc with ES256とされる
    • 各属性は事前に署名される
    • ウォレットは要求された属性だけを開示し、残りはsalted-digest commitmentsで隠す
  • ZKライブラリがリポジトリに含まれていても、presentation pathではそれを呼び出していない
    • リポジトリに存在することと、実際にswitched onになっていることは別だと区別している
    • 各国アプリが後から有効化するかは未解決の問題として残されている
  • 現在のreferenceのunlinkabilityも、強い数学的保証とは異なるものとして説明されている
    • 本文ではこれをdisposable-batch unlinkabilityと表現している
    • 署名済み資格情報を1回ずつしか使わなければ、18歳以上かどうかと発行者程度しか明らかにならず、一意の識別子はないとされる

プライバシー特性と限界

  • 全体の流れはlocal-firstに近いが、資格情報発行サーバーは依然として必要である
    • 文書スキャンと初期検査はスマートフォン上で行われる
    • attested appという前提のもと、発行サーバーはどのコードが実行されたかをある程度信頼できる
    • サーバーは文書署名を検証し、署名済みのcredentialを発行する
  • 検証者から見たunlinkabilityは、ウォレットが規則どおりに動く場合にのみ成立する
    • 設計は、2つの証明が数学的に相関分析不可能な構造ではなく、disposable credentialsを1回ずつ使って再取得する方式である
    • ウォレットがこれを守れば、異なる検証者は異なる署名を見ることになり、結び付けにくくなる
    • ウォレットが不正をしたりproofが再利用されたりすると、同じ署名バイト列が現れ、容易にリンクされる
  • よくあるZK = 永続的unlinkabilityという語りはここには当てはまらない
    • この性質は、暗号技術が再利用自体を無力化するからではなく、ウォレットがローテーション規則を守ることで維持される
    • 比較対象としてBBS+CL signaturesが挙げられ、それらの方式では再利用されても問題ない非連結の証明を作れるとされる
  • 発行者の観点からの追跡範囲も限定的である
    • 発行者は、ユーザーがIDを提示したときにcredentialを発行する
    • その後、そのcredentialがどこで何回使われたかはサーバーにはわからない
    • 想定可能なrate limitも発行量の制限にすぎず、実際の利用回数の制限ではない
  • 正常なウォレット動作のもとでは、EU加盟国の市民であること程度は推測できても、どのアカウント群が同一人物のものかや、サイト間の活動連携は難しいとされる

Relay attackの問題

  • 規格が適切に答えられていないrelay attackシナリオが提示される
    • 未成年者が年齢制限サイトに入ろうとするとき、代理認証サービスにQRコードやリンクを渡す
    • そのサービスは、それを実際の成人の政府ウォレットが入ったクリーンなスマートフォンへ転送する
    • 成人が承認すれば、サイトは完全に有効なover-18 proofを受け取り、アクセスを許可する
  • この流れでは、どの暗号検証も失敗しない
    • すべての署名は本物で、attestationも本物であり、成人も実際に成人である
    • 問題は、プロトコルが今このブラウザの前にいる人間ではなく、どこかのウォレットが承認したという事実にしかバインドされていない点にある
  • proximity checkがないことが中核的な限界として示されている
    • ブラウザ側のDigital Credentials APIは、同一スマートフォン上でブラウジングと認証を同時に行う場合にのみ一部の緩和効果がある
    • デバイス間移動に使われるQRコードやdeep linkは、依然として開いたままだとされる
  • Play Integrityもこの問題を防げない
    • Play Integrityがattestationするのは、どのデバイス上でどのコードが実行されているかだけである
    • そのデバイスの前に誰がいるか、そのデバイスがどこにあるかは示さない
    • プロキシフローでは、代理Webサービスはattestationの対象ではなく、バイト列を中継するだけである
  • 成人登録後は再販売モデルがさらに容易になるとみている
    • ウォレットには短い周期で更新される30個の disposable credentialsがあるとされる
    • 発行者はそれらの資格情報が実際にどのように消費されるかを見られない
    • したがって、プロキシ運営者は同じcredentialを多くの未成年者に再利用でき、上流システムはそれを検出できない
  • この問題は実装バグではなく、protocol shapeに由来する構造的性質と位置づけられている
    • そのため、規格に従う27か国のアプリ全体に残る問題とみなされている

デジタルIDインフラへの拡張懸念

  • 年齢確認アプリはdigital ID infrastructureへの入口として扱われている
  • 出発点は児童保護と有害コンテンツ遮断だが、実際には人々がより都合のよいattested walletを選ぶよう摩擦を生む構造として描かれている
  • この構造ではアプリ自体もattestationの対象であるため、何を実行できるかをGoogleまたはAppleが左右することになる
  • 資格情報はissuerが失効させられると記されている
  • reference appは顔写真をローカルでのみ漏らすと記されている
    • 同時に27か国がそれぞれ別バージョンを作るため、各国実装ごとに別個のプライバシーバグが生じうるとみている
  • 反復的なウォレット呼び出しはHawthorne effectを生むとされる
    • 議論の多いサイトで毎回ウォレットを取り出させられると、proofが匿名でも自己検閲が強まる可能性がある
    • 政府がこうしたデータをうまく保護してきた実績は良くないとされる
  • その後、Digital Euroのような別の仕組みと接続される懸念も示される
    • そうなると生活の大部分が遠隔で止められうるとみている
    • 駐車違反の反則金未納を例に、credentialの一時剥奪のようなシナリオを想定している
  • 結論として、インターネットアクセスの代償としてrevocable digital IDsを受け入れる必要はないと強く述べている

公開されたハッキング事例の切り分け

  • 報告された問題は2種類に分けられる
    • mock-up bugs: ファイル漏えい、未検証のMRZスキャン、placeholder backendを叩くChrome extensionデモなど
    • structural properties: proximity bindingの欠如、クライアント側one-time-use、再利用で崩れるunlinkabilityなど
  • 前者は各国実装で修正できる問題として分類される
    • reference appのディスクファイル漏えいは修正される類のもので、本質的問題ではない
    • テストcredentialをだまし取れても、実際の主経路は未検証MRZスキャナのmock-upではなく、各国eID体系になると記されている
  • 後者はバグではなく、規格から直接導かれる性質として扱われる
    • 規格に従うすべての国家実装に残る問題と規定される
  • custom Chrome extensionベースのハックも、本番環境では通用しないとみられている
    • attestationが強制されれば、アプリ検証で失敗する
    • MRZ経路も実際のEU共通バックエンドにはつながらず、有効文書レジストリは各国の管轄だとされる
  • mock-upを破ったという類のデモは、ライブラリ利用例を攻撃したに近いと整理している
    • 実際には Slovak、Hungarian、German、Dutch、French などの国家別アプリがそれぞれ存在することになると記されている

需要と結論

  • このような仕組みへの需要自体は存在するとみている
    • インターネットが危険だと感じる親は、子どもを守る手段を求めている
    • 子どもが回避する可能性とは別に、守られる側の子どもよりも安心したい親こそが実質的な顧客として描かれている
  • 関連参考リンクも掲載されている
  • 結論部の判断は4点に要約される
    • EU fancy ZK appsは準備が遅れており、プラットフォームが一般的なKYC provider、AI顔年齢推定器、その他の手段を使う可能性が高い
    • 規格どおりに実装されれば、プラットフォームがユーザーの実名やアカウント間の結び付きを把握しにくいという意味のあるプライバシー特性はある
    • ただしその特性は暗号学的強制よりwallet behaviorに依存しており、リポジトリ内のZK数学は現時点で有効化されていない
    • Google/Apple approved deviceでなければ動作しない制約と、relay attackの構造的限界が併存する

1件のコメント

 
GN⁺ 3 일 전
Hacker Newsの意見
  • これはトロイの木馬ではなく、決定文・議論・法文に明記された目標そのものだ
    年齢確認の要件は、技術的に実現可能であることを示す手段であると同時に、完全なデジタルIDへ向かう最も単純な出発点として選ばれたものだ
    EUではすでに各国政府がスマートカードや政府アカウントベースのOIDCに近い認証サービスを提供しており、デジタルウォレットはその延長線上で、他国のEU市民の認証を容易にし、身分証を携帯電話に載せられるようにする仕組みだ
    子どもに年齢確認トークンを渡してしまうというシナリオは現実でもすでに可能であり、そのリスクは受け入れたうえで、発覚したら処罰する形で対処してきたのであって、酒場が後をつけて実際に飲むかどうかまで確認したりはしない

    • 今日は年齢確認、明日はデジタルID、その次は恒久的な追跡というパターンは、いつも同じに見える
    • 違いは大きい
      実際の物理的な身分証は、銀行業務、文書への署名、行政対応のようなまれな場面でだけ見せればよいことが多く、酒を買うときでさえほとんど要求されなかった
      要求されても、ただ見せるだけで、写真を撮って保存されるようなことは許さない
      しかし、食料品店、薬局、ガソリンスタンド、駐車場、レストラン、バーのたびに身分証を求められ、写真まで撮ってDBに保存されるなら、歓迎する人はいないだろう
    • それならロードマップやスケジュールがあるのか気になる
      自分も筆者と同じくスロバキアのIDを持っているので、これがインターネットサービスへのアクセスに実際に役立つようになるのがいつなのか知りたい
    • 現実でも可能だというたとえは、不適切な類推に近い
      ここで言う欠陥は、回避を産業化できる点にあり、現実で数回代理購入するのとは大きく異なる
  • BBS+やCL署名のような本当の暗号学的unlinkabilityは、再利用しても相関のない証明を作れるが、このシステムはそうではない
    スイスのeID議論でも出ていたように、ZKPの代わりに
    ローテーション署名
    を使う理由は、ほとんどのスマートフォンのセキュアハードウェアがBBS+のようなアルゴリズムをサポートしていないからだ
    国家が独自の秘密鍵保管基盤を新たに作るよりも、ハードウェアモジュールが作成した署名の束を循環利用するほうが、全体として現実的で大きな問題も少ないという判断だ
    ハードウェアモジュールの利点は、携帯電話を紛失したときに攻撃者が実際の秘密鍵を抜き出すのをはるかに難しくする点にある
    デジタルIDの話が出るたびに、恐怖を煽る側がコピペしたような懸念を繰り返すが、実際にEUDI specを読めば、そのかなりの部分はすでに対処されている
    https://eudi.dev/1.6.0/architecture-and-reference-framework-main/

    • 仕様は読んだが、revocation flowが、発行者・政府とサイト運営者が結託した場合に年齢確認利用者の身元を暴けないよう、どう防いでいるのかよく分からない
    • さまざまなIDシステムの提案、長所短所、実運用の経験をまとめた良い入門資料があれば知りたい
      Wikipediaで国別eIDの記事を見るより良い出発点が必要だ
    • その通りだ
      オオカミ少年式の大騒ぎを繰り返す流れには本当にうんざりする
  • 別の見方もできる
    EU Age Control自体はトロイの木馬ではなく、アプリは掲げている機能をそのまま実行している
    誰もそれを使いたがってはいない
    本当のトロイの木馬は企業製モバイルOS
    無料の贈り物のように見えるので、人々は喜んで受け入れるが、実際にはGoogle・Appleと広告パートナーに有利なプライバシー侵食ソフトウェアが中核ビジネスモデルになっている
    人々はその機能を見ず、きれいな無料の贈り物しか見ない
    だから年齢確認アプリも企業製モバイルOSでしか動かない
    筆者が述べているように、GoogleやAppleが承認した端末でなければLinux、GrapheneOS、Huawei、カスタムファームウェアは排除され、それがセキュリティモデルの一部だという
    IDを要求する本当の口実は年齢確認ではなくセキュリティであり、まさにその論理のせいで、端末所有者が自分でコンパイルしたOSを使えなくなる

  • 私には、デジタルIDはデジタル通貨のように、最終的には避けられなくなる可能性が高いように見える
    より便利で効率的だから発行は続くだろうし、紙ベースの身元証明は時間とともに消えていくだろう
    つながった世界では、銀行カードや運転免許証のような物理トークンは必須でも最善の解決策でもない
    だから焦点は、政府がそれで何をできないかを統制することに向けるべきだ
    例えば市民権を剥奪してはならないのと同じように、IDの無効化や削除も簡単にはできないようにすべきだ

    • 人々はdigital idsと聞くと、それぞれ別のものを思い浮かべているようだ
      オランダ政府が納税申告などに使っているデジタルIDもあれば、ウクライナ政府発行のX509証明書とアプリで同じようなことをする場合もある
      そういうものまで悪いと見るのはよく分からない
    • だが多くの国は実際に市民権剥奪を認めている
      英国では政治的判断でも可能で、銀行口座の凍結のように他の権利も止められるので、それを実効的に禁じられるのか懐疑的だ
      物理トークンの問題もよく分からない
      単純で、単一障害点を作らず、携帯電話を失ってもカードと現金は残り、ネットワークやシステム障害にも強い
      カードを数枚持ち歩くことがそこまで大きな欠点だとは思えない
    • デジタルIDも結局は物理トークンの形態と併存する可能性が高い
      しかも紙の上にも、デジタル化され暗号学的に署名されたIDを載せられるので、安全性と機械可読性の面では電子式とかなり近い役割を果たせる
      電子トークンが特に威力を発揮するのは、IDであれ他のものであれ、単一コピーの物理的所持を証明するときだ
    • 避けられないという点には同意するが、その先は深いウサギ穴のように見える
      EUはすでに何年も前から、政府にできることを統制するという名目のもとで、こうした方向に進んでいる
      https://escapekey.substack.com/p/europe-goes-full-digital
    • IDの停止禁止を言うとしても、パスポートをなくしたら警察に届けて無効化しなければならないように、携帯電話内のデジタルIDも紛失時には失効できる必要がある
  • ソーシャルメディアが拡大してから選挙が変わったのを見ると、政府は以前のような統制力を取り戻したがっているように思える
    児童性的虐待コンテンツ、テロ、そして今ではAI生成CPのような恐怖を掲げてオープンインターネットをますます締め付け、結局は西側版のグレートファイアウォールと社会信用に似た二流の仕組みを得ることになりそうだ
    すでにいくつかの自由民主主義国家はその根を植えているように見える

    • むしろソーシャルメディアでは、デジタル本人確認によって公的討論を壊すボットアカウントを排除しようとしている側面のほうが近いと思う
      大物インフルエンサーのアカウントの一部が中国・ロシアのボットだと判明しており、憎悪と分断を拡大しようとする動きはLLMによってさらに悪化している
      ソーシャルアカウントの実体を検証できる何らかのデジタルIDこそが、本当の公的討論を守る最後の希望かもしれない
    • 政府が統制力を取り戻したいと言いながら、実際には私たちを米国企業が完全に支配する端末を経由させるのは、おかしくないかと思う
    • これが選挙の変化と直接結びついているのかは分からない
      私の政府はしばらく前から、ソーシャルメディアが私たちをより愚かにし、より憂鬱にし、より不安にしていると言ってきたし、それは事実だと思う
      その影響が選挙にも現れるのは分かるが、解決したい問題の中核が選挙そのものだとは思わない
      問題を解決すれば選挙にも影響が及ぶのは、むしろ当然だ
    • 政府はAI CPを本当に問題視しているようには見えない
      実在の子どもを元に作ったものですら、億万長者が生成器へのアクセス権を堂々と売れば見逃されているように見える
      だからこれは結局、恐怖を煽る藁人形論法だという思いが強まる
  • デモアプリであれ何であれ、適切に実装することのほうが重要だ
    各加盟国がすべて正しく実装する可能性は低いからだ
    子どもを守るという解決策にも結局限界がある
    子どもにスマホやコンピュータを与えないのが単純な解決策かもしれないし、どうせ違法サイトは年齢確認に従わないだろう
    Pirate Bayのようなところが法をきちんと守っていたなら、そもそも存在していないはずで、結局は実効性のない解決策に近い

    • 単一アプリかどうかより、データベースと相互接続性のほうが心配だ
      特に国家間でどのような承認・統制プロトコルに従うのかが重要だ
      単一DBや統制のないネットワークを望むという発想は、かなり恐ろしく感じる
    • 子どもにスマホやコンピュータを与えないのは解決策ではない
      今では多くの学校がコンピュータへのアクセス自体を要求している
  • 私たちはすでにずっと前からeIDを使っており、それがオンラインでより広く使われるようになるのは問題ない
    年齢確認も同様だが、その過程に米国企業やPalantirが関与しない形であるべきだ

  • 年齢確認のようなところで、本物のZero Knowledge Proofの仕組みが認められる可能性は低そうだ
    そしてremote attestationもそのようには機能しない
    本物のZKP体系では、鍵が1つ漏えいしたり抽出されたりするだけで無限に偽の証明を作れてしまい、それを検出するのが難しくなるからだ

    • この記事が扱うEUの年齢確認は、私が見た技術文書では明確にZKPの使用を明記している
      https://eudi.dev/2.5.0/discussion-topics/g-zero-knowledge-proof/
    • だとするとGoogle Play Integrityは使えないことになる
      Oreoのような古い端末まで認証しているが、ベンダーがアップデートを打ち切った端末には事実上無限の脆弱性が残り、鍵漏えいが可能になるからだ
  • 多くの国ではすでに何年もデジタルIDを運用してきた
    問題はデジタルIDそのものではなく監視
    政府が発行した主体と直接やり取りするときだけ使うデジタルIDは問題なく、むしろ望ましいことすらある
    しかし年齢確認を押し進めるのは、その情報を民間企業にも開放する仕組みであり、それこそがトロイの木馬だと思う

    • ここでいう情報は、実質的には{"over_18": true}{"over_16": true, "over_18": false}に政府署名が付く程度のものだ
      もちろんバチカンIDのような特殊な例なら困るかもしれないが、そもそもあちらはこのシステムに参加しない
  • インターネットはもともとサイバーパンク的な逃避先だったのに、今ではどんな代償を払ってでも匿名性をなくそうという方向に進んでいるようだ
    顔認証でスマホを起こし、インターネットの記録が政府IDと1対1で結びつく世界は、ただただやるせない