Techtok #7：耐量子暗号（PQC）、DNSプロトコル、公開鍵証明書について解説

今回の「TechTok」コラムでは、量子耐性プロトコルとバッテリー使用の関係に関する質問への回答を解説し、DoHとDoQというDNSプロトコルの違いを詳しく説明します。さらに、デジタル証明書（「公開鍵証明書」とも言われる）とは何か、そしてAdGuardのようなツールとどの関係にあるのかについても探っていきます。
さて、シートベルトを締めていよいよ出発です。

Big Mekk さんからのご質問：

AdGuardの「AdGuardian」ニュースレターで、AdGuardがVPNでKyber/量子耐性プロトコルをサポートすると記載されています。この機能を有効にすると、特にモバイルデバイスでの処理などにおいてバッテリー消費が増加するのでしょうか？

まだニュースを追えていない方のために：AdGuard VPNはKyber — 量子コンピューターによる脅威から保護するためのアルゴリズム — のサポートをデスクトップとモバイルアプリの両方で提供開始しました。では、ご質問に答えるために、具体的な実装方法を見ていきましょう。モバイルとデスクトップの両方で、クラシックなX25519楕円曲線アルゴリズムとKyber768ベースのML-KEM768を組み合わせたハイブリッドアプローチを採用しています。

モバイルデバイスとAdGuard VPNの間で接続が確立される際、これらのアルゴリズムは並行して使用されます。デバイスはX25519用とKyber768用の2つの公開鍵を送信し、サーバーも同様に応答します。各側は両方のアルゴリズムから共有秘密鍵を導出し、それらを安全に結合してVPNセッションを保護する単一の暗号化鍵を生成します。これは二重交換であり、従来のハンドシェイクよりも多くのデータが必要です。通常のハンドシェイクでは、各方向で約32バイトが必要ですが、ハイブリッドハンドシェイクでは約1.2 KBが必要です。

バッテリーへの影響については、追加の計算処理がデバイスのCPUにやや負荷をかける点は事実です。古いまたは低性能なデバイスを使用する場合、Kyberアルゴリズムを有効にした接続確立に、通常より最大0.1秒長くかかる場合があります。これによりバッテリー使用量がわずかに増加する可能性がありますが、これは初期接続フェーズに限られます。この影響はほとんど気づかないほど小さく、特に画面をオンにしたりアプリを開いたりする日常的な動作と比べると無視できるレベルです。VPN接続が確立されると、セッションは従来の対称暗号化で実行されるため、バッテリー消費量は以前と全く同じになります。

要するに、セッション中にVPN接続が複数回切断され、毎回再接続する必要がない限り、Kyberアルゴリズムを有効にしてもバッテリー寿命に意味のある影響は与えません。

Álvaroさんからのご質問：

DOHとDOQプロトコルのうち、どちらがよりプライバシー保護に優れていますか？

これは難しい質問ですね、ありがとうございます。さらに説明する前に、DOH（DNS over HTTPS）とDoQ（DNS over QUIC）が何を指し、どのようにデータを送信するかを明確にしましょう。そのため、DNS（ドメインネームシステム）の仕組みを簡単に説明します。

ブラウザがウェブサイトにアクセスしたい場合、そのサイトのIPアドレスを知る必要があります。ここでDNSサーバーが登場します：DNSサーバーは、アドレスバーに入力した人間が読めるドメイン名を、コンピュータがウェブサイトを特定するために使用する数値のIPアドレスに変換（または「解決」）します。

かつては、このプロセスは完全に平文で行われていました — 暗号化は一切施されていませんでした。つまり、あなたのDNSクエリ（訪問したウェブサイトを含む）は、ISPに閲覧可能でした。また、DNSトラフィックは盗聴、改ざん、またはなりすましにさらされていました。これが、DoT（DNS over TLS）やDoH（DNS over HTTPS）のような暗号化プロトコルが登場する前のDNSの状態でした。DoTはDNSトラフィックのセキュリティ強化に向けた最初の主要なステップでした。これは、DNSトラフィックをTLS（Transport Layer Security）プロトコルでカプセル化して送信します。専用のポート（ポート853）を暗号化されたDNSトラフィック用に予約しています。この専用ポートの使用はネットワーク管理者の作業を簡素化しますが、一方でDoTトラフィックを検出したり、ファイアウォールや検閲システムでブロックしたりするのが容易になるという欠点もあります。

