Missing a guideline for constructing secure SUIT Manifest

[kentakayama]

There are a lot of security mechanisms in both SUIT Manifest document and this document. Avoiding them to be misused, how about adding a guidance for selecting mechanisms and reconstruct the chapter?

Chapter Reconstruction

1. Add ECDH-ES+HKDF-256 and ECDH-ES+HKDF-512 (because suit-mti document lists them)
2. Put encryption algorithms into one chapter (7. Content Encryption)
3. Add a guideline for constructing secure SUIT Manifest (8. Constructing Secure SUIT Manifest)

Current	Proposed
1. Introduction	1. Introduction
2. Conventions and Terminology	2. Conventions and Terminology
3. Architecture	3. Architecture
4. Encryption Extensions	4. Encryption Extensions
5. Extended Directives	5. Extended Directives
6. Content Key Distribution	6. Content Key Distribution
6.1. Content Key Distribution with AES Key Wrap	6.1. Content Key Distribution with AES Key Wrap
6.1.1. Introduction	6.1.1. Introduction
6.1.2. Deployment Options	6.1.2. Deployment Options
6.1.3. CDDL	6.1.3. CDDL
6.1.4. Example	- - (MOVED INTO 7.1.1)
--	6.2. Content Key Distribution with ECDH-ES + HKDF (NEW)
--	6.2.1. Introduction
--	6.2.2. Deployment Options
--	6.2.3. CDDL
--	6.2.4. Context Information Structure
6.2. Content Key Distribution with Ephemeral-Static Diffie-Hellman	6.3. Content Key Distribution with ECDH-ES + AES Key Wrap
6.2.1. Introduction	6.3.1. Introduction
6.2.2. Deployment Options	6.3.2. Deployment Options
6.2.3. CDDL	6.3.3. CDDL
6.2.4. Context Information Structure	6.3.4. Context Information Structure
6.2.5. Example	-- (MOVED INTO 7.1.3)
--	7. Content Encryption
--	7.1. AES-GCM (NEW)
--	7.1.1. AES-KW + AES-GCM Example (MODED FROM 6.1.4)
--	7.1.2. ES-DH+HKDF + AES-GCM Example (NEW)
--	7.1.3. ES-DH+AES-KW + AES-GCM Example (MODED FROM 6.2.5)
7. Firmware Updates on IoT Devices with Flash Memory	-- (MOVED INTO 9.)
7.1. AES-CBC	7.2. AES-CBC
7.1.1. AES-KW + AES-CBC Example	7.2.1. AES-KW + AES-CBC Example
--	7.2.2. ES-DH+HKDF + AES-CBC Example (NEW)
7.1.2. ES-DH + AES-CBC Example	7.2.3. ES-DH+AES-KW + AES-CBC Example
7.2. AES-CTR	7.3. AES-CTR
7.2.1. AES-KW + AES-CTR Example	7.3.1. AES-KW + AES-CTR Example
--	7.3.2. ES-DH+HKDF + AES-CTR Example (NEW)
7.2.2. ES-DH + AES-CTR Example	7.3.3. ES-DH+AES-KW + AES-CTR Example
7.3. Battery Exhaustion Attacks	-- (MOVED INTO 9.1)
--	8. Constructing Secure SUIT Manifest (NEW)
--	8.1. Security Mechanisms (NEW)
--	8.2. Payload Delivery (NEW)
--	8.3. Mechanism Patterns for Best Practice (NEW)
--	9. Firmware Updates on IoT Devices with Flash Memory (MOVED FROM 7.)
--	9.1. Battery Exhaustion Attacks (MOVED FROM 7.3.)
8. Complete Examples	10. Complete Examples
9. Operational Considerations	11. Operational Considerations
10. Security Considerations	12. Security Considerations

8.1. Security Mechanisms

place	target	algorithm	for	whom
suit-authentication-wrapper	suit-manifest	{SHA-256, ...}x{ES256, HMAC-256, ...}	authenticity + integrity	Author
suit-parameter-image-digest	(encrypted) payload	SHA-256, ...	integrity	Author
suit-parameter-uri (HTTPS or other secure protocols)	(encrypted) payload	AES-GCM, AES-CCM, ChaCha/Poly, ...	(authenticity +) integrity	Firmware Server
SUIT_Encryption_Info	(encrypted) payload	AES-GCM, ...	authenticity + integrity	Sender

8.2. Payload Delivery

directive	parameter	is protected by
--	suit-parameter-content	suit-authentication-wrapper
suit-directive-fetch	suit-parameter-uri = "http://..." or "#integrated" (via not secure protocols)	not protected
suit-directive-fetch	suit-parameter-uri = "https://..." (via secure protocols)	protocol

• The value of suit-parameter-content is protected by the suit-authentication-wrapper, but it SHOULD be used only if the size of content is enough tiny.
• The payload in integrated-payload or fetched via not secure protocols is NOT protected by the suit-authentication-wrapper, so that additional validation like suit-condition-image-match MUST be done.
• Fetching the plaintext payload via secure communications like HTTPS is out of scope of this document. Conducting suit-condition-image-match is highly RECOMMENDED if the delivery point is not fully trusted.

8.3. Mechanism Patterns for Best Practice

pattern	suit-authentication-wrapper	payload integrity	encryption algorithms	for	good at
#1 Symmetric + Content	COSE_Mac0(HMAC-256)	by suit-authentication-wrapper	AES-KW + AES-CTR	delivering tiny payloads	compact
#2 Symmetric + Integrated Payload	COSE_Mac0(HMAC-256)	by suit-condition-image-match	AES-KW + AES-CTR	basically offline devices	network connectivity is not required
#3 Symmetric + HTTP	COSE_Mac0(HMAC-256)	by suit-condition-image-match	AES-KW + AES-CTR	Constrained IoT devices	only symmetric algorithm is required
#4 Asymmetric + HTTP	COSE_Sign1(ES256)	by AEAD algorithm in COSE_Encrypt	ECDH-ES+HKDF-256 + AES-CTR	IoT devices	key management
#5 Asymmetric + HTTPS	COSE_Sign1(ES256)	by AEAD algorithms in COSE_Encrypt	ECDH-ES+AES-KW + AES-GCM	powerful devices	defense in depth

[mcd500]

Hi @kentakayama,

I understand your comment and your objective is good, but I feel the changes are a bit too intrusive considering it is at the last stage of the suit-firmware-encryption draft.

[kentakayama]

@mcd500 Exactly but my concern was arised after the suit-mti document defines profiles using AES-CTR. Additionaly, I realized that there is a mismatch around ECDH-ES+HKDF.

My concern is that some might create a manifest like:

directive-override-parameters {
  uri: "http://example.com/file.bin",
  encryption-info: <<96([h'', { / alg / 1: -65534 / A128CTR / }, null, ... ])>>
},
directive-fetch,
directive-copy / decrypt fetched payload using encryption-info /
/ done /

The manifest processor would decrypt the payload without checking its integrity because the AES-CTR protects only confidentiality. The condition-image-match SHOULD be executed on plaintext payload after decryption (or on cipheitext payload before decryption, see section 7 in detail). But it MAY be skipped when the code signing and secure boot protect the plaintext payload. On the other hand as long as we use AEAD such as AES-GCM, condition-image-match is not required after decryption because its tag are validated at the same time.

I think they are so complicated and the non AEAD might be easily misused. That's why I've raised this issue.