ＰＫＩにおける認証局の研究

ネットワークシステム研究室
指導教員：坂本　直志　助教授
02KC073：高須　直人

目次

１章

２章

３章

４章

付録

参考文献

１章

１．１　はじめに

　近年、インターネットやIT技術が急速に発展、普及しており、今や情報通信社会のインフラとして定着している。インターネットによる情報発信や情報検索、情報交換は、日常生活に不可欠なツールとして、これまでのメディアとは異なる様々な価値ある情報資源を生み出しつつある。インターネットは、時間と距離という物理的な制約を超越した新しい社会を生み出している。 しかしながら、この利便性の発展普及の裏で、悪意のある第三者によるウイルス攻撃やWebページの改ざん、通信の盗聴による情報漏洩など様々な脅威や弊害も増えてきている。便利なツールであるが故に、使い方次第によって弊害にもなりうるということである。 今後、ますますインターネットが生活の中に溶け込み、電子社会が日常化する中で、インターネットは新しい段階に入っていかなければならない。これからは、利便性を求めながらも安全性を最大限配慮することが不可欠となるであろう。インターネットを安心して信頼して利用するためにも、今後、暗号通信だけでなく、公開鍵証明書を利用した確実な個人認証に基づく通信が行われることが必須となる。 国としても、ｅ−Ｊａｐａｎ構想に基づく電子政府を実現するための認証基盤である、ＧＰＫＩ（Government Public Key Infrastructure：政府認証基盤）やＬＧＰＫＩ（Local Government Public Key Infrastructure：自治体認証基盤）の普及を進めている。また、２００１年には電子署名法が施行されたことによって、インターネット上で公的文書や契約書の法的な根拠が明らかになったことなど、電子政府や電子社会の基盤が整いつつある。 現状では、運用する側にも利用する側にも、まだ知識や意識などで至らない点も多く、ＰＫＩ（Public Key Infrastructure：公開鍵基盤）が一般に普及しているとは言い難い。将来的に、国民全てが安全に利用できるようにするためにも、ＰＫＩの利用推進に関しての研究や啓蒙を行う活動が必要となってくる。

　本研究では、PKIに利用される様々な技術の中から、基本的な部分について、暗号技術や電子署名、認証基盤について、またPKI技術の利用などについて述べる。さらに、その中でも認証局の運用について掘り下げ、問題点や改善点などを述べる。

２章

２．１　ＰＫＩ（Public Key Infrastructure：公開鍵基盤）

２．１．１　ＰＫＩとは

　インターネットの急速な普及に伴い、個人情報や取引情報などの重要な情報がネットワークを流れる状況も増えている。その一方で、以下に示す様々な問題が発生し、健全なインターネットの発展に陰を落としている。

・「クラッキング」：
　悪意を持ってネットワークやシステムに外部から進入し、データやプログラムを盗聴、改ざん、破壊する行為。最近では不正アクセスの意で使われることが多い。
・「ウイルス」：
　コンピュータに勝手に入り込み、悪さをするプログラム。画面表示をでたらめにしたり無意味な表示をするものから、データを破壊したり勝手にメールを送信して自分のコピーを増殖させるものまで多種多様なウイルスが存在する。インターネット上のダウンロードファイルや他人からもらったファイルによって感染する。
・「盗聴」：
　コンピュータ内もしくは通信路上のデータの内容を盗み見る行為。通信をしている者にとっては直接的な被害はないが、秘密情報や個人情報などが外部に漏れてしまう。
・「改ざん」：
　コンピュータ内もしくは通信路上のデータの内容を管理者の許可を得ずに書き換える行為。電子データは改ざんの跡が残らないため、改ざんされたデータを見た人はそれが正規のデータか否かを判別できない。
・「なりすまし」：
　他人のＩＤやパスワードを盗用し、その人のふりをして活動すること。本来その人しか見ることができない情報を盗み出したり、働いた悪事をその人のせいにしたりする。
・「否認（事後否認）」：
　通信の当事者間（送信者と受信者）がやりとりそのものを否認すること。つまり、送信者あるいは受信者が後になってその事実を否定したり、内容が改ざんされたと主張すること。

　PKIとは公開鍵暗号を利用したシステムであり、公開鍵の特徴を活かして、上記の問題のうちいくつかの問題を解決する方法として注目されている。

　公開鍵暗号では、データの暗号化と復号で異なる鍵を用いる非対称鍵を利用するため、安全に鍵の受け渡しや管理ができるため、この鍵を利用した暗号通信によって「盗聴」を防ぐことができる。また、誰にも知られていない秘密鍵を利用してデータの暗号化を行うことで、「否認」の防止や「改ざん」のチェックに利用できる電子署名としての役割も果たす。さらにこの秘密鍵を、認証局という第３者機関に登録することで、秘密鍵の所有者の証明が行う事ができ、「なりすまし」を防ぐ通信相手の認証が行える。

　このように、公開鍵を中心とした様々なセキュリティ技術を組み合わせることで、社会に広がるインターネットでの取引などを、安全に、有効に活用するためのシステムがPKIである。

２．１．２　暗号技術

　通信文などのデータ（平文）を、第三者にとって意味のないデータ（暗号文）に変換することで、通信の当事者以外にとってデータの有用性を失わせるために、暗号技術を利用する。

　暗号方式として、大きく分けて「共通鍵暗号方式」と「公開鍵暗号方式」の２つがある。以下の節ではそれぞれの暗号方式の特徴を述べる。それぞれに利点と欠点があり、一般的に両方の暗号方式を組み合わせたハイブリッド暗号方式を用いることが多い。

２．１．２．１　共通鍵暗号方式

　共通鍵暗号方式とは、暗号化と復号で同一の鍵を利用する暗号方式である。

　この方式を使った単純な暗号であるシーザー暗号（Caesar cipher）を例に説明する。シーザー暗号とは、紀元前１００年頃に生まれ活躍した武将のジュリアス・シーザーが使っていたと言われる暗号である。アルゴリズムは単純で、平文で使われているアルファベットを、一定の文字数だけずらすことによって暗号化を行う。このずらす文字数がシーザー暗号の鍵となる。この暗号文を受信したら、同じ鍵の文字数だけ逆にずらせば元の平文に復号できる。

＜ｅｘ．シーザー暗号＞
　鍵「３」

　平文　　ｔ　ａ　ｋ　ａ　ｓ　ｕ
　　　　　│　│　│　│　│　│　
　　　　　└┐└┐└┐└┐└┐└┐　　暗号化・・・３文字分右へずらす
　　　　　　↓　↓　↓　↓　↓　↓
　暗号文　　ｗ　ｄ　ｎ　ｄ　ｖ　ｘ
　　　　　　│　│　│　│　│　│　
　　　　　┌┘┌┘┌┘┌┘┌┘┌┘　　復号　・・・３文字分左へずらす
　　　　　↓　↓　↓　↓　↓　↓
　平文　　ｔ　ａ　ｋ　ａ　ｓ　ｕ

　もちろんこの単純なシーザー暗号がそのままコンピュータの世界で使われているわけではないが、この考え方が、共通鍵暗号方式の基礎となっている。つまり、共通鍵暗号方式とは、暗号化の際に行われる手順と全く逆の手順を行うことで復号することができる暗号方式である。

　実際にコンピュータ上では、データはすべて０か１のビット列で処理される。ビット列の演算にはXOR(exclusive or：排他的論理和)を利用する。これはかけ合わせる２つのビットの値が同じであれば０を、異なれば１を返す計算である。これを用いた暗号化処理は次のようになる。

