On 21.02.15 12:00, freebsd-security-requ...@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-requ...@freebsd.org > > You can reach the person managing the list at > freebsd-security-ow...@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 <leich...@lrw.com> > To: Henry Baker <hbak...@pipeline.com> > Cc: cypherpu...@cpunks.org, freebsd-security@freebsd.org, > cryptogra...@metzdowd.com, grarpamp <grarp...@gmail.com> > Subject: Re: [Cryptography] trojans in the firmware > Message-ID: <a8bd647b-0156-4da5-94f7-cf6ef4756...@lrw.com> > Content-Type: text/plain; charset=us-ascii > > On Feb 19, 2015, at 11:12 AM, Henry Baker <hbak...@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 <grarp...@gmail.com> > To: freebsd-security@freebsd.org > Subject: Re: [Cryptography] trojans in the firmware > Message-ID: > <CAD2Ti2_Wo9+FHz7qV_C-pyY+xyTxpbULWD=epasyvvv4jud...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Fri, Feb 20, 2015 at 4:50 PM, grarpamp <grarp...@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 <j...@callas.org> > To: Henry Baker <hbak...@pipeline.com> > Cc: cypherpu...@cpunks.org, freebsd-security@freebsd.org, > cryptogra...@metzdowd.com, Jon Callas <j...@callas.org>, grarpamp > <grarp...@gmail.com> > Subject: Re: [Cryptography] trojans in the firmware > Message-ID: <711b69eb-1cbf-4f03-9336-afebe0b85...@callas.org> > Content-Type: text/plain; charset=us-ascii > > > On Feb 19, 2015, at 8:12 AM, Henry Baker <hbak...@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 <grarp...@gmail.com> > To: freebsd-security@freebsd.org > Subject: Re: [Cryptography] trojans in the firmware > Message-ID: > <cad2ti2_cfb7jmj1a+5xyjerl6qastn6w_fham2v9xwt3vgt...@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...@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 <k...@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-unsubscr...@freebsd.org" > > ------------------------------ > > End of freebsd-security Digest, Vol 522, Issue 3 > ************************************************ > _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
