The password wallets are an excellent solution to cope with the usability problems of passwords, because you can use different passwords for each account and you no longer have to remember or type them. Password wallets can be used straight away because nothing has to change at the server side: from the viewpoint of the web site you're visiting, you are still just sending them a password, as usual. This, however, is also the main limit of the password-wallet solution: you're obviously still stuck, by design, with passwords, so you still suffer from the inherent security problems of those static secrets: they can be recorded and replayed, they can be compromised if the web site gets hacked and, unless they're assigned randomly by the computer, if they're created by the user then in many cases they can also be guessed by a smart adversary. Pico instead uses a challenge-response based on public key cryptography rather than static secrets and therefore does not suffer from those security problems.
Some password wallets reside on a separate device, such as your smartphone, in which case there's the problem of transcribing the password from that device to the one where you want to use it. Some are polyinstantiated on both your smartphone and your regular computer, in which case you can cut-and-paste rather than retyping, which is still a bit cumbersome but much less so than retyping. From the security viewpoint there's also the concern that your password wallet resides on your networked computer and is conceivably a target for malware, which could steal all your passwords. Pico instead is a dedicated device rather than a general-purpose networked computer running arbitrary applications.
Some password wallets are integrated in the web browser, in which case they don't work for non-web passwords, whereas we want Pico to replace all passwords, including the one you type to log into your computer or to unlock the screen saver. And we want Pico to be useful even in user authentication contexts that don't necessarily involve a PC or phone, such as getting money from an ATM, or starting your car.
Funny you should say that: we have done just that! Many people already have smartphones that can recognize QR codes, so this appears like a natural match. Indeed our first student projects and internal prototypes have implemented Pico as a smartphone app. We'll soon be releasing the app to testers. We want people to try out Pico with their low value accounts and tell us how they get along: if we want Pico to be much easier to use than passwords, there's really no other way than for us to iteratively improve it until it actually is.
In due course, the most secure version of Pico will be a dedicated hardware device: phones nowadays are general purpose programmable web-connected computers on which people download and execute arbitrary code. We wouldn't want all your login credentials to be sitting next to the malware you just downloaded thinking it was a free game! Even if some phones have hardened OS-level and even hardware-level sandboxing, we haven't seen any yet that provide trusted path to the user. To protect all your high value accounts we want Pico to be a non-programmable, single-purpose gadget that is smaller, simpler and more secure than your phone.
Having said that, the Pico App running on a smartphone has the merit of not forcing you to carry (and remember to recharge) yet another gadget, which is good. And, after all, many of us already take the (arguably modest) level of security offered by our phones to be sufficient for email, e-banking and so forth. So we view the Pico App and the hardware Pico as two equally valid points on a spectrum of solutions that span the trade-off between convenience and security. Maybe you'll want the hardware Pico only to access your most valuable assets and you'll be satisfied with the smartphone Pico App for the rest.
It won't. The initial Pico App will only scan codes displayed on other devices, such as your desktop or laptop computer. A future Pico App might allow you to log in on a web site you open on the phone, but of course it won't "scan itself", nor will it need to: when the web browser and the Pico App are on the same machine (your phone), they can communicate directly, rather than through the optical channel.
This is a common problem when replacing "something you know" with "something you have": all token-based authentication systems have to face it. In some familiar cases we seem to accept no protection for the authentication token, as is the case for physical keys: if someone pinches your car keys, they can drive off with your wheels; and, if someone pinches your home keys, they can get in. Another popular solution is to protect an electronic token with a PIN or equivalent, like the graphical squiggle popular on Android smartphones. But we don't favour that solution: research (including extensive work at Cambridge such as Bonneau's PhD on Guessing human-chosen secrets) has shown that human-chosen secrets are easier to guess than you might think; besides, one of the design goals of Pico is that you should no longer have to remember secrets to authenticate. What do we do then instead?
Ideally, the Pico would lock itself up completely (like a powered-down laptop with full disk encryption) whenever outside of your control. The world doesn't yet have the technology for "telepathic authentication", but we approximate it with our idea of "Picosiblings", small devices worn on your body and in your clothes that create an aura of "being around you" that the Pico can sense. Besides Picosiblings, we are researching other possible methods of approximating telepathic authentication, with different trade-offs.
We have also designed a facility for disabling the Pico remotely once you notice it is missing.
The docking station that recharges your Pico takes a backup of the encrypted Pico every time the device is recharged. If you lose the Pico you may buy a new blank Pico and restore your most recent backup onto it.
Once the system is widely deployed, the cost of a blank Pico should be similar to that of a basic mobile phone or computer mouse, so you might even keep a spare blank at home and one at the office, just in case.
No, the initial Pico App will only have a small subset of all the features you see in our envisionment video. You won't own any Picosiblings yet, for example, so to lock your phone you still have to rely on whatever facility is offered by your phone manufacturer (PIN code, graphical squiggle, fingerprint, face recognition and so forth). This initial Pico App doesn't offer the whole Pico experience yet, but it lets you try the part where you interact with the web site and scan a QR code instead of remembering and typing a password.
Some forms of biometric authentication can be very accurate and powerful, and work very well in locally supervised applications such as border control or population census; but most biometric recognition technologies are insecure when used across a network unless you can assure to the remote verifier that a live biometric is being sampled by a genuine reader. Because this trusted path assurance is usually not provided, remote user authentication through biometrics is vulnerable to replay attacks, from the most basic analogue tricks such as the "gummi finger" to attacks in which the reader itself is replaced by an emulator.
There are two other reasons for not wanting to use biometrics to replace passwords. One is that, if they get compromised, you can't revoke them unless you resort to rather gruesome procedures, as graphically illustrated in Minority Report where Tom Cruise has a clandestine eyeball transplant to fool the police's iris scanner. The other one is that your biometrics identify you uniquely and therefore they allow colluding verifiers to link your activities across domains. So your employer, your mental health clinic, your political party, your telecomms provider and so forth (not to mention your friendly government agencies, which already do) would be in a position to build a dossier of everything you do and everywhere you go.
Pico, instead, is designed from the start to protect your privacy: its protocols are designed to ensure that even two colluding verifiers can't tell whether it's you or two different users. Even better, you can open two email accounts on the same provider and they won't know that they're linked (unless of course you disclose it by leaking that information at other layers in the stack).
Having said that, there is scope for a biometric input to contribute to unlocking the Pico device itself, alongside the radio-based Picosiblings. This would help address the scenario in which the user goes swimming and must leave all electronics in a swimming pool locker.
In our base design, this is supported by the Pico having a different set of credentials for every account. You can have different email accounts for work, family and hobbies, for example. By design, to protect your privacy, the provider can't tell they're all linked to you, so you'll first have to select the chosen persona on your Pico.
An alternative, which some users might find simpler, might be to have a different Pico (real or virtual) for every persona. We are prototyping all of these options and more, and testing them with users, to find out which will be the easiest to understand and manage for non-geeks.
Well, in an ideal world you'd have the backups of your phone (you do take backups regularly, right?). In practice this may be unrealistic so the Pico App additionally takes an encrypted cloud backup of its own every time you teach it a new password. You choose where: Dropbox, Google drive, whatever.
Provided the attacker (at the site holding your backups) can't break the encryption, they can notice that you just opened a new account but they can't tell at which site, unless they are a much more powerful Global Observer (think NSA etc) that can monitor the whole network. We may allow propellerheads to run their own backup server, rather than relying on a commercial cloud provider, but that wouldn't be of great help to the regular human beings incapable of doing so. Besides, even that would have trouble resisting a Global Observer who could monitor the whole network. Other options, such as local radio-based backups, anonymous cloud backups, decoy writes and so forth are topics for our future research. In any case, making Pico privacy-protecting remains a design priority.
The main issue here is to stop the Pico from thinking the siblings are nearby when in fact they are far away, with their messages being detected and relayed to local fake siblings. This is a well-studied problem in the literature (see e.g. Beth-Desmedt, Brands-Chaum, Hancke-Kuhn...) and an effective solution is a distance-bounding protocol based on the fact that the speed of light is finite: with accurate timing of the challenges and responses we can detect a relay attack because no remote attacker can respond as quickly as a genuine Picosibling that is within arm's reach.
This is a more elaborate problem, and one to which several other authentication systems are vulnerable. Distance bounding cannot be the solution, here, because even the legitimate prover has to go over the Internet, with unpredictable routes and timings. We have studied the problem extensively, identifying a whole class of vulnerable systems that work in similar ways to Pico. Several of them push the burden of defense back on the user, who is called upon detecting that a relay is taking place by examining subtle cues; but we believe this approach is both unfair and ineffective, as the user's attention is then legitimately elsewhere, and it's relatively easy for a fraudster to camouflage as something that a normal user can't be expected to distinguish from the genuine article. We devised a better solution. It's described in our "lousy phish" paper.
If no limits are imposed on what the adversary can do, including abduction and unbounded physical violence towards victims and their loved ones, I believe it's always going to be possible to describe a hypothetical worst-case scenario in which the protection offered by any given authentication system (whatever it may be) would be insufficient.
As I believe I explained in the coercion resistance section of the original Pico paper you mention, there is a crucial trade-off between confidentiality and availability. If confidentiality must be protected at all costs, and I value it so much that I prefer my credentials to become inaccessible for all rather than accessible to my enemies (even if it means forever inaccessible to me too), then this can be achieved relatively easily by the "cyanide pill" strategy of destroying the Pico when I fall into enemy hands, and for very high security applications this could even be facilitated in hardware with appropriate physical-self-destruction mechanisms (microscopic shaped charges etc) aimed at being more thoroughly destructive of the stored secrets than merely smashing the device. (But, if we are exploring improbable paranoid scenarios, note also that, as I remarked in footnote 65, the fact that you make it impossible for the mafiosi to obtain your credentials by torturing you does not guarantee that they won't still torture you anyway; maybe because they didn't read the FAQ and don't understand that even you can no longer recover the credentials; maybe in revenge for that; or maybe just because they sadistically enjoy it.)
Having said that, the cost of losing access forever will usually be too high for most users and therefore a solution involving a backup will often be preferred. The victim can still destroy the Pico when mugged/abducted but can then restore the credentials on a blank new one after being released. This strategy will work against many classes of attackers but, because a way of recovering the credentials still exists, the really evil and powerful attackers could still coerce/torture the victim to force use of the backups even if the Pico has been destroyed.
My design stance is that security is risk management. Different threat models require different solutions and users should not be forced to pay a price not commensurate to their risk profile. The Pico platform will support a spectrum of solutions, from the very relaxed to the ultra-paranoid (the "cyanide pill and no backups" option will still be available, on request, for James Bond's Pico), but by default will not impose on ordinary users the burdens associated with the most paranoid scenarios.
With passwords, you are required to use a different one for every site, it can't be a dictionary word or a name, it must have a long enough mixture of lowercase, uppercase, digits and symbols, you are not allowed to write it down, etc etc etc. It's impossible for anyone to comply with all these requirements at once, so people violate at least some of these directives (for example by recycling passwords at more than one site, or by writing them down); but, if they get hacked, then they get blamed for not having followed the rules. (Read your online banking contract for what you're supposed to do with your PIN, for example, and what you'll be blamed for if you don't.) I like to think that, if people had the choice of using either passwords or Pico, which is much easier to use and doesn't require memorization of secrets, besides also being more secure, they'd probably pick the easier option.
For people to have that choice, though, of using either passwords or Pico, they'd have to be able to use Pico wherever they already use passwords today. So maybe the answer is: for people to adopt it, Pico would have to be supported by most of the places that ask people to type in their passwords. This is a hard struggle but we have a plan, and a secret weapon---the Pico Lens! (More on this in another question and in our "bootstrapping adoption" paper.)
From the viewpoint of the web sites, a very good reason for adopting the Pico system is that it would spare them the reputation loss of ending up on the front page of the Financial Times with a headline like "Ebay warns 128m users to change password after hackers break in"---this is an actual one from 22 May 2014 but there's a similar one almost every other month (the latest one being that of the Russian hackers who allegedly stole over a billion passwords). With Pico, which uses public key crypto instead of passwords that can be cracked offline, even if the bad guys hacked your site, they would not obtain any login credentials---just the public keys of your users, which cannot be used to impersonate them.
It means their Pico won't work unless the web site they visit explicitly supports Pico. This causes a vicious circle: people will have no incentive to get a Pico if their favourite sites won't support it, while sites will have no incentive to support Pico if none of their users have one.
To address this problem we created the Pico Lens: an add-on for your web browser that transforms the login pages of the sites you visit, rewriting them as Pico-compatible pages. From the viewpoint of the user, the site looks as if it were Pico-enabled, and they can log in with Pico without typing any password. Behind the scenes, though, the Pico Lens ensures that the web site still receives a password. The user gets most of the usability benefits of Pico and some of its security benefits: it's still more secure than typing a password; just not quite as secure as running the full Pico protocol.
This is a stepping stone that allows people to use their Pico even before web sites support it. Hopefully this breaks the vicious circle: as people use Pico for its convenience anyway, web sites realize they might as well support the full Pico protocol and also get greater security.
To help with deployment, we are also making a "smartphone app" version of Pico: less secure than the dedicated hardware version but no less secure than the e-banking app provided by your bank. Plus, you don't have to carry anything else in your pocket.
Our "bootstrapping adoption" paper gives more details on these technologies.
At the ethical level, Pico aims to eliminate the fundamental unfairness imposed by passwords: non-techies are asked to do an impossible thing (once brilliantly summarized in a Mikko Hypponen tweet as "pick something you can't remember, then don't write it down") and then are blamed if they don't. As architects of the digital society, we have a responsibility to offer a better deal than that to the rest of humanity. Pico is meant to be much easier to use than passwords, and doesn't require you to do impossible things.
At the practical level, Pico wants you to be able to log in without having to remember any secrets, be they passwords, PINs, passphrases, images, finger squiggles or whatever. Remembering secrets is a solution that can't possibly scale if you need a different one for every account you have.
If you have another question, write to cl-pico-faq at lists.cam.ac.uk. We can't promise individual replies, but answers to popular questions will be added here.
I don't have a question for the FAQ, but how else can I get in touch? ➤