＜ｅｘ．XOR＞
　鍵「１０１０１０１０」

　平文　　　　０１００１１００
　鍵　　XOR 　１０１０１０１０
────────────────　暗号化
　暗号文　　　１１１００１１０

　鍵　　XOR 　１０１０１０１０
────────────────　復号
　平文　　　　０１００１１００

　このような単純な処理を複雑に混ぜ合わせることで実用的な共通鍵暗号が成り立つ。しかし、コンピュータ上でこの共通鍵を送り手が受け手に渡す方法が問題となる。鍵を他人に知られた場合、暗号文を盗聴することも、変更することも、偽造することも可能になってしまうことにくわえ、鍵をコピーすることも容易にできてしまう。そうなると、この鍵を使ったその後の暗号通信は暗号の意味をなさなくなってしまう。鍵を送らなければならないのに、鍵を送ってはいけない。このジレンマが共通鍵暗号における鍵配送問題である。これらの問題を防ぐためにも、細心の注意を払った鍵の受け渡しや、共通鍵の有効期限について厳密な運用が必要である。

２．１．２．２　公開鍵暗号方式

　公開鍵暗号方式とは、共通鍵暗号に対し、暗号化と復号で異なる鍵を利用する暗号方式であり、共通鍵暗号方式における鍵配送問題を解決するために考案された。

　共通鍵暗号と異なり、暗号化の逆の手順を行っても復号できない一方向性関数を用いることによって、片方の鍵（公開鍵）からもう一方の鍵（秘密鍵）が容易に連想されないように構成されている。

　公開鍵暗号では、１人が一対の公開鍵と秘密鍵を生成し、公開鍵を公開し、秘密鍵は本人が保持する形式をとっている。公開鍵は誰でも入手出来るので、誰にでも暗号化は出来るが、それを復号するためには対となる秘密鍵が必要になるため、秘密鍵の持ち主にしか容易に復号することは出来ないことになる。ただし、膨大な時間をかければ公開鍵から関数表をつくり、対応する秘密鍵を作ることも可能となるため、原理的に解読不能にはできない。

公開鍵暗号方式
図１　公開鍵暗号方式

　公開鍵暗号には次のような特徴がある。

鍵の配送が容易である。
　共通鍵暗号方式に対し、公開鍵暗号方式では暗号化のための鍵は一般に公開しても問題ない。そのため、共通鍵の共有時に問題となる、鍵を送らなければならないのに送ってはいけないという鍵配送のジレンマを解決することが出来る。
秘密に保持する鍵の種類が少ないため、鍵の管理がしやすい。
　共通鍵暗号では、盗聴されないためにも全ての鍵が異なる必要がある。また、通信以前に鍵を保持している必要があるため、通信相手が増えるに従い秘密に保持する共通鍵の量が増大していく。一方、公開鍵暗号では、秘密鍵さえ異なれば盗聴される心配はないため、本人の秘密鍵１つだけを秘密に保持し、暗号通信するときに通信相手の公開鍵を参照して暗号化すればよい。
秘密に保持する鍵の管理
図２　秘密に保持する鍵の管理
　図のように、共通鍵では通信相手の数だけ別の鍵を用意しなければならないため、ｎ人で通信を行う場合、ｎＣ２個、すなわち、ｎ(ｎ−１)／２個の鍵が必要となる。一方公開鍵では、それぞれが秘密鍵と公開鍵を用意すればよく、その数は２ｎ個となる。さらには秘密に保持する必要があるのはｎ個だけとなる。
　この差は通信を行う人数が増えれば増えるほど大きくなっていくため、大規模ネットワークでの実用を考えると公開鍵暗号方式による鍵管理の有用性は大きい。
安全な認証機能（電子署名）がある。
　RSAやElGamal暗号などは、公開鍵と秘密鍵を逆に使って暗号化しても正しく復号出来るという鍵同士の交換則を満たすプロトコルである。これらのプロトコルでは、秘密鍵で暗号化し公開鍵で復号するという通常の暗号化と逆の手順を踏むことで、送られてきた暗号文が間違いなく送信者本人が送ったものであることを証明できる機能を持っている。本人しか持っていない秘密鍵で暗号化した証明文を送り、対となる公開鍵で復号することで間違いなく本人であることが確認できる。この電子署名については、２．１．３．１節で詳しく説明する。
暗号化速度が遅い。
　共通鍵暗号方式は、ビット毎に並列に計算が可能なため回路化が容易である。一方公開鍵暗号方式は、素因数分解や離散対数問題など、現在簡単な解き方が知られていない数学の演算の困難性を利用していることにくわえ、これらの演算（加算や乗算）はビット毎の並列処理は難しい。このため計算量が多くなり、共通鍵暗号方式に比べて暗号化処理に時間がかかってしまう。つまり、暗号文全てにたいして公開鍵暗号を適用するのは得策ではない。現在では、鍵配送を公開鍵暗号で行い、暗号文自体には共通鍵暗号を使うというようなハイブリッド暗号が広く利用されている。

　以下に公開鍵暗号を利用したアルゴリズムとして代表的なものを挙げる。

表１　代表的な公開鍵暗号アルゴリズム
アルゴリズム 安全性の根拠
RSA 素因数分解の困難性を利用
RABIN
ElGamal 離散対数問題の困難性を利用
Diffie-Hellman
ESIGN
DSA
ECDSA 楕円離散対数問題の困難性を利用

２．１．２．３　一方向性ハッシュ関数

　ハッシュとは、巨大なデータから、そのデータを代表する小さなデータを「ダイジェスト（ハッシュ値）」として生成する操作、またはそのような値を得るための関数（ハッシュ関数）の事を言う。
　例えば、ハッシュとして「５字おきに字を拾いその列を並べたものをハッシュ値とする」という操作を行うと、このハッシュによって元の文書を１／５に圧縮することが出来る。しかし、
○うまく適当な文字を入れて、別の文書を作ることが出来る。
○間の文字を推測して元の文書を復元できてしまうこともある。
○短い定型的な文章では、多数の文書から同じダイジェストが出来てしまうことがあり得る（コリジョン）。
○文章が１万字あれば、ダイジェストだけでも２千字になってしまう。
などの問題がおこる。

　ハッシュ関数は、理想的には、異なったデータからは常に異なったハッシュ値が得られること（完全ハッシュ関数）が望ましいが、実際には不可能である。そこで実用上のハッシュ関数では、次のような要件を満たす必要がある。

　これらの要件を満たすハッシュ関数によって求められるハッシュ値は次のような性質を持つ。

　暗号で使われるハッシュ関数には、さらに一方向関数の持つ性質も持たせている。一方向関数とは、引数から結果を求めるのは簡単だが、結果から引数を求めることは難しいような関数である。

　これらのことにより、一方向性ハッシュ関数は次のような性質を持つように設計されている。

  1. 元のデータをx、一方向性ハッシュ関数をh()としたときに、h(x)からもとのxが復元できるようなxに関するいかなる情報も得ることが困難である。そのため、得られたダイジェストから同じダイジェストを持つ平文を作ることが困難である。
  2. ハッシュ値が同一となる異なる２つのメッセージを見つけることが困難である。（コリジョンフリー）

　一方向性ハッシュ関数は、改ざん検出や、認証、署名など、PKIをさせるベース技術のひとつとして広く使われている。現在最も多く使われている一方向性ハッシュ関数としては次のようなアルゴリズムがある。

