Passkeys are a newly popular mechanism for accelerating a “passwordless future” for digital identities, heralded by Google as “the beginning of the end of the password.” But, there are challenges that still face this form of user authentication — the problem of portability. 

What happens if a user loses their signing device? 

Engineers at the Oasis Foundation believe in a better solution for the future of authenticating digital identities. Keep reading to explore why passkeys are not ideal and how encrypted key management contracts on Oasis are safer and more reliable.

‍The Problem of Portability

Some readers may not be familiar with passkeys. They are a relatively new form of digital authentication that sends a challenge to a user’s device when they try to log in to a service. When their device uses a private key to sign and complete the challenge, the user can access their account. Passkeys are functionally the same as a username and password combination that most Web2 users are familiar with, and they’re intended to make the authentication experience easier for consumers. 

But, this “Password 2.0” system has some very important differences. 

Passkeys are intended to solve a couple core problems with regular passwords, namely phishing attacks and data breaches. Public key cryptographic stores keys on the user’s device, and it is possible to use passkeys via WebAuthentication, or “WebAuthn,” to encrypt user data by deriving a key from a signing operation. But there is still the problem of portability that needs to be solved. 

What happens when a signing device is lost? 

First, all credentials are not passkeys. For example, the WebAuthN registration and credential signing flow on Android and desktop prompts users to add any supported device to their account, for example, hardware tokens, NFC security devices, an Android or iOS device linked with a QR code. Authentication via Android devices or hardware tokens (e.g., Thetis or Yubikey) will likely be device locked, and they are protected by a secure enclave, which secures the key from theft by preventing it from leaving the physical device. So, users should never assume that a credential they register is a passkey and is portable. 

For credentials that are passkeys, however, Apple, Google, and other companies alert users that passkeys can be recovered by accounts synced to a cloud account. But, the recovery process involves not only a traditional username-and-password combination, it also uses SMS verification. Almost everyone in Web3 is probably very familiar with the risks of SMS verification, including no encryption, network outages, SIM-Swapping and social engineering. Could this be a step forward or backward for user authentication? 

The WebAuthN standard mentioned above for registration and signing isn't specific to passkeys. So, while some implementations like Apple hardware or password managers may support passkeys, which can be migrated across devices, this is not the norm — valid security concerns could also be raised even for credentials that are portable. Non-portable credentials are sometimes referred to as “device-bound passkeys,” which is an apt name. Ultimately, the fact is that if an encryption key is tied to a specific device, all encrypted data may become unrecoverable if the device is lost. 

Innovative tools for replacing traditional customer identity and access management (CIAM) systems are essential for the future of the Internet. So, what’s the solution? 

‍Adding More Authentication Modes

One solution to secure portable identity is to permit multiple authentication methods for an account. This method is favored by many emerging account abstraction frameworks in Web3 and by prominent Web2 platforms like GitHub. For example, if a user registers their Ledger or Trezor device to an account, but later they decide they want more convenient access, they could grant access to their account, or a subset of its capabilities, to a lower-security but still-physically authenticated device, which does not require a pin. Or they could use an Android-based biometric protected key. Or they could even use a normal password. 

It should be noted that normal password authentication is possible on the Oasis Network’s Sapphire runtime without the need for zero-knowledge proofs. This access is possible due to the fact that Oasis contracts have confidential storage, and contract calls can be encrypted end to end. 

‍The Oasis Solution: Key Management Contracts

Encrypted key management contracts deployed on Sapphire is the Oasis Network’s alternative to passkeys. Account abstraction is poised to fundamentally reshape how Web3 operates, so it’s important to get credential authenticating right. In short, Oasis key management contracts create a per-user encryption seed and provide methods to manage — add or remove — authentication credentials.

During onboarding, a new user will create an onchain profile that specifies one or more authentication credentials, such as their Ethereum address or WebAuthN registration. It’s assumed that their dApp will sponsor the gas costs of onchain registration, and it’s assumed that registration can only be performed with the dApps approval. As an added benefit, gas costs on Sapphire are negligible — only fractions of a cent in USD terms.

After onboarding, the authentication contract can be requested to derive encryption keys using the seed. Contract requests are made in a view call, so there is no need to pay for gas or perform an onchain transaction. For each request, a user will specify their profile, credential, and a name for the key. Then they sign it using their credentials such as a passkey, WebAuthN or an Ethereum address.

During a user’s lifetime in Web3, their key management contract can, if desired, sign the validity of the encryption key for a specific user by generating a keypair either for the whole contract or for each individual user. This flexibility allows users to pass the encryption key with metadata like profile ID or key names to a third-party in a way that certifies it was authorized by the user and can be derived again if needed. For example, this functionality would be useful in an instance where a special multi-signature wallet requests the contract to provide specific encryption keys.

Because the Oasis contract is managing a keypair rather than deploying a smart-contract wallet (SCW) to the target chain, it can be used to create user-controlled wallets on any Ethereum compatible chain without any other dependencies or prerequisites. Because the Sapphire runtime has signing functions for Secp256k1, Secp256r1 and Ed25519, it is even possible to sign cross-chain Bitcoin or Monero transactions should the smart contracts be modified to allow it.

In short, Sapphire key manager contracts are fully cross-chain. 

‍Oasis Account Abstraction Examples

Passkeys may be the beginning of the end for passwords, but encryption key management contracts on Oasis could also be the beginning of the end for Passkeys. Below are a few code examples that use many of the functions described in the previous section of this post.  

Click here to view WebAuthNProvider.tsx

Click here to view WebAuthNExample.sol

These examples can be modified as needed.

‍