2016-11-16 1 views
0

を生成します。SQL Serverの:BACKUPのマスターキーが異なる出力私は新しいDB上でこれを実行するたびに

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '27c381e5-27cf-483f-81bf-143845911a5f'; 

BACKUP MASTER KEY TO FILE = 'c:\temp\key1.key' 
ENCRYPTION BY PASSWORD = '27c381e5-27cf-483f-81bf-143845911a5f' 

BACKUP MASTER KEY TO FILE = 'c:\temp\key2.key' 
ENCRYPTION BY PASSWORD = '27c381e5-27cf-483f-81bf-143845911a5f' 

はしかし、バックアップが異なります。

C:\Windows\system32>type c:\temp\key1.key | md5sum 
702f95c38ea9b740ebaa7e186b9c12ec *- 

C:\Windows\system32>type c:\temp\key2.key | md5sum 
31906913d9d7c15fc1ba90a9635fee52 *- 

は、私も、六角ダンプをしましたファイルは遠隔的には似ていません。

誰かがこの現象を説明できますか?私はバックアップと復元をしようとしています。このプロセスがどのように機能するのかわかりません。リストアが失敗しているので、バックアップで何が起きているのか把握できないようです。

+0

DMK復元中にエラーが発生しました... –

+0

復元していません。キーが機能しない場合、NULLを取得します。私はそれが元の質問であるキーと内容が変更されていないときでも、バックアップデータが異なるためだと思います。バックアップの奇妙さを説明できるようになるまで、復元をデバッグできません。何か案が? –

+0

私は確認できませんが、ほとんどの暗号化アルゴリズムでは、虹のテーブル型攻撃から保護するために塩を使用しています。あなたはここにそれを実行している可能性があります。 –

答えて

1

TL; DR:

暗号文は、各暗号化に異なるようにするためにそれは他のすべてのものが等しい場合、正常です。パスワードの推測を簡単にしないために、これは出力の意図的な「ランダム化」と考えています。ただし、署名は常に同じです。

DMKバックアップファイルの内容を並べて見ると、最初の40〜60バイトがほぼ同じ構造(同じ量の例えば、同じ場所のスペース)。いくつかのデータだけが異なります。これは、とりわけ塩が存在するヘッダーです。塩は隠される必要はありません。それはランダムである必要があります。


ここで、何らかの理由で、知られていない復元中に表示されるエラーについて教えてください。私はテスト環境と2つのDMKバックアップを作成しました。また、物事はもう少し現実的にするために、私は、暗号化パスワードを指定せずに証明書を作成しました:

create certificate [TestCert] authorization [dbo] 
    with subject = 'DMK Restore Test certificate'; 

これは、証明書の秘密鍵がDMKを使用して暗号化されることを意味し、今我々はいくつかの暗号化を持っていますデータ。私はその最初のバックアップからDMKを復元しようとした場合:

restore master key from file = 'D:\Tests\Key1.dmk' 
    decryption by password = 'asdfdgkjh98hvio' 
    encryption by password = 'nmbneknfownoih'; 

SSMS(あなたがいないエラー、心の)次のメッセージを出力します

古いものと新しいマスターキーが同じです。データの再暗号化は不要です。

デフォルトの動作で、違いは検出されないため、キーは現在開いています。私達の証明書を使って署名を作成しようとすると、DMK(証明書の秘密鍵)で暗号化されたデータがアクセス可能であることを証明している:

select signbycert(cert_id('TestCert'), 'ASDfgh'); 

(あなたが上記のためのいくつかのvarbinary(128)出力が表示されます)。私はあなたがデータベースのバックアップを復元するときの一般的なシナリオである、masterからそのコピーを削除することで、キーの自動開放をオフにした場合 しかし、:その後、

alter master key drop encryption by service master key; 

と同じrestore master keyステートメントを使用して復元しよう上記、確かに、エラーが発生します。

メッセージ15329、レベル16、状態30、行1

現在のマスターキーを解読することはできません。これがデータベース マスターキーの場合は、この操作を実行する前にセッションで開こうとしてください。 FORCEオプションを使用すると、この エラーを無視して操作を続行できますが、古い マスターキーで暗号化されたデータは失われます。

キー(既存のものと復元されているもの)は同じですが、今回はSQL Serverはそれを見ることができません - DMKは閉じています。証明書を使用して署名しようとすると、同じ理由でNULLが返されます。 FORCEオプションの説明に注意してください。私はそれを追加した場合:現在のマスターキーが解読することはできません

restore master key from file = 'D:\Tests\Key1.dmk' 
    decryption by password = 'asdfdgkjh98hvio' 
    encryption by password = 'nmbneknfownoih' 
    force; 

結果は、単なる情報メッセージ、再び、です。 FORCEオプションが指定されているため、エラーは無視されました 。

唯一のものは戻ってデータを取得するために左に明示的DMKを開く、または上の自動開放を引き返すことです:、証明書署名が再び機能し始めその後

open master key decryption by password = 'nmbneknfownoih'; 
go 
-- And if you need it to be always available in the future 
alter master key add encryption by service master key; 
go 

(と最初と同じバイナリデータを返します)。

+0

それを築いてくれてありがとう、Roger。繰り返し暗号化されるかもしれませんが、バックアップ(読み込み:必ずしも互いの知識がないシステム間でのデータの一回の暗号化)*が具体的に*塩漬けされないことが期待されます。私はその種のデータが塩漬けされたことを見たことはありません。私たちが別の場所に復元している場合、バックアップはどのようにランダムに塩漬けできますか?それはどのように機能するのですか? –

+0

それは私が見ているエラーを隠しているわけではありません。MSSQLの暗号化に慣れていない人として、私はこの機能に精通していない他の人を目撃しました。骨折した監督になりがちです)、いくつかの基本的なステートメントを使用してキーをバックアップしてから復元してください。彼がこれをした後、我々はテーブルから選択し、我々の値はNULLとして提示されていた。私はキーの非対称性に気づいた。私たちはステップを逃しているので、私はウォークスルーを感謝します。 **これは最初に開かれる鍵を要求しただけかもしれませんか?** –

+0

@DustinOpreaは、説明した点を明確にするための説明を追加しました。 –

関連する問題