> * 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 <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima