20
WHITE PAPER: powered by Symantec White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA-2」 移行対応ガイド 再びやってくる暗号アルゴリズム移行を 無事乗り越えるためのチェックリスト 9項目

White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA …す。SHA-2移行と2010年問題とでは、いくつかの注意点は非 常に似ている一方、その対応プラットフォームのカバレッジに違い

  • Upload
    others

  • View
    8

  • Download
    0

Embed Size (px)

Citation preview

Page 1: White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA …す。SHA-2移行と2010年問題とでは、いくつかの注意点は非 常に似ている一方、その対応プラットフォームのカバレッジに違い

WH

ITE PA

PER

:

powered by Symantec

White Paper

「SSLサーバ証明書のハッシュアルゴリズムSHA-2」 移行対応ガイド再びやってくる暗号アルゴリズム移行を 無事乗り越えるためのチェックリスト 9項目

Page 2: White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA …す。SHA-2移行と2010年問題とでは、いくつかの注意点は非 常に似ている一方、その対応プラットフォームのカバレッジに違い

White Paper :「SSL サーバ証明書のハッシュアルゴリズム SHA-2 移行」対応ガイド

2

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

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

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

Page 3: White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA …す。SHA-2移行と2010年問題とでは、いくつかの注意点は非 常に似ている一方、その対応プラットフォームのカバレッジに違い

White Paper :「SSL サーバ証明書のハッシュアルゴリズム SHA-2 移行」対応ガイド

3

CONTENTS第 1 章 概要 4

第 2 章 なぜ、ハッシュアルゴリズムの SHA-2 への移行が必要なのか? 5

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

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

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

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

検証の結果 NG となることがあるのでしょうか? 9

第 2 章のまとめ 11

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

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

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

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

第 4 章 いつまでに対策をとる必要があるのでしょうか? 17

求められるアクション 18

第 5 章 暗号アルゴリズムの移行はいつまで続けるのか? 19

第 6 章 最後に 19

Page 4: White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA …す。SHA-2移行と2010年問題とでは、いくつかの注意点は非 常に似ている一方、その対応プラットフォームのカバレッジに違い

White Paper :「SSL サーバ証明書のハッシュアルゴリズム SHA-2 移行」対応ガイド

4

第 1 章 概要

ほぼすべてのサーバ管理者が 2013 年に対応を終えた「暗号アルゴリズム 2010 年問題(以下、「2010 年問題」)」。ようやく対応が終わった管理者に、次のテーマがやってきます。それが、ハッシュアルゴリズムの SHA-2 への移行です。

2010 年問題の際には、検証や移行計画などを十分に立てられなかったものの結果的に対応が済んでいたという方もいたと思います。SHA-2 移行と 2010 年問題とでは、いくつかの注意点は非常に似ている一方、その対応プラットフォームのカバレッジに違いがありますので、管理者は、2010 年問題の際にチェックした項目のうちいくつかは同様にチェックしつつ、十分な移行計画に基づいて進める必要があります。

シマンテックでは、2010 年問題に対処してきたノウハウをもとに、企業のサーバ管理者が取り組むべき SHA-2 移行について、現場で活用可能なチェックリストをご用意いたしました。

表1:サーバ管理者のためのチェックリスト 9 項目

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

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

2 CSR の生成方法について確認しておこう SSL サーバ証明書 □

3 クロスルート方式に関する中間証明書の設定方法をおさらいしておこう サーバ設定 □

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

5 (サーバ間通信環境の場合)念には念を。必要なルート証明書の再確認を サーバ設定(またはクライアント環境) □

6 (PC ブラウザ)対応状況の大幅改善。Windows XP と Windows Vista 以降の違い クライアント環境 □

7 (フィーチャーフォン・スマートフォン)カバー率を把握しておこう クライアント環境 □

8 (フィーチャーフォン)「携帯アプリ」(Java、BREW 等 ) の特性を把握しておこう クライアント環境 □

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

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

免責事項

当社は、ここで公開する情報が有用であると考えていますが、この情報について明示的なあるいは暗示的な、いかなる保証も与えるものではありません。当社は、この情報を使用した事によって生ずるいかなる損害に関しても責任を負いません。

Page 5: White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA …す。SHA-2移行と2010年問題とでは、いくつかの注意点は非 常に似ている一方、その対応プラットフォームのカバレッジに違い

White Paper :「SSL サーバ証明書のハッシュアルゴリズム SHA-2 移行」対応ガイド

5

第 2 章 なぜ、ハッシュアルゴリズムの SHA-2 への移行が必要なのか?

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

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

SSL/TLS通信は、情報の「暗号化」の他に、「ウェブサイト運営者の実在性証明」を加えた2つの役割を持っています。ウェブ サーバにSSL サーバ証明書をインストールし、ブラウザからウェブサーバに

