Reviewer: Martin Thomson
Review result: Almost Ready
The draft describes a means by which firmware - as identified by a SUIT
manifest - might have confidentiality protection added. Though this is not
entirely clear from the draft, a reason that this might be useful is where the
distribution system operates at a lower level of trust to the source of
firmware (the author) and the devices that will run it. For those cases where
encryption keys use symmetric ciphers (AES-KW), this assumes that there is a
parallel (but unspecified and unmentioned) system for the distribution of
content keys to devices; the use of asymmetric cryptography might permit a more
direct means of wrapped keys, but that means the creation of per-key (likely
per-device) manifests.
This leads to the first issue: the design in the draft leads to some
intermingling of the functions performed by the roles of author and distributor
(a term I will use instead of "distribution system" as it has fewer characters
for me to type). This occurs due to the fact that encryption parameters being
covered by the signature that covers the manifest. Two options are considered:
* The author needs to obtain a complete list of the keys held by devices that
will receive the firmware. This means having the author take on many of the
responsibilities of the distributor.
* The distributor needs to generate a fresh manifest for each recipient with
per-device encryption keys. This means giving the distributor access to the
plaintext of the manifest. This is not really addressed in the security
considerations. It's not clear to me who the encryption protects against in
that case.
Note that the latter also means giving the distributor a signing key, but any
risk there is managed by the use of a two-layer manifest, as described in
draft-ietf-suit-trust-domains.
Ultimately, the effect of this choice is to largely eliminate any useful
distinction between the roles of author and distributor, which leads me to
question the value of building up the edifice in the first place.
The lack of a threat model makes it hard to know whether the design meets the
design goals. Is the goal to protect against the distributor, or are there
unspecified others that the encryption is deployed against?
The draft does not really make it clear why an alternative design is
infeasible. That is, one where integrity information based on the *plaintext*
of the firmware is delivered as part of the manifest (a hash would suffice) and
encryption keys are delivered separately, such that there is no need to re-sign
the manifest when the keys change. In particular, this would be compatible
with the non-AEAD usage in the document. I don't know a lot about COSE, but it
seems like the unprotected field of COSE_Sign would do the job here.
In Section 5, the draft says that it redefines the write and copy directives,
but doesn't actually say what the redefinition is in any concrete terms. It
really only offers specification by way of examples, which isn't ideal. I
would have expected something like: Where suit-directive-write instructs the
device to take content and write it to a specific location, that directive is
changed to perform decryption of the indicated content while executing the
write operation, using the information provided in
suit-parameter-encryption-info. This introduces new failure modes for the
operation if the encryption method uses an AEAD (if the input content cannot be
successfully authenticated) or a CBC (if the padding is invalid).
Also in Section 5, the draft describes the use of suit-parameter-image-digest
for a referenced image, but equivocates about whether this applies to the
ciphertext or the plaintext. That sort of equivocation has no place in a
specification. While it might be possible to check a digest both before and
after decryption, it is relatively easy to specify which. If the ordering of
parameters determines which, say that, though I suspect that this would be
inadvisable due to the way that the processing model writes override parameters.
UPDATE: I just found Section 8. Yikes. Why is this hidden so far down?
That's better, but still not very clear. There is an ordering that applies
here and this does not establish that. The implication is that the digest
applies AFTER the decryption if they are part of the same directive, but the
text never actually says that.
The draft defines the use of AES-CBC. I see no value in using that scheme.
AES-CTR has value in that it doesn't change the size of the ciphertext. An
AEAD has the advantage of being able to bind additional context and perform
data origin authentication in exchange for the extra padding. CBC modes offer
none of those advantages, but expand the size by almost the same amount.
The draft does not set constraints on the size of the ciphertext. It should.
For battery exhaustion attacks, it seems like having to obtain - and maybe
process - the entire image before being able to authenticate any part of it is
a big part of why there is a problem. Presumably it is not always possible to
hold an entire image at once, so if the digest were able to be incrementally
validated, that would be a useful defense. Note that in the absence of a
key-committing AEAD, I'm not sure that having multiple AEAD tags would be a
useful defense, though it might be of some help in narrowing the attack
profile. The lack of key commitment makes me uncertain about Q3 in the flow
chart in Section 8.2; I believe than attacker that can modify the CEK (again:
threat model? what are the capabilities of the adversary?) is able to produce a
variant key that will pass AEAD validation on a given ciphertext. I'd suggest
a simple list of hashes with a chunk size parameter (which could be some
cardinal multiple of the sector size if you prefer), rather than a single hash.
Nits:
Section 6 introduces notation that looks like function invocations, except that
it is not. In LaTeX, I would write CEK(R, S) with a subscript as
$\mathsf{CEK}_{R,S}$. This is somewhat confusing as ENC(K, V) is a function.
I recommend the use of square brackets. For example, 6.1.2 would have: 1.
Fetch KEK[*, S] 2. Generate CEK 3. ENC(CEK, KEK[*, S]) 4. ENC(payload, CEK).
Note also that there is a established convention whereby the first parameter
to a PRF or encryption function is the key; this draft inverts that, which
could be confusing when both inputs are keys of one form or other.
The draft consistently fails to use <xref target="RFCXXXX" section="x.y"/> for
section references to other RFCs or drafts. This is just as easy to type as
what is there, but it makes someone else do a bunch of work. Fixing it should
be easy enough too.
Section 12 has a wonderful table that is drawn using ascii art, which is then
converted to an SVG. Please use a table.
For the fancy diagrams showing the cipher modes (which are entirely
unnecessary, in my view, there are citations you can use) aasvg recognizes ⊕,
which would make the SVG more comprehensible; presently it is not. Figure 11
references the previous diagram for a legend. That diagram (Figure 1) does not
include a legend; the next one (Figure 14) does. As far as legends go, it
might be better to have those in text, rather than the figure.
Many of the CDDL or diagnostic output figures are wider than the 72 column
format permits.
In Section 7, "For these ciphers the Enc_structure, shown in Figure 8, MUST NOT
be used because the Additional Authenticated Data (AAD) byte string is only
consumable by AEAD ciphers." -> s/MUST NOT/cannot/
In Section 7.3.1 (CBC), I don't understand this statement: "The numbering of
sectors in a slot MUST start with zero (0) and MUST increase by one with every
sector till the end of the slot is reached. The IV follows this numbering."
There is a single IV input to AES-CBC.
Section 7.3.1 also mentions AES-CTR-128, despite being about CBC.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
