lu ru
SSL関連情報のページ

ここは、米 Netscape 社が提唱している、 SSL (Secure Sockets Layer) に関する情報を集めたページです。 これからは何と言っても暗号化技術が重要になってきます。 皆さんが普段お使いのブラウザに標準で組み込まれている 「身近な暗号技術」の代表としての SSL についての情報を集めてみました。

注意!内容は 1997年頃以降は実質ほとんど更新していません。 現状の実態と異なる内容が書かれている場合があります。
…とは言え、リンク切れ切れでは あまりに恥ずかしいのでちょっと修復しました。(2002.5.10)
最新情報は、ブログ の「暗号」カテゴリをご覧下さい。(2004.9.4)


おすすめ本:
右記の本「暗号技術大全」は暗号技術全般について 非常に詳しく解説してあるもので、比較的高価ですがそれだけの価値のある 本だと思います。 (注:ただしSSLに特化した内容ではありません。というか、 暗号の基本を扱っており、応用編である「SSL」は、見出し語すらありません…)

私は、仕事の関係で「原始多項式の例」を探していて、バッチリ表が出ていた ので、先日書店で偶然見つけて内容を吟味して即断即決!で買ってしまいました。
特に、暗号を実装される方に必要な情報がびっしり詰まっています。 暗号の実装上の脆弱性に対する注意点という意味では右に出る書が 無いかも知れない程充実しています。 私も大いに参考にしてある暗号方式を実装しました。(^^; (2005.11.1)


目次


概要

SSL (Secure Sockets Layer) は、米 Netscape 社が考案した 暗号通信方式です。 ネットワークの世界ではスタンダードな BSD socket の上にかぶせるように 作られており、ソケットを扱う手軽さで暗号化通信ができます。 SSL と似た技術で、セキュアな HTTP を実現する SHTTP も存在しますが、 これは HTTP のプロトコルのみを対象としているため、 (1)HTTP 以外に応用ができない、 (2)専用のブラウザが必要 といった問題点があります。 (2) については SSL も同様ですが、広く普及してしまった Netscape Navigator や マイクロソフト社の Internet Explorer に 組み込まれているという点で、この問題点を事実上クリアしていると言えます。

技術的な面では、SSL には 「秘密鍵暗号」「公開鍵暗号」「メッセージ認証」「相手認証」 の技術が応用されています。

基本的に SSL では通信路を伝搬するデータを暗号化する事で 第三者によるデータの盗聴を防止します。これには秘密鍵暗号が用いられます。 秘密鍵暗号はサーバとクライアントが同一の秘密鍵を持ち、 この鍵によって暗号化と復号化を行ないます。
SSL では複数の種類の秘密鍵暗号が用意され、サーバおよびクライアントで 共通する暗号方式のうちから、1つが選択されます。 規格上は DES, RC2, RC4, IDEA, 3DES, Fortezza が定められています。 が、米国の輸出規制の関係から日本国内で入手できる米国製の ブラウザの場合 RC2, RC4 の鍵長 40bit しか入っていないものが大半です。

秘密鍵をサーバとクライアントで共用するために 公開鍵暗号を用いています。 公開鍵暗号では、サーバやクライアントはそれぞれの公開鍵と プライベート鍵を持っています。公開鍵は文字通り誰にでも公開された鍵です。 一方プライベート鍵は、サーバやクライアントが自分の中だけに閉じて 利用する秘密の鍵です。 (「秘密鍵」と言うと秘密鍵暗号の通信鍵とまぎらわしいため、 プライベート鍵と呼びます。)
SSL では公開鍵暗号も RSA, Diffie & Hellman, Fortezza など 複数種類が規格上用意されており、サーバおよびクライアント間の ネゴシエーションによって使用される公開鍵暗号が決定されます。

公開鍵暗号では、第三者に知られることなく秘密鍵などの 伝送ができますが、その秘密鍵を伝えている相手が本当に 現在通信したい相手なのかどうかという事は保証出来ません。 全然関係無い人が、有名なサーバの名をかたってそれらしい公開鍵を 用意するだけでそのサーバになりすます事も出来てしまいます。
この問題を解決するには、公開鍵が本当に正しいものなのかどうかを 証明する事が重要です。この技術を「相手認証」と呼び、 SSL では CA (Certification Authority)方式を採用しています。 これは、クライアントとサーバ以外の第三者が あらかじめその正当性を保証するものです。 例えば、あらかじめ CA がサーバの正当性を調査しておいて、サーバの 公開鍵やドメイン名などの情報に「電子署名」をしておきます。 クライアントは、 信頼できる CA の情報さえ保持しておけば、サーバが提示した認証情報に 自分の知っている CA の署名さえあれば、その CA のお墨付きがある という事で通信相手を認証する事ができます。

また伝送途中に、データの書き替え(改ざん)が発生しないかどうかを 調べる技術が「メッセージ認証」です。 SSL では伝送中のデータと、メッセージ認証用の鍵などをハッシュ関数に 通す事で、 メッセージ認証子(MAC=Message Authentication Code)を生成します。 暗号化されたデータを送信するたびに MAC を付けて送信しています。
ハッシュ関数も SSL では、MD5 と SHA という二種類が定義されていて、 これまた通信開始時のネゴシエーションで決定されます。


動向

輸出規制
現在 SSL ライブラリや SSL を使った製品は 主として米国製が多く、米国政府の暗号製品輸出規制の影響により、 ある程度以上の強度を持ったものはアメリカやカナダ以外の国で 利用する事は出来ませんでした。

SSL の規格が考案された段階では、秘密鍵暗号は鍵長 40bit まで、 公開鍵暗号は鍵長 512bit までとされていました。 (それゆえ、SSL の規格書の中で暗号の種類の記述で EXPORT40 などの 名称が見られます。)

輸出規制がやや軟化?
ところが、1997年 5月上旬に Netscape Communications 社が SSL の秘密鍵暗号部分に DES CBC 56bit が含まれた製品の輸出許可を 取り付けました。その直後に公開された Netscape Communicator 4.0 PR4 には既にこのライブラリが入っていました。

輸出規制が別の方向に…
さらにその後、 1997年 6月 24日付けで Netscape Communications 社は同社のサーバと接続した場合のみでかつ、 銀行がサーバに特定の電子証明書を組み込んだ場合に限って 128bit の鍵長まで利用可能なブラウザおよび、特殊なサーバの 輸出許可を得たと発表しました。 http://home.netscape.com/flash2/newsref/pr/newsrelease428.html
また、同日 Microsoft 社も同様の許可を取り付けたとの発表をしています。 http://www.microsoft.com/industry/bank/press/encryptnpr.htm

さて、これらは、CA のしくみをうまく利用する事により、 電子商取引などの用途にはより強力な暗号を利用可能にすると同時に、 悪意を持ったユーザによる強力な暗号の利用を阻止する事に対する 1つの解を示したものと言えます。
ただし、特定の CA による証明書のみが有効となるため、例えば イントラネット用などの様に閉じた環境用に自前の CA を持つ場合などは 128bit 暗号は利用できないという問題は残ります。

ここからは推測ですが、恐らく米国政府の管理下にある CA のみが この証明書を発行する事が出来るような仕組みになっていると思われます。

輸出規制の緩和
読売新聞によると、1997年 9月末に米国下院商業委員会が完全自由化案を 可決したとの事です。まだ最終決定ではありませんが、 流れとしては「自由化」の方向にあるように思われます。

こぼれ話
上記の特殊な証明書方式に切り替わった途端、 DES 56bitは急に 輸出禁止になってしまいました。英語版の Netscape Communicator 4.0 製品 版ではしっかり外されていました。 日本語版は当初DES 56bit込みの形で 発売される予定だったのが、水際で FBI に輸出を差し止められたとか。 結局、海外にDES 56bit可能なブラウザが出たのは前述の Communicator 4.0 PR 版のみでした。
[1998.10.7]ところが、最近になって 56bit DES を使った製品の 輸出が原則自由化されたようで、またブラウザの SSL に復活する のかも知れません。


実験 (実験 CA による認証)

実験を始めるに当たって、SSL の証明書をどこかの CA に発行して もらわなくてはなりません。しかしながら、当初は単なる実験に過ぎない ため、我々自身の実験 CA を立ち上げました。 そして、この CA により実験用のサーバの証明書を発行しました。 我々の CA のルートキー この CA は、自分自身を認証するルート CA となっています。 そのため、Netscape Navigator があらかじめ持っている CA 情報では、 この CA によって発行された証明書を持つ サーバを直ちに認証する事が出来ません。 サーバ接続時に、「このサーバを認めるか?」という意味のダイアログが 表示され、ユーザに確認を求めてきます。 利便性を考慮すると Navigator にあらかじめ我々の CA を 認識しておいてもらうのが早いという事になります。

次のメニューにて我々の CA のルートキーをあなたの Navigator に組み込む 事ができます。 ただし、対応しているのは Netscape Navigator 2.0 以上および、 Internet Explorer 3.0 以上 のみです。

  1. デモ CA ルートキーの組み込み
    (「開く」を選択し、表示されるウィザードの指示に従ってください)

実験メニュー

  1. 実験用のサーバ証明書発行 (別途ご相談)
  2. 発行済みサーバ証明書の検索 (とりやめ)
  3. 実験用の個人向けクライアント証明書発行(都合により中止しました)
  4. 発行済み個人向けクライアント証明書の検索 (プライバシーの点からとりやめ)

SSL & SSLeay の Q&A コーナー デモ CA に関する Q & A を用意しました。


リンク集

ポータル

暗号理解.com ( http://www.angou-rikai.com/ )
暗号に関する様々なコンテンツ、書評、リンク集など、暗号に関する多くの 情報が網羅されています。
特にSSL/TLSに限定せず、暗号技術全般、ネットワーク・セキュリティに関 するポータルという位置づけのサイトとなっております。

規格

米 Netscape 社: SSL の仕様に関するページ [基本]
やはり、御本家の SSL に関する情報が基本でしょう。 1996 年 3 月には、 SSL Version 3.0 が発表されSSL 2.0はどうやら徐々に消えゆく運命のようです。
SSLv2 と SSLv3 では、基本的なコンセプトやおおまかな処理の流れは同じですが、 細部はかなり手が加えられていて、かなり攻撃に強くなったという印象を 受けます。ただ、互換性のため、SSLv2, SSLv3 の両方が使える クライアントでは、最初にクライアントが出す client_hello メッセージは SSLv2 形式に基づいて出すようになっています。
(しかし SSL Version 3.0 のドラフトは 1996年 9月で期限切れなんだけど、 新しいのはいつ出るんだろう?→と思ったら、1996年 11月版のドラフトも 置いてありました。 SSL Version 3.0参照)

SSL 3.0 については、 稲村 雄:「WWW」オープンデザイン 1996年 6月号(No.14), pp.100 - 117 にも詳しい解説が掲載されています。 内容的には上記 Netscape 社のドラフトのエッセンスを日本語で書いた という感じで、上記ドラフトと併せて読むと理解が深まります。

米 Netscape 社: SSL 2.0 の証明書の形式
(SSL 2.0 CERTIFICATE FORMAT)
本家 Netscape による SSL 2.0 の証明書のフォーマットに関する情報。 Document Info を開いた時に出てくる、いわゆる「fingerprint」の 値についても言及されています。 単に証明書の MD5 によるハッシュ値だとの事です。 言われてみれば何だ!という感じですが、 この情報を探すのに苦労しました。
米 Netscape 社: Navigator 3.0 の証明書に関するフォーマット
Navigator 3.0 から用意された <KEYGEN> タグの仕様や、 その他認証情報のフォーマットに関する情報です。
米 Microsoft 社: Microsoft インターネットセキュリティフレームワーク(MISF)
同社のインターネットセキュリティに関連した情報のページです。 MSIE3.0 で、個人向けクライアント証明書を発行するための キーペアの生成は専用の ActiveX Control を用いて行ないます。
http://www.microsoft.com/security/ca/enroll.htm に詳細情報があります。(Thank you >> 池田さん) (ちなみに Netscape Navigator の場合、 3.0 以降では <KEYGEN> タグで生成できます)
米 Netscape 社: フォーム入力への署名機能(Form Signing) (ニュースリリース)
Netscape Communicator で、HTMLのフォームに入力された値に対して 電子署名を行なおうというもの。SSLとは別の規格。 (1997.12.25)
RSA 社の PKCS シリーズ [基本]
公開鍵暗号と言えば「RSA」社。同社が定める公開鍵暗号に関する標準に ついては、以下のページにあります。 これ自体強制力のあるものではありませんが、 安全な公開鍵暗号を使ったシステムを実現する上で必要なノウハウを ギュッと詰め込んだもので、非常に有用であり 今では多くの企業の多くの製品に採用されており、 事実上の標準規格と言ってもよいと思います。 http://www.rsasecurity.com/rsalabs/pkcs/ RSA Laboratories | Public Key Cryptography Standards (PKCS)
BER (Basic Encoding Rules), DER (Distinguished Encoding Rules), ASN.1 (Abstruct Syntax Notation One) に関する断片的情報
SSL 2.0 の問題点と SSL 3.0 での対処 (論文, PS形式 165KB)
David Wagner氏と、 Bruce Schneier氏による論文。 (1996.11 2nd USENIX Workshop on Electronic Commerce)
SSL 2.0 にはセキュリティ上の問題点がいくつかあるが、 SSL 3.0 でどのように解決されたかを述べている。
Security Info [おすすめ]
consensus development corporation が同社の商用 SSL ライブラリ開発に関連して収集したと推測される SSL を中心としたセキュリティ関連情報です。 SSL 関連の Wellknown port をはじめ、かなり詳しい情報が 得られる SSL-Talk FAQは一見の価値あり。
鈴木 幹夫監修:「インターネット時代のセキュリティ用語事典」 [おすすめ]
月刊 Open Network 1996年 5月号創刊特別付録は、 SSL も含めた暗号技術全般にわたる用語解説です。 国内トップクラスの暗号技術の専門家が執筆しており、 付録ながらとても充実した内容となっています。 (私はこの付録が欲しくて買いました。本体は… どっか行ってしまいました)
日経BP: 電子決済関連リンク集
電子決済に関連するインターネット上の情報をかなり 網羅的に収集したリンク集です。
http://www.nikkeibp.co.jp/info/link/digi-money/
TLS (Transport Layer Security)
IETF にてトランスポート層暗号化プロトコルの標準化が 進められています。それに合わせて Netscape, Microsoft などが最終的に方式が決まった段階での対応を表明しています。 内容的には SSL3.1 と呼んだ方がいい程度 SSL3.0 に近いものですが、 Draft には TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA の実装が必須などとの記述があり 波紋を呼んでいます。(アメリカの会社が製品輸出出来なくなる!)
http://www.ietf.org/ids.by.wg/tls.html IETF Internet Draft: Transport Layer Security
TLS(Transport Layer Security)日経インターネットテクノロジ 1998.4, pp.74-81
Overview of Certification Systems: X.509, CA, PGP and SKIP
タイトル通り X509, CA, PGP, SKIP の概要について触れた文書です。
http://www.mcg.org.br/cert.htm Overview of Certification Systems: X.509, CA, PGP and SKIP
SSLとTLSの各種規格ドキュメントの日本語訳 [おすすめ]
SSLとTLSに関するプロトコル規定・拡張・基盤・適用に関する ドキュメントが日本語に翻訳して提供されています。
http://www21.ocn.ne.jp/~k-west/SSLandTLS/ SSL & TLS Specifications in Japanese
SSLeay, OpenSSL にセキュリティホール!
BizTech によれば、OpenSSL の古いバージョンにセキュリティホールが 存在するとの事です。OpenSSL 0.9.6d 以前と 0.9.7 の開発途中版に 問題があるようです。
http://biztech.nikkeibp.co.jp/wcs/show/leaf/CID/onair/biztech/comp/199084 OpenSSLの一部バージョンにセキュリティ・ホール(BizTech)
SSLにセキュリティホール (Microsoft指摘)
MS が SSL の実装に問題があるとの発表を行ったもの。 文面を見る限りは、DNS を騙す必要があったり、 正規のCAから虚偽の証明書を取り寄せないといけないなど、 事実上悪用は困難らしいが、MS としては修正を加えるらしい。 以前の MS のいい加減なセキュリティから、ここまで細かい問題を 指摘するようになったか!と、ちょっとびっくりです。
http://www.microsoft.com/technet/security/news/IARWSV.asp Information about Reported Web Security Vulnerability(英文)

グローバルサーバID
米国外においても、金融機関など特定の業種向けだけに限って 強力な暗号を許可する方式が開発されました。 それが、「グローバルサーバID」方式です。
技術的には、ブラウザが SSL のネゴシエーション中にサーバの証明書の 検証段階で、それがグローバルサーバID用のプライベート鍵で 署名されている事を検出したら、 再度強力な暗号も許可した状態で SSL の接続からネゴシエーションをやり直す という方式です。グローバルサーバIDのための検証鍵はブラウザ内部に 隠し証明書として組み込まれています。
現時点では、日本国内では住友銀行および安田信託銀行グローバルサーバID を取得しているようです。 ただ、洩れ聞く話しでは米国によるかなり厳しい審査or監査が行なわれていて、 えっそんな情報まで…という感じだとか何とか。(私の所に伝わるまでに 誇張されているのかも知れませんが…) いろいろ大変なようです。

http://www.verisign.co.jp/service_intro/global_server.html 日本VeriSign:サービス紹介 グローバル・サーバID

暗号方式
SSL に使われている方式+αをリストにしてみました。 下記のページにも暗号方式についての情報があります。
http://www.wani.net/bak/crypt/index.htm CRYPTOGRAPHY (bakさん) http://mercury.ecs.cst.nihon-u.ac.jp/~masaki/kenkyu/security.html 暗号班 (Masaki さん)

【公開鍵暗号】
RSA
素因数分解の困難さに基づいた公開鍵暗号方式で、 現在最も多く使われている方式でもあります。
この文書内: RSAの特許
http://www.rsa-japan.co.jp/faq/faq_rsa.html 最新暗号化技術に関する RSA の FAQ (RSA Japan)
http://www.st.rim.or.jp/~m-ito/rsa/ サルにも分かるRSA暗号
Diffie-Hellman (DH)
Diffie と Hellman が考案した公開鍵暗号方式です。 暗号の革命とも言える「公開鍵暗号方式」のアイディアを 最初に考案したのは Diffie なのですが、具体的な方式化が遅れて しまったため素因数分解の困難さを利用した暗号方式は RSA になって しまったようです。(→NHK 新電子立国「コンピュータ地球網」)
EPOC, PSEC
NTTによる「安全性を数学的に証明した」公開鍵暗号方式です。 ただし、前提条件としてハッシュ関数の出力がランダムである事と、 EPOCは素因数分解問題が解読困難である事、 PSECは楕円離散対数問題が解読困難である事を使っているそうで、 前提が崩れればやばいのは他の方式と同様。
(SSL 2.0, 3,0 には使われていません。特許料が無料で使えます)
EPOCホームページ: http://info.isl.ntt.co.jp/epoc/index-j.html
PSECホームページ: http://info.isl.ntt.co.jp/psec/index-j.html
NTT:暗号技術の基本特許を無償化: http://www.ntt.co.jp/news/news01/0104/010417.html
【共通鍵暗号】
http://www.ipa.go.jp/SECURITY/enc/regist-3.htm IPA: ISO/9979 に基づく暗号アルゴリズムの登録状況
FEAL
NTT が開発した共通鍵暗号方式。 ソフトウェア化に適した高速処理が特徴で、 処理段数に対応して FEAL-8, FEAL-32, FEAL-N, (いずれも鍵長=64bit), FEAL-NX (N:処理段数=32/64; X:鍵長=128bit) があります。
(残念ながら SSL 2.0, 3.0 の標準規格には含まれていません)
http://info.isl.ntt.co.jp/feal-nx/ NTT: FEAL-NX Specifications
DES
IBM が開発した共通鍵暗号方式で、米国標準にもなっています。 UNIX パスワードの暗号(ハッシュ)化に用いられています。 ブロック暗号でブロック長 64bit で、鍵長も 64bit です。 しかし、鍵は 8bit 毎にパリティビットを 1bit 含むため 実効鍵長は 56bit となります。

しかし最近になって暗号化に癖があり、 利用方法によっては線形解読法などにより解読が容易になる事があるなど 強度的な問題が指摘され始め、 DES を 3段直列にして実効鍵長を 3倍(168bit)にする Triple-DES (あるいは DES3 とも表記)が考案されました。 3段分のそれぞれの処理について暗号化(E)復号化(D)の別があり、 暗号・復号・暗号と繰り返すものを DES3-EDE、 暗号・暗号・暗号と繰り返すものを DES3-EEE などと表記します。 また、有効鍵長については DES3-EDE の場合、 計算量の節約のため両端の暗号化に同じ鍵を用いる場合もあり、 その場合有効鍵長は 2倍(112bit) です。
ftp://ripem.msu.edu/pub/crypt/docs/des-algorithm-details.txt How to implement the Data Encryption Standard (DES)

IDEA
スイスの ascom が開発した共通鍵暗号方式です。 ブロック鍵暗号です。 米欧において特許を取得していて、 使用する際はライセンス契約が必要です。 日本国内でも特許出願済みです。
http://home.ecn.ab.ca/~jsavard/crypto/co0404.htm IDEA (International Data Encryption Algorithm)
RC2
Rivest の考案した共通鍵暗号方式。 手続き非公開だったブロック暗号ですが、 1997年5月に手続きが公開されました。 これに伴い、国内でも正式に RC2 の暗号ライブラリが 製品化されるようになりました。
http://www.ietf.org/rfc/rfc2268.txt Rivest: A Description of the RC2(r) Encryption Algorithm
RC4
Rivest の考案した共通鍵暗号方式。 (公式には)手続き非公開のストリーム暗号です。 SSL で最もよく使われている(選択される)共通鍵暗号方式です。 ネットニュースに暴露されてしまったソースコードは SSLeay の パッケージに含まれています。 SSL プロトコルで使われる共通鍵暗号の「標準」と言っても良い存在。
http://www.rsasecurity.com/rsalabs/faq/3-6-3.html RSA Laboratories | Cryptography FAQ | What is RC4?
http://www.wisdom.weizmann.ac.il/~itsik/RC4/rc4.html RC4 Page
RC5
Rivest の考案した共通鍵暗号方式。 手続き公開のブロック鍵暗号で、処理語長(bit)、段数(段)、鍵長(バイト)が可変。 このパラメータを付与して RC5-32/12/8 のように表記します。 RSA 社の暗号解読コンテストDES とともに同社の代表方式として出題されました。 鍵展開と実際の暗号化の部分から成り、 鍵展開の処理が1ブロックの暗号化処理の数倍重く、 かつローテート(ビット回転)が多用されていて 総当たり探索による解読を困難にしています。
(SSL 2.0, 3,0 には使われていません)
http://www.ietf.org/rfc/rfc2040.txt (RFC2040: RC5,RC5-CBC, RC5-CBC-Pad, RC5-CTS のアルゴリズム)
Camellia
NTTと三菱が共同で開発した、共通鍵暗号方式です。 128ビットのブロック長で、高速処理やハード化に適した処理内容である 事が特徴の方式です。 基本特許が無料で使えますが、 実は高速化実装など基本特許でない部分は無料ではないようですので、 実用的な Camellia を実装しようという方は要注意です。
(SSL 2.0, 3,0 には使われていません。)が、
2005年5月26日にISO/IEC国際標準暗号規格に採用されてから、 とんとん拍子に、2005年7月20日にTLSでのIETF公式標準暗号の 一つとして承認されました。
http://info.isl.ntt.co.jp/crypt/camellia/index.html Camelliaホームページ
http://www.ntt.co.jp/news/news01/0104/010417.html NTT:暗号技術の基本特許を無償化
http://www.ietf.org/rfc/rfc4132.txt RFC4132: Addition of Camellia Cipher Suites to Transport Layer Security (TLS)
【ハッシュ関数】
MD5
Rivest が考案したハッシュ関数。
128bit のハッシュ値を生成します。 UNIXではネット上のファイルの改ざん検出ツール(md5)としてもおなじみ。
http://www.ietf.org/rfc/rfc1321.txt RFC1321: The MD5 Message-Digest Algorithm
SHA, SHA1
米国商務省の定めた標準ハッシュ関数。(FIPS-180-1 または 59 Fed Reg 35317 (1994)) 160bit のハッシュ値を生成します。 MD5 の 62% 程度の性能 (cf.RFC1852) で、ハッシュ値が長い分攻撃に強いと言われています。 FIPS 180 として最初に出された SHA は強度的な問題があったようで、 現在は抹消されています。 インターネット上に流通しているソースの中には古いものがあるので 注意しましょう。当然古いものは現在の SHA と互換性はありません。 FIPS-180-1 を SHA-1 や SHA1 と表記する場合もあります。
http://www.nist.gov/itl/div897/pubs/fip180-1.htm FIPS-180-1

暗号の強度
暗号の強度とは
ほぼ全ての暗号は解読出来ます。 ただ、解読の容易さが違いますから 暗号解読にどの程度のコスト(計算機パワー) を要するかをもって暗号の強度を表します。 (例:200MHz の xxx で総当り検索すると xxx万年かかります)
一般に暗号方式の強度を定量的に評価するには、現在判明している 複数の解読方法による困難さを利用します。 これは理論的に証明する場合や、評価用のソフトウェアツールを 利用して暗号化前後のビットパターン等から測定する場合があります。

しかし、ある日誰かが突然非常に簡単に鍵を見つける方法を 考案してしまったら、その暗号方式は無意味になってしまいます。 また、計算機パワーは日々向上しています。 そこで、強度を検証する1つの方法として、懸賞金付きの 暗号解読コンテストが開催される場合があります。

暗号解読コンテスト
米RSA社が各種暗号強度の確認のため開催したコンテスト。 1997年 1月 28日 9:00 (PST)から開始されたもので、 DES 56bit と、 RC5 の 40, 48, 56, 64, 72, 80, 88, 96, 104, 112, 120, 128bit の鍵を使った問題が出題されていて、簡単なものを 除いて賞金はそれぞれ 10,000 ドルです。
http://www.rsa.com/rsalabs/97challenge/ (コンテストホームページ)
http://www.rsa.com/rsalabs/97challenge/html/status.html (賞金と現在の状況)
暗号解読コンテストの状況
RC5 の 40, 48 bit は 予想通りあっという間に破られてしまいました。 その後 DES 56bit と、 RC5 56bit が相次いで破られました。 いずれも総当たり検索(Brute Force Attack)で、 インターネット接続された数万台の計算機パワーに 物を言わせて力ずくで計算させています。 次は RC5 64bit に挑戦中という。
その後 DES 56bit のコンテスト(DES II)が2回開催され たのですが、2回目は何と!専用ハードウェア「Deep Crack」を使った 団体が 2.5日で解いてしまいました。
http://www.watch.impress.co.jp/internet/www/article/970619/des.htm (56bit DES 破られる)
http://www.watch.impress.co.jp/internet/www/article/971024/rsa.htm (56bit RC5 破られる)
http://www.distributed.net/rc5/ Project RC5-64 (Project Bovine)
DES-56bit, RC5-56bit の解読に成功した団体。簡単に参加できます。

特許等について
SSL の特許
米国では Netscape 社が特許(Pat.#5657390)を保有しています。
http://patent.womplex.ibm.com/details?patent_number=5657390 SECURE SOCKET LAYER APPLICATION PROGRAM APPARATUS AND METHOD
RSA の特許
公開鍵暗号としての RSA 自体は北米のみ特許を取得していましたが、 2000年9月に特許が失効し、RSA 社はパブリックドメイン化を宣言した そうです。
http://www.zdnet.co.jp/news/0009/11/rsapatent.html ZDNN: 「RSA特許の失効を受け、新たな動きに出るライバル各社」
その他知的財産に関するリンク
http://www.law.tohoku.ac.jp/intproplaw-j.html インターネットと法/知的財産権法プロジェクト
http://www.iisi.co.jp/RSA-patent.htm 公開鍵暗号に関する(米国内の)全特許

SSLの実践
フリーのSSLライブラリ「SSLeay」のFAQ 等 (日本語版もあります) [おすすめ]
http://www2.psy.uq.edu.au/~ftp/Crypto/
SSLeay はフリーの SSL パッケージで、 Eric A Youngさんと Tim J Hudsonさん (現在はEric Youngさんが中心かな?) によって開発されたもので、 現在もバージョンアップが続いています。(1996.10.4 現在 Version 0.6.4) SSLeay に関するメーリングリストのアーカイブもあります。
また、SSLeay では商用利用も認めておりこれを組み込んだいくつかの 製品も出ているようです。(未確認情報)
最新版の SSLeay 0.9.0b では TLSv1.0 にも対応しています。 下手な市販ライブラリよりも機能が豊富で安定しています。 ただ、CRL 関連の機能の作り込みが今一歩なのが残念です。
RSA社による SSLeay の買い上げ&製品化に伴い (だから、今のRSA社製品に入っているSSLはフリーソフト出身なんですよ!)、 その後フリー版は "OpenSSL" として分岐して独自に発展を続けています。 /2002.5.10
http://www.openssl.org/ OpenSSL: The Open Source toolkit for SSL/TLS

■著作権的には DES のモジュールの一部に Eric Young 氏以外が著作権を主張するファイルが3つある点に注意。 2つは Mark Murray 氏のものを Young 氏が改造したもの。 利用条件は Young 氏のものとほぼ同等。 残る1つは米 Sun Microsystems 社が出しているフリーのヘッダです。 いずれもフリーのソースなので、著作権的には問題なし (Eric Young さんのソースと同程度の問題)であると言えます。
■米国の輸出規制的には、SSLeay はオーストラリアで開発されたもの なので、米国の輸出規制には引っかかりません。 Sun Microsystems 社のヘッダファイルについては、DES のあるデータ構造 についてのもので 116 行と短く、暗号化ルーチンそのものでも無いし、 何より実際入手出来ていますし、注意を呼びかける文書等も 含まれていませんので、問題なしと考えられます。
■暗号技術のライセンスという点については、

  • IDEA 方式は日本国内でライセンス料の支払いが必要になってくる。 (ただし、SSLeay から取り外しは可能)
  • 秘密鍵暗号の RC2, RC4 が 組み込まれているが、本来両方式はアルゴリズム非公開のはず。 Cypher Punk と名乗る人たちが RSADSI 社の暗号モジュール BSAFE をリバースして、 ソースの形でネットニュースにぶちまけてしまった事件 (1994年9月14日、Message-ID: < sternCvKL4B.Hyy@netcom.com > を参照)があって、 その情報に基づいて作成されているためです。
という事から、実験的に使う分には問題がないと思われますが、 商用利用には問題があります。

SSLeay とそれを使ったアプリケーションに関しては、 稲村 雄:「暗号ツールを使う<SSL>」 オープンデザイン 1997年 6月号(No.20), pp.122 - 145 にかなり実践的な解説が掲載されています。

■おまけ:「SSLeay」はどう発音するか?
一時メーリングリストでも話題になったのですが、 面倒なのですが「えすえすえるいーえーわい」と1文字づつ発音するの だと作者自身は主張しています。(FAQにある通り) しかしこれでは発音しにくいので人によっては 「えすえすれい」もしくは「えすえすりー」と発音したりもするようです。 Eric Young さん曰く「私は S-S-L-e-a-y の方を使うんだけど、 SLeaSy(すりーしー)ってアナグラムもあるよ 」とも言っております。 私は「えすえすりー」と言ってますが、作者の意志を尊重した方が良いのかな? 願わくば作者がもっと発音しやすい読み方を正式な読み方にしてくれれば いんだけど、メーリングリストでの話題は意見だけ出て消えてしまった…。

Netscape 1.1N を使って SSL が使えるようになるまで
Alex Tang さんが Netscape Navigator 1.1N と SSLeay で SSL が使えるようになるまでの各種体験談をとりまとめたもの。 Navigator 2.0 での話しが反映されていないものの、いろいろと参考になります。
ちなみに…、Netscape Navigator 2.0 以降や Internet Explorer 3.0 では 任意の CA 証明書を後からブラウザに追加読み込み出来るので、 このあたりの苦労はしなくて済みます。
W3C (CERN) httpd 3.0用 CONNECT method を通す patch
SSL での接続は原則として、相手サーバとの直接接続が必要です。ところが、 ファイアウォールの内側にいて proxy 経由で HTTP アクセスをしている場合 には従来これが困難でした。
これに対し、proxy サーバにおいて CONNECT メソッドなるものを導入し、 proxy サーバが直接相手のサーバにコネクションを張ってくれ、コンテンツを スルーで通過させてしまうという方法が考案されました。本パッチは、free のサーバで proxy 機能がかなり使われている W3C httpd (CERN httpd) にこ のメソッドのサポート機能を付けるためのパッチです。Ari Luotonen氏が提供したもので す。
Infoscience社の 「暗号化 セキュリティ関連ツール」ページ
Infoscience 社は、SSL に関しても積極的に取り組んでおられるようで、 SSLeay FAQ の日本語版や、各種情報を収集・公開して いるようです。 上記タイトルページは、これらセキュリティ関連情報の 出発点になっていて、貴重な日本語の資料です。
http://www.infoscience.co.jp/ インフォサイエンス
http://www.infoscience.co.jp/technical/crypto/ssleay_jp.html SSLeayとSSLappsに関するよくある質問

SSL ライブラリ製品・ SSL エンジン
SSL Plus (SSL 3.0 商用ライブラリキット)
consensus development corporation の SSL 3.0 用ライブラリキット です。価格は 4万ドル(高い!)(1997.5.1現在) で、他に RSADSI 社の BSAFE の ライセンスが必要というものです。 ただし、会社が米国にあるので日本に輸出してもらえるかどうかは 微妙です。
OrbixSSLについて(東洋情報システム)
C++, Java から利用可能な SSL エンジンです。 RC4 をサポートしているので、市販ブラウザとの通信が可能と推測されます。 また、CA 構築が可能な程度の機能も含まれているらしい。
アイルランド ボルチモア社の製品(株式会社エヌ・エス・ジェー)
C/SSL という SSL ツールキットが SSL エンジンとして利用可能そうです。 その他に、UniCERT と呼ばれる CA 機能なども付いているらしい。

SSLを使ったアプリケーション
Netscape Commerce Server
SSL 提唱元の Netscape 社の SSLv2 サポート型の WWW サーバです。
Netscape Enterprise Server (Pro)
SSL 提唱元の Netscape 社の SSLv3 サポート型の WWW サーバです。 Commerce Server の上位製品で、クライアント認証もサポートされました。 特に SSLv3 で加わった機能により、同一ポートに接続しておきながら、 後で証明書を要求できるという機能が実現されてて、かなり実用的。
Apache-SSL
世界的に最も人気のあるフリーの WWW サーバ Apache に SSLeay を組み合わせたサーバです。
http://japache.infoscience.co.jp/Apache-SSL/ (Apache-SSL 日本語サイト)
SSLftp
フリーのソースに SSLeay を組み合わせたもののようです。 ftp://xenium.lodz.pdi.net/pub/Crypto/SSLappなどにあります。
SSLtelnet
フリーのソースに SSLeay を組み合わせたもののようです。 ftp://xenium.lodz.pdi.net/pub/Crypto/SSLappなどにあります。
stelnet
Simon J. Gerratyさんによる SSLeay を使った telnet です。 この方は、SSLeay の API上にさらに "sslfd" なる簡単なAPIを作って移植されたようです。
http://www.quick.com.au/ftp/pub/sjg/ (配布ファイル)
SSLrsh, SSLrcp, SSLrdist
Simon J. Gerratyさんによる SSLeay を使った BSD 系の rsh, rcp, rdist コマンドです。 これも "sslfd" を使用。
http://www.quick.com.au/ftp/pub/sjg/ (配布ファイル)
http://www.quick.com.au/ftp/pub/sjg/help/ (HELP情報)
SSLtcl
Tcl/tk でおなじみの言語 Tcl 用の SSLeay を使うためのローダブルモジュール。 socket コマンドにより SSL 通信が可能になる。
http://www.abc.se/~m339/prog/ssl/SSLtcl.htmlドキュメント
http://www.abc.se/~m9339/prog/ssl配布ファイル
ftp://ftp.mc.hik.se/pub/users/mia95anp/ssl配布ファイル

CA (認証機関)

●海外

米 Verisign
認証事業のパイオニアと言えば Verisign でしょう。 発行はDigital ID Centerで やっているようです。
EuroSign
ヨーロッパの CA らしい。 先頭ページがテキストだけでかなり雑な作りだし、 「Nihongo」のページを見ると変なローマ字日本語だし。 ちょっと怪しい! CA です。
COST
Xcert Software Inc
南ア THAWTE 社
SSLeay の ML でアナウンスされたところです。 この会社自体はよく知りませんが、Navigator 3.0b の 個人向けクライアント認証を発行してくれました。
GTE CYBERTRUST

●日本国内

株式会社バイス(業務終了)
日本国内で最初に米VeriSign 社より 電子印鑑証明(Digital ID)発行のライセンスを取得し、 実際に発行していた。 (株式会社ビー・ユー・ジー の 100% 子会社) が、現在 CA 機能は 日本ベリサイン に移され、1996.5.31 をもって同社での証明書発行業務は終了した。
ところが、 ビー・ユー・ジーは、今度はサイバートラスト株式会社なる 電子認証機関を複数の企業との共同出資で設立した模様。 GTE CYBERTRUST の日本法人という位置付けもあるものと思われる。
報道発表:
サイバートラスト株式会社
上記の GTE, B.U.G., 野村総研, NTTドコモ等の共同出資による日本法人
日本ベリサイン
1996年 2月より 米Verisign Inc. の日本現地法人として活動開始。
日本認証サービス
1997年 10月 1日設立の新会社。日立・富士通・NECの共同設立。 特に SET 用の証明書の発行において、米系の2社に対抗して設立された模様。
http://www.jcsinc.co.jp/日本認証サービス
プレスリリース:
http://www.fujitsu.co.jp/hypertext/news/1997/Sep/29.html(富士通)
http://www.hitachi.co.jp/New/cnews/9709/0929b.html(日立)
http://www.nec.co.jp/japanese/today/newsrel/9709/2902.html(NEC)
私のところ
一応、私のところでも SSLeay を用いて実験サーバや個人の証明書発行を行なっています。 が、現在のところ実験用として内部向け証明書のみを手動でやっています。
(今はやっていません/2000.11.7)

本ページに掲載する内容は、 MiracleCat が独断と偏見で集めたものを整理したものです。 本ページに掲載する内容に関しては何らの保証も行ないませんし、 直接的および間接的にかかわらず本ページの情報によって生じた いかなる不利益に関しても、MiracleCat は責任を負えません。御了承下さい。


[トップページへ] ・ [いんぎらーっとしまっし Part2] [ねこだま掲示板2] [ねこだまについて] [カップルズ・バイオリズム]

2003.1.11 Written by , all rights reserved.

lb rb