i have no idea

I have no idea

bibouroku

やる気の出ない情報セキュリティ6 「PKI(公開鍵暗号基盤)」

PKI

会社で情報セキュリティをやることになったので、勉強がてらメモ
文献は「マスタリングTCP/IP 情報セキュリティ編」

PKIの基礎

PKI(Public Key Infrastructure)とは、「公開鍵暗号基盤」と呼ばれます。
PKI公開鍵暗号化方式やディジタル署名といった技術を組み合わせて利用する複合技術のフレームワークです。
インターネットなどのネットワークにおいて公開鍵の配布をするうえで有効な手段となります。実装例にはHTTPS等があります。

  • PKIが必要となる理由
    インターネットを使って、Webページにアクセスするようにするためには、公開鍵を配布する必要があります。
    しかし、実際の運用では公開鍵を安全な方法で配布することが必要となってきます。
    電子メールなどに添付して公開鍵を送る手法では、間で攻撃者によって情報が盗まれた場合に問題となってきます。なので、公開鍵のすりかえなどを防止するためにもPKIが必要となってきます。

トラストモデル

誰かが本物であるかを確認する仕組みには、様々な様式があります。そのような信頼のための様式をトラストモデルと呼びます。
インターネットなどの公開鍵を配布する際に、公開鍵の所有者を確認する仕組み、には以下の2つのトラストモデルがあります

Web of Trust モデルは、公開鍵の所有者を、自身が信頼できる人物に保証してもらう仕組みです。
RFC 4880によって策定されているOpenPGPという規格に準拠したソフトウェアで採用されています。
Web of Trustモデルは、個人レベルでの信頼関係がベースとなり、全体を集中して管理する主体が存在しないので、企業などの組織での運用に適用することは難しい場合もあります。
ですが、全体を集中して管理する主体が存在しないことは、利点として考えられることもできます。

f:id:yabicon:20210511222306p:plain
Web of trust モデルの例

認証局モデルでは、Web of Trust モデルとは違い、全体を集中して管理する主体を用意します。
信頼できる第三者機関(TTP)に、公開鍵の所有者を保証してもらう仕組みです。
TTPは、公開鍵の所有者の本人性を確認し、公開鍵とその所有者を証明する情報を持つ証明書(公開鍵証明書)を発行します。改竄を防ぐためにTTPの署名も施されます

f:id:yabicon:20210511222345p:plain
認証局モデルの例

公開鍵証明書

証明書には、公開鍵とその所有者を証明する公開鍵証明書(public key certificate)や、公開鍵証明書で証明された人に対して所有する権限や役割を証明する属性証明書(attribute certificate)があります
一般的にPKIでの証明書は公開鍵証明書のことを言います。


公開鍵証明書の標準フォーマットとして、ITU-Tが策定したX.509証明書があります。
証明書は、主に以下によって構成されます。

  • 署名前証明書(tbsCertificate)
  • 署名アルゴリズム(signatureAlgorithm)
  • 署名値(signatureValue)

証明書の所有者、公開鍵の有効期間等の情報は、「署名前証明書」に記載され、署名前証明書に対する署名が、「署名アルゴリズム」によって施され、その値が「署名値」となります。
署名前証明書にはそのほかにも拡張領域があって、鍵の利用目的やポリシー等を含めることができます。

Youtubeとかでは、こんな証明書がみれますね... !

f:id:yabicon:20210511214335p:plain
youtubeの証明書

認証局

PKI認証局モデルでは、TTPである認証局によって発行された証明書を用いて、公開鍵の安全な配布を実現しています。

PKIを構成する主体には、以下のものがあります

  • 認証局(CA Certification Authority)
    認証局は、証明書利用者や証明書所有者に対して、公開鍵とそれに対応する秘密鍵の所有者を対応付ける証明書を発行します。また、発行した証明書の信頼性が失われた場合、その証明書を 失効させ、執行情報を載せたCRL(証明書失効リスト)を発行します。
    さらに、証明書と証明書失効リストを、証明書利用者が取得できるように後述のリポジトリに公開します。

  • 登録局(RA Registration Authority)
    主として登録業務を行う機関で、証明書所有者から証明書の申請がなされたとき、申請者の本人性の審査・確認を行います。
    認証局に対して証明書の発行や執行を要求します。

  • リポジトリ
    証明書及び証明書失効リストを格納し、証明書所有者や証明書利用者へ公開します。

  • 証明書所有者
    証明書が発行される主体を指します。証明書では、主体者(subject)や加入者(subscriber)と呼ばれます。
    証明書及び対応する秘密鍵を用いて、暗号文の複合や電子文書への署名を行います。

  • 証明書利用者
    証明書所有者の証明書を入手し、それを利用してデータの暗号化や署名の検証を行う主体です。

f:id:yabicon:20210511222418p:plain
認証局モデルの例2

