Secure Quick Reliable Login | ||
A highly secure, comprehensive, easy-to-use replacement for usernames, passwords, reminders, one-time-code authenticators . . . and everything else. |
The diagram above depicts the flow and interconnectivity of cryptographic keying information within the SQRL client. For the sake of clarity, implementation details such as the generation of per-encryption salt and the creation and storage of decryption verifiers, implied by the technology, are not shown.
|
Taking SQRL's need for Entropy seriously:
A SQRL identity flows from a single high-quality random 256-bit value. As shown above, that value directly becomes the Identity Unlock Key and, through a PBKDF2 one-way key derivation function, the Identity Master Key. Since this forms the user's single system-wide identity, the SQRL system acknowledges that the entropy of this value is crucial. Thus client implementors MUST pay particular heed to this value's high entropy requirement by using as many sources of input entropy as possible. Depending upon the hosting platform, all sources of entropy should be used, such as seeding from a mobile device's photo collection (but never in isolation since it is obviously repeatable), the platform's own crypto-random source, real time camera and audio streaming, GPS, inertia sensor, WiFi signal strength, network history, storage contents, etc. Modern processors also contain event counters which monitor deterministic but unpredictable and unknowable internal processor state. Since it only needs to be done once per identity, the high-entropy random value can be generated deliberately and carefully.
The important takeaway is: Implementors should budget to invest heavily in this process, feel no need to hide it ‘magically’, and feel free to engage their users.
Never store decrypted secrets:
SQRL clients must carefully adhere to several important security safeguards: The two decrypted key values highlighted in red, above, must NEVER be written, even briefly, into non-volatile memory. They must only exist in RAM. Only their encrypted counterparts, shown with green highlight, may be (and in some cases must be) stored permanently. As shown by the flowchart, the application of user-supplied secrets (in blue) enables the encryption/decryption paths between the stored encrypted keys and the never-stored decrypted keys.
Protection from identity loss:
As the flowchart shows, the Identity Master Key, rather then being independently arrived at pseudo-randomly, is obtained directly through the one-way, irreversible PBKDF2 function from the Identity Unlock Key. This allows the encrypted Identity Unlock Key ‑ to serve as a complete identity backup, empowered not only with the identity unlock role (enabling replacement, re-enabling or deletion of existing online identities) but also able to protect its user from any loss of their Identity Master Key, as well as from forgetting its matching password.
The system chooses the identity unlock “Rescue Code”:
To safeguard the encryption of the Identity Unlock Key, the user does not choose its encryption password. (People are notoriously poor sources of entropy.) Instead, the system provides a randomly chosen 24-decimal-digit “Identity Unlock Rescue Code.”
Simple decimal digits were chosen because they are simple, are more language-neutral than alphabetic symbols, and are typically easier to enter than special characters. Although larger character sets using case-sensitive alphabetic and special symbols encode a larger number of bits per symbol, human factors studies show that, to obtain a desired total bit length representation, ease of use increases as the size of the character set is reduced and the number of characters is increasing. In other words, people would rather enter a greater number of simple characters than fewer complex characters.
24 decimal digits allows the system to select one Rescue Code of 1024, which is equivalent to 79.73 (we'll call it 80) bits of entropy. Since each 80-bit value is passed through a slow, highly acceleration resistant, EnScrypt operation to convert it into a 256-bit cipher key. Any attacker would be forced to slowly brute force guess the full-entropy randomly-chosen 24-digit Rescue Code. Note that verifying any guess requires additional work of decrypting the encrypted key under the guess to obtain a candidate Identity Unlock Key then passing that through the elliptic curve “Make Public Key” function to obtain a candidate Identity Lock Key for comparison with the client's actual stored Identity Lock Key. This is more than sufficient for protecting the user's encrypted identity unlock key.
A password the user DOES memorize and control:
The Identity Master Key is always stored in encrypted form under the user's chosen (and readily changeable) authentication password. This is the password they use to prove their identity to the SQRL client in their smartphone, laptop or desktop. It may be readily exported from the client for cloning to another device, or for backup storage.
Password “hints” to reduce user frustration:
Someday we'll have a better way to authenticate users to their appliances. Perhaps bluetooth tags, truly secure and private biometrics, or whatever. But today, we have the ubiquitous memorized password. The needs of security push the password's length up, but the need to user convenience pushes the length down. SQRL resolves this by adopting a password “hint” system:
Once the user's full password has been entered, the decrypted identity key will be obtained. As the password was being entered, the first few characters, typically four, are captured separately. That “hint string” is passed through a (much quicker) instance of our EnScrypt PBKDF function to produce a “hint key”. The full password is used to decrypt the statically stored Identity Master Key (IMK). It is then immediately re-encrypted under the hint key. This “hint-encrypted” version of the IMK is stored in RAM and is never written to non-volatile memory.
The decrypted IMK is then used once for the immediate operation being performed, then it is overwritten and discarded. Any subsequent operations can be authenticated by prompting for the user's password hint, requiring just the first few characters of their full password. The short hint decrypts the RAM-resident hint-encrypted IMK for easier use. Note that ANY mistake in the entry of the hint will immediately wipe the hint-encrypted IMK from RAM memory and prompt the user for their full password. No guessing is allowed here. Also, any action which should eventually re-prompt for the full password, such as the system sleeping, a screen blanker activating, etc. would also immediately overwrite the RAM-resident hint-encrypted IMK.
What to store and what to never store:
The three keys shown in green above, along with associated cryptographic details, are stored — always and only — in encrypted form in the client's non-volatile memory for use as needed. Since the decrypted keys shown in red are never stored in non-volatile memory, they may only be created by decrypting the stored encrypted keys using the proper access code or user password.
No matter how much security the SQRL system could provide, it won't actually be provided if it's not widely used. And it won't be widely used if its use is overly complex and confusing. We must remember that SQRL's “competition” is the woefully insecure, but oh-so-trivial to use, status quo: An eMail address and a user-chosen (well worn) password.
Fancy as all this crypto magic may be, it needs to make sense to its users. Remember that SQRL's typical user will have NO understanding whatsoever of the meaning, reasoning and subtlety of any of this. By storing the system's two main keys — the Identity Unlock Key (IUK) and the Identity Master Key (IMK) — together in a single package, protecting the critical IUK with an extremely strong high-entropy access code, and allowing it to be optionally deleted, we give the user just one understandable SQRL identity to manage, backup, and copy. The result is a dramatically simplified user-interface.
The SQRL Client User-Interface page will spend a great deal more time exploring the proper and suggested care and handling of SQRL's users.
This schematic details the operation of SQRL's “EnHash” (iterated hash) function shown in the Key Flow diagram above:
The SHA-256 hash is already a cryptographically strong one-way function. But SQRL's application needs to derive one 256-bit key from another (meaning no more input than output) while depending crucially upon the integrity of the function's one-way nature. Meanwhile, the fact that SHA-256 was chosen for use with popular crypto-currencies has meant that incredible SHA-256 hashing rates and technologies are being developed and achieved with dedicated hardware. Since SQRL can only offer 256-bits of input from the user's randomly chosen Identity Unlock Key (IUK), and since this function must not be allowed to be weakened, we felt that an abundance of caution was warranted. So sixteen (16) chained iterations of SHA-256 are used with each iteration's output XORed to produce the final output, which becomes the user's Identity Master Key (IMK).
If some weakness should ever be found in the mapping between a low input bit count an the hash's output, this simple construction should thwart any hash-reversing exploitation and prevent the weakening of the secrecy of SQRL's Identity Unlock Key.
Gibson Research Corporation is owned and operated by Steve Gibson. The contents of this page are Copyright (c) 2024 Gibson Research Corporation. SpinRite, ShieldsUP, NanoProbe, and any other indicated trademarks are registered trademarks of Gibson Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy. |
Last Edit: Aug 02, 2015 at 13:17 (3,381.68 days ago) | Viewed 2 times per day |