サーバ証明書は今が替えどき、「SHA-1」証明書は風前のともしび：セキュリティ強化塾

あまり意識しないSSLサーバ証明書の運用管理。1024ビット鍵長の公開鍵とSHA-1ハッシュアルゴリズムの脆弱性や移行の問題とは？

[キーマンズネット]

　ECサイトや会員制サイトを運営する企業では「SSL」はおなじみの技術だ。あまりにも当たり前の技術すぎて、その安全と信頼の源である「SSLサーバ証明書」の運用管理は日常的にほとんど意識されることがない。

　例えば、1024ビット鍵長のルート証明書をクロスルート証明書によって延命させる措置をまだ続けてはいないだろうか。また現在主流のSHA-1ハッシュアルゴリズムを用いた証明書は数年先にWebブラウザでサポートされなくなるが、移行計画は進んでいるだろうか。

　新しい年を迎え、次期予算策定に向かう今こそ、SSLの仕組みをおさらいした上で、SSLサーバ証明書の運用状況を点検してみよう。

SSLに関連する脆弱（ぜいじゃく）性でなりすまし攻撃の危険が増加中

　SSLに関連して、このところ大きな影響を及ぼす事例が頻発している。

　例えばSSLの実装に不備があるケースでは、2014年4月、OpenSSLバージョン1.01シリーズにTLSのハートビート（死活監視）拡張プログラムにおけるサーバメモリ操作のエラー処理にバグが発見され、攻撃を受けるとメモリ内のデータを抜き取られる脆弱性が指摘された。これは「Heartbleed（心臓出血）」と呼ばれ、脆弱性修正バージョン（1.0.1g以降）への更新かハートビートを利用しないようにする対応が求められた。

　さらに2014年はSSL3.0の脆弱性が公表され、こちらも盗聴の危険が指摘されていて利用を停止することが強く推奨されている。また2014年9月に一部のAndroidアプリで「SSLサーバ証明書を適切に検証しない脆弱性」が発見された。これを悪用されると、不正なSSLサーバ証明書を用いた中間者攻撃により通信が盗聴される可能性がある。

図1 Androidアプリで発見されたSSL実装の欠陥を突いた中間者攻撃のイメージ（出典：IPA）

　これらの事例はSSL/TLSプロトコルそのものやサーバ証明書の脆弱性とは関連がないが、SSL実装に関しては今後も脆弱性が見つかる可能性があることを前提にして、情報発表があり次第、抜かりなく対応していける準備をしておく必要があるだろう。

CA運用の欠陥による問題

　SSL運用の要になるCA（認証局、Certification Authority）運用のセキュリティホールも、2011年に起きた2つの偽SSLサーバ証明書発行事件でクローズアップされた。

　最初に起きた「Comodo事件」では、英国の認証局であるComodoのオンライン証明書発行手続きにセキュリティの不備があり、攻撃者が正当なユーザーになりすまして見かけ上は正当な偽SSLサーバ証明書の不正発行に成功した。

　そのすぐ後に起きた「DigNotar事件」では、オランダのCAであるDigiNotarの複数CAに不正侵入が行われ、SSLサーバ証明書発行機能を不正に使われて500枚以上の偽SSLサーバ証明書が発行されてしまった。このような攻撃に対してユーザー側ではなすすべがないが、報道などに注意して、問題があれば証明書の使用を停止するなどの対応が必要になるだろう。

SSL/TLSプロトコルの脆弱性を突く攻撃

　加えてウイルスを利用してSSL通信データからCookie情報を入手しセッションハイジャックする「BEAST」「CRIME」などの攻撃手法も報告されている。さらに暗号処理の時間差から暗号解読する手法（Lucky 13）も理論的には可能とされている。前者はウイルス感染を防ぐとともに、ブラウザを最新バージョンに更新しておくことで予防可能であり、後者はまだ理論的な可能性が示された段階だ。

SSLサーバ証明書の脆弱性を突く攻撃

　上掲のどれよりも影響が大きくなる可能性があるのが、現在も一部で使用されている1024ビット鍵長の証明書および主流になっているSHA-1ハッシュアルゴリズムを使用した証明書の脆弱性を狙ったなりすまし攻撃だ。

　計算機性能の進化により1024ビット鍵長のRSA暗号やSHA-1によるハッシュは解読され、偽造される危険性が出てくることが、以前から指摘されてきた。ところがどちらも今でもかなり広く使われている。

