Here is the first article of a serie dedicated to understanding and implementing Web Authentication API (WebAuthn) in a demo application.

The Web Authentication API (also known as WebAuthn) is a specification written by the W3C and FIDO, with the participation of Google, Mozilla, Microsoft, Yubico, and others. The API allows servers to register and authenticate users using public key cryptography instead of a password.

Source: https://webauthn.guide

In this article, I will explain the foundations of WebAuthn: public-key cryptography.

Public-key encryption

In computer science, cryptography is mainly concerned with security of messages exchanged through insecure networks like internet. Its principal application is encryption.
Encryption is the process by which a message, called plaintext, is rendered incomprehensible by an algorithm called cipher. The encrypted message is also called ciphertext. The cipher takes as input the plaintext and an encryption key which can be secret or public depending on the type of cipher. The cipher carries also the decryption, which is the process of getting the plaintext from the ciphertext. Strictly speaking, the cipher is composed of the encryption and decryption algorithms, which are not necessarily identical.

The key used during the encryption process can be the same used during the decryption process, in which case, we talk about symmetric encryption. Otherwise, when the decryption key is different from the encryption key, we talk about asymmetric encryption or public-key encryption.

In asymmetric encryption, the receiver of a message generates a pair of keys. One of the key is secret and kept securely by the receiver and is called private key. The other key is distributed to the message sender and is considered public, hence the name public-key encryption. The sender uses the public key to encrypt the message. The cipher is designed in a way that only the corresponding private key can decrypt the ciphertext. In this case, only the owner of the private key, the receiver, can decrypt the ciphertext.

When you encrypt a message with a private key and decrypt it with a public key, it's called signature and not encryption, as this process alone does not ensure confidentiality but authenticity.

Digital signature

Digital signature can be seen as a message metadata that stands as an attestation of the message authenticity and integrity. Authenticity is insurance about the message creator identity and integrity ensures that the message is not tampered with during transit.

Before explaining how public-key cryptography can be involved in the process of digital signature, we need to introduce another concept: hash functions.

In cryptography, a hash function is a one-way function that generates a hash value (also called message digest) from a message in a way that even the slightest modification of the original message generates a totally different message digest*.* The hash value is a serie of bits generally shorter than the original message. It is not possible to get the original message from the message digest. However, given the same input parameters, a hash function can be used to regenerate the message digest from the original message to make sure that it has not been modified by comparing hash values.

Now, let's see how digital signatures can be generated using public-key cryptography and hash functions.

Let's say Bob wants to send a document to Julie. He wants to guarantee to Julie that the document has been created by him and that no one has modified it during the transit. Bob has already generated a pair of public/private keys and distributed the public key to Julie.

First, Bob generates the message digest by hashing the document. Then, he signs the hash value using a cryptographic cipher and his private key. The result is Bob's digital signature of the original document. Since he is the only one who owns his private key, only him can generate such signature.
Bob then sends the document and his digital signature to Julie. She uses Bob's public-key to verify the signature by getting back the message digest. Julie also regenerates the message digest with the received document using the same hash function and ensure that the hash values match.
Any modification of the document occurred after its signature will render the signature invalid and any attempt by a third party to replace the signature will fail because only Bob has the private key necessary to generate a valid signature.

As previously mentioned, to verify a digital signature, the receiver needs the public key of the sender. If the number of senders grows, the number of public keys to maintain by the receiver may be unmanageable.
Now let's say that Julie receives a public key from a person claiming to be Bob. How Julie can make sure it is actually Bob's public key and not a man in the middle trying to impersonate Bob?
These issues are solved by digital certificates as we will see next.

Digital certificate

In the context of public-key cryptography, a digital certificate is a public key with identity signed by a trusted third party also called certificate authority. For instance, Bob's digital certificate would contain Bob’s name and his public key signed by a certificate authority.
The other parties who trust the certificate authority maintains his public key in order to verify the certificates he delivers.

Digital certificates solve the public key distribution issues mentioned above. Instead of sending his public key to Julie prior to sending her a signed document, Bob can send the signed document alongside his digital certificate to Julie. Since Julie has the public key of the certificate authority, she can verify Bob's certificate and trust Bob's public key after a successful verification. Julie does not need to store Bob's public key anymore and no one can forge Bob's certificate because it would require having the private key of the certificate authority.

The problem of getting the public key of the certificate authority remains, but it is much simpler. The receiver has to get and store securely only one public key and only once.

It is possible to have multiple certificate authorities in which case the receiver stores the public keys of all of them.
In some cases, there can be multiple layers of certificate authorities. For example, a root certificate authority can deliver a certificate to an intermediate certificate authority who delivers Bob's certificate. In this case, Julie only needs to store the root certificate authority's public key and Bob will send to Julie the signed document, his certificate and the certificate of the intermediate certificate authority. Julie will trust the intermediate certificate because it has been delivered by a root certificate authority she trusts. She will also trust Bob's certificate delivered by the intermediate certificate authority.

The system involving certificate authorities for digital certificates delivery and distribution in the context of public-key cryptography is called Public Key Infrastructure (PKI).

Public-key cryptography provides powerful tools to ensure confidentiality, authenticity and integrity of messages exchanged through insecure networks.

In the next article, we will see how WebAuthn leverages on these tools to drop password in user authentication.

Thanks for reading and stay tuned.