Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

zdnet.com

Post reply on HN
Print view View original

41–50 of 113 posts

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#41

Post by basilgohar »

xoa wrote: post #39
yellowapple wrote: post #25

Earlier quoted context omitted.

Yep, yep, and yep. I've said it enough to sound like a broken record: Transparency is a dependency of trust. If you can't see how it works, then it's objectively impossible to trust it to do the right thing. This applies to everything on a computer, really. Is your browser transparent? Is your operating system transparent? What about the drivers? Device firmware? That "security" solution that unexpectedly ushered in…

> Transparency is a dependency of trust. I think you go too far here. Trust is a dynamic spectrum, not binary. Transparency is one potential avenue to add trust, but is neither necessary nor sufficient in most cases. Every instance must be evaluated in light of its specific details, threat scenarios, and available tradeoffs. > If you can't see how it works, then it's objectively impossible to trust it to do the right…

I did not read GP as saying it was a binary choice, but rather a prerequisite. That is to say, without transparency, there can be no trust, but you can also have no trust with transparency.

For someone like me, who is somewhat technically competent, but not a security expert, openness means that names and figures I do trust have the chance to examine whatever I intend to use and comment on it, observe it, and make assessments, including shaming poor implementations claiming traits they have no right to. Turns out there are plenty of people more competent than me that can catch these things.

Transparency also allows less hiding of incompetency in otherwise commercial and/or proprietary designs.

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#42

Post by nly »

tptacek wrote: post #40
nly wrote: post #37

Earlier quoted context omitted.

Sorry no, i don't trust Shay Gueron either and, even if I did, I wouldn't trust what Intel, AWS or anybody else did after he left the building. Same goes for Whatsapp. It might be based on Moxies protocols and excellent work. I might trust Moxie, but I still don't trust WhatsApp to be eavesdrop free because I can't easily create compatible clients, inspect their protocol, or look at their code. That's not to say you…

You can have whatever criteria you'd like for trust. I'm familiar enough with the "open source security" argument on Hacker News to know where this discussion converges. I'm just offering a counterpoint: 1. Closed source wasn't too much of an obstacle for a pair of interested researchers to independently validate, without assistance from vendors, the firmware and hardware crypto interfaces on a bunch of drives. 2. Th…

1. There's a difference between kicking the tyres and looking under the bonnet of a car, and taking the schematics and building your own. It's easier to show something is crap than convince people that it is good when you're outright hiding things. If the things you aren't hiding (well) are crap, then god only knows how terrible the things you are really hiding are.

2. Making claims based on the calibre of the companies and individuals involved doesn't work. People don't trust DJBs algorithms simply because of his personal track record. He also publishes whitepapers about their design, and demonstrates their advantages over the state of the art. That's hard science, not "it must be good because DJB is a rock star". The fact that people can then take his designs and implement them themselves, in the open, is also important.

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#44

Post by paavoova »

I wonder what this implies for SSDs that claim to support instantaneous ATA Secure Erase. Many SEDs, when issued this command, will simply discard their internal key and generate a new one, in theory rendering data irretrievable. I've encountered this method recommend over traditional wiping for reasons of security (you can't be sure all blocks are wiped when overwriting due to internal reservation), speed, and flash-longevity.

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#45

Post by tptacek »

nly wrote: post #42
tptacek wrote: post #40

Earlier quoted context omitted.

You can have whatever criteria you'd like for trust. I'm familiar enough with the "open source security" argument on Hacker News to know where this discussion converges. I'm just offering a counterpoint: 1. Closed source wasn't too much of an obstacle for a pair of interested researchers to independently validate, without assistance from vendors, the firmware and hardware crypto interfaces on a bunch of drives. 2. Th…

1. There's a difference between kicking the tyres and looking under the bonnet of a car, and taking the schematics and building your own. It's easier to show something is crap than convince people that it is good when you're outright hiding things. If the things you aren't hiding (well) are crap, then god only knows how terrible the things you are really hiding are. 2. Making claims based on the calibre of the compan…

I don't know many people who actually work in cryptography who believe that verification is cheaper and easier than building systems.

People absolutely do, for the most part, trust DJB because of his track record. Find 10 people who have adopted Poly1305 and ask them what Poly1305 does better than GCM. That's not to say their decision is uninformed; rather, they've delegated a very specialized part of the decision that very few people are actually qualified to make out to an expert they trust, and trust for good reason.

In practical cryptography, the opposite approach --- people who trust nothing until they verify it from first principles --- is extremely problematic. That's how you end up with oddball libraries that only look like they can do a secure scalar multiplication or reliably add two numbers together. As Bruce Schneier is fond of pointing out, everyone can design a system they themselves can't break.

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#46

Post by xoa »

basilgohar wrote: post #41
xoa wrote: post #39

Earlier quoted context omitted.

> Transparency is a dependency of trust. I think you go too far here. Trust is a dynamic spectrum, not binary. Transparency is one potential avenue to add trust, but is neither necessary nor sufficient in most cases. Every instance must be evaluated in light of its specific details, threat scenarios, and available tradeoffs. > If you can't see how it works, then it's objectively impossible to trust it to do the right…

