ニュースレターNo.23/2003年3月発行

インターネット10分講座：PKI

PKIとは

PKI（Public-Key Infrastructure）は公開鍵暗号^※1を利用した認証基盤です。基盤技術であるため、PKIという一つの仕組みを、様々な認証の為に利用できます。たとえばユーザー認証やメッセージの正当性確認などに応用でき、電子メールやWebサービスで利用されています。

PKIでは通信相手が本物であるかどうかの確認（認証）に公開鍵証明書（以下、証明書）を利用します。PKIにおける証明書は、発行者の名前といった情報が記述されており、身分証明書の役割を果たします。身分証明書を、信頼できる第三者（TTP：Trusted Third Party）に発行してもらうことで、その身分証明書を信頼できるようにするのがPKIの特徴です（図1）。たとえばここでいう身分証明書が運転免許証であるとすると、信頼できる第三者は公安委員会ということになります。

図1：信頼できる第三者と身分証明

証明書を利用して相手を認証する際には、証明書が偽造されていないか、その証明書の発行元は信頼がおけるのか、といった確認が行われます。証明書が有効であれば、その証明書の提示を行ったのが正しい相手であることがわかります。そのため初めて通信する相手でも、直接対面することができない通信相手でも認証できます。よってPKIはインターネットのような通信相手と対面することを前提にできない環境に適しています。

以下にPKIの仕組みのうち、X.509^※2やRFC3280^※3に基づいた証明書の扱いについて解説します。

証明書の利用

PKIで用いられる証明書は、認証局（CA：Certification Authority）によって発行されます。PKIでは、このCAが“信頼できる第三者”にあたります。CAは、いわば身分の証明を行っている機関なので、ユーザーに強く信頼されていなければなりません。ユーザーは、自分が信頼しているCAが発行した証明書であれば信じられるということになります。

証明書には身分を証明する内容だけでなく、公開鍵暗号方式で使われる暗号鍵（公開鍵）も含まれています。この暗号鍵は、電子メールの電子署名やWeb のサーバやクライアント（ブラウザ）の認証に使うことができます。たとえば電子メールの場合、S/MIME（Secure/Multipurpose Internet Mail Extensions）^※4というプロトコルで、PKIを利用することができます。電子メールでの重要なやりとりでは、送信者は本人に間違いないのか、内容が他人によって書き換えられていないか、といった事が重要になります。PKIを使うと、S/MIMEでの電子署名が本人のものであるかを確認することができます。またTLS （Transport Layer Security）^※5というプロトコルでもPKIが利用されます。Webブラウザがhttps（TLSやSSLを使ったhttp）を使ってWebサーバと通信を行っているとき、そのことを示す鍵マークが表示されます。鍵マークが表示されるまでに、WebサーバとWebブラウザは証明書の交換を行い相手の証明書を検証しますが、この時にPKIが使われます。 PKIは認証情報をアプリケーションとは独立に扱います。そのため様々なアプリケーションに応用したり、アプリケーションに変更を加えずにPKIの仕組み自体を改良したりできます。

証明書とユーザー

ユーザーはCAに証明書を発行してもらい、その証明書をアプリケーションで利用します（図2）。CAはユーザーと同様に証明書を持っており、その証明書に含まれている暗号鍵を使って、発行する証明書に電子署名を施します。ユーザーはCAの証明書を参照する事で、検証したい証明書の発行に使われた暗号鍵が、確かにそのCAのものであるということを確認できます。

図3のように、ユーザーはルートCA、もしくはいずれかのCAを信頼し、そのCAが発行する証明書は正しいという前提に立って証明書を検証します。ユーザーが信頼しているCAは、そのユーザーにとっての“トラストポイント”（信頼点）と呼ばれます。トラストポイントはユーザーによって異なります。

図2：証明書の発行と利用

図3：トラストポイント

証明書の内容

証明書には図4のような内容が記述されています。

図4：証明書の例

SubjectやIssuerに記述されている名称は、識別名（DN: Distinguished Name）と呼ばれます。表1にDNの要素と意味を示します。

表1：X.509形式の証明書で使われる識別名（DN）の要素
要素	意味
C（Country）	国名
O（Organization）	組織名
OU（Organizational Unit）	部門名
CN（Common Name）	一般名

この他に、証明書には公開鍵データやCAによる署名のデータ、用途などの情報が記述されています。これらのフィールド（項目名と値）は、検証の際に参照されます。

証明書の検証

証明書の検証には、二つの側面があります。

一つ目は証明書チェイン（証明書の連鎖）です。証明書チェインとは、検証したい証明書からトラストポイントもしくはルートCAの証明書までの一連の証明書が連鎖している状態のことです。各々の証明書に電子署名されており、それぞれの電子署名を検証できる公開鍵は、発行者であるCAの証明書（以下、CA 証明書）に含まれています。認証したい相手の証明書を検証するには、一連の証明書を次々に検証していく必要があります。

