Posts Tagged ‘NAS’

TerraMaster is a relatively new company specializing in network attached storage and direct attached storage solutions. The majority of TerraMaster NAS solutions are ARM64 and Intel-based boxes aimed at the home and SOHO users. TerraMaster’s OS (TOS) is based on Linux. At this time, TOS 4.1 is the current version of the OS.

TerraMaster advertises secure AES encryption with unspecified key length through the entire range of its current NAS devices. This time around, we’re dealing with folder-based encryption that runs on top of the open-source encrypting file system eCryptfs. TerraMaster’s implementation of data encryption is extremely simplistic and lacks any sort of management for either the encryption key or the encrypted data.

Abstract and Summary

TerraMaster implements folder-based AES encryption with a single, fixed, unchangeable encryption key based on the user-provided password. The company does not specify the length of the key used for AES encryption. A 42-byte (336-bit) encryption key file can be manually exported for backup purposes. Users can unlock encrypted volumes by either typing the original plain-text password or uploading the encryption key.

TerraMaster has never documented any technical details about the underlying encryption mechanisms.

Encryption key: plain-text password or key file (must be manually exported while the encrypted share is mounted and unlocked).

The original password is used as Media Encryption Key. The concept of Key Encryption Keys is never utilized here; as a result, users cannot change their encryption password at all. In addition, TerraMaster OS does not have provisions for encrypting existing data or permanently decrypting encrypted shares. Any changes to encryption require deleting and re-creating shares and filling them up with data.

The entire encryption scheme lacks any sort of technical documentation.

Test Bench

We analyzed a TerraMaster F2-220 device based on a quad-code ARM64 design. A non-SED WD Red HDD was used to set up the NAS perform the analysis. The NAS was running on the latest available version of TOS 4.1.

TerraMaster: Folder-Based Encryption

TerraMaster uses folder-based encryption based on eCryptfs, an open-source stacked cryptographic file system. Detailed information on eCryptfs is available here. This is the same encryption scheme as used in consumer Synology NAS devices. However, while Synology properly documents the restrictions of folder-based encryption, TerraMaster does not. As a result, the user finds out about the fact that encrypted file names are restricted to 143 Latin characters in a hard way by getting a write error when attempting to store a file with a name that is longer than permitted. Using Asian characters makes the possible file names even shorter.

From the point of view of a normal consumer, TerraMaster’s implementation of encryption is not just restrictive; it’s restrictive by surprise since no advance warning is given and no documentation is available about it.

Once the encrypted share is created, users cannot change the encryption passphrase.

Encrypting

Users can only encrypt newly created, empty shares. Encrypting an existing share is not possible. One must first delete the encrypted share, create a new one while selecting the encryption option. As a result, encrypting shares with existing data is not supported.

The good thing about this encryption scheme is the ability to create multiple shares, each with its own unique password. If there are multiple users, each user can encrypt their personal share with their own password. However, the complete inability to change the encryption password makes this approach dubious in the grand scheme of things.

Creating an encrypted share

The first step is creating a new share:

The “Encrypt this shared folder” box activates the encryption. The encryption feature requires a password, which is used as an encryption key. There are no obvious limitations (minimum or maximum) to the length of the password or supported character sets.

The process is concluded after setting access permissions and confirming settings:

The encrypted share is created and mounted. Note the “lock” icon:

Exporting the encryption key

Pretty much the only thing users can do with their encryption key other than using it for mounting shares is exporting it to a file.

In order to export the key, users must re-enter their encryption password:

Mounting encrypted shares

The encrypted volumes can be only mounted manually. Users must log in to the TOS Web UI, click on the encrypted share and use the Mount command. There are no auto-mount options available, and there are no vulnerabilities connected with the improper storage or handling of encryption keys.

The following two options are supported.

  1. Mounting with the original plain-text password.
  2. Mounting with the exported key file.

Choosing between these two options, the key file appears to be the more secure one as users can generate a long, random password with high volatility and use that password to produce the backup key file.

Unmounting encrypted shares

Encrypted shares are unmounted automatically once the NAS is powered off or rebooted. Manually unmounting the encrypted share requires accessing the Web UI:

Permanent decryption

Your familiar full-disk encryption tools such as Microsoft BitLocker allow removing the password from an encrypted volume. This is possible because these encryption tools use a concept of separate Media Encryption Keys (MEK, which are used to protect the data) and Key Encryption Keys (KEK, which are used to protect, or “wrap”, the MEK).

TerraMaster does not use the concept of separate MEK and KER. As a result, removing the password is not possible without physically decrypting the entire set of data (which is not supported by TOS). The only way to permanently decrypt the data is removing the encrypted share, re-creating the share without encryption and filling it up with data.

