[Cryptography] Fwd: [IP] 'We cannot trust' Intel and Via's chip-based crypto, FreeBSD developers say

[Theodore Ts'o]

On Thu, Dec 19, 2013 at 07:42:30AM -0500, Jerry Leichter wrote:
> On Dec 18, 2013, at 2:46 AM, ianG wrote:
> 
> If you don't like the idea of mixing RDRAND into the pool rather
> than XOR'ing it at the end, an easy fix is to move the RDRAND
> instruction to any point before the value that the existing RNG will
> output has been computed, save the value in memory, then read it and
> XOR it in at the end.  This will produce exactly the output you are
> getting today, at the additional cost of one memory read and write,
> but puts a spiked RDRAND implementation in the position where it
> cannot determine what value its output will be combined with.
> (Well, if you believe the "spike" can extend to keeping track of the
> memory location where the RDRAND value went and later modifying what
> a memory->register transfer or an XOR does based on a recent read of
> that location ... what can I say.)  -- Jerry

You have to do something very close to this already given how modern
CPU's handle register renaming, out of order execution, speculative
execution, etc.  You can do anything at all, including scanning the
instruction sequences for crypto algorithms and then finding secret
ways to exfiltrate the data via various covert channels (and since
modern computers tend to use chipsets where the wired and wireless
ethernet also come from Intel, if you assume that level of complete
control, you really, REALLY, should be building your own computer out
of TTL chips).

What I've done instead will hopefully finally put this issue to bed,
except for those people who belive that since the NSA authored SHA-1,
they clearly would have anticipated the use of SHA-1 with RDRAND two
decades ago, when SHA-1 has been authored, and put a backdoor into
SHA-1...

							- Ted

commit a9f069e38cc36d6c4ab3c831bc4bef2ae1a16e96
Author: Theodore Ts'o <tytso at mit.edu>
Date:   Tue Dec 17 21:16:39 2013 -0500

    random: use the architectural HWRNG for the SHA's IV in extract_buf()
    
    To help assuage the fears of those who think the NSA can introduce a
    massive hack into the instruction decode and out of order execution
    engine in the CPU without hundreds of Intel engineers knowing about
    it (only one of which woud need to have the conscience and courage of
    Edward Snowden to spill the beans to the public), use the HWRNG to
    initialize the SHA starting value, instead of xor'ing it in
    afterwards.
    
    Signed-off-by: "Theodore Ts'o" <tytso at mit.edu>

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 8cc7d65..d07575c 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1012,23 +1012,23 @@ static void extract_buf(struct entropy_store *r, __u8 *out)
 	__u8 extract[64];
 	unsigned long flags;
 
-	/* Generate a hash across the pool, 16 words (512 bits) at a time */
-	sha_init(hash.w);
-	spin_lock_irqsave(&r->lock, flags);
-	for (i = 0; i < r->poolinfo->poolwords; i += 16)
-		sha_transform(hash.w, (__u8 *)(r->pool + i), workspace);
-
 	/*
 	 * If we have an architectural hardware random number
-	 * generator, mix that in, too.
+	 * generator, use it for SHA's initial vector
 	 */
+	sha_init(hash.w);
 	for (i = 0; i < LONGS(20); i++) {
 		unsigned long v;
 		if (!arch_get_random_long(&v))
 			break;
-		hash.l[i] ^= v;
+		hash.l[i] = v;
 	}
 
+	/* Generate a hash across the pool, 16 words (512 bits) at a time */
+	spin_lock_irqsave(&r->lock, flags);
+	for (i = 0; i < r->poolinfo->poolwords; i += 16)
+		sha_transform(hash.w, (__u8 *)(r->pool + i), workspace);
+
 	/*
 	 * We mix the hash back into the pool to prevent backtracking
 	 * attacks (where the attacker knows the state of the pool