[FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-14:01.random

[Edward Tomasz Napierała]

Wiadomość napisana przez Alan Somers w dniu 15 sty 2014, o godz. 20:25:
> On Wed, Jan 15, 2014 at 11:53 AM, Darren Pilgrim
> <list_freebsd at bluerosetech.com> wrote:
>> On 1/15/2014 10:39 AM, Mike Tancsa wrote:
>>> 
>>> On 1/15/2014 12:04 PM, Darren Pilgrim wrote:
>>>> 
>>>> 
>>>> 1. If you're on "bare metal", the attacker has firmware-level or
>>>> physical access to the machine;
>>>> 2. If you're on a hypervisor, you can't trust the hypervisor;
>>>> 
>>>> In both cases, I would think the attacker can use much simpler, more
>>>> direct vectors and you have much worse things to worry about than the
>>>> quality of /dev/random.  I'm not questioning the validity of the
>>>> advisory, I'm genuinely curious about this.  I can't think of a scenario
>>>> were someone could attack /dev/random using this vector without 1 or 2
>>>> above also being true.
>>> 
>>> 
>>> Say you have a physical tap on the network upstream from the victim. The
>>> victim is exchanging data across a VPN. You can capture the encrypted
>>> traffic, and knowing there is a weakness in the quality of RNG, more
>>> easily decode the encrypted traffic.  You dont have to worry about
>>> sending "extra" traffic from the host say, by poking around in /dev/mem
>>> etc.
>> 
>> 
>> Yes, that's an obvious consequence of a compromised RNG; but that's not what
>> I was asking.  I'm asking how the attacker could compromise the hardware RNG
>> without also obtaining effectively unfettered access to the entire system.
> 
> By compromising it at the design stage.  For example, the NSA could
> hypothetically collaborate with Intel to trojan Intel's RNG.  In that
> case, the NSA would've compromised the RNG, but they wouldn't have
> unfettered access to the rest of the system.

Also this: http://people.umass.edu/gbecker/BeckerChes13.pdf

"In this paper, we will therefore focus on Trojans inserted into designs
at the layout level, after the place & route phase. [..] By using two case
studies, a side-channel resistant SBox implementation and an implementation
of a secure digital random number post-processing design derived from Intel's
new RNG used in the Ivy Bridge processors, we prove that the proposed
dopant-based Trojans can be used eciently in practice to compromise
the security".

Might not apply to Intel, since it has its own fabs, but e.g. AMD doesn't.

-- 
If you cut off my head, what would I say?  Me and my head, or me and my body?