Google が暗号化アルゴリズム SHA-1 の廃止を急いでいる理由

[[120276]]

ハッシュアルゴリズムのヒルベルト曲線図 (Ian Boyd 提供)

Googleの公式ブログは、ChromeブラウザにおけるSHA-1証明書のセキュリティ表示を段階的に削減していくと発表しました。しかし興味深いのは、Google.com は現在 SHA-1 で署名された証明書を使用していますが、この証明書は 3 か月後に期限切れになり、Google は 2015 年から SHA-2 で署名された証明書を使用する予定だということです。 SHA-1 アルゴリズムには重大な弱点は見つかっていませんが、証明書の偽造コストはますます低くなっています。

概要

安全なウェブサイトのほとんどが安全でないアルゴリズムを使用しており、Google はこれが長期的な緊急事態になると発表しました。

SSL 暗号化を使用する Web サイトの約 90% は、個人情報のなりすましを防ぐために SHA-1 アルゴリズムを使用しています。 URL にアクセスすると、パスワードが攻撃者に送信されず、実際の Facebook にアクセスしていることが保証されます。残念ながら、SHA-1 アルゴリズムは非常に脆弱であり、長い間その状態が続いてきました。このアルゴリズムのセキュリティは年々低下していますが、インターネットでは依然として広く使用されています。代替となる SHA-2 は十分に強力であり、広くサポートされるはずです。

Google は最近、Chrome ブラウザを使用すると、多数の安全な Web サイトに対するブラウザの警告が今後も変更されることになると発表しました。

2017 年まで有効な証明書を持つサイト向けの Chrome の変更

最初の警告はクリスマス前に発せられ、今後6か月間にわたって次第に厳しくなる予定だ。最終的には、2016 年まで有効な SHA-1 証明書を持つサイトにも黄色の警告が表示されるようになります。

Google は一連の警告を発することで長期的な緊急事態を宣言し、状況が悪化する前にサイトを更新するようユーザーに促している。これは良いことです。なぜなら、SHA-1 は段階的に廃止される時期であり、人々は SHA-1 の潜在的なリスクを十分に真剣に受け止めていないからです。

SSL を使用する Web サイトをお持ちの場合は、私が作成した SHA-1 テスト ガジェットを使用してサイトをテストし、どのように動作すべきかを確認できます。ウェブサイトを持っていない場合でも、読んでみることをお勧めします。次のブログ投稿では、SSL と SHA-1 が Web 上でどのように連携するか、Google が言うようにそれがなぜそれほど緊急であるか、そしてブラウザがそれに対して何をしているかについて説明します。

また、セキュリティ コミュニティにとって、Web サイトのセキュリティ アップグレードを急いで行う必要がないように、証明書の置き換えプロセスをより簡単かつ簡単にすることも重要です。 #p#

ポピュラーサイエンス: セキュアハッシュアルゴリズムと SHA-1

セキュア ハッシュ アルゴリズム (英語: Secure Hash Algorithm) は、デジタル メッセージに対応する固定長の文字列 (メッセージ ダイジェストとも呼ばれる) を計算できるアルゴリズムです。また、入力メッセージが異なる場合、異なる文字列に対応する可能性が非常に高くなります。SHA は、FIPS によって認定された 5 つの安全なハッシュ アルゴリズムの 1 つです。これらのアルゴリズムは、次の 2 つの点に基づいて「安全」であると言われています (公式標準で説明されているとおり)。

1. メッセージ要約から元の入力メッセージを推測するのは計算上困難です。

2. 計算理論の観点から、同じメッセージ ダイジェストに対応する 2 つの異なるメッセージ セットを見つけることも非常に困難です。入力メッセージに変更を加えると、結果のメッセージ ダイジェストが完全に異なる可能性が高くなります。

SHA (Secure Hash Algorithm) は、国家安全保障局 (NSA) によって設計され、国立標準技術研究所 (NIST) によってリリースされた一連の暗号化ハッシュ関数です。

SHA-1 の紹介

SHA-1 の置き換えがなぜそれほど重要なのかを理解するには、まずブラウザの立場に立って考えてみましょう。

SSL を使用する Web サイトにアクセスすると、Web サイトはブラウザにファイル (ID カードに類似)、つまり SSL 証明書を提示します。この証明書は、Web サイトへの接続を暗号化し、Web サイトの真の ID を確認するという 2 つの目的で使用されます。

接続を暗号化するために任意の証明書を使用できます。しかし、本物の Facebook (偽物ではない) にアクセスしていることを確認するために、ブラウザは緑色のロックが表示される前に、何らかの方法で証明書が本物であるかどうかを判断する必要があります。

検証プロセスを完了するために、ブラウザは、Web サイトの証明書が権威ある組織 (証明機関、略して「CA」) によって発行されたかどうかを確認します。 CA は通常、Web サイトに証明書ファイルを発行する際に料金を請求します。ブラウザは、Verisign、GoDaddy、米国国防総省など 56 を超える CA (ルート CA) によって作成および保証された証明書と、56 のルート CA によって承認された数千の中間 CA を信頼します。ご想像のとおり、これは非常に欠陥のあるシステムですが、それが現実なのです。

ChromeでURLの前の緑色の鍵をクリックすると何が表示されますか

当時この Web サイトの CA は Comodo であり、Namecheap を通じて購入されました。ウェブサイトの SSL 証明書が CA によってそのサイトに発行されたと主張する場合、ブラウザは別の重要なテストを実行する必要があります。証明書自体がその事実を証明できるかどうかです。

インターネットでは一般的に、事実を証明するために数学が使用されます。証明書が発行されると、CA は秘密鍵を使用して証明書に署名することで ID の証明を提供します。ある意味では、本物の CA だけがこの署名を実行でき (秘密鍵を紛失しない限り、笑、私はよく鍵を紛失します)、ブラウザは署名を検証できます。

しかし、CA は実際には生の証明書に署名しません。まず、「一方向ハッシュ」アルゴリズム (MD5、SHA-1、SHA-256 など) を実行して、証明書を一意のフィールドに圧縮します。

Chrome ブラウザからの証明書スニペット

一方向ハッシュ アルゴリズムは情報を圧縮します。たとえば、3.2 MB バージョンの「戦争と平和」を SHA-1 で実行すると、次のようになります。

baeb2c3a70c85d44947c1b92b448655273ce22bb

MD5file.com からの結果 (興味深いオンライン ハッシュ計算機)

SHA-1 と同様に、一方向ハッシュ アルゴリズムを使用して、一意の不可逆なデータ ブロックを生成します (元のテキストはスラグと呼ばれます)。 「戦争と平和」の内容を aeb2c3a70c85d44947c1b92b448655273ce22bb から元に戻すことはできなくなりました (つまり、ハッシュ操作は元に戻せません)。他のファイルが同じデータ ブロックを生成できない (つまり、フィンガープリントが一意である) ことも重要です。コンテンツに小さな変更を加えるだけでも、SHA-1 操作の結果は大きく変わり、前の操作と次の操作の相関関係を見つけることが難しくなります。

2 つのファイルが同じハッシュ操作の後に同じ値を生成する場合、この現象は「衝突」と呼ばれます。衝突は理論的には起こり得ますが、その確率は非常に低いため、現実的には不可能だと考えられています。

ブラウザは証明書を検出すると、証明書情報の SHA-1 ハッシュを計算し、それを証明書が ID 証明として使用している元の SHA-1 ハッシュと比較します。 SHA-1 の結果は一意であるため、2 つの値が同じであれば、ブラウザは提供された証明書と CA によって発行された証明書が同じであり、改ざんされていないと確信できます。

ターゲット サイトの証明書と衝突する証明書を設計すると、CA を騙してこの証明書を発行させることができます。最終的には、この証明書を使用してターゲット サイトを偽装することができ、ブラウザーでさえ違いを認識できなくなります。

詳細: 署名アルゴリズムと SSL 証明書の詳細を知りたい場合は、Joshua Davis がここで非常に詳しく説明しています。

http://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art012

#p#

SHA-1 攻撃

2005 年、暗号学者は SHA-1 が予想よりも 2,000 倍速く解読できることを実証しました。しかし、それを解読するのは依然として非常に困難で費用もかかります。しかし、コンピューターが高速化、低価格化するにつれ、SHA-1 がインターネットで使用されなくなるのは時間の問題です。

その後、インターネットでは SHA-1 が引き続き使用されました。 2012 年に、Jesse Walker 氏は SHA-1 証明書の偽造にかかるコストの見積もりを作成しました。この評価では、Amazon Web Services の価格設定とムーアの法則を参照します。

当時、ウォーカー氏は、SHA-1 の衝突による損害は、2012 年には 200 万ドル、2015 年には 70 万ドル、2018 年には 17 万 3000 ドル、2021 年には 4 万 3000 ドルになると見積もっていました。これらの数字に基づき、シュナイアー氏は、犯罪グループが2018年までに証明書を偽造できるようになり、科学機関も2021年までに証明書を偽造できるようになると示唆している。

Walker の評価と Schneier の推論は、SHA-1 の置き換えをめぐる計画と議論において広く引用されました。主要な CA のグループである CA Security Council は最近、Walker 氏と Schneier 氏の結論を利用して、Google のタイムラインについて不満を述べた。 CAは評価結果を武器に状況を反駁し、「このような攻撃は2018年までは実際には起こらない」と主張した。

私は、CA 安全保障理事会の立場が漫画のように子供っぽいと思う。彼らは、交換プロセスの加速が彼らに大きな不便（率直に言って、時間とお金）をもたらすことをよく知っているので、問題を隠蔽しているだけのように思えます。

ウォーカー氏とシュナイアー氏の評価は、スノーデン氏の暴露以前、政府も敵であることが明らかになる前に行われたものだ。彼らの推定によると、2014年に証明書を偽造するのにかかる費用は200万ドル未満で、多くの一流セレブが支払える金額だった。

彼らがこれを実行するとどうして確信できるのでしょうか? それは、彼らがすでに実行しているからです。 （とにかく、そんなにお金をくれたらそんなバカなことはしません）

カスペルスキー研究所、Flameウイルスに感染したコンピューターを監視

2012年に研究者たちは有名な炎ウイルスを発見しました。ワシントン・ポスト紙は、これはイランから情報収集し、イランの核兵器計画を阻止するための米国とイスラエルの協力だったと報じた。漏洩したNSA文書がこの見解を裏付けているようだ。 Flame ウイルスは、MD5 (SHA-1 の前身) 衝突を実装する偽造 SSL 証明書に依存しています。残念なことに、MD5 は何年も研究されていたにもかかわらず、当時はほとんど知られていない手法が使用されていました。この事件から得られる教訓は、最も危険な脆弱性は未知であると想定すべきだということです。

MD5 に関して興味深い話があります。 SHA-1 と同様に、MD5 にも脆弱性があることがかなり以前に発見されており、SHA-1 と同様に、MD5 をインターネットから削除するのに驚くほどの時間がかかりました。

MD5 は 1995 年に初めて理論上の脆弱性があることが明らかになり、時間の経過とともに脆弱性が増していきましたが、2008 年まで一部の CA によって使用されていました。

Chromeでchrome://settings/certificatesから確認する

これは重大な状況であったにもかかわらず、Chrome は MD5 が信頼できないことが最初に証明されてから 16 年後の 2011 年まで MD5 のサポートを削除しませんでした。

インターネット上の署名アルゴリズムを変更すると、独特の課題が生じます。ブラウザが SHA-1 をサポートしている限り、誰の証明書でも偽造できるのです。ブラウザは SHA-1 で署名された偽の証明書しか認識せず、「本物の」証明書があることや、証明書が SHA-2 で署名される必要があることを認識しないため、SHA-1 で署名された偽の証明書を使用して、SHA-2 で署名された証明書になりすますことができます。 （簡単に言うと、対象サイトの証明書を偽装するために、偽造された証明書の情報は、署名アルゴリズムが SHA-1 に変更されている点を除いて、対象サイトの証明書とまったく同じです。）つまり、SHA-1 を使用した証明書の偽造を防ぐ唯一の方法は、ブラウザが SHA-1 のサポートをキャンセルすることです。 #p#

さまざまなブラウザからの応答

SHA-1 の廃止計画を最初に発表したのは Microsoft であり、Windows と IE は 2016 年以降 SHA-1 証明書を信頼しなくなります。 Mozillaも同じ決定を下した。 Microsoft と Mozilla はユーザーにこの問題を通知しましたが、どちらもユーザー インターフェイスを変更する予定は示していません。

一方、Google は最近、SHA-1 が脆弱すぎるため、Chrome ブラウザでユーザーに警告を表示するという衝撃的な発表をしました。

「Chrome の HTTPS セキュリティ インジケーターを通じて、SHA-1 が当初の設計要件を満たしていないという事実を強調する予定です。私たちは定量化可能なアプローチを採用し、セキュリティ インジケーターを徐々に下げ、タイムラインを徐々に進めていきます。」

