[Servercert-wg] Proposed ballot: Minimum expectations regarding weak keys

[Jacob Hoffman-Andrews]

Corey's previous email at
https://archive.cabforum.org/pipermail/servercert-wg/2020-April/001846.html
suggested iterating over 11 platforms was necessary:

> As stated in my previous messages, you need to check for all 11 platforms
supported by Debian at the time of the vulnerability

> The presentation you linked to in the previous email stated as such on
slide 11 ("… and each platform (x86,x64,PPC,…)"). As time goes on and this
antiquated hardware becomes increasingly rare, this will be an increasingly
onerous requirement. for incumbent --and especially new -- CAs.

The presentation referred to was
https://trailofbits.files.wordpress.com/2008/07/hope-08-openssl.pdf (linked
by Ryan in
https://archive.cabforum.org/pipermail/servercert-wg/2020-April/001845.html
).

The presentation has this text:
> As exhaustive as possible:
> … and each platform (x86,x64,PPC,…)

However, I don't think that line was meant to claim that each of the 11
platforms differs. That's made clear later in the presentation by the fact
that the researchers simply used Ubuntu VMs on various affected endianness
/ word size, and only treated endianness / word size, not platform, as a
variable in their naming scheme:

> Amazon provides VMs, including vulnerable Ubuntu
> 1. Populate a distributed queue with strings describing which keys to
generate
> “rsa/1024/65537/le32/0-FF”
> 2. Launch 20 VMs (the default limit)

Also, all contemporary sources, including the Debian Security team
generating {openssl,openssh,openvpn}-blacklist, seem to have believed
endianness and bit size were the only meaningful variables with regard to
platform.

>
https://www.cs.umd.edu/class/fall2017/cmsc818O/papers/private-keys-public.pdf

To avoid any potential confusion: even though "2017" is in the URL, this
paper was from 2009 as you can see here:
https://dl.acm.org/doi/10.1145/1644893.1644896.

One other bit of useful information for people following these threads: The
previous thread suggested that the rnd / nornd / noreadrnd states are
documented at https://wiki.debian.org/SSLkeys, but that page does not
document those states. The best documentation I've been able to find is in
https://packages.debian.org/jessie/openssl-blacklist. Download the diff
file (
http://deb.debian.org/debian/pool/main/o/openssl-blacklist/openssl-blacklist_0.5-3.diff.gz)
and find gen_certs.sh. It contains this comment:

> # There are 3 types of vulnerable moduli:

> # 1. ~/.rnd does not exist when openssl is run
> # 2. ~/.rnd existed, but was not readable when openssl is run
> # 3. ~/.rnd is readable and writable when openssl is run

This is backed up by the 2009 "When Private Keys Become Public" paper:

> Because the binary representation in memory of certain values is added to
the entropy pool, not a canonical representation, our key generation must
account for the target platform’s endianness and native word size. In
addition, the presence of a file called .rnd in the user’s home directory
affects the behavior of OpenSSL’s command-line utilities. If it is present,
its contents are added to the entropy pool. Accordingly, we must generate
two sets of keys: ones assuming the presence of .rnd, one its absence.
(Because of the Debian bug, the contents of the randomness file are not
consulted; all 1024-byte files produce the same result.) When .rnd is
missing, versions of OpenSSL before and after 0.9.8f have different
behavior that we must again account for.6 Debian-derived distributions
shipped versions with both behaviors, so we must account for both.

So I agree with the above posts, that we should parameterize only on
endianness and word size (and pid, rnd, modulus length), not full system
architecture.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200916/e758c8f6/attachment.html>