| layout | published | title |
|---|---|---|
post |
true |
CA Exploited by Uber-Hacker Havenwood! -or- How Revocation Works |
On Feb-20-2013 at approximately 10:00 GMT a mysterious user known only as Havenwood was able to bypass several layers of security and receive certification from the authority without proper authentication.
He is believed to be a Caucasian male, between fifteen to fifty years old, four to six feet high, weighing between one and three hundred pounds. If you have any information about his whereabouts, please contact us. If you encounter him in person, contact your local authorities. Do not attempt to apprehend him yourself. He is rumored to be armed and extremely dangerous.
Havenwood submitted an application for certification. Because of a bug in the code, we did not realize that he never actually confirmed his account, which meant that he never demonstrated that he actually controlled the submitted private key. In spite of this, we signed off on his key.
Nope. If we've issued a signature in error, or later decide that a previously authenticated user has malicious intent, we can revoke our certification.
Once the problem was discovered we were able to issue a revocation of the original signature and send it off to the keyservers. You can see the revocation on pool.sks-keyservers.net.
The line starting including revoke indicates our original signature has been revoked. You will no longer trust the authenticity of Havenwood's key, at least based on our signature. If you've authenticated the key via other means, you'll still trust that and ignore our revocation.
For this revocation to take effect users would need to pull the revocation down from the keyserver network. If they've previously downloaded the key and they never refresh it, they'll never know we revoked our certification.
To encourage good keyring hygiene we've setup a rotating expiration date on our signing key. On May 17th, 2013 the signing key will expire. At that time we will bump up the expiration date and publish this information.
If a user hasn't been keeping their keyring up-to-date, authentication of users we have certified would start failing on their machine because the system will think our signing key is expired. They would need to refresh their keyring by running:
gpg --keyserver pool.sks-keyservers.net --refresh-keys
Performing this operation will grab an updated expiration date for our
signing key. It will also grab our revocation of our signature
against Havenwood's key. Any attempt to install software signed by
this key with the --trust option would now fail as the key will no
longer be trusted.
(This example assumes you've already trusted our keys as described in The Complete Guide to Signing the Certificate Authority Keys.)
Get Havenwood's key and examine the signatures:
gpg --keyserver pool.sks-keyservers.net --recv-key 0x50DBC4B4
gpg --list-sigs 0x50DBC4B4
You'll see that you have both our original signature and the revocation.
Here's a message Havenwood signed. Save this to a file somewhere:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is our world now... the world of the electron and the switch, the beauty of the baud.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Darwin)
iQIcBAEBAgAGBQJRR1NRAAoJEM9hVGdQ28S00hcQALyHa/3ZpmWY7jwWLoXXZbpc
Pd+MXuH2cmkUBx/Xaeu8FzcNL05svBoZrQn8eJNTRgYN/zD5b8G6eD3a5w4PVO3I
7hP0zN+WRqUBvwuJdq7Ek0cdGNOMU+jGonSCfRhTwTNDBeDWkoIxkiIl+04BmSAD
7kBaHZu0vWbHjWEJkAM26KaE3r/bVYTojVO0D8RKdJ8d6H5nyRW8F3S+b4sHmwXY
hEb9zz1/QkUbU9L4I3I+ag43HAw9ywsTDcWfGk5G3V7aUCWYTMfoIjuEEhQYQAHJ
UcJy0cuJxQtOG6gP3N/x9WSeLmVOleTrJSVuV0CsDw9lR3ALHVZJ5A8HpevKe795
HokoVpwjN4580qKIeRZM2eB+P6sK8CJKXxh8rAqAsgv9TrsfXD8ESKy4iqF0ZS96
wSj5btHLU7Jk511w8wKWLr66fPTLd6wLP/+2Iw5BWntERMPMjICP8erDzw7Lah05
ghiSyj2lifMqwoXe4nznAVmihEjv7tOXE45IlSBc6nBUQxtMMgTzUTuqRbumMLXf
W2TYVYI01Dv/KWjo+XvmLNte8irhIoePRekj/Do0BD9hzYiN6ZrxZw7sgOswo+uV
g+NYUof3jVa2pd7RQo1ihbp0eqrtjQbOf6ZhvbUxu3DDoNkIS8j9DK3kXecoQW1W
A5sPId7OoYQUlId/RprT
=12Qp
-----END PGP SIGNATURE-----
Check the signature:
johnmudhead:~ grant$ gpg foo.txt.asc
gpg: Signature made Mon Mar 18 13:43:33 2013 EDT using RSA key ID 50DBC4B4
gpg: Good signature from "Shannon Skipper (havenwood) <blah@example.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 06CB 6789 306C 1DC4 BEAE ABF1 CF61 5467 50DB C4B4
Note the WARNING lines of text. This is because we our signature is no longer included in the calculations.
If you ran gem install foo --trust against a gem signed by this key
the operation would now because the key is once again untrusted.
On the other hand, if you trusted the key by other means, for example because you knew Havenwood personally, the install would succeed. Our revocation doesn't state anything good or bad about Havenwood other than the fact that you should ignore our previous certification.
Thanks for being a good sport Havenwood.