Abstract
Pico is a user authentication system that does not require remembering secrets. It is based on a personal handheld token that holds the user’s credentials and that is unlocked by a “personal aura” generated by digital accessories worn by the owner. The token, acting as prover, engages in a public-key-based authentication protocol with the verifier. What would happen to Pico if success of the mythical quantum computer meant secure public key primitives were no longer available, or if for other reasons such as energy consumption we preferred not to deploy them? More generally, what would happen under those circumstances to user authentication on the web, which relies heavily on public key cryptography through HTTPS/TLS?
Although the symmetric-key-vs-public-key debate dates back to the 1990s, we note that the problematic aspects of public key deployment that were identified back then are still ubiquitous today. In particular, although public key cryptography is widely deployed on the web, revocation still doesn’t work.
We discuss ways of providing desirable properties of public-key-based user authentication systems using symmetric-key primitives and tamper-evident tokens. In particular, we present a protocol through which a compromise of the user credentials file at one website does not require users to change their credentials at that website or any other.
We also note that the current prototype of Pico, when working in compatibility mode through the Pico Lens (i.e. with websites that are unaware of the Pico protocols), doesn’t actually use public key cryptography, other than that implicit in TLS. With minor tweaks we adopt this as the native mode for Pico, dropping public key cryptography and achieving much greater deployability without any noteworthy loss in security.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
Reversibly encrypted with 3DES, not salted and hashed as they should have been. To add the insult to the injury, the encryption was performed by treating each block independently, in ECB mode.
- 2.
Splashdata publish an annual list: the most recent one at the time of writing is http://splashdata.com/press/worst-passwords-of-2014.htm.
- 3.
This may not be part of the advice John receives from bettersite.com when they ask him to change his password there, since they have no incentive about protecting his other accounts, despite the fact that it is the leak at their site that has made John vulnerable to fraud elsewhere. But they might argue that it was John’s reuse of his password that put him at risk and that, since he contravened their advice against it, it was his fault. We do not condone this buck-passing, since demanding that users remember complex and distinct passwords for each site is unreasonable in the first place.
- 4.
A better designed password mechanism should blacklist all passwords that have appeared in a document, at least as far as the maintainers of the system are able to figure out. If they knew about this paper, for example, then even Emily’s password would no longer be acceptable. VAX/VMS, developed in the 1970s, rejected all of the password examples that appeared in its own documentation.
- 5.
This corresponds to having different passwords for the different site, but without Emily having to remember them because the Pico does that for her.
- 6.
Which was the germ of the discussion among the first three authors that eventually resulted in this paper.
- 7.
Although we know that this often doesn’t happen, as documented by Bonneau and Preibusch [4].
- 8.
- 9.
Some people, but not us, no longer call this a password, because users can’t remember it. Note that, if the attacker can perform any industrial-sized number of guessing attempts offline, most passwords that the average user will actually remember are vulnerable.
- 10.
They consist essentially of a set of semantic labels for the HTML of the login form, saying in a machine-readable format that this is a login form, this field is the username, this field is the password and so on. The HTML5 specification contains something similar and some web browsers recognise this. For example, you may specify a policy that when web forms are cached any password fields are omitted from the data that is cached.
- 11.
Why “almost”? Because, with public key, there is the additional benefit that the website cannot impersonate the user. This does not affect accounts at other sites if the user adopts a different password for each, but it does affect logins at the site itself. Without public key, the website, which on exit from the TLS tunnel receives the user’s password in plaintext even though it is not supposed to store it other than salted and hashed, could pretend to a third party that the user authenticated at other times. With public key, it would not be able to produce evidence of any other logins than the ones in which the user actually replied correctly to the challenge. As with other arguments in favour of public key, this one too becomes problematic once the possibility of revocation is accounted for. It should also be noted that a better web login scheme would allow the prover to demonstrate knowledge of the shared secret without revealing it—cfr “Level 3” in Sect. 5.1.
- 12.
In this context, secure means offering confidentiality, freshness and authenticity of source and destination.
- 13.
Note that we are not even beginning to address the even more complex human factors problem that the average user can’t understand the difference between the HTTPS padlock in the address bar (whose appearance changes between browsers and between versions of the same browser anyway) and a bitmap of a padlock in the client area of the page, and can therefore be phished.
- 14.
It was a common discussion theme at conferences such as Oakland in the mid-1990s, and the subject was also discussed by the Internet Research Task Force (IRTF) Privacy Task Force in the late 1980’s/early 1990’s. It was widely understood that both symmetric key set-up cost and public key revocation cost were of order \(k \log N\) with N counterparties in the case of hierarchical servers. Possibly for economic reasons the early CAs pushed for short certificate life, rather than effective revocation mechanisms, contributing to the rather unsatisfactory situation that we have today. Interestingly, version 1 of the SWIFT protocol used a trusted logger in conjunction with symmetric keys to prevent message forgery, and 3GPP has a current Generic Authentication Architecture that is based on symmetric-key. The authors would be delighted to hear from any readers who are aware of other publications that address in a measured way the trade-offs between symmetric and public key in the presence of revocation.
- 15.
For example via public key certificates propagating in an uncontrolled way.
- 16.
As well as a privacy concern—because a global observer can now link your interactions with the various websites to which your Pico issues revocation requests by their timing and network origin.
- 17.
Note also that there are often more than two parties involved in a session. I may authenticate Amazon when I buy a book, but the part of the transaction I really care about is the payment via my bank. Unfortunately the current protocol requires Amazon to protect my credit card details so I should check the revocation status of Amazon’s certificate. A better protocol would allow me to send an encrypted bundle to Amazon (running the risk that it isn’t Amazon) which instructs my bank to pay Amazon (say) £20. Only the bank, not Amazon, should be able to decrypt that bundle.
- 18.
There is an alternative that is used in many financial networks. The decision to check for revocation might depend upon the value of the transaction. When buying a coffee I might neglect to check revocation status, accepting the risk. When ordering a new television I might insist on checking the status because the value at risk is higher. However this assumes a protocol that prevents the coffee shop from reusing my credentials to buy a television.
- 19.
It is interesting to note that browser makers can decide individually on the policy they choose, though they compete against each other on security, features and especially performance.
- 20.
We don’t hear much about such attacks. Is it because they don’t happen and we shouldn’t worry or because they happen so effectively that we are not aware of them?
- 21.
This design is architecturally plausible but has the potentially undesirable property that now the client and the website must trust Visa (or equivalent) not just with their money, but also with the confidentiality and authenticity of all their subsequent communications with the website. This problem is shared by all KDS mechanisms; one solution is to combine several keys distributed by mutually mistrusting authentication servers, at the expense of further complexity, latency and potential failure points.
- 22.
Notation: \(K^+\) is a public key and \(K^-\) is the matching private key. A K without exponent is a symmetric key. \(E_{K^+} [m]\) or \(E_K [m]\) is the encryption of message m under key \(K^+\) or K respectively, whereas \(D_{K^-}[m]\) or \(S_{K^-} [m]\) is the decryption or signature, respectively, of message m with key \(K^-\). Finally, h(m) is the one-way hash of message m.
- 23.
The security requirements for posting revocations are surprisingly subtle. Clearly public visibility, persistence, and integrity of the revocation string all need to be assured by the publisher, to prevent the attacker from overwriting it. But what about a denial of service attack where the attacker publishes a bogus revocation string to prevent the correct principal from publishing the real one? We can’t require the principal that is revoking their keys to authenticate themselves to the publisher in any conventional way: after all, the keys are being revoked precisely because they may have been stolen. One possibility is for the principal to pre-reserve space with the publisher at an “address” corresponding to a hash of the revocation string, with the agreement that the publisher will allow only the corresponding pre-image to be published at that address. Notice that we needn’t care who it is that posts the legitimate revocation string: revocation strings are supposed to be kept secret from attackers, so if a revocation string has been stolen then a tamper-evident device has been compromised, and the corresponding keys therefore need to be revoked anyway.
- 24.
Thus, at that stage, the client cannot decrypt the inner set of brackets \( E_{K_w} [ \text{ Revoke }, W, K'_{cw} ]\) which appears as a blob of gibberish.
- 25.
To avoid confusion: even though we call R a revocation string, this string is necessary but not sufficient to cause a revocation. It behaves like an inert component until activated by primer \(K_w\), mentioned next, which is the trigger for the revocation.
- 26.
In the client case, after first decrypting R using \(K_{cw}\). Forgetting \(K_{cw}\) gives forward security: a subsequent leak of \(K_0 = h(K_{cw})\) does not reveal \(K_{cw}\), so even knowing \(K_w\) the attacker still cannot obtain \(K'_{cw}\) from R.
- 27.
In contrast, we don’t need to worry about the attacker learning the revocation codes as a result of the attack, but we do need to ensure that the principals can still get access to these codes after the attack has happened.
- 28.
This is similar to the threat model of Yu and Ryan [12].
- 29.
This involves checking for the absence of the appropriate revocation string, both in the public key and in the symmetric key case. When a key is revoked, the replacement key is used to share the latest time guaranteed to be before the breach, that is, the latest time at which the tamper-evident hardware was known to be intact. Sessions between then and the new pipe build are assumed to be compromised.
- 30.
Prover Alice sends the verifier a succession of \(x_i\) with increasing i. The verifying website holds \(x_i\) from the previous round and cannot derive \(x_{i+1}\) from it, but if it receives \(x_{i+1}\) it can verify it’s genuine by checking whether \(h(x_{i+1}) = x_i\). The number n is the length of the chain and determines the number of logins that Alice can perform before having to reload the chain. A version of the Guy Fawkes protocol [13] can be used to refresh \(x_0\) when n is exhausted.
- 31.
The table entry accessed by \(t_i\) will include \(h(T_A)\), where \(T_A\) is the revocation string for Alice. Alice initiates the revocation protocol with W by revealing \(T_A\).
- 32.
To allow for the possibility that the two parties might get out of sync, for example through non-malicious communication errors, we might relax the verification slightly. If the pre-image check fails, the verifier should hash again for a configurable number of times. If a match is found, they will have both authenticated and resynchronized.
- 33.
Note that the hash chains \(x_i\) and \(K_i\) run in opposite directions. The Lamport hash chain is \(x_i\).
- 34.
Of course, following a second break-in to the website, the attacker will be able to correlate client identities from the second attack with those stolen from the first. Just as in the public-key case, clients who wish to prevent this will need to update their login credentials (\(x_0\) or \(K^-\) in the symmetric and public key cases respectively) before the second attack. However no third-party mediated authentication is required for this.
- 35.
Hopefully not merely a Needham optimization: replacing something that works with something that almost works but is cheaper.
- 36.
As we said, HTML5 also supports similar annotations.
- 37.
We suggested \(t=64\) characters taken at random from the base64 alphabet.
- 38.
The website is able to distinguish machine-generated passwords by their length and flag them as such in the hashed credentials file. The website is therefore in a position not to bother those users with a password reset, since their password cannot be realistically brute-forced from the hash even by an arbitrarily powerful offline adversary.
- 39.
They are instead t-character-long random sequences of base64 characters. With \(t=64\) they are equivalent to 384-bit symmetric keys.
- 40.
In the sense of allowing an adversary to derive the private key from the public key, for key sizes that are today considered secure against the strongest classical computers.
References
Hern, A.: Did your adobe password leak? now you and 150m others can check. http://www.theguardian.com/technology/2013/nov/07/adobe-password-leak-can-check (2013). Accessed 28 May 2015
Morris, R., Thompson, K.: Password security: a case history. Commun. ACM 22(11), 594–597 (1979)
Stajano, F.: Pico: no more passwords!. In: Christianson, B., Crispo, B., Malcolm, J., Stajano, F. (eds.) Security Protocols 2011. LNCS, vol. 7114, pp. 49–81. Springer, Heidelberg (2011)
Bonneau, J., Preibusch, S.: The password thicket: technical and market failures in human authentication on the web. In: Proceedings of the Ninth Workshop on the Economics of Information Security (WEIS), June 2010
Stajano, F., Spencer, M., Jenkinson, G., Stafford-Fraser, Q.: Password-manager friendly (PMF): Semantic annotations to improve the effectiveness of password managers. In: Proceedings of the Passwords 2014. Springer, Heidelberg (2014, to appear). http://mypico.org/documents/2014-StaSpeJen-pmf.pdf
Stajano, F., Jenkinson, G., Payne, J., Spencer, M., Stafford-Fraser, Q., Warrington, C.: Bootstrapping adoption of the pico password replacement system. In: Christianson, B., Malcolm, J., Matyáš, V., Švenda, P., Stajano, F., Anderson, J. (eds.) Security Protocols 2014. LNCS, vol. 8809, pp. 172–186. Springer, Heidelberg (2014)
Krawczyk, H.: SIGMA: the ‘SIGn-and-MAc’ approach to authenticated Diffie-Hellman and its use in the IKE protocols. In: Boneh, D. (ed.) CRYPTO 2003. LNCS, vol. 2729, pp. 400–425. Springer, Heidelberg (2003). http://www.ee.technion.ac.il/hugo/sigma.html
Needham, R.M., Schroeder, M.D.: Using encryption for authentication in large networks of computers. Commun. ACM 21(12), 993–999 (1978)
Kohl, J., Neuman, C.: The kerberos network authentication service (v5) (1993)
Christianson, B., Crispo, B., Malcolm, J.A.: Public-key crypto-systems using symmetric-key crypto-algorithms. In: Christianson, B., Crispo, B., Malcolm, J.A., Roe, M. (eds.) Security Protocols 2000. LNCS, vol. 2133, pp. 182–183. Springer, Heidelberg (2001)
Myers, M., Ankney, R., Malpani, A., Galperin, S., Adams, C.: RFC 2560, X. 509 internet public key infrastructure online certificate status protocol-OCSP. Internet Engineering Task Force (1999)
Yu, J., Ryan, M.D.: Device attacker models: fact and fiction. In: Christianson, B., et al. (eds.) Security Protocols 2015. LNCS, vol. 9379, pp. 155–164. Springer, Switzerland (2015)
Anderson, R., Bergadano, F., Crispo, B., Lee, J.H., Manifavas, C., Needham, R.: A new family of authentication protocols (1998)
Bonneau, J., Herley, C., van Oorschot, P.C.v., Stajano, F.: The quest to replace passwords: a framework for comparative evaluation of web authentication schemes. In: Proceedings of the 2012 IEEE Symposium on Security and Privacy, SP 2012, pp. 553–567. IEEE Computer Society, Washington, DC (2012)
Bonneau, J.: Getting web authentication right: a best-case protocol for the remaining life of passwords. In: Christianson, B., Crispo, B., Malcolm, J., Stajano, F. (eds.) Security Protocols 2011. LNCS, vol. 7114, pp. 98–104. Springer, Heidelberg (2011)
Acknowledgements
We thank Ross Anderson, Bruno Crispo, Michael Roe and Alf Zugenmaier for their comments on the history of the public key vs symmetric key user authentication debate. Thanks also to Steven Murdoch for his comments on revocation on the web today. The authors with a Cambridge affiliation are grateful to the European Research Council for funding this research through grant StG 307224 (Pico).
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Rights and permissions
Copyright information
© 2015 Springer International Publishing Switzerland
About this paper
Cite this paper
Stajano, F. et al. (2015). Pico Without Public Keys. In: Christianson, B., Švenda, P., Matyáš, V., Malcolm, J., Stajano, F., Anderson, J. (eds) Security Protocols XXIII. Security Protocols 2015. Lecture Notes in Computer Science(), vol 9379. Springer, Cham. https://doi.org/10.1007/978-3-319-26096-9_21
Download citation
DOI: https://doi.org/10.1007/978-3-319-26096-9_21
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-319-26095-2
Online ISBN: 978-3-319-26096-9
eBook Packages: Computer ScienceComputer Science (R0)