公開鍵インフラストラクチャ (KPI) について

この付録では、以下の項目について説明します。

基盤となる必要性

コンピュータを使用していてセキュリティを必要とする状況は数多くあります。馴染みのある一例は、インターネットなどの安全ではないネットワークを移動するビジネス・トランザクションなどの情報をどのように保護するかといった状況です。また、ある種の検証可能で法的拘束力のある電子署名が必要な場合もあります。

セキュリティを提供する最も一般的な方法の 1 つは公開鍵暗号化の使用です。公開鍵暗号化は、データの暗号化および解読を可能にする数学的アルゴリズムです。公開鍵暗号化を使用しているユーザは誰でも公開鍵と秘密鍵の 2 つの鍵を保持しています。このアルゴリズムでは、ある操作 (暗号化など) の実行に一方の鍵が使用され、他方の鍵によって、補完的な操作 (ここでは解読) が実行されます。これらの鍵および操作を使用して、公開鍵暗号化は、送信中のデータの保護、ドキュメントの出所の立証などのセキュリティを実現する方法を提供します。

ただし、公開鍵暗号化のみでは、特にアクティビティの参加者が個人的にお互いを知らない場合には、その参加者の身元確認に十分な信頼性を提供できません。十分な信頼性を提供して、インターネットを介した設定などの安全ではない設定で公開鍵暗号化を使用できるようにするには、関与しているエンティティに関して信頼性の高い、検証可能な身元確認情報も提供するより大きな構造が必要です。このような構造を公開鍵インフラストラクチャ (PKI) と呼びます。

PKI は、個人的に直接知らないまたはお互いに接触がない個人および組織 (一般的にエンティティと呼びます) がお互いの身元を信頼できる方法を提供します。これは、エンティティそれぞれが、他方のエンティティ (他方のピアとも呼ばれます) の身元を請け合うサードパーティを信頼することに依存します。これによって、エンティティは、意味のある、法的拘束力のある暗号化操作を実行できます。この操作には、暗号化、解読、デジタル署名、シグニチャの検証などがあります。

以下のような複数の目的で PKI を使用できます。

SSL/TLS (Secure Sockets Layer またはその後継の Transport Layer Security) を使用した通信の保護
XML デジタル署名 (通信ありまたはなし)
データ暗号化
デジタル署名

公開鍵暗号化について

公開鍵暗号化は、個別のエンティティ (エンティティとは、人、アプリケーション、組織など) によって制御されるデータを操作します。各エンティティには、厳密に保持される秘密である秘密鍵、および広く使用可能にされる公開鍵があります(通常、公開鍵は、公開鍵自体と鍵保有者の識別情報の両方を保持する公開鍵証明書にカプセル化されています。証明書および認証機関の詳細は、以下を参照してください)。

公開鍵アルゴリズムは、補完的操作に 2 つの鍵を使用します。いずれの鍵でもいずれの操作を実行できます(最も一般的に使用されている公開鍵アルゴリズムは Ron Rivest、Adi Shamir、および Leonard Adleman が開発した RSA アルゴリズムです)。公開鍵暗号化に関連付けられたすべての機能は、一方の鍵で暗号化されたデータは他方の鍵でのみ解読できるというこの基本原則に基づいています。

したがって、あなたの秘密鍵を使用してコンテンツを暗号化した場合、その解読に使用できるのはあなたの公開鍵のみです。逆に、あなたの公開鍵を使用して別のユーザがコンテンツを暗号化した場合、あなたの秘密鍵のみ (したがって、あなたのみ) がそのコンテンツを解読できます。つまり、公開鍵暗号化は、2 つのエンティティ間の安全かつ個人的な通信を実現する方法を提供します。私の秘密鍵で署名されていて、あなたの公開鍵で暗号化されているメッセージを私があなたに送信する場合、あなたは、私からであると信じることができ (私のみが私の秘密鍵にアクセスできるため)、あなたのみが読むことができる (あなたの秘密鍵のみがこれを解読できるため) コンテンツを入手できます

(1 つのエンティティのみが鍵のペアおよび証明書を持っている、より単純なケースもあります。これは、そのピアの身元のみを検証する必要がある場合のアレンジです)。

公開鍵暗号化の使用法には以下が含まれます。

秘密鍵のみがデータを解読できるように、公開鍵を使用してデータを暗号化。この使用法では、秘密裏にデータを転送できます。例えば、暗号化されたデータが特定の医療レコードである場合があります。その結果、このようなレコードを一方のピアが他方のピアに安全に転送でき、他方のピアのみがそのレコードを解読できることを確信できます。
誰もが署名者の公開鍵を使用してデータまたはハッシュを解読できるように、既知の署名者の秘密鍵を使用してデータ (またはデータに基づいたハッシュ) を暗号化。この使用法は、データの出所を立証します。例えば、暗号化されたデータは法律文書である場合があります。その結果、既知の個人に関連付けられた秘密鍵を使用してデータを暗号化するアクションは、その文書に対する法的拘束力のあるデジタル署名になります。
署名者の身元を確認できるように、署名者の身元が不明である場合に秘密鍵を使用してデータを暗号化。この使用法は、公開鍵に対する秘密鍵の一意のリンク、公開鍵をエンティティにバインドする証明書の使用、および証明書に基づいてエンティティを検索する機能に基づいています。例えば、秘密鍵を使用して署名されたメッセージのみを使用すると、そのメッセージの出所 (つまり作成元、具体的には署名者) を特定できます。

認証、証明書、および認証機関

