19

Is there any research as to how secure hardware encryption of SSD's is - for example Samsung EVO 850? Or at least any articles that explain how it works?

kat
  • 411
  • 1
  • 3
  • 11
  • Hardware encryption? – ferit Aug 22 '16 at 16:40
  • 1
    Related: [Samsung SSD 840 Evo Disk-Encryption](https://security.stackexchange.com/questions/67284/samsung-ssd-840-evo-disk-encryption), [Samsung SSD 850 EVO. Best way to protect personal data against thiefs](https://security.stackexchange.com/questions/108027/samsung-ssd-850-evo-best-way-to-protect-personal-data-against-thiefs). Support is also reported to be limited: [How to enable SSD encryption?](https://superuser.com/questions/1007792/how-to-enable-ssd-encryption), [Is a hardware-based full disk encryption possible on a Mac?](http://apple.stackexchange.com/q/76530) – Alexander O'Mara Aug 22 '16 at 17:06
  • Here's some good SSD information in general: https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEFCON-24-Tom-Kopchak-Sentient-Storage.pdf when the talk gets published to youtube in the next few weeks or so, you should check that out too. Understanding how SSD works is useful in answering your question. And that pres does go into SSD for Samsungs. – HashHazard Aug 22 '16 at 17:43
  • So basically a few years in and self-encrypting SSD's are still a black box... So it's safe to consider that for now software-based FDE is the preferable method of encryption, especially considering the two don't have that many differences as far as attacking goes (at least based on what is known) - source: https://www1.cs.fau.de/sed. – kat Aug 23 '16 at 11:50
  • I am not sure what is the issue you were (are) having with SED/FDE. OPAL 2.0 is around for years, just like [sedutil](https://github.com/Drive-Trust-Alliance/sedutil) which helps you with using PBA (Pre-Boot Authentication) images. Maybe you should read something on the topic – [Securing SSDs with AES Disk Encryption](https://www.electronicdesign.com/memory/securing-ssds-aes-disk-encryption). Samsung provides their own facility for managing SEDs as well (built into Samsung Magician). – ᄂ ᄀ Aug 21 '18 at 14:12
  • A recent Dutch study at Radboud University has shown that many ssd’s (of an admittedly limited subset) are extremely vulnerable. See for example https://www.zdnet.com/article/flaws-in-self-encrypting-ssds-let-attackers-bypass-disk-encryption/ – Sebastiaan van den Broek Nov 15 '18 at 05:02

2 Answers2

18

TL;DR: Do not use hardware encryption on any storage medium no matter whether it's a thumb drive, an HDD, or an SSD! That's a really, really bad idea!

Hardware manufacturers are know to have included back doors or just bee very, very stupid about encrypting the data. This goes as far as them just using the same key for all their devices or them letting the encryption keys lay around unencrypted and hoping that no one will change the firmware in a way that allows someone to access them without knowing the password. I've heard and read this a lot and can't possibly show you my actual sources but here is an article confirming what I just claimed.

Hardware manufacturers are also known to have been forced to lower the level of encryption. Same way I know this as above and this article confirms it.

Just picture what's happening when you use hardware encryption. You buy that magical device from someone who claims that only people who know the password can access the data stored on this. That person does not show you how it works. They may also lie to you (see article linked in the previous paragraph) with you having very little chance of ever finding out. You have no way of verifying or disproving those claims.

Of course, don't trust software encryption by hardware manufacturers either. I bought a USB stick about 5 years ago from SanDisk (still have it and last used it an hour ago) which came with an "encryption software". I never used that encryption software, not only because it's against all standards one should uphold about encryption (see last paragraph) but also because after very little research I found that that software (which only worked for MS Windows which itself is another very good reason to never use it) writes 1 or 2 characters (I forgot whether it was 1 or 2 but that doesn't matter) into a file which it created in the Windows user folder if the correct password has been entered. Those 1 or 2 characters showed the application that the user had permission to access the files. If you simply wrote the correct content to the file (which is the same for everyone using that software), you could access the data stored on the thumb drive without knowing the password. So don't use that either.

Software encryption is much better because you as the user control which software is used. You can take a look at, pay someone to take a look at it, if it's commonly used (And it should be!), others will have a look at it anyways, and if it's openly developed, there are people publicly arguing about how it should be to be as secure as possible and those people don't trust each other.

Furthermore, you have an easier time switching out the software used for encryption. If you use hardware encryption, once you have the hardware, you use the specific encryption that hardware provides. You'll be reluctant to spend a lot of money to buy new hardware and throw the old hardware away, even if it's revealed that there are security issues because "It's not that bad." and "No one will attack me, anyways." whereas you would've thrown out a software with similar flaws and exchanged it for a different one within one day.

Only use encryption software if it is free and widely accepted to be secure. That it is free requires that you can get hold of its source code if you don't know that. (Not that it being open source is necessary, not sufficient.) If you are denied access to the source code, never trust the application! This of course includes not trusting it about protecting your data from unauthorized access. If it isn't widely accepted to be secure, it's very likely that the people who created it made mistakes (one can make an awful lot of mistakes about encryption and has to do a very good job in order to make encryption secure) or even maliciously made it insecure which can include not encrypting anything at all.

UTF-8
  • 2,300
  • 1
  • 9
  • 24
  • 2
    Problem is that you might not think about everything when using encryption software. You are not going to encrypt the trash, some paged memory, some backups, etc... whereas all of this is encrypted with FDE. It's also freaking slow if you want to actually work on encrypted data whereas FDE is accelerated by the TPM. Use FDE, if your threat model includes the NSA, then do both. – David 天宇 Wong Jun 23 '17 at 10:13
  • 1
    @David天宇Wong When you use the default disk encryption or home folder encryption of your operating system, this is clearly not true. For disk encryption, it's obvious. Regarding home folder encryption: I don't know of any Linux distro where the trash is not inside the home folder for files which were in the home folder before. There are different locations for the trash but they all are inside the home folder. This is important for performance (and avoiding unnecessary read/write operations). Ubuntu certainly encrypts the swap partition when you select disk encryption during installation. – UTF-8 Jun 23 '17 at 13:43
  • 1
    @David天宇Wong Speed was not asked about in the question. The question is about how secure hardware / software encryption is respectively. Speed of software encryption greatly depends on whether you have hardware acceleration for the method of encryption chosen. – UTF-8 Jun 23 '17 at 13:46
  • I'm guessing any 64-bit architecture has AES-NI nowadays so :| – David 天宇 Wong Jun 24 '17 at 15:15
  • 4
    And it's now been [confirmed](https://www.ru.nl/publish/pages/909282/draft-paper.pdf) about the Samsung EVO which the OP mentions specifically. – Ploni Nov 05 '18 at 22:39
  • @Ploni Thank you very much for providing evidence supporting my point. – UTF-8 Dec 26 '19 at 17:39
-3

The symmetric encryption which is AES-128 or 256 is safe.

However it has it's own trade-offs.

Being built-in the hard-drive, the secret key is stored on drive and protected by key. Now the thing is that in every drive there's a way to bypass it in some way and recover the key. It's quite unlikely that hardware vendor put enough protection into this even it's technically possible.

So with most SSDs and AES, forensic companies may be able to decrypt it without knowing password or cracking it at all.

On the other hand, the software encryption requires you to enter the password to unlock the key and then the key is stored in RAM.

As it's impossible to decrypt the drive, it's possible to decrypt from suspended laptop with cold-boot attack.

I don't think if there's some reliable way of doing it. I think one option would be storing the key in the TPM, and then transferring it using trusted kernel to the harddrive firmware. Another way would be to use 20 or 40 characters random password which is a key and once entered it's transferred to the hard-drive firmware.

Anyway, with software encryption like LUKS you have a lot better chance of not getting drive decrypted when stolen. The way AES is used also may be better.

Aria
  • 2,706
  • 11
  • 19
  • 2
    Providing some citations and references would make your answer a lot stronger. – Mike Ounsworth Aug 23 '16 at 13:25
  • 1
    As would a mention of the weakest link in the security chain, the human operator. Social engineering is almost always a bigger threat than technical attacks. – Jared Smith Aug 23 '16 at 13:26
  • Yes, but the topic is about the technical aspects of encryption, leaving aside the human factor. Obviously, even the strongest encryption is useless if you give away your key freely. – kat Aug 23 '16 at 16:09
  • "Being built-in the hard-drive, the secret key is stored on drive and protected by key. Now the thing is that in every drive there's a way to bypass it in some way and recover the key. It's quite unlikely that hardware vendor put enough protection into this even it's technically possible." Recover what key using bypass? The master is usually (LUKS fo example) encrypted by a KEK (key encryption key) that is NEVER stored anywhere, but derived everytime from user passphrase (or pin or password or keyfile) and salt. – refex Aug 23 '16 at 22:18
  • LUKS is software encryption (in operating system). While harddrive encryption is also some sort of software, very often it doesn't have strong matured design as LUKS simply because LUKS was maturing for long time while HDD/SSD encryption is relatively new compared to LUKS and keeps being defeated. – Aria Aug 28 '16 at 12:00
  • [You're wrong.](https://www.ru.nl/publish/pages/909282/draft-paper.pdf) (Link originally provided in [this comment](https://security.stackexchange.com/questions/134564/how-secure-is-hardware-full-disk-encryption-fde-for-ssds/136390#comment391899_136390).) – UTF-8 Dec 26 '19 at 17:40