White Paper 「暗号アルゴリズムにおける2010年問 …White Paper...

WH

ITE PA

PER

:

powered by Symantec

White Paper

「暗号アルゴリズムにおける2010年問題」対応ガイド問題なく移行するために抑えておきたい、サーバ管理者のためのチェックリスト 10項目

White Paper :「暗号アルゴリズムにおける 2010 年問題」対応ガイド

2

Copyright Symantec Corporation. All rights reserved.　Symantec と Symantec ロゴは、Symantec Corporation または関連会社の米国およびその他の国における登録商標です。その他の会社名、製品名は各社の登録商標または商標です。

合同会社シマンテック・ウェブサイトセキュリティは、本書の情報の正確さと完全性を保つべく努力を行っています。ただし、合同会社シマンテック・ウェブサイトセキュリティは本書に含まれる情報に関して、（明示、黙示、または法律によるものを問わず）いかなる種類の保証も行いません。合同会社シマンテック・ウェブサイトセキュリティは、本書に含まれる誤り、省略、または記述によって引き起こされたいかなる（直接または間接の）損失または損害についても責任を負わないものとします。さらに、合同会社シマンテック・ウェブサイトセキュリティは、本書に記述されている製品またはサービスの適用または使用から生じたいかなる責任も負わず、特に本書に記述されている製品またはサービスが既存または将来の知的所有権を侵害しないという保証を否認します。本書は、本書の読者に対し、本書の内容に従って作成された機器または製品の作成、使用、または販売を行うライセンスを与えるものではありません。最後に、本書に記述されているすべての知的所有権に関連するすべての権利と特権は、特許、商標、またはサービス･マークの所有者に属するものであり、それ以外の者は、特許、商標、またはサービス･マークの所有者による明示的な許可、承認、またはライセンスなしにはそのような権利を行使することができません。

合同会社シマンテック・ウェブサイトセキュリティは、本書に含まれるすべての情報を事前の通知なく変更する権利を持ちます。


3

CONTENTS

1 概要 4

2 「暗号アルゴリズムにおける 2010 年問題」とは？ 5

はじめに 5

SSL/TLS 通信で利用される暗号アルゴリズムの種類 5

暗号アルゴリズムの安全性は徐々に低下している？ 6

アルゴリズムの安全性が低下すると、現実的には何が起こるのか？ 7

検証および対策の範囲・方法をより明確にしよう 8

検証結果が NG となる可能性と対応方法 9

第 2 章のまとめ 11

3 「サーバ管理者のためのチェックリスト 10 項目」に沿った具体的なアクション 12

SSL サーバ証明書について確認すべきこと 12

サーバ設定について確認すべきこと 14

クライアント環境について理解すべきこと 17

4 いつまでに対策をとる必要があるのか？ 20

5 「2010 年問題」は繰り返されるのか？ 22

6 最後に 22

注釈・参考文献 22


4

1 概要

企業のサーバ管理者は、「暗号アルゴリズムにおける 2010 年問題 ( 以下「2010 年問題」)」についてどこまで理解しておくべきなのでしょうか？サーバやブラウザについて何を事前にチェックし、いつまでに対応の計画を立てれば良いのでしょうか？

「2010 年問題｣の脅威は、運用中のシステムや広く普及した通信機器の可用性を損なうことなく安全な暗号アルゴリズムに移行することの困難さが指摘されていながら、この為の具体的な検証方法や対応策が見えにくいことにあります。しかし、暗号アルゴリズムの種類・用途を正しく理解し、これを利用するサーバやブラウザなど個々の構成要素に対する具体的な検証および対策の方法が分かれば、一見複雑に見えるこの脅威を回避することは難しくありません。

シマンテックでは、14 年に渡って継続してきた SSL サーバ証明書発行業務を通じて得たノウハウを基に、企業のサーバ管理者が、この「2010 年」に取り組むべき「2010 年問題」について、現場で活用可能なチェックリストをご用意いたしました（表１）。

このホワイトペーパーでは、第 2 章で「2010 年問題」の背景を解説しながら移行を問題なく進めるための観点を整理し、第 3章ではチェックリストを基に、具体的な検証および対策の方法についてガイダンスをご提供します。また第 4 章、第 5 章では今後の動向についての注意点をご紹介します。

表１：サーバ管理者のためのチェックリスト 10 項目

No. チェックポイントカテゴリチェック

1 中間証明書、ルート証明書の鍵長やハッシュ関数を把握しておこう SSL サーバ証明書 □

2 鍵長 1,024bit の CSR はいつまで受付けられるか確認しておこう SSL サーバ証明書 □

3 新しいスタンダード、鍵長 2,048bit の CSR の生成方法を確認しておこうサーバ設定 □

4 4 階層証明書の場合、中間証明書の設定方法を確認しておこうサーバ設定 □

5 サーバで利用可能な Cipher Suite を確認しておこうサーバ設定 □

6 （サーバ間通信環境の場合）必要なルート証明書の導入を忘れずにサーバ設定（またはクライアント環境） □

7 （PC ブラウザ）Windows® XP と Windows Vista® 以降の違いを把握しておこうクライアント環境 □

8 （携帯電話）認証局毎に対応率が大きく異なるカバー率を把握しておこうクライアント環境 □

9 （携帯電話）「携帯アプリ」(Java、BREW 等 ) の特性を把握しておこうクライアント環境 □

10 （家電・組込み機器）各機器の通信機能と、ルート証明書を把握しておこうクライアント環境 □


5

2 「暗号アルゴリズムにおける 2010 年問題」とは？

はじめに

インターネット上での情報を暗号化し安全にやりとりする通信プロトコルである SSL/TLS 通信の仕組み。ここで利用されている暗号化通信を支える技術（以下、「暗号アルゴリズム」と呼びます）が急に使えなくなったとしたら、あるいは既に誰かに解読されてしまい重要な個人情報が盗聴されてしまっていたとしたら、私たちが日常生活で利用するインターネットはどのようになってしまうのでしょうか？

実は、暗号アルゴリズムの安全性は、コンピュータの性能向上および暗号解読技術の進歩により、徐々に低下していくことが避けられません。つまり、暗号アルゴリズムの「移行」を先延ばしにしてしまうと、ウェブサイトでの SSL/TLS 通信が利用できなくなったり、個人情報が流出してしまったりという危険性が現実のものになってしまいます。

SSL/TLS 通信で利用される暗号アルゴリズムの種類

SSL/TLS 通信は、情報の「暗号化」の他に、「ウェブサイト運営者の実在性証明」を加えた２つの役割を持っています。ウェブサーバに SSL サーバ証明書をインストールし、ブラウザからウェブサーバに「https://」から始まる URL でアクセスした時に、この証明書を利用して、SSL/TLS 通信が行われます。このイメージを図１で見てみましょう。

SSL/TLS 通信は一般にブラウザとウェブサーバの間で行われますが、これを実現するためにウェブサーバには SSL サーバ証明書、そしてブラウザにはルート証明書が導入されている必要があります。ブラウザがウェブサーバに「https://」から始まる URL でアクセスすると、この時にウェブサーバから SSL サーバ証明書をダウンロードします。クライアント側では、この証明書が正しい認証機関（認証局）から発行された「信頼できる」証明書か否かを確認するために、ブラウザに埋め込まれたルート証明書（認証局の鍵を持っています）を用いて、SSL サーバ証明書に付与された電子的な署名の確認（「署名検証」と呼びます）を行います。この電子的な署名には「ハッシュ関数」という種類のアルゴリズムが利用されます。

次のステップでは、個々のブラウザとウェブサーバとの間で双方向に暗号通信を行うためのルールとして、各セッションに固有の鍵

（「共通鍵暗号方式」と呼ばれ、またここで生成する鍵を「共通鍵」と呼びます）を生成しますが、この鍵を安全に共有するために、SSL サーバ証明書に含まれる「公開鍵」とウェブサーバに管理される「秘密鍵」が利用されます。「公開鍵」と「秘密鍵」は、RSA という種類の暗号アルゴリズムに基づいて必ずペアで生成され、片方で暗号化したものはもう一方の鍵でしか復号化できないという特徴を持ちます (「公開鍵暗号方式」)。公開鍵と秘密鍵の生成プロセスは、ウェブサーバで SSL サーバ証明書を導入した経験をお持ちの方であれば、証明書申請のための「CSR 生成」作業として既にご存知かも知れません。( 認証局に提出する CSR には公開鍵が含まれ、多くの場合これと同時にサーバ側には秘密鍵が生成されます )

