Self Encrypting Drive Support

[cs03dmj]

So I plumped for the TS-453 Pro and a Samsung 840 EVO SSD. Both have hardware AES encryption, but I believe using that built into the disk would provide better performance. To that end, can anyone please confirm how to configure the Self Encrypting Drive?

[schumaku]

There is no SED drive support - explained several times - consider using search before posting please. http://forum.qnap.com/search.php?keywor ... ting+Drive

[cs03dmj]

I should've clarified that my searches resulted in no clear answer. Now you have provided one, hopefully my question will help anyone else in the same predicament - thanks!

[mjburns]

I put in a product request for SED support a while back (Ticket ID: IZN-721-70345). Don't know if it will ever happen. But it would be nice. My QNAP uses Western Digital RE drives, which are SED drives, which means they are encrypting & de-encrypting all data being written & read to them on the fly already. But without the QNAP having SED support, it's like storing your stuff in a safe but having to leave the door unlocked.

[schumaku]

This does only help against physical NAS or HDD thieves or unwanted data leakage on HDD service/warranty replacements. Once unlocked, SED drives provide transparent access to the data. SED makes perfect sense for portable devices which can be lost or stolen easily.

Physical access is always the number one security risk to mitigate.

it's like storing your stuff in a safe but having to leave the door unlocked.

Nope. The NAS is certainly not to be compared to a safe - if you have this kind of high sensitive data on systems located at physical insecure place there is something badly wrong with the security concept.

[johnripper]

I am using the NAS for project teams in temporary customer locations where neither I or the teams can guarantee 100% physical security to the devices. Even so the devices should only hold customer data, the customer shouldn't get access to this data itself as there might be "department" confidential data was well. Also there might be a chance that selective knowledge of our company might be stored on the device.
This is why I am using disk the full encryption with the option to enter the password on boot.

I can see any wrong security concept here.

[pwilson]

I am using the NAS for project teams in temporary customer locations where neither I or the teams can guarantee 100% physical security to the devices. Even so the devices should only hold customer data, the customer shouldn't get access to this data itself as there might be "department" confidential data was well. Also there might be a chance that selective knowledge of our company might be stored on the device.
This is why I am using disk the full encryption with the option to enter the password on boot.

I can see any wrong security concept here.

Your concept is fine. Unfortunately this functionality does not exist on the NAS, so your "concept" is unfortunately "useless" to you at this time. You can encrypt external drives "manually" as desired, but the NAS does not (yet) support SED drives. This would probably make a good "feature request" for consideration for a future Firmware.

[mjburns]

Once unlocked, SED drives provide transparent access to the data.

That same criticism is valid for QNAP's present model for encrypting disks/volumes.

In both cases, the authentication has to be repeated if the system is rebooted, but otherwise provides transparent access to the data once the drive (or volume) is given the access credentials by the PC or NAS. The SED model is probably more secure if the drive is removed, as the SED drive won't allow the volume to be examined at all unless someone can supply the unlock password. An non-SED drive with a encrypted EXT4 volume on the other hand, can have it's bits examined at will without a password, although the data is encrypted so that usually won't do anyone any good. In both cases, the drives can simply be reformatted and the encrypted data lost, if the thief only wants the drives for their storage not their data.

As for the "safe" analogy, it is actually the standard analogy for SEDs. All data on the drive is encrypted on all writes, and decrypted on all reads, using an internal key generated when the drive is first set up by the user. If the drive was not locked (in PC's activated with a bio setting), then the drive, to the PC, looks like a normal drive and will "talk" to anyone even though all data is internally encrypted, and the drive can be moved between machines just like a non-SED drive. Hence the analogy when the SED drive isn't setup to be locked as "akin to having a safe but always leaving the door wide open."

The bottom line is that most people asking for SED support &/or folder level encryption are worried about sensitive data if the unit gets stolen. I know people who have had cars broken into and their laptops stolen, as well as businesses burgled and servers stolen. Worries about data theft by people who have authentication credentials in their possession and want to steal the data over the network, such as disgruntled employees or "hackers", is a different issue.

BTW, for those who are unfamiliar with SEDs, HP has a nice (short - only 6 pages) white paper on SED's. http://h20195.www2.hp.com/v2/GetPDF.asp ... 992ENW.pdf

Physical access is always the number one security risk to mitigate.

While I don't disagree with that statement, I've worked in all sorts of environments, including secure defense establishments, where property thefts have occurred. So I never assume physical access by unauthorized people can't happen. I've also worked in environments where the ability to secure property with anything beyond putting it in a locked closet was impossible. You have to play the cards you are dealt.

[schumaku]

Hey, I understand the needs for SED perfectly. However, I don't trust in the "simplicity" of most EFTI/BIOS SED control implementations - where we're back to the single password ... essentially the root password issue we both perfectly know from the U*x world. This approach is not fit for business usage !

Yes, I must admit having some history in specifying, implementing, and deploying of pre-boot environments providing managed and controlled multi-user access (based on certificates resp. digital signatures, obvious eh?) to control SED (we worked with all three big HDD makers back then...) and proprietary HDD vendor access blockers and encryption systems. No Smartcard, no PIN, and certificate not validate-able online == no unlock, and no HDD access at all. Or limited HDD access for example - you get the idea. Needless to say - all that was (and still is) part of the single-sign-on solution.

I'm still convinced data _is_ stolen daily, hourly, every minute, every second...in 99.9999% without being anywhere near to the hardware. It's the 0.0001 % case that hardware is stolen to get the data. Wrong priority settings for me.

PS. Back in these times, we (resp. a customer of us) go under fire by a major European government who disliked our system, because they had not bypass for it. Ridiculous French law back then...

[W4CHL]

Here is another use case for Self Encrypting Drives (SEDs): reuse of NAS drives as part of "sneaker-net" data transport as part of a data migration solution between different sites. In some environments the drives cannot be re-used with another customer unless they are scrubbed using 5 pass DoD rewrite process. In some cases, disk destruction and drop ship of new drives to the next customer separate from the NAS is cheaper. However, the SED drive has a very simple mechanism that meets the test for data scrubbing by just resetting the drive to use a new key on the drive and "reformat". This much less expensive process tilts the balance toward re-use of drives again. However, the drive environment, the NAS or drive array, must support this reset of the SED, which no QNAP NAS supports, yet!

Unclear how QNAP volume encryption setup will fare in review, as we are faced with a spec for supporting SEDs, or disk destruction or multi-pass wipe without.

So as part of a team that considered QNAS vs some other SAS supported NAS for such sneakernet data, I put in feature request in again for QTS 4.2 followup.