The Trusted Software Layer
By combining and extending the interfaces provided by the underlying resource management 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 a combination 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, translated, 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 function 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).
- Secure Installer: 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 applications and security-critical services has to be controlled by a trustworthy service. The main tasks of the secure installer are therefore to help users to derive the minimal set of privileges for a desired application, and to translate and provide the results. Since the secure installer 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 integrity 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.