[Anima] cBRSKI

[Michael Richardson <[e-mail]>]

> * What's the assumption of voucher-artifacts on the the IDevID's private
> key's secrecy once BRSKI has completed?

The private key is private.  Nothing needs to be revealed.
It can be stored in a TPM/fTPM or SecureElement.
Whether the LDevID certificate(s), have the same private key or a newly
minted one is a topic that 802.1AR section 6.

> Will the now-owner be able to read it? If so, once you see a logged
> assertion you can already not trust that device again.

Non-owners would have no access to the secret.
In many devices, owners would also have no access, but it depends upon the device.

> Or the owner still can't? Then why the logging in the first place, the
> IDevID will only be used in BRSKI if the device is pristine (or has been
> factory-reset).

The logging is about witnessing that the device became owned.
Subsequent owners can review this information to determine if they device is
still useable.   While we think about malware and root kits and the like,
other users might also think about wear and tear, such as for a braking system.

> Or is this a matter of security-in-depth, where the owner has better
> chances of exploiting weaknesses, so we better make as-sure-as-we-can that
> there was never an owner who could have done so?

Yes, that's certainly a concern.  An owner might be permitted to load
whatever code they want, and depending upon many concerns, that might include
getting access to the IDevID private key, if it is stored on an fTPM or not
secured at all.
To my mind, the smallest of IoT microcontrollers likely will be without
secred storage for private keys for a few generations, but many have secure
boot mechanisms, so in theory, the entire device is secured, and will not run
arbitrary code.

> Is delegated-voucher The (only) Way to oboard a resold device (or a device
> from a domain that suffered critical infrastructure collapse) without
> taking a programmer to it?

No.  A device could go through a controlled factory reset so that it no
longer knows it's LDevID, or network credentials, at which point, it would
start over.  The only evidence of the previous owner would be in the MASA
audit log.
This could be via button push, via software command.

delegated-voucher has two purposes: 1) to enable resale without talking to
the original MASA (infrastructure collapse), 2) to enable aggregation of
devices into sub-systems.

I think, and I think that there will be regulatory processes that go with
this, that in the event of infrastructure collapse one of two things will
occur:

a) a new MASA will be operated, and a new set of code will be produced from
   escrowed sources.  (Back when software was expensive, in the hundreds of
   thousands of dollars/copy, source code escrow was a normal thing to do)
   If done in an orderly fashion, the old supplier would
   produce a new firmware image with new anchors and would deploy that before
   going out of business.

b) the devices would be marked a regulator as no longer safe, since they have
   no one to patch them, and would be forced out of service.


> If an owner can take complete control over a device (like, switch over the
> firmware, as you can do with a PC or a device that contains GPL-3
> software), would the issuer of such a new firmware also need to provision
> the device with a new IDevID?

Maybe.  Probably be a good idea.  The MASA URL would be wrong in the existing
IDevID.  RFC8995 provides for the Registrar to have the ability to override
that URL under operator control.  That would apply to all devices from that
manufacturer, probably, so it's a big hammer. Replacing the IDevID would be
simpler.

There are many different ways in which one can switch over the firmware.
On a PC, one does not typically replace the BIOS, so it might be that one is
just using a secure boot shim, or a replacing trust anchors.
For a PC, my notion is that BRSKI would not be used for the main CPU, but
rather for the BMC.





--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide