この記事では，研究のサーベイをまとめていきたいと思います。ただし，全ての論文が網羅されている訳ではありません。また，分かりやすいように多少意訳した部分もあります。ですので，参考程度におさめていただければ幸いです。
間違えている箇所がございましたらご指摘ください。随時更新予定です。他のサーベイまとめ記事はコチラのページをご覧ください。
本記事の内容
大学で学習した「情報セキュリティ」の内容を網羅的にまとめていくものです。目次は以下の記事をご覧ください。
PKI
前回までの内容は，鍵自体の信頼性は考えずに議論してきました。つまり，太郎君が通信を行うときに，太郎君の公開鍵がホンモノであることは疑っていませんでした。しかし，現実には，鍵がホンモノであることを証明する仕組みが必要になります。
信頼できる第三者を利用して，鍵がホンモノであることを証明する枠組みのことを，PKI（Public Key Infrastructure）と呼びます。PKIは，以下の要素を含みます。
●鍵の信頼を担保する仕組み
●SSL/TLS対応サーバ（ブラウザ）
●暗号化電子メール
●サーバ証明書発行
●失効サーバ
●公開鍵暗号技術
トラストモデル
PKIはどのようにして鍵の信頼を担保するのでしょうか。以下に，２つのモデルを紹介します。
Web of Trustモデル
個人レベルの信頼関係をベースとしたモデルです。日本語訳すると「信頼の輪」となるように，信頼しあうもの同士がお互いに署名しあうことで，信頼の輪を広げていくという考えです。具体例としては，PGP（Pretty Good Privacy）や，その仕様であるOpenPGPが挙げられます。
認証局モデル
信頼できる第三者に，認証局を利用する方法です。公開鍵を，認証局の署名と一緒に（＝証明書）公開することで，鍵がホンモノであることを証明することができます。証明書は，一般に以下のような内容を含みます。
●バージョン
●シリアルナンバー
●アルゴリズム
●署名者（認証局の鍵の保有者）
●鍵の保有者
●有効期限
●公開鍵
●証明書の用途の制約
●失効状況の入手方法
認証局モデルの構成は，以下のようになっています。
●登録局（RA）
●認証局（CA）
●リポジトリ
●証明書所有者（送信者）
●証明書利用者（受信者）
証明書が欲しいユーザ（送信者）は，まず登録局に発行を要求します。すると，登録局ではユーザの実在性を審査・確認します。OKだと判断されれば，登録局は認証局に証明書の発行，または失効の要求をします。認証局では，証明書の発行を行います。失効の場合はその手続きを行い，レポジトリにCRL（Certificate Revocation List）を公開します。
リポジトリでは，CRLを公開するために，HTTPやLDAPなどのプロトコルにしたがって実装します。 証明書所有者は，手に入れた証明書を受信者に送ります。受信者（証明書利用者）は，適宜レポジ取りのCRLと参照しながら，信頼性を検証します。
鋭い指摘ですよね。結局，PKIを利用しても，鍵の信頼性問題は堂々巡りになってしまいます。そこで，認証局の公開鍵はOSやWebブラウザに同梱することで，信頼性を担保しています。他にも，認証局は信頼性を主張するためにも，証明書ポリシー（CP）や認証実施規定（CPS）を公開して，監査法人に定期的にチェックしてもらっています。
また，証明書にも種類があります。例えば，ドメインの有効性を証明したいのであれば，DV証明書が利用されます。具体的には，認証局が指定した乱数をWebサーバの決められたパスに設置することで，信頼性の証明をする例もあります。
他には，OV（Organization Validation）証明書では，ドメインと組織の実在を確認します。具体的には，電話による確認や企業データベースとの照合が行われる例もあります。さらに，ドメインと組織に関して厳格に確認を行う場合は，OV証明書の審査に加えて銀行口座の確認や「責任ある役職によって署名された法的義務を伴う文書」によって確認が行われる。
HTTPS
証明書を利用している身近な例として，HTTPSが挙げられます。ECサイトでは，顧客のクレジットカード等の情報を守るため，その他Webサービスでは利用者のプライバシー保護のために利用されます。
HTTPS通信の流れは，今までの議論で送信者を「SSL/TLSサーバ」，受信者を「Web利用者」とすれば基本的にはOKです。SSL/TLSサーバのWebサイトのFQDN・所有者情報・公開鍵を元に認証局の証明書を発行し，通信を行います。
今までとは少し異なるのは，受信者が「クライアント証明書」を発行する点にあります。クライアント証明書を利用した認証を行うことで，複数のデバイスからのなりすましや改善等の脆弱性に対応することができます。
現実的には，１つの認証局が全ての証明書に署名を施すことは不可能です。ですので，PKIを階層構造にすることで，複数の認証局を利用することが可能になります。その際，一番元になる認証局の証明書を「ルート証明書」と呼びます。ルート証明書を配布することで，認証局自らが信頼を示すことになります。（OSやブラウザに同梱が基本）
最後に，証明書の失効についてです。秘密鍵が漏洩してしまった場合や，証明書に記載していることに変更がある場合は，証明書を失効させる必要があります。証明書の失効には，２つのもでるがあります。１つ目は「CRL（Certificate Revocation List）」，２つ目は「OCSP（Online Certificate Status Protocol）」です。
CRLモデルでは，失効した証明書のシリアル番号を列挙します。一方，OSCPモデルでは，証明書の失効をリアルタイムで確認します。前者はプライバシー侵害の恐れが少なく，サーバへの負荷が軽い一方で，失効した証明書の数が多くなるとリストのデータサイズが大きくなってしまう点が指摘できます。後者は，情報が最新である一方で，プライバシーの問題やサーバの稼動状態に依存するという点が指摘できます。
証明書の利用
SSL/TLSは，セキュリティプロトコルの代表例です。公開鍵による暗号化通信と，PKIによるサーバ・クライアント認証を含んでいます。鍵の交換方法としては，「サーバ証明書の公開鍵で暗号化した乱数から生成する」方法と，「Diffie-Hellmanの鍵交換アルゴリズム」を利用する方法があります。
SSL/TLSは，通信自体は暗号化されています。しかし，接続先のサイトが悪いものである可能性までは除外できません。HTTPS通信を行なって接続したサイトに，マルウェアが忍び込んでいる可能性もあるのです。
最近の話題
最近では，認証局の信頼性を高めるために，様々な取り組みがなされています。
●Certificate Transparency
→第三者によって証明書にログスタンプを付与するアイディア。サーバ証明書を公開ログサーバ上で誰でも閲覧できるため，トラブルの早期発見が見込めます。一方で，公開ログサーバの信頼性を担保するのが難しいです。
●Certificate Pinning
→証明書をブラウザに一定時間記録するアイディア。見知らぬ証明書を受け付けないようにすることができます。
まとめ
情報セキュリティのPKIについてお伝えしました。おそらく，情報系としてはこれくらいの素養は身につけておくべきなのでしょう。一方で，セキュリティ関係の話は，深掘りしていくと泥沼のように複雑な内容が絡んでくるため，まずは広く浅く学び，そのあとに掘り下げるような勉強をしていきたいです。
