Refinement-Based Specification and Security Analysis of Separation

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. XX, NO. X, AUGUST 201X 1 Reﬁnement-based Speciﬁcation and Security Analysis of Separation Kernels

Yongwang Zhao, David Sanan,´ Fuyuan Zhang, Yang Liu

Abstract—Assurance of information-flow security by formal methods is mandated in security certification of separation kernels. As an industrial standard for improving safety, ARINC 653 has been complied with by mainstream separation kernels. Due to the new trend of integrating safe and secure functionalities into one separation kernel, security analysis of ARINC 653 as well as a formal specification with security proofs are thus significant for the development and certification of ARINC 653 compliant Separation Kernels (ARINC SKs). This paper presents a specification development and security analysis method for ARINC SKs based on refinement. We propose a generic security model and a stepwise refinement framework. Two levels of functional specification are developed by the refinement. A major part of separation kernel requirements in ARINC 653 are modeled, such as kernel initialization, two-level scheduling, partition and process management, and inter-partition communication. The formal specification and its security proofs are carried out in the Isabelle/HOL theorem prover. We have reviewed the source code of one industrial and two open-source ARINC SK implementations, i.e. VxWorks 653, XtratuM, and POK, in accordance with the formal specification. During the verification and code review, six security flaws, which can cause information leakage, are found in the ARINC 653 standard and the implementations.

Index Terms—Separation Kernels, ARINC 653, Refinement, Formal Specification, Information-flow Security, Common Criteria, Theorem Proving. !

1 INTRODUCTION

N recent years, a trend in embedded systems is to enable On the other hand, the security of separation kernels is I multiple applications from different vendors and with usually achieved by the Common Criteria (CC) [6] and different criticality levels to share a common set of physical Separation Kernel Protection Profile (SKPP) [7] evaluation, resources, such as IMA [1] and AUTOSAR [2]. To facilitate in which formal verification of information-flow security is such a model, resources of each application must be pro- mandated for high assurance levels. tected from other applications in the system. The separation A trend in this field is to integrate the safe and se- kernel [3] and its variants (e.g. partitioning kernels and cure functionalities into one separation kernel. For instance, partitioning operating systems [4], [5]) establish such an PikeOS, LynxSecure, and XtratuM are designed to support execution environment by providing to their hosted appli- both safety-critical and security-critical solutions. Therefore, cations spatial/temporal separation and controlled informa- it is necessary to assure the security of the functionali- tion flow. Separation kernels, such as PikeOS, VxWorks 653, ties defined in ARINC 653 when developing ARINC 653 INTEGRITY-178B, LynxSecure, and LynxOS-178, have been compliant Separation Kernels (ARINC SKs). Moreover, a widely applied in domains from aerospace and automotive security verified specification compliant with ARINC 653 to medical and consumer electronics. and its mechanically checked proofs are highly desirable Traditionally, safety and security of critical systems are for the development and certification of ARINC SKs. The assured by using two kinds of separation kernels respec- highest assurance level of CC certification (EAL 7) requires tively, such as VxWorks 653 for safety-critical systems and comprehensive security analysis using formal representa- VxWorks MILS for security-critical systems. In order to tions of the security model and functional specification of improve the safety of separation kernels, the ARINC 653 ARINC SKs as well as formal proofs of correspondence standard [5] has been developed to standardize the system between them. Although formal specification [8], [9], [10], functionality as well as the interface between the kernel and [11] and verification [12], [13], [14], [15], [16], [17], [18] of applications. ARINC 653 is the premier safety standard and information-flow security on separation kernels have been has been complied with by mainstream separation kernels. widely studied in academia and industry, information-flow security of ARINC SKs has not been studied to date. To the best of our knowledge, our work is the first effort on this • This research is supported in part by the National Research Foundation, topic in the literature. Prime Minister’s Office, Singapore under its National Cybersecurity R&D Program (Award No. NRF2014NCR-NCR001-30) and administered by There exist three major challenges to be addressed in this the National Cybersecurity R&D Directorate. work. First, the ARINC 653 standard is highly complicated. • Y. Zhao is with the School of Computer Science and Engineering, Beihang It specifies the system functionality and 57 standard services Univerisity, Beijing, China (Email: [email protected]) and the School of separation kernels using more than 100 pages of informal of Computer Science and Engineering, Nanyang Technological University, Singapore (Email: [email protected]). descriptions. Second, as a sort of hyperproperties [19], it • D. Sanán,F. Zhang and Y. Liu are with the School of Computer Science is difficult to automatically verify information-flow security and Engineering, Nanyang Technological University, Singapore (Email: on separation kernels so far. Formal analysis of information- { } sanan, fuzh, yangliu @ntu.edu.sg). flow security of separation kernels is difficult and needs IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. XX, NO. X, AUGUST 201X 2 exhausting manual efforts. Moreover, there exist different found in the standard. These works aim at the safety of definitions of information-flow security (e.g. in [20], [21], separation kernels and applications. Our work is the first to [22], [23]) and the relationship of them on ARINC SKs has conduct a formal security analysis of ARINC 653. to be clarified. Third, reusability of formal specification and We have used Isabelle/HOL [34] to formalize the secu- proofs is important. They should be extensible and easy to rity model, the refinement method, and functional specifi- be reused for subsequent development and certification. cations as well as to prove information-flow security. All This paper presents a specification development and specifications and security proofs are available at “http: security analysis method based on stepwise refinement [24], //securify.scse.ntu.edu.sg/skspecv3/”. In detail, the tech- [25] for ARINC SKs with regard to the EAL 7 of CC certifica- nical contributions of this work are as follows. tion. A separation kernel is an event-driven system reacting 1) We define a security model, which is a parameterized to hypercalls or exceptions, which is alternatively called a abstraction for the execution and security configuration reactive system. Therefore, we borrow design elements from of ARINC SKs. A set of information-flow security prop- existing formalisms such as superposition refinement [26] of erties are defined in the model. An inference framework reactive systems and Event-B [27]. We start from a generic is proposed to sketch out the implications of the prop- security model of ARINC SKs that could be instantiated erties and an unwinding theorem for compositional as functional specifications at different abstract levels. The reasoning. refinement in this paper concretizes an abstract functional 2) We propose a refinement framework for stepwise de- specification by incorporating additional design elements velopment of ARINC SKs. Functional specifications of and by transforming existing ones. The stepwise refinement ARINC SKs at different levels are instantiations of the addresses the first challenge by modeling complicated re- security model, and thus all properties of the security quirements of ARINC 653 in a modular and hierarchical model are satisfied on the specifications. We define manner. The refinement provides formal proofs of the cor- a security extended superposition refinement for AR- respondence between functional specifications for CC certi- INC SKs, which supports introducing additional design fication. Information-flow security is proven on an abstract elements (e.g. new state variables and new events). specification and it is preserved in a concrete specification We also show the security proofs of the refinement, by means of refinement. Moreover, system functionalities i.e. the preservation of security properties during the and services of ARINC 653 are modeled as the event spec- refinement. ification in the functional specification. In such a design, 3) We develop a top-level specification for ARINC SKs information-flow security is proven in a compositional way, which covers kernel initialization, partition schedul- i.e. the security of ARINC SKs is implied by the satisfaction ing, partition management, and inter-partition com- of local properties (unwinding conditions) on events. Thus, munication (IPC) according to ARINC 653. A second- the second challenge is resolved. Using the correctness- level specification is developed by refining the top- by-construction method based on the refinement, well- level one. We add processes, process scheduling, and structured specification of ARINC SKs is developed together process management according to ARINC 653. Security with their correctness and security proofs, which helps to is proven by refinement. resolve the third challenge. 4) We conduct a code-to-spec review required by CC certi- The challenges mentioned above are not well addressed fication on one industrial and two open-source ARINC in the literature. In formal verification of the seL4 micro- SK implementations, i.e. VxWorks 653, XtratuM [35], kernel [28] and its separation extension [16], and the ED and POK [36], in accordance with the formal specifica- separation kernel [12], refinement methods have been ap- tion. During the verification and code review, six covert plied. First, due to the post-hoc verification objective of these channels to leak information [37] have been found in projects, refinement is not a technique to develop the speci- the ARINC 653 standard and the implementations. The fication in a stepwise manner, but to prove the conformance approaches to fixing them are also provided. between formalizations at different levels. Therefore, they In this paper, we have extended our previous work [38] have few levels of specification and the refinement is coarse- by introducing the security model, the refinement frame- grained. Second, ARINC 653 is not the emphasis of these work, the second-level specification, the code review of works and the formal specification are not compliant with VxWorks 653, and four new covert channels. The rest of ARINC 653. Information-flow security verification has been this paper is organized as follows. Section2 introduces enforced on PikeOS [10], [11], INTEGRITY-178B [13], and an preliminaries of this paper. Section3 presents the overview ARM-based separation kernel [17]. However, refinement is of our method. The next four sections present the security not considered in these works. Correctness-by-construction model, refinement framework, top-level and second-level methods have been used to create formal specification of specifications, respectively. Then, Section8 discusses the se- separation kernels [8], [9], [15], [29]. However, information- curity flaws found in ARINC 653 and the implementations. flow security is not the emphasis of them. Formalization and Finally, Section9 gives the conclusion and future work. verification of ARINC 653 have been studied in recent years, such as the formal specification of ARINC 653 architecture 2 PRELIMINARIES [31], modeling ARINC 653 for model-driven development of IMA applications [32], and formal verification of application 2.1 Information-flow Security software on top of ARINC 653 [33]. In [29], [30], the system The notion noninterference is introduced in [39] in order to functionalities and all service in ARINC 653 have been provide a formal foundation for the specification and anal- formalized in Event-B, and some inconsistencies have been ysis of information-flow security policies. The idea is that a IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. XX, NO. X, AUGUST 201X 3 u v security domain is noninterfering with a domain if no Partition 1 Partition 2 ...... Partition n u Applications Applications Applications Applications action performed by can influence the subsequent outputs (Unclassified) (Top Secret) (Secret) (Top Secret) seen by v. Language-based information-flow security [21] processes processes processes processes assigns either High or Low labels to program variables and ensures the data confidentiality by preventing information hypercalls hypercalls hypercalls hypercalls High Low leakage from -level data to -level data. Transitive ARINC 653 Services ARINC 653 Services ARINC 653 Services ARINC 653 Services

