4 ms·

That approach requires remote attestation (or you can't trust the TPM / secure enclave), which is far too much to ask unless you actually own the device being u

That approach requires remote attestation (or you can't trust the TPM / secure enclave), which is far too much to ask unless you actually own the device being used to access the service.

Sirened 5y ago
100%! As a _user_ I personally would love if I could store all my session authentication info in my device's TPM/SEP for my own safety. I do this with my SSH keys for specifically the reason you suggest—I like that my private keys are non-exportable and so installing a public key on a server is a solid authentication for one device and one device only. This, however, only establishes trust on _my_ end. My SSH servers cannot know or trust that my keys are well guarded because, for all they know, I have a crumby TPM and/or store them unencrypted in my .ssh folder. You cannot make a trust decision based on TPM storage because you have no idea what the TPM actually did (or if aforesaid TPM even _exists_ at all) unless you require remote attestation, which is both non-portable, non-free, and requires you support only users who have a specific variety of CPU.
- mjg59 5y ago
  https://github.com/google/go-attestation https://github.com/google/go-attestation is a free implementation of remote attestation that's not associated with any CPU type and will work on anything that has a TPM. But what we want here isn't really remote attestation (which implies attesting to the overall state of the device), it's key attestation (where you verify that the key was generated on a legitimate TPM). But there's still a legitimate privacy concern, in that the attestation is still rooted in an immutable key that would allow anyone who performed key attestation with you to associate your identity with a specific computer.
  - nybble41 5y ago
    > key attestation (where you verify that the key was generated on a legitimate TPM) This is the same problem, just one level further down. The scheme depends on hardware acting against the desires of its owner—whether we're talking about the entire system or just the TPM portion. The privacy concerns are real but not the full extent of the problem.
mjg59 5y ago
The credential issuer is (in general) not in a position to make a determination whether the device is trustworthy or not. In an ideal world, I (the person responsible for the security of the device) would be able to ask the issuer to delegate that decision to me (which is what we want for a full ZTA experience), but 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.
- 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 ago
    I'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 ago
      If 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 ago
        You're the one who claimed this approach required remote attestation, not me?

That approach requires remote attestation (or you can't trust the TPM / secure enclave), which is far too much to ask unless you actually own the device being used to access the service.

Sirened 5y ago

100%! As a _user_ I personally would love if I could store all my session authentication info in my device's TPM/SEP for my own safety. I do this with my SSH keys for specifically the reason you suggest—I like that my private keys are non-exportable and so installing a public key on a server is a solid authentication for one device and one device only. This, however, only establishes trust on _my_ end. My SSH servers cannot know or trust that my keys are well guarded because, for all they know, I have a crumby TPM and/or store them unencrypted in my .ssh folder. You cannot make a trust decision based on TPM storage because you have no idea what the TPM actually did (or if aforesaid TPM even _exists_ at all) unless you require remote attestation, which is both non-portable, non-free, and requires you support only users who have a specific variety of CPU.

mjg59 5y ago
https://github.com/google/go-attestation https://github.com/google/go-attestation is a free implementation of remote attestation that's not associated with any CPU type and will work on anything that has a TPM. But what we want here isn't really remote attestation (which implies attesting to the overall state of the device), it's key attestation (where you verify that the key was generated on a legitimate TPM). But there's still a legitimate privacy concern, in that the attestation is still rooted in an immutable key that would allow anyone who performed key attestation with you to associate your identity with a specific computer.
- nybble41 5y ago
  > key attestation (where you verify that the key was generated on a legitimate TPM) This is the same problem, just one level further down. The scheme depends on hardware acting against the desires of its owner—whether we're talking about the entire system or just the TPM portion. The privacy concerns are real but not the full extent of the problem.

mjg59 5y ago

The credential issuer is (in general) not in a position to make a determination whether the device is trustworthy or not. In an ideal world, I (the person responsible for the security of the device) would be able to ask the issuer to delegate that decision to me (which is what we want for a full ZTA experience), but 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.

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 ago
  I'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 ago
    If 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 ago
      You're the one who claimed this approach required remote attestation, not me?