「https://」から始まるURLでアクセスした時に、この証明書を利用して、SSL/TLS通信が行われます。このイメージを図1で見てみましょう。

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

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

ルート証明書

シマンテックサーバ ID

①暗号化仕様交渉

②SSLサーバ証明書送付

③共通鍵生成

④暗号化データ通信開始

共通鍵40bit ~ 256bit

共通鍵40bit ~ 256bit

確認OK!

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

https://www. ・・・

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

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

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

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

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

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

Page 6: White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA …す。SHA-2移行と2010年問題とでは、いくつかの注意点は非 常に似ている一方、その対応プラットフォームのカバレッジに違い

White Paper :「SSL サーバ証明書のハッシュアルゴリズム SHA-2 移行」対応ガイド

6

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

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

2010 年問題への対応で移行を終えた「RSA 1,024bit」の公開鍵暗号方式や、ハッシュ関数「SHA-1」は、この尺度によると

「80bit の等価安全性を持っている」と評価されています。これは、このグループに属する暗号アルゴリズムの解読に必要な計算量が 2 の 80 乗相当である暗号の強度を持っている、ということを意味します。

CRYPTREC(Cryptography Research and Evaluation Committees 暗号技術について調査・検討するプロジェクト)では、SHA-1 はすでに実際に解読されるリスクが高まるなど、推奨すべき状態ではなくなった暗号技術として「運用暗号リスト」に掲載され、互換性維持以外の目的での利用は推奨しないとしています。※ 1

また、CRYPTO2012 というカンファレンスにおいて、より少ない計算量で解読可能な SHA-1 に対する原像攻撃が発見された旨の論文が発表※ 2 されました。こうして、暗号アルゴリズムはコンピュータの計算性能向上と新たな攻撃手法の発見によって、さらにその安全性が低下していきます。

これらから、現実的な脅威が目前に迫ってきている状況であることが分かります。つまり、あと数年のうちに、十分な資金や環境を持つハッカーによって SHA-1 に対する攻撃 ( 詳細は後述 ) が成功するという事態が想定されます。

一方、112bit 安全性を持つハッシュアルゴリズム SHA-2( 以下、SHA-224、SHA-256、SHA-384、SHA-512 を 総 称して

「SHA-2」と呼びます ) は、前述の CRYPTREC の暗号リストにおいて電子政府推奨暗号リストとして掲載されており、安全性及び実装性能が確認された暗号技術で今後の普及が見込まれると判断されています。

すなわち、本当の「2010 年問題」への対応は、「80bit 安全性」のハッシュアルゴリズムである SHA-1 の使用を中止し、「112bit以上の安全性」を持つアルゴリズムである SHA-2 への移行によってはじめて完了すると言えます。

これらの背景から、インターネットにおける一般的なセキュリティ要件として「SHA-2」への対応の必要性が高まっています。

例えば、NIST は、米国政府系システムにおいて SHA-1 は最長 2013 年末までに使用停止することとしています(NIST 勧告)し、PCIDSS(Payment Card Industry Data Security Standards クレジットカード業界のセキュリティ標準 ) では、NIST 勧告と同等 (SHA-1 は最長 2013 年末までに使用停止 )のスケジュールを要求しています。

また、民間への影響という意味で最も影響が大きいのがマイクロソフト社のアナウンス※3であり、Windows OSにおけるSSLサーバ証明書の利用について、より安全性の高い SHA-2 への移行を促すと同時に、2016 年末までに SHA-1 の利用を停止すると発表しました。

