Device identity: private keys and what a TPM protects

A device name or serial number can be copied. To distinguish a registered device from someone using its name, a service needs proof that the sender holds a secret key. A TPM can help protect and use that key. It does not, by itself, prove that the device software is healthy or that every requested action is allowed.

Imagine an irrigation controller: a device that opens and closes a water valve. It sends reports to a server, a computer that receives device messages and provides services such as storing reports or sending settings. If someone puts the controller's name on another computer, the server needs a way to tell the two apart.

An identifier names a device; authentication asks for evidence

An identifier such as irrigation-07 helps the server find the device record. Like a name on an envelope, it is useful but is not proof of ownership. In our example, a trusted setup process associates a public key with that record. This initial registration matters: accepting a replacement key from any sender would defeat the later identity check.

A cryptographic key is data used by a mathematical method to sign or check messages. A digital signature scheme uses two related keys. The device keeps its private key secret and gives its public key to the verifier. It signs with the private key; the server checks the signature with the public key. A digital signature is not a picture of handwriting, and it does not hide the message.

Why not reuse a signed response?

If a device always signs the same sentence, someone who records one valid response could try sending it again. This is a replay. The server instead issues a fresh, unpredictable challenge. Its random value is often called a nonce; in this use, an accepted challenge must not be accepted again.

Our hypothetical challenge includes the device name, the intended service, a nonce and an expiry time. The device signs these fields together. The server checks the signature and confirms that the response matches the challenge it issued, has not expired and has not already been consumed. These are separate checks. A valid signature alone does not prevent replay.

A worked irrigation example

Give each challenge a hypothetical 10-second lifetime. This is a teaching choice, not a universal product setting; a suitable lifetime depends on the network and system design. Issue challenge A at second zero:

The offline exercise uses a 16-byte random nonce. A byte contains eight bits, and each bit can be zero or one. That gives 128 bits and 2^128 ≈ 3.4 × 10^38 possible values. If they are equally likely, one exact guess has probability 1/2^128. This calculation describes guessing that value, not the probability of compromising the entire system or the strength of the signature. Secure random generation, tracking issued challenges and enforcing one-time use still matter.

Where a TPM helps

TPM stands for Trusted Platform Module. It provides security functions that include protecting keys. With a suitable implementation and key configuration, private key operations can take place inside a protected environment without exporting the private key. Non-exportability is not a property to assume for every key; the key type, settings and implementation matter.

A TPM can be a separate component or implemented within a protected part of the system. A firmware TPM, or fTPM, implements the function through device-level software in such an environment. For example, Variscite documents SEC-TPM using OP-TEE, an environment that separates certain sensitive operations from ordinary software. That guide says the documented configuration makes SEC-TPM available after the Linux kernel has booted. It should not be assumed to replace every earlier boot-security mechanism.

Keeping a private key in a protected environment can prevent a copy of ordinary device files from becoming a copy of the key. Malicious software may still try to misuse operations it is allowed to request. Access controls, updates, revoking a lost device and protecting the server remain necessary.

Four different questions

• Authentication: Does the responder hold the key associated with this registered device?
• Authorization: What may this identified device do? A controller on one farm must not change another farm's settings.
• Communication confidentiality: Can someone else read the messages? An encrypted connection with proper peer verification addresses a different concern from this signing example.
• Attestation: Is there verifiable evidence about the device's boot or execution environment? This requires measurements, a chain of trust and a verification policy. Signing a nonce alone is not such a report.

An optional offline exercise

The Python exercise demonstrates a valid response, the wrong key and replay rejection. It assumes you can run Python and install cryptography. It generates temporary keys in one process and checks six cases. It does not connect to a network or TPM, or save a key. It uses Ed25519 signatures; that choice does not imply that every TPM supports Ed25519.

python -m pip install cryptography==50.0.2
python identity_exercise.py

Expect six PASS lines: valid response, wrong key, changed content, replay, expiry and unknown identity. This software exercise is neither a production authentication protocol nor a TPM security test. A product needs a reviewed protocol and implementation; concurrency, secure transport and key lifecycle management are outside this teaching file.

Continue with BLE security for the distinction between authentication and ownership in nearby-device connections. The embedded systems learning path places software and testing within a complete device.

Sources

• Microsoft: TPM fundamentals and key protection
• Microsoft: TPM attestation concepts
• Variscite: versioned SEC-TPM guide
• cryptography 50.0.2: Ed25519 signing
• Python: random data for security uses