「PKI・認証技術」に関する問題への対策

2016年9月5日(月)
小林 浩史

はじめに

今回は、「PKI・認証技術」について解説します。PKIについては本試験の午前Ⅱ問題で毎回出題されており、また午後問題でもよく取り上げられています。しっかりと理解しておきましょう。

まず「電子署名」から理解しよう

現実世界では書類に押印したり、手書きでサインを記入したりして誰がその文書を書いたか、また承認したかを明確にします。これをコンピュータの世界で実現するものが「電子署名」です。

電子署名は、誰がその情報を作成したか、情報が改ざんされていないかを確認し、その情報作成者の真正性と情報自体の真正性を識別します。

電子署名の実現方法は図1のとおりです。

図1:電子署名の仕組み

電子署名では送信者の秘密鍵で暗号化(①)、公開鍵で復号化(②)を行います。また、復号されたデータのハッシュ値と送信者から送られてきた情報から生成したハッシュ値と一致するかを確認(③)します。これにより、送信者の真正性と情報自体の真正性を識別します。

PKIの必要性

この時に注意すべきは、復号処理に使用した公開鍵が本当に「送信者の公開鍵」かどうかです。送信者の公開鍵は事前もしくは通信時に受信者へ渡す必要がありますが、公開鍵には名前が書いてあるわけではないので、そのまま渡しても誰の公開鍵か分かりません。第三者(悪者)が送信者になりすまして、送信者の公開鍵を渡すふりをしながら、自分の公開鍵を渡す可能性もあります。

なりすました相手とセキュアな通信をしても意味がありませんので、相手から公開鍵をもらったら、その公開鍵が一体誰の持ち物で、それを誰が保証しているのか確認することが重要となります。

この公開鍵の真正性を保証する仕組みが「PKI(Public Key Infrastructure:公開鍵基盤)」であり、その公開鍵が誰の持ち物かを証明してくれるのが「公開鍵証明書(ディジタル証明書)」です。

CA(Certificate Authority:認証局)とは

公開鍵の所有者は、公開鍵が自分の所有物であると認めてもらうため「CA(Certificate Authority:認証局)」に申請を行います。CAはその申請内容を審査基準に従って審査し、「確かにその申請者の公開鍵である」と認められれば公開鍵証明書を発行します。

CAは機能要素によって、以下のように分かれています。

  • IA(Issuing Authority:発行局)
    公開鍵証明書の発行や失効などの証明書管理を行う
  • RA(Registration Authority:登録局)
    公開鍵証明書の発行申請や失効申請の受付、審査やIAに公開鍵証明書の発行や失効を指示する
  • リポジトリ
    公開鍵証明書や「CRL(Certificate Revocation List:証明書失効リスト)」等の情報を保管し、検索サービスを提供する
  • VA(Validation Authority:証明書有効性検証機関)
    公開鍵証明書が有効であるかを検証する機関

それぞれ似通った名前ですが、これらの名称と役割をしっかりと覚えておきましょう。

なお、午前問題ではこれらの機能の役割について問われることが多く、例えば平成27年春期の午前Ⅱ問4では、以下のような問題が出題されました。

問4 VA(Validation Authority)の役割はどれか。

ア ディジタル証明書の失効状態についての問合せに応答する。
イ ディジタル証明書を作成するためにディジタル署名する。
ウ 認証局に代わって属性証明書を発行する。
エ 本人確認を行い,ディジタル証明書の発行を指示する。

正解は(ア)です。(イ)はIA、(ウ)は「AA(属性証明書発行機関:Attribute Certificate Authority)、AC(属性証明書:Attribute Certificate))」、(エ)はRAです。AAはあまり出題されませんが、前回も解説したように、もし違う選択肢を正解とする問題が出題されても答えられるように、不正解の選択肢も一度は内容を調べる癖をつけてください。

また、平成27年春期の午後Ⅱ問題問2の設問(4)では、K工場とJ社本社の役割分担でどの役割をどちらが担当するかを決めるような問題が出題されています。IA、RAの役割をしっかりと理解していれば、問題なく解答できるはずです。

