This is a two part series. Stay tuned for Part 2.

Over the years, I have been involved in developing agent applications for iOS & Android that run on the user’s device to do many things. From mobile device managment to threat defense agent apps. These applications are complicated. They are resource intensive, hard to maintain & harder to distribute. Some enterprise customers are willing to look past these “inconveniences” as endpoint security is vital for their day-to-day operations. Consumers on the other hand have different sets of expectations. Primarily, ease of use & privacy. Most tech-savvy (normies included;)) individuals don’t like to install an app that “Scans” their device. Trust is expensive and I have paid the price in many ways trying to explain away the problem and trying to convince users of the benefit. It doesn’t always work.

Pwned Report

  1. Is agent app required to do threat detection? Are there simpler ways? The answer was NOT alwasy! I found a novel way that utilizes instant app. Read more here, https://ismyapppwned.com/2022/05/30/pwned_report_introduction/
  2. Is it possible to ditch the agent app altogether?

This article tries to answer question #2. And the short answer is YES.

Multi-device FIDO credentials AKA Passkeys

Before diving into the details, a little introduction about FIDO credentials. FIDO credentials are set of standards and protocols designed by FIDO Alliance to address the “password” problem. Most websites require passwords to access their services. Passwords are susceptible to phishing & breach. Have I been Pwned (https://haveibeenpwned.com/) and similar products were created to track breaches that stem from password theft.

FIDO credentials are essentially cryptographic keys that are generated during an authentication flow. It consists of two parts. One public & one private. As the name suggests, the public key is visible to everyone while the private key is only visible to the user.

These key pairs are managed by the operating system. A user does not need to remember/maintain them. You don’t need “password managers” to keep track of multiple keys for different websites. So, how does the authentication work


Passkey Login Flow
Passkey Login Flow Credit hanko.io

A user is presented with a login screen. Enter email/user-id and press sign-in. The operating system presents biometric login asking the user to authenticate. If successful, the two keypairs we discussed above are generated. The public key will be shared with the website. Typically, this website, on its backend, will associate this public key with the user’s email id; similar to how they associate passwords with the user id. The private key never leaves the user’s devices and is saved securely.

Now, what happens when the user loses his device? Or purchases a new device and wants to log in back? The public/private key pair is stuck on the old device. Is there a way to transfer it to my new device? That’s where multi-device FIDO credentials come in. It outlines the different ways by which these key pairs are transferred/synced onto new devices

  1. Bluetooth - Bring your old & new devices close enough to transfer the credentials using Bluetooth protocol. This has an obvious disadvantage. To sign in on a new device, you will need to carry your old device (If not lost)
  2. Cloud Sync - Synchronize FIDO credentials to a remote server.

Option #2 is what Google & Apple call passkeys. They take care of synchronizing your FIDO credentials to their servers. Google utilizes, Google Password Manager on Chrome while Apple uses iCloud service.

The Tale of two private keys

Cloud Synchronization (transferring FIDO credentials from cloud to a new device) is taken care of by the operating system. Private keys need to be present on a device & ready before login is attempted by the user. Additionally, the service provider (Google/Apple) is responsible for the security of these keys. To partially address this issue, FIDO proposed Device-bound Public Key WebAuthn extension. This extension allows websites to incorporate device security & risk analysis during sign-in. If this extension is requested, two private keys are generated.

  1. Passkey private key
  2. Device-bound private key

On Android, device-bound private keys are generated in the device’s trusted execution environment (TEE), via the Android Keystore API. This provides hardware-backed protections against exfiltration of the device-bound private key to other devices. Device-bound private keys are not backed up, so e.g. when a device is factory reset and restored from a prior backup, its device-bound key pairs will be different.

If device-bound-private key is new or unseen anywhere else, we can deduce a device is fresh and signing from a new location/device/. Secondly, more importantly, we can attest this key to make sure the device is secure. No visible compromise is detected.

This device-bound private key is unique to the passkey and each response includes a copy of the corresponding device-bound public key.

Client

We will be using the credential management API to create credentials discussed in the above section, https://developer.mozilla.org/en-US/docs/Web/API/CredentialsContainer/create

Here are few important parameters

attestation - “direct” indicates the RP wants to receive the attestation statement. This means the website that requested this will need to receive attestation statement.

extension - devicePubKey - This extension is responsible for instructing the client to generate device bound key. 

var createCredentialDefaultArgs = {
    publicKey: {
        rp: {
            name: "Pwned Report"
        },
        extensions: {
            devicePubKey: true,
        },
        user: {
            id: new Uint8Array(16),
            name: window.navigator.userAgent,
            displayName: window.navigator.platform
        },
        pubKeyCredParams: [{
            type: "public-key",
            alg: -7 //ES256 elliptic curve
        }],
        attestation: "direct",
        timeout: 90000,
        challenge: nonce
    }

};

The create method will return credentials object that contain the following,

  1. Credential type
  2. Attestation statement
  3. Client Data

Next, we will send these values to the server for validation. The process of validating #1, #2 & #3 is called attestation verification and it’s done on the server.

Server

The verification process is where we decide if the device is compromised or not. I will prepare a separate blog post to discuss the details.

Demo

Try it out

Supported Platform

  • Android Chrome 99+
  • iOS - Unfortunately, Device-bound Public Key WebAuthn extension is not yet implemented by Apple.

Visit, https://pwned.report/scan2