Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Information Security Functions
A root-of-trust needs at least a random number generator, a hash function, and an encryption/decryption engine, because a remote user needs to 1) verify evidence that a platform contains a root-of-trust, and 2) verify evidence gathered by that root-of-trust (about the software state of the platform). This is probably impossible without the use of information security mechanisms.
Given that a Trusted Platform must contain information security mechanisms, it's a no-brainer to decide that a Trusted Platform could (and should) provide basic information security services to users of the platform. Those basic services are as follows:
Digital signatures. Ordinary platforms can already do digital signatures but typically have neither a safe place to keep signature keys, nor protection for a signature key while it's being used.
Confidentiality of data. Platforms can already encrypt files but typically don't have a safe place to keep confidentiality keys.
Controlled access to keys and data. Access conditions are dictated by the entity (normally the owner of the information) that submits the information to the root-of-trust. Access controls can include any combination (including none) of the following mechanisms:
Presentation of a password
Checking that the platform is the exact platform that originally stored the information
Checking that the platform has a given software state
This latter aspect of access control is possible only because of the unique behavior of Trusted Platforms: they report measurements of the software state of a platform. It's therefore possible to incorporate values of measurements of the software state of a platform into access control information. A Trusted Platform can then refuse to reveal a secret if the current software state is not the expected state into which the secret should be revealed. This is valuable because a Trusted Platform executing the wrong software (such as a hacker script) has a means to decide not to release keys (for example). This prevents digital signing and the release of confidential data in the wrong software environment, even if the correct password is presented.
There are also other important auxiliary information security services, including a means for the root-of-trust to attest that keys belong to a Trusted Platform (giving some degree of confidence that keys are being protected while they are being used).
A Trusted Platform needs both asymmetric and symmetric encryption algorithms, because they have different properties and different usages. These asymmetric and symmetric algorithms are preferably implemented in different ways:
Asymmetric encryption uses two keys—one for encryption and one for decryption—and is relatively slow. Typically, asymmetric encryption is used for signing, and for confidentiality of symmetric keys. Countries rarely restrict the strength of confidentiality for signing keys and storage of symmetric keys. In fact, the European Union worries about too little protection for signing keys, and its "Signature Directive" specifies minimum levels of physical protection for signing keys. The outcome is that all Trusted Platforms use high-strength asymmetric encryption algorithms and must provide a good level of protection for asymmetric keys that are used for signing in the EU.
Symmetric encryption uses the same key for both encryption and decryption, and is relatively fast. Typically, symmetric encryption is used for confidentiality of files and messages. For reasons of national security, many countries have restrictions on the strength of confidentiality for files and messages, and mandate the maximum strength of symmetric encryption in platforms in their jurisdiction. The outcome is that a Trusted Platform must allow its symmetric encryption strength to be easily customized. This means that symmetric encryption must be provided by software.