OpenPKSDプロジェクトのおはなしをしたいと思います。このプロジェクトは OpenPGPの新しい鍵サーバ実装を行う フリーソフトウェア プロジェクトです。 最近、ようやく一般 にもサービスできる状態になってきたので、このタイミングで紹介したいと思 います。まずは pgp.nic.ad.jp と openpksd.org を紹介しましょう。
前者は日本国内で運用しているOpenPGP公開鍵サーバです。後者は筆者が進めている OpenPKSDプロジェクトのWebサーバです。OpenPGPやOpenPGP公開鍵サーバに関する色々 なドキュメントが用意されています。
その前にOpenPGPとは何かを簡単にお話しましょう。OpenPGPとは、みなさんも よく知っている暗号プログラムPGPを仕様にまとめたもので、この規格は現在 IETFのRFC2440として文章化され公開されています。もともとPGPは1991年に Philip Zimmermannが作成・公開した暗号ソフトウェアです。当時は、そんな に多くの人が使うとも思わず彼が何人かの友人にコピーした程度のものでした。 そのうち誰かが地元のBBSにソースコードをアップロードし、さらに誰かがそ のソースコードをUSENET上に投稿したのをきっかけに爆発的に全世界に広がり ました。
後にZimmermannがPGP,Inc.という会社を作りPGPのパッケージ販売を行うと平行し て、それまでと同じようにソースコードを公開し、誰でも自由にダウンロードできる ようにしました。
ちなみに同時期にPEM(Privacy Extended Mail)という暗号化メール規格があり ます。これはIETFで RFC化 もされた本格的な暗号化メールの規格です。 しかしPEMという規格や、その実装を知っている、あるいは使ったことがある という人は、ほんの一握りでしょう。RFC化された当時は"花形スター"の座を 約束されていたかのように思えたものです。最初のPGPを作っていた頃、 ZimmermannはPEMの存在を知りませんでした。PEMの存在を知った時、彼は「あ あ、俺はなんて世間知らずなんだ!俺の作ったPGPなんてすぐに潰されてしまう!」 と思ったそうです。
ところが暗号技術専門家たちの議論を経て仕様をまとめ上げ、いくつもの実装 も存在していて前途洋々に見えたPEMは結局、生き残りませんでした。 その後に出てきた暗号化メールの仕組みS/MIMEにしてもRSA社がバックにつき NetscapeやMicrosoftが採用していても、PGP/GnuPGまでの広がりには届いてい ません。
では、何かPGPが生き残るためのサバイバルプランがあったかと問われると、 「そんなものは存在していません」というしかありません。 人々がPGP(やGnuPG)を支持し、現在に至ったという現実だけが残っているのです。
当時米国では暗号ソフトウェアは軍事物資のカテゴリに分類されていたのでソー スコードを米国内のftpサイトに用意しダウンロードするということは出来ま せん。そこでPGPのソースコードを本として出版します。 PGP: Source Code and Internalsという本は から発行された正真正銘の本でISBN (ISBN 0-262-24039-4)もきちんとつけら れています。もしこれを米国政府が差し止めようとするなら 米国憲法修正第一条 で保証している言論や出版の自由を犯したという理由で 出版元であるMIT Press ( この出版社の母体は MIT ) と Zimmermannが徹底抗戦する覚悟でいました。 実際には、この大胆な挑戦に対し政府は傍観するしかありませんでした。この 本は海外にいるPGP エバンジェリストの手によりスキャナーで読み込まれソー スコードに変更され、きちんとコンパイルできるパッケージにしてヨーロッパ のftpサイトに置かれ、世界中の人達がダウンロードするという形で世界に配 付されます。
ここで付け加えておくと、当時、多くの人に誤解されていたのですが対共産圏 輸出規制COCOMに加盟していた国でも、多くの国では暗号であろうともオープ ンな情報に関しては輸出規制が課せられていませんでした。だからこそPGPの ソースコードをftpサイトに置けたのです。当時、通産省から出ていた通達で も、学会論文や本、雑誌などの公に出版されるものやソースコードが公開され ているソフトウェアは制限から除外されています。米国やフランスなど少数の 国がCOCOMよりも厳しい独自の輸出法を持っていたに過ぎません。
PGP,IncがNetwork Associates,Inc.に売却され、同社の一部門となってもソー スコードは公開するというZimmermannのポリシーは貫かれました。 (後にNAIはPGP部門を売却し、 PGPコーポレーション という新会社ができた)
1997年ドイツUNIXユーザグループのメンバーであるWerner Kochが GNU Privacy Guard プロジェクト の一環としてPGP互換のフリーソフトウェアであるGnuPGの 公開を始めます。それまでPGPはZimmermannの率いる開発グループが作ってい たものが唯一無二の存在だったので、わざわざ仕様ドキュメントを作る必要は ありませんでした。GnuPGとPGPという複数のソフトウェアが存在することによっ て、個々のソフトウェア間で互換性を保つための規格ドキュメントを作る必要 が発生します。かくして1998年にOpenPGPという規格にまとめられました。そ れをRFC化したドキュメントが RFC2440 です。現在はドキュメントがアップデー トされRFC2440-bizがまとめられている最中です(6月末現在)。
OpenPGP公開鍵サーバとはOpenPGPの公開鍵をユーザ間でやり取りするための公 開サーバです。これはユーザ間での公開鍵のやり取りの簡便性を高めるために 用意されている公開鍵をプールする(貯めておく)ためのサーバです。誰でも登 録することができます。もちろんただ貯めておくだけなので、何の保証もしま せん。個々の公開鍵の信頼性はユーザ自身が責任をもって確認します。
OpenPGPではフィンガープリントと呼んでいる公開鍵と付属する情報から作っ たハッシュ値を使い公開鍵の持ち主が正しい持ち主であるか自分自身で確認す る方法が推奨されます。あるいは確認したい公開鍵に対し信頼のおける第三者 の正しい署名がされており、その署名が正しいものであることを信頼するとい う"Web Of Trust"(信頼の輪)を取る方法もあります。基本的に何を信頼し、何 を信頼しないかは、ユーザの判断にかかっています。
最初の公開鍵サーバは1994年にMITの学生であるBrian LaMacchiaが作製しまし た。鍵の登録、取得はメール経由で行われ、PGPバージョン2.6.3のコマンドを 直接呼び出すようなラップするPerlプログラムが用意されていただけでした。 1997年に同じくMITの学生(当時)であるMarc Horowitzが作った PGP Public KeyServer(pksd) が登場します。これは本格的なデータベースの機能をもった公開鍵サーバで、 現在もこのpksdを改良・修正しながら利用しています。
世界各地のボランティアによりサポートされているPGP公開鍵サーバ間は、ど こか1つに登録すると他のPGP公開鍵サーバにも分配され同期できるようになっ ています。このような同期サーバは世界におおよそ10〜15程度あります。主 要なところとしてヨーロッパではオランダのSurfnet、ドイツのDFN-CERT、ス ペインのRedIRISが、アメリカではMIT、Gatech(ジョージア工科大学)が、日本 ではJPNICが用意しています。これらの間では密に連絡が取られています。
ヨーロッパで紹介した3組織はいずれもインターネットセキュリティに関連し た活動をしている組織です。2000年にはSurfnet主催で 第一回PGP鍵サーバ管理者シンポジューム というのがオランダで開かれました。シンポジュームといっても20数名が Surfnetの会議室に集まった小さな会ですが、Zimermann、Koch、Horowitzはも とより、NAI,Incのエンジニア、ヨーロッパやアメリカでの管理者そして日本 から筆者が参加しました。このグループのメンバーのほとんどはPGPという継 りがなくても、よく見知った顔の集まりです(業界は狭いということを実感さ せられます)。
日本のPGP公開鍵サーバ は筆者が管理しています。1994年には筆者の勤務して いた会社にある自分の使っている作業用マシンで動かしていました。当時はメー ル経由でのリクエスト機能しかありません。 96年から 認証実証協議会 ICAT の認証タスクフォースに属する 1つの実験プロジェクトとしてICATの他目的サーバ上で動かしていました。そ して98年から現在までJPNICの実証実験プロジェクトとしてJPNICのサーバー群 の1つに専用マシンを用意した形でサービスしています。このマシンはNSPIXP2に 100Mbpsでダイレクトに接続しています。 いまでこそ100Mbpsという数字に驚きませんが、当時としては画期的なネット ワーク環境でした。公開鍵サーバに登録されるPGP公開鍵の爆発的ともいえる 増加に対応するためには、これくらいのバンド幅の余裕を見ておいた方が良い と考えていました。
登録されるPGPの公開鍵は1997年年末で5万5000鍵程度だったものが、現在は 160万鍵を超えています ( 詳しい資料は こちらを御覧下さい ) 。 この5年間で一日のトランザクション量は100倍ぐらいに増加しています。現在 は、あいかわらず登録鍵数は増えていますが、ここ1年のトランザクションの 増加率は鈍化しています。これはPGPやGnuPGの普及が一巡してしまったのかも 知れません。現状でよければ実際には安定した数Mbps程度のバンド幅が確保さ れていれば充分運用できます。ただし保持しているデータが大きいので、以前 にも増して大量メモリ、高速なCPU、大容量のHDDが必用です。ただし近年では ハードウェアコストが劇的に低下しているので、以前のような大きな問題には ならないでしょう。
思いおこせば`97年ごろはサーバマシンやインターネットに接続するコストも非 常に高価で個人で手が出せるようなものではありませんでした。その窮状を見 かねた多くの人が、影になり日向になり助けてくれて現在に至っています。こ の場を借りて感謝します。
認証局がユーザの公開鍵を認証するメカニズムであるX.509方式の公開鍵イン フラストラクチャー(PKI)しか知らないと"Web of Trust"方式は奇異な手法に 思えるかも知れません。X.509という規格はITU-T(国際通信連合電信電話分科 会:規格を作り始めた当時は、その前身であるCCITTという組織)という国際的 に公式な組織でまとめられたもので、多くの商用ソフトウェアがサポートし、 商用のX.509認証局も稼動しています。あふれるばかりの解説書や、認証ビジ ネスのマーケットを広げようとする企業から大量に流される広告を無批判に受 け入れ、世間では無自覚のうちに「公開鍵の信頼性=認証局=X.509」という理 解になっています。
OpenPGPとX.509に関する面白い話をしましょう。インターネットセキュリティ の最前線に立つ各国のインシデントチーム(たとえば米国ではCERT/CC、日本で はJPCERT/CCなどがそうです)がお互いのデータを確認する時の電子署名には OpenPGPを使っています。
商用の認証局は確実でしょうか?何年か前に米国マイクロソフトに成りすました何者 かが、米国マイクロソフトの認証書を取得し騒ぎになったことがあります。この事件 が発覚すると同時に発行したこの認証書を無効にし、それを通知するCRL (CertificateRevocationList)を用意しました。 この騒動、当のマイクロソフトの製品には用意されたCRLを処理する機能が 実装されていなかった というオチがつきました。
またIEやNetscapeといったSSLをサポートするブラウザでは、X.509証明書本来 の能力を有効に使ってはいません。たとえばWebページを参照するときはX.509 証明書を使ってサーバをチェックしているにも関わらず、ブラウザからWebサー バへデータを送付するときは証明書の存在を無視しています。本来はWebサー バ側に悪意があろうとも、ユーザが確認できるというのが電子署名と電子署名 の証明書の役目であるのに、それが出来ていません。たとえば最近あちらこち らで話題になっているクロスサイトスクリプト問題の病根はWebサーバアプリ ケーションではなく、サーバが嘘をついていても見分けなければならないはず のブラウザ側の認証チェックが機能していないという部分にあるのです。
また、そもそもの問題として誰が誰を認証するかという問題は、人間を取巻く 諸問題も含むので機械的にどうこうするような単純な話ではないのです。東京 大学の 今井秀樹 教授は、かねてより暗号技術は常に人間が介在する要素を含む 難しさ指摘しており、このことを「ヒューマンクリプト」と呼んで重要性を説 いています。
OpenPGPのように自分の手で確認する方法か、あるいはWeb of Trustのように あなたが信頼できる第三者の証明をあなたが確認する方法はとても合理的なの です。第一に責任所在が明確であることが上げられます。これは利用者責任で あることがはっきりしています。次に信頼のおける複数の第三者の署名がある ような場合、すべての署名が偽造、あるいは成りすましでだませる確率は小さ くなります。
もちろんX.509方式やOpenPGPの"Web of Trust"方式以外にもMITの Ron Rivest 教授らが提唱する SPKI/SDSI [link 1] [ link 2 ] 方式が提案されています。筆者の目からはX.509方 式よりもSPKI/SDSI方式の方がはるかに優れています。ちょっとだけX.509の肩 を持つとするならば、X.509規格以前に広域なレベルで使う署名や認証システ ムは存在していなかったので、初の本格的な公開鍵のインフラストラクチャー という意味はあるのかな、程度の評価です。
現在のOpenPKSDとはpksd互換のOpenPKSD公開鍵サーバです。現在はpksd互換と して用意していますが、将来の拡張のためのプラットフォームになるソフトウェ アで、pksdとはまったく構造が違うものです。また、OpenPKSDを構成するソフ トウェアの80%以上はRubyでかかれており、 残りの殆どがShell(bash)スクリプト、 そして約20行ほどがC言語でかかれています。
Ruby にした理由は、オブジェクト指向言語として優秀なこと、そしてプログラマー側 にC言語でかかれたモジュールAPIを用意していること、なによりも「今が旬」のスク リプト言語だからです。スクリプト言語といいましたが、サーバプログラムを作るぐ らいの充分な能力を持つプログラム言語であり、このOpenPKSDプロジェクトがRubyの 能力を証明したかったというモチベーションもありました。
pgp.nic.ad.jpで使っているHorowitz版pksdは、内部にBSD dbmの流れを汲む sleepyCat版のハッシュテーブル型のデータベースを利用していました。しかし、これ ではシステムデザイン的にプログラムとデータベースの独立性が保てないことと、管 理時のデータベースの運用が柔軟ではないという問題のためOpenPKSDでは採用しませ んでした。
一番わかり易いケースはデータベース中のテーブルへの大量の登録と検索に使うイン デックスの生成タイミングの関係です。データベースのインデックスは検索を高速に 処理するために必用な情報です。通常、1つ新しいレコードをデータベースに登録す るたびにインデックスに新しいレコードに対応する情報が加えられインデックス自体 も更新されます。バッチ方式で数百万件のレコードを一気に登録しようとすると、こ のインデックスの同時更新が大変な負荷になります。
これを単純なモデルにすると、 「N個の要素がハッシュテーブルに追加されるコストの総和」になる。 ただしハッシュテーブルに追加されるコストは O(t)、1<=t<=n とする。
一般にSQLデータベースでは、インデックスの存在とデータベーステーブルは 独立になっています。PostgreSQLも同様です。まず大量のレコードをテーブル に登録した後、インデックスを別手順で作成します。わかりやすく言えば100 万の登録の時に、インデックスを100万回更新するか、あるいは1度だけ作成す るかの違いになります。まず大量に登録した後、登録終了後にインデックスを 生成する方法にすると、インデックス生成のための余分な時間は10数分かかる だけで済みます。
これを単純なモデルにすると、「N個の要素がテーブルに追加されるコストの総和 ＋ N個の要素からハッシュテーブルを作るコスト」になる。 ただし要素がテーブルに追加されるコストはO(1)であり、 N個の要素からハッシュテーブルを作るコストはO(n)とする。
「単純な登録、検索とプラスαなので、MySQLでも充分ではないか、またMySQL の方が高速ではないか」という指摘を頻繁に受けます。現状においてはその指 摘は正しいものです。しかしながら、 PostgreSQLの良い点 は、簡易SQLプログラムではなく商用に真っ向から対抗できる本格的なSQLサー バです。ノンストップでメンテナンスや運用をするための数々の機能が充実し ています。最新のPostgreSQLではマルチCPUでは処理能力が上がる、データベー スを稼動しながらデータベースメンテナンスのvacuum処理を行えるなど数々の 利点があります。
現在は1つのPostgreSQLで処理していますが、次世代OpenPKSDのために PostgreSQLをクラスター化しスケーラビリティを持たせるための基礎的な調査 研究も開始しています。これは1 Billion Keys Problem(10億鍵問題:大量の鍵 をどう扱うか問題)に対応するための研究です。もちろんこんなに大量の鍵を 扱うことは将来もありえないかも知れません。しかしながら、将来への技術的 なロードマップを誰かが用意する必要があります。OpenPKSDでは、そのような 困難なテーマにも取り組んでいます。
現状の方式でもPostgreSQLを高信頼・超高性能マシン上で動かし、複数の openpksdデーモンから1つのPostgreSQLにリクエストを出すといった構成に拡 張することも可能です。かなり柔軟に色々なことを試すことができます。この 方式なら1億や2億の公開鍵でもハンドリングできるでしょう。
OpenPKSDに関する情報はすべて openpksd.org 上に用意しています。PGPやGnuPGPを使っていなくてもWeb経由でOpenPGPの公 開鍵を検索できます。また昨年度調査した報告書などもこのサーバからダウン ロードできます。世界で10サイト程度でしか使われないと思われるOpenPKSDで すが、このソースコードも もちろん用意しています 。
以上
OpenPKSD.ORGトップページへ$Id: SD200208.html,v 1.2 2002/12/19 01:53:33 hironobu Exp hironobu $