By combining and extending the interfaces provided by the underlying hypervisor layer, the trusted software layer realizes security-critical services needed to build secure computing platforms (see Figure 1).
Figure 1: examples of security-critical services provided by the Trusted Software Layer.
In the following, we discuss the main purposes of the trusted software layer:
Policy Translation: The security policy to be enforced by a secure system is acombination of different sub-policies coming from several sources of different interests. One main task of the trusted software layer is to convert the different subpolicies into one consistent set of access control rules and to find and solve conflicts. Moreover, the resulting security policy has to be separated, trandlated, and distributed such that they can be understand and enforced the other security services.
Privacy Protection: Many services provided by the trusted software layer can violate security policies of end-users if they are not designed carefully. A common example is the specification of the Trusted Computing Group (TCG). If the provided TPM functionality is injudiciously used, anonymity requirements of the user's identity or the platform's configuration can be violated. The security services of trusted software layer prevent such a misbehavior by applying more secure protocols on top of the core functions. A pragmatic form of property-based attestation preventing discrimination of software, for example, is realized on top of the sealing fucntion provided by TPMs.
Trusted GUI: Based on the basic resource management features offered by the underlying layers, a user-friendly but secure user interface has to help users to prevent security-critical mistakes. An application authentication mechanism, for instance, helps users to detect Trojan horses; moreover, the secure user interface has to ensure that used features (e.g., paste & copy) do not violate the security policy. Another task of the secure user interface is to protect the integrity and confidentiality of security-critical input (e.g., a PIN) and output (e.g., a document to be verified).
Compartment Manager: Although a secure system should be capable of executing potentially malicious applications without violation of the mandatory security policy (note that it is in general impossible to detect Trojan horses), the installation and update of compartments, like applications and security-critical services, has to be controlled by a trustworthy service. The main tasks of the compartment manager are therefore to help users to derive the minimal set of priviledges for a desired application, and to translate and provide the results. Since it enforces a security policy defined by the platform owner, it is, for instance, possible to ensure that the whole system or only a compartment behaves like a closed system that can only be manipulated by authorized entities.
Trusted Storage: Different applications require different security properties to be provided by the storage mechanisms both during runtime and if the system is shut down. The intergity of application code, for example, has to be protected to prevent unauthorized modifications (e.g., by a virus). Application data (e.g., documents) requires storage protecting integrity and confidentiality. But there are more storage types required by a secure platform: to prevent reset attacks, for instance, some applications and cryptographic protocols require storage mechanisms providing freshness.
Crypto Services: The security services discussed above are based on different cryptographic schemes and protocols which are logically summarized in this service. In practice, its functionality is distributed over different cryptograpic libraries (e.g., the Trusted Software Stack (TSS)) and services (e.g., the TPM driver).