Date: Fri, 20 Feb 2015 06:19:55 -0500 From: Jerry Leichter <leichter@lrw.com> To: Henry Baker <hbaker1@pipeline.com> Cc: cypherpunks@cpunks.org, freebsd-security@freebsd.org, cryptography@metzdowd.com, grarpamp <grarpamp@gmail.com> Subject: Re: [Cryptography] trojans in the firmware Message-ID: <A8BD647B-0156-4DA5-94F7-CF6EF4756044@lrw.com> In-Reply-To: <E1YOTjj-0004uI-59@elasmtp-mealy.atl.sa.earthlink.net> References: <E1YNSQU-0004pW-Oh@elasmtp-kukur.atl.sa.earthlink.net> <E3B30770-BB81-47F1-895D-14CF7FCFC0BE@lrw.com> <54E2B04C.9080707@av8n.com> <E1YNuOT-0004uN-CV@elasmtp-mealy.atl.sa.earthlink.net> <54E436FB.9000709@deadhat.com> <CAAMy4USCzQDO=k3yhZ_LVb4ivz4k5qTCasm3KCen%2By1yi8oa%2Bw@mail.gmail.com> <CAD2Ti29bD6f7tTq=FgGQDXD43C%2BzTW0fOWYrbCeTCBmiu0bBqA@mail.gmail.com> <E1YOGNA-0004BG-UT@elasmtp-banded.atl.sa.earthlink.net> <E1YOTjj-0004uI-59@elasmtp-mealy.atl.sa.earthlink.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 19, 2015, at 11:12 AM, Henry Baker <hbaker1@pipeline.com> wrote:
> I would love to be able to program this device myself, instead of =
relying on Samsung's firmware.
Good luck with that. SSD performance and even proper operation is still =
somewhat of a black art; much of the value of the device comes from the =
proprietary algorithms that control it, which are build knowing details =
of the design. Samsung, like other SSD makers, has every reason to keep =
that stuff secret. The market advantage of increments in speed and =
other features is significant; the market to people who want to program =
it themselves is essentially non-existent.
> BTW, what's the point of AES encryption on this pre-p0wned device? =
More security theatre?
It depends on the implementation and what kind of attacker you're =
considering. There have been implementations in the past which use =
simply match a password stored in the device - encrypted with AES so =
that the advertising claims aren't outright lies - against a password =
entered at boot; the data itself was left unencrypted. But there's =
plenty of power in a device like this to essentially build FDE right =
into the SSD. That's probably proof against any attack against a =
stolen/seized SSD. (Of course, Samsung may have deliberately, or =
through incompetence, provided a back door - we'd never know. But most =
attackers wouldn't know either. I'm sure North Korea would *assume* =
that the South Korean intelligence services have access, whether it's =
true or not.)
Low-enough level attacks against the boot sequence could intercept and =
leak the password. The OS typically would come in way too late to see =
the password - but of course if you take it over, you have full access =
to the device.
In summary: Assuming a decent implementation and no back doors =
available to the attackers of interest to you, this has exactly the =
strengths and weaknesses of FDE, with no overhead in the host. Not =
really security theatre, but given modern hardware, perhaps not much of =
an advantage either. You could go for defense in depth by using FDE on =
top of what the device provides.
-- Jerry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A8BD647B-0156-4DA5-94F7-CF6EF4756044>