3 ms·
> in the absence of that it's legitimate for the issuer to assume that when the client asserts that a key was generated in hardware that it was telling the trut
by nybble41 5y ago
> in the absence of that it's legitimate for the issuer to assume that when the client asserts that a key was generated in hardware that it was telling the truth
You want the credentials to be non-extractable. The client wants to extract the credentials and use them somewhere else. Blind trust in an unsupported assertion from a client with diametrically opposing goals is not much of a security model.
- mjg59 5y agoI'm not the service owner. I care about credentials on my clients being hardware backed, and I have enough control over the platform to have reasonable confidence that they'll make a truthful assertion. Clients managed by other people may have different priorities, and should be able to make their own decisions.
- nybble41 5y agoIf you control the clients then there is no need to assert anything, truthful or otherwise. Go ahead and store the keys in a TPM if you want—the server has no reason to know or care about that. This does not require any key attestation.
- mjg59 5y agoYou're the one who claimed this approach required remote attestation, not me?
- nybble41 5y agoIf the service wants to make sure the keys can't be copied then it will need remote attestation for either the whole system or just the TPM (what you called "key attestation") to ensure that the client isn't cheating. If it's only the client that doesn't want the keys to be copied they have any number of options for that and no attestation is needed. I assumed your article was promoting the former as the latter really isn't interesting at all.