Re: [Iot-onboarding] [Anima] Device Certificate Deployment Automation with ACME using BRSKI

[Kent Watsen <[e-mail]>]

> On Aug 9, 2019, at 11:16 AM, Michael Richardson <[e-mail]> wrote:
> 
> 
> Kent Watsen <[e-mail]> wrote:
>>> But, more interestingly, it can be used to update the trust anchors, to
>>> enable a resale/transfer of ownership!
> 
>> But, seriously, no.  It's expected that decommissioning will returned a
>> device back to its factory default state.  No manufacturer will agree
>> that it is anything other than the state of the device when it was
>> manufactured.   Anything other than that could be leveraged to mount an
>> attack.  Change in ownership-assignment needs to occur through some
>> other means, of which there are many but, in the end, if the 2nd-owner
>> cares about the security (not just the convenience) of bootstrapping,
>> then they are strongly advised to purchase never before used
>> equipment.
> 
> This is indeed the tussle the BRSKI document has been dealing with
> in its IESG review.  If we can't change the trust anchors used to verify
> the voucher, then how can the device be onboarded after the MASA
> has gone away?

Oh, wait, my prior response wasn't wholly accurate.

The factory default state reflects zero remnants, but it doesn't necessarily mean the same OS-version as the day the device left the factory.   Many devices don't have enough NV storage to keep the original OS forever, not to mention that it would be rather silly as, better, would be to keep what's considered the last known-good OS image (which may not be the same thing).   Many devices will effectively overwrite the previous OS image ("don't touch the power button during install!") and thus what happens when pressing the "reset to factory default" button is a reflection of what "factory default" means to the new OS image.   The good news is that new OS images can contain new CA certificates, for authenticating well-known services (e.g., MASA, OVIS, etc.).  What cannot change is the IDevID certificate (LDevIDs are wiped).

Of course, all this assumes the manufacturer is still around to release OS updates, but this is simply part of the business decision that customers need to consider when purchasing equipment.   The probability of a successful bootstrap shortly after fresh purchase directly from the manufacturer is very high, but lowers over time as risks around businesses going belly-up start to creep in.  A device sitting on a shelf for a decade, or devices bought on eBay, may not bootstrap without an OS upgrade.

None of the above reflects how to support change in ownership, though.   A device reset to factory default has no "owner", just some trust anchors that can be used to verify an entity claiming to be its owner.  What backend sale-channel integration or customer-handoff protocol might be used to support change in ownership is out of scope.



> I don't understand how RFC8572 slipped through the IESG without resolving this.

Perhaps because BRSKI leads with ephemeral vouchers and hence the need for online MASAs (with offline support tacked on the side), whereas SZTP leads with optional use of vouchers but, when used, they're mostly non-ephemeral and accessible at time or purchase (with ephemeral voucher support tacked on the side).   The shift in emphasis begs the question, so they're asking it.  Still, it seems more like a customer/business issue than something IESG should worry about.


Kent