Top

ドメイン名入門
入門ガイド
管理ガイド基礎
[Email]
  alias
  procmail
  M4 Macro
  SPAM防止
    SpamAssassin
    vinstallログ
    accessファイル
  Anti-Virus
  メールリスト
    Mailman
      VHostで利用
      リスト作成
    Majordomo
      インストール
      リスト作成
      MajorCool
  暗号化ツール
    SSL上での利用
    PGP
      暗号化PGP
      暗号化GnuPG
  自動返信メール
  virtusertable
[FTP]
[Web]
[Ports]
[Shell]
[User]
[iManager]
[CPX]
[Webmin]
管理上級編


v2
Top
v2
Start
v2
Email
v2
Ftp
v2
Web
v2
Ports
v2
Shell
v2
User
v2
Perl
v2
Java
v2
System
v2
iManager
v2
CPX


PGP ユーザーズガイド 1

注意: このページは、レンタルサーバー SPEEDEX VPS v2 の技術サポートです。
2009年6月現在、VPS v2 の新規オーダーを受けしておりますが、 VPS v3 の採用をお勧めします。
現在提供中のサービスについては SPEEDEX のメニューページを参照ください。
SPEEDEX VPS v1 サーバーご利用の場合は v1 サーバーサポートページを参照ください。
SPEEDEX VPS v3 サーバーご利用の場合は v3 サーバーサポートページを参照ください。
SPEEDEX OneDom サーバーご利用の場合は OneDom サーバーサポートページを参照ください。

Phil's Pretty Good Softwareが提供するソフトウェア

PGP (tm)

◇Pretty Good(tm) Privacy
一般の人を対象とした公開鍵暗号化方式

◇PGP(tm) ユーザーズガイド
第 1 巻: 基本事項
作成者:Philip Zimmermann   改定日: 1994 年 10 月 11 日

◇PGP バージョン 2.6.2  1994 年 10 月 11 日
ソフトウェア作成者:Philip Zimmermann ほか

概要:
PGP(tm) は、公開鍵を暗号化することによって E メールやデータファイル保護するためのソフトウェアです。このプログラムを使うと、知らない相手との通信を安全に行うことができます。セキュリティ保護された通信路を使って、前もって鍵の交換を行っておく必要もありません。PGP は高い機能性と高速性を備えたプログラムです。高度な鍵管理機能、デジタル署名機能、データ圧縮機能が備わっているだけでなく、使い勝手のよい優れた製品です。

ソフトウェアとマニュアルの著作権(1990-1994)は、Phillip Zimmermann に帰属します。無断転載を禁じます。PGP のライセンス許諾、配布、著作権、特許、商標、免責事項、輸出規制については、『PGP ユーザーズガイド』の第 2 巻、特殊事項の「法律に関連する事項」のセクションを参照してください。配布元は、マサチューセッツ工科大学です。


「何をするにしても意味がないように思えるかもしれませんが、することに最大の意義があるのです」
                                    - マハトマ・ガンジー


==================
目次
==================
・PGP の概要
・PGP を使う理由
・PGP の仕組み
・PGP のインストール
・PGP の使い方
・使用方法の概略を表示する
・メッセージの暗号化
・メッセージを暗号化して複数の相手に送信する
・メッセージに署名する
・署名を付けたあと暗号化する
・従来の暗号化方式のみを使う
・復号化と署名の確認
・鍵の管理
・RSA 鍵の生成
・キーホルダーに鍵を登録する
・キーホルダーから鍵やユーザー ID を削除する
・キーホルダーに登録されている鍵を取り出す(コピーする)
・キーホルダーの内容を確認する
・公開鍵の改ざんを防止する方法
・PGP における有効な鍵の管理方法
・秘密鍵の漏洩を防止する方法
・公開鍵の無効化
・秘密鍵を紛失した場合の対応について
・高度な使い方
・E メールで暗号文を送信する radix-64 フォーマット
・パス名の環境変数
・PGP 設定ファイルのパラメータを設定する
・弱点
・粗悪品に注意
・Mac ユーザーに対する注意事項
・PGP クイックリファレンス
・法律に関連する事項
・謝辞
・原稿作成者について



==================
PGP の概要
==================
Philis Pretty Good Software の PGP (Pretty Good(tm) Privacy) は、MS/DOS、UNIX、VAX/VMS などに対応した高セキュリティの暗号化ソフトウェアアプリケーションです。PGP を使ってメッセージやファイルの交換を行うと、プライバシーが漏れることなく、本人確認を行うことができ、利便性にも優れています。プライバシーとは、本来の受信者以外がメッセージを読めないことを意味します。本人確認とは、メッセージの送信者として表示されている人が本当にそのメッセージを送信したかどうかを確認することです。利便性とは、従来の暗号化ソフトウェアに付随するような鍵の管理に労力を使うことなく、プライバシーを保護したり本人確認が行えたりすることです。ユーザー間で鍵を交換する際に通信路をセキュリティ保護する必要がないため、簡単に使用できます。これは、PGP が「公開鍵」暗号化技術と呼ばれる強力な新技術を基盤としているからです。

PGP は、RSA (Rivest-Shamir-Adleman) 方式の公開鍵暗号化システムの利便性と従来の暗号技術の高速性を兼ね備えたソフトウェアであり、メッセージダイジェストによる署名、圧縮データの暗号化、使い勝手のよい設計、優れた鍵管理機能といった特長を備えています。さらに、PGP の公開鍵機能の実行速度は、ほかの一般的なソフトウェアよりも優れています。PGP は、一般の人々を対象とした公開鍵暗号化技術です。

内蔵モデムによる通信機能は備わっていません。モデムによる通信を行う場合は、別のソフトウェアを使う必要があります。

このマニュアル(第 1 巻: 基本事項)は、PGP を使用する際の基本事項だけを説明したものであり、PGP のすべてのユーザーに読んでいただく必要があります。『第 2 巻: 特殊事項』では、PGP の高度な機能をはじめとする特殊な事項を説明しており、PGP の上級ユーザーを対象とした内容になっています。暗号化アルゴリズムとデータ構造の基盤となる技術の詳細については、第 1 巻でも第 2 巻でも解説していません。

==================
PGP を使う理由
==================
PGP を使う理由は、個人情報とプライバシーを守るためです。これは、あなた自身の問題です。政治活動を計画したり、税金に関する相談を行ったりしている人もいれば、倫理に反するような恋愛をしている人もいるでしょう。自分では違法だとは思っていなくても、実際には違法行為を行っている場合もあります。いずれにせよ、プライベートな電子メール(E メール)や機密文書は、第三者に読まれたくないはずです。自分のプライバシーを主張することは、きわめて正当なことです。プライバシーには、憲法と同じ価値があります。

自分の E メールには違法な要素はまったくないので、暗号化する必要はないと考える人がいるかもしれません。法を遵守しているので隠すようなことは何もないのであれば、ハガキに書いて送ればよいはずです。薬物検査の要求に応じないのはなぜですか。警察の家宅捜索に対して、その理由を求めるのはなぜですか。何かを隠そうとしているからですか。封筒の中に手紙を隠している人は破壊活動分子ですか。それとも偏執症者ですか。法を遵守している人は E メールを暗号化する必要はありませんか。

違法行為を行っていない人はハガキを使って通信すべきであると誰もが考えていたら、どのようなことが起こるでしょうか。勇気のある人が、封書を使うことによって自分のプライバシーを主張しようとしたら、疑惑を持たれてしまいます。その手紙は管轄官庁に開封され、内容を確認されてしまうでしょう。幸いなことに、われわれが実際に暮している社会ではこのようなことは起こりません。誰もが、一般的に封書を使っているからです。封書を使うことによってプライバシーを主張したからといって、誰も疑惑を抱くことはありません。数が多いことは安全であることを意味します。同様に、意識するしないにかかわらず、すべての人がすべての E メールを暗号化することが一般的になれば、暗号化を行うことによって E メールのプライバシーを主張したとしても誰も疑惑を抱かなります。皆が同じ意見を持っていることを具体的な形にしたものであると考えてください。

今日、政府が一般市民のプライバシーを侵害しようとした場合、郵便物を開封して通信を傍受したり、電話の会話を盗聴して筆記したりするといった手段を使いますが、これには一定額のコストや人手が必要になります。大きな労働力を要するこのような監視行為を大規模に行うことは、現実的には不可能です。このような行為は、通信を傍受する価値があると思われるような重要なケース以外では行われません。

私たちのプライベートな通信は、電子的な通信路を通じて配信される機会がますます多くなっています。電子メールは、次第に従来の郵便にとって代わりつつあります。E メールは、簡単に傍受したり、興味のあるキーワードを探したりすることができます。このような行為は、簡単に、日常的に、自動的に、そして誰にも気付かれずに大規模に行うことができます。NSA (National Security Agency: 国家安全保障局) は、すでにこのような方法を使って国際海底電信を大規模にチェックしています。

今後、国中に光ファイバーのデータネットワークが張り巡らされるようになり、普及し続けているパーソナルコンピュータのすべてがこのようなネットワークによって接続されるようになります。現在、E メールは目新しい物ですが、誰もが普通に利用するようになります。政府は自らが考案した暗号化規約を使って、私たちの E メールを保護するつもりでいます。ほとんどの人は、このようなシステムに黙って従うでしょうが、自分独自の保護手段を利用したいと考える人もいるでしょう。

上院議案 266 号(包括的な犯罪防止に関する議案)には、人々を不安にさせるような施策が盛り込まれています。拘束力のないこのような解決策が立法化されればセキュリティ保護された通信を提供する機器のメーカーは製品に「トラップドア」を挿入することを義務付けられ、政府はすべての人のメッセージを読むことができるようになります。議案の内容は、「法律でしかるべく規定することによって、電子通信サービスを提供する企業および電子通信サービス機器のメーカーは、音声、データなどによる通信の内容を政府が平文形式で読み取れるような通信システムを使うことを義務付けることが議会の意向である」です。このような対策案は、一般市民の自由論者や産業界の激しい反対によって否決されました。

1992 年、FBI のデジタルテレフォニー盗聴案が議会に提出されました。この法案は、すべての通信機器メーカーに特殊な遠隔盗聴ポートを機器に組み込むことを義務付けることによって、電子的な通信すべてを FBI の各部署から遠隔盗聴できるようにするというものでした。1992 年の議会では、市民から反対されたため、この法案を支持するものは誰もいませんでしたが、1994 年に同じ法案が再提出されました。

最も大きな不安感を与えるものは、ブッシュ政権の発足後 NSA で進められ、1993 年 4 月に発表されたホワイトハウスの大胆な暗号化方針構想です。この構想の中心となるものは、政府が製作した「クリッパー」チップと呼ばれる暗号化デバイスであり、このデバイスには新しく機密指定された NSA 暗号化アルゴリズムが使われています。政府は、民間産業のセキュアフォン、セキュアファックスといった通信関連の全製品にこのアルゴリズムを組み入れることを推奨しています。現在 AT & T は、同社の音声関連のセキュア製品にクリッパーを組み入れています。これにはわなが仕掛けられています。つまり、1 つ 1 つのクリッパーチップは製造時に固有の鍵を使って組み込まれるので、政府はコピーを第三者預託してそれを保持できるということです。しかし、心配する必要はありません。法律によって正当に許可されている場合以外は、このような鍵を使って通信経路を読み取らないことを政府は約束しているからです。もちろん、クリッパーを完全に有効なものにするためには、必然的にほかの形態の暗号方法を法律で禁止する必要があります。

プライバシーを保護することが法律で禁止されるようなことがあれば、法律に違反しないかぎりプライバシーを保護できないことになります。諜報機関は、優れた暗号化技術を利用できます。権力を持つ組織やドラッグの取り引き人も優れた暗号化技術を利用できます。防衛関係の請負業者、石油会社、大手の企業も同様です。それに対して、一般市民や政治的な草の根団体のほとんどは、これまで軍用レベルの公開鍵暗号化技術を利用することはできませんでした。

