[T2TRG] Review of draft-richardson-t2trg-idevid-considerations-06

[Sini Ruohomaa <[e-mail]>]

Hello, T2TRG!

I got an internal ping that you have a document in need of review:

A Taxonomy of operational security considerations for manufacturer
installed keys and Trust Anchors" :

https://www.ietf.org/archive/id/draft-richardson-t2trg-idevid-considerations-06.html
 [accessed 9 Mar 2022]

This is an interesting document, and I appreciate the background
information included. I have no major structural comments but a
bunch of 'formulation' comments and some proposals here and
there. :) A "easy-to-use" modeling of the considerations list is the
hardest part to make general here, as simplifications tend to come bite
us in the backside afterwards, but in my opinion it is not actually
even the biggest contribution of this paper and "perfecting" it should
not be considered a pre-requirement for publication.

I would like to pass my warm greetings to the authors for the
effort of trying to make this more communicable. I would like
to reference this document when it is ready. It is written in a very
approachable way so I see value in it also as an educational document,
not just an evaluation framework.

Apologies in advance that I'm not from the mailing list and just a
drive-by reviewer with the attention span of a squirrel; I've asked Ari
to keep an eye and let me know in case any clarifications are needed
(thanks again).

1. Introduction

"An increasing number of protocols derive a significant part of their
security by using trust anchors [RFC4949] 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. [RFC6024] deals with how trust
anchor stores are managed, while this document deals with how the
associated PKI which is anchor is managed."

The last sentence is a bit hard to parse.

"Device identity keys are used when performing enrollment requests (in
[RFC8995], and in some uses of [I-D.ietf-emu-eap-noob]. The device
identity certificate is also used to sign Evidence by an Attesting
Environment (see [I-D.ietf-rats-architecture])."

One closing parenthese ")" is missing.

3.6 "what else" question

The identities trust anchor for validating identities of non-web-PKI
devices in case they need to ever talk to each other, or the identity
trust anchor of a vendor specific service that the device must connect
to in order to do e.g. enrolment of other identities, setting up
attestation or zero-touch bootstrapping come to mind (this allows the
device too to know who it is talking to, in addition to having the
device authenticate towards such an enrolment service). 

I would cover these with a 'other identity validation trust anchors' in
addition to the public web PKI trust anchors, as the category is
probably too wide to cover satisfactorily an individual subcategory at
a time.

4.1: minor

"[ieee802-1AR] defines a category of certificates that are installed by
the manufacturer, which contain at the least, a device unique serial
number."

Had trouble parsing the sentence, is the comma right?

"This may be a software setting, or could be as dramatic as blowing a
fuse."

I really appreciate the author's hearty writing style here. :D

4.1.2.2

"Generating the key off-device has the advantage that the randomness of
the private key can be better analyzed. "

A second benefit that I expect has been more commercially interesting
is that (assuming serial numbers or other relevant identities can be
pre-reserved) the certificates can be pre-issued, which eliminates both
CA latency and CA dependency from the manufacturing process itself. I
still would not recommend off-device generation though. Due to the leak
potential and wider exposure to insider attack it has a creepy ring to
it that may undermine the trust placed in the PKI. Even if we 'never
store' the key (as is suggested later in this section) we will leave
computational traces of the key around.

4.1.2.3

Agree with the conclusion that this method shares the downsides of both
above.

5. PKIs

"A PKI which discloses one or more private certification authority keys
is no longer secure."

Technically, subCAs exist for the sake that they CAN be revoked by a
higher level CA, to recover from compromise of an issuing level CA
which is typically more exposed than the higher levels. However,
everything issued from that subCA is indeed due for hardware recall so
the event is major. But the most major event is leaking the root CA, as
there is no way to recover from that within the same root chain.

To get really into detail though, a well managed CA is able to keep
track of public keys it has intentionally signed into certificate, and
depending on the use case even a compromised subCA key could
theoretically be worked around in the field through administrative
means that basically let go of the cryptographic protection of the PKI
chain in favour of administrative tracking. I think that part would be
hackish and beyond the scope of this text, however. Just can't help
myself going through the what-ifs; these PKIs have to be seriously
robust. Just imagine a full hardware recall of a car manufacturer for a
"oops need a quick bootstrapping identity PKI fix". Or of anything
resembling a home wifi access point box that end users don't even touch
if it's still working.

5.1

"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
subordinate CA is available in an online form."

This formulation implies that subCAs would not be in hardware security
modules or that they cannot offer CAs available in online form. I think
we should definitely underline the importance of keeping subCAs in HSMs
as well.

