Docstoc

Partitioning Kernel Protection Profile

Document Sample
Partitioning Kernel Protection Profile Powered By Docstoc
					                Protection Profile for
                 Partitioning Kernels
in Environments Requiring Augmented High Robustness



                             Version 1.3




                             9 June 2003




                             Prepared By:
                          Lockheed-Martin,
                               Boeing,
                          Rockwell Collins,
                         Green Hills Software,
                            LynuxWorks,
                         Objective Interface,
                      and the University of Idaho
                         for The Open Group
               and the Information Assurance Directorate
                   of the National Security Agency
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness



Foreword
The purpose of this protection profile (PP) is to define the security functional requirements and the security
assurance requirements for a Partitioning Kernel target of evaluation (TOE). A Partitioning Kernel is that portion of
an operating system that is responsible for enforcing data isolation and information flow control among memory
partitions. This PP is based on the ―Common Criteria for Information Technology Security Evaluations, Version
2.1.‖
This PP has been prepared under the auspices of The Open Group by a team directed by the Lockheed Martin
Aeronautics Company and the Air Force Research Laboratory. The team consists of Rockwell Collins, Green Hills
Software, LynuxWorks, and the University of Idaho. Other significant participants in the development of the PP
were the Boeing Company, Objective Interface Systems, General Dynamics Decision Systems, the Navy (China
Lake), Computer Technology Associates, Raytheon, Aerospace Corporation, MITRE Corporation, and the National
Security Agency.
Comments for this PP may be sent to the National Security Agency (NSA), C12, ATTN: Mr. Mark Vanfleet, or by
e-mail to wvanflee@restarea.ncsc.mil. Comments may also be sent to Ben Calloni (Lockheed-Martin) by email to
ben.a.calloni@lmco.com. The comments should include the title of the document, the page, the section number, the
paragraph number, detailed comments, and recommendations.


                                            REVISION RECORD

        REVISION                                  DESCRIPTION                                      DATE
           draft          First Draft Submittal, Rockwell-Collins                               14 Mar 2002
           draft          Second Draft Submittal, Boeing                                        23 Oct 2002
        Version 1.0       Submittal for NSA approval, Boeing / The Open Group                   09 Dec 2002
        Version 1.1       Submittal for NSA approval, Lockheed-Martin / The Open Group          03 Feb 2003
        Version 1.2       Submittal for NSA approval, Lockheed-Martin / The Open Group          03 Mar 2003
        Version 1.3       Submittal for NSA approval, Lockheed-Martin / The Open Group          09 Jun 2003




9 June 2003                                     Version 1.3                                                2
           Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

                                                                 Table of Contents
1     Introduction ...........................................................................................................................................................5
    1.1      Identification ..................................................................................................................................................5
    1.2      Overview .......................................................................................................................................................5
    1.3      Conventions ...................................................................................................................................................6
    1.4      Glossary of Terms..........................................................................................................................................6
    1.5      Document Organization ............................................................................................................................... 10
2     Target of Evaluation (TOE) Description ............................................................................................................. 11
3     TOE Security Environment ................................................................................................................................. 13
    3.1      Threats ......................................................................................................................................................... 13
    3.2      Security Policy ............................................................................................................................................. 14
    3.3      Security Usage Assumptions ....................................................................................................................... 14
4     Security Objectives .............................................................................................................................................. 16
    4.1      TOE Security Objectives ............................................................................................................................. 16
    4.2      Security Objectives for the Environment ..................................................................................................... 17
5     IT Security Requirements .................................................................................................................................... 18
    5.1      TOE Security Functional Requirements ...................................................................................................... 18
      5.1.1          Class FAU: Security Audit .................................................................................................................. 18
      5.1.2          Class FCO: Communication ................................................................................................................ 19
      5.1.3          Class FDP: User Data Protection ......................................................................................................... 19
      5.1.4          Class FIA: Identification and Authentication ...................................................................................... 20
      5.1.5          Class FMT: Security Management ...................................................................................................... 20
      5.1.6          Class FPT: Protection of the TSF ........................................................................................................ 21
      5.1.7          Class FRU: Resource Utilization ......................................................................................................... 22
    5.2      TOE Security Assurance Requirements ....................................................................................................... 23
      5.2.1          Configuration management (ACM) ..................................................................................................... 23
      5.2.2          Delivery and operation (ADO) ............................................................................................................ 25
      5.2.3          Development (ADV)............................................................................................................................ 25
      5.2.4          Guidance documents (AGD)................................................................................................................ 28
      5.2.5          Life cycle support (ALC) ..................................................................................................................... 29
      5.2.6          Tests (ATE) ......................................................................................................................................... 30
      5.2.7          Vulnerability assessment (AVA) ......................................................................................................... 31
      5.2.8          Assurance maintenance plan (AMA) ................................................................................................... 32
    5.3      Security Requirements for the IT environment ............................................................................................ 34
      5.3.1          Class FMT: Security Management ...................................................................................................... 34
      5.3.2          Class FPT: Protection of the TSF ........................................................................................................ 35
      5.3.3          Vulnerability Assessment (AVA) ........................................................................................................ 35
      5.3.4          Delivery and Operation (ADO) ........................................................................................................... 35

9 June 2003                                                            Version 1.3                                                                               3
           Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

6     Rationale .............................................................................................................................................................. 36
    6.1      Security Objectives Rationale ...................................................................................................................... 36
      6.1.1          Explanation of Threats to Objectives Mapping ................................................................................... 38
      6.1.2          Explanation of Policies to Objectives Mapping ................................................................................... 40
      6.1.3          Explanation of Assumptions to Objectives Mapping ........................................................................... 41
    6.2      Security Requirements Rationale ................................................................................................................. 41
    6.3      Explicit Requirements Rationale ................................................................................................................. 48
    6.4      Rationale for Strength of Function .............................................................................................................. 49
    6.5      Rationale for Assurance Rating ................................................................................................................... 50
7     References ........................................................................................................................................................... 51




9 June 2003                                                            Version 1.3                                                                               4
         Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness


Introduction

This section contains overview information necessary to allow a Protection Profile (PP) to be registered through a
Protection Profile Registry. The ―Overview‖ section summarizes the profile in narrative form and provides
sufficient information for the reader to determine whether the PP is of interest. The ―Conventions‖ section provides
the notation, formatting, and conventions used in this PP. The ―Glossary of Terms‖ section gives basic definitions
of terms, which are specific to this PP. The ―Document Organization‖ section briefly explains how this document is
organized.


Identification

Title:       Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness,
             version 1.2d, 6 June 2003


Registration:      <to be provided upon registration>


Keywords:          Partitioning Kernel, Separation Kernel, Security Kernel, Real-Time Operating System


Overview
This Protection Profile (PP) specifies the security functional and assurance requirements for a Partitioning Kernel.
A Partitioning Kernel is that portion of an operating system that is responsible for enforcing data isolation and
information flow control among memory partitions. Only authorized information flows are allowed between
memory partitions, which contain software programs and data. Many operating system functions will remain
outside the Partitioning Kernel.
The Partitioning Kernel will be used in embedded real-time systems, such as telecom switches, commercial and
military avionics, automotive controls (including trains), medical devices, power plant controls (including nuclear),
mission computers, and amusement park ride controllers. These end systems have strict safety and security
requirements that result in a need for a high level of assurance for the partitioning functions.
For example, the Partitioning Kernel may be used by the Department of Defense as a foundation for building end
systems that are accredited to be Multilevel Secure (MLS). It may also be used by commercial industry to build end
systems that require a high degree of safety, such as process controllers in a nuclear power plant. Some end systems
may require a high degree of both safety and security, such as military avionics. Although the Partitioning Kernel
supports real-time applications, end systems built using the Partitioning Kernel need not be real-time. However, the
Partitioning Kernel per se only serves as a building block. This document does not address the security
requirements for end systems that might be built using the Partitioning Kernel.
The operating systems used for these various end systems have many characteristics in common. Expected
characteristics of the Partitioning Kernel include the following:
               Real-time.
               Deterministic.
               Multiple partitions (number constrained only by resource availability).
               Pre-defined static system configuration.
               Static and/or dynamic scheduling support.
               Hardware-supported data isolation techniques.
               Sanitization applied before switching partitions
               No direct users (subjects only).
9 June 2003                                        Version 1.3                                              5
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

             Support for ―user mode‖ device drivers.
             Support for short hardware exception handlers.
             No file system or built-in communication protocols.
             Small installation size.


Conventions
The CC permits four functional component operations, assignment, refinement, selection, and iteration, to be
performed on functional requirements, indicated as follows:
    •    Assignment: allows the specification of an identified parameter. Indicated with bold text and, if further
         operations are necessary by the Security Target author, italics.
    •    Refinement: allows the addition of details. Indicated with bold text and, if further operations are necessary
         by the Security Target author, italics.
    •    Selection: allows the specification of one or more elements from a list. Indicated with underlined text.
    •    Iteration: allows a component to be used more than once with varying operations. Not used in this PP.


Glossary of Terms
This profile uses the terms described in this section. Terminology that is not taken directly from the Common
Criteria, Version 2.1, Vol. 1 is noted in italics.
Assets — Information or resources to be protected by the countermeasures of a TOE.
Assignment — The specification of an identified parameter in a component.
Assurance — Grounds for confidence that an entity meets its security objectives.
Attack potential — The perceived potential for success of an attack, should an attack be launched, expressed in
terms of an attacker’s expertise, resources and motivation.
Augmentation — The addition of one or more assurance components from Common Criteria Part 3 to an EAL or
an assurance package.
Cache — A data structure used to temporarily store a subset of another data structure. A cache may be used to
store data and program instructions in a fast-access memory device or to store address translations for use by the
MMU.
Class — A grouping of families that share a common focus.
Code — See “program.”
Component — The smallest selectable set of elements that may be included in a PP, an ST, or a package.
Configuration data — The data describing the partitions, the connections among partitions, resources allocated to
each partition, and specific privileges granted to each partition. The configuration data define the information flow
control and data isolation policies that are enforced by the Partitioning Kernel. The configuration data are loaded
and made available to the Partitioning Kernel in a secure fashion that is application-specific.
Connection — Defined interfaces over which information flows occur. A connection has two or more end-points
that are assigned to unique partitions.
Countermeasure — Action, device, procedure, technique, or other measure that reduces the vulnerability of an
information system. [1]
Covert Channel — Unintended and/or unauthorized communications path that can be used to transfer information
in a manner that violates a security policy. [1]
Data Isolation — In the context of this PP, data isolation is the stipulation that the memory cells of a partition
cannot be modified by any subject other than the one that is exclusively bound to that partition.


9 June 2003                                      Version 1.3                                                 6
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

Denial of Service —Type of incident resulting from any action or series of actions that prevents any part of an IS
from functioning. [1] The incident could prevent the IS from functioning or from functioning in a timely manner.
Dependency — A relationship between requirements such that a leading requirement must be satisfied in order for
other requirements reliant on the leader to be able to meet their objectives.
Domain — Unique context (e.g., access control parameters) in which a program is operating; in effect, the set of
objects a subject has the privilege to access. [1] In the context of this PP, each partition and the Partitioning
Kernel are separate domains.
Element — An indivisible security requirement.
Evaluation — Assessment of a PP, ST or a TOE against defined criteria.
Evaluation Assurance Level (EAL) — A package consisting of assurance components from Common Criteria Part
3 that represents a point on the Common Criteria predefined assurance scale.
External IT entity — Any IT product or system, untrusted or trusted, outside of a TOE that interacts with the TOE.
Family — A grouping of components that share security objectives but may differ in emphasis or rigor.
Formal — Expressed in a restricted syntax language with defined semantics based on well-established
mathematical concepts.
Informal — Expressed in natural language.
Information Flow Control __ Procedure to ensure that information transfers are not made from a higher security
level domain to a lower security level domain. In the context of this PP, information flow control is an exception to
data isolation that allows specifically authorized communication (copying of data) from one partition to another.
Information flow control is the stipulation that only specifically authorized communications can occur.
Kernel — Program and associated data structures used to enforce the security policies of this PP and provide
support for subject operations.
Multilevel Security– Concept of processing information with different classifications and categories that
simultaneously permits access by users with different security clearances and denies access to users who lack
authorization. [1]
Object — An entity within the TSC that contains or receives information and upon which subjects perform
operations. For purposes of the Partitioning Kernel, shared memory segments are considered objects.
Organizational security policies — One or more security rules, procedures, practices, or guidelines imposed by an
organization upon its operations.
Partition — In the context of this PP, the set of memory cells and/or time intervals allocated to a subject.
Partitioning Kernel — The set of computer instructions operating in “privileged” or “supervisor” mode that is
responsible for implementing the data isolation and information flow control security policies.
Privilege — Authorization to enforce any or all of the SFP. A subject that has been given privilege is considered
trusted. See “trusted subject.”
Product — A package of IT software, firmware, and/or hardware providing functionality designed for use or
incorporation within a multiplicity of systems.
Program (also Software Program) — Sequence of instructions intended for interpretation by the processor. Also
referenced to in this protection profile as “code.” Programs are constructed by a system developer or TOE
developer.
Protection Profile (PP) — An implementation-independent set of security requirements for a category of TOEs that
meet specific consumer needs.
Reference monitor — The concept of an abstract machine that enforces access control policies.
Reference validation mechanism — An implementation of the reference monitor concept that possesses the
following properties: it is tamperproof, always invoked, and simple enough to be subjected to thorough analysis and
testing.


9 June 2003                                      Version 1.3                                                   7
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

Resource — Memory cells, processor utilization, and or permissions attributes that can be allocated to one
(isolated resource) or more (shared resource) domains. In general, anything usable or consumable by a subject or
by the Partitioning Kernel.
Sanitization —In the context of this PP, sanitization is the supporting process of removing residual information
from a shared resource so as to prevent the violation of the data isolation or information flow control stipulations.
The primary examples of sanitization are: (1) clearing processor registers before transferring control of the
processor to a subject; (2) clearing a block of memory before allocating it to a partition.
Security Function (SF) — A part or parts of a TOE that enforce a closely related subset of rules from the TSP.
Security Function Policy (SFP) — The security policy enforced by a SF.
Security objective — A statement of intent to counter identified threats and/or satisfy identified organization
security policies and assumptions.
Security Target (ST) — A set of security requirements and specifications used as a basis for evaluation of an
identified TOE.
Semiformal — Expressed in a restricted syntax language with defined semantics.
Service Request — Request from subject to the Partitioning Kernel to perform an operation on the subject’s behalf.
Strength of Function (SOF) — A qualification of a TOE security function expressing the minimum efforts
assumed necessary to defeat its expected security behavior by directly attacking its underlying security mechanisms.
Subject — An entity within the TSC that causes operations to be performed. Subjects can come in two forms:
trusted and untrusted (see following definitions). Specifically, a subject is a set of computer instructions operating in
“user” or “non-privileged” mode, together with associated state information, where the execution of the
instructions is governed by the TOE Security Policy. Each subject is bound to exactly one partition. A set of
instructions may be memory-mapped into more than one partition, in which case each mapping corresponds to a
separate subject with its own state information.
System — A specific IT installation, with a particular purpose and operational environment.
Target of Evaluation (TOE) — An IT product or system and its associated administrator and user guidance
documentation that is the subject of an evaluation.
Timely — Characteristic of operation (e.g., information transfer) that meets deadlines established by the system
developer. To support timely operations, the system developer will require an accounting of processor execution-
time utilization for the Partitioning Kernel and the subjects. The Partitioning Kernel must have a predictable means
of allocating the processor to subjects (e.g., time slices, priorities, deadlines, or combinations thereof) whose
behavior can be analyzed to show the established deadlines will be met.
TOE resource — Anything useable or consumable in the TOE.
TOE Security Functions (TSF) — A set consisting of all hardware, software, and firmware of a TOE that must be
relied upon for the correct enforcement of the TSP.
TOE Security Functions Interface (TSFI) — A set of interfaces, whether interactive (man-machine interface) or
programmatic (application programming interface), through which TOE resources are accessed, mediated by the
TSF, or information is obtained from the TSF.
TOE Security Policy (TSP) — A set of rules that regulate the management, protection and distribution of assets
within a TOE.
TOE security policy model — A structured representation of the security policy to be enforced by the TOE.
Trusted subject — With respect to a specific SFP, a subject that is trusted to enforce any or all of the SFP, and has
been tested and verified to operate only as intended.
TSF data — Data created by and for a TOE, that might affect the operation of the TOE.
TSF Scope of Control (TSC) — The set of interactions that can occur with or within a TOE subject to the rules of
the TSP.
Untrusted subject — A subject that is not trusted with respect to any or all of the specific SFPs being enforced.

9 June 2003                                      Version 1.3                                                  8
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

User — Any entity (human user or external IT entity) outside the TOE that interacts with the TOE. In the context of
the Partitioning Kernel, there are no direct users. Rather, the term “user” identifies the programmers, system
developers, integrators, and administrators who make use of the Partitioning Kernel or the system in which the
Partitioning Kernel is embedded.




9 June 2003                                    Version 1.3                                               9
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness


Document Organization

Section 1 provides the introductory material.
Section 2 provides a description of the TOE and its use to aid in understanding the security requirements.
Section 3 provides a discussion of the expected environment for the TOE. This section also defines the set of threats
that are to be addressed by either the technical countermeasures implemented in the TOE software or through the
environmental controls.
Section 4 defines the security objectives for both the TOE and the TOE environment.
Section 5 contains the security functional requirements and the security assurance requirements derived from the
Common Criteria, Part 2 and 3, respectively, that must be satisfied by the TOE.
Section 6 provides rationale to explicitly demonstrate that the information technology security objectives satisfy the
policies and threats. Arguments are provided for the coverage of each policy and threat. The section then explains
how the requirements are complete relative to the objectives, and that each security objective is addressed by one or
more component requirements. Arguments are provided for the coverage of each objective. Section 6 also explains
the use of explicit requirements not drawn from the CC, strength of function issues, and the assurance rationale..
Application notes are included with the requirements in Section 5.
The appendix provides additional information on the use and implementation of the Partitioning Kernel as
envisioned by the authors.




9 June 2003                                     Version 1.3                                                  10
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness


Target of Evaluation (TOE) Description
This Protection Profile (PP) specifies the security functional and assurance requirements for a Partitioning Kernel
together with the underlying hardware that supports it. The end systems for which the Partitioning Kernel are
intended often have strict requirements for safety as well as for information security. The Partitioning Kernel
provides high-assurance partitioning and information flow control that is tamperproof and non-bypassable in a way
that allows other software programs to meet those security and safety requirements. Examples of these software
programs that can be implemented outside of the Partitioning Kernel, but are dependent on its secure partitioning
functions, include security reference monitors, device drivers, file managers, and message-passing services.
The Partitioning Kernel functionally divides a host processor into multiple processing engines that are logically
separated in both space and time (see Figure 2-1). It is the basic component of an operating system, with minimum
functionality that includes the following:
            Time and space partitioning
            Data isolation
            Information flow control
            Residual information protection
            Minimum interrupt servicing
            Semaphores
            Timers.



                                                                      CONCEPTUAL MULTIPLE
       PHYSICAL MULTIPLE                                                 PROCESSORS
          PARTITIONS
                                                                  A
                                                                                                 I/O
                                 A                                       uPROC
                                 B                                                      MEM               A
                       A,B,C     C

                        A        A
     A B C                                                        B
                                                                                                 I/O




                                                                         uPROC
                        B
                        C
                                                                                        MEM               B
      uPROC
                                 B         B
                                           C                     C
                                                                                                 I/O




                                 C                                       uPROC
                                                                                        MEM               C

                  Figure 0-1 Conceptual Processor System with Strong Isolation

The Partitioning Kernel maintains separation between partitions, allowing only authorized information flows
between the partitions. Configuration data, usually set at installation, defines the authorized information flows. To
help ensure that unauthorized transfers of information between partitions do not occur, the Partitioning Kernel may
use sanitization of hardware registers and memory blocks to help ensure that unauthorized transfers of information
between partitions do not occur. To ensure that the Partitioning Kernel is tamperproof and non-bypassable, the
Partitioning Kernel relies on certain characteristics of the underlying hardware, including:
9 June 2003                                       Version 1.3                                                11
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

        A memory access control capability that can limit access to physical memory locations and any cached
         copies based on their addresses
        Prevention of modification of the memory access control capability except by software executing with the
         appropriate privilege.
        Prevention of any actions that can bypass partition boundaries except by software executing with the
         appropriate privilege.
        A means for immediate transfer of control to the Partitioning Kernel upon attempts by software not
         executing with the appropriate privilege to execute an instruction that would bypass the memory partition
         boundaries. The offending instruction shall not be allowed to complete its action..
        A means for immediate transfer of control to the Partitioning Kernel upon attempts by software not
         executing with the appropriate privilege to execute an instruction that could enable or disable interrupts,
         change the processor privilege level, or directly or indirectly bypass partitioning boundaries. The offending
         instruction shall not be allowed to complete its action.
        Absence of hardware that could potentially be used by subjects to violate data isolation and information
         flow control, e.g. a Direct Memory Access mechanism that bypasses the memory access control.
Time is partitioned by the Partitioning Kernel into time intervals, which are allocated to each subject. Time may be
statically allocated (time-slice scheduling), or it may be allocated on demand based on preemptive priorities,
deadlines, or some other scheduling principle. Each subject is allowed exclusive use and control of the CPU and
related hardware during its time partition. During partition transitions, the Partitioning Kernel has control of the
CPU and read/write access to the entire physical memory.
The choice of scheduling algorithm used by the Partitioning Kernel is not specified by this Protection Profile. If
time-intervals are not statically allocated, the variations in computing time utilized by subjects may potentially be
used as covert channels and/or means to implement denial-of-service attacks. The potential risks should be clearly
identified in the guidance documentation delivered with the Partitioning Kernel.
The Partitioning Kernel mediates inter-partition communications on a single processor. Any communication across
processor boundaries, or use of external devices, will require additional software not covered by this PP. Most
operating system functions will also require additional software not covered by this PP.
To ensure that the Partitioning Kernel reaches a secure initial state, control must be reliability passed to the
Partitioning Kernel after power-on or processor reset. This may be done by hardware directly or by software that
executes first and then passes control to the Partitioning Kernel.
Some end systems may require additional functionality within the Partitioning Kernel beyond the minimum set
listed in this TOE description. For example, instrumentation is a capability that allows partitions with sufficient
privilege to have visibility into kernel operations, allowing for error detection and diagnosis. Instrumentation is
often required when building military avionics due to the complexity of the systems. Additional kernel functionality
such as instrumentation may have security ramifications, and must meet the security requirements of this PP.
Vendors may need to provide more functions in the Partitioning Kernel than those specified here to meet the needs
of their customers.
Since end systems using the Partitioning Kernel vary widely, to ensure the security and integrity of the Partitioning
Kernel, the end system must provide a few specific functions, in particular:
        A trusted loading mechanism that guarantees that the correct code and configuration data are installed on
         the hardware.
        Configuration data must allocate privileges to specific partitions that are permitted to perform privileged
         operations, such as authorized modifications to the configuration data.
The security certification of the system in which the Partitioning Kernel is used must consider the trustworthiness of
those mechanisms and processes. Also, if a non-static time partitioning mechanism is employed, the risks of covert
timing channels and denial of service threats must be considered. If the Partitioning Kernel does not flush cache
memories during the transition of the processor from one partition to another, the risks of covert timing channels
based on cache manipulation must also be considered.


9 June 2003                                      Version 1.3                                               12
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness


TOE Security Environment

The security environment for the functions addressed by this profile includes threats, security policy, and usage
assumptions, as discussed below.
The Partitioning Kernel guarantees that data isolation and information flow control are not violated. The partitions
are initialized to provide strong serviceable isolation between security-critical functions. The system built on the
Partitioning Kernel will be used to maintain the isolation of partitions operating at different security levels and allow
only authorized information flows between partitions. Functions requiring isolation include those that involve
cryptography, key management, process control, alarm processing, network management, and access control.



Threats
The specific threats to security that must be countered by the Partitioning Kernel are listed in this section. In the
context of an embedded system, the Partitioning Kernel does not have any direct interactions with human beings at
run time. However, subjects do interact with the TOE at run time and human beings are involved in configuration,
manufacturing, and maintenance. These may be the source of threats based on the procedures and processes used
and their assurance. For example, the System Integrator that configures the system may be trusted to not be
careless, willfully negligent, or hostile. The Manufacturing Personnel may be trusted to not be willfully negligent or
hostile. The Maintenance Personnel may not be trusted. Likewise, subjects may be trusted or untrusted. A subject
that helps to initialize the Partitioning Kernel may be trusted to not be careless, willfully negligent, or hostile. On
the other hand, other subjects may not be tested and verified to the same degree.


T.CONFIG_CORRUPT            A malicious or faulty subject may modify or corrupt the Partitioning Kernel's
                            configuration data defining resource allocations and inter-partition communications by
                            accessing memory outside its partition.
T.DOS                       A malicious or faulty subject may block other subjects from using the processor by
                            exhausting shared resources.
T.EAVESDROP                 A malicious or faulty subject may intercept an inter-partition communication for which it
                            is not authorized by retrieving data from an unsanitized resource or by accessing
                            information outside its own partition.
T.HARDWARE_FAIL             The hardware on which the Partitioning Kernel is installed may fail to provide the
                            functions upon which the Partitioning Kernel depends for correct operation due to
                            implementation errors, faulty design, or malicious intent.
T.NON-SECURE_STARTUP       Control may fail to be reliably passed to the Partitioning Kernel after power-on
                  or processor reset.
T.KERNEL_INDISCRETE         A subject may gain unauthorized information regarding another subject from the
                  Partitioning Kernel.
T.KERNEL_TAMPER             A malicious or faulty subject may tamper with the Partitioning Kernel code or data to
                            modify or disable the partitioning mechanism by accessing memory outside its partition
                            or executing instructions for which it does not have privilege, or exploiting a weakness in
                            a Partitioning Kernel service request interface.
T.MASQUERADE                A malicious or faulty subject may masquerade as a different subject by tampering with
                            Partitioning Kernel data structures or providing invalid parameters to Partitioning Kernel
                            service calls.
T.NONDETERMINISTIC                    A subject may be denied required resources due to the Partitioning Kernel
                            failing to provide provably worst-case bounded execution time or memory usage.
                            Note: Suspending a service request to implement a scheduling policy is not to be
                            construed, per se, as nondeterminism on the part of the Partitioning Kernel.
9 June 2003                                       Version 1.3                                                13
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

T.POOR_DESIGN             Unintentional or intentional errors in requirement specification, design or development of
                          the Partitioning Kernel may occur.
T.POOR_IMPLEMENTATION Unintentional or intentional errors in implementing the design of the Partitioning
                 Kernel may occur.
T.POOR_TEST               Incorrect behavior resulting from faulty design or implementation may not be detected by
                          the testing program.
T.POOR_TRANSFER           An authorized information flow may occur untimely or data is lost and/or corrupted
                          during the transfer.
                          Note: Suspending an information flow to implement a scheduling policy is not to be
                          construed, per se, as poor transfer on the part of the Partitioning Kernel.
T.SYSACC                  A malicious or faulty subject may gain unauthorized access to Partitioning Kernel
                          services reserved for trusted subjects.
T.UNAUTH_ACCESS           A malicious or faulty subject may access (read and/or write) memory cells and/or devices
                          that have not been allocated to it.
T.UNSANITIZED             A subject may gain unauthorized information from an improperly sanitized shared
                          resource.
T.WRONG_CODE              The code of the Partitioning Kernel may be corrupted, or an incorrect version substituted,
                          prior to being loaded into the computer in which it will execute.
T.WRONG_COMM              An unauthorized information flow may occur between partitions. This includes
                          exploiting a covert channel for the unauthorized information flow.
T.WRONG_CONFIG            The configuration data used by the Partitioning Kernel to control resource allocations and
                          inter-partition communications may not accurately reflect the end user’s intentions
                          regarding partitioning and information flow.


Security Policy

Policy statements whose enforcement must be provided by the Partitioning Kernel’s security mechanisms:


P.SHARED_MEMORY           The Partitioning Kernel shall ensure that each shared memory segment can be accessed
                          only by those partitions explicitly authorized to do so, and only in the allowed mode,
                          read-only or read/write.
P.UNIQUE_PARTITION The Partitioning Kernel shall ensure that each subject is bound to exactly one partition,
                   and that each partition is bound to exactly one subject.
P.ISOLATION               Unless otherwise authorized by the Partitioning Kernel's configuration data, the
                          Partitioning Kernel shall ensure that a subject can read information from, or write
                          information to, only the partition to which it is bound.
P.INFO_FLOW               The Partitioning Kernel shall ensure that only explicitly authorized information flows
                          occur between partitions or into or out of a partition and that the information flows are
                          not prevented by partitions not involved in the transfer.


Security Usage Assumptions

The following usage assumptions constitute requirements on the system in which the Partitioning Kernel is
embedded. These assumptions are to be addressed by the system-level certification process.




9 June 2003                                    Version 1.3                                                14
       Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

A.TRUSTED_LOAD          It is assumed that the code and configuration data for the Partitioning Kernel are reliably
                        loaded into the processor and are reliably protected from unauthorized modification.
A.SCHEDULER_RMI         (Risk Mitigation for non-static scheduler) If a non-static time partitioning mechanism is
                        employed, it is assumed that the potential risks of covert timing channels and denial of
                        service threats have been addressed.
A.CACHE_MEM_RMI         (Risk Mitigation for not flushing cache memories) If the Partitioning Kernel does not
                        flush cache memories during the transition of the processor from one partition to another,
                        then it is assumed that the risks of covert timing channels based on cache manipulation
                        have been addressed.




9 June 2003                                  Version 1.3                                                15
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness


Security Objectives
 This section defines the security objectives for the TOE and its environment. These objectives are suitable to
counter all identified threats and cover all identified security policies and assumptions. The names of the TOE
security objectives have an ―O.‖ prefix and the environment objective names have an ―OE.‖ prefix.


TOE Security Objectives

    O.CLEAR_RESIDUAL                         The Partitioning Kernel shall clear residual information prior to
                                             reassigning a resource to a subsequent subject.
    O.CONFIG_MGMT                            Every delivered version of the Partitioning Kernel shall be uniquely
                                             identified, and all changes to the Partitioning Kernel and its
                                             development evidence shall be documented, tracked, and controlled.
    O.CONFIG_SUPPORT                         A combination of instruction materials and support tools shall be
                                             provided to aid the end user in constructing the Partitioning Kernel's
                                             configuration data that accurately reflect the end user’s intentions
                                             regarding partitioning and information flow.
    O.FAIL_SAFE                              The Partitioning Kernel shall ensure that hardware-detected faults do
                                             not result in violations of the data isolation and information flow
                                             control security policies. This shall apply to all hardware-detected
                                             faults, whether they occur within the Partitioning Kernel domain or
                                             within a subject's domain.
    O.INFORMATION_FLOW                       The Partitioning Kernel shall enforce information flow control between
                                             partitions, and into and out of partitions, as specified in its
                                             configuration data. Where one way communication is configured
                                             between partitions the communication mechanism will minimize covert
                                             back channels in flow control mechanisms.
    O.PARTITION_CREATE                       As directed by its configuration data, the Partitioning Kernel shall
                                             create and initialize exactly one partition for each subject, and allocate
                                             all required resources to it.
    O.PARTITION_PROTECT                      Except where shared memory areas are explicitly authorized by the
                                             Partitioning Kernel's configuration data, the Partitioning Kernel shall
                                             maintain separation between partitions, ensuring that each subject can
                                             read from and write to only the partition to which it is bound.
    O.RESOURCE_GUARANTEE                     The Partitioning Kernel shall guarantee that all resources allocated to a
                                             partition by the Partitioning Kernel’s configuration data shall be
                                             available to that partition. This includes memory allocated to the
                                             partition, any Partitioning Kernel resources necessary to support
                                             execution or communication, and statically allocated execution times, if
                                             any.
                                             Note: The user manual may document allowed tolerance in allocated
                                             execution time and allocated memory that may not be fully available.
    O.SELF_PROTECT                           The Partitioning Kernel shall maintain a domain for its own execution
                                             to protect itself from interference or tampering.
    O.SELF_TEST                              The TOE shall provide self test to demonstrate correct operation of the
                                             TSF.
                                              .
    O.SOUND_DESIGN                           The design of the Partitioning Kernel shall account for, and be
                                             traceable to, all of its functional requirements.

9 June 2003                                       Version 1.3                                               16
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

    O.SOUND_IMPLEMENTATION                    The implementation of the Partitioning Kernel shall be an accurate
                                              instantiation of its design.
    O.TESTING                                 The Partitioning Kernel shall undergo independent Security
                                              Verification (SV) Testing, based at least in part on an independent
                                              vulnerability analysis.
    O.TRUSTED_DELIVERY                        A trusted delivery capability shall be provided to ensure that the code
                                              for the Partitioning Kernel that is to be loaded into the processor is a
                                              valid copy of the identified version.
    O.TRUSTED_STARTUP                         A trusted startup capability shall be provided to ensure that the
                                              Partitioning Kernel reaches a secure initial state after power-on or a
                                              processor reset.




Security Objectives for the Environment

The following requirements must be satisfied by the environment in which the Partitioning Kernel operates in order
to ensure that the Partitioning Kernel can enforce the security policy. Certification artifacts of a system in which the
Partitioning Kernel is used should include evidence that the system complies with these requirements.


    OE.TRUSTED_LOAD                           A trusted load capability shall be provided to ensure that the code and
                                              configuration data for the Partitioning Kernel are reliably loaded into
                                              the processor and are protected from unauthorized modification.
    OE.SCHEDULER_RMI                          If a non-static time partitioning mechanism is employed, an explanation
                                              shall be provided for how the risks of covert timing channels and denial
                                              of service threats have been addressed.
    OE.CACHE_MEM_RMI                          If the Partitioning Kernel does not flush cache memories during the
                                              transition of the processor from one partition to another, an explanation
                                              shall be provided for how that the risks of covert timing channels based
                                              on cache manipulation have been addressed.




9 June 2003                                      Version 1.3                                                17
         Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness


IT Security Requirements

 The TOE functional security requirements support:
                  Security audit
                  Non-repudiation of origin
                  Information flow control
                  Security attributes
                  Residual information protection
                  Security management
                  Abstract machine testing
                  Failure with preservation of secure state
                  Non-bypassability
                  Domain separation
                  Reliable time stamps
                  Self test
                  Maximum quotas

The TOE assurance security requirements support an evaluated assurance level of seven (EAL7), augmented by:
                  systematic flaw remediation requirements (ALC_FLR.3)
                  maintenance of assurance requirements (AMA_AMP.1, AMA_CAT.1, AMA_EVD.1 and
                   AMA_SIA.2)


TOE Security Functional Requirements

The TOE security functional requirements are listed below.


     Class FAU: Security Audit


