[Pki-clean-room-devel] Entropy gathering

[Daniel Kahn Gillmor]

On Fri 2017-10-06 12:05:50 +0300, Sergey Matveev wrote:
> I presume that entropy could and should be additionally provided to
> running air-gapped computer on media devices and fed into /dev/random
> pool (cat /mnt/additional_entropy > /dev/random). Also, when computer
> is going to shutdown, then his current pool state could be saved on that
> media for future use.

entropy for a usually-off machine is definitely a concern, as
immediately after boot there is insufficient entropy to do reliable
crypto.  But it's worth considering what you need the entropy for.

As i understand the clean-room project, its goal is the creation,
storage, management, and use of certification keys.  The three
cryptographic operations in question here are:

  a) secret key generation
  b) secret key secure storage (password lock/unlock)
  c) certification of third-party OpenPGP certificates

entropy for (a) is critical.  See Heninger's "Mining your P's and Q's"
paper for a vivid description of what goes wrong when insufficient
entropy is used.

But (a) happens only once, and when done, the only things that remain
are (b) and (c), right?

iiuc, (b) requires entropy only during the "lock" operation: for the
choice of salt for the password-stretching operation that happens before
key storage, and the salt itself is stored in the clear next to the
protected key.  This "password lock" operation happens at the same time
as key generation, and when changing a password.  If an attacker
controls (or knows) your entropy source during this operation, it only
gives them advance knowledge of the salt -- useful for pre-computation
if your password itself is guessable, but not so useful against strong
passwords.

(c) is the critical part, though -- and it depends on the signing scheme
used during certification.  when using DSA or ECDSA in traditional mode,
using a bad RNG can actually leak your secret key.  However, modern DSA
and ECDSA implementations should use deterministic signing (see RFC 6979
[0]), which frees you from the need for entropy.  And RSA signatures in
OpenPGP use EMSA-PKCS1-v1_5, which is also deterministic [1] (meaning
that it doesn't use any entropy at all).

So, the most important need for entropy in the clean-room project
appears to be (a) secret key generation.

----

see the man pages random(7) and random(4) [2] for more details about the
tradeoffs between different sources of entropy and how they interact on
boot, before the kernel has had enough entropy to initialize the
"blocking pool".

On normal systems using systemd as the service manager, entropy is saved
to local storage and restored across a reboot with
systemd-random-seed.service (see systemd-random-seed(8)).

Note that this means that read access to the filesystem on which the
seed is stored might give an attacker some additional knowledge about
any entropy needed.  So, for example, if /var/lib/systemd is visible to
the attacker, and no other sources of entropy are available, and the
user subsequently generates a key with the clean-room machine, they
could end up generating a key where the secret part is also known to the
attacker.

Another approach to addressing potential low-entropy situations is
HAVEGE [3], with at least one implementation available in debian as the
"haveged" package.  I haven't evaluated HAVEGE in an adversarial context
for a dedicated-use computer (like cleanroom), though :/

Another useful bit of guidance may be to use a hardware RNG.  This could
be an external device (like the NeuG or an entropykey) or it could be
the one built into many modern processors (e.g. RDRAND [4]) -- though
depending on the adversaries you're concerned about, you might decide
that some of these are less-trustworthy than others.

hopefully this is useful background,

          --dkg


[0] https://tools.ietf.org/html/rfc6979
[1] https://tools.ietf.org/html/rfc4880#section-13.1.3
[2] i.e. by running "man 7 random" or "man 4 random" from your favorite
shell
[3] https://www.irisa.fr/caps/projects/hipsor/
[4] https://en.wikipedia.org/wiki/RdRand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pki-clean-room-devel/attachments/20171006/51a7937c/attachment.sig>