What is a device key?

A device key is a key pair that belongs to one device rather than to a person or an account. Each phone, laptop or sensor generates its own pair, keeps the private half and shares the public half. A person with several devices has several device keys.

The Messaging Layer Security standard, MLS (RFC 9420), is built around this idea. It defines a client as an agent that takes part in the protocol and says a client is defined by the cryptographic keys it holds. It also notes that if a user has several devices in a group, each device’s client could present the same user-level identifier. The protocol tracks devices; the application decides which devices belong to which person.

Keeping keys per device means a private key never has to be copied between devices, and removing one device means removing one key rather than replacing a key that every other device shares.

A device usually needs keys for two different jobs:

• Signing. The device signs what it sends, for example with Ed25519, so others can check it came from that device and was not changed. In MLS, each message carries a signature from the sender’s signature key.
• Key agreement and decryption. Others use the device’s public key to set up encryption to it. An MLS key package, for example, carries a public key that other clients use to encrypt to that client.

NIST’s key management guidance says that, in general, a single key shall be used for only one purpose, because using one key for two processes may weaken both and because limiting a key’s use limits the damage if it is compromised. So what people call a device key may in practice be a small set of keys, for example a long-lived identity key for signing plus separate keys for key agreement. Some systems also derive the device’s address from its public key, which makes it a self-certifying identifier.

Phones offer storage designed to keep private keys from leaving the device.

Android Keystore. Android’s documentation says key material in the Keystore remains non-exportable and never enters the app’s process; the app sends data to a system process that performs the operation. Keys can be bound to secure hardware, such as a Trusted Execution Environment or a Secure Element, in which case the key material is never exposed outside that hardware. Apps can also restrict a key to certain algorithms and purposes, a validity period, or recent user authentication.

Apple keychain and Secure Enclave. Apple describes the keychain as encrypting key data on disk and making it available only to your app or apps you authorise, but notes that using a keychain key means briefly copying a plain-text version into memory. The Secure Enclave goes further: the app never handles the plain-text key and receives only the results of operations.

The strongest options have limits. Apple says the Secure Enclave works only with NIST P-256 elliptic curve keys and cannot take in keys created elsewhere. Android’s StrongBox supports a listed subset of algorithms whose elliptic curve entries are ECDSA and ECDH on P-256. An app that uses Ed25519 or X25519 device keys therefore cannot create them inside the Secure Enclave or StrongBox, and keeps them in other protected storage, such as the keychain.

A valid signature from a device key shows that the signer held that private key. It does not show who was holding the phone, or what they are allowed to do. Those need separate steps:

• Enrolment. To link a device to an existing account, a server can issue a fresh random challenge, have the device sign it, verify the signature and store the binding.
• Authorisation. The application decides what an enrolled device may do. Proving possession of a key grants no permissions by itself.
• User presence. Where it matters, the key can be configured so that it works only after the user authenticates, which both Android Keystore and the Secure Enclave support.

MLS’s security considerations show why enrolment deserves care. A compromised authentication service could add a key under a user’s name as if it were a new device for that user, and the RFC suggests schemes in which a user’s devices vouch for each other by signing each other’s keys.

A device key is meant to persist across app restarts, and it can outlive the app itself. Offline Protocol’s security documentation notes that on iOS, keychain identity state survives an app uninstall unless it is explicitly wiped, so reinstalling is not an identity reset. Account deletion should remove the key on purpose.

When a device is lost, its key should be removed from every group and account it belongs to, and keys it shared with others should be replaced. Key rotation covers the replacement side, and what happens when a phone holding keys is lost covers the response as a whole.