表2:暗号アルゴリズムの種類毎の等価安全性の評価(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 以上

安全性

Page 7: White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA …す。SHA-2移行と2010年問題とでは、いくつかの注意点は非 常に似ている一方、その対応プラットフォームのカバレッジに違い

White Paper :「SSL サーバ証明書のハッシュアルゴリズム SHA-2 移行」対応ガイド

7

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

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

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

マイクロソフト社のアナウンスでは、Windows OS において2016 年末に SHA-1 の利用停止をうたっており、これ以降、その署名にハッシュアルゴリズム SHA-1 を用いた SSL サーバ証明書については、Internet Explorer などのブラウザにおいて、エラーメッセージが表示されるようになる可能性があります。

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

しかし現在運用中のサーバや、サービスを利用するブラウザは、SHA-2 を扱う準備が整っているのでしょうか?これを明らかにするための検証を確実に行わないと、より大きなトラブルを引き起こしてしまう可能性があります。

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

表3:暗号アルゴリズムの種類毎の用途

暗号アルゴリズムの種類 SSL/TLS 通信における用途現時点で十分に安全と考えられている アルゴリズムの例

公開鍵暗号

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

RSA2048bit、ECDSA(NIST P-256 など )

ハッシュ関数

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

SHA-2(SHA-224, SHA-256 など )

共通鍵暗号

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

AES 128bit など

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

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

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

・一般数体篩法

ハッシュ関数

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

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

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

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

Page 8: White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA …す。SHA-2移行と2010年問題とでは、いくつかの注意点は非 常に似ている一方、その対応プラットフォームのカバレッジに違い

White Paper :「SSL サーバ証明書のハッシュアルゴリズム SHA-2 移行」対応ガイド

8

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

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

ここでは、サーバに導入された SSL サーバ証明書のハッシュアルゴリズムを SHA-1 から SHA-2 に切り替えるケースについて、それぞれの環境でどのような検証が必要となるか、表5に考えられるパターンを整理してみます。

表5:「SSL サーバ証明書のハッシュアルゴリズムを SHA-1 から SHA-2 に切り替える」場合の検証方法の例

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

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

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

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

・ 双方向のサーバ環境

検証のためのサーバ準備

・ ウェブサーバに、SHA-2 で署名された SSLサーバ証明書を導入

・ ウェブサーバに、SHA-2 で署名された SSLサーバ証明書を導入

・ トランザクション通信を行う全てのサーバ環境に、SHA-2 で署名されたサーバ証明書を導入

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

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

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

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

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

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

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

・ 携帯電話が SHA-2 に未対応・ ウェブサーバへの中間証明書の導入忘れなどの設定ミス

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

・ 通信機器が SHA-2 を扱うことができない・ 通信機器の設計・コーディングの不備

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

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

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

Page 9: White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA …す。SHA-2移行と2010年問題とでは、いくつかの注意点は非 常に似ている一方、その対応プラットフォームのカバレッジに違い

White Paper :「SSL サーバ証明書のハッシュアルゴリズム SHA-2 移行」対応ガイド

9

検証の結果 NG となることがあるのでしょうか?

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

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

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

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

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

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

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

SSL サーバ証明書の発行元である認証局のルート証明書がクライアント側に存在していないと、サーバ側の証明書が「正しい認証局から発行されていない、不正な証明書である」と認識されてしまいます。クライアント側のブラウザや機器の実装上の問題である場合も見られますが、多くは、新たに必要となる別のルート証明書が適切に導入されていないケースと考えられます。

パターン3: パターン1、2以外で、とにかく接続ができない

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

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

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

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

これまでのシマンテック・ウェブサイトセキュリティの調査※ 4 では、最新バージョンのウェブサーバでは、「ハッシュアルゴリズム」に関して、SHA-2 対応版の SSL サーバ証明書への対応が進んでいることが確認できています。また、「共通鍵暗号方式」に関しても、AES-128bit などのより安全性の高いアルゴリズムを利用可能なケースがほとんどですが、ウェブサーバの SSL/TLS 通信設定によっては、これより安全性が低いと考えられる DES や RC4 を利用して接続可能な状態になっているケースが多く見られ※ 5、ブラウザとの間で行なわれる暗号の仕様交渉の結果によっては、こうした安全性の低いアルゴリズムによって SSL/TLS セッションが確立されてしまうために注意が必要です。

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

3. ウェブサーバ ( サーバ間通信の場合 )基本的に一般的なウェブサイトの場合と同じですが、一方のサーバが他方のサーバにとってのクライアントとなるサーバ間通信のケースにおいては、相手のサーバの SSL サーバ証明書の検証を行うための「ルート証明書」が双方で利用可能になっているか、注意が必要です。ブラウザ同様に、出荷時に一定のルート証明書がインストールされているサーバアプリケーションも存在しますが、仕様や設定状況を確認した結果、ルート証明書がインストールされていない場合は、認証局などから独自に入手する必要があります※ 6。また、サーバ間通信を伴う環境は大規模な企業システムの一部であることが多く、開発や運用を外部委託するケースが多いために、暗号アルゴリズムの対応状況の検証の為に一定の予算確保が必要となる場合があることへの考慮が必要です。

Page 10: White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA …す。SHA-2移行と2010年問題とでは、いくつかの注意点は非 常に似ている一方、その対応プラットフォームのカバレッジに違い

White Paper :「SSL サーバ証明書のハッシュアルゴリズム SHA-2 移行」対応ガイド

10

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

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

5. 携帯電話(フィーチャーフォン)携帯電話の SHA-2 への対応は 2009 年出荷モデルから順次行われ、その後のモデルについては順次対応されているものの、そのカバー率※ 7 は完全とは言えません。また、過去出荷した機種に対する今後の追加アップデートの計画なども発表されていません。

(2014 年 7 月時点)したがって、SHA-2 対応版の証明書が導入されたウェブサイトには、古い携帯電話機種でアクセス出来ません。携帯電話用の EC サイトなどではあらかじめユーザに対して注意喚起するなどのアクションが必要です。

6. スマートフォンスマートフォンは比較的新しい暗号アルゴリズムへの対応が進んでいて、ほぼすべてのスマートフォンの標準対応ブラウザは SHA-2に対応しています。対応状況について当社サイト※ 8 で確認の上、接続テストを実施してその結果に差が出た場合には、ウェブサーバ側の設定不備(前述)などを疑ってみてもよいでしょう。

7. 組込み機器家電やゲーム機、OA 機器などの組込みプラットフォームでは、CPU の高機能化に伴い搭載機能が増加し、インターネット接続を行う機能を持つものが増えてきています。しかしこうした機器においては、携帯電話と同様、もしくはそれ以上にメモリ容量の制限など実装面での制約が大きく、SHA-2 のようなより安全な暗号アルゴリズムへの対応状況が低いと考えられます。同様に、限られたウェブサーバにのみアクセスを行うケースが多いことから、搭載されるルート証明書の種類も少数に限定される場合が多いようです。

例えばサーバ側の SSL サーバ証明書を SHA-2 対応版に入れ替えると、SSL/TLS 通信に不具合が発生する危険性が考えられます。また、こうした組込み機器は、開発されてからエンドユーザの手に渡り、その寿命を終えるまでのライフサイクルが一般的なブラウザなどと比べて長いことから、不具合が発生した場合にも、機器の入替えなどの対応が進みにくいと考えられます。

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

8. システムインテグレータによる独自開発クライアントサーバモデルシステムインテグレータがその顧客の要望に応じて、ブラウジング機能をもったクライアントソフトを開発するケースがあります。その場合、顧客要望に応じて作りこんでいることからライフサイクルが長く、新しい暗号アルゴリズムに対応していないケースが多く存在しています。また、その多くはシマンテックなどの認証局が配布するルート証明書をインストールして利用していることから、認証局のアルゴリズム移行の影響を受けます。

システムインテグレータが SSL 暗号を用いたシステム/サービスを提供している場合、まず SHA-2 への対応状況を確認し、システム全体の移行計画をたててエンドユーザとその計画を合意する必要があります。

Page 11: White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA …す。SHA-2移行と2010年問題とでは、いくつかの注意点は非 常に似ている一方、その対応プラットフォームのカバレッジに違い

White Paper :「SSL サーバ証明書のハッシュアルゴリズム SHA-2 移行」対応ガイド

11

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

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

第 2 章のまとめ

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

SHA-2 への移行を円滑に進められるか否かは、いかに早く環境の構成要素と、それぞれの要素に対する具体的な対処方法を把握し、その移行計画をたてるかによります。その計画が予算確保まで含めて適切なタイミングで行われていれば、問題の回避は難しくありません。

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

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

SSL/TLS 通信の 各構成要素 提供者

暗号アルゴリズムの利用・選択備考

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

証明書 認証局

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

(ルート証明書・中間証明書は認証局が決定)

- ( 認証局が決定 )

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

サーバシステムシステム開発者

(SIer)

Page 12: White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA …す。SHA-2移行と2010年問題とでは、いくつかの注意点は非 常に似ている一方、その対応プラットフォームのカバレッジに違い

White Paper :「SSL サーバ証明書のハッシュアルゴリズム SHA-2 移行」対応ガイド

12

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

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

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

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

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

図2:一般的な証明書の階層構造(4 階層)の例

セキュア・サーバID - SHA-1版とSHA-2版

1. VeriSign Class 3 Secure Server CA - G3

2. 2048bitRSA 3. SHA1withRSA

1. (End -Entity) 2. 2048bitRSA 3. SHA1withRSA

1. VeriSign Class 3 Public Primary Certification Authority – G5

2. 2048bitRSA 3. SHA1withRSA

1. Class 3 Public Primary Certification Authority

2. 1024bitRSA 3. SHA1withRSA

1. VeriSign Class 3 Public Primary Certification Authority – G5

2. 2048bitRSA 3. SHA1withRSA

ルート証明書

中間CA証明書(クロスルート設定用)

中間CA証明書

End-Entity証明書

1. Symantec Class 3 Secure Server CA - G4

2. 2048bitRSA 3. SHA256withRSA

1. (End -Entity) 2. 2048bitRSA 3. SHA256withRSA

1. VeriSign Class 3 Public Primary Certification Authority – G5

2. 2048bitRSA 3. SHA1withRSA

1. Class 3 Public Primary Certification Authority

2. 1024bitRSA 3. SHA1withRSA

1. VeriSign Class 3 Public Primary Certification Authority – G5

2. 2048bitRSA 3. SHA1withRSA

署名アルゴリズム = RSA SHA-1 (2014年8月現在)

署名アルゴリズム=RSA SHA-2

※専用の新しい中間CA証明書をウェブサーバにインストールいただく必要がございます。 以前にご取得いただいた中間CA証明書をご利用いただくことはできませんのでご注意ください。

ブラウザ側に搭載

ウェブサーバに設定

■凡例1.証明書Subjectの名称2.公開鍵暗号方式および鍵長3.デジタル署名

+中間CA証明書および End -Entity証明書への署名にSHA256withRSA を採用

Page 13: White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA …す。SHA-2移行と2010年問題とでは、いくつかの注意点は非 常に似ている一方、その対応プラットフォームのカバレッジに違い

White Paper :「SSL サーバ証明書のハッシュアルゴリズム SHA-2 移行」対応ガイド

13

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

例えば、認証局は事前にアナウンスしたスケジュールで証明書の階層構造においては「End-Entity」と呼ばれる SSL サーバ証明書のハッシュアルゴリズムを SHA-2 に切り替えて発行します。しかしハッシュアルゴリズムを SHA-2 に移行するにはこれだけでは十分ではありません。この証明書と対になりサーバに設定する中間証明書もハッシュアルゴリズムがSHA-2にする必要があります。一般論として、中間証明書は SSL サーバ証明書更新の際に必ず認証局が指定する最新のものをインストールする必要がありますが、特にこの暗号アルゴリズム移行のタイミングで中間証明書の入れ替えを怠ると、SSL 通信に支障をきたすことになります。

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

表7:シマンテック SSL サーバ証明書中間証明書およびルート証明書で利用される暗号アルゴリズム

シマンテックの SSL サーバ証明書 中間証明書 クロスルート・ルート証明書

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

RSA2048bit SHA-1 or 2 RSA2,048bit SHA-1 or 2 RSA2,048bit* SHA-1

*「クロスルート」という方式が採用されているため、RSA1,024bit のルート証明書を併用する。(クロスルートの詳細については後述)

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

チェックリスト No.2 - CSR の生成方法について確認しておこうハッシュアルゴリズム SHA-2 の鍵を持つ SSL サーバ証明書を発行するために、何か CSR 作成時に管理者が配慮すべきことはあるでしょうか?

SSL サーバ証明書のハッシュアルゴリズムを指定するのは、CSR作成時ではなく、SSL サーバ証明書の申請時です。 従って、CSR 生成時には特に配慮するべき事項はありません。逆に SSLサーバ証明書の申請時に選択するハッシュアルゴリズムとして、誤って SHA-1 を選択すると、SHA-1 の SSL サーバ証明書が発行されてしまいます。

前述の通り、上記のとおり申請・決定したハッシュアルゴリズムをもつ SSL 証明書から正しくチェーンされる中間証明書およびクロスルート証明書を選択してインストールする必要があります。

鍵長の選択については、必ず 2048bit 以上を選択しなければSSL サーバ証明書を申請する際に申請が受け付けられません。すでに一度同様の選択をされていると思いますが、正しく2048bit以上の鍵長を選択できるよう、必要に応じて今一度事前にウェブサーバアプリケーションのマニュアルをチェックし、あるいは必要

に応じてベンダーへ鍵長の指定方法を事前確認しておくことをお勧めいたします。

これらを確認するため、シマンテックでは、テスト用無料 SSL サーバ証明書をご用意しています。

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

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

図2はシマンテックの「セキュア・サーバ ID EV(SHA-1/SHA-2)」の階層構造を表しています。この証明書は、「( 通称 )G5 ルート」と「( 通称 )G1 ルート」という2 種類の独立したルート証明

Page 14: White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA …す。SHA-2移行と2010年問題とでは、いくつかの注意点は非 常に似ている一方、その対応プラットフォームのカバレッジに違い

White Paper :「SSL サーバ証明書のハッシュアルゴリズム SHA-2 移行」対応ガイド

14

書を利用して署名検証を可能にする「クロスルート」という方式を利用して発行されています。ウェブサーバには (a) End-Entity 証明書 ,(b) 中間証明書 , および (c) クロスルート用中間証明書の 3枚の証明書をインストールします。

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

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

シマンテックによる各ブラウザ・携帯電話などからの接続に関する動作確認は、このクロスルート方式を前提に行っています。多くのブラウザではクロスルート用中間証明書を設定しなくても正しく接続される場合もありますが、接続試験の切り分けを複雑化しないため、ウェブサーバの証明書の設定順序について各サーバアプリケーションのマニュアルをチェックし、あるいは必要に応じてベンダーへの事前に確認しておくことをお勧めいたします。

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

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

これに対して NIST では、前に示した暗号アルゴリズムの強度の評価などに加え、サーバ管理者にとって役立つ指針となる、Cipher Suite の選択基準についてのドキュメントを公開しています。以下の表9は、NIST が TLS1.2 において RSA 方式の証明書を用いた場合に利用推奨するCipher Suite を優先順に記したものです。RSA の他、同ドキュメントにおいて、ECDSA(ECC を用いた鍵交換方式)や、DSA(Digital Signature Algorism : 主に米国政府系システムで用いられているアルゴリズム)に関する推奨Cipher Suite も記載されています。

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

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

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

表9:NIST が推奨する、TLS1.0 における暗号セット (Cipher Suite) 設定リスト (TLS 1.2)(NIST SP 800-52 Revision 1 “Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations”、 3.3.1 Cipher Suites より抜粋)

Cipher Suite Name Key Exchange Encryption Hash Function for HMAC

Hash Function for PRF

TLS_RSA_WITH_AES_128_GCM_SHA256 RSA AES_128_GCM N/A SHA-256

TLS_RSA_WITH_AES_256_GCM_SHA384 RSA AES_256_GCM N/A SHA-384

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ECDHE AES_128_CBC N/A SHA-256

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDHE AES_128_GCM N/A SHA-256

TLS_RSA_WITH_AES_128_CBC_SHA256 RSA AES_128_CBC SHA-256 SHA-256

TLS_RSA_WITH_AES_256_CBC_SHA256 RSA AES_256_CBC SHA-256 SHA-256

TLS_RSA_WITH_AES_128_CCM16 RSA AES_128_CCM N/A SHA-256

TLS_RSA_WITH_AES_256_CCM RSA AES_256_CCM N/A SHA-256

Page 15: White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA …す。SHA-2移行と2010年問題とでは、いくつかの注意点は非 常に似ている一方、その対応プラットフォームのカバレッジに違い

White Paper :「SSL サーバ証明書のハッシュアルゴリズム SHA-2 移行」対応ガイド

15

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

SHA-2 移行にあたって前述の確認をするのはもちろんですが、見落とされがちなのが「必要なルート証明書が各サーバ側に導入されているか」という点です。

サーバ間通信においてはそれぞれのサーバアプリケーションが、ブラウザに代わって、同時に通信相手の SSL サーバ証明書の署名検証を行うクライアントとしても振舞うことから、署名検証に利用されるルート証明書が導入されている必要があります。通常、シマンテックを含む代表的な認証局のルート証明書はアプリケーションプラットフォームや開発環境(例:Java SE 等)の一部としてプレインストールされていますし、シマンテックの SSL サーバ証明書の階層構造でいうと、ルート証明書については前述の通り通称 G5/G1 というSHA-1 のものを継続的に利用するため、基本的にはルート証明書の変更は必要ありませんが、念のため、ルート証明書の追加の要否、および追加の方法について確認をしておくことをお勧めします。

例:サーバ通信システムが J2EE(Java 言語で構成された企業向けアプリケーション環境 ) で構成されている場合、アプリケーション自身がクライアントとして、通信相手のサーバと SSL/TLS 通信を行うときは、Java SE などの開発環境に含まれる「cacerts」と呼ばれるファイルにルート証明書が集約されており、「keytool」と呼ばれるツールを使って追加や削除を行います。

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

http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/keytool.html

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

チェックリスト No.6 - (PC ブラウザ)対応状況PC ブラウザや携帯電話は、どの程度 SHA-2 に対応できているのでしょうか?まずは PC ブラウザについてですが、例えばWindows 上で動作する各バージョンのブラウザが、これらのアルゴリズムを正しく扱うことが出来るか、および、これらのアルゴリズムを実装した認証局のルート証明書を導入しているか、という2つの観点で、図10に簡単にまとめてみます。

表10:Windows 上でのブラウザの対応状況

Windows Vista Windows 7,8

IE7 IE8 IE8 以降

ハッシュアルゴリズムSHA-2 への対応 ◎ ◎ ◎

◎:全く問題ない▲:一部の環境では問題ないが、十分でないケースが多い

*Windows XP の SHA-256 対応は SP3 以降で部分的に適用されている。

表10に記されたプラットフォームの範囲におけるハッシュ関数のSHA-2 への移行について、2010 年当時と比較し、Windows 7 などの新しい OS の普及と Windows XP のサポート終了による OS 移行の加速に伴い、SHA-2 へのアルゴリズムの対応は劇的に改善したと言えます。

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

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

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

Page 16: White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA …す。SHA-2移行と2010年問題とでは、いくつかの注意点は非 常に似ている一方、その対応プラットフォームのカバレッジに違い

White Paper :「SSL サーバ証明書のハッシュアルゴリズム SHA-2 移行」対応ガイド

16

チェックリスト No.7 - (フィーチャーフォン・スマートフォン)カバー率を把握しておこう第 2 章で示したように、フィーチャーフォンはメモリ容量の制限などを理由に PC ブラウザと比べて扱える暗号アルゴリズムの範囲が狭いと言えます。また、機種によってはオプションとしてフルブラウザ機能が搭載されていますが、標準のブラウザ機能と扱える暗号アルゴリズムの範囲が異なる場合があるので、こちらも注意が必要です。

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

図11:フィーチャーフォン・スマートフォンでの対応状況

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

ハッシュアルゴリズムSHA-2 への対応

× ▲※ 7 ◎

◎:全く問題ない▲:一部の環境では問題ない(対応状況が十分でないケースが多い)

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

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

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

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

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

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

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

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

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

・ 長期的な暗号アルゴリズムの動向に対して注意を払う・ 認証局の長期的なルート証明書移行プランについて情報収集する・ 機器メーカーに対して、新しいアルゴリズムおよび必要なルート証明書の導入を要求する

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

Page 17: White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA …す。SHA-2移行と2010年問題とでは、いくつかの注意点は非 常に似ている一方、その対応プラットフォームのカバレッジに違い

White Paper :「SSL サーバ証明書のハッシュアルゴリズム SHA-2 移行」対応ガイド

17

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

マイクロソフト社は前述の要件の中で認証局に対して、2015 年末までにハッシュアルゴリズム SHA-1 を利用した SSL サーバ証明書(End-Entity 証明書)および中間証明書の発行を停止し、2016 年末までにそれらの証明書の利用停止を求めています。その要件に対して、シマンテックを始めとした多くの認証局は同様の方針で SHA-1 証明書の発行停止と SHA-2 証明書への移行を表明しており、サーバ管理者もこれに対応する必要があります。

シマンテックでは、スムーズな SHA-2 への移行を進めるため、SHA-2 証明書の発行拡大を進めるとともに、SHA-1 証明書の順次発行停止を進めていくスケジュールを公表しています。※ 9

第 4 章 いつまでに対策をとる必要があるのでしょうか?

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

2010年 2011年 2012年 2013年 2014年 2015年 2016年 2017年

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

一般的なWebサーバ・ブラウザのSHA-2 対応・普及期間

SSL通信を行うすべてのアプリケーション・デバイス等のSHA-2 対応・普及期間

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

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

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

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

SHA-2 対応検証期間

証明書(従来仕様)

証明書(新仕様)

検証・対応期間

(参考)Microsoft WindowsにおけるSHA-1 サポート期間

STOPSTOP

STOPSTOP

Page 18: White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA …す。SHA-2移行と2010年問題とでは、いくつかの注意点は非 常に似ている一方、その対応プラットフォームのカバレッジに違い

White Paper :「SSL サーバ証明書のハッシュアルゴリズム SHA-2 移行」対応ガイド

18

求められるアクション

SSL/TLS 通信はクライアント/ブラウザとサーバとの間で行う通信であるため、それぞれ行うべき対処を下表のとおりまとめました。

(表11)

SHA-1 を利用するウェブサイト管理者やブラウザベンダ等は、約2 年の間に SHA-2 への移行を済ませる必要があり、検証から移行まで含めた予算計画・実行計画を策定するにあたって、決して早すぎるタイミングではありません。

ウェブサイトのレスポンス改善に寄与する、ECC( 楕円曲線暗号 ) の導入検討ECC は、現在の標準的な公開鍵暗号方式である RSA に比べ、短い暗号鍵長でも、より強固なセキュリティを実現することができる暗号技術です。2013 年にシマンテックが発行を開始した ECC証明書は、すべてそのハッシュアルゴリズムに SHA-2 を用いており、すでにマイクロソフト社の要件を満たした仕様となっていますし、等価安全性 128bit の暗号強度を実現したものとなっています。※ 10

ホスティング事業等を展開する株式会社ディレクターズは、ECC(SHA-2) 対応版 SSL サーバ証明書を導入することで、Web サーバの CPU にかかる負荷が 46%軽減され、応答時間が7%改善されたことを確認しました。

ハッシュアルゴリズムの SHA-2 移行を進めるための一つの選択肢として、RSA 方式よりもブラウザなどの対応率は劣るものの、上記の通りウェブサービスのパフォーマンス改善に寄与する ECC 証明書の存在も知っておくとよいでしょう。

共通鍵暗号方式について最後に「共通鍵暗号方式」については、No.4 に挙げた NIST の文書などを参考にしながら、サーバ運用時の SSL/TLS 設定に関して、利用するプロトコルと Cipher Suite についてのポリシー制定から始めることが望ましいかもしれません。

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

表11:SHA-2 への移行に関する求められるアクション

SHA-2 の導入 SHA-1 の利用停止

ウェブサイト管理者・SHA-2 証明書の検証 ・ SHA-2 証明書の順次導入(最長 2016 年 12 月31 日まで)

・ SHA-1 証明書が 2017 年を超える場合、再発行などの手段によって SHA-2 証明書を順次導入

API を利用したシステム間連携の管理者・SHA-2 証明書のシステム間連携検証・ SHA-2 証明書やルート証明書の導入(最長 2016年 12 月 31 日まで)

・ SHA-1証明書の有効期限が2017年を超える場合、再発行などの手段によって SHA-2 証明書を順次導入

ブラウザベンダ / 組み込み機器ベンダ・SHA-2 アルゴリズムへの対応・ SHA-2 ルート証明書をブラウザや組み込み機器へ実装

・ SHA-1 証明書に対して順次警告表示などの対処

Page 19: White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA …す。SHA-2移行と2010年問題とでは、いくつかの注意点は非 常に似ている一方、その対応プラットフォームのカバレッジに違い

White Paper :「SSL サーバ証明書のハッシュアルゴリズム SHA-2 移行」対応ガイド

19

第 5 章 暗号アルゴリズムの移行はいつまで続けるのか?

鍵長 RSA2048bit への移行を 2013 年末までに終えるや否や、SHA-2 への移行検討を開始しなければいけない。こうした移行の必要性は今後も起こり得るのでしょうか?

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

表12:システムの利用機関毎に必要とされる最低限の等価安全性(出典:表2に同じ)

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

2010 年末まで 80bit

2030 年末まで 112bit

2031 年以降を含む 128bit

特にハッシュ関数 SHA-2 は、SHA-1 とよく似た設計がされているために、「次世代ハッシュ関数」の必要性が認識され、NIST においてこの候補を募るコンテストを行い、2012 年 10 月に最終候補の一つである Keccack を「SHA-3」として選んだことを発表※ 11 し、今後仕様の最終調整を行って仕様確定を行うとしています。

また、公開鍵暗号方式についても、前述の通り楕円曲線暗号 (ECC)の利用が有効であると言われています。

第 6 章 最後に

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

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

Page 20: White Paper 「SSLサーバ証明書のハッシュアルゴリズムSHA …す。SHA-2移行と2010年問題とでは、いくつかの注意点は非 常に似ている一方、その対応プラットフォームのカバレッジに違い

White Paper :「SSL サーバ証明書のハッシュアルゴリズム SHA-2 移行」対応ガイド

20

合同会社シマンテック・ウェブサイトセキュリティ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)またはその関連会社の米国またはその他の国における登録商標、または、商標です。その他の名称もそれぞれの所有者による商標である可能性があります。製品の仕様と価格は、都合により予告なしに変更することがあります。 本カタログの記載内容は、2015年4月現在のものです。

