Introduction
The number of information technologies, such as IoT devices and mobile Internet, are rising and therefore also the need for trustworthy computing environments. The digital community is seeing more and more threats to their secret information, threats such as computer viruses and malware. Any company or individual with sensitive information will want to be able to keep it in a secure environment that preserves the integrity, authenticity, confidentiality and reliability of the data. Not only does the information need to be secure in an individual server but will need to travel through trusted channels. While firewalls and virus defense mostly protect the server side of a computing platform, the client side is vulnerable, which is where trusted computing comes in.
There are many organizations that have attempted to establish a standard definition for trusted computing, but there are many different ways of understanding a trustworthy environment. The Trusted Computing Group (TCG) presented a solution where a security module is placed into the hardware platform in order to increase the security of the system. This is known as the Trusted Platform Module (TPM). Although, this solution of improving computer architecture by incorporating a trusted computing chip into the hardware has already been used since the 1990s, the need for enhancements is growing.
The main goals of trusted computing are to establish a trustworthy transfer system, secure platform, and a solution to the trust problem between man and program, man and computer, man and man, that can provide evidence of its state of execution. First, a trust is established within a terminal platform, which is done by building a chain of trust. A chain of trust focuses mainly on OS measurements, where TCG had suggested using TPM as root of trust as a method to build measurement systems. The concept of a chain of trust for terminals can be extended from local platforms to remote platforms, which is called remote attestation.
Remote attestation is considered one of the most important parts of trusted computing, because it can attest the trusted computing platform’s hardware, firmware and software. Remote attestation can attest many identities at once and satisfies the users’ security requirements in some of the following ways:
1. Help determine if the trusted computing capabilities of the computing platform can be trusted in communication.
2. Help detect the integrity of the platform configuration and the input and output of the software running on the platform.
3. Help verify if the platform configuration is in accordance with the verifier security policy.
The TPM provides the advanced security service of remote attestation and needs additional support from the basic functions of the system, such as integrity measurements. What to attest is solved by the integrity measurements and how to attest is found with the TPM identity keys.
The TPM has a Root of Trust for Measurement (RTM), which is the starting point for the integrity measurement, and goes on to acquire the characteristic values of trust degree for the software and hardware platforms. Everything from BIOS to applications will be measured for integrity by the trusted computing platform and the TPM. The characteristic will be obtained from this and hash values will be created and stored. By doing this process, the integrity states of the hardware and software modules’ executions are recorded and will proceed to build a chain of trust. If any value has been changed by malware, the hash value will be affected and the problem can be detected.
There are seven keys that the TPM supports:
1. Signing key
2. Storage key
3. Identity key
4. Endorsement key (EK)
5. Binding key
6. Migratable key
7. Certified key
Although, remote attestation can only use the platform identity key (PIK). This key is also called the attestation identity key (AIK) in the TPM specifications. PIK is an elliptic curve cryptology key, while AIK is an RSA key. For other aspects of these two key types, they are the same.
Remote Attestation Protocol
There are a few key terms that are important to define for a better understanding of the remote attestation protocol:
1. Prover: The platform/client/device that is trying to prove its identity to a challenger
2. Challenger: The platform/server that is challenging the identity of prover
3. Trusted-Third Party: A third-party verifier that assists the challenger/prover in the attestation process. This verifier is usually a private Certificate Authority (CA).
The TPM implements primitive cryptographic functions upon which more complex functions, i.e. remote attestation, can be built on. The TPM is responsible for:
1. Performing public key cryptographic operations
2. Computing hash functions
3. Key management and generation
4. Secure storage of keys and other secret data
5. Random number generation
6. Integrity measurement
7. Attestation
The combination of these functionalities provide the backbone for remote attestation. Each TPM is given a public/private key (i.e. AIK) built into the hardware which is provided by a trusted third-party (TTP) Certificate Authority (CA).
The key element to the remote attestation protocol is the process of integrity measurement. Integrity measurement is a way to ascertain information about the hardware, software, or firmware that runs on a trusted computing platform. At load-time or run-time, the TPM uses a hash function to fingerprint an application, a set of files, or an application with its input as a way to establish the code identity for the challenger. Measurement can also be done on the hardware, firmware, operating system, or any piece of code/data across the software stack that requires attestation.
The remote attestation protocol uses these measurements of integrity to allow the challenger to verify the identity of the prover. The three main actors in the protocol described below are the prover (called the trusted computing platform in the Figure), the challenger (the remote verifier), and the TTP.
There are two main steps that take place for remote attestation to work: issuing a platform identity to the prover and then platform identity attestation.
Issuing a platform identity
When a new device is bought, the TPM chip does not have an identity and must be issued one by a TTP. The TTP provides a platform identity certificate and also verifies the AIK to allow for successful attestation.
1. The TPM chip on the prover machine generates a public/private key which is the Attestation Identity Key (AIK). The AIK is the key that the challenger uses to verify the identity of the prover. After generating the key, the prover wraps the public key of AIK, the EK certificate, the conformance certificate, and the platform certificate into one object.
2. The prover then sends this wrapped object to the TTP for an approved certificate that verifies the AIK of the TPM chip.
3. The TTP will then verify the application for the AIK certificate using the public key of AIK, the EK certificate and the platform certificate.
4. The TTP signs the AIK certificate with its own key and encrypts it using the EK public key.
5. The TTP then sends the verified AIK certificate to the TPM chip on the prover. The TPM chip will decrypt the certificate to obtain the unencrypted version of the AIK certificate.
At this point, the TPM chip has a verified AIK certificate that can be used for remote attestation.
Attestation of Platform identity
1. The prover (Platform A) sends a request for attestation to the challenger (Platform B).
2. The challenger then sends a request with a challenge nonce and specific integrity measurements of interest.
3. The prover then takes the AIK from the TPM chip and signs the integrity measurements with the private AIK.
4. The prover sends the certificate created in Step 3 and additional logs to prove the integrity of the device to the challenger.
5. The challenger then requests the TTP for verification about the identity of the prover. The requested information is relayed back to the challenger.
6. If the prover is trusted by the TTP, the challenger then verifies the integrity measurements and additional logs provided by the prover.
This model of remote attestation achieves both the ability to authenticate the prover’s identity as well as assess the trustworthiness of the environment that is running on the prover’s machine. Since both the prover and challenger use the TTP for authentication of the prover, only the TTP knows the identity of the prover, not the challenger. Although this does increase the level of privacy from the perspective of the prover, it does not completely provide anonymity. To deal with this problem, the Direct Anonymous Attestation (DAA) scheme was proposed.
Direct Anonymous Attestation
The direct anonymous attestation (DAA) scheme relies on zero-knowledge proofs, group signatures, and other cryptographic functions to anonymously attest platform identity. In other words, DAA does not rely on a TTP to provide proof of a prover’s identity. This provides two benefits:
1. If the challenger and the TTP collude, the identity of the prover and TPM chip residing on it are at risk.
2. Since a TPM chip can theoretically generate an infinite amount of AIKs and certificates, the verification process between the prover and the TTP is a major bottleneck.
The DAA scheme relies on the idea that the challenger does not know the identity of the TPM chip but instead identifies the chip using an alias - the DAA key. Using this mechanism, the prover’s identity is concealed yet allows attestation to proceed as expected.
The protocol divides the identity from the alias by storing the private key f in the internal memory of the TPM chip and cannot be exported. The DAA key can be stored outside of the chip somewhere within the prover’s device or in other storage devices. The DAA procedure has four main steps:
1. Setup: The issuer generates a public/private key pair that will be used to sign the anonymous credentials.
2. DAA join: The TPM chip sends the application request which includes the DAA key, public key of the TPM chip, and some sort of key to prove that the computation was sound. The issuer then sends back an anonymous credential that authenticates the alias of the prover.
3. DAA sign: The TPM chip then uses the anonymous credential and the secret key f to create a DAA signature.
4. Verify: The prover sends the DAA signature to the challenger. The challenger verifies the DAA signature through some computation and checks to see if the TPM chip has already been revoked.
As the above procedure shows, the challenger nor the issuer is able to correlate the DAA key with the AIKs of a TPM chip.
The DAA protocol is supported in v1.2 of the TPM specification.
Attacks on Remote Attestation
This section will briefly discuss some attacks that can be performed during the remote attestation process. Remote attestation is vulnerable to:
1. Replay attacks: A malicious device that replay old integrity measurements that correspond to a valid platform.
2. Tampering: An attacker may be able to change the integrity measurements on the prover’s device.
3. Hardware attacks: An attacker can change the data structures that store integrity measurements or break into the TPM chip to retrieve the private AIK
4. Masquerading: An attacker can send integrity measurements of another valid system as a way to then be verified by a challenger.
5. Malicious measurement agent: An attacker can report incorrect integrity values
A study done by students at Stanford created a new remote attestation protocol that is built on top of the SSL/TLS handshake protocol to mitigate these kinds of attacks.
The protocol, as described in the paper, follows these steps:
1. The prover (C) sends a nonce along with its identity to the challenger - this is similar to the client hello message in the SSL/TLS protocol.
2. The challenger (S) sends a nonce back along with a signed certificate from a CA to prove its identity - this is similar to the server hello message in the SSL/TLS protocol.
3. The prover then sends three objects to the challenger:
a. The prover sends a signed certificate using the public key of the challenger encapsulating the integrity measurements and the secret session key.
b. It also sends a signed certificate encapsulating the AIK of the TPM chip provided by the TTP.
c. The prover also sends a signed certificate using the private AIK encapsulating the hash of the nonces from Step 1 and 2 as well as the secret session key. This packet also includes a structure to validate the integrity measurements.
4. The challenger validates the AIK certificate and also verifies of the integrity measurements.
5. If the prover passes the integrity checks, the two devices continue to send messages as described in the SSL/TLS protocol.
Using this model, this version of the remote attestation protocol is secure against the threats described above. The paper uses the Murphi model, a finite-state machine, to evaluate the threat model.
Conclusion
Trusted computing and remote attestations provide the means for secure verification of device identities. As the market for IoT devices grow, the more important remote attestation becomes. As we describe in this blog, remote attestation has gone through a lot of changes from relying on trust to using anonymous identities to maintain privacy. More recent research look at variants of the protocol that use secure protocols such as SSL/TLS or rely purely on hardware instead of a TPM chip for attestation. These variants are crucial to furthering the science of remote attestation - a crucial component of trusted computing as well as secure communications.
References
1. https://learning.oreilly.com/library/view/trusted-computing/9783110476095/content/14_chapter07_1.xhtml#chapter07_1_1
2. https://seclab.stanford.edu/pcl/cs259/projects/cs259_final_lavina_jayesh/CS259_report_lavina_jayesh.pdf
3. https://courses.cs.washington.edu/courses/csep590/06wi/finalprojects/bare.pdf
4. https://web.cs.wpi.edu/~guttman/pubs/good_attest.pdf
Introduction
The number of information technologies, such as IoT devices and mobile Internet, are rising and therefore also the need for trustworthy computing environments. The digital community is seeing more and more threats to their secret information, threats such as computer viruses and malware. Any company or individual with sensitive information will want to be able to keep it in a secure environment that preserves the integrity, authenticity, confidentiality and reliability of the data. Not only does the information need to be secure in an individual server but will need to travel through trusted channels. While firewalls and virus defense mostly protect the server side of a computing platform, the client side is vulnerable, which is where trusted computing comes in.There are many organizations that have attempted to establish a standard definition for trusted computing, but there are many different ways of understanding a trustworthy environment. The Trusted Computing Group (TCG) presented a solution where a security module is placed into the hardware platform in order to increase the security of the system. This is known as the Trusted Platform Module (TPM). Although, this solution of improving computer architecture by incorporating a trusted computing chip into the hardware has already been used since the 1990s, the need for enhancements is growing.
The main goals of trusted computing are to establish a trustworthy transfer system, secure platform, and a solution to the trust problem between man and program, man and computer, man and man, that can provide evidence of its state of execution. First, a trust is established within a terminal platform, which is done by building a chain of trust. A chain of trust focuses mainly on OS measurements, where TCG had suggested using TPM as root of trust as a method to build measurement systems. The concept of a chain of trust for terminals can be extended from local platforms to remote platforms, which is called remote attestation.
Remote attestation is considered one of the most important parts of trusted computing, because it can attest the trusted computing platform’s hardware, firmware and software. Remote attestation can attest many identities at once and satisfies the users’ security requirements in some of the following ways:
1. Help determine if the trusted computing capabilities of the computing platform can be trusted in communication.
2. Help detect the integrity of the platform configuration and the input and output of the software running on the platform.
3. Help verify if the platform configuration is in accordance with the verifier security policy.
The TPM provides the advanced security service of remote attestation and needs additional support from the basic functions of the system, such as integrity measurements. What to attest is solved by the integrity measurements and how to attest is found with the TPM identity keys.
The TPM has a Root of Trust for Measurement (RTM), which is the starting point for the integrity measurement, and goes on to acquire the characteristic values of trust degree for the software and hardware platforms. Everything from BIOS to applications will be measured for integrity by the trusted computing platform and the TPM. The characteristic will be obtained from this and hash values will be created and stored. By doing this process, the integrity states of the hardware and software modules’ executions are recorded and will proceed to build a chain of trust. If any value has been changed by malware, the hash value will be affected and the problem can be detected.
There are seven keys that the TPM supports:
1. Signing key
2. Storage key
3. Identity key
4. Endorsement key (EK)
5. Binding key
6. Migratable key
7. Certified key
Although, remote attestation can only use the platform identity key (PIK). This key is also called the attestation identity key (AIK) in the TPM specifications. PIK is an elliptic curve cryptology key, while AIK is an RSA key. For other aspects of these two key types, they are the same.
Remote Attestation Protocol
There are a few key terms that are important to define for a better understanding of the remote attestation protocol:1. Prover: The platform/client/device that is trying to prove its identity to a challenger
2. Challenger: The platform/server that is challenging the identity of prover
3. Trusted-Third Party: A third-party verifier that assists the challenger/prover in the attestation process. This verifier is usually a private Certificate Authority (CA).
The TPM implements primitive cryptographic functions upon which more complex functions, i.e. remote attestation, can be built on. The TPM is responsible for:
1. Performing public key cryptographic operations
2. Computing hash functions
3. Key management and generation
4. Secure storage of keys and other secret data
5. Random number generation
6. Integrity measurement
7. Attestation
The combination of these functionalities provide the backbone for remote attestation. Each TPM is given a public/private key (i.e. AIK) built into the hardware which is provided by a trusted third-party (TTP) Certificate Authority (CA).
The key element to the remote attestation protocol is the process of integrity measurement. Integrity measurement is a way to ascertain information about the hardware, software, or firmware that runs on a trusted computing platform. At load-time or run-time, the TPM uses a hash function to fingerprint an application, a set of files, or an application with its input as a way to establish the code identity for the challenger. Measurement can also be done on the hardware, firmware, operating system, or any piece of code/data across the software stack that requires attestation.
The remote attestation protocol uses these measurements of integrity to allow the challenger to verify the identity of the prover. The three main actors in the protocol described below are the prover (called the trusted computing platform in the Figure), the challenger (the remote verifier), and the TTP.
There are two main steps that take place for remote attestation to work: issuing a platform identity to the prover and then platform identity attestation.
Issuing a platform identity
When a new device is bought, the TPM chip does not have an identity and must be issued one by a TTP. The TTP provides a platform identity certificate and also verifies the AIK to allow for successful attestation.
1. The TPM chip on the prover machine generates a public/private key which is the Attestation Identity Key (AIK). The AIK is the key that the challenger uses to verify the identity of the prover. After generating the key, the prover wraps the public key of AIK, the EK certificate, the conformance certificate, and the platform certificate into one object.
2. The prover then sends this wrapped object to the TTP for an approved certificate that verifies the AIK of the TPM chip.
3. The TTP will then verify the application for the AIK certificate using the public key of AIK, the EK certificate and the platform certificate.
4. The TTP signs the AIK certificate with its own key and encrypts it using the EK public key.
5. The TTP then sends the verified AIK certificate to the TPM chip on the prover. The TPM chip will decrypt the certificate to obtain the unencrypted version of the AIK certificate.
At this point, the TPM chip has a verified AIK certificate that can be used for remote attestation.
Attestation of Platform identity
1. The prover (Platform A) sends a request for attestation to the challenger (Platform B).
2. The challenger then sends a request with a challenge nonce and specific integrity measurements of interest.
3. The prover then takes the AIK from the TPM chip and signs the integrity measurements with the private AIK.
4. The prover sends the certificate created in Step 3 and additional logs to prove the integrity of the device to the challenger.
5. The challenger then requests the TTP for verification about the identity of the prover. The requested information is relayed back to the challenger.
6. If the prover is trusted by the TTP, the challenger then verifies the integrity measurements and additional logs provided by the prover.
This model of remote attestation achieves both the ability to authenticate the prover’s identity as well as assess the trustworthiness of the environment that is running on the prover’s machine. Since both the prover and challenger use the TTP for authentication of the prover, only the TTP knows the identity of the prover, not the challenger. Although this does increase the level of privacy from the perspective of the prover, it does not completely provide anonymity. To deal with this problem, the Direct Anonymous Attestation (DAA) scheme was proposed.
Direct Anonymous Attestation
The direct anonymous attestation (DAA) scheme relies on zero-knowledge proofs, group signatures, and other cryptographic functions to anonymously attest platform identity. In other words, DAA does not rely on a TTP to provide proof of a prover’s identity. This provides two benefits:1. If the challenger and the TTP collude, the identity of the prover and TPM chip residing on it are at risk.
2. Since a TPM chip can theoretically generate an infinite amount of AIKs and certificates, the verification process between the prover and the TTP is a major bottleneck.
The DAA scheme relies on the idea that the challenger does not know the identity of the TPM chip but instead identifies the chip using an alias - the DAA key. Using this mechanism, the prover’s identity is concealed yet allows attestation to proceed as expected.
The protocol divides the identity from the alias by storing the private key f in the internal memory of the TPM chip and cannot be exported. The DAA key can be stored outside of the chip somewhere within the prover’s device or in other storage devices. The DAA procedure has four main steps:
1. Setup: The issuer generates a public/private key pair that will be used to sign the anonymous credentials.
2. DAA join: The TPM chip sends the application request which includes the DAA key, public key of the TPM chip, and some sort of key to prove that the computation was sound. The issuer then sends back an anonymous credential that authenticates the alias of the prover.
3. DAA sign: The TPM chip then uses the anonymous credential and the secret key f to create a DAA signature.
4. Verify: The prover sends the DAA signature to the challenger. The challenger verifies the DAA signature through some computation and checks to see if the TPM chip has already been revoked.
As the above procedure shows, the challenger nor the issuer is able to correlate the DAA key with the AIKs of a TPM chip.
The DAA protocol is supported in v1.2 of the TPM specification.
Attacks on Remote Attestation
This section will briefly discuss some attacks that can be performed during the remote attestation process. Remote attestation is vulnerable to:1. Replay attacks: A malicious device that replay old integrity measurements that correspond to a valid platform.
2. Tampering: An attacker may be able to change the integrity measurements on the prover’s device.
3. Hardware attacks: An attacker can change the data structures that store integrity measurements or break into the TPM chip to retrieve the private AIK
4. Masquerading: An attacker can send integrity measurements of another valid system as a way to then be verified by a challenger.
5. Malicious measurement agent: An attacker can report incorrect integrity values
A study done by students at Stanford created a new remote attestation protocol that is built on top of the SSL/TLS handshake protocol to mitigate these kinds of attacks.
1. The prover (C) sends a nonce along with its identity to the challenger - this is similar to the client hello message in the SSL/TLS protocol.
2. The challenger (S) sends a nonce back along with a signed certificate from a CA to prove its identity - this is similar to the server hello message in the SSL/TLS protocol.
3. The prover then sends three objects to the challenger:
a. The prover sends a signed certificate using the public key of the challenger encapsulating the integrity measurements and the secret session key.
b. It also sends a signed certificate encapsulating the AIK of the TPM chip provided by the TTP.
c. The prover also sends a signed certificate using the private AIK encapsulating the hash of the nonces from Step 1 and 2 as well as the secret session key. This packet also includes a structure to validate the integrity measurements.
4. The challenger validates the AIK certificate and also verifies of the integrity measurements.
5. If the prover passes the integrity checks, the two devices continue to send messages as described in the SSL/TLS protocol.
Using this model, this version of the remote attestation protocol is secure against the threats described above. The paper uses the Murphi model, a finite-state machine, to evaluate the threat model.
Conclusion
Trusted computing and remote attestations provide the means for secure verification of device identities. As the market for IoT devices grow, the more important remote attestation becomes. As we describe in this blog, remote attestation has gone through a lot of changes from relying on trust to using anonymous identities to maintain privacy. More recent research look at variants of the protocol that use secure protocols such as SSL/TLS or rely purely on hardware instead of a TPM chip for attestation. These variants are crucial to furthering the science of remote attestation - a crucial component of trusted computing as well as secure communications.References
1. https://learning.oreilly.com/library/view/trusted-computing/9783110476095/content/14_chapter07_1.xhtml#chapter07_1_12. https://seclab.stanford.edu/pcl/cs259/projects/cs259_final_lavina_jayesh/CS259_report_lavina_jayesh.pdf
3. https://courses.cs.washington.edu/courses/csep590/06wi/finalprojects/bare.pdf
4. https://web.cs.wpi.edu/~guttman/pubs/good_attest.pdf
Comments
Post a Comment