MD5(Message Digest)
　MD5とは、RSA社によって開発された128bitのダイジェストを生成するハッシュアルゴリズムである。コンピュータ上で計算しやすいように最適化されている。
SHA-1(Secure Hash Algorism)
　SHA-1とは、NISTによって標準化された160bitのダイジェストを生成するハッシュアルゴリズムである。コンピュータ上で計算しやすいように最適化されている。

※　MD5やSHA-1には、同じハッシュ値を持つ２つの平文を作り出せること（コリジョン）が発見されていることや、データ列の中のあるビットの値を変更してもそれが最終的なハッシュ値に影響を与えない「Neutral Bit」と呼ばれるビットが存在する可能性があることが、2005年5月に発表されている。


２．１．２．４　MAC(Message Authentication Codes：メッセージ認証コード)

　MACとは、メッセージの発信者によって作られ、通信中は平文メッセージに付加されるデータである。このMAC値によってメッセージの完全性（改ざんされていないかどうか）をチェックすることができる。

　メッセージを受け取ったときに、受取人はメッセージからMAC値を再生成し、２つのMAC値の一致を確認することで、改ざんの検出を行う。

２．１．３　電子署名

２．１．３．１　電子署名

　電子署名とは、電子化された文書の内容を勝手に複製したり改ざんしたりする行為を防ぐための技術のひとつである。電子署名を用いると、文書の改ざんの検出と、発行者の認証を行うことができる。技術的には公開鍵暗号方式を利用して実現している。


署名の手順
  1. 署名する対象文書のハッシュ値を計算する。（ここで、ハッシュ値とは、一方向性ハッシュ関数による出力値）
  2. このハッシュ値を公開鍵暗号方式での作成者の秘密鍵で暗号化し、署名データとする。
  3. 元の文書と署名を組み合わせて、署名付き文書データとして扱う。
検証の手順
  1. 署名時と同様の方法で文書のハッシュ値を計算する。
  2. 文書に対する署名データを、作成者の公開鍵で復号し、先ほど計算したハッシュ値と比較する。
  3. 比較の結果、同じ値であれば、署名者の作成した文書といえる。
電子署名
図３　電子署名

２．１．３．２　電子署名法

　電子署名法とは、電子署名を利用するうえでの法制度である。アメリカの各州に続き、日本でも「電子署名及び認証業務に関する法律」（通称：電子署名法）が2000年5月に公布、翌年2001年4月から施行された。

　法律上の「電子署名」の定義は次のようになっている。

　従来における電子署名技術の中心は公開鍵暗号を利用したものであったが、この法律では、今後の技術発展により新たな技術が実用化された場合にも対応できるよう、公開鍵暗号技術に限定せず技術的中立性を保つ観点から電子署名が果たすべき機能について定義している。

＜電子署名法の概要＞

２．１．４　認証基盤

２．１．４．１　電子認証局

　公開鍵暗号方式では２つの鍵、すなわち「秘密鍵」と「公開鍵」を利用して電子署名や暗号化に利用する。このうち、公開鍵は、誰でも入手でき、鍵の持ち主に向けて暗号文を送ることができるが、ここで問題になるのが、入手した公開鍵が本当に当人のものであるかをどのように検証するかである。公開鍵基盤では、電子認証局という信頼できる組織を介して公開鍵の本人認証を次のように行う。公開鍵を公開する人は、信頼できる認証局（CA：Certification Authority）に公開鍵の登録を行い、その証明書とともに公開鍵を公開する。このようにして、公開鍵を利用する人は、公開鍵の所有者が真に通信の相手先であることを確認できる。

　CAは、公開鍵の証明とともに、証明書の有効期限や破棄状態を把握し、利用者に提供する働きもある。

　電子認証基盤においてCAは大きな役割を果たすため、CAの信頼性が重要となる。

　　　　　　　　　　　　　　　　　　　　　　　 　 　┌────┐
　　　　　　　　　　　　　　　　　　　　　　 　 　　│ルートCA│
　　　　　　　　　　　　　　　　　　　　　  　　　　└────┘
　　　　　　　　 　　　┌────────────────┼────・・・───┐
　　　　　　　　　┌────┐　　　　　　　　　　　┌────┐　　　　　┌────┐
　　　　　　　　　│中間CA　│　　　　　　　　　　　│中間CA　│　　　　　│中間CA　│
　　　　　　　　　└────┘　　　　　　　　　　　└────┘　　　　　└────┘
　 　　┌───────┼───・・・────┐　　　　　├────┐┌────┼────┐
┌──────┐┌──────┐　　　┌──────┐
│エンド　　　││エンド　　　│　　　│エンド　　　│
│エンティティ││エンティティ│・・・│エンティティ│　　・・・　　　　　　　　　　 ・・・
└──────┘└──────┘　　　└──────┘

エンドエンティティ：証明書を発行される人物や機器
図４　CAの階層構造

　CAは図のように階層構造にすることが可能なので、ユーザの発行したCAは上位CAの証明書を持っていて、それによって信用されている場合もある。

　これは、得られたルートCAが信頼できる場合、残るCAおよび階層内のいかなるCAが発行した証明書も信頼できる、という前提のもとに成り立っている。

　ルートCAとは、世界でただ１つ存在するものではない。現状では、商用で証明書を発行している企業が多くあるが、これらの企業は、それぞれが階層のトップであるCAを立てている。日本では、日本ベリサインやエントラストジャパン、ビートラステッド・ジャパンなどの企業が一般向けに証明書発行サービスを行っている。

　現状広く使われているWebブラウザには、初めから大手の商用CAのルート証明書がインストールされている。例えばInternetExplorer6.0では、［ツール］→［インターネットオプション］→［コンテンツ］→［証明書］とたどることで、ブラウザにインストールされている証明書を確認できる。

　CAにはパブリックCAとプライベートCAがある。

　これらの階層構造のルートCAが異なる階層のルートCAと相互認証している場合もある。これらのルートCAを仮にCA1とCA2とすると、それぞれがお互いに証明書を発行することにより、CA1から証明書を発行されたユーザと、CA2から証明書を発行されたユーザの認証が相互で行うことが可能となる。
　日本政府が進めている政府認証基盤（GPKI）では、これを応用し、各行政機関のCA間にブリッジCAという認証局を置くことでそれぞれのCAの相互認証を行っている。ただし、これらのCAは、パブリックCAの認証を受けていないいわゆるプライベートCAとなるため、ブラウザには証明書がインストールされていない。安全に利用するためには、安全な経路で手に入れた認証局の証明書を、ブラウザにインストールする必要がある。

　　　　　　　　　　　　　　　　┌────┐　　　　　　　　　　　┌────┐
　　　　　　　　　　　　　　　　│省庁CA１│　　　　　　　　　　　│民間CA２│
　　　　　　　　　　　　　　　　└────┘　──┐　　　┌──　└────┘
　　　　　　　　　　　　　　　　　　　　↑　　　　↓　　　↓　　　　↑
　　　　　　　　　　　　　　　　　　　　└──　┌─────┐　──┘
　　　　　　　　　　　　　　　　　　　　 　 　　│ブリッジCA│
　　　　　　　　　　　　　　　　　　　  ┌──　└─────┘　──┐
　　　　　　　　　　　　　　　　　　　　↓　　　　↑　　　↑　　　　↓
　　　　　　　　　　　　　　　　┌────┐　──┘　　　└──　┌────┐
　　　　　　　　　　　　　　　　│省庁CA２│　　　　　　　　　　　│民間CA１│
　　　　　　　　　　　　　　　　└────┘　　　　　　　　　　　└────┘
図５　ブリッジCA

