XMSS Library
•All Classes Files Functions Variables Typedefs Enumerations Enumerator Macros Pages
Public key authentication

Table of Contents

The public key needs to be authenticated before it can be trusted to verify signatures.

As a common scenario, we consider a manufacturer creating products that require firmware updates at the site of the customer after production. Usually, the public key is 'authenticated' by storing it, preferably irreversibly, in the product at manufacturing time; for example:

PRODUCTxmss_public_key_tpinned_public_keyStored at factoryMESSAGExmss_signature_tsignatureCreated at factorybytespayloadData to be authenticatedverifies

Depending on the backup strategy, one could pin multiple public keys; for example:

PRODUCTxmss_public_key_tpinned_public_key_1Stored at factoryxmss_public_key_tpinned_public_key_2Stored at factoryMESSAGEintpublic_key_indexDetermined at factoryxmss_signature_tsignatureCreated at factorybytespayloadData to be authenticatedverifies

Alternatively, one could construct some kind of Public Key Infrastructure (PKI). In that case the product pins the public root key and the message is accompanied by a signed (chain of) public sub-key(s); for example:

PRODUCTxmss_public_key_tpinned_public_root_keyStored at factoryMESSAGExmss_signature_tkey_signatureSigned by root key, authenticates sub-keyxmss_public_key_tpublic_sub_keyCreated at factoryxmss_signature_tpayload_signatureSigned by sub-key, authenticates payloadbytespayloadData to be authenticatedverifies

The API allows managing multiple keys in a single instance of the library.

Root of trust

At least one public key must serve as a root of trust by embedding it in the product. This could be achieved by making it part of the ROM image of the product or by loading it into the product within a secure environment.

Multiple roots of trust

In the examples above, a single (root) key authenticates all messages for all products. Alternatively, one could use different keys for different (groups of) products; for example, a unique key per customer or even a unique key per unit.

Public key confidentiality

When using multiple roots of trust, an attacker that acquires two product units could determine from the public key embedded in the units whether or not these two units are pinned to the same public key. For example, when using a unique key per customer, an attacker could determine if the two units are from the same customer.

It is possible to mitigate this threat; see Public key obfuscation.

Note that in general, the public key does not need to be protected for confidentiality, only for integrity and for availability. Only in some special high assurance cases is public key obfuscation a requirement.