お互いを知らず、帯域外認証 (身元の確認) を簡単に実行できないユーザ間で公開鍵暗号化を有用なものにするには、どの公開鍵がどのユーザに関連付けられているかを判定する方法が必要です。この目標を達成するメカニズムが証明書で、認証機関 (CA) によって発行されます。証明書は、信頼されるサード・パーティ (CA) によってデジタル署名され、公開鍵をその所有者に関する一連の識別情報 (名前、組織、場所など) と結びつけるドキュメントです。

通常、CA は VeriSign などの独立した組織であるか、または組織内にあります。外部 CA でも内部 CA でも、中間 CA を設けることもできます。中間 CA は、最上位の CA またはルート CA に対する下位 CA として機能します。例えば、組織全体がルート CA を所持し、部門または営業所がそれぞれ独自の中間 CA を所持できます。

各エンティティが同じ CA を使用する必要はありません。それぞれ (より一般的にはそれぞれのソフトウェア) が他の CA を信頼する必要があるだけです。この CA の信頼のリレーションシップは、通常、一連の事前承認された CA 証明書をブラウザに付属させるなど、ユーザの操作なしで確立されます。例えば、Firefox 14.0 では、[詳細] タブの [ツール]→[オプション] ダイアログで [証明書を表示] ボタンおよび [認証局証明書] タブをクリックして信頼された CA のリストを表示できます。ユーザが SSL/TLS を使用していて、信頼された CA を所有しているサイトに接続しようとすると、ユーザのブラウザはそのサイトを認証できます。

接続を受け取るエンティティが接続を開始したエンティティを認証することもできます。これを、相互認証といいます。これも通常、人による操作を必要としません。

2 つのエンティティが相互に認証を必要とする場合、両者の証明書および CA の信頼されたリレーションシップを使用して認証を行います。したがって、Alice と Bob が例えば SSL/TLS を使用して通信しようとする場合、SSL/TLS ハンドシェイクは、以下のようにそれぞれの認証を実行します。

Alice は最終的に Bob の証明書を受け取ります。Bob の CA がこの証明書に署名済みであるため、Alice はこの証明書を信頼できます。Bob の CA は信頼された CA であるか、証明書のチェーンを上にたどると、Bob の CA 自体が信頼された CA によって最終的に署名された証明書を持っています。
同じ事が Alice の証明書と Bob にも当てはまります。

別の例として、ある大企業の本社がサンパウロにあり、東京とイスタンブールに営業所があるとします。この会社のルート CA はサンパウロにあり、中間 CA が東京とイスタンブールにあります。相互に認証する必要があるエンティティが東京とイスタンブールにあるとします。東京のエンティティが他方の証明書を受け取ると、この証明書はイスタンブールの CA によって署名されていて、このイスタンブールの CA はサンパウロのルート CA によって署名された証明書を持っていることがわかります。東京の CA によって署名された証明書を確認するイスタンブールのエンティティも同様です。

CA が証明書を作成する方法

あるエンティティが CA から証明書を取得するとき、多くのイベントが発生しますが、その多くをユーザには表示されません。

まず、アルゴリズムによって鍵のペアが作成されます。次に、その鍵のペアを使用してそのエンティティを説明するために必要な情報 (エンティティの場所、組織などに関係する) を取得します。すべてを合わせて、この識別情報は識別名 (DN) を構成します。このエンティティは、証明書署名要求 (CSR) の形式で公開鍵および DN 情報を CA に提供します。秘密鍵は、ここでも厳密に保持される秘密であるため、提供しません。

CA は CSR を受け取り、手順に従って CSR を処理します (手順は、CA およびその証明書が証明する信頼性の度合いによって変わります)。最終的に CA は、公開鍵を DN 情報にバインドしているドキュメントに署名し、証明書 (具体的には、X.509Opens in a new tab 標準に準拠した証明書) を作成します。

証明書の制限 : 有効期限および取り消し

証明書には有効期限があります。このため、証明書の所有者は、証明書を定期的に更新する必要があります。CA 証明書にも有効期限がありますが、これはサイトの無効な証明書を受け入れますかと質問するメッセージが時折表示される 1 つの理由です。このメッセージは、サイトの所有者が証明書を期限切れにすると表示されます。

証明書が失効した場合、CA には証明書取り消しリスト (CRL) と呼ばれるものを使用して、これを無効であると宣言する手段もあります。CRL は、CA が公開し、認定を取り消す証明書をすべて指定するドキュメントです。CRL は、店舗が個人小切手を受け付けない人のリストに似ています。実際、証明書または小切手は有効だが、CRL または前記のリストで受け入れられない証明書または小切手を指定している場合、CA と店舗の両方で不履行という点でよく似ています。

PKI 機能のまとめ

CA およびそのクライアントのさまざまなアクティビティは、これらが公開鍵インフラストラクチャ (PKI) の一部であることによって可能になっています。まとめると以下のようになります。

PKI は、秘密鍵、および公開鍵を格納している証明書を作成して管理するためのシステムの実装です。証明書は、公開鍵をエンティティと関連付ける方法を提供するため、エンティティの身元を保証できます。このために、PKI には認証機関 (CA) と呼ばれる信頼されるサード・パーティが含まれます。
PKI は ID およびその他の重要な情報を公開鍵と関連付けます。公開鍵は関連付けられた秘密鍵の存在を示唆するため、公開鍵に関連付けられた ID は秘密鍵とも関連付けられます。
すべてを合わせて、PKI は、安全でない環境のエンティティが、十分な確信を持って、公開鍵暗号化を意味があり法的拘束力のある方法で使用できる機能を提供します。