Google のライアン・スリーヴィ氏は 2 週間前に初めて Chrome の予想される戦略を発表しました。議論の全文を読むことをお勧めします。リンクは次のとおりです。

https://groups.google.com/a/chromium.org/d/msg/security-dev/2-R4XziFc7A/NDI8cOwMGRQJ

多くの CA や大規模 Web サイト運営者が参加し、Ryan Sleevi 氏と議論しようとしているのがわかるでしょう。なぜなら、Ryan Sleevi 氏は、脆弱な証明書の発行を来年まで延期するのではなく、今すぐに停止すべきだと彼らに伝えているからです。

これは Google による大胆な動きであり、大きなリスクを伴います。ブラウザが署名アルゴリズムを削除するのが非常に難しい主な理由は、ブラウザが重要なサイトが危険であるとユーザーに通知すると、ユーザーはブラウザに何か問題があると考え、ブラウザを変更してしまうためです。 Google は、ユーザーが Chrome のセキュリティを十分に信頼し、プログラムの不便さを受け入れるほど気に入っていると賭けているようだ。 （結局のところ、最初に試したのは Google なので、称賛に値します！）

オペラはグーグルの計画を支持すると述べた。 Safari チームは見守っており (一般に「傍観者」として知られている)、何の声明も出していない。 #p#

ガイダンス

移行を支援するために、サイトが SHA-1 を使用しているかどうか、および更新する必要があるかどうかを確認できる小さなサイト www.shaaaaaaaaaaaa.com を作成しました。

A の文字の数は予測できない大きな素数です (著者がなぜそのような数字を選んだのか不思議です。答えを教えていただけませんか? 笑)

新しい証明書要求を送信し、CA に SHA-2 を使用する新しい証明書を発行してもらう必要があります。既存の秘密鍵を使用します:

openssl req -new -sha256 -key your-private.key -out your-domain.csr

-sha256 フラグは CSR を SHA-2 で署名しますが、SHA-2 で署名された証明書を発行するかどうかは CA が決定します。私は、さまざまな CA から SHA-2 証明書を取得することに関する質問と解決策をフォローしてきました。ウェブサイトに記載されていない問題が発生した場合は、こちらで報告してください。すぐにウェブサイトを更新します。

SHA-1 中間証明書もデジタル署名によって検証する必要があるため、すべて更新することをお勧めします。つまり、CA が SHA-2 中間証明書を発行したかどうか、またどこで発行されたかを追跡する必要があります。また、さまざまな CA によって発行された SHA-2 中間証明書の場所を追跡してきました。ウェブサイトに記載されていないものを見つけた場合、または CA に中間証明書がない場合は、こちらで報告してください。

サイトを所有しているが、証明書を別の会社が管理している場合は、その会社のカスタマー サービスに電子メールで連絡して知らせることができます。 Google にアナウンスのリンクを送信し、タイムラインを尋ねます。もちろん私も助けが必要です。よろしければ、サイト上の未解決の問題を確認して、手伝ってください。

SHA-1 ルート証明書: ブラウザに付属する SHA-1 ルート証明書の整合性はデジタル署名によって検証されないため、心配する必要はありません。

結論は

SHA-1 を廃止する動きは、ずっと前から必要だった。 CA は長い間有効な対策を講じることができなかったため、高まる圧力によって生じたすべての問題は、Google をスケープゴートにするのではなく、CA に向けられるべきだ。

個人にとって、証明書の取得はドメイン名の購入と同じくらい簡単で、インストールは Web サイトを開くのと同じくらい簡単で、変更は自動化されている必要があります。これらのアイデアは、オープンソース ツールに対する非常に明確なビジネス チャンスとニーズを示しています。

組織では、インフラストラクチャの設計と更新中に、証明書の頻繁なローテーションを優先する必要があります。この作業をうまく行う組織は、作業の結果をオープンにして共有する必要があります。

その間、ウェブサイト運営者は証明書を更新し、Heartbleed レベルの緊急事態が発生していないことを機会として SSL 構成を見直し、前方秘匿性などの機能を有効にする必要があります。

【参考情報元：Why Google is Hurrying the Web to Kill SHA-1. 内容は、原文の意味をできるだけ保つように編集されています。 [Rabbit_Runからの翻訳]