Flaw in Full Volume Encryption still existing?

Synology
1

Hi there!

I am looking forward to get the first NAS-System for my company.
When I was consider it for the first time, i stumbled about the massive flaw in the full volume encryption published by SpaceRex in 2023.
That´s a full deal-breaker for me, so i put the Idea of a NAS beside.

However, I really need one now and I don´t really like the QNAS-Alternative where the full volume encryption does the job like it should be as far as I know.
I would prefer to get a Synology-NAS.
But only if the flaw in the full volume encryption is fixed.

So, long story short… my question is: Does the flaw in the full volume encryption still exist or is this issue fixed?

Many thanks for any helpful reply.

Regards

2

Maybe you like to elaborate on the flaw you mentioned. Not that I am illiterate on the matter, but each reader that responds might have a different view on it and confusion starts.

My take is there are two issues with volume encryption.

First, the user that implements it has no clue about key management. This may result in a situation that the recovery key is lost and the volume stays encrypted after a mode 1 reset. Only a restore from backup can help you out, against the cost of downtime.

Second, volume encryption starts making sense if you store the volume encryption key on a different Synology NAS, not the same NAS (remote versus local encryption key vault).

Last but not least, what is it what you plan to achieve with volume encryption in the first place? The business case is often not clear. The bottom line here is that encryption is not always better. To the contrary.

3

Thanks for your fast reply.

The flaw I am talking about is the possibility for attackers to get access to the encrypted data as descripted here:

My goal is to have a full encrypted NAS-volume with the full responsibility on my side. Meaning: If I lose the password, there shall be no way by any means to access this data. Doesn´t matter how much knowledge is needed to carry out an successful attack. There shall be just no way with today technical methods to access the encrypted data if you don´t know the password.
Of course I am fully aware of the risks coming with a true full volume encryption without any rescue- or possible attacking-pathes. But that´s what I would like to have. Like a full encrypted TrueCrypt-Volume: No password, no access by any means.

4

As Synology states in their white paper on the subject, volume encryption with a local key vault protects you from data stolen in case the disks are stolen without the NAS. This separates the key from the disks and the volume remains locked when placed in another NAS.

With a remote key vault you are protected against theft from disk alone, and from disks with NAS.
I think that a potential flaw in the local key vault design should not be your biggest concern.

Storing the key with the volume on the same NAS offers little benefit. A remote key vault is the way to go. And it dissolves any concerns about a potential design flaw in the local key vault.

You need a second NAS that supports volume encryption as these models also support KMIP remote key vault. If my memory servers me right all recent Plus models and higher are in this category.
Perhaps that second NAS, with a non-encrypted volume, is the backup NAS.

5

Thank you for the detailed reply. I have been pondering about something similar. I am in the process of setting up my system + offsite backup from scratch again, and wanted to go full volume encryption on both DSM devices this time. Here is the scenario I am struggling with:

I am using Tailscale to establish a VPN between both systems since they both sit behind firewalls that are outside of my control. I want to make device #2 the remote key vault for device #1 and device #1 the remote key vault for device #2.

Now, if one of the devices gets stolen, I would have to immediately sever the Tailscale connection to prevent it from automatically connecting via Tailscale to the other device again, automatically decrypting the volume, no? Is this a scenario I should just not be concerned about since the intruder would have to steal the NAS, connect it to the internet (revealing its location), …

Synology should just offer the option to require a password for volume decryption upon boot as this would circumvent all of these considerations.

Anyways, I am curious to hear your thoughts. Thank you.

6

Hi dsm,

What a cunning plan you have! :wink: I have some information and food for thought.

A Synology NAS that is a remote key client can not be a remote key server at the same time, and vice versa. In other words, the NASs can not be each other’s remote key server while being each other’s remote key clients. A remote key server, however, can store client keys from different volumes and different NASs.

As far as I know, the key client-server connection must be local, but a VPN connection might work. I have no information about that or experience with it, but it is on my to-do list.

Assuming that a remote key client-to-server connection works over Tailscale, a stolen NAS that is the client won’t be able to connect to the remote key server from a location that is not part of your Tailscale VPN. It is good to test that scenario, but this is the theory so far. Again, this is for the to-do list.

Having both NASs fitted with an encrypted volume is unnecessary since you can encrypt the backup. Don’t forget to store the password for that backup properly.

More: You plan to trust the transport of your encryption key to a third party. Consider the potential risks regarding the trustworthiness and availability of this service.

For example, if you restart your NAS after a DSM upgrade and Tailscale is temporarily out of service, your volume remains locked until the connection is re-established unless you apply the recovery key.

Last: when you (plan to) implement volume encryption or any form of storage encryption, plan your recovery key storage. The key must always be available for you or other authorized persons and never to any unauthorized person.

Finally, periodically test the recovery procedure. Preferably, have it written down to ensure it works when needed.

Tip: when you encrypt a volume, consider a small unencrypted volume on the same NAS for applications you can’t live without in case of a locked volume. This is about balancing risks (prying eyes versus availability).

7

This is very helpful. Thank you very much! I will make sure to test (and write down) the recovery procedure to know that things are working as intended.

You are correct: Hyper Backup can just be encrypted on the receiving end. I was toying with the idea of having perfect clones (on two encrypted drives) using rsync, but like your idea more, the more I think about it. Why not use HB the way it was intended…