The Internet Computer replaces usernames and passwords with a more advanced and secure method of encrypted authentication.
To understand what identity and authentication means in the context of Internet computers, we must first how its used in today’s networks.
When logging into a Web site, a user name is usually an e-mail address or a string of letters and numbers that is your unique identifier that links relevant data on the server to your identity. A password, on the other hand, is the means of authentication; in theory, only you know the password, and the server interprets your password as proof of its communication with you. The truth is, however, that passwords are not actually a good mechanism for remote authentication.
When you enter a password on a website, your computer sends it to the server and checks it against the password database. Unfortunately, hackers can gain access to these password databases. In the worst case, passwords are stored in plaintext on the server and are very insecure. Even if the passwords are encrypted, cracking them is simply a matter of whether the hacker is willing to invest computational and monetary resources in order to gain access.
The Internet Computer is a blockchain computing network that runs at network speeds and can increase its capacity without limit. It is designed to provide security against malicious behavior by individual computing providers by replicating data and computation across multiple data centers. It is important to note that replication, while protecting data integrity, does not prevent information leakage; the use of passwords on Internet computers is still subject to the same security issues as on traditional networks. Therefore, on Internet computers, we replace passwords with proper cryptographic authentication.
The primary cryptographic mechanism we use for authentication on Internet computers is a digital signature scheme. Digital signatures are a fairly standard concept, invented in the late 1970s and widely used since the mid-1990s.
It usually consists of the following three algorithms.
Key generation: Key generation can be thought of as choosing a cipher. Usually, key generation creates a pair of keys: 1) a private key that must be kept secret like a cipher, and 2) a public key derived from the private key that can be made public.
Signatures: Signatures require messages and private keys to be generated. When we use digital signatures for user authentication, the algorithm is run on the user side that holds the private key.
Verification: The algorithm receives the message, signature, and public key and verifies that the signature matches the message and the public key. The key property here is that unlike checking passwords, which need to be stored on the server, verification of signatures in this case can be done based on public information only, since the server stores a list of public keys, one for each user, and neither the public key nor the signature needs to be kept secret.
Applications on Internet computers are implemented based on containers (Canister) that interact by passing messages. In more detail, the interaction model is request-based, similar to a remote procedure call. When container A calls container B, container A specifies the target container, the name of the function to be called, and the parameters of the function. When the specified function is evaluated on container B, that container also knows that the function was called by container A. When evaluation is complete, Container A will get the return value of the function as a response. And the same remote procedure call model applies when the user interacts with a container. When the user invokes a container, the user sends a request to the target container. This request also specifies a function with parameters, and the user can also obtain the return value as a response. During the change of the request, the container also learns the identity of the user who invoked it.
Note: On ICP platforms, Canister is the most basic constituent element and can be understood as a container, similar to a smart contract on blockchain public chain platforms such as ethereum. These containers can be replicated, forked, and more easily self-organized.
The diagram above shows a user sending a request. The light gray area in the middle shows the core request, including the target container ID, function name, parameters, and the identity or subject of the caller. The dark gray area shows the envelope containing the authentication information, signature, and public key. The subject of the caller is derived from the public key by hashing, as shown on the left side of the figure. This technique is widely used in the blockchain space, as is the case with Bitcoin or Ether addresses, for example. In addition, the right part of the figure shows how the content of a request as a message in a digital signature scheme is bound to a public key by a signature. When an Internet computer receives such a request, it checks both the validity of the signature under the specified public key and the relationship between the public key and the subject of the caller.
To make sure that the message was indeed sent by the caller specified in the message, the container does not have to pay attention to these technical details. If everything is checked, the Internet computer evaluates the specified function on the container, but if one of the checks fails, the request is dropped.
Here are some details about the identity format we use. We start with the public key in DER format and hash it with SHA-224, resulting in a 28-byte string. We will add a byte to distinguish the identity subject from the public key from the identity subject we use elsewhere in the Internet computer, such as a container. These 29 bytes are represented in the internal binary of the user’s principal. When converting a principal to its textual representation, we first prepend a CRC-32 error detection code. Then, using the string generated by the Base32 encoding, we finally create groups of 5 characters each, separated by dashes. We chose this format to support easy copy-and-paste with proper error detection, while still allowing less than 64 characters in the ASCII representation for compatibility with Internet protocols such as DNS.
The schemes we have seen so far are still somewhat inflexible in their structure. They bind the user’s identity subject to a single encryption key, but this limitation can make it difficult for the user to interact with containers from different devices, as the need to share the same encryption key across these devices is both cumbersome and insecure. Instead, we use authorization between different encryption keys. As shown above, you can see the delegation from the yellow key to the orange key. This delegation includes the delegated key, which is the orange key; some additional parameters, such as expiration or limits on the scope of the delegation; and the signature of the delegated key, which is the yellow key.
When signing a request with the orange key, the user can use the delegate from the yellow key in order to use the identity from the yellow key. In addition, delegation is powerful because of the combinability. For example, an orange key can extend delegation to a purple key. This structure is very similar to PKI and X.509, but it is not a coincidence that we borrowed from them and used a more lightweight data structure.
One specific application of delegation is related to web authentication. Web Authentication is a recent standard from the World Wide Web Consortium (W3C) that focuses on two-factor authentication for web applications. The standard is motivated by the fact that, as mentioned earlier, passwords have serious security flaws. They often fall prey to cybercriminals when phishing emails, malware, and hacking attacks occur.
Two-factor authentication means that in addition to a password, logging into a web application requires an additional security factor, usually a secure device owned by the user. In reality, this could be a secure USB key or a secure chip built into the user’s terminal device and activated by biometrics, with the secure chip storing the encryption key. Since the encryption 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 generates a random challenge and sends it to the user’s browser. The browser then sends the challenge to the security device, which needs to interact with the user before signing the challenge. The signed challenge is then sent back to the server, which verifies the signature on the challenge against the user’s registered public key. This ensures that the security device needs to be held in addition to the password when logging into the web application.
It is an accepted fact that web authentication is an open standard, uses digital signatures for authentication, and is already supported by a wide range of devices. However, when adapting it to Internet computers, we had to overcome a number of obstacles. Network authentication assumes the session-oriented client-server model of traditional networks, where users authenticate once when they log into an application and send subsequent messages during the same session. In contrast, Internet computers implement a model and each request is authenticated individually. In particular, since there is no stateful session between the browser and the Internet computer, no server can generate a challenge and have it signed by a secure device. However, recall that in a typical network authentication process, the security appliance needs to provide a digital signature to the challenge sent by the server.
In order to implement request authentication using the same protocol, we need to use the request itself as the challenge and have it signed by the security appliance, similar to our general request authentication scheme. Another problem we must overcome is that network authentication requires user interaction for each signature. In a typical front-end provided by an Internet computer, a single page load may correspond to multiple requests. Since we did not want to require the user to explicitly acknowledge each request, we used the delegation mechanism described above. When interacting with a container using network authentication, we first generate a short-term session key. Network authentication is then used to sign a delegation oriented to that session key, so that a single user interaction can trigger multiple requests to the Internet computer.
While network authentication is useful for securely storing encryption keys, it binds these keys not only to the device, but also to a specific container. The reason for this is the browser’s security model, which strictly separates the state 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 a Web site. On an Internet computer, each origin then corresponds to a container. This strict separation of state is critical to security, but it also makes features such as key backups or supporting seamless access to the same container from multiple devices cumbersome, since all of these operations must be performed separately for each container. We solve this problem by using Internet identity services, i.e., identity providers, similar to the “sign in with Google or Facebook” feature you are familiar with on the Web.
When a user loads the front-end of a particular container for the first time, that front-end presents a “Sign in with IC” button. When the user clicks that button, the browser opens a pop-up window showing the Internet Identity Service, a specific application that allows users to manage their keys and identities. The user can then decide whether to allow the container front-end to use the user’s identity. If the user agrees, the browser will be redirected to the container front-end and will be able to access the container as the user. This mechanism will again trigger the session key and delegation mechanism. At that time, the container front-end generates a session key pair and transmits the public key to Internet Identity. If confirmed by the user, Internet Identity generates the delegation and returns it to the repository front-end. As an added benefit of signing through a large technology provider, the complete authentication process for the identity provider occurs on the user side, so there is much less exposure to the user’s private behavior, thus reducing identity tracking. (Internet Identity Services FAQ)
When it comes to user tracking, Internet Identity will provide a different identity for each container front-end that a user logs into, which is very beneficial for security and privacy. If this were not the case, Internet Identity would allow each front-end to log in under a single subject for the user. If that user interacts with unrelated services, such as message boards and shopping sites, those services could be associated behind the scenes with the user’s behavior on those sites. Worse, a message board front-end can maliciously invoke the container of a shopping site , and place orders in the user’s name. Therefore, the Internet Identity Service generates a different identity for each front-end that the user logs into and distinguishes it by host name. In this way, the user’s behavior on different services is less easily tracked. While the front-end is still able to use the user’s identity to invoke any container on the Internet computer, it is always only the identity associated with the front-end that performs the invocation.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/learn-about-dfinity-internet-computers-encrypted-network-authentication-and-identity-verification-in-one-article/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.