冒頭でもお話ししたように、午前、午後どちらにもよく出題される分野ですので、基礎をしっかり押さえておきましょう。

公開鍵証明書とは

「公開鍵証明書」は通常、「ITU-T勧告X.509」の規格に準拠したものが使用されます。図2は、X.509v3のディジタル証明書の構成内容です。

図2:ディジタル証明書の構成内容(X.509 v3)

公開鍵証明書には公開鍵情報、公開鍵の所有者(主体者)情報、認証局情報、有効期限があり、公開鍵が誰の持ち物で、誰がその証明書を認めているのかが分かります。従って、公開鍵証明書を受け取ったら、これらの項目を基に偽造や改ざん等、偽の公開鍵証明書でないことを確認する必要があります。

例えば、公開鍵証明書を使用した身近な通信にWebのHTTPS(HTTP over SSL/TLS)通信があります。Webブラウザ側からWebサーバへHTTPS通信を行うと、Webサーバ側からサーバの公開鍵証明書が送られてきます。このとき、ブラウザ側でWebサーバの公開鍵証明書が信頼できるかを確認します。その主なチェック項目は以下の通りです(図3)。

  • 信頼された認証局から公開鍵証明書が発行されているか
    「信頼された認証局」は公開鍵証明書を受け取る側がその認証局を信頼しているかどうかが重要になる。認証局の公開鍵証明書を持つことはその認証局の身分証明書を受け入れていることと同じなので、その認証局を信頼することになる
  • 相手がなりすましていないか
    通信のあて先で設定した相手と、相手から送られてきた公開鍵証明書に記載されている相手の名前が一致しているか
  • 公開鍵証明書の有効期限が切れていないか
    公開鍵証明書に記載されている有効期限内か

図3:公開鍵証明書の確認

平成28年度春期の午後Ⅰ問題問3「スマートフォンアプリケーションの試験」の問題でPKI関連の問題が出題されました。出題レベルとしてはそれほど高いものではなく、PKIの基本的な仕組みについて問われています。

この問題の表2では「不正なサーバ証明書の検出についての試験項目(抜粋)」を記載しており、その「試験項目」として「発行者が不正であることの検出」「有効期間内でないことの検出」「サブジェクトのコモンネームが不正であることの検出」が挙げられています。この3つは前述したWebサーバの公開鍵証明書を検証する項目そのもので、表2にはそれが正しく動作するかをテストするための内容が記載されています。よって、この3項目を理解していれば解答に迷うこともないと思われるので、必ず押さえておいてください。

また「サブジェクトのコモンネーム」という言葉が使われていますが、これは「サーバ証明書にある主体者(この場合はWebサーバ)の一般名(CN:Common Name)」を指しています。X.509 v3で定義されている公開鍵証明書の用語を覚えていれば問題なく理解できると思いますので、一度は本物の公開鍵証明書を見ておくと良いでしょう。ちなみに、thinkit.co.jpのWebサーバ証明書は図4のようになっています。

図4:thinkit.co.jpのWebサーバ証明書

証明書失効リストとは

公開鍵証明書の発行後、まだ有効期限内であるのにもかかわらず、何らかの理由でその証明書が不要になった場合は、証明書の失効申請を出す必要があります。失効申請は証明書発行申請と同様にRAへ出しますが、失効申請が受理されるとCRL(証明書失効リスト)に失効した公開鍵証明書のシリアル番号が掲載されます。

CRLについてもよく出題されますが、平成27年度春期の午前Ⅱ問6では、以下のような問題が出題されました。

問6 X.509におけるCRL(Certificate Revocation List)についての説明のうち,適切なものはどれか。

ア PKIの利用者は,認証局の公開鍵がブラウザに組み込まれていれば,CRLを参照しなくてもよい。
イ 認証局は,発行したすべてのディジタル証明書の有効期限をCRLに登録する。
ウ 認証局は,発行したディジタル証明書のうち,失効したものは,失効後1年間CRLに登録するよう義務付けられている。
エ 認証局は,有効期限内のディジタル証明書をCRLに登録することがある。