Changing the password: impossible

Decades ago, manufacturers came up with a brilliant idea of separating the binary encryption keys that are used to encrypt and decrypt the data, and secrets that are used to unlock the encryption keys. This wonderful concept allows many things such as using any one of the several different passwords (or multiple types of authentication credentials, such as a smart card or a password) to unlock encrypted volumes. Sadly, this concept is rarely used by NAS manufacturers. TerraMaster is no exception; users cannot change the password because the password itself is the Media Encryption Key.

Manually Decrypting Encrypted Shares

Looking at the path that contains the encrypted files, I wonder if TerraMaster could be inspired by Synology’s implementation of folder-based encryption. The path to encrypted share looks as follows:

/mnt/md0/@encrypted@/

Where “encrypted” is the name of the share (as seen on screenshots above).

Path to decrypted files/mounted share:

/mnt/md0/encrypted/

Since TerraMaster uses eCryptfs, we can use the familiar command to mount the encrypted share:

mount -t ecryptfs /mnt/md0/@encrypted@ /mnt/md0/encrypted

You will need the user’s original, plain-text encryption password. TOS does not appear to be storing the encryption password or the encryption key file anywhere on the disk or in the boot DOM.

If you are able to decrypt the files, but the file names remain encrypted (ECRYPTFS_FNEK_ENCRYPTED), check out the following threads:

Alternatively, this open-source tool: pecryptfs – Portable Userspace eCryptfs may help decrypting individual file names.

What Risks Are Covered by TerraMaster Security Model

Similar to other implementations of NAS encryption, the security model employed by the TerraMaster is stripped down to the bare essentials. I have the following remarks about the TOS security model.

  1. Unlike volume encryption schemes, folder-based encryption comes with encryption metadata duplicated in every file. “eCryptfs stores cryptographic metadata in the header of each file, so that encrypted files can be copied between hosts; the file will be decrypted with the proper key in the Linux kernel keyring.” (source) This makes secure erase of encrypted data impossible. To securely erase data encrypted with eCryptfs, one must either wipe (overwrite) encryption metadata in each and every encrypted file; wipe the full content of every file; or wipe the entire disk.
  2. This encryption model does not properly protect the data if one needs to send the disk out for repair/replacement or simply wants to sell the disk. The encryption metadata is duplicated in every file in the encrypted folder. As a result, the attacker can obtain a single file and run a (fast) attack on the encryption key. Open-source tools such as pecryptfs – Portable Userspace eCryptfs may help decrypting individual files.
  3. The lack of any sort of technical documentation for the data protection scheme is discouraging. This might be passable for the home user and occasional small office use, but unacceptable for anything beyond that.
  4. The encryption key cannot be changed. Enough said.

Conclusion: TerraMaster Folder Encryption

When it comes to attached storage encryption, we are still in the Stone Age. The lack of basic features, many of which we accept as a given, makes TerraMaster encryption hardly usable. The lack of technical documentation, undocumented functional restrictions and encryption metadata duplicated in every file makes this encryption hardly useful. TerraMaster OS does not separate Media Encryption Keys and Key Encryption Keys, which makes password changes impossible.

The lack of the key management, the inability to change the encryption password, and the inability to encrypt or permanently decrypt existing shares makes TerraMaster NAS encryption one of the least flexible implementations, on par with Thecus NAS encryption. The protection system uses the well-established eCryptfs encryption framework, yet the TOS implementation still lacks transparency or any sort of technical documentation. Security wise, the data would be impossible to decrypt without knowing (or breaking) the user’s encryption password (or, alternatively, without access to the exported encryption key).

At the same time, TOS encryption implementation is straightforward enough to appeal to some users. However, those same users may be put off by the need of re-entering their encryption password in the Web interface every time they power on or reboot the NAS.

Thecus has been manufacturing NAS devices for more than 15 years. The company develops an in-house Linux-based NAS OS, the ThecusOS. At this time, the most current version of the OS is ThecusOS 7. Thecus advertises secure data encryption in most of its NAS devices. The company’s volume-based encryption tool allows users to fully encrypt their entire RAID volume, defending essential data in instances of theft of the physical device. We found Thecus’ implementation of encryption somewhat unique. In this research, we’ll verify the manufacturer’s claims and check just how secure is Thecus’ implementation of 256-bit AES encryption.

Abstract and Summary

Thecus uses volume-based 256-bit AES encryption with a single, fixed, unchangeable encryption key. The 3968-byte (31744-bit) encryption key file is generated at the time the user creates a new encrypted volume based on the user’s password (4-16 characters, 0-9, a-z, A-Z only). Creating several encrypted volumes with the same password produces different encryption key files.

