Phill: This is really a description of IDevID certificates that are installed by a factory, and then replaced by LDevID certificates that are issed by the device owner at the time of installation. NETCONF already supports that model.What am I missing?
Russ
> On Mar 16, 2025, at 11:31 PM, Phillip Hallam-Baker <ph...@hallambaker.com>
> wrote:
>
> A common requirement in device security is to know that a key is bound to a
> device with some degree of hardware assurance such that the key can be used
> on the device but not extracted from it.
>
> FIPS-140 specifies a set of assurance levels but there is value in even the
> lightest of lightweight assurance levels. By far the largest risk of key
> disclosure comes from administrative error, backing up the private key file
> in plaintext, selling a host machine on EBay without wiping the disks, etc.
> etc. Yes, Kocher side channel attacks are important if you are going to do it
> right but the bar to measurable improvement in security turns out to be
> really really low.
>
> So what if we could add a means of attesting that a key that the manufacturer
> of the device has absolutely no knowledge of is bound to a device that is
> completely compatible with SSL/1.0 thru TLS/1.3? No protocol changes needed.
> The only change comes in the key generation step and the manner in which the
> hardware key is used.
>
>
> Step 1: Device generation
>
> Manufacturer generates an ECC private key pair {x.P, x} and an assertion
> A(x.P) that the private key corresponding to x.P is bound to the device
> accredited under the trust chain of your choice.
>
> This assertion does not expire. The manufacturer has absolutely no
> involvement in the protocol after the device ships.
>
>
> Step 2: Key generation
>
> Since Alice does not trust the manufacturer at all or in any degree, Alice is
> going to generate her own keypair {y.P, y}.
>
> Alice also generates P(x.P, y.P) a proof of possession for y consisting of
> Sig (x.P, y)
>
>
> Step 3: Certificate request
>
> A certificate request is generated for the public key z.P = x.P + y.P with an
> attestation section containing A(x.P) and P(x.P, y.P)
>
> The CA verifies that z.P is consistent with the claims specified in A(x.P)
> and P(x.P, y.P), if the check succeeds, the CA adds an extension to the cert
> saying the key is dependent on the bound key x.P.
>
> [Alternatively, the extension can specify A(x.P) and P(x.P, y.P) allowing
> endpoints to do the validation, this can be achieved either directly or
> through a self validating URI such as an EARL.]
>
>
> Step 4: Performing TLS (or other protocol)
>
> Key operations involving x have to be submitted to whatever security module
> holds x. This API is extended to support the operation Sign (Data, keyID,
> offset), the caller specifies Sign (Data, "boundKey", y)
>
> This is not a threshold signature protocol, it is a threshold key protocol
> where the key produced by adding x+y is used for signature. So we don't have
> to worry about all the 'concurrency' issues to do with combining the results
> of two signature operations. There is a single signature operation occurring
> but under a key that is not known to either the manufacturer or the user.
>
>
> Impact
>
> This approach is completely backwards compatible. An attested TLS certificate
> works in every circumstance that legacy certificates work with absolutely no
> protocol changes. The only difference in use is that a relying party that
> requires the attestation can see it in the certificate.
>
> The Manufacturer is required to do the attestation bit but their involvement
> is minimal, they have to develop some sort of secure enclave and provide an
> api to use the key with a user specified offset.
>
> The Key Generation app used by the client needs to be slightly modified but
> this is minimal
>
> The CA needs to do some additional validation checks but these are easy to
> specify and enforce.
>
> The TLS library doesn't need to change very much beyond being able to present
> a private key to a crypto provider. This might fit into existing plug and
> play crypto schemes or it might not. This is something that is fixable and
> should be fixed.
>
> The big win for security is that disclosure of the private key y doesn't lead
> to a breach unless the manufacturer also suffers a breach. The value y can be
> stored unencrypted.
>
>
> Key Rollover
>
> Yup, the device bound key never changes. We can spin up a new y as many times
> as we like but x never changes. Nor is there any value in changing it. Any
> mechanism you try to construct for rolling over the bound key is going to
> increase rather than decrease attack surface. Yes, I am aware that you could
> put in place a route for rollover of the bound key via the manufacturer
> but... just no, not needed, not useful.
>
>
> Post Quantum
>
> Yup, depends on ECC so if you want PQC as well, you would need to have a
> hybrid config until someone works out how to do threshold securely in PQC.
> Yes, I can do threshold in ML-KEM, I can also break that scheme.
>
>
> Draft
>
> Will spin up the draft when I get home. My MacBook is refusing to run my
> dotNET code for my Word->XML2RFC converter. Anyone know how to bypass the
> malware protection checks?
>
>
> Patents
>
> Yeah, probably covered by prior art I disclosed in the Mesh documents and in
> public presentations many years back. I am not intending to make a claim. If
> someone does, please remember who provides relevant expert witness services...
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
