5

I'm trying to find out which encryption method is used by a piece of software I use, viz. the 'Cloud Sync' feature of Synology's DSM 6.0 running on a Synology NAS.

(Background. This Cloud Sync software stores a backup of my files for me in some cloud storage of mine in an encrypted way, and it gave me a key to keep safe, in case the software loses it, or I have to reinstall the software from scratch. Now, I'd like to be able to decrypt my files myself, without requiring the software to be running.

So I'm not asking anyone to "break the security of a specific system" here; I'm trying to find out how I can recover my own data that was encrypted by this specific Synology Cloud Sync software, given my own password / private key.)

As far as I've been able to reverse engineer the file format, each file is encrypted separately, and apart from the encrypted files no other information is stored. For each encrypted file the following data is stored:

  • a list of bytes, presumably the encrypted data, very likely compressed before or after encryption
  • enc_key1: 384 bits (48 bytes)
  • enc_key2: 2048 bits (256 bytes)
  • key1_hash: a 42-character string
  • key2_hash: a 42-character string
  • session_key_hash: a 42-character string

Each of the 42-character hash strings looks like this:

1qxNH-CinG6f49c3ab7f3e66e35c929b06b6fc60d0

This seems to be 10 characters in some base64-like encoding (I see only letters, digits, and -; this would be 60 bits), followed by 32 hex characters (128 bits).

The key the software gave me consists of two .pem files, a private key (-----BEGIN RSA PRIVATE KEY-----) and a public key (-----BEGIN RSA PUBLIC KEY-----).

What encryption algorithm is used here? (And what's that weird 42-character hash?)

And how could I use the above information to restore the original file?

Update: Just discovered that there also is a password that plays a role, and each file can be decrypted using either the private key or the password; no need to have both.

Update 2: I just discovered that a (closed source) decryption tool is available from the vendor.

Update 3: Updated the above question to name the vendor and the software, after having having contacted the vendor (Synology). I discovered that the encryption/decryption algorithm is documented, but only on a high level.

All 'official' information about this encryption/decryption algorithm is on page 9 of "Cloud Sync White Paper -- Based on DSM 6.0" (archive.org copy) which I received through Synology Support.

This has a nice diagram explaining the high level algorithm:

  • a random 32-byte session key is generated;
  • the original file contents is encrypted using the session key;
  • the session key is encrypted through the "user-defined primary key" (= the password) through AES-256 (-> enc_key1);
  • the session key is also encrypted through a "randomly-generated key pair" (= public.pem for encryption, and private.pem for decryption) (-> enc_key2);
  • except for the session key itself, all of the above (and more) is stored in the encrypted file.

However, no other details are provided.

What I know so far is how to decode the file format, and that enc_key1 (which is stored in base64-encoded form) can be decrypted using OpenSSL through AES-256 in CBC mode, without a salt, using OpenSSL's undocumented password-to-key-and-iv algorithm, as follows:

$ echo 'f662PyjwrkzR61qSRHyBEVkXVd7STUpV6o7IrJs+m8gN1haqmBtMzLvq2/Gj134r' | openssl enc -aes256 -d -a -pass pass:'buJx9/y9fV' -nosalt
BxY2A-ouRpI8YRvmiWii5KkCF3LVN1O6

So that gives me the session key-- but I have not yet been able to use it successfully to decrypt the actual data.

Everything I know until now is now on GitHub in the synology-decrypt repository.

My goal for this question is to get at the full details, like:

  • How to actually use the session key to decrypt the raw data? I've tried AES-256 CBC without salt for that as well, and that results in half readable data, half garbage.

  • What about the 42-character hashes? As a specific example, continuing on the example above, how is session_key_hash jM41by6vAd517830d42bfb52eae9b58cd41eac95b0 the hash of the decrypted session key BxY2A-ouRpI8YRvmiWii5KkCF3LVN1O6?)

Update 4: For anyone curious about the state of affairs, I found out the type of hash (a 10 byte/character random salt followed by the MD5 of salt + data); the algorithm is AES-256 in CBC mode without salt; and the data is compressed using LZ4 (which leaves some parts uncompressed, explaining the above partial decryption success).

For further updates on the latest format change which added salt, see https://github.com/marnix/synology-decrypt.

MarnixKlooster ReinstateMonica
  • 259
  • 4
  • 11
  • 1
    `compressed before or after` compression is almost always done before encryption ... doing it after is pretty much useless – CaffeineAddiction Jun 01 '16 at 20:45
  • looks like rsa and aes and some mac/signatures... – dandavis Jun 01 '16 at 21:19
  • @CaffeineAddiction Of course, should've thought of that: if the encrypted data can be compressed then it isn't encrypted really well... – MarnixKlooster ReinstateMonica Jun 01 '16 at 22:17
  • @dandavis What aspect makes you think of AES? Any little detail helps. :-) – MarnixKlooster ReinstateMonica Jun 01 '16 at 22:18
  • 1
    Is the software publicly available? It might help if we had access to the software or could do further research on it if we knew the product we were dealing with. – Bacon Brad Jun 01 '16 at 23:22
  • guessing. a session key that's not an RSA key, most file encryption is symmetric, and most symmetric is aes. that a password can do the same as a rsa private key also suggests that both protect a symmetric key, and (less directly) that "hash" is possibly a misnomer and could contain a IV and key, or it could be a harmless sequence number... – dandavis Jun 02 '16 at 03:32
  • @baconface I just discovered that there is a decryption tool, and that it is publicly available from the vendor's website (platform-specific binaries only, no source code or license info in sight). However, I'm first asking the vendor for details about the algorithm, and if that does not help I'll update this question with vendor and product names and links. – MarnixKlooster ReinstateMonica Jun 02 '16 at 06:37
  • @Xander et al.: I've tried to clarify in my question that this is not a matter of breaking encryption of a system, but about knowing the details of an encryption algorithm, so that I can decrypt my own data _when I know my password / private key_. So I don't agree with the "break the security" close reason. Can this question please be reopened? – MarnixKlooster ReinstateMonica Jun 11 '16 at 08:47
  • @baconface The decryption tool is 'Synology Cloud Sync Decryption Tool'. It can be obtained through the Synology Support Download Center at https://www.synology.com/en-us/support/download/, then choose a NAS that offers Cloud Sync (many of them, e.g., DS110j). – MarnixKlooster ReinstateMonica Jun 11 '16 at 08:51
  • 1
    We only have a small range of close options, which is why that one was chosen. It is not on topic here as you'd really need to speak to the vendor and get them to tell you. – Rory Alsop Jun 11 '16 at 17:47

1 Answers1

2

Your update helps, but the pieces still don't quite fit. You know that the key the software gave you to keep safe is an RSA public/private pair, and you know a session key is involved. The usual practice is to choose a fast symmetric algorithm to do the actual encryption of the data, randomly generate a key suitable for that algorithm called the session key, encrypt the session key using the RSA public key, and store the encrypted session key along with everything else.

In your case, the session key is encrypted and stored twice: once with the RSA algorithm and the RSA public key, and once with some other algorithm and a key derived from the password via some KDF. To make it easy for the software to figure out if you gave it the right password and/or the right RSA key, they include a hash code of the session key.

One of the things that doesn't fit is that this doesn't explain what key1hash and key2hash are for, unless they're a redundant check before the software attempts to decrypt the session key.

The big thing you don't know is what algorithm is used for the actual encryption of the data; if it is a block cipher you also don't know the padding scheme or mode; and if CBC mode you also don't know the IV. To determine the algorithms involved, and how they're being called, you either need to decompile the software or run it under a debugger, or make some lucky guesses based on the age of the software and some research about what was state of the art (or at least commonly used) when the software was written.

At a guess, the hash codes are probably MD5, which produces 128 bits. MD5 is considered broken but might good enough for the usage described above, since the security of the above doesn't depend on it. (However, depending on what key1hash is being used for, and depending on the details of the KDF, the use of MD5 combined with a user-chosen password might very well be a weakness.)

As for the first ten characters of the hash string, you might want to look at how they vary among the three hashes, and from file to file. If they're similar they're probably flags; if they look random they could be salt for the hashes or (not very private) private keys for an HMAC-MD5.

Since you have an RSA private key, I suggest using it to decrypt enc_key2 and see that if that gives you a bunch of bits the right length to be a symmetric cipher key.

gatkin
  • 666
  • 5
  • 3