Re: [Suit] Dependency index

[Brendan Moran <[e-mail]>]

>
>     > I'm struggling to identify any counter-examples, or reasons that they
>     > *must* be treated differently. The only thing I can think of is a
>     > specific optimization: when you have multiple generations of a root
>     > manifest that reference one changing manifest and one or more
>     > un-changing manifests.  Depending on how slots are implemented, this
>     > might become more complex.  However, I think that's an implementation
>     > consideration that exists regardless.
>
> Are you thinking about situations where, for instance, a radio image has only
> one slot (active slot), while some more critical has multiple slots.

This concern probably could have been exposed  with two manifests
rather than three, but this is where we are, so let's stick with it.

Remember that the context here is multiple trust domains. If we have
multiple manifests, then it must be because we have different parts
that are authorised by different signatures. Suppose that we have an
IoT device environment with three mutually distrustful actors:
1) An OEM/Software Vendor
2) A Network Operator
3) A Device Operator.

In this scenario, the OEM is responsible for the application software
& OS. The network operator is responsible for the network
configuration and/or interface firmware (see handset modems, for
example). The device operator is responsible for application
configuration, credentials, and maybe custom applets, or extensions.

We start with a single trust domain for the device software. (S)

- The OEM does not want to expose their IP to either the network
operator or the device operator.
- The OEM does not want the burden of signing network configuration or
application configuration.
This establishes (at least) a second trust domain. (N)

- The Network Operator does not trust the Device Operator to supply
valid network configuration
- The Network Operator does not want the burden of signing application
configuration
- The Device Operator does not trust the Network Operator with
credentials or to supply valid device configuration
This establishes a third trust domain. (D)


Since the network operator does not want to sign application config,
application config must not be a dependency of network config.
Since the OEM does not want to sign network config or application
config, neither of these configurations may be a dependency of the
system software.

This means that there are two possible models:

D ---> N --> S

D -+-> N
   |
   +-> S

If the Software Image is updated often (for security patches, etc.)
but the Network Config is rarely updated, then the Network Operator
may prefer NOT to take a dependency on the Software Image. The same
could be true for the Device Config, but let's ignore that scenario
for this discussion and assume that the Device Operator wants to
explicitly authorise deployment of new Software Images (note that this
may be important for inter-device compatibility checking in IoT system
deployments).

Then, we have constructed a scenario where D depends on N, D depends
on S. S & N are independent, but may have loose version coupling e.g.,
SemVer checks.

D must be re-signed for each S
N rarely changes

This is quite similar to your Android example.


Suppose that Manifests are just Components. When a manifest processor
parses a new manifest_D, it fetches some components in the dependency
resolution section: manifest_S and manifest_N--but it already has a
copy of manifest_N; it hasn't changed

In this scenario, the manifest processor is given the instruction to
download a component to the ID pertaining to Manifest_N. This will
result in an additional download & installation of payload_N. This is
unnecessary overhead. We've previously discussed that the "Fetch"
command could be written to identify whether a component is already
correct, according to the supplied digest, and skip the download if
so. This would need to work across slots, but I think that requirement
already exists.

> I think you mean that main images would be more trusted than dependent images.


I mean that, due to supply-chain considerations the least trusted
nodes in a manifest tree are closest to the root, or indeed the root
itself, while the most trusted nodes are typically leaves. This means
that, due to implementation considerations in the manifest processor,
less trusted nodes in the tree invoke "process dependency" on more
trusted nodes, effectively choosing whether and when to invoke a more
trusted node's command sequence. This is effectively a privilege
inversion--and acknowledged as such from the beginning. The result was
adding the manifest processor required checks.


Thinking through this some more, there are a few caveats to the
"dependency manifests are components" story:
- A manifest stored to more than one component ID will be handled more
than once. This raises the question of repeated application of a
manifest in the scenario of diamond dependencies. Where identical
manifests are guaranteed to be unique (KV store) the manifest
processor can trap this easily.
- A manifest treated as a component will have the digest of its
envelope checked, rather than the digest of the manifest itself.
-- A further implication is that severing elements, adding signatures,
etc. will change the digest.
- We do not have a command to check the signature of a manifest. Maybe
this needs to be a special case of "process-dependency" when invoked
from dependency-resolution?

I think that if we move forward on giving dependency manifests
component IDs, there will be several required changes to the existing
format and workflows

1. Components that will be identified as dependencies must be
designated, either in the component ID list or in a separate
dependencies list (it could just include component indices, for
example)
2. A manifest that declares any dependencies must declare all command
sequences for each procedure (Update, or Secure Invocation)
3. The manifest processor must keep track of each dependency and
ensure that "process dependencies" is invoked once, in each command
sequence, for each component that is classed as a dependency
4. When check-image is invoked on a component that is classed as a
dependency, the process is: 1) compare the check-image expected digest
to the auth-block digest, 2) compute the digest over the manifest, not
the envelope, fail if either does not match the check-image expected
digest
5. When process-dependency is invoked, the manifest processor must
validate the dependency's auth block. If the system can make
invariance guarantees about the dependency's integrity (e.g. the
manifest processor has already checked the dependency's auth block in
a previous command sequence, it's been stored in secure memory since
the last invocation, etc.) then it may defer to a previous validation.

I don't think these requirements are too onerous. This could
potentially simplify implementations of multiple trust domains quite a
bit since it removes the need for a secure key/value store. I think
the requirements above do deal with the potential security
consideration I was discussing earlier.

Best Regards,
Brendan

On Wed, Sep 28, 2022 at 12:10 PM Michael Richardson
<[e-mail]> wrote:
>
>
> Brendan Moran <[e-mail]> wrote:
>     > I'm struggling to identify any counter-examples, or reasons that they
>     > *must* be treated differently. The only thing I can think of is a
>     > specific optimization: when you have multiple generations of a root
>     > manifest that reference one changing manifest and one or more
>     > un-changing manifests.  Depending on how slots are implemented, this
>     > might become more complex.  However, I think that's an implementation
>     > consideration that exists regardless.
>
> Are you thinking about situations where, for instance, a radio image has only
> one slot (active slot), while some more critical has multiple slots.
>
> Android has significant dependancies between kernel and radio images,
> but does not use slots for the main image, rather uses a rescue image.
> One often can't have networking in the rescue image because it never
> matches the radio image. (And code space)
>
> But, one could imaging a phone with multiple boot slots, but yet, the radio
> still has only a single slot.  The un-changing manifest here is the radio image.
>
>     > There's a separate security concern that we should work
>     > through. Typically, I expect dependencies to be more trusted than
>     > dependents.
>
> Is there a typo/wrong word here? :-)
>
> Aren't dependents (my children) the things that I report to the tax authority
> as dependencies?  I'm not sure what the term for entity that has dependencies
> is (other than: "dad")
>
> I think you mean that main images would be more trusted than dependent images.
>
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>