Re: [Secdispatch] [lamps] IDevID considerations document to secdispatch

Phillip Hallam-Baker <> Wed, 29 July 2020 15:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66DC33A0C50; Wed, 29 Jul 2020 08:22:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Mv2W-f8giFGv; Wed, 29 Jul 2020 08:22:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 653FB3A0C4A; Wed, 29 Jul 2020 08:22:45 -0700 (PDT)
Received: by with SMTP id k22so21062825oib.0; Wed, 29 Jul 2020 08:22:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mr40i66UCktCJo+VWijBOq4XSC+g1Ln4LvdN+u3LWx0=; b=fsJ+V4yYykTSgOc2he1dZgaDlyuWaZtCGfMzlBEVwST0fmS6CGX5FLXcFm8Uz1XwTh d2z8txa7Bz1mP4BFXt39Flvz/oGrELVeIVC1mwb2H3d6zPK0pO6XCYgkzLAM/j0Nkw9J LatqS/G/qRmRspBoLthVRnvEcR/EikDPMnDZiFUNzlWr3GhEQSHj4gw44hYJDjhfkP5b eYCXE8+WXTLsjFOy6jJDMgrqJHUwWa1XWhUWITKaoKGseS1cocc3snEDFcVmFS10wZ0g JlyUQ94aESci5rfyrTdgArRpyIp5CqizuP/XiTfRYIarSpiyfqG90hRvDGiWg1WbHHlC HCGA==
X-Gm-Message-State: AOAM532GyDrEuga3upKbZmZzSPe/KZnIkAWMOzw2EhCZHCZuy5cuddOr yH+sYHxtlYEY/WpiUgPprY1ZcXEjwev8YYCqYx5WY3doN0s=
X-Google-Smtp-Source: ABdhPJyMmQgQks2TF/CCCCyTCFohfrEoL+FQskarjAGm0tYjMz3Qn8oGu+/OyD2ogb0yUNZdrKzBHPXXfNef2eEstxE=
X-Received: by 2002:aca:fcd2:: with SMTP id a201mr6040989oii.166.1596036164439; Wed, 29 Jul 2020 08:22:44 -0700 (PDT)
MIME-Version: 1.0
References: <> <10463.1591763623@localhost> <13107.1591804306@localhost> <> <5843.1591897975@localhost> <> <20595.1593377487@localhost> <> <22303.1595374300@localhost> <> <19924.1595432391@localhost> <> <19403.1595518388@localhost> <> <15413.1595532896@localhost>
In-Reply-To: <15413.1595532896@localhost>
From: Phillip Hallam-Baker <>
Date: Wed, 29 Jul 2020 11:22:33 -0400
Message-ID: <>
To: Michael Richardson <>
Cc: SPASM <>, IETF SecDispatch <>
Content-Type: multipart/alternative; boundary="000000000000a152e705ab962038"
Archived-At: <>
Subject: Re: [Secdispatch] [lamps] IDevID considerations document to secdispatch
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Jul 2020 15:22:48 -0000

On Thu, Jul 23, 2020 at 3:35 PM Michael Richardson <>

> Phillip Hallam-Baker <> wrote:
>     > Just thought I would weigh in with some points.
> Thank you.
> I don't quite understand how XKMS can be used to provision private keys,
> but
> I do agree that I do agree that the rest is a mess

There is a key provisioning protocol in the spec.

> My goal is to just collect and describe the methods.
> I originally started with the idea of being prescriptive about the shape of
> of the PKI that is used to provision the certificates.  I am pulling back
> from the prescriptive part, and instead I intend to just describe the
> different considerations, giving them names.
>     > There are no good choices for creating key pairs. All have drawbacks.
>     > * Any key generated by the manufacturer can leak at multiple points
> in the
>     > supply chain. But it can be welded to the device in such a way that
> it
>     > cannot be extracted without extreme persuasion.
>     > * Any key that is generated by the device can also be compromised
> through
>     > an intentional side channel or by weak key generation. And once
> generated
>     > can usually be extracted.
> I am interested in why you say that the key can be welded into place
> by the factory, but a key generated internally can't be welded in place in
> the same way.

I have been through a bunch of designs where the manufacturer key can be
replaced by a user one. I don't think they actually add value.

What I am proposing for a threshold co-processor to address SPECTRE,
ROWHAMMER etc. attacks is the following:

Secret key key installed during manufacture are ka, ks

Operation Threshold Agree: P, a, c -> (a.ka+c).P

Operation Threshold Sign: Rin, a, c, m1, m2 -> r.P,  r + H(m1 ||  (r.P+Rin)
|| m2). (a.ks+c)

Such a co-processor should always offer operations on (a.k+c) rather than
just k. This allows the platform to make use of Lagrange/Shamir sharing
approaches and to construct as many virtual application keys as are needed .

Changing the manufacturer key just introduces a point of possible failure
without really achieving anything because the application should always be
adding in its own mix-in.

Unless one is prohibited from using the manufacturer key because of a
doctrine, I can't see why it would be a requirement. The manufacturer key
should never be used except in the process of application key provisioning.
And there the benefit of being able to print a QR Code on the device that
has real meaning probably outweighs that concern.
Doctrines can be a useful tool but we cannot develop specification
responsive to classified doctrines in an open process.

>     > So none of the solutions are good. What should we do? The best
> answer is to
>     > do all of them and combine the keys using threshold techniques. That
> allows
>     > us to get a key that combines all the properties we want and is only
>     > vulnerable if there are multiple failures.
>     > The math is explained in this draft:
>     >
> I would like to include this in my list, but we have a chicken and egg
> situation on it.

There is a NIST program looking at threshold. It is certainly an option
even if IETF isn't supporting it right now.