2つの公開鍵暗号(公開鍵暗号の基礎知識)

はじめに

TLS/SSLをはじめとして、様々な場面で公開鍵暗号が重要な役割を果たしているのは良く知られていることと思います。
ここで公開鍵暗号が何かというと、「かたやデータを公開鍵で暗号化して、かたや秘密鍵で復号する。他人にはデータの内容が漏れない」という説明が一般的です。

そうすると大抵の人は「TLS/SSL、公開鍵で暗号化して秘密鍵で復号するのね」と2つの情報を組み合わせ、それで納得してしまうわけですが、実は今日これは大体において誤り¹です。

この誤りはいまやどうしようもなく広く流布していています。これは、適切な入門書がないことや、そもそも情報の検証を行う人が少ない ( そこまでする動機がない ) という理由によるわけですが、公開鍵暗号という言葉が2通りの意味で流通しているという面も大きいように思われます。

ということで、この2つの意味の違いに着目しつつ、基礎の整理を行いたいと思います。

導入

暗号と言う曖昧な言葉

皆さんが「暗号」という言葉から思い浮かべるものはなんでしょうか。

例えば「軍の暗号が解読されて作戦が漏れていた」や、そこまで大きくなくとも「本音を『縦読み²』で文章に隠した」という話や、関係者間でのみ流通する「符丁」など。解読のキーとなる情報を知っている相手にのみ分かるようにデータを秘密裏に伝達できる方法というのが一般的かと思います。

これは情報セキュリティ的には**機密性(confidentiality)**に相当する機能であり、古来より、もちろん今でも、暗号の機能として非常に重要なものです。

しかし今では、機密性だけではなく、次のような様々な機能が暗号の守備範囲となっています。

• 完全性(integrity)
  データが改ざんされていないかを確認できる
• 真正性(authenticity)
  対象が想定通りの人やモノであるか、なりすましでないかを確認できる(**認証(authentication)**とも)
• 否認防止(non-repudiation)
  発行されたデータをなかったことにする ( しらばっくれる ) ことを防ぐ

そのため、技術の総称としての暗号という言葉を使う分にはしようのない面もあるのですが、詳細に踏み込んだ話をする場合には、どの機能を指すのかが不明瞭になるという意味で曖昧になる懸念があります。何より、やはり一般的に印象の強い機密性でイメージが固定され易い³からです。

もちろん、中には機密性を実現する技術の延長として説明できる暗号もある⁴のですが、機密性に囚われていては暗号技術の全体像を捉えるのは非常に困難であると言えるでしょう。
逆に言えば、「暗号と言えば機密性」特に「暗号化」という先入観を振り払うのが理解への近道ではないかと思います。今回話題の公開鍵暗号は特にそのような側面が強いところです。

公開鍵暗号とは

簡単な歴史

昔の暗号では、当事者間で予め鍵となる秘密の情報⁵を共有し、その鍵を用いて操作を行うというのが当然の前提となっていました。用意した暗号表で暗号文を作る・解読するなど、その典型と言えるでしょう。
もちろん、今でもこの形態は広く使われており、AESに代表される「共通鍵暗号」は、暗号化と復号という2種類の操作に共通の鍵を用いる、機密性を確保するための技術です。

しかし、1976年にディフィーとヘルマンが、2種類の操作に異なる鍵を用いるという概念「公開鍵暗号」と、その実例の1つとしてDH法 ( ディフィー・ヘルマンの鍵交換 ) を発表し⁶、今までの当然の前提を覆しました。
これは、逆計算が困難な数学上の問題を利用することで、ペアになる2種類の鍵の一方 ( 公開鍵 ) を公開したとしても、もう一方の鍵 ( 秘密鍵 ) が事実上割り出せないようにし、それら2種類の鍵で別々の操作を行う方式です。

その発表の翌年には、リベスト、シャミア、エーデルマンの3人が、素因数分解の困難性を元に2種類の機能を実現する公開鍵暗号の方式を発表し⁷、今でもRSA暗号・署名として ( 主に署名の方が ) 広く使われています。

その後、(当時)特許問題をかかえたRSAの代わりにSSHに採用された署名方式DSAや、楕円曲線と呼ばれる数学上の対象を利用した、近年普及した楕円曲線暗号といった暗号群もあります。前述したDH法も含め、これらは「離散対数問題」という問題に基づく方式です。

それ以外にも、ペアリング暗号といった暗号や準同型暗号として挙げられる技術も、2種類の鍵を用いるという点でやはり公開鍵暗号になります。

概要

上述の通り、公開鍵暗号とは次の特徴をもった方式です。

• 逆計算が困難な数学上の問題に基づく暗号方式⁸
• ペアをなす次の2種類の鍵を用いてそれぞれ別々の(非対称な)操作を行う
  • 公開鍵 … 広く一般に公開する。
  • 秘密鍵 … 個人や特定の機器のみで保持する。

どのような機能・操作となるかは暗号方式により様々です。ただ、今後異なる機能を持った公開鍵暗号が生まれてくることもあると思いますが、現時点では以下の3つに分類されます。

• 鍵交換
• 電子署名
• (狭義)公開鍵暗号

それぞれの分類について、次で説明していきます。

なお、公開鍵という手掛かりになるデータを公開し、それでも秘密鍵を漏洩させないという特性のためか、どうしても扱うデータが少量である、あるいは多量のデータの処理に向かないという性質があります。
その点で電子署名は大容量のデータも取り扱うので例外に見えますが、これはハッシュによって大容量のデータから小さなデータを作り出す過程を内部に組み込んでいるためです。

分類

鍵交換

以下の特徴を持った方式です。

• 両者でそれぞれの公開鍵を交換し、自身の秘密鍵と組み合わせて計算を行うことで、秘密裏に何らかの情報を共有できる方式です。
• この共有した情報は、共通鍵暗号の鍵などに活用します。
• 機能的には機密性に相当します。
• DH法や、その楕円曲線暗号版であるECDH等がこれに分類されます。後述の(狭義)公開鍵暗号も鍵交換に転用することができます。⁹

図にすると次のようなイメージになります。

なぜこれで同じ秘密情報が共有できるのか? 今の所広く用いられるのは、DH法およびECDHですが、これらはいずれもべき乗の持つ性質を利用したものです。数学的な説明は、拙記事「電子署名DSA/ECDSAの数的構造(1/2)」の「べき乗の性質」でも触れています。

電子署名

過去にも拙記事電子署名の基礎知識で説明を載せたことがありますが、以下の特徴を持った方式です。

• 対象のデータ(被署名データ)に応じて秘密鍵の持ち主のみが作成できるデータ(署名)を作成する方式です。誰でも公開鍵を用いて、被署名データと署名の整合性を検証することができます。
• この署名は現実世界の署名や押印のように、対象のデータに対する承認や保証の意を示す証跡として活用します。
• この証跡は否認防止の機能に相当します。またデータの改ざんがあれば、検証時に不整合として検出することもできますので、そういう意味では完全性の機能にも相当します。
• RSA署名やDSA、楕円曲線暗号であるECDSAやEdDSAがこれに分類されます。

図にすると次のようなイメージになります。

この検証をどのように実現しているのか? それは方式によって様々であるため、一般化はし辛いのですが、現在流通している方式を見るに、概ね次の図のように2通りの方法で検証値を計算し一致するかどうかを確認するという形態をとっています。

以下、主要な署名方式であるRSA署名と、DSA/ECDSA署名の概要を図示したものです。
※数学的な話は本記事では触れません。が、DSA/ECDSAの方は、拙記事「電子署名DSA/ECDSAの数的構造」にあります。ここでもそれに合わせた表現を使っています。

なお、電子署名の処理には必ずと言ってよいほど、SHA-1やSHA-2(SHA256/384等)といったハッシュが組み込まれています。
これについて、被署名対象データが大容量だとしても分割して個々に署名を作るわけには行かない¹⁰こと、整合性を確認するためのデータのために大容量のデータは必ずしも必要ではないことから、小規模な要約データを得る効果のあるハッシュが利用されるのは、自然な帰結であると言えます。

(狭義)公開鍵暗号

以下の特徴を持った方式です。

• 誰でも公開鍵を用いてデータを暗号化することができ、秘密鍵の持ち主のみが復号して元のデータを得ることができる方式です。
• 暗号化・復号という処理から明らかなように、機密性に相当します。
• RSA暗号等がこれに分類されます。

図にすると次のようなイメージになります。

鍵交換の項で触れた通り、次のようにすることで、鍵交換に転用することもできます。図中、公開情報A,Bを交換することで秘密情報sを共有できるところは鍵交換と同様です。

さて。暗号化・復号という処理で機密性を実現するのであれば、一方の鍵を公開できるというメリットがある分、同じ暗号化・復号を行う共通鍵暗号にとってかわるのではないかと思われるかも知れませんが、そうはなっていません。
それは、公開鍵暗号の特性として、どうしても多量のデータの処理に向かない面があるからです。
更に言うと、鍵の公開という話だけであれば鍵交換によって共有した秘密情報を鍵として共通鍵暗号を使えば事足ります。

このため、S/MIME¹¹や(これまでの)SSL/TLSといった暗号方式でも、(狭義)公開鍵暗号は単なる鍵交換の亜種でしかないような扱いです。

しかし、例えば「準同型暗号」としての特性を持った方式は、鍵交換+共通鍵暗号では代用できない特長を持っています。
「準同型」とは、そもそも公開鍵暗号かどうかと無関係な概念で、暗号の場合であれば「暗号文の状態で合成をした結果が、復号しても反映されている」ことに相当しますが、次のように公開鍵暗号であれば、個々の情報提供者の情報を秘密にしたまま合成した結果のみを渡す使い方¹²ができます。

とは言え、多量のデータ処理には向かないという面はどうしてもあるので、より効率的な改良された手法が期待されている分野でもあるようです。
これ以外にも、暗号化したまま検索にかけられる検索可能暗号など、高機能暗号と呼ばれる分野でもこの(狭義)公開鍵暗号が関連してきますが、詳細は(詳しくないので)割愛します。

分類まとめ

以上の分類を図示すると次のようになります。
なお、カッコ内の名称は、CRYPTRECリスト(電子政府推奨暗号リスト)での分類に対応しています。

2つの公開鍵暗号

さて、今更ではありますが「(狭義)公開鍵暗号」と「狭義」という言葉をつけていたのは、鍵交換・電子署名もひっくるめた広い意味を持つ公開鍵暗号と区別するためでもあります。

(狭義)公開鍵暗号の項で「単なる鍵交換の亜種でしかないような扱い」と表現しましたが、SSL/TLSやSSHといった暗号方式で重要なのは鍵交換と電子署名であって、(狭義)公開鍵暗号は鍵交換の1方式でしかありません。( SSHではそもそも使われてすらいません )

そのような状況で、広義の公開鍵暗号と狭義の公開鍵暗号を混同してしまうようだと、根本で既に間違えているため、より理解を深める段階になって害にしかならないだろうと考えています。

もちろん、(狭義)公開鍵暗号は、暗号化と復号の処理で機密性を実現するということで、昔ながらの暗号のイメージに近く心情的に受け入れやすいというメリットは認められるところですが、同時になんでもかんでも暗号化という考えに囚われ、誤解に導かれてしまうという大きなデメリットがあります。
実際に、今まで取り上げてきた「電子署名=『秘密鍵で暗号化』」という良くある誤解の話や、SSHの公開鍵認証における良くある誤解の話、SSL/TLSの見落とされがちな「認証」という基本機能といった事例は、全てこのデメリットに相当するものと言えるでしょう。

今後、公開鍵暗号の話に触れる際には、どちらの意味で用いられているものか、注意されることを是非お勧めします。

公開鍵暗号と認証

認証の重要性

共通鍵暗号などのように、事前に鍵を共有する必要がある方式は、いかにその鍵を安全にやり取りするかという問題を抱えています。
ここで、公開鍵暗号の中でも鍵交換は、公開鍵のみのやり取りで秘密情報を共有する方式ですから、「鍵を安全にやり取りする」という問題をクリアしているように見えます。

しかし、話はそう単純ではありません。なぜならば、事前に鍵を共有するという前提は、鍵を共有して正しく暗号の処理が行えるのは信頼できる当事者だけという強力な条件も暗黙に含みますが、対して鍵交換の場合、なんの対策もなければ鍵交換を行う相手がそもそも意図した通りかの保証がありません。¹³

そのため、公開鍵暗号の鍵交換では、相手が意図通りかを確認する「認証」という機能が欠かせません。
同時に認証を実現するのも公開鍵暗号の守備範囲内¹⁴となります。

どのように認証に使うか

ここで公開鍵暗号の特徴を思い出してみます。
どの方式も、個人や特定の機器のみで保持する「秘密鍵」があり、「秘密鍵の所有者のみが行える処理」がありました。

そのため単純には、「秘密鍵の所有者のみが行える処理」を行って、それを「公開鍵を使って確認してもらう」ことで、正当な「秘密鍵の所有者」として認証を実現することができます。これは、鍵交換、電子署名、(狭義)公開鍵暗号のいずれでも同じ¹⁵です。
※ただし、現在基本的に認証に使われるのは電子署名のみです。その理由は後述します。

簡単に言うと、次のようになります。

• 鍵交換((狭義)公開鍵暗号含む)の場合
  鍵交換を行って、公開鍵が想定通りであることと、交換した秘密情報が同一であることを確認してもらう。
• 電子署名の場合
  署名データを送信し、公開鍵が想定通りであることと、署名がその公開鍵で検証できることを確認してもらう。
  ※ただし、署名が流用されないような被署名データを共有するため、鍵交換の併用が必要¹⁶です。

なお、これら認証を実現するためには、秘密鍵の所有者がペアとなる公開鍵の本物を相手に渡しておく必要があります。

例えばgithub等のgitリポジトリにアクセスする手段としても馴染みのあるSSH、その代表的な実装のOpenSSHの場合、接続先のサーバが想定通りかを確認するためのホスト認証において、初めてのサーバから公開鍵を受け取る時は次のような確認が行われます¹⁷。

ssh-github初回接続時のホスト鍵確認

$ ssh [e-mail]
The authenticity of host 'github.com (192.30.255.112)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)?

githubの場合、以下のページのように公開鍵情報(fingerprint)が公開されていますから、それによって本物の公開鍵(の1つ)であることを確認できるようになっています¹⁸。

2種類の鍵とPFS

ところで、先ほど「基本的に認証に使われるのは電子署名のみ」という話をしましたが、その理由についても触れておきます。
それには、公開鍵暗号の鍵の2通りの分類が関係します。固定(長期)鍵と、一時(短期)鍵です。
この2つは、文字通り鍵を使用する期間に基づく分類です。

• 固定(長期)鍵
  ある程度の期間、同じ鍵ペアを使い続ける鍵。日常生活でメールアドレスや電話番号を頻繁に変えるわけにはいかないように、認証に使う鍵は固定(長期)鍵である必要がある。
  また、日常生活で実印やサインを頻繁に変えないのと同じ理由で、電子署名の鍵も必然的に固定(長期)鍵になる。
• 一時(短期)鍵
  短期間、あるいは1回限りで使い捨てを行う鍵。
  鍵交換((狭義)公開鍵暗号含む)の鍵は、PFSの観点から一時(短期)鍵であることが望ましい。

ここで、PFS(Perfect Forward Secrecy:前方秘匿性)という考え方が出てきます。公開鍵暗号の秘密鍵はもちろん所有者以外に秘密にしなければなりませんが、万が一漏洩してしまった場合のリスクに関わる話です。
もし漏洩した場合、認証に使う鍵や電子署名の鍵であればなりすましに悪用されるリスクがありますが、あくまでそれは今後の話です。一方で鍵交換の場合、過去に遡って誰かと共有した秘密情報が暴かれ、それら秘密情報を鍵として共通鍵暗号で暗号化した機密データが解読されるリスクを背負うことになります。
短期(一時)鍵であれば、この「過去に遡って」のリスクをなくすことができます。これをPFSと呼んでいます。

ここまで来れば理由は明らかかと思いますが、認証に使うための固定(長期)鍵に向いているのは、電子署名だということです。
実際、SSH(現在のv2プロトコル)、SSL/TLSの2018年に公開されたTLS1.3で認証に使われるのは電子署名のみとなっています。

PKI(公開鍵基盤)

公開鍵を配布する上での問題点

「どのように認証に使うか」の項で、「認証を実現するためには、秘密鍵の所有者がペアとなる公開鍵の本物を相手に渡しておく必要があります」と説明しました。

しかし、自分が何者であるかを証明するために公開鍵を渡すのに、その公開鍵が本物であることの保証が要るという本末転倒な状況に陥っています。( 直に会って手渡しするなどできれば良いのですが )
実のところこの問題は、**どこか暗号技術の外で解決するしかない(信頼はゼロから作り出せない)**のですが、だからと言って各個人が、更に鍵一つ一つ毎に個別に対処するのでは大規模な対応は困難です。
そこで、電子署名によって保証して貰うことを通じて、この対処にかかる手間を軽減する仕組みが考案されています。

1つはPGPのように個人個人の「信頼の輪」を通じて保証関係を連鎖させていく方式、そしてもう1つが**第三者組織を通じて保証を行うPKI(公開鍵基盤)**です。以下ではPKIについて簡単に説明します。

PKIの概要

PKIと言っても、それに関しては色々な話があるのですが、ここで触れるのは公開鍵の所有者であることを証明する(公開鍵)証明書について、です。

公開鍵の所有者を保証するために、**認証局(CA:Certificate Authority)**という組織があり、公開鍵、所有者情報、発行者(認証局)情報、有効期限・用途等の付加情報に署名を付加したデータとして、(公開鍵)証明書を発行します。

申請する際には、証明書署名要求(CSR:Certificate Signing Request)というデータを送付します。この中に公開鍵と所有者(申請者)の情報を入れる形となります。認証局は、申請者とCSRに記された所有者に不整合がないことを確認し、認証局自身の秘密鍵で署名を施し証明書を発行します。
簡単に図示すると次のようになります。

なお、「所有者の情報」と言っても、必ずしも個人名や法人名のことではありません。( 図では擬人化して表現していますが )
SSL/TLSのサーバ認証に用いる証明書であれば所有者とはドメインのこと¹⁹であって、認証局は、「申請者が確かにそのドメインの運営者であること」を確認することになりますし、メールの暗号化・署名に用いるS/MIMEであれば、メールアドレスが該当します。

証明書の検証

続いて、証明書の妥当性 ( その公開鍵が所有者のものであること ) の検証についてです。

証明書に含まれる署名を認証局の公開鍵で検証することで、証明書の妥当性を検証するのですが、この「認証局の公開鍵」も証明書(CA証明書)として提供されます。
そして通常は、そのCA証明書も別の認証局から発行され、階層的に保証が連鎖するような構成を取ります。その階層の最上位は、他の認証局に依存せず、自分自身で証明書を発行する「ルート認証局」です。ルート認証局以外は「中間認証局」と呼ばれます。

例えば、このQiitaのWebサイトに使われているSSL/TLSサーバ証明書をFireFoxの証明書ビューアで見てみると、ルート認証局→中間認証局→qiita.comという3階層になっていることが分かります。

証明書の検証にあたって、公開鍵の所有者は、自身の証明書と、発行に直接・間接に関わる全ての中間認証局のCA証明書を提出します。
それら証明書を受け取った方は、発行者情報を辿りながら対応する認証局の公開鍵で署名を検証していき、最終的に自分が予め持っているルート認証局のCA証明書の公開鍵で検証するところまで成功すれば、全体として検証成功と判断します。

ルート認証局のCA証明書は、信頼の起点(トラストアンカー)として働くことになり、非常に重要な存在となっています。
なので、PKIに関わる暗号技術の外で安全に所有する必要があります。例えば、OSに同梱される形であるとか、Webブラウザソフトに同梱されるといった形で、です。原則として、一般ユーザが手動で管理するようなものではないと考えた方が良いです。²⁰

ハイブリッド暗号

概要

公開鍵暗号の応用として広く使われているハイブリッド暗号として、SSL/TLS、SSHについてもごく簡単に触れます。
※2020/1/11追記: SSL/TLSの概要については、記事「SSL/TLSの基本」も書きましたので、そちらも参考に。

ハイブリッド暗号と言うと、次のように説明されていることがあります。

• (狭義)公開鍵暗号で秘密情報を送る
• その秘密情報を鍵として共通鍵暗号で暗号化する

これは初期の(公開鍵暗号が提唱された時の)アイデアに近いのですが、それだけでは機能的に不十分²¹で、以下の4要素の組み合わせになっています。

• 鍵交換による秘密情報の共有
  ※TLS1.2までのSSL/TLSでは、(狭義)公開鍵暗号での鍵交換もある
• 電子署名によるサーバ認証
  ※TLS1.2までのSSL/TLSでは、固定鍵による(狭義)公開鍵暗号が認証を兼ねる方式も使われている²²
• 共通鍵暗号による暗号化
• HMAC²³あるいはAEAD(認証付き暗号)²⁴による改ざん検知
  ※TLS1.3からはAEADのみとなり、SSHでもAEADに対応してきている

鍵交換により共有した秘密情報は、後半の2要素に使う鍵へと活用されます。

なお、サーバ認証用の公開鍵は、SSL/TLSでは(公開鍵)証明書の形で用いられます。SSHでは証明書を用いる運用もありますが、公開鍵単体で用いる運用の方が一般的です。
クライアント側の認証にも公開鍵暗号(電子署名)が用いられるのは、特にSSHで有名²⁵ですが、これもSSL/TLSでは証明書のみ、SSHでは証明書よりも公開鍵単体の方が一般的です。

おわりに

どうやって○○を実現するの?

人によっては、こういった非対称性を持った操作を可能とする公開鍵暗号、どうやって実現しているのか、疑問に感じまたスッキリさせたいと思うかもしれません。
しかし、そこに踏み込むにはどうしても数学を避けては通れません。
※例えば電子署名については電子署名DSA/ECDSAの数的構造、電子署名EdDSA(ed25519)の数的構造で取り上げています。

だからと言って、皆が皆数学に習熟する必要があるとは思っていません。機能と操作を整理することで十分に理解を進めることはできるはずです。
「暗号化」という言葉は、そこをなんとなく分かった気にさせてくれる魔法の言葉です。しかしその実態は正しい理解へ進む妨げになるまやかしなのです。

1. 大体において誤り: かつてはSSL/TLSにおいては部分的には正しいものでした。もっとも、SSHの説明のように完全に誤っていた事例もあります。詳細はSSHの公開鍵認証における良くある誤解の話をご覧ください。 ↩

2. 縦読み: 折句という言葉遊びの一種ですね。気を付けていれば容易に判別することができるので「暗号」というには大げさかも知れませんが、気付かなければ分からないという意味ではデータを秘匿していると言えるでしょう。 ↩

3. イメージが固定: 実際問題として、機密性のみが強調されるあまり真正性(認証)が意識から外れてしまうという話は、過去に「SSL/TLSの見落とされがちな「認証」という基本機能」でも記しています。 ↩

4. 延長にある技術: 例えば、完全性を実現するMAC(メッセージ認証コード)と呼ばれる技術の1方式であるCMACは、機密性を実現する共通鍵暗号(AES等)を応用したものです。 ↩

5. 鍵となる秘密の情報: 古来は方式そのものを秘密とすることで機密性を確保しようとする発想であったようですが、現代の暗号は方式自体はオープンなものとし、「鍵」という小規模なデータを秘密にするのが一般的です。これは、オープンにすることで逆に問題点をクリアにし暗号としての強度を担保する面と、バックドア(暗号方式に仕掛けられた抜け道)を通じた情報の漏洩やなりすましといった悪用のリスクがないことを保証する面があると言えるでしょう。 ↩

6. 1976年の発表内容: 当時の論文"New Directions in Cryptography"はネット上で幾つか公開されています。 ↩

7. 1977年の発表内容: 当時の論文"A Method for Obtaining Digital Signatures and Public-Key Cryptosystems"もネット上で公開されています。 ↩

8. 逆計算が困難: 尤も、共通鍵暗号なりハッシュなりの他の暗号技術も、逆計算が困難という意味では同じなので、殊更特別な特徴とは言えないかもしれません。 ↩

9. 鍵交換への転用: ただ、(狭義)公開鍵暗号ベースの方式を鍵交換として分類するかは意見が分かれるところかとは思います。 ↩

10. 分割して個々に署名: 分割した場合、順序の入れ替えや故意に一部を欠いたデータも承認することになるのか、という厄介な問題が出てきます。( 例えば、新聞の記事を切り抜いて切り貼りした脅迫文も新聞記事と言えるのか、という話を考えてみて下さい ) ↩

11. S/MIME: S/MIMEは、メールに署名を施すことで送信者がなりすましでないことを確認できる機能と、暗号化によって受信者以外にメールの内容を秘匿する機能を持った技術です。後者の暗号化(共通鍵暗号)に用いる鍵の提供のため、鍵交換あるいは(狭義)公開鍵暗号による鍵交換が用いられます。 ↩

12. 準同型暗号の使い方: 例えば、選挙で各個人の投票内容を伏せたまま、集計結果のみを渡すといった応用が考えられます。 ↩

13. 相手が意図通りか: 相手になりすまして ( あるいはデータのやり取りに介入して ) 代わりに鍵交換を行う可能性があります。それで鍵交換が成立して、以降共通鍵暗号等を使ったとしても、もはや意味がありません。 ↩

14. 公開鍵暗号による認証: 一度、拙記事「電子署名による認証(身分証明)」で説明した内容ではあります。 ↩

15. いずれでも同じ: 実際、SSL/TLSの2019年現在最新のTLS1.3の前のバージョンTLS1.2までは、鍵交換・電子署名・(狭義)公開鍵暗号の3種類での認証方式がありました。鍵交換を使った方式については、拙記事static-DHによるSSL/TLSで紹介しています。 ↩

16. 鍵交換の併用: SSHの公開鍵認証における良くある誤解の話でも、「セッションIDを署名対象データに混ぜておくことで、認証のために生成した署名が流用されることを防ぐ」と説明している部分がこの1例になっています。 ↩

17. サーバからの公開鍵: 一度接続を承認したサーバの公開鍵情報は、known_hostsと呼ばれる鍵データベースに登録されます。これにより、もし次回以降異なる鍵をサーバが提示した場合は、なりすましの可能性ありと判別することができます。よりセキュリティ的に厳しく運用するのであれば、初回の接続前に予め公開鍵情報を鍵データベースに登録しておきます。 ↩

18. 本物の公開鍵であることを確認: もちろん、そのWebサイトが本物かという問題をクリアする必要があるわけですが、そこはSSL/TLSが裏付けとなっています。 ↩

19. 所有者はドメイン: ただし、証明書によっては、ドメイン名以外に運営組織情報も付加される場合があります。もちろん認証局がその運営状況の裏を取った上で、ですが。 ↩

20. 手動で管理するようなものではない:例えばCRYPTREC/IPAのSSL/TLS暗号設定ガイドラインでも、5.4.2章で「ルートCA証明書の安易な手動インストールは避ける」という注意があります。 ↩

21. 機能的に不十分: 本記事でも、SSL/TLSの見落とされがちな「認証」という基本機能でも指摘した通り、認証の機能がないためです。 ↩

22. 電子署名以外のサーバ認証: static-DHによるSSL/TLSで紹介した通り、鍵交換による認証もありますが、実運用はほぼされていません。 ↩

23. HMAC: HMACはハッシュベースのMAC(メッセージ認証コード)で、通信データと鍵を混ぜてハッシュ値を計算することで、改ざん検出用のデータとして用いるものです。 ↩

24. AEAD(認証付き暗号): AES-GCM等のように、MACの機能も備えた共通鍵暗号を指します。 ↩

25. クライアント側の認証: クライアント(ユーザ)認証が必須であるSSHに比べ、SSL/TLSでは(たとえ必要であっても)Webアプリのレイヤで独自に認証を行うことも多く、公開鍵暗号(証明書)によるクライアント認証はマイナーと言えます。なお、SSHの認証方法に誤解が多いのはSSHの公開鍵認証における良くある誤解の話の通りです。 ↩