PGP を利用すると、一般の人もプライバシーを確保できます。そのような必要性は、社会的に大きくなっています。この文章を書いたのは、そのような理由からです。


==================
PGP の仕組み
==================
暗号化技術全般の概念や特定の公開鍵暗号化技術を理解しておくことは有用なことですが、このセクションでは、公開鍵の暗号化技術に関する初歩的な内容だけを紹介することにします。

まず、いくつかの基本的な用語について説明します。送信するメッセージの内容を、その受信者以外には読まれたくないとします。このような場合に、メッセージを「暗号化」します。暗号化するとは、解読不可能な複雑な方法を使ってメッセージの内容をかき混ぜ、本来の受信者以外がその内容を読めないようにすることです。メッセージの送信者は、メッセージを暗号化するのに使った暗号「鍵」を送ります。受信者はこの鍵を使ってメッセージを解読、つまり「復号化」します。簡単に言うと、これが従来の「単一鍵」による暗号化システムの仕組みです。

米国のデータ暗号化標準規格(DES: Data Encryption Standard)など、従来の暗号化システムでは、暗号化と復号化の両方の処理において単一の同じ鍵が使われます。つまり、まずセキュリティ保護された通信路を使って鍵を送ることによって両者が鍵を知っている状態にしたあと、暗号化されたメッセージをセキュリティ保護されていない通信路で送信するということです。これは不便な方法です。鍵を安全に交換できるのであれば、そもそも暗号化を行う必要はないと言えます。

公開鍵を使う暗号化システムでは、すべての人がお互いに関連性のある補完的な 2 つの鍵を持ちます。一般公開されている鍵と第三者には知られていない鍵(一般的には秘密鍵と呼ばれています)です。一方の鍵を使って、もう 1 つの鍵で作成したコードを解読します。公開鍵を知っていても、それに対応する秘密鍵は容易に推測することはできません。公開鍵は、公開したり通信ネットワークを使って配信したりしてもかまいません。このような規約のおかげで、従来の暗号化システムで必要とされていたセキュリティ保護された通信路を使わなくてもプライバシーが実現します。

受信者の公開鍵を使うと誰でもメッセージを暗号化できます。受信者は公開鍵に対応する専用の秘密鍵を使ってメッセージを復号化します。受信者以外はメッセージを復号化できません。第三者は絶対にその秘密鍵にアクセスできないからです。メッセージを暗号化した人でさえ、復号化することはできません。

メッセージ送信者の本人確認を行うこともできます。送信者が所有する秘密鍵を使うと、メッセージを暗号化して「署名」を付加することができます。この方法を使うと、メッセージのデジタル署名が作成されるので、受信者(および第三者)は、送信者の公開鍵を使ってメッセージを復号化することによって署名を確認できます。デジタル署名が付加されていると、メッセージの発信人と送信者が同一人物であること、そしてメッセージが送信後に第三者によって改ざんされていないことがわかります。その署名を作成するのに使われた秘密鍵を所有しているのは、メッセージの送信者だけだからです。署名付きのメッセージを偽造することは不可能であり、あとになってその署名が自分のものではないと言うこともできません。

これらの 2 つの方法を組み合わせると、自分の秘密鍵を使ってメッセージに署名したあと、受信者の公開鍵を使って署名付きのメッセージを暗号化することによって、プライバシーと本人確認の両方が実現します。受信者は逆の手順を実行します。つまり、自分の秘密鍵を使ってメッセージを復号化したあと、送信者の公開鍵を使って署名を確認します。このような手順は、受信者のソフトウェアによって自動実行されます。

公開鍵の暗号化アルゴリズムは、従来の単一鍵の暗号化と比べて各段に低速であるため、メッセージの暗号化には、従来の高品質で高速な単一鍵による暗号化アルゴリズムを使ったほうが質の高い暗号化を行えます。暗号化されていない元のメッセージは「平文」と呼ばれます。ユーザーに見えないプロセスにおいて、この 1 回の「セッション」のためだけに作成された一時的な無作為鍵を使って、従来どおりに平文ファイルを暗号化します。次に、受信者の公開鍵を使って、この従来の一時的な無作為鍵を暗号化します。公開鍵を使って暗号化されたこのような従来の「セッション」鍵は、暗号化されたテキスト(「暗号文」と言います)と一緒に送信します。受信者は、自分の秘密鍵を使ってこの一時的なセッション鍵を復号化したあと、その鍵を使って従来の高速な単一鍵アルゴリズムを実行してサイズの大きい暗号文メッセージを復号化します。

公開鍵は、個々の「鍵証明書」に格納されます。鍵証明書には、鍵の所有者のユーザー ID(その人の名前)、2 つの鍵が作成された日時を表すタイムスタンプ、そして鍵に関する実際の情報が記載されています。公開鍵の証明書には公開鍵に関する情報が、そして秘密鍵の証明書には秘密鍵に関する情報が格納されます。また、秘密鍵は、盗まれた場合に備えて独自のパスワードで暗号化されています。鍵ファイル、つまり「キーホルダー」には、このような鍵の証明書が 1 つまたは複数保存されています。公開鍵のキーホルダーには公開鍵の証明書が、そして秘密鍵のキーホルダーには秘密鍵の証明書が格納されています。

また、それぞれの鍵は「鍵 ID」によって内部参照されています。鍵 ID には、公開鍵の短縮形(サイズの大きい公開鍵の下位 64ビットが使われます。この鍵の ID の表示時には、簡略化するために下位 32 ビットのみが示されます。ユーザー ID は、複数の鍵に対して同じものを使うことができます。現実的には、鍵 ID は鍵ごとに異なるからです。

PGP では、「メッセージダイジェスト」を使って署名を作成します。メッセージダイジェストとは、メッセージに 128 ビットの暗号強度を持たせた一方向的なハッシュ関数のことです。メッセージダイジェストはメッセージをコンパクトに表したものであるという点、そしてメッセージの変更を検出するために使うという点においては、「チェックサム」や CRC エラーチェックコードと似ているとも言えます。CRC と異なる点は、まったく同じメッセージダイジェストを生成するような別のメッセージを考え出すことによって攻撃を行うことが計算上不可能であることです。メッセージダイジェストは秘密鍵を使って暗号化され、署名が生成されます。

文書に署名する場合は、文書の先頭に署名の証明書を付加します。この証明書には、署名を付けるときに使った鍵の ID、秘密鍵によって署名を行った文書のメッセージダイジェスト、署名日時を示すタイムスタンプが格納されます。鍵 ID は、受信者が送信者の公開鍵を調べて署名を確認するときに使います。送信者の公開鍵と受信者の公開鍵のキーホルダーに登録されているユーザー ID は、受信者のソフトウェアによって自動的にチェックされます。

暗号化されたファイルの先頭には、そのファイルを暗号化するのに使った公開鍵の ID が付加されます。受信者は、この鍵 ID のメッセージプレフィクスを使って、メッセージを復号化するのに必要な秘密鍵を見つけ出します。受信者の秘密鍵のキーホルダーに登録されている復号化に必要な秘密鍵は、受信者のソフトウェアによって自動的にチェックされます。

このような 2 種類のキーホルダーを使うことが、公開鍵と秘密鍵の保存と管理における基本的な方法となっています。個々の鍵を別々の鍵ファイルに保存しておくのではなく、キーホルダーにまとめておくことによって、鍵 ID またはユーザー ID のいずれかによって鍵を自動検索することが容易になります。各ユーザーが、独自のキーホルダーを 2 つ保有します。個々の公開鍵は、それを受け取った人がその人のキーホルダーに保存するまでの間、別のファイルに一時的に保存されます。


==================
PGP のインストール
==================
MSDOS版の PGP パッケージは、PGPxx.ZIP(xx の部分には、バージョンによって異なる数字が入ります)という名前の圧縮ファイルで配布されています。たとえば、バージョン 2.6 のパッケージは PGP26.zip となります。圧縮ファイルを解凍するには、PKUNZIPという解凍ユーティリティ(MSDOS 用のシェアウェア)や unzip(Unix のユーティリティ)を使います。解凍後の PGP のリリースパッケージには、さまざまなファイルが格納されています。その中の 1 つに README.doc という名前のファイルがあります。必ずこのファイルを読んでから、PGP をインストールしてください。README.doc ファイルには、パッケージに付属するほかのすべてのファイルの内容だけでなく、PGP のこのパッケージの最新情報に関して後日発表されたニュースも記載されています。

古いバージョンの PGP がインストールされている場合は、新しいバージョンの PGP との間で名前の競合が発生しないように、ファイルの名前を変更するか削除してください。

PGP のインストールに関する詳細については、このパッケージに付属する SETUP.doc ファイルに記載された『PGP インストールガイド』を別途参照してください。PGP ディレクトリと AUTOEXEC.BAT ファイルの設定方法、PKUNZIP を使って PGP をインストールする方法の詳細が記載されています。詳しいインストールマニュアルを読んでいる時間がない方のために、このファイルでインストール手順を簡単に説明します。

MSDOS システムに PGP をインストールするには、圧縮された状態の PGPxx.ZIP ファイルをハードディスクの適当なディレクトリ(C:\PGP など)にコピーしたあと、PKUNZIP を使って解凍します。最適な結果を得るためには、このマニュアルの別のセクションでも説明しているように、AUTOEXEC.BAT ファイルにも変更を加える必要があります。ただし、変更作業を行うのは、PGP を少し使ってみたり、このマニュアルをじっくり読んだりしたあとでかまいません。これまでに PGP を実行したことがない場合は、インストール後(およびこのマニュアルを読んだあと)にまず行わなければならないことがあります。それは、PGP の鍵生成コマンド(pgp -kg)を実行して、1 組の鍵を作成することです。まず、マニュアルの「RSA 鍵の作成」のセクションを読んでください。

UNIX や VAX/VMS にインストールする場合も、MSDOS にインストールする場合と手順はほとんど同じですが、まずソースコードをコンパイルする必要があるかもしれません。ソースリリースには、ソースコードをコンパイルするための Unix makefile が付属しています。



==================
PGP の使い方
==================

使用方法の概略を表示する
----------------------
PGP コマンドの使い方の概略を表示するには、以下のように入力します。

 pgp -h


メッセージの暗号化
--------------------
受信者の公開鍵を使って平文ファイルを暗号化するには、以下のように入力します。

pgp -e textfile her_userid

このコマンドを実行すると、textfile.pgp という名前の暗号文ファイルが生成されます。以下に具体例を示します。

pgp -e letter.txt Alice
または
pgp -e letter.txt "Alice S"

1 つ目の例では、ユーザーの公開鍵のキーホルダーファイル(pubring.pgp)を対象に、ユーザー ID フィールドに「Alice」という文字列が存在する公開鍵証明書が検索されます。2 つ目の例では、「Alice S」という文字列を含むユーザー ID が検索されます。コマンドラインで指定する文字列にスペースを使いたい場合は、文字列全体を引用符で囲んでください。検索では、大文字と小文字は区別されません。該当する公開鍵が見つかったら、その鍵を使って平文ファイル(letter.txt)が暗号化され、letter.pgp という名前の暗号文ファイルが生成されます。

平文を圧縮してから暗号化を行うため、暗号解読の困難さが大幅に向上しています。このような方法で暗号化を行うため、一般的に暗号文ファイルは平文ファイルよりもサイズが小さくなります。

暗号化したメッセージを E メールで送りたい場合は、-a オプションを指定して、表示可能な ASCII radix-64 フォーマットに変換します。具体的な方法については、このあと説明します。



メッセージを暗号化して複数の相手に送信する
-------------------------------------------

1 つのメッセージを複数の相手に送信したい場合は、複数の相手に送信するメッセージの暗号化を指定します。これで、受信者全員がその暗号ファイルを復号化できるようになります。複数の受信者を指定するには、コマンドラインに複数のユーザー ID を記述します。以下に例を示します。

pgp -e letter.txt Alice Bob Carol

このコマンドを実行すると、letter.pgp という名前の暗号文ファイルが生成されます。このファイルは、Alice、Bob、Carol が復号化できます。指定できる受信者の数に制限はありません。



メッセージに署名する
-----------------

ユーザーの秘密鍵を使って平文ファイルに署名するには、以下のように入力します。

pgp -s textfile [-u your_userid]

[ ] は、オプションのフィールドを表しています。実際にこのカッコを入力する必要はありません。注意してください。

このコマンドを実行すると、textfile.pgp という名前の署名付きファイルが生成されます。以下に具体例を示します。

pgp -s letter.txt -u Bob

この例では、ユーザーの秘密鍵のキーホルダーファイル(secring.pgp)を対象に、ユーザー ID フィールドに「Bob」という文字列が存在する秘密鍵証明書が検索されます(ユーザーの名前が Bob の場合)。検索では、大文字と小文字は区別されません。該当する秘密鍵が見つかったら、その鍵を使って平文ファイル(letter.txt)に署名が付けられ、letter.pgp という名前の署名ファイルが生成されます。

ユーザー ID を指定しないと、秘密鍵のキーホルダーに登録されている最初の鍵がデフォルトの鍵として使われます。

PGP では、メッセージを圧縮してから署名を付加します。したがって、一般的に署名付きのファイルは元のファイルよりもサイズが小さくなり、保存するのに便利です。このような処理を行うことによって、元のメッセージが普通の ASCII テキストで書かれていたとしても、一般的な管理者がファイルを読むことができなくなります。人間が直接読むことができないような署名付きファイルを作成できたとしたらすばらしいことです。署名付きのメッセージを E メールとして送信したい場合に、特に便利です。

E メールに署名する場合は、一般的に人間が読めるような形式にしたいはずです。このような場合は、CLEARSIG 機能を利用すると便利でしょう。CLEARSIG 機能については、あとで説明します。この機能を利用すると、テキストの最後に表示可能な形式で署名が表示されるだけでなく、テキストの圧縮も行われなくなります。つまり、受信者は PGP を使って署名を確認しなくても、テキストを読むことができるということです。これについては、「CLEARSIG - 署名付きメッセージを判読可能な形式でカプセル化する機能」というセクションで詳しく説明します。マニュアルのそのセクションまで待てない方のために、以下の例を使って、CLEARSIG 機能を使って署名が付けられた E メールがどのように表示されるかを示します。

pgp -sta message.txt

このコマンドを実行すると、message.asc ファイル内に署名付きメッセージが作成されます。message.asc ファイルは、人間が判読可能な形式の元のテキストと表示可能な ASCII 形式の署名証明書が格納され、E メールで送信できます。この例では、設定ファイルで CLEARSIG フラグを有効にする通常の設定を指定していることを前提にしています。


署名を付けたあと暗号化する
---------------------------

秘密鍵を使って平文ファイルに署名したあと、受信者の公開鍵を使って暗号化するには、以下のように入力します。

pgp -es textfile her_userid [-u your_userid]

[ ] は、オプションのフィールドを表しています。実際にこのカッコを入力する必要はありません。注意してください。

この例では、textfile.pgp という名前の入れ子形の暗号文ファイルが生成されます。署名を生成するのに使った秘密鍵は、秘密鍵のキーホルダーを対象に your_userid を使って自動的に検索されます。受信者の公開鍵は、ユーザーの公開鍵のキーホルダーを対象に her_userid を使って自動的に検索されます。コマンドラインに受信者のユーザー ID を指定しなかった場合は、ユーザー ID を指定するように指示されます。

自分のユーザー ID を指定しないと、秘密鍵のキーホルダーに登録されている最初の鍵がデフォルトの鍵として使われます。

PGP では、平文を圧縮してから暗号化を行います。

暗号化したメッセージを E メールで送りたい場合は、-a オプションを指定して、表示可能な ASCII radix-64 フォーマットに変換します。具体的な方法については、このあと説明します。

複数の受信者を指定するには、コマンドラインに複数のユーザー ID を記述します。



従来の暗号化方式のみを使う
----------------------------------

従来の方法(単一鍵による暗号化)でファイルを暗号化するので十分な場合もあります。この方法は、保存だけして誰にも送信しないようなアーカイブファイルを保護する場合に便利です。ファイルを暗号化する人と復号化する人が同じであるため、実際には公開鍵による暗号化を行う必要がありません。

従来の暗号化方式を利用して平文ファイルを暗号化するには、以下のように入力します。

pgp -c textfile

この例では、公開鍵による暗号化、キーホルダー、ユーザー ID といったものを使わずに、textfile という名前の平文ファイルが暗号化され、textfile.pgp という名前の暗号文ファイルが生成されます。従来の鍵として使うことによってファイルを暗号化する場合は、パスフレーズの入力を求められます。このパスフレーズは、自分の秘密鍵を保護するときに使うパスフレーズと同じものである必要はありません(実際には、同じパスフレーズを使わないほうがよいでしょう)。PGP では、平文を圧縮してから暗号化を行います。

毎回同じパスフレーズを使ったとしても、同じ平文を暗号化する際に同じ方法は二度と使われません。



復号化と署名の確認
----------------------------------

暗号化されたファイルを復号化したり、署名付きファイルの署名の妥当性を確認したりするには、以下のように入力します。

pgp ciphertextfile [-o plaintextfile]

[ ] は、オプションのフィールドを表しています。実際にこのカッコを入力する必要はありません。注意してください。

暗号文ファイルの名前には、デフォルトの拡張子である .pgp を使うことを前提としています。オプションとして平文の出力先ファイルの名前を指定すると、処理済みの平文出力を保存する場所を指定できます。ファイル名を指定しないと、拡張子を除いた暗号文ファイルの名前が使われます。暗号化されたファイルの内部に署名を入れ子にした場合は、自動的に復号化され、署名の妥当性が確認されます。署名を行ったユーザーの ID は、正式なものが表示されます。

暗号化ファイルに署名だけが付けられている場合、暗号化のみ行われている場合、その両方が行われている場合のいずれにおいても、暗号文ファイルの「開封」は完全に自動的に行われます。PGP では、暗号文ファイル内の鍵 ID プレフィクスを使って、秘密鍵のキーホルダーに登録されている適切な秘密復号鍵が自動的に見つけ出されます。入れ子にした署名が存在する場合は、入れ子になった署名の鍵 ID プレフィクスを使って、公開鍵のキーホルダーに登録されている適切な公開鍵が自動的に見つけ出され、その鍵を使って署名の確認が行われます。キーホルダーにすべての正しい鍵がすでに存在する場合は、必要に応じて秘密鍵のパスワードを入力するように求められる場合もありますが、それ以外ではユーザーが介入する必要はありません。暗号文が公開鍵による従来の暗号技術を使って暗号化されている場合は、PGP はそれを認識して、従来の方法で復号化するためのパスフレーズの入力を要求します。


==================
鍵の管理
==================

ジュリアス・シーザーの時代から、暗号技術における最大の課題は鍵の管理でした。PGP の大きな特長の 1 つとして、高度な鍵管理機能が挙げられます。



RSA 鍵の生成
------------------

指定したサイズの独自の公開鍵と秘密鍵を作成するには、以下のように入力します。

pgp -kg

推奨する鍵のサイズ(「低商用」レベル、「高商用」レベル、「軍用」レベル)がメニュー表示され、希望のサイズを指定するように指示されます(最大 1,000 ビット以上のサイズを指定できます)。鍵のサイズが大きければ大きいほどセキュリティは高くなりますが、速度は低下します。

ユーザー ID、つまりユーザー名の入力も求められます。ユーザー ID には、自分の姓名を使うとよいでしょう。ほかの人が間違った公開鍵を使って自分あてのメッセージを暗号化する危険性が低減するからです。ユーザー ID には、スペースやドット(.)も使用できます。名前のあとに、< > で囲った E メールアドレスを併記しておくと便利です。以下に例を示します。

Robert M. Smith

E メールアドレスを持っていない場合は、電話番号など、自分に固有の情報を使って、自分のユーザー ID がほかの人と同じにならないようにします。

秘密鍵が第三者に知られてしまったときのことを考えて、秘密鍵を保護するための「パスフレーズ」の入力も求められます。このパスフレーズを入力しないかぎり、秘密鍵を使うことはできません。パスフレーズはパスワードと似ていますが、さまざまな単語、スペース、句読点などを自由に使えるフレーズや文章であるという点がパスワードとは異なります。パスフレーズはなくさないようにしてください。なくしてしまったパスフレーズを復元することはできません。パスフレーズは、あとで秘密鍵を使うときに毎回必要になります。パスフレーズでは、大文字と小文字が区別されます。短すぎるものや簡単に推測できるようなものは使わないようにしてください。画面上には決して表示されません。他人の目に付くような場所にメモしておいたり、コンピュータ内に保存したりしないようにしてください。パスフレーズを指定したくない場合は(決してお奨めしません)、パスフレーズのプロンプトで何も入力せずに Enter キーを押します。

公開鍵と秘密鍵は、高速タイマーを使ってユーザーの打鍵間隔を測定することによって生成した完全な乱数(大きな数字)を使って生成されます。PGP では、無作為な文字をユーザーに入力するように指示することによって、ランダムビットの一部を蓄積して鍵を作成します。文字の入力を指示されたら、タイピングの間隔が十分にランダムになるようにキーを押してください。意味を成さないような文字列を入力してもかまいません。入力内容の予測不可能性によってランダム性が生じることもあるので、同じ文字を連続して入力しないようにしてください。

RSA 鍵の生成は時間のかかるプロセスです。高速プロセッサを使ってサイズの小さい鍵を作成する場合でも数秒、旧式の IBM PC を使ってサイズの大きな鍵を作成する場合は数分かかリます。PGP では、鍵生成の進行状態が視覚的にわかるような形式で表示されます。

生成された公開鍵と秘密鍵は、公開鍵のキーホルダーと秘密鍵のキーホルダーに保存されます。新しく作成した公開鍵は、あとで -kx コマンドオプションを使うことによって公開鍵のキーホルダーから取り出して(コピーして)、友人に配布するのに適した別の公開鍵のキーホルダーに保存することができます。公開鍵ファイルは、友人の公開鍵のキーホルダーに格納して友人に送ることができます。当然、ユーザーは自分の秘密鍵ファイルを保存しておきます。ファイルは、秘密鍵のキーホルダーに保存します。キーホルダーに保存された個々の秘密鍵は、個別のパスフレーズによって個別に保護されます。

秘密鍵は絶対に他人に渡さないようにしてください。同様の理由で、公開鍵と秘密鍵の組み合わせは友人にも渡さないようにしてください。すべてのユーザーは、自分独自の公開鍵と秘密鍵を作成する必要があります。秘密鍵は常に物理的に管理してください。リモートのタイムシェアリングコンピュータ上に保存すると、他人に知られてしまうおそれがあります。自分のコンピュータに保存しておいてください。

『PGP ユーザーズガイド』がお使いのコンピュータ上に見つからないため、公開鍵と秘密鍵を作成できないというメッセージが表示されてもあわてないでください。『PGP ユーザーズガイド』の「特殊事項」編の「設定パラメータの設定」セクションで、NOMANUAL パラメータの説明を参照してください。


キーホルダーに鍵を登録する
-----------------------------

ほかの人から送られてきた鍵を、鍵ファイルという形でキーホルダーに保存したい場合もあると思います。

公開鍵ファイルや秘密鍵ファイルを公開鍵のキーホルダーや秘密鍵のキーホルダーに保存するには、以下のように入力します([ ] は、オプションのフィールドを表しています。注意してください)。

pgp -ka keyfile [keyring]

鍵ファイルのデフォルトの拡張子は .pgp です。キーホルダーファイルのオプションのファイル名は、デフォルトで pubring.pgp または secring.pgp になります。どちらのファイル名が使われるかは、鍵ファイルに保存されている鍵の種類(公開鍵または秘密鍵)によって決まります。キーホルダーファイルには別の名前を指定してもかまいません。この場合、拡張子はデフォルトで .pgp になります。

対象となる鍵がキーホルダーにすでに保存されている場合、その鍵は保存されません。重複しているものを除いて、鍵ファイルのすべての鍵がキーホルダーに登録されます。

署名を使って鍵を認証するという概念については、このマニュアルでこのあと説明します。登録する鍵にそれを認証する署名が付加されている場合は、その署名も鍵と一緒に登録されます。対象となる鍵がすでにキーホルダーに登録されている場合、キーホルダーにまだ登録されていないその鍵の任意の新しい認証署名に統合されます。

PGP は本来、サイズの小さい個人のキーホルダーを扱うことを前提に作成されたものです。非常にサイズの大きいキーホルダーを扱いたい場合は、「特殊事項」編の「サイズの大きい公開鍵のキーホルダーを処理する」のセクションを参照してください。



キーホルダーから鍵やユーザー ID を削除する
--------------------------------------------

キーホルダーから鍵やユーザー ID を削除するには、以下のように入力します。

pgp -kr userid [keyring]

このコマンドを実行すると、指定したユーザー ID がキーホルダーを対象に検索され、一致するものがあった場合は削除されます。検索時には、ユーザー ID の一部でも一致していれば、該当するユーザー ID が探し出されます。キーホルダーファイルのオプションの名前が pubring.pgp の場合に、秘密鍵を削除したいのであれば、pubring.pgp は省略できます。または、secring.pgp を指定してもかまいません。別のキーホルダーファイルの名前を指定することもできます。キーホルダーファイルのデフォルトの拡張子は .pgp です。

対象となる鍵に対して複数のユーザー ID が存在する場合は、指定したユーザー ID だけを削除し、鍵とその鍵のほかのユーザーはそのまま残しておくかどうかを確認するように指示されます。



キーホルダーに登録されている鍵を取り出す(コピーする)
---------------------------------------------

秘密鍵または公開鍵のキーホルダーから鍵を取り出す(コピーする)には、以下のように入力します。

pgp -kx userid keyfile [keyring]

このコマンドを実行すると、ユーザー ID によって指定された鍵が公開鍵または秘密鍵のキーホルダーから指定の鍵ファイルにコピーされます。このとき、キーホルダーの内容は変更されません。自分の公開鍵のコピーをほかの人に渡したいときに使うと非常に便利です。

キーホルダーの鍵に認証署名が添付されている場合は、鍵と一緒に署名もコピーされます。

取り出した鍵を表示可能な ASCII テキストにして、E メールで送信できるようにしたい場合は、-kxa オプションを使います。



キーホルダーの内容を確認する
-------------------------------------

キーホルダーの内容を確認するには、以下のように入力します。

pgp -kv[v] [userid] [keyring]

このコマンドを実行すると、キーホルダーに登録されている鍵の中で、指定したユーザー ID のサブストリングと一致するものがすべてリストされます。ユーザー ID の指定を省略した場合は、キーホルダーに登録されているすべての鍵がリストされます。オプションの keyring で指定するファイル名が pubring.pgp の場合、pubring.pgp は省略できます。秘密鍵をリストしたいのであれば、secring.pgp を指定してもかまいません。キーホルダーファイルには別の名前を指定することもできます。キーホルダーファイルの拡張子はデフォルトで .pgp になります。

署名を使って鍵を認証するという概念については、このマニュアルでこのあと説明します。各鍵に添付されているすべての認証署名を確認する場合は、以下のように kvv オプションを使います。

pgp -kvv [userid] [keyring]

特定のキーホルダーファイルの名前を指定して、しかもそのファイルに登録されているすべての鍵を確認したい場合は、以下のように入力してもかまいません。

pgp keyfile

コマンドオプションを指定しないと、keyfile.pgp に保存されているすべての鍵がリストされ、それらがキーホルダーに登録されていない場合は登録されます。



公開鍵の改ざんを防止する方法
-----------------------------------------

公開鍵を使う暗号化システムでは、公開鍵の漏洩を防止する必要はありません。実際に、公開鍵は広く配布するほうが望ましいと言えます。しかし、公開鍵の改ざんを防止することは重要です。その公開鍵の所有者が本当に正当な所有者である必要があるからです。これが、公開鍵を利用した暗号化システムの最大の弱点であると言えるかもしれません。まず、どのような惨事が起こる可能性があるのかを考え、次に PGP を使ってそのような事態の発生を安全に防止する方法を考えてみましょう。

アリスにプライベートなメッセージを送りたいとします。まず、アリスの公開鍵証明書を電子掲示板(BBS)からダウンロードしたあと、この公開鍵を使ってアリスあてのメッセージを暗号化します。暗号化したメッセージは、BBS の E メール機能を利用してアリスに送ります。

しかし、困ったことに、あなたもアリスも知らないチャーリーという名前の別のユーザーが BBS に潜入し、添付されているアリスのユーザー ID を使って自分の公開鍵を作成していました。そして、自分のにせの鍵とアリスの本当の公開鍵をこっそり取り換えました。あなたはアリスの公開鍵ではなく、チャーリーが所有するこのにせの鍵をそれとは知らずに使ってしまいます。にせの鍵にはアリスのユーザー ID が使われているため、間違った鍵であることには気付きません。チャーリーは公開鍵に対応する秘密鍵を持っているため、アリスあてのメッセージを復号化できます。アリスの本当の公開鍵を使って復号化したメッセージを再度暗号化してアリスに送れば、誰にも疑われることはありません。また、チャーリーはこの秘密鍵を使って、いかにも正しく見えるアリスの署名を作成することもできます。アリスの署名を確認する際に、必ずにせの公開鍵が使われるからです。

このような惨事を防止する唯一の方法は、公開鍵を絶対に改ざんさせないことです。公開鍵をアリスから直接受け取った場合は問題ありません。しかし、アリスが非常に遠方に住んでいたり、現在連絡が取れない状況である場合は、直接受け取ることは難しいかもしれません。

あなたとアリスの両方が信用できる友人であるデービッドがアリスの公開鍵の正当なコピーを持っている場合は、デービッドからアリスの公開鍵を手に入れるという方法が考えられます。デービッドがアリスの公開鍵に署名することによって、アリスの公開鍵が本物であることを保証できます。デービッドが署名を作成する際には、デービッドの秘密鍵を使います。

このような方法によって、署名付き公開鍵証明書を作成し、アリスの公開鍵が改ざんされていないことを証明できます。この場合、正当であることがわかっているデービッドの公開鍵のコピーを使って、デービッドの署名を確認する必要があります。デービッドは、あなたの公開鍵の署名付きコピーをアリスにも渡すことができるでしょう。デービッドは、このような方法であなたとアリスとの間の「仲介者」としての役割を果たします。

アリスのこの署名付き公開鍵証明書は、デービッドまたはアリスが BBS にアップロードしたあと、あなたがダウンロードします。そのあとあなたはデービッドの公開鍵を使って署名を確認し、それが本当にアリスの公開鍵であることを確認します。にせの鍵をアリスの鍵として使わせることは絶対にできません。デービッドの署名は絶対に偽造できないからです。

信用度合いが高い人であれば、公開鍵証明書に署名を付与することによって、このようなユーザー「仲介」サービスを専門に扱うことも可能です。この信頼性の高い人を「キーサーバー」、つまり「認証局」とみなすことができます。キーサーバーの署名が付与されている公開鍵証明書は、鍵の所有者が正当な所有者であるものとして信頼できます。正当なものであることがわかっているキーサーバーの公開鍵のコピーさえあればキーサーバーの署名を確認できるので、このサービスを利用することができます。

信頼性の高い統合的キーサーバー(認証局)は、一元管理されている非民間組織や政府機関に最適です。階層構造の認証局を使っている機関もあります。

分権化傾向が強い「ゲリラスタイル」の環境では、統合キーサーバーを利用するよりも、すべてのユーザーが友人に対して信頼できる仲介者の役割を果たしたほうがうまく機能するでしょう。PGP では、このような分権的かつ非組織な方法の重要性を主張しています。この方法では、個人的な社会レベルにおける人間どうしのやり取りが反映されており、信頼できる人を上手に選んで鍵の管理を行うことができます。

公開鍵の改ざんを防止するこのビジネス全体が、実用的な公開鍵の利用における唯一そして最大の問題です。これが、公開鍵による暗号化技術のアキレス腱であり、この 1 つの問題を解決するためにソフトウェアが複雑にならざるをえなくなっています。

公開鍵を使うときは、それが改ざんされていない正当な公開鍵であること、そして鍵の所有者が本当の所有者であることを確認してから使ったほうがよいでしょう。鍵をその所有者から直接受け取った場合やすでに正当な公開鍵を受け取っている信用できる人の署名が鍵に付与されている場合は、これらのことを確認できます。また、ユーザー名には鍵の所有者の名だけでなく姓名を使います。

いくら便利だからといって(実際に便利ですが)、信用のできる人の署名が付いている鍵でなければ、掲示板に公開鍵をアップロードしたり、掲示板から公開鍵をダウンロードしたりすることは絶対にやめてください。正当性が確認されていないそのような公開鍵は第三者によって、場合によっては掲示板の管理者によって改ざんされている可能性もあります。

ほかの人の公開鍵証明書に署名することを依頼された場合は、その鍵の所有者が公開鍵証明書のユーザー ID に記載された人と本当に同一の人であることを確認してください。その人の公開鍵証明書に署名するということは、その公開鍵が本当にその人のものであることを証明することになるからです。あなたの署名が付加されているので、あなたを信用している人であれば、その人の公開鍵が正当なものであると考えます。根拠のないうわさを信じるのは軽率なことです。その公開鍵が本当にその人のものであることを自分自身で確認できない場合は、署名しないでください。公開鍵を本人から直接受け取った場合以外は、署名をしないのが望ましいことです。

公開鍵に署名する場合は、単にその鍵を使ってメッセージを暗号化したいという理由からではなく、その鍵の所有者をしっかりと確認できる必要があります。鍵を使っても大丈夫であるという正当性を確認するには、信用できる仲介者の認証署名があれば十分です。ただし、自分自身で署名を行う場合は、その鍵の所有者を自分自身で確認できる必要があります。鍵の所有者に電話をして、鍵ファイルの内容をその人に読んで聞かせ、その鍵が本当にそのひとのものであることを確認してもらうと同時に、話している相手が本当に鍵の所有者であることを確認するとよいでしょう。詳細については、特殊事項編の「電話で公開鍵を確認する」のセクションを参照してください。

公開鍵証明書に署名するということは、その人の人間としての正当性を保証することではなく、単にその人の公開鍵の正当性(その人が鍵の所有者であること)を保証することです。鍵が本当にその人のものであることに確信がある場合は、社会病質者の公開鍵に署名したからといって、署名者の信用がなくなることはありません。あなたの署名が付与されているので、あなたを信用する第三者はその鍵の所有者が本当にその人であると考えますが、その鍵の所有者を信用するわけではありません。鍵を信用することと鍵の所有者を信用することは別のことです。

信用というものは必ずしも引き継がれるものではありません。私には、嘘をつかないと信じている友人がいます。この友人はだまされやすい性格をしており、大統領はうそをつかないと信じています。だからといって、私も大統領はうそをつかないと思っているわけではありません。これは、当然のことです。鍵に付与されているアリスの署名を私が信用し、そして鍵に付与されたチャーリーの署名をアリスが信用しているからといって、鍵に付与されているチャーリーの鍵を私が信用しなければならないということにはなりません。

公開鍵とともにできるだけ多くの「仲介者」の証明をともに保管しておくと、その中のどれかが信用される可能性が高まるので便利です。自分の鍵にさまざまな認証署名を添付して、さまざまな電子掲示板にアップロードしておくこともできます。ほかの人の公開鍵に署名する場合は、その鍵と署名をその人に返送して、その人が自分の公開鍵の認証コレクションに追加できるようにします。

PGP には、公開鍵のキーホルダーに登録された鍵の中で、ユーザーが信用する仲介者の署名によって適切に認証されたものを記録しておく機能が備わっています。ユーザーは仲介者として信用できる人を PGP に登録し、自分の最大限に信用できる鍵を使って仲介者の鍵を認証するだけでかまいません。PGP はそれを取り出し、ユーザーが指定した仲介者の署名が付与されているほかの鍵を自動的に有効化します。もちろん、ユーザー自身が直接ほかの鍵に署名してもかまいません。これについては、あとで詳しく説明します。

自分の公開鍵のキーホルダーは絶対に改ざんできないようにしてください。署名付きの新しい公開鍵証明書は最終的に、すでに自分の公開鍵のキーホルダーに登録されている信用できる公開鍵の正当性に依存するようにする必要があります。自分の公開鍵のキーホルダーは、物理的な方法で管理してください。秘密鍵のときと同様、リモートのタイムシェアリングシステムではなく自分のコンピュータに保存することが望ましいと言えます。これは、改ざんを防止するためであり、漏洩を防止するためではありません。公開鍵のキーホルダーと秘密鍵のキーホルダーの信用できるバックアップコピーを作成し、書き込みを禁止したメディアに保存しておいてください。

信用できる自分の公開鍵は、キーホルダーに登録されているほかのすべての鍵を直接的、または間接的に認証するための最終的な根拠として使われるため、改ざんを防止しなければならない最も重要な鍵です。最終的に信用できる自分の公開鍵が改ざんされていないかどうかを確認するには、PGP の設定を変更して、自分の公開鍵と書き込みを禁止したメディアに保存してあるバックアップコピーが自動的に比較されるようにします。詳細については、特殊事項編でキーホルダー確認するための kc コマンドに関する説明を参照してください。

PGP では、一般的にユーザーがシステムやキーホルダーだけでなく、PGP そのもののコピーに対して物理的なセキュリティを維持していることを前提としています。ユーザーのディスクに不正変更を加えることができる侵入者がいたとしたら、理論的には PGP そのものに対しても不正変更を加えることができることになり、PGP が検知すべき鍵の改ざんに対する防止機能の意味がなくなってしまいます。

自分の公開鍵のキーホルダー全体が改ざんされることを防止するには、自分の秘密鍵を使ってキーホルダー全体に署名するといういくぶん複雑な方法もあります。これを行うには、-sb オプションを使ってキーホルダーに署名することによって、公開鍵のキーホルダーの独立した署名を作成します。残念ながら、この方法を使っても、自分の公開鍵の独立した信用できるコピーを保存しておく必要があります。キーホルダー全体を署名するために作成した鍵をチェックする際、公開鍵のキーホルダーに保存されている自分の公開鍵を使うことはできません。その公開鍵がまさにチェックの対象となっているからです。



PGP における有効な鍵の管理方法
------------------------------------------------

このセクションを読む前に、前項の「公開鍵の改ざんを防止する方法」を読んでおいてください。

PGP には、公開鍵のキーホルダーに登録された鍵の中で、ユーザーが信用する仲介者の署名によって適切に認証されたものを記録しておく機能が備わっています。ユーザーは仲介者として信用できる人を PGP に登録し、自分の最大限に信用できる鍵を使って仲介者の鍵を認証するだけでかまいません。PGP はそれを取り出し、ユーザーが指定した仲介者の署名が付与されているほかの鍵を自動的に有効化します。もちろん、ユーザー自身が直接ほかの鍵に署名してもかまいません。

公開鍵の有効性を判断する際、PGP は以下に示すまったく異なる 2 つの基準を使います。これらの 2 つの基準を混同しないようにしてください。

1) 鍵の所有者が本当にその鍵の所有者であるかどうか(信用できる署名によって認証されているかどうか)
2) 鍵の所有者がほかの鍵も正当に認証しているということを信用できるどうか

