- HOME
- zkTLSとは？～(1) 導入：Web2の世界で正当性を担保する～
更新日:2025年7月 7日 14:06
公開日:2025年7月 7日 11:00
この記事では、昨今話題の暗号技術である zkTLS についてご紹介します。
zkTLS とは、一言で言うと、「信頼できる第三者（オラクル）」の協力で「正当性」を担保しつつ、ゼロ知識証明を行う仕組みです。zkTLS についてこれから数本の記事を書く予定ですが、1本目となる本記事ではまず導入として、
- 問題設定～コンビニでの年齢確認～
- ゼロ知識証明の説明と、その課題～正当性～
- TLS通信はデータの正当性の説明が苦手
- zkTLS の導入
という順に説明していきます。
zkTLS を実現するための技術的ポイントについての説明は別記事に譲ることにして、この記事では zkTLS という技術の必要性や通常のTLSとの違いについての説明を順に行っていきます。
問題設定～コンビニでの年齢確認～
コンビニでお酒を買うことを想像してみてください。購入のためには、レジで「年齢確認」ボタンを押したり、必要に応じて年齢確認証明書の原本を見せたりする必要があります【1】。
この際、一つ重要なポイントとして、Alice はお店に年齢確認証明書を 見せるだけで渡しはしない ということがあります。一般には、セキュリティ上個人を証明する証明書の取り扱いは非常にリスクが高く、原本は決して譲渡しない、更に、見せないで済むならば見せずに証明だけ行いたい、というのがAlice側の要望となります。
これに応える技術としてゼロ知識証明（Zero Knowledge Proof、ZKP）があります。次節では、ZKP について簡単に概要を述べた後、これからの記事で重要な論点となる「正当性」という課題について説明します。
- 日本フランチャイズチェーン協会の年齢確認ガイドライン（2022/01/17改訂）によると、『酒類・たばこのご購入に際しては、法律に基づきお客様の年齢確認ができる身分証明書（原本のみ）等をご提示いただく場合がございます。』と記載されています。
https://ss.jfa-fc.or.jp/folder/top/img/n_20230523115810t37usyum2bynq2qg.pdf
ゼロ知識証明とその課題～正当性～
ゼロ知識証明の説明のため、前節の状況を以下のように言い換えてみます。
- ショッピングサイトA→サーバ（Server）
- Alice→証明者（Prover）
- お店→検証者（Verifier）
- 年齢確認証明書→証拠（Witness）
証明者・検証者・証拠、というのはゼロ知識証明特有の用語です。今回証明者が行いたいことは、「『証明者自身が20歳以上である』という主張が正しいことを、検証者に対して証明する（言い換えると、検証者に納得してもらう）」ことです。ただし、この証明の際、年齢確認証明書は検証者含む第三者には隠さないといけません。このように、証明に用いるけど第三者に隠さないといけないデータのことを、「証拠（Witness）」と呼びます。
この状況を、ゼロ知識証明のフローで説明すると、図2のようになります。「証拠ファイル」は証明者の秘密情報（証拠）を含み、「証明ファイル」はその秘密情報を開示することなく、主張の真偽を示すことのできる暗号化された情報です。
まず、証明者はサーバから自分の年齢に関する公的な情報を「証拠ファイル」の形でダウンロードします。そのあと、この証拠ファイルを入力として、主張の記述されたスクリプトを用いて証明を実行することで、暗号化された証明ファイルが作成されます。検証者はこの証明ファイルに対して検証コマンドを実行することで、主張「証明者が20歳以上である」の真偽を確認することができます。また、検証者がこのフローで知りうるのは主張の真偽のみで、証明者が何歳かという具体的な情報は得ることができません。
これは ZKP のフローの典型的な例ですが、このフローには穴があります。例えば以下の図3は、証明者が検証者を騙しているケースです。
サーバにある原本上では証明者は15歳であると記述されているにもかかわらず、証明者は改竄した証拠ファイルを用いて「主張は真である」という証明を作成し、検証者を騙しています。疑り深い検証者が証明を信じるためには、 証明者がサーバにある原本と同じデータを証明に用いていること を担保する必要があります。※ ZKP に限らず、一般的に暗号プロトコルの場合は、登場人物は皆「疑り深い」ことにご注意ください。
ここで、本節のタイトルにも書かれている「正当性」の説明のための準備が整いました。あるデータが正当性を持つとは、以下の2つの性質を持つことを指します。
- Provenance （出所）: データの情報源が想定通りである
- Authenticity （真正性）: データが情報源にあるもの（原本）から改竄されていない
この2つを満たすデータは、想定通りの情報源にある原本と同じものであるということが保証され、信用できるデータであるといえます。 例えば上で述べた「年齢確認のZKPフロー（証明者が検証者を騙しているケース）」の例だと、Authenticity を満たしていない、ということになります。
データの正当性証明の必要性はここ近年飛躍的に上がってきており、例えば、
- 本物の画像とAI生成のフェイク画像を区別する（Provenance）
- 業務のデジタル化に伴うデータ改竄対策（Authenticity）
といった必要性は日々刻刻と増しています。
TLS通信はデータの正当性の説明が苦手
TLS（Transport Layer Security）はWeb通信の安全を支える基本技術ですが、「第三者へのデータの正当性の説明」は得意ではありません。この節では、その理由を具体的に見ていきましょう。そのために、前節でご紹介した「年齢確認のZKPフロー」を少し詳細化します。
図4の通り、サーバと証明者の間の経路でデータが改竄されないことはTLS暗号化により保証されるのですが、ここでの問題のポイントは 証明者がダウンロードした証拠ファイルの正当性を第三者に対して説明する 、という点になります。
通常のTLSプロトコルでこの問題を解決するのは困難です。その理由は、TLS通信においては暗号化・復号化を行う共通鍵はサーバとクライアント間のみに共有される【2】ため、「共通鍵を使って正しく暗号化・復号化したこと」を第三者が証明できないからです。しかも、証明のために安易に共通鍵を第三者に渡してしまうと、その第三者がデータを自由に暗号化・復号化できてしまい、データの閲覧や改竄という新たなリスクが生じてしまいます。
この課題を解決する技術が、今回ご紹介する zkTLS です。
- TLSハンドシェイクというサーバ・クライアント間のメッセージのやり取りの後、生成されます
余談 ：この問題を Web3、つまりブロックチェーン技術を前提としたWebだと、この問題はDID（分散型ID）やVC（検証可能な資格情報）などのブロックチェーン技術を使って解決することができます。しかし、今回ご紹介するzkTLSは、Web2、つまりブロックチェーンを前提としないWebで第三者への正当性を証明できる、というところが大きな特長になります。
zkTLS の導入
zkTLS はTLS通信における共通鍵の扱い方を少し変えることで、「信頼できる第三者」がデータ復号の一部を担保し、正当性を第三者に証明する仕組みです。これまでのサーバ→証明者→検証者のZKPフローに「信頼できる第三者」を加えることで正当性を保証した一連のフローを、「 zkTLS 」と呼びます。
通常の TLS での暗号化・復号化プロセスとzkTLSのものとを簡単に比較した図が以下になります。この図ではサーバ・クライアントというTLS通信での役割にフォーカスするため、これまでの節で「証明者」と呼んでいたエンティティを「クライアント」と呼ぶことにします。
zkTLSの暗号化・復号化プロセスでは通常のTLS通信と比べ、以下3つの特徴があります。
- 特徴①：信頼できる第三者の協力により、クライアントがダウンロードしたファイルの正当性を保証することができます。
- 特徴②：信頼できる第三者は、サーバには何も協力しません。したがって、サーバから見ると通常のTLS通信とは変わりありません。
- このことは「正当性を担保するzkTLS導入のために、既存の Web2 の世界のWebサーバの仕組みを全く改変する必要はない」ことを意味します。
- 特徴③：信頼できる第三者は、復号化したファイルを見ることはできない
- このことは、「データ漏洩という観点で、通常のTLS通信と同等の安全性が担保されている」ことを意味します。
信頼できる第三者がどのように協力するか、という観点で、zkTLS は「MPC（Multi-Party Computation）モデル」・「プロキシモデル」などと分類することができます。これらの概要については、次回の記事で説明します。
