Re: [Suit] Review comments on draft-pagel-suit-manifest-00

[Martin Pagel <[e-mail]>]

Brendan,
See responses with * below:
Best
Martin

From: Brendan Moran <[e-mail]>

1. I do not understand how images are authenticated. I see no reference to an image digest. Are images concatenated inline within the structure? I see no reference to concatenation within the format definition.
* Each image can be downloaded and authenticated separately. The image file should have a digest, key identifier or thumbprint, and signature using a platform specific format at the end of the file.

2. This is a format for low-end devices (Section 1, paragraph 1)

The meaning of "low-end devices" is not described and no reference to RFC 7228 is made. Without this information, it is not possible to fully evaluate the claims in this document. Given the nature of this standard, the presence or absence of hardware-accelerated cryptographic primitives and/or ROM cryptographic functions is extremely important to device classification. I will assume that “low-end” means Class 0 and Class 1 devices, as defined by RFC7228.

The minimum usable size of the described format is 298 bytes. Assuming no URI, no signing key ID, the critical information for a Class 0 device is:

Sequence number (2 bytes should be adequate for Class 0)
Flags (2 bytes)
Vendor ID (16 bytes)
Class ID (16 bytes)
Payload digest (32 bytes)
Signature (64 bytes)

This format encodes 132 bytes into a 298 byte structure when used with a single image Class 0 device. This does not seem like an improvement over CBOR: draft-moran-suit-manifest-03 would encode this same information into 199 bytes

* Brendan, I don’t understand why you think it would require 298 bytes to store 132 bytes, can you explain?
Also, the digest and signature are platform specific and only listed for reference. (if the device supports COSE, it might even use COSE putting it on par )

3. At IETF 103, there was discussion of devices with cryptographic accelerators. Public key acceleration is what is needed for update. Devices with public key acceleration are rare, but becoming more common. In surveying the available devices with ECDSA acceleration, the majority of devices I found had at least 512kiB of Flash, most vendors had offerings with 256KiB of Flash, there was only a single device family I could find with 128kiB of Flash, and none smaller. Each of these devices had 96kiB of RAM or more. These are not Class 0 or Class 1 devices; they are Class 2 or higher, with the possible exception of the 128kiB device, which seems to be somewhere in between.

* public key crypto accelerators are quite small and easy to add even to a Class 1 MCU as we did with the MT3620. Driven by increasing security awareness, we expect more MCUs to support them.

Does the SUIT working group believe that the size of a minimal manifest parser/validator (<600 bytes) is relevant when compared to the signature verification library in Class 0 or Class 1 devices? Does the working group believe that the size of a more flexible parser (cn-cbor, for example) is relevant on a Class 2 or greater device, when it may have a cryptographic accelerator?

4. It is an advantage to extract data from a packed binary format, rather than a serialised format on low-end devices (Section 1, paragraph 1)

I don’t understand why it is considered an advantage to not run a parser. Parsers are just information accessors. Packed binary formats still need accessors.

Serialised formats do not imply general-purpose parsers. General-purpose parsers incur a lot of overhead, it is true, but specialised format accessors can operate at a similar cost to direct binary encoding. When a general-purpose parser is not appropriate, a serialised format can be consumed by a specialised format accessor can be used instead.

Since code size was raised as a concern, I wrote a validator/information accessor for manifest formats to evaluate the code size of each, when compiled on Arm Cortex-M4. A validator for a minimal subset of draft-moran-suit-manifest-03 consumed 560 bytes. A validator for a minimal subset of draft-pagel-suit-manifest-00 consumed 474 bytes. I would like to know if the working group believes that this savings of 86 bytes of code warrants using a packed binary format.

* If you don’t use a parser, you not only save the parsing code (see my code in separate email), but you won’t need to a separate temporary buffer to load the manifest file into, too.

5. Implementers will pick a fixed format for each target device (Section 1, paragraph 2)

Implementers may well pick a fixed format however, as you note in Section 2, paragraph 1, if they need more than one, fixed binary formats will either incur a additional complexity and overhead. As more options become available in the format, the flexibility of a CBOR format becomes more attractive.

