私が使用しているソフトウェアの1つ、つまり、どの暗号化方式が使用されているかを調べようとしています。 Synology NASで実行されるSynologyのDSM 6.0の「クラウド同期」機能。
(Background。このCloud Syncソフトウェアは、私のファイルのバックアップを暗号化された方法で私のクラウドストレージに保存し、ソフトウェアがそれを失った場合に備えて、安全を保つための鍵を与えました。または、ソフトウェアを最初から再インストールする必要がありますが、ソフトウェアを実行せずに自分でファイルを復号化できるようにしたいと考えています。
したがって、ここで「特定のシステムのセキュリティを破る」ことを誰かに求めているわけではありません。この特定のSynology Cloud Syncソフトウェアで暗号化された自分のデータをどのように回復できるか調べようとしています自分のパスワード/秘密キーを指定。)
私がファイル形式をリバースエンジニアリングできる限り、各ファイルは個別に暗号化され、暗号化されたファイルを除いて、他の情報は保存されません。暗号化されたファイルごとに、次のデータが保存されます。
enc_key1
:384ビット(48バイト)enc_key2
:2048ビット(256バイト)key1_hash
:42文字の文字列key2_hash
:42文字の文字列session_key_hash
:42文字の文字列42文字のハッシュ文字列はそれぞれ次のようになります。
1qxNH-CinG6f49c3ab7f3e66e35c929b06b6fc60d0
これは、base64に似たエンコードでは10文字(文字、数字、および-
のみが表示されます。これは60ビットです)で、その後に32桁の16進文字(128ビット)が続くようです。
ソフトウェアから提供されたキーは、秘密キー(.pem
)と公開キー(-----BEGIN RSA PRIVATE KEY-----
)の2つの-----BEGIN RSA PUBLIC KEY-----
ファイルで構成されています。
ここではどの暗号化アルゴリズムが使用されていますか? (そして、その奇妙な42文字のハッシュは何ですか?)
また、上記の情報を使用して元のファイルを復元するにはどうすればよいですか?
更新:役割を果たしているパスワードもあり、各ファイルは秘密鍵またはパスワードのいずれかを使用して復号化できることを発見しました。両方を持っている必要はありません。
更新2:(クローズドソース)復号化ツールがベンダーから入手できることを発見しました。
更新3:ベンダー(Synology)に連絡した後、ベンダーとソフトウェアに名前を付けるために上記の質問を更新しました。暗号化/復号化アルゴリズムisが文書化されていることを発見しましたが、それは高レベルのみです。
この暗号化/復号化アルゴリズムに関するすべての「公式」情報は、9ページの "Cloud Sync White Paper-Based on DSM 6.0" ( archive.org copy )です。 Synologyサポートを通じて受け取りました。
これは、高レベルのアルゴリズムを説明するニースの図です:
enc_key1
);public.pem
、復号化の場合はprivate.pem
)によって暗号化されます(-> enc_key2
);ただし、その他の詳細は提供されません。
私がこれまでに知っているのは、ファイル形式をデコードする方法です。enc_key1
(base64エンコード形式で保存)は、OpenSSLを使用して、CBCモードでAES-256を介して、ソルトなしで- OpenSSLの文書化されていないパスワードから鍵およびivへのアルゴリズム 、次のように:
$ echo 'f662PyjwrkzR61qSRHyBEVkXVd7STUpV6o7IrJs+m8gN1haqmBtMzLvq2/Gj134r' | openssl enc -aes256 -d -a -pass pass:'buJx9/y9fV' -nosalt
BxY2A-ouRpI8YRvmiWii5KkCF3LVN1O6
これでセッションキーが得られますが、実際のデータを復号化するためにこれを正常に使用することはできません。
私が今まで知っていることはすべてGitHubの synology-decrypt リポジトリにあります。
この質問の私の目標は、次のような詳細を理解することです。
実際にセッションキーを使用して生データを復号化するにはどうすればよいですか?私もそのために塩なしでAES-256 CBCを試しました、そしてそれは半分の読み取り可能なデータ、半分のゴミに終わります。
42文字のハッシュについてはどうですか?具体的な例として、上の例を続けて、session_key_hash
jM41by6vAd517830d42bfb52eae9b58cd41eac95b0
は、復号化されたセッションキーのハッシュBxY2A-ouRpI8YRvmiWii5KkCF3LVN1O6
?)です。
Update 4:情勢に興味がある人のために、ハッシュのタイプ(10バイト/文字のランダムソルトとそれに続くMD5ソルト+データ);アルゴリズムはソルトなしのCBCモードのAES-256です。そして、データはLZ4を使用して圧縮されます(一部の部分は圧縮されずに残り、上記の部分的な復号化の成功を説明します)。
Saltを追加した最新のフォーマット変更の詳細については、 https://github.com/marnix/synology-decrypt を参照してください。
あなたのアップデートは役に立ちますが、それでもまだうまくいきません。ソフトウェアが安全を確保するために提供したキーはRSAのパブリック/プライベートペアであり、セッションキーが関係していることを知っています。通常、データの実際の暗号化を行う高速対称アルゴリズムを選択し、そのアルゴリズムに適したセッションキーと呼ばれるキーをランダムに生成し、RSA公開キーを使用してセッションキーを暗号化し、暗号化されたセッションキーを一緒に保存します。ほかのすべて。
あなたのケースでは、セッションキーは2回暗号化されて保存されます。1つはRSAアルゴリズムとRSA公開キー、もう1つは他のアルゴリズムとKDFを介してパスワードから派生したキーです。ソフトウェアが適切なパスワードやRSAキー、あるいはその両方を指定したかどうかをソフトウェアが簡単に判別できるように、セッションキーのハッシュコードが含まれています。
適合しないことの1つは、ソフトウェアがセッションキーの暗号化を解除する前の冗長チェックでない限り、key1hashとkey2hashの目的を説明しないことです。
あなたが知らない大きなことは、データの実際の暗号化にどのアルゴリズムが使用されているかです。それがブロック暗号である場合、パディングスキームやモードもわかりません。 CBCモードの場合、IVもわかりません。関連するアルゴリズムとその呼び出し方法を特定するには、ソフトウェアを逆コンパイルするか、デバッガーの下で実行するか、ソフトウェアの古さに基づいてラッキーな推測を行い、最新の技術に関する調査を行う必要があります。 (または少なくとも一般的に使用される)ソフトウェアが作成されたとき。
推測では、ハッシュコードはおそらくMD5で、128ビットを生成します。 MD5は壊れていると見なされますが、上記のセキュリティはそれに依存しないため、上記の使用法には十分な可能性があります。 (ただし、どのkey1hashが使用されているか、およびKDFの詳細によっては、ユーザーが選択したパスワードと組み合わせたMD5の使用は非常に弱点になる可能性があります。)
ハッシュ文字列の最初の10文字については、3つのハッシュ間、およびファイル間でどのように変化するかを確認したい場合があります。それらが類似している場合、それらはおそらくフラグです。それらがランダムに見える場合、それらはハッシュのソルトまたは(あまりプライベートではない)HMAC-MD5のプライベートキーである可能性があります。
あなたはRSA秘密鍵を持っているので、それを使用してenc_key2を復号化し、それがビットの束を与えて、対称暗号鍵になる適切な長さを与えることを確認することをお勧めします。