Public key authentication

Table of Contents

• Root of trust
• Multiple roots of trust
• Public key confidentiality

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:

erDiagram
    PRODUCT }o--o{ MESSAGE : verifies
    PRODUCT {
        xmss_public_key_t pinned_public_key "Stored at factory"
    }
    MESSAGE {
        xmss_signature_t signature "Created at factory"
        bytes payload "Data to be authenticated"
    }

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

erDiagram
    PRODUCT }o--o{ MESSAGE : verifies
    PRODUCT {
        xmss_public_key_t pinned_public_key_1 "Stored at factory"
        xmss_public_key_t pinned_public_key_2 "Stored at factory"
    }
    MESSAGE {
        int public_key_index "Determined at factory"
        xmss_signature_t signature "Created at factory"
        bytes payload "Data to be authenticated"
    }

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:

erDiagram
    PRODUCT }o--o{ MESSAGE : verifies
    PRODUCT {
        xmss_public_key_t pinned_public_root_key "Stored at factory"
    }
    MESSAGE {
        xmss_signature_t key_signature "Signed by root key, authenticates sub-key"
        xmss_public_key_t public_sub_key "Created at factory"
        xmss_signature_t payload_signature "Signed by sub-key, authenticates payload"
        bytes payload "Data to be authenticated"
    }

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.