DoTとは異なり、DNS over HTTPS（DoH）はHTTPS経由でクエリを送信し、ポート443（セキュアなウェブサイトを訪問する際と同じポート）で通常のウェブトラフィックと混在します。これは両刃の剣です：一方では、DoHトラフィックを検出やブロックしにくくし、プライバシーを向上させます。一方、DoHは訪問しているウェブサイトと同じHTTPS接続を共有する場合（特にブラウザでは）があり、意図せずパターンを漏洩する可能性があります。例えば、どのDNSクエリがどのウェブサイトやセッションと関連しているかなどが判明する可能性があります。
本質的に、HTTPおよびHTTPSはトランスポート層プロトコルではありません。 この点を覚えておきましょう。

では、DoHはデータをどのように送信するのでしょうか？アプリ層（ネットワークの標準や手順を定義する部分）でHTTP/2またはHTTP/3を使用し、TCP（HTTP/2の場合）やQUIC（HTTP/3の場合）のような暗号化されたトランスポートプロトコル上で動作します。HTTP/2では、マルチプレクシングという機能により、単一の接続上で複数のDNSクエリを同時に送信できます。これにより、複数のリクエストとレスポンスが互いを待たずに同じ接続を共有できます。ただし、HTTP/2は単一のTCP接続上で動作するため、すべてのデータパケットが同じトランスポート層を共有します。これにより、ヘッド・オブ・ライン・ブロッキング（head-of-line blocking）と呼ばれる問題が発生します。送信中に1つのパケットが損失または遅延すると、その後のすべてのパケット（異なるクエリに属するものであっても）は、欠落したパケットが再送信され受信されるまで待機する必要があります。これにより、他のデータが送信可能であっても、応答の全体的なストリームが遅延します。この問題はDoHに特有のものではなく、TCP上で実行される他のすべてのプロトコルに影響を及ぼします。

DoQでは、各DNSクエリ/レスポンスが独自のストリームに隔離されるため、上記で説明したヘッド・オブ・ライン・ブロッキングの問題が解消されます。

では、本題に戻りましょう：これらはあなたのプライバシーにどのような影響を与えるのでしょうか？

DNSクエリが単一の共有ストリーム経由で送信される場合（HTTP/2を使用したDoHのように）、そのタイミングは関連付けられるのです。1つのクエリが遅延すると、他のクエリのタイミングに影響を及ぼし、トラフィックに目に見えるパターンが生じます。コンテンツは暗号化されていますが、ネットワーク管理者、ISP、または検閲者などの観測者は、これらのパターンを分析して、あなたが訪問しているサイト、訪問した時間、訪問頻度を推測する可能性があります。

DoQがDoHよりもプライバシー面で優れているもう1つの点は、トラフィックの処理方法です。DoQはUDPを基盤に構築され、QUICプロトコルを使用しています。DoHはDNSクエリを通常のウェブトラフィックと混合しますが、DoQはDNSトラフィックを分離します。これはDoTと同様ですが、ヘッドオブラインブロックの問題はありません。この分離により、他のHTTPSコンテンツとの混合が防止され、外部観察者がDNSアクティビティを特定のブラウジング行動と関連付けることが困難になります。ただし、このトラフィックを他のウェブトラフィックから区別することは容易です。

しかし、あなたは疑問に思うかもしれません — HTTPプロトコルの最新バージョンであるHTTP/3は、トランスポート層としてQUICを使用していますが、どうでしょうか？それは良い質問です。実際、主要なブラウザの95%以上（Chrome、Firefox、Safariを含む）は現在HTTP/3をサポートしています。しかし、ここがポイントです：HTTP/3は内部でQUICを使用していますが、HTTP自体はトランスポートプロトコルではありません。そして、適切なトランスポートプロトコルの代替として使用できるものの、これには多くの不要なリスクを伴います。特にプライバシーの観点では、HTTPベースのトラフィックにはクッキー、認証ヘッダー、User-Agent文字列、その他のメタデータなどが含まれます。これらの情報は、トラッキング、フィンガープリント、またはユーザーのプロフィール作成などに利用される可能性があります — これは、DNSトラフィックのような機密性の高いデータと混在させるべきではありません。