正解は(エ)です。CRLには有効期限内に失効した証明書の情報が登録されます。有効期限が切れるとCRLに登録されていなくても効力を失うため、有効期限を超えたものは基本的にCRLには登録はされません。覚えておきましょう。

また、証明書の失効理由について問われる場合もあります。特に気を付けたいのが秘密鍵を漏えい・紛失した場合です。第三者に秘密鍵を悪用され、なりすまされる可能性があります。秘密鍵を漏えい・紛失した場合は、すみやかに証明書失効申請を行う必要があります。

前述した平成27年度春期の午後Ⅱ問2設問(4)でも、秘密鍵の漏えい・紛失における失効申請理由について記述する問題が出題されています。

証明書失効の確認について

証明書失効処理が行われると、CRLに失効した証明書情報が登録されますが、証明書自体には何の変化もありません。証明書を見ただけでは証明書が失効しているかどうか分からないので、証明書を受け取る側は証明書が失効していないかも確認する必要があります。

証明書が失効しているかどうかは、定期的にCAのリポジトリからCRLをダウンロードすることでチェックできます。Internet Explorerであれば「ツール」-「インターネットオプション」の「詳細設定」タブで「セキュリティ」-「サーバの証明書失効を確認する」にチェックを入れておけば良いでしょう(図5)。

図5:証明書失効の確認方法(Internet Explorerの場合)

ただし、この場合は相手から証明書が送られてくるたびにCRLをダウンロードしているわけではありません。一度CRLをダウンロードすると、次のCRL更新時まではダウンロードされません。

また、別の方法として「OCSP(Online Certificate Status Protocol )」により失効情報を確認する方法もあります。OCSPはリアルタイムで証明書の失効状態を確認するプロトコルで、OCSPに関してもよく出題されています。

平成28年度の春期午前Ⅱ問3では、以下のような問題が出題されました。

問3 PKIを構成するOCSPを利用する目的はどれか。

ア 誤って破棄してしまった秘密鍵の再発行処理の進捗状況を問い合わせる。
イ ディジタル証明書から生成した鍵情報の交換がOCSPクライアントとレスポンダの間で失敗した際,認証状態を確認する。
ウ ディジタル証明書の失効情報を問い合わせる。
エ 有効期限の切れたディジタル証明書の更新処理の進捗状況を確認する。

正解は(ウ)です。他の選択肢ももっともらしいことを書いていますが、OCSPが失効情報をオンラインで問い合わせるプロトコルであることを知っていれば問題ないと思います。

また、CRLをダウンロードすると、失効しているか調べたい証明書以外の失効情報も送られてきますが、OCSPは問い合わせたい証明書の失効情報のみを検索して調べるため、効率が良くなります。

ただし、OCSPはネットワークの切断等で認証局のリポジトリと通信できなければ問い合わせできませんが、CRLダウンロードは一度CRLをダウンロードしておけば、認証局のリポジトリと通信できなくても利用できます。このような両者の特徴も併せて覚えておいてください。

おわりに

「PKI・認証技術」は仕組みがややこしいところもありますが、試験では午前も午後も「基本的な仕組みを理解しているか」を問われることが多いので、試験前に必ず確認し、自分の言葉でPKIの仕組みを説明できるようにしておきましょう。

次回は、「ネットワークセキュリティ分野」について解説します。

NECマネジメントパートナー 人材開発サービス事業部
1993年日本電気株式会社入社。教育部門に所属し、セキュリティ領域の教育を担当。2004年から(ISC)2公式インストラクターとして、CISSPレビューセミナーの講師も務めている。近年においては、官公庁の職員や重要インフラ事業者のCSIRT要員に対してインシデント対応の演習を行っており、国のサイバーセキュリティ人材育成にも貢献している。

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています