From 0acf3de674018b34ec692be84072291825e53caa Mon Sep 17 00:00:00 2001 From: Adam Comley Date: Sun, 18 Feb 2018 13:19:56 -0600 Subject: [PATCH] Identity Operations --- draft-sqrl.txt | 520 ++++++++++++++++++++++----------------------- src/draft-sqrl.xml | 32 +-- 2 files changed, 278 insertions(+), 274 deletions(-) diff --git a/draft-sqrl.txt b/draft-sqrl.txt index 1194d18..bbdaa75 100644 --- a/draft-sqrl.txt +++ b/draft-sqrl.txt @@ -78,12 +78,12 @@ Table of Contents 2.2.2. Validation . . . . . . . . . . . . . . . . . . . . . 7 2.2.3. Decoding . . . . . . . . . . . . . . . . . . . . . . 8 2.3. EnHash . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 2.4. EnScrypt . . . . . . . . . . . . . . . . . . . . . . . . 8 - 3. Cryptographic Keys, Secrets, and Passwords . . . . . . . . . 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.3. Rescue Code (RC) . . . . . . . . . . . . . . . . . . 10 + 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 @@ -91,21 +91,21 @@ Table of Contents 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.3. Class C (Public) Keys . . . . . . . . . . . . . . . . . . 12 - 3.3.1. Site Specific Public Key (SSPK) . . . . . . . . . . . 12 + 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. Identity Creation . . . . . . . . . . . . . . . . . . . . 13 - 4.3. User Options . . . . . . . . . . . . . . . . . . . . . . 13 - 4.4. Identity Storage . . . . . . . . . . . . . . . . . . . . 14 - 4.4.1. Storage Blocks . . . . . . . . . . . . . . . . . . . 15 - 4.4.2. Predefined Block Types . . . . . . . . . . . . . . . 15 - 4.5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 18 - 4.6. Importing / Exporting an Identity . . . . . . . . . . . . 18 - 4.7. Changing the User's Password . . . . . . . . . . . . . . 19 - 4.8. Identity Recovery . . . . . . . . . . . . . . . . . . . . 19 + 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 @@ -114,10 +114,11 @@ Comley & Killian Expires August 22, 2018 [Page 2] Internet-Draft SQRL February 2018 - 4.9. Re-Keying an Identity . . . . . . . . . . . . . . . . . . 19 - 5. Client-Server Protocol . . . . . . . . . . . . . . . . . . . 19 - 5.1. Initiation of SQRL Authentication . . . . . . . . . . . . 19 - 5.1.1. The SQRL Scheme . . . . . . . . . . . . . . . . . . . 19 + 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 @@ -125,10 +126,10 @@ Internet-Draft SQRL February 2018 5.3.2. Commands . . . . . . . . . . . . . . . . . . . . . . 20 5.3.3. Options . . . . . . . . . . . . . . . . . . . . . . . 20 5.3.4. The server Value . . . . . . . . . . . . . . . . . . 20 - 5.3.5. The client Value . . . . . . . . . . . . . . . . . . 20 - 5.3.6. Client Keys . . . . . . . . . . . . . . . . . . . . . 20 - 5.3.7. Client Signatures . . . . . . . . . . . . . . . . . . 20 - 5.3.8. Composing the Request . . . . . . . . . . . . . . . . 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 @@ -136,32 +137,31 @@ Internet-Draft SQRL February 2018 5.4.4. Composing the Reply . . . . . . . . . . . . . . . . . 21 6. Client-Server Interactions . . . . . . . . . . . . . . . . . 21 6.1. Same Device Authentication . . . . . . . . . . . . . . . 21 - 6.2. Cross Device Authentication . . . . . . . . . . . . . . . 21 - 6.3. Identity Association . . . . . . . . . . . . . . . . . . 21 - 6.4. Updating Identity Association . . . . . . . . . . . . . . 21 - 6.5. Disabling Site Login . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 22 + 8.1. Phishing . . . . . . . . . . . . . . . . . . . . . . . . 23 8.2. Shoulder-Surfing . . . . . . . . . . . . . . . . . . . . 24 - 8.3. Evil Router . . . . . . . . . . . . . . . . . . . . . . . 24 + 8.3. Evil Router . . . . . . . . . . . . . . . . . . . . . . . 25 8.4. Server Compromise . . . . . . . . . . . . . . . . . . . . 25 - 8.5. CPU Flooding . . . . . . . . . . . . . . . . . . . . . . 25 - 8.6. Evil Client . . . . . . . . . . . . . . . . . . . . . . . 25 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 26 - 9.2. Informative References . . . . . . . . . . . . . . . . . 27 + 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 . . . . . . . . . . . . . . . . . . . 28 - A.3.2. Identity Backup . . . . . . . . . . . . . . . . . . . 28 + A.3.1. Master Password . . . . . . . . . . . . . . . . . . . 29 + A.3.2. Identity Backup . . . . . . . . . . . . . . . . . . . 29 A.3.3. Disaster Recovery . . . . . . . . . . . . . . . . . . 29 - Appendix B. Harvesting Entropy . . . . . . . . . . . . . . . . . 29 - B.1. Entropy Sources . . . . . . . . . . . . . . . . . . . . . 30 - B.1.1. Operating System . . . . . . . . . . . . . . . . . . 30 + Appendix B. Harvesting Entropy . . . . . . . . . . . . . . . . . 30 + B.1. Entropy Sources . . . . . . . . . . . . . . . . . . . . . 31 @@ -170,6 +170,7 @@ Comley & Killian Expires August 22, 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 @@ -217,7 +218,6 @@ Internet-Draft SQRL February 2018 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 @@ -226,6 +226,7 @@ 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. @@ -272,8 +273,7 @@ Internet-Draft SQRL February 2018 o SHA-256 [FIPS.180-4.2015] - o urlencode: Percent-Encoding as defined in Section 2.1 of - [RFC3986]. + @@ -282,6 +282,9 @@ 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]. + 2.2. base56check base56check encoding allows the backup of SQRL identities to a @@ -326,10 +329,7 @@ Internet-Draft SQRL February 2018 Now, with our converted BASE string, we can calculate the check digits and produce the final output. - 6. Split BASE into 19 character CHUNKS (the final chunk may be - smaller). - 7. For each CHUNK: @@ -338,6 +338,11 @@ 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). + + 7. For each CHUNK: + A. Append a single byte zero-based CHUNK-NUMBER to the CHUNK. B. Perform a SHA-256 hash on the CHUNK, yielding HASH. @@ -381,11 +386,6 @@ Internet-Draft SQRL February 2018 E. Compare CHECK with the character from ALPHABET at position REMAINDER. - F. If comparison passes (is equal), continue. Otherwise, there - is an error in this CHUNK. - - - @@ -394,6 +394,9 @@ 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. + 2.2.3. Decoding Decoding base56check is similarly straight-forward: @@ -436,12 +439,9 @@ 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: + + @@ -450,6 +450,13 @@ 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: + +-------+------------+-----+---+ | dkLen | N | r | p | +-------+------------+-----+---+ @@ -490,13 +497,6 @@ 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. - @@ -506,6 +506,13 @@ 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 + + SQRL uses a wide variety of secrets in various operations. + 3.1. Class A Secrets Class A secrets are absolutely critical to protecting a user's @@ -548,13 +555,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. -3.1.3. Rescue Code (RC) - - The Rescue Code is a Class A, computer generated, high entropy - passcode consisting of 24 numeric digits. The client SHOULD - encourage the user to store the Rescue Code in an offline format - (printed or written). - Comley & Killian Expires August 22, 2018 [Page 10] @@ -562,6 +562,13 @@ 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 + passcode consisting of 24 numeric digits. The client SHOULD + encourage the user to store the Rescue Code in an offline format + (printed or written). + 3.1.4. Password Derived Keys Several keys are generated from user input. Both the user supplied @@ -603,13 +610,6 @@ 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. - - @@ -618,6 +618,12 @@ 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. + o The secret SHOULD NOT be transmitted over the network in any form, and MUST NOT be transmitted unencrypted. @@ -656,16 +662,10 @@ Internet-Draft SQRL February 2018 The RLK is generated randomly when the client associates with a new server. -3.3. Class C (Public) Keys - Class C keys are not required to be kept secret. -3.3.1. Site Specific Public Key (SSPK) - SSPK = ed25519_public_key( SSSK ); - The Site Specific Public Key (SSPK) is the public counterpart to the - SSSK. It serves as the user's pseudonymous identity on the site. @@ -674,6 +674,17 @@ 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. + +3.3.1. Site Specific Public Key (SSPK) + + SSPK = ed25519_public_key( SSSK ); + + The Site Specific Public Key (SSPK) is the public counterpart to the + SSSK. It serves as the user's pseudonymous identity on the site. + 3.3.2. Server Unlock Key (SUK) SUK = curve25519_public_key( RLK ); @@ -694,11 +705,7 @@ Internet-Draft SQRL February 2018 TODO -4.2. Identity Creation - - TODO - -4.3. User Options +4.2. User Options Several user options are available which will affect the operation of compatible SQRL clients: @@ -715,13 +722,6 @@ Internet-Draft SQRL February 2018 second. Idle Timeout: - 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 - idle time. Valid values are 1-65535. - - Option Flags: - The following binary flags turn on or off various user options: @@ -730,6 +730,14 @@ 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 + idle time. Valid values are 1-65535. + + Option Flags: + The following binary flags turn on or off various user options: + +--------+----------------------------------------------------------+ | Flag | Description | +--------+----------------------------------------------------------+ @@ -763,7 +771,7 @@ Internet-Draft SQRL February 2018 User Option Flags -4.4. Identity Storage +4.3. Identity Storage Because SQRL identities are intended to last the user's lifetime, the user needs to be able to move his identity between clients. Every @@ -771,6 +779,13 @@ 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 @@ -779,13 +794,6 @@ Internet-Draft SQRL February 2018 Values stored in standard SQRL storage format MUST follow these rules: - - -Comley & Killian Expires August 22, 2018 [Page 14] - -Internet-Draft SQRL February 2018 - - o All numeric values are unsigned. o Multibyte numeric values are stored in little endian byte order, @@ -793,7 +801,7 @@ Internet-Draft SQRL February 2018 o String values are stored in natural order, first byte first. -4.4.1. Storage Blocks +4.3.1. Storage Blocks A stored SQRL identity is composed of any number of blocks. Each block begins with a four byte header identifying the total length of @@ -815,9 +823,9 @@ Internet-Draft SQRL February 2018 Any client reading an identity that encouters a block type unknown to that client MUST simply ignore that block. -4.4.2. Predefined Block Types +4.3.2. Predefined Block Types -4.4.2.1. Block Type 1: Working Identity +4.3.2.1. Block Type 1: Working Identity 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 @@ -829,14 +837,6 @@ Internet-Draft SQRL February 2018 - - - - - - - - Comley & Killian Expires August 22, 2018 [Page 15] Internet-Draft SQRL February 2018 @@ -902,7 +902,7 @@ Internet-Draft SQRL February 2018 hasn't changed, clients SHOULD use the original salt and iteration count to re-encrypt the block. -4.4.2.2. Block Type 2: Rescue Identity +4.3.2.2. Block Type 2: Rescue Identity 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. @@ -932,7 +932,7 @@ Internet-Draft SQRL February 2018 o The RCDK is used in place of the PWDK. -4.4.2.3. Block Type 3: Previous Identities +4.3.2.3. Block Type 3: Previous Identities 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 @@ -973,7 +973,7 @@ Internet-Draft SQRL February 2018 content, the same encryption key will never be used to encrypt a different set of data and AAD, so a random IV is not necessary. -4.5. Encoding +4.3.3. Encoding Identities may be stored to file or optical (QR) code in binary format, or in base64url or base56check (Section 2.2) encoded text. @@ -997,10 +997,10 @@ Internet-Draft SQRL February 2018 Table 5: Storage Encodings and Headers -4.6. Importing / Exporting an Identity +4.4. Identity Operations + + - For compatibility, clients MUST support importing and exporting - identities in at least one of these standard formats. It is @@ -1010,11 +1010,19 @@ Comley & Killian Expires August 22, 2018 [Page 18] Internet-Draft SQRL February 2018 +4.4.1. Identity Creation + + TODO + +4.4.2. Importing / Exporting an Identity + + 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. Binary File - An identity in the standard format (Section 4.4), saved as a + An identity in the standard format (Section 4.3), saved as a binary file with the "sqrldata" header. The RECOMMENDED file extension is ".sqrl". @@ -1026,45 +1034,53 @@ Internet-Draft SQRL February 2018 * TODO: Recommend Mode, Encoding, Error Correction, etc. Text - An identity in the standard format (Section 4.4), encoded with + An identity in the standard format (Section 4.3), encoded with base56check (Section 2.2), intended to be printed to paper for offline storage and manually entered by the user during import. -4.7. Changing the User's Password +4.4.3. Changing the User's Password - TODO + Clients SHOULD allow the user to change their password at any time. + The process is simple: -4.8. Identity Recovery + 1. Using the user's current password, decrypt the Type 1 Block. + Other block types are not affected by this operation. - TODO + 2. 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 (Section 4.2). + + 3. Save the changes to non-volatile storage. -4.9. Re-Keying an Identity +4.4.4. Identity Recovery TODO -5. Client-Server Protocol - TODO -5.1. Initiation of SQRL Authentication - TODO -5.1.1. The SQRL Scheme - TODO +Comley & Killian Expires August 22, 2018 [Page 19] + +Internet-Draft SQRL February 2018 +4.4.5. Re-Keying an Identity + TODO +5. Client-Server Protocol + TODO +5.1. Initiation of SQRL Authentication + TODO -Comley & Killian Expires August 22, 2018 [Page 19] - -Internet-Draft SQRL February 2018 +5.1.1. The SQRL Scheme + TODO 5.1.2. QR Codes (Out of Band) @@ -1094,33 +1110,33 @@ Internet-Draft SQRL February 2018 TODO -5.3.5. The client Value - TODO -5.3.6. Client Keys - TODO -5.3.7. Client Signatures - TODO -5.3.8. Composing the Request - TODO +Comley & Killian Expires August 22, 2018 [Page 20] + +Internet-Draft SQRL February 2018 +5.3.5. The client Value + TODO +5.3.6. Client Keys + TODO +5.3.7. Client Signatures + TODO -Comley & Killian Expires August 22, 2018 [Page 20] - -Internet-Draft SQRL February 2018 +5.3.8. Composing the Request + TODO 5.4. Server to Client Replies @@ -1150,33 +1166,33 @@ Internet-Draft SQRL February 2018 TODO -6.2. Cross Device Authentication - TODO -6.3. Identity Association - TODO -6.4. Updating Identity Association - TODO -6.5. Disabling Site Login - TODO +Comley & Killian Expires August 22, 2018 [Page 21] + +Internet-Draft SQRL February 2018 +6.2. Cross Device Authentication + TODO +6.3. Identity Association + TODO +6.4. Updating Identity Association + TODO -Comley & Killian Expires August 22, 2018 [Page 21] - -Internet-Draft SQRL February 2018 +6.5. Disabling Site Login + TODO 6.6. Re-Enabling Site Login @@ -1206,6 +1222,18 @@ Internet-Draft SQRL February 2018 5. Breaking of pseudonymous nature of SQRL authentication (association of SQRL identities on various sites) + + + + + + + +Comley & Killian Expires August 22, 2018 [Page 22] + +Internet-Draft SQRL February 2018 + + 8.1. Phishing One well-known attack mode is where the user is invited to click on a @@ -1227,13 +1255,6 @@ Internet-Draft SQRL February 2018 the user to grc.com. In reality, the attacker would substitute the name of his phishing site and most users might be fooled entirely. - - -Comley & Killian Expires August 22, 2018 [Page 22] - -Internet-Draft SQRL February 2018 - - 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. @@ -1260,6 +1281,15 @@ 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. @@ -1282,14 +1312,6 @@ Internet-Draft SQRL February 2018 running their own internal DNS systems, so it should be an option the user can turn off. - - - -Comley & Killian Expires August 22, 2018 [Page 23] - -Internet-Draft SQRL February 2018 - - 8.2. Shoulder-Surfing Shoulder-surfing is when an attacker reads or scans the display, @@ -1316,6 +1338,14 @@ 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 resolve the screen and keyboard can get the Master Password AND the @@ -1338,14 +1368,6 @@ Internet-Draft SQRL February 2018 Once an attacker gains control of the default gateway, he could engage in phishing and DNS spoofing attacks as described above. More - - - -Comley & Killian Expires August 22, 2018 [Page 24] - -Internet-Draft SQRL February 2018 - - significantly, he could insert himself into the TLS handshake and commit any number of attacks designed to compromise the security of TLS. @@ -1372,6 +1394,14 @@ 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 @@ -1393,15 +1423,6 @@ Internet-Draft SQRL February 2018 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 - - - - -Comley & Killian Expires August 22, 2018 [Page 25] - -Internet-Draft SQRL February 2018 - - attaching itself to the localhost:25519 port. If artfully done, the user would have no clue that a substitution has been made. @@ -1430,6 +1451,13 @@ 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 @@ -1448,16 +1476,6 @@ Internet-Draft SQRL February 2018 National Institute of Standards and Technology, "Secure Hash Standard", August 2015. - - - - - -Comley & Killian Expires August 22, 2018 [Page 26] - -Internet-Draft SQRL February 2018 - - [NIST.800-38D] Dworkin, M., "NIST Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: @@ -1487,6 +1505,15 @@ 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, . @@ -1507,13 +1534,6 @@ Internet-Draft SQRL February 2018 . - - -Comley & Killian Expires August 22, 2018 [Page 27] - -Internet-Draft SQRL February 2018 - - [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007,
TODO -
TODO
+
Several user options are available which will affect the operation of compatible SQRL clients: @@ -421,7 +421,7 @@ VUK = ed25519_public_key( curve25519_key_agreement( ILK, RLK ));]]>
+
Identities may be stored to file or optical (QR) code in binary format, or in base64url or base56check () encoded text. Compatible clients MUST support at least one of @@ -433,18 +433,22 @@ VUK = ed25519_public_key( curve25519_key_agreement( ILK, RLK ));]]>EncodingHeader (ASCII)binarysqrldatabase64urlSQRLDATAbase56check
- 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. - - An identity in the standard format, saved as a binary file with the "sqrldata" - header. The RECOMMENDED file extension is ".sqrl". - TODO: Reference QR Code specification?TODO: Recommend Mode, Encoding, Error Correction, etc. - An identity in the standard format, encoded with - base56check, intended to be printed to paper for offline - storage and manually entered by the user during import. - -
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
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.