web-dev-qa-db-ja.com

ルートCAの拇印/指紋をカスタマイズする必要がありますか？ （SHA1またはMD5）

私の目標は、証明書の拇印を「簡単に」確認できるようにすることであり、そうすることでセキュリティを低下させないことです。

RSAベースのビットコインテクノロジーには、「バニティアドレス」と呼ばれる概念があり、ハッシュが ユーザー定義の先行ビット （ コンテンツ とビットの長さは任意です）、セキュリティを低下させることはありません。この概念をCAとその拇印/指紋に適用して、手動での検証を容易にすることができると思います。

enter image description here

もちろん、このハッシュの先頭ビットをカスタマイズするために必要な計算能力は、カスタマイズするビットごとに長くなります（指数関数的に長くなりますか？）。このアクティビティは、何らかの方法でセキュリティを低下させますか？

質問

  • これにより、手動検証が必要な信頼されていないルート証明書のセキュリティが向上しますか？他の種類の証明書はどうですか？

  • SHA1は2番目のプリイメージ攻撃に対して安全です なので、上記の拇印が01:23:45:67:89:01:23:45:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xxを読み取るようにCAがキーを継続的に再生成することにはリスクがありますか？確認）

  • これが良いアイデアである場合、有効期限が長いルートCAに対して、中間、または継続的に短い有効期限を持つユーザーまたはWebサーバーCAに対して、何ビットを設定する必要がありますか？ （2013年）

  • 基準が設定されるまで、どのサーバーソフトウェアがこのカスタマイズ、またはこの再生成のスクリプトをサポートしますか？

  • 検証を容易にするために適切な値はどれですか？すべてゼロに設定すると検証が難しくなる可能性があり、人間はBase10で人間の連続番号付けを簡単にできると考えるため、01:02:03:04:05:06:07:08:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx

tlscryptographycertificatescertificate-authoritysha
3
goodguys_activate

「バニティビット」に特定の値を強制することはセキュリティを低下させません（2番目のプリイメージ耐性は2番目のプリイメージ耐性です）が、それは高価です。つまり、n "バニティビット"を特定の値にするには、（平均して）2ん一致が見つかるまで証明書。試行するたびに、証明書の内容（たとえば、不透明なバイトを含むSubject Key Identifier拡張子）にわずかな変更を加え、次に証明書に署名してハッシュします。署名部分も回避されません（ただし、以下を参照）。拇印も計算されるためです。

この署名操作は、断然、最も高価な部分になります。現実的には、1秒あたり2000回程度（キーの種類とサイズに応じて、数台のPCで）を期待できます。つまり、30の「バニティビット」を取得するには2週間の計算が必要で、ビットを追加するたびにコストが2倍になります。 8つは得られませんbytes;最大4つ。したがって、利点はわずかです。SHA-1ハッシュは20バイトであるため、節約される作業の最大20％です。

また、特定の値に設定されている場合でも、これらのビットをチェックする必要があります。

証明書をnot自己署名にすることで、プロセスを大幅に改善できます。 「自己発行の」証明書は信頼されているアプリオリ（つまり、uber-CAによって発行されたのではなく、マジックによって）ので、自己署名を検証することには真の意味がありません。そのため、その署名は実際に正しい必要はありません。デコードの目的で、おおよそ適切なサイズのバイトのシーケンスである必要があります。

したがって、署名の最後のバイトを変更するだけで「試用証明書」を作成できます。署名フィールドが最後になるため、このプロセスは、1回の試行で1回の基本ハッシュ呼び出しと同じくらい速くなる可能性があります。 GPUといくつかのプログラミングを投入すると、毎秒billionsを試すことができます。

10億は遠くからすばらしく見えますが、それは実際にはほんの30ビットです。良いGPUクラスターとある程度の忍耐力があれば、たとえば52ビット程度のバニティビットが期待できます。これは、SHA-1ハッシュの40のうち13の16進文字に変換されます。私の意見では、これはまだ努力する価値はありませんが、ちょっと、それはあなたのCPUです。

技術面では、それを実行したい場合は、独自のSHA-1-on-GPUを実装することをお勧めします。とにかく、既存の実装を再利用しようとする場合でも、GPUプログラミングに習熟する必要があります。 SHA-1部分自体は難しくありません。

4
Thomas Pornin

これは 証明書のフィンガープリントのグラフィック表現 を表示するためのsshのVisualHostKeyオプションに相当します。

これにより、手動検証が必要な信頼されていないルート証明書のセキュリティが向上しますか？

誤った安心感が生じるおそれがあります。ブラウザ/ sshクライアント/などがポップアップして「危険、信頼できない証明書です！」と表示された場合しかし、あなたの唯一の確認は、指紋全体ではなく、最初の数バイトをチェックすることです。これにより、攻撃者の仕事がはるかに簡単になります。彼らがしなければならないすべてはそれらのビットで始まる自己署名証明書を生成することです。

一方、攻撃者があなたのスキームに気付かない場合は、それがあなたの証明書ではないことが簡単にわかります。

フィンガープリントを表示するクライアントの場合、これはVisualHostKeysの状況と非常に似ていますが、攻撃者が準拠する偽の証明書を生成する方が簡単です。

だから：これに気づいた攻撃者に対して、彼らよりもあなたを傷つけるでしょう。気づかない攻撃者に対して、それはあなたのために役立ちます。

[信頼されたルートに戻る証明書]についてはどうですか？

証明書が検証されたときにクライアントがユーザーの介入なしで接続した場合（Webブラウザーなど）、それは役に立たないと思います。 MITMが実行されているかどうかを確認できる唯一の方法は、接続後に証明書情報を確認した場合です。この時点で、攻撃者は安全なセッションCookieをすでに持っていますが、このチェックを実行しない可能性があります。

さらに、あなたのアドレスに対して有効に署名された証明書を取得するために長い時間を費やした攻撃者は、元の証明書を詳細に調べ、スキームに気づき、それをコピーした可能性が高いです。

4
Michael