1 つ目の項目に対する答えは PGP が自動的に計算してくれます。PGP が 2 つ目の項目に答えられるようにするには、ユーザーが明示的に指示する必要があります。2 つ目の項目に対する答えを入力すると、信用できる人間としてユーザーが指定した仲介者が署名したほかの鍵に対する 1 つ目の項目の答を PGP は計算することができます。

信用できる仲介者の署名が付与されている鍵は有効であるとみなされます。信用できる仲介者が所有する鍵自体は、ユーザーまたはほかの信用できる仲介者によって認証されている必要があります。

PGP では、ユーザーが仲介者の役割を果たす場合、ほかの人に対する信用度合いは微妙に異なることがあるという可能性が考慮されています。鍵の所有者に対する仲介者としての信用度合いは、ユーザーの人間としての誠実さだけで決まるわけではありません。鍵管理に関する十分な知識と鍵に署名する際の十分な判断力が備わっているかどうかも信用度合いを決定する要素になります。PGP では、ほかの公開鍵を認証する人を、「不明」、「信用できない」「まずまず信用できる」「完全に信用できる」といったカテゴリーに分類できます。信用に関するこの情報は、キーホルダーに鍵と一緒に保存されます。しかし、キーホルダーに保存されている鍵をコピーした場合、信用に関する情報はコピーされません。信用に関するユーザーの個人的な見解は、極秘項目であるとみなされるからです。

