暗号化アルゴリズムやプロトコルは、システムの安全を維持するのに必要です。 インターネットのように信頼できないネットワークを経由して通信する場合は、特に 必要になります。 できるだけ暗号技術を使って情報を認証し、秘密を維持してください(しかし、 暗号化が認証を自動的にうまく行ってくれると、単純に思いこまないでください)。 一般的には、適切なツールを使ってアプリケーションを安全にする必要があります。
これまでの背景を知りたければ、著名なテキストである「Applied Cryptography」 [Schneier 1996]を読んでください。 「sci.crypt」ニュースグループは、FAQ を逐次出しています。あちこちで手に 入りますが、http://www.landfield.com/faqs/cryptography-faq にもあります。 Linux Encryption HOWTO を含む Linux 固有の情報元は http://marc.mutz.com/Encryption-HOWTO/ です。 プロトコルがどのような基本的アルゴリズムを利用しているかについては、 [Opplinger 1998]を見てください。 プロトコルにどうやって暗号を適用するかについては、ドキュメントのコレクション として [Stallings 1996]があります。 ここでわずかですが、解説をします。特化した内容になっていますので、より広く 知りたいならば、別のところを参照してください。
暗号化したプロトコルや暗号アルゴリズムを正しく理解するのは困難なので、自分で 作ろうとはしないでください。 そのかわりに、広く利用され、念入りに解析されたプロトコルやアルゴリズムを利用 してください。それが安全なものと理解してください。 暗号に関連したものを作成しなければならない時には、レビューを広く公開し、 セキュリティ分析の専門家が問題を調査できるようにしなければいけません。 自分が暗号化の専門家で、何をしているかを把握し、何年もかけてアルゴリズムの 専門家のレビューを受ける計画を立てられなければ、暗号アルゴリズムを作成する ようなことはしないでください。 (いくらかでも役に立つ)暗号アルゴリズムの作成は、専門家だけに許された作業です。
アルゴリズムの多くは特許を取っています。所有者が「利用は自由」、とある時点で 認めていたとしても、契約書に署名をしていなければ、所有者の気持ちが後になって 変わって、後で多大なリスクを背負うことになります。 総じて特許のあるアルゴリズムはすべて避けてください。ほとんどどんなケースでも、 特許に抵触しない解決方法があります。またその解決方法は、少なくとも特許を持つ ものと同等か、それ以上に優れた技術を使っています。そうしておけば、法的な問題の 数々を回避できます。
プロトコルは標準で適応している SSL(まもなく TLS に)や SSH、IPSec、GnuPG/PGP、 Kerberos 等を使うようにしてください。 機能のいくつかはそれぞれにかぶっていますが、おのおの「得意の」分野を持って います。 SSL(まもなく TLS)は、そもそも http(Web)のやり取りを保護する手法です。 PGP 互換プロトコル(PGP や GnuPG で実装)は、そもそも端末相互間で安全な電子 メールをやり取りする方法です。 Kerberos は本来、LAN 上で認証を安全にサポートする方法です。また、秘密を共有 する仕組みを構築します(つまり、実際に通信を保護するアルゴリズムは別に 必要になります)。 SSH はそもそもインターネット越しに「離れた端末」を安全にする方法です。 たとえば、telnet や X Window System のようなものを対象にしています。しかし 他のデータ・ストリーム(CVS へのアクセスのような)を安全にする場合にも良く 使われています。 SSH プロトコルにはメジャーな 2 つのバージョンが存在していることに注意して ください。また鍵のタイプ等の選択肢がいくつかあることにも注意してください。 詳しい情報はそれぞれのドキュメントを参照してください。 OpenSSH は、SSH のオープンソース版実装の 1 つです。 IPSec はそもそも低レベルでパケット「すべて」を安全にする方法です。したがって、 仮想プライベート・ネットワーク(VPN)や離れたところにあるマシンを安全にするのに 便利です。 インターネット・プロトコルの新しいバージョンである IPv6 は IPSec を「組み 込んで」いますが、より一般的な IPv4 でも IPSec は動作します。
さまざまなプロトコルで、いろいろなアルゴリズムが利用できます。したがって デフォルトとして、適切なアルゴリズムを選択する必要があります(たとえば、暗号化 アルゴリズム)。
暗号アルゴリズムの利用や輸出入は、国で規制されているケースが多く、かつ法律 は刻々と改定されます。 暗号を使ってアプリケーションを構築しようとする前に、法律がどうなっているか を調査してください。
秘密鍵(巨大なデータです)の暗号化アルゴリズムは、オープンに公開されていて、 長年の攻撃に耐え続けたものだけを利用してください。特許の状態も調べてください。 私としては、Rijndahl として有名な Advanced Encryption Standard(AES)の利用を 推奨します。大勢の暗号研究者がこれを解析して、重大な弱点が見つけられないこと がわかっています。私は、現状では十分に信頼するに足ると信じています。 AES のかわりとして優れているものは、Serpent アルゴリズムです。このアルゴリズム は処理が少々低速ですが、攻撃に対してとても強力です。 アプリケーションの多くにとって、triple-DES は非常に優れた暗号アルゴリズムです。 鍵長も適度で(112 ビット)、特許問題もありませんし、攻撃に長年耐えてきた実績が あります(公開資料があり、適度な鍵長を持った暗号化アルゴリズムの中で、これほど 長い期間攻撃に耐えてきたものは他にありません)。 しかし、triple-DES はソフトウェアで実装してあると非常に低速で、triple-DES は 「安全だが遅い」と思われています。 Twofish は優れた暗号アルゴリズムですが、なかなかある疑いがぬぐえません。 それは、Sean Murphy 氏 と Fauzan Mirza 氏が Twofish はたくさんの学者が所有権 を持っている、としている点です(しかし今のところ誰もその所有権を犯そうとは していません)。 MARS は「新手の斬新な」攻撃に対して抵抗力が強力です。しかし、より複雑で、 低性能 IC カードで対応するのは非現実的です。 今のところ、私は Twofish を採用しません。理由は、確かに Twofish は決して やられることはないと思われますが、しがらみを確認するのが困難だからです。 しがらみがないアルゴリズムが他にも存在していますので。 IDEA は使わないでください。米国と欧州の特許にしばられています。 定数や文字定数を XOR したようなものや ROT(転置暗号)法やビジネル暗号等、 考えなしなアルゴリズムを使わないでください。これらは現在のコンピュータなら わけもなく破れます。 「double DES」(DES を 2 度かける)は使わないでください。 triple-DES では 起こらない「man in the middle 攻撃」にやられやすいからです。 とにかく、プロトコルが複数の暗号アルゴリズムをサポートしているようにして ください。そうすれば、ある暗号アルゴリズムがやられても、ユーザは別の アルゴリズムに変更できますので。 【訳註：「man in the middle 攻撃」については、 二つの MITM って？ が参考になります】
対称鍵の暗号化(たとえば、巨大な暗号向けに)には、もし 2016 年まで秘密を保ちたい なら、90 ビットより小さい鍵長を利用しないでください(さらにビットを増やせば、 ビット毎に 18 か月セキュリティを保持する期間が増えます)[Blaze 1996]。 それほど重要でないデータを暗号化するなら、以前からある DES アルゴリズムが 役立つ場合があります。しかし最近のハードウェアならいとも簡単に総当たり攻撃 で DES の 56 ビット鍵を破れます。 DES を使っているなら、鍵として ASCII テキストを使わないようにしてください。 パリティは最下位(最上位ではない)ビットにありますし、DES アルゴリズムの多くは、 攻撃者がよく知ってしまっている鍵値を使って暗号化しています。 そのかわり、鍵のハッシュを作成し、間違いなくパリティ・ビットに設定して ください(暗号化ルーチンが出すエラーメッセージには注意を払ってください)。 いわゆる輸出向け暗号アルゴリズムは、有効な鍵長がたった 40 ビットになって います。これでは意味がありません。 1996 年には攻撃者は 10,000 ドルを費やして 12 分でそのような鍵を破りましたし、 コンピュータが空いている時間を使って数日で鍵を破りました。どちらのケースも、 破られるのに 18か月の半分の時間を持っていたのにです。
ブロック暗号化アルゴリズムは、いろいろなモードを使っています。たとえば、 「electronic code book」(ECB)や「cipher block chaining」(CBC)がそれです。 CBC を利用するのが一般的ですが、ECB モードは使わないで ください。ECB モードでは、あるストリームで、同じデータブロックが常に同じ 結果を返します。これでは暗号化されたものが何なのか、公表しているようなもの です。 CBC モードを含むモードは、「初期ベクトル」(IV)を必要とする場合が多くあります。 IV を秘密にする必要はありませんが、攻撃者が予測できるようではいけません。 セッションをまたがって IV を再利用してはいけません。セッションをはじめる 度に、新しい IV を使ってください。
ストリーム暗号アルゴリズムはいろいろありますが、大部分が特許に縛られています。 特許に引っかからず、技術的に問題の無いものに、WAKE があります。 RC4 は RSA Data Security Inc の企業秘密でした。しかし漏洩してしまったので、 その利用に現実的な法的障害があるとは思えません。しかし RSA はその利用者に対して 法的処置を施すと、主張を続けてきました(RSA ができることが何なのか、はっきり していません。しかしユーザが無意味な裁判沙汰に巻き込まれる可能性があるのは 疑いようもありません)。 RC4 を使うなら、自覚して利用してください。特に RC4 が生成した最初の 256 バイトは切り捨ててください。さもないと脆弱さを抱えることになります。 SEAL は IBM が特許を持っています。したがって利用しないでください。 SOBER には特許があります。特許の所有者は、利用許可を取ってくれれば自由に使って かまわないとしていますが、後々の利用の障害になります。 さらに面白いのは、モードでブロック暗号アルゴリズムを利用できる点です。 ブロック暗号アルゴリズムをストリーム暗号のように扱います。ストリーム暗号 を使いたいユーザは、この解決方法を検討してください(もっと広く公開している アルゴリズムから選ぶこともできます)。
公開鍵暗号法(秘密鍵に署名し、それを送る場合に特に利用されています)で、 広く利用されているアルゴリズムはほんのわずかです。 広く利用されているアルゴリズムに、RSA があります。 RSA のアルゴリズムには特許があります。しかしそれは米国に限定されますし、 2000 年 9 月に特許が切れますので、自由に使えます。 決して生の値を復号したり、署名したりしないでください。攻撃者は RSA を使って 直接生の値を渡し、その結果を公開します。こうすることで、秘密鍵を公開できるから です(実際にはこれは問題にはなりません。プロトコルの大部分は、ユーザ側で計算 したハッシュに署名したものが入っているからです。これは生データではありません。 つまり結果は公開されません)。 まったく同じ生の値を何回も復号したり、署名したりは絶対しないでください(元の 値が公開されてしまうかもしれません)。 常に双方にランダムなパディングを追加すれば、解決できます(PGP はそうして います)。普通この解決方法を Optimal Asymmetric Encryption Padding (OAEP)と 呼んでいます。
Diffie-Hellman 鍵交換アルゴリズムは、2 者間でセッション鍵を一致させる場合に 広く利用されています。それ自身では、お互いに誰であるかの保証はしていません ので、仲介者は存在しません。しかし、盗み聞きを防ぐのには、非常に効果があります。 特許は 1997 年に切れました。 Diffie-Hellman を使って共有鍵を作成したいなら、はじめに必ずハッシュしてください (共有値を直接使った攻撃方法が存在します)。
NIST は digital signature standard (DSS)を開発しました(ElGamal 暗号システム の改良版です)。これは電子署名の生成と認証を目的としています。開発条件の 1 つに、特許は取らない、とあります。
RSA や Diffie-Hellman、El Gamal 法は、代表的な対称鍵と比べて、同等の セキュリティを実現するのにさらにビット数を要します。 1024 ビット鍵が 80 ビットの対称鍵とおおよそ同等です。私の考えでは、この ビット数は現在必要な最低ラインです。 公開鍵をごくわずかなビット数にする必要があるなら、elliptic curve 暗号(楕円 曲線暗号)を利用しても良いでしょう(IEEE P1363 では曲線をいくつか推奨して います。適切な曲線を見つけるのは困難です)。 しかし注意すべき点があります。elliptic curve 暗号には特許はありませんが、 その高速化技術に特許がある点です(elliptic curve 暗号は十分に高速で、これらの 高速化は実際に普通の暗号セッションや巨大な暗号鍵の利用には必要ありません)。
一方向ハッシュ暗号アルゴリズムが必要なプログラムもあります。つまり「任意の」 量のデータを受け取って、攻撃者が逆転するのが困難な固定長の数を生成する関数です (たとえば、攻撃者が別のデータを使って、同じ値を生成するのが困難なものです)。 もう何年も MD5 が本命でしたが、最近の成果で MD5 の 128 ビット長ではもはや 十分でないことが示されました[van Oorschot 1994]。 また、ある種の攻撃は MD5 の防御を弱体化します[Dobbertin 1996]。 業界トップの暗号家が MD5 を破ったが、雇用契約の関係で沈黙している、という噂 が実際にあります(John Viega 氏が Bugtraq に August 2000 年 8 月 22 日に投稿 した記事を見てください)。 噂は誰でも流せますが、弱点がそれなりに見つかっていますので、完璧に破ったという のはもっともらしく聞こえます。 新しくコードを書くなら、MD5 のかわりに SHA-1 を使ってください。 オリジナルの SHA(SHA-0 と呼ばれています) は使わないでください。 SHA-0 は MD5 と同じような弱点があります。 ハッシュアルゴリズムにもっとビット数が必要なら、SHA-256 や SHA-384、SHA-512 を使ってください。仕様書は、NIST の FIPS PUB 180-2 にあります。
通信をする時には、何らかの整合性のチェックが必要です(暗号化にだけ頼らないで ください。攻撃者が情報を変更して、「ランダム」な値にしてしまえます) チェックはハッシュアルゴリズムで実現できます。しかし、直接ハッシュ関数を使用 しないでください(そうすると、ユーザを「拡張」攻撃にさらすことになります。 攻撃者がハッシュ値を利用して、自分が選んだデータを追加し、新しいハッシュを 計算する攻撃です)。 解決方法は、普通は「HMAC」です。これで整合性のチェックを次のように計算します。
H(k xor opad, H(k xor ipad, data)). |
HMAC による解決方法では、受信者が送信者となって同じデータを偽造できることを 忘れないでください。 これは普段問題にはなりません。しかし回避しなければならないなら、公開鍵方式 を使って、送信者が送信者の秘密鍵で「署名」して下さい。これで偽造による攻撃 は回避できますが、より手間がかかってしまいます。たいていの環境では必要では ありません。
暗号化とデータの整合性双方をチェックしてください。それが重要です。 暗号化に整合性のチェックがあったとしても、それに頼ってはいけません。攻撃者 がビットを変更して、別の値にしてしまうかもしれません。特定の値に変更できない としても、その値を変更できればそれで十分です。 普通は、手の込んだ攻撃を回避するために、整合性と秘密維持に別の鍵を使って ください。
十分に議論できていない問題の 1 つに「トラフィック分析」があります。 つまりメッセージが暗号化され、その暗号が破られていなくても、攻撃者は暗号化 したメッセージからさまざまなことが分かってしまいます。 たとえば、2 つの会社の社長が、多数の暗号化された電子メールのメッセージを やり取りしはじめたとすると、 2 つの会社が合併を検討しているかもしれません。 別の例として、SSH の実装の多くにはパスワード交換の弱点があることが分かって います。観察者はパケットを見て、パスワード長(もしくは長さの範囲)を推測でき ます。パスワード自体は推測できないにしてもです。 また、パスワードに関連したその他の情報も推測できます。これはパスワードを 破るのにかなりの手助けとなります。
部分的に問題を解決するような真似はしないでください。信頼できる環境(誰を信頼 できるか)が変化したなら、別の鍵を使ってください。 あまりに長い間同じ鍵を使わないでください。つまり、セッション鍵やパスワードは 変更してください。そうすれば、攻撃者は振りだしに戻らなければならなくなります。
概して何かを暗号化したいなら圧縮すべきです。これは固定長のへッダーを 加えることになり、必ずしも良いとは言えないのですが、メッセージを小さくする のと同時に、メッセージの残りにあるいくつものパタンも無くします。圧縮した結果 が小さくなりそうなら、普通は「うまくいった」と考えても良いでしょう。
関連事項として、自分で通信プロトコルを作成しなければならないなら、以前 どんな問題があったのか調査をしてください。 Bellovin[1989]のような TCP/IP プロトコルのセキュリティ上の問題を論じた 古典が役に立つと思います。Bruce Schneier [1998]や Mudge 氏による Microsoftの PPTP の実装を破った資料やその後の資料も同様です。 繰り返しますが、新しいプロトコルはどんなものでも、必ず広く公開してレビューを 受けてください。利用できるものは利用してください。