MENU

Implementing multiple-independent-levels-of-security architectures on multi-core processors

Implementing multiple-independent-levels-of-security architectures on multi-core processors

Feature articles |
By eeNews Europe



The Cyber Security Landscape
In recent years, many European countries have recognised the growing cyber threats against both civilian infrastructure and defence systems, and have responded by developing national cyber security policies which define the objectives for the protection of critical national infrastructure against cyber attacks, and a range of strategies for achieving these objectives.

The Advent of the MILS Architecture

Commercial organisations and European national governments have long categorised information at different security classifications, based on criteria such as information value, sensitivity, and the impact of disclosure. Historically, information at different security classifications has been physically isolated in separate domains, initially in manual systems, and subsequently in computerised systems.

More recently, as organisations have become increasingly reliant on computer systems, there has been a drive towards automation of the information flow process between different security domains. This enables decision-making to be accelerated in fields as diverse as commercial business, banking, government and armed forces. Traditionally, multi-level secure (MLS) computer systems were built as bridges between these domains using multiple, physically separated computers, networks, and displays. This technique, known as “air gap” security, required expensive equipment and occupied a large footprint in terms of Size, Weight and Power (SWaP), and has limitations in the cyber era.

The Multiple Independent Levels of Security (MILS) architecture was proposed as an alternative approach for secure embedded systems many years ago. MILS uses a layered software architecture, with a separation kernel (SK) built on four fundamental security policies:

1) Data Isolation, which ensures that a partition cannot access resources in other partitions.

2) Periods Processing, which ensures that applications within partitions cannot consume more than their allocated share of CPU usage.

3) Information Flow, which defines the permitted information flows between partitions.

4) Fault Isolation, which defines that a failure in one partition does not impact any other partition within the system.


These four policies create an architecture where the separation kernel is Non-Bypassable, Evaluatable, Always Invoked and Tamper Proof, collectively known as NEAT. The small separation kernel and layered assurance approach means that the amount of code which would need to undergo rigorous scrutiny as part of a high assurance security evaluation can be very small, to reduce both evaluation time and cost. This would be an important benefit when developing a critical national infrastructure system which needs to undergo a high-assurance security evaluation.

The implementation of MILS systems on single-core (also known as unicore) processor architectures has utilised the hardware capabilities provided by the processor to enforce the four fundamental security policies, and to also minimise unintended hidden channels of communication between applications, known as covert channels. This is an important consideration for high-assurance systems, as covert channels can be used by advanced adversaries in sophisticated cyber-attacks against critical national assets. However, as unicore processor architectures have been in use for many years, the characteristics of covert channels on these architectures are well understood. This means that on certain unicore processor architectures it may be possible to use appropriate countermeasures in the MILS implementation to reduce their bandwidth.

Advent of Multi-core Processors

For decades, gains in processor performance were achieved through increasing the processor clock frequency. This approach eventually reached the limits of viability due to dramatically increased power consumption, so semiconductor companies turned to focus on the development of multi-core processor architectures to achieve both performance gains and power reduction. However, the advent of multi-core processor architecture is a disruptive change, as applications and systems need to be designed with multi-core in mind in order to efficiently utilise the potential performance available.

Multi-core processors also present new challenges for security with respect to application isolation and core separation, because applications can truly run concurrently (compared to running sequentially on a unicore processor). Research into these areas has been undertaken in recent years in the related discipline of safety-critical systems, and although the end-goals of safety certification and high-assurance security are different, there is some overlap in their requirements. Recent research undertaken by the European Aviation Safety Agency (EASA) has highlighted issues around suitability of individual multi-core processor architectures for safety-critical avionics applications, due to contention for shared resources. This issue could have a potential impact for a security-critical application in terms of a covert channel. However, analysis also reveals that some multi-core processor designs provide hardware features which can be utilised to enforce application isolation and core separation. The result is that careful scrutiny is required when selecting multi-core processor architectures for high-assurance security applications.

Cross-Domain System Requirements

Critical national infrastructure includes systems which have an important role as gateways between networks, or domains, of different security classifications. These gateways are an example of a Cross-Domain Solution (CDS) which have a requirement to process data at different security classifications. Such gateways can be deployed in a wide range of environments, for example between a corporate enterprise network and the public internet; or between government or defence networks of different security classifications. These CDS systems must provide prevent unauthorised data flows between domains, and must provide high assurance that they are able to withstand cyber-attacks and protect government and defence networks against advanced persistent threats (APT).

Figure 1

In each case, the generalised use case and topology is the same (see Fig. 1). The CDS will be connected to two different networks, and should have an application to receive messages from one network and pass them to a guard, which determines whether to forward or discard the messages based on a pre-defined security policy and examination of the messages’ data contents. A similar configuration with a separate guard (and potentially a different security policy) would operate in the reverse direction.

Cross-Domain System network gateway

This CDS system could be implemented on a MILS platform using a unicore processor, potentially using a minimum of four partitions: sender/receiver for Domain A, guard for Domain A, sender/receiver for Domain B, and guard for Domain B (Figure 2).

 

Figure 2

These applications would be securely isolated from each other by the MILS separation kernel, and only authorised information flows – according to the system security policy – would be allowed. In a typical system, this would be augmented with additional partitions which would be used for attestation, performing trusted initialisation of the hardware and verifying that the software payload had not been tampered with; and system configuration, to enable different guard configurations depending on security policy and threat environment.


Cross-Domain System network gateway

The CDS system could also be implemented using MILS on a multi-core processor, which may provide many more configuration options and the potential for higher system performance (than a unicore implementation) due to the ability to run applications concurrently on separate processor cores. However, the system will need to be architected carefully to ensure that the potential for covert channels of communication is minimised. This could be achieved by allocating the applications to different processor cores and using a time-sliced synchronised scheduling approach to limit the number of security levels or domains being processed at the same time. This means that if a covert channel is exploited, then only information at the same security classification or domain would be exchanged.

Wind River MILS Platform Multi-core Edition

Wind River VxWorks MILS Platform, Multi-core Edition provides an operating run-time environment designed for systems having high security, high assurance, and high performance requirements. The platform implements the MILS architecture, enabling multiple software components with high performance requirements, from different security levels or from different domains, to safely and securely share the same multi-core processor-based hardware platform.

VxWorks MILS Platform, Multi-core Edition supports multi-core processors in asymmetric multiprocessing (AMP) mode, where each core (and its associated hardware resources) hosts an independent instantiation of VxWorks MILS, complete with separation kernel and applications running in partitions. Mechanisms are also provided to enable communications between partitions located on different cores, with information flow control enforced by the cores’ VxWorks MILS separation kernels.

By partitioning multiple software components, with time and space resource allocation, information flow control, and fault isolation all strictly enforced to conform to the system’s security policies, VxWorks MILS Platform enables security-critical applications, carrying potentially confidential or mission-critical data, to coexist on the same system with medium or low security applications, which may connect to non-secure channels (e.g., the public Internet). VxWorks MILS Platform, Multi-core Edition is thus designed to be the foundation for multicore-processor-based security-critical systems, such as those used in critical national infrastructures.

About the author

 


Eur Ing Paul Parkinson FIET is a Principal Systems Architect with Wind River in the UK, working with customers in the Aerospace & Defence sector in Europe. Paul’s professional interests include Information Security (InfoSec), Integrated Modular Avionics (IMA), Intelligence Surveillance Target Acquisition Reconnaissance (ISTAR) systems and the Internet of Things (IoT). Paul blogs on A&D industry issues on the Wind River website at https://blogs.windriver.com/?s=paul+parkinson

If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :    eeNews on Google News

Share:

Linked Articles
10s