認証局は、運営形態により2種類に分類できます。

  • パブリック認証局
    公的な位置づけという意味です。パブリック認証局が発行する証明書の一部は、一般的なOSやWebブラウザにあらかじめ同梱されているケースがあり、その場合は証明書の配布やインストールが不要です
    パブリック認証局は、その運営ポリシーを、証明書ポリシー(CP Certificate Policy)または、認証業務実施規定(CPS : Certification Practice Statement)として公表しています。
    認証局がどのような目的であるのか、証明書失効リストの更新頻度、設備の安全性に関することも記載されます。
    パブリック認証局を運営する会社は、COMODO社、GlobalSign社、VeriSign社など多数あります。

  • プライベート認証局
    企業や組織内で独自の運用基準を設けて設立し運営する認証局です。
    証明書の配布や設定などに手間がかかりますが、運用規定を組織の中で自由に設定できるため、限られたネットワークの半家で証明書を利用する場合は、プライベート認証局を設立し電子証明書を発行するほうが便利であることもあります。


登録局における厳格な認証プロセスを経て発酵されるEV SSL証明書というものもあります。
EV SSL証明書を発行する認証局は、認証プロセスなどがガイドラインに従って正しく運営されているか、1年ごとに外部監査を受けます。

EV SSLでは、会社名がアドレスに表示されます。

f:id:yabicon:20210511220046p:plain
こんな感じ EV SSL

証明書の利用

HTTPSにおける証明書の利用例
HTTPS通信において、認証局が発行する証明書は、その利用形態によって以下の3種類に分類できます

サーバ証明書はサーバを識別するための証明書で、SSL/TLSサーバーが証明書のSubject(証明書所有者)となります。なのでSSLサーバ証明書とも呼ばれます
サーバー証明書には、Webサイトの所有者の情報、SSL/TLS通信における暗号化に必要な公開鍵などの情報を含み、認証局によって署名されます。
HTTPS通信におけるサーバ証明書の主な目的は、証明書に示されたWebサイトのFQDNが含まれる公開鍵の所有者であることを証明することです。
サーバ証明書とその秘密鍵は、Webサーバの稼働するOS上で管理されます

クライアント証明書はクライアントを識別するための証明書で、クライアント(Webブラウザ、ユーザ、端末等)がSubject(証明書所有者)となります。
HTTPSで利用するケースでは、SSLサーバがクライアントを認証するときに使います。
クライアント証明書とその秘密鍵Webブラウザなどにインストールして利用することが多いです。

ルート証明書は、各種証明書を発行する認証局が、発行する証明書の署名の正当性を示すために自ら署名して発行する証明書のことです。
認証局が自らの秘密鍵で署名することから、自己署名証明書とも呼びます。
ルート証明書は、SSL/TLSサーバ及びWebブラウザ、もしくはそれらのOSにインストールします。
ルート証明書の正当性により認証局が信頼の起点となり、それにより、サーバー証明書およびクライアント証明書の真正性を検証できます。

f:id:yabicon:20210511222510p:plain
HTTPSの例


PKIの運用

証明書の運用という観点からPKIを見ると、「証明書の発行」「利用の際の検証」そして「失効の確認」という一連の流れであるといえます

  • 証明書の発行
    証明書を必要とする主体は、公開鍵暗号化方式における公開鍵ペアを作成します。
    次にCSR (Certificate Signing Request)を作成し、それを証明書発行機関に提出します。その際登録局で本人性を確認します CSRには署名前証明書の情報が含まれます。
    登録局は、提出されたCSRとともに本人性の確認後、認証局CSRを提出します。認証局は、認証局の署名をして、証明書を作成します。
    発行された証明書は、証明書所有者に私、認証局を通して配布されます。

    f:id:yabicon:20210511222535p:plain
    証明書の発行の流れ

  • 証明書の検証
    証明書があっても、公開鍵が真正か確かめなければ、中間者攻撃によって証明書をすり替えられる可能性があります。ので、検証が必要となります。
    証明書を信頼できる認証局が発行したものであるということを、認証局が発行したルート証明書を検証して、確かめることができます。

  • 証明書の失効
    証明書は有効期間内であっても、以下のような事象があったときに証明書を破棄する必要が生じます

    • 証明書に含まれる公開鍵に対応する秘密鍵が紛失もしくは漏洩した場合
    • 証明書に記載した事項が変化したなどの場合

    証明書が失効したことを知らしめる手段には、「CRLモデル」「OCSPモデル」の2つの方式があります。

    CRLモデル
    認証局が失効された証明書のリストを定期的に公開する方式です。このリストのことを証明書失効リスト(CRL : Certificate Revocation List)と呼びます。
    証明書失効リストには、失効した証明書のシリアル番号、発行日時などを掲載し、署名を施します。
    CRLモデルはややリアルタイム性に欠ける仕組みでありますが、非常にシンプルで使いやすい手法となります。

    OCSPモデル
    OCSP(Online Certificate Status Protocol)モデルは、証明書の正当性をリアルタイムで確認するプロトコルのことです。
    証明書の失効情報を保持したサーバ(OCSPサーバ)が。証明書利用者からの証明書の失効情報の問い合わせに対して、指定された証明書について応答を署名付きで返すというものです。