On Friday, August 24, 2018 at 5:42:16 AM UTC-4, awokd wrote: > On Thu, August 23, 2018 8:03 pm, tai...@gmx.com wrote: > > There is no reason to use an SED drive. > > I think that's a bit over-broad. It depends on threat model, which varies > from person to person.
Agreed. I'll just add a few bullet points on why it is wise to use the hardware encryption that comes with your OPAL-supporting SED SSD (via ATA Password or OPAL). This only applies to OPAL-supporting SED SSDs (e.g. Samsung 840 EVO/850 PRO and later; Crucial M500 and later): Read/Write user data denial: 1. ATA Password locked drive cannot be read from or written to until unlocked. 2. OPAL locked drive cannot be written to and on boot only presents a very small volume with generic read-only boot code that loads the tool to authenticate the user to the drive and decrypt the DEK. Flash firmware denial: 1. The OPAL standard requires that securely-configured drives (having enabling OPAL or ATA Password and importantly, whether currently locked or unlocked) shall block firmware updates or, if they do not fully block, the unlocking credential used to unlock the drive at boot must also be sent to initiate firmware updates. 2. IMPORTANTLY: when not securely-configured (as they come from the factory), firmware updates are not blocked at all. Enabling the locking of the drive at power on is also the way to block firmware changes. Don't be fooled by past analysis of the flaws of ATA Password, some no longer apply. For example, OPAL supporting drives are required to encrypt the DEK using the ATA Password and not store either the DEK or the Password in cleartext on the drive when ATA Password (or OPAL) is enabled. The old trick of using manufacturer-specific commands (either via the (S)ATA interface or using the jumper pinouts) to disable or rewrite the ATA Password cannot work with OPAL drives to get to the data on them. Don't like the DEK that was generated by the manufacturer? Change it (and wipe the drive) using ATA Sanitize Crypto Scramble Ext. > > In terms of encrypting boot that is generally impossible without the use > > of coreboot > > Encrypting boot is one use case for SEDs when only light security is > required. Will your average evil maid (or some thief who steals your > laptop) have access to tools needed to defeat OPAL, assuming it's > backdoored? And if your OPAL drive is backdoored by the manufacturer for a government, your drive is backdoored whether you're using OPAL or not and depending on what you wanted to keep private, you're already screwed. No security mechanism exists in a vacuum. Layer them as necessary. I want to prevent both remote firmware tampering and out-of-sight boot tampering. So I utilize the SED hardware security. I also enable software volume encryption, when available, as well. Brendan -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f2448952-5bc9-42e6-84b4-9c147b960843%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