２．１．４．２　公開鍵証明書

　CAによって発行され、利用者の公開鍵を認証するために用いる。現在もっともよく利用されている方式は、ITU-T （国際電気通信連合）で定義されたX.509証明書である。X.509証明書は、名前・メールアドレスなどのユーザの本人情報、公開鍵とそのアルゴリズムなど、証明書情報などと、これら全てを認証局の秘密鍵で暗号化したCAによる署名から構成されている。

２．１．５　ＰＫＩの用途

２．１．５．１　インターネット上の商取引

　近年大きな広がりを見せるインターネット上でのショッピングやバンキングでのセキュリティ確保にもPKI技術は欠かせない。SSL（２．２．１）を利用し、暗号通信路を確保した上で、購入情報や送り先などの個人情報、決済に利用するカード情報などのやりとりを行う。また、インターネットショッピングにおいては、サーバ証明書による認証を行うことで、その店舗が実際に信頼出来る店舗であることを確認している。インターネットバンキングにおいては、より高いレベルのセキュリティが必要となり、サーバ認証の他にも利用者確認用でクライアント認証も行い（サーバ・クライアント相互認証）、利用者と事業者双方の信頼を結ぶほか、暗号強度を増した暗号鍵を利用するなどの対策がなされている。
　またインターネットショッピングを初めとして、リアルな世界でも使われ始めた電子マネーにも、PKIを利用したセキュリティ技術が導入されている。

２．１．５．２　企業内ネットワークへのアクセス制御

　電子証明書を利用した応用例として、ネットワークへのアクセス制御がある。ＩＣカードに個人の電子証明書を格納することで、企業内のクライアントＰＣへのログイン制御、ネットワークやネットワーク上で稼働する各種サービスへのアクセス制御を実現することができる。
　また、電子証明書の個人情報を利用することにより、サービスのきめ細やかな機能展開が可能になり、個人ごとのメニューや利用できる機能の制御などを実現することが容易になる。

２．１．５．３　電子公証システム

　電子商取引を確実に実施するために必要な第三者による電子文書の原本性と日付を保証するためのシステムである。これにより、事実否認や内容の改ざんといった不正行為を防止することができる。
　電子公証システムでは、原本性を保証するために、文書と署名を合わせたフィンガープリント（データとデータのハッシュ値）を、日付が確定できる媒体を利用して公開することにより、原本性と日付を保証するシステムを構成する。

２．１．５．４　企業間取引

　インターネットショッピングのシステムの発展系として、企業間の電子商取引を支援するシステムへの応用がある。このシステムでは、取引の一連の工程を管理することが可能になり、業務効率の向上に高い効果が期待される。PKIの利用としてはインターネットバンキングと同様にSSLによるサーバ・クライアント相互認証機能に加え、ワークフローの機能やデータベース機能を加味した実践的なシステムとなっている。また取引内容のデータの保管など、より厳しい認証機能を有する必要がある。

２．１．５．５　電子申請

　行政上の手続きをインターネット上で行えるようにするシステムとして、現在国をあげて取り組んでいる。
　申請者は作成した公開鍵を自分の個人情報と一緒に申請し、証明書を発行してもらう。その証明書を利用した認証基盤を利用することによって、役所に行かなくても行政手続きが行えるようになる。
　システムとしては通常の認証基盤とは異なり、各省庁に設けられた政府独自の認証局をブリッジCAで結ぶことに相互認証による安全性がうたわれている。
　住民基本台帳ネットワークを筆頭に運用が開始されてからかなり経つが、申請時の手続きの煩雑さや利用時に専用のICカードリーダーが必要になるなど気軽に使えるとは言い難いため、あまり普及していない。

２．２　ＰＫＩを利用したシステム

２．２．１　ＳＳＬ(Secure Socket Layer)／ＴＬＳ(Transport Layer Security)

　SSLとは、共通鍵暗号、公開鍵暗号、MAC、デジタル署名などの暗号技術が組み合わされた暗号プロトコルである。OSI参照モデルにおけるセッション層で機能するプロトコルのため、アプリケーションに依存せず、HTTPだけでなくFTPやPOP3などにも柔軟性の高い実装が可能となっている。

　SSLとTLSの間に互換性はないものの、TLSがSSLを改良して作られたものなので、動作はほぼ同じである。SSLはNetscape社によって開発されたアプリケーションで、現在ではバージョン３が最新である。このバージョン３をもとに改良が加えられたのがTLSであり、IETF(the Internet Engineering Task Force)によって標準化されている。

　主な用途としては、HTTPS(HTTP over SSL)が一般的である。ユーザはURLやブラウザ上に表示される鍵マークなどから、SSL処理が行われていることを確認できる。サーバ上では、URLによってしようするポート番号を区別し、それぞれの処理を行う。

ＳＳＬ
図６　SSL

　SSLの信頼性は、インターネットにおけるセキュリティ要件である、次の３つの機能を含んでいるところにある。

２．２．２　ＳＳＨ(Secure SHell)

　SSHとは、OSI参照モデルのアプリケーション層で暗号化通信を行うためのプロトコルである。UNIX系のOSで使用されている遠隔操作系のプログラム（rlogin, ftp, telnet,...）は通信データがネットワーク上にそのまま送出されるため、その代わりに安全な通信を可能とするツールとして開発された。SSLと同様に、認証、かぎ配送には公開鍵暗号方式、暗号通信には共通鍵暗号方式、といったハイブリッドシステムを採用することにより、通信データの盗聴や改ざんを防ぐことが出来る。

　SSHプロトコルは、バージョン１(SSH1)とバージョン２(SSH2)の２つがあるが、その間には互換性がない。SSH1は標準化の認定が行われていないため、1.3や1.5といった派生バージョンが存在し、いくつかの脆弱性も指摘されている。一方SSH2に関しては、IETFのワーキンググループで標準化作業が進められている。

２．２．３　Ｓ／ＭＩＭＥ(Secure Multipurpose Internet Mail Extensions)

　電子メールでは、一般にSMTP(Simple Mail Transfer Protocol)という技術を使用しているが、これは「改ざん」「盗聴」「なりすまし」などにたいして無防備であるため、重要文書などの送受信は暗号化などの対策を施す必要がある。このような問題を解消する目的に開発されたのが、このS/MIMEである。

２．２．４　ＰＧＰ(Pretty Good Privacy)

　PGPとは、共通鍵暗号や公開鍵暗号を利用し、単体でデータの暗号化や電子署名などの機能を備えている汎用性の高い暗号化ソフトウェアである。ファイルの暗号化・復号化、署名・検証が可能であり、生成した暗号文はテキスト文書として出力されるため、電子メールに暗号文を添付することで、メールの内容の暗号化や本人認証を可能にする。「信頼の輪」と呼ばれる認証モデルを利用しており認証局を必要としないため、運用面での手軽さが受け世界中で普及している。
　最近では、ディスク全体の暗号化やVPN(Virtual Private Network)の実現にも利用される。

３章

３．１　パブリック認証局

　証明書を発行・管理する認証局のシステムは、2.1.4.1でも述べたように、ルートCAと呼ばれる組織の下に中間CA（サブCA）という組織があり、さらにその下に・・・と言うように階層構造になっている。このルートCAは一本化されておらず、インターネットの一般的なサイト認証に使えるルートCAはいくつも存在する。

　ルートCAでないCAは、それぞれ上位のCAによって証明書が発行されているが、階層の一番上に位置するルートCAは自分自身によって証明書を発行している。このルートCAをどのように信用するか？という問題が認証局を運用する上でもっとも重要となってくる。

