With due respect, no this is not the same at all. They may provide the same
functionality but the technical implementation is entirely different as are
the security guarantees and the complexity of the TPM module operations. It
appears that we have very different use cases.
The notion of allowing the manufacturer to install updates into any device
I own is abhorrent to me. I come from the process control industry. We
recognize that updates are far more likely to break systems than protect
them. The manufacturer has no idea how my system works. They have not
validated the changes within my system.
If I did want the functionality you suggest, I would do it very
differently. What I am attempting to do is to provide relying parties with
selective manufacturer attested attributes, either directly or mediated via
a Trusted Third Party.
In my model, the manufacturer key is never used as a private key, use is
strictly limited to applying an offset to the user provisioned key.
This greatly simplifies the requirements for the TPM, the TPM does not need
to understand signature formats, certificates, CSRs or anything of the
sort. The TPM can be implemented in pure hardware.
If we are going to be applying formal methods to anything, the first step
is always to reduce the scope of the thing you want to reason about to the
absolute smallest scope possible. In my model, the TPM needs to do nothing
more than a private key operation.
In my model, the CA can disclose as much or as little information from the
manufacturer as required. If I am running a Web server, I might well want
to let browsers know that the private key is device bound, that might in
turn allow for a longer certificate expiry or the like. I almost certainly
do not want to reveal the precise model and manufacturer of my hardware.
If desired in specific circumstances, I can of course provide the full
attestation. But the point is, this is an option.
What I have invented here is a different thing with different properties.
My approach uses an entirely stock TLS library with no changes to the TLS
layer at all. The only place where any changes happen are in forming the
CSR sent to the CA and processing the certificate by the application when
it decides whether to accept it. And that is limited to looking for an
extension.
I never said that nobody had provided the same functionality before, what I
said is that I found the existing approaches to be overly complex.
On Mon, Mar 17, 2025 at 10:37 AM Russ Housley <hous...@vigilsec.com> wrote:
> 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
>
>
>
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
