公開鍵暗号方式の種類と概要
公開鍵暗号方式にはいくつか種類がありますが、この記事でメインに説明するのは『RSA』の概要です。
各種公開鍵の概要は以下の通りです。
その他に重要な公開鍵暗号方式として『Diffie Hellman (DH) 鍵交換』もありますが、DH 鍵交換の仕組みについては以下を参照下さい。
RSA 公開鍵/秘密鍵の仕組みを分かりやすく図解
まずは RSA の公開鍵/秘密鍵について説明します。
特定のサーバ A が秘密鍵を持ち、任意のクライアントがその対となる公開鍵 (サーバ A の公開鍵) を持っているとします。
公開鍵を使って暗号化すると秘密鍵でのみ復号できます。秘密鍵は原則サーバ A 以外には知られないため、サーバ A のみが復号でき、機密性が確保できます。
逆に、秘密鍵を使って暗号化すると、公開鍵でのみ復号できます。公開鍵は広く知られる前提であるため、機密性の確保はできませんが、「サーバ A の公開鍵で復号できた」通信というのは、「発信源が間違いなくサーバ A であり、内容は改竄されていない」という完全性・真正性が確保できます。
これは主に『デジタル署名 (Digital-Signature)』で使われます。
なお、上図は『RSA でデジタル署名を行う場合』の話ですが、DSA,ECDSA,EdDSA でデジタル署名を行う場合、これらは署名専用のアルゴリズムであるため、そもそも暗号化/復号する機能がありません。『秘密鍵で署名』し、『公開鍵で検証』する機能のみです。
デジタル署名の詳細については以下をご参照下さい。
何にせよ、RSA ではこの性質を利用し、サーバに公開鍵及び秘密鍵をインストールすることで、以下のことができるようになります。
任意のクライアントから特定のサーバ A への通信の機密性確保
サーバ A に一対の公開鍵と秘密鍵をインストールします。そして通信をしたいクライアントが現れたら、そのクライアントに公開鍵を配布します。そのクライアントは通信内容を公開鍵で暗号化をした上でサーバ A へ通信します。
サーバ A は全てのクライアントの通信を、1 つの秘密鍵で復号して中身を確認することができます。
一方、サーバ A 以外の全世界の機器は秘密鍵が無いので通信は復号できません。公開鍵では復号出来ないので、公開鍵は盗聴されても影響ありません。
特定のサーバ A から任意のクライアントへの通信の完全性・真正性確保
送信元がサーバ A であること (真正性)、およびサーバ A からの通信が改竄されていないこと (完全性) を、任意のクライアントが検証できます。
サーバ A は通信を送るときに、その通信内容のハッシュ値を秘密鍵で暗号化したデータを一緒に送ります。
クライアントは通信内容のハッシュ値を計算しつつ、付加されたデータを公開鍵で復号し、同じ値になるかを確認します。合致すればそれはサーバ A からの通信であり、通信内容は途中で改竄されていないということを意味します。
筆跡鑑定のように後から人を特定することができるので『デジタル署名 (Digital-Signature)』と呼ばれています。
最近ではビットコインの multi-sig が話題になりましたが、これは、ビットコインを使う際に、複数人 (例えば夫婦) による上記デジタル署名のサインが必要となる、デジタル署名の応用例です。
共通鍵暗号方式と公開鍵暗号方式の比較 メリット・デメリット
共通鍵暗号方式の代表格 AES と公開鍵暗号方式の代表格 RSA を比較します。
| 比較項目 | AES 共通鍵暗号方式 | RSA 公開鍵暗号方式 |
|---|---|---|
| 暗号・復号速度 (計算負荷) | 高速 (低負荷) | 低速 (高負荷) |
| 鍵をセットするタイミング | 通信開始より前に共有 | 通信開始時に公開鍵を送付 |
| クライアント数Nのときの 鍵の必要数 | 2N | N+1 |
| 2030年以降でも使える強度 のbit数 (セキュリティ強度) | 256bit | 3072bit |
一番身近な具体例 https (SSL/TLS) への応用
https (SSL/TLS) では通信の暗号化自体は共通鍵暗号方式を使いますが、その共通鍵の元ネタの交換には RSA とは異なる公開鍵暗号方式が使われます。具体的には『DH (Diffie Hellman) 鍵交換』が利用されます。
DH では上で説明してきたものとは異なるタイプの公開鍵 (DH 公開鍵) を使います。この DH 公開鍵はサーバとクライアントでそれぞれ異なるのですが、この 2 つの公開鍵を合体させて共通鍵を生成します。
ですが、DH には認証機能がなく、成り済ましに弱いため、RSA 公開鍵暗号方式による認証を行いながら共通鍵の交換を行います。
なので https (SSL/TLS) における RSA 公開鍵 (DH 公開鍵ではなく今まで説明してきた公開鍵暗号方式) は『認証』の用途のみに使われます。
具体的にはクライアントは以下 3 つを確認します。
- デジタル証明書の信頼チェーンの最上位 (ルート証明書) が「信頼されたルート証明機関」に登録されているか？(デジタル証明書自体が信頼できるものか？)
- 署名を公開鍵で復号したものと、証明書のハッシュ計算結果が同じになるか？(証明書自体が改竄されていないか？)
- アクセス先 URL のドメイン名とデジタル証明書の SANs (サブジェクト代替名) は一致するか？(※1)
- サーバの秘密鍵によりデジタル署名された「DH 公開鍵 (SV)」を、RSA 公開鍵で検証できるか？(サーバは RSA 秘密鍵を持っているか？)
(※1) 以前は「コモンネーム (CN)」が一致するかどうかを見ることがありましたが、最近では SANs のみを確認する傾向にあります。
このように公開鍵方式と共通鍵方式を両用することで、お互いのメリットをフルに活かしているのです。
例として Web サーバへの https アクセスを考えます。
Web サーバは『RSA 秘密鍵』と『RSA 公開鍵付き証明書 (デジタル証明書、より一般的にはサーバ証明書)』を持ち、クライアントはサーバへのアクセス時にサーバから RSA 公開鍵付き証明書を提示されます。
RSA 公開鍵付き証明書は『証明書本体』と『署名』に明確に分かれており、証明書本体には公開鍵が内包されています。一方、署名は、証明書本体をハッシュ化し、秘密鍵で暗号化したものです。
また、証明書本体には『サブジェクト代替名』というサーバへアクセスする際の URL のドメイン名が書かれています。例えば www.yahoo.co.jp の Webサーバなら、サブジェクト代替名も www.yahoo.co.jp になります。
なお、https プロトコルのシーケンスは以下の通りです。
- クライアントがサーバへ https アクセス、その際、自身が使える暗号方式を通知
- サーバは最適な暗号方式を返信しらさらに署名付き証明書をクライアントへ提示
- クライアントはルート証明書の検証、証明書の改竄有無、アクセス URL のドメイン名とSANs (サブジェクト代替名) の合否を確認
- 問題なければ、クライアントとサーバ間で DH 公開鍵方式により、共通鍵の素を共有、併せてサーバからは RSA 秘密鍵による署名をクライアントへ送付 (DH は成り済ましに弱いためデジタル署名で相手を認証する)
- クライアントとサーバはそれぞれ共通鍵の素から共通鍵を生成
- 共通鍵で暗号化通信開始
また、ケースとしては少ないですが、SSL/TLS にはオプションで、クライアントの認証を行うこともできます。
その他の有名な使用例 SSH への応用
SSH を使うための事前準備として、サーバ側ではまず最初に RSA 等の秘密鍵/公開鍵のペアを生成する必要があります。ここでは例として RSA 秘密鍵/公開鍵を使うこととします。
実際に SSH クライアントからアクセスを受けた場合、まずは DH 鍵交換により共通鍵を共有し、以降の通信を全て暗号化した上で、デジタル署名による認証を行います。
なお、共通鍵は時間経過とともに別の鍵に変えていきます。
SSH サーバの認証（ホスト認証）
SSH クライアントはクライアント側の DH 公開鍵を送信します。それを受けてサーバはサーバ側の DH 公開鍵を送信しますが、同時に『RSA 公開鍵』、『RSA 秘密鍵による署名』も送信します。
SSH クライアントは SSH サーバからの署名を RSA 公開鍵で検証し、相手が正しい通信相手だと認証するのです。これがホスト認証です。
なお、SSH クライアントは、それが初回アクセスであれば、SSH サーバの IP アドレスと紐付けて、その RSA 公開鍵をインストールします。TeraTerm の場合、以下のような画面が表示されます。"Continue" を押下するとクライアントに RSA 公開鍵がインストールされます。
次回以降、同じ IP へのアクセス時に、提示される公開鍵が変わると、警告を出します。単にサーバを更改した場合は問題無いですが、身に覚えが無い場合、成りすましの可能性があるためです (その後の ID パスワード入力が漏洩し、正規のサーバに不正ログインされる可能性がある)。
例えば TeraTerm だと以下のような警告画面が出ます。本当に鍵を変えているのであれば "既存の鍵を,新しい鍵で上書きする" にチェックを入れ、"続行" を押下し、鍵を置き換えます。
SSH クライアントの認証
ホスト認証が終わった後は逆に、SSH サーバが SSH クライアントを認証します。これには大きく 2 つのやり方があります。
1 つは ID パスワード認証、もう 1 つは公開鍵認証です。
SSH クライアントの ID パスワード認証
前述の通り、SSH ではまず鍵交換により共通鍵での通信暗号化が為されます。なので SSH クライアントの ID パスワード認証は、共通鍵で暗号化された状態でサーバへ送付されます。サーバはやはり共通鍵でその情報を復号し、ID パスワードが正しいかどうかを確認します。
SSH クライアントの公開鍵認証
SSH クライアントの公開鍵認証においては、ID パスワードを使わず、クライアントの公開鍵による認証を行います。
この方式を使うためには、SSH クライアント側でも事前に RSA 等の公開鍵/秘密鍵のペアを生成し、公開鍵を SSH サーバへインストールする必要があります。
例えば user-a というユーザが SSH アクセスするためには、サーバ側の "/home/user-a/.ssh/authorized_keys" に公開鍵情報を書き込んでおきます。
あとは SSH クライアントが『クライアント側の RSA 秘密鍵による署名』をサーバへ送信するだけです。サーバ側では RSA 公開鍵を前述の authorized_keys に保有していますので、これを使って署名の検証を行います。この検証に成功すれば SSH クライアントが正しい (正しい RSA 秘密鍵を持っている) と判断します。
秘密鍵のセキュリティ、パスフレーズの必要性
秘密鍵はとても重要なものであるがゆえに、メール添付等を含め、安易に複製すべきではありませんし、保護すべきです。Windows 等のいくつかのソフトウェアでは秘密鍵をエクスポートできないような保護設定があります。
また、OpenSSL コマンドや ssh-keygen コマンド等で鍵ペアを作成する際、秘密鍵にパスフレーズを付けて保護することもできます。
このパスフレーズによる保護は、もし秘密鍵の利用タイミングが手動実行時のみであれば、利用のたびにパスフレーズを入力すればそれで問題ありません。
ですが例えば Apache の https 用秘密鍵をパスフレーズで保護している環境において、Web サーバが予期せず再起動してしまった場合はパスフレーズの入力を求められ、手動で打ち込まないと httpd が起動しません。
なので自動で秘密鍵が利用されることを期待する環境においては、パスフレーズを設定してはいけいません。
一方、人間がサーバ等の管理のために SSH 接続で秘密鍵を使う場合は、あった方がセキュリティは高くなります。
一見同じものとも思われがちですが、これはニ要素認証の考え方では、異なるものです。二要素認証では、認証の要素として『何を知っている？』『何を持っている？』『何者なのか？』といった種類の中から異なる 2 種類の要素に合格することで認証成功にする、という考え方をします。(同じ要素の中で 2 回認証するものを 2 段階認証と言います)
パスフレーズは人間が頭の中で覚えておくのが前提なので『何を知ってるか？』に該当します。一方、秘密鍵の内容は人間が覚えきれるものではなく、『何を持っているか？』に当たります。(具体的には秘密鍵のファイルそのもの)
このように、パスフレーズを設定した秘密鍵を使うことで、二要素認証を実現しているのです。
※ちなみに、『何者なのか？』は主に静脈認証や網膜認証等の生体認証のことです。
コメント
色々調べられたり考えられたりしたのだろうとは思いますが、基本的なところが間違いだらけです。詳しく書くならちゃんと裏をとる、分かってない部分は無理に詳しく書かない、何はともあれ基本を押さえるのが大事だと思います。
> angel さん
コメントありがとうございます。私も全ての発言、記述で正しいことを言っているつもりはないです。それはangelさんも同じかと思いますが、間違っているものはできる限りで直したいと思っています。
なので、ぜひ具体的な間違いの箇所を教えて頂けないでしょうか。
宜しくお願いします。
「正しい」という保証を完全に行うのはそれは難しいでしょうが、それでも妥当性をどのように担保するのかは書き手として考えなければいけないと思います。少なくとも「どこかでそう書いてあったから」は全くあてになりません。
では、ざっと見当たる点についてコメントします。
—
○公開鍵・秘密鍵でできること ～暗号化とデジタル署名～
* 逆に、秘密鍵を使って暗号化すると、公開鍵でのみ復号できます。
問題点: そんな事実はない
備考: まず、公開鍵暗号の「暗号化」と「署名」は別技術。
RSAに限っては「暗号化」「署名」に両用できるという特殊性があり、そこから生まれたよくある誤解。
○特定のサーバ A から任意のクライアントへの通信の完全性・真正性確保
* その通信内容のハッシュ値を秘密鍵で暗号化したデータ
問題点: 上の間違いの延長で同様に間違い
備考: 「署名」の仕組みを詳しく説明するのには数学が必須。
なおかつ方式によって計算内容は様々なので、一般向けにはむしろ踏み込むべきではない。
「署名」「検証」で十分だし、その意味を押さえるという基本を確かにする方が大事。
○共通鍵暗号方式と公開鍵暗号方式の比較 メリット・デメリット
この表自体が微妙
メリット・デメリットというより、向き・不向きに応じて
色々使い分けされてる、くらいのことしか言えないと思う
○一番身近な具体例 https (SSL/TLS) への応用
* その共通鍵の元ネタ (プレマスターシークレット) は公開鍵暗号方式が使われます。
気になる点: 「プレマスターシークレット」は TLS1.2までの名前で、TLS1.3からは
シェアードシークレットなので、補足を入れるなり詳しい呼び名を省くなり工夫がほしい
* 具体的には『DH (Diffie Hellman) 鍵交換』が利用されます。
問題点: 今時ECDHのことも言おうよ
* ですが、DH には認証機能がなく、成り済ましに弱いため、
気になる点: 鍵交換・認証を役割分担してるだけなので、この説明はちょっとネガティブに穿って見える
* RSA 公開鍵 (DH 公開鍵ではなく今まで説明してきた公開鍵暗号方式) は『認証』の用途のみに使われます。
良い点: 「認証」をちゃんと言葉にしてる説明は少ないので良いと思う。
問題点: ただ、その認証が何を指しているか説明がない。あと、「署名」であることの明記がほしい
図中の「☆サーバ認証」だけだと50点、これは証明書の検証にすぎないため
* 図中「DiffieHellman鍵交換」
問題点: そんな処理はしていない。というかDH秘密鍵はどこいった
* 図中「共通鍵暗号方式」
気になる点: MAC/AEAD による改ざん検知の話も出しておきたい
* 証明書本体には『コモンネーム』というサーバへアクセスする際の URL 名が書かれています。
問題点: 「コモンネーム」ではなく「SANs」、URL名ではなく「ドメイン名」
備考: ドメイン名確認において、コモンネームはSANsがない場合の予備的なもの
* クライアントは署名付き証明書を受け取ると、証明書の発行元 (ルート) が信頼できるルート証明書かどうかの確認、
問題点: 中間認証局の考慮がないので、表現を見直した方が良い
* ④問題なければ、クライアントとサーバ間で DH 公開鍵方式により、…(略)
良い点: ここの記述自体は特に間違っているとはいえないので良いと思う。
備考: ただ、そこまでの記述や図に齟齬があるので、この文面の内容を明確に把握できてないのではないか。
○その他の有名な使用例 SSH への応用
* 以降の通信は (公開鍵の送付も含め) 全てこの共通鍵による暗号化を行った上で行います。これにより公開鍵の改竄を防ぐことができます。
良い点: 鍵交換後の通信が暗号化されているのを挙げるのは良いと思う
問題点: 「公開鍵の改ざんを防ぐ」は特に意味がないのでミスリーディング。なにか誤解があるのではないか。
○SSH サーバの認証（ホスト認証）
* 共通鍵を交換後、サーバからクライアントへサーバの公開鍵が提示されます。
問題点: 鍵交換と公開鍵の提示は同時なので ( プロセス自体が一体化してるので )、そのような順序関係はない
* そしてクライアントはある適当な数を公開鍵で暗号化し、それをサーバに送信します。(略)これがSSHサーバの認証です。
問題点: そのような事実はない。というか使ってるのは「署名」なのだから暗号化は関係ない。
○SSH クライアントの ID パスワード認証
* SSH クライアントの ID パスワード認証においては、ID パスワード情報を共通鍵で暗号化してサーバへ送付します。
気になる点: ID・パスワードを暗号化、というよりも、鍵交換成立後で通信が暗号化されているから
ID・パスワードも保護される、が妥当。殊更にID・パスワードを狙って暗号化しているようにも読める
○SSH クライアントの公開鍵認証
* 例えば “/home/user-a/.ssh/known_hosts” に公開鍵情報を書き込んでおきます。
問題点: 一般には authorized_keys ファイル。known_hosts は役割が違う
* あとはホスト認証の逆を行います。
問題点: ホスト認証の話と同様、そのような事実はない
—
この記事に関係する話は、以下を参考にどうぞ
* 2つの公開鍵暗号
https://qiita.com/angel_p_57/items/897bf94160be8d637585
* SSL/TLSの基本
https://qiita.com/angel_p_57/items/446130934b425d90f89d
* SSHの公開鍵認証における良くある誤解の話
https://qiita.com/angel_p_57/items/2e3f3f8661de32a0d432
angel さん
コメントありがとうございます。正直いきなり喧嘩腰で不愉快だなぁと思っていましたが、ご指摘に関しては参考になりました。ありがとうございます。
ご指摘の 17 点のうち、2 点 (SSHの認証) については確かに裏取りが甘かったです。ここに関しては私の理解不足だったので修正しました。
1 点については文章を修正したが図の修正が間に合ってなかったものがあります。こちらについても修正しました。
1 点は angel さんの認識違いでは？と思う箇所がありました。
1 点は微妙だというコメントですが、特段微妙だとは思いませんでした。(理論と実装をごっちゃにしている節が見られました)
4 点については、明らかな間違いであったり、説明を修正した方がよい部分がありましたが、基本がどうというレベルの話ではなく、些細な点だと、個人的には思っています。
残り 8 点含む全体的な話として、ご指摘は主にスタンスの違いだと思っています。
スタンスというのは具体的には、angelさんの説明が「分かり易さを犠牲にしても、正しい情報を書くべき」というスタンスだと推測しますが、私は「多少は正しさを犠牲にしてでも、まずは読む人に腹落ちさせるのが優先」というスタンスです。
正しさというのは主に『細かいところを全部書くかどうか』です。例えばこの記事ではDHの説明だけしかしていませんので、それゆえそれしか方法が無いようにも見えるからデタラメだ！という主張は理解はできますが、秘密鍵初心者にDHとECDHの違いを説明しても分かるわけないんじゃない？という理由で省いてたりします。
正しさを犠牲にすることにより大部分の人が間違った知識で技術者として不利益を被るのであれば本意ではありませんが、そのような不利益よりも理解の助けとなり実務に役立つ利益を考えると、私はこのスタンスで記事を作りたいと思っています。
本記事を読んだ人がステップアップしてより細かなものを学んでいき、「ああ、あのサイトの説明は少し違うな」と思われることもあるでしょうが、私としてはそれでもこのサイトの役割は果たしている、と考えています。
そんな前提で、頂いたコメントについて返信させて頂きます。
>○公開鍵・秘密鍵でできること ～暗号化とデジタル署名～
>* 逆に、秘密鍵を使って暗号化すると、公開鍵でのみ復号できます。
>問題点: そんな事実はない
>備考: まず、公開鍵暗号の「暗号化」と「署名」は別技術。
>RSAに限っては「暗号化」「署名」に両用できるという特殊性があり、そこから生まれた
>よくある誤解。
そんな事実は無い、というよりは「RSA」のことを言っている、という前提が抜けているだけだと思います。追加しました。
>○特定のサーバ A から任意のクライアントへの通信の完全性・真正性確保
>* その通信内容のハッシュ値を秘密鍵で暗号化したデータ
>問題点: 上の間違いの延長で同様に間違い
>備考: 「署名」の仕組みを詳しく説明するのには数学が必須。
>なおかつ方式によって計算内容は様々なので、一般向けにはむしろ踏み込むべきではな
>い。
>「署名」「検証」で十分だし、その意味を押さえるという基本を確かにする方が大事。
問題点については上記と同じですが、「一般向けにはむしろ踏み込むべきではない。」や「～にする方が大事。」についてはスタンスの違いです。「すべきでない」というのは主観の押し付けに聞こえます。(客観的な論拠を付けられるなら別ですが)
>○共通鍵暗号方式と公開鍵暗号方式の比較 メリット・デメリット
>この表自体が微妙
>メリット・デメリットというより、向き・不向きに応じて
>色々使い分けされてる、くらいのことしか言えないと思う
ここでは現実世界での実装の話をしているわけではありません。
方式のメリット・デメリットであり、その結果、実装で使い分けがされているわけですよね。
>○一番身近な具体例 https (SSL/TLS) への応用
>* その共通鍵の元ネタ (プレマスターシークレット) は公開鍵暗号方式が使われます。
>気になる点: 「プレマスターシークレット」は TLS1.2までの名前で、TLS1.3からは
>シェアードシークレットなので、補足を入れるなり詳しい呼び名を省くなり工夫がほし
>い
これは知りませんでした。たしかにtls 1.3 の RFC をさらっと検索した感じでは draft の途中から
premasterというワードが出てこなくなりました。とりあえず消しときます。(しかし本質からは外れた指摘で、基本がなっているかどうか、とは違う話かと。)
>* 具体的には『DH (Diffie Hellman) 鍵交換』が利用されます。
>問題点: 今時ECDHのことも言おうよ
先ほど申した通り、スタンスの違いです。「この記事で何を説明したいか」という観点で、省いてます。
この説明を入れるならそれこそ数学的な話が必要になり、私が説明したい内容から焦点がぼやけます。中途半端な説明をするよりは書かない方がいいと判断しています。数学に強い方がこのような主張をされるのは何となくお気持ちは分かりますが。
>* ですが、DH には認証機能がなく、成り済ましに弱いため、
>気になる点: 鍵交換・認証を役割分担してるだけなので、この説明はちょっとネガティ
>ブに穿って見える
うーん、仰っていることは分かりますが、、この説明のほうが私は理解が進むと思います。
「これこれこういう役割分担をしています」とさらっと説明してしまうと「DHは成りすましに弱い」
という事実が印象に残らないと思いますので。
>* RSA 公開鍵 (DH 公開鍵ではなく今まで説明してきた公開鍵暗号方式) は『認証』の用
>途のみに使われます。
>良い点: 「認証」をちゃんと言葉にしてる説明は少ないので良いと思う。
>問題点: ただ、その認証が何を指しているか説明がない。あと、「署名」であることの
>明記がほしい
>図中の「☆サーバ認証」だけだと50点、これは証明書の検証にすぎないため
この次の図で説明しています。分かりづらかったので文章を箇条書きにして分かりやすく補足をつけました。
>* 図中「DiffieHellman鍵交換」
>問題点: そんな処理はしていない。というかDH秘密鍵はどこいった
仰る通りです。修正しました。
>* 図中「共通鍵暗号方式」
>気になる点: MAC/AEAD による改ざん検知の話も出しておきたい
確かにAEADの話は入れたいのですが、これも焦点がぼやけるのでここは割愛。
>* 証明書本体には『コモンネーム』というサーバへアクセスする際の URL 名が書かれて
>います。
>問題点: 「コモンネーム」ではなく「SANs」、URL名ではなく「ドメイン名」
>備考: ドメイン名確認において、コモンネームはSANsがない場合の予備的なもの
これは違うのでは？そもそもSANsってサブジェクト”代替”名ですよね？
コモンネーム以外にも代替で使える名前なのでは？(コモンネームはサブジェクト内にある)
しかも拡張フィールドですし、本来的にはコモンネームだと思いますが。
なお、本記事のメインは「秘密鍵・公開鍵」ですので、httpsに特化して色々と
詳しい説明をするつもりはありません。他の記事でこのあたりは記載しています。
>* クライアントは署名付き証明書を受け取ると、証明書の発行元 (ルート) が信頼でき
>るルート証明書かどうかの確認、
>問題点: 中間認証局の考慮がないので、表現を見直した方が良い
これも焦点がぼやけるので割愛。
>* ④問題なければ、クライアントとサーバ間で DH 公開鍵方式により、…(略)
>良い点: ここの記述自体は特に間違っているとはいえないので良いと思う。
>備考: ただ、そこまでの記述や図に齟齬があるので、この文面の内容を明確に把握でき
>てないのではないか。
図の修正が追いついていなかったので修正しました。
>○その他の有名な使用例 SSH への応用
>* 以降の通信は (公開鍵の送付も含め) 全てこの共通鍵による暗号化を行った上で行い
>ます。これにより公開鍵の改竄を防ぐことができます。
>良い点: 鍵交換後の通信が暗号化されているのを挙げるのは良いと思う
>問題点: 「公開鍵の改ざんを防ぐ」は特に意味がないのでミスリーディング。なにか誤
>解があるのではないか。
改めて見てみて、自分でも意味わからなかったです。書き直しました。
>○SSH サーバの認証（ホスト認証）
>* 共通鍵を交換後、サーバからクライアントへサーバの公開鍵が提示されます。
>問題点: 鍵交換と公開鍵の提示は同時なので ( プロセス自体が一体化してるので )、そ
>のような順序関係はない
>
>* そしてクライアントはある適当な数を公開鍵で暗号化し、それをサーバに送信します
>。(略)これがSSHサーバの認証です。
>問題点: そのような事実はない。というか使ってるのは「署名」なのだから暗号化は関
>係ない。
これはご指摘の通り、裏取りを取らずに記載していました。確認し、修正しました。
>○SSH クライアントの ID パスワード認証
>* SSH クライアントの ID パスワード認証においては、ID パスワード情報を共通鍵で暗
>号化してサーバへ送付します。
>気になる点: ID・パスワードを暗号化、というよりも、鍵交換成立後で通信が暗号化さ
>れているから
>ID・パスワードも保護される、が妥当。殊更にID・パスワードを狙って暗号化している
>ようにも読める
SSHの主機能から考えて、そんな解釈します？と言いたいですが一理あるので修正しました。
>○SSH クライアントの公開鍵認証
>* 例えば “/home/user-a/.ssh/known_hosts” に公開鍵情報を書き込んでおきます。
>問題点: 一般には authorized_keys ファイル。known_hosts は役割が違う
凡ミスです。修正しました。これも基本がどうという話ではないかと。
>* あとはホスト認証の逆を行います。
>問題点: ホスト認証の話と同様、そのような事実はない
これも確認し、修正しました。
通りすがりの基本情報技術者検定の受験者ですが、公開鍵と秘密鍵の違いがよく分かりました。
情報を発信する方にはその発信内容に対する批判をする人がいるのがつきものですが、役に立っていると思っている方もリードオンリーで大勢いますので（私含む）、お気になさらず発信を続けて欲しいと思います。
通りすがりさん、お気遣いありがとうございます！とても励みになります。
初めてのことだったのでどう対処したものか、という感じでしたが、このサイトも認知度が上がってきたのだな、勲章みたいなものだな、と捉えることにしました。
今後もぜひごひいきに！
こんにちは。
「一番身近な具体例 https (SSL/TLS) への応用」の図にてご質問させてください。
①他サイトや参考書では、この図で言うDH鍵交換プロセスにおいては、
CLからSVにpremaster secret(PMS)をSVのRSA公開鍵によって暗号化し、SV側でPMSを複合した後
SV、CLそれぞれでPMSからMS(共通が技)を生成する旨が記載されています。
この図では「DH公開鍵(CL)」がPMSに該当すると理解したのですが、
その場合上記説明と異なり、SVのRSA公開鍵で暗号化されてSVに送られていないのは何故でしょうか。
②SV、CLそれぞれにおいて「DH公開鍵(SV,CL)とDH秘密鍵から、共通鍵を生成」とありますが、
DH秘密鍵とはSV、CLそれぞれのDH秘密鍵のことでしょうか？
そうであれば、SVとCLで同じ共通鍵が作成される仕組みが理解できませんでしたので、
解説いただけると助かります。（おそらく私の理解力が足りていないため）
よろしくお願いいたします。
あああああさん
コメントありがとうございます。
①についてですが、鍵交換プロセスでRSA公開鍵は現在ほぼ使われていません。現在httpsで実装されているのはDH公開鍵です。(TLSバージョン1.3ではRSA方式は廃止になりました。)
「RSA公開鍵による共通鍵生成」は、前方秘匿性が無く、大きなセキュリティリスクを伴うことが認知されたからです。あるサーバの秘密鍵が漏洩した際、過去のhttps通信を「全て」復号出来てしまうのです。(このあたりはスノーデン事件と関わりがあります。)
私もずっと気になってはいるのですが、他サイトや参考書では古い情報がそのまま使われているようですね。
②については、ご認識の通り、SV/CLそれぞれのDH秘密鍵のことです。
このあたりは Diffie-Hellman で検索すれば色々と情報が出てくると思います。私自身が分かり易い説明ができなかったので割愛しているのですが、、そのうち解説記事にしてみたいと思います。
ご返信ありがとうございます。
①本文中にも、鍵交換としてRSAを使用するのは危険な旨しっかり記載されてありましたね。大変失礼いたしました。
ただ、本サイトの別記事「【図解】よく分かるデジタル証明書(SSL証明書)の仕組み…」
中の「デジタル(SSL)証明書とは」箇所のシーケンス図におても、RSAとは書かれていないものの
クライアント側から”共通鍵の元ネタ”をサーバの公開鍵で暗号化しているように見えます。
そもそも、DH方式では、RSA方式とは異なり、クライアントからサーバに”共通鍵の元ネタ”(本記事の図でいう”DH公開鍵(CL)”)を暗号化して送る必要性が無くなった、という解釈でよろしいのでしょうか・・？
②私の方でも調べてみます。解説記事のご検討ありがとうございます！
あああああさん
「デジタル証明書の仕組み」についてですが、図が古い方式の説明になっており、修正しようと思いながらも放置しておりました。。。この機会を頂き、修正しました。。
> そもそも、DH方式では、RSA方式とは異なり、クライアントからサーバに”共通鍵の元ネタ”(本記事の図でいう”DH公開鍵(CL)”)を暗号化して送る必要性が無くなった、という解釈でよろしいのでしょうか・・？
はい。RSAとDHは根本的に方式が違います。DHでは特定条件の互いに異なる公開鍵を送り合うことで、周りに知られずに共通鍵を生成することができます。