Info Synology NAS Encryption: Forensic Analysis of Synology NAS Devices by Elcomsoft

[jeyare]

for all users, who use Encrypted Shared Folders must read this article, mandatory
I will start with conclusion from guys, who break the wall:

In this article, you can find no out of the box “we have a tool for that” type of solutions. We demonstrated vulnerabilities in some of the most commonly used hardware-backed implementations of encryption used by major manufacturers of attached storage devices for consumers. As we demonstrated, relying on built-in encryption in network-attached devices manufactured by Synology may leave information vulnerable depending on whether or not the key is stored in the built-in Key Manager.

more here

 

[Rusty]

Well luckily, the key is not stored in the Key Manager...

 

[jeyare]

Lesson learned for those, who use encryption for shared folder(s):

1. Encryption is efficient only when you have Key Store location on an external device (USB).

2. Key Store location must be mounted when you need your Shared folder for an operation (internal, external data availability). Then if you don’t have attached the external device with encryption Key, you can’t use your Shared folder. Think about the external device:
- if you store the key here, backup it to another place. It will prevent your mental health when you will lose, damage or whatever will happen with your external device
- the backup place must be useful and safe for you, otherwise it’s pointless

3. Passphrase
Don’t be lazy. Use tool like Bitwarden (in Docker) or similar for really strong passphrase secure store:
- more than 35 characters mixed with all possible special symbols
- use the tool with more than single device (for off line usage), when you operate it by Docker in your NAS and you need ASAP your passphrase. This is a kind of prevention when your primary device for off line Bitwarden stored data is out of order.

Any suggestions?

 

[Rusty]

agreed

 

[jeyare]

Of course, include 2FA in BW

 

[Rusty]

Of course, include 2FA in BW

Didn't think about that. That on by default for me, but good point.

 

[jeyare]

author of the blog from Elcomsoft is already invited here to open a discussion about the topic

 

[Oleg Afonin]

Hi guys! Thank you for the invitation. I am the author of the article being discussed here. I'm still not done with my research. My intention is to figure out the details (e.g. the physical location where the encryption key is stored, as well as the location of the wrapping passphrase once the key is stored on a USB device). I am also planning to describe steps to extract, unwrap and use those bits and pieces together to decrypt a "cold" disk based on the available information.