FAU_GEN.1 Security Audit Data Generation
The TSF shall be able to generate an audit record of the following auditable events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the [selection: not specified] level of audit; and
c) Memory access violations. (FAU_GEN.1.1, amplified by assignment)
         Application note: The generation of audit records is implementation dependent; however, a
         minimal implementation is expected. An interface must be provided so that a trusted (or
         privileged) subject can retrieve the audit data.
         Application note: In item (a), in a system where the audit function is always enabled when
         application software is executing it is not necessary to have an explicit audit record for start-up
         and shutdown of the audit function. It may be assumed.
         Application note: In item (b), ―not specified‖ indicates that no audit events are selected from the
         requirements in the CC and passes responsibility for specifying more to item (c). Partitioning
         Kernel implementers are free to add audit events.
         Application note: Persistence of the audit record(s) through a processor reset is not required.


9 June 2003                                        Version 1.3                                                 18
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

The TSF shall record within each audit record at least the following information:
a) Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the functional components included in the
PP/ST, [assignment: no other information]. (FAU_GEN.1.2, amplified by assignment)


         Application note: All audited events are failures.
         Application note: (b) is assigned so that no more information is supplied.
         Application note: Date and Time of the event may be recorded in the system’s native format
         without synchronization to an external time source.
         Dependencies: 0. FPT_STM.1 Reliable Time Stamps


     Class FCO: Communication
FCO_NRO Non-Repudiation of Origin
The TSF shall provide the identity of the sender of information on request by the recipient. (FCO_NRO_EXP.1.1)
         Application note: Trusted certificates, as envisioned by FCO_NRO.1 and FCO_NRO.2, are not
         required. However, some subjects will require the authenticated identity of the sender of
         information received via an inter-partition channel. For example, a reference monitor would need
         to know the identity of a subject requesting to access an object. To avoid masquerading threats
         and potential covert channels, the identity should come from a source independent of the sender
         (e.g., from the configuration data). The identity should be constructed such that it does not violate
         any security policies.
         Dependencies: None


     Class FDP: User Data Protection
FDP_IFC.2 Complete Information Flow Control
The TSF shall enforce the information flow control SFP defined in the Partitioning Kernel's configuration data on
inter-partition connections and shared memory segments defined in the Partitioning Kernel's configuration data and
on all operations that cause information to flow to and from subjects covered by the SFP. (FDP_IFC.2.1, amplified
by assignment)
         Application note: The information flow control security policy contained in the Partitioning
         Kernel’s configuration data defines communication channels between partitions and between
         partitions and objects. Any information from the sender’s partition may be sent over a channel.
         The Partitioning Kernel does not make access control decisions for individual transfers. Rather,
         the channels are established during initialization based on the Partitioning Kernel's configuration
         data and remain in place permanently.
The TSF shall ensure that all operations that cause any information in the TSC to flow to and from any subject in the
TSC are covered by an information flow control SFP. (FDP_IFC.2.2)
         Application note: Most information flow is between partitions. But some information, such as the
         current value of a real time clock, may be obtained from the Partitioning Kernel or I/O device.
         Also, a partition may be granted permission to control an I/O device. The SFP contained in the
         Partitioning Kernel’s configuration data must address all such operations and support selective
         granting of privileges to partitions/subjects.
The TSF shall prevent the disclosure, modification, and loss of use (including untimely transfer) of
information when it is transferred between subjects over the authorized channels. (FDP_IFC_EXP.1.1).
         Dependencies: 0 FDP_IFF.1 Simple Security Attributes


9 June 2003                                      Version 1.3                                                19
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

FDP_IFF.1 Simple Security Attributes
The TSF shall enforce the information flow control SFP defined in the Partitioning Kernel’s configuration data
based on the following types of subject and information security attributes: connections between partitions and
between partitions and shared memory defined in the Partitioning Kernel’s configuration data. (FDP_IFF.1.1,
expanded by assignment)
The TSF shall permit an information flow between a controlled subject and controlled information via a controlled
operation if the following rules hold: for each operation between subjects, and for each operation between subject
and shared memory segment, a connection must be defined in the Partitioning Kernel configuration data.
(FDP_IFF.1.2, amplified by assignment)
         Application Note: FDP_IFF.1.3, 1.4, 1.5, are left to be defined in the vendors' STs for the purpose
         of defining privileges and their operations.
         Application Note: FDP_IFF.1 also has a dependency on FMT_MSA.3, Static Attribute
         Initialization. In the case of the Partitioning Kernel, all attributes are defined explicitly in the
         Partitioning Kernel’s configuration data. This data is created outside of the Partitioning Kernel,
         therefore FMT_MSA.3 is allocated to the environment.
         Dependencies: FDP_IFC.1 (subset of 0 FDP_IFC.2 Complete Information Flow Control)

FDP_RIP.2 Full Residual Information Protection
The TSF shall ensure that any previous information content of a resource is made unavailable upon the allocation of
the resource to, deallocation of the resource from, all objects. (FDP_RIP.2.1, amplified by selection)
         Application note: It is the Partitioning Kernel implementer’s choice as to which time the resource
         is sanitized.
         Dependencies: None


     Class FIA: Identification and Authentication
Requirements from this class are allocated to the environment.


     Class FMT: Security Management
Requirements from this class are allocated to the environment with the exception of one explicit component
(FMT_MCD_EXP.1) introduced here that is related to the intent of this class.

FMT_MCD_EXP.1 Management of Configuration Data
The TSF shall provide a capability whereby a partition with the appropriate privileges may provide a new set of
configuration data to the Partitioning Kernel and read back the current configuration data. (FMT_MCD_EXP.1.1)
         Application Note: The IT environment may provide other means to provide for modification of Partitioning
         Kernel’s configuration data and may prevent the Partitioning Kernel from modifying it. The modification
         of Partitioning Kernel’s configuration data may be a subset (e.g., just the partition schedule data).
         However, the responsibility for ensuring the modified configuration data meets the end user's intentions is
         assigned to the IT environment. If the configuration data is static, read back of configuration data may be
         provided through a system build mechanism. Also, this does not imply the TOE must have access to a
         storage device.
An off-line support tool shall be provided to aid an Administrator in constructing the Partitioning Kernel's
configuration data that accurately reflect the end user’s intentions regarding data isolation and information flow
control. (FMT_MCD_EXP.1.2)
         Application note: It is anticipated that without support tools, constructing a correct set of
         configuration data could be error-prone. A suitable tool or set of tools should be provided that
         will check for consistency, display the Partitioning Kernel’s configuration data in an easy-to-
         understand format, and otherwise aid in constructing the desired data.
         Dependencies: None
9 June 2003                                      Version 1.3                                                    20
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

     Class FPT: Protection of the TSF
FPT_AMT.1 Abstract Machine Testing
The TSF shall run a suite of tests during initial startup to demonstrate the correct operation of the security
assumptions provided by the abstract machine that underlies the TSF. (FPT_AMT.1.1, amplified by selection)
         Application note: In some operational scenarios a quick startup that foregoes test may be
         necessary. This may be acceptable if it can be demonstrated that the likelihood of a failure since
         the last successful operation is sufficiently low.
         Dependencies: None

FPT_FLS.1 Failure with preservation of secure state
The TSF shall preserve a secure state when the following types of failures occur: failures that are detected by the
processor hardware. (FPT_FLS.1.1, amplified by selection)
         Application note: The Partitioning Kernel cannot protect itself, or the subjects, against all types of
         hardware failures. For example, a radiation induced change of a single bit in a memory access
         control register could result in an incorrect (but valid) memory location being accessed. This
         would not be detected by the hardware.
         Dependencies: ADV_SPM.1 (subset of 0 Formal TOE security policy model (ADV_SPM.3))

FPT_IGS_EXP.1 Installation, Generation, and Startup
Requirement for trusted load (i.e. FPT_IGS_EXP.1.1) has been allocated to the environment.
A trusted startup capability shall be provided to ensure that control is reliably passed to the Partitioning Kernel after
power-on or a processor reset. (FPT_IGS_EXP.1.2)

FPT_RVM.1 Non-bypassability of the TSP
The TSF shall ensure that TSP enforcement functions are invoked and succeed before each function within the TSC
is allowed to proceed. (FPT_RVM.1.1)
         Application Note: "TSP enforcement functions" are interpreted to include the validation of all
         service requests to ensure that the subject has permission to issue the requests and that the requests
         will not cause the TSF to fail to enforce the security policy.
         Dependencies: None

FPT_SEP.1 TSF domain separation
The TSF shall maintain a security domain for its own execution that protects it from interference and tampering by
untrusted subjects. (FPT_SEP.1.1)
The TSF shall enforce separation between the security domains of subjects in the TSC. (FPT_SEP.1.2)
         Application note: This requirement addresses sanitization of all resources allocated to subjects,
         including MMU, cache, processor registers, and memory blocks.
         Dependencies: None

FPT_STM.1 Reliable Time Stamps
The TSF shall be able to provide reliable time stamps for its own use. (FPT_STM.1.1)
         Application Note: Whatever native format the system keeps time in is acceptable.
         Synchronization to an external time source is not required.
         Dependencies: None.




9 June 2003                                       Version 1.3                                                 21
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

FPT_TST.1 TSF Self Test
The TSF shall run a series of tests periodically during normal operation to demonstrate the correct operation of the
TSF. (FPT_TST.1.1, amplified by assignment)
         Application note: In an embedded, real-time system, periodic self-test may need to be scheduled
         in an application-dependent manner. Therefore, although part of the TOE, this function cannot be
         an autonomous function of the Partitioning Kernel per se. Also, some tests for hardware failure
         (e.g., illegal instructions and MMU failures) can only be invoked outside of the Partitioning
         Kernel when operating in ―user mode.‖
The TSF shall provide trusted subjects with the capability to verify the integrity of TSF data. (FPT_TST.1.2,
modified)
         Application note: The term ―authorized users‖ has been modified to ―trusted subjects‖. The Partitioning
         Kernel has no requirement for user-subject binding and it is the subject itself that is ―trusted‖ in the
         Partitioning Kernel’s configuration data.
         Application note: The ―capability to verify‖ is to be interpreted broadly. For example, at one
         extreme, the Partitioning Kernel might perform all the integrity checks and simply return a ―good‖
         or ―bad‖ response to the subject. At the other extreme, the Partition Kernel might simply allow
         the subject to view the data and the subject would perform all the integrity checks.
The TSF shall provide trusted subjects with the capability to verify the integrity of stored TSF executable code.
(FPT_TST.1.3, modified)
         Application note: The term ―authorized users‖ has been modified to ―trusted subjects.‖ The Partitioning
         Kernel has no requirement for user-subject binding and it is the subject itself that is ―trusted‖ in the
         Partitioning Kernel’s configuration data.
         Application note: The ―capability to verify‖ is to be interpreted broadly. At one extreme, the
         Partitioning Kernel might perform all the integrity checks and simply return a ―good‖ or ―bad‖
         response to the subject. At the other extreme, the Partition Kernel might allow the subject to view
         the code and the subject would perform all the integrity checks.
         Application note: The term ―stored TSF executable code‖ does not imply that the Partitioning Kernel must
         store code.
         Dependencies: 0 FPT_AMT.1 Abstract Machine Testing


     Class FRU: Resource Utilization
FRU_RSA.1 Maximum quotas
The TSF shall enforce maximum quotas of the following resources that subjects can use, as specified in the
Partitioning Kernel’s configuration data: memory, Partitioning Kernel resources, processing time. (FRU_RSA.1.1,
amplified by assignment and selection)
         Dependencies: None

FRU_RSA_EXP.1 Deterministic Resource Utilization
The TSF shall have predictable, worst-case bounded execution time and memory usage. (FRU_RSA_EXP.1.1)
         Application note: Suspending a service request to implement a scheduling policy is not to be
         construed, per se, as nondeterminism or unpredictability on the part of the Partitioning Kernel.




9 June 2003                                     Version 1.3                                                 22
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness


TOE Security Assurance Requirements

                                  Table 5-1 Assurance Requirements: EAL (7)
 Assurance Class                    Assurance Components
 ACM                      ACM_AUT.2 ACM_CAP.5 ACM_SCP.3
 ADO                      ADO_DEL.3 ADO_IGS.1
 ADV                      ADV_FSP.4 ADV_HLD.5 ADV_IMP.3 ADV_INT.3 ADV_LLD.2 ADV_RCR.3
                          ADV_SPM.3
 AGD                      AGD_ADM.1 AGD_USR.1
 ALC                      ALC_DVS.2 ALC_LCD.3 ALC_TAT.3
                          Augmented by ALC_FLR.3
 ATE                      ATE_COV.3 ATE_DPT.3 ATE_FUN.2 ATE_IND.3
 AVA                      AVA_CCA.2 AVA_MSU.3 AVA_SOF.1 AVA_VLA.4
 AMA                      AMA_AMP.1, AMA_CAT.1, AMA_EVD.1, AMA_SIA.2


        Dependencies: With the exception of the requirements noted below, all assurance requirements in
        this PP are exactly the EAL7 requirements from the CC. Since all dependencies are known to be
        satisfied for EAL7 they are also satisfied in this PP. For these, the dependencies identified in the
        CC are not repeated in this section.
        In this PP, EAL7 has been augmented with ALC_FLR.3, AMA_AMP.1, AMA_CAT.1,
        AMA_EVD.1, AMA_SIA.2. For these, the dependencies identified in the CC are resolved in the
        requirements below.
        Note: Developer in this section refers to the TOE developer.


     Configuration management (ACM)
Complete CM automation (ACM_AUT.2)
The developer shall use a CM system. ACM_AUT.2.1D
The developer shall provide a CM plan. ACM_AUT.2.2D
The CM system shall provide an automated means by which only authorized changes are made to the TOE
implementation representation, and to all other configuration items. ACM_AUT.2.1C
The CM system shall provide an automated means to support the generation of the TOE. ACM_AUT.2.2C
The CM plan shall describe the automated tools used in the CM system. ACM_AUT.2.3C
The CM plan shall describe how the automated tools are used in the CM system. ACM_AUT.2.4C
The CM system shall provide an automated means to ascertain the changes between the TOE and its preceding
version. ACM_AUT.2.5C
The CM system shall provide an automated means to identify all other configuration items that are affected by the
modification of a given configuration item. ACM_AUT.2.6C

Advanced support (ACM_CAP.5)
The developer shall provide a reference for the TOE. ACM_CAP.5.1D
The developer shall use a CM system. ACM_CAP.5.2D

9 June 2003                                    Version 1.3                                                23
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

The developer shall provide CM documentation. ACM_CAP.5.3D
The reference for the TOE shall be unique to each version of the TOE. ACM_CAP.5.1C
The TOE shall be labeled with its reference. ACM_CAP.5.2C
The CM documentation shall include a configuration list, a CM plan, an acceptance plan, and integration
procedures. ACM_CAP.5.3C
The configuration list shall describe the configuration items that comprise the TOE. ACM_CAP.5.4C
The CM documentation shall describe the method used to uniquely identify the configuration items.
ACM_CAP.5.5C
The CM system shall uniquely identify all configuration items. ACM_CAP.5.6C
The CM plan shall describe how the CM system is used. ACM_CAP.5.7C
The evidence shall demonstrate that the CM system is operating in accordance with the CM plan. ACM_CAP.5.8C
The CM documentation shall provide evidence that all configuration items have been and are being effectively
maintained under the CM system. ACM_CAP.5.9C
The CM system shall provide measures such that only authorized changes are made to the configuration items.
ACM_CAP.5.10C
The CM system shall support the generation of the TOE. ACM_CAP.5.11C
The acceptance plan shall describe the procedures used to accept modified or newly created configuration items as
part of the TOE.ACM_CAP.5.12C
The integration procedures shall describe how the CM system is applied in the TOE manufacturing process.
ACM_CAP.5.13C
The CM system shall require that the person responsible for accepting a configuration item into CM is not the
person who developed it. ACM_CAP.5.14C
The CM system shall clearly identify the configuration items that comprise the TSF. ACM_CAP.5.15C
The CM system shall support the audit of all modifications to the TOE, including as a minimum the originator, date,
and time in the audit trail. ACM_CAP.5.16C
The CM system shall be able to identify the master copy of all material used to generate the TOE.
ACM_CAP.5.17C
The CM documentation shall demonstrate that the use of the CM system, together with the development security
measures, allow only authorized changes to be made to the TOE. ACM_CAP.5.18C
The CM documentation shall demonstrate that the use of the integration procedures ensures that the generation of
the TOE is correctly performed in an authorized manner. ACM_CAP.5.19C
The CM documentation shall demonstrate that the CM system is sufficient to ensure that the person responsible for
accepting a configuration item into CM is not the person who developed it. ACM_CAP.5.20C
The CM documentation shall justify that the acceptance procedures provide for an adequate and appropriate review
of changes to all configuration items. ACM_CAP.5.21C

Development tools CM coverage (ACM_SCP.3)
The CM documentation shall show that the CM system, as a minimum, tracks the following: the TOE
implementation representation, design documentation, test documentation, user documentation, administrator
documentation, CM documentation, security flaws, and development tools and related information. ACM_SCP.3.1C
The developer shall provide CM documentation. ACM_SCP.3.1D
The CM documentation shall describe how configuration items are tracked by the CM system. ACM_SCP.3.2C




9 June 2003                                    Version 1.3                                                24
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

     Delivery and operation (ADO)
