On Thu, Sep 25, 2014 at 8:29 AM, Gervase Markham <g...@mozilla.org> 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 > > It seems like they have numerous disadvantages (some subjective): > > * Client certs can be invisibly stolen if a machine is compromised > * Client certs are harder to manage and reason about for an average > person > * Client certs generally expire and need replacing, with no warning > * Client certs are either single-machine, or need a probably-complex > copying process > > What are the advantages?
Going back to this thread because nobody seems to have addressed the real issue - usability. Right now I am working on email encryption but solving the usability issues of email requires a general solution so I have worked on these issues as well. And I think I have solved them. Passwords have terrible security because they shift the cost to someone who does not care about security of the asset because they don't own it. I use the same password for my Washington Post, New York Times, Slashdot, etc. accounts and it was leaked over five years ago. I do not care because it isn't my asset involved. So the passwords get forgotten and no password is better than the security of the recovery system which is SMTP. Passwords are also horribly insecure because they are disclosed to validate them. Now we could solve this with some clever crypto scheme but why bother when its actually easier to design a sensible PKI scheme. Passwords also have pretty horrid usability. But they get away with it because implementation of client certificates is really, really bad. One time tokens are pretty horrid usability as well. You have to carry the thing about with you. Which I won't do unless I am paid. So most of those schemes are migrating into smart phones. TAAA-DAAA! We are now emulating 1970s technology with a computer that would have been supercomputer class in the 1990s. There is a much better way to use a smartphone, send it a message that asks "Do you want to pay your gas bill of $503.43?" and have the user answer yes or no and the app return a signed message. I am currently working on making S/MIME and PGP email really really easy to use. As in no more effort to use than regular email. As part of that I have written a tool that creates and installs a certificate. For a self signed cert the process is just run the configurator tool and its done. For a CA issued cert, the user will specify the domain name of the CA and it is done. Not even email links to click on because the configurator has control of their mail app and can do the challenge/response automatically. [There are other validation schemes supported but I won't go into them here] What I have taken out is all the makework that the user currently has to suffer. And this is not just bad for Thunderbird, it is poke the user in the eye with a sharp stick bad. It literally takes a quarter of an hour to go through all the incantations. And that is me doing it, I know what I am doing. I would expect no more than 60% of users to follow instructions correctly. And all the effort is complete makework. The user has to pull the certificate out of the Windows store and install it in T-bird. Oh and repeat once a year. Client SSL certs are just as bad and in addition the use interface is horrid like it is on every other browser. The basic problem with most Internet crypto is that the implementation is 'enterprise grade'. By which I mean terrible usability because the person who decides what stuff to buy will never use it. The problems don't require a usability lab to sort out either. In fact DON'T go to the lab. If the user is being given work to do then the design is wrong. I don't need to test out my configurator in the usability lab because there isn't a user interface to test. OK so how do we solve the usability issues Gerv raised? * Certs expire after 1 year * Transferring keys between devices? Answer: We don't. Look again at the requirements. What are the use cases that drive them? I can't see any driver for enterprise or consumer deployments. I can't even see a need to do either in the government case, but the first is probably inherited from NSA doctrine. First step to sanity is that authentication keys are only ever in one machine. If a user has two machines then they have two keys. If they have eight machines then they have eight keys. This solves two problems, first the key transport problem, second a large chunk of the revocation problem. If a device is lost we only need to affect one device, not every device. [Decryption keys are another matter, there are good reasons to have a single decryption key in multiple devices. And the reason that I got into the per device authentication keys in the first place was to enable the migration scheme for decryption keys.] So now we have a per machine certificate, how do we bind eight keys to one account? Well in PKIX thats just a matter of eight certs. What I am actually doing is a little more complicated though. I am setting up a personal PKI hierarchy for each person. At the root of the hierarchy is an offline 'life-long' master key (it can be rolled but there is no predetermined expiry). Underneath that there is an online cert signing key. So the first step to provision a device would be to issue a cert for its authentication key. That is not quite enough though, what if the device is lost? To address this issue we either use an OCSP token or make the device certs short lived and re-issue them monthly or whatever. My goal is to achieve transparent usability for Internet security. I am not tied to one particular approach or even a business model. PKI is a useful technology, but I am actually using a lot of symmetric key, Kerberos type approaches under the covers. I did not begin with 'how do we keep CAs' but giving the option to put services in the cloud allows for a better consumer experience and as the success of dropcam shows, given a cloud option, most users will take it as the easy path. The current status is that I have a lot of open source code and specs. These are linked from prismproof.org. I have the configurator running for Windows Live Mail and I will add outlook soon. But I abandoned the attempt to do T-bird because I just can't get the dev system running on my Windows box despite more than a day trying. The documentation is incomplete and misses out references to necessary tools to even build the library. The error made in T-bird is that it ignores the fact that storing keys is a platform concern. Platforms such as Windows and OSX have code and in many cases hardware to protect keys. Applications should use them. Even if they want to use their own crypto library, protecting the user should always be first. It would not be very difficult to write a driver that allows Thunderbird/Firefox to make use of keys stored in an OS secure keystore and get the benefit of hardware protection. Certainly a lot easier than writing platform specific drivers. Which is a long winded way of saying that I can show people how to fix the usability nightmare that client side certs are at present on the mozilla platform but I can't to the work myself and putting the user first might require a change in approach for the crypto stack. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