このように利用される「公開鍵暗号方式」、「共通鍵暗号方式」および「ハッシュ関数」などを総称して、暗号アルゴリズムと呼びます。

図１：SSL/TLS 通信開始時のブラウザとウェブサーバのやり取りのイメージ

＊：シマンテックのルート証明書は、「信頼される認証局」として PC 用のブラウザを始め携帯端末など多くのクライアント端末に予め搭載されており、クライアント側でエンドユーザがルート証明書をインストールする必要はない

ルート証明書

シマンテックサーバ ID

①暗号化仕様交渉

②SSLサーバ証明書送付

③共通鍵生成

④暗号化データ通信開始

共通鍵40bit ～ 256bit

共通鍵40bit ～ 256bit

確認OK！

クライアントのブラウザウェブサーバ

https://www. ・・・

ウェブサーバは自らの正当性をクライアントに確認してもらうため、SSLサーバ証明書（および中間証明書）をブラウザへ送付する

ブラウザは受信した SSL サーバ証明書の発行元が、自分が保持するルート証明書※を利用して、正当な認証局であるか確認する


6

暗号アルゴリズムの安全性は徐々に低下している？

「公開鍵暗号方式」や「ハッシュ関数」にあまり耳なじみが無い方でも、「RSA1,024bit」や「SHA-1」など個々のアルゴリズムの呼称には、少し耳なじみがあるかも知れません。また、暗号アルゴリズムの動向により敏感な方は、「SHA-1 への衝突攻撃により、強度が 2 の n 乗まで低下」という記事を読んだことがあるかもしれません。

NIST( 米国標準技術研究所 ) という機関では、いくつかの種類が異なる暗号アルゴリズムについて強度を測る共通の尺度（「等価安全性」と呼びます）を準備し、表２のように整理しています。

これまで多く利用されてきた「RSA 1,024bit」の公開鍵暗号方式や、「SHA-1」というハッシュ関数は、この尺度によると「80bitの等価安全性を持っている」と評価されます＊1。これは、このグループに属する暗号アルゴリズムの解読に必要な計算量が 2 の 80 乗相当である暗号の強度を持っている、ということを意味します。

さて、2 の 80 乗の計算量とは、どの程度なのでしょうか？例えば、1 年間かけてこの計算量を賄えるコンピュータを入手可能と

なるのは、何年後のことなのでしょうか？CRYPTREC という機関がこの観点から、「RSA1,024bit」の強度について将来予測を行った結果、「2010 年～ 2020 年の間に、その時点で世界のTOP500 に含まれる程度の性能を持つスーパーコンピュータを利用すれば、1 年間で解読可能となると想定される」との報告がなされています＊2 。

この予測に含まれる様々な前提を含めて考えても、現実的な脅威が目前に迫ってきている状況であることが分かります。つまり、あと数年のうちに、十分な資金や環境を持つハッカーが 1 年間程度の時間をかければ、あるウェブサイト上でやり取りされた情報が「解読」されてしまうという事態が想定されます。

一方、112bit 安全性を持つ「RSA2,048bit」は、同様の条件化でも 2020 年を超えてこれ以降まで十分な安全性を保つことが出来ると考えられています ( 詳細については第 4 章で後述 )。つまり「2010 年問題」への対応は、「80bit 安全性」のアルゴリズムの使用を中止し、「112bit 以上の安全性」を持つアルゴリズムのみを利用するように移行していく対応である、と言い換えることが出来ます。

表２：暗号アルゴリズムの種類毎の等価安全性の評価（NIST SP 800-57 “Recommendation for Key Management”、 5.6 Guidance for Cryptographic Algorithm and Key Size Selection より抜粋）

等価安全性（Bits of Security）

公開鍵暗号方式（RSA の場合）および鍵長ハッシュ関数共通鍵暗号方式および鍵長

80bit 1,024bit 以上SHA-1＊1

SHA-224, SHA-256,SHA-384, SHA-512

2TDEA (2key Triple DES),3TDEA (3key Triple DES),AES 128bit 以上

112bit 2,048bit 以上 SHA-224, SHA-256,SHA-384, SHA-512

3TDEA (3key Triple DES),AES 128bit 以上

128bit 3,072bit 以上 SHA-256, SHA-384,SHA-512 AES 128bit 以上

192bit 7,680bit 以上 SHA-384, SHA-512 AES 192bit 以上

256bit 15,360bit 以上 SHA-512 AES 256bit 以上

安全

性低

高


7

アルゴリズムの安全性が低下すると、現実的には何が起こるのか？

仮に移行を行わずにこのままアルゴリズムの安全性が低下していった場合の危険性を知るために、それぞれのアルゴリズムがどのような用途で利用されているか、下の表３で再確認しましょう。

それぞれの暗号アルゴリズムの安全性が低下し、実際に攻撃が行われた場合には、上記の用途が正しく満たされないことになり、下の表４のようなリスクを顕在化（実害をもたらす問題の発生）させてしまうことになります。

それではこれを防ぐために、企業のサーバ管理者は何をすれば良いのでしょうか？根本的な対策は、表３に示すように、より安全性が高い暗号アルゴリズムに移行すると同時に、今後安全性が十分でなくなると考えられる「RSA1,024bit」や「SHA-1」などのアルゴリズムの利用を順次停止し、ウェブサービスの環境全体の安全性を高めることが必要となってきます。

しかし現在運用中のサーバや、サービスを利用するブラウザは、RSA2,048bit や SHA-2 ファミリー (SHA-224, SHA-256 などの総称 ) などのより安全なアルゴリズムを扱う準備が整っているのでしょうか？これを明らかにするための検証を確実に行わないと、より大きなトラブルを引き起こしてしまう可能性があります。

次のパートでは、様々な形態のウェブサービスや企業システム環境において、こうした検証および対策を行う範囲や方法について考えてみましょう。

表３：暗号アルゴリズムの種類毎の用途暗号アルゴリズムの種類

SSL/TLS 通信における用途現在主流のアルゴリズムの例

より安全なアルゴリズムの例

公開鍵暗号

秘密鍵はウェブサーバに保管され、対になる公開鍵は証明書に含まれて公開される。共通鍵の安全な共有、またウェブサーバの運営者を特定するための認証に利用される。SSL/TLS 通信を行うウェブサーバおよびブラウザが、個々のアルゴリズム（鍵長）を正しく扱える必要がある。

RSA 1,024bit

RSA 2,048bit

ハッシュ関数

データを他人に改竄されたことを検知する役割を持つ。認証局が SSL サーバ証明書を発行する際に電子署名を付与するため、また、ブラウザが証明書の署名検証を行うために利用される。SSL/TLS 通信を行うウェブサーバおよびブラウザが、個々のアルゴリズムを正しく扱える必要がある。

SHA-1 SHA-256

共通鍵暗号サーバとブラウザ間の通信ごとに生成され、通信データの暗号化・復号化に利用される。SSL/TLS 通信を行うウェブサーバおよびブラウザが、個々のアルゴリズム（鍵長）を正しく扱える必要がある。

2TDEA (2-key Triple DES)

AES 128bit

表４：暗号アルゴリズムの安全性が低下した場合のリスク

暗号アルゴリズムの種類安全性低下によるリスク安全性の低下をもたらす手法の例

公開鍵暗号公開鍵から秘密鍵を類推されてしまう。これにより、正しい証明書を保有している企業や個人の「なりすまし」や、暗号データの不正な復号化による「盗聴」が可能となる。

・一般数体篩法

ハッシュ関数

同じハッシュ値を持つ別のデータを生成されてしまう。これにより、不正に作成した証明書に対して、正しい認証局から発行された証明書であると誤認されるような電子署名を生成でき、正しい証明書を保有している企業や個人の「なりすまし」が可能となる。

・Collision Attack・Pre-image Attack・ Chosen-prefix Attack

共通鍵暗号暗号データを不正に「復号化」されてしまい、暗号化前の素のデータ（「平文 ( ひらぶん )」と呼びます）が「盗聴」可能となる。

・全数探索攻撃・暗号文一致攻撃


8

検証および対策の範囲・方法をより明確にしよう