公開鍵の有効性を計算する際には、添付されているすべての認証署名の信用レベルがチェックされます。有効性のウェート付きスコアリングが算出され、まずまず信用できる署名 2 つで 1 つの完全に信用できる署名とみなされます。PGP の判断基準の設定は変更することができます。たとえば、完全に信用できる署名 2 つとまずまず信用できる署名 3 つが揃っていれば有効な鍵とみなされるように設定することもできます。

PGP では、ユーザー自身の鍵が有効であることは自明であるため、その有効性を証明するための仲介者は必要ありません。どの公開鍵がユーザーのものであるかについては、秘密鍵のキーホルダー内で対応する秘密鍵を探すことによって判断されます。また、ほかの鍵の認証に関しては、ユーザー自身が最大に信用できる人間であるとみなされます。

時間経過とともに、信用できる仲介者に指定したいような人の鍵の数が多くなります。信用できる仲介者として指定する人間は、ユーザーによって異なります。どのユーザーの場合も、第三者の認証署名の数は次第に増えるので、それらの署名のうちの少なくとも 1 つまたは 2 つは受信者に信用してもらえるだろうと考えて、多くの署名を鍵と一緒に配布します。したがって、すべての公開鍵に対して、一元管理されていない信頼性の高い信用できる Web が実現します。

このような独特の草の根アプローチは、一元的な管理と一元的な信用が必須であるインターネット PEM (Privacy Enhanced Mail) など、公開鍵の管理に対して政府が標準採用している方法とは大幅に異なります。この標準的な方法は、信用できる人を強要する認証局の階層を基盤としています。PGP で採用されている分散的かつ見込みに基づいて公開鍵の正当性を判断する方法は、その鍵管理アーキテクチャの中心となるものです。PGP では、信用できる人の指定はユーザーが独自に行うことができるため、個人の認証ピラミッドの頂点に存在するのはユーザーということになります。PGP は、自分の安全は自分で守りたい人のためのプログラムです。



秘密鍵の漏洩を防止する方法
------------------------------------------

自分の秘密鍵とパスフレーズは厳重に保護してください。いくら厳重に保護しても、厳重すぎるということはありません。秘密鍵が危険にさらされるようなことがあった場合は、第三者がその秘密鍵を使ってあなたの名前で署名を作成してしまわないうちに、関係するすべての人に早急に知らせたほうがよいでしょう。たとえば、その鍵を使ってにせの公開鍵証明書に署名されてしまう可能性もあり、特にあなたの署名が広く信用されている場合は、多くの人に問題が発生します。そしてもちろん、自分の秘密鍵の正当性に問題があると、あなたあてのすべてメッセージが盗み見されてしまう可能性もあります。

自分の秘密鍵を保護するには、まずは秘密鍵を常に物理的に管理することです。自宅のパーソナルコンピュータや持ち歩いているノートバソコンに保存しておくのであれば問題はありません。常に物理的に管理できるとは限らない職場のコンピュータに保存する場合は、公開鍵と秘密鍵のキーホルダーを書き込み禁止のフロッピーディスクに保存し、職場から離れるときはフロッピーディスクを放置しないようにしてください。リモートのダイアルイン Unix システムなど、リモートのタイムシェアリングシステムに秘密鍵を常時保存しておくことはやめたほうがよいでしょう。モデム回線を盗聴してパスフレーズを盗まれ、リモートシステムに保存されている実際の秘密鍵を知られてしまう可能性があります。秘密鍵は、自分が物理的に管理できるマシン以外では使わないようにしてください。

パスフレーズは、秘密鍵ファイルが保存されているコンピュータ上に保存しないようにしてください。秘密鍵とパスフレーズを同じコンピュータに保存することは、銀行のキャッシュカードと暗証番号を同じ財布に入れておくことと同じくらい危険なことです。パスフレーズと秘密鍵の両方が保存されたディスクには、誰も手を触れて欲しくないはずです。パスフレーズは記憶しておくことが望ましく、頭の中以外のどこにも保存しないのが最も安全です。パスフレーズをどこかに書き留めておく必要があると思うのであれば、厳重に保護してください。パスフレーズは秘密鍵そのものよりも厳重に保護する必要があります。

また、秘密鍵のキーホルダーはバックアップを作成して保存しておいてください。ただし、自分の秘密鍵のコピーを持っているのは自分だけであり、コピーをなくしたら世界中に配布した公開鍵のすべてのコピーが使用できなくなってしまうということを忘れないでください。

PGP で採用されている分散的かつ非組織的な公開鍵の管理方法には独自のメリットがありますが、どの鍵の正当性が信用できないかを示す一元的な 1 つのリストを信頼できないというデメリットもあります。そのため、秘密鍵の漏洩による損害が拡大しないようにすることは多少困難になります。なるべく多くの人に情報を伝えてその情報がなるべく多くの人に伝わることを期待するしかありません。

最悪の事態、つまり秘密鍵とパスフレーズの両方が危険にさらされる(何らかの方法で、このような事実を把握できればよいのですが)ような事態が発生した場合は、「鍵の非正当性」証明書を発行する必要があります。このような証明書を発行する目的は、ほかの人に対してあなたの公開鍵の使用を停止するように警告することです。PGP を使ってこのような証明書を作成するには、pgp -kd コマンドを使います。証明書を作成したら、何らかの方法を使って、この非正当性証明書を世界中の人に送ります。少なくとも、友人とその知り合いの人たちには送る必要があります。非正当性証明書を受け取った人の PGP ソフトウェアは、この証明書を公開鍵のキーホルダーにインストールし、あなたの公開鍵が間違って使われることを自動的に防止します。そのあと、あなたは新しい秘密鍵と公開鍵を作成し、新しい公開鍵を公表します。新しい公開鍵と古い公開鍵の非正当性証明書をまとめて、1 つのパッケージとして送ることも可能です。



公開鍵の無効化
---------------------

秘密鍵とパスフレーズの両方が何らかの形で危険にさらされているとします。このような場合は、ほかの人にその情報を知らせることによって、その人たちがあなたの公開鍵を使わないようにする必要があります。これを行うには、「鍵の非正当性」証明書(「鍵の無効化」証明書)を発行します。

自分の鍵が無効であることを示す証明書を作成するには、以下のような kd コマンド使います。

pgp -kd your_userid

証明書には、無効にしようとしている鍵を使って作成されたあなたの署名が記載されます。鍵の無効化証明書は、できるだけ早急に多くの人に送る必要があります。証明書を受け取った人はその証明書を自分の公開鍵のキーホルダーに登録できます。PGP ソフトウェアはこの証明書を公開鍵のキーホルダーにインストールし、あなたの公開鍵が間違って使われることを自動的に防止します。そのあと、あなたは新しい秘密鍵と公開鍵のペアを作成し、新しい公開鍵を公表します。

鍵の無効化は、秘密鍵が危険にさらされている場合以外でも行うことができます。ほかの理由で鍵を無効化する場合でも、無効化と同じメカニズムを利用することができます。



秘密鍵を紛失した場合の対応について
---------------------------------

