A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors
Sandelman Software Works
mcr+ietf@sandelman.ca
T2TRG Research Group
Internet-Draft
This document provides a taxonomy of methods used by manufacturers of silicon and devices
to secure private keys and public trust anchors.
This deals with two related activities: how trust anchors and private keys
are installed into devices during manufacturing, and how the related
manufacturer held private keys are secured against disclosure.
This document does not evaluate the different mechanisms, but rather just
serves to name them in a consistent manner in order to aid in communication.
RFCEDITOR: please remove this paragraph. This work is occurring in https://github.com/mcr/idevid-security-considerations
Introduction
An increasing number of protocols derive a significant part of their security by using trust anchors that are installed by manufacturers.
Disclosure of the list of trust anchors does not usually cause a problem, but changing them in any way does.
This includes adding, replacing or deleting anchors.
Many protocols also leverage manufacturer installed identities.
These identities are usually in the form of Initial Device Identity certificates (IDevID).
The identity has two components: a private key that must remain under the strict control of a trusted part of the device, and a public part (the certificate), which (ignoring, for the moment, personal privacy concerns) may be freely disclosed.
There also situations where identities are tied up in the provision of symmetric shared secret.
A common example is the SIM card (), it now comes as a virtual SIM, but which is usually not provisioned at the factory.
The provision of an initial, per-device default password also falls into the category of symmetric shared secret.
It is further not unusual for many devices (particularly smartphones) to also have one or more group identity keys.
This is used in, for instance, in to make claims about being a particular model of phone (see ).
The key pair that does this is loaded into large batches of phones for privacy reasons.
The trust anchors are used for a variety of purposes.
Trust anchors are used to verify:
- the signature on a software update (as per ).
- a TLS Server Certificate, such as when setting up an HTTPS connection.
- the format voucher that provides proof of an ownership change
Device identity keys are used when performing enrollment requests (in , and in some uses of .
The device identity certificate is also used to sign Evidence by an Attesting Environment (see ).
These security artifacts are used to anchor other chains of information: an EAT Claim as to the version of software/firmware running on a device (), an EAT claim about legitimate network activity (via , or embedded in the IDevID in ).
Known software versions lead directly to vendor/distributor signed Software Bill of Materials (SBOM), such as those described by and the NTIA/SBOM work and CISQ/OMG SBOM work underway .
In order to manage risks and assess vulnerabilities in a Supply Chain, it is necessary to determine a degree of trustworthiness in each device.
A device may mislead audit systems as to its provenance, about its software load or even about what kind of device it is (see for a humorous example).
In order to properly assess the security of a Supply Chain it is necessary to understand the kinds and severity of the threats which a device has been designed to resist.
To do this, it is necessary to understand the ways in which the different trust anchors and identities are initially provisioned, are protected, and are updated.
To do this, this document details the different trust anchors (TrA) and identities (IDs) found in typical devices.
The privacy and integrity of the TAs and IDs is often provided by a different, superior artifact.
This relationship is examined.
While many might desire to assign numerical values to different mitigation techniques in order to be able to rank them, this document does not attempt to do that, as there are too many other (mostly human) factors that would come into play.
Such an effort is more properly in the purview of a formal ISO9001 process such as ISO14001.
Terminology
This document is not a standards track document, and it does not make use of formal requirements language.
This section will be expanded to include needed terminology as required.
The words Trust Anchor are contracted to TrAnc rather than TA, in order not to confuse with 's "Trusted Application".
This document defines a number of hyphenated terms, and they are summarized here:
- device-generated:
-
a private or symmetric key which is generated on the device
- infrastructure-generated:
-
a private or symmetric key which is generated by some system, likely
located at the factory that built the device
- mechanically-installed:
-
when a key or certificate is programmed into non-volatile storage by out-of-band mechanism like JTAG
- mechanically-transferred:
-
when a key or certificate is transferred into a system via private interface, such as serial console, JTAG managed mailbox, or other physically private interface
- network-transfered:
-
when a key or certificate is transfered into a system using a network interface which would be available after the device has shipped. This applies even if the network is physically attached using a bed-of-nails.
- device/infrastructure-co-generated:
-
when a private or symmetric key is derived from a secret previously synchronized between the silicon vendor and the factory using a common algorithm.
Applicability Model
There is a wide variety of devices to which this analysis can apply. (See )
This document will use a J-group as a sample.
This class is sufficiently large to experience complex issues among multiple CPUs, packages and operating systems, but at the same time, small enough that this class is often deployed in single-purpose IoT-like uses.
Devices in this class often have Secure Enclaves (such as the "Grapeboard"), and can include silicon manufacturer controlled processors in the boot process (the Raspberry PI boots under control of the GPU).
Almost all larger systems (servers, laptops, desktops) include a Baseboard Management Controller (BMC), which ranges from a M-Group Class 3 MCU, to a J-Group Class 10 CPU (see, for instance which uses a Linux kernel and system inside the BMC).
As the BMC usually has complete access to the main CPU's memory, I/O hardware and disk, the boot path security of such a system needs to be understood first as being about the security of the BMC.
A reference manufacturing/boot process
In order to provide for immutability and privacy of the critical TrAnc and IDs, many CPU manufacturers will provide for some kind of private memory area which is only accessible when the CPU is in certain privileged states.
See the Terminology section of , notably TEE, REE, and TAM, and also section 4, Architecture.
The private memory that is important is usually non-volatile and rather small.
It may be located inside the CPU silicon die, or it may be located externally.
If the memory is external, then it is usually encrypted by a hardware mechanism on the CPU, with only the key kept inside the CPU.
The entire mechanism may be external to the CPU in the form of a hardware-TPM module, or it may be entirely internal to the CPU in the form of a firmware-TPM.
It may use a custom interface to the rest of the system, or it may implement the TPM 1.2 or TPM 2.0 specifications.
Those details are important to performing a full evaluation, but do not matter much to this model (see initial-enclave-location below).
During the manufacturing process, once the components have been soldered to the board, the system is usually put through a system-level test.
This is often done on as a "bed-of-nails" test , where the board has key points attached mechanically to a test system.
A process tests the System Under Test, and then initializes some firmware into the still empty flash storage.
It is now common for a factory test image to be loaded first: this image will include code to initialize the private memory key described above, and will include a first-stage bootloader and some kind of (primitive) Trusted Application Manager (TAM).
(The TAM is a piece of software that lives within the trusted execution environment)
Embedded in the stage one bootloader will be a Trust Anchor that is able to verify the second-stage bootloader image.
After the system has undergone testing, the factory test image is erased, leaving the first-stage bootloader.
One or more second-stage bootloader images are installed.
The production image may be installed at that time, or if the second-stage bootloader is able to install it over the network, it may be done that way instead.
There are many variations of the above process, and this section is not attempting to be prescriptive, but to be provide enough illustration to motivate subsequent terminology.
There process may be entirely automated, or it may be entirely driven by humans working in the factory.
Or a combination of the above.
These steps may all occur on an access-controlled assembly line, or the system boards may be shipped from one place to another (maybe another country) before undergoing testing.
Some systems are intended to be shipped in a tamper-proof state, but it is usually not desirable that bed-of-nails testing be possible without tampering, so the initialization process is usually done prior to rendering the system tamper-proof.
An example of a one-way tamper-proof, weather resistant treatment might to mount the system board in a plastic case and fill the case with resin.
Quality control testing may be done prior to as well as after the application of tamper-proofing, as systems which do not pass inspection may be reworked to fix flaws, and this should ideally be impossible once the system has been made tamper-proof.
Types of Trust Anchors
Trust Anchors (TrAnc) are fundamentally public keys with authorizations implicitely attached through the code that references them.
They are used to validate other digitally signed artifacts.
Typically, these are chains of PKIX certificates leading to an End-Entity certificate (EE).
The chains are usually presented as part of an externally provided object, with the term "externally" to be understood as being as close as untrusted flash, to as far as objects retrieved over a network.
There is no requirement that there be any chain at all: the trust anchor can be used to validate a signature over a target object directly.
The trust anchors are often stored in the form of self-signed certificates.
The self-signature does not offer any cryptographic assurance, but it does provide a form of error detection, providing verification against non-malicious forms of data corruption.
If storage is at a premium (such as inside-CPU non-volatile storage) then only the public key itself need to be stored.
For a 256-bit ECDSA key, this is 32 bytes of space.
When evaluating the degree of trust for each trust anchor there are four aspects that need to be determined:
- can the trust anchor be replaced or modified?
- can additional trust anchors be added?
- can trust anchors be removed?
- how is the private key associated with the trust anchor, maintained by the manufacturer, maintained?
The first three things are device specific properties of how the integrity of the trust anchor is maintained.
The fourth property has nothing to do with the device, but has to do with the reputation and care of the entity that maintains the private key.
Different anchors have different authorizations associated with them.
These are:
Secured First Boot Trust Anchor
This anchor is part of the first-stage boot loader, and it is used to validate a second-stage bootloader which may be stored in external flash.
This is called the initial software trust anchor.
Software Update Trust Anchor
This anchor is used to validate the main application (or operating system) load for the device.
It can be stored in a number of places.
First, it may be identical to the Secure Boot Trust Anchor.
Second, it may be stored in the second-stage bootloader, and therefore its integrity is protected by the Secured First Boot Trust Anchor.
Third, it may be stored in the application code itself, where the application validates updates to the application directly (update in place), or via a double-buffer arrangement.
The initial (factory) load of the application code initializes the trust arrangement.
In this situation the application code is not in a secured boot situation, as the second-stage bootloader does not validate the application/operating system before starting it, but it may still provide measured boot mechanism.
Trusted Application Manager anchor
This anchor the secure key for the Trusted Application Manager (TAM).
Code which is signed by this anchor will be given execution privileges as described by the manifest which accompanies the code.
This privilege may include updating anchors.
Public WebPKI anchors
These anchors are used to verify HTTPS certificates from web sites.
These anchors are typically distributed as part of desktop browsers, and via desktop operating systems.
The exact set of these anchors is not precisely defined: it is usually determined by the browser vendor (e.g., Mozilla, Google, Apple, Safari, Microsoft), or the operating system vendor (e.g., Apple, Google, Microsoft, Ubuntu).
In most cases these vendors look to the CA/Browser Forum () for inclusion criteria.
DNSSEC root
This anchor is part of the DNS Security extensions.
It provides an anchor for securing DNS lookups.
Secure DNS lookups may be important in order to get access to software updates.
This anchor is now scheduled to change approximately every 3 years, with the new key announced several years before it is used, making it possible to embed a keys that
will be valid for up to five years.
This trust anchor is typically part of the application/operating system code and is usually updated by the manufacturer when they do updates.
However, a system which is connected to the Internet may update the DNSSEC anchor itself through the mechanism described in .
There are concerns that there may be a chicken and egg situation for devices that have remained in a powered off state (or disconnected from the Internet) for some period of years.
That upon being reconnected, that the device would be unable to do DNSSEC validation.
This failure would result in them being unable to obtain operating system updates that would then include the updates to the DNSSEC key.
Types of Identities
Identities are installed during manufacturing time for a variety of purposes.
Identities require some private component.
Asymmetric identities (e.g., RSA, ECDSA, EdDSA systems) require a corresponding public component, usually in the form of a certificate signed by a trusted third party.
This certificate associates the identity with attributes.
The process of making this coordinated key pair and then installing it into the device is called identity provisioning.
Manufacturer installed IDevID certificates
defines a category of certificates that are installed by the manufacturer, which contain at the least, a device unique serial number.
A number of protocols depend upon this certificate.
-
and introduce mechanisms for new devices (called pledges) to be onboarded into a network without intervention from an expert operator. A number of derived protocols such as , , , extend this in a number of ways.
-
depends upon a key provisioned into the Attesting Environment to sign Evidence.
-
may depend upon a key provisioned into the
device in order to decrypt software updates.
Both symmetric and asymmetric keys are possible.
In both cases, the decrypt operation depends upon the device having access to
a private key provisioned in advance.
The IDevID can be used for this if algorithm choices permit.
ECDSA keys do not directly support encryption in the same way that RSA does, for
instance, but the addition of ECIES can solve this.
There may be other legal considerations why the IDevID might not be used, and
a second key provisioned.
- TBD
Operational Considerations for Manufacturer IDevID Public Key Infrastructure
The manufacturer has the responsibility to provision a key pair into each
device as part of the manufacturing process.
There are a variety of mechanisms to accomplish this, which this document will overview.
There are three fundamental ways to generate IDevID certificates for devices:
- generating a private key on the device, creating a Certificate Signing
Request (or equivalent), and then returning a certificate to the device.
- generating a private key outside the device, signing the certificate, and
the installing both into the device.
- deriving the private key from a previously installed secret seed, that is shared with only the manufacturer.
There is a fourth situation where the IDevID is provided as part of a Trusted
Platform Module (TPM), in which case the TPM vendor may be making the same
tradeoffs.
The document provides some practical instructions
on setting up a reference implementation for ECDSA keys using a three-tier
mechanism.
Key Generation process
On-device private key generation
Generating the key on-device has the advantage that the private key never leaves the device.
The disadvantage is that the device may not have a verified random number generator.
is an example of this scenario.
There are a number of options of how to get the public key securely from the
device to the certification authority.
This transmission must be done in an integral manner, and must be securely associated with the assigned serial number.
The serial number goes into the certificate, and the resulting certificate needs to be loaded into the manufacturer's asset database.
One way to do the transmission is during a factory Bed of Nails test (see ) or Boundary Scan.
When done via a physical connection like this, then this is referred to as a
device-generated / mechanically-transferred .
There are other ways that could be used where a certificate signing request is sent over a special network channel when the device is powered up in the factory.
This is referrered to as the device-generated / network-transferred method.
Regardless of how the certificate signing request is sent from the device to the factory, and how the certificate is returned to the device, a concern from production line managers is that the assembly line may have to wait for the certification authority to respond with the certificate.
After the key generation, the device needs to set a flag such that it no longer generates a new key, or will accept a new IDevID via the factory connection.
This may be a software setting, or could be as dramatic as blowing a fuse.
The risk is that if an attacker with physical access is able to put the device back into an unconfigured mode, then the attacker may be able to substitute a new certificate into the device.
It is difficult to construct a rationale for doing this, unless the network initialization also permits an attacker to load or replace trust anchors at the same time.
Devices are typically constructed in a fashion such that the device is unable to ever disclose the private key via an external interface.
This is usually done using a secure-enclave provided by the CPU architecture in combination with on-chip non-volatile memory.
Off-device private key generation
Generating the key off-device has the advantage that the randomness of the private key can be better analyzed.
As the private key is available to the manufacturing infrastructure, the authenticity of the public key is well known ahead of time.
If the device does not come with a serial number in silicon, then one should be assigned and placed into a certificate.
The private key and certificate could be programmed into the device along with the initial bootloader firmware in a single step.
Aside from the change of origin for the randomness, a major advantage of this mechanism is that it can be done with a single write to the flash.
The entire firmware of the device, including configuration of trust anchors and private keys can be loaded in a single write pass.
Given some pipelining of the generation of the keys and the creation of certificates, it may be possible to install unique identities without taking any additional time.
The major downside to generating the private key off-device is that it could be seen by the manufacturing infrastructure.
It could be compromised by humans in the factory, or the equipment could be compromised.
The use of this method increases the value of attacking the manufacturing infrastructure.
If keys are generated by the manufacturing plant, and are immediately installed, but never stored, then the window in which an attacker can gain access to the private key is immensely reduced.
As in the previous case, the transfer may be done via physical interfaces such as bed-of-nails, giving the infrastructure-generated / mechanically-transferred method.
There is also the possibility of having a infrastructure-generated / network-transferred
key.
There is a support for "server-generated" keys in , , and .
All methods strongly recommend encrypting the private key for transfer.
This is difficult to comply with as there is not yet any private key material in the device, so in many cases it will not be possible to encrypt the private key.
Key setup based on 256 bit secret seed
A hybrid of the previous two methods leverages a symmetric key that is often provided by a silicon vendor to OEM manufacturers.
Each CPU (or a Trusted Execution Environment , or a TPM) is provisioned at fabrication time with a unique, secret seed, usually at least 256 bits in size.
This value is revealed to the OEM board manufacturer only via a secure channel.
Upon first boot, the system (probably within a TEE, or within a TPM) will generate a key pair using the seed to initialize a Pseudo-Random-Number-Generator (PRNG).
The OEM, in a separate system, will initialize the same PRNG and generate the same key pair.
The OEM then derives the public key part, signs it and turns it into a certificate.
The private part is then destroyed, ideally never stored or seen by anyone.
The certificate (being public information) is placed into a database, in some cases it is loaded by the device as its IDevID certificate, in other cases, it is retrieved during the onboarding process based upon a unique serial number asserted by the device.
This method appears to have all of the downsides of the previous two methods: the device must correctly derive its own private key, and the OEM has access to the private key, making it also vulnerable.
The secret seed must be created in a secure way and it must also be communicated securely.
There are some advantages to the OEM however: the major one is that the problem of securely communicating with the device is outsourced to the silicon vendor.
The private keys and certificates may be calculated by the OEM asynchronously to the manufacturing process, either done in batches in advance of actual manufacturing, or on demand when an IDevID is demanded.
Doing the processing in this way permits the key derivation system to be completely disconnected from any network, and requires placing very little trust in the system assembly factory.
Operational security such as often incorrectly presented fictionalized stories of a "mainframe" system to which only physical access is permitted begins to become realistic.
That trust has been replaced with a heightened trust placed in the silicon (integrated circuit) fabrication facility.
The downsides of this method to the OEM are: they must be supplied by a trusted silicon fabrication system, which must communicate the set of secrets seeds to the OEM in batches, and they OEM must store and care for these keys very carefully.
There are some operational advantages to keeping the secret seeds around in some form, as the same secret seed could be used for other things.
There are some significant downsides to keeping that secret seed around.
Public Key Infrastructures (PKI)
describes the format for certificates, and numerous mechanisms
for doing enrollment have been defined (including: EST , CMP ,
SCEP ).
provides mechanisms to deal with multi-level certification
authorities, but it is not always clear what operating rules apply.
The certification authority (CA) that is central to -style public key infrastructures can suffer two kinds of failures:
- disclosure of a private key.
- loss of a private key.
- inappropriate signing of a certificate from an unauthorized source
A PKI which discloses one or more private certification authority keys is no
longer secure.
An attacker can create new identities, and forge certificates connecting
existing identities to attacker controlled public/private keypairs.
This can permit the attacker to impersonate any specific device.
There is an additional kind of failure is when the CA is convinced to sign (or issue) a certificate which it is not authorized to do so.
See for instance .
This is an authorization failure, and while a significant event, it does not result in the CA having to be re-initialized from scratch.
This is disintinguished from a loss as described above renders the CA completely useless and likely requires a recall of all products that have ever had IDevID issued from this CA.
If the PKI uses Certificate Revocation Lists (CRL)s, then an attacker that has access to the private key can also revoke existing identities.
In the other direction, a PKI which loses access to a private key can no
longer function.
This does not immediately result in a failure, as existing identities remain valid until their expiry time (notAfter).
However, if CRLs or OCSP are in use, then the inability to sign a fresh CRL or OCSP response will result in all identities becoming invalid once the existing CRLs or OCSP statements expire.
This section details some nomenclature about the structure of certification
authorities.
Number of levels of certification authorities
, section 6.1 provides a Basic Path Validation.
In the formula, the certificates are arranged into a list.
The certification authority (CA) starts with a Trust Anchor (TA).
This is counted as the first level of the authority.
In the degenerate case of a self-signed certificate, then this a one level PKI.
.----------.<-.
|Issuer= X | |
|Subject=X |--'
'----------'
The private key associated with the Trust Anchor signs one or more certificates.
When this first level authority trusts only End-Entity (EE) certificates,
then this is a two level PKI.
.----------.<-.
|Issuer= X | | root
|Subject=X |--' CA
'----------'
| \-------\
v |
.----EE----. .----EE----.
|Issuer= X | |Issuer= X |
|Subject=Y1| |Subject=Y2|
'----------' '----------'
When this first level authority signs suborbinate certification authorities,
and those certification authorities sign End-Entity certificates, then
this is a three level PKI.
.----------.<-.
root |Issuer= X | |
CA |Subject=X |--'
'----------'
.-----------' '------------.
v v
.----------. .----------.
|Issuer= X | subordinate |Issuer= X |
|Subject=Y1| CA |Subject=Y2|
'----------' '----------'
.--' '-------. .---' '------.
v v v v
.----EE----. .----EE----. .----EE----. .----EE----.
|Issuer= Y1| |Issuer= Y1| |Issuer= Y2| |Issuer= Y2|
|Subject=Z1| |Subject=Z1| |Subject=Z3| |Subject=Z4|
'----------' '----------' '----------' '----------'
In general, when arranged as a tree, with the End-Entity certificates at the
bottom, and the Trust Anchor at the top, then the level is where the deepest EE
certificates are, counting from one.
It is quite common to have a three level PKI, where the root of the CA is
stored in a Hardware Security Module, while the level one suborbinate CA is
available in an online form.
Protection of CA private keys
The private key for the certification authorities must be protected from
disclosure.
The strongest protection is afforded by keeping them in a offline device,
passing Certificate Signing Requests (CSR)s to the offline device by human
process.
For examples of extreme measures, see .
There is however a wide spectrum of needs, as exampled in .
The SAS70 audit standard is usually used as a basis for the Ceremony, see .
This is inconvenient, and may involve latencies of days, possibly even weeks
to months if the offline device is kept in a locked environment that requires
multiple keys to be present.
There is therefore a tension between protection and convenience.
This is often accomplished by having some levels of the PKI be offline, and
some levels of the PKI be online.
There is usually a need to maintain backup copies of the critical keys.
It is often appropriate to use secret splitting technology such as Shamir
Secret Sharing among a number of parties
This mechanism can be setup such that some threshold k (less than the total
n) of shares are needed in order to recover the secret.
Supporting provisioned anchors in devices
IDevID-type Identity (or Birth) Certificates which are provisioned into
devices need to be signed by a certification authority maintained by the manufacturer.
During the period of manufacture of new product, the manufacturer needs to be be able to sign new Identity Certificates.
During the anticipated lifespan of the devices the manufacturer needs to maintain the ability for third parties to validate the Identity Certificates.
If there are Certificate Revocation Lists (CRLs) involved, then they will need to resigned during this period.
Even for devices with a short active lifetime, the lifespan of the device could very long if devices are kept in a warehouse for many decades before being activated.
Trust anchors which are provisioned in the devices will have corresponding
private keys maintained by the manufacturer.
The trust anchors will often anchor a PKI which is going to be used for a
particular purpose.
There will be End-Entity (EE) certificates of this PKI which will be used to sign
particular artifacts (such as software updates), or communications protocols
(such as TLS connections).
The private key associated with these EE certificates are not stored in the
device, but are maintained by the manufacturer.
These need even more care than the private keys stored in the devices, as
compromise of the software update key compromises all of the devices, not
just a single device.
Evaluation Questions
This section recaps the set of questions that may need to be answered.
This document does not assign valuation to the answers.
Integrity and Privacy of on-device data
- initial-enclave-location:
-
Is the location of the initial software trust anchor internal to the CPU package?
Some systems have a software verification public key which is built into the CPU package, while other systems store that initial key in a non-volatile device external to the CPU.
- initial-enclave-integrity-key:
-
If the first-stage bootloader is external to the CPU, and it is integrity protected, where is the key used to check the integrity?
- initial-enclave-privacy-key:
-
If the first-stage data is external to the CPU, is it kept confidential by use of encryption?
- first-stage-initialization:
-
The number of people involved in the first stage initialization. An entirely automated system would have a number zero. A factory with three 8 hour shifts might have a number that is a multiple of three. A system with humans involved may be subject to bribery attacks, while a system with no humans may be subject to attacks on the system which are hard to notice.
- first-second-stage-gap:
-
If a board is initialized with a first-stage bootloader in one location
(factory), and then shipped to another location, there may situations where
the device can not be locked down until the second step.
Integrity and Privacy of device identify infrastructure
For IDevID provisioning, which includes a private key and matching
certificate installed into the device, the associated public key
infrastructure that anchors this identity must be maintained by the
manufacturer.
- identity-pki-level:
-
how deep are the IDevID certificates that are issued?
- identity-time-limits-per-subordinate:
-
how long is each subordinate CA maintained before a new
subordinate CA key is generated? There may be no time limit, only a device
count limit.
- identity-number-per-subordinate:
-
how many identities are signed by a particular subordinate CA before it is
retired? There may be no numeric limit, only a time limit.
- identity-anchor-storage:
-
how is the root CA key stored? How many people are needed to recover the private key?
Integrity and Privacy of included trust anchors
For each trust anchor (public key) stored in the device, there will be an
associated PKI.
For each of those PKI the following questions need to be answered.
- pki-level:
-
how deep is the EE that will be evaluated (the trust root is at level 1)
- pki-algorithms:
-
what kind of algorithms and key sizes will be considered to valid
- pki-level-locked:
-
(a Boolean) is the level where the EE cert will be found locked by the device, or can
levels be added or deleted by the PKI operator without code changes to the
device.
- pki-breadth:
-
how many different non-expired EE certificates is the PKI designed to manage?
- pki-lock-policy:
-
can any EE certificate be used with this trust anchor to sign? Or, is there
some kind of policy OID or Subject restriction? Are specific subordinate
CAs needed that lead to the EE?
- pki-anchor-storage:
-
how is the private key associated with this trust root stored? How many people are needed to recover it?
Privacy Considerations
many yet to be detailed
Security Considerations
This entire document is a security considerations.
IANA Considerations
This document makes no IANA requests.
Acknowledgements
Robert Martin of MITRE provided some guidance about citing the SBOM efforts.
References
Normative References
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]
IEEE 802.1AR Secure Device Identifier
IEEE Standard
Informative References
Bootstrapping Remote Secure Key Infrastructures (BRSKI)
Cisco
Sandelman Software Works
Futurewei Technologies Inc. USA
Watsen Networks
This document specifies automated bootstrapping of an Autonomic
Control Plane. To do this a Secure Key Infrastructure is
bootstrapped. This is done using manufacturer-installed X.509
certificates, in combination with a manufacturer's authorizing
service, both online and offline. We call this process the
Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol.
Bootstrapping a new device can occur using a routable address and a
cloud service, or using only link-local connectivity, or on limited/
disconnected networks. Support for deployment models with less
stringent security requirements is included. Bootstrapping is
complete when the cryptographic identity of the new key
infrastructure is successfully deployed to the device. The
established secure connection can be used to deploy a locally issued
certificate to the device as well.
Delegated Authority for Bootstrap Voucher Artifacts
Sandelman Software Works
Huawei Technologies Co., Ltd.
This document describes an extension of the RFC8366 Voucher Artifact
in order to support delegation of signing authority. The initial
voucher pins a public identity, and that public indentity can then
issue additional vouchers. This chain of authorization can support
permission-less resale of devices, as well as guarding against
business failure of the BRSKI [I-D.ietf-anima-bootstrapping-keyinfra]
Manufacturer Authorized Signing Authority (MASA).
BRSKI Cloud Registrar
Cisco
Auth0
Sandelman Software Works
This document specifies the behaviour of a BRSKI Cloud Registrar, and
how a pledge can interact with a BRSKI Cloud Registrar when
bootstrapping.
RFCED REMOVE: It is being actively worked on at https://github.com/
anima-wg/brski-cloud
Constrained Voucher Artifacts for Bootstrapping Protocols
Sandelman Software Works
vanderstok consultancy
Cisco Systems
IoTconsultancy.nl
This document defines a protocol to securely assign a Pledge to an
owner and to enroll it into the owner's network. The protocol uses
an artifact that is signed by the Pledge's manufacturer. This
artifact is known as a "voucher".
This document builds upon the work in [RFC8366] and [BRSKI], but
defines an encoding of the voucher in CBOR rather than JSON, and
enables the Pledge to perform its transactions using CoAP rather than
HTTPS.
The use of Raw Public Keys instead of X.509 certificates for security
operations is also explained.
Support of asynchronous Enrollment in BRSKI (BRSKI-AE)
Siemens AG
Siemens AG
Cisco Systems
Siemens AG
This document describes enhancements of bootstrapping a remote secure
key infrastructure (BRSKI) to also operate in domains featuring no or
only timely limited connectivity between involved components.
Moreover, newly introduced are methods to perform the BRSKI approach
in environments, in which the role of the pledge changes to a server
instead of the client. This changes the interaction model as the
pledge is pushed to interact with the registrar instead of pulling
information from the registrar. To support both, BRSKI-AE relies on
the exchange of it authenticated self-contained objects (signature-
wrapped objects) also for requesting and distributing of domain
specific device certificates. The defined approach is agnostic
regarding the utilized enrollment protocol allowing the application
of existing and potentially new certificate management protocols.
Guide for building an ECC pki
HTT Consulting
Fraunhofer SIT
Huawei
Sandelman Software Works
This memo provides a guide for building a PKI (Public Key
Infrastructure) using openSSL. All certificates in this guide are
ECDSA, P-256, with SHA256 certificates. Along with common End Entity
certificates, this guide provides instructions for creating IEEE
802.1AR iDevID Secure Device certificates.
Internet Security Glossary, Version 2
This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.
Automated Updates of DNS Security (DNSSEC) Trust Anchors
This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s).
This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. [STANDARDS-TRACK]
A Voucher Artifact for Bootstrapping Protocols
This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher".
This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)).
This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it.
Secure Zero Touch Provisioning (SZTP)
This document presents a technique to securely provision a networking device when it is booting in a factory-default state. Variations in the solution enable it to be used on both public and private networks. The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs. The updated device is subsequently able to establish secure connections with other systems. For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems.
Enrollment over Secure Transport
This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.
Simple Certificate Enrolment Protocol
University of Auckland
This document specifies the Simple Certificate Enrolment Protocol (SCEP), a PKI protocol that leverages existing technology by using Cryptographic Message Syntax (CMS, formerly known as PKCS #7) and PKCS #10 over HTTP. SCEP is the evolution of the enrolment protocol sponsored by Cisco Systems, which enjoys wide support in both client and server implementations, as well as being relied upon by numerous other industry standards that work with certificates.
Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)
This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. [STANDARDS-TRACK]
Specification of the Subscriber Identity Module - Mobile Equipment (SIM-ME) interface
3GPP
Bed of nails tester
Wikipedia
Factory provisioning overview
ARM Pelion
Factoring RSA keys from certified smart cards: Coppersmith in the wild
DNSSEC Practice Statement for the Root Zone ZSK Operator
Verisign
Root Key Ceremony, Cryptography Wiki
Community
SAS 70 Key Ceremony
Digi-Sign
How to share a secret.
SP 800-57 Part 1 Rev. 4 Recommendation for Key Management, Part 1: General
NIST
FIDO TechNotes: The Truth about Attestation
FIDO Alliance
NTIA Software Compoment Transparency
NTIA
n.d.
TOOL-TO-TOOL SOFTWARE BILL OF MATERIALS EXCHANGE
CISQ/Object Management Group
Comodo-gate hacker brags about forged certificate exploit
Defining a Standard Baseboard Management Controller Firmware Stack
Linux Foundation/OpenBMC Group
Joint Test Action Group
1149.7-2009 - IEEE Standard for Reduced-Pin and Enhanced-Functionality Test Access Port and Boundary-Scan Architecture
IEEE Standard
Proposal for Future Root Zone KSK Rollovers
ICANN
CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.7.3
CA/Browser Forum
Use cases for Remote Attestation common encodings
Sandelman Software Works
Red Hound Software
Huawei Technologies
This document details mechanisms created for performing Remote
Attestation that have been used in a number of industries. The
document initially focuses on existing industry verticals, mapping
terminology used in those specifications to the more abstract
terminology used by the IETF RATS Working Group.
The document aspires to describe possible future use cases that would
be enabled by common formats.
A Firmware Update Architecture for Internet of Things
Arm Limited
Arm Limited
Linaro
Consultant
Vulnerabilities in Internet of Things (IoT) devices have raised the
need for a reliable and secure firmware update mechanism suitable for
devices with resource constraints. Incorporating such an update
mechanism is a fundamental requirement for fixing vulnerabilities but
it also enables other important capabilities such as updating
configuration settings as well as adding new functionality.
In addition to the definition of terminology and an architecture this
document motivates the standardization of a manifest format as a
transport-agnostic means for describing and protecting firmware
updates.
Nimble out-of-band authentication for EAP (EAP-NOOB)
Aalto University
Ericsson
Aalto University
The Extensible Authentication Protocol (EAP) provides support for
multiple authentication methods. This document defines the EAP-NOOB
authentication method for nimble out-of-band (OOB) authentication and
key derivation. The EAP method is intended for bootstrapping all
kinds of Internet-of-Things (IoT) devices that have no pre-configured
authentication credentials. The method makes use of a user-assisted
one-directional OOB message between the peer device and
authentication server to authenticate the in-band key exchange. The
device must have an input or output interface, such as a display,
microphone, speaker or blinking light, which can send or receive
dynamically generated messages of tens of bytes in length.
Remote Attestation Procedures Architecture
Fraunhofer SIT
Microsoft
Sandelman Software Works
Intel Corporation
Huawei Technologies
In network protocol exchanges it is often the case that one entity
requires believable evidence about the operational state of a remote
peer. Such evidence is typically conveyed as claims about the peer's
software and hardware platform, and is subsequently appraised in
order to assess the peer's trustworthiness. The process of
generating and appraising this kind of evidence is known as remote
attestation. This document describes an architecture for remote
attestation procedures that generate, convey, and appraise evidence
about a peer's operational state.
A SUIT Manifest Extension for Concise Software Identifiers
Fraunhofer SIT
This document defines a resource extension for Concise Software
Identifiers (CoSWID) that represents a SUIT firmware manifest. This
extension combines the information elements of the SUIT information
model with the semantic expressiveness of Software Identifiers. In
consequence, this composite enables the integration of Firmware
Updates for the Internet of Things (SUIT) in existing work-flows for
updates of software components in general.
MUD-Based RATS Resources Discovery
Fraunhofer SIT
Manufacturer Usage Description (MUD) files and the MUD URI that point
to them are defined in RFC 8520. This document introduces a new type
of MUD file to be delivered in conjunction with a MUD file signature
and/or to be referenced via a MUD URI embedded in an IEEE 802.1AR
Secure Device Identifier (DevID). A DevID is a device specific pub-
key identity document that can be presented to other entities, e.g. a
network management system. If this entity is also a verifier as
defined by the IETF Remote ATtestation procedureS (RATS)
architecture, this verifier can use the references found in the MUD
file specified in this document in order to discover appropriate
Reference Integrity Measurements (RIM), Endorsement Documents, or
even globally suitable Remote Attestation Services (RAS). All three
types of theses resources are required to conduct RATS. Hence, the
MUD file defined in this document enables remote attestation
procedures by supporting the discovery of these required resources or
services.
Manufacturer Usage Description Specification
This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects.
This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions.
Concise Software Identification Tags
Fraunhofer SIT
Department of Defense
The MITRE Corporation
National Institute of Standards and Technology
ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an
extensible XML-based structure to identify and describe individual
software components, patches, and installation bundles. SWID tag
representations can be too large for devices with network and storage
constraints. This document defines a concise representation of SWID
tags: Concise SWID (CoSWID) tags. CoSWID supports a similar set of
semantics and features as SWID tags, as well as new semantics that
allow CoSWIDs to describe additional types of information, all in a
more memory efficient format.
The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)
The Hyper Text Coffee Pot Control Protocol (HTCPCP) specification does not allow for the brewing of tea, in all its variety and complexity. This paper outlines an extension to HTCPCP to allow for pots to provide networked tea-brewing facilities.
Terminology for Constrained-Node Networks
Universitaet Bremen TZI
Ericsson
UPC/i2CAT
The Internet Protocol Suite is increasingly used on small devices
with severe constraints on power, memory, and processing resources,
creating constrained-node networks. This document provides a number
of basic terms that have been useful in the standardization work for
constrained-node networks.
Trusted Execution Environment Provisioning (TEEP) Architecture
Broadcom
Arm Limited
Microsoft
Intel
A Trusted Execution Environment (TEE) is an environment that enforces
that any code within that environment cannot be tampered with, and
that any data used by such code cannot be read or tampered with by
any code outside that environment. This architecture document
motivates the design and standardization of a protocol for managing
the lifecycle of trusted applications running inside such a TEE.