noninterference is too strong and thus is declassified as src port dest port intransitive one [40], [41]. That is, the system should allow transmit msgs transmit msgs schedule certain flows of information from High domains to Low do- Channel Channel mains, if that flow traverses the appropriate declassifier. In schedule Message Transmitter [20], intransitive noninterference is defined in a state-event Scheduler schedule manner and concerns the visibility of events, i.e. the secrets that events introduce in the system state. Language-based information-flow security is generalized to arbitrary multi- Fig. 1: Architecture of ARINC 653 Separation Kernels domain policies in [22] as a new state-event based notion nonleakage. In [22], nonleakage and intransitive noninter- models a partial function, which is equal to 0b ⇒ (0a option). ference are combined as a new notion noninfluence, which Record types may be defined, for example record point = considers both the data confidentiality and the secrecy of xcoord :: int ycoord :: int with the elements like p = events. Intransitive noninterference [20], [22], [42] in state- (|xcoord = 10, ycoord = 10|) and projections xcoord p and event manner has been applied to verify separation kernels, ycoord p. Records may be updated, such as p(|xcoord := such as seL4 [16], PikeOS [11], INTEGRITY-178B [13], and 20, ycoord := 20|), and extended, such as record cpoint = AAMP7G [14]. point + col :: colour. Nonrecursive definitions can be made with the definition command and the primrec function def- 2.2 ARINC 653 inition is used for primitive recursions. Locales are Isabelle’s The ARINC 653 standard is organized in six parts. Part 1 [5] approach for dealing with parametric theories. Locales may in Version 3 specifies the baseline operating environment for be instantiated by assigning concrete data to parameters, application software used within IMA. It defines the system and the resulting instantiated declarations are added to functionality and requirements of 57 services. ARINC SKs are the current context. This is called locale interpretation. In its mandated to comply with this part. The six major function- simplest form, a locale declaration consists of a sequence of alities specified in ARINC 653 are partition management, context elements declaring parameters (the keyword fixes) process management, time management, inter- and intra- and assumptions (the keyword assumes). partition communication, and health monitoring. To enhance readability, we will use standard mathemat- ARINC 653 establishes and separates multiple partitions ical notation where possible. Examples of formal specifica- in time and space except the controlled information flows tion will be given in the Isabelle/HOL syntax. along communication channels among partitions. The security policy used by ARINC SKs is the Inter-Partition Flow Pol- icy (IPFP) [43], which is intransitive. It is expressed abstract- 3 METHOD OVERVIEW ly in a partition flow matrix partition flow : partition × The architecture of ARINC SKs we consider in this paper partition → mode, whose entries indicate the mode of the is shown in Fig.1. Since ARINC 653 Part 1 in Version flow. For instance, partition flow(P ,P ) = QUEUING 1 2 3 [5] is targeted at single-core processing environments, means that partition P is allowed to send information 1 we consider single-core separation kernels. For simplicity, to partition P via a channel with a message queue. An- 2 separation kernels usually disable interrupts in kernel mode other feature of ARINC 653 is its two-level scheduling, [16] and thus there is no in-kernel concurrency, which means i.e. partition scheduling and process scheduling. For the that the hypercalls and system events (e.g. scheduling) are purpose of temporal separation, the partition scheduling in executed in an atomic manner. ARINC 653 is a fixed, cycle based scheduling and is strictly We adopt intransitive noninterference in state-event deterministic over time. Process scheduling in a partition is manner due to its practicality in industry and intransitive priority preemptive. channel-control policies used in ARINC 653. We formalize various definitions of information-flow security, e.g. non- 2.3 Isabelle/HOL interference, nonleakage, and noninfluence. An inference Isabelle is a generic and tactic-based theorem prover. framework of these properties is provided, in which the We use Isabelle/HOL [34], an implementation of high- implication relationship among the properties is proven. order logic in Isabelle, for our development. The key- Since automatic analysis of information-flow security is word datatype is used to define an inductive data type. still restricted by the size of state space ( [44], [45]), it is diffi- The list in Isabelle is one of the essential data type cult to deal with operating system kernels so far. Automatic in computing and is defined as datatype 0a list = analysis techniques (e.g. model checking) usually verify one Nil (“[]”) | Cons 0a “ 0a list ”(infixr “#”), where [] configuration of the system at a time [46]. However, the is the empty list and # is the concatenation. The poly- deployment of partitions on separation kernels is unknown morphic option type is defined as datatype 0a option = in advance. Therefore, it is well suited to use theorem prov- None | Some (the : 0a). A function of type 0b * 0a ing based approaches. Interactive theorem proving requires IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. XX, NO. X, AUGUST 201X 4

Formal Specification Security and Proof instantiation, the properties of the inference framework are

Inference Framework preserved on the speciﬁcation. The rest of security proofs

Information Flow Security of the specification is to show satisfaction of unwinding Properties State Machine & Security satisfy conditions (UCs) which are instances of GUCs. Configuration imply In order to support additional design elements in the General Unwinding refinement, we use superposition refinement [26] in this Security Model Security Conditions (GUC)

Instantiate work. Since formal speciﬁcation of ARINC SKs combines Instantiate Instantiate the system dynamics and security components, we extend Functional Specification the superposition reﬁnement with security constraints for Kernel satisfy use Event Unwinding Conditions ARINC SKs. The state represented by a set of state vari- Execution Specification (Top Level)

Model ables at the abstract level is transformed into concrete state Top-level variables and extended by new state variables. An event refine extend is reﬁned to a set of concrete events and new events may Functional Specification be introduced in the reﬁnement. Therefore, in addition to a Kernel satisfy use Event Unwinding Conditions state simulation relation, we use an event relation to connect Execution Specification (2nd Level)

Model the abstract and concrete events. To show information-flow Second-level ... extend security at the concrete level, UCs of the abstract level are refine nth level extended due to the new state variables and new events. The proofs of UCs at the concrete level only consider the Fig. 2: Method Overview new state variables and security proofs at the abstract level are reused. In the case of data refinement, i.e. without introducing new events and new state variables, security human intervention and creativity, but produces machine- is automatically preserved in the refinement. checkable proofs required by CC certification. Moreover, it A major part of requirements in ARINC 653 are modeled is not constrained to specific properties or finite state spaces. in this work. We develop two levels of specification by This approach is mostly adopted to formal verification of refinement. ARINC SKs use IPC to implement controlled operating systems [47]. We choose Isabelle/HOL in this information flows among partitions. Moreover, in the IPFP work because (1) it can deal with large-scale formal veri- policy of ARINC 653, communication ports and channels are fication of real-world systems [48] due to the expressiveness associated with partitions, and all processes in a partition of HOL, a high degree of proof automation, and powerful can access the ports configured for this partition. Therefore, libraries, etc.; (2) most of the OS verification are using we model functionalities related to information flows, i.e. Isabelle/HOL, e.g. seL4 [16], [28] and PikeOS [10], [11]; partition management and IPC services, in the top-level and (3) Isabelle/HOL is recommended as a formal methods functional specification. For functional completeness, kernel tools as required by CC certification on high assurance lev- initialization and partition scheduling are also modeled. At els [49]. Although other approaches, e.g. Event-B, provide the second level, we use the refinement to add process the refinement framework, properties of information-flow scheduling and process management services, which are security could not be formulated straightforwardly by their functionalities in partitions. Other functionalities and ser- inherent specification languages. We could see some efforts vices of ARINC 653 are possible to be added by refinement on this direction [50] but no supported tools. in future. The method overview is shown in Fig.2. The security model is a generic model of ARINC SKs for information- 4 SECURITY MODELOF SEPARATION KERNELS flow security, which includes a state machine based execution model and the security configuration. The inference We design a security model for ARINC SKs in this section. framework presents the implication among these proper- The model consists of a nondeterministic state machine, ties and an unwinding theorem. It follows the classical the security configuration of ARINC SKs, information-flow unwinding relation based proof [20], i.e. satisfaction of the security properties, and an inference framework of these general unwinding conditions (GUCs) implies the security. properties. The security model is a parameterized abstraction, which means that the kernel components are defined as abstract 4.1 State Machine and Security Configuration types. It could be instantiated to a concrete model, i.e. a The state-event based information-flow security uses a state functional specification of ARINC SKs. By this instantiation, machine to represent the system model. For universality, all elements (e.g. properties, implications, and proofs) of the we adopt a nondeterministic model. The state machine of security model are reused and preserved in the specification. ARINC SKs is defined as follows. In order to improve the reusablity of the specification and Definition 1 (State Machine of ARINC SKs). M = proofs, a functional specification is decomposed into two hS, E, ϕ, s i is a tuple, where S is the state space, E is parts: a kernel execution model and an event specification 0 the set of event labels, s ∈ S is the initial state, and for ARINC 653. The execution model is an instance of 0 ϕ : E → (S × S) is the state-transition function. the security model, while the event specification defines P Isabelle/HOL functions to implement the state changes The ϕ function characterises the single-step behaviour when an event occurs. The concrete functions in the event of separation kernels by executing an event, such as a specification are invoked by the execution model. By the hypercall or scheduling. The auxiliary functions used in IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. XX, NO. X, AUGUST 201X 5 run([ ]) = Id s # es , {s} run(es) occurs, the kernel must consult the partition scheduler to run(e#es) = ϕ(e) ◦ run(es) R(s) , ∃es. (s0, s) ∈ run(es) determine which partition is currently executing, and the D d d d current executing partition is the domain of the hypercall. s ≈ t , ∀d ∈ D. s ∼ t ss ts , ∀s t. s ∈ ss ∧ t ∈ ts −→ s ∼ t On the other hand, separation kernels can provide specific  sources([ ], s, d) = {d}  hypercalls which are only available to privileged partitions.  [  sources(e#es, s, d) = ( {sources(es, s0, d) | (s, s0) ∈ ϕ(e)}) ∪ Therefore, the domain of an event is represented as a partial 0 function kdom : S × E * D.  {w | w = kdom(s, e) ∧ (∃v s . (w v)   ∧ (s, s0) ∈ ϕ(e) ∧ v ∈ sources(es,; s0, d))} State equivalence: It means states are identical for a security domain. We define an equivalence relation ∼ on  ipurge([ ], d, ss) = [ ] d  states for each domain such that s ∼ t if and only if states s  ipurge(e#es, d, ss) = if(∃s ∈ ss. kdom(s, e) ∈ sources(e#es, s, d))  t d s t  then and are identical for domain , that is to say states and [ are indistinguishable for d. Two states are equivalent for the  e#ipurge(es, d, ( {s0 | (s, s0) ∈ ϕ(e)}))  scheduler when domains of each event in the two states are  s∈ss  D  else ipurge(es, d, ss) the same. For a set of domains D, we define s ≈ t as shown in Fig.3 to represent that states s and t are equivalent for Fig. 3: Auxiliary Functions in Security Model all domains in D. For two sets of states ss and ts, we define d ss ts as shown in Fig.3 to represent that any two states in ss and ts are equivalent for domain d. the security model are defined in detail in Fig.3. Based Based on the discussion above, we define the security on the ϕ function, we define the run function to represent model of ARINC SKs as follows. We assume that each event the execution of a sequence of events. The execution(s, es) is always enabled in a state. Whenever an event e should function (denoted as s es) returns the set of final states by # not be executed in a state s, it does not change the state. executing a sequence of events es from a state s, where is Definition 2 (Security Model of ARINC SKs). the domain restriction of a relation. By the execution function, the reachability of a state s is defined as reachable(s) SM = hM, D, kdom, , ∼i R(s) (denoted as ). ; The security configuration of separation kernels is usual- with assumptions as follows. ly comprised of security domains, security policies, domain 1) ∀p1, p2 ∈ P. p1 p2 −→ p1 T ∧ T p2 of events, and state equivalence as follows. 2) ∀d ∈ D. S d ; ; ; Security domains: Applications in partitions have vari- 3) ∀d ∈ D. d ; S −→ d = S ous security levels. We consider each partition as a security 4) ∼ is an equivalence; relation. domain. Since partition scheduling is strictly determinis- 5) ∀s t e. s ∼S t −→ kdom(s, e) = kdom(t, e) tic over time, we define a security domain scheduler for 6) events are enabled in any state, i.e. ∀s e. R(s) −→ partition scheduling, which cannot be interfered by any (∃s0. (s, s0) ∈ ϕ(e)). other domains to ensure that the scheduler does not leak The security model is represented in Isabelle/HOL as a information via its scheduling decisions. Note that process locale SM, which could be instantiated to create functional scheduling is conducted in partitions. Since ARINC 653 de- specification. fines the channel-based communication services using ports and leaves the implementation of message transmission over channels to underlying separation kernels, a security 4.2 Information-flow Security Properties domain message transmitter is defined for message transmis- In order to express the allowed information flows for the sion. The transmitter also decouples message transmission intransitive policies, we use a function sources(es, s, d) as from the scheduler to ensure that the scheduler is not shown in Fig.3, which yields the set of domains that interfered by partitions. Therefore, the security domains (D) are allowed to pass information to domain d when event of ARINC SKs are the scheduler (S), the transmitter (T), and sequence es occurs from state s. It is inductively defined the configured partitions (P), i.e. D = P ∪ {S, T}. on event sequences. We include in sources(e#es, s, d) all Security policies: In order to discuss information-flow domains that can pass information to d when es occurs from security policies, we assume an interference relation ⊆ all successor states s0 of s, as well as the domain kdom(s, e) D × D according to the partition flow matrix and /;is performing the event e, whenever there exists some inter- the complement relation of . If there is a channel; from mediate domain v by which the domain kdom(s, e) can a partition p1 to a partition p;2, then p1 T and T p2 pass information to d indirectly. In the intransitive purged since the transmitter is the message intermediator.; ; Since sequence (ipurge(es, d, ss) in Fig.3), the events of partitions the scheduler can possibly schedule other domains, it can that are not allowed to pass information to d directly or interfere with them. In order to prevent the scheduler from indirectly are removed. Given an event sequence e#es leaking information via its scheduling decisions, we require executing from a set of state ss, ipurge keeps the first event that no other domains can interfere with the scheduler. e if this event is allowed to affect the target domain d, i.e. Domain of events: Traditional formulations in the state- ∃s ∈ ss. kdom(s, e) ∈ sources(e#es, s, d). It then continues event based approach assume a static mapping from events on the remaining events es from the successor states of ss to domains, such that the domain of an event can be deter- after executing e. On the other hand, if e is not allowed mined solely from the event itself [20]. However, in separa- to affect the target domain d, then it is removed from the tion kernels that mapping is dynamic [23]. When a hypercall sequence and purging continues on the remaining events es IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. XX, NO. X, AUGUST 201X 6 TABLE 1: Information-flow Security Properties noninfluence weak_noninfluence No. Properties noninterference: (1) d ∀d es. (s0 # es) (s0 # ipurge(es, d, {s0})) weak noninterference: consistent step nonleakage (2) ∀d es1 es2. ipurge(es1, d, {s0}) = ipurge(es2, d, {s0}) d noninterference_r weak_noninterference_r −→ ((s0 # es1) (s0 # es2)) noninterference r: (3) d Conditions Unwinding General ∀d es s. R(s) −→ ((s # es) (s # ipurge(es, d, {s}))

locally respects locally noninterference weak_noninterference weak noninterference r: (4) ∀d es1 es2 s. R(s) ∧ ipurge(es1, d, {s}) = ipurge(es2, d, {s}) Fig. 4: Inference Framework of Security Properties d −→ ((s # es1) (s # es2)) nonleakage: (5) sources(es,s,d) when for any pair of reachable states s and t and an S ∀d es s t. R(s) ∧ R(t) ∧ (s ∼ t) ∧ (s ≈ t) observing domain d, if (1) s and t are equivalent for all d −→ ((s # es) (t # es)) domains that may (directly or indirectly) interfere with d weak noninfluence: sources(es,s,d) (6) sources(es1,s,d) during the execution of es, i.e. s ≈ t, and (2) ∀d es1 es2 s t. R(s) ∧ R(t) ∧ (s ≈ t) the same domain is currently executing in both states, i.e. S S ∧ (s ∼ t) ∧ ipurge(es1, d, {s}) = ipurge(es2, d, {t}) s ∼ t, then s and t are observationally equivalent for d d and es. Noninfluence is the combination of nonleakage −→ ((s # es1) (t # es2)) noninfluence: and noninterference to ensure that there is no secrete data (7) sources(es,s,d) ∀d es s t. R(s) ∧ R(t) ∧ (s ≈ t) ∧ (s ∼S t) leakage and secrete events are not visible according to secu- d rity policies. Murray et al. [23] have defined noninfluence −→ ((s # es) (t # ipurge(es, d, {t}))) for seL4, which is a weaker one and defined as weak noninfluence in Table1. Similar to weak noninterference, it can handle arbitrary insertion and deletion of secret events. It from the current set of states ss. The observational equiva- is the combination of weak noninterference r and nonleakage. d We propose a stronger one, i.e. noninfluence, according to the lence of an execution is denoted as (s # es1) (t # es2), which means that a domain d is identical to any two final original definition [22] by extending the scheduler and the state reachability. It is the combination of noninterference r states after executing es1 from s (s # es1) and executing and nonleakage. In the next subsection, we will show that es2 from t. noninfluence is actually the conjunction of noninterference The intransitive noninterference [20] on the execution and nonleakage. model is defined as noninterference in Table1. Its intuitive meaning is that events of domains that cannot interfere with a domain d should not affect d. Formally, given an 4.3 Inference Framework of Security Properties event sequence es and a domain d, final states after exe- The inference framework clarifies the implication relations cuting es from the initial state s0 and after executing its among the security properties on the security model. We purged sequence from s0 are identical to d. In noninterfer- have proven all implication relations as shown in Fig.4, ence, the ipurge function only deletes all unsuitable events. where an arrow means the implication between properties. Another version is introduced in [22] to handle arbitrary The standard proof of information-flow security is dis- insertion and deletion of secret events, which is defined as charged by proving a set of unwinding conditions [20] weak noninterference in Table1. In weak noninterference, we that examine individual execution steps of the system. This only ask for two event sequences which have the same paper also follows this approach. We first define the un- d ipurge(es , d, {s }) = effects on the target domain , i.e. 1 0 winding conditions on event (UCE) as follows. ipurge(es2, d, {s0}). The above definitions of noninterfer- Definition 3 (Step Consistent Condition of Event). ence are based on the initial state s0, but separation kernels usually support warm or cold start and they may start to d S SC(e) , ∀d s t. R(s) ∧ R(t) ∧ (s ∼ t) ∧ (s ∼ t) execute from a non-initial state. Therefore, we define a more kdom(s,e) general version noninterferece r based on the reachable func- ∧ (kdom(s, e) d) ∧ (s ∼ t) tion R. This general noninterference requires that systems −→ (∀s0 t0. (s,; s0) ∈ ϕ(e) ∧ (t, t0) ∈ ϕ(e) −→ s0 ∼d t0) starting from any reachable state are secure. It is obvious that this noninterference implies the classical noninterfer- Definition 4 (Locally Respects Condition of Event). ence due to R(s0) = T rue. Weak noninterference is also 0 0 generalized as a new property weak noninterference r. LR(e) , ∀d s s . R(s) ∧ (kdom(s, e) / d) ∧ (s, s ) ∈ ϕ(e) Nonleakage and noninflunce are defined for ARINC SKs −→ (s ∼d s0) ; based on the scheduler as shown in Table1. The intuitive meaning of nonleakage is that if data are not leaked initially, The step consistent condition requires that for any pair data should not be leaked during executing a sequence of of reachable states s and t, and any observing domain events. Separation kernels are said to preserve nonleakage d, the next states after executing an event e in s and t IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. XX, NO. X, AUGUST 201X 7 d are indistinguishable for d, i.e. s0 ∼ t0, if (1) s and t are 5.2 Specification Refinement d indistinguishable for , (2) the current executing domains In the superposition refinement, existing state variables and s t e s in and are the same, (3) the domain of in state can events can be refined. In addition, new state variables and d s t interference with , and (4) and are indistinguishable for events can be added to an abstract specification. Here, e the domain of . The locally respects condition means that we use subscripts A and C to represent the abstract and e s an event that executes in a state can affect only those concrete specifications, respectively. During the refinement domains to which the domain executing e is allowed to send the abstract state SA can be transformed into ST and new information. state variables denoted as S∆ can be incorporated. Thus, Based on the UCEs, the general unwinding conditions the concrete state S = S + S , where the symble “+” SC ∀e. SC(e) C T ∆ of the security model can be defined as , is the extension of data type (e.g. record extension in Is- LR ∀e. LR(e) and , . The soundness and completeness of abelle/HOL). The security extended superposition refine- unwinding conditions in the security model are shown as ment for the functional specification is defined as follows. follows, where the soundness is the unwinding theorem in [20], [22]. Definition 6 (Refinement). Given two functional specifications SK and SK , SK refines SK using a state Theorem 1 (Soundness and Completeness of Unwinding A C C A simulation relation Ψ: S → S and an event relation Conditions). The security model SM satisfies that C A Θ: EC → (EA ∪ {τ}), denoted as SKA vΨ,Θ SKC , if (SC ∧ LR) = noninfluence and SC = nonleakage 1) the initial state in SKC establishes R, i.e. Ψ(s0C ) = s0A. The objective of noninfluence is to ensure data confiden- 2) each event in EA is refined by a set of events in EC , i.e. Θ tiality and secrecy of events by combing noninterference and is a surjection and ∀e s t. Θ(e) 6= τ ∧ (s, t) ∈ ϕC (e) −→ nonleakage. We show the soundness and completeness of (Ψ(s), Ψ(t)) ∈ ϕA(Θ(e)). noninfluence in the security model as follows. 3) new events only change the new state variables in- Theorem 2 (Soundness and Completeness of Noninfluence). troduced in the refinement and does not affect the The security model SM satisfies that variables in SKA, i.e. ∀e s t. Θ(e) = τ ∧ (s, t) ∈ ϕC (e) −→ Ψ(t) = Ψ(s). noninfluence = (noninterference r ∧ nonleakage) and 4) security domains are preserved and refined events has weak noninfluence = (weak noninterference r the same execution domain as that at the abstract level, ∧ nonleakage) i.e. DC = DA and ∀e s. Θ(e) 6= τ −→ kdomC (s, e) = kdomA(Ψ(s), Θ(e)). 5 SPECIFICATION AND REFINEMENT FRAMEWORK 5) the refinement does not change the interference rela- After discussing the security model, we present the function, i.e. C = A. tional specification by instantiating the security model and d d d 6) s ∼C t ;= Ψ(s;) ∼A Ψ(t) ∧ s ∼∆ t, where ∼∆ only a refinement framework for stepwise specification develop- considers the new state variables S∆ introduced in the ment in this section. refinement.

5.1 Specification by Security Model Instantiation The relation Ψ maps concrete states to abstract ones. It is actually the transformation of S to S . Abstract states A functional specification consists of a kernel execu- A T of next states by executing an event e in a state t at the tion model and an event specification. The kernel exe- concrete level is a subset of next states by executing the cution model is an instance of the security model. The refined event Θ(e) in a state s (s = Ψ(t)) at the abstract level. instantiation is an interpretation of the SM locale, i.e. SM = interpretation SM{s /s , ϕ/ϕ , kdom/kdom , If the event is a new one at the concrete level, its execution I 0 0I I I should not affect the abstract state. We could consider that a /Sched, /T rans, ∼ / ∼ , / }, where the param- S T I I new event at the concrete level refines a τ action, which does eters of SM are substituted by concrete ones. In order ; ; not change the abstract states. The security configuration at to assure the correctness of the instantiation, we provide the abstract level is preserved in the refinement, i.e. (1) , , the instantiation proof to show that the instance parameters S T partitions D, and the relation are the same, (2) the domain preserve the assumptions of SM. of events at the abstract level is preserved, and (3) the state The event specification is a mapping from events to a ; equivalence relation at the abstract level is preserved, while set of functions to model the functionalities and services in the relation at the concrete level also requires that the two ARINC 653. The ϕ function in the execution model exe- I states are equivalent for the new state variables (i.e. ∼ ). cutes events by invoking these functions. Thus, a functional ∆ The refinement in this paper is reflexive and transitive. specification of ARINC SKs is defined as follows. The correctness is ensured by Theorem3. Since noninterfer- Definition 5 (Functional Specification of ARINC SKs). A ence considers the state and event together, our refinement SK = hSM ,F i functional specification is a tuple I , implies that the state-event trace set of a concrete specifi- where cation is a subset of the abstract one. Thus, the refinement 1) SMI = hMI , DI , kdomI , I , ∼I i is the execution preserves noninterference as we present in the next subsec- model, where MI = hSI , EI ,; ϕI , s0I i. tion. 2) F : EI → Γ is the event specification, where Γ is the set Theorem 3 (Soundness of Refinement). If SKA and SKC are of functions and each f ∈ Γ has the type SI → P(SI ). instances of SM and SKA vΨ,Θ SKC , then 3) ϕI in MI defines the execution of each event e, where ϕ (e) = {(s, t) | t ∈ F (e)(s)} ∗ ∗ I . ∀es. Ψ (s0C # es) ⊆ s0A # Θ (es) IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. XX, NO. X, AUGUST 201X 8

∗ In the theorem, Ψ maps a set of concrete states to a ∀ e. Θ(e) = τ ∧ LR∆(e) −→ LRC (e) ∗ set of abstract states by the relation Ψ, and Θ maps a Finally, based on these lemmas and Theorem4, we have sequence of concrete events to a sequence of abstract events Theorem5. The theorem means that if SKC is a refinement by the relation Θ. The τ event is ignored during executing a of SKA and SKA satisfies the unwinding conditions, we sequence of events at the abstract level. only need to prove the unwinding conditions on new state From the definition of the refinement, we could see that variables to show information-flow security of SKC . for any reachable state s at the concrete level, its abstract Theorem 5 (Security of Refinement). If SKA and SKC state on the Ψ relation is also reachable at the abstract level. are instances of SM, SKA satisfies SCA ∧ LRA, SKC Lemma 1 (State Reachability in Refinement). If SKA and satisfies SC∆ ∧ LR∆, and SKA vΨ,Θ SKC , then SKC SKC are instances of SM and SKA vΨ,Θ SKC , then satisfies noninfluence.

∀s. RC (s) −→ RA(Ψ(s)) In the case of data refinement, i.e. without new events and new state variables introduced in the refinement, Superposition refinement [26] assumes the termination information-flow security is automatically preserved on the of new events introduced in the refinement. Since hypercalls concrete specification. and system events of ARINC SKs terminate, we assume Corollary 1. If SKA and SKC are instances of SM, SKA that events terminate in our refinement framework. In the satisfies SCA ∧ LRA, SKA vΨ,Θ SKC , @e. Θ(e) = τ, formal specification of ARINC SKs, we use the primrec and ∀s t d. s ∼d t SK noninfluence definition in Isabelle/HOL to define the event specification. and ∆ , then C satisfies . Thus, the termination of events is automatically ensured in Isabelle/HOL. 6 TOP-LEVEL SPECIFICATION AND SECURITY PROOFS 5.3 Security Proofs of Refinement In the top-level functional specification, we model kernel The security proofs of a concrete specification also follow initialization, partition scheduling, partition management, the unwinding theorem introduced in Subsection 4.3. Since and inter-partition communication defined in ARINC 653. a concrete specification is an instance of the security model, We first instantiate the security model as the kernel execu- we have following theorem according to Theorem1. tion model. Then, we present the event specification. Finally, Theorem 4 (Unwinding Theorem for Concrete Specification). security proofs are discussed. If SKC is an instances of SM and SKC satisfies SCC ∧ LRC , then SKC satisfies noninfluence. 6.1 Kernel Execution Model We define the step consistent condition of events on the Basic components at the top level are partitions and com- new state variables as follows. munication objects. A partition is basically the same as a Definition 7 (Step Consistent Condition of Event on New program in a single application environment [5]. IPC is State Variables). conducted via messages on channels configured among partitions. Partitions have access to channels via ports which are d S SCC∆(e) , ∀ d s t. RC (s) ∧ RC (t) ∧ (s ∼C t) ∧ (s ∼C t) the endpoints of channels. The modes of transferring mes- kdomC (s,e) ∧ (kdomC (s, e) C d) ∧ (s ∼C t) sages over channels are queuing and sampling. A significant characteristic of ARINC SKs is that the basic components −→ (∀s0 t0. (s, s;0) ∈ ϕ (e) ∧ (t, t0) ∈ ϕ (e) −→ s0 ∼d t0) C C ∆ are statically configured at built-time. Partitions, communication objects, and the system configuration are specified The locally respects condition of events on the new in Isabelle/HOL as “record Sys Config” and defined as state variables is defined in an analogous manner. Based on a constant “conf::Sys Config” in the top-level specification. definitions of the refinement and the unwinding conditions When creating ports by invoking IPC services in a partition, as well as Lemma1, we have four lemmas shown as follows. only configured ports in the partition are created. A set of Lemma 2 (Step Consistent of Event Refinement). If SKA and configuration constraints are defined to ensure the correct- SKC are instances of SM and SKA vΨ,Θ SKC , then ness of the system configuration. ∀ e. Θ(e) 6= τ ∧ SCA(Θ(e)) ∧ SCC∆(e) −→ SCC (e) We first instantiate the security model by a set of concrete parameters as follows. Lemma 3 (Locally Respects of Event Refinement). If SK A Events: We consider two types of events in the spec- and SK are instances of SM and SK v SK , C A Ψ,Θ C ification: hypercalls and system events. Hypercalls cover all then partition management and IPC services in ARINC 653. ∀ e. Θ(e) 6= τ ∧ LRA(Θ(e)) ∧ LRC∆(e) −→ LRC (e) System events are the actions of the kernel itself and include Lemma 4 (Step Consistent of New Event in Refinement). kernel initialization, scheduling, and transmitting messages If SKA and SKC are instances of SM and SKA vΨ,Θ over channels. Other types of events could be introduced SKC , then during subsequent refinements. Events are illustrated in Fig. 1 as dotted line arrows and italics. ∀ e. Θ(e) = τ ∧ SC (e) −→ SC (e) ∆ C Kernel State and Transition: In the top-level specifi- Lemma 5 (Locally Respects of New Event in Refinement). cation, the kernel state concerns states of partitions, the If SKA and SKC are instances of SM and SKA vΨ,Θ scheduler, and ports. The state of a partition consists of its SKC , then operating mode (partitions) and the created ports (part IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. XX, NO. X, AUGUST 201X 9

ports Partition1 ). The state of the scheduler shows which is the current processes executing partition (cur). The state of a port is mainly about messages in its buffer (comm). The datatype P ort T ype receive write

models sampling and queuing mode ports as well as their ... source/sampling port message buffers. We deﬁne the type of port id as natural destination/queuing port number and use the partial functions to store the created trans_sampling_msg trans_queuing_msg ports and their states. We prove a set of invariants about channel types in the speciﬁcation, such as the domain of part ports source/queuing port ... destination/sampling is the same as that of comm in all reachable states. port read record State = partitions :: part id * part mode type send read part ports :: port id * part id cur :: domain id comm :: port id * Port Type Partition2 Partition3

The state transition function ϕ is instantiated as the Fig. 5: Channel-based Communication in ARINC 653 exec event function in the top-level speciﬁcation, in which the mapping function F in Deﬁnition5 is also modeled.

Event Domain: The domain of the system events is defined as s0 = system init conf. The system init func- static: the domain of the event scheduling is S and the domain tion assigns initial values to the kernel state according to of message transmission is T. The domain of hypercalls is the kernel configuration. Because the execution of message dynamic and depends on the current state of the kernel. transmission is also under the control of scheduling, we It is defined as kdom s (hyperc h) = cur s, where cur s define an abstract partition scheduling as follows that non- returns the current executing partition in the state s. deterministically chooses one partition or the transmitter as Interference Relation: The interference relation in the the current executing domain, where partconf is a field of security model is instantiated as the function interference1 as Sys Config with the type partition id * P artition Conf follows in the top-level specification. to store the configured partitions. definition interference1 :: domain-id ⇒ domain-id ⇒ bool ((- -)) definition schedule :: “Sys Config ⇒ State ⇒ State” where where interference1 d1 d2 ≡ ; schedule sc s ≡ s(|cur := SOME p. p∈ {x. (partconf sc) x 6= None = if d1 d2 then True ∨ x = T sc}|) else if is-sched conf d1 then True else if ¬(is-sched conf d1) ∧ (is-sched conf d2) then False Partition Management: Partition management services else if is-part conf d1 ∧ is-trm conf d2 then part-intf-trm conf d1 else if is-trm conf d1 ∧ is-part conf d2 then trm-intf-part conf d2 in ARINC 653 are available to the application software else False for setting a partition’s operating mode and to obtain a partition’s status. The Set Partition Mode service request is interference1 The is in conformance with the assump- used to set the operating mode of the current partition to tions 1) - 3) in Definition2. d NORMAL after the initialization of the partition is complete. State Equivalence: For a partition d, s ∼ t if and only if The service is also used for setting the partition back to vpeq part s d t, which is defined as follows. IDLE (partition shutdown), and to COLD START or WAR- definition vpeq part :: “State ⇒ part id ⇒ (State × bool)” where M START (partition restart), when a fault is detected and vpeq part s d t ≡ (partitions s) d = (partitions t) d ∧ vpeq part comm s d t processed. The Set Partition Mode service is specified as follows. The partition mode transition in ARINC 653 does It means that states s and t are equivalent for partition not allow transitting from COLD START to WARM START. d, when the partition state and the communication abilities The function updates the operating mode of the current of d on these two states are the same. An example of the executing partition. communication ability is that if a destination queuing port p is not empty in two states s and t, partition d has the definition set part mode :: Sys Config ⇒ State ⇒ part mode type ⇒ State p s t d where same ability on in as in . This is because is able to set part mode sc s m ≡ receive a message from p in the two states. The equivalence (if (partitions s)(cur s) 6= None ∧ of communication abilities defines that partition d has the ¬ (the ((partitions s)(cur s)) = COLD START same set of ports, and that the number of messages is the ∧ m = WARM START) then let pts = partitions s in s(|partitions := pts(cur s := Some m )|) same for all destination ports on states s and t. else s) Two states s and t are equivalent for the scheduler when the current executing partition in the two states are the Inter-partition Communication: The communication ar- same. The equivalence of states for the transmitter requires chitecture is illustrated in Fig.5. In the first stage of this that all ports and states of the ports are the same. work, we design the event specification completely based on the service behavior specified in ARINC 653. When proving the unwinding conditions on these events, we find 6.2 Event Specification covert channels (Section8 in detail). We change the service The event specification on the top level models kernel specification in ARINC 653 by allowing message loss to initialization, partition scheduling, all services of IPC and avoid these covert channels according to the results in [51]. partition management defined in ARINC 653. We use a set of functions to implement one service. Kernel Initialization and Scheduling: The kernel initial- For instance, the Send Queuing Message service is imple- ization considers initialization of the kernel state, which is mented by the send que msg lost function as follows. The IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. XX, NO. X, AUGUST 201X 10

manipulated port should be a source (is source port s p) and queuing (is a queuingport s p) port. It should belong Finally, we conclude the satisfaction of the noninflu- to current partition too (is a port of partition s p). If the ence property on the top-level specification and all other message buffer of the port is full (is full portqueuing), the information-flow security properties according to the infer- service just omits the message. Otherwise, the message is ence framework of the security model. inserted into the buffer (insert msg2queuing port). send que msg lost :: “Sys Config ⇒ State ⇒ port id ⇒ Mes- definition ECOND LEVEL PECIFICATION AND ECURITY sage ⇒ (State × bool)” where 7 S - S S send que msg lost sc s p m ≡ PROOFS (if(¬ is a queuingport s p ∨ ¬ is source port s p ∨ ¬ is a port of partition s p ) then (s, False) In the second-level specification, we refine the top-level else if is full portqueuing sc s p then (s, True) one by adding processes, process scheduling in partitions, else (insert msg2queuing port s p m, True)) and process management services in ARINC 653. We first The message transmission on channels is shown in Fig. instantiate the security model as the kernel execution model. 5. For instance, the message transmission in queuing mode Then, we present the refinement. Finally, the security proofs is specified as follows. If the source and destination port of the specification are discussed. have been created (get portid by name s sn 6= None) and there are messages in the buffer of the source port (has msg 7.1 Kernel Execution Model inportqueuing), a message in the buffer is removed (remove msg from queuingport) and inserted into the buffer of the In ARINC 653, a partition comprises one or more pro- destination port. When the buffer of the destination port cesses that combine dynamically to provide the functions is full (is full portqueuing), the message is discarded. associated with that partition [5]. Processes are separated among partitions, while processes within a partition share primrec transf que msg lost :: “Sys Config ⇒ State ⇒ Channel Type the resources of the partition. Process management provides ⇒ State” where transf que msg lost sc s (Queuing sn dn) = the services to control the life-cycle of processes. We refine (let sp = get portid by name s sn; dp = get portid by name s dn in the state at the top-level as follows. The state variables at if sp 6= None ∧ dp 6= None ∧ has msg inportqueuing s (the sp) then the top level are not changed. The state is extended by new let sm = remove msg from queuingport s (the sp) in if is full portqueuing sc (fst sm)(the dp) then s state variables of processes by means of record extension. else insert msg2queuing port (fst sm)(the dp)(the (snd sm)) Thus, the state relation R is simple and defined as follows. else s ) | A partition has a set of created processes (procs) and may transf que msg lost sc s (Sampling ) = s have a current executing process (cur proc part). A process has a state (proc state). We found a covert channel if we use 6.3 Security Proofs global process identifiers (Section8 in detail). Here, we use separated process identifiers for each partition. Since the top-level specification is an instance of the security model, the first part of the security proofs is the instantia- record StateR = State + procs :: partition-id * (process-id set) tion proof. The assumptions 1) - 3) of the security model cur-proc-part :: partition-id * process-id (Definition2) on the interference relation are preserved by proc-state :: partition-id × process-id * Proc-State the interference1 function. The assumption 4) is preserved by ∼ for the scheduler. The definition of ∼ is an equivalence definition R :: StateR ⇒ State (⇑- [50]) where relation at the top level, which means the preservation of R r = (|cur = cur r, partitions = partitions r, comm = comm r, part-ports = part-ports r |) the assumption 5). By the following lemma, the assumption 6) of the security model is preserved by the top-level speci- Each event at the top level is refined by one at the second fication. level. We add events for process scheduling and process Lemma 6 (Event Enabled in Top-level Specification). management services. The exec event function at the top 0 0 level is extended by adding maps of new events to new ∀s e. R(s) −→ (∃s . (s, s ) ∈ exec event(e)) functions in the event specification. The event domain and the interference relation at the second level are the same The second step of the security proofs is to show the as those at the top level. The state equivalence relation is UCEs, i.e. satisfaction of Definitions3 and4. We define a set d extended on new state variables as s . ∼ . t as follows. of concrete conditions for events. Satisfaction of the concrete d The state equivalence on new state variables, i.e. s ∼∆ t conditions of one event implies that the event satisfies the d UCEs. For instance, Definition8 shows the concrete con- in Definition6, is defined as s . ∼∆ . t at the second level. dition of step consistent for the Create Queuing Port event, It requires that the processes of a partition d, the states of which is an instance of UCEs of the event. processes, and the current executing process in the partition are the same in states s and t. Definition 8 (Concrete SC(e) of Creating Queuing Port). definition vpeqR :: StateR ⇒ domain-id ⇒ StateR ⇒ bool ((- ∼. - .∼ -)) 0 0 d S ∀ d s t s t p. R(s) ∧ R(t) ∧ s ∼ t ∧ s ∼ t where vpeqR s d t ≡ (R s) ∼ d ∼ (R t) ∧ (s∼.d.∼∆t) ∧ is part conf (cur s) ∧ (cur s) d ∧ s cur∼ s t ∧ s0 = fst (create queuing port; conf s p) 7.2 Event Specification 0 ∧ t = fst (create queuing port conf t p) Due to the new events introduced in the refinement, we −→ s0 ∼d t0 use new functions to implement the process management IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. XX, NO. X, AUGUST 201X 11