企業のウェブサイトのサーバ管理者は、自社のサーバ環境だけでなく、サーバと通信を行うブラウザなどのクライアント環境について検証を行う必要があります。例えば EC サイトの運営企業では、PC ブラウザのみならず膨大なモデルの携帯電話でもアクセスを行い、決済等を含む一連の動作確認を行う必要があります。あるいは大規模な企業間のサーバ間通信システムなどでは、細かな設定変更を反映する場合でも、膨大な検証シナリオを実施しなおす必要があります。

ここでは、サーバに導入された「SSL サーバ証明書を入れ替える際に、公開鍵の鍵長を RSA1,024bit から RSA2,048bit に切り替える」対策をとるケースを例として、それぞれの環境でどのような検証が必要となるか、表５に考えられるパターンを整理してみます。

この例は、公開鍵の鍵長を変更したケースについて述べられていますが、証明書の署名で利用されるハッシュ関数が変更された場合にも、同様の観点から検証が必要となります。例えばウェブサーバのバージョンのアップグレードや、新しい OS やブラウザのバージョンがリリースされた場合などの検証についてルールを既に定めて運用している企業のサーバ管理者も、これに加えて、「2010年問題」を背景に今後 SSL サーバ証明書の仕様が変更される可能性は高まっているため、SSL サーバ証明書を入れ替える際にその検証の範囲と方法を正しく理解し、見直しておく必要があります。

表５：「SSL サーバ証明書の公開鍵を RSA1,024bit から RSA2,048bit に切り替える」場合の検証方法の例

一般的なウェブサイト組込み通信機器サーバ間通信システム

イメージ https://... https://... https://...

環境の構成要素・ウェブサーバ・PC ブラウザ・（携帯サイトの場合）携帯電話

・ウェブサーバ・通信機器（家電、ゲーム機や OA 機器、etc）

・双方向のサーバ環境

検証のためのサーバ準備

・ウェブサーバに、RSA2,048bit の鍵を持つSSL サーバ証明書を導入

・ウェブサーバに、RSA2,048bit の鍵を持つSSL サーバ証明書を導入

・トランザクション通信を行う全てのサーバ環境に、RSA2,048bit の鍵を持つ SSL サーバ証明書を導入

SSL/TLS 通信に関する検証項目

・ PC ブラウザ、携帯電話など、想定するクライアント環境の全てから、ウェブサイトに

「https」に正常にアクセスできるか

・ウェブサービスで利用する通信機器から、ウェブサービスに「https」で正常にアクセスできるか

・双方向通信を行う全てのサーバ間において、「https」での通信が正常に行えるか

検証 NG の場合に考えられる原因

・携帯電話に必要なルート証明書が組込まれていない

・携帯電話が RSA2,048bit に未対応（2G携帯など）

・ウェブサーバへの中間証明書の導入忘れなどの設定ミス

・通信機器に必要なルート証明書が組込まれていない

・通信機器が RSA2,048bit の鍵長を扱うことができない

・通信機器の設計・コーディングの不備

・サーバに必要なルート証明書が導入されていない

・サーバへの中間証明書の導入忘れなどの設定ミス

・サーバアプリケーションの設計・コーディングの不備


9

検証結果が NG となる可能性と対応方法

検証結果が NG となる可能性は、それぞれの環境においてどのくらいあるのでしょうか？またそれは何故起こるのでしょうか？

ここでは SSL/TLS 通信を構成するプレイヤーの役割をもう一度整理しながら、「NG となる可能性」と対応方法を整理します。

1. SSL サーバ証明書SSL サーバ証明書を原因として検証 NG となるケースは、そのほとんどが、以下のパターンに分類されます。

パターン１：証明書で利用されている暗号アルゴリズムが、サーバやブラウザで対応していないものである

サーバやブラウザなどの対応が十分でない状況で、SSL サーバ証明書の暗号アルゴリズムをアップグレードすると、これまで問題なく利用できていたサービスが突然利用できなくなります。この為、証明書を発行する認証局は、ブラウザなどの対応状況に十分に注意しながら、暗号アルゴリズムの移行を行う義務があります。

一方、古いバージョンのブラウザとの互換性などに捉われ過ぎることでいつまでも安全性の低い暗号アルゴリズムを採用し続けることは、先に述べたようなセキュリティリスクを高めることに繋がります。サーバ管理者はこのバランスをとりながら、利用する証明書、ウェブサーバおよびブラウザのバージョンなどを選定し、自社のサービスを定義し、管理・運用することが求められます。

パターン２：クライアント側に必要なルート証明書が存在しない

SSL サーバ証明書の発行元である認証局のルート証明書がクライアント側に存在していないと、サーバ側の証明書が「正しい認証局から発行されていない、不正な証明書である」と認識されてしまいます。クライアント側のブラウザや機器の実装上の問題である場合も見られますが、多くは、認証局が SSL サーバ証明書の暗号アルゴリズム移行を目的として行う階層構造（チェーン）の変更 (「ルートロールオーバ」とも呼ばれます ) に伴い、新たに必要となる別のルート証明書が適切に導入されていないケースと考えられます。この背景には「2010 年問題」があり、この為に顕在化するリスクの一部と言えます。

パターン３：パターン１、２以外で、とにかく接続ができない

これは「2010 年問題」ではなく、例えば SSL サーバ証明書や中間証明書が正しくサーバにインストールされていないなど、情報不足や設定不備によるトラブルと分類できます。

このケースについては、トラブルシューティングに役立つホワイトペーパー「サーバ管理者必見！失敗しない SSL 設定のキホン」をご参照ください。

2. ウェブサーバ ( 一般的なウェブサイトの場合 )通常ウェブサーバは、非常に高性能な CPU を持ち処理能力が高く、またバージョンアップの頻度も高いために、より安全性の高い暗号アルゴリズムへの対応が比較的進んでいます。

これまでのシマンテックの調査では、「公開鍵暗号方式」に関して、RSA2,048bit の鍵長を扱えないウェブサーバは少ないことが分かっています。また、「共通鍵暗号方式」に関しても、AES-128bit などのより安全性の高いアルゴリズムを利用可能なケースがほとんどですが、ウェブサーバの SSL/TLS 通信設定によっては、これより安全性が低いと考えられる DES や RC4 を利用して接続可能な状態になっているケースが多く見られ＊3、ブラウザとの間で行なわれる暗号の仕様交渉の結果によっては、こうした安全性の低いアルゴリズムによって SSL/TLS セッションが確立されてしまうために注意が必要です。

企業のサーバ管理者は、ブラウザとの間で交渉においてより安全性の高い通信を行うための「Cipher Suite( 暗号セット、TLS 1.0などのプロトコルで定義される暗号アルゴリズムの組合せ )」についての優先順位を定義し、またどの Cipher Suite を許可しないのかを検討し、判断する必要があります。この方法については第3 章に後述します。

3. ウェブサーバ ( サーバ間通信の場合 )基本的に一般的なウェブサイトの場合と同じですが、一方のサーバが他方のサーバにとってのクライアントとなるサーバ間通信のケースにおいては、相手のサーバの SSL サーバ証明書の検証を行うための「ルート証明書」が双方で利用可能になっているか、注意が必要です。ブラウザ同様に、出荷時に一定のルート証明書がインストールされているサーバアプリケーションも存在しますが、仕様や設定状況を確認した結果、ルート証明書がインストールされていない場合は、認証局などから独自に入手する必要があります＊4。

また、サーバ間通信を伴う環境は大規模な企業システムの一部であることが多く、開発や運用を外部委託するケースが多いために、暗号アルゴリズムの対応状況の検証の為に一定の予算確保が必要となる場合があることへの考慮が必要です。

4. ブラウザ (PC ブラウザ )PC ブラウザ (Windows Internet Explorer®、Mozilla FireFoxなどを総称してこう呼びます ) は通常高い処理能力を持ち、またバージョンアップの頻度も高いために、新しい暗号アルゴリズムへの対応が比較的進んでいます。また、あらかじめ組込まれているルート証明書などのモジュールに不足があった場合も、オンラインでパッチプログラムを配信するなど、製品のリリース後にアップデートを行う機能を備えるケースも多く見られます。


10

一方、Windows Internet Explorer などは、メジャーバージョンアップによって以前のバージョンへのサポートが終了し、これに伴ってパッチプログラムの配信も停止されます。こうした古いバージョンのブラウザは、強固な暗号アルゴリズムへの対応が不十分であるばかりでなく、他の種類のセキュリティリスクへの対策も十分には行えなくなるため、サーバ管理者として、エンドユーザに対してより新しいブラウザ環境への移行を促すことも重要であると言えます。