要するに、DoHは通常のウェブトラフィックに溶け込むことで強力なプライバシーを提供しますが（検出やブロックが困難になる）、DoQはヘッドオブラインブロックを回避し、DNSトラフィックを他のウェブアクティビティから分離し、識別可能な情報の漏洩リスクを低減します。プライバシーの観点からは、DoQがより適切な選択肢です。

最後に、匿名ユーザーからのご質問です：

公開鍵証明書は現代のネットワークにおいて不可欠なものとなっています。AdGuardはローカルデバイスに証明書を配置しますが、これはデータをどのように保護するのでしょうか？証明書をインストールすることで、害よりも利益が大きいのか、逆なのか？

さらに深く掘り下げる前に、デジタル証明書とは何かを明確にしましょう。最もシンプルな考え方は、デジタル証明書を「すべてのウェブサイト、ウェブサービス、APIが、自分自身が本物であることを証明するために提示するID」と想像することです。一般的に、インターネットに接続され、ユーザーや他のシステムとリモートでやり取りするものは、その正当性を証明するために証明書が必要です。はい、トラフィックはHTTPSで暗号化されており、送信中は安全かもしれませんが、デジタル証明書がなければ、接続しているウェブサイトが本物かどうか、または誰かがそのサイトになりすまして情報を盗もうとしているかどうかを判断できません。

しかし、詐欺師が敏感なデータを盗むためにウェブサイトを作成する用意があるなら、証明書を偽造するのを止めるものは何でしょうか？幸いなことに、それは簡単ではありません。ブラウザがウェブサイトに接続する際、ウェブサイトは自身の証明書と、信頼されたルート証明書発行機関（CA）まで遡る中間証明書チェーンを送信します。ブラウザは公開鍵暗号化を使用して、チェーン内の各証明書のデジタル署名を検証し、問題がなければ接続を許可します。この仕組みにより、CAを侵害またはなりすまさない限り、証明書を偽造することは事実上不可能です。これは不可能ではありませんが、極めて稀なケースです（CAが侵害された最後の重大な事例は2017年に発生しました）。ブラウザとオペレーティングシステムには、信頼されたルートCA証明書の一覧が既に組み込まれており、ベンダーは定期的にこの一覧を更新し、侵害されたまたは信頼できないCAを削除し、新しいCAを追加しています。ユーザーは手動でCAを信頼された一覧に追加することもできますが、当然ながら、これには極度の注意が必要です。

では、AdGuardがこの仕組みにどのように関与しているか説明します。例えば、Windows、Mac、またはAndroid（ブラウザ拡張機能とiOSアプリは動作が異なります）にAdGuardアプリケーションをインストールした場合、ブラウザがウェブサーバーに接続しようとした際、AdGuardはブラウザとサーバーの「間」に配置され、ブラウザのトラフィックがまずAdGuardを通過するようにします。しかし、ブラウザがウェブサイトに直接接続する際、サーバーを信頼する必要があるのと同じように、この場合ブラウザはAdGuardを信頼する必要があります。そうでないと、AdGuardはHTTPSトラフィックを復号化できません。そして、既に述べたように、そのためには信頼された証明書が必要です。そのため、インストール時にAdGuardは特別なルート証明書を生成し、システムにインストールします。

先ほど述べたように、ユーザーはカスタム証明書を軽率に追加すべきではありません。その理由は、信頼すべきでない相手に信頼を寄せると、深刻な結果を招く可能性があるからです。しかし、私たちはセキュリティを非常に真剣に考えています。公開鍵暗号化では、プライベートキーを安全に保管することが極めて重要です。AdGuardは、プライベートキーをデバイス上にローカルで生成します。このキーは暗号化され、ローカルに保存されます。誰とも共有されず、私たちも知りません。

もちろん、AdGuardはアウトバウンドトラフィックも安全に保護します。HTTPSトラフィックを復号化し、そこに含まれるすべての広告とトラッカーをブロックした後、すべてを再暗号化します。AdGuardは、ブラウザと同様にウェブサーバーの証明書を確認してその正当性を検証します。私たちは追加のセキュリティ措置を講じています。詳細については、ナレッジベースの記事をご覧ください.

最終的に、AdGuardは接続のセキュリティを直接強化するわけではありませんが、追加のリスクも導入しません。デバイスにAdGuardアプリをインストールすれば、トラフィックが広告やトラッカーから解放され、安全に保護されることを確信できます。