COLD/WARM_START NORMAL proc-st ((cur s 0, selp) := Some (st(|state := RUNNING|))), 0 partition transits cur-proc-part := cur-pr(cur s := Some selp)|)}) to NORMAL Waiting suspend Ready else {s} schedule

schedule resume start Reﬁned Events: All events at the top level are reﬁned

suspend stop resume start stop Suspend according to the new state type. For instance, the set partition mode function (Subsection 6.2) at the top level stop Dormant Running is refined as follows. When setting a partition to NORMAL stop Dormant partition transits mode, the states of processes in the partition are correctly set to NORMAL partition transits stop set procs to normal to NORMAL ( ) according to process state transitions create a suspend process Suspend in Fig.6. When setting a partition from NORMAL mode to others, all processes in the partition are deleted (remove partition resources). Fig. 6: Process State Transitions in Second-level Specification definition set-partition-modeR :: Sys-Config ⇒ StateR ⇒ partition-mode-type ⇒ StateR where set-partition-modeR sc s m ≡ and scheduling. The existing functions in the top-level spec- (if (partitions s)(cur s) 6= None ∧ ification are refined according to the new state type. The ¬ (the ((partitions s)(cur s)) = COLD-START ∧ m = WARM-START) then process state transitions in the second-level specification are let pts = partitions s; shown in Fig.6. We capture all state transitions defined in s 0 = (if m = NORMAL then ARINC 653 except those triggered by intra-partition com- set-procs-to-normal s (cur s) munication, which will be modeled in future refinement. else if the ((partitions s)(cur s)) = NORMAL then remove-partition-resources s (cur s) Process Management: Seven basic services of process else s ) in management in ARINC 653, i.e. Create/Start/Stop/Suspend/ s 0(|partitions := pts(cur s 0 := Some m )|) Resume Process, Set Priority, and Get Process Status, are else s) modeled at the second level. We use a set of functions 7.3 Security Proofs to implement these services. For instance, Start Process is implemented by the start process function as follows. Since the second-level specification is a refinement and an instance of the security model, the first part of the definition start-process :: StateR ⇒ process-id ⇒ StateR where start-process s p ≡ security proofs are the instantiation and refinement proofs. if p ∈ the ((procs s)(cur s)) ∧ The assumptions (1) - (6) of the security model (Definition (state (the ((proc-state s)(cur s, p)))) = DORMANT then 2) have been proven on the second-level specification. In let st = (if the ((partitions s)(cur s)) = NORMAL order to show the refinement relation, conditions (1) - (6) in then READY else WAITING); pst = the ((proc-state s)(cur s, p)); Definition6 are proven on the second-level specification. proc-state 0 = (proc-state s) ((cur s, p) := The second step of security proofs is to show the UCEs, Some (pst (|state := st|))) in i.e. satisfaction of Definitions3 and4. By following Theorem s(|proc-state:=proc-state 0|) else s 5, we only need to prove that SKC satisfies SC∆ ∧ LR∆ to The process to be started should belong to the current show the information-flow security, since the satisfaction of executing partition and be in DORMANT state. As shown SCA ∧ LRA in SKA has been proven at the top level and in Fig.6, if the current partition is in NORMAL mode, the we have SKA vΨ,Θ SKC . Therefore, we define a set of new state of the process is READY. Otherwise, the new state concrete conditions for all events on the new state variables. is WAITING. Satisfaction of the conditions of one event implies that Process Scheduling: ARINC 653 defines a priority based the event satisfies the unwinding conditions. For instance, process scheduling in partitions, which is implemented as Definition9 shows the concrete condition of step consistent follows. The process scheduling occurs in a partition only for the Schedule Process event, which is an instance of UCEs when the partition is in NORMAL mode. It first sets the state on the new state variables (SCC∆(e)) of the event. of the current executing process to READY (setRun2Ready). Definition 9 (Concrete SCC∆(e) of Schedule Process). Then it chooses one of processes in READY state with 0 0 d S ∀ d s t s t p. RC (s) ∧ RC (t) ∧ s . ∼ . t ∧ s . ∼ . t highest priority in the current partition. Finally, it sets the cur s chosen process as the current executing process of the cur- ∧ is part conf (cur s) ∧ (cur s) d ∧ s . ∼ . t 0 0 rent partition. ∧ s ∈ schedule process s ∧ t ∈ ;schedule process t 0 d 0 definition schedule-process :: StateR ⇒ StateR set where −→ s . ∼∆ . t schedule-process s ≡ if is-part conf (cur s) ∧ Finally, we conclude the satisfaction of the noninfluence (the ((partitions s)(cur s))) = NORMAL then (let s 0 = setRun2Ready s; property on the second-level specification and all other readyprs = {p. p∈the (procs s 0 (cur s 0)) ∧ information-flow security properties according to Theorem state (the (proc-state s 0 (cur s 0,p))) = READY}; 5 and the inference framework of the security model. selp = SOME p. p∈{x. state (the (proc-state s 0 (cur s 0,x))) = READY ∧ ESULTS AND ISCUSSION (∀ y∈readyprs. priority (the (proc-state s 0 (cur s 0,x))) ≥ 8 R D priority (the (proc-state s 0 (cur s 0,y))))}; 8.1 Evaluation st = the ((proc-state s 0)(cur s 0, selp)); proc-st = proc-state s 0; cur-pr = cur-proc-part s 0 in We use Isabelle/HOL as the specification and verification {s 0(|proc-state := system for ARINC SKs. The proofs are conducted in the IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. XX, NO. X, AUGUST 201X 12 TABLE 2: Specification and Proof Statistics TABLE 3: The Found Covert Channels

Specification Proof Covert Item PM ARINC standard VxWorks 653 XtratuM POK # of type/ # of lemma Channel LOC LOP definition /theorem (1) X X X X Security (2) 25 130 63 900 1 X X Model (3) ∗ X Top-level ∗ ∗ 116 680 193 5,200 6 (4) Specification (5) ∗ Refinement 6 100 42 600 1 (6) X X 2nd-level ∗ 45 330 111 1,100 4 X: existing; : potential; blank: not existing Specification Total 192 1,240 409 7,800 12 1) Queuing mode channel: If there is a queuing mode

Instantiation reuse channel from a partition a to a partition b, we ﬁnd a (150 LOP) Security Security Model covert channel from b to a in ARINC 653. UCEs (20 LOP) (900 LOP) 2) Leakage of port identiﬁers: In the Send/Receive

Top-level (5,000 LOP) Queuing Message and Write/Read Sampling Message services, there is no judgement on whether the accessing port belongs to the current partition. The port identiﬁer Instantiation in ARINC 653 is a covert channel. (80 LOP) Security Refinement (20 LOP) (600 LOP) 3) Shared space of port identiﬁers: In ARINC 653, the UCEs

2nd-level (1,000 LOP) Create Sampling Port and Create Queuing Port services create a port and return a new unique identifier as- signed by the kernel to the new port. A potential covert Fig. 7: Proof Reusability channel is to use a global variable for unused port identifiers. structured proof language Isar in Isabelle, allowing for proof 4) Partition scheduling: State related scheduling policies, text naturally understandable for both humans and comput- such as policies only selecting non-IDLE partitions, is a ers. All derivations of our proofs have passed through the covert channel. Isabelle proof kernel. 5) Shared space of process identifiers: In ARINC 653, The statistics for the effort and size of the specifi- the Create Process service creates a process and assigns cation and proofs are shown in Table2. We use 190 an unique identifier to the created process. A potential datatypes/definitions and ∼ 1,240 lines of code (LOC) of covert channel is to use a global variable for unused Isabelle/HOL to develop the security model, the refinement process identifiers. framework, and two levels of functional specifications. 409 6) Leakage of process identifiers: In the services of pro- lemmas/theorems in Isabelle/HOL are proven using ∼ cess management, there is no judgement on whether 7,800 lines of proof (LOP) of Isar to ensure the information- the process belongs to the current partition. Thus, the flow security of the specification. The work is carried out locally respects condition is not preserved on the events. by a total effort of roughly 12 person-months (PM). The The process identifier in ARINC 653 becomes a covert proof reusability is shown in Fig.7. The proof of the security channel. model is reusable at each level. The proof of our refinement Then we review the source code of implementations is reusable at each refinement step. The major part of proof to validate the covert channels. As we consider single- at each level is UCEs which is reusable at a lower level, for core separation kernels in this paper, we manually review example ∼ 5,000 LOP of the top-level specification is reused the single-core version of the implementations. Since the in the second-level specification. reviewed implementations are non-preemptive during the execution of hypercalls and have the same execution model as in our specification, it makes sense that we review the 8.2 Covert Channels and Attack Analysis implementations according to our specification. In EAL 7 When proving the UCEs in our original specification which evaluation of ARINC SKs, to ensure that the proved security is completely compliant with ARINC 653, a few covert really means that the implementation has the appropriate channels are found in the standard. Then, we conduct a behavior, a formal model of the low-level design is creat- code-to-spec review on VxWorks 653, XtratuM, and POK ed. Then, the correspondence between the model and the in accordance with our formal specification. The covert implementation is shown. Since our specification is at high channels are also found in them. Table3 shows the covert level, we use the unwinding conditions to manually check channels and their existence. the source code of hypercalls in the implementations, rather Covert channels 1, 2 and 6 actually exist in the ARINC than to show their correspondence. 653 standard. Covert channels 3 and 5 are potential ones and The result of code review is shown in Table3. The may be introduced to the specification by careless design. version of VxWorks 653 Platform we review is v2.2. The Covert channel 4 does not exist in ARINC 653. However, it covert channel 5 is not found during code review. However, is a potential flaw that should be taken into account. They the covert channel 4 potentially exists and the other four are described as follows. In Appendix A, we present how covert channels are found in VxWorks 653. The version of we find and fix them in our specification in detail. XtratuM we review is v3.7.3. The covert channel 1 exists IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. XX, NO. X, AUGUST 201X 13 and the covert channel 4 is a potential one in XtratuM. The ARINC SKs. By the proposed superposition refinement, version of POK we review is the latest one released in 2014. we have developed two levels of formal specification. We We find the covert channel 1 in POK. In Appendix B, we provided the mechanically checked proofs of information- present where the covert channels exist in the source code flow security to overcome covert channels in separation and how we find them in detail. kernels. We revealed some security flaws in ARINC 653 and The found covert channels pose threats to real-world implementations. In the next step, we will refine the second- ARINC SKs. In order to analyze the potential attacks, we level specification to lower levels by adding services of com- assume a threat model of ARINC SKs in which all user- plicated process management and intra-partition communi- level code in partitions is malicious and acting to break cation. Supporting multi-core is also under consideration in the security policy. The attacker’s goal is to read or infer future. Due to the kernel concurrency between cores, we the information in partitions that should remain secret to are using CSimpl [53] and its rely-guarantee framework to it according to the policy. Malicious programs in partitions specify and verify multi-core separation kernels. could utilise the covert channels to break the security policy. The security risk of covert channels 1, 2, and 6 is high. Secu- ACKNOWLEDGEMENT rity information in a secret partition can be easily leaked by attackers. The covert channel 4 is a timing channel. Covert We would like to thank David Basin of Department of channels 3 and 5 have low bandwidth in real-world systems. Computer Science, ETH Zurich, Gerwin Klein and Ralf We illustrate potential attacks to ARINC SKs in Appendix C Huuck of NICTA, Australia for their suggestions. in detail. REFERENCES 8.3 Discussion [1] G. Parr and R. Edwards, “Integrated Modular Avionics,” Air & The refinement-based specification and analysis method in Space Europe, vol. 1, no. 2, pp. 72 – 75, March - April 1999. the paper is compliant to the EAL 7 of CC certification. [2] AUTOSAR Specifications (Release 4.2), AUTOSAR GbR, July 2015. [3] J. Rushby, “Design and Verification of Secure Systems,” ACM With regard to the EAL 7, the main requirements addressed SIGOPS Operating Systems Review, vol. 15, no. 5, pp. 12–21, De- by formal methods are (1) a formal security policy model cember 1981. (SPM) of Target of Evaluation (TOE), (2) a complete semi- [4] J. Rushby, “Partitioning in Avionics Architectures: Requirements, Mechanisms, and Assurance,” U.S. Department of Transportation, formal functional specification (FSP) with an additional Federal Aviation Administration, DOT/FAA/AR-99/58, 2000. formal specification, and (3) a complete semi-formal and [5] ARINC Specification 653: Avionics Application Software Standard In- modular design with high-level TOE design specification terface, Part 1 - Required Services, Aeronautical Radio, Inc., Novem- (TDS). The security model in this paper represents the ber 2010. [6] Common Criteria for Information Technology Security Evaluation, security policies of ARINC SKs and is a formal model of 3rd ed., National Security Agency, 2012. the SPM. The two levels of functional specifications in this [7] U.S. Government Protection Profile for Separation Kernels in Environ- paper correspond to the FSP. The properties demonstrated ments Requiring High Robustness, National Security Agency, 2007. [8] I. Craig, Formal Refinement for Operating System Kernels. New York, on the SPM are formally preserved down to the FSP by the USA: Springer-Verlag, 2007, ch. 5. model instantiation and instantiation proofs. The functional [9] A. Velykis and L. Freitas, “Formal Modelling of Separation Kernel specification can be refined to a TDS model using the step- Components,” in Theoretical Aspects of Computing, LNCS, Springer, wise refinement. The refinement provides the formal link 2010, vol. 6255, pp. 230–244. [10] F. Verbeek, S. Tverdyshev, et al., “Formal Specification of a Generic between the FSP and the TDS. Finally, code-to-spec review Separation Kernel,” Archive of Formal Proofs, 2014. can be considered between the last formal model of the TDS [11] F. Verbeek, O. Havle, J. Schmaltz, et al., “Formal API Specification and the implementation to show the correspondence. In this of the PikeOS Separation Kernel,” in NASA Formal Methods, LNCS, Springer, 2015, vol. 9058, pp. 375–389. paper, we conduct a code review of the implementations [12] C. Heitmeyer, M. Archer, E. Leonard, and J. McLean, “Applying according to our specification. Formal Methods to a Certifiably Secure Software System,” IEEE The method in this paper can alleviate the efforts of CC Transactions on Software Engineering, vol. 34, no. 1, pp. 82–98, certification. The instantiation of the security model and the January - February 2008. [13] R. Richards, Design and Verification of Microprocessor Systems for refinement framework ease the development and make the High-Assurance Applications. Springer US, 2010, ch. Modeling and proof easier. As the same in the high assurance levels of CC Security Analysis of a Commercial Real-Time Operating System certification of INTEGRITY-178B and AAMP7G [52], formal Kernel, pp. 301–322. model and proof are part of the evaluation and directly [14] M. Wilding, D. Greve, R. Richards, and D. Hardin, Design and Ver- ification of Microprocessor Systems for High-Assurance Applications. submitted to the evaluation team for certification. Certainly, Springer US, 2010, ch. Formal Verification of Partition Manage- formal model and proof should be created in accordance ment for the AAMP7g Microprocessor, pp. 175–191. with a set of “safe” rules, such as rules of Isabelle/HOL in [15] L. Freitas and J. McDermott, “Formal Methods for Security in the Xenon Hypervisor,” International Journal on Software Tools for [49], which have been complied with by our specification. Technology Transfer, vol. 13, no. 5, pp. 463–489, Octorber 2011. On the other hand, for a specific TOE in CC certification, [16] T. Murray, D. Matichuk, M. Brassil, et al., “seL4: From General our specification may be revised and TDS model has to be Purpose to a Proof of Information Flow Enforcement,” in Proc. of developed. S&P 13, IEEE Press, CA, USA, May 2013, pp. 415 – 429. [17] M. Dam, R. Guanciale, N. Khakpour, H. Nemati, and O. Schwarz, “Formal Verification of Information Flow Security for a Simple Arm-based Separation Kernel,” in Proc. of CCS 13, ACM Press, 9 CONCLUSIONSAND FUTURE WORK Berlin, Germany, November 2013, pp. 223–234. [18] D. Sanan,´ A. Butterfield, and M. Hinchey, “Separation Kernel In this paper, we have presented a refinement-based spec- Verification: The Xtratum Case Study,” in Verified Software: Theories, ification development and security analysis method for Tools and Experiments, LNCS, Springer, 2014, vol. 8471, pp. 133–149. IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. XX, NO. X, AUGUST 201X 14

