
“We cannot trust” Intel and Via’s chip-based crypto, FreeBSD developers say - robin_reala
http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and-vias-chip-based-crypto-freebsd-developers-say/
======
ctz
It was _always_ the right answer to feed all available entropy sources
(irrespective of previous laundering -- eg. Intel RDRAND gets laundered
through the SP800-90 AES-CTR_DRBG internally) into a decent CSPRNG. Feeding
multiple entropy sources of different qualities, speeds or backdooredness
cannot (by construction) _decrease_ the entropy of the output (it can,
obviously, fail to increase it -- say if your ring oscillator got stuck in a
fixed bit pattern like the Taiwanese smartcards).

Yarrow and Fortuna are examples of decent CSPRNGs, so I'd say this is a pretty
good move by FreeBSD.

~~~
Peaker
If the RNG instructions are malicious, they can reduce entropy, by for example
XOR'ing into the result previous register values that held the previous
entropy source values.

~~~
ars_technician
Sorry, that's not how entropy works with XOR.

If you do not know one of the inputs to an XOR, you know nothing about the
output.

XORing random sources is great because it acts as a minimum function for
entropy of all of the sources. As long as you have just one good source, the
output is good.

~~~
gefh
The processor could recognize that it is in common key generation code, and
generate 'entropy' that precisely reverses most of the existing entropy. The
existing 'good' entropy could be known by the hardware PRNG.

~~~
tedunangst
The processor can also just write whatever it wants into the memory containing
the entropy pool even if you never call the RDRAND instruction.

~~~
dragontamer
Checkmate.

Good call on this. If you can't trust the CPU you're running on, you can't
trust anything at all. The proper solution is to find a supplier you trust and
go with them.

Pulling useful entropy away from the OS's RNG functions is the best example of
an ignorant knee-jerk reaction to this security problem.

~~~
ars_technician
It's not checkmate. It's a completely unreasonable threat model. How would the
processor know where the entropy pool used by the operating system is?

How would the processor even know it's performing crypto operations that it
should swap numbers for?

~~~
tedunangst
Presumably using the same skynet tech it uses to look ahead and see where the
rdrand is going to be xored into. I'm less familiar with precisely how linux
does it, but it's not as simple as "newsecret = oldsecret ^ rdrand". The bits
are scattered all to hell.

Building a "where will this rdrand go?" backdoor is _harder_ than building a
backdoor that just trawls through load addresses for various common kernels
looking for the symbol table so it can poison the entropy directly.

~~~
ars_technician
Do you realize how much of a performance hit modern desktops would take if a
processor that had to freeze the operating system while it wandered through
memory first identifying the operating system and then finding the entropy
pool and modifying it?

>Presumably using the same skynet tech it uses to look ahead and see where the
rdrand is going to be xored into.

There is no such tech. That's why this is not 'checkmate'. A poisoned random
number that generates numbers in a predictable manner is orders of magnitude
easier to implement and less possible to detect than a magical processor that
changes memory it thinks might be entropy for some operating systems it has
been pre-programmed to look for under the assumption that kernel will never
change ever. Get real.

~~~
tedunangst
I think you have misinterpreted my comments as arguments for the backdoor that
I am attempting to dismiss.

------
kkielhofner
I've been working with this project for some time:

[https://github.com/pwarren/rtl-entropy](https://github.com/pwarren/rtl-
entropy)

Quite a bit of entropy using radio noise and a $15 RTL-SDR USB dongle. Still
could use some work and review but seems like the start to an almost ideal
solution.

~~~
IgorPartola
I wonder how hard it is to build something like that using the mic input. Or
perhaps measuring the noise on a spare 802.11 card. I know in general it is
not easy to add a kernel facility that will be widely available, but how hard
is it to build a physical RNG if your specific case demands high entropy and
you do not want/need a commercial product?

~~~
hdevalence
There is already a project whose name sadly escapes me that does this, using
information theory to derive lower bounds on the number of bits of entropy in
data read from a line-in jack.