* yes, a binary format will increase the complexity to support variances in the data formats on the server side, but reduce the complexity for simple devices. The server needs to know a lot about each platform anyways, as it can’t expect that each device can handle any type of signature format, payload format etc. CBOR allows for flexibility but I believe that’s a flexibility a device shouldn’t have to worry about as it increases complexity and therefore code and data size and the risk for exposures. If the server ignores the fact, that a device won’t/can’t handle certain parameters, this may cause some very unexpected problems so you better develop the Update Server in a way it understands the capabilities of the devices it supports.

6. Platform providers will provide separate layers (Section 1, paragraph 3)

For Class 0 and Class 1 devices, I find it very unlikely that there will be software layers distributed in separate binaries, with the possible exceptions of: bootloaders, external hardware modules. Perhaps other members of SUIT can provide their views on how firmware is distributed to Class 0 and Class 1 devices.

For Class 2 devices and above, this is more likely. Bear in mind that, for an ABI to make sense, a software component must implement either software interrupts, jump tables, loadable modules, or multiple cores with a core-to-core communication mechanism.

* Not sure what your point is…  Yes, I agree that you may not need ABI info for Class 0+1, it would be easy to leave that out.

7.  Each layer is signed independently (Section 1, paragraph 3)

For Class 0 and Class 1 devices, validating a signature comes with a high overhead. ECDSA validation can take more than 400ms (https://datatracker.ietf.org/meeting/92/materials/slides-92-lwig-3<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F92%2Fmaterials%2Fslides-92-lwig-3&data=02%7C01%7CMartin.Pagel%40microsoft.com%7Cd0a33198464d446f423708d64be524b5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636779844877229449&sdata=jNGDdmq%2F%2BMuP%2Bl2%2B7rVaOZb2kiYVEzZ0%2FjIB26G33hs%3D&reserved=0>), which comes with significant energy consumption. I do not expect Class 0 and Class 1 devices to perform many signature verifications. Multiple signatures on a set of images on battery-powered devices, are likely to reduce device lifetime significantly.

draft-moran-suit-manifest-03 shares this challenge. How should devices validate the authenticity of multiple binaries that require different rights without the overhead of multiple signature verifications? I think this is an open area for improvement.

* I share your concern. Simple devices typically only have access to a single key associated with the Update Server. For such devices, the Update Server would need to verify the signatures from the various vendors and combine it into a single manifest with a single signature.

8. Component type implies payload format (Section 1, paragraph 4)

I do not see the benefit of conflating component type and payload format.

If component type implies payload format and both are implementation-defined (Section 1, paragraph 4), there is no way to do IANA registration of payload types. This poses several problems: It requires deep knowledge of each device’s component/type IDs in order to build tools to create manifests. It causes integration problems when using existing libraries for handling components from different vendors: imagine trying to build the updater for a device that has two radio modules—one wifi, one BLE, for example—and each vendor has provided an installer that depends on a type ID; there is no registry available to prevent conflicts between type IDs.

The chance of constructing an erroneous manifest is high because component-type’s meaning is different from target to target.

* I think the device’s installer for Class 0+1 devices would only support a few payload formats and not be able to launch separate installers. Just because a payload has IANA registration, the device won’t know how to deal with it. So either the vendor would have to provide the software in one such formats, or the Update Server may have to convert the format from the vendor’s format to one of the device’s format.

9. A single 16-bit flags field is sufficient to encode all vendor-specific information (Section 1, paragraph 4)

I don’t understand how the 16 bits in the manifest-set will be adequate to handle the use-cases described. How can a 16-bit integer specify both where to store a payload and to configure encrypted payload handling. The same considerations as 8. apply with regards to IANA registration.

* It’s expected that the device installer understands certain image types and knows how and where to install them or how to decrypt them if it supports encryption. The flags will only be necessary in case the device offers any install options.

10. No human-readable information is required (Implied, no text fields present in format)

How can a human operator know what a given manifest does without textual descriptions? What are the security considerations around any unauthenticated delivery of textual information?

* My understanding was that this work group would focus on automated updates through an Update Server and not concern itself with human installations. Am I missing something?

11. Devices have software components with abstract APIs (Implied by Section 1, paragraph 7, presence of ABI fields in all manifests)

Most Class 1 and all Class 0 devices I have seen use statically linked applications, that effectively have no ABI. For the ABI Dependency information to make sense, it needs to be on a system with modules that communicate via software interrupt, loadable modules, jump tables, or script interpreters. These approaches are far more common in Class 2 or higher devices—devices where a generic CBOR parser would likely be available. The only exceptions that I have seen to this is with regards to boot loaders or external hardware modules, such as radio modules.

* Yes, I agree that you may not need ABI info for Class 0+1, it would be easy to leave that out.

12. The manifest should report which ABIs are exposed by the components it contains (Section 1, paragraph 7)

There are many existing mechanisms for referring to ABI versions. I haven’t seen this one before. What are its advantages and disadvantages compared to existing mechanisms?

* We chose this implementation for its simplicity. Brendan, do you have a better method in mind?

13. Payloads should be obtained by discovery, not by explicit direction (Section 1, paragraph 9)

This is a reasonable design decision for a system, but I would much rather if that design choice were left up to implementers, rather than enforced in the standard.

Fetching payload by discovery introduces a round-trip query for each device. How would this affect multicast and broadcast use-cases? A payload URI could potentially contain a broadcast interval or a receive slot for the payload. How would a device determine broadcast interval or receive slot without that information being provided in the manifest? I expect that the logic for (1. Authenticating with a remote service, 2. Querying that service for a URL, and 3. Initiating a download) would be much more expensive than resolving a URL in a manifest.

* Installers for basic devices are usually configured for a particular update mechanism, meaning they watch a broadcast slot or can turn the ImageId into a URL and don’t necessarily need to make additional calls.

14. Basic devices are better served by binary formats due to space constraints (Section 2, paragraph 2)

Fixed binary formats cannot prune unused fields. This means that a minimal binary format cannot provide intermediate or advanced functionality, meanwhile, an intermediate or advanced fixed binary format is much larger than the space needed for a minimal use-case. To demonstrate this problem, a manifest constructed according to draft-pagel-suit-manifest-00 with a single manifest and a single image consumes 298 bytes. A manifest constructed according to draft-moran-suit-manifest-03 that contains a single image, with no URI consumes, text, or signer identifier, consumes 199 bytes.

* the data structure for a single image is only 100 bytes (the size of the signature depends on the platform). If you want to eliminate portions (such as ABI dependencies), then you can define a custom data structure version, that’s what the Version parameter is for.

15. Sophisticated devices should use CBOR manifests, since they are more flexible (Section 2, paragraph 3)

I agree, sophisticated devices are better served by CBOR manifests. I contend that basic devices are better served by CBOR as well since the format can be tailored exactly to the use-case, while remaining compatible with standard tooling.


16. Byte order is platform specific (Section 3, paragraph 1)

Tools must know the recipient in order to construct a manifest. The chance of constructing an erroneous manifest is high.

* most platforms now use the same byte order and you still need to do testing anyways.

17. Signers should be identified by certificate fingerprint (fields described in Section 3)

Maybe this could be changed to Subject Key Identifier? By mandating the use of fingerprints, the implication is that public keys are delivered via certificate. Certificates imply DER parsing, which has far more overhead than a simple CBOR parser. If public keys are delivered via certificate, then the format of the manifest is irrelevant for a constrained device. Subject Key Identifiers allow the use of either certificates or bare keys, which reduces the parsing overhead for signature verification.

* that would be fine

18. ManifestEntrySize (Section 3)

I don’t understand what this size is for. Doesn’t the version cover this already?

* it’s an optimization to make it a bit easier to find the signature portion, but not totally necessary.

19. Build Date (Section 3)

This has been debated in the SUIT working group. The wg feels that there are too many problems with timestamped manifests and that a sequence number is more appropriate.

* There may be some advantage for humans to interpret the timestamp, but I don’t have strong feelings either way.

20. No differential updates (Section 4.8)

The draft seems to imply that IoT devices will not use differential updates. I am aware of several products that do use differential updates. Does the working group believe that we should not support differential updates?

* For large software systems, differential updates are certainly useful, but we didn’t feel that for class 0+1, the file size vs complexity is worth the effort in particular if the device may not be online for a long time, then it has to download the full image anyways once it comes online again.

21. Content Encryption Key Identifier (Section 4.11)

I don’t see a way for a device to specify an encryption key identifier. How would this be done?

* It could use a portion of the Flags parameter to identify the key. Btw, I have not seen any discussion on key management, did I miss this?