本文とサイドメニューへジャンプするためのナビゲーションスキップです。

スタートアップガイド

J-Net21 中小企業ビジネス支援サイト

  • J-Net21とは
  • スタートアップガイド
中小機構
  • メルマガ登録
  • RSS一覧
  • お問い合わせ

HOME > 製品・技術を開発する > デジ・ステーション

デジ・ステーション


初級ネットワーク講座
第25回 電子証明書とSSL

2004年のe-文書法の制定によって、商取引における文書は、従来の紙だけではなく電子データとしても保存することが可能となった。また、電子政府・電子自治体などによってインターネットによる各種申請が可能となってきた。これらの電子データが法律的根拠を持つためには、紙の書類同様に真正性、つまり認証や改ざんの有無の検出が必要となる。今回はSSLを例にとりながらCAおよび電子証明書の役割について説明する。

1 セキュアプロトコル

表1 OSI参照モデルとセキュアプロトコル
表1 OSI参照モデルとセキュアプロトコル

前号で解説した暗号化技術を実際にユーザが使おうとした場合、「公開鍵暗号方式か?それとも共通鍵暗号方式か?」「秘密鍵、公開鍵をどう生成するか?」などを考慮しなくてはならず、負荷がかかる。そこで、ユーザが意識しなくても暗号化技術を使えるようにしたのが「セキュアプロトコル」である。
 セキュアプロトコルには、L2TP、PPTP、IPsec、SSL、S/MIMEなどがある。それぞれに特徴があり、表1のように動作するレイヤ(OSI参照モデル上の層)が異なるので、利用目的に応じて適切なセキュアプロトコルを選択することになる。
 今回は、インターネット上でWebサーバにアクセスする際、暗号化および認証のため用いられるセキュアプロトコル、SSLについて解説する。

2.SSL(Secure Socket Layer)の仕組み

SSLは、トランスポート層の上位、セッション層の下位で動作する。もともと、HTTPとの併用を前提に開発されたが、上位層のプロトコルには依存しない。
 SSLは公開鍵暗号方式、共通鍵暗号方式、ハッシュ関数、そして電子証明書などのセキュリティ技術を組み合わせ、「通信相手の認証」と「通信データの暗号化の機能」を持つことで、通信データの盗聴や改ざん、なりすまし対策を実現できる。SSLの登場により、現在インターネットで広く使われているHTTPやFTPなどのデータを安全にやり取りすることが可能となった。

コラム:SSLとTLS(Transport Layer Security)
 SSLを最初に開発したのは、Netscape Communications社である。SSL3.0にIETFが多少の手直しを加え、次のバージョンとしてRFC2246 TLS1.0が標準化された。この段階でSSLはTLS(Transport Layer Security)と名称が変わったのだが、すでにSSLという名前が広く浸透してしまっていたため、今も一般的にはTLSも含めてSSLと呼ばれている。

2-1 SSL通信の準備

ネットショッピングのサイトを立ち上げることになったと考えてみよう(図1)。

図1 SSL通信の準備
図1 SSL通信の準備
(1)
顧客情報を安全にやりとりするためにSSL対応のサーバが必要となるが、そのためには認証局(CA:(Certificate Authority)(以下「CA」と略す)が発行する電子証明書が必要である。そこで、サイト管理者は、公開鍵暗号方式を用いて、あらかじめサーバの「公開鍵」(以下「サ公」)と「秘密鍵」(以下「サ秘」)のキーペアを生成する(図1(1))。
(2)
サイト管理者は「サ公」とともに、CSR(証明書署名要求:Certificate Signing Request)をCAに提出する(図1(2))。
(3)
CAは、サイトを運営している会社または個人が存在することを確認したうえで、「証明情報」「サ公」とともに「CAの電子署名」を付加して電子証明書を作成し、サイト管理者に渡す(図1(3))。
(4)
サイト管理者はサーバに電子証明書をインストールする。

2-2 電子証明書の仕組み

SSLで用いられる電子証明書は、「X.509証明書」「公開鍵証明書」「デジタル証明書」とも呼ばれ、ITU-T(国際電気通信連合)がX.509として策定したもので、ISO/IECの国際標準としても規定されている。
 電子証明書は、証明情報、被証明者(主体者)の公開鍵、証明者(発行者)の電子署名の3つの部分から構成されている。証明情報と被証明者(主体者)の公開鍵をあわせて「署名前証明書」と呼ぶ。この「署名前証明書」にハッシュ関数を用いて「署名前証明書のメッセージダイジェスト」を生成、これを証明者(発行者)の秘密鍵で暗号化したものを「電子署名」とする(図2)。

図2 電子証明書の構成
図2 電子証明書の構成

CA発行の電子証明書の場合、CAは公開鍵暗号方式を用いて、あらかじめCAの「公開鍵」と「秘密鍵」(以下「CA公」「CA秘」)のキーペアを生成しておく。「署名前証明書のメッセージダイジェスト」に「CA秘」で暗号化したものを「CAの電子署名」とする。

2-3 SSLサーバへのアクセス

利用者(クライアント)からサイト(サーバ)へのアクセスがあった時、どんな通信が行われるのか。実際のパケットをキャプチャした画面で見てみよう(図3-1、図3-2)。

図3-1
図3-1

パケット1からパケット6まで
(クリックすると大きな画像が表示されます。)

図3-2
図3-2

パケット7とパケット8
(クリックすると大きな画像が表示されます。)

パケット1 クライアント→サーバ SYN

TCPコネクション最初のパケット、あて先ポート番号(0020行目の左から9個目)が"01BB"(10進数で"443")でSSLでコネクション確立したいと要求(SYN)。

パケット2 サーバ→クライアント SYN、ACK

クライアントからサーバに対するコネクション確立要求に対する肯定応答(ACK)、および、サーバからクライアントに対するコネクション確立要求(SYN)。

パケット3 クライアント→サーバ ACK

サーバからクライアントに対するコネクション確立要求に対する肯定応答(ACK)。

このように、パケット1からパケット3で、クライアント=サーバ間のコネクションが確立した。TCPのコネクション確立は3つのパケットを使って行われるので3wayハンドシェークとも呼ぶ。次からSSL通信が始まる。

パケット4 クライアント→サーバ Client Hello

まずはクライアントからサーバに「Client Hello」なるパケットを送信する。
 このあと暗号化通信を行うが、クライアントとサーバ側で使用する暗号方式を一致させないと復号できない。また、自分の保有している暗号方式を必ずしも相手が保有しているとは限らない。そこで、使用する暗号の方式を決めなければならない。
 そこで、「Client Hello」には、クライアントが保有する暗号方式の一覧(例えば、共通鍵暗号方式は★★と◎◎と△△、公開鍵暗号方式は※※、ハッシュ関数は**、◆◆のように)を送る。あわせて、クライアントで生成した乱数(以下「クライアント乱数」)をサーバに送る。

パケット5 サーバ→クライアント Server Hello + Server certificate

Client Helloでクライアントが保有する暗号方式の一覧を受け取ったサーバは、あらかじめ決めておいた優先度順に従って、使用する暗号方式を確定する。あわせて、サーバで生成した乱数(以下「サーバ乱数」)をクライアントに送る。
 続いて、電子証明書を送付する。電子証明書の署名前証明書部分は平文なので、パケットキャプチャのASCII文字列で容易に読み取れる。この例では、証明者(発行者)が「RSA DATA Security Inc」で、被証明者(主体者)が「Amazon.com」である。
 また、被証明者の識別子が「www.amazon.co.jp」(01A0行目参照)というFQDN(完全修飾ドメイン名:Fully Qualified Domain Name)になっている。FQDNとは、ホスト名とドメイン名をあわせたもの。同じドメイン名でもホスト名が異なれば、すなわちFQDNが異なれば、それぞれについて電子証明書を取得しなければならない。
 電子証明書には、サーバ証明書、クライアント証明書などいくつかの種類の証明書がある。ここでは、「RSA DATA Security Inc」というCAが「Amazon.com」という会社の「www.amazon.co.jp」というサーバのサーバ証明書を発行している。
 さらに、パケット5 には、「www.amazon.co.jp」のサーバ証明書とは別に、もう1つの電子証明書が含まれている。こちらは証明者(発行者)が「Verisign」で、被証明者(主体者)が「RSA DATA Security Inc」である。この両者はいずれもCAであり、CAがCAに発行した電子証明書、すなわちCA証明書である。ここに、CAの公開鍵も含まれる。

2-4 電子証明書の検証

パケット5を受け取ったクライアントは、電子証明書の有効性の検証を行う。下記の項目のうちひとつでも不具合があると画面にエラーメッセージが表示される。

●電子証明書の失効確認
 電子証明書のシリアルナンバーを見て、証明書失効リスト(CRL:Certificate Revocation List)に該当のシリアルナンバーがないか確認する。
●有効期限の確認
 電子証明書の有効開始年月日時分秒および有効終了年月日時分秒を現在時刻と比較し、電子証明書が有効期間内か確認する。
●識別子の確認
 電子証明書のFQDNとアドレスが同一か確認する。

次に電子証明書を、署名前証明書と電子署名に分ける。

(1)
「電子署名」を「CAの公開鍵」で復号して「署名前証明書のメッセージダイジェスト」を取り出す。←【認証】
(2)
「署名前証明書」にハッシュ関数を用いて「署名前証明書のメッセージダイジェスト」を生成する。
(3)
双方の「署名前証明書のメッセージダイジェスト」を照合する←【改ざんの有無の確認】

図4のように、CAは頂点が「ルートCA」とする階層構造となっている。それぞれの枝が認証した証として電子証明書が生成される。

図4 CAの階層構造
図4 CAの階層構造

そして、受け取った電子証明書がルートCAまで達するまでのパスを検証する。どの階層のCAが発行した電子証明書かによって、パスの数は異なる。
 この例では図5のとおり、3つの証明書でルートCAに達するまでのパスを検証する。ルートCAの電子証明書だけは、自身の秘密鍵で電子署名を作成しているのでルートCAの電子証明書まで検証できれば完了である。

図5 ルートCAまでのパスの検証
図5 ルートCAまでのパスの検証

クライアントはルートCAの電子証明書をどうやって入手したのか。パケットキャプチャを見るかぎり、パケットを介して手に入れた形跡はない。実は、WindowsなどのOSでは、あらかじめ世界の主だったルートCAの証明書がインストールされている。

コラム:電子証明書のみかた

(クリックすると大きな画像が表示されます。)

 インターネットエクスプローラの場合、

「ツール」→「インターネットオプション」→「コンテンツ」→「証明書」→「信頼されたルート証明機関」

で、証明書の一覧および詳細を見ることができる。

2-5 サーバ認証とクライアント認証

このようにクライアントがサーバの電子証明書を認証することを「サーバ認証」と呼ぶ。
 このあと、オプションでサーバはクライアントに対して、クライアントの電子証明書を要求することができる。要求されるとクライアントはサーバにクライアントの電子証明書を送付し、サーバはクライアントの電子証明書を検証する。
 これを「サーバ・クライアント認証」と呼ぶ。
 この例ではクライアントの電子証明書を要求していない。SSLでは、「サーバ認証」は必須だが「サーバ・クライアント認証」は必須ではない。
 現在、一般的なショッピングサイトでは「サーバ認証」のみが主流だが、国や地方自治体への申請、多額の取引や重要なデータのやり取りなどでは「サーバ・クライアント認証」が用いられている。

2-6 セッション鍵の生成

このあといよいよ、実際にデータのやり取りが始まるのだが、データのやり取りを、このまま公開鍵暗号方式で行うと、暗号化、復号に非常に時間がかかってしまう。したがって、データのやり取りは、共通鍵暗号方式で行う。そのため、サーバ、クライアント双方に同じ鍵を持たなければならない。
 そこで、サーバ証明書の検証後、クライアントはプレマスタシークレットキーという、セッション鍵の元となるデータを生成したのち、パケット5で受け取ったサーバ証明書に含まれる「サ公」で暗号化する。

パケット6 Client Key Exchange

「サ公」で暗号化されたプレマスタシークレットキーをサーバに送る。暗号化されているので、盗聴されても解読できない。
 クライアントは、クライアント乱数、パケット5で受け取ったサーバ乱数、プレマスタシークレットキーの3つで、セッション鍵(共有鍵)を生成する。
 サーバは、サーバ乱数、パケット4で受け取ったクライアント乱数、プレマスタシークレットキーの3つで、セッション鍵(共有鍵)を生成する。
 DH法(Diffie-Hellman鍵交換)により、クライアント、サーバ双方に同じセッション鍵が生成される。

コラム:共通鍵は2つ?
 SSLではセッション鍵を2つ生成する。
 共通鍵暗号方式の定義では、「暗号化する鍵と復号する鍵が同一」となっているのに、どうして異なる2つの鍵を作るのだろうか。

 ここに2つの鍵X、Yがあるとしよう。

 クライアント  鍵X   で暗号化      →     サーバ       鍵X   で復号

 サーバ     鍵Y   で暗号化      →     クライアント    鍵Y   で復号

 つまり、あくまでも「暗号化する鍵と復号する鍵が同一」ではあるが、上り、下りで異なる鍵を使っている。したがって、2つの鍵が必要となる。
パケット7 Change Cipher Spec + Finished

サーバは、暗号化通信の準備が完了したことをクライアントに伝える。

パケット8、9

共通鍵暗号方式でデータの暗号化通信が行われる。
 Ethernetヘッダ IPヘッダ TCPヘッダ までは平文だが、データ部は暗号化されているのでパケットキャプチャのASCII部分では読み取ることができない。

3 電子証明書を取得するには

電子証明書は、CAをビジネスとしている団体企業などから有償で取得することができる。前述のとおりWindowsなどのOSでは、OSの作成元が信頼しているルートCAの証明書があらかじめインストールされている。
 一般的なWebサービスの利用の際には、そういったルート認証局の配下にある認証局が発行したサーバ証明書であれば、ユーザは意識することなくサーバから受け取ったサーバ証明書の検証ができる。
 しかし、政府認証基盤(GPKI)で会計申告、電子入札などを利用する場合、ルート証明書があらかじめインストールされていないことが多い。そのため、ユーザは前もってルートCAの電子証明書を信頼できる手段で手にしておく必要がある。
 相手が提示した電子証明書が信用できるかどうかは、ユーザが発行元のCAを確認し、さらにそのCAを認証している上位のCAを確認するというように、ルートCAまで辿っていき、最終的に自分の手元にあるルート証明書に一致するルートCAにたどり着くことができれば、信頼できると確認できる。
 民間CAのほとんどは商用であるため、電子証明書の交付を受けるには費用がかかる。Webサイトなどの中には、自らがルートCAとなって証明書を発行し、暗号化通信を行うサイトもある。この場合はルート証明書があらかじめインストールされていないことが多いため、GPKI同様ユーザ自身が電子証明書を確認する必要がある。
 電子証明書を発行するソフトもある。自己で電子証明書の管理運用をすることができるが、発行手続きのみならず、有効期間の確認、失効手続きなどの負荷がともなうとともに、CAの秘密鍵が漏洩することなどによって偽の電子証明書が発行されるなど、システム全体のセキュリティが失われてしまうリスクも負うことになる。

【次回予告】
情報セキュリティの技術的対策の1つに、ファイアウォールがある。ファイアウォールは単に、許可されたパケットを通過させ、禁止されているパケットを遮断するだけである。それに対してIDSは、不正侵入を検出し、何らかの方法で管理者に通知する機能を持つ。更にIPSは不正侵入に対して自動的に防御する機能を備えている。いち早く不正侵入を検出し、適切に対応することで被害を最小限に抑えることができる。次回は、IDS/IPSの分類、侵入の検出方法などについて説明する。

取材協力 : アイテック

掲載日:2009年12月24日

キーマンズネット

出典元:株式会社リクルート キーマンズネット 2009年11月10日掲載分

検索

このページの先頭へ