EDIT: I'm thinking of Turbid:
[http://www.av8n.com/turbid/paper/turbid.htm](http://www.av8n.com/turbid/paper/turbid.htm)

EDIT2: There's also a wealth of information in this thread from the metzdowd
cryptography mailing list:
[http://www.metzdowd.com/pipermail/cryptography/2013-Septembe...](http://www.metzdowd.com/pipermail/cryptography/2013-September/017572.html)

~~~
BuildTheRobots
is it VanHeusden's audio_entropyd? [1]

They also provide a timer and video based entropy daemons too.

[1] [http://www.vanheusden.com/aed/](http://www.vanheusden.com/aed/)

------
dangero
Hmm I've been having similar concerns about the Windows rand_s function. Every
Windows application including every modern browser relies on rand_s for secure
random number generation but obviously the function is completely closed
source. Seems like a perfect target for the NSA.

~~~
tptacek
Closed source isn't a significant obstacle to understanding code, and
Microsoft's code is the most comprehensively reverse-engineered in the
industry. It would be extremely stupid to hide a backdoor in binaries that
Microsoft ships.

~~~
pnathan
Calling attention to this: disassembly is a thing. It is entirely possible to
reconstruct a program's design and logic from the disassembled code. This is
what software crackers and antivirus writers do on a regular basis. For an
enlightening write-up, see the Symantec paper(s) on Stuxnet.

~~~
forgottenpaswrd
"This is what software crackers and antivirus writers do on a regular basis.
For an enlightening write-up, see the Symantec paper(s) on Stuxnet."

Well, not really.

I was both software cracker and virus writer myself(just for fun, we never
distributed our virus or our cracks, keygens and stuff outside).

I was part of a larger group doing it. I had contacts with people that became
famous for breaking several important protections, specially for games.

You have no idea how big software is. A million lines of code is impossible to
read by any human being in his entire life. Yes, there are automatic tools and
great disassemblers like IDA pro, but even if you were to see the entire
source code, it is very easy to hide some flaw into the code.

If you add undocumented hardware into the equation, then it is very hard to
disassemble without significant resources.

This hardware took dozens of millions of dollars to develop, hundreds of very
smart people to design, with all the documentation. It will take at least an
order of magnitude more to decode not having that info.

~~~
tptacek
I don't know when you were a virus writer (the heyday of the virus writers I
knew was the mid-1990s, and the virus writers I was aware of post-2000 had
more knowledge of WinAPI than of x86), but: the state of the art for
disassembly and reverse engineering has progressed dramatically in the past 10
years.

In particular, reverse engineering is no longer the specialty of virus authors
the way it used to be; a totally mainstream application of reverse
engineering, practiced by most major security companies, is reverse
engineering patches to find the underlying security flaws they fix so they can
be weaponized.

It is easy to hide flaws in any code. Assembly doesn't make it much easier.

~~~
dr_doom
Can you expand on or point to a write up on reverse engineering patches?

Do you mean that reversers' try to locate the, say, buffer overflow that was
fixed and try to find another way to exploit it? Why would major companies
want to do this?

~~~
m0nastic
The earliest talk I ever saw on automated binary reverse engineering was this
one: [http://www.blackhat.com/presentations/win-usa-04/bh-
win-04-f...](http://www.blackhat.com/presentations/win-usa-04/bh-
win-04-flake.pdf)

I actually didn't see the BH talk, but I saw a similar talk that Halvar gave
at CanSecWest shortly after.

The gist of it is, imagine that you have a binary that you are looking to find
vulnerabilities in to exploit. You can go through all the trouble of
discovering a vulnerability, and then hope it doesn't get patched; or you can
sit and wait for a patch for said binary. There's reams of data out there
about how long it takes for systems to apply patches, but in general, you can
find vulnerable versions of patched software long after the patch has been
released.

Using binary differential analysis you are basically zeroing in on the parts
that were changed (which you can imagine is a much smaller subset of the
overall binary) and find the vulnerability much more quickly.

There are tools (there is/was a product called Bindiff that I don't know if
Zynamics still sells after they got bought by Google), which help you do this
in a more automated fashion.

That means that with much less work, you can write up a working exploit that
will still work on some decent percentage of the install base for the
application (until everyone patches it).

Additionally, you can imagine that a lot of times when vulnerabilities get
fixed, they aren't necessarily fixed with the utmost rigor. There's a lot of
cases where an individual vulnerability might be fixed, but if you look at
what was done, you can find other parts of the binary that are vulnerable to
the same underlying flaw. Knowing what gets changed in the patch can tell you
a lot about underlying issues.

------
nightcracker
I warned against this in July:
[http://crypto.stackexchange.com/questions/9210/technical-
fea...](http://crypto.stackexchange.com/questions/9210/technical-feasibility-
of-decrypting-https-by-replacing-the-computers-prng/9212#9212)

------
polarix
Have people talked about using sensor device input as prng seeds? onboard
microphone, fan speed jitter, etc?

~~~
__alexs
Yes. People have even experimented with using CPU specific instabilities in
certain operations to extract entropy.

[http://www.irisa.fr/caps/projects/hipsor/misc.php#exectime](http://www.irisa.fr/caps/projects/hipsor/misc.php#exectime)

The problem with such systems is that is generally quite difficult to have
confidence that they are not subject to attacks that may starve the system of
entropy or trick the entropy estimator into thinking it has any when it has
none.

Low-level hardware RNGs can be constructed in ways that make them quite
difficult to attack externally, but are also basically impossible for us to
verify.

Really it seems that the best approach is to take a wide range of flexible
entropy sources and to learn to trust our mixing pools and trapdoor functions.

~~~
wtbob
> The problem with such systems is that is generally quite difficult to have
> confidence that they are not subject to attacks that may starve the system
> of entropy or trick the entropy estimator into thinking it has any when it
> has none.

That's why you give up on estimating entropy. It's just not possible in the
general case.

Mix multiple sources of potential entropy in a secure fashion (e.g. with a
crypographically-secure hashing function). Recover over time from a
compromise.

> Really it seems that the best approach is to take a wide range of flexible
> entropy sources and to learn to trust our mixing pools and trapdoor
> functions.

Yup, you're exactly right. Now we just need to convince Ted T'so to replace
Linux's hacky /dev/random with a Fortuna-based one.

~~~
__alexs
You need some degree of entropy estimation at initialisation time or early
boot numbers are predictable.

------
ris
This coming from a BSD distribution that ships binary blob device drivers.

~~~
tachion
Yes, and?

~~~
matthewmacleod
The point was obviously that it's surprising to see that they are happy to
ship binary drivers (which could contain arbitrary compromises from a user's
point of view) but are not willing to trust the HWRNG (to which the same
caveat applies).

Of course, I don't agree with this comparison; running the output of the HWRNG
through Yarrow is good practice in any case.

~~~
AnthonyMouse
What's the problem with the comparison? The only real advantage of the binary
blob over the hardware is that you can theoretically verify what it's doing
more easily. But actually doing that verification has a difficulty on the same
order as reverse engineering the driver to release an open source version, so
all the existence of the binary driver does is to imply that such verification
_hasn 't_ occurred -- because if it had then those doing the verification
would have been in a good position to release source code (or at least
complete hardware documentation) for an open source driver.

Binary blob software also has the distinct disadvantage that even if you were
to verify it, you would have to verify each release again whenever there is an
update.

~~~
tachion
In my perspective, binary drives are a matter of choice, you can use them, but
you dont have to, if you dont want to, whereas the random numbers generation
is used everywhere in the OS, and you cant just decide to not to use it -
that's a huge difference, what makes this comparison bad.

~~~
AnthonyMouse
Can't you though? We're really talking about defaults here. If you don't want
to use the hardware RNG, you can always disable it in either the BIOS or the
OS. Or use hardware that doesn't have one. The trouble is for the common user
who doesn't know anything about any of this and is just going to take the
defaults for everything, who is exactly the sort of person who is going to
take the binary driver to "just make it work" and then be exposed to any
vulnerabilities it may contain.

You have to make the defaults secure because they're what most people will
use. It doesn't matter that you can change it if most people never do.

------
ape4
Where are the Intel and Via random instructions supposed to be getting their
entropy?

Edit: thanks for the interesting replies!

~~~
jbri
In theory? Quantum and thermal effects inside an unstable configuration of
transistors.

The simple example is a basic SR latch (two NOR gates, where the output of one
gate feeds one of the inputs of the other, and vice versa), where you start
things off by applying a signal to both S and R. When you remove the signals,
the latch will eventually fall back into one of the two stable states - but
which state it ends up in is random.

So you can easily produce a stream of bits from a potentially-biased random
source, and then do some deterministic massaging of that stream to produced an
unbiased stream of random bits.

------
salient
Sounds like a good move to me. Intel has been awfully quiet about this.

~~~
jrockway
Not to accuse Intel, because I have no idea whether or not they have
backdoors, but do you want them to say: "Yes, we intentionally sold faulty
products that put all your customer data at risk, and you at risk of a lawsuit
for not protecting your customers' data."

Not so good for the share price, methinks.

~~~
numbsafari
Makes me wonder, though... if the government forces intel to sell everyone
defective products does that violate our 4th amendment rights? Do I, as an
individual, have standing to sue the federal government because they
intentionally weakened a product I purchased, potentially exposing me to other
kinds of threats?

What about someone who has actually been victimized by an exploit of a
backdoor that was ordered installed by the government? Would they have
standing to sue for damages that resulted?

I only ask because I know "standing" has been an important issue in many of
the cases related to these abuses. Most of the suits have failed because the
plaintiffs were found to lack standing for one reason or another.

~~~
jrockway
No. In general, you may only sue the federal government when the federal
government gives you permission to sue them.

[http://en.wikipedia.org/wiki/Sovereign_immunity_in_the_Unite...](http://en.wikipedia.org/wiki/Sovereign_immunity_in_the_United_States#Federal_sovereign_immunity)

~~~
protomyth
You can file a lawsuit saying your rights were violated (the ACLU has done it
multiple times). You can also sue under The Federal Tort Claims Act ("FTCA").
The Federal Government is not immune from rights violations.

------
lifeisstillgood
I used to work for an online gaming company (legal in the UK) - and they
basically used the on server chips (as opposed to quantum RNG) - and was not
unusual in the industry. which _may_ lead to weaker randomness and so an
exploit for scamming. It's just that the validation tests were to simulate a
few million rolls of the dice and see if the graph came out right.

~~~
Flenser
Is that a good validation test though? I'd have thought that if I programmed
it to have a 50/50 chance that it would repeat the previous roll the graph
would look about the same. i.e. half a million rolls look about the same as a
million.

Edit: which is to say that I thought the issue wasn't that the Intel/via
chip's random number generators wouldn't look random in aggregate over lots of
uses, but that people are concerned that there could be exploitable patterns
in short sequences.

------
RamiK
There is a(n expensive) solution:

[https://en.wikipedia.org/wiki/Hardware_random_number_generat...](https://en.wikipedia.org/wiki/Hardware_random_number_generator)

[https://en.wikipedia.org/wiki/Comparison_of_hardware_random_...](https://en.wikipedia.org/wiki/Comparison_of_hardware_random_number_generators)

~~~
simias
Not a solution to the particular issue of trusting HW PRNG unless you can
audit the innards of this particular hardware.

Maybe an opensource FPGA-based solution might do the trick if you really need
high-quality highly-secure fast random number generation.

Personally when I've needed good and fast sources of entropy I've just picked
a good (but slow) random number source and used it as a key for a strong
stream cipher (that I would renew every megabit or so). Assuming there are no
weaknesses in the cipher and you have hardware acceleration you can get a very
fast PRNG source.

And unlike RDRAND you can actually audit the hardware cipher implementation
because it behaves deterministically.

------
pja
mhoye points to the notes from the FreeBSD summit on his Twitter feed. The
notes from the security sessions are here:
[https://wiki.freebsd.org/201309DevSummit/Security](https://wiki.freebsd.org/201309DevSummit/Security)

Key quote: "rdrand in ivbridge not implemented by Intel."

~~~
tedunangst
You're referring to errata BV54?

~~~
pja
No, that's just a failure to set the relevant property bit in the CPU at
startup, so despite the RDRAND instruction being present it won't actually run
on those CPUs.

It's well known that the Intel RDRAND implementation uses a hardware entropy
source to seed a software RNG implemented directly in the CPU. The _suspicion_
is that said CSRNG could be using an elliptic curve CSRNG to carry out the
final mixing where the NSA has chosen both the curve and the points on the
curve. It's impossible to tell from the outside whether this is the case or
not - such an implementation would still pass all known randomness tests.
However, if the curve points have been carefully chosen then you can derive
the internal state of the RNG from the output and thus both predict future
values (until the hardware entropy source re-seeds the generator, if it
actually does that at all) and derive past ones (up to the last re-seed).

It's been said elsewhere that using an elliptic curve CSRNG where the NSA has
chosen the curve points is effectively equivalent to doing the second half of
a Diffie-Hellman exchange with the NSA to securely communicate your RNG state
to them. For cryptographic algorithms that depend upon a secure RNG source
this is devastating. All communications that use such are source are
transparent to the NSA. (The NSA crypto geeks must have thought this was a
fantastic trick: the communication would remain completely secure against all
other third parties because deriving the magic numbers that let you decrypt
the output from the public curve points is next to impossible - it's the
discrete logarithm problem in action.)

~~~
tedunangst
I don't understand how what you just wrote relates to your key quote: "rdrand
in ivbridge not implemented by Intel."

~~~
pja
I'm not sure how I can explain it any more clearly!

If that note is true, then crucial details of the RDRAND specification in
Intel CPUs were supplied by someone other than Intel.

Who's most likely to want to push for a particular implementation to their own
enormous potential advantage? The NSA. Who has prior history of doing
_exactly_ this to a random number generator standard? The NSA. Do we know that
the NSA influenced the Intel RDRAND implementation in these ways? No. Did they
have both motive & opportunity? Absolutely, yes they did.

Which is why a concrete reference for that note would be good: if someone can
point to the place in the public record where Intel admitted that they were
not solely responsible for the RDRAND implementation then that's a fairly big
deal & a brief sentence in someone's conference notes isn't good enough.

~~~
tedunangst
Obvious follow up question: who implemented rdrand for haswell? The
identification of ivy bridge seems oddly specific if they're not referring to
the erratum.

------
codex
Even if you could trust these RNGs, it is possible that they will malfunction
at any time through a manufacturing defect or thermal issue. Blindly trusting
hardware is naive. Linux never did, and decisions like this make me less
likely to ever use BSD again. The critical mass of talent is just not there.

~~~
astrange
It seems unlikely that a manufacturing issue could affect the RDRAND
instruction and not any other part of the CPU.

------
UNIXgod
This on AMD chips as well? Since it's BSD we can just have an option to turn
it off.

~~~
zxcdw
As far as I am aware there are no instructions for AMD CPUs to generate random
numbers thus far, although Wikipedia mentions that their upcoming
Excavator(scheduled for a 2015 release) architecture includes support for
Intel's RDRAND.

------
timbro
> the NSA and its British counterpart defeat encryption technologies by
> working with chipmakers to insert backdoors, or cryptographic weaknesses, in
> their products.

I had already started to forget about that...

From that other report (september):

> They reveal a highly classified program codenamed Bullrun, which according
> to the reports relied on a combination of "supercomputers, technical
> trickery, court orders, and behind-the-scenes persuasion" to undermine basic
> staples of Internet privacy, including virtual private networks (VPNs) and
> the widely used secure sockets layer (SSL) and transport layer security
> (TLS) protocols.

------
gnu8
If I recall correctly, Linus refused to make this change in Linux, denouncing
it as paranoia.

My fear is that the extra complexity adds additional opportunity for a back
door to be inserted. However, software can be audited, the hardware cannot be.

~~~
masklinn
No, Linus has refused to make a different change in Linux (the complete
removal of RDRAND) because linux does not directly use RDRAND output, and _it
already_ uses RDRAND as an other source of entropy[-1], which is what FreeBSD
is moving towards.

According to Theodore Ts'o, there was pressure from Intel engineers to rely
solely on RDRAND but they were rejected[0], it looks like the FreeBSD devs did
do it and have /dev/random using RDRAND/Padlock directly[1]

[-1] although — and I don't know why — the linux rng XORs pool output with
RDRAND output instead of feeding RDRAND into the entropy pool itself[3]

[0]
[https://plus.google.com/+TheodoreTso/posts/SDcoemc9V3J#+Theo...](https://plus.google.com/+TheodoreTso/posts/SDcoemc9V3J#+TheodoreTso/posts/SDcoemc9V3J)

[1] That's the only way I can interpret "for 10, we are going to backtrack and
remove RDRAND and Padlock backends and feed them into Yarrow instead of
delivering their output directly to /dev/random"[2] anyway

[2]
[http://www.freebsd.org/news/status/report-2013-09-devsummit....](http://www.freebsd.org/news/status/report-2013-09-devsummit.html#Security)

[3] I'll try to stop now but[4] provides a rationale for it: a history of
unnoticed bugs in the random pool making the risk of a trivial xor lower as
far as kernel devs are concerned: if you xor a known A and an unknown B, you
can't know anything about the output (it won't be any more known than B is),
whereas if you know of bugs in the random pool you might be able to take
advantage of them and skew the output. Make of that what you will.

[4]
[http://thread.gmane.org/gmane.linux.kernel/1323386/focus=133...](http://thread.gmane.org/gmane.linux.kernel/1323386/focus=1332780)

~~~
acqq
The last time I've followed, RDRAND was _not_ "just another source" in Linux,
as it was xored after another sources were "fully" mixed.

~~~
masklinn
Yes, I had modified my comment to make note of that. Although I tuned the
language a bit more (removed the "just" of "just an other source")

------
noir_lord
I think which Linux distro you use should be like religion and politics should
be a personal matter ;).

That said I am a Mint XFCE user and have been back to 13 (before that Gnome 2)
every release has been brilliant I run it on everything from an ancient
ThinkPad to a thoroughly modern development machine and it has worked well.

It's also the only WM/DE that handles multiple screens (3 on both desktops and
2 on Dell/External) without any show stopping/tremendously irritating bugs
couple that with the huge amount of software available via Debian/Ubuntu and
PPA's and it's a cracking developer OS.

~~~
leokun
The original post is neither about Linux nor bragging about what you use. It's
about the RNG in FreeBSD which is not a Linux distro

~~~
noir_lord
Heh, Posted the comment in the wrong thread, downvotes are fair enough.

