プロフェッショナルSSL/TLS

[koheiyamayama]

• 1章
  • どの装置も、転送され る情報を守るために、TLS(Transport Layer Security)と呼ばれるプロトコルを利用している。
  • TLSの目的
  • 暗号学的なセキュリティ
    • 情報を交換しようとする二者の間で安全な通信ができるようにすること
  • 相互運用性
    • 異なるソフトウェア同士でも同じパラメータを用いて暗号通信ができる必要がある。
  • 拡張性
    • TLS は実際に使う暗号プロトコルの開発および運用のための便利なフレームワークとし て設計されている。利用する要素技術(暗号アルゴリズムやハッシュ関数)をプロトコル から独立させて、新たにプロトコルを作り直さなくても新しい要素技術に対応できるようにしている。 要するにTLSプロトコルに指定された通りにどういう暗号を使うのか？をクライアントとサーバ間で合意することで安全に通信を行えるようにしているってこと。更に新しい暗号技術が出てきてもTLSプロトコルは変更なしにその暗号をクライアントとサーバが使えるように設計することで拡張性を保っている。
  • 効率性
    • コストがかかる暗号処理を最小限にし、後続のセッションでの再 計算を避けるキャッシュ方式を用意することで、他の 3 つの目標をすべて妥当なパフォーマ ンスで達成すること。
  • TLSはOSI参照モデルでいうL6に分類される。
  • だいたいのプロトコルはセキュリティを考慮してない。TLSではその点をカバーしている。
  • 暗号技術を適切に運用することで以下の目的を果たせる。
  • 機密性 秘密が守られること
  • 真正性 本人であることの検証ができること
  • 完全性 オリジナルのデータが改竄されることなく転送されること
  • 共通鍵暗号方式
  • 平文をどういう暗号で暗号化するのか、秘密鍵は何なのか？を通信の主体者たちが合意した上で暗号化を行い、暗号文をやり取りする方式。通信の主体者たちは同じ秘密鍵を使って復号化する。攻撃者は秘密鍵を知らなければ理論的には復号化できない。
  • 「暗号システムは、鍵以外のすべてが攻撃者に掌握されたとしても安全でなければならない」という考えがある。これは以下の点を考えると妥当である。
    • 暗号化アルゴリズムは他の複数の相手と共有しなければ使えない。アルゴリズムを共有する相手が増えれば、敵対する相手にアルゴリズムが漏れる可能性も高くなる。要するに暗号化アルゴリズムは複数の人に共有することが前提なので、攻撃者にも暗号化アルゴリズムを把握されうる。それを知られた上でも安全に通信を行うためには鍵を知られないようにする必要があるってこと。
    • 鍵もなしに同じアルゴリズムを大人数で使っていると、みんなが通信を復号できてしまうので、不都合である。要するに上で書いたことと同じ。
    • 優れた暗号アルゴリズムとは「平文に関する情報を解読しようする攻撃者が解読できないようなランダムに見える暗号文を生成するアルゴリズム」のこと。
  • ストリーム暗号化方式
  • 鍵ストリームを生成する。鍵ストリームとは一見するとランダムなデータの無限列のこと。
  • この鍵ストリームの1バイトと平文の1バイトの排他的論理和を取ることで暗号化する。全ての平文が暗号化されるまでこの処理を繰り返すことをストリーム暗号化方式と呼ぶ。
  • この方式では鍵ストリームを攻撃者に知られないことが重要である。そして、知られないためには鍵ストリームを使い回さないことが重要である。 使い回すと、鍵ストリームを攻撃者に知られうるからである。なぜなら、平文の特定の部分を攻撃者が予測しうる場合、鍵ストリームの一部の情報を知ることができてしまうからである。その情報を用いることで一部または全ての暗号化を解読できてしまう。 基本的には通信の主体者が持つ秘密鍵から通信のたびに鍵ストリームを導出して使っている。
  • 具体例 以下の処理を平文が暗号化されるまで繰り返す。
    • 鍵ストリーム 11001100
    • 平文 00001111
    • 暗号文 11001011
  • ブロック暗号化方式
  • データの塊をまとめて暗号化する。ブロックの大きさ(=ブロック長)は現在の多くのブロック暗号化方式では128ビット(16バイト)とされている。
  • 同じ入力を、同じ鍵を使って受け取ると、出力結果が同じになる。
  • 入力の小さな変化が出力の大きな変化になる。
  • ブロック暗号化方式だけでは以下の理由であまり役に立たない。
    • 暗号化するブロック長と同じ長さの平文しか暗号化できない。任意の長さを扱えるような仕組みがなければならない。
    • 同じ入力に対して同じ出力が返ること。この性質を利用した攻撃に対処する必要がある。
  • 上記の問題に対処するために暗号化利用モードと呼ばれる暗号化スキームを利用する。
  • ブロック暗号化方式はハッシュやメッセージ認証コード(MAC)、疑似乱数生成器、さ らにはストリーム暗号化方式にいたるまで、さまざまな暗号技術の基盤としても使われる。
  • AES(Advanced Encryption Standard)という暗号が世界で最も使われるブロック暗号化方式である。
  • パディング
  • ブロック暗号化方式の課題の1つとして、ブロック長よりも短いデータをどう暗号化するのか？というのがある。
  • 16バイトをブロック長とする暗号方式に対して、入力が12バイトしかない場合はパディングという余分なデータを平文が16バイトになるように付け加える。要するにパディングは余分なデータということになる。
  • パディングはどんなデータでもよいわけではない。パディングであることを受け手が 認識し、何バイト破棄すればいいかを正確に把握できるような形式にしなければならない。
  • TLSでは暗号化ブロックの末尾にパディングが何バイトあるのかを格納する必要がある。パディングとして格納する値は末尾に格納されている値と同じにする。こうすることで、パディングが正しいのか受け手が確認できる。
  • 
  • 受け手は、まずデータブロックの末尾のバイトを調べ、その末尾のパディングバイトを取り除く。それから、末尾のパディングバイトに示されていた値と同じ個数のバイトを、各バイトの値がその数と等しいかどうか調べながら削除していく。
  • ハッシュ関数
  • 任意の長さの入力を受け取って固定長の出力へと変換するアルゴリズムのことである。ハッシュ関数が出力した値をハッシュ値と呼ぶ。
  • ハッシュ関数は暗号に用いることができないものもある。暗号に用いることができるハッシュ関数(暗号学的ハッシュ関数)には以下の特徴がある。
    • 現像計算困難性
    • あるハッシュ値からそのハッシュ値になるメッセージを見つけたり構成したりすることが計算論的に困難であること。
    • hash(A)→B
      • Aは平文。Bはハッシュ値。今回の説明文だと、メッセージというのはAのことを指している。要するにB(ハッシュ値)からA(メッセージ)を計算論的に求めることが困難であること。
    • 第二現像計算困難性
    • あるメッセージとそのハッシュ値から、同じハッシュ値になる別のメッセージを見つけることが計算論的に困難であること。
    • hash(A)→Bとhash(C)→B
      • AとBからCを求めるのが計算論的に困難であること。ってこと。
    • 衝突耐性
    • 同じハッシュ値が得られるメッセージを 2 つ見つけることが計算論的に困難であること。
    • hash(A)→Bとhash(C)→B
    • ↑の式が成立するAとCを求めることが計算論的に困難であること。
  • MAC(メッセージ認証コード)
  • ハッシュ関数を使うと通信データの完全性を検証できるが、そのためにはデータそのものとは別にハッシュ値を転送しなければならない。そもそもどうして通信データの完全性を検証できるか？というと、平文をハッシュ値に変換する。これらはhash(平文)→ハッシュ値なので、平文、ハッシュ値どちらかが改竄されると、この式が成立しなくなる。だから、両方を送り、受け取り手がこの式が成立するかどうか確かめることで、通信データの完全性(オリジナルのデータが改竄されてないこと)を確認することができる。注意点としてはデータの完全性を検証することはできるが、保証することはできない。攻撃者が通信途中で巧みに書き換えることは可能であるから。 ハッシュ値とデータを一緒に転送すると、攻撃者に両方をすり替えられる可能性がある。そこで考案されたのが、ハッシュ関数を拡張して認証を可能にした暗号学的な関数である。これをMACあるいは鍵付きハッシュと呼ぶ。で、以下の流れで通信の完全性を保証する。
    • 1. 送り手 MAC(A, Key)→B
    • 2. 送り手 AとBを送信する
    • 3. 受け取り手がAとBを受け取る
    • 4. 受け取り手がMAC(A, Key)→Bであることを検証する
  • 仮に2と3の間で攻撃者がデータ(AとB)を書き換えたとしても、Keyがわからない限りはMAC(A, Key)→Bを求めることはできない。なぜなら、攻撃者はmac(C, key')→Dとしか計算できず、通信の主体者たちと違うkeyを使うことになる。違うキーを使うと、仮にmac(C, key)→Dとなるが、これは成立しない。keyが違うからである。
  • 暗号化利用モード
  • 暗号化利用モードとは、ブロック暗号化方式を拡張して任意の長さのデータを暗号化できるようにした処理のこと。
  • 暗号化利用モードにはいくつかの種類がある。
    • ECBモード
    • ECBは最も単純な暗号化利用モードである。
    • ECBはブロック長の整数倍の長さのデータにしか対応してない。それ以外の長さはのデータは事前にパディングが必要である。で、ハッシュ関数と同じ性質を持つがゆえに、同じ欠点がある。それは以下。
      • 暗号文に一定のパターンができてしまうが、そ のパターンは平文のパターンに対応している
      • 攻撃者にメッセージの繰り返しが見つかってしまう
      • 暗号文を観察できてさまざまな平文の暗号化を試せる攻撃者(Web 通信などで は特別な状況ではない)が何回も試すことで平文を推測できる
    • CBCモード
    • ECBの「同じ入力に対して同じ出力が返る」性質に対処するため、CBDではIV(Initialization Vector)という概念が導入されている。IVのおかげで入力が同じでも毎回の出力を違うものにできる。CBCでは以下の手順でデータを暗号化する。
      • IVを生成する。IVは暗号化ブロック長と同じ。
      • 平文の最初のブロックとIVとの排他的論理和を取る。取った結果のデータが暗号文となる。
      • 次のブロックではその前のブロックで取った暗号文をIVとして使う。
      • 以降はこれを繰り返す。
    • 通信ではIVを送信先に送る必要がある。
  • 公開鍵暗号化方式
  • 共通鍵暗号化方式は便利だが、欠点がある。
    • 同じ集団のメンバーが同じ鍵を共有していなければならない。集団に参加するメンバーが増えるほど、鍵が危殆化しやすくなる。危殆化とは鍵の流出、推測などのことを指す。
    • スケールしない。10人だと45個、1,000人だと499,500個の鍵が必要になる。
  • 公開鍵暗号方式は鍵を2種類使って暗号化を行う。
  • 2種類の鍵を秘密鍵、公開鍵と呼ぶ。
  • 公開鍵Aで暗号化されたデータは秘密鍵A'(公開鍵Aと対になってる鍵のこと)を使わないと復号化できない。
  • 秘密鍵A'を使って暗号化されたデータは公開鍵Aを使えば誰でも復号化できる。この性質はディジタル署名では役に立つ。
  • ディジタル署名
    1. 送り手Aと受け取り手Bがいるとする。
    2. 送り手Aは秘密鍵Aと公開鍵Aを生成する。
    3. 受け取り手Bは公開鍵Aを送り手Aからもらう。
    4. 送り手Aはsha256(document)=>hashed value を行う。
    5. 送り手Aは encode(hashed value + meta data)を行う。この結果をCとする。
    6. 送り手AはRSA(C, 秘密鍵A)を行う。出力される値をdigital signed(電子署名)と呼ぶ。
    7. document + digital signedを受け取り手Bに送信する。
    8. 受け取り手Bはsha256(document)=>hashed valueを行う。
    9. 受け取り手BはCを公開鍵Aを使って復号化する。
       • 秘密鍵で暗号化したデータは対となる公開鍵で復号化できる。
       • 逆に公開鍵で暗号化したデータは秘密鍵で復号化できる。
       • 今回はCは秘密鍵Aで暗号化されているので、対となる公開鍵Aで復号化できる。
    10. 復号化した結果、C = encode(hashed value + meta data)となる。encodeは簡単にdecodeできるので、すぐにhashed value と meta dataを求めることができる。
    11. hで求めたhashed valueとjで求めたhashed valueを比較して等しい場合はデータの真正性を確認できる。
  • 真正性は担保されている。 完全性も担保されている。 なぜなら、hashed valueを比較しているから。もし、documentが改竄されている場合は11の工程で完全性が侵されていることが分かる。 機密性は、、、、担保されない。 なぜなら、documentをhashedせずに送っているから。
  • 乱数生成器
  • 暗号学の観点から言うと、セキュリティのすべては乱数生成器の品質にかかっています。セ キュリティのかなめは既知の暗号アルゴリズムと秘密鍵であると説明してきましたが、その秘 密鍵というのは、要するにとても長い乱数だからです。
  • 予測不能で長いランダムな文字列を生成するのが乱数生成器。
  • プロトコル
  • 通信を安全に行うために「機密性」「完全性」「真正性」を満たすために暗号の要素技術を組み合わせること。また、組み合わせる決まりのこと。このようなプロトコルをセキュリティプロトコルと呼ぶ。
  • 暗号技術に対する攻撃
  • 暗号学的には暗号アルゴリズム→スキーム→プロトコルの順で攻撃対象となりうる。なぜなら、構成が複雑になればなるほど隙きを突きやすくなるからである。
  • さらに攻撃対象になりやすいのはプロトコルを実装しているソフトウェアである。ソフトウェアにある脆弱性を突いて、鍵を手に入れたりしようとする。
  • このような問題は以下の3点を守ることで避けることができる。
    • 確立されたプロトコルを使い、自分でスキームを含め設計しない。
    • 高レベルのライブラリを使い、暗号処理を直接扱うコー ドを自分で書かない。
    • 確立された暗号アルゴリズムを十分な鍵長で使う。
  • 暗号強度
  • 暗号強度を上げるにはとりあえず鍵長が長いものを使え。
  • MITM攻撃
  • トランスポート層に対する攻撃の大半は中間者攻撃。
  • つまり、通信の当事者である二者に加えて、悪意を持った存在が介在する。攻撃者が単に当事者の会話を聞いてる場合は受動的ネットワーク攻撃と呼ぶ。攻撃者が積極的に通信内容を操作したり、何らかの方法で当事者間の会話に影響を与える場合、能動的ネットワーク攻撃と呼ぶ。
  • アクセスの奪取
  • いろいろな攻撃手法が乗っている。いつかローカルネットワーク上でやってみる。
  • 受動的攻撃
  • ネットワーク上を流れるデータを監視/収集したりする攻撃。
  • 暗号化されたデータでも収集しておけば、後年になって暗号アルゴリズムの脆弱性が見つかり、復号化できるかもしれないことから、暗号化されたデータに対しても受動的ネットワーク攻撃は有効である。
  • 能動的な攻撃
  • MIMT攻撃(中間者攻撃)といったら、ほとんどの場合、攻撃者が何かしらの手段で通信を乗っ取る能動的な攻撃を指す。

3日掛かった。19ページ分。

[koheiyamayama]

• 2章

  • TLSとは「上位層の通信プロトコルが何であるかによらず、接続指向のネットワーク通信を安全にするために設計された暗号化プロトコル」である。

  • Recordプロトコル

  • TLSを大まかに捉えるとRecordプロトコルによって実現されている。このプロトコルがコネクション上でやり取りされる低レベルのメッセージの転送を担う。

  • Recordプロトコルは以下の構成になっている。

    • 短いヘッダ
    • コンテントタイプ
    • バージョン
    • レコード長
    • メッセージデータ

  • Recordプロトコルは具体的に以下の役割を持つ。

    • メッセージの転送 別のレイヤーから渡される書式の定まってないデータのバッファを転送する。レコードの長さには制限(16,384バイト)があり、それよりも長いデータはRecordプロトコルによって小さなチャンクへと分割される。その逆に小さなバッファがRecordプロトコルによって単一のレコードにまとめられることもある。
    • 暗号化および完全性の検証 TLSでは、最初の接続における一連のメッセージ群は保護されない。厳密に言うと、TLS_NULL_WITH_NULL_NULLという暗号スイートが使われる。 最初のネゴシエーションを行うためにはこれは仕方ないことである。最初のネゴシエーションを完了した後はネゴシエーションしたパラメータに基づいてレコード層による暗号化および完全性の検証が始まる。
    • 圧縮 TLSの圧縮機能は使われてない。
    • 拡張性 Recordプロトコルが担うのは 「データ転送と暗号処理」 であり、他の機能はすべてサブプロトコルで行う。新しいサブプロトコルは容易に追加できるので、この方針おかげでTLSの拡張が可能になっている。Record プロトコルが暗号処理を担うので、サブプロト コルはすべてネゴシエーションしたパラメータを使って自動的に保護されます。

  • TLSのメインの仕様では以下4つのサブプロトコルが規定されている。

    • Handshakeプロトコル
    • ApplicationDataプロトコル
    • Alertプロトコル
    • Change Cipher Spec プロトコル

  • Handshakeプロトコル

  • Handshakeプロトコルでは、二点間通信の両サイドはTLS接続で使うパラメータのネゴシエーションと認証をHandshakeプロトコルで行う。

  • どのようなやり取りになるのかは設定と対応している拡張の種類によって様々に変わる。実用上は以下を抑えておけば問題ない。

    • サーバ認証を伴うフルハンドシェイク
    • 前回のセッションを再開する場合の一部のメッセージを省略したハンドシェイク
    • クライアントとサーバの認証を伴うハンドシェイク

  • Handshakeプロトコルのメッセージの先頭にはヘッダが付く。このヘッダーでメッセージの種類とメッセージの長さを表現する。あと、メッセージ。具体的には以下の構成になっている。

  • struct {
      HandshakeType msg_type;
      uint24 length;
      HandshakeMessage message;
    } Handshake;

  • フルハンドシェイク

    • TLSの接続はハンドシェイクから始まる。クライアントがそれ以前にサーバとセッションを確立したことがない場合、両者はTLSセッションを確立するためにフルハンドシェイクを実行する。フルハンドシェイクの間にクライアントとサーバが行うことは主に4つある。
    • 1. 接続で使いたいパラメータを双方が提示し、互いに合意する。
    • 2. 提示された証明書か、他の方法を使って認証を行う。
    • 3. セッションの保護に使うマスターシークレットを共有する。
    • 4. ハンドシェイクのメッセージ群が第三者によって書き換えられていないことを検証する。
  • 
    • 1. クライアントが新規のハンドシェイクを開始し、希望する暗号スイート(2.11 節)や鍵 交換の方法(2.3 節)などについてのパラメータ群をサーバに送信する
    • このときに送られるメッセージを ClientHello と呼ぶ。
    • このメッセージは新規のハンドシェイクで常に最初に送信される。
    • このメッセージでクライアントが期待するパラメータ群とその優先度をサーバに伝える。
    • クライアントがこのメッセージを送信する場合は3つある。
      • 新規にコネクションを開始するとき
      • 再ネゴシエーションしたいとき
      • サーバ起源の再ネゴシエーションの要求に応えるとき
    • 2. サーバがパラメータを決定
    • サーバは接続で使うパラメータを選択し、それをクライアントに返答する。
    • その返答に使うメッセージがServerHello。
    • 3. サーバが自身の証明書チェーンを送信する(サーバ認証が必要な場合のみ)
    • Certificateメッセージを使う。
    • 4. マスターシークレット(48バイトの鍵)の生成に必要な情報がある場合、それをサーバからクライアントへ送信する。選択した鍵交換方法によって必要な情報は異なる
    • ServerKeyExchange メッセージを使う。
    • 鍵交換に必要なメタデータを運ぶこと。
    • このメッセージの中身はネゴシエーションする暗号スイートに応じて異なる。
    • 5. ネゴシエーションにおける自分の番が終わったことをサーバからクライアントへ通知する
    • ServerHelloDone メッセージを使う。
    • 予定していたハンドシェイクを全て送信したときにサーバから送る合図。
    • 以降は、サーバはクライアントからメッセージが来るのを待機する。
    • 6. マスターシークレットの生成に必要な情報をクライアントから送信する
    • ClientKeyExchange メッセージを使う。
    • 鍵交換に必要な情報をクライアントから送信するためのメッセージ。
    • 7. クライアント側で暗号通信に切り替え、そのことをサーバに通知する
    • ChangeCipherSpec メッセージを使う。
    • 接続で使うパラメータを組み立てるのに十分な情報をすでに手に入れたこと、暗号鍵を生成したこと、これから暗号処理へ移行することを相手に伝える。このメッセージは、クライアントとサーバの両方が送信する。
    • 8. クライアントから、送信および受信したハンドシェイクメッセージの MAC(改竄検知のためのメッセージ)を送る
    • Finished メッセージを使う。
    • このメッセージはハンドシェイクが完了したという合図である。
    • 9. サーバ側で暗号通信に切り替え、そのことをクライアントに通知する
    • 10. サーバから、送信および受信したハンドシェイクメッセージの MAC を送る

  • クライアント認証

    • クライアントとサーバの相互認証は必須ではないが、サーバはほとんど常に認証が要求される。
    • サーバがクライントの認証を求めるには、許容できるクライアント証明書を一覧にした CertificateRequest メッセージを送る。クライアントはこの要求に対し、自身の Certificate メッセージを送り、対応する秘密鍵を持っていることを CertificateVerify メッセージを使って証明する。
    • 
    • クライアント認証を要求できるのは認証済みのサーバだけである。

  • セッションリザンプション

    • Session IDという一意の識別子を使ってセッションの再開を可能にする仕組み。
    • セッションリザンプションに対応するサーバでは、セッションに対してSessionIDを割り当てる。SessionIDはサーバからクライアントに対し、ServerHelloを使って送る。クライアントとサーバは完全なネゴシエーションによって確立した接続が終了した後もこのSessionIDを一定期間保持する。クライアントは以前のセッションを再開しようとする場合、 ClientHelloメッセージに適切なSessionIDを含めて送信する。サーバは当該のセッションを再開することにした場合、同じSessionIDを ServerHello メッセージに含めて送り返す。そして、以前共有したマスターシークレットを使って新しい暗号鍵(暗号化に使う鍵や MAC 鍵など)を生成し、 暗号通信へと移行してから、 Finished メッセージを送る。クライアントは、セッション が再開されたことを確認したら、サーバと同じことをする。結果的にハンドシェイクが短く なり、ネットワーク上のやり取りが一往復だけで済む。
    • 

  • 鍵交換

  • 鍵交換の目的は プリマスターシークレットという値を生成すること にある。

  • そもそも鍵交換とは「安全ではない通信路を使って2つの参加者が安全に鍵を交換する方法」のことである。参考

  • TLSでは色々な鍵交換アルゴリズムを使うことができる。ネゴシエーションの結果、どのアルゴリズムを使うか決まった後に ServerKeyExchange メッセージをサーバがクライアントに送る。ここではアルゴリズムに必要なメタデータを送信する。アルゴリズムによってはメタデータが必要ない場合がある。

  • 認証

  • TLSでは高コストな処理である暗号処理を何度もしないように、認証と鍵交換が一体となっている。

  • 実際にどうやって一体となっているのかは鍵交換アルゴリズムによって異なる。

  • 暗号化

  • TLSではアプリケーションデータを様々なアルゴリズムで暗号化できる。

  • TLSで使用できる暗号化アルゴリズムは以下の3つに分類できる。

    • ストリーム暗号化方式
    • ブロック暗号化方式
    • AEAD(認証付き暗号)

  • 再ネゴシエーション

  • Application Dataプロトコル

  • アプリケーションのデータを運ぶのがAppliction Dataプロトコルである。ApplicationDataプロトコルはTLSおいては単なるデータのバッファとして機能する。アプリケーションのデータはセキュリティパラメータに従って、Recordプロトコルのレイヤでパッケージ化、細分化、および暗号化される。

  • Alertプロトコル

  • 通信中の相手に例外的な状況を伝える関係な通知の仕組みがAlertプロトコルである。

  • 接続を閉じる

  • 通信の主体者が意図的に接続を切る方法が必要である。なぜなら、強制切断攻撃を防ぐためである。強制切断攻撃をされると、それ以降のデータが送られなくなる。なので、意図的に接続を閉じるための方法がないと、通信が正常に終了したのか、それとも強制切断攻撃を受けたのかが分からない。

  • 暗号処理

  • 疑似乱数生成器

    • TLSでは任意の長さの疑似乱数を生成するためにPRF(疑似乱数生成器)を使う。PRFは引数としてシークレット、シード、一意なラベルを取る。
    • TLS1.2の全ての暗号スイートでは、HMACとSHA256に基づくPRFを使う。

  • マスターシークレット

  • 接続鍵の生成

  • 暗号スイート

  • 拡張

  • 色々な拡張がある。

  • プロトコルの限界

  • TLSで全ての通信が暗号化されるわけではない。

  • プロトコルのバージョン

[koheiyamayama]

3章 公開鍵基盤

3.1 インターネットPKI

• PKIの目的は「お互いに会ったことがない者同士での安全な通信を実現すること」である。
• 現在のPKIは全員が無条件に信頼する証明書の発行をCA(Certificate Authority/認証局)と呼ばれる信頼のおける第三者機関に委ねるモデルになっている。
• 
  • 証明書所有者 証明書を必要とする安全なサービスを希望している主体を証明書所有者(Subscriber/サブスクライバ)と呼びます 。エンドエンティティ(End-Entity)と呼ぶこともあります。Webサービスの世界だと、サービス提供者がこれに当たりそう。
  • RA(登録局) RA の仕事は、証明書の発行に関係したある種のマネジメントです。たとえば、CA が証明書を発行する前に必要になる本人性の検証は RA の仕事になります。CA が末端の利用者に 近い場所(別の国など)に支局を作る場合などは、RA のことをローカル登録局(Local RA) と呼ぶこともあります。実際には CA の多くが RA の役割も果たしています。
  • CA(認証局) 証明書は、証明書所有者(サブスクライバ)の本人性を保証するものです。その証明書を発行するのが、信頼された CA です。CA には、証明書の失効についての最新情報をオンライ ンで提供することで、下記で説明する証明書利用者が証明書の有効性を検証できるようにす る必要もあります。
  • 証明書利用者 証明書を実際に使うのが証明書利用者(relying party)です。厳密に言うと、証明書を検証するのは Web ブラウザなどのプログラムと OS になります。その際にプログラムや OS で はルートトラストストア(root trust store)と呼ばれるものを利用します。ルートトラス トストアには、いくつかの CA から発行された、信頼する証明書(トラストアンカー)が格 納されています。証明書利用者は、インターネット上で証明書に頼って安全に通信する広義 のエンドユーザだといえます。

3.2 証明書の標準

3.3 証明書

• 証明書はディジタル文書であり、その中には公開鍵、公開鍵に紐づけられた主体に関する情 報、それに証明書を発行した主体のディジタル署名が含まれいる。
• この証 明書が PKI の基本的な構成要素となる。
• そもそもディジタル署名とは「デジタル署名を用いると、メッセージの完全性 [20] と作成者の認証 [21] が可能になります。」である。
• バージョン3の証明書はフィールドと拡張で構成されている。

  3.3.1 証明書のフィールド

• Version バージョン1~3がある。バージョンは0~2の数字で表現される。殆どの場合はバージョン3が利用されている。 バージョンごとにできることが違ったりする。
• Serial Number ある CA から発行された証明書を一意に識別するための値。 現在は、連番ではなく、20 ビットのエントロピーを有する 予測不能な値がシリアル番号として要求されています。
• Signature Algorithm 証明書の署名に使われているアルゴリズムを示すフィールドです。その署名によって保護できるように、証明書の内部であるこのフィールドに格納されます。
• Issuer 証明書を発行した主体の識別名(DN:Distinguished Name)が、この Issuer フィールドに格納されます。
• Validity 証明書の Validity は、その証明書が有効な期間です。この有効期間は、開始の日付と終了の日付の 2 つの値で表されます。
• Subject 現在では使われてない。 証明書の発行を受けた者の公開鍵に紐づけられた団体の識別名(DN)が Subject フィールドに格納されます。自己署名証明書の場合は、Subject フィールドと Issuer フィールドが 同一である 今はSAN(Subject Alternative Name)という拡張が使われている。
• Public key 公開鍵を格納するフィールドである。

3.3.2 証明書の拡張

拡張はそれぞれ一意の識別子オブジェクト、拡張子の重要度、それに値で構成される。重要度がcriticalと設定されている拡張は必ず認識され正しく処理されなかればならない。そうならない場合は証明書ごと破棄しなければならない。

• Subject Alternative Name Subject Alternative Name(SAN)拡張は、Subject フィールドに代わって、DNS 名や IP アドレスや URI によって示される複数の主体を公開鍵に結び付けられるようになっている。

• Name Constrains Name Constraints 拡張は、CA が証明書を発行できる主体に制約を課すために使います。 主体を表す名前空間を明示して除外したり、許可したりできるのです。この便利な拡張によ り、たとえば、自分で所有しているドメイン名に対してのみ証明書を発行できる下位の CA を企業などが持てるようになります。

• Basic Constrains よくわからん。 CA 証明書であることを示すため、および、下位 CA の証明書パスの深さを制御するために使う拡張です。証明書パスの深さは、入れ子になった CA 証明書を発行できるかどうかと、 その入れ子の深さを意味し、この拡張の path length constraint フィールド( pathlen ) を使って示します。

• Key Usage 証明書に含まれる鍵の用途を規定します。鍵の用途は限られており、 個々の証明書にはそのいずれかを設定できます。たとえば、CA 証明書であれば Certificate Signer(署名の検証用)および CRL Signer(CRL の署名の検証用)の各ビットを設定するこ とになります。

• Extended Key Usage 公開鍵の用途をさらに柔軟に決定したり制限したりできるように、任意の用途を追加で指定できるようにするのが EKU(Extended Key Usage、鍵拡張用途)拡張です。

• Certificate Policies よくわからない。

• CRL Distribution Points CRL(Certificate Revocation List、証明書失効リスト)の場所を示すのに使われる拡張です。CRL の場所は、通常は LDAP や HTTP の URI で示されます。

• Authority Information Access 証明書を発行している CA が提供する付加的な情報やサービスへのアクセス方法を示すための拡張が AIA(Authority Information Access)です。そのような情報の例としては、 OCSP レスポンダの場所(HTTP スキームの URI)が挙げられます。証明書利用者は OCSP レ スポンダを使って失効情報をリアルタイムに確認できます。

• Subject Key Identifier この拡張には、特定の公開鍵を含む証明書を識別するために利用可能な一意の値が含まれます。識別子は公開鍵そのものから(ハッシュ化などで)導出したものとすることが推奨さ れています。CA 証明書はすべてこの拡張を含んでいなければならず、その値は発行済みの すべての証明書の‌Authority Key Identifier‌拡張に含まれる識別子と同じでなければなりま せん。

• Authority Key Identifier よくわからん

3.4 証明書チェーン

3.5 証明書利用者

3.6 CA

3.7 証明書のライフサイクル

3.8 失効

3.9 弱点

3.10 ルートCA証明書の鍵の危殆化

3.11 エコシステムの観測

3.12 改善

[koheiyamayama]

• 5章
• 8章
• 11章
• 12章
• 16章

[koheiyamayama]

• 証明書に関するRFC https://tools.ietf.org/html/rfc5280
• IPAのPKIに関するドキュメント https://www.ipa.go.jp/security/pki/033.html#_Toc3020769

[koheiyamayama]

• 11章
• 12章
• 16章