[19] M. Clarkson and F. Schneider, “Hyperproperties,” Journal of Com- [44] M. Clarkson, B. Finkbeiner, M. Koleini, K. Micinski, M. Rabe, and puter Security, vol. 18, no. 6, pp. 1157–1210, 2010. C. Sanchez,´ “Temporal Logics for Hyperproperties,” in Principles [20] J. Rushby, “Noninterference, Transitivity, and Channel-control Se- of Security and Trust, LNCS, Springer, 2014, vol. 8414, pp. 265–284. curity Policies,” SRI International, Computer Science Laboratory, [45] S. Eggert, R. Van der Meyden, H. Schnoor, and T. Wilke, “The 1992. Complexity of Intransitive Noninterference,” in Proc. of S&P 11, [21] A. Sabelfeld and A. Myers, “Language-based Information-flow IEEE Press, California, USA, May 2011, pp. 196–211. Security,” IEEE Journal on Selected Areas in Communications, vol. 21, [46] V. Ha, M. Rangarajan, D. Cofer, H. Rues, and B. Dutertre, “Feature- no. 1, pp. 5–19, January 2003. Based Decomposition of Inductive Proofs Applied to Real-Time [22] D. Oheimb, “Information Flow Control Revisited: Noninfluence Avionics Software: An Experience Report,” in Proc. of ICSE 04, = Noninterference+ Nonleakage,” in Computer Security, LNCS, IEEE Press, Scotland, UK, May 2004, pp. 304–313. Springer, 2004, vol. 3193, pp. 225–243. [47] G. Klein, “Operating System Verification - an Overview,” Sadhana, [23] T. Murray, D. Matichuk, M. Brassil, P. Gammie, and G. Klein, vol. 34, no. 1, pp. 27–69, February 2009. “Noninterference for Operating System Kernels,” in Certified Pro- [48] J. Andronick, R. Jeffery, G. Klein, et al., “Large-scale Formal grams and Proofs, LNCS, Springer, 2012, vol. 7679 , pp. 126–142. Verification in Practice: A Process Perspective,” In Proc. of ICSE [24] R. Back and K. Sere, “Stepwise Refinement of Action Systems,” 12, IEEE Press, Zurich, June 2012, pp. 1002–1011. in Mathematics of Program Construction, LNCS, Springer, 1989, vol. [49] H. Blasum, O. Havle, S. Tverdyshev, B. Langenstein, W. Stephan, 375, pp. 115–138. et al., “Used Formal Methods,” White Paper, EURO-MILS, 2015. [25] Niklaus Wirth, “Program Development by Stepwise Refinement,” [50] T.S. Hoang, “Security Invariants in Discrete Transition Systems,” Communications of the ACM, vol. 14, no. 4, pp. 221–227, April 1971. Formal Aspects of Computing, vol. 25, no. 1, pp. 59–87, January 2013. [26] R. Back,, and K. Sere, “Superposition Refinement of Reactive [51] D. McCullough, “Noninterference and the Composability of Se- Systems,” Formal Aspects of Computing, vol. 8, no. 3, pp. 324–346, curity Properties,” in Proc. of S&P 88, IEEE Press, Oakland, USA, May 1996. April 1988, pp. 177–186. [27] J. Abrial and S. Hallerstede, “Refinement, Decomposition, and [52] R. Richards, D. Greve, M. Wilding, “The Common Criteria, Formal Instantiation of Discrete Models: Application to Event-B,” Fun- Methods and ACL2,” in Proc. of ACL2 Workshop 04, Austin, Texas, damenta Informaticae, vol. 77, no. 1-2, pp.1–28, January 2007. USA, November 2004. [28] G. Klein, J. Andronick, K. Elphinstone, T. Murray, T. Sewell, [53] D. Sanan, Y. Zhao, H. Zhe, et al., “CSimpl: A Rely-Guarantee- R. Kolanski, and G. Heiser, “Comprehensive Formal Verification Based Framework for Verifying Concurrent Programs,” in Proc. of of an OS Microkernel,” ACM Transactions on Computer Systems, TACAS 17, Springer, Uppsala, Sweden, April 2017. (To appear) vol. 32, no. 1, pp.2:1 – 2:70, February 2014. [29] Y. Zhao, Z. Yang, D. Sanan, and Y. Liu, “Event-based Formalization Yongwang Zhao received the Ph.D. degree of Safety-Critical Operating System Standards: An Experience in computer science from Beihang University Report on ARINC 653 Using Event-B,” in Proc. of ISSRE 15, IEEE (BUAA) in Beijing, China, in 2009. He is an as- Press, MD, USA, November 2015, pp. 281 – 292. sociate professor at the School of Computer Sci- [30] Y. Zhao, D. Sanan, F. Zhang, and Y. Liu,, “Formal Specification and ence and Engineering, Beihang Univerisity. He Analysis of Partitioning Operating Systems by Integrating Ontol- has also been a Research Fellow in the School ogy and Refinement,” IEEE Transactions on Industrial Informatics, of Computer Science and Engineering, Nanyang vol. 12, no. 4, pp.1321 – 1331, August 2016. Technological University, Singapore, from 2015. [31] A. Gomes, “Formal Specification of the ARINC 653 Architecture His research interests include formal methods, Using Circus,” Master’s thesis, University of York, 2012. OS kernels, information-flow security, and AADL. [32] J. Delange, L. Pautet, and F. Kordon, “Modeling and Validation of ARINC653 architectures,” in Proc. of ERTS 10, Toulouse, France, May 2010. David Sanan´ received the Ph.D. degree in Soft- [33] P. Camara,´ J. Castro, M. Gallardo, and P. Merino, “Verification Sup- ware Engineering and Artificial Inteligent from port for ARINC-653-based Avionics Software,” Software Testing, the University of Malaga,´ Spain, in 2009. He Verification and Reliability, vol. 21, no. 4, pp. 267–298, December has been working as a Research Fellow in the 2011. Singapore University of Technology and Design, [34] T. Nipkow, M. Wenzel, and L. Paulson, Isabelle/HOL: A Proof Trinity College Dublin, and National University Assistant for Higher-order Logic. Berlin, Heidelberg: Springer-Verlag, of Singapore. In 2015 he joined Nanyang Tech- 2002. nological University in Singapore, where he is [35] A. Crespo, I. Ripoll, and M. Masmano, “Partitioned Embedded currently working as a research fellow. His inter- Architecture Based on Hypervisor: The XtratuM Approach,” in est research includes formal methods, and their Proc. of EDCC 10, IEEE Press, Valencia, Italy, April 2010, pp.67–72. application in separation micro-kernels. [36] J. Delange, and L. Lec, “POK, an ARINC 653-compliant Operating System Released under the BSD License,” in Proc. of 13th Real-Time Fuyuan Zhang received the Ph.D. degree in Linux Workshop, Prague, Poland, October 2011, pp.1–13. computer science from Technical University of [37] J. Millen, “20 years of Covert Channel Modeling and Analysis,” in Denmark in 2012. Currently, he is a research Proc. of S&P 99, IEEE Press, Oakland, USA, May 1999, pp. 113–114. fellow in School of Physical and Mathemati- cal Sciences, Nanyang Technological University, [38] Y. Zhao, D. Sanan, F. Zhang and Y. Liu, “Reasoning About Infor- Singapore. His research interests include formal mation Flow Security of Separation Kernels with Channel-based verification of IT systems, computer security and Communication,” in Proc. of TACAS 16, Springer, Eindhoven, The quantum computation. Netherlands, April 2016, pp. 791 – 810. [39] J. Goguen and J. Meseguer, “Security Policies and Security Model- s,” in Proc. of S&P 82, IEEE Press, Oakland, CA, USA, April 1982, pp. 11 – 20. [40] H. Mantel, D. Sands, “Controlled Declassification Based on In- Yang Liu received the Ph.D. degree in computer transitive Noninterference,” in Proc. of APLAS 04, Spinger, Taipei, science from National University of Singapore Taiwan, November 2004, pp. 129–145. (NUS) in 2010 and continued with his post- [41] M. Krohn, E. Tromer, “Noninterference for a Practical DIFC-Based doctoral work in NUS. Since 2012, he joined Operating System,” in Proc. of S&P 09, IEEE Press, Berkeley, CA, Nanyang Technological University as an Assis- May 2009, pp. 61–76. tant Professor. His research focuses on software [42] A.G. Ramirez, J. Schmaltz, F. Verbeek, et al., “On Two Models of engineering, formal methods and security. Par- Noninterference: Rushby and Greve, Wilding, and Vanfleet,” in ticularly, he specializes in software verification Proc. of SAFECOMP 14, Springer, Florence, Italy, September 2014, using model checking techniques. This work led pp. 246–261. to the development of a state-of-the art model [43] T. Levin, C. Irvine, C. Weissman, and T. Nguyen, “Analysis of checker, Process Analysis Toolkit. Three Multilevel Security Architectures,” in Proc. of CSAW 07, ACM Press, VA, USA, October 2007, pp. 37–46.