5. 携帯電話携帯電話は古くから SSL/TLS 通信に対応してきましたが、メモリ容量の制限などを理由に、当時主流であった RSA1,024bit への対応が重視され、当時はまだ市場に少なかった RSA2,048bitの公開鍵を持つ証明書への対応の優先度は、さほど高くなかったものと推測されます。特に、既に各キャリアによって停波が宣言されている第 2 世代 (2G) 携帯電話については、その多くがRSA2,048bit の鍵を扱えないことが分かっています＊5。

シマンテックが発行する SSL サーバ証明書には、証明書に含まれる鍵長を RSA1,024bit に限定する場合と、RSA2,048bit の鍵長を含む場合があります。このうち後者の仕様の証明書が導入されたウェブサイトには、これらの古い携帯電話機種でアクセス出来ないために、携帯電話用の EC サイトなどでは導入の際に注意が必要です。

6. 組込み機器家電やゲーム機、OA 機器などの組込みプラットフォームでは、CPU の高機能化に伴い搭載機能が増加し、インターネット接続を行う機能を持つものが増えてきています。しかしこうした機器にお

いては、携帯電話と同様、もしくはそれ以上にメモリ容量の制限など実装面での制約が大きく、RSA2,048bitやSHA-256など、より安全な暗号アルゴリズムへの対応状況が低いと考えられます。同様に、限られたウェブサーバにのみアクセスを行うケースが多いことから、搭載されるルート証明書の種類も少数に限定される場合が多いようです。

例えば「2010 年問題」を背景に、サーバ側の SSL サーバ証明書を新しい暗号アルゴリズムを実装したものに入れ替えると、SSL/TLS 通信に不具合が発生する危険性が考えられます。また、こうした組込み機器は、開発されてからエンドユーザの手に渡り、その寿命を終えるまでのライフサイクルが一般的なブラウザなどと比べて長いことから、不具合が発生した場合にも、機器の入替えなどの対応が進みにくいと考えられます。

このため、こうしたクライアント環境を対象としたウェブサービスを運営しているサーバ管理者は、その開発元と協力しながら、サーバ側の証明書の入替に加えて、機器のアップグレードおよび入替えを促進してゆくためのプランニングが必要になります。

最後にこれらの構成要素と暗号アルゴリズムの関係をまとめると、以下の表６のようになります。

サーバやブラウザ、携帯電話などの暗号アルゴリズムの対応状況については、情報が公開されている場合と、そうでない場合があります。企業のサーバ管理者は、自社のサービスの形態を踏まえながら、必要に応じてこれらのベンダー（「提供者」）の連絡先などを入手し、問合せが出来るようにしておくことが望ましいです。

表６：SSL/TLS 通信の構成要素毎の、提供者側の暗号アルゴリズムの利用・選択の考え方の例SSL/TLS 通信の各構成要素提供者暗号アルゴリズムの利用・選択備考

公開鍵暗号共通鍵暗号ハッシュ関数

証明書認証局

サーバ管理者が CSR 作成時に鍵長を指定

（ルート証明書・中間証明書は認証局が決定）

－ ( 認証局が決定 )

ウェブサーバ ( 一般ウェブサイト )

サーバベンダーサーバ管理者が Cipher Suite として選択する

ウェブサーバ ( サーバ間通信 )

システム開発者 (SIer など )

サーバ管理者が Cipher Suite として選択する※ ルート証明書が各サーバに導入されているか要確認

PC ブラウザブラウザソフトウェアの開発元

RSA2,048bit など長い鍵長が扱える

ブラウザ毎に Cipher Suite の優先順位がことなるため要確認

SHA-256 は、 Windows Vista 以降でしか扱えないなど、要確認

通常は認証局が、対応クライアント環境を公開している＊5

携帯電話携帯キャリアおよび端末メーカー

多くの機種でRSA2,048bit など長い鍵長が扱える

ブラウザ毎に Cipher Suite の優先順位がことなるため要確認

SHA-256 は、 2009 年以降発売の機種でしか扱えないなど、要確認

通信機器機器メーカー扱える暗号アルゴリズム、導入されているルート証明書は機器によって大きく異なるため、開発元に要確認


11

第 2 章のまとめ

「2010 年問題｣の本質は、認証局、サーバ、ブラウザのベンダーおよびこれらを利用する企業が、多様なクライアント環境を対象とした可用性を重視しすぎる余りに、セキュリティリスクが目前に迫るまで根本的な対策を先延ばしにしてきたことにあると言うことも出来ます。根本的な対策とはつまり、証明書の暗号アルゴリズム変更、古い携帯電話や組込み機器のアップグレードおよび入れ替えなどを指します。

本来、SSL/TLS 通信の安全性を維持するためには、暗号アルゴリズムの強度を段階的に高めていく必要があります。従って、例えば 10 年程度の寿命を想定している機器では、10 年先の暗号アルゴリズムの動向を考慮して設計されることが理想的です。しかしながら、機器のライフサイクルと暗号アルゴリズムのライフサイクルのバランスをとることが難しいなどの理由から、こうした対策が十分にとられているとは言いにくい状況です。

しかし、冒頭でも述べたように、一見複雑に見える「2010 年問題」の脅威は、環境の構成要素と、それぞれの要素に対する具体的な対処方法が分かれば、回避は難しくありません。

次の章では、本稿が想定する読者にあたるサーバ管理者の業務の中で、より具体的なステップを踏んで問題を把握し、回避の対応を進めるイメージを持っていただくため、第 1 章にご紹介したチェックリストの各項目についてご説明いたします。


12

3 「サーバ管理者のためのチェックリスト 10 項目」に沿った具体的なアクション

前章までに述べてきたような「2010 年問題」への対策は、誰によって、どのように行われるべきなのでしょうか？企業のサーバ管理者が出来ることには何があるのでしょうか？サーバ側で対策を行った際に、ブラウザや、携帯電話への影響は無いのでしょうか？

第 2 章で環境によって異なる対応のポイントを具体的に確認することができたら、次に検証や対応のための具体的なアクションを起こしましょう。ここでは第 1 章の表 1 に記したチェックリスト 10項目に沿って、今すぐ取り組むことができるアクションについてご説明します。

SSL サーバ証明書について確認すべきこと

チェックリスト No.1 - 中間証明書、ルート証明書の鍵長やハッシュ関数を把握しておこう多くの SSL サーバ証明書は、ウェブサーバへインストールするSSL サーバ証明書に加えて、ブラウザでの署名検証を正しく行うために、これと正しく対になって (「チェーンする」とも言われます )利用される中間証明書およびルート証明書を加えた、図２のような3 階層以上の階層構造になっています。

図２：一般的な証明書の階層構造（３階層）の例

VeriSign Class3Public Primary CA署名（自己署名）：SHA-1公開鍵長：RSA 1,024bit

VeriSign InternationalServer CA - Class 3署名：SHA-1公開鍵長：RSA 1,024bit

SSL サーバ証明書（End-Entity）署名：SHA-1公開鍵長：RSA 1,024bit/2,048bit

グローバル・サーバ ID（2009年 12月時点）

・ルート証明書は、ブラウザベンダーやデバイスメーカーが、出荷前にソフトウェアに組み込む

・信頼された認証局しか組み込みを許可されない

内容発行先公開鍵長署名アルゴリズム

1. 申請者（組織・団体）に対してシマンテックが認証を実施

2. 全ての認証が完了した後に、中間認証局の秘密鍵を利用して End Entity証明書に電子署名を付与

3. 2. で署名された End Entity 証明書が SSL サーバ証明書として、申請者（組織・団体）に発行される

クライアントPCのブラウザにプレインストールされているルート証明書

ウェブサーバ等にインストールする中間証明書

ウェブサーバ等にインストールするサーバ証明書


13

企業のサーバ管理者は、自社のウェブサイトなどで利用する SSLサーバ証明書について、その階層構造の各階層で利用される証明書の鍵長およびハッシュ関数を把握しておくことが望まれます。

例えば、仮に RSA2,048bit の鍵長を扱えない第 2 世代 (2G)の携帯電話を対象に含めたサービスを行う必要がある場合、証明書の階層構造においては「End-Entity」と呼ばれる SSL サーバ証明書の鍵長を RSA1,024bit にするために、CSR を鍵長RSA1,024bit で生成することが必要になります。しかしこれだけでは十分ではありません。この証明書と対になりサーバに設定する中間証明書の鍵長が RSA2,048bit であれば、古い携帯電話端末で SSL/TLS 通信を行うことは出来ません。

シマンテックを始めとする各認証局では、End-Entity だけでなく、中間証明書やルート証明書で利用する暗号アルゴリズムを常に見直し、必要に応じてより強固なものへ移行してゆく義務があります。こうした情報は定期的に認証局からサーバ管理者に宛てて提供されますので、認証局が提供する情報にも注意を払う必要があります。

チェックリスト No.2 - 鍵長 1,024bit の CSR はいつまで受付けられるか確認しておこうシマンテックなど認証局が行う必要がある「2010 年問題」への対応の一つに、SSL サーバ証明書申請時に、サーバ管理者から申請時に受領する CSR( 証明書署名要求 ) の鍵長に下限を設け、短い鍵を持つ証明書を発行しないことが挙げられます。

CSR は、例えるならばパスポートの発行を要求するための申請書に該当し、認証局に対して提出するこのデータには、発行されるSSL サーバ証明書に含めるための公開鍵が含まれています。

EV SSL 証明書については、標準規格を定める EV ガイドライン＊6 に従い、シマンテックを始めとする各認証局では順次RSA1,024bit の鍵長の CSR による EV SSL 証明書の申請受付と発行を停止しています。

また、EV SSL 以外の証明書の CSR の鍵長については、各認証局が独自に設けるルールに従って鍵長の下限が定められます。シマンテックの場合の例を表８に示します。

今後は RSA2,048bit の CSR を中心に利用することが望ましいといえます。また、何らかの都合によりRSA1,024bit の利用を継続しなければならない場合は、申請前に認証局に対して、鍵長の制限の有無について事前確認いただくことをお勧めします。

表７：シマンテック SSL サーバ証明書製品毎の、中間証明書およびルート証明書で利用される暗号アルゴリズム

シマンテック SSL サーバ証明書(End-Entity)

チェーンする中間証明書チェーンするルート証明書

公開鍵長ハッシュ関数公開鍵長ハッシュ関数

EV SSL 証明書グローバル・サーバ ID EV RSA2,048bit SHA-1 RSA2,048bit ※ 2 SHA-1

セキュア・サーバ ID EV RSA2,048bit SHA-1 RSA2,048bit ※ 2 SHA-1

EV SSL 以外の SSLサーバ証明書

グローバル・サーバ ID RSA1,024bit SHA-1 RSA1,024bit SHA-1

セキュア・サーバ ID RSA1,024bit またはRSA2,048bit ※ 1 SHA-1 RSA1,024bit SHA-1

※ 1: RSA2,048bit はマネージド PKI for SSL サービスでのみ選択可能 (2010 年 1 月時点 )※ 2: EV SSL 証明書では「クロスルート」という方式が採用されているため、RSA1,024bit のルート証明書を併用する。（クロスルートの詳細については後述）

表８：シマンテック製品カテゴリ毎の CSR の鍵長に関する制限

製品カテゴリCSR 鍵長

RSA1,024bit RSA2,048bit

EV SSL 証明書 2009 年 9 月に受付停止 ( ストアフロントの場合 ) 今後数年～十数年は利用可能である見込み

EV SSL 以外の SSL サーバ証明書 2012 年 9 月に受付停止 ( ストアフロントの場合 ) 今後数年～十数年は利用可能である見込み


14

サーバ設定について確認すべきこと

チェックリスト No.3 - 新しいスタンダード、鍵長2,048bit の CSR の生成方法を確認しておこうNo. 2 に示した通り、RSA2,048bit の鍵を持つ SSL サーバ証明書を発行するためには、CSR 作成時に RSA2,048bit の公開鍵を含めるよう、サーバ管理者が指定する必要があります。

さて、CSR の鍵長はどのように指定するのでしょうか。代表的なウェブサーバの例として、Microsoft® IIS での CSR 鍵長の指定方法を図３に示しますが、多くのウェブサーバアプリケーションにおいて CSR の鍵長は、この様にユーザフレンドリなインターフェイスを利用して、シンプルに指定することが出来ます。

図３：Microsoft IIS 7.0 での CSR 作成時の鍵長の指定

もう一つ代表的な例として、Apache + OpenSSL 環境では、以下のようなコマンドラインから CSR の鍵長を 2,048bit に指定することが出来ます ( 斜体下線部にて鍵長を指定 )。

# ./openssl genrsa -rand rand.dat -des3 2048 > 2009key.pem

注意が必要なケースとしては、鍵長の選択方法が、こうした直感的なユーザインターフェイスが提供されていないためにサーバ管理者にとって分かりにくい場合があります。事前にウェブサーバアプリケーションのマニュアルをチェックし、あるいは必要に応じてベンダーへ鍵長の指定方法を事前確認しておくことをお勧めいたします。


15

チェックリスト No.4 -　クロスルート方式の場合、中間証明書の設定方法を確認しておこうシマンテック EV SSL 証明書には、クロスルートという方式が採用されています。この時、ウェブサーバには、SSL サーバ証明書 (End-Entity) に加えて、さらに 2 種類 ( ルート証明書と End-Entity の間に設定する 2 階層分 ) の中間証明書をインストールする必要があります (PKCS#7 形式のファイルからインストールする場合は不要です )。合計 3 種類の証明書をウェブサーバにインストールする際には、インストールの順番に注意が必要です。設定方法を図４として解説します。

図 4 はシマンテックの「グローバル・サーバ ID EV」の階層構造を表しています。この証明書は、「( 通称 )G5 ルート」と「( 通称 )G1 ルート」という2 種類の独立したルート証明書を利用して署名検証を可能にする「クロスルート」という方式を利用して発行されています。ウェブサーバには (a),(b), および (c) の 3 枚の証明書をインストールします。

こうすると、G5 ルートが既に導入されている比較的新しいブラウザ（Internet Explorer 7 以上など）では、G5 ルートをトラストアンカーとする 3 階層で署名検証されます（この場合 (c) を検証経路とする G1 ルートへのチェーンはされません）。また、「G5」ルートが導入されていない携帯電話などでは、(a) → (b) → (c) の順に署名検証され、最終的に「G1」ルートへ 4 階層でのチェーンを辿ります。

この時、 (c) の中間証明書の設定を忘れている、または、(a)、(b)および (c) の 3 枚の証明書が正しい順序で設定されていないなどの理由で、クライアントから ( 特に 4 階層でチェーンを辿る携帯電話など ) 正しく検証ができないといった不具合が報告されることがあります。

サーバ管理者は、このようなクロスルート方式の SSL サーバ証明書を導入するケースを考慮し、ウェブサーバの証明書の設定順序について各サーバアプリケーションのマニュアルをチェックし、あるいは必要に応じてベンダーへの事前に確認しておくことをお勧めいたします。

図４：クロスルート方式のイメージ

例：グローバル・サーバ ID EVの階層構造

クライアントPCのブラウザにプレインストールされているルート証明書

ウェブサーバ等にインストールする中間証明書

ウェブサーバ等にインストールするサーバ証明書

ウェブサーバの設定・認証局から発行された End-Entity 証明書 (a) と併せ、2 階層分の中間証明書 ((b) および (c)) の計 3 種類の証明書をサーバへインストール

・クライアントからの通信要求時には 3種類の証明書をダウンロードさせる

VeriSign Class3Public Primary CA（通称 G1ルート）署名アルゴリズム：SHA-1公開鍵長：1,024bit

VeriSign Class3Public Primary CA - G5（通称 G5ルート）署名アルゴリズム：SHA-1公開鍵長：2,048bit

VeriSign Class3Public Primary CA - G5署名アルゴリズム：SHA-1公開鍵長：2,048bit

VeriSign Class3Extended Validation SSL SGC CA署名アルゴリズム：SHA-1公開鍵長：2,048bit

SSL サーバ証明書（End-Entity)署名アルゴリズム：SHA-1公開鍵長：2,048bit

(a)

(b)

(c)

■G5ルートを持たない古いブラウザの場合G1ルートをアンカーとして、4 階層で署名検証される

■G5ルートを持つ新しいブラウザの場合G5ルートをアンカーとして、3階層で署名検証される※この場合、中間証明書 (c) は無視される