自分の秘密鍵を無効にしたい場合には、一般的には kd コマンドを使って、自分の秘密鍵を使って作成した署名が付与された無効化証明書を発行します(「公開鍵の無効化」を参照してください)。

秘密鍵がなくなったり、破壊されてしまったりした場合は、どうしたらよいのでしょうか。鍵を無効化するには秘密鍵を使う必要があります。しかし、その鍵がないのですから、無効化処理を行うことはできません。PGP の将来のバージョンでは、このような状況においても鍵を安全に無効化できる方法を用意し、公開鍵が無効化されていることを信用できる仲介者が認証できるようにするつもりです。ただし現時点では、何らかの非公式な方法を使ってこの事実を知らせ、ほかの人の個々の公開鍵のキーホルダーに保存されているあなたの公開鍵を無効にするように頼む必要があります。

ほかのユーザーが、公開鍵のキーホルダーに保存されているあなたの公開鍵を無効にするには、-dk コマンドを使います。秘密鍵のキーホルダーに保存されている秘密鍵に対応していないユーザー ID を指定して kd コマンドを実行すると、公開鍵のキーホルダーでそのユーザー ID が探され、その公開鍵が無効な鍵としてマークされます。無効化された鍵は、メッセージを暗号化したり、-kx コマンドを使ってキーホルダーから取り出したりすることはできません。署名を確認することはできますが、警告メッセージが表示されます。このキーホルダーに同じ鍵をもう一度登録しようとしても、その操作は機能しません。無効化されたその鍵はすでにキーホルダーに存在するからです。このような複合機能によって、無効化された鍵がそれ以上広がらないようになります。

指定した公開鍵がすでに無効化されている場合に kd コマンドを実行すると、鍵を再度有効にするかどうかの確認を要求されます。


==================
高度な使い方
==================

高度な使い方に関するほとんどの項目は、『PGP ユーザーズガイド、第 2 巻: 特殊事項』に記載されていますが、いくつかの項目については、このマニュアルで取り上げます。


E メールで暗号文を送信する radix-64 フォーマット
-----------------------------------------------------------

一般的な E メールシステムでは、ASCII テキストで記述されたメッセージ以外は処理できないので、暗号文を構成する 8 ビットの生のバイナリデータは処理できません。この問題を解決するために、PGP では 暗号文メッセージの ASCII radix-64 フォーマット(PEM (Privacy-Enhanced Mail) フォーマットやインターネット MIME フォーマットと似たフォーマット)をサポートしています。この特殊なフォーマットでは、表示可能な ASCII 文字のみを使うことによってバイナリデータを表現します。したがって、7 ビットのチャネルを使ってバイナリ形式の暗号化されたデータを送信したり、バイナリ形式の暗号化されたデータを通常の E メールテキストとして送信したりするのに便利です。このフォーマットは、「輸送保護」機能の役割を果たすため、インターネット上のインターシステムゲートウェイを経由して運ばれる際に、データが破損されることを防止する役割を果たします。PGP には、CRC を追記して伝送エラーを検知する機能も備わっています。

radix-64 フォーマットでは、バイナリの 8 ビットバイト 3 個の固まりを 4 つの表示可能な ASCII 文字に拡張することによって平文が変換されるため、ファイルのサイズは 33% ほど大きくなります。しかし、暗号化を行う前にファイルがそれ以上の比率で圧縮されることを考えれば、このサイズの増大は大した問題ではありません。

ASCII radix-64 フォーマットの暗号文ファイルを作成するには、メッセージを作成したり署名を付加したりするときに a オプションを指定します。以下に例を示します。

pgp -esa message.txt her_userid

この例では、MIME とよく似た ASCII radix-64 フォーマットで記述されたデータが格納された message.asc という名前の暗号文ファイルが作成されます。このファイルは、7 ビットのチャネルを利用してテキストエディタにロードし、通常の E メールとしてインターネットなどの E メールネットワークを使って送信することができます。

radix-64 フォーマットで伝送保護されたメッセージに対する復号化は、通常の復号化とまったく同じ方法で行います。以下に例を示します。

pgp message

message.asc という名前の ASCII ファイルが自動的に探し出されたあと、message.pgp という名前のバイナリファイルが探されます。ファイルが radix-64 フォーマットで記述されていることが認識されると、バイナリ形式に戻されたあと通常どおりに処理されます。その結果、副生成物として、バイナリ形式の .pgp 暗号文ファイルが作成されます。最終的な出力ファイルは、元のファイル(message.txt)と同様の通常の平文形式で記述されます。

インターネットを利用した一般的な E メール機能では、50,000 ~ 65,000 バイトを超えるメッセージを送信することを禁止しています。これよりも長いメッセージはサイズの小さい複数のメッセージに分割され、別々に送信されます。暗号化したメッセージのサイズが非常に大きい場合に radix-64 フォーマットを要求すると、E メールで送信できるサイズに自動的に分割されます。分割されたメッセージは、.as1、.as2、.as3、… という拡張子が付いたファイルに変換されます。受信者は、適切な手順を使ってこれらの個々のファイルを元の大きなサイズの 1 つのファイルに戻してから復号化します。復号化処理では、radix-64 メッセージブロックで囲まれていないメールヘッダー内の無関係な文字は無視されます。

公開鍵を radix-64 フォーマットでほかの人に送りたい場合は、キーホルダーから鍵を取り出すときに a オプションを指定します。

暗号文ファイルの作成時や鍵の抽出時に a オプションを指定するのを忘れたとしても、暗号化を指定せずに a オプションだけを使うことによって、バイナリファイルを radix-64 フォーマットに変換することができます。この処理を行うと、鍵が .asc ファイルに変換されます。

平文ファイルを暗号化せずに署名を付加すると、通常は署名後にファイルの圧縮が行われ、人間が判読できない形式に変換されるので、署名を付加したファイルを保存・保管するときに使うと便利です。ただし、署名を付与したメッセージを E メールとして送り、元の平文メッセージをバイナリ形式ではなく、テキスト形式で残しておきたい場合は、平文が圧縮されない方法を使って、しかも ASCII 保護がバイナリ形式の署名だけに適用され、平文メッセージには適用されないような方法で E メールで送信することもできます。この方法を使うと、受信者は PGP を利用しなくても署名付きのメッセージを読むことができます。もちろん、実際に署名を確認するときには PGP が必要になります。この機能の詳細については、特殊事項編の「設定パラメータの設定」のセクションを参照してください。

バイナリデータのファイルを、PGP を使って暗号化したり署名を付加したりせずに E メールで送信したい場合もあるかもしれません。このような場合は、Unix の uuencode ユーティリティを利用してもかまいませんが、PGP でも同様のことが実行できます。それは、-a オプションを単独で使う方法であり、uuencode ユーティリティよりも機能性に優れています。詳細については、特殊事項編の「PGP を使って、Uuencode と同等以上の機能を実行する」のセクションを参照してください。


パス名の環境変数
------------------------------------

PGP では、目的に応じてさまざまな特殊ファイルが使われます。たとえば、標準キーホルダーファイル(pubring.pgp と secring.pgp)、乱数シードファイル(randseed.bin)、PGP 設定ファイル(config.txt、または pgp.ini、.pgprc)、外国語文字列変換ファイル(language.txt)などがあります。このような特殊ファイルは、PGPPATH という環境変数を目的のパス名に設定することによって、任意のディレクトリに保存できます。たとえば、MSDOS で

SET PGPPATH=C:\PGP

というシェルコマンドを実行すると、公開鍵のキーホルダーファイルの名前は C:\PGP\pubring.pgp であるとみなされます。もちろん、このようなディレクトリが存在していることが前提条件です。任意のテキストエディタを使って、MSDOS の AUTOEXEC.BAT ファイルを変更し、システム起動時に自動的にこの変数が設定されるようにします。PGPPATH を設定しないままにしておくと、これらの特殊ファイルはカレントディレクトリに保存されているとみなされます。



PGP 設定ファイルのパラメータを設定する
------------------------------------------------

PGP には、ユーザーが設定できるパラメータが数多くあります。このようなパラメータは、config.txt という名前の特殊な PGP 設定テキストファイルで設定します。config.txt ファイルは、シェル環境変数 PGPPATH によって示されるディレクトリに格納されています。設定ファイルを作成すると、PGP のさまざまなフラグやパラメータをユーザーが設定できるので、PGP のコマンドラインで毎回パラメータを設定する手間が省けます。

ローカルの OS のファイル名規則に対応するために、Unix システムでは .pgprc という名前を、MSDOS システムの場合は pgp.ini という名前をこの設定ファイルに付けることができます。

これらの設定パラメータを利用すると、一時的なスクラッチファイルの保存場所を設定したり、診断メッセージやユーザープロンプトを表示するときに使う言語を指定したり、保存されている認証署名の数に基づいて鍵の有効性を判断する際の基準レベルを調整したりすることができます。

これらの設定パラメータの設定に関する詳細については、『PGP ユーザーズガイド、特殊事項編』の該当するセクションを参照してください。



弱点
---------------

侵入できないデータセキュリティシステムはありません。PGP でもさまざまな方法で抜け道を見つけることができます。弱点となりえるものとして知っておくべき項目には、パスフレーズや秘密鍵の漏洩、公開鍵の改ざん、削除したがディスクに残っているファイル、各種ウィルスとトロイの木馬、物理的なセキュリティの侵害、電磁波の放出、マルチユーザーシステムにおける漏洩、トラフィック分析、そして直接的な暗号解読などがあります。

これらの問題に関する詳細については、『PGP ユーザーズガイド、特殊事項編』の「弱点」のセクションを参照してください。


==================
粗悪品に注意
==================

暗号化ソフトウェアパッケージをチェックすると、どうしてその製品を信用できるのかという疑問が必ずつきまといます。自分自身でソースコードをチェックしたとしても、すべての人が暗号化に関して十分な経験を有しているわけではないので、ソフトウェアのセキュリティを判断することはできません。たとえ暗号化に関する経験が豊富だったとしても、アルゴリズムに存在するちょっとした脆弱性を発見することはできません。

70 年代前半、私が大学生だったときに、当時はすばらしいと思っていた暗号方式を考え出しました。それは、単純な疑似乱数のストリームを平文ストリームに付加することによって暗号文を作成するというものでした。この方法は、暗号文の頻度解析の裏をかいているため、非常に資源が豊富な政府の諜報機関ですら解読不可能なように思えました。私は、自分の考案に対して過剰な自信を持っていました。つまりうぬぼれていたのです。

数年後、暗号化に関するいくつかの入門書や手引き書にこれと同じ方法が紹介されていることを知りました。ほかの人も同じ方法を思いついていたのですから、これはすばらしいことです。しかし残念ながら、初歩的な暗号解読手法を使って暗号を解読するための簡単な宿題としてこの方法が取り上げられていたのです。私の考え出した方法とはその程度のものだったのです。

この屈辱的な経験から学んだことは、暗号化アルゴリズムの考案時にはそれが安全であるという間違った考えを簡単に持ってしまうということです。豊富な資源を有する敵による長期的かつ必死の攻撃に耐えることができる暗号化アルゴリズムを考え出すことが恐ろしく難しいことであることをほとんどの人はわかっていません。多くの主流派のソフトウェアエンジニアたちによって、同程度の(まったく同じ方式であることもめずらしくありません)単純な暗号化方式が開発されてきました。また、このような暗号化方式の一部は市販の暗号化ソフトウェアパッケージに採用され、安全性を疑っていない非常に多くのユーザーに高い価格で販売されてきました。

これは、見た目も触った感じも大丈夫に見えていても、最も低速の衝突テストで外れてしまうような自動車のシートベルトを販売するようなものです。このようなシートベルトを信頼することは、シートベルトをまったく装着しないよりも危険であると言えるかもしれません。実際に衝突事故が発生するまでは、誰も疑いません。脆弱な暗号化ソフトウェアを信用して使っていると、知らないうちに重要な情報を危険にさらしてしまう可能性があります。暗号化ソフトウェアをまったく所有していなければ、そのようは事態が発生しないかもしれません。データが危険な状態にさらされていたことすらわからないかもしれません。

DES (Federal Data Encryption Standard: 連邦データ暗号化規格) を採用している市販パッケージもあります。DES は、政府が商用での使用を推奨している以前から存在するかなり優れたアルゴリズムです(ただし、不思議なことに、極秘情報には使わないことを奨めています)。DES で使用できる「操作モード」にはさまざまなものがありますが、優れているモードとそうでないモードがあります。政府は、最も脆弱でシンプルなモード、つまり ECB (Electronic Codebook: 電子コードブック) モードを使ってメッセージを暗号化しないことを明確に推奨しています。政府が推奨しているモードは、強度が高く複雑な CFB (Cipher Feedback: 暗号フィードバック) モードや CBC (ブロックチェーン化) モードです。

残念ながら、私が知っている市販の暗号化パッケージのほとんどで ECB モードが使われています。数多く存在するこのような製品の作成者と話す機会があったのですが、作成者は CBC や CFB といったモードの存在を聞いたこともなく、ECB モードの弱点についても何も知らないということでした。暗号化ソフトウェアの作成者たちが暗号化技術に関して十分な知識を持っていないため、このような基本的な概念すらわかっていないという事実には不安を感じます。しかも、不適切な方法やセキュリティ保護されていない方法で DES 鍵が管理されている場合もあります。また、このような同様のソフトウェアパッケージには、一般的に DES の代わりに使用できる高速な別の暗号アルゴリズムも搭載されています。一般論として、パッケージの作成者たちは、自分が開発した高速アルゴリズムと DES のセキュリティが同程度であると考える傾向にあります。しかし、パッケージの作成者に質問をしてみると、そのようなアルゴリズムは、私が大学生のときに考え出したすばらしい方法の変形にすぎないということがわかります。暗号化ソフトウェアの作成者は、自分が開発した暗号化方法の仕組みを明らかにしたくないのでしょうが、それでもその方法がすばらしいものであると言い、私はそれを信用することにします。作成者は、自分のアルゴリズムがすばらしいと信じていることは確かですが、その仕組みがわからなくては判断のしようがありません。

まったく公平な意見として、安全性の低いこのような製品のほとんどは、暗号化技術を専門としていない会社から発売されているということを指摘せざるをえません。

DES を適切な操作モードで使っている本当に優れたソフトウェアパッケージにも問題はあります。標準的な DES では、56 ビットの鍵が使われます。現在の基準から考えると、この鍵のサイズは小さすぎるため、特殊な高速マシーンを使って徹底的な鍵検索を行えば、簡単に解読されてしまう可能性があります。DES が有効に使用できる時代は終わりました。したがって、DES を基盤としているソフトウェアパッケージにも有効性はありません。

AccessData (87 East 600 South, Orem, Utah 84058、電話: 1-800-658-5199) という会社から、WordPerfect、Lotus 1-2-3、MS Excel、Symphony、Quattro Pro、Paradox、MS Word 2.0 に組み込まれている暗号化方式を解読できるパッケージが 185 ドルで発売されています。このソフトウェアを使うと、単なるパスワードの推測ではなく、本格的な暗号解読を行うことができます。自分のファイルのパスワードを忘れてしまったという理由で、このソフトウェアを購入する人もいます。法の執行機関もこのソフトウェアを購入して、差し押さえたファイルを読めるようにしています。ソフトウェアの作成者であるエリック・トンプソンと話したところ、解読処理は数分の 1 秒で実行できるが、遅延ループを挿入して速度を低下しているため、ユーザーはそれほどまでに簡単な処理であるとは思っていないということでした。また、PKZIP ファイルのパスワード暗号化機能は簡単に破れることが多く、法の執行に関連するユーザーは、別のベンダーから定期的に提供されているこのサービスをすでに利用しているということも教えてくれました。

暗号化技術は、ある意味では医薬品と似ています。完全であることが絶対条件であると言えるからです。粗悪な薬も優れた薬も見た目は同じだからです。表計算ソフトウェアに欠陥があれば、そのことを指摘できます。しかし、暗号化ソフトウェアに弱点があるかどうかについては、わかりようがありません。弱点のある暗号化アルゴリズムで作成した暗号文は、しっかりした暗号化アルゴリズムで作成した暗号文と同様、何も問題がないように見えます。世の中では、多くの粗悪品が販売され、さまざまないかさま療法が行われています。昔の薬売りと異なる点は、これらのソフトウェア作成者が一般的には自分たちの製品がまがい物であることすら知らないということです。彼らは優れたソフトウェアエンジニアであるかもしれませんが、一般的には暗号化技術に関する専門書を 1 冊も読んだことがありません。それでも、優れた暗号化ソフトウェアを作成できると考えています。どうしてでしょうか。要するに、暗号化ソフトウェアは簡単に作成できるような気がするからです。しかも、そのようなソフトウェアには問題がないように見えるからです。

解読不可能な暗号化方法を考え出したと思っている人がいたとしたら、その人はまれに見る大天才か経験を積んでいない無知な人であるかのどちらかです。自分が設計した暗号化アルゴリズムを搭載することによって PGP を改善したいと考えている暗号作成者志望の人がいます。残念なことに、私はそのような人たちに対応しなければならないことがあります。

NSA において高い地位に就いていた暗号作成者だったブライアン・スノウと交わした会話を今でも覚えています。ブライアンの言ったことは、まずは多大な時間を費やしてコードを解読することによって基礎知識を身に付けた人が考えた暗号化アルゴリズムでなければ絶対に信用しないというような内容でした。これは、当を得た意見です。暗号化技術に関する商業界で、このような基準を満たしているような人を私は知りません。ブライアンは自信のある笑みを浮かべ、「そのとおり。だから、NSA におけるわれわれの業務がたやすいものになるんだよ」と言いました。恐ろしい考え方です。私も合格基準を満たしていません。

政府もこれまで粗悪品を押しつけてきました。第二次世界大戦後、米国はドイツの Enigma 暗号機を第三世界の各国政府に売りました。しかし、連合軍が大戦中に Enigma のコードを解読していたという事実は隠していました(この事実は、何年もの間極秘扱いされていました)。現在でも、Unix システムでは世界的に Enigma の暗号を使ってファイルを暗号化しています。もっと質の高いアルゴリズムを使うことを妨害するような法律を制定したことがその理由の 1 つです。1997 年、政府は RSA アルゴリズムの最初の公表さえ阻止しようとしました。また、一般の人を対象とした効果的なセキュアテレフォンを開発するための商業的な取り組みをほとんどすべてつぶしてしまいました。

米国政府の NSA (National Security Agency: 国家安全保障局) における最大の業務は、主に人々のプライベートな会話をこっそり盗聴することによって、情報を収集することです(『The Puzzle Palace』(James Bamford 著)を参照してください)。NSA では、コードを解読するための相当な技術力とリソースが蓄積されてきました。われわれが優れた暗号技術を手に入れることによって自分を守ることができなければ、NSA は簡単に業務を遂行することができます。NSA には、暗号化アルゴリズムを承認、推奨する役割もあります。これは利害の衝突であり、狐をにわとり小屋の門番に任命するようなものであると非難する評論家もいます。NSA は、自分たちが考えた従来の暗号化アルゴリズムを押しつけ、その仕組みについては、極秘であるという理由によって公表しませんでした。信用して使って欲しいと考えているのです。しかし、優れた暗号化アルゴリズムであれば、極秘にしておかなくても安全性を保つことができるということは、暗号作成者であれば誰でも知っています。鍵だけを保護すればよいのです。NSA の極秘アルゴリズムが安全であるかどうかは決してわかりません。第三者がアルゴリズムをチェックできないのであれば、自分たちだけが解読できるような暗号化アルゴリズムを考え出すことは、NSA にとってそれほど難しいことではありません。NSA は故意に粗悪品を売りつけようとしているのでしょうか。

米国で市販されている暗号化ソフトウェアの品質を根底から揺るがしているものとして、主に 3 つの要素があります。1 つ目の要素は、市販の暗号化ソフトウェアの作成者の能力がほぼ全般的に不足しているということです(ただし、PGP のリリースをきっかけにこの傾向は変わりつつあります)。すべてのソフトウェアエンジニアが自分自身のことを暗号作成者であると思っているため、本当に粗悪な暗号化ソフトウェアが普及してしまいました。2 つ目の要素は、法的な威嚇や経済的な圧力によって NSA が民間の優れた暗号化技術を故意にそして組織的に抑制しているということです。このような圧力は、暗号化ソフトウェアの輸出を厳重に規制することによっても加えられたため、ソフトウェア販売の経済的側面によって、最終的には米国内における暗号化ソフトウェアを抑制する結果になりました。圧力はほかの方法でも加えられました。主なものは、公開鍵のすべての暗号化アルゴリズムのすべてのソフトウェア特許を 1 つの企業だけに認めるというものでした。この場合、接触点が 1 箇所しかできないため、技術が拡散することが抑制されました。これらすべての抑制策が効果を発揮したのは、PGP がリリースされるまでのことです。米国には、安全性が非常に高い汎用の暗号化ソフトウェアは存在しませんでした。

PGP のセキュリティについては、大学時代に優れた暗号化ソフトウェアを考え出したときほど確信を持っているわけではありません。確信を持っていたとしたら、それは悪い兆候です。しかし、PGP には著しい弱点がないことについてはかなりの自信を持っています(バグは存在するかもしれません)。暗号化アルゴリズムは、ハイレベルの民間暗号化学界の人たちによって開発されたものであり、1 つ 1 つのアルゴリズムは、仲間によって幅広くチェックされてきました。ソースコードが公開されているので、PGP は対等の立場で簡単にチェックすることができ、一部のユーザーが持っている不安を消すことができます。十分な研究も行われており、作成されて数年が経ちます。しかも、私は NSA の職員ではありません。PGP のセキュリティを信用することには、過大な信用が必要とされないことを願っています。


=========================
Mac ユーザーに対する注意事項
=========================

PGP はもともと、MSDOS マシーンや Unix マシーン向けに開発されたものですが、Apple 社の Macintosh 向けのバージョンもあります。このマニュアルは、MSDOS 版と Unix 版の PGP を対象としています。MSDOS 版と Unix 版の PGP では、コマンドラインインターフェースを使って PGP のすべての機能を実行します。Mac では、プルダウンメニューやダイアログボックスを使って PGP のすべての機能にアクセスします。また、MacPGP の使い方に関するオンラインヘルプも用意されており、MacPGP パッケージには、このマニュアル以外にも Mac 専用のユーザーマニュアルが付属しています。

Mac 用の優れたソフトウェアアプリケーションはすべて、最初から Mac を対象に作成されています。単にほかの OS から移植するわけではありません。しかし、残念ながら、現在の Mac 版 PGP は最初から Mac 向けに設計されたものではありません。Zbigniew Fiedorwicz 氏によって、MSDOS/Unix 版から Mac に移植されたものです。MSDOS/Unix 版の PGP は、GUI(グラフィカルユーザーインターフェース)のプログラムではないため、Mac に移植する作業は簡単ではありませんでした。バグも数多く残っています。現在、PGP のまったく新しいバージョンを開発中ですが、このバージョンは GUI に簡単に対応できるような設計になっています。Mac 用の新バージョンは、この新しい PGP ソースコードから作成します。これまでのバージョンよりも Mac らしくなり、信頼性も向上します。MacPGP の現行バージョンにはバグが存在しますが、PGP のまったく新しいバージョンが完成するのを待って Mac への移植作業を行わなければならなかったとすれば、Mac 版の PGP が存在しない状態があまりにも長く続いていたということをご理解ください。


=====================
PGP クイックリファレンス
=====================

以下に、PGP のコマンドを簡単にまとめました。


受信者の公開鍵を使って平文ファイルを暗号化するには、以下のように入力します。
pgp -e textfile her_userid

ユーザーの秘密鍵を使って平文ファイルに署名するには、以下のように入力します。
pgp -s textfile [-u your_userid]

