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

Erwann Abalea <> Mon, 24 July 2017 16:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE31F131E85 for <>; Mon, 24 Jul 2017 09:17:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PloyT-666hAC for <>; Mon, 24 Jul 2017 09:17:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7145131E7B for <>; Mon, 24 Jul 2017 09:17:43 -0700 (PDT)
Received: by with SMTP id d145so47580386qkc.2 for <>; Mon, 24 Jul 2017 09:17:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BrKthAGajqCypHsuNvHXv8eBUTzhdgk1wuxN0/Kwi9I=; b=kAbbz0lRV2UrSNhcLqewaCqCZtFN8sbMcGtuU3fDFmghbfF/wb7VlPhdTJimacqnhP YuWe2K0gMvK1auRKr//BWwsFIAkdB8aI+/hooiwow82z3qv8KWhtOju/4nv2l46eGYBq zvjCmCVA4ck3GAfkR99otWDvTQFXmAe7lbqbqirMT6xGfv/M/r96Q1fHeTP5c1cn59kH Y4HlZYHSFNjkYzBiC/AoahnAVFeG4tQZ/MwEyn2qqKAUyhyF07u5VumrERxuJsdubyyS eMon0+bnbuRZww0R8g/nK6pUBuXDmQZsJjmla6KkhEqU8nmYoyoM2MT4lftSMtl4H3aE 9gKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BrKthAGajqCypHsuNvHXv8eBUTzhdgk1wuxN0/Kwi9I=; b=hCBvtG6NZXo8fK13cfQiV+B7r/VJw0AXIMT7yeDSnlyZFUI30/r3xSDfyVthy++Eoo Lhv+FYr9ELaaHvv3uhkumebjbqNOzwRR/pswjKppa0+wD+s2VlhsDkJaUlOXZWBmSg4t vcZvaF3XYR+JykidFnn8E92i95Figphoctyueyflf59fg59/xmIEf0kpqbOf6453ZA7r ZtnpM7KNRVwsG2Bh2IK8ujsc4Fv+4iCyaxqGkoYQN3SscESlxf/Ay35CCbHo2dDI0Slf RKj/mseMldh6oWfCxoMZ6zArCRLvRBYb57i/gaUKQEYmeKC9/OAnho9nOiMPmDi12yCO jAYg==
X-Gm-Message-State: AIVw111QQGZoz2CbcJXm3dxbwtIfQPaH2zdUHKowyrMi9kMLsrFgnmzz SwfWWWUs6qgfmN5J4rzSHNCckG7WBZq6
X-Received: by with SMTP id g128mr19473254qkc.166.1500913062845; Mon, 24 Jul 2017 09:17:42 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 24 Jul 2017 09:17:41 -0700 (PDT)
In-Reply-To: <>
References: <> <001501d2ff0e$00eddfa0$02c99ee0$> <> <> <003d01d2ffdd$35d67c70$a1837550$> <> <> <> <> <> <>
From: Erwann Abalea <>
Date: Mon, 24 Jul 2017 18:17:41 +0200
Message-ID: <>
To: Robert Moskowitz <>
Cc: Anders Rundgren <>, "<>" <>
Content-Type: multipart/alternative; boundary="001a114fe738f320520555128dca"
Archived-At: <>
Subject: Re: [pkix] Connected Cars. Upgradable/Replaceable IoT systems. Re: Managing Long-Lived CA certs
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Jul 2017 16:17:46 -0000

2017-07-24 15:23 GMT+02:00 Robert Moskowitz <>om>:

> 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.

That's right. This long-term ID is used to get short-term IDs that are
changed frequently and used to sign messages (CAM and DENM at least).

Having worked on the ETSI counterpart of 1609.2, the expected figures are:
around 1500 short-term IDs per vehicle and per year, CAMs are to be
sent+signed between 1 and 10 times per second (depending on environment and
network status).

ETSI also wanted to have their own autoconfigurable network, in which
network addresses contain GPS coordinates, some messages specify the
intended network coverage, and every vehicle can act as a mobile router.
And all messages are to be signed, by one of these short-term IDs.

Reason for a new certificate format: reduce the size of network packets to
limit the congestion; ETSI adds a congestion control layer that doesn't
exist in 1609.x, limiting in-air messages to 0.6s, whatever the current
rate (which is also negotiable).
Reason for that many certificates: try to forbid an attacker to passively
track a vehicle's path. Privacy, in fact.

Revocation of these short-term IDs is somewhat defined in 1609.2, not at
all in ETSI (that may change).