On Thu, September 25, 2014 11:18 pm, Henri Sivonen wrote: > On Fri, Sep 26, 2014 at 12:33 AM, Matt Palmer <mpal...@hezmatt.org> wrote: > > On Thu, Sep 25, 2014 at 01:29:04PM +0100, Gervase Markham wrote: > >> A question which occurred to me, and I thought I'd put before an > >> audience of the wise: > >> > >> * What advantages, if any, do client certs have over number-sequence > >> widgets such as e.g. the HSBC Secure Key, used with SSL? > >> > >> http://www.hsbc.co.uk/1/2/customer-support/online-banking-security/secure-key > > I can see one advantage: > * A client cert that's *not* on an external token is just bits on > your device and doesn't add a physical thing you have to carry around. > > >> It seems like they have numerous disadvantages (some subjective): > >> > >> * Client certs can be invisibly stolen if a machine is compromised > > > > Well, the cert is quasi-public information, so it doesn't matter if they > > get > > stolen, invisibly or otherwise. The private key, on the other hand... > > <grin> But at any rate, just stick the key/cert in a USB HSM. Problem > > solved. > > On a more serious note, putting the private key on a USB device or a > smart card isn't a realistic solution. It's not even a "now you have > two problems" kind of solution. If you do that, you have way more than > two problems. > > I live in a country with a failed but still zombied initiative to > issue client certs on smart cards to all citizens (or maybe residents; > I'm not quite sure; I believe the issuance never reached more than 10% > of the population anyway because for many people it makes more sense > to have a driver's license for domestic use and to have a passport for > global use than to have an ID card for EU use [the certs are on ID > cards] and only a handful of people ever had hardware and drivers to > use the issued certs) and I've worked in a project that was supposed > to use these things for user login. The initiative is an expensive > boondoggle that's a big waste of tax money. With desktops, there's the > problem of having to obtain a card slot [not a problem with a direct > USB device you mention], driver problems and usability problems. With > non-desktops, there's the problem of not even theoretically having > suitable hardware interfaces. Sure, it would be fair to say that the > initiative in Finland was just badly executed: It occured to the > government CA to file > https://bugzilla.mozilla.org/show_bug.cgi?id=463989 only in 2008, even > though the lack of root program inclusion was a major usability > problem already in 2003 when I worked in a project that was supposed > to use this stuff. And they've failed to follow up on that bug for 6 > years now! Even if you point to e.g. Estonia for better execution, > observation at a point in time is not enough. Compare with the South > Korea ActiveX bank crypto, which might have looked like a good idea to > some at some earlier point in time. Also, committing a large > population to particular hardware interfaces for the token inherently > risks obstructing progress. Paper-based one-time passcodes FTW! > (That's how identifying people for government Web sites actually works > in Finland--with banks acting as IdPs.) > > Now, you may say that tokens work on the scale of your company and of > course they don't scale on the level of a country, but Gerv's case of > a large bank in the UK is on the same level of scale as the population > of a less populous European country. > > >> * Client certs are harder to manage and reason about for an average > >> person > > > > Hmm... I think this one could go either way. If you get a cert/key on a > > USB > > stick, is that massively different from the consumer's perspective from > > getting a Yubikey or number-sequence token? > > A USB HSM and a Yubikey are massively different from each other, > because the latter acts as a USB keyboard and, therefore, doesn't > require special drivers or any sort of infrastructure work to > integrate with a browser. > > >> * Client certs generally expire and need replacing, with no warning > > > > As has been noted elsewhere, that's a UI problem, and number-sequence > > tokens > > aren't immune either. > > The UI problems with client certs are on a completely different level > of problem than the UI problems with having to type four to six digits > that you look up from a paper sheet or a small hardware widget. (Paper > sheets FTW, BTW. More eco-friendly than hardware widgets. Don't break > when bent or exposed to cold weather. Paper is easier to clone, yes, > but that's not enough of a Real Problem to deserve solving. Usually, > the problem isn't cloning but losing the original paper/widget.) > > >> * Client certs are either single-machine, or need a probably-complex > >> copying process > > > > Or a USB HSM. (I'm starting to see a pattern here) > > How do you plug that USB HSM into a tablet with no USB host > capability? (I'm saying "tablet" rather than "phone" so that you can't > go "Well, with mobile devices, you just put the private key on the > SIM.") > > All in all, paper sheet of one-time passcodes entered by hand to a > form submitted over https work well, are time-proven to work before > and after revolutions like smart phones and are platform-independent. > Just say "no" to client certs and especially ones embedded on hardware > tokens for bank use. > > -- > Henri Sivonen > hsivo...@hsivonen.fi > https://hsivonen.fi/ > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy >
Correct. There is so much usability failure in smart cards that I've worked quite hard to keep them out of scope of W3C Web Crypto WG (which, unfortunately, looks like that may fail in the rechartering and all hell will break lose). I mean they are fundamentally a boondoggle, a waste of taxpayer money, and incompatible with the web in so many ways. Do they exist? Yes. Are they a good idea, especially at a national or international level? No. Absolutely not. However, rather than just rant about the evils, I'll point out some of the key flaws: - In many of the national schemes, they are seen as legally binding, but malware can and does easily abuse this. However, much like CHIP+PIN in the EU, the liability is shifted to the user, because "surely" these systems never fail. - They fail to work with a variety of devices and form factors. Yes, I'm aware of the relevant IEEE standards. That doesn't many crap for ubiquity of access though. - The key, much like a fingerprint, is often extremely sensitive PII. Even the public key is an identifiable number (it has to be, it's cryptographically random). Throw in the contents of the cert, which often include far more personal details, and you're doomed. - There's zero trusted path for entering PINs or for validating what you're signing. This fundamentally boils down to the Trusted Computing problem, and the only way to achieve security (against malware - or, in the web crypto future world - 'hostile' websites) is to lock down the platform such that the user can change nothing. - On a technical level, it's incompatible with MITM. Say what you will about how that's a great thing (don't get me wrong, I hate MITM), but in practice, that makes it undeployable for a vast number of schools and enterprises (that are doing dumb things, but I respect their freedom to be idiots, to a degree) - The Web is built on a multi-origin model, but you cannot begin to identify which TLS connections are authenticated/identifying you to a website and which aren't. Nor can the server ever provide any semblance of a 'log off' These sorts of problems have been responsible for a lot of the attempts to 'reinvent' client certs without the baggage, the latest of which is the FIDO Alliance work (which in some areas is quite good). However, Passport's ID cards or Microsoft's latest U-Prove stuff also exists in a similar space, and you can easily find dozens of other examples. Oh, and did I mention it's an absolute godforsaken patent wasteland for the actual act of getting a client certificate issued - hardware or not? While Oracle stands out (via Sun's GlobalPlatform work), nearly every hardware vendor has a warchest of patently obvious (although not obvious enough to prevent patents from being issued) IP that they use as "value add" to their customers, but which enshrines vendor lock-in to a degree unimaginable. Fundamentally, the technology is user hostile, device hostile, and privacy hostile. But it's still the best we've got for some situations (typically, controlled environments like enterprises, in which they can be both awesome and terrible...) _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
