On 21.02.15 12:00, freebsd-security-request at freebsd.org
wrote:> Send freebsd-security mailing list submissions to
> freebsd-security at freebsd.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> or, via email, send a message with subject or body 'help' to
> freebsd-security-request at freebsd.org
>
> You can reach the person managing the list at
> freebsd-security-owner at freebsd.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of freebsd-security digest..."
>
>
> Today's Topics:
>
> 1. Re: [Cryptography] trojans in the firmware (Jerry Leichter)
> 2. Re: [Cryptography] trojans in the firmware (grarpamp)
> 3. Re: [Cryptography] trojans in the firmware (Jon Callas)
> 4. Re: [Cryptography] trojans in the firmware (grarpamp)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 20 Feb 2015 06:19:55 -0500
> From: Jerry Leichter <leichter at lrw.com>
> To: Henry Baker <hbaker1 at pipeline.com>
> Cc: cypherpunks at cpunks.org, freebsd-security at freebsd.org,
> cryptography at metzdowd.com, grarpamp <grarpamp at gmail.com>
> Subject: Re: [Cryptography] trojans in the firmware
> Message-ID: <A8BD647B-0156-4DA5-94F7-CF6EF4756044 at lrw.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Feb 19, 2015, at 11:12 AM, Henry Baker <hbaker1 at 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
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 20 Feb 2015 17:12:57 -0500
> From: grarpamp <grarpamp at gmail.com>
> To: freebsd-security at freebsd.org
> Subject: Re: [Cryptography] trojans in the firmware
> Message-ID:
> <CAD2Ti2_Wo9+FHz7qV_C-pyY+xyTxpbULWD=EpaSyvvV4judJ-Q at
mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Fri, Feb 20, 2015 at 4:50 PM, grarpamp <grarpamp at gmail.com>
wrote:
> > These for starters, then all the public hacker malware versions of
> > the same thing both extant and coming...
>
> Note the explicit references to FreeBSD and UFS in those links.
> Linux and EXT FS as well. These OS are not immune to 0-day
> and other exploits. Multiple defenses are always useful..
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 20 Feb 2015 14:36:55 -0800
> From: Jon Callas <jon at callas.org>
> To: Henry Baker <hbaker1 at pipeline.com>
> Cc: cypherpunks at cpunks.org, freebsd-security at freebsd.org,
> cryptography at metzdowd.com, Jon Callas <jon at callas.org>,
grarpamp
> <grarpamp at gmail.com>
> Subject: Re: [Cryptography] trojans in the firmware
> Message-ID: <711B69EB-1CBF-4F03-9336-AFEBE0B857A0 at callas.org>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Feb 19, 2015, at 8:12 AM, Henry Baker <hbaker1 at pipeline.com>
wrote:
>
> > I would love to be able to program this device myself, instead of
relying on Samsung's firmware.
> >
> > BTW, what's the point of AES encryption on this pre-p0wned device?
More security theatre?
>
> NAND memory runs faster when the hamming weight of the data is
approximately even between zeroes and ones. You can speed up NAND flash by
running the data through a suitable whitening function.
>
> AES is a great whitening function. If you then go to the extra effort to do
key management, you have security. It's a simple matter of architecture and
programming. :)
>
> Jon
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 20 Feb 2015 20:26:35 -0500
> From: grarpamp <grarpamp at gmail.com>
> To: freebsd-security at freebsd.org
> Subject: Re: [Cryptography] trojans in the firmware
> Message-ID:
> <CAD2Ti2_CFB7JmJ1a+5XYjeRL6qASTN6w_FHam2v9xwT3VGtdDQ at
mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> These were the links I was referring to that
> never made it past moderation/spam...
>
> > Alfred Hegemeier <molybdanstahl-hh at yahoo.co.uk> saith:
> > just encrypt the whole hard drive with Geli.
>
> GELI works under your control for what you store on the
> drive, and you can even enable the AES encryption feature
> of the drive itself as a no cost to performance extra freebie
> underneath that. However since the raw device interface is still
> accessible, neither of them do anything to block firmware
> updates.
what has blocking firmware updates to do with
firmware being able to read the data passing
through the controller ?
That encryption is a good line of defense, you can
read here:
https://www.ibr.cs.tu-bs.de/users/kurmus/papers/acsac13.pdf
in section 4.1.
>
>
>
> > Karl Denninger <karl at denninger.net> saith:
> > 1. The BIOS (which reads the boot sector) has not been compromised.
> > 2. Once the drive code has been tampered with
>
> These cases were addressed earlier...
>
> "
> Obviously. This is only meant to help protect clean
> systems, or prevent subsequent malicious commands if
> they happen to go through a user to firmware path that has
> for some reason not yet been compromised (say through
> the usual /dev to driver to hardware path).
>
> In all cases, having the logging capability for non production
> opcodes without having to postfilter them out of some
> debugging stream would be nice. Obviously again caveat
> parts of the system that have not been compromised.
> "
>
> > how many of these attacks are going to be loaded into your machine
> > through a _*running*_ modern BSD-style system?
>
> These for starters, then all the public hacker malware versions of
> the same thing both extant and coming...
>
> https://www.schneier.com/blog/archives/2014/01/iratemonk_nsa_e.html
> http://leaksource.files.wordpress.com/2013/12/nsa-ant-iratemonk.jpg
> https://www.schneier.com/blog/archives/2014/02/swap_nsa_exploi.html
> http://leaksource.files.wordpress.com/2013/12/nsa-ant-swap.jpg
> http://leaksource.files.wordpress.com/2013/12/nsa-ant-sierramontana.jpg
>
http://25zbkz3k00wn2tp5092n6di7b5k.wpengine.netdna-cdn.com/files/2015/02/Equation_group_questions_and_answers.pdf
>
> > I suspect the answer is
> > "few" and a false sense of security is worse than none at
all.
>
> Defense in depth is not a false defense, even when thrown at the few.
> Given a clean system, the ability to block these opcodes would
> seem defensive.
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> freebsd-security at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe at
freebsd.org"
>
> ------------------------------
>
> End of freebsd-security Digest, Vol 522, Issue 3
> ************************************************
>