InvestorsHub Logo
Followers 2
Posts 100
Boards Moderated 0
Alias Born 10/17/2003

Re: None

Tuesday, 07/15/2008 11:56:34 PM

Tuesday, July 15, 2008 11:56:34 PM

Post# of 249202
I don't understand this, everybody is talking about Wavexpress while intel has released The most important tech that most of here have invested in Wave for the sole purpose TRUSTED EXECUTION and attestation.

Intel Trusted Execution Technology requires the system to contain a TPMv1.2 as defined by the Trusted Computing Group and specific software for some uses


More on Attestation and Trust


Unsealing and sealing secrets
Trusted Execution Technology 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 succinctly: how do we determine initial trust?
Trusted Execution Technology 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 trust decision:
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 agent like”
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.

http://www.intel.com/technology/security/downloads/arch-overview.pdf




Join the InvestorsHub Community

Register for free to join our community of investors and share your ideas. You will also get access to streaming quotes, interactive charts, trades, portfolio, live options flow and more tools.