From d249e5e306fb4ad3462169df22d122d69a59c93b Mon Sep 17 00:00:00 2001 From: Shane Killian Date: Mon, 19 Feb 2018 13:52:01 -0500 Subject: [PATCH] Resync (#3) * Identity Creation * Identity Recovery and Rekey * Abstract & Introduction * Added ShortPass Appendix to Outline * Rebuild --- draft-sqrl.txt | 836 +++++++++++++++++++++++++++------------------ src/draft-sqrl.xml | 175 ++++++---- 2 files changed, 613 insertions(+), 398 deletions(-) diff --git a/draft-sqrl.txt b/draft-sqrl.txt index bbdaa75..1b85689 100644 --- a/draft-sqrl.txt +++ b/draft-sqrl.txt @@ -5,7 +5,7 @@ Internet Engineering Task Force A. Comley, Ed. Internet-Draft Intended status: Informational S. Killian, Ed. -Expires: August 22, 2018 February 18, 2018 +Expires: August 23, 2018 February 19, 2018 Secure Quick Reliable Login (SQRL), an Authentication and Identity @@ -14,17 +14,24 @@ Expires: August 22, 2018 February 18, 2018 Abstract - Secure Quick Reliable Login (SQRL) is an authentication method and - identity management framework. It enables a user to create and - manage a single, pseudonymous lifetime identity. That identity will - allow the user to securely authenticate with any SQRL enabled server - without relying on a third party or disclosing personally - identifiable information. + Secure Quick Reliable Login (SQRL) is an application-level protocol + for user authentication and identity management. It enables a user + to create and manage a single pseudonymous lifetime identity. That + identity will allow the user to securely authenticate with any SQRL + enabled server without relying on a third party or disclosing + personally identifiable information. - SQRL's identity management framework gives the user complete control - over their online identity, including provisions for recovering from - the loss of their identity file or password and recovering from - potential security breaches. + It provides: + + o Unique pseudonymous identifiers for each site + + o Separation of identity management from account management + + o Strong anti-phishing protection + + o No shared secrets that can be exploited by bad actors + + o Out-of-band authentication for logging in on untrusted devices Status of This Memo @@ -41,23 +48,23 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 22, 2018. - -Copyright Notice - - Copyright (c) 2018 IETF Trust and the persons identified as the - document authors. All rights reserved. + This Internet-Draft will expire on August 23, 2018. - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents -Comley & Killian Expires August 22, 2018 [Page 1] +Comley & Killian Expires August 23, 2018 [Page 1] Internet-Draft SQRL February 2018 +Copyright Notice + + Copyright (c) 2018 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect @@ -69,125 +76,156 @@ Internet-Draft SQRL February 2018 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 - 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.1. Standard Algorithms . . . . . . . . . . . . . . . . . . . 5 + 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6 + 1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 + 2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.1. Standard Algorithms . . . . . . . . . . . . . . . . . . . 6 2.2. base56check . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 6 - 2.2.2. Validation . . . . . . . . . . . . . . . . . . . . . 7 + 2.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 7 + 2.2.2. Validation . . . . . . . . . . . . . . . . . . . . . 8 2.2.3. Decoding . . . . . . . . . . . . . . . . . . . . . . 8 - 2.3. EnHash . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 2.3. EnHash . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4. EnScrypt . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Cryptographic Keys, Secrets, and Passwords . . . . . . . . . 10 - 3.1. Class A Secrets . . . . . . . . . . . . . . . . . . . . . 10 - 3.1.1. Identity Unlock Key (IUK) . . . . . . . . . . . . . . 10 - 3.1.2. Unlock Request Signing Key (URSK) . . . . . . . . . . 10 + 3.1. Class A Secrets . . . . . . . . . . . . . . . . . . . . . 11 + 3.1.1. Identity Unlock Key (IUK) . . . . . . . . . . . . . . 11 + 3.1.2. Unlock Request Signing Key (URSK) . . . . . . . . . . 11 3.1.3. Rescue Code (RC) . . . . . . . . . . . . . . . . . . 11 - 3.1.4. Password Derived Keys . . . . . . . . . . . . . . . . 11 - 3.2. Class B Secrets . . . . . . . . . . . . . . . . . . . . . 11 - 3.2.1. Previous Identity Unlock Key (PIUK) . . . . . . . . . 12 - 3.2.2. Identity Master Key (IMK) . . . . . . . . . . . . . . 12 - 3.2.3. Identity Lock Key (ILK) . . . . . . . . . . . . . . . 12 - 3.2.4. Site Specific Secret Key (SSSK) . . . . . . . . . . . 12 - 3.2.5. Random Lock Key (RLK) . . . . . . . . . . . . . . . . 12 + 3.1.4. Password Derived Keys . . . . . . . . . . . . . . . . 12 + 3.2. Class B Secrets . . . . . . . . . . . . . . . . . . . . . 12 + 3.2.1. Previous Identity Unlock Key (PIUK) . . . . . . . . . 13 + 3.2.2. Identity Master Key (IMK) . . . . . . . . . . . . . . 13 + 3.2.3. Identity Lock Key (ILK) . . . . . . . . . . . . . . . 13 + 3.2.4. Site Specific Secret Key (SSSK) . . . . . . . . . . . 13 + 3.2.5. Random Lock Key (RLK) . . . . . . . . . . . . . . . . 13 3.3. Class C (Public) Keys . . . . . . . . . . . . . . . . . . 13 3.3.1. Site Specific Public Key (SSPK) . . . . . . . . . . . 13 - 3.3.2. Server Unlock Key (SUK) . . . . . . . . . . . . . . . 13 - 3.3.3. Verify Unlock Key (VUK) . . . . . . . . . . . . . . . 13 - 4. Identity Management . . . . . . . . . . . . . . . . . . . . . 13 - 4.1. Identity Lifecycle . . . . . . . . . . . . . . . . . . . 13 - 4.2. User Options . . . . . . . . . . . . . . . . . . . . . . 13 - 4.3. Identity Storage . . . . . . . . . . . . . . . . . . . . 14 - 4.3.1. Storage Blocks . . . . . . . . . . . . . . . . . . . 15 - 4.3.2. Predefined Block Types . . . . . . . . . . . . . . . 15 - 4.3.3. Encoding . . . . . . . . . . . . . . . . . . . . . . 18 - 4.4. Identity Operations . . . . . . . . . . . . . . . . . . . 18 - 4.4.1. Identity Creation . . . . . . . . . . . . . . . . . . 19 - 4.4.2. Importing / Exporting an Identity . . . . . . . . . . 19 - 4.4.3. Changing the User's Password . . . . . . . . . . . . 19 - - - -Comley & Killian Expires August 22, 2018 [Page 2] + 3.3.2. Server Unlock Key (SUK) . . . . . . . . . . . . . . . 14 + 3.3.3. Verify Unlock Key (VUK) . . . . . . . . . . . . . . . 14 + 4. Identity Management . . . . . . . . . . . . . . . . . . . . . 14 + 4.1. Identity Lifecycle . . . . . . . . . . . . . . . . . . . 14 + + + +Comley & Killian Expires August 23, 2018 [Page 2] Internet-Draft SQRL February 2018 - 4.4.4. Identity Recovery . . . . . . . . . . . . . . . . . . 19 - 4.4.5. Re-Keying an Identity . . . . . . . . . . . . . . . . 20 - 5. Client-Server Protocol . . . . . . . . . . . . . . . . . . . 20 - 5.1. Initiation of SQRL Authentication . . . . . . . . . . . . 20 - 5.1.1. The SQRL Scheme . . . . . . . . . . . . . . . . . . . 20 - 5.1.2. QR Codes (Out of Band) . . . . . . . . . . . . . . . 20 - 5.2. The SQRL Realm (Domain) . . . . . . . . . . . . . . . . . 20 - 5.3. Client to Server Requests . . . . . . . . . . . . . . . . 20 - 5.3.1. Protocol Version . . . . . . . . . . . . . . . . . . 20 - 5.3.2. Commands . . . . . . . . . . . . . . . . . . . . . . 20 - 5.3.3. Options . . . . . . . . . . . . . . . . . . . . . . . 20 - 5.3.4. The server Value . . . . . . . . . . . . . . . . . . 20 - 5.3.5. The client Value . . . . . . . . . . . . . . . . . . 21 - 5.3.6. Client Keys . . . . . . . . . . . . . . . . . . . . . 21 - 5.3.7. Client Signatures . . . . . . . . . . . . . . . . . . 21 - 5.3.8. Composing the Request . . . . . . . . . . . . . . . . 21 - 5.4. Server to Client Replies . . . . . . . . . . . . . . . . 21 - 5.4.1. Required Values . . . . . . . . . . . . . . . . . . . 21 - 5.4.2. Optional Values . . . . . . . . . . . . . . . . . . . 21 - 5.4.3. Additional Values . . . . . . . . . . . . . . . . . . 21 - 5.4.4. Composing the Reply . . . . . . . . . . . . . . . . . 21 - 6. Client-Server Interactions . . . . . . . . . . . . . . . . . 21 - 6.1. Same Device Authentication . . . . . . . . . . . . . . . 21 - 6.2. Cross Device Authentication . . . . . . . . . . . . . . . 22 - 6.3. Identity Association . . . . . . . . . . . . . . . . . . 22 - 6.4. Updating Identity Association . . . . . . . . . . . . . . 22 - 6.5. Disabling Site Login . . . . . . . . . . . . . . . . . . 22 - 6.6. Re-Enabling Site Login . . . . . . . . . . . . . . . . . 22 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 - 8.1. Phishing . . . . . . . . . . . . . . . . . . . . . . . . 23 - 8.2. Shoulder-Surfing . . . . . . . . . . . . . . . . . . . . 24 - 8.3. Evil Router . . . . . . . . . . . . . . . . . . . . . . . 25 - 8.4. Server Compromise . . . . . . . . . . . . . . . . . . . . 25 - 8.5. CPU Flooding . . . . . . . . . . . . . . . . . . . . . . 26 - 8.6. Evil Client . . . . . . . . . . . . . . . . . . . . . . . 26 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 27 - 9.2. Informative References . . . . . . . . . . . . . . . . . 28 - Appendix A. Recommendations and Best Practices . . . . . . . . . 28 - A.1. For Clients . . . . . . . . . . . . . . . . . . . . . . . 28 - A.2. For Servers . . . . . . . . . . . . . . . . . . . . . . . 28 - A.3. For Users . . . . . . . . . . . . . . . . . . . . . . . . 28 - A.3.1. Master Password . . . . . . . . . . . . . . . . . . . 29 - A.3.2. Identity Backup . . . . . . . . . . . . . . . . . . . 29 - A.3.3. Disaster Recovery . . . . . . . . . . . . . . . . . . 29 - Appendix B. Harvesting Entropy . . . . . . . . . . . . . . . . . 30 - B.1. Entropy Sources . . . . . . . . . . . . . . . . . . . . . 31 - - - -Comley & Killian Expires August 22, 2018 [Page 3] + 4.2. User Options . . . . . . . . . . . . . . . . . . . . . . 14 + 4.3. Identity Storage . . . . . . . . . . . . . . . . . . . . 15 + 4.3.1. Storage Blocks . . . . . . . . . . . . . . . . . . . 16 + 4.3.2. Predefined Block Types . . . . . . . . . . . . . . . 16 + 4.3.3. Encoding . . . . . . . . . . . . . . . . . . . . . . 19 + 4.4. Identity Operations . . . . . . . . . . . . . . . . . . . 19 + 4.4.1. Identity Creation . . . . . . . . . . . . . . . . . . 20 + 4.4.2. Importing / Exporting an Identity . . . . . . . . . . 21 + 4.4.3. Changing the User's Password . . . . . . . . . . . . 21 + 4.4.4. Identity Recovery . . . . . . . . . . . . . . . . . . 21 + 4.4.5. Rekeying an Identity . . . . . . . . . . . . . . . . 22 + 5. Client-Server Protocol . . . . . . . . . . . . . . . . . . . 23 + 5.1. Initiation of SQRL Authentication . . . . . . . . . . . . 23 + 5.1.1. The SQRL Scheme . . . . . . . . . . . . . . . . . . . 23 + 5.1.2. QR Codes (Out of Band) . . . . . . . . . . . . . . . 23 + 5.2. The SQRL Realm (Domain) . . . . . . . . . . . . . . . . . 23 + 5.3. Client to Server Requests . . . . . . . . . . . . . . . . 23 + 5.3.1. Protocol Version . . . . . . . . . . . . . . . . . . 23 + 5.3.2. Commands . . . . . . . . . . . . . . . . . . . . . . 23 + 5.3.3. Options . . . . . . . . . . . . . . . . . . . . . . . 23 + 5.3.4. The server Value . . . . . . . . . . . . . . . . . . 23 + 5.3.5. The client Value . . . . . . . . . . . . . . . . . . 23 + 5.3.6. Client Keys . . . . . . . . . . . . . . . . . . . . . 24 + 5.3.7. Client Signatures . . . . . . . . . . . . . . . . . . 24 + 5.3.8. Composing the Request . . . . . . . . . . . . . . . . 24 + 5.4. Server to Client Replies . . . . . . . . . . . . . . . . 24 + 5.4.1. Required Values . . . . . . . . . . . . . . . . . . . 24 + 5.4.2. Optional Values . . . . . . . . . . . . . . . . . . . 24 + 5.4.3. Additional Values . . . . . . . . . . . . . . . . . . 24 + 5.4.4. Composing the Reply . . . . . . . . . . . . . . . . . 24 + 6. Client-Server Interactions . . . . . . . . . . . . . . . . . 24 + 6.1. Same Device Authentication . . . . . . . . . . . . . . . 24 + 6.2. Cross Device Authentication . . . . . . . . . . . . . . . 24 + 6.3. Identity Association . . . . . . . . . . . . . . . . . . 25 + 6.4. Updating Identity Association . . . . . . . . . . . . . . 25 + 6.5. Disabling Site Login . . . . . . . . . . . . . . . . . . 25 + 6.6. Re-Enabling Site Login . . . . . . . . . . . . . . . . . 25 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 8.1. Phishing . . . . . . . . . . . . . . . . . . . . . . . . 25 + 8.2. Shoulder-Surfing . . . . . . . . . . . . . . . . . . . . 27 + 8.3. Evil Router . . . . . . . . . . . . . . . . . . . . . . . 27 + 8.4. Server Compromise . . . . . . . . . . . . . . . . . . . . 28 + 8.5. CPU Flooding . . . . . . . . . . . . . . . . . . . . . . 28 + 8.6. Evil Client . . . . . . . . . . . . . . . . . . . . . . . 29 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 30 + 9.2. Informative References . . . . . . . . . . . . . . . . . 31 + + + +Comley & Killian Expires August 23, 2018 [Page 3] Internet-Draft SQRL February 2018 - B.1.1. Operating System . . . . . . . . . . . . . . . . . . 31 - B.1.2. Hardware . . . . . . . . . . . . . . . . . . . . . . 31 - B.1.3. User . . . . . . . . . . . . . . . . . . . . . . . . 32 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 + Appendix A. Recommendations and Best Practices . . . . . . . . . 31 + A.1. For Clients . . . . . . . . . . . . . . . . . . . . . . . 31 + A.2. For Servers . . . . . . . . . . . . . . . . . . . . . . . 31 + A.3. For Users . . . . . . . . . . . . . . . . . . . . . . . . 31 + A.3.1. Master Password . . . . . . . . . . . . . . . . . . . 31 + A.3.2. Identity Backup . . . . . . . . . . . . . . . . . . . 32 + A.3.3. Disaster Recovery . . . . . . . . . . . . . . . . . . 32 + Appendix B. The Optional ShortPass Feature . . . . . . . . . . . 33 + Appendix C. Harvesting Entropy . . . . . . . . . . . . . . . . . 33 + C.1. Entropy Sources . . . . . . . . . . . . . . . . . . . . . 33 + C.1.1. Operating System . . . . . . . . . . . . . . . . . . 34 + C.1.2. Hardware . . . . . . . . . . . . . . . . . . . . . . 34 + C.1.3. User . . . . . . . . . . . . . . . . . . . . . . . . 35 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 1. Introduction +1.1. Purpose + Secure Quick Reliable Login (SQRL) is an authentication method and - identity management framework with the following features: + identity management framework which gives the user complete control + over their online identity, including provisions for recovering from + the loss of their identity file or password and recovering from + potential security breaches. + +1.2. Features Secure Through a series of cryptographic signatures, the user can prove their identity without disclosing any information that would allow - that identity to be compromised or their account hacked. + that identity to be compromised or their account hacked. SQRL + also provides strong anti-phishing features. + + Identity Management + SQRL separates and delineates the concepts of account and + identity. The user is given full control over their identity and + its full life cycle, while leaving servers with complete control + over account issues. SQRL provides a full identity lifecycle + management framework which allows the user to maintain complete + control of their identity. Even in the event of a compromise, the + user retains the ability to retake control of their identity and + lock the attacker out. Automated rekeying means that the user can + maintain a single SQRL identity indefinitely, even after a + compromise. Global Password The user only has to remember a single password, which is used to locally decrypt their identity during SQRL authentication. Since + + + +Comley & Killian Expires August 23, 2018 [Page 4] + +Internet-Draft SQRL February 2018 + + the user no longer has to remember a unique password for each site, this one global password can be very strong. This strong password combined with strong encryption makes it infeasible for @@ -195,37 +233,35 @@ Internet-Draft SQRL February 2018 apps can alternately use other methods of protection such as biometrics when available on the host device.) - Anonymous + Pseudononymous SQRL authentication is pseudonymous, in that it only provides a secure, site-specific token to the server. This token cannot be directly linked to a user's account at any other server, and provides no personally identifiable information. + No Shared Secrets + Passwords, time-based authenticators, and other authentication + methods work through shared secrets. These secrets can + conceivably be stolen by hackers or rogue employees and used to + impersonate the user. SQRL does not operate through shared + secrets, and even if the server's account database is stolen the + attacker is not given any means to impersonate the user. + No Third Party The user's identity cannot be compromised by a security breach at a third party authentication provider, protecting it from both hackers and overreaching authorities. - User Controlled, Lifetime Identity - SQRL provides an identity management framework which allows the - user to maintain complete control of their identity. Even in the - event that their password is compromised, the user retains the - ability to retake control of their identity and lock the attacker - out. Automated rekeying means that the user can maintain a single - SQRL identity indefinately, even after a compromise + No Per-Site Settings + Unlike password managers, SQRL does not require any information + about specific websites to be saved, preventing potential privacy + issues stemming from information leaks as well as keeping its + database size small. Offline Identity Backup Since SQRL identities are intended to last a lifetime, and there is no third party that can help the user recover their identity if they forget their password, SQRL includes an offline backup - - - -Comley & Killian Expires August 22, 2018 [Page 4] - -Internet-Draft SQRL February 2018 - - mechanism. The user can print out or write down their encrypted identity, along with a secure Rescue Code, that will allow the user to recover from a forgotten password. @@ -236,13 +272,23 @@ Internet-Draft SQRL February 2018 mobile device containing their SQRL identity, without the need to expose that identity to the public system. -1.1. Requirements Language + + + + + +Comley & Killian Expires August 23, 2018 [Page 5] + +Internet-Draft SQRL February 2018 + + +1.3. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. -1.2. Definitions +1.4. Definitions TODO @@ -273,15 +319,6 @@ Internet-Draft SQRL February 2018 o SHA-256 [FIPS.180-4.2015] - - - - -Comley & Killian Expires August 22, 2018 [Page 5] - -Internet-Draft SQRL February 2018 - - o urlencode: Percent-Encoding as defined in Section 2.1 of [RFC3986]. @@ -292,6 +329,15 @@ Internet-Draft SQRL February 2018 o Accepts an arbitrarily sized payload. + + + + +Comley & Killian Expires August 23, 2018 [Page 6] + +Internet-Draft SQRL February 2018 + + o Uses a set of 56 alphanumeric symbols chosen to be easily distinguishable in any font. @@ -329,15 +375,6 @@ Internet-Draft SQRL February 2018 Now, with our converted BASE string, we can calculate the check digits and produce the final output. - - - - -Comley & Killian Expires August 22, 2018 [Page 6] - -Internet-Draft SQRL February 2018 - - 6. Split BASE into 19 character CHUNKS (the final chunk may be smaller). @@ -350,6 +387,13 @@ Internet-Draft SQRL February 2018 C. Treating HASH as a single little-endian number, divide HASH by 56 to obtain REMAINDER. + + +Comley & Killian Expires August 23, 2018 [Page 7] + +Internet-Draft SQRL February 2018 + + D. Replace the last character in CHUNK with the character in ALPHABET at position REMAINDER. @@ -386,14 +430,6 @@ Internet-Draft SQRL February 2018 E. Compare CHECK with the character from ALPHABET at position REMAINDER. - - - -Comley & Killian Expires August 22, 2018 [Page 7] - -Internet-Draft SQRL February 2018 - - F. If comparison passes (is equal), continue. Otherwise, there is an error in this CHUNK. @@ -404,6 +440,16 @@ Internet-Draft SQRL February 2018 1. Start with an empty BASE string and an zero OUTPUT buffer, to be treated as a single, large, little-endian number. + + + + + +Comley & Killian Expires August 23, 2018 [Page 8] + +Internet-Draft SQRL February 2018 + + 2. Perform the base56check validation as described above, appending all but the last character of each validated CHUNK to the BASE string. @@ -439,23 +485,26 @@ Internet-Draft SQRL February 2018 return output; } +2.4. EnScrypt + + EnScrypt is an iterative construct based on the scrypt password based + key derivation function. It hardens scrypt by allowing for extended + processing time. The following parameters are used for the scrypt + function: -Comley & Killian Expires August 22, 2018 [Page 8] - -Internet-Draft SQRL February 2018 -2.4. EnScrypt - EnScrypt is an iterative construct based on the scrypt password based - key derivation function. It hardens scrypt by allowing for extended - processing time. The following parameters are used for the scrypt - function: + +Comley & Killian Expires August 23, 2018 [Page 9] + +Internet-Draft SQRL February 2018 + +-------+------------+-----+---+ | dkLen | N | r | p | @@ -497,21 +546,21 @@ Internet-Draft SQRL February 2018 Timer Mode is used when creating an encryption key from a password. Once the key is derived and the identity encrypted, the resulting + number of iterations is saved with the identity file. Counter Mode + is used to recreate this key and decrypt the identity. +3. Cryptographic Keys, Secrets, and Passwords + SQRL uses a wide variety of secrets in various operations. -Comley & Killian Expires August 22, 2018 [Page 9] - -Internet-Draft SQRL February 2018 - number of iterations is saved with the identity file. Counter Mode - is used to recreate this key and decrypt the identity. -3. Cryptographic Keys, Secrets, and Passwords +Comley & Killian Expires August 23, 2018 [Page 10] + +Internet-Draft SQRL February 2018 - SQRL uses a wide variety of secrets in various operations. 3.1. Class A Secrets @@ -522,7 +571,7 @@ Internet-Draft SQRL February 2018 REQUIRED when dealing with Class A secrets: o The secret MUST be generated using the highest quality entropy - source available to the client. See Appendix B for + source available to the client. See Appendix C for recommendations. o The client MUST prevent the secret from being written to non- @@ -545,7 +594,7 @@ Internet-Draft SQRL February 2018 The IUK is a Class A 256 bit high entropy random number that represents a user's identity. All other identifying keys are derived from this one. After identity creation, this key is only used in - emergency situations, such as re-keying an identity in the event of a + emergency situations, such as rekeying an identity in the event of a possible compromise. 3.1.2. Unlock Request Signing Key (URSK) @@ -555,13 +604,6 @@ Internet-Draft SQRL February 2018 Used by the client to update the identity association on a server, the URSK is derived from the SUK and IUK. - - -Comley & Killian Expires August 22, 2018 [Page 10] - -Internet-Draft SQRL February 2018 - - 3.1.3. Rescue Code (RC) The Rescue Code is a Class A, computer generated, high entropy @@ -569,6 +611,13 @@ Internet-Draft SQRL February 2018 encourage the user to store the Rescue Code in an offline format (printed or written). + + +Comley & Killian Expires August 23, 2018 [Page 11] + +Internet-Draft SQRL February 2018 + + 3.1.4. Password Derived Keys Several keys are generated from user input. Both the user supplied @@ -610,19 +659,20 @@ Internet-Draft SQRL February 2018 volatile memory in plaintext form, including being swapped to disk, by any means possible. + o The plaintext secret MUST be securely wiped from RAM as soon as it + is no longer needed. + o If the secret is to be stored, it MUST be stored in an encrypted + form. -Comley & Killian Expires August 22, 2018 [Page 11] - -Internet-Draft SQRL February 2018 - o The plaintext secret MUST be securely wiped from RAM as soon as it - is no longer needed. - o If the secret is to be stored, it MUST be stored in an encrypted - form. +Comley & Killian Expires August 23, 2018 [Page 12] + +Internet-Draft SQRL February 2018 + o The secret SHOULD NOT be transmitted over the network in any form, and MUST NOT be transmitted unencrypted. @@ -637,7 +687,7 @@ Internet-Draft SQRL February 2018 IMK = EnHash( IUK ); - This Class B ) key acts as a proxy for the IUK during normal SQRL + This Class B key acts as a proxy for the IUK during normal SQRL operation. It is used to generate the unique keys that each site associates with the user. The IMK is derived from the IUK using the EnHash (Section 2.3) function. @@ -662,18 +712,6 @@ Internet-Draft SQRL February 2018 The RLK is generated randomly when the client associates with a new server. - - - - - - - -Comley & Killian Expires August 22, 2018 [Page 12] - -Internet-Draft SQRL February 2018 - - 3.3. Class C (Public) Keys Class C keys are not required to be kept secret. @@ -685,6 +723,13 @@ Internet-Draft SQRL February 2018 The Site Specific Public Key (SSPK) is the public counterpart to the SSSK. It serves as the user's pseudonymous identity on the site. + + +Comley & Killian Expires August 23, 2018 [Page 13] + +Internet-Draft SQRL February 2018 + + 3.3.2. Server Unlock Key (SUK) SUK = curve25519_public_key( RLK ); @@ -712,9 +757,9 @@ Internet-Draft SQRL February 2018 ShortPass Length: The number of characters from the user's password to use as the - ShortPass. Clients that implement ShortPass MUST honor the user's - choice here. Valid values are 0 to 255. A value of 0 disables - the ShortPass feature. + ShortPass (Appendix B). Clients that implement ShortPass MUST + honor the user's choice here. Valid values are 0 to 255. A value + of 0 disables the ShortPass feature. EnScrypt Seconds: The number of seconds to run EnScrypt when deriving the PWDK. The @@ -722,14 +767,6 @@ Internet-Draft SQRL February 2018 second. Idle Timeout: - - - -Comley & Killian Expires August 22, 2018 [Page 13] - -Internet-Draft SQRL February 2018 - - If the client implements ShortPass or holds the user's password or keys in memory in any form, and the 0x0080 option flag is set, it MUST securely erase that memory after this many minutes of system @@ -738,6 +775,17 @@ Internet-Draft SQRL February 2018 Option Flags: The following binary flags turn on or off various user options: + + + + + + +Comley & Killian Expires August 23, 2018 [Page 14] + +Internet-Draft SQRL February 2018 + + +--------+----------------------------------------------------------+ | Flag | Description | +--------+----------------------------------------------------------+ @@ -779,13 +827,6 @@ Internet-Draft SQRL February 2018 standard format. The format described here is RECOMMENDED for both non-volatile and in-memory storage. - - -Comley & Killian Expires August 22, 2018 [Page 14] - -Internet-Draft SQRL February 2018 - - Because identities should be backed up offline (to printed paper), the storage format must be compact enough to reliably fit in a printed QR code, and short enough to not cause undue burden if the @@ -794,6 +835,13 @@ Internet-Draft SQRL February 2018 Values stored in standard SQRL storage format MUST follow these rules: + + +Comley & Killian Expires August 23, 2018 [Page 15] + +Internet-Draft SQRL February 2018 + + o All numeric values are unsigned. o Multibyte numeric values are stored in little endian byte order, @@ -837,7 +885,15 @@ Internet-Draft SQRL February 2018 -Comley & Killian Expires August 22, 2018 [Page 15] + + + + + + + + +Comley & Killian Expires August 23, 2018 [Page 16] Internet-Draft SQRL February 2018 @@ -893,7 +949,7 @@ Internet-Draft SQRL February 2018 -Comley & Killian Expires August 22, 2018 [Page 16] +Comley & Killian Expires August 23, 2018 [Page 17] Internet-Draft SQRL February 2018 @@ -949,7 +1005,7 @@ Internet-Draft SQRL February 2018 -Comley & Killian Expires August 22, 2018 [Page 17] +Comley & Killian Expires August 23, 2018 [Page 18] Internet-Draft SQRL February 2018 @@ -999,20 +1055,75 @@ Internet-Draft SQRL February 2018 4.4. Identity Operations + Identity creation, recovery, and rekeying are particularly vulnerable + times for the SQRL identity, during which several Class A secrets may + be exposed. Special care is required to protect this sensitive key + + + +Comley & Killian Expires August 23, 2018 [Page 19] + +Internet-Draft SQRL February 2018 + + + during these operations. Clients SHOULD inform the user of the + security implications and encourage the user not to perform these + operations on a device that the user believes to be compromised. + +4.4.1. Identity Creation + + The SQRL identity is, in essence, just a long random number (the + IUK). In order to protect the new identity, both during creation and + against future exploits, the client MUST use the highest quality + entropy available to it while creating a new identity. See + Appendix C for recommendations on harvesting entropy. + Creating an identity involves generating a random IUK and Rescue + Code, deriving the IMK and ILK, and encrypting these keys. In + addition, the client MUST allow and encourage the user to store both + the new identity and the Rescue Code in an offline format. The + following process is RECOMMENDED: + 1. Begin harvesting entropy if the client does not do this + continuously. + 2. Prompt the user to name their new identity so that they can + recognize it later. + 3. Generate a random Rescue Code, and have the user store the Rescue + Code offline. Written or printed form is RECOMMENDED. Encourage + the user to securely store the Rescue Code in an offline format. + The client MAY require the user to retype the Rescue Code to + ensure that they have stored a copy. + 4. Prompt the user for a password to protect the new identity. + Clients SHOULD encourage the user to choose a strong password. -Comley & Killian Expires August 22, 2018 [Page 18] + 5. Generate a random IUK and store it in a newly constructed Type 2 + block (Section 4.3.2.2), encrypted with the newly generated + Rescue Code. + + 6. Derive the IMK and ILK and store them in a newly constructed Type + 1 block (Section 4.3.2.1), encrypted with the user's new + password. + + 7. Securely wipe any memory containing unencrypted keys or + passwords. + + 8. Save the newly created blocks to local storage with the user + chosen name. + + + + + +Comley & Killian Expires August 23, 2018 [Page 20] Internet-Draft SQRL February 2018 -4.4.1. Identity Creation - - TODO + 9. Provide options for, and encourage the user to backup the new + identity to an offline format. 4.4.2. Importing / Exporting an Identity @@ -1054,21 +1165,77 @@ Internet-Draft SQRL February 2018 4.4.4. Identity Recovery - TODO + If the user has forgotten their password, or lost their identity + file, identity recovery is required to reconstruct a usable identity. + Depending on the situation, the client may be recovering from an + existing identity file, or from an offline backup. In either case, + the procedure is the same: + +Comley & Killian Expires August 23, 2018 [Page 21] + +Internet-Draft SQRL February 2018 + + + 1. Because the user's options are lost in this process, the client + SHOULD give the user an opportunity to review the default options + and make changes. + + 2. Prompt the user to enter their Rescue Code and new password. + + 3. Validate the Rescue Code by decrypting the Type 2 block and + obtain the IUK. + + 4. Derive the IMK and ILK, and construct a new Type 1 block + protected by the user's newly chosen password. + + 5. Securely wipe any memory containing unencrypted keys or + passwords. + + 6. Save the recovered identity. + +4.4.5. Rekeying an Identity + + Rekeying an identity completely replaces the IUK with a new one. It + is only required when the user believes that their identity may have + been compromised. After rekeying, the client SHOULD encourage the + user to visit and authenticate with any important sites to ensure + that those sites update their identity association. Until this is + done, an attacker may still have full access to those sites. To + rekey an identity: + + 1. Prompt the user for their Rescue Code. + + 2. Using the Rescue Code, decrypt the Type 2 block to obtain the IUK + (now a PIUK). + 3. Follow the steps in Section 4.4.1 to create a new identity. + 4. Before saving or exporting the new identity, a Type 3 block + (Section 4.3.2.3) must be constructed: + A. If a Type 3 block already exists (rekeying has been performed + in the past), the existing block must be decrypted and + modified. The "Edition" field is incremented, and the new + PIUK is prepended to the existing PIUKs. If the list now + contains more than four PIUKs, the last (oldest) one is + removed. -Comley & Killian Expires August 22, 2018 [Page 19] + B. If a Type 3 block does not already exist, a new one is + created. Fill the "Edition" field with the number 1. The + encrypted section will contain only the new PIUK. + + + + +Comley & Killian Expires August 23, 2018 [Page 22] Internet-Draft SQRL February 2018 -4.4.5. Re-Keying an Identity - - TODO + C. Encrypt the Type 3 block using the new IMK and ensure that it + is saved / exported with the new identity. 5. Client-Server Protocol @@ -1110,22 +1277,19 @@ Internet-Draft SQRL February 2018 TODO +5.3.5. The client Value + TODO - -Comley & Killian Expires August 22, 2018 [Page 20] +Comley & Killian Expires August 23, 2018 [Page 23] Internet-Draft SQRL February 2018 -5.3.5. The client Value - - TODO - 5.3.6. Client Keys TODO @@ -1166,6 +1330,10 @@ Internet-Draft SQRL February 2018 TODO +6.2. Cross Device Authentication + + TODO + @@ -1173,15 +1341,11 @@ Internet-Draft SQRL February 2018 -Comley & Killian Expires August 22, 2018 [Page 21] +Comley & Killian Expires August 23, 2018 [Page 24] Internet-Draft SQRL February 2018 -6.2. Cross Device Authentication - - TODO - 6.3. Identity Association TODO @@ -1222,26 +1386,22 @@ Internet-Draft SQRL February 2018 5. Breaking of pseudonymous nature of SQRL authentication (association of SQRL identities on various sites) +8.1. Phishing + One well-known attack mode is where the user is invited to click on a + link appearing to go to a legitimate site, but is in reality directed + to an attacker's server. + One common method of this is a look-alike link. For example, a user + believing he is going to example.com is in reality going to - - -Comley & Killian Expires August 22, 2018 [Page 22] +Comley & Killian Expires August 23, 2018 [Page 25] Internet-Draft SQRL February 2018 -8.1. Phishing - - One well-known attack mode is where the user is invited to click on a - link appearing to go to a legitimate site, but is in reality directed - to an attacker's server. - - One common method of this is a look-alike link. For example, a user - believing he is going to example.com is in reality going to examp1e.com (the lowercase "l" is replaced with a numeral "1"). A historical example is "tvvitter.com" (the letter "v" twice instead of a "w"). @@ -1281,15 +1441,6 @@ Internet-Draft SQRL February 2018 warned of an IP mismatch, and CPS will redirect the browser to a safe page on the real site. No such protections exist for cross-device authentication (Section 6.2), but this is only used in the case of - - - - -Comley & Killian Expires August 22, 2018 [Page 23] - -Internet-Draft SQRL February 2018 - - untrusted devices where the user will probably be typing in the domain name manually. @@ -1300,6 +1451,13 @@ Internet-Draft SQRL February 2018 attacker. In such a case, SQRL would be fooled (as would anything else on the compromised device). + + +Comley & Killian Expires August 23, 2018 [Page 26] + +Internet-Draft SQRL February 2018 + + However, cross-device authentication would foil this, as the user would be using a smartphone or other trusted device that would be doing its own DNS lookup. Local authentication should take place @@ -1338,16 +1496,8 @@ Internet-Draft SQRL February 2018 the user type the Master Password on the keyboard. Keep in mind that these can be picked up using binoculars or seen on a CCTV camera. - - - -Comley & Killian Expires August 22, 2018 [Page 24] - -Internet-Draft SQRL February 2018 - - It is absolutely crucial that a new SQRL identity NOT be created, and - an existing one NOT be re-keyed, in such an area. Anyone who can + an existing one NOT be rekeyed, in such an area. Anyone who can resolve the screen and keyboard can get the Master Password AND the Rescue Code. @@ -1356,6 +1506,14 @@ Internet-Draft SQRL February 2018 In this context, the router in consideration is the one connecting the user's LAN segment to the rest of the Internet. Home routers have been shown to be lacking in security, and even a well-supported + + + +Comley & Killian Expires August 23, 2018 [Page 27] + +Internet-Draft SQRL February 2018 + + router must be updated when new firmware versions are released, something most users aren't aware of. @@ -1394,14 +1552,6 @@ Internet-Draft SQRL February 2018 All the same, once authenticated the user is subject to all of the harms that can occur regardless of the form of authentication. - - - -Comley & Killian Expires August 22, 2018 [Page 25] - -Internet-Draft SQRL February 2018 - - 8.5. CPU Flooding CPU flooding is where the attacker is able to cause one or more @@ -1412,6 +1562,14 @@ Internet-Draft SQRL February 2018 With SQRL, this can be a vulnerability when running EnScrypt (Section 2.4) in Timer Mode. After 5 seconds (by default), the timer runs out, and the resulting key is used to encrypt the identity and + + + +Comley & Killian Expires August 23, 2018 [Page 28] + +Internet-Draft SQRL February 2018 + + the number of iterations recorded. If another process utilizes significant CPU clocks during this process, the total number of iterations will be lower than it would have, meaning that the Master @@ -1433,14 +1591,14 @@ Internet-Draft SQRL February 2018 Moreover, it could keep track of everywhere the user logs in and send to the attacker all of the user's accounts on banking, e-commerce, - and other important websites. And although a user can re-key his + and other important websites. And although a user can rekey his identity, he would first have to understand that his identity has been compromised. The absolute worst case scenario would be when a user uses an evil - client to create or re-key his identity, which would give the - attacker access to even the Rescue Code. All other possible security - concerns pale to this. + client to create or rekey his identity, which would give the attacker + access to even the Rescue Code. All other possible security concerns + pale to this. SQRL mitigates this possibility by requiring (and advising) only that the user place his SQRL identity on trusted devices, using cross- @@ -1451,13 +1609,6 @@ Internet-Draft SQRL February 2018 stores for Android and iOS. A malicious SQRL app, sadly, is not out of the question. - - -Comley & Killian Expires August 22, 2018 [Page 26] - -Internet-Draft SQRL February 2018 - - This issue can be somewhat mitigated by requiring that SQRL apps be certified by trusted authorities. The reference implementation from GRC not only checks the certificate on every update, but checks the @@ -1468,6 +1619,13 @@ Internet-Draft SQRL February 2018 software hijack the sqrl:// protocol and eliminate the need for a localhost connection on port 25519. + + +Comley & Killian Expires August 23, 2018 [Page 29] + +Internet-Draft SQRL February 2018 + + 9. References 9.1. Normative References @@ -1505,15 +1663,6 @@ Internet-Draft SQRL February 2018 RFC 3986, DOI 10.17487/RFC3986, January 2005, . - - - - -Comley & Killian Expires August 22, 2018 [Page 27] - -Internet-Draft SQRL February 2018 - - [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, August 2016, . @@ -1523,6 +1672,16 @@ Internet-Draft SQRL February 2018 Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016, . + + + + + +Comley & Killian Expires August 23, 2018 [Page 30] + +Internet-Draft SQRL February 2018 + + [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, sqrl - Secure Quick Reliable Login (SQRL) is an authentication method and - identity management framework. It enables a user to create and manage - a single, pseudonymous lifetime identity. That identity will allow the user to - securely authenticate with any SQRL enabled server without relying on - a third party or disclosing personally identifiable information. - - SQRL's identity management framework gives the user complete control - over their online identity, including provisions for recovering from - the loss of their identity file or password and recovering from - potential security breaches. -
- Secure Quick Reliable Login (SQRL) is an authentication method and - identity management framework with the following features: - - Through a series of cryptographic signatures, the user can prove - their identity without disclosing any information that would allow - that identity to be compromised or their account hacked. - - The user only has to remember a single password, which is used to - locally decrypt their identity during SQRL authentication. Since - the user no longer has to remember a unique password for each site, - this one global password can be very strong. This strong password - combined with strong encryption makes it infeasible for even a - state level actor to compromise the user's identity. (SQRL apps can alternately use other methods of protection such as biometrics when available on the host device.) - - SQRL authentication is pseudonymous, in that it only provides a - secure, site-specific token to the server. This token cannot be - directly linked to a user's account at any other server, and - provides no personally identifiable information. - - The user's identity cannot be compromised by a security breach at - a third party authentication provider, protecting it from both - hackers and overreaching authorities. - - SQRL provides an identity management framework which allows the - user to maintain complete control of their identity. Even in the - event that their password is compromised, the user retains the - ability to retake control of their identity and lock the attacker - out. Automated rekeying means that the user can maintain a single - SQRL identity indefinately, even after a compromise - - Since SQRL identities are intended to last a lifetime, and there - is no third party that can help the user recover their identity if - they forget their password, SQRL includes an offline backup - mechanism. The user can print out or write down their encrypted - identity, along with a secure Rescue Code, that will allow the user - to recover from a forgotten password. - - With SQRL, the user can safely authenticate a session on public or - potentially compromised systems by scanning a QR code - on a trusted mobile device containing their SQRL identity, without the need to expose that identity to the public system. - -
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + keywords will be used for the search engine. --> + + Secure Quick Reliable Login (SQRL) is an application-level protocol for user authentication and identity management. It enables a user to create and manage a single pseudonymous lifetime identity. That identity will allow the user to securely authenticate with any SQRL enabled server without relying on a third party or disclosing personally identifiable information. + + It provides: + Unique pseudonymous identifiers for each site + Separation of identity management from account management + Strong anti-phishing protection + No shared secrets that can be exploited by bad actors + Out-of-band authentication for logging in on untrusted devices + + + +
+
Secure Quick Reliable Login (SQRL) is an authentication method and identity management framework which gives the user complete control over their online identity, including provisions for recovering from the loss of their identity file or password and recovering from potential security breaches.
+
+ + Through a series of cryptographic signatures, the user can prove + their identity without disclosing any information that would allow + that identity to be compromised or their account hacked. SQRL also provides strong anti-phishing features. + + SQRL separates and delineates the concepts of account and identity. The user is given full control over their identity and its full life cycle, while leaving servers with complete control over account issues. SQRL provides a full identity lifecycle management framework which allows the user to maintain complete control of their identity. Even in the event of a compromise, the user retains the ability to retake control of their identity and lock the attacker out. Automated rekeying means that the user can maintain a single SQRL identity indefinitely, even after a compromise. + + The user only has to remember a single password, which is used to + locally decrypt their identity during SQRL authentication. Since + the user no longer has to remember a unique password for each site, + this one global password can be very strong. This strong password + combined with strong encryption makes it infeasible for even a + state level actor to compromise the user's identity. (SQRL apps can alternately use other methods of protection such as biometrics when available on the host device.) + + SQRL authentication is pseudonymous, in that it only provides a + secure, site-specific token to the server. This token cannot be + directly linked to a user's account at any other server, and + provides no personally identifiable information. + + Passwords, time-based authenticators, and other authentication methods work through shared secrets. These secrets can conceivably be stolen by hackers or rogue employees and used to impersonate the user. SQRL does not operate through shared secrets, and even if the server's account database is stolen the attacker is not given any means to impersonate the user. + + The user's identity cannot be compromised by a security breach at + a third party authentication provider, protecting it from both + hackers and overreaching authorities. + + Unlike password managers, SQRL does not require any information about specific websites to be saved, preventing potential privacy issues stemming from information leaks as well as keeping its database size small. + + Since SQRL identities are intended to last a lifetime, and there + is no third party that can help the user recover their identity if + they forget their password, SQRL includes an offline backup + mechanism. The user can print out or write down their encrypted + identity, along with a secure Rescue Code, that will allow the user + to recover from a forgotten password. + + With SQRL, the user can safely authenticate a session on public or + potentially compromised systems by scanning a QR code + on a trusted mobile device containing their SQRL identity, without the need to expose that identity to the public system. + + +
+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in - RFC 2119.
TODO
TODO
The following standard algorithms are used in this document: + RFC 2119.
TODO
+
TODO
The following standard algorithms are used in this document: AES-GCM base64url: URL safe base64 encoding, as defined in Section 4 of , without padding. @@ -256,7 +260,7 @@ IUK = RandomBytes( 32 );]]> The IUK is a Class A 256 bit high entropy random number that represents a user's identity. All other identifying keys are derived from this one. After identity creation, this key is only - used in emergency situations, such as re-keying an identity in the + used in emergency situations, such as rekeying an identity in the event of a possible compromise.
@@ -310,7 +314,7 @@ URSK = curve25519_key_agreement( SUK, curve25519_private_key( IUK ));]]>
- This Class B ) key acts as a proxy for the IUK during normal SQRL + This Class B key acts as a proxy for the IUK during normal SQRL operation. It is used to generate the unique keys that each site associates with the user. The IMK is derived from the IUK using the EnHash () function. @@ -347,7 +351,7 @@ VUK = ed25519_public_key( curve25519_key_agreement( ILK, RLK ));]]> The number of characters from the user's password to use as the - ShortPass. Clients that implement ShortPass MUST honor the user's + ShortPass (). Clients that implement ShortPass MUST honor the user's choice here. Valid values are 0 to 255. A value of 0 disables the ShortPass feature. @@ -390,7 +394,7 @@ VUK = ed25519_public_key( curve25519_key_agreement( ILK, RLK ));]]>
+
The type 1 block contains the user's encrypted IMK and ILK, as well as user defined options. The user options are in plain text, but MUST be regarded as untrusted until authenticated through AES-GCM. Type 1 @@ -402,7 +406,7 @@ VUK = ed25519_public_key( curve25519_key_agreement( ILK, RLK ));]]>Populate the ciphertext result and verification tag from AES-GCM.Securely wipe the plaintext keys, encryption key, and password from memory if they are no longer needed. If the client is updating a type 1 block, and the user's password hasn't changed, clients SHOULD use the original salt and iteration count to re-encrypt the block. -
+
The type 2 block contains a single key, the IUK, along with it's encryption parameters. It is encrypted with AES-GCM using the RCDK. FieldDefaultBytesBlock Length732Block Type22EnScrypt Salt16EnScrypt n-factor91EnScrypt Iteration Count4Encrypted IUK32AES-GCM Verification Tag16 @@ -412,7 +416,7 @@ VUK = ed25519_public_key( curve25519_key_agreement( ILK, RLK ));]]>The RCDK is used in place of the PWDK. -
+
The type 3 block contains from one to four of the most recent PIUKs, IUKs which have been replaced by rekeying. It also includes the total number of times the identity has been rekeyed, the "Edition". If the identity has never been rekeyed, this block will be absent. Encrypted using the IMK as the AES-GCM encryption key, the @@ -433,7 +437,31 @@ VUK = ed25519_public_key( curve25519_key_agreement( ILK, RLK ));]]>EncodingHeader (ASCII)binarysqrldatabase64urlSQRLDATAbase56check
TODO
+ EncodingHeader (ASCII)binarysqrldatabase64urlSQRLDATAbase56check
+ Identity creation, recovery, and rekeying are particularly vulnerable times for the SQRL identity, during which + several Class A secrets may be exposed. Special care is required to protect this sensitive key during these operations. + Clients SHOULD inform the user of the security implications and encourage the user not to perform these operations + on a device that the user believes to be compromised. +
+ The SQRL identity is, in essence, just a long random number (the IUK). In order to protect the new identity, + both during creation and against future exploits, the client MUST use the highest quality entropy available to + it while creating a new identity. See for recommendations on harvesting entropy. + + Creating an identity involves generating a random IUK and Rescue Code, deriving the IMK and ILK, and encrypting these + keys. In addition, the client MUST allow and encourage the user to store both the new identity and the Rescue Code in + an offline format. The following process is RECOMMENDED: + Begin harvesting entropy if the client does not do this continuously.Prompt the user to name their new identity so that they can recognize it later. + Generate a random Rescue Code, and have the user store the Rescue Code offline. Written or printed form is RECOMMENDED. + Encourage the user to securely store the Rescue Code in an offline format. The client MAY require the user to retype + the Rescue Code to ensure that they have stored a copy. + Prompt the user for a password to protect the new identity. Clients SHOULD encourage the user to choose a strong password. + Generate a random IUK and store it in a newly constructed Type 2 block (), encrypted with + the newly generated Rescue Code. + + Derive the IMK and ILK and store them in a newly constructed Type 1 block (), encrypted with + the user's new password. + Securely wipe any memory containing unencrypted keys or passwords.Save the newly created blocks to local storage with the user chosen name.Provide options for, and encourage the user to backup the new identity to an offline format. +
For compatibility, clients MUST support importing and exporting identities in at least one of these standard formats. It is RECOMMENDED that clients support all of them. Clients MAY offer additional formats as well. @@ -448,7 +476,26 @@ VUK = ed25519_public_key( curve25519_key_agreement( ILK, RLK ));]]>Using the user's current password, decrypt the Type 1 Block. Other block types are not affected by this operation.Using the user's new password, re-encrypt the Type 1 Block. During encryption, EnScrypt MUST be called in Timer Mode, using the user's chosen "EnScrypt Seconds" option ().Save the changes to non-volatile storage. -
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
TODO
As SQRL aims to protect a single identity that is ultimately used to authenticate a user everywhere, the security of this identity is paramount. Further, users must face many of the same security issues as with traditional methods of authentication.It is important to consider the following attack goals:1. Session hijacking2. Site credential theft3. Association of SQRL identity to site account4. Master key theft5. Breaking of pseudonymous nature of SQRL authentication (association of SQRL identities on various sites)
One well-known attack mode is where the user is invited to click on a link appearing to go to a legitimate site, but is in reality directed to an attacker's server.One common method of this is a look-alike link. For example, a user believing he is going to example.com is in reality going to examp1e.com (the lowercase "l" is replaced with a numeral "1"). A historical example is "tvvitter.com" (the letter "v" twice instead of a "w").Another method is to use a malformed URL to misdirect a user. For example, this link:https://www.amazon.com@%67%72%63.%63%6f%6d/at first glance appears to be a link to Amazon, but in reality takes the user to grc.com. In reality, the attacker would substitute the name of his phishing site and most users might be fooled entirely.The phishing site is generally set up to look and work exactly the way the real site works, at least up until the point where the attacker has stolen the intended data.Phishing attacks where the goal is to obtain authentication credentials are entirely foiled by SQRL. Since SQRL uses the domain name as the basis for authentication, it will create completely different identity keys. The SSPK the attacker gets will be a public key specifically for his attack site, useless to him for obtaining access to the real site.However, the attacker may have other goals. If the attacker can successfully mimic an e-commerce site such as Amazon or a financial site such as PayPal, the user could be tricked into entering account data such as a credit card number. The real domain name is displayed to the user before authentication, giving him the opportunity to realize he is being fooled.Many phishing attacks are pass-through attacks, where the phishing site acts as an active Man-In-The-Middle. It obtains the genuine page from the real site and passes it along to the user, receiving the user's responses and passing them back to the site. In the case of same-device authentication, the client will be warned of an IP mismatch, and CPS will redirect the browser to a safe page on the real site. No such protections exist for cross-device authentication, but this is only used in the case of untrusted devices where the user will probably be typing in the domain name manually.The attacker can get around SQRL's protections with DNS spoofing, where the device's DNS addresses are altered, entries are added to the hosts file, or otherwise made to redirect a host name to an incorrect address, generally the phishing site controlled by the attacker. In such a case, SQRL would be fooled (as would anything else on the compromised device).However, cross-device authentication would foil this, as the user would be using a smartphone or other trusted device that would be doing its own DNS lookup. Local authentication should take place only on trusted devices. DNS could only be spoofed on these devices using malware, but malware can compromise any security feature.A client developer could also foil such an attack by providing its own internal DNS resolver, bypassing the attacker's spoofing. However, such a feature may not be desired on enterprise networks running their own internal DNS systems, so it should be an option the user can turn off.
Shoulder-surfing is when an attacker reads or scans the display, keyboard, and other components of the target's device directly, allowing the attacker to see sensitive information, including information entered into forms.In the context of SQRL, the danger is of an attacker scanning the QR code of a SQRL-enabled website. With good timing, the attacker could fool the user into thinking he's logged in as himself when in reality he's authenticated to an account controlled by the attacker. The attacker could then get anything the user enters into that web site, including credit card numbers and other sensitive information.However, in such a case the user's authentication would fail as the nut is no longer valid. The SQRL client MUST deliver an error message to the user saying that the authentication has failed, and SHOULD advise the user of the dangers of continuing to use the web site, especially if the authentication has the appearance of having worked.Care should be taken when authenticating to a website in a public area, or any other place where others could see the QR code, or watch the user type the Master Password on the keyboard. Keep in mind that these can be picked up using binoculars or seen on a CCTV camera.It is absolutely crucial that a new SQRL identity NOT be created, and an existing one NOT be re-keyed, in such an area. Anyone who can resolve the screen and keyboard can get the Master Password AND the Rescue Code.
In this context, the router in consideration is the one connecting the user's LAN segment to the rest of the Internet. Home routers have been shown to be lacking in security, and even a well-supported router must be updated when new firmware versions are released, something most users aren't aware of.It is also increasingly the case that users connect to Wi-Fi hotspots when travelling, relying on routers whose security they could not evaluate even if they knew to. Moreover, an attacker on the LAN segment could engage in ARP spoofing to make the attacker's own device the default gateway for the segment, forwarding the packets on to the true router but establishing himself as a Man-In-The-Middle.Once an attacker gains control of the default gateway, he could engage in phishing and DNS spoofing attacks as described above. More significantly, he could insert himself into the TLS handshake and commit any number of attacks designed to compromise the security of TLS.SQRL provides no means of defending the user against such an attack, however, at most the attacker will gain access to the specific login sessions the user makes while at that location.
A server compromise can result in sensitive user data being obtained by the attacker without the user even logging in.In the case of SQRL there is less critical data for the attacker to get. There are no passwords or other secrets sent to the server that have to be hashed and protected. The attacker can only get the SSPK, SUK, and VUK, which are useless to him.If the attacker has gained access to more than one site, the SSPK would be different, meaning that the attacker could not correlate user data between websites (unless, of course, there was other identifying information in common such as an email address).All the same, once authenticated the user is subject to all of the harms that can occur regardless of the form of authentication.
CPU flooding is where the attacker is able to cause one or more processes to run that take up significant CPU time. It also can happen without a malicious attacker, when a normal process starts running in the background.With SQRL, this can be a vulnerability when running EnScrypt in Timer Mode. After 5 seconds (by default), the timer runs out, and the resulting key is used to encrypt the identity and the number of iterations recorded. If another process utilizes significant CPU clocks during this process, the total number of iterations will be lower than it would have, meaning that the Master Password has weaker protection against cracking.
An evil client is a maliciously-developed SQRL client. It may take the form of its own client, or it may mimic an existing and trusted SQRL client. It may enter the user's computer in the form of malware, hijacking the sqrl:// protocol as a new handler and attaching itself to the localhost:25519 port. If artfully done, the user would have no clue that a substitution has been made.The consequences cannot be overstated. The evil client would be able to gain the unencrypted IMK on its very first use, allowing the attacker to be able to hijack ANY account on ANY website where the user has authenticated using SQRL.Moreover, it could keep track of everywhere the user logs in and send to the attacker all of the user's accounts on banking, e-commerce, and other important websites. And although a user can re-key his identity, he would first have to understand that his identity has been compromised.The absolute worst case scenario would be when a user uses an evil client to create or re-key his identity, which would give the attacker access to even the Rescue Code. All other possible security concerns pale to this.SQRL mitigates this possibility by requiring (and advising) only that the user place his SQRL identity on trusted devices, using cross-device authentication on all other devices. However, this only limits the attack surface. In the past, fake versions of Firefox and other web browsers, fake Bitcoin wallets, and numerous others have been downloaded by users and even placed inside the trusted app stores for Android and iOS. A malicious SQRL app, sadly, is not out of the question.This issue can be somewhat mitigated by requiring that SQRL apps be certified by trusted authorities. The reference implementation from GRC not only checks the certificate on every update, but checks the fingerprint on the DigiCert root certificate as well to help ensure that there was no improper substitution. However, the ultimate protection can only come from complete SQRL integration into web browsers and operating systems, which will refuse to let any other software hijack the sqrl:// protocol and eliminate the need for a localhost connection on port 25519.