The appealing elegance and simplicity of the SQRL system is, more than anything else, the idea that a single globally unique user can be identified by a single globally unique ID (their 256-bit identity master key) while enforcing their privacy by presenting a different unique 256-bit identifier to every website on the Internet. The simple SQRL protocol accomplishes this using only a few cryptographic operations, and in a perfect hacker-free world with perfect users we would be finished, and could declare a job well done.

But the world is not hacker-free, and user's are not always perfect. So for SQRL to have the best chance of achieving wide adoption, it needs to not only be clearly superior to alternatives, but also work to address every criticism and concern. It must be able to offer answers to improbable if inevitable “what if” challenges. And, ultimately, its features must assure both users and websites that it will protect them, as well as possible, against both known and unknown threats.

SQRL's Identity Lock answers the question: “But what if someone,
someday, DOES obtain unencrypted access to a user's identity?”

To facilitate SQRL's possible life-long use by an individual, we felt that the user should be allowed to retire their current SQRL identity if, for any reason, they became concerned that it might no longer be secure and safe to use. Although today's individual websites will likely permit their users to perform a manual process involving traditional usernames, passwords, and eMail . . . what if the SQRL solution were to succeed so well that it eventually replaced other, current forms of authentication? Or what if users wishing the highest degree of security and anonymity established accounts lacking any other form of identity verification? In those cases, “out of band” SQRL identity changes would be impossible and the SQRL system would need to provide its own means for allowing its users to securely retire and replace worrisome or compromised identities. This is that system, here today, and part of the v1.0 SQRL specification.

Even though the only known weakness in the base SQRL system is user password compromise, and even though the system's password management system renders password guessing and hacking entirely infeasible, a user could use a very poor password or have their SQRL smartphone or desktop client hacked. The result would be a potential compromise of their entire Internet-wide SQRL-controlled identity. Because the “but what if that happens?” question can be asked, we have designed an answer.

Although ID Lock is independent of, and runs parallel to, the base SQRL identification protocol, it offers such strong and useful protection that it is a required component of the SQRL specification which every SQRL client and web server should implement.

SQRL's ID Lock provides a frictionless means for securely
authorizing SQRL client-mediated (“in band”) identity changes,
while simultaneously preventing unauthorized identity modification.

ID Lock operates by creating a second “master key” different from SQRL's regular identity master key. This second “Identity Unlock Key” is created when a user first sets up and begins using SQRL. It never changes, it may never be needed, but it should never be lost. To prevent attackers from having any opportunity to gain access to this key, it is never stored in any SQRL client application, and it is never written to non-volatile storage. After it is created, it must be printed onto paper as a graphic QR code or exported as a short text file and stored securely. Then it is completely removed from the SQRL device or application that created it. It cannot, and must not, remain accessible “online” in any fashion. This typically ends the user's involvement and responsibility for their identity management. The special “Identity Unlock Key” will likely (hopefully) never be needed, but in case it is ever needed it should not be lost.

To protect the user, once a user has established their identity with a website, the only (automated) way for the website to accept a new identity for the user is for a SQRL client to be temporarily re-loaded with the always-offline (super secret) Identity Unlock Key. Since this key is never normally present in any of the user's SQRL clients, it could never have become known to any attacker. Therefore, the presence of that key proves to the site that this really is the authentic user, not someone who may have somehow obtained the user's daily operation master key and password. This allows the user to retire and replace their previous identity with a new one so that anyone who may have obtained their master key and password will be unable to use them.

The Identity Unlock Key is never stored in the SQRL client, nor even electronically “online” in the computer, because no matter what, bad guys must never be allowed to obtain it. It exists outside, on paper only, specifically so that no possible breach of the user's normal daily operating security might possibly result in its disclosure. (Note that to be used, an attacker still needs to obtain the user's identity master key and matching password. So the offline Identity Unlock Key also enjoys all of the protections provided by the rest of the system. We just don't want it to be present in SQRL clients which might be hacked and the key obtained.)

