この文書では 公開鍵インフラ (Public Key Infrastructure: PKI) の仕組みについて解説します。
Secure Sockets Layerの概要
SSL(Secure Sockets Layer)は、Netscape社によって提唱された暗号化プロトコルで、ある。セキュリティ付きソケット層とも呼ばれる。クライアント・サーバー相互間の認証を行い、クライアント・サーバー間で認証され暗号化された接続の確立を可能にする。 TCP/IP上で、かつHTTP、LDAP、IMAP、NNTP、その他上位のネットワークプロトコルの下で動く。
このプロトコルを使い、Netscape Navigator等のWWWブラウザでは"http"の暗号化通信を実現している。なお、Navigatorで暗号通信を行う場合は"http://"の表記ではなく"https://"の表記によってプロトコル指定を行う。
SSLの機能は、暗号通信、認証通信、データ完全性の機能の3つに分けられる。認証は、RSAなどの公開鍵方式で行い、通信データの暗号化は共有鍵方式で行われる。データの完全性は、データのダイジェスト(フィンガープリント)を取る事で得られるMAC(Massage Authentication Codes)と呼ばれる数値でチェックする事で選られる。
以下に暗号化通信の確立までの、サーバとクライアント間のSSLシーケンスを示す。
- クライアント (SSLをサポートしたブラウザ) は、いくつかのポート (HTTPS のデフォルト ポートは 443) のサーバで TCP 接続を開放する。
- サーバが TCP 接続を受け入れる。
- クライアントが、SSL との通信を希望する内容のメッセージを送信する。
- サーバが証明書 (CAにより署名されたサーバ公開鍵および情報) を含めて 、SSL との通信を受け入れる内容の返事を送信する。
- クライアントが証明機関の公開鍵を使って、サーバの証明書の証明機関ディジタル署名を確認する。
- サーバの証明書が有効であれば、クライアントは「マスターキー」をランダムで作成し、サーバの公開鍵(サーバの証明書から) を使ってマスターキーを暗号化して、サーバに送り返す。
- サーバはプライベート キーを使って受け取ったマスターキーを解読し、クライアントにメッセージを送ってハンドシェイクを完了する。
- この時点でクライアントとサーバは同じマスターキーを共有しており、それを使って転送されるデータの暗号化に使用する 1 組のセッション キーを作成する。
SSL はOSI参照モデルでのセッション層で機能するように作られている。プロセス間通信などで使われるSocketに対し暗号通信、認証通信、データ完全性の機能を追加したものである。そのため、"http"の他に"ftp"や"telnet"など、ポートを新たに割り付ければ、どのアプリケーションでも透過的に暗号通信、認証通信等を利用する事ができる。
SSL内でのプロトコルの区分としては
- Socketを管理しトランスポート層の真上に置かれるSSL Record Protocol
- その上でサービスを受けるSSLの各種プロトコル (SSL Handshake Protocol, Alert Protocol, Change Cipher Spec Protocol, Application Data Protocol)
の2種類に大別する事ができる。
これらのプロトコルを利用する上で、SSLではセッションとコネクションという2種類の接続状態を持っている。セッションでは、通信に用いるデータ圧縮や暗号のアルゴリズムの種類などを保持し、その上で複数のコネクションを利用する事が可能になる。コネクションは、暗号化や復号化の鍵など、実際の通信で使用するデータを保持している。
CA
証明機関 (Certificate Authority:CA) とは、暗号化通信などで使用する証明書を発行する機関です。デジタル証明書の発行、更新、一時停止、取消、管理を行います。認証局ともいいます。
Public CA
第三者認証局。世界中で絶対的に信頼されるデジタル証明書というのはありませんが、一般的に信頼度の高い認証局ならば多数存在します。会社概要、業務形態、証明書の発行ポリシー等を公開し、証明書発行のシステムに不正侵入されない強固なシステムを持ち、火災等の災害時の対策、物理的な建物への侵入対策まで入念に設計された 第三者認証機関と呼ばれるのがそれです。日本国内では、日本ベリサイン社 やサイバートラスト・ジャパン社が代表的です。 それら信頼できる認証局の公開鍵は Netscape Communicator やInternet Exproler といったSSL対応ブラウザ、S/MIME 対応メーラーにはあらかじめ組み込まれており、送られてきたデジタル証明書の確認 (認証局の公開鍵を利用)がスムーズに行われるようになっています。
Private CA
プライベート認証局。Public CAでは年間の契約料金が発生することや、証明書を持つ世界中の不特定多数のインターネットユーザがアクセスできては逆に不都合が発生する運用ポリシーを持つ場合もある為、企業で独自の認証局を立てる必要が出てきます。これを、プライベート認証局といいます。 プライベート認証局から発行されたデジタル証明書はそのままでは利用することができません。何故ならばブラウザの中にこの認証局の証明書(公開鍵)が入っていない為です。
サーバ認証
サーバ認証の処理の流れを以下に示す。
- クライアントがサーバにSSLを利用した接続要求を送る。
- サーバがサーバの証明書をクライアントに送る。
- サーバの証明書の認証を行う。
サーバーとクライアント認証は、SSL接続にとって必須のものではなく、暗号化された情報を引き続き交換できるが、暗号化情報を正しい当事者に送っていることを両当事者に確約する。また、クライアントとサーバーは認証なしでも通信できるが、サーバーがアクセス制御に対するクライアント認証を要求すると、クライアントが有効な証明書を持たない場合、そのクライアントは拒否される。
クライアント認証
クライアント認証は、以下のステップを通じて達成される。
- クライアントがSSL対応サーバーとの接続を要求する。
- サーバーが(前のステップを通じて)認証されるか、または拒否される。
- クライアントは署名するが、証明書の暗号化はせずにサーバーに送る。
- サーバーは、クライアントの公開鍵を使う。公開鍵は証明書の所有者が署名した人と同一人であることを確認するための証明ファイルに入っている。
- サーバーは、証明書のCAがすでに信頼しているCAであるかどうかを確認する。間違いなければ、サーバーは次のステップに進み、間違っていれば、サーバーはクライアントを認証しない。
- サーバーは、証明書の情報をクライアントに関して受け取ったばかりの情報と比較するす。すべての情報が符合すれば、サーバーはクライアントを認証されたものとして受け付ける。
クライアント認証を行う為には、予め証明書を取得しておかなければならない。証明書取得の流れを次に示す。
- ユーザは鍵ペア(公開鍵と秘密鍵)を生成する。
- ユーザは証明書要求を作成する。
- 証明書要求をCAに送る。
- CA管理者はユーザ証明書を生成し、CAの秘密鍵でユーザ証明書にディジタル署名を行う。
- ユーザ証明書をユーザに送る。
証明書リポジトリ
証明書は証明書リポジトリに格納され、各種アプリケーションから利用することができる。「リポジトリ」とは証明書の配布を可能にするネットワークサービスのことである。
ここ数年間でリポジトリの技術として最もすぐれているのはLDAP に対応したX.500ディレクトリシステムである。
ITU-T (International Telecommunications Union - Telecommunication Standardization Sector: 国際通信連合-通信標準化部門) 勧告のX.500では,ディレクトリの利用者であるDUA(Directory User Agent)とディレクトリサービスを提供するDSA(Directory System Agent)とのあいだで情報を交換するための通信プロトコルとして,DAP(Directory Access Protocol)が規定されている。しかし,DAPはインターネットで利用するにはオーバーヘッドが大きすぎることから,IETFがX.500に準拠してインターネット上で利用できるように軽い通信プロトコルを策定した。これが,RFC1777で提唱されているLDAP(Lightweight Directory Access Protocol)である。LDAPは,TCP/IP経由でディレクトリ管理システムにアクセスするときに使用され,DAPの提供する機能のほとんどを低コストで実現できるように開発されている。
X.500とは、ITU-Tが策定した、ディレクトリサービスに関する国際勧告である。ディレクトリの概念やその階層構造、サービスやオブジェクトの定義などが含まれる。OSIプロトコルで通信する場合には,ネットワーク・アドレスなど通信相手のさまざまな属性をあらかじめ知る必要がある。ディレクトリ・システムは相手の名前からこの属性を検索することができる。このシステムはDUA,DSA, DIB (directory information base)で構成する。ユーザーがDUA経由で属性を問い合わせると,これを受け取ったDSAがDIBから必要な情報を抽出し,DUA経由でユーザーに返信する。
ITU-TのX.509証明書をインターネットで使用するために証明書のプロファイルを定めたRFC2459が発行されている。ディレクトリに証明書を格納し、ユーザーの代わりにアプリケーションが自動的に証明書を検索することによって、ほとんどの企業で必要になる透過性が実現できる。また、LDAPをサポートする多くのディレクトリ技術は、項目数がきわめて多くても対応でき、検索要求に効率よく応答できるだけの情報記憶装置と検索方法を備え、ネットワークの隅々にまで適用できるため、どれほど広範囲に分散した組織であっても、その組織の要件を満足することができる。
発行された公開鍵証明書は、様々な理由により失効することがある。例えば、あるエンティティの秘密鍵が盗まれてしまった場合には、その秘密鍵に対応する公開鍵は無効としなければならないため、公開鍵証明書も失効する。また、学校を卒業すると学生証が無効になるように、ある組織から抜けた場合には、その組織から発行されていた公開鍵証明書を無効にしなければならない場合もある。あるいは、期限が過ぎた証明書や公開鍵が不要になったときにも証明書を取り消さねばならない。
そこで、ある公開鍵証明書が有効であるかをチェックする仕組みが必要となる。PKIでは、失効した公開鍵証明書を破棄証明書リスト(Certificate Revocation Lists:CRL)と呼ばれるリストに登録し証明書の検証の際に参照できるようにしている。CRLは証明書を使用する前に毎回確認される。このCRLも証明書リポジトリに格納される。
PKCS
公開鍵暗号化標準 (Public-Key Cryptography Standard: PKCS)とは、米RSA Security社の RSA Laboratories が、米 Microsoft社、米DEC社 (現Compaq Computer 社) 、米Novell社、MIT (マサチューセッツ工科大学) などの協力を得て策定した公開鍵暗号化のための標準規格です。公開鍵を管理する機関CAへの電子証明書発行要求など、暗号化、認証に関するさまざまな事柄が盛り込まれており、現在PKCS #1から #15 までが RSA Security社のサイト (http://www.rsasecurity.com) で公開されています。
PKCS #5
公開鍵暗号化標準その5。パスワードベースの暗号化、例えば保管しておくための秘密鍵の暗号化を受け持ちます。
PKCS #7
公開鍵暗号化標準その7。デジタル署名などのデータの暗号化を受け持ちます。
PKCS #8
公開鍵暗号化標準その8。鍵の格納を定めたものです。公開鍵および秘密鍵を単独でファイル化することは殆ど無く、通常PKCS #12を使用することが多い。
PKCS #11
公開鍵暗号化標準その11。スマートカードなど暗号を用いる通貨とのやり取りを受け持ちます。
PKCS #12
公開鍵暗号化標準その12。スマートカードなど暗号を用いる通貨とのやり取りを受け持ちます。秘密鍵や認定証、その他秘密にしておくものの保存や転送の方式を管理します。
用語集
- CMMF
- Certificate Management Message Formats (証明書管理メッセージフォーマット)。PKIXフォーマットというのがあり、これは証明書の発行・廃棄の要求を使用者から認証機関へ、様々な情報を認証機関から使用者へ送るのに使われている。CMMFはまた別に提案された「CMS(CMC)の証明書管理メッセージ」に含まれるものである。
- CRMF
- Certificate Request Message Formats (証明書要求メッセージフォーマット)。PKIXフォーマットであり、X.509による証明書のライフサイクル管理に関するメッセージで使われる。CMMFの下位セットである。
- DN
- Distingushed Name ITU-T X.500プロトコルで定義されており、世界中でユニークに割り付けられた識別名。
- EE
- end entity (加入者と依存者)。
- FIPS 140-1
- FIPS PUBSで定められた暗号化モジュールに対するセキュリティ要件。
- IAB
- Internet Architecture Board インターネットを運用管理する仕組みの中にあって、インターネットの方針や標準規格などの基本的な問題を検討する組織のこと。
- IETF
- Internet Engineering Task Force (インターネット技術専門委員会)。インターネット上で使われる各種プロトコルなどを標準化したRFC(request for comments)を発行する組織。IABの下部組織にあたる。エリアと呼ばれる分野ごとに責任者を置く形態を採用し、各エリアはいくつものワーキング・グループで構成する。
- OCSP
- Online Certificate Status Protocol (オンライン認証状態プロトコル)。PKIX のプロトコルで、デジタル認証の現在の状態を決めるものである。
- PKIX
- Public Key Infrastructure X.509 (公開鍵技術 X.509)。X.509認証に基づく公開鍵技術をサポートするのに必要なインターネット標準を開発している IETF のワーキンググループ。
- S/MIME
- 高機密化多目的インターネットメール拡張。署名がついて暗号化されたMIMEデータの確実な送受信を提供するメッセージ仕様(広く知られているMIME標準がベースとなっている)がある。
- X.509
- ITU-T が策定した、電子認証や電子証明書に関する国際勧告。秘密鍵 と公開鍵、メッセージダイジェスト (あるいはハッシュ) と呼ばれる暗号化技術を使用して、データの完全性・信頼性・機密性が保たれた暗号・認証を実現するためのフレームワーク(骨組み) が記されている。公開鍵はCAで管理されており、ここからの公開鍵の入手方法も定義されている。
- 依存者
- 加入者の証明書に依存して加入者のディジタル署名を検証する人、組織またはオブジェクト。
- 加入者
- 証明書の発行を受けた対象者(人、組織、またはオブジェクト)。証明書の中で公開鍵と主体名称を結合される。