16

チェックリスト No.5 – サーバで利用可能な Cipher Suite を確認しておこうこれまでのチェックポイントでは、「共通鍵暗号」についてあまり触れていません。理由は、「公開鍵暗号」および「ハッシュ関数」は、シマンテックを始めとする認証局がその仕様を決定しますが、

「共通鍵暗号」はブラウザとウェブサーバとの会話（図１に示される SSL ハンドシェイクと呼ばれるプロセスのうち①で示される「仕様交渉」プロセス）によって決定されるためです。ブラウザやウェブサーバがどのような優先順位で仕様交渉を行なうかについての情報はあまり公開されていません。

これに対して NIST では、前に示した暗号アルゴリズムの強度の評価などに加え、サーバ管理者にとって役立つ指針となる、Cipher Suite の選択基準についてのドキュメントを公開しています。以下の表９は、NIST が TLS1.0 において利用推奨するCipher Suite を優先順に記したものです。

残念ながら、企業のサーバ管理者向けに表 9 のような Cipher Suiteの設定マニュアル整備はあまり進んでいません。多くのサーバ管理者は、ウェブサーバを導入し SSL サービスを開始する際には、デフォルトで設定されている Cipher Suite を利用していると考えられますが、表９のような入手可能なドキュメントを参照しながら、「共通鍵暗号」を含めた暗号アルゴリズムのセキュリティ対策を包括的に進めていくことが望ましいと考えられます。同様に国内のサーバアプリケーションベンダーや認証局に対しても、この為のマニュアルやリストを策定し普及を図ってゆくことが求められ始めています＊3。

（参考） OpenSSL で利用可能な Cipher Suite を確認できるウェブサイト

http://www.openssl.org/docs/apps/ciphers.html

表９：NIST が推奨する、Cipher Suite 設定リスト（NIST SP 800-52 “Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations”、 5.2 Server Considerationsより抜粋）

Cipher Suite Auth Key Establishment Encryption Digest

TLS_DHE_DSS_WITH_AES_256_CBC_SHA DSS DHE AES_256_CBC SHA-1

TLS_DHE_RSA_WITH_AES_256_CBC_SHA RSA DHE AES_256_CBC SHA-1

TLS_RSA_WITH_AES_256_CBC_SHA RSA RSA AES_256_CBC SHA-1

TLS_DH_DSS_WITH_AES_256_CBC_SHA DSS DH AES_256_CBC SHA-1

TLS_DH_RSA_WITH_AES_256_CBC_SHA RSA DH AES_256_CBC SHA-1

TLS_RSA_WITH_AES_128_CBC_SHA DSS DHE AES_128_CBC SHA-1

TLS_DH_DSS_WITH_AES_128_CBC_SHA RSA DHE AES_128_CBC SHA-1

TLS_DH_RSA_WITH_AES_128_CBC_SHA RSA RSA AES_128_CBC SHA-1

TLS_DHE_DSS_WITH_AES_256_CBC_SHA DSS DH AES_128_CBC SHA-1

TLS_DH_RSA_WITH_AES_128_CBC_SHA RSA DH AES_128_CBC SHA-1

TLS_DHE_DSS_WITH_AES_256_CBC_SHA DSS DHE AES_256_CBC SHA-1

TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DSS DHE 3DES_EDE_CBC SHA-1

TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA RSA DHE 3DES_EDE_CBC SHA-1

TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA RSA 3DES_EDE_CBC SHA-1

TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DSS DH 3DES_EDE_CBC SHA-1

TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA RSA DH 3DES_EDE_CBC SHA-1


17

チェックリスト No.6 - （サーバ間通信環境の場合）必要なルート証明書の導入を忘れずに続いて、SSL/TLS 通信を用いたサーバ間通信システムの場合です。これには、グループ企業間の Extranet や企業間の受発注システムなど、様々なケースがあります。

「2010 年問題」への対応として、それぞれのサーバが SSL/TLS 通信を行うために導入している SSL サーバ証明書をより安全性の高い暗号アルゴリズムを利用したものに入替えを行うこと、また No.5 に示すようにプロトコルや Cipher Suite の強化を行うことはもちろんですが、対応の中でつい見落とされがちなことがあります。それは「必要なルート証明書が各サーバ側に導入されているか」という点です。

サーバ間通信においてはそれぞれのサーバアプリケーションが、ブラウザに代わって、同時に通信相手の SSL サーバ証明書の署名検証を行うクライアントとしても振舞うことから、署名検証に利用されるルート証明書が導入されている必要があります。通常、シマンテックを含む代表的な認証局のルート証明書はアプリケーションプラットフォームや開発環境（例：Java SE 等）の一部としてプレインストールされていますが、それぞれのバージョンによって含まれるルート証明書の種類が異なるために、サーバ管理者は、ルート証明書の追加の要否、および追加の方法について確認をしておくことをお勧めします。

例：サーバ通信システムが J2EE(Java 言語で構成された企業向けアプリケーション環境 ) で構成されている場合、アプリケーション自身がクライアントとして、通信相手のサーバと SSL/

TLS 通信を行うときは、Java SE などの開発環境に含まれる「cacerts」と呼ばれるファイルにルート証明書が集約されており、「keytool」と呼ばれるツールを使って追加や削除を行います。

( 参考 ) Sun Microsystems 「keytool - 鍵と証明書の管理ツール」

http://java.sun.com/javase/ja/6/docs/ja/technotes/tools/solaris/keytool.html

クライアント環境について理解すべきこと

チェックリスト No.7 - （PC ブラウザ）Windows XPと Windows Vista 以降の違いを把握しておこうPC ブラウザや携帯電話向けにサービスを行う一般的なウェブサイトであれば、SSL サーバ証明書の仕様 (No.1,No.2) を把握した上で、正しくウェブサーバに設定すること (No.3、No.4 およびNo.5) に加えて、サービスを行う対象であるクライアントのアルゴリズム対応状況が把握できれば、情報収集という意味では十分と言えます。

さて、では PC ブラウザや携帯電話は、どの程度 RSA2,048bitや SHA-256 などの安全性の高い暗号アルゴリズムに対応できているのでしょうか？まずは PC ブラウザについてですが、例えばWindows 上で動作する各バージョンのブラウザが、これらのアルゴリズムを正しく扱うことが出来るか、および、これらのアルゴリズムを実装した認証局のルート証明書を導入しているか、という２つの観点で、表 10 に簡単にまとめてみます。

表 10：より強固な暗号アルゴリズムの種類毎の、Windows 上でのブラウザの対応状況

Windows XP Windows Vista Windows 7

IE6 IE7 IE8 IE7 IE8 IE8

RSA2,048bit

アルゴリズムへの対応 ◎ ◎ ◎ ◎ ◎ ◎

アルゴリズムを実装したシマンテックのルート証明書の搭載※ 1

◎( 例：Class3 Public Primary CA - G3, etc)

◎( 同左 )

◎( 同左 )

SHA-256

アルゴリズムへの対応※ 2 ▲ ▲ ▲ ◎ ◎ ◎

アルゴリズムを実装したシマンテックのルート証明書の搭載※ 1 ※ 3

▲( 例：Universal Root CA)

◎( 同左 )

◎( 同左 )

◎：全く問題ない▲：一部の環境では問題ないが、十分でないケースが多い※ 1 : 表中カッコ内の名称は、例として各 Windows OS のバージョンに搭載されているルート証明書を表す。一部略称を使用している。※ 2 : Windows XP の SHA-256 対応は SP3 以降で部分的に適用されている。※ 3 : Windows XP に Universal Root CA が搭載されるのは、「ルート証明書の更新プログラム (KB931125、2009 年 11 月以降版 )」を適用した場合。なお、

Windows Vista 以降、ルート証明書は出荷時に搭載されず、都度マイクロソフト社のオンラインのストアから必要に応じてルート証明書を検索・ダウンロードする方式へ変更となっている。


18

表 10 に記されたプラットフォームの範囲においては、RSA2,048bit への対応は十分に進んでおり、また必要なルート証明書も導入済みであることから、RSA1,024bit からの移行を行うための環境は既に整っていると言えます。一方ハッシュ関数の移行については、SHA-256 へのアルゴリズムの対応、および必要なルート証明書の普及に、まだ時間がかかると考えられます。

クライアントプラットフォームにおける、暗号アルゴリズムおよびルート証明書の普及状況は、認証局が発行する SSL サーバ証明書について仕様変更を行う方法やタイミングを大きく左右します。

例えばマイクロソフトはルート証明書プログラムの中で、認証局に対する「要件 (Requirement)」として、RSA1,024bit からRSA2,048bit への移行、またはハッシュ関数の移行についてのスケジュールを示しています＊7。認証局が発行する SSL サーバ証明書の仕様策定の背景には、こうした OS やブラウザなどクライアントプラットフォームの暗号アルゴリズム対応状況やルート証明書の搭載状況および今後の対応スケジュールとの整合性が保たれています。

サーバ管理者は、より安全な暗号アルゴリズムへの対応が進んでいる新しい OS やブラウザへの移行を促進し、OS やブラウザの提供者および認証局と共に、SSL/TLS 通信の安全性の維持・確保に取り組んでいくことが求められています。

チェックリスト No.8 - （携帯電話）認証局毎に対応率が大きく異なるカバー率を把握しておこう調査によるとシマンテック SSL サーバ証明書は、約 3 割もしくはこれ以上が携帯電話専用のウェブサイト、あるいは PC ブラウザと携帯電話の両方を対象とするウェブサイトで利用されています＊7。

一方、第 2 章で示したように、携帯電話はメモリ容量の制限などを理由に PC ブラウザと比べて扱える暗号アルゴリズムの範囲が狭いと言えます。また同様の理由から、各認証局が提供するルート証明書の搭載数に制限が設けられているため、結果として必要とされるルート証明書の搭載がされていないケースもあります。数多く存在する認証局毎に、いわゆる「携帯電話カバー率」が大きく異なるのは、こうした事情によるためです。また、機種によってはオプションとしてフルブラウザ機能が搭載されていますが、標準のブラウザ機能と扱える暗号アルゴリズムの範囲が異なる場合があるので、こちらも注意が必要です。

一方、最近は iPhone などスマートフォンの普及が進み、メモリ容量の制限が少なくなり、よりPC ブラウザに近づく傾向が見られます。こうした潮流も踏まえ、No.7 で示した PC ブラウザと同様の方法で、携帯電話におけるアルゴリズム対応状況およびルート証明書の導入状況を表 11 にまとめます。

ここでサーバ管理者が注意すべき点は、多くの認証局が、例えば「携帯電話対応率 NN%」とアピールしている場合にも、その中には「200X 年に販売された xx モデル／シリーズ以前を除く」や

「( 機種の販売時期やモデル／シリーズではなく) あるサイトへのアクセス数をベースにしてシェアを算出」など、複雑な制限を設けた上でカバー率を大きく見せるケースです。

携帯電話のモデル／シリーズ別などは一つの指標になりますが、随時変化してゆくものと言えますので、企業のサーバ管理者は、数字の比較だけではなく、モデル毎の正確な対応状況を図り、エンドユーザに伝えていただくことが望ましいと考えられます。

表 11：より強固な暗号アルゴリズムの種類毎の、携帯電話での対応状況

2G 携帯電話 3G 携帯電話スマートフォン

RSA2,048bit

アルゴリズムへの対応 ▲ ○ ◎

アルゴリズムを実装したシマンテックのルート証明書の搭載 × ○※ 1 ○※ 1

SHA-256

アルゴリズムへの対応 × ▲※ 2 ▲

アルゴリズムを実装したシマンテックのルート証明書の搭載 × ▲ ▲

◎：全く問題ない○：多くの環境で問題ない（一部で対応状況が十分でない）▲：一部の環境では問題ない（対応状況が十分でないケースが多い）※ 1 : クロスルート方式を採用することで、多くの環境で署名検証には問題がない※ 2 : NTTドコモの携帯電話では、2009 年冬春モデルよりSHA-256 対応が適用されている


19

（参考）シマンテック SSL サーバ証明書を扱えない携帯電話モデル毎の情報（未対応機種一覧）

http://www.symantec.com/ja/jp/page.jsp?id=ssl-eligibility

また、より正確な情報の入手先として、携帯電話の提供者である各キャリアが公開する情報、例えば以下のウェブサイト等で機種毎のアルゴリズム対応状況やルート証明書搭載状況をチェックすることも可能です。

（参考）各キャリアの SSL/TLS 通信に関する携帯電話仕様について

NTT docomo

http://www.nttdocomo.co.jp/service/imode/make/content/ssl/spec/index.html#taiou

au by KDDI

http://www.au.kddi.com/ezfactory/tec/spec/ssl.html

SoftBank　Mobile

https://creation.mb.softbank.jp/web/web_ssl.html

サーバ管理者は、エンドユーザからの問合せなどに対して、こうした公開情報を事前にチェックしておくことをお勧めいたします。また、PC ブラウザの場合と同様に、より安全な暗号アルゴリズムへの対応が進んでいる新しい携帯電話への移行および利用を促進し、認証局および携帯電話キャリアやメーカーと共に、SSL/TLS通信の安全性の維持・確保に取り組んでいくことが求められています。

チェックリスト No.9 - （携帯電話）「携帯アプリ」(Java、BREW 等 ) の特性を把握しておこう携帯電話向けのサービスの一部には、ウェブブラウザではなく携帯電話上で動作する専用アプリケーションを介して、SSL/TLS通信を行うケースがあります。代表的なアプリケーションプラットフォームとしては、Java の J2ME や BREW などが挙げられます。

多くの場合、これらのクライアント環境からは、エンドユーザがURL を自由に指定してウェブサイトへアクセスをするのではなく、特定のサイトのみとの通信をバックグラウンドで行います。従って、専用アプリケーションを介して通信を行うようなウェブサイト（ウェブサービス）を運営するサーバ管理者は、クライアント側のアプリケーションプラットフォームのアルゴリズム対応状況、および No.6

同様に、ルート証明書導入状況を確認しておく必要があります。

例：携帯電話向けに利用されている BREW プラットフォームの場合、Qualcomm 社のウェブサイトから入手可能な SDK には、それぞれのバージョンに応じてプレインストールされているルート証明書の一覧について、ヘルプコンテンツで参照することが出来ます。

（参考）Qualcomm 社提供の BREW SDK を入手可能なウェブサイト

https://brewx.qualcomm.com/brew/sdk/download.jsp

チェックリスト No.10 - （家電・組込み機器）各機器の通信機能と、ルート証明書を把握しておこう第 2 章に示したように家電やゲーム機、OA 機器などの組込みプラットフォームから SSL/TLS 通信を利用したインターネット接続を行う場合、これらの機器から接続されるサーバの管理者は、必ず

「機器が扱える暗号アルゴリズム」「機器に導入されているルート証明書」を確認した上で、対応する適切な SSL サーバ証明書を選択し、導入する必要があります。

注意すべき点としては、家電や機器はライフサイクルが長いために、機器メーカー側で暗号アルゴリズムの追加やルート証明書の追加を行おうとしても、市場の機器が入れ替わるまでに長い時間がかかることが挙げられます。

こうしたクライアントとの通信を行うサーバ管理者は、一般的なウェブサイトのサーバ管理者の業務に加えて、以下のようなことに注意を払う必要があります。

・長期的な暗号アルゴリズムの動向に対して注意を払う

・認証局の長期的なルート証明書移行プランについて情報収集する

・機器メーカーに対して、新しいアルゴリズムおよび必要なルート証明書の導入を要求する

シマンテックでは「デベロッパープログラム＊4」という取組みの中で、ルート証明書の移行プラン等に関する情報発信や、機器から実際に接続して検証を行っていただけるテスト用ウェブサイトの案内などを行っています。また、常にメディアに対して、世の中のサーバ管理者にとって有用と考えられる情報を発信する取組みを行っています。このような認証局が発信する情報や、提供されるプログラムやリソースを活用することが一つの有効な対策になります。


20

4 いつまでに対策をとる必要があるのか？

第 3 章で紹介したチェックリスト 10 項目では、企業のサーバ管理者がすぐに行うべき、かつ行うことが出来るアクションに着目してご案内しました。ここではこうしたアクションを踏まえて、今後数年の間にどのように移行が進むのか、いくつかの想定を踏まえながらご紹介します。図５をご参照ください。