Without the Identity Unlock Key, no one, not even the valid SQRL user, can alter their online identity. This means that if “but what if” actually did ever happen, although bad guys might gain access to a user's account, they could never lock the user out by changing the account's SQRL identity. Then, as soon as malicious access was detected, or preemptively, if a user was concerned that their SQRL identity master key and SQRL password might be compromised, the valid SQRL user could load their offline Identity Unlock key, retire and replace their own identity master key, then login to their most important web sites using SQRL to immediately replace their SQRL identity for every site they visit.

If the worst happened, and a user's decrypted SQRL identity somehow
escaped from their control, the user can securely cancel & replace
their lost identity, rendering the stolen (old) identity useless.

In keeping with SQRL's use of Dan Bernstein's highly efficient and carefully designed (NSA-free) Curve25519 elliptic curve cryptosystem, the SQRL ID Lock protocol uses an elliptic curve version of Diffie-Hellman (DH) Key Agreement (KA). Therefore, our use would be known as Elliptic Curve Diffie-Hellman, or ECDH. For additional information see Dan Bernstein's ECDH web page, and his Curve25519 PDF white paper.

The Identity Lock protocol is admittedly a bit tricky. It needs to be more complex than SQRL's comparatively straightforward identification protocol because its requirements are much more complex: When operating, it must be able to generate and provide something to every web server so that it's identity can later be proven, but what it generates and provides to each web server cannot in any way identify it to the server, since the SQRL system provides strong anonymity guarantees to prevent web servers from having anything they might compare to identify and track users. And on top of that, since it must also be truly hacker-proof, the system that generates this identity-proving information must not, itself, be able to prove its own identity . . . otherwise a compromised or hacked SQRL client could be used to maliciously prove its identity to “unlock” and alter a user's website identification. So we need to be able to provide anonymous identity proof without being able to prove our identity.

In the traditional use of DHKA, two parties wish to establish a shared secret key which they will then use to encrypt subsequent communications. So the parties first arrange to obtain each other's public keys. This can be done it full public view so long as no man-in-the-middle is able to intercept and subvert that public key exchange. In other words, a passive eavesdropper can be allowed or assumed to passively observe the exchange so long as they cannot alter it (to insert their own public key(s). Then, with each party having their own matching secret key, each is able to compute the same unique shared secret by applying the DHKA process. This shared secret cannot be computed by anyone having only the public keys, and of course, each party has their own secret key which they never disclose.

If we have public key one (PubKey1) and secret key one (SecKey1) and public key two (PubKey2) and secret key two (SecKey2), then:

DHKA( PubKey1, SecKey2 ) = DHKA( PubKey2, SecKey1 )

Some confusion can result from SQRL's unique application of Diffie-Hellman Key Agreement because it differs from the typical, more symmetrical use of DHKA. SQRL applies DHKA in a different, though valid, fashion. It uses three Diffie-Hellman properties that make it suitable for our needs:

• Secret keys are just random numbers. It's extremely quick and convenient to be able to simply pick a large 256-bit number at random and use it as a secret EC key.
• Public EC keys have a hash-like one-way relationship with their matching secret key. They are directly derived from their secret counterparts by running them through the EC function. This is a one-way function which, like a hash, does not reveal the secret key from the public key.
• Opposing pairs of keys combine to form a value that discloses nothing about either of them. Owing to the one-way nature of EC crypto, the “agreed upon key” does not reveal either key to attackers. In practice, this characteristic is less than absolutely strong, so the key agreement output is typically run through additional hashing to strongly disconnect it from its source keys.

Each side of the equation above requires two keys, one public and one secret, from each of the parties. And here's the key: If one is missing, the proper value of that side of the equation cannot be calculated and the equality assertion between the two sides cannot be satisfied. The SQRL ID Lock protocol relies upon that simple property.

One pair of keys is generated only once and never changes: The secret key is kept and stored offline for use only if the user's identity ever needs to be unlocked and changed. Therefore, we call this the “Identity Unlock Key.” Its complimentary public key is retained online in the client and is used to provide identity locking information when the user first introduces themselves to a new website. It's called the “Identity Lock Key.”

IdentityLock := MakePublic( IdentityUnlock )

The second pair of keys is generated at random every time a user is creating a new SQRL “identity association” with a website. First, a random 256-bit “Random Lock Key” is created. It is used to generate the identity locking information. Then, from it we generate the complimentary “Server Unlock Key” which the web server holds for us.

If we plug these four keys back into the original Diffie-Hellman Key Agreement equation, we get:

As shown in the two equations and schematic diagram below, the system uses three of these four keys to synthesize the fourth Server Unlock Key, and an additional public Verify Unlock Key which are both sent to and retained by the web server:

VerifyUnlock :=	SignPublic( DHKA( IdentityLock, RandomLock ))
ServerUnlock :=	MakePublic( RandomLock )

The “SignPublic” function is the “crypto_sign_seed_keypair” function from LibSodium. It is part of the Curve25519 elliptic curve cryptosystem which converts a 256-bit “seed” into a pair of signing keys: a private signing key and a public signature verification key. The VerifyUnlock key is the public signature verification key produced by that function.

After examining this glossary of key definitions and functions, we'll carefully step through the identity lock and unlock processes:

Identity Unlock Key: (IUK)	Randomly generated once, then printed and stored offline. The SQRL client must have access to this secret key for it to synthesize the Unlock Request Signing Key which the client must use to sign any identity change request.
Identity Lock Key: (ILK)	Generated once, but it can be regenerated if needed, because it is the public side of the Identity Unlock Key. It is retained by all of the user's SQRL clients and combined with randomly generated Random Lock Keys to create a web site's Verify Unlock Key (which verifies the signatures of any identity change requests).
Random Lock Key: (RLK)	Randomly chosen whenever the user is associating their SQRL identity with a new web server. It is used for two things, then discarded: It is mixed with the permanent Identity Lock Key (above) to produce the Verify Unlock Key, which the web server receives and stores. It is also used to create the Server Unlock Key which is also sent to the web server and stored.
Server Unlock Key: (SUK)	Generated by the SQRL client then sent to and retained by the web server. When the client later indicates that it wishes to change its identity association, the web server returns this public key to the client. The SQRL client combines it with its reloaded secret Identity Unlock Key to produce the Unlock Request Signing Key which must be used to sign any identity change request.
Verify Unlock Key: (VUK)	Received and retained by the web server from the client during the initial SQRL identity association, it is the public key used to verify the signature produced by the Unlock Request Signing Key. The web server will use this key, as it does with the SQRL identification protocol, to verify that the SQRL client is in possession of the matching Unlock Request Signing Key (which it could have only synthesized by combining the web server provided Server Unlock Key and its own secret, reloaded, Identity Unlock Key).
Unlock Request Signing Key (URSK):	Synthesized by the SQRL client by combining the web server supplied Server Unlock Key with the user's secret reloaded Identity Unlock Key. This produces a secret elliptic curve signing key that must be used to sign any SQRL client's identity change requests. The server's matching Verify Unlock Key is the public key used to verify the signature.

The SQRL client continuously holds onto the Identity Lock Key after it is created from the Identity Unlock Key. We cannot simply give every web server the public Identity Lock Key, because doing that would mean that we were giving every web server the same public key . . . which would break one of the SQRL system's most important properties: No ability to link user identities between servers.

Instead, we create a unique randomly derived version of our Identity Lock Key that cannot be traced back to our actual Identity Lock Key. We do this by first generating a new Random Lock Key and use the DHKA function to mix it with our Identity Lock Key (see below). This technically produces a 256-bit value that will be our private identity request signing key, but we don't use or retain it at this stage. Instead, we immediately pass it through Dan Bernstein's elliptic curve signing algorithm to produce its matching signature verifying public key. This becomes the Verify Unlock Key that is sent to and retained by the web server for it future use in verifying the signatures of the client's identity change requests.

In order for the client to later be able to re-synthesize the matching private signing key (which we just ignored and discarded), the Random Lock Key is also passed through a standard Curve25519 Diffie-Hellman Key Agreement (DHKA) function to create its matching public key. This becomes the Server Unlock Key which is sent to the web server for storage. When the SQRL client indicates that it wishes to update this user's identity, the web server returns this key which, when combined with the user's super-secret Identity Unlock Key allows the SQRL client to synthesize the private elliptic curve signing key which is required to sign any identity change requests:

