Slashdot Mirror
Fake PGP Keys For Crypto Developers Found
IamTheRealMike (537420) writes "In recent months fake PGP keys have been found for at least two developers on well known crypto projects: Erinn Clark, a Tor developer and Gavin Andresen, the maintainer of Bitcoin. In both cases, these PGP keys are used to sign the downloads for popular pieces of crypto software. PGP keys are supposed to be verified through the web of trust, but in practice it's very hard to find a trust path between two strangers on the internet: one reply to Erinn's mail stated that despite there being 30 signatures [attached to] her key, [the respondent] couldn't find any trust paths to her. It's also very unclear whether anyone would notice a key substitution attack like this. This leaves three questions: who is doing this, why, and what can be done about it? An obvious candidate would be intelligence agencies, who may be trying to serve certain people with backdoored binaries via their QUANTUMTHEORY man-in-the-middle system. As to what can be done about it, switching from PGP to X.509 code signing would be an obvious candidate. Both Mac and Windows support it, obtaining a forged certificate is much harder than simply uploading a fake PGP key, and whilst X.509 certs can be issued in secret until Google's Certificate Transparency system is fully deployed, finding one would be strong evidence that an issuing CA had been compromised: something that seems plausible but for which we currently lack any evidence. Additionally, bad certificates can be revoked when found whereas beyond making blog posts, not much can be done about the fake PGP keys."
The chain of trust is broken. This because today a certificate is only authorized by a single source, not by several. In addition to this the model has the flaw that it does not easily allow a point to point scenario where only two parties are involved.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
X.509 Certificate Authorities?
The CA model for X.509 certificates has been shown to be utterly broken for protection against intellengence agencies, they clearly have both access to some of the private keys of "trusted" CAs as well as the leverage to have "trusted" CAs issue arbitrary certificates in their home jurisdiction. There is no way in which this would get better by switching to X.509 compared to PGP.
We have already have plenty of malware with valid signatures backed by trusted CAs using stolen keys etc, check stuxnet/duqu for instance.
Now, I know it can be hard to bootstrap a PGP web of trust, and there is certainly plenty of work to be done there to make it easier and user friendlier. But chucking out the one piece of actually working low-level technology for real security in favour of one that is utterly broken, and has been shown to be broken for years, is just plain stupid.
Isn't a checksum of a file posted to a mailing list replicated enough where it can not be manipulated, so it avoids all the trust problems currently found with attempts to sign binary files?
been years since i've heard of PGP. I still have version 7.0.3 for Windows 9x but i haven't used it much
Agree. You are never going to stop the agencies. Any attempt is a waist of effort. PGP is as good as any, might as well work to improve it.
slashdot troll = you make a compelling argument I do not like the implications of.
Gives you an idea as to the level of trust employed when it comes to manipulating internet internals http://www.theguardian.com/tec...
...X.509... Google's Certificate Transparency system...
Finding out that a key isn't signed by anyone you trust isn't a sign that the system is broken: it's a sign that it's working as intended. If people don't check in the first place, that's a deployment problem, but the problem to snooping by centralised organisations isn't reliance on centralised organisations. Google, in particular, are one of the few organisations I'd trust even less than Verisign for anything crypto-related.
The chain of trust has not been broken. There was never a chain of trust to break.
The global internet has no chain of trust or secure* encryption technologies. We have, at best, a series or half-hearted attempts which make it difficult or minor private interests to intercept communications. But we have no-way whatsoever of dealing with NSA sized, centrally managed state backed and internet wide surveillance and control.
The CA system is by now a farce, and a default means of breaking security. The Web of Trust is an only slightly more sophisticated improvement, but again is a joke compared to an actual distributed authentication method like, say, Bitcoin. Unfortunately, the latter is dominated by libertarians, swindlers, and above all a few professionalised central mining operations, so there's no solace there either. The web needs distributed, anonymous, encrypted, secure, robust, usuable and un-commandeerable communication technologies right now. The Network will be turned into a dystopian panopticon at the current rate of software development.
Whether the current generation of walled garden, App-raised programmers is up to this task remains to be seen.
*To appease the new Crypto-dogma neophytes -- reasonably secure for the digital age.
May the Maths Be with you!
I'd be interested in understand more regarding the x509 code idea. SSL is build on x509 and is pretty broken, not necessarily the algorithms, but Digicert and Turktrust highlight two known failures in that system that allowed major web domains to be compromised for those who fell victim to it... also certain countries have certain laws that might allow for private keys of a CA to be say, um, required in secret by authorities and it's not just CAs. Can you trust any PGP key in the UK given the wording of the UK's RIP Act. So what would your suggestion of x509 solve? UK might be a nice country, (the weather could be better today), but I'm sure it doesn't have the worst laws on "requiring" encryption keys.
Combination of methods seems to be the best thing to do for now until encryption technologies have caught up.
If I were to distribute software assets, where possible:
1, I'd use a hash tree like GIT (even for the binaries).
2. Put the assets in a folder with subfolders of signatories, pgp signatures and hopefully an empty folder of pgp revocations signatures.
3. Serve the git tree behind https
4. Only provide binaries if necessary so whoever downloading it can, if they wish, perform a sanity check of recent commits.
5. Provide a simple script for checkout and update that can be downloaded so a non techie could use the above and will fail loudly if something is wrong.
However, better still would be to combine Bitcoin ideas too, distributing assets would be impossible, but you only need to distribute the proof of the asset so you could use a multi-signature transaction system could be used to hold PGP and SHA-3 hashes and have multiple parties involved with a single upload (web of trust).
The address in the database could chain from its first transaction a list of trusted signature addresses. Likely requires some tinkering, but tie that with git, pgp and https and you might be at least one step closer to a common methodology.
+ Side git and bitcoin already have UI implementations, so it wouldn't be too hard to make these steps transparent to a user.
Just because you trust somebody doesn't mean you trust him or her to trust others.
If you have any cert authority in the U.S. they already been compromised and can be muted with a security letter. Unless you run whatever future certt out of a military type environment, you will be infiltrated with keyboard bugs, monitor bugs, cable taps, etc.
Why do you think the Russians went back to typewriters? Anything electronic can be snooped, the level of compromise so great that it is nearly impossible to protect against attacks.
So what can you do? Set up multiple checks across the globe, out of control. If there is discrepancy, then consider yourself compromised or a target.
The fact that the PGP fakes have shown up means that there have been man in the middle attacks.
Your personal router has a back door? Probably if it is commercially sold.
Your internet provider has been backdoored? Most likely, or is easily done with a device brought in the front door with a security letter.
Your local internet backbone has an intercept? Definitely
You can be served faked certs and ip addresses, fake windows updates? Proven
Commercial routers have back door? Proven, the very fabric of the internet is polluted.
You have to containerize your internet now via VPN, and those keys can be secured in the U.S. with a security letter. With quantum computing, it can be broken.
What if the intention isn't on cracking it but just on spreading FUD?
People are pissed off right now. That Snowden thing just isn't going away and people are looking into encrypted email options. Even people who never thought of using pgp (or regarded it as something for paranoid conspiracy theory nuts) would use it now, if it just came as an easy clickable option.
If you're some government agency, that doesn't look desirable. To make things worse, it's a web of trust, one of these pesky decentralized models. Unlike with a central certification authority, trusting one signature doesn't translate into trusting others. But on the other hand, there is no single CA that can be compromised. If you are a government agency in the business of undermining privacy, you would have to attack it one user at a time. Quite frustrating.
What to do about it?
Create some headlines like:
Fake PGP Keys For Crypto Developers Found
Hmm- looks that isn't safe either. Not worth the effort trying it out I guess.
Google is on the right track with their "certificate transparency" scheme, with a public log of all certificate generations, but, like most Google schemes, it involves Google as a central party. The public log needs to be decentralized.
We know how to do this. The Bitcoin block chain is just such a decentralized public log. The Bitcoin block chain could be used to secure the cert log, by putting the Merkle tree into a Bitcoin transaction every 10 minutes or so. Then there can be multiple copies of the public log, and anyone can check them for consistency and validity.
obtaining a forged certificate is much harder than simply uploading a fake PGP key,
Not for an intelligence agency.
would be strong evidence that an issuing CA had been compromised: something that seems plausible but for which we currently lack any evidence.
Uh, no? Short memory? We already had CAs compromised. Was it last year or the one before, I'm not sure.
Assorted stuff I do sometimes: Lemuria.org
What's with all the Jew talk today?
The topic brings out the conspiracy nuts.
Crypto.
Crypt
Freemasons
Jews
This are keys issued in a person's name. Names tend to not be unique, many people share the same given name(s)/surname combination. The same accounts for company names, where it's even easier to get a key with the exact same name as anyone can register a company in the same name as the company they want to copy.
Those keys are perfectly valid. CA's do not have to be compromised for this kind of "attack", they do their job and issue keys in the actual name of the applicant. It can't be that they refuse a key just because someone else somewhere in this world happens to share your name, and they got a key first.
This simple issue is not addressed here, but it's definitely closely related to this problem.
MOD PARENT UP GD DMN IT!
you have to trust big authorities. You DO trust many by default. Everyone can issue wrong certifcates and you will not notice it, you are not required to review new certificates for them to work.
And you CAN revote wrong PGP key. There is an option so sign them with "I DO NOT trust". Just do it. Do it from your right key, get other people, which verified you, to do the same.
I know several webinterfaces ... but how do you do it yourself? Do you need to scrape the whole web of trust, until you have all keys on your keyring to do then a search on the graph?
How does stealing GPG private keys differ from stealing any other private part of a keypair?
Typically in X.509, a keypair is expected to expire. (Technically, a certificate expires, but at least in the use of X.509 for TLS, it is common to make a new key and CSR for the new cert.)
The "obviously stupid" candidate, maybe. Surely that idea doesn't stay on the table for more than a second or two before everyone starts laughing.
Whatever it is that you do, in order to be able to trust an X.509 CA, you can do the same exact thing to trust a PGP CA. Go meet them.
The difference is that if you're not quite able to do that (as is the case for many many people; i.e. nearly everyone; I have never heard anyone say they actually "met" the Verisign signer), then with PGP (huh.. except I have met signers here) you have a backup plan B: partially trust a few people, and require a conspiracy in order for you to lose. With X.509 that plan isn't on the table: if you don't trust the sole signer, then either you live with that increased risk, or else you are denied ability to communicate.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
The first step toward a solution is probably to have many more people use encryption. Only then will the web of trust thicken enough. Then there will be interest in developing more advanced protocols and software.
That first step is doable: Enhance (or fork) Mozilla Thunderbird as follows. People will learn that if they use Thunderbird, and their friends use Thunderbird too, the mail exchanges will automatically and transparently be encrypted, and there is nothing the users need to learn or do differently. Post-Snowden, this will be popular. People will switch to Thunderbird, or to clients and services that support the same protocols.
Make it practical, not secure by the book. Have Thunderbird automatically generate a key for each mail account, and store it lightly obfuscated in a local file. Keep the mails unencrypted in the mail store, in the sent and received folders. Invent a new type of attachment, and have Thunderbird automatically send the public key of the sender's account along with every message. Have Thunderbird store keys it receives in such attachments, in the address book. And have Thunderbird encrypt everything it sends to a receiver whose key it has in the address book.
Add a protocol that allows Thunderbird synchronize keys between multiple installations using the same mail address. Perhaps this should work by sending a mail to yourself from any one of the installations, that is picked up by the other installations. The other installations should respond with new similar mails if they have keys that the originator of the first message may need. This synchronization should probably default to use a hash of the account password as basis for a synchronization encryption key.
Then add options to secure the key file with a strong password, to manage the keys, to revoke them, to export and import them, etc. But only for those who want it. Make sure everything works at a basic security level even with no intervention from the user.
Probably NSA and its relatives will subvert Thunderbird to send the key file home. But this is all a starting point, we can tighten security as we go.
There is no substitute for common sense. Especially, no body of rules will do.
Why would we rely upon the certificate transparency system of Google, purportedly a member of the PRISM Project?
Sadly, a Libertarian cannot force his views on another, and freedom cannot spread as does the cancer known as religion.
Firstly, we have no evidence of any CA being compromised by intelligence agencies despite the obvious appeal to them of doing so. This is remarkable. Despite the huge number of Snowden documents so far none of them have even hinted at compromise of the CA infrastructure.
x509 has already been b0rked numerous times. Just look at the slashdot archives: there are a number of case where:
- stolen keys were used to sign malware
- a "legit" certificate was obtain from a CA for nefarious purposes.
(by "legit" I mean that it's a valid certificate signed by an official Certificate Authority. It's 100% legit as the identity signed there is completely wrong. Like a malware compagny getting a certificate issued for "Microsoft" by some obscure CA which isn't the one Microsoft is using, and which is ready to sign a certificate with "microsoft" written on it, even if the guy handing the certificate is you and not bill gates)
That has so often happened, that:
- Some CA were plain black-listed. I don't mean that a few such bogus certificates were revoked. No, I mean that some vendors (linux distribution, opensource software, etc) have decided to say "fuck you" to the root certificate of such sloppy CA that can't be trusted with the key they sign.
- There are several firefox extension (like "Certificate Patrol") which specially track when the CA who's signed the site you are visiting: if suddenly https://google.com/ isn't signed by "Geotrust" but by "TurkTrust", it might that you are infact being "Man-in-the-Middle" 'd by a crook who has managed to get a certificate for "Google" signed by "TrukTrust".
I'm not speaking about "Hypothetical Attack Vectors" which are currently debated by the academics and which could be used to create problems.
I'm speaking about actual occurences, documented in the press and reported here.
Several actual cases.
If any random crook can do it, chances are that CIA, FSB/KGB/TchK, MSS or any other government can pull the same trick.
The fact that none of the file of Snowden mentions it (and I doubt it, I'm sure I've read about this somewhere) has probably more to do with random chance (not worth mentionning on any of those particular documents, or any of the mentioned cases happens not to use a bogus certificate), than officials not being able to do it.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
transparent updating is another issue. You grant a program the the right to install arbitrary binary code.
Huh... no.
Certificate update is *certainly not* binary code installation.
First of all, it's not binary, it's a collection of text files (containing base64 data, so not even full ASCII).
And most importantly, certificates are not executable code. They are just static data.
They can be sagely transparently updated without being a remote access risk.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]