The encryption key is stored on an external USB drive (the only, forced option) and does not have any additional protection.

The encrypted volume is automatically unlocked once the user inserts the USB drive that contains the correct encryption key.

The original password the user typed when creating an encrypted volume is never used again, anywhere. Users cannot change the encryption password. Users cannot encrypt existing data. Users cannot permanently decrypt encrypted volumes. Any changes to encryption require deleting and re-creating the volume and filling it up with data. The entire encryption scheme lacks any sort of technical documentation.

The entire protection scheme is completely undocumented. For example, it is not clear what the password is used for since the user never has to type it again (ever) to mount or otherwise access encrypted volumes.

Note: SED is supported by ThecusOS but was not tested in our lab.

Test Bench

We analyzed a Thecus N2810 device based on an Intel Celeron Processor N2810. A non-SED WD Red HDD was used to set up the NAS perform the analysis. The NAS was running on the latest available version of ThecusOS 7.

Volume-Based Encryption

ThecusOS supports volume-based encryption. Unlike folder-based encryption that allows protecting (or not protecting) individual shares, volume-based encryption protects the entire RAID volume. The closest analogy to volume-based encryption would be BitLocker in Microsoft Windows or FileVault 2 in Apple macOS. However, the Thecus implementation is significantly more basic compared to Apple’s or Microsoft’s full-disk encryption tools.

Encrypting

Users can only encrypt newly created, empty RAID volumes (regardless of the number of disks; a single-disk RAID volume can be encrypted just as easily as a volume spanning across multiple physical disks).

Encrypting an existing volume is not possible. One must first remove the volume, create a new one and tick the “Encrypt” box. As a result, encrypting volumes with existing data is not supported.

The first step is creating a new volume:

The optional encryption feature requires a password. The password must be 4 to 16 characters long; character groups 0-9, a-z, A-Z are supported (no special characters and no local characters).

Users don’t have to memorize that password as they’ll never have to type it again to access the encrypted data. Instead, ThecusOS will generate a 3968-byte (31744-bit) encryption key, and store that key on an external USB drive that must be connected to the NAS at the time the encrypted volume is created.

Once the user inserts an external USB drive (e.g. a flash drive) into one of the available USB ports, the NAS saves the encryption key on that drive and creates and mounts the encrypted volume.

Mounting encrypted volumes

The encrypted volumes are mounted automatically when the user inserts a USB drive that contains the volume encryption key into any available USB port on the Thecus NAS. There are no additional prompts, and there is no need to open the Web UI.

The following scenarios are supported.

  1. The NAS is powered on or rebooted; no USB drive containing the encryption key is inserted. In this case, the encrypted volume is locked, and the data is not accessible.
    However, the NAS can still complete the boot sequence as the main OS (and some configuration files) are stored on a small NAND storage chip and not on the hard drive(s).
  2. The NAS is powered on or rebooted; the USB drive containing the encryption key is inserted. In this case, the encrypted volume will be mounted by the time the device completes the boot sequence.
  3. The most interesting scenario is when the NAS is powered on or rebooted without a USB drive inserted, and the user inserts the USB drive containing the encryption key at a later point. In this case, the OS will automatically recognize the USB drive, read the encryption key and automatically mount the encrypted volume.

Locking encrypted volumes

As we figured, encrypted volumes are mounted automatically when the user inserts the correct USB drive. What happens after the USB drive is removed? In this case, the NAS keeps the encrypted volume mounted. The volume remains mounted until the NAS is powered off or rebooted, or until the user manually locks the volume through the Web UI.

Decrypting

If you are used to BitLocker, you probably know it is easily possible to remove the password from an encrypted volume. Interestingly, BitLocker will not decrypt any data that has already been encrypted; instead, it’ll just store the unwrapped encryption key in the volume header, allowing the system to pick up the key and access information without a password. Any new information saved on such BitLocker volumes would be saved unencrypted.

With Thecus, the situation is much simpler. Users cannot remove encryption or permanently decrypt encrypted volumes, period. The only way to permanently decrypt the data is removing the encrypted volume, re-creating the volume without encryption and filling it up with data.

Changing the password: impossible

Decades ago, manufacturers came up with a brilliant idea of separating the binary keys that are used to actually encrypt and decrypt the data, and user-provided secrets that are used to access the data. In symmetric cryptography, only one unique binary encryption key may be used to encrypt and decrypt the data; this is called the Media Encryption Key (or Data Encryption Key). However, users can unlock encrypted data by using multiple different types of credentials such as plain-text passwords, credentials stored on secure smart cards or TPM modules, binary keys (files) or combinations of thereof. These credentials (Key Encryption Keys) are used to encrypt (wrap) the Media Encryption Key. Multiple different Key Encryption Keys may be used to wrap the same Media Encryption Key, allowing the user to instantly change their plain-text password, add or remove smart cards and other credentials.

ThecusOS 7 does not use the concept of Key Encryption Keys. The user’s original plain-text password is used to produce a single, fixed Media Encryption Key. Neither the password nor the encryption key can be changed after the volume is encrypted.

Observations

While users are required to enter a password when encrypting the volume, this password will never be used again anywhere in the ThecusOS interface. I was unable to find any references to this password in the Thecus technical documentation or the online knowledge base. The password is not used to decrypt data or to mount encrypted partitions. Users will never have to type that password again. In other words, the password seems completely redundant in this setup. The lack of a proper explanation, let alone comprehensive technical documentation, makes me shake my head.

ThecusOS produces different encryption keys when creating volumes protected with the same password. This is a good hint that the password is salted with some random data. The lack of proper documentation makes this guess as good as any others.

Thecus and SED Encryption

ThecusOS supports SED (Self-Encrypting Drive) encryption, as seen on the screen shot below.

We have not tested the SED implementation due to the lack of a compatible hard drive. Considering the cost and market positioning of the Thecus N2810, the model is likely to be used with consumer-grade NAS hard drives such as the Western Digital Red or Seagate Ironwolf series, both of which lack the SED support.

What Risks Are Covered by Thecus Security Model

The security model employed by the ThecusOS is stripped down to the bare essentials. I have the following remarks about the Thecus security model.

  1. It is not clear why the system prompts for a password if that password cannot be used to unlock volumes and cannot be changed. If the user’s password is only needed as a random seed of a sort, this must be properly disclosed and documented.
  2. The lack of any sort of technical documentation for the data protection scheme is discouraging. This might be passable for the home user and occasional small office use, but unacceptable for anything beyond that.
  3. The encryption key is stored on a separate USB drive. Users can conveniently insert that USB drive at any time to automatically unlock encrypted volumes. As a result, the entire protection scheme is based exclusively on “something you have”. Anyone who has access to the USB drive holding the encryption key will be able to mount encrypted volumes.

As one can see, it all comes down to whether or not the attacker has access to the USB drive containing the encryption keys.

If the USB encryption key is stored separately of the NAS unit, and the NAS is powered off, the encrypted data is protected against the theft of the hard drives and the theft of the whole NAS unit.

If the attacker has access to both the NAS unit and the USB drive containing the encryption key, the protection is nil.

Conclusion: Thecus Encryption vs. Microsoft BitLocker

When it comes to full-disk encryption, Microsoft BitLocker and Apple FileVault 2 are the first things that come to mind, with TrueCrypt and VeraCrypt being the most popular third-party implementations. Secure encryption, comprehensive key management and multiple methods for encrypting and unlocking volumes are supported by all of these crypto-containers.

When it comes to attached storage encryption, you are welcome back to the Stone Age. A typical NAS advertising 256-bit AES encryption lacks any kind of key management; often to the point the user cannot even change their encryption password without deleting the entire volume, re-creating, re-encrypting and re-filling with data. Many NAS manufacturers have no idea about the existence of separate Media Encryption Keys and Key Encryption Keys, let alone their multiple instances. A typical NAS sold to a home or small office user does not allow encrypting existing data or removing the password from encrypted volumes should you no longer need to protect them.

All of these statements are true for the ThecusOS 7. The lack of even the basic key management, the inability to change the encryption password, and the inability to encrypt or decrypt existing volumes makes Thecus NAS encryption one of the least flexible ever. The protection system lack transparency or any sort of technical documentation. How does the system come up with a 3968-byte encryption key based on the user’s 4 to 16-character password? In a case of data loss, is it possible to decrypt the data with the user’s password instead of the encryption key? Does the key contain the user’s password, the hash of a password, or is it mostly random data? None of these questions have answers in the technical documentation.

At the same time, the encryption implementation is simple and straightforward. Based on a file stored on a removable USB drive, the data would be impossible to decrypt without said USB drive (unless a vulnerability is found). This encryption would likely be sufficient to protect most data stored by home and small office users.

Home users and small offices are served by two major manufacturers of network attached storage devices (NAS): QNAP and Synology, with Western Digital being a distant third. All Qnap and Synology network attached storage models are advertised with support for hardware-accelerated AES encryption. Encrypted NAS devices can be a real roadblock on the way of forensic investigations. In this article, we’ll review the common encryption scenarios used in home and small office models of network attached storage devices made by Synology. (more…)