自分の秘密鍵を使って平文の ASCII テキストファイルに署名して、E メールで送信するのに適した署名付き平文メッセージを作成するには、以下のように入力します。
pgp -sta textfile [-u your_userid]

秘密鍵を使って平文ファイルに署名したあと、受信者の公開鍵を使って暗号化するには、以下のように入力します。
pgp -es textfile her_userid [-u your_userid]

従来の暗号化方式を利用して平文ファイルを暗号化するには、以下のように入力します。
pgp -c textfile

暗号化されたファイルを復号化したり、署名付きファイルの署名の妥当性を確認したりするには、以下のように入力します。
pgp ciphertextfile [-o plaintextfile]

複数の相手に送信するメッセージを暗号化するには、以下のように入力します。
pgp -e textfile userid1 userid2 userid3

鍵管理関連のコマンド

独自の公開鍵と秘密鍵のペアを生成するには、以下のように入力します。
pgp -kg

公開鍵ファイルや秘密鍵ファイルの内容を公開鍵のキーホルダーや秘密鍵のキーホルダーに保存するには、以下のように入力します。
pgp -ka keyfile [keyring]

秘密鍵または公開鍵のキーホルダーから鍵を取り出す(コピーする)には、以下のように入力します。
pgp -kx userid keyfile [keyring]
または pgp -kxa userid keyfile [keyring]

キーホルダーの内容を確認するには、以下のように入力します。
pgp -kv[v] [userid] [keyring]

公開鍵のフィンガープリントを表示して、電話でその所有者に確認できるようにするには、以下のように入力します。
pgp -kvc [userid] [keyring]

自分の公開鍵のキーホルダーの内容を確認して、その認証署名をチェックするには、以下のように入力します。
pgp -kc [userid] [keyring]

自分の公開鍵のユーザー ID やパスフレーズを変更するには、以下のように入力します。
pgp -ke userid [keyring]

公開鍵の信用パラメータを変更するには、以下のように入力します。
pgp -ke userid [keyring]

公開鍵のキーホルダーから鍵またはユーザー ID だけを削除するには、以下のように入力します。
pgp -kr userid [keyring]

公開鍵のキーホルダーに保存されているほかの人の公開鍵に署名して、それを認証するには、以下のように入力します。
pgp -ks her_userid [-u your_userid] [keyring]

ユーザー ID やキーホルダーから、指定した署名を削除するには、以下のように入力します。
pgp -krs userid [keyring]

自分の鍵を完全に無効にして、鍵の非正当性証明書を発行するには、以下のように入力します。
pgp -kd your_userid

公開鍵のキーホルダーに保存されている公開鍵を無効にしたり有効にしたりするには、以下のように入力します。
pgp -kd userid

高度なコマンド

メッセージを復号化する際にそのメッセージに付けられている署名をそのまま残すには、以下のように入力します。
pgp -d ciphertextfile

文書から削除された署名証明書を作成するには、以下のように入力します。
pgp -sb textfile [-u your_userid]

署名付きメッセージから署名を削除するには、以下のように入力します。
pgp -b ciphertextfile

ほかのコマンドオプションと同時に使用できるコマンドオプション(コマンドオプションの組み合わせによって面白いつづりになるものもあります)。

ASCII radix-64 フォーマットの暗号文ファイルを作成するには、メッセージを作成したり署名を付加したりするとき、または鍵を抽出するときに a オプションを指定します。以下に例を示します。
pgp -sea textfile her_userid
または pgp -kxa userid keyfile [keyring]

暗号文ファイルの作成後に平文ファイルを削除するには、メッセージを暗号化したりメッセージに署名する際に -w (wipe) オプションを指定します。以下に例を示します。
pgp -sew message.txt her_userid

平文ファイルにバイナリ文字ではなく ASCII 文字を使い、受信者のローカルコンピュータのテキスト行の規則に合わせて変換するには、ほかのオプションと一緒に -t (text) オプションを指定します。以下に例を示します。
pgp -seat message.txt her_userid

復号化した平文出力を画面に表示するには、(Unix の more コマンドと同様)ファイルに書き込こまずに、復号化を行うときに -m (more) オプションを指定します。
pgp -m ciphertextfile

受信者が復号化した平文は画面上だけで確認できるようにし、ディスクに保存できないようにするには、-m オプションを指定します。以下に例を示します。
pgp -steam message.txt her_userid

復号化処理中に、元の平文ファイルの名前を復元するには、-p オプションを指定します。以下に例を示します。
pgp -p ciphertextfile

Unix 風のフィルターモードを使って、標準入力からの読み込みおよび標準出力への書き込みを行うには、-f オプションを指定します。以下に例を示します。
pgp -feast her_userid outputfile



==================
法律に関連する事項
==================

PGP のライセンス許諾、配布、著作権、特許、商標、免責事項、輸出規制の詳細については、『PGP ユーザーズガイド』の第 2 巻、特殊事項の「法律に関連する事項」のセクションを参照してください。

PGP では使われている公開鍵のアルゴリズムは、米国特許番号 4,405,829 で認めらたものです。この特許のライセンス許諾権は Public Key Partners (PKP) という企業が所有し、ライセンス許諾されていないユーザーが米国内で PGP を使うと、特許の侵害になる場合があります。 この問題の詳細については、マニュアルの第 2 巻および PGP のフリーウェア版に付属する RSARAEF のライセンスで説明されています。PKP は、特許の使用権を他社にライセンス許諾しており、ViaCrypt という企業もその中の 1 社です。ViaCrypt の販売する PGP は完全なライセンスを許諾されているバージョンです。ViaCrypt の連絡先は、602-944-0773 です。

PGP は「ゲリラ」フリーウェアであり、広範囲に配布していただいて結構です。ただし、私にソフトウェアの送付を要求しないようにしてください。ユーザー自身で、さまざまな BBS システムやインターネットの FTP サイトで見つけてください。PGP を配布する場合は、暗号化ソフトウェアに関する米国の輸出規制を理解しておくことが重要です。



==================
謝 辞
==================

PGP を阻止するような大きな障害や強い力が存在しました。このような障害は、高い理想を持った人たちの力によって克服されつつあります。PGP は反体制ソフトウェアとして悪名を得ました。完全にライセンス許諾されたフリーウェアとして PGP を正当な地位に引き上げることには、忍耐力と継続力が要求されました。特に、マサチューセッツ工科大学の Hal Abelson、Jeff Schiller、Brian LaMacchia、Derek Atkins の各氏に感謝の意を表します。また、マサチューセッツ工科大学事務局の Jim Bruce と David Litster の両氏、マサチューセッツ工科大学広報部の Bob Prior と Terry Ehling の両氏にも感謝します。その業務がまだ継続中である弁護チーム全員にも感謝します。弁護チームに所属する多くの前向きな弁護士に出会う前、私は弁護士をばかにするような冗談を数多く言ってきましたが、弁護士の多くは奉仕的な活動を行っています。

PGP の開発は社会現象として注目を集めることになり、その独自の政治的訴求によって、数が増えつづけている自発的なプログラムに対する総合的な取り組みが活発になりました。「石のスープ」という童話を覚えていますか。

Pretty Good Privacy の作成に尽力していただいた以下の人たちに感謝の意を表します。PGP バージョン 1.0 を作成したのは私ですが、それよりあとのバージョンの大部分は、私の設計指針に基づいて、多くの人々が国境を超えた共同作業を行ったことによって実現したものです。

Branko Lankester、Hal Finney、Peter Gutmann の各氏は、PGP 2.0 における機能拡張や各種の Unix システムへの移植作業に多大な時間を割いてくださいました。

VAX/VMS への移植は Hugh Kennedy 氏が、Atari ST への移植は Lutz Frank 氏が、そして Commodore Amiga への移植は Cor Bosman と Colin Plumb の両氏が行ってくれました。

他言語への翻訳については、フランスの Jean-loup Gailly 氏、スペインの Armando Ramos 氏、オランダの Felipe Rodriquez Svensson と Branko Lankester の両氏、スペインの Miguel Angel Gallardo 氏、ドイツの Hugh Kennedy と Lutz Frank の両氏、イタリアの David Vincenzetti 氏、リトアニアの Zygimantas Cepaitis 氏、ロシアの Peter Suchkow と Andrew Chernov の両氏、そしてエスペラント語については Alexander Smishlajev 氏によって行われました。Peter Gutmann 氏からニュージーランド英語への翻訳の申し出がありましたが、最終的には米国英語で問題ないという結論に達しました。

Jean-loup Gailly、Mark Adler、Richard B. Wales の各氏が ZIP の圧縮コードを公表し、PGP への搭載を許可してくれました。MD5 ルーチンは、Ron Rivest 氏によって開発され、パブリックドメインに配置されました。IDEA (tm) を開発したのは、チューリッヒの ETH の Xuejia Lai と James L. Massey の両氏であり、Ascom-Tech AG の許可を得て PGP に採用しました。

公開鍵を使った暗号化技術に適した多倍精度演算の実行方法を最初に私に教えてくれたのは、Charlie Merritt 氏であり、Jimmy Upton 氏は乗算・モジュロアルゴリズムの高速化に貢献してくれました。Thad Smith 氏は、さらに高速の乗算・モジュロアルゴリズムを実現してくれました。Zhahai Stewart 氏は、鍵に対する複数のユーザー ID の設定など、PGP のファイルフォーマットやそれ以外の項目に対しても数々の有益なアイデアを提供してくれました。仲介者という概念は、Whit Diffie 氏から教わりました。電子形態としてはじめてリリースした PGP 1.0 のほとんどの作業を担当してくれたのは Kelly Goen 氏です。

コード化作業は、Colin Plumb、Derek Atkins、Castor Fu の各氏のさまざまな協力を得て行われました。コード化だけでなくそのほかの作業にも協力してくれたのは、Hugh Miller、Eric Hughes、Tim May、Stephan Neuhaus の各氏です。このほかにも、数が多すぎて今すぐに思い出せないほど多くの人の協力を得ました。Mac への移植を最初に行ったのは Zbigniew Fiedorwicz 氏です。

PGP 2.0 のリリース後、ほかの多くのプログラマがパッチの提供してくれたり、バグ修正やほかのコンピュータに移植するための手直しを行ってくれました。数が多すぎるので、ここでひとり一人の名前を挙げて感謝の気持ちを述べることはできません。

「石のスープ」の話のとおり、ポットいっぱいに入ったスープの底にある最初に入れた石(つまり、最初の段階)を見ることはだんだん難しくなってきています。



==================
原稿作成者について
==================

Philip Zimmermann には、ソフトウェアエンジニアコンサルタントとして 19 年の経験があります。専門分野は、組み込みリアルタイムシステム、暗号化技術、認証、データ通信です。金融情報システムネットワークの認証システムの設計と実装、ネットワークデータセキュリティ、鍵の管理プロトコル、組み込みリアルタイムマルチタスク管理、オペレーティングシステム、LAN などにおいても経験を有しています。

Zimmermann は、暗号化や認証に関連した製品の特注バージョンや NIST DSS など公開鍵を製品化したものの特注バージョン、および製品開発に関連する特別サービスを提供しています。Zimmermann のコンサルタント会社の連絡先は以下のとおりです。

Boulder Software Engineering
3021 Eleventh Street
Boulder, Colorado 80304 USA
電話番号:303-541-0140 (米国山岳標準時の 10:00am ~ 7:00pm )
ファックス:電話と切り替え
メールアドレス: prz@acm.org

SPEEDEX サポートポリシー

Copyright @ Cyber Vision Hosting Co., Ltd. All rights reserved.


株式会社サイバービジョンホスティング提供サービス一覧
再販売用レンタルサーバーのSPEEDEX | VPS(仮想専用サーバー) | 共用サーバー | 専用サーバー | 独自ドメイン取得・運用 | SSLサーバー証明書 | ワイルドカードサーバー証明書 | SEO | Google Apps(TM)
WindowsデータバックアップのDataShelter | 事業者向け再販売用Windowsデータバックアップ | クリエイティブワークの検索エンジン