Zenn
Closed7

情報処理安全確保支援士勉強

hirohiro

今日はいつもお世話になっているつべ動画で進めます。シリーズになってるのでPKIから開始。
https://youtu.be/2hiMWRou_is

PKI(Public Key Infrastructure)

公開鍵の信頼性を保証する仕組みそのものを指す。デジタル署名に添付された公開鍵を検証するときに使う
デジタル署名作成者（秘密鍵保持者）が事前に準備しておく必要がある

PKIの構成要素
CA（Cirtification Authority:認証局）が公開鍵が本物であること保証

  1. デジタル署名作成者がCAに公開鍵証明の作成を依頼（公開鍵と自身の情報を申請）
  2. CAが公開鍵証明書(cert : X.509フォーマット)を作成
  3. CAが公開鍵証明を認証局の秘密鍵で暗号化し作成者に返却

＊認証局の公開鍵で公開鍵証明を検証することが可能 つまりそこに含まれる公開鍵情報を信頼できるということ

X.509

  • バージョン
  • シリアル番号
  • 署名アルゴリズム
  • 認証局名
  • 有効期間
  • 所有者
  • 所有者の公開鍵情報
hirohiro

CA(Certification Authority)認証局 ： 公的第三者機関として証明

公開鍵証明書の種類

  1. サーバー証明書
  2. クライアント証明書
  3. ルート証明書

サーバ証明書(zennのをみてみた)ブラウザに表示されるURLの鍵マークをクリックすれば閲覧可能

  • 暗号通信 HTTPS(SSL/TLS) をするのに使う
  • サーバーのなしすまし確認

ブラウザはこの証明書の内容(CN:Common Name)と接続先のドメイン名からなりすましを検出する。

サーバ証明書の作成

  1. CSR(Cirtificate Sigining Request)の生成、申請者（サーバ）の情報と公開鍵
  2. CSRを元にサーバ証明書を作成

CSR

  • Common Name : FQDNで作成すること
  • Organization
  • Organization Unit
  • Locality
  • State or Province
  • Country

CNは基本的にFQDNを使うが、ワイルドカード証明書でホスト部を*でまとめて複数のサーバーを扱うことができる

サーバ証明書の種類

  • DV証明書 ドメイン認証型 ： CNのみで申請可能。信用低、HTTPSが利用可能、一時的なサイトなど向け。フィッシングサイトの可能性あり、無料〜低価格。
  • OV証明書 組織認証型、企業認証型： ↑＋証明書の保有者の実在性を保証、登記簿謄本などを使用。ワイルドカード使用可能。
  • EV証明書 EV認証型 ： ↑＋業務実態を保証する、銀行等。

OVとEVは見た目上違いが分かりにくいがブラウザで表示方法を変えている場合がある。
DV証明書は比較的新しい仕組み、悪意のあるサイトであってもDV証明書を取得できるので、HTTPSをしていれば安全ということにはならない。

hirohiro

サーバ証明書の正当性検証

  1. クライアント側Webブラウザがサーバにアクセス
  2. サーバがサーバ証明書を返却
  3. ブラウザ側でサーバ証明書が改ざんなどされていないか確認する ←ここが大事
  4. サーバー証明書の署名をCAの公開鍵で復号、サーバー証明書のハッシュ値を作成して比較する。
  5. サーバー証明書の有効期限を確認する。
  6. サーバー証明書が失効していないか確認する：サーバの秘密鍵が漏洩など危殆化（セキュリティの低下）した場合などは有効期限内のサーバ証明書も失効される。

サーバ証明書も公開鍵証明書と同様に、CAの署名がつくため、CAの公開鍵で正当性を確認することができる。
CSRを元に作ったサーバ証明書のハッシュ値をCAの秘密鍵で暗号化したものをサーバ証明書の署名とする。

