ここでは、PQC とは何か、Google が PQC をどのように利用しているか、そして他の組織はこの新しい標準をどのように採用できるのかについて簡単に説明します。PQC と標準化プロセスにおける Google の役割の詳細については、Cloud の CISO である Phil Venables が 2022 年に投稿した内容もご覧ください。

PQC とは何か？

暗号化は、インターネットで情報の機密性と安全性を維持するうえで、中心的な役割を果たします。現在、最新のブラウザでは、ほとんどのインターネット セッションが暗号化されているので、転送中のデータを盗聴したり改ざんしたりすることはできません。デジタル署名もオンラインの信頼性にとって重要な要素であり、プログラムが改ざんされていないことを証明するコード署名や、オンライン ID を確認する信頼できるシグナルなどに使われています。

現在の暗号化技術が安全なのは、「暗号を解読する」ために莫大な計算能力が必要になり、現在や近未来のコンピュータではとても対応できないからです。残念ながら、この状況が永遠に続くわけではありません。実用的な大規模量子コンピュータが登場するのはまだ何年も先のことですが、コンピュータ サイエンティストたちは、暗号解読可能量子コンピュータ（CRQC）が既存の非対称鍵暗号を破れることを何十年も前から知っていました。

PQC では、そのリスクを防ぐために、標準を定義し、従来のコンピュータと量子コンピュータの両方による攻撃に対抗できる新しいアルゴリズムを共同実装する取り組みが行われています。

ポスト量子暗号の利用や準備に、量子コンピュータは必要ありません。本日 NIST が公開したすべての標準は、現在利用されている従来のコンピュータで動作します。

暗号化はどのようなリスクにさらされているのか？

CRQC はまだ存在しませんが、現在使われているデバイスやデータは、今後影響を受ける可能性があります。すでに存在するリスクとして、以下のようなものが挙げられます。

• 保存データ: Store Now, Decrypt Later と呼ばれる攻撃では、攻撃者は取得した暗号データを保管しておき、まだ構築されていない量子コンピュータの助けを借りて、後ほど復号化を行います。
• ハードウェア プロダクト: 将来の攻撃者は、デジタル署名を偽造することで、使われ続けている量子以前のデバイスに危険なファームウェアやソフトウェア アップデートを埋め込もうとする可能性があります。それを防ぐ防御策を講じる必要があります。

CRQC 関連のリスクについて詳しく知りたい方は、PQC 脅威モデルについての投稿をご覧ください。

組織は PQC への移行に備えるために何ができるか？

多くの場合、新しい暗号化アルゴリズムに移行するプロセスには時間がかかります。この点は、広く使用されている暗号システムに影響を与える脆弱性がある場合でも同様です。新しいテクノロジーへの移行を完全に終えるには、組織的、物流的な課題を克服する必要があるからです。たとえば NIST は、2011 年に SHA-1 ハッシュ アルゴリズムを非推奨としましたが、段階的廃止は 2030 年までに終えることを推奨しています。

そのため、容易に PQC に移行できるように、PQC と関係のないところも含め、組織の準備態勢を改善する措置を今すぐ講じることが重要です。

この 暗号アジリティ のベスト プラクティスは、すぐにでも実施できます。

• 暗号の棚卸し: 組織がどこでどのように暗号化を利用しているかを理解しておきます。たとえば、どの暗号化アルゴリズムが使われているかを把握します。また、鍵マテリアルを安全に管理することも重要です。
• 鍵のローテーション: 新しい暗号システムでは、サービスを停止することなく新しい鍵を生成し、本番環境に移動できる必要があります。バックアップからのリカバリをテストするのと同じく、鍵のローテーションを定期的にテストするようにします。これがなければ、優れたレジリエンス計画とは言えません。
• 抽象化レイヤ: Tink などのツールを使用することができます。Tink は、Google の多言語クロスプラットフォーム オープンソース ライブラリであり、専門家でなくても簡単かつ安全に暗号を利用したり、大規模なコードのリファクタリングをせずに暗号化アルゴリズムを切り替えたりできるように設計されています。
• エンドツーエンドのテスト: PQC アルゴリズムには、さまざまな特性があります。公開鍵、暗号テキスト、署名は特に多様です。スタックのすべてのレイヤが期待どおりに動作することを確認する必要があります。

私たちの 2022 年の論文「Transitioning organizations to post-quantum cryptography」（組織のポスト量子暗号への移行）には、組織が移行に向けて準備することに役立つその他の推奨事項が記載されています。また、こちらの Google セキュリティ ブログの最近の投稿では、暗号アジリティと鍵のローテーションについて詳しく説明しています。

PQC に向けた Google の取り組み

Google は以上のリスクを真剣に受け止めており、複数の面で対策を講じています。Google は、2016 年に Chrome で PQC のテストを開始し、2022 年以降は PQC を利用して社内通信を保護しています。2024 年 5 月には、PC 向けの Chrome で、TLS 1.3 と QUIC 用の ML-KEM をデフォルトで有効化しています。ML-KEM は、Google のサーバー群でも有効化されています。PC 版 Chrome と、Cloud Console や Gmail といった Google プロダクトとの接続は、すでに試験運用的なポスト量子鍵交換で保護されています。