I did not read GP as saying it was a binary choice, but rather a prerequisite. That is to say, without transparency, there can be no trust, but you can also have no trust with transparency. For someone like me, who is somewhat technically competent, but not a security expert, openness means that names and figures I do trust have the chance to examine whatever I intend to use and comment on it, observe it, and make as…

>I did not read GP as saying it was a binary choice, but rather a prerequisite.

That is a binary statement though, saying it's a prereq is saying without it trust is 0.

>That is to say, without transparency, there can be no trust, but you can also have no trust with transparency.

That would clearly be incorrect though. Transparency is not needed to probe a system, it is mostly helpful in changing the incentive structure for development in the first place (helping avoid laziness mostly), making the system more likely to be casually looked at, and fixing it if the original party is slow about it or absent. There can absolutely be trust without transparency however when other factors are strong enough, it's just that transparency lowers the strength needed and in turn helps in cases where it's not there.

>For someone like me, who is somewhat technically competent, but not a security expert, openness means that names and figures I do trust have the chance to examine whatever I intend to use and comment on it, observe it, and make assessments, including shaming poor implementations claiming traits they have no right to. Turns out there are plenty of people more competent than me that can catch these things.

>Transparency also allows less hiding of incompetency in otherwise commercial and/or proprietary designs.

That's what I said though? But are you arguing in turn that the typical iPhone is a lot easier to break into and less trustworthy then the typical Android or PC? It's the least transparent after all. And what about for the majority of the population who lack even the technical meta-knowledge we have let alone anything more? They still have to exercise trust, so how do you think that works from their perspective?

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#47

Post by tgsovlerkhgsel »

Skunkleton wrote: post #8
trulyrandom wrote: post #5

I did not know that BitLocker relies on hardware encryption if the SSD has support for it. That seems like an extremely dangerous default to have, especially as the implementation is closed source in most (all?) cases.

But bitlocker itself is closed source. Why do you trust microsoft more than the disk vendor? Further, if I were going to choose an opaque blob to trust I would choose the one that has the smaller attack surface.

Because historically, hardware vendors have had pretty bad security, and are usually not getting reviewed. There's also many of them, which makes any specific one less likely to undergo review.

Meanwhile, BitLocker has received at least some level of review, it is the most common disk encryption product for Windows, and Microsoft can be reasonably expected, based on past experience, to put somewhat competent people on it.

Additionally, at least for parts of BitLocker, there is at least high-level documentation how it is supposed to behave (e.g. https://docs.microsoft.com/en-us/windows/security/informatio..., there may be more detailed documentation elsewhere), plus there is likely reverse-engineered research available confirming the basic functionality.

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#48

Post by pbarnes_1 »

wmf wrote: post #17
amarshall wrote: post #7

As far as I know, no other popular full-disk encryption (LUKS, geli, FileVault) delegates to the SSD’s hardware encryption (by default, anyway) as BitLocker apparently does [0]. Anyone know otherwise? [0]: https://docs.microsoft.com/en-us/previous-versions/windows/i...

Lots of enterprise SAN/NAS equipment uses SEDs, although one would hope those are actually secure considering how much they charge for it.

Yeah. Would love to see if a Toshiba PX04/PX05 with SED/SED FIPS is vulnerable. That's a very expensive add-on.

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#49

Post by PeterisP »

basilgohar wrote: post #41
xoa wrote: post #39

Earlier quoted context omitted.

> Transparency is a dependency of trust. I think you go too far here. Trust is a dynamic spectrum, not binary. Transparency is one potential avenue to add trust, but is neither necessary nor sufficient in most cases. Every instance must be evaluated in light of its specific details, threat scenarios, and available tradeoffs. > If you can't see how it works, then it's objectively impossible to trust it to do the right…

I did not read GP as saying it was a binary choice, but rather a prerequisite. That is to say, without transparency, there can be no trust, but you can also have no trust with transparency. For someone like me, who is somewhat technically competent, but not a security expert, openness means that names and figures I do trust have the chance to examine whatever I intend to use and comment on it, observe it, and make as…

"names and figures I do trust have the chance to examine whatever I intend to use and comment on it, observe it, and make assessments, including shaming poor implementations claiming traits they have no right to" does not necessarily require openness - third party audits, if done by people who you do trust, can do the same thing for closed systems, for example as described in the tptacek's comment https://news.ycombinator.com/item?id=18385507 above.

Re: Self-encrypting deception: weaknesses in the encryption of solid state drives [pdf]

#50

Post by wlll »

DyslexicAtheist wrote: post #2

"We have analyzed the hardware full-disk encryption of several SSDs by reverse engineering their firmware. In theory, the security guarantees offered by hardware encryption are similar to or better than software implementations. In reality, we found that many hardware implementations have critical security weaknesses, for many models allowing for complete recovery of the data without knowledge of any secret. BitLocke…

> we know how bad general code quality is in commercial vendor firmware, it's not surprising to see this

Quite. My experience of firmware is that it's usually total junk, from Internet connected web cams, to HTTP routers, to backplanes for NAS devices.

I was putting together a FreeNAS box for home a couple of months ago and this was the first time I'd seen drives with a self-encrypting ability. I ignored it and went for software encryption.

Post reply on HN