I would separate the two dimensions explicitly and say "where the root
of the CA is stored in a Hardware Security Module in a way that it
cannot be continuously accessed ('offline'), while the subordinate CA
can sign certificates at any time ('online')." Or potentially even
another formulation that mentions completely separately that "CA keys
are stored in Hardware Security Modules so that the root ... and the
subordinate ...".

The section below talks about this in more length so this could also be
migrated there.

6.1

"first-stage initialization" focusing on the raw number of people
'involved' feels maybe a bit arbitrary.
- it is also important what level of access these people have to the
device in practice, or are they performing primarily a monitoring task
- considering a factory shopfloor, it may be misleading to think that
only 3 people are involved because 3 people actually are *supposed* to
be touching the board, if in fact 300 other people have access to the
actual space and could pop by to intervene with the process if it's not
happening in a separate locked room. (Note that the janitors could also
be bribed and planted/instructed even though no one would count them as
'involved' by default.)

I might redefine this as 'exposure' of the device while in the process,
where fully automatic closed area might be 'low' and a large shopfloor
where 20+ people have physical access to actually go physically touch
the device or the equipment processing it as 'high', for example.

first-second-stage-gap: This factor is not formulated as a question.

(Some later factors are not capitalized and punctuated consistently.)

6.2

"identity-pki-level: how deep are the IDevID certificates that are
issued?"

Would just clarify formulation a bit: how many levels of CAs exist
above the certificates issued. (The 'depth' concept seems ambiguous and
may cause confusion.)

identity-anchor-storage: 'Recover' the private key is a bit ambiguous -
different quorums may be needed for a) making it available to sign a
new CA vs. b) making it possible to actually copy the root key around
to new devices/places. I would maybe use the term 'to access' here to
avoid that debate altogether, since signature access is enough to
compromise.

Potentially some indicators to add could include how wide the issuing
CA access is stretched, if that can be captured in a simple question.
The easiest way to deploy a subCA is to give everyone a copy of the
private key, and then you can't place a whole lot of trust on the CA
itself. Handing off subCAs vs. having a centralized entity controlling
all issuing CAs does make a difference in possibility for
administrative oversight.

6.3

pki-level: similar consideration here, 'deep' is a bit ambiguous. Not
sure what the EE level to evaluate actually implies of the integrity of
the trust anchors, it seems more a category for e.g. integrity and
privacy of 'software signing PKI' or whatever we want to call this one-
to-many devices relationship vs. the many devices to 'one' integration
target in identities.

pki-algorithms: potentially include also the timespan they are
considered valid or in active use, cf. keylength.org - it makes a big
difference if you trust the lowest rung of security for the next
several decades or just a year or two.
- potentially also could differentiate here between algorithms actually
used in the PKI vs. algorithms the device in general is capable of,
because if they are not used in the PKI (and that is more painful to
enumerate) then their appearance is mostly irrelevant or a sign of
compromise. The current formulation implies the device is able to
handle these algorithms but if they are not used in the PKI now or
tomorrow they are irrelevant. 

(Generally algorithm filtering in semi-closed systems is best achieved
by just not signing certificates that are worse, not so much at
validation point as an extra check (X.509 standards do not support this
sort of filtering directly even), but in case of web PKI the PKI may be
only "semi-trusted" to follow sensible rules and maybe a browser could
blacklist some algorithms in addition to forbidding some protocols they
could be used in, which is more common and often allows user
configuration to turn blacklists off - which may not be as feasible in
these cases.)

pki-level-locked: This formulation is unclear. I think what it means is
whether X.509 path level constraints are applied in the root and/or
below. It is most relevant for the online subCAs if they are "handed
around" as opposed to being centrally controlled, i.e. can the subCA
quietly sign another subCA. If the PKI ownership is a closed system the
path length constraints add less value in exchange for putting
additional contraints on an already stiff tool.

pki-breadth: maybe hard to answer and potentially largely irrelevant as
I can't see outside public web CAs anyone coming to wag a finger if a
vendor suddenly becomes super popular and issues certificates for an
exponentially larger number of end entities with a wider series of CAs
than initially deployed. All they really need to do is add storage
space. The load on an individual issuing CA is more interesting from a
few different points of view, than the capacity of the full and very
expandable PKI tree. Though of course there might be some actual
limitations in some management software implementations too.

"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?"

It is unclear here what the first sentence means, 'to sign what'
basically. OID references are good. I would replace 'needed' with
'required' or 'demanded' as they are often constraints of systems
rather than actual needs.

Same recovery vs. usage note as above.

Thank you for your work. I hope to see this draft go live. :)

Best regards,

--Sini