Subject: [Iotops] maintain ownership (was: can we create protocols that securely transfer ownership?)

From: Toerless Eckert <[email-masked]>
Date: Tue, 3 Nov 2020 20:10:05 +0100

Thanks, Qin

Cross-posting to anima, because i think these discussions apply to any type
of (physical) device level certificate wrt. ownership:

Most IDevID in TPMs can not be renewed, so they either have infinite lifetime,
or the device is preordained trash when the certificate expires. 

The security problem you are pointing to is called key exhaustion, aka: it
does not come from the lifetime, but from how often you use it. One
simple way to solve this is not to use such infinite lifetime certs often.
This is true for IDevIDs unless you start to do bad protocols that use them
often.

One simple way IMHO to solve this problem is to make the infinite lifetime
certs a local CA and use it to periodically generate new local cert(s) that
you use actively. Increases amount of data for cert-chain signaling required though.

Wrt. overwriting existing certs: i was just giving an example. Agree that there
are various options.

Cheers
    Toerless

On Tue, Nov 03, 2020 at 01:32:29PM +0000, Qin Wu wrote:
> [Qin]: Not sure lifetime long certs is a good idea. I feel it is more vulnerable.
> Also I think the current cert doesn't need to be overwritten by cert of the new owner.
> The current Cert can be embedded in the Cert of new owner, see delegation voucher
> https://tools.ietf.org/html/draft-richardson-anima-voucher-delegation-02
> when the device is in resale, wrong?
> 
> JUst a line of thoughts.
> 
> On Sat, Oct 31, 2020 at 08:58:27AM +1300, Brian E Carpenter wrote:
> > On 31-Oct-20 06:25, Michael Richardson wrote:
> > >
> > > Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:
> > >     > Yes, in addition to being a good story, the point is who controls the
> > >     > firmware in our things, and how bad it can get not only when the
> > >     > manufacturer enforces DRM, but the gov't enables the behavior
> > >     > (criminalizing jailbreaking).
> > >
> > >     > Or the issues that arise when the manufacturer fails to properly maintain
> > >     > the firmware, or goes out of business.
> > >
> > > All major concerns.  What do you think the IETF can/should do?
> > > I have some very specific ideas which I think are manageable and specific.
> >
> > Both BRSKI and SUIT have minor references to the latter problem, and I
> > think that when considering tiny cheap devices it isn't a theoretical issue,
> > but one that's highly likely. There is also (as for incandescent light
> > bulbs) a strong incentive for manufacturers to sell devices that are
> > designed to break after a while. An expiring certificate would be a great
> > way to break devices remotely, for example.
> 
> Indeed, before even thinking about transferring ownership i would to see what
> IETF security community can do to remove the current problem of even just
> MAINTAINING OWNERSHIP in face of (if i am not mistaken) current PKI
> recommendations:
> 
> My TivoHD for example had its certificate expire few years into its lifetime,
> even though i had upfront bought a so-called "lifetime service" for it.
> Of course, the lifetime-service did not include "maintaining a current cert for the
> lifetime of the device".
> 
> And that is just the most egregious example i ran across because of me having
> to learn how to hack up all the software that was talking to the TiVo via
> TLS - to ignore the expired cert.
> 
> I am saying the IETF is partially to blame because i think we also proliferate
> the notion that certificates have to be renewed periodically with maximum
> usual lifetimes of now i think one year ? (was two years)
> 
> Of course, this is specifically a consumer-IoT problem, because industrial
> customers should typically be in a stronger position to avoid these vendor
> abuse of principally sound technical guidance.
> 
> As much as i like to explore short lived certificates more in environments
> where i can set up the right environment to support that, we should IMHO
> also think about the simplicity of lifetime-long-certificates. Which we
> currently do not have in web PKI.
> 
> The fact alone that we do only have in browsers one single TA space (Internet)
> seems to be the worst offender, proliferated by the fact that that is the
> only domain that most big contributors in the IETF are interested in.
> Nevertheless, to support what we classically did without crypto, namely
> private networks (with private addresses), we should also have a crypto
> strategy for such private networks. And in most cases, lifetime-long certs
> will be the only reasonable solution there.
> 
> But, and to get back to the topic: One way on how to get to lifetime-long
> certs would be an actual transfer of ownership from whaever the vendor
> put in as certs to a cert from the current owner and using a lifelong
> expiry time (e.g.: infinite). This could be hosted in a private TA.
> The question is primarily how to have browsers support different TA
> domains without confusing the user.
> 
> And of course, when you sell the device, you would need to do transfer
> of ownership again by overwriting the current cert with one of the
> new owner.
> [Qin]: Not sure lifetime long certs is a good idea. I feel it is more vulnerable.
> Also I think the current cert doesn't need to be overwritten by cert of the new owner.
> The current Cert can be embedded in the Cert of new owner, see delegation voucher
> https://tools.ietf.org/html/draft-richardson-anima-voucher-delegation-02
> when the device is in resale, wrong?
> 
> JUst a line of thoughts.
> 
> Cheers
>     Toerless
> 
> -- 
> Iotops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iotops

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Nov 2020 14:17:46 -0500

> you use actively. Increases amount of data for cert-chain signaling required though.

There is another (new) way which doesn't use the term "CA", which risks
visits from lawyers:

https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/

Delegated Credentials for TLS
draft-ietf-tls-subcerts-09
Abstract
   The organizational separation between the operator of a TLS endpoint
   and the certification authority can create limitations.  For example,
   the lifetime of certificates, how they may be used, and the
   algorithms they support are ultimately determined by the
   certification authority.  This document describes a mechanism by
   which operators may delegate their own credentials for use in TLS,
   without breaking compatibility with peers that do not support this
   specification.

Also: STIR Certificate Delegation
draft-ietf-stir-cert-delegation-03
Abstract
   The Secure Telephone Identity Revisited (STIR) certificate profile
   provides a way to attest authority over telephone numbers and related
   identifiers for the purpose of preventing telephone number spoofing.
   This specification details how that authority can be delegated from a
   parent certificate to a subordinate certificate.  This supports a
   number of use cases, including those where service providers grant
   credentials to enterprises or other customers capable of signing
   calls with STIR.

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