When I'm all done here, I'll move on to QNAP (already have one; they're using a different encryption method and a different approach to key storage, which, at least at this point, seems less secure than what we have in Synology devices).

 

[jeyare]

Thx Oleg, for your fast response to my invitation
How you is your perception to use Bitwarden like tools for a heavy passphrase level of security for an USB Key store approach?
As you can see here many of us is running self hosted Bitwarden in our NASes (Docker based container)

 

[Oleg Afonin]

Honestly, I haven't looked into Bitwarden (yet) since it's add-on software (not preinstalled on Synology NAS). I'll have a look though!

 

[Micky]

So, when storing the keys on a e.g. memory stick, I'm save at least as long as I keep the stick with me., right?

OTH, this means, on each reboot I've to plugin the stick again for decryption of the folders and afterwards I can unmount the stick and put it to a safe place.

And what about backups? Are backups are encrypted, too - think so otherwise this would be a security flaw.

Another question regarding backups: Restoring a backup to a new or old Synology. Will I be able to decrypt the content to get back its original content?

Michael

 

[Oleg Afonin]

So, when storing the keys on a e.g. memory stick, I'm safe at least as long as I keep the stick with me., right?

I need a bit of a research on this (and I have that planned). From what I've seen, the encryption key stored on a USB device is wrapped with a user-provided passphrase. That's fine; in an ideal world, this would mean that one would need all three of (hard drive), (USB stick) and (user-provided wrapping passphrase) in order to unlock the encrypted folder.

However, from what I've seen, DSM allows automatically mounting encrypted folders on boot even if you store the encryption key on a USB stick and enter your own wrapping passphrase. This, in turn, would mean that the wrapping passphrase (not just the hash but the actual passphrase) is stored somewhere on the HDD; otherwise, DSM would be unable to mount such folders automatically on boot.

Whether or not the wrapping passphrase is stored on the HDD if you are NOT using the "automatically mount" feature is subject to future research. Technically, it shouldn't be there, but I wouldn't place my bets on it.

 

[Oleg Afonin]

And what about backups? Are backups are encrypted, too - think so otherwise this would be a security flaw.

It depends on "what backup". If you're using HyperBackup, then you can also use encryption (the encryption key will be saved on the HDD). If you're using rsync (or the USB Copy plugin from the repository), then there is no official way to make encrypted backups. I already finished researching this issue, and discovered that there IS a way to make an encrypted backup if you like.

Since DSM uses eCryptFS, which is a FUSE file system, there's also the "real" folder somewhere on the HDD that contains encrypted files and folders. DSM does not allow accessing that folder from the GUI; however, you can easily add a scheduled backup job such as this. Assuming that your encrypted share is named "Encrypted":

rsync -avz -delete --omit-dir-times --no-perms --no-t /volume1/@Encrypted@ /volumeUSB2/usbshare2-2/ECRYPTFS_Encrypted

Of course, you're free use rsync options to your liking. ("ECRYPTFS_Encrypted" can be any folder on the USB drive, obviously; DSM uses @<foldername>@ to identify encrypted folders).

This command will create an encrypted backup on your external USB media. THIS WILL BE SECURE (at least as secure as your encryption passphrase) as neither the key nor the passphrase are stored on that USB drive. The best thing is, you can easily take that hard drive and mount the backup in any Linux distribution, as long as it supports eCryptFS, by simply using your existing encryption passphrase.

 

[Oleg Afonin]

Another question regarding backups: Restoring a backup to a new or old Synology. Will I be able to decrypt the content to get back its original content?

If you make backups using the method I described above, you then must follow these steps to restore on another Synology.

1. Create an encrypted shared folder using the same encryption passphrase as in your old unit and the backup.
2. Lock the folder from DSM.
3. Restore the encrypted backup to @<name_of_share>@ folder using the reverse of the rsync command you used to create the backup.
4. Unlock the share from DSM using your encryption passphrase.

 

[jeyare]

@Oleg Afonin
how was feedback from Synology regarding your blog?

 

[Oleg Afonin]

Zero feedback.

 

[fredbert]

Zero feedback.

You didn’t make the mistake of asking on their forum and expecting a response??

 

[Oleg Afonin]

No, that's not how I work Basically, I don't expect Synology to admit that their implementation is flawed, and I don't blame them. Making use of a TPM2.0 module that might be available in their x86 units and not using one (since there's none) on ARM devices would probably mess up user experience. I wonder if ARMv8 chipsets used in Synology's recent models are equipped with something like Trust Zone (I mean, in hardware). Probably not, as those chipsets seem to be quite ancient and stripped down to the basics.

Honestly, if I were designing a NAS with emphasis on security and hardware-backed AES encryption, I would do it in a very different way. For example, I would use hardware passthrough encryption instead of "software-accelerated" one (the term borrowed from Google's excuse for not utilizing a proper chip in their early Nexus devices) in the form of an always-encrypting SATA bridge as the first encryption layer (zero hit on performance), with an encrypted file system being an optional extra layer of encryption. I would use hardware-backed security (Trust Zone or similar on ARM, TPM2.0 on x86) to generate encryption keys. I would definitely enforce secure boot.

 

[jeyare]

Yes @Oleg Afonin, agree
with wide range of supported CPU platforms it’s a highway to hell. From one side it’s great, that Syno can provide “low cost” ARM based NAS. TBH, the price between ARM vs Intel based model is not a heavy gap for the group of customers, who can compare differences:
DS 218j (ARM) ... 165€
vs
DS218+ (Intel) ... 327€
And this is the answer. The range of ARM based HW is for budget driven customers (what isn’t a shame from the customer’s point of view). Then Syno is in their own cage of more secure encryption multi platform development.
It will be great to see what portion of the sold Syno NASes are based on these “j” class HW and what is a trend in last 3y.

 

[fredbert]

@jeyare The j-series is their gateway drug to the harder + series.