二つ目の側面は、証明内容を受け入れられるかどうかです。証明書には、証明対象の名称や証明書の用途、証明書のポリシー（の識別子）が含まれています。たとえば対象を限定して検証を行いたい場合、Subjectの比較を行ないます。JPNICという組織に属しているものだけを認証したいとき、Subjectに“C=JP, O=JPNIC”が含まれているかどうかを確認します。たとえ証明書の連鎖が成立していても、Subjectが想定したものと異なる場合、認証は成立しないことになります。Subject以外に、受け入れられる用途かどうか、受け入れられるポリシーかどうかといった検査を行います。これらの二つの側面で検査し問題がなければ、認証が成立したことになります。

次に上記で説明した側面をふまえ、証明書の検証手順について説明します。証明書の検証手順には、いくつかの方法が提案されています。ここでは認証対象の証明書から上位のCAに向かって証明書を辿っていく方法を説明します。はじめに認証対象の証明書から上位のCAに向けて証明書のチェインを構築します。この処理はパス構築と呼ばれます。

Issuerの値（発行者の名称）を元にCA証明書を入手。
CA証明書のIssuerの値を元に、そのCA証明書を発行したCAの証明書を入手。
CA証明書入手を繰り返しトラストポイントのCA証明書に辿り着いたかどうか判断。

次にそれぞれの証明書の証明内容を検査します。

CA証明書に含まれている公開鍵で、認証対象の証明書の電子署名を検証。
名称、有効期限、鍵の用途が受け入れられるかどうかを検査。
証明書が失効していないかを検査。

証明書の失効とは、CAがその証明書の効力が失われたと認識し宣言することです。証明書の失効の理由には、証明内容の変更や暗号鍵（秘密鍵）の紛失などがあります。証明書が失効されているかどうかはCAによって発行されるCRL（Certificate Revocation List（失効された証明書のリスト））を使って調べることができます。

証明書の検証をネットワークアプリケーションに組み込むと、そのアプリケーションの認証の手順は以下のようになります。

認証処理のはじめに証明書を交換。
次に相手が提示した証明書を検証。
CRLの入手などを適宜行ない、証明書の最新の状態を確認。
証明書が有効である場合、認証できたと判断しアプリケーションのサービスを開始。

PKIの今後

X.509は、証明書のフィールドと扱いについて書かれたものです。そのため、PKIを利用するための実用的なプロトコルは、X.509の枠組みには含まれていません。一方、IETFのPKIX WGでは、RFC3280を始め、より実用的なプロトコルが提案されています。今後もIETFを含め様々な団体で、PKIの実用性や適用の可能性を広げる活動が行なわれると考えられます。

運用の面では、CAの運用に必要な環境整備や、より複雑なCAの相互接続が進むと考えられます。CAの運用には明確な方針が必要です。国内でも、方針作りの助けになる文書が整備されつつあります。また複数のCAが相互接続されることにより、ユーザが各自のトラストポイントを変更せずに、別の組織のCAを利用する場面が現れると考えられます。

（JPNIC セキュリティ事業準備室　木村泰司）

※１　公開鍵暗号：: 暗号化と復号（暗号化されているデータを元に戻す処理）のために異なる鍵を使う暗号方式。一方の鍵から他方の鍵を推測することが難しいため、片方の鍵を公開して利用することができる。公開された方の鍵で暗号化されたデータは、公開されない方の鍵でしか復号できない。公開される鍵は公開鍵と呼ばれ、公開されない鍵は秘密鍵と呼ばれる。
※２　X.509：ITU Recommendation X.509。: 証明書のフィールド（項目名と値）や、その扱いについて勧告した国際標準。RFC3280などIETF PKIX WGの提案は、このＸ.509にもとづいています。
※３　RFC3280：IETF PKIX WGにて証明書のフィールドや扱いを提案したRFC。 http://www.ietf.org/rfc/rfc3280.txt
※４　S/MIME：Secure/Multipurpose Internet Mail Extensions: 主に電子メールなどで利用されるプロトコル。データに対する暗号化や電子署名の扱いを、エンベロープ（封筒）という概念を用いて提案したもの（RFC 2633）。http://www.ietf.org/rfc/rfc2633.txt
※５　TLS：Transport Layer Security: TCPなどのトランスポート層プロトコルの上位プロトコルで、暗号化や双方向の承認を実現します。TLSやSSLを併用したHTTPは、httpsと表記されます（RFC 2246）。http://www.ietf.org/rfc/rfc2246.txt