provide validator to check embedded keys against known key lists
Description
Environment
depends on
has dependent
Activity
Ian YoungDecember 22, 2015 at 6:01 PM
Closed on release 0.9.0.
Ian YoungDecember 10, 2015 at 5:27 PM
Imported from ukf-mda project, commit 33287d6a3e759bf21b3d70bd9c8b02b732fbcc60.
This includes a number of text files containing the appropriate key blacklists for the Debian weak key issue, and some random known-compromised keys.
Ian YoungNovember 21, 2013 at 4:43 PM
I have one of these in the ukf-mda project now. We can pull this into the main codebase in the next feature release.
Ian YoungNovember 21, 2013 at 1:23 PM
Ugh. It's worse than that.
The ssh blacklists are the trimmed MD5 hash of the ssh key in some representation, not just the modulus.
The OpenSSL blacklists are the trimmed lower-case hash of a string made up of "Modulus=", the upper-case hex value of the modulus (with any leading 00 bytes removed) and "\n".
No escaping from the madness of the old blacklist representation, in other words.
Ian YoungNovember 21, 2013 at 11:39 AM
The current Debian 7.2 "Wheezy" release provides some packages using a more compact blacklist format:
openssh-blacklist and openssh-blacklist-extra
openssl-blacklist and openssl-blacklist-extra
These use a lower-case trimmed MD5 hash representing the 80 LSBs of each modulus hash value, so they are only 50% the size of the original ones and a bit simpler to compute.
There are still a lot of "Debian weak keys" floating about. In the UK federation, we use a really revolting script to check embedded keys against blacklists to weed these out. This means that it isn't run as part of the main metadata build. I'd like to be able to bring this into the aggregator environment by creating a key modulus blacklisting stage.
Here's the original Debian advisory:
http://www.debian.org/security/2008/dsa-1571
The two Debian-supplied blacklists are 8MiB each (one for 1024-bit keys, one for 2048-bit keys), each being 196K-line files with one hexadecimal hash value per line. Unfortunately the hashes are not of the moduli per se but of the line in OpenSSL output where the modulus is printed, so in order to reuse those files one would need to recreate that situation without OpenSSL. That shouldn't be too hard, though, and probably beats the alternative of regenerating the blacklists in a more comprehensible format.
For the Debian case, we definitely don't want to include the hashes within the bean configurations, but refer to the files containing them instead.
It may also be worth building a stage that blacklists moduli hashes for other purposes. In that case I'd suggest making the blacklist contain hashes of the actual moduli, and including them in the configuration directly. This is not that, though.