独占的な補助者としてのハードウェア証明
(grapheneos.social)- AppleとGoogleはハードウェアベースの証明の利用を拡大し、より多くのサービスでの採用を促すことで、長期的には承認していないハードウェアやOSとの競争を排除する構造を強化している
- Google Play Integrity APIとApple App Attest APIは似たように動作し、Play Integrityは
strong integrityでハードウェア証明を要求し、device integrityにも段階的にそれを求める方向へ進んでいる - Apple Privacy Pass、Googleの中止されたWeb Environment Integrity、
reCAPTCHA Mobile Verificationは、証明要求をWebへ持ち込み、iOSまたは認証済みAndroid端末がなければWebサービスへのアクセスが遮断される可能性を生む - Play Integrity APIは、GrapheneOSが許可されている対象より安全であっても禁止し、10年間セキュリティパッチのない端末は許可するため、セキュリティ上の名目よりもGoogle Mobile Servicesのライセンス供与と競争排除の目的がより際立っている
- 政府や銀行のサービスがApp AttestとPlay Integrityの利用をますます要求することで、Apple端末またはGoogle認証Android端末を事実上強制し、Windows・デスクトップLinux・FreeBSDのような環境からのWebアクセスにも影響し得る
Webへ拡大する証明要求
- AppleのPrivacy Passは、自社ハードウェアでCAPTCHA通過を助けるために、ハードウェア証明をWebへ持ち込む
- 当時は、Appleハードウェア以外の利用者を遮断するサイトは多くないだろうという理由で、無害だと見る人が多かった
- AppleとGoogleはいずれも、より広範なハードウェア証明をWebへ持ち込む可能性が高い
- 銀行や政府サービスはモバイルアプリの利用をますます要求しており、アプリ内で証明を使ってAppleまたはGoogleが承認した端末とOSを強制できる
- AppleのPrivacy Pass、Googleの中止されたWeb Environment Integrity、そしてreCAPTCHA Mobile Verificationは、こうした流れをWebへ持ち込んでいる
- reCAPTCHA Mobile Verificationに関する現在の報道は、その影響と意味を十分に扱えていない
- この方式では、特定の状況でreCAPTCHAを通過するために認証済みスマートフォンでQRをスキャンすることを要求し、Windows、デスクトップLinux、OpenBSDなどにもハードウェア証明要求を持ち込む
- GoogleはreCAPTCHAに対する支配力を通じて、iOSまたは認証済みAndroid端末がなければWebの膨大な部分を利用できないようにする立場にある
- GoogleはAndroid認証の要件を定義しており、これにはGoogle Chromeの同梱強制などが含まれる
- reCAPTCHA Mobile Verificationは現在、GrapheneOSのサンドボックス化されたGoogle Playとともに動作するが、ハードウェア証明のないシステムにもこれを使い始めるための手段として存在している
- この要求が適用されれば、iOSまたはAndroid端末を持たない人は追加条件なしでも遮断され得る
Play IntegrityとGrapheneOSの排除
- GoogleのPlay Integrity APIは、GrapheneOSが許可されているどの対象よりもはるかに安全であっても、GrapheneOSの利用を禁止する
- Play Integrity APIは他の代替手段も禁止しており、これはAOSPベースOSだけの問題ではない
- FreeBSDベースのモバイルOSを使ってもこの問題は避けられず、むしろさらに排除されるだけである
- Play Integrity APIは、10年間セキュリティパッチのない端末でも許可する
device integrityレベルはスプーフィングで回避できるが、Googleはそれが大規模に使われ始めれば、かなりうまく検知して遮断できるstrong integrityレベルを回避するには、TEEまたはSEから漏えいした鍵が必要になる- Play Integrity APIはそれほど安全ではなく、一時的に回避すること自体は特別に難しいわけではない
- ソフトウェア検査をスプーフィングするフレームワークがあり、ハードウェア証明を回避するための漏えい鍵も購入できる
- ただし回避は次第に難しくなっており、有効期間もますます短くなっている
- Play Integrityは有用なセキュリティ機能を提供しない一方で、競争排除には非常によく機能する
- Apple App AttestまたはGoogle Play Integrityを要求するサービスは、主にAppleとGoogleがモバイル端末で複占を維持する助けとなっている
- Play Integrityがより重要なのは、AOSPがオープンソースだからである
- GrapheneOSはハードウェア証明で検証可能であり、GoogleがPlay IntegrityでGrapheneOSを禁止するのは、Google Mobile Servicesのライセンスを受けておらず、反競争的なルールにも従っていないためである
- そのルールは韓国などで既に違法と判断されたことがある
- サービスは任意のハードウェアとオペレーティングシステムの利用を禁止すべきではない
- Googleが10年間パッチのない端末は許可しながら、はるかに安全なOSは許可しないという点から見ても、セキュリティ上の名目は成り立ちにくい
- これはGMSライセンス供与を通じて独占を強制するためのものだ
政府・銀行サービスと規制の役割
- 政府は自らのサービスだけでなく、商用サービスにもApple App AttestとGoogle Play Integrityの利用をますます義務づけている
- EUは、デジタル決済、本人確認、年齢確認などにこうした要件を適用する流れを主導している
- 多くのEU政府アプリは、すでにこうした要件を備えている
- 政府はAppleとGoogleの深刻な反競争的行為を止める代わりに、自らのサービスを通じて競争排除に直接参加している
- 人々にApple端末またはGoogle認証Android端末を要求することは、セキュリティではなく競争制限である
- 銀行・政府サービスへのアクセスや、特定のreCAPTCHA通過のために、改変されていないiOSまたはGoogle Mobile Services対応Android端末が必要になる問題は、GrapheneOSだけの問題ではない
- Windows、デスクトップLinux、FreeBSDなどにも同じ影響を及ぼす
- Pixel、Android端末、AOSPベースのオペレーティングシステムに特化した問題ではなく、デスクトップからのWebアクセスにも影響し得る
Android証明APIとUnified Attestation
- Androidは、検証済みブート鍵フィンガープリントを許可することで、代替オペレーティングシステムをサポートする標準的なハードウェア証明システムを提供している
- Androidのハードウェア証明は主にGoogleの信頼ルートとリモート鍵プロビジョニングサービスを使うが、API自体は代替信頼ルートをサポートしている
- Androidハードウェア証明は、特定のハードウェアやOSを使わない利用者を排除するために使われるべきではない
- ただし、任意の信頼ルートとOSを許可できるという点は、サービスがより多くの対象を許容する余地を与える
- Googleがセキュリティ目的だったなら、同じシステムを使ってPlay IntegrityでGrapheneOSを許可できるはずだ
- Unified Attestationは、複数の欧州企業が推進している別の反競争的システムであり、任意のハードウェアとソフトウェアの利用者を同様に排除することになる
- Unified Attestationは解決策ではなく、Androidのはるかに開かれたハードウェア証明APIよりもずっと悪い
- VollaのUnified Attestationは、Androidのハードウェア証明APIの上に完全に構築されている
- VollaのUnified Attestationは、何が許可されるかを中央権限とサービスが統制できるようにするために存在している
2件のコメント
Googleが大好きなので、5つくらいあってほしいです🥰
Hacker Newsの意見
EU Digital Identity Wallet(EUDI) がGoogleやAppleのハードウェア証明を要求しており、事実上EUのすべてのデジタルIDを米国の二強に縛り付けている
デジタル主権を語りながらこの判断をしていることになり、子どもの保護が主権より優先されるという発想に見える
https://gitlab.opencode.de/bmi/eudi-wallet/wallet-developmen...
そもそもなぜこんな判断をしたのか理解できない
技術知識のない一般利用者向けの返答であることが明らかに見えた
主権や米国依存からの脱却を重要だと言う人は多いのに、なぜもっと大きな反対がないのかわからないし、単なる無知だと見るしかないのかと思ってしまう
とくにプライバシー保護型の識別子ではなおさらで、そのためデバイス証明が重要になる
ハードウェアがユーザーによる鍵抽出を防いでいるか確認できなければ、ID鍵がデバイスにロックされていると保証できない
最悪なのは、意欲ある犯罪者はいずれその鍵を抜き出して詐欺に使う方法を見つけるだろうという点で、その結果オープンソースとオープンなコンピューティングが破壊されることだ
誰が身分証の提示を求められるべきかは別問題で、オンライン専用の状況の大半では答えは「ノー」だと思うが、金融業界が何十年も信頼してきた解決策はすでに存在する
承認されたシリコンとソフトウェアを要求することすら、ここで最大の問題ではない
彼らはゼロ知識証明やブラインド署名を使っていない
そのため、デバイスで証明するたびに、その行動をデバイスと結び付けるために使える証明パケットが残る
中間サーバーで静的デバイスIDからワンタイムIDを受け取る迂回構造を入れて、プライバシーに配慮しているふりはしているが、その中間サーバーが何をしているのかわからない以上、すべて記録していると考えるべきだ
リモート証明の経路だけでもこうで、DRM IDの経路はさらに悪い。意味のある回避策がないため、すべてのライセンスサーバーがシリコンに焼き込まれた静的な身元にアクセスできる。Googleアカウント経路は言うまでもない
リモート証明にブラインド署名を使おうという提案は実際にあったが、現状で目立つ場所では使われていない: <https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation>
そうなっている理由はいくつかある。わかりやすい理由は、必要なときにプライバシーを侵害できるようにしたい、あるいはそうした能力を義務付けられているからだろう
別の理由として、特定のデバイスと証明を結び付けられないと、不正利用の緩和策が実質的にレート制限しかなくなり、彼らの基準ではそれでは不十分かもしれないという点がある。攻撃者がデバイスファームを構築し、各デバイスが悪意ある行為者にリモート証明を提供して時間単位で稼ぐこともできてしまう
どうやってサービスを匿名のままレート制限できるのかわからない
あるサービスが2つの要求が同じ主体から来たか数えられるなら、2つのサービスが同じサービスのふりをして、その2つの要求が同じ主体から来たかを知り、相互に関連付けることもできるはずだ
「問題はハードウェア証明ではなくゼロ知識証明を使っていないことだ」などと言うのは、新しい行動様式を正当化している
そんなことをしてはいけない。ゼロ知識証明を使おうが最新のセキュリティ技術でハードウェア証明をしようが、問題はハードウェア証明そのものだ
年齢確認も同じだ。問題は年齢確認がデータ漏えいに弱いことではなく、問題自体が年齢確認なのだ
アプリ発表時から、だいたいこういう構造だろうと確信していた
Grapheneのフォーラムでも、DRM IDが保持されるだけでなく、プロファイルをまたいでも同一のままだという議論を見た記憶がある
もしそうなら、導入を進めるためのアメやムチは何になるのだろう
この技術がなぜ「開かれた」何かにとって問題になっていくのかをよく示しているスレッドだ
「自分たち用の別のウェブを作ればいい」という主張は、すべてのサービスがGoogle承認またはApple承認のモバイル機器所有を強制するウェブの裏側に入る前までは通用する
Googleはすでにそれを完全に塞いでいる
要求された項目を選ぶために四角をクリックすると無限ループになり、音声版を使おうとすると不審なアクティビティがあったとして完全に遮断される
だから最近は一人で走っているし、今年は会員資格も更新しなかった
最後に似た経験をしたのは、Facebookがある種のイベント参加の唯一の経路になり始めたときだった。そのときも、ただ排除されたものとして受け入れ、時間と金を別のところに使った
すでに多くの企業や社会的集まりは、FacebookやWhatsAppのようなものの向こう側に置かれ、そこを通らないとアクセスできなかった
これは本当に奇妙なサイバーパンクのディストピアのように感じる。同じ民間郵便サービスに加入した人にしか手紙や荷物を送れないとか、自分の車のブランドと相互ライセンスのある道路でしか運転できないようなものだ
たとえセキュリティ機能があったとしても、GoogleやApple以外のOSを二級市民にしてしまう副作用はそのままで、それこそが核心的な問題だ
銀行や政府とのやり取りは現実的ではないだろうが、それ以外の多くのサービスでは可能ではないかと思う
ただし、何かを作る作業は依然として必要で、コストは人数の少ない側に分散され、広告技術を作る必要がないぶん複雑さが下がるという利点だけでは相殺できない可能性が高い
それでも、一種の良い食材の問題なのかもしれない。ハードウェアはもっと難しいだろう
ばかげた質問に聞こえるかもしれないが、本気で聞いている
1999年にIntelがCPUへソフトウェアから読み取れるシリアル番号を入れようとしたとき、ものすごい反発があり、結局その決定は撤回された
その後も「セキュリティ」と信頼できるコンピューティングを推し進める権威主義者たちは、TPMと関連技術を押し続け、モバイルの囲い込みエコシステムの台頭にも寄与した
Windows 11のTPM要件も、その目標へ向かう別の一歩だった。ここや他所で、それが良いことだという宣伝がいかに多かったかには衝撃を受けた
「セキュリティ」が大義名分として掲げられると、かなりの人々は何でも簡単に受け入れさせられてしまうことが明らかになる。その数が減っていくことを願う
汎用コンピューティングとの戦いは続いており、こちらも戦い続けなければならない
Stallmanはいつも通り正しかった。彼の「Right to Read」を読み返す時だ。まだないなら、AIで作る短編映画も良いアイデアかもしれない
「安全のために自由を手放す者は、そのどちらにも値しない」
AIは完全に中央集権的で独占的なツールだ
このスレッドでも見られるように、こうした問題に対する推進力や怒りや自律的に組織された対応の代わりに、「誰も気にしない」「自分たちにできることはない」といった絶望ばかりがある
諦めることは、負けるための最も確実な方法だ
ここのコメントは証明そのものが悪いという話として読んでいるようだが、本当の主張はAppleとGoogle以外の提供者も明示的に含まれる道筋があるべきだ、ということに近く見える
タイトルはAppleとGoogleが邪悪で、独占の固定化のためにこれを行い、競合であるGrapheneOSが人々のために立ち向かっているかのように見える
しかし最後の反論は、自分たちも含まれるべきだったというものであり、GoogleのPlay Integrity APIで不明確な理由により拒否された、その理由は悪意あるものだと主張している点を見ると、彼らもセキュリティ上の価値自体は認めているように見える
重要なIDデータには、完全な署名チェーンの証明が本当に必要だ。AIで偽の身元を簡単に作れる状況を避ける唯一の方法だからだ
特許と著作権はもともとの独占の形だった
ソフトウェアがオープンソースでない限り、定義上それは独占である
GrapheneOSを支援するHNの金持ちがもっと多くないのは意外だ
この問題を気にする富裕層と技術者たちのベン図はかなり重なるはずで、Grapheneは欠点が多くてもこの分野で多くの基礎作業をしている
私たちの文明は、現代のマイクロエレクトロニクスを製造後に改変する手段を切実に必要としており、少なくとも設備の整った修理店では使えるべきだ
すでに昨日必要だったレベルの話だ
代案としては、汎用として販売されるコンピューティング機器において、CPUやSoCのマスクROMに何らかの初期ブートローダーを入れて出荷することを違法化すべきだ
つまり、リセット後にCPUが実行する最初の命令は、CPUパッケージの外に物理的に存在するストレージから来なければならない
参考: https://pluralistic.net/2026/01/01/39c3/
比較的単純なSoCでも、文書化されていないブートROMで、アーキテクチャ上のリセットベクタに到達する前にリセット処理を助けるため多くの作業を行っている
誤って消されることのないブートROMに低レベルのDFUルーチンを入れておく価値も大きい
SoCシリコンは、電源投入からセキュアブート引き継ぎ命令までに実行された各命令を記録するよう改訂されうる
状態照会、オーバーフローの有無、署名生成などの補助命令まで用意すれば、OSが自前の証明を作る際に、ブート前改変を暗黙に報告することになる
ブートローダーにハードコードされた鍵素材を入れ、その鍵でロードされるコードを検証することを違法化すればよい
Google・Appleの二強が、まったく無関係なサービスに誰がアクセスできて誰ができないかを決める立場に置かれていることに驚く
反Google的な見解のせいでGoogleのサービスから締め出され、その結果銀行口座にもログインできなくなる状況を想像してみてほしい
本当にAlphabet分割をやるべきだ
これほど重大な話題なら、読みにくいスレッドよりも、1ページに整理された論理的で実体のある文章のほうがはるかに良かったはずだ