web-dev-qa-db-ja.com

OpenSSHがDSA鍵を廃止した理由

質問がありました SSH認証キーのRSAとDSAの比較 どのキーがより良いかを尋ねる。基本的に、すべての回答はDSAよりもRSAを支持するものでしたが、DSAがなんらかの理由で安全でないとは本当に言いませんでした。

しかし現在、DSAはOpenSSHによって非推奨になり、後で完全に削除されます： https://www.gentoo.org/support/news-items/2015-08-13-openssh-weak-keys.html

情報には、

OpenSSHの7.0リリース以降、ssh-dssキーのサポートは、継承の弱点のために、実行時にデフォルトで無効になっています。これらのキータイプに依存している場合は、修正措置を講じる必要があります。そうしないと、ロックアウトされるリスクがあります。

最善のオプションは、rsa、ecdsa、ed25519などの強力なアルゴリズムを使用して新しいキーを生成することです。 RSAキーは他のクライアント/サーバーとの最大の移植性を提供し、ed25519はOpenSSHで最高のセキュリティを提供します。

DSA鍵の本質的な弱点は何ですか？

sshrsaopensshdsa
72
Petr

これは良い質問です。 OpenSSHの 専用ページ は次のように述べています。

OpenSSH 7.0以降も同様に、ssh-dss（DSA）公開鍵アルゴリズムを無効にします。それも弱いので、使用しないことをお勧めします。

これは発表からの「継承の弱点」にすぎません。 「最近の発見」について語る根拠のないイタチを除いて、これらの弱点についての公開された説明は見つかりませんでした。したがって、それはいくつかの調査の時間です。

OpenSSH-6.9p1（Ubuntu 15.10パッケージ）のソースコードで、鍵生成ツールssh-keygen、私はこの驚くべきコードを見つけました：

    maxbits = (type == KEY_DSA) ?
        OPENSSL_DSA_MAX_MODULUS_BITS : OPENSSL_RSA_MAX_MODULUS_BITS;
    if (*bitsp > maxbits)
            fatal("key bits exceeds maximum %d", maxbits);
    if (type == KEY_DSA && *bitsp != 1024)
            fatal("DSA keys must be 1024 bits");

OPENSSL_DSA_MAX_MODULUS_BITSはOpenSSLのヘッダーからの定数で、10000に定義します。したがって、最初の4行は、生成時に要求されたキーサイズが実際にキー生成プロセスで処理できることを確認します。ただし、次の2行には基本的に、「上記のテストに関係なく、キーがDSAでサイズが1024でない場合は適切」と書かれています。

これらの6行は、それ自体、そのコードを開発した人は誰でも、キーのサイズに関して完全には同意しなかったことを示しています。このコードはおそらく段階的にアセンブルされ、おそらく別の人によってアセンブルされました。 "1024"のソースは、実際のDSA標準（ "デジタル署名標準"として "DSS"と呼ばれます）、 FIPS 186-4 までたどることができます。その基準は何度か改訂されました。 DSAの最初のバージョンでは、サイズが512〜1024ビットのモジュラスを使用することが義務付けられていました（おそらく実装者のタスクを簡略化するために、64の倍数にする必要があります）。新しいバージョンでは、技術力の向上と数学的進歩を認め、1024ビット以外のサイズを禁止しました。 FIPS 186（2016年前半の4番目のリビジョン））の最新バージョンでは、係数のサイズを1024、2048、または3072ビットにすることができます。

したがって、ssh-keygen 1024ビットとは異なる係数サイズの使用を拒否します。誰かが、ある時点で、その時点で最新のFIPS 186を厳密に義務付けたバージョンを読み、誰もssh-keygen FIPS標準が修正されたとき。この壮大なプログラミング統合失調症がどのようになったかに関係なく、生の結果は、現在使用されているタイプDSAのすべてのSSHキーがほとんどではないということです。 1024ビット係数。

パズルの次のピースは Logjam攻撃 です。 Logjamは基本的に、クライアントとサーバーが弱い暗号の使用に同意すると攻撃される可能性があることを通知することについてです。これは、SSHではなく、SSL/TLSに対する攻撃です。ただし、Logjamの記事は、DHに512ビットのモジュラスを使用するためのSSL/TLS実装を（正しく）たたき落とすことに留まりません。それはまた、「国家レベルの敵対者」に話し合いの場を捧げる。その部分は、すでに知られていることを主に述べています。つまり、1024ビットのモジュロを法として離散対数を分解すること（DHとDSAの両方を分解できるようなもの）は、恐ろしく高価ですが、不可能に関して問題の現在の知識と利用可能な技術（RSA-1024の破壊と同様であり、2048ビットのDHまたはDSAの破壊とは非常に異なり、現在のEarthリソースでは実現可能ではありません）。

これはすべて、「NSA !! SSHで使用される場合に含まれる、1024ビットDSAキーの件名。

余分なポイントは、DSAを使用すると、新しいランダム値for signatureを生成する必要があり、その値の生成の品質が最も重要であることです。一部の実装は見事に失敗し、秘密鍵の漏洩を引き起こしました（特に「ビットコインウォレット」の場合）。 DSAのこの特性は、楕円曲線バージョンのECDSAと共有されます。 修正可能 。しかし、それはDSA署名が適切に行うにはトリッキーである可能性があるという考えを植え付けました（そしてECDSA署名も同様ですが、楕円曲線はクールで誰もそれらを禁止したくありません）。

これらのパラメータをまとめると、禁止が説明されます。これは、OpenSSH開発者がセキュリティの概念に積極的であり、ユーザーに強力な暗号を使用するように強制する準備ができている場合と見なすことができます。非常に同じ一連の決定を確認する別の方法は、OpenSSH開発者がFIPS 186の読み取りが不十分なために、ある時点でひどく誤解し、海での投棄と同等の方法でそれをカバーしようとしたことです。不便な夫の死体。

DSAキーを破ると、攻撃者はあなたになりすますことができますが、記録されたセッションを復号化することはできません。 ECDSAキーへの切り替えは、ある時点で良いアイデアであると言えます（帯域幅とCPUを少し節約します）が、暗号解読の緊急性はありません。そうしないと、一部のパッケージャが非推奨ポリシーに熱心すぎたためにサーバーからロックアウトされる可能性があるため、これを行う必要があります。

98
Tom Leek

https://bugzilla.mindrot.org/show_bug.cgi?id=1647 DSAキーを1024ビットに制限する背後には理由がありますが、基本的には次のとおりです。

  • RFC4253セクション6.6では、ssh-dss（つまりDSA）認証にSHA1ハッシュ（160ビット）が必要です。
  • FIPS 186-3セクション4.2では、160ビットを超えるハッシュを使用するには、1024ビットを超えるDSAキーが必要です。
  • 両方に準拠する唯一の方法は、1024ビットのキーのみを許可することです。
11
Darren Tucker