Synology DSM 7.2 introduced a highly anticipated feature: volume-level encryption. This data protection mechanism works faster and has less limitations than shared folder encryption, which was the only encryption option supported in prior DSM releases. However, upon investigation, we determined that the implementation of the encryption key management mechanism for full-volume encryption fails to meet the expected standards of security for encrypted data for many users.

In this article, we will explore the current implementation of encrypted volumes in DSM 7.2 and shed light on the challenges posed by the existing key vault design. We will examine the limitations of the system, particularly in relation to the potential vulnerability of encryption keys and passwords stored on the same disk as the encrypted volume. Additionally, we will compare this design with the previously used encrypted folder approach, highlighting the advantages of the older method in terms of security.

Update: apparently, it took researchers with physical access to an encrypted Synology device less than 8 hours to bypass encryption by altering the system partition, adding a cron job that creates a reverse root shell on boot (reddit). A remote KMIP server may resolve the issue if and only if the auto-mounting of encrypted volumes is not enabled (reddit).

Before: shared folder encryption

Back in 2019, we analyzed the encryption of shared folders in Synology NAS units, and discovered a potential vulnerability in the encryption key vault if the user enabled the Auto-mount option. You can read about the issue in Synology NAS Encryption: Forensic Analysis of Synology NAS Devices. As to my knowledge, there were no major changes to shared folder encryption or encrypted key vault since that publication.

Instead of discussing the protection of the shared folder encryption key vault, let us talk about the pros and contras of shared folder encryption. There are tangible benefits to this protection method, namely:

1. Since one encrypts shared folders and not volumes, the location of encrypted data does not matter much. However, SynologydoesnotsupporttheencryptionofexternalUSBdrives.
2. A unique password can be used to protect each individual shared folder. Multiple users can set their own passwords to their folders.
3. One can copy an unmounted shared folder back and forth to another device without having to decrypt the content or even knowing the encryption password. This makes encrypted shares perfect for backups, especially remote backups to untrusted destinations.
4. The internally used eCryptFS file system encrypts both the content and names of files and folders (the latter comes with a tax).

Despite these benefits, shared folder encryption has several drawbacks that restrict its usability in real-world scenarios.

1. Encrypted file names may only contain up to 143 ANSI characters or up to 47 Asian characters.
2. While file and folder names are encrypted, the overall file system structure remains accessible along with metadata (file sizes, date/time/attributes and so on). This may not be acceptable in some applications.
3. Low read/write performance, especially when it comes to multiple small files.
4. Synology DSM does not use the concept of separate media encryption keys and key encryption keys. The data is encrypted directly with a key generated straight from the user-provided password, which in turn means that one cannot change that password without decrypting and re-encrypting the entire content of the encrypted hare.
5. Finally, the encrypted key vault in DSM makes encryption useless if the user enables the Auto-mount option, in which case the encryption password is wrapped with a known, fixed, leaked password, and stored alongside with encrypted data.

While we do list the 5) as a negative, do take a note on the following: the potential vulnerability only exists if the user manually enables the optional Auto-mount feature. If they don’t, or if they decide not to store the encryption password in the vault at all, accessing the encrypted share will require the intruder to perform a complex password recovery attack with no guarantee of success. This is no longer the case for volume encryption.

DSM 7.2: full volume encryption

DSM 7.2 introduced full появилась возможность шифрования тома – volume encryption, which is implemented via LUKS in aes-xts-plain64 mode.

One can only enable encryption on newly created volumes. You won’t be able to decrypt or decrypt an existing volume. When a new encrypted volume is created, DSM will save the recovery key (which one can recall and replace with a new one in the future).

Essentially, the system stores a key to the encrypted volume on the same storage device as the encrypted data. This in turn enables DSM to automatically mount encrypted volumes on system startup with no user interaction. There is no way for the end user to change this behavior unless they employ a remote KMIP server to manage encryption keys. Currently, only another Synology NAS (one that supports full volume encryption) may be used as a KMIP server. While beta versions of DSM 7.2 allowed for third-party KMIP servers, the feature was removed in the release build. Therefore, DSM 7.2 currently provides two options for encryption key management:

1. The key is stored locally on the same device as the encrypted data. Synology does not reveal the exact location and format of that key. It appears that the encryption key vault protects the key with a user-provided password (which is the same password the user enters when creating the encrypted volume). The vault password can be reset by the user; if the encrypted volume is mounted at that time, there will be no need to enter the old vault password (the user will have to enter their DSM login password though).
2. The key is managed by a remote KMIP server on another Synology NAS. In this case, to access the data, the intruder will have to gain physical control over two separate devices, including the KMIP server. If the key is stored on the other server’s encrypted volume, the intruder will have to overcome encryption on that volume first to access the key to the target NAS. While this management scheme appears more secure than a locally stored key vault, in the end it boils down to whether or not at least one of the two devices keeps a volume encryption key locally (which would normally be the case for the KMIP server).

Volume encryption vs. shared folder encryption

The table below provides a concise overview of the features and characteristics of volume encryption and shared folder encryption as implemented in Synology DSM 7.2.

Volume encryption offers comprehensive protection for everything stored on the encrypted volume, including shared folders, virtual machines (VMs), containers, and logical unit numbers (LUNs). On the other hand, shared folder encryption primarily focuses on safeguarding the content of files and their names, while excluding certain elements like the file system structure and metadata.

In terms of flexibility, both volume encryption and shared folder encryption allow users to change the encryption key vault password. However, volume encryption offers the additional capability of changing the encryption key by regenerating the recovery key. In contrast, shared folder encryption requires full decryption of all data to change the encryption key.

There are some differences in file and folder name length limitations, with volume encryption adhering to the Linux standard of 255 ANSI characters, while shared folder encryption restricts names to 143 ANSI characters.

Performance-wise, volume encryption is advertised to be up to 48% faster than shared folder encryption, with only minor performance impacts during backups and snapshot replication (as data must be decrypted when performing backups/replication). Shared folder encryption, on the other hand, experiences a noticeable performance drop when accessing multiple small files, but this does not affect snapshot replication because replication deals with raw (encrypted) data.

Key storage methods also differ between the two encryption types. Volume encryption allows for local key storage with obligatory auto-mount or remote storage using a Key Management Interoperability Protocol (KMIP) server, although the latter is currently limited to compatible Synology devices. Shared folder encryption utilizes a local key vault, which can be password-protected, with the option to store the password. Additionally, shared folder encryption supports storing keys on USB devices.

Regarding backups, encrypted volumes can only be backed up when encrypted volumes are mounted on both devices (if the destination device also uses volume encryption). In contrast, shared folder encryption supports fully transparent backups that do not require mounting or decrypting the data, making it ideal for backups to untrusted remote destinations.

Both volume encryption and shared folder encryption provide options for automatic mount on startup, with volume encryption enforcing it and shared folder encryption making it optional.

The key vault issue

As we can see, the volume encryption key is stored in the key vault on the disk, and the key vault itself is presumably encrypted for added protection with a user-provided password. However, there is an issue with DSM 7.2 insisting on the automatic mounting of encrypted volumes at boot. If no remote KMIP server is configured to keep the encryption key, the key to the key vault is also stored on the same disk(s) as the key vault and the encrypted data. We are not certain whether this key is stored unencrypted or is encrypted with a fixed passphrase (which is likely based on our previous research of Synology shared folder encryption). Nevertheless, this design creates a chain of passwords and keys that are all available on the same disk(s) as the encrypted volume.

The current design of the key vault undermines the primary purpose of volume encryption, which is to prevent unauthorized access to the encrypted data when someone has physical access to the disk. Interestingly, despite being technologically inferior in other aspects, the older design of encrypted shared folders actually surpasses encrypted volumes in terms of maintaining data security – at least unless one moves the key vault out of the local volume and onto a remote KMIP server.

Stacking encrypted shares on top of volume encryption

DSM 7.2 supports encryption stacking: one can create plain and encrypted shared folders on encrypted volumes. Volume encryption is implemented transparently in DSM, so there are no restrictions to stacking protection methods. One can create, backup, restore, and replicate encrypted shares on encrypted volumes without any additional restrictions. This in turn means that there are three types of protection available in DSM 7.2:

1. Plain shared folders on encrypted volumes.
2. Encrypted shared folders on plain volumes.
3. Encrypted shared folders on encrypted volumes.

Stacking protection methods by creating encrypted shared folders on encrypted volumes delivers additional security due to the way the encryption keys are managed in DSM. At the same time, one will also experience all the limitations of both encryption methods. There may be a small performance hit when placing an encrypted share on an encrypted volume, too; we plan to benchmark the different combinations of encryption in the future.

Using volume encryption

To create an encrypted volume, start in the same way as you would when making a regular one. The encryption settings will show up in the volume creation wizard:

On the next step, you’ll need to specify a password to protect the key vault. Later on, you’ll be able to use that password to unlock the key vault and mount the encrypted volume.

The system creates a recovery key:

After a final warning, the encrypted volume will be created:

Note: full volume encryption in DSM 7.2 enforces volume auto-mount on startup.

If you forget the vault password, you’ll be able to reset it by signing into your NAS device and resetting the vault password while the encrypted volume is mounted (the original vault password is not required, but you will be prompted for a local DSM password).

You won’t be able to disable encryption key vault unless you store the key on a KMIP server.

You can use another Synology NAS as a KMIP server:

The key can be stored on plain or encrypted volumes:

You can use the recovery key to unlock and mount the encrypted volume if you lose access to the key vault. You can also regenerate the recovery key, which automatically invalidates the old recovery key:

One Synology NAS can be a KMIP server and client at the same time.

However, you won’t be able to use a pair of Synology NAS devices to be each other’s KMIP server and client. If device A is a KMIP server and device B is a client, device B cannot be used as a KMIP server to device A (but can be used as a KMIP server to device C).

Note: third-party KMIP servers are not supported in the release version of DSM 7.2. Beta versions of the OS did not have such restrictions, and this open-source KMIP server provided a viable alternative to a second Synology NAS.

Conclusion

In this article, we discussed the introduction of volume-level encryption introduced in Synology’s DSM 7.2. This highly anticipated feature offers enhanced data protection, boasting faster performance compared to the previously exclusive shared folder encryption mechanism and addressing many of the limitations associated with folder-based encryption.

However, upon further examination, we discovered a significant drawback in the implementation of the encryption key management mechanism. Despite the advancements in volume-level encryption, the current approach fails to provide the desired level of security for encrypted data on the majority of devices, specifically nearly all devices owned by home users who may not have the ability or skills to use a remote KMIP server.

While the new encryption method offers improved speed and flexibility, the effectiveness of any encryption system heavily relies on the robustness of its key management. Unfortunately, the current key management implementation on local devices falls short in adequately safeguarding the encryption keys, leaving encrypted data vulnerable to potential breaches.

We strongly believe it is crucial for Synology to address this security concern, as the strength of encryption lies not only in the encryption algorithm but also in the protection of the keys. Without a reliable key management system, the overall security of the encrypted data remains compromised.

Therefore, it is essential that Synology focus on refining the encryption key management mechanism to ensure the desired level of security for encrypted data. Only through comprehensive security measures one can truly leverage the potential benefits of volume-level encryption and protect sensitive information from unauthorized access.