[Cryptography] USB 3.0 authentication: market power and DRM?

[dj at deadhat.com]

> On 5/2/16, dj at deadhat.com <dj at deadhat.com> wrote:
>> The CA that needs to exist would the the USB-IF.
>
> Who cares what CA exists.
> So long as it is *optional* to the user.
>

Indeed. Up to 8 cert chain slots are addressable - The slot number
occupies 3 bits in the protocol.

The USB-IF slot 0 is mandatory for USB certified devices and gets filled
with a cert chain rooted in the USB-IF. That is what I meant - It's
mandatory for the USB-IF to set up  CA to support that. Not mandatory on
manufacturers to get certified (unless you want to use the trademarks and
not mandatory for you to use or honor the USB rooted credentials.

The USB rooted credential chain tells you that the USB-IF tested and
certified the device design, subject to the usual ways that might be
circumvented, which has already been discussed on this mailing list (the
metzdowd crypto list at least). This is a mechanism that has proprietary
solutions today, but it's not based on those solutions as far as I'm
aware.

Other slots can be used for whatever your purpose.

What you need to be concerned about is control over policy. If the policy
is hardwired to 'must have a USB-IF certified device cert' then you will
be limited to devices certified by the USB-IF. If you want to roll your
own USB device, you might want to wrestle control of the policy setting.

The other caveat is that if you want to certify your devices under your
own PKI, then you need 'provisionable' devices. Meaning they support the
provisioning protocol that's in the spec, have enough non volatile storage
and a means to securely hold keys.

I can envisage companies charging extra for 'provisionable devices', even
though the silicon might support it by default. That's the way of things.

The other wrinkle is it might be the silicon that's certified, not the box
it is in. Think about stand alone USB-RS232 chips. They get certified by
the USB and integrator doesn't meddle with the insides.

> Remember SecureBoot...
>

I do.

> You can find many motherboards with SecureBoot
> that have the Microsoft PK's locked in the BIOS. Best
> you can do is 'disable' it and not be 'secure' anymore.
>
> The Linux crowd went apeshit over it, and rightfully so. Then they
> dropped to their knees and wrote silly stub loaders and submitted
> them to their Microsoft Overlord for signing. They are still submitting
> to this scheme today, even though they don't have to...
>
> Because if you look, you can find boards that allow completely
> deleting the Microsoft keys and installing and managing your
> own in the BIOS, and opensource tools to sign and authorize
> your own loaders do exist. Buy those boards instead.
>
> Tech can be useful, but you better fight for, select, and
> maintain your private right and control over it.

I have no argument with that. Again, in the USB context, this is a matter
of devices being provisionable to support your desire to enforce your own
policy. The analogy to the secure boot situation is finding that a USB
vendor had pre provisioned slots above zero and had hard coded a policy
relating to the pre-provisioned slot. Don't buy those devices. The spec
has words to say on not using the auth protocol for vendor lock in, and so
enforcement could happen with the certification process. Whether or not it
will is not something I know. Of course a non certified device could do as
it pleases.