Android 14 には更新可能なルート証明書が付属している可能性があります。この記事では、それがなぜ重要なのかについて説明します。
ルート証明書は公開キー基盤 (PKI) の中核であり、信頼できる認証局によって署名されています。 CA。 ブラウザ、アプリケーション、およびその他のプログラムには、これらの証明書が 信頼できる。 HTTPS をサポートしている Web サイトにアクセスしても、ブラウザのルート ストアにある CA によって署名された証明書を使用していない場合、その Web サイトには安全ではないというフラグが付けられます。 通常、アプリケーションとブラウザは証明書を更新できますが、携帯電話は OTA アップデート経由でない限り証明書を更新できません。 それは変わるかもしれません アンドロイド14、 によると 超能力者.
ここ数年、証明書に関連していくつかの懸念がありました。それは、私たちが Web サイトにアクセスするときに信頼の連鎖の中核として証明書に依存しているためです。 ここから XDA、私たちの証明書は非営利 CA である Let's Encrypt によって署名されています。 その証明書は Internet Security Research Group によって署名されており、その信頼の連鎖によって、この Web サイトへの接続が安全かつ確実に保証されます。 HTTPS を使用する他の Web サイトにアクセスする場合も同様です。
すべてのオペレーティング システムには独自の組み込みルート ストアがあり、Android も例外ではありません。 実際、デバイスの設定でセキュリティとプライバシーに移動すると、Android スマートフォンでこのルート ストアを表示できます。 そこから先は、使用しているデバイスの種類によって異なりますが、以下のスクリーンショットは、OneUI 5 上の場所を示しています。
ただし、問題は、このルート ストアでさえも最終的なものではなく、すべてであるということです。 アプリは独自のルート ストアを使用して信頼することを選択でき (Firefox はこれを実行します)、受け入れることができるのは 中間者 (MITM) を回避するための特定の証明書 (証明書ピンニングと呼ばれます) 攻撃します。 ユーザーは独自の証明書をインストールできますが、Android 7 以降、アプリ開発者はアプリでこれらの証明書を使用できるようにオプトインする必要がありました。
更新可能なルート証明書を持つことが重要な理由
Let's Encrypt 証明書は Internet Security Research Group によって相互署名されており、 多く インターネットの多くは ISRG のセキュリティに依存しています。 ISRG が秘密鍵の制御を失った場合 (たとえば秘密鍵が盗まれた場合)、ISRG は鍵を取り消す必要があります。 企業の対応次第では、更新可能なルート証明書を持たないデバイスはインターネットの一部にアクセスできなくなる可能性があります。 これは完全に破滅的な悪夢のシナリオですが（そしてまったくの仮説ですが）、まさに Google が避けたい種類のシナリオです。 そのため、現在 TrustCor で起こっていることは、更新可能なルート証明書を Android に追加する時期が来たことを Google に知らせている可能性があります。
文脈を説明すると、TrustCor はそのような認証局の 1 つであり、研究者らが米国の軍事請負業者と密接な関係があると主張したため、厳しい監視の対象となっています。 TrustCor は秘密キーを紛失していませんが、 もっている ルート ストアにどの証明書を含めるかを決定する必要がある多くの企業の信頼を失いました。 これらの研究者らは、米国の軍事請負業者であるTrustCorと親密な関係にある企業が、スマートフォンのアプリにデータ収集マルウェアを仕込むよう開発者に報酬を支払っていたと主張している。 PKI では信頼がすべてであり、TrustCor はこれらの疑惑が明るみに出るとその信頼を失いました。 それ以来、Google、Microsoft、Mozilla などの企業は、認証局として TrustCor を廃止しました。 Android ルート ストアから TrustCor の証明書を削除するには、OTA アップデートが必要ですが、コミットはすでに完了しています。 AOSP で作成されているため、TrustCor の証明書を弊社から削除するアップデートを実際に入手できるようになるまで、おそらく長い時間がかかるでしょう。 デバイス。
利点は、デバイス上の証明書にアクセスして、デバイス上の TrustCor の証明書を無効にできることです。 上で示したように、デバイスを選択し、TrustCor までスクロールして、付属の 3 つの証明書を無効にします。 デバイス。 の開発者によると、 グラフェンOS プロジェクトでは、「この CA は特定のダイナミック DNS プロバイダー以外にはほとんど使用されないため、Web 互換性への影響はほとんどない」はずです。
解決策: プロジェクトのメインライン
Project Mainline に精通している場合は、これが問題の解決にどのように役立つかがすでにわかるでしょう。 Google は、Google Play Services フレームワークおよび Google Play ストアを通じて提供される Mainline モジュールを利用します。 各メインライン モジュールは、APK ファイル、APEX ファイル、または APK-in-APEX のいずれかとして配信されます。 メインライン モジュールが更新されると、ユーザーのデバイスに「Google Play システム アップデート」(GPSU) 通知が表示されます。 事実上、Google は、重要なコンポーネントにアップデートを配信するために、OEM がアップデートを展開するのを待つ必要を回避し、タスク自体を実行することを選択しました。 Bluetooth とウルトラワイドバンドは、Google が扱う 2 つの重要なメインライン モジュールです。
によると AOSP Gerrit にコミットする (発見者 超能力者)、Android の TLS 実装を提供するメインライン モジュールである Conscrypt は、将来のアップデートで更新可能なルート証明書をサポートする予定です。 これは、Google Play システム アップデートを通じて証明書が削除 (または追加) される可能性があることを意味します。 プロジェクト メインライン。TrustCor のような別の状況（またはそれより悪い状況）が発生した場合に、より迅速なプロセスを保証します。 未来。 これがいつ展開されるかは不明ですが、おそらく Android 14 で提供される可能性があります。 Google が Android 13 QPR2 でそれをプッシュしたい可能性は技術的にはあり得ますが、来年 Android 14 が他のユーザーに届くまでは、Google Pixel ユーザーのみが恩恵を受けることになります。 これは、他の OEM が通常 QPR アップデートを展開しないためです。
この機能が存在する理由は、OEM によるアップデートのプッシュに依存することなく、Google がデバイスのセキュリティのもう 1 つの重要な側面を制御できるようにするためです。 現在、OTA は証明書を更新する必要がありますが、緊急事態では、ユーザーが更新できない毎日が重要になる可能性があります。 Project Mainline を利用して、ユーザーが必要になったときに重要な証明書の更新を確実に入手できるようにすることは、確かに歓迎すべき変更です。
ソース： 超能力者