SPD Node independent technologies

9.2.1.1Isolation

To provide an even higher degree of security, efforts were taken to also address the integrity of hypervisors themselves. HyperSafe [7], for example, suggests a way to “lock down” the memory and restricts pointer indexing. Hereby, the control-flow integrity is maintained by comparing referred branch targets with a stored control-flow graph.

Not only hypervisors are used for isolation. Microkernels such as the systems of the L4 family [8] are alternatives. L4 has even been completely formally verified. However, also virtual machine monitors such as the one of the Robin project [9] or the above mentioned SecVisor are upcoming verification targets. This is especially promising as hypervisors have a much thinner code base compared to often complex operating systems.

First efforts have been undertaken to apply virtualization for security on embedded systems as well [10].

The weakness of these solutions is that they only concentrate on single platforms, but do not address distributed systems, especially not heterogeneous ones.

9.2.1.2Monitoring and Trust

Virtualization can be enhanced by trusted computing technology. Yet, there are challenges to overcome as virtual machines usually would not get direct access to the TPM. The Terra hypervisor [13] uses certificates for attestation on various assurance levels. It is capable of isolating virtual machines, so that even the owner of a (physical) machine is prevented from accessing the contents of the virtual machines. Another approach [14] uses a “Virtual TPM” implemented in software. It allows the virtual machines to communicate directly with a secure software-TPM which itself is linked to a physical TPM. To facilitate trusted computing on embedded systems, Winter [15] suggests the usage of ARM’s virtualization hardware TrustZone [16]. The Trusted Computing Group proposes furthermore a Mobile Trusted Module (MTM) [17]. The field of application of trusted virtualization on embedded systems is wide. Selhorst et al. [18] describe a secure signing environment where process isolation and platform attestation enable the trusted sending of text messages.

One weakness of Trusted Computing is the resources required for operations. Here it is important to compare existing solutions and point out improvements.

A Trusted Virtual Domain (TVD) [19][20][21][22] is a coalition of virtual machines that share virtualized resources for I/O and computation. Virtualization of resources as well as machines allows creating arbitrary virtual networks that operate independently from architecture and topology of the underlying hardware platform. In a TVD, interaction between VMs is modeled and regulated through shared TVD resources, for example virtual networks or storage. A TVD establishes a certain level of trust between members of a domain based on an admission policy enforced on these entities upon joining the TVD. The management of the TVD infrastructure is done through a central server (TVD Master) that can be used to define security policies for the TVD, and keep track of the availability and configurations of physical and virtual entities in the TVD. The TVD Master allows definition of the network topology in a way to ensure complete isolation of the TVD-specific data when stored, processed or communicated via network. This means that the physical and virtual entities of a network are connected or not to each other based on the delimited confinement boundaries of the TVD.

In the Trusted Virtual Datacenter described in [23], resource assignment, resource access and communication between virtual machines are controlled by means of a two-sided policy based on the non-hierarchical enforcement model [24]. On the one hand, the policy defines the security context of a virtual machine by “labeling” the set of the resources it can access to. On the other hand, the policy defines some collocation rules, which, for example, enforce restrictions on which virtual machines can run on the same platforms at the same time.

However, this kind of solutions has limitations when considering infrastructures of heterogeneous devices where trust domains are defined, with physical or virtual entities entering and leaving the trust domains. In this case, the challenge, which is not addressed in current solutions, can be summarized in the following points:

• 
  Upon a change in the network topology, e.g., in case a node enters or leaves a trust domain, the component-specific security policies should be automatically adapted and enforced without a change in the high-level security policy. Current fully centralized solutions, do not account for this kind of scenarios.
  
• 
  The central management service that defines the security policy for the trust domain should be continuously reachable by the physical devices in the domain in order for these to stay synchronized with the security policy updates. The reliance on a single central server for controlling the trust domains represents a potential threat for the maintenance of trust in the domain.
  
• 
  When a device or component is attacked, or its configuration is (unintentionally) modified in a way to pose a security threat that would undermine the level of trust in the domain, these changes must be reported to the central security management point in order to account for the potential consequences. This requirement cannot be addressed by current solutions; they solely rely on integrity measurements for admission control, but miss to monitor continuously.