Keys & sessions.

Understand what stays in the secure element, what lives on the host, and what unlocking the device changes.

Where things live

Location	Responsibility
Host application	PIN entry, plaintext, application logic, files, and the user interface.
ESP32-C3	Command parsing, token/session coordination, and key metadata in NVS.
NXP SE051	Customer private and symmetric key material, key policies, and cryptographic operations.

The encrypted connection established after unlock is between the ESP and the SE051. It does not make the USB PIN exchange encrypted. The ESP-side authentication secret is also separate from customer key material held in the secure element.

Authentication opens a session

A PIN unlock opens an authenticated device session that supports multiple operations. You do not enter a PIN for every request. The session belongs to the token, not to a single host handle.

Closing a program or releasing its USB handle does not explicitly lock the stick. Call the lock operation when your workflow is finished. Firmware inactivity locking also closes the session.

Status is only a snapshot. A session may close between a status check and the next operation; handle the structured authentication-required error in your application.

A key has a type and a usage

Key types are AES, HMAC, RSA, and EC. Usage is ENCRYPT, SIGN, or DERIVE. The combination determines which operations the firmware permits; the secure element enforces access policies.

For example, an EC SIGN key is for ECDSA, while an EC DERIVE key is used for ECDH. See the mechanism table for compatible choices.

Metadata describes a key

Metadata includes an object ID, label, type, size, usage, and host-supplied creation timestamp. It lives in ESP NVS, separate from the secure-element object.

Labels need not be unique.
Object IDs can be reused after deletion.
Creation timestamps are supplied by the host, not an authenticated device clock.
An ID filter takes precedence; other list filters combine with AND.

Do not treat a label or a deleted-and-reused ID as a permanent identity for a cryptographic key. Export the public key when your application needs to identify an asymmetric key.

Public export and recovery

RSA and EC public keys can be exported as DER SubjectPublicKeyInfo. The protocol does not offer general private-key or symmetric-key export, import, wrapping, or backup.

A copy of a Keyring database or a Seal file preserves encrypted data, not the key on the stick. Recreating a label does not recreate the original key.

Ambiguous outcomes

A timeout or disconnect does not prove an operation failed. A key may have been created or deleted before the host lost the response. Inspect state and restore a usable connection before deciding what to do next; do not automatically replay state-changing commands.

The protocol has no request IDs. Keep one request/response transaction in flight per device.