Category Archives: identity
Pretty Good Phishing
PGP is not broken. It has long been the best framework most of us have for digital identity, and a secure means of communication.
Sadly the same cannot be said for certain popular PGP tools, nor for vast numbers of tutorials out there. The usage we enjoyed and became accustomed to for a quarter century will now lead at best to confusion, and at worst to mistakes that could defeat the entire purpose of PGP and leave users wide open to spoofing. That applies both to longstanding users who understand it well, and to the newbie who has read and understood a tutorial.
The underlying problem is that 32-bit (8 hex character) key IDs are comprehensively broken. The story of that is told at evil32.com, by (I think) the people who originally demonstrated the issue. It’s developed further since I last paid attention to it (and drew my colleagues’ attention to the need to stop using those 32-bit key IDs), in that an entire ‘shadow strong set’ has now been uploaded to the keyservers. Those imposters were revoked by the evil32 folks, but with the idea being out there, anyone could now repeat that exercise and generate their own fake identities and fake Web of Trust. And when a real malefactor does that, they’ll have the private keys, so there’ll be no-one to revoke them.
Let’s take a look at a recent sequence of events, when I rolled a release candidate for an Apache software package, and PGP-signed it. Bear in mind, this is all happening in a techie community: people who have been happily using PGP for years.
[me] Signs a software bundle, upload it with the signature to web space.
[colleague] Checks the software, comes back with a number of comments. Among them:
- Key B87F79A9 is listed as "revoked: 2016-08-16" in key server
Where does that come from? I take great care of my PGP keys, and I certainly don’t recollect revoking that one. To have revoked it, someone needs to have had access to both my private key and my passphrase, which is kind-of equivalent to having both the chip and the PIN to use my bank card (and that’s ignoring risks like someone tampering with my post on its way from the bank). This is … impossible … alarming!
Yet this is exactly what happens if you RTFM:
% gpg --verify bundle.asc gpg: Signature made Sun 16 Apr 2017 00:00:14 BST using RSA key ID B87F79A9 gpg: Can't check signature: public key not foundWe don’t have the release manager’s public key ( B87F79A9 ) in our local system. You now need to retrieve the public key from a key server.
% gpg --recv-key B87F79A9 gpg: requesting key B87F79A9 from HKP keyserver pgpkeys.mit.edu gpg: key B87F79A9: public key "Nick Kew <me>" imported gpg: Total number processed: 1 gpg: imported: 1
That’s a paraphrased extract from a real tutorial (which I intend to update, if noone else gets there first). It was fine when it was written, but now imports not one but two keys. Here they are:
$ gpg --list-keys B87F79A9 pub 4096R/B87F79A9 2011-01-30 uid Nick Kew <niq@apache...> uid Nick Kew (4096-bit key) <nick@webthing...> sub 4096R/862BA082 2011-01-30 pub 4096R/B87F79A9 2014-06-16 [revoked: 2016-08-16] uid Nick Kew <niq@apache...>
Both appear to be me; one is really me, the other an imposter from the evil32 set. It’s easy to see when we know what we’re looking for, but could be confusing if unexpected!
The problem goes away if we use 64-bit Key IDs, or (nowadays strongly recommended) the full 160-bit (40 character) fingerprint. It is computationally infeasible anyone could impersonate that, and indeed, they haven’t.
$ gpg --fingerprint B87F79A9 pub 4096R/B87F79A9 2011-01-30 Key fingerprint = 3CE3 BAC2 EB7B BC62 4D1D 22D8 F3B9 D88C B87F 79A9 uid Nick Kew <niq@apache...> uid Nick Kew (4096-bit key) <nick@webthing...> sub 4096R/862BA082 2011-01-30 pub 4096R/B87F79A9 2014-06-16 [revoked: 2016-08-16] Key fingerprint = C74C 8AA5 91CB 3766 9D6F 73C0 2DF2 C6E4 B87F 79A9 uid Nick Kew <niq@apache...>
The imposter’s fingerprint is completely different from mine. It’s not PGP that’s broken, it’s the use of 32-bit/8-character key IDs in our tools, our tutorials, and our minds, that’s at fault.
However, the problem is a whole lot worse than that. It’s not just my key (and everyone else in the Strong Set at the time of the evil32 demo) that has an imposter, it’s the entire WoT. Let’s see if WordPress will let me present these side-by-side if I truncate the lines a bit. The commandline used here is
$ gpg --list-sigs [fingerprint] |egrep ^sig|cut -c14-50|sort|uniq|head -5
which lists me:
| My Key | Imposter |
|---|---|
010D6F3A 2012-04-11 dirk astrath (mo 02D1BC65 2011-02-07 Peter Van Eynde 0AA3BF0E 2011-02-06 Christophe De Wo 16879738 2011-02-07 Markus Reichelt 1DFBA164 2011-02-07 Bernhard Wiedema |
010D6F3A 2014-08-05 dirk astrath (mo 02D1BC65 2014-08-05 Peter Van Eynde 0AA3BF0E 2014-08-05 Christophe De Wo 16879738 2014-08-05 Markus Reichelt 1DFBA164 2014-08-05 Bernhard Wiedema |
The first field there is the culprit 8-hex-char Key IDs for my signatories and their evil32 doppelgangers. The only clue is in those dates, which would be easy to overlook. Otherwise we have a complete imposter WoT. Those IDs offer no more security than a checksum (such as MD5 or SHA) if used without due care, and without a chain of trust right back to the user’s own signature (which is something you probably don’t have if you’re not a geek).
There are a lot of tools and tutorials out there that need updating to prevent this becoming yet another phisher’s playground. Tools should not merely stop displaying 8-character key IDs, they shouldn’t even accept them. I don’t think mere disambiguation is enough when an innocent user might thoughtlessly just select, say, the first of competing options.
I’ve already been diving in to some of those tutorials where I have write access to update them, but the task is complicated by having to work in the context of a document that deals with more than just the one thing, and without adding too much complexity for readers. So I decided to work through the story here first!
Identity and Trust
Folks who know me will know that I’ve been taking an interest for some time in the problems of online identity and trust:
- Passwords (as we know them today) are a sick joke.
- Monolithic certificate authorities (and browser trust lists) are a serious weakness in web trust.
- PGP and the Web of Trust remain the preserve of geekdom.
- People distrust and even fear centralised databases. At issue are both the motivations of those who run them, and security against intruders.
- Complexity and poor practice opens doors for phishing and identity theft.
- Establishing identity and trust can be a nightmare, to the extent that a competent fraudster might find it easier than the real person to establish an identity.
I’m not a cryptographer. But as mathematician, software developer, and old cynic, I have the essential ingredients. I can see that things are wrong and could so easily be a whole lot better at many levels. It’s not even a hard problem: merely a more rational deployment of existing technology! Some time back I thought about setting myself up in the business of making it happen, but was put off by the ghost of what happened last time I tried (and failed) to launch an innovative startup.
Recently – starting this summer – I’ve embarked on another mission towards improving the status quo. Instead of trying to run my own business, I’ve sought out an existing business doing good work in the field, to which I can hope to make a significant contribution. So the project’s fortunes tap into my strengths as techie rather than my weaknesses as a Suit.
I should add that the project does rather more than just improve the deployment of existing technology, as it significantly advances the underlying cryptographic framework. Most importantly it introduces a Distributed Trust Authority model, as an alternative to the flawed monolithic Certificate Authority and its single point of failure. The distributed model also makes it particularly well-suited to “cloud” applications and to securing the “Internet of Things”.
And it turns out, I arrived at an opportune moment. The project has been single-company open source for some time and generated some interest at github. Now it’s expanding beyond that: a second corporate team is joining development and I understand there are further prospects. So it could really use a higher-level development model than github: one that will actively foster the community and offer mutual assurance and protection to all participants. So we’ve put it forward as a candidate for incubation at Apache. The proposal is here.
If all goes well, this could be the core of my work for some time to come. Here’s hoping for a big success and a better, safer online world.
Who is blocking what?
I have a problem with identifying myself. Again. And I’ve come to the conclusion that if we haven’t yet reached a point where it’s harder for me than for a competent fraudster to prove my identity, we can’t have far to go!
Specifically, I need to provide proof of identity by means of a bank statement. Not an electronic one, which is all I get. This is in order to open a new account elsewhere, that’ll pay relatively decent interest.
OK, ask at my local agency. No, they can’t supply it, but suggest I call their call centre.
Try the call centre (and navigate through a voice-driven system that is long but at least works surprisingly well). They can send an interim statement (on headed paper, so *hopefully* OK), but a full one will cost a tenner. Probably worth it in the circumstances, but …
It’s the end of the month, so my regular statement should be due. If I go online and amend my options to receive paper statements, it’s free. Simple enough.
Except …
The system just hangs when I try to submit the request. Dammit, now I recollect it doing the same thing repeatedly over about a week when I tried to view my full creditcard statement (which is mid-January). Hmmm …
All this while I’m on the phone to the call centre. They can’t change my options for me, and tell me to go back to my branch. Grrr ….
Plan 3, get it up on the pocket-puter, and go down to the branch with that. Try resubmitting a few times as I walk down the street.
And lo … suddenly it works, acknowledges my request!
What had changed? I’d just walked out of range of my wifi, and submitted over the ‘phone network (and the different IP address didn’t log me out – so at least something was right)! Presumably all that’s changed is that I was accessing them through a different route, and it suddenly works!
I have something slightly similar with some Yahoo sites, where access from my IP just hangs (this has not always been the case), but it works fine if I go through a proxy. What gives?
Relying on Identity
Yesterday’s news: Government agency loses sensitive data on 25 million people. Not encrypted. Head of agency resigns. El Reg reports something interesting has popped up on ebay.
Meeja gasp in astonishment: how could they? That’s half the country exposed to identity theft and fraud in a single incident. Shock, horror!
But the reality is that this kind of ‘accident’ is becoming a regular event. OK, 25 million at once is not the norm, but losses of six-figure numbers of such records are being reported every few weeks. The culprits are household names, like banks and government agencies. How many such incidents go unreported is unknown. Nor do we know whether this is anything new: what has changed recently is that such losses suddenly became sensitive.
Furthermore, a lot of personal information can be obtained legitimately and cheaply. There are companies who make a business of tracing holders of assets. I’ve recently been contacted by one such about some bonus-shares from one of the Thatcher privatisations, and registered to me at an address I’ve had no connection with since about 1990. My shares are apparently worth about £200, and their finders fee – if I choose to use their service – would be about £20. The fact they can run a business based on that kind of thing demonstrates just how easy it is to trace people!
Conclusion: this is something we’re going to have to live with.
So, how do we live with it? Indeed, why is it a problem in the first place? The idea that we should carefully guard our own personal information is new to those of us with nothing to hide: for example, it’s not so long ago I published my home address on my homepage on the ‘net. Some countries have different attitudes to privacy, and consider some of the information we jealously guard to be public.
The basic problem, as we hear it reported, is one of fraud:
Ring, Ring.
“Hello, this is Gordon Brown, of 10, Downing Street, SW1. I’d like a £50K loan for a flashy new car.”
“Yes Mr Brown. Your credit rating says that’ll be fine. We’ll need you to answer a couple of personal questions so we know it’s really you. What is your mother’s maiden name?”
[… cut …]
“OK, that’s all in order. When do you need the money?”
“Immediately, please. And since I’m away from home until the end of next week, can you send it to me c/o the Mended Drum, Ankh Morpork?”
“Yes sir, that will be fine.”
Apparently that kind of thing really does happen. Enumerating the problems with it is left as an exercise for the reader.
It seems to me that the fundamental problem is not really who has access to information, but rather why do we allow basic, widely available or low-security information to be so profitable? It all smells of the race to the bottom, wherein companies put generating new business and market share above the quality, and in this case security, of that business.
The exception to that is tokens such as passwords and PIN numbers, and how to use strong ones, use them securely, remember them, and not re-use the same tokens for multiple different purposes. Public-key technology can indeed solve that (and without the need for a massive central identity database), but that’s another topic.
niq's soapbox 