Prevention of modification (ADO_DEL.3)
The developer shall document procedures for delivery of the TOE or parts of it to the user. ADO_DEL.3.1D
The developer shall use the delivery procedures. ADO_DEL.3.2D
The delivery documentation shall describe all procedures that are necessary to maintain security when distributing
versions of the TOE to a user's site. ADO_DEL.3.1C
The delivery documentation shall describe how the various procedures and technical measures provide for the
prevention of modifications, or any discrepancy between the developer's master copy and the version received at the
user site. ADO_DEL.3.2C
The delivery documentation shall describe how the various procedures allow detection of attempts to masquerade as
the developer, even in cases in which the developer has sent nothing to the user's site. ADO_DEL.3.3C

Installation, generation, and start-up procedures (ADO_IGS.1)
The developer shall document procedures necessary for the secure installation, generation, and start-up of the TOE.
(ADO_IGS.1.1D)
The documentation shall describe the steps necessary for secure installation, generation, and start-up of the TOE.
ADO_IGS.1.1C
         Application Note: The requirements for installation, generation, and start-up procedures are
         divided between the TOE and the IT Environment (see rationale for O.TRUSTED_STARTUP and
         OE.TRUSTED_LOAD.
         Application Note: These requirements include the generation and installation of the configuration
         data describing the connections between partitions and shared memory.
         Dependencies: 0 Administrator guidance (AGD_ADM.1)



     Development (ADV)
Formal functional specification (ADV_FSP.4)
The functional specification shall describe the TSF and its external interfaces using a formal style, supported by
informal, explanatory text where appropriate. ADV_FSP.4.1C
The developer shall provide a functional specification. ADV_FSP.4.1D
The functional specification shall be internally consistent. ADV_FSP.4.2C
The functional specification shall describe the purpose and method of use of all external TSF interfaces, providing
complete details of all effects, exceptions and error messages. ADV_FSP.4.3C
The functional specification shall completely represent the TSF. ADV_FSP.4.4C
The functional specification shall include rationale that the TSF is completely represented. ADV_FSP.4.5C

Formal high-level design. (ADV_HLD.5)
The presentation of the high-level design shall be formal. ADV_HLD.5.1C
The developer shall provide the high-level design of the TSF. ADV_HLD.5.1D
The high-level design shall be internally consistent. ADV_HLD.5.2C
The high-level design shall describe the structure of the TSF in terms of subsystems. ADV_HLD.5.3C
The high-level design shall describe the security functionality provided by each subsystem of the
TSF.ADV_HLD.5.4C

9 June 2003                                      Version 1.3                                               25
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

The high-level design shall identify any underlying hardware, firmware, and/or software required by the TSF with a
presentation of the functions provided by the supporting protection mechanisms implemented in that hardware,
firmware, or software. ADV_HLD.5.5C
The high-level design shall identify all interfaces to the subsystems of the TSF. ADV_HLD.5.6C
The high-level design shall identify which of the interfaces to the subsystems of the TSF are externally visible.
ADV_HLD.5.7C
The high-level design shall describe the purpose and method of use of all interfaces to the subsystems of the TSF,
providing complete details of all effects, exceptions and error messages. ADV_HLD.5.8C
The high-level design shall describe the separation of the TOE into TSP-enforcing and other subsystems.
ADV_HLD.5.9C
The high-level design shall justify that the identified means of achieving separation, including any protection
mechanisms, are sufficient to ensure a clear and effective separation of TSP-enforcing from non-TSP-enforcing
functions. ADV_HLD.5.10C
The high-level design shall justify that the TSF mechanisms are sufficient to implement the security functions
identified in the high-level design. ADV_HLD.5.11C

Structured implementation of the TSF (ADV_IMP.3)
The implementation representation shall unambiguously define the TSF to a level of detail such that the TSF can be
generated without further design decisions. ADV_IMP.3.1C
The developer shall provide the implementation representation for the entire TSF. ADV_IMP.3.1D
The implementation representation shall be internally consistent. ADV_IMP.3.2C
The implementation representation shall describe the relationships between all portions of the implementation.
ADV_IMP.3.3C
The implementation representation shall be structured into small and comprehensible sections. ADV_IMP.3.4C

Minimization of complexity (ADV_INT.3)
The architectural description shall identify the modules of the TSF and shall specify which portions of the TSF
enforce the access control and/or information flow control policies. ADV_INT.3.1C
The developer shall design and structure the TSF in a modular fashion that avoids unnecessary interactions between
the modules of the design. ADV_INT.3.1D
The architectural description shall describe the purpose, interface, parameters, and side-effects of each module of the
TSF. ADV_INT.3.2C
The developer shall provide an architectural description. ADV_INT.3.2D
The architectural description shall describe how the TSF design provides for largely independent modules that avoid
unnecessary interactions. ADV_INT.3.3C
The developer shall design and structure the TSF in a layered fashion that minimizes mutual interactions between
the layers of the design. ADV_INT.3.3D
The architectural description shall describe the layering architecture. ADV_INT.3.4C
The developer shall design and structure the TSF in such a way that minimizes the complexity of the entire TSF.
ADV_INT.3.4D
The architectural description shall show that mutual interactions have been minimized, and justify those that remain.
ADV_INT.3.5C
The developer shall design and structure the portions of the TSF that enforce any access control and/or information
flow control policies such that they are simple enough to be analyzed. ADV_INT.3.5D
The architectural description shall describe how the entire TSF has been structured to minimize complexity.
ADV_INT.3.6C

9 June 2003                                      Version 1.3                                               26
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

The developer shall ensure that functions whose objectives are not relevant for the TSF are excluded from the TSF
modules. ADV_INT.3.6D
The architectural description shall justify the inclusion of any non-TSP-enforcing modules in the TSF.
ADV_INT.3.7C

Semiformal low-level design (ADV_LLD.2)
The low-level design shall describe the separation of the TOE into TSP-enforcing and other modules.
ADV_LLD.2.10C
The presentation of the low-level design shall be semiformal. ADV_LLD.2.1C
The developer shall provide the low-level design of the TSF. ADV_LLD.2.1D
The low-level design shall be internally consistent. ADV_LLD.2.2C
The low-level design shall describe the TSF in terms of modules. ADV_LLD.2.3C
The low-level design shall describe the purpose of each module. ADV_LLD.2.4C
The low-level design shall define the interrelationships between the modules in terms of provided security
functionality and dependencies on other modules. ADV_LLD.2.5C
The low-level design shall describe how each TSP-enforcing function is provided. ADV_LLD.2.6C
The low-level design shall identify all interfaces to the modules of the TSF. ADV_LLD.2.7C
The low-level design shall identify which of the interfaces to the modules of the TSF are externally visible.
ADV_LLD.2.8C
The low-level design shall describe the purpose and method of use of all interfaces to the modules of the TSF,
providing complete details of all effects, exceptions and error messages. ADV_LLD.2.9C

Formal correspondence demonstration (ADV_RCR.3)
For each adjacent pair of provided TSF representations, the analysis shall prove or demonstrate that all relevant
security functionality of the more abstract TSF representation is correctly and completely refined in the less abstract
TSF representation. ADV_RCR.3.1C
The developer shall provide an analysis of correspondence between all adjacent pairs of TSF representations that are
provided. ADV_RCR.3.1D
For each adjacent pair of provided TSF representations, where portions of one representation are semiformally
specified and the other at least semiformally specified, the demonstration of correspondence between those portions
of the representations shall be semiformal. ADV_RCR.3.2C
For those corresponding portions of representations that are formally specified, the developer shall prove that
correspondence. ADV_RCR.3.2D
For each adjacent pair of provided TSF representations, where portions of both representations are formally
specified, the proof of correspondence between those portions of the representations shall be formal.
ADV_RCR.3.3C

Formal TOE security policy model (ADV_SPM.3)
The TSP model shall be formal. ADV_SPM.3.1C
The developer shall provide a TSP model. ADV_SPM.3.1D
The TSP model shall describe the rules and characteristics of all policies of the TSP that can be modeled.
ADV_SPM.3.2C
The developer shall demonstrate or prove, as appropriate, correspondence between the functional specification and
the TSP model. ADV_SPM.3.2D
The TSP model shall include a rationale that demonstrates that it is consistent and complete with respect to all
policies of the TSP that can be modeled. ADV_SPM.3.3C

9 June 2003                                      Version 1.3                                                 27
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

The demonstration of correspondence between the TSP model and the functional specification shall show that all of
the security functions in the functional specification are consistent and complete with respect to the TSP model.
ADV_SPM.3.4C
Where the functional specification is semiformal, the demonstration of correspondence between the TSP model and
the functional specification shall be semiformal. ADV_SPM.3.5C
Where the functional specification is formal, the proof of correspondence between the TSP model and the functional
specification shall be formal. ADV_SPM.3.6C


     Guidance documents (AGD)
Administrator guidance (AGD_ADM.1)
The administrator guidance shall describe the administrative functions and interfaces available to the administrator
of the TOE. AGD_ADM.1.1C
         Application note: From the point of view of the Partitioning Kernel, the primary Administrator
         function is creating and modifying the Partitioning Kernel’s configuration data. The system in
         which the Partitioning Kernel is embedded may require additional functions of the Administrator.
The developer shall provide administrator guidance addressed to system administrative personnel. AGD_ADM.1.1D
The administrator guidance shall describe how to administer the TOE in a secure manner. AGD_ADM.1.2C
The administrator guidance shall contain warnings about functions and privileges that should be controlled in a
secure processing environment. AGD_ADM.1.3C
The administrator guidance shall describe all assumptions regarding user behavior that are relevant to secure
operation of the TOE. AGD_ADM.1.4C
The administrator guidance shall describe all security parameters under the control of the administrator, indicating
secure values as appropriate. AGD_ADM.1.5C
The administrator guidance shall describe each type of security-relevant event relative to the administrative
functions that need to be performed, including changing the security characteristics of entities under the control of
the TSF. AGD_ADM.1.6C
The administrator guidance shall be consistent with all other documentation supplied for evaluation.
AGD_ADM.1.7C
The administrator guidance shall describe all security requirements for the IT environment that are relevant to the
administrator. AGD_ADM.1.8C

User guidance (AGD_USR.1)
The user guidance shall describe the functions and interfaces available to the non-administrative users of the TOE.
AGD_USR.1.1C
The developer shall provide user guidance. AGD_USR.1.1D
The user guidance shall describe the use of user-accessible security functions provided by the TOE.
AGD_USR.1.2C
         Application note: Examples of user-accessible security functions: (a) reading Partitioning Kernel
         data; (b) accessing I/O devices; (c) updating the system clock. These are ―user-accessible‖ in the
         sense that a programmer may write code that invokes the functions.
The user guidance shall contain warnings about user-accessible functions and privileges that should be controlled in
a secure processing environment. AGD_USR.1.3C
The user guidance shall clearly present all user responsibilities necessary for secure operation of the TOE, including
those related to assumptions regarding user behavior found in the statement of TOE security environment.
AGD_USR.1.4C
The user guidance shall be consistent with all other documentation supplied for evaluation. AGD_USR.1.5C

9 June 2003                                      Version 1.3                                                28
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

The user guidance shall describe all security requirements for the IT environment that are relevant to the user.
AGD_USR.1.6C


     Life cycle support (ALC)
Sufficiency of security measures (ALC_DVS.2)
The development security documentation shall describe all the physical, procedural, personnel, and other security
measures that are necessary to protect the confidentiality and integrity of the TOE design and implementation in its
development environment. ALC_DVS.2.1C
The developer shall produce development security documentation. ALC_DVS.2.1D
The development security documentation shall provide evidence that these security measures are followed during
the development and maintenance of the TOE. ALC_DVS.2.2C
The evidence shall justify that the security measures provide the necessary level of protection to maintain the
confidentiality and integrity of the TOE. ALC_DVS.2.3C

Systematic Flaw Remediation (ALC_FLR.3)
The developer shall document the flaw remediation procedures. ALC_FLR.3.1D
The developer shall establish a procedure for accepting , and acting upon user reports of security flaws and requests
for corrections to those flaws. ALC_FLR.3.2D
The developer shall designate one or more specific points of contact for user reports and inquiries about security
issues involving the TOE. ALC_FLR.3.3D
The flaw remediation procedures documentation shall describe the procedures used to track all reported security
flaws in each release of the TOE. ALC_FLR.3.1C
The flaw remediation procedures shall require that a description of the nature and effect of each security flaw be
provided, as well as the status of finding a correction to that flaw. ALC_FLR.3.2C
The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws.
ALC_FLR.3.3C
The flaw remediation procedures documentation shall describe the methods used to provide flaw information,
corrections and guidance on corrective actions to TOE users. ALC_FLR.3.4C
The procedures for processing reported security flaws shall ensure that any reported flaws are corrected and the
correction issued to TOE users. ALC_FLR.3.5C
The procedures for processing reported security flaws shall provide safeguards that any corrections to these security
flaws do not introduce any new flaws. ALC_FLR.3.6C
The flaw remediation procedures shall include a procedure requiring timely responses for the automatic distribution
of security flaw reports and the associated corrections to registered users who might be affected by the security flaw.
ALC_FLR.3.7C
         Application note: In ALC_FLR.3.2D the procedure for ―accepting‖ user reports may include verifying that
         the reports represent actual flaws.
         Dependencies: None.

Measurable life-cycle model (ALC_LCD.3)
The life-cycle definition documentation shall describe the model used to develop and maintain the TOE, including
the details of its arithmetic parameters and/or metrics used to measure the TOE development against the model.
ALC_LCD.3.1C
The developer shall establish a life-cycle model to be used in the development and maintenance of the TOE.
ALC_LCD.3.1D


9 June 2003                                      Version 1.3                                                29
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

The life-cycle model shall provide for the necessary control over the development and maintenance of the TOE.
ALC_LCD.3.2C
The developer shall provide life-cycle definition documentation. ALC_LCD.3.2D
The life-cycle definition documentation shall explain why the model was chosen. ALC_LCD.3.3C
The developer shall use a standardized and measurable life-cycle model to develop and maintain the TOE.
ALC_LCD.3.3D
The life-cycle definition documentation shall explain how the model is used to develop and maintain the TOE.
ALC_LCD.3.4C
The developer shall measure the TOE development using the standardized and measurable life-cycle model.
ALC_LCD.3.4D
The life-cycle definition documentation shall demonstrate compliance with the standardized and measurable life-
cycle model. ALC_LCD.3.5C
The life-cycle documentation shall provide the results of the measurements of the TOE development using the
standardized and measurable life-cycle model. ALC_LCD.3.6C

Compliance with implementation standards - all parts (ALC_TAT.3)
All development tools used for implementation shall be well-defined. ALC_TAT.3.1C
The developer shall identify the development tools being used for the TOE. ALC_TAT.3.1D
The documentation of the development tools shall unambiguously define the meaning of all statements used in the
implementation. ALC_TAT.3.2C
The developer shall document the selected implementation-dependent options of the development tools.
ALC_TAT.3.2D
The documentation of the development tools shall unambiguously define the meaning of all implementation-
dependent options. ALC_TAT.3.3C
The developer shall describe the implementation standards for all parts of the TOE. ALC_TAT.3.3D


     Tests (ATE)
Rigorous analysis of coverage (ATE_COV.3)
The analysis of the test coverage shall demonstrate the correspondence between the tests identified in the test
documentation and the TSF as described in the functional specification. ATE_COV.3.1C
The developer shall provide an analysis of the test coverage. ATE_COV.3.1D
The analysis of the test coverage shall demonstrate that the correspondence between the TSF as described in the
functional specification and the tests identified in the test documentation is complete. ATE_COV.3.2C
The analysis of the test coverage shall rigorously demonstrate that all external interfaces of the TSF identified in the
functional specification have been completely tested. ATE_COV.3.3C

Testing: implementation representation (ATE_DPT.3)
The depth analysis shall demonstrate that the tests identified in the test documentation are sufficient to demonstrate
that the TSF operates in accordance with its high-level design, low-level design and implementation representation.
ATE_DPT.3.1C
The developer shall provide the analysis of the depth of testing. ATE_DPT.3.1D

Ordered functional testing (ATE_FUN.2)
The test documentation shall consist of test plans, test procedure descriptions, expected test results and actual test
results. ATE_FUN.2.1C

9 June 2003                                       Version 1.3                                                30
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

The developer shall test the TSF and document the results. ATE_FUN.2.1D
The test plans shall identify the security functions to be tested and describe the goal of the tests to be performed.
ATE_FUN.2.2C
The developer shall provide test documentation. ATE_FUN.2.2D
The test procedure descriptions shall identify the tests to be performed and describe the scenarios for testing each
security function. These scenarios shall include any ordering dependencies on the results of other tests.
ATE_FUN.2.3C
The expected test results shall show the anticipated outputs from a successful execution of the tests. ATE_FUN.2.4C
The test results from the developer execution of the tests shall demonstrate that each tested security function
behaved as specified. ATE_FUN.2.5C
The test documentation shall include an analysis of the test procedure ordering dependencies. ATE_FUN.2.6C

Independent testing - complete (ATE_IND.3)
The TOE shall be suitable for testing. ATE_IND.3.1C
The developer shall provide the TOE for testing. ATE_IND.3.1D
The developer shall provide an equivalent set of resources to those that were used in the developer's functional
testing of the TSF. ATE_IND.3.2C


     Vulnerability assessment (AVA)
Systematic covert channel analysis (AVA_CCA.2)
The analysis documentation shall identify covert channels and estimate their capacity. AVA_CCA.2.1C
The developer shall conduct a search for covert channels for each information flow control policy. AVA_CCA.2.1D
The analysis documentation shall describe the procedures used for determining the existence of covert channels, and
the information needed to carry out the covert channel analysis. AVA_CCA.2.2C
The developer shall provide covert channel analysis documentation. AVA_CCA.2.2D
The analysis documentation shall describe all assumptions made during the covert channel analysis.
AVA_CCA.2.3C
The analysis documentation shall describe the method used for estimating channel capacity, based on worst case
scenarios. AVA_CCA.2.4C
The analysis documentation shall describe the worst case exploitation scenario for each identified covert channel.
AVA_CCA.2.5C
The analysis documentation shall provide evidence that the method used to identify covert channels is systematic.
AVA_CCA.2.6C

Analysis and testing for insecure states (AVA_MSU.3)
The guidance documentation shall identify all possible modes of operation of the TOE (including operation
following failure or operational error), their consequences and implications for maintaining secure operation.
AVA_MSU.3.1C
The developer shall provide guidance documentation. AVA_MSU.3.1D
The guidance documentation shall be complete, clear, consistent and reasonable. AVA_MSU.3.2C
The developer shall document an analysis of the guidance documentation. AVA_MSU.3.2D
The guidance documentation shall list all assumptions about the intended environment. AVA_MSU.3.3C
The guidance documentation shall list all requirements for external security measures (including external
procedural, physical and personnel controls). AVA_MSU.3.4C

9 June 2003                                       Version 1.3                                                 31
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

The analysis documentation shall demonstrate that the guidance documentation is complete. AVA_MSU.3.5C

Strength of TOE security function evaluation (AVA_SOF.1)
For each mechanism with a strength of TOE security function claim the strength of TOE security function analysis
shall show that it meets or exceeds the minimum strength level defined in the PP/ST. AVA_SOF.1.1C
         Application note: No security functions have been identified for the Partitioning Kernel that are
         realized by a probabilistic or permutational mechanism. Therefore there are no strength of
         function claims.
The developer shall perform a strength of TOE security function analysis for each mechanism identified in the ST as
having a strength of TOE security function claim. AVA_SOF.1.1D
For each mechanism with a specific strength of TOE security function claim the strength of TOE security function
analysis shall show that it meets or exceeds the specific strength of function metric defined in the PP/ST.
AVA_SOF.1.2C

Highly resistant (AVA_VLA.4)
The documentation shall show, for all identified vulnerabilities, that the vulnerability cannot be exploited in the
intended environment for the TOE. AVA_VLA.4.1C
The developer shall perform and document an analysis of the TOE deliverables searching for ways in which a user
can violate the TSP. AVA_VLA.4.1D
The documentation shall justify that the TOE, with the identified vulnerabilities, is resistant to obvious penetration
attacks. AVA_VLA.4.2C
The developer shall document the disposition of identified vulnerabilities. AVA_VLA.4.2D
The evidence shall show that the search for vulnerabilities is systematic. AVA_VLA.4.3C
The analysis documentation shall provide a justification that the analysis completely addresses the TOE
deliverables. AVA_VLA.4.4C


     Assurance maintenance plan (AMA)
Assurance maintenance plan (AMA_AMP.1)
The AM Plan shall contain or reference a brief description of the TOE, including the security functionality it
provides. AMA_AMP.1.1C
The developer shall provide an AM Plan. AMA_AMP.1.1D
The AM Plan shall identify the certified version of the TOE, and shall reference the evaluation results.
AMA_AMP.1.2C
The AM Plan shall reference the TOE component categorisation report for the certified version of the TOE.
AMA_AMP.1.3C
The AM Plan shall define the scope of changes to the TOE that are covered by the plan. AMA_AMP.1.4C
The AM Plan shall describe the TOE life-cycle, and shall identify the current plans for any new releases of the TOE,
together with a brief description of any planned changes that are likely to have a significant security impact.
AMA_AMP.1.5C
The AM Plan shall describe the assurance maintenance cycle, stating and justifying the planned schedule of AM
audits and the target date of the next reevaluation of the TOE. AMA_AMP.1.6C
The AM Plan shall identify the individual(s) who will assume the role of developer security analyst for the TOE.
AMA_AMP.1.7C
The AM Plan shall describe how the developer security analyst role will ensure that the procedures documented or
referenced in the AM Plan are followed. AMA_AMP.1.8C


9 June 2003                                      Version 1.3                                                 32
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

The AM Plan shall describe how the developer security analyst role will ensure that all developer actions involved
in the analysis of the security impact of changes affecting the TOE are performed correctly. AMA_AMP.1.9C
The AM Plan shall justify why the identified developer security analyst(s) have sufficient familiarity with the
security target, functional specification and (where appropriate) high-level design of the TOE, and with the
evaluation results and all applicable assurance requirements for the certified version of the TOE. AMA_AMP.1.10C
The AM Plan shall describe or reference the procedures to be applied to maintain the assurance in the TOE, which
as a minimum shall include the procedures for configuration management, maintenance of assurance evidence,
performance of the analysis of the security impact of changes affecting the TOE, and flaw remediation.
AMA_AMP.1.11C
         Dependencies: 0 ACM_CAP.5 Advanced support (ACM_CAP.5 is a superset of ACM_CAP.2 dependency
         identified in the Common Criteria), 0 ALC_FLR.3 Systematic flaw remediation (ALC_FLR.3 is a superset
         of ALC_FLR.1 dependency identified in the Common Criteria), 0 AMA_CAT.1 TOE Component
         categorization report

TOE component categorization report (AMA_CAT.1)
The TOE component categorization report shall categorize each component of the TOE, identifiable in each TSF
representation from the most abstract to the least abstract, according to its relevance to security; as a minimum, TOE
components must be categorized as one of TSP-enforcing or non-TSP enforcing. AMA_CAT.1.1C
The developer shall provide a TOE component categorization report for the certified version of the TOE.
AMA_CAT.1.1D
The TOE component categorization report shall describe the categorization scheme used, so that it can be
determined how to categorize new components introduced into the TOE, and also when to re-categorize existing
TOE components following changes to the TOE or its security target. AMA_CAT.1.2C
The TOE component categorization report shall identify any tools used in the development environment that, if
modified, will have an impact on the assurance that the TOE satisfies its security target. AMA_CAT.1.3C
         Dependencies: 0 ACM_CAP.5 Advanced support (ACM_CAP.5 is a superset of ACM_CAP.2 dependency
         identified in the Common Criteria)

Evidence of assurance maintenance (AMA_EVD.1)
The AM documentation shall include a configuration list and a list of identified vulnerabilities in the TOE.
AMA_EVD.1.1C
The developer security analyst shall provide AM documentation for the current version of the TOE.
AMA_EVD.1.1D
The configuration list shall describe the configuration items that comprise the current version of the TOE.
AMA_EVD.1.2C
The AM documentation shall provide evidence that the procedures documented or referenced in the AM Plan are
being followed. AMA_EVD.1.3C
The list of identified vulnerabilities in the current version of the TOE shall show, for each vulnerability, that the
vulnerability cannot be exploited in the intended environment for the TOE. AMA_EVD.1.4C
         Dependencies: 0 AMA_AMP.1 Assurance maintenance plan, 0 AMA_SIA.2 (AMA_SIA.2 is a superset of
         the AMA_SIA.1 dependency identified in the Common Criteria)

Security impact analysis (AMA_SIA.2)
The security impact analysis shall identify the certified TOE from which the current version of the TOE was
derived. AMA_SIA.2.1C
The developer security analyst shall, for the current version of the TOE, provide a security impact analysis that
covers all changes affecting the TOE as compared with the certified version. AMA_SIA.2.1D
The security impact analysis shall identify all new and modified TOE components that are categorized as TSP-
enforcing. AMA_SIA.2.2C
9 June 2003                                       Version 1.3                                                 33
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

The security impact analysis shall, for each change affecting the security target or TSF representations, briefly
describe the change and any effects it has on lower representation levels. AMA_SIA.2.3C
The security impact analysis shall, for each change affecting the security target or TSF representations, identify all
IT security functions and all TOE components categorized as TSP-enforcing that are affected by the change.
AMA_SIA.2.4C
The security impact analysis shall, for each change which results in a modification of the implementation
representation of the TSF or the IT environment, identify the test evidence that shows, to the required level of
assurance, that the TSF continues to be correctly implemented following the change. AMA_SIA.2.5C
The security impact analysis shall, for each applicable assurance requirement in the configuration management
(ACM), life cycle support (ALC), delivery and operation (ADO) and guidance documents (AGD) assurance classes,
identify any evaluation deliverables that have changed, and provide a brief description of each change and its impact
on assurance. AMA_SIA.2.6C
The security impact analysis shall, for each applicable assurance requirement in the vulnerability assessment (AVA)
assurance class, identify which evaluation deliverables have changed and which have not, and give reasons for the
decision taken as to whether or not to update the deliverable. AMA_SIA.2.7C
         Dependencies: 0 AMA_CAT.1 TOE Component categorization report


Security Requirements for the IT environment
This section includes both functional and assurance requirements that must be satisfied by the environment in which
the Partitioning Kernel operates. Also, where security requirements for the IT environment refer to the TSF, they
refer to the security functions of the environment, rather than security functions of the TOE (see paragraph 219 of
the CEM, section 3.4.5.2.1).


     Class FMT: Security Management
FMT_MSA.1 Management of Security Attributes
The TSF shall enforce the information flow control SFP to restrict the ability to modify the security attributes,
connections, and privileges to system configurer. (FMT_MSA.1.1, amplified by assignment and selection)
         Dependencies:
         FDP_IFC.1 Subset information flow control
         Normally, FMT_SMR.1 Security roles, would be a dependency. But for this TOE there are no
         ―users,‖ and the security attributes in the configuration data are installed through an environmental
         trusted load capability (see FPT_IGS_EXP.1.1). Consequently, the dependency on FMT_SMR.1
         is null.


FMT_MSA.3 Static Attribute Initialization
The TSF shall enforce the information flow control SFP to provide restrictive default values for security attributes
that are used to enforce the SFP. (FMT_MSA.3.1, amplified by assignment and selection)
The TSF shall allow the system configurer to specify alternative initial values to override the default values when an
object or information is created. (FMT_MSA.3.2)
         Dependencies:
         FMT_MSA.1 Management of security attributes
         Normally, FMT_SMR.1 Security roles, would be a dependency. But for this TOE there are no
         ―users,‖ and the security attributes in the configuration data are installed through an environmental
         trusted load capability (see FPT_IGS_EXP.1.1). Consequently, the dependency on FMT_SMR.1
         is null.




9 June 2003                                      Version 1.3                                                34
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

     Class FPT: Protection of the TSF
FPT_IGS_EXP.1 Installation, Generation, and Startup
A trusted load capability shall be provided to ensure that the code and configuration data for the Partitioning Kernel
are reliably loaded into the processor and are protected from unauthorized modification. (FPT_IGS_EXP.1.1)
         Dependencies: None
Requirement for trusted startup (i.e. FPT_IGS_EXP.1.2) has been allocated to the TOE.


     Vulnerability Assessment (AVA)
Risk Mitigation (AVA_RMI_EXP.1)
If a non-static time partitioning mechanism is employed, an explanation shall be provided for how the risks of covert
timing channels and denial of service threats have been addressed. (AVA_RMI_EXP.1.1)
If the Partitioning Kernel does not flush cache memories during the transition of the processor from one partition to
another, an explanation shall be provided for how that the risks of covert timing channels based on cache
manipulation have been addressed. (AVA_RMI_EXP.1.2)
         Dependencies: None


     Delivery and Operation (ADO)
Installation, Generation, and Start-up (ADO_IGS.1)
The environment developer shall document procedures necessary for the secure installation, generation, and start-up
of the TOE. (ADO_IGS_EXP.1)
The documentation shall describe the steps necessary for secure installation, generation, and start-up of the TOE.
ADO_IGS.1.1C
         Application Note: The requirements for installation, generation, and start-up procedures are
         divided between the TOE and the IT Environment (see rationale for O.TRUSTED_STARTUP and
         OE.TRUSTED_LOAD).
         Application Note: These requirements include the generation and installation of the configuration
         data describing the connections between partitions and shared memory.
         Dependencies: 0 Administrator guidance (AGD_ADM.1)




9 June 2003                                      Version 1.3                                               35
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness


Rationale

This section provides the rationale used for selection, creation, and use of security objectives and requirements.


Security Objectives Rationale

                  Table 6-1 Mapping of the TOE Security Environment to Security Objectives
                   Policy/Threat/Assumptions                              Objectives
                A.TRUSTED_LOAD                            OE.TRUSTED_LOAD
                A.SCHEDULER_RMI                           OE.SCHEDULER_RMI
                A.CACHE_MEM_RMI                           OE.CACHE_MEM_RMI
                P.INFO_FLOW                               O.INFORMATION_FLOW
                P.ISOLATION                               O.PARTITION_PROTECT
                P.SHARED_MEMORY                           O.PARTITION_PROTECT
                P.UNIQUE_PARTITION                        O.PARTITION_CREATE
                T.CONFIG_CORRUPT                          O.SELF_PROTECT
                T.CONFIG_CORRUPT                          OE.TRUSTED_LOAD
                T.DOS                                     O.RESOURCE_GUARANTEE
                T.DOS                                     O.SELF_PROTECT
                T.EAVESDROP                               O.INFORMATION_FLOW
                T.EAVESDROP                               O.PARTITION_PROTECT
                T.EAVESDROP                               O.CLEAR_RESIDUAL
                T.HARDWARE_FAIL                           O.SELF_TEST
                T.NON-SECURE_STARTUP                      O.TRUSTED_STARTUP
                T.KERNEL_INDISCRETE                       O.INFORMATION_FLOW
                T.KERNEL_TAMPER                           O.FAIL_SAFE
                T.KERNEL_TAMPER                           O.RESOURCE_GUARANTEE
                T.KERNEL_TAMPER                           O.SELF_PROTECT
                T.MASQUERADE                              O.SELF_PROTECT
                T.NONDETERMINISTIC                        O.RESOURCE_GUARANTEE
                T.NONDETERMINISTIC                        O.SOUND_DESIGN
                T.NONDETERMINISTIC                        O.SOUND_IMPLEMENTATION
                T.POOR_DESIGN                             O.SOUND_DESIGN
                T.POOR_IMPLEMENTATION                     O.SOUND_IMPLEMENTATION
                T.POOR_TEST                               O.TESTING
                T.POOR_TRANSFER                           O.INFORMATION_FLOW
                T.POOR_TRANSFER                           O.SOUND_DESIGN
                T.POOR_TRANSFER                           O.SOUND_IMPLEMENTATION
                T.SYSACC                                  O.SELF_PROTECT
                T.UNAUTH_ACCESS                           O.PARTITION_PROTECT
                T.UNSANITIZED                             O.CLEAR_RESIDUAL
                T.WRONG_CODE                              O.CONFIG_MGMT
                T.WRONG_CODE                              O.TRUSTED_DELIVERY
                T.WRONG_CODE                              OE.TRUSTED_LOAD
                T.WRONG_COMM                              O.INFORMATION_FLOW
                T.WRONG_COMM                              OE.SCHEDULER_RMI
                T.WRONG_COMM                              OE.CACHE_MEM_RMI
                T.WRONG_CONFIG                            O.CONFIG_SUPPORT

9 June 2003                                      Version 1.3                                                36
       Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness




                Table 6-2 Tracing of Security Objectives to the TOE Security Environment


                       Objectives                         Policy/Threat/Assumptions
              O.CLEAR_RESIDUAL                       T.EAVESDROP
              O.CLEAR_RESIDUAL                       T.UNSANITIZED
              O.CONFIG_MGMT                          T.WRONG_CODE
              O.CONFIG_SUPPORT                       T.WRONG_CONFIG
              O.FAIL_SAFE                            T.KERNEL_TAMPER
              O.INFORMATION_FLOW                     P.INFO_FLOW
              O.INFORMATION_FLOW                     T.EAVESDROP
              O.INFORMATION_FLOW                     T.KERNEL_INDISCRETE
              O.INFORMATION_FLOW                     T.POOR_TRANSFER
              O.INFORMATION_FLOW                     T.WRONG_COMM
              O.PARTITION_CREATE                     P.UNIQUE_PARTITION
              O.PARTITION_PROTECT                    P.ISOLATION
              O.PARTITION_PROTECT                    P.SHARED_MEMORY
              O.PARTITION_PROTECT                    T.EAVESDROP
              O.PARTITION_PROTECT                    T.UNAUTH_ACCESS
              O.RESOURCE_GUARANTEE                   T.DOS
              O.RESOURCE_GUARANTEE                   T.KERNEL_TAMPER
              O.RESOURCE_GUARANTEE                   T.NONDETERMINISTIC
              O.SELF_PROTECT                         T.CONFIG_CORRUPT
              O.SELF_PROTECT                         T.DOS
              O.SELF_PROTECT                         T.KERNEL_TAMPER
              O.SELF_PROTECT                         T.MASQUERADE
              O.SELF_PROTECT                         T.SYSACC
              O.SELF_TEST                            T.HARDWARE_FAIL
              O.SOUND_DESIGN                         T.NONDETERMINISTIC
              O.SOUND_DESIGN                         T.POOR_DESIGN
              O.SOUND_IMPLEMENTATION                 T.NONDETERMINISTIC
              O.SOUND_IMPLEMENTATION                 T.POOR_IMPLEMENTATION
              O.TESTING                              T.POOR_TEST
              O.TRUSTED_STARTUP                      T.NON-SECURE_STARTUP
              OE.CACHE_MEM_RMI                       A.CACHE_MEM_RMI
              OE.CACHE_MEM_RMI                       T.WRONG_COMM
              OE.SCHEDULER_RMI                       A.SCHEDULER_RMI
              OE.SCHEDULER_RMI                       T.WRONG_COMM
              O.TRUSTED_DELIVERY                     T.WRONG_CODE
              OE.TRUSTED_LOAD                        A.TRUSTED_LOAD
              OE.TRUSTED_LOAD                        T.CONFIG_CORRUPT
              OE.TRUSTED_LOAD                        T.WRONG_CODE




9 June 2003                                 Version 1.3                                            37
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

     Explanation of Threats to Objectives Mapping
T.CONFIG_CORRUPT         A malicious or faulty subject may modify or corrupt the Partitioning Kernel's
                         configuration data defining resource allocations and inter-partition communications by
                         accessing memory outside its partition.
                         Protection of the Partitioning Kernel’s configuration data, which define the security
                         policy that is being enforced, must be provided both during load (OE.TRUSTED_LOAD)
                         and during normal operation (O.SELF_PROTECT).
T.DOS                    A malicious or faulty subject may block other subjects from using the processor by
                         exhausting shared resources.
                         Denial of service is prevented by guaranteeing each subject/partition the resources that it
                         needs (O.RESOURCE_GUARANTEE) and by preventing Partitioning Kernel tampering
                         through self protection measures (O.SELF_PROTECT). If a non-static time allocation
                         scheme is used, a potential DOS threat have to be addressed at the system level (see
                         A.SCHEDULER_RMI and the resulting OE.SCHEDULER_RMI).
T.EAVESDROP              A malicious or faulty subject may intercept an inter-partition communication for which it
                         is not authorized by retrieving data from an unsanitized resource or by accessing
                         information outside its own partition.
                         Eavesdropping is prevented by protecting partitions from unauthorized access
                         (O.PARTITION_PROTECT), by controlling the flow of information so that only
                         authorized subjects receive it (O.INFORMATION_FLOW), and by sanitizing resources
                         before they are allocated to a subject (O.CLEAR_RESIDUAL).
T.HARDWARE_FAIL          The hardware on which the Partitioning Kernel is installed may fail to provide the
                         functions upon which the Partitioning Kernel depends for correct operation due to
                         implementation errors, faulty design, or malicious intent.
                         Self-test is provided (O.SELF_TEST) to verify correct hardware operation.
T.NON-SECURE_STARTUP       Control may fail to be reliably passed to the Partitioning Kernel after power-on
                  or processor reset.
                         A trusted startup capability is provided to ensure that the Partitioning Kernel reaches a
                         secure initial state after power-on or processor reset (O.TRUSTED_STARTUP)
T.KERNEL_INDISCRETE
                         A subject may gain unauthorized information regarding another subject from the
                         Partitioning Kernel.
                         Release of any information regarding one subject to another, by the Partitioning Kernel,
                         must be explicitly authorized by the Partitioning Kernel's configuration data.
                         (O.INFORMATION_FLOW)
T.KERNEL_TAMPER          A subject may tamper with the Partitioning Kernel code or data to modify or disable the
                         partitioning mechanism by accessing memory outside its partition or executing
                         instructions for which it does not have privilege.
                         The Partitioning Kernel relies on features of the hardware to ensure that attempts by
                         subjects to bypass partition boundaries will result in a transfer of control directly to the
                         Partitioning Kernel (see section 2 TOE Description). The Partitioning Kernel is required
                         to handle these transfers of control in a way that prevents damage or violation of the
                         security policies (O.FAIL_SAFE), and to set up the hardware so as to detect tampering
                         (O.SELF_PROTECT). To protect against attacks through the Partitioning Kernel-to-
                         application interfaces, the Partitioning Kernel is required to validate application requests
                         (O.SELF_PROTECT), and to guarantee that requests for resources beyond those
                         allocated in the Partitioning Kernel’s configuration data will be blocked
                         (O.RESOURCE_GUARANTEE).



9 June 2003                                   Version 1.3                                                 38
       Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

T.MASQUERADE            A malicious or faulty subject may masquerade as a different subject by tampering with
                        Partitioning Kernel data structures or providing invalid parameters in Partitioning Kernel
                        service requests.
                        Partitioning Kernel data structures are protected from tampering by using the hardware to
                        enforce domain boundaries and by validating all service requests (O.SELF_PROTECT).
T.NONDETERMINISTIC
                        The Partitioning Kernel may fail to provide provably worst-case bounded execution time
                        or memory usage.
                        Verification activities are required for the Partitioning Kernel's design and
                        implementation to assure deterministic execution time of Partitioning Kernel service
                        requests, interrupt dispatching, scheduling overhead and memory allocation/deallocation
                        (O.RESOURCE_GUARANTEE, O.SOUND_DESIGN,
                        O.SOUND_IMPLEMENTATION).
                        Suspending a service request to implement a scheduling policy is not to be construed, per
                        se, as nondeterminism on the part of the Partitioning Kernel.
T.POOR_DESIGN           Unintentional or intentional errors in requirement specification, design or development of
                        the Partitioning Kernel may occur.
                        Verification activities are required for the Partitioning Kernel’s design to check for
                        requirements coverage and traceability (O.SOUND_DESIGN).
T.POOR_IMPLEMENTATION Unintentional or intentional errors in implementing the design of the Partitioning
                 Kernel may occur.
                        Verification activities are required for the implementation of the Partitioning Kernel to
                        verify that the design has been faithfully rendered, and that the design reflects all of the
                        code in the implementation (O.SOUND_IMPLEMENTATION).
T.POOR_TEST             Incorrect behavior resulting from faulty design or implementation may not be detected by
                        the testing program.
                        Test verification activities are required for the Partitioning Kernel, including independent
                        testing, and testing based on a vulnerability analysis (O.TESTING).
T.POOR_TRANSFER         The Partitioning Kernel may delay or prevent the defined information flows from
                        occurring. The Partitioning Kernel may also corrupt, truncate, or append to the data
                        within the information flow. Error free transfer is an aspect of information flow
                        (O.INFORMATION_FLOW).
                        Verification activities are required for the Partitioning Kernel's design and
                        implementation to assure the authorized data transfers (O.SOUND_DESIGN,
                        O.SOUND_IMPLEMENTATION).
                        Suspending an information flow to implement a scheduling policy is not to be construed,
                        per se, as poor transfer on the part of the Partitioning Kernel.
T.SYSACC                A malicious or faulty subject may gain unauthorized access to Partitioning Kernel
                        services reserved for trusted subjects.
                        Use of services reserved for trusted subjects is protected by validating all service requests
                        (O.SELF_PROTECT).
T.UNAUTH_ACCESS         A malicious or faulty subject may access memory cells that have not been allocated to it.
                        The Partitioning Kernel is required to use the hardware capabilities to enforce data
                        isolation (O.PARTITION_PROTECT).
T.UNSANITIZED           A subject may gain unauthorized information from an improperly sanitized shared
                        resource.



9 June 2003                                   Version 1.3                                                 39
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

                         When control over a shared resource such as the processor or a block of memory is
                         transferred to a partition, the Partitioning Kernel is required to remove any residual
                         information that may have been left by a previous subject (O.CLEAR_RESIDUAL).
T.WRONG_CODE             The code of the Partitioning Kernel may be corrupted, or an incorrect version substituted,
                         prior to being loaded into the computer in which it will execute.
                         The code of the Partitioning Kernel must go through several processes on it way from the
                         TOE provider to the embedded system memory where it will execute. Careful control
                         over the configuration management process (O.CONFIG_MGMT), the delivery process
                         (O.TRUSTED_DELIVERY), and the process by which the delivered product is loaded
                         into the computer (OE.TRUSTED_LOAD) are required.
T.WRONG_COMM             An unauthorized communication may occur between partitions.
                         Correct communication among partitions is the primary aspect of the information flow
                         security policy that the Partitioning Kernel is required to implement
                         (O.INFORMATION_FLOW). In addition, there must be protection against certain
                         classes of covert channels. Responsibility for addressing the potential risks of covert
                         timing channels via non-static scheduling and processor cache is allocated to the
                         environment in which the Partitioning Kernel is used (OE.SCHEDULER_RMI,
                         OE.CACHE_MEM_RMI).
T.WRONG_CONFIG           The configuration data used by the Partitioning Kernel to control resource allocations and
                         inter-partition communications may not accurately reflect the end user’s intentions
                         regarding data isolation and information flow.
                         Adequate tools and documentation are mandated to aid the system Administrator in
                         properly constructing the Partitioning Kernel’s configuration data
                         (O.CONFIG_SUPPORT).


     Explanation of Policies to Objectives Mapping
P.SHARED_MEMORY          The Partitioning Kernel shall ensure that each shared memory segment can be accessed
                         only by those partitions explicitly authorized to do so, and only in the allowed mode,
                         read-only or read/write.
                         Certain hardware features must be present in order to control shared memory (see section
                         2 TOE Description). The Partitioning Kernel is required to employ these features to
                         control access to shared memory (O.PARTITION_PROTECT).
P.UNIQUE_PARTITION The Partitioning Kernel shall ensure that each subject is bound to exactly one partition,
                   and that each partition is bound to exactly one subject.
                         Partitions are created and allocated to subjects based on the Partitioning Kernel’s
                         configuration data (O.PARTITION_CREATE).
P.ISOLATION              Unless otherwise authorized by the Partitioning Kernel's configuration data, the
                         Partitioning Kernel shall ensure that a subject can read information from, or write
                         information to, only the partition to which it is bound.
                         Certain hardware features must be present in order to guarantee isolation (see section 2
                         TOE Description). The Partitioning Kernel is required to employ these features to isolate
                         partitions from each other (O.PARTITION_PROTECT).
P.INFO_FLOW              The Partitioning Kernel shall ensure that only explicitly authorized communications
                         occur between partitions or into or out of a partition.
                         The Partitioning Kernel’s configuration data specify the information flow control policy
                         that is to be enforced by the Partitioning Kernel (O.INFORMATION_FLOW).




9 June 2003                                   Version 1.3                                                40
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

     Explanation of Assumptions to Objectives Mapping
A.TRUSTED_LOAD             It is assumed that the code and configuration data for the Partitioning Kernel are reliably
                           loaded into the processor and is reliably protected from unauthorized modification.
                           Because the mechanisms for loading the Partitioning Kernel and its configuration data
                           can be very different for different applications, the requirement for trusted load is
                           allocated to the system in which the Partitioning Kernel is being used
                           (OE.TRUSTED_LOAD).
A.SCHEDULER_RMI            If a non-static time partitioning mechanism is employed, it is assumed that the potential
                           risks of covert timing channels and denial of service threats have been addressed.
                           The potential risks of covert timing channels and DOS due to processor contention can be
                           eliminated by using a statically defined schedule for partition execution. However, this
                           may be incompatible with the performance requirements for some systems. Therefore
                           this PP allows the accreditation process for the system containing the Partitioning Kernel
                           to assess the potential risks and/or if necessary eliminate them by other means
                           (OE.SCHEDULER_RMI).
A.CACHE_MEM_RMI            If the Partitioning Kernel does not flush cache during the transition of the processor from
                           one partition to another, then it is assumed that the potential risks of covert timing
                           channels have been addressed.
                           Cache misses due to varying use of cache can affect program timing and are potential
                           covert timing channels. Since flushing cache may create an unacceptable performance
                           penalty for some systems, the responsibility for addressing the potential risks is allocated
                           to the system (OE.CACHE_MEM_RMI).



Security Requirements Rationale

This section demonstrates that the set of security requirements identified in Section 5 is suitable to meet the security
objectives identified in Section 4. In tables 6-3 and 6-4, requirements prefixed with ―Env‖ have been allocated to
the IT environment.


                      Table 6-3 Mapping the TOE Security Objectives to the Requirements
                   Objectives                                    Requirements
              O.CLEAR_RESIDUAL                          FDP_RIP.2.1
              O.CONFIG_MGMT                             ACM_AUT.2
              O.CONFIG_MGMT                             ACM_CAP.5
              O.CONFIG_MGMT                             ACM_SCP.3
              O.CONFIG_SUPPORT                          FMT_MCD_EXP.1.2
              O.CONFIG_SUPPORT                          AGD_ADM.1
              O.CONFIG_SUPPORT                          AGD_USR.1
              O.FAIL_SAFE                               FPT_FLS.1.1
              O.INFORMATION_FLOW                        FDP_IFC.2.1
              O.INFORMATION_FLOW                        FDP_IFC.2.2
              O.INFORMATION_FLOW                        FDP_RIP.2.1
              O.INFORMATION_FLOW                        FCO_NRO_EXP.1.1
              O.INFORMATION_FLOW                        FDP_IFF.1.1
              O.INFORMATION_FLOW                        FDP_IFC_EXP.1.1
              O.INFORMATION_FLOW                        Env FMT_MSA.1.1
              O.INFORMATION_FLOW                        Env FMT_MSA.3.1
              O.INFORMATION_FLOW                        Env FMT_MSA.3.2
9 June 2003                                      Version 1.3                                                 41
       Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

              O.PARTITION_CREATE                  FRU_RSA.1.1
              O.PARTITION_CREATE                  FPT_SEP.1.2
              O.PARTITION_PROTECT                 FPT_SEP.1.2
              O.RESOURCE_GUARANTEE                FRU_RSA.1.1
              O.RESOURCE_GUARANTEE                FRU_RSA_EXP.1.1
              O.SELF_PROTECT                      FAU_GEN.1.1
              O.SELF_PROTECT                      FAU_GEN.1.2
              O.SELF_PROTECT                      FPT_STM_1.1
              O.SELF_PROTECT                      FPT_AMT.1.1
              O.SELF_PROTECT                      FPT_FLS.1.1
              O.SELF_PROTECT                      FPT_RVM.1.1
              O.SELF_PROTECT                      FPT_SEP.1.1
              O.SELF_PROTECT                      FPT_TST.1.1
              O.SELF_TEST                         FPT_AMT.1.1
              O.SELF_TEST                         FPT_TST.1.1
              O.SELF_TEST                         FPT_TST.1.2
              O.SELF_TEST                         FPT_TST.1.3
              O.SOUND_DESIGN                      FDP_IFC_EXP.1.1
              O.SOUND_DESIGN                      FRU_RSA_EXP.1
              O.SOUND_DESIGN                      ALC_DVS.2
              O.SOUND_DESIGN                      ALC_LCD.3
              O.SOUND_DESIGN                      ALC_TAT.3
              O.SOUND_DESIGN                      ALC_FLR.3
              O.SOUND_DESIGN                      ADV_FSP.4
              O.SOUND_DESIGN                      ADV_HLD.5
              O.SOUND_DESIGN                      ADV_LLD.2
              O.SOUND_DESIGN                      ADV_SPM.3
              O.SOUND_DESIGN                      ADV_RCR.3
              O.SOUND_DESIGN                      AVA_MSU.3
              O.SOUND_DESIGN                      AVA_VLA.4
              O.SOUND_DESIGN                      AVA_SOF.1
              O.SOUND_DESIGN                      AMA_AMP.1
              O.SOUND_DESIGN                      AMA_CAT.1
              O.SOUND_DESIGN                      AMA_EVD.1
              O.SOUND_DESIGN                      AMA_SIA.2
              O.SOUND_IMPLEMENTATION              FDP_IFC_EXP.1.1
              O.SOUND_IMPLEMENTATION              FRU_RSA_EXP.1
              O.SOUND_IMPLEMENTATION              ALC_DVS.2
              O.SOUND_IMPLEMENTATION              ALC_LCD.3
              O.SOUND_IMPLEMENTATION              ALC_TAT.3
              O.SOUND_IMPLEMENTATION              ALC_FLR.3
              O.SOUND_IMPLEMENTATION              ADV_FSP.4
              O.SOUND_IMPLEMENTATION              ADV_HLD.5
              O.SOUND_IMPLEMENTATION              ADV_LLD.2
              O.SOUND_IMPLEMENTATION              ADV_IMP.3
              O.SOUND_IMPLEMENTATION              ADV_INT.3
              O.SOUND_IMPLEMENTATION              ADV_RCR.3
              O.SOUND_IMPLEMENTATION              AVA_CCA.2
              O.SOUND_IMPLEMENTATION              AVA_MSU.3
              O.SOUND_IMPLEMENTATION              AVA_VLA.4
              O.SOUND_IMPLEMENTATION              AVA_SOF.1
              O.SOUND_IMPLEMENTATION              ATE_COV.3
9 June 2003                                 Version 1.3                                            42
       Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

              O.SOUND_IMPLEMENTATION              ATE_DPT.3
              O.SOUND_IMPLEMENTATION              ATE_FUN.2
              O.SOUND_IMPLEMENTATION              ATE_IND.3
              O.SOUND_IMPLEMENTATION              AMA_AMP.1
              O.SOUND_ IMPLEMENTATION             AMA_CAT.1
              O.SOUND_ IMPLEMENTATION             AMA_EVD.1
              O.SOUND_ IMPLEMENTATION             AMA_SIA.2
              O.TESTING                           ATE_IND.3
              O.TESTING                           ATE_FUN.2
              O.TESTING                           ATE_COV.3
              O.TESTING                           ATE_DPT.3
              O.TESTING                           FPT_TST.1.2
              O.TESTING                           FPT_TST.1.3
              O.TRUSTED_DELIVERY                  ADO_DEL.3
              O.TRUSTED_STARTUP                   FPT_IGS_EXP.1.2
              O.TRUSTED_STARTUP                   ADO_IGS.1
              OE.TRUSTED_LOAD                     Env FPT_IGS_EXP.1.1
              OE.TRUSTED_LOAD                     Env ADO_IGS.1
              OE.TRUSTED_LOAD                     FMT_MCD_EXP.1.1
              OE.SCHEDULER_RMI                    Env AVA_RMI_EXP.1.1
              OE.CACHE_MEM_RMI                    Env AVA_RMI_EXP.1.2


                   Table 6-4 Mapping the Requirements to the TOE Security Objectives
                  Requirements                             Objectives
              ACM_AUT.2                           O.CONFIG_MGMT
              ACM_CAP.5                           O.CONFIG_MGMT
              ACM_SCP.3                           O.CONFIG_MGMT
              ADO_DEL.3                           O.TRUSTED_DELIVERY
              ADV_FSP.4                           O.SOUND_DESIGN
              ADV_FSP.4                           O.SOUND_IMPLEMENTATION
              ADV_HLD.5                           O.SOUND_DESIGN
              ADV_HLD.5                           O.SOUND_IMPLEMENTATION
              ADV_IMP.3                           O.SOUND_IMPLEMENTATION
              ADV_INT.3                           O.SOUND_IMPLEMENTATION
              ADV_LLD.2                           O.SOUND_DESIGN
              ADV_LLD.2                           O.SOUND_IMPLEMENTATION
              ADV_RCR.3                           O.SOUND_DESIGN
              ADV_RCR.3                           O.SOUND_IMPLEMENTATION
              ADV_SPM.3                           O.SOUND_DESIGN
              AGD_ADM.1                           O.CONFIG_SUPPORT
              AGD_USR.1                           O.CONFIG_SUPPORT
              ALC_DVS.2                           O.SOUND_DESIGN
              ALC_DVS.2                           O.SOUND_IMPLEMENTATION
              ALC_FLR.3                           O.SOUND_DESIGN
              ALC_FLR.3                           O.SOUND_IMPLEMENTATION
              ALC_LCD.3                           O.SOUND_DESIGN
              ALC_LCD.3                           O.SOUND_IMPLEMENTATION
              ALC_TAT.3                           O.SOUND_DESIGN
              ALC_TAT.3                           O.SOUND_IMPLEMENTATION
              AMA_AMP.1                           O.SOUND_DESIGN
              AMA_AMP.1                           O.SOUND_IMPLEMENTATION
9 June 2003                                 Version 1.3                                            43
       Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

              AMA_CAT.1                           O.SOUND_DESIGN
              AMA_CAT.1                           O.SOUND_IMPLEMENTATION
              AMA_EVD.1                           O.SOUND_DESIGN
              AMA_EVD.1                           O.SOUND_IMPLEMENTATION
              AMA_SIA.2                           O.SOUND_DESIGN
              AMA_SIA.2                           O.SOUND_IMPLEMENTATION
              ATE_COV.3                           O.SOUND_IMPLEMENTATION
              ATE_COV.3                           O.TESTING
              ATE_DPT.3                           O.SOUND_IMPLEMENTATION
              ATE_DPT.3                           O.TESTING
              ATE_FUN.2                           O.SOUND_IMPLEMENTATION
              ATE_FUN.2                           O.TESTING
              ATE_IND.3                           O.SOUND_IMPLEMENTATION
              ATE_IND.3                           O.TESTING
              AVA_CCA.2                           O.SOUND_IMPLEMENTATION
              AVA_MSU.3                           O.SOUND_DESIGN
              AVA_MSU.3                           O.SOUND_IMPLEMENTATION
              AVA_SOF.1                           O.SOUND_DESIGN
              AVA_SOF.1                           O.SOUND_IMPLEMENTATION
              AVA_VLA.4                           O.SOUND_DESIGN
              AVA_VLA.4                           O.SOUND_IMPLEMENTATION
              Env ADO_IGS.1                       OE.TRUSTED_LOAD
              ADO_IGS.1                           O.TRUSTED_STARTUP
              Env AVA_RMI_EXP.1.1                 OE.SCHEDULER_RMI
              Env AVA_RMI_EXP.1.2                 OE.CACHE_MEM_RMI
              Env FPT_IGS_EXP.1.1                 OE.TRUSTED_LOAD
              FPT_IGS_EXP.1.2                     O.TRUSTED_STARTUP
              FCO_NRO_EXP.1.1                     O.INFORMATION_FLOW
              FAU_GEN.1.1                         O.SELF_PROTECT
              FAU_GEN.1.2                         O.SELF_PROTECT
              FDP_IFC.2.1                         O.INFORMATION_FLOW
              FDP_IFC.2.2                         O.INFORMATION_FLOW
              FDP_IFC.2.2                         O.SOUND_DESIGN
              FDP_IFC.2.2                         O.SOUND_IMPLEMENTATION
              FDP_IFC_EXP.1.1                     O.INFORMATION_FLOW
              FDP_IFF.1.1                         O.INFORMATION_FLOW
              FDP_RIP.2.1                         O.CLEAR_RESIDUAL
              FDP_RIP.2.1                         O.INFORMATION_FLOW
              FMT_MCD_EXP.1.1                     OE.TRUSTED_LOAD
              FMT_MCD_EXP.1.2                     O.CONFIG_SUPPORT
              Env FMT_MSA.1.1                     O.INFORMATION_FLOW
              Env FMT_MSA.3.1                     O.INFORMATION_FLOW
              Env FMT_MSA.3.2                     O.INFORMATION_FLOW
              FPT_AMT.1.1                         O.SELF_PROTECT
              FPT_AMT.1.1                         O.SELF_TEST
              FPT_FLS.1.1                         O.FAIL_SAFE
              FPT_FLS.1.1                         O.SELF_PROTECT
              FPT_RVM.1.1                         O.SELF_PROTECT
              FPT_SEP.1.1                         O.SELF_PROTECT
              FPT_SEP.1.2                         O.PARTITION_CREATE
              FPT_SEP.1.2                         O.PARTITION_PROTECT
              FPT_STM.1.1                         O.SELF_PROTECT
9 June 2003                                 Version 1.3                                            44
       Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

              FPT_TST.1.1                           O.SELF_PROTECT
              FPT_TST.1.1                           O.SELF_TEST
              FPT_TST.1.2                           O.SELF_TEST
              FPT_TST.1.2                           O.TESTING
              FPT_TST.1.3                           O.SELF_TEST
              FPT_TST.1.3                           O.TESTING
              FRU_RSA.1.1                           O.PARTITION_CREATE
              FRU_RSA.1.1                           O.RESOURCE_GUARANTEE
              FRU_RSA_EXP.1.1                       O.RESOURCE_GUARANTEE
              FRU_RSA_EXP.1.1                       O.SOUND_DESIGN
              FRU_RSA_EXP.1.1                       O.SOUND_IMPLEMENTATION



Explanation of mapping from Objectives to Requirements
O.CLEAR_RESIDUAL                 The Partitioning Kernel shall clear residual information prior to reassigning a
                                 resource to a subsequent subject.
                                 The previous content of any shared resource must be cleared before another
                                 subject can be allowed to use the resource (FDP_RIP.2.1).
O.CONFIG_MGMT                    Every delivered version of the Partitioning Kernel shall be uniquely identified,
                                 and all changes to the Partitioning Kernel and its development evidence shall be
                                 documented, tracked, and controlled.
                                 Versions of the TOE must be tracked (ACM_SCP.3) to prevent uncontrolled
                                 changes from being introduced during its development. The automated system
                                 (ACM_AUT.2) will track the TOE and its associated documentation
                                 (ACM_CAP.5), along with any security flaws that are discovered during
                                 development.
O.CONFIG_SUPPORT                 A combination of instruction materials and support tools shall be provided to aid
                                 the end user in constructing Partitioning Kernel configuration data that
                                 accurately reflect the end user’s intentions regarding partitioning and
                                 information flow.
                                 A support tool (FMT_MCD_EXP.1.2) is mandated to help check for errors or
                                 inconsistencies in the Partitioning Kernel's configuration data, and to present the
                                 data to a human administrator in a format that is easy to understand and check.
                                 Documentation on how to construct configuration data (AGD_ADM.1) and use
                                 special security functions of the Partitioning Kernel (AGD_USR.1) are also
                                 required.
O.FAIL_SAFE                      The Partitioning Kernel shall ensure that hardware-detected faults do not result
                                 in violations of the data isolation and information flow control security policies.
                                 This shall apply to all hardware-detected faults, whether they occur within the
                                 Partitioning Kernel domain or within a subject's domain.
                                 The Partitioning Kernel is required to handle fault interrupts (FPT_FLS.1.1) in a
                                 manner that maintains enforcement of the security policy.
O.INFORMATION_FLOW               The Partitioning Kernel shall enforce information flow control between
                                 partitions, and into and out of partitions, as specified in its configuration data.
                                 The Partitioning Kernel must enforce the information flow control policy
                                 specified in its configuration data (FDP_IFC.2.1), and all operations that cause
                                 information flow must be covered by that policy (FDP_IFC.2.2). The
                                 information flow must be error free (FDP_IFC_EXP.1.1). Information flow
                                 control is based on subject/partition privileges and interconnections
                                 (FDP_IFF.1.1) specified in the Partitioning Kernel's configuration data. Control

9 June 2003                                   Version 1.3                                                  45
       Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

                                 of the security attributes for information flow in the configuration data is limited
                                 to the system configurer (FMT_MSA.1.1, FMT_MSA.3.1, FMT_MSA.3.2).
                                 Potential covert data channels are prevented by clearing residual information
                                 from shared resources before they can be used by a new subject (FDP_RIP.2.1).
                                 Support is provided for application-specific security functions by providing the
                                 identity of the sender of information that is passed between partitions
                                 (FCO_NRO_EXP.1.1).


O.PARTITION_CREATE               As directed by its configuration data, the Partitioning Kernel shall create and
                                 initialize exactly one partition for each subject, and allocate all required
                                 resources to it.
                                 A separate partition must be created for each subject so that its security domain
                                 is separate from the domains of the other subjects (FPT_SEP.1.2). Each subject
                                 is guaranteed to have the resources allocated to it in the Partitioning Kernel's
                                 configuration data (FRU_RSA.1.1).
O.PARTITION_PROTECT              Except where shared memory areas are explicitly authorized by the Partitioning
                                 Kernel's configuration data, the Partitioning Kernel shall maintain separation
                                 between partitions, ensuring that each subject can read from and write to only
                                 the partition to which it is bound.
                                 The security domains of subjects must be kept separate from each other
                                 (FPT_SEP.1.2).
O.RESOURCE_GUARANTEE             The Partitioning Kernel shall guarantee that all resources allocated to a partition
                                 by the Partitioning Kernel’s configuration data shall always be available to that
                                 partition. This includes memory allocated to the partition, any Partitioning
                                 Kernel resources necessary to support execution or communication, and
                                 statically allocated execution times, if any.
                                 The Partitioning Kernel guarantees that the quotas established by the
                                 configuration data will not be infringed upon by a subject that attempts to
                                 exceed its own quotas (FRU_RSA.1.1). Furthermore, the Partitioning Kernel
                                 itself will have deterministic resource utilization and not infringe upon a
                                 subject’s allocated resources and induce nondeterminism in an otherwise
                                 deterministic subject. (FRU_RSA_EXP.1.1).
O.SELF_PROTECT                   The Partitioning Kernel shall maintain a domain for its own execution to protect
                                 itself from interference or tampering.
                                 The TOE protects itself by verifying that the processor and its own functions are
                                 working correctly (FPT_AMT.1.1, FPT_TST.1.1), and by responding to
                                 hardware-detected faults in a safe manner (FPT_FLS.1.1). It controls the
                                 hardware protection features to ensure that TSP enforcement functions are non-
                                 bypassable (FPT_RVM.1.1), and to maintain a separate domain for its own
                                 execution (FPT_SEP.1.1). Attempted memory access violations will captured in
                                 a time-stamped audit record (FAU_GEN.1.1, FAU_GEN.1.2, FPT_STM.1.1).
O.SELF_TEST                      The TOE shall provide self test to demonstrate correct operation of the TSF.
                                 The Partitioning Kernel tests the operation of both the processor and its own
                                 functions (FPT_AMT.1.1, FPT_TST.1.1). Additional capability is provided for
                                 trusted subjects to verify the integrity of the Partitioning Kernel’s data
                                 (FPT_TST.1.2) and code (FPT_TST.1.3) so that tests may be conducted by the
                                 during normal operations.
O.SOUND_DESIGN                   The design of the Partitioning Kernel shall account for, and be traceable to, all
                                 of its functional requirements.
                                 A sound design depends upon development (ALC_DVS.2) in a well-defined
                                 life-cycle model (ALC_LCD.3). This includes identifying the development
9 June 2003                                  Version 1.3                                                 46
       Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

                                 tools used (ALC_TAT.3), remediating any flaws discovered during maintenance
                                 (ALC_FLR.3), and assuring that the TOE will continue to meet its security
                                 target as changes are made to the TOE or its environment (AMA_AMP.1,
                                 AMA_CAT.1, AMA_EVD.1, AMA_SIA.2).
                                 The correspondences among the development documentation (ADV_FSP.4,
                                 ADV_HLD.5, ADV_LLD.2, ADV_SPM.3) must be documented
                                 (ADV_RCR.3). System-level problems in the design can be detected by an
                                 analysis of any vulnerabilities that might be caused by unclear documentation
                                 (AVA_MSU.3). These analyses for vulnerabilities must be systematic and show
                                 that the TOE is resistant to attackers with a high attack potential (AVA_VLA.4).
                                 There must be an analysis of the strength of the functions (AVA_SOF.1).
                                 The Partitioning Kernel must be designed to not induce nondeterminism in an
                                 otherwise deterministic subject (FRU_RSA_EXP.1.1). The Partitioning Kernel
                                 must also be designed to prevent loss of use (including untimely transfer) of
                                 information when it is transferred between subjects over the authorized
                                 channels. (FDP_IFC_EXP.1.1)
O.SOUND_IMPLEMENTATION The implementation of the Partitioning Kernel shall be an accurate instantiation
                       of its design.
                                 A sound implementation depends upon careful development (ALC_DVS.2) in a
                                 well-defined life-cycle model (ALC_LCD.3). This includes identifying the
                                 development tools used (ALC_TAT.3), remediating any flaws discovered during
                                 maintenance (ALC_FLR.3), and assuring that the TOE will continue to meet its
                                 security target as changes are made to the TOE or its environment
                                 (AMA_AMP.1, AMA_CAT.1, AMA_EVD.1, AMA_SIA.2).
                                 The correspondences among the development documentation (ADV_FSP.4,
                                 ADV_HLD.5, ADV_LLD.2, ADV_IMP.3, ADV_INT.3) must be documented
                                 (ADV_RCR.3). Problems with the implementation can be found from an
                                 analysis of covert channels (AVA_CCA.2). System-level problems in the
                                 design can be detected by an analysis of any vulnerabilities that might be caused
                                 by unclear documentation (AVA_MSU.3). These analyses for vulnerabilities
                                 must be systematic and show that the TOE is resistant to attackers with a high
                                 attack potential (AVA_VLA.4). There must also be an analysis of the strength
                                 of the functions (AVA_SOF.1).
                                 Testing – both that is performed as part of the developer’s testing effort
                                 (ATE_COV.3, ATE_DPT.3, ATE_FUN.2) as well as independent testing
                                 (ATE_IND.3) for vulnerabilities theorized by these analyses—also helps to
                                 reduce implementation flaws.
                                 The Partitioning Kernel must be implemented to not induce nondeterminism in
                                 an otherwise deterministic subject (FRU_RSA_EXP.1.1). The Partitioning
                                 Kernel must also be implemented to prevent loss of use (including untimely
                                 transfer) of information when it is transferred between subjects over the
                                 authorized channels. (FDP_IFC_EXP.1.1).
O.TESTING                        The Partitioning Kernel shall undergo independent Security Verification (SV)
                                 Testing, based at least in part on an independent vulnerability analysis.
                                 The TOE must undergo independent testing (ATE_IND.3) based upon the
                                 developer’s test effort (ATE_FUN.2). The developer’s testing effort must show
                                 adequate coverage (ATE_COV.3) and depth (ATE_DPT.3) to be considered
                                 complete.
                                 Testing is aided by the testing interfaces (FPT_TST.1.2, FPT_TST.1.3).
O.TRUSTED_DELIVERY               A trusted delivery capability shall be provided to ensure that the code for the
                                 Partitioning Kernel that is to be loaded into the processor is a valid copy of the
                                 identified version.
9 June 2003                                  Version 1.3                                                 47
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

                                   The procedures for trusted delivery must be documented and shown to be
                                   effective (ADO_DEL.3).
O.TRUSTED_STARTUP                  A trusted startup capability shall be provided to ensure that the Partitioning
                                   Kernel reaches a secure initial state after power-on or a processor reset.
                                   The trusted startup requirement (FPT_IGS_EXP.1.2) provides that control is
                                   reliably passed to the Partitioning Kernel. This may be done by hardware
                                   directly or software that executes first then passes control to the Partitioning
                                   Kernel. As such, this capability is considered part of the TOE, although not
                                   necessarily part of the Partitioning Kernel. Documentation for secure startup
                                   procedures (ADO_IGS.1) must also be provided by the developer.
OE.TRUSTED_LOAD                    A trusted load capability shall be provided to ensure that the code and
                                   configuration data for the Partitioning Kernel are reliably loaded into the
                                   processor and are protected from unauthorized modification.
                                   The trusted load requirement (FPT_IGS_EXP.1.1) is allocated to the IT
                                   environment because it is application-specific. Documentation for secure load
                                   procedures (ADO_IGS.1) must also be provided by the application system
                                   developer.
                                   While the loading function is application-specific and therefore performed
                                   outside of the Partitioning Kernel, it can be aided by an appropriate interface
                                   (FMT_MCD_EXP.1.1).
OE.SCHEDULER_RMI                   If a non-static time partitioning mechanism is employed, an explanation shall be
                                   provided for how potential risks of covert timing channels and denial of service
                                   threats have been addressed.
                                   If the system is exposed to a risk of covert timing channels and denial of service
                                   because a non-static scheduler is needed, the responsibilities for secure usage are
                                   assigned to the IT environment (AVA_RMI_EXP.1.1).




OE.CACHE_MEM_RMI                   If the Partitioning Kernel does not flush cache memories during the transition of
                                   the processor from one partition to another, an explanation shall be provided for
                                   how that the potential risks of covert timing channels based on cache usage have
                                   been addressed.
                                   If an application developer chooses not to have cache flushed on partition
                                   transitions, the responsibilities of secure operation are assigned to the IT
                                   environment (AVA_RMI_EXP.1.2).




Explicit Requirements Rationale
The following explicit requirements have been included in this Protection Profile because the Common Criteria
requirements were found to be insufficient as stated.
 FCO_NRO_EXP.1            The non-repudiation requirements in the CC imply a fairly heavy mechanism for creating
                          a permanent record of the origin of a data transfer. But in the case of the Partitioning
                          Kernel, the receiving partition just needs to know the authenticated identity of the sender
                          so that it can handle the data accordingly.
                          FCO_NRO_EXP.1 requires that a simple ―who sent that‖ service be provided by the
                          Partitioning Kernel.

9 June 2003                                    Version 1.3                                                 48
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

 FDP_IFC_EXP.1.1          The authorized information flows are established statically in the Partitioning Kernel’s
                          configuration data. When information is transferred over these flows, the TSF could
                          delay the flow or modify the data in some way (corrupt, truncate, or append). The CC
                          user data protection requirements do not account for this.
 FMT_MCD_EXP.1.1          The information flow security policy is established statically in the Partitioning Kernel’s
                          configuration data. The configuration data could be loaded with the Partitioning Kernel
                          code at initialization, but from that point on they could not be changed to allow different
                          configurations of partitions. The CC security management requirements do not account
                          for this case.
                          FMT_MCD_EXP.1.1 makes it possible for a trusted partition to serve as a loader
                          function that can provide updated configuration data to the Partitioning Kernel and verify
                          that the Partitioning Kernel’s copy is correct.
 FMT_MCD_EXP.1.2          The security management capabilities described in the CC are aimed at complete systems
                          in which an Administrator can create, delete, and modify the security attributes of
                          subjects and objects. But none of this applies in the case of a Partitioning Kernel because
                          the existence and attributes of subjects and objects are established statically in the
                          Partitioning Kernel’s configuration data and objects do not exist.
                          The role of the Administrator is to create the Partitioning Kernel’s configuration data off-
                          line. If there are many subjects, connections, and privileges, these data could be error-
                          prone and difficult to validate. FMT_MCD_EXP.1.2 requires a supporting tool that will
                          help to check for errors in the Partitioning Kernel's configuration data and will present
                          the data in a way that is easy for a human administrator to understand and check.
 FPT_IGS_EXP.1            The trusted recovery requirements in the CC assume that there is a human administrator
                          available to perform manual measures if required. They also assume that the recovery
                          function is integral to the TOE. But a Partitioning Kernel is intended to be installed in
                          many different systems, and each system will have its own unique system load and start-
                          up mechanisms.
                          FPT_IGS_EXP.1.1 and 1.2 allow the trusted load and start-up functions to be separated
                          from the Partitioning Kernel so that the Partitioning Kernel will not contain any
                          application-specific code. They also permit completely automated mechanisms for load
                          and start-up, as will normally be required in an embedded, real-time system.
 FRU_RSA_EXP.1            The resource utilization requirements in the CC address denial of service by means of
                          monopolization of resources by other subjects. But in embedded, real-time systems,
                          many applications have a requirement for predictable, bounded worst-case performance
                          and resource utilization.
                          FRU_RSA_EXP.1.1 ensures that the Partitioning Kernel does not induce nondeterminism
                          in otherwise deterministic subjects by nondeterministic resource utilization itself.
 ADO_IGS_EXP.1            Because the requirement for trusted load has been allocated to the environment the
                          requirement for documenting those procedures must also be allocated to the environment.
                          ADO_IGS_EXP.1 assigns responsibility to the ―environment developer,‖ rather than the
                          TOE developer as stated in CC requirement ADO_IGS.1.1D
 AVA_RMI_EXP.1.1, 1.2 – Because the Partitioning Kernel is intended to be used in embedded, real-time systems,
                      this PP is in the conflicting position of having to allow certain practices for performance
                      reasons that may require prohibition for security reasons.
                          AVA_RMI_EXP.1.1 and 1.2 shift the burden of enforcement to the IT environment for
                          those aspects of the security policy that might otherwise be violated by these practices.
                          This permits the system developer to counter the potential threats posed by these
                          practices using techniques that are outside the realm of the Partitioning Kernel.


Rationale for Strength of Function
No Partitioning Kernel functions have been identified for which a Strength of Function argument is applicable.
9 June 2003                                    Version 1.3                                               49
        Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness

Rationale for Assurance Rating
This protection profile has been developed for a DoD high robustness environment. The intent is to provide a
Partitioning Kernel for a deeply embedded real time system that can enforce separation of data classified at
unclassified through Top Secret with uncleared authorized users having access to the system. The end system would
require additional policy enforcement mechanisms running on the Partitioning Kernel, such as a reference monitor
for messaging or application-level data handling. Current NSA guidance indicates EAL7 will provide sufficient
assurance that the Partitioning Kernel will maintain the isolation of partitions operating at different security levels
and allow only authorized information flows between partitions.




9 June 2003                                      Version 1.3                                               50
       Protection Profile for Partitioning Kernels in Environments Requiring Augmented High Robustness


References
[1]   National Security Telecommunications and Information Systems Security Committee, National Information
      Systems Security (INFOSEC) Glossary, NSTISSI No. 4009, September 2000.




9 June 2003                                 Version 1.3                                            51
Appendix
Implementation Notes

These notes describe the Partitioning Kernel as conceived by the Protection Profile authors. It may help some
readers understand what the Partioning Kernel can do, and others how it may be implemented. However, there may
be many different ways to successfully and securely implement and utilize a Partitioning Kernel.
The Partitioning Kernel makes use of memory mapping and privileged mode protection features of the processor
hardware to ensure that it is tamper-proof, non-bypassable, and that software programs in partitions are isolated
from each other. It uses sanitization of the processor registers and memory blocks to help ensure that unauthorized
transfers of information between partitions do not occur.
The Partitioning Kernel enforces a static (i.e. pre-determined and fixed) information flow control security policy
among subjects. The authorized information flows are defined in configuration data that must be provided to the
Partitioning Kernel in a secure manner when software programs are loaded. The Partitioning Kernel also allocates
processor time among the subjects so that their program instructions may be executed.
A high-assurance Partitioning Kernel can serve as a foundation upon which project-specific security policies can be
implemented. Its several advantages include:
        A single physical processor may host multiple functions operating at different security levels. A system can
         be built on the Partitioning Kernel so that physically isolated processors are not required, thus reducing
         hardware costs, weight, power consumption, and other related requirements.
        A composition of evaluated system components can leverage the individual component evaluations,
         provided that the assumptions behind those evaluations are satisfied.
        Certification costs are reduced because the system level certification can reference the individual system
         component evaluations. The system level certification documentation should describe how the
         assumptions made in those system component evaluations are satisfied by the system.
        Each component may be evaluated just once, independently, and incorporated by multiple systems.
        Real-time performance may be supported in a securely partitioned system. However the choice of the
         scheduling algorithm is not specified in this protection profile and providing support for real-time
         performance is the responsibility of the implementer.
The Partitioning Kernel provides the following critical security functions:
    o    Data isolation is the stipulation that the memory cells of a partition cannot be modified by any subject
         other than the one that is exclusively bound to that partition.
    o    Information flow control is a modification of Data Isolation that allows specifically authorized transfers of
         data from one partition to another. Information Flow Control is the stipulation that only these specifically
         authorized transfers can occur and cannot be prevented from occurring by partitions not involved in the
         transfer. In systems that use shared memory as part of the transfer mechanism, multiple subjects may
         access the same memory segment.
    o    Sanitization is the supporting process of removing residual information from a shared resource so as to
         prevent the violation of the Data Isolation or Information Flow Control functions. The primary examples
         of sanitization are: (1) clearing processor registers before transferring control of the processor to a subject;
         (2) clearing a block of memory before allocating it to a partition.
The security functional requirements and the security assurance requirements discussed in this protection profile are
intended to support these three functions. In order to provide high assurance of satisfying the three functions, there
are four characteristics of the Partitioning Kernel that must be supported by the lower level functional and assurance
requirements herein:
             The Partitioning Kernel must be implemented in such a way that the information flow control security
              policy is always invoked and the information flows in a timely manner.
             The Partitioning Kernel must be non-bypassable and subject to no conditions limiting the enforcement
              of the information flow control security policy.
9 June 2003                                       Version 1.3                                                 52
             The Partitioning Kernel must be tamper-proof, which requires that the Partitioning Kernel operation be
              isolated from other activities within the system.
             The Partitioning Kernel must be evaluatable, which requires the above security functions to be
              explicitly defined and the proof of the implementation to be capable of being checked with a freely
              available theorem proving system. The Partitioning Kernel must also be sufficiently modular and well
              designed so that formal methods may be reasonably applied.
The general requirements that specify the features and functions of the Partitioning Kernel, and the syntax and
semantics of its interfaces, are not included in this document. Nevertheless, some of those requirements must be
anticipated here because a kernel that has no general requirements should have no features or functions, and
consequently, no security requirements. Conversely, because of the limited scope of the Partitioning Kernel, this PP
does not include many security functions that normally would be considered to be part of a secure information
processing system. In particular, if any of the following functions are deemed necessary for a system, they will have
to be implemented by additional software outside the Partitioning Kernel: security audit; non-repudiation (except for
basic sender ID); cryptographic support; user data protection (except for the partition isolation and information flow
control); user identification and authentication; user privacy; functions related to distributed or multi-processor
systems; control of user sessions.
This protection profile may differ from protection profiles for other operating systems by the following set of key
characteristics of the underlying Partitioning Kernel:
             Real-time.
             Deterministic.
             Multiple partitions (number constrained only by resource availability).
             Statically defined system configuration.
             Static and/or dynamic scheduling support.
             Hardware supported data isolation techniques.
             Sanitization applied before switching partitions
             No users (subjects only).
             Support for ―user mode‖ device drivers.
             Support for short hardware exception handlers.
             No file system or built-in communication protocols.
             Small installation size.
This protection profile defines the Partitioning Kernel as a foundation component on which to build other
components. These composite components, which may have their own protection profiles, could include: run-time
systems (e.g. Ada 95 or defined subset), support libraries (e.g. C, C++, ARINC-653, POSIX, or defined subsets), file
systems, communication protocols, device drivers, and reference monitors.
This protection profile does not define the set of operating system features the Partitioning Kernel must provide for
application support, since they are not security relevant. However, the typical Partitioning Kernel, in combination
with a subset of support components, might support common embedded real-time operating system features such as
multi-threading, inter-partition communications, time management, semaphores, and I/O device management.
The Partitioning Kernel defined in this profile is intended for use in multi-level security systems. The profile is
sufficiently rich in features such that a compliant Partitioning Kernel may be used in other embedded applications
where considerations for security objectives such as covert channels are not necessary. This may include:
             Telecom switches (using non-static time scheduler).
             Commercial avionics.
             Automotive controls (including trains).
             Medical devices.

9 June 2003                                      Version 1.3                                               53
             Power plant controls (including nuclear).
             Mission computers.
             Theme park rides.
As such, data isolation becomes explicit. All internal processes (subjects) are separated in time through the partition
scheduler in the Partitioning Kernel. For all practical purposes, once configured, each partition within the processor
has a dedicated processor and execution environment.



                                                                       CONCEPTUAL MULTIPLE
       PHYSICAL MULTIPLE                                                  PROCESSORS
          PARTITIONS
                                                                  A




                                                                                                  I/O
                                   A                                     uPROC
                                   B                                                     MEM               A
                     A,B,C         C

                         A         A
     A B C                                                        B




                                                                                                  I/O
                                                                         uPROC
                         B
                         C
                                                                                         MEM               B
      uPROC
                                   B       B
                                           C                      C




                                                                                                  I/O
                                   C                                     uPROC
                                                                                         MEM               C


             Figure 0-1 Conceptual Processor System with Strong Functional Isolation

Time is partitioned into time-intervals, which are allocated to each of the subjects. Time may be statically allocated
(time-slice scheduling), or it may be allocated on demand based on preemptive priorities, deadlines, or some other
scheduling principle. Each subject is allowed exclusive use and control of the CPU and related hardware during its
time partition. During partition transitions, the trusted Partitioning Kernel has control of the CPU and read/write
access to the entire physical memory.
The choice of scheduling algorithm is not specified by this Protection Profile. If time-intervals are not statically
allocated, the variations in computing time utilized by subjects may potentially be used as covert channels and/or
means to implement denial-of-service attacks. The potential risks should be clearly identified in the guidance
documentation delivered with the Partitioning Kernel. The accreditor of a system employing a Partitioning Kernel
should consider the potential risks and mitigating factors if time-slice scheduling is not used.
The Partitioning Kernel is intended to be used as the foundation for a variety of application-specific systems,
primarily in support of an embedded, real-time operating system. The applications for which the Partitioning Kernel
is intended often have high levels of requirements for safety as well as for information security. The Partitioning
Kernel provides high-assurance partitioning and information flow control in a way that allows other software
components, such as a reference monitor, a device driver, a file manager, or a message-passing service, to be
implemented securely outside of the Partitioning Kernel.
The Partitioning Kernel mediates inter-partition communications on a single processor. Any communication across
processor boundaries, or use of external devices, will require additional software not covered by this PP. Most
operating system functions will also require additional software not covered by this PP. The Partitioning Kernel
will not contain any application-specific code. A properly constructed Partitioning Kernel can be evaluated once

9 June 2003                                      Version 1.3                                               54
and used without modification in many different systems. Software that implements additional security functionality
may also be evaluated separately. System certifications and accreditations can make use of the component
evaluations.


A. 1 Example Application System Using a Partitioning Kernel
As an example, a simple use of a Partitioning Kernel is illustrated in Figure 2-2. The figure shows five software
applications and two custom software components, each in its own partition. The Partitioning Kernel is not
explicitly shown. It is in the ―background‖, enforcing data isolation and information flow among the partitions.
    Processor
                                         Kernel-mediated connections between Apps 1-4 and
                                         the Reference Monitor

                    App 1
                                                              Application-specific
                                                              reference monitor


                                                  Reference                          Message
                    App 2
                                                   Monitor                            Service

                                                                                                   Data
                                                                                                   bus
  Separate
                    App 3
  partitions                                        Application-specific message
                                                    service between applications, both
                                                    within and between processors

                    App 4
                                                     Kernel mediated connection between
                                                     App4 and App5


                    App 5




                    Figure 0-2 Example Reference Monitor and Message Service
Software applications 1-4 are connected as clients through a reference monitor to a message service that can pass
messages between software programs, both within the processor and between processors. The reference monitor
verifies permissions to send or receive the messages according to an application system-specific policy.
Applications 4 and 5 are connected directly without going through the reference monitor.
Note that there are two levels of security policies being enforced in this example. The first is the Partitioning
Kernel-mediated connections between partitions. These are defined in configuration data provided to the
Partitioning Kernel when software programs are loaded. The Partitioning Kernel guarantees that these are the only
paths by which information can flow among the partitions. The second level is the application-specific access
control policy enforced by the reference monitor. The Partitioning Kernel-mediated first level policy provides
functions that the second level can use to make its security policy also tamper-proof and non-bypassable. Thus the
reference monitor can be evaluated as a modular component, separate from the Partitioning Kernel, but dependent
on the security functions provided by the Partitioning Kernel. No change to the Partitioning Kernel is required to
support this application-specific security policy.


A. 2 Hardware Support
The Partitioning Kernel depends on certain processor hardware features for its secure operation. Among these are:
              The presence of a memory management unit (MMU).

9 June 2003                                     Version 1.3                                               55
             A special privileged mode of operation.
             Instruction ―traps‖ to ensure that an attempt by non-privileged code to circumvent the partitioning
              features will transfer control directly to the Partitioning Kernel.
             A non-bypassable means to assure operation is returned to the Partitioning Kernel after some elapse of
              time. This may be provided by a Partitioning Kernel protected device in the hardware module.
This PP lists the hardware dependencies as assumptions to be verified when a processor is selected. It is the intent
of this PP that evaluation of a processor will take place separately from that of a Partitioning Kernel. The evaluation
of the Partitioning Kernel may assume that the processor works as advertised and hardware does not contain features
can could potentially be used by subjects to violate data isolation and information flow control. (e.g. a Direct
Memory Access mechanism that bypasses the MMU.)
Modern processors make extensive use of cache memories to enhance performance. While these processors can be
trusted to not allow caches to serve as covert data channels, the degree to which cache ―misses‖ change the timing of
a program may serve as a covert timing channel. To prevent the covert channel, the Partitioning Kernel may have to
flush the caches whenever control of the processor transitions from one partition to another. But in many
applications, cache flushing may impose an unacceptable performance penalty. Therefore, this PP allows a
Partitioning Kernel to dispense with cache flushing by adding yet another environmental assumption: if cache
flushing is not used, it is assumed that the threat of a covert timing channel based on cache manipulation is
addressed at the system level.




9 June 2003                                      Version 1.3                                               56

				
DOCUMENT INFO