　ベリサインなどの商用の認証局を持っている企業は、特定の組織などの境界に関係なく一般大衆に対して証明書を発行している。これらの認証局をパブリック認証局(Public CA)と言う。パブリック認証局となるには、運用方法や管理方法など厳しい規定があり、それをクリアする必要がある。この審査には莫大な費用や期間が必要となるため、簡単にはパブリック認証局を立てることはできない。そこで、パブリック認証局であるベリサインなどの商用認証局によって認証を得ることで、パブリック認証局と同等に信頼のできる認証局となることができる。ベリサインなどのパブリック認証局のルート証明書は、InternetExplorerなどの主要なブラウザにはあらかじめインストールされているので、パブリック認証局から認証を受けているサイトは信頼することができる。

３．２　プライベート認証局

　パブリック認証局をルートCAとして使えない、もしくは使わない場合もある。パブリック認証局の認証を受ける際にも、証明書の発行や更新などにも費用がかかるなど、誰でも手軽に証明書の発行をうけられるというわけにはいかない。

　そこで、自分でルートCAを立てて、独自の認証の階層を作ることができる。これをプライベート認証局(Private CA)という。認証局を立てるためのソフトウェアとしてOpenSSLなどのフリーソフトが存在するため、構築するだけなら、パブリック認証局の認証を受けるのに比べ非常に安価に認証局を構築することができる。

　パブリック認証局の証明書と異なり、ブラウザにルート証明書が登録されていないため、利用するためには、各ブラウザに証明書をインストールする必要がある。

３．２．１　プライベート認証局の構築

　研究室内のサーバsrv.net.c.dendai.ac.jp内で、apacheとOpenSSLを利用したプライベート認証局の構築を行う。

＜CAの構築＞
　CAの構築場所として、ディレクトリを作成する。以下特筆しないかぎりこのディレクトリ下で作業を行う。　
/usr/local/CA
　OpenSSLのインストールされているディレクトリ（/usr/lib/ssl/misc/）に入っているCA.shをCA構築ディレクトリにコピーし、編集する。

・CA.sh の以下の行を修正する。
--------------------------------------------------------------------------------
CATOP=/usr/local/CA　　　　←CAの構築場所を指定
CAKEY=cakey.pem　　　　←CAの秘密鍵ファイル名
CACERT=cacert.pem　　　　←CAの証明書ファイル名
--------------------------------------------------------------------------------

・OpenSSLの設定ファイル（/etc/ssl/openssl.cnf）も同様にCAの構築場所をを修正する。
--------------------------------------------------------------------------------
[ CA_default ]
dir = /usr/local/CA
--------------------------------------------------------------------------------

・CAの構築を行う。
　./CA.sh -newca
--------------------------------------------------------------------------------
CA certificate filename (or enter to create)

Enter PEM pass phrase:******　　　　←証明書のパスフレーズを入力
Verifying - Enter PEM pass phrase:******　　　　←証明書のパスフレーズの確認入力
Country Name (2 letter code)[AU]:JP　　　　←国名
State or Province Name (full name)[Some-State]:Tokyo　　　　←都道府県名
Location Name (eg,city)[]:Chiyoda　　　　←組織の本拠地の市区町村名
Organization Name (eg,company)[Internet Widgits Pty Ltd]:TDU　　　　←組織名
Organization Unit Name (eg,section)[]:netlab　　　←部署名
Common Name (eg,YOUR name)[]:srv.net.c.dendai.ac.jp　　　　←サーバのホスト名
Email Address[]:02kc073@ed.cck.dendai.ac.jp　　　　←連絡先E-Mailアドレス
--------------------------------------------------------------------------------

　これで /usr/local/CA/ 以下に必要なファイルが作成され、CAの作成は終了。
cacert.pem　　　　＝認証機関の証明書
private/cakey.pem　　　　＝認証機関の秘密鍵

　作成した証明書は以下のコマンドで内容の確認が出来る。
openssl x509 -in cacert.pem -text

３．２．２　証明書の発行

＜サーバの秘密鍵と署名要求書の作成＞
　サーバの作業を行うための場所として、ディレクトリを作成する。サーバの作業はこのディレクトリ下で行う。
/usr/local/SERVER
また、このディレクトリへの、アクセス権限を変更する。
chmod 600 /usr/local/SERVER　　　　←アクセス権限の変更
この変更により、このディレクトリに対しては所有者のみが読み込みと書き込みが行えるようになった。

・サーバの秘密鍵を作成する。
openssl genrsa -des3 -out server.key 1024
パスフレーズを入力する必要があるので、任意に設定する。
これで、1024ビットの鍵長を持つサーバの秘密鍵、server.keyが作成された。

秘密鍵の作成
図７　秘密鍵の作成

・CAへの署名要求書(csr)を作成する。
openssl req -new -days 365 -key server.key -out csr.pem
＊今回のように同一ホストの事故認証曲を利用する場合は、以下の情報はCA構築時と全く同じ内容にする。
--------------------------------------------------------------------------------
Country Name (2 letter code)[AU]:JP
State or Province Name (full name)[Some-State]:Tokyo
Location Name (eg,city)[]:Chiyoda
Organization Name (eg,company)[Internet Widgits Pty Ltd]:TDU
Organization Unit Name (eg,section)[]:netlab
Common Name (eg,YOUR name)[]:srv.net.c.dendai.ac.jp
Email Address[]:02kc073@ed.cck.dendai.ac.jp
--------------------------------------------------------------------------------
ここで作成した署名要求書（csr.pem）をCAに送り、署名をしてもらう。

・CAでサーバ証明書を作成する。
　/etc/ssl/以下にあるopenssl.cnfを元にサーバ署名用の設定ファイルopenssl-server.cnfを作成する。なお、ここでは、ファイルを作り替えたため、使用する設定ファイル名はopenssl-server2.cnfとなっている。
　設定ファイルの以下の行を変更する。
--------------------------------------------------------------------------------
[ CA_default ]
dir = /usr/local/CA　　　　←CAディレクトリを指定

default_days = 3650　　　　←証明書の有効期限を指定
default_crl_days= 365　　　　←失効リストの有効期限を指定

