情報セキュリティでは、あらゆるシーンでディジタル証明書(電子証明書)が利用されます。
デジタル証明書の利用シーン、種類、仕組みを説明します。
ディジタル証明書の用途・利用シーン
インターネットでは、アクセスしたウエブサイトが本物のページか(偽のページではないか)を確認することが難しいです。理由は本物そっくりのページを作ることは簡単にできるからです。
偽のウェブサイトだと思ってアクセスし、IDやパスワードを入力すると、その情報を盗まれるてしまいます。
これを防ぐために、ディジタル証明書が使われます。
ネット上を流れるデータが盗聴されないよう、一般的にデータを暗号化しますが、その際に公開鍵という公開されている鍵を使用する方式がありますが、その際に公開鍵が本物なのかを証明する際にもディジタル証明書が使用されます。
ディジタル証明書の種類
ディジタル証明書はいくつか用途があり、それによって種類もいくつかあります。
サーバ証明書
WEBサイトのサーバが本物かどうかを証明するための証明書です。
サーバ証明書は、サーバがが正規の運営者によって管理されているものであることを証明すること以外にも、安全な通信（HTTPS）を実現するために使われます。
SSL通信やTLS通信を行うWebサイトの場合、SSLサーバー証明書と呼ぶこともあります。
クライアント証明書
クライアント証明書は、クライアント(アクセスしてきた人が本人であることを証明するための証明書です。
主な用途としては、社内システムへアクセスやインターネットバンキングへアクセスする際に本人であることを証明する際に使用します。
一般的にクライアント証明書を予めPCやスマホなどの端末にインストールして使います。
コードサイニング証明書
コードサイニング証明書は、公開されているソフトウェアに対して、信頼できる開発者（または企業）が作成し、改ざんされていないことを証明する際に使用します。
認証局(CA)
サーバやクライアントなどが本物であることを証明するための証明書ですが、この証明書に書かれていることが信頼できるものだと確認するために大事なのが認証局(CA)です。
認証局は、ディジタル証明書の発行元であり、信頼できるものであり、有効であることを証明してくれる第三者機関です。
CA(認証局)は階層構造
- 発行元のCA(認証局)が信頼できる機関であることを確認するために、発行元のCA(認証局)にあるディジタル証明書を使います。この発行元CA(認証局)のディジタル証明書は、別のCA(認証局)というとこをから発行されています。
- CA(認証局)は複数台で構成されることもあります。
これらは中間CA(認証局)と呼んでいます。 - 最終的にルートCA(認証局)が中間CA(認証局)の証明書の正当性を証明します。ルートCA(認証局)のルート証明書は予めクライアントのPCへインストールしておきます。
ルート証明書は一般的にブラウザにインストールされていますので、古いブラウザだと正しいルート証明書の正当性を確認できない場合があります。
証明書の正当性確認方法はこの後で説明します。
CPS：CAの運用基準を明示
CPS(「Certification Practice Statement)は、CAが発行するディジタル証明発行業務をどのようなルールで行うかを明示した文書です。
認証局が遵守する具体的な手続き、セキュリティ対策、責任範囲などを明文化したものです。
ディジタル証明書の発行
デジタル証明書は認証局（CA）から発行されます。
サーバ証明書を発行する場合の流れを説明します。
- サーバがCSR（証明書署名要求）を作り、認証局へ提出
- CSRをもとにサーバの識別子などの情報を取得し、これにCAの識別子などを加えた値をハッシュ化してハッシュ値を生成
- ハッシュ値を認証局の秘密鍵で暗号化してディジタル署名を生成し、サーバ証明書を発行
- サーバが証明書受け取り、インストール
ディジタル証明書 利用の流れ(正当性確認の流れ)
ディジタル証明書を使った正当性確認はどのようにするのか、サーバの場合とデータの場合を使った例で説明をします。
サーバ証明書の正当性確認の流れ
①クライアントはサーバ証明書をダウンロードする。
②サーバ証明書内のディジタル署名を、発行元CA(認証局)の公開鍵で復号化する。
※CAの公開鍵の正当性確認もするがここでは省略
これについては「CA(認証局)の公開鍵の正当性確認」章を参照
③サーバ情報(サーバ識別子(ドメイン名)など)からハッシュ値を生成
④２つのハッシュ値を比較し一致すれば正当な証明書である
※実際のサーバ証明書は、公開鍵が含まれており、これを使ってクライアントとサーバ間のデータの暗号化を行いますが、ここではサーバの正当性確認の流れのみを説明しています。
データの正当性確認の流れ
インターネット経由で誰かにデータを送る場合、受信者はディジタル証明書を使ってデータが改ざんされていないことと、本人が作成したデータであることを確認できます。
＜流れ＞
- 送信者がハッシュ関数を使って、送ろうとしているメッセージからメッセージダイジェストを生成
- 生成したメッセージダイジェストを、送信者の秘密鍵で暗号化してこれをディジタル署名とする
- 送信者がメッセージ、ディジタル署名、Aさんの電子証明書を受信者へ送る
- 受信者は、送信者の電子証明書がCA(認証局)から発行されたものであることを確認
- 受信者が、受信したメッセージをハッシュ化した結果と、ディジタル署名を送信者の公開鍵(電子証明書内にある)で復号した結果を比較して一致すれば、データが改ざんされておらず、本人が作成したデータである
CA(認証局)が発行した公開鍵の正当性確認
サーバなどの電子証明書の正当性確認は、CA(認証局)の公開鍵を使いますが、これも正当性確認をします。
まずはサーバ証明書などの発行元の公開鍵証明書を取得します。
発行元CAの公開鍵証明書の正当性を確認するため、発行元である中間CAの公開鍵証明書を取得してその中の公開鍵でディジタル署名を復号化して正当性を検討します。
最終的にルートCAが発行した証明書の正当性を確認することで、今まで確認してきた各証明書の正当性が信頼できるものだという判断になります。
もし、CAが攻撃されて不正なディジタル証明書が発行されてしまった場合、クライアント側の対処方法は対象のルート証明書を信頼できないものに変更しておくことです。
ディジタル証明書が失効していないか確認するCRL
CRL(Certificate Revocation List)とは有効期限よりも前に失効させたディジタル証明書の一覧です。
CRL には，有効期限内のデジタル証明書のうち失効したデジタル証明書のシリアル番号と失効した日時の対応が提示されています。
Web ブラウザからWeb サイトへ接続した際、証明書を受け取った Web ブラウザは証明書の「CRL 配布ポイント(CRL Distribution PointCRL)」という項目で指定されたURL へ自動でアクセスして、CRL をダウンロードします。
Web ブラウザは取得した CRL に登録されているすべてのシリアル番号とWeb サーバから送られてきた証明書のシリアル番号を照合して、一致した場合に Web ブラウザが「証明書が失効されている」と判別してセキュリティ警告やエラーメッセージを表示します。
まとめ
- ディジタル証明書はインターネット上で個人や組織の身元を証明するもの。
- ディジタル証明書は信頼できる第三者機関である「認証局（CA）」が発行し、ディジタル証明書の正当性はCAが保証する
- ディジタル証明書は公開鍵と識別情報（氏名、組織名など）などで、ディジタル署名を生成してディジタル証明書内に埋め込む
- CAは階層構造になっており、ルートCAのディジタル証明書はクラアント(ブラウザなど)にインストールされている。
コメント