greg s' not being a techie, doesn't this say WAVE is all over LeGrade?
7
More on Attestation and Trust Unsealing and sealing secrets
LT provides the capability to seal and unseal secrets with the assistance of a TPM v.1.2 device. This capability ensures that a secret generated by one domain manager or environment is not
available to another domain. The basis of this protection lies with the TPM’s Storage Root Key (SRK), a public/private key
pair. The SRK private key never leaves the TPM. Any data encrypted with the SRK public key can only be decrypted by the corresponding SRK private key. As the private key never leaves the TPM, only this TPM may decrypt this data.
The TPM provides a SEAL operation, which permits data and a list of PCRs to be encrypted into a blob using a TPM storage key. The resulting encrypted blob may be stored anywhere. A corresponding UNSEAL operation decrypts the blob, but will not expose decrypted data unless the saved PCR values match current PCRs. This operation permits a domain manager to seal data to the current PCR values representing its current protected environment; the resulting blob can only be unsealed to expose the data if the identical domain manager is running.
Typically, a domain manager generates its own bulk encryption key, to be used in software, and seals this key using the TPM. The bulk encryption key is then used to encrypt all secrets managed by this domain manager, and may also be used to encrypt secrets for the applications running in the protected partition.
Establishing Initial Trust A sealed secret can only be unsealed and accessed by the same domain manager environment. If a secret known only to a user was sealed to an environment that the user chose to trust, then if this secret can be re-displayed the user knows the same trusted environment is currently running.
A similar method uses a secret shared with a remote agent, allowing the remote agent to know that the same trusted environment is currently running. But that leaves the question of how the user or remote agent determines that the environment should be trusted before a shared secret exists. To put the question more succintly: how do we determine initial trust?
LT supports an optional, verifiable reporting mechanism, called attestation. Attestation permits either the user or, optionally, a remote agent to measure the currently running environment using measurement and reporting mechanisms supported by the TPM. Based upon these reported measurements, the user or remote agent may use this information to decide whether to trust the current platform environment.
For a remote agent, the attestation process involves standard cryptographic methods. A remote agent generates a random value (called a nonce or challenge), and sends it to the system to be
tested. At that system, the TPM creates a record containing the nonce and the current PCR values (which represent the currently running domain manager environment). The TPM signs this record
with its private key and the signed record is returned to the remote agent, along with the TPM’s public key and credentials. The remote agent may examine the credentials to determine that this public key does; in fact, represent a real TPM, then uses the public key to verify the signature on the record and, then extracts the data from the record. The extracted data may now be checked against various lists to determine if this is an environment acceptable to the remote agent.
Attesting the environment of a local machine to a human user is more challenging, given that most humans cannot perform cryptographic calculations in their heads. There are at least three methods a user may choose from to identify the local machine environment and make a trustdecision:
1. Assuming that a system is in its original state (as delivered from an OEM that a user trusts), the user may simply choose to trust this initial configuration. The user would be advised to
create a secret (e.g. a favorite phrase or quote) to be sealed to this environment. As long as this secret can be displayed to the user on subsequent boots, the user has confidence that the
same environment is running.
2. A portable token capable of cryptographic operations may be used to act as a “remote agentlike” proxy for the user. This token can be loaded with measurements of valid environment
configurations at the local retailer. Such a portable token can then be connected to the PC and performs attestation of the user system in a manner identical to that described for remote
agents. The portable token could then report pass/fail.
3. The user may request that a remote agent perform attestation of the system. However, this leaves the problem of how the remote agent safely reports this information back to the user,
given that the user cannot (yet) trust the software environment on the system. There are at least two methods of achieving this:
If the user has a portable token, the remote agent’s results can be communicated using cryptographically secured protocols to the portable token which displays the result for the user.
The remote agent provides the results “out-of-band”, perhaps using an automated phone menu or mail.
News 
Market Data 
Discover 
