Date: Sat, 21 Feb 2015 14:41:57 +0100 From: Kay Rydyger <kay.rydyger@yahoo.co.uk> To: freebsd-security@freebsd.org Subject: Re: freebsd-security Digest, Vol 522, Issue 3 Message-ID: <20150221134157.GA23391@snowflake.fritz.box> In-Reply-To: <mailman.77.1424520002.92355.freebsd-security@freebsd.org> References: <mailman.77.1424520002.92355.freebsd-security@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21.02.15 12:00, freebsd-security-request@freebsd.org wrote: > Send freebsd-security mailing list submissions to > freebsd-security@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@freebsd.org > > You can reach the person managing the list at > freebsd-security-owner@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@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> > Content-Type: text/plain; charset=us-ascii > > 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 > > > > ------------------------------ > > Message: 2 > Date: Fri, 20 Feb 2015 17:12:57 -0500 > From: grarpamp <grarpamp@gmail.com> > To: freebsd-security@freebsd.org > Subject: Re: [Cryptography] trojans in the firmware > Message-ID: > <CAD2Ti2_Wo9+FHz7qV_C-pyY+xyTxpbULWD=EpaSyvvV4judJ-Q@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Fri, Feb 20, 2015 at 4:50 PM, grarpamp <grarpamp@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@callas.org> > To: Henry Baker <hbaker1@pipeline.com> > Cc: cypherpunks@cpunks.org, freebsd-security@freebsd.org, > cryptography@metzdowd.com, Jon Callas <jon@callas.org>, grarpamp > <grarpamp@gmail.com> > Subject: Re: [Cryptography] trojans in the firmware > Message-ID: <711B69EB-1CBF-4F03-9336-AFEBE0B857A0@callas.org> > Content-Type: text/plain; charset=us-ascii > > > On Feb 19, 2015, at 8: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. > > > > 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@gmail.com> > To: freebsd-security@freebsd.org > Subject: Re: [Cryptography] trojans in the firmware > Message-ID: > <CAD2Ti2_CFB7JmJ1a+5XYjeRL6qASTN6w_FHam2v9xwT3VGtdDQ@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@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@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > > ------------------------------ > > End of freebsd-security Digest, Vol 522, Issue 3 > ************************************************ >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150221134157.GA23391>