The complete SQRL authenticator architecture.
Let's begin by examining SQRL's cryptographic design at the interconnected functional block level. Later, we'll examine the critical and non-obvious functions—“Crypto Signature” & “Make Public Key.”
If you look again at the simplified schematic shown near the top of the first intro page, you'll see the essence of the design, which was where we initially began. This original pure solution delivers perfect remote security, but it lacks any provision for local abuse protection. If smartphones perfectly protected their applications from use by non-owners, and if it could be safe to export non-encrypted master identity keys, then that first diagram would be the finished solution. And it would be extremely secure. But we know that smartphones in the real (grubby) world are treated casually. People allow others to use and play with their phones, and there's probably no other application needing abuse prevention security safeguards more than a user's universal identity authenticator.
Consequently, it was necessary to add some additional functions to the conceptually pure design to make it practical and safe for use in the real world.
ONLY IF the user enters the correct password will the output of the PBKDF function correctly XOR with the current value of the identity master key to produce the correct original master key value which keys the private key generating HMAC function.
Every time the user changes their identity authentication password—including the first time when it is changed from a null password—the identity master key's value is updated to preserve the post-XOR value which keys the private key generating HMAC function.
When a brand new identity is first created, local device's cryptographically secure pseudo random number generator (CSPRNG), augmented by entropy streamed in from the device's camera(s) for five seconds (because SQRL is not going to rely solely upon any platform's CSPRNG), generates the user's identity master key. The system's secure PBKDF Scrypt function should be used for this.
The user will be prompted to enter and re-enter a master SQRL password which will be used to prove their identity to the application whenever they wish to adjust settings, import or export a backup master key, or identify and authenticate themselves to a remote website. Whenever a new password is being set, 64-bits of random “salt” will be created for input to Script's PBKFD2 functions. Then, driven by the user's supplied and confirmed new password, the Scrypt PBKDF function will generate a 256-bit value which will be XOR'd with the user's master key and that result used to key the private key generating HMAC function.
To verify future password reentry, that final 256-bit password output value is then hashed once more to produce a derived 256-bit value. The lower 128 bits of that value will be saved as the password verifier so that future password entries can be quickly verified. The single additional hashing yields a verification value that gives away nothing of the hash's previous 256-bit output
As mentioned above, the SQRL system employs the “Scrypt” function as its PBKDF. Scrypt is a so-called “sequential memory hard” function which was deliberately designed to require much more memory for its execution than traditional cryptographic hashing functions. This means that it actively resists acceleration by GPU's and FPGA's which inherently lack the “per-function” memory resources which Scrypt requires. Therefore, the first prong of defense is our use of a memory hard PBKDF for password processing.
The SQRL application uses Scrypt for password processing in two different “strengths”: a half-second strength used for on-the-fly user authentication, and the much longer 60-second strength used to protect the user's exported identity master key. These varying strengths balance cracking difficulty with convenience and relative threat level. Half a second is completely acceptable for interactive user-interface password verification, yet it still renders brute-force attacks inefficient enough as to be impractical. This time-targeted strengthening allows the entire password verification system to dynamically adapt to whatever platform it is installed upon, and to maintain a fixed half-second password verification time even as the speed and power of smartphones increases over time.
As discussed on the user experience page, since an exported identity master key potentially exposes its user to a password guessing attack, exported keys are encrypted under an Scrypt strength which requires a full 60 seconds of extremely acceleration resistant processing by the smartphone. Since importing and exporting master keys is performed infrequently, a 60-second wait is a useful and non-burdensome precaution for allowing the user's master key to exist outside of the phone.
Now that we have examined all aspects of the overall SQRL cryptographic architecture, let's look at how this structure supports the various user interactions described on the previous user experience page:
The user should probably first be asked to enter and re-enter a secure password to protect their identity. A built-in password strength meter should encourage them to use a longish password with a variety of character element types, etc. And it might also discourage their use of their “standard” password, which would help to improve their security. (“Oh, I know the password my mom always uses.”) They should also be instructed and encouraged to write this down and store it for safe keeping. We discuss this system's password recovery facility below, but there is no third-party to take responsibility.
Once the user has verified their ability to reenter their password, the app should ask them to wave the smartphone around until it chimes. The application would send the platform's random number generator, and five seconds of the smartphone's streaming video, through a secure SHA256 PBKDF2 function to generate the user's initial encrypted master key. This would be saved as shown above as their 256-bit identity master key.
Since the same password that was in place during the master key's export must be used after that key has been imported into the same or another device, the exported master key QR code also contains the 64-bit nonce salt, the 128-bit password verifier and the Scrypt strength parameter to allow for password verification after the master key has been imported. The system recognizes that the addition of password verification information enables an offline brute-force attack using only the information contained in the exported QR code. So the computational burden of verifying every password is increased to 60-seconds. During the exportation process, the system uses an Scrypt strength that yields 60 seconds of processing on the exporting smartphone. During this time a percentage complete indication is displayed.
Therefore, exportation of the user's master key converts the currently saved 256-bit master key into a QR code graphic for display, copying, eMailing, etc. The user would be instructed that it is “encrypted” by their current password, so it should be stored somewhere securely and the matching password at the time of its export should also be written down and saved alongside the QR code. (The user might change their working password after the export, but the exported key would be encrypted by their previous password.)
Importation of a master identity key would occur either to add a new user identity to the application or to overwrite an existing identity. In either case, the password which was associated with that key at the time it was exported MUST be provided to catch entry errors. (This, of course, protects the user from theft of their identity master key.)
What about the mysterious “Make Public Key”
and “Crypto Signature” functions?
The other necessary feature offered by elliptic curves over RSA prime factorization cryptography is the performance of key generation, digest signing and signature verification. For this system to be feasible on the authenticating server's end, signature verification must be extremely fast and efficient . . . and we do have that.
The SQRL system uses the so-called “25519” (as in 2255-19) elliptic curve, which was developed by and has been extensively studied by University of Illinois mathematician, cryptographer, programmer, and research professor of computer science, Daniel Julius Bernstein, who is well know by his initials DJB or more often just “djb.” He maintains the website at the double-take worthy domain name of: “cr.yp.to”.
Since the SQRL system uses a unique public/private key pair for every website, even if it were possible to somehow crack an instance of authentication security (and no one knows how to do that in any reasonable length of time) only that one website's authentication would be compromised. Every other site authenticates with its own unique keys.
And finally, Dan states that the best known attacks appear to require a minimum of 2140 operations, so he exceeded even his original security target by a factor of 4,096.
Having established an understanding of the complete SQRL architecture, let's now turn to the topic of: Attacks, weaknesses and vulnerabilities.
Gibson Research Corporation is owned and operated by Steve Gibson. The contents
of this page are Copyright (c) 2014 Gibson Research Corporation. SpinRite, ShieldsUP,
NanoProbe, and any other indicated trademarks are registered trademarks of Gibson
|Last Edit: Oct 29, 2013 at 18:59 (577.85 days ago)||Viewed 12 times per day|