問題タブ [symmetric-key]

私の会社は、顧客のために機密データを保存し、マネージ .NET 暗号化アルゴリズム クラスの 1 つを使用してデータを暗号化する予定です。ほとんどの作業は完了しましたが、鍵を保管する方法/場所がわかりません。簡単な検索と読み取りを行ったところ、ハードウェア ソリューションが最も安全なようです。キーストレージのソリューションまたは方法に関する推奨事項はありますか?

---

皆様、ご回答ありがとうございます。

スポールソン、問題は実際にはあなたが言及した両方の「スコープ」です。もっとはっきり言うべきだったと思います。

データ自体と、データを暗号化および復号化するロジックは、ASP.NET プロファイル プロバイダーに抽象化されます。このプロファイル プロバイダーは、暗号化されたプロファイル プロパティとプレーン テキストのプロファイル プロパティの両方を許可します。暗号化されたプロパティ値は、暗号化されているという明白な例外を除いて、プレーン テキストのものとまったく同じ方法で保存されます。

とはいえ、鍵は次の 3 つの理由のいずれかで召喚できる必要があります。

1. 承認されたサーバー上で実行される承認された Web アプリケーションは、データを暗号化する必要があります。
2. #1 と同じですが、データを復号化します。
3. ビジネス チームの承認されたメンバーは、暗号化されたデータを表示する必要があります。

私が想像しているのは、実際には誰もキーを知らないということです。データの実際の暗号化と復号化を制御するソフトウェアが存在するでしょう。とはいえ、鍵はどこかから来る必要があります。

完全な開示 - まだわからない場合は、これまでにこのようなことをしたことがないので、これがどのように機能するかについての私の認識が完全にずれている場合は、ぜひお知らせください.

暗号化された DB (対称キー/証明書) をバックアップし、別のサーバーに復元しました。

残念ながら、復号化に問題があります...誰かが助けてくれることを願っています.

復元されたデータベースでは、SSMS で対称キーと証明書を確認できますが、証明書を使用してキーを開こうとすると (証明書 CertB による対称キー KeyA 復号化を開く)、次の非常にわかりやすいエラーが表示されます。

メッセージ 15466、レベル 16、状態 1、行 1 復号化中にエラーが発生しました。

何か案は？

前もって感謝します。

DES 暗号化を使用しており、TripleDESCryptoServiceProvider のキーを保存したいと考えています。

しかし、キーは (キー + IV) で構成され、

を使用してXMLファイルに保存しようとしていました

しかし、IV に無効な文字 "=" が XML に含まれているため、例外が発生しました。

対称暗号化キーを保存するより良い方法はありますか?

一部のデータを暗号化するためにpyDesを使用しています。キーや初期値を 1 ビットでも変更すると、暗号化されたデータがまったく異なるものになることを実証したかったのです。最後の文字を +/- 1 だけ変更するように 16 バイトのキーを設定しました。これにより、少なくとも 1 ビットが異なることになります。ただし、それを行っても、暗号化されたデータの 3 つの異なるインスタンスがすべて異なるわけではありません。

キーまたは初期値のいずれかを少し変更しただけでは、アサーションの 1 つが失敗するようです。私は両方を見てきd1 != d2ましd1 != d3たが、変更内容によっては失敗します。また、入力データが短すぎるだけではないことを確認するために、に変更しようとし'Hello'ました。'Hello' * 50

完全にランダムなキーを作成すると、アサーションはパスします。上記のプログラムでは、d1 != d3失敗します (これらのキーは 1 ビット離れており、k1-k2 は 2 ビット異なります)。

私は決して暗号化の専門家ではありませんが、1 ビットしか離れていない 2 つのキーが同じ暗号化されたデータになる場合、それは、キーをブルート フォースするために必要な労力が 2 分の 1 になったことを意味します。

明らかな何かが欠けていますか？トリプル DES は、非常によく似たキーに対して一意の結果を与えることは想定されていませんか? それとも、これは PyDes のバグですか? 他の誰かが別の実装でこの動作を確認できるでしょうか?

---

@Chris Jester-Young は、キーの一部のビットがパリティ ビットであるという回答を持っていました。そして、結局のところ、この記事によると：

DES の入力キーの長さは 64 ビットですが、DES で使用される実際のキーの長さはわずか 56 ビットであることに注意してください。各バイトの最下位 (右端) ビットはパリティ ビットであり、すべてのバイトに奇数個の 1 が常に存在するように設定する必要があります。これらのパリティ ビットは無視されるため、各バイトの最上位 7 ビットのみが使用されるため、キーの長さは 56 ビットになります。これは、トリプル DES の有効なキー強度が実際には 168 ビットであることを意味します。これは、3 つのキーのそれぞれに、暗号化プロセス中に使用されない 8 つのパリティ ビットが含まれているためです。

（強調は私のものでした）

そして、これらのパリティ ビットは、まさにこの例で変更していたビットです。

ありがとうクリス！

データを暗号化してファイルに保存し、後で復号化できるようにする必要があります。このために、RijndaelManaged クラスを使用しています。ここで、キーをコードにハードコーディングしたくありません。いくつかのグーグルの後、私はこの方法を見つけました-

ここでキーが生成されますが、パスフレーズ、ソルト、IV などの他のすべての値はハードコーディングされます。ユーザーにパスワードを入力させるオプションがないため、これらの値もハードコーディングする必要があります。それで、これは本当に安全ですか？一部のハッカーはツールを使用して、これらのハードコードされた値を見つけてキーを見つけ出すことはできませんか?

対称キーを使用して SQL Server のデータを暗号化しようとしています。ユーザーが Web フォームからデータを送信するときに、SQL Server 内に保存した対称キーを使用してデータを暗号化したいと考えています。これを行う方法を見つけようとしています。現在、私は以下を実行しています：

これはうまく機能しますが、Web.Config ファイルからキーを開こうとすると、エラーが発生します。

C# コード:

Web.Config ファイル

try/catch ステートメントからのエラー:

エラー番号: 102、エラー メッセージ: 'myKey' 付近の構文が正しくありません。: -2146232060 および System.Data.SqlClient.SqlErrorCollection

質問/問題:

• エラーが発生するのはなぜですか?
• キーにアクセスしたり、データを暗号化する別の方法はありますか?

追加:キー名を「myKey」から「myKeya」などに変更しようとしたところ、次のエラーが発生しました。

エラー番号: 15151、エラー メッセージ: 対称キー 'myKeya' が見つかりません。存在しないか、権限がないためです。: -2146232060 および System.Data.SqlClient.SqlErrorCollection

当然、「myKey」とは別の単語を使用していますが、使用している単語が何らかのキーワードであるかどうかを確認したところ、Google、bing、msdn の検索で出てきません...だから私は私はそこで安全だと思います。また、これは、データベースが実際にリクエストを受信して​​いるという点で私に手がかりを与えますが、別の方法でキーが必要です。うーん....

これまで、PCI コンプライアンスに対処する必要はありませんでした。文書を読んだところ、クレジット カード番号、有効期限、およびカード所有者の名前を保護する必要があると書かれています。セキュリティコードの保存はありません。

彼らのドキュメントでは、保護とだけ書かれています。これは、データベース内のこれら 3 つの列を暗号化する必要があるということですか? 暗号化する必要があるデータは数字だけだと思いました。いずれにせよ、私は大丈夫です。

3 つの列すべてを暗号化する必要がある場合、1 つの証明書を共有して 3 つの対称キーを使用する必要がありますか?それとも、3 つの列すべてで使用されている対称キーを使用して、それぞれ 1 つだけ必要ですか? 私が尋ねる理由は、列の暗号化に関する BoL ドキュメントにあります。キーは、暗号化する列にちなんで名付けられています。

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

対称キーを持つデータベースを持つサーバーがあります (データベース -> セキュリティ -> 対称キー)。テストデータベースとして使用しているバックアップの複製データベースがありますが、そこにはこのキーがありません。

この対称キーを複製して (または古いものとまったく同じように新しいものを作成して)、既存のデータベースに配置するにはどうすればよいですか? 他のものと同じ値とキー名を持つ必要があります。

これは SQL Server 2008 上にあります。

私は暗号アルゴリズムを学び始めており、上記のアルゴリズムがどのように機能するかを理解しています。AESの鍵長が長いということですか？AES 暗号化のどの手順で DES よりも脆弱性が低くなりますか?

暗号化のテキストには、対称アルゴリズムに対するブルートフォース攻撃では、試行の半分の後にキーが見つかる可能性が50％あると記載されています。

^{たとえば、56ビットキーを使用するDESは、最初の2 55}回の試行後にキーを見つける可能性が50％になります。

対称暗号化アルゴリズムに対するブルートフォース攻撃で、試行の半分の後にキーが見つかる可能性が50％あるのはなぜですか？それの数学的証明は何ですか？