

Random Seeds in Ubuntu 14.04 LTS Cloud Instances - jcastro
http://blog.dustinkirkland.com/2014/02/random-seeds-in-ubuntu-1404-lts-cloud.html

======
zimbatm
TLDR; PRNG seeds in the cloud are somewhat predictable. Because sshd generates
the keys on boot it's possible to guess the private key on a fraction of the
cloud hosts.

Ubuntu 14.04LTS solves the problem by adding a new source of entropy. They add
a early-boot (before sshd) service that fetches data from an external server.
In short: `curl [http://some-server](http://some-server) > /dev/urandom`

EDIT: Looking for the default server but launchpad seems to be down. Ideally
it would be a trusted source like the cloud provider themselves.

EDIT2: [https://entropy.ubuntu.com/](https://entropy.ubuntu.com/) and the
public cert is provided with the package.

~~~
bmm6o
Ubuntu hosts one, but it's open source so the cloud provider can host one, or
you can host one yourself (when appropriate).

------
otterley
Is egd not sufficient here?

~~~
lotharrr
Nope. Linux systems don't need EGD: the in-kernel gatherers do everything the
user-space EGD daemon would, and better. The problem they're aiming to solve
is that some things (like first-boot ssh key generation) are running so early
that the in-kernel gatherers haven't produced anything yet, so a user-space
daemon couldn't do any better.

(disclaimer: I wrote EGD)

This sort of "early remote entropy fetch" could work well in an EC2-like
environment, where there's a mature box with its own well-seeded entropy pool
nearby (e.g. the physical host of the new VM), close enough that we can talk
to it without an eavesdropper hearing the seed.

We really do need network-proximity for this: encryption wouldn't help you. If
the attacker knew the complete state of your client, they could deduce your
"random" DH session key, and then learn the seed you were trying to transfer.
You either need an unobserved conversation, or a pre-shared secret (and if you
have that, you could just use _it_ as the seed).

~~~
e12e
> We really do need network-proximity for this: encryption wouldn't help you.

That was my first thought on reading the article - they do connect via ssl/tls
to a daemon and get 64 bytes of entropy. But how much good entropy would you
need to complete a secure tls handshake?

Granted, it should be less than for generating some private key(s) -- but this
still feels a little (too) hand-wave-y for me.

I certainly appreciate the effort (both writing the simple client _and_
server, and highlighting the problem (more)).

Looks like a great thing to run on vm hosts, though.

~~~
zackelan
> That was my first thought on reading the article - they do connect via
> ssl/tls to a daemon and get 64 bytes of entropy. But how much good entropy
> would you need to complete a secure tls handshake?

It certainly doesn't mitigate the attack completely, but it does reduce it to
a narrower window of time, so I think that's a step in the right direction.

Before - given 1000 machines in EC2, running the same AMI, it seems like you
have a better-than-expected chance of predicting the SSH host keys (or other
sensitive "random" data that was generated on first boot) of a fair number of
those machines.

With this - given those same 1000 machines in EC2, you would have to eavesdrop
on the network traffic of each one, at the time of its first boot, to have a
reasonable chance of guessing the state of the internal entropy pool.

~~~
e12e
Seems like a reasonable[1] approach would be to have a custom handshake using
pre-generated pre-shared secrets (using eg AES-GCM ?). You'd probably want
separate keys pr vm though -- which I suppose defeats the point (If you can do
that, just give each vm its ssh/ssl-key(s) from "outside"...).

Perhaps it is possible to do something along these lines with TLS-PSK? If we
assume a goal of no random session keys for the setup, I guess it would still
be possible to a) sniff the "seed", record it for all N vms sharing a PSK b)
(later) break into one out of any N vms, thus c) derive the state of all N vms
entropy pool at the state of keygeneration.

The more I think about this, it seems the easiest fix is to a) make sure the
host has a reasonable entropy pool b) have the host supply entropy seed to the
vm when it boots. Maybe some new standard virtual entropy-seed device (might
be specified as a blocking source of entropy as opposed to an unlimited tap
into the hosts /dev/urandom).

At least there are things in place (like Kerberos/LDAP or AD) for managing
shared secrets for the host(s) (which might not be used for managing the VMs)
-- so having a service like this on all the hosts (only) should be easier than
demanding all VMs have it.

Then just do a cat /dev/special_random_init_random > /dev/urandom on (vm)
boot.

[1] As reasonable as it is to have a big list of per-machine shared secrets...

------
neuroscr
Sending your random seed over the wire doesn't sound like the right direction.
For those listening, it always makes sure they have your seed. Did the NSA get
them too?

------
bmm6o
The links in the slides are borked, there seem to be 3 stray bytes at the end
of each shortened url.

------
hiphopyo
Choose OpenBSD for your Unix needs. OpenBSD -- the world's simplest and most
secure Unix-like OS. Creator of the world's most used SSH implementation
OpenSSH, the world's most elegant firewall PF, and the world's most elegant
mail server OpenSMTPD. OpenBSD -- the cleanest kernel, the cleanest userland
and the cleanest configuration syntax.

~~~
skywhopper
It would be interesting to hear how OpenBSD deals with the issue Ubuntu is
attempting to address here. This comment, however, is neither interesting nor
is it, apparently, related in any way to the topic of this post or the content
of the article.

~~~
justincormack
Theo is against virtualisation, and there is no support for it (you can of
course do it anyway with full hardware emulation).

"You've been smoking something really mind altering, and I think you should
share it.

x86 virtualization is about basically placing another nearly full kernel, full
of new bugs, on top of a nasty x86 architecture which barely has correct page
protection. Then running your operating system on the other side of this brand
new pile of shit.

You are absolutely deluded, if not stupid, if you think that a worldwide
collection of software engineers who can't write operating systems or
applications without security holes, can then turn around and suddenly write
virtualization layers without security holes."