WPHashSHA-2_2014_1504

注釈・参考文献※ 1: 2013 年 7 月『CRYPTREC Report 2012 暗号方式委員会報告書』

http://www.cryptrec.go.jp/report/c12_sch_web.pdf※ 2: New Preimage Attacks Against Reduced SHA-1

http://www.iacr.org/conferences/crypto2012/slides/6-3-Knellwolf.pdf※ 3: Microsoft Root Certificate Program(2014 年 7 月時点)

http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx

※ 4: シマンテック・ウェブサイトセキュリティによる動作検証済みハードウェア https://knowledge.symantec.com/jp/support/ssl-certificates-support/index?page=content&id=SO23044

※ 5: 2012 年 IPA 「SSL サーバ設定状況等の調査報告書」 http://www.ipa.go.jp/files/000014264.pdf

※ 6: シマンテック・ウェブサイトセキュリティ デベロッパープログラム https://www.jp.websecurity.symantec.com/developer/index.html

※ 7: 2014 年 7 月時点でアクセスカバー率 7 割程度です。 検証結果は以下をご確認ください。 https://knowledge.symantec.com/jp/library/VERISIGN/VSJ/resources/client-sha2ee.pdf

※ 8: アクセスカバー率:99.9% https://knowledge.symantec.com/jp/support/ssl-certificates-support/index?page=content&id=SO23044

※ 9: シマンテックの証明書製品における SHA-2 への対応スケジュールのご案内 (2014 年 3 月 4 日 ) https://www.verisign.co.jp/ssl/about/20140304.html

※ 10: シマンテック ECC 証明書 http://www.symantec.com/ja/jp/page.jsp?id=ssl-ecc-dsa-encryption

※ 11: NIST Third-Round Report of the SHA-3 Cryptographic Hash Algorithm Competition (2012 年 11 月 ) http://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7896.pdf