第 3 章のチェックリスト No.7、No.8 で示したように、SSL サーバ証明書で利用する「公開鍵暗号方式」と「ハッシュ関数」のうち、今後移行が必要となる SHA-256 などの「ハッシュ関数」については、クライアント環境の対応状況が十分でないために、移行にはもう数年かかることが考えられます。一方、「公開鍵暗号方式」で利用される暗号アルゴリズムの移行は比較的スムーズに進めることができるため、最初の「Step1」として実施される可能性が高いと考えられます。

図５：企業のサーバ管理者が「移行」を行うためのタイムラインの例（下記に示す想定 1 および 2 の下で「移行」が進むことを想定した例であり、シマンテックの「移行」タイムラインを示すものではありません）

2010年 2011年 2012年 2013年 2014年 X年 Y年

RSA 1,024bit 鍵を持つ証明書の新規発行

RSA 1,024bit 鍵を持つ証明書の最大有効期限

SHA-1 を利用した証明書の新規発行

SHA-1 を利用した証明書の最大有効期限

RSA 2,048bit 鍵を持つ証明書の新規発行および最大有効期限

SHA-256を利用した証明書の新規発行および最大有効期限

RSA 2,048bit への対応検証期間

SHA-256への対応検証期間

証明書（従来仕様）

証明書（新仕様）

検証・対応期間（推奨）

想定 1：Microsoft 社などの要件に従い、RSA1,024bit 鍵を持つ証明書の新規発行が停止される

想定 2：2010 年末までに発行された RSA1,024bit 鍵を持つ証明書の最大有効期限（シマンテックサーバ IDの場合、3年）※自然に有効期限満了を迎えた場合

※SHA-1 を利用した証明書の発行および利用の停止について、民間企業への明確な要求を示した文書は存在しない。ただし、解読技術の発展に伴い急速に危殆化が進展する危険性がある


21

Step １：「2010 年末を目処に各認証局は発行するSSL サーバ証明書で利用する鍵長を 2,048bit 以上に移行する」

（移行の方法は No.1、No.2 で述べた通りです）

この時、企業のサーバ管理者は、No.3、No.4、No.6 ～No.10 などの対策をとりながら、アルゴリズムの移行に対応することが望まれます。

No.2 で示した通り EV SSL 証明書では既に「Step1」、RSA2,048bit への対応を完了していることから、いち早く対応に取り組む場合は、既に導入実績を数多く持つ EV SSL 証明書の採用をご検討することをお勧めします。

( 参考 ) シマンテック EV SSL 証明書導入事例

http://www.symantec.com/ja/jp/page.jsp?id=ssl-certificates-resources

「ハッシュ関数」についてはどうでしょうか。

Step ２：「SHA-1 の安全性が低下するリスクを監視しながら、ブラウザや携帯電話などが SHA-256 など SHA-2 ファミリへの対応を完了することを待つ」

この時、「SHA-1 の安全性が急速に低下した場合には、どのような対策をとる必要があるのか」について、さらに企業の対策として 2 つの観点からコンティンジェンシープラン（緊急対応計画）を立てておくことが重要になります。

観点 1： SHA-2 を利用した SSL サーバ証明書に切替えることで、利用できなくなると可能性があるクライアントの範囲を把握し、救済策を策定すること。（組込み機器などを利用している場合は、機器メーカーを含めた移行のプランニングを可能な限り早いタイミングで開始することをお勧めいたします）

観点 2： SHA-1 の証明書を利用し続けることで想定される現実的なリスク ( 第 2 章において幾つかの例を紹介 ) を想定し、評価すること。（必要に応じて観点１で評価したリスクとの比較が出来ることが望ましい）

最後に「共通鍵暗号方式」については、No.5 に挙げた NIST の文書などを参考にしながら、以下から始めることが望ましいかもしれません。

Step ３：「サーバ運用時の SSL/TLS 設定に関して、利用するプロトコルと Cipher Suite についてポリシーを制定する」

ウェブサイトの脆弱性診断サービスなどでこうした点を第三者から客観的に評価・指摘してもらうことが可能であり、こうしたサービスを利用することも一つの手段と言えます。


22

5 「2010 年問題」は繰り返されるのか？ 6 最後に

インターネット上に SSL/TLS 通信が普及してから現在までに、主流として利用されてきた暗号アルゴリズムを利用停止して新しい世代に移行するという取組みは前例がありません。それでは、こうした移行の必要性は今後も起こり得るのでしょうか？

NIST では、RSA2,048bit や SHA-224 など、2010 年以降も十分に安全であると評価されたアルゴリズムの中にも、2030年を境に安全性が十分でなくなるものがあると予測しています。長い期間利用するようなシステムを管理する担当者または担当部署は、表１２に示すようにシステムの稼働が終わるまで十分な安全性を保ち続けられる暗号アルゴリズムを利用できるよう設計・あるいは改修を行うべきと言えます。

表 12：システムの利用機関毎に必要とされる最低限の等価安全性　（出典：表２に同じ）

システムの利用期間利用する暗号アルゴリズムが満たすべき最低限の等価安全性

2010 年末まで 80bit

2030 年末まで 112bit

2031 年以降を含む 128bit

特に SHA-224、SHA-256 などを含む SHA-2 ファミリと呼ばれるハッシュ関数のグループは、SHA-1 とよく似た設計がされているために、急速な安全性の低下を向かえるリスクがあることが指摘されています。このためハッシュ関数については「次世代ハッシュ関数」の必要性が認識され、NIST においてこの候補を募るコンテストが現在も行われています。

( 参考 )http://csrc.nist.gov/groups/ST/hash/timeline.html

また、公開鍵暗号方式についても、さらに長い鍵長の公開鍵を利用することのみならず、より短い鍵長で高い安全性を得ることができるといわれている楕円暗号方式 (ECC) の利用が有効であるとも言われています。

暗号アルゴリズムの移行は、認証局のみならずサーバや PC ブラウザのベンダー、そしてこれらを活用して実際にビジネスを行うサーバ管理者の努力を必要とする大きな課題です。ただし予め範囲を特定し、ポイントを抑え、先行して準備することで、サーバ管理者は適切な対策とスムーズな移行を行うことができます。

シマンテックでは認証サービスのリーディング企業として、移行をよりスムーズに行えるよう、証明書の発行業務および皆様のサポートを行ってまいります。

注釈・参考文献

＊1: SHA-1 については、2005 年に衝突探索に必要な計算量は 2^69 から 2^63 まで低下したとの発表がされた。(Xiaoyun Wang, 他 [2005]) その後、さらに 2^52 まで低下との発表もある ([EUROCRYPTO2009]) ため、実際の等価安全性は 80bit を大きく下回っていると考えられる。

＊2: 2007 年 3 月『CRYPTREC Report 2006』

＊3: Internet Week 2009 NTT 情報流通プラットフォーム研究所神田雅透氏、他

＊4: シマンテックデベロッパープログラム https://www.jp.websecurity.symantec.com/developer/index.html

＊5: シマンテックでは独自調査結果に基づく未対応機種の一覧を以下のサイトで公開している。 http://www.symantec.com/ja/jp/page.jsp?id=ssl-eligibility

＊6: シマンテックのルート証明書が搭載されている幅広いクライアント環境について、以下のサイトで公開している。 http://www.symantec.com/ja/jp/page.jsp?id=ssl-eligibility

＊7: 本稿執筆時点での最新版は『EV SSL Certificate Guidelines Version 1.2』、http://www.cabforum.org/documents.html)

＊8: Microsoft Root Certificate Program（http://technet.microsoft.com/en-us/library/cc751157.aspx）

＊9: 2009 年自社調べ

合同会社シマンテック・ウェブサイトセキュリティhttps://www.jp.websecurity.symantec.com/〒104-0028　東京都港区赤坂1-11-44赤坂インターシティTel : 0120-707-637E-mail : [email protected]

Copyright Symantec Corporation. All rights reserved.シマンテック（Symantec）、ノートン（Norton）、およびチェックマークロゴ（the Checkmark Logo）は米国シマンテック・コーポレーション（Symantec Corporation）またはその関連会社の米国またはその他の国における登録商標、または、商標です。その他の名称もそれぞれの所有者による商標である可能性があります。製品の仕様と価格は、都合により予告なしに変更することがあります。本カタログの記載内容は、2014年4月現在のものです。

WPSSL2010_1504

White Paper 「暗号アルゴリズムにおける2010年問 …White Paper...

Documents

Transcript of White Paper 「暗号アルゴリズムにおける2010年問 …White Paper...