問題タブ [cng]

私は CNG ECDH を実装する処理を行っており、BCRYPT_KDF_SP80056A_CONCAT KDF を使用して対称 AES256 キー (BCryptDeriveKey()) を導出しようとしています。問題が発生しています (常に 0xc000000d ステータスが返されます)。

共有シークレットを正常に生成し、1 つの AlgorithmID、1 つの PartyU および 1 つの PartyV の「その他の情報」を含む「BCryptBuffer」の配列を持つバッファー記述子「BCryptBufferDesc」を作成しました。構造がすべて適切に定義され、設定されていると思います。私は PartyU と PartyV バイトのいくつかの「値」を選んでいます (それぞれに 1 バイトと 16 バイトを試しましたが、同じ結果が得られました)。NIST のドキュメントには、他の情報がどうあるべきかについての詳細は記載されていません。

文字列や定義などを使用して、これらの構造を作成するために Microsoft の Web サイトに従いました。標準の L"HASH" kdf を試してみたところ、機能し、両方の「側」で同じ派生キーを取得しましたが、連結KDF 私はいつも同じ 0xC000000D ステータスを返します..

他の誰かが BCRYPT_KDF_SP80056A_CONCAT CNG KDF を正常に使用できましたか? もしそうなら、何かヒントはありますか？

BCryptGetFipsAlgorithmMode()TRUE を返すか FALSEを返すかを決定する要因を見つけるのに苦労しています。次のステータスを返すだけですか？

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled

それとも何か他のものですか？

MS CNG と別のデバイスの間で ECDH キー交換を実行しようとしています。物事をデバッグするために、CNG で生成されている共有シークレットを確認して、他のデバイスで生成されたシークレットと比較できるようにしたいと考えています。これを行う方法を知っている人はいますか？

私はメッセージと署名を送信するための非常に限られたチャネルを持っており、示されています（https://crypto.stackexchange.com/questions/3075/asymmetric-algorithm-to-generate-compact-unique-messages-that -検証可能/）ECDSAが最もコンパクトな非対称アルゴリズムを提供します。

私はこれをかなり簡単に次のように進めています：

しかし、ある程度の強度を犠牲にして、BCLが提供する最小の256ビットキーサイズ未満を使用できるようにしたいのですが、必要なことを実行する実装が見つかりませんでした。

BouncyCastleを試しましたが、箱から出してすぐに同じ制限があるようです。

私のオプションは何ですか？実装の制限を解除する別の実装はありますか？

カスタム Microsoft P160 PlayReady 曲線が HSM にフィードされるように、適切に DER でエンコードされた ECC パラメーターを作成しようとしています。P160 曲線は非標準でカスタムであるため、P160 曲線の定義を指定するソースをいくつか見つけました。以下は、1 つのソースへのリンクです。特に、PlayReady 曲線の値については、ウィリアム スタイン著『Elementary Number Theory,A Computational Approach』のセクション 6.4.2 で説明されています。

以下は、P160 PlayReady 曲線パラメーターに関する別の情報源からの影響です。

ECC の場合、Microsoft は Zp 上の楕円曲線を使用しています。ここで、p は 160 ビットの素数です (以下を参照)。曲線は、曲線 y^2=x^3+ax+b 上の点で構成されます。ここで、操作はフィールド Zp に対して行われ、a と b は以下に示す係数です。すべての値は、パックされたバイナリ値として表されます。つまり、Zp を超える単一の値は、単純に 20 バイトとしてエンコードされ、リトル エンディアン順に格納されます。したがって、楕円曲線上の点は 40 バイトのブロックであり、2 つの 20 バイトのリトルエンディアン値 (x 座標の後に y 座標が続く) で構成されます。MS-DRM で使用される楕円曲線のパラメーターは 次の

とおり です。

coefficient b : 0dd8dabf725e2f3228e85f1ad78fdedf9328239e
generator x : 8723947fd6a3a1e53510c07dba38daf0109fa120
*generator y : 445744911075522d8c3c5856d4ed7acda379936f
Order of curve : 89abcdef012345672716b26eec14904428c2a675

These constants are fixed, and used by all parties in the MS-DRM system. この数値を 16 進数で表示すると、モジュラスの「オタクの魅力」が高まります。基本定数 e、pi、および sqrt(2) の数字だけでなく、16 進数でのカウントも含まれます。

この情報に基づいて、基本 ASN.1 ライブラリとして BouncyCastle を使用して、P160 曲線の DER エンコード曲線パラメーターの次の 16 進エンコードを作成しました。これらの曲線パラメータにはシード値が指定されていないことに注意してください。

308195020101302006072a8648ce3d010102150089abcdef012345672718281831415926141424f7302c041437a5abccd277bce87632ff3d4780c009ebe4149704140dd8dabf725e2f3228e85f1ad78fdedf9328239e0429048723947fd6a3a1e53510c07dba38daf0109fa120445744911075522d8c3c5856d4ed7acda379936f02150089abcdef012345672716b26eec14904428c2a675

数学的には、これらの曲線パラメーターは HSM と OpenSSL によって受け入れられますが、生成された P160 曲線ポイントは PlayReady には受け入れられません。同じプロセスを使用して、PlayReady に受け入れられる有効な P256 カーブ ポイントを生成できるので、私の方法に欠陥があるとは思いません。PlayReady P160 の曲線パラメーターを使用した経験のある人はいますか?

NCryptOpenKey()キー名パラメーターとして証明書の拇印を呼び出して使用することにより、CNG (Windows Cryptography API Next Generation) キー ハンドルを作成しようとしています。

この keyName を使用するとキーが見つかりませんが、certmgr.msc で調べると、その拇印で証明書を確認できます (" <code>e0 f5 df 72 7f 81 92 fa ae 8a 4b f1 d5 53 c1 be 40 18 90 dc")。ここで何が問題になる可能性がありますか？

編集：私が本質的にやりたいことは（スタックオーバーフローの人々の助けによってわかったように;））、Windows証明書ストアに保存されている証明書からNCRYPT_KEY_HANDLEを作成することです。

PowerShell スクリプトから秘密鍵のアクセス許可を付与する方法を見つけようとしています。証明書は CNG に保存されます。すべてのアイデアを歓迎します。

CLR セキュリティ ライブラリ Security.Cryptography.dll (ホームページ: http://clrsecurity.codeplex.com )を使用して自己署名証明書を作成しようとしています。

証明書を作成し、それを使用して暗号化することもできますが、「指定されたプロバイダーの種類が無効です」というエラーで復号化に失敗します。

証明書作成コードは次のとおりです。

暗号化方法は次のとおりです。

Decrypt メソッドは次のとおりです。

makecert.exe で作成した証明書とまったく同じコードを使用すると、うまく機能します。私が使用するmakecertコマンドラインは次のとおりです。makecert.exe -sr LocalMachine -ss My -n CN=[SomeDN] -sk [SomeRandomGUID] -sky exchange

CngKey または証明書の作成時に追加のパラメーターを指定する必要がありますか? それとも、暗号化中に追加情報を渡しますか?

助けてくれてありがとう！