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

[Brendan Moran <[e-mail]>]

Hi Martin,

Please see my responses below.

Best Regards,
Brendan

On 19 Nov 2018, at 23:40, Martin Pagel <[e-mail]<mailto:[e-mail]>> wrote:

Brendan,
See responses with * below:
Best
Martin

From: Brendan Moran <[e-mail]<mailto:[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.

Does that mean that this format mandates an additional signature per image on top of the one in the manifest? If there is another way to authenticate the image, I have not been able to spot it.


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 )

From what I understood in the draft, the minimum size of the manifest described was:

sizeof(ManifestSetHeader) = 10
sizeof(Manifest) = 130
sizeof(ImageManifestEntry) = 74
sizeof(ManifestSetFooter) = 84
============
298

The ManifestSetHeader appears to be mandatory because it’s the only block that contains Magic and Flags, both of which are necessary for the device to understand the manifest. If the ManifestSetHeader is necessary, then the ManifestSetFooter is mandatory too.

If the digest and signature are platform-specific, and no type is provided, how can intermediate systems validate the manifest?

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.

Can you quantify what quite small means? The smallest ECDSA IP I found advertised 16000 gates. Class 0 and Class 1 CPUs run in the range of 12,000 gates for Cortex-M0+ to 33,000 gates for a Cortex-M3. Adding 16,000 gates to that size of CPU may be acceptable in some applications, but it likely won’t in others. I don’t think the working group should be reasoning about code size based on the availability of ECDSA accelerators when it’s not clear that devices targeted by SUIT will always have them. If we can get some clarity on the availability of ECDSA accelerators in Class 0 and Class 1 devices, then maybe we can adjust our reasoning.

I don’t understand how the MT3620 is relevant when discussing Class 1 devices. It’s a Cortex-A7 at 500MHz, 2 general purpose Cortex-M4 at 200MHz, and one special purpose Cortex-M4 integrated into the security subsystem. It has 16MiB of Flash and each M4 has 256kiB of RAM. That is so far beyond a Class 2 device that it’s not even possible to discuss in terms defined by RFC7228.

https://www.mediatek.com/products/azureSphere/mt3620

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.

But access and validation still aren’t free. I will post my code in the next few days. It costs 474 bytes of Thumb2 code to extract necessary information and validate the structure. If you look at the CBOR parser that I shared, it uses no temporary buffers.

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.

The draft-ietf-suit-architecture defines the creator of SUIT manifests as separate from the server. The author of a manifest, which is locked to a particular device class by the ClassID, should know what the capabilities of a device are. The reduction in complexity on simple devices is 86 bytes (See 4). CBOR encoding, however, reduces the size of the manifest: 199 bytes in draft-moran-suit-manifest-03 vs. 298 in draft-pagel-suit-manifest-00.



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.

My point is that every piece of unused information in a manifest consumes space and must be validated. For example, if a device supports no ABIs (as expected in a single-image device), is it an error for it to specify an ABI dependency? I would think that it has to be an error, since that would imply that the device cannot operate. That means that the dependencies must be validated to be a NULL value—I have assumed that this is 0 in my code.

How many different manifest structures will be defined in this specification?


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.

That introduces a single point of failure in a network-connected machine into the system. This breaks the end-to-end security guarantees of SUIT. draft-ietf-suit-architecture-01 explicitly separates the role of the update server from the Firmware Authority’s private key. There are some instances where this may be permissible, as raised in the discussion at IETF 101, but I don’t think this should be the default.


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.

This isn’t about how the device handles IANA-registered types, it’s about how the tools for creating manifests work. If each device has different types, then there can’t be any standard tools: the tools need to be customised for every device.


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.

I don’t see how this helps when the flags are in the ManifestSetHeader. How can the installer know which flags apply to which manifests/images? Or does a given device only accept a single configuration of manifests and images? The lack of specification for this field and the overloading that is necessary when there is no clear link between flags and manifests and images makes me worry that this will be very difficult to get right.

If you have multiple broadcast and encrypted images, then it’s going to be difficult to pack all the required options into the flags field, with no option to get more flags. You’ll need some bits to indicate the broadcast slot for each image and some bits to indicate the key identifier for each encrypted image. Does this limit the number of images that can be distributed in a single update if they are broadcast and encrypted? Or does it limit how many keys can be used? Or how many broadcast slots can be used?

Conflating flags from different manifests causes an authority problem too. How can the author of the ManifestSetHeader hold sole authority to specify any installation options, encryption keys, etc., when they are not the party responsible for that information? Shouldn’t all information relevant to a particular manifest be authenticated in that manifest?


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?

Regardless of the level of automation, at some point, a human must have to make a decision to apply a particular firmware to a particular set of devices. If that human is NOT the creator of the ManifestSet, then how can they make a decision without human-readable information?


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.

But this means that there will be two manifest structures instead of one. How many different versions of the same structure will be included in this draft?


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?

The concern I have is that this is very difficult to interpret. How does the Update Server find missing dependencies? I would have expected something more like (Image UID + version identifier). Otherwise, each image has two different identifiers: the image UID and the ABI. What does ABI actually indicate? The definition is very light: I wouldn’t know how to construct a depends-on ABI, or a provides ABI, given the existing draft.


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.

The draft specifies one behaviour: the device queries a known service for a URI, for each image, which it then fetches. How would these devices know which broadcast slot to watch? Or does this specification mandate that images are only ever broadcast in a particular slot? If the Flags field is the answer, then do all images in a given ManifestSet have to be broadcast in the same slot?

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.

I don’t understand how it can be 100 bytes. The sizes of the structures defined in the draft are:

sizeof(ManifestSetHeader) = 10
sizeof(Manifest) = 130
sizeof(ImageManifestEntry) = 74
sizeof(ManifestSetFooter) = 84

Which parts of these are combined to make 100 bytes? And how can you use a subset when each part of these structures contains some necessary information?

ManifestSetHeader => flags
Manifest => Vendor/Class ID
ImageManifestEntry => Image ID, type, size
ManifestSetFooter => signature


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.

Then that byte order should be specified. Otherwise, it will cause integration headaches.



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.

Most NB-IoT, LoRA, and LP-WAN devices in general require differential updates due to their very limited bandwidth. Likewise, satellite-connected devices will require differential update due to the very expensive bandwidth (both in power and in money).


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?

This flags field is starting to contain a lot of data! I’ve seen it suggested to carry:
* Encryption key identifiers
* Install options
* Additional information about where to fetch images

Key management is explicitly out of scope for now, but that doesn’t mean we can’t assume that devices have access to keys that are referenced by some form of identifier.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.