Google のエンジニアは、NIST が公開した標準や ISO が作成した標準に貢献しており、Trust Expressions、Merkle Tree Certificates、ハッシュベースの署名状態管理といったインターネット ドラフトを IETF に提出しています。Tink は、安全で使いやすい暗号 API を提供する Google のオープンソース ライブラリであり、すでに C++ に試験運用的な PQC アルゴリズムを提供しています。私たちのエンジニアは、パートナーと協力しながら、Google などで利用できる正式に検証された PQC 実装の作成にあたっています。

Google は、自社の PQC 移行を進めつつ、Android、Chrome、Cloud などの Google サービスの PQC アップデートを続けていきます。

• Google Pixel：Google がつくった AI スマホ：リンク
• Vision AI：リンク
• Gemini：リンク
• Imagen 2：リンク

Cookie を盗む情報窃取マルウェアを使うサイバー犯罪者は、ユーザーの安全とセキュリティにリスクをもたらし続けています。この分野では、すでに多くの取り組みが実施されています。たとえば、セーフ ブラウジングによる Chrome のダウンロード保護、デバイス バウンド セッション認証情報、盗まれた Cookie が使われたことを検知する Google のアカウントベースの脅威検出などです。この度、新たな保護レイヤーについてお知らせします。これにより、この種のマルウェアから Windows ユーザーを保護する際の安全性が向上します。

Chrome は現在、秘密情報を保存する必要がある他のソフトウェアと同じように、OS が利用できる技術を使用して Cookie やパスワードといった機密データを保護しています。macOS ではキーチェーン サービスという技術を、Linux では kwallet や gnome-libsecret などのシステムが提供するウォレットを使っています。Windows の Chrome は、システムの他のユーザーやコールドブート攻撃から保存データを保護するために、データ保護 API（DPAPI）を使っています。しかし、悪意のあるアプリケーションがログイン中のユーザーとしてコードを実行できる場合、DPAPI では保護できません。

Chrome 127 で、DPAPI を改善する新しい保護機能を Windows に導入します。これは、アプリケーション バウンド（アプリバウンド）暗号化プリミティブを提供することによって実現します。Chrome は、ログイン中のユーザーとして実行されるアプリがこのデータにアクセスできるようにするのではなく、アプリの ID に紐付けてデータを暗号化できるようにします。これは、macOS のキーチェーンの動作と同様です。

今後、各種シークレットをこの新しいシステムに移行する予定ですが、Chrome 127 では、まず Cookie の移行を行います。今後のリリースでは、この保護をパスワードや支払いデータ、その他の永続的な認証トークンに拡大し、情報窃取マルウェアに対するユーザー保護をさらに強化する予定です。

動作の仕組み

アプリバウンド暗号化では、特権サービスを利用して要求元アプリケーションの身元を確認します。アプリバウンド暗号化サービスは、暗号化する際にアプリの ID をエンコードして暗号データに埋め込み、復号化が試行されたときにその有効性を確認します。システムに存在する別のアプリが同じデータを復号化しようとすると、失敗します。

アプリバウンド サービスはシステム権限で実行されます。そのため攻撃者には、単にユーザーを誘導して悪意のあるアプリを実行させる以上のことが必要になります。つまり、マルウェアはシステム権限を取得するか、Chrome にコードを挿入しなければならなくなります。これは、正規のソフトウェアが行うべきことではありません。そのため、動作の疑わしさが高まり、ウイルス対策ソフトウェアによって検出される可能性が高くなります。この保護とともに、Cookie 復号化のイベントログを提供するといった最近の取り組みも合わせて動作します。その目的は、ユーザーのデータを盗もうとする攻撃者のコストと検出リスクを高めることにあります。

企業での考慮事項

マルウェアは、昇格して実行することでこの保護をバイパスできます。そのため、エンタープライズ環境でダウンロードしたファイルを管理者として実行できないようにすることが特に効果的です。このような環境では、マルウェアが単純に昇格した権限を要求することはできなくなるので、インジェクションなどの技術を使わざるを得なくなります。このような操作は、エンドポイント エージェントでかなり容易に検出できます。

アプリバウンド暗号化では、暗号化鍵がマシンに強くバインドされるため、Chrome のプロファイルが複数のマシンをローミングする環境では正しく動作しません。ローミング プロファイルをサポートしたい企業には、現在のベスト プラクティスに従うことをお勧めします。必要な場合は、新しい ApplicationBoundEncryptionEnabled ポリシーを使ってアプリバウンド暗号化を構成できます。

互換性のない状況の検出に役立つように、Chrome は検証に失敗した際にイベントを発行します。イベントは、アプリケーション ログの「Chrome」ソースの ID 257 です。

まとめ

アプリバウンド暗号化により、攻撃者のデータ盗難コストは増加し、システムでの動作ははるかに目立ちやすくなります。また、システムの他のアプリに許容される動作について、防御側が明確な線引きを行うことができます。マルウェアの状況は継続的に進化します。それに合わせて、セキュリティ コミュニティの他のメンバーと協力しながら、検出の改善、強力なアプリ分離プリミティブといったオペレーティング システムの保護の強化など、バイパス対策の取り組みを続けていきたいと考えています。