Web Authentication and Identity on the Internet Computer
The Internet Computer replaces usernames and passwords with a more advanced and secure method of cryptographic authentication.
By Björn Tackmann, Team Lead, Research | DFINITY
To understand what identity and authentication mean in the context of the Internet Computer, the world’s first blockchain network that runs at web speed and can increase its capacity without bound, we must first consider how identity and authentication are used with the web today.
When you log into a website, your username is typically either your email address or a string of letters and numbers, which acts as your unique identifier that connects the relevant data on the servers with your identity. Your password is the means of authentication. Since, in theory, only you should know your password, the server interprets your password as proof that it is communicating with you. But it turns out that passwords are actually not a good mechanism for remote authentication.
When you enter your password on a website, your computer sends the password to a server, where it is checked against a password database. Unfortunately, hackers can gain access to these password databases. In the most egregious cases, passwords are stored on the server in plaintext, which is not a recommended security practice. However, even if passwords are encrypted, recovering them is only a matter of the computational and monetary resources that the hacker is willing to invest in order to gain access.
The Internet Computer is designed to provide security against the malicious behavior of individual compute providers by replicating data and computation across multiple data centers. Replication, while protecting the integrity of the data, does not protect against leakage of information; the use of passwords on the Internet Computer would still be subject to the same security issues as on the traditional web. Therefore, with the Internet Computer, we have replaced passwords with proper cryptographic authentication.
The main cryptographic mechanism we use for authentication on the Internet Computer is a digital signature scheme. Digital signatures are a pretty standard concept. They were invented in the late 1970s and have been widely used since at least the mid-1990s.
They are generally thought of as consisting of three algorithms:
- Key generation, which you can think of as an analog for choosing a password. Key generation creates a pair of keys: 1) a private key that has to be kept secret, just like a password, and 2) a public key that is derived from the private key, but can be made public.
- Signing, which takes a message and the private key and produces a signature. When we use digital signatures for user authentication, this algorithm is run on the user side where the private key is held.
- Verification, which takes the message, the signature, and the public key and verifies that the signature matches the message and public key. The crucial property here is that unlike checking a password, which requires the secret password to be stored on the server, the verification of a signature in this case can be performed merely based on public information. The server stores a list of public keys, one for each user, and neither the public key nor the signature have to remain secret.
Applications on the Internet Computer are implemented based on canister smart contracts that interact by passing messages. In a bit more detail, the interaction model is based on requests, which are a lot like remote procedure calls. When Canister A calls Canister B, Canister A specifies the target canister, which is Canister B, the name of the function it attends to call, and the arguments for the function. When the specified function is evaluated on Canister B, that canister is also aware that the function was invoked by Canister A. After the evaluation is complete, Canister A obtains the return value of the function as a response. The same remote procedure call model applies when users interact with canisters. When a user calls a canister, the user sends a request to the target canister. This request also specifies a function with arguments and the user obtains the return as a response. During the variation of the request, the canister also learns the identity of the user invoking it.
The above figure shows a schematic view of a request sent from a user. The light gray area in the middle shows the core request: the target canister ID, the function name, the arguments, and the identity or principal of the caller. The darker gray area shows the envelope that contains the authentication information, the signature, and the public key. As shown on the left-hand side, the caller’s principal is derived by hashing from the public key. This technique is used widely in the blockchain space, such as in Bitcoin or Ethereum addresses. The right-hand side shows how the contents of the request as a message in a digital signature scheme are bound to the public key via the signature. When the Internet Computer receives such a request, it checks both whether the signature is valid under the specified public key, as well as the relation between the public key and the caller principal.
To ensure that the message was indeed sent by the caller specified in the message, the canister does not have to bother with these technical details. If everything checks out, the Internet Computer evaluates the specified function on the canister. If one of the checks fails, the request is simply dropped.
I’d like to mention a few details about the format of the principals we use. We start with a public key in the DER format and hash it with SHA-224, resulting in a 28-byte string. We append a single byte that only serves to differentiate principals derived from public keys from ones we use elsewhere in the Internet Computer, such as for canisters. Those 29 bytes are the internal binary representation of a user’s principal. When converting a principal to its textual representation, we first prepend a CRC-32 error detection code. We then encode the resulting string in Base32, and finally build groups of five characters each, separated by dashes. The format has been chosen to support easy copy-pasting with appropriate error detection, while still allowing for less than 64 characters in ASCII representation for compatibility with internet protocols, such as DNS.
The scheme we’ve seen up to this point is still a bit inflexible by construction. It binds the user’s principal to a single cryptographic key. This restriction makes it difficult for a user to interact with canisters from different devices, as that would require the sharing of the same cryptographic key between those devices, which is both tedious and discouraged from a security perspective. Instead, we use delegations between different cryptographic keys. In the above figure, you see a delegation from the yellow key to the orange key. Such a delegation consists of the delegated key, the orange one; some additional parameters, such as an expiration or a restriction of the scope of the delegation; and the signature of the delegating key, the yellow one.
When signing a request with the orange key, the user can now include the delegation from the yellow key in order to use the identity derived from the yellow key. What is particularly powerful about delegations is that they can be composed. For example, the orange key can extend the delegation to the purple key. If all that seems familiar from the public key infrastructure and X.509, it is no coincidence — we’re just using more lightweight data structures.
One specific application of delegations is related to web authentication. Web authentication is a recent standard of the World Wide Web Consortium (W3C), and mainly targets two-factor authentication for web applications. The motivation for the standard is that, as indicated earlier, passwords have severe security deficiencies. They often fall prey to cybercriminals, whether via phishing emails and malware installed on user devices, or when services are hacked.
Two-factor authentication means that besides the password, logging into web applications also requires an additional security factor, usually a secure device that the user owns. In practice, that could be a secure USB key or a secure chip that is built into the user’s end device and activated via biometrics. The secure chip stores cryptographic keys. As the cryptographic keys never leave the secure chip, they remain secure, even if the user’s computer or phone is infected with malware.
When web authentication is used as a second factor in a web application, the protocol flow is as follows: After the user initiates the login process by providing a username and password, the web server will generate a random challenge and send it to the user’s browser. The browser then sends the challenge to the secure device, which requires user interaction before it signs the challenge. The signed challenge is then sent back to the server, which verifies the signature on the challenge relative to the user’s registered public key. This ensures that logging into the web application requires holding the secure device in addition to the password.
We are building on the fact that web authentication is an open standard that uses digital signatures for authentication and is already supported on a broad range of devices. When adapting it for the Internet Computer, however, we had to overcome a few hurdles. Web authentication assumes the session-oriented client server model of the traditional web, where a user authenticates once when logging in with the application and sends subsequent messages within the same session. In contrast, the Internet Computer implements a model where each request is authenticated individually. In particular, there is no server that can generate a challenge to be signed by the security device, as there is no stateful session between the browser and the Internet Computer. Recall, however, that in the typical web authentication flow, the secure device provides a digital signature on the challenge sent by the server.
To implement request authentication using the same protocol, we use the request itself as the challenge and have it signed by the secure device, analogous to our general request authentication scheme. Another issue that we had to overcome is that web authentication requires user interaction for every signature. In the typical front ends served by the Internet Computer, a single page load can correspond to multiple requests. Since we don’t want to require the user to explicitly confirm each request, we use the delegation mechanism described above. When interacting with a canister using web authentication, we first generate a short-term session key. We then use web authentication to sign a delegation towards that session key, so that the single user interaction can trigger multiple requests to the Internet Computer.
While web authentication is great for storing cryptographic keys securely, it binds those keys not only to the device, but also to a particular canister. The reason for this is the browser security model, which strictly separates the states accessible to different applications running in the same web browser by their origin. On the web, you can think of an origin as roughly corresponding to one website. On the Internet Computer, each origin corresponds to one canister. This strict state separation is vital for security, but it also makes functions such as key backup or support for accessing the same canisters seamlessly from multiple devices tedious, since all those operations have to be performed separately for each canister. We resolve this issue by using the Internet Identity service, an identity provider that is similar to the “Sign in with Google or Facebook” functionality that you’re familiar with from the web.
When a user first loads the front end of a given canister, that front end can present a “Sign in with the IC” button. When the user clicks that button, the browser opens a pop-up with the Internet Identity service, a specific application that allows the user to manage the keys and identities. There, the user can then decide whether to allow the canister front end to use the user’s identity. If the user approves, the browser is redirected to the canister front end and can access the canister under the user’s identity. This mechanism again uses the session key and delegation mechanisms. The canister front end generates a session key pair and transfers the public key to Internet Identity. If the user confirms, Internet Identity generates a delegation, and returns it to the canister front end. As an additional benefit over signing in via a Big Tech provider, the complete authentication flow in the identity provider happens on the user side, so there is much less exposure of private user actions and thus much less tracking. (Internet Identity Service FAQ)
Speaking about user tracking, Internet Identity will give the user a different identity for every canister front end that they log into, which is great for security and privacy. If it were not so, Internet Identity would allow every front end to log in under the user’s single principal. If that user interacts with unrelated services — for example, a message board and a shopping site — these could behind the back correlate the user’s behavior on these sites. And even worse, the front end of the message board could maliciously call the canisters of the shopping site and make orders in the user’s name. Therefore, the Internet Identity service generates a different identity for every front end that the user logs into, with the front ends differentiated by their hostname. This way, a user’s actions on different services are not so easily tracked. While the front end is still able to call any canister on the Internet Computer using the user’s identity, it is only ever the identity that is associated with the front end performing the calls.
The mechanisms described above and used in Internet Identity are specified in detail in the Internet Computer Interface Specification that we released recently — and we’re looking forward to seeing what else our developer community is going to build from it.
_____
Stay tuned for more releases detailing the technologies behind the Internet Computer.
