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

Robert Moskowitz <rgm-sec@htt-consult.com> Mon, 24 July 2017 13:23 UTC

Return-Path: <rgm-sec@htt-consult.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F899131CFB for <pkix@ietfa.amsl.com>; Mon, 24 Jul 2017 06:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZsSEy1efAIU for <pkix@ietfa.amsl.com>; Mon, 24 Jul 2017 06:23:16 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C78131D05 for <pkix@ietf.org>; Mon, 24 Jul 2017 06:23:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id D20376215F; Mon, 24 Jul 2017 09:23:15 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03xnbnptBwcR; Mon, 24 Jul 2017 09:23:08 -0400 (EDT)
Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id C5E766219D; Mon, 24 Jul 2017 09:23:07 -0400 (EDT)
To: Anders Rundgren <anders.rundgren.net@gmail.com>, pkix@ietf.org
References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz> <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> <003d01d2ffdd$35d67c70$a1837550$@x500.eu> <d032d03f-6ece-44e1-58b7-e3141f3b8e3d@openca.org> <c66ebeda-21be-93fe-f315-7d1e7f069505@gmail.com> <b474e62e-64d3-5c9f-6dc3-4f96749f5440@free.fr> <f59e8121-7b66-a6bb-2b31-16a1aeaeaf37@gmail.com> <0edcee2d-3dea-bbaa-2cd1-cf3915bfeff7@gmail.com>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Message-ID: <07553cee-882a-74e3-569f-2c501461f2dd@htt-consult.com>
Date: Mon, 24 Jul 2017 09:23:05 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <0edcee2d-3dea-bbaa-2cd1-cf3915bfeff7@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/45VTe2q3yzoppbwcH65RtqNrhv4>
Subject: Re: [pkix] Connected Cars. Upgradable/Replaceable IoT systems. Re: Managing Long-Lived CA certs
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jul 2017 13:23:19 -0000

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
>> pkix@ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>>
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>