　つまり、攻撃者が本気で攻撃すれば、本物と見分けがつかない（形式的には正当な）サーバ証明書を作成し、正当なサーバになりすましてクレジットカード番号やパスワードの窃取をはじめとしたさまざまな悪事を働ける状態になっているわけだ。

　上掲の図1の場合は不正なサーバ証明書を受け付けてしまうアプリの欠陥が問題なのだが、この場合は証明書が形式上は正当なので、適切に証明書を検証していてもエラーにならず、被害を受けることが避けられない。フィッシングサイトが巧妙に作られていれば、セキュリティに詳しいユーザーであってもなりすましサーバであることに気付くことは難しいだろう。

　このように、日ごろ特に気を付けることもないSSL通信にも危険が潜んでいる。特に既に脆弱性の存在が明らかなSSL証明書を継続して利用することにはリスクが伴う。今回は、特にSSLサーバ証明書に注目して、その仕組みを理解し、問題点と対応の仕方を考えてみたい。

SSLサーバ証明書の暗号技術とは？

　SSL（Secure Socket Layer）プロトコルは1994年のSSL 2.0に始まり（1.0は実装例がない）、1995年のSSL 3.0に引き継がれ、これまで長い年月使われてきたが、SSL 3.0の仕様上の脆弱性が分かり今後は廃止されること確実だ。

　19999年にはSSLの仕様を受け継いで改善したTLS（Transport Layer Security）1.0プロトコルが誕生し、2006年にTLS1.1、08年にTLS 1.2が策定されている。実際にはTLSを使っていても、通信方式の呼び名としては今でも「SSL」が一般に使われていて、特に技術的な説明の時に両者を総称して「SSL/TLS」といった表記をすることが多い。

　この方式による通信は、図2に示すようにサーバが所有する証明書をクライアント（Webブラウザなど）に提示して、クライアントがその正当性を検証するのが一般的だ（SSLVPNではクライアント側にも証明書を用意してサーバ側でその正当性を検証する）。

図2 SSL通信を確立する手続きのイメージ（一部の手続きは省略）

　図2に見るように、SSLクライアント（Webブラウザなど）には、信頼できるCAが発行したデジタル署名付きの「ルート証明書」が格納されている。サーバにSSL接続を要求したクライアントはサーバから送られてくるSSLサーバ証明書とルート証明書の署名を突き合わせ、正当なCAが発行したものであるか否かを検証する。

　検証できたら、プレマスターシークレットと呼ばれる乱数を生成して、SSLサーバ証明書にある公開鍵で暗号化してサーバに送る。受け取ったサーバは、公開鍵に対応する固有の秘密鍵で復号して、プレマスターシークレットを取り出す。それぞれの側でプレマスターシークレットから「共通鍵」を生成（どちらの側にも同じものができる）し、その後は共通鍵で暗号化してデータを送り出し、受け取ったデータは共通鍵で復号するという仕組みで暗号化通信を行う。

　この仕組みなら、クライアントは相手先のサーバがCAによって認められた正当なものであることが確認（認証）でき、通信経路上で盗聴されない暗号化通信が可能で、通信データが改ざんされた場合はそれが検出できることになる。

　しかし、この仕組みの安全性を保障している重要な要素が証明書と署名であることに注意が必要だ。万一SSLサーバ証明書と署名が偽造された場合には、通信の安全性は根底から崩れ去ってしまう。現在のECサイトやオンラインバンキングなどのサービス、会員制Webサイトなどが依拠する基盤が崩れたら、企業活動はもちろん社会全体が危機に陥ることになりかねない。

　もっとも証明書の偽造は大変な手間がかかる仕事には違いなく、現在までのところ理論的に偽造可能とされているだけで実際に偽造SSLサーバ証明書が使用された例は、研究者や国家規模のサイバー諜報活動による限定的なものにとどまっている。とはいえ明日、突然偽造証明書が自社サイトや従業員がアクセスするサイトに悪用されないとも限らないのが現状なのだ。

1024ビット鍵長の公開鍵とSHA-1ハッシュアルゴリズムの脆弱性

　公開鍵の鍵長が短いと解読、偽造の可能性が高くなる。その危険は10年以上前から懸念されており、世界の技術標準の主導的立場にあるNIST（米国立標準技術研究所）では、2005年の段階で、2010年をめどに次世代暗号技術へ移行するよう勧告している。

　公開鍵暗号方式では「RSA1024ビット鍵長からRSA2048ビット鍵長以上」への移行、ハッシュアルゴリズムはSHA-1からSHA-2への移行が求められた。SHA-1はハッシュ値の長さが160ビットだがSHA-2は224ビット・256ビット・384ビット・512ビットが選べる仕様であり、長いほど安全性が高い。

　NISTの勧告を受ける形で、証明書の世界的標準化機関である「CAブラウザフォーラム」は、2014年1月1日を越える有効期限を持つサーバ証明書については、鍵長2048ビットでなければならないと規定した。またFirefoxを提供するMozillaやChromeを提供するGoogle、Internet Explorerを提供するMicrosoftは、いずれも2014年以降に鍵長1024ビットのルート証明書を無効化していくことを発表している。これらWebブラウザについて1024ビット対応の証明書に残された寿命はわずかだ。

　既に証明書ベンダーでは2048ビット鍵長のサーバ証明書発行が主流になり、1024ビット証明書の発行は停止して、2048ビット証明書へ移行することを強く求めている。また、ほとんどの最新PCやスマートデバイスには2048ビットルート証明書が導入済み（未導入でも簡単にアップデートが可能）なのだが、一部には1024ビットルート証明書でなければ利用できない端末がある。特に日本で利用者がいまだ多い旧型のフィーチャーフォンやゲーム機がそれだ。また2048ビット対応が遅れたベンダーの証明書を継続して利用している端末も中にはある。

　これらの端末でSSL利用サービスを使うユーザーのために、今でも1024ビットルート証明書が利用され続けているのが問題だ。特にフィーチャーフォンが普及した日本では、いまだに1024ビットルート証明書から脱却できずにいる場合が多いようだ。

　それを可能にしているのが「クロスルート証明書」（図3）だ。これは2048ビットルート証明書非対応端末の救済策として、無理に延命を図る策であり、1024ビット鍵長の脆弱性の解決にはなっていない。

　そうした旧型の端末は最新の機種にリプレースすれば問題はなくなる。またルート証明書の更新が可能な場合には、端末機種に対応する2048ビットルート証明書が導入できる。国内の証明書ベンダーでは2013年10月時点で携帯電話対応率が約99.6％超というほど対応機種が幅広いので、証明書の切替えを検討してみるとよいだろう。

図3 クロスルート証明書を使った1024ビット証明書の延命

SHA-1アルゴリズムからSHA-2アルゴリズムへの移行の問題点

　SHA-1ハッシュアルゴリズムの脆弱性によって今後何が起きるだろうか。もちろん署名の偽造が懸念されるのだが、恐らく偽造署名の登場前にWebブラウザ側でのサポートが行われなくなると思われる。

　最初にSHA-1からの脱却を宣言したのがマイクロソフトだ。2013年11月に「Windowsは2017年1月1日以降、SHA-1のサーバ証明書でのSSL通信を拒否する」という指針を出している。またCAに対し、2016年1月1日までに新しいSHA-1 のサーバ証明書およびコードサイニング証明書の発行停止も求めた。代わりに利用できる証明書として、SHA-2の256ビットのハッシュ値を利用する仕様（SHA-256と呼ばれる）を備える証明書が推奨されている。

　2014年9月にGoogleより提供が開始されたChrome バージョン39以降では、SHA-1を利用したSSLサーバ証明書が導入されたWebサイトとのSSL通信時に警告を表示するようにした。アドレスバーにアイコンを表示して注意喚起する方法をとる。バージョンが進むにつれ、より厳しい表現のアイコンに替えていく予定だ。

図4 ChromeのSHA-1ベースのSSLサーバ証明書に対する警告表示の変更予定

　Mozillaも同月、SHA-1証明書の発行と利用を推奨しないことを表明、2015年初期にリリースされるFirefox以降において、SHA-1証明書を仕様するサーバとの通信時、アドレスバーに警告を表示することにした。こちらもいずれはエラーとして表示するなど表現を段階的に厳しくしていく。どのブラウザの場合も、直ちに大きな影響が出ないようにしながら、徐々にSHA-2証明書への移行が進むように誘導していきたいということのようだ。

　なお、2014年10月にはCAブラウザフォーラムでもこれに関する議論が行われており、「2015年1月16日以降、満了日が2017年1月1日を超えるSHA-1証明書の発行を行うべきではない」「2016年1月1日以降、SHA-1証明書を発行してはならない」という指針が出ている。

　このような動向を見ても、SHA-1証明書の存続は風前のともしびであり、できるだけ早めのSHA-2証明書への移行が望ましい。

SSLサーバ証明書の移行のために

　公開鍵の鍵長は2048ビット、ハッシュアルゴリズムはSHA-2を利用するSSLサーバ証明書への移行が望ましい理由は上述の通りだ。ではどのように証明書を置き換えていけばよいだろうか。この際、証明書運用を見直し、より自社にふさわしい証明書を利用したいものだ。2048ビット、SHA-2対応は当然として、次のような点にも注意しておきたい。

サーバの実在証明のレベル

　SSLサーバ証明書はベンダーにより、また種類によりコストが違う。主な種類の違いは、利用企業のサーバが実在するものであることをどう証明するかという点だ。サーバが間違いなくその企業のものであり、その企業も実在していることを、証明書ベンダーが検証した上で発行される証明書のほうが価値が高く、セキュリティのレベルも高いといえる。主に次のような種類がある。

EV（Extended Validation）証明書：

　ドメイン登録はもちろんサイト運営企業の実在を確認した上で、世界共通の認証基準を厳格に満たしているかどうかを審査して発行される。運営企業の実在証明が得られ、信頼性が最も高いが、高価格だ。

企業認証（OV、Organization Validation）証明書：

　レジストラにドメイン登録されているかどうかと、サイトを運営している企業の実在を確認してあり、信頼性は比較的高い。

ドメイン認証（DV、Domain Validated）証明書：

　レジストラにドメイン登録されているかどうかだけを審査し、サイトの運営企業の実在証明はない。信頼性は限定的だが低価格だ。

　予算が見合えばEV証明書がお薦めだ。これを利用すると、閲覧するWebブラウザのアドレス表示箇所に緑色で会社名などが表示され、Webサイトにアクセスした人はひと目でEV証明書を使っていることが分かる。

　「このサービスなら安全だ」と感じてもらえることがブランドイメージを上げる。認証基準において、運営企業の実在確認の要件として法人格の確認が規定されており、人手を使い厳密チェックしているため、信頼性は高い。ECサイトやオンラインバンキング、その他顧客からの信頼が大切なサービスには、ぜひこのタイプの証明書を使いたい。

　逆に、特定のパートナー企業、グループ内企業、各地の自社拠点などのように、サイトを運営する企業の実在が自明であるような場合には、機械的な確認処理で済むドメイン認証の方が安くて早く入手できる良さがある。ただし、ドメイン認証のCAは、機械的な処理であるが故に攻撃者にとっても悪用しやすいため、CAの安全性に疑問があるような証明書ベンダーには注意する必要がある。

　これらの中間が企業認証証明書になる。金銭がからまないサービスを提供している場合には、このタイプで十分な場合が多いだろう。

　なお、グループ企業間などでの利用には「自己署名SSL証明書」が使われるケースがある。これは発行ツールを利用すれば誰でも発行できる証明書で、フィッシング詐欺など不正行為に利用されることが多いため「オレオレSSL証明書」の異名も持つ。

　第三者機関であるCAの認証を通っていないので一般に信頼性が低く、公開Webサイトにはふさわしくない。またこれを利用していると、Webブラウザに「証明書が検証できない」旨の表示が出る。その画面に対して「無視して続行」する操作もできるのだが、この操作に慣れてしまったユーザーは、フィッシング攻撃サイトに対しても警告を無視してアクセスしてしまうことがあり得る。

コスト有利な証明書の購入法

　SSLサーバ証明書は原則として1台のサーバに1枚が必要になるのだが、ベンダーによってはFQDN（完全修飾ドメイン名、Fully Qualified Domain Name）単位で1枚を導入する方法がとれる。

　例えばWebサーバを多数稼働させてロードバランサーで負荷分散して利用している場合、それぞれのサーバに証明書を導入するのではなく、同じFQDNを持つひとかたまりのサーバ群に対して1枚の証明書で済む。これは大きなコスト圧縮効果がある。

　他にも1枚の証明書でサブドメインや別ドメインなど複数の別FQDNで使える「マルチドメイン証明書」など、単体価格は高くても使い勝手のよいオプションがあるので、ベンダーに確認した上で自社にふさわしいタイプを選ぶとよいだろう。

　なお、証明書のリプレースに当たって以前からの証明書の有効期間が残っていた場合、その分の有効期間延長をしてくれるサービス、また移行期間に相当する有効期間をおまけでつけてくれるサービスなどもベンダーそれぞれにあるので、まずは相談してみることをお薦めする。