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