When a user is first associating their SQRL identity with web server account (which we refer to as “identity association”) the SQRL client generates and the server receives and permanently stores the Server Unlock Key and the Verify Unlock Key which, as shown in the schematic above, are created on-the-fly and derived from a random number and the user's permanent Identity Lock Key. Once those keys have been set for a user, they never need to be changed. They are both unique public keys which disclose nothing about the user's identity. They serve to lock the value of the user's SQRL public identity key, which was provided when the identity association was established.

Although this has already been touched upon above, we'll examine it in greater detail here.

In order for an existing SQRL identity association to be re-enabled, updated, replaced or removed, the SQRL client must be able to cryptographically sign its identity change request by regenerating the correct private elliptic curve signing key. In response to the SQRL client's request to change identity association, the web server sends the SQRL client the stored value of the Server Unlock Key. This is the value the SQRL client originally generated and asked the web server to retain for just this eventuality. The Server Unlock Key provides the public half of a standard Diffie-Hellman Key Agreement (DHKA) where the private half is the user's super-secret, normally offline but now reloaded, Identity Unlock Key:

UnlockRequestSigning := SignPrivate( DHKA( ServerUnlock, IdentityUnlock ))

Similar to the VerifyUnlock key above, the “SignPrivate” function is the “crypto_sign_seed_keypair” function from LibSodium. It is part of the Curve25519 elliptic curve cryptosystem which converts a 256-bit “seed” into a pair of signing keys: a private signing key and a public signature verification key. The UnlockRequestSigning key is the private signing key produced by that function.

Since this is the right-hand side of the original equation above, it reproduces the private Unlock Request Signing Key which was briefly created but never used, other than to produce the matching public signature verifying Verify Unlock Key which the server also stored. The SQRL client combines the web server provided Server Unlock Key with the user's reloaded Identity Unlock Key to reproduce the original Unlock Request Signing Key. The client uses this recreated signing key to cryptographically sign its identity change request and sends that specially signed request to the web server.

The web server uses its stored Verify Unlock Key, which is the matching public signature verification key to verify the request's validity and authenticity, and updates the appropriate entries in the user's SQRL account database.

• The web server provides a cryptographically strong “nut” in every SQRL link URL and with every SQRL client query reply to protect all transactions and signatures from replay attacks.
• Note that to protect against replay attacks the web server must verify that the nut value returned by the SQRL client exactly matches the nut it supplied. This prevents an attacker from reusing a previously captured nut to again succeed with a replay attack.
• Since a new 256-bit Random Lock Key is only needed when a new identity association is being established with a web server, SQRL's demands for platform entropy are already very minimal. However, the identity lock protocol has very weak entropy requirements. The Random Lock Key is never exposed outside the client and it is situated behind one or two elliptic curve modular multiplications which are lossy one-way functions. So, unlike with SQRL's main operating secret keys—whose entropy requirements are extreme—there is little need to worry about or strengthen the generation of this transient and discarded key.
• It would have been more convenient to use the SQRL system's existing site-specific public and secret keys instead of continuously generating random keys for the Identity Unlock and Identity Lock keys. But if we had done that, an attacker who had compromised the user's password and identity master key would have been able to compute the value of the Server Unlock and Verify Unlock keys, thus defeating the system's protections. So we went with per-server random key values.
• For more information about the detailed operation of Diffie-Hellman key agreement, see the very good wikipedia entries: Diffie–Hellman key exchange and Elliptic curve Diffie–Hellman.

This straightforward protocol has the features of:

• Requires nothing more from the web server other than the storage of two static keys and verifying identity change requests using exactly the same logic and algorithms already being used by the base SQRL identification system.
• Reuses existing SQRL system EC components to smooth implementation and keep overall complexity low.
• Synthesizes one side of a DH key agreement without the secret key ever being present.
• Preserves anonymity by avoiding any cross-site linkage of identity-locking data.

If anyone were EVER to obtain access to a user's identity, the user can
securely cancel and replace their lost identity, making the stolen
identity useless and essentially taking back their lost identity.