[ usr_cert ]
nsCertType = server　　　　←コメント(#)を外して有効にする
--------------------------------------------------------------------------------

・作成した設定ファイルを利用して署名作業をする。
　ここからは再び /usr/local/CA で作業を行う。
openssl ca -config /etc/ssl/openssl-server2.cnf -in /usr/local SERVER/csr.pem -keyfile private/cakey.pem -cert cacert.pem -out cert.pem
-in　　　　 サーバの署名要求書ファイルの読み込み
-keyfile　 認証機関の秘密鍵ファイルの指定
-cert　　　認証機関の証明書ファイルの指定
-out　　　 作成する証明書ファイル
これでCAに署名されたサーバ証明書のcert.pemが作成された。

サーバ証明書の作成
図８　サーバ証明書の作成

・apacheの設定を変更する。
　証明書を利用したSSL通信を実行するためには、apacheの設定を変更する必要がある。apacheの設定ファイルであるhttpd.confを編集し、SSLを有効にする。
--------------------------------------------------------------------------------
SSLCAcertificateFile /usr/local/CA/cacert.pem　　　←CAの証明書の場所を指定

SSLCertificateFile /usr/local/CA/cert.pem　　　←CAで署名済みのサーバ証明書の場所を指定

SSLCertificateKeyFile /usr/local/SERVER/server.key　　　←サーバの秘密鍵の場所を指定
--------------------------------------------------------------------------------
　あとはapache-sslを起動すれば、サーバ認証を用いたSSL通信が可能になる。

３．２．３　プライベート認証局の問題点

　プライベート認証局は、個人での使用や、特定の企業内などの閉じた範囲の中でそれぞれのポリシーに則った使用であれば特に大きな問題はない。しかし、このプライベート認証局を外部に向けてのサービスで利用してしまうと、大きな危険が生まれてくる。

　プライベート認証局の証明書はブラウザにインストールされていないため、そのままSSL通信をしようとすると、図９のような警告が表示される。

セキュリティ警告
図９　セキュリティ警告

　このような場合はいったん証明書を表示し、確実に信頼のできる証明書であることを確認してから、証明書をインストールすることで、以降この警告が出ないようにすることができる。しかし、今回作成した認証局のようにルートとなる認証局がプライベート認証局の場合、証明書のインストール時に図１０のような警告が再び出る。

インストール時の警告
図１０　証明書インストール時の警告

　プライベート認証局を認証するのが自分自身になるため、同じ認証局をつくり同じ名前で「私は私です」と主張されてしまえば、万が一なりすまされた時になりすましかどうかの判別をすることができなくなってしまう。電話の相手を声だけで判別するのが難しいのと同じである。近年多発しているオレオレ詐欺（振り込め詐欺）からとって、一部では、プライベート認証局の事を「オレオレ認証局」、この認証局が発行する証明書を「オレオレ証明書」などとも呼んでいる。そのため、ブラウザでも安易にプライベート認証局の発行した証明書をインストールしないように厳重に警告を出している。

　組織内などの閉じたネットワークの中で使われる場合は、信頼の確認が取りやすいため、あまり大きな問題にはならないかもしれない。しかしいくつかの点に注意しなければならない。
　証明書のインストールはネットワーク上で行うのが効率がよい。しかしネットワーク上で行う以上、インストール時に別の場所から介入することができ、そこでなりすまされてしまう危険性がある。そのため、コストのかかる作業にはなるが、証明書をデータとして配布し、それぞれのクライアントにインストールする方法が最も安全である。
　証明書をデータとして出力するには、作成したPEMフォーマットからバイナリDERフォーマットに変換する必要がある。
openssl x509 -in cacert.pem -outform DER -out cacert.der

　また、閉じたネットワーク内で認証局を立てると、プライベートアドレスを認証局に割り振ってしまう可能性もあるが、そうすると多組織で同じプライベートアドレスを利用していた場合に誤認識してしまう問題がある。そのため、認証局には必ずプライベートアドレスを割り振る必要がある。

　作成した認証局の証明書と、認証局の署名の入ったサーバの証明書をインストールすると、以後警告は表示されず、図１１のように正常にSSL通信が行えることが確認できる。

SSL通信
図１１　SSL通信の確認

　[ツール]→[インターネットオプション]→[コンテンツ]→[証明書]（InternetExplorer6.0の場合）とたどることで、作成した認証局の証明書がインストールされていることが確認できる。

証明書
図１２　証明書の確認

　実際に官公庁などでもプライベート認証局が使用されていることもあり、その場合図９のようにブラウザから証明書が正しくない（ブラウザに実装されていない）旨の警告がでる。さらによくないことには、この警告を無視して進んでも暗号化は正常に行われるというような説明がされているところまである。官公庁など、社会的にも信用のおける機関だということだけで信用してしまいがちだが、そこにこのプライベート認証局の落とし穴があり、その機関になりすまされて秘密情報を盗まれてしまう危険性がある。現在では専門家の働きかけなどにより、上記のような説明は訂正されており、認証局もパブリック認証局による認証を受けた模様で、ブラウザからの警告が出ないようになっているところが多い。

３．２．４　パブリック認証局との相違点

　パブリック認証局とプライベート認証局の棲み分けはどこに向けたサービスを提供をするかになる。パブリック認証局は外部の不特定多数に対して、プライベート認証局は独自の認証レベルを設定して運用する閉域内での特定少数に対してサービスを提供するべきである。

　プライベート認証局は組織（会社など）の独自の判断に基づいて構築され、構成する認証局のツリー上に他の組織と共用する認証局がない。そのため、その組織独自の信頼関係を構築することが可能である。また、組織のポリシーに応じて自由に構成を変更できるため、パブリック認証局の認証を受けるよりも自由度は高い。パブリック認証局の認証を受ける際に必要となる組織の内部情報などを提出せずに済むので、情報保護の観点からも利点がある。しかし、運用管理は厳しく行う必要があり、高度な専門技術も必要となることから、場合によってはパブリック認証局の認証を受けるよりもコストがかかってしまうこともある。

３．３　その他の認証局

３．３．１　ブリッジ認証局

　複数の認証局が階層構造ではなく、相互で認証しているメッシュ構造をとっている場合もある（メッシュモデル）。しかしこのメッシュ構造では、接続する認証局の数が増えると、相互認証の数も膨大になり、認証パスの構築に時間がかかるようになってしまう。この相互認証の中継点として、ブリッジ認証局(Bridge CA)を設けることで、認証パスの数を減らすことができる。このような方式を「ブリッジCAモデル」と呼ぶ。

メッシュモデルとブリッジCAモデルの比較
図１３　メッシュモデルとブリッジCAモデルの比較

　例えば、図１３のように８つの認証局を相互接続する場合、メッシュモデルではパス数は最大で２８となるが、ブリッジCAモデルのパス数は８となる。

　このブリッジCAモデルは、相互認証の数を抑えながら柔軟な構成を取ることができるようになっており、アメリカやカナダ、日本などの政府認証基盤(GPKI)でも採用されている。

４章

４．１　まとめ

　インターネット人口が増えるにつれて、ネットワーク上に流れる膨大な個人情報や機密情報を守るために導入されるＰＫＩ技術において、認証局の運用は非常に重要である。日本でも、法整備や政府による取り組み（GPKI）など、ＰＫＩを普及させるための施策がなされているが、現状では決して十分とは言い難い。特定の組織内のポリシーに沿って運用する自由度の高いプライベート認証局と、対外的に信頼の得られるパブリック認証局またはパブリック認証局の認証を受けた中間認証局、これらの特徴をよく把握した上で認証局を運用する必要がある。また、利用者に対しても、起こり得る危険性などを正確に通知するなどの工夫が必要である。
　また、運用する側だけでなく利用する側も、インターネットに全幅の信頼を置いてしまうのは危険である。警告が出ても、そのサイトの「安全なので、そのまま進んで構いません」という言葉を安易に信じてしまったり、警告の理由を調べたり確認するのが面倒くさいなどの理由で、警告を無視してしまう事も少なくないだろう。しかし不正行為というものは往々にしてそのような隙をついて行われるものであり、特にインターネットの世界では本人が気づかずに被害を受けるケースもあるので、十分に注意を払う必要がある。
　運用者と利用者、相互のより深い理解とともに、技術的道徳的両面からもインターネット上の危険に対する注意を促すための取り組みが必要だろう。

　また暗号技術についても、同様に絶対に安全と言うことはない。本論文で取り上げたRSA暗号を初めとした現在利用されている暗号の多くは、「暗号を解かれない」のではなく「暗号を解くのが難しい」というものである。今後新たに暗号の解法が発見される可能性もある。いくつかの暗号アルゴリズムを組み合わせて使うことや、SSLのように使用するアルゴリズムをその都度選択できるシステムは、そのような場合にも柔軟に対応ができる。

　さらに、現在研究されている量子コンピュータが現実のものとなると、現在使われている暗号は、全て瞬時に計算されてしまう。量子コンピュータとは、現在利用されているコンピュータとは全く異なる仕組みのコンピュータであり、多くの計算を同時に並列処理することができる。現状では多くの量子の状態を保持するのが難しいために実用には至っていないが、近い将来量子コンピュータが実際に利用できるようになるだろう。量子コンピュータの計算能力は膨大であるため、このコンピュータに解くのが難しい暗号というのは不可能に等しい。そのため量子の世界の暗号では、読まれないための暗号ではなく、読まれたことや内容が書き換えられたことが必ずわかるような量子暗号というものが考えられている。

　技術の進歩は目まぐるしく進んでいくため、暗号が強化されればそれを解く方法が見つかり、さらに暗号が強化され・・・というようにいたちごっこのようなものである。その中で柔軟に新たな技術を取り込む姿勢や制度、また先の技術を見据えた実装なども必要となるであろう。本論文でＰＫＩの大まかな全体像及び認証局について調査したことで、インターネット上の脅威に対する考え方が大きく変わった。この脅威に対する考え方を広められるよう、さらに理解を深め、ＰＫＩについてのより多くの情報にアンテナを張っていきたい。

付録

Ａ．　アルゴリズム

Ａ−１．　ＲＳＡ暗号

　RSA暗号とは、公開鍵暗号アルゴリズムの一つである。３人の開発者、Rivest、Shamir、Adlemanの頭文字をとって名前がつけられた。RSA暗号の式は以下のようにシンプルに表すことが出来る。

＜暗号化＞　：　Ｃ　＝　ＭE　mod　N

＜復号化＞　：　Ｍ　＝　ＣD　mod　N

ここで、Ｍを平文、Ｃを暗号文とし、Ｍ・ＣはそれぞれN以下のNと互いに素な自然数とする。
また、(E,N)の組が公開鍵、(D,N)の組すなわち(D)が秘密鍵となる。


＜鍵{N,E,D}の生成＞

  1. Nを求める。
  2. Lを求める。
  3. Eを求める。
  4. Dを求める。

＜復号の検証＞

暗号文Ｃが秘密鍵(D,N)によって平文Ｍに復号されることを検証する。
まず、Ｃ　＝　ＭE　mod　N より、
Ｍ　＝　(ＭE)D　mod　Nとなる。

また、鍵の生成で、Dを求める際に必要となる条件、E × D ≡ 1　(mod L)は、次のように書き直せる。
　E × D ≡ 1　(mod φ(N))
さらに、自然数kを用いて、
　E × D ＝ k × φ(N) ＋ 1
と表せる。
これをそれぞれ平文Ｍに乗ずると、
　ＭE × D ＝ Ｍk × φ(N) ＋ 1

ここで、オイラーの定理より、次の式が成り立つ。
　Ｍk × φ(N) ＋ 1 ≡ Ｍ （mod N）
よって、

　ＭE × D ≡ Ｍ （mod N）

となり、暗号文Ｃが秘密鍵(D,N)によって、平文Ｍに正しく復号されることが確認できる。


このRSA暗号のように、公開鍵と秘密鍵をかける順番を変えても同じ結果が得られる(ＭED ＝ ＭDE)プロトコルを、鍵同士の交換則を満たすプロトコルという。


＜RSA暗号の安全性＞


Ａ−２．　ＳＳＬ

SSLプロトコル層
Handshake Protocol 
　新規セッション確立時　　　　　　　　　　　　　　　　　既存セッション再開時

クライアント　　　　　　　　　　　　　　　サーバ      クライアント　　　　　　　　　　　　　　　サーバ
　　│　　　　　　　　　　　　　　　　　　　│        　　│　　　　　　　　　　　　　　　　　　　│
　　│　　Client Hello　　　　　　　　　　　│        　　│　　Client Hello　　　　　　　　　　　│
　　├──────────────────→│        　　├──────────────────→│
　　│　　　　　　　　　　　　　　　　　　　│        　　│　　　　　　　　　　　　　　　　　　　│
　　│　　　　　　　　　　　Server Hello　　│        　　│　　　　　　　　　　　Server Hello　　│
　　│←──────────────────┤        　　│←──────────────────┤
　　│　　　　　　　　　　　　　　　　　　　│        　　│　　　　　　　　　　　　　　　　　　　│
　　│　　　　　　　 *Server Certificate  　│        　　│　　　　　　　　Change Cipher Spec　　│
　　│←──────────────────┤　        　│←──────────────────┤
　　│　　　　　　　　　　　　　　　　　　　│        　　│　　　　　　　　　　　　　　　　　　　│
　　│　　　　　　  *Server Key Exchange　　│        　　│　　　　　　　　　　　　　Finished　　│
　　│←──────────────────┤        　　│←──────────────────┤
　　│　　　　　　　　　　　　　　　　　　　│        　　│　　　　　　　　　　　　　　　　　　　│
　　│　　　　　　  *Certificate Request    │　        　│　　Change Cipher Spec　　　　　　　　│
　　│←──────────────────┤        　　├──────────────────→│
　　│　　　　　　　　　　　　　　　　　　　│        　　│　　　　　　　　　　　　　　　　　　　│
　　│　　　　　　　 　Server Hello Done　  │        　　│　　　　　　　　　　　　　Finished　　│
　　│←──────────────────┤        　　├──────────────────→│
　　│　　　　　　　　　　　　　　　　　　　│        　　│　　　　　　　　　　　　　　　　　　　│
　　│　　*Client Certificate　　 　　　　　│        　　│　　　　　　　　　　　　　　　　　　　│
　　├──────────────────→│　        　│←─────────────────→│
　　│　　　　　　　　　　　　　　　　　　　│        　　│　　　　 　Application Data　　　　 　│
　　│　　Client Key Exchange　 　　　　　　│        　　│←─────────────────→│
　　├──────────────────→│　        　│　　　　　　　　　　　　　　　　　　　│
　　│　　　　　　　　　　　　　　　　　　　│
　　│　　*Certificate Verify　　 　　　　　│
　　├──────────────────→│
　　│　　　　　　　　　　　　　　　　　　　│
　　│　　Change Cipher Spec　　　　　　　　│
　　├──────────────────→│
　　│　　　　　　　　　　　　　　　　　　　│
　　│　　Finished　　　　　　　　　　　　　│
　　├──────────────────→│
　　│　　　　　　　　　　　　　　　　　　　│
　　│　　　　　　　　Change Cipher Spec　　│
　　│←──────────────────┤
　　│　　　　　　　　　　　　　　　　　　　│
　　│　　　　　　　　　　　　　Finished　　│
　　│←──────────────────┤
　　│　　　　　　　　　　　　　　　　　　　│
　　│　　　　　　　　　　　　　　　　　　　│
　　│←─────────────────→│
　　│　　   　Application Data　　　　 　　│
　　│←─────────────────→│
　　│　　　　　　　　　　　　　　　　　　　│

*：必ずしも送信されるわけではなく、状況に応じて変化する


                                    図ａ　ハンドシェイクプロトコル手順

Client Hello、Server Hello、Client Key Exchange、それぞれのメッセージの中に、サーバ／クライアントそれぞれで生成された乱数が埋め込まれている。これらの乱数を複雑にハッシュ関数にかけ、マスタ・シークレットと呼ばれる鍵の元となる秘密のデータを生成する。

このマスタ・シークレットは同一セッション内では同じ値が使用される。


また、このマスタ・シークレットと、Client Hello、Server Helloに埋め込まれた乱数をさらに混ぜ合わせ、ハッシュ値を計算することで、暗号化に使用する鍵を生成する。

Client Hello、Server Helloの乱数はセッション再開ごとに新たな値を使用して鍵を生成する。

Ｂ．　数学的知識

Ｂ−１．　整数の合同

　合同という考えと記号は、数学者のガウスが、その有名な著書「整数論考究」の中で初めて発表した。以下はその引用である。
「もし数ａがｂ，ｃの差を割りきるならば、ｂとｃはａに関して合同であるといい、もしそうでなければ、非合同であるという。ａ自身は法という名で呼ぶことにしよう。前者の場合、ｂ，ｃのおのおのはもう一方の数の剰余と呼ばれるが、後者の場合は非剰余と呼ばれる。・・・・・以後、数の合同を記号≡によって明示し、法が必要な場合には、それを括弧に入れて −１６≡９（ｍｏｄ．５）、−７≡１５（ｍｏｄ．１１）というふうに表記することにしよう。・・・」（ガウスは（ｍｏｄ．５）と書いたが、現在では「．」を書かない）

＜定理＞

ａとｂを正整数ｃで割ったときの余りが等しいときに、ａとｂはｃを法として合同であるといい、

　　　　　ａ≡ｂ（ｍｏｄ ｃ）

と書く。

ここで、ｍｏｄはｍｏｄｕｌｏ（モデュロー）の略で剰余を計算する記号である。


Ｂ−２．　オイラーの定理

　ｎを整数、ｘをｎと互いに素である整数、φ(ｎ)をｎ以下のｎと互いに素となる正整数の個数としたとき、ｘをφ(ｎ)回かけて、そこから１引いたものは必ずｎで割り切れる。つまり、以下の式が成り立つ。

　　　　　ｘφ(ｎ)≡１　(ｍｏｄ ｎ)

　また、ｘがｎの倍数でない限り、ｘをφ(ｎ)＋１回かけると自分自身に戻る。つまり、以下の式が成り立つ。

　　　　　ｘφ(ｎ)＋１≡ｘ　(ｍｏｄ ｎ)


　φ(ｎ)は整数ｎのオイラー関数と呼ばれている。ｎが素数の時には、１，２，．．．，ｎ−１はｎと互いに素なのでφ(ｎ)＝ｎ−１となる。ｎが異なる２つの素数ｐとｑの積ならば、φ(ｎ)＝(ｐ−１)(ｑ−１)となる。

Ｂ−３．　ユークリッドの互除法

二つの自然数から、それらの最大公約数を求めるための解法。

＜アルゴリズム＞

入力：正の整数　a, b　（ a ≧ b ）

step1　　a mod b　→　r
step2　　r = 0　ならばstep4へ
step3　　b　→　a、　r　→　b　としてstep1へ
step4　　b が最大公約数
＜証明＞

このアルゴリズムは a mod b = r において、「aとbの最大公約数はbとrの最大公約数と等しい」という事実を根拠として成り立っている。

　ｒはａをｂで割った余りであるので、ａはｂ、ｒそしてその商ｑを用いて次のように書ける。

　　ａ＝ｂｑ＋ｒ　　…(１)

　今、ａとｂの最大公約数をｐとする。
　そうすると、ａ、ｂはｐおよび、正の整数ｘ，ｙを用いて次のように書ける。

　　ａ＝ｘｐ　
　　ｂ＝ｙｐ

　これを使うと、(１)は次のように書きなおせる。　

　　ｘｐ＝ｙｑｐ＋ｒ　　…(２)

　(２)は次のように変形できる。

　　ｘ―ｙｑ＝ｒ／ｐ　　…(３)

　ここで、(３)の左辺は、整数であるから、(３)の右辺も整数でなければならない。すなわち、ｒはｐを因数に持つ。（つまり、ｒ＝ｚｐという形で書ける。）よって題意は示される。


Ｂ−４．　拡張ユークリッドの互除法

＜定理＞

ｘ，ｙを０でない自然数都市、ｃ＝GCD(ｘ,ｙ)とする。このとき、ａｘ＋ｂｙ＝ｃとなる整数ａ，ｂが存在する。そして、このａ，ｂは実際に計算することができる。

＜アルゴリズム＞

便宜上ｘ＝ｒ0，ｙ＝ｒ1と置く。このとき、GCD(ｘ,ｙ)＝ｒ＝ｒｎは次の式で与えられる。

(0)　　　ｒ0＝ｑ1＊ｒ1＋ｒ2 0＜ｒ2＜ｒ1
(1)　　　ｒ1＝ｑ2＊ｒ2＋ｒ3 0＜ｒ3＜ｒ2
(2)　　　ｒ2＝ｑ3＊ｒ3＋ｒ4 0＜ｒ4＜ｒ3
…　　　　・・・
(k-1)　　ｒｋ-1＝ｑｋ＊ｒｋ＋ｒｋ+1 0＜ｒｋ+1＜ｒｋ
…　　　　・・・
(n-2)　　ｒｎ-2＝ｑｎ-1＊ｒｎ-1＋ｒｎ 0＜ｒｎ＜ｒｎ-1
(n-1)　　ｒｎ-1＝ｑｎ＊ｒｎ

このとき、ｉ＝０,１,２,...,ｋに対して、
(*1)　　　ａｉ＊ｘ＋ｂｉ＊ｙ＝ｒｉ
と表されたとすると、

(*2)　　　ａｋ+1＝ａｋ-1−ｑｋ＊ａｋ
　　　　　 ｂｋ+1＝ｂｋ-1−ｑｋ＊ｂｋ
に対して、
(*3)　　　ａｋ+1＊ｘ＋ｂｋ+1＊ｙ＝ｒｋ+1
が成立する。

ここで(*3)の証明をする。
まず、(k-1)の式から、

　　　　ｒｋ+1＝ｒｋ-1−ｑｋ＊ｒｋ

となり、この右辺に、(*1)のｉ＝ｋ−１と、ｉ＝ｋの式を代入すると、

　　　　ｒｋ+1＝(ａｋ-1＊ｘ＋ｂｋ-1＊ｙ)−ｑ＊(ａｋ＊ｘ＋ｂｋ＊ｙ)
　　　　　　 ＝(ａｋ-1−ｑｋ＊ａｋ)＊ｘ＋(ｂｋ-1−ｑｋ＊ｂｋ)＊ｙ

となる。このしきに(*2)を代入すると、

　　　　ｒｋ+1＝ａｋ+1＊ｘ＋ｂｋ+1＊ｙ

が得られ、これが式(*3)となる。

ａ0＝１，ｂ0＝０，ａ1＝０，ｂ1＝１と置く。
このとき、ｘ＝ｒ0，ｙ＝ｒ1と(0)，(1)に注意すると、ｉ＝０,１に対して、

　　　　ａｉ＊ｘ＋ｂｉ＊ｙ＝ｒｉ

が成立する。
従って、(*1),(*2),(*3)の操作を、ｋ＝２,３,...ｎ−１まで続けると、最終的に

　　　　ａｎ＊ｘ＋ｂｎ＊ｙ＝ｒｎ

が得られる。ここで、ｒｎ＝GCD(ｘ,ｙ)＝ｃなので、ａ＝ａｎ，ｂ＝ｂｎと置くと、

　　　　ａ＊ｘ＋ｂ＊ｙ＝ｃ が得られる。

参考文献