Re: Connected Cars. Upgradable/Replaceable IoT systems. Re: Managing Long-Lived CA certs

I have consulted a few auto OEMs on matters like this.

Today, and actually for a few years, all devices with software MUST be 
field (minimum dealer) upgradeable.  And some support 'over the air' 
updates.

This includes the 'telematics' control unit where up to now, has been 
the only component with certificates.  I worked on three telematics 
certificate systems.

The IEEE 1609.2 standard for Vehicle safety messaging has a 'monster' 
PKI with certificate management.  To put it mildly.

However, IEEE 802.1AR 'Device Identity' standard defines the iDevID as a 
permanent, non-mutable certificate with expected 10 - 20 year life.  
Yeah lots of issues with this.  Lots of reasons for this approach.  Note 
that the iDevID is only used for proof on manufacturer identity when 
enrolling in the buyer's PKI with the lDevID (see ANIMA that is using 
these).   It may also be used in firmware updates from the 
manufacturer.  Thus the iDevID is not intended to be an 'operational' 
certifcate.

Further note that 802.1AR certificates MAY be a major player in the 
future (perhaps as early as 2019 vehicles) Automotive Ethernet sensor 
networks (as may 802.1AE mac security).

Bob


On 07/21/2017 01:01 AM, Anders Rundgren wrote:
> My guess is that 10-15Y+ old connected cars won't be permitted on 
> public roads unless they are upgraded.
> Upgrading really old cars will become a major task since the 
> electronics is unlikely to actually be upgradable.
>
> Anders
>
> On 2017-07-21 05:23, Anders Rundgren wrote:
>> Hi,
>>
>> It is not uncommon that there are more than one imaginable solution 
>> to a problem.
>>
>> In this case there is an obvious alternative to what is proposed.
>> Assume that a system * in some way becomes obsolete.
>>
>> If such a system represents a considerable investment AND needs to 
>> live for decades, it should be upgradable.
>>
>> If OTOH the system is not upgradable, it should be replaced.
>>
>> If an IoT device only supports outdated algorithms it is anyway 
>> vulnerable to attacks making workarounds on the CA side fairly useless.
>>
>> BTW, who in their right mind would run a CA with compromised keys or 
>> a CA for obsolete devices?
>>
>> Anders
>> * System in this context involves the entire infrastructure, 
>> including possible CAs.
>>
>>> Hi PKIX,
>>>
>>> I have a small question for the list regarding long-lived CA
>>> certificates. Especially in the context of device certificates, we 
>>> often
>>> see the use of extra long-lived certificates for Root and Sub CAs 
>>> (e.g.,
>>> 35+ years) combined with limited key sizes (e.g., p256).
>>>
>>> Until we have a supported mechanism for reprovisioning devices (...),
>>> one possible solution for limiting the exposure of the private key 
>>> would
>>> be to have a scoped certificate issuance period.
>>>
>>> What I am thinking about would be adding an extension that says: "This
>>> CA can issue certificates from up to 5 years from the validFrom, after
>>> this, just use it to provide revocation information". This might 
>>> provide
>>> some protection in case the CA key is compromised after the initial 5
>>> years of validity (e.g., certificates issued after that date shall be
>>> rejected).
>>>
>>> Does such extension exists today ? If not, could this be some work for
>>> LAMPS/SPASM WG ?
>>
>>
>>
>> _______________________________________________
>> pkix mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/pkix
>>
>
> _______________________________________________
> pkix mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pkix
>

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix