Documentation Analysis/Audience/Investigators

From SQRLauth.net
Revision as of 15:44, 2 July 2017 by Perlkönig (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Who are they?

These are people who want to better understand how the system works. They don't necessarily want to or even can understand all the math, but they do want more concrete details than the simply curious.

Existing Web Copy

The user experience:

[Image: SAMPLE SQRL Login Form]

Wishing to login to an online service where an “SQRL” code appears nearby:

  • The user can tap or click directly on the SQRL code to login,or launch their smartphone's SQRL app, and scan the QR code.
  • For verification, SQRL displays the domain name contained in the SQRL code.
  • After verifying the domain, the user permits the SQRL app to authenticate their identity.
  • Leaving the login information blank, the user clicks the “Log in” button... and is logged in. (A bit of page automation could even eliminate the need to click the “Log in” button.)

Even though it is THAT simple, it is FAR more secure than any other login solution. (We'll define exactly what “far more secure” means, below.)

What happened behind the scenes?(This is intended to quickly inform crypto-aware readers. Complete details are provided below.)

  • The QR code presented near the login prompt contains the URL of the authentication service for the site. The URL includes a securely generated long random number so that every presentation of the login page displays a different QR code. (In crypto circles this long random number is known as a “nonce.”)
  • The smartphone's SQRL authentication app cryptographically hashes the domain name of the site keyed by the user's master key to produce a site-specific public key pair.
  • The app cryptographically signs the entire URL contained in the QR code using the site-specific private key. Since the URL includes a secure long random number (the nonce), the signature is unique for that site and QR code.
  • The app issues a secure HTTPS POST query to the QR code's URL, which is the authentication service for the site. The POST provides the site-specific public key and the matching cryptographic signature of the QR code's URL.
  • The authenticating web site receives and acknowledges the POST query by returning a standard HTTP “200 OK” with no other content. The SQRL app acknowledges the successful submission of the user-signed QR code.
  • The authenticating site has the URL containing the nonce which came back from the login page via the user's smartphone. It also has a cryptographic signature of that URL, and the user's site-specific public key. It uses the public key to verify that the signature is valid for the URL. This confirms that the user who produced the signature used the private key corresponding to the public key. After verifying the signature, the authenticating site recognizes the now-authenticated user by their site-specific public key.

[Image: SQRL Public Key Generation and Authentication]

Summarizing this for your next cocktail party: “The website's login presents a QR code containing the URL of its authentication service, plus a nonce. The user's smartphone signs the login URL using a private key derived from its master secret and the URL's domain name. The Smartphone sends the matching public key to identify the user, and the signature to authenticate it.”

This simple and straightforward SQRL protocol yields a surprising array of features and benefits:

  • Anonymous Identification & Authentication:
    • SQRL ID: Visitors to a website are uniquely identified by an absolutely anonymous SQRL ID. Their “SQRL ID” is simply their public key, described above, a 256-bit number. The same visitor always presents the same ID every time they visit the same site. But no two visitors will ever have the same ID. Thus a single website can uniquely and anonymously identify every one of their visitors.
    • SQRL IDs are both user AND site specific: Although the same user always presents the same ID to the same site, they present an entirely different ID to every other site they visit. There is NO WAY TO ASSOCIATE the SQRL ID presented to one site with those presented to any other sites. In other words, there is absolutely no cross-site coupling of identity. Users are free to use their SQRL identity anywhere and everywhere because every site receives its own unique SQRL ID.
    • No annoying account creation: Suppose you wish to simply comment on a blog posting. Rather than going through the annoying process of “creating an account” to uniquely identify yourself to a new website (which such websites know causes them to lose valuable feedback traffic), you can login using your SQRL identity. If the site hasn't encountered your SQRL ID before, it might prompt you for a “handle name” to use for your postings. But either way, you immediately have an absolutely secure and unique identity on that system where no one can possibly impersonate you, and any time you ever return, you will be immediately and uniquely known. No account, no usernames or passwords. Nothing to remember or to forget. Your SQRL identity eliminates all of that.
    • An important note about anonymity: To be clear, virtually nothing else about the use of the Internet is securely anonymous. A web browser's collection and regurgitation of cookies and other telltale debris, your connection IP address, your ISP, etc. all provide potentially identifying and de-anonymizing data. This SQRL system does not, and is not intended to, circumvent, defeat, or resolve any of those problems. This system simply generates a highly secure persistent “opaque identification token” which is dynamically authenticated to prevent impersonation... and it does so instantly, with startling ease-of-use.
  • Inherent Protection From Hackers:
    • Identification vs Authentication: SQRL-enabled websites have only your unique SQRL ID to disclose, and it is useful only to that single site since every users SQRL ID is automatically unique for every site they visit. There need not be any username or password for sites to have compromised, lost or stolen. Your SQRL ID does not authenticate your identity, it only identifies you to that single website. Authentication requires the SQRL smartphone app to cryptographically sign a long random number and return it with your SQRL ID (your public key). Thus, even if a hacker were to obtain your stored SQRL ID, it is useless for impersonating you—even to that one site—because the private key required to create the signature never leaves your smartphone.
    • The opportunity for strong anti-phishing countermeasures: This is significant enough that it has its own page: “How SQRL Can Thwart Phishing Attacks” (page 5 in the link block at the bottom of this page.) SQRL can be used for “same-device” login, where a desktop, laptop, tablet, or smartphone user wishes to login securely on the same device they are using. (This is different than the “cross-device” login we have been examining where an optical QR code is scanned. “Same-device” login is also discussed below.) In same-device login, the IP address of the SQRL login authentication will be identical to the IP address that received the login page's QR code image. This means that a sophisticated website spoofing/phishing attack, which SQRL already makes much more difficult, will be detectable and easily blocked.
    • “Identity Lock” prevents identity change & allows recovery: This is also significant enough to deserve its own detailed description page: “The identity lock protocol” (page 4 in the link block at the bottom of this page.) Once a user's identity has been established with a web server, the SQRL client is unable to change that identity. This means that if the worst happened, and a very weak and easily guessed password was used, or a user's phone or desktop was hacked to obtain their identity master key and password, no malicious third party can change the user's online identity to lock them out of their own online accounts. And, moreover, by then loading an a normally offline “Identity Unlock Key”, the true owner of their identity can retire and replace their lost or stolen online identity to essentially take it back from any attacker, rendering their previous identity useless. Please see page 4 for all the details.
    • No “shared secrets” with websites: Six-digit time-based authenticators are based upon a cryptographic secret known only (we hope) to your smartphone and the authenticating website. This allows the website and your phone to agree upon which six-digits will be shown at any time. While this has the benefit of always changing, it repeats the username and password problem of needing to always be kept secret . . . which websites continuously demonstrate is beyond them. (And remember, the employees of those websites do have access to your credentials.) Also like passwords, because they are not truly secure, you must employ a separate and unique authentication sequence for every website you use. If this were to become popular and widespread, you would soon be scrolling through hundreds of six-digit numbers to find the right one. SQRL gives websites no secrets to keep.
    • Out-of-band authentication: In the context of an untrusted computer, we mentioned above how website visitors were almost magically logged in without touching the computer's keyboard. This is one aspect of an important security principle known as “out of band.” The principle is that it is generally more secure not to send all aspects of a secure communication through a single channel because the security of that channel may be compromised. Entering your username, password, and one-time password all through the same keyboard is worrisome “all in band” authentication. Difficult though it might be to compromise the security of any single channel, it is vastly more difficult to simultaneously compromise two very different forms of communication. Since SQRL uses a smartphone's connection to the internet, perhaps even a cellular carrier, it avoids reusing most or all of the local computer's channel. Authentication often occurs completely “out of band”, and thus invisible to any intruder monitoring the computer's communications.
    • No keyboard interaction: Imagine that you want to login to a computer at an unsafe location such as a library or a hotel. With SQRL, your login occurs without entering any personal credential information into the computer. You provide no username or password that might be captured by a keystroke logger or resident malware. The website issues an “SQRL authentication challenge” in the form of a unique SQRL graphic code. If you have an SQRL smartphone app, it takes up the challenge and sends the website a unique challenge response that can only have come from you. The website then logs you in when you click “Log in” under the still-empty login form. From the standpoint of that computer—and anything it might contain that's attempting to spy on you—you are magically logged in without your credentials ever appearing or passing through. Your smartphone's SQRL application saw the site's SQRL code, instantly identified you to the site, and provided cryptographic proof that the person who just clicked the “Log in” button . . . is you.
  • Protection From Hostile Authorities:
    • No third-party involvement: In this era of pervasive government surveillance and US NSA coercion, who is going to trust any third-party with their identity? Other identity systems and solutions attempt to “federate” trust by creating a role for themselves as a third party with whom you establish a separate trust relationship. Then the authenticating website asks that third party to verify your identity on your behalf. It would be one thing if there were no alternative. But this page, and the pages that follow, demonstrate that secure and practical anonymous identification can use an entirely first-party protocol while delivering extreme ease of use.
    • Easily scram and recover: SQRL's inherently stateless operation creates additional security benefits. Imagine that you and your smartphone are be crossing a country's border with potentially nosey or hostile authorities. If you are not comfortable relying upon SQRL's very strong and brute-force-proof (see following pages) password protections, you can simply delete your user account from the SQRL app, or even delete the SQRL app from the phone completely. There will be nothing for any authorities to find. Then, since SQRL's entire state (containing your identity master key, ID lock, etc.) is backed up on a single low-resolution small QR code patch, you can later reinstall the app, retrieve the QR code from your wallet, shoe, the back of your watch, the tattoo on the bottom of your foot . . . or wherever you had creatively hidden it. You scan your master key, apply your password, wait a minute for the deliberately slow import decryption process to complete (which massively retards guessing) . . . and your ability to identity and authenticate yourself to every SQRL-supporting site in the Internet is fully restored.

The LACK of third-party involvement

The use of a third-party “middleman” transfers much of the responsibility for the management of your online identity to an external facility. In an era of secret national security letters compelling the disclosure of whatever the government desires, that's a serious liability (as mentioned above), but it can also be a significant benefit: If your smartphone escapes from your control, you need only tell the third-party to cancel the phone's authentication authority and you're immediately protected from malicious use of your smartphone's identity assertion. This SQRL system concentrates ALL authentication authority into the smartphone. The benefit is that no one else has the keys to your online identity. No one. But the liability is that YOU are then absolutely responsible for maintaining the security of your online identity. Ultimately, someone has to be responsible for your identity. Should it be you, or someone else?

This is a serious issue that needed to be addressed. Our solution is to provide the user with a conceptually simple set of tools to dramatically ease the burden of assuming and managing this responsibility. As subsequent pages detail, the system provides extensive cloning, backup, local password protection and reset capability.

Hold on a second . . . We send the website a signed bunch of gibberish? That's it?

Yes. And that's exactly the point. SQRL provides absolutely anonymous identity authentication (IA). Users are identified only by a random “opaque token” and each unique combination of user and website creates a unique identity token. Thus, every user presents a unique identity to every website they visit. It is up to the user and the website to then (optionally) bind the user's unique SQRL identity to a real-world account on the website.

For example, Amazon's account management might have an option to associate a logged in user with their Amazon SQRL identity. So Amazon would present a unique SQRL code on the account management page. The user simply snaps it with their smartphone's SQRL app and now Amazon can add their SQRL ID to their account. From now on, the user can login to Amazon anywhere with vastly improved security just that easily.

And it would probably work the other way around too: Amazon's login page would present traditional login fields and a SQRL code on the side. An existing Amazon user who is establishing their SQRL identity snaps the SQRL code with their new smartphone app and Amazon replies that it does not recognize the user. If they wish to create a new account, they may do so here, or if they are an existing user, please use traditional login one last time to associate their new SQRL identity with their existing Amazon account.

Defending against the dark forces Why we prominently display the domain name BEFORE authenticating: The smartphone has no way of knowing the website the user is visiting. It only receives the domain contained in the QR code displayed by that page. In one of the possible "Evil Website" attacks (discussed on the attacks page), a malicious website pretends to offer an SQRL login for itself (www.evilsite.com), but instead it obtains and displays a login QR code from some other domain (www.amazon.com) where an SQRL user may be known. The SQRL app always identifies and authenticates its user to the domain contained within the (human unreadable) QR code. So an unwitting user, who didn't know the domain they were about to login and authenticate to, could be logging themselves into a session initiated and controlled by the Evil Website, thus allowing the Evil Website to impersonate them.

Note that even in this instance, none of the user's login credentials ever become known to the Evil Website. The Evil Website only gets a spontaneously logged-in session (though that's clearly not a good thing!)

This risk can be easily mitigated, however, simply by having the user's smartphone first prominently display the domain name it will authenticate to only if the user gives it permission to proceed. The user knows they are visiting “www.evilsite.com.” So if their phone asks for permission to login to “www.amazon.com” they just say no. Trusting the app: Though it should go without saying, it's better to say it: Until SQRL support is moved into the underlying smartphone OS, and is then curated perhaps more carefully, users will be responsible for choosing and installing an SQRL client into their smartphones. As the SQRL system gains in popularity, it is foreseeable that malicious developers might create malicious applications to steal their users' credentials. This is not a problem that's in any way unique to SQRL. Any sort of identity or password manager needs to be carefully vetted before it is entrusted with important information. The standard advice here is to stick with the herd and go with the solution that's been most thoroughly examined, checked out, and proven.

Practical Considerations:

  • Open & free, as it should be: The component techniques and technologies employed by this solution are all well known, well tested, well understood, unencumbered by patents, and exist in the public domain. The entire system can be readily assembled from 100% open source algorithms, packages and libraries.
  • Did I invent anything? I don't care. Even if some aspects of this system are novel, and might be subject to intellectual property protection, this is too important and much bigger than me. It should be made free for the world to use without encumbrance. With this publication of every detail, I hereby release and disclaim any and all proprietary rights to any new ideas developed and presented herein. This work is thereby added to the public domain.
  • The chicken & egg problem: There was a time before the Internet, when people asked: If there are no high-quality websites no one will use the Internet; and if no one is using the Internet no one will bother creating high-quality websites. Somehow it happened anyway. We hope and expect that SQRL login will be like that. Once we have established the required interoperability standards, people WILL create free smartphone SQRL clients—probably many. And as websites begin to offer SQRL login as a side-by-side alternative to the traditional username and password, SQRL popularity will grow. Why would anyone NOT use it when it's free, perfect, and just works? Users will want it because it immediately eliminates the most annoying aspect of the Internet. Website visitors will demand it and websites will soon see that they are losing visitors by not offering the instantaneous SQRL option. Now that we have such a terrific egg, it's difficult to see what's going to keep it from hatching, surviving, and growing.
  • It only works with a smartphone? Not any more. See the “Three Ways to Go” section above. It can be used to login to a smartphone's displayed website and with only a desktop or laptop.
  • QR Codes? Yes. Or not. A QR code is an elegant, robust, convenient and instantly recognizable icon that now can represent “instant log in authentication.” But the QR code is simply conveying a standard format URL. And we've already seen (above) that the SQRL code can be tapped or clicked-on to invoke the QR code as a link. So anything that can convey an Internet-format URL can be used. QR codes simply have many nice properties, both visually and technically.
  • Minimal complexity: Committee-designed solutions too often suffer from the “too many cooks” syndrome. This SQRL solution has been designed to make just one thing, which should be simple, very simple indeed. It's the one thing that most people do most of the time and wish was fast, simple and secure. It is.
  • Computational burden: Despite the fact that this is a public key authentication system, you will see on the following pages that a set of algorithms and parameters have been carefully chosen to minimize client and server-side authentication overhead. In particular, the all-important server-side signature verification is very fast and lightweight.
  • NSA & NIST-free cryptography: The recommended implementation of this system leverages several unique characteristics of well-known cryptographer Dr. Daniel J. Bernstein's (DJB) carefully designed twisted Edward's curve digital signature algorithm (EdDSA). In his extensive and complete papers (linked herein) Bernstein explains the detailed derivation and properties of his “25519” elliptic curve. Importantly, there are no mysterious constants or “magic numbers” of unknown provenance. Dan has a long and well-known history of fighting for cryptographic freedom. In 1995, while a student at the University of California, Berkeley, Dan brought a lawsuit against the United States (represented by the EFF) challenging the restrictions on the export of cryptography . . . because he wanted to publish a paper and associated source code of this “Snuffle” encryption system. The ruling in the case declared software as protected speech under the First Amendment, and national restrictions on encryption software were overturned. (He won.) Please see the Detailed Crypto Architecture page for full detail and discussion.

So what's left?

We're JUST getting started!

What we've seen so far are only the broad outlines of the solution, enough to provide an overview of the system's operation to interested parties, to perhaps convince skeptics that such a system CAN operate, and to create a foundation and interest in the further detailed pages that follow.

Among the problems we have solved to create a practical solution, are:

  • How are identities backed up and/or cloned to other devices?
  • What about logging into a website displayed on the smartphone's own browser?
  • What if the smartphone that contains my identity is lost or stolen?
  • What about password protecting logins on the phone?
  • What if the phone is hacked?
  • What about different people (and identities) sharing one phone?
  • What about having multiple identities for the same website?

There are workable solutions to every one of those problems, and more. The full implementation of the system protects the user's identities even if their smartphone is stolen and every secret it contains, becomes known.

All the content here: https://www.grc.com/sqrl/userview.htm

SQRL's Identity Lock Protocol The problem:

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.

The User's Experience

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.

Note that since there could be an emergency situation where a user needs to block their SQRL identity for specific sites, but they might not have immediate access to their “Identity Unlock Key”, SQRL permits a user to disable their current identity at a website without needing Identity Unlock Key. They must then later use their Identity Unlock Key to either re-enable or replace their identity. But they can, in an emergency, disable any existing identity.

The SQRL system takes advantage of this stronger tamper-proofing and enhanced trust in three ways:

  • Login Redirection

As we know, the user's web browser is not actually viewing the authentic web site. It is viewing a malicious copy of the authentic web site. In effect, it got off on the wrong foot by first visiting a spoofed web address. But as the diagram above shows, the SQRL login agent IS communicating directly with the authentic web site. So, if the authentic web site were to respond to the SQRL login agent with a correct link to the logged-in web session instead of logging in the fraudulent session which was initiated by user's browser, the SQRL login agent could follow the correct that link to safely login its user, thus bypassing and dropping the attempted and failed malicious login.

  • Action Confirmation

Another way the authentic web server can take advantage of the SQRL login agent's direct connection to it is by sending confirmation requests for important actions back to the SQRL login agent rather than to the regular web session. If, for example, the malicious man-in-the-middle attempted to transfer money from the user's online account, but the user had logged in and authenticated using SQRL, the authentic web server could send a confirmation of this request NOT back to the user's web browser session (which may have been compromised) but instead to the SQRL login agent, thus bypassing any interference from the man in the middle. The user would receive a request to confirm an unexpected transaction and decline to approve it.

  • Man In The Middle Detection

When the SQRL login agent resides on the same device (computer, tablet, mobile phone, etc.) as the user's web browser, both the web browser's web queries, and the SQRL login agent's login authentication queries, would share that machine's IP address. This is known as “same-device” SQRL login, and it provides another strong anti-phishing / anti-man-in-the-middle attack mitigation. As you can see in the diagram above, from the perspective of the authentic web server, fraudulent man-in-the-middle web queries will be received from the IP address of the MITM server — not from the user's web browser — but the user's SQRL login agent's queries will be received from the IP address of the SQRL login agent. When the authentic web server sees that those IPs are different, it will warn the SQRL login agent. If the SQRL agent expects that its queries should have the same IP as the user's web browser, it can warn the user and abort the login.

SQRL Commentary

  • Don Kiely's DevPro Blog: Securely SQRL Away Authentication Credentials
  • Cristian Satnic's OdeToData Blog: Time to say goodbye to usernames and passwords for website authentication
  • BraveNewCoin Blog: SQRL Revolutionizing Web Site Login And Authentication

Some of the content from here: https://www.grc.com/sqrl/faq.htm