サーバ証明書の失効
確認方法が２つ

  1. CRL (Certificate Revocation List) 証明書失効リスト PKIにおける失効シリアル番号のリスト、サーバ証明書内に記載がある。

    クリックするとcrlファイルがダウンロードされる、がこのままテキストとしてみることができない。
    https://letticiablog.wordpress.com/2015/10/25/crlの中身ってどうやってみるの？/

このような感じで復号しないといけないわけですね、とんでもない行数でターミナル埋まった。

openssl crl -inform der -in ~/Downloads/bT8Xij6eRHU.crl -text


おそらく一行が失効したシリアル番号か、ここでも X509 が出てきている。

  1. OCSP (Online Certificate Status Protocol) オンラインで証明書失効状態を確認する
    　公開しているサーバ（OCSPレスポンダ）にアクセスし失効情報を確認する。
    　インターネットが使えることが前提条件
hirohiro

OCSPステープリング
サーバ証明書の検証をスムーズにするために サーバ証明書 OCSP応答 をステープリングする

OCSPレスポンダの通信状況によっては、OCSPの応答が得られずサーバ証明書の検証が完了しないために
Webサイトに接続が完了しない（時間がかかる）場合がある問題の対応策がOCSPステープリング。

Webサーバ側が事前にOCSPレスポンダからの応答を取得し、サーバ証明書と一緒にOCSP応答結果をクライアントに返す。クライアント側はOCSPに問い合わせする必要がない。この場合OCSP応答結果に認証曲署名が付与されているので、改竄、捏造対策してある必要がある。

hirohiro

認証局 CA (Certification Authority) の種類

  • パブリック認証局：インターネット公開、発行手数料がかかる
  • プライベート認証局 ：特定組織内で利用（社会的信用は低い）する証明書を発行するために設置されることがある
  • 政府系認証局 ：行政システムで使用

CAの役割分担

  • RA（登録局）：CSRを受け取り、審査、申請者にCSRを交付、IAに対して発行要求
  • IA（発行局）：公開鍵証明に認証局の署名をつけてRAに返却、発行した公開鍵情報リポジトリの管理（CRLなど）
hirohiro

認証局の階層

最上位の認証局：ルート認証局、自身に対して電子証明書（ルート証明書）を発行する＝自己署名
ルート下位の認証局：中間認証局
上位認証局が下位認証局を証明する構造

階層によりルート認証局が全ての認証局を保証する形になっているので、ルート認証局の公開鍵を持っていればサーバ証明書の署名にある認証局そのものの公開鍵がなくても、中間認証局の公開鍵証明書辿ることで検証可能な状態となる。：最終的にルート認証局の公開鍵さえあれば参加の認証局全てを検証できたことになる。（認証パス path）

つまりクライアントは、接続先サーバが返却したサーバ証明書の認証局の公開鍵証明書（中間認証局の証明書）を辿ったルート認証局の公開鍵を入手すれば、接続先サーバの署名を検証可能となる。

OSやブラウザのベンダーが世界中のルート証明書をあらかじめ組み込んでいる。
ルート認証局とベンダーの信頼で成り立っている仕組みといえる。
基本的にルート証明書をユーザーがインストールする必要がない
悪意のあるルート証明書をインストールすると配下の全ての認証局を信用することとなるため危険。

hirohiro

CT(Certificate Transparecy) 証明書の透過性
サイト運営者が偽の公開鍵を発行されていないか調べる手段

2011世界中の認証局で発生、認証局の秘密鍵が漏洩し勝手に偽の証明書が発行されていたため、対応策として導入された仕組み

CSRに対して、CAが発行した公開鍵証明書（サーバ証明書）にSCT情報を付与する(Singned Certificate Timestamp)
→サーバ証明書(SCTなし）の場合ブラウザが信憑性が低いとして警告する

CTログサーバ：CAが発行した公開鍵証明書情報を公開、サーバ証明書を受け取ったクライアント側がSCTにより定期的にCTログサーバに接続して参照。
偽の公開鍵証明書を調べるための仕組み。


複数のSCT情報が付与されている様子。

このスクラップは2022/12/11にクローズされました