I’m trying to make notes about the TPM and what it does. More specifically I’m looking at the 3 RSA key pairs: the ‘endorsement key’, the ‘storage root key’ and the ‘attestation identity key’.
This is what I have written so far:
The ‘Endorsement Key’ is an RSA key pair where any data sent to another device is encrypted using the private key and the receiving device decrypts it with the public key, so it knows the data is trusted. This is created when the TPM is manufactured (not user-specific)
The ‘Storage Root Key’ is a pair of RSA keys within the TPM and is used to protect TPM protected keys created by applications and stored outside of the TPM, so that these keys cannot be used without the TPM. It’s created when you take ownership of the TPM (If user changes so does the key)
However, I am now trying to research the use of the attestation identity key but don’t understand how it is different from the endorsement key? If anyone could explain in simple terms because this is all new to me I would greatly appreciate it 🙂
I need to know how to seal data for example in platform A, according to some values of PCR, and them, send the seal data to a platformB, this platform get the data and do an unseal to get the information.
I see the information of the tpm2 however, i dont know how to do thath because in every example use the EK (tpm2_createprimary) to seal the data.
It seems that the therm “Local attestation” is usually used to refer an attestation conducted within an Intel environment. While the therm remote attestation is widely used with a big range of platforms.
- Does the local attestation has some architectural requirements?
- When is the local attestation is valuable?
- Can the concept local attestation be deployed in environments other than Intel?
DAA (Direct Anonymous Attestation) is not the only scheme to achieve anonymous attestation. In general, these schemes allow an entity to stay anonymous throughout the attestation process. The concern here is not the attestation but key revocation. TPM/FIDO DAA scheme requires to keep a rogue list of compromised private keys to make revocation possible. But the assumption of compromised device will have its private key leaked publicly is naïve. In fact in many scenarios, a hacker may not reveal a compromised key. Such key can be used for attack such as denial of service attack etc… Since device identity is anonymous to service provider, there is no way for service provider to differentiate an attacker from genuine user.
What making it worse is having the private key stored/protected using hardware key store or HSM (Hardware Security Module). A hacker may have the knowledge to hack and extract the private key from a HSM using zero-day vulnerability. Since private key is designed not to output private key in plain. Therefore, even if a user acknowledge his device is compromised, but there is no way for him to inform the authority since it is not possible to extract the private key as a normal user.
Therefore, DAA sound like a wonderful technology but is not commercially viable?
I am reading on digital signatures:
A valid digital signature gives a recipient reason to believe that the message was created by a known sender (authentication), that the sender cannot deny having sent the message (nonrepudiation), and that the message was not altered in transit (integrity).
I’m using for 2FA a hardware key (e.g. Yubikey, Key-id) to authenticate a user with Webauthn and also later require user’s confirmation to take certain sensitive actions.
Question: if I store on the server the challenge and the AuthenticatorAttestationObject returned by the hardware key, can that serve for non-repudiation?
Rephrase: can the user claim that an action that required pressing the Yubikey button was not initiated by him, but was fabricated e.g. from server side?
What’s the exact difference between secure boot and device attestation. Nowadays with secure devices both are used, even at the same time, when in the core they do similar things, which is verification of the software running on the platform.