From 8aa4a8f7b089eb73535a4b8a48874d54ab10f05c Mon Sep 17 00:00:00 2001 From: kevin Date: Thu, 6 Oct 2022 12:08:18 -0400 Subject: [PATCH 01/13] Removed cc.xml. --- input/cc.xml | 53805 ------------------------------------------------- 1 file changed, 53805 deletions(-) delete mode 100755 input/cc.xml diff --git a/input/cc.xml b/input/cc.xml deleted file mode 100755 index 52c4e42b..00000000 --- a/input/cc.xml +++ /dev/null @@ -1,53805 +0,0 @@ - - - - - - - For the purposes of this document, the terms, definitions, - symbols and abbreviated terms given in CC Part 1 apply. - - - - Security assurance components, as defined in this CC Part 3, are - the basis for the security assurance requirements expressed in a - Protection Profile (PP) or a Security Target (ST). - - These requirements establish a standard way of expressing the - assurance requirements for TOEs. This CC Part 3 catalogues the - set of assurance components, families and classes. This CC Part - 3 also defines evaluation criteria for PPs and STs and presents - evaluation assurance levels that define the predefined CC scale - for rating assurance for TOEs, which is called the Evaluation - Assurance Levels (EALs). - - The audience for this CC Part 3 includes consumers, developers, - and evaluators of secure IT products. CC Part 1 Clause provides additional information - on the target audience of the CC, and on the use of the CC by - the groups that comprise the target audience. These groups may - use this part of the CC as follows: - - - Consumers, who use this CC Part 3 when selecting components - to express assurance requirements to satisfy the security - objectives expressed in a PP or ST, determining required - levels of security assurance of the TOE. - - - Developers, who respond to actual or perceived consumer - security requirements in constructing a TOE, reference this - CC Part 3 when interpreting statements of assurance - requirements and determining assurance approaches of TOEs. - - - Evaluators, who use the assurance requirements defined in - this part of the CC as mandatory statement of evaluation - criteria when determining the assurance of TOEs and when - evaluating PPs and STs. - - - - - - - Clause describes the paradigm - used in the security assurance requirements of CC Part - 3. - - Clause describes the - presentation structure of the assurance classes, families, - components, evaluation assurance levels along with their - relationships, and the structure of the composed assurance - packages. It also characterises the assurance classes and - families found in Clauses through - . - - Clause provides detailed - definitions of the EALs. - - Clause provides detailed - definitions of the CAPs. - - Clauses through provide the detailed definitions of the CC Part 3 - assurance classes. - - provides further - explanations and examples of the concepts behind the - Development class. - - provides an explanation of - the concepts behind composed TOE evaluations and the - Composition class. - - provides - a summary of the dependencies between the assurance - components. - - provides a cross - reference between PPs and the families and components of the - class. - - provides a cross reference - between the EALs and the assurance components. - - provides a cross reference - between the CAPs and the assurance components. - - - - - The following referenced documents are indispensable for the - application of this document. For dated references, only the - edition cited applies. For undated references, the latest - edition of the referenced document (including any amendments) - applies. - - CC-1 - - Common Criteria for Information Technology Security - Evaluation, Version _CCVERSION_, revision _CCREVISION_, - _CCDATE_. Part 1: Introduction and general model. - - - - CC-2 - - Common Criteria for Information Technology Security - Evaluation, Version _CCVERSION_, revision _CCREVISION_, - _CCDATE_. Part 2: Functional security components. - - - - - - This CC Part 3 defines the assurance requirements of the CC. It - includes the evaluation assurance levels (EALs) that define a - scale for measuring assurance for component TOEs, the composed - assurance packages (CAPs) that define a scale for measuring - assurance for composed TOEs, the individual assurance components - from which the assurance levels and packages are composed, and - the criteria for evaluation of PPs and STs. - - - - The goal of this annex is to explain the concepts behind - composition evaluations and the - criteria. This annex does not define the criteria; this definition can be found in clause - . - - - The IT market is, on the whole, made up of vendors offering a - particular type of product/technology. Although there is some - overlap, where a PC hardware vendor may also offer application - software and/or operating systems or a chip manufacturer may - also develop a dedicated operating system for their own - chipset, it is often the case that an IT solution is - implemented by a variety of vendors. - - There is sometimes a need for assurance in the combination - (composition) of components in addition to the assurance of - the individual components. Although there is cooperation - between these vendors, in the dissemination of certain - material required for the technical integration of the - components, the agreements rarely stretch to the extent of - providing detailed design information and development - process/procedure evidence. This lack of information from the - developer of a component on which another component relies - means that the dependent component developer does not have - access to the type of information necessary to perform an - evaluation of both the dependent and base components at EAL2 - or above. Therefore, while an evaluation of the dependent - component can still be performed at any assurance level, to - compose components with assurance at EAL2 or above it is - necessary to reuse the evaluation evidence and results of - evaluations performed for the component developer. - - It is intended that the criteria - are applicable in the situation where one IT entity is - dependent on another for the provision of security - services. The entity providing the services is termed the - ``base component'', and that receiving the services is termed - the ``dependent component''. This relationship may exist in a - number of contexts. For example, an application (dependent - component) may use services provided by an operating system - (base component). Alternatively, the relationship may be - peer-to-peer, in the sense of two linked applications, either - running in a common operating system environment, or on - separate hardware platforms. If there is a dominant peer - providing the services to the minor peer, the dominant peer is - considered to be the base component and the minor peer the - dependent component. If the peers provide services to each - other in a mutual manner, each peer will be considered to be - the base component for the services offered and dependent - component for the services required. This will require - iterations of the components - applying all requirements to each type of component - peer. - - The criteria are also intended to be more broadly applicable, - stepwise (where a composed TOE comprised of a dependent - component and a base component itself becomes the base - component of another composed TOE), in more complex - relationships, but this may require further - interpretation. - - It is still required for composed TOE evaluations that the - individual components are evaluated independently, as the - composition evaluation builds on the results of the individual - component evaluations. The evaluation of the dependent - component may still be in progress when the composed TOE - evaluation commences. However, the dependent component - evaluation must complete before the composed TOE evaluation - completes. - - The composed evaluation activities may take place at the same - time as the dependent component evaluation. This is due to two - factors: - - - Economic/business drivers - the dependent component - developer will either be sponsoring the composition - evaluation activities or supporting these activities as - the evaluation deliverables from the dependent component - evaluation are required for composed evaluation - activities. - - Technical drivers - the components consider whether the - requisite assurance is provided by the base component - (e.g. considering the changes to the base component since - completion of the component evaluation) with the - understanding that the dependent component has recently - undergone (is undergoing) component evaluation and all - evaluation deliverables associated with the evaluation are - available. Therefore, there are no activities during - composition requesting the dependent component evaluation - activities to be re-verified. Also, it is verified that - the base component forms (one of) the test configurations - for the testing of the dependent component during the - dependent component evaluation, leaving to consider the base component in this - configuration. - - The evaluation evidence from the evaluation of the dependent - component is required input into the composed TOE evaluation - activities. The only evaluation material from the evaluation - of the base component that is required as input into the - composed TOE evaluation activities: - - - Residual vulnerabilities in the base component, as - reported during the base component evaluation. This is - required for the - activities. - - No other evaluation evidence from the base component - activities should be required for the composed TOE evaluation, - as the evaluation results from the component evaluation of the - base component should be reused. Additional information about - the base component may be required if the composed TOE TSF - includes more of the base component than was considered to be - TSF during component evaluation of the base component. - - The component evaluation of the base and dependent components - are assumed to be complete by the time final verdicts are - assigned for the components. - - The components only consider - resistance against an attacker with an attack potential up to - Enhanced-Basic. This is due to the level of design information - that can be provided of how the base component provides the - services on which the dependent component relies through - application of the - activities. Therefore, the confidence arising from composed TOE - evaluations using CAPs is limited to a level similar to that - obtained from EAL4 component TOE evaluations. Although - assurance in the components that comprise the composed TOE may - be higher than EAL4. - - - - An ST will be submitted by the developer for the evaluation of - the composed (base component + dependent component) TOE. This - ST will identify the assurance package to be applied to the - composed TOE, providing assurance in the composed entity by - drawing upon the assurance gained in the component - evaluations. - - The purpose of considering the composition of components - within an ST is to validate the compatibility of the - components from the point of view of both the environment and - the requirements, and also to assess that the composed TOE ST - is consistent with the component STs and the security policies - expressed within them. This includes determining that the - component STs and the security policies expressed within them - are compatible. - - The composed TOE ST may refer out to the content of the - component STs, or the ST author may chose to reiterate the - material of the component STs within the composed TOE ST - providing a rationale of how the component STs are represented - in the composed TOE ST. - - During the conduct of the - evaluation activities for a composed TOE ST the evaluator - determines that the component STs are accurately represented - in the composed TOE ST. This is achieved through determining - that the composed TOE ST demonstrably conforms to the - component TOE STs. Also, the evaluator will need to determine - that the dependencies of the dependent component on the - operational environment are adequately fulfilled in the - composed TOE. - - The composed TOE description will describe the composed - solution. The logical and physical scope and boundary of the - composed solution will be described, and the logical - boundary(ies) between the components will also be - identified. The description will identify the security - functionality to be provided by each component. - - The statement of SFRs for the composed TOE will identify which - component is to satisfy an SFR. If an SFR is met by both - components, then the statement will identify which component - meets the different aspects of the SFR. Similarly the composed - TOE Summary Specification will identify which component - provides the security functionality described. - - The package of requirements - applied to the composed TOE ST should be consistent with the - package of requirements used in - the component evaluations. - - Reuse of evaluation results from the evaluation of component - STs can be made in the instances that the composed TOE ST - directly refers to the component STs. e.g. if the composed TOE - ST refers to a component ST for part of its statement of SFRs, - the evaluator can understand that the requirement for the - completion of all assignment and selection operations (as - stated in .*.3C has been - satisfied in the component evaluations. - - - - The TSF of the base component is often defined without - knowledge of the dependencies of the possible applications - with which it may by composed. The TSF of this base component - is defined to include all parts of the base component that - have to be relied upon for enforcement of the base component - SFRs. This will include all parts of the base component - required to implement the base component SFRs. - - The TSFI of this base component represents the interfaces - provided by the TSF to the external entities defined in the - statement of SFRs to invoke a service of the TSF. This - includes interfaces to the human user and also interfaces to - external IT entities. However, the TSFI only includes those - interfaces to the TSF, and therefore is not necessarily an - exhaustive interface specification of all possible interfaces - available between an external entity and the base - component. The base component may present interfaces to - services that were not considered security-relevant, either - because of the inherent purpose of the service (e.g., adjust - type font) or because associated CC SFRs are not being claimed - in the base component's ST (e.g. the login interface when no - SFRs are claimed). - - The functional interfaces provided by the base component are - in addition to the security interfaces (TSFIs), and are not - required to be considered during the base component - evaluation. These often include interfaces that are used by a - dependent component to invoke a service provided by the base - component. - - The base component may include some indirect interfaces - through which TSFIs may be called, e.g. APIs that can be used - to invoke a service of the TSF, which were not considered - during the evaluation of the base component. -
- - The dependent component, which relies on the base component, - is similarly defined: interfaces to external entities defined - in the SFRs of the component ST are categorised as TSFI and - are examined in . - - Any call out from the dependent TSF to the environment in - support of an SFR will indicate that the dependent TSF - requires some service from the environment in order to satisfy - the enforcement of the stated dependent component SFRs. Such a - service is outside the dependent component boundary and the - base component is unlikely to be defined in the dependent ST - as an external entity. Hence, the calls for services made out - by the dependent TSF to its underlying platform (the base - component) will not be analysed as part of the activities. These dependencies on - the base component are expressed in the dependent component ST - as security objectives for the environment. - - This abstraction of the dependent component and the interfaces - is shown in Figure - below. -
- - When considering the composition of the base component and the - dependent component, if the dependent component's TSF requires - services from the base component to support the implementation - of the SFR, the interface to the service will need to be - defined. If that service is provided by the base component's - TSF, then that interface should be a TSFI of the base - component and will therefore already be defined within the - functional specification of the base component. - - If, however, the service called by the dependent component's - TSF is not provided by the TSF of the base component (i.e., it - is implemented in the non-TSF portion of the base component or - possibly even in the non-TOE portion of the base component - (not illustrated in Figure ), there is unlikely to be a TSFI of the base - component relating to the service, unless the service is - mediated by the TSF of the base component. The interfaces to - these services from the dependent component to the operational - environment are considered in the family . - - The non-TSF portion of the base component is drawn into the - TSF of the composed TOE due to the dependencies the dependent - component has on the base component to support the SFRs of the - dependent component. Therefore, in such cases, the TSF of the - composed TOE would be larger than simply the sum of the - components' TSFs. -
- - It may be the case that the base component TSFI is being - called in a manner that was unforeseen in the base component - evaluation. Hence there would be a requirement for further - testing of the base component TSFI. - - The possible interfaces are further described in the following - diagram (Figure ) and - supporting text. -
- - - - Arrows going into 'dependent component-a' - (A and B) = where the component expects the environment to - respond to a service request (responding to calls out from - dependent component to the environment); - - Arrows coming out of 'base component-b' - (C and D) = interfaces of services provided by the base - component to the environment; - - Broken lines between components = types of communication - between pairs of interfaces; - - The other (grey) arrows = interfaces that are described by - the given criteria. - - The following is a simplification, but explains the - considerations that need to be made. - - There are components a ('dependent component-a') and b ('base - component-b'): the arrows coming out of TSF-a - are services provided by TSF-a and are therefore TSFIs(a); - likewise, the arrows coming out of TSF-b - (``C'') are TSFIs(b). These are each detailed in their - respective functional specs. component-a is such that it - requires services from its environment: those needed by the - TSF(a) are labelled ``A''; the other (not related to TSF-a) - services are labelled ``B''. - - When component-a and component-b are combined, there are four - possible combinations of {services needed by component-a} and - {services provided by component-b}, shown as broken lines - (types of communication between pairs of interfaces). Any set - of these might exist for a particular composition: - - - TSF-a needs those services that are provided by TSF-b ("A" is connected to "C"): - this is straightforward: the details about "C" are in the FSP for component-b. - In this instance the interfaces should all be defined in the functional specifications for - the component-b. - - - Non-TSF-a needs those services that are provided by TSF-b - (``B'' is connected to ``C''): this is straightforward - (again, the details about ``C'' are in the FSP for - component-b), but unimportant: security-wise. - - Non-TSF-a needs those services that are provided by - non-TSF-b (``B'' is connected to ``D''): we have no - details about D, but there are no security implications - about the use of these interfaces, so they do not need to - be considered in the evaluation, although they are likely - to be an integration issue for the developer. - - TSF-a needs those services that are provided by non-TSF-b - (``A'' is connected to ``D''): this would arise when - component-a and component-b have different senses of what - a ``security service'' is. Perhaps component-b is making - no claims about I&A (has no - SFRs in its ST), but component-a needs authentication - provided by its environment. There are no details about - the ``D'' interfaces available (they are not TSFI (b), so - they are not in component-b's FSP). - - Note: if the kind of interaction described in case d above - exists, then the TSF of the composed TOE would be TSF-a + TSF-b - + Non-TSF-b. Otherwise, the TSF of the composed TOE would be - TSF-a + TSF-b. - - Interfaces types 2 and 4 of Figure are not directly relevant to the evaluation of - the composed TOE. Interfaces 1 and 3 will be considered during - the application of different families: - - - (for component-b) will - describe the C interfaces. - - will describe the A - interfaces. - - will describe the C - interfaces for connection type 1 and the D interfaces for - connection type 3. - - A typical example where composition may be applied is a - database management system (DBMS) that relies upon its - underlying operating system (OS). During the evaluation of - the DBMS component, there will be an assessment made of the - security properties of that DBMS (to whatever degree of rigour - is dictated by the assurance components used in the - evaluation): its TSF boundary will be identified, its - functional specification will be assessed to determine whether - it describes the interfaces to the security services provided - by the TSF, perhaps additional information about the TSF (its - design, architecture, internal structure) will be provided, - the TSF will be tested, aspects of its life-cycle and its - guidance documentation will be assessed, etc. - - However, the DBMS evaluation will not call for any evidence - concerning the dependency the DBMS has on the OS. The ST of - the DBMS will most likely state assumptions about the OS in - its Assumptions subclause and state security objectives for the - OS in its Environment subclause. The DBMS ST may even - instantiate those objectives for the environment in terms of - SFRs for the OS. However, there will be no specification for - the OS that mirrors the detail in the functional - specification, architecture description, or other evidence as for the DBMS. will fulfil that need. - - describes the interfaces of - the dependent TOE that make the calls to the base component - for the provision of services. These are the interfaces to - which the base component is to respond. The interface - descriptions are provided from the dependent component's - viewpoint. - - describes the interfaces - provided by the base component, which respond to the dependent - component service requests. These interfaces are mapped to the - relevant dependent component interfaces that are identified in - the reliance information. (The completeness of this mapping, - whether the base component interfaces described represent all - dependent component interfaces, is not verified here, but in - ). At the higher levels of - the subsystems providing the - interfaces are described. - - Any interfaces required by the dependent component that have - not been described for the base component are reported in the - rationale for . The rationale - also reports whether the interfaces of the base component on - which the dependent component relies were considered within - the base component evaluation. For any interfaces that were - not considered in the base component evaluation, a rationale - is provided of the impact of using the interface on the base - component TSF. - - - - - This annex contains ancillary material to further explain and - provide additional examples for the topics brought up in - families of the class. - - - A security architecture is a set of properties that the TSF - exhibits; these properties include self-protection, domain - separation, and non-bypassability. Having these properties - provides a basis of confidence that the TSF is providing its - security services. This annex provides additional material on - these properties, as well as discussion on contents of a - security architecture description. - - The remainder of this subclause first explains these properties, - then discusses the kinds of information that are needed to - describe how the TSF exhibits those properties. - - Self-protection refers to the ability of - the TSF to protect itself from manipulation from external - entities that may result in changes to the TSF. Without these - properties, the TSF might be disabled from performing its - security services. - - It is oftentimes the case that a TOE uses services or - resources supplied by other IT entities in order to perform - its functions (e.g. an application that relies upon its - underlying operating system). In these cases, the TSF does - not protect itself entirely on its own, because it depends - on the other IT entities to protect the services it - uses. - Domain separation is a property whereby the TSF - creates separate security domains for each - untrusted active entity to operate on its resources, and then - keeps those domains separated from one another so that no entity - can run in the domain of any other. For example, an operating - system TOE supplies a domain (address space, per-process - environment variables) for each process associated with - untrusted entities. - - For some TOEs such domains do not exist because all of the - actions of the untrusted entities are brokered by the TSF. A - packet-filter firewall is an example of such a TOE, where - there are no untrusted entity domains; there are only data - structures maintained by the TSF. The existence of domains, - then, is dependant upon 1) the type of TOE and 2) the SFRs - levied on the TOE. In the cases where the TOE does provide - domains for untrusted entities, this family requires that - those domains are isolated from one another such that - untrusted entities in one domain are prevented from - tampering (affecting without brokering by the TSF) from - another untrusted entity's domain. - - Non-bypassability is a property that the - security functionality of the TSF (as specified by the SFRs) - is always invoked and cannot be circumvented when - appropriate for that specific mechanism. For example, if - access control to files is specified as a capability of the - TSF via an SFR, there must be no interfaces through which - files can be accessed without invoking the TSF's access - control mechanism (an interface through which a raw disk - access takes place might be an example of such an - interface). - - As is the case with self-protection, the very nature of some - TOEs might depend upon their environments to play a role in - non-bypassability of the TSF. For example, a security - application TOE requires that it be invoked by the - underlying operating system. Similarly, a firewall depends - upon the fact that there are no direct connections between - the internal and external networks and that all traffic - between them must go through the firewall. - - - The security architecture description explains how the - properties described above are exhibited by the TSF. It - describes how domains are defined and how the TSF keeps them - separate. It describes what prevents untrusted processes - from getting to the TSF and modifying it. It describes what - ensures that all resources under the TSF's control are - adequately protected and that all actions related to the - SFRs are mediated by the TSF. It explains any role the - environment plays in any of these (e.g. presuming it gets - correctly invoked by its underlying environment, how are its - security functions invoked?). - - The security architecture description presents the TSF's - properties of self-protection, domain separation, and - non-bypassability in terms of the decomposition descriptions. - The level of this description is commensurate with the TSF - description required by the , - and requirements that are being claimed. For example, if - is the only TSF description - available, it would be difficult to provide any meaningful - security architecture description because none of the details of - any internal workings of the TSF would be available. - - However, if the TOE design were also available, even at the most - basic level (), there would be - some information available concerning the subsystems that make - up the TSF, and there would be a description of how they work to - implement self-protection, domain separation, and - non-bypassability. For example, perhaps all user interaction - with the TOE is constrained through a process that acts on that - user's behalf, adopting all of the user's security attributes; - the security architecture description would describe how such a - process comes into being, how the process's behaviour is - constrained by the TSF (so it cannot corrupt the TSF), how all - actions of that process are mediated by the TSF (thereby - explaining why the TSF cannot be bypassed), etc. - - If the available TOE design is more detailed (e.g. at the - modular level), or the implementation representation is also - available, then the security architecture description would be - correspondingly more detailed, explaining how the user's process - communicate with the TSF processes, how different requests are - processed by the TSF, what parameters are passed, what - programmatic protections (buffer overflow prevention, parameter - bounds checking, time of check/time of use checking, etc.) are - in place. Similarly, a TOE whose ST claimed the component would go into - implementation-specific detail. - - The explanations provided in the security architecture - description are expected to be of sufficient detail that one - would be able to test their accuracy. That is, simple - assertions (e.g. "The TSF keeps domains separate'') provide - no useful information to convince the reader that the TSF - does indeed create and separate domains. - - In cases where the TOE exhibits domain separation entirely on - its own, there would be a straightforward description of how - this is attained. The security architecture description would - explain the different kinds of domains that are defined by the - TSF, how they are defined (i.e. what resources are allocated - to each domain), how no resources are left unprotected, and - how the domains are kept separated so that active entities in - one domain cannot tamper with resources in another - domain. - For cases where the TOE depends upon other IT entities to play - a role in domain separation, that sharing of roles must be made - clear. For example, a TOE that is solely application software - relies upon the underlying operating system to correctly - instantiate the domains that the TOE defines; if the TOE - defines separate processing space, memory space, etc, for each - domain, it depends upon the underlying operating system to - operate correctly and benignly (e.g. allow the process to - execute only in the execution space that is requested by the - TOE software). - For example, mechanisms that implement domain separation - (e.g., memory management, protected processing modes provided - by the hardware, etc.) would be identified and described. Or, - the TSF might implement software protection constructs or - coding conventions that contribute to implementing separation - of software domains, perhaps by delineating user address space - from system address space. - The vulnerability analysis and testing (see ) activities will likely include attempts to defeat - the described TSF domain separation through the use of - monitoring or direct attack the TSF. - - - In cases where the TOE exhibits self-protection entirely - on its own, there would be a straightforward description - of how this self-protection is attained. Mechanisms that - provide domain separation to define a TSF domain that is - protected from other (user) domains would be identified - and described. - - For cases where the TOE depends upon other IT entities to - play a role in protecting itself, that sharing of roles - must be made clear. For example, a TOE that is solely - application software relies upon the underlying operating - system to operate correctly and benignly; the application - cannot protect itself against a malicious operating system - that subverts it (for example, by overwriting its - executable code or TSF data). - - The security architecture description also covers how user input - is handled by the TSF in such a way that the TSF does not - subject itself to being corrupted by that user input. For - example, the TSF might implement the notion of privilege and - protect itself by using privileged-mode routines to handle user - data. The TSF might make use of processor-based separation - mechanisms (e.g. privilege levels or rings) to separate TSF - code and data from user code and data. The TSF might implement - software protection constructs or coding conventions that - contribute to implementing separation of software, perhaps by - delineating user address space from system address space. - - For TOEs that start up in a low-function mode (for - example, a single-user mode accessible only to installers - or administrators) and then transition to the evaluated - secure configuration (a mode whereby untrusted users are - able to login and use the services and resources of the - TOE), the security architecture description also includes - an explanation of how the TSF is protected against this - initialisation code that does not run in the evaluated - configuration. For such TOEs, the security architecture - description would explain what prevents those services - that should be available only during initialisation - (e.g. direct access to resources) from being accessible in - the evaluated configuration. It would also explain what - prevents initialisation code from running while the TOE is - in the evaluated configuration. - - There must also be an explanation of how the trusted - initialisation code will maintain the integrity of the TSF - (and of its initialisation process) such that the - initialisation process is able to detect any modification - that would result in the TSF being spoofed into believe it - was in an initial secure state. - - The vulnerability analysis and testing (see ) activities will likely include - attempts to defeat the described TSF self protection - through the use of tampering, direct attack, or monitoring - of the TSF. - - - The property of non-bypassability is concerned with - interfaces that permit the bypass of the enforcement - mechanisms. In most cases this is a consequence of the - implementation, where if a programmer is writing an - interface that accesses or manipulates an object, it is - that programmer's responsibility to use interfaces that - are part of the SFR enforcement mechanism for the object - and not to try to circumvent those interfaces. For the - description pertaining to non-bypassability, then, there - are two broad areas that have to be covered. - - The first consists of those interfaces to the SFR-enforcement. - The property for these interfaces is that they contain no - operations or modes that allow them to be used to bypass the - TSF. It is likely that the evidence for and can be used in - large part to make this determination. Because non-bypassability - is the concern, if only certain operations available through - these TSFIs are documented (because they are SFR-enforcing) and - others are not, the developer should consider whether additional - information (to that presented in - and ) is necessary to make a - determination that the - SFR-supporting and SFR-non-interfering - operations of the TSFI do not afford an - untrusted entity the ability to bypass the policy being - enforced. If such information is necessary, it is included - in the security architecture description. - - The second area of non-bypassability is concerned with - those interfaces whose interactions are not associated - with SFR-enforcement. Depending on the and components - claimed, some information about these interfaces may or - may not exist in the functional specification and TOE - design documentation. The information presented for such - interfaces (or groups of interfaces) should be sufficient - so that a reader can make a determination (at the level of - detail commensurate with the rest of the evidence supplied - in the class) that the - enforcement mechanisms cannot be bypassed. - - The property that the security functionality cannot be - bypassed applies to all security functionality - equally. That is, the design description should cover - objects that are protected under the SFRs (e.g. _* components) and functionality - (e.g., audit) that is provided by the TSF. The description - should also identify the interfaces that are associated - with security functionality; this might make use of the - information in the functional specification. This - description should also describe any design constructs, - such as object managers, and their method of use. For - instance, if routines are to use a standard macro to - produce an audit record, this convention is a part of the - design that contributes to the non-bypassability of the - audit mechanism. It is important to note that - non-bypassability in this context is not an - attempt to answer the question ``could a part of the TSF - implementation, if malicious, bypass the security - functionality'', but rather to document how the - implementation does not bypass the security - functionality. - - The vulnerability analysis and testing (see ) activities will likely include - attempts to defeat the described non-bypassability by - circumventing the TSF. - - - - - The purpose in specifying the TSFIs is to provide the - necessary information to conduct testing; without knowing the - possible means interact with the TSF, one cannot adequately - test the behaviour of the TSF. - - There are two parts to specifying the TSFIs: identifying them - and describing them. Because of the diversity of possible - TOEs, and of different TSFs therein, there is no standard set - of interfaces that constitute ``TSFIs''. This annex provides - guidance on the factors that determine which interfaces are - TSFIs. - - - In order to identify the interfaces to the TSF, the parts of the - TOE that make up the TSF must first be identified. This - identification is actually a part of the analysis, but is also performed implicitly - (through identification and description of the TSFI) by the - developer in cases where is not - included in the assurance package. In this analysis, a portion - of the TOE must be considered to be in the TSF if it contributes - to the satisfaction of an SFR in the ST (in whole or in - part). This includes, for example, everything in the TOE that - contributes to TSF run-time initialisation, such as software - that runs prior to the TSF being able to protect itself because - enforcement of the SFRs has not yet begun (e.g., while booting - up). Also included in the TSF are all parts of the TOE that - contribute to the architectural principles of TSF - self-protection, domain separation, and non-bypassability (see - ). - - Once the TSF has been defined, the TSFI are identified. - The TSFI consists of all means by which external entities (or - subjects in the TOE but outside of the TSF) supply data to the TSF, - receive data from the TSF and invoke services from the TSF. - These service invocations and responses are the means of crossing - the TSF boundary. While many of these are readily apparent, others - might not be as obvious. The question that should be asked when - determining the TSFIs is: ``How can a potential attacker interact - with the TSF in an attempt to subvert the SFRs?'' The following - discussions illustrate the application of the TSFI definition in - different contexts. - - - In TOEs such as smart cards, where the adversary has not - only logical access to the TOE, but also complete physical - access to the TOE, the TSF boundary is the physical - boundary. Therefore, the exposed electrical interfaces - are considered TSFI because their manipulation could - affect the behaviour of the TSF. As such, all these - interfaces (electrical contacts) need to be described: - various voltages that might be applied, etc. - - - - The TSFIs of a TOE that performs protocol processing would - be those protocol layers to which a potential attacker has - direct access. This need not be the entire protocol stack, - but it might be. - - For example, if the TOE were some sort of a network - appliance that allowed potential attackers to affect every - level of the protocol stack (i.e. to send arbitrary - signals, arbitrary voltages, arbitrary packets, arbitrary - datagrams, etc.), then the TSF boundary exists at each - layer of the stack. Therefore, the functional - specification would have to address every protocol at - every layer of the stack. - - If, however, the TOE were a firewall that protects an - internal network from the Internet, a potential attacker - would have no means of directly manipulating the voltages - that enter the TOE; any extreme voltages would simply not - be passed though the Internet. That is, the attacker would - have access only to those protocols at the Internet layer - or above. The TSF boundary exists at each layer of the - stack. Therefore, the functional specification would have - to address only those protocols at or above the Internet - layer: it would describe each of the different - communication layers at which the firewall is exposed in - terms of what constitutes well-formed input for what might - appear on the line, and the result of both well-formed and - malformed inputs. For example, the description of the - Internet protocol layer would describe what constitutes a - well-formed IP packet and what happens when both - correctly-formed and malformed packets are - received. Likewise, the description of the TCP layer would - describe a successful TCP connection and what happens both - when successful connections are established and when - connections cannot be established or are inadvertently - dropped. Presuming the firewall's purpose is to filter - application-level commands (like FTP or telnet), the - description of the application layer would describe the - application-level commands that are recognised and - filtered by the firewall, as well as the results of - encountering unknown commands. - - The descriptions of these layers would likely reference - published communication standards (telnet, FTP, TCP, etc.) - that are used, noting which user-defined options are - chosen. - - - -
- - - ``Wrappers'' translate complex series of interactions into - simplified common services, such as when Operating Systems - create APIs for use by applications (as shown in Figure - ). Whether the TSFIs - would be the system calls or the APIs depends upon what is - available to the application: if the application can use - the system calls directly, then the system calls are the - TSFIs. If, however, there were something that prohibits - their direct use and requires all communication through - the APIs, then the APIs would be the TSFIs. - - A Graphical User interface is similar: it translates - between machine-understandable commands and user-friendly - graphics. Similarly, the TSFIs would be the commands if - users have access to them, or the graphics (pull-down - menus, check-boxes, text fields) if the users are - constrained to using them. - - It is worth noting that, in both of these examples, if the - user is prohibited from using the more primitive - interfaces (i.e. the system calls or the commands), the - description of this restriction and of its enforcement - would be included in the Security Architecture Description - (see ). Also, the wrapper would be - part of the TSF. - - - - For a given TOE, not all of the interfaces may be - accessible. That is, the security - objectives for the operational environment (in the - Security Target) may prevent access to these interfaces or - limit access in such a way that they are practically - inaccessible. Such interfaces would not be considered - TSFIs. Some examples: - - If the security objectives for the operational - environment for the stand-alone firewall state that - ``the firewall will be operational in a server room - environment to which only trusted and trained - personnel will have access, and which will be equipped - with an interruptible power supply (against power - failure)'', physical and power interfaces will not be - accessible, since trusted and trained personnel will - not attempt to dismantle the firewall and/or disable - its power supply. If the security - objectives for the operational environment for the - software firewall (application) state that ``the OS - and the hardware will provide a security domain for - the application free from tampering by other - programs'', the interfaces through which the firewall - can be accessed by other applications on the OS - (e.g. deleting or modifying the firewall executable, - direct reading or writing to the memory space of the - firewall) will not be accessible, since the - OS/hardware part of the operational environment makes - this interface inaccessible. If the - security objectives for the operational environment - for the software firewall additionally state that the - OS and hardware will faithfully execute the commands - of the TOE, and will not tamper with the TOE in any - manner, interfaces through which the firewall obtains - primitive functionality from the OS and hardware - (executing machine code instructions, OS APIs, such as - creating, reading, writing or deleting files, - graphical APIs etc.) will not be accessible, since the - OS/hardware are the only entities that can access that - interface, and they are completely - trusted. For all of these examples, - these inaccessible interfaces would not be - TSFIs. - - - - Figure - illustrates a complex TOE: a database management system that - relies on hardware and software that is outside the TOE - boundary (referred to as the IT environment - in the rest of this discussion). To simplify this example, - the TOE is identical to the TSF. The - shaded boxes represent the TSF, while the unshaded boxes - represent IT entities in the environment. The TSF comprises - the database engine and management GUIs (represented by the - box labelled DB) and a kernel module that - runs as part of the OS that performs some security function - (represented by the box labelled PLG). The - TSF kernel module has entry points defined by the OS - specification that the OS will call to invoke some function - (this could be a device driver, or an authentication module, - etc.). The key is that this pluggable kernel module is - providing security services specified by functional - requirements in the ST. - -
- - - The IT environment consists of the operating system itself - (represented by the box labelled OS), as - well as an external server (labelled SRV). - This external server, like the OS, provides a service that - the TSF depends on, and thus needs to be in the IT - environment. Interfaces in the figure are labelled - Ax for TSFI, and Bx for - other interfaces that would be documented in . Each of these groups of interfaces is now - discussed. - - Interface group A1 represents the most obvious set of TSFI. - These are interfaces used by users to directly access the - database and its security functionality and - resources. - - Interface group A2 represent the TSFI that the OS invokes to - obtain the functionality provided by the pluggable module. - These are contrasted with interface group B3, which - represent calls that the pluggable module makes to obtain - services from the IT environment. - - Interface group A3 represent TSFI that pass through the IT - environment. In this case, the DBMS communicates over the - network using a proprietary application-level - protocol. While the IT environment is responsible for - providing various supporting protocols (e.g., Ethernet, IP, - TCP), the application layer protocol that is used to obtain - services from the DBMS is a TSFI and must be documented as - such. The dotted line indicates return values/services from - the TSF over the network connection. - - The interfaces labelled Bx represent - interfaces to functionality in the IT Environment. These - interfaces are not TSFI and need only be discussed and - analysed when the TOE is being used in a composite - evaluation as part of the activities associated with the - class. - - - - The Example firewall is used between an internal network and - an external network. It verifies the source address of data - received (to ensure that external data is not attempting to - masquerade as originating from the internal data); if it - detects any such attempts, it saves the offending attempt to - the audit log. The administrator connects to the firewall by - establishing a telnet connection to the firewall from the - internal network. Administrator actions consist of - authenticating, changing passwords, reviewing the audit log, - and setting or changing the addresses of the internal and - external networks. - - The Example firewall presents the following interfaces to - the internal network: - - IP datagrams - Administrator Commands and the - following interfaces to the external network: - - IP datagrams - Interfaces Descriptions: IP - Datagrams - The datagrams are in the format specified by RFC 791. - - Purpose - to transmit blocks of data (``datagrams'') - from source hosts to destination hosts identified by - fixed length addresses; also provides for fragmentation - and reassembly of long datagrams, if necessary, for - transmission through small-packet networks. - Method of Use - they arrive from the lower-level - (e.g. data link) protocol. - Parameters - the following fields of the IP datagram - header: source address, destination address, - don't-fragment flag. - Parameter description - [As defined by RFC 791, - subclause 3.1 (``Internet Header Format'')] - Actions - Transmits datagrams that are not - masquerading; fragments large datagrams if necessary; - reassembles fragments into datagrams. - Error messages - (none). No reliability guaranteed - (reliability to be provided by upper-level protocols) - Undeliverable datagrams (e.g. must be fragmented for - transmission, but don't-fragment flag is set) - dropped. - Interfaces Descriptions: Administrator - Commands - The administrator commands provide a means for the - administrator to interact with the firewall. These commands - and responses ride atop a telnet (RFC 854) connection - established from any host on the internal network. Available - commands are: - - Passwd - - Purpose - sets administrator password - Method of Use - Passwd - <password> - Parameters - password - Parameter description - value of new - password - Actions - changes password to new value - supplied. There are no restrictions. - Error messages - none. - - Readaudit - - Purpose - presents the audit log to the - administrator - Method of Use - Readaudit - Parameters - none - Parameter description - none - Actions - provides the text of the audit - log - Error messages - none. - - Setintaddr - - Purpose - sets the address of the internal - address. - Method of Use - Setintaddr - <address> - Parameters - address - Parameter description - first three fields of an - IP address (as defined in RFC 791). For example: - 123.123.123. - Actions - changes the internal value of the - variable defining the internal network, the value of - which is used to judge attempted masquerades. - Error messages - ``address in use'': indicates - the identified internal network is the same as the - external network. - - Setextaddr - - Purpose - sets the address of the external address - Method of Use - Setextaddr - <address> - Parameters - address - Parameter description - first three fields of an - IP address (as defined in RFC 791). For example: - 123.123.123. - Actions - changes the internal value of the - variable defining the external network. - Error messages - ``address in use'': indicates - the identified external network is the same as the - internal network. - - - - - - - The wide variety of TOEs makes it impossible to codify - anything more specific than ``well-structured'' or ``minimum - complexity''. Judgements on structure and complexity are - expected to be derived from the specific technologies used in - the TOE. For example, software is likely to be considered - well-structured if it exhibits the characteristics cited in - the software engineering disciplines. - - This annex provides supplementary material on assessing the - structure and complexity of procedure-based software portions - of the TSF. This material is based on information readily - available in software engineering literature. For other kinds - of internals (e.g. hardware, non-procedural software such as - object-oriented code, etc.), corresponding literature on good - practises should be consulted. - - - The structure of procedural software is traditionally - assessed according to its - modularity. Software written with a modular - design aids in achieving understandability by clarifying - what dependencies a module has on other modules - (coupling) and by including in a module - only tasks that are strongly related to each other - (cohesion). The use of modular design - reduces the interdependence between elements of the TSF and - thus reduces the risk that a change or error in one module - will have effects throughout the TOE. Its use enhances - clarity of design and provides for increased assurance that - unexpected effects do not occur. Additional desirable - properties of modular decomposition are a reduction in the - amount of redundant or unneeded code. - - Minimising the amount of functionality in the TSF allows the - evaluator as well as the developer to focus only on that - functionality which is necessary for SFR enforcement, - contributing further to understandability and further - lowering the likelihood of design or implementation - errors. - - The incorporation of modular decomposition, layering and - minimisation into the design and implementation process must - be accompanied by sound software engineering - considerations. A practical, useful software system will - usually entail some undesirable coupling among modules, some - modules that include loosely-related functions, and some - subtlety or complexity in a module's design. These - deviations from the ideals of modular decomposition are - often deemed necessary to achieve some goal or constraint, - be it related to performance, compatibility, future planned - functionality, or some other factors, and may be acceptable, - based on the developer's justification for them. In applying - the requirements of this class, due consideration must be - given to sound software engineering principles; however, the - overall objective of achieving understandability must be - achieved. - - - Cohesion is the manner and degree to which the tasks - performed by a single software module are related to one - another; types of cohesion include coincidental, - communicational, functional, logical, sequential, and - temporal. These types of cohesion are characterised below, - listed in the order of decreasing desirability. - - functional cohesion - a module - with functional cohesion performs activities related - to a single purpose. A functionally cohesive module - transforms a single type of input into a single type - of output, such as a stack manager or a queue - manager. - sequential cohesion - a module - with sequential cohesion contains functions each of - whose output is input for the following function in - the module. An example of a sequentially cohesive - module is one that contains the functions to write - audit records and to maintain a running count of the - accumulated number of audit violations of a specified - type. - communicational cohesion - a - module with communicational cohesion contains - functions that produce output for, or use output from, - other functions within the module. An example of a - communicationally cohesive module is an access check - module that includes mandatory, discretionary, and - capability checks. - temporal cohesion - a module - with temporal cohesion contains functions that need to - be executed at about the same time. Examples of - temporally cohesive modules include initialisation, - recovery, and shutdown modules. - logical (or - procedural) cohesion - a module with - logical cohesion performs similar activities on - different data structures. A module exhibits logical - cohesion if its functions perform related, but - different, operations on different inputs. - coincidental cohesion - a - module with coincidental cohesion performs unrelated, - or loosely related, activities. - - - - Coupling is the manner and degree of interdependence - between software modules; types of coupling include call, - common and content coupling. These types of coupling are - characterised below, listed in the order of decreasing - desirability: - - call: two modules are call coupled if they - communicate strictly through the use of their - documented function calls; examples of call coupling - are data, stamp, and control, which are defined below. - - data: two modules are data - coupled if they communicate strictly through the - use of call parameters that represent single data - items. - stamp: two modules are stamp - coupled if they communicate through the use of - call parameters that comprise multiple fields or - that have meaningful internal structures. - control: two modules are - control coupled if one passes information that is - intended to influence the internal logic of the - other. - - common: two modules are common - coupled if they share a common data area or a common - system resource. Global variables indicate that - modules using those global variables are common - coupled. Common coupling through global variables is - generally allowed, but only to a limited degree. For - example, variables that are placed into a global area, - but are used by only a single module, are - inappropriately placed, and should be removed. Other - factors that need to be considered in assessing the - suitability of global variables are: - - The number of modules that modify a global - variable: In general, only a single module should - be allocated the responsibility for controlling - the contents of a global variable, but there may - be situations in which a second module may share - that responsibility; in such a case, sufficient - justification must be provided. It is unacceptable - for this responsibility to be shared by more than - two modules. (In making this assessment, care - should be given to determining the module actually - responsible for the contents of the variable; for - example, if a single routine is used to modify the - variable, but that routine simply performs the - modification requested by its caller, it is the - calling module that is responsible, and there may - be more than one such module). Further, as part - of the complexity determination, if two modules - are responsible for the contents of a global - variable, there should be clear indications of how - the modifications are coordinated between - them. - The number of modules that reference a global - variable: Although there is generally no limit on - the number of modules that reference a global - variable, cases in which many modules make such a - reference should be examined for validity and - necessity. - - content: two modules are content - coupled if one can make direct reference to the - internals of the other (e.g. modifying code of, or - referencing labels internal to, the other module). - The result is that some or all of the content of one - module are effectively included in the other. Content - coupling can be thought of as using unadvertised - module interfaces; this is in contrast to call - coupling, which uses only advertised module - interfaces. - - - - - Complexity is the measure of the decision points and logical - paths of execution that code takes. Software engineering - literature cites complexity as a negative characteristic of - software because it impedes understanding of the logic and - flow of the code. Another impediment to the understanding of - code is the presence of code that is unnecessary, in that it - is unused or redundant. - - The use of layering to separate levels of abstraction and - minimise circular dependencies further enables a better - understanding of the TSF, providing more assurance that the - TOE security functional requirements are accurately and - completely instantiated in the implementation. - - Reducing complexity also includes reducing or eliminating - mutual dependencies, which pertains both to modules in a - single layer and to those in separate layers. Modules that - are mutually dependent may rely on one another to formulate - a single result, which could result in a deadlock condition, - or worse yet, a race condition (e.g., time of check vs. time - of use concern), where the ultimate conclusion could be - indeterminate and subject to the computing environment at - the given instant in time. - - Design complexity minimisation is a key characteristic of a - reference validation mechanism, the purpose of which is to - arrive at a TSF that is easily understood so that it can be - completely analysed. (There are other important - characteristics of a reference validation mechanism, such as - TSF self-protection and non-bypassability; these other - characteristics are covered by requirements in the family.) - - - - - This Subclause provides additional guidance on the TDS family, - and its use of the terms ``subsystem'' and ``module''. This is - followed by a discussion of how, as more-detailed becomes - available, the requirement for the less-detailed is - reduced. - - Figure - shows that, depending on the complexity of the TSF, the - design may be described in terms of subsystems - and modules (where subsystems are at a - higher level of abstraction than modules); or it may just be - described in terms of one level of abstraction (e.g., - subsystems at lower assurance levels, - modules at higher levels). In cases where a - lower level of abstraction (modules) is presented, - requirements levied on higher-level abstractions - (subsystems) are essentially met by default. This concept is - further elaborated in the discussion on subsystems and - modules below. -
- - The developer is expected to describe the design of the TOE - in terms of subsystems. The term - ``subsystem'' was chosen to be specifically vague so that it - could refer to units appropriate to the TOE (e.g., - subsystems, modules). subsystems can even be uneven in - scope, as long as the requirements for description of - subsystems are met. - - The first use of subsystems is to distinguish the TSF boundary; - that is, the portions of the TOE that comprise the TSF. In - general, a subsystem is part of the TSF if it has the capability - (whether by design or implementation) to affect the correct - operation of any of the SFRs. For example, for software that - depends on different hardware execution modes to provide domain - separation (see ) where - SFR-enforcing code is executed in one domain, then all - subsystems that execute in that domain would be considered part - of the TSF. Likewise, if a server outside that domain - implemented an SFR (e.g. enforced an access control policy over - objects it managed), then it too would be considered part of the - TSF. - - The second use of subsystems is to provide a structure for - describing the TSF at a level of description that, while - describing how the TSF works, does not necessarily contain - low-level implementation detail found in module descriptions - (discussed later). subsystems are described at either a high - level (lacking an abundance of implementation detail) or a - detailed level (providing more insight into the - implementation). The level of description provided for a - subsystem is determined by the degree to which that - subsystem is responsible for implementing an SFR. - - An SFR-enforcing subsystem is a subsystem - that provides mechanisms for enforcing an element of any SFR, - or directly supports a subsystem that is responsible - for enforcing an SFR. If a subsystem provides (implements) - an SFR-enforcing TSFI, then the subsystem is - SFR-enforcing. - - Subsystems can also be identified as - SFR-supporting and - SFR-non-interfering. An SFR-supporting - subsystem is one that is depended on by an SFR-enforcing - subsystem in order to implement an SFR, but does not play as - direct a role as an SFR-enforcing subsystem. An - SFR-non-interfering subsystem is one that is not depended - upon, in either a supporting or enforcing role, to implement - an SFR. - - - - A module is generally a relatively small architectural unit - that can be characterised in terms of the properties - discussed in . When both - (or above) requirements - and requirements are - present in a PP or ST, a ``module'' in terms of the requirements refers to the same - entity as a ``module'' for the requirements. Unlike subsystems, modules - describe the implementation in a level of detail that can - serve as a guide to reviewing the implementation - representation. - - It is important to note that, depending on the TOE, modules - and subsystems may refer to the same abstraction. For and (which do not require description at the - module level) the subsystem description provides the lowest - level detail available about the TSF. For (which require module - descriptions) these descriptions provide the lowest level of - detail, while the subsystem descriptions (if they exist as - separate entities) merely serve to put to the module - descriptions in context. That is, it is not necessary to - provide detailed subsystem descriptions if module - descriptions exist. In TOEs that are sufficiently simple, a - separate ``subsystem description'' is not necessary; the - requirements can be met through documentation provided by - modules. For complex TOEs, the purpose of the subsystem - description (with respect to the TSF) is to provide the - reader context so they can focus their analysis - appropriately. This difference is illustrated in Figure - . - - An SFR-enforcing module is a module that completely or partially implements - a security functional requirement (SFR) in the ST. Such modules may - implement an SFR-enforcing TSFI, but some functionality expressed in an SFR (for example, - audit and object re-use functionality) may not be directly tied to a single TSFI. As was - the case with subsystems, SFR-supporting modules are those modules that are depended upon by - an SFR-enforcing module, but are not responsible for directly implementing an SFR. - SFR-non-interfering modules are those modules that do not deal, directly or indirectly, - with the enforcement of SFRs. - - It is important to note that the determination of what - ``directly implements'' means is somewhat subjective. In the - narrowest sense of the term, it could be interpreted to mean - the one or two lines of code that actually perform a - comparison, zeroing operation, etc. that implements a - requirement. A broader interpretation might be that it - includes the module that is invoked in response to a - SFR-enforcing TSFI, and all modules that may be invoked in - turn by that module (and so on until the completion of the - call). Neither of these interpretations is particularly - satisfying, since the narrowness of the first interpretation - may lead to important modules being incorrectly categorised - as SFR supporting, while the second leads to modules that - are actually not SFR-enforcing being classified as - such. - - A description of a module should be such that one could create an implementation of the - module from the description, and the resulting implementation would be 1) identical to - the actual TSF implementation in terms of the interfaces presented, 2) identical in the - use of interfaces that are mentioned in the design, and 3) functionally equivalent to the - description of the purpose of the TSF module. For instance, RFC 793 - provides a high-level description of the TCP protocol. It is necessarily implementation - independent. While it provides a wealth of detail, it is - not - a suitable design description because it is not specific to an implementation. An actual - implementation can add to the protocol specified in the RFC, and implementation choices - (for example, the use of global data vs. local data in various parts of the implementation) - may have an impact on the analysis that is performed. The design description of the TCP - module would list the interfaces presented by the implementation (rather than just those - defined in RFC 793), as well as an algorithm description of the processing associated with - the modules implementing TCP (assuming they were part of the TSF). - - In the design, modules are described in detail in terms - of the function they provide (the purpose); the interfaces - they present (when required by the criteria); the return - values from such interfaces; the interfaces (presented by other modules) - they use (provided those interfaces are required to be also described); - and a description of how they provide their functionality using a - technique appropriate to the method used to implement the module. - - The purpose of a module should be described indicating what - function the module is providing. It should be sufficient so - that the reader could get a general idea of what the - module's function is in the architecture. - - The interfaces presented by a module are those interfaces used by - other modules to invoke the functionality provided. Interfaces include both - explicit interfaces (e.g., a calling sequence invoked by - other modules) as well as implicit interfaces (e.g., global - data manipulated by the module). Interfaces are described in terms of how - they are invoked, and any values that are returned. This description would - include a list of parameters, and descriptions of these parameters. If a parameter - were expected to take on a set of values (e.g., a ``flag'' parameter), the complete set - of values the parameter could take on that would have an effect on module processing - would be specified. Likewise, parameters representing data structures are described - such that each field of the data structure is identified and described. - Global data should be described to the extent required to understand their purpose. - The level of description required for a global data structure needs to be identical - to the one for module interfaces, where the input parameter and return values correspond - to the individual fields and their possible values in the data structure. Global data - structures may be described separate from the modules that manipulate or read them as - long as the design of the modules contain sufficient information about the global data - structures updated or the information extracted from global data structures. - - Note that different programming languages may have - additional ``interfaces'' that would be non-obvious; an - example would be operator/function overloading in C++. This - ``implicit interface'' in the class description would also - be described as part of the module design. Note that - although a module could present only one interface, it is - more common that a module presents a small set of related - interfaces. - - When it is required to describe the interfaces used by a module, it must be - clear from either the design description of the module or the purpose of the - module called, what service is expected from the module called. For example if - Module A is being described, and it uses Module B's bubble sort routine, the - description of the interaction between modules must allow to identify why - Module B's bubble sort routine is called and what this call contributes to the - implementation of the SFRs. The interface and purpose of Module B's bubble sort - routine must be described as part of the interfaces of Module B (provided the - level of ADV_TDS and the classification of Module B require a description its - interfaces) and so Module A just needs to identify what data it needs to have - sorted using this routine. An adequate description would be: "Module A invokes - Module B's interface double_bubble() to sort the usernames in - alphabetical order". - Note that if this sorting of the user names is not important for the enforcement of - any SFR (e. g. it is just done to speed up things and an algorithmically identical - implementation of Module A could also avoid to have the usernames sorted), the use of - Module B's bubble sort routine is not SFR-enforcing and it is suffcient to explain in - the description of Module A that the usernames are sorted in alphabetical order to - enhance performance. Module B may be classified as "SFR-supporting" only and the level - of ADV_TDS chosen indicates if the interfaces of SFR-supporting modules need to be - described or if its is sufficient to just describe the purpose of Module B. - - As discussed previously, the algorithmic description of the - module should describe in an algorithmic fashion the - implementation of the module. This can be done in - pseudo-code, through flow charts, or (at ) informal text. It discusses - how the module inputs and called functions are used to - accomplish the module's function. It notes changes to global - data, system state, and return values produced by the - module. It is at the level of detail that an implementation - could be derived that would be very similar to the actual - implementation of the TOE. - - It should be noted that source code does not meet the module - documentation requirements. Although the module design - describes the implementation, it is not the - implementation. The comments surrounding the source code - might be sufficient documentation if they provide an - explanation of the intent of the source code. In-line - comments that merely state what each line of code is doing - are useless because they provide no explanation of what the - module is meant to accomplish. - - In the elements below, the labels (SFR-enforcing, - SFR-supporting, and SFR-non-interfering) discussed for - subsystems and modules are used to describe the amount and - type of information that needs to be made available by the - developer. The elements have been structured so that there - is no expectation that the developer provide - only the information specified. That is, if - the developer's documentation of the TSF provides the - information in the requirements below, there is no - expectation that the developer update their documentation - and label subsystems and modules as SFR-enforcing, - SFR-supporting, and SFR-non-interfering. The primary purpose - of this labelling is to allow developers with less mature - development methodologies (and associated artifacts, such as - detailed interface and design documentation) to provide the - necessary evidence without undue cost. - - - - Because there is subjectivity in determining what is - SFR-enforcing vs. SFR-supporting (and in some cases, even - determining what is SFR-non-interfering) the following - paradigm has been adopted in this family. In early - components of the family, the developer makes a - determination about the classification of the subsystems - into SFR-enforcing, etc., supplying the appropriate - information, and there is little additional evidence for the - evaluator to examine to support this claim. As the level of - desired assurance increases, while the developer still makes - a classification determination, the evaluator obtains more - and more evidence that is used to confirm the developer's - classification. - - In order to focus the evaluator's analysis on the SFR-related - portions of the TOE, especially at lower levels of assurance, - the components of the family are levelled such that initially - detailed information is required only for SFR-enforcing - architectural entities. As the level of assurance increases, - more information is required for SFR-supporting and (eventually) - SFR-non-interfering entities. It should be noted that even when - complete information is required, it is not required that all of - this information be analysed in the same level of detail. The - focus should be in all cases on whether the - necessary information has been provided and - analysed. - - Table summarises the - information required at each of the family components for the - architectural entities to be described. - - - - - - TSF subsystem - TSF Module - - - SFR - Enforce - SFR - Support - SFR - NI - SFR - Enforce - SFR - Support - SFR - NI - - - - - - (informal - presentation) - - structure, summary of SFR-Enf. behaviour, interactions - - designation support - designation support means that - only documentation sufficient to support the - classification of the subsystem / module is - needed. - - designation support - - - - - - - (informal - presentation) - - structure, detailed description of SFR-Enf. behaviour, - summary of other behaviour, interactions - - - structure, summary of other behaviour, interactions - - designation support, interactions - - - - - - - - (informal - presentation) description, - interactions description, interactions - description, interactions - - purpose, SFR interfacesSFR interfaces means that the module description contains, - for each SFR-related interface, the returned values and the called interfaces - to other modules. - interaction, purpose - interaction, purpose - - - - (semiformal - presentation) - description, interactions - description, interactions - description, interactions - - purpose, SFR interfaces - - - purpose, SFR interfaces - - interaction, purpose - - - - - (semiformal - presentation) - description, interactions - description, interactions - description, interactions - - purpose, all interfacesAll interfaces means that the module description contains, - for each interface, the returned values and the called interfaces to other - modules. - - purpose, all interfaces - - - purpose, all interfaces - - - - - (semiformal - presentation; additional formal - presentation) - description, interactions - description, interactions - description, interactions - - purpose, all interfaces - - - purpose, all interfaces - - - purpose, all interfaces - - - - - Description Detail Levelling -
- - - - - Formal methods provide a mathematical representation of the - TSF and its behaviour and are required by the , , and - components. There are two aspects of formal methods: the - specification language that is used for - formal expression, and the theorem prover - that mathematically proves the completeness and correctness of - the formal specification. - - A formal specification is expressed within a formal system - based upon well-established mathematical concepts. These - mathematical concepts are used to define well-defined - semantics, syntax and rules of inference. A formal system is - an abstract system of identities and relations that can be - described by specifying a formal alphabet, a formal language - over that alphabet which is based on a formal syntax, and a - set of formal rules of inference for constructing derivations - of sentences in the formal language. - - The evaluator should examine the identified formal systems to - make sure that: - - The semantics, syntax and inference rules of the - formal system are defined or a definition is - referenced. - Each formal system is accompanied by explanatory text - that provides defined semantics so that: - - the explanatory text provides defined meanings of - terms, abbreviations and acronyms that are used in a - context other than that accepted by normal - usage, - the use of a formal system and semiformal notation - use is accompanied by supporting explanatory text in - informal style appropriate for unambiguous - meaning, - the formal system is able to express rules and - characteristics of applicable SFPs, - security functionality and interfaces (providing - details of effects, exceptions and error messages) of - TSF, their subsystems or modules to be specified for - the assurance family for which the notations are - used. - the notation provides rules to determine the - meaning of syntactical valid constructs. - - Each formal system uses a formal syntax that provides - rules to unambiguously recognise constructs. - Each formal system provides proof rules which - - support logical reasoning of well-established - mathematical concepts, - help to prevent derivation of - contradictions - - If the developer uses a formal system which is already accepted - by the evaluation authority the evaluator can rely on the level - of formality and strength of the system and focus on the - instantiation of the formal system to the TOE specifications and - correspondence proofs. - - The formal style supports mathematical proofs of the security - properties based on the security features, the consistency of - refinements and the correspondence of the representations. - Formal tool support seems adequate whenever manual derivations - would otherwise become long winded and - incomprehensible. Formal tools are also apt to reduce the - error probability inherent in manual derivations. - - Examples of formal systems: - - The Z specification language is highly - expressive, and supports many different methods or styles - of formal specification. The use of Z has been - predominantly for model-oriented specification, using - schemas to formally specify - operations. See for more - information. - ACL2 is an open-source formal system - comprising a LISP-based specification language and a - theorem prover. See for - further information. - Isabelle is a popular generic theorem - proving environment that allows mathematical formulae to - be expressed in a formal language and provides tools for - proving those formulae within a logical calculus (see - e.g. for - additional information) - The B method is a formal system based - on the propositional calculus, the first order predicate - calculus with inference rules and set theory (see - e.g. for further - information). - - - - - The dependencies documented in the components of Clauses and - are the direct dependencies between the - assurance components. - - The following dependency tables for assurance components show - their direct, indirect and optional dependencies. Each of the - components that is a dependency of some assurance component is - allocated a column. Each assurance component is allocated a - row. The value in the table cell indicate whether the column - label component is directly required (indicated by a cross - ``X'') or indirectly required (indicated by a dash ``-''), by - the row label component. If no character is presented, the - component is not dependent upon another component. - - - - The purpose of this Clause is to document the philosophy that - underpins the CC approach to assurance. An understanding of this - Clause will permit the reader to understand the rationale behind - the CC Part 3 assurance requirements. - - - The CC philosophy is that the threats to security and - organisational security policy commitments should be clearly - articulated and the proposed security measures be demonstrably - sufficient for their intended purpose. - - Furthermore, measures should be adopted that reduce the - likelihood of vulnerabilities, the ability to exercise - (i.e. intentionally exploit or unintentionally trigger) a - vulnerability, and the extent of the damage that could occur - from a vulnerability being exercised. Additionally, measures - should be adopted that facilitate the subsequent - identification of vulnerabilities and the elimination, - mitigation, and/or notification that a vulnerability has been - exploited or triggered. - - - - The CC philosophy is to provide assurance based upon an - evaluation (active investigation) of the IT product that is to - be trusted. Evaluation has been the traditional means of - providing assurance and is the basis for prior evaluation - criteria documents. In aligning the existing approaches, the - CC adopts the same philosophy. The CC proposes measuring the - validity of the documentation and of the resulting IT product - by expert evaluators with increasing emphasis on scope, depth, - and rigour. - - The CC does not exclude, nor does it comment upon, the - relative merits of other means of gaining assurance. Research - continues with respect to alternative ways of gaining - assurance. As mature alternative approaches emerge from these - research activities, they will be considered for inclusion in - the CC, which is so structured as to allow their future - introduction. - - - It is assumed that there are threat agents that will - actively seek to exploit opportunities to violate security - policies both for illicit gains and for well-intentioned, - but nonetheless insecure actions. Threat agents may also - accidentally trigger security vulnerabilities, causing harm - to the organisation. Due to the need to process sensitive - information and the lack of availability of sufficiently - trusted products, there is significant risk due to failures - of IT. It is, therefore, likely that IT security breaches - could lead to significant loss. - - IT security breaches arise through the intentional - exploitation or the unintentional triggering of - vulnerabilities in the application of IT within business - concerns. - - Steps should be taken to prevent vulnerabilities arising in - IT products. To the extent feasible, vulnerabilities should - be: - - - eliminated -- that is, active steps should be taken to - expose, and remove or neutralise, all exercisable - vulnerabilities; - - - minimised -- that is, active steps should be taken to - reduce, to an acceptable residual level, the potential - impact of any exercise of a vulnerability; - - - monitored -- that is, active steps should be taken to - ensure that any attempt to exercise a residual - vulnerability will be detected so that steps can be - taken to limit the damage. - - - - - - Vulnerabilities can arise through failures in: - - - requirements -- that is, an IT product may possess all - the functions and features required of it and still - contain vulnerabilities that render it unsuitable or - ineffective with respect to security; - - - development -- that is, an IT product does not meet its - specifications and/or vulnerabilities have been - introduced as a result of poor development standards or - incorrect design choices; - - - operation -- that is, an IT product has been constructed - correctly to a correct specification but vulnerabilities - have been introduced as a result of inadequate controls - upon the operation. - - - - - - Assurance is grounds for confidence that an IT product meets - its security objectives. Assurance can be derived from - reference to sources such as unsubstantiated assertions, - prior relevant experience, or specific experience. However, - the CC provides assurance through active - investigation. Active investigation is an evaluation of the - IT product in order to determine its security - properties. - - - - Evaluation has been the traditional means of gaining - assurance, and is the basis of the CC approach. Evaluation - techniques can include, but are not limited to: - - - analysis and checking of process(es) and procedure(s); - - - checking that process(es) and procedure(s) are being - applied; - - - analysis of the correspondence between TOE design - representations; - - - analysis of the TOE design representation against the - requirements; - - - verification of proofs; - - - analysis of guidance documents; - - - analysis of functional tests developed and the results - provided; - - - independent functional testing; - - - analysis for vulnerabilities (including flaw - hypothesis); - - - penetration testing. - - - - - - - The CC philosophy asserts that greater assurance results from - the application of greater evaluation effort, and that the - goal is to apply the minimum effort required to provide the - necessary level of assurance. The increasing level of effort - is based upon: - - - scope -- that is, the effort is greater because a larger - portion of the IT product is included; - - - depth -- that is, the effort is greater because it is - deployed to a finer level of design and implementation - detail; - - - rigour -- that is, the effort is greater because it is - applied in a more structured, formal manner. - - - - - - - This annex provides an explanation of the criteria and examples of their application. This - annex does not define the criteria; - this definition can be found in CC Part 3 Section . - - This annex consists of 2 major parts: - - - Guidance for completing an independent vulnerability - analysis. This is summarised in section , and described in more - detail in section - . These sections describe how an evaluator should approach - the construction of an independent Vulnerability Analysis. - - - How to characterise and use assumed Attack Potential of an - attacker. This is described in sections to . These sections provide an example of describe - how an attack potential can be characterised and should be - used, and provide examples. - - - - - The purpose of the vulnerability assessment activity is to - determine the existence and exploitability of flaws or - weaknesses in the TOE in the operational environment. This - determination is based upon analysis performed by the - evaluator, and is supported by evaluator testing. - - At the lowest levels of the - evaluator simply performs a search of publicly available - information to identify any known weaknesses in the TOE, while - at the higher levels the evaluator performs a structured - analysis of the TOE evaluation evidence. - - There are three main factors in performing a vulnerability - analysis, namely: - - the identification of potential vulnerabilities; - - assessment to determine whether the identified potential - vulnerabilities could allow an attacker with the relevant - attack potential to violate the SFRs. - - penetration testing to determine whether the identified - potential vulnerabilities are exploitable in the operational - environment of the TOE. - - - The identification of vulnerabilities can be further - decomposed into the evidence to be searched and how hard to - search that evidence to identify potential vulnerabilities. In - a similar manner, the penetration testing can be further - decomposed into analysis of the potential vulnerability to - identify attack methods and the demonstration of the attack - methods. - - These main factors are iterative in nature, i.e. penetration - testing of potential vulnerabilities may lead to the - identification of further potential vulnerabilities. Hence, - these are performed as a single vulnerability analysis - activity. - - - - The evaluator vulnerability analysis is to determine that the - TOE is resistant to penetration attacks performed by an - attacker possessing a Basic (for and ), - Enhanced-Basic (for ), - Moderate (for ) or High (for - ) attack potential. The - evaluator first assesses the exploitability of all identified - potential vulnerabilities. This is accomplished by conducting - penetration testing. The evaluator should assume the role of - an attacker with a Basic (for - and ), Enhanced-Basic (for - ), Moderate (for ) or High (for ) attack potential when attempting to penetrate the - TOE. - - The evaluator considers potential vulnerabilities encountered - by the evaluator during the conduct of other evaluation - activities. The evaluator penetration testing determining TOE - resistance to these potential vulnerabilities should be - performed assuming the role of an attacker with a Basic (for - and ), Enhanced-Basic (for ), Moderate (for ) - or High (for ) attack - potential. - - However, vulnerability analysis should not be performed as an - isolated activity. It is closely linked with and . The evaluator - performs these other evaluation activities with a focus on - identifying potential vulnerabilities or ``areas of - concern''. Therefore, evaluator familiarity with the generic - vulnerability guidance (provided in Section ) is required. - - - The following five categories provide discussion of generic - vulnerabilities. - - - Bypassing includes any means by which an attacker could - avoid security enforcement, by: - - - exploiting the capabilities of interfaces to the TOE, - or of utilities which can interact with the TOE; - - - inheriting privileges or other capabilities that - should otherwise be denied; - - - (where confidentiality is a concern) reading sensitive - data stored or copied to inadequately protected areas. - - - - Each of the following should be considered (where - relevant) in the evaluator's independent vulnerability - analysis. - - - Attacks based on exploiting the capabilities of - interfaces or utilities generally take advantage of - the absence of the required security enforcement on - those interfaces. For example, gaining access to - functionality that is implemented at a lower level - than that at which access control is - enforced. Relevant items include: - - - changing the predefined sequence of invocation of - TSFI; - - - invoking an additional TSFI; - - - using a component in an unexpected context or for - an unexpected purpose; - - - using implementation detail introduced in less - abstract representations; - - - using the delay between time of access check and - time of use. - - - - - Changing the predefined sequence of invocation of - components should be considered where there is an - expected order in which interfaces to the TOE - (e.g. user commands) are called to invoke a TSFI - (e.g. opening a file for access and then reading data - from it). If a TSFI is invoked through one of the TOE - interfaces (e.g. an access control check), the - evaluator should consider whether it is possible to - bypass the control by performing the call at a later - point in the sequence or by missing it out altogether. - - - Executing an additional component (in the predefined - sequence) is a similar form of attack to the one - described above, but involves the calling of some - other TOE interface at some point in the sequence. It - can also involve attacks based on interception of - sensitive data passed over a network by use of network - traffic analysers (the additional component here being - the network traffic analyser). - - - Using a component in an unexpected context or for an - unexpected purpose includes using an unrelated TOE - interface to bypass the TSF by using it to achieve a - purpose that it was not designed or intended to - achieve. Covert channels are an example of this type - of attack (see for further discussion of covert - channels). The use of undocumented interfaces, which - may be insecure, also falls into this category. Such - interfaces may include undocumented support and help - facilities. - - - Using implementation detail introduced in lower - representations may allow an attacker to take - advantage of additional functions, resources or - attributes that are introduced to the TOE as a - consequence of the refinement process. Additional - functionality may include test harness code contained - in software modules and back-doors introduced during - the implementation process. - - - Using the delay between time of check and time of use - includes scenarios where an access control check is - made and access granted, and an attacker is - subsequently able to create conditions in which, had - they applied at the time the access check was made, - would have caused the check to fail. An example would - be a user creating a background process to read and - send highly sensitive data to the user's terminal, and - then logging out and logging back in again at a lower - sensitivity level. If the background process is not - terminated when the user logs off, the MAC checks - would have been effectively bypassed. - - - Attacks based on inheriting privileges are generally - based on illicitly acquiring the privileges or - capabilities of some privileged component, usually by - exiting from it in an uncontrolled or unexpected - manner. Relevant items include: - - - executing data not intended to be executable, or - making it executable; - - - generating unexpected input for a component; - - - invalidating assumptions and properties on which - lower-level components rely. - - - - - Executing data not intended to be executable, or - making it executable includes attacks involving - viruses (e.g. putting executable code or commands in a - file which are automatically executed when the file is - edited or accessed, thus inheriting any privileges the - owner of the file has). - - - Generating unexpected input for a component can have - unexpected effects which an attacker could take - advantage of. For example, if the TSF could be - bypassed if a user gains access to the underlying - operating system, it may be possible to gain such - access following the login sequence by exploring the - effect of hitting various control or escape sequences - whilst a password is being authenticated. - - - Invalidating assumptions and properties on which lower - level components rely includes attacks based on - breaking out of the constraints of an application to - gain access to an underlying operating system in order - to bypass the TSF of an application. In this case the - assumption being invalidated is that it is not - possible for a user of the application to gain such - access. A similar attack can be envisaged against an - application on an underlying database management - system: again the TSF could be bypassed if an attacker - can break out of the constraints of the application. - - - Attacks based on reading sensitive data stored in - inadequately protected areas (applicable where - confidentiality is a concern) include the following - issues which should be considered as possible means of - gaining access to sensitive data: - - - disk scavenging; - - - access to unprotected memory; - - - exploiting access to shared writable files or - other shared resources (e.g. swap files); - - - Activating error recovery to determine what access - users can obtain. For example, after a crash an - automatic file recovery system may employ a lost - and found directory for headerless files, which - are on disk without labels. If the TOE implements - mandatory access controls, it is important to - investigate at what security level this directory - is kept (e.g. at system high), and who has access - to this directory. - - - - - - There are a number of different methods through which an - evaluator may identify a back-door, including two main - techniques. Firstly, by the evaluator inadvertently - identifying during testing an interface that can be - misused. Secondly, through testing each external - interface of the TSF in a debugging mode to identify any - modules that are not called as a part of testing the - documented interfaces and then inspecting the code that is - not called to consider whether it is a back-door. - - For a software TOE where and or - higher components are included in the assurance package, - the evaluator may consider during their analysis of the - tools the libraries and packages that are linked by the - compiler at compilation stage to determine that back-doors - are not introduced at this stage. - - - - Tampering includes any attack based on an attacker - attempting to influence the behaviour of the TSF - (i.e. corruption or de-activation), for example by: - - - accessing data on whose confidentiality or integrity - the TSF relies; - - - forcing the TOE to cope with unusual or unexpected - circumstances; - - - disabling or delaying security enforcement; - - - physical modification the TOE. - - - - Each of the following should be considered (where - relevant) in the evaluator's independent vulnerability - analysis. - - - Attacks based on accessing data, whose confidentiality - or integrity are protected, include: - - - reading, writing or modifying internal data - directly or indirectly; - - - using a component in an unexpected context or for - an unexpected purpose; - - - using interfaces between components that are not - visible at a higher level of abstraction. - - - - - Reading, writing or modifying internal data directly - or indirectly includes the following types of attack - which should be considered: - - - reading ``secrets'' stored internally, such as - user passwords; - - - spoofing internal data that security enforcing - mechanisms rely upon; - - - modifying environment variables (e.g. logical - names), or data in configuration files or - temporary files. - - - - It may be possible to deceive a trusted process into - modifying a protected file that it wouldn't normally - access. - - - The evaluator should also consider the following - ``dangerous features'': - - - source code resident on the TOE along with a - compiler (for instance, it may be possible to - modify the login source code); - - - an interactive debugger and patch facility (for - instance, it may be possible to modify the - executable image); - - - the possibility of making changes at device - controller level, where file protection does not - exist; - - - diagnostic code which exists in the source code - and that may be optionally included; - - - developer's tools left in the TOE. - - - - - Using a component in an unexpected context or for an - unexpected purpose includes (for example), where the - TOE is an application built upon an operating system, - users exploiting knowledge of a word processor package - or other editor to modify their own command file - (e.g. to acquire greater privileges). - - - Using interfaces between components which are not - visible at a higher level of abstraction includes - attacks exploiting shared access to resources, where - modification of a resource by one component can - influence the behaviour of another (trusted) - component, e.g. at source code level, through the use - of global data or indirect mechanisms such as shared - memory or semaphores. - - - Attacks based on forcing the TOE to cope with unusual - or unexpected circumstances should always be - considered. Relevant items include: - - - generating unexpected input for a component; - - - invalidating assumptions and properties on which - lower-level components rely. - - - - - Generating unexpected input for a component includes - investigating the behaviour of the TOE when: - - - command input buffers overflow (possibly - ``crashing the stack'' or overwriting other - storage, which an attacker may be able to take - advantage of, or forcing a crash dump that may - contain sensitive information such as clear-text - passwords); - - - invalid commands or parameters are entered - (including supplying a read-only parameter to an - interface which expects to return data via that - parameter and supplying improperly formatted input - that should fail parsing such as SQL-injection, - format strings); - - - an end-of-file marker (e.g. CTRL-Z or CTRL-D) or - null character is inserted in an audit trail. - - - - - Invalidating assumptions and properties on which - lower-level components rely includes attacks taking - advantage of errors in the source code where the code - assumes (explicitly or implicitly) that security - relevant data is in a particular format or has a - particular range of values. In these cases the - evaluator should determine whether they can invalidate - such assumptions by causing the data to be in a - different format or to have different values, and if - so whether this could confer advantage to an attacker. - - - The correct behaviour of the TSF may be dependent on - assumptions that are invalidated under extreme - circumstances where resource limits are reached or - parameters reach their maximum value. The evaluator - should consider (where practical) the behaviour of the - TOE when these limits are reached, for example: - - - changing dates (e.g. examining how the TOE behaves - when a critical date threshold is passed); - - - filling disks; - - - exceeding the maximum number of users; - - - filling the audit log; - - - saturating security alarm queues at a console; - - - overloading various parts of a multi-user TOE - which relies heavily upon communications - components; - - - swamping a network, or individual hosts, with - traffic; - - - filling buffers or fields. - - - - - Attacks based on disabling or delaying security - enforcement include the following items: - - - using interrupts or scheduling functions to - disrupt sequencing; - - - disrupting concurrence; - - - using interfaces between components which are not - visible at a higher level of abstraction. - - - - - Using interrupts or scheduling functions to disrupt - sequencing includes investigating the behaviour of the - TOE when: - - - a command is interrupted (with CTRL-C, CTRL-Y, - etc.); - - - a second interrupt is issued before the first is - acknowledged. - - - - - The effects of terminating security critical processes - (e.g. an audit daemon) should be explored. Similarly, - it may be possible to delay the logging of audit - records or the issuing or receipt of alarms such that - it is of no use to an administrator (since the attack - may already have succeeded). - - - Disrupting concurrence includes investigating the - behaviour of the TOE when two or more subjects attempt - simultaneous access. It may be that the TOE can cope - with the interlocking required when two subjects - attempt simultaneous access, but that the behaviour - becomes less well defined in the presence of further - subjects. For example, a critical security process - could be put into a resource-wait state if two other - processes are accessing a resource which it requires. - - - Using interfaces between components which are not - visible at a higher level of abstraction may provide a - means of delaying a time-critical trusted process. - - - Physical attacks can be categorised into physical - probing, physical manipulation, physical modification, - and substitution. - - - Physical probing by penetrating the TOE targeting - internals of the TOE, e.g. reading at internal - communication interfaces, lines or memories. - - - Physical manipulation can be with the TOE - internals aiming at internal modifications of the - TOE (e.g. by using optical fault induction as an - interaction process), at the external interfaces - of the TOE (e.g. by power or clock glitches) and - at the TOE environment (e.g. by modifying - temperature). - - - Physical modification of TOE internal security - enforcing attributes to inherit privileges or - other capabilities that should be denied in - regular operation. Such modifications can be - caused, e.g., by optical fault induction. Attacks - based on physical modification may also yield a - modification of the TSF itself, e.g. by causing - faults at TOE internal program data transfers - before execution. Note, that such kind of - bypassing by modifying the TSF itself can - jeopardise every TSF unless there are other - measures (possibly environmental measures) that - prevent an attacker from gaining physical access - to the TOE. - - - Physical substitution to replace the TOE with - another IT entity, during delivery or operation of - the TOE. Substitution during delivery of the TOE - from the development environment to the user - should be prevented through application of secure - delivery procedures (such as those considered - under ). Substitution of the TOE during - operation may be considered through a combination - of user guidance and the operational environment, - such that the user is able to be confident that - they are interacting with the TOE. - - - - - - - - Direct attack includes the identification of any - penetration tests necessary to test the strength of - permutational or probabilistic mechanism and other - mechanisms to ensure they withstand direct attack. - - For example, it may be a flawed assumption that a - particular implementation of a pseudo-random number - generator will possess the required entropy necessary to - seed the security mechanism. - - Where a probabilistic or permutational mechanism relies on - selection of security attribute value (e.g. selection of - password length) or entry of data by a human user - (e.g. choice of password), the assumptions made should - reflect the worst case. - - Probabilistic or permutational mechanisms should be - identified during examination of evaluation evidence - required as input to this sub-activity (security target, - functional specification, TOE design and implementation - representation subset) and any other TOE (e.g. guidance) - documentation may identify additional probabilistic or - permutational mechanisms. - - Where the design evidence or guidance includes assertions - or assumptions (e.g. about how many authentication - attempts are possible per minute), the evaluator should - independently confirm that these are correct. This may be - achieved through testing or through independent - analysis. - - Direct attacks reliant upon a weakness in a cryptographic - algorithm should not be considered under , as this is outside the scope - of the CC. Correctness of the implementation of the - cryptographic algorithm is considered during the and - activities. - - - - Information is an abstract view on relation between the - properties of entities, i.e. a signal contains information - for a system, if the TOE is able to react to this - signal. The TOE resources processes and stores information - represented by user data. Therefore: - - - information may flow with the user data between - subjects by internal TOE transfer or export from the TOE; - - - information may be generated and passed to other user - data; - - - information may be gained through monitoring the - operations on data representing the information. - - - - The information represented by user data may be - characterised by security attributes like ``classification - level'' having values, for example unclassified, - confidential, secret, top secret, to control operations to - the data. This information and therefore the security - attributes may be changed by operations e.g. may describe decrease of the - level by ``sanitarisation'' or increase of level by - combination of data. This is one aspects of an information - flow analysis focused on controlled operations of - controlled subjects on controlled objects. - - The other aspect is the analysis of illicit - information flow. This aspect is more - general than the direct access to objects containing user - data addressed by the - family. An unenforced - signalling channel carrying information under control of - the information flow control policy can also be caused by - monitoring of the processing of any object containing or - related to this information (e.g. side channels). An - enforced signalling channels - may be identified in terms of the subjects manipulating - resources and the subject or user that observe such - manipulation. Classically, covert channels have been - identified as timing or storage channels, according to the - resource being modified or modulated. As for other - monitoring attacks, the use of the TOE is in accordance - with the SFRs. - - Covert channels are normally applicable in the case when - the TOE has unobservability AND multi-level separation - policy requirements. Covert channels may be routinely - spotted during vulnerability analysis and design - activities, and should therefore be tested. However, - generally such monitoring attacks are only identified - through specialised analysis techniques commonly referred - to as ``covert channel analysis''. These techniques have - been the subject of much research and there are many - papers published on this subject. Guidance for the - conduct of covert channel analysis should be sought from - the evaluation authority. - - Unenforced information flow monitoring - attacks include passive analysis techniques aiming at - disclosure of sensitive internal data of the TOE by - operating the TOE in the way that corresponds to the - guidance documents. - - Side Channel Analysis includes crypt analytical techniques - based on physical leakage of the TOE. Physical leakage can - occur by timing information, power consumption or power - emanation during computation of a TSF. Timing information - can be collected also by a remote-attacker (having network - access to the TOE), power based information channels - requires that the attacker is in the near-by environment - of the TOE. - - Eavesdropping techniques include interception of all forms - of energy, e.g., electromagnetic or optical emanation of - computer displays, not necessarily in the near-field of - the TOE. - - Monitoring also includes exploits of protocol flaws, e.g., - an attack on SSL implementation. - - - - Misuse may arise from: - - - incomplete guidance documentation; - - - unreasonable guidance; - - - unintended misconfiguration of the TOE; - - - forced exception behaviour of the TOE. - - - - If the guidance documentation is incomplete the user may - not know how to operate the TOE in accordance with the - SFRs. The evaluator should apply familiarity with the TOE - gained from performing other evaluation activities to - determine that the guidance is complete. In particular, - the evaluator should consider the functional - specification. The TSF described in this document should - be described in the guidance as required to permit secure - administration and use through the TSFI available to human - users. In addition, the different modes of operation - should be considered to ensure that guidance is provided - for all modes of operation. - - The evaluator may, as an aid, prepare an informal mapping - between the guidance and these documents. Any omissions in - this mapping may indicate incompleteness. - - The guidance is considered to be unreasonable if it makes - demands on the TOE's usage or operational environment that - are inconsistent with the ST or unduly onerous to maintain - security. - - A TOE may use a variety of ways to assist the consumer in - effectively using that TOE in accordance with the SFRs and - prevent unintentional misconfiguration. A TOE may employ - functionality (features) to alert the consumer when the - TOE is in a state that is inconsistent with the SFRs, - whilst other TOEs may be delivered with enhanced guidance - containing suggestions, hints, procedures, etc. on using - the existing security features most effectively; for - instance, guidance on using the audit feature as an aid - for detecting when the SFRs are being compromised; namely - insecure. - - The evaluator considers the TOE's functionality, its - purpose and security objectives for the operational - environment to arrive at a conclusion of whether or not - there is reasonable expectation that use of the guidance - would permit transition into an insecure state to be - detected in a timely manner. - - The potential for the TOE to enter into insecure states - may be determined using the evaluation deliverables, such - as the ST, the functional specification and any other - design representations provided as evidence for components - included in the assurance package for the TOE (e.g. the - TOE/TSF design specification if a component from is included). - - Instances of forced exception behaviour of the TSF could - include, but are not limited to, the following: - - - behaviour of the TOE when start-up, close-down or error - recovery is activated; - - - behaviour of the TOE under extreme circumstances - (sometimes termed overload or asymptotic behaviour), - particularly where this could lead to the - de-activation or disabling of parts of the TSF; - - - any potential for unintentional misconfiguration or - insecure use arising from attacks noted in the section - on tampering above. - - - - - - - Potential vulnerabilities may be identified by the evaluator - during different activities. They may become apparent during - an evaluation activity or they may be identified as a result - of analysis of evidence to search for - vulnerabilities. - - - The encountered identification of vulnerabilities is where - potential vulnerabilities are identified by the evaluator - during the conduct of evaluation activities, i.e. the - evidence are not being analysed with the express aim of - identifying potential vulnerabilities. - - The encountered method of identification is dependent on the - evaluator's experience and knowledge; which is monitored and - controlled by the evaluation authority. It is not reproducible - in approach, but will be documented to ensure repeatability of - the conclusions from the reported potential - vulnerabilities. - - There are no formal analysis criteria required for this - method. Potential vulnerabilities are identified from the - evidence provided as a result of knowledge and - experience. However, this method of identification is not - constrained to any particular subset of evidence. - - Evaluator is assumed to have knowledge of the TOE-type - technology and known security flaws as documented in the - public domain. The level of knowledge assumed is that - which can be gained from a security e-mail list relevant - to the TOE type, the regular bulletins (bug, vulnerability - and security flaw lists) published by those organisations - researching security issues in products and technologies - in widespread use. This knowledge is not expected to - extend to specific conference proceedings or detailed - theses produced by university research for or . However, to ensure the knowledge applied is - up to date, the evaluator may need to perform a search of - public domain material. - - For to the search of publicly - available information is expected to include conference - proceeding and theses produced during research activities - by universities and other relevant organisations. - - Examples of how these may arise (how the evaluator may - encounter potential vulnerabilities): - - - while the evaluator is examining some evidence, it - sparks a memory of a potential vulnerability - identified in a similar product type, that the - evaluator believes to also be present in the TOE under - evaluation; - - - while examining some evidence, the evaluator spots a - flaw in the specification of an interface, that - reflects a potential vulnerability. - - - This may include becoming aware of a potential - vulnerability in a TOE through reading about generic - vulnerabilities in a particular product type in an IT - security publication or on a security e-mail list to which - the evaluator is subscribed. - - Attack methods can be developed directly from these - potential vulnerabilities. Therefore, the encountered - potential vulnerabilities are collated at the time of - producing penetration tests based on the evaluator's - vulnerability analysis. There is no explicit action for - the evaluator to encounter potential - vulnerabilities. Therefore, the evaluator is directed - through an implicit action specified in and .*.4E. - - Current information regarding public domain - vulnerabilities and attacks may be provided to the - evaluator by, for example, an evaluation authority. This - information is to be taken into account by the evaluator - when collating encountered vulnerabilities and attack - methods when developing penetration tests. - - - - The following types of analysis are presented in terms of - the evaluator actions. - - - The unstructured analysis to be performed by the - evaluator (for ) - permits the evaluator to consider the generic - vulnerabilities (as discussed in ). The evaluator will also apply their - experience and knowledge of flaws in similar technology - types. - - - - During the conduct of evaluation activities the - evaluator may also identify areas of concern. These are - specific portions of the TOE evidence that the evaluator - has some reservation about, although the evidence meets - the requirements for the activity with which the - evidence is associated. For example, a particular - interface specification looks particularly complex, and - therefore may be prone to error either in the - development of the TOE or in the operation of the - TOE. There is no potential vulnerability apparent at - this stage, further investigation is required. This is - beyond the bounds of encountered, as further - investigation is required. - - Difference between potential vulnerability and area of - concern: - - - Potential vulnerability - The evaluator knows a - method of attack that can be used to exploit the - weakness or the evaluator knows of vulnerability - information that is relevant to the TOE. - - - Area of concern - The evaluator may be able to - discount concern as a potential vulnerability based - on information provided elsewhere. While reading - interface specification, the evaluator identifies - that due to the extreme (unnecessary) complexity of - an interface a potential vulnerability may lay - within that area, although it is not apparent - through this initial examination. - - - The focused approach to the identification of - vulnerabilities is an analysis of the evidence with the - aim of identifying any potential vulnerabilities evident - through the contained information. It is an unstructured - analysis, as the approach is not predetermined. This - approach to the identification of potential - vulnerabilities can be used during the independent - vulnerability analysis required by . - - This analysis can be achieved through different - approaches, that will lead to commensurate levels of - confidence. None of the approaches have a rigid format - for the examination of evidence to be performed. - - The approach taken is directed by the results of the - evaluator's assessment of the evidence to determine it - meets the requirements of the / - sub-activities. Therefore, the investigation of the - evidence for the existence of potential vulnerabilities - may be directed by any of the following: - - - areas of concern identified during examination of - the evidence during the conduct of evaluation - activities; - - - reliance on particular functionality to provide - separation, identified during the analysis of the - architectural design (as in ), requiring further analysis to - determine it cannot be bypassed; - - - representative examination of the evidence to - hypothesise potential vulnerabilities in the - TOE. - - The evaluator will report what actions were taken to - identify potential vulnerabilities in the - evidence. However, the evaluator may not be able to - describe the steps in identifying potential - vulnerabilities before the outset of the - examination. The approach will evolve as a result of the - outcome of evaluation activities. - - The areas of concern may arise from examination of any - of the evidence provided to satisfy the SARs specified - for the TOE evaluation. The information publicly - accessible is also considered. - - The activities performed by the evaluator can be - repeated and the same conclusions, in terms of the level - of assurance in the TOE, can be reached although the - steps taken to achieve those conclusions may vary. As - the evaluator is documenting the form the analysis took, - the actual steps taken to achieve those conclusions are - also reproducible. - - - - The methodical analysis approach takes the form of a - structured examination of the evidence. This method - requires the evaluator to specify the structure and form - the analysis will take (i.e. the manner in which the - analysis is performed is predetermined, unlike the - focused identification method). The method is specified - in terms of the information that will be considered and - how/why it will be considered. This approach to the - identification of potential vulnerabilities can be used - during the independent vulnerability analysis required - by and . - - This analysis of the evidence is deliberate and - pre-planned in approach, considering all evidence - identified as an input into the analysis. - - All evidence provided to satisfy the () assurance requirements specified in the - assurance package are used as input to the potential - vulnerability identification activity. - - The ``methodical'' descriptor for this analysis has been - used in an attempt to capture the characterisation that - this identification of potential vulnerabilities is to - take an ordered and planned approach. A ``method'' or - ``system'' is to be applied in the examination. The - evaluator is to describe the method to be used in terms - of what evidence will be considered, the information - within the evidence that is to be examined, the manner - in which this information is to be considered; and the - hypothesis that is to be generated. - - The following provide some examples that a hypothesis - may take: - - - consideration of malformed input for interfaces - available to an attacker at the external interfaces; - - - examination of a security mechanism, such as domain - separation, hypothesising internal buffer overflows - leading to degradation of separation; - - - analysis to identify any objects created in the TOE - implementation representation that are then not - fully controlled by the TSF, and could be used by an - attacker to undermine the SFRs. - - - - For example, the evaluator may identify that interfaces - are a potential area of weakness in the TOE and specify - an approach to the analysis that ``all interface - specifications provided in the functional specification - and TOE design will be analysed to hypothesise potential - vulnerabilities'' and go on to explain the methods used - in the hypothesis. - - This identification method will provide a plan of attack - of the TOE, that would be performed by an evaluator - completing penetration testing of potential - vulnerabilities in the TOE. The rationale for the method - of identification would provide the evidence for the - coverage and depth of exploitation determination that - would be performed on the TOE. - - - - - - - - Attack potential is used by a PP/ST author during the - development of the PP/ST, in consideration of the threat - environment and the selection of assurance components. This - may simply be a determination that the attack potential - possessed by the assumed attackers of the TOE is generically - characterised as Basic, Enhanced-Basic, Moderate or - High. Alternatively, the PP/ST may wish to specify - particular levels of individual factors assumed to be - possessed by attackers. (e.g. the attackers are assumed to - be experts in the TOE technology type, with access to - specialised equipment.) - - The PP/ST author considers the threat profile developed during a - risk assessment (outside the scope of the CC, but used as an - input into the development of the PP/ST in terms of the Security - Problem Definition or in the case of low assurance STs, the - requirements statement). Consideration of this threat profile in - terms of one of the approaches discussed in the following - sections will permit the specification of the attack potential - the TOE is to resist. - - - - Attack potential is especially considered by the evaluator - in two distinct ways during the ST evaluation and the - vulnerability assessment activities. - - Attack potential is used by an evaluator during the conduct - of the vulnerability analysis sub-activity to determine - whether or not the TOE is resistant to attacks assuming a - specific attack potential of an attacker. If the evaluator - determines that a potential vulnerability is exploitable in - the TOE, they have to confirm that it is exploitable - considering all aspects of the intended environment, - including the attack potential assumed by an - attacker. - - Therefore, using the information provided in the threat - statement of the Security Target, the evaluator determines - the minimum attack potential required by an attacker to - effect an attack, and arrives at some conclusion about the - TOE's resistance to attacks. Table demonstrates the relationship between this - analysis and attack potential. - - - - - Vulnerability Component - TOE resistant to attacker with - attack potential of: - Residual vulnerabilities only - exploitable by attacker with attack potential - of: - - - - - VAN.5 - High - Beyond High - - - VAN.4 - Moderate - High - - - VAN.3 - Enhanced-Basic - Moderate - - - VAN.2 - Basic - Enhanced-Basic - - - VAN.1 - Basic - Enhanced-Basic - - - - Vulnerability testing and attack potential -
- - The ``beyond high'' entry in the residual vulnerabilities - column of the above table represents those potential - vulnerabilities that would require an attacker to have an - attack potential greater than that of ``high'' in order to - exploit the potential vulnerability. A vulnerability - classified as residual in this instance reflects the fact - that a known weakness exists in the TOE, but in the current - operational environment, with the assumed attack potential, - the weakness cannot be exploited. - - At any level of attack potential a potential vulnerability - may be deemed ``infeasible'' due to a countermeasure in the - operational environment that prevents the vulnerability from - being exploited. - - A vulnerability analysis applies to all TSFI, including ones - that access probabilistic or permutational mechanisms. No - assumptions are made regarding the correctness of the design - and implementation of the TSFI; nor are constraints placed - on the attack method or the attacker's interaction with the - TOE - if an attack is possible, then it is to be considered - during the vulnerability analysis. As shown in Table , successful evaluation - against a vulnerability assurance component reflects that - the TSF is designed and implemented to protect against the - required level of threat. - - It is not necessary for an evaluator to perform an attack - potential calculation for each potential vulnerability. In - some cases it is apparent when developing the attack method - whether or not the attack potential required to develop and - run the attack method is commensurate with that assumed of - the attacker in the operational environment. For any - vulnerabilities for which an exploitation is determined, the - evaluator performs an attack potential calculation to - determine that the exploitation is appropriate to the level - of attack potential assumed for the attacker. - - The approach described below is to be applied whenever it is - necessary to calculate attack potential, unless the evaluation - authority provides mandatory guidance that an alternative - approach is to be applied. The values given in Tables and - below are not mathematically proven. Therefore, the values given - in these example tables may need to be adjusted according to the - technology type and specific environments. The evaluator should - seek guidance from the evaluation authority. - - - - - - Attack potential is a function of expertise, resources and - motivation. There are multiple methods of representing and - quantifying these factors. Also, there may be other factors - that are applicable for particular TOE types. - - - Motivation is an attack potential factor that can be used - to describe several aspects related to the attacker and - the assets the attacker desires. Firstly, motivation can - imply the likelihood of an attack - one can infer from a - threat described as highly motivated that an attack is - imminent, or that no attack is anticipated from an - un-motivated threat. However, except for the two extreme - levels of motivation, it is difficult to derive a - probability of an attack occurring from motivation. - - Secondly, motivation can imply the value of the asset, - monetarily or otherwise, to either the attacker or the - asset holder. An asset of very high value is more likely - to motivate an attack compared to an asset of little - value. However, other than in a very general way, it is - difficult to relate asset value to motivation because the - value of an asset is subjective - it depends largely upon - the value an asset holder places on it. - - Thirdly, motivation can imply the expertise and resources - with which an attacker is willing to effect an attack. One - can infer that a highly motivated attacker is likely to - acquire sufficient expertise and resources to defeat the - measures protecting an asset. Conversely, one can infer - that an attacker with significant expertise and resources - is not willing to effect an attack using them if the - attacker's motivation is low. - - During the course of preparing for and conducting an - evaluation, all three aspects of motivation are at some - point considered. The first aspect, likelihood of attack, - is what may inspire a developer to pursue an - evaluation. If the developer believes that the attackers - are sufficiently motivated to mount an attack, then an - evaluation can provide assurance of the ability of the TOE - to thwart the attacker's efforts. Where the operational - environment is well defined, for example in a system - evaluation, the level of motivation for an attack may be - known, and will influence the selection of - countermeasures. - - Considering the second aspect, an asset holder may believe - that the value of the assets (however measured) is - sufficient to motivate attack against them. Once an - evaluation is deemed necessary, the attacker's motivation - is considered to determine the methods of attack that may - be attempted, as well as the expertise and resources used - in those attacks. Once examined, the developer is able to - choose the appropriate assurance level, in particular the - requirement components, - commensurate with the attack potential for the - threats. During the course of the evaluation, and in - particular as a result of completing the vulnerability - assessment activity, the evaluator determines whether or - not the TOE, operating in its operational environment, is - sufficient to thwart attackers with the identified - expertise and resources. - - It may be possible for a PP author to quantify the - motivation of an attacker, as the PP author has greater - knowledge of the operational environment in which the TOE - (conforming to the requirements of the PP) is to be - placed. Therefore, the motivation could form an explicit - part of the expression of the attack potential in the PP, - along with the necessary methods and measures to quantify - the motivation. - - - - - This section examines the factors that determine attack - potential, and provides some guidelines to help remove some - of the subjectivity from this aspect of the evaluation - process. - - - The determination of the attack potential for an attack - corresponds to the identification of the effort required to - create the attack, and to demonstrate that it can be - successfully applied to the TOE (including setting up or - building any necessary test equipment), thereby exploiting the - vulnerability in the TOE. The demonstration that the attack can - be successfully applied needs to consider any difficulties in - expanding a result shown in the laboratory to create a useful - attack. For example, where an experiment reveals some bits or - bytes of a confidential data item (such as a key), it is - necessary to consider how the remainder of the data item would - be obtained (in this example some bits might be measured - directly by further experiments, while others might be found by - a different technique such as exhaustive search). It may not be - necessary to carry out all of the experiments to identify the - full attack, provided it is clear that the attack actually - proves that access has been gained to a TOE asset, and that the - complete attack could realistically be carried out in - exploitation according to the - component targeted. In some cases the only way to prove that an - attack can realistically be carried out in exploitation - according to the component - targeted is to perform completely the attack and - then rate it based upon the resources actually required. - One of the outputs from the identification of a potential - vulnerability is assumed to be a script that gives a - step-by-step description of how to carry out the attack that can - be used in the exploitation of the vulnerability on another - instance of the TOE. - - In many cases, the evaluators will estimate the parameters - for exploitation, rather than carry out the full - exploitation. The estimates and their rationale will be - documented in the ETR. - - - - The following factors should be considered during analysis - of the attack potential required to exploit a - vulnerability: - - - Time taken to identify and exploit ( - Elapsed Time); - - - Specialist technical expertise required ( - Specialist Expertise); - - - Knowledge of the TOE design and operation ( - Knowledge of the TOE); - - - - Window of opportunity; - - - - IT hardware/software or other - equipment required for - exploitation. - - - - In many cases these factors are not independent, but may be - substituted for each other in varying degrees. For example, - expertise or hardware/software may be a substitute for time. A - discussion of these factors follows. (The levels of each factor - are discussed in increasing order of magnitude.) When it is the - case, the less ``expensive'' combination is considered in the - exploitation phase. - Elapsed time is the total amount - of time taken by an attacker to identify that a particular - potential vulnerability may exist in the TOE, to develop an - attack method and to sustain effort required to mount the attack - against the TOE. When considering this factor, the worst case - scenario is used to estimate the amount of time required. The - identified amount of time is as follows: - less than one day;between one day and one week;between one week and two weeks;between two weeks and one month;each additional month up to 6 months leads to an - increased value;more than 6 months. - - Specialist expertise refers - to the level of generic knowledge of the underlying - principles, product type or attack methods (e.g. Internet - protocols, Unix operating systems, buffer overflows). The - identified levels are as follows: - - - Laymen are unknowledgeable compared to experts or - proficient persons, with no particular expertise; - - - Proficient persons are knowledgeable in that they are - familiar with the security behaviour of the product or - system type; - - - Experts are familiar with the underlying algorithms, - protocols, hardware, structures, security behaviour, - principles and concepts of security employed, - techniques and tools for the definition of new - attacks, cryptography, classical attacks for the - product type, attack methods, etc. implemented in the - product or system type. - - - The level ``Multiple Expert'' is introduced to allow for - a situation, where different fields of expertise are - required at an Expert level for distinct steps of an - attack. - - It may occur that several types of expertise are - required. By default, the higher of the different - expertises factors is chosen. In very specific cases, the - ``multiple expert'' level could be used but it should be - noted that the expertise must concern fields that are - strictly different like for example HW manipulation and - cryptography. - - - Knowledge of the TOE refers to - specific expertise in relation to the TOE. This is - distinct from generic expertise, but not unrelated to - it. Identified levels are as follows: - - - Public information concerning the TOE (e.g. as gained - from the Internet); - - - Restricted information concerning the TOE - (e.g. knowledge that is controlled within the - developer organisation and shared with other - organisations under a non-disclosure agreement) - - - Sensitive information about the TOE (e.g. knowledge - that is shared between discreet teams within the - developer organisation, access to which is constrained - only to members of the specified teams); - - - Critical information about the TOE (e.g. knowledge - that is known by only a few individuals, access to - which is very tightly controlled on a strict need to - know basis and individual undertaking). - - - - The knowledge of the TOE may graduate according to design - abstraction, although this can only be done on a TOE by - TOE basis. Some TOE designs may be public source (or - heavily based on public source) and therefore even the - design representation would be classified as public or at - most restricted, while the implementation representation - for other TOEs is very closely controlled as it would give - an attacker information that would aid an attack and is - therefore considered to be sensitive or even - critical. - - It may occur that several types of knowledge are - required. In such cases, the higher of the different - knowledge factors is chosen. - - - Window of opportunity - - (Opportunity) is also an important consideration, and has - a relationship to the Elapsed Time - factor. Identification or exploitation of a - vulnerability may require considerable amounts of access - to a TOE that may increase the likelihood of - detection. Some attack methods may require considerable - effort off-line, and only brief access to the TOE to - exploit. Access may also need to be continuous, or over a - number of sessions. - - For some TOEs the Window of - opportunity may equate to the number of - samples of the TOE that the attacker can obtain. This is - particularly relevant where attempts to penetrate the - TOE and undermine the SFRs may result in the destruction - of the TOE preventing use of that TOE sample for further - testing, e.g. hardware devices. Often in these cases - distribution of the TOE is controlled and so the - attacker must apply effort to obtain further samples of - the TOE. - - For the purposes of this discussion: - - - unnecessary/unlimited access means that the attack - doesn't need any kind of opportunity to be realised - because there is no risk of being detected during - access to the TOE and it is no problem to access the - number of TOE samples for the attack; - - easy means that access is required for less than a day - and that the number of TOE samples required to perform - the attack is less than ten; - - moderate means that access is required for less than a - month and that the number of TOE samples required to - perform the attack is less than one hundred; - - difficult means that access is required for at least a - month or that the number of TOE samples required to - perform the attack is at least one hundred; - - none means that the opportunity window is not - sufficient to perform the attack (the length for which - the asset to be exploited is available or is sensitive - is less than the opportunity length needed to perform - the attack - for example, if the asset key is changed - each week and the attack needs two weeks); another - case is, that a sufficient number of TOE samples - needed to perform the attack is not accessible to the - attacker - for example if the TOE is a hardware and - the probability to destroy the TOE during the attack - instead of being successful is very high and the - attacker has only access to one sample of the - TOE. - - Consideration of this factor may result in determining - that it is not possible to complete the exploit, due to - requirements for time availability that are greater than - the opportunity time. - - - IT hardware/software or other equipment - refers to the equipment required to identify - or exploit a vulnerability. - - - Standard equipment is readily available to the - attacker, either for the identification of a - vulnerability or for an attack. This equipment may be - a part of the TOE itself (e.g. a debugger in an - operating system), or can be readily obtained - (e.g. Internet downloads, protocol analyser or simple - attack scripts). - - - Specialised equipment is not readily available to the attacker, - but could be acquired without undue effort. This could include - purchase of moderate amounts of equipment (e.g. power analysis - tools, use of hundreds of PCs linked across the Internet would - fall into this category), or development of more extensive - attack scripts or programs. If clearly different test benches - consisting of specialised equipment are required for distinct - steps of an attack this would be rated as bespoke. - - - Bespoke equipment is not readily available to the - public as it may need to be specially produced - (e.g. very sophisticated software), or because the - equipment is so specialised that its distribution is - controlled, possibly even restricted. Alternatively, - the equipment may be very expensive. - - The level ``Multiple Bespoke'' is introduced to allow - for a situation, where different types of bespoke - equipment are required for distinct steps of an - attack. - - Specialist expertise and Knowledge of the - TOE are concerned with the information - required for persons to be able to attack a TOE. There - is an implicit relationship between an attacker's - expertise (where the attacker may be one or more persons - with complementary areas of knowledge) and the ability - to effectively make use of equipment in an attack. The - weaker the attacker's expertise, the lower the potential - to use equipment (IT hardware/software or other - equipment). Likewise, the greater the expertise, the - greater the potential for equipment to be used in the - attack. Although implicit, this relationship between - expertise and the use of equipment does not always - apply, for instance, when environmental measures prevent - an expert attacker's use of equipment, or when, through - the efforts of others, attack tools requiring little - expertise to be effectively used are created and freely - distributed (e.g. via the Internet). - - - - Table identifies the - factors discussed in the previous section and associates - numeric values with the total value of each factor. - - Where a factor falls close to the boundary of a range the - evaluator should consider use of an intermediate value to those - in the table. For example, if twenty samples are required to - perform the attack then a value between one and four may be - selected for that factor, or if the design is based on a - publicly available design but the developer has made some - alterations then a value between zero and three should be - selected according to the evaluator's view of the impact of - those design changes. The table is intended as a guide. - - The ``**'' specification in the table in considering - Window of Opportunity is not - to be seen as a natural progression from the timescales - specified in the preceding ranges associated with this - factor. This specification identifies that for a - particular reason the potential vulnerability cannot be - exploited in the TOE in its intended operational - environment. For example, access to the TOE may be - detected after a certain amount of time in a TOE with a - known environment (i.e. in the case of a system) where - regular patrols are completed, and the attacker could not - gain access to the TOE for the required two weeks - undetected. However, this would not be applicable to a TOE - connected to the network where remote access is possible, - or where the physical environment of the TOE is - unknown. - - - - - - Factor - - - Value - - - - - - - Elapsed Time - - - - - - <= one day - - 0 - - - - <= one week - - 1 - - - - <= two weeks - - 2 - - - - <= one month - - 4 - - - - <= two months - - 7 - - - - <= three months - - 10 - - - - <= four months - - 13 - - - - <= five months - - 15 - - - - <= six months - - 17 - - - - > six months - - 19 - - - - Expertise - - - - - - Layman - - 0 - - - - Proficient - - - 3*When several proficient persons are - required to complete the attack path, the - resulting level of expertise still remains - ``proficient'' (which leads to a 3 - rating). - - - - Expert - - 6 - - - - Multiple experts - - 8 - - - - Knowledge of TOE - - - - - - Public - - 0 - - - - Restricted - - 3 - - - - Sensitive - - 7 - - - - Critical - - 11 - - - - Window of Opportunity - - - - - - Unnecessary / unlimited access - - 0 - - - - Easy - - 1 - - - - Moderate - - 4 - - - - Difficult - - 10 - - - - None - - - **Indicates that the attack path is not - exploitable due to other measures in the - intended operational environment of the - TOE. - - - - - Equipment - - - - - - Standard - - 0 - - - - Specialised - - 4If clearly different test benches - consisting of specialised equipment are required - for distinct steps of an attack, this should be - rated as bespoke. - - - - Bespoke - - 7 - - - - Multiple bespoke - - 9 - - - - - Calculation of attack potential -
- - To determine the resistance of the TOE to the potential - vulnerabilities identified the following steps should be - applied: - - - Define the possible attack scenarios {AS1, AS2, ..., - ASn} for the TOE in the operational - environment. - - For each attack scenario, perform a theoretical - analysis and calculate the relevant attack potential - using Table . - - For each attack scenario, if necessary, perform - penetration tests in order to confirm or to disprove - the theoretical analysis. - - Divide all attack scenarios {AS1, AS2, ..., ASn} into - two groups: - - - the attack scenarios having been successful - (i.e. those that have been used to successfully - undermine the SFRs), and - - the attack scenarios that have been demonstrated - to be unsuccessful. - - - - For each successful attack scenario, apply Table and determine, whether - there is a contradiction between the resistance of the - TOE and the chosen - assurance component, see the last column of Table . - - Should one contradiction be found, the vulnerability - assessment will fail, e.g. the author of the ST chose - the component and an - attack scenario with an attack potential of 21 points - (high) has broken the security of the TOE. In this - case the TOE is resistant to attacker with attack - potential 'Moderate', this contradicts to , hence, the vulnerability - assessment fails. - - The ``Values'' column of Table indicates the range of attack potential values - (calculated using Table ) of an - attack scenario that results in the SFRs being - undermined. - - - - - - Values - - - Attack potential required to exploit scenario: - - - TOE resistant to attackers with attack potential - of: - - - Meets assurance components:: - - - Failure of components: - - - - - - - 0-9 - - Basic - - No rating - - - - - , , , , - - - - - 10-13 - - Enhanced-Basic - - Basic - - , - - , , - - - - 14-19 - - Moderate - - Enhanced-Basic - - , , - - , - - - - 20-24 - - High - - Moderate - - , , , - - - - - - =>25 - - Beyond High - - High - - , , , , - - - - - - - - Rating of vulnerabilities and TOE - resistance -
- - An approach such as this cannot take account of every - circumstance or factor, but should give a better - indication of the level of resistance to attack required - to achieve the standard ratings. Other factors, such as - the reliance on unlikely chance occurrences are not - included in the basic model, but can be used by an - evaluator as justification for a rating other than those - that the basic model might indicate. - - It should be noted that whereas a number of - vulnerabilities rated individually may indicate high - resistance to attack, collectively the combination of - vulnerabilities may indicate that overall a lower rating - is applicable. The presence of one vulnerability may make - another easier to exploit. - - If a PP/ST author wants to use the attack potential table for - the determination of the level of attack the TOE should - withstand (selection of Vulnerability analysis () component), he should proceed as - follows: For all different attack scenarios (i.e. for all - different types of attacker and/or different types of attack the - author has in mind) which must not violate the SFRs, several - passes through Table should be - made to determine the different values of attack potential - assumed for each such unsuccessful attack scenario. The PP/ST - author then chooses the highest value of them in order to - determine the level of the TOE resistance to be claimed from - Table : the TOE resistance must - be at least equal to this highest value determined. For - example, the highest value of attack potentials of all attack - scenarios, which must not undermine the TOE security policy, - determined in such a way is Moderate; hence, the TOE resistance - shall be at least Moderate (i.e. Moderate or High); therefore, - the PP/ST author can choose either (for Moderate) or - (for High) as the appropriate assurance component. - - - - - - - - Mechanisms subject to direct attack are often vital for system - security and developers often strengthen these mechanisms. As - an example, a TOE might use a simple pass number - authentication mechanism that can be overcome by an attacker - who has the opportunity to repeatedly guess another user's - pass number. The system can strengthen this mechanism by - restricting pass numbers and their use in various ways. During - the course of the evaluation an analysis of this direct attack - could proceed as follows: - - Information gleaned from the ST and design evidence reveals - that identification and authentication provides the basis upon - which to control access to network resources from widely - distributed terminals. Physical access to the terminals is not - controlled by any effective means. The duration of access to a - terminal is not controlled by any effective means. Authorised - users of the system choose their own pass numbers when - initially authorised to use the system, and thereafter upon - user request. The system places the following restrictions on - the pass numbers selected by the user: - - - the pass number must be at least four and no greater than - six digits long; - - - consecutive numerical sequences are disallowed (such as - 7,6,5,4,3); - - - repeating digits is disallowed (each digit must be - unique). - - - - Guidance provided to the users at the time of pass number - selection is that pass numbers should be as random as possible - and should not be affiliated with the user in some way - a - date of birth, for instance. - - The pass number space is calculated as follows: - - - Patterns of human usage are important considerations that - can influence the approach to searching a password - space. Assuming the worst case scenario and the user - chooses a number comprising only four digits, the number - of pass number permutations assuming that each digit must - be unique is: - - - The number of possible increasing sequences is seven, as - is the number of decreasing sequences. The pass number - space after disallowing sequences is: - - - - Based on further information gleaned from the design evidence, - the pass number mechanism is designed with a terminal locking - feature. Upon the sixth failed authentication attempt the - terminal is locked for one hour. The failed authentication - count is reset after five minutes so that an attacker can at - best attempt five pass number entries every five minutes, or - 60 pass number entries every hour. - - On average, an attacker would have to enter 2513 pass numbers, - over 2513 minutes, before entering the correct pass number. The - average successful attack would, as a result, occur in slightly - less than: - - Using the approach to calculate the attack potential, described - in the previous section, identifies that it is possible that a - layman can defeat the mechanism within days (given easy access - to the TOE), with the use of standard equipment, and with no - knowledge of the TOE, giving a value of 1. Given the resulting - sum, 1, the attack potential required to effect a successful - attack is not rated, as it falls below that considered to be - Basic. - - - - - Table describes the - relationship between the composition assurance levels and the - assurance classes, families and components. - - - - The Composed Assurance Packages (CAPs) provide an increasing - scale that balances the level of assurance obtained with the - cost and feasibility of acquiring that degree of assurance for - composed TOEs. - - It is important to note that there are only a small number of - families and components from CC Part 3 included in the - CAPs. This is due to their nature of building upon evaluation - results of previously evaluated entities (base components and - dependent components), and is not to say that these do not - provide meaningful and desirable assurances. - - - CAPs are to be applied to composed TOEs, which are comprised - of components that have been (are going through) component TOE - evaluation (see ). The - individual components will have been certified to an EAL or - another assurance package specified in the ST. It is expected - that a basic level of assurance in a composed TOE will be - gained through application of EAL1, which can be achieved with - information about the components that is generally available - in the public domain. (EAL1 can be applied as specified - within to both component and composed TOEs.) CAPs provide an - alternative approach to obtaining higher levels of assurance - for a composed TOE than application of the EALs above - EAL1. - - While a dependent component can be evaluated using a - previously evaluated and certified base component to satisfy - the IT platform requirements in the environment, this does not - provide any formal assurance of the interactions between the - components or the possible introduction of vulnerabilities - resulting from the composition. Composed assurance packages - consider these interactions and, at higher levels of - assurance, ensure that the interface between the components - has itself been the subject of testing. A vulnerability - analysis of the composed TOE is also performed to consider the - possible introduction of vulnerabilities as a result of - composing the components. - - Table represents a summary - of the CAPs. The columns represent a hierarchically ordered - set of CAPs, while the rows represent assurance families. Each - number in the resulting matrix identifies a specific assurance - component where applicable. - - As outlined in the next Subclause, three hierarchically - ordered composed assurance packages are defined in the CC for - the rating of a composed TOE's assurance. They are - hierarchically ordered inasmuch as each CAP represents more - assurance than all lower CAPs. The increase in assurance from - CAP to CAP is accomplished by substitution of a hierarchically - higher assurance component from the same assurance family - (i.e. increasing rigour, scope, and/or depth) and from the - addition of assurance components from other assurance families - (i.e. adding new requirements). These increases result in - greater analysis of the composition to identify the impact on - the evaluation results gained for the individual component - TOEs. - - These CAPs consist of an appropriate combination of assurance - components as described in Clause of this CC Part 3. More - precisely, each CAP includes no more than one component of - each assurance family and all assurance dependencies of every - component are addressed. - - The CAPs only consider resistance against an attacker with an - attack potential up to Enhanced-Basic. This is due to the level - of design information that can be provided through the , limiting some of the factors - associated with attack potential (knowledge of the composed TOE) - and subsequently affecting the rigour of vulnerability analysis - that can be performed by the evaluator. Therefore, the level of - assurance in the composed TOE is limited, although the assurance - in the individual components within the composed TOE may be much - higher. -
- - - - The following Subclauses provide definitions of the CAPs, - highlighting differences between the specific requirements and - the prose characterisations of those requirements using bold - type. - - - - - - Unlike the CC, where each element maintains the last digit of - its identifying symbol for all components within the family, - the CEM may introduce new work units when a CC evaluator - action element changes from sub-activity to sub-activity; as a - result, the last digit of the work unit's identifying symbol - may change although the work unit remains unchanged. - - Any methodology-specific evaluation work required that is not - derived directly from CC requirements is termed - task or sub-task. - - - - All work unit and sub-task verbs are preceded by the auxiliary - verb shall and by presenting both the verb - and the shall in - - bold italic type face. The - auxiliary verb shall is used only when the - provided text is mandatory and therefore only within the work - units and sub-tasks. The work units and sub-tasks contain - mandatory activities that the evaluator must perform in order - to assign verdicts. - - Guidance text accompanying work units and sub-tasks gives - further explanation on how to apply the CC words in an - evaluation. The verb usage is in accordance with ISO - definitions for these verbs. The auxiliary verb - should is used when the described method is - strongly preferred. All other auxiliary verbs, including - may, are used where the described method(s) - is allowed but is neither recommended nor strongly preferred; - it is merely explanation. - - The verbs check, examine, - report and record are used - with a precise meaning within this part of the CEM and the - Clause should be - referenced for their definitions. - - - - Material that has applicability to more than one sub-activity - is collected in one place. Guidance whose applicability is - widespread (across activities and EALs) has been collected - into . Guidance that - pertains to multiple sub-activities within a single activity - has been provided in the introduction to that activity. If - guidance pertains to only a single sub-activity, it is - presented within that sub-activity. - - - - There are direct relationships between the CC structure - (i.e. class, family, component and element) and the structure - of the CEM. Figure illustrates the correspondence - between the CC constructs of class, family and evaluator - action elements and CEM activities, sub-activities and - actions. However, several CEM work units may result from the - requirements noted in CC developer action and content and - presentation elements.
- - - - For the purposes of this document, the following terms and - definitions apply. - Terms which are presented in bold-faced type are themselves - defined in this Subclause. - action - - evaluator action element of the CC Part 3 - - These actions are either explicitly stated as evaluator - actions or implicitly derived from developer actions (implied - evaluator actions) within the CC Part 3 assurance components. - - activity - - application of an assurance class of the CC Part 3 - - check - - generate a verdict by a simple comparison - - Evaluator expertise is not required. The statement - that uses this verb describes what is mapped. - - evaluation deliverable - - any resource required from the sponsor or developer by the - evaluator or evaluation authority to perform one or more evaluation or - evaluation oversight activities - - evaluation evidence - tangible evaluation deliverable - evaluation technical report - - report that documents the overall verdict and its - justification, produced by the evaluator and submitted to an - evaluation authority - examine - - generate a verdict by analysis using - evaluator expertise - - The statement that uses this verb identifies what is analysed - and the properties for which it is analysed. - - interpretation - clarification or amplification of a CC, CEM or - scheme requirement - methodology - - system of principles, procedures and processes applied to IT - security evaluations - - observation report - - report written by the evaluator requesting a clarification - or identifying a problem during the evaluation - - overall verdict - pass or fail statement issued by an - evaluator with respect to the result of an - evaluation - - oversight verdict - - statement issued by an evaluation authority confirming or - rejecting an overall verdict based on the - results of evaluation oversight activities - - record - - retain a written description of procedures, events, - observations, insights and results in sufficient detail to - enable the work performed during the evaluation to be - reconstructed at a later time - - report - - include evaluation results and supporting material in the - Evaluation Technical Report or an - Observation Report - scheme - - set of rules, established by an evaluation authority, - defining the evaluation environment, including criteria and - methodology required to conduct IT security - evaluations - - sub-activity - - application of an assurance component of the CC Part 3 - - Assurance families are not explicitly addressed in the CEM - because evaluations are conducted on a single assurance - component from an assurance family. - - tracing - - simple directional relation between two sets of - entities, which shows which entities in the first set - correspond to which entities in the second - - verdict - pass, fail or inconclusive statement issued - by an evaluator with respect to a CC evaluator action element, - assurance component, or class - - Also see overall verdict. - - work unit - - most granular level of evaluation work - - Each CEM action comprises one or more work units, which are - grouped within the CEM action by CC content and presentation - of evidence or developer action element. The work units are - presented in the CEM in the same order as the CC elements - from which they are derived. Work units are identified in - the left margin by a symbol such as . In this symbol, the - string - indicates the CC component (i.e. the CEM sub-activity), and - the final digit (2) indicates that this is - the second work unit in the - sub-activity. - - - - The target audience for the Common Methodology for Information - Technology Security Evaluation (CEM) is primarily evaluators - applying the CC and certifiers confirming evaluator actions; - evaluation sponsors, developers, PP/ST authors and other parties - interested in IT security may be a secondary audience. - - The CEM recognises that not all questions concerning IT security - evaluation will be answered herein and that further - interpretations will be needed. Individual schemes will - determine how to handle such interpretations, although these may - be subject to mutual recognition agreements. A list of - methodology-related activities that may be handled by individual - schemes can be found in . - - - - - Clause defines the - conventions used in the CEM. - - Clause - describes general evaluation tasks with no verdicts associated - with them as they do not map to CC evaluator action - elements. - - Clause addresses the work - necessary for reaching an evaluation result on a PP. - - Clauses to define the evaluation activities, organised by - Assurance Classes. - - covers the basic - evaluation techniques used to provide technical evidence of - evaluation results. - - provides an explanation - of the Vulnerability Analysis criteria and examples of their - application - - - - - The following referenced documents are indispensable for the - application of this document. For dated references, only the - edition cited applies. For undated references, the latest - edition of the referenced document (including any amendments) - applies. - - CC - - Common Criteria for Information Technology Security - Evaluation, Version _CCVERSION_, revision _CCREVISION_, - _CCDATE_. - - - - - - The Common Methodology for Information Technology Security - Evaluation (CEM) is a companion document to the Common Criteria - for Information Technology Security Evaluation (CC). The CEM - defines the minimum actions to be performed by an evaluator in - order to conduct a CC evaluation, using the criteria and - evaluation evidence defined in the CC. - The CEM does not define evaluator actions for certain high - assurance CC components, where there is as yet no generally - agreed guidance. - - - - CEM - - Common Methodology for Information Technology Security - Evaluation - - - - ETR - - Evaluation Technical Report - - - - OR - - Observation Report - - - - - - - Table describes the - relationship between the evaluation assurance levels and the - assurance classes, families and components.
- - - - The Evaluation Assurance Levels (EALs) provide an increasing - scale that balances the level of assurance obtained with the - cost and feasibility of acquiring that degree of assurance. The - CC approach identifies the separate concepts of assurance in a - TOE at the end of the evaluation, and of maintenance of that - assurance during the operational use of the TOE. - - It is important to note that not all families and components - from CC Part 3 are included in the EALs. This is not to say that - these do not provide meaningful and desirable - assurances. Instead, it is expected that these families and - components will be considered for augmentation of an EAL in - those PPs and STs for which they provide utility. - - - Table represents a summary - of the EALs. The columns represent a hierarchically ordered - set of EALs, while the rows represent assurance families. Each - number in the resulting matrix identifies a specific assurance - component where applicable. - - As outlined in the next Subclause, seven hierarchically - ordered evaluation assurance levels are defined in the CC for - the rating of a TOE's assurance. They are hierarchically - ordered inasmuch as each EAL represents more assurance than - all lower EALs. The increase in assurance from EAL to EAL is - accomplished by substitution of a hierarchically higher - assurance component from the same assurance family - (i.e. increasing rigour, scope, and/or depth) and from the - addition of assurance components from other assurance families - (i.e. adding new requirements). - - These EALs consist of an appropriate combination of assurance - components as described in Clause of this CC Part 3. More - precisely, each EAL includes no more than one component of - each assurance family and all assurance dependencies of every - component are addressed. - - While the EALs are defined in the CC, it is possible to - represent other combinations of assurance. Specifically, the - notion of ``augmentation'' allows the addition of assurance - components (from assurance families not already included in - the EAL) or the substitution of assurance components (with - another hierarchically higher assurance component in the same - assurance family) to an EAL. Of the assurance constructs - defined in the CC, only EALs may be augmented. The notion of - an ``EAL minus a constituent assurance component'' is not - recognised by the standard as a valid claim. Augmentation - carries with it the obligation on the part of the claimant to - justify the utility and added value of the added assurance - component to the EAL. An EAL may also be augmented with - extended assurance requirements. -
- - - - The following Subclauses provide definitions of the EALs, - highlighting differences between the specific requirements and - the prose characterisations of those requirements using bold - type. - - - - - - The objective of this clause is to cover general guidance - used to provide technical evidence of evaluation results. The - use of such general guidance helps in achieving objectivity, - repeatability and reproducibility of the work performed by the - evaluator. - - - - This Subclause provides general guidance on sampling. Specific - and detailed information is given in those work units under - the specific evaluator action elements where sampling has to - be performed. - - Sampling is a defined procedure of an evaluator whereby some - subset of a required set of evaluation evidence is examined - and assumed to be representative for the entire set. It allows - the evaluator to gain enough confidence in the correctness of - particular evaluation evidence without analysing the whole - evidence. The reason for sampling is to conserve resources - while maintaining an adequate level of assurance. Sampling of - the evidence can provide two possible outcomes: - - - The subset reveals no errors, allowing the evaluator to - have some confidence that the entire set is correct. - - - The subset reveals errors and therefore the validity of - the entire set is called into question. Even the - resolution of all errors that were found may be - insufficient to provide the evaluator the necessary - confidence and as a result the evaluator may have to - increase the size of the subset, or stop using sampling - for this particular evidence. - - - - Sampling is a technique which can be used to reach a reliable - conclusion if a set of evidence is relatively homogeneous in - nature, e.g. if the evidence has been produced during a well - defined process. - - Sampling in the cases identified in the CC, and in cases - specifically covered in CEM work items, is recognised as a - cost-effective approach to performing evaluator - actions. Sampling in other areas is permitted only in - exceptional cases, where performance of a particular activity - in its entirety would require effort disproportionate to the - other evaluation activities, and where this would not add - correspondingly to assurance. In such cases a rationale for - the use of sampling in that area will need to be made. Neither - the fact that the TOE is large and complex, nor that it has - many security functional requirements, is sufficient - justification, since evaluations of large, complex TOEs can be - expected to require more effort. Rather it is intended that - this exception be limited to cases such as that where the TOE - development approach yields large quantities of material for a - particular CC requirement that would normally all need to be - checked or examined, and where such an action would not be - expected to raise assurance correspondingly. - - Sampling needs to be justified taking into account the - possible impact on the security objectives and threats of the - TOE. The impact depends on what might be missed as a result of - sampling. Consideration also needs to be given to the nature - of the evidence to be sampled, and the requirement not to - diminish or ignore any security functions. - - It should be recognised that sampling of evidence directly - related to the implementation of the TOE (e.g. developer test - results) requires a different approach to sampling, then - sampling related to the determination of whether a process is - being followed. In many cases the evaluator is required to - determine that a process is being followed, and a sampling - strategy is recommended. The approach for sampling a - developer's test results will differ. This is because the - former case is concerned with ensuring that a process is in - place, and the latter deals with determining correct - implementation of the TOE. Typically, larger sample sizes - should be analysed in cases related to the correct - implementation of the TOE than would be necessary to ensure - that a process is in place. - - In certain cases it may be appropriate for the evaluator to - give greater emphasis to the repetition of developer - testing. For example if the independent tests left for the - evaluator to perform would be only superficially different - from those included in an extensive developer test set - (possibly because the developer has performed more testing - than necessary to satisfy the - and criteria) then it would - be appropriate for the evaluator to give greater focus to the - repetition of developer tests. Note that this does not - necessarily imply a requirement for a high percentage sample - for repetition of developer tests; indeed, given an extensive - developer test set, the evaluator may be able to justify a low - percentage sample. - - Where the developer has used an automated test suite to - perform functional testing, it will usually be easier for the - evaluator to re-run the entire test suite rather than repeat - only a sample of developer tests. However the evaluator does - have an obligation to check that the automatic testing does - not give misrepresentative results. The implication is thus - that this check must be performed for a sample of the - automatic test suite, with the principles for selecting some - tests in preference to others and ensuring a sufficient sample - size applying equally in this case. - - The following principles should be followed whenever sampling - is performed: - - - Sampling should not be random, rather it should be chosen - such that it is representative of all of the evidence. The - sample size and composition must always be justified. - - - When sampling relates to the correct implementation of the - TOE, the sample should be representative of all aspects - relevant to the areas that are sampled. In particular, the - selection should cover a variety of components, - interfaces, developer and operational sites (if more than - one is involved) and hardware platform types (if more than - one is involved). The sample size should be commensurate - with the cost effectiveness of the evaluation and will - depend on a number of TOE dependent factors (e.g. the size - and complexity of the TOE, the amount of documentation). - - - Also, when sampling relates to specifically gaining - evidence that the developer testing is repeatable and - reproducible the sample used must be sufficient to - represent all distinct aspects of developer testing, such - as different test regimes. The sample used must be - sufficient to detect any systematic problem in the - developer's functional testing process. The evaluator - contribution resulting from the combination of repeating - developer tests and performing independent tests must be - sufficient to address the major points of concern for the - TOE. - - - Where sampling relates to gaining evidence that a process - (e.g. visitor control or design review) the evaluator - should sample sufficient information to gain reasonable - confidence that the procedure is being followed. - - - The sponsor and developer should not be informed in - advance of the exact composition of the sample, subject to - ensuring timely delivery of the sample and supporting - deliverable, e.g. test harnesses and equipment to the - evaluator in accordance with the evaluation schedule. - - - The choice of the sample should be free from bias to the - degree possible (one should not always choose the first or - last item). Ideally the sample selection should be done by - someone other than the evaluator. - - - - Errors found in the sample can be categorised as being either - systematic or sporadic. If the error is systematic, the - problem should be corrected and a complete new sample - taken. If properly explained, sporadic errors might be solved - without the need for a new sample, although the explanation - should be confirmed. The evaluator should use judgement in - determining whether to increase the sample size or use a - different sample. - - - - In general it is possible to perform the required evaluation - activities, sub-activities, and actions in any order or in - parallel. However, there are different kinds of dependencies - which have to be considered by the evaluator. This Subclause - provides general guidance on dependencies between different - activities, sub-activities, and actions. - - - For some cases the different assurance classes may recommend - or even require a sequence for the related activities. A - specific instance is the ST activity. The ST evaluation - activity is started prior to any TOE evaluation activities - since the ST provides the basis and context to perform - them. However, a final verdict on the ST evaluation may not - be possible until the TOE evaluation is complete, since - changes to the ST may result from activity findings during - the TOE evaluation. - - - - Dependencies identified between components in CC Part 3 have - to be considered by the evaluator. Most dependencies are - one way, e.g. claims a - dependency on and . There are also instances of - mutual dependencies, where both components depend on each - other. An example of this is and . - - A sub-activity can be assigned a pass verdict normally only - if all those sub-activities are successfully completed on - which it has a one-way dependency. For example, a pass - verdict on can normally - only be assigned if the sub-activities related to and are assigned a pass verdict too. In the case - of mutual dependency the ordering of these components is - down to the evaluator deciding which sub-activity to perform - first. Note this indicates that pass verdicts can normally - only be assigned once both sub-activities have been - successful. - - So when determining whether a sub-activity will impact - another sub-activity, the evaluator should consider whether - this activity depends on potential evaluation results from - any dependent sub-activities. Indeed, it may be the case - that a dependent sub-activity will impact this sub-activity, - requiring previously completed evaluator actions to be - performed again. - - A significant dependency effect occurs in the case of - evaluator-detected flaws. If a flaw is identified as a - result of conducting one sub-activity, the assignment of a - pass verdict to a dependent sub-activity may not be possible - until all flaws related to the sub-activity upon which it - depends are resolved. - - - - It may be the case, that results which are generated by the - evaluator during one action are used for performing another - action. For example, actions for completeness and - consistency cannot be completed until the checks for content - and presentation have been completed. This means for example - that the evaluator is recommended to evaluate the PP/ST - rationale after evaluating the constituent parts of the - PP/ST. - - - - - - The assurance class includes - requirements for - - - the application of configuration management, ensuring - that the integrity of the TOE is preserved; - - - measures, procedures, and standards concerned with - secure delivery of the TOE, ensuring that the security - protection offered by the TOE is not compromised during - the transfer to the user, - - - security measures, used to protect the development - environment. - - - - A development site visit is a useful means whereby the - evaluator determines whether procedures are being followed - in a manner consistent with that described in the - documentation. - - Reasons for visiting sites include: - - - to observe the use of the CM system as described in the - CM plan; - - - to observe the practical application of delivery - procedures as described in the delivery documentation; - - - to observe the application of security measures during - development and maintenance of the TOE as described in - the development security documentation. - - - - Specific and detailed information is given in work units for - those activities where site visits are performed: - - - .n with n>=3 - (especially work unit = = ); - - - (especially work unit - ); - - - (especially work unit - = ). - - - - - - During an evaluation it is often necessary that the - evaluator will meet the developer more than once and it is a - question of good planning to combine the site visit with - another meeting to reduce costs. For example one might - combine the site visits for configuration management, for - the developer's security and for delivery. It may also be - necessary to perform more than one site visit to the same - site to allow the checking of all development phases. It - should be considered that development could occur at - multiple facilities within a single building, multiple - buildings at the same site, or at multiple sites. - - The first site visit should be scheduled early during the - evaluation. In the case of an evaluation which starts during - the development phase of the TOE, this will allow corrective - actions to be taken, if necessary. In the case of an - evaluation which starts after the development of the TOE, an - early site visit could allow corrective measures to be put - in place if serious deficiencies in the applied procedures - emerge. This avoids unnecessary evaluation effort. - - Interviews are also a useful means of determining whether the - written procedures reflect what is done. In conducting such - interviews, the evaluator aims to gain a deeper understanding of - the analysed procedures at the development site, how they are - used in practise and whether they are being applied as described - in the provided evaluation evidence. Such interviews complement - but do not replace the examination of evaluation - evidence. - - As a first step preparing the site visits the evaluators - should perform the evaluator work units concerning the - assurance class excluding the - aspects describing the results of the site visit. Based on - the information provided by the relevant developer - documentation and the remaining open questions which were - not answered by the documentation the evaluators compile a - check list of the questions which are to be resolved by the - site visits. - - The first version of the evaluation report concerning the - class and the check list serves - as input for the consultation with the evaluation authority - concerning the site visits. - - The check list serve as a guide line for the site visits, - which questions are to be answered by inspection of the - relevant measures, their application and results, and by - interviews. Where appropriate, sampling is used for gaining - the required level of confidence (see Subclause ). - - The results of the site visits are recorded and serve as - input for the final version of the evaluation report - concerning the assurance class . - - Other approaches to gain confidence should be considered - that provide an equivalent level of assurance (e.g. to - analyse evaluation evidence). Any decision not to make a - visit should be determined in consultation with the - evaluation authority. Appropriate security criteria and a - methodology should be based on other standards of the - Information Security Management Systems area. - - - - In the following some keywords are provided, which topics - should be checked during an audit. - - Basic - - - Items of the configuration list, including TOE, source - code, run time libraries, design documentation, - development tools (). - - - Tracking of design documentation, source code, user - guidance to different versions of the TOE. - - - Integration of the configuration system in the design - and development process, test planning, test analysis - and quality management procedures. - - - - Test analysis - - - Tracking of test plans and results to specific - configurations and versions of the TOE. - - - - Access control to development systems - - - Policies for access control and logging. - - - Policies for project specific assignment and changing - of access rights. - - - - Clearance - - - Policies for clearance of the TOE and user guidance to - the customer. - - - Policies for testing and approving of components and - the TOE before deployment. - - - - - - Infrastructure - - - Security measures for physical access control to the - development site and rationale for the effectiveness - of these measures. - - - - Organisational measures - - - Organisational structure of the company in respect of - the security of the development environment. - - - Organisational separation between development, - production, testing and quality assurance. - - - - Personal measures - - - Measures for education of the personnel in respect of - development security. - - - Measures and legal agreements of non disclosure of - internal information. - - - - Access control - - - Assignment of secured objects (for instance TOE, - source code, run time libraries, design documentation, - development tools, user guidance) and security - policies. - - - Policies and responsibilities concerning the access - control and the handling of authentication - information. - - - Policies for logging of any kind access to the - development site and protection of the logging data. - - - - Input, processing and output of data - - - Security measures for protection of output and output - devices (printer, plotter and displays). - - - Securing of local networks and communication - connections. - - - - Storage, transfer and destruction of documents and data - media. - - - Policies for handling of documents and data media. - - - Policies and responsibilities for destruction of - sorted out documents and logging of these events. - - - - Data protection - - - Policies and responsibilities for data and information - protection (e.g. for performing backups). - - - - Contingency plan - - - Practises in case of emergency and responsibilities. - - - Documentation of the contingency measures concerning - access control. - - - Information of the personnel about applicable - practises in extreme cases. protection (e.g. for - performing backups). - - - - - - - The examples of checklists for site visits consist in tables - for the preparation of an audit and for the presentation of - the results of an audit. - - The checklist structure given in the following is - preliminary. Dependent on the concrete contents of the new - guideline, changes might become necessary. - The checklist is divided into three subclauses according - to the subjects indicated in the introduction (Subclause ). - - - Configuration management system. - - - Delivery procedures. - - - Security measures during development. - - - These subclauses correspond to the actual CC class , especially the families .n with n>=3, and . - The subclauses are subdivided further into rows - corresponding to the relevant work units of the CEM. - - The columns of the checklist contain in turn - - - a consecutive number, - - - the referenced work unit, - - - the references to the corresponding developer - documentation, - - - the explicit reproduction of the developer measures, - - - special remarks and questions to be clarified on the - visit (beyond the standard evaluator task to verify the - application of the indicated measures), - - - the result of the examinations during the visit. - - - If it is decided to have separate checklists for - preparation and reporting of the audit, the result column is - omitted in the preparation list and the remarks and - questions column is omitted in the reporting list. The - remaining columns should be identical in both lists. -
- - Example of a checklist at EAL 4 (extract) - - - - - - A. Examination of the CM system ( and ) - - - - - No. - - - Work Unit - - - Developer Documentation - - - Measures - - - Questions and Remarks - - - Result - - - - - - - A.1 - - - , - - - - ``Configuration Management System'', ch. ... - - - The system automatically managing the source code - files is capable of administering user profiles and - graded access rights, and of checking identification - and authentication of users. - - - Does reading or updating of a source code file - require a user authentication? - - - If a user has not the right to access a confidential - document, it is not even displayed to him in the - file list. - - - - - ... - - - ... - - - ... - - - ... - - - ... - - - ... - - - - - - - - - B. Examination of the Delivery Procedures () - - - - - No. - - - Work Unit - - - Developer Documentation - - - Measures - - - Questions and Remarks - - - Result - - - - - - - B.1 - - - , - - - - ``Delivery of the TOE'', ch. ... - - - The software is transmitted PGP-signed and encrypted - to the customer. - - - --- - - - The evaluators have checked the process and found it - as described, additionally a checksum is - transmitted. - - - - - ... - - - ... - - - ... - - - ... - - - ... - - - ... - - - - - - - - - C. Examination of the organisational and - infrastructural developer security - (, - , - ) - - - - - No. - - - Work Unit - - - Developer Documentation - - - Measures - - - Questions and Remarks - - - Result - - - - - - - C.1 - - - , - - - - ``Security of the development environment'', - ch. ... (Premises) - - - The premises are protected by security fencing. - - - Is the fencing sufficiently strong and high to - prevent an easy intrusion into the premises? - - - The evaluators considered the fencing to be - sufficiently strong and high. - - - - - C.2 - - - , - - - - ``Security of the development environment'', - ch. ... (Building) - - - The building has the following access possibilities: - The main entrance which is surveyed by the reception - and is closed if the reception is not manned. And an - access in the goods reception which is secured by - two roller shutters. - - - Is the listing of the access possibilities complete? - - - Beyond the indicated access possibilities, there is - an emergency exit that cannot be opened from the - outside. The roller shutters mentioned before can be - operated only from inside. - - - - - ... - - - ... - - - ... - - - ... - - - ... - - - ... - - - - -
- - - - - This CEM describes the minimum technical work that evaluations - conducted under oversight (scheme) bodies must - perform. However, it also recognises (both explicitly and - implicitly) that there are activities or methods upon which - mutual recognition of evaluation results do not rely. For the - purposes of thoroughness and clarity, and to better delineate - where the CEM ends and an individual scheme's methodology - begins, the following matters are left up to the discretion of - the schemes. Schemes may choose to provide the following, - although they may choose to leave some unspecified. (Every - effort has been made to ensure this list is complete; - evaluators encountering a subject neither listed here nor - addressed in the CEM should consult with their evaluation - schemes to determine under whose auspices the subject - falls.) - - The matters that schemes may choose to specify include: - - - what is required in ensuring that an evaluation was done - sufficiently - every scheme has a means of verifying the - technical competence, understanding of work and the work - of its evaluators, whether by requiring the evaluators to - present their findings to the oversight body, by requiring - the oversight body to redo the evaluator's work, or by - some other means that assures the scheme that all - evaluation bodies are adequate and comparable; - - - process for disposing of evaluation evidence upon - completion of an evaluation; - - - any requirements for confidentiality (on the part of the - evaluator and the non-disclosure of information obtained - during evaluation); - - - the course of action to be taken if a problem is - encountered during the evaluation (whether the evaluation - continues once the problem is remedied, or the evaluation - ends immediately and the remedied product must be - re-submitted for evaluation); - - - any specific (natural) language in which documentation - must be provided; - - - any recorded evidence that must be submitted in the ETR - - this CEM specifies the minimum to be reported in an ETR; - however, individual schemes may require additional - information to be included; - - - any additional reports (other than the ETR) required from - the evaluators -for example, testing reports; - - - any specific ORs that may be required by the scheme, - including the structure, recipients, etc. of any such ORs; - - - any specific content structure of any written report as a - result from an ST evaluation - a scheme may have a - specific format for all of its reports detailing results - of an evaluation, be it the evaluation of a TOE or of an - ST; - - - any additional PP/ST identification information required; - - - any activities to determine the suitability of - explicitly-stated requirements in an ST; - - - any requirements for provision of evaluator evidence to - support re-evaluation and re-use of evidence; - - - any specific handling of scheme identifiers, logos, - trademarks, etc.; - - - any specific guidance in dealing with cryptography; - - - handling and application of scheme, national and - international interpretations; - - - a list or characterisations of suitable alternative - approaches to testing where testing is infeasible; - - - the mechanism by which an evaluation authority can determine what - steps an evaluator took while testing; - - - preferred test approach (if any): at internal interface or - at external interface; - - - a list or characterisation of acceptable means of - conducting the evaluator's vulnerability analysis - (e.g. flaw hypothesis methodology); - - - information regarding any vulnerabilities and weaknesses - to be considered. - - - - - - - - The following annexes through provide the application notes for the functional - classes defined in the main body of this part of the CC. - - - For the purposes of this document, the terms, definitions, - symbols and abbreviated terms given in CC Part 1 apply. - - - Security functional components, as defined in this CC Part 2, are - the basis for the security functional requirements expressed in a - Protection Profile (PP) or a Security Target (ST). These - requirements describe the desired security behaviour expected of a - Target of Evaluation (TOE) and are intended to meet the security - objectives as stated in a PP or an ST. These requirements describe - security properties that users can detect by direct interaction - (i.e. inputs, outputs) with the IT or by the IT response to - stimulus. - - Security functional components express security requirements - intended to counter threats in the assumed operating environment - of the TOE and/or cover any identified organisational security - policies and assumptions. - - The audience for this CC Part 2 includes consumers, developers, - and evaluators of secure IT products. CC Part 1 - Chapter provides additional - information on the target audience of the CC, and on the use of - the CC by the groups that comprise the target audience. These - groups may use this part of the CC as follows: - - - Consumers, who use this CC Part 2 when selecting components to - express functional requirements to satisfy the security - objectives expressed in a PP or ST. CC Part 1 Section provides more detailed - information on the relationship between security objectives - and security requirements. - - - Developers, who respond to actual or perceived consumer - security requirements in constructing a TOE, may find a - standardised method to understand those requirements in this - part of the CC. They can also use the contents of this part of - the CC as a basis for further defining the TOE security - functionality and mechanisms that comply with those - requirements. - - - Evaluators, who use the functional requirements defined in - this part of the CC in verifying that the TOE functional - requirements expressed in the PP or ST satisfy the IT security - objectives and that all dependencies are accounted for and - shown to be satisfied. Evaluators also should use this part of - the CC to assist in determining whether a given TOE satisfies - stated requirements. - - - - - - The CC and the associated security functional requirements - described herein are not meant to be a definitive answer to all - the problems of IT security. Rather, the CC offers a set of well - understood security functional requirements that can be used to - create trusted products reflecting the needs of the market. These - security functional requirements are presented as the current - state of the art in requirements specification and - evaluation. - - This part of the CC does not presume to include all possible - security functional requirements but rather contains those that - are known and agreed to be of value by the CC Part 2 authors at - the time of release. - - Since the understanding and needs of consumers may change, the - functional requirements in this part of the CC will need to be - maintained. It is envisioned that some PP/ST authors may have - security needs not (yet) covered by the functional requirement - components in CC Part 2. In those cases the PP/ST author may - choose to consider using functional requirements not taken from - the CC (referred to as extensibility), as explained in annexes - and - of - CC Part 1. - - - - Clause - describes the paradigm used in the security functional - requirements of CC Part 2. - - Clause - introduces the catalogue of CC Part 2 functional components - while clauses through describe the functional classes. - - provides explanatory information for potential - users of the functional components including a complete cross - reference table of the functional component dependencies. - - through provide the explanatory information for the - functional classes. This material must be seen as normative - instructions on how to apply relevant operations and select - appropriate audit or documentation information; the use of the - auxiliary verb should means that the instruction is strongly - preferred, but others may be justifiable. Where different - options are given, the choice is left to the PP/ST - author. - - Those who author PPs or STs should refer to clause 2 of CC Part - 1 for relevant structures, rules, and guidance: - - - CC Part 1, clause - defines the terms used in the CC. - - - CC Part 1, annex defines the - structure for STs. - - - CC Part 1, annex defines the - structure for PPs. - - - - - - The following referenced documents are indispensable for the - application of this document. For dated references, only the - edition cited applies. For undated references, the latest edition - of the referenced document (including any amendments) applies.CC - Common Criteria for Information Technology Security - Evaluation, Version _CCVERSION_, revision _CCREVISION_, - _CCDATE_. Part 1: Introduction and general model. - - - This part of the CC defines the required structure and content - of security functional components for the purpose of security - evaluation. It includes a catalogue of functional components - that will meet the common security functionality requirements - of many IT products. - - - This chapter describes the paradigm used in the security - functional requirements of this part of the CC. Key concepts - discussed are highlighted in bold/italics. This section is not - intended to replace or supersede any of the terms found in CC Part - 1, chapter . - - This part of the CC is a catalogue of security functional - components that can be specified for a Target of - Evaluation (TOE). A TOE is a set of software, firmware - and/or hardware possibly accompanied by user and administrator - guidance documentation. A TOE may contain resources such as - electronic storage media (e.g. main memory, disk space), - peripheral devices (e.g. printers), and computing capacity (e.g. - CPU time) that can be used for processing and storing - information and is the subject of an evaluation. - - TOE evaluation is concerned primarily with ensuring that a defined - set of security functional requirements (SFRs) is - enforced over the TOE resources. The SFRs define the rules by - which the TOE governs access to and use of its resources, and thus - information and services controlled by the TOE. - - The SFRs may define multiple Security Function Policies - (SFPs) to represent the rules that the TOE must enforce. Each such SFP - must specify its scope of control, by defining the subjects, - objects, resources or information, and operations to which it applies. All - SFPs are implemented by the TSF (see below), whose mechanisms enforce the - rules defined in the SFRs and provide necessary capabilities. - - Those portions of a TOE that must be relied on for the correct - enforcement of the SFRs are collectively referred to as the - TOE Security Functionality (TSF). The TSF consists of - all hardware, software, and firmware of a TOE that is either - directly or indirectly relied upon for security enforcement. - - The TOE may be a monolithic product containing hardware, firmware, - and software. - - Alternatively a TOE may be a distributed product that consists - internally of multiple separated parts. Each of these parts of the - TOE provides a particular service for the TOE, and is connected to - the other parts of the TOE through an internal communication - channel. This channel can be as small as a processor bus, - or may encompass a network internal to the TOE. - - When the TOE consists of multiple parts, each part of the TOE may - have its own part of the TSF which exchanges user and TSF data - over internal communication channels with other parts of the - TSF. This interaction is called internal TOE - transfer. In this case the separate parts of the TSF - abstractly form the composite TSF, which enforces the SFRs. - - TOE interfaces may be localised to the particular TOE, or they may - allow interaction with other IT products over external - communication channels. These external interactions with - other IT products may take two forms: - - - The SFRs of the other ``trusted IT product'' and the SFRs of - the TOE have been administratively coordinated and the other - trusted IT product is assumed to enforce its SFRs correctly - (e. g. by being separately evaluated). Exchanges of - information in this situation are called inter-TSF - transfers, as they are between the TSFs of distinct - trusted products. - - - The other IT product may not be trusted, it may be called an - ``untrusted IT product''. Therefore its SFRs are either - unknown or their implementation is not viewed as - trustworthy. TSF mediated exchanges of information in this - situation are called transfers outside of the - TOE, as there is no TSF (or its policy characteristics - are unknown) on the other IT product. - - - The set of interfaces, whether interactive (man-machine - interface) or programmatic (application programming interface), - through which resources are accessed that are mediated by the TSF, - or information is obtained from the TSF, is referred to as the - TSF Interface (TSFI). The TSFI defines the boundaries - of the TOE functionality that provide for the enforcement of the - SFRs. - - Users are outside of the TOE. However, in order to request that - services be performed by the TOE that are subject to rules - defined in the SFRs, users interact with the TOE through the - TSFIs. There are two types of users of interest to CC Part 2: - human users and external IT - entities. Human users may further be differentiated as - local human users, meaning they interact directly - with the TOE via TOE devices (e.g. workstations), or - remote human users, meaning they interact - indirectly with the TOE through another IT product. - - A period of interaction between users and the TSF is referred to - as a user session. Establishment of user sessions can - be controlled based on a variety of considerations, for example: - user authentication, time of day, method of accessing the TOE, and - number of allowed concurrent sessions (per user or in total). - - This part of the CC uses the term authorised to - signify a user who possesses the rights and/or privileges - necessary to perform an operation. The term authorised - user, therefore, indicates that it is allowable for a user - to perform a specific operation or a set of operations as defined - by the SFRs. - - To express requirements that call for the separation of - administrator duties, the relevant security functional - components (from family ) - explicitly state that administrative roles are - required. A role is a pre-defined set of rules establishing the - allowed interactions between a user operating in that role and - the TOE. A TOE may support the definition of any number of - roles. For example, roles related to the secure operation of a - TOE may include ``Audit Administrator'' and ``User Accounts - Administrator''. - - TOEs contain resources that may be used for the - processing and storing of information. The primary goal of the TSF - is the complete and correct enforcement of the SFRs over the - resources and information that the TOE controls. - - TOE resources can be structured and utilised in many different - ways. However, CC Part 2 makes a specific distinction that allows - for the specification of desired security properties. All entities - that can be created from resources can be characterised in one of - two ways. The entities may be active, meaning that they are the - cause of actions that occur internal to the TOE and cause - operations to be performed on information. Alternatively, the - entities may be passive, meaning that they are either the - container from which information originates or to which - information is stored. - - Active entities in the TOE that perform operations on objects are - referred to as subjects. Several types of subjects - may exist within a TOE: - - - those acting on behalf of an authorised user (e.g. UNIX - processes); - - - those acting as a specific functional process that may in turn - act on behalf of multiple users (e.g. functions as might be - found in client/server architectures); or - - - those acting as part of the TOE itself (e.g. processes not - acting on behalf of a user). - - - - CC Part 2 addresses the enforcement of the SFRs over types of - subjects as those listed above. - - Passive entities in the TOE that contain or receive information - and upon which subjects perform operations are called - objects. In the case where a subject (an active - entity) is the target of an operation (e.g. interprocess - communication), a subject may also be acted on as an object. - - Objects can contain information. This concept is - required to specify information flow control policies as addressed - in the FDP class. - - Users, subjects, information, objects, sessions and resources - controlled by rules in the SFRs may possess certain - attributes that contain information that is used by - the TOE for its correct operation. Some attributes, such as file - names, may be intended to be informational or may be used to - identify individual resources while others, such as access control - information, may exist specifically for the enforcement of the - SFRs. These latter attributes are generally referred to as - ``security attributes''. The word attribute will be - used as a shorthand in some places of this part of the CC for the - word ``security attribute''. However, no matter what the intended - purpose of the attribute information, it may be necessary to have - controls on attributes as dictated by the SFRs. - - Data in a TOE is categorised as either user data or TSF - data. Figure depicts this - relationship. User Data is information stored in TOE - resources that can be operated upon by users in accordance with - the SFRs and upon which the TSF places no special meaning. For - example, the content of an electronic mail message is user - data. TSF Data is information used by the TSF in making decisions - as required by the SFRs. TSF Data may be influenced - by users if allowed by the SFRs. Security attributes, - authentication data, TSF internal status variables used by the - rules defined in the SFRs or used for the protection of the TSF - and access control list entries are examples of TSF data. - - There are several SFPs that apply to data protection such as - access control SFPs and information flow - control SFPs. The mechanisms that implement access control - SFPs base their policy decisions on attributes of the users, - resources, subjects, objects, sessions, TSF status data and - operations within the scope of control. These attributes are used - in the set of rules that govern operations that subjects may - perform on objects. - - The mechanisms that implement information flow control SFPs base - their policy decisions on the attributes of the subjects and - information within the scope of control and the set of rules that - govern the operations by subjects on information. The attributes - of the information, which may be associated with the attributes of - the container or may be derived from the data in the container, - stay with the information as it is processed by the TSF. -
- - Two specific types of TSF data addressed by CC Part 2 can be, but - are not necessarily, the same. These are authentication - data and secrets. - - Authentication data is used to verify the claimed identity of a - user requesting services from a TOE. The most common form of - authentication data is the password, which depends on being kept - secret in order to be an effective security mechanism. However, - not all forms of authentication data need to be kept - secret. Biometric authentication devices (e.g. fingerprint - readers, retinal scanners) do not rely on the fact that the data - is kept secret, but rather that the data is something that only - one user possesses and that cannot be forged. - - The term secrets, as used in CC Part 2, while applicable to - authentication data, is intended to also be applicable to other - types of data that must be kept secret in order to enforce a - specific SFP. For example, a trusted channel mechanism that - relies on cryptography to preserve the confidentiality of - information being transmitted via the channel can only be as - strong as the method used to keep the cryptographic keys secret - from unauthorised disclosure. - - Therefore, some, but not all, authentication data needs to be kept - secret and some, but not all, secrets are used as authentication - data. Figure shows this relationship - between secrets and authentication data. In the Figure the types - of data typically encountered in the authentication data and the - secrets sections are indicated. -
- - - - - This clause provides an overview of the evaluation process - and defines the tasks an evaluator is intended to perform when - conducting an evaluation. - - Each evaluation, whether of a PP or TOE (including ST), - follows the same process, and has four evaluator tasks in - common: the input task, the output task, the evaluation - sub-activities, and the demonstration of the technical - competence to the evaluation authority task. - - The input task and the output tasks, which are related to - management of evaluation evidence and to report generation, - are entirely described in this clause. Each task has - associated sub-tasks that apply to, and are normative for all - CC evaluations (evaluation of a PP or a TOE). - - The evaluation sub-activities are only introduced in this - clause, and fully described in the following clauses. - - In contrast to the evaluation sub-activities, input and output - tasks have no verdicts associated with them as they do not map - to CC evaluator action elements; they are performed in order - to ensure conformance with the universal principles and to - comply with the CEM. - - The demonstration of the technical competence to the - evaluation authority task may be fulfilled by the evaluation - authority analysis of the output tasks results, or may include - the demonstration by the evaluators of their understanding of - the inputs for the evaluation sub-activities. This task has no - associated evaluator verdict, but has an evaluator authority - verdict. The detailed criteria to pass this task are left to - the discretion of the evaluation authority, as noted in Annex - . - - - - - This subclause presents the general model of the methodology - and identifies: - - - roles and responsibilities of the parties involved in - the evaluation process; - - - the general evaluation model. - - - - - - The general model defines the following roles: sponsor, - developer, evaluator and evaluation authority. - - The sponsor is responsible for requesting and supporting an - evaluation. This means that the sponsor establishes the - different agreements for the evaluation (e.g. commissioning - the evaluation). Moreover, the sponsor is responsible for - ensuring that the evaluator is provided with the evaluation - evidence. - - The developer produces the TOE and is responsible for - providing the evidence required for the evaluation - (e.g. training, design information), on behalf of the - sponsor. - - The evaluator performs the evaluation tasks required in the - context of an evaluation: the evaluator receives the - evaluation evidence from the developer on behalf of the - sponsor or directly from the sponsor, performs the - evaluation sub-activities and provides the results of the - evaluation assessment to the evaluation authority. - - The evaluation authority establishes and maintains the - scheme, monitors the evaluation conducted by the evaluator, - and issues certification/validation reports as well as - certificates based on the evaluation results provided by the - evaluator. - - - - To prevent undue influence from improperly affecting an - evaluation, some separation of roles is required. This - implies that the roles described above are fulfilled by - different entities, except that the roles of developer and - sponsor may be satisfied by a single entity. - - Moreover, some evaluations (e.g. EAL1 evaluation) may not - require the developer to be involved in the project. In this - case, it is the sponsor who provides the TOE to the - evaluator and who generates the evaluation evidence. - - - - The evaluation process consists of the evaluator performing - the evaluation input task, the evaluation output task and - the evaluation sub-activities. Figure provides an overview of - the relationship between these tasks and - sub-activities. -
- - The evaluation process may be preceded by a preparation - phase where initial contact is made between the sponsor and - the evaluator. The work that is performed and the - involvement of the different roles during this phase may - vary. It is typically during this step that the evaluator - performs a feasibility analysis to assess the likelihood of - a successful evaluation. - - - - The evaluator assigns verdicts to the requirements of the CC - and not to those of the CEM. The most granular CC structure - to which a verdict is assigned is the evaluator action - element (explicit or implied). A verdict is assigned to an - applicable CC evaluator action element as a result of - performing the corresponding CEM action and its constituent - work units. Finally, an evaluation result is assigned, as - described in CC Part 1, Clause . -
- - The CEM recognises three mutually exclusive verdict states: - - - Conditions for a pass verdict are - defined as an evaluator completion of the CC evaluator - action element and determination that the requirements - for the PP, ST or TOE under evaluation are met. The - conditions for passing the element are defined as: - - - the constituent work units of the related CEM - action, and; - - - all evaluation evidence required for performing - these work units is coherent, that is it can be - fully and completely understood by the evaluator, - and - - - all evaluation evidence required for performing - these work units does not have any obvious internal - inconsistencies or inconsistencies with other - evaluation evidence. Note that obvious means here - that the evaluator discovers this inconsistency - while performing the work units: the evaluator - should not undertake a full consistency analysis - across the entire evaluation evidence every time a - work unit is performed. - - - - - Conditions for a fail verdict are - defined as an evaluator completion of the CC evaluator - action element and determination that the requirements - for the PP, ST, or TOE under evaluation are not met, or - that the evidence is incoherent, or an obvious - inconsistency in the evaluation evidence has been found; - - - All verdicts are initially inconclusive - and remain so until either a pass or - fail verdict is assigned. - - - - The overall verdict is pass if and only if - all the constituent verdicts are also - pass. In the example illustrated in Figure - , if the verdict for one - evaluator action element is fail then the - verdicts for the corresponding assurance component, - assurance class, and overall verdict are also - fail. - - - - - - The objective of this task is to ensure that the evaluator - has available the correct version of the evaluation evidence - necessary for the evaluation and that it is adequately - protected. Otherwise, the technical accuracy of the - evaluation cannot be assured, nor can it be assured that the - evaluation is being conducted in a way to provide repeatable - and reproducible results. - - - - The responsibility to provide all the required evaluation - evidence lies with the sponsor. However, most of the - evaluation evidence is likely to be produced and supplied by - the developer, on behalf of the sponsor. - - Since the assurance requirements apply to the entire TOE, - all evaluation evidence pertaining to all parts of the TOE - is to be made available to the evaluator. The scope and - required content of such evaluation evidence is independent - of the level of control that the developer has over each of - the parts of the TOE. For example, if design is required, - then the requirements will - apply to all subsystems that are part of the TSF. In - addition, assurance requirements that call for procedures to - be in place (for example, - and ) will also apply to the - entire TOE (including any part produced by another - developer). - - It is recommended that the evaluator, in conjunction with - the sponsor, produce an index to required evaluation - evidence. This index may be a set of references to the - documentation. This index should contain enough information - (e.g. a brief summary of each document, or at least an - explicit title, indication of the subclauses of interest) to - help the evaluator to find easily the required - evidence. - - It is the information contained in the evaluation evidence - that is required, not any particular document - structure. Evaluation evidence for a sub-activity may be - provided by separate documents, or a single document may - satisfy several of the input requirements of a - sub-activity. - - The evaluator requires stable and formally-issued versions - of evaluation evidence. However, draft evaluation evidence - may be provided during an evaluation, for example, to help - an evaluator make an early, informal assessment, but is not - used as the basis for verdicts. It may be helpful for the - evaluator to see draft versions of particular appropriate - evaluation evidence, such as: - - - test documentation, to allow the evaluator to make an - early assessment of tests and test procedures; - - - design documents, to provide the evaluator with - background for understanding the TOE design; - - - source code or hardware drawings, to allow the evaluator - to assess the application of the developer's standards. - - - - Draft evaluation evidence is more likely to be encountered - where the evaluation of a TOE is performed concurrently with - its development. However, it may also be encountered during - the evaluation of an already-developed TOE where the - developer has had to perform additional work to address a - problem identified by the evaluator (e.g. to correct an - error in design or implementation) or to provide evaluation - evidence of security that is not provided in the existing - documentation (e.g. in the case of a TOE not originally - developed to meet the requirements of the CC). - - - - - The evaluator shall perform configuration control of the - evaluation evidence. - - The CC implies that the evaluator is able to identify and - locate each item of evaluation evidence after it has been - received and is able to determine whether a specific - version of a document is in the evaluator's - possession. - - The evaluator shall protect the evaluation evidence from - alteration or loss while it is in the evaluator's - possession. - - - - Schemes may wish to control the disposal of evaluation - evidence at the conclusion of an evaluation. The disposal - of the evaluation evidence should be achieved by one or - more of: - - - returning the evaluation evidence; - - - archiving the evaluation evidence; - - - destroying the evaluation evidence. - - - - - - An evaluator may have access to sponsor and developer - commercially-sensitive information (e.g. TOE design - information, specialist tools), and may have access to - nationally-sensitive information during the course of an - evaluation. Schemes may wish to impose requirements for - the evaluator to maintain the confidentiality of the - evaluation evidence. The sponsor and evaluator may - mutually agree to additional requirements as long as these - are consistent with the scheme. - - Confidentiality requirements affect many aspects of - evaluation work, including the receipt, handling, storage - and disposal of evaluation evidence. - - - - - - The evaluation sub-activities vary depending whether it is a - PP or a TOE evaluation. Moreover, in the case of a TOE - evaluation, the sub-activities depend upon the selected - assurance requirements. - - - - - The objective of this Subclause is to describe the Observation - Report (OR) and the Evaluation Technical Report - (ETR). Schemes may require additional evaluator reports such - as reports on individual units of work, or may require - additional information to be contained in the OR and the - ETR. The CEM does not preclude the addition of information - into these reports as the CEM specifies only the minimum - information content. - - Consistent reporting of evaluation results facilitates the - achievement of the universal principle of repeatability and - reproducibility of results. The consistency covers the type and - the amount of information reported in the ETR and OR. ETR and OR - consistency among different evaluations is the responsibility of - the evaluation authority. - - The evaluator performs the two following sub-tasks in order - to achieve the CEM requirements for the information content - of reports: - - - write OR sub-task (if needed in the context of the - evaluation); - - - write ETR sub-task. - - - - - - The evaluator delivers the ETR to the evaluation authority, - as well as any ORs as they become available. Requirements - for controls on handling the ETR and ORs are established by - the scheme which may include delivery to the sponsor or - developer. The ETR and ORs may include sensitive or - proprietary information and may need to be sanitised before - they are given to the sponsor. - - - - In this version of the CEM, the requirements for the - provision of evaluator evidence to support re-evaluation and - re-use have not been explicitly stated. Where information - for re-evaluation or re-use is required by the sponsor, the - scheme under which the evaluation is being performed should - be consulted. - - - - ORs provide the evaluator with a mechanism to request a - clarification (e.g. from the evaluation authority on the application of a - requirement) or to identify a problem with an aspect of the - evaluation. - - In the case of a fail verdict, the evaluator shall provide - an OR to reflect the evaluation result. Otherwise, the - evaluator may use ORs as one way of expressing clarification - needs. - - For each OR, the evaluator shall report the following: - - - the identifier of the PP or TOE evaluated; - - - the evaluation task/sub-activity during which the - observation was generated; - - - the observation; - - - the assessment of its severity (e.g. implies a fail - verdict, holds up progress on the evaluation, requires a - resolution prior to evaluation being completed); - - - the identification of the organisation responsible for - resolving the issue; - - - the recommended timetable for resolution; - - - the assessment of the impact on the evaluation of - failure to resolve the observation. - - - - The intended audience of an OR and procedures for handling the - report depend on the nature of the report's content and on the - scheme. Schemes may distinguish different types of ORs or define - additional types, with associated differences in required - information and distribution (e.g. evaluation ORs to evaluation authorities - and sponsors). - - - - - The evaluator shall provide an ETR to present technical - justification of the verdicts. - - The CEM defines the ETR's minimum content requirement; - however, schemes may specify additional content and - specific presentational and structural requirements. For - instance, schemes may require that certain introductory - material (e.g. disclaimers and copyright Clauses) be - reported in the ETR. - - The reader of the ETR is assumed to be familiar with - general concepts of information security, the CC, the CEM, - evaluation approaches and IT. - - The ETR supports the evaluation authority to confirm that - the evaluation was done to the required standard, but it - is anticipated that the documented results may not provide - all of the necessary information, so additional - information specifically requested by the scheme may be - necessary. This aspect is outside the scope of the - CEM. - - - - This Subclause describes the minimum content of the ETR for - a PP evaluation. The contents of the ETR are portrayed in - Figure ; this figure - may be used as a guide when constructing the structural - outline of the ETR document. -
- - - The evaluator shall report evaluation scheme - identifiers. - - Evaluation scheme identifiers (e.g. logos) are the - information required to unambiguously identify the - scheme responsible for the evaluation oversight. - - The evaluator shall report ETR configuration control - identifiers. - - The ETR configuration control identifiers contain - information that identifies the ETR (e.g. name, date and - version number). - - The evaluator shall report PP configuration control - identifiers. - - PP configuration control identifiers (e.g. name, date and - version number) are required to identify what is being evaluated - in order for the evaluation authority to verify that the verdicts have been - assigned correctly by the evaluator. - - The evaluator shall report the identity of the - developer. - - The identity of the PP developer is required to identify - the party responsible for producing the PP. - - The evaluator shall report the identity of the - sponsor. - - The identity of the sponsor is required to identify the - party responsible for providing evaluation evidence to - the evaluator. - - The evaluator shall report the identity of the - evaluator. - - The identity of the evaluator is required to identify - the party performing the evaluation and responsible for - the evaluation verdicts. - - - - The evaluator shall report the evaluation methods, - techniques, tools and standards used. - - The evaluator references the evaluation criteria, - methodology and interpretations used to evaluate the - PP. - - The evaluator shall report any constraints on the - evaluation, constraints on the handling of evaluation - results and assumptions made during the evaluation that - have an impact on the evaluation results. - - The evaluator may include information in relation to - legal or statutory aspects, organisation, - confidentiality, etc. - - - - The evaluator shall report a verdict and a supporting - rationale for each assurance component that constitutes - an activity, as a result of - performing the corresponding CEM action and its - constituent work units. - - The rationale justifies the verdict using the CC, the - CEM, any interpretations and the evaluation evidence - examined and shows how the evaluation evidence does or - does not meet each aspect of the criteria. It contains a - description of the work performed, the method used, and - any derivation of results. The rationale may provide - detail to the level of a CEM work unit. - - - - The evaluator shall report the conclusions of the - evaluation, in particular the overall verdict as defined - in CC Part 1 Clause , and determined by application - of the verdict assignment described in . - - The evaluator provides recommendations that may be useful for - the evaluation authority. These recommendations may include shortcomings of - the PP discovered during the evaluation or mention of features - which are particularly useful. - - - - The evaluator shall report for each item of evaluation - evidence the following information: - - - the issuing body (e.g. the developer, the sponsor); - - - the title; - - - the unique reference (e.g. issue date and version - number). - - - - - - The evaluator shall report any acronyms or abbreviations - used in the ETR. - - Glossary definitions already defined by the CC or CEM - need not be repeated in the ETR. - - - - The evaluator shall report a complete list that uniquely - identifies the ORs raised during the evaluation and - their status. - - For each OR, the list should contain its identifier as - well as its title or a brief summary of its - content. - - - - - This Subclause describes the minimum content of the ETR for - a TOE evaluation. The contents of the ETR are portrayed in - Figure ; this figure - may be used as a guide when constructing the structural - outline of the ETR document. -
- - - The evaluator shall report evaluation scheme - identifiers. - - Evaluation scheme identifiers (e.g. logos) are the - information required to unambiguously identify the - scheme responsible for the evaluation oversight. - - The evaluator shall report ETR configuration control - identifiers. - - The ETR configuration control identifiers contain - information that identifies the ETR (e.g. name, date and - version number). - - The evaluator shall report ST and TOE configuration - control identifiers. - - ST and TOE configuration control identifiers identify - what is being evaluated in order for the evaluation authority to - verify that the verdicts have been assigned correctly by - the evaluator. - - If the ST claims that the TOE conforms to the - requirements of one or more PPs, the ETR shall report - the reference of the corresponding PPs. - - The PPs reference contains information that uniquely - identifies the PPs (e.g. title, date, and version - number). - - The evaluator shall report the identity of the - developer. - - The identity of the TOE developer is required to - identify the party responsible for producing the - TOE. - - The evaluator shall report the identity of the - sponsor. - - The identity of the sponsor is required to identify the - party responsible for providing evaluation evidence to - the evaluator. - - The evaluator shall report the identity of the - evaluator. - - The identity of the evaluator is required to identify - the party performing the evaluation and responsible for - the evaluation verdicts. - - - - The evaluator shall report a high level description of - the TOE and its major components based on the evaluation - evidence described in the CC assurance family entitled - , where - applicable. - - The intent of this Subclause is to characterise the degree - of architectural separation of the major components. If - there is no requirement - in the ST, this is not applicable and is considered to - be satisfied. - - - - The evaluator shall report the evaluation methods, - techniques, tools and standards used. - - The evaluator may reference the evaluation criteria, - methodology and interpretations used to evaluate the TOE - or the devices used to perform the tests. - - The evaluator shall report any constraints on the - evaluation, constraints on the distribution of - evaluation results and assumptions made during the - evaluation that have an impact on the evaluation - results. - - The evaluator may include information in relation to - legal or statutory aspects, organisation, - confidentiality, etc. - - - - For each activity on which the TOE is evaluated, the - evaluator shall report: - - - the title of the activity considered; - - - a verdict and a supporting rationale for each - assurance component that constitutes this activity, - as a result of performing the corresponding CEM - action and its constituent work units. - - - - The rationale justifies the verdict using the CC, the - CEM, any interpretations and the evaluation evidence - examined and shows how the evaluation evidence does or - does not meet each aspect of the criteria. It contains a - description of the work performed, the method used, and - any derivation of results. The rationale may provide - detail to the level of a CEM work unit. - - The evaluator shall report all information specifically - required by a work unit. - - For the and activities, work units that identify - information to be reported in the ETR have been - defined. - - - - The evaluator shall report the conclusions of the - evaluation, which will relate to whether the TOE has - satisfied its associated ST, in particular the overall - verdict as defined in CC Part 1 Clause , and determined by - application of the verdict assignment described in . - - The evaluator provides recommendations that may be useful for - the evaluation authority. These recommendations may include shortcomings of - the IT product discovered during the evaluation or mention of - features which are particularly useful. - - - - The evaluator shall report for each item of evaluation - evidence the following information: - - - the issuing body (e.g. the developer, the sponsor); - - - the title; - - - the unique reference (e.g. issue date and version - number). - - - - - - The evaluator shall report any acronyms or abbreviations - used in the ETR. - - Glossary definitions already defined by the CC or CEM - need not be repeated in the ETR. - - - - The evaluator shall report a complete list that uniquely - identifies the ORs raised during the evaluation and - their status. - - For each OR, the list should contain its identifier as - well as its title or a brief summary of its - content. - - - - - - - The CC permits comparability between the results of independent - security evaluations. The CC does so by providing a common set - of requirements for the security functionality of IT products - and for assurance measures applied to these IT products during a - security evaluation. These IT products may be implemented in - hardware, firmware or software. - The evaluation process establishes a level of confidence that - the security functionality of these IT products and the - assurance measures applied to these IT products meet these - requirements. The evaluation results may help consumers to - determine whether these IT products fulfil their security needs. - The CC is useful as a guide for the development, evaluation - and/or procurement of IT products with security functionality. - The CC is intentionally flexible, enabling a range of evaluation - methods to be applied to a range of security properties of a - range of IT products. Therefore users of the standard are - cautioned to exercise care that this flexibility is not - misused. For example, using the CC in conjunction with - unsuitable evaluation methods, irrelevant security properties, - or inappropriate IT products, may result in meaningless - evaluation results. - Consequently, the fact that an IT product has been evaluated has - meaning only in the context of the security properties that were - evaluated and the evaluation methods that were used. Evaluation - authorities are advised to carefully check the products, - properties and methods to determine that an evaluation will - provide meaningful results. Additionally, purchasers of - evaluated products are advised to carefully consider this - context to determine whether the evaluated product is useful and - applicable to their specific situation and needs. - The CC addresses protection of assets from unauthorised - disclosure, modification, or loss of use. The categories of - protection relating to these three types of failure of security - are commonly called confidentiality, integrity, and - availability, respectively. The CC may also be applicable - to aspects of IT security outside of these three. The CC - is applicable to risks arising from human activities (malicious - or otherwise) and to risks arising from non-human - activities. Apart from IT security, the CC may be applied - in other areas of IT, but makes no claim of applicability in - these areas. - Certain topics, because they involve specialised techniques or - because they are somewhat peripheral to IT security, are - considered to be outside the scope of the CC. Some of these are - identified below. - - The CC does not contain security evaluation criteria - pertaining to administrative security measures not related - directly to the IT security functionality. However, it is - recognised that significant security can often be achieved - through or supported by administrative measures such as - organisational, personnel, physical, and procedural - controls. - - The evaluation of some technical physical aspects of IT - security such as electromagnetic emanation control is not - specifically covered, although many of the concepts - addressed will be applicable to that area. - - The CC does not address the evaluation methodology - under which the criteria should be applied. This methodology - is given in the CEM. - - The CC does not address the administrative and legal - framework under which the criteria may be applied by - evaluation authorities. However, it is expected that the CC - will be used for evaluation purposes in the context of such - a framework. - - The procedures for use of evaluation results in - accreditation are outside the scope of the CC. Accreditation - is the administrative process whereby authority is granted - for the operation of an IT product (or collection thereof) - in its full operational environment including all of its - non-IT parts. The results of the evaluation process are an - input to the accreditation process. However, as other - techniques are more appropriate for the assessments of - non-IT related properties and their relationship to the IT - security parts, accreditors should make separate provisions - for those aspects. - - The subject of criteria for the assessment of the inherent - qualities of cryptographic algorithms is not covered in the - CC. Should independent assessment of mathematical properties - of cryptography be required, the evaluation scheme under - which the CC is applied must make provision for such - assessments. - - ISO terminology, such as "can", "informative", "may", - "normative", "shall" and "should" used throughout the document - are defined in the ISO/IEC Directives, Part 2. Note that the - term "should" has an additional meaning applicable when using - this standard. See the note below. The following definition is - given for the use of ``should'' in the CC. - should - - within normative text, ``should'' indicates ``that among - several possibilities one is recommended as particularly - suitable, without mentioning or excluding others, or that a - certain course of action is preferred but not necessarily - required.'' (ISO/IEC Directives, Part 2). - - The CC interprets ``not necessarily required'' to mean - that the choice of another possibility requires a justification - of why the preferred option was not chosen. - - This part of the CC establishes the general concepts and - principles of IT security evaluation and specifies the general - model of evaluation given by various parts of the standard which - in its entirety is meant to be used as the basis for evaluation - of security properties of IT products. - Part one provides an overview of all parts of the CC - standard. It describes the various parts of the standard; - defines the terms and abbreviations to be used in all parts of - the standard; establishes the core concept of a Target of - Evaluation (TOE); the evaluation context and describes the - audience to which the evaluation criteria are addressed. An - introduction to the basic security concepts necessary for - evaluation of IT products is given. - It defines the various operations by which the functional and - assurance components given in CC Part 2 and CC Part 3 may be - tailored through the use of permitted operations. - The key concepts of protection profiles (PP), packages of - security requirements and the topic of conformance are specified - and the consequences of evaluation, evaluation results are - described. This part of the CC gives guidelines for the - specification of Security Targets (ST) and provides a - description of the organization of components throughout the - model. General information about the evaluation methodology are - given in the CEM and the scope of evaluation schemes is - provided. - The following referenced documents are indispensable for the - application of this CC part 1. For dated references, only the - edition cited applies. For undated references, the latest - edition of the referenced document (including any amendments) - applies.CC-2 - Common Criteria for Information Technology Security - Evaluation, Version _CCVERSION_, revision _CCREVISION_, - _CCDATE_. Part 2: Functional security components. - CC-3 - Common Criteria for Information Technology Security - Evaluation, Version _CCVERSION_, revision _CCREVISION_, - _CCDATE_. Part 3: Assurance security components. - CEM - Common Methodology for Information Technology Security - Evaluation, Version _CCVERSION_, revision _CCREVISION_, - _CCDATE_. - - For the purpose of the CC, the following terms and definitions - apply. - This Clause contains only - those terms which are used in a specialised way throughout the - CC. Some combinations of common terms used in the CC, while not - meriting inclusion in this Clause , are explained for clarity in the context - where they are used. - adverse actions - - actions performed by a threat agent on an asset - - assets - - entities that the owner of the TOE presumably places value upon - - assignment - - the specification of an identified parameter in a component - (of the CC) or requirement - - assurance - - grounds for confidence that a TOE meets the SFRs - - attack potential - - measure of the effort to be expended in attacking a TOE, - expressed in terms of an attacker's expertise, resources and - motivation - - augmentation - - addition of one or more requirement(s) to a package - - authentication data - - information used to verify the claimed identity of a user - - authorised user - - TOE user who may, in accordance with the SFRs, perform an operation - - class - - set of CC families that share a common focus - - coherent - - logically ordered and having discernible meaning - - For documentation, this addresses both the actual text and - the structure of the document, in terms of whether it is - understandable by its target audience. - - complete - - property where all necessary parts of an entity have been provided - - In terms of documentation, this means that all relevant - information is covered in the documentation, at such a level - of detail that no further explanation is required at that - level of abstraction. - - component - - smallest selectable set of elements on which requirements - may be based - - composed assurance package - - assurance package consisting of requirements drawn from - CC Part 3 (predominately from the class), representing a point on the CC - predefined composition assurance scale - - confirm - - declare that something has been reviewed in detail with an - independent determination of sufficiency - - The level of rigour required depends on the nature of the subject - matter. This term is only applied to evaluator actions. - - connectivity - - property of the TOE allowing interaction with IT entities - external to the TOE - - This includes exchange of data by wire or by wireless means, - over any distance in any environment or configuration. - - consistent - - relationship between two or more entities such that there - are no apparent contradictions between these entities - - counter, verb - - meet an attack where the impact of a particular threat is - mitigated but not necessarily eradicated - - demonstrable conformance - - relation between an ST and a PP, where the ST provides a - solution which solves the generic security problem in the PP - - The PP and the ST may contain entirely different statements - that discuss different entities, use different concepts - etc. Demonstrable conformance is also suitable for a TOE - type where several similar PPs already exist, thus allowing - the ST author to claim conformance to these PPs - simultaneously, thereby saving work. - - demonstrate - - provide a conclusion gained by an analysis which is less - rigorous than a ``proof'' - - dependency - - relationship between components such that if a requirement - based on the depending component is included in a PP, ST or - package, a requirement based on the component that is - depended upon must normally also be included in the PP, ST - or package - - describe - - provide specific details of an entity - - determine - - affirm a particular conclusion based on independent analysis - with the objective of reaching a particular conclusion - - The usage of this term implies a truly independent analysis, - usually in the absence of any previous analysis having been - performed. Compare with the terms ``confirm'' or - ``verify'' which imply that an analysis has already been - performed which needs to be reviewed - - development environment - - environment in which the TOE is developed - - element - - indivisible statement of a security need - - ensure - - guarantee a strong causal relationship between an action and - its consequences - - When this term is preceded by the word ``help'' it indicates - that the consequence is not fully certain, on the basis of - that action alone. - - evaluation - - assessment of a PP, an ST or a TOE, against defined criteria - - evaluation assurance level - - set of assurance requirements drawn from CC Part 3, - representing a point on the CC predefined assurance scale, - that form an assurance package - - evaluation authority - - body that sets the standards and monitors the quality of - evaluations conducted by bodies within a specific community - and implements the CC for that community by means of an - evaluation scheme - - evaluation scheme - - administrative and regulatory framework under which the CC - is applied by an evaluation authority within a specific - community - - exhaustive - - characteristic of a methodical approach taken to perform an - analysis or activity according to an unambiguous plan - - This term is used in the CC with respect to conducting an - analysis or other activity. It is related to ``systematic'' - but is considerably stronger, in that it indicates not only - that a methodical approach has been taken to perform the - analysis or activity according to an unambiguous plan, but - that the plan that was followed is sufficient to ensure that - all possible avenues have been exercised. - - explain - - give argument accounting for the reason for taking a course - of action - - This term differs from both ``describe'' and - ``demonstrate''. It is intended to answer the question - ``Why?'' without actually attempting to argue that the - course of action that was taken was necessarily optimal. - - extension - - addition to an ST or PP of functional requirements not - contained in CC Part 2 and/or assurance requirements not - contained in CC Part 3 - - external entity - - human or IT entity possibly interacting with the TOE from - outside of the TOE boundary - - family - - set of components that share a similar goal but differ in - emphasis or rigour - - formal - - expressed in a restricted syntax language with defined - semantics based on well-established mathematical concepts - - guidance documentation - - documentation that describes the delivery, preparation, - operation, management and/or use of the TOE - - identity - - representation uniquely identifying entities (e.g. a user, a - process or a disk) within the context of the TOE - - An example of such a representation is a string. For a human - user, the representation can be the full or abbreviated name - or a (still unique) pseudonym. - - informal - - expressed in natural language - - inter TSF transfers - - communicating data between the TOE and the security - functionality of other trusted IT products - - internal communication channel - - communication channel between separated parts of the TOE - - internal TOE transfer - - communicating data between separated parts of the TOE - - internally consistent - - no apparent contradictions exist between any aspects of an - entity - - In terms of documentation, this means that there can be no - statements within the documentation that can be taken to - contradict each other. - - iteration - - use of the same component to express two or more distinct - requirements - - justification - - analysis leading to a conclusion - - ``Justification'' is more rigorous than a - demonstration. This term requires significant rigour in - terms of very carefully and thoroughly explaining every step - of a logical argument. - - object - - passive entity in the TOE, that contains or receives - information, and upon which subjects perform operations - - operation (on a component of the CC) - - modification or repetition of a component - - Allowed operations on components are assignment, iteration, - refinement and selection. - - operation (on an object) - - specific type of action performed by a subject on an object - - operational environment - - environment in which the TOE is operated - - organisational security policy - - set of security rules, procedures, or guidelines for an - organisation - - A policy may pertain to a specific operational environment. - - package - - named set of either security functional or security - assurance requirements - - An example of a package is ``EAL 3''. - - Protection Profile evaluation - - assessment of a PP against defined criteria - - Protection Profile - - implementation-independent statement of security needs for a - TOE type - - prove - - show correspondence by formal analysis in its mathematical - sense - - It is completely rigorous in all ways. Typically, ``prove'' - is used when there is a desire to show correspondence - between two TSF representations at a high level of rigour. - - refinement - - addition of details to a component - - role - - predefined set of rules establishing the allowed - interactions between a user and the TOE - - secret - - information that must be known only to authorised users - and/or the TSF in order to enforce a specific SFP - - secure state - - state in which the TSF data are consistent and the TSF - continues correct enforcement of the SFRs - - security attribute - - property of subjects, users (including external IT - products), objects, information, sessions and/or resources - that is used in defining the SFRs and whose values are used - in enforcing the SFRs - - security function policy - - set of rules describing specific security behaviour enforced - by the TSF and expressible as a set of SFRs - - security objective - - statement of an intent to counter identified threats and/or - satisfy identified organisation security policies and/or - assumptions - - security problem - - statement which in a formal manner defines the nature and - scope of the security that the TOE is intended to address - - This statement consists of a combination of: - - threats to be countered by the TOE, - - the OSPs enforced by the TOE, and - - the assumptions that are upheld for the TOE and its - operational environment. - - security requirement - - requirement, stated in a standardised language, which is - meant to contribute to achieving the security objectives for - a TOE - - Security Target - - implementation-dependent statement of security needs for a - specific identified TOE - - selection - - specification of one or more items from a list in a component - - semiformal - - expressed in a restricted syntax language with defined semantics - - specify - - provide specific details about an entity in a rigorous and precise manner - - strict conformance - - hierarchical relationship between a PP and an ST where all - the requirements in the PP also exist in the ST - - This relation can be roughly defined as ``the ST shall - contain all statements that are in the PP, but may contain - more''. Strict conformance is expected to be used for - stringent requirements that are to be adhered to in a single - manner. - - ST evaluation - - assessment of an ST against defined criteria - - subject - - active entity in the TOE that performs operations on objects - - target of evaluation - - set of software, firmware and/or hardware possibly - accompanied by guidance - - threat agent - - entity that can adversely act on assets - - TOE evaluation - - assessment of a TOE against defined criteria - - TOE resource - - anything useable or consumable in the TOE - - TOE security functionality - - combined functionality of all hardware, software, and - firmware of a TOE that must be relied upon for the correct - enforcement of the SFRs - - trace, verb - - perform an informal correspondence analysis between two - entities with only a minimal level of rigour - - transfers outside of the TOE - - TSF mediated communication of data to entities not under the - control of the TSF - - translation - - describes the process of describing security requirements in - a standardised language. - - use of the term translation in this context is not literal - and does not imply that every SFR expressed in standardised - language can also be translated back to the security - objectives. - - trusted channel - - a means by which a TSF and another trusted IT product can - communicate with necessary confidence - - trusted IT product - - IT product, other than the TOE, which has its security - functional requirements administratively coordinated with - the TOE and which is assumed to enforce its security - functional requirements correctly - - An example of a trusted IT product would be one that has - been separately evaluated. - - trusted path - - means by which a user and a TSF can communicate with the - necessary confidence - - TSF data - - data for the operation of the TOE upon which the enforcement - of the SFR relies - - TSF interface - - means by which external entities (or subjects in the TOE but - outside of the TSF) supply data to the TSF, receive data - from the TSF and invoke services from the TSF - - user - - see external entity - - user data - - data for the user, that does not affect the operation of the TSF - - verify - - rigorously review in detail with an independent - determination of sufficiency - - Also see ``confirm''. This term has more rigorous - connotations. The term ``verify'' is used in the context - of evaluator actions where an independent effort is required - of the evaluator. - - The following terms are used in the requirements for software - internal structuring. Some of these are derived from the - IEEE Std 610.12-1990, - Standard glossary of software engineering terminology, - Institute of Electrical and Electronics Engineers. - administrator - - entity that has a level of trust with respect to all - policies implemented by the TSF - - Not all PPs or STs assume the same level of trust for - administrators. Typically administrators are assumed to - adhere at all times to the policies in the ST of the - TOE. Some of these policies may be related to the - functionality of the TOE, others may be related to the - operational environment. - - call tree - - identifies the modules in a system in diagrammatic form - showing which modules call one another - - Adapted from - cohesion - - module strength - - manner and degree to which the tasks performed by a single - software module are related to one another - - Types of cohesion include coincidental, communicational, - functional, logical, sequential, and temporal. These types - of cohesion are described by the relevant term entry. - - coincidental cohesion - - module with the characteristic of performing unrelated, or - loosely related, activities - - See ``cohesion''. - - communicational cohesion - - module containing functions that produce output for, or use - output from, other functions within the module - - See ``cohesion''. - An example of a communicationally cohesive module is an - access check module that includes mandatory, - discretionary, and capability checks. - complexity - - measure of how difficult software is to understand, and thus - to analyse, test, and maintain - - Reducing complexity is the ultimate goal for using modular - decomposition, layering and minimisation. Controlling - coupling and cohesion contributes significantly to this - goal. - A good deal of effort in the software engineering field - has been expended in attempting to develop metrics to - measure the complexity of source code. Most of these - metrics use easily computed properties of the source code, - such as the number of operators and operands, the - complexity of the control flow graph (cyclomatic - complexity), the number of lines of source code, the ratio - of comments to executable code, and similar - measures. Coding standards have been found to be a useful - tool in generating code that is more readily understood. - The family calls for a complexity - analysis in all components. It is expected that the - developer will provide support for the claims that there - has been a sufficient reduction in complexity. This - support could include the developer's programming - standards, and an indication that all modules meet the - standard (or that there are some exceptions that are - justified by software engineering arguments). It could - include the results of tools used to measure some of the - properties of the source code, or it could include other - support that the developer finds appropriate. - coupling - - manner and degree of interdependence between software modules - - Types of coupling include call, common and content - coupling. These are characterised below: - - call coupling - - relationship between two modules - - Examples of call coupling are data, stamp, and control: - - call coupling (data) - - relationship between two modules communicating strictly - through the use of call parameters that represent single - data items. - - See ``call coupling'' - - call coupling (stamp) - - relationship between two modules through the use of call - parameters that comprise multiple fields or that have - meaningful internal structures. - - See ``call coupling'' - - call coupling (control) - - relationship between two modules if one passes information - that is intended to influence the internal logic of the - other. - - See ``call coupling'' - - common coupling - - relationship between two modules sharing a common data area - or other common system resource - - Global variables indicate that modules using those global - variables are common coupled. Common coupling through global - variables is generally allowed, but only to a limited - degree. - For example, variables that are placed into a global area, - but are used by only a single module, are inappropriately - placed, and should be removed. Other factors that need to - be considered in assessing the suitability of global - variables are: - - The number of modules that modify a global variable: - In general, only a single module should be allocated - the responsibility for controlling the contents of a - global variable, but there may be situations in which - a second module may share that responsibility; in such - a case, sufficient justification must be provided. It - is unacceptable for this responsibility to be shared - by more than two modules. (In making this assessment, - care should be given to determining the module - actually responsible for the contents of the variable; - for example, if a single routine is used to modify the - variable, but that routine simply performs the - modification requested by its caller, it is the - calling module that is responsible, and there may be - more than one such module). Further, as part of the - complexity determination, if two modules are - responsible for the contents of a global variable, - there should be clear indications of how the - modifications are coordinated between them. - - The number of modules that reference a global - variable: Although there is generally no limit on the - number of modules that reference a global variable, - cases in which many modules make such a reference - should be examined for validity and necessity. - - content coupling - - relationship between two modules where one makes direct - reference to the internals of the other - - Examples include modifying code of, or referencing labels - internal to, the other module. The result is that some or - all of the content of one module are effectively included in - the other. Content coupling can be thought of as using - unadvertised module interfaces; this is in contrast to call - coupling, which uses only advertised module interfaces. - - domain separation - - security architecture property whereby the TSF defines - separate security domains for each user and for the TSF and - ensures that no user process can affect the contents of a - security domain of another user or of the TSF - - functional cohesion - - functional property of a module which performs activities - related to a single purpose - - A functionally cohesive module transforms a single type of - input into a single type of output, such as a stack manager or - a queue manager. See also ``cohesion''. - - interaction - - general communication-based activity between entities - - interface - - means of interaction with a component or module - - layering - - design technique where separate groups of modules (the - layers) are hierarchically organised to have separate - responsibilities such that one layer depends only on layers - below it in the hierarchy for services, and provides its - services only to the layers above it - - Strict layering adds the constraint that each layer receives - services only from the layer immediately beneath it, and - provides services only to the layer immediately above it. - - logical cohesion - - procedural cohesion - - characteristics of a module performing similar activities on - different data structures - - A module exhibits logical cohesion if its functions perform - related, but different, operations on different inputs. See - also ``cohesion''. - - modular decomposition - - process of breaking a system into components to facilitate - design, development and evaluation - - non-bypassability (of the TSF) - - security architecture property whereby all SFR-related - actions are mediated by the TSF - - procedural cohesion - - See ``logical cohesion'' - - security domain - - collection of resources to which an active entity has access - privileges - - sequential cohesion - - module containing functions each of whose output is input - for the following function in the module - - An example of a sequentially cohesive module is one that - contains the functions to write audit records and to - maintain a running count of the accumulated number of audit - violations of a specified type. - - software engineering - - application of a systematic, disciplined, quantifiable - approach to the development and maintenance of software; - that is, the application of engineering to software - - As with engineering practices in general, some amount of - judgement must be used in applying engineering - principles. Many factors affect choices, not just the - application of measures of modular decomposition, layering, - and minimisation. For example, a developer may design a - system with future applications in mind that will not be - implemented initially. The developer may choose to include - some logic to handle these future applications without fully - implementing them; further, the developer may include some - calls to as-yet unimplemented modules, leaving call - stubs. The developer's justification for such deviations - from well-structured programs will have to be assessed using - judgement, as well as the application of good software - engineering discipline. - - temporal cohesion - - characteristics of a module containing functions that need - to be executed at about the same time - - Adapted from . Examples of temporally - cohesive modules include initialisation, recovery, and - shutdown modules. - - TSF self-protection - - security architecture property whereby the TSF cannot be - corrupted by non-TSF code or entities - - installation - - procedure performed by a human user embedding the TOE in its - operational environment and putting it into an operational - state - - This operation is performed normally only once, after - receipt and acceptance of the TOE. The TOE is expected to be - progressed to a configuration allowed by the ST. If similar - processes have to be performed by the developer they are - denoted as ``generation'' throughout . If - the TOE requires an initial start-up that does not need to - be repeated regularly, this process would be classified as - installation. - - operation - - usage phase of the TOE including ``normal usage'', - administration and maintenance of the TOE after delivery and - preparation - - preparation - - activity in the life-cycle phase of a product, comprising - the customer's acceptance of the delivered TOE and its - installation which may include such things as booting, - initialisation, start-up and progressing the TOE to a state - ready for operation - - acceptance criteria - - criteria to be applied when performing the acceptance - procedures (e.g. successful document review, or successful - testing in the case of software, firmware or hardware) - - acceptance procedures - - procedures followed in order to accept newly created or - modified configuration items as part of the TOE, or to move - them to the next step of the life-cycle - - These procedures identify the roles or individuals - responsible for the acceptance and the criteria to be - applied in order to decide on the acceptance. - There are several types of acceptance situations some of - which may overlap: - - acceptance of an item into the configuration - management system for the first time, in particular - inclusion of software, firmware and hardware - components from other manufacturers into the TOE - (``integration''); - - progression of configuration items to the next - life-cycle phase at each stage of the construction of - the TOE (e.g. module, subsystem, quality control of - the finished TOE); - - subsequent to transports of configuration items (for - example parts of the TOE or preliminary products) - between different development sites; - - subsequent to the delivery of the TOE to the consumer. - - configuration management - - discipline applying technical and administrative direction - and surveillance to: identify and document the functional - and physical characteristics of a configuration item, - control changes to those characteristics, record and report - change processing and implementation status, and verify - compliance with specified requirements. - - CM documentation - - all CM documentation including CM output, CM list - (configuration list), CM system records, CM plan and CM - usage documentation - - configuration management evidence - - everything that may be used to establish confidence in the - correct operation of the CM system - - For example, CM output, rationales provided by the - developer, observations, experiments or interviews made by - the evaluator during a site visit. - - configuration item - - object managed by the CM system during the TOE development - - These may be either parts of the TOE or objects related to - the development of the TOE like evaluation documents or - development tools. CM items may be stored in the CM system - directly (for example files) or by reference (for example - hardware parts) together with their version. - - configuration list - - configuration management output document listing all - configuration items for a specific product together with the - exact version of each configuration management item relevant - for a specific version of the complete product - - This list allows distinguishing the items belonging to the - evaluated version of the product from other versions of - these items belonging to other versions of the product. The - final configuration management list is a specific document - for a specific version of a specific product. (Of course the - list can be an electronic document inside of a configuration - management tool. In that case it can be seen as a specific - view into the system or a part of the system rather than an - output of the system. However, for the practical use in an - evaluation the configuration list will probably be delivered - as a part of the evaluation documentation.) The - configuration list defines the items that are under the - configuration management requirements of . - - configuration management output - - results, related to configuration management, produced or - enforced by the configuration management system - - These configuration management related results could occur - as documents (for example filled paper forms, configuration - management system records, logging data, hard-copies and - electronic output data) as well as actions (for example - manual measures to fulfil configuration management - instructions). Examples of such configuration management - outputs are configuration lists, configuration management - plans and/or behaviours during the product life-cycle. - - configuration management plan - - description of how the configuration management system is - used for the TOE - - The objective of issuing a configuration management plan is - that staff members can see clearly what they have to - do. From the point of view of the overall configuration - management system this can be seen as an output document - (because it may be produced as part of the application of - the configuration management system). From the point of view - of the concrete project it is a usage document because - members of the project team use it in order to understand - the steps that they have to perform during the project. The - configuration management plan defines the usage of the - system for the specific product; the same system may be used - to a different extent for other products. That means the - configuration management plan defines and describes the - output of the configuration management system of a company - which is used during the TOE development. - - configuration management system - - set of procedures and tools (including their documentation) - used by a developer to develop and maintain configurations - of his products during their life-cycles - - Configuration management systems may have varying degrees of - rigour and function. At higher levels, configuration - management systems may be automated, with flaw remediation, - change controls, and other tracking mechanisms. - - configuration management system records - - output produced during the operation of the configuration - management system documenting important configuration - management activities - - Examples of configuration management system records are - configuration management item change control forms or - configuration management item access approval forms. - - configuration management tools - - manually operated or automated tools realising or supporting - a configuration management system - - For example tools for the version management of the parts of - the TOE. - - configuration management usage documentation - - part of the configuration management system, which - describes, how the configuration management system is - defined and applied by using for example handbooks, - regulations and/or documentation of tools and procedures - - delivery - - transmission of the finished TOE from the production - environment into the hands of the customer - - This product life-cycle phase may include packaging and - storage at the development site, but does not include - transportations of the unfinished TOE or parts of the TOE - between different developers or different development - sites. - - developer - - organisation responsible for the development of the TOE - - development - - product life-cycle phase which is concerned with generating - the implementation representation of the TOE - - Throughout the requirements, development - and related terms (developer, develop) are meant in the more - general sense to comprise development and production. - - development tools - - tools (including test software, if applicable) supporting - the development and production of the TOE - - For example for a software TOE, development tools are - usually programming languages, compilers, linkers and - generating tools. - - implementation representation - - least abstract representation of the TSF, specifically the - one that is used to create the TSF itself without further - design refinement - - Source code that is then compiled or a hardware drawing that - is used to build the actual hardware are examples of parts - of an implementation representation. - - life-cycle - - sequence of stages of existence of an object (for example a - product or a system) in time - - life-cycle definition - - definition of the life-cycle model - - life cycle model - - description of the stages and their relations to each other - that are used in the management of the life-cycle of a - certain object, how the sequence of stages looks like and - which high level characteristics the stages have - - production - - production life-cycle phase follows the development phase - and consists of transforming the implementation - representation into the implementation of the TOE, i.e. into - a state acceptable for delivery to the customer - - This phase may comprise manufacturing, integration, - generation, internal transports, storage, and labelling of - the TOE. -
- covert channel - - enforced, illicit signalling channel that allows a user to - surreptitiously contravene the multi-level separation policy - and unobservability requirements of the TOE - - encountered potential vulnerabilities - - potential weakness in the TOE identified by the evaluator - while performing evaluation activities that could be used to - violate the SFRs - - exploitable vulnerability - - weakness in the TOE that can be used to violate the SFRs in - the operational environment for the TOE - - monitoring attacks - - generic category of attack methods that includes passive - analysis techniques aiming at disclosure of sensitive - internal data of the TOE by operating the TOE in the way - that corresponds to the guidance documents - - potential vulnerability - - suspected, but not confirmed, weakness - - Suspicion is by virtue of a postulated attack path to - violate the SFRs. - - residual vulnerability - - weakness that cannot be exploited in the operational - environment for the TOE, but that could be used to violate - the SFRs by an attacker with greater attack potential than - is anticipated in the operational environment for the TOE - - vulnerability - - weakness in the TOE that can be used to violate the SFRs in - some environment - - base component - - entity in a composed TOE, which has itself been the subject - of an evaluation, providing services and resources to a - dependent component - - compatible (components) - - property of a component able to provide the services - required by the other component, through the corresponding - interfaces of each component, in consistent operational - environments - - component TOE - - successfully evaluated TOE that is part of another composed - TOE - - composed TOE - - TOE comprised solely of two or more components that have - been successfully evaluated - - dependent component - - entity in a composed TOE, which is itself the subject of an - evaluation, relying on the provision on services by a base - component - - functional interface - - external interface providing a user with access to - functionality of the TOE which is not directly involved in - enforcing security functional requirements - - In a composed TOE these are the interfaces provided by the - base component that are required by the dependent component - to support the operation of the composed TOE. - - The following abbreviations are used in one or more parts of the - CC:API - Application Programming Interface - CAP - Composed Assurance Package - CC - Common Criteria - CCRAArrangement on the - Recognition of Common Criteria Certificates in the field of IT - Security - CM - Configuration Management - DAC - Discretionary Access Control - EAL - Evaluation Assurance Level - GHz - Gigahertz - GUI - Graphical User Interface - IC - Integrated Circuit - IOCTL - Input Output Control - IP - Internet Protocol - IT - Information Technology - MB - Mega Byte - OS - Operating System - OSP - Organisational Security Policy - PC - Personal Computer - PCI - Peripheral Component Interconnect - PKI - Public Key Infrastructure - PP - Protection Profile - RAM - Random Access Memory - RPC - Remote Procedure Call - SAR - Security Assurance Requirement - SFR - Security Functional Requirement - SFP - Security Function Policy - SPD - Security Problem Definition - ST - Security Target - TCP - Transmission Control Protocol - TOE - Target of Evaluation - TSF - TOE Security Functionality - TSFI - TSF Interface - VPN - Virtual Private Network - - This Clause introduces the main concepts of the CC. It - identifies the concept ``TOE'', the target audience of the CC, - and the approach taken to present the material in the remainder - of the CC. - The CC is flexible in what to evaluate and is therefore not - tied to the boundaries of IT products as commonly - understood. Therefore in the context of evaluation, the CC - uses the term ``TOE'' (Target of Evaluation). - A TOE is defined as a set of software, firmware and/or - hardware possibly accompanied by guidance. - While there are cases where a TOE consists of an IT product, - this need not be the case. The TOE may be an IT product, a - part of an IT product, a set of IT products, a unique - technology that may never be made into a product, or a - combination of these. - As far as the CC is concerned, the precise relation - between the TOE and any IT products is only important in one - aspect: the evaluation of a TOE containing only part of an IT - product should not be misrepresented as the evaluation of the - entire IT product. - Examples of TOEs include: - - A software application; - - An operating system; - - A software application in combination with an operating - system; - - A software application in combination with an operating - system and a workstation; - - An operating system in combination with a workstation; - - A smart card integrated circuit; - - The cryptographic co-processor of a smart card integrated - circuit; - - A Local Area Network including all terminals, servers, - network equipment and software; - - A database application excluding the remote client - software normally associated with that database - application. - - In the CC, a TOE can occur in several - representations, such as (for a software TOE): - - a list of files in a configuration management system; - - a single master copy, that has just been compiled; - - a box containing a CD-ROM and a manual, ready to be shipped to a customer; - - an installed and operational version. - - All of these are considered to be a TOE: and wherever the - term ``TOE'' is used in the remainder of the CC, the - context determines the representation that is meant. - In general, IT products can be configured in many ways: - installed in different ways, with different options enabled - or disabled. As, during a CC evaluation, it will be - determined whether a TOE meets certain requirements, this - flexibility in configuration may lead to problems, as all - possible configurations of the TOE must meet the - requirements. For these reasons, it is often the case that - the guidance part of the TOE strongly constrains the - possible configurations of the TOE. That is: the guidance of - the TOE may be different from the general guidance of the IT - product. - An example is an operating system IT product. This product - can be configured in many ways (e.g. types of users, number - of users, types of external connections allowed/disallowed, - options enabled/disabled etc.). - If the same IT product is to be a TOE, and is evaluated - against a reasonable set of requirements, the configuration - should be much more tightly controlled, as many options - (e.g. allow all types of external connections or the system - administrator does not need to be authenticated) will lead - to a TOE not meeting the requirements. - For this reason, there would normally be a difference - between the guidance of the IT product (allowing many - configurations) and the guidance of the TOE (allowing only - one or only configurations that do not differ in - security-relevant ways). - Note that if the guidance of the TOE still allows more than - one configuration, these configurations are collectively - called ``the TOE'' and each such configuration must meet the - requirements levied on the TOE. - There are three groups with a general interest in evaluation - of the security properties of TOEs: consumers, developers and - evaluators. The criteria presented in this CC part 1 have been - structured to support the needs of all three groups. They are - all considered to be the principal users of the CC. The - three groups can benefit from the criteria as explained in the - following paragraphs. - The CC is written to ensure that evaluation fulfils - the needs of the consumers as this is the fundamental - purpose and justification for the evaluation process. - Consumers can use the results of evaluations to help decide - whether a TOE fulfils their security needs. These security - needs are typically identified as a result of both risk - analysis and policy direction. Consumers can also use the - evaluation results to compare different TOEs. - The CC gives consumers, especially in consumer groups - and communities of interest, an implementation-independent - structure, termed the Protection Profile (PP), in which to - express their security requirements in an unambiguous - manner. - The CC is intended to support developers in preparing - for and assisting in the evaluation of their TOEs and in - identifying security requirements to be satisfied by those - TOEs. These requirements are contained in an - implementation-dependent construct termed the Security - Target (ST). This ST may be based on one or more PPs to show - that the ST conforms to the security requirements from - consumers as laid down in those PPs. - The CC can then be used to determine the - responsibilities and actions to provide evidence that is - necessary to support the evaluation of the TOE against these - requirements. It also defines the content and presentation - of that evidence. - The CC contains criteria to be used by evaluators - when forming judgements about the conformance of TOEs to - their security requirements. The CC describes the set - of general actions the evaluator is to carry out. Note that - the CC does not specify procedures to be followed in - carrying out those actions. More information on these - procedures may be found in Subclause . - While the CC is oriented towards specification and - evaluation of the IT security properties of TOEs, it may - also be useful as reference material to all parties with an - interest in or responsibility for IT security. Some of the - additional interest groups that can benefit from information - contained in the CC are: - - system custodians and system security officers - responsible for determining and meeting organisational - IT security policies and requirements; - - auditors, both internal and external, responsible for - assessing the adequacy of the security of an IT solution - (which may consist of or contain a TOE); - - security architects and designers responsible for the - specification of security properties of IT products; - - accreditors responsible for accepting an IT solution for - use within a particular environment; - - sponsors of evaluation responsible for requesting and - supporting an evaluation; and - - evaluation authorities responsible for the management - and oversight of IT security evaluation programmes. - - The CC is presented as a set of distinct but related - parts as identified below. Terms used in the description of - the parts are explained in Clause . - Part 1, Introduction and general model is the - introduction to the CC. It defines the general concepts - and principles of IT security evaluation and presents a - general model of evaluation. - Part 2, Security functional components - establishes a set of functional components that serve as - standard templates upon which to base functional - requirements for TOEs. CC Part 2 catalogues the set of - functional components and organises them in families and - classes. - Part 3, Security assurance components - establishes a set of assurance components that serve as - standard templates upon which to base assurance - requirements for TOEs. CC Part 3 catalogues the set of - assurance components and organises them into families and - classes. CC Part 3 also defines evaluation criteria for - PPs and STs and presents seven pre-defined assurance - packages which are called the Evaluation Assurance Levels - (EALs). - - In support of the three parts of the CC listed above, - other documents have been published, the CEM provides - the methodology for IT security evaluation using the CC - as a basis. It is anticipated that other documents will be - published, including technical rationale material and guidance - documents. - The following table presents, for the three key target - audience groupings, how the parts of the CC will be of - interest. - Consumers - - Developers - - Evaluators - - Part 1 - - Use for background information and - are obliged to use for reference purposes. Guidance - structure for PPs. - - Use for background information and reference - purposes. Are obliged to use for the development of - security specifications for TOEs. - - Are obliged to use for reference purposes and for - guidance in the structure for PPs and STs. - - Part 2 - - Use for guidance and reference when formulating - statements of requirements for a TOE. - - Are obliged to use for reference when interpreting - statements of functional requirements and formulating - functional specifications for TOEs. - - Are obliged to use for reference when interpreting - statements of functional requirements. - - Part 3 - - Use for guidance when determining required levels of - assurance. - - Use for reference when interpreting statements of - assurance requirements and determining assurance - approaches of TOEs. - - Use for reference when interpreting statements of - assurance requirements. - Road map to the Common Criteria
- In order to achieve greater comparability between evaluation - results, evaluations should be performed within the framework - of an authoritative evaluation scheme that sets the standards, - monitors the quality of the evaluations and administers the - regulations to which the evaluation facilities and evaluators - must conform. - The CC does not state requirements for the regulatory - framework. However, consistency between the regulatory - frameworks of different evaluation authorities will be - necessary to achieve the goal of mutual recognition of the - results of such evaluations. - A second way of achieving greater comparability between - evaluation results is using a common methodology to achieve - these results. For the CC, this methodology is given in - the CEM. - Use of a common evaluation methodology contributes to the - repeatability and objectivity of the results but is not by - itself sufficient. Many of the evaluation criteria require the - application of expert judgement and background knowledge for - which consistency is more difficult to achieve. In order to - enhance the consistency of the evaluation findings, the final - evaluation results may be submitted to a certification - process. - The certification process is the independent inspection of the - results of the evaluation leading to the production of the - final certificate or approval, which is normally publicly - available. The certification process is a means of gaining - greater consistency in the application of IT security - criteria. - The evaluation schemes and certification processes are the - responsibility of the evaluation authorities that run such - schemes and processes and are outside the scope of the CC. - This clause presents the general concepts used throughout the - CC, including the context in which the concepts are to be used - and the CC approach for applying the concepts. CC Part 2 and CC - Part 3, which are obliged to be consulted by users of the CC - Part 1, expand on the use of these concepts and assume that the - approach described is used. Further, for users of the CC who - intend to perform evaluation activities the CEM is - applicable. This clause assumes some knowledge of IT security - and does not propose to act as a tutorial in this area. - The CC discusses security using a set of security - concepts and terminology. An understanding of these concepts and - the terminology is a prerequisite to the effective use of - the CC. However, the concepts themselves are quite - general and are not intended to restrict the class of IT - security problems to which the CC is applicable. - Security is concerned with the protection of assets. Assets - are entities that someone places value upon. Examples of - assets include: - contents of a file or a server;the authenticity of votes cast in an election;the availability of an electronic commerce - process;the ability to use an expensive printer;access to a classified facility. - but given that value is highly subjective, almost anything can - be an asset. - The environment(s) in which these assets are located is called - the operational environment. Examples of (aspects of) - operational environments are: - - the computer room of a bank; - - a computer network connected to the Internet; - - a LAN; - - a general office environment. - - Many assets are in the form of information that is stored, - processed and transmitted by IT products to meet requirements - laid down by owners of the information. Information owners may - require that availability, dissemination and modification of - any such information are strictly controlled and that the - assets are protected from threats by countermeasures. Figure - illustrates these - high level concepts and relationships.
- Safeguarding assets of interest is the responsibility of - owners who place value on those assets. Actual or presumed - threat agents may also place value on the assets and seek to - abuse assets in a manner contrary to the interests of the - owner. Examples of threat agents include hackers, malicious - users, non-malicious users (who sometimes make errors), - computer processes and accidents. - The owners of the assets will perceive such threats as - potential for impairment of the assets such that the value of - the assets to the owners would be reduced. Security-specific - impairment commonly includes, but is not limited to: loss of - asset confidentiality, loss of asset integrity and loss of - asset availability. - These threats therefore give rise to risks to the assets, - based on the likelihood of a threat being realised and the - impact on the assets when that threat is - realised. Subsequently countermeasures are imposed to reduce - the risks to assets. These countermeasures may consist of IT - countermeasures (such as firewalls and smart cards) and non-IT - countermeasures (such as guards and procedures). See also - ISO/IEC 27001 and ISO/IEC 27002 for a more general discussion - on security countermeasures (controls). - Owners of assets may be (held) responsible for those assets - and therefore should be able to defend the decision to accept - the risks of exposing the assets to the threats. - Two important elements in defending this decision are being - able to demonstrate that: - - the countermeasures are sufficient: if the countermeasures do what - they claim to do, the threats to the assets are countered; - - the countermeasures are correct: the countermeasures do - what they claim to do. - - Many owners of assets lack the knowledge, expertise or - resources necessary to judge sufficiency and correctness of - the countermeasures, and they may not wish to rely solely on - the assertions of the developers of the countermeasures. These - consumers may therefore choose to increase their confidence in - the sufficiency and correctness of some or all of their - countermeasures by ordering an evaluation of these - countermeasures.
- In an evaluation, sufficiency of the countermeasures is - analysed through a construct called the Security Target. In - this Subclause a simplified view on this construct is - provided: a more detailed and complete description may be - found in . - The Security Target begins with describing the assets and - the threats to those assets. The Security Target then - describes the countermeasures (in the form of Security - Objectives) and demonstrates that these countermeasures are - sufficient to counter these threats: if the countermeasures - do what they claim to do, the threats are countered. - The Security Target then divides these countermeasures in - two groups: - - the security objectives for the TOE: these describe the - countermeasure(s) for which correctness will be - determined in the evaluation; - - the security objectives for the Operational Environment: - these describe the countermeasures for which correctness - will not be determined in the evaluation. - - The reasons for this division are: - - The CC is only suitable for assessing the - correctness of IT countermeasures. Therefore the non-IT - countermeasures (e.g. human security guards, procedures) - are always in the Operational Environment. - - Assessing correctness of countermeasures costs time and - money, possibly making it infeasible to assess the - correctness of all IT countermeasures. - - The correctness of some IT countermeasures may already - have been assessed in another evaluation. It is - therefore not cost-effective to assess this correctness - again. - - For the TOE (the IT countermeasures whose correctness will - be assessed during the evaluation), the Security Target - requires a further detailing of the security objectives for - the TOE in Security Functional Requirements (SFRs). These - SFRs are formulated in a standardised language (described in - CC Part 2) to ensure exactness and facilitate comparability. - In summary, the Security Target demonstrates that: - - The SFRs meet the security objectives for the TOE; - - The security objectives for the TOE and the security - objectives for the operational environment counter the - threats; - - And therefore, the SFRs and the security objectives for - the operational environment counter the threats. - - From this it follows that a correct TOE (meeting the SFRs) - in combination with a correct operational environment - (meeting the security objectives for the operational - environment) will counter the threats. In the next two - subclauses correctness of the TOE and correctness of the - operational environment are discussed separately. - A TOE may be incorrectly designed and implemented, and may - therefore contain errors that lead to vulnerabilities. By - exploiting these vulnerabilities, attackers may still damage - and/or abuse the assets. - These vulnerabilities may arise from accidental errors made - during development, poor design, intentional addition of - malicious code, poor testing etc. - To determine correctness of the TOE, various activities can - be performed such as: - - testing the TOE; - - examining various design representations of the TOE; - - examining the physical security of the development - environment of the TOE. - - The Security Target provides a structured description of - these activities to determine correctness in the form of - Security Assurance Requirements (SARs). These SARs are - formulated in a standardised language (described in CC Part - 3) to ensure exactness and facilitate comparability. - If the SARs are met, there exists assurance in the - correctness of the TOE and the TOE is therefore less likely - to contain vulnerabilities that can be exploited by - attackers. The amount of assurance that exists in the - correctness of the TOE is determined by the SARs themselves: - a few ``weak'' SARs will lead to a little assurance, a lot - of ``strong'' SARs will lead to a lot of assurance. - The operational environment may also be incorrectly designed - and implemented, and may therefore contain errors that lead - to vulnerabilities. By exploiting these vulnerabilities, - attackers may still damage and/or abuse the assets. - However, in the CC, no assurance is obtained - regarding the correctness of the operational - environment. Or, in other words, the operational environment - is not evaluated (see the next Subclause). - As far as the evaluation is concerned, the operational - environment is assumed to be a 100% correct instantiation of - the security objectives for the operational environment. - This does not preclude a consumer of the TOE from using - other methods to determine the correctness of his - operational environment, such as: - - If, for an OS TOE, the security objectives for the - operational environment state ``The operational - environment shall ensure that entities from an untrusted - network (e.g. the Internet) can only access the TOE by - ftp'', the consumer could select an evaluated firewall, - and configure it to only allow ftp access to the TOE; - - If the security objectives for the operational - environment state ``The operational environment shall - ensure that all administrative personnel will not behave - maliciously'', the consumer could adapt his contracts - with administrative personnel to include punitive - sanctions for malicious behaviour, but this - determination is not part of a CC evaluation. - - The CC recognises two types of evaluation: an ST/TOE - evaluation, which is described below, and an evaluation of - PPs, which is defined in CC Part 3. In many places, - the CC uses the term evaluation (without qualifiers) to - refer to an ST/TOE evaluation. - In the CC an ST/TOE evaluation proceeds in two steps: - - An ST evaluation: where the sufficiency of the TOE and the - operational environment are determined; - - A TOE evaluation: where the correctness of the TOE is - determined. As said earlier, the TOE evaluation does not - assess correctness of the operational environment. - - The ST evaluation is carried out by applying the Security - Target evaluation criteria (which are defined in CC Part 3) to - the Security Target. The precise method to apply the criteria is determined by the evaluation - methodology that is used. - The TOE evaluation is more complex. The principal inputs to a - TOE evaluation are: the evaluation evidence, which includes - the TOE and ST, but will usually also include input from the - development environment, such as design documents or developer - test results. - The TOE evaluation consists of applying the SARs (from the - Security Target) to the evaluation evidence. The precise - method to apply a specific SAR is determined by the evaluation - methodology that is used. - How the results of applying the SARs are documented, and what - reports need to be generated and in what detail, is determined - by both the evaluation methodology that is used and the - evaluation scheme under which the evaluation is carried out. - The result of the TOE evaluation process is either: - - A statement that not all SARs have been met and that - therefore there is not the specified level of assurance - that the TOE meets the SFRs as stated in the ST; - - A statement that all SARs have been met, and that - therefore there is the specified level of assurance that - the TOE meets the SFRs as stated in the ST. - - The TOE evaluation may be carried out after TOE development - has finished, or in parallel with TOE development. - The method of stating ST/TOE evaluation results is described - in Clause . These results also - identify the PP(s) and package(s) to which the TOE claims - conformance, and these constructs are described in the next - Clause. - The CC functional and assurance components may be used exactly - as defined in CC Part 2 and CC Part 3, or they may be tailored - through the use of permitted operations. When using - operations, the PP/ST author should be careful that the - dependency needs of other requirements that depend on this - requirement are satisfied. The permitted operations are - selected from the following set: - - Iteration: allows a component to be used more than once - with varying operations; - - Assignment: allows the specification of parameters; - - Selection: allows the specification of one or more items - from a list; and - - Refinement: allows the addition of details. - - The assignment and selection operations are permitted only - where specifically indicated in a component. Iteration and - refinement are permitted for all components. The operations - are described in more detail below. - The CC Part 2 Annexes provide the guidance on the valid - completion of selections and assignments. This guidance - provides normative instructions on how to complete operations, - and those instructions shall be followed unless the PP/ST - author justifies the deviation: - - ``None'' is only available as a choice for the completion - of a selection if explicitly provided. - - The lists provided for the completion of selections must - be non-empty. If a ``None'' option is chosen, no - additional selection options may be chosen. If ``None'' - is not given as an option in a selection, it is - permissible to combine the choices in a selection with - ``and''s and ``or''s, unless the selection explicitly - states ``choose one of''. - Selection operations may be combined by iteration where - needed. In this case, the applicability of the option - chosen for each iteration should not overlap the subject - of the other iterated selection, since they are intended - to be exclusive. - For the completion of assignments, the CC Part 2 Annexes - shall be consulted in order to determine when ``None'' - would be a valid completion. - - The iteration operation may be performed on every - component. The PP/ST author performs an iteration operation - by including multiple requirements based on the same - component. Each iteration of a component shall be different - from all other iterations of that component, which is - realised by completing assignments and selections in a - different way, or by applying refinements to it in a - different way. - Different iterations should be uniquely identified to allow - clear rationales and tracings to and from these - requirements. - It is important to note that sometimes an iteration - operation can be used with components where could also be - possible to perform an assignment operation with a range or - list of values instead of iterate them. In that case the - author can select the most appropriate alternative, - considering if there is a necessity of providing a whole - rationale for the range of values or if it is necessary to - have a separate one for each of them. The author should also - keep in mind if individual traces are required for those - values. - An assignment operation occurs where a given component - contains an element with a parameter that may be set by the - PP/ST author. The parameter may be an unrestricted variable, - or a rule that narrows the variable to a specific range of - values. - Whenever an element in a PP contains an assignment, a PP - author shall do one of four things: - - leave the assignment uncompleted. The PP author could - include ``When the - defined number of unsuccessful authentication attempts - has been met or surpassed, the TSF shall - [assignment: list of actions].'' in the PP. - - complete the assignment. As an example, the PP author - could include ``When - the defined number of unsuccessful authentication - attempts has been met or surpassed, the TSF shall - prevent that external entity from binding to any - subject in the future.'' in the PP. - - narrow the assignment, to further limit the range of - values that is allowed. As an example, the PP author - could include ``The - TSF shall detect when [assignment: positive - integer between 4 and 9] unsuccessful authentication - attempts occur ...'' in the PP. - - transform the assignment to a selection, thereby - narrowing the assignment. As an example, the PP author - could include ``When - the defined number of unsuccessful authentication - attempts has been met or surpassed, the TSF shall - [selection: prevent that user from binding to any - subject in the future, notify the - administrator].'' in the PP. - - Whenever an element in an ST contains an assignment, an ST - author shall complete that assignment, as indicated in b) - above. Options a), c) and d) are not allowed for STs. - The values chosen in options b), c) and d) shall conform to - the indicated type required by the assignment. - When an assignment is to be completed with a set - (e.g. subjects), one may list a set of subjects, but also - some description of the set from which the elements of the - set can be derived such as: - - all subjects - - all subjects of type X - - all subjects except subject a - - as long as it is clear which subjects are meant. - - The selection operation occurs where a given component - contains an element where a choice from several items has to - be made by the PP/ST author. - Whenever an element in a PP contains a selection, the PP - author may do one of three things: - - leave the selection uncompleted. - - complete the selection by choosing one or more items. - - restrict the selection by removing some of the choices, - but leaving two or more. - - Whenever an element in an ST contains a selection, an ST - author shall complete that selection, as indicated in b) - above. Options a) and c) are not allowed for STs. - The item or items chosen in b) and c) shall be taken from - the items provided in the selection. - The refinement operation can be performed on every - requirement. The PP/ST author performs a refinement by - altering that requirement. The first rule for a refinement - is that a TOE meeting the refined requirement also meets the - unrefined requirement in the context of the PP/ST (i.e. a - refined requirement must be ``stricter'' than the original - requirement). If a refinement does not meet this rule, the - resulting refined requirement is considered to be an - extended requirement and shall be treated as such. - The first rule for a refinement is that a TOE meeting the - refined requirement also meets the unrefined requirement in - the context of the PP/ST (i.e. a refined requirement must be - ``stricter'' than the original requirement) - The only exception to this rule is that a PP/ST author is - allowed to refine a SFR to apply to some but not all - subjects, objects, operations, security attributes and/or - external entities. - However, this exception does not apply to refining SFRs that - are taken from PPs that compliance is being claimed to; - these SFRs may not be refined to apply to fewer subjects, - objects, operations, security attributes and/or external - entities than the SFR in the PP. - The second rule for a refinement is that the refinement - shall be related to the original component. - A special case of refinement is an editorial refinement, - where a small change is made in a requirement, - i.e. rephrasing a sentence due to adherence to proper - English grammar, or to make it more understandable to the - reader. This change is not allowed to modify the meaning of - the requirement in any way. - Dependencies may exist between components. Dependencies arise - when a component is not self sufficient and relies upon the - presence of another component to provide security - functionality or assurance. - The functional components in CC Part 2 typically have - dependencies on other functional components as do some of the - assurance components in CC Part 3 which may have dependencies - on other CC Part 3 components. CC Part 2 dependencies on CC - Part 3 components may also be defined. However, this does not - preclude extended functional components having dependencies on - assurance components or vice versa. - Component dependency descriptions are determined by consulting - the CC Part 2 and CC Part 3 component definitions. In order to - ensure completeness of the TOE security requirements, - dependencies should be satisfied when requirements based on - components with dependencies are incorporated into PPs and - STs. Dependencies should also be considered when constructing - packages. - In other words: if component A has a dependency on component - B, this means that whenever a PP/ST contains a security - requirement based on component A, the PP/ST shall also contain - one of : - - a security requirement based on component B, or - - a security requirement based on a component that is - hierarchically higher than B, or - - a justification why the PP/ST does not contain a security - requirement based on component B. - - In cases a) and b), when a security requirement is included - because of a dependency, it may be necessary to complete - operations (assignment, iteration, refinement, selection) on - that security requirement in a particular manner to make sure - that it actually satisfies the dependency. - In case c), the justification that a security requirement is - not included should address either: - - why the dependency is not necessary or useful, or - - that the dependency has been addressed by the operational - environment of the TOE, in which case the justification - should describe how the security objectives for the - operational environment address this dependency, or - - that the dependency has been addressed by the other SFRs - in some other manner (extended SFRs, combinations of SFRs - etc.) - - In the CC it is mandatory to base requirements on - components from CC Part 2 or CC Part 3 with two - exceptions: - - there are security objectives for the TOE that can not be - translated to Part 2 SFRs, or there are third party - requirements (e.g., laws, standards) that can not be - translated to Part 3 SARs (e.g. regarding evaluation of - cryptography); - - a security objective can be translated, but only with - great difficulty and/or complexity based on components in - CC Part 2 and/or CC Part 3. - - In both cases the PP/ST author is required to define his own - components. These newly defined components are called extended - components. A precisely defined extended component is needed - to provide context and meaning to the extended SFRs and SARs - based on that component. - After the new components have been defined correctly, the - PP/ST author can then base one or more SFRs or SARs on these - newly defined extended components and use them in the same way - as the other SFRs and SARs. From this point on, there is no - further distinction between SARs and SFRs based on the CC and - SARs and SFRs based on extended components. Refer to CC Part 3 - and for further - requirements on extended components. - To allow consumer groups and communities of interest to - express their security needs, and to facilitate writing STs, - this part of the CC provides two special constructs: packages - and Protection Profiles (PPs). In the following two subclauses - these constructs are described in more detail, followed by a - subclause on how these constructs can be used. - A package is a named set of security requirements. A package - is either - - a functional package, containing only SFRs, or - - an assurance package, containing only SARs. - - Mixed packages containing both SFRs and SARs are not allowed. - A package can be defined by any party and is intended to be - re-usable. To this goal it should contain requirements that - are useful and effective in combination. Packages can be used - in the construction of larger packages, PPs and STs. At - present there are no criteria for the evaluation of packages, - therefore any set of SFRs or SARs can be a package. - Examples of assurance packages are the evaluation assurance - levels (EALs) that are defined in CC Part 3. At the time - of writing there are no functional packages for this version - of the CC. - Whereas an ST always describes a specific TOE (e.g. the - MinuteGap v18.5 Firewall), a PP is intended to describe a TOE - type (e.g. firewalls). The same PP may therefore be used as a - template for many different STs to be used in different - evaluations. A detailed description of PPs is given in  . - In general an ST describes requirements for a TOE and is - written by the developer of that TOE, while a PP describes - the general requirements for a TOE type, and is therefore - typically written by: - - A user community seeking to come to a consensus on the - requirements for a given TOE type; - - A developer of a TOE, or a group of developers of - similar TOEs wishing to establish a minimum baseline for - that type of TOE; - - A government or large corporation specifying its - requirements as part of its acquisition process. - - The PP determines the allowed type of conformance of the ST - to the PP. That is, the PP states (in the PP conformance - statement, see subclause ) - what the allowed types of conformance for the ST are: - - if the PP states that strict conformance is required, - the ST shall conform to the PP in a strict manner; - - if the PP states that demonstrable conformance is - required, the ST shall conform to the PP in a strict or - demonstrable manner. - - Restating this in other words, an ST is only allowed to - conform in a PP in a demonstrable manner, if the PP - explicitly allows this. - If an ST claims conformance to multiple PPs, it shall - conform (as described above) to each PP in the manner - ordained by that PP. This may mean that the ST conforms - strictly to some PPs and demonstrably to other PPs. - Note that either the ST conforms to the PP in question or it - does not. The CC does not recognise ``partial'' - conformance. It is therefore the responsibility of the PP - author to ensure the PP is not overly onerous, prohibiting - PP/ST authors in claiming conformance to the PP. - An ST is equivalent or more restrictive than a PP if: - - all TOEs that meet the ST also meet the PP, and - - all operational environments that meet the PP also meet - the ST. - - or, informally, the ST shall levy the same or more, - restrictions on the TOE and the same or less restrictions on - the operational environment of the TOE. - This general statement can be made more specific for various - subclauses of the ST: - Security problem definition: The - conformance rationale in the ST shall demonstrate that - the security problem definition in the ST is equivalent - (or more restrictive) than the security problem - definition in the PP. This means that: - - all TOEs that would meet the security problem - definition in the ST also meet the security problem - definition in the PP; - - all operational environments that would meet the - security problem definition in the PP would also - meet the security problem definition in the ST. - Security objectives: The conformance - rationale in the ST shall demonstrate that the security - objectives in the ST is equivalent (or more restrictive) - than the security objectives in the PP. This means that: - - all TOEs that would meet the security objectives for - the TOE in the ST also meet the security objectives - for the TOE in the PP; - - all operational environments that would meet the - security objectives for the operational environment - in the PP would also meet the security objectives - for the operational environment in the ST. - - If strict conformance for protection profiles is specified - then the following requirements apply: - Security problem definition: The ST shall - contain the security problem definition of the PP, may - specify additional threats and OSPs, but may not specify - additional assumptions. - Security objectives: The ST: - - shall contain all security objectives for the TOE of - the PP but may specify additional security - objectives for the TOE; - - shall contain all security objectives for the - operational environment (with one exception in the - next bullet) but may not specify additional security - objectives for the operational environment; - - may specify that certain objectives for the - operational environment in the PP are security - objectives for the TOE in the ST. This is called - re-assigning a security objective. If a security - objective is re-assigned to the TOE the security - objectives rationale has to make clear which - assumption or part of the assumption is not - necessary any more. - Security requirements: The ST shall contain - all SFRs and SARs in the PP, but may claim additional or - hierarchically stronger SFRs and SARs. The completion of - operations in the ST must be consistent with that in the - PP; either the same completion will be used in the ST as - that in the PP or one that makes the requirement more - restrictive (the rules of refinement apply). - - If demonstrable conformance for protection profiles is - specified then the following requirements apply: - - the ST shall contain a rationale on why the ST is - considered to be ``equivalent or more restrictive'' than - the PP. - - Demonstrable conformance allows a PP author to describe - a common security problem to be solved and provide - generic guidelines to the requirements necessary for its - resolution, in the knowledge that there is likely to be - more than one way of specifying a resolution. - - PP evaluation is optional. Evaluation is performed by applying - the criteria to them as listed in - CC Part 3. The goal of such an evaluation is to demonstrate - that the PP is complete, consistent, and technically sound and - suitable for use as a template on which to build another PP or - an ST. - Basing a PP/ST on an evaluated PP has two advantages: - - There is much less risk that there are errors, ambiguities - or gaps in the PP. If any problems with a PP (that would - have been caught by evaluating that PP) are found during - the writing or evaluation of the new ST, significant time - may elapse before the PP is corrected. - - Evaluation of the new PP/ST may often re-use evaluation - results of the evaluated PP, resulting in less effort - for evaluating the new PP/ST. -
- If an ST claims to be conformant to one or more packages - and/or Protection Profiles, the evaluation of that ST will - (among other properties of that ST) demonstrate that the ST - actually conforms to these packages and/or PPs that they claim - conformance to. Details of this determination of conformance - can be found in . - This allows the following process: - - An organisation seeking to acquire a particular type of - IT security product develops their security needs into a - PP, then has this evaluated and publishes it; - - A developer takes this PP, writes an ST that claims - conformance to the PP and has this ST evaluated; - - The developer then builds a TOE (or uses an existing - one) and has this evaluated against the ST. - - The result is that the developer can prove that his TOE is - conformant to the security needs of the organisation: the - organisation can therefore acquire that TOE. A similar line of - reasoning applies to packages. - The CC also allows PPs to conform to other PPs, allowing - chains of PPs to be constructed, each based on the previous - one(s). - For instance, one could take a PP for an Integrated Circuit - and a PP for a Smart Card OS, and use these to construct a - Smart Card PP (IC and OS) that claims conformance to the - other two. One could then write a PP on Smart Cards for - Public Transport based on the Smart Card PP and a PP on - Applet Loading. Finally, a developer could then construct an - ST based on this Smart Cards for Public Transport PP. - This clause presents the expected results from PP and ST/TOE - evaluations performed according to the CEM. - PP evaluations lead to catalogues of evaluated PPs. - An ST evaluation leads to intermediate results that are used - in the frame of a TOE evaluation. - ST/TOE evaluations lead to catalogues of evaluated TOEs. In - many cases these catalogues will refer to the IT products that - the TOEs are derived from rather than the specific - TOE. Therefore, the existence of an IT product in a catalogue - should not be construed as meaning that the whole IT product - has been evaluated; instead the actual extent of the ST/TOE - evaluation is defined by the ST. Refer to the bibliography for - examples of such catalogues.
- STs may be based on packages, evaluated PPs or non-evaluated - PPs - however this is not mandatory, as STs do not have to be - based on anything at all. - Evaluation should lead to objective and repeatable results - that can be cited as evidence, even if there is no absolute - objective scale for representing the results of a security - evaluation. The existence of a set of evaluation criteria is a - necessary pre-condition for evaluation to lead to a meaningful - result and provides a technical basis for mutual recognition - of evaluation results between evaluation authorities. - An evaluation result represents the findings of a specific - type of investigation of the security properties of a - TOE. Such a result does not automatically guarantee fitness - for use in any particular application environment. The - decision to accept a TOE for use in a specific application - environment is based on consideration of many security issues - including the evaluation findings. - CC Part 3 contains the evaluation criteria that an evaluator - is obliged to consult in order to state whether a PP is - complete, consistent, and technically sound and hence suitable - for use in developing an ST. - The results of the evaluation shall also include a - ``Conformance Claim'' (see Subclause )). - CC Part 3 contains the evaluation criteria that an evaluator - is obliged to consult in order to determine whether - sufficient assurance exists that the TOE satisfies the SFRs - in the ST. Evaluation of the TOE shall therefore result in a - pass/fail statement for the ST. If both the ST and the TOE - evaluation have resulted in a pass statement, the underlying - product is eligible for inclusion in a registry. The results - of evaluation shall also include a ``Conformance Claim'' as - defined in the next subclause. - It may be the case that the evaluation results are - subsequently used in a certification process, but this - certification process is outside the scope of the CC. - The conformance claim indicates the source of the collection - of requirements that is met by a PP or ST that passes its - evaluation. This conformance claim contains a CC conformance - claim that: - - describes the version of the CC to which the PP - or ST claims conformance. - - describes the conformance to CC Part 2 (security - functional requirements) as either: - CC Part 2 conformant - A PP or ST - is CC Part 2 conformant if all SFRs in that PP - or ST are based only upon functional components in - CC Part 2, or - CC Part 2 extended - A PP or ST - is CC Part 2 extended if at least one SFR in - that PP or ST is not based upon functional - components in CC Part 2. - - describes the conformance to CC Part 3 (security - assurance requirements) as either: - CC Part 3 conformant - A PP or ST - is CC Part 3 conformant if all SARs in that PP - or ST are based only upon assurance components in - CC Part 3, or - CC Part 3 extended - A PP or ST - is CC Part 3 extended if at least one SAR in - that PP or ST is not based upon assurance components - in CC Part 3. - - Additionally, the conformance claim may include a statement - made with respect to packages, in which case it consists of - one of the following: - Package name Conformant - A PP or ST is - conformant to a pre-defined package (e.g. EAL) if: - - the SFRs of that PP or ST are identical to the SFRs - in the package, or - - the SARs of that PP or ST are identical to the SARs - in the package. - Package name Augmented - A PP or ST is - an augmentation of a predefined package if: - - the SFRs of that PP or ST contain all SFRs in the - package, but have at least one additional SFR or one - SFR that is hierarchically higher than an SFR in the - package. - - the SARs of that PP or ST contain all SARs in the - package, but have at least one additional SAR or one - SAR that is hierarchically higher than an SAR in the - package. - - Note that when a TOE is successfully evaluated to a given - ST, any conformance claims of the ST also hold for the - TOE. A TOE can therefore also be e.g. CC Part 2 conformant. - Finally, the conformance claim may also include two - statements with respect to Protection Profiles: - PP Conformant - A PP or TOE meets - specific PP(s), which are listed as part of the - conformance result. - Conformance Statement (Only for PPs) - - This statement describes the manner in which PPs or STs - must conform to this PP: strict or demonstrable. For - more information on this Conformance Statement, see -   . - - Once an ST and a TOE have been evaluated, asset owners can - have the assurance (as defined in the ST) that the TOE, - together with the operational environment, counters the - threats. The evaluation results may be used by the asset - owner in deciding whether to accept the risk of exposing the - assets to the threats. - However, the asset owner should carefully check whether: - - the Security Problem Definition in the ST matches the - security problem of the asset owner; - - the Operational Environment of the asset owner conforms - (or can be made to conform) to the security objectives - for the Operational Environment described in the ST. - - If either of these is not the case, the TOE may not be - suitable for the purposes of the asset owner. - Additionally, once an evaluated TOE is in operation, it is - still possible that previously unknown errors or - vulnerabilities in the TOE may surface. In that case, the - developer may correct the TOE (to repair the - vulnerabilities) or change the ST to exclude the - vulnerabilities from the scope of the evaluation. In either - case, the old evaluation results may no longer be valid. - If it is deemed necessary that confidence is regained, - re-evaluation is needed. The CC may be used for this - re-evaluation, but detailed procedures for re-evaluation are - outside the scope of this part of the CC. - The goal of this annex is to explain the Security Target (ST) - concept. This annex does not define the criteria; this definition can be found in CC Part - 3 and is supported by the documents given in the bibliography. - This annex consists of four major parts: - What an ST must contain. This is - summarised in Subclause , and described in more detail - in Subclauses - . These subclauses describe the - mandatory contents of the ST, the interrelationships - between these contents, and provide examples. - How an ST should be used. This is - summarised in Subclause , and described in more detail in - subclause . These - subclauses describe how an ST should be used, and some of - the questions that can be answered with an ST. - Low Assurance STs. Low Assurance STs are - STs with reduced content. They are described in detail in - subclause . - Claiming compliance with - standards. Subclause describes how an ST writer can claim that - the TOE meets a particular standard. - - Figure portrays the mandatory - contents of an ST that are given in CC Part 3. Figure may also be used as a structural outline - of the ST, though alternative structures are allowed. For - instance, if the security requirements rationale is - particularly bulky, it could be included in an appendix of the - ST instead of in the security requirements subclause. The - separate subclauses of an ST and the contents of those - subclauses are briefly summarised below and explained in much - more detail in subclauses to . An ST normally contains: - an ST introduction containing three - narrative descriptions of the TOE on different levels of - abstraction; - a conformance claim, showing whether the - ST claims conformance to any PPs and/or packages, and if - so, to which PPs and/or packages; - a security problem definition, showing - threats, OSPs and assumptions; - security objectives, showing how the - solution to the security problem is divided between - security objectives for the TOE and security objectives - for the operational environment of the TOE; - extended components definition - (optional), where new components (i.e. those not included - in CC Part 2 or CC Part 3) may be defined. These new - components are needed to define extended functional and - extended assurance requirements; - security requirements, where a - translation of the security objectives for the TOE into a - standardised language is provided. This standardised - language is in the form of SFRs. Additionally this - subclause defines the SARs; - a TOE summary specification, showing how - the SFRs are implemented in the TOE. - - There also exists low assurance STs which have reduced - contents; these are described in detail in subclause . All other parts of this Annex assume an ST - with full contents.
- A typical ST fulfils two roles: - - Before and during the evaluation, the ST specifies - ``what is to be evaluated''. In this role, the ST serves - as a basis for agreement between the developer and the - evaluator on the exact security properties of the TOE - and the exact scope of the evaluation. Technical - correctness and completeness are major issues for this - role. Subclause describes how - the ST should be used in this role. - - After the evaluation, the ST specifies ``what was - evaluated''. In this role, the ST serves as a basis for - agreement between the developer or re-seller of the TOE - and the potential consumer of the TOE. The ST describes - the exact security properties of the TOE in an abstract - manner, and the potential consumer can rely on this - description because the TOE has been evaluated to meet - the ST. Ease of use and understandability are major - issues for this role. Subclause describes how the ST should be used - in this role. - - Two roles (among many) that an ST should not fulfil are: - a detailed specification: An ST is - designed to be a security specification on a relatively - high level of abstraction. An ST should, in general, not - contain detailed protocol specifications, detailed - descriptions of algorithms and/or mechanisms, long - description of detailed operations etc. - a complete specification: An ST is - designed to be a security specification and not a - general specification. Unless security-relevant, - properties such as interoperability, physical size and - weight, required voltage etc. should not be part of an - ST. This means that in general an ST may be a part of a - complete specification, but not a complete specification - itself. - - The ST introduction describes the TOE in a narrative way on - three levels of abstraction: - - the ST reference and the TOE reference, which provide - identification material for the ST and the TOE that the ST - refers to; - - the TOE overview, which briefly describes the TOE; - - the TOE description, which describes the TOE in more - detail. - - An ST contains a clear ST reference that identifies that - particular ST. A typical ST reference consists of title, - version, authors and publication date. An example of an ST - reference is ``MauveRAM Database ST, version 1.3, MauveCorp - Specification Team, 11 October 2002''. - An ST also contains a TOE reference that identifies the TOE - that claims conformance to the ST. A typical TOE reference - consists of developer name, TOE name and TOE version - number. An example of a TOE reference is ``MauveCorp - MauveRAM Database v2.11''. As a single TOE may be evaluated - multiple times, for instance by different consumers of that - TOE, and therefore have multiple STs, this reference is not - necessarily unique. - If the TOE is constructed from one or more well-known - products, it is allowed to reflect this in the TOE - reference, by referring to the product name(s). However, - this should not be used to mislead consumers: situations - where major parts or security functionalities were not - considered in the evaluation, yet the TOE reference does not - reflect this are not allowed. - The ST reference and the TOE reference facilitate indexing - and referencing the ST and TOE and their inclusion in - summaries of lists of evaluated TOEs/Products. - The TOE overview is aimed at potential consumers of a TOE - who are looking through lists of evaluated TOEs/Products to - find TOEs that may meet their security needs, and are - supported by their hardware, software and firmware. The - typical length of a TOE overview is several paragraphs. - To this end, the TOE overview briefly describes the usage of - the TOE and its major security features, identifies the TOE - type and identifies any major non-TOE - hardware/software/firmware required by the TOE. - The description of the usage and major security features - of the TOE is intended to give a very general idea of what - the TOE is capable of in terms of security, and what it - can be used for in a security context. This subclause - should be written for (potential) TOE consumers, - describing TOE usage and major security features in terms - of business operations, using language that TOE consumers - understand. - An example of this is ``The MauveCorp MauveRAM Database - v2.11 is a multi-user database intended to be used in a - networked environment. It allows 1024 users to be active - simultaneously. It allows password/token and biometric - authentication, protects against accidental data - corruption, and can roll-back ten thousand - transactions. Its audit features are highly configurable, - so as to allow detailed audit to be performed for some - users and transactions, while protecting the privacy of - other users and transactions.'' - The TOE overview identifies the general type of TOE, such - as: firewall, VPN-firewall, smart card, crypto-modem, - intranet, web server, database, web server and database, - LAN, LAN with web server and database, etc. - It may be the case that the TOE is not of a readily - available type, in which case ``none'' would be - acceptable. - In some cases, a TOE type can mislead consumers. Examples include: - - certain functionality can be expected of the TOE - because of its TOE type, but the TOE does not have - this functionality. Examples include: - - an ATM-card type TOE, which does not support any - identification/authentication functionality; - - a firewall type TOE, which does not support - protocols that are almost universally used; - - a PKI-type TOE, which has no certificate - revocation functionality. - - the TOE can be expected to operate in certain - operational environments because of its TOE type, but - it cannot do so. Examples include: - - a PC-operating system type TOE, which is unable to - function securely unless the PC has no network - connection, floppy drive, and CD/DVD-player; - - a firewall, which is unable to function securely - unless all users that can connect through that - firewall are benign. - - While some TOEs do not rely upon other IT, many TOEs - (notably software TOEs) rely on additional, non-TOE, - hardware, software and/or firmware. In the latter case, - the TOE overview is required to identify such non-TOE - hardware,software and/or firmware . A complete and fully - detailed identification of the additional hardware, - software and/or firmware is not necessary, but the - identification should be complete and detailed enough for - potential consumers to determine the major - hardware,software and/or firmware needed to use the TOE. - Example hardware/software/firmware identifications are: - - a standard PC with a 1GHz or faster processor and - 512MB or more RAM, running version 3.0 Update 6b, c, - or 7, or version 4.0 of the Yaiza operating system; - - a standard PC with a 1GHz or faster version processor - and 512MB or more RAM, running version 3.0 Update 6d - of the Yaiza operating system and the WonderMagic 1.0 - Graphics card with the 1.0 WM Driver Set; - - a standard PC with version 3.0 of the Yaiza OS (or - higher); - - a CleverCard SB2067 integrated circuit; - - a CleverCard SB2067 integrated circuit running v2.0 of - the QuickOS smart card operating system; - - the December 2002 installation of the LAN of the - Director-General's Office of the Department of - Traffic. - - A TOE description is a narrative description of the TOE, - likely to run to several pages. The TOE description should - provide evaluators and potential consumers with a general - understanding of the security capabilities of the TOE, in - more detail than was provided in the TOE overview. The TOE - description may also be used to describe the wider - application context into which the TOE will fit. - The TOE description discusses the physical scope of the TOE: - a list of all hardware, firmware, software and guidance - parts that constitute the TOE. This list should be described - at a level of detail that is sufficient to give the reader a - general understanding of those parts. - The TOE description should also discuss the logical scope of - the TOE: the logical security features offered by the TOE at - a level of detail that is sufficient to give the reader a - general understanding of those features. This description is - expected to be in more detail than the major security - features described in the TOE overview. - An important property of the physical and logical scopes is - that they describe the TOE in such a way that there remains - no doubt on whether a certain part or feature is in the TOE - or whether this part or feature is outside the TOE. This is - especially important when the TOE is intertwined with and - cannot be easily separated from non-TOE entities. - Examples where the TOE is intertwined with non-TOE entities - are: - - the TOE is a cryptographic co-processor of a smart card - IC, instead of the entire IC; - - the TOE is a smart card IC, except for the cryptographic - processor; - - the TOE is the Network Address Translation part of the - MinuteGap Firewall v18.5. - - This subclause of an ST describes how the ST conforms with: - - Part 2 and Part 3 of this International Standard; - - Protection Profiles (if any); - - Packages (if any). - - The description of how the ST conforms to the CC consists of - two items: the version of the CC that is used and whether the - ST contains extended security requirements or not (see - Subclause ). - The description of conformance of the ST to Protection - Profiles means that the ST lists the packages that conformance - is being claimed to. For an explanation of this, see Subclause - . - The description of conformance of the ST to packages means - that the ST lists the packages that conformance is being - claimed to. For an explanation of this, see Subclause . - The security problem definition defines the security problem - that is to be addressed. The security problem definition is, - as far as the CC is concerned, axiomatic. That is, - the process of deriving the security problem definition - falls outside the scope of the CC. - However, it should be noted that the usefulness of the - results of an evaluation strongly depends on the ST, and the - usefulness of the ST strongly depends on the quality of the - security problem definition. It is therefore often - worthwhile to spend significant resources and use - well-defined processes and analyses to derive a good - security problem definition. - Note that according to CC Part 3 it is not mandatory - to have statements in all subclauses, an ST with threats - does not need to have OSPs and vice versa. Also, any ST may - omit assumptions. - Also note that where the TOE is physically distributed, it - may be better to discuss the relevant threats, OSPs and - assumptions separately for distinct domains of the TOE - operational environment. - This subclause of the security problem definition shows - the threats that are to be countered by the TOE, its - operational environment, or a combination of the two. - A threat consists of an adverse action performed by a - threat agent on an asset. - Adverse actions are actions performed by a threat agent on - an asset. These actions influence one or more properties - of an asset from which that asset derives its value. - Threat agents may be described as individual entities, but - in some cases it may be better to describe them as types - of entities, groups of entities etc. - Examples of threat agents are hackers, users, computer - processes, and accidents. Threat agents may be further - described by aspects such as expertise, resources, - opportunity and motivation. - Examples of threats are: - - a hacker (with substantial expertise, standard - equipment, and being paid to do so) remotely copying - confidential files from a company network; - - a worm seriously degrading the performance of a - wide-area network; - - a system administrator violating user privacy; - - someone on the Internet listening in on confidential - electronic communication. - - This subclause of the security problem definition shows - the OSPs that are to be enforced by the TOE, its - operational environment, or a combination of the two. - OSPs are security rules, procedures, or guidelines imposed - (or presumed to be imposed) now and/or in the future by an - actual or hypothetical organisation in the operational - environment. OSPs may be laid down by an organisation - controlling the operational environment of the TOE, or - they may be laid down by legislative or regulatory - bodies. OSPs can apply to the TOE and/or the operational - environment of the TOE. - Examples of OSPs are: - - All products that are used by the Government must - conform to the National Standard for password - generation and encryption; - - Only users with System Administrator privilege and - clearance of Department Secret shall be allowed to - manage the Department Fileserver. - - This subclause of the security problem definition shows - the assumptions that are made on the operational - environment in order to be able to provide security - functionality. If the TOE is placed in an operational - environment that does not meet these assumptions, the TOE - may not be able to provide all of its security - functionality anymore. Assumptions can be on physical, - personnel and connectivity of the operational environment. - Examples of assumptions are: - - Assumptions on physical aspects of the operational environment: - - It is assumed that the TOE will be placed in a - room that is designed to minimise electromagnetic - emanations; - - It is assumed that the administrator consoles of - the TOE will be placed in a restricted access - area. - - Assumptions on personnel aspects of the operational - environment: - - It is assumed that users of the TOE will be - trained sufficiently in order to operate the TOE; - - It is assumed that users of the TOE are approved - for information that is classified as National - Secret; - - It is assumed that users of the TOE will not write - down their passwords. - - Assumptions on connectivity aspects of the operational - environment: - - It is assumed that a PC workstation with at least - 10GB of disk space is available to run the TOE on; - - It is assumed that the TOE is the only non-OS - application running on this workstation; - - It is assumed that the TOE will not be connected - to an untrusted network. - - Note that during the evaluation these assumptions are - considered to be true: they are not tested in any way. For - these reasons, assumptions can only be made on the - operational environment. Assumptions can never be made on - the behaviour of the TOE because an evaluation consists of - evaluating assertions made about the TOE and not by - assuming that assertions on the TOE are true. - The security objectives are a concise and abstract statement - of the intended solution to the problem defined by the - security problem definition. The role of the security - objectives is threefold: - - provide a high-level, natural language solution of the - problem; - - divide this solution into two part wise solutions, that - reflect that different entities each have to address a - part of the problem; - - demonstrate that these part wise solutions form a - complete solution to the problem. - - The security objectives consist of a set of short and - clear statements without overly much detail that together - form a high-level solution to the security problem. The - level of abstraction of the security objectives aims at - being clear and understandable to knowledgeable potential - consumers of the TOE. The security objectives are in - natural language. - In an ST the high-level security solution, as described by - the security objectives, is divided into two part wise - solutions. These part wise solutions are called the - security objectives for the TOE and the security - objectives for the operational environment. This reflects - that these part wise solutions are to be provided by two - different entities: the TOE, and the operational - environment. - The TOE provides security functionality to solve a - certain part of the problem defined by the security - problem definition. This part wise solution is called - the security objectives for the TOE and consists of a - set of objectives that the TOE should achieve in order - to solve its part of the problem. - Examples of security objectives for the TOE are: - - The TOE shall keep confidential the content of all - files transmitted between it and a Server; - - The TOE shall identify and authenticate all users - before allowing them access to the Transmission - Service provided by the TOE; - - The TOE shall restrict user access to data according - to the Data Access policy described in Annex 3 of - the ST. - - If the TOE is physically distributed, it may be better - to subdivide the ST subclause containing the security - objectives for the TOE into several sub-subclauses to - reflect this. - The operational environment of the TOE implements - technical and procedural measures to assist the TOE in - correctly providing its security functionality (which is - defined by the security objectives for the TOE). This - part wise solution is called the security objectives for - the operational environment and consists of a set of - statements describing the goals that the operational - environment should achieve. - Examples of security objectives for the operational - environment are: - - The operational environment shall provide a - workstation with the OS Inux version 3.01b to - execute the TOE on; - - The operational environment shall ensure that all - human TOE users receive appropriate training before - allowing them to work with the TOE; - - The operational environment of the TOE shall - restrict physical access to the TOE to - administrative personnel and maintenance personnel - accompanied by administrative personnel; - - The operational environment shall ensure the - confidentiality of the audit logs generated by the - TOE before sending them to the central Audit Server. - - If the operational environment of the TOE consists of - multiple sites, each with different properties, it may - be better to subdivide the ST subclause containing the - security objectives for the operational environment into - several sub-subclauses to reflect this. - The ST also contains a security objectives rationale - containing two subclauses: - - a tracing that shows which security objectives - address which threats, OSPs and assumptions; - - a set of justifications that shows that all threats, - OSPs, and assumptions are effectively addressed by - the security objectives. - - The tracing shows how the security objectives trace - back to the threats, OSPs and assumptions as described - in the security problem definition. - No spurious objectives: Each - security objective traces to at least one threat, - OSP or assumption. - Complete with respect to the security - problem definition: Each threat, OSP and - assumption has at least one security objective - tracing to it. - Correct tracing: Since - assumptions are always made by the TOE on the - operational environment, security objectives for - the TOE do not trace back to assumptions. The - tracings allowed by CC Part 3 are depicted in - Figure . -
- Multiple security objectives may trace to the same - threat, indicating that the combination of those - security objectives counters that threat. A similar - argument holds for OSPs and assumptions. - The security objectives rationale also demonstrates - that the tracing is effective: All the given threats, - OSPs and assumption are addressed (i.e. countered, - enforced and upheld respectively) if all security - objectives tracing to a particular threat, OSP or - assumption are achieved. - This demonstration analyses the effect of achieving - the relevant security objectives on countering the - threats, enforcing the OSPs and upholding the - assumptions and leads to the conclusion that this is - indeed the case. - In some cases, where parts of the security problem - definition very closely resemble some security - objectives, the demonstration can be very simple. An - example is: a threat ``T17: Threat agent X reads the - Confidential Information in transit between A and B'', - a security objective for the TOE: ``OT12: The TOE - shall ensure that all information transmitted between - A and B is kept confidential'', and a demonstration - ``T17 is directly countered by OT12''. - Countering a threat does not necessarily mean removing - that threat, it can also mean sufficiently diminishing - that threat or sufficiently mitigating that threat. - Examples of removing a threat are: - - removing the ability to execute the adverse action - from the threat agent; - - moving, changing or protecting the asset in such a - way that the adverse action is no longer - applicable to it; - - removing the threat agent (e.g. removing machines - from a network that frequently crash that - network). - - Examples of diminishing a threat are: - - restricting the ability of a threat agent to - perform adverse actions; - - restricting the opportunity to execute an adverse - action of a threat agent; - - reducing the likelihood of an executed adverse - action being successful; - - reducing the motivation to execute an adverse - action of a threat agent by deterrence; - - requiring greater expertise or greater resources - from the threat agent. - - Examples of mitigating the effects of a threat are: - - making frequent back-ups of the asset; - - obtaining spare copies of an asset; - - insuring an asset; - - ensuring that successful adverse actions are - always timely detected, so that appropriate action - can be taken. - - Based on the security objectives and the security - objectives rationale, the following conclusion can be - drawn: if all security objectives are achieved then the - security problem as defined in is - solved: all threats are countered, all OSPs are - enforced, and all assumptions are upheld. - In many cases the security requirements (see the next - subclause) in an ST are based on components in CC Part 2 - or CC Part 3. However, in some cases, there may be - requirements in an ST that are not based on components in - CC Part 2 or CC Part 3. In this case, new components - (extended components) must be defined, and this definition - should be done in the Extended Components Definition. For - more information on this, see Annex . - Note that this subclause is intended to contain only the - extended components and not the extended requirements - (requirements based on extended components). The extended - requirements should be included in the security - requirements (see the next subclause) and are for all - purposes the same as requirements based on components in - CC Part 2 or CC Part 3. - The security requirements consist of two groups of - requirements: - the security functional requirements - (SFRs): a translation of the security objectives for the - TOE into a standardised language; - the security assurance requirements - (SARs): a description of how assurance is to be gained - that the TOE meets the SFRs. - - These two groups are discussed in the following two subclauses: - The SFRs are a translation of the security objectives for - the TOE. They are usually at a more detailed level of - abstraction, but they have to be a complete translation - (the security objectives must be completely addressed) and - be independent of any specific technical solution - (implementation). The CC requires this translation into a - standardised language for several reasons: - - to provide an exact description of what is to be - evaluated. As security objectives for the TOE are - usually formulated in natural language, translation - into a standardised language enforces a more exact - description of the functionality of the TOE. - - to allow comparison between two STs. As different ST - authors may use different terminology in describing - their security objectives, the standardised language - enforces using the same terminology and concepts. This - allows easy comparison. - - There is no translation required in the CC for the - security objectives for the operational environment, - because the operational environment is not evaluated and - does therefore not require a description aimed at its - evaluation. See the bibliography for items relevant to the - security assessment of operational systems. - It may be the case that parts of the operational - environment are evaluated in another evaluation, but this - is out of scope for the current evaluation. For example: - an OS TOE may require a firewall to be present in its - operational environment. Another evaluation may - subsequently evaluate the firewall, but this evaluation - has nothing to do with the evaluation of the OS TOE. - The CC supports this translation in three ways: - - by providing a predefined precise ``language'' - designed to describe exactly what is to be - evaluated. This language is defined as a set of - components defined in CC Part 2. The use of this - language as a well-defined translation of the - security objectives for the TOE to SFRs is - mandatory, though some exceptions exist (see - Subclause ). - - by providing operations: mechanisms that allow the - ST writer to modify the SFRs to provide a more - accurate translation of the security objectives for - the TOE. This part of the CC defines the four - allowed operations: assignment, selection, - iteration, and refinement. These are described - further in Subclause . - - by providing dependencies: a mechanism that supports - a more complete translation to SFRs. In the CC Part - 2 language, an SFR can have a dependency on other - SFRs. This signifies that if an ST uses that SFR, it - generally needs to use those other SFRs as - well. This makes it much harder for the ST writer to - overlook including necessary SFRs and thereby - improves the completeness of the ST. Dependencies - are described further in Subclause . - - The ST also contains a security requirements rationale, - consisting of two subclauses about SFRs: - - a tracing that shows which SFRs address which - security objectives for the TOE; - - a set of justifications that shows that all security - objectives for the TOE are effectively addressed by - the SFRs. - - The tracing shows how the SFRs trace back to the - security objectives for the TOE as follows: - No spurious SFRs: Each SFR traces - back to at least one security objective. - Complete with respect to the security - objectives for the TOE: Each security - objective for the TOE has at least one SFR tracing - to it. - - Multiple SFRs may trace to the same security objective - for the TOE, indicating that the combination of those - security requirements meets that security objective - for the TOE. - The security requirements rationale demonstrates that - the tracing is effective: if all SFRs tracing to a - particular security objective for the TOE are - satisfied, that security objective for the TOE is - achieved. - This demonstration should analyse the effects of - satisfying the relevant SFRs on achieving the security - objective for the TOE and lead to the conclusion that - this is indeed the case. - In cases where SFRs very closely resemble security - objectives for the TOE, the demonstration can be very - simple. - The SARs are a description of how the TOE is to be - evaluated. This description uses a standardised language - for two reasons: - - to provide an exact description of how the TOE is to - be evaluated. Using a standardised language assists in - creating an exact description and avoids ambiguity. - - to allow comparison between two STs. As different ST - authors may use different terminology in describing - the evaluation, the standardised language enforces - using the same terminology and concepts. This allows - easy comparison. - - This standardised language is defined as a set of - components defined in CC Part 3. The use of this - language is mandatory, though some exceptions - exist. The CC enhances this language in two ways: - - by providing operations: mechanisms that allow the ST - writer to modify the SARs. The CC has four operations: - assignment, selection, iteration, and - refinement. These are described further in Subclause - . - - by providing dependencies: a mechanism that supports a - more complete translation to SARs. In CC Part 3 - language, an SAR can have a dependency on other - SARs. This signifies that if an ST uses that SAR, it - generally needs to use those other SARs as well. This - makes it much harder for the ST writer to overlook - including necessary SARs and thereby improves the - completeness of STs. Dependencies are described - further in Subclause . - - The ST also contains a security requirements rationale - that explains why this particular set of SARs was deemed - appropriate. There are no specific requirements for this - explanation. The goal for this explanation is to allow the - readers of the ST to understand the reasons why this - particular set was chosen. - An example of an inconsistency is if the security problem - description mentions threats where the threat agent is - very capable, and a low (or no) is - included in the SARs. - In the security problem definition of the ST, the security - problem is defined as consisting of threats, OSPs and - assumptions. In the security objectives subclause of the - ST, the solution is provided in the form of two - sub-solutions: - - security objectives for the TOE; - - security objectives for the operational environment. - - Additionally, a security objectives rationale is provided - showing that if all security objectives are achieved, the - security problem is solved: all threats are countered, all - OSPs are enforced, and all assumptions are upheld.
- In the security requirements subclause of the ST, the - security objectives for the TOE are translated to SFRs and - a security requirements rationale is provided showing that - if all SFRs are satisfied, all security objectives for the - TOE are achieved. - Additionally, a set of SARs is provided to show how the - TOE is evaluated, together with an explanation for - selecting these SARs. - All of the above can be combined into the statement: If - all SFRs and SARs are satisfied and all security - objectives for the operational environment are achieved, - then there exists assurance that the security problem as - defined in is solved: all - threats are countered, all OSPs are enforced, and all - assumptions are upheld. This is illustrated in Figure - . - The amount of assurance obtained is defined by the SARs, - and whether this amount of assurance is sufficient is - defined by the explanation for choosing these SARs. - The objective for the TOE summary specification is to provide - potential consumers of the TOE with a description of how the - TOE satisfies all the SFRs. The TOE summary specification - should provide the general technical mechanisms that the TOE - uses for this purpose. The level of detail of this description - should be enough to enable potential consumers to understand - the general form and implementation of the TOE. - For instance if the TOE is an Internet PC and the SFRs contain - to specify authentication, - the TOE summary specification should indicate how this - authentication is done: password, token, iris scanning - etc. More information, like applicable standards that the TOE - uses to meet SFRs, or more detailed descriptions may also be - provided. - After the evaluation, the ST specifies ``what was - evaluated''. In this role, the ST serves as a basis for - agreement between the developer or re-seller of the TOE and - the potential consumer of the TOE. The ST can therefore answer - the following questions (and more): - How can I find the ST/TOE that I need given the - multitude of existing STs/TOEs? This question is - addressed by the TOE overview, which gives a brief - (several paragraphs) summary of the TOE; - Does this TOE fit in with my existing - IT-infrastructure? This question is addressed by - the TOE overview, which identifies the major - hardware/firmware/software elements needed to run the TOE; - Does this TOE fit in with my existing operational - environment? This question is addressed by the - security objectives for the operational environment, which - identifies all constraints the TOE places on the - operational environment in order to function; - What does the TOE do (interested reader)? - This question is addressed by the TOE overview, which - gives a brief (several paragraphs) summary of the TOE; - What does the TOE do (potential - consumer)? This question is addressed by the TOE - description, which gives a less brief (several pages) - summary of the TOE; - What does the TOE do (technical)? This - question is addressed by the TOE summary specification - which provides a high-level description of the mechanisms - the TOE uses; - What does the TOE do (expert)? This - question is addressed by the SFRs which provide an - abstract highly technical description, and the TOE summary - specification which provide additional detail; - Does the TOE address the problem as defined by my - government/organisation? If your - government/organisation has defined packages and/or PPs to - define this solution, then the answer can be found in the - Conformance Claims subclause of the ST, which lists all - packages and PPs that the ST conforms to - Does the TOE address my security problem - (expert)? What are the threats countered by the - TOE? What organisational security policies does it - enforce? What assumptions does it make about the - operational environment? These questions are addressed by - the security problem definition; - How much trust can I place in the TOE? - This can be found in the SARs in the security requirements - subclause, which provide the assurance level that was used - to evaluate the TOE, and hence the trust that the - evaluation provides in the correctness of the TOE. - - Writing an ST is not a trivial task, and may, especially in - low assurance evaluations, be a major part of the total effort - expended by the developer and the evaluator in the whole of - the evaluation. For this reason, it is also possible to write - a low assurance ST. - The CC allows the use of a low assurance ST for an EAL 1 - evaluation, but not for EAL 2 and up. A low-assurance ST may - only claim conformance to a low-assurance PP (see ). A regular ST - (i.e., one with full contents) may claim conformance with a - low assurance PP. - A low assurance ST has a significantly reduced content - compared to a regular ST: - - there is no need to describe the security problem definition; - - there is no need to describe the security objectives for - the TOE. The security objectives for the operational - environment must still be described; - - there is no need to describe the security objectives - rationale as there is no security problem definition in - the ST; - - the security requirements rationale only needs to justify - (any) dependencies not being satisfied as there are no - security objectives for the TOE in the ST. - - All that remains are: - - the references to TOE and ST; - - a conformance claim; - - the various narrative descriptions; - - the TOE overview; - - the TOE description; - - the TOE summary specification. - - security objectives for the operational environment; - - the SFRs and the SARs (including the extended components - definition) and the security requirements rationale (only - if the dependencies are not satisfied). - - The reduced content of a low assurance ST is shown in Figure - .
- In some cases, an ST writer may wish to refer to an external - standard, such as a particular cryptographic standard or - protocol. The CC allows three ways of doing this: - - As an organisational security policy (or part of it). - - If, for example, there exists a government standard - defining how passwords have to be chosen, this may be - stated as an organisational security policy in an - ST. This may lead to an objective for the environment - (e. g. if users of the TOE need to choose passwords - accordingly), or it may lead to security objectives for - the TOE and then to appropriate SFRs (likely of the - class), if the TOE generates - passwords. In both cases the rationale of the developer - needs to make plausible that the security objectives for - the TOE and the SFRs are suitable to fulfil the OSP. The - evaluator will examine if this is in fact plausible (and - may decide to look into the standard for this), if the - OSP is implemented by SFRs, as explained below. - As a technical standard (for example a cryptographic - standard) used in a refinement of an SFR. - - In this case conformance to the standard is part of the - fulfilment of the SFR by the TOE and is treated as if - the full text of the standard is part of the - SFR. Conformance is subsequently determined like any - other conformance to SFRs: during and - it is analysed, by design analysis and - tests, that the SFR is completely and fully implemented - in the TOE. If reference to only a certain part of a - standard is desired, that part should be unambiguously - stated in the SFR refinement. - As a technical standard (for example a cryptographic - standard) mentioned in the TOE summary specification. - - The TOE summary specification is only considered as an - explanation of how the SFRs are realised, and is not - strictly used as a strict implementation requirement - like the SFRs or the documents delivered for . So the evaluator may detect an inconsistency - if the TSS references a technical standard and this is - not reflected in documentation, but - there is no routine activity to test fulfilment of the - standard. - The goal of this Annex is to explain the Protection Profile - (PP) concept. This Annex does not define the criteria; this definition can be found in - CC Part 3 and is supported by the documents given in the - bibliography. - As PPs and STs have a significant overlap, this Annex focuses - on the differences between PPs and STs. The material that is - identical between STs and PPs is described in . - This annex consists of four major parts: - What a PP must contain. This is - summarised in Subclause , and described in more detail - in Subclauses -. These clauses describe the - mandatory contents of the PP, the interrelationships - between these contents, and provide examples. - How a PP should be used. This is - summarised in Subclause . - Low Assurance PPs. Low Assurance PPs are - PPs with reduced content. They are described in detail in - Subclause . - Claiming compliance with - standards. Subclause describes how a PP writer can claim that - the TOE is to meet a particular standard. - - Figure portrays the - mandatory content for a PP that is given in - CC Part 3. Figure may - also be used as a structural outline of the PP, though - alternative structures are allowed. For instance, if the - security requirements rationale is particularly bulky, it - could be included in an appendix of the PP instead of in the - security requirements subclause. The separate subclauses of a - PP and the contents of those subclauses are briefly summarised - below and explained in much more detail in Subclauses - . A - PP contains: - - a PP introduction containing a narrative - description of the TOE type; - - a conformance claim, showing whether the - PP claims conformance to any PPs and/or packages, and if - so, to which PPs and/or packages; - - a security problem definition, showing - threats, OSPs and assumptions; - security objectives, showing how the - solution to the security problem is divided between - security objectives for the TOE and security objectives - for the operational environment of the TOE; - extended components definition, where new - components (i.e. those not included in CC Part 2 or - CC Part 3) may be defined. These new components are - needed to define extended functional and extended - assurance requirements; - security requirements, where a - translation of the security objectives for the TOE into a - standardised language is provided. This standardised - language is in the form of SFRs. Additionally this - subclause defines the SARs; - - There also exist low assurance PPs, which have reduced - contents; these are described in detail in Subclause . With this exception, all other - parts of this Annex assume a PP with full contents.
- A PP is typically a statement of need where a user - community, a regulatory entity, or a group of developers - define a common set of security needs. A PP gives consumers - a means of referring to this set, and facilitates future - evaluation against these needs. - A PP is therefore typically used as: - - part of a requirement specification for a specific - consumer or group of consumers, who will only consider - buying a specific type of IT if it meets the PP; - - part of a regulation from a specific regulatory entity, - who will only allow a specific type of IT to be used if - it meets the PP; - - a baseline defined by a group of IT developers, who then - agree that all IT that they produce of this type will - meet this baseline. - - though this does not preclude other uses. - Three roles (among many) that a PP should not fulfil are: - a detailed specification: A PP is - designed to be a security specification on a relatively - high level of abstraction. A PP should, in general, not - contain detailed protocol specifications, detailed - descriptions of algorithms and/or mechanisms, long - description of detailed operations etc. - a complete specification: A PP is - designed to be a security specification and not a general - specification. Unless security-relevant, properties such - as interoperability, physical size and weight, required - voltage etc. should not be part of a PP. This means that - in general a PP is a part of a complete specification, but - not a complete specification itself. - a specification of a single product: - Unlike an ST, a PP is designed to describe a certain type - of IT, and not a single product. When only a single - product is described, it is better to use an ST for this - purpose. - - The PP introduction describes the TOE in a narrative way on - two levels of abstraction: - - the PP reference, which provides identification material - for the PP; - - the TOE overview, which briefly describes the TOE. - - A PP contains a clear PP reference that identifies that - particular PP. A typical PP reference consists of title, - version, authors and publication date. An example of a PP - reference is ``Atlantean Navy CablePhone Encryptor PP, - version 2b, Atlantean Navy Procurement Office, April 7, - 2003''. The reference must be unique so that it is possible - to tell different PPs and different versions of the same PP - apart. - The PP reference facilitates indexing and referencing the PP - and its inclusion in lists of PPs. - The TOE overview is aimed at potential consumers of a TOE - who are looking through lists of evaluated products to find - TOEs that may meet their security needs, and are supported - by their hardware, software and firmware. - The TOE overview is also aimed at developers who may use the - PP in designing TOEs or in adapting existing products. - The typical length of a TOE overview is several paragraphs. - To this end, the TOE overview briefly describes the usage of - the TOE and its major security features, identifies the TOE - type and identifies any major non-TOE - hardware/software/firmware available to the TOE. - The description of the usage and major security features - of the TOE is intended to give a very general idea of what - the TOE should be capable of, and what it can be used - for. This subclause should be written for (potential) TOE - consumers, describing TOE usage and major security - features in terms of business operations, using language - that TOE consumers understand. - An example of this is ``The Atlantean Navy CablePhone - Encryptor is an encryption device that should allow - confidential communication between ships across the - Atlantean Navy CablePhone system. To this end it should - allow at least 32 different users and support at least 100 - Mbps encryption speed. It should allow both bilateral - communication between ships and broadcast across the - entire network.'' - The TOE overview identifies the general type of TOE, such - as: firewall, VPN-firewall, smart card, crypto-modem, - intranet, web server, database, web server and database, - LAN, LAN with web server and database, etc. - While some TOEs do not rely upon other IT, many TOEs - (notably software TOEs) rely on additional, non-TOE, - hardware, software and/or firmware. In the latter case, - the TOE overview is required to identify the non-TOE - hardware/software/firmware. - As a Protection Profile is not written for a specific - product, in many cases only a general idea can be given of - the available hardware/software/firmware. In some other - cases, e.g. a requirements specification for a specific - consumer where the platform is already known, (much) more - specific information may be provided. - Examples of hardware/software/firmware identifications - are: - - None. (for a completely stand-alone TOE); - - The Yaiza 3.0 Operating System running on a general - PC; - - a CleverCard SB2067 integrated circuit; - - a CleverCard SB2067 IC running v2.0 of the QuickOS - smart card operating system; - - the December 2002 installation of the LAN of the - Director-General's Office of the Department of - Traffic. - - This subclause of a PP describes how the PP conforms with - other PPs and with packages. It is identical to the - conformance claims subclause for an ST (see Subclause ), with one exception: - the conformance statement. - The conformance statement in the PP states how STs and/or - other PPs must conform to that PP. The PP author selects - whether ``strict'' or ``demonstrable'' conformance is - required. See - for more details on this. - This subclause is identical to the security problem definition - subclause of an ST as explained in Subclause . - This subclause is identical to the security objectives subclause - of an ST as explained in Subclause . - This subclause is identical to the extended components subclause - of an ST as explained in Subclause . - This subclause is identical to the security requirements - subclause of an ST as explained in Subclause . Note however that the rules for completing - operations in a PP are slightly different from the rules for - completing operations in an ST. This is explained in more - detail in Subclause . - A PP has no TOE summary specification. - A low assurance PP has the same relationship to a regular PP - (i.e., one with full contents), as a low assurance ST has to a - regular ST. This means that a low-assurance PP consists of - - a PP introduction, consisting of a PP reference and a TOE - overview; - - a conformance claim; - - security objectives for the operational environment; - - the SFRs and the SARs (including the extended components - definition) and the security requirements rationale (only - if the dependencies are not satisfied). - - A low-assurance PP may only claim conformance to a - low-assurance PP (see ). A - regular PP may claim conformance with a low assurance PP. - The reduced content of a low assurance PP is shown in Figure - .
- This subclause is identical to the subclause on standards for - STs as described in Subclause , with one exception: as a PP has no TOE - summary specification, the third option is not valid for PPs. - The PP author is reminded that referring to a standard in SFRs - may impose a significant burden on a developer developing a - TOE to meet that PP (depending on the size and complexity of - the standard and the assurance level required), and that it - may be more suitable to require alternative (non-CC related) - ways to assess conformance to that standard. - As described in this CC part 1, Protection Profiles and - Security Targets contain pre-defined security requirements, as - well as providing PP and ST authors the ability to extend the - component lists in some circumstances. - The four types of operations are given in section . Examples of the various - operations are described below: - As described in section - the iteration operation may be performed on every - component. The PP/ST author performs an iteration operation - by including multiple requirements based on the same - component. Each iteration of a component is different from - all other iterations of that component, which is realised by - completing assignments and selections in a different way, or - by applying refinements to it in a different way. Different - iterations should be uniquely identified to allow clear - rationales and tracings to and from these requirements. - A typical example of an iteration is - being iterated twice in order to require the implementation - of two different cryptographic algorithms. An example of - each iteration being uniquely identified is: - - Cryptographic operation (RSA and DSA signatures) - (FCS_COP.1(1)) - - Cryptographic operation (TLS/SSL: symmetric operations) - (FCS_COP.1(2)) - - As described in subclause - an assignment operation occurs where a given component - contains an element with a parameter that may be set by the - PP/ST author. The parameter may be an unrestricted variable, - or a rule that narrows the variable to a specific range of - values. - An example of an element with an assignment is: ``When the defined number of - unsuccessful authentication attempts has been met or - surpassed, the TSF shall [assignment: list of - actions].'' - As described in subclause - the selection operation occurs where a given component - contains an element where a choice from several items has to - be made by the PP/ST author. - An example of an element with a selection is: ``The TSF shall run a suite of - self tests [selection: during initial start-up, periodically - during normal operation, at the request of the authorised - user, at the conditions [assignment: conditions under which - self test should occur]] to demonstrate the correct - operation of ...'' - As described in subclause - the refinement operation can be performed on every - requirement. The PP/ST author performs a refinement by - altering that requirement. - An example of a valid refinement is ``The TSF shall require each user to be - successfully authenticated before allowing any other - TSF-mediated actions on behalf of that user.'' being refined - to ``The TSF shall require each user to be successfully - authenticated by username/password before - allowing any other TSF-mediated actions on behalf of that - user.'' - The first rule for a refinement is that a TOE meeting the - refined requirement also meets the unrefined requirement in - the context of the PP/ST (i.e. a refined requirement must be - ``stricter'' than the original requirement) - The only exception to this rule is that a PP/ST author is - allowed to refine a SFR to apply to some but not all - subjects, objects, operations, security attributes and/or - external entities. - An example of a such an exception is ``The TSF shall require each user to be - successfully authenticated before allowing any other - TSF-mediated actions on behalf of that user.'' being refined - to ``The TSF shall require each user originating from - the internet to be successfully authenticated before - allowing any other TSF-mediated actions on behalf of that - user.'' - The second rule for a refinement given is that the - refinement shall be related to the original component. For - example, refining an audit component with an extra element - on prevention of electromagnetic radiation is not allowed. - A special case of refinement is an editorial refinement, - where a small change is made in a requirement, - i.e. rephrasing a sentence due to adherence to proper - English grammar, or to make it more understandable to the - reader. This change is not allowed to modify the meaning of - the requirement in any way. Examples of editorial - refinements include: - - the SFR ``The TSF shall - continue to preserve a secure state when the following - failures occur: breakdown of one CPU'' - could be refined to - ``The TSF shall continue to preserve a secure state when - the following failure occurs: breakdown of one - CPU'' or even - ``The TSF shall continue to preserve a secure state when - one CPU breaks down''. - - The CC has organised the components in CC Part 2 and CC Part 3 - into hierarchical structures: - Classes, consisting ofFamilies, consisting ofComponents, consisting ofElements. - This organisation into a hierarchy of class - family - - component - element is provided to assist consumers, - developers and evaluators in locating specific components. - The CC presents functional and assurance components in - the same general hierarchical style and use the same - organisation and terminology for each. - An example of a class is the class that is - focused at identification of users, authentication of users - and binding of users and subjects. - An example of a family is the family - which is part of the class. This family - concentrates on the authentication of users. - An example of a component is which - concentrates on unforgeable authentication. - An example of an element is which - concentrates on the prevention of use of copied - authentication data. - Whenever a PP/ST author defines an extended component, - this has to be done in a similar manner to the existing CC - components: clear, unambiguous and evaluatable (it is - possible to systematically demonstrate whether a - requirement based on that component holds for a - TOE). Extended components must use similar labelling, - manner of expression, and level of detail as the existing - CC components. - The PP/ST author also has to make to sure that all - applicable dependencies of an extended component are - included in the definition of that extended - component. Examples of possible dependencies are: - - if an extended component refers to auditing, - dependencies to components of the - class may have to be included; - - if an extended component modifies or accesses data, - dependencies to components of the - family may have to be included; - - if an extended component uses a particular design - description a dependency to the appropriate family (e.g. Functional Specification) may - have to be included. - - In the case of an extended functional component, the PP/ST - author also has to include any applicable audit and - associated operations information in the definition of - that component, similar to existing CC Part 2 - components. In the case of an extended assurance - component, the PP/ST author also has to provide suitable - evaluation methodology for the component, similar to the - methodology provided in the CEM. - Extended components may be placed in existing families, in - which case the PP/ST writer has to show how these families - change. If they do not fit into an existing family, they - shall be placed in a new family. New families have to be - defined similarly to the CC. - New families may be placed in existing classes in which - case the PP/ST writer has to show how these classes - change. If they do not fit into an existing class, they - shall be placed in a new class. New classes have to be - defined similarly to the CC. - A PP is intended to be used as a ``template'' for an ST. That - is: the PP describes a set of user needs, while an ST that - conforms to that PP describes a TOE that satisfies those - needs. - Note that it is also possible for a PP to be used as a - template for another PP. That is PPs can claim conformance to - other PPs. This case is completely similar to that of an ST - vs. a PP. For clarity this Annex describes only the ST/PP - case, but it holds also for the PP/PP case. - The CC does not allow any form of partial conformance, so if a - PP is claimed, the PP or ST must fully conform to the - referenced PP or PPs. There are however two types of - conformance (``strict'' and demonstrable'') and the type of - conformance allowed is determined by the PP. That is, the PP - states (in the PP conformance statement, see subclause ) what the allowed types of conformance for the ST - are. This distinction between strict and demonstrable - conformance is applicable to each PP to which an ST may claim - conformance on an individual basis. This may mean that the ST - conforms strictly to some PPs and demonstrably to other - PPs. An ST is only allowed to conform to a PP in a - demonstrable manner, if the PP explicitly allows this, whereas - an ST can always conform with strict conformance to any PP. - Restating this in other words, an ST is only allowed to - conform to a PP in a demonstrable manner, if the PP explicitly - allows this. - Conformance to a PP means that the PP or ST (and if an ST is - of an evaluated product, the product as well) meets all - requirements of that PP. - Published PPs will normally require demonstrable - conformance. This means that STs claiming conformance with the - PP must offer a solution to the generic security problem - described in the PP, but can do so in any way that is - equivalent or more restrictive to that described in the - PP. ``Equivalent but more restrictive'' is defined at length - within the CC, but in principle it means that the PP - and ST may contain entirely different statements that discuss - different entities, use different concepts etc., provided that - overall the ST levies the same or more restrictions on the - TOE, and the same or less restrictions on the operational - environment of the TOE. - Strict conformance is oriented to the PP-author who requires - evidence that the requirements in the PP are met, that the ST - is an instantiation of the PP, though the ST could be broader - than the PP. In essence, the ST specifies that the TOE does at - least the same as in the PP, while the operational environment - does at most the same as in the PP. - A typical example of the use of strict conformance is in - selection based purchasing where a product's security - requirements are expected to exactly match those specified in - the PP. - An ST instantiating strict conformance to a PP can still - introduce additional restrictions to those given in the PP. - Demonstrable conformance is orientated to the PP-author who - requires evidence that the ST is a suitable solution to the - generic security problem described in the PP. - Where there is a clear subset-superset type relation between - PP and ST in the case of strict conformance, the relation is - less clear-cut in the case of demonstrable conformance. STs - claiming conformance with the PP must offer a solution to the - generic security problem described in the PP. but can do so in - any way that is equivalent or more restrictive to that - described in the PP. - This bibliography contains references to further material and - standards that the reader of the CC may find useful. For - undated references the reader is recommended to refer to the - latest edition of the referenced document.ISO/IEC 15292Information technology -- Security techniques -- - Protection Profile registration proceduresISO/IEC 15443Information technology -- Security techniques - -- A framework for IT security assurance - all partsISO/IEC 15446Information technology -- Security techniques - -- Guide for the production of Protection Profiles and Security - TargetsISO/IEC 19790Information technology -- Security techniques - -- Security requirements for cryptographic modulesISO/IEC 19791Information technology -- Security techniques - -- Security assessment of operational systemsISO/IEC 27001Information technology -- Security techniques - -- Information security management systems -- RequirementsISO/IEC 27002Information technology -- Security techniques - -- Code of practice for information security managementIEEE Std 610.12-1990 - Institute of Electrical and Electronics Engineers, Standard - Glossary of Software Engineering Terminology - CC portal - Common Criteria portal, February 2009. CCRA, www.commoncriteriaportal.org - - - - Table describes the - relationship between PPs and the families and components of the - class. - - - - - Assurance - class - Assurance family - Assurance component - - - Low Assurance PP - PP - - - - - Protection Profile evaluation - - 1 - 1 - - - - 1 - 1 - - - - 1 - 1 - - - - 1 - 2 - - - - 1 - 2 - - - - - 1 - - - - PP assurance level summary -
- - - - - - - - - - The following Subclauses describe the constructs used in - representing the assurance classes, families, and - components. - - Figure - illustrates the SARs defined in this CC Part 3. Note that the - most abstract collection of SARs is referred to as a - class. Each class contains assurance families, which then - contain assurance components, which in turn contain assurance - elements. Classes and families are used to provide a taxonomy - for classifying SARs, while components are used to specify - SARs in a PP/ST. - - - Figure - illustrates the assurance class structure. - - - Each assurance class is assigned a unique name. The name - indicates the topics covered by the assurance - class. - - A unique short form of the assurance class name is also - provided. This is the primary means for referencing the - assurance class. The convention adopted is an ``A'' - followed by two letters related to the class name. - - - - Each assurance class has an introductory Subclause that - describes the composition of the class and contains - supportive text covering the intent of the class. - - - - Each assurance class contains at least one assurance - family. The structure of the assurance families is - described in the following Subclause. - - -
- - - Figure - illustrates the assurance family structure. - - - Every assurance family is assigned a unique name. The name - provides descriptive information about the topics covered - by the assurance family. Each assurance family is placed - within the assurance class that contains other families - with the same intent. - - A unique short form of the assurance family name is also - provided. This is the primary means used to reference the - assurance family. The convention adopted is that the short - form of the class name is used, followed by an underscore, - and then three letters related to the family name. - - - - The objectives Subclause of the assurance family presents - the intent of the assurance family. - - This Subclause describes the objectives, particularly - those related to the CC assurance paradigm, that the - family is intended to address. The description for the - assurance family is kept at a general level. Any specific - details required for objectives are incorporated in the - particular assurance component. - - - - Each assurance family contains one or more assurance - components. This Subclause of the assurance family - describes the components available and explains the - distinctions between them. Its main purpose is to - differentiate between the assurance components once it has - been determined that the assurance family is a necessary - or useful part of the SARs for a PP/ST. - - Assurance families containing more than one component are - levelled and rationale is provided as to how the - components are levelled. This rationale is in terms of - scope, depth, and/or rigour. - - - - The application notes Subclause of the assurance family, - if present, contains additional information for the - assurance family. This information should be of particular - interest to users of the assurance family (e.g. PP and ST - authors, designers of TOEs, evaluators). The presentation - is informal and covers, for example, warnings about - limitations of use and areas where specific attention may - be required. - - - - Each assurance family has at least one assurance - component. The structure of the assurance components is - provided in the following Subclause. - - - - - Figure illustrates the - assurance component structure. -
- - The relationship between components within a family is - highlighted using a bolding convention. Those parts of the - requirements that are new, enhanced or modified beyond the - requirements of the previous component within a hierarchy - are bolded. - - - The component identification Subclause provides - descriptive information necessary to identify, categorise, - register, and reference a component. - - Every assurance component is assigned a unique name. The - name provides descriptive information about the topics - covered by the assurance component. Each assurance - component is placed within the assurance family that - shares its security objective. - - A unique short form of the assurance component name is - also provided. This is the primary means used to reference - the assurance component. The convention used is that the - short form of the family name is used, followed by a - period, and then a numeric character. The numeric - characters for the components within each family are - assigned sequentially, starting from 1. - - - - The objectives Subclause of the assurance component, if - present, contains specific objectives for the particular - assurance component. For those assurance components that - have this Subclause, it presents the specific intent of - the component and a more detailed explanation of the - objectives. - - - - The application notes Subclause of an assurance component, - if present, contains additional information to facilitate - the use of the component. - - - - Dependencies among assurance components arise when a - component is not self-sufficient, and relies upon the - presence of another component. - - Each assurance component provides a complete list of - dependencies to other assurance components. Some - components may list ``No dependencies'', to indicate that - no dependencies have been identified. The components - depended upon may have dependencies on other - components. - - The dependency list identifies the minimum set of - assurance components which are relied upon. Components - which are hierarchical to a component in the dependency - list may also be used to satisfy the dependency. - - In specific situations the indicated dependencies might - not be applicable. The PP/ST author, by providing - rationale for why a given dependency is not applicable, - may elect not to satisfy that dependency. - - - - A set of assurance elements is provided for each assurance - component. An assurance element is a security requirement - which, if further divided, would not yield a meaningful - evaluation result. It is the smallest security requirement - recognised in the CC. - - Each assurance element is identified as belonging to one - of the three sets of assurance elements: - - - Developer action elements: the activities that shall - be performed by the developer. This set of actions is - further qualified by evidential material referenced in - the following set of elements. Requirements for - developer actions are identified by appending the - letter ``D'' to the element number. - - - Content and presentation of evidence elements: the - evidence required, what the evidence shall - demonstrate, and what information the evidence shall - convey. Requirements for content and presentation of - evidence are identified by appending the letter ``C'' - to the element number. - - - Evaluator action elements: the activities that shall - be performed by the evaluator. This set of actions - explicitly includes confirmation that the requirements - prescribed in the content and presentation of evidence - elements have been met. It also includes explicit - actions and analysis that shall be performed in - addition to that already performed by the - developer. Implicit evaluator actions are also to be - performed as a result of developer action elements - which are not covered by content and presentation of - evidence requirements. Requirements for evaluator - actions are identified by appending the letter ``E'' - to the element number. - - - - The developer actions and content and presentation of - evidence define the assurance requirements that are used - to represent a developer's responsibilities in - demonstrating assurance in the TOE meeting the SFRs of a - PP or ST. - - The evaluator actions define the evaluator's - responsibilities in the two aspects of evaluation. The - first aspect is validation of the PP/ST, in accordance - with the classes and in Clauses and . The second - aspect is verification of the TOE's conformance with its - SFRs and SARs. By demonstrating that the PP/ST is valid - and that the requirements are met by the TOE, the - evaluator can provide a basis for confidence that the TOE - in its operational environment solves the defined security - problem. - - The developer action elements, content and presentation of - evidence elements, and explicit evaluator action elements, - identify the evaluator effort that shall be expended in - verifying the security claims made in the ST of the - TOE. - - - - - Each element represents a requirement to be met. These - statements of requirements are intended to be clear, - concise, and unambiguous. Therefore, there are no compound - sentences: each separable requirement is stated as an - individual element. - - - - This CC Part 3 contains classes of families and components - that are grouped on the basis of related assurance. At the - start of each class is a diagram that indicates the families - in the class and the components in each family. -
- - In Figure , - above, the class as shown contains a single family. The - family contains three components that are linearly - hierarchical (i.e. component 2 requires more than component - 1, in terms of specific actions, specific evidence, or - rigour of the actions or evidence). The assurance families - in this CC Part 3 are all linearly hierarchical, although - linearity is not a mandatory criterion for assurance - families that may be added in the future. - - - - - Figure illustrates - the EALs and associated structure defined in this CC Part - 3. Note that while the figure shows the contents of the - assurance components, it is intended that this information - would be included in an EAL by reference to the actual - components defined in the CC. -
- - - Each EAL is assigned a unique name. The name provides - descriptive information about the intent of the EAL. - - A unique short form of the EAL name is also provided. This - is the primary means used to reference the EAL. - - - - The objectives Subclause of the EAL presents the intent of - the EAL. - - - The application notes Subclause of the EAL, if present, - contains information of particular interest to users of the - EAL (e.g. PP and ST authors, designers of TOEs targeting - this EAL, evaluators). The presentation is informal and - covers, for example, warnings about limitations of use and - areas where specific attention may be required. - A set of assurance components have been chosen for each - EAL. - A higher level of assurance than that provided by a given - EAL can be achieved by: - - including additional assurance components from other - assurance families; or - - replacing an assurance component with a higher level - assurance component from the same assurance family. - - - - Figure - illustrates the relationship between the SARs and the - assurance levels defined in the CC. While assurance - components further decompose into assurance elements, - assurance elements cannot be individually referenced by - assurance levels. Note that the arrow in the figure - represents a reference from an EAL to an assurance component - within the class where it is defined. -
- - - - - The structure of the CAPs is similar to that of the EALs. The - main difference between these two types of package is the type - of TOE they apply to; the EALs applying to component TOEs and - the CAPs applying to composed TOEs. - - Figure illustrates - the CAPs and associated structure defined in this CC Part - 3. Note that while the figure shows the contents of the - assurance components, it is intended that this information - would be included in a CAP by reference to the actual - components defined in the CC. -
- - - Each CAP is assigned a unique name. The name provides - descriptive information about the intent of the CAP. - - A unique short form of the CAP name is also provided. This - is the primary means used to reference the CAP. - - - - The objectives Subclause of the CAP presents the intent of - the CAP. - - - The application notes Subclause of the CAP, if present, - contains information of particular interest to users of the - CAP (e.g. PP and ST authors, integrators of composed TOEs - targeting this CAP, evaluators). The presentation is - informal and covers, for example, warnings about limitations - of use and areas where specific attention may be - required. - A set of assurance components have been chosen for each - CAP. - Some dependencies identify the activities performed during - the evaluation of the dependent component on which the - composed TOE activity relies. Where it is not explicitly - identified that the dependency is on a dependent component - activity, the dependency is to another evaluation activity - of the composed TOE. - A higher level of assurance than that provided by a given - CAP can be achieved by: - - including additional assurance components from other - assurance families; or - - replacing an assurance component with a higher level - assurance component from the same assurance family. - - The components included in the CAP - assurance packages should not be used as augmentations for - component TOE evaluations, as this would provide no - meaningful assurance for the component. - - - Figure - illustrates the relationship between the SARs and the - composed assurance packages defined in the CC. While - assurance components further decompose into assurance - elements, assurance elements cannot be individually - referenced by assurance packages. Note that the arrow in the - figure represents a reference from a CAP to an assurance - component within the class where it is defined. -
- - - - - - - - This clause defines the content and presentation of the - functional requirements of the CC, and provides guidance on - the organisation of the requirements for new components to be - included in an ST. The functional requirements are expressed - in classes, families, and components. - - - - Figure illustrates the - functional class structure in diagrammatic form. Each - functional class includes a class name, class introduction, - and one or more functional families. - -
- - - - The class name subclause provides information necessary to - identify and categorise a functional class. Every - functional class has a unique name. The categorical - information consists of a short name of three - characters. The short name of the class is used in the - specification of the short names of the families of that - class. - - - - The class introduction expresses the common intent or - approach of those families to satisfy security - objectives. The definition of functional classes does not - reflect any formal taxonomy in the specification of the - requirements. - - The class introduction provides a figure describing the - families in this class and the hierarchy of the components - in each family, as explained in subclause . - - - - - - Figure - illustrates the functional family structure in diagrammatic - form. - -
- - - - The family name subclause provides categorical and - descriptive information necessary to identify and - categorise a functional family. Every functional family - has a unique name. The categorical information consists of - a short name of seven characters, with the first three - identical to the short name of the class followed by an - underscore and the short name of the family as follows - XXX_YYY. The unique short form of the family name provides - the principal reference name for the components. - - - - The family behaviour is the narrative description of the - functional family stating its security objective and a - general description of the functional requirements. These - are described in greater detail below: - - - The security objectives of the family - address a security problem that may be solved with the - help of a TOE that incorporates a component of this - family; - - - The description of the functional - requirements summarises all the requirements - that are included in the component(s). The description - is aimed at authors of PPs, STs and functional - packages who wish to assess whether the family is - relevant to their specific requirements. - - - - - - Functional families contain one or more components, any - one of which can be selected for inclusion in PPs, STs and - functional packages. The goal of this section is to - provide information to users in selecting an appropriate - functional component once the family has been identified - as being a necessary or useful part of their security - requirements. - - This section of the functional family description - describes the components available, and their - rationale. The exact details of the components are - contained within each component. - - The relationships between components within a functional - family may or may not be hierarchical. A component is - hierarchical to another if it offers more security. - - As explained in the descriptions of the - families provide a graphical overview of the hierarchy of - the components in a family. - - - - - The management clauses contain information for - the PP/ST authors to consider as management activities for a - given component. The clauses reference components of the - management class (FMT), and provide guidance regarding potential - management activities that may be applied via operations to - those components. - - A PP/ST author may select the indicated management components or - may include other management requirements not listed to detail - management activities. As such the information should be - considered informative. - - - - - The audit requirements contain auditable - events for the PP/ST authors to select, if requirements - from the class , are included in the - PP/ST. These requirements include security relevant events - in terms of the various levels of detail supported by the - components of the family. For example, - an audit note might include actions that are in terms of: - Minimal - successful use of the security mechanism; Basic - - any use of the security mechanism as well as relevant - information regarding the security attributes involved; - Detailed - any configuration changes made to the - mechanism, including the actual configuration values - before and after the change. - - It should be observed that the categorisation of auditable - events is hierarchical. For example, when Basic Audit - Generation is desired, all auditable events identified as - being both Minimal and Basic should be included in the - PP/ST through the use of the appropriate assignment - operation, except when the higher level event simply - provides more detail than the lower level event. When - Detailed Audit Generation is desired, all identified - auditable events (Minimal, Basic and Detailed) should be - included in the PP/ST. - - In the class the rules governing the audit - are explained in more detail. - - - - - - Figure illustrates the - functional component structure. - -
- - - - The component identification subclause provides - descriptive information necessary to identify, categorise, - register and cross-reference a component. The following is - provided as part of every functional component: - - A unique name. The name reflects the - purpose of the component. - - A short name. A unique short form of the - functional component name. This short name serves as the - principal reference name for the categorisation, - registration and cross-referencing of the component. This - short name reflects the class and family to which the - component belongs and the component number within the - family. - - A hierarchical-to list. A list of other - components that this component is hierarchical to and for - which this component can be used to satisfy dependencies - to the listed components. - - - - - A set of elements is provided for each component. Each - element is individually defined and is self-contained. - - A functional element is a security functional requirement - that if further divided would not yield a meaningful - evaluation result. It is the smallest security functional - requirement identified and recognised in the CC. - - When building packages, PPs and/or STs, it is not - permitted to select only one or more elements from a - component. The complete set of elements of a component - must be selected for inclusion in a PP, ST or package. - - A unique short form of the functional element name is - provided. For example the requirement name FDP_IFF.4.2 - reads as follows: F - functional requirement, DP - class - ``User data protection'', _IFF - - family ``Information flow control - functions'', .4 - 4th component named - ``Partial elimination of illicit information - flows'', .2 - 2nd element of the component. - - - - - Dependencies among functional components arise when a - component is not self sufficient and relies upon the - functionality of, or interaction with, another component - for its own proper functioning. - - Each functional component provides a complete list of - dependencies to other functional and assurance - components. Some components may list ``No - dependencies''. The components depended upon may in - turn have dependencies on other components. The list - provided in the components will be the direct - dependencies. That is only references to the functional - requirements that are required for this requirement to - perform its job properly. The indirect dependencies, that - is the dependencies that result from the depended upon - components can be found in - of this part of the CC. It is noted that in some cases the - dependency is optional in that a number of functional - requirements are provided, where each one of them would be - sufficient to satisfy the dependency (see for example - ). - - The dependency list identifies the minimum functional or - assurance components needed to satisfy the security - requirements associated with an identified - component. Components that are hierarchical to the - identified component may also be used to satisfy the - dependency. - - The dependencies indicated in CC Part 2 are - normative. They must be satisfied within a PP/ST. In - specific situations the indicated dependencies might not - be applicable. The PP/ST author, by providing the - rationale why it is not applicable, may leave the depended - upon component out of the package, PP or ST. - - - - - - - - - The grouping of the components in this part of the CC does not - reflect any formal taxonomy. - - This part of the CC contains classes of families and - components, which are rough groupings on the basis of related - function or purpose, presented in alphabetic order. At the - start of each class is an informative diagram that indicates - the taxonomy of each class, indicating the families in each - class and the components in each family. The diagram is a - useful indicator of the hierarchical relationship that may - exist between components. - - In the description of the functional components, a section - identifies the dependencies between the component and any - other components. - - In each class a figure describing the family hierarchy similar - to Figure , is provided. In Figure - the first family, Family 1, - contains three hierarchical components, where component 2 and - component 3 can both be used to satisfy dependencies on - component 1. Component 3 is hierarchical to component 2 and - can also be used to satisfy dependencies on component 2. - -
- - - In Family 2 there are three components not all of which are - hierarchical. Components 1 and 2 are hierarchical to no other - components. Component 3 is hierarchical to component 2, and - can be used to satisfy dependencies on component 2, but not to - satisfy dependencies on component 1. - - In Family 3, components 2, 3, and 4 are hierarchical to - component 1. Components 2 and 3 are both hierarchical to - component 1, but non-comparable. Component 4 is hierarchical - to both component 2 and component 3. - - These diagrams are meant to complement the text of the - families and make identification of the relationships - easier. They do not replace the ``Hierarchical - to:'' note in each component that is the mandatory - claim of hierarchy for each component. - - - The relationship between components within a family is - highlighted using a bolding - convention. This bolding convention calls for the bolding of - all new requirements. For hierarchical components, - requirements are bolded when they are - enhanced or modified beyond the requirements of the previous - component. In addition, any new or enhanced permitted - operations beyond the previous component are also - highlighted using bold type. - - - - - - This annex contains additional guidance for the families and - components defined in the elements of this CC Part 2, which - may be required by users, developers or evaluators to use the - components. To facilitate finding the appropriate information, - the presentation of the classes, families and components in - this annex is similar to the presentation within the elements. - - - - This clause defines the content and presentation of the notes - related to functional requirements of the CC. - - - - Figure below - illustrates the functional class structure in this annex. - -
- - - - This is the unique name of the class defined within the - normative elements of this part of the CC. - - - - - The class introduction in this annex provides information - about the use of the families and components of the - class. This information is completed with the informative - diagram that describes the organisation of each class with - the families in each class and the hierarchical - relationship between components in each family. - - - - - - Figure illustrates - the functional family structure for application notes in - diagrammatic form. - -
- - - - This is the unique name of the family defined within the - normative elements of this part of the CC. - - - - - The user notes contain additional information that is of - interest to potential users of the family, that is PP, ST - and functional package authors, and developers of TOEs - incorporating the functional components. The presentation - is informative, and might cover warnings about limitations - of use and areas where specific attention might be - required when using the components. - - - - - The evaluator notes contain any information that is of - interest to developers and evaluators of TOEs that claim - compliance with a component of the family. The - presentation is informative and can cover a variety of - areas where specific attention might be needed when - evaluating the TOE. This can include clarifications of - meaning and specification of the way to interpret - requirements, as well as caveats and warnings of specific - interest to evaluators. - - These User Notes and Evaluator Notes sections are not - mandatory and appear only if appropriate. - - - - - - Figure illustrates - the functional component structure for the application - notes. - -
- - - - This is the unique name of the component defined within - the normative elements of this part of the CC. - - - - - Any specific information related to the component can be - found in this section. - - - The rationale contains the specifics - of the rationale that refine the general statements on - rationale for the specific level, and should only be - used if level specific amplification is required. - - - The application notes contain - additional refinement in terms of narrative - qualification as it pertains to a specific - component. This refinement can pertain to user notes, - and/or evaluator notes as described in Subclause . This refinement can be - used to explain the nature of the dependencies - (e.g. shared information, or shared operation). - - - - This section is not mandatory and appears only if - appropriate. - - - - - This portion of each component contains advice relating to - the permitted operations of the component. - - This section is not mandatory and appears only if - appropriate. - - - - - - The following dependency tables for functional components - show their direct, indirect and optional dependencies. Each - of the components that is a dependency of some functional - component is allocated a column. Each functional component is - allocated a row. The value in the table cell indicate whether - the column label component is directly required (indicated by - a cross ``X''), indirectly required (indicated by a - dash ``-''), or optionally required (indicated by a - ``o'') by the row label component. An example of a - component with optional dependencies is , which requires either - or to be present. So if is present, is not - necessary and vice versa. If no character is presented, the - component is not dependent upon another component. - - - - - - Security auditing involves recognising, recording, storing, - and analysing information related to security relevant - activities (i.e. activities controlled by the TSF). The - resulting audit records can be examined to determine which - security relevant activities took place and whom (which user) - is responsible for them. - - - - CC audit families allow PP/ST authors the ability to define - requirements for monitoring user activities and, in some - cases, detecting real, possible, or imminent violations of - the enforcement of the SFRs. The TOE's security audit functions are - defined to help monitor security-relevant events, and act as a - deterrent against security violations. The requirements of the - audit families refer to functions that include audit data - protection, record format, and event selection, as well as - analysis tools, violation alarms, and real-time analysis. The - audit trail should be presented in human-readable format - either directly (e.g. storing the audit trail in - human-readable format) or indirectly (e.g. using audit - reduction tools), or both. - - While developing the security audit requirements, the PP/ST - author should take note of the inter-relationships among the - audit families and components. The potential exists to specify - a set of audit requirements that comply with the - family/component dependencies lists, while at the same time - resulting in a deficient audit function (e.g. an audit - function that requires all security relevant events to be - audited but without the selectivity to control them on any - reasonable basis such as individual user or object). - - - The implementation of audit requirements for networks and - other large systems may differ significantly from those - needed for stand-alone systems. Larger, more complex and - active systems require more thought concerning which audit - data to collect and how this should be managed, due to - lowered feasibility of interpreting (or even storing) what - gets collected. The traditional notion of a time-ordered list - or ``trail'' of audited events may not - be applicable in a global asynchronous network with - arbitrarily many events occurring at once. - - Also, different hosts and servers on a distributed TOE may - have differing naming policies and values. Symbolic names - presentation for audit review may require a net-wide - convention to avoid redundancies and ``name - clashes.'' - - A multi-object audit repository, portions of which are - accessible by a potentially wide variety of authorised - users, may be required if audit repositories are to serve a - useful function in distributed systems. - - Finally, misuse of authority by authorised users should be - addressed by systematically avoiding local storage of audit - data pertaining to administrator actions. - - - - - - - This family defines the response to be taken in case of - detected events indicative of a potential security - violation. - - - - The Security audit automatic response family describes - requirements for the handling of audit events. The - requirement could include requirements for alarms or TSF - action (automatic response). For example, the TSF could - include the generation of real time alarms, termination of - the offending process, disabling of a service, or - disconnection or invalidation of a user account. - - An audit event is defined to be an ``potential - security violation'' if so indicated by the - components. - - - - - - - - - An action should be taken for follow up action in the - event of an alarm. This action can be to inform the - authorised user, to present the authorised user with a set - of possible containment actions, or to take corrective - actions. The timing of the actions should be carefully - considered by the PP/ST author. - - - - At , the TSF shall take actions in - case a potential security violation is detected. - - - the management (addition, removal, or modification) of - actions. - - - Actions taken due to potential security violations. - - - The TSF shall take - - - list of actions - - - - the PP/ST author should specify the actions to be taken - in case of a potential security violation. An example of - such a list is: ``inform the authorised user, disable - the subject that created the potential security - violation.'' It can also specify that the action to be - taken can be specified by an authorised user. - - - upon detection of a potential security violation. - - - - - - - - This family defines requirements for recording the - occurrence of security relevant events that take place under - TSF control. This family identifies the level of auditing, - enumerates the types of events that shall be auditable by - the TSF, and identifies the minimum set of audit-related - information that should be provided within various audit - record types. - - - - The Security audit data generation family includes - requirements to specify the audit events that should be - generated by the TSF for security-relevant events. - - This family is presented in a manner that avoids a dependency - on all components requiring audit support. Each component has - an audit section developed in which the events to be audited - for that functional area are listed. When the PP/ST author - assembles the PP/ST, the items in the audit area are used to - complete the variable in this component. Thus, the - specification of what could be audited for a functional area - is localised in that functional area. - - The list of auditable events is entirely dependent on the - other functional families within the PP/ST. Each family - definition should therefore include a list of its - family-specific auditable events. Each auditable event in the - list of auditable events specified in the functional family - should correspond to one of the levels of audit event - generation specified in this family (i.e. minimal, basic, - detailed). This provides the PP/ST author with information - necessary to ensure that all appropriate auditable events are - specified in the PP/ST. The following example shows how - auditable events are to be specified in appropriate functional - families: - - ``The following actions should be auditable if is included in the PP/ST: - - - Minimal: Successful use of the user security attribute - administration functions; - - - Basic: All attempted uses of the user security attribute - administration functions; - - - Basic: Identification of which user security attributes - have been modified; - - - Detailed: With the exception of specific sensitive - attribute data items (e.g. passwords, cryptographic - keys), the new values of the attributes should be - captured.'' - - - - For each functional component that is chosen, the auditable - events that are indicated in that component, at and below the - level indicated in should be - auditable. If, for example, in the previous example ``Basic'' - would be selected in , the - auditable events mentioned in a), b) and c) should be - auditable. - - Observe that the categorisation of auditable events is - hierarchical. For example, when Basic Audit Generation is - desired, all auditable events identified as being either - Minimal or Basic, should also be included in the PP/ST - through the use of the appropriate assignment operation, - except when the higher level event simply provides more - detail than the lower level event. When Detailed Audit - Generation is desired, all identified auditable events - (Minimal, Basic, and Detailed) should be included in the - PP/ST. - - A PP/ST author may decide to include other auditable events - beyond those required for a given audit level. For example, - the PP/ST may claim only minimal audit capabilities while - including most of the basic capabilities because the few - excluded capabilities conflict with other PP/ST constraints - (e.g. because they require the collection of unavailable - data). - - The functionality that creates the auditable event should be - specified in the PP or ST as a functional requirement. - - The following are examples of the types of the events that - should be defined as auditable within each PP/ST functional - component: - - - Introduction of objects within the control of the TSF into a - subject's address space; - - - Deletion of objects; - - - Distribution or revocation of access rights or - capabilities; - - - Changes to subject or object security attributes; - - - Policy checks performed by the TSF as a result of a - request by a subject; - - - The use of access rights to bypass a policy check; - - - Use of Identification and Authentication functions; - - - Actions taken by an operator, and/or authorised user - (e.g. suppression of a TSF protection mechanism as - human-readable labels); - - - Import/export of data from/to removable media - (e.g. printed output, tapes, diskettes). - - - - - - - - - - - This component defines requirements to identify the - auditable events for which audit records should be - generated, and the information to be provided in the audit - records. - - by itself might be used - when the SFRs do not require that individual user identities - be associated with audit events. This could be appropriate - when the PP/ST also contains privacy requirements. If the - user identity must be incorporated could be used in addition. - - If the subject is a user, the user identity may be recorded as - the subject identity. The identity of the user may not yet been - verified if has not been - applied. Therefore in the instance of an invalid login the - claimed user identity should be recorded. It should be - considered to indicate when a recorded identity has not been - authenticated. - - - - There is a dependency on . If correctness of time is not an issue for - this TOE, elimination of this dependency could be - justified. - - - - defines the level of auditable - events, and specifies the list of data that shall be - recorded in each record. - - - The TSF shall be able to generate an audit record of the - following auditable events: - - - Start-up and shutdown of the audit functions; - - - All auditable events for the - - minimum - basic - detailed - not specified - - - the PP/ST author should select the level of - auditable events called out in the audit section of - other functional components included in the - PP/ST. This level is one of the following: - ``minimum'', ``basic'', ``detailed'' or ``not - specified''. - - - level of audit; and - - - - - other specifically defined auditable events - - - - the PP/ST author should assign a list of other - specifically defined auditable events to be included - in the list of auditable events. The assignment may - comprise none, or events that could be auditable - events of a functional requirement that are of a - higher audit level than requested in , as well as the - events generated through the use of a specified - Application Programming Interface (API). - - . - - - - - The TSF shall record within each audit record at least the - following information: - - - Date and time of the event, type of event, subject identity (if - applicable), and the outcome (success or failure) of the event; - and - - - For each audit event type, based on the auditable event - definitions of the functional components included in the - PP/ST, - - - other audit relevant information - - - - the PP/ST author should assign, for each auditable - events included in the PP/ST, either a list of other - audit relevant information to be included in audit - events records or none. - - . - - - - - - - - - - - - - This component addresses the requirement of accountability - of auditable events at the level of individual user - identity. This component should be used in addition to - . - - There is a potential conflict between the audit and privacy - requirements. For audit purposes it may be desirable to know - who performed an action. The user may want to keep his/her - actions to himself/herself and not be identified by other - persons (e.g. a site with job offers). Or it might be - required in the Organisational Security Policy that the - identity of the users must be protected. In those cases the - objectives for audit and privacy might contradict each - other. Therefore if this requirement is selected and privacy - is important, inclusion of the component user pseudonimity - might be considered. Requirements on determining the real - user name based on its pseudonym are specified in the - privacy class. - - If the identity of the user has not yet been verified through - authentication, in the instance of an invalid login the claimed - user identity should be recorded. It should be considered to - indicate when a recorded identity has not been authenticated. - - - - At , the TSF shall associate - auditable events to individual user identities. - - - For audit events resulting from actions of identified users, the - TSF shall be able to associate each auditable event with the - identity of the user that caused the event. - - - - - - - - This family defines requirements for automated means that - analyse system activity and audit data looking for possible or - real security violations. This analysis may work in support of - intrusion detection, or automatic response to a potential - security violation. - - The actions to be taken based on the detection can be - specified using the family as - desired. - - - - This family defines requirements for automated means that - analyse system activity and audit data looking for possible - or real security violations. This analysis may work in - support of intrusion detection, or automatic response to a - potential security violation. - - The action to be performed by the TSF on detection of a - potential violation is defined in components. - - For real-time analysis, audit data could be transformed into a - useful format for automated treatment, but into a different - useful format for delivery to authorised users for - review. - - - - - - - - - This component is used to specify the set of auditable - events whose occurrence or accumulated occurrence held to - indicate a potential violation of the enforcement of the - SFRs, and any rules to be used to perform the violation - analysis. - - - - In , basic threshold - detection on the basis of a fixed rule set is - required. - - - maintenance of the rules by (adding, modifying, deletion) - of rules from the set of rules. - - - Enabling and disabling of any of the analysis mechanisms; - - - Automated responses performed by the tool. - - - The TSF shall be able to apply a set of rules in monitoring - the audited events and based upon these rules indicate a - potential violation of the enforcement of the SFRs. - - - The TSF shall enforce the following rules for monitoring - audited events: - - - Accumulation or combination of - - - subset of defined auditable events - - - - the PP/ST author should identify the subset of - defined auditable events whose occurrence or - accumulated occurrence need to be detected as an - indication of a potential violation of the - enforcement of the SFRs. - - - known to indicate a potential security violation; - - - - - any other rules - - - - the PP/ST author should specify any other rules that - the TSF should use in its analysis of the audit - trail. Those rules could include specific - requirements to express the needs for the events to - occur in a certain period of time (e.g. period of - the day, duration). If there are no additional - rules that the TSF should use in the analysis of the - audit trail, this assignment can be completed with - ``none''. - - . - - - - - - - - - - - - - A profile is a structure that - characterises the behaviour of users and/or subjects; it - represents how the users/subjects interact with the TSF in - a variety of ways. Patterns of usage are established with - respect to the various types of activity the - users/subjects engage in (e.g. patterns in exceptions - raised, patterns in resource utilisation (when, which, - how), patterns in actions performed). The ways in which - the various types of activity are recorded in the profile - (e.g. resource measures, event counters, timers) are - referred to as profile metrics. - - Each profile represents the expected patterns of usage - performed by members of the profile target - group. This pattern may be based on past use - (historical patterns) or on normal use for users of - similar target groups (expected behaviour). A profile - target group refers to one or more users who interact with - the TSF. The activity of each member of the profile group - is used by the analysis tool in establishing the usage - patterns represented in the profile. The following are - some examples of profile target groups: - - - Single user account: one profile per - user; - - - Group ID or Group Account: one profile - for all users who possess the same group ID or operate - using the same group account; - - - Operating Role: one profile for all users - sharing a given operating role; - - - System: one profile for all users of a - system. - - - - Each member of a profile target group is assigned an - individual suspicion rating that - represents how closely that member's new - activity corresponds to the established patterns of usage - represented in the group profile. - - The sophistication of the anomaly detection tool will - largely be determined by the number of target profile - groups required by the PP/ST and the complexity of the - required profile metrics. - - - The PP/ST author should enumerate specifically what activity - should be monitored and/or analysed by the TSF. The PP/ST - author should also identify specifically what information - pertaining to the activity is necessary to construct the - usage profiles. - - requires that the TSF - maintain profiles of system usage. The word maintain implies - that the anomaly detector is actively updating the usage - profile based on new activity performed by the profile - target members. It is important here that the metrics for - representing user activity are defined by the PP/ST - author. For example, there may be a thousand different - actions an individual may be capable of performing, but the - anomaly detector may choose to monitor a subset of that - activity. Anomalous activity gets integrated into the - profile just like non-anomalous activity (assuming the tool - is monitoring those actions). Things that may have appeared - anomalous four months ago, might over time become the norm - (and vice-versa) as the user's work duties change. The TSF - wouldn't be able to capture this notion if it filtered out - anomalous activity from the profile updating - algorithms. - - Administrative notification should be provided such that - the authorised user understands the significance of the - suspicion rating. - - The PP/ST author should define how to interpret suspicion - ratings and the conditions under which anomalous activity is - indicated to the - mechanism. - - - - In , the TSF maintains - individual profiles of system usage, where a profile - represents the historical patterns of usage performed by - members of the profile target group. A profile target group - refers to a group of one or more individuals (e.g. a single - user, users who share a group ID or group account, users who - operate under an assigned role, users of an entire system or - network node) who interact with the TSF. Each member of a - profile target group is assigned an individual suspicion - rating that represents how well that member's current - activity corresponds to the established patterns of usage - represented in the profile. This analysis can be performed - at runtime or during a post-collection batch-mode - analysis. - - - maintenance (deletion, modification, addition) of the - group of users in the profile target group. - - - - The TSF shall be able to maintain profiles of system usage, - where an individual profile represents the historical - patterns of usage performed by the member(s) of - - - the profile target group - - - - the PP/ST author should specify the profile target - group. A single PP/ST may include multiple profile - target groups. - - . - - - The TSF shall be able to maintain a suspicion rating - associated with each user whose activity is recorded in a - profile, where the suspicion rating represents the degree to - which the user's current activity is found - inconsistent with the established patterns of usage - represented in the profile. - - - The TSF shall be able to indicate a possible violation of - the enforcement of the SFRs when a user's suspicion rating exceeds - the following threshold conditions - - - conditions under which anomalous activity is reported by - the TSF - - - - the PP/ST author should specify conditions under which - anomalous activity is reported by the TSF. Conditions - may include the suspicion rating reaching a certain - value, or be based on the type of anomalous activity - observed. - - . - - - - - - - - In practice, it is at best rare when an analysis tool can - detect with certainty when a security violation is - imminent. However, there do exist some system events that - are so significant that they are always worthy of - independent review. Example of such events include the - deletion of a key TSF security data file (e.g. the - password file) or activity such as a remote user - attempting to gain administrative privilege. These events - are referred to as signature events in that their - occurrence in isolation from the rest of the system - activity are indicative of intrusive activity. - - The complexity of a given tool will depend greatly on the - assignments defined by the PP/ST author in identifying the - base set of signature events. - - The PP/ST author should enumerate specifically what events - should be monitored by the TSF in order to perform the - analysis. The PP/ST author should identify specifically - what information pertaining to the event is necessary to - determine if the event maps to a signature event. - - Administrative notification should be provided such that - the authorised user understands the significance of the - event and the appropriate possible responses. - - An effort was made in the specification of these - requirements to avoid a dependency on audit data as the - sole input for monitoring system activity. This was done - in recognition of the existence of previously developed - intrusion detection tools that do not perform their - analyses of system activity solely through the use of - audit data (examples of other input data include network - datagrams, resource/accounting data, or combinations of - various system data). - - The elements of do not - require that the TSF implementing the immediate attack - heuristics be the same TSF whose activity is being - monitored. Thus, one can develop an intrusion detection - component that operates independently of the system whose - system activity is being analysed. - - - - In , the TSF shall be able - to detect the occurrence of signature events that represent - a significant threat to enforcement of the SFRs. This search - for signature events may occur in real-time or during a - post-collection batch-mode analysis. - - - maintenance (deletion, modification, addition) of the subset - of system events. - - - - The TSF shall be able to maintain an internal representation - of the following signature events - - - a subset of system events - - - - the PP/ST author should identify a base subset of system - events whose occurrence, in isolation from all other - system activity, may indicate a violation of the - enforcement of the SFRs. These include events that by - themselves indicate a clear violation to the enforcement - of the SFRs, or whose occurrence is so significant that - they warrant actions. - - - that may indicate a violation of the enforcement of the SFRs. - - - The TSF shall be able to compare the signature events - against the record of system activity discernible from an - examination of - - - the information to be used to determine system activity - - - - the PP/ST author should specify the information used to - determine system activity. This information is the input - data used by the analysis tool to determine the system - activity that has occurred on the TOE. This data may - include audit data, combinations of audit data with - other system data, or may consist of data other than the - audit data. The PP/ST author should define precisely - what system events and event attributes are being - monitored within the input data. - - . - - - The TSF shall be able to indicate a potential violation of the - enforcement of the SFRs when a system event is found to match - a signature event that indicates a potential violation of the - enforcement of the SFRs. - - - - - - - - In practice, it is at best rare when an analysis tool can - detect with certainty when a security violation is - imminent. However, there do exist some system events that - are so significant they are always worthy of independent - review. Example of such events include the deletion of a key - TSF security data file (e.g. the password file) or activity - such as a remote user attempting to gain administrative - privilege. These events are referred to as signature events - in that their occurrence in isolation from the rest of the - system activity are indicative of intrusive activity. Event - sequences are an ordered set of signature events that might - indicate intrusive activity. - - The complexity of a given tool will depend greatly on the - assignments defined by the PP/ST author in identifying the - base set of signature events and event sequences. - - The PP/ST author should enumerate specifically what events - should be monitored by the TSF in order to perform the - analysis. The PP/ST author should identify specifically - what information pertaining to the event is necessary to - determine if the event maps to a signature event. - - Administrative notification should be provided such that - the authorised user understands the significance of the - event and the appropriate possible responses. - - An effort was made in the specification of these - requirements to avoid a dependency on audit data as the - sole input for monitoring system activity. This was done - in recognition of the existence of previously developed - intrusion detection tools that do not perform their - analyses of system activity solely through the use of - audit data (examples of other input data include network - datagrams, resource/accounting data, or combinations of - various system data). Levelling, therefore, requires the - PP/ST author to specify the type of input data used to - monitor system activity. - - The elements of do not - require that the TSF implementing the complex attack - heuristics be the same TSF whose activity is being - monitored. Thus, one can develop an intrusion detection - component that operates independently of the system whose - system activity is being analysed. - - - - In , the TSF shall be able to - represent and detect multi-step intrusion scenarios. The - TSF is able to compare system events (possibly performed - by multiple individuals) against event sequences known to - represent entire intrusion scenarios. The TSF shall be - able to indicate when a signature event or event sequence - is found that indicates a potential violation of the - enforcement of the SFRs. - - - maintenance (deletion, modification, addition) of the subset - of system events; - - - maintenance (deletion, modification, addition) of the set of - sequence of system events. - - - - The TSF shall be able to maintain an internal representation - of the following event sequences of known intrusion - scenarios - - - list of sequences of system events whose occurrence are - representative of known penetration scenarios - - - - the PP/ST author should identify a base set of list of - sequences of system events whose occurrence are - representative of known penetration scenarios. These - event sequences represent known penetration - scenarios. Each event represented in the sequence should - map to a monitored system event, such that as the system - events are performed, they are bound (mapped) to the - known penetration event sequences. - - - and the following signature events - - - a subset of system events - - - - the PP/ST author should identify a base subset of - system events whose occurrence, in isolation from all - other system activity, may indicate a violation of the - enforcement of the SFRs. These include events that by themselves indicate - a clear violation to the SFRs, or whose occurrence is - so significant they warrant action. - - - that may indicate a potential - violation of the enforcement of the SFRs. - - - The TSF shall be able to compare the signature events and - event sequences against the record of system activity - discernible from an examination of - - - the information to be used to determine system activity - - - - the PP/ST author should specify the information used to - determine system activity. This information is the input - data used by the analysis tool to determine the system - activity that has occurred on the TOE. This data may - include audit data, combinations of audit data with - other system data, or may consist of data other than the - audit data. The PP/ST author should define precisely - what system events and event attributes are being - monitored within the input data. - - . - - - The TSF shall be able to indicate a potential violation of the - enforcement of the SFRs when system activity is found to match - a signature event or event sequence that indicates a potential - violation of the enforcement of the SFRs. - - - - - - - - This family defines the requirements for audit tools that - should be available to authorised users to assist in the - review of audit data. - - - - The Security audit review family defines requirements - related to review of the audit information. - - These functions should allow pre-storage or post-storage - audit selection that includes, for example, the ability to - selectively review: - - - the actions of one or more users (e.g. identification, - authentication, TOE entry, and access control actions); - - - the actions performed on a specific object or TOE - resource; - - - all of a specified set of audited exceptions; - or - - - actions associated with a specific SFR attribute. - - - - The distinction between audit reviews is based on - functionality. Audit review (only) encompasses the ability to - view audit data. Selectable review is more sophisticated, and - requires the ability to select subsets of audit data based on a - single criterion or multiple criteria with logical (i.e. and/or) - relations, and order the audit data before it is - reviewed. - - - - - - - - - This component will provide authorised users the - capability to obtain and interpret the information. In - case of human users this information needs to be in a - human understandable presentation. In case of external IT - entities the information needs to be unambiguously - represented in an electronic fashion. - - - - This component is used to specify that users and/or - authorised users can read the audit records. These audit - records will be provided in a manner appropriate to the - user. There are different types of users (human users, - machine users) that might have different needs. - - The content of the audit records that can be viewed can be - specified. - - - - , provides the capability to read - information from the audit records. - - - maintenance (deletion, modification, addition) of the group - of users with read access right to the audit records. - - - Reading of information from the audit records. - - - The TSF shall provide - - - authorised users - - - - the PP/ST author should specify the authorised users - that can use this capability. If appropriate the PP/ST - author may include security roles (see ). - - - with the capability to read - - - list of audit information - - - - the PP/ST author should specify the type of information - the specified user is permitted to obtain from the audit - records. Examples are ``all'', ``subject identity'', - ``all information belonging to audit records referencing - this user''. When employing the SFR, FAU_SAR.1, it is not - necessary to repeat, in full detail, the list of audit - information first specified in FAU_GEN.1. Use of terms - such as ``all'' or ``all audit information'' assist in - eliminating ambiguity and the further need for - comparative analysis between the two security - requirements. - - - from the audit records. - - - The TSF shall provide the audit records in a manner suitable - for the user to interpret the information. - - - - - - - - - - This component specifies that any users not identified in - will not be able to read - the audit records. - - - - , requires that there are - no other users except those that have been identified in - that can read the - information. - - - Unsuccessful attempts to read information from the audit - records. - - - The TSF shall prohibit all users read access to the audit - records, except those users that have been granted explicit - read-access. - - - - - - - - - - This component is used to specify that it should be - possible to perform selection of the audit data to be - reviewed. If based on multiple criteria, those criteria - should be related together with logical - (i.e. ``and'' or - ``or'') relations, and the tools - should provide the ability to manipulate audit data - (e.g. sort, filter). - - - - , requires audit review - tools to select the audit data to be reviewed based on - criteria. - - - the parameters used for the viewing. - - - The TSF shall provide the ability to apply - - methods of selection and/or ordering - - the PP/ST author should specify whether capabilities to - select and/or order audit data is required from the - TSF. - of audit data based on - - criteria with logical relations - - the PP/ST author should assign the criteria, possibly - with logical relations, to be used to select the audit - data for review. The logical relations are intended to - specify whether the operation can be on an individual - attribute or a collection of attributes. An example of - this assignment could be: ``application, user account - and/or location''. In this case the operation could be - specified using any combination of the three attributes: - application, user account and location.. - - - - - - - - This family defines requirements to select the set of events to - be audited during TOE operation from the set of all auditable - events. - - - - The Security audit event selection family provides - requirements related to the capabilities of identifying which - of the possible auditable events are to be audited. The - auditable events are defined in the family, but those events should be defined as - being selectable in this component to be audited. - - This family ensures that it is possible to keep the audit - trail from becoming so large that it becomes useless, by - defining the appropriate granularity of the selected - security audit events. - - - - - - - - - - This component defines the selection criteria used, and the - resulting audited subsets of the set of all auditable events, - based on user attributes, subject attributes, object attributes, - or event types. - - The existence of individual user identities is not assumed - for this component. This allows for TOEs such as routers - that may not support the notion of users. - - For a distributed environment, the host identity could be - used as a selection criteria for events to be audited. - - The management function - will handle the rights of authorised users to query or - modify the selections. - - - , requires the ability to - select the set of events to be audited from the set of all - auditable events, identified in , based upon attributes to be specified by the - PP/ST author. - - - maintenance of the rights to view/modify the audit events. - - - All modifications to the audit configuration that occur - while the audit collection functions are operating. - - - The TSF shall be able to select the set of events to be audited from - the set of all auditable events based on the following - attributes: - object identityuser identitysubject identityhost identityevent type - the PP/ST author should select whether the - security attributes upon which audit selectivity - is based, is related to object identity, user - identity, subject identity, host identity, or event type. - list of additional attributes that audit selectivity is based upon - - the PP/ST author should specify any additional - attributes upon which audit selectivity is based. If - there are no additional rules upon which audit - selectivity is based, this assignment can be - completed with ``none''. - - - - - - - This family defines the requirements for the TSF to be able - to create and maintain a secure audit trail. Stored audit - records refers to those records within the audit trail, and - not the audit records that have been retrieved (to temporary - storage) through selection. - - - - The Security audit event storage family describes - requirements for storing audit data for later use, including - requirements controlling the loss of audit information due - to TOE failure, attack and/or exhaustion of storage - space. - - - - - - - - In a distributed environment, as the location of the audit - trail is in the TSF, but not necessarily co-located with - the function generating the audit data, the PP/ST author - could request authentication of the originator of the - audit record, or non-repudiation of the origin of the - record prior storing this record in the audit trail. - - The TSF will protect the stored audit records in the audit trail from unauthorised - deletion and modification. It is noted that in some TOEs the - auditor (role) might not be authorised to delete the audit - records for a certain period of time. - - - - At , requirements are - placed on the audit trail. It will be protected from - unauthorised deletion and/or modification. - - - The TSF shall protect the stored audit records in the audit - trail from unauthorised deletion. - - - The TSF shall be able to preventdetect the PP/ST author should specify whether the TSF - shall prevent or only be able to detect modifications of the - stored audit records in the audit trail. Only one of these - options may be - chosen. unauthorised - modifications to the stored audit records in the audit trail. - - - - - - - - - - - This component allows the PP/ST author to specify to which - metrics the audit trail should conform. - - In a distributed environment, as the location of the audit - trail is in the TSF, but not necessarily co-located with - the function generating the audit data, the PP/ST author - could request authentication of the originator of the - audit record, or non-repudiation of the origin of the - record prior storing this record in the audit trail. - - - - , specifies the guarantees - that the TSF maintains over the audit data given the - occurrence of an undesired condition. - - - maintenance of the parameters that control the audit storage - capability. - - - The TSF shall protect the stored audit records in the audit trail from - unauthorised deletion. - - - The TSF shall be able to preventdetect the PP/ST author should specify whether the TSF - shall prevent or only be able to detect modifications of the - stored audit records in the audit trail. Only one of these - options may be - chosen. unauthorised - modifications to the stored audit records in the audit trail. - - - The TSF shall ensure that - - - metric for saving audit records - - - - the PP/ST author should specify the metric that the TSF - must ensure with respect to the stored audit - records. This metric limits the data loss by enumerating - the number of records that must be kept, or the time - that records are guaranteed to be maintained. An example - of the metric could be ``100,000'' indicating that - 100,000 audit records can be stored. - - - stored audit records will be maintained when the - following conditions occur: - - audit storage exhaustion - failure - attack - - - the PP/ST author should specify the condition under which the - TSF shall still be able to maintain a defined amount of audit - data. This condition can be any of the following: audit - storage exhaustion, failure, attack. - - - - - - - - - - - - This component requires that actions will be taken when - the audit trail exceeds certain pre-defined limits. - - - - , specifies actions to be taken if a - threshold on the audit trail is exceeded. - - - maintenance of the threshold; - - - maintenance (deletion, modification, addition) of actions to - be taken in case of imminent audit storage failure. - - - Actions taken due to exceeding of a threshold. - - - The TSF shall - - - actions to be taken in case - of possible audit storage failure - - - - the PP/ST author should indicate the pre-defined - limit. If the management functions indicate that this - number might be changed by the authorised user, this - value is the default value. The PP/ST author might - choose to let the authorised user define this - limit. In that case the assignment can be for example - ``an authorised user set limit''. - - - if the audit trail exceeds - - - pre-defined limit - - - - the PP/ST author should specify actions that should be - taken in case of imminent audit storage failure - indicated by exceeding the threshold. Actions might - include informing an authorised user. - - . - - - - - - - - - - - This component specifies the behaviour of the TOE if the audit - trail is full: either audit records are ignored, or the TOE is - frozen such that no audited events can take place. The - requirement also states that no matter how the requirement is - instantiated, the authorised user with specific rights to this - effect, can continue to generate audited events (actions). The - reason is that otherwise the authorised user could not even - reset the TOE. Consideration should be given to the choice of - the action to be taken by the TSF in the case of audit storage - exhaustion, as ignoring events, which provides better - availability of the TOE, will also permit actions to be - performed without being recorded and without the user being - accountable. - - - - , specifies actions in case the - audit trail is full. - - - maintenance (deletion, modification, addition) of actions to - be taken in case of audit storage failure. - - - Actions taken due to the audit storage failure. - - - The TSF shall - ``ignore audited - events''``prevent audited events, - except those taken by the authorised user with special - rights'' - ``overwrite the oldest stored audit - records'' - - the PP/ST author should select whether the TSF shall ignore - audited actions, or whether it should prevent audited - actions from happening, or whether the oldest audit records - should be overwritten when the TSF can no longer store audit - records. Only one of these options may be chosen. - and - - other actions to be taken in case of audit storage - failure - - the PP/ST author should specify other actions that should be - taken in case of audit storage failure, such as informing the - authorised user. If there is no other action to be taken in - case of audit storage failure, this assignment can be - completed with ``none''. - if the audit trail is full. - - - - - - - - This class provides two families specifically concerned with - assuring the identity of a party participating in a data - exchange. These families are related to assuring the identity - of the originator of transmitted information (proof of origin) - and assuring the identity of the recipient of transmitted - information (proof of receipt). These families ensure that an - originator cannot deny having sent the message, nor can the - recipient deny having received it. - - - - This class describes requirements specifically of interest for - TOEs that are used for the transport of information. Families - within this class deal with non-repudiation. - - In this class the concept of ``information'' is - used. This information should be interpreted as the object - being communicated, and could contain an electronic mail - message, a file, or a set of predefined attribute types. - - In the literature, the terms ``proof of receipt'' - and ``proof of origin'' are commonly used - terms. However it is recognised that the term - ``proof'' might be interpreted in a legal sense to - imply a form of mathematical rationale. The components in this - class interpret the de-facto use of the word - ``proof'' in the context of ``evidence'' - that the TSF demonstrates the non-repudiated transport of - types of information. - - - - - - Non-repudiation of origin ensures that the originator of - information cannot successfully deny having sent the - information. This family requires that the TSF provide a - method to ensure that a subject that receives information - during a data exchange is provided with evidence of the - origin of the information. This evidence can then be - verified by either this subject or other subjects. - - - - Non-repudiation of origin defines requirements to provide - evidence to users/subjects about the identity of the - originator of some information. The originator cannot - successfully deny having sent the information because - evidence of origin (e.g. digital signature) provides - evidence of the binding between the originator and the - information sent. The recipient or a third party can verify - the evidence of origin. This evidence should not be - forgeable. - - If the information or the associated attributes are altered - in any way, validation of the evidence of origin might - fail. Therefore a PP/ST author should consider including - integrity requirements such as in the - PP/ST. - - In non-repudiation there are several different roles - involved, each of which could be combined in one or more - subjects. The first role is a subject that requests evidence - of origin (only in ). The second role - is the recipient and/or other subjects to which the evidence - is provided (e.g. a notary). The third role is a subject - that requests verification of the evidence of origin, for - example, a recipient or a third party such as an arbiter. - - The PP/ST author must specify the conditions that must be - met to be able to verify the validity of the evidence. An - example of a condition which could be specified is where the - verification of evidence must occur within 24 hours. These - conditions, therefore, allow the tailoring of the - non-repudiation to legal requirements, such as being able to - provide evidence for several years. - - In most cases, the identity of the recipient will be the - identity of the user who received the transmission. In some - instances, the PP/ST author does not want the user identity - to be exported. In that case the PP/ST author must consider - whether it is appropriate to include this class, or whether - the identity of the transport service provider or the - identity of the host should be used. - - In addition to (or instead of) the user identity, a PP/ST - author might be more concerned about the time the - information was transmitted. For example, requests for - proposals must be transmitted before a certain date in order - to be considered. In such instances, these requirements can - be customised to provide a timestamp indication (time of - origin). - - - - - - - - - , requires the TSF to provide - subjects with the capability to request evidence of the - origin of information. - - - The management of changes to information types, fields, - originator attributes and recipients of evidence. - - - The identity of the user who requested that evidence of - origin would be generated. - - - The invocation of the non-repudiation service. - - - Identification of the information, the destination, and a - copy of the evidence provided. - - - The identity of the user who requested a verification of the - evidence. - - - - The TSF shall be able to generate evidence of origin for - transmitted - - - list of information types - - - - the PP/ST author should fill in the types of - information subject to the evidence of origin - function, for example, electronic mail messages. - - - at the request of the - - - originator - - - recipient - - - - - list of third parties - - - - the PP/ST author, dependent on the selection, should specify the third - parties that can request evidence of origin. A third party could be an - arbiter, judge or legal body. - - - - - - the PP/ST author should specify the user/subject who - can request evidence of origin. - - . - - - The TSF shall be able to relate the - - - list of attributes - - - - the PP/ST author should fill in the list of the - attributes that shall be linked to the information; - for example, originator identity, time of origin, and - location of origin. - - - of the originator of the information, and the - - list of information fields - - - the PP/ST author should fill in the list of - information fields within the information over which - the attributes provide evidence of origin, such as the - body of a message. - - - of the information to which the evidence applies. - - - The TSF shall provide a capability to verify the evidence of - origin of information to - - - originator - - - recipient - - - - - list of third parties - - - - the PP/ST author, dependent on the selection, - should specify the third parties that can verify - the evidence of origin. - - - - - - the PP/ST author should specify the user/subject who - can verify the evidence of origin. - - - given - - - limitations on the evidence of origin - - - - the PP/ST author should fill in the list of - limitations under which the evidence can be - verified. For example the evidence can only be - verified within a 24 hour time interval. An assignment - of ``immediate'' or - ``indefinite'' is acceptable. - - . - - - - - - - - - - - , requires that the TSF always - generate evidence of origin for transmitted information. - - - - The invocation of the non-repudiation service. - - - Identification of the information, the destination, and a - copy of the evidence provided. - - - The identity of the user who requested a verification of the - evidence. - - - - The TSF shall enforce the generation of evidence of origin - for transmitted - - - list of information types - - - - the PP/ST author should fill in the types of - information subject to the evidence of origin - function, for example, electronic mail messages. - - - at all times. - - - The TSF shall be able to relate the - - - list of attributes - - - - the PP/ST author should fill in the list of the - attributes that shall be linked to the information; - for example, originator identity, time of origin, and - location of origin. - - - of the originator of the information, and the - - - list of information fields - - - - the PP/ST author should fill in the list of - information fields within the information over which - the attributes provide evidence of origin, such as the - body of a message. - - - of the information to which the evidence applies. - - - The TSF shall provide a capability to verify the evidence of - origin of information to - - - originator - - - recipient - - - - - list of third parties - - - - the PP/ST author, dependent on the selection, - should specify the third parties that can verify - the evidence of origin. A third party could be an - arbiter, judge or legal body. - - - - - - the PP/ST author should specify the user/subject who - can verify the evidence of origin. - - - given - - - limitations on the evidence of origin - - - - the PP/ST author should fill in the list of - limitations under which the evidence can be - verified. For example the evidence can only be - verified within a 24 hour time interval. An assignment - of ``immediate'' or - ``indefinite'' is acceptable. - - . - - - - - - - - Non-repudiation of receipt ensures that the recipient of - information cannot successfully deny receiving the - information. This family requires that the TSF provide a - method to ensure that a subject that transmits information - during a data exchange is provided with evidence of receipt - of the information. This evidence can then be verified by - either this subject or other subjects. - - - - Non-repudiation of receipt defines requirements to provide - evidence to other users/subjects that the information was - received by the recipient. The recipient cannot successfully - deny having received the information because evidence of - receipt (e.g. digital signature) provides evidence of the - binding between the recipient attributes and the - information. The originator or a third party can verify the - evidence of receipt. This evidence should not be forgeable. - - It should be noted that the provision of evidence that the - information was received does not necessarily imply that the - information was read or comprehended, but only delivered - - If the information or the associated attributes are altered - in any way, validation of the evidence of receipt with - respect to the original information might fail. Therefore a - PP/ST author should consider including integrity - requirements such as in the PP/ST. - - In non-repudiation, there are several different roles - involved, each of which could be combined in one or more - subjects. The first role is a subject that requests evidence - of receipt (only in ). The second role - is the recipient and/or other subjects to which the evidence - is provided, (e.g. a notary). The third role is a subject - that requests verification of the evidence of receipt, for - example, an originator or a third party such as an arbiter. - - The PP/ST author must specify the conditions that must be - met to be able to verify the validity of the evidence. An - example of a condition which could be specified is where the - verification of evidence must occur within 24 hours. These - conditions, therefore, allow the tailoring of the - non-repudiation to legal requirements, such as being able to - provide evidence for several years. - - In most cases, the identity of the recipient will be the - identity of the user who received the transmission. In some - instances, the PP/ST author does not want the user identity - to be exported. In that case, the PP/ST author must consider - whether it is appropriate to include this class, or whether - the identity of the transport service provider or the - identity of the host should be used. - - In addition to (or instead of) the user identity, a PP/ST - author might be more concerned about the time the - information was received. For example, when an offer expires - at a certain date, orders must be received before a certain - date in order to be considered. In such instances, these - requirements can be customised to provide a timestamp - indication (time of receipt). - - - - - - - - - , requires the TSF to provide - subjects with a capability to request evidence of the - receipt of information. - - - The management of changes to information types, fields, - originator attributes and third parties recipients of - evidence. - - - The identity of the user who requested that evidence of - receipt would be generated. - - - The invocation of the non-repudiation service. - - - Identification of the information, the destination, and a - copy of the evidence provided. - - - The identity of the user who requested a verification of the - evidence. - - - The TSF shall be able to generate - evidence of receipt for received - - - list of information types - - - - the PP/ST author should fill in the types of - information subject to the evidence of receipt - function, for example, electronic mail messages. - - - at the request of the - - - originator - - - recipient - - - - - list of third parties - - - - the PP/ST author, dependent on the selection, - should specify the third parties that can request - evidence of receipt. A third party could be an - arbiter, judge or legal body. - - - - - - the PP/ST author should specify the user/subject who - can request evidence of receipt. - - . - - - The TSF shall be able to relate the - - list of attributes - - - the PP/ST author should fill in the list of the - attributes that shall be linked to the information; - for example, recipient identity, time of receipt, and - location of receipt. - - - of the recipient of the information, and the - - - list of information fields - - - - the PP/ST author should fill in the list of - information fields with the fields within the - information over which the attributes provide evidence - of receipt, such as the body a message. - - - of the information to which the evidence applies. - - - The TSF shall provide a capability to verify the evidence of - receipt of information to - - - originator - - - recipient - - - - - list of third parties - - - - the PP/ST author, dependent on the selection, - should specify the third parties that can verify - the evidence of receipt. - - - - - - the PP/ST author should specify the user/subjects who - can verify the evidence of receipt. - - - given - - - limitations on the evidence of receipt - - - - the PP/ST author should fill in the list of - limitations under which the evidence can be - verified. For example the evidence can only be - verified within a 24 hour time interval. An assignment - of ``immediate'' or - ``indefinite'' is acceptable. - - . - - - - - - - - - - - , requires that the TSF always - generate evidence of receipt for received information. - - - - The invocation of the non-repudiation service. - - - Identification of the information, the destination, and a - copy of the evidence provided. - - - The identity of the user who requested a verification of the - evidence. - - - - The TSF shall enforce the generation of evidence of receipt - for received - - list of information types - - the PP/ST author should fill in the types of - information subject to the evidence of receipt - function, for example electronic mail messages. at all times. - - - The TSF shall be able to relate the - - list of attributes - - - the PP/ST author should fill in the list of the - attributes that shall be linked to the information; - for example, recipient identity, time of receipt, and - location of receipt. - - - of the recipient of the information, and the - - - list of information fields - - - - the PP/ST author should fill in the list of - information fields with the fields within the - information over which the attributes provide evidence - of receipt, such as the body of a message. - - - of the information to which the evidence applies. - - - The TSF shall provide a capability to verify the evidence of - receipt of information to - - - originator - - - recipient - - - - - list of third parties - - - - the PP/ST author, dependent on the selection, - should specify the third parties that can verify - the evidence of receipt. A third party could be an - arbiter, judge or legal body. - - - - - - the PP/ST author should specify the user/subjects who - can verify the evidence of receipt. - - - given - - - limitations on the evidence of receipt - - - - the PP/ST author should fill in the list of - limitations under which the evidence can be - verified. For example the evidence can only be - verified within a 24 hour time interval. An assignment - of ``immediate'' or - ``indefinite'' is acceptable. - - . - - - - - - - - The TSF may employ cryptographic functionality to help satisfy - several high-level security objectives. These include (but are - not limited to): identification and authentication, - non-repudiation, trusted path, trusted channel and data - separation. This class is used when the TOE implements - cryptographic functions, the implementation of which could be - in hardware, firmware and/or software. - - The class is composed of two families: and . The family addresses the management aspects of - cryptographic keys, while the family is - concerned with the operational use of those cryptographic - keys. - - - - The TSF may employ cryptographic functionality to help satisfy - several high-level security objectives. These include (but are - not limited to): identification and authentication, - non-repudiation, trusted path, trusted channel and data - separation. This class is used when the TOE implements - cryptographic functions, the implementation of which could be - in hardware, firmware and/or software. - - The class is composed of two families: and . The family addresses the management aspects of - cryptographic keys, while the family is - concerned with the operational use of those cryptographic - keys. - - For each cryptographic key generation method implemented by - the TOE, if any, the PP/ST author should select the component. - - For each cryptographic key distribution method implemented by - the TOE, if any, the PP/ST author should select the component. - - For each cryptographic key access method implemented by the - TOE, if any, the PP/ST author should select the component. - - For each cryptographic key destruction method implemented by - the TOE, if any, the PP/ST author should select the component. - - For each cryptographic operation (such as digital signature, - data encryption, key agreement, secure hash, etc.) performed - by the TOE, if any, the PP/ST author should select the component. - - Cryptographic functionality may be used to meet objectives - specified in class , and in families , , , - , , , to meet a variety of objectives. In the cases - where cryptographic functionality is used to meet objectives - for other classes, the individual functional components - specify the objectives that cryptographic functionality must - satisfy. The objectives in class should be - used when cryptographic functionality of the TOE is sought by - consumers. - - - - - - Cryptographic keys must be managed throughout their life - cycle. This family is intended to support that lifecycle and - consequently defines requirements for the following - activities: cryptographic key generation, cryptographic key - distribution, cryptographic key access and cryptographic key - destruction. This family should be included whenever there - are functional requirements for the management of - cryptographic keys. - - - - Cryptographic keys must be managed throughout their - lifetime. The typical events in the lifecycle of a - cryptographic key include (but are not limited to): - generation, distribution, entry, storage, access - (e.g. backup, escrow, archive, recovery) and destruction. - - The inclusion of other stages is dependent on the key management - strategy being implemented, as the TOE need not be involved in - all of the key life-cycle (e.g. the TOE may only generate and - distribute cryptographic keys). - - This family is intended to support the cryptographic key - lifecycle and consequently defines requirements for the - following activities: cryptographic key generation, - cryptographic key distribution, cryptographic key access and - cryptographic key destruction. This family should be - included whenever there are functional requirements for the - management of cryptographic keys. - - If Security Audit Data Generation is - included in the PP/ST then, in the context of the events - being audited: - - - The object attributes may include the assigned user - for the cryptographic key, the user role, the - cryptographic operation that the cryptographic key is - to be used for, the cryptographic key identifier and - the cryptographic key validity period. - - - The object value may include the values of cryptographic - key(s) and parameters excluding any sensitive - information (such as secret or private cryptographic - keys). - - - - Typically, random numbers are used to generate cryptographic - keys. If this is the case, then - should be used instead of the component . - In cases where random number generation is required for purposes other - than for the generation of cryptographic keys, the component - should be used. - - - - - - - - - - - - - - This component requires the cryptographic key sizes and - method used to generate cryptographic keys to be - specified, this can be in accordance with an assigned - standard. It should be used to specify the cryptographic - key sizes and the method (e.g. algorithm) used to generate - the cryptographic keys. Only one instance of the component - is needed for the same method and multiple key sizes. The - key size could be common or different for the various - entities, and could be either the input to or the output - from the method. - - - - , requires cryptographic keys to be - generated in accordance with a specified algorithm and key - sizes which can be based on an assigned standard. - - - - Success and failure of the activity. - - - The object attribute(s), and object value(s) excluding any - sensitive information (e.g. secret or private keys). - - - The TSF shall generate cryptographic keys in accordance with - a specified cryptographic key generation algorithm - - - cryptographic key generation algorithm - - - - the PP/ST author should specify the cryptographic key - generation algorithm to be used. - - - and specified cryptographic key sizes - - - cryptographic key sizes - - - - the PP/ST author should specify the cryptographic key - sizes to be used. The key sizes specified should be - appropriate for the algorithm and its intended use. - - - that meet the following: - - - list of standards - - - - the PP/ST author should specify the assigned standard - that documents the method used to generate - cryptographic keys. The assigned standard may comprise - none, one or more actual standards publications, for - example, from international, national, industry or - organisational standards. - - . - - - - - - - - - - - - - - - This component requires the method used to distribute - cryptographic keys to be specified, this can be in - accordance with an assigned standard. - - - - , requires cryptographic keys to be - distributed in accordance with a specified distribution - method which can be based on an assigned standard. - - - - - - The TSF shall distribute cryptographic keys in accordance - with a specified cryptographic key distribution method - - - cryptographic key distribution method - - - - the PP/ST author should specify the cryptographic key - distribution method to be used. - - - that meets the following: - - - list of standards - - - - the PP/ST author should specify the assigned standard - that documents the method used to distribute - cryptographic keys. The assigned standard may comprise - none, one or more actual standards publications, for - example, from international, national, industry or - organisational standards. - - . - - - - - - - - - - - - - - - This component requires the method used to access - cryptographic keys be specified, this can be in accordance - with an assigned standard. - - - - , requires access to cryptographic - keys to be performed in accordance with a specified access - method which can be based on an assigned standard. - - - - - - The TSF shall perform - - - type of cryptographic key access - - - - the PP/ST author should specify the type of - cryptographic key access being used. Examples of types - of cryptographic key access include (but are not - limited to) cryptographic key backup, cryptographic - key archival, cryptographic key escrow and - cryptographic key recovery. - - - in accordance with a specified cryptographic key access - method - - - cryptographic key access method - - - - the PP/ST author should specify the cryptographic key - access method to be used. - - - that meets the following: - - - list of standards - - - - the PP/ST author should specify the assigned standard - that documents the method used to access cryptographic - keys. The assigned standard may comprise none, one or - more actual standards publications, for example, from - international, national, industry or organisational - standards. - - . - - - - - - - - - - - - - - This component requires the method used to destroy - cryptographic keys be specified, this can be in accordance - with an assigned standard. - - - - , requires cryptographic keys to be - destroyed in accordance with a specified destruction - method which can be based on an assigned standard. - - - - - - The TSF shall destroy cryptographic keys in accordance with - a specified cryptographic key destruction method - - - cryptographic key destruction method - - - - the PP/ST author should specify the key destruction - method to be used to destroy cryptographic keys. - - - that meets the following: - - - list of standards - - - - the PP/ST author should specify the assigned standard - that documents the method used to destroy - cryptographic keys. The assigned standard may comprise - none, one or more actual standards publications, for - example, from international, national, industry or - organisational standards. - - . - - - - - - - - In order for a cryptographic operation to function - correctly, the operation must be performed in accordance - with a specified algorithm and with a cryptographic key of a - specified size. This family should be included whenever - there are requirements for cryptographic operations to be - performed. - - Typical cryptographic operations include data encryption - and/or decryption, digital signature generation and/or - verification, cryptographic checksum generation for - integrity and/or verification of checksum, secure hash - (message digest), cryptographic key encryption and/or - decryption, and cryptographic key agreement. - - - - A cryptographic operation may have cryptographic mode(s) of - operation associated with it. If this is the case, then the - cryptographic mode(s) must be specified. Examples of - cryptographic modes of operation are cipher block chaining, - output feedback mode, electronic code book mode, and cipher - feedback mode. - - Cryptographic operations may be used to support one or more - TOE security services. The component - may need to be iterated more than once depending on: - - - the user application for which the security service is - being used. - - - the use of different cryptographic algorithms and/or - cryptographic key sizes. - - - the type or sensitivity of the data being operated on. - - - - If Security audit data generation is - included in the PP/ST then, in the context of the - cryptographic operation events being audited: - - - The types of cryptographic operation may include digital - signature generation and/or verification, cryptographic - checksum generation for integrity and/or for - verification of checksum, secure hash (message digest) - computation, data encryption and/or decryption, - cryptographic key encryption and/or decryption, - cryptographic key agreement and random number - generation. - - - The subject attributes may include subject role(s) and - user(s) associated with the subject. - - - The object attributes may include the assigned user for - the cryptographic key, user role, cryptographic - operation the cryptographic key is to be used for, - cryptographic key identifier, and the cryptographic key - validity period. - - - - - - - - - - - - - - - This component requires the cryptographic algorithm and - key size used to perform specified cryptographic - operation(s) which can be based on an assigned standard. - - - - , requires a cryptographic operation - to be performed in accordance with a specified algorithm - and with a cryptographic key of specified sizes. The - specified algorithm and cryptographic key sizes can be - based on an assigned standard. - - - Success and failure, and the type of cryptographic - operation. - - - Any applicable cryptographic mode(s) of operation, subject - attributes and object attributes. - - - The TSF shall perform - - - list of cryptographic operations - - - - the PP/ST author should specify the cryptographic - operations being performed. Typical cryptographic - operations include digital signature generation and/or - verification, cryptographic checksum generation for - integrity and/or for verification of checksum, secure - hash (message digest) computation, data encryption - and/or decryption, cryptographic key encryption and/or - decryption, cryptographic key agreement and random - number generation. The cryptographic operation may be - performed on user data or TSF data. - - - in accordance with a specified cryptographic algorithm - - - cryptographic algorithm - - - - the PP/ST author should specify the cryptographic - algorithm to be used. Typical cryptographic algorithms - include, but are not limited to, DES, RSA and IDEA. - - - and cryptographic key sizes - - - cryptographic key sizes - - - - the PP/ST author should specify the cryptographic key - sizes to be used. The key sizes specified should be - appropriate for the algorithm and its intended use. - - - that meet the following: - - - list of standards - - - - the PP/ST author should specify the assigned standard - that documents how the identified cryptographic - operation(s) are performed. The assigned standard may - comprise none, one or more actual standards - publications, for example, from international, - national, industry or organisational standards. - - . - - - - - - - - This class contains families specifying requirements related - to protecting user data. is split - into four groups of families (listed below) that address user - data within a TOE, during import, export, and storage as well - as security attributes directly related to user data. - - The families in this class are organised into four groups: - - - User data protection security function policies: - - - ; and - - - . - - - - Components in these families permit the PP/ST author to - name the user data protection security function policies - and define the scope of control of the policy, necessary - to address the security objectives. The names of these - policies are meant to be used throughout the remainder - of the functional components that have an operation that - calls for an assignment or selection of an "access - control SFP" or an "information flow control - SFP". The rules that define the functionality of - the named access control and information flow control - SFPs will be defined in the and - families (respectively). - - - Forms of user data protection: - - - ; - - - ; - - - ; - - - ; - - - ; and - - - . - - - - - Off-line storage, import and export: - - - ; - - - ; - - - . - - - - Components in these families address the trustworthy - transfer into or out of the TOE. - - - Inter-TSF communication: - - - ; and - - - . - - - - Components in these families address communication - between the TSF of the TOE and another trusted IT - product. - - - - - - This class contains families specifying requirements related - to protecting user data. This class differs from FIA and FPT - in that specifies components to - protect user data, FIA specifies components to protect - attributes associated with the user, and FPT specifies - components to protect TSF information. - - The class does not contain explicit requirements for - traditional Mandatory Access Controls (MAC) or traditional - Discretionary Access Controls (DAC); however, such - requirements may be constructed using components from this - class. - - does not explicitly deal with - confidentiality, integrity, or availability, as all three are - most often intertwined in the policy and mechanisms. However, - the TOE security policy must adequately cover these three - objectives in the PP/ST. - - A final aspect of this class is that it specifies access - control in terms of ``operations''. An operation - is defined as a specific type of access on a specific - object. It depends on the level of abstraction of the PP/ST - author whether these operations are described as - ``read'' and/or ``write'' - operations, or as more complex operations such as - ``update the database''. - - The access control policies are policies that control access - to the information container. The attributes represent - attributes of the container. Once the information is out of - the container, the accessor is free to modify that - information, including writing the information into a - different container with different attributes. By contrast, an - information flow policies controls access to the information, - independent of the container. The attributes of the - information, which may be associated with the attributes of - the container (or may not, as in the case of a multi-level - database) stay with the information as it moves. The accessor - does not have the ability, in the absence of an explicit - authorisation, to change the attributes of the information. - - This class is not meant to be a complete taxonomy of IT access - policies, as others can be imagined. Those policies included - here are simply those for which current experience with actual - systems provides a basis for specifying requirements. There - may be other forms of intent that are not captured in the - definitions here. - - For example, one could imagine a goal of having user-imposed - (and user-defined) controls on information flow (e.g. an - automated implementation of the NO FOREIGN handling - caveat). Such concepts could be handled as refinements of, or - extensions to the components. - - Finally, it is important when looking at the components in - to remember that these components are - requirements for functions that may be implemented by a - mechanism that also serves or could serve another purpose. For - example, it is possible to build an access control policy - () that uses labels () as the basis of the access control - mechanism. - - A set of SFRs may encompass many security function - policies (SFPs), each to be identified by the two policy - oriented components , and . These policies will typically take - confidentiality, integrity, and availability aspects into - consideration as required, to satisfy the TOE - requirements. Care should be taken to ensure that all objects - are covered by at least one SFP and that there are no - conflicts arising from implementing the multiple SFPs. - - When building a PP/ST using components from the class, the following information provides guidance - on where to look and what to select from the class. - - The requirements in the class are defined in - terms of a set of SFRs that will - implement a SFP. Since a TOE may implement multiple SFPs - simultaneously, the PP/ST author must specify the name for - each SFP, so it can be referenced in other families. This name - will then be used in each component selected to indicate that - it is being used as part of the definition of requirements for - that SFP. This allows the author to easily indicate the - scope for operations such as objects covered, operations - covered, authorised users, etc. - - Each instantiation of a component can apply to only one - SFP. Therefore if an SFP is specified in a component then - this SFP will apply to all the elements in this - component. The components may be instantiated multiple times - within a PP/ST to account for different policies if so - desired. - - The key to selecting components from this family is to have a - well defined set of TOE security objectives to enable proper - selection of the components from the two policy components; - and . In and respectively, all access control - policies and all information flow control policies are - named. Furthermore the scope of control of these components in - terms of the subjects, objects and operations covered by this - security functionality. The names of these policies are meant - to be used throughout the remainder of the functional - components that have an operation that calls for an assignment - or selection of an ``access control SFP'' or an ``information - flow control SFP''. The rules that define the functionality - of the named access control and information flow control SFPs - will be defined in the and - families - (respectively). - - The following steps are guidance on how this class is applied - in the construction of a PP/ST: - - - Identify the policies to be enforced from the , and families. These - families define scope of control for the policy, - granularity of control and may identify some rules to go - with the policy. - - - Identify the components and perform any applicable operations - in the policy components. The assignment operations may be - performed generally (such as with a statement ``All - files'') or specifically (``The files - ``A'', ``B'', etc.) depending upon - the level of detail known. - - - Identify any applicable function components from the and families to address - the named policy families from and - . Perform the operations to make the - components define the rules to be enforced by the named - policies. This should make the components fit the - requirements of the selected function envisioned or to be - built. - - - Identify who will have the ability to control and change - security attributes under the function, such as only a - security administrator, only the owner of the object, - etc. Select the appropriate components from - and perform the operations. Refinements may be useful here - to identify missing features, such as that some or all - changes must be done via trusted path. - - - Identify any appropriate components from the for initial values for new objects and subjects. - - - Identify any applicable rollback components from the family. - - - Identify any applicable residual information protection - requirements from the family. - - - Identify any applicable import or export components, and how - security attributes should be handled during import and - export, from the and families. - - - Identify any applicable internal TOE communication - components from the family. - - - Identify any requirements for integrity protection of stored - information from the . - - - Identify any applicable inter-TSF communication components - from the or - families. - - - - - - - - This family identifies the access control SFPs (by name) and - defines the scope of control of the policies that form the - identified access control portion of the SFRs related to the - SFP. This scope of control is characterised by three sets: the - subjects under control of the policy, the objects under control - of the policy, and the operations among controlled subjects and - controlled objects that are covered by the policy. The criteria - allows multiple policies to exist, each having a unique name. - This is accomplished by iterating components from this family - once for each named access control policy. The rules that - define the functionality of an access control SFP will be - defined by other families such as and . The names - of the access control SFPs identified here in are meant to be used throughout the remainder of - the functional components that have an operation that calls for - an assignment or selection of an ``access control SFP.'' - - - - This family is based upon the concept of arbitrary controls - on the interaction of subjects and objects. The scope and - purpose of the controls is based upon the attributes of the - accessor (subject), the attributes of the container being - accessed (object), the actions (operations) and any - associated access control rules. - - The components in this family are capable of identifying the - access control SFPs (by name) to be enforced by the traditional - Discretionary Access Control (DAC) mechanisms. It further - defines the subjects, objects and operations that are covered by - identified access control SFPs. The rules that define the - functionality of an access control SFP will be defined by other - families, such as and . The names of the access control SFPs - defined in are meant to be used - throughout the remainder of the functional components that have - an operation that calls for an assignment or selection of an - ``access control SFP.'' - - The access control SFP covers a set of triplets: subject, - object, and operations. Therefore a subject can be covered - by multiple access control SFPs but only with respect to a - different operation or a different object. Of course the - same applies to objects and operations. - - A critical aspect of an access control function that - enforces an access control SFP is the ability for users to - modify the attributes involved in access control - decisions. The family does not address - these aspects. Some of these requirements are left - undefined, but can be added as refinements, while others are - covered elsewhere in other families and classes such as - . - - There are no audit requirements in as - this family specifies access control SFP requirements. Audit - requirements will be found in families specifying functions - to satisfy the access control SFPs identified in this - family. - - This family provides a PP/ST author the capability to - specify several policies, for example, a fixed access - control SFP to be applied to one scope of control, and a - flexible access control SFP to be defined for a different - scope of control. To specify more than one access control - policy, the components from this family can be iterated - multiple times in a PP/ST to different subsets of operations - and objects. This will accommodate TOEs that contain - multiple policies, each addressing a particular set of - operations and objects. In other words, the PP/ST author - should specify the required information in the ACC component - for each of the access control SFPs that the TSF will - enforce. For example, a TOE incorporating three access - control SFPs, each covering only a subset of the objects, - subjects, and operations within the TOE, will contain one - component for each of the three - access control SFPs, necessitating a total of three components. - - - - - - - - - The terms object and subject refer to generic elements in - the TOE. For a policy to be implementable, the entities - must be clearly identified. For a PP, the objects and - operations might be expressed as types such as: named - objects, data repositories, observe accesses, etc. For a - specific TOE these generic terms (subject, object) must be - refined, e.g. files, registers, ports, daemons, open - calls, etc. - - This component specifies that the policy cover some - well-defined set of operations on some subset of the - objects. It places no constraints on any operations - outside the set - including operations on objects for - which other operations are controlled. - - - - , requires that each identified - access control SFP be in place for a subset of the - possible operations on a subset of the objects in the TOE. - - - The TSF shall enforce the - - - access control SFP - - - - the PP/ST author should specify a uniquely named - access control SFP to be enforced by the TSF. - - - on - - - list of subjects, objects, and operations among subjects - and objects covered by the SFP - - - - the PP/ST author should specify the list of subjects, - objects, and operations among subjects and objects - covered by the SFP. - - . - - - - - - - - - - - This component requires that all possible operations on - objects, that are included in the SFP, are covered by an - access control SFP. - - The PP/ST author must demonstrate that each combination of - objects and subjects is covered by an access control SFP. - - - - , requires that each identified - access control SFP cover all operations on subjects and - objects covered by that SFP. It further requires that all - objects and operations protected by the TSF are covered by at - least one identified access control SFP. - - - The TSF shall enforce the - - - access control SFP - - - - the PP/ST author should specify a uniquely named - access control SFP to be enforced by the TSF. - - - on - - - list of subjects and objects - - - - the PP/ST author should specify the list of subjects - and objects covered by the SFP. All operations among - those subjects and objects will be covered by the SFP. - - - and all operations among subjects and objects covered by the - SFP. - - - The TSF shall ensure that all operations between any subject - controlled by the TSF and any object controlled by the TSF are covered by an - access control SFP. - - - - - - - - This family describes the rules for the specific functions - that can implement an access control policy named in . specifies the scope of control of the - policy. - - - - This family describes the rules for the specific functions - that can implement an access control policy named in which also specifies the scope of - control of the policy. - - This family provides a PP/ST author the capability to - describe the rules for access control. This results in a - TOE where the access to objects will not change. An - example of such an object is ``Message of the Day'', which - is readable by all, and changeable only by the authorised - administrator. This family also provides the PP/ST author - with the ability to describe rules that provide for - exceptions to the general access control rules. Such - exceptions would either explicitly allow or deny - authorisation to access an object. - - There are no explicit components to specify other possible - functions such as two-person control, sequence rules for - operations, or exclusion controls. However, these - mechanisms, as well as traditional DAC mechanisms, can be - represented with the existing components, by careful - drafting of the access control rules. - - A variety of acceptable access control functionality may be - specified in this family such as: - - - Access control lists (ACLs) - - - Time-based access control specifications - - - Origin-based access control specifications - - - Owner-controlled access control attributes - - - - - - - - - - - This component provides requirements for a mechanism that - mediates access control based on security attributes - associated with subjects and objects. Each object and - subject has a set of associated attributes, such as - location, time of creation, access rights (e.g., Access - Control Lists (ACLs)). This component allows the PP/ST - author to specify the attributes that will be used for the - access control mediation. This component allows access - control rules, using these attributes, to be - specified. - - Examples of the attributes that a PP/ST author might - assign are presented in the following paragraphs. - - An identity attribute may be associated with users, - subjects, or objects to be used for mediation. Examples of - such attributes might be the name of the program image - used in the creation of the subject, or a security - attribute assigned to the program image. - - A time attribute can be used to specify that access will - be authorised during certain times of the day, during - certain days of the week, or during a certain calendar - year. - - A location attribute could specify whether the location is - the location of the request for the operation, the - location where the operation will be carried out, or - both. It could be based upon internal tables to translate - the logical interfaces of the TSF into locations such as - through terminal locations, CPU locations, etc. - - A grouping attribute allows a single group of users to be - associated with an operation for the purposes of access - control. If required, the refinement operation should be - used to specify the maximum number of definable groups, - the maximum membership of a group, and the maximum number - of groups to which a user can concurrently be - associated. - - This component also provides requirements for the access - control security functions to be able to explicitly - authorise or deny access to an object based upon security - attributes. This could be used to provide privilege, - access rights, or access authorisations within the - TOE. Such privileges, rights, or authorisations could - apply to users, subjects (representing users or - applications), and objects. - - - - This family addresses security attribute usage and - characteristics of policies. The component within this - family is meant to be used to describe the rules for the - function that implements the SFP as identified in . The PP/ST author may also - iterate this component to address multiple policies in the - TOE. - - Security attribute - based access control allows the TSF to enforce access - based upon security attributes and named groups of - attributes. Furthermore, the TSF may have the ability to - explicitly authorise or deny access to an object based - upon security attributes. - - - Managing the attributes used to make explicit access or - denial based decisions. - - - Successful requests to perform an operation on an object - covered by the SFP. - - - All requests to perform an operation on an object covered by - the SFP. - - - The specific security attributes used in making an access - check. - - - The TSF shall enforce the - - access control SFP - - the PP/ST author should specify an access control SFP - name that the TSF is to enforce. The name of the access - control SFP, and the scope of control for that policy - are defined in components from . - to objects based on the following: - - list of subjects and objects controlled under the - indicated SFP, and for each, the SFP-relevant security - attributes, or named groups of SFP-relevant security - attributes - - the PP/ST author should specify, for each controlled - subject and object, the security attributes and/or named - groups of security attributes that the function will use - in the specification of the rules. For example, such - attributes may be things such as the user identity, - subject identity, role, time of day, location, ACLs, or - any other attribute specified by the PP/ST author. Named - groups of security attributes can be specified to - provide a convenient means to refer to multiple security - attributes. Named groups could provide a useful way to - associate ``roles'' defined in , and - all of their relevant attributes, with subjects. In - other words, each role could relate to a named group of - attributes.. - - - The TSF shall enforce the following rules to determine if an - operation among controlled subjects and controlled objects - is allowed: - - - rules governing access among controlled subjects and - controlled objects using controlled operations on - controlled objects - - - - the PP/ST author should specify the SFP rules - governing access among controlled subjects and - controlled objects using controlled operations on - controlled objects. These rules specify when access - is granted or denied. It can specify general access - control functions (e.g. typical permission bits) or - granular access control functions (e.g. ACLs). - - . - - - The TSF shall explicitly authorise access of subjects to - objects based on the following additional rules: - - - rules, based on security attributes, that explicitly - authorise access of subjects to objects - - - - the PP/ST author should specify the rules, based on - security attributes, that explicitly authorise access - of subjects to objects that will be used to explicitly - authorise access. These rules are in addition to those - specified in . They are - included in as they are - intended to contain exceptions to the rules in . An example of rules to explicitly - authorise access is based on a privilege vector - associated with a subject that always grants access to - objects covered by the access control SFP that has - been specified. If such a capability is not desired, - then the PP/ST author should specify - ``none''. - - . - - - The TSF shall explicitly deny access of subjects to objects based on the - following additional rules: - rules, based on security attributes, that - explicitly deny access of subjects to objects the PP/ST author should specify the rules, - based on security attributes, that explicitly deny access of subjects - to objects. These rules are in addition to those specified in - - . They are included in - - as they are intended to contain exceptions to the rules in - - . An example of rules to explicitly deny access is based on a privilege - vector associated with a subject - that always denies access to objects covered by the access control SFP - that has been specified. If such a capability is not desired, then the - PP/ST author should specify ``none''.. - - - - - - - - Data authentication permits an entity to accept - responsibility for the authenticity of information (e.g., by - digitally signing it). This family provides a method of - providing a guarantee of the validity of a specific unit of - data that can be subsequently used to verify that the - information content has not been forged or fraudulently - modified. In contrast to , this family is - intended to be applied to "static" data rather - than data that is being transferred. - - - - This family describes specific functions that can be used to - authenticate ``static'' data. - - Components in this family are to be used when there is a - requirement for ``static'' data - authentication, i.e. where data is to be signed but not - transmitted. (Note that the family - provides for non-repudiation of origin of information - received during a data exchange.) - - - - - - This component may be satisfied by one-way hash functions - (cryptographic checksum, fingerprint, message digest), to - generate a hash value for a definitive document that may - be used as verification of the validity or authenticity of - its information content. - - - - , requires that the TSF is capable - of generating a guarantee of authenticity of the - information content of objects (e.g. documents). - - - The assignment or modification of the objects for which data - authentication may apply could be configurable. - - - Successful generation of validity evidence. - - - Unsuccessful generation of validity evidence. - - - The identity of the subject that requested the evidence. - - - The TSF shall provide a capability to generate evidence that - can be used as a guarantee of the validity of - - - list of objects or information types - - - - the PP/ST author should specify the list of objects or - information types for which the TSF shall be capable - of generating data authentication evidence. - - . - - - The TSF shall provide - - - list of subjects - - - - the PP/ST author should specify the list of subjects - that will have the ability to verify data - authentication evidence for the objects identified in - the previous element. The list of subjects could be - very specific, if the subjects are known, or it could - be more generic and refer to a - ``type'' of subject such - as an identified role. - - - with the ability to verify evidence of the validity of the - indicated information. - - - - - - - - - - - This component additionally requires the ability to verify - the identity of the user that provided the guarantee of - authenticity (e.g. a trusted third party). - - - - additionally requires that the TSF - is capable of establishing the identity of the subject who - provided the guarantee of authenticity. - - - - Successful generation of validity evidence. - - - Unsuccessful generation of validity evidence. - - - The identity of the subject that requested the evidence. - - - The identity of the subject that generated the evidence. - - - The TSF shall provide a capability to generate evidence that - can be used as a guarantee of the validity of - - - list of objects or information types - - - - the PP/ST author should specify the list of objects or - information types for which the TSF shall be capable - of generating data authentication evidence. - - . - - - The TSF shall provide - - - list of subjects - - - - the PP/ST author should specify the list of subjects - that will have the ability to verify data - authentication evidence for the objects identified in - the previous element as well as the identity of the - user that created the data authentication evidence. - - - with the ability to verify evidence of the validity of the - indicated information and the identity of the user that - generated the evidence. - - - - - - - - This family defines functions for TSF-mediated exporting of user data from - the TOE such that its security attributes and protection - either can be explicitly preserved or can be ignored once it - has been exported. It is concerned with limitations on - export and with the association of security attributes with - the exported user data. - - - - This family defines functions for TSF-mediated exporting of user data from - the TOE such that its security attributes either can be - explicitly preserved or can be ignored once it has been - exported. Consistency of these security attributes are - addressed by . - - is concerned with limitations on export - and association of security attributes with the exported - user data. - - This family, and the corresponding Import family , address how the TOE deals with user data - transferred into and outside its control. In principle this - family is concerned with the TSF-mediated exporting of user data and its - related security attributes. - - A variety of activities might be involved here: - - - exporting of user data without any security attributes; - - - exporting user data including security attributes where - the two are associated with one another and the security - attributes unambiguously represent the exported user - data. - - - - If there are multiple SFPs (access control and/or - information flow control) then it may be appropriate to - iterate these components once for each named SFP. - - - - - - - - - - - - This component is used to specify the TSF-mediated exporting of user data - without the export of its security attributes. - - - - , requires that the TSF enforce the - appropriate SFPs when exporting user data outside the - TSF. User data that is exported by this function is - exported without its associated security attributes. - - - Successful export of information. - - - All attempts to export information. - - - The TSF shall enforce the - - - access control SFP(s) and/or information flow control - SFP(s) - - - - the PP/ST author should specify the access control - SFP(s) and/or information flow control SFP(s) that - will be enforced when exporting user data. The user - data that this function exports is scoped by the - assignment of these SFPs. - - - when exporting user data, controlled under the SFP(s), - outside of the TOE. - - - The TSF shall export the user data without the user - data's associated security attributes - - - - - - - - - - - - - The user data is exported together with its security - attributes. The security attributes are unambiguously - associated with the user data. There are several ways of - achieving this association. One way that this can be - achieved is by physically collocating the user data and - the security attributes (e.g. the same floppy), or by - using cryptographic techniques such as secure signatures - to associate the attributes and the user data. could be used to assure that the attributes - are correctly received at the other trusted IT product - while can be used to make sure that - those attributes are properly interpreted. Furthermore, - could be used to make sure that the - export is being initiated by the proper user. - - - - , requires that the TSF enforce the - appropriate SFPs using a function that accurately and - unambiguously associates security attributes with the user - data that is exported. - - - The additional exportation control rules could be - configurable by a user in a defined role. - - - - - The TSF shall enforce the - - - access control SFP(s) and/or information flow control - SFP(s) - - - - the PP/ST author should specify the access control - SFP(s) and/or information flow control SFP(s) that - will be enforced when exporting user data. The user - data that this function exports is scoped by the - assignment of these SFPs. - - - when exporting user data, controlled under the SFP(s), - outside of the TOE. - - - The TSF shall export the user data with the user - data's associated security attributes. - - - The TSF shall ensure that the security attributes, when - exported outside the TOE, are unambiguously associated with - the exported user data. - - - The TSF shall enforce the following rules when user data is - exported from the TOE: - - - additional exportation control rules - - - - the PP/ST author should specify any additional - exportation control rules or - ``none'' if there are no - additional exportation control rules. These rules will - be enforced by the TSF in addition to the access - control SFPs and/or information flow control SFPs - selected in . - - . - - - - - - - - This family identifies the information flow control SFPs (by - name) and defines the scope of control for each named - information flow control SFP. This scope of control is - characterised by three sets: the subjects under control of the - policy, the information under control of the policy, and - operations which cause controlled information to flow to and - from controlled subjects covered by the policy. The criteria - allows multiple policies to exist, each having a unique name. - This is accomplished by iterating components from this family - once for each named information flow control policy. The rules - that define the functionality of an information flow control SFP - will be defined by other families such as and . The names - of the information flow control SFPs identified here in are meant to be used throughout the - remainder of the functional components that have an operation - that calls for an assignment or selection of an ``information - flow control SFP.'' - - The TSF mechanism controls the flow of information in - accordance with the information flow control SFP. Operations - that would change the security attributes of information are - not generally permitted as this would be in violation of an - information flow control SFP. However, such operations may - be permitted as exceptions to the information flow control - SFP if explicitly specified. - - - - This family covers the identification of information flow - control SFPs; and, for each, specifies the scope of control - of the SFP. - - The components in this family are capable of identifying the - information flow control SFPs to be enforced by the traditional - Mandatory Access Control mechanisms that would be found in a - TOE. However, they go beyond just the traditional MAC mechanisms - and can be used to identify and describe non-interference - policies and state-transitions. It further defines the subjects - under control of the policy, the information under control of - the policy, and operations which cause controlled information to - flow to and from controlled subjects for each information flow - control SFP in the TOE. The information flow control SFP will be - defined by other families such as and . The - information flow control SFPs named here in are meant to be used throughout the remainder of - the functional components that have an operation that calls for - an assignment or selection of an ``information flow control - SFP.'' - - These components are quite flexible. They allow the domain - of flow control to be specified and there is no requirement - that the mechanism be based upon labels. The different - elements of the information flow control components also - permit different degrees of exception to the policy. - - Each SFP covers a set of triplets: subject, information, and - operations that cause information to flow to and from - subjects. Some information flow control policies may be at a - very low level of detail and explicitly describe subjects in - terms of processes within an operating system. Other - information flow control policies may be at a high level and - describe subjects in the generic sense of users or - input/output channels. If the information flow control - policy is at too high a level of detail, it may not clearly - define the desired IT security functions. In such cases, it - is more appropriate to include such descriptions of - information flow control policies as objectives. Then the - desired IT security functions can be specified as supportive - of those objectives. - - In the second component (), each - information flow control SFP will cover all possible - operations that cause information covered by that SFP to - flow to and from subjects covered by that SFP. Furthermore, - all information flows will need to be covered by a - SFP. Therefore for each action that causes information to - flow, there will be a set of rules that define whether the - action is allowed. If there are multiple SFPs that are - applicable for a given information flow, all involved SFPs - must allow this flow before it is permitted to take place. - - An information flow control SFP covers a well-defined set of - operations. The SFPs coverage may be - ``complete'' with respect to some - information flows, or it may address only some of the - operations that affect the information flow. - - An access control SFP controls access to the objects that - contain information. An information flow control SFP - controls access to the information, independent of its - container. The attributes of the information, which may be - associated with the attributes of the container (or may not, - as in the case of a multi-level database) stay with the - information as it flows. The accessor does not have the - ability, in the absence of an explicit authorisation, to - change the attributes of the information. - - Information flows and operations can be expressed at - multiple levels. In the case of a ST, the information flows - and operations might be specified at a system-specific - level: TCP/IP packets flowing through a firewall based upon - known IP addresses. For a PP, the information flows and - operations might be expressed as types: email, data - repositories, observe accesses, etc. - - The components in this family can be applied multiple times - in a PP/ST to different subsets of operations and - objects. This will accommodate TOEs that contain multiple - policies, each addressing a particular set of objects, - subjects, and operations. - - - - - - - - - This component requires that an information flow control - policy apply to a subset of the possible operations in the - TOE. - - - - , requires that each identified - information flow control SFPs be in place for a subset of - the possible operations on a subset of information flows - in the TOE. - - - The TSF shall enforce the - - - information flow control SFP - - - - the PP/ST author should specify a uniquely named - information flow control SFP to be enforced by the - TSF. - - - on - - - list of subjects, information, and operations that cause - controlled information to flow to and from controlled - subjects covered by the SFP - - - - the PP/ST author should specify the list of subjects, - information, and operations which cause controlled - information to flow to and from controlled subjects - covered by the SFP. As mentioned above, the list of - subjects could be at various levels of detail - depending on the needs of the PP/ST author. It could - specify users, machines, or processes for - example. Information could refer to data such as email - or network protocols, or more specific objects similar - to those specified under an access control policy. If - the information that is specified is contained within - an object that is subject to an access control policy, - then both the access control policy and information - flow control policy must be enforced before the - specified information could flow to or from the - object. - - . - - - - - - - - - - - This component requires that all possible operations that - cause information to flow to and from subjects included in - the SFP, are covered by an information flow control SFP. - - The PP/ST author must demonstrate that each combination of - information flows and subjects is covered by an - information flow control SFP. - - - - , requires that each identified - information flow control SFP cover all operations on - subjects and information covered by that SFP. It further - requires that all information flows and operations controlled - by the TSF are covered by at least one identified information - flow control SFP. - - - The TSF shall enforce the - - - information flow control SFP - - - - the PP/ST author should specify a uniquely named - information flow control SFP to be enforced by the - TSF. - - - on - - - list of subjects and information - - - - the PP/ST author should specify the list of subjects - and information that will be covered by the SFP. All - operations that cause that information to flow to and - from subjects will be covered by the SFP. As mentioned - above, the list of subjects could be at various levels - of detail depending on the needs of the PP/ST - author. It could specify users, machines, or processes - for example. Information could refer to data such as - email or network protocols, or more specific objects - similar to those specified under an access control - policy. If the information that is specified is - contained within an object that is subject to an - access control policy, then both the access control - policy and information flow control policy must be - enforced before the specified information could flow - to or from the object. - - - and all operations that cause that information to flow to - and from subjects covered by the SFP. - - - The TSF shall ensure that all operations that cause any - information in the TOE to flow to and from any subject in - the TOE are covered by an information flow control SFP. - - - - - - - - This family describes the rules for the specific functions - that can implement the information flow control SFPs named - in , which also specifies the scope of - control of the policy. It consists of two kinds of - requirements: one addressing the common information flow - function issues, and a second addressing illicit information - flows (i.e. covert channels). This division arises because - the issues concerning illicit information flows are, in some - sense, orthogonal to the rest of an information flow control - SFP. By their nature they circumvent the information flow - control SFP resulting in a violation of the policy. As such, - they require special functions to either limit or prevent - their occurrence. - - - - This family describes the rules for the specific functions - that can implement the information flow control SFPs named - in , which also specifies the scope of - control of the policies. It consists of two - ``trees:'' one addressing the common - information flow control function issues, and a second - addressing illicit information flows (i.e. covert channels) - with respect to one or more information flow control - SFPs. This division arises because the issues concerning - illicit information flows are, in some sense, orthogonal to - the rest of an SFP. Illicit information flows are flows in - violation of policy; thus they are not a policy issue. - - In order to implement strong protection against disclosure - or modification in the face of untrusted software, controls - on information flow are required. Access controls alone are - not sufficient because they only control access to - containers, allowing the information they contain to flow, - without controls, throughout a system. - - In this family, the phrase ``types of illicit - information flows'' is used. This phrase may be - used to refer to the categorisation of flows as - ``Storage Channels'' or - ``Timing Channels'', or it can refer to - improved categorisations reflective of the needs of a PP/ST - author. - - The flexibility of these components allows the definition of - a privilege policy within and to allow the controlled bypass of all or - part of a particular SFP. If there is a need for a - predefined approach to SFP bypass, the PP/ST author should - consider incorporating a privilege policy. - - - - - - - - - - This component requires security attributes on - information, and on subjects that cause that information - to flow and subjects that act as recipients of that - information. The attributes of the containers of the - information should also be considered if it is desired - that they should play a part in information flow control - decisions or if they are covered by an access control - policy. This component specifies the key rules that are - enforced, and describes how security attributes are - derived. - - This component does not specify the details of how a - security attribute is assigned (i.e. user versus - process). Flexibility in policy is provided by having - assignments that allow specification of additional policy - and function requirements, as necessary. - - This component also provides requirements for the - information flow control functions to be able to - explicitly authorise and deny an information flow based - upon security attributes. This could be used to implement - a privilege policy that covers exceptions to the basic - policy defined in this component. - - - - , requires security attributes on - information, and on subjects that cause that information - to flow and on subjects that act as recipients of that - information. It specifies the rules that must be enforced - by the function, and describes how security attributes are - derived by the function. - - - Managing the attributes used to make explicit access based - decisions. - - - Decisions to permit requested information flows. - - - All decisions on requests for information flow. - - - The specific security attributes used in making an - information flow enforcement decision. - - - Some specific subsets of the information that has flowed - based upon policy goals (e.g. auditing of downgraded - material). - - - The TSF shall enforce the - - - information flow control SFP - - - - the PP/ST author should specify the information flow - control SFPs enforced by the TSF. The name of the - information flow control SFP, and the scope of control - for that policy are defined in components from - . - - - based on the following types of subject and - information security attributes: - - list of subjects and information controlled under the - indicated SFP, and for each, the security attributes - - the PP/ST author should specify, for each type of - controlled subject and information, the security - attributes that are relevant to the specification of the - SFP rules. For example, such security attributes may be - things such the subject identifier, subject sensitivity - label, subject clearance label, information sensitivity - label, etc. The types of security attributes should be - sufficient to support the environmental needs.. - - - 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, the security attribute-based - relationship that must hold between subject and - information security attributes - - - - the PP/ST author should specify for each operation, - the security attribute-based relationship that must - hold between subject and information security - attributes that the TSF will enforce. - - . - - - The TSF shall enforce the - - - additional information flow control SFP rules - - - the PP/ST author should specify any additional information - flow control SFP rules that the TSF is to enforce. This - includes all rules of the SFP that are either not based on the - security attributes of the information and the subject or - rules that automatically modify the security attributes of - information or subjects as a result of an access operation. - An example for the first case is a rule of the SFP controlling - a threshold value for specific types of information. This - would for example be the case when the information flow SFP - contains rules on access to statistical data where a subject - is only allowed to access this type of information up to a - specific number of accesses. An example for the second case - would be a rule stating under which conditions and how the - security attributes of a subject or object change as the - result of an access operation. Some information flow policies - for example may limit the number of access operations to - information with specific security attributes. If there are - no additional rules then the PP/ST author should specify - ``none''. - . - - - - The TSF shall explicitly authorise an information flow based - on the following rules: - - - rules, based on security attributes, that explicitly - authorise information flows - - - - the PP/ST author should specify the rules, based on - security attributes, that explicitly authorise - information flows. These rules are in addition to - those specified in the preceding elements. They are - included in as they are - intended to contain exceptions to the rules in the - preceding elements. An example of rules to explicitly - authorise information flows is based on a privilege - vector associated with a subject that always grants - the subject the ability to cause an information flow - for information that is covered by the SFP that has - been specified. If such a capability is not desired, - then the PP/ST author should specify - ``none''. - - . - - - The TSF shall explicitly deny an information flow based on - the following rules: - - - rules, based on security attributes, that explicitly - deny information flows - - - - the PP/ST author should specify the rules, based on security - attributes, that explicitly deny information flows. These rules - are in addition to those specified in the preceding - elements. They are included in as they - are intended to contain exceptions to the rules in the preceding - elements. An example of rules to explicitly deny information - flows is based on a privilege vector associated with a subject - that always denies the subject the ability to cause an - information flow for information that is covered by the SFP that - has been specified. If such a capability is not desired, then - the PP/ST author should specify ``none''. - - . - - - - - - - - - - - - This component requires that the named information flow control - SFP uses hierarchical security attributes that - form a lattice. - - It is important to note that the hierarchical relationship - requirements identified in need - only apply to the information flow control security - attributes for the information flow control SFPs that have - been identified in . This - component is not meant to apply to other SFPs such as - access control SFPs. - phrases the requirements for the set of - security attributes to form a lattice. A number of information - flow policies defined in the literature and implemented in IT - products are based on a set of security attributes that form a - lattice. is specifically included to - address this type of information flow policies. - - If it is the case that multiple information flow control - SFPs are to be specified, and that each of these SFPs will - have their own security attributes that are not related to - one another, then the PP/ST author should iterate this - component once for each of those SFPs. Otherwise a - conflict might arise with the sub-items of since the required relationships will - not exist. - - - expands on the requirements - of by requiring that all - information flow control SFPs in the set of SFRs use - hierarchical security attributes that form a lattice (as defined - in mathematics). is derived from the - mathematical properties of a lattice. A lattice consists of a - set of elements with an ordering relationship with the property - defined in the first bullet, a least upper bound which is the - unique element in the set that is greater or equal (in the - ordering relationship) than any other element of the lattice, - and a greatest lower bound, which is the unique element in the set - that is smaller or equal than any other element of the lattice. - - - - - - - The TSF shall enforce the - - - information flow control SFP - - - - the PP/ST author should specify the information flow - control SFPs enforced by the TSF. The name of the - information flow control SFP, and the scope of control - for that policy are defined in components from . - - - based on the following types of subject and - information security attributes: - - list of subjects and information controlled under the - indicated SFP, and for each, the security attributes - - the PP/ST author should specify, for each type of - controlled subject and information, the security - attributes that are relevant to the specification of the - SFP rules. For example, such security attributes may be - things such the subject identifier, subject sensitivity - label, subject clearance label, information sensitivity - label, etc. The types of security attributes should be - sufficient to support the environmental needs.. - - - The TSF shall permit an information flow between a - controlled subject and controlled information via a - controlled operation if the following rules, based on the - ordering relationships between security attributes hold: - - - for each operation, the security attribute-based - relationship that must hold between subject and - information security attributes - - - - the PP/ST author should specify for each operation, - the security attribute-based relationship that must - hold between subject and information security - attributes that the TSF will enforce. These - relationships should be based upon the ordering - relationships between the security attributes. - - . - - - The TSF shall enforce the - - - additional information flow control SFP rules - - - the PP/ST author should specify any additional information - flow control SFP rules that the TSF is to enforce. This - includes all rules of the SFP that are either not based on the - security attributes of the information and the subject or - rules that automatically modify the security attributes of - information or subjects as a result of an access operation. - An example for the first case is a rule of the SFP controlling - a threshold value for specific types of information. This - would for example be the case when the information flow SFP - contains rules on access to statistical data where a subject - is only allowed to access this type of information up to a - specific number of accesses. An example for the second case - would be a rule stating under which conditions and how the - security attributes of a subject or object change as the - result of an access operation. Some information flow policies - for example may limit the number of access operations to - information with specific security attributes. If there are - no additional rules then the PP/ST author should specify - ``none''. - . - - - - The TSF shall explicitly authorise an information flow based - on the following rules: - - - rules, based on security attributes, that explicitly - authorise information flows - - - - the PP/ST author should specify the rules, based on - security attributes, that explicitly authorise - information flows. These rules are in addition to - those specified in the preceding elements. They are - included in as they are - intended to contain exceptions to the rules in the - preceding elements. An example of rules to explicitly - authorise information flows is based on a privilege - vector associated with a subject that always grants - the subject the ability to cause an information flow - for information that is covered by the SFP that has - been specified. If such a capability is not desired, - then the PP/ST author should specify - ``none''. - - . - - - The TSF shall explicitly deny an information flow based on - the following rules: - - - rules, based on security attributes, that explicitly - deny information flows - - - - the PP/ST author should specify the rules, based on security - attributes, that explicitly deny information flows. These rules - are in addition to those specified in the preceding - elements. They are included in as they are intended to contain exceptions to the - rules in the preceding elements. An example of rules to - explicitly deny information flows is based on a privilege vector - associated with a subject that always denies the subject the - ability to cause an information flow for information that is - covered by the SFP that has been specified. If such a capability - is not desired, then the PP/ST author should specify - ``none''. - - . - - - The TSF shall enforce the following relationships for any - two valid information flow control security attributes: - - - There exists an ordering function that, given two valid - security attributes, determines if the security - attributes are equal, if one security attribute is - greater than the other, or if the security attributes - are incomparable; and - - - There exists a ``least upper bound'' - in the set of security attributes, such that, given any - two valid security attributes, there is a valid security - attribute that is greater than or equal to the two valid - security attributes; and - - - There exists a ``greatest lower - bound'' in the set of security attributes, - such that, given any two valid security attributes, - there is a valid security attribute that is not greater - than the two valid security attributes. - - - - - - - - - - - - This component should be used when at least one of the - SFPs that requires control of illicit information flows - does not require elimination of flows. - - For the specified illicit information flows, certain - maximum capacities should be provided. In addition a PP/ST - author has the ability to specify whether the illicit - information flows must be audited. - - - - , requires the SFP to cover illicit - information flows, but not necessarily eliminate them. - - - Decisions to permit requested information flows. - - - All decisions on requests for information flow. - - - The use of identified illicit information flow channels. - - - The specific security attributes used in making an - information flow enforcement decision. - - - Some specific subsets of the information that has flowed - based upon policy goals (e.g. auditing of downgraded - material). - - - The use of identified illicit information flow channels with - estimated maximum capacity exceeding a specified value. - - - The TSF shall enforce the - - - information flow control SFP - - - - the PP/ST author should specify the information flow - control SFPs enforced by the TSF. The name of the - information flow control SFP, and the scope of control - for that policy are defined in components from . - - - to limit the capacity of - - - types of illicit information flows - - - - the PP/ST author should specify the types of illicit - information flows that are subject to a maximum - capacity limitation. - - - to a - - - maximum capacity - - - - the PP/ST author should specify the maximum capacity - permitted for any identified illicit information - flows. - - . - - - - - - - - - - - This component should be used when all the SFPs that - requires control of illicit information flows require - elimination of some (but not necessarily all) illicit - information flows. - - - - , requires the SFP to cover the - elimination of some (but not necessarily all) illicit - information flows. - - - - - - The TSF shall enforce the - - - information flow control SFP - - - - the PP/ST author should specify the information flow - control SFPs enforced by the TSF. The name of the - information flow control SFP, and the scope of control - for that policy are defined in components from - . - - - to limit the capacity of - - - types of illicit information flows - - - - the PP/ST author should specify the types of illicit - information flows which are subject to a maximum - capacity limitation. - - - to a - - - maximum capacity - - - - the PP/ST author should specify the maximum capacity - permitted for any identified illicit information - flows. - - . - - - The TSF shall prevent - - - types of illicit information flows - - - - the PP/ST author should specify the types of illicit - information flows to be eliminated. This list may not - be empty as this component requires that some illicit - information flows are to be eliminated. - - . - - - - - - - - - - - This component should be used when the SFPs that require - control of illicit information flows require elimination - of all illicit information flows. However, the PP/ST - author should carefully consider the potential impact that - eliminating all illicit information flows might have on - the normal functional operation of the TOE. Many practical - applications have shown that there is an indirect - relationship between illicit information flows and normal - functionality within a TOE and eliminating all illicit - information flows may result in less than desired - functionality. - - - - , requires SFP to cover the - elimination of all illicit information flows. - - - - - - The TSF shall ensure that no illicit information flows exist - to circumvent - - - name of information flow control SFP - - - - the PP/ST author should specify the information flow - control SFP for which illicit information flows are to - be eliminated. The name of the information flow - control SFP, and the scope of control for that policy - are defined in components from . - - . - - - - - - - - - - This component should be used when it is desired that the - TSF provide the ability to monitor the use of illicit - information flows that exceed a specified capacity. If it - is desired that such flows be audited, then this component - could serve as the source of audit events to be used by - components from the family. - - - - , requires the SFP to monitor - illicit information flows for specified and maximum - capacities. - - - The enabling or disabling of the monitoring function. - - - Modification of the maximum capacity at which the monitoring - occurs. - - - - - - The TSF shall enforce the - - - information flow control SFP - - - - the PP/ST author should specify the information flow - control SFPs enforced by the TSF. The name of the - information flow control SFP, and the scope of control - for that policy are defined in components from - . - - - to monitor - - - types of illicit information flows - - - - the PP/ST author should specify the types of illicit - information flows that will be monitored for exceeding - a maximum capacity. - - - when it exceeds the - - - maximum capacity - - - - the PP/ST author should specify the maximum capacity - above which illicit information flows will be - monitored by the TSF. - - . - - - - - - - - This family defines the mechanisms for TSF-mediated importing of user - data into the TOE such that it has appropriate security - attributes and is appropriately protected. It is concerned - with limitations on importation, determination of desired - security attributes, and interpretation of security - attributes associated with the user data. - - - - This family defines mechanisms for TSF-mediated importing of user data from - outside the TOE into the TOE such that the user data - security attributes can be preserved. Consistency of these - security attributes are addressed by . - - is concerned with limitations on - import, user specification of security attributes, and - association of security attributes with the user data. - - This family, and the corresponding export family , address how the TOE deals with user data - outside its control. This family is concerned with assigning - and abstraction of the user data security attributes. - - A variety of activities might be involved here: - - - importing user data from an unformatted medium - (e.g. floppy disk, tape, scanner, video or audit - signal), without including any security attributes, and - physically marking the medium to indicate its contents; - - - importing user data, including security attributes, from - a medium and verifying that the object security - attributes are appropriate; - - - importing user data, including security attributes, from - a medium using a cryptographic sealing technique to - protect the association of user data and security - attributes. - - - - This family is not concerned with the determination of - whether the user data may be imported. It is concerned with - the values of the security attributes to associate with the - imported user data. - - There are two possibilities for the import of user data: - either the user data is unambiguously associated with - reliable object security attributes (values and meaning of - the security attributes is not modified), or no reliable - security attributes (or no security attributes at all) are - available from the import source. This family addresses both - cases. - - If there are reliable security attributes available, they - may have been associated with the user data by physical - means (the security attributes are on the same media), or by - logical means (the security attributes are distributed - differently, but include unique object identification, - e.g. cryptographic checksum). - - This family is concerned with TSF-mediated importing of user data and - maintaining the association of security attributes as - required by the SFP. Other families are concerned with other - import aspects such as consistency, trusted channels, and - integrity that are beyond the scope of this - family. Furthermore, is only concerned - with the interface to the import medium. is responsible for the other end point of the - medium (the source). - - Some of the well known import requirements are: - - - importing of user data without any security attributes; - - - importing of user data including security attributes - where the two are associated with one another and the - security attributes unambiguously represent the - information being imported. - - - - These import requirements may be handled by the TSF with or - without human intervention, depending on the IT limitations - and the organisational security policy. For example, if user - data is received on a ``confidential'' - channel, the security attributes of the objects will be set - to ``confidential''. - - If there are multiple SFPs (access control and/or - information flow control) then it may be appropriate to - iterate these components once for each named SFP. - - - - - - - - - - - - - This component is used to specify the import of user data - that does not have reliable (or any) security attributes - associated with it. This function requires that the - security attributes for the imported user data be - initialised within the TSF. It could also be the case that - the PP/ST author specifies the rules for import. It may be - appropriate, in some environments, to require that these - attributes be supplied via a trusted path or a trusted - channel mechanism. - - - - , requires that the security - attributes correctly represent the user data and are - supplied separately from the object. - - - The modification of the additional control rules used for - import. - - - Successful import of user data, including any security - attributes. - - - All attempts to import user data, including any security - attributes. - - - The specification of security attributes for imported user - data supplied by an authorised user. - - - The TSF shall enforce the - - access control SFP(s) and/or information flow control SFP(s) - - the PP/ST author should specify the access control SFP(s) - and/or information flow control SFP(s) that will be - enforced when importing user data from outside of the - TOE. The user data that this function imports is - scoped by the assignment of these SFPs. - when importing user data, controlled under the SFP, from - outside of the TOE. - - - The TSF shall ignore any security attributes associated with - the user data when imported from outside the TOE. - - - The TSF shall enforce the following rules when importing - user data controlled under the SFP from outside the TOE: - - - additional importation control rules - - - - the PP/ST author should specify any additional - importation control rules or - ``none'' if there are no - additional importation control rules. These rules will - be enforced by the TSF in addition to the access - control SFPs and/or information flow control SFPs - selected in . - - . - - - - - - - - - - - - - - - - - - This component is used to specify the import of user data - that has reliable security attributes associated with - it. This function relies upon the security attributes that - are accurately and unambiguously associated with the - objects on the import medium. Once imported, those objects - will have those same attributes. This requires to ensure the consistency of the data. It - could also be the case that the PP/ST author specifies the - rules for import. - - - - , requires that security attributes - correctly represent the user data and are accurately and - unambiguously associated with the user data imported from - outside the TOE. - - - - - - - The TSF shall enforce the - - - access control SFP(s) and/or information flow control - SFP(s) - - - - the PP/ST author should specify the access control - SFP(s) and/or information flow control SFP(s) that - will be enforced when importing user data from outside - of the TOE. The user data that this function imports - is scoped by the assignment of these SFPs. - - - when importing user data, controlled under the SFP, from - outside of the TOE. - - - The TSF shall use the security attributes associated with - the imported user data. - - - The TSF shall ensure that the protocol used provides for the - unambiguous association between the security attributes and - the user data received. - - - The TSF shall ensure that interpretation of the security - attributes of the imported user data is as intended by the - source of the user data. - - - The TSF shall enforce the following rules when importing - user data controlled under the SFP from outside the TOE: - - - additional importation control rules - - - - the PP/ST author should specify any additional - importation control rules or - ``none'' if there are no - additional importation control rules. These rules will - be enforced by the TSF in addition to the access - control SFPs and/or information flow control SFPs - selected in . - - . - - - - - - - - This family provides requirements that address protection of - user data when it is transferred between separated parts of a TOE - across an internal channel. This may be contrasted with the - and families, - which provide protection for user data when it is - transferred between distinct TSFs across an external - channel, and and , - which address TSF-mediated transfer of data to or from outside the - TOE. - - - - This family provides requirements that address protection of - user data when it is transferred between parts of a TOE - across an internal channel. This may be contrasted with the - and family, which - provide protection for user data when it is transferred - between distinct TSFs across an external channel, and and , which address - TSF-mediated transfer of data to or from outside the TOE. - - The requirements in this family allow a PP/ST author to - specify the desired security for user data while in transit - within the TOE. This security could be protection against - disclosure, modification, or loss of availability. - - The determination of the degree of physical separation above - which this family should apply depends on the intended - environment of use. In a hostile environment, there may be - risks arising from transfers between parts of the TOE - separated by only a system bus. In more benign environments, - the transfers may be across more traditional network media. - - If there are multiple SFPs (access control and/or - information flow control) then it may be appropriate to - iterate these components once for each named SFP. - - - - - - - - - - - - , requires that user data be - protected when transmitted between parts of the TOE. - - - If the TSF provides multiple methods to protect user data - during transmission between physically separated parts of - the TOE, the TSF could provide a pre-defined role with the - ability to select the method that will be used. - - - Successful transfers of user data, including identification - of the protection method used. - - - All attempts to transfer user data, including the protection - method used and any errors that occurred. - - - The TSF shall enforce the - - - access control SFP(s) and/or information flow control - SFP(s) - - - - the PP/ST author should specify the access control - SFP(s) and/or information flow control SFP(s) covering - the information being transferred. - - - to prevent the - - - disclosure - - - modification - - - loss of use - - - - the PP/ST author should specify the types of - transmission errors that the TSF should prevent - occurring for user data while in transport. The options - are disclosure, modification, loss of use. - - - of user data when it is transmitted between - physically-separated parts of the TOE. - - - - - - - - - - - - - - This component could, for example, be used to provide - different forms of protection to information with - different clearance levels. - - One of the ways to achieve separation of data when it is - transmitted is through the use of separate logical or - physical channels. - - - - , requires separation of data based - on the value of SFP-relevant attributes in addition to the - first component. - - - - - - The TSF shall enforce the - - - access control SFP(s) and/or information flow control - SFP(s) - - - - the PP/ST author should specify the access control - SFP(s) and/or information flow control SFP(s) covering - the information being transferred. - - - to prevent the - - - disclosure - - - modification - - - loss of use - - - - the PP/ST author should specify the types of - transmission errors that the TSF should prevent - occurring for user data while in transport. The options - are disclosure, modification, loss of use. - - - of user data when it is transmitted between - physically-separated parts of the TOE. - - - The TSF shall separate data controlled by the SFP(s) when - transmitted between physically-separated parts of the TOE, - based on the values of the following: - - - security attributes that require separation - - - - the PP/ST author should specify the security - attributes, the values of which the TSF will use to - determine when to separate data that is being - transmitted between physically-separated parts of the - TOE. An example is that user data associated with the - identity of one owner is transmitted separately from - the user data associated with the identify of a - different owner. In this case, the value of the - identity of the owner of the data is what is used to - determine when to separate the data for transmission. - - . - - - - - - - - - - - - - - This component is used in combination with either or . It ensures - that the TSF checks received user data (and their - attributes) for integrity. or will provide the data in a manner such - that it is protected from modification (so that can detect any modifications). - - The PP/ST author has to specify the types of errors that - must be detected. The PP/ST author should consider: - modification of data, substitution of data, unrecoverable - ordering change of data, replay of data, incomplete data, - in addition to other integrity errors. - - The PP/ST author must specify the actions that the TSF - should take on detection of a failure. For example: ignore - the user data, request the data again, inform the - authorised administrator, reroute traffic for other lines. - - - - , requires that the TSF monitor user - data transmitted between parts of the TOE for identified - integrity errors. - - - The specification of the actions to be taken upon detection - of an integrity error could be configurable. - - - Successful transfers of user data, including identification - of the integrity protection method used. - - - All attempts to transfer user data, including the integrity - protection method used and any errors that occurred. - - - Unauthorised attempts to change the integrity protection - method. - - - The action taken upon detection of an integrity error. - - - The TSF shall enforce the - - - access control SFP(s) and/or information flow control - SFP(s) - - - - the PP/ST author should specify the access control - SFP(s) and/or information flow control SFP(s) covering - the information being transferred and monitored for - integrity errors. - - - to monitor user data transmitted between - physically-separated parts of the TOE for the following - errors: - - - integrity errors - - - - the PP/ST author should specify the type of possible - integrity errors to be monitored during transmission - of the user data. - - . - - - Upon detection of a data integrity error, the TSF shall - - - specify the action to be taken upon integrity error - - - - the PP/ST author should specify the action to be taken - by the TSF when an integrity error is encountered. An - example might be that the TSF should request the - resubmission of the user data. The SFP(s) specified in - will be enforced as the - actions are taken by the TSF. - - . - - - - - - - - - - - - - - - This component is used in combination with . It ensures that the TSF checks received - user data, that has been transmitted by separate channels - (based on values of specified security attributes), for - integrity. It allows the PP/ST author to specify actions - to be taken upon detection of an integrity error. - - For example, this component could be used to provide - different integrity error detection and action for - information at different integrity levels. - - The PP/ST author has to specify the types of errors that - must be detected. The PP/ST author should consider: - modification of data, substitution of data, unrecoverable - ordering change of data, replay of data, incomplete data, - in addition to other integrity errors. - - The PP/ST author should specify the attributes (and - associated transmission channels) that necessitate - integrity error monitoring - - The PP/ST author must specify the actions that the TSF - should take on detection of a failure. For example: ignore - the user data, request the data again, inform the - authorised administrator, reroute traffic for other lines. - - - - expands on the third component by - allowing the form of integrity monitoring to differ by - SFP-relevant attribute. - - - - - - - - The TSF shall enforce the - - - access control SFP(s) and/or information flow - control SFP(s) - - - - the PP/ST author should specify the access control - SFP(s) and/or information flow control SFP(s) covering - the information being transferred and monitored for - integrity errors. - - - to monitor user data transmitted between - physically-separated parts of the TOE for the following - errors: - - - integrity errors - - - - the PP/ST author should specify the type of possible - integrity errors to be monitored during transmission - of the user data. - - , based on the following attributes: - - - security attributes that require separate transmission - channels - - - - the PP/ST author should specify a list of security - attributes that require separate transmission - channels. This list is used to determine which user - data to monitor for integrity errors., based on its - security attributes and its transmission channel. This - element is directly related to . - - . - - - Upon detection of a data integrity error, the TSF shall - - - specify the action to be taken upon integrity - error - - - - the PP/ST author should specify the action to be taken - by the TSF when an integrity error is encountered. An - example might be that the TSF should request the - resubmission of the user data. The SFP(s) specified in - will be enforced as the - actions are taken by the TSF. - - . - - - - - - - - This family addresses the need to ensure that any data contained - in a resource is not available when the resource is de-allocated - from one object and reallocated to a different object. This - family requires protection for any data contained in a resource - that has been logically deleted or released, but may still be - present within the TSF-controlled resource which in turn may be - re-allocated to another object. - - - - Residual information protection ensures that TSF-controlled - resources when de-allocated from an object and before they are - reallocated to another object are treated by the TSF in a way - that it is not possible to reconstruct all or part of the data - contained in the resource before it was de-allocated. - - A TOE usually has a number of functions that potentially - de-allocate resources from an object and potentially re-allocate - those resources to objects. Some, but not all of those resources - may have been used to store critical data from the previous use - of the resource and for those resources FDP_RIP requires that - they are prepared for reuse. Object reuse applies to explicit - requests of a subject or user to release resources as well as - implicit actions of the TSF that result in the de-allocation and - subsequent re-allocation of resources to different - objects. Examples of explicit requests are the deletion or - truncation of a file or the release of an area of main - memory. Examples of implicit actions of the TSF are the - de-allocation and re-allocation of cache regions. - The requirement for object reuse is related to the content of - the resource belonging to an object, not all information about - the resource or object that may be stored elsewhere in the - TSF. As an example to satisfy the FDP_RIP requirement for files - as objects requires that all sectors that make up the file need - to be prepared for re-use. - - It also applies to resources that are serially reused by - different subjects within the system. For example, most - operating systems typically rely upon hardware registers - (resources) to support processes within the system. As - processes are swapped from a ``run'' state to a ``sleep'' - state (and vice versa), these registers are serially reused - by different subjects. While this ``swapping'' action may - not be considered an allocation or deallocation of a - resource, could apply to - such events and resources. - - typically controls access - to information that is not part of any currently defined or - accessible object; however, in certain cases this may not be - true. For example, object ``A'' is a file and object ``B'' - is the disk upon which that file resides. If object ``A'' is - deleted, the information from object ``A'' is under the - control of even though it - is still part of object ``B''. - - It is important to note that applies only to on-line objects and not - off-line objects such as those backed-up on tapes. For - example, if a file is deleted in the TOE, can be instantiated to require that no - residual information exists upon deallocation; however, the - TSF cannot extend this enforcement to that same file that - exists on the off-line back-up. Therefore that same file is - still available. If this is a concern, then the PP/ST author - should make sure that the proper environmental objectives - are in place to support operational user guidance to address - off-line objects. - - and can conflict when is instantiated to require that residual - information be cleared at the time the application releases - the object to the TSF (i.e. upon deallocation). Therefore, - the selection of - ``deallocation'' should not be used with since there would be no information to roll - back. The other selection, ``unavailability upon - allocation'', may be used with , but there is the risk that the resource - which held the information has been allocated to a new - object before the roll back took place. If that were to - occur, then the roll back would not be possible. - - There are no audit requirements in because this is not a user-invokable - function. Auditing of allocated or deallocated resources - would be auditable as part of the access control SFP or the - information flow control SFP operations. - - This family should apply to the objects specified in the - access control SFP(s) or the information flow control SFP(s) - as specified by the PP/ST author. - - - - - - This component requires that, for a subset of the objects - in the TOE, the TSF will ensure that there is no available - residual information contained in a resource allocated to - those objects or deallocated from those objects. - - - - , requires that the TSF - ensure that any residual information content of any - resources is unavailable to a defined subset of the - objects controlled by the TSF upon the resource's - allocation or deallocation. - - - The choice of when to perform residual information - protection (i.e. upon allocation or deallocation) could be - made configurable within the TOE. - - - 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 - - - - the PP/ST author should specify the event, allocation - of the resource to or deallocation of the resource - from, that invokes the residual information protection - function. - - - the following objects: - - - list of objects - - - - the PP/ST author should specify the list of objects - subject to residual information protection. - - . - - - - - - - - This component requires that for all objects in the TOE, - the TSF will ensure that there is no available residual - information contained in a resource allocated to those - objects or deallocated from those objects. - - - - , requires that the TSF ensure that - any residual information content of any resources is - unavailable to all objects upon the resource's - allocation or deallocation. - - - - 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 - - - - the PP/ST author should specify the event, allocation - of the resource to or deallocation of the resource - from, that invokes the residual information protection - function. - - - all objects. - - - - - - - - The rollback operation involves undoing the last operation - or a series of operations, bounded by some limit, such as a - period of time, and return to a previous known - state. Rollback provides the ability to undo the effects of - an operation or series of operations to preserve the - integrity of the user data. - - - - This family addresses the need to return to a well defined - valid state, such as the need of a user to undo - modifications to a file or to undo transactions in case of - an incomplete series of transaction as in the case of - databases. - - This family is intended to assist a user in returning to a - well defined valid state after the user undoes the last set - of actions, or, in distributed databases, the return of all - of the distributed copies of the databases to the state - before an operation failed. - - and conflict when - enforces that the contents will be made - unavailable at the time that a resource is deallocated from - an object. Therefore, this use of - cannot be combined with as there would - be no information to roll back. can be - used only with when it enforces that - the contents will be unavailable at the time that a resource - is allocated to an object. This is because the mechanism will have an opportunity to access - the previous information that may still be present in the - TOE in order to successfully roll back the operation. - - The rollback requirement is bounded by certain limits. For - example a text editor typically only allows you roll back up - to a certain number of commands. Another example would be - backups. If backup tapes are rotated, after a tape is - reused, the information can no longer be retrieved. This - also poses a bound on the rollback requirement. - - - - - - - - - - - - This component allows a user or subject to undo a set of - operations on a predefined set of objects. The undo is - only possible within certain limits, for example up to a - number of characters or up to a time limit. - - - - addresses a need to roll back or - undo a limited number of operations within the defined - bounds. - - - The boundary limit to which rollback may be performed could - be a configurable item within the TOE. - - - Permission to perform a rollback operation could be - restricted to a well defined role. - - - All successful rollback operations. - - - All attempts to perform rollback operations. - - - All attempts to perform rollback operations, including - identification of the types of operations rolled back. - - - The TSF shall enforce - - - access control SFP(s) and/or information flow control - SFP(s) - - - - the PP/ST author should specify the access control - SFP(s) and/or information flow control SFP(s) that - will be enforced when performing rollback - operations. This is necessary to make sure that roll - back is not used to circumvent the specified SFPs. - - - to permit the rollback of the - - - list of operations - - - - the PP/ST author should specify the list of operations - that can be rolled back. - - - on the - - information and/or list of objects - - the PP/ST author should specify the information and/or - list of objects that are subjected to the rollback policy.. - - - The TSF shall permit operations to be rolled back within the - - - boundary limit to which rollback may be performed - - - - the PP/ST author should specify the boundary limit to - which rollback operations may be performed. The - boundary may be specified as a predefined period of - time, for example, operations may be undone which were - performed within the past two minutes. Other possible - boundaries may be defined as the maximum number of - operations allowable or the size of a buffer. - - . - - - - - - - - - - - - - - This component enforces that the TSF provide the - capability to rollback all operations; however, the user - can choose to rollback only a part of them. - - - - addresses the need to roll back or - undo all operations within the defined bounds. - - - - - - - The TSF shall enforce - - - access control SFP(s) and/or information flow control - SFP(s) - - - - the PP/ST author should specify the access control - SFP(s) and/or information flow control SFP(s) that - will be enforced when performing rollback - operations. This is necessary to make sure that roll - back is not used to circumvent the specified SFPs. - - - to permit the rollback of all the operations on the - - - list of objects - - - - the PP/ST author should specify the list of objects - that are subjected to the rollback policy. - - . - - - The TSF shall permit operations to be rolled back within the - - - boundary limit to which rollback may be performed - - - - the PP/ST author should specify the boundary limit to - which rollback operations may be performed. The - boundary may be specified as a predefined period of - time, for example, operations may be undone which were - performed within the past two minutes. Other possible - boundaries may be defined as the maximum number of - operations allowable or the size of a buffer. - - . - - - - - - - - This family provides requirements that address protection of - user data while it is stored within containers controlled by the TSF. Integrity - errors may affect user data stored in memory, or in a - storage device. This family differs from which protects the user data from integrity - errors while being transferred within the TOE. - - - - This family provides requirements that address protection of - user data while it is stored within containers controlled by the TSF. - - Hardware glitches or errors may affect data stored in - memory. This family provides requirements to detect these - unintentional errors. The integrity of user data while - stored on storage devices controlled by the TSF are also addressed - by this family. - - To prevent a subject from modifying the data, the or families are required - (rather than this family). - - This family differs from that protects - the user data from integrity errors while being transferred - within the TOE. - - - - - - This component monitors data stored on media for integrity - errors. The PP/ST author can specify different kinds of - user data attributes that will be used as the basis for - monitoring. - - - - , requires that the TSF monitor user - data stored within containers controlled by the TSF for identified integrity - errors. - - - Successful attempts to check the integrity of user data, - including an indication of the results of the check. - - - All attempts to check the integrity of user data, including - an indication of the results of the check, if performed. - - - The type of integrity error that occurred. - - - The TSF shall monitor user data stored in containers controlled by the TSF for - - - integrity errors - - - - the PP/ST author should specify the integrity errors - that the TSF will detect. - - - on all objects, based on the following attributes: - - - user data attributes - - - - the PP/ST author should specify the user data - attributes that will be used as the basis for the - monitoring. - - . - - - - - - - - This component monitors data stored on media for integrity - errors. The PP/ST author can specify which action should - be taken in case an integrity error is detected. - - - - adds the additional capability to - the first component by allowing for actions to be taken as - a result of an error detection. - - - The actions to be taken upon the detection of an integrity - error could be configurable. - - - Successful attempts to check the integrity of user data, - including an indication of the results of the check. - - - All attempts to check the integrity of user data, including - an indication of the results of the check, if performed. - - - The type of integrity error that occurred. - - - The action taken upon detection of an integrity error. - - - The TSF shall monitor user data stored in containers controlled by the TSF for - - - integrity errors - - - - the PP/ST author should specify the integrity errors - that the TSF will detect. - - - on all objects, based on the following attributes: - - - user data attributes - - - - the PP/ST author should specify the user data - attributes that will be used as the basis for the - monitoring. - - . - - - Upon detection of a data integrity error, the TSF shall - - - action to be taken - - - - the PP/ST author should specify the actions to be - taken in case an integrity error is detected. - - . - - - - - - - - This family defines the requirements for ensuring the - confidentiality of user data when it is transferred using an - external channel between the TOE and another trusted IT product. - - - - This family defines the requirements for ensuring the - confidentiality of user data when it is transferred using an - external channel between the TOE and another trusted IT - product. Confidentiality is enforced by preventing - unauthorised disclosure of user data in transit between the - two end points. The end points may be a TSF or a user. - - This family provides a requirement for the protection of user - data during transit. In contrast, handles TSF data. - - - - - - - - - - - - - - - - Depending on the access control or information flow policies the TSF is - required to send or receive user data in a manner such that the - confidentiality of the user data is protected. - - - - In , the goal is to provide - protection from disclosure of user data while in transit. - - - The identity of any user or subject using the data exchange - mechanisms. - - - The identity of any unauthorised user or subject attempting - to use the data exchange mechanisms. - - - A reference to the names or other indexing information - useful in identifying the user data that was transmitted or - received. This could include security attributes associated - with the information. - - - The TSF shall enforce the - - access control SFP(s) and/or information flow control SFP(s) - the PP/ST author should specify the access control SFP(s) - and/or information flow control SFP(s) that will be enforced when exchanging - user data. The specified policies will be enforced to make decisions about - who can exchange data and which data can be exchanged. - to - transmitreceivethe PP/ST author should specify whether this element - applies to a mechanism that transmits or receives user data. - user data in a manner protected from unauthorised disclosure. - - - - - - - - This family defines the requirements for providing integrity - for user data in transit between the TOE and another trusted - IT product and recovering from detectable errors. At a - minimum, this family monitors the integrity of user data for - modifications. Furthermore, this family supports different - ways of correcting detected integrity errors. - - - - This family defines the requirements for providing integrity - for user data in transit between the TSF and another trusted - IT product and recovering from detectable errors. At a - minimum, this family monitors the integrity of user data for - modifications. Furthermore, this family supports different - ways of correcting detected integrity errors. - - This family defines the requirements for providing integrity - for user data in transit; while handles - TSF data. - - and are duals of - each other, as addresses user data - confidentiality. Therefore, the same mechanism that - implements could possibly be used to - implement other families such as and - . - - - - - - - - - - - - - - - - Depending on the access control or information flow policies the TSF is - required to send or receive user data in a manner such that modification - of the user data is detected. There is no requirement for a TSF mechanism - to attempt to recover from the modification. - - - - addresses detection of - modifications, deletions, insertions, and replay errors of - the user data transmitted. - - - The identity of any user or subject using the data exchange - mechanisms. - - - The identity of any user or subject attempting to use the - user data exchange mechanisms, but who is unauthorised to do - so. - - - A reference to the names or other indexing information - useful in identifying the user data that was transmitted or - received. This could include security attributes associated - with the user data. - - - Any identified attempts to block transmission of user data. - - - The types and/or effects of any detected modifications of - transmitted user data. - - - The TSF shall enforce the - access control SFP(s) and/or information flow control SFP(s) - the PP/ST author should specify the access control SFP(s) - and/or information flow control SFP(s) that will be enforced on the transmitted - data or on the received data. The specified policies will be enforced to make - decisions about who can transmit or who can receive data, and which data can be - transmitted or received. - to - transmitreceivethe PP/ST author should specify whether this element applies - to a TSF that is transmitting or receiving objects. - user data in a manner protected from - modificationdeletioninsertionreplaythe PP/ST author should specify whether the data should be - protected from modification, deletion, insertion or replay. - errors. - - - The TSF shall be able to determine on receipt of user data, - whether - - - modification - - - deletion - - - insertion - - - replay - - - - the PP/ST author should specify whether the errors of - the type: modification, deletion, insertion or replay - are detected. - - - has occurred. - - - - - - - - - - - - - - - - - This component provides the ability to recover from a set - of identified transmission errors, if required, with the - help of the other trusted IT product. As the other trusted - IT product is outside the TOE, the TSF cannot control its - behaviour. However, it can provide functions that have the - ability to cooperate with the other trusted IT product for - the purposes of recovery. For example, the TSF could - include functions that depend upon the source trusted IT - product to re-send the data in the event that an error is - detected. This component deals with the ability of the TSF - to handle such an error recovery. - - - - addresses recovery of the original - user data by the receiving TSF with help from the source - trusted IT product. - - - The identity of any user or subject using the data exchange - mechanisms. - - - Successful recovery from errors including they type of error - that was detected. - - - The identity of any user or subject attempting to use the - user data exchange mechanisms, but who is unauthorised to do - so. - - - A reference to the names or other indexing information - useful in identifying the user data that was transmitted or - received. This could include security attributes associated - with the user data. - - - Any identified attempts to block transmission of user data. - - - The types and/or effects of any detected modifications of - transmitted user data. - - - The TSF shall enforce the - - - access control SFP(s) and/or information flow control - SFP(s) - - - - the PP/ST author should specify the access control - SFP(s) and/or information flow control SFP(s) that - will be enforced when recovering user data. The - specified policies will be enforced to make decisions - about which data can be recovered and how it can be - recovered. - - - to be able to recover from - - - list of recoverable errors - - - - the PP/ST author should specify the list of integrity - errors from which the TSF, with the help of the source - trusted IT product, is be able to recover the original - user data. - - - with the help of the source trusted IT product. - - - - - - - - - - - - - - - - - - - - This component provides the ability to recover from a set - of identified transmission errors. It accomplishes this - task without help from the source trusted IT product. For - example, if certain errors are detected, the transmission - protocol must be robust enough to allow the TSF to recover - from the error based on checksums and other information - available within that protocol. - - - - addresses recovery of the original - user data by the receiving TSF on its own without any help - from the source trusted IT product. - - - - - - The TSF shall enforce the - - - access control SFP(s) and/or information flow control - SFP(s) - - - - the PP/ST author should specify the access control - SFP(s) and/or information flow control SFP(s) that - will be enforced when recovering user data. The - specified policies will be enforced to make decisions - about which data can be recovered and how it can be - recovered. - - - to be able to recover from - - - list of recoverable errors - - - - the PP/ST author should specify the list of integrity - errors from which the receiving TSF, alone, is able to - recover the original user data. - - - without any help from the source trusted IT product. - - - - - - - - Families in this class address the requirements for functions - to establish and verify a claimed user identity. - - Identification and Authentication is required to ensure that - users are associated with the proper security attributes - (e.g. identity, groups, roles, security or integrity levels). - - The unambiguous identification of authorised users and the - correct association of security attributes with users and - subjects is critical to the enforcement of the intended - security policies. The families in this class deal with - determining and verifying the identity of users, determining - their authority to interact with the TOE, and with the correct - association of security attributes for each authorised - user. Other classes of requirements (e.g. User Data - Protection, Security Audit) are dependent upon correct - identification and authentication of users in order to be - effective. - - - - A common security requirement is to unambiguously identify the - person and/or entity performing functions in a TOE. This - involves not only establishing the claimed identity of each - user, but also verifying that each user is indeed who he/she - claims to be. This is achieved by requiring users to provide - the TSF with some information that is known by the TSF to be - associated with the user in question. - - Families in this class address the requirements for functions - to establish and verify a claimed user - identity. Identification and Authentication is required to - ensure that users are associated with the proper security - attributes (e.g. identity, groups, roles, security or - integrity levels). - - The unambiguous identification of authorised users and the - correct association of security attributes with users and - subjects is critical to the enforcement of the security - policies. - - The family addresses determining the - identity of a user. - - The family addresses verifying the - identity of a user. - - The family addresses defining limits on - repeated unsuccessful authentication attempts. - - The family address the definition of user - attributes that are used in the enforcement of the SFRs. - - The family addresses the correct - association of security attributes for each authorised user. - - The family addresses the generation and - verification of secrets that satisfy a defined metric. - - - - - - This family contains requirements for defining values for - some number of unsuccessful authentication attempts and TSF - actions in cases of authentication attempt - failures. Parameters include, but are not limited to, the - number of failed authentication attempts and time - thresholds. - - - - This family addresses requirements for defining values for - authentication attempts and TSF actions in cases of - authentication attempt failure. Parameters include, but are - not limited to, the number of attempts and time thresholds. - - The session establishment process is the interaction with - the user to perform the session establishment independent of - the actual implementation. If the number of unsuccessful - authentication attempts exceeds the indicated threshold, - either the user account or the terminal (or both) will be - locked. If the user account is disabled, the user cannot - log-on to the system. If the terminal is disabled, the - terminal (or the address that the terminal has) cannot be - used for any log-on. Both of these situations continue until - the condition for re-establishment is satisfied. - - - - - - - - - The PP/ST author may define the number of unsuccessful - authentication attempts or may choose to let the TOE - developer or the authorised user to define this - number. The unsuccessful authentication attempts need not - be consecutive, but rather related to an authentication - event. Such an authentication event could be the count - from the last successful session establishment at a given - terminal. - - The PP/ST author could specify a list of actions that the - TSF shall take in the case of authentication failure. An - authorised administrator could also be allowed to manage - the events, if deemed opportune by the PP/ST author. These - actions could be, among other things, terminal - deactivation, user account deactivation, or administrator - alarm. The conditions under which the situation will be - restored to normal must be specified on the action. - - In order to prevent denial of service, TOEs usually ensure - that there is at least one user account that cannot be - disabled. - - Further actions for the TSF can be stated by the PP/ST - author, including rules for re-enabling the user session - establishment process, or sending an alarm to the - administrator. Examples of these actions are: until a - specified time has lapsed, until the authorised - administrator re-enables the terminal/account, a time - related to failed previous attempts (every time the - attempt fails, the disabling time is doubled). - - - - , requires that the TSF be able to - terminate the session establishment process after a - specified number of unsuccessful user authentication - attempts. It also requires that, after termination of the - session establishment process, the TSF be able to disable - the user account or the point of entry (e.g. workstation) - from which the attempts were made until an - administrator-defined condition occurs. - - - management of the threshold for unsuccessful authentication - attempts; - - - management of actions to be taken in the event of an - authentication failure. - - - the reaching of the threshold for the unsuccessful - authentication attempts and the actions (e.g. disabling of a - terminal) taken and the subsequent, if appropriate, - restoration to the normal state (e.g. re-enabling of a - terminal). - - - The TSF shall detect when - - positive integer number - - if the assignment of a positive integer is selected, - the PP/ST author should specify the default number - (positive integer) of unsuccessful authentication - attempts that, when met or surpassed, will trigger - the events. - an administrator configurable positive integer within - - range of acceptable values - - if an administrator configurable positive integer is - selected, the PP/ST author should specify the range of - acceptable values from which the administrator of the - TOE may configure the number of unsuccessful - authentication attempts. The number of authentication - attempts should be less than or equal to the upper - bound and greater or equal to the lower bound values. - the PP/ST author should select either the assignment of a positive integer, - or the phrase ``an administrator configurable positive integer'' specifying - the range of acceptable values. - unsuccessful authentication attempts occur related to - - - list of authentication events - - - - the PP/ST author should specify the authentication - events. Examples of these authentication events are: - the unsuccessful authentication attempts since the - last successful authentication for the indicated user - identity, the unsuccessful authentication attempts - since the last successful authentication for the - current terminal, the number of unsuccessful - authentication attempts in the last 10 minutes. At - least one authentication event must be specified. - - . - - - When the defined number of unsuccessful authentication - attempts has been - metsurpassed - the PP/ST author should select whether the event of - meeting or surpassing the defined number of unsuccessful - authentication attemps shall trigger an action by the - TSF., the TSF shall - - list of actions - - the PP/ST author should specify the actions to be taken in - case the threshold is met or surpassed, as selected. These - actions could be disabling of an account for 5 minutes, - disabling the terminal for an increasing amount of time (2 - to the power of the number of unsuccessful attempts in - seconds), or disabling of the account until unlocked by - the administrator and simultaneously informing the - administrator. The actions should specify the measures and - if applicable the duration of the measure (or the - conditions under which the measure will be ended).. - - - - - - - - All authorised users may have a set of security attributes, - other than the user's identity, that is used to - enforce the SFRs. This family defines the requirements for - associating user security attributes with users as needed to - support the TSF in making security decisions. - - - - All authorised users may have a set of security attributes, - other than the user's identity, that are used to - enforce the SFRs. This family defines the requirements for - associating user security attributes with users as needed to - support the TSF in making security decisions. - - There are dependencies on the individual security policy (SFP) - definitions. These individual definitions should contain the - listing of attributes that are necessary for policy - enforcement. - - - - - - This component specifies the security attributes that - should be maintained at the level of the user. This means - that the security attributes listed are assigned to and - can be changed at the level of the user. In other words, - changing a security attribute in this list associated with - a user should have no impact on the security attributes of - any other user. - - In case security attributes belong to a group of users - (such as Capability List for a group), the user will need - to have a reference (as security attribute) to the - relevant group. - - - - , allows user security attributes - for each user to be maintained individually. - - - if so indicated in the assignment, the authorised - administrator might be able to define additional security - attributes for users. - - - The TSF shall maintain the following list of security - attributes belonging to individual users: - - - list of security attributes - - - - the PP/ST author should specify the security - attributes that are associated to an individual - user. An example of such a list is - {``clearance'', ``group - identifier'', ``rights''}. - - . - - - - - - - - This family defines requirements for mechanisms that enforce - defined quality metrics on provided secrets and generate - secrets to satisfy the defined metric. - - - - This family defines requirements for mechanisms that enforce - defined quality metrics on provided secrets, and generate - secrets to satisfy the defined metric. Examples of such - mechanisms may include automated checking of user supplied - passwords, or automated password generation. - - A secret can be generated outside the TOE (e.g. selected by - the user and introduced in the TOE). In such cases, the - component can be used to - ensure that the external generated secret adheres to certain - standards, for example a minimum size, not present in a - dictionary, and/or not previously used. - - Secrets can also be generated by the TOE. In those cases, - the component can be used - to require the TOE to ensure that the secrets that will - adhere to some specified metrics. - - Secrets contain the authentication data provided by the user - for an authentication mechanism that is based on knowledge - the user possesses. When cryptographic keys are employed, - the class should be used instead of this - family. - - - - - - Secrets can be generated by the user. This component - ensures that those user generated secrets can be verified - to meet a certain quality metric. - - - - , requires the TSF to verify that - secrets meet defined quality metrics. - - - the management of the metric used to verify the secrets. - - - Rejection by the TSF of any tested secret; - - - Rejection or acceptance by the TSF of any tested secret; - - - Identification of any changes to the defined quality - metrics. - - - The TSF shall provide a mechanism to verify that secrets - meet - - - a defined quality metric - - - - the PP/ST author should provide a defined quality - metric. The quality metric specification can be as - simple as a description of the quality checks to be - performed, or as formal as a reference to a government - published standard that defines the quality metrics - that secrets must meet. Examples of quality metrics - could include a description of the alphanumeric - structure of acceptable secrets and/or the space size - that acceptable secrets must meet. - - . - - - - - - - This component allows the TSF to generate secrets for - specific functions such as authentication by means of - passwords. - - When a pseudo-random number generator is used in a secret - generation algorithm, it should accept as input random - data that would provide output that has a high degree of - unpredictability. This random data (seed) can be derived - from a number of available parameters such as a system - clock, system registers, date, time, etc. The parameters - should be selected to ensure that the number of unique - seeds that can be generated from these inputs should be at - least equal to the minimum number of secrets that must be - generated. - - - - , requires the TSF to be able to - generate secrets that meet defined quality metrics. - - - the management of the metric used to generate the secrets. - - - - - - The TSF shall provide a mechanism to generate secrets that - meet - - - a defined quality metric - - - - the PP/ST author should provide a defined quality - metric. The quality metric specification can be as - simple as a description of the quality checks to be - performed or as formal as a reference to a government - published standard that defines the quality metrics - that secrets must meet. Examples of quality metrics - could include a description of the alphanumeric - structure of acceptable secrets and/or the space size - that acceptable secrets must meet. - - . - - - The TSF shall be able to enforce the use of TSF generated - secrets for - - - list of TSF functions - - - - the PP/ST author should provide a list of TSF - functions for which the TSF generated secrets must be - used. An example of such a function could include a - password based authentication mechanism. - - . - - - - - - - - This family defines the types of user authentication - mechanisms supported by the TSF. This family also defines - the required attributes on which the user authentication - mechanisms must be based. - - - - This family defines the types of user authentication - mechanisms supported by the TSF. This family defines the - required attributes on which the user authentication - mechanisms must be based. - - - - - - - - - This component requires that the PP/ST author define the - TSF-mediated actions that can be performed by the TSF on - behalf of the user before the claimed identity of the user - is authenticated. The TSF-mediated actions should have no - security concerns with users incorrectly identifying - themselves prior to being authenticated. For all other - TSF-mediated actions not in the list, the user must be - authenticated before the action can be performed by the - TSF on behalf of the user. - - This component cannot control whether the actions can also - be performed before the identification took place. This - requires the use of either or - with the appropriate assignments. - - - - , allows a user to perform certain - actions prior to the authentication of the - user's identity. - - - management of the authentication data by an administrator; - - - management of the authentication data by the associated - user; - - - managing the list of actions that can be taken before the - user is authenticated. - - - Unsuccessful use of the authentication mechanism; - - - All use of the authentication mechanism; - - - All TSF mediated actions performed before authentication of - the user. - - - The TSF shall allow - - - list of TSF mediated actions - - - - the PP/ST author should specify a list of TSF-mediated - actions that can be performed by the TSF on behalf of - a user before the claimed identity of the user is - authenticated. This list cannot be empty. If no - actions are appropriate, component should be used instead. An example of - such an action might include the request for help on - the login procedure. - - - on behalf of the user to be performed before the user is - authenticated. - - - The TSF shall require each user to be successfully - authenticated before allowing any other TSF-mediated actions - on behalf of that user. - - - - - - - - - - - This component requires that a user is authenticated before any other - TSF-mediated action can take place on behalf of that user. - - - , requires that users are - authenticated before any other action will be allowed by the TSF. - - - management of the authentication data by an administrator; - - - management of the authentication data by the user associated - with this data. - - - Unsuccessful use of the authentication mechanism; - - - All use of the authentication mechanism. - - - The TSF shall require each user to be successfully - authenticated before allowing any other TSF-mediated actions - on behalf of that user. - - - - - - - This component addresses requirements for mechanisms that - provide protection of authentication data. Authentication - data that is copied from another user, or is in some way - constructed should be detected and/or rejected. These - mechanisms provide confidence that users authenticated by - the TSF are actually who they claim to be. - - This component may be useful only with authentication - mechanisms that are based on authentication data that - cannot be shared (e.g. biometrics). It is impossible for a - TSF to detect or prevent the sharing of passwords outside - the control of the TSF. - - - - Unforgeable authentication, - requires the authentication mechanism to be able to detect - and prevent the use of authentication data that has been - forged or copied. - - - Detection of fraudulent authentication data; - - - All immediate measures taken and results of checks on the - fraudulent data. - - - The TSF shall - - - detect - - - prevent - - - - the PP/ST author should specify whether the TSF will - detect, prevent, or detect and prevent forging of - authentication data. - - - use of authentication data that has been forged by any user - of the TSF. - - - The TSF shall - - - detect - - - prevent - - - - the PP/ST author should specify whether the TSF will - detect, prevent, or detect and prevent copying of - authentication data. - - - use of authentication data that has been copied from any - other user of the TSF. - - - - - - - This component addresses requirements for authentication - mechanisms based on single-use authentication - data. Single-use authentication data can be something the - user has or knows, but not something the user is. Examples - of single-use authentication data include single-use - passwords, encrypted time-stamps, and/or random numbers - from a secret lookup table. - - The PP/ST author can specify to which authentication - mechanism(s) this requirement applies. - - - - , requires an authentication - mechanism that operates with single-use authentication - data. - - - Attempts to reuse authentication data. - - - The TSF shall prevent reuse of authentication data related - to - - - identified authentication mechanism(s) - - - - the PP/ST author should specify the list of - authentication mechanisms to which this requirement - applies. This assignment can be ``all - authentication mechanisms''. An example of - this assignment could be ``the - authentication mechanism employed to authenticate - people on the external network''. - - . - - - - - - - The use of this component allows specification of - requirements for more than one authentication mechanism to - be used within a TOE. For each distinct mechanism, - applicable requirements must be chosen from the class to be applied to each - mechanism. It is possible that the same component could be - selected multiple times in order to reflect different - requirements for the different use of the authentication - mechanism. - - The management functions in the class FMT may provide - maintenance capabilities for the set of authentication - mechanisms, as well as the rules that determine whether - the authentication was successful. - - To allow anonymous users to interact with the TOE, a - ``none'' authentication mechanism can be incorporated. The - use of such access should be clearly explained in the - rules of . - - - - , requires that different - authentication mechanisms be provided and used to - authenticate user identities for specific events. - - - the management of authentication mechanisms; - - - the management of the rules for authentication. - - - The final decision on authentication; - - - The result of each activated mechanism together with the - final decision. - - - The TSF shall provide - - - list of multiple authentication mechanisms - - - - the PP/ST author should define the available - authentication mechanisms. An example of such a list - could be: ``none, password mechanism, - biometric (retinal scan), S/key mechanism''. - - - to support user authentication. - - - The TSF shall authenticate any user's claimed - identity according to the - - - rules describing how the multiple authentication - mechanisms provide authentication - - - - the PP/ST author should specify the rules that - describe how the authentication mechanisms provide - authentication and when each is to be used. This means - that for each situation the set of mechanisms that - might be used for authenticating the user must be - described. An example of a list of such rules is: - ``if the user has special privileges a - password mechanism and a biometric mechanism both - shall be used, with success only if both succeed; for - all other users a password mechanism shall be - used.'' - - The PP/ST author might give the boundaries within - which the authorised administrator may specify - specific rules. An example of a rule is: - ``the user shall always be authenticated by - means of a token; the administrator might specify - additional authentication mechanisms that also must be - used.'' The PP/ST author also might choose - not to specify any boundaries but leave the - authentication mechanisms and their rules completely - up to the authorised administrator. - - . - - - - - - - This component addresses potential needs to - re-authenticate users at defined points in time. These may - include user requests for the TSF to perform security - relevant actions, as well as requests from non-TSF - entities for re-authentication (e.g. a server application - requesting that the TSF re-authenticate the client it is - serving). - - - - , requires the ability to specify - events for which the user needs to be re-authenticated. - - - if an authorised administrator could request - re-authentication, the management includes a - re-authentication request. - - - Failure of reauthentication; - - - All reauthentication attempts. - - - The TSF shall re-authenticate the user under the conditions - - - list of conditions under which re-authentication is - required - - - - the PP/ST author should specify the list of conditions - requiring re-authentication. This list could include a - specified user inactivity period that has elapsed, the - user requesting a change in active security - attributes, or the user requesting the TSF to perform - some security critical function. - - The PP/ST author might give the boundaries within - which the reauthentication should occur and leave the - specifics to the authorised administrator. An example - of such a rule is: ``the user shall always - be re-authenticated at least once a day; the - administrator might specify that the re-authentication - should happen more often but not more often than once - every 10 minutes.'' - - . - - - - - - - - - - This component addresses the feedback on the - authentication process that will be provided to the - user. In some systems the feedback consists of indicating - how many characters have been typed but not showing the - characters themselves, in other systems even this - information might not be appropriate. - - This component requires that the authentication data is - not provided as-is back to the user. In a workstation - environment, it could display a - ``dummy'' (e.g. star) for each - password character provided, and not the original - character. - - - - , requires that only limited - feedback information is provided to the user during the - authentication. - - - The TSF shall provide only - - - list of feedback - - - - the PP/ST author should specify the feedback related - to the authentication process that will be provided to - the user. An example of a feedback assignment is - ``the number of characters - typed'', another type of feedback is - ``the authentication mechanism that failed - the authentication''. - - - to the user while the authentication is in progress. - - - - - - - - This family defines the conditions under which users shall - be required to identify themselves before performing any - other actions that are to be mediated by the TSF and which - require user identification. - - - - This family defines the conditions under which users are - required to identify themselves before performing any other - actions that are to be mediated by the TSF and that require - user identification. - - - - - - This component poses requirements for the user to be - identified. The PP/ST author can indicate specific actions - that can be performed before the identification takes - place. - - If is used, the TSF-mediated - actions mentioned in should also - appear in this . - - - - , allows users to perform certain - actions before being identified by the TSF. - - - the management of the user identities; - - - if an authorised administrator can change the actions - allowed before identification, the managing of the action - lists. - - - Unsuccessful use of the user identification mechanism, - including the user identity provided; - - - All use of the user identification mechanism, including the - user identity provided. - - - The TSF shall allow - - - list of TSF-mediated actions - - - - the PP/ST author should specify a list of TSF-mediated - actions that can be performed by the TSF on behalf of - a user before the user has to identify itself. If no - actions are appropriate, component should be used instead. An example of - such an action might include the request for help on - the login procedure. - - - on behalf of the user to be performed before the user is - identified. - - - The TSF shall require each user to be successfully identified before - allowing any other TSF-mediated actions on behalf of that user. - - - - - - - - In this component users will be identified. A user is not - allowed by the TSF to perform any action before being - identified. - - - - , requires that users identify - themselves before any other action will be allowed by the TSF. - - - the management of the user identities. - - - - - The TSF shall require each user to be successfully identified before - allowing any other TSF-mediated actions on behalf of that user. - - - - - - - - An authenticated user, in order to use the TOE, typically - activates a subject. The user's security - attributes are associated (totally or partially) with this - subject. This family defines requirements to create and - maintain the association of the user's security - attributes to a subject acting on the user's - behalf. - - - - An authenticated user, in order to use the TOE, typically - activates a subject. The user's security - attributes are associated (totally or partially) with this - subject. This family defines requirements to create and - maintain the association of the user's security - attributes to a subject acting on the user's - behalf. - - - - It is intended that a subject is - acting on behalf of the user who caused the subject to come into - being or to be activated to perform a certain task. - Therefore, when a subject is created, that subject is acting on - behalf of the user who initiated the creation. In cases where - anonymity is used, the subject is still acting on behalf of a - user, but the identity of that user is unknown. A special - category of subjects are those subjects that serve multiple - users (e.g. a server process). In such cases the user that - created this subject is assumed to be the ``owner''., requires the specification of any rules - governing the association between user attributes and the - subject attributes into which they are mapped. - an authorised administrator can define default subject security - attributes. - - an authorised administrator can change subject security - attributes. - - Unsuccessful binding of user security attributes to a subject - (e.g. creation of a subject). - - Success and failure of binding of user security attributes to a - subject (e.g. success or failure to create a subject). - - The TSF shall associate the following user security attributes - with subjects acting on the behalf of that user: - - list of user security attributes - - the PP/ST author should specify a list of the user security - attributes that are to be bound to subjects.. - - The TSF shall enforce the following rules on the initial - association of user security attributes with subjects acting on - the behalf of users: - - rules for the initial association of attributes - - the PP/ST author should specify any rules that are to apply - upon initial association of attributes with subjects, or - ``none''.. - - The TSF shall enforce the following rules governing changes to the - user security attributes associated with subjects acting on the - behalf of users: - - rules for the changing of attributes - - the PP/ST author should specify any rules that are to apply - when changes are made to the user security attributes - associated with subjects acting on behalf of users, or - ``none''.. - - - - - - - This class is intended to specify the management of several - aspects of the TSF: security attributes, TSF data and - functions. The different management roles and their - interaction, such as separation of capability, can be - specified. - - This class has several objectives: - - - management of TSF data, which include, for example, - banners; - - - management of security attributes, which include, for - example, the Access Control Lists, and Capability Lists; - - - management of functions of the TSF, which includes, for - example, the selection of functions, and rules or - conditions influencing the behaviour of the TSF; - - - definition of security roles. - - - - - - This class specifies the management of several aspects of the - TSF: security attributes, TSF data and functions in the - TSF. The different management roles and their interaction, - such as separation of capability, can also be specified - - In an environment where the TOE is made up of multiple - physically separated parts, the timing issues with respect to - propagation of security attributes, TSF data, and function - modification become very complex, especially if the - information is required to be replicated across the parts of - the TOE. This should be considered when selecting components - such as , or , where the behaviour might be - impaired. In such situations, use of components from is advisable. - - - - - - This family allows authorised users control over the - management of functions in the TSF. Examples of functions in - the TSF include the audit functions and the multiple - authentication functions. - - - - The TSF management functions enable authorised users to set - up and control the secure operation of the TOE. These - administrative functions typically fall into a number of - different categories: - - - Management functions that relate to access control, - accountability and authentication controls enforced by - the TOE. For example, definition and update of user - security characteristics (e.g. unique identifiers - associated with user names, user accounts, system entry - parameters) or definition and update of auditing system - controls (e.g. selection of audit events, management of - audit trails, audit trail analysis, and audit report - generation), definition and update of per-user policy - attributes (such as user clearance), definition of known - system access control labels, and control and management - of user groups. - - - Management functions that relate to controls over - availability. For example, definition and update of - availability parameters or resource quotas. - - - Management functions that relate to general installation - and configuration. For example, TOE configuration, - manual recovery, installation of TOE security fixes (if - any), repair and reinstallation of hardware. - - - Management functions that relate to routine control and - maintenance of TOE resources. For example, enabling and - disabling peripheral devices, mounting of removable - storage media, backup and recovery. - - - - Note that these functions need to be present in a TOE based - on the families included in the PP or ST. It is the - responsibility of the PP/ST author to ensure that adequate - functions will be provided to manage the TOE in a secure - fashion. - - The TSF might contain functions that can be controlled by an - administrator. For example, the auditing functions could be - switched off, the time synchronisation could be switchable, - and/or the authentication mechanism could be modifiable. - - - - - - - - - - This component allows identified roles to manage the - security functions of the TSF. This might entail obtaining - the current status of a security function, disabling or - enabling the security function, or modifying the behaviour - of the security function. An example of modifying the - behaviour of the security functions is changing of - authentication mechanisms. - - - - allows the authorised users (roles) - to manage the behaviour of functions in the TSF that use - rules or have specified conditions that may be manageable. - - - managing the group of roles that can interact with the - functions in the TSF; - - - All modifications in the behaviour of the functions in the - TSF. - - - The TSF shall restrict the ability to - - - determine the behaviour of - - - disable - - - enable - - - modify the behaviour of - - - - the PP/ST author should select whether the role can - determine the behaviour of, disable, enable, and/or - modify the behaviour of the security functions. - - - the functions - - - list of functions - - - - the PP/ST author should specify the functions that can - be modified by the identified roles. Examples include - auditing and time determination. - - - to - - - the authorised identified roles - - - - the PP/ST author should specify the roles that are - allowed to modify the functions in the TSF. The - possible roles are specified in . - - . - - - - - - - - This family allows authorised users control over the - management of security attributes. This management might - include capabilities for viewing and modifying of security - attributes. - - - - This family defines the requirements on the management of - security attributes. - - Security attributes affect the behaviour of the TSF. Examples of - security attributes are the groups to which a user belongs, the - roles he/she might assume, the priority of a process (subject), - and the rights belonging to a role or a user. These security - attributes might need to be managed by the user, a subject, a - specific authorised user (a user with explicitly given rights - for this management) or inherit values according to a given - policy/set of rules. - - It is noted that the right to assign rights to users is - itself a security attribute and/or potentially subject to - management by . - can be used to ensure that any - accepted combination of security attributes is within a - secure state. The definition of what - ``secure'' means is left to the TOE guidance. - - In some instances subjects, objects or user accounts are - created. If no explicit values for the related security - attributes are given, default values need to be used. can be used to specify that these default - values can be managed. - - - - - - - - - - - - - This component allows users acting in certain roles to - manage identified security attributes. The users are - assigned to a role within the component . - - The default value of a parameter is the value the - parameter takes when it is instantiated without - specifically assigned values. An initial value is provided - during the instantiation (creation) of a parameter, and - overrides the default value. - - - - allows authorised users (roles) to - manage the specified security attributes. - - - managing the group of roles that can interact with the - security attributes; - - management of rules by which security attributes inherit - specified values. - - - All modifications of the values of security attributes. - - - The TSF shall enforce the - - access control SFP(s), information flow control SFP(s) - - the PP/ST author should list the access control SFP(s) or - the information flow control SFP(s) for which the security - attributes are applicable. - to restrict the ability to - - - change_default - - - query - - - modify - - - delete - - - - - other operations - - - - if selected, the PP/ST author should specify which - other operations the role could perform. An - example of such an operation could be - ``create''. - - - - - - the PP/ST author should specify the operations that - can be applied to the identified security - attributes. The PP/ST author can specify that the role - can modify the default value (change_default), query, - modify the security attribute, delete the security - attributes entirely or define their own operation. - - - the security attributes - - - list of security attributes - - - - the PP/ST author should specify the security - attributes that can be operated on by the identified - roles. It is possible for the PP/ST author to specify - that the default value such as default access-rights - can be managed. Examples of these security attributes - are user-clearance, priority of service level, access - control list, default access rights. - - - to - - - the authorised identified roles - - - - the PP/ST author should specify the roles that are - allowed to operate on the security attributes. The - possible roles are specified in . - - . - - - - - - - - - - - - - - - This component contains requirements on the values that - can be assigned to security attributes. The assigned - values should be such that the TOE will remain in a secure - state. - - The definition of what ``secure'' means is - not answered in this component but is left to the - development of the TOE and the resulting information in the - guidance. An example could be that if a user account is - created, it should have a non-trivial password. - - - - ensures that values assigned to - security attributes are valid with respect to the secure - state. - - management of rules by which security attributes inherit - specified values. - - - All offered and rejected values for a security attribute; - - - All offered and accepted secure values for a security - attribute. - - - The TSF shall ensure that only secure values are accepted - for - list of security attributes - - the PP/ST author should specify the list of security - attributes that require only secure values to be provided.. - - - - - - - - - - - This component requires that the TSF provide default - values for relevant object security attributes, which can - be overridden by an initial value. It may still be - possible for a new object to have different security - attributes at creation, if a mechanism exists to specify - the permissions at time of creation. - - - - ensures that the default values of - security attributes are appropriately either permissive or - restrictive in nature. - - - managing the group of roles that can specify initial values; - - - managing the permissive or restrictive setting of default values - for a given access control SFP; - - management of rules by which security attributes inherit specified values. - - - Modifications of the default setting of permissive or - restrictive rules. - - - All modifications of the initial values of security - attributes. - - - The TSF shall enforce the - - - access control SFP, information flow control SFP - - - - the PP/ST author should list the access control SFP or - the information flow control SFP for which the - security attributes are applicable. - - - to provide - - - restrictive - - - permissive - - - other property - - if the PP/ST author selects another property, the PP/ST - author should specify the desired characteristics of the - default values. - - - the PP/ST author should select whether the default property - of the access control attribute will be restrictive, - permissive, or another property. Only one of these options - may be chosen. - - - default values for security attributes that are used to - enforce the SFP. - - - The TSF shall allow the - - - the authorised identified roles - - - - the PP/ST author should specify the roles that are - allowed to modify the values of the security - attributes. The possible roles are specified in . - - - to specify alternative initial values to override the - default values when an object or information is created. - - - This component requires specification of the set of rules - through which the security attribute inherits values and the - conditions to be met for these rules to be applied. allows the rules/policies - to be specified that will dictate the value to be inherited - by a security attribute. - specification of the role permitted to establish or modify - security attributes. - - Modifications of security attributes, possibly with the old - and/or values of security attributes that were modified. - - The TSF shall use the following rules to set the value of security attributes: - - rules for setting the values of security attributes - - the PP/ST author specifies the rules governing the value - that will be inherited by the specified security - attribute, including the conditions that are to be met - for the rules to be applied. For example, if a new file - or directory is created (in a multilevel filesystem), - its label is the label at which the user is logged in at - the time it is created. - - - - - - This family allows authorised users (roles) control over the - management of TSF data. Examples of TSF data include audit - information, clock and other TSF - configuration parameters. - - - - This component imposes requirements on the management of TSF - data. Examples of TSF data are the current time and the - audit trail. So, for example, this family allows the - specification of whom can read, delete or create the audit - trail. - - - - - - - - - This component allows users with a certain role to manage - values of TSF data. The users are assigned to a role - within the component . - - The default value of a parameter is the values the - parameter takes when it is instantiated without - specifically assigned values. An initial value is provided - during the instantiation (creation) of a parameter and - overrides the default value. - - - - allows authorised users to manage - TSF data. - - - managing the group of roles that can interact with the TSF - data. - - - All modifications to the values of TSF data. - - - The TSF shall restrict the ability to - - - change_default - - - query - - - modify - - - delete - - - clear - - - - - other operations - - - - if selected, the PP/ST author should specify which - other operations the role could perform. An - example could be - ``create''. - - - - - - the PP/ST author should specify the operations that - can be applied to the identified TSF data. The PP/ST - author can specify that the role can modify the - default value (change_default), clear, query or modify - the TSF data, or delete the TSF data entirely. If so - desired the PP/ST author could specify any type of - operation. To clarify ``clear TSF data'' means that - the content of the TSF data is removed, but that the - entity that stores the TSF data remains in the - TOE. - - - the - - - list of TSF data - - - - the PP/ST author should specify the TSF data that can - be operated on by the identified roles. It is possible - for the PP/ST author to specify that the default value - can be managed. - - - to - - - the authorised identified roles - - - - the PP/ST author should specify the roles that are - allowed to operate on the TSF data. The possible roles - are specified in . - - . - - - - - - - - - - - This component specifies limits on TSF data, and actions - to be taken if these limits are exceeded. This component, - for example, will allow limits on the size of the audit - trail to be defined, and specification of the actions to - be taken when these limits are exceeded. - - - - specifies the action to be taken if - limits on TSF data are reached or exceeded. - - - managing the group of roles that can interact with the - limits on the TSF data. - - - All modifications to the limits on TSF data; - - - All modifications in the actions to be taken in case of - violation of the limits. - - - The TSF shall restrict the specification of the limits for - - - list of TSF data - - - - the PP/ST author should specify the TSF data that can - have limits, and the value of those limits. An example - of such TSF data is the number of users logged-in. - - - to - - - the authorised identified roles - - - - the PP/ST author should specify the roles that are - allowed to modify the limits on the TSF data and the - actions to be taken. The possible roles are specified - in . - - . - - - The TSF shall take the following actions, if the TSF data - are at, or exceed, the indicated limits: - - - actions to be taken - - - - the PP/ST author should specify the actions to be - taken if the specified limit on the specified TSF data - is exceeded. An example of such TSF action is that the - authorised user is informed and an audit record is - generated. - - . - - - - - - - - - - This component covers requirements on the values that can - be assigned to TSF data. The assigned values should be - such that the TOE will remain in a secure state. - - The definition of what ``secure'' means is not - answered in this component but is left to the development of - the TOE and the - resulting information in the guidance. - - - - ensures that values assigned to TSF - data are valid with respect to the secure state. - - - All rejected values of TSF data. - - - The TSF shall ensure that only secure values are accepted - for - list of TSF data - - the PP/ST author should specify what TSF data require only - secure values to be accepted.. - - - - - - - - This family addresses revocation of security attributes for - a variety of entities within a TOE. - - - - This family addresses revocation of security attributes for - a variety of entities within a TOE. - - - - - - - - - This component specifies requirements on the revocation of - rights. It requires the specification of the revocation - rules. Examples are: - - - Revocation will take place on the next login of the - user; - - - Revocation will take place on the next attempt to open - the file; - - - Revocation will take place within a fixed time. This - might mean that all open connections are re-evaluated - every x minutes. - - - - - - provides for revocation of security - attributes to be enforced at some point in time. - - - managing the group of roles that can invoke revocation of - security attributes; - - - managing the lists of users, subjects, objects and other - resources for which revocation is possible; - - - managing the revocation rules. - - - Unsuccessful revocation of security attributes; - - - All attempts to revoke security attributes. - - - The TSF shall restrict the ability to revoke - - list of security attributes - - the PP/ST author should specify which security attributes - are to be revoked when a change is made to the associated - object/subject/user/other resource. - associated with the - - users - - subjects - - objects - other additional resources - the PP/ST author should, if additional resources is - selected, specify whether the ability to revoke their - security attributes shall be provided by the - TSF. - the PP/ST author should specify whether the ability to - revoke security attributes from users, subjects, objects, - or any additional resources shall be provided by the - TSF. - under the control of the TSF to - - the authorised identified roles - - the PP/ST author should specify the roles that are allowed - to modify the functions in the TSF. The possible roles are - specified in .. - - - The TSF shall enforce the rules - - - specification of revocation rules - - - - the PP/ST author should specify the revocation - rules. Examples of these rules could include: - ``prior to the next operation on the - associated resource'', or ``for - all new subject creations''. - - . - - - - - - - - This family addresses the capability to enforce time limits - for the validity of security attributes. - - - - This family addresses the capability to enforce time limits - for the validity of security attributes. This family can be - applied to specify expiration requirements for access - control attributes, identification and authentication - attributes, certificates (key certificates such as ANSI X509 - for example), audit attributes, etc. - - - - - - - - - - provides the capability for an - authorised user to specify an expiration time on specified - security attributes. - - - managing the list of security attributes for which - expiration is to be supported; - - - the actions to be taken if the expiration time has passed. - - - Specification of the expiration time for an attribute; - - - Action taken due to attribute expiration. - - - The TSF shall restrict the capability to specify an - expiration time for - - - list of security attributes for which expiration is to - be supported - - - - the PP/ST author should provide the list of security - attributes for which expiration is to be supported. An - example of such an attribute might be a - user's security clearance. - - - to - - - the authorised identified roles - - - - the PP/ST author should specify the roles that are - allowed to modify the security attributes in the - TSF. The possible roles are specified in . - - . - - - For each of these security attributes, the TSF shall be able - to - - - list of actions to be taken for each security attribute - - - - the PP/ST author should provide a list of actions to - be taken for each security attribute when it - expires. An example might be that the - user's security clearance, when it expires, - is set to the lowest allowable clearance on the - TOE. If immediate revocation is desired by the PP/ST, - the action ``immediate - revocation'' should be specified. - - - after the expiration time for the indicated security - attribute has passed. - - - - This family allows the specification of the management - functions to be provided by the TOE. Management functions - provide TSFI that allow administrators to define the - parameters that control the operation of security-related - aspects of the TOE, such as data protection attributes, TOE - protection attributes, audit attributes, and identification - and authentication attributes. Management functions also - include those functions performed by an operator to ensure - continued operation of the TOE, such as backup and - recovery. This family works in conjunction with the other - components in the class: the component in - this family calls out the management functions, and other - families in restrict the ability to use - these management functions. - This family allows the specification of the management - functions to be provided by the TOE. Each security - management function that is listed in fulfilling the - assignment is either security attribute management, TSF data - management, or security function management. - This component specifies the management functions to be - provided. - PP/ST authors should consult the ``Management'' sections - for components included in their PP/ST to provide a basis - for the management functions to be listed via this - component. requires that the TSF provide - specific management functions. - Use of the management functions. - - The TSF shall be capable of performing the following - management functions: - - list of management functions to be provided by - the TSF - - the PP/ST author should specify the management - functions to be provided by the TSF, either security - attribute management, TSF data management, or security - function management.. - - - - - - This family is intended to control the assignment of - different roles to users. The capabilities of these roles - with respect to security management are described in the - other families in this class. - - - - This family reduces the likelihood of damage resulting from - users abusing their authority by taking actions outside - their assigned functional responsibilities. It also - addresses the threat that inadequate mechanisms have been - provided to securely administer the TSF. - - This family requires that information be maintained to - identify whether a user is authorised to use a particular - security-relevant administrative function. - - Some management actions can be performed by users, others - only by designated people within the organisation. This - family allows the definition of different roles, such as - owner, auditor, administrator, daily-management. - - The roles as used in this family are security related - roles. Each role can encompass an extensive set of - capabilities (e.g. root in UNIX), or can be a single right - (e.g. right to read a single object such as the - helpfile). This family defines the roles. The capabilities - of the role are defined in , and . - - Some type of roles might be mutually exclusive. For example - the daily-management might be able to define and activate - users, but might not be able to remove users (which is - reserved for the administrator (role)). This class will - allow policies such as two-person control to be specified. - - - - - - - - - This component specifies the different roles that the TSF - should recognise. Often the system distinguishes between - the owner of an entity, an administrator and other users. - - - - specifies the roles with respect to - security that the TSF recognises. - - - managing the group of users that are part of a role. - - - modifications to the group of users that are part of a role; - - - every use of the rights of a role. - - - The TSF shall maintain the roles - - - the authorised identified roles - - - - the PP/ST author should specify the roles that are - recognised by the system. These are the roles that - users could occupy with respect to security. Examples - are: owner, auditor and administrator. - - . - - - The TSF shall be able to associate users with roles. - - - - - - - - - - - This component specifies the different roles that the TSF - should recognise, and conditions on how those roles could - be managed. Often the system distinguishes between the - owner of an entity, an administrator and other users. - - The conditions on those roles specify the - interrelationship between the different roles, as well as - restrictions on when the role can be assumed by a user. - - - - specifies that in addition to the - specification of the roles, there are rules that control - the relationship between the roles. - - - managing the group of users that are part of a role; - - - managing the conditions that the roles must satisfy. - - - modifications to the group of users that are part of a role; - - - unsuccessful attempts to use a role due to the given - conditions on the roles; - - - every use of the rights of a role. - - - The TSF shall maintain the roles: - - - authorised identified roles - - - - the PP/ST author should specify the roles that are - recognised by the system. These are the roles that - users could occupy with respect to security. Examples - are: owner, auditor, administrator. - - . - - - The TSF shall be able to associate users with roles. - - - The TSF shall ensure that the conditions - - - conditions for the different roles - - - - the PP/ST author should specify the conditions that - govern role assignment. Examples of these conditions - are: ``an account cannot have both the - auditor and administrator role'' or - ``a user with the assistant role must also - have the owner role''. - - - are satisfied. - - - - - - - - - - This component specifies that an explicit request must be - given to assume the specific role. - - - - , requires that an explicit request - is given to the TSF to assume a role. - - - explicit request to assume a role. - - - The TSF shall require an explicit request to assume the - following roles: - - - the roles - - - - the PP/ST author should specify the roles that require - an explicit request to be assumed. Examples are: - auditor and administrator. - - . - - - - - - - - This class contains privacy requirements. These requirements - provide a user protection against discovery and misuse of - identity by other users. - - - - This class describes the requirements that could be levied to - satisfy the users' privacy needs, while still allowing - the system flexibility as far as possible to maintain - sufficient control over the operation of the system. - - In the components of this class there is flexibility as to - whether or not authorised users are covered by the required - security functionality. For example, a PP/ST author might - consider it appropriate not to require protection of the privacy - of users against a suitably authorised user. - - This class, together with other classes (such as those - concerned with audit, access control, trusted path, and - non-repudiation) provides the flexibility to specify the - desired privacy behaviour. On the other hand, the requirements - in this class might impose limitations on the use of the - components of other classes, such as or . For example, if - authorised users are not allowed to see the user identity - (e.g. Anonymity or Pseudonymity), it will obviously not be - possible to hold individual users accountable for any security - relevant actions they perform that are covered by the privacy - requirements. However, it may still be possible to include - audit requirements in a PP/ST, where the fact that a - particular security relevant event has occurred is more - important than knowing who was responsible for it. - - Additional information is provided in the application notes - for class , where it is explained that the - definition of ``identity'' in the context of - auditing can also be an alias or other information that could - identify a user. - - This class describes four families: Anonymity, Pseudonymity, - Unlinkability and Unobservability. Anonymity, Pseudonymity and - Unlinkability have a complex interrelationship. When choosing - a family, the choice should depend on the threats - identified. For some types of privacy threats, pseudonymity - will be more appropriate than anonymity (e.g. if there is a - requirement for auditing). In addition, some types of privacy - threats are best countered by a combination of components from - several families. - - All families assume that a user does not explicitly perform an - action that discloses the user's own identity. For - example, the TSF is not expected to screen the user name in - electronic messages or databases. - - All families in this class have components that can be scoped - through operations. These operations allow the PP/ST author to - state the cooperating users/subjects to which the TSF must be - resistant. An example of an instantiation of anonymity could - be: `` The TSF shall ensure that the users and/or - subjects are unable to determine the user identity bound to - the teleconsulting application''. - - It is noted that the TSF should not only provide this - protection against individual users, but also against users - cooperating to obtain the information. - - - - - - This family ensures that a user may use a resource or - service without disclosing the user's identity. The - requirements for Anonymity provide protection of the user - identity. Anonymity is not intended to protect the subject - identity. - - - - Anonymity ensures that a subject may use a resource or - service without disclosing its user identity. - - The intention of this family is to specify that a user or - subject might take action without releasing its user - identity to others such as users, subjects, or objects. The - family provides the PP/ST author with a means to identify - the set of users that cannot see the identity of someone - performing certain actions. - - Therefore if a subject, using anonymity, performs an action, - another subject will not be able to determine either the - identity or even a reference to the identity of the user - employing the subject. The focus of the anonymity is on the - protection of the users identity, not on the protection of - the subject identity; hence, the identity of the subject is - not protected from disclosure. - - Although the identity of the subject is not released to - other subjects or users, the TSF is not explicitly - prohibited from obtaining the users identity. In case the - TSF is not allowed to know the identity of the user, could be invoked. In that case - the TSF should not request the user information. - - The interpretation of ``determine'' should be - taken in the broadest sense of the word. - - The component levelling distinguishes between the users and - an authorised user. An authorised user is often excluded - from the component, and therefore allowed to retrieve a - user's identity. However, there is no specific - requirement that an authorised user must be able to have the - capability to determine the user's identity. For - ultimate privacy the components would be used to say that no - user or authorised user can see the identity of anyone - performing any action. - - Although some systems will provide anonymity for all - services that are provided, other systems provide anonymity - for certain subjects/operations. To provide this - flexibility, an operation is included where the scope of the - requirement is defined. If the PP/ST author wants to address - all subjects/operations, the words ``all subjects and - all operations'' could be provided. - - Possible applications include the ability to make enquiries - of a confidential nature to public databases, respond to - electronic polls, or make anonymous payments or donations. - - Examples of potential hostile users or subjects are - providers, system operators, communication partners and - users, who smuggle malicious parts (e.g. Trojan Horses) into - systems. All of these users can investigate usage patterns - (e.g. which users used which services) and misuse this - information. - - - - - - This component ensures that the identity of a user is - protected from disclosure. There may be instances, - however, that a given authorised user can determine who - performed certain actions. This component gives the - flexibility to capture either a limited or total privacy - policy. - - - - , requires that other users or - subjects are unable to determine the identity of a user - bound to a subject or operation. - - - The invocation of the anonymity mechanism. - - - The TSF shall ensure that - - - set of users and/or subjects - - - - the PP/ST author should specify the set of users - and/or subjects against which the TSF must provide - protection. For example, even if the PP/ST author - specifies a single user or subject role, the TSF must - not only provide protection against each individual - user or subject, but must protect with respect to - cooperating users and/or subjects. A set of users, for - example, could be a group of users which can operate - under the same role or can all use the same - process(es). - - - are unable to determine the real user name bound to - - - list of subjects and/or operations and/or objects - - - - the PP/ST author should identify the list of subjects - and/or operations and/or objects where the real user - name of the subject should be protected, for example, - ``the voting application''. - - . - - - - - - - - This component is used to ensure that the TSF is not - allowed to know the identity of the user. - - - - enhances the - requirements of by - ensuring that the TSF does not ask for the user - identity. - - - - The TSF shall ensure that - - - set of users and/or subjects - - - - the PP/ST author should specify the set of users - and/or subjects against which the TSF must provide - protection. For example, even if the PP/ST author - specifies a single user or subject role, the TSF must - not only provide protection against each individual - user or subject, but must protect with respect to - cooperating users and/or subjects. A set of users, for - example, could be a group of users which can operate - under the same role or can all use the same - process(es). - - - are unable to determine the real user name bound to - - - list of subjects and/or operations and/or objects - - - - the PP/ST author should identify the list of subjects - and/or operations and/or objects where the real user - name of the subject should be protected, for example, - ``the voting application''. - - . - - - The TSF shall provide - - - list of services - - - - the PP/ST author should identify the list of services - which are subject to the anonymity requirement, for - example, ``the accessing of job - descriptions''. - - - to - - - list of subjects - - - - the PP/ST author should identify the list of subjects - from which the real user name of the subject should be - protected when the specified services are provided. - - - without soliciting any reference to the real user name. - - - - - - - - This family ensures that a user may use a resource or - service without disclosing its user identity, but can still - be accountable for that use. - - - - Pseudonymity ensures that a user may use a resource or - service without disclosing its identity, but can still be - accountable for that use. The user can be accountable by - directly being related to a reference (alias) held by the - TSF, or by providing an alias that will be used for - processing purposes, such as an account number. - - In several respects, pseudonymity resembles anonymity. Both - pseudonymity and anonymity protect the identity of the user, - but in pseudonymity a reference to the user's - identity is maintained for accountability or other purposes. - - The component does not - specify the requirements on the reference to the user's - identity. For the purpose of specifying requirements on this - reference two sets of requirements are presented: and . - - A way to use the reference is by being able to obtain the - original user identity. For example, in a digital cash - environment it would be advantageous to be able to trace the - user's identity when a check has been issued multiple times - (i.e. fraud). In general, the user's identity needs to be - retrieved under specific conditions. The PP/ST author might - want to incorporate to - describe those services. - - Another usage of the reference is as an alias for a - user. For example, a user who does not wish to be - identified, can provide an account to which the resource - utilisation should be charged. In such cases, the reference - to the user identity is an alias for the user, where other - users or subjects can use the alias for performing their - functions without ever obtaining the user's - identity (for example, statistical operations on use of the - system). In this case, the PP/ST author might wish to - incorporate to specify the rules to - which the reference must conform. - - Using these constructs above, digital money can be created - using specifying that the user - identity will be protected and, if so specified in the - condition, that there be a requirement to trace the user - identity if the digital money is spent twice. When the user - is honest, the user identity is protected; if the user tries - to cheat, the user identity can be traced. - - A different kind of system could be a digital credit card, - where the user will provide a pseudonym that indicates an - account from which the cash can be subtracted. In such - cases, for example, could be - used. This component would specify that the user identity - will be protected and, furthermore, that the same user will - only get assigned values for which he/she has provided money - (if so specified in the conditions). - - It should be realised that the more stringent components - potentially cannot be combined with other requirements, such - as identification and authentication or audit. The - interpretation of ``determine the identity'' - should be taken in the broadest sense of the word. The - information is not provided by the TSF during the operation, - nor can the entity determine the subject or the owner of the - subject that invoked the operation, nor will the TSF record - information, available to the users or subjects, which might - release the user identity in the future. - - The intent is that the TSF not reveal any information that - would compromise the identity of the user, e.g. the identity - of subjects acting on the user's behalf. The - information that is considered to be sensitive depends on - the effort an attacker is capable of spending. - - Possible applications include the ability to charge a caller - for premium rate telephone services without disclosing his - or her identity, or to be charged for the anonymous use of - an electronic payment system. - - Examples of potential hostile users are providers, system - operators, communication partners and users, who smuggle - malicious parts (e.g. Trojan Horses) into systems. All of - these attackers can investigate which users used which - services and misuse this information. Additionally to - Anonymity services, Pseudonymity Services contains methods - for authorisation without identification, especially for - anonymous payment (``Digital Cash''). This - helps providers to obtain their payment in a secure way - while maintaining customer anonymity. - - - - - - This component provides the user protection against - disclosure of identity to other users. The user will - remain accountable for its actions. - - - - requires that a set of users and/or - subjects are unable to determine the identity of a user - bound to a subject or operation, but that this user is - still accountable for its actions. - - - The subject/user that requested resolution of the user - identity should be audited. - - - The TSF shall ensure that - - - set of users and/or subjects - - - - the PP/ST author should specify the set of users - and/or subjects against which the TSF must provide - protection. For example, even if the PP/ST author - specifies a single user or subject role, the TSF must - not only provide protection against each individual - user or subject, but must protect with respect to - cooperating users and/or subjects. A set of users, for - example, could be a group of users which can operate - under the same role or can all use the same - process(es). - - - are unable to determine the real user name bound to - - - list of subjects and/or operations and/or objects - - - - the PP/ST author should identify the list of subjects - and/or operations and/or objects where the real user - name of the subject should be protected, for example, - ``the accessing of job offers''. Note - that ``objects'' includes any other - attributes that might enable another user or subject - to derive the actual identity of the user. - - . - - - The TSF shall be able to provide - - - number of aliases - - - - the PP/ST author should identify the (one or more) - number of aliases the TSF is able to provide. - - - aliases of the real user name to - - - list of subjects - - - - the PP/ST author should identify the list of subjects - to whom the TSF is able to provide an alias. - - . - - - The TSF shall - - - determine an alias for a user - - - accept the alias from the user - - - - the PP/ST author should specify whether the user alias is - generated by the TSF, or supplied by the user. Only one of - these options may be chosen. - - - and verify that it conforms to the - - - alias metric - - - - the PP/ST author should identify the metric to which - the TSF-generated or user-generated alias should - conform. - - . - - - - - - - - - - - In this component, the TSF shall ensure that under - specified conditions the user identity related to a - provided reference can be determined. - - In the TSF shall provide an alias - instead of the user identity. When the specified - conditions are satisfied, the user identity to which the - alias belong can be determined. An example of such a - condition in an electronic cash environment is: `` - The TSF shall provide the notary a capability to determine - the user identity based on the provided alias only under - the conditions that a check has been issued - twice.''. - - - - , requires the TSF to provide a - capability to determine the original user identity based - on a provided alias. - - - - The TSF shall ensure that - - - set of users and/or subjects - - - - the PP/ST author should specify the set of users - and/or subjects against which the TSF must provide - protection. For example, even if the PP/ST author - specifies a single user or subject role, the TSF must - not only provide protection against each individual - user or subject, but must protect with respect to - cooperating users and/or subjects. A set of users, for - example, could be a group of users which can operate - under the same role or can all use the same - process(es). - - - are unable to determine the real user name bound to - - - list of subjects and/or operations and/or objects - - - - the PP/ST author should identify the list of subjects - and/or operations and/or objects where the real user - name of the subject should be protected, for example, - ``the accessing of job offers''. Note - that ``objects'' includes any other - attributes that might enable another user or subject - to derive the actual identity of the user. - - . - - - The TSF shall be able to provide - - - number of aliases - - - - the PP/ST author should identify the (one or more) - number of aliases the TSF, is able to provide. - - - aliases of the real user name to - - - list of subjects - - - - the PP/ST author should identify the list of subjects - to whom the TSF is able to provide an alias. - - . - - - The TSF shall - - - determine an alias for a user - - - accept the alias from the user - - - - the PP/ST author should specify whether the user alias is - generated by the TSF or supplied by the user. Only one of - these options may be chosen. - - - and verify that it conforms to the - - - alias metric - - - - the PP/ST author should identify the metric to which - the TSF-generated or user-generated alias should - conform. - - . - - - The TSF shall provide - - - an authorised user - - - - - list of trusted subjects - - - - the PP/ST author should identify the list of trusted - subjects that can obtain the real user name under a - specified condition, for example, a notary or - special authorised user. - - - - - - the PP/ST author should select whether the authorised - user and/or trusted subjects can determine the real - user name. - - - a capability to determine the user identity based on the - provided alias only under the following - - - list of conditions - - - - the PP/ST author should identify the list of - conditions under which the trusted subjects and - authorised user can determine the real user name based - on the provided reference. These conditions can be - conditions such as time of day, or they can be - administrative such as on a court order. - - . - - - - - - - - In this component, the TSF shall ensure that the provided - reference meets certain construction rules, and thereby - can be used in a secure way by potentially insecure - subjects. - - If a user wants to use disk resources without disclosing - its identity, pseudonymity can be used. However, every - time the user accesses the system, the same alias must be - used. Such conditions can be specified in this component. - - - - , requires the TSF to - follow certain construction rules for the alias to the user - identity. - - - - The TSF shall ensure that - - - set of users and/or subjects - - - - the PP/ST author should specify the set of users - and/or subjects against which the TSF must provide - protection. For example, even if the PP/ST author - specifies a single user or subject role, the TSF must - not only provide protection against each individual - user or subject, but must protect with respect to - cooperating users and/or subjects. A set of users, for - example, could be a group of users which can operate - under the same role or can all use the same - process(es). - - - are unable to determine the real user name bound to - - - list of subjects and/or operations and/or objects - - - - the PP/ST author should identify the list of subjects - and/or operations and/or objects where the real user - name of the subject should be protected, for example, - ``the accessing of job offers''. Note - that ``objects'' includes any other - attributes which might enable another user or subject - to derive the actual identity of the user. - - . - - - The TSF shall be able to provide - - - number of aliases - - - - the PP/ST author should identify the (one or more) - number of aliases the TSF is able to provide. - - - aliases of the real user name to - - - list of subjects - - - - the PP/ST author should identify the list of subjects - to whom the TSF is able to provide an alias. - - . - - - The TSF shall - - - determine an alias for a user - - - accept the alias from the user - - - - the PP/ST author should specify whether the user alias is - generated by the TSF, or supplied by the user. Only one of - these options may be chosen. - - - and verify that it conforms to the - - - alias metric - - - - the PP/ST author should identify the metric to which - the TSF-generated or user-generated alias should - conform. - - . - - - The TSF shall provide an alias to the real user name which - shall be identical to an alias provided previously under the - following - - - list of conditions - - - - the PP/ST author should identify the list of - conditions that indicate when the used reference for - the real user name shall be identical and when it - shall be different, for example, ``when the - user logs on to the same host'' it will use a - unique alias. - - - otherwise the alias provided shall be unrelated to - previously provided aliases. - - - - - - - This family ensures that a user may make multiple uses of - resources or services without others being able to link - these uses together. - - - - Unlinkability ensures that a user may make multiple uses of - resources or services without others being able to link - these uses together. Unlinkability differs from pseudonymity - that, although in pseudonymity the user is also not known, - relations between different actions can be provided. - - The requirements for unlinkability are intended to protect - the user identity against the use of profiling of the - operations. For example, when a telephone smart card is - employed with a unique number, the telephone company can - determine the behaviour of the user of this telephone - card. When a telephone profile of the users is known, the - card can be linked to a specific user. Hiding the - relationship between different invocations of a service or - access of a resource will prevent this kind of information - gathering. - - As a result, a requirement for unlinkability could imply - that the subject and user identity of an operation must be - protected. Otherwise this information might be used to link - operations together. - - Unlinkability requires that different operations cannot be - related. This relationship can take several forms. For - example, the user associated with the operation, or the - terminal which initiated the action, or the time the action - was executed. The PP/ST author can specify what kind of - relationships are present that must be countered. - - Possible applications include the ability to make multiple - use of a pseudonym without creating a usage pattern that - might disclose the user's identity. - - Examples for potential hostile subjects and users are - providers, system operators, communication partners and - users, who smuggle malicious parts, (e.g. Trojan Horses) - into systems, they do not operate but want to get - information about. All of these attackers can investigate - (e.g. which users used which services) and misuse this - information. Unlinkability protects users from linkages, - which could be drawn between several actions of a - customer. An example is a series of phone calls made by an - anonymous customer to different partners, where the - combination of the partner's identities might disclose the - identity of the customer. - - - - - - This component ensures that users cannot link different - operations in the system and thereby obtain information. - - - - , requires that users and/or subjects - are unable to determine whether the same user caused - certain specific operations. - - - the management of the unlinkability function. - - - The invocation of the unlinkability mechanism. - - - The TSF shall ensure that - - - set of users and/or subjects - - - - the PP/ST author should specify the set of users - and/or subjects against which the TSF must provide - protection. For example, even if the PP/ST author - specifies a single user or subject role, the TSF must - not only provide protection against each individual - user or subject, but must protect with respect to - cooperating users and/or subjects. A set of users, for - example, could be a group of users which can operate - under the same role or can all use the same - process(es). - - - are unable to determine whether - - - list of operations - - - - the PP/ST author should identify the list of - operations which should be subjected to the - unlinkability requirement, for example, - ``sending email''. - - - - - were caused by the same user - - - are related as follows - - - list of relations - - - - the PP/ST author should identify the list of - relations which should be protected against, for - example, ``originate from the same - terminal''. - - - - - - the PP/ST author should select the relationships that - should be obscured. The selection allows either the - user identity or an assignment of relations to be - specified. - - . - - - - - - - - This family ensures that a user may use a resource or - service without others, especially third parties, being able - to observe that the resource or service is being used. - - - - Unobservability ensures that a user may use a resource or - service without others, especially third parties, being able - to observe that the resource or service is being used. - - Unobservability approaches the user identity from a - different direction than the previous families Anonymity, - Pseudonymity and Unlinkability. In this case, the intent is - to hide the use of a resource or service, rather than to - hide the user's identity. - - A number of techniques can be applied to implement - unobservability. Examples of techniques to provide - unobservability are: - - - Allocation of information impacting unobservability: - Unobservability relevant information (e.g. information - that describes that an operation occurred) can be - allocated in several locations within the TOE. The - information might be allocated to a single randomly - chosen part of the TOE such that an attacker does not - know which part of the TOE should be attacked. An - alternative system might distribute the information such - that no single part of the TOE has sufficient - information that, if circumvented, the privacy of the - user would be compromised. This technique is explicitly - addressed in . - - - Broadcast: When information is broadcast (e.g. ethernet, - radio), users cannot determine who actually received and - used that information. This technique is especially - useful when information should reach receivers which - have to fear a stigma for being interested in that - information (e.g. sensitive medical information). - - - Cryptographic protection and message padding: People - observing a message stream might obtain information from - the fact that a message is transferred and from - attributes on that message. By traffic padding, message - padding and encrypting the message stream, the - transmission of a message and its attributes can be - protected. - - - - Sometimes, users should not see the use of a resource, but an - authorised user must be allowed to see the use of the resource - in order to perform his duties. In such cases, the could be used, which provides the - capability for one or more authorised users to see the - usage. - - This family makes use of the concept ``parts of the - TOE''. This is considered any part of the TOE that is either - physically or logically separated from other parts of the - TOE. - - Unobservability of communications may be an important factor - in many areas, such as the enforcement of constitutional - rights, organisational policies, or in defence related - applications. - - - - - - This component requires that the use of a function or - resource cannot be observed by unauthorised users. - - - - , requires that users and/or - subjects cannot determine whether an operation is being - performed. - - - the management of the behaviour of the unobservability - function. - - - The invocation of the unobservability mechanism. - - - The TSF shall ensure that - - - list of users and/or subjects - - - - the PP/ST author should specify the list of users and/or - subjects against which the TSF must provide - protection. For example, even if the PP/ST author - specifies a single user or subject role, the TSF must - not only provide protection against each individual user - or subject, but must protect with respect to cooperating - users and/or subjects. A set of users, for example, - could be a group of users which can operate under the - same role or can all use the same process(es). - - - are unable to observe the operation - - - list of operations - - - - the PP/ST author should identify the list of - operations that are subjected to the unobservability - requirement. Other users/subjects will then not be - able to observe the operations on a covered object in - the specified list (e.g. reading and writing to the - object). - - - on - - - list of objects - - - - the PP/ST author should identify the list of objects - which are covered by the unobservability - requirement. An example could be a specific mail - server or ftp site. - - - by - - - list of protected users and/or subjects - - - - the PP/ST author should specify the set of protected - users and/or subjects whose unobservability - information will be protected. An example could be: - ``users accessing the system through the - internet''. - - . - - - - - - - - - This component requires that the use of a function or - resource cannot be observed by specified users or - subjects. Furthermore this component specifies that - information related to the privacy of the user is - distributed within the TOE such that attackers might not - know which part of the TOE to target, or they need to - attack multiple parts of the TOE. - - An example of the use of this component is the use of a - randomly allocated node to provide a function. In such a - case the component might require that the privacy related - information shall only be available to one identified part - of the TOE, and will not be communicated outside this part - of the TOE. - - A more complex example can be found in some - ``voting algorithms''. Several parts of the - TOE will be involved in the service, but no individual - part of the TOE will be able to violate the policy. So a - person may cast a vote (or not) without the TOE being able - to determine whether a vote has been cast and what the - vote happened to be (unless the vote was unanimous). - - - - - , requires that the TSF - provide specific mechanisms to avoid the concentration of - privacy related information within the TOE. Such - concentrations might impact unobservability if a security - compromise occurs. - - - - - - The TSF shall ensure that - - - list of users and/or subjects - - - - the PP/ST author should specify the list of users - and/or subjects against which the TSF must provide - protection. For example, even if the PP/ST author - specifies a single user or subject role, the TSF must - not only provide protection against each individual - user or subject, but must protect with respect to - cooperating users and/or subjects. A set of users, for - example, could be a group of users which can operate - under the same role or can all use the same - process(es). - - - are unable to observe the operation - - - list of operations - - - - the PP/ST author should identify the list of - operations that are subjected to the unobservability - requirement. Other users/subjects will then not be - able to observe the operations on a covered object in - the specified list (e.g. reading and writing to the - object). - - - on - - - list of objects - - - - the PP/ST author should identify the list of objects - which are covered by the unobservability - requirement. An example could be a specific mail - server or ftp site. - - - by - - - list of protected users and/or subjects - - - - the PP/ST author should specify the set of protected - users and/or subjects whose unobservability - information will be protected. An example could be: - ``users accessing the system through the - internet''. - - . - - - The TSF shall allocate the - - - unobservability related information - - - - the PP/ST author should identify which privacy related - information should be distributed in a controlled - manner. Examples of this information could be: IP - address of subject, IP address of object, time, used - encryption keys. - - - among different parts of the TOE such that the following - conditions hold during the lifetime of the information: - - - list of conditions - - - - the PP/ST author should specify the conditions to - which the dissemination of the information should - adhere. These conditions should be maintained - throughout the lifetime of the privacy related - information of each instance. Examples of these - conditions could be: ``the information shall - only be present at a single separated part of the TOE - and shall not be communicated outside this part of the - TOE.'', ``the information shall only - reside in a single separated part of the TOE, but - shall be moved to another part of the TOE - periodically'', ``the information shall - be distributed between the different parts of the TOE - such that compromise of any 5 separated parts of the - TOE will not compromise the security policy''. - - . - - - - - - - - - - This component is used to require that the TSF does not - try to obtain information that might compromise - unobservability when provided specific services. Therefore - the TSF will not solicit (i.e. try to obtain from other - entities) any information that might be used to compromise - unobservability. - - - - , requires that the TSF - does not try to obtain privacy related information that - might be used to compromise unobservability. - - - The TSF shall provide - - - list of services - - - - the PP/ST author should identify the list of services - which are subject to the unobservability requirement, - for example, ``the accessing of job - descriptions''. - - - to - - - list of subjects - - - - the PP/ST author should identify the list of subjects - from which privacy related information should be - protected when the specified services are provided. - - - without soliciting any reference to - - - privacy related information - - - - the PP/ST author should specify the privacy related - information that will be protected from the specified - subjects. Examples include the identity of the subject - that used a service and the quantity of a service that - has been used such as memory resource - utilisation. - - . - - - - - - - This component is used to require that there will be one - or more authorised users with the rights to view the - resource utilisation. Without this component, this review - is allowed, but not mandated. - - - - , requires the TSF to - provide one or more authorised users with a capability to - observe the usage of resources and/or services. - - - the list of authorised users that are capable of determining - the occurrence of operations. - - - The observation of the use of a resource or service by a - user or subject. - - - The TSF shall provide - - - set of authorised users - - - - the PP/ST author should specify the set of authorised - users for which the TSF must provide the capability to - observe the resource utilisation. A set of authorised - users, for example, could be a group of authorised users - which can operate under the same role or can all use the - same process(es). - - - with the capability to observe the usage of - - - list of resources and/or services - - - - the PP/ST author should specify the set of resources - and/or services that the authorised user must be able - to observe. - - . - - - - - - - - This class contains families of functional requirements that - relate to the integrity and management of the mechanisms that - constitute the TSF and to the integrity of TSF data. In some - sense, families in this class may appear to duplicate - components in the class; they may - even be implemented using the same mechanisms. However, focuses on user data protection, while - focuses on TSF data - protection. In fact, components from the class are necessary to provide requirements that - the SFPs in the TOE cannot be tampered with or - bypassed. - - From the point of view of this class, regarding to the - TSF there are three significant elements: - - The TSF's implementation, which executes and implements the - mechanisms that enforce the SFRs. - - The TSF's data, which are the administrative databases that guide the - enforcement of the SFRs. - - The external entities that the TSF may interact with in order to - enforce the SFRs. - - - - - This class contains families of functional requirements that - relate to the integrity and management of the mechanisms that - constitute the TSF and to the - integrity of TSF data. In some sense, families in this class may - appear to duplicate components in the - class; they may even be implemented using the - same mechanisms. However, focuses on user - data protection, while focuses on TSF data - protection. In fact, components from the - class are necessary to provide requirements that the SFPs in - the TOE cannot be tampered with or bypassed. - - From the point of view of this class, regarding to the - TSF there are three significant elements: - - The TSF's implementation, which executes and implements the - mechanisms that enforce the SFRs. - - The TSF's data, which are the administrative databases that guide the - enforcement of the SFRs. - - The external entities that the TSF may interact with in order to - enforce the SFRs. - - - All of the families in the class can be - related to these areas, and fall into the following groupings: - , which provides an authorised user - with the ability to detect external attacks on the parts - of the TOE that comprise the TSF. - and , - which provide an authorised user with the ability to verify the correct - operation of the external entities interacting with the TSF to enforce - the SFRs, and the integrity of the TSF data and TSF itself. - , , and , which address the behaviour of the TSF - when failure occurs and immediately after. - , , , - which address the protection and availability of TSF data between the TSF and another trusted IT product. - , which addresses protection of TSF - data when it is transmitted between physically-separated - parts of the TOE. - , which addresses the replay of - various types of information and/or operations. - , which addresses the synchronisation - of states, based upon TSF data, between different parts of - a distributed TSF. - , which addresses reliable timing. - , which addresses the consistency of - TSF data shared between the TSF and another trusted IT product. - - - - - - - - - The requirements of this family ensure that the TOE will always enforce - its SFRs in the event of identified categories of - failures in the TSF. - - - - The requirements of this family ensure that the TOE will - always enforce its SFRs in the event of certain - types of failures in the TSF. - - - - - - The term ``secure state'' refers to a state in which the - TSF data are consistent and the TSF continues correct - enforcement of the SFRs. - - Although it is desirable to audit situations in which - failure with preservation of secure state occurs, it is - not possible in all situations. The PP/ST author should - specify those situations in which audit is desired and - feasible. - - Failures in the TSF may include - ``hard'' failures, which indicate an - equipment malfunction and which may require maintenance, - service or repair of the TSF. Failures in the TSF may also - include recoverable ``soft'' failures, - which may only require initialisation or resetting of the - TSF. - - - - This family consists of only one component, , which requires that the TSF preserve a - secure state in the face of the identified failures. - - - Failure of the TSF. - - - The TSF shall preserve a secure state when the following - types of failures occur: - - - list of types of failures in the TSF - - - - the PP/ST author should list the types of failures in - the TSF for which the TSF should ``fail - secure,'' that is, should preserve a secure - state and continue to correctly enforce the SFRs. - - . - - - - - - - - This family defines the rules for the prevention of loss of - availability of TSF data moving between the TSF and another - trusted IT product. This data could, for example, be TSF - critical data such as passwords, keys, audit data, or TSF - executable code. - - - - This family defines the rules for the prevention of loss of - availability of TSF data moving between the TSF and another - trusted IT product. This data could be TSF critical data - such as passwords, keys, audit data, or TSF executable code. - - This family is used in a distributed context where the TSF - is providing TSF data to another trusted IT product. The - TSF can only take the measures at its site and cannot be - held responsible for the TSF at the other trusted IT - product. - - If there are different availability metrics for different - types of TSF data, then this component should be iterated - for each unique pairing of metrics and types of TSF data. - - - - - - This family consists of only one component, . - This component requires that the TSF ensure, to an identified degree of probability, the - availability of TSF data provided to another trusted IT product. - - - management of the list of types of TSF data that must be - available to another trusted IT product. - - - the absence of TSF data when required by a TOE. - - - The TSF shall ensure the availability of - - list of types of TSF data - - the PP/ST author should specify the types of TSF data - that are subject to the availability metric. - provided to another trusted IT product within - - a defined availability metric - - the PP/ST should specify the availability metric for - the applicable TSF data. - given the following conditions - - conditions to ensure availability - - the PP/ST author should specify the conditions under - which availability must be ensured. For example: - there must be a connection between the TOE and - another trusted IT product.. - - - - - - - - This family defines the rules for the protection from - unauthorised disclosure of TSF data during transmission - between the TSF and another trusted IT product. This data - could, for example, be TSF critical data such as passwords, - keys, audit data, or TSF executable code. - - - - This family defines the rules for the protection from - unauthorised disclosure of TSF data moving between the TSF - and another trusted IT product. Examples of this data are - TSF critical data such as passwords, keys, audit data, or - TSF executable code. - - This family is used in a distributed context where - the TSF is providing TSF data to another trusted IT - product. The TSF can only take the measures at its site and - cannot be held responsible for the behaviour of the other - trusted IT product. - - - - - - Confidentiality of TSF Data during transmission is - necessary to protect such information from - disclosure. Some possible implementations that could - provide confidentiality include the use of cryptographic - algorithms as well as spread spectrum techniques. - - - - This family consists of only one component, , - which requires that the TSF ensure that data transmitted between the TSF and another trusted IT - product is protected from disclosure while in transit. - - - The TSF shall protect all TSF data transmitted from the TSF - to another trusted IT product from unauthorised disclosure - during transmission. - - - - - - - - This family defines the rules for the protection, from - unauthorised modification, of TSF data during transmission - between the TSF and another trusted IT product. This data - could, for example, be TSF critical data such as passwords, - keys, audit data, or TSF executable code. - - - - This family defines the rules for the protection, from - unauthorised modification, of TSF data during transmission - between the TSF and another trusted IT product. Examples of - this data are TSF critical data such as passwords, keys, - audit data, or TSF executable code. - - This family is used in a distributed context where - the TSF is exchanging TSF data with another trusted IT - product. Note that a requirement that addresses - modification, detection, or recovery at another trusted - IT product cannot be specified, as the mechanisms that - another trusted IT product will use to protect its data - cannot be determined in advance. For this reason, these - requirements are expressed in terms of the ``TSF - providing a capability'' which another trusted - IT product can use. - - - - - - This component should be used in situations where it is - sufficient to detect when data have been modified. An - example of such a situation is one in which another - trusted IT product can request the TOE's TSF to - retransmit data when modification has been detected, or - respond to such types of request. - - The desired strength of modification detection is based - upon a specified modification metric that is a function of - the algorithm used, which may range from a weak checksum - and parity mechanisms that may fail to detect multiple bit - changes, to more complicated cryptographic checksum - approaches. - - - , provides the ability to detect - modification of TSF data during transmission between the - TSF and another trusted IT product, under the assumption - that another trusted IT product is cognisant of the mechanism used. - - - the detection of modification of transmitted TSF data. - - - the action taken upon detection of modification of - transmitted TSF data. - - - The TSF shall provide the capability to detect modification - of all TSF data during transmission between the TSF and - another trusted IT product within the following metric: - - a defined modification metric - - the PP/ST should specify the modification metric that - the detection mechanism must satisfy. This - modification metric shall specify the desired strength - of the modification detection.. - - - The TSF shall provide the capability to verify the integrity - of all TSF data transmitted between the TSF and another - trusted IT product and perform - - action to be taken - - the PP/ST should specify the actions to be taken if a - modification of TSF data has been detected. An example - of an action is: ``ignore the TSF data, and - request the originating trusted product to send the - TSF data again''. - if modifications are detected. - - - - - - - - This component should be used in situations where it is - necessary to detect or correct modifications of TSF - critical data. - - The desired strength of modification detection is based - upon a specified modification metric that is a function of - the algorithm used, which may range from a checksum and - parity mechanisms that may fail to detect multiple bit - changes, to more complicated cryptographic checksum - approaches. The metric that needs to be defined can either - refer to the attacks it will resist (e.g. only 1 in a 1000 - random messages will be accepted), or to mechanisms that - are well known in the public literature (e.g. the strength - must be conformant to the strength offered by Secure Hash - Algorithm). - - The approach taken to correct modification might be done - through some form of error correcting checksum. - - - - Some possible means of satisfying this requirement - involves the use of cryptographic functions or some form - of checksum. - - - , provides the ability for - another trusted IT product not only to detect modification, - but to correct modified TSF data under the assumption that - another trusted IT product is cognisant of the mechanism used. - - - management of the types of TSF data that the TSF should try - to correct if modified in transit; - - - management of the types of action that the TSF could take if - TSF data is modified in transit. - - - the detection of modification of transmitted TSF data; - - - the action taken upon detection of modification of - transmitted TSF data. - - - the use of the correction mechanism. - - - The TSF shall provide the capability to detect modification - of all TSF data during transmission between the TSF and - another trusted IT product within the following metric: - - a defined modification metric - - the PP/ST should specify the modification metric that - the detection mechanism must satisfy. This - modification metric shall specify the desired strength - of the modification detection.. - - - The TSF shall provide the capability to verify the integrity - of all TSF data transmitted between the TSF and another - trusted IT product and perform - - action to be taken - - the PP/ST should specify the actions to be taken if a - modification of TSF data has been detected. An example - of an action is: ``ignore the TSF data, and - request the originating trusted product to send the - TSF data again''. - if modifications are detected. - - - The TSF shall provide the capability to correct - - type of modification - - the PP/ST author should define the types of - modification from which the TSF should be capable of - recovering. - of all TSF data transmitted between the TSF and another - trusted IT product. - - - - - - - - This family provides requirements that address protection of - TSF data when it is transferred between separate parts of a - TOE across an internal channel. - - - - This family provides requirements that address protection of - TSF data when it is transferred between separate parts of a - TOE across an internal channel. - - The determination of the degree of separation (i.e., - physical or logical) that would make application of this - family useful depends on the intended environment of use. In - a hostile environment, there may be risks arising from - transfers between parts of the TOE separated by only a - system bus or an inter-process communications channel. In - more benign environments, the transfers may be across more - traditional network media. - - - - One practical mechanism available to a TSF to provide this - protection is cryptographically-based. - - - - - - , requires that TSF data be - protected when transmitted between separate parts of the - TOE. - - - management of the types of modification against which the - TSF should protect; - - - management of the mechanism used to provide the protection - of the data in transit between different parts of the TSF. - - - The TSF shall protect TSF data from - - - disclosure - - - modification - - - - the PP/ST author should specify the desired type of - protection to be provided from the choices: - disclosure, modification. - - - when it is transmitted between separate parts of the TOE. - - - - - - - - One of the ways to achieve separation of TSF data based on - SFP-relevant attributes is through the use of separate - logical or physical channels. - - - - , requires that the TSF separate - user data from TSF data during transmission. - - - management of the types of modification against which the - TSF should protect; - - - management of the mechanism used to provide the protection - of the data in transit between different parts of the TSF; - - - management of the separation mechanism. - - - The TSF shall protect TSF data from - - - disclosure - - - modification - - - - the PP/ST author should specify the desired type of - protection to be provided from the choices: - disclosure, modification. - - - when it is transmitted between separate parts of the TOE. - - - The TSF shall separate user data from TSF data when such - data is transmitted between separate parts of the TOE. - - - - - - - - - - , requires that the TSF data - transmitted between separate parts of the TOE is monitored - for identified integrity errors. - - - management of the types of modification against which the - TSF should protect; - - - management of the mechanism used to provide the protection - of the data in transit between different parts of the TSF; - - - management of the types of modification of TSF data the TSF - should try to detect; - - - management of the action>s that will be taken. - - - the detection of modification of TSF data; - - - the action taken following detection of an integrity error. - - - The TSF shall be able to detect - - - modification of data - - - substitution of data - - - re-ordering of data - - - deletion of data - - - - - other integrity errors - - - - if the PP/ST author chooses the latter selection - noted in the preceding paragraph, then the author - should also specify what those other integrity - errors are that the TSF should be capable of - detecting. - - - - - - the PP/ST author should specify the desired type of - modification that the TSF shall be able to detect. The - PP/ST author should select from: modification of data, - substitution of data, re-ordering of data, deletion of - data, or any other integrity errors. - - - for TSF data transmitted between separate parts of the TOE. - - - Upon detection of a data integrity error, the TSF shall take - the following actions: - - - specify the action to be taken - - - - the PP/ST author should specify the action to be taken - when an integrity error is identified. - - . - - - - - - - - TSF physical protection components refer to restrictions on - unauthorised physical access to the TSF, and to the - deterrence of, and resistance to, unauthorised physical - modification, or substitution of the TSF. - - The requirements of components in this family ensure that - the TSF is protected from physical tampering and - interference. Satisfying the requirements of these - components results in the TSF being packaged and used in - such a manner that physical tampering is detectable, or - resistance to physical tampering is enforced. Without these - components, the protection functions of a TSF lose their - effectiveness in environments where physical damage cannot - be prevented. This family also provides requirements - regarding how the TSF shall respond to physical tampering - attempts. - - - - TSF physical protection components refer to restrictions on - unauthorised physical access to the TSF, and to the - deterrence of, and resistance to, unauthorised physical - modification, or substitution of the TSF. - - The requirements in this family ensure that the TSF is - protected from physical tampering and - interference. Satisfying the requirements of these - components results in the TSF being packaged and used in - such a manner that physical tampering is detectable, or - resistance to physical tampering is measurable based on - defined work factors. Without these components, the - protection functions of a TSF lose their effectiveness in - environments where physical damage cannot be prevented. This - component also provides requirements regarding how the TSF - must respond to physical tampering attempts. - - Examples of physical tampering scenarios include mechanical - attack, radiation, changing the temperature. - - It is acceptable for the functions that are available to an - authorised user for detecting physical tampering to be - available only in an off-line or maintenance mode. Controls - should be in place to limit access during such modes to - authorised users. As the TSF may not be - ``operational'' during those modes, it - may not be able to provide normal enforcement for authorised - user access. The physical implementation of a TOE might - consist of several structures: for example an outer - shielding, cards, and chips. This set of - ``elements'' as a whole must protect - (protect, notify and resist) the TSF from physical - tampering. This does not mean that all devices must provide - these features, but the complete physical construct as a - whole should. - - Although there is only minimal auditing associating with - these components, this is solely because there is the - potential that the detection and alarm mechanisms may be - implemented completely in hardware, below the level of - interaction with an audit subsystem (for example, a - hardware-based detection system based on breaking a circuit - and lighting a light emitting diode (LED) if the circuit is - broken when a button is pressed by the authorised - user). Nevertheless, a PP/ST author may determine that for a - particular anticipated threat environment, there is a need - to audit physical tampering. If this is the case, the PP/ST - author should include appropriate requirements in the list - of audit events. Note that inclusion of these requirements - may have implications on the hardware design and its - interface to the software. - - - - - - should be used when threats from - unauthorised physical tampering with parts of the TOE are not - countered by procedural methods. It addresses the threat of - undetected physical tampering with the TSF. Typically, an - authorised user would be given the function to verify whether - tampering took place. As written, this component simply provides - a TSF capability to detect tampering. Specification of - management functions in should be - considered to specify who can make use of that capability, and - how they can make use of that capability. If this is done by non-IT mechanisms - (e.g. physical inspection) management functions are not required. - - - - , provides for features that - indicate when a TSF device or TSF element is subject to - tampering. However, notification of tampering is not - automatic; an authorised user must invoke a security - administrative function or perform manual inspection to - determining if tampering has occurred. - - management of the user or role that determines whether physical - tampering has occurred. - - - if detection by IT means, detection of intrusion. - - - The TSF shall provide unambiguous detection of physical - tampering that might compromise the TSF. - - - The TSF shall provide the capability to determine whether - physical tampering with the TSF's devices or - TSF's elements has occurred. - - - - - - - - - - should be used when threats from - unauthorised physical tampering with parts of the TOE are - not countered by procedural methods, and it is required - that designated individuals be notified of physical - tampering. It addresses the threat that physical tampering - with TSF elements, although detected, may not be noticed. - Specification of management functions in FMT_MOF.1 Management of - security functions behaviour should be considered to specify who - can make use of that capability, and how they can make use of that capability. - - - - , provides for automatic - notification of tampering for an identified subset of - physical penetrations. - - - management of the user or role that gets informed about - intrusions; - - - management of the list of devices that should inform the - indicated user or role about the intrusion. - - - detection of intrusion. - - - The TSF shall provide unambiguous detection of physical - tampering that might compromise the TSF. - - - The TSF shall provide the capability to determine whether physical - tampering with the TSF's devices or - TSF's elements has occurred. - - - For - - - list of TSF devices/elements for which active detection - is required - - - - the PP/ST author should provide a list of TSF - devices/elements for which active detection of - physical tampering is required. - - , the TSF shall monitor the devices and - elements and notify - - - a designated user or role - - - - the PP/ST author should designate a user or role that - is to be notified when tampering is detected. The type - of user or role may vary depending on the particular - security administration component (from the family) included in the PP/ST. - - - when physical tampering with the - TSF's devices or TSF's elements has - occurred. - - - - - - - For some forms of tampering, it is necessary that the TSF - not only detects the tampering, but actually resists it or - delays the attacker. - - This component should be used when TSF devices and TSF - elements are expected to operate in an environment where a - physical tampering (e.g. observation, analysis, or - modification) of the internals of a TSF device or TSF - element itself is a threat. - - - - , provides for features that prevent - or resist physical tampering with TSF devices and TSF - elements. - - - management of the automatic responses to physical tampering. - - - The TSF shall resist - - - physical tampering scenarios - - - - the PP/ST author should specify tampering scenarios to - a list of TSF devices/elements for which the TSF - should resist physical tampering. This list may be - applied to a defined subset of the TSF physical - devices and elements based on considerations such as - technology limitations and relative physical exposure - of the device. Such subsetting should be clearly - defined and justified. Furthermore, the TSF should - automatically respond to physical tampering. The - automatic response should be such that the policy of - the device is preserved; for example, with a - confidentiality policy, it would be acceptable to - physically disable the device so that the protected - information may not be retrieved. - - - to the - - - list of TSF devices/elements - - - - the PP/ST author should specify the list of TSF - devices/elements for which the TSF should resist - physical tampering in the scenarios that have been - identified. - - - by responding automatically such that the SFRs are always enforced. - - - - - - - - The requirements of this family ensure that the TSF can - determine that the TOE is started up without protection - compromise and can recover without protection compromise - after discontinuity of operations. This family is important - because the start-up state of the TSF determines the - protection of subsequent states. - - - - The requirements of this family ensure that the TSF can - determine that the TOE is started-up without protection - compromise and can recover without protection compromise - after discontinuity of operations. This family is important - because the start-up state of the TSF determines the - protection of subsequent states. - - Recovery components reconstruct the TSF secure states, or - prevent transitions to insecure states, as a direct response - to occurrences of expected failures, discontinuity of - operation or start-up. Failures that must be generally - anticipated include the following: - - - Unmaskable action failures that always result in a - system crash (e.g. persistent inconsistency of critical - system tables, uncontrolled transfers within the TSF - code caused by transient failures of hardware or - firmware, power failures, processor failures, - communication failures). - - - Media failures causing part or all of the media - representing the TSF objects to become inaccessible or - corrupt (e.g. parity errors, disk head crash, persistent - read/write failure caused by misaligned disk heads, - worn-out magnetic coating, dust on the disk surface). - - - Discontinuity of operation caused by erroneous - administrative action or lack of timely administrative - action (e.g. unexpected shutdowns by turning off power, - ignoring the exhaustion of critical resources, - inadequate installed configuration). - - - - Note that recovery may be from either a complete or partial - failure scenario. Although a complete failure might occur in - a monolithic operating system, it is less likely to occur in - a distributed environment. In such environments, subsystems - may fail, but other portions remain operational. Further, - critical components may be redundant (disk mirroring, - alternative routes), and checkpoints may be available. Thus, - recovery is expressed in terms of recovery to a secure - state. - There are different interactions between - and components to be considered when - selecting : - - The need for trusted recovery may be indicated through - the results of TSF self-testing, where the results of - the self-tests indicate that the TSF is in an insecure - state and return to a secure state or entrance in - maintenance mode is required. - - A failure, as discussed above, may be identified by an - administrator. Either the administrator may perform - the actions to return the TOE to a secure state and - then invoke TSF self-tests to confirm that the secure - state has been achieved. Or, the TSF self-tests may be - invoked to complete the recovery process. - - A combination of a. and b. above, where the need for - trusted recovery is indicated through the results of - TSF self-testing, the administrator performs the - actions to return the TOE to a secure state and then - invokes TSF self-tests to confirm that the secure - state has been achieved. - - Self tests detect a failure/service discontinuity, - then either automated recovery or entrance to a - maintenance mode. - - - This family identifies a maintenance mode. In this - maintenance mode normal operation might be impossible or - severely restricted, as otherwise insecure situations might - occur. Typically, only authorised users should be allowed - access to this mode but the real details of who can access - this mode is a function of . If does not put any controls on who can access this - mode, then it may be acceptable to allow any user to restore - the system if the TOE enters such a state. However, in - practice, this is probably not desirable as the user - restoring the system has an opportunity to configure the TOE - in such a way as to violate the SFRs. - - Mechanisms designed to detect exceptional conditions during - operation fall under , , and other areas that address the - concept of ``Software Safety.'' It is likely that the use of - one of these families will be required to support the adoption - of . This is to ensure that - the TOE will be able to detect when recovery is - required. - - Throughout this family, the phrase ``secure state'' is - used. This refers to some state in which the TOE has - consistent TSF data and a TSF that can correctly enforce the - policy. This state may be the initial ``boot'' of a clean - system, or it might be some checkpointed state. - - Following recovery, it may be necessary to confirm that the - secure state has been achieved through self-testing of the - TSF. However, if the recovery is performed in a manner such - that only a secure state can be achieved, else recovery - fails, then the dependency to the TSF - self-test component may be argued away. - - - - - - - - - In the hierarchy of the trusted recovery family, recovery - that requires only manual intervention is the least - desirable, for it precludes the use of the system in an - unattended fashion. - - This component is intended for use in TOEs that do not - require unattended recovery to a secure state. The - requirements of this component reduce the threat of - protection compromise resulting from an attended TOE - returning to an insecure state after recovery from a - failure or other discontinuity. - - - - It is acceptable for the functions that are available to - an authorised user for trusted recovery to be available - only in a maintenance mode. Controls should be in place to - limit access during maintenance to authorised users. - - - - , allows a TOE to only provide - mechanisms that involve human intervention to return to a - secure state. - - - management of who can access the restore capability within - the maintenance mode. - - - the fact that a failure or service discontinuity occurred; - - - resumption of the regular operation; - - - type of failure or service discontinuity. - - - After - - list of failures/service discontinuities - - the PP/ST author should specify the list of failures or - service discontinuities (e.g. power failure, audit - storage exhaustion, any failure or discontinuity) - following which the TOE will enter a maintenance mode. the TSF shall enter a maintenance mode where - the ability to return to a secure state is provided. - - - - - - - - - - - Automated recovery is considered to be more useful than - manual recovery, as it allows the machine to operate in an - unattended fashion. - - The component extends the feature - coverage of by requiring that there - be at least one automated method of recovery from failure - or service discontinuity. It addresses the threat of - protection compromise resulting from an unattended TOE - returning to an insecure state after recovery from a - failure or other discontinuity. - - - - It is acceptable for the functions that are available to - an authorised user for trusted recovery to be available - only in a maintenance mode. Controls should be in place to - limit access during maintenance to authorised users. - - For , it is the responsibility of - the developer of the TSF to determine the set of - recoverable failures and service discontinuities. - - It is assumed that the robustness of the automated - recovery mechanisms will be verified. - - - - , provides, for at least one type of - service discontinuity, recovery to a secure state without - human intervention; recovery for other discontinuities may - require human intervention. - - - management of who can access the restore capability within - the maintenance mode; - - - management of the list of failures/service discontinuities - that will be handled through the automatic procedures. - - - - - When automated recovery from - - list of failures/service discontinuities - - the PP/ST author should specify the list of failures or - service discontinuities (e.g. power failure, audit - storage exhaustion) following which the TOE will need to - enter a maintenance mode. is not possible, the TSF shall enter a - maintenance mode where the ability to return to a secure state - is provided. - - - For - - - list of failures/service discontinuities - - - - the PP/ST author should specify the list of failures - or other discontinuities for which automated recovery - must be possible. - - , the TSF shall ensure the return of the TOE - to a secure state using automated procedures. - - - - - - - - - - - Automated recovery is considered to be more useful than - manual recovery, but it runs the risk of losing a - substantial number of objects. Preventing undue loss of - objects provides additional utility to the recovery - effort. - - The component extends the feature - coverage of by requiring that there - not be undue loss of TSF data or objects under the control - of the TSF. At , the automated recovery - mechanisms could conceivably recover by deleting all - objects and returning the TSF to a known secure - state. This type of drastic automated recovery is - precluded in . - - This component addresses the threat of protection - compromise resulting from an unattended TOE returning to - an insecure state after recovery from a failure or other - discontinuity with a large loss of TSF data or objects - under the control of the TSF. - - - - It is acceptable for the functions that are available to - an authorised user for trusted recovery to be available - only in a maintenance mode. Controls should be in place to - limit access during maintenance to authorised users. - - It is assumed that the evaluators will verify the - robustness of the automated recovery mechanisms. - - - - , also provides for automated - recovery, but strengthens the requirements by disallowing - undue loss of protected objects. - - - - - - When automated recovery from - - list of failures/service discontinuities - - the PP/ST author should specify the list of failures or - service discontinuities (e.g. power failure, audit - storage exhaustion) following which the TOE will need to - enter a maintenance mode. - is not possible, the TSF shall enter a maintenance mode where - the ability to return to a secure state is provided. - - - For - - - list of failures/service discontinuities - - - - the PP/ST author should specify the list of failures - or other discontinuities for which automated recovery - must be possible. - - , the TSF shall ensure the return of the TOE - to a secure state using automated procedures. - - - The functions provided by the TSF to recover from failure or - service discontinuity shall ensure that the secure initial - state is restored without exceeding - - - quantification - - - - the PP/ST author should provide a quantification for - the amount of loss of TSF data or objects that is - acceptable. - - - for loss of TSF data or objects under the control of the TSF. - - - The TSF shall provide the capability to determine the - objects that were or were not capable of being recovered. - - - - - - - Function recovery requires that if there should be some - failure in the TSF, that certain functions in the TSF should - either complete successfully or recover to a secure state. - - - - , provides for recovery at the level - of particular functions, ensuring either successful completion - or rollback of TSF data to a secure state. - - - if possible, the impossibility to return to a secure state - after a failure of the TSF; - - - if possible, the detection of a failure of a function. - - - The TSF shall ensure that - - - list of functions and failure scenarios - - - - the PP/ST author should specify a list the functions and - failure scenarios. In the event that any of the - identified failure scenarios happen, the functions that have - been specified must either complete successfully or - recover to a consistent and secure state. - - - have the property that the function either completes successfully, - or for the indicated failure scenarios, recovers to a - consistent and secure state. - - - - - - - - This family addresses detection of replay for various types - of entities (e.g. messages, service requests, service - responses) and subsequent actions to correct. In the case - where replay may be detected, this effectively prevents it. - - - - This family addresses detection of replay for various types - of entities and subsequent actions to correct. - - - - - - The entities included here are, for example, messages, - service requests, service responses, or sessions. - - - - The family consists of only one component, , which requires that the TSF shall be - able to detect the replay of identified entities. - - - management of the list of identified entities for which - replay shall be detected; - - - management of the list of actions that need to be taken in - case of replay. - - - Detected replay attacks. - - - Action to be taken based on the specific actions. - - - The TSF shall detect replay for the following entities: - - - list of identified entities - - - - the PP/ST author should provide a list of identified - entities for which detection of replay should be - possible. Examples of such entities might include: - messages, service requests, service responses, and - user sessions. - - . - - - The TSF shall perform - - - list of specific actions - - - - the PP/ST author should specify the list of actions to - be taken by the TSF when replay is detected. The - potential set of actions that can be taken includes: - ignoring the replayed entity, requesting confirmation - of the entity from the identified source, and - terminating the subject from which the re-played - entity originated. - - - when replay is detected. - - - - - - - - - Distributed TOEs may give rise to greater complexity than - monolithic TOEs through the potential for differences in - state between parts of the TOE, and through delays in - communication. In most cases synchronisation of state - between distributed functions involves an exchange protocol, - not a simple action. When malice exists in the distributed - environment of these protocols, more complex defensive - protocols are required. - - establishes the requirement for certain - critical functions of the TSF to use this trusted - protocol. ensures that two distributed - parts of the TOE (e.g. hosts) have synchronised their states - after a security-relevant action. - - - - Distributed TOEs may give rise to greater complexity than - monolithic TOEs through the potential for differences in - state between parts of the TOE, and through delays in - communication. In most cases, synchronisation of state - between distributed functions involves an exchange protocol, - not a simple action. When malice exists in the distributed - environment of these protocols, more complex defensive - protocols are required. - - establishes the requirement for certain - critical functions of the TSF to use a trusted - protocol. ensures that two distributed - parts of the TOE (e.g. hosts) have synchronised their states - after a security-relevant action. - - Some states may never be synchronised, or the transaction - cost may be too high for practical use; encryption key - revocation is an example, where knowing the state after the - revocation action is initiated can never be known. Either - the action was taken and acknowledgment cannot be sent, or - the message was ignored by hostile communication partners - and the revocation never occurred. Indeterminacy is unique - to distributed TOEs. Indeterminacy and state synchrony - are related, and the same solution may apply. It is futile - to design for indeterminate states; the PP/ST author should - express other requirements in such cases (e.g. raise an - alarm, audit the event). - - - - - - - - - In this component, the TSF must supply an acknowledgement - to another part of the TSF when requested. This - acknowledgement should indicate that one part of a - distributed TOE successfully received an unmodified - transmission from a different part of the distributed TOE. - - - - , requires only a simple - acknowledgment by the data recipient. - - - failure to receive an acknowledgement when expected. - - - The TSF shall acknowledge, when requested by another part of - the TSF, the receipt of an unmodified TSF data transmission. - - - - - - - - - - - In this component, in addition to the TSF being able to - provide an acknowledgement for the receipt of a data - transmission, the TSF must comply with a request from - another part of the TSF for an acknowledgement to the - acknowledgement. - - For example, the local TSF transmits some data to a remote - part of the TSF. The remote part of the TSF acknowledges - the successful receipt of the data and requests that the - sending TSF confirm that it receives the - acknowledgement. This mechanism provides additional - confidence that both parts of the TSF involved in the data - transmission know that the transmission completed - successfully. - - - - , requires mutual acknowledgment of - the data exchange. - - - - The TSF shall acknowledge, when requested by another part of - the TSF, the receipt of an unmodified TSF data - transmission. - - - The TSF shall ensure that the relevant parts of the TSF know - the correct status of transmitted data among its different - parts, using acknowledgements. - - - - - - - - This family addresses requirements for a reliable time stamp - function within a TOE. - - - - This family addresses requirements for a reliable time stamp - function within a TOE. - - It is the responsibility of the PP/ST author to clarify the - meaning of the phrase ``reliable time - stamp'', and to indicate where the responsibility - lies in determining the acceptance of trust. - - - - - - Some possible uses of this component include providing - reliable time stamps for the purposes of audit as well as - for security attribute expiration. - - - - This family consists of only one component, , which requires that the TSF provide - reliable time stamps for TSF functions. - - - management of the time. - - - changes to the time; - - - providing a timestamp. - - - The TSF shall be able to provide reliable time stamps. - - - - - - - - In a distributed environment, a TOE may - need to exchange TSF data (e.g. the SFP-attributes - associated with data, audit information, identification - information) with another trusted IT product, This family - defines the requirements for sharing and consistent - interpretation of these attributes between the TSF of the - TOE and a different trusted IT product. - - - - In a distributed or composite environment, a TOE may - need to exchange TSF data (e.g. the SFP-attributes - associated with data, audit information, identification - information) with another trusted IT Product, This family - defines the requirements for sharing and consistent - interpretation of these attributes between the TSF of the - TOE and that of a different trusted IT Product. - - The components in this family are intended to provide - requirements for automated support for TSF data consistency - when such data is transmitted between the TSF of the TOE and - another trusted IT Product. It is also possible that wholly - procedural means could be used to produce security attribute - consistency, but they are not provided for here. - - This family is different from FDP_ETC and FDP_ITC, as those - two families are concerned only with resolving the security - attributes between the TSF and its import/export medium. - - If the integrity of the TSF data is of concern, requirements - should be chosen from the family. These - components specify requirements for the TSF to be able to - detect or detect and correct modifications to TSF data in - transit. - - - - - - The TSF is responsible for maintaining the consistency of - TSF data used by or associated with the specified function - and that are common between two or more trusted - systems. For example, the TSF data of two different - systems may have different conventions internally. For the - TSF data to be used properly (e.g. to afford the user data - the same protection as within the TOE) by the receiving - trusted IT product, the TOE and the other trusted IT - product must use a pre-established protocol to exchange - TSF data. - - - - , requires that the TSF provide the - capability to ensure consistency of attributes between - TSFs. - - - Successful use of TSF data consistency mechanisms. - - - Use of the TSF data consistency mechanisms. - - - Identification of which TSF data have been interpreted. - - - Detection of modified TSF data. - - - The TSF shall provide the capability to consistently - interpret - - - list of TSF data types - - - - the PP/ST author should define the list of TSF data - types, for which the TSF shall provide the capability - to consistently interpret, when shared between the TSF - and another trusted IT product. - - - when shared between the TSF and another trusted IT product. - - - The TSF shall use - - - list of interpretation rules to be applied by the TSF - - - - the PP/ST should assign the list of interpretation - rules to be applied by the TSF, - - - when interpreting the TSF data from another trusted IT - product. - - - - This family defines requirements for the TSF to perform tests - on one or more external entities. - This component is not intended to be applied to human users. - External entities may include applications running on the TOE, hardware or - software running ``underneath'' the TOE (platforms, operating systems etc.) - or applications/boxes connected to the TOE (intrusion detection systems, - firewalls, login servers, time servers etc.). - This family defines requirements for the testing of one or more external - entities by the TSF. These external entities are not human users, and they can - include combinations of software and/or hardware interacting with the TOE. - Examples of the types of tests that may be run are: - - Tests for the presence of a firewall, and possibly whether it is - correctly configured; - - Tests of some of the properties of the operating system that an - application TOE runs on; - - Tests of some of the properties of the IC that a smart card OS TOE - runs on (e.g. the random number generator). - - Note that the external entity may ``lie'' about the test results, either on - purpose or because it is not working correctly. - These tests can be carried out either in some maintenance state, at start-up, - on-line, or continuously. The actions to be taken by the TOE as the result of - testing are defined also in this family. - The tests of external entities should be sufficient to test all of the - characteristics of them upon which the TSF relies. - This component is not intended to be applied to human users. - This component provides support for the periodic testing of properties - related to external entities upon which the TSF's operation depends, by - requiring the ability to periodically invoke testing functions. - The PP/ST author may refine the requirement to state whether the function - should be available in off-line, on-line or maintenance mode. - It is acceptable for the functions for periodic testing to be available only in - an off-line or maintenance mode. Controls should be in place to limit access, - during maintenance, to authorised users., provides for testing of the - external entities by the TSF. - management of the conditions under which the testing of external - entities occurs, such as during initial start-up, regular interval, or - under specified conditions; - - management of the time interval if appropriate. - - Execution of the tests of the external entities and the results of - the tests. - - The TSF shall run a suite of tests - - during initial start-up - - periodically during normal operation - - at the request of an authorised user - - other conditions - - the PP/ST author should, if other conditions are - selected, specify the frequency with which the testing of external entities will be run. - An example of this other frecuency or condition may be to run the - tests each time a user requests to initiate a session with the TOE. For - instance, this could be the case of testing a directory server before its - interaction with the TSF during the user authentication process. - the PP/ST author should specify when the TSF will - run the testing of external entities, during initial start-up, periodically - during normal operation, at the request of an authorised user, or under - other conditions. If the tests are run often, then the end users should - have more confidence that the TOE is operating correctly than if the - tests are run less frequently. However, this need for confidence that - the TOE is operating correctly must be balanced with the potential - impact on the availability of the TOE, as often times, the testing of external entities may - delay the normal operation of a TOE. - to check the fulfillment of - - list of properties of the external entities - - the PP/ST author should specify the properties of the - external entities to be checked by the tests. Examples of these - properties may include configuration or availability properties of - a directory server supporting some access control part of the TSF. - . - - If the test fails, the TSF shall - - action(s) - - the PP/ST author should specify what are the action(s) - that the TSF shall perform when the testing fails. Examples of these - action(s), illustrated by a directory server instance, may include to - connect to an alternative available server or otherwise to look for a - backup server. - . - - - - - - The requirements of this family are needed to ensure the - consistency of TSF data when such data is replicated - internal to the TOE. Such data may become inconsistent if - the internal channel between parts of the TOE becomes - inoperative. If the TOE is internally structured as a - network and parts of the TOE network connections are broken, - this may occur when parts become disabled. - - - - The requirements of this family are needed to ensure the - consistency of TSF data when such data is replicated - internal to the TOE. Such data may become inconsistent if an - internal channel between parts of the TOE becomes - inoperative. If the TOE is internally structured as a - network of parts of the TOE, this can occur when parts - become disabled, network connections are broken, and so on. - - The method of ensuring consistency is not specified in this - component. It could be attained through a form of - transaction logging (where appropriate transactions are - ``rolled back'' to a site upon - reconnection); it could be updating the replicated data - through a synchronisation protocol. If a particular protocol - is necessary for a PP/ST, it can be specified through - refinement. - - It may be impossible to synchronise some states, or the cost - of such synchronisation may be too high. Examples of this - situation are communication channel and encryption key - revocations. Indeterminate states may also occur; if a - specific behaviour is desired, it should be specified via - refinement. - - - - - - - - - This family consists of only one component, , which requires that the TSF ensure the - consistency of TSF data that is replicated in multiple - locations. - - - restoring consistency upon reconnection. - - - Detected inconsistency between TSF data. - - - The TSF shall ensure that TSF data is consistent when - replicated between parts of the TOE. - - - When parts of the TOE containing replicated TSF data are - disconnected, the TSF shall ensure the consistency of the - replicated TSF data upon reconnection before processing any - requests for - - - list of functions dependent on TSF data replication - consistency - - - - the PP/ST author should specify the list of functions - dependent on TSF data replication consistency. - - . - - - - - - - - The family defines the requirements for the self-testing of - the TSF with respect to some expected correct - operation. Examples are interfaces to enforcement functions, - and sample arithmetical operations on critical parts of the - TOE. These tests can be carried out at start-up, - periodically, at the request of the authorised user, or when - other conditions are met. The actions to be taken by the TOE - as the result of self testing are defined in other families. - - The requirements of this family are also needed to detect - the corruption of TSF data and TSF itself (i.e. TSF executable code or - TSF hardware component) by various failures that do not necessarily - stop the TOE's operation (which would be handled by other - families). These checks must be performed because these - failures may not necessarily be prevented. Such failures can - occur either because of unforeseen failure modes or - associated oversights in the design of hardware, firmware, - or software, or because of malicious corruption of the TSF - due to inadequate logical and/or physical protection. - - - - The family defines the requirements for the self-testing of - the TSF with respect to some expected correct - operation. Examples are interfaces to enforcement functions, - and sample arithmetical operations on critical parts of the - TOE. These tests can be carried out at start-up, - periodically, at the request of an authorised user, or when - other conditions are met. The actions to be taken by the TOE - as the result of self testing are defined in other families. - - The requirements of this family are also needed to detect - the corruption of TSF data and TSF itself (i.e. TSF executable code or - TSF hardware component) by various failures that do not necessarily - stop the TOE's operation (which would be handled by other - families). These checks must be performed because these - failures may not necessarily be prevented. Such failures can - occur either because of unforeseen failure modes or - associated oversights in the design of hardware, firmware, - or software, or because of malicious corruption of the TSF - due to inadequate logical and/or physical protection. - - In addition, use of this component may, with appropriate - conditions, help to prevent inappropriate or damaging TSF - changes being applied to an operational TOE as the result of - maintenance activities. - - The term ``correct operation of the TSF'' refers primarily to - the operation of the TSF and the integrity of the TSF data. - - - - - - - This component provides support for the testing of the - critical functions of the TSF's operation by - requiring the ability to invoke testing functions and - check the integrity of TSF data and executable code. - - - - It is acceptable for the functions that are available to - the authorised user for periodic testing to be available - only in an off-line or maintenance mode. Controls should - be in place to limit access during these modes to - authorised users. - - - , provides the ability to test the - TSF's correct operation. These tests may be - performed at start-up, periodically, at the request of the - authorised user, or when other conditions are met. It also - provides the ability to verify the integrity of TSF data - and TSF itself. - - - management of the conditions under which TSF self testing - occurs, such as during initial start-up, regular interval, - or under specified conditions; - - - management of the time interval if appropriate. - - - Execution of the TSF self tests and the results of the - tests. - - - The TSF shall run a suite of self tests - - during initial start-up - - periodically during normal operation - - at the request of the authorised user - - at the conditions - - conditions under which self test should occur - - the PP/ST author should, if selected, specify the - conditions under which the self test should take - place. - the PP/ST author should specify when the TSF will execute - the TSF test; during initial start-up, periodically during - normal operation, at the request of an authorised user, at - other conditions. In the case of the latter option, the - PP/ST author should also assign what those conditions are - via the following assignment. - to demonstrate the correct operation of - - parts of TSF - - the PP/ST author should, if selected, specify the - list of parts of the TSF that will be subject to TSF - self-testing. - the TSF - - the PP/ST author should specify whether the self tests - are to be carried out to demonstrate the correct - operation of the entire TSF, or of only specified parts - of TSF.. - - - The TSF shall provide authorised users with the capability to - verify the integrity of - - parts of TSF data - - the PP/ST author should, if selected, specify the - list of TSF data that will be verified for - integrity. - TSF data - - the PP/ST author should specify whether data integrity - is to be verified for all TSF data, or only for selected - data.. - - - The TSF shall provide authorised users with the capability to - verify the integrity of - - parts of TSF - - the PP/ST author should, if selected, specify the - list of TSF that will be verified for - integrity. - TSF - - the PP/ST author should specify whether TSF integrity - is to be verified for all TSF, or only for selected - TSF.. - - - - - - - - This class provides three families that support the - availability of required resources such as processing - capability and/or storage capacity. The family Fault Tolerance - provides protection against unavailability of capabilities - caused by failure of the TOE. The family Priority of Service - ensures that the resources will be allocated to the more - important or time-critical tasks and cannot be monopolised by - lower priority tasks. The family Resource Allocation provides - limits on the use of available resources, therefore preventing - users from monopolising the resources. - - - - This class provides three families that support the - availability of required resources such as processing - capability and/or storage capacity. The family Fault Tolerance - provides protection against unavailability of capabilities - caused by failure of the TOE. The family Priority of Service - ensures that the resources will be allocated to the more - important or time-critical tasks, and cannot be monopolised by - lower priority tasks. The family Resource Allocation provides - limits on the use of available resources, therefore preventing - users from monopolising the resources. - - - - - - The requirements of this family ensure that the TOE will - maintain correct operation even in the event of failures. - - - - This family provides requirements for the availability of - capabilities even in the case of failures. Examples of such - failures are power failure, hardware failure, or software - error. In case of these errors, if so specified, the TOE - will maintain the specified capabilities. The PP/ST author - could specify, for example, that a TOE used in a nuclear - plant will continue the operation of the shut-down procedure - in the case of power-failure or communication-failure. - - Because the TOE can only continue its correct operation if - the SFRs are enforced, there is a requirement that the system - must remain in a secure state after a failure. This - capability is provided by . - - The mechanisms to provide fault tolerance could be active or - passive. In case of an active mechanism, specific functions - are in place that are activated in case the error - occurs. For example, a fire alarm is an active mechanism: - the TSF will detect the fire and can take action such as - switching operation to a backup. In a passive scheme, the - architecture of the TOE is capable of handling the - error. For example, the use of a majority voting scheme with - multiple processors is a passive solution; failure of one - processor will not disrupt the operation of the TOE - (although it needs to be detected to allow correction). - - For this family, it does not matter whether the failure has - been initiated accidentally (such as flooding or unplugging - the wrong device) or intentionally (such as monopolising). - - - - - - - - - This component is intended to specify which capabilities - the TOE will still provide after a failure of the - system. Since it would be difficult to describe all - specific failures, categories of failures may be - specified. Examples of general failures are flooding of - the computer room, short term power interruption, - breakdown of a CPU or host, software failure, or buffer - overflow. - - - - , requires the TOE to continue - correct operation of identified capabilities in the event - of identified failures. - - - Any failure detected by the TSF. - - - All TOE capabilities being discontinued due to a failure. - - - The TSF shall ensure the operation of - - - list of TOE capabilities - - - - the PP/ST author should specify the list of TOE - capabilities the TOE will maintain during and after a - specified failure. - - - when the following failures occur: - - - list of type of failures - - - - the PP/ST author should specify the list of type of - failures against which the TOE has to be explicitly - protected. If a failure in this list occurs, the TOE - will be able to continue its operation. - - . - - - - - - - - - - - This component is intended to specify against what type of - failures the TOE must be resistant. Since it would be - difficult to describe all specific failures, categories of - failures may be specified. Examples of general failures - are flooding of the computer room, short term power - interruption, breakdown of a CPU or host, software - failure, or overflow of buffer. - - - - , requires the TOE to continue - correct operation of all capabilities in the event of - identified failures. - - - Any failure detected by the TSF. - - - The TSF shall ensure the operation of all the - TOE's capabilities when the following failures - occur: - - - list of type of failures - - - - the PP/ST author should specify the list of type of - failures against which the TOE has to be explicitly - protected. If a failure in this list occurs, the TOE - will be able to continue its operation. - - . - - - - - - - - The requirements of this family allow the TSF to control the - use of resources under the control of the TSF by users and subjects such - that high priority activities under the control of the TSF will always be - accomplished without undue interference or delay caused by - low priority activities. - - - - The requirements of this family allow the TSF to control the - use of resources under the control of the TSF by users and subjects such - that high priority activities under the control of the TSF will always be - accomplished without interference or delay due to low - priority activities. In other words, time critical tasks - will not be delayed by tasks that are less time critical. - - This family could be applicable to several types of - resources, for example, processing capacity, and - communication channel capacity. - - The Priority of Service mechanism might be passive or - active. In a passive Priority of Service system, the system - will select the task with the highest priority when given a - choice between two waiting applications. While using passive - Priority of Service mechanisms, when a low priority task is - running, it cannot be interrupted by a high priority - task. While using an active Priority of Service mechanisms, - lower priority tasks might be interrupted by new high - priority tasks. - - The audit requirement states that all reasons for rejection - should be audited. It is left to the developer to argue that - an operation is not rejected but delayed. - - - - - - This component defines priorities for a subject, and the - resources for which this priority will be used. If a - subject attempts to take action on a resource controlled - by the Priority of Service requirements, the access and/or - time of access will be dependent on the subject's - priority, the priority of the currently acting subject, - and the priority of the subjects still in the queue. - - - - , provides priorities for a - subject's use of a subset of the resources - under the control of the TSF. - - - assignment of priorities to each subject in the TSF. - - - Rejection of operation based on the use of priority within - an allocation. - - - All attempted uses of the allocation function which involves - the priority of the service functions. - - - The TSF shall assign a priority to each subject in the TSF. - - - The TSF shall ensure that each access to - - - controlled resources - - - - the PP/ST author should specify the list of controlled - resources for which the TSF enforces priority of service - (e.g. resources such as processes, disk space, memory, - bandwidth). - - - shall be mediated on the basis of the subjects assigned - priority. - - - - - - - - This component defines priorities for a subject. All - shareable resources under the control of the TSF will be subjected to the - Priority of Service mechanism. If a subject attempts to - take action on a shareable TSF resource, the access and/or - time of access will be dependent on the subject's - priority, the priority of the currently acting subject, - and the priority of the subjects still in the queue. - - - - , provides priorities for a - subject's use of all of the resources under the control of the TSF. - - - - - - The TSF shall assign a priority to each subject in the TSF. - - - The TSF shall ensure that each access to all shareable - resources shall be mediated on the basis of the subjects - assigned priority. - - - - - - - - The requirements of this family allow the TSF to control the - use of resources by users and subjects such that denial of - service will not occur because of unauthorised - monopolisation of resources. - - - - The requirements of this family allow the TSF to control the - use of resources under the control of the TSF by users and subjects such - that unauthorised denial of service will not take place by - means of monopolisation of resources by other users or - subjects. - - Resource allocation rules allow the creation of quotas or - other means of defining limits on the amount of resource - space or time that may be allocated on behalf of a specific - user or subjects. These rules may, for example: - - - Provide for object quotas that constrain the number - and/or size of objects a specific user may allocate. - - - Control the allocation/deallocation of preassigned - resource units where these units are under the control - of the TSF. - - - - In general, these functions will be implemented through the - use of attributes assigned to users and resources. - - The objective of these components is to ensure a certain - amount of fairness among the users (e.g. a single user - should not allocate all the available space) and - subjects. Since resource allocation often goes beyond the - lifespan of a subject (i.e. files often exist longer than - the applications that generated them), and multiple - instantiations of subjects by the same user should not - negatively affect other users too much, the components allow - that the allocation limits are related to the users. In some - situations the resources are allocated by a subject - (e.g. main memory or CPU cycles). In those instances the - components allow that the resource allocation be on the - level of subjects. - - This family imposes requirements on resource allocation, not - on the use of the resource itself. The audit requirements - therefore, as stated, also apply to the allocation of the - resource, not to the use of the resource. - - - - - - This component provides requirements for quota mechanisms - that apply to only a specified set of the shareable - resources in the TOE. The requirements allow the quotas to - be associated with a user, possibly assigned to groups of - users or subjects as applicable to the TOE. - - - - , provides requirements for quota - mechanisms that ensure that users and subjects will not - monopolise a controlled resource. - - - specifying maximum limits for a resource for groups and/or - individual users and/or subjects by an administrator. - - - Rejection of allocation operation due to resource limits. - - - All attempted uses of the resource allocation functions for - resources that are under control of the TSF. - - - The TSF shall enforce maximum quotas of the following - resources: - - - controlled resources - - - - the PP/ST author should specify the list of controlled - resources for which maximum resource allocation limits - are required (e.g. processes, disk space, memory, - bandwidth). If all resources under the control of the TSF need to be - included, the words ``all TSF - resources'' can be specified. - - - that - - - individual user - - - defined group of users - - - subjects - - - - the PP/ST author should select whether the maximum - quotas apply to individual users, to a defined group - of users, or subjects or any combination of these. - - - can use - - - simultaneously - - - over a specified period of time - - - - the PP/ST author should select whether the maximum - quotas are applicable to any given time - (simultaneously), or over a specific time interval. - - . - - - - - - - - This component provides requirements for quota mechanisms - that apply to a specified set of the shareable resources - in the TOE. The requirements allow the quotas to be - associated with a user, or possibly assigned to groups of - users as applicable to the TOE. - - - - , provides requirements for quota - mechanisms that ensure that users and subjects will always - have at least a minimum of a specified resource and that - they will not be able to monopolise a controlled resource. - - - specifying minimum and maximum limits for a resource for - groups and/or individual users and/or subjects by an - administrator. - - - - - The TSF shall enforce maximum quotas of the following - resources - - - controlled resources - - - - the PP/ST author should specify the controlled - resources for which maximum and minimum resource - allocation limits are required (e.g. processes, disk - space, memory, bandwidth). If all resources under the control of the TSF - need to be included, the words ``all TSF - resources'' can be specified. - - - that - - - individual user - - - defined group of users - - - subjects - - - - the PP/ST author should select whether the maximum - quotas apply to individual users, to a defined group - of users, or subjects or any combination of these. - - - can use - - - simultaneously - - - over a specified period of time - - - - the PP/ST author should select whether the maximum - quotas are applicable to any given time - (simultaneously), or over a specific time interval. - - . - - - The TSF shall ensure the provision of minimum quantity of - each - - - controlled resource - - - - the PP/ST author should specify the controlled - resources for which a minimum allocation limit needs - to be set (e.g. processes, disk space, memory, - bandwidth). If all resources under the control of the TSF need to be - included the words ``all TSF resources'' - can be specified. - - - that is available for - - - an individual user - - - defined group of users - - - subjects - - - - the PP/ST author should select whether the minimum - quotas apply to individual users, to a defined group - of users, or subjects or any combination of these. - - - to use - - - simultaneously - - - over a specified period of time - - - - the PP/ST author should select whether the minimum - quotas are applicable to any given time - (simultaneously), or over a specific time interval. - - . - - - - - - - - This family specifies functional requirements for controlling - the establishment of a user's session. - - - - The establishment of a user's session typically - consists of the creation of one or more subjects that perform - operations in the TOE on behalf of the user. At the end of the - session establishment procedure, provided the TOE access - requirements are satisfied, the created subjects bear the - attributes determined by the identification and authentication - functions. This family specifies functional requirements for - controlling the establishment of a user's session. - - A user session is defined as the period starting at the time - of the identification/authentication, or if more appropriate, - the start of an interaction between the user and the system, - up to the moment that all subjects (resources and attributes) - related to that session have been deallocated. - - - - - - This family defines requirements to limit the scope of - session security attributes that a user may select for a - session. - - - - This family defines requirements that will limit the session - security attributes a user may select, and the subjects to - which a user may be bound, based on: the method of access; - the location or port of access; and/or the time - (e.g. time-of-day, day-of-week). - - This family provides the capability for a PP/ST author to - specify requirements for the TSF to place limits on the - domain of an authorised user's security attributes - based on an environmental condition. For example, a user may - be allowed to establish a ``secret session'' - during normal business hours but outside those hours the - same user may be constrained to only establishing - ``unclassified sessions''. The identification of - relevant constraints on the domain of selectable attributes - can be achieved through the use of the selection - operation. These constraints can be applied on an - attribute-by-attribute basis. When there exists a need to - specify constraints on multiple attributes this component - will have to be replicated for each attribute. Examples of - attributes that could be used to limit the session security - attributes are: - - - The method of access can be used to specify in which - type of environment the user will be operating - (e.g. file transfer protocol, terminal, vtam). - - - The location of access can be used to constrain the - domain of a user's selectable attributes based - on a user's location or port of access. This - capability is of particular use in environments where - dial-up facilities or network facilities are available. - - - The time of access can be used to constrain the domain - of a user's selectable attributes. For example, - ranges may be based upon time-of-day, day-of-week, or - calendar dates. This constraint provides some - operational protection against user actions that could - occur at a time where proper monitoring or where proper - procedural measures may not be in place. - - - - - - - - , provides the requirement for a TOE - to limit the scope of the session security attributes - during session establishment. - - - management of the scope of the session security attributes - by an administrator. - - - All failed attempts at selecting a session security - attributes; - - - All attempts at selecting a session security attributes; - - - Capture of the values of each session security attributes. - - - The TSF shall restrict the scope of the session security - attributes - - - session security attributes - - - - the PP/ST author should specify the set of session - security attributes that are to be - constrained. Examples of these session security - attributes are user clearance level, integrity level - and roles. - - , based on - - - attributes - - - - the PP/ST author should specify the set of attributes - that can be use to determine the scope of the session - security attributes. Examples of such attributes are - user identity, originating location, time of access, - and method of access. - - . - - - - - - - - This family defines requirements to place limits on the - number of concurrent sessions that belong to the same user. - - - - This family defines how many sessions a user may have at the - same time (concurrent sessions). This number of concurrent - sessions can either be set for a group of users or for each - individual user. - - - - - - - - - This component allows the system to limit the number of - sessions in order to effectively use the resources of the - TOE. - - - - , provides limitations that apply to - all users of the TSF. - - - management of the maximum allowed number of concurrent user - sessions by an administrator. - - - Rejection of a new session based on the limitation of - multiple concurrent sessions. - - - Capture of the number of currently concurrent user sessions - and the user security attribute(s). - - - The TSF shall restrict the maximum number of concurrent - sessions that belong to the same user. - - - The TSF shall enforce, by default, a limit of - - - default number - - - - the PP/ST author should specify the default number of - maximum concurrent sessions to be used. - - - sessions per user. - - - - - - - - - - - This component provides additional capabilities over those - of , by allowing further constraints - to be placed on the number of concurrent sessions that - users are able to invoke. These constraints are in terms - of a user's security attributes, such as a - user's identity, or membership of a role. - - - - extends by - requiring the ability to specify limitations on the number - of concurrent sessions based on the related security - attributes. - - - management of the rules that govern the maximum allowed - number of concurrent user sessions by an administrator. - - - - - The TSF shall restrict the maximum number of concurrent - sessions that belong to the same user according to the rules - - - rules for the number of maximum concurrent sessions - - - - the PP/ST author should specify the rules that - determine the maximum number of concurrent - sessions. An example of a rule is ``maximum - number of concurrent sessions is one if the user has a - classification level of ``secret'' - and five otherwise''. - - . - - - The TSF shall enforce, by default, a limit of - - - default number - - - - the PP/ST author should specify the default number of - maximum concurrent sessions to be used. - - - sessions per user. - - - - - - - - This family defines requirements for the TSF to provide the - capability for TSF-initiated and user-initiated locking, - unlocking, and termination of interactive sessions. - - - This family defines requirements for the TSF to provide the - capability for TSF-initiated and user-initiated locking, - unlocking, and termination of interactive sessions. - When a user is directly interacting with subjects in the TOE - (interactive session), the user's terminal is vulnerable if - left unattended. This family provides requirements for the TSF - to disable (lock) the terminal or terminate the session after - a specified period of inactivity, and for the user to initiate - the disabling (locking) of the terminal or terminate the - session. To reactivate the terminal, an event specified by the - PP/ST author, such as the user re-authentication must - occur. - A user is considered inactive, if he/she has not provided any - stimulus to the TOE for a specified period of time. - A PP/ST author should consider whether - should be included. In that case, the function ``session - locking'' should be included in the operation in . - - - - - - - - , provides the capability for the - TSF to lock an active user session after a specified - period of time. Locking a terminal would prevent any - further interaction with an existing active session - through the use of the locked terminal. - - If display devices are overwritten, the replacement - contents need not be static (i.e. ``screen - savers'' are permitted). - - This component allows the PP/ST author to specify what - events will unlock the session. These events may be - related to the terminal (e.g. fixed set of keystrokes to - unlock the session), the user (e.g. reauthentication), or - time. - - - - includes system initiated locking - of an interactive session after a specified period of user - inactivity. - - - specification of the time of user inactivity after which - lock-out occurs for an individual user; - - - specification of the default time of user inactivity after - which lock-out occurs; - - - management of the events that should occur prior to - unlocking the session. - - - Locking of an interactive session by the session locking - mechanism. - - - Successful unlocking of an interactive session. - - - Any attempts at unlocking an interactive session. - - - The TSF shall lock an interactive session after - - - time interval of user inactivity - - - - the PP/ST author should specify the interval of user - inactivity that will trigger the locking of an - interactive session. If so desired the PP/ST author - could, through the assignment, specify that the time - interval is left to the authorised administrator or - the user. The management functions in the FMT class - can specify the capability to modify this time - interval, making it the default value. - - - by: - - - clearing or overwriting display devices, making the - current contents unreadable; - - - disabling any activity of the user's data - access/display devices other than unlocking the session. - - - - - The TSF shall require the following events to occur prior to - unlocking the session: - - - events to occur - - - - the PP/ST author should specify the event(s) that - should occur before the session is unlocked. Examples - of such an event are: ``user - re-authentication'' or ``user - enters unlock key-sequence''. - - . - - - - - - - - - , provides the capability for - an authorised user to lock and unlock his/her own interactive - session. This would provide authorised users with the ability to - effectively block further use of their active sessions without - having to terminate the active session. - - If devices are overwritten, the replacement contents need - not be static (i.e. ``screen savers'' - are permitted). - - - - , provides capabilities for the user - to lock and unlock the user's own interactive - sessions. - - - management of the events that should occur prior to - unlocking the session. - - - - - The TSF shall allow user-initiated locking of the - user's own interactive session, by: - - - clearing or overwriting display devices, making the - current contents unreadable; - - - disabling any activity of the user's data - access/display devices other than unlocking the session. - - - - - The TSF shall require the following events to occur prior to - unlocking the session: - - - events to occur - - - - the PP/ST author should specify the event(s) that - should occur before the session is unlocked. Examples - of such an event are: ``user - re-authentication'', or ``user - enters unlock key-sequence''. - - . - - - - - - - , requires that the TSF terminate an - interactive user session after a period of inactivity. - - The PP/ST author should be aware that a session may - continue after the user terminated his/her activity, for - example, background processing. This requirement would - terminate this background subject after a period of - inactivity of the user without regard to the status of the - subject. - - - , provides requirements for - the TSF to terminate the session after a specified period of - user inactivity. - - - specification of the time of user inactivity after which - termination of the interactive session occurs for an - individual user; - - - specification of the default time of user inactivity after - which termination of the interactive session occurs. - - - Termination of an interactive session by the session locking - mechanism. - - - The TSF shall terminate an interactive session after a - - - time interval of user inactivity - - - - the PP/ST author should specify the interval of user - inactivity that will trigger the termination of an - interactive session. If so desired, the PP/ST author - could, through the assignment, specify that the - interval is left to the authorised administrator or - the user. The management functions in the FMT class - can specify the capability to modify this time - interval, making it the default value. - - . - - , provides the capability for an - authorised user to terminate his/her interactive - session.. - The PP/ST author should be aware that a session may continue - after the user terminated his/her activity, for example, - background processing. This requirement would allow the user - to terminate this background subject without regard to the - status of the subject., provides capabilities for the user - to terminate the user's own interactive sessions. - Termination of an interactive session by the user. - - The TSF shall allow user-initiated termination of the user's own - interactive session. - - - - - - - This family defines requirements to display a configurable - advisory warning message to users regarding the appropriate - use of the TOE. - - - - Prior to identification and authentication, TOE access - requirements provide the ability for the TOE to display an - advisory warning message to potential users pertaining to - appropriate use of the TOE. - - - - - - This component requires that there is an advisory warning - regarding the unauthorised use of the TOE. A PP/ST author - could refine the requirement to include a default banner. - - - - , provides the requirement for a TOE - Access Banner. This banner is displayed prior to the - establishment dialogue for a session. - - - maintenance of the banner by the authorised administrator. - - - Before establishing a user session, the TSF shall display an - advisory warning message regarding unauthorised use of the - TOE. - - - - - - - - This family defines requirements for the TSF to display to a - user, upon successful session establishment, a history of - successful and unsuccessful attempts to access the - user's account. - - - - This family defines requirements for the TSF to display to - users, upon successful session establishment to the TOE, a - history of unsuccessful attempts to access the account. This - history may include the date, time, means of access, and - port of the last successful access to the TOE, as well as - the number of unsuccessful attempts to access the TOE since - the last successful access by the identified user. - - - - - - - This family can provide authorised users with information - that may indicate the possible misuse of their user - account. - - This component request that the user is presented with the - information. The user should be able to review the - information, but is not forced to do so. If a user so - desires he might, for example, create scripts that ignore - this information and start other processes. - - - - , provides the requirement for a TOE - to display information related to previous attempts to - establish a session. - - - Upon successful session establishment, the TSF shall display - the - - - date - - - time - - - method - - - location - - - - the PP/ST author should select the security attributes - of the last successful session establishment that will - be shown at the user interface. The items are: date, - time, method of access (such as ftp), and/or location - (e.g. terminal 50). - - - of the last successful session establishment to the user. - - - Upon successful session establishment, the TSF shall display - the - - - date - - - time - - - method - - - location - - - - the PP/ST author should select the security attributes - of the last unsuccessful session establishment that - will be shown at the user interface. The items are: - date, time, method of access (such as ftp), and/or - location (e.g. terminal 50). - - - of the last unsuccessful attempt to session establishment - and the number of unsuccessful attempts since the last - successful session establishment. - - - The TSF shall not erase the access history information from - the user interface without giving the user an opportunity to - review the information. - - - - - - - This family defines requirements to deny a user permission - to establish a session with the TOE. - - - - This family defines requirements to deny an user permission - to establish a session with the TOE based on attributes such - as the location or port of access, the user's security - attribute (e.g. identity, clearance level, integrity level, - membership in a role), ranges of time (e.g. time-of-day, - day-of-week, calendar dates) or combinations of parameters. - - This family provides the capability for the PP/ST author to - specify requirements for the TOE to place constraints on the - ability of an authorised user to establish a session with - the TOE. The identification of relevant constraints can be - achieved through the use of the selection - operation. Examples of attributes that could be used to - specify the session establishment constraints are: - - - The location of access can be used to constrain the - ability of a user to establish an active session with - the TOE, based on the user's location or port - of access. This capability is of particular use in - environments where dial-up facilities or network - facilities are available. - - - The user's security attributes can be used to - place constraints on the ability of a user to establish - an active session with the TOE. For example, these - attributes would provide the capability to deny session - establishment based on any of the following: - - - a user's identity; - - - a user's clearance level; - - - a user's integrity level; and - - - a user's membership in a role. - - - - - - This capability is particularly relevant in situations where - authorisation or login may take place at a different - location from where TOE access checks are performed. - - - The time of access can be used to constrain the ability - of a user to establish an active session with the TOE - based on ranges of time. For example, ranges may be - based upon time-of-day, day-of-week, or calendar - dates. This constraint provides some operational - protection against actions that could occur at a time - where proper monitoring or where proper procedural - measures may not be in place. - - - - - - - - , provides requirements for denying - users access to the TOE based on attributes. - - - management of the session establishment conditions by the - authorised administrator. - - - Denial of a session establishment due to the session - establishment mechanism. - - - All attempts at establishment of a user session. - - - Capture of the value of the selected access parameters - (e.g. location of access, time of access). - - - The TSF shall be able to deny session establishment based on - - - attributes - - - - the PP/ST author should specify the attributes that - can be used to restrict the session - establishment. Example of possible attributes are user - identity, originating location (e.g. no remote - terminals), time of access (e.g. outside hours), or - method of access (e.g. X-windows). - - . - - - - - - - - Families in this class provide requirements for a trusted - communication path between users and the TSF, and for a - trusted communication channel between the TSF and other - trusted IT products. Trusted paths and channels have the - following general characteristics: - - - The communications path is constructed using internal and - external communications channels (as appropriate for the - component) that isolate an identified subset of TSF data - and commands from the remainder of the TSF and user data. - - - Use of the communications path may be initiated by the - user and/or the TSF (as appropriate for the component). - - - The communications path is capable of providing assurance - that the user is communicating with the correct TSF, and - that the TSF is communicating with the correct user (as - appropriate for the component). - - - - In this paradigm, a trusted channel is a communication channel - that may be initiated by either side of the channel, and - provides non-repudiation characteristics with respect to the - identity of the sides of the channel. - - A trusted path provides a means for users to perform functions - through an assured direct interaction with the TSF. Trusted - path is usually desired for user actions such as initial - identification and/or authentication, but may also be desired - at other times during a user's session. Trusted - path exchanges may be initiated by a user or the TSF. User - responses via the trusted path are guaranteed to be protected - from modification by or disclosure to untrusted applications. - - - - Users often need to perform functions through direct - interaction with the TSF. A trusted path provides confidence - that a user is communicating directly with the TSF whenever it - is invoked. A user's response via the trusted path - guarantees that untrusted applications cannot intercept or - modify the user's response. Similarly, trusted - channels are one approach for secure communication between the - TSF and another trusted IT product. - - Absence of a trusted path may allow breaches of accountability - or access control in environments where untrusted applications - are used. These applications can intercept user-private - information, such as passwords, and use it to impersonate - other users. As a consequence, responsibility for any system - actions cannot be reliably assigned to an accountable - entity. Also, these applications could output erroneous - information on an unsuspecting user's display, - resulting in subsequent user actions that may be erroneous and - may lead to a security breach. - - - - - - This family defines requirements for the creation of a - trusted channel between the TSF and other trusted IT - products for the performance of security critical - operations. This family should be included whenever there - are requirements for the secure communication of user or TSF - data between the TOE and other trusted IT products. - - - - This family defines the rules for the creation of a trusted - channel connection that goes between the TSF and another - trusted IT product for the performance of security critical - operations between the products. An example of such a - security critical operation is the updating of the TSF - authentication database by the transfer of data from a - trusted product whose function is the collection of audit - data. - - - - - - This component should be used when a trusted communication - channel between the TSF and another trusted IT product is - required. - - - - , requires that the TSF provide a - trusted communication channel between itself and another - trusted IT product. - - - Configuring the actions that require trusted channel, if - supported. - - - Failure of the trusted channel functions. - - - Identification of the initiator and target of failed trusted - channel functions. - - - All attempted uses of the trusted channel functions. - - - Identification of the initiator and target of all trusted - channel functions. - - - The TSF shall provide a communication channel between itself - and another trusted IT product that is logically distinct - from other communication channels and provides assured - identification of its end points and protection of the - channel data from modification or disclosure. - - - The TSF shall permit - - the TSF - - another trusted IT product - - the PP/ST author must specify whether the local TSF, - another trusted IT product, or both shall have the - capability to initiate the trusted channel. - to initiate communication via the trusted channel. - - - The TSF shall initiate communication via the trusted channel - for - - - list of functions for which a trusted channel is - required - - - - the PP/ST author should specify the functions for - which a trusted channel is required. Examples of these - functions may include transfer of user, subject, - and/or object security attributes and ensuring - consistency of TSF data. - - . - - - - - - - - This family defines the requirements to establish and - maintain trusted communication to or from users and the - TSF. A trusted path may be required for any - security-relevant interaction. Trusted path exchanges may be - initiated by a user during an interaction with the TSF, or - the TSF may establish communication with the user via a - trusted path. - - - - This family defines the requirements to establish and - maintain trusted communication to or from users and the - TSF. A trusted path may be required for any - security-relevant interaction. Trusted path exchanges may be - initiated by a user during an interaction with the TSF, or - the TSF may establish communication with the user via a - trusted path. - - - - - - This component should be used when trusted communication - between a user and the TSF is required, either for initial - authentication purposes only or for additional specified - user operations. - - - - , requires that a trusted path - between the TSF and a user be provided for a set of events - defined by a PP/ST author. The user and/or the TSF may - have the ability to initiate the trusted path. - - - Configuring the actions that require trusted path, if - supported. - - - Failures of the trusted path functions. - - - Identification of the user associated with all trusted path - failures, if available. - - - All attempted uses of the trusted path functions. - - - Identification of the user associated with all trusted path - invocations, if available. - - - The TSF shall provide a communication path between itself and - - remote - - local - - the PP/ST author should specify whether the trusted path - must be extended to remote and/or local users. - users that is logically distinct from other communication - paths and provides assured identification of its end points - and protection of the communicated data from - - modification - - disclosure - - other types of integrity or confidentiality violation - - if selected, the PP/ST author should identify any - additional types of integrity or confidentiality - violation against which the trusted path shall protect - the data. - the PP/ST author should specify whether the trusted path - shall protect the data from modification, disclosure, - and/or other types of integrity or confidentiality - violation.. - - - The TSF shall permit - - - the TSF - - - local users - - - remote users - - - - the PP/ST author should specify whether the TSF, local - users, and/or remote users should be able to initiate - the trusted path. - - - to initiate communication via the trusted path. - - - The TSF shall require the use of the trusted path for - - - initial user authentication - - - - - other services for which trusted path is required - - - - if selected, the PP/ST author should identify - other services for which trusted path is required, - if any. - - - - - - the PP/ST author should specify whether the trusted - path is to be used for initial user authentication - and/or for other specified services. - - . - - - - - - - - The class encompasses five - families. These families specify assurance requirements that - are designed to provide confidence that a composed TOE will - operate securely when relying upon security functionality - provided by previously evaluated software, firmware or - hardware components. - - Composition involves taking two or more IT entities - successfully evaluated against CC security assurance - requirements packages (base components and dependent - components, see ) and - combining them for use, with no further development of either - IT entity. The development of additional IT entities is not - included (entities that have not previously been the subject - of a component evaluation). The composed TOE forms a new - product that can be installed and integrated into any specific - environment instance that meets the objectives for the - environment. - - This approach does not provide an alternative approach for the - evaluation of components. Composition under provides a composed TOE integrator a method, which - can be used as an alternative to other assurance levels - specified in the CC, to gain confidence in a TOE that is the - combination of two or more successfully evaluated components - without having to re-evaluate the composite TSF. (The composed - TOE integrator is referred to as ``developer'' throughout the - class, with any references to the - developer of the base or dependent components clarified as - such.) - - Composed Assurance Packages, as defined in Clauses and , is an - assurance scale for composed TOEs. This assurance scale is - required in addition to EALs because to combine components - evaluated against EALs and gain a resulting EAL assurance, all - SARs in the EAL have to be applied to the composed - TOE. Although reuse can be made of the component TOE - evaluation results, there are often additional aspects of the - components that have to be considered in the composed TOE, as - described in Annex . Due to the different parties involved in a - composed TOE evaluation activity it is generally not possible - to gain all necessary evidence about these additional aspects - of the components to apply the appropriate EAL. Hence, CAPs - have been defined to address the issue of combining evaluated - components and gaining a meaningful result. This is discussed - further in . - -
- - - In a composed TOE it is generally the case that one component - relies on the services provided by another component. The - component requiring services is termed the dependent component - and the component providing the services is termed the base - component. This interaction and distinct is discussed further - in Annex B. It is assumed to be the case that the developer of - the dependent component is supporting the composed TOE - evaluation in some manner (as developer, sponsor, or just - cooperating and providing the necessary evaluation evidence - from the dependent component evaluation) The components included in the CAP assurance packages - should not be used as augmentations for component TOE - evaluations, as this would provide no meaningful assurance for - the component. - - The families within the class - interact in a similar manner to the , and classes in a component TOE evaluation and hence - leverage from the specification of requirements from those - classes where applicable. There are however a few items - specific to composed TOE evaluations. To determine how the - components interact and identify any deviations from the - evaluations of the components, the dependencies that the - dependent component has upon the underlying base component are - identified (). This reliance on - the base component is specified in terms of the interfaces - through which the dependent component makes calls for services - in support of the dependent component SFRs. The interfaces, - and at higher levels the supporting behaviour, provided by the - base component in response to those service requests are - analysed in . The family is based on the family, as at the simplest level the - TSF of each component can be viewed as a subsystem of the - composed TOE, with additional portions of each component seen - as additional subsystems. Therefore, the interfaces between - the components are seen as interactions between subsystems in - a component TOE evaluation. - - It is possible that the interfaces and supporting behaviour - descriptions provided for are - incomplete. This is determined during the conduct of . The - family takes the outputs of and - and determines whether the - components are being used in their evaluated configuration and - identifies where any specifications are incomplete, which are - then identified as inputs into testing () and vulnerability analysis () activities of the composed TOE. - - Testing of the composed TOE is performed to determine that the - composed TOE exhibits the expected behaviour as determined by - the composed TOE SFRs, and at higher levels demonstrates the - compatibility of the interfaces between the components of the - composed TOE. - - The vulnerability analysis of the composed TOE leverages from - the outputs of the vulnerability analysis of the component - evaluations. The composed TOE vulnerability analysis considers - any residual vulnerabilities from the component evaluations to - determine that the residual vulnerabilities are not applicable - to the composed TOE. A search of publicly available - information relating to the components is also performed to - identify any issues reported in the components since the - completion of the respective evaluations. - - The interaction between the - families is depicted in Figure below. This shows by solid arrowed lines where - the evidence and understanding gained in one family feeds into - the next activity and the dashed arrows identify where an - activity explicitly traces back to the composed TOE SFRs, as - described above. - -
- - - Further discussion of the definition and interactions within - composed TOEs is provided in . - - - - Assurance class defines - requirements of the information necessary to ensure that two - or more components, which have themselves been the subject of - a CC evaluation, can be integrated in a secure manner. - - The assurance requirements will - be applied to the composed TOE to: - - - determine that the required assurance is provided by the - base component; - - determine that the base component and dependent component - are compatible; and - - search for any vulnerabilities introduced through - composing the base and dependent components into a single - composed TOE entity. - - - - The goal of this activity is to determine whether the - components can be integrated in a secure manner, as defined in - the ST for the composed TOE. This is achieved through - examination and testing of the interfaces between the - components, supported by examination of the design of the - components and the conduct of vulnerability analysis. - - - - The family identifies where - the dependent component is reliant upon IT in its operational - environment (satisfied by a base component in the composed TOE - evaluation) in order to provide its own security - services. This reliance is identified in terms of the - interfaces expected by the dependent component to be provided - by the base component. then - determines which interfaces of the base component were - considered (as TSFI) during the component evaluation of the - base component. - - It should be noted that does - not cover other evidence that may be needed to address the - technical integration problem of composing components - (e.g. descriptions of non-TSF interfaces of the operating - system, rules for integration, etc.). This is outside the - security assessment of the composition and is a functional - composition issue. - - As part of the evaluator will - perform testing of the composed TOE SFRs at the composed TOE - interfaces and of the interfaces of the base component relied - upon by the dependent component to confirm they operate as - specified. The subset selected will consider the possible - effects of changes to the configuration/use of the base - component as used in the composed TOE. These changes are - identified from the configuration of the base component - determined during the base component evaluation. The developer - will provide test evidence for each of the base component - interfaces (the requirements for coverage are consistent with - those applied to the evaluation of the base component). - - requires the evaluator to - determine whether the appropriate assurance measures have been - applied to the base component, and whether the base component - is being used in its evaluated configuration. This includes - determination of whether all security functionality required - by the dependent component was within the TSF of the base - component. The requirement - may be met through the production of evidence that each of - these is demonstrated to be upheld. This evidence may be in - the form of the security target and a public report of the - component evaluation (e.g. certification report). - - If, on the other hand, one of the above have not been upheld, - then it may be possible that an argument can be made as to why - the assurance gained during an original evaluation is - unaffected. If this is not possible then additional evaluation - evidence for those aspects of the base component not covered - may have to be provided. This material is then assessed in - . - - For example, it may be the case as described in the - Interactions between entities (see Annex in CC Part 3) that the - dependent component requires the base component to provide - more security functionality in the composed TOE than included - in the base component evaluation. This would be determined - during the application of the - and families. In this case - the composition rationale evidence provided for would demonstrate that the - assurance gained from the base component evaluation is - unaffected. This may be achieved by means including: - - - Performing a re-evaluation of the base component focusing - on the evidence relating to the extended part of the - TSF; - - Demonstrating that the extended part of the TSF cannot - affect other portions of the TSF, and providing evidence - that the extended part of the TSF provides the necessary - security functionality. - - - - - This family addresses the requirement to demonstrate that - the base component can provide an appropriate level of - assurance for use in composition. - - - - The family is used to - determine whether or not the appropriate assurance measures - have been applied to the base component for successful - integration in the composed TOE. That is, the SARs claimed - by the base component are consistent with the SARs in the - assurance package for the composed TOE. (e.g. if the - assurance package for the composed TOE included , a base component that was - evaluated against would - not have had the appropriate assurance measures applied, as - insufficient design evidence would have been - examined.) - - The family calls for - evidence that the appropriate assurance is provided, without - being specific about how this is achieved. If the - appropriate evidence is not available, then it may be - necessary to report an assessment of the residual risk to - assist consumers of the composed TOE - (e.g. accreditors). This report would need to identify the - change to the base component that may have an effect on the - assurance gained during the original evaluation, along with - any known effects. - - - - - There is only a single component in this family. - - - - - - - - The evaluation evidence for this sub-activity is: - - - the composed ST; - - the composition rationale; - - the reliance information; - - the development information; - - unique identifier. - - - - - The developer shall provide composition rationale for the - base component. - - - The composition rationale shall demonstrate that a level of - assurance at least as high as that of the dependent - component has been obtained for the support functionality of - the base component, when the base component is configured as - required to support the TSF of the dependent component. - - - The evaluator shall confirm that the information meets all - requirements for content and presentation of evidence. - - - - The evaluator shall examine the correspondence analysis - with the development information and the reliance - information to identify the interfaces that are relied - upon by the dependent component which are not detailed - in the development information. - - The evaluator's goal in this work unit is two fold: - - - to determine which interfaces relied upon by the - dependent component have had the appropriate - assurance measures applied. - - to determine that the assurance package applied to - the base component during the base component - evaluation contained either the same assurance - requirements as those in the package applied to the - dependent component during its' evaluation, or - hierarchically higher assurance requirements. - - - The evaluator may use the correspondence tracing in the - development information developed during the activities (e.g. , , ) to - help identify the interfaces identified in the reliance - information that are not considered in the development - information. - - The evaluator will record the SFR-enforcing interfaces - described in the reliance information that are not - included in the development information. These will - provide input to - work unit, helping to identify the portions of the base - component in which further assurance is required. - - If the both the base and dependent components were - evaluated against the same assurance package, then the - determination of whether the level of assurance in the - portions within the base component evaluation is at - least as high as that of the dependent component is - trivial. If however, the assurance packages applied to - the components during the component evaluations differ, - the evaluator needs to determine that the assurance - requirements applied to the base component are all - hierarchically higher to the assurance requirements - applied to the dependent component. - - - - - The evaluator shall examine the composition rationale to - determine, for those included base component interfaces - on which the dependent TSF relies, whether the interface - was considered during the evaluation of the base - component. - - The ST, component public evaluation report (e.g. certification - report) and guidance documents for the base component all - provide information on the scope and boundary of the base - component. The ST provides details of the logical scope and - boundary of the composed TOE, allowing the evaluator to - determine whether an interface relates to a portion of the - product that was within the scope of the evaluation. The - guidance documentation provides details of use of all interfaces - for the composed TOE. Although the guidance documentation may - include details of interfaces in the product that are not within - the scope of the evaluation, any such interfaces should be - identifiable, either from the scoping information in the ST or - through a portion of the guidance that deals with the evaluated - configuration. The public evaluation report may provide any - additional constraints on the use of the composed TOE that are - necessary. - - Therefore, the combination of these inputs allows the - evaluator to determine whether an interface described in - the composition rationale has the necessary assurance - associated with it, or whether further assurance is - required. The evaluator will record those interfaces of - the base component for which additional assurance is - required, for consideration during . - - - - - The evaluator shall examine the composition rationale to - determine that the necessary assurance measures have - been applied to the base component. - - The evaluation verdicts, and resultant assurance, for - the base component can be reused provided the same - portions of the base component are used in the composed - TOE and they are used in a consistent manner. - - In order to determine whether the necessary assurance - measures have already been applied to the component, and - the portions of the component for which assurance - measures still need to be applied, the evaluator should - use the output of the .*.2E action and the work units and : - - - - For those interfaces identified in the reliance - information (), but - not discussed in development information (), additional information - is required. (Identified in .) - - For those interfaces used inconsistently in the - composed TOE from the base component (difference - between the information provided in and the impact of the differences in use - need to be considered. (Identified in .*.2E.) - - For those interfaces identified in composition - rationale for which no assurance has previously been - gained, additional information is - required. (Identified in .) - - For those interfaces consistently described in the - reliance information, composition rationale and the - development information, no further action is - required as the results from the base component - evaluation can be re-used. - - The interfaces of the base component reported to be - required by the reliance information but not included in - the development information indicate the portions of the - base component where further assurance is required. The - interfaces identify the entry points into the base - component. - - For those interfaces included in both the development - information and reliance information, the evaluator is - to determine whether the interfaces are being used in - the composed TOE in a manner that is consistent with the - base component evaluation. The method of use of the - interface will be considered during the activities to determine that - the use of the interface is consistent in both the base - component and the composed TOE. The remaining - consideration is the determination of whether the - configurations of the base component and the composed - TOE are consistent. To determine this, the evaluator - will consider the guidance documentation of each to - ensure they are consistent (see further guidance below - regarding consistent guidance documentation). Any - deviation in the documentation will be further analysed - by the evaluation to determine the possible - effects. - - For those interfaces that are consistently described in - the reliance information and development information, - and for which the guidance is consistent for the base - component and the composed TOE, the required level of - assurance has been provided. - - The following subsubclauses provide guidance on how to - determine consistency between assurance gained in the - base component, the evidence provided for the composed - TOE, and the analysis performed by the evaluator in the - instances where inconsistencies are identified. - - - The reliance information identifies the interfaces in - the dependent component that are to be matched by the - base component. If an interface identified in the - reliance information is not identified in the - development information, then the composition - rationale is to provide a justification of how the - base component provides the required - interfaces. - - If an interface identified in the reliance information - is identified in the development information, but - there are inconsistencies between the descriptions, - further analysis is required. The evaluator identifies - the differences in use of the base component as - considered in the base component evaluation and the - composed TOE evaluation. The evaluator will devise - testing to be performed (during the conduct of ) to test the - interface. - - The patch status of the base and dependent components - as used in the composed TOE should be compared to the - patch status of the components during the component - evaluations. If any patches have been applied to the - components, the composition rationale is to include - details of the patches, including any potential impact - to the SFRs of the evaluated component. The evaluator - should consider the details of the changes provided - and verify the accuracy of the potential impact of the - change on the component SFRs. The evaluator should - then consider whether the changes made by the patch - should be verified through testing, and will identify - the necessary testing approach. The testing may take - the form of repeating the applicable - evaluator/developer testing performed for the - component evaluation of the component or it may be - necessary for the evaluator to devise new tests to - confirm the modified component. - - If any of the individual components have been the - subject of assurance continuity activities since the - completion of the component evaluation, the evaluator - will consider the changes assessed in the assurance - continuity activities during the independent - vulnerability analysis activity for the composed TOE - (in ). - - - - The guidance for the composed TOE is likely to make - substantial reference out to the guidance for the - individual components. The minimal guidance expected - to be necessary is the identification of any ordering - dependencies in the application of guidance for the - dependent and base components, particularly during the - preparation (installation) of the composed TOE. - - In addition to the application of the and families to the guidance for the - composed TOE, it is necessary to analyse the - consistency between the guidance for the components - and the composed TOE, to identify any - deviations. - - If the composed TOE guidance refers out to the base - component and dependent component guidance, then the - consideration for consistency is limited to - consistency between the guidance documentation - provided for each of the components (i.e. consistency - between the base component guidance and the dependent - component guidance). However, if additional guidance - is provided for the composed TOE, to that provided for - the components, greater analysis is required, as - consistency is also required between the guidance - documentation for the components and guidance - documentation for the composed TOE. - - Consistent in this instance is - understood to mean that either the guidance is the - same or it places additional constraints on the - operation of the individual components when combined, - in a similar manner to refinement of - functional/assurance components. - - With the information available (that used as input for - or the development - aspects discussed above) the evaluator may be able to - determine all possible impacts of the deviation from - the configuration of the base component specified in - the component evaluation. However, for high EALs - (where evaluation of the base component included requirements) it is - possible that, unless detailed design abstractions for - the base component are delivered as part of the - development information for the composed TOE, the - possible impacts of the modification to the guidance - cannot be fully determined as the internals are - unknown. In this case the evaluator will report the - residual risk of the analysis. - - These residual risks are to be included in any public - evaluation report for the composed TOE. - - The evaluator will note these variances in the - guidance for input into evaluator independent testing - activities (). - - The guidance for the composed TOE may add to the - guidance for the components, particularly in terms of - installation and the ordering of installation steps - for the base component in relation to the installation - steps for the dependent component. The ordering of - the steps for the installation of the individual - components should not change, however they may need to - be interleaved. The evaluator will examine this - guidance to ensure that it still meets the requirement - of the activity - performed during the evaluations of the - components. - - It may be the case that the reliance information - identifies that interfaces of the base component, in - addition to those identified as TSFIs of the base - component, are relied upon by the dependent component - are identified in the reliance information. It may be - necessary for guidance to be provided for the use of - any such additional interfaces in the base - component. Provided the consumer of the composed TOE - is to receive the guidance documentation for the base - component, then the results of the and - verdicts for the base component can be reused for - those interfaces considered in the evaluation of the - base component. However, for the additional interfaces - relied upon by the dependent component, the evaluator - will need to determine that the guidance documentation - for the base component meets the requirements of and , as applied in the base component - evaluations. - - For those interfaces considered during the base - component evaluation, and therefore, for which - assurance has already been gained, the evaluator will - ensure that the guidance for the use of each interface - for the composed TOE is consistent with that provided - for the base component. To determine the guidance for - the composed TOE is consistent with that for the base - component, the evaluator should perform a mapping for - each interface to the guidance provided for both the - composed TOE and the base component. The evaluator - then compares the guidance to determine - consistency. - - Examples of additional constraints provided in - composed TOE guidance that would be considered to be - consistent with component guidance are (guidance for a - component is given followed by an example of guidance - for a composed TOE that would be considered to provide - additional constraints): - - - Component: The password length must be set to a - minimum of 8 characters length, including - alphabetic and numeric characters. - - Composed TOE: The password length must be set to a - minimum of 10 characters in length, including - alphabetic and numeric characters and at - least one of the following special characters: ( ) - { } ^ < > - _ - - NOTE: It would only be acceptable to increase the - password length to [integer > - 8] characters while removing the mandate - for the inclusion of both alphabetic and numeric - characters for the composed TOE, if the same or a - higher metric was achieved for the strength rating - (taking into account the likelihood of the - password being guessed). - - Component: The following services are to be - disabled in the registry settings: WWW Publishing - Service and ICDBReporter service. - - Composed TOE: The following services are to be - disabled in the registry settings: - Publishing Service, ICDBReporter service, - Remote Procedure Call (RPC) Locator and Procedure - Call (RPC) Service. - - Component: Select the following attributes to be - included in the accounting log files: date, time, - type of event, subject identity and - success/failure. - - Composed TOE: Select the following attributes to - be included in the accounting log files: date, - time, type of event, subject identity, - success/failure, event message and process - thread. - - If the guidance for the composed TOE deviates (is not - a refinement) from that provided for the base - component, the evaluator will assess the potential - risks of the modification to the guidance. The - evaluator will use the information available - (including that provided in the public domain, the - architectural description of the base component in the - public evaluation report (e.g. certification report), - the context of the guidance from the remainder of the - guidance documentation) to identify likely impact of - the modification to the guidance on the SFRs of the - composed TOE. - - If during the dependent component evaluation the trial - installation used the base component to satisfy the - environment requirements of the dependent component - this work unit for the composed TOE is considered to - be satisfied. If the base component was not used in - satisfaction of the work unit during the dependent component - evaluation, the evaluator will apply the user - procedures provided for the composed TOE to prepare - the composed TOE, in accordance with the guidance - specified in . This will allow the evaluator to - determine that the preparative guidance provided for - the composed TOE is sufficient to prepare the composed - TOE and its operational environment securely. - - - - - If there is a different delivery mechanism used for - the delivery of the composed TOE (i.e. the - components are not delivered to the consumer in - accordance with the secure delivery procedures - defined and assessed during the evaluation of the - components), the delivery procedures for the - composed TOE will require evaluation against the - requirements - applied during the components evaluations. - - The composed TOE may be delivered as an integrated - product or may require the components to be - delivered separately. - - If the components are delivered separately, the - results of the delivery of the base component and - dependent component are reused. The delivery of the - base component is checked during the evaluator trial - installation of the dependent component, using the - specified guidance and checking the aspects of - delivery that are the responsibility of the user, as - described in the guidance documentation for the base - component. - - If the composed TOE is delivered as a new entity, - then the method of delivery of that entity must be - considered in the composed TOE evaluation - activities. - - The assessment of the delivery procedures for - composed TOE items is to be performed in accordance - with the methodology for as for any other [component] TOE, - ensuring any additional items (e.g. additional - guidance documents for the composed TOE) are - considered in the delivery procedures. - - - - The unique identification of the composed TOE is - considered during the application of and the items from - which that composed TOE is comprised are considered - during the application of . - - Although additional guidance may be produced for the - composed TOE, the unique identification of this - guidance (considered as part of the unique - identification of the composed TOE during ) is considered - sufficient control of the guidance. - - The verdicts of the remaining (not considered above) - activities can be - reused from the base component evaluation, as no - further development is performed during integration - of the composed TOE. - - There are no additional considerations for - development security as the integration is assumed - to take place at either the consumer's site or, in - the instance that the composed TOE is delivered as - an integrated product, at the site of the dependent - component developer. Control at the consumer's site - is outside the consideration of the CC. No - additional requirements or guidance are necessary if - integration is at the same site as that for the - dependent component, as all components are - considered to be configuration items for the - composed TOE, and should therefore be considered - under the dependent component developer's security - procedures anyway. - - Tools and techniques adopted during integration will - be considered in the evidence provided by the - dependent component developer. Any tools/techniques - relevant to the base component will have been - considered during the evaluation of the base - component. For example, if the base component is - delivered as source code and requires compilation by - the consumer (e.g. dependent component developer who - is performing integration) the compiler would have - been specified and assessed, along with the - appropriate arguments, during evaluation of the base - component. - - There is no life-cycle definition applicable to the - composed TOE, as no further development of items is - taking place. - - The results of flaw remediation for a component are - not applicable to the composed TOE. If flaw - remediation is included in the assurance package for - the composed TOE, then the requirements are to be applied during - the composed TOE evaluation (as for any - augmentation). - - - - - The composed TOE will have been tested during the - conduct of the activities - for evaluation of the dependent component, as the - configurations used for testing of the dependent - component should have included the base component to - satisfy the requirements for IT in the operational - environment. If the base component was not used in the - testing of the dependent component for the dependent - component evaluation, or the configuration of either - component varied from their evaluated configurations, - then the developer testing performed for evaluation of - the dependent component to satisfy the requirements is to be repeated - on the composed TOE. - - - - - - - - - This family sets out requirements for a specification of the - base component in increasing levels of detail. Such - information is required to gain confidence that the - appropriate security functionality is provided to support - the requirements of the dependent component (as identified - in the reliance information). - - - - provides details of the - base component interfaces and internals in increasing levels - of detail, mirroring the level of detail provided by . The application of these two - families will provide the specifications of security - services from each perspective of the TSF making the call - and the TSF servicing the call. - - Having the two descriptions then allows a determination to - be made, as part of the - activities (.*.2E actions), - that these two descriptions are consistent. - - - - The components are levelled on the basis of increasing - amounts of detail about the interfaces provided, and how - they are implemented. - - - - The TSF of the base component is often defined without - knowledge of the dependencies of the possible applications - with which it may by composed. The TSF of this base - component is defined to include all parts of the base - component that have to be relied upon for enforcement of the - base component SFRs. This will include all parts of the base - component required to implement the base component - SFRs. - - The functional specification of the base component will - describe the TSFI in terms of the interfaces the base - component provides to allow an external entity to invoke - operations of the TSF. This includes interfaces to the - human user to permit interaction with the operation of the - TSF invoking SFRs and also interfaces allowing an external - IT entity to make calls into the TSF. - - The functional specification only provides a description of - what the TSF provides at its interface and the means by - which that TSF functionality are invoked. Therefore, the - functional specification does not necessarily provide a - complete interface specification of all possible interfaces - available between an external entity and the base - component. It does not include what the TSF expects/requires - from the operational environment. The description of what a - dependent component TSF relies upon of a base component is - considered in and the - development information evidence provides a response to the - interfaces specified. - - The development information evidence includes a - specification of the base component. This may be the - evidence used during evaluation of the base component to - satisfy the requirements, or may - be another form of evidence produced by either the base - component developer or the composed TOE developer. This - specification of the base component is used during to gain confidence that the - appropriate security functionality is provided to support - the requirements of the dependent component. The level of - detail required of this evidence increases to reflect the - level of required assurance in the composed TOE. This is - expected to broadly reflect the increasing confidence gained - from the application of the assurance packages to the - components. The evaluator determines that this description - of the base component is consistent with the reliance - information provided for the dependent component. - - - - - - A description of the interfaces in the base component, on - which the dependent component relies, is required. This is - examined to determine whether or not it is consistent with - the description of interfaces on which the dependent - component relies, as provided in the reliance - information. - - - - The objective of this sub-activity is to determine that - the appropriate security functionality is provided by the - base component to support the dependent component. This is - achieved through examination of the interfaces of the base - component to determine that they are consistent with the - interfaces specified in the reliance information; those - required by the dependent component. - - The description of the interfaces into the base component - is to be provided at a level of detail consistent with - although not all of the - aspects necessary for satisfaction of are required for , as once the interface has been identified - and the purpose described the remaining detail of the - interface specification can be reused from evaluation of - the base component. - - - - The evaluation evidence for this sub-activity is: - - - the composed ST; - - - the development information; - - - the reliance information. - - - - - The developer shall provide development information for the - base component. - - - The development information shall describe the purpose of - each interface of the base component used in the composed - TOE. - - - The development information shall show correspondence - between the interfaces, used in the composed TOE, of the - base component and the dependent component to support the - TSF of the dependent component. - - - The evaluator shall confirm that the information meets all - requirements for content and presentation of evidence. - - - - The evaluator shall examine the development information - to determine that it describes the purpose of each - interface. - - The base component provides interfaces to support - interaction with the dependent component in the - provision of the dependent TSF. The purpose of each - interface is to be described at the same level as the - description of the interfaces to the dependent component - TSF functionality, as would be provided between - subsystems in the TOE design (). This description is to provide the - reader with an understanding of how the base component - provides the services required by the dependent - component TSF. - - This work unit may be satisfied by the provision of the - functional specification for the base component for - those interfaces that are TSFIs of the base - component. - - - - - The evaluator shall examine the development information - to determine the correspondence, between the interfaces - of the base component and the interfaces on which the - dependent component relies, is accurate. - - The correspondence between the interfaces of the base - component and the interfaces on which the dependent - component relies may take the form of a matrix or - table. The interfaces that are relied upon by the - dependent component are identified in the reliance - information (as examined during activity). - - There is, during this activity, no requirement to - determine completeness of the coverage of interfaces - that are relied upon by the dependent component, only - that the correspondence is correct and ensuring that - interfaces of the base component are mapped to - interfaces required by the dependent component wherever - possible. The completeness of the coverage is considered - in activities. - - - - The evaluator shall determine that the interface description - provided is consistent with the reliance information - provided for the dependent component. - - - The evaluator shall examine the development information - and the reliance information to determine that the - interfaces are described consistently. - - The evaluator's goal in this work unit is to determine - that the interfaces described in the development - information for the base component and the reliance - information for the dependent component are represented - consistently. - - - - - - - - - A description of the interfaces in the base component, on - which the dependent component relies, is required. This is - examined to determine whether or not it is consistent with - the description of interfaces on which the dependent - component relies, as provided in the reliance - information. - - In addition, the security behaviour of the base component - that supports the dependent component TSF is - described. - - - - The objective of this sub-activity is to determine that - the appropriate security functionality is provided by the - base component to support the dependent component. This is - achieved through examination of the interfaces and - associated security behaviour of the base component to - determine that they are consistent with the interfaces - specified in the reliance information; those required by - the dependent component. - - - - The evaluation evidence for this sub-activity is: - - - the composed ST; - - - the development information; - - - reliance information. - - - - - The developer shall provide development information for the - base component. - - - The development information shall describe the purpose and - method of use of each interface of the base component used - in the composed TOE. - - - The development information shall provide a high-level - description of the behaviour of the base component, which - supports the enforcement of the dependent component SFRs. - - - The development information shall show correspondence - between the interfaces, used in the composed TOE, of the - base component and the dependent component to support the - TSF of the dependent component. - - - The evaluator shall confirm that the information meets all - requirements for content and presentation of evidence. - - - - The evaluator shall examine the development information - to determine that it describes the purpose of each - interface. - - The base component provides interfaces to support - interaction with the dependent component in the - provision of the dependent TSF. The purpose of each - interface is to be described at the same level as the - description of the interfaces to the dependent component - TSF functionality, as would be provided between - subsystems in the TOE design (). This description is to provide the - reader with an understanding of how the base component - provides the services required by the dependent - component TSF. - - This work unit may be satisfied by the provision of the - functional specification for the base component for - those interfaces that are TSFIs of the base - component. - - - - - The evaluator shall examine the development information - to determine that it describes the method of use for - each interface. - - The method of use for an interface summarises how the - interface is manipulated in order to invoke the - operations and obtain results associated with the - interface. The evaluator should be able to determine - from reading this material in the development - information how to use each interface. This does not - necessarily mean that there needs to be a separate - method of use for each interface, as it may be possible - to describe in general how APIs are invoked, for - instance, and then identify each interface using that - general style. - - This work unit may be satisfied by the provision of the - functional specification for the base component for - those interfaces that are TSFIs of the base - component. - - - - The evaluator shall examine the development information - to determine that it describes the behaviour of the base - component that supports the enforcement of the dependent - component SFRs. - - The dependent component invokes interfaces of the base - component for the provision of services by the base - component. For the interfaces of the base component that - are invoked, the development information shall provide a - high-level description of the associated security - behaviour of the base component. The description of the - base component security behaviour will outline how the - base component provides the necessary service when the - call to the interface is made. This description is to be - at a level similar to that provided for . Therefore, the provision - of the TOE design evidence from the base component - evaluation would satisfy this work unit, where the - interfaces invoked by the dependent component are TSFI - of the base component. If the interfaces invoked by the - dependent component are not TSFIs of the base component - it is the associated security behaviour will not - necessarily be described in the base component TOE - design evidence. - - - - - The evaluator shall examine the development information - to determine the correspondence, between the interfaces - of the base component and the interfaces on which the - dependent component relies, is accurate. - - The correspondence between the interfaces of the base - component and the interfaces on which the dependent - component relies may take the form of a matrix or - table. The interfaces that are relied upon by the - dependent component are identified in the reliance - information (as examined during ). - - There is, during this activity, no requirement to - determine completeness of the coverage of interfaces - that are relied upon by the dependent component, only - that the correspondence is correct and ensuring that - interfaces of the base component are mapped to - interfaces required by the dependent component wherever - possible. The completeness of the coverage is considered - in activities. - - - - The evaluator shall determine that the interface description - provided is consistent with the reliance information - provided for the dependent component. - - - The evaluator shall examine the development information - and the reliance information to determine that the - interfaces are described consistently. - - The evaluator's goal in this work unit is to determine - that the interfaces described in the development - information for the base component and the reliance - information for the dependent component are represented - consistently. - - - - - - - - A description of the interfaces in the base component, on - which the dependent component relies, is required. This is - examined to determine whether or not it is consistent with - the description of interfaces on which the dependent - component relies, as provided in the reliance - information. - - The interface description of the architecture of the base - component is provided to enable the evaluator to determine - whether or not that interface formed part of the TSF of - the base component. - - - - The objective of this sub-activity is to determine that - the appropriate security functionality is provided by the - base component to support the dependent component. This is - achieved through examination of the interfaces and - associated security behaviour of the base component to - determine that they are consistent with the interfaces - specified in the reliance information; those required by - the dependent component. - - In addition to the interface description, the subsystems - of the base component that provide the security - functionality required by the dependent component will be - described to enable the evaluator to determine whether or - not that interface formed part of the TSF of the base - component. - - - - The evaluation evidence for this sub-activity is: - - - the composed ST; - - - the development information; - - - reliance information. - - - - - The developer shall provide development information for the - base component. - - - The development information shall describe the purpose and - method of use of each interface of the base component used - in the composed TOE. - - - The development information shall identify the subsystems of - the base component that provide interfaces of the base - component used in the composed TOE. - - - The development information shall provide a high-level - description of the behaviour of the base component - subsystems, which support the enforcement of the dependent - component SFRs. - - - The development information shall provide a mapping from the - interfaces to the subsystems of the base component. - - - The development information shall show correspondence - between the interfaces, used in the composed TOE, of the - base component and the dependent component to support the - TSF of the dependent component. - - - The evaluator shall confirm that the information meets all - requirements for content and presentation of evidence. - - - - The evaluator shall examine the development information - to determine that it describes the purpose of each - interface. - - The base component provides interfaces to support - interaction with the dependent component in the - provision of the dependent TSF. The purpose of each - interface is to be described at the same level as the - description of the interfaces to the dependent component - TSF functionality, as would be provided between - subsystems in the TOE design (). This description is to provide the - reader with an understanding of how the base component - provides the services required by the dependent - component TSF. - - This work unit may be satisfied by the provision of the - functional specification for the base component for - those interfaces that are TSFIs of the base - component. - - - - - The evaluator shall examine the development information - to determine that it describes the method of use for - each interface. - - The method of use for an interface summarises how the - interface is manipulated in order to invoke the - operations and obtain results associated with the - interface. The evaluator should be able to determine - from reading this material in the development - information how to use each interface. This does not - necessarily mean that there needs to be a separate - method of use for each interface, as it may be possible - to describe in general how APIs are invoked, for - instance, and then identify each interface using that - general style. - - This work unit may be satisfied by the provision of the - functional specification for the base component for - those interfaces that are TSFIs of the base - component. - - - - The evaluator shall examine the development information - to determine that all subsystems of the base component - that provide interfaces to the dependent component are - identified. - - For those interfaces that are considered to form part of - the TSFI of the base component, the subsystems - associated with the interface will be subsystems - considered in the - activity during the base component evaluation. The - interfaces on which the dependent component relies that - did not form part of the TSFI of the base component will - map to subsystems outside of the base component - TSF. - - - - The evaluator shall examine the development information - to determine that it describes the behaviour of the base - component subsystems that support the enforcement of the - dependent component SFRs. - - The dependent component invokes interfaces of the base - component for the provision of services by the base - component. For the interfaces of the base component that - are invoked, the development information shall provide a - high-level description of the associated security - behaviour of the base component. The description of the - base component security behaviour will outline how the - base component provides the necessary service when the - call to the interface is made. This description is to be - at a level similar to that provided for . Therefore, the provision - of the TOE design evidence from the base component - evaluation would satisfy this work unit, where the - interfaces invoked by the dependent component are TSFI - of the base component. If the interfaces invoked by the - dependent component are not TSFIs of the base component - it is the associated security behaviour will not - necessarily be described in the base component TOE - design evidence. - - - - - The evaluator shall examine the development information - to determine that the correspondence between the - interfaces and subsystems of the base component is - accurate. - - If the TOE design and functional specification evidence - from the base component evaluation is available, this - can be used to verify the accuracy of the correspondence - between the interfaces and subsystems of the base - component as used in the composed TOE. Those interfaces - of the base component, which formed part of the base - component TSFI will be described in the base component - functional specification, and the associated subsystems - will be described in the base component TOE design - evidence. The tracing between the two will be provided - in the base component TOE design evidence. - - If, however, the base component interface did not form - part of the TSFI of the base component, the description - of the subsystem behaviour provided in the development - information will be used to verify the accuracy of the - correspondence. - - - - The evaluator shall examine the development information - to determine the correspondence, between the interfaces - of the base component and the interfaces on which the - dependent component relies, is accurate. - - The correspondence between the interfaces of the base - component and the interfaces on which the dependent - component relies may take the form of a matrix or - table. The interfaces that are relied upon by the - dependent component are identified in the reliance - information (as examined during ). - - There is, during this activity, no requirement to - determine completeness of the coverage of interfaces - that are relied upon by the dependent component, only - that the correspondence is correct and ensuring that - interfaces of the base component are mapped to - interfaces required by the dependent component wherever - possible. The completeness of the coverage is considered - in activities. - - - - The evaluator shall determine that the interface description - provided is consistent with the reliance information - provided for the dependent component. - - - The evaluator shall examine the development information - and the reliance information to determine that the - interfaces are described consistently. - - The evaluator's goal in this work unit is to determine - that the interfaces described in the development - information for the base component and the reliance - information for the dependent component are represented - consistently. - - - - - - - The purpose of this family is to provide evidence that - describes the reliance that a dependent component has upon - the base component. This information is useful to persons - responsible for integrating the component with other - evaluated IT components to form the composed TOE, and for - providing insight into the security properties of the - resulting composition. - - This provides a description of the interface between the - dependent and base components of the composed TOE that may - not have been analysed during evaluation of the individual - components, as the interfaces were not TSFIs of the - individual component TOEs. - - - - The family considers the - interactions between the components where the dependent - component relies upon a service from the base component to - support the operation of security functionality of the - dependent component. The interfaces into these services of - the base component may not have been considered during - evaluation of the base component because the service in the - base component was not considered security-relevant during - evaluation of the component, either because of the inherent - purpose of the service (e.g., adjust type font) or because - associated CC SFRs are not being claimed in the base - component's ST (e.g. the login interface when no SFRs are claimed). These interfaces - into the base component are often viewed as functional - interfaces when evaluating the base component, and are in - addition to the security interfaces (TSFIs) considered in - the functional specification. - - - - The components in this family are levelled according to the - amount of detail provided in the description of the reliance - by the dependent component upon the base component. - - - - The family considers the - interactions between the components where the dependent - component relies upon a service from the base component to - support the operation of security functionality of the - dependent component. The interfaces into these services of - the base component may not have been considered during - evaluation of the base component because the service in the - base component was not considered security-relevant in the - component evaluation, either because of the inherent purpose - of the service (e.g., adjust type font) or because - associated CC SFRs are not being claimed in the base - component's ST (e.g. the login interface when no SFRs are claimed). These interfaces - into the base component are often viewed as functional - interfaces in the evaluation of the base component, and are - in addition to the security interfaces (TSFI) considered in - the functional specification. - - In summary, the TSFIs described in the functional - specification only include the calls made into a TSF by - external entities and responses to those calls. Calls made - by a TSF, which were not explicitly considered during - evaluation of the components, are described by the reliance - information provided to satisfy . - - - - - The objectives of this sub-activity are to determine - whether the developer's reliance evidence provides - sufficient information to determine that the necessary - functionality is available in the base component, and the - means by which that functionality is invoked. These are - provided in terms of a high-level description. - - - - - A dependent component whose TSF interacts with the base - component requires functionality provided by that base - component (e.g., remote authentication, remote audit data - storage). In these cases, those invoked services need to - be described for those charged with configuring the - composed TOE for end users. The rationale for requiring - this documentation is to aid integrators of the composed - TOE to determine what services in the base component might - have adverse effects on the dependent component, and to - provide information against which to determine the - compatibility of the components when applying the family. - - - - The evaluation evidence for this sub-activity is: - - - the composed ST; - - - the dependent component functional specification; - - - the dependent component design; - - - the dependent component architectural design; - - - the reliance information. - - - - - The developer shall provide reliance information of the - dependent component. - - - The reliance information shall describe the functionality of - the base component hardware, firmware and/or software that - is relied upon by the dependent component TSF. - - - The reliance information shall describe all interactions - through which the dependent component TSF requests services - from the base component. - - - The reliance information shall describe how the dependent - TSF protects itself from interference and tampering by the - base component. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check the reliance information to - determine that it describes the functionality of the - base dependent hardware, firmware and/or software that - is relied upon by the dependent component TSF. - - The evaluator assesses the description of the security - functionality that the dependent component TSF requires - to be provided by the base component's hardware, - firmware and software. The emphasis of this work unit is - on the level of detail of this description, rather than - on an assessment of the information's accuracy. (The - assessment of the accuracy of the information is the - focus of the next work unit.) - - This description of the base component's functionality - need not be any more detailed than the level of the - description of a component of the TSF, as would be - provided in the TOE Design () - - - - - The evaluator shall examine the reliance information to - determine that it accurately reflects the objectives - specified for the operational environment of the - dependent component. - - The reliance information contains the description of the - base component's security functionality relied upon by - the dependent component. To ensure that the reliance - information is consistent with the expectations of the - operational environment of the dependent component, the - evaluator compares the reliance information with the - statement of objectives for the environment in the ST - for the dependent component. - - For example, if the reliance information claims that the - dependent component TSF relies upon the base component - to store and protect audit data, yet other evaluation - evidence (e.g. the dependent component design) makes it - clear that the dependent component TSF itself is storing - and protecting the audit data, this would indicate an - inaccuracy. - - It should be noted that the objectives for the - operational environment may include objectives that can - be met by non-IT measures. While the services that the - base component environment is expected to provide may be - described in the description of IT objectives for the - operational environment in the dependent component ST, - it is not required that all such expectations on the - environment be described in the reliance - information. - - - - - The evaluator shall examine the reliance information to - determine that it describes all interactions between the - dependent component and the base component, through - which the dependent component TSF requests services from - the base component. - - The dependent component TSF may request services of the - base component that were not within the TSF of the base - component (see in CC Part - 3). - - The interfaces to the base component's functionality are - described at the same level as the description of the - interfaces to the dependent component TSF functionality, - as would be provided between subsystems in the TOE - design (). - - The purpose of describing the interactions between the - dependent component and the base component is to provide - an understanding of how the dependent component TSF - relies upon the base component for the provision of - services to support the operation of security - functionality of the dependent component. These - interactions do not need to be characterised at the - implementation level (e.g. parameters passed from one - routine in a component to a routine in another - component), but the data elements identified for a - particular component that are going to be used by - another component should be covered in this - description. The statement should help the reader - understand in general why the interaction is - necessary. - - Accuracy and completeness of the interfaces is based on - the security functionality that the TSF requires to be - provided by the base component, as assessed in work - units and . It should be possible to - map all of the functionality described in the earlier - work units to the interfaces identified in this work - unit, and vice versa. An interface that does not - correspond to described functionality would also - indicate an inadequacy. - - - - The evaluator shall examine the reliance information to - determine that it describes how the dependent TSF protects - itself from interference and tampering by the base - component. - - The description of how the dependent component protects - itself from interference and tampering by the base - component is to be provided at the same level of detail - as necessary for . - - - - - - - The objectives of this sub-activity are to determine - whether the developer's reliance evidence provides - sufficient information to determine that the necessary - functionality is available in the base component, and the - means by which that functionality is invoked. This is - provided in terms of the interfaces between the - dependent and base component and the return values from - those interfaces called by the dependent component. - - - - - A dependent component whose TSF interacts with the base - component requires functionality provided by that base - component (e.g., remote authentication, remote audit data - storage). In these cases, those invoked services need to - be described for those charged with configuring the - composed TOE for end users. The rationale for requiring - this documentation is to aid integrators of the composed - TOE to determine what services in the base component might - have adverse effects on the dependent component, and to - provide information against which to determine the - compatibility of the components when applying the family. - - - - The evaluation evidence for this sub-activity is: - - - the composed ST; - - - the dependent component functional specification; - - - the dependent component design; - - - the dependent component implementation representation; - - - the dependent component architectural design; - - - the reliance information. - - - - - The developer shall provide reliance information of the - dependent component. - - - The reliance information shall describe the functionality of - the base component hardware, firmware and/or software that - is relied upon by the dependent component TSF. - - - The reliance information shall describe all interactions - through which the dependent component TSF requests services - from the base component. - - - The reliance information shall describe each interaction in - terms of the interface used and the return values from those - interfaces. - - - The reliance information shall describe how the dependent - TSF protects itself from interference and tampering by the - base component. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check the reliance information to - determine that it describes the functionality of the - base dependent hardware, firmware and/or software that - is relied upon by the dependent component TSF. - - The evaluator assesses the description of the security - functionality that the dependent component TSF requires - to be provided by the base component's hardware, - firmware and software. The emphasis of this work unit is - on the level of detail of this description, rather than - on an assessment of the information's accuracy. (The - assessment of the accuracy of the information is the - focus of the next work unit.) - - This description of the base component's functionality - need not be any more detailed than the level of the - description of a component of the TSF, as would be - provided in the TOE Design () - - - - - The evaluator shall examine the reliance information to - determine that it accurately reflects the objectives - specified for the operational environment of the - dependent component. - - The reliance information contains the description of the - base component's security functionality relied upon by - the dependent component. To ensure that the reliance - information is consistent with the expectations of the - operational environment of the dependent component, the - evaluator compares the reliance information with the - statement of objectives for the environment in the ST - for the dependent component. - - For example, if the reliance information claims that the - dependent component TSF relies upon the base component - to store and protect audit data, yet other evaluation - evidence (e.g. the dependent component design) makes it - clear that the dependent component TSF itself is storing - and protecting the audit data, this would indicate an - inaccuracy. - - It should be noted that the objectives for the - operational environment may include objectives that can - be met by non-IT measures. While the services that the - base component environment is expected to provide may be - described in the description of IT objectives for the - operational environment in the dependent component ST, - it is not required that all such expectations on the - environment be described in the reliance - information. - - - - - The evaluator shall examine the reliance information to - determine that it describes all interactions between the - dependent component and the base component, through - which the dependent component TSF requests services from - the base component. - - The dependent component TSF may request services of the - base component that were not within the TSF of the base - component (see Annex in CC Part - 3). - - The interfaces to the base component's functionality are - described at the same level as the description of the - interfaces to the dependent component TSF functionality, - as would be provided between subsystems in the TOE - design (). - - The purpose of describing the interactions between the - dependent component and the base component is to provide - an understanding of how the dependent component TSF - relies upon the base component for the provision of - services to support the operation of security - functionality of the dependent component. These - interactions do not need to be characterised at the - implementation level (e.g. parameters passed from one - routine in a component to a routine in another - component), but the data elements identified for a - particular component that are going to be used by - another component should be covered in this - description. The statement should help the reader - understand in general why the interaction is - necessary. - - Accuracy and completeness of the interfaces is based on - the security functionality that the TSF requires to be - provided by the base component, as assessed in work - units and . It should be possible to - map all of the functionality described in the earlier - work units to the interfaces identified in this work - unit, and vice versa. An interface that does not - correspond to described functionality would also - indicate an inadequacy. - - - - The reliance information shall describe each interaction - in terms of the interface used and the return values - from those interfaces. - - The identification of the interfaces used by the - dependent component TSF when making services requests of - the base component allows an integrator to determine - whether the base component provides all the necessary - corresponding interfaces. This understanding is further - gained through the specification of the return values - expected by the dependent component. The evaluator - ensures that interfaces are described for each - interaction specified (as analysed in ). - - - - The evaluator shall examine the reliance information to - determine that it describes how the dependent TSF protects - itself from interference and tampering by the base - component. - - The description of how the dependent component protects - itself from interference and tampering by the base - component is to be provided at the same level of detail - as necessary for . - - - - - - - This family requires that testing of composed TOE and - testing of the base component, as used in the composed TOE, - is performed. - - - - The family details - requirements for testing to demonstrate that the composed - TOE operates as specified in the composed TOE SFRs and the - base component interfaces match the design descriptions as - provided in the development information (). Testing evidence is to be provided of all - SFRs specified in the composed TOE ST and to exercise all - base component interfaces used by the dependent component, - as identified in . - - - - The components in this family are levelled on the basis of - increasing rigour of interface testing and increasing rigour - of the analysis of the sufficiency of the tests to - demonstrate that the composed TSF operates in accordance - with the reliance information and the composed TOE - SFRs. - - - - There are two distinct aspects of testing associated with - this family: - - - testing of the interfaces between the base component and - the dependent component, which the dependent component - rely upon for enforcement of security functionality, to - demonstrate their compatibility; - - - testing of the composed TOE to demonstrate that the TOE - behaves in accordance with the SFRs for the composed - TOE. - - - - If the test configurations used during evaluation of the - dependent component included use of the base component as a - ``platform'' and the test analysis sufficiently demonstrates - that the TSF behaves in accordance with the SFRs, the - developer need perform no further testing of the composed - TOE functionality. However, if the base component was not - used in the testing of the dependent component, or the - configuration of either component varied, then the developer - is to perform testing of the composed TOE. This may take - the form of repeating the dependent component developer - testing of the dependent component, provided this adequately - demonstrates the composed TOE TSF behaves in accordance with - the SFRs. - - The developer is to provide evidence of testing the base - component interfaces used in the composition. The operation - of base component TSFIs would have been tested as part of - the activities during - evaluation of the base component. Therefore, provided the - appropriate interfaces were included within the test sample - of the base component evaluation and it was determined in - that the base component is - operating in accordance with the base component evaluated - configuration, with all security functionality required by - the dependent component included in the TSF, the evaluator - action may be met - through reuse of the base component verdicts. - - If this is not the case, the base component interfaces used - relevant to the composition that are affected by any - variations to the evaluated configuration and any additional - security functionally will be tested to ensure they - demonstrate the expected behaviour. The expected behaviour - to be tested is that described in the reliance information - ( evidence). - - - - - - - The objective of this component is to ensure that each - interface of the base component, on which the dependent - component relies, is tested. - - - - The objective of this sub-activity is to determine whether - the developer correctly performed and documented tests for - each of the base component interfaces on which the - dependent component relies. As part of this determination - the evaluator repeats a sample of the tests performed by - the developer and performs any additional tests required - to ensure the expected behaviour of all composed TOE SFRs - and interfaces of the base component relied upon by the - dependent component is demonstrated. - - - - The evaluation evidence for this sub-activity is: - - - the composed TOE suitable for testing; - - - the composed TOE testing evidence; - - - the reliance information; - - - the development information. - - - - - The developer shall provide composed TOE test documentation. - - - The developer shall provide base component interface test - documentation. - - - The developer shall provide the composed TOE for testing. - - - The developer shall provide an equivalent set of resources - to those that were used in the base component developer's - functional testing of the base component. - - - The composed TOE and base component interface test - documentation shall consist of test plans, expected test - results and actual test results. - - - The test documentation from the developer execution of the - composed TOE tests shall demonstrate that the TSF behaves as - specified. - - - The test documentation from the developer execution of the - base component interface tests shall demonstrate that the - base component interface relied upon by the dependent - component behaves as specified. - - - The base component shall be suitable for testing. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the composed TOE test - documentation to determine that it consists of test - plans, expected test results and actual test - results. - - This work unit may be satisfied by provision of the test - evidence from the evaluation of the dependent component - if the base component was used to satisfy the - requirements for IT in the operational environment of - the dependent component. - - All work units necessary for the satisfaction of will be applied to - determine: - - - that the test documentation consist of test plans - expected test results and actual test - results; - - that the test documentation contains the information - necessary to ensure the tests are repeatable; - - the level of developer effort that was applied to - testing of the base component. - - - - - The evaluator shall examine the base component interface - test documentation to determine that it consists of test - plans, expected test results and actual test - results. - - This work unit may be satisfied by provision of the test - evidence from the evaluation of the base component for - those interfaces relied upon in the composed TOE by the - dependent component are TSFIs of the successfully - evaluated base component. The determination of whether - the interfaces of the base component relied upon by the - dependent component were in fact TSFIs of the evaluated - base component is made during the activity. - - All work units necessary for the satisfaction of will be applied to - determine: - - - that the test documentation consist of test plans - expected test results and actual test - results; - - that the test documentation contains the information - necessary to ensure the tests are repeatable; - - the level of developer effort that was applied to - testing of the base component. - - - - - The evaluator shall examine the test documentation to - determine that the developer execution of the composed - TOE tests shall demonstrate that the TSF behaves as - specified. - - The evaluator should construct a mapping between the - tests described in the test plan and the SFRs specified - for the composed TOE to identify which SFRs have been - tested by the developer. - - Guidance on this work unit can be found in: - - - Clause . - - Clause . - - - The outputs from the successful execution of the tests - (as assessed for can - be compared with the mapping to determine that the SFRs - of the composed TOE, as tested by the developer, behave - as expected. - - - - - The evaluator shall examine the test documentation to - determine that the developer execution of the base - component interface tests shall demonstrate that the - base component interfaces relied upon by the dependent - component behave as specified. - - The evaluator should construct a mapping between the - tests described in the test plan and the interfaces of - the base component relied upon by the dependent - component (as specified in the reliance information, - examined under ) to - identify which base component interfaces have been - tested by the developer. - - Guidance on this work unit can be found in: - - - Clause . - - Clause . - - - The outputs from the successful execution of the tests - (as assessed for can - be compared with the mapping to determine that the - interfaces of the base component, as tested by the - developer, behave as expected. - - - - - The evaluator shall examine the composed TOE to - determine that it has been installed properly and is in - a known state. - - To determine that the composed TOE has been installed - properly and is in a known state the and work units will be - applied to the TOE provided by the developer for - testing. - - - - - The evaluator shall examine the set of resources - provided by the developer to determine that they are - equivalent to the set of resources used by the base - component developer to functionally test the base - component. - - To determine that the set of resources provided are - equivalent to those used to functionally test the base - component as used in the composed TOE, the work unit will be - applied. - - - - The evaluator shall execute a sample of test in the test - documentation to verify the developer test results. - - - The evaluator shall perform testing in accordance with , for a subset of the SFRs - specified in the composed security target, to verify the - developer test results. - - The evaluator will apply all work units necessary for - the satisfaction of , reporting in the ETR for the composed TOE - all analysis, results and verdicts as dictated by the - associated work units. - - - - The evaluator shall test a subset of the TSF interfaces of - the composed TOE to confirm that the composed TSF operates - as specified. - - - The evaluator shall perform testing in accordance with , for a subset of the SFRs - specified in the composed security target, to confirm that the - TSF operates as specified. - - The evaluator will apply all work units necessary for - the satisfaction of , reporting in the ETR for the composed TOE - all analysis, results and verdicts as dictated by the - work units. - - When selecting interfaces of the TSF of the composed TOE - to test, the evaluator should take into account any - modifications to the components from the evaluated - version or configuration. Modifications to the component - from that evaluated may include patches introduced, a - different configuration as a result of modified guidance - documentation, reliance an additional portion of the - component that was not within the TSF of the - component. These modifications will have been identified - during the - activity. - - - - - - - - - - The objective of this component is to ensure that each - interface of the base component, on which the dependent - component relies, is tested. - - - - The objective of this sub-activity is to determine whether - the developer correctly performed and documented tests for - each of the base component interfaces on which the - dependent component relies. As part of this determination - the evaluator repeats a sample of the tests performed by - the developer and performs any additional tests required - to fully demonstrate the expected behaviour of the - composed TOE and the interfaces of the base component - relied upon by the dependent component. - - - - The evaluation evidence for this sub-activity is: - - - the composed TOE suitable for testing; - - - the composed TOE testing evidence; - - - the reliance information; - - - the development information. - - - - - The developer shall provide composed TOE test documentation. - - - The developer shall provide base component interface test - documentation. - - - The developer shall provide the composed TOE for testing. - - - The developer shall provide an equivalent set of resources - to those that were used in the base component developer's - functional testing of the base component. - - - The composed TOE and base component interface test - documentation shall consist of test plans, expected test - results and actual test results. - - - The test documentation from the developer execution of the - composed TOE tests shall demonstrate that the TSF behaves as - specified and is complete. - - - The test documentation from the developer execution of the - base component interface tests shall demonstrate that the - base component interface relied upon by the dependent - component behaves as specified and is complete. - - - The base component shall be suitable for testing. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the composed TOE test - documentation to determine that it consists of test - plans, expected test results and actual test - results. - - This work unit may be satisfied by provision of the test - evidence from the evaluation of the dependent component - if the base component was used to satisfy the - requirements for IT in the operational environment of - the dependent component. - - All work units necessary for the satisfaction of will be applied to - determine: - - - that the test documentation consist of test plans - expected test results and actual test - results; - - that the test documentation contains the information - necessary to ensure the tests are repeatable; - - the level of developer effort that was applied to - testing of the base component. - - - - - The evaluator shall examine the base component interface - test documentation to determine that it consists of test - plans, expected test results and actual test - results. - - This work unit may be satisfied by provision of the test - evidence from the evaluation of the base component for - those interfaces relied upon in the composed TOE by the - dependent component are TSFIs of the successfully - evaluated base component. The determination of whether - the interfaces of the base component relied upon by the - dependent component were in fact TSFIs of the evaluated - base component is made during the activity. - - All work units necessary for the satisfaction of will be applied to - determine: - - - that the test documentation consist of test plans - expected test results and actual test - results; - - that the test documentation contains the information - necessary to ensure the tests are repeatable; - - the level of developer effort that was applied to - testing of the base component. - - - - - - - The evaluator shall examine the test documentation to - determine that it provides accurate correspondence - between the tests in the test documentation relating to - the testing of the composed TOE and the composed TOE - SFRs in the composed TOE security target. - - A simple cross-table may be sufficient to show test - correspondence. The identification of correspondence - between the tests and SFRs presented in the test - documentation has to be unambiguous. - - - - - The evaluator shall examine the test documentation to - determine that the developer execution of the composed - TOE tests shall demonstrate that the TSF behaves as - specified. - - Guidance on this work unit can be found in: - - - Clause . - - Clause . - - - - The outputs from the successful execution of the tests - (as assessed for can - be compared with the mapping to determine that the SFRs - of the composed TOE, as tested by the developer, behave - as expected. - - - - - The evaluator shall examine the test documentation to - determine that it provides accurate correspondence - between the tests in the test documentation relating to - the testing of the base component interfaces relied upon - by the dependent component and the interfaces specified - in the reliance information. - - A simple cross-table may be sufficient to show test - correspondence. The identification of correspondence - between the tests and interfaces presented in the test - documentation has to be unambiguous. - - - - - The evaluator shall examine the test documentation to - determine that the developer execution of the base - component interface tests shall demonstrate that the - base component interfaces relied upon by the dependent - component behave as specified. - - Guidance on this work unit can be found in: - - - Clause . - - Clause . - - - The outputs from the successful execution of the tests - (as assessed for can - be compared with the mapping to determine that the - interfaces of the base component, as tested by the - developer, behave as expected. - - - - - The evaluator shall examine the composed TOE to - determine that it has been installed properly and is in - a known state. - - To determine that the composed TOE has been installed - properly and is in a known state the and work units will be - applied to the TOE provided by the developer for - testing. - - - - - The evaluator shall examine the set of resources - provided by the developer to determine that they are - equivalent to the set of resources used by the base - component developer to functionally test the base - component. - - To determine that the set of resources provided are - equivalent to those used to functionally test the base - component as used in the composed TOE, the work unit will be - applied. - - - - The evaluator shall execute a sample of test in the test - documentation to verify the developer test results. - - - The tests are to be selected and executed in accordance - with , to - demonstrate the correct behaviour of the SFRs specified - in the composed TOE security target. - - The evaluator will apply all work units necessary for - the satisfaction of , reporting in the ETR for the composed TOE - all analysis, results and verdicts as dictated by the - associated work units. - - - - The evaluator shall test a subset of the TSF interfaces of - the composed TOE to confirm that the composed TSF operates - as specified. - - - The evaluator shall perform testing in accordance with , for a subset of the SFRs - specified in the composed security target, to confirm that the - TSF operates as specified. - - The evaluator will apply all work units necessary for - the satisfaction of , reporting in the ETR for the composed TOE - all analysis, results and verdicts as dictated by the - work units. - - When selecting interfaces of the TSF of the composed TOE - to test, the evaluator should take into account any - modifications to the components from the evaluated - version or configuration. Modifications to the component - from that evaluated may include patches introduced, a - different configuration as a result of modified guidance - documentation, reliance an additional portion of the - component that was not within the TSF of the - component. These modifications will have been identified - during the - activity. - - - - The evaluator shall perform testing, in accordance with - , for a subset of the - interfaces to the base component to confirm they operate - as specified. - - The evaluator will apply all work units necessary for - the satisfaction of , reporting in the ETR for the composed TOE - all analysis, results and verdicts as dictated by the - work units. - - When selecting interfaces of the base component to test, - the evaluator should take into account any modifications - to the base component from the evaluated version or - configuration. In particular, the evaluator should - consider the development of tests to demonstrate the - correct behaviour of interfaces of the base component - that were not considered during the evaluation of the - base component. These additional interfaces and other - modifications to the base component will have been - identified during the - activity. - - - - - - - - This family calls for an analysis of vulnerability - information available in the public domain and of - vulnerabilities that may be introduced as a result of the - composition. - - - - The vulnerability analysis in includes determination of two different - aspects of resistance by the composed TOE, namely: - - - Residual vulnerabilities in the base and dependent - components remain unexploitable in the operational - environment of the composed TOE; - - The composed TOE is resistant to attackers with a given - level of attack potential. - - - - The components in this family are levelled on the basis of - increasing scrutiny of vulnerability information from the - public domain and independent vulnerability analysis. - - - - The developer will provide details of any residual - vulnerabilities reported during evaluation of the - components. These may be gained from the component - developers or evaluation reports for the components. These - will be used as inputs into the evaluator's vulnerability - analysis of the composed TOE in the operational - environment. - - - The operational environment of the composed TOE is examined - to ensure that the assumptions and objectives for the - component operational environment (specified in each - component ST) are satisfied in the composed TOE. An initial - analysis of the consistency of assumptions and objectives - between the components and the composed TOE STs will have - been performed during the conduct of the activities for the composed TOE. However, this - analysis is revisited with the knowledge acquired during the - , and the - activities to ensure that, for example, assumptions of the - dependent component that were addressed by the environment - in the dependent component ST are not reintroduced as a - result of composition (i.e. that the base component - adequately addresses the assumptions of the dependent - component ST in the composed TOE). - - A search by the evaluator for issues in each component will - identify potential vulnerabilities reported in the public - domain since completion of the evaluation of the components. - Any potential vulnerabilities will then be subject to - testing. - - If the base component used in the composed TOE has been the - subject of assurance continuity activities since - certification, the evaluator will consider during the - composed TOE vulnerability analysis activities the changes - made in base component. - - - - - - The objective of this sub-activity is to determine whether - the composed TOE, in its operational environment, has - easily exploitable vulnerabilities. - - The developer provides details of any residual - vulnerabilities reported from evaluation of the - components. The evaluator performs an analysis of the - disposition the residual vulnerabilities reported and also - performs a search of the public domain, to identify any - new potential vulnerabilities in the components - (i.e. those issues that have been reported in the public - domain since evaluation of the base component). The - evaluator then performs penetration testing to demonstrate - that the potential vulnerabilities cannot be exploited in - the TOE, in its operational environment, by an attacker - with basic attack potential. - - - - See the application notes for . - - - - The evaluation evidence for this sub-activity is: - - - the composed TOE suitable for testing; - - - the composed ST; - - - the composition rationale; - - - the guidance documentation; - - - information publicly available to support the - identification of possible security vulnerabilities; - - - residual vulnerabilities reported during evaluation of - each component. - - - - - The developer shall provide the composed TOE for testing. - - - The composed TOE shall be suitable for testing. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - The evaluator shall examine the composed TOE to - determine that it has been installed properly and is in - a known state. - - To determine that the composed TOE has been installed - properly and is in a known state the and work units will be - applied to the composed TOE. - - If the assurance package includes a component from the - family, then the - evaluator may refer to the result of the work unit *-1 to demonstrate this has been - satisfied. - - - - The evaluator shall examine the composed TOE - configuration to determine that any assumptions and - objectives in the STs the components relating to IT - entities for are fulfilled by the other - components. - - The STs for the component may include assumptions about - other components that may use the component to which the - ST relates, e.g. the ST for an operating system used as - a base component may include an assumption that any - applications loaded on the operating system do not run - in privileged mode. These assumptions and objectives are - to be fulfilled by other components in the composed - TOE. - - - - The evaluator shall perform an analysis to determine that - any residual vulnerabilities identified for the base and - dependent components are not exploitable in the composed TOE - in its operational environment. - - - The evaluator shall examine the residual vulnerabilities - from the base component evaluation to determine that - they are not exploitable in the composed TOE in its - operational environment. - - The list of vulnerabilities identified in the product - during the evaluation of the base component, which were - demonstrated to be non-exploitable in the base - component, is to be used as an input into this - activity. The evaluator will determine that the - premise(s) on which a vulnerability was deemed to be - non-exploitable is upheld in the composed TOE, or - whether the combination has re-introduced the potential - vulnerability. For example, if during evaluation of the - base component it was assumed that a particular - operating system service was disabled, which is enabled - in the composed TOE evaluation, any potential - vulnerabilities relating to that service previously - scoped out should now be considered. - - Also, this list of known, non-exploitable - vulnerabilities resulting from the evaluation of the - base component should be considered in the light of any - known, non-exploitable vulnerabilities for the other - components (e.g. dependent component) within the - composed TOE. This is to consider the case where a - potential vulnerability that is non-exploitable in - isolation is exploitable when integrated with an IT - entity containing another potential - vulnerability. - - - - The evaluator shall examine the residual vulnerabilities - from the dependent component evaluation to determine - that they are not exploitable in the composed TOE in its - operational environment. - - The list of vulnerabilities identified in the product - during the evaluation of the dependent component, which - were demonstrated to be non-exploitable in the dependent - component, is to be used as an input into this - activity. The evaluator will determine that the - premise(s) on which a vulnerability was deemed to be - non-exploitable is upheld in the composed TOE, or - whether the combination has re-introduced the potential - vulnerability. For example, if during evaluation of the - dependent component it was assumed that IT meeting the - operational environment requirements would not return a - certain value in response to a service request, which is - provided by the base component in the composed TOE - evaluation, any potential vulnerabilities relating to - that return value previously scoped out should now be - considered. - - Also, this list of known, non-exploitable - vulnerabilities resulting from the evaluation of the - dependent component should be considered in the light of - any known, non-exploitable vulnerabilities for the other - components (e.g. base component) within the composed - TOE. This is to consider the case where a potential - vulnerability that is non-exploitable in isolation is - exploitable when integrated with an IT entity containing - another potential vulnerability. - - - - The evaluator shall perform a search of public domain - sources to identify possible vulnerabilities arising from - use of the base and dependent components in the composed TOE - operational environment. - - - The evaluator shall examine the sources of information - publicly available to support the identification of - possible security vulnerabilities in the base component - that have become known since the completion of - evaluation of the base component. - - The evaluator will use the information in the public - domain as described in to search for vulnerabilities in the base - component. - - Those potential vulnerabilities that were publicly - available prior to the evaluation of the base component - do not have to be further investigated unless it is - apparent to the evaluator that the attack potential - required by an attacker to exploit the potential - vulnerability has been significantly reduced. This may - be through the introduction of some new technology since - the base component evaluation that means the - exploitation of the potential vulnerability has been - simplified. - - - - The evaluator shall examine the sources of information - publicly available to support the identification of - possible security vulnerabilities in the dependent - component that have become known since the completion of - the dependent component evaluation. - - The evaluator will use the information in the public - domain as described in to search for vulnerabilities in the - dependent component. - - Those potential vulnerabilities that were publicly - available prior to the evaluation of the dependent - component do not have to be further investigated unless - it is apparent to the evaluator that the attack - potential required by an attacker to exploit the - potential vulnerability has been significantly - reduced. This may be through the introduction of some - new technology since evaluation of the dependent - component that means the exploitation of the potential - vulnerability has been simplified. - - - - The evaluator shall record in the ETR the identified - potential security vulnerabilities that are candidates - for testing and applicable to the composed TOE in its - operational environment. - - The ST, guidance documentation and functional - specification are used to determine whether the - vulnerabilities are relevant to the composed TOE in its - operational environment. - - The evaluator records any reasons for exclusion of - vulnerabilities from further consideration if the - evaluator determines that the vulnerability is not - applicable in the operational environment. Otherwise the - evaluator records the potential vulnerability for - further consideration. - - A list of potential vulnerabilities applicable to the - composed TOE in its operational environment, which can - be used as an input into penetration testing activities - (i.e. ), shall be - reported in the ETR by the evaluators. - - - - The evaluator shall conduct penetration testing, based on - the identified vulnerabilities, to demonstrate that the - composed TOE is resistant to attacks by an attacker with - basic attack potential. - - - The evaluator shall conduct penetration testing as - detailed for . - - The evaluator will apply all work units necessary for - the satisfaction of evaluator action , reporting in the ETR - for the composed TOE all analysis and verdicts as - dictated by the work units. - - The evaluator will also apply the work units for the - evaluator action - to determine that the composed TOE provided by the - developer is suitable for testing. - - - - - - - - - The objective of this sub-activity is to determine whether - the composed TOE, in its operational environment, has - vulnerabilities exploitable by attackers possessing basic - attack potential. - - The developer provides an analysis of the disposition of - any residual vulnerabilities reported for the components - and of any vulnerabilities introduced through the - combination of the base and dependent components. The - evaluator performs a search of the public domain to - identify any new potential vulnerabilities in the - components (i.e. those issues that have been reported in - the public domain since the completion of the evaluation - of the components). The evaluator will also perform an - independent vulnerability analysis of the composed TOE and - penetration testing. - - - - See the application notes for . - - - - The evaluation evidence for this sub-activity is: - - - the composed TOE suitable for testing; - - - the composed ST; - - - the composition rationale; - - the reliance information; - - - the guidance documentation; - - - information publicly available to support the - identification of possible security vulnerabilities. - - - residual vulnerabilities reported during evaluation of - each component. - - - - - The developer shall provide the composed TOE for testing. - - - The composed TOE shall be suitable for testing. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - The evaluator shall examine the composed TOE to - determine that it has been installed properly and is in - a known state. - - To determine that the composed TOE has been installed - properly and is in a known state the and work units will be - applied to the composed TOE. - - If the assurance package includes family, then the evaluator may refer to the - result of the work unit *-1 to demonstrate this has been - satisfied. - - - - The evaluator shall examine the composed TOE - configuration to determine that any assumptions and - objectives in the STs the components relating to IT - entities for are fulfilled by the other - components. - - The STs for the component may include assumptions about - other components that may use the component to which the - ST relates, e.g. the ST for an operating system used as - a base component may include an assumption that any - applications loaded on the operating system do not run - in privileged mode. These assumptions and objectives are - to be fulfilled by other components in the composed - TOE. - - - - The evaluator shall perform an analysis to determine that - any residual vulnerabilities identified for the base and - dependent components are not exploitable in the composed TOE - in its operational environment. - - - The evaluator shall examine the residual vulnerabilities - from the base component evaluation to determine that - they are not exploitable in the composed TOE in its - operational environment. - - The list of vulnerabilities identified in the product - during the evaluation of the base component, which were - demonstrated to be non-exploitable in the base - component, is to be used as an input into this - activity. The evaluator will determine that the - premise(s) on which a vulnerability was deemed to be - non-exploitable is upheld in the composed TOE, or - whether the combination has re-introduced the potential - vulnerability. For example, if during evaluation of the - base component it was assumed that a particular - operating system service was disabled, which is enabled - in the composed TOE evaluation, any potential - vulnerabilities relating to that service previously - scoped out should now be considered. - - Also, this list of known, non-exploitable - vulnerabilities resulting from the evaluation of the - base component should be considered in the light of any - known, non-exploitable vulnerabilities for the other - components (e.g. dependent component) within the - composed TOE. This is to consider the case where a - potential vulnerability that is non-exploitable in - isolation is exploitable when integrated with an IT - entity containing another potential - vulnerability. - - - - The evaluator shall examine the residual vulnerabilities - from the dependent component evaluation to determine - that they are not exploitable in the composed TOE in its - operational environment. - - The list of vulnerabilities identified in the product - during the evaluation of the dependent component, which - were demonstrated to be non-exploitable in the dependent - component, is to be used as an input into this - activity. The evaluator will determine that the - premise(s) on which a vulnerability was deemed to be - non-exploitable is upheld in the composed TOE, or - whether the combination has re-introduced the potential - vulnerability. For example, if during evaluation of the - dependent component it was assumed that IT meeting the - operational environment requirements would not return a - certain value in response to a service request, which is - provided by the base component in the composed TOE - evaluation, any potential vulnerabilities relating to - that return value previously scoped out should now be - considered. - - Also, this list of known, non-exploitable - vulnerabilities resulting from the evaluation of the - dependent component should be considered in the light of - any known, non-exploitable vulnerabilities for the other - components (e.g. base component) within the composed - TOE. This is to consider the case where a potential - vulnerability that is non-exploitable in isolation is - exploitable when integrated with an IT entity containing - another potential vulnerability. - - - - The evaluator shall perform a search of public domain - sources to identify possible vulnerabilities arising from - use of the base and dependent components in the composed TOE - operational environment. - - - The evaluator shall examine the sources of information publicly - available to support the identification of possible security - vulnerabilities in the base component that have become known - since the completion of the base component evaluation. - - The evaluator will use the information in the public - domain as described in to search for vulnerabilities in the base - component. - - Those potential vulnerabilities that were publicly - available prior to the evaluation of the base component - do not have to be further investigated unless it is - apparent to the evaluator that the attack potential - required by an attacker to exploit the potential - vulnerability has been significantly reduced. This may - be through the introduction of some new technology since - the base component evaluation that means the - exploitation of the potential vulnerability has been - simplified. - - - - The evaluator shall examine the sources of information - publicly available to support the identification of - possible security vulnerabilities in the dependent - component that have become known since the completion of - the dependent component evaluation. - - The evaluator will use the information in the public domain as - described in to search for - vulnerabilities in the dependent component. - - Those potential vulnerabilities that were publicly - available prior to the evaluation of the dependent - component do not have to be further investigated unless - it is apparent to the evaluator that the attack - potential required by an attacker to exploit the - potential vulnerability has been significantly - reduced. This may be through the introduction of some - new technology since evaluation of the dependent - component that means the exploitation of the potential - vulnerability has been simplified. - - - - The evaluator shall record in the ETR the identified - potential security vulnerabilities that are candidates - for testing and applicable to the composed TOE in its - operational environment. - - The ST, guidance documentation and functional - specification are used to determine whether the - vulnerabilities are relevant to the composed TOE in its - operational environment. - - The evaluator records any reasons for exclusion of - vulnerabilities from further consideration if the - evaluator determines that the vulnerability is not - applicable in the operational environment. Otherwise the - evaluator records the potential vulnerability for - further consideration. - - A list of potential vulnerabilities applicable to the - composed TOE in its operational environment, which can - be used as an input into penetration testing activities - (), shall be - reported in the ETR by the evaluators. - - - - The evaluator shall perform an independent vulnerability - analysis of the composed TOE, using the guidance - documentation, reliance information and composition - rationale to identify potential vulnerabilities in the - composed TOE. - - - The evaluator shall conduct a search of the composed TOE - ST, guidance documentation, reliance information and - composition rationale to identify possible security - vulnerabilities in the composed TOE. - - The consideration of the components of the composed TOE - in the independent evaluator vulnerability analysis will - take a slightly different form to that documented in - for a component - evaluation, as it will not necessarily consider all - layers of design abstraction relevant to the assurance - package. These will have already been considered during - the evaluation of the components, but the evidence may - not be available for the composed TOE - evaluation. However, the general approach described in - the work units associated with is applicable and should form the basis of - the evaluator's search for potential vulnerabilities in - the composed TOE. - - A vulnerability analysis of the individual components - used in the composed TOE will have already been - performed during evaluation of the individual - components. The focus of the vulnerability analysis - during the composed TOE evaluation is to identify any - vulnerabilities introduced as a result of the - integration of the components or due to any changes in - the use of the components between the evaluated - component configuration to the composed TOE - configuration. - - The evaluator will use the understanding of the - component's construction as detailed in the reliance - information for the dependent component, and the - development information and composition rationale for - the base component, together with the dependent - component design information. This information will - allow the evaluator to gain an understanding of how the - base component and dependent component interact and - identify potential vulnerabilities that may be - introduced as a result of this interaction. - - The evaluator will consider any new guidance provided - for the installation, start-up and operation of the - composed TOE to identify any potential vulnerabilities - introduced through this revised guidance. - - If any of the individual components have been through - assurance continuity activities since the completion of - the component evaluation, the evaluator will consider - the patch(es) in the independent vulnerability - analysis. Information related to the change provided in - a public report of the assurance continuity activities - (e.g. Maintenance Report) will be the main source of - input material of the change. This will be supplemented - by any updates to the guidance documentation resulting - from the change and any information regarding the change - available in the public domain, e.g. vendor - website. - - Any risks identified due to the lack of evidence to - establish the full impact of any patches or deviations - in the configuration of a component from the evaluated - configuration are to be documented in the evaluator's - vulnerability analysis. - - - - The evaluator shall conduct penetration testing, based on - the identified vulnerabilities, to demonstrate that the - composed TOE is resistant to attacks by an attacker with - basic attack potential. - - - The evaluator shall conduct penetration testing as - detailed for . - - The evaluator will apply all work units necessary for - the satisfaction of evaluator action , reporting in the ETR - for the composed TOE all analysis and verdicts as - dictated by the work units. - - The evaluator will also apply the work units for the - evaluator action - to determine that the composed TOE provided by the - developer is suitable for testing. - - - - - - - - - The objective of this sub-activity is to determine whether the - composed TOE, in its operational environment, has - vulnerabilities exploitable by attackers possessing - Enhanced-Basic attack potential. - - The developer provides an analysis of the disposition of - any residual vulnerabilities reported for the components - and of any vulnerabilities introduced through the - combination of the base and dependent components. The - evaluator performs a search of the public domain to - identify any new potential vulnerabilities in the - components (i.e. those issues that have been reported in - the public domain since the completion of the component - evaluations). The evaluator will also perform an - independent vulnerability analysis of the composed TOE and - penetration testing. - - - - See the application notes for . - - - - The evaluation evidence for this sub-activity is: - - - the composed TOE suitable for testing; - - - the composed ST; - - - the composition rationale; - - - the reliance information; - - - the guidance documentation; - - - information publicly available to support the - identification of possible security vulnerabilities. - - - residual vulnerabilities reported during evaluation of - each component. - - - - - The developer shall provide the composed TOE for testing. - - - The composed TOE shall be suitable for testing. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - The evaluator shall examine the composed TOE to - determine that it has been installed properly and is in - a known state. - - To determine that the composed TOE has been installed - properly and is in a known state the and work units will be - applied to the composed TOE. - - If the assurance package includes family, then the evaluator may refer to the - result of the work unit *-1 to demonstrate this has been - satisfied. - - - - The evaluator shall examine the composed TOE - configuration to determine that any assumptions and - objectives in the STs the components relating to IT - entities for are fulfilled by the other - components. - - The STs for the component may include assumptions about - other components that may use the component to which the - ST relates, e.g. the ST for an operating system used as - a base component may include an assumption that any - applications loaded on the operating system do not run - in privileged mode. These assumptions and objectives are - to be fulfilled by other components in the composed - TOE. - - - - The evaluator shall perform an analysis to determine that - any residual vulnerabilities identified for the base and - dependent components are not exploitable in the composed TOE - in its operational environment. - - - The evaluator shall examine the residual vulnerabilities - from the base component evaluation to determine that - they are not exploitable in the composed TOE in its - operational environment. - - The list of vulnerabilities identified in the product - during the evaluation of the base component, which were - demonstrated to be non-exploitable in the base - component, is to be used as an input into this - activity. The evaluator will determine that the - premise(s) on which a vulnerability was deemed to be - non-exploitable is upheld in the composed TOE, or - whether the combination has re-introduced the potential - vulnerability. For example, if during evaluation of the - base component it was assumed that a particular - operating system service was disabled, which is enabled - in the composed TOE evaluation, any potential - vulnerabilities relating to that service previously - scoped out should now be considered. - - Also, this list of known, non-exploitable - vulnerabilities resulting from the evaluation of the - base component should be considered in the light of any - known, non-exploitable vulnerabilities for the other - components (e.g. dependent component) within the - composed TOE. This is to consider the case where a - potential vulnerability that is non-exploitable in - isolation is exploitable when integrated with an IT - entity containing another potential - vulnerability. - - - - The evaluator shall examine the residual vulnerabilities - from the dependent component evaluation to determine - that they are not exploitable in the composed TOE in its - operational environment. - - The list of vulnerabilities identified in the product - during the evaluation of the dependent component, which - were demonstrated to be non-exploitable in the dependent - component, is to be used as an input into this - activity. The evaluator will determine that the - premise(s) on which a vulnerability was deemed to be - non-exploitable is upheld in the composed TOE, or - whether the combination has re-introduced the potential - vulnerability. For example, if during evaluation of the - dependent component it was assumed that IT meeting the - operational environment requirements would not return a - certain value in response to a service request, which is - provided by the base component in the composed TOE - evaluation, any potential vulnerabilities relating to - that return value previously scoped out should now be - considered. - - Also, this list of known, non-exploitable - vulnerabilities resulting from the evaluation of the - dependent component should be considered in the light of - any known, non-exploitable vulnerabilities for the other - components (e.g. base component) within the composed - TOE. This is to consider the case where a potential - vulnerability that is non-exploitable in isolation is - exploitable when integrated with an IT entity containing - another potential vulnerability. - - - - The evaluator shall perform a search of public domain - sources to identify possible vulnerabilities arising from - use of the base and dependent components in the composed TOE - operational environment. - - - The evaluator shall examine the sources of information publicly - available to support the identification of possible security - vulnerabilities in the base component that have become known - since the completion of the base component evaluation. - - The evaluator will use the information in the public - domain as described in to search for vulnerabilities in the base - component. - - Those potential vulnerabilities that were publicly - available prior to the evaluation of the base component - do not have to be further investigated unless it is - apparent to the evaluator that the attack potential - required by an attacker to exploit the potential - vulnerability has been significantly reduced. This may - be through the introduction of some new technology since - the base component evaluation that means the - exploitation of the potential vulnerability has been - simplified. - - - - The evaluator shall examine the sources of information - publicly available to support the identification of - possible security vulnerabilities in the dependent - component that have become known since completion of the - dependent component evaluation. - - The evaluator will use the information in the public domain as - described in to search for - vulnerabilities in the dependent component. - - Those potential vulnerabilities that were publicly - available prior to the evaluation of the dependent - component do not have to be further investigated unless - it is apparent to the evaluator that the attack - potential required by an attacker to exploit the - potential vulnerability has been significantly - reduced. This may be through the introduction of some - new technology since evaluation of the dependent - component that means the exploitation of the potential - vulnerability has been simplified. - - - - The evaluator shall record in the ETR the identified - potential security vulnerabilities that are candidates - for testing and applicable to the composed TOE in its - operational environment. - - The ST, guidance documentation and functional - specification are used to determine whether the - vulnerabilities are relevant to the composed TOE in its - operational environment. - - The evaluator records any reasons for exclusion of - vulnerabilities from further consideration if the - evaluator determines that the vulnerability is not - applicable in the operational environment. Otherwise the - evaluator records the potential vulnerability for - further consideration. - - A list of potential vulnerabilities applicable to the - composed TOE in its operational environment, which can - be used as an input into penetration testing activities - (), shall be - reported in the ETR by the evaluators. - - - - The evaluator shall perform an independent vulnerability - analysis of the composed TOE, using the guidance - documentation, reliance information and composition - rationale to identify potential vulnerabilities in the - composed TOE. - - - The evaluator shall conduct a search of the composed TOE - ST, guidance documentation, reliance information and - composition rationale to identify possible security - vulnerabilities in the composed TOE. - - The consideration of the components in the independent - evaluator vulnerability analysis will take a slightly - different form to that documented in for a component - evaluation, as it will not necessarily consider all - layers of design abstraction relevant to the assurance - package. These will have already been considered during - the evaluation of the base component, but the evidence - may not be available for the composed TOE - evaluation. However, the general approach described in - the work units associated with is applicable and should form the basis of - the evaluator's search for potential vulnerabilities in - the composed TOE. - - A vulnerability analysis of the individual components - used in the composed TOE will have already been - performed during evaluation of the components. The focus - of the vulnerability analysis during the composed TOE - evaluation is to identify any vulnerabilities introduced - as a result of the integration of the components or due - to any changes in the use of the components between the - configuration of the component determined during the - component evaluation and the composed TOE - configuration. - - The evaluator will use the understanding of the - component's construction as detailed in the reliance - information for the dependent component, and the - composition rationale and development information for - the base component, together with the dependent - component design information. This information will - allow the evaluator to gain an understanding of how the - base component and dependent component interact. - - The evaluator will consider any new guidance provided - for the installation, start-up and operation of the - composed TOE to identify any potential vulnerabilities - introduced through this revised guidance. - - If any of the individual components have been through - assurance continuity activities since the completion of - the component evaluation, the evaluator will consider - the patch in the independent vulnerability - analysis. Information related to the change provided in - a public report of the assurance continuity activities - (e.g. Maintenance Report). This will be supplemented by - any updates to the guidance documentation resulting from - the change and any information regarding the change - available in the public domain, e.g. vendor - website. - - Any risks identified due to the lack of evidence to - establish the full impact of any patches or deviations - in the configuration of a component from the evaluated - configuration are to be documented in the evaluator's - vulnerability analysis. - - - - The evaluator shall conduct penetration testing, based on the - identified vulnerabilities, to demonstrate that the composed TOE - is resistant to attacks by an attacker with Enhanced-Basic - attack potential. - - The evaluator shall conduct penetration testing as detailed - for . - The evaluator will apply all work units necessary for the - satisfaction of evaluator action , reporting in the ETR for the composed TOE all - analysis and verdicts as dictated by the work units. - The evaluator will also apply the work units for the - evaluator action to - determine that the composed TOE provided by the developer is - suitable for testing. - - - - - - - The requirements of the Development class provide information - about the TOE. The knowledge obtained by this information is - used as the basis for conducting vulnerability analysis and - testing upon the TOE, as described in the and classes. - - The Development class encompasses six families of requirements - for structuring and representing the TSF at various levels and - varying forms of abstraction. These families include: - - requirements for the description (at the various - levels of abstraction) of the design and implementation of - the SFRs (, , ) - requirements for the description of the - architecture-oriented features of domain separation, TSF - self-protection and non-bypassability of the security - functionality () - requirements for a security policy model and for correspondence - mappings between security policy model and the functional - specification () - requirements on the internal structure of the TSF, - which covers aspects such as modularity, layering, and - minimisation of complexity () - - When documenting the security functionality of a TOE, there - are two properties that need to be demonstrated. The first - property is that the security functionality works correctly; - that is, it performs as specified. The second property, and - one that is arguably harder to demonstrate, is that the TOE - cannot be used in a way such that the security functionality - can be corrupted or bypassed. These two properties require - somewhat different approaches in analysis, and so the families - in are structured to support these - different approaches. The families , , , and deal with the first property: the specification - of the security functionality. The families and deal with - the second property: the specification of the design of the - TOE demonstrating the security functionality cannot be - corrupted or bypassed. It should be noted that both properties - need to be realised: the more confidence one has that the - properties are satisfied, the more trustworthy the TOE is. The - components in the families are designed so that more assurance - can be gained as the components hierarchically - increase. - - The paradigm for the families targeted at the first property - is one of design decomposition. At the highest level, there is - a functional specification of the TSF in terms of its - interfaces (describing what the TSF does in - terms of requests to the TSF for services and resulting - responses), decomposing the TSF into smaller units (dependent - on the assurance desired and the complexity of the TOE) and - describing how the TSF accomplishes its - functions (to a level of detail commensurate with the - assurance level), and showing the implementation of the TSF. A - formal model of the security behaviour also may be given. All - levels of decomposition are used in determining the - completeness and accuracy of all other levels, ensuring that - the levels are mutually supportive. The requirements for the - various TSF representations are separated into different - families, to allow the PP/ST author to specify which TSF - representations are required. The level chosen will dictate - the assurance desired/gained. - - Figure indicates the - relationships among the various TSF representations of the - class, as well as their - relationships with other classes. As the figure indicates, the - and - classes define the requirements for the correspondence between - the SFRs and the security objectives for the TOE. Class also defines requirements for the - correspondence between both the security objectives and SFRs, - and for the TOE summary specification which explains how the - TOE meets its SFRs. The activities of include the verification that the TSF that is - tested under the and classes is in fact the one described by all of the - decomposition levels. -
- - The requirements for all other correspondence shown in Figure - are defined in the - class. The family defines the requirements for formally - modelling selected SFRs, and providing correspondence between - the functional specification and the formal model. Each - assurance family specific to a TSF representation (i.e., , - and ) defines requirements - relating that TSF representation to the SFRs. All - decompositions must accurately reflect all other - decompositions (i.e., be mutually supportive); the developer - supplies the tracings in the last .C elements of the - components. Assurance relating to this factor is obtained - during the analysis for each of the levels of decomposition by - referring to other levels of decomposition (in a recursive - fashion) while the analysis of a particular level of - decomposition is being performed; the evaluator verifies the - correspondence as part of the second E element. The - understanding gained from these levels of decomposition form - the basis of the functional and penetration testing - efforts. - - The family is not represented - in this figure, as it is related to the internal structure of - the TSF, and is only indirectly related to the process of - refinement of the TSF representations. Similarly, the family is not represented in the - figure because it relates to the architectural soundness, - rather than representation, of the TSF. Both and - relate to the analysis of the property that the TOE cannot be - made to circumvent or corrupt its security - functionality. - - The TOE security functionality (TSF) consists of all parts of - the TOE that have to be relied upon for enforcement of the - SFRs. The TSF includes both functionality that directly - enforces the SFRs, as well as functionality that, while not - directly enforcing the SFRs, contributes to their enforcement - in a more indirect manner, including functionality with the - capability to cause the SFRs to be violated. This includes - portions of the TOE that are invoked on start-up that are - responsible for putting the TSF into its initial secure - state. - - Several important concepts were used in the development of the - components of the families. These - concepts, while introduced briefly here, are explained more - fully in the application notes for the families. - - One over-riding notion is that, as more information becomes - available, greater assurance can be obtained that the security - functionality 1) is correctly implemented; 2) cannot be - corrupted; and 3) cannot be bypassed. This is done through the - verification that the documentation is correct and consistent - with other documentation, and by providing information that - can be used to ensure that the testing activities (both - functional and penetration testing) are comprehensive. This is - reflected in the levelling of the components of the - families. In general, components are levelled based on the - amount of information that is to be provided (and subsequently - analysed). - - While not true for all TOEs, it is generally the case that the - TSF is sufficiently complex that there are portions of the TSF - that deserve more intense examination than other portions of - the TSF. Determining those portions is unfortunately somewhat - subjective, thus terminology and components have been defined - such that as the level of assurance increases, the - responsibility for determining what portions of the TSF need - to be examined in detail shifts from the developer to the - evaluator. To aid in expressing this concept, the following - terminology is introduced. It should be noted that in the - families of the class, this terminology is used when - expressing SFR-related portions of the TOE (that is, elements - and work units embodied in the , , and families). While the general - concept (that some portions of the TOE are more - interesting than others) applies to other - families, the criteria are expressed differently in order to - obtain the assurance required. - - All portions of the TSF are security - relevant, meaning that they must preserve the - security of the TOE as expressed by the SFRs and - requirements for domain separation and - non-bypassability. One aspect of security relevance is the - degree to which a portion of the TSF enforces a security - requirement. Since different portions of the TOE play - different roles (or no apparent role at all) in enforcing - security requirements, this creates a continuum of SFR - relevance: at one end of this continuum are portions of the - TOE that are termed SFR-enforcing. Such - portions play a direct role in implementing any SFR on the - TOE. Such SFRs refer to any functionality provided by one of - the SFRs contained in the ST. It should be noted that the - definition of plays a role in for - SFR-enforcing functionality is impossible to express - quantitatively. For example, in the implementation of a - Discretionary Access Control (DAC) mechanism, a very narrow - view of SFR-enforcing might be the several - lines of code that actually perform the check of a subject's - attributes against the object's attributes. A broader view - would include the software entity (e.g., C function) that - contained the several lines of code. A broader view still - would include callers of the C function, since they would be - responsible for enforcing the decision returned by the - attribute check. A still broader view would include any code - in the call tree (or programming equivalent for the - implementation language used) for that C function (e.g., a - sort function that sorted access control list entries in a - first-match algorithm implementation). At some point, the - component is not so much enforcing the - security policy but rather plays a - supporting role; such components are termed - SFR supporting. - - One of the characteristics of SFR-supporting functionality is - that it is trusted to preserve the correctness of the SFR - implementation by operating without error. Such functionality - may be depended on by SFR-enforcing functionality, but the - dependence is generally at a functional level; for example, - memory management, buffer management, etc. Further down on the - security relevance continuum is functionality termed - SFR non-interfering. Such functionality has - no role in implementing the SFRs, and is likely part of the - TSF because of its environment; for example, any code running - in a privileged hardware mode on an operating system. It needs - to be considered part of the TSF because, if compromised (or - replaced by malicious code), it could compromise the correct - operation of an SFR by virtue of its operating in the - privileged hardware mode. An example of SFR non-interfering - functionality might be a set of mathematical floating point - operations implemented in kernel mode for speed - considerations. - - The architecture family () - provides for requirements and analysis of the TOE based on - properties of domain separation, self-protection, and - non-bypassability. These properties relate to the SFRs in - that, if these properties are not present, it will likely lead - to the failure of mechanisms implementing SFRs. Functionality - and design relating to these properties is - not considered a part of the continuum described - above, but instead is treated separately due to its - fundamentally different nature and analysis - requirements. - - The difference in analysis of the implementation of SFRs - (SFR-enforcing and SFR-supporting functionality) and the - implementation of somewhat fundamental security properties of - the TOE, which include the initialisation, self-protection, - and non-bypassability concerns, is that the SFR-related - functionality is more or less directly visible and relatively - easy to test, while the above-mentioned properties require - varying degrees of analysis on a much broader set of - functionality. Further, the depth of analysis for such - properties will vary depending on the design of the TOE. The - families are constructed to address - this by a separate family () - devoted to analysis of the initialisation, self-protection, - and non-bypassability requirements, while the other families - are concerned with analysis of the functionality supporting - SFRs. - - Even in cases where different descriptions are necessary for - the multiple levels of abstraction, it is not absolutely - necessary for each and every TSF representation to be in a - separate document. Indeed, it may be the case that a single - document meets the documentation requirements for more than - one TSF representation, since it is the information about each - of these TSF representations that is required, rather than the - resulting document structure. In cases where multiple TSF - representations are combined within a single document, the - developer should indicate which portions of the documents meet - which requirements. - - Three types of specification style are mandated by this class: - informal, semiformal and formal. The functional specification - and TOE design documentation are always written in either - informal or semiformal style. A semiformal style reduces the - ambiguity in these documents over an informal presentation. A - formal specification may also be required in addition - to the semi-formal presentation; the value is that a - description of the TSF in more than one way will add increased - assurance that the TSF has been completely and accurately - specified. - - An informal specification is written as prose in natural - language. Natural language is used here as meaning - communication in any commonly spoken tongue (e.g. Spanish, - German, French, English, Dutch). An informal specification is - not subject to any notational or special restrictions other - than those required as ordinary conventions for that language - (e.g. grammar and syntax). While no notational restrictions - apply, the informal specification is also required to provide - defined meanings for terms that are used in a context other - than that accepted by normal usage. - - The difference between semiformal and informal documents is - only a matter of formatting or presentation: a semiformal - notation includes such things as an explicit glossary of - terms, a standardised presentation format, etc. A semiformal - specification is written to a standard presentation - template. The presentation should use terms consistently if - written in a natural language. The presentation may also use - more structured languages/diagrams (e.g. data-flow diagrams, - state transition diagrams, entity-relationship diagrams, data - structure diagrams, and process or program structure - diagrams). Whether based on diagrams or natural language, a - set of conventions must be used in the presentation. The - glossary explicitly identifies the words that are being used - in a precise and constant manner; similarly, the standardised - format implies that extreme care has been taken in - methodically preparing the document in a manner that maximises - clarity. It should be noted that fundamentally different - portions of the TSF may have different semiformal notation - conventions and presentation styles (as long as the number of - different ``semiformal notations'' is small); this still - conforms to the concept of a semiformal - presentation. - - A formal specification is written in a notation based upon - well-established mathematical concepts, and is typically - accompanied by supporting explanatory (informal) prose. These - mathematical concepts are used to define the syntax and - semantics of the notation and the proof rules that support - logical reasoning. The syntactic and semantic rules supporting - a formal notation should define how to recognise constructs - unambiguously and determine their meaning. There needs to be - evidence that it is impossible to derive contradictions, and - all rules supporting the notation need to be defined or - referenced. - - - - The purpose of the Development class is to provide evidence - about the TOE. Without the knowledge about the TOE that is - gained from this information, there could be no useful - vulnerability analysis or testing conducted upon the TOE (as - described in the and classes). - - - The purpose of the development activity is to assess the - design documentation in terms of its adequacy to understand - how the TSF meets the SFRs and how the implementation of these - SFRs cannot be tampered with or bypassed. This understanding - is achieved through examination of increasingly refined - descriptions of the TSF design documentation. Design - documentation consists of a functional specification (which - describes the interfaces of the TSF), a TOE design description - (which describes the architecture of the TSF in terms of how - it works in order to perform the functions related to the SFRs - being claimed), and an implementation description (a source - code level description). In addition, there is a security - architecture description (which describes the architectural - properties of the TSF to explain how its security enforcement - cannot be compromised or bypassed), an internals description - (which describes how the TSF was constructed in a manner that - encourages understandability), and a security policy model - (which formally describes the security policies enforced by - the TSF). - - - - The CC requirements for design documentation are levelled by - the amount, and detail of information provided, and the degree - of formality of the presentation of the information. At lower - levels, the most security-critical portions of the TSF are - described with the most detail, while less security-critical - portions of the TSF are merely summarised; added assurance is - gained by increasing the amount of information about the most - security-critical portions of the TSF, and increasing the - details about the less security-critical portions. The most - assurance is achieved when thorough details and information of - all portions are provided. - - The CC considers a document's degree of formality (that is, - whether it is informal or semiformal) to be hierarchical. An - informal document is one that is expressed in a natural - language. The methodology does not dictate the specific - language that must be used; that issue is left for the - scheme. The following paragraphs differentiate the contents of - the different informal documents. - - A functional specification provides a description of the - purpose and method-of-use of interfaces to the TSF. For - example, if an operating system presents the user with a means - of self-identification, of creating files, of modifying or - deleting files, of setting permissions defining what other - users may access files, and of communicating with remote - machines, its functional specification would contain - descriptions of each of these and how they are realised - through interactions with the externally-visible interfaces to - the TSF. If there is also audit functionality that detects and - record the occurrences of such events, descriptions of this - audit functionality would also be expected to be part of the - functional specification; while this functionality is - technically not directly invoked by the user at the external - interface, it certainly is affected by what occurs at the - user's external interface. - - A design description is expressed in terms of logical - divisions (subsystems or modules) that each provide a - comprehensible service or function. For example, a firewall - might be composed of subsystems that deal with packet - filtering, with remote administration, with auditing, and with - connection-level filtering. The design description of the - firewall would describe the actions that are taken, in terms - of what actions each subsystem takes when an incoming packet - arrives at the firewall. - - - - - The objective of this family is for the developer to provide - a description of the security architecture of the TSF. This - will allow analysis of the information that, when coupled - with the other evidence presented for the TSF, will confirm - the TSF achieves the desired properties. The security - architecture descriptions supports the implicit claim that - security analysis of the TOE can be achieved by examining - the TSF; without a sound architecture, the entire TOE - functionality would have to be examined. - - - - The information presented for the security architecture of - the TOE is related to the information contained in other - decomposition documentation (functional specification and - TOE design documentation) provided for the TSF, but presents - the design in a manner that supports architectural arguments - (e.g., the TSF cannot be compromised; the TSF provides - security domains consistent with its SFRs; the TSF cannot be - bypassed). - - - - This family contains only one component. - - - - The properties of self-protection, domain separation, and - non-bypassability are distinct from security functionality - expressed by Part 2 SFRs because self-protection and - non-bypassability largely have no directly observable - interface at the TSF. Rather, they are properties of the TSF - that are achieved through the design of the TOE and TSF, and - enforced by the correct implementation of that - design. - - The approach used in this family is for the developer to - design and provide a TSF that exhibits the above-mentioned - properties, and to provide evidence (in the form of - documentation) that explains these properties of the - TSF. This explanation is provided at the same level of - detail as the description of the SFR-enforcing elements of - the TOE in the TOE design document. The evaluator has the - responsibility for looking at the evidence and, coupled with - other evidence delivered for the TOE and TSF, determining - that the properties are achieved. - - Specification of security functionality implementing the - SFRs (in the and ) will not necessarily describe - mechanisms employed in implementing self-protection and - non-bypassability (e.g. memory management - mechanisms). Therefore, the material needed to provide the - assurance that these requirements are being achieved is - better suited to a presentation separate from the design - decomposition of the TSF as embodied in and . This is not - to imply that the security architecture description called - for by this component cannot reference or make use of the - design decomposition material; but it is likely that much of - the detail present in the decomposition documentation will - not be relevant to the argument being provided for the - security architecture description document. - - The description of architectural soundness can be thought of - as a developer's vulnerability analysis, in that it provides - the justification for why the TSF is sound and enforces all - of its SFRs. Where the soundness is achieved through - specific security mechanisms, these will be tested as part - of the requirements; where - the soundness is achieved solely through the architecture, - the behaviour will be tested as part of the requirements. - - This family consists of requirements for a security - architecture description that describes the self-protection, - domain separation, non-bypassability principles, including a - description of how these principles are supported by the - parts of the TOE that are used for TSF - initialisation. - Additional information on the security architecture - properties of self-protection, domain separation, and - non-bypassability can be found in Annex . - - - - - - - The objective of this sub-activity is to determine whether - the TSF is structured such that it cannot be tampered with - or bypassed, and whether TSFs that provide security - domains isolate those domains from each other. - - - - The notions of self-protection, domain separation, and - non-bypassability are distinct from security functionality - expressed in Part 2 SFRs because self-protection and - non-bypassability largely have no directly observable - interface at the TSF. Rather, they are properties of the - TSF that are achieved through the design of the TOE, and - enforced by the correct implementation of that - design. Also, the evaluation of these properties is less - straight-forward than the evaluation of mechanisms; it is - more difficult to check for the absence of functionality - than for its presence. However, the determination that - these properties are being satisfied is just as critical - as the determination that the mechanisms are properly - implemented. - - The overall approach used is that the developer provides a - TSF that meets the above-mentioned properties, and - provides evidence (in the form of documentation) that can - be analysed to show that the properties are indeed - met. The evaluator has the responsibility for looking at - the evidence and, coupled with other evidence delivered - for the TOE, determining that the properties are - achieved. The work units can be characterised as those - detailing with what information has to be provided, and - those dealing with the actual analysis the evaluator - performs. - - The security architecture description describes how - domains are defined and how the TSF keeps them - separate. It describes what prevents untrusted processes - from getting to the TSF and modifying it. It describes - what ensures that all resources under the TSF's control - are adequately protected and that all actions related to - the SFRs are mediated by the TSF. It explains any role the - environment plays in any of these (e.g. presuming it gets - correctly invoked by its underlying environment, how is - its security functionality invoked?). In short, it - explains how the TOE is considered to be providing any - kind of security service. - - The analyses the evaluator performs must be done in the - context of all of the development evidence provided for - the TOE, at the level of detail the evidence is - provided. At lower assurance levels there should not be - the expectation that, for example, TSF self-protection is - completely analysed, because only high-level design - representations will be available. The evaluator also - needs to be sure to use information gleaned from other - portions of their analysis (e.g., analysis of the TOE - design) in making their assessments for the properties - being examined in the following work units. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the functional specification; - - - the TOE design; - - - the security architecture description; - - - the implementation representation (if available); - - - the operational user guidance; - - - - - The developer shall design and implement the TOE so that the - security features of the TSF cannot be bypassed. - - - The developer shall design and implement the TSF so that it - is able to protect itself from tampering by untrusted active - entities. - - - The developer shall provide a security architecture - description of the TSF. - - - The security architecture description shall be at a level of - detail commensurate with the description of the - SFR-enforcing abstractions described in the TOE design - document. - - - The security architecture description shall describe the - security domains maintained by the TSF consistently with the - SFRs. - - - The security architecture description shall describe how the - TSF initialisation process is secure. - - - The security architecture description shall demonstrate that - the TSF protects itself from tampering. - - - The security architecture description shall demonstrate that - the TSF prevents bypass of the SFR-enforcing functionality. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the security architecture - description to determine that the information provided - in the evidence is presented at a level of detail - commensurate with the descriptions of the SFR-enforcing - abstractions contained in the functional specification - and TOE design document. - - With respect to the functional specification, the - evaluator should ensure that the self-protection - functionality described cover those effects that are - evident at the TSFI. Such a description might include - protection placed upon the executable images of the TSF, - and protection placed on objects (e.g., files used by - the TSF). The evaluator ensures that the functionality - that might be invoked through the TSFI is - described. - - If or is included, the evaluator - ensures the security architecture description contains - information on how any subsystems that contribute to TSF - domain separation work. - - If or higher is - available, the evaluator ensures that the security - architecture description also contains - implementation-dependent information. For example, such - a description might contain information pertaining to - coding conventions for parameter checking that would - prevent TSF compromises (e.g. buffer overflows), and - information on stack management for call and return - operations. The evaluator checks the descriptions of the - mechanisms to ensure that the level of detail is such - that there is little ambiguity between the description - in the security architecture description and the - implementation representation. - - The evaluator action related to this work unit is assigned a fail verdict - if the security architecture description mentions any module, subsystem, or interface - that is not described in the functional specification or TOE design document. - - - - The evaluator shall examine the security architecture - description to determine that it describes the security - domains maintained by the TSF. - - Security domains refer to environments supplied by the - TSF for use by potentially-harmful entities; for - example, a typical secure operating system supplies a - set of resources (address space, per-process environment - variables) for use by processes with limited access - rights and security properties. The evaluator determines - that the developer's description of the security domains - takes into account all of the SFRs claimed by the - TOE. - - For some TOEs such domains do not exist because all of - the interactions available to users are severely - constrained by the TSF. A packet-filter firewall is an - example of such a TOE. Users on the LAN or WAN do not - interact with the TOE, so there need be no security - domains; there are only data structures maintained by - the TSF to keep the users' packets separated. The - evaluator ensures that any claim that there are no - domains is supported by the evidence and that no such - domains are, in fact, available. - - - - - The evaluator shall examine the security architecture - description to determine that the initialisation process - preserves security. - - The information provided in the security architecture - description relating to TSF initialisation is directed - at the TOE components that are involved in bringing the - TSF into an initial secure state (i.e. when all parts of - the TSF are operational) when power-on or a reset is - applied. This discussion in the security architecture - description should list the system initialisation - components and the processing that occurs in - transitioning from the ``down'' state to the initial - secure state. - - It is often the case that the components that perform - this initialisation function are not accessible after - the secure state is achieved; if this is the case then - the security architecture description identifies the components and - explains how they are not reachable by untrusted - entities after the TSF has been established. In this - respect, the property that needs to be preserved is that - these components either 1) cannot be accessed by - untrusted entities after the secure state is achieved, - or 2) if they provide interfaces to untrusted entities, - these TSFI cannot be used to tamper with the TSF. - - The TOE components related to TSF initialisation, then, - are treated themselves as part of the TSF, and analysed - from that perspective. It should be noted that even - though these are treated as part of the TSF, it is - likely that a justification (as allowed by ) can be made that they do not - have to meet the internal structuring requirements of - . - - - - - The evaluator shall examine the security architecture - description to determine that it contains information - sufficient to support a determination that the TSF is - able to protect itself from tampering by untrusted - active entities. - - ''Self-protection'' refers to the ability of the TSF to - protect itself from manipulation from external entities - that may result in changes to the TSF. For TOEs that - have dependencies on other IT entities, it is often the - case that the TOE uses services supplied by the other IT - entities in order to perform its functions. In such - cases, the TSF alone does not protect itself because it - depends on the other IT entities to provide some of the - protection. For the purposes of the security - architecture description, the notion of - self-protection applies only to the - services provided by the TSF through its TSFI, and not - to services provided by underlying IT entities that it - uses. - - Self-protection is typically achieved by a variety of - means, ranging from physical and logical restrictions on - access to the TOE; to hardware-based means (e.g. - ``execution rings'' and memory management - functionality); to software-based means (e.g. boundary - checking of inputs on a trusted server). The evaluator - determines that all such mechanisms are - described. - - The evaluator determines that the design description - covers how user input is handled by the TSF in such a - way that the TSF does not subject itself to being - corrupted by that user input. For example, the TSF might - implement the notion of privilege and protect itself by - using privileged-mode routines to handle user input. The - TSF might make use of processor-based separation - mechanisms such as privilege levels or rings. The TSF - might implement software protection constructs or coding - conventions that contribute to implementing separation of - software domains, perhaps by delineating user address - space from system address space. And the TSF might have - reliance its environment to provide some support to the - protection of the TSF. - - All of the mechanisms contributing to the domain - separation functions are described. The evaluator should - use knowledge gained from other evidence (functional - specification, TOE design, TSF internals description, - other parts of the security architecture description, or - implementation representation, as included in the - assurance package for the TOE) in determining if any - functionality contributing to self-protection was - described that is not present in the security - architecture description. - - Accuracy of the description of the self-protection mechanisms is the property that the - description faithfully describes what is implemented. The evaluator should use other - evidence (functional specification, TOE design, TSF Internals documentation, other parts - of the security architecture description, implementation representation, as included in - the ST for the TOE) in determining whether there are discrepancies in any descriptions - of the self-protection mechanisms. If - - is included in the assurance package for the TOE, the evaluator will choose a sample of - the implementation representation; the evaluator should also ensure that the descriptions - are accurate for the sample chosen. If an evaluator cannot understand how a certain - self-protection mechanism works or could work in the system architecture, it may be the - case that the description is not accurate. - - - - - The evaluator shall examine the security architecture - description to determine that it presents an analysis - that adequately describes how the SFR-enforcing - mechanisms cannot be bypassed. - - Non-bypassability is a property that the security - functionality of the TSF (as specified by the SFRs) is - always invoked. For example, if access control to files - is specified as a capability of the TSF via an SFR, - there must be no interfaces through which files can be - accessed without invoking the TSF's access control - mechanism (such as an interface through which a raw disk - access takes place). - - Describing how the TSF mechanisms cannot be bypassed - generally requires a systematic argument based on the - TSF and the TSFIs. The description of how the TSF works - (contained in the design decomposition evidence, such as - the functional specification, TOE design documentation) - - along with the information in the TSS - provides the - background necessary for the evaluator to understand - what resources are being protected and what security - functions are being provided. The functional - specification provides descriptions of the TSFIs through - which the resources/functions are accessed. - - The evaluator assesses the description provided (and other - information provided by the developer, such as the functional - specification) to ensure that no available interface can be used - to bypass the TSF. This means that every available interface - must be either unrelated to the SFRs that are claimed in the ST - (and does not interact with anything that is used to satisfy - SFRs) or else uses the security functionality that is described - in other development evidence in the manner described. For - example, a game would likely be unrelated to the SFRs, so there - must be an explanation of how it cannot affect security. Access - to user data, however, is likely to be related to access control - SFRs, so the explanation would describe how the security - functionality works when invoked through the data-access - interfaces. Such a description is needed for every available - interface. - - An example of a description follows. Suppose the TSF - provides file protection. Further suppose that although - the ``traditional'' system call TSFIs for open, read, - and write invoke the file protection mechanism described - in the TOE design, there exists a TSFI that allows - access to a batch job facility (creating batch jobs, - deleting jobs, modifying unprocessed jobs). The - evaluator should be able to determine from the - vendor-provided description that this TSFI invokes the - same protection mechanisms as do the ``traditional'' - interfaces. This could be done, for example, by - referencing the appropriate subclauses of the TOE design - that discuss how the batch job facility - TSFI achieves its security objectives. - - Using this same example, suppose there is a TSFI whose - sole purpose is to display the time of day. The - evaluator should determine that the description - adequately argues that this TSFI is not capable of - manipulating any protected resources and should not - invoke any security functionality. - - Another example of bypass is when the TSF is supposed to - maintain confidentiality of a cryptographic key (one is - allowed to use it for cryptographic operations, but is - not allowed to read/write it). If an attacker has direct - physical access to the device, he might be able to - examine side-channels such as the power usage of the - device, the exact timing of the device, or even any - electromagnetic emanations of the device and, from this, - infer the key. - - If such side-channels may be present, the demonstration - should address the mechanisms that prevent these - side-channels from occurring, such as random internal - clocks, dual-line technology etc. Verification of these - mechanisms would be verified by a combination of purely - design-based arguments and testing. - - For a final example using security functionality rather - than a protected resource, consider an ST that contains - , which requires that - the TSF provides evidence of origination for information - types specified in the ST. Suppose that the - ``information types'' included all information that is - sent by the TOE via e-mail. In this case the evaluator - should examine the description to ensure that all TSFI - that can be invoked to send e-mail perform the - ``evidence of origination generation'' function are - detailed. The description might point to user guidance - to show all places where e-mail can originate (e.g., - e-mail program, notification from scripts/batch jobs) - and then how each of these places invokes the evidence - generation function. - - The evaluator should also ensure that the description is comprehensive, in that each - interface is analysed with respect to the entire set of claimed SFRs. This may require the - evaluator to examine supporting information (functional specification, TOE design, other - parts of the security architecture description, operational user guidance, and perhaps even - the implementation representation, as provided for the TOE) to determine that the description - has correctly capture all aspects of an interface. The evaluator should consider what SFRs each - TSFI might affect (from the description of the TSFI and its implementation in the supporting - documentation), and then examine the description to determine whether it covers those aspects. - - - - - - - - This family levies requirements upon the functional specification, - which describes the TSF interfaces (TSFIs). - The TSFI consists of all means by which external entities (or - subjects in the TOE but outside of the TSF) supply data to the TSF, - receive data from the TSF and invoke services from the TSF. - It does not describe how the TSF processes those service - requests, nor does it describe the communication when the TSF invokes services - from its operational environment; this information is addressed by the - and - families, respectively. - - This family provides assurance directly by allowing the - evaluator to understand how the TSF meets the claimed SFRs. It - also provides assurance indirectly, as input to other assurance - families and classes: - , where the description of - the TSFIs may be used to gain better understanding of how the - TSF is protected against corruption (i.e. subversion of - self-protection or domain separation) and/or bypass; - , where the description of the - TSFIs is an important input for both developer and evaluator - testing; - , where the description of the - TSFIs is used to search for vulnerabilities. - - - - - The information presented in the functional specification - describes the interfaces through which the TSF services are - invoked. At the lower levels of assurance, there is an - effort to reduce the amount of information that must be - supplied by requiring only the most security-critical - information. - - - - The components in this family are levelled on the degree of - detail required of the description of the TSFIs, and the degree - of formalism required of the description of the TSFIs. - - - - Once the TSFIs are determined (see for guidance and - examples of determining TSFI), they are described. At - lower-level components, developers focus their documentation - (and evaluators focus their analysis) on the more - security-relevant aspects of the TOE. Three categories of - TSFIs are defined, based upon the relevance the services - available through them have to the SFRs being claimed: - If a service available through an interface can be - traced to one of the SFRs levied on the TSF, then that - interface is termed SFR-enforcing. - Note that it is possible that an interface may have - various services and results, some of which may be - SFR-enforcing and some of which may not. - interfaces to (or services available through an - interface relating to) services that SFR-enforcing - functionality depends upon, but need only to function - correctly in order for the security policies of the TOE - to be preserved, are termed - SFR-supporting. - Interfaces to services on which SFR-enforcing - functionality has no dependence are termed SFR - non-interfering. - - It should be noted that in order for an interface to be - SFR-supporting or SFR non-interfering it must have - no SFR-enforcing services or results. In - contrast, an SFR-enforcing interface may have SFR-supporting - services (for example, the ability to set the system clock - may be an SFR-enforcing service of an interface, but if that - same interface is used to display the system date that - service may be only SFR-supporting). An example of a purely - SFR-supporting interface is a system call interface that is - used both by users and by a portion of the TSF that is - running on behalf of users. - - As more information about the TSFIs becomes available, the - greater the assurance that can be gained that the interfaces are - correctly categorised/analysed. The requirements are structured - such that, at the lowest level, the information required for SFR - non-interfering interfaces is the minimum necessary in order for - the evaluator to make this determination in an effective - manner. At higher levels, more information becomes available so - that the evaluator has greater confidence in the - designation. - - The purpose in defining these labels (SFR-enforcing, - SFR-supporting, and SFR-non-interfering) and for levying - different requirements upon each (at the lower assurance - components) is to provide a first approximation of where to - focus the analysis and the evidence upon which that analysis - is performed. If the developer's documentation of the TSF - interfaces describes all of the interfaces to the degree - specified in the requirements for the SFR-enforcing - interfaces (that is, if the documentation exceeds the - requirements), there is no need for the developer to create - new evidence to match the requirements. Similarly, because - the labels are merely a means of differentiating the - interface types within the requirements, there is no need - for the developer to update the evidence solely to label the - interfaces as SFR-enforcing, SFR-supporting, and - SFR-non-interfering. The primary purpose of this labelling - is to allow developers with less mature development - methodologies (and associated artifacts, such as detailed - interface and design documentation) to provide only the - necessary evidence without undue cost. - - The last C element of each component within this family provides - a direct correspondence between the SFRs and the functional - specification; that is, an indication of which interfaces are - used to invoke each of the claimed SFRs. In the cases where the - ST contains such functional requirements as , whose functionality may not manifest itself at - the TSFIs, the functional specification and/or the tracing is - expected to identify these SFRs; including them in the functional - specification helps to ensure that they are not lost at lower - levels of decomposition, where they will be relevant. - - - The requirements define collections of details about TSFI - to be provided. For the purposes of the requirements, - interfaces are specified (in varying degrees of detail) in - terms of their purpose, method of use, parameters, - parameter descriptions, and error messages. - - The purpose of an interface is a - high-level description of the general goal of the - interface (e.g. process GUI commands, receive network - packets, provide printer output, etc.) - - The interface's method of use describes - how the interface is supposed to be used. This description - should be built around the various interactions available - at that interface. For instance, if the interface were a Unix - command shell, ls, mv - and cp would be interactions for that - interface. For each interaction the method of use - describes what the interaction does, both for behaviour - seen at the interface (e.g. the programmer calling the - API, the Windows users changing a setting in the registry, - etc.) as well as behaviour at other interfaces - (e.g. generating an audit record). - - Parameters are explicit inputs to and - outputs from an interface that control the behaviour of - that interface. For example, parameters are the arguments - supplied to an API; the various fields in a packet for a - given network protocol; the individual key values in the - Windows Registry; the signals across a set of pins on a - chip; the flags that can be set for the - ls, etc. The parameters are - ``identified'' with a simple list of what they are. - - A parameter description tells what the - parameter is in some meaningful way. For instance, an - acceptable parameter description for interface - foo(i) would be ``parameter i is an - integer that indicates the number of users currently - logged in to the system''. A description such as - ``parameter i is an integer'' is not an acceptable. - - The description of an interface's actions - describes what the interface does. This is more detailed - than the purpose in that, while the ``purpose'' reveals - why one might want to use it, the ``actions'' reveals - everything that it does. These actions might be related to - the SFRs or not. In cases where the interface's action is - not related to SFRs, its description is said to be - summarised, meaning the description - merely makes clear that it is indeed not SFR-related. - - The error message description identifies - the condition that generated it, what the message is, and - the meaning of any error codes. An error message is - generated by the TSF to signify that a problem or - irregularity of some degree has been encountered. The - requirements in this family refer to different kinds of - error messages: - a ``direct'' error message is a - security-relevant response through a specific TSFI - invocation. - an ``indirect'' error cannot be tied to a - specific TSFI invocation because it results from - system-wide conditions (e.g. resource exhaustion, - connectivity interruptions, etc.). Error messages that - are not security-relevant are also considered - ``indirect''. - ``remaining'' errors are any other errors, such as those - that might be referenced within the code. For example, the use of - condition-checking code that checks for conditions that would not - logically occur (e.g. a final ``else'' after a list of ``case'' - statements), would provide for generating a catch-all error - message; in an operational TOE, these error messages should never - be seen. - - An example functional specification is provided in . - - - - Increasing assurance through increased completeness and - accuracy in the interface specification is reflected in - the documentation required from the developer as detailed - in the various hierarchical components of this - family. - - At , the only - documentation required is a characterisation of all TSFIs - and a high level description of SFR-enforcing and - SFR-supporting TSFIs. To provide some assurance that the - ``important'' aspects of the TSF have been correctly - characterised at the TSFIs, the developer is required to - provide the purpose and method of use, parameters for the - SFR-enforcing and SFR-supporting TSFIs. - - At , the developer is - required to provide the purpose, method of use, - parameters, and parameter descriptions for all - TSFIs. Additionally, for the SFR-enforcing TSFIs the - developer has to describe the SFR-enforcing actions and - direct error messages. - - At , the developer must now, - in addition to the information required at , provide enough information about the SFR-supporting - and SFR-non-interfering actions to show that they are not - SFR-enforcing. Further, the developer must now document all of - the direct error messages resulting from the invocation of - SFR-enforcing TSFIs. - - At , all TSFIs - whether - SFR-enforcing, SFR-supporting, SFR-non-interfering - must - be described to the same degree, including all of the - direct error messages. - - At , the TSFIs descriptions - also include error messages that do not result from an - invocation of a TSFI. - - At , in addition to the - information required by , all - remaining error messages are included. The developer must also - provide a formal description of the TSFI. This provides an - alternative view of the TSFI that may expose inconsistencies or - incomplete specification. - - - - - - The objective of this sub-activity is to determine whether the - developer has provided a high-level description of at least the - SFR-enforcing and SFR-supporting TSFIs, in terms of descriptions - of their parameters. There is no other required evidence that - can be expected to be available to measure the accuracy of these - descriptions; the evaluator merely ensures the descriptions seem - plausible. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the functional specification; - - - the operational user guidance; - - - - - The developer shall provide a functional specification. - - - The developer shall provide a tracing from the functional - specification to the SFRs. - - - The functional specification shall describe the purpose and - method of use for each SFR-enforcing and SFR-supporting - TSFI. - - - The functional specification shall identify all parameters - associated with each SFR-enforcing and SFR-supporting TSFI. - - - The functional specification shall provide rationale for the - implicit categorisation of interfaces as - SFR-non-interfering. - - - The tracing shall demonstrate that the SFRs trace to TSFIs - in the functional specification. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the functional specification - to determine that it states the purpose of each - SFR-supporting and SFR-enforcing TSFI. - - The purpose of a TSFI is a general statement summarising - the functionality provided by the interface. It is not - intended to be a complete statement of the actions and - results related to the interface, but rather a statement - to help the reader understand in general what the - interface is intended to be used for. The evaluator - should not only determine that the purpose exists, but - also that it accurately reflects the TSFI by taking into - account other information about the interface, such as - the description of the parameters; this can be done in - association with other work units for this - component. - - If an action available through an interface plays a role in - enforcing any security policy on the TOE (that is, if one of the - actions of the interface can be traced to one of the SFRs levied - on the TSF), then that interface is - SFR-enforcing. Such policies are not limited to - the access control policies, but also refer to any functionality - specified by one of the SFRs contained in the ST. Note that it - is possible that an interface may have various actions and - results, some of which may be SFR-enforcing and some of which - may not. - - Interfaces to (or actions available through an interface - relating to) actions that SFR-enforcing functionality - depends on, but need only to function correctly in order - for the security policies of the TOE to be preserved, - are termed SFR supporting. Interfaces - to actions on which SFR-enforcing functionality has no - dependence are termed SFR - non-interfering. - - It should be noted that in order for an interface to be - SFR supporting or SFR non-interfering it must have - no SFR-enforcing actions or results. In - contrast, an SFR-enforcing interface may have - SFR-supporting actions (for example, the ability to set - the system clock may be an SFR-enforcing action of an - interface, but if that same interface is used to display - the system date that action may only be SFR - supporting). An example of a purely SFR-supporting - interface is a system call interface that is used both - by untrusted users and by a portion of the TSF that is - running in user mode. - - At this level, it is unlikely that a developer will have - expended effort to label interfaces as SFR-enforcing and - SFR-supporting. In the case that this has been done, - the evaluator should verify to the extent that - supporting documentation (e.g., operational user - guidance) allows that this identification is correct. - Note that this identification activity is necessary for - several work units for this component. - - In the more likely case that the developer has not - labelled the interfaces, the evaluator must perform - their own identification of the interfaces first, and - then determine whether the required information (for - this work unit, the purpose) is present. Again, because - of the lack of supporting evidence this identification - will be difficult and have low assurance that all - appropriate interfaces have been correctly identified, - but nonetheless the evaluator examines other evidence - available for the TOE to ensure as complete coverage as - is possible. - - - - - The evaluator shall examine the functional specification - to determine that the method of use for each - SFR-supporting and SFR-enforcing TSFI is given. - - See work unit for a - discussion on the identification of SFR-supporting and - SFR-enforcing TSFI. - - The method of use for a TSFI summarises how the - interface is manipulated in order to invoke the actions - and obtain the results associated with the TSFI. The - evaluator should be able to determine, from reading this - material in the functional specification, how to use - each interface. This does not necessarily mean that - there needs to be a separate method of use for each - TSFI, as it may be possible to describe in general how - kernel calls are invoked, for instance, and then - identify each interface using that general - style. Different types of interfaces will require - different method of use specifications. APIs, network - protocol interfaces, system configuration parameters, - and hardware bus interfaces all have very different - methods of use, and this should be taken into account by - the developer when developing the functional - specification, as well as by the evaluator evaluating - the functional specification. - - For administrative interfaces whose functionality is documented - as being inaccessible to untrusted users, the evaluator ensures - that the method of making the functions inaccessible is - described in the functional specification. It should be noted - that this inaccessibility needs to be tested by the developer in - their test suite. - - - - - The evaluator shall examine the presentation of the TSFI - to determine that it identifies all parameters - associated with each SFR-enforcing and SFR-supporting - TSFI. - - See work unit for a - discussion on the identification of SFR-supporting and - SFR-enforcing TSFI. - - The evaluator examines the functional specification to - ensure that all of the parameters are described for - identified TSFI. Parameters are explicit inputs or - outputs to an interface that control the behaviour of - that interface. For examples, parameters are the - arguments supplied to an API; the various fields in - packet for a given network protocol; the individual key - values in the Windows Registry; the signals across a set - of pins on a chip; etc. - - While difficult to obtain much assurance that all - parameters for the applicable TSFI have been identified, - the evaluator should also check other evidence provided - for the evaluation (e.g., operational user guidance) to - see if behaviour or additional parameters are described - there but not in the functional specification. - - - - - The evaluator shall examine the rationale provided by - the developer for the implicit categorisation of - interfaces as SFR-non-interfering to determine that it - is accurate. - - In the case where the developer has provided adequate - documentation to perform the analysis called for by the - rest of the work units for this component without - explicitly identifying SFR-enforcing and SFR-supporting - interfaces, this work unit should be considered - satisfied. - - This work unit is intended to apply to cases where the developer - has not described a portion of the TSFI, claiming that it is - SFR-non-interfering and therefore not subject to other - requirements of this component. In such a case, the developer - provides a rationale for this characterisation in sufficient - detail such that the evaluator understands the rationale, the - characteristics of the interfaces affected (e.g., their - high-level function with respect to the TOE, such as ``colour - palette manipulation''), and that the claim that these are - SFR-non-interfering is supported. Given the level of assurance - the evaluator should not expect more detail than is provided for - the SFR-enforcing or SFR-supporting interfaces, and in fact the - detail should be much less. In most cases, individual - interfaces should not need to be addressed in the - developer-provided rationale subclause. - - - - The evaluator shall check that the tracing links the - SFRs to the corresponding TSFIs. - - The tracing is provided by the developer to serve as a - guide to which SFRs are related to which TSFIs. This - tracing can be as simple as a table; it is used as input - to the evaluator for use in the following work units, in - which the evaluator verifies its completeness and - accuracy. - - - - The evaluator shall determine that the functional - specification is an accurate and complete instantiation of - the SFRs. - - - The evaluator shall examine the functional specification - to determine that it is a complete instantiation of the - SFRs. - - To ensure that all SFRs are covered by the functional - specification, as well as the test coverage analysis, the - evaluator may build upon the developer's tracing (see a map between the TOE security - functional requirements and the TSFI). Note that this map may - have to be at a level of detail below the component or even - element level of the requirements, because of operations - (assignments, refinements, selections) performed on the - functional requirement by the ST author. - - For example, the - component contains an element with assignments. If the - ST contained, for instance, ten rules in the assignment, and these ten - rules were covered by three different TSFI, it would be - inadequate for the evaluator to map to TSFI A, B, and C and claim they had - completed the work unit. Instead, the evaluator would - map (rule 1) to TSFI A; - (rule 2) to TSFI B; - etc. It might also be the case that the interface is a - wrapper interface (e.g., IOCTL), in which case the - mapping would need to be specific to certain set of - parameters for a given interface. - - The evaluator must recognise that for requirements that have - little or no manifestation at the TSF boundary (e.g., ) it is not expected that they - completely map those requirements to the TSFI. The analysis for - those requirements will be performed in the analysis for the TOE - design () when included in the - ST. It is also important to note that since the parameters - associated with TSFIs must be fully specified, the evaluator - should be able to determine if all aspects of an SFR appear to - be implemented at the interface level. - - - - The evaluator shall examine the functional specification - to determine that it is an accurate instantiation of the - SFRs. - - For each functional requirement in the ST that results - in effects visible at the TSF boundary, the information - in the associated TSFI for that requirement specifies - the required functionality described by the - requirement. For example, if the ST contains a - requirement for access control lists, and the only TSFI - that map to that requirement specify functionality for - Unix-style protection bits, then the functional - specification is not accurate with respect to the - requirements. - - The evaluator must recognise that for requirements that - have little or no manifestation at the TSF boundary - (e.g., ) it is not - expected that the evaluator completely map those - requirements to the TSFI. The analysis for those - requirements will be performed in the analysis for the - TOE design () when - included in the ST. - - - - - - - - - The objective of this sub-activity is to determine whether - the developer has provided a description of the TSFIs in - terms of their purpose, method of use, and parameters. In - addition, the SFR-enforcing actions, results and error - messages of each TSFI that is SFR-enforcing are also - described. - - - - The evaluation evidence for this sub-activity that is - required by the work-units is: - - - the ST; - - - the functional specification; - - - the TOE design. - - - - The evaluation evidence for this sub-activity that is used - if included in the ST for the TOE is: - - - the security architecture description; - - - the operational user guidance; - - - - - The developer shall provide a functional specification. - - - The developer shall provide a tracing from the functional - specification to the SFRs. - - - The functional specification shall completely represent the - TSF. - - - The functional specification shall describe the purpose and - method of use for all TSFI. - - - The functional specification shall identify and describe all - parameters associated with each TSFI. - - - For each SFR-enforcing TSFI, the functional specification shall - describe the SFR-enforcing actions associated with the TSFI. - - - For each SFR-enforcing TSFI, the functional specification shall - describe direct error messages resulting from processing - associated with the SFR-enforcing actions. - - - The tracing shall demonstrate that the SFRs trace to TSFIs - in the functional specification. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the functional specification - to determine that the TSF is fully represented. - - The identification of the TSFI is a necessary - prerequisite to all other activities in this - sub-activity. The TSF must be identified (done as part - of the work units) in - order to identify the TSFI. This activity can be done at - a high level to ensure that no large groups of - interfaces have been missed (network protocols, hardware - interfaces, configuration files), or at a low level as - the evaluation of the functional specification - proceeds. - - In making an assessment for this work unit, the - evaluator determines that all portions of the TSF are - addressed in terms of the interfaces listed in the - functional specification. All portions of the TSF should - have a corresponding interface description, or if there - are no corresponding interfaces for a portion of the - TSF, the evaluator determines that that is - acceptable. - - - - - The evaluator shall examine the functional specification - to determine that it states the purpose of each - TSFI. - - The purpose of a TSFI is a general statement summarising - the functionality provided by the interface. It is not - intended to be a complete statement of the actions and - results related to the interface, but rather a statement - to help the reader understand in general what the - interface is intended to be used for. The evaluator - should not only determine that the purpose exists, but - also that it accurately reflects the TSFI by taking into - account other information about the interface, such as - the description of actions and error messages. - - - - - The evaluator shall examine the functional specification - to determine that the method of use for each TSFI is - given. - - The method of use for a TSFI summarises how the - interface is manipulated in order to invoke the actions - and obtain the results associated with the TSFI. The - evaluator should be able to determine, from reading this - material in the functional specification, how to use - each interface. This does not necessarily mean that - there needs to be a separate method of use for each - TSFI, as it may be possible to describe in general how - kernel calls are invoked, for instance, and then - identify each interface using that general - style. Different types of interfaces will require - different method of use specifications. APIs, network - protocol interfaces, system configuration parameters, - and hardware bus interfaces all have very different - methods of use, and this should be taken into account by - the developer when developing the functional - specification, as well as by the evaluator evaluating - the functional specification. - - For administrative interfaces whose functionality is documented - as being inaccessible to untrusted users, the evaluator ensures - that the method of making the functions inaccessible is - described in the functional specification. It should be noted - that this inaccessibility needs to be tested by the developer in - their test suite. - - The evaluator should not only determine that the set of - method of use descriptions exist, but also that they - accurately cover each TSFI. - - - - - The evaluator shall examine the presentation of the TSFI - to determine that it completely identifies all - parameters associated with every TSFI. - - The evaluator examines the functional specification to - ensure that all of the parameters are described for each - TSFI. Parameters are explicit inputs or outputs to an - interface that control the behaviour of that - interface. For examples, parameters are the arguments - supplied to an API; the various fields in packet for a - given network protocol; the individual key values in the - Windows Registry; the signals across a set of pins on a - chip; etc. - - In order to determine that all of the parameters are - present in the TSFI, the evaluator should examine the - rest of the interface description (actions, error - messages, etc.) to determine if the effects of the - parameter are accounted for in the description. The - evaluator should also check other evidence provided for - the evaluation (e.g., TOE design, security architecture - description, operational user guidance, implementation - representation) to see if behaviour or additional - parameters are described there but not in the functional - specification. - - - - - The evaluator shall examine the presentation of the TSFI - to determine that it completely and accurately describes - all parameters associated with every TSFI. - - Once all of the parameters have been identified, the - evaluator needs to ensure that they are accurately - described, and that the description of the parameters is - complete. A parameter description tells what the - parameter is in some meaningful way. For instance, the - interface foo(i) could be described as - having ``parameter i which is an integer"; this is not - an acceptable parameter description. A description such - as ``parameter i is an integer that indicates the number - of users currently logged in to the system'' is much - more acceptable. - - In order to determine that the description of the - parameters is complete, the evaluator should examine the - rest of the interface description (purpose, method of - use, actions, error messages, etc.) to determine if the - descriptions of the parameter(s) are accounted for in - the description. The evaluator should also check other - evidence provided (e.g., TOE design, architectural - design, operational user guidance, implementation - representation) to see if behaviour or additional - parameters are described there but not in the functional - specification. - - - - - The evaluator shall examine the presentation of the TSFI - to determine that it completely and accurately describes - the SFR-enforcing actions associated with the - SFR-enforcing TSFIs. - - If an action available through an interface can be - traced to one of the SFRs levied on the TSF, then that - interface is SFR-enforcing. Such - policies are not limited to the access control policies, - but also refer to any functionality specified by one of - the SFRs contained in the ST. Note that it is possible - that an interface may have various actions and results, - some of which may be SFR-enforcing and some of which may not. - - The developer is not required to ``label'' interfaces as - SFR-enforcing, and likewise is not required to identify - actions available through an interface as SFR-enforcing. - It is the evaluator's responsibility to examine the - evidence provided by the developer and determine that - the required information is present. In the case where - the developer has identified the SFR-enforcing TSFI and - SFR-enforcing actions available through those TSFI, the - evaluator must judge completeness and accuracy based on - other information supplied for the evaluation (e.g., TOE - design, security architecture description, operational - user guidance), and on the other information presented - for the interfaces (parameters and parameter - descriptions, error messages, etc.). - - In this case (where the developer has provided only the - SFR-enforcing information for SFR-enforcing TSFI) the - evaluator also ensures that no interfaces have been - mis-categorised. This is done by examining other - information supplied for the evaluation (e.g., TOE - design, security architecture description, operational - user guidance), and the other information presented for - the interfaces (parameters and parameter descriptions, - for example) not labelled as SFR-enforcing. - - In the case where the developer has provided the same - level of information on all interfaces, the evaluator - performs the same type of analysis mentioned in the - previous paragraphs. The evaluator should determine - which interfaces are SFR-enforcing and which are not, - and subsequently ensure that the SFR-enforcing aspects - of the SFR-enforcing actions are appropriately - described. - The SFR-enforcing actions are those that are - visible at any external interface and that provide for - the enforcement of the SFRs being claimed. For example, - if audit requirements are included in the ST, then - audit-related actions would be SFR-enforcing and - therefore must be described, even if the result of that - action is generally not visible through the invoked - interface (as is often the case with audit, where a user - action at one interface would produce an audit record - visible at another interface). - - The level of description that is required is that - sufficient for the reader to understand what role the - TSFI actions play with respect to the SFR. The - evaluator should keep in mind that the description - should be detailed enough to support the generation (and - assessment) of test cases against that interface. If - the description is unclear or lacking detail such that - meaningful testing cannot be conducted against the TSFI, - it is likely that the description is inadequate. - - - - - The evaluator shall examine the presentation of the TSFI - to determine that it completely and accurately describes - error messages that may result from SFR-enforcing - actions associated with each SFR-enforcing TSFI. - - This work unit should be performed in conjunction with, - or after, work unit - in order to ensure the set of SFR-enforcing TSFI and - SFR-enforcing actions is correctly identified. The - developer may provide more information than is required - (for example, all error messages associated with each - interface), in which the case the evaluator should - restrict their assessment of completeness and accuracy - to only those that they determine to be associated with - SFR-enforcing actions of SFR-enforcing TSFI. - - Errors can take many forms, depending on the interface - being described. For an API, the interface itself may - return an error code, set a global error condition, or - set a certain parameter with an error code. For a - configuration file, an incorrectly configured parameter - may cause an error message to be written to a log - file. For a hardware PCI card, an error condition may - raise a signal on the bus, or trigger an exception - condition to the CPU. - - Errors (and the associated error messages) come about - through the invocation of an interface. The processing - that occurs in response to the interface invocation may - encounter error conditions, which trigger (through an - implementation-specific mechanism) an error message to - be generated. In some instances this may be a return - value from the interface itself; in other instances a - global value may be set and checked after the invocation - of an interface. It is likely that a TOE will have a - number of low-level error messages that may result from - fundamental resource conditions, such as ``disk full'' - or ``resource locked''. While these error messages may - map to a large number of TSFI, they could be used to - detect instances where detail from an interface - description has been omitted. For instance, a TSFI that - produces a ``disk full'' message, but has no obvious - description of why that TSFI should cause an access to - the disk in its description of actions, might cause the - evaluator to examine other evidence (, ) related - that TSFI to determine if the description is - accurate. - In order to determine that the description of the - error messages of a TSFI is accurate and complete, the - evaluator measures the interface description against the - other evidence provided for the evaluation (e.g., TOE - design, security architecture description, operational - user guidance), as well as other evidence available for - that TSFI (parameters, analysis from work unit ). - - - - The evaluator shall check that the tracing links the - SFRs to the corresponding TSFIs. - - The tracing is provided by the developer to serve as a - guide to which SFRs are related to which TSFIs. This - tracing can be as simple as a table; it is used as input - to the evaluator for use in the following work units, in - which the evaluator verifies its completeness and - accuracy. - - - - The evaluator shall determine that the functional - specification is an accurate and complete instantiation of - the SFRs. - - - The evaluator shall examine the functional specification - to determine that it is a complete instantiation of the - SFRs. - - To ensure that all SFRs are covered by the functional - specification, as well as the test coverage analysis, - the evaluator may build upon the developer's tracing - (see a map between - the TOE security functional requirements and the TSFI. - Note that this map may have to be at a level of detail - below the component or even element level of the - requirements, because of operations (assignments, - refinements, selections) performed on the functional - requirement by the ST author. - - For example, the - component contains an element with assignments. If the - ST contained, for instance, ten rules in the assignment, and these ten - rules were covered by three different TSFI, it would be - inadequate for the evaluator to map to TSFI A, B, and C and claim they had - completed the work unit. Instead, the evaluator would - map (rule 1) to TSFI A; - (rule 2) to TSFI B; - etc. It might also be the case that the interface is a - wrapper interface (e.g., IOCTL), in which case the - mapping would need to be specific to certain set of - parameters for a given interface. - - The evaluator must recognise that for requirements that - have little or no manifestation at the TSF boundary - (e.g., ) it is not - expected that they completely map those requirements to - the TSFI. The analysis for those requirements will be - performed in the analysis for the TOE design () when included in the ST. It is - also important to note that since the parameters, - actions, and error messages associated with TSFIs must - be fully specified, the evaluator should be able to - determine if all aspects of an SFR appear to be - implemented at the interface level. - - - - The evaluator shall examine the functional specification - to determine that it is an accurate instantiation of the - SFRs. - - For each functional requirement in the ST that results - in effects visible at the TSF boundary, the information - in the associated TSFI for that requirement specifies - the required functionality described by the - requirement. For example, if the ST contains a - requirement for access control lists, and the only TSFI - that map to that requirement specify functionality for - Unix-style protection bits, then the functional - specification is not accurate with respect to the - requirements. - - The evaluator must recognise that for requirements that - have little or no manifestation at the TSF boundary - (e.g., ) it is not - expected that the evaluator completely map those - requirements to the TSFI. The analysis for those - requirements will be performed in the analysis for the - TOE design () when - included in the ST. - - - - - - - - - The objective of this sub-activity is to determine whether - the developer has provided a description of the TSFIs in - terms of their purpose, method of use, and parameters. In - addition, the actions, results and error messages of each - TSFI are also described sufficiently that it can be - determined whether they are SFR-enforcing, with the - SFR-enforcing TSFI being described in more detail than - other TSFIs. - - - - The evaluation evidence for this sub-activity that is - required by the work-units is: - - - the ST; - - - the functional specification; - - - the TOE design. - - - - The evaluation evidence for this sub-activity that is used - if included in the ST for the TOE is: - - - the security architecture description; - - - the implementation representation; - - - the TSF internals description; - - - the operational user guidance; - - - - - The developer shall provide a functional specification. - - - The developer shall provide a tracing from the functional - specification to the SFRs. - - - The functional specification shall completely represent the - TSF. - - - The functional specification shall describe the purpose and - method of use for all TSFI. - - - The functional specification shall identify and describe all - parameters associated with each TSFI. - - - For each SFR-enforcing TSFI, the functional specification shall - describe the SFR-enforcing actions associated with the TSFI. - - - For each SFR-enforcing TSFI, the functional specification shall - describe direct error messages resulting from SFR-enforcing - actions and exceptions associated with invocation of the TSFI. - - - The functional specification shall summarise the SFR-supporting - and SFR-non-interfering actions associated with each TSFI. - - - The tracing shall demonstrate that the SFRs trace to TSFIs - in the functional specification. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the functional specification - to determine that the TSF is fully represented. - - The identification of the TSFI is a necessary - prerequisite to all other activities in this - sub-activity. The TSF must be identified (done as part - of the work units) in - order to identify the TSFI. This activity can be done at - a high level to ensure that no large groups of - interfaces have been missed (network protocols, hardware - interfaces, configuration files), or at a low level as - the evaluation of the functional specification - proceeds. - - In making an assessment for this work unit, the - evaluator determines that all portions of the TSF are - addressed in terms of the interfaces listed in the - functional specification. All portions of the TSF should - have a corresponding interface description, or if there - are no corresponding interfaces for a portion of the - TSF, the evaluator determines that that is - acceptable. - - - - - The evaluator shall examine the functional specification - to determine that it states the purpose of each - TSFI. - - The purpose of a TSFI is a general statement summarising - the functionality provided by the interface. It is not - intended to be a complete statement of the actions and - results related to the interface, but rather a statement - to help the reader understand in general what the - interface is intended to be used for. The evaluator - should not only determine that the purpose exists, but - also that it accurately reflects the TSFI by taking into - account other information about the interface, such as - the description of actions and error messages. - - - - - The evaluator shall examine the functional specification - to determine that the method of use for each TSFI is - given. - - The method of use for a TSFI summarises how the - interface is manipulated in order to invoke the actions - and obtain the results associated with the TSFI. The - evaluator should be able to determine, from reading this - material in the functional specification, how to use - each interface. This does not necessarily mean that - there needs to be a separate method of use for each - TSFI, as it may be possible to describe in general how - kernel calls are invoked, for instance, and then - identify each interface using that general - style. Different types of interfaces will require - different method of use specifications. APIs, network - protocol interfaces, system configuration parameters, - and hardware bus interfaces all have very different - methods of use, and this should be taken into account by - the developer when developing the functional - specification, as well as by the evaluator evaluating - the functional specification. - - For administrative interfaces whose functionality is documented - as being inaccessible to untrusted users, the evaluator ensures - that the method of making the functions inaccessible is - described in the functional specification. It should be noted - that this inaccessibility needs to be tested by the developer in - their test suite. - - The evaluator should not only determine that the set of - method of use descriptions exist, but also that they - accurately cover each TSFI. - - - - - The evaluator shall examine the presentation of the TSFI - to determine that it completely identifies all - parameters associated with every TSFI. - - The evaluator examines the functional specification to - ensure that all of the parameters are described for each - TSFI. Parameters are explicit inputs or outputs to an - interface that control the behaviour of that - interface. For examples, parameters are the arguments - supplied to an API; the various fields in packet for a - given network protocol; the individual key values in the - Windows Registry; the signals across a set of pins on a - chip; etc. - - In order to determine that all of the parameters are - present in the TSFI, the evaluator should examine the - rest of the interface description (actions, error - messages, etc.) to determine if the effects of the - parameter are accounted for in the description. The - evaluator should also check other evidence provided for - the evaluation (e.g., TOE design, security architecture - description, operational user guidance, implementation - representation) to see if behaviour or additional - parameters are described there but not in the functional - specification. - - - - - The evaluator shall examine the presentation of the TSFI - to determine that it completely and accurately describes - all parameters associated with every TSFI. - - Once all of the parameters have been identified, the - evaluator needs to ensure that they are accurately - described, and that the description of the parameters is - complete. A parameter description tells what the - parameter is in some meaningful way. For instance, the - interface foo(i) could be described as - having ``parameter i which is an integer''; this is not - an acceptable parameter description. A description such - as ``parameter i is an integer that indicates the number - of users currently logged in to the system'' is much - more acceptable. - - In order to determine that the description of the - parameters is complete, the evaluator should examine the - rest of the interface description (purpose, method of - use, actions, error messages, etc.) to determine if the - descriptions of the parameter(s) are accounted for in - the description. The evaluator should also check other - evidence provided (e.g., TOE design, architectural - design, operational user guidance, implementation - representation) to see if behaviour or additional - parameters are described there but not in the functional - specification. - - - - - The evaluator shall examine the presentation of the TSFI - to determine that it completely and accurately describes - the SFR-enforcing actions associated with the - SFR-enforcing TSFIs. - - If an action available through an interface plays a role - in enforcing any security policy on the TOE (that is, if - one of the actions of the interface can be traced to one - of the SFRs levied on the TSF), then that interface is - SFR-enforcing. Such policies are not - limited to the access control policies, but also refer - to any functionality specified by one of the SFRs - contained in the ST. Note that it is possible that an - interface may have various actions and results, some of - which may be SFR-enforcing and some of which may - not. - The developer is not required to ``label'' - interfaces as SFR-enforcing, and likewise is not - required to identify actions available through an - interface as SFR-enforcing. It is the evaluator's - responsibility to examine the evidence provided by the - developer and determine that the required information is - present. In the case where the developer has identified - the SFR-enforcing TSFI and SFR-enforcing actions - available through those TSFI, the evaluator must judge - completeness and accuracy based on other information - supplied for the evaluation (e.g., TOE design, security - architecture description, operational user guidance), - and on the other information presented for the - interfaces (parameters and parameter descriptions, error - messages, etc.). - - In this case (developer has provided only the - SFR-enforcing information for SFR-enforcing TSFI) the - evaluator also ensures that no interfaces have been - mis-categorised. This is done by examining other - information supplied for the evaluation (e.g., TOE - design, security architecture description, operational - user guidance), and the other information presented for - the interfaces (parameters and parameter descriptions, - for example) not labelled as SFR-enforcing. The analysis - done for work units - and are also used in - making this determination. - In the case where the developer has provided the - same level of information on all interfaces, the - evaluator performs the same type of analysis mentioned - in the previous paragraphs. The evaluator should - determine which interfaces are SFR-enforcing and which - are not, and subsequently ensure that the SFR-enforcing - aspects of the SFR-enforcing actions are appropriately - described. Note that in this case, the evaluator should - be able to perform the bulk of the work associated with - work unit in the - course of performing this SFR-enforcing analysis. - The SFR-enforcing actions are those that are - visible at any external interface and that provide for - the enforcement of the SFRs being claimed. For example, - if audit requirements are included in the ST, then - audit-related actions would be SFR-enforcing and - therefore must be described, even if the result of that - action is generally not visible through the invoked - interface (as is often the case with audit, where a user - action at one interface would produce an audit record - visible at another interface). - - The level of description that is required is that - sufficient for the reader to understand what role the - TSFI actions play with respect to the SFR. The - evaluator should keep in mind that the description - should be detailed enough to support the generation (and - assessment) of test cases against that interface. If - the description is unclear or lacking detail such that - meaningful testing cannot be conducted against the TSFI, - it is likely that the description is inadequate. - - - - - The evaluator shall examine the presentation of the TSFI - to determine that it completely and accurately describes - error messages that may result from an invocation of - each SFR-enforcing TSFI. - - This work unit should be performed in conjunction with, or - after, work unit in order - to ensure the set of SFR-enforcing TSFI is correctly identified. - The evaluator should note that the requirement and associated - work unit is that all direct error messages associated with an - SFR-enforcing TSFI must be described, that are associated with - SFR-enforcing actions. This is because at this level of - assurance, the ``extra'' information provided by the error - message descriptions should be used in determining whether all - of the SFR-enforcing aspects of an interface have been - appropriately described. For instance, if an error message - associated with a TSFI (e.g., ``access denied'') indicated that - an SFR-enforcing decision or action had taken place, but in the - description of the SFR-enforcing actions there was no mention of - that particular SFR-enforcing mechanism, then the description - may not be complete. - - Errors can take many forms, depending on the interface - being described. For an API, the interface itself may - return an error code, set a global error condition, or - set a certain parameter with an error code. For a - configuration file, an incorrectly configured parameter - may cause an error message to be written to a log - file. For a hardware PCI card, an error condition may - raise a signal on the bus, or trigger an exception - condition to the CPU. - - Errors (and the associated error messages) come about - through the invocation of an interface. The processing - that occurs in response to the interface invocation may - encounter error conditions, which trigger (through an - implementation-specific mechanism) an error message to - be generated. In some instances this may be a return - value from the interface itself; in other instances a - global value may be set and checked after the invocation - of an interface. It is likely that a TOE will have a - number of low-level error messages that may result from - fundamental resource conditions, such as ``disk full'' - or ``resource locked''. While these error messages may - map to a large number of TSFI, they could be used to - detect instances where detail from an interface - description has been omitted. For instance, a TSFI that - produces a ``disk full'' message, but has no obvious - description of why that TSFI should cause an access to - the disk in its description of actions, might cause the - evaluator to examine other evidence (, ) related - that TSFI to determine if the description is - accurate. - - In order to determine that the description of the error messages - of a TSFI is accurate and complete, the evaluator measures the - interface description against the other evidence provided for - the evaluation (e.g., TOE design, security architecture - description, operational user guidance), as well as for other - evidence supplied for that TSFI (description of SFR-enforcing - actions, summary of SFR-supporting and SFR-non-interfering - actions and results). - - - - - The evaluator shall examine the presentation of the TSFI to - determine that it summarises the SFR-supporting and - SFR-non-interfering actions associated with each TSFI. - - The purpose of this work unit is to supplement the details about - the SFR-enforcing actions (provided in work unit ) with a summary of the remaining - actions (i.e., those that are not SFR-enforcing). This covers - all SFR-supporting and SFR-non-interfering - actions, whether invokable through SFR-enforcing TSFI or through - SFR-supporting or SFR-non-interfering TSFI. Such a summary - about all SFR-supporting and SFR-non-interfering actions helps - to provide a more complete picture of the functions provided by - the TSF, and is to be used by the evaluator in determining - whether an action or TSFI may have been mis-categorised. - - The information to be provided is more abstract than that - required for SFR-enforcing actions. While it should still be - detailed enough so that the reader can understand what the - action does, the description does not have to be detailed enough - to support writing tests against it, for instance. For the - evaluator, the key is that the information must be sufficient to - make a positive determination that the action is SFR-supporting - or SFR-non-interfering. If that level of information is - missing, the summary is insufficient and more information must - be obtained. - - - - The evaluator shall check that the tracing links the - SFRs to the corresponding TSFIs. - - The tracing is provided by the developer to serve as a - guide to which SFRs are related to which TSFIs. This - tracing can be as simple as a table; it is used as input - to the evaluator for use in the following work units, in - which the evaluator verifies its completeness and - accuracy. - - - - The evaluator shall determine that the functional - specification is an accurate and complete instantiation of - the SFRs. - - - The evaluator shall examine the functional specification - to determine that it is a complete instantiation of the - SFRs. - - To ensure that all SFRs are covered by the functional - specification, as well as the test coverage analysis, - the evaluator may build upon the developer's tracing - (see a map between - the TOE security functional requirements and the TSFI. - Note that this map may have to be at a level of detail - below the component or even element level of the - requirements, because of operations (assignments, - refinements, selections) performed on the functional - requirement by the ST author. - - For example, the - component contains an element with assignments. If the - ST contained, for instance, ten rules in the assignment, and these ten - rules were covered by three different TSFI, it would be - inadequate for the evaluator to map to TSFI A, B, and C and claim they had - completed the work unit. Instead, the evaluator would - map (rule 1) to TSFI A; - (rule 2) to TSFI B; - etc. It might also be the case that the interface is a - wrapper interface (e.g., IOCTL), in which case the - mapping would need to be specific to certain set of - parameters for a given interface. - - The evaluator must recognise that for requirements that - have little or no manifestation at the TSF boundary - (e.g., ) it is not - expected that they completely map those requirements to - the TSFI. The analysis for those requirements will be - performed in the analysis for the TOE design () when included in the ST. It is - also important to note that since the parameters, - actions, and error messages associated with TSFIs must - be fully specified, the evaluator should be able to - determine if all aspects of an SFR appear to be - implemented at the interface level. - - - - The evaluator shall examine the functional specification - to determine that it is an accurate instantiation of the - SFRs. - - For each functional requirement in the ST that results - in effects visible at the TSF boundary, the information - in the associated TSFI for that requirement specifies - the required functionality described by the - requirement. For example, if the ST contains a - requirement for access control lists, and the only TSFI - that map to that requirement specify functionality for - Unix-style protection bits, then the functional - specification is not accurate with respect to the - requirements. - - The evaluator must recognise that for requirements that - have little or no manifestation at the TSF boundary - (e.g., ) it is not - expected that the evaluator completely map those - requirements to the TSFI. The analysis for those - requirements will be performed in the analysis for the - TOE design () when - included in the ST. - - - - - - - - - The objective of this sub-activity is to determine whether - the developer has completely described all of the TSFI in - a manner such that the evaluator is able to determine - whether the TSFI are completely and accurately described, - and appears to implement the security functional - requirements of the ST. - - - - The functional specification describes the interfaces to - the TSF (the TSFI) in a structured manner. Because of the - dependency on , the - evaluator is expected to have identified the TSF prior to - beginning work on this sub-activity. Without firm - knowledge of what comprises the TSF, it is not possible to - assess the completeness of the TSFI. - - In performing the various work units included in this family, - the evaluator is asked to make assessments of accuracy and - completeness of several factors (the TSFI itself, as well as the - individual components (parameters, actions, error messages, - etc.) of the TSFI). In doing this analysis, the evaluator is - expected to use the documentation provided for the - evaluation. This includes the ST, the TOE design, and may - include other documentation such as the operational user - guidance, security architecture description, and implementation - representation. The documentation should be examined in an - iterative fashion. The evaluator may read, for example, in the - TOE design how a certain function is implemented, but see no way - to invoke that function from the interface. This might cause the - evaluator to question the completeness of a particular TSFI - description, or whether an interface has been left out of the - functional specification altogether. Describing analysis - activities of this sort in the ETR is a key method in providing - rationale that the work units have been performed - appropriately. - - It should be recognised that there exist functional - requirements whose functionality is manifested wholly or - in part architecturally, rather than through a specific - mechanism. An example of this is the implementation of - mechanisms implementing the requirements. Such mechanisms typically are - implemented to ensure a behaviour isn't present, which is - difficult to test and typically is verified through - analysis. In the cases where such functional requirements - are included in the ST, it is expected that the evaluator - recognise that there may be SFRs of this type that have no - interfaces, and that this should not be considered a - deficiency in the functional specification. - - - - The evaluation evidence for this sub-activity that is - required by the work-units is: - - - the ST; - - - the functional specification; - - - the TOE design. - - - - The evaluation evidence for this sub-activity that is used - if included in the ST for the TOE is: - - - the security architecture description; - - - the implementation representation; - - - the TSF internals description; - - - the operational user guidance; - - - - - The developer shall provide a functional specification. - - - The developer shall provide a tracing from the functional - specification to the SFRs. - - - The functional specification shall completely represent the - TSF. - - - The functional specification shall describe the purpose and - method of use for all TSFI. - - - The functional specification shall identify and describe all - parameters associated with each TSFI. - - - The functional specification shall describe all actions - associated with each TSFI. - - - The functional specification shall describe all direct error - messages that may result from an invocation of each TSFI. - - - The tracing shall demonstrate that the SFRs trace to TSFIs - in the functional specification. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the functional specification - to determine that the TSF is fully represented. - - The identification of the TSFI is a necessary - prerequisite to all other activities in this - sub-activity. The TSF must be identified (done as part - of the work units) in - order to identify the TSFI. This activity can be done at - a high level to ensure that no large groups of - interfaces have been missed (network protocols, hardware - interfaces, configuration files), or at a low level as - the evaluation of the functional specification - proceeds. - - In making an assessment for this work unit, the - evaluator determines that all portions of the TSF are - addressed in terms of the interfaces listed in the - functional specification. All portions of the TSF should - have a corresponding interface description, or if there - are no corresponding interfaces for a portion of the - TSF, the evaluator determines that that is - acceptable. - - - - - The evaluator shall examine the functional specification - to determine that it states the purpose of each - TSFI. - - The purpose of a TSFI is a general statement summarising - the functionality provided by the interface. It is not - intended to be a complete statement of the actions and - results related to the interface, but rather a statement - to help the reader understand in general what the - interface is intended to be used for. The evaluator - should not only determine that the purpose exists, but - also that it accurately reflects the TSFI by taking into - account other information about the interface, such as - the description of actions and error messages. - - - - - The evaluator shall examine the functional specification - to determine that the method of use for each TSFI is - given. - - The method of use for a TSFI summarises how the - interface is manipulated in order to invoke the actions - and obtain the results associated with the TSFI. The - evaluator should be able to determine, from reading this - material in the functional specification, how to use - each interface. This does not necessarily mean that - there needs to be a separate method of use for each - TSFI, as it may be possible to describe in general how - kernel calls are invoked, for instance, and then - identify each interface using that general - style. Different types of interfaces will require - different method of use specifications. APIs, network - protocol interfaces, system configuration parameters, - and hardware bus interfaces all have very different - methods of use, and this should be taken into account by - the developer when developing the functional - specification, as well as by the evaluator evaluating - the functional specification. - - For administrative interfaces whose functionality is documented - as being inaccessible to untrusted users, the evaluator ensures - that the method of making the functions inaccessible is - described in the functional specification. It should be noted - that this inaccessibility needs to be tested by the developer in - their test suite. - - The evaluator should not only determine that the set of - method of use descriptions exist, but also that they - accurately cover each TSFI. - - The evaluator shall examine the functional specification to - determine the completeness of the TSFI - The evaluator shall use the design documentation to identify the possible types of - interfaces. The evaluator shall search the design documentation and the guidance - documentation for potential TSFI not contained in the developer's documentation, - thus indicating that the set of TSFI defined by the developer is incomplete. The - evaluator shall examine the arguments presented by the developer that the TSFI is - complete and check down to the lowest level of design or with the - implementation representation that no additional TSFI exist. - - - - The evaluator shall examine the presentation of the TSFI - to determine that it completely identifies all - parameters associated with every TSFI. - - The evaluator examines the functional specification to - ensure that all of the parameters are described for each - TSFI. Parameters are explicit inputs or outputs to an - interface that control the behaviour of that - interface. For examples, parameters are the arguments - supplied to an API; the various fields in packet for a - given network protocol; the individual key values in the - Windows Registry; the signals across a set of pins on a - chip; etc. - - In order to determine that all of the parameters are - present in the TSFI, the evaluator should examine the - rest of the interface description (actions, error - messages, etc.) to determine if the effects of the - parameter are accounted for in the description. The - evaluator should also check other evidence provided for - the evaluation (e.g., TOE design, security architecture - description, operational user guidance, implementation - representation) to see if behaviour or additional - parameters are described there but not in the functional - specification. - - - - - The evaluator shall examine the presentation of the TSFI - to determine that it completely and accurately describes - all parameters associated with every TSFI. - - Once all of the parameters have been identified, the - evaluator needs to ensure that they are accurately - described, and that the description of the parameters is - complete. A parameter description tells what the - parameter is in some meaningful way. For instance, the - interface foo(i) could be described as - having ``parameter i which is an integer''; this is not - an acceptable parameter description. A description such - as ``parameter i is an integer that indicates the number - of users currently logged in to the system'' is much - more acceptable. - - In order to determine that the description of the - parameters is complete, the evaluator should examine the - rest of the interface description (purpose, method of - use, actions, error messages, etc.) to determine if the - descriptions of the parameter(s) are accounted for in - the description. The evaluator should also check other - evidence provided (e.g., TOE design, architectural - design, operational user guidance, implementation - representation) to see if behaviour or additional - parameters are described there but not in the functional - specification. - - - - - The evaluator shall examine the presentation of the TSFI - to determine that it completely and accurately describes - all actions associated with every TSFI. - - The evaluator checks to ensure that all of the actions - are described. actions available through an interface - describe what the interface does (as opposed to the TOE - design, which describes how the actions are provided by - the TSF). - - Actions of an interface describe functionality that can - be invoked through the interface, and can be categorised - as regular actions, and - SFR-related actions. Regular actions - are descriptions of what the interface does. The amount - of information provided for this description is - dependant on the complexity of the interface. The - SFR-related actions are those that are visible at any - external interface (for instance, audit activity caused - by the invocation of an interface (assuming audit - requirements are included in the ST) should be - described, even though the result of that action is - generally not visible through the invoked - interface). Depending on the parameters of an interface, - there may be many different actions able to be invoked - through the interface (for instance, an API might have - the first parameter be a ``subcommand'', and the - following parameters be specific to that subcommand. The - IOCTL API in some Unix systems is an example of such an - interface). - - In order to determine that the description of the - actions of a TSFI is complete, the evaluator should - review the rest of the interface description (parameter - descriptions, error messages, etc.) to determine if the - actions described are accounted for. The evaluator - should also analyse other evidence provided for the - evaluation (e.g., TOE design, security architecture - description, operational user guidance, implementation - representation) to see if there is evidence of actions - that are described there but not in the functional - specification. - - - - - The evaluator shall examine the presentation of the TSFI - to determine that it completely and accurately describes - all errors messages resulting from an invocation of each - TSFI. - - Errors can take many forms, depending on the interface - being described. For an API, the interface itself may - return an error code; set a global error condition, or - set a certain parameter with an error code. For a - configuration file, an incorrectly configured parameter - may cause an error message to be written to a log - file. For a hardware PCI card, an error condition may - raise a signal on the bus, or trigger an exception - condition to the CPU. - - Errors (and the associated error messages) come about - through the invocation of an interface. The processing - that occurs in response to the interface invocation may - encounter error conditions, which trigger (through an - implementation-specific mechanism) an error message to - be generated. In some instances this may be a return - value from the interface itself; in other instances a - global value may be set and checked after the invocation - of an interface. It is likely that a TOE will have a - number of low-level error messages that may result from - fundamental resource conditions, such as ``disk full'' - or ``resource locked''. While these error messages may - map to a large number of TSFI, they could be used to - detect instances where detail from an interface - description has been omitted. For instance, a TSFI that - produces a ``disk full'' message, but has no obvious - description of why that TSFI should cause an access to - the disk in its description of actions, might cause the - evaluator to examine other evidence (, ) related - that TSFI to determine if the description is complete - and accurate. - - The evaluator determines that, for each TSFI, the exact - set of error messages that can be returned on invoking - that interface can be determined. The evaluator reviews - the evidence provided for the interface to determine if - the set of errors seems complete. They cross-check this - information with other evidence provided for the - evaluation (e.g., TOE design, security architecture - description, operational user guidance, implementation - representation) to ensure that there are no errors - steaming from processing mentioned that are not included - in the functional specification. - - - - - The evaluator shall examine the presentation of the TSFI to determine - that it completely and accurately describes the meaning of all - error messages resulting from an invocation of each TSFI. - - In order to determine accuracy, the evaluator must be - able to understand meaning of the error. For example, if - an interface returns a numeric code of 0, 1, or 2, the - evaluator would not be able to understand the error if - the functional specification only listed: ``possible - errors resulting from invocation of the - foo() interface are 0, 1, or - 2''. Instead the evaluator checks to ensure that the - errors are described such as: ``possible errors - resulting from invocation of the foo() - interface are 0 (processing successful), 1 (file not - found), or 2 (incorrect filename - specification)''. - - In order to determine that the description of the errors - due to invoking a TSFI is complete, the evaluator - examines the rest of the interface description - (parameter descriptions, actions, etc.) to determine if - potential error conditions that might be caused by using - such an interface are accounted for. The evaluator also - checks other evidence provided for the evaluation - (e.g. TOE design, security architecture description, - operational user guidance, implementation - representation) to see if error processing related to - the TSFI is described there but is not described in the - functional specification. - - - - The evaluator shall check that the tracing links the - SFRs to the corresponding TSFIs. - - The tracing is provided by the developer to serve as a - guide to which SFRs are related to which TSFIs. This - tracing can be as simple as a table; it is used as input - to the evaluator for use in the following work units, in - which the evaluator verifies its completeness and - accuracy. - - - - The evaluator shall determine that the functional - specification is an accurate and complete instantiation of - the SFRs. - - - The evaluator shall examine the functional specification - to determine that it is a complete instantiation of the - SFRs. - - To ensure that all SFRs are covered by the functional - specification, as well as the test coverage analysis, - the evaluator may build upon the developer's tracing - (see a map between - the TOE security functional requirements and the TSFI. - Note that this map may have to be at a level of detail - below the component or even element level of the - requirements, because of operations (assignments, - refinements, selections) performed on the functional - requirement by the ST author. - - For example, the - component contains an element with assignments. If the - ST contained, for instance, ten rules in the assignment, and these ten - rules were covered by three different TSFI, it would be - inadequate for the evaluator to map to TSFI A, B, and C and claim they had - completed the work unit. Instead, the evaluator would - map (rule 1) to TSFI A; - (rule 2) to TSFI B; - etc. It might also be the case that the interface is a - wrapper interface (e.g., IOCTL), in which case the - mapping would need to be specific to certain set of - parameters for a given interface. - - The evaluator must recognise that for requirements that - have little or no manifestation at the TSF boundary - (e.g., ) it is not - expected that they completely map those requirements to - the TSFI. The analysis for those requirements will be - performed in the analysis for the TOE design () when included in the ST. It is - also important to note that since the parameters, - actions, and error messages associated with TSFIs must - be fully specified, the evaluator should be able to - determine if all aspects of an SFR appear to be - implemented at the interface level. - - - - The evaluator shall examine the functional specification - to determine that it is an accurate instantiation of the - SFRs. - - For each functional requirement in the ST that results - in effects visible at the TSF boundary, the information - in the associated TSFI for that requirement specifies - the required functionality described by the - requirement. For example, if the ST contains a - requirement for access control lists, and the only TSFI - that map to that requirement specify functionality for - Unix-style protection bits, then the functional - specification is not accurate with respect to the - requirements. - - The evaluator must recognise that for requirements that - have little or no manifestation at the TSF boundary - (e.g., ) it is not - expected that the evaluator completely map those - requirements to the TSFI. The analysis for those - requirements will be performed in the analysis for the - TOE design () when - included in the ST. - - - - - - - - - - The objective of this sub-activity is to determine whether - the developer has completely described all of the TSFI in - a manner such that the evaluator is able to determine - whether the TSFI are completely and accurately described, - and appears to implement the security functional - requirements of the ST. The completeness of the interfaces - is judged based upon the implementation - representation. - - - - The evaluation evidence for this sub-activity that is - required by the work-units is: - - - the ST; - - - the functional specification; - - - the TOE design; - - - the implementation representation. - - - - The evaluation evidence for this sub-activity that is used - if included in the ST for the TOE is: - - - the security architecture description; - - - the TSF internals description; - - - the formal security policy model; - - - the operational user guidance; - - - - - The developer shall provide a functional specification. - - - The developer shall provide a tracing from the functional - specification to the SFRs. - - - The functional specification shall completely represent the - TSF. - - - The functional specification shall describe the TSFI using a - semi-formal style. - - - The functional specification shall describe the purpose and - method of use for all TSFI. - - - The functional specification shall identify and describe all - parameters associated with each TSFI. - - - The functional specification shall describe all actions - associated with each TSFI. - - - The functional specification shall describe all direct error - messages that may result from an invocation of each TSFI. - - The functional specification - shall describe all error messages that do not result from an - invocation of a TSFI. - - - The functional specification shall provide a rationale for - each error message contained in the TSF implementation yet - does not result from an invocation of a TSFI. - - - The tracing shall demonstrate that the SFRs trace to TSFIs - in the functional specification. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - The evaluator shall examine the functional specification - to determine that the TSF is fully represented. - - The identification of the TSFI is a necessary - prerequisite to all other activities in this - sub-activity. The TSF must be identified (done as part - of the work units) in - order to identify the TSFI. This activity can be done at - a high level to ensure that no large groups of - interfaces have been missed (network protocols, hardware - interfaces, configuration files), or at a low level as - the evaluation of the functional specification - proceeds. - - In making an assessment for this work unit, the - evaluator determines that all portions of the TSF are - addressed in terms of the interfaces listed in the - functional specification. All portions of the TSF should - have a corresponding interface description, or if there - are no corresponding interfaces for a portion of the - TSF, the evaluator determines that that is - acceptable. - - - - - The evaluator shall examine the functional specification - to determine that it is presented using a semiformal - style. - - A semi-formal presentation is characterised by a - standardised format with a well-defined syntax that - reduces ambiguity that may occur in informal - presentations. Since the intent of the semi-formal - format is to enhance the reader's ability to understand - the presentation, use of certain structured presentation - methods (pseudo-code, flow charts, block diagrams) are - appropriate, though not required. - - For the purposes of this activity, the evaluator should - ensure that the interface descriptions are formatted in - a structured, consistent manner and use common - terminology. A semiformal presentation of the interfaces - also implies that the level of detail of the - presentation for the interfaces is largely consistent - across all TSFI. For the functional specification, it is - acceptable to refer to external specifications for - portions of the interface as long as those external - specifications are themselves semiformal. - - - - - The evaluator shall examine the functional specification - to determine that it states the purpose of each - TSFI. - - The purpose of a TSFI is a general statement summarising - the functionality provided by the interface. It is not - intended to be a complete statement of the actions and - results related to the interface, but rather a statement - to help the reader understand in general what the - interface is intended to be used for. The evaluator - should not only determine that the purpose exists, but - also that it accurately reflects the TSFI by taking into - account other information about the interface, such as - the description of actions and error messages. - - - - - The evaluator shall examine the functional specification - to determine that the method of use for each TSFI is - given. - - The method of use for a TSFI summarises how the - interface is manipulated in order to invoke the actions - and obtain the results associated with the TSFI. The - evaluator should be able to determine, from reading this - material in the functional specification, how to use - each interface. This does not necessarily mean that - there needs to be a separate method of use for each - TSFI, as it may be possible to describe in general how - kernel calls are invoked, for instance, and then - identify each interface using that general - style. Different types of interfaces will require - different method of use specifications. APIs, network - protocol interfaces, system configuration parameters, - and hardware bus interfaces all have very different - methods of use, and this should be taken into account by - the developer when developing the functional - specification, as well as by the evaluator evaluating - the functional specification. - - For administrative interfaces whose functionality is documented - as being inaccessible to untrusted users, the evaluator ensures - that the method of making the functions inaccessible is - described in the functional specification. It should be noted - that this inaccessibility needs to be tested by the developer in - their test suite. - - The evaluator should not only determine that the set of - method of use descriptions exist, but also that they - accurately cover each TSFI. - - The evaluator shall examine the functional specification to - determine the completeness of the TSFI - The evaluator shall use the design documentation to identify the possible types of - interfaces. The evaluator shall search the design documentation and the guidance - documentation for potential TSFI not contained in the developer's documentation, - thus indicating that the set of TSFI defined by the developer is incomplete. The - evaluator shall examine the arguments presented by the developer that the TSFI is - complete and check down to the lowest level of design or with the - implementation representation that no additional TSFI exist. - - - - The evaluator shall examine the presentation of the TSFI - to determine that it completely identifies all - parameters associated with every TSFI. - - The evaluator examines the functional specification to - ensure that all of the parameters are described for each - TSFI. Parameters are explicit inputs or outputs to an - interface that control the behaviour of that - interface. For examples, parameters are the arguments - supplied to an API; the various fields in packet for a - given network protocol; the individual key values in the - Windows Registry; the signals across a set of pins on a - chip; etc. - - In order to determine that all of the parameters are - present in the TSFI, the evaluator should examine the - rest of the interface description (actions, error - messages, etc.) to determine if the effects of the - parameter are accounted for in the description. The - evaluator should also check other evidence provided for - the evaluation (e.g., TOE design, security architecture - description, operational user guidance, implementation - representation) to see if behaviour or additional - parameters are described there but not in the functional - specification. - - - - - The evaluator shall examine the presentation of the TSFI - to determine that it completely and accurately describes - all parameters associated with every TSFI. - - Once all of the parameters have been identified, the - evaluator needs to ensure that they are accurately - described, and that the description of the parameters is - complete. A parameter description tells what the - parameter is in some meaningful way. For instance, the - interface foo(i) could be described as - having ``parameter i which is an integer''; this is not - an acceptable parameter description. A description such - as ``parameter i is an integer that indicates the number - of users currently logged in to the system''. is much - more acceptable. - - In order to determine that the description of the - parameters is complete, the evaluator should examine the - rest of the interface description (purpose, method of - use, actions, error messages, etc.) to determine if the - descriptions of the parameter(s) are accounted for in - the description. The evaluator should also check other - evidence provided (e.g., TOE design, architectural - design, operational user guidance, implementation - representation) to see if behaviour or additional - parameters are described there but not in the functional - specification. - - - - - The evaluator shall examine the presentation of the TSFI - to determine that it completely and accurately describes - all actions associated with every TSFI. - - The evaluator checks to ensure that all of the actions - are described. actions available through an interface - describe what the interface does (as opposed to the TOE - design, which describes how the actions are provided by - the TSF). - - actions of an interface describe functionality that can - be invoked through the interface, and can be categorised - as regular actions, and - SFR-related actions. Regular actions - are descriptions of what the interface does. The amount - of information provided for this description is - dependant on the complexity of the interface. The - SFR-related actions are those that are visible at any - external interface (for instance, audit activity caused - by the invocation of an interface (assuming audit - requirements are included in the ST) should be - described, even though the result of that action is - generally not visible through the invoked - interface). Depending on the parameters of an interface, - there may be many different actions able to be invoked - through the interface (for instance, an API might have - the first parameter be a ``subcommand'', and the - following parameters be specific to that subcommand. The - IOCTL API in some Unix systems is an example of such an - interface). - In order to determine that the description of the - actions of a TSFI is complete, the evaluator should - review the rest of the interface description (parameter - descriptions, error messages, etc.) to determine if the - actions described are accounted for. The evaluator - should also analyse other evidence provided for the - evaluation (e.g., TOE design, security architecture - description, operational user guidance, implementation - representation) to see if there is evidence of actions - that are described there but not in the functional - specification. - - - - - The evaluator shall examine the presentation of the TSFI - to determine that it completely and accurately describes - all errors messages resulting from an invocation of each - TSFI. - - Errors can take many forms, depending on the interface - being described. For an API, the interface itself may - return an error code; set a global error condition, or - set a certain parameter with an error code. For a - configuration file, an incorrectly configured parameter - may cause an error message to be written to a log - file. For a hardware PCI card, an error condition may - raise a signal on the bus, or trigger an exception - condition to the CPU. - - Errors (and the associated error messages) come about - through the invocation of an interface. The processing - that occurs in response to the interface invocation may - encounter error conditions, which trigger (through an - implementation-specific mechanism) an error message to - be generated. In some instances this may be a return - value from the interface itself; in other instances a - global value may be set and checked after the invocation - of an interface. It is likely that a TOE will have a - number of low-level error messages that may result from - fundamental resource conditions, such as ``disk full'' - or ``resource locked''. While these error messages may - map to a large number of TSFI, they could be used to - detect instances where detail from an interface - description has been omitted. For instance, a TSFI that - produces a ``disk full'' message, but has no obvious - description of why that TSFI should cause an access to - the disk in its description of actions, might cause the - evaluator to examine other evidence (, ) related - that TSFI to determine if the description is complete - and accurate. - - The evaluator determines that, for each TSFI, the exact - set of error messages that can be returned on invoking - that interface can be determined. The evaluator reviews - the evidence provided for the interface to determine if - the set of errors seems complete. They cross-check this - information with other evidence provided for the - evaluation (e.g., TOE design, security architecture - description, operational user guidance, implementation - representation) to ensure that there are no errors - steaming from processing mentioned that are not included - in the functional specification. - - - - - The evaluator shall examine the presentation of the TSFI to determine - that it completely and accurately describes the meaning of all - error messages resulting from an invocation of each TSFI. - - In order to determine accuracy, the evaluator must be - able to understand meaning of the error. For example, if - an interface returns a numeric code of 0, 1, or 2, the - evaluator would not be able to understand the error if - the functional specification only listed: ``possible - errors resulting from invocation of the - foo() interface are 0, 1, or - 2''. Instead the evaluator checks to ensure that the - errors are described such as: ``possible errors - resulting from invocation of the foo() - interface are 0 (processing successful), 1 (file not - found), or 2 (incorrect filename - specification)''. - - In order to determine that the description of the errors - due to invoking a TSFI is complete, the evaluator - examines the rest of the interface description - (parameter descriptions, actions, etc.) to determine if - potential error conditions that might be caused by using - such an interface are accounted for. The evaluator also - checks other evidence provided for the evaluation (e.g., - TOE design, security architecture description, - operational user guidance, implementation - representation) to see if error processing related to - the TSFI is described there but is not described in the - functional specification. - - - - - The evaluator shall examine the functional specification - to determine that it completely and accurately describes - all errors messages that do not result from an - invocation of any TSFI. - - This work unit complements work unit , which describes those - error messages that result from an invocation of the - TSFI. Taken together, these work units cover all error - messages that might be generated by the TSF. - - The evaluator assesses the completeness and accuracy of - the functional specification by comparing its contents - to instances of error message generation within the - implementation representation. Most of these error - messages will have already been covered by work unit - . - - The error messages related to this work unit are - typically those that are not expected to be generated, - but are constructed as a matter of good programming - practises. For example, a case statement that defines - actions resulting from each of a list of cases may end - with a final else statement to apply - to anything that might not be expected; this practise - ensures the TSF does not get into an undefined state. - However, it is not expected that the path of execution - would ever get to this else - statement; therefore, any error message generation - within this else statement would - never be generated. Although it would not get - generated, it must still be included in the functional - specification. - - - - - The evaluator shall examine the functional specification - to determine that it provides a rationale for each error - message contained in the TSF implementation yet does not - result from an invocation of a TSFI. - - The evaluator ensures that every error message found - under work unit - contains a rationale describing why it cannot be invoked - from the TSFI. - - As was described in the previous work unit, this - rationale might be as straightforward as the fact that - the error message in question is provided for - completeness of execution logic and that it is never - expected to be generated. The evaluator ensures that the - rationale for each such error message is logical. - - - - The evaluator shall check that the tracing links the - SFRs to the corresponding TSFIs. - - The tracing is provided by the developer to serve as a - guide to which SFRs are related to which TSFIs. This - tracing can be as simple as a table; it is used as input - to the evaluator for use in the following work units, in - which the evaluator verifies its completeness and - accuracy. - - - - The evaluator shall determine that the functional - specification is an accurate and complete instantiation of - the SFRs. - - - The evaluator shall examine the functional specification - to determine that it is a complete instantiation of the - SFRs. - - To ensure that all SFRs are covered by the functional - specification, as well as the test coverage analysis, - the evaluator may build upon the developer's tracing - (see a map between - the TOE security functional requirements and the TSFI. - Note that this map may have to be at a level of detail - below the component or even element level of the - requirements, because of operations (assignments, - refinements, selections) performed on the functional - requirement by the ST author. - - For example, the - component contains an element with assignments. If the - ST contained, for instance, ten rules in the assignment, and these ten - rules were covered by three different TSFI, it would be - inadequate for the evaluator to map to TSFI A, B, and C and claim they had - completed the work unit. Instead, the evaluator would - map (rule 1) to TSFI A; - (rule 2) to TSFI B; - etc. It might also be the case that the interface is a - wrapper interface (e.g., IOCTL), in which case the - mapping would need to be specific to certain set of - parameters for a given interface. - - The evaluator must recognise that for requirements that - have little or no manifestation at the TSF boundary - (e.g., ) it is not - expected that they completely map those requirements to - the TSFI. The analysis for those requirements will be - performed in the analysis for the TOE design () when included in the ST. It is - also important to note that since the parameters, - actions, and error messages associated with TSFIs must - be fully specified, the evaluator should be able to - determine if all aspects of an SFR appear to be - implemented at the interface level. - - - - The evaluator shall examine the functional specification - to determine that it is an accurate instantiation of the - SFRs. - - For each functional requirement in the ST that results - in effects visible at the TSF boundary, the information - in the associated TSFI for that requirement specifies - the required functionality described by the - requirement. For example, if the ST contains a - requirement for access control lists, and the only TSFI - that map to that requirement specify functionality for - Unix-style protection bits, then the functional - specification is not accurate with respect to the - requirements. - - The evaluator must recognise that for requirements that - have little or no manifestation at the TSF boundary - (e.g., ) it is not - expected that the evaluator completely map those - requirements to the TSFI. The analysis for those - requirements will be performed in the analysis for the - TOE design () when - included in the ST. - - - - - - - - - (Need Objectives text for FSP.6 methodology) - - - - The evaluation evidence for this sub-activity that is - required by the work-units is: - - - the ST; - - - the functional specification; - - - the TOE design. - - - - The evaluation evidence for this sub-activity that is used - if included in the ST for the TOE is: - - - the security architecture description; - - - the implementation representation; - - - the TSF internals description; - - - the formal security policy model; - - - the operational user guidance; - - - - - The developer shall provide a functional specification. - - - The developer shall provide a formal presentation of the - functional specification of the TSF. - - - The developer shall provide a tracing from the functional - specification to the SFRs. - - - The functional specification shall completely represent the - TSF. - - - The functional specification shall describe the TSFI using a - formal style. - - - The functional specification shall describe the purpose and - method of use for all TSFI. - - - The functional specification shall identify and describe all - parameters associated with each TSFI. - - - The functional specification shall describe all actions - associated with each TSFI. - - - The functional specification shall describe all direct error - messages that may result from an invocation of each TSFI. - - - The functional specification shall describe all error messages - contained in the TSF implementation representation. - - - The functional specification shall provide a rationale for - each error message contained in the TSF implementation that - is not otherwise described in the functional specification - justifying why it is not associated with a TSFI. - - - The formal presentation of the functional specification of - the TSF shall describe the TSFI using a formal style, - supported by informal, explanatory text where appropriate. - - - The tracing shall demonstrate that the SFRs trace to TSFIs - in the functional specification. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - The evaluator shall determine that the functional - specification is an accurate and complete instantiation of - the SFRs. - - - - - - - The function of the family - is for the developer to make available the implementation - representation (and, at higher levels, the implementation - itself) of the TOE in a form that can be analysed by the - evaluator. The implementation representation is used in - analysis activities for other families (analysing the TOE - design, for instance) to demonstrate that the TOE conforms - its design and to provide a basis for analysis in other - areas of the evaluation (e.g., the search for - vulnerabilities). The implementation representation is - expected to be in a form that captures the detailed internal - workings of the TSF. This may be software source code, - firmware source code, hardware diagrams and/or IC hardware - design language code or layout data. - - - - The implementation representation of the TOE is made - available so that it can be analysed by the evaluator to - demonstrate that the TOE conforms its design and to provide - a basis for analysis in other areas of the evaluation (e.g., - the search for vulnerabilities). The implementation - representation captures the detailed internal workings of - the TSF. This may be software source code, firmware source - code, hardware diagrams and/or chip specifications. - - - - The components in this family are levelled on the amount of - implementation that is mapped to the TOE design - description. - - - - Source code or hardware diagrams and/or IC hardware design - language code or layout data that are used to build the - actual hardware are examples of parts of an implementation - representation. It is important to note that while the - implementation representation must be made available to the - evaluator, this does not imply that the evaluator needs to - possess that representation. For instance, the developer may - require that the evaluator review the implementation - representation at a site of the developer's choosing. - - The entire implementation representation is made available - to ensure that analysis activities are not curtailed due to - lack of information. This does not, however, imply that all - of the representation is examined when the analysis - activities are being performed. This is likely impractical - in almost all cases, in addition to the fact that it most - likely will not result in a higher-assurance TOE - vs. targeted sampling of the implementation - representation. The implementation representation is made - available to allow analysis of other TOE design - decompositions (e.g., functional specification, TOE design), - and to gain confidence that the security functionality - described at a higher level in the design actually appear to - be implemented in the TOE. Conventions in some forms of the - implementation representation may make it difficult or - impossible to determine from just the implementation - representation itself what the actual result of the - compilation or run-time interpretation will be. For example, - compiler directives for C language compilers will cause the - compiler to exclude or include entire portions of the - code. For this reason, it is important that such ``extra'' - information or related tools (scripts, compilers, etc.) be - provided so that the implementation representation can be - accurately determined. - - The purpose of the mapping between the implementation - representation and the TOE design description is to aid the - evaluator's analysis. The internal workings of the TOE may - be better understood when the TOE design is analysed with - corresponding portions of the implementation representation. - The mapping serves as an index into the implementation - representation. At the lower component, only a subset of the - implementation representation is mapped to the TOE design - description. Because of the uncertainty of which portions of - the implementation representation will need such a mapping, - the developer may choose either to map the entire - implementation representation beforehand, or to wait to see - which portions of the implementation representation the - evaluator requires to be mapped. - - The implementation representation is manipulated by the - developer in a form that is suitable for transformation to - the actual implementation. For instance, the developer may - work with files containing source code, which is eventually - compiled to become part of the TSF. The developer makes - available the implementation representation in the form used - by the developer, so that the evaluator may use automated - techniques in the analysis. This also increases the - confidence that the implementation representation examined - is actually the one used in the production of the TSF (as - opposed to the case where it is supplied in an alternate - presentation format, such as a word processor document). It - should be noted that other forms of the implementation - representation may also be used by the developer; these - forms are supplied as well. The overall goal is to supply - the evaluator with the information that will maximise the - effectiveness of the evaluator's analysis efforts. - - Some forms of the implementation representation may require - additional information because they introduce significant - barriers to understanding and analysis. Examples include - ``shrouded'' source code or source code that has been - obfuscated in other ways such that it prevents understanding - and/or analysis. These forms of implementation - representation typically result from the TOE developer - taking a version of the implementation representation and - running a shrouding or obfuscation program on it. While the - shrouded representation is what is compiled and may be - closer to the implementation (in terms of structure) than - the original, un-shrouded representation, supplying such - obfuscated code may cause significantly more time to be - spent in analysis tasks involving the representation. When - such forms of representation are created, the components - require details on the shrouding tools/algorithms used so - that the un-shrouded representation can be supplied, and the - additional information can be used to gain confidence that - the shrouding process does not compromise any security - functionality. - - - - - - - The objective of this sub-activity is to determine that - the implementation representation made available by the - developer is suitable for use in other analysis - activities; suitability is judged by its - conformance to the requirements for this component. - - - - The entire implementation representation is made available - to ensure that analysis activities are not curtailed due - to lack of information. This does not, however, imply that - all of the representation is examined when the analysis - activities are being performed. This is likely impractical - in almost all cases, in addition to the fact that it most - likely will not result in a higher-assurance TOE - vs. targeted sampling of the implementation - representation. For this sub-activity, this is even - truer. It would not be productive for the evaluator to - spend large amounts of time verifying the requirements for - one portion of the implementation representation, and then - use a different portion of the implementation - representation in performing analysis for other work - units. Therefore, the evaluator is encouraged to select - the sample of the implementation representation from the - areas of the TOE that will be of most interest during the - analysis performed during work units from other families - (e.g. , and ). - - - - The evaluation evidence for this sub-activity is: - - - the implementation representation; - - - the documentation of the development tools, as - resulting from ; - - - TOE design description. - - - - - The developer shall make available the implementation - representation for the entire TSF. - - - The developer shall provide a mapping between the TOE design - description and the sample of the implementation - representation. - - - The implementation representation shall define the TSF to a - level of detail such that the TSF can be generated without - further design decisions. - - - The implementation representation shall be in the form used - by the development personnel. - - - The mapping between the TOE design description and the - sample of the implementation representation shall - demonstrate their correspondence. - - - The evaluator shall confirm that, for the selected sample of - the implementation representation, the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the implementation - representation defines the TSF to a level of detail such - that the TSF can be generated without further design - decisions. - - Source code or hardware diagrams and/or IC hardware - design language code or layout data that are used to - build the actual hardware are examples of parts of an - implementation representation. The evaluator samples the - implementation representation to gain confidence that it - is at the appropriate level and not, for instance, a - pseudo-code level which requires additional design - decisions to be made. The evaluator is encouraged to - perform a quick check when first looking at the - implementation representation to assure themselves that - the developer is on the right track. However, the - evaluator is also encourage to perform the bulk of this - check while working on other work units that call for - examining the implementation; this will ensure the - sample examined for this work unit is relevant. - - - - - The evaluator shall check that the implementation - representation is in the form used by development - personnel. - - The implementation representation is manipulated by the - developer in form that it suitable for transformation to - the actual implementation. For instance, the developer - may work with files containing source code, which is - eventually compiled to become part of the TSF. The - developer makes available the implementation - representation in the form they use, so that the - evaluator may use automated techniques in the - analysis. This also increases the confidence that the - implementation representation examined is actually the - one used in the production of the TSF (as opposed to the - case where it is supplied in an alternate presentation - format, such as a word processor document). It should be - noted that other forms of the implementation - representation may also be used by the developer; these - forms are supplied as well. The overall goal is to - supply the evaluator with the information that will - maximise the evaluator's analysis efforts. - - The evaluator samples the implementation representation - to gain confidence that it is the version that is usable - by the developer. The sample is such that the evaluator - has assurance that all areas of the implementation - representation are in conformance with the requirement; - however, a complete examination of the entire - implementation representation is unnecessary. - - Conventions in some forms of the implementation - representation may make it difficult or impossible to - determine from just the implementation representation - itself what the actual result of the compilation or - run-time interpretation will be. For example, compiler - directives for C language compilers will cause the - compiler to exclude or include entire portions of the - code. - - Some forms of the implementation representation may - require additional information because they introduce - significant barriers to understanding and - analysis. Examples include shrouded source code or - source code that has been obfuscated in other ways such - that it prevents understanding and/or analysis. These - forms of implementation representation typically result - from by taking a version of the implementation - representation that is used by the TOE developer and - running a shrouding or obfuscation program on it. While - the shrouded representation is what is compiled and may - be closer to the implementation (in terms of structure) - than the original, un-shrouded representation, supplying - such obfuscated code may cause significantly more time - to be spent in analysis tasks involving the - representation. When such forms of representation are - created, the components require details on the shrouding - tools/algorithms used so that the un-shrouded - representation can be supplied, and the additional - information can be used to gain confidence that the - shrouding process does not compromise any security - mechanisms. - - The evaluator samples the implementation representation - to gain confidence that all of the information needed to - interpret the implementation representation has been - supplied. Note that the tools are among those referenced - by components. The - evaluator is encouraged to perform a quick check when - first looking at the implementation representation to - assure themselves that the developer is on the right - track. However, the evaluator is also encouraged to - perform the bulk of this check while working on other - work units that call for examining the implementation; - this will ensure the sample examined for this work unit - is relevant. - - - - - The evaluator shall examine the mapping between the TOE - design description and the sample of the implementation - representation to determine that it is accurate. - - The evaluator augments the determination of existence - (specified in work unit ) by verifying the accuracy of a portion of - the implementation representation and the TOE design - description. For parts of the TOE design description - that are interesting, the evaluator would verify the - implementation representation accurately reflects the - description provided in the TOE design - description. - - For example, the TOE design description might identify a - login module that is used to identify and authenticate - users. If user authentication is sufficiently - significant, the evaluator would verify that the - corresponding code in fact implements that service as - described in the TOE design description. It might also - be worthwhile to verify that the code accepts the - parameters as described in the functional - specification. - - It is worth pointing out the developer must choose - whether to perform the mapping for the entire - implementation representation, thereby guaranteeing that - the chosen sample will be covered, or waiting for the - sample to be chosen before performing the mapping. The - first option is likely more work, but may be completed - before the evaluation begins. The second option is less - work, but will produce a suspension of evaluation - activity while the necessary evidence is being - produced. - - - - - - - - - - - The objective of this sub-activity is to determine that - the implementation representation made available by the - developer can be transformed into the implementation that - is used in the testing activities. - - - - The evaluation evidence for this sub-activity is: - - - the implementation representation; - - - the documentation of the development tools, as - resulting from ; - - - TOE design description. - - - - - The developer shall make available the implementation - representation for the entire TSF. - - - The developer shall provide a mapping between the TOE design - description and the entire implementation representation. - - - The implementation representation shall define the TSF to a - level of detail such that the TSF can be generated without - further design decisions. - - - The implementation representation shall be in the form used - by the development personnel. - - - The mapping between the TOE design description and the - entire implementation representation shall demonstrate their - correspondence. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - - - - This family addresses the assessment of the internal - structure of the TSF. A TSF whose internals are - well-structured is easier to implement and less likely to - contain flaws that could lead to vulnerabilities; it is also - easier to maintain without the introduction of flaws. - - - - The internal structure of the TSF can aid or hamper - understandability of the implementation representation. - Source code that conforms to coding standards, that exhibit - a minimum of interactions, and that is written in modules - each with a single purpose, is much easier to understand - than poorly-structured code with unnecessary or - loosely-defined interactions. - - - - The components in this family are levelled on the basis of - the amount of structure and minimisation of complexity - required. places - requirements for well-structured internals on only selected - parts of the TSF. This component is not included in an EAL - because this component is viewed for use in special - circumstances (e.g., the sponsor has a specific concern - regarding a cryptographic module, which is isolated from the - rest of the TSF) and would not be widely applicable. - - At the next level, the requirements for well-structured - internals are placed on the entire TSF. Finally, - minimisation of complexity is introduced in the highest - component. - - - - These requirements, when applied to the internal structure - of the TSF, typically result in improvements that aid both - the developer and the evaluator in understanding the TSF, - and also provide the basis for designing and evaluating test - suites. Further, improving understandability of the TSF - should assist the developer in simplifying its - maintainability. - - The requirements in this family are presented at a fairly - abstract level. The wide variety of TOEs makes it impossible - to codify anything more specific than ``well-structured'' or - ``minimum complexity''. Judgements on structure and - complexity are expected to be derived from the specific - technologies used in the TOE. For example, software is - likely to be considered well-structured if it exhibits the - characteristics cited in the software engineering - disciplines. The components within this family call for - identifying the standards for measuring the characteristic - of being well-structured and not overly-complex. - - - - - - - - The objective of this component is to provide a means for - requiring specific portions of the TSF to be - well-structured. The intent is that the entire TSF has - been designed and implemented using sound engineering - principles, but the analysis is performed upon only a - specific subset. - - - - This component requires the PP or ST author to fill in an - assignment with the subset of the TSF. This subset may be - identified in terms of the internals of the TSF at any - layer of abstraction. For example: - - the structural elements of the TSF as identified - in the TOE design (e.g. ``The developer shall design - and implement the audit subsystem - such that it has well-structured internals.'') - the implementation (e.g. ``The developer shall - design and implement the encrypt.c and - decrypt.c files such that it has - well-structured internals.'' or ``The developer shall - design and implement the 6227 IC chip - such that it has well-structured - internals.'') - - It is likely this would not be readily accomplished by - referencing the claimed SFRs (e.g. ``The developer shall - design and implement the portion of the TSF that - provide anonymity as defined in - such that it has well-structured - internals.'') because this does not indicate where to - focus the analysis. - - This component has limited value and would be suitable in cases - where potentially-malicious users/subjects have limited or - strictly controlled access to the TSFIs or where there is - another means of protection (e.g., domain separation) that - ensures the chosen subset of the TSF cannot be adversely - affected by the rest of the TSF (e.g., the cryptographic - functionality, which is isolated from the rest of the TSF, is - well-structured). - - - - The objective of this sub-activity is to determine whether - the defined subset of the TSF is designed and structured - such that the likelihood of flaws is reduced and that - maintenance can be more readily performed without the - introduction of flaws. - - - - The role of the internals description is to provide - evidence of the structure of the design and implementation - of the TSF. - - The structure of the design has two aspects: the - constituent parts of the TSF and the procedures used to - design the TSF. In cases where the TSF is designed in a - manner consistent with the design represented by the TOE - design (see ), the - assessment of the TSF design is obvious. In cases where - the design procedures (see ) - are being followed, the assessment of the TSF design - procedures is similarly obvious. - - In cases where the TSF is implemented using - procedure-based software, this structure is assessed on - the basis of its modularity; the - modules identified in the internals description are the - same as the modules identified in the TOE design (). A module consists of one or - more source code files that cannot be decomposed into - smaller compilable units. - - The use of the assignment in this component levies stricter - constraints on the subset of the TSF that is explicitly - identified in the assignment - than on the remainder of the TSF. - While the entire TSF is to be designed using good - engineering principles and result in a well-structured TSF, only - the specified subset is specifically analysed for this - characteristic. The evaluator determines that the developer's - application of coding standards result in a TSF that is - understandable. - - The primary goal of this component is to ensure the TSF - subset's implementation representation is understandable - to facilitate maintenance and analysis (of both the - developer and evaluator). - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the TOE design description; - - - the implementation representation (if is part of the claimed - assurance); - - - the TSF internals description and justification; - - - the documentation of the coding standards, as - resulting from . - - - - - The developer shall design and implement subset - of the TSF such that it has well-structured - internals. - - - The developer shall provide an internals description and - justification. - - - The justification shall explain the characteristics used to - judge the meaning of ``well-structured''. - - - The TSF internals description shall demonstrate that the - assigned subset of the TSF is well-structured. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - The evaluator shall examine the justification to - determine that it identifies the basis for determining - whether the TSF is well-structured. - - The evaluator verifies that the criteria for determining - the characteristic of being well-structured are clearly - defined in the justification. Acceptable criteria - typically originate from industry standards for the - technology discipline. For example, procedural software - that executes linearly is traditionally viewed as - well-structured if it adheres to software engineering - programming practises, such as those defined in the IEEE - Standard (IEEE Std 610.12-1990). For - example, it would identify the criteria for the - procedural software portions of the TSF subset: - - the process used for modular - decomposition - coding standards used in the development of the - implementation - a description of the maximum acceptable level of - intermodule coupling exhibited by the TSF - subset - a description of the minimum acceptable level of - cohesion exhibited the modules of the TSF - subset - - For other types of technologies used in the TOE - such as - non-procedural software (e.g. object-oriented programming), - widespread commodity hardware (e.g. PC microprocessors), and - special-purpose hardware (e.g. smart-card processors) - the - evaluator should seek guidance from the evaluation authority for - determining the adequacy of criteria for being - ``well-structured''. - - - - The evaluator shall check the TSF internals - description to determine that it identifies the Assigned - subset of the TSF. - - This subset may be identified in terms of the internals - of the TSF at any layer of abstraction. For example, it - may be in terms of the structural elements of the TSF as - identified in the TOE design (e.g. the audit subsystem), - or in terms of the implementation - (e.g. encrypt.c and - decrypt.c files, or the 6227 IC - chip). - - It is insufficient to identify this subset in terms of - the claimed SFRs (e.g. the portion of the TSF that - provide anonymity as defined in ) because this does not indicate where to - focus the analysis. - - - - The evaluator shall examine the TSF internals - description to determine that it demonstrates that the - assigned TSF subset is well-structured. - - The evaluator examines the internals description to - ensure that it provides a sound explanation of how the - TSF subset meets the criteria from - - For example, it would explain how the procedural - software portions of the TSF subset meets the following: - - that there is a one-to-one correspondence - between the modules identified in the TSF subset and - the modules described in the TOE design () - how the TSF design is a reflection of the - modular decomposition process - a justification for all instances where the - coding standards were not used or met - a justification for any coupling or cohesion - outside the acceptable bounds - - - - The evaluator shall perform an internals analysis on the - assigned subset of the TSF. - - - The evaluator shall determine that the TOE design for - the assigned TSF subset is well-structured. - - The evaluator examines a sample of the TOE design to - verify the accuracy of the justification. For example, a - sample of the TOE design is analysed to determine its - adherence to the design standards, etc. As with all - areas where the evaluator performs activities on a - subset the evaluator provides a justification of the - sample size and scope - - The description of the TOE's decomposition into - subsystems and modules will make the argument that the - TSF subset is well-structured self-evident. Verification - that the procedures for structuring the TSF (as examined - in ) are being followed - will make it self-evident that the TSF subset is - well-structured. - - - - The evaluator shall determine that the assigned TSF - subset is well-structured. - - If is not part of the - claimed assurance, then this work unit is not applicable - and is therefore considered to be satisfied. - - The evaluator examines a sample of the TSF subset to - verify the accuracy of the internals description. For - example, a sample of the procedural software portions of - the TSF subset is analysed to determine its cohesion and - coupling, its adherence to the coding standards, etc. As - with all areas where the evaluator performs activities - on a subset the evaluator provides a justification of - the sample size and scope. - - - - - - - - - - - The objective of this component is to provide a means for - requiring the TSF to be well-structured. The intent is - that the entire TSF has been designed and implemented - using sound engineering principles. - - - - Judgements on the adequacy of the structure are expected to - be derived from the specific technologies used in the TOE. - This component calls for identifying the standards for - measuring the characteristic of being - well-structured. - - - - The objective of this sub-activity is to determine whether - the TSF is designed and structured such that the - likelihood of flaws is reduced and that maintenance can be - more readily performed without the introduction of - flaws. - - - - The role of the internals description is to provide - evidence of the structure of the design and implementation - of the TSF. - - The structure of the design has two aspects: the - constituent parts of the TSF and the procedures used to - design the TSF. In cases where the TSF is designed in a - manner consistent with the design represented by the TOE - design (see ), the - assessment of the TSF design is obvious. In cases where - the design procedures (see ) - are being followed, the assessment of the TSF design - procedures is similarly obvious. - - In cases where the TSF is implemented using - procedure-based software, this structure is assessed on - the basis of its modularity; the - modules identified in the internals description are the - same as the modules identified in the TOE design (). A module consists of one or - more source code files that cannot be decomposed into - smaller compilable units. - - The primary goal of this component is to ensure the TSF's - implementation representation is understandable to - facilitate maintenance and analysis (of both the developer - and evaluator). - - - - The evaluation evidence for this sub-activity is: - - - the modular design description; - - - the implementation representation (if is part of the claimed - assurance)); - - - the TSF internals description; - - - the documentation of the coding standards, as - resulting from . - - - - - The developer shall design and implement the entire TSF such - that it has well-structured internals. - - - The developer shall provide an internals description and - justification. - - - The justification shall describe the characteristics used to - judge the meaning of ``well-structured''. - - - The TSF internals description shall demonstrate that the - entire TSF is well-structured. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - The evaluator shall examine the justification to - determine that it identifies the basis for determining - whether the TSF is well-structured. - - The evaluator verifies that the criteria for determining - the characteristic of being well-structured are clearly - defined in the justification. Acceptable criteria - typically originate from industry standards for the - technology discipline. For example, procedural software - that executes linearly is traditionally viewed as - well-structured if it adheres to software engineering - programming practises, such as those defined in the IEEE - Standard (IEEE Std 610.12-1990). For - example, it would identify the criteria for the - procedural software portions of the TSF: - - the process used for modular - decomposition - coding standards used in the development of the - implementation - a description of the maximum acceptable level of - intermodule coupling exhibited by the TSF - a description of the minimum acceptable level of - cohesion exhibited the modules of the - TSF - - For other types of technologies used in the TOE - such - as non-procedural software (e.g. object-oriented - programming), widespread commodity hardware (e.g. PC - microprocessors), and special-purpose hardware - (e.g. smart-card processors) - the evaluation authority - should be consulted for determining the adequacy of - criteria for being ``well-structured''. - - - - The evaluator shall examine the TSF internals - description to determine that it demonstrates that the - TSF is well-structured. - - The evaluator examines the internals description to - ensure that it provides a sound explanation of how the - TSF meets the criteria from - - For example, it would explain how the procedural - software portions of the TSF meet the following: - - that there is a one-to-one correspondence - between the modules identified in the TSF and the - modules described in the TOE design () - how the TSF design is a reflection of the - modular decomposition process - a justification for all instances where the - coding standards were not used or met - a justification for any coupling or cohesion - outside the acceptable bounds - - - - The evaluator shall perform an internals analysis on the - TSF. - - - The evaluator shall determine that the TOE design is - well-structured. - - The evaluator examines the TOE design of a sample of the - TSF to verify the accuracy of the justification. For - example, a sample of the TOE design is analysed to - determine its adherence to the design standards, etc. As - with all areas where the evaluator performs activities - on a subset the evaluator provides a justification of - the sample size and scope - - The description of the TOE's decomposition into - subsystems and modules will make the argument that the - TSF subset is well-structured self-evident. Verification - that the procedures for structuring the TSF (as examined - in ) are being followed - will make it self-evident that the TSF subset is - well-structured. - - - - The evaluator shall determine that the TSF is - well-structured. - - If is not part of the - claimed assurance, then this work unit is not applicable - and is therefore considered to be satisfied. - - The evaluator examines a sample of the TSF to verify the - accuracy of the internals description. For example, a - sample of the procedural software portions of the TSF is - analysed to determine its cohesion and coupling, its - adherence to the coding standards, etc. As with all - areas where the evaluator performs activities on a - subset the evaluator provides a justification of the - sample size and scope. - - - - - - - - - - - The objective of this component is to provide a means for - requiring the TSF to be well-structured and of minimal - complexity. The intent is that the entire TSF has been - designed and implemented using sound engineering - principles. - - - - Judgements on the adequacy of the structure and complexity - are expected to be derived from the specific technologies - used in the TOE. This component calls for identifying the - standards for measuring the structure and - complexity. - - - - The evaluation evidence for this sub-activity is: - - - the modular design description; - - - the implementation representation; - - - the TSF internals description; - - - the documentation of the coding standards, as - resulting from . - - - - - The developer shall design and implement the entire TSF such - that it has well-structured internals. - - - The developer shall provide an internals description and - justification. - - - The justification shall describe the characteristics used to - judge the meaning of ``well-structured'' and ``complex''. - - - The TSF internals description shall demonstrate that the - entire TSF is well-structured and is not overly complex. - - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - The evaluator shall perform an internals analysis on the - entire TSF. - - - - - - - It is the objective of this family to provide additional - assurance from the development of a formal security - policy model of the TSF, and establishing a - correspondence between the functional specification and this - security policy model. Preserving internal consistency the - security policy model is expected to formally establish the - security principles from its characteristics by means of a - mathematical proof. - - - - A formal security model precisely describes important - aspects of security and their relationship to the behaviour - of the TSF. Formalism helps to prove mathematically the - thoroughness of the security. - - - - This family contains only one component. - - - - Inadequacies in a TOE can result either from a failure in - understanding the security requirements or from a flawed - implementation of those security requirements. Defining the - security requirements adequately to ensure their - understanding may be problematic because the definition must - be sufficiently precise to prevent undesired results or - subtle flaws during implementation of the TOE. Throughout - the design, implementation, and review processes, the - modelled security requirements may be used as precise design - and implementation guidance, thereby providing increased - assurance that the modelled security requirements are - satisfied by the TOE. The precision of the model and - resulting guidance is significantly improved by casting the - model in a formal language and verifying the security - requirements by formal proof. - - The creation of a formal security policy model helps to - identify and eliminate ambiguous, inconsistent, - contradictory, or unenforceable security policy - elements. Once the TOE has been built, the formal model - serves the evaluation effort by contributing to the - evaluator's judgement of how well the developer has - understood the security functionality being implemented and - whether there are inconsistencies between the security - requirements and the TOE design. The confidence in the model - is accompanied by a proof that it contains no - inconsistencies. - - A formal security model is a precise formal presentation of - the important aspects of security and their relationship to - the behaviour of the TOE; it identifies the set of rules and - practises that regulates how the TSF manages, protects, and - otherwise controls the system resources. The model includes - the set of restrictions and properties that specify how - information and computing resources are prevented from being - used to violate the SFRs, accompanied by a persuasive set of - engineering arguments showing that these restrictions and - properties play a key role in the enforcement of the SFRs. - It consists both of the formalisms that express the security - functionality, as well as ancillary text to explain the - model and to provide it with context. The security behaviour - of the TSF is modelled both in terms of external behaviour - (i.e. how the TSF interacts with the rest of the TOE and - with its operational environment), as well as its internal - behaviour. - - The Security Policy Model of the TOE is informally - abstracted from its realisation by considering the proposed - security requirements of the ST. The informal abstraction is - taken to be successful if the TOE's principles (also termed - ``invariants'') turn out to be enforced by its - characteristics. The purpose of formal methods lies within - the enhancement of the rigour of enforcement. Informal - arguments are always prone to fallacies; especially if - relationships among subjects, objects and operations get - more and more involved. In order to minimise the risk of - insecure state arrivals the rules and characteristics of the - security policy model are mapped to respective properties - and features within some formal system, whose rigour and - strength can afterwards be used to obtain the security - properties by means of theorems and formal proof. - - While the term ``formal security policy model'' is used in - academic circles, the CC's approach has no fixed definition - of ``security''; it would equate to whatever SFRs are being - claimed. Therefore, the formal security policy model is - merely a formal representation of the set of SFRs being - claimed. - - The term security policy has - traditionally been associated with only access control - policies, whether label-based (mandatory access control) or - user-based (discretionary access control). However, a - security policy is not limited to access control; there are - also audit policies, identification policies, authentication - policies, encryption policies, management policies, and any - other security policies that are enforced by the TOE, as - described in the PP/ST. contains an assignment for identifying these - policies that are formally modelled. - - - - - - The objectives of this sub-activity are to determine - whether the formal TOE security policy model clearly and - consistently describes the rules of operation, states, - transition, invariants, and other security properties of - the claimed SFRs and whether this description corresponds - with the description of the security functionality in the - functional specification. - - - - This activity applies to cases where the developer has - formally modelled all security policies of the TOE that - are capable of being modelled formally. - - A formal TOE security policy model is a representation of - the rules (synonymously termed ``principles'') and - characteristics of security policies in mathematical - terms. Their formal counterparts are called security - properties and security features, respectively. The - representation includes but is not limited to algebraic - specifications, finite state machines and logic formalisms - strong enough to formally infer the properties from the - features. The formal security policy model is accompanied - by an informal interpretation explaining how the rules and - characteristics are mapped to the respective properties - and features. - - It is recognised that not all policies (see work unit - ) can be formally - modelled for all TOEs. This is because either the state of - the art is insufficient to formally model a given policy, - or because the nature of the TOE renders impossible the - modelling of policies that would otherwise be possible to - model. If none of the SFRs can be formally modelled, this - component cannot be met. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the functional specification; - - - the TOE security policy model; - - - the operational user guidance; - - - - - The developer shall provide a formal security policy model for - the list of policies that are formally - modelled. - - For each policy covered by the formal security policy model, the - model shall identify the relevant portions of the statement of - SFRs that make up that policy. - - - The developer shall provide a formal proof of correspondence - between the model and any formal functional specification. - - - The developer shall provide a demonstration of - correspondence between the model and the functional - specification. - - - The model shall be in a formal style, supported by - explanatory text as required, and identify the security - policies of the TSF that are modelled. - - - For all policies that are modelled, the model shall define - security for the TOE and provide a formal proof that the TOE - cannot reach a state that is not secure. - - - The correspondence between the model and the functional - specification shall be at the correct level of formality. - - - The correspondence shall show that the functional - specification is consistent and complete with respect to the - model. - - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the TOE security policy - model to determine that it is written in a formal - style. - - The evaluator identifies the formal framework upon which - the TOE security policy model is based and ensures that - it is founded on well established mathematical concepts, - and identifies the security properties and features - addressed in the application notes and ensures the - formalisation of at least one security policy. If no - policy is formally modelled, this component cannot be - successfully claimed. - - For additional guidance on formal methods refer to . - - - - - The evaluator shall examine the TOE security policy - model to determine that it contains all necessary - informal explanatory text. - - Supporting narrative descriptions are necessary for all - parts of the model (for example, to make clear the - meaning of any formal notation and how they are used) - including the security properties and features. - - - - - The evaluator shall examine the TOE security policy - model to determine that it contains all policies that - can be formally modelled. - - It is recognised that not all policies can be formally - modelled for all TOEs. This is because either the state - of the art is insufficient to formally model a given - policy, or because the nature of the TOE renders - impossible the modelling of policies that would - otherwise be possible to model. - - While access control, information flow control, and data - integrity policies have all been formally modelled - successfully, the possibility of modelling other - policies is based on a case by case decision. Abstention - from formally modelling security relevant policies - requires argumentation and rests the burden of proof - entirely on the developer's side. - - For any security policy where formal models are not - possible, the policy must be identified in the - assignment of . - - - - - The evaluator shall examine the model to determine that - the security behaviour of the TOE is clearly - articulated. - - The security policy model's properties describe the - TOE's behaviour in enforcing the principles of the - policy. For example, a policy that is modelled on the - basis of state transitions would include principles of - its states, identify its initial state, and define what - it means to be a secure state. - - The security policy model's features describe the - attributes and conditions of the TOE that come into - consideration when enforcing its policy's - characteristics. For example, a policy that is modelled - on the basis of state transitions would describe the - necessary conditions to transform the TOE from one state - to the next. - - An informal interpretation of all formal concepts - (including attributes, predicates and variables, if - available) must also be provided in order to make clear - their intended meaning. - - - - - The evaluator shall examine the correspondence between - the security policy model and the formal functional - specification to determine that it is presented in a - formal style. - - If no part of the functional specification is formal, - this work unit is not applicable and is therefore - considered to be satisfied. The corresponding work will - be performed under work unit . - - For any part of the functional specification that is - formally presented, the correspondence between that part - of the functional specification and the security policy - model must be formal. Analysis of the content is - performed as part of work units through . - - For guidance on formal methods refer to . - - - - - The evaluator shall examine the correspondence between - the security policy model and the semiformal functional - specification to determine that it is presented in a - semiformal style. - - If the entire functional specification is formal, this - work unit is not applicable and is therefore considered - to be satisfied. The corresponding work will be - performed under work unit . - - For formally-modelled policies whose corresponding - description in the functional specification is not - formally presented, the correspondence between the model - and the functional specification must be a semiformal - demonstration. Analysis of the content is performed as - part of work units - through . - - If a security policy model exists, either this work unit - or the previous work unit (or both) will be - applicable. - - - - - The evaluator shall examine the TOE security policy - model rationale to determine that it formally proves the - correspondence between the security properties and the - security features. - - The proof shall show that the security features enforce - the security properties. To determine the enforcement, - the evaluator considers the security properties and the - security features and verifies that the arguments used - in the proof are valid. The proof of correspondence - between the security properties and the security - features shall be formal. - - - - - The evaluator shall examine the TOE security policy - model rationale to determine that it proves the internal - consistency of the TOE security policy model. - - The proof shall show the absence of contradictions - within the TOE security policy model. In determining the - absence of contradictions, the evaluator verifies that - the arguments used in the proof are valid. - - Since the TOE security policy model is formal, the proof - of its internal consistency shall be formal. It is - recognised that a complete formal proof of the internal - consistency of the TOE security policy model usually is - not possible due to the fundamental nature of formal - frameworks. Generally, it is sufficient to generate - evidence using formal proofs based on the specific TOE - security policy model that prove the internal - consistency by means of a combination with generic - arguments of the formal framework. - - - - - The evaluator shall examine the TOE security policy - model rationale to determine that the behaviour modelled - is consistent with respect to policies described by the - security policies (as articulated by the functional - requirements in the ST). - - The examination considers the informal relationships of - the model. Hence the meaning of consistency reflects - the conventional understanding in contrast to the - internal consistency concept of the previous work - unit. - - In determining consistency, the evaluator verifies that - the rationale shows that each description of properties - and features in the security policy model accurately - reflects the intent of the security policies. For - example, if a policy stated that access control was - necessary to the granularity of a single individual, - then a security policy model describing the security - behaviour of a TOE in the context of controlling groups - of users would not be consistent. Likewise, if the - policy stated that access control for groups of users - was necessary, then a security policy model describing - the security behaviour of a TOE in the context of - controlling individual users would also not be - consistent. - - The evaluator also examines whether the security - policies are reflected within their formal counterparts - of the security policy model. - - - - - The evaluator shall examine the TOE security policy - model rationale to determine that the behaviour modelled - is complete with respect to the policies described by - the security policies (i.e. as articulated by the - functional requirements in the ST). - - In determining completeness of this rationale, the - evaluator considers the properties and features of the - security policy model and maps those properties and - features to explicit policy statements (i.e. functional - requirements). The rationale should show that all - policies that are required to be modelled have an - associated property or feature description in the TOE - security policy model. - - Abstention from formally modelling policy statements - always calls for justification on the developer's side - (also confer the application notes above). - - - - - The evaluator shall examine the demonstration of - correspondence to determine that all Assigned policies - are mapped to functions within the functional - specification. - - If all policies are included within the security policy - model (i.e. they are all formally modelled) and the - assignment in is - therefore empty, this work unit is not applicable and is - therefore considered to be satisfied. - - The evaluator verifies that the correspondence - demonstrates that the descriptions of the SFR-related - functions in the functional specification correspond to - the SFRs. This may be done as part of the work units addressing - correspondence to the SFRs. However, if the developer - provides a well-structured semiformal or informal - security policy model to better articulate the notions - of security enforced by the TOE, the evaluator will - verify that such a model is consistent with the - SFRs. - - - - - - - - The design description of a TOE provides both context for a - description of the TSF, and a thorough description of the - TSF. As assurance needs increase, the level of detail - provided in the description also increases. As the size and - complexity of the TSF increase, multiple levels of - decomposition are appropriate. The design requirements are - intended to provide information (commensurate with the given - assurance level) so that a determination can be made that - the security functional requirements are realised. - - - - The design description provides a further-refined - description of the TSF from that presented in the functional - specification. The functional specification provides a - description of what the TSF does at its - interface; the design description provides more insight into - the TSF by describing how the TSF works in - order to perform the functions supporting the SFRs. At lower - assurance levels, complete details relating to all portions - of the TSF are not required. As the desired assurance - increases, more detail is made available so that analysis - can be performed that supports the assurance claims being - made. - - - - The components in this family are levelled on the basis of - the amount of information that is required to be presented - with respect to the TSF, and on the degree of formalism - required of the design description. - - - - The goal of design documentation is to provide sufficient - information to determine the TSF boundary, and to describe - how the TSF implements the Security - Functional Requirements. The amount and structure of the - design documentation will depend on the complexity of the - TOE and the number of SFRs; in general, a very complex TOE - with a large number of SFRs will require more design - documentation than a very simple TOE implementing only a few - SFRs. Very complex TOEs will benefit (in terms of the - assurance provided) from the production of differing levels - of decomposition in describing the design, while very simple - TOEs do not require both high-level and low-level - descriptions of its implementation. - - This family uses two levels of decomposition: the - subsystem and the module. - A module is the most specific description of functionality: - it is a description of the implementation. A developer - should be able to implement the part of the TOE described by - the module with no further design decisions. A subsystem is - a description of the design of the TOE; it helps to provide - a high-level description of what a portion of the TOE is - doing and how. As such, a subsystem may be further divided - into lower-level subsystems, or into modules. Very complex - TOEs might require several levels of subsystems in order to - adequately convey a useful description of how the TOE works. - Very simple TOEs, in contrast, might not require a subsystem - level of description; the module might clearly describe how - the TOE works. - - The general approach adopted for design documentation is - that, as the level of assurance increases, the emphasis of - description shifts from the general (subsystem level) to - more (module level) detail. In cases where a module-level - of abstraction is appropriate because the TOE is simple - enough to be described at the module level, yet the level of - assurance calls for a subsystem level of description, the - module-level description alone will suffice. For complex - TOEs, however, this is not the case: an enormous amount of - (module-level) detail would be incomprehensible without an - accompanying subsystem level of description. - - This approach follows the general paradigm that providing - additional detail about the implementation of the TSF will - result in greater assurance that the SFRs are implemented - correctly, and provide information that can be used to - demonstrate this in testing (). - - In the requirements for this family, the term - interface is used as the means of - communication (between two subsystems or modules). It - describes how the communication is invoked; this is similar - to the details of TSFI (see ). The term interaction is - used to identify the purpose for communication; it - identifies why two subsystems or modules are - communicating. - - - The requirements define collections of details about - subsystems and modules to be provided: - - The subsystems and modules are - identified with a simple list of what - they are. - - Subsystems and modules may be categorised - (either implicitly or explicitly) as ``SFR-enforcing'', - ``SFR-supporting'', or ``SFR-non-interfering''; these terms are - used the same as they are used in . - - A subsystem's behaviour is what it does. The - behaviour may also be categorised as SFR-enforcing, - SFR-supporting, or SFR-non-interfering. The behaviour of the - subsystem is never categorised as more SFR-relevant than the - category of the subsystem itself. For example, an SFR-enforcing - subsystem can have SFR-enforcing behaviour as well as - SFR-supporting or SFR-non-interfering behaviour. - A behaviour summary of a - subsystem is an overview of the actions it performs - (e.g. ``The TCP subsystem assembles IP datagrams into - reliable byte streams''). - A behaviour description of a - subsystem is an explanation of everything it - does. This description should be at a level of detail - that one can readily determine whether the behaviour - has any relevance to the enforcement of the - SFRs. - - A description of interactions among or between - subsystems or modules identifies the reason that subsystems or - modules communicate, and characterises the information that is - passed. It need not define the information to the same level of - detail as an interface specification. For example, it would be - sufficient to say ``subsystem X requests a block of memory from - the memory manager, which responds with the location of the - allocated memory. - A description of interfaces provides the - details of how the interactions among modules are achieved. - Rather than describing the reason the modules are communicating - or the purpose of their communication (that is, the description - of interactions), the description of interfaces describes the - details of how that communication is accomplished, in terms of - the structure and contents of the messages, semaphores, internal - process communications, etc. - - - The purpose describes how a module provides - their functionality. It provides sufficient detail that no - further design decisions are needed. The correspondence between - the implementation representation that implements the module, - and the purpose of the module should be readily apparent. - A module is otherwise described - in terms of whatever is identified in the - element. Subsystems and modules, and - ``SFR-enforcing'', etc. are all further explained in - greater detail in . - - - - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the functional specification; - - - security architecture description; - - - the TOE design. - - - - - The developer shall provide the design of the TOE. - - - The developer shall provide a mapping from the TSFI of the - functional specification to the lowest level of - decomposition available in the TOE design. - - The design shall describe the structure of the TOE in terms - of subsystems. - - - The design shall identify all subsystems of the TSF. - - - The design shall describe the behaviour of each - SFR-supporting or SFR-non-interfering TSF subsystem in - sufficient detail to determine that it is not SFR-enforcing. - - - The design shall summarise the SFR-enforcing behaviour of - the SFR-enforcing subsystems. - - - The design shall provide a description of the interactions - among SFR-enforcing subsystems of the TSF, and between the - SFR-enforcing subsystems of the TSF and other subsystems of - the TSF. - - - The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the TOE design to determine - that the structure of the entire TOE is described in - terms of subsystems. - - The evaluator ensures that all of the subsystems of the - TOE are identified. This description of the TOE will be - used as input to work unit , where the parts of the TOE that make up - the TSF are identified. That is, this requirement is on - the entire TOE rather than on only the TSF. - - The TOE (and TSF) may be described in multiple layers of - abstraction (i.e. subsystems and modules) Depending upon - the complexity of the TOE, its design may be described - in terms of subsystems and modules, as described in CC - Part 3 . At this - level of assurance, the decomposition only need be at - the ``subsystem'' level. - - In performing this activity, the evaluator examines - other evidence presented for the TOE (e.g., ST, operator - user guidance) to determine that the description of the - TOE in such evidence is consistent with the description - contained in the TOE design. - - - - - The evaluator shall examine the TOE design to determine - that all subsystems of the TSF are identified. - - In work unit all of - the subsystems of the TOE were identified, and a - determination made that the non-TSF subsystems were - correctly characterised. Building on that work, the - subsystems that were not characterised as non-TSF - subsystems should be precisely identified. The evaluator - determines that, of the hardware and software installed - and configured according to the guidance, each subsystem has been - accounted for as either one that is part of the TSF, or - one that is not. - - - - - The evaluator shall examine the TOE design to determine that - each SFR-supporting or SFR-non-interfering subsystem of the TSF - is described such that the evaluator can determine that the - subsystem is SFR-supporting or SFR-non-interfering. - - SFR-supporting and SFR-non-interfering subsystems do not need to - be described in detail as to how they function in the system. - However, the evaluator makes a determination, based on the - evidence provided by the developer, that the subsystems that do - not have high-level descriptions are SFR-supporting or - SFR-non-interfering. Note that if the developer provides a - uniform level of detailed documentation then this work unit will - be largely satisfied, since the point of categorising the - subsystems is to allow the developer to provide less information - for SFR-supporting and SFR-non-interfering subsystems than for - SFR-enforcing subsystems. - - An SFR-supporting subsystem is one that is depended on - by an SFR-enforcing subsystem in order to implement an - SFR, but does not play as direct a role as an - SFR-enforcing subsystem. An SFR-non-interfering - subsystem is one that is not depended upon, in either a - supporting or enforcing role, to implement an - SFR. - - - - - The evaluator shall examine the TOE design to determine - that it provides a complete, accurate, and high-level - description of the SFR-enforcing behaviour of the - SFR-enforcing subsystems. - - The developer may designate subsystems as SFR-enforcing, - SFR-supporting, and SFR non-interfering, but these - ``tags'' are used only to describe the amount and type - of information the developer must provide, and can be - used to limit the amount of information the developer - has to develop if their engineering process does not - produce the documentation required. Whether the - subsystems have been categorised by the developer or - not, it is the - evaluator's responsibility to determine that the - subsystems have the appropriate information for their - role (SFR-enforcing, etc.) in the TOE, and to obtain the - appropriate information from the developer should the - developer fail to provide the required information for a - particular subsystem. - - SFR-enforcing behaviour refers to how a - subsystem provides the functionality that implements an - SFR. A high-level description need not refer to - specific data structures (although it may), but instead - talks about more general data flow, message flow, and - control relationships within a subsystem. The goal of - these descriptions is to give the evaluator enough - information to understand how the - SFR-enforcing behaviour is achieved. Note that the - evaluator should find unacceptable asserts of - SFR-enforcement in the TOE design documentation for this - work unit. It should be noted that it is the - evaluator's determination with respect to what - ``high-level'' means for a particular TOE, and the - evaluator obtains enough information from the developer - to make a sound verdict for this work unit. - - To determine completeness and accuracy, the evaluator - examines other information available (e.g., functional - specification, security architecture description, - implementation representation). Descriptions of - functionality in these documents should be consistent - with what is provided for evidence for this work - unit - - - - - The evaluator shall examine the TOE design to determine - that interactions between the subsystems of the TSF are - described. - - The goal of describing the interactions between the - SFR-enforcing subsystems and other subsystems is to help provide - the reader a better understanding of how the TSF performs it - functions. These interactions do not need to be characterised at - the implementation level (e.g., parameters passed from one - routine in a subsystem to a routine in a different subsystem; - global variables; hardware signals (e.g., interrupts) from a - hardware subsystem to an interrupt-handling subsystem), but the - data elements identified for a particular subsystem that are - going to be used by another subsystem need to be covered in this - discussion. Any control relationships between subsystems (e.g., - a subsystem responsible for configuring a rule base for a - firewall system and the subsystem that actually implements these - rules) should also be described. - - The evaluators need to use their own judgement in assessing the - completeness of the description. If the reason for an - interaction is unclear, or if there are SFR-related interactions - (discovered, for instance, in examining the descriptions of - subsystem behaviour) that do not appear to be described, the - evaluator ensures that this information is provided by the - developer. However, if the evaluator can determine that - interactions among a particular set of subsystems, while - incompletely described by the developer, will not aid in - understanding the overall functionality nor security - functionality provided by the TSF, then the evaluator may choose - to consider the description sufficient, and not pursue - completeness for its own sake. - - - - - The evaluator shall examine the TOE design to determine - that it contains a complete and accurate mapping from - the TSFI described in the functional specification to - the subsystems of the TSF described in the TOE - design. - - The subsystems described in the TOE design provide a - description of how the TSF works at a detailed level for - SFR-enforcing portions of the TSF, and at a higher level - for other portions of the TSF. The TSFI provide a - description of how the implementation is exercised. The - evidence from the developer identifies the subsystem - that is initially involved when an operation is - requested at the TSFI, and identify the various - subsystems that are primarily responsible for - implementing the functionality. Note that a complete - ``call tree'' for each TSFI is not required for this - work unit. - - The evaluator assesses the completeness of the mapping - by ensuring that all of the TSFI map to at least one - subsystem. The verification of accuracy is more - complex. - - The first aspect of accuracy is that each TSFI is mapped - to a subsystem at the TSF boundary. This determination - can be made by reviewing the subsystem description and - interactions, and from this information determining its - place in the architecture. The next aspect of accuracy - is that the mapping makes sense. For instance, mapping a - TSFI dealing with access control to a subsystem that - checks passwords is not accurate. The evaluator should - again use judgement in making this determination. The - goal is that this information aids the evaluator in - understanding the system and implementation of the SFRs, - and ways in which entities at the TSF boundary can - interact with the TSF. The bulk of the assessment of - whether the SFRs are described accurately by the - subsystems is performed in other work units. - - - - The evaluator shall determine that the design is an accurate - and complete instantiation of all security functional - requirements. - - - The evaluator shall examine the TOE security functional - requirements and the TOE design, to determine that all - ST security functional requirements are covered by the - TOE design. - - The evaluator may construct a map between the TOE security - functional requirements and the TOE design. This map will - likely be from a functional requirement to a set of - subsystems. Note that this map may have to be at a level of - detail below the component or even element level of the - requirements, because of operations (assignments, refinements, - selections) performed on the functional requirement by the ST - author. - - For example, the - component contains an element with assignments. If the - ST contained, for instance, ten rules in the assignment, and these ten - rules were implemented in specific places within fifteen - modules, it would be inadequate for the evaluator to map - to one subsystem and - claim the work unit had been completed. Instead, the - evaluator would map - (rule 1) to subsystem A, behaviours x, y, and z; (rule 2) to subsystem A, - behaviours x, p, and q; etc. - - - - The evaluator shall examine the TOE design to determine - that it is an accurate instantiation of all security - functional requirements. - - The evaluator ensures that each security requirement - listed in the TOE security functional requirements - subclause of the ST has a corresponding design description - in the TOE design that accurately details how the TSF - meets that requirement. This requires that the evaluator - identify a collection of subsystems that are responsible - for implementing a given functional requirement, and - then examine those subsystems to understand how the - requirement is implemented. Finally, the evaluator would - assess whether the requirement was accurately - implemented. - - As an example, if the ST requirements specified a - role-based access control mechanism, the evaluator would - first identify the subsystems that contribute to this - mechanism's implementation. This could be done by - in-depth knowledge or understanding of the TOE design or - by work done in the previous work unit. Note that this - trace is only to identify the subsystems, and is not the - complete analysis. - - The next step would be to understand what mechanism the - subsystems implemented. For instance, if the design - described an implementation of access control based on - UNIX-style protection bits, the design would not be an - accurate instantiation of those access control - requirements present in the ST example used above. If - the evaluator could not determine that the mechanism was - accurately implemented because of a lack of detail, the - evaluator would have to assess whether all of the - SFR-enforcing subsystems have been identified, or if - adequate detail had been provided for those - subsystems. - - - - - - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the functional specification; - - - security architecture description; - - - the TOE design. - - - - - The developer shall provide the design of the TOE. - - - The developer shall provide a mapping from the TSFI of the - functional specification to the lowest level of - decomposition available in the TOE design. - - - The design shall describe the structure of the TOE in terms - of subsystems. - - - The design shall identify all subsystems of the TSF. - - - The design shall describe the behaviour of each SFR - non-interfering subsystem of the TSF in detail sufficient to - determine that it is SFR non-interfering. - - - The design shall describe the SFR-enforcing behaviour of the - SFR-enforcing subsystems. - - - The design shall summarise the SFR-supporting and - SFR-non-interfering behaviour of the SFR-enforcing subsystems. - - - The design shall summarise the behaviour of the - SFR-supporting subsystems. - - - The design shall provide a description of the interactions - among all subsystems of the TSF. - - - The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the TOE design to determine - that the structure of the entire TOE is described in - terms of subsystems. - - The evaluator ensures that all of the subsystems of the - TOE are identified. This description of the TOE will be - used as input to work unit , where the parts of the TOE that make up - the TSF are identified. That is, this requirement is on - the entire TOE rather than on only the TSF. - - The TOE (and TSF) may be described in multiple layers of - abstraction (i.e. subsystems and modules) Depending upon - the complexity of the TOE, its design may be described - in terms of subsystems and modules, as described in CC - Part 3 . At this - level of assurance, the decomposition only need be at - the ``subsystem'' level. - - In performing this activity, the evaluator examines - other evidence presented for the TOE (e.g., ST, operator - user guidance) to determine that the description of the - TOE in such evidence is consistent with the description - contained in the TOE design. - - - - - The evaluator shall examine the TOE design to determine - that all subsystems of the TSF are identified. - - In work unit all of - the subsystems of the TOE were identified, and a - determination made that the non-TSF subsystems were - correctly characterised. Building on that work, the - subsystems that were not characterised as non-TSF - subsystems should be precisely identified. The evaluator - determines that, of the hardware and software installed - and configured according to the guidance, each subsystem has been - accounted for as either one that is part of the TSF, or - one that is not. - - - - - The evaluator shall examine the TOE design to determine - that each SFR-non-interfering subsystem of the TSF is - described such that the evaluator can determine that the - subsystem is SFR-non-interfering. - - SFR-non-interfering subsystems do not need to be - described in detail as to how they function in the - system. However, the evaluator makes a determination, - based on the evidence provided by the developer, that - the subsystems that do not have detailed descriptions - are SFR-non-interfering. Note that if the developer - provides a uniform level of detailed documentation then - this work unit will be largely satisfied, since the - point of categorising the subsystems is to allow the - developer to provide less information for - SFR-non-interfering subsystems than for SFR-enforcing - and SFR-supporting subsystems. - - An SFR-non-interfering subsystem is one on which the - SFR-enforcing and SFR-supporting subsystems have no - dependence; that is, they play no role in implementing - SFR functionality. - - - - - The evaluator shall examine the TOE design to determine - that it provides a complete, accurate, and detailed - description of the SFR-enforcing behaviour of the - SFR-enforcing subsystems. - - The developer may designate subsystems as SFR-enforcing, - SFR-supporting, and SFR non-interfering, but these - ``tags'' are used only to describe the amount and type - of information the developer must provide, and can be - used to limit the amount of information the developer - has to develop if their engineering process does not - produce the documentation required. Whether the - subsystems have been categorised by the developer or - not, it is the - evaluator's responsibility to determine that the - subsystems have the appropriate information for their - role (SFR-enforcing, etc.) in the TOE, and to obtain the - appropriate information from the developer should the - developer fail to provide the required information for a - particular subsystem. - - SFR-enforcing behaviour refers to how a - subsystem provides the functionality that implements an - SFR. While not at the level of an algorithmic - description, a detailed description of behaviour - typically discusses how the functionality is provided in - terms of what key data and data structures are, what - control relationships exist within a subsystem, and how - these elements work together to provide the - SFR-enforcing behaviour. Such a description also - references SFR-supporting behaviour, which the evaluator - should consider in performing subsequent work - units. - - To determine completeness and accuracy, the evaluator - examines other information available (e.g., functional - specification, security architecture description). Descriptions of - functionality in these documents should be consistent - with what is provided for evidence for this work unit. - - - - - The evaluator shall examine the TOE design to determine that it - provides a complete and accurate high-level description of the - SFR-supporting and SFR-non-interfering behaviour of the - SFR-enforcing subsystems. - - The developer may designate subsystems as SFR-enforcing, - SFR-supporting, and SFR non-interfering, but these - ``tags'' are used only to describe the amount and type - of information the developer must provide, and can be - used to limit the amount of information the developer - has to develop if their engineering process does not - produce the documentation required. Whether the - subsystems have been categorised by the developer or - not, it is the - evaluator's responsibility to determine that the - subsystems have the appropriate information for their - role (SFR-enforcing, etc.) in the TOE, and to obtain the - appropriate information from the developer should the - developer fail to provide the required information for a - particular subsystem. - - In contrast to the previous work unit, this work unit calls for - the evaluator to assess the information provided for - SFR-enforcing subsystems that is SFR-supporting or - SFR-non-interfering. The goal of this assessment is two-fold. - First, it should provide the evaluator greater understanding of - the way each subsystem works. Second, the evaluator determines - that all SFR-enforcing behaviour exhibited by a subsystem has - been described. Unlike the previous work unit, the information - provided for the SFR-supporting or SFR-non-interfering behaviour - does not have to be as detailed as that provided by the - SFR-enforcing behaviour. For example, data structures or data - items that do not pertain to SFR-enforcing functionality will - likely not need to be described in detail, if at all. It is the - evaluator's determination, however, with respect to what - ``high-level'' means for a particular TOE, and the evaluator - obtains enough information from the developer (even if it turns - out to be equivalent to information provided for the parts of - the subsystem that are SFR-enforcing) to make a sound verdict - for this work unit. - - The evaluator is cautioned, however, that ``perfect'' - assurance is not a goal nor required by this work unit, - so judgement will have to be exercised in determine the - amount and composition of the evidence required to make - a verdict on this work unit. - - To determine completeness and accuracy, the evaluator examines - other information available (e.g., functional specification, - security architecture description). Descriptions of functionality in these - documents should be consistent with what is provided for - evidence for this work unit. In particular, the functional - specification should be used to determine that the behaviour - required to implement the TSF Interfaces described by the - functional specification are completely described by the - subsystem, since the behaviour will either be SFR-enforcing, - SFR-supporting or SFR-non-interfering. - - - - - The evaluator shall examine the TOE design to determine - that it provides a complete and accurate high-level - description of the behaviour of the SFR-supporting - subsystems. - - The developer may designate subsystems as SFR-enforcing, - SFR-supporting, and SFR non-interfering, but these - ``tags'' are used only to describe the amount and type - of information the developer must provide, and can be - used to limit the amount of information the developer - has to develop if their engineering process does not - produce the documentation required. Whether the - subsystems have been categorised by the developer or - not, it is the - evaluator's responsibility to determine that the - subsystems have the appropriate information for their - role (SFR-enforcing, etc.) in the TOE, and to obtain the - appropriate information from the developer should the - developer fail to provide the required information for a - particular subsystem. - - In contrast to the previous two work units, this work - unit calls for the developer to provide (and the - evaluator to assess) information about SFR supporting - subsystems. Such subsystems should be referenced by the - descriptions of the SFR-enforcing subsystems, as well as - by the descriptions of interactions in work unit . The goal of evaluator's - assessment, like that for the previous work unit, is - two-fold. First, it should provide the evaluator with - an understanding of the way each SFR-supporting - subsystem works. Second, the evaluator determines that - the behaviour is described in enough detail so that the - way in which the subsystem supports the SFR-enforcing - behaviour is clear, and that the behaviour is not itself - SFR-enforcing. The information provided for - SFR-supporting subsystem's behaviour does not have to be - as detailed as that provided by the SFR-enforcing - behaviour. For example, data structures or data items - that do not pertain to SFR-enforcing functionality will - likely not need to be described in detail, if at all. - It is the evaluator's determination, however, with - respect to what ``high-level'' means for a particular - TOE, and the evaluator obtains enough information from - the developer (even if it turns out to be equivalent to - information provided for the parts of the subsystem that - are SFR-enforcing) to make a sound verdict for this work - unit. - - The evaluator is cautions, however, that ``perfect'' - assurance is not a goal nor required by this work unit, - so judgement will have to be exercised in determine the - amount and composition of the evidence required to make - a verdict on this work unit. - - To determine completeness and accuracy, the evaluator - examines other information available (e.g., functional - specification, security architecture description, - implementation representation). Descriptions of - functionality in these documents should be consistent - with what is provided for evidence for this work unit. - In particular, the functional specification should be - used to determine that the behaviour required to - implement the TSF Interfaces described by the functional - specification are completely described by the - subsystem. - - - - - The evaluator shall examine the TOE design to determine - that interactions between the subsystems of the TSF are - described. - - The goal of describing the interactions between the subsystems - is to help provide the reader a better understanding of how the - TSF performs it functions. These interactions do not need to be - characterised at the implementation level (e.g., parameters - passed from one routine in a subsystem to a routine in a - different subsystem; global variables; hardware signals (e.g., - interrupts) from a hardware subsystem to an interrupt-handling - subsystem), but the data elements identified for a particular - subsystem that are going to be used by another subsystem need to - be covered in this discussion. Any control relationships - between subsystems (e.g., a subsystem responsible for - configuring a rule base for a firewall system and the subsystem - that actually implements these rules) should also be - described. - - It should be noted while the developer should characterise all - interactions between subsystems, the evaluators need to use - their own judgement in assessing the completeness of the - description. If the reason for an interaction is unclear, or if - there are SFR-related interactions (discovered, for instance, in - examining the descriptions of subsystem behaviour) that do not - appear to be described, the evaluator ensures that this - information is provided by the developer. However, if the - evaluator can determine that interactions among a particular set - of subsystems, while incompletely described by the developer, - will not aid in understanding the overall functionality nor - security functionality provided by the TSF, then the evaluator - may choose to consider the description sufficient, and not - pursue completeness for its own sake. - - - - - The evaluator shall examine the TOE design to determine - that it contains a complete and accurate mapping from - the TSFI described in the functional specification to - the subsystems of the TSF described in the TOE - design. - - The subsystems described in the TOE design provide a - description of how the TSF works at a detailed level for - SFR-enforcing portions of the TSF, and at a higher level - for other portions of the TSF. The TSFI provide a - description of how the implementation is exercised. The - evidence from the developer identifies the subsystem - that is initially involved when an operation is - requested at the TSFI, and identify the various - subsystems that are primarily responsible for - implementing the functionality. Note that a complete - ``call tree'' for each TSFI is not required for this - work unit. - - The evaluator assesses the completeness of the mapping - by ensuring that all of the TSFI map to at least one - subsystem. The verification of accuracy is more - complex. - - The first aspect of accuracy is that each TSFI is mapped - to a subsystem at the TSF boundary. This determination - can be made by reviewing the subsystem description and - interactions, and from this information determining its - place in the architecture. The next aspect of accuracy - is that the mapping makes sense. For instance, mapping a - TSFI dealing with access control to a subsystem that - checks passwords is not accurate. The evaluator should - again use judgement in making this determination. The - goal is that this information aids the evaluator in - understanding the system and implementation of the SFRs, - and ways in which entities at the TSF boundary can - interact with the TSF. The bulk of the assessment of - whether the SFRs are described accurately by the - subsystems is performed in other work units. - - - - The evaluator shall determine that the design is an accurate - and complete instantiation of all security functional - requirements. - - - The evaluator shall examine the TOE security functional - requirements and the TOE design, to determine that all - ST security functional requirements are covered by the - TOE design. - - The evaluator may construct a map between the TOE security - functional requirements and the TOE design. This map will - likely be from a functional requirement to a set of - subsystems. Note that this map may have to be at a level of - detail below the component or even element level of the - requirements, because of operations (assignments, refinements, - selections) performed on the functional requirement by the ST - author. - - For example, the - component contains an element with assignments. If the - ST contained, for instance, ten rules in the assignment, and these ten - rules were implemented in specific places within fifteen - modules, it would be inadequate for the evaluator to map - to one subsystem and - claim the work unit had been completed. Instead, the - evaluator would map - (rule 1) to subsystem A, behaviours x, y, and z; (rule 2) to subsystem A, - behaviours x, p, and q; etc. - - - - The evaluator shall examine the TOE design to determine - that it is an accurate instantiation of all security - functional requirements. - - The evaluator ensures that each security requirement - listed in the TOE security functional requirements - subclause of the ST has a corresponding design description - in the TOE design that accurately details how the TSF - meets that requirement. This requires that the evaluator - identify a collection of subsystems that are responsible - for implementing a given functional requirement, and - then examine those subsystems to understand how the - requirement is implemented. Finally, the evaluator would - assess whether the requirement was accurately - implemented. - - As an example, if the ST requirements specified a - role-based access control mechanism, the evaluator would - first identify the subsystems that contribute to this - mechanism's implementation. This could be done by - in-depth knowledge or understanding of the TOE design or - by work done in the previous work unit. Note that this - trace is only to identify the subsystems, and is not the - complete analysis. - - The next step would be to understand what mechanism the - subsystems implemented. For instance, if the design - described an implementation of access control based on - UNIX-style protection bits, the design would not be an - accurate instantiation of those access control - requirements present in the ST example used above. If - the evaluator could not determine that the mechanism was - accurately implemented because of a lack of detail, the - evaluator would have to assess whether all of the - SFR-enforcing subsystems have been identified, or if - adequate detail had been provided for those - subsystems. - - - - - - - - - The objective of this sub-activity is to determine whether - the TOE design provides a description of the TOE in terms - of subsystems sufficient to determine the TSF boundary, - and provides a description of the TSF internals in terms - of modules (and optionally higher-level abstractions). It - provides a detailed description of the SFR-enforcing - modules and enough information about the SFR-supporting - and SFR-non-interfering modules for the evaluator to - determine that the SFRs are completely and accurately - implemented; as such, the TOE design provides an - explanation of the implementation representation. - - - - There are three types of activity that the evaluator must - undertake with respect to the TOE design. First, the evaluator - determines that the TSF boundary has been adequately - described. Second, the evaluator determines that the developer - has provided documentation that conforms to the content and - presentation requirements for this subsystem, and that is - consistent with other documentation provided for the - TOE. Finally, the evaluator must analyse the design information - provided for the SFR-enforcing modules (at a detailed level) and - the SFR-supporting and SFR-non-interfering modules (at a less detailed level) to - understand how the system is implemented, and with that - knowledge ensure that the TSFI in the functional specification - are adequately described, and that the test information - adequately tests the TSF (done in the work units). - - It is important to note that while the developer is obligated to - provide a complete description of the TSF (although - SFR-enforcing modules will have more detail than the - SFR-supporting or SFR-non-interfering modules), the evaluator is - expected to use their judgement in performing their - analysis. While the evaluator is expected to look at every - module, the detail to which they examine each module may - vary. The evaluator analyses each module in order to gain enough - understanding to determine the effect of the functionality of - the module on the security of the system, and the depth to which - they need to analyse the module may vary depending on the - module's role in the system. An important aspect of this - analysis is that the evaluator should use the other - documentation provided (TSS, functional specification, security - architecture description, and the TSF internal document) in - order to determine that the functionality that is described is - correct, and that the implicit designation of SFR-supporting or - SFR-non-interfering modules (see below) is supported by their - role in the system architecture. - - The developer may designate modules as SFR-enforcing, - SFR-supporting, and SFR non-interfering, but these - ``tags'' are used only to describe the amount and type - of information the developer must provide, and can be - used to limit the amount of information the developer - has to develop if their engineering process does not - produce the documentation required. Whether the - modules have been categorised by the developer or - not, it is the - evaluator's responsibility to determine that the - modules have the appropriate information for their - role (SFR-enforcing, etc.) in the TOE, and to obtain the - appropriate information from the developer should the - developer fail to provide the required information for a - particular module. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the functional specification; - - - security architecture description; - - - the TOE design. - - - - - The developer shall provide the design of the TOE. - - - The developer shall provide a mapping from the TSFI of the - functional specification to the lowest level of - decomposition available in the TOE design. - - - The design shall describe the structure of the TOE in terms - of subsystems. - - - The design shall describe the TSF in terms of modules. - - - The design shall identify all subsystems of the TSF. - - - The design shall provide a description of each subsystem of - the TSF. - - - The design shall provide a description of the interactions - among all subsystems of the TSF. - - - The design shall provide a mapping from the subsystems of - the TSF to the modules of the TSF. - - - The design shall describe each SFR-enforcing module in terms of - its purpose and relationship with other modules. - - - The design shall describe each SFR-enforcing module in terms of - its SFR-related interfaces, return values from those interfaces, - interaction with other modules and called - SFR-related interfaces to other SFR-enforcing modules. - - - The design shall describe each SFR-supporting or - SFR-non-interfering module in terms of its purpose and - interaction with other modules. - - - The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the TOE design to determine - that the structure of the entire TOE is described in - terms of subsystems. - - The evaluator ensures that all of the subsystems of the - TOE are identified. This description of the TOE will be - used as input to work unit , where the parts of the TOE that make up - the TSF are identified. That is, this requirement is on - the entire TOE rather than on only the TSF. - - The TOE (and TSF) may be described in multiple layers of - abstraction (i.e. subsystems and modules). Depending upon the - complexity of the TOE, its design may be described in terms of - subsystems and modules, as described in CC Part 3 . For a very simple TOE that can be - described solely at the ``module'' level (see ), this work unit is not - applicable and therefore considered to be satisfied. - - In performing this activity, the evaluator examines - other evidence presented for the TOE (e.g., ST, operator - user guidance) to determine that the description of the - TOE in such evidence is consistent with the description - contained in the TOE design. - - - - - The evaluator shall examine the TOE design to determine - that the entire TSF is described in terms of - modules. - - The evaluator will examine the modules for specific - properties in other work units; in this work unit the - evaluator determines that the modular description covers - the entire TSF, and not just a portion of the TSF. The - evaluator uses other evidence provided for the - evaluation (e.g., functional specification, - security architecture description) in making this - determination. For example, if the - functional specification contains interfaces to - functionality that does not appear to be described in - the TOE design description, it may be the case that a - portion of the TSF has not been included - appropriately. Making this determination will likely be - an iterative process, where as more analysis is done on - the other evidence, more confidence can be gained with - respect to the completeness of the documentation. - - Unlike subsystems, modules describe the implementation in a level of detail that can serve - as a guide to reviewing the implementation representation. A description of a module should - be such that one could create an implementation of the module from the description, and the - resulting implementation would be 1) identical to the actual TSF implementation in terms of - the interfaces presented, 2) identical in the use of interfaces that are mentioned in the - design, and 3) functionally equivalent to the description of the purpose of the TSF module. - For instance, RFC 793 provides a high-level description of the TCP protocol. It is - necessarily implementation independent. While it provides a wealth of detail, it is - not - a suitable design description because it is not specific to an implementation. An actual - implementation can add to the protocol specified in the RFC, and implementation choices (for - instance, the use of global data vs. local data in various parts of the implementation) may - have an impact on the analysis that is performed. The design description of the TCP module would - list the interfaces presented by the implementation (rather than just those defined in RFC 793), - as well as an algorithm description of the processing associated with the modules implementing - TCP (assuming it was part of the TSF). - - - - - The evaluator shall examine the TOE design to determine - that all subsystems of the TSF are identified. - - If the design is presented solely in terms of modules, - then subsystems in these requirements are equivalent to - modules and the activity should be performed at the - module level. - - In work unit all of - the subsystems of the TOE were identified, and a - determination made that the non-TSF subsystems were - correctly characterised. Building on that work, the - subsystems that were not characterised as non-TSF - subsystems should be precisely identified. The evaluator - determines that, of the hardware and software installed - and configured according to the guidance, each subsystem has been - accounted for as either one that is part of the TSF, or - one that is not. - - - - - The evaluator shall examine the TOE design to determine - that each subsystem of the TSF describes its role in - the enforcement of SFRs described in the ST. - - If the design is presented solely in terms of modules, - then this work unit will be considered satisfied by the - assessment done in subsequent work units; no explicit - action on the part of the evaluator is necessary in this - case. - - On systems that are complex enough to warrant a - subsystem-level description of the TSF in addition to - the modular description, the goal of the subsystem-level - description is to give the evaluator context for the - modular description that follows. Therefore, the - evaluator ensures that the subsystem-level description - contains a description of how the security functional - requirements are achieved in the design, but at a level - of abstraction above the modular description. This - description should discuss the mechanisms used at a - level that is aligned with the module description; this - will provide the evaluators the road map needed to - intelligently assess the information contained in the - module description. A well-written set of subsystem - descriptions will help guide the evaluator in - determining the modules that are most important to - examine, thus focusing the evaluation activity on the - portions of the TSF that have the most relevance with - respect to the enforcement of the SFRs. - - The evaluator ensures that all subsystems of the TSF - have a description. While the description should focus - on the role that the subsystem plays in enforcing or - supporting the implementation of the SFRs, enough - information must be present so that a context for - understanding the SFR-related functionality is - provided. - - The evaluator shall examine the TOE design to determine that - each SFR-non-interfering subsystem of the TSF is described such that - the evaluator can determine that the subsystem is SFR-non-interfering. - If the design is presented solely in terms of modules, then this work unit - will be considered satisfied by the assessment done in subsequent work units; - no explicit action on the part of the evaluator is necessary in this case. - An SFR-non-interfering subsystem is one on which the SFR-enforcing and - SFR-supporting subsystems have no dependence; that is, they play no role - in implementing SFR functionality. - The evaluator ensures that all subsystems of the TSF have a description. - While the description should focus on the role that the subsystem do not plays - in enforcing or supporting the implementation of the SFRs, enough information - must be present so that a context for understanding the SFR-non-interfering - functionality is provided. - - - - The evaluator shall examine the TOE design to determine - that interactions between the subsystems of the TSF are - described. - - If the design is presented solely in terms of modules, - then this work unit will be considered satisfied by the - assessment done in subsequent work units; no explicit - action on the part of the evaluator is necessary in this - case. - - On systems that are complex enough to warrant a subsystem-level - description of the TSF in addition to the modular description, - the goal of describing the interactions between the subsystems - is to help provide the reader a better understanding of how the - TSF performs its functions. These interactions do not need to be - characterised at the implementation level (e.g., parameters - passed from one routine in a subsystem to a routine in a - different subsystem; global variables; hardware signals (e.g., - interrupts) from a hardware subsystem to an interrupt-handling - subsystem), but the data elements identified for a particular - subsystem that are going to be used by another subsystem should - be covered in this discussion. Any control relationships - between subsystems (e.g., a subsystem responsible for - configuring a rule base for a firewall system and the subsystem - that actually implements these rules) should also be described. - - It should be noted while the developer should characterise all - interactions between subsystems, the evaluators need to use - their own judgement in assessing the completeness of the - description. If the reason for an interaction is unclear, or if - there are SFR-related interactions (discovered, for instance, in - examining the module-level documentation) that do not appear to - be described, the evaluator ensures that this information is - provided by the developer. However, if the evaluator can - determine that interactions among a particular set of - subsystems, while incompletely described by the developer, and a - complete description will not aid in understanding the overall - functionality nor security functionality provided by the TSF, - then the evaluator may choose to consider the description - sufficient, and not pursue completeness for its own sake. - - - - - The evaluator shall examine the TOE design to determine - that the mapping between the subsystems of the TSF and - the modules of the TSF is complete. - - If the design is presented solely in terms of modules, - then this work unit is considered satisfied. - - For TOEs that are complex enough to warrant a - subsystem-level description of the TSF in addition to - the modular description, the developer provides a simple - mapping showing how the modules of the TSF are allocated - to the subsystems. This will provide the evaluator a - guide in performing their module-level assessment. To - determine completeness, the evaluator examines each - mapping and determines that all subsystems map to at - least one module, and that all modules map to exactly - one subsystem. - - - - - The evaluator shall examine the TOE design to determine - that the mapping between the subsystems of the TSF and - the modules of the TSF is accurate. - - If the design is presented solely in terms of modules, - then this work unit is considered satisfied. - - For TOEs that are complex enough to warrant a - subsystem-level description of the TSF in addition to - the modular description, the developer provides a simple - mapping showing how the modules of the TSF are allocated - to the subsystems. This will provide the evaluator a - guide in performing their module-level assessment. The - evaluator may choose to check the accuracy of the - mapping in conjunction with performing other work - units. An ``inaccurate'' mapping is one where the module - is mistakenly associated with a subsystem where its - functions are not used within the subsystem. Because the - mapping is intended to be a guide supporting more - detailed analysis, the evaluator is cautioned to apply - appropriate effort to this work unit. Expending - extensive evaluator resources verifying the accuracy of - the mapping is not necessary. Inaccuracies that lead to - mis-understandings related to the design that are - uncovered as part of this or other work units are the - ones that should be associated with this work unit and - corrected. - - - - - The evaluator shall examine the TOE design to determine - that the description of the purpose of each - SFR-enforcing module and relationship with other modules is complete and accurate. - - The developer may designate modules as SFR-enforcing, - SFR-supporting, and SFR non-interfering, but these - ``tags'' are used only to describe the amount and type - of information the developer must provide, and can be - used to limit the amount of information the developer - has to develop if their engineering process does not - produce the documentation required. Whether the - modules have been categorised by the developer or - not, it is the - evaluator's responsibility to determine that the - modules have the appropriate information for their - role (SFR-enforcing, etc.) in the TOE, and to obtain the - appropriate information from the developer should the - developer fail to provide the required information for a - particular module. - - The purpose of a module provides a description - indicating what function the module is fulfilling. A - word of caution to evaluator is in order. The focus of - this work unit should be to provide the evaluator an - understanding of how the module works so that - determinations can be made about the soundness of the - implementation of the SFRs, as well as to support - architectural analysis performed for component. As long as the evaluator has a - sound understanding of the module's operation, and its - relationship to other modules and the TOE as a whole, - the evaluator should consider the objective of the work - achieved and not engage in a documentation exercise for - the developer (by requiring, for example, a complete - algorithmic description for a self-evident - implementation representation). - Because the modules are at such a low level, it may be difficult - determine completeness and accuracy impacts from other - documentation, such as operational user guidance, the functional - specification, the TSF internals, or the security architecture - description. However, the evaluator uses the information present - in those documents to the extent possible to help ensure that - the purpose is accurately and completely described. This - analysis can be aided by the analysis performed for the work - units for the element, - which maps the TSFI in the functional specification to the - modules of the TSF. - - - - - The evaluator shall examine the TOE design to determine - that the description of the interfaces presented by each - SFR-enforcing module contain an accurate and complete - description of the SFR-related parameters, the - invocation conventions for each interface, and any - values returned directly by the interface. - - The SFR-related interfaces of a module are those - interfaces used by other modules as a means to invoke - the SFR-related operations provided, and to provide - inputs to or receive outputs from the module. The - purpose in the specification of these interfaces is to - permit the exercise of them during testing. - Inter-module interfaces that are not SFR-related need - not be specified or described, since they are not a - factor in testing. Likewise, other internal interfaces - that are not a factor in traversing SFR-related paths of - execution (such as those internal paths that are fixed) - need not be specified or described, since they are not a factor in testing. - - SFR-related interfaces are described in terms of how - they are invoked, and any values that are returned. This - description would include a list of SFR-related - parameters, and descriptions of these parameters. Note - that global data would also be considered parameters if - used by the module (either as inputs or outputs) when - invoked. If a parameter were expected to take on a set - of values (e.g., a ``flag'' parameter), the complete set - of values the parameter could take on that would have an - effect on module processing would be - specified. Likewise, parameters representing data - structures are described such that each field of the - data structure is identified and described. Note that - different programming languages may have additional - ``interfaces'' that would be non-obvious; an example - would be operator/function overloading in C++. This - ``implicit interface'' in the class description would - also be described as part of the low-level TOE - design. Note that although a module could present only - one interface, it is more common that a module presents - a small set of related interfaces. - - In terms of the assessment of parameters (inputs and - outputs) to a module, any use of global data must also - be considered. A module ``uses'' global data if it - either reads or writes the data. In order to assure the - description of such parameters (if used) is complete, - the evaluator uses other information provided about the - module in the TOE design (interfaces, algorithmic - description, etc.), as well as the description of the - particular set of global data assessed in work unit - . For instance, the - evaluator could first determine the processing the - module performs by examining its function and interfaces - presented (particularly the parameters of the - interfaces). They could then check to see if the - processing appears to ``touch'' any of the global data - areas identified in the TOE design. The evaluator then - determines that, for each global data area that appears - to be ``touched'', that global data area is listed as a - means of input or output by the module the evaluator is - examining. - - Invocation conventions are a programming-reference-type - description that one could use to correctly invoke a - module's interface if one were writing a program to make - use of the module's functionality through that - interface. This includes necessary inputs and outputs, - including any set-up that may need to be performed with - respect to global variables. - - Values returned through the interface refer to values - that are either passed through parameters or messages; - values that the function call itself returns in the - style of a ``C'' program function call; or values passed - through global means (such as certain error routines in - *ix-style operating systems). - - In order to assure the description is complete, the - evaluator uses other information provided about the - module in the TOE design (e.g., algorithmic description, - global data used) to ensure that it appears all data - necessary for performing the functions of the module is - presented to the module, and that any values that other - modules expect the module under examination to provide - are identified as being returned by the module. The - evaluator determines accuracy by ensuring that the - description of the processing matches the information - listed as being passed to or from an interface. - - - - - - The evaluator shall examine the TOE design to determine that - SFR-supporting and SFR-non-interfering modules are correctly - categorised. - - In the cases where the developer has provided different amounts - of information for different modules, an implicit categorisation - has been done. That is, modules (for instance) with detail - presented on their SFR-related interfaces (see ) are candidate SFR-enforcing - modules, although examination by the evaluator may lead to a - determination that some set of them are SFR-supporting or - SFR-non-interfering. Those with only a description of their - purpose and interaction with other modules (for instance) are - ``implicitly categorised'' as SFR-supporting or - SFR-non-interfering. - - In these cases, a key focus of the evaluator for this work unit - is attempting to determine from the evidence provided for each - module implicitly categorised as SFR-supporting or - SFR-non-interfering and the evaluation information about other - modules (in the TOE design, the functional specification, the - security architecture description, and the operational user - guidance), whether the module is indeed SFR-supporting or - SFR-non-interfering. At this level of assurance some error - should be tolerated; the evaluator does not have to be - absolutely sure that a given module is SFR-supporting or - SFR-non-interfering, even though it is labelled as - such. However, if the evidence provided indicates that a - SFR-supporting or SFR-non-interfering module is SFR-enforcing, - the evaluator requests additional information from the developer - in order to resolve the apparent inconsistency. For instance, - suppose the documentation for Module A (an SFR-enforcing module) - indicates that it calls Module B to perform an access check on a - certain type of construct. When the evaluator examines the - information associated with Module B, they find that all the - developer has provided is a purpose and a set of interactions - (thus implicitly categorising Module B as SFR-supporting or - SFR-non-interfering). On examining the purpose and interactions - from Module A, the evaluator finds no mention of Module B - performing any access checks, and Module A is not listed as a - module with which Module B interacts. At this point the - evaluator should approach the developer to resolve the - discrepancies between the information provided in Module A and - that in Module B. - - Another example would be where the evaluator examines the - mapping of the TSFI to the modules as provided by . This examination shows that - Module C is associated with an SFR requiring identification of - the user. Again, when the evaluator examines the information - associated with Module C, they find that all the developer has - provided is a purpose and a set of interactions (thus implicitly - categorising Module C as SFR-supporting or - SFR-non-interfering). Examining the purpose and interactions - presented for Module C, the evaluator is unable to determine why - Module C, listed as mapping to a TSFI concerned with user - identification, would not be classified as SFR-enforcing. Again, - the evaluator should approach the developer to resolve this - discrepancy. - - - A final example is from the opposite point of view. As - before, the developer has provided information associated - with Module D consisting of a purpose and a set of - interactions (thus implicitly categorising Module D as - SFR-supporting or SFR-non-interfering). The evaluator - examines all of the evidence provided, including the purpose - and interactions for Module D. The purpose appears to give a - meaningful description of Module D's function in the TOE, - the interactions are consistent with that description, and - there is nothing to indicate that Module D is - SFR-enforcing. In this case, the evaluator should not demand - more information about Module D ``just be to sure'' it is - correctly categorised. The developer has met their - obligations and the resulting assurance the evaluator has in - the implicit categorisation of Module D is (by definition) - appropriate for this assurance level. - - - - - The evaluator shall examine the TOE design to determine that the - description of the purpose of each SFR-supporting or - SFR-non-interfering module is complete and accurate. - - The description of the purpose of a module indicates - what function the module is fulfilling. From the - description, the evaluator should be able to obtain a - general idea of the module's role. In order to assure - the description is complete, the evaluator uses the - information provided about the module's interactions - with other modules to assess whether the reasons for the - module being called are consistent with the module's - purpose. If the interaction description contains - functionality that is not apparent from, or in conflict - with, the module's purpose, the evaluator needs to - determine whether the problem is one of accuracy or of - completeness. The evaluator should be wary of purposes - that are too short, since meaningful analysis based on a - one-sentence purpose is likely to be impossible. - - Because the modules are at such a low level, it may be difficult determine - completeness and accuracy impacts from other documentation, - such as administrative guidance, the functional specification, - the security architecture description, or the TSF internals document. - However, the evaluator uses the information present in those documents - to the extent possible to help ensure that the function is accurately - and completely described. This analysis can be aided by the analysis - performed for the work units for the ADV_TDS.3.10C element, - which maps the TSFI in the functional specification to the modules of the TSF. - - - - - The evaluator shall examine the TOE design to determine that the - description of a SFR-supporting or SFR-non-interfering module's - interaction with other modules is complete and accurate. - - It is important to note that, in terms of the Part 3 - requirement and this work unit, the term - interaction is intended to convey less - rigour than interface. An interaction - does not need to be characterised at the implementation - level (e.g., parameters passed from one routine in a - module to a routine in a different module; global - variables; hardware signals (e.g., interrupts) from a - hardware subsystem to an interrupt-handling subsystem), - but the data elements identified for a particular module - that are going to be used by another module should be - covered in this discussion. Any control relationships - between modules (e.g., a module responsible for - configuring a rule base for a firewall system and the - module that actually implements these rules) should also - be described. - - Because the modules are at such a low level, it may be difficult - determine completeness and accuracy impacts from other - documentation, such as operational user guidance, the functional - specification, the security architecture description, or the TSF - internals document. However, the evaluator uses the information - present in those documents to the extent possible to help ensure - that the function is accurately and completely described. This - analysis can be aided by the analysis performed for the work - units for the element, - which maps the TSFI in the functional specification to the - modules of the TSF. - - A module's interaction with other modules goes beyond - just a call-tree-type document. The interaction is - described from a functional perspective of why a module - interacts with other modules. The module's purpose - describes what functions the module provides to other - modules; the interactions should describe what the - module depends on from other modules in order to - accomplish this function. - - - - - - The evaluator shall examine the TOE design to determine - that it contains a complete and accurate mapping from - the TSFI described in the functional specification to - the modules of the TSF described in the TOE - design. - - The modules described in the TOE design provide a description of - the implementation of the TSF. The TSFI provide a description of - how the implementation is exercised. The evidence from the - developer identifies the module that is initially invoked when - an operation is requested at the TSFI, and identifies the chain - of modules invoked up to the module that is primarily - responsible for implementing the functionality. However, a - complete call tree for each TSFI is not required for this work - unit. The cases in which more than one module would have to be - identified are where there are ``entry point'' modules or - wrapper modules that have no functionality other than - conditioning inputs or de-multiplexing an input. Mapping to one - of these modules would not provide any useful information to the - evaluator. - - The evaluator assesses the completeness of the mapping - by ensuring that all of the TSFI map to at least one - module. The verification of accuracy is more - complex. - - The first aspect of accuracy is that each TSFI is mapped to a module at the TSF boundary. - This determination can be made by reviewing the module description and its - interfaces/interactions. The next aspect of accuracy is that each TSFI identifies - a chain of modules between the initial module identified and a module - that is primarily responsible for implementing the function presented at the TSF. - Note that this may be the initial module, or there may be several modules, - depending on how much pre-conditioning of the inputs is done. It should be noted that - one indicator of a pre-conditioning module is that it is invoked for a large number - of the TSFI, where the TSFI are all of similar type (e.g., system call). - The final aspect of accuracy is that the mapping makes sense. For instance, - mapping a TSFI dealing with access control to a module that checks passwords - is not accurate. The evaluator should again use judgement in making this determination. - The goal is that this information aids the evaluator in understanding the system and - implementation of the SFRs, and ways in which entities at the TSF boundary can interact - with the TSF. The bulk of the assessment of whether the SFRs are described accurately - by the modules is performed in other work units. - - - - The evaluator shall determine that the design is an accurate - and complete instantiation of all security functional - requirements. - - - The evaluator shall examine the TOE security functional - requirements and the TOE design, to determine that all - ST security functional requirements are covered by the - TOE design. - - The evaluator may construct a map between the TOE - security functional requirements and the TOE design. - This map will likely be from a functional requirement to - a set of subsystems, and later to modules. Note that this map may have to be - at a level of detail below the component or even element - level of the requirements, because of operations - (assignments, refinements, selections) performed on the - functional requirement by the ST author. - - For example, the - component contains an element with assignments. If the - ST contained, for instance, ten rules in the assignment, and these ten - rules were implemented in specific places within fifteen - modules, it would be inadequate for the evaluator to map - to one subsystem and - claim the work unit had been completed. Instead, the - evaluator would map - (rule 1) to modules x, y, and z of subsystem A; - (rule 2) to modules x, p, and q of subsystem A; etc. - - - - The evaluator shall examine the TOE design to determine - that it is an accurate instantiation of all security - functional requirements. - - The evaluator may construct a map between the TOE security - functional requirements and the TOE design. This map will - likely be from a functional requirement to a set of - subsystems. Note that this map may have to be at a level of - detail below the component or even element level of the - requirements, because of operations (assignments, refinements, - selections) performed on the functional requirement by the ST - author. - - As an example, if the ST requirements specified a - role-based access control mechanism, the evaluator would - first identify the subsystems, and modules that contribute to this - mechanism's implementation. This could be done by - in-depth knowledge or understanding of the TOE design or - by work done in the previous work unit. Note that this - trace is only to identify the subsystems, and modules, and is not the - complete analysis. - - The next step would be to understand what mechanism the - subsystems, and modules implemented. For instance, if the design - described an implementation of access control based on - UNIX-style protection bits, the design would not be an - accurate instantiation of those access control - requirements present in the ST example used above. If - the evaluator could not determine that the mechanism was - accurately implemented because of a lack of detail, the - evaluator would have to assess whether all of the - SFR-enforcing subsystems and modules have been identified, or if - adequate detail had been provided for those subsystems and modules. - - - - - - - - - The objective of this sub-activity is to determine whether - the TOE design provides a description of the TOE in terms - of subsystems sufficient to determine the TSF boundary, - and provides a description of the TSF internals in terms - of modules (and optionally higher-level abstractions). It - provides a detailed description of the SFR-enforcing and - SFR-supporting modules and enough information about the - SFR-non-interfering modules for the evaluator to determine - that the SFRs are completely and accurately implemented; - as such, the TOE design provides an explanation of the - implementation representation. - - - - There are three types of activity that the evaluator must - undertake with respect to the TOE design. First, the evaluator - determines that the TSF boundary has been adequately - described. Second, the evaluator determines that the developer - has provided documentation that conforms to the content and - presentation requirements this subsystem, and that is consistent - with other documentation provided for the TOE. Finally, the - evaluator must analyse the design information provided for the - SFR-enforcing modules (at a detailed level) and the - SFR-supporting and SFR-non-interfering modules (at a less detailed level) to - understand how the system is implemented, and with that - knowledge ensure that the TSFI in the functional specification - are adequately described, and that the test information - adequately tests the TSF (done in the work units). - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the functional specification; - - - security architecture description; - - - the TOE design. - - - - - The developer shall provide the design of the TOE. - - - The developer shall provide a mapping from the TSFI of the - functional specification to the lowest level of - decomposition available in the TOE design. - - - The design shall describe the structure of the TOE in terms - of subsystems. - - - The design shall describe the TSF in terms of modules, - designating each module as SFR-enforcing, - SFR-supporting, or SFR-non-interfering. - - - The design shall identify all subsystems of the TSF. - - - The design shall provide a semiformal description of each subsystem of - the TSF, supported by informal, explanatory text where appropriate. - - - The design shall provide a description of the interactions - among all subsystems of the TSF. - - - The design shall provide a mapping from the subsystems of - the TSF to the modules of the TSF. - - - The design shall describe each SFR-enforcing and SFR-supporting - module in terms of its purpose and relationship with other - modules. - - - The design shall describe each SFR-enforcing and SFR-supporting module - in terms of its SFR-related interfaces, return values from those interfaces, - interaction with other modules and called SFR-related - interfaces to other SFR-enforcing or SFR-supporting modules. - - - The design shall describe each SFR-non-interfering module in - terms of its purpose and interaction with other modules. - - - The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the TOE design to determine - that the structure of the entire TOE is described in - terms of subsystems. - - The evaluator ensures that all of the subsystems of the - TOE are identified. This description of the TOE will be - used as input to work unit , where the parts of the TOE that make up - the TSF are identified. That is, this requirement is on - the entire TOE rather than on only the TSF. - - The TOE (and TSF) may be described in multiple layers of - abstraction (i.e. subsystems and modules) Depending upon - the complexity of the TOE, its design may be described - in terms of subsystems and modules, as described in CC - Part 3 . For a very - simple TOE that can be described solely at the - ``module'' level (see ), this work unit is not applicable and - therefore considered to be satisfied. - - In performing this activity, the evaluator examines - other evidence presented for the TOE (e.g., ST, operator - user guidance) to determine that the description of the - TOE in such evidence is consistent with the description - contained in the TOE design. - - - - - The evaluator shall examine the TOE design to determine - that the entire TSF is described in terms of - modules. - - The evaluator will examine the modules for specific - properties in other work units; in this work unit the - evaluator determines that the modular description covers - the entire TSF, and not just a portion of the TSF. The - evaluator uses other evidence provided for the - evaluation (e.g., functional specification, - architectural description) in making this - determination. For example, if the functional - specification contains interfaces to functionality that - does not appear to be described in the TOE design - description, it may be the case that a portion of the - TSF has not been included appropriately. Making this - determination will likely be an iterative process, where - as more analysis is done on the other evidence, more - confidence can be gained with respect to the - completeness of the documentation. - - Unlike subsystems, modules describe the implementation in a level of detail that can serve - as a guide to reviewing the implementation representation. A description of a module should - be such that one could create an implementation of the module from the description, and the - resulting implementation would be 1) identical to the actual TSF implementation in terms of - the interfaces presented, 2) identical in the use of interfaces that are mentioned in the - design, and 3) functionally equivalent to the description of the purpose of the TSF module. - For instance, RFC 793 provides a high-level description of the TCP protocol. It is - necessarily implementation independent. While it provides a wealth of detail, it is - not - a suitable design description because it is not specific to an implementation. An actual - implementation can add to the protocol specified in the RFC, and implementation choices (for - instance, the use of global data vs. local data in various parts of the implementation) may - have an impact on the analysis that is performed. The design description of the TCP module would - list the interfaces presented by the implementation (rather than just those defined in RFC 793), - as well as an algorithm description of the processing associated with the modules implementing - TCP (assuming it was part of the TSF). - - - - - The evaluator shall check the TOE design to determine - that the TSF modules are identified as either - SFR-enforcing, SFR-supporting, or - SFR-non-interfering. - - The purpose of designating each module (according to the role a - particular module plays in the enforcement of the SFRs) is to - allow developers to provide less information about the parts of - the TSF that have little role in security. It is always - permissible for the developer to provide more information or - detail than the requirements demand, as might occur when the - information has been gathered outside the evaluation context. In - such cases the developer must still designate the modules as - either SFR-enforcing, SFR-supporting, or - SFR-non-interfering. - - The accuracy of these designations is continuously - reviewed as the evaluation progresses. The concern is - the mis-designation of modules as being less important - (and hence, having less information) than is really the - case. While blatant mis-designations may be immediately - apparent (e.g., designating an authentication module as - anything but SFR-enforcing when is one of the SFRs being claimed), other - mis-designations might not be discovered until the TSF - is better understood. The evaluator must therefore keep - in mind that these designations are the developer's - initial best effort, but are subject to change. Further - guidance is provided under work unit , which examines the - accuracy of these designations. - - - - - The evaluator shall examine the TOE design to determine - that all subsystems of the TSF are identified. - - If the design is presented solely in terms of modules, - then subsystems in these requirements are equivalent to - modules and the activity should be performed at the - module level. - - In work unit all of - the subsystems of the TOE were identified, and a - determination made that the non-TSF subsystems were - correctly characterised. Building on that work, the - subsystems that were not characterised as non-TSF - subsystems should be precisely identified. The evaluator - determines that, of the hardware and software installed - and configured according to the guidance, each subsystem has been - accounted for as either one that is part of the TSF, or - one that is not. - The evaluator shall examine the TDS documentation to determine - that the semiformal notation used for describing the subsystems, modules and - their interfaces is defined or referenced.A semiformal notation can be either defined by the sponsor or - a corresponding standard be referenced. The evaluator should provide a mapping - of security functions and their interfaces outlining in what part of the - documentation a function or interface is semiformal described and what notation - is used. The evaluator examines all semiformal notations used to make sure that - they are of a semiformal style and to justify the appropriateness of the manner - how the semiformal notations are used for the TOE.The evaluator is reminded that a semi-formal presentation is - characterised by a standardised format with a well-defined syntax that reduces - ambiguity that may occur in informal presentations. The syntax of all semiformal - notations used in the functional specification shall be defined or a corresponding - standard be referenced. The evaluator verifies that the semiformal notations used - for expressing the functional specification are capable of expressing features - relevant to security. In order to determine this, the evaluator can refer to the - SFR and compare the TSF security features stated in the ST and those described - in the FSP using the semiformal notations. - - - - The evaluator shall examine the TOE design to determine - that each subsystem of the TSF describes its role in - the enforcement of SFRs described in the ST. - - If the design is presented solely in terms of modules, - then this work unit will be considered satisfied by the - assessment done in subsequent work units; no explicit - action on the part of the evaluator is necessary in this - case. - - On systems that are complex enough to warrant a - subsystem-level description of the TSF in addition to - the modular description, the goal of the subsystem-level - description is to give the evaluator context for the - modular description that follows. Therefore, the - evaluator ensures that the subsystem-level description - contains a description of how the security functional - requirements are achieved in the design, but at a level - of abstraction above the modular description. This - description should discuss the mechanisms used at a - level that is aligned with the module description; this - will provide the evaluators the road map needed to - intelligently assess the information contained in the - module description. A well-written set of subsystem - descriptions will help guide the evaluator in - determining the modules that are most important to - examine, thus focusing the evaluation activity on the - portions of the TSF that have the most relevance with - respect to the enforcement of the SFRs. - - The evaluator ensures that all subsystems of the TSF - have a description. While the description should focus - on the role that the subsystem plays in enforcing or - supporting the implementation of the SFRs, enough - information must be present so that a context for - understanding the SFR-related functionality is - provided. - - The evaluator shall examine the TOE design to determine that - each SFR-non-interfering subsystem of the TSF is described such that - the evaluator can determine that the subsystem is SFR-non-interfering. - If the design is presented solely in terms of modules, then this work unit - will be considered satisfied by the assessment done in subsequent work units; - no explicit action on the part of the evaluator is necessary in this case. - An SFR-non-interfering subsystem is one on which the SFR-enforcing and - SFR-supporting subsystems have no dependence; that is, they play no role - in implementing SFR functionality. - The evaluator ensures that all subsystems of the TSF have a description. - While the description should focus on the role that the subsystem do not plays - in enforcing or supporting the implementation of the SFRs, enough information - must be present so that a context for understanding the SFR-non-interfering - functionality is provided. - - - - The evaluator shall examine the TOE design to determine - that interactions between the subsystems of the TSF are - described. - - If the design is presented solely in terms of modules, - then this work unit will be considered satisfied by the - assessment done in subsequent work units; no explicit - action on the part of the evaluator is necessary in this - case. - - On systems that are complex enough to warrant a subsystem-level - description of the TSF in addition to the modular description, - the goal of describing the interactions between the subsystems - is to help provide the reader a better understanding of how the - TSF performs it functions. These interactions do not need to be - characterised at the implementation level (e.g., parameters - passed from one routine in a subsystem to a routine in a - different subsystem; global variables; hardware signals (e.g., - interrupts) from a hardware subsystem to an interrupt-handling - subsystem), but the data elements identified for a particular - subsystem that are going to be used by another subsystem need to - be covered in this discussion. Any control relationships - between subsystems (e.g., a subsystem responsible for - configuring a rule base for a firewall system and the subsystem - that actually implements these rules) should also be - described. - - It should be noted while the developer should characterise all - interactions between subsystems, the evaluators need to use - their own judgement in assessing the completeness of the - description. If the reason for an interaction is unclear, or if - there are SFR-related interactions (discovered, for instance, in - examining the module-level documentation) that do not appear to - be described, the evaluator ensures that this information is - provided by the developer. However, if the evaluator can - determine that interactions among a particular set of - subsystems, while incompletely described by the developer, and a - complete description will not aid in understanding the overall - functionality nor security functionality provided by the TSF, - then the evaluator may choose to consider the description - sufficient, and not pursue completeness for its own sake. - - - - - The evaluator shall examine the TOE design to determine - that the mapping between the subsystems of the TSF and - the modules of the TSF is complete. - - If the design is presented solely in terms of modules, - then this work unit is considered satisfied. - - For TOEs that are complex enough to warrant a - subsystem-level description of the TSF in addition to - the modular description, the developer provides a simple - mapping showing how the modules of the TSF are allocated - to the subsystems. This will provide the evaluator a - guide in performing their module-level assessment. To - determine completeness, the evaluator examines each - mapping and determines that all subsystems map to at - least one module, and that all modules map to exactly - one subsystem. - - - - - The evaluator shall examine the TOE design to determine - that the mapping between the subsystems of the TSF to - the modules of the TSF is accurate. - - If the design is presented solely in terms of modules, - then this work unit is considered satisfied. - - For TOEs that are complex enough to warrant a - subsystem-level description of the TSF in addition to - the modular description, the developer provides a simple - mapping showing how the modules of the TSF are allocated - to the subsystems. This will provide the evaluator a - guide in performing their module-level assessment. The - evaluator may choose to check the accuracy of the - mapping in conjunction with performing other work - units. An ``inaccurate'' mapping is one where the module - is mistakenly associated with a subsystem where its - functions are not used within the subsystem. Because the - mapping is intended to be a guide supporting more - detailed analysis, the evaluator is cautioned to apply - appropriate effort to this work unit. Expending - extensive evaluator resources verifying the accuracy of - the mapping is not necessary. Inaccuracies that lead to - mis-understandings related to the design that are - uncovered as part of this or other work units are the - ones that should be associated with this work unit and - corrected. - - - - - The evaluator shall examine the TOE design to determine - that the description of the purpose of each - SFR-enforcing and SFR-supporting module, and relationship with other modules - is complete and accurate. - - The developer may designate modules as SFR-enforcing, - SFR-supporting, and SFR non-interfering, but these - ``tags'' are used only to describe the amount and type - of information the developer must provide, and can be - used to limit the amount of information the developer - has to develop if their engineering process does not - produce the documentation required. Whether the modules - have been categorised by the developer or not, it is the - evaluator's responsibility to determine that the modules - have the appropriate information for their role - (SFR-enforcing, etc.) in the TOE, and to obtain the - appropriate information from the developer should the - developer fail to provide the required information for a - particular module. - - The purpose of a module provides a description - indicating what function the module is fulfilling. A - word of caution to evaluator is in order. The focus of - this work unit should be to provide the evaluator an - understanding of how the module works so that - determinations can be made about the soundness of the - implementation of the SFRs, as well as to support - architectural analysis performed for subsystems. As long as the evaluator has a - sound understanding of the module's operation, and its - relationship to other modules and the TOE as a whole, - the evaluator should consider the objective of the work - achieved and not engage in a documentation exercise for - the developer (by requiring, for example, a complete - algorithmic description for a self-evident - implementation representation). - Because the modules are at such a low level, it may be difficult - determine completeness and accuracy impacts from other - documentation, such as operational user guidance, the functional - specification, the TSF internals, or the security architecture - description. However, the evaluator uses the information present - in those documents to the extent possible to help ensure that - the purpose is accurately and completely described. This - analysis can be aided by the analysis performed for the work - units for the element, - which maps the TSFI in the functional specification to the - modules of the TSF. - - - - - The evaluator shall examine the TOE design to determine - that the description of the interfaces presented by each - SFR-enforcing and SFR-supporting module contain an - accurate and complete description of the SFR-related - parameters, the invocation conventions for each - interface, and any values returned directly by the - interface. - - The SFR-related interfaces of a module are those - interfaces used by other modules as a means to invoke - the SFR-related operations provided, and to provide - inputs to or receive outputs from the module. The - purpose in the specification of these interfaces is to - permit the exercise of them during testing. - Inter-module interfaces that are not SFR-related need - not be specified or described, since they are not a - factor in testing. Likewise, other internal interfaces - that are not a factor in traversing SFR-related paths of - execution (such as those internal paths that are - fixed). - SFR-related interfaces of SFR-supporting modules are all - interfaces of SFR-supporting modules that are called directly - or indirectly from SFR-enforcing modules. Those interfaces - need to be described with all the parameter used in such a - call. This allows the evaluator to understand the purpose of - the call to the SFR-supporting module in the context of - operation of the SFR-enforcing modules. - - SFR-related interfaces are described in terms of how - they are invoked, and any values that are returned. This - description would include a list of parameters, and - descriptions of these parameters. Note that global data - would also be considered parameters if used by the - module (either as inputs or outputs) when invoked. If a - parameter were expected to take on a set of values - (e.g., a ``flag'' parameter), the complete set of values - the parameter could take on that would have an effect on - module processing would be specified. Likewise, - parameters representing data structures are described - such that each field of the data structure is identified - and described. Note that different programming languages - may have additional ``interfaces'' that would be - non-obvious; an example would be operator/function - overloading in C++. This ``implicit interface'' in the - class description would also be described as part of the - low-level TOE design. Note that although a module could - present only one interface, it is more common that a - module presents a small set of related - interfaces. - - In terms of the assessment of parameters (inputs and - outputs) to a module, any use of global data must also - be considered. A module ``uses'' global data if it - either reads or writes the data. In order to assure the - description of such parameters (if used) is complete, - the evaluator uses other information provided about the - module in the TOE design (interfaces, algorithmic - description, etc.), as well as the description of the - particular set of global data assessed in work unit - . For instance, the - evaluator could first determine the processing the - module performs by examining its function and interfaces - presented (particularly the parameters of the - interfaces). They could then check to see if the - processing appears to ``touch'' any of the global data - areas identified in the TDS design. The evaluator then - determines that, for each global data area that appears - to be ``touched'', that global data area is listed as a - means of input or output by the module the evaluator is - examining. - - Invocation conventions are a programming-reference-type - description that one could use to correctly invoke a - module's interface if one were writing a program to make - use of the module's functionality through that - interface. This includes necessary inputs and outputs, - including any set-up that may need to be performed with - respect to global variables. - - Values returned through the interface refer to values - that are either passed through parameters or messages; - values that the function call itself returns in the - style of a ``C'' program function call; or values passed - through global means (such as certain error routines in - *ix-style operating systems). - - In order to assure the description is complete, the - evaluator uses other information provided about the - module in the TOE design (e.g., algorithmic description, - global data used) to ensure that it appears all data - necessary for performing the functions of the module is - presented to the module, and that any values that other - modules expect the module under examination to provide - are identified as being returned by the module. The - evaluator determines accuracy by ensuring that the - description of the processing matches the information - listed as being passed to or from an interface. - - - - - - The evaluator shall examine the TOE design to determine - that SFR-non-interfering modules are correctly - categorised. - - As mentioned in work unit , - less information is required about modules that are - SFR-non-interfering. A key focus of the evaluator for this work - unit is attempting to determine from the evidence provided for - each module implicitly categorised as SFR-non-interfering and - the evaluation (information about other modules in the TOE - design, the functional specification, the security architecture - description, the operational user guidance, the TSF internals - document, and perhaps even the implementation representation) - whether the module is indeed SFR-non-interfering. At this level - of assurance some error should be tolerated; the evaluator does - not have to be absolutely sure that a given module is - SFR-non-interfering, even though it is labelled as - such. However, if the evidence provided indicates that a - SFR-non-interfering module is SFR-enforcing or SFR-supporting, - the evaluator requests additional information from the developer - in order to resolve the apparent inconsistency. For example, - suppose the documentation for Module A (an SFR-enforcing module) - indicates that it calls Module B to perform an access check on a - certain type of construct. When the evaluator examines the - information associated with Module B, it is discovered that the - only information the developer has provided is a purpose and a - set of interactions (thus implicitly categorising Module B as - SFR-supporting or SFR-non-interfering). On examining the purpose and interactions - from Module A, the evaluator finds no mention of Module B - performing any access checks, and Module A is not listed as a - module with which Module B interacts. At this point the - evaluator should approach the developer to resolve the - discrepancies between the information provided in Module A and - that in Module B. - - Another example would be where the evaluator examines - the mapping of the TSFI to the modules as provided by - . This examination - shows that Module C is associated with an SFR requiring - identification of the user. Again, when the evaluator - examines the information associated with Module C, they - find that all the developer has provided is a purpose - and a set of interactions (thus implicitly categorising - Module C as SFR-non-interfering). Examining the purpose - and interactions presented for Module C, the evaluator - is unable to determine why Module C, listed as mapping - to a TSFI concerned with user identification, would not - be classified as SFR-enforcing or SFR-supporting. Again, - the evaluator should approach the developer to resolve - this discrepancy. - - A final example illustrates the opposite situation. As - before, the developer has provided information - associated with Module D consisting of a purpose and a - set of interactions (thus implicitly categorising Module - D as SFR-non-interfering). The evaluator examines all of - the evidence provided, including the purpose and - interactions for Module D. The purpose appears to give a - meaningful description of Module D's function in the - TOE, the interactions are consistent with that - description, and there is nothing to indicate that - Module D is SFR-enforcing or SFR-supporting. In this - case, the evaluator should not demand more information - about Module D ``just be to sure'' it is correctly - categorised. The developer has met the obligations and - the resulting assurance the evaluator has in the - implicit categorisation of Module D is (by definition) - appropriate for this assurance level. - - - - - The evaluator shall examine the TOE design to determine - that the description of the purpose of each - SFR-non-interfering module is complete and - accurate. - - The description of the purpose of a module indicates - what function the module is fulfilling. From the - description, the evaluator should be able to obtain a - general idea of the module's role. In order to assure - the description is complete, the evaluator uses the - information provided about the module's interactions - with other modules to assess whether the reasons for the - module being called are consistent with the module's - purpose. If the interaction description contains - functionality that is not apparent from, or in conflict - with, the module's purpose, the evaluator needs to - determine whether the problem is one of accuracy or of - completeness. The evaluator should be wary of purposes - that are too short, since meaningful analysis based on a - one-sentence purpose is likely to be impossible. - - Because the modules are at such a low level, it may be difficult - determine completeness and accuracy impacts from other - documentation, such as operational user guidance, the functional - specification, the security architecture description, or the TSF - internals document. However, the evaluator uses the information - present in those documents to the extent possible to help ensure - that the function is accurately and completely described. This - analysis can be aided by the analysis performed for the work - units for the element, - which maps the TSFI in the functional specification to the - modules of the TSF. - - - - - The evaluator shall examine the TOE design to determine - that the description of a SFR-non-interfering module's - interaction with other modules is complete and - accurate. - - It is important to note that, in terms of the Part 3 - requirement and this work unit, the term - interaction is intended to convey less - rigour than interface. An interaction - does not need to be characterised at the implementation - level (e.g., parameters passed from one routine in a - module to a routine in a different module; global - variables; hardware signals (e.g., interrupts) from a - hardware subsystem to an interrupt-handling subsystem), - but the data elements identified for a particular module - that are going to be used by another module should be - covered in this discussion. Any control relationships - between modules (e.g., a module responsible for - configuring a rule base for a firewall system and the - module that actually implements these rules) should also - be described. - - A module's interaction with other modules can be captured in - many ways. The intent for the TOE design is to allow the - evaluator to understand (in part through analysis of module - interactions) the role of the SFR-supporting and - SFR-non-interfering modules in the overall TOE - design. Understanding of this role will aid the evaluator in - performing work unit . - - A module's interaction with other modules goes beyond - just a call-tree-type document. The interaction is - described from a functional perspective of why a module - interacts with other modules. The module's purpose - describes what functions the module provides to other - modules; the interactions should describe what the - module depends on from other modules in order to - accomplish this function. - - Because the modules are at such a low level, it may be difficult - determine completeness and accuracy impacts from other - documentation, such as operational user guidance, the functional - specification, the security architecture description, or the TSF - internals document. However, the evaluator uses the information - present in those documents to the extent possible to help ensure - that the interactions are accurately and completely - described. - - - - - The evaluator shall examine the TOE design to determine - that it contains a complete and accurate mapping from - the TSFI described in the functional specification to - the modules of the TSF described in the TOE - design. - - The modules described in the TOE design provide a - description of the implementation of the TSF. The TSFI - provide a description of how the implementation is - exercised. The evidence from the developer identifies - the module that is initially invoked when an operation - is requested at the TSFI, and identify the chain of - modules invoked up to the module that is primarily - responsible for implementing the functionality. However, - a complete call tree for each TSFI is not required for - this work unit. The cases in which more than one module - would have to be identified are where there are ``entry - point'' modules or wrapper modules that have no - functionality other than conditioning inputs or - de-multiplexing an input. Mapping to one of these - modules would not provide any useful information to the - evaluator. - - The evaluator assesses the completeness of the mapping - by ensuring that all of the TSFI map to at least one - module. The verification of accuracy is more - complex. - - The first aspect of accuracy is that each TSFI is mapped - to a module at the TSF boundary. This determination can - be made by reviewing the module description and its - interfaces/interactions. The next aspect of accuracy is - that each TSFI identifies a chain of modules between the - initial module identified and a module that is primarily - responsible for implementing the function presented at - the TSF. Note that this may be the initial module, or - there may be several modules, depending on how much - pre-conditioning of the inputs is done. It should be - noted that one indicator of a pre-conditioning module is - that it is invoked for a large number of the TSFI, where - the TSFI are all of similar type (e.g., system - call). The final aspect of accuracy is that the mapping - makes sense. For instance, mapping a TSFI dealing with - access control to a module that checks passwords is not - accurate. The evaluator should again use judgement in - making this determination. The goal is that this - information aids the evaluator in understanding the - system and implementation of the SFRs, and ways in which - entities at the TSF boundary can interact with the - TSF. The bulk of the assessment of whether the SFRs are - described accurately by the modules is performed in - other work units. - - - - The evaluator shall determine that the design is an accurate - and complete instantiation of all security functional - requirements. - - - The evaluator shall examine the TOE security functional - requirements and the TOE design, to determine that all - ST security functional requirements are covered by the - TOE design. - - The evaluator may construct a map between the TOE - security functional requirements and the TOE design. - This map will likely be from a functional requirement to - a set of subsystems, and later to modules. Note that this map may have to be - at a level of detail below the component or even element - level of the requirements, because of operations - (assignments, refinements, selections) performed on the - functional requirement by the ST author. - - For example, the - component contains an element with assignments. If the - ST contained, for instance, ten rules in the assignment, and these ten - rules were implemented in specific places within fifteen - modules, it would be inadequate for the evaluator to map - to one subsystem and - claim the work unit had been completed. Instead, the - evaluator would map - (rule 1) to modules x, y and z of subsystem A; - (rule 2) to x, p, and q of subsystem A; etc. - - - - The evaluator shall examine the TOE design to determine - that it is an accurate instantiation of all security - functional requirements. - - The evaluator may construct a map between the TOE security - functional requirements and the TOE design. This map will - likely be from a functional requirement to a set of - subsystems. Note that this map may have to be at a level of - detail below the component or even element level of the - requirements, because of operations (assignments, refinements, - selections) performed on the functional requirement by the ST - author. - - As an example, if the ST requirements specified a - role-based access control mechanism, the evaluator would - first identify the subsystems, and modules that contribute to this - mechanism's implementation. This could be done by - in-depth knowledge or understanding of the TOE design or - by work done in the previous work unit. Note that this - trace is only to identify the subsystems, and modules, and is not the - complete analysis. - - The next step would be to understand what mechanism the - subsystems, and modules implemented. For instance, if the design - described an implementation of access control based on - UNIX-style protection bits, the design would not be an - accurate instantiation of those access control - requirements present in the ST example used above. If - the evaluator could not determine that the mechanism was - accurately implemented because of a lack of detail, the - evaluator would have to assess whether all of the - SFR-enforcing subsystems and modules have been identified, or if - adequate detail had been provided for those subsystems and modules. - - - - - - - - - The objective of this sub-activity is to determine whether - the TOE design provides a description of the TOE in terms - of subsystems sufficient to determine the TSF boundary, - and provides a description of the TSF internals in terms - of modules (and optionally higher-level abstractions). It - provides a detailed description of all modules for the - evaluator to determine that the SFRs are completely and - accurately implemented; as such, the TOE design provides - an explanation of the implementation - representation. - - - - At this level, there is no differentiation of required - information according to SFR-relevance. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the functional specification; - - - security architecture description; - - - the TOE design; - - - the security architecture description; - - - the implementation representation. - - - - - The developer shall provide the design of the TOE. - - - The developer shall provide a mapping from the TSFI of the - functional specification to the lowest level of - decomposition available in the TOE design. - - - The design shall describe the structure of the TOE in terms - of subsystems. - - - The design shall describe the TSF in terms of modules, - designating each module as SFR-enforcing, - SFR-supporting, or SFR-non-interfering. - - - The design shall identify all subsystems of the TSF. - - - The design shall provide a semiformal description of each - subsystem of the TSF, supported by informal, explanatory text where - appropriate. - - - The design shall provide a description of the interactions among all subsystems of the TSF. - - - The design shall provide a mapping from the subsystems of - the TSF to the modules of the TSF. - - - The design shall provide a semiformal description of each module - in terms of its purpose, interaction, interfaces, return values - from those interfaces, and called interfaces to other modules, - supported by informal, explanatory text where appropriate. - - - The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - The evaluator shall determine that the design is an accurate - and complete instantiation of all security functional - requirements. - - - - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the functional specification; - - - security architecture description; - - - the TOE design; - - - the security architecture description; - - - the implementation representation. - - - - - The developer shall provide the design of the TOE. - - - The developer shall provide a mapping from the TSFI of the - functional specification to the lowest level of - decomposition available in the TOE design. - - - The developer shall provide a formal specification of the - TSF subsystems. - - - The developer shall provide a proof of correspondence - between the formal specifications of the TSF subsystems and - of the functional specification. - - - The design shall describe the structure of the TOE in terms - of subsystems. - - - The design shall describe the TSF in terms of modules, - designating each module as SFR-enforcing, - SFR-supporting, or SFR-non-interfering. - - - The design shall identify all subsystems of the TSF. - - - The design shall provide a semiformal description of each - subsystem of the TSF, supported by informal, explanatory text where - appropriate. - - - The design shall provide a description of the interactions among all subsystems of the TSF. - - - The design shall provide a mapping from the subsystems of - the TSF to the modules of the TSF. - - - The design shall describe each module in semiformal style in terms - of its purpose, interaction, interfaces, return values from those interfaces, - and called interfaces to other modules, supported by informal, explanatory - text where appropriate. - - - The formal specification of the TSF subsystems shall - describe the TSF using a formal style, supported by - informal, explanatory text where appropriate. - - - The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke. - - - The proof of correspondence between the formal - specifications of the TSF subsystems and of the functional - specification shall demonstrate that all behaviour described - in the TOE design is a correct and complete refinement of - the TSFI that invoked it. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - The evaluator shall determine that the design is an accurate - and complete instantiation of all security functional - requirements. - - - - - - - The guidance documents class provides the requirements for - guidance documentation for all user roles. For the secure - preparation and operation of the TOE it is necessary to - describe all relevant aspects for the secure handling of the - TOE. The class also addresses the possibility of unintended - incorrect configuration or handling of the TOE. - - In many cases it may be appropriate that guidance is provided - in separate documents for preparation and operation of the - TOE, or even separate for different user roles as end-users, - administrators, application programmers using software or - hardware interfaces, etc. - - The guidance documents class is subdivided into two families - which are concerned with the preparative user guidance (what - has to be done to transform the delivered TOE into its - evaluated configuration in the operational environment as - described in the ST) and with the operational user guidance - (what has to be done during the operation of the TOE in its - evaluated configuration). - - - - Assurance class defines - requirements directed at the understandability, coverage and - completeness of the preparative and operational documentation - provided by the developer. This documentation, which provides - information for all user roles, is an important factor in the - secure preparation and operation of the TOE. - - - - The purpose of the guidance document activity is to judge the - adequacy of the documentation describing how the user can - handle the TOE in a secure manner. Such documentation should - take into account the various types of users (e.g. those who - accept, install, administrate or operate the TOE) whose - incorrect actions could adversely affect the security of the - TOE or of their own data. - - The guidance documents class is subdivided into two families - which are concerned firstly with the preparative procedures - (all that has to be done to transform the delivered TOE into - its evaluated configuration in the environment as described in - the ST, i.e. accepting and installing the TOE) and secondly - with the operational user guidance (all that has to be done - during the operation of the TOE in its evaluated - configuration, i.e. operation and administration). - - - - The guidance documents activity applies to those functions and - interfaces which are related to the security of the TOE. The - secure configuration of the TOE is described in the ST. - - - - - Operational user guidance refers to written material that is - intended to be used by all types of users of the TOE in its - evaluated configuration: end-users, persons responsible for - maintaining and administering the TOE in a correct manner - for maximum security, and by others (e.g. programmers) using - the TOE's external interfaces. Operational user guidance - describes the security functionality provided by the TSF, - provides instructions and guidelines (including warnings), - helps to understand the TSF and includes the - security-critical information, and the security-critical - actions required, for its secure use. Misleading and - unreasonable guidance should be absent from the guidance - documentation, and secure procedures for all modes of - operation should be addressed. Insecure states should be - easy to detect. - - The operational user guidance provides a measure of - confidence that non-malicious users, administrators, - application providers and others exercising the external - interfaces of the TOE will understand the secure operation - of the TOE and will use it as intended. The evaluation of - the user guidance includes investigating whether the TOE can - be used in a manner that is insecure but that the user of - the TOE would reasonably believe to be secure. The objective - is to minimise the risk of human or other errors in - operation that may deactivate, disable, or fail to activate - security functionality, resulting in an undetected insecure - state. - - - - Requirements for operational user guidance help ensure that - all types of users are able to operate the TOE in a secure - manner (e.g. the usage constraints assumed by the PP or ST - must be clearly explained and illustrated). It should be - excluded that the TOE can be used in a manner that is - insecure but that the user of the TOE would reasonably - believe to be secure. Operational user guidance is the - primary vehicle available to the developer for providing the - TOE users with the necessary background and specific - information on how to correctly use the TOE's protection - functions. - - Operational user guidance must do two things. First, it - needs to explain what the security functionality accessible - by the user does and how it is to be used, so that users are - able to consistently and effectively protect their - information. Second, it needs to explain the user's role in - maintaining the TOE's security. - - - - This family contains only one component. - - - - There may be different user roles or groups that are - recognised by the TOE and that can interact with the - TSF. These user roles and groups should be taken into - consideration by the operational user guidance. They may be - roughly grouped into administrators and non-administrative - users, or more specifically grouped into persons responsible - for receiving, accepting, installing and maintaining the - TOE, application programmers, revisors, auditors, - daily-management, end-users. Each role can encompass an - extensive set of capabilities, or can be a single - one. - - The requirement - encompasses the aspect that any warnings to the users during - operation of a TOE with regard to the security problem - definition and the security objectives for the operational - environment described in the PP/ST are appropriately covered - in the user guidance. - - The concept of secure values, as employed in , has relevance where a user - has control over security parameters. Guidance needs to be - provided on secure and insecure settings for such - parameters. - - requires that the - user guidance describes the appropriate reactions to all - security-relevant events. Although many security-relevant - events are the result of performing functions, this need not - always be the case (e.g. the audit log fills up, an - intrusion is detected). Furthermore, a security-relevant - event may happen as a result of a specific chain of - functions or, conversely, several security-relevant events - may be triggered by one function. - - requires that the - user guidance is clear and reasonable. Misleading or - unreasonable guidance may result in a user of the TOE - believing that the TOE is secure when it is not. - - An example of misleading guidance would be the description - of a single guidance instruction that could be parsed in - more than one way, one of which may result in an insecure - state. - - An example of unreasonable guidance would be a - recommendation to follow a procedure that is so complicated - that it cannot reasonably be expected that users will follow - this guidance. - - - - - - The objectives of this sub-activity are to determine - whether the user guidance describes for each user role the - security functionality and interfaces provided by the TSF, - provides instructions and guidelines for the secure use of - the TOE, addresses secure procedures for all modes of - operation, facilitates prevention and detection of - insecure TOE states, or whether it is misleading or - unreasonable. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the functional specification; - - - the TOE design, if applicable; - - - the user guidance; - - - - - The developer shall provide operational user guidance. - - - The operational user guidance shall describe, for each user - role, the user-accessible functions and privileges that - should be controlled in a secure processing environment, - including appropriate warnings. - - - The operational user guidance shall describe, for each user - role, how to use the available interfaces provided by the - TOE in a secure manner. - - - The operational user guidance shall describe, for each user - role, the available functions and interfaces, in particular - all security parameters under the control of the user, - indicating secure values as appropriate. - - - The operational user guidance shall, for each user role, - clearly present each type of security-relevant event - relative to the user-accessible functions that need to be - performed, including changing the security characteristics - of entities under the control of the TSF. - - - The operational user guidance 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. - - - The operational user guidance shall, for each user role, - describe the security measures to be followed in order to - fulfil the security objectives for the operational - environment as described in the ST. - - - The operational user guidance shall be clear and reasonable. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the operational user - guidance to determine that it describes, for each user - role, the user-accessible functions and privileges that - should be controlled in a secure processing environment, - including appropriate warnings. - - The configuration of the TOE may allow different user - roles to have dissimilar privileges in making use of the - different functions of the TOE. This means that some - users are authorised to perform certain functions, while - other users may not be so authorised. These functions - and privileges should be described, for each user role, - by the user guidance. - - The user guidance identifies, for each user role, the - functions and privileges that must be controlled, the - types of commands required for them, and the reasons for - such commands. The user guidance should contain warnings - regarding the use of these functions and - privileges. Warnings should address expected effects, - possible side effects, and possible interactions with - other functions and privileges. - - - - - The evaluator shall examine the operational user - guidance to determine that it describes, for each user - role, the secure use of the available interfaces - provided by the TOE. - - The user guidance should provide advice regarding - effective use of the TSF (e.g. reviewing password - composition practises, suggested frequency of user file - backups, discussion on the effects of changing user - access privileges). - - - - - The evaluator shall examine the operational user - guidance to determine that it describes, for each user - role, the available security functionality and - interfaces, in particular all security parameters under - the control of the user, indicating secure values as - appropriate. - - The user guidance should contain an overview of the - security functionality that is visible at the user - interfaces. - - The user guidance should identify and describe the - purpose, behaviour, and interrelationships of the - security interfaces and functionality. - - For each user-accessible interface, the user guidance - should: - - - describe the method(s) by which the interface is - invoked (e.g. command-line, programming-language - system call, menu selection, command button); - - - describe the parameters to be set by the user, their - particular purposes, valid and default values, and - secure and insecure use settings of such parameters, - both individually or in combination; - - - describe the immediate TSF response, message, or - code returned. - - - - The evaluator should consider the functional - specification and the ST to determine that the TSF - described in these documents is consistent to the - operational user guidance. The evaluator has to ensure - that the operational user guidance is complete to allow - the secure use through the TSFI available to all types - of human users. The evaluator may, as an aid, prepare an - informal mapping between the guidance and these - documents. Any omissions in this mapping may indicate - incompleteness. - - - - - The evaluator shall examine the operational user - guidance to determine that it describes, for each user - role, each type of security-relevant event relative to - the user functions that need to be performed, including - changing the security characteristics of entities under - the control of the TSF and operation following failure - or operational error. - - All types of security-relevant events are detailed for - each user role, such that each user knows what events - may occur and what action (if any) he may have to take - in order to maintain security. Security-relevant events - that may occur during operation of the TOE (e.g. audit - trail overflow, system crash, updates to user records, - such as when a user account is removed when the user - leaves the organisation) are adequately defined to allow - user intervention to maintain secure operation. - - - - - The evaluator shall examine the operational user - guidance and other evaluation evidence to determine that - the guidance identifies all possible modes of operation - of the TOE (including, if applicable, operation - following failure or operational error), their - consequences and implications for maintaining secure - operation. - - Other evaluation evidence, particularly the functional - specification, provide an information source that the - evaluator should use to determine that the guidance - contains sufficient guidance information. - - If test documentation is included in the assurance - package, then the information provided in this evidence - can also be used to determine that the guidance contains - sufficient guidance documentation. The detail provided - in the test steps can be used to confirm that the - guidance provided is sufficient for the use and - administration of the TOE. - - The evaluator should focus on a single human visible - TSFI at a time, comparing the guidance for securely - using the TSFI with other evaluation evidence, to - determine that the guidance related to the TSFI is - sufficient for the secure usage (i.e. consistent with - the SFRs) of that TSFI. The evaluator should also - consider the relationships between interfaces, searching - for potential conflicts. - - - - - The evaluator shall examine the operational user - guidance to determine that it describes, for each user - role, the security measures to be followed in order to - fulfil the security objectives for the operational - environment as described in the ST. - - The evaluator analyses the security objectives for the - operational environment in the ST and determines that - for each user role, the relevant security measures are - described appropriately in the user guidance. - - The security measures described in the user guidance - should include all relevant external procedural, - physical, personnel and connectivity measures. - - Note that those measures relevant for secure - installation of the TOE are examined in . - - - - - The evaluator shall examine the operational user - guidance to determine that it is clear. - - The guidance is unclear if it can reasonably be - misconstrued by an administrator or user, and used in a - way detrimental to the TOE, or to the security provided - by the TOE. - - - - - The evaluator shall examine the operational user - guidance to determine that it is reasonable. - - The guidance is unreasonable if it makes demands on the - TOE's usage or operational environment that are - inconsistent with the ST or unduly onerous to maintain - security. - - - - - - - - Preparative procedures are useful for ensuring that the TOE - has been received and installed in a secure manner as - intended by the developer. The requirements for preparation - call for a secure transition from the delivered TOE to its - initial operational environment. This includes investigating - whether the TOE can be configured or installed in a manner - that is insecure but that the user of the TOE would - reasonably believe to be secure. - - - - Preparation requires that the delivered copy of the TOE is - accepted, configured and activated by the user to exhibit - the protection properties as needed during operation of the - TOE. The preparative procedures provide confidence that the - user will be aware of the TOE configuration parameters and - how they can affect the TSF. - - - - This family contains only one component. - - - - It is recognised that the application of these requirements - will vary depending on aspects such as whether the TOE is - delivered in an operational state, or whether it has to be - installed at the TOE owner's site, etc. - - The first process covered by the preparative procedures is - the consumer's secure acceptance of the received TOE in - accordance with the developer's delivery procedures. If the - developer has not defined delivery procedures, security of - the acceptance has to be ensured otherwise. - - Installation of the TOE includes transforming its - operational environment into a state that conforms to the - security objectives for the operational environment provided - in the ST. - - It might also be the case that no installation is necessary, - for example a smart card. In this case it may be - inappropriate to require and analyse installation - procedures. - - The requirements in this assurance family are presented - separately from those in the family, due to the infrequent, possibly - one-time use of the preparative procedures. - - - - - The objective of this sub-activity is to determine whether - the procedures and steps for the secure preparation of the - TOE have been documented and result in a secure - configuration. - - - - The preparative procedures refer to all acceptance and - installation procedures, that are necessary to progress - the TOE to the secure configuration as described in the - ST. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the TOE including its preparative procedures; - - - the description of developer's delivery procedures, if - applicable; - - - - - The developer shall provide the TOE including its - preparative procedures. - - The preparative procedures - shall describe all the steps necessary for secure acceptance - of the delivered TOE in accordance with the developer's - delivery procedures. - - The preparative procedures - shall describe all the steps necessary for secure - installation of the TOE and for the secure preparation of - the operational environment in accordance with the security - objectives for the operational environment as described in - the ST. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - - The evaluator shall examine the provided acceptance - procedures to determine that they describe the steps - necessary for secure acceptance of the TOE in accordance - with the developer's delivery procedures. - If it is not anticipated by the developer's delivery - procedures that acceptance procedures will or can be - applied, this work unit is not applicable, and is - therefore considered to be satisfied. - - The acceptance procedures should include as a minimum, - that the user has to check that all parts of the TOE as - indicated in the ST have been delivered in the correct - version. - - The acceptance procedures should reflect the steps the - user has to perform in order to accept the delivered TOE - that are implied by the developer's delivery - procedures. - - The acceptance procedures should provide detailed - information about the following, if applicable: - - - making sure that the delivered TOE is the complete - evaluated instance; - - - detecting modification/masquerading of the delivered - TOE. - - - - - - - - The evaluator shall examine the provided installation - procedures to determine that they describe the steps - necessary for secure installation of the TOE and the - secure preparation of the operational environment in - accordance with the security objectives in the - ST. - - If it is not anticipated that installation procedures - will or can be applied (e.g. because the TOE may already - be delivered in an operational state), this work unit is - not applicable, and is therefore considered to be - satisfied. - - The installation procedures should provide detailed - information about the following, if applicable: - - - minimum system requirements for secure installation; - - - requirements for the operational environment in - accordance with the security objectives provided by - the ST; - - the steps the user has to perform in order to get to an - operational TOE being commensurate with its evaluated - configuration. Such a description shall include - for each step - - a clear scheme for the decision on the next step depended on - success, failure or problems at the current step; - - - changing the installation specific security - characteristics of entities under the control of the - TSF (for example parameters, settings, passwords); - - - handling exceptions and problems. - - - - - - The evaluator shall apply the preparative procedures to - confirm that the TOE can be prepared securely for operation. - - - The evaluator shall perform all user procedures - necessary to prepare the TOE to determine that the TOE - and its operational environment can be prepared securely - using only the supplied preparative procedures. - Preparation requires the evaluator to advance the - TOE from a deliverable state to the state in which it is - operational, including acceptance and installation of - the TOE, and enforcing the SFRs consistent with the - security objectives for the TOE specified in the - ST. - - The evaluator should follow only the developer's - procedures and may perform the activities that customers - are usually expected to perform to accept and install - the TOE, using the supplied preparative procedures only. - Any difficulties encountered during such an exercise may - be indicative of incomplete, unclear or unreasonable guidance. - - This work unit may be performed in conjunction with the - evaluation activities under . - - If it is known that the TOE will be used as a dependent - component for a composed TOE evaluation, then the - evaluator should ensure that the operational environment - is satisfied by the base component used in the composed - TOE. - - - - - - - - - Life-cycle support is an aspect of establishing discipline and - control in the processes of refinement of the TOE during its - development and maintenance. Confidence in the correspondence - between the TOE security requirements and the TOE is greater - if security analysis and the production of the evidence are - done on a regular basis as an integral part of the development - and maintenance activities. - - In the product life-cycle it is distinguished whether the TOE - is under the responsibility of the developer or the user - rather than whether it is located in the development or user - environment. The point of transition is the moment where the - TOE is handed over to the user. This is also the point of - transition from the to the class. - - The class consists of seven - families. is the high-level - description of the TOE life-cycle; a more detailed description of the management - of the configuration items. - requires a minimum set of configuration items to be managed in - the defined way. is - concerned with the developer's physical, procedural, - personnel, and other security measures; with the development tools and implementation - standards used by the developer; with the handling of security flaws. defines the procedures used for - the delivery of the TOE to the consumer. Delivery processes - occurring during the development of the TOE are denoted rather - as transportations, and are handled in the context of - integration and acceptance procedures in other families of - this class. - - Throughout this class, development and related terms - (developer, develop) are meant in the more general sense to - comprise development and production, whereas - production specifically means the process of transforming the - implementation representation into the final TOE. - - - - Assurance class defines - requirements for assurance through the adoption of a well - defined life-cycle model for all the steps of the TOE - development, including flaw remediation procedures and - policies, correct use of tools and techniques and the security - measures used to protect the development environment. - - Configuration management (CM) helps to ensure that the - integrity of the TOE is preserved, by preventing unauthorised - modifications, additions, or deletions to the TOE, thus - providing assurance that the TOE and documentation used for - evaluation are the ones prepared for distribution. - - The delivery procedures define requirements for the measures, - procedures, and standards concerned with secure delivery of - the TOE, ensuring that the security protection offered by the - TOE is not compromised during the transfer to the user. - - - - The purpose of the life-cycle support activity is to determine - the adequacy of the security procedures that the developer - uses during the development and maintenance of the TOE. These - procedures include the life-cycle model used by the developer, - the configuration management, the security measures used - throughout TOE development, the tools used by the developer - throughout the life-cycle of the TOE, the handling of security - flaws, and the delivery activity. - - Poorly controlled development and maintenance of the TOE can - result in vulnerabilities in the implementation. Conformance - to a defined life-cycle model can help to improve controls in - this area. A measurable life-cycle model used for the TOE can - remove ambiguity in assessing the development progress of the - TOE. - - The purpose of the configuration management activity is to - assist the consumer in identifying the evaluated TOE, to - ensure that configuration items are uniquely identified, and - the adequacy of the procedures that are used by the developer - to control and track changes that are made to the TOE. This - includes details on what changes are tracked, how potential - changes are incorporated, and the degree to which automation - is used to reduce the scope for error. - - Developer security procedures are intended to protect the TOE - and its associated design information from interference or - disclosure. Interference in the development process may allow - the deliberate introduction of vulnerabilities. Disclosure of - design information may allow vulnerabilities to be more easily - exploited. The adequacy of the procedures will depend on the - nature of the TOE and the development process. - - The use of well-defined development tools and the application - of implementation standards by the developer and by third - parties involved in the development process help to ensure - that vulnerabilities are not inadvertently introduced during - refinement. - - The flaw remediation activity is intended to track security - flaws, to identify corrective actions, and to distribute the - corrective action information to TOE users. - - The purpose of the delivery activity is to judge the adequacy - of the documentation of the procedures used to ensure that the - TOE is delivered to the consumer without modification. - - - - - Configuration management (CM) is one means for increasing - assurance that the TOE meets the SFRs. CM establishes this - by requiring discipline and control in the processes of - refinement and modification of the TOE and the related - information. CM systems are put in place to ensure the - integrity of the portions of the TOE that they control, by - providing a method of tracking any changes, and by ensuring - that all changes are authorised. - - The objective of this family is to require the developer's - CM system to have certain capabilities. These are meant to - reduce the likelihood that accidental or unauthorised - modifications of the configuration items will occur. The CM - system should ensure the integrity of the TOE from the early - design stages through all subsequent maintenance - efforts. - - The objective of introducing automated CM tools is to - increase the effectiveness of the CM system. While both - automated and manual CM systems can be bypassed, ignored, or - proven insufficient to prevent unauthorised modification, - automated systems are less susceptible to human error or - negligence. - - The objectives of this family include the following: - - - ensuring that the TOE is correct and complete before it - is sent to the consumer; - - - ensuring that no configuration items are missed during - evaluation; - - - preventing unauthorised modification, addition, or - deletion of TOE configuration items. - - - - - - Configuration management capabilities define the - characteristics of the configuration management - system. - - - - The components in this family are levelled on the basis of - the CM system capabilities, the scope of the CM - documentation and the evidence provided by the - developer. - - - - While it is desired that CM be applied from the early design - stages and continue into the future, this family requires - that CM be in place and in use prior to the end of the - evaluation. - - In the case where the TOE is a subset of a product, the - requirements of this family apply only to the TOE - configuration items, not to the product as a whole. - - For developers that have separate CM systems for different - life-cycle phases (for example development, production - and/or the final product), it is required to document all of - them. For evaluation purposes, the separate CM systems - should be regarded as parts of an overall CM system which is - addressed in the criteria. - - Similarly, if parts of the TOE are produced by different - developers or at different sites, the CM systems being in - use at the different places should be regarded as parts of - an overall CM system which is addressed in the criteria. In - this situation, integration aspects have also to be taken - into account. - - Several elements of this family refer to configuration - items. These elements identify CM requirements to be imposed - on all items identified in the configuration list, but leave - the contents of the list to the discretion of the - developer. can be used to - narrow this discretion by identifying specific items that - must be included in the configuration list, and hence - covered by CM. - - introduces a - requirement that the CM system uniquely identify all - configuration items. This also requires that modifications - to configuration items result in a new, unique identifier - being assigned to the configuration item. - - introduces the - requirement that the evidence shall demonstrate that the CM - system operates in accordance with the CM plan. Examples of - such evidence might be documentation such as screen - snapshots or audit trail output from the CM system, or a - detailed demonstration of the CM system by the - developer. The evaluator is responsible for determining that - this evidence is sufficient to show that the CM system - operates in accordance with the CM plan. - - introduces a - requirement that the CM system provide an automated means to - support the production of the TOE. This requires that the CM - system provide an automated means to assist in determining - that the correct configuration items are used in generating - the TOE. - - introduces a - requirement that the CM system provide an automated means to - ascertain the changes between the TOE and its preceding - version. If no previous version of the TOE exists, the - developer still needs to provide an automated means to - ascertain the changes between the TOE and a future version - of the TOE. - - - - - - A unique reference is required to ensure that there is no - ambiguity in terms of which instance of the TOE is being - evaluated. Labelling the TOE with its reference ensures - that users of the TOE can be aware of which instance of - the TOE they are using. - - - - The objectives of this sub-activity are to determine - whether the developer has clearly identified the - TOE. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the TOE suitable for testing. - - - - - The developer shall provide the TOE and a reference for the - TOE. - - - The TOE shall be labelled with its unique reference. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the TOE provided for - evaluation is labelled with its reference. - - The evaluator should ensure that the TOE contains the - unique reference which is stated in the ST. This could - be achieved through labelled packaging or media, or by a - label displayed by the operational TOE. This is to - ensure that it would be possible for consumers to - identify the TOE (e.g. at the point of purchase or - use). - - The TOE may provide a method by which it can be easily - identified. For example, a software TOE may display its - name and version number during the start up routine, or - in response to a command line entry. A hardware or - firmware TOE may be identified by a part number - physically stamped on the TOE. - - Alternatively, the unique reference provided for the TOE - may be the combination of the unique reference of each - component from which the TOE is comprised (e.g. in the - case of a composed TOE). - - - - The evaluator shall check that the TOE references used - are consistent. - - If the TOE is labelled more than once then the labels - have to be consistent. For example, it should be - possible to relate any labelled guidance documentation - supplied as part of the TOE to the evaluated operational - TOE. This ensures that consumers can be confident that - they have purchased the evaluated version of the TOE, - that they have installed this version, and that they - have the correct version of the guidance to operate the - TOE in accordance with its ST. - - The evaluator also verifies that the TOE reference is - consistent with the ST. - - If this work unit is applied to a composed TOE, the - following will apply. The composed IT TOE will not be - labelled with its unique (composite) reference, but only - the individual components will be labelled with their - appropriate TOE reference. It would require further - development for the IT TOE to be labelled, i.e. during - start-up and/or operation, with the composite reference. - If the composed TOE is delivered as the constituent - component TOEs, then the TOE items delivered will not - contain the composite reference. However, the composed - TOE ST will include the unique reference for the - composed TOE and will identify the components comprising - the composed TOE through which the consumers will be - able to determine whether they have the appropriate - items. - - - - - - - - - A unique reference is required to ensure that there is no - ambiguity in terms of which instance of the TOE is being - evaluated. Labelling the TOE with its reference ensures - that users of the TOE can be aware of which instance of - the TOE they are using. - - Unique identification of the configuration items leads to - a clearer understanding of the composition of the TOE, - which in turn helps to determine those items which are - subject to the evaluation requirements for the TOE. - - The use of a CM system increases assurance that the - configuration items are maintained in a controlled - manner. - - - - The objectives of this sub-activity are to determine - whether the developer uses a CM system that uniquely - identifies all configuration items. - - - - This component contains an implicit evaluator action to - determine that the CM system is being used. As the - requirements here are limited to identification of the TOE - and provision of a configuration list, this action is - already covered by, and limited to, the existing work - units. At the - requirements are expanded beyond these two items, and more - explicit evidence of operation is required. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the TOE suitable for testing; - - - the configuration management documentation. - - - - - The developer shall provide the TOE and a reference for the - TOE. - - - The developer shall provide the CM documentation. - - - The developer shall use a CM system. - - - The TOE shall be labelled with its unique reference. - - - The CM documentation shall describe the method used to - uniquely identify the configuration items. - - - The CM system shall uniquely identify all configuration - items. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the TOE provided for - evaluation is labelled with its reference. - - The evaluator should ensure that the TOE contains the - unique reference which is stated in the ST. This could - be achieved through labelled packaging or media, or by a - label displayed by the operational TOE. This is to - ensure that it would be possible for consumers to - identify the TOE (e.g. at the point of purchase or - use). - - The TOE may provide a method by which it can be easily - identified. For example, a software TOE may display its - name and version number during the start up routine, or - in response to a command line entry. A hardware or - firmware TOE may be identified by a part number - physically stamped on the TOE. - - Alternatively, the unique reference provided for the TOE - may be the combination of the unique reference of each - component from which the TOE is comprised (e.g. in the - case of a composed TOE). - - - - The evaluator shall check that the TOE references used - are consistent. - - If the TOE is labelled more than once then the labels - have to be consistent. For example, it should be - possible to relate any labelled guidance documentation - supplied as part of the TOE to the evaluated operational - TOE. This ensures that consumers can be confident that - they have purchased the evaluated version of the TOE, - that they have installed this version, and that they - have the correct version of the guidance to operate the - TOE in accordance with its ST. - - The evaluator also verifies that the TOE reference is - consistent with the ST. - - If this work unit is applied to a composed TOE, the - following will apply. The composed IT TOE will not be - labelled with its unique (composite) reference, but only - the individual components will be labelled with their - appropriate TOE reference. It would require further - development for the IT TOE to be labelled, i.e. during - start-up and/or operation, with the composite reference. - If the composed TOE is delivered as the constituent - component TOEs, then the TOE items delivered will not - contain the composite reference. However, the composed - TOE ST will include the unique reference for the - composed TOE and will identify the components comprising - the composed TOE through which the consumers will be - able to determine whether they have the appropriate - items. - - - - - The evaluator shall examine the method of identifying - configuration items to determine that it describes how - configuration items are uniquely identified. - - Procedures should describe how the status of each - configuration item can be tracked throughout the - life-cycle of the TOE. The procedures may be detailed in - the CM plan or throughout the CM documentation. The - information included should describe: - - - the method how each configuration item is uniquely - identified, such that it is possible to track - versions of the same configuration item; - - the method how configuration items are assigned - unique identifiers and how they are entered into the - CM system; - - the method to be used to identify superseded - versions of a configuration item. - - - - - - The evaluator shall examine the configuration items to - determine that they are identified in a way that is - consistent with the CM documentation. - Assurance that the CM system uniquely identifies - all configuration items is gained by examining the - identifiers for the configuration items. For both - configuration items that comprise the TOE, and drafts of - configuration items that are submitted by the developer - as evaluation evidence, the evaluator confirms that each - configuration item possesses a unique identifier in a - manner consistent with the unique identification method - that is described in the CM documentation. - - - - - - - - - - A unique reference is required to ensure that there is no - ambiguity in terms of which instance of the TOE is being - evaluated. Labelling the TOE with its reference ensures - that users of the TOE can be aware of which instance of - the TOE they are using. - - Unique identification of the configuration items leads to - a clearer understanding of the composition of the TOE, - which in turn helps to determine those items which are - subject to the evaluation requirements for the TOE. - - The use of a CM system increases assurance that the - configuration items are maintained in a controlled - manner. - - Providing controls to ensure that unauthorised - modifications are not made to the TOE (``CM access - control''), and ensuring proper functionality and use of - the CM system, helps to maintain the integrity of the - TOE. - - - - The objectives of this sub-activity are to determine - whether the developer uses a CM system that uniquely - identifies all configuration items, and whether the - ability to modify these items is properly - controlled. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the TOE suitable for testing; - - - the configuration management documentation. - - - - - The developer shall provide the TOE and a reference for the - TOE. - - - The developer shall provide the CM documentation. - - - The developer shall use a CM system. - - - The TOE shall be labelled with its unique reference. - - - The CM documentation shall describe the method used to - uniquely identify the configuration items. - - - The CM system shall uniquely identify all configuration - items. - - - The CM system shall provide measures such that only - authorised changes are made to the configuration items. - - - The CM documentation shall include a CM plan. - - - The CM plan shall describe how the CM system is used for the - development of the TOE. - - - The evidence shall demonstrate that all configuration items - are being maintained under the CM system. - - - The evidence shall demonstrate that the CM system is being - operated in accordance with the CM plan. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the TOE provided for - evaluation is labelled with its reference. - - The evaluator should ensure that the TOE contains the - unique reference which is stated in the ST. This could - be achieved through labelled packaging or media, or by a - label displayed by the operational TOE. This is to - ensure that it would be possible for consumers to - identify the TOE (e.g. at the point of purchase or - use). - - The TOE may provide a method by which it can be easily - identified. For example, a software TOE may display its - name and version number during the start up routine, or - in response to a command line entry. A hardware or - firmware TOE may be identified by a part number - physically stamped on the TOE. - - Alternatively, the unique reference provided for the TOE - may be the combination of the unique reference of each - component from which the TOE is comprised (e.g. in the - case of a composed TOE). - - - - The evaluator shall check that the TOE references used - are consistent. - - If the TOE is labelled more than once then the labels - have to be consistent. For example, it should be - possible to relate any labelled guidance documentation - supplied as part of the TOE to the evaluated operational - TOE. This ensures that consumers can be confident that - they have purchased the evaluated version of the TOE, - that they have installed this version, and that they - have the correct version of the guidance to operate the - TOE in accordance with its ST. - - The evaluator also verifies that the TOE reference is - consistent with the ST. - - If this work unit is applied to a composed TOE, the - following will apply. The composed IT TOE will not be - labelled with its unique (composite) reference, but only - the individual components will be labelled with their - appropriate TOE reference. It would require further - development for the IT TOE to be labelled, i.e. during - start-up and/or operation, with the composite reference. - If the composed TOE is delivered as the constituent - component TOEs, then the TOE items delivered will not - contain the composite reference. However, the composed - TOE ST will include the unique reference for the - composed TOE and will identify the components comprising - the composed TOE through which the consumers will be - able to determine whether they have the appropriate - items. - - - - - The evaluator shall examine the method of identifying - configuration items to determine that it describes how - configuration items are uniquely identified. - - Procedures should describe how the status of each - configuration item can be tracked throughout the - life-cycle of the TOE. The procedures may be detailed in - the CM plan or throughout the CM documentation. The - information included should describe: - - - the method how each configuration item is uniquely - identified, such that it is possible to track - versions of the same configuration item; - - the method how configuration items are assigned - unique identifiers and how they are entered into the - CM system; - - the method to be used to identify superseded - versions of a configuration item. - - - - - - The evaluator shall examine the configuration items to - determine that they are identified in a way that is - consistent with the CM documentation. - - Assurance that the CM system uniquely identifies all - configuration items is gained by examining the - identifiers for the configuration items. For both - configuration items that comprise the TOE, and drafts of - configuration items that are submitted by the developer - as evaluation evidence, the evaluator confirms that each - configuration item possesses a unique identifier in a - manner consistent with the unique identification method - that is described in the CM documentation. - - - - - The evaluator shall examine the CM access control - measures described in the CM plan to determine that they - are effective in preventing unauthorised access to the - configuration items. - - The evaluator may use a number of methods to determine - that the CM access control measures are effective. For - example, the evaluator may exercise the access control - measures to ensure that the procedures could not be - bypassed. The evaluator may use the outputs generated by - the CM system procedures required by . The evaluator may also witness a - demonstration of the CM system to ensure that the access - control measures employed are operating - effectively. - - - - - The evaluator shall check that the CM documentation - provided includes a CM plan. - The CM plan needs not to be a connected document, but it is - recommended that there is a single document that describes where - the various parts of the CM plan can be found. If the CM plan is - no single document, the list in the following work unit gives - hints regarding which context is expected. - - - - - The evaluator shall examine the CM plan to determine - that it describes how the CM system is used for the - development of the TOE. - - The descriptions contained in a CM plan include, if - applicable: - - - all activities performed in the TOE development that - are subject to configuration management procedures - (e.g. creation, modification or deletion of a - configuration item, data-backup, archiving); - - - which means (e.g. CM tools, forms) have to be made - available; - - - the usage of the CM tools: the necessary details for - a user of the CM system to be able to operate the CM - tools correctly in order to maintain the integrity - of the TOE; - - - which other objects (development components, tools, - assessment environments, etc) are taken under CM - control; - - - the roles and responsibilities of individuals - required to perform operations on individual - configuration items (different roles may be - identified for different types of configuration - items (e.g. design documentation or source code)); - - - how CM instances (e.g. change control boards, - interface control working groups) are introduced and - staffed; - - - the description of the change management; - - - the procedures that are used to ensure that only - authorised individuals can make changes to - configuration items; - - - the procedures that are used to ensure that - concurrency problems do not occur as a result of - simultaneous changes to configuration items; - - - the evidence that is generated as a result of - application of the procedures. For example, for a - change to a configuration item, the CM system might - record a description of the change, accountability - for the change, identification of all configuration - items affected, status (e.g. pending or completed), - and date and time of the change. This might be - recorded in an audit trail of changes made or change - control records; - - - the approach to version control and unique - referencing of TOE versions (e.g. covering the - release of patches in operating systems, and the - subsequent detection of their application). - - - - - - - The evaluator shall check that the configuration items - identified in the configuration list are being - maintained by the CM system. - - The CM system employed by the developer should maintain the - integrity of the TOE. The evaluator should check that for each - type of configuration item (e.g. design documents or source code - modules) contained in the configuration list there are examples - of the evidence generated by the procedures described in the CM - plan. In this case, the approach to sampling will depend upon - the level of granularity used in the CM system to control CM - items. Where, for example, 10,000 source code modules are - identified in the configuration list, a different sampling - strategy needs to be applied compared to the case in which there - are only 5, or even 1. The emphasis of this activity should be - on ensuring that the CM system is being operated correctly, - rather than on the detection of any minor error. - - For guidance on sampling see . - - - - - The evaluator shall check the CM documentation to - ascertain that it includes the CM system records - identified by the CM plan. - - The output produced by the CM system should provide the - evidence that the evaluator needs to be confident that - the CM plan is being applied, and also that all - configuration items are being maintained by the CM - system as required by . Example output could include change - control forms, or configuration item access approval - forms. - - - - - The evaluator shall examine the evidence to determine - that the CM system is being operated in accordance with - the CM plan. - - The evaluator should select and examine a sample of - evidence covering each type of CM-relevant operation - that has been performed on a configuration item - (e.g. creation, modification, deletion, reversion to an - earlier version) to confirm that all operations of the - CM system have been carried out in line with documented - procedures. The evaluator confirms that the evidence - includes all the information identified for that - operation in the CM plan. Examination of the evidence - may require access to a CM tool that is used. The - evaluator may choose to sample the evidence. - - For guidance on sampling see . - - Further confidence in the correct operation of the CM system and - the effective maintenance of configuration items may be - established by means of interviews with selected development - staff. In conducting such interviews, the evaluator aims - to gain a deeper understanding of how the CM system is used in - practise as well as to confirm that the CM procedures are being - applied as described in the CM documentation. Note that such - interviews should complement rather than replace the examination - of documentary evidence, and may not be necessary if the - documentary evidence alone satisfies the requirement. However, - given the wide scope of the CM plan it is possible that some - aspects (e.g. roles and responsibilities) may not be clear from - the CM plan and records alone. This is one case where - clarification may be necessary through interviews. - - It is expected that the evaluator will visit the - development site in support of this activity. - - For guidance on site visits see . - - - - - - - - - - - A unique reference is required to ensure that there is no - ambiguity in terms of which instance of the TOE is being - evaluated. Labelling the TOE with its reference ensures - that users of the TOE can be aware of which instance of - the TOE they are using. - - Unique identification of the configuration items leads to - a clearer understanding of the composition of the TOE, - which in turn helps to determine those items which are - subject to the evaluation requirements for the TOE. - - The use of a CM system increases assurance that the - configuration items are maintained in a controlled - manner. - - Providing controls to ensure that unauthorised - modifications are not made to the TOE (``CM access - control''), and ensuring proper functionality and use of - the CM system, helps to maintain the integrity of the - TOE. - - The purpose of the acceptance procedures is to ensure that - the parts of the TOE are of adequate quality and to - confirm that any creation or modification of configuration - items is authorised. Acceptance procedures are an - essential element in integration processes and in the - life-cycle management of the TOE. - - In development environments where the configuration items - are complex, it is difficult to control changes without - the support of automated tools. In particular, these - automated tools need to be able to support the numerous - changes that occur during development and ensure that - those changes are authorised. It is an objective of this - component to ensure that the configuration items are - controlled through automated means. If the TOE is - developed by multiple developers, i.e. integration has to - take place, the use of automatic tools is adequate. - - Production support procedures help to ensure that the - generation of the TOE from a managed set of configuration - items is correctly performed in an authorised manner, - particularly in the case when different developers are - involved and integration processes have to be carried - out. - - - - The objectives of this sub-activity are to determine - whether the developer has clearly identified the TOE and - its associated configuration items, and whether the - ability to modify these items is properly controlled by - automated tools, thus making the CM system less - susceptible to human error or negligence. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the TOE suitable for testing; - - - the configuration management documentation. - - - - - The developer shall provide the TOE and a reference for the - TOE. - - - The developer shall provide the CM documentation. - - - The developer shall use a CM system. - - - The TOE shall be labelled with its unique reference. - - - The CM documentation shall describe the method used to - uniquely identify the configuration items. - - - The CM system shall uniquely identify all configuration - items. - - - The CM system shall provide automated measures such that - only authorised changes are made to the configuration items. - - - The CM system shall support the production of the TOE by - automated means. - - - The CM documentation shall include a CM plan. - - - The CM plan shall describe how the CM system is used for the - development of the TOE. - - - The CM plan shall describe the procedures used to accept - modified or newly created configuration items as part of the - TOE. - - - The evidence shall demonstrate that all configuration items - are being maintained under the CM system. - - - The evidence shall demonstrate that the CM system is being - operated in accordance with the CM plan. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the TOE provided for - evaluation is labelled with its reference. - - The evaluator should ensure that the TOE contains the - unique reference which is stated in the ST. This could - be achieved through labelled packaging or media, or by a - label displayed by the operational TOE. This is to - ensure that it would be possible for consumers to - identify the TOE (e.g. at the point of purchase or - use). - - The TOE may provide a method by which it can be easily - identified. For example, a software TOE may display its - name and version number during the start up routine, or - in response to a command line entry. A hardware or - firmware TOE may be identified by a part number - physically stamped on the TOE. - - Alternatively, the unique reference provided for the TOE - may be the combination of the unique reference of each - component from which the TOE is comprised (e.g. in the - case of a composed TOE). - - - - The evaluator shall check that the TOE references used - are consistent. - - If the TOE is labelled more than once then the labels - have to be consistent. For example, it should be - possible to relate any labelled guidance documentation - supplied as part of the TOE to the evaluated operational - TOE. This ensures that consumers can be confident that - they have purchased the evaluated version of the TOE, - that they have installed this version, and that they - have the correct version of the guidance to operate the - TOE in accordance with its ST. - - The evaluator also verifies that the TOE reference is - consistent with the ST. - - If this work unit is applied to a composed TOE, the - following will apply. The composed TOE will not be - labelled with its unique (composite) reference, but only - the individual components will be labelled with their - appropriate TOE reference. It would require further - development for the composed TOE to be labelled, i.e. during - start-up and/or operation, with the composite reference. - If the composed TOE is delivered as the constituent - component TOEs, then the TOE items delivered will not - contain the composite reference. However, the composed - TOE ST will include the unique reference for the - composed TOE and will identify the components comprising - the composed TOE through which the consumers will be - able to determine whether they have the appropriate items. - - - - - The evaluator shall examine the method of identifying - configuration items to determine that it describes how - configuration items are uniquely identified. - - Procedures should describe how the status of each - configuration item can be tracked throughout the - life-cycle of the TOE. The procedures may be detailed in - the CM plan or throughout the CM documentation. The - information included should describe: - - - the method how each configuration item is uniquely - identified, such that it is possible to track - versions of the same configuration item; - - the method how configuration items are assigned - unique identifiers and how they are entered into the - CM system; - - the method to be used to identify superseded - versions of a configuration item. - - - - - - The evaluator shall examine the configuration items to - determine that they are identified in a way that is - consistent with the CM documentation. - - Assurance that the CM system uniquely identifies all - configuration items is gained by examining the - identifiers for the configuration items. For configuration - items identified under , - the evaluator confirms that each configuration item possesses - a unique identifier in a manner consistent with the unique - identification method that is described in the CM documentation. - - - - - The evaluator shall examine the CM access control - measures described in the CM plan (cf. ) to determine that they - are automated and effective in preventing unauthorised - access to the configuration items. - - The evaluator may use a number of methods to determine - that the CM access control measures are effective. For - example, the evaluator may exercise the access control - measures to ensure that the procedures could not be - bypassed. The evaluator may use the outputs generated by - the CM system procedures required by . The evaluator may also witness a - demonstration of the CM system to ensure that the access - control measures employed are operating - effectively. - - - - - The evaluator shall check the CM plan (cf. ) for automated - procedures for supporting the production of the - TOE. - - The term ``production'' applies to those processes - adopted by the developer to progress the TOE from the - implementation representation to a state acceptable for - delivery to the end customer. - - The evaluator verifies the existence of automated - production support procedures within the CM plan. - - The following are examples for automated means - supporting the production of the TOE: - - - a ``make'' tool (as provided with many software - development tools) in the case of a software TOE; - - - a tool ensuring automatically (for example by means - of bar codes) that only parts are combined which - indeed belong together in the case of a hardware - TOE. - - - - - - - The evaluator shall examine the TOE production support - procedures to determine that they are effective in - ensuring that a TOE is generated that reflects its - implementation representation. - - The production support procedures should describe which - tools have to be used to produce the final TOE from the - implementation representation in a clearly defined - way. The conventions, directives, or other necessary - constructs are described under . - - The evaluator determines that by following the - production support procedures the correct configuration - items would be used to generate the TOE. For example, in - a software TOE this may include checking that the - automated production procedures ensure that all source - files and related libraries are included in the compiled - object code. Moreover, the procedures should ensure that - compiler options and comparable other options are - defined uniquely. For a hardware TOE, this work unit may - include checking that the automatic production - procedures ensure that the belonging parts are built - together and no parts are missing. - - The customer can then be confident that the version of - the TOE delivered for installation is derived from the - implementation representation in an unambiguous way and - implements the SFRs as described in the ST. - - The evaluator should bear in mind that the CM system - need not necessarily possess the capability to produce - the TOE, but should provide support for the process that - will help reduce the probability of human error. - - - - - The evaluator shall check that the CM documentation - provided includes a CM plan. - The CM plan does not need to be contained within a single - document, but it is recommended that there is a separate - document that describes where the various parts of the CM plan - can be found. If the CM plan is provided by a set of documents, - the list in the following work unit gives guidance regarding the - required content. - - - - - The evaluator shall examine the CM plan to determine - that it describes how the CM system is used for the - development of the TOE. - - The descriptions contained in a CM plan include, if - applicable: - - - all activities performed in the TOE development that - are subject to configuration management procedures - (e.g. creation, modification or deletion of a - configuration item, data-backup, archiving); - - - which means (e.g. CM tools, forms) have to be made - available; - - - the usage of the CM tools: the necessary details for - a user of the CM system to be able to operate the CM - tools correctly in order to maintain the integrity - of the TOE; - - - the production support procedures; - - - which other objects (development components, tools, - assessment environments, etc) are taken under CM - control; - - - the roles and responsibilities of individuals - required to perform operations on individual - configuration items (different roles may be - identified for different types of configuration - items (e.g. design documentation or source code)); - - - how CM instances (e.g. change control boards, - interface control working groups) are introduced and - staffed; - - - the description of the change management; - - - the procedures that are used to ensure that only - authorised individuals can make changes to - configuration items; - - - the procedures that are used to ensure that - concurrency problems do not occur as a result of - simultaneous changes to configuration items; - - - the evidence that is generated as a result of - application of the procedures. For example, for a - change to a configuration item, the CM system might - record a description of the change, accountability - for the change, identification of all configuration - items affected, status (e.g. pending or completed), - and date and time of the change. This might be - recorded in an audit trail of changes made or change - control records; - - - the approach to version control and unique - referencing of TOE versions (e.g. covering the - release of patches in operating systems, and the - subsequent detection of their application). - - - - - - - The evaluator shall examine the CM plan to determine - that it describes the procedures used to accept modified - or newly created configuration items as parts of the - TOE. - - The descriptions of the acceptance procedures in the CM - plan should include the developer roles or individuals - responsible for the acceptance and the criteria to be - used for acceptance. They should take into account all - acceptance situations that may occur, in particular: - - - accepting an item into the CM system for the first - time, in particular inclusion of software, firmware - and hardware components from other manufacturers - into the TOE (``integration''); - - - moving configuration items to the next life-cycle - phase at each stage of the construction of the TOE - (e.g. module, subsystem, system); - - - subsequent to transports between different - development sites. - - - - If this work unit is applied to a dependent component - that is going to be integrated in a composed TOE, the CM - plan should consider the control of base components - obtained by the dependent TOE developer. - - When obtaining the components the evaluators are to - verify the following: - - - Transfer of each base component from the base - component developer to the integrator (dependent TOE - developer) was performed in accordance with the base - component TOE's secure delivery procedures, as - reported in the base component TOE certification - report. - - - The component received has the same identifiers as - those stated in the ST and Certification Report for - the component TOE. - - - All additional material required by a developer for - composition (integration) is provided. This is to - include the necessary extract of the component TOE's - functional specification. - - - - - - - The evaluator shall check that the configuration items - identified in the configuration list are being - maintained by the CM system. - - The CM system employed by the developer should maintain the - integrity of the TOE. The evaluator should check that for each - type of configuration item (e.g. design documents or source code - modules) contained in the configuration list there are examples - of the evidence generated by the procedures described in the CM - plan. In this case, the approach to sampling will depend upon - the level of granularity used in the CM system to control CM - items. Where, for example, 10,000 source code modules are - identified in the configuration list, a different sampling - strategy needs to be applied compared to the case in which there - are only 5, or even 1. The emphasis of this activity should be - on ensuring that the CM system is being operated correctly, - rather than on the detection of any minor error. - - For guidance on sampling see . - - - - - The evaluator shall check the CM documentation to - ascertain that it includes the CM system records - identified by the CM plan. - - The output produced by the CM system should provide the - evidence that the evaluator needs to be confident that - the CM plan is being applied, and also that all - configuration items are being maintained by the CM - system as required by . Example output could include change - control forms, or configuration item access approval - forms. - - - - - The evaluator shall examine the evidence to determine - that the CM system is being operated in accordance with - the CM plan. - - The evaluator should select and examine a sample of - evidence covering each type of CM-relevant operation - that has been performed on a configuration item - (e.g. creation, modification, deletion, reversion to an - earlier version) to confirm that all operations of the - CM system have been carried out in line with documented - procedures. The evaluator confirms that the evidence - includes all the information identified for that - operation in the CM plan. Examination of the evidence - may require access to a CM tool that is used. The - evaluator may choose to sample the evidence. - - For guidance on sampling see . - - Further confidence in the correct operation of the CM system and - the effective maintenance of configuration items may be - established by means of interviews with selected development - staff. In conducting such interviews, the evaluator aims - to gain a deeper understanding of how the CM system is used in - practise as well as to confirm that the CM procedures are being - applied as described in the CM documentation. Note that such - interviews should complement rather than replace the examination - of documentary evidence, and may not be necessary if the - documentary evidence alone satisfies the requirement. However, - given the wide scope of the CM plan it is possible that some - aspects (e.g. roles and responsibilities) may not be clear from - the CM plan and records alone. This is one case where - clarification may be necessary through interviews. - - It is expected that the evaluator will visit the - development site in support of this activity. - - For guidance on site visits see . - - - - - - - - - - - A unique reference is required to ensure that there is no - ambiguity in terms of which instance of the TOE is being - evaluated. Labelling the TOE with its reference ensures - that users of the TOE can be aware of which instance of - the TOE they are using. - - Unique identification of the configuration items leads to - a clearer understanding of the composition of the TOE, - which in turn helps to determine those items which are - subject to the evaluation requirements for the TOE. - - The use of a CM system increases assurance that the - configuration items are maintained in a controlled - manner. - - Providing controls to ensure that unauthorised - modifications are not made to the TOE (``CM access - control''), and ensuring proper functionality and use of - the CM system, helps to maintain the integrity of the - TOE. - - The purpose of the acceptance procedures is to ensure that - the parts of the TOE are of adequate quality and to - confirm that any creation or modification of configuration - items is authorised. Acceptance procedures are an - essential element in integration processes and in the - life-cycle management of the TOE. - - In development environments where the configuration items - are complex, it is difficult to control changes without - the support of automated tools. In particular, these - automated tools need to be able to support the numerous - changes that occur during development and ensure that - those changes are authorised. It is an objective of this - component to ensure that the configuration items are - controlled through automated means. If the TOE is - developed by multiple developers, i.e. integration has to - take place, the use of automatic tools is adequate. - - Production support procedures help to ensure that the - generation of the TOE from a managed set of configuration - items is correctly performed in an authorised manner, - particularly in the case when different developers are - involved and integration processes have to be carried - out. - - Requiring that the CM system be able to identify the - version of the implementation representation from which - the TOE is generated helps to ensure that the integrity of - this material is preserved by the appropriate technical, - physical and procedural safeguards. - - Providing an automated means of ascertaining changes - between versions of the TOE and identifying which - configuration items are affected by modifications to other - configuration items assists in determining the impact of - the changes between successive versions of the TOE. This - in turn can provide valuable information in determining - whether changes to the TOE result in all configuration - items being consistent with one another. - - - - The objectives of this sub-activity are to determine - whether the developer has clearly identified the TOE and - its associated configuration items, and whether the - ability to modify these items is properly controlled by - automated tools, thus making the CM system less - susceptible to human error or negligence. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the TOE suitable for testing; - - - the configuration management documentation. - - - - - The developer shall provide the TOE and a reference for the - TOE. - - - The developer shall provide the CM documentation. - - - The developer shall use a CM system. - - - The TOE shall be labelled with its unique reference. - - - The CM documentation shall describe the method used to - uniquely identify the configuration items. - - - The CM documentation shall justify that the acceptance - procedures provide for an adequate and appropriate review of - changes to all configuration items. - - - The CM system shall uniquely identify all configuration - items. - - - The CM system shall provide automated measures such that - only authorised changes are made to the configuration items. - - - The CM system shall support the production of the TOE by - automated means. - - - The CM system shall ensure that the person responsible for - accepting a configuration item into CM is not the person who - developed it. - - - The CM system shall identify the configuration items that - comprise the TSF. - - - The CM system shall support the audit of all changes to the - TOE by automated means, including the originator, date, and - time in the audit trail. - - - The CM system shall provide an automated means to identify - all other configuration items that are affected by the - change of a given configuration item. - - - The CM system shall be able to identify the version of the - implementation representation from which the TOE is - generated. - - - The CM documentation shall include a CM plan. - - - The CM plan shall describe how the CM system is used for the - development of the TOE. - - - The CM plan shall describe the procedures used to accept - modified or newly created configuration items as part of the - TOE. - - - The evidence shall demonstrate that all configuration items - are being maintained under the CM system. - - - The evidence shall demonstrate that the CM system is being - operated in accordance with the CM plan. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the TOE provided for - evaluation is labelled with its reference. - - The evaluator should ensure that the TOE contains the - unique reference which is stated in the ST. This could - be achieved through labelled packaging or media, or by a - label displayed by the operational TOE. This is to - ensure that it would be possible for consumers to - identify the TOE (e.g. at the point of purchase or - use). - - The TOE may provide a method by which it can be easily - identified. For example, a software TOE may display its - name and version number during the start up routine, or - in response to a command line entry. A hardware or - firmware TOE may be identified by a part number - physically stamped on the TOE. - - Alternatively, the unique reference provided for the TOE - may be the combination of the unique reference of each - component from which the TOE is comprised (e.g. in the - case of a composed TOE). - - - - The evaluator shall check that the TOE references used - are consistent. - - If the TOE is labelled more than once then the labels - have to be consistent. For example, it should be - possible to relate any labelled guidance documentation - supplied as part of the TOE to the evaluated operational - TOE. This ensures that consumers can be confident that - they have purchased the evaluated version of the TOE, - that they have installed this version, and that they - have the correct version of the guidance to operate the - TOE in accordance with its ST. - - The evaluator also verifies that the TOE reference is - consistent with the ST. - - If this work unit is applied to a composed TOE, the - following will apply. The composed IT TOE will not be - labelled with its unique (composite) reference, but only - the individual components will be labelled with their - appropriate TOE reference. It would require further - development for the IT TOE to be labelled, i.e. during - start-up and/or operation, with the composite reference. - If the composed TOE is delivered as the constituent - component TOEs, then the TOE items delivered will not - contain the composite reference. However, the composed - TOE ST will include the unique reference for the - composed TOE and will identify the components comprising - the composed TOE through which the consumers will be - able to determine whether they have the appropriate - items. - - - - - The evaluator shall examine the method of identifying - configuration items to determine that it describes how - configuration items are uniquely identified. - - Procedures should describe how the status of each - configuration item can be tracked throughout the - life-cycle of the TOE. The procedures may be detailed in - the CM plan or throughout the CM documentation. The - information included should describe: - - - the method how each configuration item is uniquely - identified, such that it is possible to track - versions of the same configuration item; - - the method how configuration items are assigned - unique identifiers and how they are entered into the - CM system; - - the method to be used to identify superseded - versions of a configuration item. - - - - - - The evaluator shall examine the CM documentation to - determine that it justifies that the acceptance - procedures provide for an adequate and appropriate - review of changes to all configuration items. - - The CM documentation should make it sufficiently clear - that by following the acceptance procedures only parts - of adequate quality are incorporated into the - TOE. - - - - - The evaluator shall examine the configuration items to - determine that they are identified in a way that is - consistent with the CM documentation. - - Assurance that the CM system uniquely identifies all - configuration items is gained by examining the - identifiers for the configuration items. For both - configuration items that comprise the TOE, and drafts of - configuration items that are submitted by the developer - as evaluation evidence, the evaluator confirms that each - configuration item possesses a unique identifier in a - manner consistent with the unique identification method - that is described in the CM documentation. - - - - - The evaluator shall examine the CM access control - measures described in the CM plan (cf. ) to determine that - they are automated and effective in preventing - unauthorised access to the configuration items. - - The evaluator may use a number of methods to determine - that the CM access control measures are effective. For - example, the evaluator may exercise the access control - measures to ensure that the procedures could not be - bypassed. The evaluator may use the outputs generated by - the CM system procedures required by . The evaluator may also witness a - demonstration of the CM system to ensure that the access - control measures employed are operating - effectively. - - - - - The evaluator shall check the CM plan (cf. ) for automated - procedures for supporting the production of the - TOE. - - The term ``production'' applies to those processes - adopted by the developer to progress the TOE from the - implementation representation to a state acceptable for - delivery to the end customer. - - The evaluator verifies the existence of automated - production support procedures within the CM plan. - - The following are examples for automated means - supporting the production of the TOE: - - - a ``make'' tool (as provided with many software - development tools) in the case of a software TOE; - - - a tool ensuring automatically (for example by means - of bar codes) that only parts are combined which - indeed belong together in the case of a hardware - TOE. - - - - - - - The evaluator shall examine the TOE production support - procedures to determine that they are effective in - ensuring that a TOE is generated that reflects its - implementation representation. - - The production support procedures should describe which - tools have to be used to produce the final TOE from the - implementation representation in a clearly defined - way. The conventions, directives, or other necessary - constructs are described under . - - The evaluator determines that by following the - production support procedures the correct configuration - items would be used to generate the TOE. For example, in - a software TOE this may include checking that the - automated production procedures ensure that all source - files and related libraries are included in the compiled - object code. Moreover, the procedures should ensure that - compiler options and comparable other options are - defined uniquely. For a hardware TOE, this work unit may - include checking that the automatic production - procedures ensure that the belonging parts are built - together and no parts are missing. - - The customer can then be confident that the version of - the TOE delivered for installation is derived from the - implementation representation in an unambiguous way and - implements the SFRs as described in the ST. - - The evaluator should bear in mind that the CM system - need not necessarily possess the capability to produce - the TOE, but should provide support for the process that - will help reduce the probability of human error. - - - - - The evaluator shall examine the CM system to determine - that it ensures that the person responsible for - accepting a configuration item is not the person who - developed it. - - The acceptance procedures describe who is responsible - for accepting a configuration item. From these - descriptions, the evaluator should be able to determine - that the person who developed a configuration item is in - no case responsible for its acceptance. - - - - - The evaluator shall examine the CM system to determine - that it identifies the configuration items that comprise - the TSF. - - The CM documentation should describe how the CM system - identifies the configuration items that comprise the - TSF. The evaluator should select a sample of - configuration items covering each type of items, - particularly containing TSF and non-TSF items, and check - that they are correctly classified by the CM - system. - - For guidance on sampling see . - - - - - The evaluator shall examine the CM system to determine - that it supports the audit of all changes to the TOE by - automated means, including the originator, date, and - time in the audit trail. - - The evaluator should inspect a sample of audit trails - and check, if they contain the minimum - information. - - - - - The evaluator shall examine the CM system to determine - that it provides an automated means to identify all - other configuration items that are affected by the - change of a given configuration item. - - The CM documentation should describe how the CM system - identifies all other configuration items that are - affected by the change of a given configuration - item. The evaluator should select a sample of - configuration items, covering all types of items, and - exercise the automated means to determine that it - identifies all items that are affected by the change of - the selected item. - - For guidance on sampling see . - - - - - The evaluator shall examine the CM system to determine - that it is able to identify the version of the - implementation representation from which the TOE is - generated. - - The CM documentation should describe how the CM system - identifies the version of the implementation - representation from which the TOE is generated. The - evaluator should select a sample of the parts used to - produce the TOE and should apply the CM system to verify - that it identifies the corresponding implementation - representation in the correct version. - - For guidance on sampling see . - - - - - The evaluator shall check that the CM documentation provided - includes a CM plan. - The CM plan needs not to be a connected document, but it is - recommended that there is a single document that describes where - the various parts of the CM plan can be found. If the CM plan is - no single document, the list in the following work unit gives - hints regarding which context is expected. - - - - - The evaluator shall examine the CM plan to determine - that it describes how the CM system is used for the - development of the TOE. - - The descriptions contained in a CM plan include, if - applicable: - - - all activities performed in the TOE development that - are subject to configuration management procedures - (e.g. creation, modification or deletion of a - configuration item, data-backup, archiving); - - - which means (e.g. CM tools, forms) have to be made - available; - - - the usage of the CM tools: the necessary details for - a user of the CM system to be able to operate the CM - tools correctly in order to maintain the integrity - of the TOE; - - - the production support procedures; - - - which other objects (development components, tools, - assessment environments, etc) are taken under CM - control; - - - the roles and responsibilities of individuals - required to perform operations on individual - configuration items (different roles may be - identified for different types of configuration - items (e.g. design documentation or source code)); - - - how CM instances (e.g. change control boards, - interface control working groups) are introduced and - staffed; - - - the description of the change management; - - - the procedures that are used to ensure that only - authorised individuals can make changes to - configuration items; - - - the procedures that are used to ensure that - concurrency problems do not occur as a result of - simultaneous changes to configuration items; - - - the evidence that is generated as a result of - application of the procedures. For example, for a - change to a configuration item, the CM system might - record a description of the change, accountability - for the change, identification of all configuration - items affected, status (e.g. pending or completed), - and date and time of the change. This might be - recorded in an audit trail of changes made or change - control records; - - - the approach to version control and unique - referencing of TOE versions (e.g. covering the - release of patches in operating systems, and the - subsequent detection of their application). - - - - - - - The evaluator shall examine the CM plan to determine - that it describes the procedures used to accept modified - or newly created configuration items as parts of the - TOE. - - The descriptions of the acceptance procedures in the CM - plan should include the developer roles or individuals - responsible for the acceptance and the criteria to be - used for acceptance. They should take into account all - acceptance situations that may occur, in particular: - - - accepting an item into the CM system for the first - time, in particular inclusion of software, firmware - and hardware components from other manufacturers - into the TOE (``integration''); - - - moving configuration items to the next life-cycle - phase at each stage of the construction of the TOE - (e.g. module, subsystem, system); - - - subsequent to transports between different - development sites. - - - - - - - The evaluator shall check that the configuration items - identified in the configuration list are being - maintained by the CM system. - - The CM system employed by the developer should maintain the - integrity of the TOE. The evaluator should check that for each - type of configuration item (e.g. design documents or source code - modules) contained in the configuration list there are examples - of the evidence generated by the procedures described in the CM - plan. In this case, the approach to sampling will depend upon - the level of granularity used in the CM system to control CM - items. Where, for example, 10,000 source code modules are - identified in the configuration list, a different sampling - strategy needs to be applied compared to the case in which there - are only 5, or even 1. The emphasis of this activity should be - on ensuring that the CM system is being operated correctly, - rather than on the detection of any minor error. - - For guidance on sampling see . - - - - - The evaluator shall check the CM documentation to - ascertain that it includes the CM system records - identified by the CM plan. - - The output produced by the CM system should provide the - evidence that the evaluator needs to be confident that - the CM plan is being applied, and also that all - configuration items are being maintained by the CM - system as required by . Example output could include - change control forms, or configuration item access - approval forms. - - - - - The evaluator shall examine the evidence to determine - that the CM system is being operated in accordance with - the CM plan. - - The evaluator should select and examine a sample of - evidence covering each type of CM-relevant operation - that has been performed on a configuration item - (e.g. creation, modification, deletion, reversion to an - earlier version) to confirm that all operations of the - CM system have been carried out in line with documented - procedures. The evaluator confirms that the evidence - includes all the information identified for that - operation in the CM plan. Examination of the evidence - may require access to a CM tool that is used. The - evaluator may choose to sample the evidence. - - For guidance on sampling see . - - Further confidence in the correct operation of the CM system and - the effective maintenance of configuration items may be - established by means of interviews with selected development - staff. In conducting such interviews, the evaluator aims - to gain a deeper understanding of how the CM system is used in - practise as well as to confirm that the CM procedures are being - applied as described in the CM documentation. Note that such - interviews should complement rather than replace the examination - of documentary evidence, and may not be necessary if the - documentary evidence alone satisfies the requirement. However, - given the wide scope of the CM plan it is possible that some - aspects (e.g. roles and responsibilities) may not be clear from - the CM plan and records alone. This is one case where - clarification may be necessary through interviews. - - It is expected that the evaluator will visit the - development site in support of this activity. - - For guidance on site visits see . - - - - The evaluator shall determine that the application of the - production support procedures results in a TOE as provided - by the developer for testing activities. - - - The evaluator shall examine the production support - procedures to determine that by following these - procedures a TOE would be produced like that one - provided by the developer for testing activities. - - If the TOE is a small software TOE and production - consists of compiling and linking, the evaluator might - confirm the adequacy of the production support - procedures by reapplying them himself. - - If the production process of the TOE is more complicated - (as for example in the case of a smart card), but has - already started, the evaluator should inspect the - application of the production support procedures during - a visit of the development site. He might compare a copy - of the TOE produced in his presence with the samples - used for his testing activities. - - For guidance on site visits see . - - Otherwise the evaluator's determination should be based - on the documentary evidence provided by the - developer. - - This work unit may be performed in conjunction with the - evaluation activities under . - - - - - - - - The objective of this family is to identify items to be - included as configuration items and hence placed under the - CM requirements of . - Applying configuration management to these additional items - provides additional assurance that the integrity of TOE is - maintained. - - - - Configuration management scope indicates the TOE items that - need to be controlled by the configuration management - system. - - - - The components in this family are levelled on the basis of - which of the following are required to be included as - configuration items: the TOE and the evaluation evidence - required by the SARs; the parts of the TOE; the - implementation representation; security flaws; and - development tools and related information. - - - - While mandates a list of - configuration items and that each item on this list be under - CM, leaves the contents of - the configuration list to the discretion of the - developer. narrows this - discretion by identifying items that must be included in the - configuration list, and hence come under the CM requirements - of . - - - - - A CM system can control changes only to those items that - have been placed under CM (i.e., the configuration items - identified in the configuration list). Placing the TOE - itself and the evaluation evidence required by the other - SARs in the ST under CM provides assurance that they have - been modified in a controlled manner with proper - authorisations. - - - - introduces the - requirement that the TOE itself and the evaluation - evidence required by the other SARs in the ST be included - in the configuration list and hence be subject to the CM - requirements of . - - - - The objective of this sub-activity is to determine whether - the developer performs configuration management on the TOE - and the evaluation evidence. These configuration items are - controlled in accordance with . - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the configuration list. - - - - - The developer shall provide a configuration list for the - TOE. - - - The configuration list shall include the following: the TOE - itself; and the evaluation evidence required by the SARs. - - - The configuration list shall uniquely identify the - configuration items. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the configuration list - includes the following set of items: - - - the TOE itself; - - - the evaluation evidence required by the SARs in the - ST. - - - - - - - The evaluator shall examine the configuration list to - determine that it uniquely identifies each configuration - item. - - The configuration list contains sufficient information - to uniquely identify which version of each item has been - used (typically a version number). Use of this list will - enable the evaluator to check that the correct - configuration items, and the correct version of each - item, have been used during the evaluation. - - - - - - - - A CM system can control changes only to those items that - have been placed under CM (i.e., the configuration items - identified in the configuration list). Placing the TOE - itself, the parts that comprise the TOE, and the - evaluation evidence required by the other SARs under CM - provides assurance that they have been modified in a - controlled manner with proper authorisations. - - - - introduces the - requirement that the parts that comprise the TOE (all - parts that are delivered to the consumer, for example - hardware parts or executable files) be included in the - configuration list and hence be subject to the CM - requirements of . - - introduces the - requirement that the configuration list indicate the - developer of each TSF relevant configuration - item. ``Developer'' here does not refer to a person, but - to the organisation responsible for the development of the - item. - - - - The objective of this sub-activity is to determine whether - the configuration list includes the TOE, the parts that - comprise the TOE, and the evaluation evidence. These configuration items are - controlled in accordance with . - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the configuration list. - - - - - The developer shall provide a configuration list for the - TOE. - - - The configuration list shall include the following: the TOE - itself; the evaluation evidence required by the SARs; and - the parts that comprise the TOE. - - - The configuration list shall uniquely identify the - configuration items. - - - For each TSF relevant configuration item, the configuration - list shall indicate the developer of the item. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the configuration list - includes the following set of items: - - the TOE itself; - - the parts that comprise the TOE; - - the evaluation evidence required by the SARs. - - - - - - - The evaluator shall examine the configuration list to - determine that it uniquely identifies each configuration - item. - - The configuration list contains sufficient information - to uniquely identify which version of each item has been - used (typically a version number). Use of this list will - enable the evaluator to check that the correct - configuration items, and the correct version of each - item, have been used during the evaluation. - - - - - The evaluator shall check that the configuration list - indicates the developer of each TSF relevant - configuration item. - - If only one developer is involved in the development of - the TOE, this work unit is not applicable, and is - therefore considered to be satisfied. - - - - - - - - A CM system can control changes only to those items that - have been placed under CM (i.e., the configuration items - identified in the configuration list). Placing the TOE - itself, the parts that comprise the TOE, the TOE - implementation representation and the evaluation evidence - required by the other SARs under CM provides assurance - that they have been modified in a controlled manner with - proper authorisations. - - - - introduces the - requirement that the TOE implementation representation be - included in the list of configuration items and hence be - subject to the CM requirements of . - - - - The objective of this sub-activity is to determine whether - the configuration list includes the TOE, the parts that - comprise the TOE, the TOE implementation representation, - and the evaluation evidence. These configuration items are - controlled in accordance with . - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the configuration list. - - - - - The developer shall provide a configuration list for the - TOE. - - - The configuration list shall include the following: the TOE - itself; the evaluation evidence required by the SARs; the - parts that comprise the TOE; and the implementation - representation. - - - The configuration list shall uniquely identify the - configuration items. - - - For each TSF relevant configuration item, the configuration - list shall indicate the developer of the item. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the configuration list - includes the following set of items: - - - the TOE itself; - - - the parts that comprise the TOE; - - - the TOE implementation representation; - - - the evaluation evidence required by the SARs in the - ST. - - - - - - - The evaluator shall examine the configuration list to - determine that it uniquely identifies each configuration - item. - - The configuration list contains sufficient information - to uniquely identify which version of each item has been - used (typically a version number). Use of this list will - enable the evaluator to check that the correct - configuration items, and the correct version of each - item, have been used during the evaluation. - - - - - The evaluator shall check that the configuration list - indicates the developer of each TSF relevant - configuration item. - - If only one developer is involved in the development of - the TOE, this work unit is not applicable, and is - therefore considered to be satisfied. - - - - - - - - A CM system can control changes only to those items that - have been placed under CM (i.e., the configuration items - identified in the configuration list). Placing the TOE - itself, the parts that comprise the TOE, the TOE - implementation representation and the evaluation evidence - required by the other SARs under CM provides assurance - that they have been modified in a controlled manner with - proper authorisations. - - Placing security flaws under CM ensures that security flaw - reports are not lost or forgotten, and allows a developer - to track security flaws to their resolution. - - - - introduces the - requirement that security flaws be included in the - configuration list and hence be subject to the CM - requirements of . This - requires that information regarding previous security - flaws and their resolution be maintained, as well as - details regarding current security flaws. - - - - The objective of this sub-activity is to determine whether - the configuration list includes the TOE, the parts that - comprise the TOE, the TOE implementation representation, - security flaws, and the evaluation evidence. These configuration items are - controlled in accordance with . - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the configuration list. - - - - - The developer shall provide a configuration list for the - TOE. - - - The configuration list shall include the following: the TOE - itself; the evaluation evidence required by the SARs; the - parts that comprise the TOE; the implementation - representation; and security flaw reports and resolution - status. - - - The configuration list shall uniquely identify the - configuration items. - - - For each TSF relevant configuration item, the configuration - list shall indicate the developer of the item. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the configuration list - includes the following set of items: - - - the TOE itself; - - - the parts that comprise the TOE; - - - the TOE implementation representation; - - - the evaluation evidence required by the SARs in the - ST; - - - the documentation used to record details of reported - security flaws associated with the implementation - (e.g., problem status reports derived from a - developer's problem database). - - - - - - - The evaluator shall examine the configuration list to - determine that it uniquely identifies each configuration - item. - - The configuration list contains sufficient information - to uniquely identify which version of each item has been - used (typically a version number). Use of this list will - enable the evaluator to check that the correct - configuration items, and the correct version of each - item, have been used during the evaluation. - - - - - The evaluator shall check that the configuration list - indicates the developer of each TSF relevant - configuration item. - - If only one developer is involved in the development of - the TOE, this work unit is not applicable, and is - therefore considered to be satisfied. - - - - - - - - A CM system can control changes only to those items that - have been placed under CM (i.e., the configuration items - identified in the configuration list). Placing the TOE - itself, the parts that comprise the TOE, the TOE - implementation representation and the evaluation evidence - required by the other SARs under CM provides assurance - that they have been modified in a controlled manner with - proper authorisations. - - Placing security flaws under CM ensures that security flaw - reports are not lost or forgotten, and allows a developer - to track security flaws to their resolution. - - Development tools play an important role in ensuring the - production of a quality version of the TOE. Therefore, it - is important to control modifications to these - tools. - - - - introduces the - requirement that development tools and other related - information be included in the list of configuration items - and hence be subject to the CM requirements of . Examples of development tools - are programming languages and compilers. Information - pertaining to TOE generation items (such as compiler - options, generation options, and build options) is an - example of information relating to development - tools. - - - - The objective of this sub-activity is to determine whether - the configuration list includes the TOE, the parts that - comprise the TOE, the TOE implementation representation, - security flaws, development tools and related information, - and the evaluation evidence. These configuration items are - controlled in accordance with . - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the configuration list. - - - - - The developer shall provide a configuration list for the - TOE. - - - The configuration list shall include the following: the TOE - itself; the evaluation evidence required by the SARs; the - parts that comprise the TOE; the implementation - representation; security flaw reports and resolution status; - and development tools and related information. - - - The configuration list shall uniquely identify the - configuration items. - - - For each TSF relevant configuration item, the configuration - list shall indicate the developer of the item. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the configuration list - includes the following set of items: - - - the TOE itself; - - - the parts that comprise the TOE; - - - the TOE implementation representation; - - - the evaluation evidence required by the SARs in the - ST; - - - the documentation used to record details of reported - security flaws associated with the implementation - (e.g., problem status reports derived from a - developer's problem database); - - - all tools (incl. test software, if applicable) - involved in the development and production of the - TOE including the names, versions, configurations - and roles of each development tool, and related - documentation. - - - For a software TOE, ``development tools'' are usually - programming languages and compiler and ``related documentation'' - comprises compiler and linker options. For a hardware TOE, - ``development tools'' might be hardware design languages, - simulation and synthesis tools, compilers, and ``related - documentation'' might comprise compiler options again. - - - - - The evaluator shall examine the configuration list to - determine that it uniquely identifies each configuration - item. - - The configuration list contains sufficient information - to uniquely identify which version of each item has been - used (typically a version number). Use of this list will - enable the evaluator to check that the correct - configuration items, and the correct version of each - item, have been used during the evaluation. - - - - - The evaluator shall check that the configuration list - indicates the developer of each TSF relevant - configuration item. - - If only one developer is involved in the development of - the TOE, this work unit is not applicable, and is - therefore considered to be satisfied. - - - - - - - - The concern of this family is the secure transfer of the - finished TOE from the development environment into the - responsibility of the user. - - The requirements for delivery call for system control and - distribution facilities and procedures that detail the - measures necessary to provide assurance that the security of - the TOE is maintained during distribution of the TOE to the - user. For a valid distribution of the TOE, the procedures - used for the distribution of the TOE address the objectives - identified in the PP/ST relating to the security of the TOE - during delivery. - - - - Delivery covers the procedures used to maintain security - during transfer of the TOE to the user, both on initial - delivery and as part of subsequent modification. It includes - special procedures or operations required to demonstrate the - authenticity of the delivered TOE. Such procedures and - measures are the basis for ensuring that the security - protection offered by the TOE is not compromised during - transfer. While compliance with the delivery requirements - cannot always be determined when a TOE is evaluated, it is - possible to evaluate the procedures that a developer has - developed to distribute the TOE to users. - - - - This family contains only one component. An increasing level - of protection is established by requiring commensurability - of the delivery procedures with the assumed attack potential - in the family . - - - - Transportations from subcontractors to the developer or - between different development sites are not considered here, - but in the family . - - The end of the delivery phase is marked by the transfer of - the TOE into the responsibility of the user. This does not - necessarily coincide with the arrival of the TOE at the - user's location. - - The delivery procedures should consider, if applicable, - issues such as: - - - ensuring that the TOE received by the consumer - corresponds precisely to the evaluated version of the - TOE; - - - avoiding or detecting any tampering with the actual - version of the TOE; - - - preventing submission of a false version of the TOE; - - - avoiding unwanted knowledge of distribution of the TOE - to the consumer: there might be cases where potential - attackers should not know when and how it is delivered; - - - avoiding or detecting the TOE being intercepted during - delivery; and - - - avoiding the TOE being delayed or stopped during - distribution. - - - - The delivery procedures should include the recipient's - actions implied by these issues. The consistent description - of these implied actions is examined in the family, if present. - - - - - The objective of this sub-activity is to determine whether - the delivery documentation describes all procedures used - to maintain security of the TOE when distributing the TOE - to the user. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the delivery documentation. - - - - - The developer shall document and provide procedures for delivery of the - TOE or parts of it to the consumer. - - - The developer shall use the delivery procedures. - - - The evaluator shall examine aspects of the delivery - process to determine that the delivery procedures are - used. - - The approach taken by the evaluator to check the - application of delivery procedures will depend on the - nature of the TOE, and the delivery process itself. In - addition to examination of the procedures themselves, - the evaluator seeks some assurance that they are applied - in practise. Some possible approaches are: - - - a visit to the distribution site(s) where practical - application of the procedures may be observed; - - - examination of the TOE at some stage during - delivery, or after the user has received it - (e.g. checking for tamper proof seals); - - - observing that the process is applied in practise - when the evaluator obtains the TOE through regular - channels; - - - questioning end users as to how the TOE was - delivered. - - - - For guidance on site visits see . - - It may be the case of a newly developed TOE that the - delivery procedures have yet to be exercised. In these - cases, the evaluator has to be satisfied that - appropriate procedures and facilities are in place for - future deliveries and that all personnel involved are - aware of their responsibilities. The evaluator may - request a ``dry run'' of a delivery if this is - practical. If the developer has produced other similar - products, then an examination of procedures in their use - may be useful in providing assurance. - - - - The delivery documentation shall describe all procedures - that are necessary to maintain security when distributing - versions of the TOE to the consumer. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the delivery documentation - to determine that it describes all procedures that are - necessary to maintain security when distributing - versions of the TOE or parts of it to the - consumer. - - The delivery documentation describes proper procedures - to maintain security of the TOE during transfer of the - TOE or its component parts and to determine the - identification of the TOE. - - The delivery documentation should cover the entire TOE, - but may contain different procedures for different parts - of the TOE. The evaluation should consider the totality - of procedures. - - The delivery procedures should be applicable across all - phases of delivery from the production environment to - the installation environment (e.g. packaging, storage - and distribution). Standard commercial practise for - packaging and delivery may be acceptable. This includes - shrink wrapped packaging, a security tape or a sealed - envelope. For the distribution, physical (e.g. public - mail or a private distribution service) or electronic - (e.g. electronic mail or downloading off the Internet) - procedures may be used. - - Cryptographic checksums or a software signature may be - used by the developer to ensure that tampering or - masquerading can be detected. Tamper proof seals - additionally indicate if the confidentiality has been - broken. For software TOEs, confidentiality might be - assured by using encryption. If availability is of - concern, a secure transportation might be - required. - - Interpretation of the term ``necessary to maintain - security'' will need to consider: - - - The nature of the TOE (e.g. whether it is software - or hardware). - - - The overall security level stated for the TOE by the - chosen level of the Vulnerability Assessment. If the - TOE is required to be resistant against attackers of - a certain potential in its intended environment, - this should also apply to the delivery of the - TOE. The evaluator should determine that a balanced - approach has been taken, such that delivery does not - present a weak point in an otherwise secure - development process. - - - The security objectives provided by the ST. The emphasis in the - delivery documentation is likely to be on measures related to - integrity, as integrity of the TOE is always important. However, - confidentiality and availability of the delivery will be of - concern in the delivery of some TOEs; procedures relating to - these aspects of the secure delivery should also be discussed in - the procedures. - - - - - - - - - - Development security is concerned with physical, procedural, - personnel, and other security measures that may be used in - the development environment to protect the TOE and its - parts. It includes the physical security of the development - location and any procedures used to select development - staff. - - - - Development security covers the physical, procedural, - personnel, and other security measures used in the - development environment. It includes physical security of - the development location(s) and controls on the selection - and hiring of development staff. - - - - The components in this family are levelled on the basis of - whether justification of the sufficiency of the security - measures is required. - - - - This family deals with measures to remove or reduce threats - existing at the developer's site. - - The evaluator should visit the site(s) in order to assess - evidence for development security. This may include sites of - subcontractors involved in the TOE development and - production. Any decision not to visit shall be agreed with - the evaluation authority. - - Although development security deals with the maintenance of - the TOE and hence with aspects becoming relevant after the - completion of the evaluation, the requirements specify only that the - development security measures be in place at the time of - evaluation. Furthermore, - does not contain any requirements related to the sponsor's - intention to apply the development security measures in the - future, after completion of the evaluation. - - It is recognised that confidentiality may not always be an - issue for the protection of the TOE in its development - environment. The use of the word ``necessary'' allows for - the selection of appropriate safeguards. - - - - - The objective of this sub-activity is to determine whether - the developer's security controls on the development - environment are adequate to provide the confidentiality - and integrity of the TOE design and implementation that is - necessary to ensure that secure operation of the TOE is - not compromised. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the development security documentation. - - - - In addition, the evaluator may need to examine other - deliverables to determine that the security controls are - well-defined and followed. Specifically, the evaluator may - need to examine the developer's configuration management - documentation (the input for the ``Production support and acceptance - procedures'' and the - ``Problem tracking CM coverage''). Evidence that the - procedures are being applied is also required. - - - The developer shall produce and provide development security - documentation. - - - 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. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the development security - documentation to determine that it details all security - measures used in the development environment that are - necessary to protect the confidentiality and integrity - of the TOE design and implementation. - - The evaluator determines what is necessary by first referring to - the ST for any information that may assist in the determination - of necessary protection. - - If no explicit information is available from the ST the - evaluator will need to make a determination of the - necessary measures. In cases where the developer's - measures are considered less than what is necessary, a - clear justification should be provided for the - assessment, based on a potential exploitable - vulnerability. - - The following types of security measures are considered - by the evaluator when examining the documentation: - - - physical, for example physical access controls used - to prevent unauthorised access to the TOE - development environment (during normal working hours - and at other times); - - - procedural, for example covering: - - - granting of access to the development - environment or to specific parts of the - environment such as development machines - - - revocation of access rights when a person leaves - the development team - - - transfer of protected material within and out of - the development environment and between - different development sites in accordance with - defined acceptance procedures - - - admitting and escorting visitors to the - development environment - - - roles and responsibilities in ensuring the - continued application of security measures, and - the detection of security breaches. - - - - - personnel, for example any controls or checks made - to establish the trustworthiness of new development - staff; - - - other security measures, for example the logical - protections on any development machines. - - - - The development security documentation should identify - the locations at which development occurs, and describe - the aspects of development performed, along with the - security measures applied at each location and for - transports between different locations. For example, - development could occur at multiple facilities within a - single building, multiple buildings at the same site, or - at multiple sites. Transports of parts of the TOE or the - unfinished TOE between different development sites are - to be covered by , - whereas the transport of the finished TOE to the - consumer is dealt with in . - - Development includes the production of the TOE. - - - - - The evaluator shall examine the development - confidentiality and integrity policies in order to - determine the sufficiency of the security measures - employed. - - The evaluator should examine whether the following is included - in the policies: - - what information relating to the TOE development needs to be - kept confidential, and which members of the development - staff are allowed to access such material; - - what material must be protected from unauthorised - modification in order to preserve the integrity of - the TOE, and which members of the development staff - are allowed to modify such material. - - - The evaluator should determine that these policies are - described in the development security documentation, - that the security measures employed are consistent with - the policies, and that they are complete. - - It should be noted that configuration management - procedures will help protect the integrity of the TOE - and the evaluator should avoid overlap with the - work-units conducted for the . For example, the CM documentation may - describe the security procedures necessary for - controlling the roles or individuals who should have - access to the development environment and who may modify - the TOE. - - Whereas the - requirements are fixed, those for the , - mandating only necessary measures, are dependent on the nature of the TOE, - and on information that may be provided in the ST. The evaluators would - then determine that such a policy had been applied under this sub-activity. - - - - The evaluator shall confirm that the security measures are - being applied. - - - The evaluator shall examine the development security - documentation and associated evidence to determine that - the security measures are being applied. - - This work unit requires the evaluator to determine that - the security measures described in the development - security documentation are being followed, such that the - integrity of the TOE and the confidentiality of - associated documentation is being adequately - protected. For example, this could be determined by - examination of the documentary evidence - provided. Documentary evidence should be supplemented by - visiting the development environment. A visit to the - development environment will allow the evaluator to: - - - observe the application of security measures - (e.g. physical measures); - - - examine documentary evidence of application of - procedures; - - - interview development staff to check awareness of - the development security policies and procedures, - and their responsibilities. - - - - A development site visit is a useful means of gaining - confidence in the measures being used. Any decision not - to make such a visit should be determined in - consultation with the evaluation authority. - - For guidance on site visits see . - - - - - - - - The objective of this sub-activity is to determine whether - the developer's security controls on the development - environment are adequate to provide the confidentiality - and integrity of the TOE design and implementation that is - necessary to ensure that secure operation of the TOE is - not compromised. Additionally, sufficiency of the measures - as applied is intended be justified. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the development security documentation. - - - - In addition, the evaluator may need to examine other - deliverables to determine that the security controls are - well-defined and followed. Specifically, the evaluator may - need to examine the developer's configuration management - documentation (the input for the ``Production support and acceptance - procedures'' and the - ``Problem tracking CM coverage''). Evidence that the - procedures are being applied is also required. - - - The developer shall produce and provide development security - documentation. - - - 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. - - - The development security documentation shall justify that - the security measures provide the necessary level of - protection to maintain the confidentiality and integrity of - the TOE. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the development security - documentation to determine that it details all security - measures used in the development environment that are - necessary to protect the confidentiality and integrity - of the TOE design and implementation. - - The evaluator determines what is necessary by first referring to - the ST for any information that may assist in the determination - of necessary protection. - - If no explicit information is available from the ST the - evaluator will need to make a determination of the - necessary measures. In cases where the developer's - measures are considered less than what is necessary, a - clear justification should be provided for the - assessment, based on a potential exploitable - vulnerability. - - The following types of security measures are considered - by the evaluator when examining the documentation: - - - physical, for example physical access controls used - to prevent unauthorised access to the TOE - development environment (during normal working hours - and at other times); - - - procedural, for example covering: - - - granting of access to the development - environment or to specific parts of the - environment such as development machines - - - revocation of access rights when a person leaves - the development team - - - transfer of protected material out of the - development environment and between different - development sites in accordance with defined - acceptance procedures - - - admitting and escorting visitors to the - development environment - - - roles and responsibilities in ensuring the - continued application of security measures, and - the detection of security breaches. - - - - - personnel, for example any controls or checks made - to establish the trustworthiness of new development - staff; - - - other security measures, for example the logical - protections on any development machines. - - - - The development security documentation should identify - the locations at which development occurs, and describe - the aspects of development performed, along with the - security measures applied at each location and for - transports between different locations. For example, - development could occur at multiple facilities within a - single building, multiple buildings at the same site, or - at multiple sites. Transports of parts of the TOE or the - unfinished TOE between different development sites are - to be covered by the , - whereas the transport of the finished TOE to the - consumer is dealt with in the . - - Development includes the production of the TOE. - - - - - The evaluator shall examine the development security - documentation to determine that an appropriate - justification is given why the security measures provide - the necessary level of protection to maintain the - confidentiality and integrity of the TOE. - - Since attacks on the TOE or its related information are - assumed in different design and production stages, - measures and procedures need to have an appropriate - level necessary to prevent those attacks or to make them - more difficult. - - Since this level depends on the overall attack potential - claimed for the TOE (cf. the component chosen), the development - security documentation should justify the necessary - level of protection to maintain the confidentiality and - integrity of the TOE. This level has to be achieved by - the security measures applied. - - The concept of protection measures should be consistent, - and the justification should include an analysis of how - the measures are mutually supportive. All aspects of - development and production on all the different sites - with all roles involved up to delivery of the TOE should - be analysed. - - Justification may include an analysis of potential - vulnerabilities taking the applied security measures - into account. - - There may be a convincing argument showing that e.g. - - - The technical measures and mechanisms of the - developer's infrastructure are sufficient for - keeping the appropriate security level - (e.g. cryptographic mechanisms as well as physical - protection mechanisms, properties of the CM system - (cf. )); - - The system containing the implementation - representation of the TOE (including concerning - guidance documents) provides effective protection - against logical attacks e.g. by ``Trojan'' code or - viruses. It might be adequate, if the implementation - representation is kept on an isolated system where - only the software necessary to maintain it is - installed and where no additional software is - installed afterwards. - - Data brought into this system need to be carefully considered to - prevent the installation of hidden functionality onto the - system. The effectiveness of these measures need to be tested, - e.g. by independently trying to get access to the machine, - install some additional executable (program, macro etc.) or get - some information out of the machine using logical - attacks. - - The appropriate organisational (procedural and - personal) measures are unconditionally - enforced. - - - - - The evaluator shall examine the development - confidentiality and integrity policies in order to - determine the sufficiency of the security measures - employed. - - The evaluator should examine whether the following is included - in the policies: - - what information relating to the TOE development needs to be - kept confidential, and which members of the development - staff are allowed to access such material; - - what material must be protected from unauthorised - modification in order to preserve the integrity of - the TOE, and which members of the development staff - are allowed to modify such material. - - - The evaluator should determine that these policies are - described in the development security documentation, - that the security measures employed are consistent with - the policies, and that they are complete. - - It should be noted that configuration management - procedures will help protect the integrity of the TOE - and the evaluator should avoid overlap with the - work-units conducted for the . For example, the CM documentation may - describe the security procedures necessary for - controlling the roles or individuals who should have - access to the development environment and who may modify - the TOE. - - Whereas the - requirements are fixed, those for the , mandating only necessary measures, are - dependent on the nature of the TOE, and on information - that may be provided in the ST. For example, the ST may - identify a security objective for the development - environment that requires the TOE to be developed by - staff that has security clearance. The evaluators would - then determine that such a policy had been applied under - this sub-activity. - - - - The evaluator shall confirm that the security measures are - being applied. - - - The evaluator shall examine the development security - documentation and associated evidence to determine that - the security measures are being applied. - - This work unit requires the evaluator to determine that - the security measures described in the development - security documentation are being followed, such that the - integrity of the TOE and the confidentiality of - associated documentation is being adequately - protected. For example, this could be determined by - examination of the documentary evidence - provided. Documentary evidence should be supplemented by - visiting the development environment. A visit to the - development environment will allow the evaluator to: - - - observe the application of security measures - (e.g. physical measures); - - - examine documentary evidence of application of - procedures; - - - interview development staff to check awareness of - the development security policies and procedures, - and their responsibilities. - - - - A development site visit is a useful means of gaining - confidence in the measures being used. Any decision not - to make such a visit should be determined in - consultation with the evaluation authority. - - For guidance on site visits see . - - - - - - - - Flaw remediation requires that discovered security flaws be - tracked and corrected by the developer. Although future - compliance with flaw remediation procedures cannot be - determined at the time of the TOE evaluation, it is possible - to evaluate the policies and procedures that a developer has - in place to track and correct flaws, and to distribute the - flaw information and corrections. - - - - Flaw remediation ensures that flaws discovered by the TOE - consumers will be tracked and corrected while the TOE is - supported by the developer. While future compliance with the - flaw remediation requirements cannot be determined when a - TOE is evaluated, it is possible to evaluate the procedures - and policies that a developer has in place to track and - repair flaws, and to distribute the repairs to - consumers. - - - - The components in this family are levelled on the basis of - the increasing extent in scope of the flaw remediation - procedures and the rigour of the flaw remediation - policies. - - - - This family provides assurance that the TOE will be - maintained and supported in the future, requiring the TOE - developer to track and correct flaws in the - TOE. Additionally, requirements are included for the - distribution of flaw corrections. However, this family does - not impose evaluation requirements beyond the current - evaluation. - - The TOE user is considered to be the focal point in the user - organisation that is responsible for receiving and - implementing fixes to security flaws. This is not - necessarily an individual user, but may be an organisational - representative who is responsible for the handling of - security flaws. The use of the term TOE user recognises that - different organisations have different procedures for - handling flaw reporting, which may be done either by an - individual user, or by a central administrative body. - - The flaw remediation procedures should describe the methods - for dealing with all types of flaws encountered. These flaws - may be reported by the developer, by users of the TOE, or by - other parties with familiarity with the TOE. Some flaws may - not be reparable immediately. There may be some occasions - where a flaw cannot be fixed and other (e.g. procedural) - measures must be taken. The documentation provided should - cover the procedures for providing the operational sites - with fixes, and providing information on flaws where fixes - are delayed (and what to do in the interim) or when fixes - are not possible. - - Changes applied to a TOE after its release render it - unevaluated; although some information from the original - evaluation may still apply. The phrase ``release of the - TOE'' used in this family therefore refers to a version of a - product that is a release of a certified TOE, to which - changes have been applied. - - - - - The objective of this sub-activity is to determine whether - the developer has established flaw remediation procedures - that describe the tracking of security flaws, the - identification of corrective actions, and the distribution - of corrective action information to TOE users. - - - - The evaluation evidence for this sub-activity is: - - - the flaw remediation procedures documentation. - - - - - The developer shall document and provide flaw remediation procedures - addressed to TOE developers. - - - The flaw remediation procedures documentation shall describe - the procedures used to track all reported security flaws in - each release of the TOE. - - - 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. - - - The flaw remediation procedures shall require that - corrective actions be identified for each of the security - flaws. - - - The flaw remediation procedures documentation shall describe - the methods used to provide flaw information, corrections - and guidance on corrective actions to TOE users. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the flaw remediation - procedures documentation to determine that it describes - the procedures used to track all reported security flaws - in each release of the TOE. - - The procedures describe the actions that are taken by - the developer from the time each suspected security flaw - is reported to the time that it is resolved. This - includes the flaw's entire time frame, from initial - detection through ascertaining that the flaw is a - security flaw, to resolution of the security - flaw. - - If a flaw is discovered not to be security-relevant, - there is no need (for the purposes of the requirements) for the flaw - remediation procedures to track it further; only that - there be an explanation of why the flaw is not - security-relevant. - - While these requirements do not mandate that there be a - publicised means for TOE users to report security flaws, - they do mandate that all security flaws that are - reported be tracked. That is, a reported security flaw - cannot be ignored simply because it comes from outside - the developer's organisation. - - - - - The evaluator shall examine the flaw remediation - procedures to determine that the application of these - procedures would produce a description of each security - flaw in terms of its nature and effects. - - The procedures identify the actions that are taken by - the developer to describe the nature and effects of each - security flaw in sufficient detail to be able to - reproduce it. The description of the nature of a - security flaw addresses whether it is an error in the - documentation, a flaw in the design of the TSF, a flaw - in the implementation of the TSF, etc. The description - of the security flaw's effects identifies the portions - of the TSF that are affected and how those portions are - affected. For example, a security flaw in the - implementation might be found that affects the - identification and authentication enforced by the TSF by - permitting authentication with the password - ``BACK DOOR''. - - - - - The evaluator shall examine the flaw remediation - procedures to determine that the application of these - procedures would identify the status of finding a - correction to each security flaw. - - The flaw remediation procedures identify the different - stages of security flaws. This differentiation includes - at least: suspected security flaws that have been - reported, suspected security flaws that have been - confirmed to be security flaws, and security flaws whose - solutions have been implemented. It is permissible that - additional stages (e.g. flaws that have been reported - but not yet investigated, flaws that are under - investigation, security flaws for which a solution has - been found but not yet implemented) be included. - - - - - The evaluator shall check the flaw remediation - procedures to determine that the application of these - procedures would identify the corrective action for each - security flaw. - - Corrective action may consist of a - repair to the hardware, firmware, or software portions - of the TOE, a modification of TOE guidance, or - both. Corrective action that constitutes modifications - to TOE guidance (e.g. details of procedural measures to - be taken to obviate the security flaw) includes both - those measures serving as only an interim solution - (until the repair is issued) as well as those serving as - a permanent solution (where it is determined that the - procedural measure is the best solution). - - If the source of the security flaw is a documentation - error, the corrective action consists of an update of - the affected TOE guidance. If the corrective action is a - procedural measure, this measure will include an update - made to the affected TOE guidance to reflect these - corrective procedures. - - - - - The evaluator shall examine the flaw remediation - procedures documentation to determine that it describes - a means of providing the TOE users with the necessary - information on each security flaw. - - The necessary information about each - security flaw consists of its description (not - necessarily at the same level of detail as that provided - as part of work unit ), the prescribed corrective action, - and any associated guidance on implementing the - correction. - - TOE users may be provided with such information, - correction, and documentation updates in any of several - ways, such as their posting to a website, their being - sent to TOE users, or arrangements made for the - developer to install the correction. In cases where the - means of providing this information requires action to - be initiated by the TOE user, the evaluator examines any - TOE guidance to ensure that it contains instructions for - retrieving the information. - - The only metric for assessing the adequacy of the method - used for providing the information, corrections and - guidance is that there be a reasonable expectation that - TOE users can obtain or receive it. For example, - consider the method of dissemination where the requisite - data is posted to a website for one month, and the TOE - users know that this will happen and when this will - happen. This may not be especially reasonable or - effective (as, say, a permanent posting to the website), - yet it is feasible that the TOE user could obtain the - necessary information. On the other hand, if the - information were posted to the website for only one - hour, yet TOE users had no way of knowing this or when - it would be posted, it is infeasible that they would - ever get the necessary information. - - - - - - - - In order for the developer to be able to act appropriately - upon security flaw reports from TOE users, and to know to - whom to send corrective fixes, TOE users need to - understand how to submit security flaw reports to the - developer. Flaw remediation guidance from the developer to - the TOE user ensures that TOE users are aware of this - important information. - - - - The objective of this sub-activity is to determine whether - the developer has established flaw remediation procedures - that describe the tracking of security flaws, the - identification of corrective actions, and the distribution - of corrective action information to TOE - users. Additionally, this sub-activity determines whether - the developer's procedures provide for the corrections of - security flaws, for the receipt of flaw reports from TOE - users, and for assurance that the corrections introduce no - new security flaws. - - In order for the developer to be able to act appropriately - upon security flaw reports from TOE users, TOE users need - to understand how to submit security flaw reports to the - developer, and developers need to know how to receive - these reports. Flaw remediation guidance addressed to the - TOE user ensures that TOE users are aware of how to - communicate with the developer; flaw remediation - procedures describe the developer's role is such - communication - - - - The evaluation evidence for this sub-activity is: - - - the flaw remediation procedures documentation; - - - flaw remediation guidance documentation. - - - - - The developer shall document and provide flaw remediation procedures - addressed to TOE developers. - - - The developer shall establish a procedure for accepting and - acting upon all reports of security flaws and requests for - corrections to those flaws. - - - The developer shall provide flaw remediation guidance - addressed to TOE users. - - - The flaw remediation procedures documentation shall describe - the procedures used to track all reported security flaws in - each release of the TOE. - - - 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. - - - The flaw remediation procedures shall require that - corrective actions be identified for each of the security - flaws. - - - The flaw remediation procedures documentation shall describe - the methods used to provide flaw information, corrections - and guidance on corrective actions to TOE users. - - - The flaw remediation procedures shall describe a means by - which the developer receives from TOE users reports and - enquiries of suspected security flaws in the TOE. - - - The procedures for processing reported security flaws shall - ensure that any reported flaws are remediated and the - remediation procedures issued to TOE users. - - - The procedures for processing reported security flaws shall - provide safeguards that any corrections to these security - flaws do not introduce any new flaws. - - - The flaw remediation guidance shall describe a means by - which TOE users report to the developer any suspected - security flaws in the TOE. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the flaw remediation - procedures documentation to determine that it describes - the procedures used to track all reported security flaws - in each release of the TOE. - - The procedures describe the actions that are taken by - the developer from the time each suspected security flaw - is reported to the time that it is resolved. This - includes the flaw's entire time frame, from initial - detection through ascertaining that the flaw is a - security flaw, to resolution of the security - flaw. - - If a flaw is discovered not to be security-relevant, - there is no need (for the purposes of the requirements) for the flaw - remediation procedures to track it further; only that - there be an explanation of why the flaw is not - security-relevant. - - - - - The evaluator shall examine the flaw remediation - procedures to determine that the application of these - procedures would produce a description of each security - flaw in terms of its nature and effects. - - The procedures identify the actions that are taken by - the developer to describe the nature and effects of each - security flaw in sufficient detail to be able to - reproduce it. The description of the nature of a - security flaw addresses whether it is an error in the - documentation, a flaw in the design of the TSF, a flaw - in the implementation of the TSF, etc. The description - of the security flaw's effects identifies the portions - of the TSF that are affected and how those portions are - affected. For example, a security flaw in the - implementation might be found that affects the - identification and authentication enforced by the TSF by - permitting authentication with the password - ``BACKDOOR''. - - - - - The evaluator shall examine the flaw remediation - procedures to determine that the application of these - procedures would identify the status of finding a - correction to each security flaw. - - The flaw remediation procedures identify the different - stages of security flaws. This differentiation includes - at least: suspected security flaws that have been - reported, suspected security flaws that have been - confirmed to be security flaws, and security flaws whose - solutions have been implemented. It is permissible that - additional stages (e.g. flaws that have been reported - but not yet investigated, flaws that are under - investigation, security flaws for which a solution has - been found but not yet implemented) be included. - - - - - The evaluator shall check the flaw remediation - procedures to determine that the application of these - procedures would identify the corrective action for each - security flaw. - - Corrective action may consist of a - repair to the hardware, firmware, or software portions - of the TOE, a modification of TOE guidance, or - both. Corrective action that constitutes modifications - to TOE guidance (e.g. details of procedural measures to - be taken to obviate the security flaw) includes both - those measures serving as only an interim solution - (until the repair is issued) as well as those serving as - a permanent solution (where it is determined that the - procedural measure is the best solution). - - If the source of the security flaw is a documentation - error, the corrective action consists of an update of - the affected TOE guidance. If the corrective action is a - procedural measure, this measure will include an update - made to the affected TOE guidance to reflect these - corrective procedures. - - - - - The evaluator shall examine the flaw remediation - procedures documentation to determine that it describes - a means of providing the TOE users with the necessary - information on each security flaw. - - The necessary information about each - security flaw consists of its description (not - necessarily at the same level of detail as that provided - as part of work unit ), the prescribed corrective action, - and any associated guidance on implementing the - correction. - - TOE users may be provided with such information, - correction, and documentation updates in any of several - ways, such as their posting to a website, their being - sent to TOE users, or arrangements made for the - developer to install the correction. In cases where the - means of providing this information requires action to - be initiated by the TOE user, the evaluator examines any - TOE guidance to ensure that it contains instructions for - retrieving the information. - - The only metric for assessing the adequacy of the method - used for providing the information, corrections and - guidance is that there be a reasonable expectation that - TOE users can obtain or receive it. For example, - consider the method of dissemination where the requisite - data is posted to a website for one month, and the TOE - users know that this will happen and when this will - happen. This may not be especially reasonable or - effective (as, say, a permanent posting to the website), - yet it is feasible that the TOE user could obtain the - necessary information. On the other hand, if the - information were posted to the website for only one - hour, yet TOE users had no way of knowing this or when - it would be posted, it is infeasible that they would - ever get the necessary information. - - - - - The evaluator shall examine the flaw remediation - procedures to determine that they describe procedures - for the developer to accept reports of security flaws or - requests for corrections to such flaws. - - The procedures ensure that TOE users have a means by - which they can communicate with the TOE developer. By - having a means of contact with the developer, the user - can report security flaws, enquire about the status of - security flaws, or request corrections to flaws. This - means of contact may be part of a more general contact - facility for reporting non-security related - problems. - - The use of these procedures is not restricted to TOE - users; however, only the TOE users are actively supplied - with the details of these procedures. Others who might - have access to or familiarity with the TOE can use the - same procedures to submit reports to the developer, who - is then expected to process them. Any means of - submitting reports to the developer, other than those - identified by the developer, are beyond the scope of - this work unit; reports generated by other means need - not be addressed. - - - - - The evaluator shall examine the flaw remediation - procedures to determine that the application of these - procedures would help to ensure every reported flaw is - corrected. - - The flaw remediation procedures cover not only those - security flaws discovered and reported by developer - personnel, but also those reported by TOE users. The - procedures are sufficiently detailed so that they - describe how it is ensured that each reported security - flaw is corrected. The procedures contain reasonable - steps that show progress leading to the eventual, - inevitable resolution. - - The procedures describe the process that is taken from - the point at which the suspected security flaw is - determined to be a security flaw to the point at which - it is resolved. - - - - The evaluator shall examine the flaw remediation - procedures to determine that the application of these - procedures would help to ensure that the TOE users are - issued remediation procedures for each security - flaw. - - The procedures describe the process that is taken from - the point at which a security flaw is resolved to the - point at which the remediation procedures are - provided. The procedures for delivering corrective - actions should be consistent with the security - objectives; they need not necessarily be identical to - the procedures used for delivering the TOE, as - documented to meet , if - included in the assurance requirements. For example, if - the hardware portion of a TOE were originally delivered - by bonded courier, updates to hardware resulting from - flaw remediation would likewise be expected to be - distributed by bonded courier. Updates unrelated to flaw - remediation would follow the procedures set forth in the - documentation meeting the requirements. - - - - The evaluator shall examine the flaw remediation - procedures to determine that the application of these - procedures would result in safeguards that the potential - correction contains no adverse effects. - - Through analysis, testing, or a combination of the two, - the developer may reduce the likelihood that adverse - effects will be introduced when a security flaw is - corrected. The evaluator assesses whether the procedures - provide detail in how the necessary mix of analysis and - testing actions is to be determined for a given - correction. - - The evaluator also determines that, for instances where - the source of the security flaw is a documentation - problem, the procedures include the means of - safeguarding against the introduction of contradictions - with other documentation. - - - - - The evaluator shall examine the flaw remediation - guidance to determine that the application of these - procedures would result in a means for the TOE user to - provide reports of suspected security flaws or requests - for corrections to such flaws. - - The guidance ensures that TOE users have a means by - which they can communicate with the TOE developer. By - having a means of contact with the developer, the user - can report security flaws, enquire about the status of - security flaws, or request corrections to flaws. - - - - - - - - In order for the developer to be able to act appropriately - upon security flaw reports from TOE users, and to know to - whom to send corrective fixes, TOE users need to - understand how to submit security flaw reports to the - developer, and how to register themselves with the - developer so that they may receive these corrective - fixes. Flaw remediation guidance from the developer to the - TOE user ensures that TOE users are aware of this - important information. - - - - The objective of this sub-activity is to determine whether - the developer has established flaw remediation procedures - that describe the tracking of security flaws, the - identification of corrective actions, and the distribution - of corrective action information to TOE - users. Additionally, this sub-activity determines whether - the developer's procedures provide for the corrections of - security flaws, for the receipt of flaw reports from TOE - users, for assurance that the corrections introduce no new - security flaws, for the establishment of a point of - contact for each TOE user, and for the timely issue of - corrective actions to TOE users. - - In order for the developer to be able to act appropriately - upon security flaw reports from TOE users, TOE users need - to understand how to submit security flaw reports to the - developer, and developers need to know how to receive - these reports. Flaw remediation guidance addressed to the - TOE user ensures that TOE users are aware of how to - communicate with the developer; flaw remediation - procedures describe the developer's role is such - communication. - - - - The evaluation evidence for this sub-activity is: - - - the flaw remediation procedures documentation; - - - flaw remediation guidance documentation. - - - - - The developer shall document and provide flaw remediation procedures - addressed to TOE developers. - - - The developer shall establish a procedure for accepting and - acting upon all reports of security flaws and requests for - corrections to those flaws. - - - The developer shall provide flaw remediation guidance - addressed to TOE users. - - - The flaw remediation procedures documentation shall describe - the procedures used to track all reported security flaws in - each release of the TOE. - - - 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. - - - The flaw remediation procedures shall require that - corrective actions be identified for each of the security - flaws. - - - The flaw remediation procedures documentation shall describe - the methods used to provide flaw information, corrections - and guidance on corrective actions to TOE users. - - - The flaw remediation procedures shall describe a means by - which the developer receives from TOE users reports and - enquiries of suspected security flaws in the TOE. - - - The flaw remediation procedures shall include a procedure - requiring timely response and the automatic distribution of - security flaw reports and the associated corrections to - registered users who might be affected by the security flaw. - - - The procedures for processing reported security flaws shall - ensure that any reported flaws are remediated and the - remediation procedures issued to TOE users. - - - The procedures for processing reported security flaws shall - provide safeguards that any corrections to these security - flaws do not introduce any new flaws. - - - The flaw remediation guidance shall describe a means by - which TOE users report to the developer any suspected - security flaws in the TOE. - - - The flaw remediation guidance shall describe a means by - which TOE users may register with the developer, to be - eligible to receive security flaw reports and corrections. - - - The flaw remediation guidance shall identify the specific - points of contact for all reports and enquiries about - security issues involving the TOE. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the flaw remediation - procedures documentation to determine that it describes - the procedures used to track all reported security flaws - in each release of the TOE. - - The procedures describe the actions that are taken by - the developer from the time each suspected security flaw - is reported to the time that it is resolved. This - includes the flaw's entire time frame, from initial - detection through ascertaining that the flaw is a - security flaw, to resolution of the security - flaw. - - If a flaw is discovered not to be security-relevant, - there is no need (for the purposes of the requirements) for the flaw - remediation procedures to track it further; only that - there be an explanation of why the flaw is not - security-relevant. - - - - - The evaluator shall examine the flaw remediation - procedures to determine that the application of these - procedures would produce a description of each security - flaw in terms of its nature and effects. - - The procedures identify the actions that are taken by - the developer to describe the nature and effects of each - security flaw in sufficient detail to be able to - reproduce it. The description of the nature of a - security flaw addresses whether it is an error in the - documentation, a flaw in the design of the TSF, a flaw - in the implementation of the TSF, etc. The description - of the security flaw's effects identifies the portions - of the TSF that are affected and how those portions are - affected. For example, a security flaw in the - implementation might be found that affects the - identification and authentication enforced by the TSF by - permitting authentication with the password - ``BACKDOOR''. - - - - - The evaluator shall examine the flaw remediation - procedures to determine that the application of these - procedures would identify the status of finding a - correction to each security flaw. - - The flaw remediation procedures identify the different - stages of security flaws. This differentiation includes - at least: suspected security flaws that have been - reported, suspected security flaws that have been - confirmed to be security flaws, and security flaws whose - solutions have been implemented. It is permissible that - additional stages (e.g. flaws that have been reported - but not yet investigated, flaws that are under - investigation, security flaws for which a solution has - been found but not yet implemented) be included. - - - - - The evaluator shall check the flaw remediation - procedures to determine that the application of these - procedures would identify the corrective action for each - security flaw. - - Corrective action may consist of a - repair to the hardware, firmware, or software portions - of the TOE, a modification of TOE guidance, or - both. Corrective action that constitutes modifications - to TOE guidance (e.g. details of procedural measures to - be taken to obviate the security flaw) includes both - those measures serving as only an interim solution - (until the repair is issued) as well as those serving as - a permanent solution (where it is determined that the - procedural measure is the best solution). - - If the source of the security flaw is a documentation - error, the corrective action consists of an update of - the affected TOE guidance. If the corrective action is a - procedural measure, this measure will include an update - made to the affected TOE guidance to reflect these - corrective procedures. - - - - - The evaluator shall examine the flaw remediation - procedures documentation to determine that it describes - a means of providing the TOE users with the necessary - information on each security flaw. - - The necessary information about each - security flaw consists of its description (not - necessarily at the same level of detail as that provided - as part of work unit ), the prescribed corrective action, - and any associated guidance on implementing the - correction. - - TOE users may be provided with such information, - correction, and documentation updates in any of several - ways, such as their posting to a website, their being - sent to TOE users, or arrangements made for the - developer to install the correction. In cases where the - means of providing this information requires action to - be initiated by the TOE user, the evaluator examines any - TOE guidance to ensure that it contains instructions for - retrieving the information. - - The only metric for assessing the adequacy of the method - used for providing the information, corrections and - guidance is that there be a reasonable expectation that - TOE users can obtain or receive it. For example, - consider the method of dissemination where the requisite - data is posted to a website for one month, and the TOE - users know that this will happen and when this will - happen. This may not be especially reasonable or - effective (as, say, a permanent posting to the website), - yet it is feasible that the TOE user could obtain the - necessary information. On the other hand, if the - information were posted to the website for only one - hour, yet TOE users had no way of knowing this or when - it would be posted, it is infeasible that they would - ever get the necessary information. - - For TOE users who register with the developer (see work - unit ), the - passive availability of this information is not - sufficient. Developers must actively send the - information (or a notification of its availability) to - registered TOE users. - - - - - The evaluator shall examine the flaw remediation - procedures to determine that the application of these - procedures would result in a means for the developer to - receive from TOE user reports of suspected security - flaws or requests for corrections to such flaws. - - The procedures ensure that TOE users have a means by - which they can communicate with the TOE developer. By - having a means of contact with the developer, the user - can report security flaws, enquire about the status of - security flaws, or request corrections to flaws. This - means of contact may be part of a more general contact - facility for reporting non-security related - problems. - - The use of these procedures is not restricted to TOE - users; however, only the TOE users are actively supplied - with the details of these procedures. Others who might - have access to or familiarity with the TOE can use the - same procedures to submit reports to the developer, who - is then expected to process them. Any means of - submitting reports to the developer, other than those - identified by the developer, are beyond the scope of - this work unit; reports generated by other means need - not be addressed. - - - - - The evaluator shall examine the flaw remediation - procedures to determine that the application of these - procedures would result in a timely means of providing - the registered TOE users who might be affected with - reports about, and associated corrections to, each - security flaw. - - The issue of timeliness applies to the issuance of both - security flaw reports and the associated - corrections. However, these need not be issued at the - same time. It is recognised that flaw reports should be - generated and issued as soon as an interim solution is - found, even if that solution is as drastic as turn off - the TOE. Likewise, when a more permanent (and less - drastic) solution is found, it should be issued without - undue delay. - - It is unnecessary to restrict the recipients of the - reports and associated corrections to only those TOE - users who might be affected by the security flaw; it is - permissible that all TOE users be given such reports and - corrections for all security flaws, provided such is - done in a timely manner. - - - - The evaluator shall examine the flaw remediation - procedures to determine that the application of these - procedures would result in automatic distribution of the - reports and associated corrections to the registered TOE - users who might be affected. - - Automatic distribution does not mean - that human interaction with the distribution method is - not permitted. In fact, the distribution method could - consist entirely of manual procedures, perhaps through a - closely monitored procedure with prescribed escalation - upon the lack of issue of reports or corrections. - - It is unnecessary to restrict the recipients of the - reports and associated corrections to only those TOE - users who might be affected by the security flaw; it is - permissible that all TOE users be given such reports and - corrections for all security flaws, provided such is - done automatically. - - - - - The evaluator shall examine the flaw remediation procedures to - determine that the application of these procedures would help to - ensure that every reported flaw is corrected. - - The flaw remediation procedures cover not only those - security flaws discovered and reported by developer - personnel, but also those reported by TOE users. The - procedures are sufficiently detailed so that they - describe how it is ensured that each reported security - flaw is remediated. The procedures contain reasonable - steps that show progress leading to the eventual, - inevitable resolution. - - The procedures describe the process that is taken from - the point at which the suspected security flaw is - determined to be a security flaw to the point at which - it is resolved. - - - - - The evaluator shall examine the flaw remediation - procedures to determine that the application of these - procedures would help to ensure that the TOE users are - issued remediation procedures for each security - flaw. - The procedures describe the process that is taken - from the point at which a security flaw is resolved to - the point at which the remediation procedures are - provided. The procedures for delivering remediation - procedures should be consistent with the security - objectives; they need not necessarily be identical to - the procedures used for delivering the TOE, as - documented to meet , if - included in the assurance requirements. For example, if - the hardware portion of a TOE were originally delivered - by bonded courier, updates to hardware resulting from - flaw remediation would likewise be expected to be - distributed by bonded courier. Updates unrelated to flaw - remediation would follow the procedures set forth in the - documentation meeting the requirements. - - - - The evaluator shall examine the flaw remediation - procedures to determine that the application of these - procedures would result in safeguards that the potential - correction contains no adverse effects. - - Through analysis, testing, or a combination of the two, - the developer may reduce the likelihood that adverse - effects will be introduced when a security flaw is - corrected. The evaluator assesses whether the procedures - provide detail in how the necessary mix of analysis and - testing actions is to be determined for a given - correction. - - The evaluator also determines that, for instances where - the source of the security flaw is a documentation - problem, the procedures include the means of - safeguarding against the introduction of contradictions - with other documentation. - - - - - The evaluator shall examine the flaw remediation - guidance to determine that the application of these - procedures would result in a means for the TOE user to - provide reports of suspected security flaws or requests - for corrections to such flaws. - - The guidance ensures that TOE users have a means by - which they can communicate with the TOE developer. By - having a means of contact with the developer, the user - can report security flaws, enquire about the status of - security flaws, or request corrections to flaws. - - - - - The evaluator shall examine the flaw remediation - guidance to determine that it describes a means of - enabling the TOE users to register with the - developer. - - Enabling the TOE users to register with the - developer simply means having a way for each - TOE user to provide the developer with a point of - contact; this point of contact is to be used to - provide the TOE user with information related to - security flaws that might affect that TOE user, along - with any corrections to the security flaw. Registering - the TOE user may be accomplished as part of the - standard procedures that TOE users undergo to identify - themselves to the developer, for the purposes of - registering a software licence, or for obtaining - update and other useful information. - - There need not be one registered TOE user per - installation of the TOE; it would be sufficient if there - were one registered TOE user for an organisation. For - example, a corporate TOE user might have a centralized - acquisition office for all of its sites. In this case, - the acquisition office would be a sufficient point of - contact for all of that TOE user's sites, so that all of - the TOE user's installations of the TOE have a - registered point of contact. - - In either case, it must be possible to associate each - TOE that is delivered with an organisation in order to - ensure that there is a registered user for each TOE. For - organisations that have many different addresses, this - assures that there will be no user who is erroneously - presumed to be covered by a registered TOE user. - It should be noted that TOE users need not - register; they must only be provided with a means of - doing so. However, users who choose to register must be - directly sent the information (or a notification of its - availability). - - - - The evaluator shall examine the flaw remediation - guidance to determine that it identifies specific points - of contact for user reports and enquiries about security - issues involving the TOE. - - The guidance includes a means whereby registered TOE - users can interact with the developer to report - discovered security flaws in the TOE or to make - enquiries regarding discovered security flaws in the - TOE. - - - - - - - - Poorly controlled development and maintenance of the TOE can - result in a TOE that does not meet all of its - SFRs. Therefore, it is important that a model for the - development and maintenance of a TOE be established as early - as possible in the TOE's life-cycle. - - Using a model for the development and maintenance of a TOE - does not guarantee that the TOE meets all of its SFRs. It is - possible that the model chosen will be insufficient or - inadequate and therefore no benefits in the quality of the - TOE can be observed. Using a life-cycle model that has been - approved by a group of experts (e.g. academic experts, - standards bodies) improves the chances that the development - and maintenance models will contribute to the TOE meeting - its SFRs. The use of a life-cycle model including some - quantitative valuation adds further assurance in the overall - quality of the TOE development process. - - - - Life-cycle definition establishes that the engineering - practises used by a developer to produce the TOE include the - considerations and activities identified in the development - process and operational support requirements. Confidence in - the correspondence between the requirements and the TOE is - greater when quality control and the production of evidence - are done on a regular basis as an integral part of the - development process and operational support activities. It - is not the intent of this component to dictate any specific - development process. - - - - The components in this family are levelled on the basis of - increasing requirements for measurability of the life-cycle - model, and for compliance with that model. - - - - A life-cycle model encompasses the procedures, tools and - techniques used to develop and maintain the TOE. Aspects of - the process that may be covered by such a model include - design methods, review procedures, project management - controls, change control procedures, test methods and - acceptance procedures. An effective life-cycle model will - address these aspects of the development and maintenance - process within an overall management structure that assigns - responsibilities and monitors progress. - - There are different types of acceptance situations that are - dealt with at different locations in the criteria: - acceptance of parts delivered by subcontractors - (``integration'') should be treated in this family , acceptance subsequent to - internal transportations in , acceptance of parts into the CM system in - , and acceptance of the - delivered TOE by the consumer in . The first three types may overlap. - - Although life-cycle definition deals with the maintenance of - the TOE and hence with aspects becoming relevant after the - completion of the evaluation, its evaluation adds assurance - through an analysis of the life-cycle information for the - TOE provided at the time of the evaluation. - - A life-cycle model provides for the necessary control over - the development and maintenance of the TOE, if the model - enables sufficient minimisation of the danger that the TOE - will not meet its security requirement. - - A measurable life-cycle model is a model using some - quantitative valuation (arithmetic parameters and/or - metrics) of the managed product in order to measure - development properties of the product. Typical metrics are - source code complexity metrics, defect density (errors per - size of code) or mean time to failure. For the security - evaluation all those metrics are of relevance, which are - used to increase quality by decreasing the probability of - faults and thereby in turn increasing assurance in the - security of the TOE. - - One should take into account that there exist standardised - life cycle models on the one hand (like the waterfall model) - and standardised metrics on the other hand (like error - density), which may be combined. The CC does not require the - life cycle to follow exactly one standard defining both - aspects. - - - - The objective of this sub-activity is to determine - whether the developer has used a documented model of the - TOE life-cycle. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the life-cycle definition documentation. - - - - - The developer shall establish a life-cycle model to be used - in the development and maintenance of the TOE. - - - The developer shall provide life-cycle definition - documentation. - - - The life-cycle definition documentation shall describe the - model used to develop and maintain the TOE. - - - The life-cycle model shall provide for the necessary control - over the development and maintenance of the TOE. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the documented description - of the life-cycle model used to determine that it covers - the development and maintenance process. - - The description of the life-cycle model should include: - - - information on the life-cycle phases of the TOE and - the boundaries between the subsequent phases; - - - information on the procedures, tools and techniques - used by the developer (e.g. for design, coding, - testing, bug-fixing); - - - overall management structure governing the - application of the procedures (e.g. an - identification and description of the individual - responsibilities for each of the procedures required - by the development and maintenance process covered - by the life-cycle model); - - - information on which parts of the TOE are delivered - by subcontractors, if subcontractors are involved. - - - - does not require the - model used to conform to any standard life-cycle - model. - - - - - The evaluator shall examine the life-cycle model to - determine that use of the procedures, tools and - techniques described by the life-cycle model will make - the necessary positive contribution to the development - and maintenance of the TOE. - - The information provided in the life-cycle model gives - the evaluator assurance that the development and - maintenance procedures adopted would minimise the - likelihood of security flaws. For example, if the - life-cycle model described the review process, but did - not make provision for recording changes to components, - then the evaluator may be less confident that errors - will not be introduced into the TOE. The evaluator may - gain further assurance by comparing the description of - the model against an understanding of the development - process gleaned from performing other evaluator actions - relating to the TOE development (e.g. those covered - under the ). - Identified deficiencies in the life-cycle model will be - of concern if they might reasonably be expected to give - rise to the introduction of flaws into the TOE, either - accidentally or deliberately. - - The CC does not mandate any particular development - approach, and each should be judged on merit. For - example, spiral, rapid-prototyping and waterfall - approaches to design can all be used to produce a - quality TOE if applied in a controlled - environment. - - - - - - - The objective of this sub-activity is to determine - whether the developer has used a documented and measurable - model of the TOE life-cycle. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the life-cycle definition documentation; - - - information about the standard used; - - - the life-cycle output documentation. - - - - - The developer shall establish a life-cycle model to be used - in the development and maintenance of the TOE, that is based - on a measurable life-cycle model. - - - The developer shall provide life-cycle definition - documentation. - - - The developer shall measure the TOE development using the - measurable life-cycle model. - - - The developer shall provide life-cycle output documentation. - - - 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 quality of the TOE and/or its development. - - - The life-cycle model shall provide for the necessary control - over the development and maintenance of the TOE. - - - The life-cycle output documentation shall provide the - results of the measurements of the TOE development using the - measurable life-cycle model. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the documented description - of the life-cycle model used to determine that it covers - the development and maintenance process, including the - details of its arithmetic parameters and/or metrics used - to measure the TOE development. - - The description of the life-cycle model includes: - - information on the life-cycle phases of the TOE and the - boundaries between the subsequent phases; - - information on the procedures, tools and techniques used by - the developer (e.g. for design, coding, testing, - bug-fixing); - - overall management structure governing the application of - the procedures (e.g. an identification and description of - the individual responsibilities for each of the procedures - required by the development and maintenance process covered - by the life-cycle model); - - information on which parts of the TOE are delivered by - subcontractors, if subcontractors are involved; - - information on the parameters/metrics that are used to - measure the TOE development. Metrics standards typically - include guides for measuring and producing reliable products - and cover the aspects reliability, quality, performance, - complexity and cost. For the evaluation all those metrics - are of relevance, which are used to increase quality by - decreasing the probability of faults and thereby in turn - increase assurance in the security of the TOE. - - - - - - The evaluator shall examine the life-cycle model to - determine that use of the procedures, tools and - techniques described by the life-cycle model will make - the necessary positive contribution to the development - and maintenance of the TOE. - - The information provided in the life-cycle model gives - the evaluator assurance that the development and - maintenance procedures adopted would minimise the - likelihood of security flaws. For example, if the - life-cycle model described the review process, but did - not make provision for recording changes to components, - then the evaluator may be less confident that errors - will not be introduced into the TOE. The evaluator may - gain further assurance by comparing the description of - the model against an understanding of the development - process gleaned from performing other evaluator actions - relating to the TOE development (e.g. those covered - under the ). - Identified deficiencies in the life-cycle model will be - of concern if they might reasonably be expected to give - rise to the introduction of flaws into the TOE, either - accidentally or deliberately. - - The CC does not mandate any particular development - approach, and each should be judged on merit. For - example, spiral, rapid-prototyping and waterfall - approaches to design can all be used to produce a - quality TOE if applied in a controlled - environment. - - For the metrics/measurements used in the life-cycle - model, evidence has to be provided that shows how those - metrics/measurements usefully contribute to the - minimisation of the likelihood of flaws. This can be - viewed as the overall goal for measurement in an context. As a consequence the - metrics/measurements have to be selected based on their - capability to achieve that overall goal or contribute to - that. In the first place a metric/measure is suitable - with respect to if a - correlation between the metric/measure and the number of - flaws can be stated with a certain degree of - reliability. But also a metric/measure useful for - management purposes as for planning and monitoring the - TOE development are helpful since badly managed projects - are endangered to produce bad quality and to introduce - flaws. - - It may be possible to use metrics for quality - improvement, for which this use is not obvious. For - example a metric to estimate the expected cost of a - product development may help quality, if the developer - can show that this is used to provide an adequate budget - for development projects and that this helps to avoid - quality problems arising from resource shortages. - - It is not required that every single step in the life - cycle of the TOE is measurable. However the evaluator - should see from the description of the measures and - procedures that the metrics are appropriate to control - the overall quality of the TOE and to minimise possible - security flaws by this. - - - - - The evaluator shall examine the life-cycle output - documentation to determine that it provides the results - of the measurements of the TOE development using the - measurable life-cycle model. - - The results of the measurements and the life-cycle - progress of the TOE should be in accordance with the - life-cycle model. - - The output documentation not only includes numeric values of the - metrics but also documents actions taken as a result of the - measurements and in accordance with the model. For example there - may be a requirement that a certain design phase needs to be - repeated, if some error rates measured during testing are - outside of a defined threshold. In this case the documentation - should show that such action was taken, if indeed the thresholds - were not met. - - If the evaluation is conducted in parallel with the - development of the TOE it may be possible that quality - measurements have not been used in the past. In this - case the evaluator should use the documentation of the - planned procedures in order to gain confidence that - corrective actions are defined if results of quality - measurements deviate from some threshold. - - - - - - - - Tools and techniques is an aspect of selecting tools that - are used to develop, analyse and implement the TOE. It - includes requirements to prevent ill-defined, inconsistent - or incorrect development tools from being used to develop - the TOE. This includes, but is not limited to, programming - languages, documentation, implementation standards, and - other parts of the TOE such as supporting runtime - libraries. - - - - Tools and techniques addresses the need to define the - development tools being used to analyse and implement the - TOE. It includes requirements concerning the development - tools and implementation dependent options of those - tools. - - - - The components in this family are levelled on the basis of - increasing requirements on the description and scope of the - implementation standards and the documentation of - implementation-dependent options. - - - - There is a requirement for well-defined development - tools. These are tools that are clearly and completely - described. For example, programming languages and computer - aided design (CAD) systems that are based on a standard - published by standards bodies are considered to be - well-defined. Self-made tools would need further - investigation to clarify whether they are - well-defined. - - The requirement in is - especially applicable to programming languages so as to - ensure that all statements in the source code have an - unambiguous meaning. - - In and , implementation guidelines may be accepted - as an implementation standard if they have been approved by - some group of experts (e.g. academic experts, standards - bodies). Implementation standards are normally public, well - accepted and common practise in a specific industry, but - developer-specific implementation guidelines may also be - accepted as a standard; the emphasis is on the - expertise. - Tools and techniques distinguishes between the - implementation standards applied by the developer () and the implementation - standards for ``all parts of the TOE'' () which include third party software, - hardware, or firmware. The configuration list introduced in - requires that for each TSF - relevant configuration item to indicate if it has been - generated by the TOE developer or by third party - developers. - - - - - - The objective of this sub-activity is to determine whether - the developer has used well-defined development tools - (e.g. programming languages or computer-aided design (CAD) - systems) that yield consistent and predictable - results. - - - - This work may be performed in parallel with the evaluation - activities under , - specifically with regard to determining the use of - features in the tools that will affect the object code - (e.g. compilation options). - - - - The evaluation evidence for this sub-activity is: - - - the development tool documentation; - - - the subset of the implementation representation. - - - - - The developer shall provide the documentation identifying each development tool being - used for the TOE. - - - The developer shall document and provide the selected - implementation-dependent options of each development tool. - - - Each development tool used for implementation shall be - well-defined. - - - The documentation of each development tool shall - unambiguously define the meaning of all statements as well - as all conventions and directives used in the - implementation. - - - The documentation of each development tool shall - unambiguously define the meaning of all - implementation-dependent options. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the development tool - documentation provided to determine that each - development tools is well-defined. - - For example, a well-defined language, compiler or CAD - system may be considered to be one that conforms to a - recognised standard, such as the ISO standards. A - well-defined language is one that has a clear and - complete description of its syntax, and a detailed - description of the semantics of each construct. - - - - - The evaluator shall examine the documentation of each - development tool to determine that it unambiguously - defines the meaning of all statements as well as all - conventions and directives used in the - implementation. - - The development tool documentation (e.g. programming - language specifications and user manuals) should cover - all statements used in the implementation representation - of the TOE, and for each such statement should provide a - clear and unambiguous definition of the purpose and - effect of that statement. This work may be performed in - parallel with the evaluator's examination of the - implementation representation performed during the sub-activity. The key test the - evaluator should apply is whether or not the - documentation is sufficiently clear for the evaluator to - be able to understand the implementation - representation. The documentation should not assume (for - example) that the reader is an expert in the programming - language used. - - Reference to the use of a documented standard is an - acceptable approach to meet this requirement, provided - that the standard is available to the evaluator. Any - differences from the standard should be - documented. - - The critical test is whether the evaluator can - understand the TOE source code when performing source - code analysis covered in the sub-activity. However, the following - checklist can additionally be used in searching for - problem areas: - - - In the language definition, phrases such as ``the - effect of this construct is undefined'' and terms - such as ``implementation dependent'' or - ``erroneous'' may indicate ill-defined areas. - - - Aliasing (allowing the same piece of memory to be - referenced in different ways) is a common source of - ambiguity problems. - - - Exception handling (e.g. what happens after memory - exhaustion or stack overflow) is often poorly - defined. - - - - Most languages in common use, however well designed, - will have some problematic constructs. If the - implementation language is mostly well defined, but some - problematic constructs exist, then an inconclusive - verdict should be assigned, pending examination of the - source code. - - The evaluator should verify, during the examination of - source code, that any use of the problematic constructs - does not introduce vulnerabilities. The evaluator should - also ensure that constructs precluded by the documented - standard are not used. - - The development tool documentation should define all - conventions and directives used in the - implementation. - - - - - The evaluator shall examine the development tool - documentation to determine that it unambiguously defines - the meaning of all implementation-dependent - options. - - The documentation of software development tools should - include definitions of implementation-dependent options - that may affect the meaning of the executable code, and - those that are different from the standard language as - documented. Where source code is provided to the - evaluator, information should also be provided on - compilation and linking options used. - - The documentation for hardware design and development - tools should describe the use of all options that affect - the output from the tools (e.g. detailed hardware - specifications, or actual hardware). - - - - - - - - The objective of this sub-activity is to determine whether - the developer has used well-defined development tools - (e.g. programming languages or computer-aided design (CAD) - systems) that yield consistent and predictable results, - and whether implementation standards have been - applied. - - - - This work may be performed in parallel with the evaluation - activities under , - specifically with regard to determining the use of - features in the tools that will affect the object code - (e.g. compilation options). - - - - The evaluation evidence for this sub-activity is: - - - the development tool documentation; - - - the implementation standards description; - - - the provided implementation representation of the TSF. - - - - - The developer shall provide the documentation identifying each development tool being - used for the TOE. - - - The developer shall document and provide the selected - implementation-dependent options of each development tool. - - - The developer shall describe and provide the implementation standards - that are being applied by the developer. - - - Each development tool used for implementation shall be - well-defined. - - - The documentation of each development tool shall - unambiguously define the meaning of all statements as well - as all conventions and directives used in the - implementation. - - - The documentation of each development tool shall - unambiguously define the meaning of all - implementation-dependent options. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the development tool - documentation provided to determine that each - development tool is well-defined. - - For example, a well-defined language, compiler or CAD - system may be considered to be one that conforms to a - recognised standard, such as the ISO standards. A - well-defined language is one that has a clear and - complete description of its syntax, and a detailed - description of the semantics of each construct. - - - - - The evaluator shall examine the documentation of each - development tool to determine that it unambiguously - defines the meaning of all statements as well as all - conventions and directives used in the - implementation. - - The development tool documentation (e.g. programming - language specifications and user manuals) should cover - all statements used in the implementation representation - of the TOE, and for each such statement should provide a - clear and unambiguous definition of the purpose and - effect of that statement. This work may be performed in - parallel with the evaluator's examination of the - implementation representation performed during the sub-activity. The key test the - evaluator should apply is whether or not the - documentation is sufficiently clear for the evaluator to - be able to understand the implementation - representation. The documentation should not assume (for - example) that the reader is an expert in the programming - language used. - - Reference to the use of a documented standard is an - acceptable approach to meet this requirement, provided - that the standard is available to the evaluator. Any - differences from the standard should be - documented. - - The critical test is whether the evaluator can - understand the TOE source code when performing source - code analysis covered in the sub-activity. However, the following - checklist can additionally be used in searching for - problem areas: - - - In the language definition, phrases such as ``the - effect of this construct is undefined'' and terms - such as ``implementation dependent'' or - ``erroneous'' may indicate ill-defined areas. - - - Aliasing (allowing the same piece of memory to be - referenced in different ways) is a common source of - ambiguity problems. - - - Exception handling (e.g. what happens after memory - exhaustion or stack overflow) is often poorly - defined. - - - - Most languages in common use, however well designed, - will have some problematic constructs. If the - implementation language is mostly well defined, but some - problematic constructs exist, then an inconclusive - verdict should be assigned, pending examination of the - source code. - - The evaluator should verify, during the examination of - source code, that any use of the problematic constructs - does not introduce vulnerabilities. The evaluator should - also ensure that constructs precluded by the documented - standard are not used. - - The development tool documentation should define all - conventions and directives used in the - implementation. - - - - - The evaluator shall examine the development tool - documentation to determine that it unambiguously defines - the meaning of all implementation-dependent - options. - - The documentation of software development tools should - include definitions of implementation-dependent options - that may affect the meaning of the executable code, and - those that are different from the standard language as - documented. Where source code is provided to the - evaluator, information should also be provided on - compilation and linking options used. - - The documentation for hardware design and development - tools should describe the use of all options that affect - the output from the tools (e.g. detailed hardware - specifications, or actual hardware). - - - - The evaluator shall confirm that the implementation - standards have been applied. - - - The evaluator shall examine aspects of the - implementation process to determine that documented - implementation standards have been applied. - - This work unit requires the evaluator to analyse the - provided implementation representation of the TOE to - determine whether the documented implementation - standards have been applied. - - The evaluator should verify that constructs excluded by - the documented standard are not used. - - Additionally, the evaluator should verify the - developer's procedures which ensure the application of - the defined standards within the design and - implementation process of the TOE. Therefore, - documentary evidence should be supplemented by visiting - the development environment. A visit to the development - environment will allow the evaluator to: - - - observe the application of defined standards; - - examine documentary evidence of application of - procedures describing the use of defined - standards; - - interview development staff to check awareness of - the application of defined standards and - procedures. - - A development site visit is a useful means of gaining - confidence in the procedures being used. Any decision - not to make such a visit should be determined in - consultation with the evaluation authority. - - The evaluator compares the provided implementation - representation with the description of the applied - implementation standards and verifies their use. - At this level it is not required that the complete - provided implementation representation of the TSF is - based on implementation standards, but only those parts - that are developed by the TOE developer himself. The - evaluator may consult the configuration list required by - the to get the - information which parts are developed by the TOE - developer, and which by third party developers. - - If the referenced implementation standards are not - applied for at least parts of the provided implementation representation, - the evaluator action related to this work unit is assigned a fail verdict. - - Note that parts of the TOE which are not TSF relevant do - not need to be examined. - - This work unit may be performed in conjunction with the - evaluation activities under . - - - - - - - The objective of this sub-activity is to determine whether - the developer and his subcontractors have used - well-defined development tools (e.g. programming languages - or computer-aided design (CAD) systems) that yield - consistent and predictable results, and whether - implementation standards have been applied. - - - - This work may be performed in parallel with the evaluation - activities under , - specifically with regard to determining the use of - features in the tools that will affect the object code - (e.g. compilation options). - - - - The evaluation evidence for this sub-activity is: - - - the development tool documentation; - - - the implementation standards description; - - - the provided implementation representation of the TSF. - - - - - The developer shall provide the documentation identifying each development tool being - used for the TOE. - - - The developer shall document and provide the selected - implementation-dependent options of each development tool. - - - The developer shall describe and provide the implementation standards - that are being applied by the developer and by any - third-party providers for all parts of the TOE. - - - Each development tool used for implementation shall be - well-defined. - - - The documentation of each development tool shall - unambiguously define the meaning of all statements as well - as all conventions and directives used in the - implementation. - - - The documentation of each development tool shall - unambiguously define the meaning of all - implementation-dependent options. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the development tool - documentation provided to determine that each - development tool is well-defined. - - For example, a well-defined language, compiler or CAD - system may be considered to be one that conforms to a - recognised standard, such as the ISO standards. A - well-defined language is one that has a clear and - complete description of its syntax, and a detailed - description of the semantics of each construct. - - At this level, the documentation of development tools - used by third party contributors to the TOE has to be - included in the evaluator's examination. - - - - - The evaluator shall examine the documentation of each - development tool to determine that it unambiguously - defines the meaning of all statements as well as all - conventions and directives used in the - implementation. - - The development tool documentation (e.g. programming - language specifications and user manuals) should cover - all statements used in the implementation representation - of the TOE, and for each such statement should provide a - clear and unambiguous definition of the purpose and - effect of that statement. This work may be performed in - parallel with the evaluator's examination of the - implementation representation performed during the sub-activity. The key test the - evaluator should apply is whether or not the - documentation is sufficiently clear for the evaluator to - be able to understand the implementation - representation. The documentation should not assume (for - example) that the reader is an expert in the programming - language used. - - Reference to the use of a documented standard is an - acceptable approach to meet this requirement, provided - that the standard is available to the evaluator. Any - differences from the standard should be - documented. - - The critical test is whether the evaluator can - understand the TOE source code when performing source - code analysis covered in the sub-activity. However, the following - checklist can additionally be used in searching for - problem areas: - - - In the language definition, phrases such as ``the - effect of this construct is undefined'' and terms - such as ``implementation dependent'' or - ``erroneous'' may indicate ill-defined areas. - - - Aliasing (allowing the same piece of memory to be - referenced in different ways) is a common source of - ambiguity problems. - - - Exception handling (e.g. what happens after memory - exhaustion or stack overflow) is often poorly - defined. - - - - Most languages in common use, however well designed, - will have some problematic constructs. If the - implementation language is mostly well defined, but some - problematic constructs exist, then an inconclusive - verdict should be assigned, pending examination of the - source code. - - The evaluator should verify, during the examination of - source code, that any use of the problematic constructs - does not introduce vulnerabilities. The evaluator should - also ensure that constructs precluded by the documented - standard are not used. - - The development tool documentation should define all - conventions and directives used in the - implementation. - - At this level, the documentation of development tools - used by third party contributors to the TOE has to be - included in the evaluator's examination. - - - - - The evaluator shall examine the development tool - documentation to determine that it unambiguously defines - the meaning of all implementation-dependent - options. - - The documentation of software development tools should - include definitions of implementation-dependent options - that may affect the meaning of the executable code, and - those that are different from the standard language as - documented. Where source code is provided to the - evaluator, information should also be provided on - compilation and linking options used. - - The documentation for hardware design and development - tools should describe the use of all options that affect - the output from the tools (e.g. detailed hardware - specifications, or actual hardware). - - At this level, the documentation of development tools - used by third party contributors to the TOE has to be - included in the evaluator's examination. - - - - The evaluator shall confirm that the implementation - standards have been applied. - - - The evaluator shall examine aspects of the - implementation process to determine that documented - implementation standards have been applied. - - This work unit requires the evaluator to analyse the - provided implementation representation of the TOE to - determine whether the documented implementation - standards have been applied. - - The evaluator should verify that constructs excluded by - the documented standard are not used. - - Additionally, the evaluator should verify the - developer's procedures which ensure the application of - the defined standards within the design and - implementation process of the TOE. Therefore, - documentary evidence should be supplemented by visiting - the development environment. A visit to the development - environment will allow the evaluator to: - - - observe the application of defined standards; - - examine documentary evidence of application of - procedures describing the use of defined - standards; - - interview development staff to check awareness of - the application of defined standards and - procedures. - - A development site visit is a useful means of gaining - confidence in the procedures being used. Any decision - not to make such a visit should be determined in - consultation with the evaluation authority. - - The evaluator compares the provided implementation - representation with the description of the applied - implementation standards and verifies their use. - At this level it is required that the complete - provided implementation representation of the TSF is - based on implementation standards, including third party - contributions. This may require the evaluator to visit - the sites of contributors. The evaluator may consult the - configuration list required by the to see who has developed which part of - the TOE. - - Note that parts of the TOE which are not TSF relevant do - not need to be examined. - - This work unit may be performed in conjunction with the - evaluation activities under . - - - - - - - - - Evaluating a PP is required to demonstrate that the PP is - sound and internally consistent, and, if the PP is based on - one or more other PPs or on packages, that the PP is a correct - instantiation of these PPs and packages. These properties are - necessary for the PP to be suitable for use as the basis for - writing an ST or another PP. - - This Clause should be used in conjunction with Annexes , and - in CC - Part 1, as these Annexes clarify the concepts here and provide - many examples. - This standard defines two assurance packages for PP evaluation as follows: - Low assurance PP evaluation package;(Standard) PP evaluation package. - The assurance components for these packages are defined by table - .Assurance classAssurance familyAssurance componentLow Assurance PPPPProtection Profile evaluation11111112121PP assurance packages
- - - - Assurance class defines - requirements for the evaluation of an PP to demonstrate that - the PP is sound and internally consistent, and, if the PP is - based on one or more PPs or packages, that the PP is a correct - instantiation of these PPs and packages. - - - - This Clause describes the evaluation of a PP. The - requirements and methodology for PP evaluation are identical - for each PP evaluation, regardless of the EAL (or other set of - assurance requirements) that is claimed in the PP. The - evaluation methodology in this Clause is based on the - requirements on the PP as specified in CC Part 3 class . - - This Clause should be used in conjunction with Annexes , and - in CC - Part 1, as these Annexes clarify the concepts here and provide - many examples. - - - - The PP is the description of a TOE type. As such it is - expected to identify the security requirements that enforce - the defined OSPs and counter the defined threats under the - defined assumptions. - - Evaluating a PP is required to demonstrate that the PP is - sound and internally consistent, and, if the PP is based on - one or more PPs or packages, that the PP is a correct - instantiation of these PPs or packages. These properties are - necessary for the PP to be suitable for use as the basis for - an ST or another PP. - - - - - While evaluating a PP that is based on one or more certified - PPs, it may be possible to re-use the fact that these PPs were - certified. The potential for re-use of the result of a certified - PP is greater if the PP under evaluation does not add threats, - OSPs, security objectives and/or security requirements to those - of the PP that conformance is being claimed to. If the PP under - evaluation contains much more than the certified PP, re-use may - not be useful at all. - - The evaluator is allowed to re-use the PP evaluation results - by doing certain analyses only partially or not at all if - these analyses or parts thereof were already done as part of - the PP evaluation. While doing this, the evaluator should - assume that the analyses in the PP were performed - correctly. - - An example would be where the PP that conformance is being - claimed to contains a set of security requirements, and these - were determined to be internally consistent during its - evaluation. If the PP under evaluation uses the exact same - requirements, the consistency analysis does not have to be - repeated during the PP evaluation. If the PP under evaluation - adds one or more requirements, or performs operations on these - requirements, the analysis will have to be repeated. However, it - may be possible to save work in this consistency analysis by - using the fact that the original requirements are internally - consistent. If the original requirements are internally - consistent, the evaluator only has to determine that: - - the set of all new and/or changed requirements is internally - consistent, and - - the set of all new and/or changed requirements is consistent - with the original requirements. - - The evaluator notes in the ETR each case where analyses - are not done or only partially done for this reason. - - - - - - The objective of this family is to describe the TOE in a - narrative way. - - Evaluation of the PP introduction is required to demonstrate - that the PP is correctly identified, and that the PP - reference and TOE overview are consistent with each - other. - - - - The PP introduction describes the TOE in a narrative - way. - - - - - The objective of this sub-activity is to determine whether - the PP is correctly identified, and whether the PP - reference and TOE overview are consistent with each - other. - - - - The evaluation evidence for this sub-activity is: - - - the PP. - - - - - The developer shall provide a PP introduction. - - - The PP introduction shall contain a PP reference and a TOE - overview. - - - The PP reference shall uniquely identify the PP. - - - The TOE overview shall summarise the usage and major - security features of the TOE. - - - The TOE overview shall identify the TOE type. - - - The TOE overview shall identify any non-TOE - hardware/software/firmware available to the TOE. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the PP introduction - contains a PP reference and a TOE overview. - - - - - The evaluator shall examine the PP reference to - determine that it uniquely identifies the PP. - - The evaluator determines that the PP reference - identifies the PP itself, so that it may be easily - distinguished from other PPs, and that it also uniquely - identifies each version of the PP, e.g. by including a - version number and/or a date of publication. - - The PP should have some referencing system that is - capable of supporting unique references (e.g. use of - numbers, letters or dates). - - - - - The evaluator shall examine the TOE overview to - determine that it describes the usage and major security - features of the TOE. - - The TOE overview should briefly (i.e. several - paragraphs) describe the usage and major security - features expected of the TOE. The TOE overview should - enable consumers and potential TOE developers to quickly - determine whether the PP is of interest to them. - - The evaluator determines that the overview is clear - enough for TOE developers and consumers, and sufficient - to give them a general understanding of the intended - usage and major security features of the TOE. - - - - - The evaluator shall check that the TOE overview - identifies the TOE type. - - - - - The evaluator shall examine the TOE overview to - determine that it identifies any non-TOE - hardware/software/firmware available to the TOE. - - While some TOEs may run stand-alone, other TOEs (notably - software TOEs) need additional hardware, software or - firmware to operate. In this subclause of the PP, the PP - author lists all hardware, software, and/or firmware - that will be available for the TOE to run on. - - This identification should be detailed enough for - potential consumers and TOE developers to determine - whether their TOE may operate with the listed hardware, - software and firmware. - - - - - - - - The objective of this family is to determine the validity of - the conformance claim. In addition, this family specifies - how STs and other PPs are to claim conformance with the - PP. - - - - Conformance claims describes how the Protection Profile - conforms to CC Part 2 and CC Part 3, to Protection Profiles - and to packages. - - - - - - - - The objective of this sub-activity is to determine the - validity of various conformance claims. These describe how - the PP conforms to the CC, other PPs and packages. - - - - The evaluation evidence for this sub-activity is: - - - the PP; - - - the PP(s) that the PP claims conformance to; - - - the package(s) that the PP claims conformance to. - - - - - The developer shall provide a conformance claim. - - - The developer shall provide a conformance claim rationale. - - - The developer shall provide a conformance statement. - - - The conformance claim shall contain a CC conformance claim - that identifies the version of the CC to which the PP claims - conformance. - - - The CC conformance claim shall describe the conformance of - the PP to CC Part 2 as either CC Part 2 conformant or CC - Part 2 extended. - - - The CC conformance claim shall describe the conformance of - the PP to CC Part 3 as either CC Part 3 conformant or CC - Part 3 extended. - - - The CC conformance claim shall be consistent with the - extended components definition. - - - The conformance claim shall identify all PPs and security - requirement packages to which the PP claims conformance. - - - The conformance claim shall describe any conformance of the - PP to a package as either package-conformant or - package-augmented. - - - The conformance claim rationale shall demonstrate that the - TOE type is consistent with the TOE type in the PPs for - which conformance is being claimed. - - - The conformance claim rationale shall demonstrate that the - statement of the security problem definition is consistent - with the statement of the security problem definition in the - PPs for which conformance is being claimed. - - - The conformance claim rationale shall demonstrate that the - statement of security objectives is consistent with the - statement of security objectives in the PPs for which - conformance is being claimed. - - - The conformance claim rationale shall demonstrate that the - statement of security requirements is consistent with the - statement of security requirements in the PPs for which - conformance is being claimed. - - - The conformance statement shall describe the conformance - required of any PPs/STs to the PP as strict-PP or - demonstrable-PP conformance. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the conformance claim - contains a CC conformance claim that identifies the - version of the CC to which the PP claims - conformance. - - The evaluator determines that the CC conformance claim - identifies the version of the CC that was used to - develop this PP. This should include the version number - of the CC and, unless the International English version - of the CC was used, the language of the version of the - CC that was used. - - - - - The evaluator shall check that the CC conformance claim - states a claim of either CC Part 2 conformant or CC Part - 2 extended for the PP. - - - - - The evaluator shall check that the CC conformance claim - states a claim of either CC Part 3 conformant or CC Part - 3 extended for the PP. - - - - - The evaluator shall examine the CC conformance claim for - CC Part 2 to determine that it is consistent with the - extended components definition. - - If the CC conformance claim contains CC Part 2 - conformant, the evaluator determines that the extended - components definition does not define functional - components. - - If the CC conformance claim contains CC Part 2 extended, - the evaluator determines that the extended components - definition defines at least one extended functional - component. - - - - - The evaluator shall examine the CC conformance claim for - CC Part 3 to determine that it is consistent with the - extended components definition. - - If the CC conformance claim contains CC Part 3 - conformant, the evaluator determines that the extended - components definition does not define assurance - components. - - If the CC conformance claim contains CC Part 3 extended, - the evaluator determines that the extended components - definition defines at least one extended assurance - component. - - - - - The evaluator shall check that the conformance claim - contains a PP claim that identifies all PPs for which - the PP claims conformance. - - If the PP does not claim conformance to another PP, this - work unit is not applicable and therefore considered to - be satisfied. - The evaluator determines that any referenced PPs - are unambiguously identified (e.g. by title and version - number, or by the identification included in the - introduction of that PP). - - The evaluator is reminded that claims of partial - conformance to a PP are not permitted. - - - - - The evaluator shall check that the conformance claim - contains a package claim that identifies all packages to - which the PP claims conformance. - - If the PP does not claim conformance to a package, this - work unit is not applicable and therefore considered to - be satisfied. - - The evaluator determines that any referenced packages - are unambiguously identified (e.g. by title and version - number, or by the identification included in the - introduction of that package). - - The evaluator is reminded that claims of partial - conformance to a package are not permitted. - - - - - The evaluator shall check that, for each identified - package, the conformance claim states a claim of either - package-name conformant or package-name - augmented. - - If the PP does not claim conformance to a package, this - work unit is not applicable and therefore considered to - be satisfied. - - If the package conformance claim contains package-name - conformant, the evaluator determines that: - - - If the package is an assurance package, then the PP - contains all SARs included in the package, but no - additional SARs. - - - If the package is a functional package, then the PP - contains all SFRs included in the package, but no - additional SFRs. - - - - If the package conformance claim contains package-name - augmented, the evaluator determines that: - - - If the package is an assurance package, then the PP - contains all SARs included in the package, and at - least one additional SAR or at least one SAR that is - hierarchical to a SAR in the package. - - - If the package is a functional package, then the PP - contains all SFRs included in the package, and at - least one additional SFR or at least one SFR that is - hierarchical to a SFR in the package. - - - - - - - The evaluator shall examine the conformance claim - rationale to determine that the TOE type of the TOE is - consistent with all TOE types of the PPs. - - If the PP does not claim conformance to another PP, this - work unit is not applicable and therefore considered to - be satisfied. - - The relation between the types may be simple: a firewall - PP claiming conformance to another firewall PP, or more - complex: a smart card PP claiming conformance to a number - of other PPs at the same time: a PP for the integrated - circuit, a PP for the smart card OS, and two PPs for two - applications on the smart card. - - - - - The evaluator shall examine the conformance claim - rationale to determine that it demonstrates that the - statement of security problem definition is consistent, - as defined by the conformance statement of the PP, with - the statements of security problem definition stated in - the PPs to which conformance is being claimed. - - If the PP under evaluation does not claim conformance - with another PP, this work unit is not applicable and - therefore considered to be satisfied. - - If the PP to which conformance is being claimed does not - have a statement of security problem definition, this - work unit is not applicable and therefore considered to - be satisfied. - - If strict conformance is required by the PP to which - conformance is being claimed, no conformance claim - rationale is required. Instead, the evaluator determines - whether - - - the threats in the PP under evaluation are a - superset of or identical to the threats in the PP to - which conformance is being claimed; - - - the OSPs in the PP under evaluation are a superset - of or identical to the OSPs in the PP to which - conformance is being claimed; - - - the assumptions in the PP under evaluation are - identical to the assumptions in the PP to which conformance - is being claimed; - - - If demonstrable conformance is required by the PP to - which conformance is being claimed, the evaluator - examines the conformance claim rationale to determine - that it demonstrates that the statement of security - problem definition of the PP under evaluation is - equivalent or more restrictive than the statement of - security problem definition in the PP to which - conformance is being claimed. - For guidance on ``equivalent or more restrictive'' - see CC Part 1 . - - - - - The evaluator shall examine the conformance claim - rationale to determine that the statement of security - objectives is consistent, as defined by the conformance - statement of the PPs, with the statement of security - objectives in the PPs. - - If the PP does not claim conformance to another PP, this - work unit is not applicable and therefore considered to - be satisfied. - - If strict conformance is required by the PP to which - conformance is being claimed, no conformance claim - rationale is required. Instead, the evaluator determines - whether: - - The PP under evaluation contains all security - objectives for the TOE of the PP to which - conformance is being claimed. Note that it is - allowed for the PP under evaluation to have - additional security objectives for the TOE; - The PP under evaluation contains exactly all - security objectives for the operational environment - (with one exception in the next bullet). Note that - it is not allowed for the PP under evaluation to - have additional security objectives for the - operational environment; - The PP under evaluation may specify that certain - objectives for the operational environment in the PP - that conformance is being claimed to are security - objectives for the TOE in the PP under - evaluation. This is a valid exception to the - previous bullet. - - If demonstrable conformance is required by the PP to - which conformance is being claimed, the evaluator - examines the conformance claim rationale to determine - that it demonstrates that the statement of security - objectives of the PP under evaluation is equivalent or - more restrictive than the statement of security - objectives in the PP to which conformance is being - claimed. - For guidance on ``equivalent or more restrictive'' - see CC Part 1 . - - - - - The evaluator shall examine the PP to determine that it - is consistent, as defined by the conformance statement - of the PP, with all security requirements in the PPs for - which conformance is being claimed. - - If the PP does not claim conformance to another PP, this - work unit is not applicable and therefore considered to - be satisfied. - - If strict conformance is required by the PP to which - conformance is being claimed, no conformance claim - rationale is required. Instead, the evaluator determines - whether the statement of security requirements in the PP - under evaluation is a superset of or identical to the - statement of security requirements in the PP to which - conformance is being claimed (for strict - conformance). - - If demonstrable conformance is required by the PP to - which conformance is being claimed, the evaluator - examines the conformance claim rationale to determine - that it demonstrates that the statement of security - requirements of the PP under evaluation is equivalent or - more restrictive than the statement of security - requirements in the PP to which conformance is being - claimed. - For guidance on ``equivalent or more restrictive'' - see CC Part 1 . - - - - - - The evaluator shall check that the PP conformance - statement states a claim of strict-PP or demonstrable-PP - conformance. - - - - - - - - This part of the PP defines the security problem to be - addressed by the TOE and the operational environment of the - TOE. - - Evaluation of the security problem definition is required to - demonstrate that the security problem intended to be - addressed by the TOE and its operational environment, is - clearly defined. - - - - The security problem definition defines the problem - addressed by the TOE and the operational environment of the - TOE. - - - - - The objective of this sub-activity is to determine that - the security problem intended to be addressed by the TOE - and its operational environment is clearly defined. - - - - The evaluation evidence for this sub-activity is: - - - the PP. - - - - - The developer shall provide a security problem definition. - - - The security problem definition shall describe the threats. - - - All threats shall be described in terms of a threat agent, - an asset, and an adverse action. - - - The security problem definition shall describe the OSPs. - - - The security problem definition shall describe the - assumptions about the operational environment of the TOE. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the security problem - definition describes the threats. - - If all security objectives are derived from assumptions - and/or OSPs only, the statement of threats need not be - present in the PP. In this case, this work unit is not - applicable and therefore considered to be - satisfied. - - The evaluator determines that the security problem - definition describes the threats that must be countered - by the TOE and/or its operational environment. - - - - - The evaluator shall examine the security problem - definition to determine that all threats are described - in terms of a threat agent, an asset, and an adverse - action. - - If all security objectives are derived from assumptions - and OSPs only, the statement of threats need not be - present in the PP. In this case, this work unit is not - applicable and therefore considered to be - satisfied. - - Threat agents may be further described by aspects such - as expertise, resource, opportunity, and - motivation. - - - - - The evaluator shall examine that the security problem - definition describes the OSPs. - - If all security objectives are derived from assumptions - and/or threats only, OSPs need not be present in the - PP. In this case, this work unit is not applicable and - therefore considered to be satisfied. - - The evaluator determines that OSP statements are made in - terms of rules or guidelines that must be followed by - the TOE and/or its operational environment. - - The evaluator determines that each OSP is explained - and/or interpreted in sufficient detail to make it - clearly understandable; a clear presentation of policy - statements is necessary to permit tracing security - objectives to them. - - - - - The evaluator shall examine the security problem - definition to determine that it describes the - assumptions about the operational environment of the - TOE. - - If there are no assumptions, this work unit is not - applicable and is therefore considered to be - satisfied. - - The evaluator determines that each assumption about the - operational environment of the TOE is explained in - sufficient detail to enable consumers to determine that - their operational environment matches the assumption. If - the assumptions are not clearly understood, the end - result may be that the TOE is used in an operational - environment in which it will not function in a secure - manner. - - - - - - - - The security objectives are a concise statement of the - intended response to the security problem defined through - the family. - - Evaluation of the security objectives is required to - demonstrate that the security objectives adequately and - completely address the security problem definition and that - the division of this problem between the TOE and its - operational environment is clearly defined. - - - - The security objectives are a concise statement of the - intended response to the security problem. - - - - The components in this family are levelled on whether they - prescribe only security objectives for the operational - environment, or also security objectives for the TOE. - - - - - The objective of this sub-activity is to determine whether - the security objectives for the operational environment - are clearly defined. - - - - The evaluation evidence for this sub-activity is: - - - the PP. - - - - - The developer shall provide a statement of security - objectives. - - - The statement of security objectives shall describe the - security objectives for the operational environment. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the statement of security - objectives defines the security objectives for the - operational environment. - - The evaluator checks that the security objectives for - the operational environment are identified. - - - - - - - - - The objective of this sub-activity is to determine whether - the security objectives adequately and completely address - the security problem definition and that the division of - this problem between the TOE and its operational - environment is clearly defined. - - - - The evaluation evidence for this sub-activity is: - - - the PP. - - - - - The developer shall provide a statement of security - objectives. - - - The developer shall provide a security objectives rationale. - - - The statement of security objectives shall describe the - security objectives for the TOE and the security objectives - for the operational environment. - - - The security objectives rationale shall trace each security - objective for the TOE back to threats countered by that - security objective and OSPs enforced by that security - objective. - - - The security objectives rationale shall trace each security - objective for the operational environment back to threats - countered by that security objective, OSPs enforced by that - security objective, and assumptions upheld by that security - objective. - - - The security objectives rationale shall demonstrate that the - security objectives counter all threats. - - - The security objectives rationale shall demonstrate that the - security objectives enforce all OSPs. - - - The security objectives rationale shall demonstrate that the - security objectives for the operational environment uphold - all assumptions. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the statement of security - objectives defines the security objectives for the TOE - and the security objectives for the operational - environment. - - The evaluator checks that both categories of security - objectives are clearly identified and separated from the - other category. - - - - - The evaluator shall check that the security objectives - rationale traces all security objectives for the TOE - back to threats countered by the objectives and/or OSPs - enforced by the objectives. - - Each security objective for the TOE may trace back to - threats or OSPs, or a combination of threats and OSPs, - but it must trace back to at least one threat or - OSP. - - Failure to trace implies that either the security - objectives rationale is incomplete, the security problem - definition is incomplete, or the security objective for - the TOE has no useful purpose. - - - - - The evaluator shall check that the security objectives - rationale traces the security objectives for the - operational environment back to threats countered by - that security objective, to OSPs enforced by that - security objective, and to assumptions upheld by that - security objective. - - Each security objective for the operational environment - may trace back to threats, OSPs, assumptions, or a - combination of threats, OSPs and/or assumptions, but it - must trace back to at least one threat, OSP or - assumption. - - Failure to trace implies that either the security - objectives rationale is incomplete, the security problem - definition is incomplete, or the security objective for - the operational environment has no useful - purpose. - - - - - The evaluator shall examine the security objectives - rationale to determine that it justifies for each threat - that the security objectives are suitable to counter - that threat. - - If no security objectives trace back to the threat, the evaluator action - related to this work unit is assigned a fail verdict. - - The evaluator determines that the justification for a - threat shows whether the threat is removed, diminished - or mitigated. - - The evaluator determines that the justification for a - threat demonstrates that the security objectives are - sufficient: if all security objectives that trace back - to the threat are achieved, the threat is removed, - sufficiently diminished, or the effects of the threat - are sufficiently mitigated. - - Note that the tracings from security objectives to - threats provided in the security objectives rationale - may be part of a justification, but do not constitute a - justification by themselves. Even in the case that a - security objective is merely a statement reflecting the - intent to prevent a particular threat from being - realised, a justification is required, but this - justification may be as minimal as ``Security Objective - X directly counters Threat Y''. - - The evaluator also determines that each security - objective that traces back to a threat is necessary: - when the security objective is achieved it actually - contributes to the removal, diminishing or mitigation of - that threat. - - - - - The evaluator shall examine the security objectives - rationale to determine that for each OSP it justifies - that the security objectives are suitable to enforce - that OSP. - - If no security objectives trace back to the OSP, the evaluator action - related to this work unit is assigned a fail verdict. - - The evaluator determines that the justification for an - OSP demonstrates that the security objectives are - sufficient: if all security objectives that trace back - to that OSP are achieved, the OSP is enforced. - - The evaluator also determines that each security - objective that traces back to an OSP is necessary: when - the security objective is achieved it actually - contributes to the enforcement of the OSP. - - Note that the tracings from security objectives to OSPs - provided in the security objectives rationale may be - part of a justification, but do not constitute a - justification by themselves. In the case that a security - objective is merely a statement reflecting the intent to - enforce a particular OSP, a justification is required, - but this justification may be as minimal as ``Security - Objective X directly enforces OSP Y''. - - - - - The evaluator shall examine the security objectives - rationale to determine that for each assumption for the - operational environment it contains an appropriate - justification that the security objectives for the - operational environment are suitable to uphold that - assumption. - - If no security objectives for the operational environment trace back to the assumption, - the evaluator action related to this work unit is assigned a fail verdict. - - The evaluator determines that the justification for an - assumption about the operational environment of the TOE - demonstrates that the security objectives are - sufficient: if all security objectives for the - operational environment that trace back to that - assumption are achieved, the operational environment - upholds the assumption. - - The evaluator also determines that each security - objective for the operational environment that traces - back to an assumption about the operational environment - of the TOE is necessary: when the security objective is - achieved it actually contributes to the operational - environment upholding the assumption. - - Note that the tracings from security objectives for the - operational environment to assumptions provided in the - security objectives rationale may be a part of a - justification, but do not constitute a justification by - themselves. Even in the case that a security objective - of the operational environment is merely a restatement - of an assumption, a justification is required, but this - justification may be as minimal as ``Security Objective - X directly upholds Assumption Y''. - - - - - - - - Extended security requirements are requirements that are not - based on components from CC Part 2 or CC Part 3, but are - based on extended components: components defined by the PP - author. - - Evaluation of the definition of extended components is - necessary to determine that they are clear and unambiguous, - and that they are necessary, i.e. they may not be clearly - expressed using existing CC Part 2 or CC Part 3 - components. - - - - Extended security requirements are requirements that are not - based on components from CC Part 2 or CC Part 3, but are - based on extended components: components defined by the PP - author. This family is used to determine that these extended - components are defined similarly to the existing CC Part 2 - or CC Part 3 components. - - Evaluation of the definition of extended components is - necessary to determine that they are clear and unambiguous, - and that they are necessary, i.e. they may not be clearly - expressed using existing CC Part 2 or CC Part 3 - components. - - - - - The objective of this sub-activity is to determine whether - extended components have been clearly and unambiguously - defined, and whether they are necessary, i.e. they may not - be clearly expressed using existing CC Part 2 or CC Part 3 - components. - - - - The evaluation evidence for this sub-activity is: - - - the PP. - - - - - The developer shall provide a statement of security - requirements. - - - The developer shall provide an extended components - definition. - - - The statement of security requirements shall identify all - extended security requirements. - - - The extended components definition shall define an extended - component for each extended security requirement. - - - The extended components definition shall describe how each - extended component is related to the existing CC components, - families, and classes. - - - The extended components definition shall use the existing CC - components, families, classes, and methodology as a model - for presentation. - - - The extended components shall consist of measurable and - objective elements such that conformance or nonconformance - to these elements can be demonstrated. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that all security requirements - in the statement of security requirements that are not - identified as extended requirements are present in CC - Part 2 or in CC Part 3. - - - - - The evaluator shall check that the extended components - definition defines an extended component for each - extended security requirement. - - If the PP does not contain extended security - requirements, this work unit is not applicable and - therefore considered to be satisfied. - - A single extended component may be used to define - multiple iterations of an extended security requirement, - it is not necessary to repeat this definition for each - iteration. - - - - - The evaluator shall examine the extended components - definition to determine that it describes how each - extended component fits into the existing CC components, - families, and classes. - - If the PP does not contain extended security - requirements, this work unit is not applicable and - therefore considered to be satisfied. - - The evaluator determines that each extended component is - either: - - - a member of an existing CC Part 2 or CC Part 3 - family, or - - a member of a new family defined in the PP. - - - - If the extended component is a member of an existing CC - Part 2 or CC Part 3 family, the evaluator determines - that the extended components definition adequately - describes why the extended component should be a member - of that family and how it relates to other components of - that family. - - If the extended component is a member of a new family - defined in the PP, the evaluator confirms that the - extended component is not appropriate for an existing - family. - - If the PP defines new families, the evaluator determines - that each new family is either: - - - a member of an existing CC Part 2 or CC Part 3 - class, or - - - a member of a new class defined in the PP. - - - - If the family is a member of an existing CC Part 2 or CC - Part 3 class, the evaluator determines that the extended - components definition adequately describes why the - family should be a member of that class and how it - relates to other families in that class. - - If the family is a member of a new class defined in the - PP, the evaluator confirms that the family is not - appropriate for an existing class. - - - - - The evaluator shall examine the extended components - definition to determine that each definition of an - extended component identifies all applicable - dependencies of that component. - - If the PP does not contain extended security - requirements, this work unit is not applicable and - therefore considered to be satisfied. - - The evaluator confirms that no applicable dependencies - have been overlooked by the PP author. - - - - - The evaluator shall examine the extended components - definition to determine that each extended functional - component uses the existing CC Part 2 components as a - model for presentation. - - If the PP does not contain extended SFRs, this work unit - is not applicable and therefore considered to be - satisfied. - - The evaluator determines that the extended functional - component is consistent with CC Part 2 Subclause . - - If the extended functional component uses operations, the - evaluator determines that the extended functional component is - consistent with CC Part 1 Subclause . - - If the extended functional component is hierarchical to - an existing functional component, the evaluator - determines that the extended functional component is - consistent with CC Part 2 Subclause . - - - - - The evaluator shall examine the extended components - definition to determine that each definition of a new - functional family uses the existing CC functional - families as a model for presentation. - - If the PP does not define new functional families, this - work unit is not applicable and therefore considered to - be satisfied. - - The evaluator determines that all new functional - families are defined consistent with CC Part 2 Subclause - . - - - - - The evaluator shall examine the extended components - definition to determine that each definition of a new - functional class uses the existing CC functional classes - as a model for presentation. - - If the PP does not define new functional classes, this - work unit is not applicable and therefore considered to - be satisfied. - - The evaluator determines that all new functional classes - are defined consistent with CC Part 2 Subclause - - - - - The evaluator shall examine the extended components - definition to determine that each definition of an - extended assurance component uses the existing CC Part 3 - components as a model for presentation. - - If the PP does not contain extended SARs, this work unit - is not applicable and therefore considered to be - satisfied. - - The evaluator determines that the extended assurance - component definition is consistent with CC Part 3 - Subclause . - - If the extended assurance component uses operations, the - evaluator determines that the extended assurance component is - consistent with CC Part 1 Subclause . - - If the extended assurance component is hierarchical to - an existing assurance component, the evaluator - determines that the extended assurance component is - consistent with CC Part 3 Subclause . - - - - - The evaluator shall examine the extended components - definition to determine that, for each defined extended - assurance component, applicable methodology has been - provided. - - If the PP does not contain extended SARs, this work unit - is not applicable and therefore considered to be - satisfied. - - The evaluator determines that, for each evaluator action - element of each extended SAR, one or more work units are - provided and that successfully performing all work units - for a given evaluator action element will demonstrate - that the element has been achieved. - - - - - The evaluator shall examine the extended components - definition to determine that each definition of a new - assurance family uses the existing CC assurance families - as a model for presentation. - - If the PP does not define new assurance families, this - work unit is not applicable and therefore considered to - be satisfied. - - The evaluator determines that all new assurance families - are defined consistent with CC Part 3 Subclause . - - - - - The evaluator shall examine the extended components - definition to determine that each definition of a new - assurance class uses the existing CC assurance classes - as a model for presentation. - - If the PP does not define new assurance classes, this - work unit is not applicable and therefore considered to - be satisfied. - - The evaluator determines that all new assurance classes - are defined consistent with CC Part 3 Subclause . - - - - - The evaluator shall examine the extended components - definition to determine that each element in each - extended component is measurable and states objective - evaluation requirements, such that conformance or - nonconformance can be demonstrated. - - If the PP does not contain extended security - requirements, this work unit is not applicable and - therefore considered to be satisfied. - - The evaluator determines that elements of extended - functional components are stated in such a way that they - are testable, and traceable through the appropriate TSF - representations. - - The evaluator also determines that elements of extended - assurance components avoid the need for subjective - evaluator judgement. - - The evaluator is reminded that whilst being measurable - and objective is appropriate for all evaluation - criteria, it is acknowledged that no formal method - exists to prove such properties. Therefore the existing - CC functional and assurance components are to be used as - a model for determining what constitutes conformance to - this requirement. - - - - The evaluator shall confirm that no extended component may - be clearly expressed using existing components. - - - The evaluator shall examine the extended components - definition to determine that each extended component may - not be clearly expressed using existing - components. - - If the PP does not contain extended security - requirements, this work unit is not applicable and - therefore considered to be satisfied. - - The evaluator should take components from CC Part 2 and - CC Part 3, other extended components that have been - defined in the PP, combinations of these components, and - possible operations on these components into account - when making this determination. - - The evaluator is reminded that the role of this work - unit is to preclude unnecessary duplication of - components, that is, components that may be clearly - expressed by using other components. The evaluator - should not undertake an exhaustive search of all - possible combinations of components including operations - in an attempt to find a way to express the extended - component by using existing components. - - - - - - - - The SFRs form a clear, unambiguous and well-defined - description of the expected security behaviour of the - TOE. The SARs form a clear, unambiguous and well-defined - description of the expected activities that will be - undertaken to gain assurance in the TOE. - - Evaluation of the security requirements is required to - ensure that they are clear, unambiguous and - well-defined. - - - - The SFRs form a clear, unambiguous and well-defined - description of the expected security behaviour of the - TOE. The SARs form a clear, unambiguous and well-defined - description of the expected activities that will be - undertaken to gain assurance in the TOE. - - - - The components in this family are levelled on whether they - are stated as is, or whether the SFRs are derived from - security objectives for the TOE. - - - - - - The objective of this sub-activity is to determine whether - the SFRs and SARs are clear, unambiguous and well-defined - and whether they are internally consistent. - - - - The evaluation evidence for this sub-activity is: - - - the PP. - - - - - The developer shall provide a statement of security requirements. - - - The developer shall provide a security requirements - rationale. - - - The statement of security requirements shall describe the - SFRs and the SARs. - - - All subjects, objects, operations, security attributes, - external entities and other terms that are used in the SFRs - and the SARs shall be defined. - - - The statement of security requirements shall identify all - operations on the security requirements. - - - All operations shall be performed correctly. - - - Each dependency of the security requirements shall either be - satisfied, or the security requirements rationale shall - justify the dependency not being satisfied. - - - The statement of security requirements shall be internally - consistent. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the statement of security - requirements describes the SFRs. - - The evaluator determines that each SFR is identified by - one of the following means: - - - by reference to an individual component in CC Part - 2; - - - by reference to an extended component in the - extended components definition of the PP; - - - by reference to a PP that the PP claims to be - conformant with; - - - by reference to a security requirements package that - the PP claims to be conformant with; - - - by reproduction in the PP. - - It is not required to use the same means of - identification for all SFRs. - - - - - The evaluator shall check that the statement of security - requirements describes the SARs. - - The evaluator determines that each SAR is identified by - one of the following means: - - - by reference to an individual component in CC Part - 3; - - - by reference to an extended component in the - extended components definition of the PP; - - - by reference to a PP that the PP claims to be - conformant with; - - - by reference to a security requirements package that - the PP claims to be conformant with; - - - by reproduction in the PP. - - It is not required to use the same means of - identification for all SARs. - - - - - The evaluator shall examine the PP to determine that all - subjects, objects, operations, security attributes, - external entities and other terms that are used in the - SFRs and the SARs are defined. - - The evaluator determines that the PP defines all: - - (types of) subjects and objects that are used in - the SFRs; - (types of) security attributes of subjects, users, - objects, information, sessions and/or resources, possible - values that these attributes may take and any relations - between these values (e.g. top_secret is ``higher'' than secret); - (types of) operations that are used in the SFRs, - including the effects of these operations; - (types of) external entities in the SFRs; - other terms that are introduced in the SFRs - and/or SARs by completing operations, if these terms - are not immediately clear, or are used outside their - dictionary definition. - - The goal of this work unit is to ensure that the SFRs - and SARs are well-defined and that no misunderstanding - may occur due to the introduction of vague terms. This - work unit should not be taken into extremes, by forcing - the PP writer to define every single word. The general - audience of a set of security requirements should be - assumed to have a reasonable knowledge of IT, security - and Common Criteria. - - All of the above may be presented in groups, classes, - roles, types or other groupings or characterisations - that allow easy understanding. - - The evaluator is reminded that these lists and - definitions do not have to be part of the statement of - security requirements, but may be placed (in part or in - whole) in different subclauses. This may be especially - applicable if the same terms are used in the rest of the - PP. - - - - - The evaluator shall check that the statement of security - requirements identifies all operations on the security - requirements. - - The evaluator determines that all operations are - identified in each SFR or SAR where such an operation is - used. This includes both completed operations and - uncompleted operations. Identification may be achieved - by typographical distinctions, or by explicit - identification in the surrounding text, or by any other - distinctive means. - - - - - The evaluator shall examine the statement of security - requirements to determine that all assignment operations - are performed correctly. - Guidance on the correct performance of operations may be found - in CC Part 1 Annex . - - - - - The evaluator shall examine the statement of security - requirements to determine that all iteration operations - are performed correctly. - - Guidance on the correct performance of operations may be found - in CC Part 1 Annex . - - - - - The evaluator shall examine the statement of security - requirements to determine that all selection operations - are performed correctly. - - Guidance on the correct performance of operations may be found - in CC Part 1 Annex . - - - - - The evaluator shall examine the statement of security - requirements to determine that all refinement operations - are performed correctly. - - Guidance on the correct performance of operations may be found - in CC Part 1 Annex . - - - - - The evaluator shall examine the statement of security - requirements to determine that each dependency of the - security requirements is either satisfied, or that the - security requirements rationale justifies the dependency - not being satisfied. - - A dependency is satisfied by the inclusion of the - relevant component (or one that is hierarchical to it) - within the statement of security requirements. The - component used to satisfy the dependency should, if - necessary, be modified by operations to ensure that it - actually satisfies that dependency. - - A justification that a dependency is not met should - address either: - - - why the dependency is not necessary or useful, in - which case no further information is required; or - - - that the dependency has been addressed by the - operational environment of the TOE, in which case - the justification should describe how the security - objectives for the operational environment address - this dependency. - - - - - - - The evaluator shall examine the statement of security - requirements to determine that it is internally - consistent. - - The evaluator determines that the combined set of all - SFRs and SARs is internally consistent. - - The evaluator determines that on all occasions where - different security requirements apply to the same types - of developer evidence, events, operations, data, tests - to be performed etc. or to ``all objects'', ``all - subjects'' etc., that these requirements do not - conflict. - - Some possible conflicts are: - - - an extended SAR specifying that the design of a - certain cryptographic algorithm is to be kept - secret, and another extended SAR specifying an open - source review; - - specifying - that subject identity is to be logged, specifying who has - access to these logs, and specifying that some actions of - subjects should be unobservable to other - subjects. If the subject that should not be able to - see an activity may access logs of this activity, - these SFRs conflict; - - specifying - deletion of information no longer needed, and specifying that a TOE - may return to a previous state. If the information - that is needed for the rollback to the previous - state has been deleted, these requirements conflict; - - - Multiple iterations of especially where some iterations cover - the same subjects, objects, or operations. If one - access control SFR allows a subject to perform an - operation on an object, while another access control - SFR does not allow this, these requirements - conflict. - - - - - - - - - - - - The objective of this sub-activity is to determine whether - the SFRs and SARs are clear, unambiguous and well-defined, - whether they are internally consistent, and whether the - SFRs meet the security objectives of the TOE. - - - - The evaluation evidence for this sub-activity is: - - - the PP. - - - - - The developer shall provide a statement of security requirements. - - - The developer shall provide a security requirements - rationale. - - - The statement of security requirements shall describe the - SFRs and the SARs. - - - All subjects, objects, operations, security attributes, - external entities and other terms that are used in the SFRs - and the SARs shall be defined. - - - The statement of security requirements shall identify all - operations on the security requirements. - - - All operations shall be performed correctly. - - - Each dependency of the security requirements shall either be - satisfied, or the security requirements rationale shall - justify the dependency not being satisfied. - - - The security requirements rationale shall trace each SFR - back to the security objectives for the TOE. - - - The security requirements rationale shall demonstrate that - the SFRs meet all security objectives for the TOE. - - - The security requirements rationale shall explain why the - SARs were chosen. - - - The statement of security requirements shall be internally - consistent. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the statement of security - requirements describes the SFRs. - - The evaluator determines that each SFR is identified by - one of the following means: - - - by reference to an individual component in CC Part - 2; - - - by reference to an extended component in the - extended components definition of the PP; - - - by reference to an individual component in a PP that - the PP claims to be conformant with; - - - by reference to an individual component in a - security requirements package that the PP claims to - be conformant with; - - - by reproduction in the PP. - - It is not required to use the same means of - identification for all SFRs. - - - - - The evaluator shall check that the statement of security - requirements describes the SARs. - - The evaluator determines that each SAR is identified by - one of the following means: - - - by reference to an individual component in CC Part - 3; - - - by reference to an extended component in the - extended components definition of the PP; - - - by reference to an individual component in a PP that - the PP claims to be conformant with; - - - by reference to an individual component in a - security requirements package that the PP claims to - be conformant with; - - - by reproduction in the PP. - - It is not required to use the same means of - identification for all SARs. - - - - - The evaluator shall examine the PP to determine that all - subjects, objects, operations, security attributes, - external entities and other terms that are used in the - SFRs and the SARs are defined. - - The evaluator determines that the PP defines all: - - (types of) subjects and objects that are used in - the SFRs; - (types of) security attributes of subjects, users, - objects, information, sessions and/or resources, possible - values that these attributes may take and any relations - between these values (e.g. top_secret is ``higher'' than secret); - (types of) operations that are used in the SFRs, - including the effects of these operations; - (types of) external entities in the SFRs; - other terms that are introduced in the SFRs - and/or SARs by completing operations, if these terms - are not immediately clear, or are used outside their - dictionary definition. - - The goal of this work unit is to ensure that the SFRs - and SARs are well-defined and that no misunderstanding - may occur due to the introduction of vague terms. This - work unit should not be taken into extremes, by forcing - the PP writer to define every single word. The general - audience of a set of security requirements should be - assumed to have a reasonable knowledge of IT, security - and Common Criteria. - - All of the above may be presented in groups, classes, - roles, types or other groupings or characterisations - that allow easy understanding. - - The evaluator is reminded that these lists and - definitions do not have to be part of the statement of - security requirements, but may be placed (in part or in - whole) in different subclauses. This may be especially - applicable if the same terms are used in the rest of the - PP. - - - - - The evaluator shall check that the statement of security - requirements identifies all operations on the security - requirements. - - The evaluator determines that all operations are - identified in each SFR or SAR where such an operation is - used. This includes both completed operations and - uncompleted operations. Identification may be achieved - by typographical distinctions, or by explicit - identification in the surrounding text, or by any other - distinctive means. - - - - - The evaluator shall examine the statement of security - requirements to determine that all assignment operations - are performed correctly. - - Guidance on the correct performance of operations may be found - in CC Part 1 Annex . - - - - - The evaluator shall examine the statement of security - requirements to determine that all iteration operations - are performed correctly. - - Guidance on the correct performance of operations may be found - in CC Part 1 Annex . - - - - - The evaluator shall examine the statement of security - requirements to determine that all selection operations - are performed correctly. - - Guidance on the correct performance of operations may be found - in CC Part 1 Annex . - - - - - The evaluator shall examine the statement of security - requirements to determine that all refinement operations - are performed correctly. - - Guidance on the correct performance of operations may be found - in CC Part 1 Annex . - - - - - The evaluator shall examine the statement of security - requirements to determine that each dependency of the - security requirements is either satisfied, or that the - security requirements rationale justifies the dependency - not being satisfied. - - A dependency is satisfied by the inclusion of the - relevant component (or one that is hierarchical to it) - within the statement of security requirements. The - component used to satisfy the dependency should, if - necessary, be modified by operations to ensure that it - actually satisfies that dependency. - - A justification that a dependency is not met should - address either: - - - why the dependency is not necessary or useful, in - which case no further information is required; or - - - that the dependency has been addressed by the - operational environment of the TOE, in which case - the justification should describe how the security - objectives for the operational environment address - this dependency. - - - - - - - The evaluator shall check that the security requirements - rationale traces each SFR back to the security - objectives for the TOE. - - The evaluator determines that each SFR is traced back to - at least one security objective for the TOE. - - Failure to trace implies that either the security - requirements rationale is incomplete, the security - objectives for the TOE are incomplete, or the SFR has no - useful purpose. - - - - - The evaluator shall examine the security requirements - rationale to determine that for each security objective - for the TOE it justifies that the SFRs are suitable to - meet that security objective for the TOE. - - If no SFRs trace back to the security objective for the TOE, - the evaluator action related to this work unit is assigned a fail verdict. - - The evaluator determines that the justification for a - security objective for the TOE demonstrates that the - SFRs are sufficient: if all SFRs that trace back to the - objective are satisfied, the security objective for the - TOE is achieved. - - If the SFRs that trace back to a security objective for - the TOE have any uncompleted assignments, or uncompleted - or restricted selections, the evaluator determines that - for every conceivable completion or combination of - completions of these operations, the security objective - is still met. - - The evaluator also determines that each SFR that traces - back to a security objective for the TOE is necessary: - when the SFR is satisfied, it actually contributes to - achieving the security objective. - - Note that the tracings from SFRs to security objectives - for the TOE provided in the security requirements - rationale may be a part of the justification, but do not - constitute a justification by themselves. - - - - - The evaluator shall check that the security requirements - rationale explains why the SARs were chosen. - The evaluator is reminded that any explanation is - correct, as long as it is coherent and neither the SARs - nor the explanation have obvious inconsistencies with - the remainder of the PP. - An example of an obvious inconsistency between the - SARs and the remainder of the PP would be to have threat - agents that are very capable, but an SAR that does not protect against these - threat agents. - - - - - The evaluator shall examine the statement of security - requirements to determine that it is internally - consistent. - - The evaluator determines that the combined set of all - SFRs and SARs is internally consistent. - - The evaluator determines that on all occasions where - different security requirements apply to the same types - of developer evidence, events, operations, data, tests - to be performed etc. or to ``all objects'', ``all - subjects'' etc., that these requirements do not - conflict. - - Some possible conflicts are: - - - an extended SAR specifying that the design of a - certain cryptographic algorithm is to be kept - secret, and another extended SAR specifying an open - source review; - - specifying - that subject identity is to be logged, specifying who has - access to these logs, and specifying that some actions of - subjects should be unobservable to other - subjects. If the subject that should not be able to - see an activity may access logs of this activity, - these SFRs conflict; - - specifying - deletion of information no longer needed, and specifying that a TOE - may return to a previous state. If the information - that is needed for the rollback to the previous - state has been deleted, these requirements conflict; - - - Multiple iterations of especially where some iterations cover - the same subjects, objects, or operations. If one - access control SFR allows a subject to perform an - operation on an object, while another access control - SFR does not allow this, these requirements - conflict. - - - - - - - - - - - Evaluating an ST is required to demonstrate that the ST is - sound and internally consistent, and, if the ST is based on - one or more PPs or packages, that the ST is a correct - instantiation of these PPs and packages. These properties are - necessary for the ST to be suitable for use as the basis for a - TOE evaluation. - - This Clause should be used in conjunction with Annexes , and - in CC - Part 1, as these Annexes clarify the concepts here and provide - many examples. - - - - Assurance class defines - requirements for the evaluation of an ST, to demonstrate that - the ST is sound and internally consistent, and, if the ST is - based on one or more PPs or packages, that the ST is a correct - instantiation of these PPs and packages. - - - - This Clause describes the evaluation of an ST. The ST - evaluation should be started prior to any TOE evaluation - sub-activities since the ST provides the basis and context to - perform these sub-activities. The evaluation methodology in - this subclause is based on the requirements on the ST as - specified in CC Part 3 class . - - This Clause should be used in conjunction with Annexes , and - in CC - Part 1, as these Annexes clarify the concepts here and provide - many examples. - - - - The ST describes the security features of a TOE. As such it is - expected to identify the security requirements that enforce - the defined OSPs and counter the defined threats under the - defined assumptions. - - Evaluating an ST is required to demonstrate that the ST is - sound and internally consistent, and, if the ST is based on - one or more PPs or packages, that the ST is a correct - instantiation of these PPs or packages. These properties are - necessary for the ST to be suitable for use as the basis for a - TOE evaluation. - - - - - While evaluating an ST that is based on one or more - certified PPs, it may be possible to re-use the fact that - these PPs were certified. The potential for re-use of the - result of a certified PP is greater if the ST does not add - threats, OSPs, assumptions, security objectives and/or - security requirements to those of the PP. If the ST - contains much more than the certified PP, re-use may not be - useful at all. - - The evaluator is allowed to re-use the PP evaluation results - by doing certain analyses only partially or not at all if - these analyses or parts thereof were already done as part of - the PP evaluation. While doing this, the evaluator should - assume that the analyses in the PP were performed - correctly. - - An example would be where the PP contains a set of security - requirements, and these were determined to be internally - consistent during the PP evaluation. If the ST uses the - exact same requirements, the consistency analysis does not - have to be repeated during the ST evaluation. If the ST adds - one or more requirements, or performs operations on these - requirements, the analysis will have to be - repeated. However, it may be possible to save work in this - consistency analysis by using the fact that the original - requirements are internally consistent. If the original - requirements are internally consistent, the evaluator only - has to determine that: - - - the set of all new and/or changed requirements is - internally consistent, and - - - the set of all new and/or changed requirements is - consistent with the original requirements. - - - The evaluator notes in the ETR each case where analyses are - not done or only partially done for this reason. - - - - - - The objective of this family is to describe the TOE in a - narrative way on three levels of abstraction: TOE reference, - TOE overview and TOE description. - - Evaluation of the ST introduction is required to demonstrate - that the ST and the TOE are correctly identified, that the - TOE is correctly described at three levels of abstraction - and that these three descriptions are consistent with each - other. - - - - The ST introduction describes the TOE in a narrative way on - three levels of abstraction: TOE reference, TOE overview and - TOE description. - - - - - The objective of this sub-activity is to determine whether - the ST and the TOE are correctly identified, whether the - TOE is correctly described in a narrative way at three - levels of abstraction (TOE reference, TOE overview and TOE - description), and whether these three descriptions are - consistent with each other. - - - - The evaluation evidence for this sub-activity is: - - - the ST. - - - - - The developer shall provide an ST introduction. - - - The ST introduction shall contain an ST reference, a TOE - reference, a TOE overview and a TOE description. - - - The ST reference shall uniquely identify the ST. - - - The TOE reference shall identify the TOE. - - - The TOE overview shall summarise the usage and major - security features of the TOE. - - - The TOE overview shall identify the TOE type. - - - The TOE overview shall identify any non-TOE - hardware/software/firmware required by the TOE. - - - The TOE description shall describe the physical scope of the - TOE. - - - The TOE description shall describe the logical scope of the - TOE. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the ST introduction - contains an ST reference, a TOE reference, a TOE - overview and a TOE description. - - - - - The evaluator shall examine the ST reference to - determine that it uniquely identifies the ST. - - The evaluator determines that the ST reference - identifies the ST itself, so that it may be easily - distinguished from other STs, and that it also uniquely - identifies each version of the ST, e.g. by including a - version number and/or a date of publication. - - In evaluations where a CM system is provided, the - evaluator may validate the uniqueness of the reference - by checking the configuration list. In the other cases, - the ST should have some referencing system that is - capable of supporting unique references (e.g. use of - numbers, letters or dates). - - - - - The evaluator shall examine the TOE reference to - determine that it identifies the TOE. - - The evaluator determines that the TOE reference - identifies the TOE, so that it is clear to which TOE the - ST refers, and that it also identifies the version of - the TOE, e.g. by including a version/release/build - number, or a date of release. - - - - - The evaluator shall examine the TOE reference to - determine that it is not misleading. - - If the TOE is related to one or more well-known - products, it is allowed to reflect this in the TOE - reference. However, this should not be used to mislead - consumers: situations where only a small part of a - product is evaluated, yet the TOE reference does not - reflect this, are not allowed. - - - - - The evaluator shall examine the TOE overview to - determine that it describes the usage and major security - features of the TOE. - - The TOE overview should briefly (i.e. several - paragraphs) describe the usage and major security - features of the TOE. The TOE overview should enable - potential consumers to quickly determine whether the TOE - may be suitable for their security needs. - - The TOE overview in an ST for a composed TOE should - describe the usage and major security feature of the - composed TOE, rather than those of the individual - component TOEs. - - The evaluator determines that the overview is clear - enough for consumers, and sufficient to give them a - general understanding of the intended usage and major - security features of the TOE. - - - - - The evaluator shall check that the TOE overview - identifies the TOE type. - - - - - The evaluator shall examine the TOE overview to - determine that the TOE type is not misleading. - - There are situations where the general consumer would - expect certain functionality of the TOE because of its - TOE type. If this functionality is absent in the TOE, - the evaluator determines that the TOE overview - adequately discusses this absence. - - There are also TOEs where the general consumer would - expect that the TOE should be able to operate in a - certain operational environment because of its TOE - type. If the TOE is unable to operate in such an - operational environment, the evaluator determines that - the TOE overview adequately discusses this. - - - - - The evaluator shall examine the TOE overview to - determine that it identifies any non-TOE - hardware/software/firmware required by the TOE. - - While some TOEs are able to run stand-alone, other TOEs - (notably software TOEs) need additional hardware, - software or firmware to operate. If the TOE does not - require any hardware, software or firmware, this work - unit is not applicable and therefore considered to be - satisfied. - - The evaluator determines that the TOE overview - identifies any additional hardware, software and - firmware needed by the TOE to operate. This - identification does not have to be exhaustive, but - detailed enough for potential consumers of the TOE to - determine whether their current hardware, software and - firmware support use of the TOE, and, if this is not the - case, which additional hardware, software and/or - firmware is needed. - - - - - The evaluator shall examine the TOE description to - determine that it describes the physical scope of the - TOE. - - The evaluator determines that the TOE description lists - the hardware, firmware, software and guidance parts that - constitute the TOE and describes them at a level of - detail that is sufficient to give the reader a general - understanding of those parts. - - The evaluator also determines that there is no possible - misunderstanding as to whether any hardware, firmware, - software or guidance part is part of the TOE or - not. - - - - - The evaluator shall examine the TOE description to - determine that it describes the logical scope of the - TOE. - - The evaluator determines that the TOE description - discusses the logical security features offered by the - TOE at a level of detail that is sufficient to give the - reader a general understanding of those features. - - The evaluator also determines that there is no possible - misunderstanding as to whether any logical security - feature is offered by the TOE or not. - - An ST for a composed TOE may refer out to the - description of the logical scope of the component TOEs, - provided in the component TOE STs to provide the - majority of this description for the composed TOE. - However, the evaluator determines that the composed TOE - ST clearly discusses which features of the individual - components are not within the composed TOE, and - therefore not a feature of the composed TOE. - - - - The evaluator shall confirm that the TOE reference, the TOE - overview, and the TOE description are consistent with each - other. - - - The evaluator shall examine the TOE reference, TOE - overview and TOE description to determine that they are - consistent with each other. - - - - - - - - The objective of this family is to determine the validity of - the conformance claim. In addition, this family specifies - how STs are to claim conformance with the PP. - - - - Conformance claims describes how the Security Target - conforms to CC Part 2 and CC Part 3, to Protection Profiles - and to packages. - - - - - - - - The objective of this sub-activity is to determine the - validity of various conformance claims. These describe how - the ST and the TOE conform to the CC and how the ST - conforms to PPs and packages. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the PP(s) that the ST claims conformance to; - - - the package(s) that the ST claims conformance to. - - - - - The developer shall provide a conformance claim. - - - The developer shall provide a conformance claim rationale. - - - The conformance claim shall contain a CC conformance claim - that identifies the version of the CC to which the ST and - the TOE claim conformance. - - - The CC conformance claim shall describe the conformance of - the ST to CC Part 2 as either CC Part 2 conformant or CC - Part 2 extended. - - - The CC conformance claim shall describe the conformance of - the ST to CC Part 3 as either CC Part 3 conformant or CC - Part 3 extended. - - - The CC conformance claim shall be consistent with the - extended components definition. - - - The conformance claim shall identify all PPs and security - requirement packages to which the ST claims conformance. - - - The conformance claim shall describe any conformance of the - ST to a package as either package-conformant or - package-augmented. - - - The conformance claim rationale shall demonstrate that the - TOE type is consistent with the TOE type in the PPs for - which conformance is being claimed. - - - The conformance claim rationale shall demonstrate that the - statement of the security problem definition is consistent - with the statement of the security problem definition in the - PPs for which conformance is being claimed. - - - The conformance claim rationale shall demonstrate that the - statement of security objectives is consistent with the - statement of security objectives in the PPs for which - conformance is being claimed. - - - The conformance claim rationale shall demonstrate that the - statement of security requirements is consistent with the - statement of security requirements in the PPs for which - conformance is being claimed. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the conformance claim - contains a CC conformance claim that identifies the - version of the CC to which the ST and the TOE claim - conformance. - - The evaluator determines that the CC conformance claim - identifies the version of the CC that was used to - develop this ST. This should include the version number - of the CC and, unless the International English version - of the CC was used, the language of the version of the - CC that was used. - - For a composed TOE, the evaluator will consider any - differences between the version of the CC claimed for a - component and the version of the CC claimed for the - composed TOE. If the versions differ the evaluator will - assess whether the differences between the versions will - lead to conflicting claims. - - For instances where the CC conformance claims for the - base TOE and dependent TOE are for different major - releases of the CC (e.g. one component TOE conformance - claim is CC v2.x and the other component TOE conformance - claim is CC v3.x), the conformance claim for the - composed TOE will be the earlier release of the CC, as - the CC is developed with an aim to provide backwards - compatibility (although this may not be achieved in the - strictest sense, it is understood to be achieved in - principle). - - - - - The evaluator shall check that the CC conformance claim - states a claim of either CC Part 2 conformant or CC Part - 2 extended for the ST. - - For a composed TOE, the evaluator will consider whether - this claim is consistent not only with the CC Part 2, - but also with the claims of conformance to CC Part 2 by - each of the component TOEs. I.e. if one or more - component TOEs claims to be CC Part 2 extended, then the - composed TOE should also claim to be CC Part 2 - extended. - - The CC conformance claim for the composed TOE may be CC - Part 2 extended, even though the component TOEs are Part - 2 conformant, in the event that additional SFRs are - claimed for the base TOE (see composed TOE guidance for - ) - - - - - The evaluator shall check that the CC conformance claim - states a claim of either CC Part 3 conformant or CC Part - 3 extended for the ST. - - - - - The evaluator shall examine the CC conformance claim for - CC Part 2 to determine that it is consistent with the - extended components definition. - - If the CC conformance claim contains CC Part 2 - conformant, the evaluator determines that the extended - components definition does not define functional - components. - - If the CC conformance claim contains CC Part 2 extended, - the evaluator determines that the extended components - definition defines at least one extended functional - component. - - - - - The evaluator shall examine the CC conformance claim for - CC Part 3 to determine that it is consistent with the - extended components definition. - - If the CC conformance claim contains CC Part 3 - conformant, the evaluator determines that the extended - components definition does not define assurance - components. - - If the CC conformance claim contains CC Part 3 extended, - the evaluator determines that the extended components - definition defines at least one extended assurance - component. - - - - - The evaluator shall check that the conformance claim - contains a PP claim that identifies all PPs for which - the ST claims conformance. - - If the ST does not claim conformance to a PP, this work - unit is not applicable and therefore considered to be - satisfied. - - The evaluator determines that any referenced PPs are - unambiguously identified (e.g. by title and version - number, or by the identification included in the - introduction of that PP). - - The evaluator is reminded that claims of partial - conformance to a PP are not permitted. Therefore, - conformance to a PP requiring a composite solution may - be claimed in an ST for a composed TOE. Conformance to - such a PP would not have been possible during the - evaluation of the component TOEs, as these components - would not have satisfied the composed solution. This is - only possible in the instances where the ``composite'' PP - permits use of the composition evaluation approach (use - of components). - - The ST for a composed TOE will identify the STs of the - component TOEs from which the composed ST is comprised. - The composed TOE is essentially claiming conformance to - the STs of the component TOEs. - - - - - The evaluator shall check that the conformance claim - contains a package claim that identifies all packages to - which the ST claims conformance. - - If the ST does not claim conformance to a package, this - work unit is not applicable and therefore considered to - be satisfied. - - The evaluator determines that any referenced packages - are unambiguously identified (e.g. by title and version - number, or by the identification included in the - introduction of that package). - - The evaluator determines that the component TOE STs from - which the composed TOE is derived are also unambiguously - identified. - - The evaluator is reminded that claims of partial - conformance to a package are not permitted. - - - - - The evaluator shall check that, for each identified - package, the conformance claim states a claim of either - package-name conformant or package-name - augmented. - - If the ST does not claim conformance to a package, this - work unit is not applicable and therefore considered to - be satisfied. - - If the package conformance claim contains package-name - conformant, the evaluator determines that: - - - If the package is an assurance package, then the ST - contains all SARs included in the package, but no - additional SARs. - - - If the package is a functional package, then the ST - contains all SFRs included in the package, but no - additional SFRs. - - - - If the package conformance claim contains package-name - augmented, the evaluator determines that: - - - If the package is an assurance package then the ST - contains all SARs included in the package, and at - least one additional SAR or at least one SAR that is - hierarchical to a SAR in the package. - - - If the package is a functional package, then the ST - contains all SFRs included in the package, and at - least one additional SFR or at least one SFR that is - hierarchical to a SFR in the package. - - - - - - - The evaluator shall examine the conformance claim - rationale to determine that the TOE type of the TOE is - consistent with all TOE types of the PPs. - - If the ST does not claim conformance to a PP, this work - unit is not applicable and therefore considered to be - satisfied. - - The relation between the types may be simple: a firewall - ST claiming conformance to a firewall PP, or more - complex: a smart card ST claiming conformance to a number - of PPs at the same time (a PP for the integrated - circuit, a PP for the smart card OS, and two PPs for two - applications on the smart card). - - For a composed TOE, the evaluator will determine whether - the conformance claim rationale demonstrates that the - TOE types of the component TOEs are consistent with the - composed TOE type. This does not mean that both the - component and the composed TOE types have to be the - same, but rather that the component TOEs are suitable - for integration to provide the composed TOE. It should be made clear in the composed TOE ST which SFRs are only included as a result of composition, and were not examined as SFRs in the base and dependent TOE (e.g. EALx) evaluation. - - - - - The evaluator shall examine the conformance claim - rationale to determine that it demonstrates that the - statement of security problem definition is consistent, - as defined by the conformance statement of the PP, with - the statements of security problem definition stated in - the PPs to which conformance is being claimed. - - If the ST does not claim conformance with a PP, this - work unit is not applicable and therefore considered to - be satisfied. - - If the PP does not have a statement of security problem - definition, this work unit is not applicable and - therefore considered to be satisfied. - - If strict conformance is required by the PP to which - conformance is being claimed no conformance claim - rationale is required. Instead, the evaluator determines - whether: - - - the threats in the ST are a superset of or identical - to the threats in the PP to which conformance is - being claimed; - - - the OSPs in the ST are a superset of or identical to - the OSPs in the PP to which conformance is being - claimed; - - the assumptions in the ST are identical to the - assumptions in the PP to which conformance is being - claimed; - - If demonstrable conformance is required by the PP, the - evaluator examines the conformance claim rationale to - determine that it demonstrates that the statement of - security problem definition of the ST is equivalent or - more restrictive than the statement of security problem - definition in the PP to which conformance is being - claimed. - For guidance on ``equivalent or more restrictive'' - see CC Part 1 . - - For a composed TOE, the evaluator will consider whether - the security problem definition of the composed TOE is - consistent with that specified in the STs for the - component TOEs. This is determined in terms of - demonstrable conformance. In particular, the evaluator - examines the conformance claim rationale to determine - that: - - - Threat statements and OSPs in the composed TOE ST do - not contradict those from the component STs. - - Any assumptions made in the component STs are upheld - in the composed TOE ST. That is, either the - assumption should also be present in the composed - ST, or the assumption should be positively addressed - in the composed ST. The assumption may be - positively addressed through specification of - requirements in the composed TOE to provide - functionality fulfilling the concern captured in the - assumption. - - - - - The evaluator shall examine the conformance claim - rationale to determine that the statement of security - objectives is consistent, as defined by the conformance - statement of the PP, with the statement of security - objectives in the PPs to which conformance is being claimed. - - If the ST does not claim conformance to a PP, this work - unit is not applicable and therefore considered to be - satisfied. - - If strict conformance is required by the PP, no - conformance claim rationale is required. Instead, the - evaluator determines whether: - - The ST contains all security objectives for the - TOE of the PP to which conformance is being - claimed. Note that it is allowed for the ST under - evaluation to have additional security objectives - for the TOE; - The ST contains exactly all security objectives - for the operational environment (with one exception - in the next bullet). Note that it is not allowed for - the ST under evaluation to have additional security - objectives for the operational environment; - The ST may specify that certain objectives for - the operational environment in the PP that - conformance is being claimed to are security - objectives for the TOE in the ST. This is a valid - exception to the previous bullet. - - - If demonstrable conformance is required by the PP to - which conformance is being claimed, the evaluator - examines the conformance claim rationale to determine - that it demonstrates that the statement of security - objectives of the ST is equivalent or more restrictive - than the statement of security objectives in the PP to - which conformance is being claimed. - For guidance on ``equivalent or more restrictive'' - see CC Part 1 . - - For a composed TOE, the evaluator will consider whether - the security objectives of the composed TOE are - consistent with that specified in the STs for the - component TOEs. This is determined in terms of - demonstrable conformance. In particular, the evaluator - examines the conformance claim rationale to determine - that: - - - The statement of security objectives in the - dependent TOE ST relevant to any IT in the - operational environment are consistent with the - statement of security objectives for the TOE in the - base TOE ST. It is not expected that the statement - of security objectives for the environment within in - the dependent TOE ST will cover all aspects of the - statement of security objectives for the TOE in the - base TOE ST. - - The statement of security objectives in the composed - ST is consistent with the statements of security - objectives in the STs for the component TOEs. - - - If demonstrable conformance is required by the PP, the - evaluator examines the conformance claim rationale to - determine that it demonstrates that the statement of - security objectives of the ST is at least equivalent to - the statement of security objectives in the PP, or - component TOE ST in the case of a composed TOE - ST. - - - - - The evaluator shall examine the ST to determine that it - is consistent, as defined by the conformance statement - of the PP, with all security requirements in the PPs for - which conformance is being claimed. - - If the ST does not claim conformance to a PP, this work - unit is not applicable and therefore considered to be - satisfied. - - If strict conformance is required by the PP to which - conformance is being claimed, no conformance claim - rationale is required. Instead, the evaluator determines - whether the statement of security requirements in the ST - is a superset of or identical to the statement of - security requirements in the PP to which conformance is - being claimed (for strict conformance). - - If demonstrable conformance is required by the PP to - which conformance is being claimed, the evaluator - examines the conformance claim rationale to determine - that it demonstrates that the statement of security - requirements of the ST is equivalent or more restrictive - than the statement of security requirements in the PP to - which conformance is being claimed. - For guidance on ``equivalent or more restrictive'' - see CC Part 1 . - - - For a composed TOE, the evaluator will consider whether - the security requirements of the composed TOE are - consistent with that specified in the STs for the - component TOEs. This is determined in terms of - demonstrable conformance. In particular, the evaluator - examines the conformance rationale to determine that: - - - The statement of security requirements in the - dependent TOE ST relevant to any IT in the - operational environment is consistent with the - statement of security requirements for the TOE in - the base TOE ST. It is not expected that the - statement of security requirements for the - environment within in the dependent TOE ST will - cover all aspects of the statement of security - requirements for the TOE in the base TOE ST, as - some SFRs may need to be added to the statement of - security requirements in the composed TOE ST. - However, the statement of security requirements in - the base should support the operation of the dependent - component. - - The statement of security objectives in the - dependent TOE ST relevant to any IT in the - operational environment is consistent with the - statement of security requirements for the TOE in - the base TOE ST. It is not expected that the - statement of security objectives for the environment - within in the dependent TOE ST will cover all - aspects of the statement of security requirements - for the TOE in the base TOE ST. - - The statement of security requirements in the - composed is consistent with the statements of - security requirements in the STs for the component - TOEs. - - If demonstrable conformance is required by the PP to - which conformance is being claimed, the evaluator - examines the conformance claim rationale to determine - that it demonstrates that the statement of security - requirements of the ST is at least equivalent to the - statement of security requirements in the PP, or - component TOE ST in the case of a composed TOE - ST. - - - - - - - - This part of the ST defines the security problem to be - addressed by the TOE and the operational environment of the - TOE. - - Evaluation of the security problem definition is required to - demonstrate that the security problem intended to be - addressed by the TOE and its operational environment, is - clearly defined. - - - - The security problem definition defines the problem - addressed by the TOE and the operational environment of the - TOE. - - - - - The objective of this sub-activity is to determine that - the security problem intended to be addressed by the TOE - and its operational environment is clearly defined. - - - - The evaluation evidence for this sub-activity is: - - - the ST. - - - - - The developer shall provide a security problem definition. - - - The security problem definition shall describe the threats. - - - All threats shall be described in terms of a threat agent, - an asset, and an adverse action. - - - The security problem definition shall describe the OSPs. - - - The security problem definition shall describe the - assumptions about the operational environment of the TOE. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the security problem - definition describes the threats. - - If all security objectives are derived from assumptions - and/or OSPs only, the statement of threats need not be - present in the ST. In this case, this work unit is not - applicable and therefore considered to be - satisfied. - - The evaluator determines that the security problem - definition describes the threats that must be countered - by the TOE and/or operational environment. - - - - - The evaluator shall examine the security problem - definition to determine that all threats are described - in terms of a threat agent, an asset, and an adverse - action. - - If all security objectives are derived from assumptions - and/or OSPs only, the statement of threats need not be - present in the ST. In this case, this work unit is not - applicable and therefore considered to be - satisfied. - - Threat agents may be further described by aspects such - as expertise, resource, opportunity, and - motivation. - - - - - The evaluator shall examine that the security problem - definition describes the OSPs. - - If all security objectives are derived from assumptions - and threats only, OSPs need not be present in the ST. In - this case, this work unit is not applicable and - therefore considered to be satisfied. - - The evaluator determines that OSP statements are made in - terms of rules or guidelines that must be followed by - the TOE and/or its operational environment. - - The evaluator determines that each OSP is explained - and/or interpreted in sufficient detail to make it - clearly understandable; a clear presentation of policy - statements is necessary to permit tracing security - objectives to them. - - - - - The evaluator shall examine the security problem - definition to determine that it describes the - assumptions about the operational environment of the - TOE. - - If there are no assumptions, this work unit is not - applicable and is therefore considered to be - satisfied. - - The evaluator determines that each assumption about the - operational environment of the TOE is explained in - sufficient detail to enable consumers to determine that - their operational environment matches the assumption. If - the assumptions are not clearly understood, the end - result may be that the TOE is used in an operational - environment in which it will not function in a secure - manner. - - - - - - - - The security objectives are a concise statement of the - intended response to the security problem defined through - the family. - - Evaluation of the security objectives is required to - demonstrate that the security objectives adequately and - completely address the security problem definition, that the - division of this problem between the TOE and its operational - environment is clearly defined. - - - - The security objectives are a concise statement of the - intended response to the security problem. - - - - The components in this family are levelled on whether they - prescribe only security objectives for the operational - environment, or also security objectives for the TOE. - - - - - The objective of this sub-activity is to determine whether - the security objectives for the operational environment - are clearly defined. - - - - The evaluation evidence for this sub-activity is: - - - the ST. - - - - - The developer shall provide a statement of security - objectives. - - - The statement of security objectives shall describe the - security objectives for the operational environment. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the statement of security - objectives defines the security objectives for the - operational environment. - - The evaluator checks that the security objectives for - the operational environment are identified. - - - - - - - - - The objective of this sub-activity is to determine whether - the security objectives adequately and completely address - the security problem definition and that the division of - this problem between the TOE and its operational - environment is clearly defined. - - - - The evaluation evidence for this sub-activity is: - - - the ST. - - - - - The developer shall provide a statement of security - objectives. - - - The developer shall provide a security objectives rationale. - - - The statement of security objectives shall describe the - security objectives for the TOE and the security objectives - for the operational environment. - - - The security objectives rationale shall trace each security - objective for the TOE back to threats countered by that - security objective and OSPs enforced by that security - objective. - - - The security objectives rationale shall trace each security - objective for the operational environment back to threats - countered by that security objective, OSPs enforced by that - security objective, and assumptions upheld by that security - objective. - - - The security objectives rationale shall demonstrate that the - security objectives counter all threats. - - - The security objectives rationale shall demonstrate that the - security objectives enforce all OSPs. - - - The security objectives rationale shall demonstrate that the - security objectives for the operational environment uphold - all assumptions. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the statement of security - objectives defines the security objectives for the TOE - and the security objectives for the operational - environment. - - The evaluator checks that both categories of security - objectives are clearly identified and separated from the - other category. - - - - - The evaluator shall check that the security objectives - rationale traces all security objectives for the TOE - back to threats countered by the objectives and/or OSPs - enforced by the objectives. - - Each security objective for the TOE may trace back to - threats or OSPs, or a combination of threats and OSPs, - but it must trace back to at least one threat or - OSP. - - Failure to trace implies that either the security - objectives rationale is incomplete, the security problem - definition is incomplete, or the security objective for - the TOE has no useful purpose. - - - - - The evaluator shall check that the security objectives - rationale traces the security objectives for the - operational environment back to threats countered by - that security objective, to OSPs enforced by that - security objective, and to assumptions upheld by that - security objective. - - Each security objective for the operational environment - may trace back to threats, OSPs, assumptions, or a - combination of threats, OSPs and/or assumptions, but it - must trace back to at least one threat, OSP or - assumption. - - Failure to trace implies that either the security - objectives rationale is incomplete, the security problem - definition is incomplete, or the security objective for - the operational environment has no useful - purpose. - - - - - The evaluator shall examine the security objectives - rationale to determine that it justifies for each threat - that the security objectives are suitable to counter - that threat. - - If no security objectives trace back to the threat, - the evaluator action related to this work unit is assigned a fail verdict. - - The evaluator determines that the justification for a - threat shows whether the threat is removed, diminished - or mitigated. - - The evaluator determines that the justification for a - threat demonstrates that the security objectives are - sufficient: if all security objectives that trace back - to the threat are achieved, the threat is removed, - sufficiently diminished, or the effects of the threat - are sufficiently mitigated. - - Note that the tracings from security objectives to - threats provided in the security objectives rationale - may be part of a justification, but do not constitute a - justification by themselves. Even in the case that a - security objective is merely a statement reflecting the - intent to prevent a particular threat from being - realised, a justification is required, but this - justification may be as minimal as ``Security Objective - X directly counters Threat Y''. - - The evaluator also determines that each security - objective that traces back to a threat is necessary: - when the security objective is achieved it actually - contributes to the removal, diminishing or mitigation of - that threat. - - - - - The evaluator shall examine the security objectives - rationale to determine that for each OSP it justifies - that the security objectives are suitable to enforce - that OSP. - - If no security objectives trace back to the OSP, - the evaluator action related to this work unit is assigned a fail verdict. - - The evaluator determines that the justification for an - OSP demonstrates that the security objectives are - sufficient: if all security objectives that trace back - to that OSP are achieved, the OSP is enforced. - - The evaluator also determines that each security - objective that traces back to an OSP is necessary: when - the security objective is achieved it actually - contributes to the enforcement of the OSP. - - Note that the tracings from security objectives to OSPs - provided in the security objectives rationale may be - part of a justification, but do not constitute a - justification by themselves. In the case that a security - objective is merely a statement reflecting the intent to - enforce a particular OSP, a justification is required, - but this justification may be as minimal as ``Security - Objective X directly enforces OSP Y''. - - - - - The evaluator shall examine the security objectives - rationale to determine that for each assumption for the - operational environment it contains an appropriate - justification that the security objectives for the - operational environment are suitable to uphold that - assumption. - - If no security objectives for the operational environment trace back to the assumption, - the evaluator action related to this work unit is assigned a fail verdict. - - The evaluator determines that the justification for an - assumption about the operational environment of the TOE - demonstrates that the security objectives are - sufficient: if all security objectives for the - operational environment that trace back to that - assumption are achieved, the operational environment - upholds the assumption. - - The evaluator also determines that each security - objective for the operational environment that traces - back to an assumption about the operational environment - of the TOE is necessary: when the security objective is - achieved it actually contributes to the operational - environment upholding the assumption. - - Note that the tracings from security objectives for the - operational environment to assumptions provided in the - security objectives rationale may be a part of a - justification, but do not constitute a justification by - themselves. Even in the case that a security objective - of the operational environment is merely a restatement - of an assumption, a justification is required, but this - justification may be as minimal as ``Security Objective - X directly upholds Assumption Y''. - - - - - - - - Extended security requirements are requirements that are not - based on components from CC Part 2 or CC Part 3, but are - based on extended components: components defined by the ST - author. - - Evaluation of the definition of extended components is - necessary to determine that they are clear and unambiguous, - and that they are necessary, i.e. they may not be clearly - expressed using existing CC Part 2 or CC Part 3 - components. - - - - Extended components are defined wherever it is impossible to - clearly express requirements using only components from CC - Part 2 and/or CC Part 3. - - - - - The objective of this sub-activity is to determine whether - extended components have been clearly and unambiguously - defined, and whether they are necessary, i.e. they may not - be clearly expressed using existing CC Part 2 or CC Part 3 - components. - - - - The evaluation evidence for this sub-activity is: - - - the ST. - - - - - The developer shall provide a statement of security - requirements. - - - The developer shall provide an extended components - definition. - - - The statement of security requirements shall identify all - extended security requirements. - - - The extended components definition shall define an extended - component for each extended security requirement. - - - The extended components definition shall describe how each - extended component is related to the existing CC components, - families, and classes. - - - The extended components definition shall use the existing CC - components, families, classes, and methodology as a model - for presentation. - - - The extended components shall consist of measurable and - objective elements such that conformance or nonconformance - to these elements can be demonstrated. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that all security requirements - in the statement of security requirements that are not - identified as extended requirements are present in CC - Part 2 or in CC Part 3. - - - - - The evaluator shall check that the extended components - definition defines an extended component for each - extended security requirement. - - If the ST does not contain extended security - requirements, this work unit is not applicable and - therefore considered to be satisfied. - - A single extended component may be used to define - multiple iterations of an extended security requirement, - it is not necessary to repeat this definition for each - iteration. - - - - - The evaluator shall examine the extended components - definition to determine that it describes how each - extended component fits into the existing CC components, - families, and classes. - - If the ST does not contain extended security - requirements, this work unit is not applicable and - therefore considered to be satisfied. - - The evaluator determines that each extended component is - either: - - - a member of an existing CC Part 2 or CC Part 3 - family, or - - a member of a new family defined in the ST. - - - If the extended component is a member of an existing CC - Part 2 or CC Part 3 family, the evaluator determines - that the extended components definition adequately - describes why the extended component should be a member - of that family and how it relates to other components of - that family. - - If the extended component is a member of a new family - defined in the ST, the evaluator confirms that the - extended component is not appropriate for an existing - family. - - If the ST defines new families, the evaluator determines - that each new family is either: - - - a member of an existing CC Part 2 or CC Part 3 - class, or - - a member of a new class defined in the ST. - - - If the family is a member of an existing CC Part 2 or CC - Part 3 class, the evaluator determines that the extended - components definition adequately describes why the - family should be a member of that class and how it - relates to other families in that class. - - If the family is a member of a new class defined in the - ST, the evaluator confirms that the family is not - appropriate for an existing class. - - - - - The evaluator shall examine the extended components - definition to determine that each definition of an - extended component identifies all applicable - dependencies of that component. - - If the ST does not contain extended security - requirements, this work unit is not applicable and - therefore considered to be satisfied. - - The evaluator confirms that no applicable dependencies - have been overlooked by the ST author. - - - - - The evaluator shall examine the extended components - definition to determine that each extended functional - component uses the existing CC Part 2 components as a - model for presentation. - - If the ST does not contain extended SFRs, this work unit - is not applicable and therefore considered to be - satisfied. - - The evaluator determines that the extended functional - component is consistent with CC Part 2 Subclause . - - If the extended functional component uses operations, the - evaluator determines that the extended functional component is - consistent with CC Part 1 Subclause . - - If the extended functional component is hierarchical to - an existing functional component, the evaluator - determines that the extended functional component is - consistent with CC Part 2 Subclause . - - - - - The evaluator shall examine the extended components - definition to determine that each definition of a new - functional family uses the existing CC functional - families as a model for presentation. - - If the ST does not define new functional families, this - work unit is not applicable and therefore considered to - be satisfied. - - The evaluator determines that all new functional - families are defined consistent with CC Part 2 Subclause - . - - - - - The evaluator shall examine the extended components - definition to determine that each definition of a new - functional class uses the existing CC functional classes - as a model for presentation. - - If the ST does not define new functional classes, this - work unit is not applicable and therefore considered to - be satisfied. - - The evaluator determines that all new functional classes - are defined consistent with CC Part 2 Subclause . - - - - - The evaluator shall examine the extended components - definition to determine that each definition of an - extended assurance component uses the existing CC Part 3 - components as a model for presentation. - - If the ST does not contain extended SARs, this work unit - is not applicable and therefore considered to be - satisfied. - - The evaluator determines that the extended assurance - component definition is consistent with CC Part 3 - Subclause . - - If the extended assurance component uses operations, the - evaluator determines that the extended assurance component is - consistent with CC Part 1 Subclause . - - If the extended assurance component is hierarchical to - an existing assurance component, the evaluator - determines that the extended assurance component is - consistent with CC Part 3 Subclause . - - - - - The evaluator shall examine the extended components - definition to determine that, for each defined extended - assurance component, applicable methodology has been - provided. - - If the ST does not contain extended SARs, this work unit - is not applicable and therefore considered to be - satisfied. - - The evaluator determines that, for each evaluator action - element of each extended SAR, one or more work units are - provided and that successfully performing all work units - for a given evaluator action element will demonstrate - that the element has been achieved. - - - - - The evaluator shall examine the extended components - definition to determine that each definition of a new - assurance family uses the existing CC assurance families - as a model for presentation. - - If the ST does not define new assurance families, this - work unit is not applicable and therefore considered to - be satisfied. - - The evaluator determines that all new assurance families - are defined consistent with CC Part 3 Subclause . - - - - - The evaluator shall examine the extended components - definition to determine that each definition of a new - assurance class uses the existing CC assurance classes - as a model for presentation. - - If the ST does not define new assurance classes, this - work unit is not applicable and therefore considered to - be satisfied. - - The evaluator determines that all new assurance classes - are defined consistent with CC Part 3 Subclause . - - - - - The evaluator shall examine the extended components - definition to determine that each element in each - extended component is measurable and states objective - evaluation requirements, such that conformance or - nonconformance can be demonstrated. - - If the ST does not contain extended security - requirements, this work unit is not applicable and - therefore considered to be satisfied. - - The evaluator determines that elements of extended - functional components are stated in such a way that they - are testable, and traceable through the appropriate TSF - representations. - - The evaluator also determines that elements of extended - assurance components avoid the need for subjective - evaluator judgement. - - The evaluator is reminded that whilst being measurable - and objective is appropriate for all evaluation - criteria, it is acknowledged that no formal method - exists to prove such properties. Therefore the existing - CC functional and assurance components are to be used as - a model for determining what constitutes conformance - with this requirement. - - - - The evaluator shall confirm that no extended component can - be clearly expressed using existing components. - - - The evaluator shall examine the extended components - definition to determine that each extended component can - not be clearly expressed using existing - components. - - If the ST does not contain extended security - requirements, this work unit is not applicable and - therefore considered to be satisfied. - - The evaluator should take components from CC Part 2 and - CC Part 3, other extended components that have been - defined in the ST, combinations of these components, and - possible operations on these components into account - when making this determination. - - The evaluator is reminded that the role of this work - unit is to preclude unnecessary duplication of - components, that is, components that may be clearly - expressed by using other components. The evaluator - should not undertake an exhaustive search of all - possible combinations of components including operations - in an attempt to find a way to express the extended - component by using existing components. - - - - - - - - The SFRs form a clear, unambiguous and well-defined - description of the expected security behaviour of the - TOE. The SARs form a clear, unambiguous and canonical - description of the expected activities that will be - undertaken to gain assurance in the TOE. - - Evaluation of the security requirements is required to - ensure that they are clear, unambiguous and - well-defined. - - - - The SFRs form a clear, unambiguous and well-defined - description of the expected security behaviour of the - TOE. The SARs form a clear, unambiguous and well-defined - description of the expected activities that will be - undertaken to gain assurance in the TOE. - - - - The components in this family are levelled on whether they - are stated as is. - - - - - - The objective of this sub-activity is to determine whether - the SFRs and SARs are clear, unambiguous and well-defined - and whether they are internally consistent. - - - - The evaluation evidence for this sub-activity is: - - - the ST. - - - - - The developer shall provide a statement of security requirements. - - - The developer shall provide a security requirements - rationale. - - - The statement of security requirements shall describe the - SFRs and the SARs. - - - All subjects, objects, operations, security attributes, - external entities and other terms that are used in the SFRs - and the SARs shall be defined. - - - The statement of security requirements shall identify all - operations on the security requirements. - - - All operations shall be performed correctly. - - - Each dependency of the security requirements shall either be - satisfied, or the security requirements rationale shall - justify the dependency not being satisfied. - - - The statement of security requirements shall be internally - consistent. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the statement of security - requirements describes the SFRs. - - The evaluator determines that each SFR is identified by - one of the following means: - - - by reference to an individual component in CC Part - 2; - - - by reference to an extended component in the - extended components definition of the ST; - - - by reference to a PP that the ST claims to be - conformant with; - - - by reference to a security requirements package that - the ST claims to be conformant with; - - - by reproduction in the ST. - - It is not required to use the same means of - identification for all SFRs. - - - - - The evaluator shall check that the statement of security - requirements describes the SARs. - - The evaluator determines that each SAR is identified by - one of the following means: - - - by reference to an individual component in CC Part - 3; - - - by reference to an extended component in the - extended components definition of the ST; - - - by reference to a PP that the ST claims to be - conformant with; - - - by reference to a security requirements package that - the ST claims to be conformant with; - - - by reproduction in the ST. - - It is not required to use the same means of - identification for all SARs. - - - - - The evaluator shall examine the ST to determine that all - subjects, objects, operations, security attributes, - external entities and other terms that are used in the - SFRs and the SARs are defined. - - The evaluator determines that the ST defines all: - - (types of) subjects and objects that are used in - the SFRs; - (types of) security attributes of subjects, users, - objects, information, sessions and/or resources, possible - values that these attributes may take and any relations - between these values (e.g. top_secret is ``higher'' than secret); - (types of) operations that are used in the SFRs, - including the effects of these operations; - (types of) external entities in the SFRs; - other terms that are introduced in the SFRs - and/or SARs by completing operations, if these terms - are not immediately clear, or are used outside their - dictionary definition. - - The goal of this work unit is to ensure that the SFRs - and SARs are well-defined and that no misunderstanding - may occur due to the introduction of vague terms. This - work unit should not be taken into extremes, by forcing - the ST writer to define every single word. The general - audience of a set of security requirements should be - assumed to have a reasonable knowledge of IT, security - and Common Criteria. - - All of the above may be presented in groups, classes, - roles, types or other groupings or characterisations - that allow easy understanding. - - The evaluator is reminded that these lists and - definitions do not have to be part of the statement of - security requirements, but may be placed (in part or in - whole) in different subclauses. This may be especially - applicable if the same terms are used in the rest of the - ST. - - - - - The evaluator shall check that the statement of security - requirements identifies all operations on the security - requirements. - - The evaluator determines that all operations are - identified in each SFR or SAR where such an operation is - used. Identification may be achieved by typographical - distinctions, or by explicit identification in the - surrounding text, or by any other distinctive - means. - - - - - The evaluator shall examine the statement of security - requirements to determine that all assignment operations - are performed correctly. - - Guidance on the correct performance of operations may be found - in CC Part 1 Annex . - - - - - The evaluator shall examine the statement of security - requirements to determine that all iteration operations - are performed correctly. - - Guidance on the correct performance of operations may be found - in CC Part 1 Annex . - - - - - The evaluator shall examine the statement of security - requirements to determine that all selection operations - are performed correctly. - - Guidance on the correct performance of operations may be found - in CC Part 1 Annex . - - - - - The evaluator shall examine the statement of security - requirements to determine that all refinement operations - are performed correctly. - - Guidance on the correct performance of operations may be found - in CC Part 1 Annex . - - - - - The evaluator shall examine the statement of security - requirements to determine that each dependency of the - security requirements is either satisfied, or that a - security requirements rationale is provided which justifies the dependency - not being satisfied. - - A dependency is satisfied by the inclusion of the - relevant component (or one that is hierarchical to it) - within the statement of security requirements. The - component used to satisfy the dependency should, if - necessary, be modified by operations to ensure that it - actually satisfies that dependency. - - A justification that a dependency is not met should - address either: - - - why the dependency is not necessary or useful, in - which case no further information is required; or - - - that the dependency has been addressed by the - operational environment of the TOE, in which case - the justification should describe how the security - objectives for the operational environment address - this dependency. - - - - - - - The evaluator shall examine the statement of security - requirements to determine that it is internally - consistent. - - The evaluator determines that the combined set of all - SFRs and SARs is internally consistent. - - The evaluator determines that on all occasions where - different security requirements apply to the same types - of developer evidence, events, operations, data, tests - to be performed etc. or to ``all objects'', ``all - subjects'' etc., that these requirements do not - conflict. - Some possible conflicts are: - - - an extended SAR specifying that the design of a - certain cryptographic algorithm is to be kept - secret, and another extended SAR specifying an open - source review; - - specifying - that subject identity is to be logged, specifying who has - access to these logs, and specifying that some actions of - subjects should be unobservable to other - subjects. If the subject that should not be able to - see an activity may access logs of this activity, - these SFRs conflict; - - specifying - deletion of information no longer needed, and specifying that a TOE - may return to a previous state. If the information - that is needed for the rollback to the previous - state has been deleted, these requirements conflict; - - - Multiple iterations of especially where some iterations cover - the same subjects, objects, or operations. If one - access control SFR allows a subject to perform an - operation on an object, while another access control - SFR does not allow this, these requirements - conflict. - - - - - - - - - - - - The objective of this sub-activity is to determine whether - the SFRs and SARs are clear, unambiguous and well-defined, - whether they are internally consistent, and whether the - SFRs meet the security objectives of the TOE. - - - - The evaluation evidence for this sub-activity is: - - - the ST. - - - - - The developer shall provide a statement of security requirements. - - - The developer shall provide a security requirements - rationale. - - - The statement of security requirements shall describe the - SFRs and the SARs. - - All subjects, objects, - operations, security attributes, external entities and other - terms that are used in the SFRs and the SARs shall be - defined. - - - The statement of security requirements shall identify all - operations on the security requirements. - - - All operations shall be performed correctly. - - - Each dependency of the security requirements shall either be - satisfied, or the security requirements rationale shall - justify the dependency not being satisfied. - - - The security requirements rationale shall trace each SFR - back to the security objectives for the TOE. - - - The security requirements rationale shall demonstrate that - the SFRs meet all security objectives for the TOE. - - - The security requirements rationale shall explain why the - SARs were chosen. - - - The statement of security requirements shall be internally - consistent. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the statement of security - requirements describes the SFRs. - - The evaluator determines that each SFRs is identified by - one of the following means: - - - by reference to an individual component in CC Part - 2; - - - by reference to an extended component in the - extended components definition of the ST; - - - by reference to an individual component in a PP that - the ST claims to be conformant with; - - - by reference to an individual component in a - security requirements package that the ST claims to - be conformant with; - - - by reproduction in the ST. - - It is not required to use the same means of - identification for all SFRs. - - - - - The evaluator shall check that the statement of security - requirements describes the SARs. - - The evaluator determines that all SARs are identified by - one of the following means: - - - by reference to an individual component in CC Part - 3; - - - by reference to an extended component in the - extended components definition of the ST; - - - by reference to an individual component in a PP that - the ST claims to be conformant with; - - - by reference to an individual component in a - security requirements package that the ST claims to - be conformant with; - - - by reproduction in the ST. - - It is not required to use the same means of - identification for all SARs. - - - - - The evaluator shall examine the ST to determine that all - subjects, objects, operations, security attributes, - external entities and other terms that are used in the - SFRs and the SARs are defined. - - The evaluator determines that the ST defines all: - - (types of) subjects and objects that are used in - the SFRs; - (types of) security attributes of subjects, users, - objects, information, sessions and/or resources, possible - values that these attributes may take and any relations - between these values (e.g. top_secret is ``higher'' than secret); - (types of) operations that are used in the SFRs, - including the effects of these operations; - (types of) external entities in the SFRs; - other terms that are introduced in the SFRs - and/or SARs by completing operations, if these terms - are not immediately clear, or are used outside their - dictionary definition. - - The goal of this work unit is to ensure that the SFRs - and SARs are well-defined and that no misunderstanding - may occur due to the introduction of vague terms. This - work unit should not be taken into extremes, by forcing - the ST writer to define every single word. The general - audience of a set of security requirements should be - assumed to have a reasonable knowledge of IT, security - and Common Criteria. - - All of the above may be presented in groups, classes, - roles, types or other groupings or characterisations - that allow easy understanding. - - The evaluator is reminded that these lists and - definitions do not have to be part of the statement of - security requirements, but may be placed (in part or in - whole) in different subclauses. This may be especially - applicable if the same terms are used in the rest of the - ST. - - - - - The evaluator shall check that the statement of security - requirements identifies all operations on the security - requirements. - - The evaluator determines that all operations are - identified in each SFR or SAR where such an operation is - used. Identification may be achieved by typographical - distinctions, or by explicit identification in the - surrounding text, or by any other distinctive - means. - - - - - The evaluator shall examine the statement of security - requirements to determine that all assignment operations - are performed correctly. - - Guidance on the correct performance of operations may be found - in CC Part 1 Annex . - - - - - The evaluator shall examine the statement of security - requirements to determine that all iteration operations - are performed correctly. - - Guidance on the correct performance of operations may be found - in CC Part 1 Annex . - - - - - The evaluator shall examine the statement of security - requirements to determine that all selection operations - are performed correctly. - - Guidance on the correct performance of operations may be found - in CC Part 1 Annex . - - - - - The evaluator shall examine the statement of security - requirements to determine that all refinement operations - are performed correctly. - - Guidance on the correct performance of operations may be found - in CC Part 1 Annex . - - - - - The evaluator shall examine the statement of security - requirements to determine that each dependency of the - security requirements is either satisfied, or that the - security requirements rationale justifies the dependency - not being satisfied. - - A dependency is satisfied by the inclusion of the - relevant component (or one that is hierarchical to it) - within the statement of security requirements. The - component used to satisfy the dependency should, if - necessary, be modified by operations to ensure that it - actually satisfies that dependency. - - A justification that a dependency is not met should - address either: - - - why the dependency is not necessary or useful, in - which case no further information is required; or - - - that the dependency has been addressed by the - operational environment of the TOE, in which case - the justification should describe how the security - objectives for the operational environment address - this dependency. - - - - - - - The evaluator shall check that the security requirements - rationale traces each SFR back to the security - objectives for the TOE. - - The evaluator determines that each SFR is traced back to - at least one security objective for the TOE. - - Failure to trace implies that either the security - requirements rationale is incomplete, the security - objectives for the TOE are incomplete, or the SFR has no - useful purpose. - - - - - The evaluator shall examine the security requirements - rationale to determine that for each security objective - for the TOE it demonstrates that the SFRs are suitable - to meet that security objective for the TOE. - - If no SFRs trace back to the security objective for the TOE, - the evaluator action related to this work unit is assigned a fail verdict. - - The evaluator determines that the justification for a - security objective for the TOE demonstrates that the - SFRs are sufficient: if all SFRs that trace back to the - objective are satisfied, the security objective for the - TOE is achieved. - - The evaluator also determines that each SFR that traces - back to a security objective for the TOE is necessary: - when the SFR is satisfied, it actually contributes to - achieving the security objective. - - Note that the tracings from SFRs to security objectives - for the TOE provided in the security requirements - rationale may be a part of the justification, but do not - constitute a justification by themselves. - - - - - The evaluator shall check that the security requirements - rationale explains why the SARs were chosen. - - The evaluator is reminded that any explanation is correct, as - long as it is coherent and neither the SARs nor the explanation - have obvious inconsistencies with the remainder of the ST. - - An example of an obvious inconsistency between the SARs and the - remainder of the ST would be to have threat agents that are very - capable, but an SAR that does not - protect against these threat agents. - - - - - The evaluator shall examine the statement of security - requirements to determine that it is internally - consistent. - - The evaluator determines that the combined set of all - SFRs and SARs is internally consistent. - - The evaluator determines that on all occasions where - different security requirements apply to the same types - of developer evidence, events, operations, data, tests - to be performed etc. or to ``all objects'', ``all - subjects'' etc., that these requirements do not - conflict. - - Some possible conflicts are: - - - an extended SAR specifying that the design of a - certain cryptographic algorithm is to be kept - secret, and another extended assurance requirement - specifying an open source review; - - specifying - that subject identity is to be logged, specifying who has - access to these logs, and specifying that some actions of - subjects should be unobservable to other - subjects. If the subject that should not be able to - see an activity may access logs of this activity, - these SFRs conflict; - - specifying - deletion of information no longer needed, and specifying that a TOE - may return to a previous state. If the information - that is needed for the rollback to the previous - state has been deleted, these requirements conflict; - - - Multiple iterations of especially where some iterations cover - the same subjects, objects, or operations. If one - access control SFR allows a subject to perform an - operation on an object, while another access control - SFR does not allow this, these requirements - conflict. - - - - - - - - - - The TOE summary specification enables evaluators and - potential consumers to gain a general understanding of how - the TOE is implemented. - - Evaluation of the TOE summary specification is necessary to - determine whether it is adequately described how the TOE: - - meets its SFRs; - protects itself against interference, logical - tampering and bypass. and whether the TOE - summary specification is consistent with other narrative - descriptions of the TOE. - - - - The TOE Summary specification allows evaluators and - potential consumers of the TOE to gain a general - understanding of how the TOE: - - meets its SFRs; - protects itself against interference, logical - tampering and bypass. - - - - The components in this family are levelled on whether the - TOE summary specification only needs to describe how the TOE - meets the SFRs, or whether the TOE summary specification - also needs to describe how the TOE protects itself against - logical tampering and bypass. This additional description - may be used in special circumstances where there might be a - specific concern regarding the TOE security architecture. - - - - - - - The objective of this sub-activity is to determine whether - the TOE summary specification addresses all SFRs, and - whether the TOE summary specification is consistent with - other narrative descriptions of the TOE. - - - - The evaluation evidence for this sub-activity is: - - - the ST. - - - - - The developer shall provide a TOE summary specification. - - - The TOE summary specification shall describe how the TOE - meets each SFR. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the TOE summary - specification to determine that it describes how the TOE - meets each SFR. - - The evaluator determines that the TOE summary - specification provides, for each SFR from the statement - of security requirements, a description on how that SFR - is met. - - The evaluator is reminded that the objective of each description is to provide - potential consumers of the TOE with a high-level view of how the developer intends - to satisfy each SFR and that the descriptions therefore should not be overly detailed. - Often several SFRs will be implemented in one context; for instance a password - authentication mechanism may implement , - and . - Therefore usually the TSS will not consist of a long list with texts for each single - SFR, but complete groups of SFRs may be covered by one text passage. - - For a composed TOE, the evaluator also determines that - it is clear which component provides each SFR or how the - components combine to meet each SFR. - - - - The evaluator shall confirm that the TOE summary - specification is consistent with the TOE overview and the - TOE description. - - - The evaluator shall examine the TOE summary - specification to determine that it is consistent with - the TOE overview and the TOE description. - - The TOE overview, TOE description, and TOE summary - specification describe the TOE in a narrative form at - increasing levels of detail. These descriptions - therefore need to be consistent. - - - - - - - - - - The objective of this sub-activity is to determine whether - the TOE summary specification addresses all SFRs, whether - the TOE summary specification addresses interference, - logical tampering and bypass, and whether the TOE summary - specification is consistent with other narrative - descriptions of the TOE. - - - - The evaluation evidence for this sub-activity is: - - - the ST. - - - - - The developer shall provide a TOE summary specification. - - - The TOE summary specification shall describe how the TOE - meets each SFR. - - - The TOE summary specification shall describe how the TOE - protects itself against interference and logical tampering. - - - The TOE summary specification shall describe how the TOE - protects itself against bypass. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the TOE summary - specification to determine that it describes how the TOE - meets each SFR. - - The evaluator determines that the TOE summary - specification provides, for each SFR from the statement - of security requirements, a description on how that SFR - is met. - - The evaluator is reminded that the objective of each description is to provide - potential consumers of the TOE with a high-level view of how the developer intends - to satisfy each SFR and that the descriptions therefore should not be overly detailed. - Often several SFRs will be implemented in one context; for instance a password - authentication mechanism may implement , - and . - Therefore usually the TSS will not consist of a long list with texts for each single - SFR, but complete groups of SFRs may be covered by one text passage. - - For a composed TOE, the evaluator also determines that - it is clear which component provides each SFR or how the - components combine to meet each SFR. - - - - - The evaluator shall examine the TOE summary - specification to determine that it describes how the TOE - protects itself against interference and logical - tampering. - - The evaluator is reminded that the objective of each - description is to provide potential consumers of the TOE - with a high-level view of how the developer intends to - provide protection against interference and logical - tampering and that the descriptions therefore should not - be overly detailed. - - For a composed TOE, the evaluator also determines that - it is clear which component provides the protection or - how the components combine to provide protection. - - - - - The evaluator shall examine the TOE summary - specification to determine that it describes how the TOE - protects itself against bypass. - - The evaluator is reminded that the objective of each - description is to provide potential consumers of the TOE - with a high-level view of how the developer intends to - provide protection against bypass and that the - descriptions therefore should not be overly - detailed. - - For a composed TOE, the evaluator also determines that - it is clear which component provides the protection or - how the components combine to provide protection. - - - - The evaluator shall confirm that the TOE summary - specification is consistent with the TOE overview and the - TOE description. - - - The evaluator shall examine the TOE summary - specification to determine that it is consistent with - the TOE overview and the TOE description. - - The TOE overview, TOE description, and TOE summary - specification describe the TOE in a narrative form at - increasing levels of detail. These descriptions - therefore need to be consistent. - - - - - - - - - The class ``Tests'' encompasses four families: , , - (i.e. functional testing - performed by evaluators), and . Testing provides assurance that the TSF - behaves as described (in the functional specification, TOE - design, and implementation representation). - - The emphasis in this class is on confirmation that the TSF - operates according to its design descriptions. This class does - not address penetration testing, which is based upon an - analysis of the TSF that specifically seeks to identify - vulnerabilities in the design and implementation of the - TSF. Penetration testing is addressed separately as an aspect - of vulnerability assessment in the class. - - The class separates testing into - developer testing and evaluator testing. The and families address the completeness of developer - testing. addresses the rigour - with which the functional specification is tested; addresses whether testing against - other design descriptions (security architecture, TOE design, - implementation representation) is required. - - addresses the performing of - the tests by the developer and how this testing should be - documented. Finally, then - addresses evaluator testing: whether the evaluator should - repeat part or all of the developer testing and how much - independent testing the evaluator should do. - - - - Assurance class states testing - requirements that demonstrate that the TOE matches its design - descriptions as provided in the - class. - - - - The goal of this activity is to determine whether the TOE - behaves as described in the ST and as specified in the - evaluation evidence (described in the class). This determination is achieved through - some combination of the developer's own functional testing of - the TSF () and independent - testing the TSF by the evaluator (). At the lowest level of assurance, there is no - requirement for developer involvement, so the only testing is - conducted by the evaluator, using the limited available - information about the TOE. Additional assurance is gained as - the developer becomes increasingly involved both in testing - and in providing additional information about the TOE, and as - the evaluator increases the independent testing - activities. - - - - Testing of the TSF is conducted by the evaluator and, in most - cases, by the developer. The evaluator's testing efforts - consist not only of creating and running original tests, but - also of assessing the adequacy of the developer's tests and - re-running a subset of them. - - The evaluator analyses the developer's tests to determine the - extent to which they are sufficient to demonstrate that TSFI - (see ) perform as specified, - and to understand the developer's approach to - testing. Similarly, the evaluator analyses the developer's - tests to determine the extent to which they are sufficient to - demonstrate the internal behaviour and properties of the - TSF. - The evaluator also executes a subset of the developer's - tests as documented to gain confidence in the developer's test - results: the evaluator will use the results of this analysis - as an input to independently testing a subset of the TSF. With - respect to this subset, the evaluator takes a testing approach - that is different from that of the developer, particularly if - the developer's tests have shortcomings. - - To determine the adequacy of developer's test documentation or - to create new tests, the evaluator needs to understand the - desired expected behaviour of the TSF, both internally and as - seen at the TSFI, in the context of the SFRs it is to - satisfy. The evaluator may choose to divide the TSF and TSFI - into subsets according to functional areas of the ST (audit - subsystem, audit-related TSFI, authentication module, - authentication-related TSFI, etc.) if they were not already - divided in the ST, and focus on one subset of the TSF and TSFI - at a time, examining the ST requirement and the relevant parts - of the development and guidance documentation to gain an - understanding of the way the TOE is expected to behave. This - reliance upon the development documentation underscores the need - for the dependencies on by and . - - The CC has separated coverage and depth from functional tests - to increase the flexibility when applying the components of - the families. However, the requirements of the families are - intended to be applied together to confirm that the TSF - operates according to its specification. This tight coupling - of families has led to some duplication of evaluator work - units across sub-activities. These application notes are used - to minimise duplication of text between sub-activities. - - - Before the adequacy of test documentation can be accurately - evaluated, or before new tests can be created, the evaluator - has to understand the desired expected behaviour of a - security function in the context of the requirements it is - to satisfy. - - As mentioned earlier, the evaluator may choose to subset the - TSF and TSFI according to SFRs (audit, authentication, etc.) - in the ST and focus on one subset at a time. The evaluator - examines each ST requirement and the relevant parts of the - functional specification and guidance documentation to gain - an understanding of the way the related TSFI is expected to - behave. Similarly, the evaluator examines the relevant parts - of the TOE design and security architecture documentation to - gain an understanding of the way the related modules or - subsystems of the TSF are expected to behave. - - With an understanding of the expected behaviour, the - evaluator examines the test plan to gain an understanding of - the testing approach. In most cases, the testing approach - will entail a TSFI being stimulated and its responses - observed. Externally-visible functionality can be tested - directly; however, in cases where functionality is not - visible external to the TOE (for example, testing the - residual information protection functionality), other means - will need to be employed. - - - - In cases where it is impractical or inadequate to test - specific functionality (where it provides no - externally-visible TSFI), the test plan should identify the - alternate approach to verify expected behaviour. It is the - evaluator's responsibility to determine the suitability of - the alternate approach. However, the following should be - considered when assessing the suitability of alternate - approaches: - - - an analysis of the implementation representation to - determine that the required behaviour should be - exhibited by the TOE is an acceptable alternate - approach. This could mean a code inspection for a - software TOE or perhaps a chip mask inspection for a - hardware TOE. - - - it is acceptable to use evidence of developer - integration or module testing, even if the claimed - assurance requirements do not include availability of - lower level descriptions of the TOE modules (e.g. ) or implementation (). If evidence of developer - integration or module testing is used in verifying the - expected behaviour of a security functionality, care - should be given to confirm that the testing evidence - reflects the current implementation of the TOE. If the - subsystems or modules have been changed since testing - occurred, evidence that the changes were tracked and - addressed by analysis or further testing will usually be - required. - - - - It should be emphasised that supplementing the testing - effort with alternate approaches should only be undertaken - when both the developer and evaluator determine that there - exists no other practical means to test the expected - behaviour. - - - - Test pre-requisites are necessary to establish the required - initial conditions for the test. They may be expressed in - terms of parameters that must be set or in terms of test - ordering in cases where the completion of one test - establishes the necessary pre-requisites for another - test. The evaluator must determine that the pre-requisites - are complete and appropriate in that they will not bias the - observed test results towards the expected test - results. - - The test steps and expected results specify the actions and - parameters to be applied to the TSFI as well as how the - expected results should be verified and what they are. The - evaluator must determine that the test steps and expected - results are consistent with the descriptions of the TSFI in - the functional specification. This means that each - characteristic of the TSFI behaviour explicitly described in - the functional specification should have tests and expected - results to verify that behaviour. - - The overall aim of this testing activity is to determine - that each subsystem, module, and TSFI has been sufficiently - tested against the behavioural claims in the functional - specification, TOE design, and architecture description. At - the higher assurance levels, testing also includes bounds - testing and negative testing. The test procedures will - provide insight as to how the TSFIs, modules, and subsystems - have been exercised by the developer during testing. The - evaluator uses this information when developing additional - tests to independently test the TSF. - - - - - - This family establishes that the TSF has been tested against - its functional specification. This is achieved through an - examination of developer evidence of correspondence. - - - - Coverage deals with the completeness of the functional tests - performed by the developer on the TOE. It addresses the - extent to which the TSF is tested. - - - - The components in this family are levelled on the basis of - specification. - - - - - - - - - - The objective of this component is to establish that some - of the TSFIs have been tested. - - - - In this component the developer shows how tests in the - test documentation correspond to TSFIs in the functional - specification. This can be achieved by a statement of - correspondence, perhaps using a table. - - - - The objective of this sub-activity is to determine whether - the developer has tested the TSFIs, and that the - developer's test coverage evidence shows correspondence - between the tests identified in the test documentation and - the TSFIs described in the functional - specification. - - - - The coverage analysis provided by the developer is - required to show the correspondence between the tests - provided as evaluation evidence and the functional - specification. However, the coverage analysis need not - demonstrate that all TSFI have been tested, or that all - externally-visible interfaces to the TOE have been - tested. Such shortcomings are considered by the evaluator - during the independent testing () sub-activity. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the functional specification; - - - the test documentation; - - - the test coverage evidence. - - - - - The developer shall provide evidence of the test coverage. - - - The evidence of the test coverage shall show the - correspondence between the tests in the test documentation - and the TSFIs in the functional specification. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the test coverage evidence - to determine that the correspondence between the tests - identified in the test documentation and the TSFIs - described in the functional specification is - accurate. - - Correspondence may take the form of a table or - matrix. The coverage evidence required for this - component will reveal the extent of coverage, rather - than to show complete coverage. In cases where coverage - is shown to be poor the evaluator should increase the - level of independent testing to compensate. - - - - - - - - - - The objective of this component is to confirm that all of - the TSFIs have been tested. - - - - In this component the developer confirms that tests in the - test documentation correspond to all of the TSFIs in the - functional specification. This can be achieved by a - statement of correspondence, perhaps using a table, but - the developer also provides an analysis of the test - coverage. - - - - The objective of this sub-activity is to determine whether - the developer has tested all of the TSFIs, and that the - developer's test coverage evidence shows correspondence - between the tests identified in the test documentation and - the TSFIs described in the functional - specification. - - - - - - the ST; - - - the functional specification; - - - the test documentation; - - - the test coverage analysis. - - - - - The developer shall provide an analysis of the test - coverage. - - - The analysis of the test coverage shall demonstrate the - correspondence between the tests in the test documentation - and the TSFIs in the functional specification. - - - The analysis of the test coverage shall demonstrate that all - TSFIs in the functional specification have been tested. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the test coverage analysis - to determine that the correspondence between the tests - in the test documentation and the interfaces in the - functional specification is accurate. - - A simple cross-table may be sufficient to show test - correspondence. The identification of the tests and the - interfaces presented in the test coverage analysis has - to be unambiguous. - - The evaluator is reminded that this does not imply that - all tests in the test documentation must map to - interfaces in the functional specification. - - - - - The evaluator shall examine the test plan to determine - that the testing approach for each interface - demonstrates the expected behaviour of that - interface. - - Guidance on this work unit can be found in: - - - - - - - - - - - - - The evaluator shall examine the test procedures to - determine that the test prerequisites, test steps and - expected result(s) adequately test each - interface. - - Guidance on this work units, as it pertains to the - functional specification, can be found in: - - - - - - - - - - The evaluator shall examine the test coverage analysis - to determine that the correspondence between the - interfaces in the functional specification and the tests - in the test documentation is complete. - - All TSFIs that are described in the functional - specification have to be present in the test coverage - analysis and mapped to tests in order for completeness - to be claimed, although exhaustive specification testing - of interfaces is not required. Incomplete coverage would - be evident if an interface was identified in the - functional specification and no test was mapped to - it. - - The evaluator is reminded that this does not imply that - all tests in the test documentation must map to - interfaces in the functional specification. - - - - - - - - - - In this component, the objective is to confirm that the - developer performed exhaustive tests of all interfaces in - the functional specification. - - The objective of this component is to confirm that all - parameters of all of the TSFIs have been tested. - - - - In this component the developer is required to show how - tests in the test documentation correspond to all of the - TSFIs in the functional specification. This can be - achieved by a statement of correspondence, perhaps using a - table, but in addition the developer is required to - demonstrate that the tests exercise all of the parameters - of all TSFIs. This additional requirement includes bounds - testing (i.e. verifying that errors are generated when - stated limits are exceeded) and negative testing - (e.g. when access is given to User A, verifying not only - that User A now has access, but also that User B did not - suddenly gain access). This kind of testing is not, - strictly speaking, exhaustive because not - every possible value of the parameters is expected to be - checked. - - - The developer shall provide an analysis of the test - coverage. - - - The analysis of the test coverage shall demonstrate the - correspondence between the tests in the test documentation - and the TSFIs in the functional specification. - - - The analysis of the test coverage shall demonstrate that all - TSFIs in the functional specification have been completely - tested. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - - - - The components in this family deal with the level of detail - to which the TSF is tested by the developer. Testing of the - TSF is based upon increasing depth of information derived - from additional design representations and descriptions (TOE - design, implementation representation, and security - architecture description). - - The objective is to counter the risk of missing an error in - the development of the TOE. Testing that exercises specific - internal interfaces can provide assurance not only that the - TSF exhibits the desired external security behaviour, but - also that this behaviour stems from correctly operating - internal functionality. - - - - Depth deals with the level of detail to which the developer - tests the TSF. Testing is based upon increasing depth of - information derived from analysis of the TSF - representations. - - - - The components in this family are levelled on the basis of - increasing detail provided in the TSF representations, from - the TOE design to the implementation representation. This - levelling reflects the TSF representations presented in the - class. - - - - The TOE design describes the internal components - (e.g. subsystems) and, perhaps, modules of the TSF, together - with a description of the interfaces among these components and - modules. Evidence of testing of this TOE design must show that - the internal interfaces have been exercised and seen to behave - as described. This may be achieved through testing via the - external interfaces of the TSF, or by testing of the TOE - subsystem or module interfaces in isolation, perhaps employing a - test harness. In cases where some aspects of an internal - interface cannot be tested via the external interfaces, there - should either be justification that these aspects need not be - tested, or the internal interface needs to be tested - directly. In the latter case the TOE design needs to be - sufficiently detailed in order to facilitate direct - testing. - - In cases where the description of the TSF's architectural - soundness (in ) cites - specific mechanisms, the tests performed by the developer - must show that the mechanisms have been exercised and seen - to behave as described. - - At the highest component of this family, the testing is - performed not only against the TOE design, but also against - the implementation representation. - - - - - - - - The subsystem descriptions of the TSF provide a high-level - description of the internal workings of the TSF. Testing - at the level of the TOE subsystems provides assurance that - the TSF subsystems behave and interact as described in the - TOE design and the security architecture - description. - - - - The objective of this sub-activity is to determine whether - the developer has tested the TSF subsystems against the - TOE design and the security architecture - description. - - - - - - the ST; - - - the functional specification; - - - the TOE design; - - - the security architecture description; - - - the test documentation; - - - the depth of testing analysis. - - - - - The developer shall provide the analysis of the depth of - testing. - - - The analysis of the depth of testing shall demonstrate the - correspondence between the tests in the test documentation - and the TSF subsystems in the TOE design. - - - The analysis of the depth of testing shall demonstrate that - all TSF subsystems in the TOE design have been tested. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the depth of testing - analysis to determine that the descriptions of the - behaviour of TSF subsystems and of their interactions is - included within the test documentation. - - This work unit verifies the content of the - correspondence between the tests and the descriptions in - the TOE design. In cases where the description of the - TSF's architectural soundness (in ) cites specific mechanisms, this work - unit also verifies the correspondence between the tests - and the descriptions of the behaviour of such - mechanisms. - - A simple cross-table may be sufficient to show test - correspondence. The identification of the tests and the - behaviour/interaction presented in the depth-of coverage - analysis has to be unambiguous. - - When is combined with a component of , which includes descriptions at the module level - (e.g. ), the level of detail needed to map - the test cases to the behaviour of the subsystems may require - information from the module description to be used. This is - because allows the description of details - to be shifted from the subsystem level to the module level, or - even to omit the subsystems altogether. - In any case, the required level of detail in the provided - reference to the tested behaviour can be defined as ``the level - of detail required for the description of subsystem behaviour as - defined by (in particular work unit )''. It states that a detailed description of - the behaviour typically discusses how the functionality is - provided, in terms of what key data and data structures re - present; what control relationships exist within a subsytem and - how these elements work together to provide the SFR-enforcing - behaviour. - The evaluator is reminded that not all tests in the test - documentation must map to a subsystem behaviour or - interaction description. - - - - - The evaluator shall examine the test plan, test - prerequisites, test steps and expected result(s) to - determine that the testing approach for the behaviour - description demonstrates the behaviour of that subsystem - as described in the TOE design. - - Guidance on this work unit can be found in: - - - - - - - - - - When is combined with a component of , which includes descriptions at the module level - (e.g. ), the level of detail needed to map - the test cases to the behaviour of the subsystems may require - information from the module description to be used. This is - because allows the description of details - to be shifted from the subsystem level to the module level, or - even to omit the subsystems altogether. - In any case, the required level of detail in the provided - reference to the tested behaviour can be defined as ``the level - of detail required for the description of subsystem behaviour as - defined by (in particular work unit )''. It states that a detailed description of - the behaviour typically discusses how the functionality is - provided, in terms of what key data and data structures re - present; what control relationships exist within a subsytem and - how these elements work together to provide the SFR-enforcing - behaviour. - If TSF subsystem interfaces are described, the behaviour - of those subsystems may be tested directly from those - interfaces. Otherwise, the behaviour of those subsystems - is tested from the TSFI interfaces. Or a combination of - the two may be employed. Whatever strategy is used the - evaluator will consider its appropriateness for - adequately testing the behaviour that is described in - the TOE design. - - - - - The evaluator shall examine the test plan, test - prerequisites, test steps and expected result(s) to - determine that the testing approach for the behaviour - description demonstrates the interactions among - subsystems as described in the TOE design. - - While the previous work unit addresses behaviour of subsystems, - this work unit addresses the interactions among - subsystems. - - Guidance on this work unit can be found in: - - - - - - - - - - If TSF subsystem interfaces are described, the - interactions with other subsystems may be tested - directly from those interfaces. Otherwise, the - interactions among subsystems must be inferred from the - TSFI interfaces. Whatever strategy is used the evaluator - will consider its appropriateness for adequately testing - the interactions among subsystems that are described in - the TOE design. - - - - - The evaluator shall examine the test procedures to - determine that all descriptions of TSF subsystem - behaviour and interaction are tested. - - This work unit verifies the completeness of work unit - . All descriptions - of TSF subsystem behaviour and of interactions among TSF - subsystems that are provided in the TOE design have to - be tested. Incomplete depth of testing would be evident - if a description of TSF subsystem behaviour or of - interactions among TSF subsystems was identified in the - TOE design and no tests could be attributed to - it. - - When is combined with a component of , which includes descriptions at the module level - (e.g. ), the level of detail needed to map - the test cases to the behaviour of the subsystems may require - information from the module description to be used. This is - because allows the description of details - to be shifted from the subsystem level to the module level, or - even to omit the subsystems altogether. - In any case, the required level of detail in the provided - reference to the tested behaviour can be defined as ``the level - of detail required for the description of subsystem behaviour as - defined by (in particular work unit )''. It states that a detailed description of - the behaviour typically discusses how the functionality is - provided, in terms of what key data and data structures re - present; what control relationships exist within a subsytem and - how these elements work together to provide the SFR-enforcing - behaviour. - The evaluator is reminded that this does not imply that all - tests in the test documentation must map to the subsystem behaviour - or interaction description in the TOE design. - - - - - - - - - - - The subsystem and module descriptions of the TSF provide a - high-level description of the internal workings, and a - description of the interfaces of the SFR-enforcing - modules, of the TSF. Testing at this level of TOE - description provides assurance that the TSF subsystems and - SFR-enforcing modules behave and interact as described in - the TOE design and the security architecture - description. - - - - The objective of this sub-activity is to determine whether the - developer has tested all the TSF subsystems and SFR-enforcing - modules against the TOE design and the security architecture - description. - - - - - - the ST; - - - the functional specification; - - - the TOE design; - - - the security architecture description; - - - the test documentation; - - - the depth of testing analysis. - - - - - The developer shall provide the analysis of the depth of - testing. - - - The analysis of the depth of testing shall demonstrate the - correspondence between the tests in the test documentation and - the TSF subsystems and SFR-enforcing modules in the TOE design. - - - The analysis of the depth of testing shall demonstrate that - all TSF subsystems in the TOE design have been tested. - - - The analysis of the depth of testing shall demonstrate that - the SFR-enforcing modules in the TOE design have been - tested. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the depth of testing - analysis to determine that descriptions of the behaviour - of TSF subsystems and of their interactions are included - within the test documentation. - - This work unit verifies the content of the - correspondence between the tests and the descriptions in - the TOE design. In cases where the description of the - TSF's architectural soundness (in ) cites specific mechanisms, this work - unit also verifies the correspondence between the tests - and the descriptions of the behaviour of such - mechanisms. - - A simple cross-table may be sufficient to show test - correspondence. The identification of the tests and the - behaviour/interaction presented in the depth-of coverage - analysis has to be unambiguous. - - The evaluator is reminded that not all tests in the test - documentation must map to a subsystem behaviour or - interaction description. - - - - - The evaluator shall examine the test plan, test - prerequisites, test steps and expected result(s) to - determine that the testing approach for the behaviour - description demonstrates the behaviour of that subsystem - as described in the TOE design. - - Guidance on this work unit can be found in: - - - - - - - - - - If TSF subsystem interfaces are described, the behaviour - of those subsystems may be tested directly from those - interfaces. Otherwise, the behaviour of those subsystems - is tested from the TSFI interfaces. Or a combination of - the two may be employed. Whatever strategy is used the - evaluator will consider its appropriateness for - adequately testing the behaviour that is described in - the TOE design. - - - - - The evaluator shall examine the test plan, test - prerequisites, test steps and expected result(s) to - determine that the testing approach for the behaviour - description demonstrates the interactions among - subsystems as described in the TOE design. - - While the previous work unit addresses behaviour of subsystems, - this work unit addresses the interactions among - subsystems. - - Guidance on this work unit can be found in: - - - - - - - - - - If TSF subsystem interfaces are described, the - interactions with other subsystems may be tested - directly from those interfaces. Otherwise, the - interactions among subsystems must be inferred from the - TSFI interfaces. Whatever strategy is used the evaluator - will consider its appropriateness for adequately testing - the interactions among subsystems that are described in - the TOE design. - - - - - The evaluator shall examine the depth of testing - analysis to determine that the interfaces of - SFR-enforcing modules are included within the test - documentation. - - This work unit verifies the content of the - correspondence between the tests and the descriptions in - the TOE design. In cases where the description of the - TSF's architectural soundness (in ) cites specific mechanisms at the modular - level, this work unit also verifies the correspondence - between the tests and the descriptions of the behaviour - of such mechanisms. - - A simple cross-table may be sufficient to show test - correspondence. The identification of the tests and the - SFR-enforcing modules presented in the depth-of coverage - analysis has to be unambiguous. - - The evaluator is reminded that not all tests in the test - documentation must map to the interfaces of SFR-enforcing modules. - - - - - The evaluator shall examine the test plan, test prerequisites, - test steps and expected result(s) to determine that the testing - approach for each SFR-enforcing module interface demonstrates - the expected behaviour of that interface. - - While work unit addresses - expected behaviour of subsystems, this work unit addresses - expected behaviour of the SFR-enforcing module interfaces that - are covered by . - - Guidance on this work unit can be found in: - - - - - - - - - Testing of an interface may be performed directly - at that interface, or at the external interfaces, or a - combination of both. Whatever strategy is used the - evaluator will consider its appropriateness for - adequately testing the interfaces. Specifically the - evaluator determines whether testing at the internal - interfaces is necessary or whether these internal - interfaces can be adequately tested (albeit implicitly) - by exercising the external interfaces. This - determination is left to the evaluator, as is its - justification. - - - - - The evaluator shall examine the test procedures to - determine that all descriptions of TSF subsystem - behaviour and interaction are tested. - - This work unit verifies the completeness of work unit - . All descriptions - of TSF subsystem behaviour and of interactions among TSF - subsystems that are provided in the TOE design have to - be tested. Incomplete depth of testing would be evident - if a description of TSF subsystem behaviour or of - interactions among TSF subsystems was identified in the - TOE design and no tests could be attributed to - it. - - The evaluator is reminded that this does not imply that all - tests in the test documentation must map to the subsystem behaviour - or interaction description in the TOE design. - - - - - The evaluator shall examine the test procedures to - determine that all interfaces of SFR-enforcing modules - are tested. - - This work unit verifies the completeness of work unit - . All interfaces - of SFR-enforcing modules that are provided in the TOE - design have to be tested. Incomplete depth of testing - would be evident if any interface of any SFR-enforcing - modules was identified in the TOE design and no tests - could be attributed to it. - The evaluator is reminded that this does not imply - that all tests in the test documentation must map to an - interface of an SFR-enforcing module in the TOE - design. - - - - - - - - - - - The subsystem and module descriptions of the TSF provide a - high-level description of the internal workings, and a - description of the interfaces of the modules, of the - TSF. Testing at this level of TOE description provides - assurance that the TSF subsystems and modules behave and - interact as described in the TOE design and the security - architecture description. - - - - The objective of this sub-activity is to determine whether the - developer has tested the all the TSF subsystems and modules - against the TOE design and the security architecture - description. - - - - - - the ST; - - - the functional specification; - - - the TOE design; - - - the security architecture description; - - - the test documentation; - - - the depth of testing analysis. - - - - - The developer shall provide the analysis of the depth of - testing. - - - The analysis of the depth of testing shall demonstrate the - correspondence between the tests in the test documentation - and the TSF subsystems and modules in the TOE design. - - - The analysis of the depth of testing shall demonstrate that - all TSF subsystems in the TOE design have been tested. - - - The analysis of the depth of testing shall demonstrate that all - TSF modules in the TOE design have been tested. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the depth of testing - analysis to determine that descriptions of the behaviour - of TSF subsystems and of their interactions are included - within the test documentation. - - This work unit verifies the content of the - correspondence between the tests and the descriptions in - the TOE design. A simple cross-table may be sufficient - to show test correspondence. The identification of the - tests and the behaviour/interaction presented in the - depth-of coverage analysis has to be unambiguous. - - The evaluator is reminded that not all tests in the test - documentation must map to a subsystem behaviour or - interaction description. - - - - - The evaluator shall examine the test plan, test - prerequisites, test steps and expected result(s) to - determine that the testing approach for the behaviour - description demonstrates the behaviour of that subsystem - as described in the TOE design. - - Guidance on this work unit can be found in: - - - - - - - - - - If TSF subsystem interfaces are provided, the behaviour - of those subsystems may be performed directly from those - interfaces. Otherwise, the behaviour of those subsystems - is tested from the TSFI interfaces. Or a combination of - the two may be employed. Whatever strategy is used the - evaluator will consider its appropriateness for - adequately testing the behaviour that is described in - the TOE design. - - - - - The evaluator shall examine the test plan, test - prerequisites, test steps and expected result(s) to - determine that the testing approach for the behaviour - description demonstrates the interactions among - subsystems as described in the TOE design. - - Guidance on this work unit can be found in: - - - - - - - - - While the previous work unit addresses behaviour of subsystems, - this work unit addresses the interactions among - subsystems. - - If TSF subsystem interfaces are provided, the - interactions with other subsystems may be performed - directly from those interfaces. Otherwise, the - interactions among subsystems must be inferred from the - TSFI interfaces. Whatever strategy is used the evaluator - will consider its appropriateness for adequately testing - the interactions among subsystems that are described in - the TOE design. - - - - - The evaluator shall examine the depth of testing - analysis to determine that the interfaces of TSF modules - are included within the test documentation. - - This work unit verifies the content of the - correspondence between the tests and the descriptions in - the TOE design. A simple cross-table may be sufficient - to show test correspondence. The identification of the - tests and the behaviour/interaction presented in the - depth-of coverage analysis has to be unambiguous. - - The evaluator is reminded that not all tests in the test - documentation must map to a subsystem behaviour or - interaction description. - - - - - The evaluator shall examine the test plan, test - prerequisites, test steps and expected result(s) to - determine that the testing approach for each TSF module - interface demonstrates the expected behaviour of that - interface. - - Guidance on this work unit can be found in: - - - - - - - - - Testing of an interface may be performed directly - at that interface, or at the external interfaces, or a - combination of both. Whatever strategy is used the - evaluator will consider its appropriateness for - adequately testing the interfaces. Specifically the - evaluator determines whether testing at the internal - interfaces is necessary or whether these internal - interfaces can be adequately tested (albeit implicitly) - by exercising the external interfaces. This - determination is left to the evaluator, as is its - justification. - - - - - The evaluator shall examine the test procedures to - determine that all descriptions of TSF subsystem - behaviour and interaction are tested. - - This work unit verifies the completeness of work unit - . All descriptions - of TSF subsystem behaviour and of interactions among TSF - subsystems that are provided in the TOE design have to - be tested. Incomplete depth of testing would be evident - if a description of TSF subsystem behaviour or of - interactions among TSF subsystems was identified in the - TOE design and no tests could be attributed to - it. - - The evaluator is reminded that this does not imply that all - tests in the test documentation must map to the subsystem behaviour - or interaction description in the TOE design. - - - - - The evaluator shall examine the test procedures to determine - that all interfaces of all TSF modules are tested. - - This work unit verifies the completeness of work unit - . All interfaces - of TSF modules that are provided in the TOE design have - to be tested. Incomplete depth of testing would be - evident if any interface of any TSF module was - identified in the TOE design and no tests could be - attributed to it. - The evaluator is reminded that this does not imply - that all tests in the test documentation must map to an - interface of a TSF module in the TOE design. - - - - - - - - - - - - The subsystem and module descriptions of the TSF provide a - high-level description of the internal workings, and a - description of the interfaces of the modules, of the - TSF. Testing at this level of TOE description provides - assurance that the TSF subsystems and modules behave and - interact as described in the TOE design and the security - architecture description, and in accordance with the - implementation representation. - - - The developer shall provide the analysis of the depth of - testing. - - - The analysis of the depth of testing shall demonstrate the - correspondence between the tests in the test documentation - and the TSF subsystems and modules in the TOE design. - - - The analysis of the depth of testing shall demonstrate that - all TSF subsystems in the TOE design have been tested. - - - The analysis of the depth of testing shall demonstrate that - all modules in the TOE design have been tested. - - - The analysis of the depth of testing shall demonstrate that - the TSF operates in accordance with its implementation - representation. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - - - - Functional testing performed by the developer provides - assurance that the tests in the test documentation are - performed and documented correctly. The correspondence of - these tests to the design descriptions of the TSF is - achieved through the and - families. - - This family contributes to providing assurance that the - likelihood of undiscovered flaws is relatively small. - - The families , and are used in combination to define the evidence - of testing to be supplied by a developer. Independent - functional testing by the evaluator is specified by . - - - - Functional testing establishes that the tests performed by - the developer are performed and documented correctly. - - - - This family contains two components, the higher requiring - that ordering dependencies are analysed. - - - - Procedures for performing tests are expected to provide - instructions for using test programs and test suites, - including the test environment, test conditions, test data - parameters and values. The test procedures should also show - how the test results are derived from the test - inputs. - - Ordering dependencies are relevant when the successful - execution of a particular test depends upon the existence of - a particular state. For example, this might require that - test A be executed immediately before test B, since the - state resulting from the successful execution of test A is a - prerequisite for the successful execution of test B. Thus, - failure of test B could be related to a problem with the - ordering dependencies. In the above example, test B could - fail because test C (rather than test A) was executed - immediately before it, or the failure of test B could be - related to a failure of test A. - - - - - - The objective is for the developer to demonstrate that the - tests in the test documentation are performed and - documented correctly. - - - - The objective of this sub-activity is to determine whether - the developer correctly performed and documented the tests - in the test documentation. - - - - The extent to which the test documentation is required to - cover the TSF is dependent upon the coverage assurance - component. - - For the developer tests provided, the evaluator determines - whether the tests are repeatable, and the extent to which - the developer's tests can be used for the evaluator's - independent testing effort. Any TSFI for which the - developer's test results indicate that it might not - perform as specified should be tested independently by the - evaluator to determine whether or not it does. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the functional specification; - - - the test documentation. - - - - - The developer shall test the TSF and document the results. - - - The developer shall provide test documentation. - - - The test documentation shall consist of test plans, expected - test results and actual test results. - - - The test plans shall identify the tests to be performed and - describe the scenarios for performing each test. These - scenarios shall include any ordering dependencies on the - results of other tests. - - - The expected test results shall show the anticipated outputs - from a successful execution of the tests. - - - The actual test results shall be consistent with the - expected test results. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall check that the test documentation - includes test plans, expected test results and actual - test results. - - The evaluator checks that test plans, expected tests - results and actual test results are included in the test - documentation. - - - - - The evaluator shall examine the test plan to determine - that it describes the scenarios for performing each - test. - - The evaluator determines that the test plan provides - information about the test configuration being used: - both on the configuration of the TOE and on any test - equipment being used. This information should be - detailed enough to ensure that the test configuration is - reproducible. - - The evaluator also determines that the test plan - provides information about how to execute the test: any - necessary automated set-up procedures (and whether they - require privilege to run), inputs to be applied, how - these inputs are applied, how output is obtained, any - automated clean-up procedures (and whether they require - privilege to run), etc. This information should be - detailed enough to ensure that the test is - reproducible. - - The evaluator may wish to employ a sampling strategy - when performing this work unit. - - - - - The evaluator shall examine the test plan to determine - that the TOE test configuration is consistent with the - ST. - - The TOE referred to in the developer's test plan should - have the same unique reference as established by the - sub-activities and - identified in the ST introduction. - - It is possible for the ST to specify more than one - configuration for evaluation. The evaluator verifies - that all test configurations identified in the developer - test documentation are consistent with the ST. For - example, the ST might define configuration options that - must be set, which could have an impact upon what - constitutes the TOE by including or excluding additional - portions. The evaluator verifies that all such - variations of the TOE are considered. - - The evaluator should consider the security objectives - for the operational environment described in the ST that - may apply to the test environment. There may be some - objectives for the operational environment that do not - apply to the test environment. For example, an objective - about user clearances may not apply; however, an - objective about a single point of connection to a - network would apply. - - The evaluator may wish to employ a sampling strategy - when performing this work unit. - - If this work unit is applied to a component TOE that - might be used/integrated in a composed TOE (see ), the following will apply. In - the instances that the component TOE under evaluation - depends on other components in the operational - environment to support their operation, the developer - may wish to consider using the other component(s) that - will be used in the composed TOE to fulfil the - requirements of the operational environment as one of - the test configurations. This will reduce the amount an - additional testing that will be required for the - composed TOE evaluation. - - - - - The evaluator shall examine the test plans to determine - that sufficient instructions are provided for any - ordering dependencies. - - Some steps may have to be performed to establish initial - conditions. For example, user accounts need to be added - before they can be deleted. An example of ordering - dependencies on the results of other tests is the need - to perform actions in a test that will result in the - generation of audit records, before performing a test to - consider the searching and sorting of those audit - records. Another example of an ordering dependency - would be where one test case generates a file of data to - be used as input for another test case. - - The evaluator may wish to employ a sampling strategy - when performing this work unit. - - - - - The evaluator shall examine the test documentation to - determine that all expected tests results are - included. - - The expected test results are needed to determine - whether or not a test has been successfully - performed. Expected test results are sufficient if they - are unambiguous and consistent with expected behaviour - given the testing approach. - - The evaluator may wish to employ a sampling strategy - when performing this work unit. - - - - - The evaluator shall check that the actual test results - in the test documentation are consistent with the - expected test results in the test documentation. - - A comparison of the actual and expected test results - provided by the developer will reveal any - inconsistencies between the results. It may be that a - direct comparison of actual results cannot be made until - some data reduction or synthesis has been first - performed. In such cases, the developer's test - documentation should describe the process to reduce or - synthesise the actual data. - - For example, the developer may need to test the contents - of a message buffer after a network connection has - occurred to determine the contents of the buffer. The - message buffer will contain a binary number. This binary - number would have to be converted to another form of - data representation in order to make the test more - meaningful. The conversion of this binary representation - of data into a higher-level representation will have to - be described by the developer in enough detail to allow - an evaluator to perform the conversion process - (i.e. synchronous or asynchronous transmission, number - of stop bits, parity, etc.). - - It should be noted that the description of the process - used to reduce or synthesise the actual data is used by - the evaluator not to actually perform the necessary - modification but to assess whether this process is - correct. It is up to the developer to transform the - expected test results into a format that allows an easy - comparison with the actual test results. - - The evaluator may wish to employ a sampling strategy - when performing this work unit. - - - - - The evaluator shall report the developer testing effort, - outlining the testing approach, configuration, depth and - results. - - The developer testing information recorded in the ETR allows the - evaluator to convey the overall testing approach and effort - expended on the testing of the TOE by the developer. The intent - of providing this information is to give a meaningful overview - of the developer testing effort. It is not intended that the - information regarding developer testing in the ETR be an exact - reproduction of specific test steps or results of individual - tests. The intention is to provide enough detail to allow other - evaluators and evaluation authorities to gain some insight about the - developer's testing approach, amount of testing performed, TOE - test configurations, and the overall results of the developer - testing. - - Information that would typically be found in the ETR - subclause regarding the developer testing effort is: - - - TOE test configurations. The particular - configurations of the TOE that were tested, - including whether any privileged code was required - to set up the test or clean up afterwards; - - - testing approach. An account of the overall - developer testing strategy employed; - - - testing results. A description of the overall - developer testing results. - - - - This list is by no means exhaustive and is only intended - to provide some context as to the type of information - that should be present in the ETR concerning the - developer testing effort. - - - - - - - - - The objectives are for the developer to demonstrate that - the tests in the test documentation are performed and - documented correctly, and to ensure that testing is - structured such as to avoid circular arguments about the - correctness of the interfaces being tested. - - - - Although the test procedures may state pre-requisite - initial test conditions in terms of ordering of tests, - they may not provide a rationale for the ordering. An - analysis of test ordering is an important factor in - determining the adequacy of testing, as there is a - possibility of faults being concealed by the ordering of - tests. - - - The developer shall test the TSF and document the results. - - - The developer shall provide test documentation. - - - The test documentation shall consist of test plans, expected - test results and actual test results. - - - The test plans shall identify the tests to be performed and - describe the scenarios for performing each test. These - scenarios shall include any ordering dependencies on the - results of other tests. - - - The expected test results shall show the anticipated outputs - from a successful execution of the tests. - - - The actual test results shall be consistent with the - expected test results. - - - The test documentation shall include an analysis of the test - procedure ordering dependencies. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - - - - The objectives of this family are built upon the assurances - achieved in the , , and - families by verifying the developer testing and performing - additional tests by the evaluator. - - - - Independent testing specifies the degree to which the - testing of the TSF must be performed by a party other than - the developer (e.g. a third party). This family adds value - by the introduction of tests that are not part of the - developer's tests. - - - - Levelling is based upon the amount of developer test - documentation and test support and the amount of evaluator - testing. - - - - This family deals with the degree to which there is - independent functional testing of the TSF. Independent - functional testing may take the form of repeating the - developer's functional tests (in whole or in part) or of - extending the scope or the depth of the developer's - tests. These activities are complementary, and an - appropriate mix must be planned for each TOE, which takes - into account the availability and coverage of test results, - and the functional complexity of the TSF. - - Sampling of developer tests is intended to provide - confirmation that the developer has carried out his planned - test programme on the TSF, and has correctly recorded the - results. The size of sample selected will be influenced by - the detail and quality of the developer's functional test - results. The evaluator will also need to consider the scope - for devising additional tests, and the relative benefit that - may be gained from effort in these two areas. It is - recognised that repetition of all developer tests may be - feasible and desirable in some cases, but may be very - arduous and less productive in others. The highest component - in this family should therefore be used with - caution. Sampling will address the whole range of test - results available, including those supplied to meet the - requirements of both and - . - - There is also a need to consider the different - configurations of the TOE that are included within the - evaluation. The evaluator will need to assess the - applicability of the results provided, and to plan his own - testing accordingly. - - The suitability of the TOE for testing is based on the - access to the TOE, and the supporting documentation and - information required (including any test software or tools) - to run tests. The need for such support is addressed by the - dependencies to other assurance families. - - Additionally, suitability of the TOE for testing may be - based on other considerations. For example, the version of - the TOE submitted by the developer may not be the final - version. - - The term interfaces refers to interfaces - described in the functional specification and TOE design, - and parameters passed through invocations identified in the - implementation representation. The exact set of interfaces - to be used is selected through and the - components. - - References to a subset of the interfaces are intended to - allow the evaluator to design an appropriate set of tests - which is consistent with the objectives of the evaluation - being conducted. - - - - - - - - In this component, the objective is to demonstrate that - the TOE operates in accordance with its design - representations and guidance documents. - - - - This component does not address the use of developer test - results. It is applicable where such results are not - available, and also in cases where the developer's testing - is accepted without validation. The evaluator is required - to devise and conduct tests with the objective of - confirming that the TOE operates in accordance with its - design representations, including but not limited to the - functional specification. The approach is to gain - confidence in correct operation through representative - testing, rather than to conduct every possible test. The - extent of testing to be planned for this purpose is a - methodology issue, and needs to be considered in the - context of a particular TOE and the balance of other - evaluation activities. - - - - The goal of this activity is to determine, by - independently testing a subset of the TSFI, whether the - TOE behaves as specified in the functional specification - and guidance documentation. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the functional specification; - - - the operational user guidance; - - - the preparative user guidance; - - - the TOE suitable for testing. - - - - - The developer shall provide the TOE for testing. - - - The TOE shall be suitable for testing. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the TOE to determine that - the test configuration is consistent with the - configuration under evaluation as specified in the - ST. - - The TOE provided by the developer should have the same - unique reference as established by the sub-activities and identified - in the ST introduction. - - It is possible for the ST to specify more than one - configuration for evaluation. The TOE may comprise a - number of distinct hardware and software entities that - need to be tested in accordance with the ST. The - evaluator verifies that all test configurations are - consistent with the ST. - - The evaluator should consider the security objectives - for the operational environment described in the ST that - may apply to the test environment and ensure they are - met in the testing environment. There may be some - objectives for the operational environment that do not - apply to the test environment. For example, an objective - about user clearances may not apply; however, an - objective about a single point of connection to a - network would apply. - - If any test resources are used (e.g. meters, analysers) - it will be the evaluator's responsibility to ensure that - these resources are calibrated correctly. - - - - - The evaluator shall examine the TOE to determine that it - has been installed properly and is in a known - state. - - It is possible for the evaluator to determine the state - of the TOE in a number of ways. For example, previous - successful completion of the sub-activity will satisfy this work unit - if the evaluator still has confidence that the TOE being - used for testing was installed properly and is in a - known state. If this is not the case, then the evaluator - should follow the developer's procedures to install and - start up the TOE, using the supplied guidance - only. - - If the evaluator has to perform the installation - procedures because the TOE is in an unknown state, this - work unit when successfully completed could satisfy work - unit . - - - - The evaluator shall test a subset of the TSF to confirm that - the TSF operates as specified. - - - The evaluator shall devise a test subset. - - The evaluator selects a test subset and testing strategy - that is appropriate for the TOE. One extreme testing - strategy would be to have the test subset contain as - many interfaces as possible tested with little - rigour. Another testing strategy would be to have the - test subset contain a few interfaces based on their - perceived relevance and rigorously test these - interfaces. - - Typically the testing approach taken by the evaluator - should fall somewhere between these two extremes. The - evaluator should exercise most of the interfaces using - at least one test, but testing need not demonstrate - exhaustive specification testing. - - The evaluator, when selecting the subset of the - interfaces to be tested, should consider the following - factors: - - - The number of interfaces from which to draw upon for - the test subset. Where the TSF includes only a small - number of relatively simple interfaces, it may be - practical to rigorously test all of the - interfaces. In other cases this may not be - cost-effective, and sampling is required. - - - Maintaining a balance of evaluation activities. The - evaluator effort expended on the test activity - should be commensurate with that expended on any - other evaluation activity. - - - - The evaluator selects the interfaces to compose the - subset. This selection will depend on a number of - factors, and consideration of these factors may also - influence the choice of test subset size: - - - Significance of interfaces. Those interfaces more - significant than others should be included in the - test subset. One major factor of ``significance'' is - the security-relevance (SFR-enforcing interfaces - would be more significant than SFR-supporting - interfaces, which are more significant than - SFR-non-interfering interfaces; see CC Part 3 - Subclause ). The other - major factor of ``significance'' is the number of - SFRs mapping to this interface (as determined when - identifying the correspondence between levels of - abstraction in ). - - - Complexity of the interface. Complex interfaces may - require complex tests that impose onerous - requirements on the developer or evaluator, which - may not be conducive to cost-effective - evaluations. Conversely, they are a likely area to - find errors and are good candidates for the - subset. The evaluator will need to strike a balance - between these considerations. - - - Implicit testing. Testing some interfaces may often - implicitly test other interfaces, and their - inclusion in the subset may maximise the number of - interfaces tested (albeit implicitly). Certain - interfaces will typically be used to provide a - variety of security functionality, and will tend to - be the target of an effective testing approach. - - - Types of interfaces (e.g. programmatic, - command-line, protocol). The evaluator should - consider including tests for all different types of - interfaces that the TOE supports. - - - Interfaces that give rise to features that are - innovative or unusual. Where the TOE contains - innovative or unusual features, which may feature - strongly in marketing literature and guidance - documents, the corresponding interfaces should be - strong candidates for testing. - - - - This guidance articulates factors to consider during the - selection process of an appropriate test subset, but - these are by no means exhaustive. - - - The evaluator shall produce test documentation for the - test subset that is sufficiently detailed to enable the - tests to be reproducible. - - With an understanding of the expected behaviour of the - TSF, from the ST and the functional specification, the - evaluator has to determine the most feasible way to test - the interface. Specifically the evaluator considers: - - - the approach that will be used, for instance, - whether an external interface will be tested, or an - internal interface using a test harness, or will an - alternate test approach be employed (e.g. in - exceptional circumstances, a code inspection, if the - implementation representation is available); - - - the interface(s) that will be used to test and - observe responses; - - - the initial conditions that will need to exist for - the test (i.e. any particular objects or subjects - that will need to exist and security attributes they - will need to have); - - - special test equipment that will be required to - either stimulate an interface (e.g. packet - generators) or make observations of an interface - (e.g. network analysers). - - - - The evaluator may find it practical to test each - interface using a series of test cases, where each test - case will test a very specific aspect of expected - behaviour. - - The evaluator's test documentation should specify the - derivation of each test, tracing it back to the relevant - interface(s). - - - The evaluator shall conduct testing. - - The evaluator uses the test documentation developed as a - basis for executing tests on the TOE. The test - documentation is used as a basis for testing but this - does not preclude the evaluator from performing - additional ad hoc tests. The evaluator may devise new - tests based on behaviour of the TOE discovered during - testing. These new tests are recorded in the test - documentation. - - - The evaluator shall record the following information - about the tests that compose the test subset: - - - identification of the interface behaviour to be - tested; - - - instructions to connect and setup all required test - equipment as required to conduct the test; - - - instructions to establish all prerequisite test - conditions; - - - instructions to stimulate the interface; - - - instructions for observing the behaviour of the - interface; - - - descriptions of all expected results and the - necessary analysis to be performed on the observed - behaviour for comparison against expected results; - - - instructions to conclude the test and establish the - necessary post-test state for the TOE; - - - actual test results. - - - - The level of detail should be such that another - evaluator could repeat the tests and obtain an - equivalent result. While some specific details of the - test results may be different (e.g. time and date fields - in an audit record) the overall result should be - identical. - - There may be instances when it is unnecessary to provide - all the information presented in this work unit - (e.g. the actual test results of a test may not require - any analysis before a comparison between the expected - results can be made). The determination to omit this - information is left to the evaluator, as is the - justification. - - - The evaluator shall check that all actual test results - are consistent with the expected test results. - - Any differences in the actual and expected test results - may indicate that the TOE does not perform as specified - or that the evaluator test documentation may be - incorrect. Unexpected actual results may require - corrective maintenance to the TOE or test documentation - and perhaps require re-running of impacted tests and - modifying the test sample size and composition. This - determination is left to the evaluator, as is its - justification. - - - The evaluator shall report in the ETR the evaluator - testing effort, outlining the testing approach, - configuration, depth and results. - - The evaluator testing information reported in the ETR allows the - evaluator to convey the overall testing approach and effort - expended on the testing activity during the evaluation. The - intent of providing this information is to give a meaningful - overview of the testing effort. It is not intended that the - information regarding testing in the ETR be an exact - reproduction of specific test instructions or results of - individual tests. The intention is to provide enough detail to - allow other evaluators and evaluation authorities to gain some insight about - the testing approach chosen, amount of testing performed, TOE - test configurations, and the overall results of the testing - activity. - - Information that would typically be found in the ETR - subclause regarding the evaluator testing effort is: - - - TOE test configurations. The particular - configurations of the TOE that were tested; - - - subset size chosen. The amount of interfaces that - were tested during the evaluation and a - justification for the size; - - - selection criteria for the interfaces that compose - the subset. Brief statements about the factors - considered when selecting interfaces for inclusion - in the subset; - - - interfaces tested. A brief listing of the interfaces - that merited inclusion in the subset; - - - verdict for the activity. The overall judgement on - the results of testing during the evaluation. - - - - This list is by no means exhaustive and is only intended - to provide some context as to the type of information - that should be present in the ETR concerning the testing - the evaluator performed during the evaluation. - - - - - - - - - - - - In this component, the objective is to demonstrate that - the TOE operates in accordance with its design - representations and guidance documents. Evaluator testing - confirms that the developer performed some tests of some - interfaces in the functional specification. - - - - The intent is that the developer should provide the - evaluator with materials necessary for the efficient - reproduction of developer tests. This may include such - things as machine-readable test documentation, test - programs, etc. - - This component contains a requirement that the evaluator - has available test results from the developer to - supplement the programme of testing. The evaluator will - repeat a sample of the developer's tests to gain - confidence in the results obtained. Having established - such confidence the evaluator will build upon the - developer's testing by conducting additional tests that - exercise the TOE in a different manner. By using a - platform of validated developer test results the evaluator - is able to gain confidence that the TOE operates correctly - in a wider range of conditions than would be possible - purely using the developer's own efforts, given a fixed - level of resource. Having gained confidence that the - developer has tested the TOE, the evaluator will also have - more freedom, where appropriate, to concentrate testing in - areas where examination of documentation or specialist - knowledge has raised particular concerns. - - - - The goal of this activity is to determine, by - independently testing a subset of the TSF, whether the TOE - behaves as specified in the design documentation, and to - gain confidence in the developer's test results by - performing a sample of the developer's tests. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the functional specification; - - - the TOE design description; - - - the operational user guidance; - - - the preparative user guidance; - - - the configuration management documentation; - - - the test documentation; - - - the TOE suitable for testing. - - - - - The developer shall provide the TOE for testing. - - - The TOE shall be suitable for testing. - - - The developer shall provide an equivalent set of resources - to those that were used in the developer's functional - testing of the TSF. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the TOE to determine that - the test configuration is consistent with the - configuration under evaluation as specified in the - ST. - - The TOE provided by the developer and identified in the - test plan should have the same unique reference as - established by the - sub-activities and identified in the ST - introduction. - - It is possible for the ST to specify more than one - configuration for evaluation. The TOE may comprise a - number of distinct hardware and software entities that - need to be tested in accordance with the ST. The - evaluator verifies that all test configurations are - consistent with the ST. - - The evaluator should consider the security objectives - for the operational environment described in the ST that - may apply to the test environment and ensure they are - met in the testing environment. There may be some - objectives for the operational environment that do not - apply to the test environment. For example, an objective - about user clearances may not apply; however, an - objective about a single point of connection to a - network would apply. - - If any test resources are used (e.g. meters, analysers) - it will be the evaluator's responsibility to ensure that - these resources are calibrated correctly. - - - - - The evaluator shall examine the TOE to determine that it has been installed properly and is in a known state. - - It is possible for the evaluator to determine the state - of the TOE in a number of ways. For example, previous - successful completion of the sub-activity will satisfy this work unit - if the evaluator still has confidence that the TOE being - used for testing was installed properly and is in a - known state. If this is not the case, then the evaluator - should follow the developer's procedures to install and - start up the TOE, using the supplied guidance - only. - - If the evaluator has to perform the installation - procedures because the TOE is in an unknown state, this - work unit when successfully completed could satisfy work - unit . - - - - - The evaluator shall examine the set of resources provided by the developer - to determine that they are equivalent to the set of resources used by the - developer to functionally test the TSF. - - The set of resource used by the developer is documented - in the developer test plan, as considered in the family. The resource set may - include laboratory access and special test equipment, - among others. Resources that are not identical to those - used by the developer need to be equivalent in terms of - any impact they may have on test results. - - - - The evaluator shall execute a sample of tests in the test - documentation to verify the developer test results. - - - The evaluator shall conduct testing using a sample of - tests found in the developer test plan and - procedures. - - The overall aim of this work unit is to perform a - sufficient number of the developer tests to confirm the - validity of the developer's test results. The evaluator - has to decide on the size of the sample, and the - developer tests that will compose the sample (see ). - - All the developer tests can be traced back to specific - interfaces. Therefore, the factors to consider in the - selection of the tests to compose the sample are similar - to those listed for subset selection in work-unit . Additionally, the - evaluator may wish to employ a random sampling method to - select developer tests to include in the sample. - - - - The evaluator shall check that all the actual test - results are consistent with the expected test - results. - - Inconsistencies between the developer's expected test - results and actual test results will compel the - evaluator to resolve the discrepancies. Inconsistencies - encountered by the evaluator could be resolved by a - valid explanation and resolution of the inconsistencies - by the developer. - - If a satisfactory explanation or resolution can not be reached, - the evaluator's confidence in the developer's test results may be - lessened and it may be necessary for the evaluator to increase - the sample size to the extent that the subset identified in work unit - is adequately tested: - deficiencies with the developer's tests need to result in either - corrective action to the TOE by the developer (e.g., if the inconsistency - is caused by incorrect behaviour) or to the developer's tests (e.g., if the - inconsistency is caused by an incorrect test), or in the production of new - tests by the evaluator. - - - - The evaluator shall test a subset of the TSF to confirm that the - TSF operates as specified. - - - The evaluator shall devise a test subset. - - The evaluator selects a test subset and testing strategy - that is appropriate for the TOE. One extreme testing - strategy would be to have the test subset contain as - many interfaces as possible tested with little - rigour. Another testing strategy would be to have the - test subset contain a few interfaces based on their - perceived relevance and rigorously test these - interfaces. - - Typically the testing approach taken by the evaluator - should fall somewhere between these two extremes. The - evaluator should exercise most of the interfaces using - at least one test, but testing need not demonstrate - exhaustive specification testing. - - The evaluator, when selecting the subset of the - interfaces to be tested, should consider the following - factors: - - - The developer test evidence. The developer test - evidence consists of: the test documentation, the - available test coverage analysis, and the available - depth of testing analysis. The developer test - evidence will provide insight as to how the TSF has - been exercised by the developer during testing. The - evaluator applies this information when developing - new tests to independently test the - TOE. Specifically the evaluator should consider: - - - augmentation of developer testing for - interfaces. The evaluator may wish to perform - more of the same type of tests by varying - parameters to more rigorously test the - interface. - - - supplementation of developer testing strategy - for interfaces. The evaluator may wish to vary - the testing approach of a specific interface by - testing it using another test strategy. - - - - - The number of interfaces from which to draw upon for - the test subset. Where the TSF includes only a small - number of relatively simple interfaces, it may be - practical to rigorously test all of them. In other - cases this may not be cost-effective, and sampling - is required. - - - Maintaining a balance of evaluation activities. The - evaluator effort expended on the test activity - should be commensurate with that expended on any - other evaluation activity. - - - - The evaluator selects the interfaces to compose the - subset. This selection will depend on a number of - factors, and consideration of these factors may also - influence the choice of test subset size: - - - Rigour of developer testing of the interfaces. Those - interfaces that the evaluator determines require - additional testing should be included in the test - subset. - - - Developer test results. If the results of developer - tests cause the evaluator to doubt that an interface - is not properly implemented, then the evaluator - should include such interfaces in the test subset. - - - Significance of interfaces. Those interfaces more - significant than others should be included in the - test subset. One major factor of ``significance'' is - the security-relevance (SFR-enforcing interfaces - would be more significant than SFR-supporting - interfaces, which are more significant than - SFR-non-interfering interfaces; see CC Part 3 - Subclause ). The other - major factor of ``significance'' is the number of - SFRs mapping to this interface (as determined when - identifying the correspondence between levels of - abstraction in ). - - - Complexity of interfaces. Interfaces that require - complex implementation may require complex tests - that impose onerous requirements on the developer or - evaluator, which may not be conducive to - cost-effective evaluations. Conversely, they are a - likely area to find errors and are good candidates - for the subset. The evaluator will need to strike a - balance between these considerations. - - - Implicit testing. Testing some interfaces may often - implicitly test other interfaces, and their - inclusion in the subset may maximise the number of - interfaces tested (albeit implicitly). Certain - interfaces will typically be used to provide a - variety of security functionality, and will tend to - be the target of an effective testing approach. - - - Types of interfaces (e.g. programmatic, - command-line, protocol). The evaluator should - consider including tests for all different types of - interfaces that the TOE supports. - - - Interfaces that give rise to features that are - innovative or unusual. Where the TOE contains - innovative or unusual features, which may feature - strongly in marketing literature and guidance - documents, the corresponding interfaces should be - strong candidates for testing. - - - - This guidance articulates factors to consider during the - selection process of an appropriate test subset, but - these are by no means exhaustive. - - - The evaluator shall produce test documentation for the - test subset that is sufficiently detailed to enable the - tests to be reproducible. - - With an understanding of the expected behaviour of the - TSF, from the ST, the functional specification, and the - TOE design description, the evaluator has to determine - the most feasible way to test the - interface. Specifically the evaluator considers: - - - the approach that will be used, for instance, - whether an external interface will be tested, or an - internal interface using a test harness, or will an - alternate test approach be employed (e.g. in - exceptional circumstances, a code inspection); - - - the interface(s) that will be used to test and - observe responses; - - - the initial conditions that will need to exist for - the test (i.e. any particular objects or subjects - that will need to exist and security attributes they - will need to have); - - - special test equipment that will be required to - either stimulate an interface (e.g. packet - generators) or make observations of an interface - (e.g. network analysers). - - - - The evaluator may find it practical to test each - interface using a series of test cases, where each test - case will test a very specific aspect of expected - behaviour of that interface. - - The evaluator's test documentation should specify the - derivation of each test, tracing it back to the relevant - interface(s). - - - The evaluator shall conduct testing. - - The evaluator uses the test documentation developed as a - basis for executing tests on the TOE. The test - documentation is used as a basis for testing but this - does not preclude the evaluator from performing - additional ad hoc tests. The evaluator may devise new - tests based on behaviour of the TOE discovered during - testing. These new tests are recorded in the test - documentation. - - - The evaluator shall record the following information - about the tests that compose the test subset: - - - identification of the interface behaviour to be - tested; - - - instructions to connect and setup all required test - equipment as required to conduct the test; - - - instructions to establish all prerequisite test - conditions; - - - instructions to stimulate the interface; - - - instructions for observing the interface; - - - descriptions of all expected results and the - necessary analysis to be performed on the observed - behaviour for comparison against expected results; - - - instructions to conclude the test and establish the - necessary post-test state for the TOE; - - - actual test results. - - - - The level of detail should be such that another - evaluator could repeat the tests and obtain an - equivalent result. While some specific details of the - test results may be different (e.g. time and date fields - in an audit record) the overall result should be - identical. - - There may be instances when it is unnecessary to provide - all the information presented in this work unit - (e.g. the actual test results of a test may not require - any analysis before a comparison between the expected - results can be made). The determination to omit this - information is left to the evaluator, as is the - justification. - - - The evaluator shall check that all actual test results - are consistent with the expected test results. - - Any differences in the actual and expected test results - may indicate that the TOE does not perform as specified - or that the evaluator test documentation may be - incorrect. Unexpected actual results may require - corrective maintenance to the TOE or test documentation - and perhaps require re-running of impacted tests and - modifying the test sample size and composition. This - determination is left to the evaluator, as is its - justification. - - - The evaluator shall report in the ETR the evaluator - testing effort, outlining the testing approach, - configuration, depth and results. - - The evaluator testing information reported in the ETR allows the - evaluator to convey the overall testing approach and effort - expended on the testing activity during the evaluation. The - intent of providing this information is to give a meaningful - overview of the testing effort. It is not intended that the - information regarding testing in the ETR be an exact - reproduction of specific test instructions or results of - individual tests. The intention is to provide enough detail to - allow other evaluators and evaluation authorities to gain some insight about - the testing approach chosen, amount of evaluator testing - performed, amount of developer tests performed, TOE test - configurations, and the overall results of the testing - activity. - - Information that would typically be found in the ETR - subclause regarding the evaluator testing effort is: - - - TOE test configurations. The particular - configurations of the TOE that were tested. - - - subset size chosen. The amount of interfaces that - were tested during the evaluation and a - justification for the size. - - - selection criteria for the interfaces that compose - the subset. Brief statements about the factors - considered when selecting interfaces for inclusion - in the subset. - - - Interfaces tested. A brief listing of the interfaces - that merited inclusion in the subset. - - - developer tests performed. The amount of developer - tests performed and a brief description of the - criteria used to select the tests. - - - verdict for the activity. The overall judgement on - the results of testing during the evaluation. - - - - This list is by no means exhaustive and is only intended - to provide some context as to the type of information - that should be present in the ETR concerning the testing - the evaluator performed during the evaluation. - - - - - - - - - - - In this component, the objective is to demonstrate - that the TOE operates in accordance with its design - representations and guidance documents. Evaluator testing - includes repeating all of the developer tests. - - - - The intent is that the developer should provide the - evaluator with materials necessary for the efficient - reproduction of developer tests. This may include such - things as machine-readable test documentation, test - programs, etc. - - In this component the evaluator must repeat all of the - developer's tests as part of the programme of testing. As - in the previous component the evaluator will also conduct - tests that aim to exercise the TSF in a different manner - from that achieved by the developer. In cases where - developer testing has been exhaustive, there may remain - little scope for this. - - - The developer shall provide the TOE for testing. - - - The TOE shall be suitable for testing. - - - The developer shall provide an equivalent set of resources - to those that were used in the developer's functional - testing of the TSF. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - The evaluator shall execute all tests in the test - documentation to verify the developer test results. - - - The evaluator shall test the TSF to confirm that the entire - TSF operates as specified. - - - - - - - - The class addresses the - possibility of exploitable vulnerabilities introduced in the - development or the operation of the TOE. - - - - Assurance class defines - requirements directed at the identification of exploitable - vulnerabilities. Specifically, it addresses those - vulnerabilities introduced in the development, operation, - misuse, or incorrect configuration of the TOE. - - - - Generally, the vulnerability assessment activity covers various - vulnerabilities in the development and operation of the - TOE. Development vulnerabilities take advantage of some property - of the TOE which was introduced during its development, - e.g. defeating the TSF self protection through tampering, direct - attack or monitoring of the TSF, defeating the TSF domain - separation through monitoring or direct attack the TSF, or - defeating non-bypassability through circumventing (bypassing) - the TSF. Operational vulnerabilities take advantage of - weaknesses in non-technical countermeasures to violate the TOE - SFRs, e.g. misuse or incorrect configuration. Misuse - investigates whether the TOE can be configured or used in a - manner that is insecure, but that an administrator or user of - the TOE would reasonably believe to be secure. - - Assessment of development vulnerabilities is covered by the - assurance family . Basically, - all development vulnerabilities can be considered in the - context of due to the fact, - that this family allows application of a wide range of - assessment methodologies being unspecific to the kind of an - attack scenario. These unspecific assessment methodologies - comprise, among other, also the specific methodologies for - those TSF where covert channels are to be considered (a - channel capacity estimation can be done using informal - engineering measurements, as well as actual test measurements) - or can be overcome by the use of sufficient resources in the - form of a direct attack (underlying technical concept of those - TSF is based on probabilistic or permutational mechanisms; a - qualification of their security behaviour and the effort - required to overcome them can be made using a quantitative or - statistical analysis). - - If there are security objectives specified in the ST to either - to prevent one user of the TOE from observing activity - associated with another user of the TOE, or to ensure that - information flows cannot be used to achieve enforced illicit - data signals, covert channel analysis should be considered - during the conduct of the vulnerability analysis. This is often - reflected by the inclusion of - and multilevel access control policies specified through and/or requirements in the ST. - - - - The purpose of the vulnerability assessment activity is to - determine the exploitability of flaws or weaknesses in the TOE - in the operational environment. This determination is based - upon analysis of the evaluation evidence and a search of - publicly available material by the evaluator and is supported - by evaluator penetration testing. - - - - - Vulnerability analysis is an assessment to determine whether - potential vulnerabilities identified, during the evaluation - of the development and anticipated operation of the TOE or - by other methods (e.g. by flaw hypotheses or quantitative or - statistical analysis of the security behaviour of the - underlying security mechanisms), could allow attackers to - violate the SFRs. - - Vulnerability analysis deals with the threats that an - attacker will be able to discover flaws that will allow - unauthorised access to data and functionality, allow the - ability to interfere with or alter the TSF, or interfere - with the authorised capabilities of other users. - - - - Vulnerability analysis consists of the identification of - flaws potentially introduced in the different refinement - steps of the development (development vulnerabilities) or - through the application of the guidance in operation of the - TOE (operational vulnerabilities). It results in the - definition of penetration tests through the collection of - the necessary information concerning: (1) the completeness - of the TSF (does the TSF counter all the postulated - threats?), (2) the dependencies between all SFRs and (3) - whether any of the SFRs can be undermined through unexpected - behaviour of the TOE. These potential vulnerabilities are - assessed through penetration testing to determine whether - they could, in practise, be exploitable to compromise the - security of the TOE. - - The characteristics of different levels of attack potential - are discussed in CEM . - - - - Levelling is based on an increasing rigour of vulnerability - analysis by the evaluator and increased levels of attack - potential required by an attacker to identify and exploit - the potential vulnerabilities. - - - - - - - - A vulnerability survey of information available in the - public domain is performed by the evaluator to ascertain - potential vulnerabilities that may be easily found by an - attacker. - - The evaluator performs penetration testing, to confirm - that the potential vulnerabilities cannot be exploited in - the operational environment for the TOE. Penetration - testing is performed by the evaluator assuming an attack - potential of Basic. - - - - The objective of this sub-activity is to determine whether - the TOE, in its operational environment, has easily - identifiable exploitable vulnerabilities. - - - - The evaluator should consider performing additional tests - as a result of potential vulnerabilities encountered - during the conduct of other parts of the - evaluation. - - The use of the term guidance in this sub-activity refers - to the operational guidance and the preparative - guidance. - - Potential vulnerabilities may be in information that is - publicly available, or not, and may require skill to - exploit, or not. These two aspects are related, but are - distinct. It should not be assumed that, simply because a - potential vulnerability is identifiable from information - that is publicly available, it can be easily - exploited. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - - the guidance documentation; - - - the TOE suitable for testing; - - - information publicly available to support the - identification of potential vulnerabilities. - - - - Other input for this sub-activity is: - - - current information regarding potential - vulnerabilities (e.g. from an evaluation authority). - - - - - The developer shall provide the TOE for testing. - - - The TOE shall be suitable for testing. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the TOE to determine that - the test configuration is consistent with the - configuration under evaluation as specified in the - ST. - - The TOE provided by the developer and identified in the - test plan should have the same unique reference as - established by the - sub-activities and identified in the ST - introduction. - - It is possible for the ST to specify more than one - configuration for evaluation. The TOE may comprise a - number of distinct hardware and software entities that - need to be tested in accordance with the ST. The - evaluator verifies that all test configurations are - consistent with the ST. - - The evaluator should consider the security objectives - for the operational environment described in the ST that - may apply to the test environment and ensure they are - met in the testing environment. There may be some - objectives for the operational environment that do not - apply to the test environment. For example, an objective - about user clearances may not apply; however, an - objective about a single point of connection to a - network would apply. - - If any test resources are used (e.g. meters, analysers) - it will be the evaluator's responsibility to ensure that - these resources are calibrated correctly. - - - - - The evaluator shall examine the TOE to determine that it - has been installed properly and is in a known - state - - It is possible for the evaluator to determine the state - of the TOE in a number of ways. For example, previous - successful completion of the sub-activity will satisfy this work unit - if the evaluator still has confidence that the TOE being - used for testing was installed properly and is in a - known state. If this is not the case, then the evaluator - should follow the developer's procedures to install and - start up the TOE, using the supplied guidance - only. - - If the evaluator has to perform the installation - procedures because the TOE is in an unknown state, this - work unit when successfully completed could satisfy work - unit . - - - - The evaluator shall perform a search of public domain - sources to identify potential vulnerabilities in the TOE. - - - The evaluator shall examine sources of information - publicly available to identify potential vulnerabilities - in the TOE. - - The evaluator examines the sources of information - publicly available to support the identification of - possible potential vulnerabilities in the TOE. There are - many sources of publicly available information, which - should be considered, e.g. mailing lists and security - forums on the world wide web that report known - vulnerabilities in specified technologies. - - The evaluator should not constrain their consideration - of publicly available information to the above, but - should consider any other relevant information - available. - - While examining the evidence provided the evaluator will - use the information in the public domain to further - search for potential vulnerabilities. Where the - evaluators have identified areas of concern, the - evaluator should consider information publicly available - that relate to those areas of concern. - - The availability of information that may be readily - available to an attacker that helps to identify and - facilitate attacks effectively operates to substantially - enhance the attack potential of a given attacker. The - accessibility of vulnerability information and - sophisticated attack tools on the Internet makes it more - likely that this information will be used in attempts to - identify potential vulnerabilities in the TOE and - exploit them. Modern search tools make such information - easily available to the evaluator, and the determination - of resistance to published potential vulnerabilities and - well known generic attacks can be achieved in a - cost-effective manner. - - The search of the information publicly available should - be focused on those sources that refer specifically to - the product from which the TOE is derived. The - extensiveness of this search should consider the - following factors: TOE type, evaluator experience in - this TOE type, expected attack potential and the level - of evidence available. - - The identification process is iterative, where the - identification of one potential vulnerability may lead - to identifying another area of concern that requires - further investigation. - - The evaluator will report what actions were taken to - identify potential vulnerabilities in the information - publicly available. However, in this type of search, the - evaluator may not be able to describe the steps in - identifying potential vulnerabilities before the outset - of the examination, as the approach may evolve as a - result of findings during the search. - - The evaluator will report the evidence examined in - completing the search for potential - vulnerabilities. - - - - The evaluator shall record in the ETR the identified - potential vulnerabilities that are candidates for - testing and applicable to the TOE in its operational - environment. - - It may be identified that no further consideration of - the potential vulnerability is required if for example - the evaluator identifies that measures in the - operational environment, either IT or non-IT, prevent - exploitation of the potential vulnerability in that - operational environment. For instance, restricting - physical access to the TOE to authorised users only may - effectively render a potential vulnerability to - tampering unexploitable. - - The evaluator records any reasons for exclusion of - potential vulnerabilities from further consideration if - the evaluator determines that the potential - vulnerability is not applicable in the operational - environment. Otherwise the evaluator records the - potential vulnerability for further - consideration. - - A list of potential vulnerabilities applicable to the - TOE in its operational environment, which can be used as - an input into penetration testing activities, shall be - reported in the ETR by the evaluators. - - - - The evaluator shall conduct penetration testing, based on - the identified potential vulnerabilities, to determine that - the TOE is resistant to attacks performed by an attacker - possessing Basic attack potential. - - - The evaluator shall devise penetration tests, based on - the independent search for potential - vulnerabilities. - - The evaluator prepares for penetration testing as necessary to - determine the susceptibility of the TOE, in its operational - environment, to the potential vulnerabilities identified during - the search of the sources of information publicly available. - Any current information provided to the evaluator by a third - party (e.g. evaluation authority) regarding known potential - vulnerabilities will be considered by the evaluator, together - with any encountered potential vulnerabilities resulting from - the performance of other evaluation activities. - - The evaluator will probably find it practical to carry - out penetration test using a series of test cases, where - each test case will test for a specific potential - vulnerability. - - The evaluator is not expected to test for potential - vulnerabilities (including those in the public domain) - beyond those which required a Basic attack potential. In - some cases, however, it will be necessary to carry out a - test before the exploitability can be determined. Where, - as a result of evaluation expertise, the evaluator - discovers a potential vulnerability that is beyond Basic - attack potential, this is reported in the ETR as a - residual vulnerability. - - - - The evaluator shall produce penetration test - documentation for the tests based on the list of - potential vulnerabilities in sufficient detail to enable - the tests to be repeatable. The test documentation shall - include: - - - identification of the potential vulnerability the - TOE is being tested for; - - - instructions to connect and setup all required test - equipment as required to conduct the penetration - test; - - - instructions to establish all penetration test - prerequisite initial conditions; - - - instructions to stimulate the TSF; - - - instructions for observing the behaviour of the TSF; - - - descriptions of all expected results and the - necessary analysis to be performed on the observed - behaviour for comparison against expected results; - - - instructions to conclude the test and establish the - necessary post-test state for the TOE. - - - - The evaluator prepares for penetration testing based on - the list of potential vulnerabilities identified during - the search of the public domain. - - The evaluator is not expected to determine the - exploitability for potential vulnerabilities beyond - those for which a Basic attack potential is required to - effect an attack. However, as a result of evaluation - expertise, the evaluator may discover a potential - vulnerability that is exploitable only by an attacker - with greater than Basic attack potential. Such - vulnerabilities are to be reported in the ETR as - residual vulnerabilities. - - With an understanding of the potential vulnerability, - the evaluator determines the most feasible way to test - for the TOE's susceptibility. Specifically the evaluator - considers: - - - the TSFI or other TOE interface that will be used to - stimulate the TSF and observe responses; - - - initial conditions that will need to exist for the - test (i.e. any particular objects or subjects that - will need to exist and security attributes they will - need to have); - - - special test equipment that will be required to - either stimulate a TSFI or make observations of a - TSFI (although it is unlikely that specialist - equipment would be required to exploit a potential - vulnerability assuming a Basic attack potential); - - - whether theoretical analysis should replace physical - testing, particularly relevant where the results of - an initial test can be extrapolated to demonstrate - that repeated attempts of an attack are likely to - succeed after a given number of attempts. - - - - The evaluator will probably find it practical to carry - out penetration testing using a series of test cases, - where each test case will test for a specific potential - vulnerability. - - The intent of specifying this level of detail in the - test documentation is to allow another evaluator to - repeat the tests and obtain an equivalent result. - - - - The evaluator shall conduct penetration testing. - - The evaluator uses the penetration test documentation - resulting from work unit as a basis for executing penetration tests - on the TOE, but this does not preclude the evaluator - from performing additional ad hoc penetration tests. If - required, the evaluator may devise ad hoc tests as a - result of information learnt during penetration testing - that, if performed by the evaluator, are to be recorded - in the penetration test documentation. Such tests may be - required to follow up unexpected results or - observations, or to investigate potential - vulnerabilities suggested to the evaluator during the - pre-planned testing. - - The evaluator is not expected to test for potential - vulnerabilities (including those in the public domain) - beyond those which required a Basic attack potential. In - some cases, however, it will be necessary to carry out a - test before the exploitability can be determined. Where, - as a result of evaluation expertise, the evaluator - discovers a potential vulnerability that is beyond Basic - attack potential, this is reported in the ETR as a - residual vulnerability. - - - - The evaluator shall record the actual results of the - penetration tests. - - While some specific details of the actual test results - may be different from those expected (e.g. time and date - fields in an audit record) the overall result should be - identical. Any unexpected test results should be - investigated. The impact on the evaluation should be - stated and justified. - - - - The evaluator shall report in the ETR the evaluator - penetration testing effort, outlining the testing - approach, configuration, depth and results. - - The penetration testing information reported in the ETR - allows the evaluator to convey the overall penetration - testing approach and effort expended on this - sub-activity. The intent of providing this information - is to give a meaningful overview of the evaluator's - penetration testing effort. It is not intended that the - information regarding penetration testing in the ETR be - an exact reproduction of specific test steps or results - of individual penetration tests. The intention is to - provide enough detail to allow other evaluators and - evaluation authorities to gain some insight about the - penetration testing approach chosen, amount of - penetration testing performed, TOE test configurations, - and the overall results of the penetration testing - activity. - - Information that would typically be found in the ETR - subclause regarding evaluator penetration testing efforts - is: - - - TOE test configurations. The particular - configurations of the TOE that were penetration - tested; - - - TSFI penetration tested. A brief listing of the TSFI - and other TOE interfaces that were the focus of the - penetration testing; - - - verdict for the sub-activity. The overall judgement - on the results of penetration testing. - - - - This list is by no means exhaustive and is only intended - to provide some context as to the type of information - that should be present in the ETR concerning the - penetration testing the evaluator performed during the - evaluation. - - - - The evaluator shall examine the results of all - penetration testing to determine that the TOE, in its - operational environment, is resistant to an attacker - possessing a Basic attack potential. - - If the results reveal that the TOE, in its operational - environment, has vulnerabilities exploitable by an - attacker possessing less than Enhanced-Basic attack - potential, then this evaluator action fails. - - The guidance in should be used to determine the attack - potential required to exploit a particular vulnerability - and whether it can therefore be exploited in the - intended environment. It may not be necessary for the - attack potential to be calculated in every instance, - only if there is some doubt as to whether or not the - vulnerability can be exploited by an attacker possessing - an attack potential less than Enhanced-Basic. - - - - The evaluator shall report in the ETR all exploitable - vulnerabilities and residual vulnerabilities, detailing - for each: - - - its source (e.g. CEM activity being undertaken when - it was conceived, known to the evaluator, read in a - publication); - - - the SFR(s) not met; - - - a description; - - - whether it is exploitable in its operational - environment or not (i.e. exploitable or residual). - - - the amount of time, level of expertise, level of - knowledge of the TOE, level of opportunity and the - equipment required to perform the identified - vulnerabilities, and the corresponding values using - the tables and - of Annex . - - - - - - - - - - - - - - - A vulnerability analysis is performed by the evaluator to - ascertain the presence of potential - vulnerabilities. - - The evaluator performs penetration testing, to confirm - that the potential vulnerabilities cannot be exploited in - the operational environment for the TOE. Penetration - testing is performed by the evaluator assuming an attack - potential of Basic. - - - - The objective of this sub-activity is to determine whether - the TOE, in its operational environment, has - vulnerabilities exploitable by attackers possessing Basic - attack potential. - - - - The evaluator should consider performing additional tests - as a result of potential vulnerabilities encountered - during other parts of the evaluation. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - the functional specification; - - the TOE design; - - the security architecture description; - - the guidance documentation; - - the TOE suitable for testing; - - information publicly available to support the - identification of possible potential - vulnerabilities. - - The remaining implicit evaluation evidence for this - sub-activity depends on the components that have been - included in the assurance package. The evidence provided - for each component is to be used as input in this - sub-activity. - - Other input for this sub-activity is: - - - current information regarding public domain potential - vulnerabilities and attacks (e.g. from an evaluation - authority). - - - - - The developer shall provide the TOE for testing. - - - The TOE shall be suitable for testing. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the TOE to determine that - the test configuration is consistent with the - configuration under evaluation as specified in the - ST. - - The TOE provided by the developer and identified in the - test plan should have the same unique reference as - established by the - sub-activities and identified in the ST - introduction. - - It is possible for the ST to specify more than one - configuration for evaluation. The TOE may comprise a - number of distinct hardware and software entities that - need to be tested in accordance with the ST. The - evaluator verifies that all test configurations are - consistent with the ST. - - The evaluator should consider the security objectives - for the operational environment described in the ST that - may apply to the test environment and ensure they are - met in the testing environment. There may be some - objectives for the operational environment that do not - apply to the test environment. For example, an objective - about user clearances may not apply; however, an - objective about a single point of connection to a - network would apply. - - If any test resources are used (e.g. meters, analysers) - it will be the evaluator's responsibility to ensure that - these resources are calibrated correctly. - - - - - The evaluator shall examine the TOE to determine that it - has been installed properly and is in a known - state - - It is possible for the evaluator to determine the state - of the TOE in a number of ways. For example, previous - successful completion of the sub-activity will satisfy this work unit - if the evaluator still has confidence that the TOE being - used for testing was installed properly and is in a - known state. If this is not the case, then the evaluator - should follow the developer's procedures to install and - start up the TOE, using the supplied guidance - only. - - If the evaluator has to perform the installation - procedures because the TOE is in an unknown state, this - work unit when successfully completed could satisfy work - unit . - - - - The evaluator shall perform a search of public domain - sources to identify potential vulnerabilities in the TOE. - - - The evaluator shall examine sources of information - publicly available to identify potential vulnerabilities - in the TOE. - - The evaluator examines the sources of information - publicly available to support the identification of - possible potential vulnerabilities in the TOE. There are - many sources of publicly available information which the - evaluator should consider using items such as those - available on the world wide web, including: - - - specialist publications (magazines, books); - - - research papers. - - - - The evaluator should not constrain their consideration - of publicly available information to the above, but - should consider any other relevant information - available. - - While examining the evidence provided the evaluator will - use the information in the public domain to further - search for potential vulnerabilities. Where the - evaluators have identified areas of concern, the - evaluator should consider information publicly available - that relate to those areas of concern. - - The availability of information that may be readily - available to an attacker that helps to identify and - facilitate attacks may substantially enhance the attack - potential of a given attacker. The accessibility of - vulnerability information and sophisticated attack tools - on the Internet makes it more likely that this - information will be used in attempts to identify - potential vulnerabilities in the TOE and exploit - them. Modern search tools make such information easily - available to the evaluator, and the determination of - resistance to published potential vulnerabilities and - well known generic attacks can be achieved in a - cost-effective manner. - - The search of the information publicly available should - be focused on those sources that refer specifically to - the product from which the TOE is derived. The - extensiveness of this search should consider the - following factors: TOE type, evaluator experience in - this TOE type, expected attack potential and the level - of evidence available. - - The identification process is iterative, where the - identification of one potential vulnerability may lead - to identifying another area of concern that requires - further investigation. - - The evaluator will report what actions were taken to - identify potential vulnerabilities in the - evidence. However, in this type of search, the evaluator - may not be able to describe the steps in identifying - potential vulnerabilities before the outset of the - examination, as the approach may evolve as a result of - findings during the search. - - The evaluator will report the evidence examined in - completing the search for potential - vulnerabilities. This selection of evidence may be - derived from those areas of concern identified by the - evaluator, linked to the evidence the attacker is - assumed to be able to obtain, or according to another - rationale provided by the evaluator. - - - - The evaluator shall perform an independent vulnerability - analysis of the TOE using the guidance documentation, - functional specification, TOE design and security - architecture description to identify potential - vulnerabilities in the TOE. - - - The evaluator shall conduct a search of ST, guidance - documentation, functional specification, TOE design and - security architecture description evidence to identify - possible potential vulnerabilities in the TOE. - - A search of the evidence should be completed whereby - specifications and documentation for the TOE are - analysed and then potential vulnerabilities in the TOE - are hypothesised, or speculated. The list of - hypothesised potential vulnerabilities is then - prioritised on the basis of the estimated probability - that a potential vulnerability exists and, assuming an - exploitable vulnerability does exist the attack - potential required to exploit it, and on the extent of - control or compromise it would provide. The prioritised - list of potential vulnerabilities is used to direct - penetration testing against the TOE. - - The security architecture description provides the - developer vulnerability analysis, as it documents how - the TSF protects itself from interference from untrusted - subjects and prevents the bypass of security enforcement - functionality. Therefore, the evaluator should use this - description of the protection of the TSF as a basis for - the search for possible ways to undermine the - TSF. - - Subject to the SFRs the TOE is to meet in the - operational environment, the evaluator's independent - vulnerability analysis should consider generic potential - vulnerabilities under each of the following headings: - - - generic potential vulnerabilities relevant for the - type of TOE being evaluated, as may be supplied by - the evaluation authority; - - bypassing; - - tampering; - - direct attacks; - - monitoring; - - misuse. - - Items b) - f) are explained in greater detail in . - - The security architecture description should be - considered in light of each of the above generic - potential vulnerabilities. Each potential vulnerability - should be considered to search for possible ways in - which to defeat the TSF protection and undermine the - TSF. - - - - The evaluator shall record in the ETR the identified - potential vulnerabilities that are candidates for - testing and applicable to the TOE in its operational - environment. - - It may be identified that no further consideration of - the potential vulnerability is required if for example - the evaluator identifies that measures in the - operational environment, either IT or non-IT, prevent - exploitation of the potential vulnerability in that - operational environment. For instance, restricting - physical access to the TOE to authorised users only may - effectively render a potential vulnerability to - tampering unexploitable. - - The evaluator records any reasons for exclusion of - potential vulnerabilities from further consideration if - the evaluator determines that the potential - vulnerability is not applicable in the operational - environment. Otherwise the evaluator records the - potential vulnerability for further - consideration. - - A list of potential vulnerabilities applicable to the - TOE in its operational environment, which can be used as - an input into penetration testing activities, shall be - reported in the ETR by the evaluators. - - - - The evaluator shall conduct penetration testing, based on - the identified potential vulnerabilities, to determine that - the TOE is resistant to attacks performed by an attacker - possessing Basic attack potential. - - - The evaluator shall devise penetration tests, based on - the independent search for potential - vulnerabilities. - - The evaluator prepares for penetration testing as necessary to - determine the susceptibility of the TOE, in its operational - environment, to the potential vulnerabilities identified during - the search of the sources of information publicly available. - Any current information provided to the evaluator by a third - party (e.g. evaluation authority) regarding known potential - vulnerabilities will be considered by the evaluator, together - with any encountered potential vulnerabilities resulting from - the performance of other evaluation activities. - - The evaluator is reminded that, as for considering the security - architecture description in the search for vulnerabilities (as - detailed in ), testing should - be performed to confirm the architectural properties. This is - likely to require negative tests attempting to disprove the - properties of the security architecture. In developing the - strategy for penetration testing, the evaluator will ensure that - each of the major characteristics of the security architecture - description are tested, either in functional testing (as - considered in ) or evaluator - penetration testing. - - The evaluator will probably find it practical to carry - out penetration test using a series of test cases, where - each test case will test for a specific potential - vulnerability. - - The evaluator is not expected to test for potential - vulnerabilities (including those in the public domain) - beyond those which required a Basic attack potential. In - some cases, however, it will be necessary to carry out a - test before the exploitability can be determined. Where, - as a result of evaluation expertise, the evaluator - discovers an exploitable vulnerability that is beyond - Basic attack potential, this is reported in the ETR as a - residual vulnerability. - - Guidance on determining the necessary attack potential - to exploit a potential vulnerability can be found in - Annex . - - Potential vulnerabilities hypothesised as exploitable - only by attackers possessing Enhanced-Basic, Moderate or - High attack potential do not result in a failure of this - evaluator action. Where analysis supports the - hypothesis, these need not be considered further as an - input to penetration testing. However, such - vulnerabilities are reported in the ETR as residual - vulnerabilities. - - Potential vulnerabilities hypothesised as exploitable by - an attacker possessing a Basic attack potential and - resulting in a violation of the security objectives - should be the highest priority potential vulnerabilities - comprising the list used to direct penetration testing - against the TOE. - - - - The evaluator shall produce penetration test - documentation for the tests based on the list of - potential vulnerabilities in sufficient detail to enable - the tests to be repeatable. The test documentation shall - include: - - - identification of the potential vulnerability the - TOE is being tested for; - - - instructions to connect and setup all required test - equipment as required to conduct the penetration - test; - - - instructions to establish all penetration test - prerequisite initial conditions; - - - instructions to stimulate the TSF; - - - instructions for observing the behaviour of the TSF; - - - descriptions of all expected results and the - necessary analysis to be performed on the observed - behaviour for comparison against expected results; - - - instructions to conclude the test and establish the - necessary post-test state for the TOE. - - - - The evaluator prepares for penetration testing based on - the list of potential vulnerabilities identified during - the search of the public domain and the analysis of the - evaluation evidence. - - The evaluator is not expected to determine the - exploitability for potential vulnerabilities beyond - those for which a Basic attack potential is required to - effect an attack. However, as a result of evaluation - expertise, the evaluator may discover a potential - vulnerability that is exploitable only by an attacker - with greater than Basic attack potential. Such - vulnerabilities are to be reported in the ETR as - residual vulnerabilities. - - With an understanding of the potential vulnerability, - the evaluator determines the most feasible way to test - for the TOE's susceptibility. Specifically the evaluator - considers: - - - the TSFI or other TOE interface that will be used to - stimulate the TSF and observe responses (It is - possible that the evaluator will need to use an - interface to the TOE other than the TSFI to - demonstrate properties of the TSF such as those - described in the security architecture description - (as required by ). It - should the noted, that although these TOE interfaces - provide a means of testing the TSF properties, they - are not the subject of the test.); - - - initial conditions that will need to exist for the - test (i.e. any particular objects or subjects that - will need to exist and security attributes they will - need to have); - - - special test equipment that will be required to - either stimulate a TSFI or make observations of a - TSFI (although it is unlikely that specialist - equipment would be required to exploit a potential - vulnerability assuming a Basic attack potential); - - - whether theoretical analysis should replace physical - testing, particularly relevant where the results of - an initial test can be extrapolated to demonstrate - that repeated attempts of an attack are likely to - succeed after a given number of attempts. - - - - The evaluator will probably find it practical to carry - out penetration testing using a series of test cases, - where each test case will test for a specific potential - vulnerability. - - The intent of specifying this level of detail in the - test documentation is to allow another evaluator to - repeat the tests and obtain an equivalent result. - - - - The evaluator shall conduct penetration testing. - - The evaluator uses the penetration test documentation - resulting from work unit as a basis for executing penetration tests - on the TOE, but this does not preclude the evaluator - from performing additional ad hoc penetration tests. If - required, the evaluator may devise ad hoc tests as a - result of information learnt during penetration testing - that, if performed by the evaluator, are to be recorded - in the penetration test documentation. Such tests may be - required to follow up unexpected results or - observations, or to investigate potential - vulnerabilities suggested to the evaluator during the - pre-planned testing. - - Should penetration testing show that a hypothesised - potential vulnerability does not exist, then the - evaluator should determine whether or not the - evaluator's own analysis was incorrect, or if evaluation - deliverables are incorrect or incomplete. - - The evaluator is not expected to test for potential - vulnerabilities (including those in the public domain) - beyond those which required a Basic attack potential. In - some cases, however, it will be necessary to carry out a - test before the exploitability can be determined. Where, - as a result of evaluation expertise, the evaluator - discovers an exploitable vulnerability that is beyond - basic attack potential, this is reported in the ETR as a - residual vulnerability. - - - - The evaluator shall record the actual results of the - penetration tests. - - While some specific details of the actual test results - may be different from those expected (e.g. time and date - fields in an audit record) the overall result should be - identical. Any unexpected test results should be - investigated. The impact on the evaluation should be - stated and justified. - - - - The evaluator shall report in the ETR the evaluator - penetration testing effort, outlining the testing - approach, configuration, depth and results. - - The penetration testing information reported in the ETR - allows the evaluator to convey the overall penetration - testing approach and effort expended on this - sub-activity. The intent of providing this information - is to give a meaningful overview of the evaluator's - penetration testing effort. It is not intended that the - information regarding penetration testing in the ETR be - an exact reproduction of specific test steps or results - of individual penetration tests. The intention is to - provide enough detail to allow other evaluators and - evaluation authorities to gain some insight about the - penetration testing approach chosen, amount of - penetration testing performed, TOE test configurations, - and the overall results of the penetration testing - activity. - - Information that would typically be found in the ETR - subclause regarding evaluator penetration testing efforts - is: - - - TOE test configurations. The particular - configurations of the TOE that were penetration - tested; - - - TSFI penetration tested. A brief listing of the TSFI - and other TOE interfaces that were the focus of the - penetration testing; - - - Verdict for the sub-activity. The overall judgement - on the results of penetration testing. - - - - This list is by no means exhaustive and is only intended - to provide some context as to the type of information - that should be present in the ETR concerning the - penetration testing the evaluator performed during the - evaluation. - - - - The evaluator shall examine the results of all - penetration testing to determine that the TOE, in its - operational environment, is resistant to an attacker - possessing a Basic attack potential. - - If the results reveal that the TOE, in its operational - environment, has vulnerabilities exploitable by an - attacker possessing less than an Enhanced-Basic attack - potential, then this evaluator action fails. - - The guidance in should be used to determine the attack - potential required to exploit a particular vulnerability - and whether it can therefore be exploited in the - intended environment. It may not be necessary for the - attack potential to be calculated in every instance, - only if there is some doubt as to whether or not the - vulnerability can be exploited by an attacker possessing - an attack potential less than Enhanced-Basic. - - - - The evaluator shall report in the ETR all exploitable - vulnerabilities and residual vulnerabilities, detailing - for each: - - - its source (e.g. CEM activity being undertaken when - it was conceived, known to the evaluator, read in a - publication); - - - the SFR(s) not met; - - - a description; - - - whether it is exploitable in its operational - environment or not (i.e. exploitable or residual). - - - the amount of time, level of expertise, level of - knowledge of the TOE, level of opportunity and the - equipment required to perform the identified - vulnerabilities, and the corresponding values using - the tables and - of Annex . - - - - - - - - - - - - - - - - A vulnerability analysis is performed by the evaluator to - ascertain the presence of potential - vulnerabilities. - - The evaluator performs penetration testing, to confirm - that the potential vulnerabilities cannot be exploited in - the operational environment for the TOE. Penetration - testing is performed by the evaluator assuming an attack - potential of Enhanced-Basic. - - - - The objective of this sub-activity is to determine whether - the TOE, in its operational environment, has - vulnerabilities exploitable by attackers possessing - Enhanced-Basic attack potential. - - - - During the conduct of evaluation activities the evaluator - may also identify areas of concern. These are specific - portions of the TOE evidence that the evaluator has some - reservation about, although the evidence meets the - requirements for the activity with which the evidence is - associated. For example, a particular interface - specification looks particularly complex, and therefore - may be prone to error either in the development of the TOE - or in the operation of the TOE. There is no potential - vulnerability apparent at this stage, further - investigation is required. This is beyond the bounds of - encountered, as further investigation is required. - - The focused approach to the identification of potential - vulnerabilities is an analysis of the evidence with the - aim of identifying any potential vulnerabilities evident - through the contained information. It is an unstructured - analysis, as the approach is not predetermined. Further - guidance on focused vulnerability analysis can be found in - Annex . - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - the functional specification; - - the TOE design; - - the security architecture description; - - the implementation subset selected; - - the guidance documentation; - - the TOE suitable for testing; - - information publicly available to support the identification of possible potential vulnerabilities; - - the results of the testing of the basic design. - - - The remaining implicit evaluation evidence for this - sub-activity depends on the components that have been - included in the assurance package. The evidence provided - for each component is to be used as input in this - sub-activity. - - Other input for this sub-activity is: - - - current information regarding public domain potential - vulnerabilities and attacks (e.g. from an evaluation - authority). - - - - - The developer shall provide the TOE for testing. - - - The TOE shall be suitable for testing. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the TOE to determine that - the test configuration is consistent with the - configuration under evaluation as specified in the - ST. - - The TOE provided by the developer and identified in the - test plan should have the same unique reference as - established by the - sub-activities and identified in the ST - introduction. - - It is possible for the ST to specify more than one - configuration for evaluation. The TOE may comprise a - number of distinct hardware and software entities that - need to be tested in accordance with the ST. The - evaluator verifies that all test configurations are - consistent with the ST. - - The evaluator should consider the security objectives - for the operational environment described in the ST that - may apply to the test environment and ensure they are - met in the testing environment. There may be some - objectives for the operational environment that do not - apply to the test environment. For example, an objective - about user clearances may not apply; however, an - objective about a single point of connection to a - network would apply. - - If any test resources are used (e.g. meters, analysers) - it will be the evaluator's responsibility to ensure that - these resources are calibrated correctly. - - - - - The evaluator shall examine the TOE to determine that it - has been installed properly and is in a known - state - - It is possible for the evaluator to determine the state - of the TOE in a number of ways. For example, previous - successful completion of the sub-activity will satisfy this work unit - if the evaluator still has confidence that the TOE being - used for testing was installed properly and is in a - known state. If this is not the case, then the evaluator - should follow the developer's procedures to install and - start up the TOE, using the supplied guidance - only. - - If the evaluator has to perform the installation - procedures because the TOE is in an unknown state, this - work unit when successfully completed could satisfy work - unit . - - - - The evaluator shall perform a search of public domain - sources to identify potential vulnerabilities in the TOE. - - - The evaluator shall examine sources of information - publicly available to identify potential vulnerabilities - in the TOE. - - The evaluator examines the sources of information - publicly available to support the identification of - possible potential vulnerabilities in the TOE. There are - many sources of publicly available information which the - evaluator should consider using items such as those - available on the world wide web, including: - - - specialist publications (magazines, books); - - - research papers; - - - conference proceedings. - - - - The evaluator should not constrain their consideration - of publicly available information to the above, but - should consider any other relevant information - available. - - While examining the evidence provided the evaluator will - use the information in the public domain to further - search for potential vulnerabilities. Where the - evaluators have identified areas of concern, the - evaluator should consider information publicly available - that relate to those areas of concern. - - The availability of information that may be readily - available to an attacker that helps to identify and - facilitate attacks may substantially enhance the attack - potential of a given attacker. The accessibility of - vulnerability information and sophisticated attack tools - on the Internet makes it more likely that this - information will be used in attempts to identify - potential vulnerabilities in the TOE and exploit - them. Modern search tools make such information easily - available to the evaluator, and the determination of - resistance to published potential vulnerabilities and - well known generic attacks can be achieved in a - cost-effective manner. - - The search of the information publicly available should - be focused on those sources that refer to the - technologies used in the development of the product from - which the TOE is derived. The extensiveness of this - search should consider the following factors: TOE type, - evaluator experience in this TOE type, expected attack - potential and the level of - evidence available. - - The identification process is iterative, where the - identification of one potential vulnerability may lead - to identifying another area of concern that requires - further investigation. - - The evaluator will report what actions were taken to - identify potential vulnerabilities in the - evidence. However, in this type of search, the evaluator - may not be able to describe the steps in identifying - potential vulnerabilities before the outset of the - examination, as the approach may evolve as a result of - findings during the search. - - The evaluator will report the evidence examined in - completing the search for potential - vulnerabilities. This selection of evidence may be - derived from those areas of concern identified by the - evaluator, linked to the evidence the attacker is - assumed to be able to obtain, or according to another - rationale provided by the evaluator. - - - - The evaluator shall perform an independent, focused vulnerability analysis of the - TOE using the guidance documentation, functional specification, TOE design, security - architecture description and implementation representation to identify potential - vulnerabilities in the TOE. - - - The evaluator shall conduct a focused search of ST, - guidance documentation, functional specification, TOE - design, security architecture description and - implementation representation to identify possible - potential vulnerabilities in the TOE. - - A flaw hypothesis methodology needs to be used whereby - specifications and development and guidance evidence are - analysed and then potential vulnerabilities in the TOE are - hypothesised, or speculated. - - The evaluator uses the knowledge of the TOE design and operation - gained from the TOE deliverables to conduct a flaw hypothesis to - identify potential flaws in the development of the TOE and - potential errors in the specified method of operation of the - TOE. - - The security architecture description provides the developer - vulnerability analysis, as it documents how the TSF protects - itself from interference from untrusted subjects and prevents - the bypass of security enforcement functionality. Therefore, the - evaluator should build upon the understanding of the TSF - protection gained from the analysis of this evidence and then - develop this in the knowledge gained from other development - evidence. - - - The approach taken is directed by areas of concern - identified during examination of the evidence during the - conduct of evaluation activities and ensuring a - representative sample of the development and guidance - evidence provided for the evaluation is searched. - - For guidance on sampling see Annex . This guidance - should be considered when selecting the subset, giving - reasons for: - - - the approach used in selection; - - - qualification that the evidence to be examined - supports that approach. - - - - The areas of concern may relate to the sufficiency of - specific protection features detailed in the security - architecture description. - - The evidence to be considered during the vulnerability analysis - may be linked to the evidence the attacker is assumed to be able - to obtain. For example, the developer may protect the TOE design - and implementation representations, so the only information - assumed to be available to an attacker is the functional - specification and guidance (publicly available). So, although - the objectives for assurance in the TOE ensure the TOE design - and implementation representation requirements are met, these - design representations may only be searched to further - investigate areas of concerns. - - On the other hand, if the source is publicly available it would - be reasonable to assume that the attacker has access to the - source and can use this in attempts to attack the - TOE. Therefore, the source should be considered in the focused - examination approach. - - The following indicates examples for the selection of - the subset of evidence to be considered: - - - For an evaluation where all levels of design - abstraction from functional specification to - implementation representation are provided, - examination of information in the functional - specification and the implementation representation - may be selected, as the functional specification - provides detail of interfaces available to an - attacker, and the implementation representation - incorporates the design decisions made at all other - design abstractions. Therefore, the TOE design - information will be considered as part of the - implementation representation. - - - Examination of a particular subset of information in - each of the design representations provided for the - evaluation. - - - Coverage of particular SFRs through each of the - design representations provided for the evaluation. - - - Examination of each of the design representations - provided for the evaluation, considering different - SFRs within each design representations. - - - Examination of aspects of the evidence provided for - the evaluation relating to current potential - vulnerability information the evaluator has received - (e.g. from a scheme). - - - - This approach to identification of potential - vulnerabilities is to take an ordered and planned - approach; applying a system to the examination. The - evaluator is to describe the method to be used in terms - of what evidence will be considered, the information - within the evidence that is to be examined, the manner - in which this information is to be considered and the - hypothesis that is to be created. - - The following provide some examples that a hypothesis - may take: - - - consideration of malformed input for interfaces - available to an attacker at the external interfaces; - - - examination of a key security mechanism cited in the - security architecture description, such as process - separation, hypothesising internal buffer overflows - that may lead to degradation of separation; - - - search to identify any objects created in the TOE - implementation representation that are then not - fully controlled by the TSF, and could be used by an - attacker to undermine SFRs. - - - - For example, the evaluator may identify that interfaces - are a potential area of weakness in the TOE and specify - an approach to the search that ``all interface - specifications provided in the functional specification - and TOE design will be searched to hypothesise potential - vulnerabilities'' and go on to explain the methods used - in the hypothesis. - - The identification process is iterative, where the - identification of one potential vulnerability may lead - to identifying another area of concern that requires - further investigation. - - The evaluator will report what actions were taken to - identify potential vulnerabilities in the - evidence. However, in this type of search, the evaluator - may not be able to describe the steps in identifying - potential vulnerabilities before the outset of the - examination, as the approach may evolve as a result of - findings during the search. - - The evaluator will report the evidence examine in - completing the search for potential - vulnerabilities. This selection of evidence may be - derived from those areas of concern identified by the - evaluator, linked to the evidence the attacker is - assumed to be able to obtain, or according to another - rationale provided by the evaluator. - - Subject to the SFRs the TOE is to meet in the - operational environment, the evaluator's independent - vulnerability analysis should consider generic potential - vulnerabilities under each of the following headings: - - - generic potential vulnerabilities relevant for the - type of TOE being evaluated, as may be supplied by - the evaluation authority; - - bypassing; - - tampering; - - direct attacks; - - monitoring; - - misuse. - - Items b) - f) are explained in greater detail in . - - The security architecture description should be - considered in light of each of the above generic - potential vulnerabilities. Each potential vulnerability - should be considered to search for possible ways in - which to defeat the TSF protection and undermine the - TSF. - - - The evaluator shall record in the ETR the identified - potential vulnerabilities that are candidates for - testing and applicable to the TOE in its operational - environment. - - It may be identified that no further consideration of - the potential vulnerability is required if for example - the evaluator identifies that measures in the - operational environment, either IT or non-IT, prevent - exploitation of the potential vulnerability in that - operational environment. For instance, restricting - physical access to the TOE to authorised users only may - effectively render a potential vulnerability to - tampering unexploitable. - - The evaluator records any reasons for exclusion of - potential vulnerabilities from further consideration if - the evaluator determines that the potential - vulnerability is not applicable in the operational - environment. Otherwise the evaluator records the - potential vulnerability for further - consideration. - - A list of potential vulnerabilities applicable to the - TOE in its operational environment, which can be used as - an input into penetration testing activities, shall be - reported in the ETR by the evaluators. - - - The evaluator shall conduct penetration testing, based on - the identified potential vulnerabilities, to determine that - the TOE is resistant to attacks performed by an attacker - possessing Enhanced-Basic attack potential. - - - The evaluator shall devise penetration tests, based on - the independent search for potential - vulnerabilities. - - The evaluator prepares for penetration testing as necessary to - determine the susceptibility of the TOE, in its operational - environment, to the potential vulnerabilities identified during - the search of the sources of information publicly available. - Any current information provided to the evaluator by a third - party (e.g. evaluation authority) regarding known potential - vulnerabilities will be considered by the evaluator, together - with any encountered potential vulnerabilities resulting from - the performance of other evaluation activities. - - The evaluator is reminded that, as for considering the security - architecture description in the search for vulnerabilities (as - detailed in ), testing should - be performed to confirm the architectural properties. If - requirements from are included in - the SARs, the developer testing evidence will include testing - performed to confirm the correct implementation of any specific - mechanisms detailed in the security architecture - description. However, the developer testing will not necessarily - include testing of all aspects of the architectural properties - that protect the TSF, as much of this testing will be negative - testing in nature, attempting to disprove the properties. In - developing the strategy for penetration testing, the evaluator - will ensure that all aspects of the security architecture - description are tested, either in functional testing (as - considered in ) or evaluator - penetration testing. - - It will probably be practical to carry out penetration - test using a series of test cases, where each test case - will test for a specific potential vulnerability. - - The evaluator is not expected to test for potential - vulnerabilities (including those in the public domain) - beyond those which required an Enhanced-Basic attack - potential. In some cases, however, it will be necessary - to carry out a test before the exploitability can be - determined. Where, as a result of evaluation expertise, - the evaluator discovers an exploitable vulnerability - that is beyond Enhanced-Basic attack potential, this is - reported in the ETR as a residual vulnerability. - - Guidance on determining the necessary attack potential - to exploit a potential vulnerability can be found in - Annex . - - Potential vulnerabilities hypothesised as exploitable - only by attackers possessing Moderate or High attack - potential do not result in a failure of this evaluator - action. Where analysis supports the hypothesis, these - need not be considered further as an input to - penetration testing. However, such vulnerabilities are - reported in the ETR as residual vulnerabilities. - - Potential vulnerabilities hypothesised as exploitable by - an attacker possessing a Basic or Enhanced-Basic attack - potential and resulting in a violation of the security - objectives should be the highest priority potential - vulnerabilities comprising the list used to direct - penetration testing against the TOE. - - - - The evaluator shall produce penetration test - documentation for the tests based on the list of - potential vulnerabilities in sufficient detail to enable - the tests to be repeatable. The test documentation shall - include: - - - identification of the potential vulnerability the - TOE is being tested for; - - - instructions to connect and setup all required test - equipment as required to conduct the penetration - test; - - - instructions to establish all penetration test - prerequisite initial conditions; - - - instructions to stimulate the TSF; - - - instructions for observing the behaviour of the TSF; - - - descriptions of all expected results and the - necessary analysis to be performed on the observed - behaviour for comparison against expected results; - - - instructions to conclude the test and establish the - necessary post-test state for the TOE. - - - - The evaluator prepares for penetration testing based on - the list of potential vulnerabilities identified during - the search of the public domain and the analysis of the - evaluation evidence. - - The evaluator is not expected to determine the - exploitability for potential vulnerabilities beyond - those for which an Enhanced-Basic attack potential is - required to effect an attack. However, as a result of - evaluation expertise, the evaluator may discover a - potential vulnerability that is exploitable only by an - attacker with greater than Enhanced-Basic attack - potential. Such vulnerabilities are to be reported in - the ETR as residual vulnerabilities. - - With an understanding of the potential vulnerability, - the evaluator determines the most feasible way to test - for the TOE's susceptibility. Specifically the evaluator - considers: - - - the TSFI or other TOE interface that will be used to - stimulate the TSF and observe responses (It is - possible that the evaluator will need to use an - interface to the TOE other than the TSFI to - demonstrate properties of the TSF such as those - described in the security architecture description - (as required by ). It - should the noted, that although these TOE interfaces - provide a means of testing the TSF properties, they - are not the subject of the test.); - - - initial conditions that will need to exist for the - test (i.e. any particular objects or subjects that - will need to exist and security attributes they will - need to have); - - - special test equipment that will be required to - either stimulate a TSFI or make observations of a - TSFI (although it is unlikely that specialist - equipment would be required to exploit a potential - vulnerability assuming an Enhanced-Basic attack - potential); - - - whether theoretical analysis should replace physical - testing, particularly relevant where the results of - an initial test can be extrapolated to demonstrate - that repeated attempts of an attack are likely to - succeed after a given number of attempts. - - - - The evaluator will probably find it practical to carry - out penetration testing using a series of test cases, - where each test case will test for a specific potential - vulnerability. - - The intent of specifying this level of detail in the - test documentation is to allow another evaluator to - repeat the tests and obtain an equivalent result. - - - - The evaluator shall conduct penetration testing. - - The evaluator uses the penetration test documentation - resulting from work unit as a basis for executing penetration tests - on the TOE, but this does not preclude the evaluator - from performing additional ad hoc penetration tests. If - required, the evaluator may devise ad hoc tests as a - result of information learnt during penetration testing - that, if performed by the evaluator, are to be recorded - in the penetration test documentation. Such tests may be - required to follow up unexpected results or - observations, or to investigate potential - vulnerabilities suggested to the evaluator during the - pre-planned testing. - - Should penetration testing show that a hypothesised - potential vulnerability does not exist, then the - evaluator should determine whether or not the - evaluator's own analysis was incorrect, or if evaluation - deliverables are incorrect or incomplete. - - The evaluator is not expected to test for potential - vulnerabilities (including those in the public domain) - beyond those which required an Enhanced-Basic attack - potential. In some cases, however, it will be necessary - to carry out a test before the exploitability can be - determined. Where, as a result of evaluation expertise, - the evaluator discovers an exploitable vulnerability - that is beyond Enhanced-Basic attack potential, this is - reported in the ETR as a residual vulnerability. - - - - The evaluator shall record the actual results of the - penetration tests. - - While some specific details of the actual test results - may be different from those expected (e.g. time and date - fields in an audit record) the overall result should be - identical. Any unexpected test results should be - investigated. The impact on the evaluation should be - stated and justified. - - - - The evaluator shall report in the ETR the evaluator - penetration testing effort, outlining the testing - approach, configuration, depth and results. - - The penetration testing information reported in the ETR - allows the evaluator to convey the overall penetration - testing approach and effort expended on this - sub-activity. The intent of providing this information - is to give a meaningful overview of the evaluator's - penetration testing effort. It is not intended that the - information regarding penetration testing in the ETR be - an exact reproduction of specific test steps or results - of individual penetration tests. The intention is to - provide enough detail to allow other evaluators and - evaluation authorities to gain some insight about the - penetration testing approach chosen, amount of - penetration testing performed, TOE test configurations, - and the overall results of the penetration testing - activity. - - Information that would typically be found in the ETR - subclause regarding evaluator penetration testing efforts - is: - - - TOE test configurations. The particular - configurations of the TOE that were penetration - tested; - - - TSFI penetration tested. A brief listing of the TSFI - and other TOE interfaces that were the focus of the - penetration testing; - - - Verdict for the sub-activity. The overall judgement - on the results of penetration testing. - - - - This list is by no means exhaustive and is only intended - to provide some context as to the type of information - that should be present in the ETR concerning the - penetration testing the evaluator performed during the - evaluation. - - - - The evaluator shall examine the results of all - penetration testing to determine that the TOE, in its - operational environment, is resistant to an attacker - possessing an Enhanced-Basic attack potential. - - If the results reveal that the TOE, in its operational - environment, has vulnerabilities exploitable by an - attacker possessing less than Moderate attack potential, - then this evaluator action fails. - - The guidance in should be used to determine the attack - potential required to exploit a particular vulnerability - and whether it can therefore be exploited in the - intended environment. It may not be necessary for the - attack potential to be calculated in every instance, - only if there is some doubt as to whether or not the - vulnerability can be exploited by an attacker possessing - an attack potential less than Moderate. - - - - The evaluator shall report in the ETR all exploitable - vulnerabilities and residual vulnerabilities, detailing - for each: - - - its source (e.g. CEM activity being undertaken when - it was conceived, known to the evaluator, read in a - publication); - - - the SFR(s) not met; - - - a description; - - - whether it is exploitable in its operational - environment or not (i.e. exploitable or residual). - - - the amount of time, level of expertise, level of - knowledge of the TOE, level of opportunity and the - equipment required to perform the identified - vulnerabilities, and the corresponding values using - the tables and - of Annex . - - - - - - - - - - - - - - - - A methodical vulnerability analysis is performed by the - evaluator to ascertain the presence of potential - vulnerabilities. - - The evaluator performs penetration testing, to confirm - that the potential vulnerabilities cannot be exploited in - the operational environment for the TOE. Penetration - testing is performed by the evaluator assuming an attack - potential of Moderate. - - - - The objective of this sub-activity is to determine whether - the TOE, in its operational environment, has - vulnerabilities exploitable by attackers possessing - Moderate attack potential. - - - - The methodical analysis approach takes the form of a - structured examination of the evidence. This method - requires the evaluator to specify the structure and form - the analysis will take (i.e. the manner in which the - analysis is performed is predetermined, unlike the focused - analysis). The method is specified in terms of the - information that will be considered and how/why it will be - considered. Further guidance on methodical vulnerability - analysis can be found in Annex . - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - the functional specification; - - the TOE design; - - the security architecture description; - - the implementation representation; - - the guidance documentation; - - the TOE suitable for testing; - - information publicly available to support the identification of possible potential vulnerabilities; - - the results of the testing of the basic design. - - - The remaining implicit evaluation evidence for this - sub-activity depends on the components that have been - included in the assurance package. The evidence provided - for each component is to be used as input in this - sub-activity. - - Other input for this sub-activity is: - - - current information regarding public domain potential - vulnerabilities and attacks (e.g. from an evaluation - authority). - - - - - The developer shall provide the TOE for testing. - - - The TOE shall be suitable for testing. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - - The evaluator shall examine the TOE to determine that - the test configuration is consistent with the - configuration under evaluation as specified in the - ST. - - The TOE provided by the developer and identified in the - test plan should have the same unique reference as - established by the - sub-activities and identified in the ST - introduction. - - It is possible for the ST to specify more than one - configuration for evaluation. The TOE may comprise a - number of distinct hardware and software entities that - need to be tested in accordance with the ST. The - evaluator verifies that all test configurations are - consistent with the ST. - - The evaluator should consider the security objectives - for the operational environment described in the ST that - may apply to the test environment and ensure they are - met in the testing environment. There may be some - objectives for the operational environment that do not - apply to the test environment. For example, an objective - about user clearances may not apply; however, an - objective about a single point of connection to a - network would apply. - - If any test resources are used (e.g. meters, analysers) - it will be the evaluator's responsibility to ensure that - these resources are calibrated correctly. - - - - - The evaluator shall examine the TOE to determine that it - has been installed properly and is in a known - state - - It is possible for the evaluator to determine the state - of the TOE in a number of ways. For example, previous - successful completion of the sub-activity will satisfy this work unit - if the evaluator still has confidence that the TOE being - used for testing was installed properly and is in a - known state. If this is not the case, then the evaluator - should follow the developer's procedures to install and - start up the TOE, using the supplied guidance - only. - - If the evaluator has to perform the installation - procedures because the TOE is in an unknown state, this - work unit when successfully completed could satisfy work - unit . - - - - The evaluator shall perform a search of public domain - sources to identify potential vulnerabilities in the TOE. - - - The evaluator shall examine sources of information - publicly available to identify potential vulnerabilities - in the TOE. - - The evaluator examines the sources of information - publicly available to support the identification of - possible potential vulnerabilities in the TOE. There are - many sources of publicly available information which the - evaluator should consider using items such as those - available on the world wide web, including: - - - specialist publications (magazines, books); - - - research papers; - - - conference proceedings. - - - - The evaluator should not constrain their consideration - of publicly available information to the above, but - should consider any other relevant information - available. - - While examining the evidence provided the evaluator will - use the information in the public domain to further - search for potential vulnerabilities. Where the - evaluators have identified areas of concern, the - evaluator should consider information publicly available - that relate to those areas of concern. - - The availability of information that may be readily - available to an attacker that helps to identify and - facilitate attacks may substantially enhance the attack - potential of a given attacker. The accessibility of - vulnerability information and sophisticated attack tools - on the Internet makes it more likely that this - information will be used in attempts to identify - potential vulnerabilities in the TOE and exploit - them. Modern search tools make such information easily - available to the evaluator, and the determination of - resistance to published potential vulnerabilities and - well known generic attacks can be achieved in a - cost-effective manner. - - The search of the information publicly available should - be focused on those sources that refer to the - technologies used in the development of the product from - which the TOE is derived. The extensiveness of this - search should consider the following factors: TOE type, - evaluator experience in this TOE type, expected attack - potential and the level of - evidence available. - - The identification process is iterative, where the - identification of one potential vulnerability may lead - to identifying another area of concern that requires - further investigation. - - The evaluator will describe the approach to be taken to - identify potential vulnerabilities in the publicly - available material, detailing the search to be - performed. This may be driven by factors such as areas - of concern identified by the evaluator, linked to the - evidence the attacker is assumed to be able to obtain. - However, it is recognised that in this type of search - the approach may further evolve as a result of findings - during the search. Therefore, the evaluator will also - report any actions taken in addition to those described - in the approach to further investigate issues thought to - lead to potential vulnerabilities, and will report the - evidence examined in completing the search for potential - vulnerabilities. - - - - The evaluator shall perform an independent, methodical - vulnerability analysis of the TOE using the guidance - documentation, functional specification, TOE design, - security architecture description and implementation - representation to identify potential vulnerabilities in the - TOE. - - - The evaluator shall conduct a methodical analysis of ST, - guidance documentation, functional specification, TOE - design, security architecture description and - implementation representation to identify possible - potential vulnerabilities in the TOE. - - Guidance on methodical vulnerability analysis is - provided in Annex . - - This approach to identification of potential - vulnerabilities is to take an ordered and planned - approach. A system is to be applied in the - examination. The evaluator is to describe the method to - be used in terms of the manner in which this information - is to be considered and the hypothesis that is to be - created. - - A flaw hypothesis methodology needs to be used whereby the ST, - development (functional specification, TOE design and - implementation representation) and guidance evidence are - analysed and then vulnerabilities in the TOE are hypothesised, - or speculated. - - The evaluator uses the knowledge of the TOE design and operation - gained from the TOE deliverables to conduct a flaw hypothesis to - identify potential flaws in the development of the TOE and - potential errors in the specified method of operation of the - TOE. - - The security architecture description provides the developer - vulnerability analysis, as it documents how the TSF protects - itself from interference from untrusted subjects and prevents - the bypass of security enforcement functionality. Therefore, the - evaluator should build upon the understanding of the TSF - protection gained from the analysis of this evidence and then - develop this in the knowledge gained from other development - evidence. - - The approach taken to the methodical search for vulnerabilities - is to consider any areas of concern identified in the results of - the evaluator's assessment of the development and guidance - evidence. However, the evaluator should also consider each - aspect of the security architecture analysis to search for any - ways in which the protection of the TSF can be undermined. It - may be helpful to structure the methodical analysis on the basis - of the material presented in the security architecture - description, introducing concerns from other evidence as appropriate. The analysis can then be - further developed to ensure all other material from the evidence is considered. - - The following provide some examples of hypotheses that - may be created when examining the evidence: - - - consideration of malformed input for interfaces - available to an attacker at the external interfaces; - - - examination of a key security mechanism cited in the - security architecture description, such as process - separation, hypothesising internal buffer overflows - that may lead to degradation of separation; - - - search to identify any objects created in the TOE - implementation representation that are then not - fully controlled by the TSF, and could be used by an - attacker to undermine SFRs. - - - - For example, the evaluator may identify that interfaces - are a potential area of weakness in the TOE and specify - an approach to the search that 'all interface - specifications in the evidence provided will be searched - to hypothesise potential vulnerabilities' and go on to - explain the methods used in the hypothesis. - - In addition, areas of concern the evaluator has identified - during examination of the evidence during the conduct of - evaluation activities. Areas of concern may also be identified - during the conduct of other work units associated with this - component, in particular , - and where the development and conduct of penetration - tests may identify further areas of concerns for investigation, - or potential vulnerabilities. - - However, examination of only a subset of the development - and guidance evidence or their contents is not permitted - in this level of rigour. The approach description should - provide a demonstration that the methodical approach - used is complete, providing confidence that the approach - used to search the deliverables has considered all of - the information provided in those deliverables. - - This approach to identification of potential vulnerabilities is - to take an ordered and planned approach; applying a system to - the examination. The evaluator is to describe the method to be - used in terms of how the evidence will be considered; the manner - in which this information is to be considered and the hypothesis - that is to be created. This approach should be agreed with the - evaluation authority, and the evaluation authority may - provide detail of any additional approaches the evaluator should - take to the vulnerability analysis and identify any additional - information that should be considered by the evaluator. - - Although a system to identifying potential - vulnerabilities is predefined, the identification - process may still be iterative, where the identification - of one potential vulnerability may lead to identifying - another area of concern that requires further - investigation. - - Subject to the SFRs the TOE is to meet in the - operational environment, the evaluator's independent - vulnerability analysis should consider generic potential - vulnerabilities under each of the following headings: - - - generic potential vulnerabilities relevant for the - type of TOE being evaluated, as may be supplied by - the evaluation authority; - - bypassing; - - tampering; - - direct attacks; - - monitoring; - - misuse. - - Items b) - f) are explained in greater detail in . - - The security architecture description should be - considered in light of each of the above generic - potential vulnerabilities. Each potential vulnerability - should be considered to search for possible ways in - which to defeat the TSF protection and undermine the - TSF. - - - - The evaluator shall record in the ETR the identified - potential vulnerabilities that are candidates for - testing and applicable to the TOE in its operational - environment. - - It may be identified that no further consideration of - the potential vulnerability is required if for example - the evaluator identifies that measures in the - operational environment, either IT or non-IT, prevent - exploitation of the potential vulnerability in that - operational environment. For instance, restricting - physical access to the TOE to authorised users only may - effectively render a potential vulnerability to - tampering unexploitable. - - The evaluator records any reasons for exclusion of - potential vulnerabilities from further consideration if - the evaluator determines that the potential - vulnerability is not applicable in the operational - environment. Otherwise the evaluator records the - potential vulnerability for further - consideration. - - A list of potential vulnerabilities applicable to the - TOE in its operational environment, which can be used as - an input into penetration testing activities, shall be - reported in the ETR by the evaluators. - - - - The evaluator shall conduct penetration testing based on the - identified potential vulnerabilities to determine that the - TOE is resistant to attacks performed by an attacker - possessing Moderate attack potential. - - - The evaluator shall devise penetration tests, based on - the independent search for potential - vulnerabilities. - - The evaluator prepares for penetration testing as necessary to - determine the susceptibility of the TOE, in its operational - environment, to the potential vulnerabilities identified during - the search of the sources of information publicly available. - Any current information provided to the evaluator by a third - party (e.g. evaluation authority) regarding known potential - vulnerabilities will be considered by the evaluator, together - with any encountered potential vulnerabilities resulting from - the performance of other evaluation activities. - - The evaluator is reminded that, as for considering the - security architecture description in the search for - vulnerabilities (as detailed in ), testing should be performed to confirm the - architectural properties. If requirements from are included in the SARs, the - developer testing evidence will include testing - performed to confirm the correct implementation of any - specific mechanisms detailed in the security - architecture description. However, the developer testing - will not necessarily include testing of all aspects of - the architectural properties that protect the TSF, as - much of this testing will be negative testing in nature, - attempting to disprove the properties. In developing the - strategy for penetration testing, the evaluator will - ensure that all aspects of the security architecture - description are tested, either in functional testing (as - considered in ) or evaluator - penetration testing. - - The evaluator will probably find it practical to carry - out penetration test using a series of test cases, where - each test case will test for a specific potential - vulnerability. - - The evaluator is not expected to test for potential - vulnerabilities (including those in the public domain) - beyond those which required a Moderate attack - potential. In some cases, however, it will be necessary - to carry out a test before the exploitability can be - determined. Where, as a result of evaluation expertise, - the evaluator discovers an exploitable vulnerability - that is beyond Moderate attack potential, this is - reported in the ETR as a residual vulnerability. - - Guidance on determining the necessary attack potential - to exploit a potential vulnerability can be found in - Annex . - - Potential vulnerabilities hypothesised as exploitable by - an attacker possessing a Moderate (or less) attack - potential and resulting in a violation of the security - objectives should be the highest priority potential - vulnerabilities comprising the list used to direct - penetration testing against the TOE. - - - - The evaluator shall produce penetration test - documentation for the tests based on the list of - potential vulnerabilities in sufficient detail to enable - the tests to be repeatable. The test documentation shall - include: - - - identification of the potential vulnerability the - TOE is being tested for; - - - instructions to connect and setup all required test - equipment as required to conduct the penetration - test; - - - instructions to establish all penetration test - prerequisite initial conditions; - - - instructions to stimulate the TSF; - - - instructions for observing the behaviour of the TSF; - - - descriptions of all expected results and the - necessary analysis to be performed on the observed - behaviour for comparison against expected results; - - - instructions to conclude the test and establish the - necessary post-test state for the TOE. - - - - The evaluator prepares for penetration testing based on - the list of potential vulnerabilities identified during - the search of the public domain and the analysis of the - evaluation evidence. - - The evaluator is not expected to determine the - exploitability for potential vulnerabilities beyond - those for which a Moderate attack potential is required - to effect an attack. However, as a result of evaluation - expertise, the evaluator may discover a potential - vulnerability that is exploitable only by an attacker - with greater than Moderate attack potential. Such - vulnerabilities are to be reported in the ETR as - residual vulnerabilities. - - With an understanding of the potential vulnerability, - the evaluator determines the most feasible way to test - for the TOE's susceptibility. Specifically the evaluator - considers: - - - the TSFI or other TOE interface that will be used to - stimulate the TSF and observe responses (It is - possible that the evaluator will need to use an - interface to the TOE other than the TSFI to - demonstrate properties of the TSF such as those - described in the security architecture description - (as required by ). It - should the noted, that although these TOE interfaces - provide a means of testing the TSF properties, they - are not the subject of the test.); - - - initial conditions that will need to exist for the - test (i.e. any particular objects or subjects that - will need to exist and security attributes they will - need to have); - - - special test equipment that will be required to - either stimulate a TSFI or make observations of a - TSFI; - - - whether theoretical analysis should replace physical - testing, particularly relevant where the results of - an initial test can be extrapolated to demonstrate - that repeated attempts of an attack are likely to - succeed after a given number of attempts. - - - - The evaluator will probably find it practical to carry - out penetration testing using a series of test cases, - where each test case will test for a specific potential - vulnerability. - - The intent of specifying this level of detail in the - test documentation is to allow another evaluator to - repeat the tests and obtain an equivalent result. - - - - The evaluator shall conduct penetration testing. - - The evaluator uses the penetration test documentation - resulting from work unit as a basis for executing penetration tests - on the TOE, but this does not preclude the evaluator - from performing additional ad hoc penetration tests. If - required, the evaluator may devise ad hoc tests as a - result of information learnt during penetration testing - that, if performed by the evaluator, are to be recorded - in the penetration test documentation. Such tests may be - required to follow up unexpected results or - observations, or to investigate potential - vulnerabilities suggested to the evaluator during the - pre-planned testing. - - Should penetration testing show that a hypothesised - potential vulnerability does not exist, then the - evaluator should determine whether or not the - evaluator's own analysis was incorrect, or if evaluation - deliverables are incorrect or incomplete. - - The evaluator is not expected to test for potential - vulnerabilities (including those in the public domain) - beyond those which required a Moderate attack - potential. In some cases, however, it will be necessary - to carry out a test before the exploitability can be - determined. Where, as a result of evaluation expertise, - the evaluator discovers an exploitable vulnerability - that is beyond Moderate attack potential, this is - reported in the ETR as a residual vulnerability. - - - - The evaluator shall record the actual results of the - penetration tests. - - While some specific details of the actual test results - may be different from those expected (e.g. time and date - fields in an audit record) the overall result should be - identical. Any unexpected test results should be - investigated. The impact on the evaluation should be - stated and justified. - - - - The evaluator shall report in the ETR the evaluator - penetration testing effort, outlining the testing - approach, configuration, depth and results. - - The penetration testing information reported in the ETR - allows the evaluator to convey the overall penetration - testing approach and effort expended on this - sub-activity. The intent of providing this information - is to give a meaningful overview of the evaluator's - penetration testing effort. It is not intended that the - information regarding penetration testing in the ETR be - an exact reproduction of specific test steps or results - of individual penetration tests. The intention is to - provide enough detail to allow other evaluators and - evaluation authorities to gain some insight about the - penetration testing approach chosen, amount of - penetration testing performed, TOE test configurations, - and the overall results of the penetration testing - activity. - - Information that would typically be found in the ETR - subclause regarding evaluator penetration testing efforts - is: - - - TOE test configurations. The particular - configurations of the TOE that were penetration - tested; - - - TSFI penetration tested. A brief listing of the TSFI - and other TOE interfaces that were the focus of the - penetration testing; - - - Verdict for the sub-activity. The overall judgement - on the results of penetration testing. - - - - This list is by no means exhaustive and is only intended - to provide some context as to the type of information - that should be present in the ETR concerning the - penetration testing the evaluator performed during the - evaluation. - - - - The evaluator shall examine the results of all - penetration testing to determine that the TOE, in its - operational environment, is resistant to an attacker - possessing a Moderate attack potential. - - If the results reveal that the TOE, in its operational - environment, has vulnerabilities exploitable by an - attacker possessing less than a High attack potential, - then this evaluator action fails. - - The guidance in should be used to determine the attack - potential required to exploit a particular vulnerability - and whether it can therefore be exploited in the - intended environment. It may not be necessary for the - attack potential to be calculated in every instance, - only if there is some doubt as to whether or not the - vulnerability can be exploited by an attacker possessing - an attack potential less than High. - - - - The evaluator shall report in the ETR all exploitable - vulnerabilities and residual vulnerabilities, detailing - for each: - - - its source (e.g. CEM activity being undertaken when - it was conceived, known to the evaluator, read in a - publication); - - - the SFR(s) not met; - - - a description; - - - whether it is exploitable in its operational - environment or not (i.e. exploitable or residual). - - - the amount of time, level of expertise, level of - knowledge of the TOE, level of opportunity and the - equipment required to perform the identified - vulnerabilities, and the corresponding values using - the tables and - of Annex . - - - - - - - - - - - - - - - - A methodical vulnerability analysis is performed by the - evaluator to ascertain the presence of potential - vulnerabilities. - - The evaluator performs penetration testing, to confirm - that the potential vulnerabilities cannot be exploited in - the operational environment for the TOE. Penetration - testing is performed by the evaluator assuming an attack - potential of High. - - - - The objective of this sub-activity is to determine whether - the TOE, in its operational environment, has - vulnerabilities exploitable by attackers possessing High - attack potential. - - - - The methodical analysis approach takes the form of a - structured examination of the evidence. This method - requires the evaluator to specify the structure and form - the analysis will take (i.e. the manner in which the - analysis is performed is predetermined, unlike the focused - analysis). The method is specified in terms of the - information that will be considered and how/why it will be - considered. Further guidance on methodical vulnerability - analysis can be found in Annex . - - If the TOE SFRs include and - requirements such that - actions and data of one subject cannot be observed and - linked with another subject, the evaluator should consider - performing a covert channel analysis. This will build - upon the design evidence provided by the developer in - satisfaction of and requirements. The design evidence - will include details of how the TOE architecture prevents - observation by subjects of actions performed by other - subjects. the evaluator should seek guidance from the - evaluation authority on the conduct of such a covert - channel analysis. - - The analysis of the guidance documentation is to include - consideration of whether it is possible to unknowingly - configure the TOE insecurely. Therefore, the analysis will - consider warning prompts provided by the TOE when - configuration options are selected by the user that may - render the TOE in an insecure state, not just in the - guidance but also in the use of the TOE. An example may be - when access control rules are amended from a remote - administration console, which will not take effect until - the TOE has been restarted. The evaluator will determine - whether the TOE issues a suitable warning when the changes - are made to ensure the user is aware that a restart must - be completed before the changes take effect. - - - - The evaluation evidence for this sub-activity is: - - - the ST; - - the functional specification; - - the TOE design; - - the security architecture description; - - the implementation representation; - - the guidance documentation; - - the TOE suitable for testing; - - information publicly available to support the - identification of possible potential - vulnerabilities. - - The remaining implicit evaluation evidence for this - sub-activity depends on the components that have been - included in the assurance package. The evidence provided - for each component is to be used as input in this - sub-activity. - - Other input for this sub-activity is: - - - current information regarding public domain potential - vulnerabilities and attacks (e.g. from an evaluation - authority). - - - - - The developer shall provide the TOE for testing. - - - The TOE shall be suitable for testing. - - - The evaluator shall confirm that the information provided - meets all requirements for content and presentation of - evidence. - - - The evaluator shall perform a search of public domain - sources to identify potential vulnerabilities in the TOE. - - - The evaluator shall perform an independent, methodical - vulnerability analysis of the TOE using the guidance - documentation, functional specification, TOE design, - security architecture description and implementation - representation to identify potential vulnerabilities in the - TOE. - - - The evaluator shall conduct penetration testing based on the - identified potential vulnerabilities to determine that the - TOE is resistant to attacks performed by an attacker - possessing High attack potential. - - - - - - - - EAL1 is applicable where some confidence in correct operation - is required, but the threats to security are not viewed as - serious. It will be of value where independent assurance is - required to support the contention that due care has been - exercised with respect to the protection of personal or - similar information. - - EAL1 requires only a limited security target. It is sufficient - to simply state the SFRs that the TOE must meet, rather than - deriving them from threats, OSPs and assumptions through - security objectives. - - EAL1 provides an evaluation of the TOE as made available to - the customer, including independent testing against a - specification, and an examination of the guidance - documentation provided. It is intended that an EAL1 evaluation - could be successfully conducted without assistance from the - developer of the TOE, and for minimal outlay. - - An evaluation at this level should provide evidence that the - TOE functions in a manner consistent with its - documentation. - - - - EAL1 provides a basic level of assurance by a limited security - target and an analysis of the SFRs in that ST using a - functional and interface specification and guidance - documentation, to understand the security behaviour. - - The analysis is supported by a search for potential - vulnerabilities in the public domain and independent testing - (functional and penetration) of the TSF. - - EAL1 also provides assurance through unique identification of - the TOE and of the relevant evaluation documents. - - This EAL provides a meaningful increase in assurance over - unevaluated IT. - - - - - - - - - - - - - - - - - - - EAL2 requires the co-operation of the developer in terms of - the delivery of design information and test results, but - should not demand more effort on the part of the developer - than is consistent with good commercial practise. As such it - should not require a substantially increased investment of - cost or time. - - EAL2 is therefore applicable in those circumstances where - developers or users require a low to moderate level of - independently assured security in the absence of ready - availability of the complete development record. Such a - situation may arise when securing legacy systems, or where - access to the developer may be limited. - - - - EAL2 provides assurance by a full security target and an - analysis of the SFRs in that ST, using a functional and - interface specification, guidance documentation and a basic - description of the architecture of the TOE, to understand the - security behaviour. - - The analysis is supported by independent testing of the TSF, - evidence of developer testing based on the functional - specification, selective independent confirmation of the - developer test results, and a vulnerability analysis (based - upon the functional specification, TOE design, security architecture - description and guidance evidence provided) demonstrating - resistance to penetration attackers with a basic attack - potential. - - EAL2 also provides assurance through use of a configuration - management system and evidence of secure delivery - procedures. - - This EAL represents a meaningful increase in assurance from - EAL1 by requiring developer testing, a vulnerability analysis - (in addition to the search of the public domain), and - independent testing based upon more detailed TOE - specifications. - - - - - - - - - - - - - - - - - - - - - - - - - EAL3 permits a conscientious developer to gain maximum - assurance from positive security engineering at the design - stage without substantial alteration of existing sound - development practises. - - EAL3 is applicable in those circumstances where developers or - users require a moderate level of independently assured - security, and require a thorough investigation of the TOE and - its development without substantial re-engineering. - - - - EAL3 provides assurance by a full security target and an - analysis of the SFRs in that ST, using a functional and - interface specification, guidance documentation, and an - architectural description of the design of the TOE, to - understand the security behaviour. - - The analysis is supported by independent testing of the TSF, - evidence of developer testing based on the functional - specification and TOE design, selective independent - confirmation of the developer test results, and a - vulnerability analysis (based upon the functional - specification, TOE design, security architecture description and guidance - evidence provided) demonstrating resistance to penetration - attackers with a basic attack potential. - - EAL3 also provides assurance through the use of development - environment controls, TOE configuration management, and - evidence of secure delivery procedures. - - This EAL represents a meaningful increase in assurance from - EAL2 by requiring more complete testing coverage of the - security functionality and mechanisms and/or procedures that - provide some confidence that the TOE will not be tampered with - during development. - - - - - - - - - - - - - - - - - - - - - - - - - - - - EAL4 permits a developer to gain maximum assurance from - positive security engineering based on good commercial - development practises which, though rigorous, do not require - substantial specialist knowledge, skills, and other - resources. EAL4 is the highest level at which it is likely to - be economically feasible to retrofit to an existing product - line. - - EAL4 is therefore applicable in those circumstances where - developers or users require a moderate to high level of - independently assured security in conventional commodity TOEs - and are prepared to incur additional security-specific - engineering costs. - - - - EAL4 provides assurance by a full security target and an - analysis of the SFRs in that ST, using a functional and - complete interface specification, guidance documentation, a - description of the basic modular design of the TOE, and a - subset of the implementation, to understand the security - behaviour. - - The analysis is supported by independent testing of the TSF, - evidence of developer testing based on the functional - specification and TOE design, selective independent confirmation - of the developer test results, and a vulnerability analysis (based upon - the functional specification, TOE design, implementation - representation, security architecture description and guidance - evidence provided) demonstrating resistance to penetration - attackers with an Enhanced-Basic attack potential. - - EAL4 also provides assurance through the use of development - environment controls and additional TOE configuration - management including automation, and evidence of secure - delivery procedures. - - This EAL represents a meaningful increase in assurance from EAL3 - by requiring more design description, the implementation - representation for the entire TSF, and improved mechanisms - and/or procedures that provide confidence that the TOE will not - be tampered with during development. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - EAL5 permits a developer to gain maximum assurance from - security engineering based upon rigorous commercial - development practises supported by moderate application of - specialist security engineering techniques. Such a TOE will - probably be designed and developed with the intent of - achieving EAL5 assurance. It is likely that the additional - costs attributable to the EAL5 requirements, relative to - rigorous development without the application of specialised - techniques, will not be large. - - EAL5 is therefore applicable in those circumstances where - developers or users require a high level of independently - assured security in a planned development and require a - rigorous development approach without incurring unreasonable - costs attributable to specialist security engineering - techniques. - - - - EAL5 provides assurance by a full security target and an - analysis of the SFRs in that ST, using a functional and - complete interface specification, guidance documentation, a - description of the design of the TOE, and the implementation, - to understand the security behaviour. A modular TSF design is - also required. - - The analysis is supported by independent testing of the TSF, - evidence of developer testing based on the functional - specification, TOE design, selective independent confirmation - of the developer test results, and an independent - vulnerability analysis demonstrating resistance to penetration - attackers with a moderate attack potential. - - EAL5 also provides assurance through the use of a development - environment controls, and comprehensive TOE configuration - management including automation, and evidence of secure - delivery procedures. - - This EAL represents a meaningful increase in assurance from EAL4 - by requiring semiformal design descriptions, a more structured - (and hence analysable) architecture, and improved mechanisms - and/or procedures that provide confidence that the TOE will not - be tampered with during development. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - EAL6 permits developers to gain high assurance from - application of security engineering techniques to a rigorous - development environment in order to produce a premium TOE for - protecting high value assets against significant risks. - - EAL6 is therefore applicable to the development of security - TOEs for application in high risk situations where the value - of the protected assets justifies the additional costs. - - - - EAL6 provides assurance by a full security target and an - analysis of the SFRs in that ST, using a functional and - complete interface specification, guidance documentation, the - design of the TOE, and the implementation to understand the - security behaviour. Assurance is additionally gained through a - formal model of select TOE security policies and a semiformal - presentation of the functional specification and TOE design. A - modular, layered and simple TSF design is also required. - - The analysis is supported by independent testing of the TSF, - evidence of developer testing based on the functional - specification, TOE design, selective independent confirmation - of the developer test results, and an independent - vulnerability analysis demonstrating resistance to penetration - attackers with a high attack potential. - - EAL6 also provides assurance through the use of a structured - development process, development environment controls, and - comprehensive TOE configuration management including complete - automation, and evidence of secure delivery procedures. - - This EAL represents a meaningful increase in assurance from - EAL5 by requiring more comprehensive analysis, a structured - representation of the implementation, more architectural - structure (e.g. layering), more comprehensive independent - vulnerability analysis, and improved configuration management - and development environment controls. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - EAL7 is applicable to the development of security TOEs for - application in extremely high risk situations and/or where the - high value of the assets justifies the higher costs. Practical - application of EAL7 is currently limited to TOEs with tightly - focused security functionality that is amenable to extensive - formal analysis. - - - - EAL7 provides assurance by a full security target and an - analysis of the SFRs in that ST, using a functional and - complete interface specification, guidance documentation, the - design of the TOE, and a structured presentation of the - implementation to understand the security behaviour. Assurance - is additionally gained through a formal model of select TOE - security policies and a semiformal presentation of the - functional specification and TOE design. A modular, layered - and simple TSF design is also required. - - The analysis is supported by independent testing of the TSF, - evidence of developer testing based on the functional - specification, TOE design and implementation representation, - complete independent confirmation of the developer test - results, and an independent vulnerability analysis - demonstrating resistance to penetration attackers with a high - attack potential. - - EAL7 also provides assurance through the use of a structured - development process, development environment controls, and - comprehensive TOE configuration management including complete - automation, and evidence of secure delivery procedures. - - This EAL represents a meaningful increase in assurance from - EAL6 by requiring more comprehensive analysis using formal - representations and formal correspondence, and comprehensive - testing. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - CAP-A is applicable when a composed TOE is integrated and - confidence in the correct security operation of the resulting - composite is required. This requires the cooperation of the - developer of the dependent component in terms of delivery of - design information and test results from the dependent - component certification, without requiring the involvement of - the base component developer. - - CAP-A is therefore applicable in those circumstances where - developers or users require a low to moderate level of - independently assured security in the absence of ready - availability of the complete development record. - - - - CAP-A provides assurance by analysis of a security target for - the composed TOE. The SFRs in the composed TOE ST are - analysed using the outputs from the evaluations of the - component TOEs (e.g. ST, guidance documentation) and a - specification for the interfaces between the component TOEs in - the composed TOE to understand the security behaviour. - - The analysis is supported by independent testing of the - interfaces of the base component that are relied upon by the - dependent component, as described in the reliance information, - evidence of developer testing based on the reliance - information, development information and composition - rationale, and selective independent confirmation of the - developer test results. The analysis is also supported by a - vulnerability review of the composed TOE by the - evaluator. - - CAP-A also provides assurance through unique identification of - the composed TOE (i.e. IT TOE and guidance - documentation). - - - - - - - - - - - - - - - - - - - - - CAP-B permits a conscientious developer to gain maximum - assurance from understanding, at a subsystem level, the - affects of interactions between component TOEs integrated in - the composed TOE, whilst minimising the demand of involvement - of the base component developer. - - CAP-B is applicable in those circumstances where developers or - users require a moderate level of independently assured - security, and require a thorough investigation of the composed - TOE and its development without substantial - re-engineering. - - - - CAP-B provides assurance by analysis of a full security target - for the composed TOE. The SFRs in the composed TOE ST are - analysed using the outputs from the evaluations of the - component TOEs (e.g. ST, guidance documentation), a - specification for the interfaces between the component TOEs - and the TOE design (describing TSF subsystems) contained in - the composed development information to understand the - security behaviour. - - The analysis is supported by independent testing of the - interfaces of the base component that are relied upon by the - dependent component, as described in the reliance information - (now also including TOE design), evidence of developer testing - based on the reliance information, development information and - composition rationale, and selective independent confirmation - of the developer test results. The analysis is also supported - by a vulnerability analysis of the composed TOE by the - evaluator demonstrating resistance to attackers with basic - attack potential. - - This CAP represents a meaningful increase in assurance from - CAP-A by requiring more complete testing coverage of the - security functionality. - - - - - - - - - - - - - - - - - - - - - - CAP-C permits a developer to gain maximum assurance from - positive analysis of the interactions between the components - of the composed TOE, which, though rigorous, do not require - full access to all evaluation evidence of the base - component. - - CAP-C is therefore applicable in those circumstances where - developers or users require a moderate to high level of - independently assured security in conventional commodity - composed TOEs and are prepared to incur additional - security-specific engineering costs. - - - - CAP-C provides assurance by analysis of a full security target - for the composed TOE. The SFRs in the composed TOE ST are - analysed using the outputs from the evaluations of the - component TOEs (e.g. ST, guidance documentation), a - specification for the interfaces between the component TOEs - and the TOE design (describing TSF modules) contained in the - composed development information to understand the security - behaviour. - - The analysis is supported by independent testing of the - interfaces of the base component that are relied upon by the - dependent component, as described in the reliance information - (now including TOE design), evidence of developer testing based - on the reliance information, development information and - composition rationale, and selective independent confirmation of - the developer test results. The analysis is also supported by a - vulnerability analysis of the composed TOE by the evaluator - demonstrating resistance to attackers with Enhanced-Basic attack - potential. - - This CAP represents a meaningful increase in assurance from - CAP-B by requiring more design description and demonstration - of resistance to a higher attack potential. - - - - - - - - - - - - - - - - - - - - From ed89f97aaf7d40cc51e0f7c49e2f8ff2b2a6a15a Mon Sep 17 00:00:00 2001 From: kgal Date: Tue, 18 Oct 2022 11:34:11 -0400 Subject: [PATCH 02/13] Update quick_build.yml --- .github/workflows/quick_build.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/quick_build.yml b/.github/workflows/quick_build.yml index d5f255bb..e1673098 100644 --- a/.github/workflows/quick_build.yml +++ b/.github/workflows/quick_build.yml @@ -24,7 +24,7 @@ jobs: - name: Install Build Packages # run: "sudo apt-get update && sudo apt-get install -y xsltproc hunspell pandoc" - run: "sudo apt-get update && sudo apt-get install -y xsltproc hunspell" + run: "sudo apt-get update && sudo apt-get install -y xsltproc hunspell python3-lxml" - name: Install Jing run: wget -O - https://github.com/relaxng/jing-trang/releases/download/V20181222/jing-20181222.zip | jar -x From f60cd53ce7f1bef46b676e0af6775c92c42772c1 Mon Sep 17 00:00:00 2001 From: kevin Date: Wed, 19 Oct 2022 10:41:42 -0400 Subject: [PATCH 03/13] Updated transforms. Updated target-product attribute. --- input/mobile-device.xml | 2 +- transforms | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/input/mobile-device.xml b/input/mobile-device.xml index 82c4f775..d79bf295 100644 --- a/input/mobile-device.xml +++ b/input/mobile-device.xml @@ -65,7 +65,7 @@ How is it differenet then me using subsection? - Date: Thu, 20 Oct 2022 08:13:46 -0400 Subject: [PATCH 04/13] Updated trnasforms. --- transforms | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/transforms b/transforms index 1720c7df..fb314f17 160000 --- a/transforms +++ b/transforms @@ -1 +1 @@ -Subproject commit 1720c7df61ae17624616532900c2090ebbaa247b +Subproject commit fb314f177825ecbb595c6ea391d8e8993ed30b4e From 7171721352a5b460cf7eced1be7f27519f0d31aa Mon Sep 17 00:00:00 2001 From: kgal Date: Thu, 9 Feb 2023 12:46:10 -0500 Subject: [PATCH 05/13] Update quick_build.yml --- .github/workflows/quick_build.yml | 232 ++++++++++++------------------ 1 file changed, 89 insertions(+), 143 deletions(-) diff --git a/.github/workflows/quick_build.yml b/.github/workflows/quick_build.yml index e1673098..6a143a06 100644 --- a/.github/workflows/quick_build.yml +++ b/.github/workflows/quick_build.yml @@ -29,65 +29,59 @@ jobs: - name: Install Jing run: wget -O - https://github.com/relaxng/jing-trang/releases/download/V20181222/jing-20181222.zip | jar -x - # Get current banch name to use it as dest directory - - name: Extract branch name - id: extract_branch - shell: bash - run: echo "##[set-output name=branch;]$(echo ${GITHUB_REF#refs/heads/})" - + - name: Set branch name + run: echo "action_branch=$(echo ${GITHUB_REF#refs/heads/})" >> $GITHUB_ENV + - name: Quick Build - run: | - pwd - WARN_PATH="output/SanityChecksOutput.md" make + run: WARN_PATH="output/SanityChecksOutput.md" make + # PDFify - name: PDFify - if: ${{ github.ref_name != 'master' }} + if: ${{ github.event_name == 'workflow_dispatch' }} run: | sudo apt-get install -y wkhtmltopdf xvfb xvfb-run --auto-servernum --server-args='-screen 0, 1024x768x16' /usr/bin/wkhtmltopdf \ - --javascript-delay 15000 --footer-right '[page]' \ + --enable-local-file-access --javascript-delay 15000 --footer-right '[page]' \ file://${PWD}/output/${PWD##*/}.html?expand=on \ output/${PWD##*/}-paged.pdf + - id: validate run: | RNG_OUT="output/ValidationReport.txt" make validate || true - echo ::set-output name=VALERRORS::$(wc -l output/ValidationReport.txt | { read first rest ; echo $first ; } ) + - name: Set valerrors + run: echo "action_valerrors=$(wc -l output/ValidationReport.txt | { read first rest ; echo $first ; } )" >> $GITHUB_ENV + - id: spellcheck run: | SPELL_OUT="output/SpellCheckReport.txt" make spellcheck - echo ::set-output name=LINES::$(wc -l output/SpellCheckReport.txt | { read first rest ; echo $first ; } ) - - id: tdate - run: | - echo "##[set-output name=TDATE;]$(cd transforms && git log -1 --format=%cs; cd -)" + - name: Set spellerrors + run: echo "action_spellerrors=$(wc -l output/SpellCheckReport.txt | { read first rest ; echo $first ; } )" >> $GITHUB_ENV + + - name: Get Transforms Date +# run: echo "action_tdate=2002222" >> $GITHUB_ENV + run: echo "action_tdate=$(cd transforms && git log -1 --format=%cs; cd ->/dev/null)" >> $GITHUB_ENV + - name: Setup Java JDK + uses: actions/setup-java@v1.4.3 + with: + java-version: 1.8 -# ======= -# echo "##[set-output name=TDATE;]$(cd transforms && git log -1 --format=%cs; cd -)" # - -# - name: Setup Java JDK -# uses: actions/setup-java@v1.4.3 -# with: -# java-version: 1.8 -# - name: Get DaisyDiff -# run: | -# wget -O- https://github.com/AndroidKitKat/ExecuteDaisy/archive/master.zip | jar -x -# [ -d "output/images" ] || mkdir "output/images"; -# cp -u -r ExecuteDaisy-master/js ExecuteDaisy-master/css output; -# cp -u ExecuteDaisy-master/images/* output/images; + - name: Get DaisyDiff + run: | + wget -O- https://github.com/AndroidKitKat/ExecuteDaisy/archive/master.zip | jar -x + [ -d "output/images" ] || mkdir "output/images"; + cp -u -r ExecuteDaisy-master/js ExecuteDaisy-master/css output; + cp -u ExecuteDaisy-master/images/* output/images; -# - name: Make tmp dir -# run: mkdir tmp + - name: Make tmp dir + run: mkdir tmp -# # - name: Diff against specified versions -# # run: DAISY_DIR=ExecuteDaisy-master make diff -# >>>>>>> release-3.2 - - name: diff - run: make diff || true; + run: TMP=tmp make diff || true; # Little diff depends on having a git history. # The current checkout has depth=1 and has no history #- name: little diff @@ -103,96 +97,69 @@ jobs: ls input/tds/*.xml ; then echo "Master branch should not have TDs" >> output/TDValidationReport.txt fi - echo "##[set-output name=TDCOLOR;]$(if [ -s output/TDValidationReport.txt ]; then echo orange; else echo green; fi)" - echo "##[set-output name=TDWARNS;]$( wc -l output/TDValidationReport.txt | { read first rest ; echo $first;} )" if ls input/tds/*.xml; then PP_XML=output/effective.xml PP_RELEASE_HTML=output/AppliedTDs.html make release + java -jar ExecuteDaisy-master/*.jar output/*-release.html output/AppliedTDs.html --file=output/AppliedTDs-Diff.html fi -# MDF can do -# java -jar ExecuteDaisy-master/*.jar output/*-release.html output/AppliedTDs.html --file=output/AppliedTDs-Diff.html - - - - name: Make a directory listing - run: > - cd output; - (echo "Listing"; - date; - echo "
    "; - for aa in $(find . -name '*.*'); do - echo "
  1. $aa
    2. "; - done; - echo "
") > index.html - cd - - - - name: Prepare environment - id: coverage - run: | - # Generates a GitHub Workflow output named `lines` with a coverage value - echo "##[set-output name=spellcolor;]$(if [ 0 = ${{ steps.spellcheck.outputs.LINES }} ]; then echo green; else echo red; fi)" - echo "##[set-output name=valcolor;]$(if [ 0 = ${{ steps.validate.outputs.VALERRORS }} ]; then echo green; else echo red; fi)" - # Output values to be used by other steps - echo "##[set-output name=path;]${BADGE_PATH}" - echo "##[set-output name=branch;]${BRANCH}" - env: - BADGE_PATH: output/warnings-badge.svg - BRANCH: gh-pages - - name: Get Status + - name: Set TD badge attributes + run: | + echo "action_tdcolor=$(if [ -s output/TDValidationReport.txt ]; then echo orange; else echo green; fi)" >> $GITHUB_ENV + echo "action_tdwarns=$(wc -l output/TDValidationReport.txt | { read first rest ; echo $first;} )" >> $GITHUB_ENV + + + - name: Validate Effective run: | - echo ::set-output name=WORD::$(if [ -s output/SanityChecksOutput.md ]; then echo some; else echo none; fi ) - echo ::set-output name=COLOR::$(if [ -s output/SanityChecksOutput.md ]; then echo red; else echo green; fi ) - id: status + echo "action_tdcolor=$(if [ -s output/TDValidationReport.txt ]; then echo orange; else echo green; fi)" >> $GITHUB_ENV + echo "action_tdwarns=$(wc -l output/TDValidationReport.txt | { read first rest ; echo $first;} )" >> $GITHUB_ENV + - # - uses: actions/checkout@v1 - # with: - # ref: ${{ steps.coverage.outputs.branch }} - # # Create the directory where badges will be saved, if needed - # - name: Create destination directory - # env: - # BADGE_PATH: ${{ steps.coverage.outputs.path }} - # run: mkdir -p "${BADGE_PATH%/*}" + - name: Prepare environment + run: | + # Generates a GitHub Workflow output named `lines` with a coverage value + echo "action_spellcolor=$(if [ 0 = ${{ env.action_spellerrors }} ]; then echo green; else echo red; fi)" >> $GITHUB_ENV + echo "action_valcolor=$(if [ 0 = ${{ env.action_valerrors }} ]; then echo green; else echo red; fi)" >> $GITHUB_ENV + echo "action_sanitystatus=$(if [ -s output/SanityChecksOutput.md ]; then echo some; else echo none; fi)" >> $GITHUB_ENV + echo "action_sanitycolor=$(if [ -s output/SanityChecksOutput.md ]; then echo red; else echo green; fi )" >> $GITHUB_ENV + + # Use the output from the `coverage` step - name: Generate the spelling badge SVG image uses: emibcn/badge-action@v1 with: label: 'Misspellings' - status: ${{ steps.spellcheck.outputs.LINES }} - color: ${{ steps.coverage.outputs.spellcolor }} + status: ${{ env.action_spellerrors }} + color: ${{ env.action_spellcolor }} path: output/spell-badge.svg - - name: Generate the built branch SVG + # Use the output from the `coverage` step + - name: Generate the validation badge SVG image uses: emibcn/badge-action@v1 with: - label: 'Last Built' - status: ${{ steps.extract_branch.outputs.branch }} - color: black - path: "output/build-branch-badge.svg" - + label: 'Validation' + status: ${{ env.action_valerrors }} + color: ${{ env.action_valcolor }} + path: output/validation.svg - # - name: Upload badge as artifact - # uses: actions/upload-artifact@v2 - # with: - # name: badge - # path: build-branch-badge.svg - # if-no-files-found: error # Use the output from the `coverage` step - name: Generate the badge SVG image uses: emibcn/badge-action@v1 with: label: 'Warnings' - status: ${{ steps.status.outputs.WORD }} - color: ${{ steps.status.outputs.COLOR }} + status: ${{ env.action_sanitystatus }} + color: ${{ env.action_sanitycolor }} path: output/warnings.svg + - name: Generate the transforms badge uses: emibcn/badge-action@v1 with: label: 'Transforms' - status: ${{ steps.tdate.outputs.TDATE }} + status: ${{ env.action_tdate }} color: gray path: output/transforms.svg @@ -200,66 +167,45 @@ jobs: uses: emibcn/badge-action@v1 with: label: 'TDs' - status: ${{steps.tds.outputs.TDWARNS}} - color: ${{steps.tds.outputs.TDCOLOR}} + status: ${{ env.action_tdwarns }} + color: ${{ env.action_tdcolor }} path: output/tds.svg + - name: Prepare checkout + run: | + pwd + ls + echo "---" + mkdir gh-pages - - # Use the output from the `coverage` step - - name: Generate the validation badge SVG image - uses: emibcn/badge-action@v1 + - uses: actions/checkout@v3 with: - label: 'Validation' - status: ${{ steps.validate.outputs.VALERRORS }} - color: ${{ steps.coverage.outputs.valcolor }} - path: output/validation.svg + ref: gh-pages + path: gh-pages - - id: debug + - name: Move output to branch run: | - ls - ls output pwd + ls + echo "+++" + rm -rf gh-pages/${{ env.action_branch }} + mv output gh-pages/${{ env.action_branch }} + - name: Make listing + run: | + cd gh-pages + (echo "Listing"; + date; + echo "
    "; + for aa in $(find . -name '*.*'); do + echo "
  1. $aa
    2. "; + done; + echo "
") > index.html - name: Deploy 🚀 uses: JamesIves/github-pages-deploy-action@4.0.0 with: branch: gh-pages # The branch the action should deploy to. - folder: output # The folder the action should deploy. + folder: gh-pages # The folder the action should deploy. - # - name: Commit badges - # continue-on-error: true - # env: - # BADGE: ${{ steps.coverage.outputs.path }} - # run: | - # git config --local user.email "action@github.com" - # git config --local user.name "GitHub Action" - # git add output #warnings.svg validation.svg build-branch-badge.svg spell-badge.svg transforms.svg tds.svg - # git commit -m "Update files" - - # # - name: Upload badge as artifact - # # - name: Upload badge as artifact - # # uses: actions/upload-artifact@v2 - # # with: - # # name: badge - # # path: ${{ steps.coverage.outputs.path }} - # # if-no-files-found: error - - # # - name: Commit badges - # # continue-on-error: true - # # env: - # # BADGE: ${{ steps.coverage.outputs.path }} - # # run: | - # # git config --local user.email "action@github.com" - # # git config --local user.name "GitHub Action" - # # git add "${{ steps.extract_branch.outputs.branch }}" - # # git commit -m "Add/Update badges" - - # - name: Push badge commit - # uses: ad-m/github-push-action@master - # if: ${{ success() }} - # with: - # github_token: ${{ secrets.GITHUB_TOKEN }} - # branch: ${{ steps.coverage.outputs.branch }} From 7217460971976575ff306b85c82c62cf84b955ac Mon Sep 17 00:00:00 2001 From: kgal Date: Fri, 3 Mar 2023 11:53:52 -0500 Subject: [PATCH 06/13] Update quick_build.yml --- .github/workflows/quick_build.yml | 82 ++++++++++++++++++++----------- 1 file changed, 53 insertions(+), 29 deletions(-) diff --git a/.github/workflows/quick_build.yml b/.github/workflows/quick_build.yml index 6a143a06..743c538e 100644 --- a/.github/workflows/quick_build.yml +++ b/.github/workflows/quick_build.yml @@ -1,4 +1,4 @@ -name: QuickBuild +name: QuickBuild v4.1 on: push: @@ -18,7 +18,7 @@ jobs: name: Quick Build steps: - name: Checkout project and transforms - uses: actions/checkout@v2 + uses: actions/checkout@v3 with: submodules: true @@ -31,13 +31,16 @@ jobs: - name: Set branch name run: echo "action_branch=$(echo ${GITHUB_REF#refs/heads/})" >> $GITHUB_ENV + + - name: Set base URL + run: echo "action_projname=${PWD##*/}" >> $GITHUB_ENV - name: Quick Build run: WARN_PATH="output/SanityChecksOutput.md" make # PDFify - name: PDFify - if: ${{ github.event_name == 'workflow_dispatch' }} + if: ${{ github.event_name == 'workflow_dispatch' }} || ${{ github.refname != 'master' }} run: | sudo apt-get install -y wkhtmltopdf xvfb xvfb-run --auto-servernum --server-args='-screen 0, 1024x768x16' /usr/bin/wkhtmltopdf \ @@ -63,12 +66,7 @@ jobs: - name: Get Transforms Date # run: echo "action_tdate=2002222" >> $GITHUB_ENV run: echo "action_tdate=$(cd transforms && git log -1 --format=%cs; cd ->/dev/null)" >> $GITHUB_ENV - - - name: Setup Java JDK - uses: actions/setup-java@v1.4.3 - with: - java-version: 1.8 - + - name: Get DaisyDiff run: | wget -O- https://github.com/AndroidKitKat/ExecuteDaisy/archive/master.zip | jar -x @@ -105,9 +103,13 @@ jobs: - name: Set TD badge attributes run: | - echo "action_tdcolor=$(if [ -s output/TDValidationReport.txt ]; then echo orange; else echo green; fi)" >> $GITHUB_ENV - echo "action_tdwarns=$(wc -l output/TDValidationReport.txt | { read first rest ; echo $first;} )" >> $GITHUB_ENV - + if ls input/tds/*.xml; then + echo "action_tdcolor=$(if [ -s output/TDValidationReport.txt ]; then echo orange; else echo green; fi)" >> $GITHUB_ENV + echo "action_tdwarns=$(wc -l output/TDValidationReport.txt | { read first rest ; echo $first;} )" >> $GITHUB_ENV + else + echo "action_tdcolor=gray" >> $GITHUB_ENV + echo "action_tdwarns=N/A" >> $GITHUB_ENV + fi - name: Validate Effective run: | @@ -115,7 +117,6 @@ jobs: echo "action_tdwarns=$(wc -l output/TDValidationReport.txt | { read first rest ; echo $first;} )" >> $GITHUB_ENV - - name: Prepare environment run: | # Generates a GitHub Workflow output named `lines` with a coverage value @@ -126,18 +127,18 @@ jobs: - # Use the output from the `coverage` step - name: Generate the spelling badge SVG image - uses: emibcn/badge-action@v1 + uses: emibcn/badge-action@v2.0.2 with: label: 'Misspellings' status: ${{ env.action_spellerrors }} color: ${{ env.action_spellcolor }} path: output/spell-badge.svg - # Use the output from the `coverage` step + + - name: Generate the validation badge SVG image - uses: emibcn/badge-action@v1 + uses: emibcn/badge-action@v2.0.2 with: label: 'Validation' status: ${{ env.action_valerrors }} @@ -145,9 +146,8 @@ jobs: path: output/validation.svg - # Use the output from the `coverage` step - - name: Generate the badge SVG image - uses: emibcn/badge-action@v1 + - name: Generate the warnings badge + uses: emibcn/badge-action@v2.0.2 with: label: 'Warnings' status: ${{ env.action_sanitystatus }} @@ -156,7 +156,7 @@ jobs: - name: Generate the transforms badge - uses: emibcn/badge-action@v1 + uses: emibcn/badge-action@v2.0.2 with: label: 'Transforms' status: ${{ env.action_tdate }} @@ -164,18 +164,44 @@ jobs: path: output/transforms.svg - name: TD Badge - uses: emibcn/badge-action@v1 + uses: emibcn/badge-action@v2.0.2 with: label: 'TDs' status: ${{ env.action_tdwarns }} color: ${{ env.action_tdcolor }} path: output/tds.svg + - name: Make Dashboard Snippet + run: | + ( + rurl="https://raw.githubusercontent.com/commoncriteria/${{env.action_projname}}/gh-pages/${{env.action_branch}}" + surl="https://commoncriteria.github.io/${{env.action_projname}}/${{env.action_branch}}" + gurl="https://github.com/commoncriteria/${{env.action_projname}}/blob/gh-pages/${{env.action_branch}}" + echo '[cols="1,1,1,1,1,1,1,1"]' + echo '|===' + echo "8+|${{ env.action_projname }} " + echo "| https://github.com/commoncriteria/${{env.action_projname}}/tree/${{env.action_branch}}[${{ env.action_branch }}] " + echo "a| $surl/${{env.action_projname}}-release.html[📄]" + echo "a|[link=$gurl/ValidationReport.txt]" + echo "image::$rurl/validation.svg[Validation]" + echo "a|[link=$gurl/SanityChecksOutput.md]" + echo "image::$rurl/warnings.svg[SanityChecks]" + echo "a|[link=$gurl/SpellCheckReport.txt]" + echo "image::$rurl/spell-badge.svg[SpellCheck]" + echo "a|[link=$gurl/TDValidationReport.txt]" + echo "image::$rurl/tds.svg[TDs]" + echo "a|image::$rurl/transforms.svg[transforms,150]" + echo "a| " + for aa in output/*.html output/*.pdf; do + echo "$surl/${aa#*/}[${aa#*/}] +" + done + echo '|===' + ) > output/Minidash.adoc + + + - name: Prepare checkout run: | - pwd - ls - echo "---" mkdir gh-pages - uses: actions/checkout@v3 @@ -183,11 +209,9 @@ jobs: ref: gh-pages path: gh-pages + - name: Move output to branch run: | - pwd - ls - echo "+++" rm -rf gh-pages/${{ env.action_branch }} mv output gh-pages/${{ env.action_branch }} @@ -203,7 +227,7 @@ jobs: echo "") > index.html - name: Deploy 🚀 - uses: JamesIves/github-pages-deploy-action@4.0.0 + uses: JamesIves/github-pages-deploy-action@v4 with: branch: gh-pages # The branch the action should deploy to. folder: gh-pages # The folder the action should deploy. From d929ad8298ca49640e037ed145a16f3376801091 Mon Sep 17 00:00:00 2001 From: kgal Date: Fri, 3 Mar 2023 11:57:23 -0500 Subject: [PATCH 07/13] Create README.adoc --- README.adoc | 105 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 README.adoc diff --git a/README.adoc b/README.adoc new file mode 100644 index 00000000..8c7bca89 --- /dev/null +++ b/README.adoc @@ -0,0 +1,105 @@ +== Protection Profile for Mobile Device Fundamentals +[cols="1,1,1,1,1,1,1,1"] +|=== +8+|mobile-device +| https://github.com/commoncriteria/mobile-device/tree/release-3.3[release-3.3] +a| https://commoncriteria.github.io/mobile-device/release-3.3/mobile-device-release.html[📄] +a|[link=https://github.com/commoncriteria/mobile-device/blob/gh-pages/release-3.3/ValidationReport.txt] +image::https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/release-3.3/validation.svg[Validation] +a|[link=https://github.com/commoncriteria/mobile-device/blob/gh-pages/release-3.3/SanityChecksOutput.md] +image::https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/release-3.3/warnings.svg[SanityChecks] +a|[link=https://github.com/commoncriteria/mobile-device/blob/gh-pages/release-3.3/SpellCheckReport.txt] +image::https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/release-3.3/spell-badge.svg[SpellCheck] +a|[link=https://github.com/commoncriteria/mobile-device/blob/gh-pages/release-3.3/TDValidationReport.txt] +image::https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/release-3.3/tds.svg[TDs] +a|image::https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/release-3.3/transforms.svg[transforms,150] +a| +https://commoncriteria.github.io/mobile-device/release-3.3/mobile-device-release-linkable.html[mobile-device-release-linkable.html] + +https://commoncriteria.github.io/mobile-device/release-3.3/mobile-device-release.html[mobile-device-release.html] + +https://commoncriteria.github.io/mobile-device/release-3.3/mobile-device.html[mobile-device.html] + +https://commoncriteria.github.io/mobile-device/release-3.3/mobile-device-paged.pdf[mobile-device-paged.pdf] + +|=== + + +https://github.com/commoncriteria/mobile-device/issues[image:https://img.shields.io/github/issues/commoncriteria/mobile-device.svg?maxAge=2592000[GitHub +issues Open]] + +This repository hosts the draft version of the Protection Profile for +Mobile Device Fundamentals based on the +https://commoncriteria.github.io/pp/mobile-device/mobile-device-esr.html[Essential +Security Requirements (ESR)] for this technology class of products. This +repository is used to facilitate collaboration and development on the +draft document. See the link:#Release-Version[release] section if you +are looking for the officially released version for evaluations. A list +of products that have passed evaluation against this Protection Profile +can be found https://www.niap-ccevs.org/Profile/Info.cfm?id=417[here]. + +=== Draft Version + +* https://commoncriteria.github.io/pp/mobile-device/mobile-device-release.html[Protection +Profile for Mobile Device Fundamentals] (html) +* https://commoncriteria.github.io/pp/mobile-device/mobile-device-release.pdf[Protection +Profile for Mobile Device Fundamentals] (pdf) + +=== Release Version + +* https://www.niap-ccevs.org/Profile/Info.cfm?PPID=455&id=455[Protection +Profile for Mobile Device Fundamentals v3.2] + +=== Contributing + +If you are interested in contributing directly to future versions the +this Protection Profile, please consider joining the NIAP technical +community. * +https://www.niap-ccevs.org/NIAP_Evolution/tech_communities.cfm[How to +join the NIAP Technical Community (Mailing list and updates)] + +=== Feedback + +Questions, comments, and fixes can be submitted to the +https://github.com/commoncriteria/mobile-device/issues[repository issue +tracker] + +=== Quickstart + +To clone this project along with its _transforms_ submodule run: + +.... + git clone --recursive git@github.com:commoncriteria/mobile-device.git +.... + +or + +.... + git clone --recursive https://github.com/commoncriteria/mobile-device.git +.... + +To pull updates from the upstream _transforms_ submodule and commit them +run: + +.... + git submodule update --remote transforms &&\ + git add transforms &&\ + git commit +.... + +==== Development Info + +https://github.com/commoncriteria/transforms/wiki/Working-with-Transforms-as-a-Submodule[Help +working with Transforms Submodule] + +=== Repository Content + +* input - Contains the `meat' of the project. It’s the input content (in +XML form) that gets transformed to readable html. +* output - The output directory where the html is placed after +transformation. +* output/images - The directory where images are stored +* transforms - Points to the transform subproject which is really a +repository for resources shared amongst many Common Criteria projects. + +=== Links + +* https://www.niap-ccevs.org/[National Information Assurance Partnership +(NIAP)] +* https://www.commoncriteriaportal.org/[Common Criteria Portal] From 9a22a949a78ee53bde07c1241c1f3d92978ccaf5 Mon Sep 17 00:00:00 2001 From: kgal Date: Fri, 3 Mar 2023 11:57:53 -0500 Subject: [PATCH 08/13] Delete README.md --- README.md | 71 ------------------------------------------------------- 1 file changed, 71 deletions(-) delete mode 100644 README.md diff --git a/README.md b/README.md deleted file mode 100644 index 26f5e06a..00000000 --- a/README.md +++ /dev/null @@ -1,71 +0,0 @@ -Protection Profile for Mobile Device Fundamentals -============================================= -![Master Badges](https://img.shields.io/badge/Build-master-black.svg) -![Build](https://github.com/commoncriteria/mobile-device/workflows/Build/badge.svg) -![Validate](https://github.com/commoncriteria/mobile-device/workflows/Validate/badge.svg) - -![Last QuickBuilt Branch](https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/build-branch-badge.svg) -[![Validation](https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/validation.svg)](https://github.com/commoncriteria/mobile-device/blob/gh-pages/ValidationReport.txt) -[![SanityChecks](https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/warnings.svg)](https://github.com/commoncriteria/mobile-device/blob/gh-pages/SanityChecksOutput.md) -[![SpellCheck](https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/spell-badge.svg)](https://github.com/commoncriteria/mobile-device/blob/gh-pages/SpellCheckReport.txt) -[![QuickBuild](https://github.com/commoncriteria/mobile-device/actions/workflows/quick_build.yml/badge.svg)](https://commoncriteria.github.io/mobile-device) - -[![GitHub issues Open](https://img.shields.io/github/issues/commoncriteria/mobile-device.svg?maxAge=2592000)](https://github.com/commoncriteria/mobile-device/issues) - -This repository hosts the draft version of the Protection Profile for Mobile Device Fundamentals based on the -[Essential Security Requirements (ESR)](https://commoncriteria.github.io/pp/mobile-device/mobile-device-esr.html) for this technology class of -products. This repository is used to facilitate collaboration and development on the draft document. -See the [release](#Release-Version) section if you are looking for the officially released version for evaluations. -A list of products that have passed evaluation against this Protection Profile can be found [here](https://www.niap-ccevs.org/Profile/Info.cfm?id=417). - - -## Draft Version -* [Protection Profile for Mobile Device Fundamentals ](https://commoncriteria.github.io/pp/mobile-device/mobile-device-release.html) (html) -* [Protection Profile for Mobile Device Fundamentals ](https://commoncriteria.github.io/pp/mobile-device/mobile-device-release.pdf) (pdf) - -## Release Version -* [Protection Profile for Mobile Device Fundamentals v3.2](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=455&id=455) - -## Contributing - -If you are interested in contributing directly to future versions the this Protection Profile, please consider joining the NIAP technical community. -* [How to join the NIAP Technical Community (Mailing list and updates)](https://www.niap-ccevs.org/NIAP_Evolution/tech_communities.cfm) - -## Feedback - -Questions, comments, and fixes can be submitted to the [repository issue tracker](https://github.com/commoncriteria/mobile-device/issues) - -## Quickstart -To clone this project along with its _transforms_ submodule run: - -```` - git clone --recursive git@github.com:commoncriteria/mobile-device.git -```` -or -```` - git clone --recursive https://github.com/commoncriteria/mobile-device.git -```` - -To pull updates from the upstream _transforms_ submodule and commit them run: -```` - git submodule update --remote transforms &&\ - git add transforms &&\ - git commit -```` - -### Development Info -[Help working with Transforms Submodule](https://github.com/commoncriteria/transforms/wiki/Working-with-Transforms-as-a-Submodule) - -## Repository Content -* input - Contains the 'meat' of the project. It's the input content (in XML form) that gets transformed to readable html. -* output - The output directory where the html is placed after transformation. -* output/images - The directory where images are stored -* transforms - Points to the transform subproject which is really a repository for resources shared amongst many Common Criteria projects. - -## Links -* [National Information Assurance Partnership (NIAP)](https://www.niap-ccevs.org/) -* [Common Criteria Portal](https://www.commoncriteriaportal.org/) - -## License - -See [License](./LICENSE) From 5776d7e3e3569338535a96da24378798b7d3af4e Mon Sep 17 00:00:00 2001 From: kgal Date: Fri, 3 Mar 2023 13:30:14 -0500 Subject: [PATCH 09/13] Update quick_build.yml --- .github/workflows/quick_build.yml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/.github/workflows/quick_build.yml b/.github/workflows/quick_build.yml index 743c538e..7477469b 100644 --- a/.github/workflows/quick_build.yml +++ b/.github/workflows/quick_build.yml @@ -40,7 +40,7 @@ jobs: # PDFify - name: PDFify - if: ${{ github.event_name == 'workflow_dispatch' }} || ${{ github.refname != 'master' }} + if: ${{ env.action_branch != 'master' }} run: | sudo apt-get install -y wkhtmltopdf xvfb xvfb-run --auto-servernum --server-args='-screen 0, 1024x768x16' /usr/bin/wkhtmltopdf \ @@ -85,7 +85,6 @@ jobs: #- name: little diff # run: make little-diff || true - - name: Outstanding TDs id: tds run: | From 954da6d0098f41d226b78d60ac1080f9fb025b2b Mon Sep 17 00:00:00 2001 From: kgal Date: Wed, 15 Mar 2023 08:26:04 -0400 Subject: [PATCH 10/13] Update quick_build.yml --- .github/workflows/quick_build.yml | 54 +++++++++++++++++++++++++------ 1 file changed, 44 insertions(+), 10 deletions(-) diff --git a/.github/workflows/quick_build.yml b/.github/workflows/quick_build.yml index 7477469b..9cbb0df4 100644 --- a/.github/workflows/quick_build.yml +++ b/.github/workflows/quick_build.yml @@ -1,4 +1,4 @@ -name: QuickBuild v4.1 +name: QuickBuild v4.3 on: push: @@ -94,10 +94,8 @@ jobs: ls input/tds/*.xml ; then echo "Master branch should not have TDs" >> output/TDValidationReport.txt fi - if ls input/tds/*.xml; then - PP_XML=output/effective.xml PP_RELEASE_HTML=output/AppliedTDs.html make release - java -jar ExecuteDaisy-master/*.jar output/*-release.html output/AppliedTDs.html --file=output/AppliedTDs-Diff.html - fi + PP_XML=output/effective.xml PP_RELEASE_HTML=output/AppliedTDs.html make release + java -jar ExecuteDaisy-master/*.jar output/*-release.html output/AppliedTDs.html --file=output/AppliedTDs-Diff.html - name: Set TD badge attributes @@ -172,10 +170,10 @@ jobs: - name: Make Dashboard Snippet run: | - ( rurl="https://raw.githubusercontent.com/commoncriteria/${{env.action_projname}}/gh-pages/${{env.action_branch}}" surl="https://commoncriteria.github.io/${{env.action_projname}}/${{env.action_branch}}" gurl="https://github.com/commoncriteria/${{env.action_projname}}/blob/gh-pages/${{env.action_branch}}" + ( echo '[cols="1,1,1,1,1,1,1,1"]' echo '|===' echo "8+|${{ env.action_projname }} " @@ -190,14 +188,50 @@ jobs: echo "a|[link=$gurl/TDValidationReport.txt]" echo "image::$rurl/tds.svg[TDs]" echo "a|image::$rurl/transforms.svg[transforms,150]" - echo "a| " - for aa in output/*.html output/*.pdf; do - echo "$surl/${aa#*/}[${aa#*/}] +" - done + echo "a| [link=$gurl/HTMLs.adoc]" + echo "image::$rurl/html_count.svg[HTML Count]" + echo "[link=$gurl/PDFs.adoc]" + echo "image::$rurl/pdf_count.svg[PDF Count]" echo '|===' ) > output/Minidash.adoc + - name: HTML List + run: | + surl="https://commoncriteria.github.io/${{env.action_projname}}/${{env.action_branch}}" + ( for aa in output/*.html ; do + echo "* $surl/${aa#*/}[${aa#*/}]" + done ) > output/HTMLs.adoc + HTML_COUNT=$(wc -l < output/HTMLs.adoc) + echo "action_html_count=$HTML_COUNT" >> $GITHUB_ENV + + - name: PDF List + run: | + surl="https://commoncriteria.github.io/${{env.action_projname}}/${{env.action_branch}}" + cd output + (for aa in $(find . -name '*.pdf') ; do + echo "* $surl/${aa#*/}[${aa#*/}]" + done ) > PDFs.adoc + PDF_COUNT=$(wc -l < PDFs.adoc) + echo "action_pdf_count=$PDF_COUNT" >> $GITHUB_ENV + + + - name: HTML Badge + uses: emibcn/badge-action@v2.0.2 + with: + label: 'HTMLs' + status: ${{ env.action_html_count }} + color: gray + path: output/html_count.svg + + - name: PDF Badge + uses: emibcn/badge-action@v2.0.2 + with: + label: 'PDFs' + status: ${{ env.action_pdf_count }} + color: gray + path: output/pdf_count.svg + - name: Prepare checkout run: | From 74c30a135652a326af7fa30202aabc32b27d6295 Mon Sep 17 00:00:00 2001 From: kgal Date: Wed, 15 Mar 2023 14:03:37 -0400 Subject: [PATCH 11/13] Update quick_build.yml --- .github/workflows/quick_build.yml | 43 +++++++++++++++++++++---------- 1 file changed, 29 insertions(+), 14 deletions(-) diff --git a/.github/workflows/quick_build.yml b/.github/workflows/quick_build.yml index 9cbb0df4..b50ff66a 100644 --- a/.github/workflows/quick_build.yml +++ b/.github/workflows/quick_build.yml @@ -1,4 +1,4 @@ -name: QuickBuild v4.3 +name: QuickBuild v4.4 on: push: @@ -38,16 +38,27 @@ jobs: - name: Quick Build run: WARN_PATH="output/SanityChecksOutput.md" make + + - name: Branch Test + run: | + branchname=$(echo ${GITHUB_REF#refs/heads/}) + if [[ $branchname =~ [0-9] ]]; then + echo "action_is_release=YES" >> $GITHUB_ENV + else + echo "action_is_release=NO" >> $GITHUB_ENV + fi + # PDFify - name: PDFify - if: ${{ env.action_branch != 'master' }} + if: ${{ env.action_is_release == 'YES' }} run: | sudo apt-get install -y wkhtmltopdf xvfb - xvfb-run --auto-servernum --server-args='-screen 0, 1024x768x16' /usr/bin/wkhtmltopdf \ - --enable-local-file-access --javascript-delay 15000 --footer-right '[page]' \ - file://${PWD}/output/${PWD##*/}.html?expand=on \ - output/${PWD##*/}-paged.pdf - + cd output + for aa in *.html; do + xvfb-run --auto-servernum --server-args='-screen 0, 1024x768x16' /usr/bin/wkhtmltopdf \ + --enable-local-file-access --javascript-delay 15000 --footer-right '[page]' \ + file://${PWD}/${aa}?expand=on ${aa}.pdf + done - id: validate run: | @@ -100,18 +111,22 @@ jobs: - name: Set TD badge attributes run: | - if ls input/tds/*.xml; then - echo "action_tdcolor=$(if [ -s output/TDValidationReport.txt ]; then echo orange; else echo green; fi)" >> $GITHUB_ENV - echo "action_tdwarns=$(wc -l output/TDValidationReport.txt | { read first rest ; echo $first;} )" >> $GITHUB_ENV - else + NUM=$(ls input/tds/*.xml | wc -l) + if [ $NUM == 0 ]; then echo "action_tdcolor=gray" >> $GITHUB_ENV echo "action_tdwarns=N/A" >> $GITHUB_ENV + echo "GOING THROUGH HERE $NUM" + else + echo "action_tdcolor=$(if [ -s output/TDValidationReport.txt ]; then echo orange; else echo green; fi)" >> $GITHUB_ENV + echo "action_tdwarns=$NUM:$(wc -l output/TDValidationReport.txt | { read first rest ; echo $first;})" >> $GITHUB_ENV + echo "THERE ARE TDs $NUM" + fi - + # Not sure what the point of this is - name: Validate Effective run: | - echo "action_tdcolor=$(if [ -s output/TDValidationReport.txt ]; then echo orange; else echo green; fi)" >> $GITHUB_ENV - echo "action_tdwarns=$(wc -l output/TDValidationReport.txt | { read first rest ; echo $first;} )" >> $GITHUB_ENV + echo "action_effvalcolor=$(if [ -s output/TDValidationReport.txt ]; then echo orange; else echo green; fi)" >> $GITHUB_ENV + echo "action_effvalwarns=$(wc -l output/TDValidationReport.txt | { read first rest ; echo $first;} )" >> $GITHUB_ENV - name: Prepare environment From b352556c4cdf8a8de02b76882ea2205e31a0dbc7 Mon Sep 17 00:00:00 2001 From: jpham-mitre Date: Mon, 12 Aug 2024 17:33:59 -0400 Subject: [PATCH 12/13] table test --- input/mobile-device.xml | 10683 ++++++++------------------------------ 1 file changed, 2205 insertions(+), 8478 deletions(-) diff --git a/input/mobile-device.xml b/input/mobile-device.xml index d79bf295..99f6be64 100644 --- a/input/mobile-device.xml +++ b/input/mobile-device.xml @@ -1,83 +1,14 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + Mobile Device Fundamentals 3.3 - National Information Assurance Partnership + NIAP 2022-09-12 - ?? + application; software @@ -89,104 +20,32 @@ How is it differenet then me using subsection? 1.1 2014-01-12 - Typographical changes and additional clarifications in application notes. Removed - assignment from FCS_TLS_EXT.1 and limited testing to those ciphersuites in both - FCS_TLS_EXT.1 and FCS_TLS_EXT.2. + Typographical changes and additional clarifications in application notes. Removedassignment from FCS_TLS_EXT.1 and limited testing to those ciphersuites in bothFCS_TLS_EXT.1 and FCS_TLS_EXT.2. 2.0 2015-09-14 - Included changes based on Technical Rapid Response Team Decisions. Clarified many - requirements and evaluation activities. Mandated objective requirements: - - Application Access Control (FDP_ACF_EXT.1.2) - VPN Information Flow Control (FDP_IFC_EXT.1) - Added new objective requirements: - - Suite B cryptography for IEEE 802.11 - Certificate enrollment - Protection of additional key material types - Heap overflow protection - Bluetooth requirements - Cryptographic operation services for applications - Remote Attestation (FPT_NOT_EXT.1) - Added transition dates for some objective requirements. Included - hardware-isolated REK and key storage selections. Allowed key derivation by - REK. Clarified FTP_ITC_EXT.1 and added FDP_UPC_EXT.1. Mandated HTTPS and - TLS for application use. (FDP_UPC_EXT.1) Removed Dual_EC_DRBG as an approved - DRBG. Adopted new TLS requirements. Mandated TSF Wipe upon authentication - failure limit and required number of authentication failures be maintained across - reboot. Clarified Management Class. Included more domain isolation - discussion and tests. Updated Audit requirements and added Auditable Events - table. Added SFR Category Mapping Table. Updated Use Case - Templates. Moved Glossary to Introduction. + Included changes based on Technical Rapid Response Team Decisions. Clarified manyrequirements and evaluation activities. Mandated objective requirements:Application Access Control (FDP_ACF_EXT.1.2)VPN Information Flow Control (FDP_IFC_EXT.1) Added new objective requirements:Suite B cryptography for IEEE 802.11Certificate enrollmentProtection of additional key material typesHeap overflow protectionBluetooth requirementsCryptographic operation services for applicationsRemote Attestation (FPT_NOT_EXT.1) Added transition dates for some objective requirements. Includedhardware-isolated REK and key storage selections. Allowed key derivation byREK. Clarified FTP_ITC_EXT.1 and added FDP_UPC_EXT.1. Mandated HTTPS andTLS for application use. (FDP_UPC_EXT.1) Removed Dual_EC_DRBG as an approvedDRBG. Adopted new TLS requirements. Mandated TSF Wipe upon authenticationfailure limit and required number of authentication failures be maintained acrossreboot. Clarified Management Class. Included more domain isolationdiscussion and tests. Updated Audit requirements and added Auditable Eventstable. Added SFR Category Mapping Table. Updated Use CaseTemplates. Moved Glossary to Introduction. 3.0 2015-09-17 - Included changes based on Technical Rapid Response Team Decisions. Clarified - many requirements and evaluation activities. Mandated objective requirements: - - Generation of Audit Records (FAU_GEN.1) - Audit Storage Protection (FAU_STG.1) - Audit Storage Overwrite (FAU_STG.4) - Lock Screen DAR (FDP_DAR_EXT.2) - Discard Bluetooth Connection Attempts from Bluetooth Addresses with Existing - Connection (FIA_BLT_EXT.3) - JTAG Disablement (FPT_JTA) - Added new objective requirements: - - Application Backup - Biometric Authentication Factor - Access Control - User Authentication - Bluetooth Encryption - WLAN client requirements moved to Extended Package for WLAN Client. Added - SFRs to support BYOD Use Case BYOD Use Case Updated key destruction SFR - + Included changes based on Technical Rapid Response Team Decisions. Clarifiedmany requirements and evaluation activities. Mandated objective requirements:Generation of Audit Records (FAU_GEN.1)Audit Storage Protection (FAU_STG.1)Audit Storage Overwrite (FAU_STG.4)Lock Screen DAR (FDP_DAR_EXT.2)Discard Bluetooth Connection Attempts from Bluetooth Addresses with ExistingConnection (FIA_BLT_EXT.3)JTAG Disablement (FPT_JTA) Added new objective requirements:Application BackupBiometric Authentication FactorAccess ControlUser AuthenticationBluetooth Encryption WLAN client requirements moved to Extended Package for WLAN Client. AddedSFRs to support BYOD Use Case BYOD Use Case Updated key destruction SFR 3.1 2017-04-05 - Included changes based on Technical Rapid Response Team Decisions and incorporated - Technical Decisions. Modified biometric requirements: - FIA_UAU.5 - Added iris, face, voice and vein as supported modalities, in addition - to fingerprint (allowed in version 3) - FIA_BMG_EXT.1.1 - Clarified AA to specify that vendor evidence is acceptable and - expectations of evidence provided. - FIA_BMG_EXT.1.2 - SAFAR was changed to an assignment of a SAFAR no greater than - 1:500. - FIA_AFL_EXT.1 - Updated to allow each biometric modality to utilize an individual - or shared counter. - FCS_TLSC_EXT.1.1 - Removed TLS ciphersuites that utilized SHA1 and updated - optional ciphersuites to be uniformed across PPs. FCS_STG_EXT.2.2 - Modified to - require long term trusted channel key material be encrypted by an approved method. - FIA_UAU_EXT.1.1 - Modified to allow the long term trusted channel key material to be - available prior to password being entered at start-up. - + Included changes based on Technical Rapid Response Team Decisions and incorporatedTechnical Decisions. Modified biometric requirements: FIA_UAU.5 - Added iris, face, voice and vein as supported modalities, in additionto fingerprint (allowed in version 3)FIA_BMG_EXT.1.1 - Clarified AA to specify that vendor evidence is acceptable andexpectations of evidence provided. FIA_BMG_EXT.1.2 - SAFAR was changed to an assignment of a SAFAR no greater than1:500. FIA_AFL_EXT.1 - Updated to allow each biometric modality to utilize an individualor shared counter. FCS_TLSC_EXT.1.1 - Removed TLS ciphersuites that utilized SHA1 and updatedoptional ciphersuites to be uniformed across PPs. FCS_STG_EXT.2.2 - Modified torequire long term trusted channel key material be encrypted by an approved method.FIA_UAU_EXT.1.1 - Modified to allow the long term trusted channel key material to beavailable prior to password being entered at start-up. 3.2 2021-04-15 - Removed TLS SFRs and utilized TLS Functional Package Removed Bluetooth SFRs - and utilized Bluetooth Module. Bluetooth SFR moved to Implementation Dependent. - FPT_TUD_EXT.4.2 renumbered to - + Removed TLS SFRs and utilized TLS Functional Package Removed Bluetooth SFRsand utilized Bluetooth Module. Bluetooth SFR moved to Implementation Dependent.FPT_TUD_EXT.4.2 renumbered to 3.3 2022-09-12 - Integrated Biometrics cPP Module, Included changes based on Technical Rapid Response Team Decisions and open issues from GitHub. - Removed biometric definitions from Tech Terms - Removed FDP_PBA - Removed FIA_BMG - Updated FIA_UAU.5 to support bio cPP module - Moved FTA_TAB.1 to mandatory - Moved FAU_SAR.1 to mandatory - Added ECD - Updated WLAN Client reference from Extended Package to Module - Removed Diffie-Hellman group 14 selection from FCS_CKM.1.1 and FCS_CKM.2.1/UNLOCKED - + Integrated Biometrics cPP Module, Included changes based on Technical Rapid Response Team Decisions and open issues from GitHub.Removed biometric definitions from Tech TermsRemoved FDP_PBARemoved FIA_BMGUpdated FIA_UAU.5 to support bio cPP moduleMoved FTA_TAB.1 to mandatoryMoved FAU_SAR.1 to mandatoryAdded ECDUpdated WLAN Client reference from Extended Package to ModuleRemoved Diffie-Hellman group 14 selection from FCS_CKM.1.1 and FCS_CKM.2.1/UNLOCKED @@ -196,1749 +55,527 @@ How is it differenet then me using subsection? https://www.niap-ccevs.org/Profile/Info.cfm?PPID=439&id=439 - - - - https://github.com/commoncriteria/vpnclient - v2.4 - - - - - - https://github.com/commoncriteria/bluetooth - v1.0 - - - - - - https://github.com/commoncriteria/mdmagent - Release-1.0 - - - - - - https://github.com/commoncriteria/wlanclient - release-1.0 - - - - - https://github.com/biometricITC/cPP-biometrics/blob/master/Protection%20Profile/BiocPP.adoc - - - - - -The scope of this Protection Profile (PP) is to describe the security functionality of mobile devices in terms of [CC] and to define functional and assurance requirements for such devices. - - - - - - An anti-exploitation feature, + https://github.com/commoncriteria/vpnclientv2.4https://github.com/commoncriteria/bluetoothv1.0https://github.com/commoncriteria/mdmagentRelease-1.0https://github.com/commoncriteria/wlanclientrelease-1.0https://github.com/biometricITC/cPP-biometrics/blob/master/Protection%20Profile/BiocPP.adoc + + The scope of this Protection Profile (PP) is to describe the security functionality of mobile devices in terms of [CC] and to define functional and assurance requirements for such devices. + + An anti-exploitation feature, which loads memory mappings into unpredictable locations. ASLR makes it more difficult for an attacker to redirect control to code that they have introduced into the address space of - a process or the kernel. - The Administrator is responsible for management activities, + a process or the kernel. + The Administrator is responsible for management activities, including setting the policy that is applied by the enterprise on the Mobile Device. This administrator is likely to be acting remotely and could be the Mobile Device Management (MDM) Administrator acting through an MDM Agent. If the device is unenrolled, the user is - the administrator. - - - - - - Auxiliary boot modes are states in which the device + the administrator. + Auxiliary boot modes are states in which the device provides power to one or more components to provide an interface that enables an unauthenticated user to interact with either a specific component or several components that - exist outside of the device’s fully authenticated, operational state. - Authentication factor, which uses + exist outside of the device’s fully authenticated, operational state. + Authentication factor, which uses biometric sample, matched to a biometric authentication template to help establish - identity. - - - - - - - - - - - - - - - Application developers (or software companies) + identity. + Application developers (or software companies) often produce many applications under the same name. Mobile devices often allow shared - resources by such applications where otherwise resources would not be shared. - Security-related information whose + resources by such applications where otherwise resources would not be shared. + Security-related information whose disclosure or modification can compromise the security of a cryptographic module or - authentication system. - Program/application or data files that are stored or transmitted by a - server or Mobile Device (MD). - A key used to encrypt data-at-rest. - Developer modes are states in which additional services are - available to a user in order to provide enhanced system access for debugging of software. - - - - - - - - These keys are stored in the main file system encrypted - by another key and can be changed and sanitized. - The state in which the Mobile Device is managed with active - policy settings from the administrator. - - - Enterprise data is any data residing in the enterprise servers, + authentication system. + Program/application or data files that are stored or transmitted by a + server or Mobile Device (MD). + A key used to encrypt data-at-rest. + Developer modes are states in which additional services are + available to a user in order to provide enhanced system access for debugging of software. + These keys are stored in the main file system encrypted + by another key and can be changed and sanitized. + The state in which the Mobile Device is managed with active + policy settings from the administrator. + Enterprise data is any data residing in the enterprise servers, or temporarily stored on Mobile Devices to which the Mobile Device user is allowed access according to security policy defined by the enterprise and implemented by the - administrator. - These keys are stored in volatile memory. - - - - - - - - - - - - - - A DEK used to encrypt a file or a director when - File Encryption is used. FEKs are unique to each encrypted file or directory. - - - - The OS can only access these keys by reference, if - at all, during runtime. - - - - A hybrid authentication factor is one where a user has to - submit a combination of a biometric sample and a PIN or password and both must pass. If either factor fails, the entire attempt fails. The user shall not be made aware of which factor failed, if either fails. - These keys are stored as hardware-protected raw key and - cannot be changed or sanitized. - - - - - - The method of using multiple layers of encryption keys to protect + administrator. + These keys are stored in volatile memory. + A DEK used to encrypt a file or a director when + File Encryption is used. FEKs are unique to each encrypted file or directory. + The OS can only access these keys by reference, if + at all, during runtime. + A hybrid authentication factor is one where a user has to + submit a combination of a biometric sample and a PIN or password and both must pass. If either factor fails, the entire attempt fails. The user shall not be made aware of which factor failed, if either fails. + These keys are stored as hardware-protected raw key and + cannot be changed or sanitized. + The method of using multiple layers of encryption keys to protect data. A top layer key encrypts a lower layer key, which encrypts the data; this method can - have any number of layers. - - A key used to encrypt other keys, such as DEKs or - storage that contains keys. - - Powered on but most functionality is unavailable for use. User - authentication is required to access functionality. - - - A device which is composed of a hardware platform and + have any number of layers. + A key used to encrypt other keys, such as DEKs or + storage that contains keys. + Powered on but most functionality is unavailable for use. User + authentication is required to access functionality. + A device which is composed of a hardware platform and its system software. The device typically provides wireless connectivity and may include software for functions like secure messaging, email, web, VPN (Virtual Private Network) connection, and VoIP (Voice over IP), for access to the protected enterprise network, enterprise data and applications, - and for communicating to other Mobile Devices. - Mobile device management (MDM) products + and for communicating to other Mobile Devices. + Mobile device management (MDM) products allow enterprises to apply security policies to mobile devices. This system consists of two - primary components: the MDM Server and the MDM Agent. - - - - The MDM Agent is installed on a Mobile Device as an application or is + primary components: the MDM Server and the MDM Agent. + The MDM Agent is installed on a Mobile Device as an application or is part of the Mobile Device’s OS. The MDM Agent establishes a secure connection back to the - MDM Server controlled by the administrator. - Friction ridge characteristics that are used to individualize a + MDM Server controlled by the administrator. + Friction ridge characteristics that are used to individualize a fingerprint image. Minutia are the points where friction ridges begin, terminate, or split into two or more ridges. In many fingerprint systems, the minutia points are compared for - recognition purposes. - The individual authorized to physically control and + recognition purposes. + The individual authorized to physically control and operate the Mobile Device. Depending on the use case, this can be the device owner or an - individual authorized by the device owner. - A type or class of biometric system, such as fingerprint + individual authorized by the device owner. + A type or class of biometric system, such as fingerprint recognition, facial recognition, iris recognition, voice recognition, signature/sign, and - others. - These keys are stored as hardware-protected raw key and can - be changed or sanitized. - - - - - - Software that runs at the highest privilege level + others. + These keys are stored as hardware-protected raw key and can + be changed or sanitized. + Software that runs at the highest privilege level and can directly control hardware resources. Modern Mobile Devices typically have at least two primary operating systems: one, which runs on the application processor and one, which runs on the cellular baseband processor. The OS of the application processor handles most user interactions and provides the execution environment for apps. The OS of the cellular baseband processor handles communications with the cellular network and may control other peripherals. The term OS, without context, may be assumed to refer to the OS of the - application processor. - - - - A type of authentication factor requiring the - user to provide a secret set of characters to gain access. - A PIN is a set of numeric or alphabetic characters that may be used + application processor. + A type of authentication factor requiring the + user to provide a secret set of characters to gain access. + A PIN is a set of numeric or alphabetic characters that may be used in addition to a biometric factor to provide a hybrid authentication factor. At this time it is not considered as a stand-alone authentication mechanism. A PIN is distinct from a password in that the allowed character set and required length of a PIN - is typically smaller than that of a password as it is designed to be input quickly. - - - The device has been shut down such that no TOE function can be - performed. - - - - - - - Protected data is all non-TSF data, including all user - or enterprise data. Some or all of this data may be considered sensitive data as well. - - A key tied to the device used to encrypt other - keys. - - - - - Sensitive data shall be identified in the TSS section of the + is typically smaller than that of a password as it is designed to be input quickly. + The device has been shut down such that no TOE function can be + performed. + Protected data is all non-TSF data, including all user + or enterprise data. Some or all of this data may be considered sensitive data as well. + A key tied to the device used to encrypt other + keys. + Sensitive data shall be identified in the TSS section of the Security Target (ST) by the ST author. Sensitive data is a subset or all of the Protected data. Sensitive data may include all user or enterprise data or may be specific application data such as emails, messaging, documents, calendar items, and contacts. Sensitive data is - protected while in the locked state (FDP_DAR_EXT.2). - - - The OS access the raw bytes of these keys during runtime. - - - - - - - - - - - A list of trusted root Certificate Authority - certificates. - Data for the operation of the TSF upon which the enforcement of the - requirements relies. - - - The state in which the Mobile Device is not managed. - Powered on and device functionality is available for use. Implies - user authentication has occurred (when so configured). - - - - A task where the biometric system attempts to confirm + protected while in the locked state (FDP_DAR_EXT.2). + The OS access the raw bytes of these keys during runtime. + A list of trusted root Certificate Authority + certificates. + Data for the operation of the TSF upon which the enforcement of the + requirements relies. + The state in which the Mobile Device is not managed. + Powered on and device functionality is available for use. Implies + user authentication has occurred (when so configured). + A task where the biometric system attempts to confirm an individual’s claimed identity by comparing a submitted sample to one or more previously - enrolled authentication templates. - - - - - -
The scope of the Protection Profile within the - development and evaluation process is described in the Common Criteria for Information - Technology Security Evaluation . In particular, a PP defines the IT security - requirements of a generic type of TOE and specifies the functional and assurance security - measures to be offered by that TOE to meet stated requirements .
-
The target audiences of this PP are Mobile - Device developers, CC consumers, evaluators and schemes.
-
This assurance standard specifies information security - requirements for Mobile Devices for use in an enterprise. A Mobile Device in the context of - this assurance standard is a device, which is composed of a hardware platform and its system - software. The device typically provides wireless connectivity - and may include software for functions - like secure messaging, email, web, VPN connection, and VoIP (Voice over IP), for access to the - protected enterprise network, enterprise data and applications, and for communicating to other - Mobile Devices. - illustrates the network operating environment of the Mobile Device. -
- - Examples of a "Mobile Device" that should claim conformance to this Protection - Profile include smartphones, tablet computers, and other Mobile Devices with similar - capabilities. The Mobile Device provides essential services, such as - cryptographic services, data-at-rest protection, and key storage services to support the - secure operation of applications on the device. Additional security features such as security - policy enforcement, application mandatory access control, anti-exploitation features, user - authentication, and software integrity protection are implemented in order to address threats. - This assurance standard describes these essential security services - provided by the Mobile Device and serves as a foundation for a secure mobile architecture. The - wireless connectivity shall be validated against the . If the - mobile device contains Bluetooth functionality (i.e., has Bluetooth hardware), the Bluetooth - connectivity shall be evaluated against the . - As illustrated in , it is expected that a typical deployment would also include either - third-party or bundled components. Whether these components are bundled as part of the Mobile - Device by the manufacturer or developed by a third-party, they must be separately validated - against the related assurance standards such as the PP-Module for MDM Agent, PP-Module for VPN - Client, PP-Module for VVoIP, and cPP-Module for Biometrics. It is the responsibility of the architect of - the overall secure mobile architecture to ensure validation of these components. Additional - applications that may come pre-installed on the Mobile Device that are not validated are - considered to be potentially flawed, but not malicious. Examples include email client and web - browser. -
- -
- - - The Mobile Device may be operated in a number of use cases. - provides use case templates that list those selections, - assignments, and objective requirements that best support the use cases identified by this - Protection Profile. - In addition to providing essential security services, the Mobile Device - includes the necessary security functionality to support configurations for these various use - cases. - Each use case may require additional configuration and applications to achieve the - desired security. - A selection of these use cases is elaborated below. - - Several of the use case templates include objective requirements that are strongly desired for - the indicated use cases. - Readers can expect those requirements to be made mandatory in a - future revision of this protection profile, and industry should aim to include that security - functionality in products in the near-term. - - As of publication of this version of the Protection Profile, meeting the requirements in - is necessary for all use cases. - + enrolled authentication templates. + +
This assurance standard specifies information security requirements for Mobile Devices for use in an enterprise. A Mobile Device in the context of this assurance standard is a device, which is composed of a hardware platform and its system software. The device typically provides wireless connectivity and may include software for functions like secure messaging, email, web, VPN connection, and VoIP (Voice over IP), for access to the protected enterprise network, enterprise data and applications, and for communicating to other Mobile Devices. illustrates the network operating environment of the Mobile Device.
Examples of a "Mobile Device" that should claim conformance to this Protection Profile include smartphones, tablet computers, and other Mobile Devices with similar capabilities. The Mobile Device provides essential services, such as cryptographic services, data-at-rest protection, and key storage services to support the secure operation of applications on the device. Additional security features such as security policy enforcement, application mandatory access control, anti-exploitation features, user authentication, and software integrity protection are implemented in order to address threats. This assurance standard describes these essential security services provided by the Mobile Device and serves as a foundation for a secure mobile architecture. The wireless connectivity shall be validated against the . If the mobile device contains Bluetooth functionality (i.e., has Bluetooth hardware), the Bluetooth connectivity shall be evaluated against the . As illustrated in , it is expected that a typical deployment would also include either third-party or bundled components. Whether these components are bundled as part of the Mobile Device by the manufacturer or developed by a third-party, they must be separately validated against the related assurance standards such as the PP-Module for MDM Agent, PP-Module for VPN Client, PP-Module for VVoIP, and cPP-Module for Biometrics. It is the responsibility of the architect of the overall secure mobile architecture to ensure validation of these components. Additional applications that may come pre-installed on the Mobile Device that are not validated are considered to be potentially flawed, but not malicious. Examples include email client and web browser.
+ + The Mobile Device may be operated in a number of use cases. provides use case templates that list those selections, assignments, and objective requirements that best support the use cases identified by this Protection Profile. In addition to providing essential security services, the Mobile Device includes the necessary security functionality to support configurations for these various use cases. Each use case may require additional configuration and applications to achieve the desired security. A selection of these use cases is elaborated below.Several of the use case templates include objective requirements that are strongly desired for the indicated use cases. Readers can expect those requirements to be made mandatory in a future revision of this protection profile, and industry should aim to include that security functionality in products in the near-term.As of publication of this version of the Protection Profile, meeting the requirements in is necessary for all use cases. - - - An enterprise-owned device for general-purpose business use is commonly - called Corporately Owned, Personally Enabled (COPE). - This use case entails a significant degree of enterprise control over configuration - and, possibly, software inventory. - The enterprise elects to provide users with Mobile Devices and additional applications (such as - VPN or email clients) in order to maintain control of their Enterprise data and security of - their networks. - Users may use Internet connectivity to browse the web or access corporate mail - or run enterprise applications, but this connectivity may be under significant control of the - enterprise. - - - import-user - mf-location - a-serverInclude personal Hotspot connections in the assignment - mf-unlockBanner - s-usbstore - s-tether - fc-ap_med - s-all-exe - fc-crypt-veri - fc-banner - + An enterprise-owned device for general-purpose business use is commonly called Corporately Owned, Personally Enabled (COPE). This use case entails a significant degree of enterprise control over configuration and, possibly, software inventory. The enterprise elects to provide users with Mobile Devices and additional applications (such as VPN or email clients) in order to maintain control of their Enterprise data and security of their networks. Users may use Internet connectivity to browse the web or access corporate mail or run enterprise applications, but this connectivity may be under significant control of the enterprise. - - - - - - An enterprise-owned device with intentionally limited network connectivity, tightly controlled configuration, and limited software inventory is appropriate for specialized, high-security use cases. For example, the device may not be permitted connectivity to any external peripherals. It may only be able to communicate via its Wi-Fi or cellular radios with the enterprise-run network, which may not even permit connectivity to the Internet. Use of the device may entail compliance with policies that are more restrictive than those in any general-purpose use case, yet may mitigate risks to highly sensitive information. As in the previous case, the enterprise will look for additional applications providing enterprise connectivity and services to have a similar level of assurance as the platform. - - - - - a-keygen-rsa-sizeSet to 3072 - - s-rek-syms-rek-256 - s-rek-asyms-rek-128 - - - s-kek-sym-256 - a-kek-asym-size128 - - - - s-keygen-ecc - - s-rek-syms-rek-256 - s-rek-asyms-rek-192 - - - s-kek-sym-256 - a-kek-asym-size128 - - s-tls-secp384 - - - s-locked-ecc-800-56As-locked-rsa - s-encrypt-256 - s-rbg-256 - s-dar-256 - s-revoke-admins-revoke-deny - mf-vpn - a-mf-radiosassign all radios on TSF - a-audiovisual-devsassign all audio or visual collection devices on TSF - mf-dar - mf-location - mf-unenroll - - - - - - - - A personally-owned device that is used for both personal activities and enterprise data is commonly called Bring Your Own Device (BYOD). The device may be provisioned for access to enterprise resources after significant personal usage has occurred. Unlike in the enterprise-owned cases, the enterprise is limited in what security policies it can enforce because the user purchased the device primarily for personal use and is unlikely to accept policies that limit the functionality of the device. However, because the enterprise allows the user full (or nearly full) access to the enterprise network, the enterprise will require their own security controls to ensure that enterprise resources are protected from potential threats posed by the personal activities on the device. These controls could potentially be enforced by a separation mechanism built-in to the device itself to distinguish between enterprise and personal activities, or by a third-party application that provides access to enterprise resources and leverages security capabilities provided by the mobile device. Based upon the operational environment and the acceptable risk level of the enterprise, those security functional requirements outlined in of this PP along with the selections in the Use Case 3 template defined in Appendix F - Use Case Templates are sufficient for the secure implementation of this BYOD use case. - - - s-vpn-per-apps-vpn-per-appgroups-vpn-per-apps-vpn-per-appgroup - s-audiovisual-per-apps-audiovisual-per-appgroups-audiovisual-per-apps-audiovisual-per-appgroup - mf-entAppRemove - mf-wipeEntData - mf-unenroll - s-smf-ext-2-rem-ent-app - fdp_group - fc_access_control_system - - - - - - - - + + An enterprise-owned device with intentionally limited network connectivity, tightly controlled configuration, and limited software inventory is appropriate for specialized, high-security use cases. For example, the device may not be permitted connectivity to any external peripherals. It may only be able to communicate via its Wi-Fi or cellular radios with the enterprise-run network, which may not even permit connectivity to the Internet. Use of the device may entail compliance with policies that are more restrictive than those in any general-purpose use case, yet may mitigate risks to highly sensitive information. As in the previous case, the enterprise will look for additional applications providing enterprise connectivity and services to have a similar level of assurance as the platform. + + + A personally-owned device that is used for both personal activities and enterprise data is commonly called Bring Your Own Device (BYOD). The device may be provisioned for access to enterprise resources after significant personal usage has occurred. Unlike in the enterprise-owned cases, the enterprise is limited in what security policies it can enforce because the user purchased the device primarily for personal use and is unlikely to accept policies that limit the functionality of the device. However, because the enterprise allows the user full (or nearly full) access to the enterprise network, the enterprise will require their own security controls to ensure that enterprise resources are protected from potential threats posed by the personal activities on the device. These controls could potentially be enforced by a separation mechanism built-in to the device itself to distinguish between enterprise and personal activities, or by a third-party application that provides access to enterprise resources and leverages security capabilities provided by the mobile device. Based upon the operational environment and the acceptable risk level of the enterprise, those security functional requirements outlined in of this PP along with the selections in the Use Case 3 template defined in Appendix F - Use Case Templates are sufficient for the secure implementation of this BYOD use case. - - - - A personally-owned device that is used for both personal activities and enterprise data is commonly called Bring Your Own Device (BYOD). This device may be provisioned for limited access to enterprise resources such as enterprise email. Because the user does not have full access to the enterprise or enterprise data, the enterprise may not need to enforce any security policies on the device. However, the enterprise may want secure email and web browsing with assurance that the services being provided to those clients by the Mobile Device are not compromised. Based upon the operational environment and the acceptable risk level of the enterprise, those security functional requirements outlined in Section 5 Security Requirements of this PP are sufficient for the secure implementation of this BYOD use case. - + + A personally-owned device that is used for both personal activities and enterprise data is commonly called Bring Your Own Device (BYOD). This device may be provisioned for limited access to enterprise resources such as enterprise email. Because the user does not have full access to the enterprise or enterprise data, the enterprise may not need to enforce any security policies on the device. However, the enterprise may want secure email and web browsing with assurance that the services being provided to those clients by the Mobile Device are not compromised. Based upon the operational environment and the acceptable risk level of the enterprise, those security functional requirements outlined in Section 5 Security Requirements of this PP are sufficient for the secure implementation of this BYOD use case. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Mobile devices are subject to the threats of traditional - computer systems along with those entailed by their mobile nature. The threats considered in - this PP are those of network eavesdropping, network attacks, physical access, - malicious or flawed applications, persistent presence, and backup - as - detailed in the following sections. + + + + + + + + + + + + + + + + + + + + + + + Mobile devices are subject to the threats of traditional computer systems along with those entailed by their mobile nature. The threats considered in this PP are those of network eavesdropping, network attacks, physical access, malicious or flawed applications, persistent presence, and backup as detailed in the following sections. - - An attacker is positioned on a wireless communications channel or elsewhere - on the network infrastructure. Attackers may monitor and gain access to data exchanged - between the Mobile Device and other endpoints. - - The threat T.NETWORK_EAVESDROP is countered by O.PROTECTED_COMMS as this provides the - capability to communicate using one (or more) standard protocols as a means to - maintain the confidentiality of data that are transmitted outside of the - TOE. + + Applications loaded onto the Mobile Device may include malicious or exploitable code. This code could be included intentionally or unknowingly by the developer, perhaps as part of a software library. Malicious apps may attempt to exfiltrate data to which they have access. They may also conduct attacks against the platform’s system software, which will provide them with additional privileges and the ability to conduct further malicious activities. Malicious applications may be able to control the device's sensors (GPS, camera, microphone) to gather intelligence about the user's surroundings even when those activities do not involve data resident or transmitted from the device. Flawed applications may give an attacker access to perform network-based or physical attacks that otherwise would have been prevented + + The threat T.MALICIOUS_APP is countered by O.AUTH as this provides the capability to authenticate the user and endpoints of a trusted path to ensure they are communicating with an authorized entity with appropriate privileges. - The threat T.NETWORK_EAVESDROP is countered by O.CONFIG as this provides a - secure configuration of the mobile device to protect data that it - processes. + The threat T.MALICIOUS_APP is countered by O.CONFIG as this provides the capability to configure and apply security policies to ensure the Mobile Device can protect user and enterprise data that it may store or process. - - The threat T.NETWORK_EAVESDROP is countered by O.AUTH as this provides - authentication of the endpoints of a trusted communication path. + + The threat T.MALICIOUS_APP is countered by O.INTEGRITY as this provides the capability to perform self-tests to ensure the integrity of critical functionality, software/firmware and data has been maintained. + + + The threat T.MALICIOUS_APP is countered by O.PRIVACY as this provides separation and privacy between user activities. + + + The threat T.MALICIOUS_APP is countered by O.PROTECTED_COMMS as this provides the capability to communicate using one (or more) standard protocols as a means to maintain the confidentiality of data that are transmitted outside of the TOE. - An attacker is positioned on a wireless communications channel or elsewhere - on the network infrastructure. Attackers may initiate communications with the Mobile - Device or alter communications between the Mobile Device and other endpoints in order to - compromise the Mobile Device. These attacks include malicious software update of any - applications or system software on the device. These attacks also include malicious web - pages or email attachments, which are usually delivered to devices over the - network. - - The threat T.NETWORK_ATTACK is countered by O.PROTECTED_COMMS as this provides the - capability to communicate using one (or more) standard protocols as a means to - maintain the confidentiality of data that are transmitted outside of the - TOE. + An attacker is positioned on a wireless communications channel or elsewhere on the network infrastructure. Attackers may initiate communications with the Mobile Device or alter communications between the Mobile Device and other endpoints in order to compromise the Mobile Device. These attacks include malicious software update of any applications or system software on the device. These attacks also include malicious web pages or email attachments, which are usually delivered to devices over the network. + + The threat T.NETWORK_ATTACK is countered by O.AUTH as this provides authentication of the endpoints of a trusted communication path. - The threat T.NETWORK_ATTACK is countered by O.CONFIG as this provides a - secure configuration of the mobile device to protect data that it - processes. + The threat T.NETWORK_ATTACK is countered by O.CONFIG as this provides a secure configuration of the mobile device to protect data that it processes. - - The threat T.NETWORK_ATTACK is countered by O.AUTH as this provides - authentication of the endpoints of a trusted communication path. + + The threat T.NETWORK_ATTACK is countered by O.PROTECTED_COMMS as this provides the capability to communicate using one (or more) standard protocols as a means to maintain the confidentiality of data that are transmitted outside of the TOE. - - An attacker, with physical access, may attempt to access user data on the - Mobile Device including credentials. These physical access threats may involve attacks, - which attempt to access the device through external hardware ports, impersonate the user - authentication mechanisms, through its user interface, and also through direct and - possibly destructive access to its storage media. Note: Defending against device re-use - after physical compromise is out of scope for this Protection Profile. - - The threat T.PHYSICAL_ACCESS is countered by O.STORAGE as this provides the - capability to encrypt all user and enterprise data and authentication keys to ensure - the confidentiality of data that it stores. - + + An attacker is positioned on a wireless communications channel or elsewhere on the network infrastructure. Attackers may monitor and gain access to data exchanged between the Mobile Device and other endpoints. - The threat T.PHYSICAL_ACCESS is countered by O.AUTH as this provides the - capability to authenticate the user prior to accessing protected functionality and - data. - - - - Applications loaded onto the Mobile Device may include malicious or - exploitable code. This code could be included intentionally or unknowingly by the - developer, perhaps as part of a software library. Malicious apps may attempt to - exfiltrate data to which they have access. They may also conduct attacks against the - platform’s system software, which will provide them with additional privileges and the - ability to conduct further malicious activities. Malicious applications may be able to - control the device's sensors (GPS, camera, microphone) to gather intelligence about the - user's surroundings even when those activities do not involve data resident or - transmitted from the device. Flawed applications may give an attacker access to perform - network-based or physical attacks that otherwise would have been prevented - - The threat T.MALICIOUS_APP is countered by O.PROTECTED_COMMS as this provides the - capability to communicate using one (or more) standard protocols as a means to - maintain the confidentiality of data that are transmitted outside of the - TOE. + The threat T.NETWORK_EAVESDROP is countered by O.AUTH as this provides authentication of the endpoints of a trusted communication path. - The threat T.MALICIOUS_APP is countered by O.CONFIG as this provides the - capability to configure and apply security policies to ensure the Mobile Device can - protect user and enterprise data that it may store or process. + The threat T.NETWORK_EAVESDROP is countered by O.CONFIG as this provides a secure configuration of the mobile device to protect data that it processes. - - The threat T.MALICIOUS_APP is countered by O.AUTH as this provides the - capability to authenticate the user and endpoints of a trusted path to ensure they are - communicating with an authorized entity with appropriate privileges. + + The threat T.NETWORK_EAVESDROP is countered by O.PROTECTED_COMMS as this provides the capability to communicate using one (or more) standard protocols as a means to maintain the confidentiality of data that are transmitted outside of the TOE. + + + Persistent presence on a device by an attacker implies that the device has lost integrity and cannot regain it. The device has likely lost this integrity due to some other threat vector, yet the continued access by an attacker constitutes an on-going threat in itself. In this case, the device and its data may be controlled by an adversary as well as by its legitimate owner. - The threat T.MALICIOUS_APP is countered by O.INTEGRITY as this provides the - capability to perform self-tests to ensure the integrity of critical functionality, - software/firmware and data has been maintained. + The threat T.PERSISTENT_PRESENCE is countered by O.INTEGRITY as this provides the capability to perform self-tests to ensure the integrity of critical functionality, software/firmware and data has been maintained. - The threat T.MALICIOUS_APP is countered by O.PRIVACY as this provides - separation and privacy between user activities. + The threat T.PERSISTENT_PRESENCE is countered by O.PRIVACY as this provides separation and privacy between user activities. - - Persistent presence on a device by an attacker implies that the device has - lost integrity and cannot regain it. The device has likely lost this integrity due to - some other threat vector, yet the continued access by an attacker constitutes an - on-going threat in itself. In this case, the device and its data may be controlled by an - adversary as well as by its legitimate owner. - - The threat T.PERSISTENT_PRESENCE is countered by O.INTEGRITY as this provides - the capability to perform self-tests to ensure the integrity of critical - functionality, software/firmware and data has been maintained. + + An attacker, with physical access, may attempt to access user data on the Mobile Device including credentials. These physical access threats may involve attacks, which attempt to access the device through external hardware ports, impersonate the user authentication mechanisms, through its user interface, and also through direct and possibly destructive access to its storage media. Note: Defending against device re-use after physical compromise is out of scope for this Protection Profile. + + The threat T.PHYSICAL_ACCESS is countered by O.AUTH as this provides the capability to authenticate the user prior to accessing protected functionality and data. - - The threat T.PERSISTENT_PRESENCE is countered by O.PRIVACY as this provides - separation and privacy between user activities. + + The threat T.PHYSICAL_ACCESS is countered by O.STORAGE as this provides the capability to encrypt all user and enterprise data and authentication keys to ensure the confidentiality of data that it stores. -
-
The specific conditions listed below are assumed to - exist in the TOE’s Operational Environment. These include both practical realities in the - development of the TOE security requirements and the essential environmental conditions on the - use of the TOE. + + + - It is assumed that the TOE’s security functions are configured correctly in a - manner to ensure that the TOE security policies will be enforced on all applicable - network traffic flowing among the attached networks. + It is assumed that the TOE’s security functions are configured correctly in a manner to ensure that the TOE security policies will be enforced on all applicable network traffic flowing among the attached networks. The operational environment objective OE.CONFIG is realized through A.CONFIG. - It is assumed that the mobile user will immediately notify the administrator - if the Mobile Device is lost or stolen. + It is assumed that the mobile user will immediately notify the administrator if the Mobile Device is lost or stolen. The operational environment objective OE.NOTIFY is realized through A.NOTIFY. - It is assumed that the mobile user exercises precautions to reduce the risk - of loss or theft of the Mobile Device. + It is assumed that the mobile user exercises precautions to reduce the risk of loss or theft of the Mobile Device. The operational environment objective OE.PRECAUTION is realized through A.PRECAUTION. - - Mobile Device users are not willfully negligent or hostile, and use the - device within compliance of a reasonable Enterprise security policy. + Mobile Device users are not willfully negligent or hostile, and use the device within compliance of a reasonable Enterprise security policy. The operational environment objective OE.DATA_PROPER_USER is realized through A.PROPER_USER. -
- + + + - - - -
+ + + + + + + - - To address the network eavesdropping (T.NETWORK_EAVESDROP) and network attack - (T.NETWORK_ATTACK) threats described in , concerning wireless - transmission of Enterprise and user data and configuration data between the TOE and - remote network entities, conformant TOEs will use a trusted communication path. The TOE - must be capable of communicating using mutually authenticated TLS, EAP-TLS, HTTPS, 802.1X, and 802.11-2012. The TOE may optionally communicate using these standard protocols: IPsec, - mutually-authenticated DTLS, or Bluetooth. These protocols are specified by RFCs that offer a variety - of implementation choices. Requirements have been imposed on some of these choices - (particularly those for cryptographic primitives) to provide interoperability and - resistance to cryptographic attack. - While conformant TOEs must - support all of the choices specified in the ST including any optional SFRs defined in - this PP, they may support additional algorithms and protocols. If such additional - mechanisms are not evaluated, guidance must be given to the administrator to make clear - the fact that they were not evaluated. - FCS_CKM.1 - FCS_CKM.1 supports the objective by defining the key generation algorithms that are used for protected communications. - - FCS_CKM.2/UNLOCKED - FCS_CKM.2/UNLOCKED supports the objective by defining the key establishment algorithms that are used for protected communications. - - FCS_COP.1/ENCRYPT - - FCS_COP.1/ENCRYPT supports the objective by requiring the TSF to implement symmetric encryption algorithms that are used in support of protected communications. - - FCS_COP.1/HASH - - FCS_COP.1/HASH supports the objective by requiring the TSF to implement hash algorithms that are used in support of protected communications. - - FCS_COP.1/SIGN - - FCS_COP.1/SIGN supports the objective by requiring the TSF to implement digital signature algorithms that are used in support of protected communications. - - FCS_COP.1/KEYHMAC - - FCS_COP.1/KEYHMAC supports the objective by requiring the TSF to implement HMAC algorithms that are used in support of protected communications. - - FCS_DTLSC_EXT.1 (TLS Package) - - FCS_DTLSC_EXT.1 supports the objective by defining the TOE's implementation of DTLS as a client if this protocol is used for protected communications. - - FCS_DTLSC_EXT.2 (TLS Package) - - FCS_DTLSC_EXT.2 supports the objective by defining the TOE's implementation of mutually-authenticated DTLS as a client if this protocol is used for protected communications. - - FCS_HTTPS_EXT.1 - - FCS_HTTPS_EXT.1 supports the objective by defining the TOE's implementation of HTTPS if this protocol is used for protected communications. - - FCS_RBG_EXT.1 - - FCS_RBG_EXT.1 supports the objective by requiring the TSF to implement deterministic random bit generation algorithms that are used in support of protected communications. - - FCS_RBG_EXT.2 (Objective) - - FCS_RBG_EXT.2 supports the objective by requiring the TSF to save the DRBG state between reboots to ensure availability of this service. - - - FCS_RBG_EXT.3 (Objective) - - FCS_RBG_EXT.3 supports the objective by defining the TSF's implementation of the SP 800-90A Personalization String for applications that require this. - - FCS_SRV_EXT.1 - - FCS_SRV_EXT.1 supports the objective by defining the cryptographic services that the TSF must make available to third-party applications, which includes those that can support protected communications. - - FCS_SRV_EXT.2 (Objective) - - FCS_SRV_EXT.2 supports the objective by requiring the TSF to make keys in its secure key storage available for use in encryption and signing operations. - - FCS_TLSC_EXT.1 (TLS Package) - - FCS_TLSC_EXT.1 supports the objective by defining the TOE's implementation of TLS as a client for protected communications. - - FCS_TLSC_EXT.2 (TLS Package) - - FCS_TLSC_EXT.2 supports the objective by defining the TOE's implementation of mutually-authenticated TLS as a client for protected communications. - - FCS_TLSC_EXT.3 (TLS Package) - - FCS_TLSC_EXT.3 supports the objective by requiring the TSF to support the TLS signature algorithms extension as part of establishing TLS protected communications. - - FDP_BLT_EXT.1 (Objective) - - FDP_BLT_EXT.1 supports the objective by limiting the applications that are authorized to use the Bluetooth interface, which may include a trusted channel. - - FDP_IFC_EXT.1 - - FDP_IFC_EXT.1 supports the objective by requiring the TSF to have either its own IPsec VPN client or interface that allows a third-party VPN client to be deployed on it. - - FDP_STG_EXT.1 - - FDP_STG_EXT.1 supports the objective by requiring the TSF to implement a protected key storage that can be used to protect persistent keys used for protected communications from disclosure. - - FDP_UPC_EXT.1/APPS - - FDP_UPC_EXT.1/APPS supports the objective by defining the protected communications channels that it allows third-party applications to invoke. - - FDP_UPC_EXT.1/BLUETOOTH - - FDP_UPC_EXT.1/BLUETOOTH supports the objective by defining the Bluetooth interfaces that it allows third-party applications to invoke. - - - FIA_X509_EXT.1 - - FIA_X509_EXT.1 supports the objective by defining the rules the TSF uses to determine if a presented X.509 certificate is valid. - - FIA_X509_EXT.2 - - FIA_X509_EXT.2 supports the objective by requiring the TSF to enumerate its uses of X.509 certificates (including protected communications) and its behavior when a certificate's revocation status is undetermined. - - FIA_X509_EXT.3 - - FIA_X509_EXT.3 supports the objective by requiring the TSF to provide a certificate validation service to third-party applications. - - FIA_X509_EXT.4 (Objective) - - FIA_X509_EXT.4 supports the objective by defining the implementation of EST as a method by which the TSF can obtain an X.509 certificate for its own use. - - FIA_X509_EXT.5 (Objective) - - FIA_X509_EXT.5 supports the objective by defining the implementation of Certificate Request Messages as a method by which the TSF can obtain an X.509 certificate for its own use. - - FPT_BLT_EXT.1 (Objective) - - FPT_BLT_EXT.1 supports the objective by requiring the TSF to disable certain Bluetooth profiles when they are inactive such that explicit user authorization is required to re-enable them. - - - FTP_ITC_EXT.1 - - FTP_ITC_EXT.1 supports the objective by defining the protected communications protocols that the TSF implements. - + + To address the issue of loss of confidentiality of user data in the event of loss of a Mobile Device (T.PHYSICAL_ACCESS), users are required to enter an authentication factor to the device prior to accessing protected functionality and data. Some non-sensitive functionality (e.g., emergency calling, text notification) can be accessed prior to entering the authentication factor. The device will automatically lock following a configured period of inactivity in an attempt to ensure authorization will be required in the event of the device being lost or stolen. Authentication of the endpoints of a trusted communication path is required for network access to ensure attacks are unable to establish unauthorized network connections to undermine the integrity of the device. Repeated attempts by a user to authorize to the TSF will be limited or throttled to enforce a delay between unsuccessful attempts. + FIA_AFL_EXT.1 + FIA_AFL_EXT.1 supports the objective by defining the authentication mechanisms that are subject to lockout behavior and how the TSF handles repeated failed authentication attempts. + FIA_PMG_EXT.1 + FIA_PMG_EXT.1 supports the objective by defining the minimum quality threshold for passwords that the TSF must enforce. + FIA_TRT_EXT.1 + FIA_TRT_EXT.1 supports the objective by enforcing an authentication throttling mechanism that limits the rate at which authentication attempts can be made to the TOE. + FIA_UAU.5 + FIA_UAU.5 supports the objective by defining all authentication factors the TSF supports and rules for how these authentication factors are used to gain access to the TSF. + FIA_UAU.6/CREDENTIAL + FIA_UAU.6/CREDENTIAL supports the objective by requiring the TSF to re-authenticate users with their password prior to allowing them to change any other authentication data. + FIA_UAU.6/LOCKED + FIA_UAU.6/LOCKED supports the objective by requiring the TSF to re-authenticate users with a valid credential prior to allowing a locked device to be unlocked. + FIA_UAU.7 + FIA_UAU.7 supports the objective by ensuring that TSF does not disclose user authentication data as it is being input to the TOE. + FIA_UAU_EXT.1 + FIA_UAU_EXT.1 supports the objective by requiring the TSF to be provided with a valid password before access to protected data is granted. + FIA_UAU_EXT.2 + FIA_UAU_EXT.2 supports the objective by defining the TOE functions that can be accessed without authentication such that all other services require authentication. + FIA_UAU_EXT.4 + FIA_UAU_EXT.4 supports the objective by defining a secondary authentication mechanism for Enterprise resources. + FIA_X509_EXT.2 + FIA_X509_EXT.2 supports the objective by defining the functions for which the TSF uses X.509 certificates as an authentication mechanism. + FTA_SSL_EXT.1 + FTA_SSL_EXT.1 supports the objective by requiring the TSF to ensure that an idle user session is terminated after a given period of time. - - To address the issue of loss of confidentiality of user data in the event of - loss of a Mobile Device (T.PHYSICAL_ACCESS), conformant TOEs will use data-at-rest protection. - The TOE will be capable of encrypting data and keys stored on the device and will - prevent unauthorized access to encrypted data. - FCS_CKM.2/LOCKED - - FCS_CKM.2/LOCKED supports the objective by defining the key establishment mechanism used for keys that protect data at rest when the TOE is in a locked state. - - FCS_CKM_EXT.1 - - FCS_CKM_EXT.1 supports the objective by defining the TOE's root encryption key that is used to protect data at rest. - - FCS_CKM_EXT.2 - - FCS_CKM_EXT.2 supports the objective by defining how the TSF creates data encryption keys that are used to protect data at rest. - - FCS_CKM_EXT.3 - - FCS_CKM_EXT.3 supports the objective by defining the key encryption keys the TOE uses to protect data at rest and how they are created. - - FCS_CKM_EXT.4 - - FCS_CKM_EXT.4 supports the objective by requiring the TSF to destroy keys and key material that could otherwise be used to compromise data at rest. - - FCS_CKM_EXT.5 - - FCS_CKM_EXT.5 supports the objective by defining the mechanism the TSF uses to perform a wipe operation that securely destroys data at rest. - - FCS_CKM_EXT.6 - - FCS_CKM_EXT.6 supports the objective by requiring the TSF to use secure salts when performing cryptographic operations that require them. - - FCS_CKM_EXT.7 (Sel-Based) - - FCS_CKM_EXT.7 supports the objective by ensuring that the TOE's root encryption key cannot be disclosed. - - FCS_COP.1/ENCRYPT - - FCS_COP.1/ENCRYPT supports the objective by defining a symmetric encryption/decryption function that can be used to protect data at rest. - - FCS_COP.1/HASH - - FCS_COP.1/HASH supports the objective by defining a hash function that can be used to protect data at rest. - - FCS_COP.1/SIGN - - FCS_COP.1/SIGN supports the objective by defining a digital signature function that can be used to protect data at rest. - - FCS_COP.1/KEYHMAC - - FCS_COP.1/KEYHMAC supports the objective by defining an HMAC function that can be used to protect data at rest. - - FCS_COP.1/CONDITION - - FCS_COP.1/CONDITION supports the objective by defining a key derivation function that can be used to protect data at rest. - - FCS_IV_EXT.1 - - FCS_IV_EXT.1 supports the objective by ensuring that any IVs the TSF generates for AES keys are generated in an appropriate manner based on the relevant standards. - - FCS_RBG_EXT.1 - - FCS_RBG_EXT.1 supports the objective by defining random bit generation function that can be used to protect data at rest. - - FCS_STG_EXT.1 - - FCS_STG_EXT.1 supports the objective by requiring the TSF to implement a hardware or software key store to protect key data at rest. - - FCS_STG_EXT.2 - - FCS_STG_EXT.2 supports the objective by defining the confidentiality mechanism used to protect stored key data from unauthorized disclosure. - - FCS_STG_EXT.3 - - FCS_STG_EXT.3 supports the objective by defining the integrity mechanism used to protect stored key data from unauthorized modification. - - FDP_ACF_EXT.3 (Objective) - - FDP_ACF_EXT.3 supports the objective by ensuring that the TSF does not permit write and execute permissions on stored data to be granted simultaneously. - - FDP_DAR_EXT.1 - - FDP_DAR_EXT.1 supports the objective by requiring the TSF to encrypt all sensitive data using data encryption keys. - - FDP_DAR_EXT.2 - - FDP_DAR_EXT.2 supports the objective by requiring the TSF to provide a mechanism to mark data as sensitive so that it can be subject to encryption. - - FIA_UAU_EXT.1 - - FIA_UAU_EXT.1 supports the objective by requiring the presentation of a valid authorization factor in order to decrypt sensitive data at rest. - - FPT_KST_EXT.1 - - FPT_KST_EXT.1 supports the objective by requiring the TSF to prevent the storage of plaintext key data in readable non-volatile memory. - - FPT_KST_EXT.2 - - FPT_KST_EXT.2 supports the objective by requiring the TSF to prevent any transmission of plaintext key material outside of the TOE boundary. - - FPT_KST_EXT.3 - - FPT_KST_EXT.3 supports the objective by requiring the TSF to prevent export of any stored plaintext keys. - - FPT_JTA_EXT.1 - FPT_JTA_EXT.1 supports the objective by requiring the TSF to enforce access controls against JTAG so that this interface cannot be used to disclose data at rest. - - - To ensure a Mobile Device protects user and enterprise data that it may - store or process, conformant TOEs will provide the capability to configure and apply - security policies defined by the user and the Enterprise Administrator. If Enterprise - security policies are configured these must be applied in precedence of user specified - security policies. - FMT_MOF_EXT.1 - - FMT_MOF_EXT.1 supports the objective by specifying the TSF management functions that an end user is authorized to perform. - - FMT_SMF.1 - - FMT_SMF.1 supports the objective by defining the TSF management functions and the users or roles that are authorized to invoke them. - - FMT_SMF_EXT.2 - - FMT_SMF_EXT.2 supports the objective by defining the configuration actions that the TSF performs automatically upon unenrollment from mobile device management. - - FTA_TAB.1 - - FTA_TAB.1 supports the objective by requiring the TSF to display a warning banner to users that governs authorized usage of the TOE. - - - - To address the issue of loss of confidentiality of user data in the event of - loss of a Mobile Device (T.PHYSICAL_ACCESS), users are required to enter an authentication - factor to the device prior to accessing protected functionality and data. Some - non-sensitive functionality (e.g., emergency calling, text notification) can be accessed - prior to entering the authentication factor. The device will automatically lock - following a configured period of inactivity in an attempt to ensure authorization will - be required in the event of the device being lost or stolen. - - Authentication of the endpoints of a trusted communication path is required for network - access to ensure attacks are unable to establish unauthorized network connections to - undermine the integrity of the device. - - Repeated attempts by a user to - authorize to the TSF will be limited or throttled to enforce a delay between - unsuccessful attempts. - - - FIA_AFL_EXT.1 - - FIA_AFL_EXT.1 supports the objective by defining the authentication mechanisms that are subject to lockout behavior and how the TSF handles repeated failed authentication attempts. - - - - FIA_PMG_EXT.1 - - FIA_PMG_EXT.1 supports the objective by defining the minimum quality threshold for passwords that the TSF must enforce. - - FIA_TRT_EXT.1 - - FIA_TRT_EXT.1 supports the objective by enforcing an authentication throttling mechanism that limits the rate at which authentication attempts can be made to the TOE. - - FIA_UAU_EXT.1 - - FIA_UAU_EXT.1 supports the objective by requiring the TSF to be provided with a valid password before access to protected data is granted. - - FIA_UAU_EXT.2 - - FIA_UAU_EXT.2 supports the objective by defining the TOE functions that can be accessed without authentication such that all other services require authentication. - - FIA_UAU_EXT.4 (Optional) - - FIA_UAU_EXT.4 supports the objective by defining a secondary authentication mechanism for Enterprise resources. - - FIA_UAU.5 - - FIA_UAU.5 supports the objective by defining all authentication factors the TSF supports and rules for how these authentication factors are used to gain access to the TSF. - - FIA_UAU.6/CREDENTIAL - - FIA_UAU.6/CREDENTIAL supports the objective by requiring the TSF to re-authenticate users with their password prior to allowing them to change any other authentication data. - - FIA_UAU.6/LOCKED - - FIA_UAU.6/LOCKED supports the objective by requiring the TSF to re-authenticate users with a valid credential prior to allowing a locked device to be unlocked. - - FIA_UAU.7 - - FIA_UAU.7 supports the objective by ensuring that TSF does not disclose user authentication data as it is being input to the TOE. - - FIA_X509_EXT.2 - - FIA_X509_EXT.2 supports the objective by defining the functions for which the TSF uses X.509 certificates as an authentication mechanism. - - FTA_SSL_EXT.1 - - FTA_SSL_EXT.1 supports the objective by requiring the TSF to ensure that an idle user session is terminated after a given period of time. - - + To ensure a Mobile Device protects user and enterprise data that it may store or process, conformant TOEs will provide the capability to configure and apply security policies defined by the user and the Enterprise Administrator. If Enterprise security policies are configured these must be applied in precedence of user specified security policies. + FMT_MOF_EXT.1 + FMT_MOF_EXT.1 supports the objective by specifying the TSF management functions that an end user is authorized to perform. + FMT_SMF.1 + FMT_SMF.1 supports the objective by defining the TSF management functions and the users or roles that are authorized to invoke them. + FMT_SMF_EXT.2 + FMT_SMF_EXT.2 supports the objective by defining the configuration actions that the TSF performs automatically upon unenrollment from mobile device management. + FTA_TAB.1 + FTA_TAB.1 supports the objective by requiring the TSF to display a warning banner to users that governs authorized usage of the TOE. + - To ensure the integrity of the Mobile Device is maintained conformant TOEs - will perform self-tests to ensure the integrity of critical functionality, - software/firmware and data has been maintained. The user shall be notified of any - failure of these self-tests. This will protect against the threat T.PERSISTENT. - To address the issue of an application containing malicious or flawed - code (T.MALICIOUS_APP), the integrity of downloaded updates to software/firmware will be - verified prior to installation/execution of the object on the Mobile Device. In - addition, the TOE will restrict applications to only have access to the system services - and data they are permitted to interact with. The TOE will further protect against - malicious applications from gaining access to data they are not authorized to access by - randomizing the memory layout. - FAU_GEN.1 - - FAU_GEN.1 supports the objective by requiring the TSF to record actions performed against it to establish a record of potential malicious activity. - - FAU_SAR.1 - - FAU_SAR.1 supports the objective by requiring the TSF to provide a mechanism to review the stored audit data so administrators can diagnose the root cause of malicious usage. - - FAU_SEL.1 (Objective) - - FAU_SEL.1 supports the objective by allowing the TSF to restrict the audit records that are generated so that records unrelated to potential malicious usage can be suppressed. - - FAU_STG.1 - - FAU_STG.1 supports the objective by ensuring that a malicious user cannot tamper with audit records by modifying or deleting them. - - FAU_STG.4 - - FAU_STG.4 supports the objective by ensuring the availability of audit records. - - FCS_COP.1/HASH - - FCS_COP.1/HASH supports the objective by requiring the TSF to implement hash algorithms that can be used to assert and verify integrity. - - FCS_COP.1/SIGN - - FCS_COP.1/SIGN supports the objective by requiring the TSF to implement digital signature algorithms that can be used to assert and verify integrity. - - FDP_ACF_EXT.1 - - FDP_ACF_EXT.1 supports the objective by requiring the TSF to maintain the integrity of its system services by limiting the entities that can access them. - - FDP_ACF_EXT.3 (Objective) - - FDP_ACF_EXT.3 supports the objective by requiring the TSF to ensure that writable files cannot be executed and vice versa, such that arbitrary code or scripts cannot be executed to compromise the integrity of the TOE. - - FPT_AEX_EXT.1 - - FPT_AEX_EXT.1 supports the objective by requiring the TSF to implement ASLR to prevent a compromise of the TSF. - - FPT_AEX_EXT.2 - - FPT_AEX_EXT.2 supports the objective by requiring the TSF to enforce permissions against memory pages to prevent a compromise of the TSF. - - FPT_AEX_EXT.3 - - FPT_AEX_EXT.3 supports the objective by requiring the TSF to implement stack overflow protection to prevent a compromise of the TSF. - - FPT_AEX_EXT.4 - - FPT_AEX_EXT.4 supports the objective by requiring the TSF to enforce address space separation to prevent a compromise of the TSF. - - FPT_AEX_EXT.5 (Objective) - - FPT_AEX_EXT.5 supports the objective by requiring the TSF to implement ASLR to prevent a compromise of the TSF. - - FPT_AEX_EXT.6 (Objective) - - FPT_AEX_EXT.6 supports the objective by requiring the TSF to ensure that writable files cannot be executed and vice versa, such that arbitrary code or scripts cannot be executed to compromise the integrity of the TOE. - - FPT_AEX_EXT.7 (Objective) - - FPT_AEX_EXT.7 supports the objective by requiring the TSF to implement heap overflow protection to prevent a compromise of the TSF. - - FPT_BBD_EXT.1 (Objective) - - FPT_BBD_EXT.1 supports the objective by ensuring that isolation between the TOE's baseband processor and application processor is enforced so that access to the baseband processor is strictly controlled. - - FPT_NOT_EXT.1 - - FPT_NOT_EXT.1 supports the objective by requiring the TSF to take some action to prevent its integrity in the event of various failure conditions. - - FPT_NOT_EXT.2 (Objective) - - FPT_NOT_EXT.2 supports the objective by requiring the TSF to make its integrity verification values available for the purpose of remote attestation. - - FPT_STM.1 - - FPT_STM.1 supports the objective by ensuring accurate system time data is applied to audit logs. - - FPT_TST_EXT.1 - - FPT_TST_EXT.1 supports the objective by defining the self-tests that the TSF performs to validate its own integrity. - - FPT_TST_EXT.2/PREKERNEL - - FPT_TST_EXT.2/PREKERNEL supports the objective by requiring the TSF to verify the integrity of its bootchain prior to kernel load. - - FPT_TST_EXT.2/POSTKERNEL (Objective) - - FPT_TST_EXT.2/POSTKERNEL supports the objective by requiring the TSF to verify the integrity of stored executable code prior to its execution. - - FPT_TST_EXT.3 (Sel-Based) - - FPT_TST_EXT.3 supports the objective by requiring the TSF to block code execution if its code signing certificate is invalid. - - FPT_TUD_EXT.1 - - FPT_TUD_EXT.1 supports the objective by allowing users to determine the version of the TOE's hardware, software/firmware, and installed applications. - - FPT_TUD_EXT.2 - - FPT_TUD_EXT.2 supports the objective by requiring the TSF to validate the integrity of software updates prior to installing them. - - FPT_TUD_EXT.3 - - FPT_TUD_EXT.3 supports the objective by requiring the TSF to validate the integrity of third-party applications prior to installing them. - - FPT_TUD_EXT.4 (Sel-Based) - - FPT_TUD_EXT.4 supports the objective by requiring the TSF to block installation of code if its associated code signing certificate is invalid. - - FPT_TUD_EXT.5 (Objective) - - FPT_TUD_EXT.5 supports the objective by specifying the X.509 certificate that the TSF uses to verify applications prior to their installation. - - FPT_TUD_EXT.6 (Objective) - - - FPT_TUD_EXT.6 supports the objective by preventing the TSF from being rolled back to an earlier version that may have known vulnerabilities that were subsequently patched. - - + To ensure the integrity of the Mobile Device is maintained conformant TOEs will perform self-tests to ensure the integrity of critical functionality, software/firmware and data has been maintained. The user shall be notified of any failure of these self-tests. This will protect against the threat T.PERSISTENT. To address the issue of an application containing malicious or flawed code (T.MALICIOUS_APP), the integrity of downloaded updates to software/firmware will be verified prior to installation/execution of the object on the Mobile Device. In addition, the TOE will restrict applications to only have access to the system services and data they are permitted to interact with. The TOE will further protect against malicious applications from gaining access to data they are not authorized to access by randomizing the memory layout. + FAU_GEN.1 + FAU_GEN.1 supports the objective by requiring the TSF to record actions performed against it to establish a record of potential malicious activity. + FAU_SAR.1 + FAU_SAR.1 supports the objective by requiring the TSF to provide a mechanism to review the stored audit data so administrators can diagnose the root cause of malicious usage. + FAU_SEL.1 + FAU_SEL.1 supports the objective by allowing the TSF to restrict the audit records that are generated so that records unrelated to potential malicious usage can be suppressed. + FAU_STG.1 + FAU_STG.1 supports the objective by ensuring that a malicious user cannot tamper with audit records by modifying or deleting them. + FAU_STG.4 + FAU_STG.4 supports the objective by ensuring the availability of audit records. + FCS_COP.1/HASH + FCS_COP.1/HASH supports the objective by requiring the TSF to implement hash algorithms that can be used to assert and verify integrity. + FCS_COP.1/SIGN + FCS_COP.1/SIGN supports the objective by requiring the TSF to implement digital signature algorithms that can be used to assert and verify integrity. + FDP_ACF_EXT.1 + FDP_ACF_EXT.1 supports the objective by requiring the TSF to maintain the integrity of its system services by limiting the entities that can access them. + FDP_ACF_EXT.3 + FDP_ACF_EXT.3 supports the objective by requiring the TSF to ensure that writable files cannot be executed and vice versa, such that arbitrary code or scripts cannot be executed to compromise the integrity of the TOE. + FPT_AEX_EXT.1 + FPT_AEX_EXT.1 supports the objective by requiring the TSF to implement ASLR to prevent a compromise of the TSF. + FPT_AEX_EXT.2 + FPT_AEX_EXT.2 supports the objective by requiring the TSF to enforce permissions against memory pages to prevent a compromise of the TSF. + FPT_AEX_EXT.3 + FPT_AEX_EXT.3 supports the objective by requiring the TSF to implement stack overflow protection to prevent a compromise of the TSF. + FPT_AEX_EXT.4 + FPT_AEX_EXT.4 supports the objective by requiring the TSF to enforce address space separation to prevent a compromise of the TSF. + FPT_AEX_EXT.5 + FPT_AEX_EXT.5 supports the objective by requiring the TSF to implement ASLR to prevent a compromise of the TSF. + FPT_AEX_EXT.6 + FPT_AEX_EXT.6 supports the objective by requiring the TSF to ensure that writable files cannot be executed and vice versa, such that arbitrary code or scripts cannot be executed to compromise the integrity of the TOE. + FPT_AEX_EXT.7 + FPT_AEX_EXT.7 supports the objective by requiring the TSF to implement heap overflow protection to prevent a compromise of the TSF. + FPT_BBD_EXT.1 + FPT_BBD_EXT.1 supports the objective by ensuring that isolation between the TOE's baseband processor and application processor is enforced so that access to the baseband processor is strictly controlled. + FPT_NOT_EXT.1 + FPT_NOT_EXT.1 supports the objective by requiring the TSF to take some action to prevent its integrity in the event of various failure conditions. + FPT_NOT_EXT.2 + FPT_NOT_EXT.2 supports the objective by requiring the TSF to make its integrity verification values available for the purpose of remote attestation. + FPT_STM.1 + FPT_STM.1 supports the objective by ensuring accurate system time data is applied to audit logs. + FPT_TST_EXT.1 + FPT_TST_EXT.1 supports the objective by defining the self-tests that the TSF performs to validate its own integrity. + FPT_TST_EXT.2/POSTKERNEL + FPT_TST_EXT.2/POSTKERNEL supports the objective by requiring the TSF to verify the integrity of stored executable code prior to its execution. + FPT_TST_EXT.2/PREKERNEL + FPT_TST_EXT.2/PREKERNEL supports the objective by requiring the TSF to verify the integrity of its bootchain prior to kernel load. + FPT_TST_EXT.3 + FPT_TST_EXT.3 supports the objective by requiring the TSF to block code execution if its code signing certificate is invalid. + FPT_TUD_EXT.1 + FPT_TUD_EXT.1 supports the objective by allowing users to determine the version of the TOE's hardware, software/firmware, and installed applications. + FPT_TUD_EXT.2 + FPT_TUD_EXT.2 supports the objective by requiring the TSF to validate the integrity of software updates prior to installing them. + FPT_TUD_EXT.3 + FPT_TUD_EXT.3 supports the objective by requiring the TSF to validate the integrity of third-party applications prior to installing them. + FPT_TUD_EXT.4 + FPT_TUD_EXT.4 supports the objective by requiring the TSF to block installation of code if its associated code signing certificate is invalid. + FPT_TUD_EXT.5 + FPT_TUD_EXT.5 supports the objective by specifying the X.509 certificate that the TSF uses to verify applications prior to their installation. + FPT_TUD_EXT.6 + FPT_TUD_EXT.6 supports the objective by preventing the TSF from being rolled back to an earlier version that may have known vulnerabilities that were subsequently patched. + - In a BYOD environment (use cases 3 and 4), a personally-owned mobile device - is used for both personal activities and enterprise data. Enterprise management - solutions may have the technical capability to monitor and enforce security policies on - the device. However, the privacy of the personal activities and data must be ensured. In - addition, since there are limited controls that the enterprise can enforce on the - personal side, separation of personal and enterprise data is needed. This will protect - against the T.MALICIOUS_APP and T.PERSISTENT_PRESENCE threats. - FDP_ACF_EXT.1 - - FDP_ACF_EXT.1 supports the objective by enforcing restrictions on services that could compromise user privacy if accessed inappropriately. - - FDP_ACF_EXT.2 (Sel-Based) - - FDP_ACF_EXT.2 supports the objective by requiring the TSF to provide separate user data stores for application groups so that the privacy of that data can be maintained. - - FDP_BCK_EXT.1 (Objective) - - FDP_BCK_EXT.1 supports the objective by allowing data to be excluded from backup operations that could compromise user privacy if disclosed. - - FMT_SMF.1 - - FMT_SMF.1 supports the objective by requiring the TSF to implement management functions that control the extent to which user data is collected and disseminated. - - FMT_SMF_EXT.3 (Objective) - - FMT_SMF_EXT.3 supports the objective by requiring the TSF to identify its authorized administrators so that a user knows the extent to which various administrators have access to the device. - - + In a BYOD environment (use cases 3 and 4), a personally-owned mobile device is used for both personal activities and enterprise data. Enterprise management solutions may have the technical capability to monitor and enforce security policies on the device. However, the privacy of the personal activities and data must be ensured. In addition, since there are limited controls that the enterprise can enforce on the personal side, separation of personal and enterprise data is needed. This will protect against the T.MALICIOUS_APP and T.PERSISTENT_PRESENCE threats. + FDP_ACF_EXT.1 + FDP_ACF_EXT.1 supports the objective by enforcing restrictions on services that could compromise user privacy if accessed inappropriately. + FDP_ACF_EXT.2 + FDP_ACF_EXT.2 supports the objective by requiring the TSF to provide separate user data stores for application groups so that the privacy of that data can be maintained. + FDP_BCK_EXT.1 + FDP_BCK_EXT.1 supports the objective by allowing data to be excluded from backup operations that could compromise user privacy if disclosed. + FMT_SMF.1 + FMT_SMF.1 supports the objective by requiring the TSF to implement management functions that control the extent to which user data is collected and disseminated. + FMT_SMF_EXT.3 + FMT_SMF_EXT.3 supports the objective by requiring the TSF to identify its authorized administrators so that a user knows the extent to which various administrators have access to the device. + + + To address the network eavesdropping (T.NETWORK_EAVESDROP) and network attack (T.NETWORK_ATTACK) threats described in , concerning wireless transmission of Enterprise and user data and configuration data between the TOE and remote network entities, conformant TOEs will use a trusted communication path. The TOE must be capable of communicating using mutually authenticated TLS, EAP-TLS, HTTPS, 802.1X, and 802.11-2012. The TOE may optionally communicate using these standard protocols: IPsec, mutually-authenticated DTLS, or Bluetooth. These protocols are specified by RFCs that offer a variety of implementation choices. Requirements have been imposed on some of these choices (particularly those for cryptographic primitives) to provide interoperability and resistance to cryptographic attack. While conformant TOEs must support all of the choices specified in the ST including any optional SFRs defined in this PP, they may support additional algorithms and protocols. If such additional mechanisms are not evaluated, guidance must be given to the administrator to make clear the fact that they were not evaluated. + FCS_CKM.1 + FCS_CKM.1 supports the objective by defining the key generation algorithms that are used for protected communications. + FCS_CKM.2/UNLOCKED + FCS_CKM.2/UNLOCKED supports the objective by defining the key establishment algorithms that are used for protected communications. + FCS_COP.1/ENCRYPT + FCS_COP.1/ENCRYPT supports the objective by requiring the TSF to implement symmetric encryption algorithms that are used in support of protected communications. + FCS_COP.1/HASH + FCS_COP.1/HASH supports the objective by requiring the TSF to implement hash algorithms that are used in support of protected communications. + FCS_COP.1/KEYHMAC + FCS_COP.1/KEYHMAC supports the objective by requiring the TSF to implement HMAC algorithms that are used in support of protected communications. + FCS_COP.1/SIGN + FCS_COP.1/SIGN supports the objective by requiring the TSF to implement digital signature algorithms that are used in support of protected communications. + FCS_HTTPS_EXT.1 + FCS_HTTPS_EXT.1 supports the objective by defining the TOE's implementation of HTTPS if this protocol is used for protected communications. + FCS_RBG_EXT.1 + FCS_RBG_EXT.1 supports the objective by requiring the TSF to implement deterministic random bit generation algorithms that are used in support of protected communications. + FCS_RBG_EXT.2 + FCS_RBG_EXT.2 supports the objective by requiring the TSF to save the DRBG state between reboots to ensure availability of this service. + FCS_RBG_EXT.3 + FCS_RBG_EXT.3 supports the objective by defining the TSF's implementation of the SP 800-90A Personalization String for applications that require this. + FCS_SRV_EXT.1 + FCS_SRV_EXT.1 supports the objective by defining the cryptographic services that the TSF must make available to third-party applications, which includes those that can support protected communications. + FCS_SRV_EXT.2 + FCS_SRV_EXT.2 supports the objective by requiring the TSF to make keys in its secure key storage available for use in encryption and signing operations. + FDP_BLT_EXT.1 + FDP_BLT_EXT.1 supports the objective by limiting the applications that are authorized to use the Bluetooth interface, which may include a trusted channel. + FDP_IFC_EXT.1 + FDP_IFC_EXT.1 supports the objective by requiring the TSF to have either its own IPsec VPN client or interface that allows a third-party VPN client to be deployed on it. + FDP_STG_EXT.1 + FDP_STG_EXT.1 supports the objective by requiring the TSF to implement a protected key storage that can be used to protect persistent keys used for protected communications from disclosure. + FDP_UPC_EXT.1/APPS + FDP_UPC_EXT.1/APPS supports the objective by defining the protected communications channels that it allows third-party applications to invoke. + FDP_UPC_EXT.1/BLUETOOTH + FDP_UPC_EXT.1/BLUETOOTH supports the objective by defining the Bluetooth interfaces that it allows third-party applications to invoke. + FIA_X509_EXT.1 + FIA_X509_EXT.1 supports the objective by defining the rules the TSF uses to determine if a presented X.509 certificate is valid. + FIA_X509_EXT.2 + FIA_X509_EXT.2 supports the objective by requiring the TSF to enumerate its uses of X.509 certificates (including protected communications) and its behavior when a certificate's revocation status is undetermined. + FIA_X509_EXT.3 + FIA_X509_EXT.3 supports the objective by requiring the TSF to provide a certificate validation service to third-party applications. + FIA_X509_EXT.4 + FIA_X509_EXT.4 supports the objective by defining the implementation of EST as a method by which the TSF can obtain an X.509 certificate for its own use. + FIA_X509_EXT.5 + FIA_X509_EXT.5 supports the objective by defining the implementation of Certificate Request Messages as a method by which the TSF can obtain an X.509 certificate for its own use. + FPT_BLT_EXT.1 + FPT_BLT_EXT.1 supports the objective by requiring the TSF to disable certain Bluetooth profiles when they are inactive such that explicit user authorization is required to re-enable them. + + + To address the issue of loss of confidentiality of user data in the event of loss of a Mobile Device (T.PHYSICAL_ACCESS), conformant TOEs will use data-at-rest protection. The TOE will be capable of encrypting data and keys stored on the device and will prevent unauthorized access to encrypted data. + FCS_CKM.2/LOCKED + FCS_CKM.2/LOCKED supports the objective by defining the key establishment mechanism used for keys that protect data at rest when the TOE is in a locked state. + FCS_CKM_EXT.1 + FCS_CKM_EXT.1 supports the objective by defining the TOE's root encryption key that is used to protect data at rest. + FCS_CKM_EXT.2 + FCS_CKM_EXT.2 supports the objective by defining how the TSF creates data encryption keys that are used to protect data at rest. + FCS_CKM_EXT.3 + FCS_CKM_EXT.3 supports the objective by defining the key encryption keys the TOE uses to protect data at rest and how they are created. + FCS_CKM_EXT.4 + FCS_CKM_EXT.4 supports the objective by requiring the TSF to destroy keys and key material that could otherwise be used to compromise data at rest. + FCS_CKM_EXT.5 + FCS_CKM_EXT.5 supports the objective by defining the mechanism the TSF uses to perform a wipe operation that securely destroys data at rest. + FCS_CKM_EXT.6 + FCS_CKM_EXT.6 supports the objective by requiring the TSF to use secure salts when performing cryptographic operations that require them. + FCS_CKM_EXT.7 + FCS_CKM_EXT.7 supports the objective by ensuring that the TOE's root encryption key cannot be disclosed. + FCS_COP.1/CONDITION + FCS_COP.1/CONDITION supports the objective by defining a key derivation function that can be used to protect data at rest. + FCS_COP.1/ENCRYPT + FCS_COP.1/ENCRYPT supports the objective by defining a symmetric encryption/decryption function that can be used to protect data at rest. + FCS_COP.1/HASH + FCS_COP.1/HASH supports the objective by defining a hash function that can be used to protect data at rest. + FCS_COP.1/KEYHMAC + FCS_COP.1/KEYHMAC supports the objective by defining an HMAC function that can be used to protect data at rest. + FCS_COP.1/SIGN + FCS_COP.1/SIGN supports the objective by defining a digital signature function that can be used to protect data at rest. + FCS_IV_EXT.1 + FCS_IV_EXT.1 supports the objective by ensuring that any IVs the TSF generates for AES keys are generated in an appropriate manner based on the relevant standards. + FCS_RBG_EXT.1 + FCS_RBG_EXT.1 supports the objective by defining random bit generation function that can be used to protect data at rest. + FCS_STG_EXT.1 + FCS_STG_EXT.1 supports the objective by requiring the TSF to implement a hardware or software key store to protect key data at rest. + FCS_STG_EXT.2 + FCS_STG_EXT.2 supports the objective by defining the confidentiality mechanism used to protect stored key data from unauthorized disclosure. + FCS_STG_EXT.3 + FCS_STG_EXT.3 supports the objective by defining the integrity mechanism used to protect stored key data from unauthorized modification. + FDP_ACF_EXT.3 + FDP_ACF_EXT.3 supports the objective by ensuring that the TSF does not permit write and execute permissions on stored data to be granted simultaneously. + FDP_DAR_EXT.1 + FDP_DAR_EXT.1 supports the objective by requiring the TSF to encrypt all sensitive data using data encryption keys. + FDP_DAR_EXT.2 + FDP_DAR_EXT.2 supports the objective by requiring the TSF to provide a mechanism to mark data as sensitive so that it can be subject to encryption. + FIA_UAU_EXT.1 + FIA_UAU_EXT.1 supports the objective by requiring the presentation of a valid authorization factor in order to decrypt sensitive data at rest. + FPT_JTA_EXT.1 + FPT_JTA_EXT.1 supports the objective by requiring the TSF to enforce access controls against JTAG so that this interface cannot be used to disclose data at rest. + FPT_KST_EXT.1 + FPT_KST_EXT.1 supports the objective by requiring the TSF to prevent the storage of plaintext key data in readable non-volatile memory. + FPT_KST_EXT.2 + FPT_KST_EXT.2 supports the objective by requiring the TSF to prevent any transmission of plaintext key material outside of the TOE boundary. + FPT_KST_EXT.3 + FPT_KST_EXT.3 supports the objective by requiring the TSF to prevent export of any stored plaintext keys. + -
-
- The following - security objectives for the operational environment assist the OS in correctly providing its - security functionality. These track with the assumptions about the environment. + + + - TOE administrators will configure the Mobile Device security functions - correctly to create the intended security policy + TOE administrators will configure the Mobile Device security functions correctly to create the intended security policy + + + Administrators take measures to ensure that mobile device users are adequately vetted against malicious intent and are made aware of the expectations for appropriate use of the device. - The Mobile User will immediately notify the administrator if the Mobile - Device is lost or stolen. + The Mobile User will immediately notify the administrator if the Mobile Device is lost or stolen. - The mobile device user exercises precautions to reduce the risk of loss or theft of - the Mobile Device. - - - Administrators take measures to ensure that mobile device users are adequately vetted against malicious intent and are made aware of the expectations for appropriate use of the device. + The mobile device user exercises precautions to reduce the risk of loss or theft of the Mobile Device. -
-
+ + + - -
- - - - - - - - - - - + + + + + +
+ + - The TSF shall be able to generate an audit record of the following auditable events:<htm:br/> - <htm:ol> - <htm:li>Start-up and shutdown of the audit functions</htm:li> - <htm:li>All auditable events for the [<refinement>not selected</refinement>] level of audit</htm:li> - <htm:li><refinement>All administrative actions</refinement></htm:li> - <htm:li><refinement>Start-up and shutdown of the OS</refinement></htm:li> - <htm:li><refinement>Insertion or removal of removable media</refinement></htm:li> - <htm:li><refinement>Specifically defined auditable events in <xref g="t-audit-mandatory"/></refinement></htm:li> - <htm:li><refinement><selectables> - <selectable>Audit records reaching <assignable>integer value less than 100</assignable> percentage of audit capacity</selectable> - <selectable>Specifically defined auditable events in <xref to="t-audit-additional"/></selectable> - <selectable><assignable>other auditable events derived from this Protection Profile</assignable></selectable> - <selectable exclusive="yes" id="s-audit-gen-no-add-audit">no additional auditable events</selectable> - </selectables></refinement></htm:li> - </htm:ol> - - <!-- <htm:table> --> - <!-- <htm:caption><ctr ctr-type="Table" id="manaudit">: Mandatory Auditable Events</ctr></htm:caption> --> - <!-- <htm:tr class="header"><htm:td>Requirement</htm:td><htm:td>Auditable Events</htm:td><htm:td>Additional Audit Record Contents</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FAU_GEN.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FAU_STG.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FAU_STG.4</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_CKM_EXT.1</htm:td><htm:td><selectables> --> - <!-- <selectable>generation of a REK</selectable> --> - <!-- <selectable>None</selectable> --> - <!-- </selectables>.</htm:td><htm:td>No additional information.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_CKM_EXT.2</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_CKM_EXT.3</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_CKM_EXT.4</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_CKM_EXT.5</htm:td><htm:td><selectables> --> - <!-- <selectable>Failure of the wipe</selectable> --> - <!-- <selectable>None</selectable> --> - <!-- </selectables>.</htm:td><htm:td>No additional information.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_CKM_EXT.6</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_CKM.1</htm:td><htm:td><selectables> --> - <!-- <selectable>Failure of key generation activity for authentication keys</selectable> --> - <!-- <selectable>None</selectable> --> - <!-- </selectables>.</htm:td><htm:td>No additional information.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_CKM.2/UNLOCKED</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_CKM.2/LOCKED</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_COP.1/ENCRYPT</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_COP.1/HASH</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_COP.1/SIGN</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_COP.1/KEYHMAC</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_COP.1/CONDITION</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_IV_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_SRV_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td rowspan="2">FCS_STG_EXT.1</htm:td><htm:td>Import or destruction of key.</htm:td><htm:td rowspan="2">Identity of key. Role and identity of requester.</htm:td></htm:tr> <htm:tr><htm:td><selectables> --> - <!-- <selectable>Exceptions to use and destruction rules</selectable> --> - <!-- <selectable exclusive="yes">No other events</selectable> --> - <!-- </selectables></htm:td> --> - <!-- </htm:tr> --> - <!-- <htm:tr><htm:td>FCS_STG_EXT.2</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_STG_EXT.3</htm:td><htm:td>Failure to verify integrity of stored key.</htm:td><htm:td>Identity of key being verified.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FDP_DAR_EXT.1</htm:td><htm:td><selectables> --> - <!-- <selectable>Failure to encrypt/decrypt data</selectable> --> - <!-- <selectable>None</selectable> --> - <!-- </selectables>.</htm:td><htm:td>No additional information.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FDP_DAR_EXT.2</htm:td><htm:td>Failure to encrypt/decrypt data.</htm:td><htm:td>No additional information.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FDP_IFC_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FDP_STG_EXT.1</htm:td><htm:td>Addition or removal of certificate from Trust Anchor Database.</htm:td><htm:td>Subject name of certificate.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FIA_PMG_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FIA_TRT_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FIA_UAU_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FIA_UAU.5</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FIA_UAU.7</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FIA_X509_EXT.1</htm:td><htm:td>Failure to validate X.509v3 certificate. </htm:td><htm:td>Reason for failure of validation.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FMT_MOF_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_AEX_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_AEX_EXT.2</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_AEX_EXT.3</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_JTA_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_KST_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_KST_EXT.2</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_KST_EXT.3</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_NOT_EXT.1</htm:td><htm:td><selectables> --> - <!-- <selectable>Measurement of TSF software</selectable> --> - <!-- <selectable>None</selectable> --> - <!-- </selectables>.</htm:td><htm:td><selectables> --> - <!-- <selectable>Integrity verification value</selectable> --> - <!-- <selectable>No additional information</selectable> --> - <!-- </selectables>.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_STM.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td rowspan="2">FPT_TST_EXT.1</htm:td><htm:td>Initiation of self-test.</htm:td><htm:td rowspan="2"><selectables> --> - <!-- <selectable>Algorithm that caused the failure</selectable> --> - <!-- <selectable>none</selectable> --> - <!-- </selectables></htm:td></htm:tr><htm:tr><htm:td>Failure of self-test.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td rowspan="2">FPT_TST_EXT.2/PREKERNEL</htm:td><htm:td>Start-up of TOE.</htm:td><htm:td>No additional information.</htm:td></htm:tr><htm:tr><htm:td><selectables> --> - <!-- <selectable>Detected integrity violation</selectable> --> - <!-- <selectable>none</selectable> --> - <!-- </selectables></htm:td><htm:td><selectables> --> - <!-- <selectable>The TSF code file that caused the integrity violation</selectable> --> - <!-- <selectable>No additional information</selectable> --> - <!-- </selectables></htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_TUD_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FTA_SSL_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FTA_TAB.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FAU_SAR.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- </htm:table><htm:br/> --> - <!-- <htm:table> --> - <!-- <htm:caption><ctr ctr-type="Table" id="objaudit">: Additional Auditable Events</ctr></htm:caption> --> - <!-- <htm:tr class="header"><htm:td>Requirement</htm:td><htm:td>Auditable --> - <!-- Events</htm:td><htm:td>Additional Audit Record Contents</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FAU_SEL.1</htm:td><htm:td>All modifications to the audit --> - <!-- configuration that occur while the audit collection functions are operating. --> - <!-- </htm:td><htm:td>No additional information.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_CKM_EXT.7</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_DTLS_EXT.1 (TLS Package)</htm:td><htm:td>Failure of the --> - <!-- certificate validity check.</htm:td><htm:td>Issuer Name and Subject Name of --> - <!-- certificate. </htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_HTTPS_EXT.1</htm:td><htm:td>Failure of the certificate validity --> - <!-- check.</htm:td> --> - <!-- <htm:td>Issuer Name and Subject Name of certificate.<htm:br/> --> - <!-- <selectables> --> - <!-- <selectable>User’s authorization decision</selectable> --> - <!-- <selectable>No additional information</selectable> --> - <!-- </selectables>.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_RBG_EXT.1</htm:td><htm:td>Failure of the randomization --> - <!-- process.</htm:td><htm:td>No additional information.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_RBG_EXT.2</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_RBG_EXT.3</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_SRV_EXT.2</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td rowspan="3">FCS_TLSC_EXT.1 (TLS --> - <!-- Package)</htm:td><htm:td>Establishment/termination of a TLS --> - <!-- session.</htm:td><htm:td>Non-TOE endpoint of --> - <!-- connection.</htm:td></htm:tr><htm:tr><htm:td>Failure to establish a TLS --> - <!-- session.</htm:td><htm:td>Reason for --> - <!-- failure.</htm:td></htm:tr><htm:tr><htm:td>Failure to verify presented --> - <!-- identifier.</htm:td><htm:td>Presented identifier and reference --> - <!-- identifier.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_TLSC_EXT.2 (TLS --> - <!-- Package)</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FCS_TLSC_EXT.3 (TLS --> - <!-- Package)</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FDP_ACF_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FDP_ACF_EXT.2</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FDP_ACF_EXT.3</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FDP_BCK_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <!-\- <htm:tr><htm:td>FDP_PBA_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> ToDo: Remove per bio cPP module -\-> --> - <!-- <htm:tr><htm:td>FDP_UPC_EXT.1/APPS</htm:td><htm:td>Application initiation of trusted --> - <!-- channel.</htm:td><htm:td>Name of application. Trusted channel protocol. Non-TOE --> - <!-- endpoint of connection.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FDP_UPC_EXT.1/BLUETOOTH</htm:td><htm:td>Application initiation of trusted --> - <!-- channel.</htm:td><htm:td>Name of application. Trusted channel protocol. Non-TOE --> - <!-- endpoint of connection.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FIA_AFL_EXT.1</htm:td><htm:td>Excess of authentication failure --> - <!-- limit.</htm:td><htm:td>Authentication factor used.</htm:td></htm:tr> --> - <!-- <!-\- ToDo: Remove per bio cPP module <htm:tr><htm:td>FIA_BMG_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FIA_BMG_EXT.2</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FIA_BMG_EXT.3</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FIA_BMG_EXT.4</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FIA_BMG_EXT.5</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FIA_BMG_EXT.6</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> -\-> --> - <!-- <htm:tr><htm:td>FIA_UAU_EXT.2</htm:td><htm:td>Action performed before --> - <!-- authentication.</htm:td><htm:td>No additional information.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FIA_UAU.6</htm:td><htm:td>User changes Password Authentication --> - <!-- Factor.</htm:td><htm:td>No additional information.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FIA_UAU_EXT.4</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FIA_X509_EXT.2</htm:td><htm:td>Failure to establish connection to --> - <!-- determine revocation status.</htm:td><htm:td>No additional --> - <!-- information.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FIA_X509_EXT.3</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td rowspan="3">FIA_X509_EXT.4</htm:td><htm:td>Generation of Certificate --> - <!-- Enrollment Request.</htm:td><htm:td>Issuer and Subject name of EST Server. --> - <!-- Method of authentication. Issuer and Subject name of certificate used to --> - <!-- authenticate. Content of Certificate Request Message.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>Success or failure of enrollment.</htm:td><htm:td>Issuer and Subject --> - <!-- name of added certificate or reason for failure.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>Update of EST Trust Anchor Database</htm:td><htm:td>Subject name of --> - <!-- added Root CA.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FIA_X509_EXT.5</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td rowspan="5">FMT_SMF_EXT.1</htm:td> --> - <!-- <htm:td><selectables> --> - <!-- <selectable>Initiation of policy update</selectable> --> - <!-- <selectable>none</selectable> --> - <!-- </selectables>.</htm:td> --> - <!-- <htm:td><selectables> --> - <!-- <selectable>Policy name</selectable> --> - <!-- <selectable>none</selectable> --> - <!-- </selectables>.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td><selectables> --> - <!-- <selectable>Change of settings</selectable> --> - <!-- <selectable>none</selectable> --> - <!-- </selectables></htm:td> --> - <!-- <htm:td><selectables> --> - <!-- <selectable>Role of user that changed setting</selectable> --> - <!-- <selectable>Value of new setting</selectable> --> - <!-- <selectable>none</selectable> --> - <!-- </selectables>.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td><selectables> --> - <!-- <selectable>Success or failure of function</selectable> --> - <!-- <selectable>none</selectable> --> - <!-- </selectables></htm:td> --> - <!-- <htm:td><selectables> --> - <!-- <selectable>Role of user that performed function</selectable> --> - <!-- <selectable>Function performed</selectable> --> - <!-- <selectable>Reason for failure, none</selectable> --> - <!-- </selectables>.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>Initiation of software update.</htm:td><htm:td>Version of update. --> - <!-- </htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>Initiation of application installation or --> - <!-- update.</htm:td><htm:td>Name and version of application.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FMT_SMF_EXT.2</htm:td> --> - <!-- <htm:td><selectables> --> - <!-- <selectable>Unenrollment</selectable> --> - <!-- <selectable>Initiation of unenrollment</selectable> --> - <!-- <selectable>none</selectable> --> - <!-- </selectables></htm:td> --> - <!-- <htm:td><selectables> --> - <!-- <selectable>Identity of administrator Remediation action --> - <!-- performed</selectable> --> - <!-- <selectable>failure of accepting command to unenroll</selectable> --> - <!-- <selectable>none</selectable> --> - <!-- </selectables></htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FMT_SMF_EXT.3</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_AEX_EXT.4</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_AEX_EXT.5</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_AEX_EXT.6</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_AEX_EXT.7</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_BBD_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_BLT_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_NOT_EXT.2</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_TST_EXT.2/POSTKERNEL</htm:td><htm:td><selectables> --> - <!-- <selectable>Detected integrity violation</selectable> --> - <!-- <selectable>none</selectable> --> - <!-- </selectables></htm:td> --> - <!-- <htm:td><selectables> --> - <!-- <selectable>The TSF code file that caused the integrity violation</selectable> --> - <!-- <selectable>No additional information</selectable> --> - <!-- </selectables></htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_TST_EXT.3</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_TUD_EXT.2</htm:td><htm:td>Success or failure of --> - <!-- signature verification for software updates.</htm:td><htm:td>No additional --> - <!-- information.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_TUD_EXT.3</htm:td><htm:td>Success or failure of signature verification for --> - <!-- applications.</htm:td><htm:td>No additional information.</htm:td></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_TUD_EXT.4</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_TUD_EXT.5</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FPT_TUD_EXT.6</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> - <!-- <htm:tr><htm:td>FTP_ITC_EXT.1</htm:td><htm:td>Initiation and termination of trusted --> - <!-- channel.</htm:td><htm:td>Trusted channel protocol. Non-TOE endpoint of --> - <!-- connection.</htm:td></htm:tr> --> - <!-- </htm:table> --> - <htm:br/> - <htm:br/> - + The TSF shall be able to generate an audit record of the following auditable events: <htm:ol><htm:li>Start-up and shutdown of the audit functions</htm:li><htm:li>All auditable events for the [<htm:b>not selected</htm:b>] level of audit</htm:li><htm:li><htm:b>All administrative actions</htm:b></htm:li><htm:li><htm:b>Start-up and shutdown of the OS</htm:b></htm:li><htm:li><htm:b>Insertion or removal of removable media</htm:b></htm:li><htm:li><htm:b>Specifically defined auditable events in <xref g="t-audit-mandatory"></xref></htm:b></htm:li><htm:li><htm:b><selectables><selectable id="fau_gen.1.1_1">Audit records reaching <assignable>integer value less than 100 </assignable> percentage of audit capacity</selectable><selectable id="fau_gen.1.1_3" >Specifically defined auditable events in <xref to="t-audit-additional"></xref></selectable><selectable id="fau_gen.1.1_5" ><assignable>other auditable events derived from this Protection Profile </assignable></selectable><selectable id="s-audit-gen-no-add-audit" exclusive="yes" >no additional auditable events</selectable></selectables></htm:b></htm:li></htm:ol> Administrator actions are defined as functions labeled as - mandatory for FMT_MOF_EXT.1.2 (i.e. ‘M-MM’ in ). If the TSF + mandatory for FMT_MOF_EXT.1.2 (i.e. ‘M-MM’ in ). If the TSF does not support removable media, number 4 is implicitly met. The - TSF must generate an audit record for all events contained in . Generating audit records for events in is currently objective. It is acceptable to include individual SFRs from in the ST, without including the entirety of . - Application Note: FPT_TST_EXT.1 – + TSF must generate an audit record for all events contained in . Generating audit records for events in is currently objective. It is acceptable to include individual SFRs from in the ST, without including the entirety of . Application Note: FPT_TST_EXT.1 – Audit of self-tests is required only at initial start-up. Since the TOE "transitions to non-operational mode" upon failure of a self-test, per FPT_NOT_EXT.1, this is considered equivalent evidence to an audit record for the failure of a self-test. @@ -1946,54 +583,32 @@ The scope of this Protection Profile (PP) is to describe the security functional volume encryption for protected data, since it is not feasible to audit when the encryption/decryption fails. If the TOE utilizes file-based encryption for protected data and audits when this encryption/decryption fails, then that auditable event should - be selected. - - Application Note: - If the audit event for FMT_SMF.1 is included in the ST, it is acceptable + be selected. Application Note: If the audit event for FMT_SMF.1 is included in the ST, it is acceptable for the initiation of the software update to be audited without indicating the outcome - (success or failure) of the update. - + (success or failure) of the update. - The TSF shall record within each audit record at least the following information: <htm:ol> - - <htm:li>Date and time of the event</htm:li> - <htm:li>Type of event</htm:li> - <htm:li>Subject identity</htm:li> - <htm:li>The outcome (success or failure) of the event</htm:li> - <refinement><htm:li>Additional information in <xref g="t-audit-mandatory"/></htm:li> - <htm:li> - <selectables> - <selectable>Additional information in <xref to="t-audit-additional"/></selectable> - <selectable id="s-audit-no-add-info" exclusive="yes"> no additional information</selectable> - </selectables></htm:li></refinement> - </htm:ol> - + The TSF shall record within each audit record at least the following information: <htm:ol><htm:li>Date and time of the event</htm:li><htm:li>Type of event</htm:li><htm:li>Subject identity</htm:li><htm:li>The outcome (success or failure) of the event</htm:li><htm:b><htm:li>Additional information in <xref g="t-audit-mandatory"></xref></htm:li><htm:li><selectables><selectable id="fau_gen.1.2_1" >Additional information in <xref to="t-audit-additional"></xref></selectable><selectable id="s-audit-no-add-info" exclusive="yes" > no additional information</selectable></selectables></htm:li></htm:b></htm:ol> The subject identity is usually the process name/ID. The event type is often indicated by a severity level, for example, ‘info’, ‘warning’, or ‘error’. - If is selected in the - second selection of FAU_GEN.1.1, then must be selected. - - s-audit-gen-no-add-audit - s-audit-no-add-info - - + If is selected in the + second selection of FAU_GEN.1.1, then must be selected. + s-audit-gen-no-add-audits-audit-no-add-info - For each audit event selected from in + For each audit event selected from in FAU_GEN.1.1 if additional information is required to be recorded within the audit record, it should be included in this selection. - - The evaluator shall check the TSS and ensure that it lists all of the auditable + + The evaluator shall check the TSS and ensure that it lists all of the auditable events and provides a format for audit records. Each audit record format type must be covered, along with a brief description of each field. The evaluator shall check to make sure that every audit event type mandated by the PP is described and that the description of the fields contains the information required in FAU_GEN.1.2. - - + The evaluator shall also make a determination of the administrative actions that are relevant in the context of this PP including those listed in the Management section. The evaluator shall examine the administrative guide and make a @@ -2003,8 +618,7 @@ The scope of this Protection Profile (PP) is to describe the security functional document the methodology or approach taken while determining which actions in the administrative guide are security relevant with respect to this PP. The evaluator may perform this activity as part of the activities associated with ensuring the - AGD_OPE guidance satisfies the requirements. - + AGD_OPE guidance satisfies the requirements. The evaluator shall test the TOE’s ability to correctly generate audit records by having the TOE generate audit records for the events listed in the provided table and administrative actions. This should include all instances of an event. The @@ -2020,48 +634,41 @@ The scope of this Protection Profile (PP) is to describe the security functional testing performed to ensure that the administrative guidance provided is correct verifies that AGD_OPE.1 is satisfied and should address the invocation of the administrative actions that are needed to verify the audit records are generated as - expected. - + expected. - + - + + - The TSF shall provide [<htm:i>the administrator</htm:i>] with the - capability to read [<htm:i>all audited events and record contents</htm:i>] - from the audit records. + The TSF shall provide [ <htm:i>the administrator</htm:i> ] with the capability to read [ <htm:i>all audited events and record contents</htm:i> ] from the audit records. The administrator must have access to read the audit record, perhaps through an API or via an MDM Agent, which transfers the local records stored on the TOE to the MDM Server where the enterprise administrator may view them. If this - requirement is included in the ST, function must be + requirement is included in the ST, function must be included in the selection of FMT_SMF.1. - The TSF shall provide the audit records in a manner suitable for the user <!--ToDo: administrator? -->to interpret the information. - + The TSF shall provide the audit records in a manner suitable for the userto interpret the information. + There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. The evaluation activity for this requirement is performed in conjunction with - test for function of FMT_SMF.1. + test for function of FMT_SMF.1. - + - + + - The TSF shall be able to select the set of events to be audited from the set of - all auditable events based on the following attributes: <selectables linebreak="yes"> - <selectable>[event type]</selectable> - <selectable>[success of auditable security events</selectable> - <selectable>failure of auditable security events</selectable> - <selectable><assignable>other attributes</assignable>]</selectable> - </selectables>. + The TSF shall be able to select the set of events to be audited from the set of all auditable events based on the following attributes:<selectables><selectable id="fau_sel.1.1_1" >[event type]</selectable><selectable id="fau_sel.1.1_2" >[success of auditable security events</selectable><selectable id="fau_sel.1.1_3" >failure of auditable security events</selectable><selectable id="fau_sel.1.1_5" ><assignable>other attributes </assignable></selectable><selectable id="fau_sel.1.1_4">]</selectable></selectables>. The intent of this requirement is to identify all criteria that can be selected to trigger an audit event. This can be configured through an interface on the TSF for a user or administrator to invoke. For the ST author, the assignment is used to list any additional criteria or "none". - + There are no TSS evaluation activities for this component. The evaluator shall review the administrative guidance to ensure that the guidance itemizes all event types, as well as describes all attributes that are to @@ -2070,14 +677,13 @@ The scope of this Protection Profile (PP) is to describe the security functional how to set the pre-selection as well as explain the syntax (if present) for multi-value pre-selection. The administrative guidance shall also identify those audit records that are always recorded, regardless of the selection criteria - currently being enforced. - - The evaluator shall also perform the following tests: + currently being enforced. + For each attribute listed in the requirement, the evaluator shall devise a test to show that selecting the attribute causes only audit events with that attribute (or those that are always recorded, as identified in the - administrative guidance) to be recorded. + administrative guidance) to be recorded. [conditional] If the TSF supports specification of more complex audit pre-selection criteria (e.g., multiple attributes, logical expressions using attributes) then the evaluator shall devise tests showing that this capability @@ -2088,19 +694,18 @@ The scope of this Protection Profile (PP) is to describe the security functional - - All modifications to the audit configuration that - occur while the audit collection functions are operating - + + All modifications to the audit configuration that occur while the audit collection functions are operating + - + + The TSF shall protect the stored audit records in the audit trail from unauthorized deletion. - The TSF shall be able to [<htm:i>prevent</htm:i>] unauthorized - modifications to the stored audit records in the audit trail. - + The TSF shall be able to [ <htm:i>prevent</htm:i> ] unauthorized modifications to the stored audit records in the audit trail. + The evaluator shall ensure that the TSS lists the location of all logs and the access controls of those files such that unauthorized modification and deletion are prevented. @@ -2117,14 +722,14 @@ The scope of this Protection Profile (PP) is to describe the security functional - + - + + - The TSF shall [<htm:i>overwrite the oldest stored audit records</htm:i>] <htm:s>and [assignment: other actions to be taken in case of audit storage failure]</htm:s> if the audit trail is - full. - - The evaluator shall examine the TSS to ensure that it describes the size limits + The TSF shall [ <htm:i>overwrite the oldest stored audit records</htm:i> ] <htm:s>and [assignment: other actions to be taken in case of audit storage failure]</htm:s> if the audit trail is full. + + The evaluator shall examine the TSS to ensure that it describes the size limits on the audit records, the detection of a full audit trail, and the actions taken by the TSF when the audit trail is full. The evaluator shall ensure that the actions results in the deletion or overwrite of the oldest stored record. @@ -2132,48 +737,23 @@ The scope of this Protection Profile (PP) is to describe the security functional There are no test evaluation activities for this component. - + - - - This section describes how keys are generated, derived, combined, released and destroyed. There are two major types of keys: DEKs and KEKs. (A REK is considered a KEK.) - DEKs are used to protect data (as in the DAR protection described in FDP_DAR_EXT.1 and FDP_DAR_EXT.2). KEKs are used to protect other keys – DEKs, other KEKs, and other types of keys stored by the user or applications. - The following diagram shows an example key hierarchy to illustrate the concepts of this profile. - This example is not meant as an approved design, but ST authors will be expected to provide a diagram illustrating their key hierarchy in order to demonstrate that they meet the requirements of this profile. - Please note if is selected in FIA_UAU.5.1, each BAF claimed in FIA_MBV_EXT.1.1 in the shall be illustrated in the key hierarchy diagram, to include a description of when and how the BAF is used to release keys. - If is selected in FIA_UAU.5.1, meaning that a PIN or password must be used in conjunction with the BAF, this interaction shall be included. -
- +
+ +
+ This section describes how keys are generated, derived, combined, released and destroyed. There are two major types of keys: DEKs and KEKs. (A REK is considered a KEK.) DEKs are used to protect data (as in the DAR protection described in FDP_DAR_EXT.1 and FDP_DAR_EXT.2). KEKs are used to protect other keys – DEKs, other KEKs, and other types of keys stored by the user or applications. The following diagram shows an example key hierarchy to illustrate the concepts of this profile. This example is not meant as an approved design, but ST authors will be expected to provide a diagram illustrating their key hierarchy in order to demonstrate that they meet the requirements of this profile. Please note if is selected in FIA_UAU.5.1, each BAF claimed in FIA_MBV_EXT.1.1 in the shall be illustrated in the key hierarchy diagram, to include a description of when and how the BAF is used to release keys. If is selected in FIA_UAU.5.1, meaning that a PIN or password must be used in conjunction with the BAF, this interaction shall be included.
 + + - The TSF shall generate <refinement>asymmetric</refinement> cryptographic keys in - accordance with a specified cryptographic key generation algorithm - <selectables linebreak="yes"> - <selectable><readable>RSA schemes</readable><refinement>RSA schemes using</refinement> cryptographic key sizes of - <assignable id="a-keygen-rsa-size">2048-bit or greater</assignable> that meet [<htm:i>FIPS PUB - 186-4, "Digital Signature Standard (DSS)", Appendix - B.3</htm:i>]</selectable> - <selectable id="s-keygen-ecc"><readable>ECC schemes</readable><refinement>ECC schemes using: </refinement><selectables linebreak="yes"> - <selectable><refinement>"NIST curves" P-384 and </refinement><selectables> - <selectable><refinement>P-256</refinement></selectable> - <selectable><refinement>P-521</refinement></selectable> - <selectable exclusive="yes"><refinement>no other - curves</refinement></selectable></selectables> that meet the following: [<htm:i>FIPS PUB 186-4, "Digital - Signature Standard (DSS)", Appendix B.4</htm:i>]</selectable> - <selectable><refinement>Curve25519 schemes</refinement> that meet the following: [<htm:i>RFC - 7748</htm:i>]</selectable></selectables></selectable> - <selectable><refinement>FFC schemes using: </refinement> - <selectables linebreak="yes"> - <selectable>cryptographic key sizes of <refinement>2048-bit or - greater</refinement> that meet the following [<htm:i>FIPS PUB 186-4, - "Digital Signature Standard (DSS)", Appendix B.1</htm:i>]</selectable> - <!-- <selectable><refinement>Diffie-Hellman group 14 </refinement>that meet the - following: [<htm:i>RFC3526</htm:i>]</selectable> --> - <selectable><refinement>"safe-prime" groups</refinement> that meet the + <title>The TSF shall generate <htm:b>asymmetric</htm:b> cryptographic keys in accordance with a specified cryptographic key generation algorithm<selectables><selectable id="fcs_ckm.1.1_1"><htm:b>RSA schemes using</htm:b> cryptographic key sizes of <assignable>2048-bit or greater </assignable> that meet [<htm:i>FIPS PUB 186-4, "Digital Signature Standard (DSS)", Appendix B.3</htm:i>]</selectable><selectable id="s-keygen-ecc"><htm:b>ECC schemes using: </htm:b><selectables><selectable id="fcs_ckm.1.1_3"><htm:b>"NIST curves" P-384 and </htm:b><selectables><selectable id="fcs_ckm.1.1_4" ><htm:b>P-256</htm:b></selectable><selectable id="fcs_ckm.1.1_5" ><htm:b>P-521</htm:b></selectable><selectable id="fcs_ckm.1.1_6" exclusive="yes" ><htm:b>no other + curves</htm:b></selectable></selectables> that meet the following: [<htm:i>FIPS PUB 186-4, "Digital Signature Standard (DSS)", Appendix B.4</htm:i>]</selectable><selectable id="fcs_ckm.1.1_7" ><htm:b>Curve25519 schemes</htm:b> that meet the following: [<htm:i>RFC + 7748</htm:i>]</selectable></selectables></selectable><selectable id="fcs_ckm.1.1_8"><htm:b>FFC schemes using: </htm:b><selectables><selectable id="fcs_ckm.1.1_9" >cryptographic key sizes of <htm:b>2048-bit or + greater</htm:b> that meet the following [<htm:i>FIPS PUB 186-4, + "Digital Signature Standard (DSS)", Appendix B.1</htm:i>]</selectable><selectable id="fcs_ckm.1.1_10" ><htm:b>"safe-prime" groups</htm:b> that meet the following: [<htm:i>NIST Special Publication 800-56A Revision 3, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete - Logarithm Cryptography"</htm:i>]</selectable> - </selectables></selectable> - </selectables>. + Logarithm Cryptography"]. The ST author must select all key generation schemes used for key establishment and entity authentication. When key generation is used for key establishment, the schemes in FCS_CKM.2/UNLOCKED and selected cryptographic protocols @@ -2182,19 +762,16 @@ The scope of this Protection Profile (PP) is to describe the security functional TOE acts as a receiver in the RSA key establishment scheme, the TOE does not need to implement RSA key generation. Curve25519 can only be used for ECDH and in conjunction with FDP_DAR_EXT.2.2. - - The evaluator shall ensure that the TSS identifies the key sizes supported by + + The evaluator shall ensure that the TSS identifies the key sizes supported by the TOE. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme. The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key generation schemes - and key sizes for all uses defined in this PP. - - - Evaluation Activity Note: The following tests require the developer to + and key sizes for all uses defined in this PP. + Evaluation Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are - typically not found on factory products. - Key Generation for FIPS PUB 186-4 RSA + typically not found on factory products.Key Generation for FIPS PUB 186-4 RSA Schemes The evaluator shall verify the implementation of RSA Key Generation by the TOE using the Key Generation test. This test verifies the ability of the TSF to correctly produce values for the key @@ -2202,20 +779,8 @@ The scope of this Protection Profile (PP) is to describe the security functional prime factors p and q, the public modulus n and the calculation of the private signature exponent d. Key Pair generation specifies 5 ways (or methods) to generate the primes - p and q. These include: - Random Primes: - Provable primes - Probable primes - - - Primes with Conditions: - Primes p1, p2, q1,q2, p and q shall all be provable primes - Primes p1, p2, q1, and q2 shall be provable primes and p and q shall - be probable primes - Primes p1, p2, q1,q2, p and q shall all be probable primes - - - To test the key generation method for the Random Provable primes method + p and q. These include: Random Primes: Provable primesProbable primesPrimes with Conditions: Primes p1, p2, q1,q2, p and q shall all be provable primes Primes p1, p2, q1, and q2 shall be provable primes and p and q shall + be probable primesPrimes p1, p2, q1,q2, p and q shall all be probable primes To test the key generation method for the Random Provable primes method and for all the Primes with Conditions methods, the evaluator must seed the TSF key generation routine with sufficient data to deterministically generate the RSA key pair. This includes the random seeds, the public exponent of the RSA key, and the @@ -2225,49 +790,23 @@ The scope of this Protection Profile (PP) is to describe the security functional known good implementation. If possible, the Random Probable primes method should also be verified against a known good implementation as described above. Otherwise, the evaluator shall have the TSF generate 10 keys pairs - for each supported key length nlen and verify: - n = p*q - p and q are probably prime according to Miller-Rabin tests - GCD(p-1,e) = 1 - GCD(q-1,e) = 1 - 2^16 < e < 2^256 and e is an odd integer - |p-q| > 2^(nlen/2 – 100) - p >= squareroot(2)*( 2^(nlen/2 -1) ) - q >= squareroot(2)*( 2^(nlen/2 -1) ) - 2^(nlen/2) < d < LCM(p-1,q-1) - e*d = 1 mod LCM(p-1,q-1) - - - Key Generation for FIPS 186-4 Elliptic Curve Cryptography - (ECC) - FIPS 186-4 ECC Key Generation Test For each + for each supported key length nlen and verify: n = p*qp and q are probably prime according to Miller-Rabin testsGCD(p-1,e) = 1GCD(q-1,e) = 12^16 < e < 2^256 and e is an odd integer|p-q| > 2^(nlen/2 – 100)p >= squareroot(2)*( 2^(nlen/2 -1) )q >= squareroot(2)*( 2^(nlen/2 -1) )2^(nlen/2) < d < LCM(p-1,q-1)e*d = 1 mod LCM(p-1,q-1)Key Generation for FIPS 186-4 Elliptic Curve Cryptography + (ECC)FIPS 186-4 ECC Key Generation Test For each supported NIST curve, i.e. P-256, P-384 and P-521, the evaluator shall require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated using an approved random bit generator (RBG). To determine correctness, the evaluator shall submit the generated key pairs to the public key - verification (PKV) function of a known good implementation. - FIPS 186-4 Public Key Verification (PKV) Test For + verification (PKV) function of a known good implementation. FIPS 186-4 Public Key Verification (PKV) Test For each supported NIST curve, i.e. P-256, P-384 and P-521, the evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify five of the public key values so that they are incorrect, leaving five values unchanged (i.e. correct). The evaluator shall obtain in response - a set of 10 PASS/FAIL values. - - - Key Generation for Curve25519 + a set of 10 PASS/FAIL values. Key Generation for Curve25519 The evaluator shall require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated as specified in RFC 7748 using an approved random bit generator (RBG) and shall be written in little-endian order (least significant byte first). To determine correctness, the evaluator shall submit the generated key pairs to the public key verification (PKV) function of a known good implementation. Note: Assuming the PKV function of the good implementation will (using little-endian order): - - Confirm the private and public keys are 32-byte values - Confirm the three least significant bits of the first byte of the private key are zero - Confirm the most significant bit of the last byte is zero - Confirm the second most significant bit of the last byte is one - Calculate the expected public key from the private key and confirm it matches the supplied public key - - + Confirm the private and public keys are 32-byte valuesConfirm the three least significant bits of the first byte of the private key are zeroConfirm the most significant bit of the last byte is zeroConfirm the second most significant bit of the last byte is oneCalculate the expected public key from the private key and confirm it matches the supplied public key The evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify 5 of the public key values so that they are incorrect, leaving five values unchanged (i.e. correct). The evaluator shall obtain in response a set of 10 PASS/FAIL values. - - Key Generation for Finite-Field Cryptography + Key Generation for Finite-Field Cryptography (FFC) The evaluator shall verify the implementation of the Parameters Generation and the Key Generation for FFC by the TOE using the Parameter Generation and Key Generation test. This test verifies the ability of the TSF to @@ -2275,21 +814,10 @@ The evaluator shall generate 10 private/public key pairs using the key generatio p-1), the cryptographic group generator g, and the calculation of the private key x and public key y. The Parameter generation specifies 2 ways (or methods) to generate the cryptographic prime q and the field prime p: - Cryptographic and Field Primes: - - Primes q and p shall both be provable primes - Primes q and field prime p shall both be probable primes - and two ways to generate the cryptographic group generator - g: Cryptographic Group Generator: - Generator g constructed through a verifiable process - Generator g constructed through an unverifiable process - The Key generation specifies 2 ways to generate the private key - x: Private Key: - - len(q) bit output of RBG where 1 <= x <= q-1 - len(q) + 64 bit output of RBG, followed by a mod q-1 operation where - 1<= x<=q-1 - The security strength of the RBG must be at least that of the security + Cryptographic and Field Primes:Primes q and p shall both be provable primesPrimes q and field prime p shall both be probable primes and two ways to generate the cryptographic group generator + g: Cryptographic Group Generator:Generator g constructed through a verifiable processGenerator g constructed through an unverifiable process The Key generation specifies 2 ways to generate the private key + x: Private Key:len(q) bit output of RBG where 1 < = x < = q-1 len(q) + 64 bit output of RBG, followed by a mod q-1 operation where + 1 < = x < =q-1 The security strength of the RBG must be at least that of the security offered by the FFC parameter set. To test the cryptographic and field prime generation method for the provable primes method or the group generator g for a verifiable process, the evaluator must seed the TSF parameter @@ -2297,83 +825,110 @@ The evaluator shall generate 10 private/public key pairs using the key generatio set. For each key length supported, the evaluator shall have the TSF generate 25 parameter sets and key pairs. The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF - with those generated from a known good implementation. Verification must also confirm - g != 0,1 - q divides p-1 - g^q mod p = 1 - g^x mod p = y - - for each FFC parameter set and key pair. - - + with those generated from a known good implementation. Verification must also confirmg != 0,1q divides p-1g^q mod p = 1g^x mod p = y for each FFC parameter set and key pair. + - - Failure of key generation activity for authentication keysNone - + + + + Failure of key generation activity for authentication keys + none + + + + + + + + The TSF shall <htm:b>perform</htm:b> cryptographic <htm:b>key + establishment</htm:b> in accordance with a specified cryptographic key <htm:b>establishment</htm:b> method:<selectables><selectable id="s-locked-rsa" >[<htm:i>RSA-based key establishment schemes</htm:i>] that meet the following: [<htm:i>NIST Special Publication 800-56B, “Recommendation for Pair-Wise Key + Establishment Schemes Using Integer Factorization + Cryptography”</htm:i>]</selectable><selectable id="fcs_ckm.2.1_LOCKED_1">[<htm:i>Elliptic curve-based key establishment schemes</htm:i>] that meet the following: <selectables><selectable id="s-locked-ecc-800-56A" ><htm:b>NIST Special Publication 800-56A Revision 3, + "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete + Logarithm Cryptography"</htm:b></selectable><selectable id="fcs_ckm.2.1_LOCKED_2" ><htm:b>RFC 7748, "Elliptic Curves for + Security"</htm:b></selectable></selectables></selectable><selectable id="fcs_ckm.2.1_LOCKED_3" >[<htm:i>Finite field-based key establishment schemes</htm:i>] + that meet the following: [<htm:i>NIST Special Publication 800-56A Revision 3, + "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm + Cryptography"</htm:i>]</selectable></selectables><htm:b>for the purposes of encrypting sensitive data received while the device is + locked.</htm:b> + The RSA-based key establishment schemes are described in + Section 9 of NIST SP 800-56B; however, Section 9 relies on implementation of other + sections in SP 800-56B. If the TOE acts as a receiver in the RSA key establishment + scheme, the TOE does not need to implement RSA key generation. The + elliptic curves used for the key establishment scheme must correlate with the curves + specified in FCS_CKM.1.1. The domain parameters used for the finite + field-based key establishment scheme are specified by the key generation according to + FCS_CKM.1.1. + + There are no TSS evaluation activities for this component. + There are no guidance evaluation activities for this component. + The test for SP800-56A Revision 3 and SP800-56B key establishment schemes is + performed in association with FCS_CKM.2/UNLOCKED. Curve25519 Key Establishment Schemes The evaluator + shall verify a TOE's implementation of the key agreement scheme using the following + Function and Validity tests. These validation tests for each key agreement scheme + verify that a TOE has implemented the components of the key agreement scheme + according to the specification. These components include the calculation of the + shared secret K and the hash of K. Function Test The Function test verifies the + ability of the TOE to implement the key agreement schemes correctly. To conduct this + test the evaluator shall generate or obtain test vectors from a known good + implementation of the TOE supported schemes. For each supported key agreement role + and hash function combination, the tester shall generate 10 sets of public keys. + These keys are static, ephemeral or both depending on the scheme being tested. + The evaluator shall obtain the shared secret value K, and the + hash of K. The evaluator shall verify the correctness of the TSF’s + implementation of a given scheme by using a known good implementation to calculate + the shared secret value K and compare the hash generated from this value. Validity Test The Validity test verifies the + ability of the TOE to recognize another party’s valid and invalid key agreement + results. To conduct this test, the evaluator generates a set of 30 test vectors + consisting of data sets including the evaluator’s public keys and the TOE’s + public/private key pairs. The evaluator shall inject an error in + some of the test vectors to test that the TOE recognizes invalid key agreement + results caused by the following fields being incorrect: the shared secret value K or + the hash of K. At least two of the test vectors shall remain unmodified and + therefore should result in valid key agreement results (they should pass). + The TOE shall use these modified test vectors to emulate the key + agreement scheme using the corresponding parameters. The evaluator shall compare the + TOE’s results with the results using a known good implementation verifying that the + TOE detects these errors. + + + - + + - The TSF shall <refinement>perform</refinement> cryptographic <refinement>key - establishment</refinement> in accordance with a specified cryptographic key - <refinement>establishment</refinement> method <selectables linebreak="yes"> - <selectable><readable>RSA-based key establishment schemes</readable>[<htm:i>RSA-based key establishment schemes</htm:i>] that meet the following - <selectables linebreak="yes"> - <selectable>NIST Special Publication 800-56B, “Recommendation for Pair-Wise + <title>The TSF shall <htm:b>perform</htm:b> cryptographic <htm:b>key + establishment</htm:b> in accordance with a specified cryptographic key <htm:b>establishment</htm:b> method<selectables><selectable id="fcs_ckm.2.1_UNLOCKED_1">[<htm:i>RSA-based key establishment schemes</htm:i>] that meet the following <selectables><selectable id="fcs_ckm.2.1_UNLOCKED_2" >NIST Special Publication 800-56B, “Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization - Cryptography”</selectable> - <selectable>RSAES-PKCS1-v1_5 as specified in Section 7.2 of RFC 8017, + Cryptography”</selectable><selectable id="fcs_ckm.2.1_UNLOCKED_3" >RSAES-PKCS1-v1_5 as specified in Section 7.2 of RFC 8017, "Public-Key Cryptography Standards (PKCS) #1:RSA Cryptography Specifications - Version 2.2"</selectable> - </selectables></selectable> - <selectable><readable>Elliptic curve-based key establishment schemes</readable>[<htm:i>Elliptic curve-based key establishment schemes</htm:i>] + Version 2.2"</selectable></selectables></selectable><selectable id="fcs_ckm.2.1_UNLOCKED_4" >[<htm:i>Elliptic curve-based key establishment schemes</htm:i>] that meet the following: [<htm:i>NIST Special Publication 800-56A Revision 3, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm - Cryptography"</htm:i>]</selectable> - <selectable>[<htm:i>Finite field-based key establishment schemes</htm:i>] + Cryptography"</htm:i>]</selectable><selectable id="fcs_ckm.2.1_UNLOCKED_5" >[<htm:i>Finite field-based key establishment schemes</htm:i>] that meet the following: [<htm:i>NIST Special Publication 800-56A Revision 3, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm - Cryptography"</htm:i>]</selectable> - <!-- <selectable>[<htm:i>Key establishment schemes using Diffie-Hellman group 14</htm:i>] that - meets the following: [<htm:i>RFC 3526</htm:i>]</selectable> --> - <!-- TD 502 - removed the below, however, I have a question into Dianne about this --> - <!-- <selectable><refinement>FFC schemes using "safe-prime" groups that meet the - following: 'NIST Special Publication 800-56A Revision 3, "Recommendation for - Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography"', and <selectables> - <selectable>RFC 3526</selectable> - <selectable>RFC 7919</selectable> - </selectables></refinement></selectable>--> - </selectables>. + Cryptography"]. The ST author must select all key establishment schemes used for the selected cryptographic protocols and any RSA-based key establishment schemes that may be used to satisfy FDP_DAR or FCS_STG. Also, FCS_TLSC_EXT.1 requires ciphersuites that use RSA-based key establishment schemes. The RSA-based key establishment schemes are described in Section 9 of NIST SP 800-56B; however, Section 9 relies on implementation of other sections in SP 800-56B. If the TOE only acts as a receiver in the RSA key establishment scheme, the TOE does not need to implement RSA key generation. The elliptic curves used for the key establishment scheme must correlate with the curves specified in FCS_CKM.1.1. The domain parameters used for the finite field-based key establishment scheme are specified by the key generation according to FCS_CKM.1.1. The finite field-based key establishment schemes that conform to NIST SP 800-56A Revision 3 correspond to the "safe-prime" groups selection in FCS_CKM.1.1. - - - The evaluator shall ensure that the supported key establishment schemes + + The evaluator shall ensure that the supported key establishment schemes correspond to the key generation schemes identified in FCS_CKM.1.1. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that - it identifies the usage for each scheme. - - - - - - + it identifies the usage for each scheme. The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key establishment - schemes. - - - Evaluation Activity Note: The following tests require the developer to + schemes. + Evaluation Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products. The evaluator shall verify the implementation of the key - establishment schemes supported by the TOE using the applicable tests below. - SP800-56A Revision 3 Key Establishment Schemes + establishment schemes supported by the TOE using the applicable tests below. SP800-56A Revision 3 Key Establishment Schemes The evaluator shall verify a TOE's implementation of SP800-56A Revision 3 key establishment schemes using the following Function and Validity tests. These validation tests for each key agreement scheme verify that a TOE has @@ -2384,9 +939,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio supported, the evaluator shall also verify that the components of key confirmation have been implemented correctly, using the test procedures described below. This includes the parsing of the DKM, the generation of MACdata and the calculation of - MacTag. - Function Test - The Function test verifies the ability of the TOE to implement + MacTag. Function Test The Function test verifies the ability of the TOE to implement the key agreement schemes correctly. To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each supported key agreement scheme-key agreement role @@ -2404,9 +957,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio calculate the shared secret value, derive the keying material DKM, and compare hashes or MAC tags generated from these values. If key confirmation is supported, the TSF shall perform the above for each implemented - approved MAC algorithm. - Validity Test - The Validity test verifies the ability of the TOE to recognize + approved MAC algorithm. Validity Test The Validity test verifies the ability of the TOE to recognize another party’s valid and invalid key agreement results with or without key confirmation. To conduct this test, the evaluator shall obtain a list of the supporting cryptographic functions included in the SP800-56A Revision 3 key @@ -2428,8 +979,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio these modified test vectors to emulate the key agreement scheme using the corresponding parameters. The evaluator shall compare the TOE’s results with the results using a known good implementation verifying that the TOE detects these - errors. - SP800-56B Key Establishment Schemes The evaluator shall verify that + errors. SP800-56B Key Establishment Schemes The evaluator shall verify that the TSS describes whether the TOE acts as a sender, a recipient, or both for RSA-based key establishment schemes. If the TOE acts as a sender, the following evaluation activity shall be performed to ensure the proper operation @@ -2476,15 +1026,10 @@ The evaluator shall generate 10 private/public key pairs using the key generatio ciphertext values that trigger each of the three decryption error checks described in NIST Special Publication 800-56B section 7.2.3.3, ensure that each decryption attempt results in an error, and ensure that any outputted or logged error message - is identical for each. - RSAES-PKCS1-v1_5 Key Establishment Schemes The evaluator shall + is identical for each.RSAES-PKCS1-v1_5 Key Establishment Schemes The evaluator shall verify the correctness of the TSF's implementation of RSAES-PKCS1-v1_5 by using a known good implementation for each protocol selected in FTP_ITC_EXT.1 that uses RSAES-PKCS1-v1_5. - FFC Schemes using "safe-prime" groups The evaluator shall verify the correctness of the TSF's implementation of "safe-prime" groups by using a known good implementation for each protocol selected @@ -2492,117 +1037,23 @@ The evaluator shall generate 10 private/public key pairs using the key generatio "safe-prime" group that each protocol uses. - + - - - The TSF shall <refinement>perform</refinement> cryptographic <refinement>key - establishment</refinement> in accordance with a specified cryptographic key - <refinement>establishment</refinement> method: <selectables linebreak="yes"> - <selectable id="s-locked-rsa"><readable>RSA-based key establishment schemes</readable>[<htm:i>RSA-based key establishment schemes</htm:i>] that meet the following: [<htm:i>NIST Special Publication 800-56B, “Recommendation for Pair-Wise Key - Establishment Schemes Using Integer Factorization - Cryptography”</htm:i>]</selectable> - <selectable><readable>Elliptic curve-based key establishment schemes</readable>[<htm:i>Elliptic curve-based key establishment schemes</htm:i>] - that meet the following: <selectables linebreak="yes"> - <selectable id="s-locked-ecc-800-56A"><readable>Pair-Wise Key Establishment Schemes Using Discrete - Logarithm Cryptography</readable><refinement>NIST Special Publication 800-56A Revision 3, - "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete - Logarithm Cryptography"</refinement></selectable> - <selectable><refinement>RFC 7748, "Elliptic Curves for - Security"</refinement></selectable> - </selectables> - </selectable> - <selectable>[<htm:i>Finite field-based key establishment schemes</htm:i>] - that meet the following: [<htm:i>NIST Special Publication 800-56A Revision 3, - "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm - Cryptography"</htm:i>]</selectable> - </selectables> - <refinement>for the purposes of encrypting sensitive data received while the device is - locked.</refinement> - - The RSA-based key establishment schemes are described in - Section 9 of NIST SP 800-56B; however, Section 9 relies on implementation of other - sections in SP 800-56B. If the TOE acts as a receiver in the RSA key establishment - scheme, the TOE does not need to implement RSA key generation. The - elliptic curves used for the key establishment scheme must correlate with the curves - specified in FCS_CKM.1.1. The domain parameters used for the finite - field-based key establishment scheme are specified by the key generation according to - FCS_CKM.1.1. - - There are no TSS evaluation activities for this component. - There are no guidance evaluation activities for this component. - The test for SP800-56A Revision 3 and SP800-56B key establishment schemes is - performed in association with FCS_CKM.2/UNLOCKED. - Curve25519 Key Establishment Schemes The evaluator - shall verify a TOE's implementation of the key agreement scheme using the following - Function and Validity tests. These validation tests for each key agreement scheme - verify that a TOE has implemented the components of the key agreement scheme - according to the specification. These components include the calculation of the - shared secret K and the hash of K. - Function Test The Function test verifies the - ability of the TOE to implement the key agreement schemes correctly. To conduct this - test the evaluator shall generate or obtain test vectors from a known good - implementation of the TOE supported schemes. For each supported key agreement role - and hash function combination, the tester shall generate 10 sets of public keys. - These keys are static, ephemeral or both depending on the scheme being tested. - The evaluator shall obtain the shared secret value K, and the - hash of K. The evaluator shall verify the correctness of the TSF’s - implementation of a given scheme by using a known good implementation to calculate - the shared secret value K and compare the hash generated from this value. - Validity Test The Validity test verifies the - ability of the TOE to recognize another party’s valid and invalid key agreement - results. To conduct this test, the evaluator generates a set of 30 test vectors - consisting of data sets including the evaluator’s public keys and the TOE’s - public/private key pairs. The evaluator shall inject an error in - some of the test vectors to test that the TOE recognizes invalid key agreement - results caused by the following fields being incorrect: the shared secret value K or - the hash of K. At least two of the test vectors shall remain unmodified and - therefore should result in valid key agreement results (they should pass). - The TOE shall use these modified test vectors to emulate the key - agreement scheme using the corresponding parameters. The evaluator shall compare the - TOE’s results with the results using a known good implementation verifying that the - TOE detects these errors. - - - - - - - - This family defines requirements for management of cryptographic keys that are not addressed by FCS_CKM in CC Part 2. - - - - - - + + requires the TSF to implement a Root Encryption Key (REK). There are no management activities foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - - Generation of a REK. - + Generation of a REK. FCS_RBG_EXT.1 Random Bit Generation - - - The TSF shall support <selectables> - <selectable id="s-immutable-hardware">immutable hardware</selectable> - <selectable id="mutable_hardware">mutable hardware</selectable></selectables> REKs with a <selectables> - <selectable id="s-rek-sym">symmetric</selectable> - <selectable id="s-rek-asym">asymmetric</selectable></selectables> key of strength <selectables> - <selectable>112 bits</selectable> - <selectable id="s-rek-128">128 bits</selectable> - <selectable id="s-rek-192">192 bits</selectable> - <selectable id="s-rek-256">256 bits</selectable></selectables>. - The TSF shall support <assignable>description of REKs</assignable> - + The TSF shall support<selectables><selectable id="s-immutable-hardware" >immutable hardware</selectable><selectable id="mutable_hardware" >mutable hardware</selectable></selectables>REKs with a<selectables><selectable id="s-rek-sym" >symmetric</selectable><selectable id="s-rek-asym" >asymmetric</selectable></selectables>key of strength<selectables><selectable id="fcs_ckm_ext.1.1_1" >112 bits</selectable><selectable id="s-rek-128" >128 bits</selectable><selectable id="s-rek-192" >192 bits</selectable><selectable id="s-rek-256" >256 bits</selectable></selectables>. - Each REK shall be hardware-isolated from the OS on the TSF in runtime. + Each REK shall be hardware-isolated from the OS on the TSF in runtime. - Each REK shall be generated by an RBG in accordance with FCS_RBG_EXT.1. + Each REK shall be generated by an RBG in accordance with FCS_RBG_EXT.1. Either asymmetric or symmetric keys are allowed; the ST author makes the selection appropriate for the device. Symmetric keys must be of size 128 or 256 bits in order to correspond with FCS_COP.1/ENCRYPT. Asymmetric keys may be of any @@ -2610,10 +1061,10 @@ The evaluator shall generate 10 private/public key pairs using the key generatio The raw key material of "immutable hardware" REKs is computationally processed by hardware and software - cannot access the raw key material. Thus if + cannot access the raw key material. Thus if is selected in FCS_CKM_EXT.1.1 it implicitly meets FCS_CKM_EXT.7. - If is selected + If is selected in FCS_CKM_EXT.1.1, FCS_CKM_EXT.7 must be included in the ST. The @@ -2623,8 +1074,8 @@ The evaluator shall generate 10 private/public key pairs using the key generatio key container or may be an off-device RBG. If performed by an off-device RBG, the device manufacturer must not be able to access a REK after the manufacturing process has been completed. The Evaluation Activities for these two cases differ. - - The evaluator shall review the TSS to determine that a REK is supported by the + + The evaluator shall review the TSS to determine that a REK is supported by the TOE, that the TSS includes a description of the protection provided by the TOE for a REK, and that the TSS includes a description of the method of generation of a REK. The evaluator shall verify that the description of the protection @@ -2644,347 +1095,72 @@ The evaluator shall generate 10 private/public key pairs using the key generatio a description of the key derivation function and shall verify the key derivation uses an approved derivation mode and key expansion algorithm according to FCS_CKM_EXT.3.2. The evaluator shall verify that the generation - of a REK meets the FCS_RBG_EXT.1.1 and FCS_RBG_EXT.1.2 requirements: - - If REKs is/are generated on-device, the TSS shall include a description + of a REK meets the FCS_RBG_EXT.1.1 and FCS_RBG_EXT.1.2 requirements: If REKs is/are generated on-device, the TSS shall include a description of the generation mechanism including what triggers a generation, how the functionality described by FCS_RBG_EXT.1 is invoked, and whether a separate - instance of the RBG is used for REKs. - If REKs is/are generated off-device, the TSS shall include evidence that + instance of the RBG is used for REKs.If REKs is/are generated off-device, the TSS shall include evidence that the RBG meets FCS_RBG_EXT.1. This will likely necessitate a second set of RBG documentation equivalent to the documentation provided for the RBG Evaluation Activities. In addition, the TSS shall describe the manufacturing process that - prevents the device manufacturer from accessing any REKs. - + prevents the device manufacturer from accessing any REKs. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component. - - generation of a REKnone - + + + + generation of a REK + none + + + - - - requires the TSF to specify the mechanism it uses to generate Data Encryption Keys (DEKs). - There are no management activities foreseen. - There are no auditable events foreseen. - FCS_RBG_EXT.1 Random Bit Generation - - + + + requires the TSF to specify the mechanism it uses to generate Data Encryption Keys (DEKs). + There are no management activities foreseen. + There are no auditable events foreseen. + FCS_RBG_EXT.1 Random Bit Generation - All DEKs shall be <selectables> - <selectable>randomly generated</selectable> - <selectable> from the combination of a randomly generated DEK with another DEK or - salt in a way that preserves the effective entropy of each factor by <selectables> - <selectable>using an XOR operation</selectable> - <selectable> concatenating the keys and using a KDF (as described in SP - 800-108)</selectable> - <selectable id="s-dek-800-56">concatenating the keys and using a KDF (as described in SP - 800-56C)</selectable></selectables></selectable> - </selectables> with entropy corresponding to the security strength of AES key sizes of <selectables> - <selectable>128</selectable> - <selectable id="s-dek-256">256</selectable></selectables> bits. - - All DEKs shall be <assignable>generation mechanism</assignable> with entropy corresponding - to the security strength of AES key sizes of <assignable>number greater than 128 </assignable> bits. - - The intent of this requirement is to ensure that the DEK - cannot be recovered with less work than a full exhaust of the key space for AES. The - key generation capability of the TOE uses an RBG implemented on the TOE device - (FCS_RBG_EXT.1). Either 128-bit or 256-bit (or both) are allowed; the ST author makes - the selection appropriate for the device. A DEK is used in addition to the KEK so that - authentication factors can be changed without having to re-encrypt all of the user - data on the device. The ST author selects all applicable DEK - generation types implemented by the TOE. SP 800-56C specifies a two-step key derivation - procedure that employs an extraction-then-expansion technique for deriving keying - material from a shared secret generated during a key establishment scheme. The - Randomness Extraction step as described in Section 5 of SP 800-56C is followed by Key - Expansion using the key derivation functions defined in SP 800-108 (as described in - Section 6 of SP 800-56C). - - - - The evaluator shall ensure that the documentation of the product's encryption key - management is detailed enough that, after reading, the product's key management hierarchy is clear - and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure - that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as - separate proprietary evidence rather than being included in the TSS. - The evaluator shall also examine the key hierarchy section of the TSS to ensure that - the formation of all DEKs is described and that the key sizes match that described - by the ST author. The evaluator shall examine the key hierarchy section of the TSS - to ensure that each DEK is generated or combined from keys of equal or greater - security strength using one of the selected methods. - - - If the symmetric DEK is generated by an RBG, the evaluator shall review - the TSS to determine that it describes how the functionality described by - FCS_RBG_EXT.1 is invoked. The evaluator uses the description of the RBG - functionality in FCS_RBG_EXT.1 or documentation available for the operational - environment to determine that the key size being requested is greater than or - equal to the key size and mode to be used for the encryption/decryption of the - data. - If the DEK is formed from a combination, the evaluator shall verify that - the TSS describes the method of combination and that this method is either an - XOR or a KDF to justify that the effective entropy of each factor is preserved. - The evaluator shall also verify that each combined value was originally generated - from an Approved DRBG described in FCS_RBG_EXT.1. - If is selected, - the evaluator shall ensure the TSS includes a description of the - randomness extraction step. - The description must include how an approved untruncated MAC function is - being used for the randomness extraction step and the evaluator must verify the TSS - describes that the output length (in bits) of the MAC function is at least as large - as the targeted security strength (in bits) of the parameter set employed by the key - establishment scheme (see Tables 1-3 of SP 800-56C). The - description must include how the MAC function being used for the randomness - extraction step is related to the PRF used in the key expansion and verify the TSS - description includes the correct MAC function: - If an HMAC-hash is used in the randomness extraction step, then the same - HMAC-hash (with the same hash function hash) is used as the PRF in the key - expansion step. - If an AES-CMAC (with key length 128, 192, or 256 bits) is used in the - randomness extraction step, then AES-CMAC with a 128-bit key is used as the PRF - in the key expansion step. - The description must include the lengths of the salt values being used in - the randomness extraction step and the evaluator shall verify the TSS - description includes correct salt lengths: - If an HMAC-hash is being used as the MAC, the salt length can be any value - up to the maximum bit length permitted for input to the hash function - hash. - If an AES-CMAC is being used as the MAC, the salt length shall be the same - length as the AES key (i.e. 128, 192, or 256 bits). - (conditional) If a KDF is used, the evaluator shall ensure that the TSS - includes a description of the key derivation function and shall verify the key - derivation uses an approved derivation mode and key expansion algorithm according to - SP 800-108 or SP 800-56C. - - The evaluator uses the description of the RBG functionality in - FCS_RBG_EXT.1 or documentation available for the operational environment to - determine that the key size being generated or combined is identical to the key size - and mode to be used for the encryption/decryption of the - data. - If a KDF is used, the evaluator shall perform one or more of the following - tests to verify the correctness of the key derivation function, depending on the - modes that are supported. maps the data fields to the - notations used in SP 800-108 and SP 800-56C. - - : Notations used in SP 800-108 and SP - 800-56C - - - Data FieldsNotations - - SP 800-108SP - 800-56C - Pseudorandom - functionPRFPRF - Counter - lengthrr - Length of output of - PRFhh - Length of derived keying - materialLL - Length of input valuesl lengthl - length - Pseudorandom input values IK1 (key derivation - key)Z (shared secret) - Pseudorandom salt - valuesn/as - Randomness extraction - MACn/aMAC - - - Counter Mode Tests: The evaluator shall determine - the following characteristics of the key derivation function: - One or more pseudorandom functions that are supported by the - implementation (PRF). - One or more of the values {8, 16, 24, 32} that equal the length of the - binary representation of the counter (r). - The length (in bits) of the output of the PRF (h). - Minimum and maximum values for the length (in bits) of the derived keying - material (L). These values can be equal if only one value of L is supported. - These must be evenly divisible by h. - Up to two values of L that are NOT evenly divisible by h. - Location of the counter relative to fixed input data: before, after, or in - the middle. - - Counter before fixed input data: fixed input data string length (in - bytes), fixed input data string value. - Counter after fixed input data: fixed input data string length (in - bytes), fixed input data string value. - Counter in the middle of fixed input data: length of data before - counter (in bytes), length of data after counter (in bytes), value of string - input before counter, value of string input after counter. - - The length (I_length) of the input values I. - For each supported combination of I_length, MAC, salt, PRF, counter - location, value of r, and value of L, the evaluator shall generate 10 test vectors - that include pseudorandom input values I, and pseudorandom salt values. If there is - only one value of L that is evenly divisible by h, the evaluator shall generate 20 - test vectors for it. For each test vector, the evaluator shall supply this data to - the TOE in order to produce the keying material output. The - results from each test may either be obtained by the evaluator directly or by - supplying the inputs to the implementer and receiving the results in response. To - determine correctness, the evaluator shall compare the resulting values to those - obtained by submitting the same inputs to a known good implementation. - Feedback Mode Tests: The evaluator shall determine - the following characteristics of the key derivation function: - One or more pseudorandom functions that are supported by the - implementation (PRF). - The length (in bits) of the output of the PRF (h). - Minimum and maximum values for the length (in bits) of the derived keying - material (L). These values can be equal if only one value of L is supported. - These must be evenly divisible by h. - Up to two values of L that are NOT evenly divisible by h. - Whether or not zero-length IVs are supported. - Whether or not a counter is used, and if so: - - One or more of the values {8, 16, 24, 32} that equal the length of the - binary representation of the counter (r). - Location of the counter relative to fixed input data: before, after, or - in the middle. - - Counter before fixed input data: fixed input data string length (in - bytes), fixed input data string value. - Counter after fixed input data: fixed input data string length (in - bytes), fixed input data string value. - Counter in the middle of fixed input data: length of data before - counter (in bytes), length of data after counter (in bytes), value of string - input before counter, value of string input after counter. - - - The length (I_length) of the input values I. - For each supported combination of I_length, MAC, salt, PRF, counter - location (if a counter is used), value of r (if a counter is used), and value of L, - the evaluator shall generate 10 test vectors that include pseudorandom input values - I and pseudorandom salt values. If the KDF supports zero-length IVs, five of these - test vectors will be accompanied by pseudorandom IVs and the other five will use - zero-length IVs. If zero-length IVs are not supported, each test vector will be - accompanied by an pseudorandom IV. If there is only one value of L that is evenly - divisible by h, the evaluator shall generate 20 test vectors for - it. For each test vector, the evaluator shall supply this data to - the TOE in order to produce the keying material output. The results from each test - may either be obtained by the evaluator directly or by supplying the inputs to the - implementer and receiving the results in response. To determine correctness, the - evaluator shall compare the resulting values to those obtained by submitting the - same inputs to a known good implementation. - Double Pipeline Iteration Mode Tests: The - evaluator shall determine the following characteristics of the key derivation - function: - One or more pseudorandom functions that are supported by the - implementation (PRF). - The length (in bits) of the output of the PRF (h). - Minimum and maximum values for the length (in bits) of the derived keying - material (L). These values can be equal if only one value of L is supported. - These must be evenly divisible by h. - Up to two values of L that are NOT evenly divisible by h. - Whether or not a counter is used, and if so: - - One or more of the values {8, 16, 24, 32} that equal the length of the - binary representation of the counter (r). - Location of the counter relative to fixed input data: before, after, or - in the middle. - - Counter before fixed input data: fixed input data string length (in - bytes), fixed input data string value. - Counter after fixed input data: fixed input data string length (in - bytes), fixed input data string value. - Counter in the middle of fixed input data: length of data before - counter (in bytes), length of data after counter (in bytes), value of string - input before counter, value of string input after counter. - - - The length (I_length) of the input values I. - For each supported combination of I_length, MAC, salt, PRF, counter - location (if a counter is used), value of r (if a counter is used), and value of L, - the evaluator shall generate 10 test vectors that include pseudorandom input values - I, and pseudorandom salt values. If there is only one value of L that is evenly - divisible by h, the evaluator shall generate 20 test vectors for - it. For each test vector, the evaluator shall supply this data to - the TOE in order to produce the keying material output. The results from each test - may either be obtained by the evaluator directly or by supplying the inputs to the - implementer and receiving the results in response. To determine correctness, the - evaluator shall compare the resulting values to those obtained by submitting the - same inputs to a known good implementation. - + All DEKs shall be<selectables><selectable id="fcs_ckm_ext.2.1_1" >randomly generated</selectable><selectable id="fcs_ckm_ext.2.1_2"> from the combination of a randomly generated DEK with another DEK or salt in a way that preserves the effective entropy of each factor by <selectables><selectable id="fcs_ckm_ext.2.1_3" >using an XOR operation</selectable><selectable id="fcs_ckm_ext.2.1_4" > concatenating the keys and using a KDF (as described in SP + 800-108)</selectable><selectable id="s-dek-800-56" >concatenating the keys and using a KDF (as described in SP + 800-56C)</selectable></selectables></selectable></selectables>with entropy corresponding to the security strength of AES key sizes of<selectables><selectable id="fcs_ckm_ext.2.1_5" >128</selectable><selectable id="s-dek-256" >256</selectable></selectables>bits. + The intent of this requirement is to ensure that the DEK cannot be recovered with less work than a full exhaust of the key space for AES. The key generation capability of the TOE uses an RBG implemented on the TOE device (FCS_RBG_EXT.1). Either 128-bit or 256-bit (or both) are allowed; the ST author makes the selection appropriate for the device. A DEK is used in addition to the KEK so that authentication factors can be changed without having to re-encrypt all of the user data on the device.The ST author selects all applicable DEK generation types implemented by the TOE.SP 800-56C specifies a two-step key derivation procedure that employs an extraction-then-expansion technique for deriving keying material from a shared secret generated during a key establishment scheme. The Randomness Extraction step as described in Section 5 of SP 800-56C is followed by Key Expansion using the key derivation functions defined in SP 800-108 (as described in Section 6 of SP 800-56C). + + The evaluator shall ensure that the documentation of the product's encryption key management is detailed enough that, after reading, the product's key management hierarchy is clear and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as separate proprietary evidence rather than being included in the TSS.The evaluator shall also examine the key hierarchy section of the TSS to ensure that the formation of all DEKs is described and that the key sizes match that described by the ST author. The evaluator shall examine the key hierarchy section of the TSS to ensure that each DEK is generated or combined from keys of equal or greater security strength using one of the selected methods.
  • If the symmetric DEK is generated by an RBG, the evaluator shall review the TSS to determine that it describes how the functionality described by FCS_RBG_EXT.1 is invoked. The evaluator uses the description of the RBG functionality in FCS_RBG_EXT.1 or documentation available for the operational environment to determine that the key size being requested is greater than or equal to the key size and mode to be used for the encryption/decryption of the data.
  • If the DEK is formed from a combination, the evaluator shall verify that the TSS describes the method of combination and that this method is either an XOR or a KDF to justify that the effective entropy of each factor is preserved. The evaluator shall also verify that each combined value was originally generated from an Approved DRBG described in FCS_RBG_EXT.1.
  • If is selected, the evaluator shall ensure the TSS includes a description of the randomness extraction step.The description must include how an approved untruncated MAC function is being used for the randomness extraction step and the evaluator must verify the TSS describes that the output length (in bits) of the MAC function is at least as large as the targeted security strength (in bits) of the parameter set employed by the key establishment scheme (see Tables 1-3 of SP 800-56C).The description must include how the MAC function being used for the randomness extraction step is related to the PRF used in the key expansion and verify the TSS description includes the correct MAC function:
  • If an HMAC-hash is used in the randomness extraction step, then the same HMAC-hash (with the same hash function hash) is used as the PRF in the key expansion step.
  • If an AES-CMAC (with key length 128, 192, or 256 bits) is used in the randomness extraction step, then AES-CMAC with a 128-bit key is used as the PRF in the key expansion step.
  • The description must include the lengths of the salt values being used in the randomness extraction step and the evaluator shall verify the TSS description includes correct salt lengths:
  • If an HMAC-hash is being used as the MAC, the salt length can be any value up to the maximum bit length permitted for input to the hash function hash.
  • If an AES-CMAC is being used as the MAC, the salt length shall be the same length as the AES key (i.e. 128, 192, or 256 bits).(conditional) If a KDF is used, the evaluator shall ensure that the TSS includes a description of the key derivation function and shall verify the key derivation uses an approved derivation mode and key expansion algorithm according to SP 800-108 or SP 800-56C. + The evaluator uses the description of the RBG functionality in FCS_RBG_EXT.1 or documentation available for the operational environment to determine that the key size being generated or combined is identical to the key size and mode to be used for the encryption/decryption of the data. + If a KDF is used, the evaluator shall perform one or more of the following tests to verify the correctness of the key derivation function, depending on the modes that are supported. maps the data fields to the notations used in SP 800-108 and SP 800-56C.Table 4: Notations used in SP 800-108 and SP 800-56C

    Data Fields

    Notations

    SP 800-108

    SP 800-56C

    Pseudorandom function

    PRF

    PRF

    Counter length

    r

    r

    Length of output of PRF

    h

    h

    Length of derived keying material

    L

    L

    Length of input values

    l length

    l length

    Pseudorandom input values I

    K1 (key derivation key)

    Z (shared secret)

    Pseudorandom salt values

    n/a

    s

    Randomness extraction MAC

    n/a

    MAC

    Counter Mode Tests:The evaluator shall determine the following characteristics of the key derivation function:
  • One or more pseudorandom functions that are supported by the implementation (PRF).
  • One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r).
  • The length (in bits) of the output of the PRF (h).
  • Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h.
  • Up to two values of L that are NOT evenly divisible by h.
  • Location of the counter relative to fixed input data: before, after, or in the middle.
  • Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value.
  • Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value.
  • Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter.
  • The length (I_length) of the input values I.For each supported combination of I_length, MAC, salt, PRF, counter location, value of r, and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it. For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output.The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. Feedback Mode Tests:The evaluator shall determine the following characteristics of the key derivation function:
  • One or more pseudorandom functions that are supported by the implementation (PRF).
  • The length (in bits) of the output of the PRF (h).
  • Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h.
  • Up to two values of L that are NOT evenly divisible by h.
  • Whether or not zero-length IVs are supported.
  • Whether or not a counter is used, and if so:
  • One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r).
  • Location of the counter relative to fixed input data: before, after, or in the middle.
  • Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value.
  • Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value.
  • Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter.
  • The length (I_length) of the input values I.For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I and pseudorandom salt values. If the KDF supports zero-length IVs, five of these test vectors will be accompanied by pseudorandom IVs and the other five will use zero-length IVs. If zero-length IVs are not supported, each test vector will be accompanied by an pseudorandom IV. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it.For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. Double Pipeline Iteration Mode Tests:The evaluator shall determine the following characteristics of the key derivation function:
  • One or more pseudorandom functions that are supported by the implementation (PRF).
  • The length (in bits) of the output of the PRF (h).
  • Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h.
  • Up to two values of L that are NOT evenly divisible by h.
  • Whether or not a counter is used, and if so:
  • One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r).
  • Location of the counter relative to fixed input data: before, after, or in the middle.
  • Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value.
  • Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value.
  • Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter.
  • The length (I_length) of the input values I.For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it.For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. - + - - + + requires the TSF to generate and manage the strength of Key Encryption Keys (KEKs). There are no management activities foreseen. There are no auditable events foreseen. - FCS_CKM.1 Cryptographic Key Generation - FCS_COP.1 Cryptographic Operation - FCS_RBG_EXT.1 Random Bit Generation - - - + FCS_CKM.1 Cryptographic Key Generation + FCS_COP.1 Cryptographic Operation + FCS_RBG_EXT.1 Random Bit Generation - The TSF shall use <selectables> - <selectable id="s-kek-asym"><snip>asymmetric KEKs</snip> of <assignable id="a-kek-asym-size">security strength greater than or equal - to 112 bits</assignable> security strength</selectable> - <selectable id="s-kek-sym"><snip>symmetric KEKs</snip> of <selectables> - <selectable>128-bit</selectable> - <selectable id="s-kek-sym-256">256-bit</selectable></selectables> security strength corresponding to at least the security strength - of the keys encrypted by the KEK</selectable> - </selectables>. - - The TSF shall use <assignable>description of KEKs</assignable>. - + The TSF shall use<selectables><selectable id="s-kek-asym"> <snip>asymmetric KEKs</snip> of <assignable>security strength greater than or equal to 112 bits </assignable> security strength</selectable><selectable id="s-kek-sym"> <snip>symmetric KEKs</snip> of <selectables><selectable id="fcs_ckm_ext.3.1_2" >128-bit</selectable><selectable id="s-kek-sym-256" >256-bit</selectable></selectables> security strength corresponding to at least the security strength of the keys encrypted by the KEK</selectable></selectables>. The ST author selects all applicable KEK types implemented by the TOE. - The TSF shall generate all KEKs using one of the following methods: - <htm:ul><htm:li>Derive the KEK from a Password Authentication Factor according to - FCS_COP.1.1<htm:b>/CONDITION</htm:b> and </htm:li></htm:ul> - <selectables linebreak="yes"> - <selectable>Generate the KEK using an RBG that meets this profile (as specified in - FCS_RBG_EXT.1)</selectable> - <selectable>Generate the KEK using a key generation scheme that meets this profile - (as specified in FCS_CKM.1)</selectable> - <selectable>Combine the KEK from other KEKs in a way that preserves the effective - entropy of each factor by <selectables> - <selectable>using an XOR operation</selectable> - <selectable>concatenating the keys and using a KDF (as described in SP - 800-108)</selectable> - <selectable>concatenating the keys and using a KDF (as described in SP - 800-56C)</selectable> - <selectable>encrypting one key with another</selectable></selectables> - </selectable> - </selectables>. - - The TSF shall generate all KEKs using one of the following methods: - <htm:ul><htm:li>Derive the KEK from a Password Authentication Factor according to - FCS_COP.1.1 and </htm:li></htm:ul> - <selectables linebreak="yes"> - <selectable>Generate the KEK using an RBG that meets this profile (as specified in - FCS_RBG_EXT.1)</selectable> - <selectable>Generate the KEK using a key generation scheme that meets this profile - (as specified in FCS_CKM.1)</selectable> - <selectable>Combine the KEK from other KEKs in a way that preserves the effective - entropy of each factor by <selectables> - <selectable>using an XOR operation</selectable> - <selectable>concatenating the keys and using a KDF (as described in SP - 800-108)</selectable> - <selectable>concatenating the keys and using a KDF (as described in SP - 800-56C)</selectable> - <selectable>encrypting one key with another</selectable> - </selectables> - </selectable> - </selectables>. - + The TSF shall generate all KEKs using one of the following methods: <htm:ul><htm:li>Derive the KEK from a Password Authentication Factor according to + FCS_COP.1.1<htm:b>/CONDITION</htm:b> and </htm:li></htm:ul><selectables><selectable id="fcs_ckm_ext.3.2_1" >Generate the KEK using an RBG that meets this profile (as specified in + FCS_RBG_EXT.1)</selectable><selectable id="fcs_ckm_ext.3.2_2" >Generate the KEK using a key generation scheme that meets this profile + (as specified in FCS_CKM.1)</selectable><selectable id="fcs_ckm_ext.3.2_3">Combine the KEK from other KEKs in a way that preserves the effective entropy of each factor by <selectables><selectable id="fcs_ckm_ext.3.2_4" >using an XOR operation</selectable><selectable id="fcs_ckm_ext.3.2_5" >concatenating the keys and using a KDF (as described in SP + 800-108)</selectable><selectable id="fcs_ckm_ext.3.2_6" >concatenating the keys and using a KDF (as described in SP + 800-56C)</selectable><selectable id="fcs_ckm_ext.3.2_7" >encrypting one key with another</selectable></selectables></selectable></selectables>. The conditioning of passwords is performed in accordance with FCS_COP.1/CONDITION. It is expected that key generation derived from conditioning, using an RBG or generation scheme, and through combination, will each be necessary to meet the requirements set out in this document. In particular, - has KEKs of each type: KEK_3 is generated, KEK_1 is derived - from a Password Authentication Factor, and KEK_2 is combined from two KEKs. In , KEK_3 may either be a symmetric key generated from an RBG or an + has KEKs of each type: KEK_3 is generated, KEK_1 is derived + from a Password Authentication Factor, and KEK_2 is combined from two KEKs. In , KEK_3 may either be a symmetric key generated from an RBG or an asymmetric key generated using a key generation scheme according to FCS_CKM.1. If combined, the ST author should describe which method of combination is used in order to justify that the effective entropy of each factor is @@ -2994,8 +1170,8 @@ The evaluator shall generate 10 private/public key pairs using the key generatio step as described in Section 5 of SP 800-56C is followed by Key Expansion using the key derivation functions defined in SP 800-108 (as described in Section 6 of SP 800-56C). - - The evaluator shall examine the key hierarchy section of the TSS to ensure that + + The evaluator shall examine the key hierarchy section of the TSS to ensure that the formation of all KEKs are described and that the key sizes match that described by the ST author. The evaluator shall examine the key hierarchy section of the TSS to ensure that each key (DEKs, software-based key storage, and KEKs) is encrypted by @@ -3022,97 +1198,53 @@ The evaluator shall generate 10 private/public key pairs using the key generatio ensure that the TSS includes a description of the key derivation function and shall verify the key derivation uses an approved derivation mode and key expansion algorithm according to SP 800-108. (conditional) If - is selected, + is selected, the evaluator shall ensure the TSS includes a description of the randomness - extraction step. The description must include - How an approved untruncated MAC function is being used for the randomness + extraction step. The description must include How an approved untruncated MAC function is being used for the randomness extraction step and the evaluator must verify the TSS describes that the output length (in bits) of the MAC function is at least as large as the targeted security strength (in bits) of the parameter set employed by the key - establishment scheme (see Tables 1-3 of SP 800-56C). - How the MAC function being used for the randomness extraction step is + establishment scheme (see Tables 1-3 of SP 800-56C).How the MAC function being used for the randomness extraction step is related to the PRF used in the key expansion and verify the TSS description - includes the correct MAC function: - - If an HMAC-hash is used in the randomness extraction step, then the same + includes the correct MAC function:If an HMAC-hash is used in the randomness extraction step, then the same HMAC-hash (with the same hash function hash) is used as the PRF in the key - expansion step. - If an AES-CMAC (with key length 128, 192, or 256 bits) is used in the + expansion step.If an AES-CMAC (with key length 128, 192, or 256 bits) is used in the randomness extraction step, then AES-CMAC with a 128-bit key is used as the - PRF in the key expansion step. - - The lengths of the salt values being used in the randomness extraction + PRF in the key expansion step.The lengths of the salt values being used in the randomness extraction step and the evaluator shall verify the TSS description includes correct salt - lengths: - - If an HMAC-hash is being used as the MAC, the salt length can be any + lengths:If an HMAC-hash is being used as the MAC, the salt length can be any value up to the maximum bit length permitted for input to the hash function - hash. - If an AES-CMAC is being used as the MAC, the salt length shall be the - same length as the AES key (i.e. 128, 192, or 256 bits). - - + hash.If an AES-CMAC is being used as the MAC, the salt length shall be the + same length as the AES key (i.e. 128, 192, or 256 bits). The evaluator shall also ensure that the documentation of the product's encryption key management is detailed enough that, after reading, the product's key management hierarchy is clear and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as - separate proprietary evidence rather than being included in the TSS. - + separate proprietary evidence rather than being included in the TSS. There are no guidance evaluation activities for this component. If a KDF is used, the evaluator shall perform one or more of the following tests to verify the correctness of the key derivation function, depending on the - modes that are supported. maps the data fields to the - notations used in SP 800-108 and SP 800-56C. - - : Notations used in SP 800-108 and SP 800-56C - - - Data FieldsNotations - SP 800-108SP - 800-56C - Pseudorandom - functionPRFPRF - Counter - lengthrr - Length of output of - PRFhh - Length of derived keying - materialLL - Length of input - valuesI_lengthI_length - Pseudorandom input values IK1 - (key derivation key)Z (shared secret) - Pseudorandom salt - valuesn/as - Randomness extraction - MACn/aMAC - - - Counter Mode Tests: - The evaluator shall determine the following characteristics of - the key derivation function: - One or more pseudorandom functions that are supported by the - implementation (PRF). - One or more of the values {8, 16, 24, 32} that equal the length of the - binary representation of the counter (r). - The length (in bits) of the output of the PRF (h). - Minimum and maximum values for the length (in bits) of the derived keying + modes that are supported. maps the data fields to the + notations used in SP 800-108 and SP 800-56C. : Notations used in SP 800-108 and SP 800-56C Data FieldsNotationsSP 800-108SP + 800-56CPseudorandom + functionPRFPRFCounter + lengthrrLength of output of + PRFhhLength of derived keying + materialLLLength of input + valuesI_lengthI_lengthPseudorandom input values IK1 + (key derivation key)Z (shared secret)Pseudorandom salt + valuesn/asRandomness extraction + MACn/aMACCounter Mode Tests: The evaluator shall determine the following characteristics of + the key derivation function:One or more pseudorandom functions that are supported by the + implementation (PRF).One or more of the values {8, 16, 24, 32} that equal the length of the + binary representation of the counter (r).The length (in bits) of the output of the PRF (h).Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. - These must be evenly divisible by h. - Up to two values of L that are NOT evenly divisible by h. - Location of the counter relative to fixed input data: before, after, or in - the middle. - Counter before fixed input data: fixed input data string length (in - bytes), fixed input data string value. - Counter after fixed input data: fixed input data string length (in - bytes), fixed input data string value. - Counter in the middle of fixed input data: length of data before + These must be evenly divisible by h.Up to two values of L that are NOT evenly divisible by h.Location of the counter relative to fixed input data: before, after, or in + the middle.Counter before fixed input data: fixed input data string length (in + bytes), fixed input data string value.Counter after fixed input data: fixed input data string length (in + bytes), fixed input data string value.Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string - input before counter, value of string input after counter. - - The length (I_length) of the input values I. - For each supported combination of I_length, MAC, salt, PRF, + input before counter, value of string input after counter.The length (I_length) of the input values I. For each supported combination of I_length, MAC, salt, PRF, counter location, value of r, and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the evaluator shall @@ -3122,36 +1254,17 @@ The evaluator shall generate 10 private/public key pairs using the key generatio evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good - implementation. - Feedback Mode Tests: - The evaluator shall determine the following characteristics of the key - derivation function: - One or more pseudorandom functions that are supported by the - implementation (PRF). - The length (in bits) of the output of the PRF (h). - Minimum and maximum values for the length (in bits) of the derived keying + implementation. Feedback Mode Tests: The evaluator shall determine the following characteristics of the key + derivation function:One or more pseudorandom functions that are supported by the + implementation (PRF).The length (in bits) of the output of the PRF (h).Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. - These must be evenly divisible by h. - Up to two values of L that are NOT evenly divisible by h. - Whether or not zero-length IVs are supported. - Whether or not a counter is used, and if so: - One or more of the values {8, 16, 24, 32} that equal the length of the - binary representation of the counter (r). - Location of the counter relative to fixed input data: before, after, - or in the middle. - - Counter before fixed input data: fixed input data string length (in - bytes), fixed input data string value. - Counter after fixed input data: fixed input data string length (in - bytes), fixed input data string value. - Counter in the middle of fixed input data: length of data before + These must be evenly divisible by h.Up to two values of L that are NOT evenly divisible by h.Whether or not zero-length IVs are supported.Whether or not a counter is used, and if so: One or more of the values {8, 16, 24, 32} that equal the length of the + binary representation of the counter (r).Location of the counter relative to fixed input data: before, after, + or in the middle.Counter before fixed input data: fixed input data string length (in + bytes), fixed input data string value.Counter after fixed input data: fixed input data string length (in + bytes), fixed input data string value.Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of - string input before counter, value of string input after counter. - - - - The length (I_length) of the input values I. - For each supported combination of I_length, MAC, salt, PRF, + string input before counter, value of string input after counter.The length (I_length) of the input values I. For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I and pseudorandom salt values. If the KDF supports zero-length IVs, @@ -3164,35 +1277,18 @@ The evaluator shall generate 10 private/public key pairs using the key generatio may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the - same inputs to a known good implementation. - Double Pipeline Iteration Mode Tests: The evaluator shall - determine the following characteristics of the key derivation function: - One or more pseudorandom functions that are supported by the - implementation (PRF). - The length (in bits) of the output of the PRF (h). - Minimum and maximum values for the length (in bits) of the derived keying + same inputs to a known good implementation.Double Pipeline Iteration Mode Tests: The evaluator shall + determine the following characteristics of the key derivation function:One or more pseudorandom functions that are supported by the + implementation (PRF).The length (in bits) of the output of the PRF (h).Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. - These must be evenly divisible by h. - Up to two values of L that are NOT evenly divisible by h. - Whether or not a counter is used, and if so: - One or more of the values {8, 16, 24, 32} that equal the length of the - binary representation of the counter (r). - Location of the counter relative to fixed input data: before, after, - or in the middle. - Counter before fixed input data: fixed input data string length - (in bytes), fixed input data string value. - Counter after fixed input data: fixed input data string length (in - bytes), fixed input data string value. - Counter in the middle of fixed input data: length of data before + These must be evenly divisible by h.Up to two values of L that are NOT evenly divisible by h.Whether or not a counter is used, and if so:One or more of the values {8, 16, 24, 32} that equal the length of the + binary representation of the counter (r).Location of the counter relative to fixed input data: before, after, + or in the middle. Counter before fixed input data: fixed input data string length + (in bytes), fixed input data string value.Counter after fixed input data: fixed input data string length (in + bytes), fixed input data string value.Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after - counter. - - - - - The length (I_length) of the input values I. - For each supported combination of I_length, MAC, salt, PRF, + counter.The length (I_length) of the input values I. For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that @@ -3205,46 +1301,26 @@ The evaluator shall generate 10 private/public key pairs using the key generatio same inputs to a known good implementation. - + - - + + requires the TSF to be able to follow specified rules to destroy plaintext keying material and cryptographic keys when no longer needed. There are no management activities foreseen. There are no auditable events foreseen. FCS_RBG_EXT.1 Random Bit Generation - - - The TSF shall destroy cryptographic keys in accordance with the specified cryptographic key destruction methods: <htm:br/> - <htm:ul> - <htm:li>By clearing the KEK encrypting the target key</htm:li> - <htm:li>In accordance with the following rules - <htm:ul><htm:li> For volatile memory, the destruction shall be executed by a single direct overwrite <selectables> - <selectable>consisting of a pseudorandom pattern using the TSF’s - RBG</selectable> - <selectable>consisting of zeros</selectable></selectables>.</htm:li> - <htm:li>For non-volatile EEPROM, the destruction shall be executed by a single + <title>The TSF shall destroy cryptographic keys in accordance with the specified cryptographic key destruction methods: <htm:ul><htm:li>By clearing the KEK encrypting the target key</htm:li><htm:li>In accordance with the following rules + <htm:ul><htm:li> For volatile memory, the destruction shall be executed by a single direct overwrite <selectables><selectable id="fcs_ckm_ext.4.1_1" >consisting of a pseudorandom pattern using the TSF’s + RBG</selectable><selectable id="fcs_ckm_ext.4.1_2" >consisting of zeros</selectable></selectables>.</htm:li><htm:li>For non-volatile EEPROM, the destruction shall be executed by a single direct overwrite consisting of a pseudo random pattern using the TSF’s RBG (as - specified in FCS_RBG_EXT.1), followed by a read-verify.</htm:li> - <htm:li>For non-volatile flash memory, that is not wear-leveled, the destruction - shall be executed <selectables> - <selectable>by a single direct overwrite consisting of zeros followed by a - read-verify</selectable> - <selectable>by a block erase that erases the reference to memory that stores - data as well as the data itself </selectable> - </selectables>.</htm:li> - <htm:li>For non-volatile flash memory, that is wear-leveled, the destruction - shall be executed <selectables> - <selectable>by a single direct overwrite consisting of zeros</selectable> - <selectable>by a block erase</selectable></selectables>.</htm:li> - <htm:li>For non-volatile memory other than EEPROM and flash, the destruction + specified in FCS_RBG_EXT.1), followed by a read-verify.</htm:li><htm:li>For non-volatile flash memory, that is not wear-leveled, the destruction + shall be executed <selectables><selectable id="fcs_ckm_ext.4.1_3" >by a single direct overwrite consisting of zeros followed by a + read-verify</selectable><selectable id="fcs_ckm_ext.4.1_4" >by a block erase that erases the reference to memory that stores + data as well as the data itself </selectable></selectables>.</htm:li><htm:li>For non-volatile flash memory, that is wear-leveled, the destruction + shall be executed <selectables><selectable id="fcs_ckm_ext.4.1_5" >by a single direct overwrite consisting of zeros</selectable><selectable id="fcs_ckm_ext.4.1_6" >by a block erase</selectable></selectables>.</htm:li><htm:li>For non-volatile memory other than EEPROM and flash, the destruction shall be executed by a single direct overwrite with a random pattern that is - changed before each write.</htm:li> - </htm:ul> - </htm:li> - </htm:ul> - + changed before each write. The clearing indicated above applies to each intermediate storage area for plaintext key or cryptographic critical security parameter (i.e. any storage, such as memory buffers, that is included in the path of such data) upon the @@ -3254,22 +1330,10 @@ The evaluator shall generate 10 private/public key pairs using the key generatio written to volatile memory. - The TSF shall destroy all plaintext keying material and critical security - parameters when no longer needed. + The TSF shall destroy all plaintext keying material and critical security parameters when no longer needed. For the purposes of this requirement, plaintext keying material refers to authentication data, passwords, secret/private symmetric keys, private asymmetric keys, data used to derive keys, values derived from passwords, etc. - - Key destruction procedures are performed in accordance with FCS_CKM_EXT.4.1. There are multiple situations in which plaintext keying material is no longer necessary, including when the TOE is powered off, when @@ -3277,7 +1341,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio material is no longer needed by the trusted channel per the protocol, and when transitioning to the locked state (for those values derived from the Password Authentication Factor or that key material which is protected by the password-derived - or biometric-unlocked KEK according to FCS_STG_EXT.2 – see ). + or biometric-unlocked KEK according to FCS_STG_EXT.2 – see ). For keys (or key material used to derive those keys) protecting sensitive data received in the locked state, "no longer needed" includes "while in the locked state." Trusted channels may include TLS, HTTPS, DTLS, IPsec VPNs, @@ -3287,8 +1351,8 @@ The evaluator shall generate 10 private/public key pairs using the key generatio same Application Processor as the OS, REK key material must be cleared from RAM immediately after use, and at least, must be wiped when the device is locked, as the REK is part of the key hierarchy protecting sensitive data. - - The evaluator shall check to ensure the TSS lists each type of plaintext key + + The evaluator shall check to ensure the TSS lists each type of plaintext key material (DEKs, software-based key storage, KEKs, trusted channel keys, passwords, etc.) and its generation and storage location. The evaluator shall verify that the TSS describes when each type of key material is cleared (for @@ -3300,145 +1364,72 @@ The evaluator shall generate 10 private/public key pairs using the key generatio (cryptographic erase, overwrite with zeros, overwrite with random pattern, or block erase) is listed. If different types of memory are used to store the materials to be protected, the evaluator shall check to ensure that the TSS describes the clearing - procedure in terms of the memory in which the data are stored. - + procedure in terms of the memory in which the data are stored. There are no guidance evaluation activities for this component. - Evaluation Activity Note: The following tests require the developer to - provide access to a test platform that provides the evaluator with tools that are - typically not found on factory products. For each software and - firmware key clearing situation (including on system power off, on wipe function, on - disconnection of trusted channels, when no longer needed by the trusted channel per - the protocol, when transitioning to the locked state, and possibly including - immediately after use, while in the locked state) the evaluator shall repeat the - following tests. For these tests the evaluator shall utilize - appropriate development environment (e.g. a Virtual Machine) and development tools - (debuggers, simulators, etc.) to test that keys are cleared, including all copies of - the key that may have been created internally by the TOE during normal cryptographic - processing with that key. Applied to each key held as plaintext in volatile memory and subject to destruction by overwrite by the TOE (whether or not the plaintext value is subsequently encrypted for storage in volatile or non-volatile memory). In the case where the only selection made for the destruction method key was removal of - power, then this test is unnecessary. The evaluator shall: - - Record the value of the key in the TOE subject to clearing. - Cause the TOE to perform a normal cryptographic processing with the - key from Step #1. - Cause the TOE to clear the key. - Cause the TOE to stop the execution but not exit. - Cause the TOE to dump the entire memory of the TOE into a binary - file. - Search the content of the binary file created in Step #5 for instances - of the known key value from Step #1. - Break the key value from Step #1 into 3 similar sized pieces and - perform a search using each piece. - - Steps 1-6 ensure that the complete key does not exist anywhere in + power, then this test is unnecessary. The evaluator shall: Record the value of the key in the TOE subject to clearing.Cause the TOE to perform a normal cryptographic processing with the + key from Step #1.Cause the TOE to clear the key.Cause the TOE to stop the execution but not exit.Cause the TOE to dump the entire memory of the TOE into a binary + file.Search the content of the binary file created in Step #5 for instances + of the known key value from Step #1.Break the key value from Step #1 into 3 similar sized pieces and + perform a search using each piece. Steps 1-6 ensure that the complete key does not exist anywhere in volatile memory. If a copy is found, then the test fails. Step 7 ensures that partial key fragments do not remain in memory. If a fragment is found, there is a minuscule chance that it is not within the context of a key (e.g., some random bits that happen to match). If this is the case the test should be repeated with a different key in Step #1. If a fragment is found the - test fails. - + test fails. Applied to each key held in non-volatile memory and subject to destruction by overwrite by the TOE. The evaluator shall use special tools (as needed), - provided by the TOE developer if necessary, to view the key storage location: - - Record the value of the key in the TOE subject to clearing. - Cause the TOE to perform a normal cryptographic processing with the - key from Step #1. - Cause the TOE to clear the key. - Search the non-volatile memory the key was stored in for instances of + provided by the TOE developer if necessary, to view the key storage location: Record the value of the key in the TOE subject to clearing.Cause the TOE to perform a normal cryptographic processing with the + key from Step #1.Cause the TOE to clear the key.Search the non-volatile memory the key was stored in for instances of the known key value from Step #1. If a copy is found, then the test - fails. - Break the key value from Step #1 into 3 similar sized pieces and + fails.Break the key value from Step #1 into 3 similar sized pieces and perform a search using each piece. If a fragment is found then the test is repeated (as described for test 1 above), and if a fragment is found in the - repeated test then the test fails. - - - + repeated test then the test fails. Applied to each key held as non-volatile memory and subject to destruction by overwrite by the TOE. The evaluator shall use special tools (as needed), - provided by the TOE developer if necessary, to view the key storage location: - - Record the storage location of the key in the TOE subject to - clearing. - Cause the TOE to perform a normal cryptographic processing with the - key from Step #1. - Cause the TOE to clear the key. - Read the storage location in Step #1 of non-volatile memory to ensure - the appropriate pattern is utilized. - - The test succeeds if correct pattern is used to overwrite the key in + provided by the TOE developer if necessary, to view the key storage location: Record the storage location of the key in the TOE subject to + clearing.Cause the TOE to perform a normal cryptographic processing with the + key from Step #1.Cause the TOE to clear the key.Read the storage location in Step #1 of non-volatile memory to ensure + the appropriate pattern is utilized. The test succeeds if correct pattern is used to overwrite the key in the memory location. If the pattern is not found the test fails. - + - - + + requires the TSF to implement a cryptographic or other mechanism to make TSF data unreadable. The following actions could be considered for the management functions in FMT: - - TSF wipe of protected data. - TSF wipe of enterprise data. - + TSF wipe of protected data.TSF wipe of enterprise data. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - - Failure of the wipe. - + Failure of the wipe. FCS_RBG_EXT.1 Random Bit Generation - - The TSF shall wipe all protected data by <selectables linebreak="yes"> - <selectable>Cryptographically erasing the encrypted DEKs or the KEKs in non-volatile memory by following the requirements in FCS_CKM_EXT.4.1</selectable> - <selectable>Overwriting all PD according to the following rules: <htm:ul> - <htm:li>For EEPROM, the destruction shall be executed by a single direct overwrite consisting of a pseudo random pattern using the TSF’s RBG (as specified in FCS_RBG_EXT.1, followed by a read-verify. </htm:li> - <htm:li>For flash memory, that is not wear-leveled, the destruction shall be executed <selectables> - <selectable>by a single direct overwrite consisting of zeros followed by a read-verify</selectable> - <selectable>by a block erase that erases the reference to memory that stores data as well as the data itself</selectable></selectables>. </htm:li> - <htm:li>For flash memory, that is wear-leveled, the destruction shall be executed <selectables> - <selectable>by a single direct overwrite consisting of zeros</selectable> - <selectable>by a block erase</selectable></selectables>. </htm:li> - <htm:li>For non-volatile memory other than EEPROM and flash, the destruction shall be executed by a single direct overwrite with a random pattern that is changed before each write. </htm:li> - </htm:ul> - </selectable> - </selectables>. - - + The TSF shall wipe all protected data by<selectables><selectable id="fcs_ckm_ext.5.1_1" >Cryptographically erasing the encrypted DEKs or the KEKs in non-volatile memory by following the requirements in FCS_CKM_EXT.4.1</selectable><selectable id="fcs_ckm_ext.5.1_2">Overwriting all PD according to the following rules: <htm:ul><htm:li>For EEPROM, the destruction shall be executed by a single direct overwrite consisting of a pseudo random pattern using the TSF’s RBG (as specified in FCS_RBG_EXT.1, followed by a read-verify. </htm:li><htm:li>For flash memory, that is not wear-leveled, the destruction shall be executed <selectables><selectable id="fcs_ckm_ext.5.1_3" >by a single direct overwrite consisting of zeros followed by a read-verify</selectable><selectable id="fcs_ckm_ext.5.1_4" >by a block erase that erases the reference to memory that stores data as well as the data itself</selectable></selectables>. </htm:li><htm:li>For flash memory, that is wear-leveled, the destruction shall be executed <selectables><selectable id="fcs_ckm_ext.5.1_5" >by a single direct overwrite consisting of zeros</selectable><selectable id="fcs_ckm_ext.5.1_6" >by a block erase</selectable></selectables>. </htm:li><htm:li>For non-volatile memory other than EEPROM and flash, the destruction shall be executed by a single direct overwrite with a random pattern that is changed before each write. </htm:li></htm:ul></selectable></selectables>. + Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well. - The TSF shall perform a power cycle on conclusion of the wipe procedure. - - - - The evaluator shall check to ensure the TSS describes how the device is wiped, the type of clearing procedure that is performed (cryptographic erase or overwrite) and, if overwrite is performed, the overwrite procedure (overwrite with zeros, overwrite three or more times by a different alternating pattern, overwrite with random pattern, or block erase). - If different types of memory are used to store the data to be protected, the evaluator shall check to ensure that the TSS describes the clearing procedure in terms of the memory in which the data are stored (for example, data stored on flash are cleared by overwriting once with zeros, while data stored on the internal persistent storage device are cleared by overwriting three times with a random pattern that is changed before each write). - + The TSF shall perform a power cycle on conclusion of the wipe procedure. + + The evaluator shall check to ensure the TSS describes how the device is wiped, the type of clearing procedure that is performed (cryptographic erase or overwrite) and, if overwrite is performed, the overwrite procedure (overwrite with zeros, overwrite three or more times by a different alternating pattern, overwrite with random pattern, or block erase). + If different types of memory are used to store the data to be protected, the evaluator shall check to ensure that the TSS describes the clearing procedure in terms of the memory in which the data are stored (for example, data stored on flash are cleared by overwriting once with zeros, while data stored on the internal persistent storage device are cleared by overwriting three times with a random pattern that is changed before each write). - The evaluator shall verify that the AGD guidance describes how to enable encryption, if it is not enabled by default. Additionally the evaluator shall verify that the AGD guidance describes how to initiate the wipe command. - + The evaluator shall verify that the AGD guidance describes how to enable encryption, if it is not enabled by default. Additionally the evaluator shall verify that the AGD guidance describes how to initiate the wipe command. - Evaluation Activity Note: - The following test may require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products. - The evaluator shall perform one of the following tests. The test before and after the wipe command shall be identical. This test shall be repeated for each type of memory used to store the data to be protected. - - For File-based Methods: - The evaluator shall enable encryption according to the AGD guidance. The evaluator shall create a user data (protected data or sensitive data) file, for example, by using an application. The evaluator shall use a tool provided by the developer to examine this data stored in memory (for example, by examining a decrypted files). The evaluator shall initiate the wipe command according to the AGD guidance provided for FMT_SMF.1. The evaluator shall use a tool provided by the developer to examine the same data location in memory to verify that the data has been wiped according to the method described in the TSS (for example, the files are still encrypted and cannot be accessed). - For Volume-based Methods: - The evaluator shall enable encryption according to the AGD guidance. The evaluator shall create a unique data string, for example, by using an application. The evaluator shall use a tool provided by the developer to search decrypted data for the unique string. The evaluator shall initiate the wipe command according to the AGD guidance provided for FMT_SMF.1. The evaluator shall use a tool provided by the developer to search for the same unique string in decrypted memory to verify that the data has been wiped according to the method described in the TSS (for example, the files are still encrypted and cannot be accessed). - - + The evaluator shall perform one of the following tests. The test before and after the wipe command shall be identical. This test shall be repeated for each type of memory used to store the data to be protected. The evaluator shall cause the device to wipe and verify that the wipe concludes with a power cycle. @@ -3446,38 +1437,32 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - - Failure of the wipenone - + + + + Failure of the wipe + none + + + - - + + requires the TSF to generate salts in a specified manner. There are no management activities foreseen. There are no auditable events foreseen. FCS_RBG_EXT.1 Random Bit Generation - - - The TSF shall generate all salts using an RBG that meets FCS_RBG_EXT.1. + The TSF shall generate all salts using an RBG that meets FCS_RBG_EXT.1. This requirement refers only to salt generation. In the examples given, a salt may be used as part of the scheme/algorithm. Requirements on nonces or ephemeral keys are provided elsewhere, if needed. The list below is provided for clarity, in order to give examples of where the TSF may be generating cryptographic salts; it is not exhaustive nor is it intended to mandate implementation of all of these schemes/algorithms. Cryptographic salts are generated for various uses - including: - RSASSA-PSS signature generation - DSA signature generation - ECDSA signature generation - DH static key agreement scheme - PBKDF - Key Agreement Scheme in NIST SP 800-56B - AES GCM - - - - The evaluator shall verify that the TSS contains a description regarding the + including: RSASSA-PSS signature generationDSA signature generationECDSA signature generationDH static key agreement schemePBKDFKey Agreement Scheme in NIST SP 800-56BAES GCM + + The evaluator shall verify that the TSS contains a description regarding the salt generation, including which algorithms on the TOE require salts. The evaluator shall confirm that the salt is generated using an RBG described in FCS_RBG_EXT.1. For PBKDF derivation of KEKs, this evaluation activity may be performed in @@ -3486,197 +1471,127 @@ The evaluator shall generate 10 private/public key pairs using the key generatio There are no test evaluation activities for this component. - + - + + - requires the TSF to prevent the reading or exporting of REKs. There are no management activities foreseen. There are no auditable events foreseen. FCS_CKM_EXT.1 Cryptographic Key Support - - A REK shall not be able to be read from or exported from the hardware. - If is selected in FCS_CKM_EXT.1.1, - FCS_CKM_EXT.7 must be included in the ST. Note that if is + A REK shall not be able to be read from or exported from the hardware. + If is selected in FCS_CKM_EXT.1.1, + FCS_CKM_EXT.7 must be included in the ST. Note that if is selected in FCS_CKM_EXT.1.1 it implicitly meets FCS_CKM_EXT.7. The lack of a public/documented API for importing or exporting, when a private/undocumented API exists, is not sufficient to meet this requirement. - + The evaluation activity for this component is performed in conjunction with the evaluation activity for FCS_CKM_EXT.1. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component. - + + + + + + The TSF shall perform <htm:b>conditioning</htm:b> in accordance with a specified cryptographic algorithm <htm:b>HMAC-<selectables><selectable id="fcs_cop.1.1_CONDITION_1" >SHA-256</selectable><selectable id="fcs_cop.1.1_CONDITION_2" >SHA-384</selectable><selectable id="fcs_cop.1.1_CONDITION_3" >SHA-512</selectable></selectables> using a salt, and <selectables><selectable id="fcs_cop.1.1_CONDITION_4">PBKDF2 with <assignable>number of iterations </assignable> iterations</selectable><selectable id="fcs_cop.1.1_CONDITION_7" ><assignable>key stretching function </assignable></selectable><selectable id="fcs_cop.1.1_CONDITION_8" exclusive="yes" >no other function</selectable></selectables> and output</htm:b> cryptographic key sizes <htm:b><selectables><selectable id="fcs_cop.1.1_CONDITION_9" >128</selectable><selectable id="fcs_cop.1.1_CONDITION_10" >256</selectable></selectables></htm:b> that meet the following: <htm:b><selectables><selectable id="fcs_cop.1.1_CONDITION_11" >NIST SP 800-132</selectable><selectable id="fcs_cop.1.1_CONDITION_12" exclusive="yes" >no standard</selectable></selectables>.</htm:b> + The key cryptographic key sizes in the third selection should + be made to correspond to the KEK key sizes selected in FCS_CKM_EXT.3. + This password must be conditioned into a string of bits that forms + the submask to be used as input into the KEK. Conditioning can be performed using one + of the identified hash functions and may include a key stretching function; the method + used is selected by the ST author. If selected, NIST SP 800-132 requires the use of a + pseudorandom function (PRF) consisting of HMAC with an approved hash function. The ST + author selects the hash function used, also includes the appropriate requirements for + HMAC and the hash function. Appendix A of NIST SP 800-132 + recommends setting the iteration count in order to increase the computation needed to + derive a key from a password and, therefore, increase the workload of performing a + dictionary attack. + + The evaluator shall check that the TSS describes the method by which the password + is first encoded and then fed to the SHA algorithm and verify the SHA algorithm + matches the first selection. If a key stretching function, such as + PBKDF2, is selected the settings for the algorithm (padding, blocking, etc.) shall + be described. The evaluator shall verify that the TSS contains a description of how + the output of the hash function or key stretching function is used to form the + submask that will be input into the function and is the same length as the KEK as + specified in FCS_CKM_EXT.3. If any manipulation of the key is + performed in forming the submask that will be used to form the KEK, that process + shall be described in the TSS. + There are no guidance evaluation activities for this component. + There are no test evaluation activities for this component. No explicit testing of the + formation of the submask from the input password is required. + + + - + + - The TSF shall perform [<htm:i>encryption/decryption</htm:i>] in accordance with a specified - cryptographic algorithm: [<htm:i> <htm:br/> - <htm:ul> - <htm:li>AES-CBC (as defined in FIPS PUB 197, and NIST SP 800-38A) mode</htm:li> - <htm:li>AES-CCMP (as defined in FIPS PUB 197, NIST SP 800-38C and IEEE 802.11-2012), and</htm:li> - <htm:li><selectables linebreak="yes"> - <selectable>AES Key Wrap (KW) (as defined in NIST SP 800-38F)</selectable> - <selectable>AES Key Wrap with Padding (KWP) (as defined in NIST SP 800-38F)</selectable> - <selectable>AES-GCM (as defined in NIST SP 800-38D)</selectable> - <selectable>AES-CCM (as defined in NIST SP 800-38C)</selectable> - <selectable>AES-XTS (as defined in NIST SP 800-38E) mode</selectable> - <selectable>AES-CCMP-256 (as defined in NIST SP800-38C and IEEE 802.11ac-2013)</selectable> - <selectable>AES-GCMP-256 (as defined in NIST SP800-38D and IEEE 802.11ac-2013)</selectable> - <selectable exclusive="yes">no other modes</selectable></selectables></htm:li> - </htm:ul> </htm:i>] and cryptographic key sizes [<htm:i>128-bit key sizes and <selectables> - <selectable id="s-encrypt-256">256-bit key sizes</selectable> - <selectable exclusive="yes">no other key sizes</selectable></selectables></htm:i>]. + The TSF shall perform [ <htm:i>encryption/decryption</htm:i> ] in accordance with a specified cryptographic algorithm: [ <htm:i><htm:br/><htm:ul><htm:li>AES-CBC (as defined in FIPS PUB 197, and NIST SP 800-38A) mode</htm:li><htm:li>AES-CCMP (as defined in FIPS PUB 197, NIST SP 800-38C and IEEE 802.11-2012), and</htm:li><htm:li><selectables><selectable id="fcs_cop.1.1_ENCRYPT_1" >AES Key Wrap (KW) (as defined in NIST SP 800-38F)</selectable><selectable id="fcs_cop.1.1_ENCRYPT_2" >AES Key Wrap with Padding (KWP) (as defined in NIST SP 800-38F)</selectable><selectable id="fcs_cop.1.1_ENCRYPT_3" >AES-GCM (as defined in NIST SP 800-38D)</selectable><selectable id="fcs_cop.1.1_ENCRYPT_4" >AES-CCM (as defined in NIST SP 800-38C)</selectable><selectable id="fcs_cop.1.1_ENCRYPT_5" >AES-XTS (as defined in NIST SP 800-38E) mode</selectable><selectable id="fcs_cop.1.1_ENCRYPT_6" >AES-CCMP-256 (as defined in NIST SP800-38C and IEEE 802.11ac-2013)</selectable><selectable id="fcs_cop.1.1_ENCRYPT_7" >AES-GCMP-256 (as defined in NIST SP800-38D and IEEE 802.11ac-2013)</selectable><selectable id="fcs_cop.1.1_ENCRYPT_8" exclusive="yes" >no other modes</selectable></selectables></htm:li></htm:ul></htm:i> ] and cryptographic key sizes [ <htm:i>128-bit key sizes and <selectables><selectable id="s-encrypt-256" >256-bit key sizes</selectable><selectable id="fcs_cop.1.1_ENCRYPT_9" exclusive="yes" >no other key sizes</selectable></selectables></htm:i> ]. - For the first selection, the ST author should choose the mode or modes in which AES operates. For the second selection, the ST author should choose the key sizes that are supported by this functionality. 128-bit CBC and CCMP are required in order to comply with the . - Note that to comply with the , AES CCMP (which uses AES in CCM as specified in SP 800-38C) with cryptographic key size of 128 bits must be implemented. If CCM is only implemented to support CCMP for WLAN, AES-CCM does not need be selected. Optionally, AES-CCMP-256 or AES-GCMP-256 with cryptographic key size of 256 bits may be implemented. + For the first selection, the ST author should choose the mode or modes in which AES operates. For the second selection, the ST author should choose the key sizes that are supported by this functionality. 128-bit CBC and CCMP are required in order to comply with the . + Note that to comply with the , AES CCMP (which uses AES in CCM as specified in SP 800-38C) with cryptographic key size of 128 bits must be implemented. If CCM is only implemented to support CCMP for WLAN, AES-CCM does not need be selected. Optionally, AES-CCMP-256 or AES-GCMP-256 with cryptographic key size of 256 bits may be implemented. - - There are no TSS evaluation activities for this component. - There are no guidance evaluation activities for this component. - + + There are no TSS evaluation activities for this component. + There are no guidance evaluation activities for this component. - Evaluation Activity Note: The following tests require the developer to - provide access to a test platform that provides the evaluator with tools that are - typically not found on factory products. - AES-CBC Tests + AES-CBC Known Answer Tests There are four Known Answer Tests (KATs), described below. In all KATs, the plaintext, ciphertext, and IV values shall be 128-bit blocks. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same - inputs to a known good implementation. - - KAT-1. To test the encrypt functionality of AES-CBC, the evaluator shall - supply a set of 10 plaintext values and obtain the ciphertext value that - results from AES-CBC encryption of the given plaintext using a key value of - all zeros and an IV of all zeros. Five plaintext values shall be encrypted - with a 128-bit all-zeros key, and the other five shall be encrypted with a - 256-bit all-zeros key. To test the decrypt functionality - of AES-CBC, the evaluator shall perform the same test as for encrypt, using - 10 ciphertext values as input and AES-CBC decryption. - - KAT-2. To test the encrypt functionality of AES-CBC, the evaluator shall - supply a set of 10 key values and obtain the ciphertext value that results - from AES-CBC encryption of an all-zeros plaintext using the given key value - and an IV of all zeros. Five of the keys shall be 128-bit keys, and the - other five shall be 256-bit keys. To test the decrypt - functionality of AES-CBC, the evaluator shall perform the same test as for - encrypt, using an all-zero ciphertext value as input and AES-CBC decryption. - - KAT-3. To test the encrypt functionality of AES-CBC, the evaluator shall - supply the two sets of key values described below and obtain the ciphertext - value that results from AES encryption of an all-zeros plaintext using the - given key value and an IV of all zeros. The first set of keys shall have 128 - 128-bit keys, and the second set shall have 256 256-bit keys. Key i in each - set shall have the leftmost i bits be ones and the rightmost N-i bits be - zeros, for i in [1,N]. To test the decrypt functionality - of AES-CBC, the evaluator shall supply the two sets of key and ciphertext - value pairs described below and obtain the plaintext value that results from - AES-CBC decryption of the given ciphertext using the given key and an IV of - all zeros. The first set of key or ciphertext pairs shall have 128 128-bit - key or ciphertext pairs, and the second set of key or ciphertext pairs shall have - 256 256-bit key or ciphertext pairs. Key i in each set shall have the leftmost - i bits be ones and the rightmost N-i bits be zeros, for i in [1,N]. The - ciphertext value in each pair shall be the value that results in an - all-zeros plaintext when decrypted with its corresponding key. - - KAT-4. To test the encrypt functionality of AES-CBC, the evaluator shall - supply the set of 128 plaintext values described below and obtain the two - ciphertext values that result from AES-CBC encryption of the given plaintext - using a 128-bit key value of all zeros with an IV of all zeros and using a - 256-bit key value of all zeros with an IV of all zeros, respectively. - Plaintext value i in each set shall have the leftmost i bits be ones and the - rightmost 128-i bits be zeros, for i in [1,128]. To test - the decrypt functionality of AES-CBC, the evaluator shall perform the same - test as for encrypt, using ciphertext values of the same form as the - plaintext in the encrypt test as input and AES-CBC decryption. - - - + inputs to a known good implementation. AES-CBC Multi-Block Message Test The evaluator shall test - the encrypt functionality by encrypting an i-block message where 1 < i <= + the encrypt functionality by encrypting an i-block message where 1 < i < = 10. The evaluator shall choose a key, an IV and plaintext message of length i blocks and encrypt the message, using the mode to be tested, with the chosen key and IV. The ciphertext shall be compared to the result of encrypting the same plaintext message with the same key and IV using a known good implementation. The evaluator shall also test the decrypt functionality for - each mode by decrypting an i-block message where 1 < i <= 10. The + each mode by decrypting an i-block message where 1 < i < = 10. The evaluator shall choose a key, an IV and a ciphertext message of length i blocks and decrypt the message, using the mode to be tested, with the chosen key and IV. The plaintext shall be compared to the result of decrypting the same ciphertext message with the same key and IV using a known good implementation. - AES-CBC Monte Carlo Tests The evaluator shall test the encrypt functionality using a set of 200 plaintext, IV, and key 3-tuples. 100 of these shall use 128 bit keys, and 100 shall use 256 bit keys. The plaintext and IV values shall be 128-bit blocks. For each 3-tuple, 1000 iterations shall be - run as follows: - # Input: PT, IV, Key for i = 1 to 1000: if i == 1: CT[1] = + run as follows: # Input: PT, IV, Key for i = 1 to 1000: if i == 1: CT[1] = AES-CBC-Encrypt(Key, IV, PT) PT = IV else: CT[i] = AES-CBC-Encrypt(Key, PT) PT - = CT[i-1] - The ciphertext computed in the 1000th iteration + = CT[i-1] The ciphertext computed in the 1000th iteration (i.e. CT[1000]) is the result for that trial. This result shall be compared to the result of running 1000 iterations with the same values using a known good implementation. The evaluator shall test the decrypt functionality using the same test as for encrypt, exchanging CT and PT and replacing AES-CBC-Encrypt with AES-CBC-Decrypt. - - AES-CCM Tests + The evaluator shall test the generation-encryption and decryption-verification functionality of AES-CCM for the following input - parameter and tag lengths: - - 128 bit and 256 bit keys - - Two payload lengths. One payload length shall be the + parameter and tag lengths: 128 bit and 256 bit keysTwo payload lengths. One payload length shall be the shortest supported payload length, greater than or equal to zero bytes. The other payload length shall be the longest supported payload length, less - than or equal to 32 bytes (256 bits). - - Two or three associated data lengths. One associated + than or equal to 32 bytes (256 bits). Two or three associated data lengths. One associated data length shall be 0, if supported. One associated data length shall be the shortest supported payload length, greater than or equal to zero bytes. One associated data length shall be the longest supported payload length, less than or equal to 32 bytes (256 bits). If the implementation supports an associated data length of 216 bytes, an associated data - length of 216 bytes shall be tested. - - Nonce lengths. All supported nonce lengths between 7 - and 13 bytes, inclusive, shall be tested. - - Tag lengths. All supported tag lengths of 4, 6, 8, 10, - 12, 14 and 16 bytes shall be tested. - To test the generation-encryption functionality of AES-CCM, the - evaluator shall perform the following four tests: - - For EACH supported key and associated data length and ANY supported - payload, nonce and tag length, the evaluator shall supply one key value, one - nonce value and 10 pairs of associated data and payload values and obtain - the resulting ciphertext. - - For EACH supported key and payload length and ANY supported associated - data, nonce and tag length, the evaluator shall supply one key value, one - nonce value and 10 pairs of associated data and payload values and obtain - the resulting ciphertext. - - For EACH supported key and nonce length and ANY supported associated - data, payload and tag length, the evaluator shall supply one key value and - 10 associated data, payload and nonce value 3-tuples and obtain the - resulting ciphertext. - - For EACH supported key and tag length and ANY supported associated data, - payload and nonce length, the evaluator shall supply one key value, one - nonce value and 10 pairs of associated data and payload values and obtain - the resulting ciphertext. - To determine correctness in each of the above tests, the evaluator + length of 216 bytes shall be tested. Nonce lengths. All supported nonce lengths between 7 + and 13 bytes, inclusive, shall be tested. Tag lengths. All supported tag lengths of 4, 6, 8, 10, + 12, 14 and 16 bytes shall be tested. To test the generation-encryption functionality of AES-CCM, the + evaluator shall perform the following four tests: To determine correctness in each of the above tests, the evaluator shall compare the ciphertext with the result of generation-encryption of the same inputs with a known good implementation. To test the decryption-verification functionality of AES-CCM, for EACH combination of @@ -3686,92 +1601,56 @@ The evaluator shall generate 10 private/public key pairs using the key generatio decrypted payload. The evaluator shall supply 10 tuples that should FAIL and 5 that should PASS per set of 15. - - AES-GCM Test The evaluator shall - test the authenticated encrypt functionality of AES-GCM for each combination of - the following input parameter lengths: - - 128 bit and 256 bit keys - - Two plaintext lengths. One of the plaintext lengths shall - be a non-zero integer multiple of 128 bits, if supported. The other plaintext - length shall not be an integer multiple of 128 bits, if supported. - - Three AAD lengths. One AAD length shall be 0, if - supported. One AAD length shall be a non-zero integer multiple of 128 bits, if - supported. One AAD length shall not be an integer multiple of 128 bits, if - supported. - - Two IV lengths. If 96 bit IV is supported, 96 bits shall - be one of the two IV lengths tested. - + The evaluator shall test the encrypt functionality using a set of 10 key, plaintext, AAD, and IV tuples for each combination of parameter lengths above and obtain the ciphertext value and tag that results from AES-GCM authenticated encrypt. Each supported tag length shall be tested at least once per set of 10. The IV value may be supplied by the evaluator or the implementation being tested, as long as it is known. - The evaluator shall test the decrypt functionality using a set of 10 key, ciphertext, tag, AAD, and IV 5-tuples for each combination of parameter lengths above and obtain a Pass/Fail result on authentication and the decrypted plaintext if Pass. The set shall include five tuples that Pass and five that Fail. - The results from each test may either be obtained by the evaluator - directly or by supplying the inputs to the implementer and receiving the results - in response. To determine correctness, the evaluator shall compare the resulting - values to those obtained by submitting the same inputs to a known good - implementation. - XTS-AES Test + + The evaluator shall test the encrypt functionality of XTS-AES for each - combination of the following input parameter lengths: - - 256 bit (for AES-128) and 512 bit (for AES-256) - keys - Three data unit (i.e. plaintext) lengths. One of the + combination of the following input parameter lengths: 256 bit (for AES-128) and 512 bit (for AES-256) + keysThree data unit (i.e. plaintext) lengths. One of the data unit lengths shall be a non-zero integer multiple of 128 bits, if supported. One of the data unit lengths shall be an integer multiple of 128 bits, if supported. The third data unit length shall be either the longest supported data unit length or 216 bits, whichever is smaller. - - using a set of 100 (key, plaintext and 128-bit random tweak value) + using a set of 100 (key, plaintext and 128-bit random tweak value) 3-tuples and obtain the ciphertext that results from XTS-AES encrypt. The evaluator may supply a data unit sequence number instead of the tweak value if the implementation supports it. The data unit sequence number is a base-10 number ranging between 0 and 255 that implementations - convert to a tweak value internally. + convert to a tweak value internally. The evaluator shall test the decrypt functionality of XTS-AES using the same test as for encrypt, replacing plaintext values with ciphertext values and XTS-AES encrypt with XTS-AES decrypt. - - AES Key Wrap (AES-KW) and Key Wrap with Padding (AES-KWP) - Test + + The evaluator shall test the authenticated encryption functionality of - AES-KW for EACH combination of the following input parameter lengths: - - 128 and 256 bit key encryption keys (KEKs) - Three plaintext lengths. One of the plaintext lengths + AES-KW for EACH combination of the following input parameter lengths: 128 and 256 bit key encryption keys (KEKs)Three plaintext lengths. One of the plaintext lengths shall be two semi-blocks (128 bits). One of the plaintext lengths shall be three semi-blocks (192 bits). The third data unit length shall be the longest supported plaintext length less than or equal to 64 semi-blocks - (4096 bits). - using a set of 100 key and plaintext pairs and obtain the ciphertext + (4096 bits). using a set of 100 key and plaintext pairs and obtain the ciphertext that results from AES-KW authenticated encryption. To determine correctness, the evaluator shall use the AES-KW authenticated-encryption function of a known good - implementation. + implementation. The evaluator shall test the authenticated-decryption functionality of AES-KW using the same test as for authenticated-encryption, replacing plaintext values with ciphertext values and AES-KW authenticated-encryption with AES-KW - authenticated-decryption. + authenticated-decryption. The evaluator shall test the authenticated-encryption functionality of AES-KWP using the same test as for AES-KW authenticated-encryption with the - following change in the three plaintext lengths: - One plaintext length shall be one octet. One plaintext length shall be - 20 octets (160 bits). - One plaintext length shall be the longest supported plaintext length - less than or equal to 512 octets (4096 bits). - - + following change in the three plaintext lengths: One plaintext length shall be one octet. One plaintext length shall be + 20 octets (160 bits).One plaintext length shall be the longest supported plaintext length + less than or equal to 512 octets (4096 bits). The evaluator shall test the authenticated-decryption functionality of AES-KWP using the same test as for AES-KWP authenticated-encryption, replacing plaintext values with ciphertext values and AES-KWP authenticated-encryption @@ -3780,62 +1659,19 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - + - + + - The TSF shall perform [<htm:i>cryptographic hashing</htm:i>] in - accordance with a specified cryptographic algorithm [<htm:i>SHA-1 and <selectables> - <selectable id="s-sha-256">SHA-256</selectable> - <selectable id="s-sha-384">SHA-384</selectable> - <selectable id="s-sha-512">SHA-512</selectable> - <selectable exclusive="yes">no other algorithms</selectable></selectables></htm:i>] and <refinement>message digest</refinement> sizes - [<htm:i>160 and <selectables> - <selectable id="s-hash-size-256">256 bits</selectable> - <selectable id="s-hash-size-384">384 bits</selectable> - <selectable id="s-hash-size-512">512 bits</selectable> - <selectable exclusive="yes">no other message digest sizes</selectable></selectables></htm:i>] that meet the following: [<htm:i>FIPS Pub - 180-4</htm:i>]. - <rule id="r-sha256"> - <or> - <and> - <ref-id>s-sha-256</ref-id><ref-id>s-hash-size-256</ref-id> - </and> - <and> - <not><ref-id>s-sha-256</ref-id></not> - <not><ref-id>s-hash-size-256</ref-id></not> - </and> - </or> - </rule> - <rule id="r-sha384"> - <or> - <and> - <ref-id>s-sha-384</ref-id><ref-id>s-hash-size-384</ref-id> - </and> - <and> - <not><ref-id>s-sha-384</ref-id></not> - <not><ref-id>s-hash-size-384</ref-id></not> - </and> - </or> - </rule> - <rule id="r-sha512"> - <or> - <and> - <ref-id>s-sha-512</ref-id><ref-id>s-hash-size-512</ref-id> - </and> - <and> - <not><ref-id>s-sha-512</ref-id></not> - <not><ref-id>s-hash-size-512</ref-id></not> - </and> - </or> - </rule> - + The TSF shall perform [ <htm:i>cryptographic hashing</htm:i> ] in accordance with a specified cryptographic algorithm [ <htm:i>SHA-1 and <selectables><selectable id="s-sha-256" >SHA-256</selectable><selectable id="s-sha-384" >SHA-384</selectable><selectable id="s-sha-512" >SHA-512</selectable><selectable id="fcs_cop.1.1_HASH_1" exclusive="yes" >no other algorithms</selectable></selectables></htm:i> ] and <htm:b>message digest</htm:b> sizes [ <htm:i>160 and <selectables><selectable id="s-hash-size-256" >256 bits</selectable><selectable id="s-hash-size-384" >384 bits</selectable><selectable id="s-hash-size-512" >512 bits</selectable><selectable id="fcs_cop.1.1_HASH_2" exclusive="yes" >no other message digest sizes</selectable></selectables></htm:i> ] that meet the following: [ <htm:i>FIPS Pub + 180-4</htm:i> ]. Per NIST SP 800-131A, SHA-1 for generating digital signatures is no longer allowed, and SHA-1 for verification of digital signatures is strongly discouraged as there may be risk in accepting these signatures. It is expected that vendors will implement SHA-2 algorithms in accordance with SP 800-131A. SHA-1 is currently required in order to comply with the - . Vendors are strongly encouraged to implement updated + . Vendors are strongly encouraged to implement updated protocols that support the SHA-2 family; until updated protocols are supported, this PP allows support for SHA-1 implementations in compliance with SP 800-131A. The intent of this requirement is to specify the hashing @@ -3848,53 +1684,44 @@ The evaluator shall generate 10 private/public key pairs using the key generatio the bit­oriented mode. In this mode the TSF hashes messages of arbitrary length. The TSF may implement either bit-oriented or byte-oriented; both implementations are not required. - - The evaluator shall check that the association of the hash function with other + + The evaluator shall check that the association of the hash function with other TSF cryptographic functions (for example, the digital signature verification function) is documented in the TSS. The evaluator shall check that the TSS indicates if the hashing function is implemented in bit-oriented or - byte-oriented mode. - + byte-oriented mode. The evaluator checks the AGD documents to determine that any configuration that is required to be done to configure the functionality for the required hash - sizes is present. - + sizes is present. - Evaluation Activity Note: The following tests require the developer to - provide access to a test platform that provides the evaluator with tools that are - typically not found on factory products. The evaluator shall - perform all of the following tests for each hash algorithm implemented by the TSF - and used to satisfy the requirements of this PP. As there are different tests for - each mode, an indication is given in the following sections for the bit­oriented vs. - the byte­oriented tests. Short Messages Test: Bit-oriented Mode The evaluators devise an input set consisting of m+1 messages, where m is the block length of the hash algorithm. The length of the messages ranges sequentially from 0 to m bits. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that - the correct result is produced when the messages are provided to the TSF. + the correct result is produced when the messages are provided to the TSF. Short Messages Test: Byte-oriented Mode The evaluators devise an input set consisting of m/8+1 messages, where m is the block length of the hash algorithm. The length of the messages range sequentially from 0 to m/8 bytes, with each message being an integral number of bytes. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct - result is produced when the messages are provided to the TSF. + result is produced when the messages are provided to the TSF. Selected Long Messages Test: Bit-oriented Mode The evaluators devise an input set consisting of m messages, where m is the block length of the hash algorithm. The length of the ith message is 512 + 99*i, where 1 ≤ i ≤ m. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to - the TSF. + the TSF. Selected Long Messages Test: Byte-oriented Mode The evaluators devise an input set consisting of m/8 messages, where m is the block length of the hash algorithm. The length of the ith message is 512 + 8*99*i, where 1 ≤ i ≤ m/8. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to - the TSF. + the TSF. Pseudorandomly Generated Messages Test: Byte-oriented Mode This test is for byte­oriented implementations only. The evaluators randomly generate a seed that is n bits long, where n is the length @@ -3906,106 +1733,24 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - + - - - The TSF shall perform [<htm:i>cryptographic signature services (generation - and verification)</htm:i>] in accordance with a specified cryptographic - algorithm <selectables linebreak="yes"> - <selectable id="s-sign-rsa"><readable>RSA schemes</readable>[<htm:i><snip>RSA schemes</snip></htm:i>] <refinement>using</refinement> cryptographic key sizes of [<htm:i>2048-bit or - greater</htm:i>] that meet the following: [<htm:i>FIPS PUB 186-4, "Digital Signature Standard - (DSS)", Section 4</htm:i>]</selectable> - <selectable id="s-sign-ecdsa"><readable>ECDSA schemes</readable>[<htm:i>ECDSA schemes</htm:i>] <refinement>using</refinement> [<htm:i>"NIST curves" P-384 and <selectables> - <selectable>P-256</selectable> - <selectable>P-521</selectable> - <selectable exclusive="yes">no other curves</selectable></selectables></htm:i>] that meet the following: [<htm:i>FIPS PUB 186-4, "Digital Signature - Standard (DSS)", Section 5</htm:i>]</selectable> - <!-- <selectable exclusive="yes">No other algorithms</selectable> --> - </selectables>. - The ST author should choose the algorithm implemented to - perform digital signatures; if more than one algorithm is available, this requirement - should be iterated to specify the functionality. For the algorithm chosen, the ST - author should make the appropriate assignments/selections to specify the parameters - that are implemented for that algorithm. - - There are no TSS evaluation activities for this component. - There are no guidance evaluation activities for this component. - - Evaluation Activity Note: The following tests require the developer to - provide access to a test platform that provides the evaluator with tools that are - typically not found on factory products. - - [conditional] If is selected in FCS_COP.1.1/SIGN - - ECDSA FIPS 186-4 Signature Generation Test For - each supported NIST curve (i.e. P-256, P-384 and P-521) and SHA function - pair, the evaluator shall generate 10 1024-bit long messages and obtain for - each message a public key and the resulting signature values R and S. To - determine correctness, the evaluator shall use the signature verification - function of a known good implementation. - ECDSA FIPS 186-4 Signature Verification Test For - each supported NIST curve (i.e. P-256, P-384 and P-521) and SHA function - pair, the evaluator shall generate a set of 10 1024-bit message, public key - and signature tuples and modify one of the values (message, public key or - signature) in five of the 10 tuples. The evaluator shall obtain in response - a set of 10 PASS/FAIL values. - - - [conditional] If is selected in FCS_COP.1.1/SIGN - - Signature Generation Test The evaluator shall - verify the implementation of RSA Signature Generation by the TOE using the - Signature Generation Test. To conduct this test the evaluator must generate - or obtain 10 messages from a trusted reference implementation for each - modulus size/SHA combination supported by the TSF. The evaluator shall have - the TOE use their private key and modulus value to sign these messages. - The evaluator shall verify the correctness of the TSF’s - signature using a known good implementation and the associated public keys - to verify the signatures. - Signature Verification Test The evaluator shall - perform the Signature Verification test to verify the ability of the TOE to - recognize another party’s valid and invalid signatures. The evaluator shall - inject errors into the test vectors produced during the Signature - Verification Test by introducing errors in some of the public keys e, - messages, IR format, or signatures. The TOE attempts to verify the - signatures and returns success or failure. - The evaluator shall use these test vectors to emulate the signature - verification test using the corresponding parameters and verify that the TOE detects - these errors. - - - - - - - - + + - The TSF shall perform [<htm:i>keyed-hash message authentication</htm:i>] - in accordance with a specified cryptographic algorithm [<htm:i>HMAC-SHA-1 and <selectables> - <selectable>HMAC-SHA-256</selectable> - <selectable>HMAC-SHA-384</selectable> - <selectable>HMAC-SHA-512</selectable> - <selectable exclusive="yes">no other algorithms</selectable></selectables></htm:i>] and cryptographic key sizes <assignable>key size (in - bits) used in HMAC</assignable><refinement> and message digest sizes 160 and <selectables> - <selectable>256</selectable> - <selectable>384</selectable> - <selectable>512</selectable> - <selectable exclusive="yes">no other</selectable></selectables> bits</refinement> that meet the following: [<htm:i>FIPS Pub + <title>The TSF shall perform [ <htm:i>keyed-hash message authentication</htm:i> ] in accordance with a specified cryptographic algorithm [ <htm:i>HMAC-SHA-1 and <selectables><selectable id="fcs_cop.1.1_KEYHMAC_1" >HMAC-SHA-256</selectable><selectable id="fcs_cop.1.1_KEYHMAC_2" >HMAC-SHA-384</selectable><selectable id="fcs_cop.1.1_KEYHMAC_3" >HMAC-SHA-512</selectable><selectable id="fcs_cop.1.1_KEYHMAC_4" exclusive="yes" >no other algorithms</selectable></selectables></htm:i> ] and cryptographic key sizes<assignable>key size (in bits) used in HMAC</assignable><htm:b> and message digest sizes 160 and <selectables><selectable id="fcs_cop.1.1_KEYHMAC_6" >256</selectable><selectable id="fcs_cop.1.1_KEYHMAC_7" >384</selectable><selectable id="fcs_cop.1.1_KEYHMAC_8" >512</selectable><selectable id="fcs_cop.1.1_KEYHMAC_9" exclusive="yes" >no other</selectable></selectables> bits</htm:b> that meet the following: [ <htm:i>FIPS Pub 198-1, "The Keyed-Hash Message Authentication Code", and FIPS Pub 180-4, "Secure - Hash Standard"</htm:i>]. + Hash Standard" ]. The selection in this requirement must be consistent with the key size specified for the size of the keys used in conjunction with the keyed-hash message authentication. HMAC-SHA-1 is currently required in order to comply with the - . - - The evaluator shall examine the TSS to ensure that it specifies the following + . + + The evaluator shall examine the TSS to ensure that it specifies the following values used by the HMAC function: key length, hash function used, block size, and output MAC length used. There are no guidance evaluation activities for this component. - - Evaluation Activity Note: The following tests require the developer to + Evaluation Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products. For each of the supported parameter sets, the evaluator shall compose 15 sets of test data. Each set @@ -4015,141 +1760,81 @@ The evaluator shall generate 10 private/public key pairs using the key generatio implementation. - + - - - The TSF shall perform <refinement>conditioning</refinement> in accordance with a - specified cryptographic algorithm <refinement>HMAC-<selectables> - <selectable>SHA-256</selectable> - <selectable>SHA-384</selectable> - <selectable>SHA-512</selectable></selectables> using a salt, and <selectables> - <selectable>PBKDF2 with <assignable>number of iterations</assignable> - iterations</selectable> - <selectable><assignable>key stretching function</assignable></selectable> - <selectable exclusive="yes">no other function</selectable></selectables> and output</refinement> cryptographic key sizes<refinement> - <selectables> - <selectable>128</selectable> - <selectable>256</selectable></selectables></refinement> that meet the following: <refinement><selectables> - <selectable>NIST SP 800-132</selectable> - <selectable exclusive="yes">no standard</selectable></selectables>.</refinement> - - The key cryptographic key sizes in the third selection should - be made to correspond to the KEK key sizes selected in FCS_CKM_EXT.3. - This password must be conditioned into a string of bits that forms - the submask to be used as input into the KEK. Conditioning can be performed using one - of the identified hash functions and may include a key stretching function; the method - used is selected by the ST author. If selected, NIST SP 800-132 requires the use of a - pseudorandom function (PRF) consisting of HMAC with an approved hash function. The ST - author selects the hash function used, also includes the appropriate requirements for - HMAC and the hash function. Appendix A of NIST SP 800-132 - recommends setting the iteration count in order to increase the computation needed to - derive a key from a password and, therefore, increase the workload of performing a - dictionary attack. - - The evaluator shall check that the TSS describes the method by which the password - is first encoded and then fed to the SHA algorithm and verify the SHA algorithm - matches the first selection. If a key stretching function, such as - PBKDF2, is selected the settings for the algorithm (padding, blocking, etc.) shall - be described. The evaluator shall verify that the TSS contains a description of how - the output of the hash function or key stretching function is used to form the - submask that will be input into the function and is the same length as the KEK as - specified in FCS_CKM_EXT.3. If any manipulation of the key is - performed in forming the submask that will be used to form the KEK, that process - shall be described in the TSS. + + + + The TSF shall perform [ <htm:i>cryptographic signature services (generation + and verification)</htm:i> ] in accordance with a specified cryptographic algorithm<selectables><selectable id="s-sign-rsa" >[<htm:i> <snip>RSA schemes</snip></htm:i>] <htm:b>using</htm:b> cryptographic key sizes of [<htm:i>2048-bit or + greater</htm:i>] that meet the following: [<htm:i>FIPS PUB 186-4, "Digital Signature Standard + (DSS)", Section 4</htm:i>]</selectable><selectable id="s-sign-ecdsa">[<htm:i>ECDSA schemes</htm:i>] <htm:b>using</htm:b> [<htm:i>"NIST curves" P-384 and <selectables><selectable id="fcs_cop.1.1_SIGN_1" >P-256</selectable><selectable id="fcs_cop.1.1_SIGN_2" >P-521</selectable><selectable id="fcs_cop.1.1_SIGN_3" exclusive="yes" >no other curves</selectable></selectables></htm:i>] that meet the following: [<htm:i>FIPS PUB 186-4, "Digital Signature Standard (DSS)", Section 5</htm:i>]</selectable></selectables>. + The ST author should choose the algorithm implemented to + perform digital signatures; if more than one algorithm is available, this requirement + should be iterated to specify the functionality. For the algorithm chosen, the ST + author should make the appropriate assignments/selections to specify the parameters + that are implemented for that algorithm. + + There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. - There are no test evaluation activities for this component. No explicit testing of the - formation of the submask from the input password is required. + + + [conditional] If is selected in FCS_COP.1.1/SIGN + [conditional] If is selected in FCS_COP.1.1/SIGN + + - + - - - This family defines requirements for implementation of the HTTPS protocol. - - - - - - + + requires the TSF to implement the HTTPS protocol in accordance with the specified standard, using TLS, and notifying the application if invalid. The following actions could be considered for the management functions in FMT: - - Configuring whether to allow or disallow establishment of a trusted channel if the peer or server certificate is deemed invalid. - + Configuring whether to allow or disallow establishment of a trusted channel if the peer or server certificate is deemed invalid. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - - Failure of the certificate validity check. - - FIA_X509_EXT.1 X.509 Validation of Certificates + Failure of the certificate validity check. + FIA_X509_EXT.1 X.509 Validation of Certificates FMT_SMF.1 Specification of Management Functions - - - The TSF shall implement the HTTPS protocol that complies with RFC 2818. + The TSF shall implement the HTTPS protocol that complies with RFC 2818. - - The TSF shall implement HTTPS using TLS as defined in [<htm:i>the <xref to="pkg-tls"/></htm:i>]. - - The TSF shall implement HTTPS using TLS as defined in - <assignable>specification that defines TLS implementation requirements</assignable>. - + The TSF shall implement HTTPS using TLS as defined in [ <htm:i>the <xref to="pkg-tls"></xref></htm:i> ]. - The must be included in the ST, with the following selections made: - FCS_TLS_EXT.1: - - TLS must be selected - Client must be selected - - - + The must be included in the ST, with the following selections made: FCS_TLS_EXT.1:TLS must be selectedClient must be selected - - The TSF shall notify the application and <selectables> - <selectable id="s-not-estab">not establish the connection</selectable> - <selectable id="s-req-app-auth">request application authorization to establish the - connection</selectable> - <selectable id="s-no-other-action" exclusive="yes">no other action</selectable></selectables> if the peer certificate is deemed invalid. - The TSF shall notify the application and <assignable>a response</assignable> if the peer certificate is deemed invalid. + The TSF shall notify the application and<selectables><selectable id="s-not-estab" >not establish the connection</selectable><selectable id="s-req-app-auth" >request application authorization to establish the + connection</selectable><selectable id="s-no-other-action" exclusive="yes" >no other action</selectable></selectables>if the peer certificate is deemed invalid. Validity is determined by the certificate path, the expiration date, and the revocation status in accordance with RFC 5280. - If is selected then "with no exceptions" must be selected - for FCS_TLSC_EXT.1.3 in the . - - s-not-estab - s-tlsc-no-excep - - If is selected then + If is selected then "with no exceptions" must be selected + for FCS_TLSC_EXT.1.3 in the . + s-not-estabs-tlsc-no-excep + If is selected then "except when override is authorized" must be selected for FCS_TLSC_EXT.1.3 in the Package for Transport Layer Security. - - s-req-app-auth - s-tlsc-override - - If is selected either selection can be + s-req-app-auths-tlsc-override + If is selected either selection can be made in FCS_TLSC_EXT.1.3. - FMT_SMF.1 Function configures whether to allow or disallow the establishment of a + FMT_SMF.1 Function configures whether to allow or disallow the establishment of a trusted channel if the peer certificate is deemed invalid. - - + There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. - The evaluator shall attempt to establish an HTTPS connection with a webserver, observe the traffic with a packet analyzer, and verify that the connection succeeds and that the traffic is identified as TLS or HTTPS. Other tests are performed in conjunction with testing in the - . Certificate validity + . Certificate validity shall be tested in accordance with testing performed for FIA_X509_EXT.1, and the - evaluator shall perform the following test: + evaluator shall perform the following test: The evaluator shall demonstrate that using a certificate without a valid certification path results in an application notification. Using the administrative guidance, the evaluator shall then load a certificate or @@ -4161,100 +1846,57 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - - Failure of the certificate validity check. - Issuer Name and Subject Name of certificate - User’s authorization decisionNo additional information - + + Failure of the certificate validity check. + Issuer Name and Subject Name of certificate + + + User’s authorization decision + No additional information + + + - - - This family defines requirements for initialization vector generation in support of key generation. - - - - - - + + requires the TSF to generate IVs in accordance with a set of approved modes. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. - - - The TSF shall generate IVs in accordance with [<htm:i><xref to="ivtable"/>: - References and IV Requirements for NIST-approved Cipher Modes</htm:i>]. - - The TSF shall generate IVs in accordance with <assignable>standard or specification for IV generation</assignable>. - - - lists the requirements for composition of IVs according to + The TSF shall generate IVs in accordance with [ <htm:i> <xref to="ivtable"></xref>: + References and IV Requirements for NIST-approved Cipher Modes</htm:i> ]. + lists the requirements for composition of IVs according to the NIST Special Publications for each cipher mode. The composition of IVs generated for encryption according to a cryptographic protocol is addressed by the protocol. Thus, this requirement addresses only IVs generated for key storage and data storage encryption. - - The evaluator shall examine the key hierarchy section of the TSS to ensure that + + The evaluator shall examine the key hierarchy section of the TSS to ensure that the encryption of all keys is described and the formation of the IVs for each key encrypted by the same KEK meets FCS_IV_EXT.1. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component. - + - - - This family defines requirements for the generation of random bits. - - - - - - + + requires the TSF to generate random data with a certain amount of entropy and in accordance with applicable standards. There are no management activities foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - - Failure of the randomization process. - + Failure of the randomization process. No dependencies. - - - The TSF shall perform all deterministic random bit generation services in - accordance with NIST Special Publication 800-90A using <selectables> - <selectable>Hash_DRBG (any)</selectable> - <selectable>HMAC_DRBG (any)</selectable> - <selectable>CTR_DRBG (AES)</selectable></selectables>. - - The TSF shall perform all deterministic random bit generation services in - accordance with NIST Special Publication 800-90A using <assignable>list of DRBG algorithms</assignable>. - + The TSF shall perform all deterministic random bit generation services in accordance with NIST Special Publication 800-90A using<selectables><selectable id="fcs_rbg_ext.1.1_1" >Hash_DRBG (any)</selectable><selectable id="fcs_rbg_ext.1.1_2" >HMAC_DRBG (any)</selectable><selectable id="fcs_rbg_ext.1.1_3" >CTR_DRBG (AES)</selectable></selectables>. - The deterministic RBG shall be seeded by an entropy source that accumulates - entropy from <selectables> - <selectable>a software-based noise source</selectable> - <selectable>TSF-hardware-based noise source</selectable> - </selectables> with a minimum of <selectables> - <selectable>128 bits</selectable> - <selectable id="s-rbg-256">256 bits</selectable></selectables> of entropy at least equal to the greatest security strength (according - to NIST SP 800-57) of the keys and hashes that it will generate. - - The deterministic RBG shall be seeded by an entropy source that accumulates - entropy from - <assignable>list of sources of random</assignable> with a minimum of - <assignable>number of bits</assignable> - of entropy at least equal to the greatest security strength (according - to NIST SP 800-57) of the keys and hashes that it will generate. - + The deterministic RBG shall be seeded by an entropy source that accumulates entropy from<selectables><selectable id="fcs_rbg_ext.1.2_1" >a software-based noise source</selectable><selectable id="fcs_rbg_ext.1.2_2" >TSF-hardware-based noise source</selectable></selectables>with a minimum of<selectables><selectable id="fcs_rbg_ext.1.2_3" >128 bits</selectable><selectable id="s-rbg-256" >256 bits</selectable></selectables>of entropy at least equal to the greatest security strength (according to NIST SP 800-57) of the keys and hashes that it will generate. - The TSF shall be capable of providing output of the RBG to applications running - on the TSF that request random bits. + The TSF shall be capable of providing output of the RBG to applications running on the TSF that request random bits. SP 800-90A contains three different methods of generating random numbers; each of these, in turn, depends on underlying cryptographic primitives (hash functions/ciphers). The ST author will select the function used, and include the @@ -4283,27 +1925,11 @@ The evaluator shall generate 10 private/public key pairs using the key generatio contains drift and jitter over time. The output of the ring oscillator consists of the oscillating binary value sampled at a constant rate from one of the inverters – a rate that is significantly slower than the oscillator’s natural frequency. - - - Entropy Documentation - - Documentation shall be produced and the evaluator shall perform the - activities in accordance with , the "Clarification to the - Entropy Documentation and Assessment". - - - API Documentation - - The evaluator shall verify - that the API documentation provided according to , includes the - security functions described in FCS_RBG_EXT.1.3. - + There are no TSS evaluation activities for this component. The evaluator shall also confirm that the operational guidance contains - appropriate instructions for configuring the RNG functionality. - - - Evaluation Activity Note: The following tests require the developer to + appropriate instructions for configuring the RNG functionality. + Evaluation Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products. The evaluator shall perform 15 trials for the RNG implementation. If the RNG is configurable, the @@ -4328,40 +1954,30 @@ The evaluator shall generate 10 private/public key pairs using the key generatio generate. The sixth and seventh are additional input and entropy input to the call to reseed. The final value is additional input to the second generate call. The following paragraphs contain more information on some of the - input values to be generated/selected by the evaluator. - - Entropy input: the length of the entropy input value must - equal the seed length. - Nonce: If a nonce is supported (CTR_DRBG with no Derivation + input values to be generated/selected by the evaluator. Entropy input: the length of the entropy input value must + equal the seed length.Nonce: If a nonce is supported (CTR_DRBG with no Derivation Function does not use a nonce), the nonce bit length is one-half the seed - length. - Personalization string: The length of the personalization - string must be ࣘ seed length. If the implementation only supports one + length.Personalization string: The length of the personalization + string must be ࣘ seed length. If the implementation only supports one personalization string length, then the same length can be used for both values. If more than one string length is support, the evaluator shall use personalization strings of two different lengths. If the implementation does not - use a personalization string, no value needs to be supplied. - Additional input: the additional input bit lengths have the - same defaults and restrictions as the personalization string lengths. - - + use a personalization string, no value needs to be supplied.Additional input: the additional input bit lengths have the + same defaults and restrictions as the personalization string lengths. - - Failure of the randomization process - + + Failure of the randomization process + - - - + + requires the TSF to save and restore the state of the RBG when powering off and starting up. There are no management activities foreseen. There are no auditable events foreseen. FCS_RBG_EXT.1 Random Bit Generation - - The TSF shall save the state of the deterministic RBG at power-off, and shall use - this state as input to the deterministic RBG at startup. + The TSF shall save the state of the deterministic RBG at power-off, and shall use this state as input to the deterministic RBG at startup. The capability to add the state saved at power-off as input to the RBG prevents an RBG that is slow to gather entropy from producing the same output regularly and across reboots. Since there is no guarantee of the protections provided @@ -4369,9 +1985,9 @@ The evaluator shall generate 10 private/public key pairs using the key generatio that the state is 'known', and therefore cannot contribute entropy to the RBG, but can introduce enough variation that the initial RBG values are not predictable and exploitable. - + The evaluation activity for this requirement is captured in the RBG documentation - for . The evaluator shall verify that the documentation + for . The evaluator shall verify that the documentation describes how the state is generated so as to be available for the next startup, how the state is used as input to the DRBG, and any protection measures used for the state while the TOE is powered off. @@ -4379,29 +1995,29 @@ The evaluator shall generate 10 private/public key pairs using the key generatio There are no test evaluation activities for this component. - + - - + + requires the TSF to support a personalization string as a DRBG input parameter. There are no management activities foreseen. There are no auditable events foreseen. FCS_RBG_EXT.1 Random Bit Generation - - The TSF shall allow applications to add data to the deterministic RBG using the - Personalization String as defined in SP 800-90A. + The TSF shall allow applications to add data to the deterministic RBG using the Personalization String as defined in SP 800-90A. As specified in SP 800-90A, the TSF must not count data input from an application towards the entropy required by FCS_RBG_EXT.1. Thus, the TSF must not allow the only input to the RBG seed to be from an application. - The evaluator shall verify that this function is included as an interface to - the RBG in the documentation required by and that the + + The evaluator shall verify that this function is included as an interface to + the RBG in the documentation required by and that the behavior of the RBG following a call to this interface is described. The evaluator shall also verify that the documentation of the RBG describes the conditions of use and possible values for the Personalization String input to the SP 800-90A specified DRBG. There are no TSS evaluation activities for this component. - There are no guidance evaluation activities for this component. + There are no guidance evaluation activities for this component. + The evaluator shall write, or the developer shall provide, an application that adds data to the RBG via the Personalization String. The evaluator shall @@ -4410,65 +2026,27 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - + - - - This family defines requirements for the ability of the TOE to make its cryptographic operations available to non-TSF components. - - - - - - + + requires the TSF to have externally-accessible cryptographic services for making algorithm functions available to applications. There are no management activities foreseen. There are no auditable events foreseen. - FCS_CKM.1 Cryptographic Key Generation + FCS_CKM.1 Cryptographic Key Generation FCS_COP.1 Cryptographic Operation - - - The TSF shall provide a mechanism for applications to request the TSF to perform - the following cryptographic operations: [<htm:i><htm:ul> - <htm:li>All mandatory and <selectables> - <selectable>selected algorithms</selectable> - <selectable> selected algorithms with the exception of ECC over curve - 25519-based algorithms</selectable></selectables> in FCS_CKM.2/LOCKED</htm:li> - <htm:li>The following algorithms in FCS_COP.1/ENCRYPT: AES-CBC, <selectables> - <selectable>AES Key Wrap</selectable> - <selectable>AES Key Wrap with Padding</selectable> - <selectable>AES-GCM</selectable> - <selectable>AES-CCM</selectable> - <selectable exclusive="yes">no other modes</selectable></selectables> - </htm:li> - <htm:li>All selected algorithms in FCS_COP.1/SIGN</htm:li> - <htm:li>All mandatory and selected algorithms in FCS_COP.1/HASH</htm:li> - <htm:li>All mandatory and selected algorithms in FCS_COP.1/KEYHMAC</htm:li> - <htm:li> - <selectables linebreak="yes"> - <selectable>All mandatory and <selectables> - <selectable>selected algorithms</selectable> - <selectable>selected algorithms with the exception of ECC over curve - 25519-based algorithms</selectable></selectables> in FCS_CKM.1</selectable> - <selectable>The selected algorithms in FCS_COP.1<htm:b>/CONDITION</htm:b></selectable> - <selectable exclusive="yes">No other cryptographic operations</selectable> - </selectables> - </htm:li> - </htm:ul></htm:i>]. - - - The TSF shall provide a mechanism for applications to request the TSF to perform - the following cryptographic operations: <assignable>cryptographic operations defined by the TSF in FCS_CKM.1 or FCS_COP.1</assignable> - - + The TSF shall provide a mechanism for applications to request the TSF to perform the following cryptographic operations: [ <htm:i><htm:ul><htm:li>All mandatory and <selectables><selectable id="fcs_srv_ext.1.1_1" >selected algorithms</selectable><selectable id="fcs_srv_ext.1.1_2" > selected algorithms with the exception of ECC over curve + 25519-based algorithms</selectable></selectables> in FCS_CKM.2/LOCKED</htm:li><htm:li>The following algorithms in FCS_COP.1/ENCRYPT: AES-CBC, <selectables><selectable id="fcs_srv_ext.1.1_3" >AES Key Wrap</selectable><selectable id="fcs_srv_ext.1.1_4" >AES Key Wrap with Padding</selectable><selectable id="fcs_srv_ext.1.1_5" >AES-GCM</selectable><selectable id="fcs_srv_ext.1.1_6" >AES-CCM</selectable><selectable id="fcs_srv_ext.1.1_7" exclusive="yes" >no other modes</selectable></selectables></htm:li><htm:li>All selected algorithms in FCS_COP.1/SIGN</htm:li><htm:li>All mandatory and selected algorithms in FCS_COP.1/HASH</htm:li><htm:li>All mandatory and selected algorithms in FCS_COP.1/KEYHMAC</htm:li><htm:li><selectables><selectable id="fcs_srv_ext.1.1_8">All mandatory and <selectables><selectable id="fcs_srv_ext.1.1_9" >selected algorithms</selectable><selectable id="fcs_srv_ext.1.1_10" >selected algorithms with the exception of ECC over curve + 25519-based algorithms</selectable></selectables> in FCS_CKM.1</selectable><selectable id="fcs_srv_ext.1.1_11" >The selected algorithms in FCS_COP.1<htm:b>/CONDITION</htm:b></selectable><selectable id="fcs_srv_ext.1.1_12" exclusive="yes" >No other cryptographic operations</selectable></selectables></htm:li></htm:ul></htm:i> ]. For each of the listed FCS components in the bulleted list, the intent is that the TOE will make available all algorithms specified for that component in the ST. For example, if for FCS_COP.1/HASH the ST author selects SHA-256, then the TOE would have to make available an interface to perform SHA-1 (the "mandatory" portion of FCS_COP.1/HASH) and SHA-256 (the "selected" portion of FCS_COP.1/HASH). - The exception is for FCS_COP.1/ENCRYPT. The TOE is not required to make available AES_CCMP, AES_XTS, AES_GCMP-256, or AES_CCMP_256 even though they may be implemented to perform TSF-related functions. It is acceptable for the platform to not provide AES Key Wrap (KW) and AES Key Wrap with Padding (KWP) to applications even if selected in FCS_COP.1/ENCRYPT. However, the ST author is expected to select AES-GCM or AES-CCM if it is selected in the ST for the FCS_COP.1/ENCRYPT component. + The exception is for FCS_COP.1/ENCRYPT. The TOE is not required to make available AES_CCMP, AES_XTS, AES_GCMP-256, or AES_CCMP_256 even though they may be implemented to perform TSF-related functions. It is acceptable for the platform to not provide AES Key Wrap (KW) and AES Key Wrap with Padding (KWP) to applications even if selected in FCS_COP.1/ENCRYPT. However, the ST author is expected to select AES-GCM or AES-CCM if it is selected in the ST for the FCS_COP.1/ENCRYPT component. - The evaluator shall verify that the API documentation provided according to - includes the security functions (cryptographic algorithms) + + The evaluator shall verify that the API documentation provided according to + includes the security functions (cryptographic algorithms) described in these requirements. There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. @@ -4480,33 +2058,23 @@ The evaluator shall generate 10 private/public key pairs using the key generatio requirements. - + - - + + requires the TSF to support its stored keys being usable by external applications through cryptographic algorithm services. There are no management activities foreseen. There are no auditable events foreseen. FCS_COP.1 Cryptographic Operation - - The TSF shall provide a mechanism for applications to request the TSF to perform - the following cryptographic operations: [<htm:i><htm:ul> - <htm:li>Algorithms in FCS_COP.1/ENCRYPT</htm:li> - <htm:li>Algorithms in FCS_COP.1/SIGN</htm:li> - </htm:ul></htm:i>] by keys stored in the secure key storage. - - The TSF shall provide a mechanism for applications to request the TSF to perform - the following cryptographic operations: - <assignable>cryptographic operations defined by the TSF in FCS_COP.1</assignable> - by keys stored in the secure key storage. - + The TSF shall provide a mechanism for applications to request the TSF to perform the following cryptographic operations: [ <htm:i><htm:ul><htm:li>Algorithms in FCS_COP.1/ENCRYPT</htm:li><htm:li>Algorithms in FCS_COP.1/SIGN</htm:li></htm:ul></htm:i> ] by keys stored in the secure key storage. The TOE will, therefore, be required to perform cryptographic operations on behalf of applications using the keys stored in the TOE’s secure key storage. - The evaluator shall verify that the API documentation for the secure key + + The evaluator shall verify that the API documentation for the secure key storage includes the cryptographic operations by the stored keys. There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. @@ -4518,198 +2086,103 @@ The evaluator shall generate 10 private/public key pairs using the key generatio Activities in FCS_STG_EXT.1. - + +
    • + +
    - - This family defines requirements for the implementation of secure key storage with access control, confidentiality, and integrity protections. - - - - The following requirements describe how keys are protected. All keys must ultimately be protected by a REK, and may optionally be protected by the user’s authentication factor. Each key’s confidentiality and integrity must be protected. This section also describes the secure key storage services to be provided by the Mobile Device for use by applications and users, applying the same level of protection for these keys as keys internal to the OS. - - - - - - - requires the TSF to implement a secure key storage and defines the access restrictions to be enforced on this. - The following actions could be considered for the management functions in FMT: - - Importing keys or secrets into the secure key storage. - Destroying imported keys or secrets in the secure key storage. - Approving exceptions for shared use of keys or secrets by multiple applications. - Approving exceptions for destruction of keys or secrets by applications that did not import the key or secret - - - The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - - Import or destruction of key. - Exceptions to use and destruction rules. - - - - [FCS_CKM.1 Cryptographic Key Generation, or - FDP_ITC.1 Import of User Data without Security Attributes, or - FDP_ITC.2 Import of User Data with Security Attributes] + + + + requires the TSF to implement a secure key storage and defines the access restrictions to be enforced on this. + The following actions could be considered for the management functions in FMT: + Importing keys or secrets into the secure key storage.Destroying imported keys or secrets in the secure key storage.Approving exceptions for shared use of keys or secrets by multiple applications.Approving exceptions for destruction of keys or secrets by applications that did not import the key or secret + The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: + Import or destruction of key.Exceptions to use and destruction rules. + + [FCS_CKM.1 Cryptographic Key Generation, or + FDP_ITC.1 Import of User Data without Security Attributes, or + FDP_ITC.2 Import of User Data with Security Attributes] FMT_SMR.1 Security Roles - - - - The TSF shall provide <selectables> - <selectable>mutable hardware</selectable> - <selectable id="s-software-store">software-based</selectable> - </selectables> secure key storage for asymmetric private keys and <selectables> - <selectable>symmetric keys</selectable> - <selectable>persistent secrets</selectable> - <selectable exclusive="yes">no other keys</selectable> - </selectables>. - - The TSF shall provide - <assignable>storage medium</assignable> - secure key storage for asymmetric private keys and - <assignable>list of secrets</assignable> - . - - - A hardware keystore can be exposed to the TSF through a variety + + The TSF shall provide<selectables><selectable id="fcs_stg_ext.1.1_1" >mutable hardware</selectable><selectable id="s-software-store" >software-based</selectable></selectables>secure key storage for asymmetric private keys and<selectables><selectable id="fcs_stg_ext.1.1_2" >symmetric keys</selectable><selectable id="fcs_stg_ext.1.1_3" >persistent secrets</selectable><selectable id="fcs_stg_ext.1.1_4" exclusive="yes" >no other keys</selectable></selectables>. + A hardware keystore can be exposed to the TSF through a variety of interfaces, including embedded on the motherboard, USB, microSD, and Bluetooth. Immutable hardware is considered outside of this requirement and will be covered elsewhere. If the secure key storage is implemented in software that is protected as required by FCS_STG_EXT.2, the ST author must select - . - If is selected, - the ST author must select in FCS_STG_EXT.2.1. - - s-software-store - s-all-software-key-store - - + . + If is selected, + the ST author must select in FCS_STG_EXT.2.1. + s-software-stores-all-software-key-store Support for secure key storage for all symmetric keys and persistent secrets will be required in future revisions. - - - - The TSF shall be capable of importing keys or secrets into the secure key storage - upon request of <selectables> - <selectable id="import-user">the user</selectable> - <selectable id="s-import-admin">the administrator</selectable> - </selectables> and <selectables> - <selectable>applications running on the TSF</selectable> - <selectable exclusive="yes">no other subjects</selectable> - </selectables>. - - The TSF shall be capable of importing keys or secrets into the secure key storage - upon request of <assignable>list of users</assignable> and <assignable>list of other subjects</assignable>. - - If the ST selects only , the ST author must select function in FMT_MOF_EXT.1.1. - - - - The TSF shall be capable of destroying keys or secrets in the secure key storage - upon request of <selectables> - <selectable>the user</selectable> - <selectable>the administrator</selectable> - </selectables>. - If the ST selects , the ST author must select function in FMT_MOF_EXT.1.1. - - - - The TSF shall have the capability to allow only the application that imported the - key or secret the use of the key or secret. Exceptions may only be explicitly authorized by <selectables> - <selectable>the user</selectable> - <selectable>the administrator</selectable> - <selectable>a common application developer</selectable> - </selectables>. - If the ST selects or , - the ST author must also select in FMT_SMF.1.1. - If the ST selects , the ST author must select function in FMT_MOF_EXT.1.1. + + + The TSF shall be capable of importing keys or secrets into the secure key storage upon request of<selectables><selectable id="import-user" >the user</selectable><selectable id="s-import-admin" >the administrator</selectable></selectables>and<selectables><selectable id="fcs_stg_ext.1.2_1" >applications running on the TSF</selectable><selectable id="fcs_stg_ext.1.2_2" exclusive="yes" >no other subjects</selectable></selectables>. + If the ST selects only , the ST author must select function in FMT_MOF_EXT.1.1. + + + The TSF shall be capable of destroying keys or secrets in the secure key storage upon request of<selectables><selectable id="fcs_stg_ext.1.3_1" >the user</selectable><selectable id="fcs_stg_ext.1.3_2" >the administrator</selectable></selectables>. + If the ST selects , the ST author must select function in FMT_MOF_EXT.1.1. + + + The TSF shall have the capability to allow only the application that imported the key or secret the use of the key or secret. Exceptions may only be explicitly authorized by<selectables><selectable id="fcs_stg_ext.1.4_1" >the user</selectable><selectable id="fcs_stg_ext.1.4_2" >the administrator</selectable><selectable id="fcs_stg_ext.1.4_3" >a common application developer</selectable></selectables>. + If the ST selects or , + the ST author must also select in FMT_SMF.1.1. + If the ST selects , the ST author must select function in FMT_MOF_EXT.1.1. - - - - The TSF shall allow only the application that imported the key or secret to request - that the key or secret be destroyed. Exceptions may only be explicitly authorized by <selectables> - <selectable id="s-killkey-user">the user</selectable> - <selectable id="s-killkey-admin">the administrator</selectable> - <selectable>a common application developer</selectable> - </selectables>. - - The TSF shall allow only the application that imported the key or secret to request - that the key or secret be destroyed. Exceptions may only be explicitly authorized by - <assignable>list of subjects</assignable>. - - - If the ST selects or , - the ST author must also select function in FMT_SMF.1.1. - If the ST selects only , - the ST author must select function in FMT_MOF_EXT.1.1. - The evaluator shall verify that the API documentation provided according to - includes the security functions (import, use, and + + + The TSF shall allow only the application that imported the key or secret to request that the key or secret be destroyed. Exceptions may only be explicitly authorized by<selectables><selectable id="s-killkey-user" >the user</selectable><selectable id="s-killkey-admin" >the administrator</selectable><selectable id="fcs_stg_ext.1.5_1" >a common application developer</selectable></selectables>. + If the ST selects or , + the ST author must also select function in FMT_SMF.1.1. + If the ST selects only , + the ST author must select function in FMT_MOF_EXT.1.1. + + The evaluator shall verify that the API documentation provided according to + includes the security functions (import, use, and destruction) described in these requirements. The API documentation shall include the method by which applications restrict access to their keys or secrets in order to meet FCS_STG_EXT.1.4. - The evaluator shall review the TSS to determine that the TOE implements the + The evaluator shall review the TSS to determine that the TOE implements the required secure key storage. The evaluator shall ensure that the TSS contains a description of the key storage mechanism that justifies the selection of "mutable - hardware" or "software-based". - - The evaluator shall review the AGD guidance to determine that it describes - the steps needed to import or destroy keys or secrets. - - The evaluator shall test the functionality of each security function: + hardware" or "software-based". + The evaluator shall review the AGD guidance to determine that it describes + the steps needed to import or destroy keys or secrets. + + + The evaluator shall test the functionality of each security function: The evaluator shall import keys or secrets of each supported type according to the AGD guidance. The evaluator shall write, or the developer shall provide access to, an application that generates a key or secret of each supported type and calls the import functions. The evaluator shall verify that no errors occur - during import. + during import. The evaluator shall write, or the developer shall provide access to, an - application that uses an imported key or secret: - - For RSA, the secret shall be used to sign data. - For ECDSA, the secret shall be used to sign data - - In the future additional types will be required to be tested: - - For symmetric algorithms, the secret shall be used to encrypt - data. - For persistent secrets, the secret shall be compared to the imported - secret. - - The evaluator shall repeat this test with the application-imported + application that uses an imported key or secret: For RSA, the secret shall be used to sign data.For ECDSA, the secret shall be used to sign data In the future additional types will be required to be tested: For symmetric algorithms, the secret shall be used to encrypt + data.For persistent secrets, the secret shall be compared to the imported + secret. The evaluator shall repeat this test with the application-imported keys or secrets and a different application’s imported keys or secrets. The evaluator shall verify that the TOE requires approval before allowing the application to - use the key or secret imported by the user or by a different application: - - The evaluator shall deny the approvals to verify that the application - is not able to use the key or secret as described. - The evaluator shall repeat the test, allowing the approvals to verify - that the application is able to use the key or secret as described. - - If the ST author has selected "common application developer", this + use the key or secret imported by the user or by a different application: The evaluator shall deny the approvals to verify that the application + is not able to use the key or secret as described. The evaluator shall repeat the test, allowing the approvals to verify + that the application is able to use the key or secret as described. If the ST author has selected "common application developer", this test is performed by either using applications from different developers or appropriately (according to API documentation) not authorizing sharing. - + The evaluator shall destroy keys or secrets of each supported type according to the AGD guidance. The evaluator shall write, or the developer shall provide access to, an application that destroys an imported key or secret. @@ -4717,76 +2190,48 @@ The evaluator shall generate 10 private/public key pairs using the key generatio application-imported keys or secrets and a different application’s imported keys or secrets. The evaluator shall verify that the TOE requires approval before allowing the application to destroy the key or secret imported by the administrator - or by a different application: - - The evaluator shall deny the approvals and verify that the application - is still able to use the key or secret as described. - The evaluator shall repeat the test, allowing the approvals and + or by a different application: The evaluator shall deny the approvals and verify that the application + is still able to use the key or secret as described. The evaluator shall repeat the test, allowing the approvals and verifying that the application is no longer able to use the key or secret as - described. - - If the ST author has selected "common application developer", this + described. If the ST author has selected "common application developer", this test is performed by either using applications from different developers or appropriately (according to API documentation) not authorizing sharing. - - - - - Import or destruction of key - Identity of key, role and identity of requester - - - Exceptions to use and destruction rulesnone - Identity of key, role and identity of requester - - - - - - - - requires the TSF to implement confidentiality measures to protect the key storage. - There are no management activities foreseen. + + + + + Import or destruction of key + Identity of key, role and identity of requester + + + + + Exceptions to use and destruction rules + none + + + Identity of key, role and identity of requester + + + + + requires the TSF to implement confidentiality measures to protect the key storage. + There are no management activities foreseen. - There are no auditable events foreseen. + There are no auditable events foreseen. - - FCS_COP.1 Cryptographic Operation + + FCS_COP.1 Cryptographic Operation FCS_STG_EXT.1 Cryptographic Key Storage - - - The TSF shall encrypt all DEKs, KEKs, <assignable>any long-term trusted channel - key material</assignable> and <selectables> - <selectable id="s-all-software-key-store">all software-based key storage</selectable> - <selectable exclusive="yes">no other keys</selectable> - </selectables> by KEKs that are <selectables linebreak="yes"> - <selectable>Protected by the REK with <selectables linebreak="yes"> - <selectable>encryption by a REK</selectable> - <selectable>encryption by a KEK chaining from a REK</selectable> - <selectable>encryption by a KEK that is derived from a REK</selectable> - </selectables> - </selectable> - <selectable>Protected by the REK and the password with <selectables linebreak="yes"> - <selectable>encryption by a REK and the password-derived KEK</selectable> - <selectable>encryption by a KEK chaining to a REK and the password-derived or - biometric-unlocked KEK</selectable> - <selectable>encryption by a KEK that is derived from a REK and the - password-derived or biometric-unlocked KEK</selectable> - </selectables> - </selectable> - </selectables>. - - The TSF shall encrypt all DEKs, KEKs, <assignable>any long-term trusted channel - key material</assignable> and - <assignable>other secrets </assignable> - by KEKs that are - <assignable>protection mechanism</assignable>. - - The ST author must select - if is selected in FCS_STG_EXT.1.1. - If the ST author selects in FCS_STG_EXT.1.1, + + The TSF shall encrypt all DEKs, KEKs,<assignable>any long-term trusted channel key material</assignable>and<selectables><selectable id="s-all-software-key-store" >all software-based key storage</selectable><selectable id="fcs_stg_ext.2.1_2" exclusive="yes" >no other keys</selectable></selectables>by KEKs that are<selectables><selectable id="fcs_stg_ext.2.1_3">Protected by the REK with <selectables><selectable id="fcs_stg_ext.2.1_4" >encryption by a REK</selectable><selectable id="fcs_stg_ext.2.1_5" >encryption by a KEK chaining from a REK</selectable><selectable id="fcs_stg_ext.2.1_6" >encryption by a KEK that is derived from a REK</selectable></selectables></selectable><selectable id="fcs_stg_ext.2.1_7">Protected by the REK and the password with <selectables><selectable id="fcs_stg_ext.2.1_8" >encryption by a REK and the password-derived KEK</selectable><selectable id="fcs_stg_ext.2.1_9" >encryption by a KEK chaining to a REK and the password-derived or + biometric-unlocked KEK</selectable><selectable id="fcs_stg_ext.2.1_10" >encryption by a KEK that is derived from a REK and the + password-derived or biometric-unlocked KEK</selectable></selectables></selectable></selectables>. + The ST author must select + if is selected in FCS_STG_EXT.1.1. + If the ST author selects in FCS_STG_EXT.1.1, the secure key storage is not subject to this requirement. REKs are not subject to this requirement. A REK and @@ -4794,8 +2239,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio FCS_CKM_EXT.3) in order to meet this requirement. Software-based key storage must be protected by the password or biometric and REK. - All keys must ultimately be protected by a REK. In particular, has KEKs protected according to these requirements: DEK_1 meets the + All keys must ultimately be protected by a REK. In particular, has KEKs protected according to these requirements: DEK_1 meets the "encryption by a REK and the password-derived KEK" case and would be appropriate for sensitive data, DEK_2 meets the "encryption by a KEK chaining from a REK" case and would not be appropriate for sensitive data, K_1 meets the "encryption by a REK" case and is not considered a sensitive key, @@ -4805,8 +2249,8 @@ The evaluator shall generate 10 private/public key pairs using the key generatio as they may be necessary in the locked state. For clarity, the ST author must assign any Long-term trusted channel key material supported by the TOE . At a minimum, a TOE must support at least Wi-Fi and Bluetooth keys. - - The evaluator shall review the TSS to determine that the TSS includes key + + The evaluator shall review the TSS to determine that the TSS includes key hierarchy description of the protection of each DEK for data-at-rest, of software-based key storage, of long-term trusted channel keys, and of KEK related to the protection of the DEKs, long-term trusted channel keys, and software-based key @@ -4818,217 +2262,105 @@ The evaluator shall generate 10 private/public key pairs using the key generatio derived, or combined according to FCS_CKM_EXT.3), the integrity protection method for each encrypted key (FCS_STG_EXT.3), and the IV generation for each key encrypted by the same KEK (FCS_IV_EXT.1). More detail for each task follows the corresponding - requirement. - The evaluator shall also ensure that the documentation of the product's encryption key + requirement. The evaluator shall also ensure that the documentation of the product's encryption key management is detailed enough that, after reading, the product's key management hierarchy is clear and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as - separate proprietary evidence rather than being included in the TSS. - - - - - - - DEKs, KEKs, <assignable>any long-term trusted channel key material</assignable> - and <selectables> - <selectable>all software-based key storage</selectable> - <selectable exclusive="yes">no other keys</selectable> - </selectables> shall be encrypted using one of the following methods: <selectables> - <selectable>using a SP800-56B key establishment scheme</selectable> - <selectable>using AES in the <selectables> - <selectable>Key Wrap (KW) mode</selectable> - <selectable>Key Wrap with Padding (KWP) mode</selectable> - <selectable>GCM</selectable> - <selectable>CCM</selectable> - <selectable>CBC mode</selectable> - </selectables></selectable> - </selectables>. - The ST author selects which key encryption schemes are used by + separate proprietary evidence rather than being included in the TSS. + + + + DEKs, KEKs,<assignable>any long-term trusted channel key material</assignable>and<selectables><selectable id="fcs_stg_ext.2.2_2" >all software-based key storage</selectable><selectable id="fcs_stg_ext.2.2_3" exclusive="yes" >no other keys</selectable></selectables>shall be encrypted using one of the following methods:<selectables><selectable id="fcs_stg_ext.2.2_4" >using a SP800-56B key establishment scheme</selectable><selectable id="fcs_stg_ext.2.2_5">using AES in the <selectables><selectable id="fcs_stg_ext.2.2_6" >Key Wrap (KW) mode</selectable><selectable id="fcs_stg_ext.2.2_7" >Key Wrap with Padding (KWP) mode</selectable><selectable id="fcs_stg_ext.2.2_8" >GCM</selectable><selectable id="fcs_stg_ext.2.2_9" >CCM</selectable><selectable id="fcs_stg_ext.2.2_10" >CBC mode</selectable></selectables></selectable></selectables>. + The ST author selects which key encryption schemes are used by the TOE. This requirement refers only to KEKs as defined this PP and does not refer to those KEKs specified in other standards. The ST author must assign the same Long-term trusted channel key material assigned in FCS_STG_EXT.2.1. - - The evaluator shall examine the key hierarchy description in the TSS section to + + The evaluator shall examine the key hierarchy description in the TSS section to verify that each DEK and software-stored key is encrypted according to FCS_STG_EXT.2. - There are no guidance evaluation activities for this component. - There are no test evaluation activities for this component. - - - - - - - requires the TSF to implement integrity measures to protect the key storage. - There are no management activities foreseen. + There are no guidance evaluation activities for this component. + There are no test evaluation activities for this component. + + + + + + + requires the TSF to implement integrity measures to protect the key storage. + There are no management activities foreseen. - The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - - Failure to verify the integrity of stored key. - - - - FCS_COP.1 Cryptographic Operation + The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: + Failure to verify the integrity of stored key. + + FCS_COP.1 Cryptographic Operation FCS_STG_EXT.2 Encrypted Cryptographic Key Storage - - - The TSF shall protect the integrity of any encrypted DEKs and KEKs and <selectables> - <selectable>long-term trusted channel key material</selectable> - <selectable>all software-based key storage</selectable> - <selectable exclusive="yes">no other keys</selectable> - </selectables> by <selectables linebreak="yes"> - <selectable><selectables> - <selectable>GCM</selectable> - <selectable>CCM</selectable> - <selectable>Key Wrap</selectable> - <selectable>Key Wrap with Padding</selectable> - </selectables> cipher mode for encryption according to FCS_STG_EXT.2</selectable> - <selectable>a hash (FCS_COP.1<htm:b>/HASH</htm:b>) of the stored key that is encrypted by a key - protected by FCS_STG_EXT.2</selectable> - <selectable>a keyed hash (FCS_COP.1<htm:b>/KEYHMAC</htm:b>) using a key protected by a key - protected by FCS_STG_EXT.2</selectable> - <selectable>a digital signature of the stored key using an asymmetric key protected - according to FCS_STG_EXT.2</selectable> - <selectable>an immediate application of the key for decrypting the protected data + <f-element id="fel-protect-key-what"> + <title>The TSF shall protect the integrity of any encrypted DEKs and KEKs and<selectables><selectable id="fcs_stg_ext.3.1_1" >long-term trusted channel key material</selectable><selectable id="fcs_stg_ext.3.1_2" >all software-based key storage</selectable><selectable id="fcs_stg_ext.3.1_3" exclusive="yes" >no other keys</selectable></selectables>by<selectables><selectable id="fcs_stg_ext.3.1_4"><selectables><selectable id="fcs_stg_ext.3.1_5" >GCM</selectable><selectable id="fcs_stg_ext.3.1_6" >CCM</selectable><selectable id="fcs_stg_ext.3.1_7" >Key Wrap</selectable><selectable id="fcs_stg_ext.3.1_8" >Key Wrap with Padding</selectable></selectables> cipher mode for encryption according to FCS_STG_EXT.2</selectable><selectable id="fcs_stg_ext.3.1_9" >a hash (FCS_COP.1<htm:b>/HASH</htm:b>) of the stored key that is encrypted by a key + protected by FCS_STG_EXT.2</selectable><selectable id="fcs_stg_ext.3.1_10" >a keyed hash (FCS_COP.1<htm:b>/KEYHMAC</htm:b>) using a key protected by a key + protected by FCS_STG_EXT.2</selectable><selectable id="fcs_stg_ext.3.1_11" >a digital signature of the stored key using an asymmetric key protected + according to FCS_STG_EXT.2</selectable><selectable id="fcs_stg_ext.3.1_12" >an immediate application of the key for decrypting the protected data followed by a successful verification of the decrypted data with previously known - information</selectable> - </selectables>. - - - The TSF shall protect the integrity of any encrypted DEKs and KEKs and <selectables> - <selectable>long-term trusted channel key material</selectable> - <selectable>all software-based key storage</selectable> - <selectable exclusive="yes">no other keys</selectable> - </selectables> by <selectables linebreak="yes"> - <selectable><selectables> - <selectable>GCM</selectable> - <selectable>CCM</selectable> - <selectable>Key Wrap</selectable> - <selectable>Key Wrap with Padding</selectable> - </selectables> cipher mode for encryption according to FCS_STG_EXT.2</selectable> - <selectable>a hash (FCS_COP.1) of the stored key that is encrypted by a key - protected by FCS_STG_EXT.2</selectable> - <selectable>a keyed hash (FCS_COP.1) using a key protected by a key - protected by FCS_STG_EXT.2</selectable> - <selectable>a digital signature of the stored key using an asymmetric key protected - according to FCS_STG_EXT.2</selectable> - <selectable>an immediate application of the key for decrypting the protected data - followed by a successful verification of the decrypted data with previously known - information</selectable> - </selectables>. - - - The ST author must assign the same Long-term trusted channel + information. + The ST author must assign the same Long-term trusted channel key material assigned in FCS_STG_EXT.2.1. - - - The TSF shall verify the integrity of the <selectables> - <selectable>hash</selectable> - <selectable>digital signature</selectable> - <selectable>MAC</selectable> - </selectables> of the stored key prior to use of the key. - This requirement is not applicable to derived keys that are not + + + The TSF shall verify the integrity of the<selectables><selectable id="fcs_stg_ext.3.2_1" >hash</selectable><selectable id="fcs_stg_ext.3.2_2" >digital signature</selectable><selectable id="fcs_stg_ext.3.2_3" >MAC</selectable></selectables>of the stored key prior to use of the key. + This requirement is not applicable to derived keys that are not stored. It is not expected that a single key will be protected from corruption by multiple of these methods; however, a product may use one integrity-protection method for one type of key and a different method for other types of keys. The explicit Evaluation Activities for each of the options will be addressed in each of the requirements (FCS_COP.1.1/HASH, FCS_COP.1.1/KEYHMAC). Key Wrapping must be implemented per SP800-38F. - - The evaluator shall examine the key hierarchy description in the TSS section to + + The evaluator shall examine the key hierarchy description in the TSS section to verify that each encrypted key is integrity protected according to one of the - options in FCS_STG_EXT.3. - The evaluator shall also ensure that the documentation of the product's encryption key + options in FCS_STG_EXT.3. The evaluator shall also ensure that the documentation of the product's encryption key management is detailed enough that, after reading, the product's key management hierarchy is clear and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as - separate proprietary evidence rather than being included in the TSS. - - There are no guidance evaluation activities for this component. - There are no test evaluation activities for this component. - - - - Failure to verify integrity of stored key - Identity of key being verified - - - - - - + separate proprietary evidence rather than being included in the TSS. + There are no guidance evaluation activities for this component. + There are no test evaluation activities for this component. + + + + Failure to verify integrity of stored key + Identity of key being verified + + +
    + +
    + A subset of the User Data Protection focuses on protecting Data-At-Rest, namely FDP_DAR_EXT.1 and FDP_DAR_EXT.2. Three levels of data-at-rest protection are addressed: TSF data, Protected Data (and keys), and sensitive data. - addresses the level of protection required for each level of data-at-rest. - - : Protection of Data Levels - - - Data LevelProtection Required - TSF DataTSF data does not require confidentiality, but does require integrity protection. (FPT_TST_EXT.2/PREKERNEL) - Protected DataProtected data is encrypted while powered off. (FDP_DAR_EXT.1) - Sensitive DataSensitive data is encrypted while in the locked state, in addition to while powered off. (FDP_DAR_EXT.2) - - - All keys, protected data, and sensitive data must ultimately be protected by the REK. Sensitive data must be protected by the password in addition to the REK. In particular, has KEKs protected according to these requirements: DEK_1 would be appropriate for sensitive data, DEK_2 would not be appropriate for sensitive data, K_1 is not considered a sensitive key, and K_2 is considered a sensitive key. + addresses the level of protection required for each level of data-at-rest. + : Protection of Data Levels Data LevelProtection RequiredTSF DataTSF data does not require confidentiality, but does require integrity protection. (FPT_TST_EXT.2/PREKERNEL)Protected DataProtected data is encrypted while powered off. (FDP_DAR_EXT.1)Sensitive DataSensitive data is encrypted while in the locked state, in addition to while powered off. (FDP_DAR_EXT.2) + All keys, protected data, and sensitive data must ultimately be protected by the REK. Sensitive data must be protected by the password in addition to the REK. In particular, has KEKs protected according to these requirements: DEK_1 would be appropriate for sensitive data, DEK_2 would not be appropriate for sensitive data, K_1 is not considered a sensitive key, and K_2 is considered a sensitive key. These requirements include a capability for encrypting sensitive data received while in the locked state, which may be considered a separate sub-category of sensitive data. This capability may be met by a key transport scheme (RSA) by using a public key to encrypt the DEK while protecting the corresponding private key with a password-derived or biometric-unlocked KEK. This capability may also be met by a key agreement scheme. To do so, the device generates a device-wide sensitive data asymmetric pair (the private key of which is protected by a password-derived or biometric-unlocked KEK) and an asymmetric pair for the received sensitive data to be stored. In order to store the sensitive data, the device-wide public key and data private key are used to generate a shared secret, which can be used as a KEK or a DEK. The data private key and shared secret are cleared after the data is encrypted and the data public key stored. Thus, no key material is available in the locked state to decrypt the newly stored data. Upon unlock, the device-wide private key is decrypted and is used with each data public key to regenerate the shared secret and decrypt the stored data. - , below, illustrates this scheme. -
    - - - - - This family defines the rules for access control functions that are not addressed by the FDP_ACF family in CC Part 2. - - - - - - - requires the TSF to be able to control access to its own services. - The following actions could be considered for the management functions in FMT: - - Placing applications into application groups based on enterprise configuration settings. - Enabling/disabling location services. - Enabling/disabling data signaling over externally-accessible hardware ports. - - - There are no auditable events foreseen. - FMT_SMR.1 Security Roles - - + , below, illustrates this scheme.
    + + + requires the TSF to be able to control access to its own services. + The following actions could be considered for the management functions in FMT: + Placing applications into application groups based on enterprise configuration settings.Enabling/disabling location services.Enabling/disabling data signaling over externally-accessible hardware ports. + There are no auditable events foreseen. + FMT_SMR.1 Security Roles - The TSF shall provide a mechanism to restrict the system services that are - accessible to an application. + The TSF shall provide a mechanism to restrict the system services that are accessible to an application. Examples of system services to which this requirement applies - include: - - Obtain data from camera and microphone input devices - Obtain current device location - Retrieve credentials from system-wide credential store - Retrieve contacts list / address book - Retrieve stored pictures - Retrieve text messages - Retrieve emails - Retrieve device identifier information - Obtain network access - - + include: Obtain data from camera and microphone input devicesObtain current device locationRetrieve credentials from system-wide credential storeRetrieve contacts list / address bookRetrieve stored picturesRetrieve text messagesRetrieve emailsRetrieve device identifier informationObtain network access The evaluator shall ensure the TSS lists all system services available for use by an application. The evaluator shall also ensure that the TSS describes how applications interface with these system services, and means by which these system services are protected by the TSF. The TSS shall describe which - of the following categories each system service falls in: - - No applications are allowed access - Privileged applications are allowed access - Applications are allowed access by user authorization - All applications are allowed access - Privileged applications include any applications developed by the TSF + of the following categories each system service falls in:No applications are allowed accessPrivileged applications are allowed accessApplications are allowed access by user authorizationAll applications are allowed access Privileged applications include any applications developed by the TSF developer. The TSS shall describe how privileges are granted to third-party applications. For both types of privileged applications, the TSS shall describe how and when the privileges are verified and how the TSF prevents unprivileged @@ -5037,15 +2369,9 @@ The evaluator shall generate 10 private/public key pairs using the key generatio whether the user is prompted for authorization when the application is installed, or during runtime. The evaluator shall ensure that the operational user guidance contains instructions for restricting application access to system services. - - + There are no guidance evaluation activities for this element. - Evaluation Activity Note: The following tests require the vendor to - provide access to a test platform that provides the evaluator with tools that are - typically not found on consumer Mobile Device products. The - evaluator shall write, or the developer shall provide, applications for the purposes - of the following tests. For each system service to which no applications are allowed access, the evaluator shall attempt to access the system service with a test application and @@ -5070,43 +2396,19 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - The TSF shall provide an access control policy that prevents <selectables> - <selectable id="s-fdp-app">application</selectable> - <selectable id="fdp_group">groups of applications</selectable> - </selectables> from accessing <selectables> - <selectable>all</selectable> - <selectable id="s-private">private</selectable> - </selectables> data stored by other <selectables> - <selectable>application</selectable> - <selectable>groups of applications</selectable> - </selectables>. Exceptions may only be explicitly authorized for such sharing by <selectables> - <selectable id="s-acl-user">the user</selectable> - <selectable id="s-acl-admin">the administrator</selectable> - <selectable id="s-acl-devel">a common application developer</selectable> - <selectable>no one</selectable> - </selectables>. - - The TSF shall provide an access control policy that prevents - <assignable>list of subjects</assignable> from accessing - <selectables><selectable>all</selectable><selectable>private</selectable> - </selectables> data stored by other <assignable>list of subjects</assignable>. - Exceptions may only be explicitly authorized for such sharing by - <assignable>list of authorized subjects</assignable>. - + The TSF shall provide an access control policy that prevents<selectables><selectable id="s-fdp-app" >application</selectable><selectable id="fdp_group" >groups of applications</selectable></selectables>from accessing<selectables><selectable id="fdp_acf_ext.1.2_1" >all</selectable><selectable id="s-private" >private</selectable></selectables>data stored by other<selectables><selectable id="fdp_acf_ext.1.2_2" >application</selectable><selectable id="fdp_acf_ext.1.2_3" >groups of applications</selectable></selectables>. Exceptions may only be explicitly authorized for such sharing by<selectables><selectable id="s-acl-user" >the user</selectable><selectable id="s-acl-admin" >the administrator</selectable><selectable id="s-acl-devel" >a common application developer</selectable><selectable id="fdp_acf_ext.1.2_4" >no one</selectable></selectables>. Application groups may be designated Enterprise or Personal. Applications installed by the user default to being in the Personal application group - unless otherwise designated by the administrator in function of FMT_SMF.1.1. Applications installed by the administrator + unless otherwise designated by the administrator in function of FMT_SMF.1.1. Applications installed by the administrator default to being in the Enterprise application group (this category includes applications that the user requests the administrator install, for instance by selecting the application for installation through an enterprise application catalog) - unless otherwise designated by the administrator in function of FMT_SMF.1.1. It is acceptable for the same application to + unless otherwise designated by the administrator in function of FMT_SMF.1.1. It is acceptable for the same application to have multiple instances installed, each in different application groups. Private data is defined as data that is accessible only by the application that wrote it. Private data is distinguished from data that an application may, by design, write to shared storage areas. - If is selected, FDP_ACF_EXT.2 must be included in the ST. + If is selected, FDP_ACF_EXT.2 must be included in the ST. The evaluator shall examine the TSS to verify that it describes which data @@ -5120,62 +2422,46 @@ The evaluator shall generate 10 private/public key pairs using the key generatio The evaluator shall write, or the developer shall provide, two applications, one that saves data containing a unique string and the other, which attempts to access that data. - If is selected, the applications + If is selected, the applications shall be placed into different groups. - If is selected, the + If is selected, the evaluator shall install the two applications. - If is selected, the + If is selected, the application shall not write to a designated shared storage area. The evaluator shall verify that the second application is unable to access the stored unique - string. If is selected, the evaluator shall grant + string. If is selected, the evaluator shall grant access as the user and verify that the second application is able to access the stored unique string. - If is selected, the + If is selected, the evaluator shall grant access as the administrator and verify that the second application is able to access the stored unique string. - If is selected, the evaluator shall grant access to + If is selected, the evaluator shall grant access to an, application with a common application developer to the first, and verify that the application is able to access the stored unique string. - - + + - + + - requires the TSF to be able to provide separate copies of system resources for different application groups. The following actions could be considered for the management functions in FMT: - - Approving exceptions for sharing data between applications or groups of applications. - - + Approving exceptions for sharing data between applications or groups of applications. There are no auditable events foreseen. - FDP_ACF_EXT.1 Access Control for System Services + FDP_ACF_EXT.1 Access Control for System Services FMT_SMR.1 Security Roles - - The TSF shall provide a separate <selectables> - <selectable>address book</selectable> - <selectable>calendar</selectable> - <selectable>keystore</selectable> - <selectable>account credential database, <assignable>list of additional - resources</assignable></selectable> - </selectables> for each application group and only allow applications within that - process group to access the resource. Exceptions may only be explicitly authorized for - such sharing by <selectables> - <selectable>the user</selectable> - <selectable>the administrator</selectable> - <selectable>no one</selectable> - </selectables>. - If is selected in FDP_ACF_EXT.1.2, + The TSF shall provide a separate<selectables><selectable id="fdp_acf_ext.2.1_1" >address book</selectable><selectable id="fdp_acf_ext.2.1_2" >calendar</selectable><selectable id="fdp_acf_ext.2.1_3" >keystore</selectable><selectable id="fdp_acf_ext.2.1_4">account credential database, <assignable>list of additional resources </assignable></selectable></selectables>for each application group and only allow applications within that process group to access the resource. Exceptions may only be explicitly authorized for such sharing by<selectables><selectable id="fdp_acf_ext.2.1_6" >the user</selectable><selectable id="fdp_acf_ext.2.1_7" >the administrator</selectable><selectable id="fdp_acf_ext.2.1_8" >no one</selectable></selectables>. + If is selected in FDP_ACF_EXT.1.2, FDP_ACF_EXT.2 must be included in the ST. - + There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. For each selected resource, the evaluator shall cause data to be placed into @@ -5184,29 +2470,22 @@ The evaluator shall generate 10 private/public key pairs using the key generatio information and verify that it cannot access the information. - - + + - - + + requires the TSF to enforce policies on applications that prohibit write and execute permissions from being granted simultaneously. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. - - The TSF shall enforce an access control policy that prohibits an application from - granting both write and execute permission to a file on the device except for <selectables> - <selectable>files stored in the application's private data folder</selectable> - <selectable>no exceptions</selectable> - </selectables>. - + The TSF shall enforce an access control policy that prohibits an application from granting both write and execute permission to a file on the device except for<selectables><selectable id="fdp_acf_ext.3.1_1" >files stored in the application's private data folder</selectable><selectable id="fdp_acf_ext.3.1_2" >no exceptions</selectable></selectables>. + There are no TSS evaluation activities for this component. - There are no guidance evaluation activities for this component. - Evaluation Activity Note: The following tests require the developer to - provide access to a test platform that provides the evaluator with tools that are - typically not found on consumer Mobile Device products. + There are no guidance evaluation activities for this component. + The evaluator shall write, or the developer shall provide, an application that attempts to store a file with both write and execute permissions. If the @@ -5223,52 +2502,35 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - - + + - - - This family defines requirements for managing device backups. - - - - - - + + requires the TSF to be able to determine which data to include in backup operations. The following actions could be considered for the management functions in FMT: - - Enable/disable backup of certain applications to a local or remote system. - - + Enable/disable backup of certain applications to a local or remote system. There are no auditable events foreseen. No dependencies. - - - The TSF shall provide a mechanism for applications to mark <selectables> - <selectable id="s-all-app-data">all application data</selectable> - <selectable id="s-sel-app-data">selected application data</selectable> - </selectables> to be excluded from device backups. - The TSF shall provide a mechanism for applications to mark <assignable>list of data categories </assignable> to be excluded from device backups. - + The TSF shall provide a mechanism for applications to mark<selectables><selectable id="s-all-app-data" >all application data</selectable><selectable id="s-sel-app-data" >selected application data</selectable></selectables>to be excluded from device backups. Device backups include any mechanism built into the TOE that allows stored application data to be extracted over a physical port or sent over the network, but does not include any functionality implemented by a specific application itself if the application is not included in the TOE. The lack of a public/documented API for performing backups, when a private/undocumented API exists, is not sufficient to meet this requirement. - + There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. - If is selected, the evaluator shall install an + If is selected, the evaluator shall install an application that has marked all of its application data to be excluded from backups. The evaluator shall cause data to be placed into the application’s storage area. The evaluator shall attempt to back up the application data and verify that the backup fails or that the application’s data was not included in the backup. - If is selected, the evaluator shall + If is selected, the evaluator shall install an application that has marked selected application data to be excluded from backups. The evaluator shall cause data covered by "selected application data" to be placed into the application’s storage area. The evaluator shall attempt to backup @@ -5276,111 +2538,47 @@ The evaluator shall generate 10 private/public key pairs using the key generatio selected data is excluded from the backup. - - + + - - - This family defines requirements for managing Bluetooth devices. - - - - - - + + requires the TSF to manage which applications communicate with Bluetooth devices. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. - - - - The TSF shall limit the applications that may communicate with a particular paired Bluetooth device. - - + + The TSF shall limit the applications that may communicate with a particular paired Bluetooth device. + Not every application with privileges to use Bluetooth should be permitted to communicate with every paired Bluetooth device. For example, the TSF may choose to require that only the application that initiated the current connection may communicate with the device, or it may strictly tie the paired device to the first application that makes a socket connection to the device following initial pairing. Additionally, for more flexibility, the TSF may choose to provide the user with a way to select which applications on the device may communicate with or observe communications with each paired Bluetooth device. - - The evaluator shall ensure that the TSS describes the mechanism used to prevent unrestricted access to paired Bluetooth devices (or their communication data) by every application with access to the Bluetooth system service on the TOE. The evaluator shall verify that this method either restricts access to a single application or provides explicit control of the applications that may communicate with the paired Bluetooth device. - The evaluator shall verify that the AGD contains the steps to configure which applications are allowed to communicate with a given Bluetooth peripheral. - The evaluator shall establish a Bluetooth connection with any peripheral. The evaluator shall verify that an application that is allowed to communicate with the Bluetooth peripheral is able to and that an application that is not allowed to communicate with that Bluetooth peripheral is unable to communicate with the peripheral. - - - - - - - - This family defines requirements for implementation of data-at-rest protection. - - - - - + + + requires the TSF to be able to protect all data with a chosen method of encryption. The following actions could be considered for the management functions in FMT: - - Enabling data-at-rest protection. - Enabling removable media’s data-at-rest protection. - - + Enabling data-at-rest protection.Enabling removable media’s data-at-rest protection. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - - Failure to encrypt/decrypt data. - + Failure to encrypt/decrypt data. FCS_COP.1 Cryptographic Operation - - - Encryption shall cover all protected data. + Encryption shall cover all protected data. Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well. - Encryption shall be performed using DEKs with AES in the <selectables> - <selectable>XTS</selectable> - <selectable>CBC</selectable> - <selectable>GCM</selectable> - </selectables> mode with key size <selectables> - <selectable>128</selectable> - <selectable id="s-dar-256">256</selectable> - </selectables> bits. - - Encryption shall be performed using DEKs with AES in the - <assignable>list of AES modes</assignable> mode with key size - <assignable>list of acceptable key sizes</assignable> bits. - - + Encryption shall be performed using DEKs with AES in the<selectables><selectable id="fdp_dar_ext.1.2_1" >XTS</selectable><selectable id="fdp_dar_ext.1.2_2" >CBC</selectable><selectable id="fdp_dar_ext.1.2_3" >GCM</selectable></selectables>mode with key size<selectables><selectable id="fdp_dar_ext.1.2_4" >128</selectable><selectable id="s-dar-256" >256</selectable></selectables>bits. IVs must be generated in accordance with FCS_IV_EXT.1.1. - + The evaluator shall verify that the TSS section of the ST indicates which data is protected by the DAR implementation and what data is considered TSF data. The evaluator shall ensure that this data includes all protected data. @@ -5390,12 +2588,8 @@ The evaluator shall generate 10 private/public key pairs using the key generatio user to perform any actions beyond configuration and providing the authentication credential. The evaluator shall also review the AGD guidance to determine that the configuration does not require the user to identify encryption on a per-file basis. - - + - Evaluation Activity Note: The following test requires the developer to - provide access to a test platform that provides the evaluator with tools that are - typically not found on consumer Mobile Device products. The evaluator shall enable encryption according to the AGD guidance. The evaluator shall create user data (non-system) either by creating a file or by @@ -5406,31 +2600,27 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - - Failure to encrypt/decrypt datanone - + + + + Failure to encrypt/decrypt data + none + + + - - + + requires the TSF to protect the Trust Anchor Database. - The following actions could be considered for the management functions in FMT: - Importing X.509v3 certificates into the Trust Anchor Database. - Removing imported X.509v3 certificates from the Trust Anchor Database. - Approving import and removal by applications of X.509v3 certificates in the Trust Anchor Database. - - + The following actions could be considered for the management functions in FMT: Importing X.509v3 certificates into the Trust Anchor Database.Removing imported X.509v3 certificates from the Trust Anchor Database.Approving import and removal by applications of X.509v3 certificates in the Trust Anchor Database. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - - Addition or removal of certificate from Trust Anchor Database - - FCS_COP.1 Cryptographic Operation - FCS_CKM.2 Cryptographic Key Establishment + Addition or removal of certificate from Trust Anchor Database + FCS_COP.1 Cryptographic Operation + FCS_CKM.2 Cryptographic Key Establishment FCS_STG_EXT.2 Encrypted Cryptographic Key Storage - - The TSF shall provide a mechanism for applications to mark data and keys as - sensitive. + The TSF shall provide a mechanism for applications to mark data and keys as sensitive. Data and keys that have been marked as sensitive will be subject to certain restrictions (through other requirements) in both the locked and unlocked states of the Mobile Device. This mechanism allows an application to choose @@ -5448,20 +2638,17 @@ The evaluator shall generate 10 private/public key pairs using the key generatio keys as sensitive. This description shall also contain information reflecting how data and keys marked in this manner are distinguished from data and keys that are not (for instance, tagging, segregation in a "special" area of memory or container, - etc.). - + etc.). There are no guidance evaluation activities for this element. The evaluator shall enable encryption of sensitive data and require user authentication according to the AGD guidance. The evaluator shall try to access and create sensitive data (as defined in the ST and either by creating a file or using an application to generate sensitive data) in order to verify that no - other user interaction is required. - + other user interaction is required. - The TSF shall use an asymmetric key scheme to encrypt and store sensitive data - received while the product is locked. + The TSF shall use an asymmetric key scheme to encrypt and store sensitive data received while the product is locked. Sensitive data is encrypted according to FDP_DAR_EXT.1.2. The asymmetric key scheme must be performed in accordance with FCS_CKM.2/LOCKED. The intent of this requirement is to allow the device to receive @@ -5478,7 +2665,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio key of an asymmetric pair (the RSA private key and the device-wide private key, respectively) be cleared when transitioning to the locked state. - The evaluator shall review the TSS section of the ST to determine that the TSS + The evaluator shall review the TSS section of the ST to determine that the TSS includes a description of the process of receiving sensitive data while the device is in a locked state. The evaluator shall also verify that the description indicates if sensitive data that may be received in the locked state is treated differently @@ -5488,8 +2675,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio being decrypted by wiping all key material used to derive or encrypt the data (as described in the application note). The introduction to this section provides two different schemes that meet the requirements, but other solutions may address this - requirement. - + requirement. There are no guidance evaluation activities for this element. The evaluator shall perform the tests in FCS_CKM_EXT.4 for all key material no longer needed while in the locked state and shall ensure that keys for the @@ -5498,13 +2684,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - The TSF shall encrypt any stored symmetric key and any stored private key of the - asymmetric keys used for the protection of sensitive data according to - [<htm:i>FCS_STG_EXT.2.1 selection 2</htm:i>]. - - The TSF shall encrypt any stored symmetric key and any stored private key of the - asymmetric keys used for the protection of sensitive data according to <assignable>mechanism for encrypted key storage</assignable>. - + The TSF shall encrypt any stored symmetric key and any stored private key of the asymmetric keys used for the protection of sensitive data according to [ <htm:i>FCS_STG_EXT.2.1 selection 2</htm:i> ]. Symmetric keys used to encrypt sensitive data while the TSF is in the unlocked state must be encrypted with (or chain to a KEK encrypted with) the REK and password-derived or biometric-unlocked KEK. A stored private key of the @@ -5521,69 +2701,51 @@ The evaluator shall generate 10 private/public key pairs using the key generatio of any private keys of the asymmetric pairs. The evaluator shall ensure that any private keys that are not wiped and are stored by the TSF are stored encrypted by a key encrypted with (or chain to a KEK encrypted with) the REK and password-derived - or biometric-unlocked KEK. - The evaluator shall also ensure that the documentation of the product's encryption key + or biometric-unlocked KEK. The evaluator shall also ensure that the documentation of the product's encryption key management is detailed enough that, after reading, the product's key management hierarchy is clear and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as - separate proprietary evidence rather than being included in the TSS. - + separate proprietary evidence rather than being included in the TSS. There are no guidance evaluation activities for this element. There are no test evaluation activities for this element. - The TSF shall decrypt the sensitive data that was received while in the locked - state upon transitioning to the unlocked state using the asymmetric key scheme and - shall re-encrypt that sensitive data using the symmetric key scheme. + The TSF shall decrypt the sensitive data that was received while in the locked state upon transitioning to the unlocked state using the asymmetric key scheme and shall re-encrypt that sensitive data using the symmetric key scheme. The evaluator shall verify that the TSS section of the ST that describes the asymmetric key scheme includes a description of the actions taken by the TSF for the purposes of DAR upon transitioning to the unlocked state. These actions shall minimally include decrypting all received data using the asymmetric key scheme and re-encrypting with the symmetric key scheme used to store data while the device is - unlocked. - + unlocked. There are no guidance evaluation activities for this element. There are no test evaluation activities for this element. - - Failure to encrypt/decrypt datanone - + + + + Failure to encrypt/decrypt data + none + + + - - - This family defines requirements for handling of information flows that are not addressed by FDP_IFC in CC Part 2. - - - - - + + requires the TSF to be able to support the use of an IPsec VPN to protect data in transit. The following actions could be considered for the management functions in FMT: - - Enabling/disabling VPN protection. - Enabling/disabling Always On VPN protection. - - + Enabling/disabling VPN protection.Enabling/disabling Always On VPN protection. There are no auditable events foreseen. FTP_ITC_EXT.1 Trusted Channel Communication - - The TSF shall <selectables linebreak="yes"> - <selectable>provide an interface which allows a VPN client to protect all IP traffic - using IPsec</selectable> - <selectable>provide a VPN client which can protect all IP traffic using - IPsec <htm:b>as defined in the <xref to="mod-vpnclient"/></htm:b></selectable> - </selectables> with the exception of IP traffic needed to manage the VPN - connection, and - <selectables> - <selectable><assignable>traffic needed for correct functioning of the TOE</assignable></selectable> - <selectable>no other traffic</selectable></selectables>, when the VPN is enabled. + The TSF shall<selectables><selectable id="fdp_ifc_ext.1.1_1" >provide an interface which allows a VPN client to protect all IP traffic + using IPsec</selectable><selectable id="fdp_ifc_ext.1.1_2" >provide a VPN client which can protect all IP traffic using + IPsec <htm:b>as defined in the <xref to="mod-vpnclient"></xref></htm:b></selectable></selectables>with the exception of IP traffic needed to manage the VPN connection, and<selectables><selectable id="fdp_ifc_ext.1.1_4" ><assignable>traffic needed for correct functioning of the TOE </assignable></selectable><selectable id="fdp_ifc_ext.1.1_5" >no other traffic</selectable></selectables>, when the VPN is enabled. Typically, the traffic needed to manage the VPN connection is referred to as "Control Plane" traffic; whereas, the IP traffic protected by the IPsec VPN is referred to as "Data Plane" traffic. All "Data Plane" traffic must flow @@ -5595,13 +2757,12 @@ The evaluator shall generate 10 private/public key pairs using the key generatio TOE’s network stack to perform the required Information Flow Control. The ST author must select the second option if the TSF implements - a native VPN client ( is selected in ). Thus the TSF must be - validated against the and the ST author must also include - FDP_IFC_EXT.1 from the . It is optional for - the VPN client to be configured to be always-on per FMT_SMF.1 Function . Always-on means the establishment of an IPsec trusted channel + a native VPN client ( is selected in ). Thus the TSF must be + validated against the and the ST author must also include + from the . It is optional for + the VPN client to be configured to be always-on per FMT_SMF.1 Function . Always-on means the establishment of an IPsec trusted channel to allow any communication by the TSF. - + The evaluator shall verify that the TSS section of the ST describes the routing of IP traffic through processes on the TSF when a VPN client is enabled. The evaluator shall ensure that the description indicates which traffic does not go @@ -5611,18 +2772,11 @@ The evaluator shall generate 10 private/public key pairs using the key generatio TSS section describes any differences in the routing of IP traffic when using any supported baseband protocols (e.g. Wi-Fi or, LTE). The evaluator shall verify that one (or more) of the following options is - addressed by the documentation: - - The description above indicates that if a VPN client is enabled, all + addressed by the documentation: The description above indicates that if a VPN client is enabled, all configurations route all Data Plane traffic through the tunnel interface - established by the VPN client. - The AGD guidance describes how the user or administrator can configure - the TSF to meet this requirement. - The API documentation includes a security function that allows a VPN - client to specify this routing. - - - + established by the VPN client.The AGD guidance describes how the user or administrator can configure + the TSF to meet this requirement.The API documentation includes a security function that allows a VPN + client to specify this routing. If the ST author identifies any differences in the routing between Wi-Fi and @@ -5663,32 +2817,22 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - + - - - This family defines requirements for managing data storage. - - - - - + + requires the TSF to be able to label, encrypt, store, and decrypt sensitive data and keys. There are no management activities foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - - Failure to encrypt/decrypt data. - - FCS_COP.1 Cryptographic Operation - FCS_CKM.2 Cryptographic Key Establishment + Failure to encrypt/decrypt data. + FCS_COP.1 Cryptographic Operation + FCS_CKM.2 Cryptographic Key Establishment FCS_STG_EXT.2 Encrypted Cryptographic Key Storage - - - The TSF shall provide protected storage for the Trust Anchor Database. - + The TSF shall provide protected storage for the Trust Anchor Database. + The evaluator shall ensure the TSS describes the Trust Anchor Database implemented that contain certificates used to meet the requirements of this PP. This description shall contain information pertaining to how certificates are loaded into @@ -5699,131 +2843,62 @@ The evaluator shall generate 10 private/public key pairs using the key generatio There are no test evaluation activities for this component. - - Addition or removal of certificate from Trust Anchor Database - Subject name of certificate. - + + Addition or removal of certificate from Trust Anchor Database + Subject name of certificate. + + + + + requires the TSF to be able to protect communication channels between products using a chosen secure method. + There are no management activities foreseen. + The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: + Application initiation of trusted channel. + FTP_ITC_EXT.1 Trusted Channel Communication + + The TSF shall provide a means for non-TSF applications executing on the TOE to use<assignable>data transfer protocol</assignable>to provide a protected communication channel between the non-TSF application and another IT product that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data. + + + The TSF shall permit the non-TSF applications to initiate communication via the trusted channel. + - - - - This family defines requirements for the use of trusted channel protocols to protect user data. - - - - - - - requires the TSF to be able to protect communication channels between products using a chosen secure method. - There are no management activities foreseen. - The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - - Application initiation of trusted channel. - - FTP_ITC_EXT.1 Trusted Channel Communication - - - - The TSF shall provide a means for non-TSF applications executing on the TOE to use - <assignable>data transfer protocol</assignable> - to provide a protected communication channel between the non-TSF application and another IT product - that is logically distinct from other communication channels, - provides assured identification of its end points, protects channel data from disclosure, - and detects modification of the channel data. - - - - The TSF shall permit the non-TSF applications to initiate communication via the - trusted channel. - - - - - - - - - + + - The TSF shall provide a means for non-TSF applications executing on the TOE to use [<htm:i><htm:ul> - <htm:li>Mutually authenticated TLS as defined in the <xref to="pkg-tls"/>,</htm:li> - <htm:li>HTTPS,</htm:li> - </htm:ul>and <selectables linebreak="yes"> - <selectable id="upc_dtls">mutually authenticated DTLS as defined in the <xref to="pkg-tls"/></selectable> - <selectable id="s-upc-ipsec">IPsec as defined in the <xref to="mod-vpnclient"/></selectable> - <selectable exclusive="yes">no other protocol</selectable> - </selectables> </htm:i>] to provide a protected communication channel between the non-TSF - application and another IT product that is logically distinct from other communication - channels, provides assured identification of its end points, protects channel data - from disclosure, and detects modification of the channel data. + The TSF shall provide a means for non-TSF applications executing on the TOE to use [ <htm:i><htm:ul><htm:li>Mutually authenticated TLS as defined in the <xref to="pkg-tls"></xref>,</htm:li><htm:li>HTTPS,</htm:li></htm:ul>and <selectables><selectable id="upc_dtls" >mutually authenticated DTLS as defined in the <xref to="pkg-tls"></xref></selectable><selectable id="s-upc-ipsec" >IPsec as defined in the <xref to="mod-vpnclient"></xref></selectable><selectable id="fdp_upc_ext.1.1_APPS_1" exclusive="yes" >no other protocol</selectable></selectables></htm:i> ] to provide a protected communication channel between the non-TSF application and another IT product that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data. The intent of this requirement is that one of the selected protocols is available for use by user applications running on the device for use in connecting to distant-end services that are not necessarily part of the enterprise infrastructure. It should be noted that the FTP_ITC_EXT.1 requires that all TSF communications be protected using the protocols indicated in that requirement, so the protocols required by this component ride "on top of" those listed in FTP_ITC_EXT.1. It should also be noted that some applications are part of the TSF, and FTP_ITC_EXT.1 requires that TSF applications be protected by at least one of the protocols in first selection in FTP_ITC_EXT.1. It is not required to have two different implementations of a protocol, or two different protocols, to satisfy both this requirement (for non-TSF apps) and FTP_ITC_EXT.1 (for TSF apps), as long as the services specified are provided. The ST author must list which trusted channel protocols are implemented by the Mobile Device for use by non-TSF apps. - The TSF must be validated against requirements from the , with the following selections made: - FCS_TLS_EXT.1: - - TLS is selected - Client is selected - - FCS_TLSC_EXT.1.1: - - The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1. - Mutual authentication must be selected - - FCS_TLSC_EXT.1.3 - - With no exceptions is selected. - - - - If is selected, the TSF must be validated against requirements from the , with the following selections made: - FCS_TLS_EXT.1: - - DTLS is selected - Client is selected - - FCS_DTLSC_EXT.1.1: - - The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1. - Mutual authentication must be selected - - FCS_DTLSC_EXT.1.3 - - With no exceptions is selected. - - - - If the ST author selects , the TSF must be validated against the PP-Module for Virtual Private Network (VPN) Clients. + The TSF must be validated against requirements from the , with the following selections made: FCS_TLS_EXT.1:TLS is selectedClient is selectedFCS_TLSC_EXT.1.1:The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.Mutual authentication must be selectedFCS_TLSC_EXT.1.3With no exceptions is selected. + If is selected, the TSF must be validated against requirements from the , with the following selections made: FCS_TLS_EXT.1:DTLS is selectedClient is selectedFCS_DTLSC_EXT.1.1:The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.Mutual authentication must be selectedFCS_DTLSC_EXT.1.3With no exceptions is selected. + If the ST author selects , the TSF must be validated against the PP-Module for Virtual Private Network (VPN) Clients. - The TSF shall permit the non-TSF applications to initiate communication via the - trusted channel. - The evaluator shall verify that the API documentation provided according to - includes the security functions (protection channel) + The TSF shall permit the non-TSF applications to initiate communication via the trusted channel. + + The evaluator shall verify that the API documentation provided according to + includes the security functions (protection channel) described in these requirements, and verify that the APIs implemented to support this requirement include the appropriate settings/parameters so that the application can both provide and obtain the information needed to assure mutual identification of the endpoints of the communication as required by this component. - The evaluator shall examine the TSS to determine that it describes that all + The evaluator shall examine the TSS to determine that it describes that all protocols listed in the TSS are specified and included in the requirements in the - ST. - + ST. The evaluator shall confirm that the operational guidance contains instructions necessary for configuring the protocols selected for use by the - applications. - + applications. - Evaluation Activity Note: The following test requires the developer to - provide access to a test platform that provides the evaluator with tools that are - typically not found on consumer Mobile Device products. The + + The evaluator shall write, or the developer shall provide access to, an application that requests protected channel services by the TSF. The evaluator shall verify that the results from the protected channel match the expected results according to the API documentation. This application may be used to assist in verifying the protected channel Evaluation Activities for the protocol requirements. The evaluator shall also - perform the following tests: + perform the following tests: The evaluators shall ensure that the application is able to initiate communications with an external IT entity using each protocol specified in the requirement, setting up the connections as described in the operational guidance @@ -5834,64 +2909,51 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - - Application initiation of trusted channel - Name of application. Trusted channel protocol. Non-TOE endpoint of connection - + + Application initiation of trusted channel + Name of application. Trusted channel protocol. Non-TOE endpoint of connection + - - + + - The TSF shall provide a means for non-TSF applications executing on the TOE to - use [<htm:i><htm:ul> - <htm:li>Bluetooth BR/EDR in accordance with the <xref to="mod-bluetooth"/>,</htm:li> - </htm:ul>and <selectables linebreak="yes"> - <selectable>Bluetooth LE in accordance with the <xref to="mod-bluetooth"/></selectable> - <selectable exclusive="yes">no other protocol</selectable> - </selectables> </htm:i>] to provide a protected communication channel between the non-TSF - application and another IT product that is logically distinct from other communication - channels, provides assured identification of its end points, protects channel data - from disclosure, and detects modification of the channel data. - If the TOE includes Bluetooth hardware, + The TSF shall provide a means for non-TSF applications executing on the TOE to use [ <htm:i><htm:ul><htm:li>Bluetooth BR/EDR in accordance with the <xref to="mod-bluetooth"></xref>,</htm:li></htm:ul>and <selectables><selectable id="fdp_upc_ext.1.1_BLUETOOTH_1" >Bluetooth LE in accordance with the <xref to="mod-bluetooth"></xref></selectable><selectable id="fdp_upc_ext.1.1_BLUETOOTH_2" exclusive="yes" >no other protocol</selectable></selectables></htm:i> ] to provide a protected communication channel between the non-TSF application and another IT product that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data. + If the TOE includes Bluetooth hardware, this requirement must be included in the ST. The intent of this requirement is that Bluetooth BR/EDR and optionally Bluetooth LE is available for use by user applications running on the device for use in connecting to distant-end services that are not necessarily part of the enterprise infrastructure. The ST author must list which trusted channel protocols are implemented by the Mobile Device for use by non-TSF apps. The TSF must be validated against requirements from the - . It should be noted that the FTP_ITC_EXT.1 requires that all + . It should be noted that the FTP_ITC_EXT.1 requires that all TSF communications be protected using the protocols indicated in that requirement, so the protocols required by this component ride "on top of" those listed in - FTP_ITC_EXT.1. - + FTP_ITC_EXT.1. - The TSF shall permit the non-TSF applications to initiate communication via the - trusted channel. - The evaluator shall verify that the API documentation provided according to - includes the security functions (protection channel) + The TSF shall permit the non-TSF applications to initiate communication via the trusted channel. + + The evaluator shall verify that the API documentation provided according to + includes the security functions (protection channel) described in these requirements, and verify that the APIs implemented to support this requirement include the appropriate settings/parameters so that the application can both provide and obtain the information needed to assure mutual identification of the endpoints of the communication as required by this component. - The evaluator shall examine the TSS to determine that it describes that all + The evaluator shall examine the TSS to determine that it describes that all protocols listed in the TSS are specified and included in the requirements in the - ST. - + ST. The evaluator shall confirm that the operational guidance contains instructions necessary for configuring the protocols selected for use by the - applications. - + applications. - Evaluation Activity Note: The following test requires the developer to - provide access to a test platform that provides the evaluator with tools that are - typically not found on consumer Mobile Device products. The + + The evaluator shall write, or the developer shall provide access to, an application that requests protected channel services by the TSF. The evaluator shall verify that the results from the protected channel match the expected results according to the API documentation. This application may be used to assist in verifying the protected channel Evaluation Activities for the protocol requirements. The evaluator shall also - perform the following tests: + perform the following tests: The evaluators shall ensure that the application is able to initiate communications with an external IT entity using each protocol specified in the requirement, setting up the connections as described in the operational guidance @@ -5902,64 +2964,33 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - - Application initiation of trusted channel - Name of application. Trusted channel protocol. Non-TOE endpoint of connection - + + Application initiation of trusted channel + Name of application. Trusted channel protocol. Non-TOE endpoint of connection + - - - - - - This family defines requirements for authentication failure handling that are not addressed by the FIA_AFL family in CC Part 2. - - - - - - +
    + +
    + + requires the TSF be able to manage unsuccessful authentication attempts and limit the number of attempts for each method. The following actions could be considered for the management functions in FMT: - - Configuration of authentication failure limit. - - + Configuration of authentication failure limit. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - - Exceeding configured authentication failure limit. - - - FCS_CKM_EXT.5 TSF Wipe + Exceeding configured authentication failure limit. + FCS_CKM_EXT.5 TSF Wipe FIA_UAU.1 Timing of Authentication - - - The TSF shall consider password and <selectables> - <!-- ToDo: Remove per bio cPP module: - <selectable>fingerprint</selectable> - <selectable> iris</selectable> - <selectable> face</selectable> - <selectable> voice</selectable> - <selectable> vein</selectable> --> - <selectable> biometric in accordance with the <xref to="mod-biometrics"/></selectable> - <selectable> hybrid</selectable> - <selectable exclusive="yes" id="s-authfail-noother"> no other mechanism</selectable> - </selectables> as critical authentication mechanisms. - - The TSF shall consider password and - <assignable>list of acceptable authentication mechanisms</assignable> - as critical authentication mechanisms. - - + The TSF shall consider password and<selectables><selectable id="fia_afl_ext.1.1_1" > biometric in accordance with the <xref to="mod-biometrics"></xref></selectable><selectable id="fia_afl_ext.1.1_2" > hybrid</selectable><selectable id="s-authfail-noother" exclusive="yes" > no other mechanism</selectable></selectables>as critical authentication mechanisms. A critical authentication mechanism is one in which countermeasures are triggered (i.e. wipe of the device) when the maximum number of unsuccessful authentication attempts is exceeded, rendering the other factors unavailable. If no additional authentication mechanisms are - selected in FIA_UAU.5.1, then must be selected. + selected in FIA_UAU.5.1, then must be selected. If an additional authentication mechanism is selected in FIA_UAU.5.1, then it must only be selected in FIA_AFL_EXT.1.1 if surpassing the authentication failure threshold for biometric data @@ -5972,28 +3003,14 @@ The evaluator shall generate 10 private/public key pairs using the key generatio lock screen interface. - The TSF shall detect when a configurable positive integer within - <assignable>range of acceptable values for each authentication - mechanism</assignable> of <selectables> - <selectable id="s-authfail-num-unique">unique</selectable> - <selectable id="s-authfail-num-non-unique">non-unique</selectable> - </selectables> unsuccessful authentication attempts occur related to last successful - authentication for each authentication mechanism. - - The TSF shall detect when a configurable positive integer within - <assignable>range of acceptable values for each authentication - mechanism</assignable> of - <selectables><selectable>unique</selectable><selectable>non-unique</selectable> - </selectables> unsuccessful authentication attempts occur related to last successful - authentication for each authentication mechanism. - + The TSF shall detect when a configurable positive integer within<assignable>range of acceptable values for each authentication mechanism</assignable>of<selectables><selectable id="s-authfail-num-unique" >unique</selectable><selectable id="s-authfail-num-non-unique" >non-unique</selectable></selectables>unsuccessful authentication attempts occur related to last successful authentication for each authentication mechanism. The positive integers is configured according to - FMT_SMF.1.1 function . An unique + FMT_SMF.1.1 function . An unique authentication attempt is defined as any attempt to verify a password or biometric - sample, in which the input is different from a previous attempt. "" must be + sample, in which the input is different from a previous attempt. " " must be selected if the authentication system increments the counter only for unique unsuccessful authentication attempts. For example, if the same incorrect password is - attempted twice the authentication system increments the counter once. "" must be selected if the authentication system + attempted twice the authentication system increments the counter once. " " must be selected if the authentication system increments the counter for each unsuccessful authentication attempt, regardless of if the input is unique. For example, if the same incorrect password is attempted twice the authentication system @@ -6019,8 +3036,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio unsuccessful authentication attempts. - The TSF shall maintain the number of unsuccessful authentication attempts that - have occurred upon power off. + The TSF shall maintain the number of unsuccessful authentication attempts that have occurred upon power off. The TOE may implement an Authentication Factor interface that precedes another Authentication Factor interface in the boot sequence (for example, a volume DAR decryption interface which precedes the lock screen interface) before the @@ -6029,17 +3045,12 @@ The evaluator shall generate 10 private/public key pairs using the key generatio authentication attempts need not be maintained for the second interface. - When the defined number of unsuccessful authentication attempts has exceeded the - maximum allowed for a given authentication mechanism, all future authentication - attempts will be limited to other available authentication mechanisms, unless the - given mechanism is designated as a critical authentication mechanism. + When the defined number of unsuccessful authentication attempts has exceeded the maximum allowed for a given authentication mechanism, all future authentication attempts will be limited to other available authentication mechanisms, unless the given mechanism is designated as a critical authentication mechanism. In accordance with FIA_AFL_EXT.1.3, this requirement also applies after the TOE is powered off and powered back on. - When the defined number of unsuccessful authentication attempts for the last - available authentication mechanism or single critical authentication mechanism has - been surpassed, the TSF shall perform a wipe of all protected data. + When the defined number of unsuccessful authentication attempts for the last available authentication mechanism or single critical authentication mechanism has been surpassed, the TSF shall perform a wipe of all protected data. Wipe is performed in accordance with FCS_CKM_EXT.5. Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well. If the TOE @@ -6048,12 +3059,11 @@ The evaluator shall generate 10 private/public key pairs using the key generatio applies to all available interfaces. - The TSF shall increment the number of unsuccessful authentication attempts prior - to notifying the user that the authentication was unsuccessful. + The TSF shall increment the number of unsuccessful authentication attempts prior to notifying the user that the authentication was unsuccessful. This requirement is to ensure that if power is cut to the device directly after an authentication attempt, the counter will be incremented to reflect that attempt. - + The evaluator shall ensure that the TSS describes that a value corresponding to the number of unsuccessful authentication attempts since the last successful authentication is kept for each Authentication Factor interface. The evaluator shall @@ -6075,8 +3085,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio The evaluator shall verify that the AGD guidance describes how the administrator configures the maximum number of unique unsuccessful authentication - attempts. - + attempts. The evaluator shall configure the device with all authentication mechanisms @@ -6096,7 +3105,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio multiple authentication mechanisms utilize a shared counter, then the evaluator shall verify that the maximum number of unsuccessful authentication attempts can be reached by using each individual authentication mechanism and a combination - of all authentication mechanisms that share the counter. + of all authentication mechanisms that share the counter. The evaluator shall repeat test one, but shall power off (by removing the battery, if possible) the TOE between unsuccessful authentication attempts. The evaluator shall verify that the total number of unsuccessful authentication @@ -6105,357 +3114,25 @@ The evaluator shall generate 10 private/public key pairs using the key generatio Alternatively, if the number of authentication failures is not maintained for the interface under test, the evaluator shall verify that upon booting the TOE between unsuccessful authentication attempts another authentication factor - interface is presented before the interface under test. + interface is presented before the interface under test. - - Excess of authentication failure limit - Authentication factor used - - - - - - This family defines requirements for the composition of password credentials. - - - - - + + requires the TSF to enforce character length and composition requirements for password credentials. The following actions could be considered for the management functions in FMT: - - Configuring password policy. - - + Configuring password policy. There are no auditable events foreseen. FIA_UAU.1 Timing of Authentication - - - The TSF shall support the following for the Password Authentication Factor: <htm:ol> - <htm:li>Passwords shall be able to be composed of any combination of <selectables> - <selectable>upper and lower case letters</selectable> - <selectable><assignable>a character set of at least 52 - characters</assignable></selectable> - </selectables>, numbers, and special characters: <selectables> - <selectable>"!"</selectable> - <selectable>"@"</selectable> - <selectable>"#"</selectable> - <selectable>"$"</selectable> - <selectable>"%"</selectable> - <selectable>"^"</selectable> - <selectable>"&"</selectable> - <selectable> "*"</selectable> - <selectable>"("</selectable> - <selectable>")"</selectable> - <selectable><assignable>other characters</assignable></selectable> - </selectables>; </htm:li> - <htm:li>Password length up to <assignable>an integer greater than or equal to - 14</assignable> characters shall be supported. </htm:li> - </htm:ol> - + The TSF shall support the following for the Password Authentication Factor: <htm:ol><htm:li>Passwords shall be able to be composed of any combination of <selectables><selectable id="fia_pmg_ext.1.1_1" >upper and lower case letters</selectable><selectable id="fia_pmg_ext.1.1_3" ><assignable>a character set of at least 52 characters </assignable></selectable></selectables>, numbers, and special characters: <selectables><selectable id="fia_pmg_ext.1.1_4" >"!"</selectable><selectable id="fia_pmg_ext.1.1_5" >"@"</selectable><selectable id="fia_pmg_ext.1.1_6" >"#"</selectable><selectable id="fia_pmg_ext.1.1_7" >"$"</selectable><selectable id="fia_pmg_ext.1.1_8" >"%"</selectable><selectable id="fia_pmg_ext.1.1_9" >"^"</selectable><selectable id="fia_pmg_ext.1.1_10" >"&"</selectable><selectable id="fia_pmg_ext.1.1_11" > "*"</selectable><selectable id="fia_pmg_ext.1.1_12" >"("</selectable><selectable id="fia_pmg_ext.1.1_13" >")"</selectable><selectable id="fia_pmg_ext.1.1_15" ><assignable>other characters </assignable></selectable></selectables>; </htm:li><htm:li>Password length up to <assignable>an integer greater than or equal to 14</assignable> characters shall be supported. </htm:li></htm:ol> While some corporate policies require passwords of 14 characters or better, the use of a REK for DAR protection and key storage protection and the anti-hammer requirement (FIA_TRT_EXT.1) addresses the threat of attackers with @@ -6466,7 +3143,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio encoding standard (such as Unicode) or defined in the assignment by the ST author. The ST author also selects the special characters that are supported by the TOE; they may optionally list additional special characters supported using the assignment. - + There are no TSS evaluation activities for this component. The evaluator shall examine the operational guidance to determine that it provides guidance to security administrators on the composition of strong passwords, @@ -6486,36 +3163,23 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - + - - - This family defines requirements for prevention of brute-force authentication attempts. - - - - - - + + requires the TSF to limit authentication attempts by number of attempts in a set amount of time. There are no management activities foreseen. There are no auditable events foreseen. FIA_UAU.5 Multiple Authentication Mechanisms - - The TSF shall limit automated user authentication attempts by <selectables> - <selectable>preventing authentication via an external port</selectable> - <selectable>enforcing a delay between incorrect authentication attempts</selectable> - </selectables> for all authentication mechanisms selected in FIA_UAU.5.1. The minimum - delay shall be such that no more than 10 attempts can be attempted per 500 - milliseconds. + The TSF shall limit automated user authentication attempts by<selectables><selectable id="fia_trt_ext.1.1_1" >preventing authentication via an external port</selectable><selectable id="fia_trt_ext.1.1_2" >enforcing a delay between incorrect authentication attempts</selectable></selectables>for all authentication mechanisms selected in FIA_UAU.5.1. The minimum delay shall be such that no more than 10 attempts can be attempted per 500 milliseconds. The authentication throttling applies to all authentication mechanisms selected in FIA_UAU.5.1. The user authentication attempts in this requirement are attempts to guess the Authentication Factor. The developer can implement the timing of the delays in the requirements using unequal or equal timing of delays. The minimum delay specified in this requirement provides defense against brute forcing. - + The evaluator shall verify that the TSS describes the method by which authentication attempts are not able to be automated. The evaluator shall ensure that the TSS describes either how the TSF disables authentication via external @@ -6527,47 +3191,31 @@ The evaluator shall generate 10 private/public key pairs using the key generatio There are no test evaluation activities for this component. - + - + + - The TSF shall provide <refinement>password and <selectables> - <!-- ToDo: Remove per bio cPP module: <selectable id="uau_fing">fingerprint</selectable> - <selectable id="uau_iris"> iris</selectable> - <selectable id="uau_face"> face</selectable> - <selectable id="uau_vox"> voice</selectable> - <selectable id="uau_vein"> vein</selectable> --> - <selectable id="uau_biometric"> biometric in accordance with the <xref to="mod-biometrics"/></selectable> - <selectable id="uau_hybr"> hybrid</selectable> - <selectable exclusive="yes">no other mechanism</selectable> - </selectables> - </refinement>to support user authentication. + The TSF shall provide <htm:b>password and <selectables><selectable id="uau_biometric" > biometric in accordance with the <xref to="mod-biometrics"></xref></selectable><selectable id="uau_hybr" > hybrid</selectable><selectable id="fia_uau.5.1_1" exclusive="yes" >no other mechanism</selectable></selectables></htm:b> to support user authentication. The TSF must support a Password Authentication Factor and may - optionally implement a BAF. A hybrid authentication factor is where a user has to submit a + optionally implement a BAF. A hybrid authentication factor is where a user has to submit a combination of PIN/password and biometric sample where both have to pass and if either fails the user is not made aware of which factor failed. - If or is selected, - then the TSF must be validated against requirements from the . + If or is selected, + then the TSF must be validated against requirements from the . - If is selected, does not need to be selected, but should be + If is selected, does not need to be selected, but should be selected if the biometric authentication can be used independent of the hybrid - authentication, i.e. without having to enter a PIN/password. - + authentication, i.e. without having to enter a PIN/password. The Password Authentication Factor is configured according to FIA_PMG_EXT.1. - The TSF shall authenticate any user's claimed identity according to the - <assignable>rules describing how each authentication mechanism selected in FIA_UAU.5.1 provides - authentication</assignable>. + The TSF shall authenticate any user's claimed identity according to the<assignable>rules describing how each authentication mechanism selected in FIA_UAU.5.1 provides authentication</assignable>. Rules regarding how the authentication factors interact in terms of unsuccessful authentication are covered in FIA_AFL_EXT.1. - + The evaluator shall ensure that the TSS describes each mechanism provided to support user authentication and the rules describing how the authentication mechanisms provide authentication. @@ -6578,7 +3226,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio successful authentication (i.e. is the user input used to derive or unlock a key) and which authentication mechanism can be used at which authentication factor interfaces (i.e. if there are times, for example, after a reboot, that only specific - authentication mechanisms can be used). If multiple BAFs are claimed in FIA_MBV_EXT.1.1 in the , the interaction between the BAFs must be described. For example, whether the + authentication mechanisms can be used). If multiple BAFs are claimed in FIA_MBV_EXT.1.1 in the , the interaction between the BAFs must be described. For example, whether the multiple BAFs can be enabled at the same time. The evaluator shall verify that configuration guidance for each authentication mechanism is addressed in the AGD guidance. @@ -6593,17 +3241,18 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - + - + + - The TSF shall re-authenticate the user <refinement>via the Password - Authentication Factor</refinement> under the conditions [<htm:i>attempted change - to any supported authentication mechanisms</htm:i>]. + The TSF shall re-authenticate the user <htm:b>via the Password + Authentication Factor</htm:b> under the conditions [ <htm:i>attempted change + to any supported authentication mechanisms</htm:i> ]. The password authentication factor must be entered before either the password or biometric authentication factor, if selected in FIA_UAU.5.1, can be changed. - + There are no TSS evaluation activities for this element. There are no guidance evaluation activities for this element. @@ -6613,12 +3262,12 @@ The evaluator shall generate 10 private/public key pairs using the key generatio Authentication Factor according to the AGD guidance and verify that the TSF requires the entry of the Password Authentication Factor before allowing the factor to be changed. - [conditional] If is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the the evaluator shall + [conditional] If is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the the evaluator shall configure the TSF to use the BAF, which includes configuring the Password Authentication Factor, according to the AGD guidance. The evaluator shall change the BAF according to the AGD guidance and verify that the TSF requires the entry of the Password Authentication Factor before allowing the BAF to be changed. - [conditional] If is selected in FIA_UAU.5.1, the evaluator shall + [conditional] If is selected in FIA_UAU.5.1, the evaluator shall configure the TSF to use the BAF and PIN or password, which includes configuring the Password Authentication Factor, according to the AGD guidance. The evaluator shall change the BAF and PIN according to the AGD guidance and verify that the @@ -6629,11 +3278,12 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - + + - The TSF shall re-authenticate the user <refinement>via an authentication factor - defined in FIA_UAU.5.1</refinement> under the conditions <refinement>TSF-initiated - lock, user-initiated lock, <assignable>other conditions</assignable></refinement>. + The TSF shall re-authenticate the user <htm:b>via an authentication factor + defined in FIA_UAU.5.1</htm:b> under the conditions <htm:b>TSF-initiated + lock, user-initiated lock, <assignable>other conditions</assignable></htm:b> . Depending on the selections made in FIA_UAU.5.1, either the password (at a minimum), biometric authentication or hybrid authentication mechanisms can be used to unlock the device. TSF-initiated and user-initiated locking is described in @@ -6648,40 +3298,41 @@ The evaluator shall generate 10 private/public key pairs using the key generatio evaluator shall wait until the TSF locks and then verify that the TSF requires the entry of the Password Authentication Factor before transitioning to the unlocked state. - [conditional] If is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the the evaluator shall + [conditional] If is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the the evaluator shall repeat Test 1 verifying that the TSF requires the entry of the BAF before transitioning to the unlocked state. - [conditional] If is selected in FIA_UAU.5.1, the evaluator shall + [conditional] If is selected in FIA_UAU.5.1, the evaluator shall repeat Test 1 verifying that the TSF requires the entry of the BAF and PIN/password before transitioning to the unlocked state. - The evaluator shall configure user-initiated locking according to the AGD + The evaluator shall configure user-initiated locking according to the AGD guidance. The evaluator shall lock the TSF and then verify that the TSF requires the entry of the Password Authentication Factor before transitioning to the unlocked state. - [conditional] If is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the the evaluator shall - repeat verifying that the TSF requires the entry of the BAF before + [conditional] If is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the the evaluator shall + repeat verifying that the TSF requires the entry of the BAF before transitioning to the unlocked state. - [conditional] If is selected in FIA_UAU.5.1, the evaluator shall - repeat verifying that the TSF requires the entry of the BAF and + [conditional] If is selected in FIA_UAU.5.1, the evaluator shall + repeat verifying that the TSF requires the entry of the BAF and PIN/password before transitioning to the unlocked state. - - User changes Password Authentication Factor - + + User changes Password Authentication Factor + - + + - The TSF shall provide only [<htm:i>obscured feedback to the device’s - display</htm:i>] to the user while the authentication is in progress. + The TSF shall provide only [ <htm:i>obscured feedback to the device’s + display</htm:i> ] to the user while the authentication is in progress. This applies to all authentication methods specified in FIA_UAU.5.1. The TSF may briefly (1 second or less) display each character or provide an option to allow the user to unmask the password; however, the password must be obscured by default. - If is selected in FIA_UAU.5.1, the TSF + If is selected in FIA_UAU.5.1, the TSF must not display sensitive information regarding any BAF that could aid an adversary in identifying or spoofing the respective biometric characteristics of a given human user. While it is true that biometric samples, by themselves, are not @@ -6689,9 +3340,9 @@ The evaluator shall generate 10 private/public key pairs using the key generatio output data from these biometric algorithms, is considered sensitive and must be kept secret. Where applicable, the TSF must not reveal or make public the reasons for authentication failure. - + The evaluator shall ensure that the TSS describes the means of obscuring the - authentication entry, for all authentication methods specified in FIA_UAU.5.1. + authentication entry, for all authentication methods specified in FIA_UAU.5.1. The evaluator shall verify that any configuration of this requirement is addressed in the AGD guidance and that the password is obscured by default. @@ -6699,8 +3350,8 @@ The evaluator shall generate 10 private/public key pairs using the key generatio The evaluator shall enter passwords on the device, including at least the Password Authentication Factor at lock screen, and verify that the password is not displayed on the device. - [conditional] If is selected in FIA_UAU.5.1, - for each BAF claimed in FIA_MBV_EXT.1.1 in the the evaluator shall + [conditional] If is selected in FIA_UAU.5.1, + for each BAF claimed in FIA_MBV_EXT.1.1 in the the evaluator shall authenticate by producing a biometric sample at lock screen. As the biometric algorithms are performed, the evaluator shall verify that sensitive images, audio, or other information identifying the user are kept secret and are not @@ -6716,38 +3367,24 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - + - - - This family defines requirements for user authentication that are not addressed by FIA_UAU in CC Part 2. - - - - - - + + requires the TSF enforce data-at-rest protection until successful authentication has occurred. There are no management activities foreseen. There are no auditable events foreseen. - FDP_DAR_EXT.1 Protected Data Encryption + FDP_DAR_EXT.1 Protected Data Encryption FDP_DAR_EXT.2 Sensitive Data Encryption - - - The TSF shall require the user to present the Password Authentication Factor - prior to decryption of protected data and encrypted DEKs, KEKs and <selectables> - <selectable>long-term trusted channel key material</selectable> - <selectable>all software-based key storage</selectable> - <selectable exclusive="yes">no other keys</selectable> - </selectables> at startup. + The TSF shall require the user to present the Password Authentication Factor prior to decryption of protected data and encrypted DEKs, KEKs and<selectables><selectable id="fia_uau_ext.1.1_1" >long-term trusted channel key material</selectable><selectable id="fia_uau_ext.1.1_2" >all software-based key storage</selectable><selectable id="fia_uau_ext.1.1_3" exclusive="yes" >no other keys</selectable></selectables>at startup. The intent of this requirement is to prevent decryption of protected data before the user has authorized to the device using the Password Authentication Factor. The Password Authentication Factor is also required in order derive the key used to decrypt sensitive data, which includes software-based secure key storage. - + The evaluator shall verify that the TSS section of the ST describes the process for decrypting protected data and keys. The evaluator shall ensure that this process requires the user to enter a Password Authentication Factor and, in accordance with @@ -6755,11 +3392,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio storage and (optionally) DEKs for sensitive data, in accordance with FCS_STG_EXT.2. There are no guidance evaluation activities for this component. - The following tests may be performed in conjunction with FDP_DAR_EXT.1 and - FDP_DAR_EXT.2. - Evaluation Activity Note: The following test require the developer to - provide access to a test platform that provides the evaluator with tools that are - typically not found on consumer Mobile Device products. + The evaluator shall enable encryption of protected data and require user authentication according to the AGD guidance. The evaluator shall write, or the @@ -6769,7 +3402,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio the application data, and verify that the unique string cannot be found. The evaluator shall enter the Password Authentication Factor to access full device functionality, use a tool provided by the developer to access the unique string - within the application data, and verify that the unique string can be found. + within the application data, and verify that the unique string can be found. [conditional] The evaluator shall require user authentication according to the AGD guidance. The evaluator shall store a key in the software-based secure key storage. The evaluator shall lock the device, use a tool @@ -6777,7 +3410,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio the key cannot be retrieved or accessed. The evaluator shall enter the Password Authentication Factor to access full device functionality, use a tool provided by developer to access the key, and verify that the key can be retrieved or - accessed. + accessed. [conditional] The evaluator shall enable encryption of sensitive data and require user authentication according to the AGD guidance. The evaluator shall write, or the developer shall provide access to, an application that includes a @@ -6792,43 +3425,29 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - + - - + + requires the TSF to prevent a subject’s use of TOE until the user is authenticated. The following actions could be considered for the management functions in FMT: - - Enabling/disabling display TSF notifications while in the locked state. - Enabling/disabling bypass of local user authentication. - - + Enabling/disabling display TSF notifications while in the locked state.Enabling/disabling bypass of local user authentication. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - - Action performed before authentication. - - + Action performed before authentication. No dependencies. - - The TSF shall allow <selectables> - <selectable> - <assignable>list of actions</assignable></selectable> - <selectable> no actions</selectable> - </selectables> on behalf of the user to be performed before the user is authenticated. - + The TSF shall allow<selectables><selectable id="fia_uau_ext.2.1_2" ><assignable>list of actions </assignable></selectable><selectable id="fia_uau_ext.2.1_3" > no actions</selectable></selectables>on behalf of the user to be performed before the user is authenticated. - The TSF shall require each user to be successfully authenticated before allowing - any other TSF-mediated actions on behalf of that user. + The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. The security relevant actions allowed by unauthorized users in locked state must be listed. At a minimum the actions that correspond to the functions available to the user in FMT_SMF.1 and are allowed by unauthorized users in locked state should be listed. For example, if the user can enable/disable the camera per - function of FMT_SMF.1 and unauthorized users can + function of FMT_SMF.1 and unauthorized users can take a picture when the device is in locked state, this action must be listed. - + The evaluator shall verify that the TSS describes the actions allowed by unauthorized users in the locked state. There are no guidance evaluation activities for this component. @@ -6837,24 +3456,20 @@ The evaluator shall generate 10 private/public key pairs using the key generatio succeed. - - Action performed before authentication. - + + Action performed before authentication. + + requires the TSF to enforce the use of a secondary authentication factor to access certain user data. There are no management activities foreseen. There are no auditable events foreseen. - FDP_ACF_EXT.2 Access Control for System Resources + FDP_ACF_EXT.2 Access Control for System Resources FIA_UAU.5 Multiple Authentication Mechanisms - - The TSF shall provide a secondary authentication mechanism for accessing - Enterprise applications and resources. The secondary authentication mechanism shall - control access to the Enterprise application and shared resources and shall be - incorporated into the encryption of protected and sensitive data belonging to - Enterprise applications and shared resources. + The TSF shall provide a secondary authentication mechanism for accessing Enterprise applications and resources. The secondary authentication mechanism shall control access to the Enterprise application and shared resources and shall be incorporated into the encryption of protected and sensitive data belonging to Enterprise applications and shared resources. For the BYOD use case, Enterprise applications and data must be protected using a different password than the user authentication to gain access to the personal applications and data, if configured. @@ -6878,18 +3493,14 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - The TSF shall require the user to present the secondary authentication factor - prior to decryption of Enterprise application data and Enterprise shared resource - data. - - - + The TSF shall require the user to present the secondary authentication factor prior to decryption of Enterprise application data and Enterprise shared resource data. + The intent of this requirement is to prevent decryption of protected Enterprise application data and Enterprise shared resource data before the user has authenticated to the device using the secondary authentication factor. Enterprise shared resource data consists of the FDP_ACF_EXT.2.1 selections. - The evaluator shall verify that the TSS section of the ST describes the process + The evaluator shall verify that the TSS section of the ST describes the process for decrypting Enterprise application data and shared resource data. The evaluator shall ensure that this process requires the user to enter an Authentication Factor and, in accordance with FCS_CKM_EXT.3, derives a KEK which is used to protect the @@ -6899,178 +3510,89 @@ The evaluator shall generate 10 private/public key pairs using the key generatio There are no test evaluation activities for this element. - + - - - This family defines requirements for the management and use of X.509 certificates. - - - - - + + specifies the rules the TSF must follow to determine if a particular X.509 certificate is valid. There are no management activities foreseen. The following action is be auditable: - - Failure to validate X.509v3 certificate. - - + Failure to validate X.509v3 certificate. FCS_COP.1 Cryptographic Operation - - - The TSF shall validate certificates in accordance with the following rules: <htm:ul> - <htm:li>RFC 5280 certificate validation and certificate path validation.</htm:li> - <htm:li>The certificate path must terminate with a certificate in the Trust Anchor Database.</htm:li> - <htm:li>The TSF shall validate a certificate path by ensuring the presence of the basicConstraints extension, that the CA flag is set to TRUE for all CA certificates, and that any path constraints are met.</htm:li> - <htm:li>The TSF shall validate that any CA certificate includes caSigning purpose in the key usage field.</htm:li> - <htm:li>The TSF shall validate the revocation status of the certificate using <selectables> - <selectable>OCSP as specified in RFC 6960</selectable> - <selectable id="s-crl">CRL as specified in RFC 5759</selectable> - <selectable>an OCSP TLS Status Request Extension (OCSP stapling) as specified in RFC 6066</selectable> - <selectable>OCSP TLS Multi-Certificate Status Request Extension (i.e., OCSP Multi-Stapling) as specified in RFC 6961</selectable> - </selectables>.</htm:li> - <htm:li>The TSF shall validate the extendedKeyUsage field according to the following rules:<htm:ul> - <htm:li>Certificates used for trusted updates and executable code integrity verification shall have the Code Signing Purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field.</htm:li> - <htm:li>Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.</htm:li> - <htm:li>Server certificates presented for EST shall have the CMC Registration Authority (RA) purpose (id-kp-cmcRA with OID 1.3.6.1.5.5.7.3.28) in the extendedKeyUsage field. [conditional]</htm:li> - <htm:li>Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.</htm:li> - <htm:li>OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field. [conditional]</htm:li></htm:ul></htm:li> - </htm:ul> - - The TSF shall validate certificates in accordance with the following rules: <assignable>list of rules</assignable>. - - FIA_X509_EXT.1.1 lists the rules for validating certificates. The ST author must select whether revocation status is verified using OCSP or CRLs. OCSP stapling and OCSP multi-stapling only support TLS server certificate validation. If other certificate types are validated, either OCSP or CRL should be claimed. The , to which a MDF TOE must also conform, requires that certificates are used for EAP-TLS; this use requires that the extendedKeyUsage rules are verified. Certificates may optionally be used for trusted updates of system software and applications (FPT_TUD_EXT.2) and for integrity verification (FPT_TST_EXT.2(1)) and, if implemented, must be validated to contain the Code Signing purpose extendedKeyUsage. - While FIA_X509_EXT.1.1 requires that the TOE perform certain checks on the certificate presented by a TLS server, there are corresponding checks that the authentication server will have to perform on the certificate presented by the client; namely that the extendedKeyUsage field of the client certificate includes “Client Authentication” and that the key agreement bit (for the Diffie-Hellman ciphersuites) or the key encipherment bit (for RSA ciphersuites) be set. Certificates obtained for use by the TOE will have to conform to these requirements in order to be used in the enterprise. This check is required to support EAP-TLS for the . + The TSF shall validate certificates in accordance with the following rules: <htm:ul><htm:li>RFC 5280 certificate validation and certificate path validation.</htm:li><htm:li>The certificate path must terminate with a certificate in the Trust Anchor Database.</htm:li><htm:li>The TSF shall validate a certificate path by ensuring the presence of the basicConstraints extension, that the CA flag is set to TRUE for all CA certificates, and that any path constraints are met.</htm:li><htm:li>The TSF shall validate that any CA certificate includes caSigning purpose in the key usage field.</htm:li><htm:li>The TSF shall validate the revocation status of the certificate using <selectables><selectable id="fia_x509_ext.1.1_1" >OCSP as specified in RFC 6960</selectable><selectable id="s-crl" >CRL as specified in RFC 5759</selectable><selectable id="fia_x509_ext.1.1_2" >an OCSP TLS Status Request Extension (OCSP stapling) as specified in RFC 6066</selectable><selectable id="fia_x509_ext.1.1_3" >OCSP TLS Multi-Certificate Status Request Extension (i.e., OCSP Multi-Stapling) as specified in RFC 6961</selectable></selectables>.</htm:li><htm:li>The TSF shall validate the extendedKeyUsage field according to the following rules:<htm:ul><htm:li>Certificates used for trusted updates and executable code integrity verification shall have the Code Signing Purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field.</htm:li><htm:li>Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.</htm:li><htm:li>Server certificates presented for EST shall have the CMC Registration Authority (RA) purpose (id-kp-cmcRA with OID 1.3.6.1.5.5.7.3.28) in the extendedKeyUsage field. [conditional]</htm:li><htm:li>Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.</htm:li><htm:li>OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field. [conditional]</htm:li></htm:ul></htm:li></htm:ul> + FIA_X509_EXT.1.1 lists the rules for validating certificates. The ST author must select whether revocation status is verified using OCSP or CRLs. OCSP stapling and OCSP multi-stapling only support TLS server certificate validation. If other certificate types are validated, either OCSP or CRL should be claimed. The , to which a MDF TOE must also conform, requires that certificates are used for EAP-TLS; this use requires that the extendedKeyUsage rules are verified. Certificates may optionally be used for trusted updates of system software and applications (FPT_TUD_EXT.2) and for integrity verification (FPT_TST_EXT.2(1)) and, if implemented, must be validated to contain the Code Signing purpose extendedKeyUsage. + While FIA_X509_EXT.1.1 requires that the TOE perform certain checks on the certificate presented by a TLS server, there are corresponding checks that the authentication server will have to perform on the certificate presented by the client; namely that the extendedKeyUsage field of the client certificate includes “Client Authentication” and that the key agreement bit (for the Diffie-Hellman ciphersuites) or the key encipherment bit (for RSA ciphersuites) be set. Certificates obtained for use by the TOE will have to conform to these requirements in order to be used in the enterprise. This check is required to support EAP-TLS for the . - The TSF shall only treat a certificate as a CA certificate if the - basicConstraints extension is present and the CA flag is set to TRUE. + The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension is present and the CA flag is set to TRUE. This requirement applies to certificates that are used and processed by the TSF and restricts the certificates that may be added to the Trust Anchor Database. - + The evaluator shall ensure the TSS describes where the check of validity of the certificates takes place. The evaluator ensures the TSS also provides a description of the certificate path validation algorithm. There are no guidance evaluation activities for this component. - The tests described must be performed in conjunction with the other Certificate Services evaluation activities, including the use cases in FIA_X509_EXT.2.1 and FIA_X509_EXT.3. The tests for the extendedKeyUsage rules are performed in conjunction with the uses that require those rules. The evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the self-signed Root CA. - - The evaluator shall demonstrate that validating a certificate without a valid certification path results in the function failing, for each of the following reasons, in turn: - By establishing a certificate path in which one of the issuing certificates is not a CA certificate, - By omitting the basicConstraints field in one of the issuing certificates, - By setting the basicConstraints field in an issuing certificate to have CA=False, - By omitting the CA signing bit of the key usage field in an issuing certificate, and - By setting the path length field of a valid CA field to a value strictly less than the certificate path. - + + + The tests described must be performed in conjunction with the other Certificate Services evaluation activities, including the use cases in FIA_X509_EXT.2.1 and FIA_X509_EXT.3. The tests for the extendedKeyUsage rules are performed in conjunction with the uses that require those rules. The evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the self-signed Root CA. + + The evaluator shall demonstrate that validating a certificate without a valid certification path results in the function failing, for each of the following reasons, in turn:By establishing a certificate path in which one of the issuing certificates is not a CA certificate,By omitting the basicConstraints field in one of the issuing certificates,By setting the basicConstraints field in an issuing certificate to have CA=False,By omitting the CA signing bit of the key usage field in an issuing certificate, andBy setting the path length field of a valid CA field to a value strictly less than the certificate path. The evaluator shall then establish a valid certificate path consisting of valid CA certificates, and demonstrate that the function succeeds. The evaluator shall then remove trust in one of the CA certificates, and show that the function fails. - - The evaluator shall demonstrate that validating an expired certificate results in the function failing. - + + The evaluator shall demonstrate that validating an expired certificate results in the function failing. + The evaluator shall test that the TOE can properly handle revoked certificates-conditional on whether CRL, OCSP, OSCP stapling, or OCSP multi-stapling is selected; if multiple methods are selected, then the following tests shall be performed for each method: The evaluator shall test revocation of the node certificate. The evaluator shall also test revocation of the intermediate CA certificate (i.e. the intermediate CA certificate should be revoked by the root CA). For the test of the WLAN use case, only pre-stored CRLs are used. If OCSP stapling per RFC 6066 is the only supported revocation method, this test is omitted. - The evaluator shall ensure that a valid certificate is used, and that the validation function succeeds. The evaluator then attempts the test with a certificate that has been revoked (for each method chosen in the selection) to ensure when the certificate is no longer valid that the validation function fails. - + The evaluator shall ensure that a valid certificate is used, and that the validation function succeeds. The evaluator then attempts the test with a certificate that has been revoked (for each method chosen in the selection) to ensure when the certificate is no longer valid that the validation function fails. - If any OCSP option is selected, the evaluator shall configure the OCSP server or use a man-in-the-middle tool to present a certificate that does not have the OCSP signing purpose and verify that validation of the OCSP response fails. If is selected, + If any OCSP option is selected, the evaluator shall configure the OCSP server or use a man-in-the-middle tool to present a certificate that does not have the OCSP signing purpose and verify that validation of the OCSP response fails. If is selected, the evaluator shall configure the CA to sign a CRL with a certificate that does not have the cRLsign key usage bit set, and verify that validation of the CRL fails. - - The evaluator shall modify any byte in the first eight bytes of the certificate and demonstrate that the certificate fails to validate (the certificate will fail to parse correctly). - - The evaluator shall modify any bit in the last byte of the signature algorithm of the certificate and demonstrate that the certificate fails to validate (the signature on the certificate will not validate). - - The evaluator shall modify any byte in the public key of the certificate and demonstrate that the certificate fails to validate (the signature on the certificate will not validate). - - - - (Conditional on support for EC certificates as indicated in FCS_COP.1(3)). The evaluator shall establish a valid, trusted certificate chain consisting of an EC leaf certificate, an EC Intermediate CA certificate not designated as a trust anchor, and an EC certificate designated as a trusted anchor, where the elliptic curve parameters are specified as a named curve. The evaluator shall confirm that the TOE validates the certificate chain. - (Conditional on support for EC certificates as indicated in FCS_COP.1(3)). The evaluator shall replace the intermediate certificate in the certificate chain for Test 8a with a modified certificate, where the modified intermediate CA has a public key information field where the EC parameters uses an explicit format version of the Elliptic Curve parameters in the public key information field of the intermediate CA certificate from Test 8a, and the modified Intermediate CA certificate is signed by the trusted EC root CA, but having no other changes. The evaluator shall confirm the TOE treats the certificate as invalid. - + + The evaluator shall modify any byte in the first eight bytes of the certificate and demonstrate that the certificate fails to validate (the certificate will fail to parse correctly). + + The evaluator shall modify any bit in the last byte of the signature algorithm of the certificate and demonstrate that the certificate fails to validate (the signature on the certificate will not validate). + + The evaluator shall modify any byte in the public key of the certificate and demonstrate that the certificate fails to validate (the signature on the certificate will not validate). - - Failure to validate X.509v3 certificate - Reason for failure of validation - + + Failure to validate X.509v3 certificate + Reason for failure of validation + - - + + defines the TSF’s usage of X.509 certificates and how it reacts to certificates with undetermined revocation status. The following actions could be considered for the management functions in FMT: - - Configuring whether to allow or disallow establishment of a trusted channel if the TSF cannot establish a connection to determine the validity of a certificate. - - + Configuring whether to allow or disallow establishment of a trusted channel if the TSF cannot establish a connection to determine the validity of a certificate. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - - Failure to establish connection to determine revocation status. - - - FIA_X509_EXT.1 X.509 Validation of Certificates + Failure to establish connection to determine revocation status. + FIA_X509_EXT.1 X.509 Validation of Certificates FTP_ITC_EXT.1 Trusted Channel Communication - - - The TSF shall use X.509v3 certificates as defined by RFC 5280 to support - authentication for [<htm:i>mutually authenticated TLS as defined in the <xref to="pkg-tls"/>, HTTPS, <selectables> - <selectable>IPsec in accordance with the <xref to="mod-vpnclient"/></selectable> - <selectable id="x509_dtls">mutually authenticated DTLS as defined in the <xref to="pkg-tls"/></selectable> - <selectable exclusive="yes">no other protocol</selectable> - </selectables></htm:i>] and <selectables> - <selectable id="x509_sys">code signing for system software updates</selectable> - <selectable id="x509_apps">code signing for mobile applications</selectable> - <selectable id="x509_sign">code signing for integrity verification</selectable> - <selectable><assignable>other uses</assignable></selectable> - <selectable exclusive="yes">no additional uses</selectable> - </selectables>. - - - The TSF shall use X.509v3 certificates as defined by RFC 5280 to support - authentication for <assignable>trusted channel protocol</assignable> and <selectables> - <selectable>code signing for system software updates</selectable> - <selectable>code signing for mobile applications</selectable> - <selectable>code signing for integrity verification</selectable> - <selectable><assignable>other uses</assignable></selectable> - <selectable>no additional uses</selectable> - </selectables>. - - + The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for [ <htm:i>mutually authenticated TLS as defined in the <xref to="pkg-tls"></xref>, HTTPS, <selectables><selectable id="fia_x509_ext.2.1_1" >IPsec in accordance with the <xref to="mod-vpnclient"></xref></selectable><selectable id="x509_dtls" >mutually authenticated DTLS as defined in the <xref to="pkg-tls"></xref></selectable><selectable id="fia_x509_ext.2.1_2" exclusive="yes" >no other protocol</selectable></selectables></htm:i> ] and<selectables><selectable id="x509_sys" >code signing for system software updates</selectable><selectable id="x509_apps" >code signing for mobile applications</selectable><selectable id="x509_sign" >code signing for integrity verification</selectable><selectable id="fia_x509_ext.2.1_4" ><assignable>other uses </assignable></selectable><selectable id="fia_x509_ext.2.1_5" exclusive="yes" >no additional uses</selectable></selectables>. - - The ST author’s first selection must match the selection of and . - Certificates may optionally be used for trusted updates of system software () and mobile applications () and for integrity verification ( and ). + The ST author’s first selection must match the selection of and . + Certificates may optionally be used for trusted updates of system software ( ) and mobile applications ( ) and for integrity verification ( and ). - - If or is selected must be included in the ST. - - - If is selected must be included in the ST. - - - If is included in the ST, must be included in the selection. + + If or is selected must be included in the ST. + If is selected must be included in the ST. + If is included in the ST, must be included in the selection. - When the TSF cannot establish a connection to determine the revocation status of - a certificate, the TSF shall <selectables> - <selectable id="s-revoke-admin"><snip>allow the administrator to choose</snip> whether to accept the certificate in - these cases</selectable> - <selectable id="s-revoke-user"><snip>allow the user to choose</snip> whether to accept the certificate in these - cases</selectable> - <selectable>accept the certificate</selectable> - <selectable id="s-revoke-deny">not accept the certificate</selectable> - </selectables>. - - When the TSF cannot establish a connection to determine the revocation status of - a certificate, the TSF shall <assignable>list of acceptable actions</assignable>. - + When the TSF cannot establish a connection to determine the revocation status of a certificate, the TSF shall<selectables><selectable id="s-revoke-admin" > <snip>allow the administrator to choose</snip> whether to accept the certificate in + these cases</selectable><selectable id="s-revoke-user" > <snip>allow the user to choose</snip> whether to accept the certificate in these + cases</selectable><selectable id="fia_x509_ext.2.2_1" >accept the certificate</selectable><selectable id="s-revoke-deny" >not accept the certificate</selectable></selectables>. The TOE must not accept the certificate if it fails any of the other validation rules in FIA_X509_EXT.1. However, often a connection must be established to perform a verification of the revocation status of a certificate - @@ -7078,24 +3600,16 @@ The evaluator shall generate 10 private/public key pairs using the key generatio behavior in the event that such a connection cannot be established (for example, due to a network error). If the TOE has determined the certificate is valid according to all other rules in FIA_X509_EXT.1, the behavior indicated in the selection must determine - the validity. If or + the validity. If or the administrator-configured or user-configured option is selected, - the ST author must also select function in - FMT_SMF.1. - - s-revoke-admin - mf-certValidity - - - s-revoke-user - mf-certValidity - + the ST author must also select function in + FMT_SMF.1. s-revoke-adminmf-certValidity s-revoke-usermf-certValidity The TOE may behave differently depending on the trusted channel; for example, in the case of WLAN where connections are unlikely to be established, the TOE may accept the certificate even though certificates are not accepted for other channels. The ST author should select all applicable behaviors. - + The evaluator shall check the TSS to ensure that it describes how the TOE chooses which certificates to use, and any necessary instructions in the administrative guidance for configuring the operating environment so that the TOE can use the @@ -7107,7 +3621,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio action, then the evaluator shall ensure that the operational guidance contains instructions on how this configuration action is performed. - The evaluator shall perform the following test for each trusted channel: + The evaluator shall demonstrate that using a valid certificate that requires certificate validation checking to be performed in at least some part by @@ -7121,13 +3635,13 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - - - Failure to establish connection to determine revocation status - + + + Failure to establish connection to determine revocation status + - - + + requires the TSF to make a certificate validation service available to environmental components. There are no management activities foreseen. @@ -7135,18 +3649,17 @@ The evaluator shall generate 10 private/public key pairs using the key generatio FIA_X509_EXT.1 X.509 Validation of Certificates - - The TSF shall provide a certificate validation service to applications. + The TSF shall provide a certificate validation service to applications. - The TSF shall respond to the requesting application with the success or failure - of the validation. + The TSF shall respond to the requesting application with the success or failure of the validation. In order to comply with all of the rules in FIA_X509_EXT.1, multiple API calls may be required; all of these calls should be clearly documented - The evaluator shall verify that the API documentation provided according to - includes the security function (certificate validation) + + The evaluator shall verify that the API documentation provided according to + includes the security function (certificate validation) described in this requirement. This documentation shall be clear as to which results indicate success and failure. There are no TSS evaluation activities for this component. @@ -7159,103 +3672,77 @@ The evaluator shall generate 10 private/public key pairs using the key generatio by FDP_STG_EXT.1, FTP_ITC_EXT.1, FMT_SMF.1, and FIA_X509_EXT.1. - + - - + + requires the TSF to implement Enrollment over Secure Transport (EST) as a mechanism to obtain X.509 certificates. There are no management activities foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - - Generation of Certificate Enrollment Request. - Success or failure of enrollment. - Update of EST Trust Anchor Database - - - FCS_CKM.1 Cryptographic Key Generation + Generation of Certificate Enrollment Request.Success or failure of enrollment.Update of EST Trust Anchor Database + FCS_CKM.1 Cryptographic Key Generation FIA_X509_EXT.1 X.509 Validation of Certificates - - The TSF shall use the Enrollment over Secure Transport (EST) protocol as - specified in RFC 7030 to request certificate enrollment using the simple enrollment - method described in RFC 7030 Section 4.2. + The TSF shall use the Enrollment over Secure Transport (EST) protocol as specified in RFC 7030 to request certificate enrollment using the simple enrollment method described in RFC 7030 Section 4.2. - The TSF shall be capable of authenticating EST requests using an existing - certificate and corresponding private key as specified by RFC 7030 Section - 3.3.2. + The TSF shall be capable of authenticating EST requests using an existing certificate and corresponding private key as specified by RFC 7030 Section 3.3.2. - The TSF shall be capable of authenticating EST requests using HTTP Basic - Authentication with a username and password as specified by RFC 7030 Section - 3.2.3. + The TSF shall be capable of authenticating EST requests using HTTP Basic Authentication with a username and password as specified by RFC 7030 Section 3.2.3. - The TSF shall perform authentication of the EST server using an Explicit Trust - Anchor following the rules described in RFC 7030, section 3.6.1. + The TSF shall perform authentication of the EST server using an Explicit Trust Anchor following the rules described in RFC 7030, section 3.6.1. EST also uses HTTPS as specified in FCS_HTTPS_EXT.1 to establish a secure connection to an EST server. The separate Trust Anchor Database dedicated to EST operations is described as Explicit Trust Anchors in RFC 7030. - The TSF shall be capable of requesting server-provided private keys as specified - in RFC 7030 Section 4.4. + The TSF shall be capable of requesting server-provided private keys as specified in RFC 7030 Section 4.4. - The TSF shall be capable of updating its EST-specific Trust Anchor Database using - the "Root CA Key Update" process described in RFC 7030 Section 4.1.3. + The TSF shall be capable of updating its EST-specific Trust Anchor Database using the "Root CA Key Update" process described in RFC 7030 Section 4.1.3. - The TSF shall generate a Certificate Request Message for EST as specified in RFC - 2986 and be able to provide the following information in the request: public key and <selectables> - <selectable>device-specific information</selectable> - <selectable>Common Name</selectable> - <selectable>Organization</selectable> - <selectable>Organizational Unit</selectable> - <selectable>Country</selectable> - </selectables>. + The TSF shall generate a Certificate Request Message for EST as specified in RFC 2986 and be able to provide the following information in the request: public key and<selectables><selectable id="fia_x509_ext.4.7_1" >device-specific information</selectable><selectable id="fia_x509_ext.4.7_2" >Common Name</selectable><selectable id="fia_x509_ext.4.7_3" >Organization</selectable><selectable id="fia_x509_ext.4.7_4" >Organizational Unit</selectable><selectable id="fia_x509_ext.4.7_5" >Country</selectable></selectables>. The public key referenced is the public key portion of the public-private key pair generated by the TOE as specified in FCS_CKM.1. - The TSF shall validate the chain of certificates from the Root CA certificate in - the Trust Anchor Database to the EST Server CA certificate upon receiving a CA - Certificates Response. - + The TSF shall validate the chain of certificates from the Root CA certificate in the Trust Anchor Database to the EST Server CA certificate upon receiving a CA Certificates Response. + There are no TSS evaluation activities for this component. The evaluator shall check to ensure that the operational guidance contains instructions on requesting certificates from an EST server, including generating a Certificate Request Message. - The evaluator shall also perform the following tests. Other tests are - performed in conjunction with the evaluation activity listed in the Package for - Transport Layer Security. + The evaluator shall use the operational guidance to cause the TOE to request certificate enrollment from an EST server using the simple enrollment method described in RFC 7030 Section 4.2, authenticating the certificate request to the server using an existing certificate and private key as described by RFC 7030 Section 3.3.2. The evaluator shall confirm that the resulting certificate is - successfully obtained and installed in the TOE key store. + successfully obtained and installed in the TOE key store. The evaluator shall use the operational guidance to cause the TOE to request certificate enrollment from an EST server using the simple enrollment method described in RFC 7030 Section 4.2, authenticating the certificate request to the server using a username and password as described by RFC 7030 Section 3.2.3. The evaluator shall confirm that the resulting certificate is successfully obtained - and installed in the TOE key store. + and installed in the TOE key store. The evaluator shall modify the EST server to return a certificate containing a different public key than the key included in the TOE’s certificate request. The evaluator shall use the operational guidance to cause the TOE to request certificate enrollment from an EST server. The evaluator shall confirm that the TOE does not accept the resulting certificate since the public key in the issued - certificate does not match the public key in the certificate request. + certificate does not match the public key in the certificate request. The evaluator shall configure the EST server or use a man-in-the-middle tool to present a server certificate to the TOE that is present in the TOE general Trust Anchor Database but not its EST-specific Trust Anchor Database. The evaluator shall cause the TOE to request certificate enrollment from the EST - server. The evaluator shall verify that the request is not successful. + server. The evaluator shall verify that the request is not successful. The evaluator shall configure the EST server or use a man-in-the-middle tool to present an invalid certificate. The evaluator shall cause the TOE to request certificate enrollment from the EST server. The evaluator shall verify that the @@ -7263,34 +3750,34 @@ The evaluator shall generate 10 private/public key pairs using the key generatio man-in-the-middle tool to present a certificate that does not have the CMC RA purpose and verify that requests to the EST server fail. The tester shall repeat the test using a valid certificate and a certificate that contains the CMC RA - purpose and verify that the certificate enrollment requests succeed. + purpose and verify that the certificate enrollment requests succeed. The evaluator shall use a packet sniffing tool between the TOE and an EST server. The evaluator shall turn on the sniffing tool and cause the TOE to request certificate enrollment from an EST server. The evaluator shall verify that the EST protocol interaction occurs over a Transport Layer Security (TLS) protected connection. The evaluator is not expected to decrypt the connection - but rather observe that the packets conform to the TLS protocol format. + but rather observe that the packets conform to the TLS protocol format. The evaluator shall use the operational guidance to cause the TOE to request a server-provided private key and certificate from an EST server. The evaluator shall confirm that the resulting private key and certificate are successfully - obtained and installed in the TOE key store. + obtained and installed in the TOE key store. The evaluator shall modify the EST server to, in response to a server-provided private key and certificate request, return a private key that does not correspond with the public key in the returned certificate. The evaluator shall use the operational guidance to cause the TOE to request a server-provided private key and certificate. The evaluator shall confirm that the TOE does not accept the resulting private key and certificate since the - private key and public key do not correspond. + private key and public key do not correspond. The evaluator shall configure the EST server to provide a "Root CA Key Update" as described in RFC 7030 Section 4.1.3. The evaluator shall cause the TOE to request CA certificates from the EST server and shall confirm that the - EST-specific Trust Anchor Database is updated with the new trust anchor. + EST-specific Trust Anchor Database is updated with the new trust anchor. The evaluator shall configure the EST server to provide a "Root CA Key Update" as described in RFC 7030 Section 4.1.3, but shall modify part of the NewWithOld certificate’s generated signature. The evaluator shall cause the TOE to request CA certificates from the EST server and shall confirm that the EST-specific Trust Anchor Database is not updated with the new trust anchor - since the signature did not verify. + since the signature did not verify. The evaluator shall use the operational guidance to cause the TOE to generate a certificate request message. The evaluator shall capture the generated message and ensure that it conforms to the format specified by RFC @@ -7301,40 +3788,31 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - - Generation of Certificate Enrollment Request - Issuer and Subject name of EST Server. Method of authentication. Issuer and Subject name of certificate used to authenticate. Content of Certificate Request Message - - - - Success or failure of enrollment - Issuer and Subject name of added certificate or reason for failure - - - Update of EST Trust Anchor Database - Subject name of added Root CA - + + Generation of Certificate Enrollment Request + Issuer and Subject name of EST Server. Method of authentication. Issuer and Subject name of certificate used to authenticate. Content of Certificate Request Message + + + Success or failure of enrollment + Issuer and Subject name of added certificate or reason for failure + + + Update of EST Trust Anchor Database + Subject name of added Root CA + - - + + requires the TSF to generate X.509 certificate requests and validate the responses. There are no management activities foreseen. There are no auditable events foreseen. - FCS_CKM.1 Cryptographic Key Generation + FCS_CKM.1 Cryptographic Key Generation FIA_X509_EXT.1 X.509 Validation of Certificates - - The TSF shall generate a Certificate Request Message as specified in RFC 2986 and - be able to provide the following information in the request: public key and <selectables> - <selectable>device-specific information</selectable> - <selectable>Common Name</selectable> - <selectable>Organization</selectable> - <selectable>Organizational Unit</selectable> - <selectable>Country</selectable> - </selectables>. + The TSF shall generate a Certificate Request Message as specified in RFC 2986 and be able to provide the following information in the request: public key and<selectables><selectable id="fia_x509_ext.5.1_1" >device-specific information</selectable><selectable id="fia_x509_ext.5.1_2" >Common Name</selectable><selectable id="fia_x509_ext.5.1_3" >Organization</selectable><selectable id="fia_x509_ext.5.1_4" >Organizational Unit</selectable><selectable id="fia_x509_ext.5.1_5" >Country</selectable></selectables>. The public key referenced in FIA_X509_EXT.5.1 is the public key portion of the public-private key pair generated by the TOE as specified in FCS_CKM.1. The trusted channel requirements do not apply to communication with the CA for the @@ -7345,9 +3823,8 @@ The evaluator shall generate 10 private/public key pairs using the key generatio Certificate Request Messages but do not yet implement EST. - The TSF shall validate the chain of certificates from the Root CA upon receiving - the CA Certificate Response. - + The TSF shall validate the chain of certificates from the Root CA upon receiving the CA Certificate Response. + If the ST author selects "device-specific information", the evaluator shall verify that the TSS contains a description of the device-specific fields used in certificate requests. @@ -7356,12 +3833,15 @@ The evaluator shall generate 10 private/public key pairs using the key generatio "Common Name", "Organization", "Organizational Unit", or "Country", the evaluator shall ensure that this guidance includes instructions for establishing these fields before creating the certificate request message. - The evaluator shall also perform the following tests: The + + + The evaluator shall also perform the following tests: + The evaluator shall use the operational guidance to cause the TOE to generate a certificate request message. The evaluator shall capture the generated message and ensure that it conforms to the format specified. The evaluator shall confirm that the certificate request provides the public key and other required - information, including any necessary user-input information. + information, including any necessary user-input information. The evaluator shall demonstrate that validating a certificate response message without a valid certification path results in the function failing. The evaluator shall then load a certificate or certificates as trusted CAs needed to @@ -7372,37 +3852,26 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - + - - +
    + +
    + Both the user and the administrator may manage the TOE. This administrator is likely to be acting remotely and could be the Mobile Device Management (MDM) Administrator acting through an MDM Agent. - The Administrator is responsible for management activities, including setting the policy that is applied by the enterprise on the Mobile Device. These management functions are likely to be a different set than those management functions provided to the user. Management functions that are provided to the user and not the administrator are listed in FMT_MOF_EXT.1.1. Management functions for which the administrator may adopt a policy that restricts the user from performing that function are listed in FMT_MOF_EXT.1.2. - compares the management functions required by this Protection Profile in the following three requirements (FMT_MOF_EXT.1.1, FMT_MOF_EXT.1.2, and FMT_SMF.1). - - - This family defines requirements for authorization to manage the behavior of the TSF that are not addressed by FMT_MOF in CC Part 2. - - + The Administrator is responsible for management activities, including setting the policy that is applied by the enterprise on the Mobile Device. These management functions are likely to be a different set than those management functions provided to the user. Management functions that are provided to the user and not the administrator are listed in FMT_MOF_EXT.1.1. Management functions for which the administrator may adopt a policy that restricts the user from performing that function are listed in FMT_MOF_EXT.1.2. compares the management functions required by this Protection Profile in the following three requirements (FMT_MOF_EXT.1.1, FMT_MOF_EXT.1.2, and FMT_SMF.1). - + + requires the TSF to apply restrictions to access its management functions to the authorized roles. The following actions could be considered for the management functions in FMT: - - Managing the group of roles that can interact with the functions in the TSF. - - + Managing the group of roles that can interact with the functions in the TSF. There are no auditable events foreseen. FMT_SMF.1 Specification of Management Functions - - - The TSF shall restrict the ability to perform the functions [<htm:i>in column 4 of - <xref to="fmt_smf"/></htm:i>] to the user. - - The TSF shall restrict the ability to perform the functions <assignable>reference to list of management functions</assignable> to the user. - + The TSF shall restrict the ability to perform the functions [ <htm:i>in column 4 of + <xref to="fmt_smf"></xref></htm:i> ] to the user. The functions that have an "M" in the fourth column are mandatory for this component, thus are restricted to the user, meaning that the administrator cannot manage those functions. The functions that have an "O" in the @@ -7429,13 +3898,8 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - The TSF shall restrict the ability to perform the functions [<htm:i>in column 6 of - <xref to="fmt_smf"/></htm:i>] to the administrator when the device is enrolled and - according to the administrator-configured policy. - - The TSF shall restrict the ability to perform the functions <assignable>reference to list of management functions</assignable> to the administrator when the device is enrolled and - according to the administrator-configured policy. - + The TSF shall restrict the ability to perform the functions [ <htm:i>in column 6 of + <xref to="fmt_smf"></xref></htm:i> ] to the administrator when the device is enrolled and according to the administrator-configured policy. As long as the device is enrolled in management, the administrator (of the enterprise) must be guaranteed that minimum security functions of the enterprise policy are enforced. Further restrictive policies can be applied at @@ -7468,7 +3932,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio The evaluator shall use the test environment to deploy policies to Mobile - Devices. + Devices. The evaluator shall create policies which collectively include all management functions which are controlled by the (enterprise) administrator and cannot be overridden/relaxed by the user as defined in FMT_MOF_EXT.1.2. The @@ -7476,129 +3940,47 @@ The evaluator shall generate 10 private/public key pairs using the key generatio setting both as the user (if a setting is available) and as an application (if an API is available), and ensure that the TSF does not permit it. Note that the user may still apply a more restrictive policy than that of the - administrator. + administrator. Additional testing of functions provided to the administrator are performed in conjunction with the testing activities for FMT_SMF.1.1. - + - - - This family defines requirements for security-relevant management functions that are not addressed by FMT_SMF in CC Part 2. - - - - - - + + - The TSF shall be capable of performing the following management functions: <htm:br/><htm:br/> - <htm:b><ctr id="fmt_smf" ctr-type="Table">: Management Functions</ctr></htm:b><htm:br/><htm:br/> - Status Markers:<htm:br/> M - Mandatory<htm:br/> O - Optional/Objective<htm:br/> - <!-- NOTE: management-function uses ctr variables crt-type=functions in the MOOO table, so that they do not - have to be renumbered when one is added or removed. However app notes and AAs need to be in the same order as the functions. - The list of IDs for each function is at the end of the xml.--> - <management-function-set default="O"> - <manager cid="I">Impl.</manager> - <manager cid="U">User Only</manager> - <manager cid="A">Admin</manager> - <manager cid="AO">Admin Only</manager> - <management-function id="mf-pwd"> - <text> - <!-- <ctr id="pwd" pre="" ctr-type="function">.</ctr>--> configure password policy: - <htm:ul> - <htm:li>Minimum password length</htm:li> - <htm:li>Minimum password complexity</htm:li> - <htm:li>Maximum password lifetime</htm:li> - </htm:ul> - </text> - <M ref="I"/> <NA ref="U"/><M ref="A"/><M ref="AO"/> - <aactivity> - <TSS>The evaluator shall verify + <title><!-- NOTE: There is currently no support for Management Function tables, so the following raw XML will be used in the XML Export --> <htm:br/> + The TSF shall be capable of performing the following management functions: <htm:br></htm:br><htm:br></htm:br><htm:b><ctr id="fmt_smf" ctr-type="Table">: Management Functions</ctr></htm:b><htm:br></htm:br><htm:br></htm:br> + Status Markers:<htm:br></htm:br> M - Mandatory<htm:br></htm:br> O - Optional/Objective<htm:br></htm:br><management-function-set default="O"><manager cid="I">Impl.</manager><manager cid="U">User Only</manager><manager cid="A">Admin</manager><manager cid="AO">Admin Only</manager><management-function id="mf-pwd"><text> configure password policy: + <htm:ul><htm:li>Minimum password length</htm:li><htm:li>Minimum password complexity</htm:li><htm:li>Maximum password lifetime</htm:li></htm:ul></text><M ref="I"></M><NA ref="U"></NA><M ref="A"></M><M ref="AO"></M><aactivity><TSS>The evaluator shall verify the TSS defines the allowable policy options: the range of values for both password length and lifetime, and a description of complexity to include character set and complexity policies (e.g., configuration and enforcement of number of - uppercase, lowercase, and special characters per password).</TSS> - <Tests> + uppercase, lowercase, and special characters per password).</TSS><Tests> The evaluator shall exercise the TSF configuration as the administrator and perform positive and negative tests, with at least two values set for each - variable setting, for each of the following: <htm:br/> - <htm:ul> - <htm:li>Minimum password length</htm:li> - <htm:li>Minimum password complexity</htm:li> - <htm:li>Maximum password lifetime</htm:li> - </htm:ul> - </Tests> - </aactivity> - - </management-function> - <management-function id="mf-screenlock"> - <text> - <!-- <ctr id="screenlock" pre="" ctr-type="function">.</ctr>--> configure session - locking policy: <htm:ul> - <htm:li>Screen-lock enabled/disabled</htm:li> - <htm:li>Screen lock timeout </htm:li> - <htm:li>Number of authentication failures</htm:li> - </htm:ul> - </text> - <M ref="I"/><NA ref="U"/><M ref="A"/><M ref="AO"/> - <aactivity> - <TSS>The evaluator shall + variable setting, for each of the following: <htm:br></htm:br><htm:ul><htm:li>Minimum password length</htm:li><htm:li>Minimum password complexity</htm:li><htm:li>Maximum password lifetime</htm:li></htm:ul></Tests></aactivity></management-function><management-function id="mf-screenlock"><text> configure session + locking policy: <htm:ul><htm:li>Screen-lock enabled/disabled</htm:li><htm:li>Screen lock timeout </htm:li><htm:li>Number of authentication failures</htm:li></htm:ul></text><M ref="I"></M><NA ref="U"></NA><M ref="A"></M><M ref="AO"></M><aactivity><TSS>The evaluator shall verify the TSS defines the range of values for both timeout period and number of - authentication failures for all supported authentication mechanisms.</TSS> - <Tests> The evaluator shall exercise the TSF configuration as the administrator. + authentication failures for all supported authentication mechanisms.</TSS><Tests> The evaluator shall exercise the TSF configuration as the administrator. The evaluator shall perform positive and negative tests, with at least two - values set for each variable setting, for each of the following: <htm:br/> - <htm:ul> - <htm:li>Screen-lock enabled/disabled</htm:li> - <htm:li>Screen lock timeout</htm:li> - <htm:li>Number of authentication failures (may be combined with test for - FIA_AFL_EXT.1)</htm:li> - </htm:ul> - </Tests> - </aactivity> - </management-function> - <management-function id="mf-vpn"> - <text> - <!-- <ctr id="vpn" pre="" ctr-type="function">.</ctr>--> enable/disable the VPN - protection: <htm:ul> - <htm:li>Across device</htm:li></htm:ul> - <htm:div class="indent"> - <selectables linebreak="yes"> - <selectable id="s-vpn-per-app">on a per-app basis</selectable> - <selectable id="s-vpn-per-appgroup">on a per-group of applications processes basis</selectable> - <selectable exclusive="yes">no other method</selectable> - </selectables></htm:div> - </text> - <M ref="I"/> - <app-note><also ref-id="mf-audioVisual"/><also ref-id="mf-location"/> - Functions <_/> must be implemented on a device-wide basis but may also be + values set for each variable setting, for each of the following: <htm:br></htm:br><htm:ul><htm:li>Screen-lock enabled/disabled</htm:li><htm:li>Screen lock timeout</htm:li><htm:li>Number of authentication failures (may be combined with test for + FIA_AFL_EXT.1)</htm:li></htm:ul></Tests></aactivity></management-function><management-function id="mf-vpn"><text> enable/disable the VPN + protection: <htm:ul><htm:li>Across device</htm:li></htm:ul><htm:div class="indent"><selectables linebreak="yes"><selectable id="s-vpn-per-app">on a per-app basis</selectable><selectable id="s-vpn-per-appgroup">on a per-group of applications processes basis</selectable><selectable exclusive="yes">no other method</selectable></selectables></htm:div></text><M ref="I"></M><app-note><also ref-id="mf-audioVisual"></also><also ref-id="mf-location"></also> + Functions <_></_> must be implemented on a device-wide basis but may also be implemented on a per-app basis or on a per-group of applications basis in which the configuration includes the list of applications or groups of applications to which the - enable/disable applies.</app-note> - <app-note> - Function <_/> addresses + enable/disable applies.</app-note><app-note> + Function <_></_> addresses enabling and disabling the IPsec VPN only. The configuration of the VPN Client itself (with information such as VPN Gateway, certificates, and algorithms) is addressed by - the <xref to="mod-vpnclient"/>. The administrator options should only be listed if the + the <xref to="mod-vpnclient"></xref>. The administrator options should only be listed if the administrator can remotely enable/disable the VPN connection. <htm:p> - Function <xref to="mf-vpn"/> optionally allows the VPN to be configured per-app or + Function <xref to="mf-vpn"></xref> optionally allows the VPN to be configured per-app or per-groups of apps. If this configuration is selected, it does not void FDP_IFC_EXT.1. Instead FDP_IFC_EXT.1 is applied to the application or group of applications the VPN is applied to. In other words, all traffic destined for the VPN-enabled application or @@ -7606,24 +3988,18 @@ The evaluator shall exercise the TSF configuration as the administrator and application or group of applications can travel outside the VPN. When the VPN is configured across the device FDP_IFC_EXT.1 applies to all traffic and the VPN must not split tunnel. - </htm:p> - </app-note> - <aactivity> - <Tests> + </htm:p></app-note><aactivity><Tests> The evaluator shall perform the following tests: - <testlist> - <test>The evaluator shall exercise the TSF configuration to enable the VPN + <testlist><test>The evaluator shall exercise the TSF configuration to enable the VPN protection. These configuration actions must be used for the testing of the - FDP_IFC_EXT.1.1 requirement. </test> - <test>[conditional] If "<xref to="s-vpn-per-app"/>" is selected, the evaluator shall + FDP_IFC_EXT.1.1 requirement. </test><test>[conditional] If "<xref to="s-vpn-per-app"></xref>" is selected, the evaluator shall create two applications and enable one to use the VPN and the other to not use the VPN. The evaluator shall exercise each application (attempting to access network resources; for example, by browsing different websites) individually while capturing packets from the TOE. The evaluator shall verify from the packet capture that the traffic from the VPN-enabled application is encapsulated in IPsec and that the traffic from the - VPN-disabled application is not encapsulated in IPsec. </test> - <test>[conditional] If "<xref to="s-vpn-per-appgroup"/>" is selected, the + VPN-disabled application is not encapsulated in IPsec. </test><test>[conditional] If "<xref to="s-vpn-per-appgroup"></xref>" is selected, the evaluator shall create two applications and the applications shall be placed into different groups. Enable one application group to use the VPN and the other to not use the VPN. The evaluator shall exercise each application @@ -7632,18 +4008,9 @@ The evaluator shall exercise the TSF configuration as the administrator and shall verify from the packet capture that the traffic from the application in the VPN-enabled group is encapsulated in IPsec and that the traffic from the application in the VPN-disabled group is not encapsulated in IPsec. - </test> - </testlist> - </Tests> - </aactivity> - </management-function> - <management-function id="mf-radios"> - <text> - <!-- <ctr id="radios" pre="" ctr-type="function">.</ctr>--> enable/disable - <assignable id="a-mf-radios">list of all radios</assignable></text> - <M ref="I"/> - <app-note> - The assignment in function <_/> + </test></testlist></Tests></aactivity></management-function><management-function id="mf-radios"><text> enable/disable + <assignable id="a-mf-radios">list of all radios</assignable></text><M ref="I"></M><app-note> + The assignment in function <_></_> consists of all radios present on the TSF, such as Wi-Fi, cellular, NFC, Bluetooth BR/EDR, and Bluetooth LE, which can be enabled and disabled. In the future, @@ -7652,8 +4019,7 @@ The evaluator shall exercise the TSF configuration as the administrator and the radio may not be enabled in order to place emergency phone calls; however, it is not expected that a device in "airplane mode", where all radios are disabled, will automatically (without authorization) turn on the cellular radio to place emergency - calls.</app-note> - <aactivity><TSS> + calls.</app-note><aactivity><TSS> The evaluator shall verify that the TSS includes a description of each radio and an indication of if the radio can be enabled/disabled along with what role can do so. In addition the @@ -7663,32 +4029,30 @@ The evaluator shall exercise the TSF configuration as the administrator and as part of the initialization of the device. </TSS><Guidance> The evaluator shall confirm that the AGD guidance describes - how to perform the enable/disable function for each radio.<htm:br/><htm:br/> - </Guidance> - <Tests> + how to perform the enable/disable function for each radio.<htm:br></htm:br><htm:br></htm:br></Guidance><Tests> The evaluator shall ensure that minimal signal leakage enters the RF shielded enclosure (i.e. Faraday bag, Faraday box, RF shielded room) by performing the - following steps:<htm:br/><htm:br/> Step 1: Place the antenna of the spectrum - analyzer inside the RF shielded enclosure.<htm:br/><htm:br/> Step 2: Enable "Max + following steps:<htm:br></htm:br><htm:br></htm:br> Step 1: Place the antenna of the spectrum + analyzer inside the RF shielded enclosure.<htm:br></htm:br><htm:br></htm:br> Step 2: Enable "Max Hold" on the spectrum analyzer and perform a spectrum sweep of the frequency range between 300 MHz – 6000 MHz, in I kHz steps (this range should encompass 802.11, 802.15, GSM, UMTS, and LTE). This range will not address NFC 13.56.MHz, another - test should be set up with similar constraints to address NFC.<htm:br/><htm:br/> + test should be set up with similar constraints to address NFC.<htm:br></htm:br><htm:br></htm:br> If power above -90 dBm is observed, the Faraday box has too great of signal leakage and shall not be used to complete the test for - Function <xref to="mf-radios"/>. + Function <xref to="mf-radios"></xref>. The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to the administrator, the user, to enable and disable the state of each radio (e.g. Wi-Fi, cellular, NFC, Bluetooth). Additionally, the evaluator shall repeat the steps below, booting into any auxiliary boot mode - supported by the device. For each radio, the evaluator shall:<htm:br/><htm:br/> + supported by the device. For each radio, the evaluator shall:<htm:br></htm:br><htm:br></htm:br> Step 1: Place the antenna of the spectrum analyzer inside the RF shielded enclosure. Configure the spectrum analyzer to sweep desired frequency range for the radio to be tested (based on range provided in the TSS)). The ambient noise floor shall be set to -110 dBm. Place the TOE into the RF shielded enclosure to - isolate them from all other RF traffic. <htm:br/><htm:br/> Step 2: The evaluator + isolate them from all other RF traffic. <htm:br></htm:br><htm:br></htm:br> Step 2: The evaluator shall create a baseline of the expected behavior of RF signals. The evaluator shall power on the device, ensure the radio in question is enabled, power off the device, enable "Max Hold" on the spectrum analyzer and power on the device. @@ -7696,7 +4060,7 @@ The evaluator shall exercise the TSF configuration as the administrator and to entering the necessary password to complete the boot process, waiting 5 minutes after the device is fully booted. The evaluator shall observe that RF spikes are present at the expected uplink channel frequency. The evaluator shall - clear the "Max Hold" on the spectrum analyzer. <htm:br/><htm:br/> Step 3: The + clear the "Max Hold" on the spectrum analyzer. <htm:br></htm:br><htm:br></htm:br> Step 3: The evaluator shall verify the absence of RF activity for the uplink channel when the radio in question is disabled. The evaluator shall complete the following test five times. The evaluator shall power on the device, ensure the radio in @@ -7710,21 +4074,8 @@ The evaluator shall exercise the TSF configuration as the administrator and RF activity for the uplink channel of the specific radio frequency band is observed after the device is fully booted or at an Authentication Factor interface it is deemed that the radio is enabled. - </Tests></aactivity> - </management-function> - <management-function id="mf-audioVisual"> - <text> - <!-- <ctr id="audioVisual" pre="" ctr-type="function">.</ctr>--> enable/disable - <assignable id="a-audiovisual-devs">list of audio or visual collection devices</assignable>: <htm:ul> - <htm:li>Across device</htm:li></htm:ul> - <htm:div class="indent"><selectables linebreak="yes"> - <selectable id="s-audiovisual-per-app">on a per-app basis</selectable> - <selectable id="s-audiovisual-per-appgroup">on a per-group of applications processes basis</selectable> - <selectable exclusive="yes">no other method</selectable> - </selectables></htm:div> - </text> - <M ref="I"/> - <app-note>The assignment in function <_/> + </Tests></aactivity></management-function><management-function id="mf-audioVisual"><text> enable/disable + <assignable id="a-audiovisual-devs">list of audio or visual collection devices</assignable>: <htm:ul><htm:li>Across device</htm:li></htm:ul><htm:div class="indent"><selectables linebreak="yes"><selectable id="s-audiovisual-per-app">on a per-app basis</selectable><selectable id="s-audiovisual-per-appgroup">on a per-group of applications processes basis</selectable><selectable exclusive="yes">no other method</selectable></selectables></htm:div></text><M ref="I"></M><app-note>The assignment in function <_></_> consists of at least one audio or visual device, such as camera and microphone, which can be enabled and disabled by either the user or administrator. Disablement of the microphone does not imply that the microphone may not be enabled in order to place @@ -7733,7 +4084,7 @@ The evaluator shall exercise the TSF configuration as the administrator and restricted to users, then this function should be iterated in the table with the appropriate table entries. <htm:p> - Regarding functions <xref to="mf-radios"/> and <xref to="mf-audioVisual"/>, + Regarding functions <xref to="mf-radios"></xref> and <xref to="mf-audioVisual"></xref>, disablement of a particular radio or audio/visual device must be effective as soon as the TOE has power. Disablement must also apply when the TOE is booted into auxiliary boot modes, for @@ -7743,18 +4094,14 @@ The evaluator shall exercise the TSF configuration as the administrator and are disabled by default while in these states. That these devices are disabled during auxiliary boot modes does not imply that the device (particularly the cellular radio) may not be enabled in order to perform emergency phone calls. - </htm:p> - </app-note> - <aactivity><TSS> + </htm:p></app-note><aactivity><TSS> The evaluator shall verify that the TSS includes a description of each collection device and an indication of if it can be enabled/disabled along with what role can do so. The evaluator shall confirm that the AGD guidance describes how to perform the enable/disable function. - </TSS> - <Tests>The evaluator shall perform the following tests: - <testlist> - <test>The evaluator shall exercise the TSF configuration as the + </TSS><Tests>The evaluator shall perform the following tests: + <testlist><test>The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to the administrator, the user, to enable and disable the state of each audio or visual collection devices (e.g. camera, microphone) listed by the ST author. For each collection @@ -7762,223 +4109,111 @@ The evaluator shall exercise the TSF configuration as the administrator and functionality. The evaluator shall reboot the TOE and verify that disabled collection devices may not be used during or early in the boot process. Additionally, the evaluator shall boot the device into each available - auxiliary boot mode and verify that the collection device cannot be used. </test> - <test>[conditional] If "<xref to="s-audiovisual-per-app"/>" is selected, the evaluator shall + auxiliary boot mode and verify that the collection device cannot be used. </test><test>[conditional] If "<xref to="s-audiovisual-per-app"></xref>" is selected, the evaluator shall create two applications and enable one to use access the A/V device and the other to not access the A/V device. The evaluator shall exercise each application attempting to access the A/V device individually. The evaluator shall verify that the enabled application is able to access the A/V device - and the disabled application is not able to access the A/V device. </test> - <test>[conditional] If "<xref to="s-audiovisual-per-appgroup"/>" is selected, the + and the disabled application is not able to access the A/V device. </test><test>[conditional] If "<xref to="s-audiovisual-per-appgroup"></xref>" is selected, the evaluator shall create two applications and the applications shall be placed into different groups. Enable one group to access the A/V device and the other to not access the A/V device. The evaluator shall exercise each application attempting to access the A/V device individually. The evaluator shall verify that the application in the enabled group is able to access the A/V device and the application in the disabled group is not able to access - the A/V device. </test> - </testlist> - </Tests> - </aactivity> - </management-function> - <management-function id="mf-lockState"> - <text> - <!-- 6. --> - <!-- <ctr id="lockState" pre="" ctr-type="function">.</ctr>--> transition to the locked - state </text> - <M ref="I"/><NA ref="U"/><M ref="A"/><NA ref="AO"/> - <aactivity><Tests> + the A/V device. </test></testlist></Tests></aactivity></management-function><management-function id="mf-lockState"><text> transition to the locked + state </text><M ref="I"></M><NA ref="U"></NA><M ref="A"></M><NA ref="AO"></NA><aactivity><Tests> The evaluator shall use the test environment to instruct the TSF, both as a user and as the administrator, to command the device to transition to a locked state, and verify that the device transitions to the locked state upon command. - </Tests></aactivity> - </management-function> - <management-function id="mf-wipe"> - <text> - <!-- 7. --> - <!-- <ctr id="wipe" pre="" ctr-type="function">.</ctr>--> TSF wipe of protected data </text> - <M ref="I"/> - <NA ref="U"/> - <M ref="A"/> - <NA ref="AO"/> - <app-note> - Wipe of the TSF (function <xref to="mf-wipe"/>) is performed according to + </Tests></aactivity></management-function><management-function id="mf-wipe"><text> TSF wipe of protected data </text><M ref="I"></M><NA ref="U"></NA><M ref="A"></M><NA ref="AO"></NA><app-note> + Wipe of the TSF (function <xref to="mf-wipe"></xref>) is performed according to FCS_CKM_EXT.5. Protected data is all non-TSF data, including all user or enterprise data. Some or all - of this data may be considered sensitive data as well.</app-note> - <aactivity> - <Tests>The evaluator shall use the test environment to instruct the TSF, both as a user and as the administrator, to command the device to perform a wipe of protected data. - The evaluator must ensure that this management setup is used when conducting the Evaluation Activities in FCS_CKM_EXT.5.</Tests> - </aactivity> - </management-function> - <management-function id="mf-appInstallRules"> - <text> - <!--8. --> - <!-- <ctr id="appInstallRules" pre="" ctr-type="function">.</ctr>--> configure - application installation policy by <htm:div class="indent"><selectables linebreak="yes"> - <selectable id="mf-appInstallRules-restrict">restricting the sources of applications</selectable> - <selectable id="mf-appInstallRules-specify">specifying a set of allowed applications based on - <assignable>application characteristics</assignable> (an <snip>application allowlist</snip>)</selectable> - <selectable id="mf-appInstallRules-deny">denying installation of applications</selectable> - </selectables></htm:div> - </text> - <M ref="I"/><NA ref="U"/><M ref="A"/><M ref="AO"/> - <app-note> + of this data may be considered sensitive data as well.</app-note><aactivity><Tests>The evaluator shall use the test environment to instruct the TSF, both as a user and as the administrator, to command the device to perform a wipe of protected data. + The evaluator must ensure that this management setup is used when conducting the Evaluation Activities in FCS_CKM_EXT.5.</Tests></aactivity></management-function><management-function id="mf-appInstallRules"><text> configure + application installation policy by <htm:div class="indent"><selectables linebreak="yes"><selectable id="mf-appInstallRules-restrict">restricting the sources of applications</selectable><selectable id="mf-appInstallRules-specify">specifying a set of allowed applications based on + <assignable>application characteristics</assignable> (an <snip>application allowlist</snip>)</selectable><selectable id="mf-appInstallRules-deny">denying installation of applications</selectable></selectables></htm:div></text><M ref="I"></M><NA ref="U"></NA><M ref="A"></M><M ref="AO"></M><app-note> The - selection in function <xref to="mf-appInstallRules"/> allows the ST author to + selection in function <xref to="mf-appInstallRules"></xref> allows the ST author to select which mechanisms are available to the administrator through the MDM Agent to restrict the applications which the user may install. The ST author must state if application allowlist is applied device-wide or if it can be specified to apply to - either the Enterprise or Personal applications. <htm:ul> - <htm:li>If the administrator can restrict the sources from which applications can be - installed, the ST author selects "<xref to="mf-appInstallRules-restrict"/>". </htm:li> - <htm:li>If the administrator can specify a allowlist of allowed applications, the ST - author selects "<xref to="mf-appInstallRules-specify"/>". The ST author should list any application characteristics + either the Enterprise or Personal applications. <htm:ul><htm:li>If the administrator can restrict the sources from which applications can be + installed, the ST author selects "<xref to="mf-appInstallRules-restrict"></xref>". </htm:li><htm:li>If the administrator can specify a allowlist of allowed applications, the ST + author selects "<xref to="mf-appInstallRules-specify"></xref>". The ST author should list any application characteristics (e.g. name, version, or developer) based on which the allowlist can be - formed.</htm:li> - <htm:li>If the administrator can prevent the user from installing additional - applications, the ST author selects "<xref to="mf-appInstallRules-deny"/>". </htm:li> - </htm:ul> - </app-note> - <aactivity><TSS> + formed.</htm:li><htm:li>If the administrator can prevent the user from installing additional + applications, the ST author selects "<xref to="mf-appInstallRules-deny"></xref>". </htm:li></htm:ul></app-note><aactivity><TSS> The evaluator shall verify the TSS describes the allowable application installation policy options based on the selection included in the ST. - If the <xref to="mf-appInstallRules-specify"/> is selected, + If the <xref to="mf-appInstallRules-specify"></xref> is selected, the evaluator shall verify that the TSS includes a description of each application characteristic upon which the allowlist may be based. - </TSS> - <Tests> The evaluator shall exercise the TSF configuration as the administrator to + </TSS><Tests> The evaluator shall exercise the TSF configuration as the administrator to restrict particular applications, sources of applications, or application installation according to the AGD guidance. The evaluator shall attempt to install unauthorized applications and ensure that this is not possible. The evaluator shall, in conjunction, perform the following specific tests: - <testlist> - <test>[conditional] The evaluator shall attempt to connect to an - unauthorized repository in order to install applications. </test> - <test>[conditional] The evaluator shall attempt to install two applications + <testlist><test>[conditional] The evaluator shall attempt to connect to an + unauthorized repository in order to install applications. </test><test>[conditional] The evaluator shall attempt to install two applications (one allowlisted, and one not) from a known allowed repository and verify that the application not on the allowlist is rejected. The evaluator shall also attempt to side-load executables or installation packages via USB connections to determine that the white list is still adhered to - </test> - </testlist> - </Tests> - </aactivity> - </management-function> - <management-function id="mf-keyStorage"> - <text> - <!-- 9. --> - <!-- <ctr id="keyStorage" pre="" ctr-type="function">.</ctr>--> import keys or secrets into - the secure key storage </text> - <M ref="I"/><NA ref="AO"/> - <aactivity><also ref-id="mf-keyWipe"/> - <TSS>The evaluator shall verify that the TSS + </test></testlist></Tests></aactivity></management-function><management-function id="mf-keyStorage"><text> import keys or secrets into + the secure key storage </text><M ref="I"></M><NA ref="AO"></NA><aactivity><also ref-id="mf-keyWipe"></also><TSS>The evaluator shall verify that the TSS describes each category of keys or secrets that can be imported into the TSF’s secure - key storage.</TSS> - <Tests> + key storage.</TSS><Tests> The test of these functions is performed in association with FCS_STG_EXT.1. - </Tests> - </aactivity> - </management-function> - <management-function id="mf-keyWipe"> - <text> - <!-- 10. --> - <!-- <ctr id="keyWipe" pre="" ctr-type="function">.</ctr>--> destroy imported - keys or secrets and <selectables> - <selectable exclusive="yes">no other keys or secrets</selectable> - <selectable><assignable>list of other categories of - keys or secrets</assignable></selectable> - </selectables> in the secure key storage </text> - <M ref="I"/><NA ref="AO"/> - </management-function> - <management-function id="mf-certImport"> - <text> - <!-- 11. --> - <!-- <ctr id="certImport" pre="" ctr-type="function">.</ctr>--> import X.509v3 - certificates into the Trust Anchor Database </text> - <M ref="I"/><NA ref="U"/><M ref="A"/> - <aactivity> - <Guidance>The evaluator shall + </Tests></aactivity></management-function><management-function id="mf-keyWipe"><text> destroy imported + keys or secrets and <selectables><selectable exclusive="yes">no other keys or secrets</selectable><selectable><assignable>list of other categories of + keys or secrets</assignable></selectable></selectables> in the secure key storage </text><M ref="I"></M><NA ref="AO"></NA></management-function><management-function id="mf-certImport"><text> import X.509v3 + certificates into the Trust Anchor Database </text><M ref="I"></M><NA ref="U"></NA><M ref="A"></M><aactivity><Guidance>The evaluator shall review the AGD guidance to determine that it describes the steps needed to import, modify, or remove certificates in the Trust Anchor database, and that the users that have authority to import those certificates (e.g., only administrator, or both administrators and users) are identified. - </Guidance> - <Tests> + </Guidance><Tests> The evaluator shall import certificates according to the AGD guidance as the user or as the administrator, as determined by the administrative guidance. The evaluator shall verify that no errors occur during import. The evaluator should perform an action requiring use of the X.509v3 certificate to provide assurance that installation was completed properly. - </Tests> - </aactivity> - </management-function> - <management-function id="mf-certWipe"> - <text> - <!-- 12. --> - <!-- <ctr id="certWipe" pre="" ctr-type="function">.</ctr>--> remove imported X.509v3 - certificates and <selectables> - <selectable exclusive="yes">no other X.509v3 certificates</selectable> - <selectable><assignable>list of other categories of X.509v3 - certificates</assignable></selectable> - </selectables> in the Trust Anchor Database </text> - <M ref="I"/><NA ref="AO"/> - <app-note> - In the future, function <xref to="mf-certWipe"/> may require + </Tests></aactivity></management-function><management-function id="mf-certWipe"><text> remove imported X.509v3 + certificates and <selectables><selectable exclusive="yes">no other X.509v3 certificates</selectable><selectable><assignable>list of other categories of X.509v3 + certificates</assignable></selectable></selectables> in the Trust Anchor Database </text><M ref="I"></M><NA ref="AO"></NA><app-note> + In the future, function <xref to="mf-certWipe"></xref> may require destruction or disabling of any default trusted CA certificates, excepting those CA certificates necessary for continued operation of the TSF, such as the developer’s certificate. At this time, the ST author must indicate in the assignment whether pre-installed or any other category of X.509v3 certificates may be removed from the Trust Anchor Database. - </app-note> - <aactivity> - <TSS> + </app-note><aactivity><TSS> The evaluator shall verify that the TSS describes each additional category of X.509 certificates and their use within the TSF. - </TSS> - <Tests> + </TSS><Tests> The evaluator shall remove an administrator-imported certificate and any - other categories of certificates included in the assignment of function <xref - to="mf-appRemove"/> from the Trust Anchor Database according to the AGD + other categories of certificates included in the assignment of function <xref to="mf-appRemove"></xref> from the Trust Anchor Database according to the AGD guidance as the user and as the administrator. - </Tests> - </aactivity> - - </management-function> - <management-function id="mf-enroll"> - <text> - <!-- 13. --> - <!-- <ctr id="enroll" pre="" ctr-type="function">.</ctr>--> enroll the TOE in management </text> - <M ref="I"/><O ref="U"/><O ref="A"/><O ref="AO"/> - <app-note> - For function <xref to="mf-enroll"/>, the + </Tests></aactivity></management-function><management-function id="mf-enroll"><text> enroll the TOE in management </text><M ref="I"></M><O ref="U"></O><O ref="A"></O><O ref="AO"></O><app-note> + For function <xref to="mf-enroll"></xref>, the enrollment function may be installing an MDM agent and includes the policies to be applied to the device. It is acceptable for the user approval notice to require the user to intentionally opt to view the policies (for example, by "tapping" on a "View" icon) rather than listing the policies in full in the notice. - </app-note> - <aactivity> - <TSS>The evaluator shall + </app-note><aactivity><TSS>The evaluator shall examine the TSS to ensure that it contains a description of each management function that will be enforced by the enterprise once the device is enrolled. The evaluator shall examine the AGD guidance to determine that this same information is present. - </TSS> - <Tests> + </TSS><Tests> The evaluator shall verify that user approval is required to enroll the device into management. - </Tests> - </aactivity> - </management-function> - <management-function id="mf-appRemove"> - <text> - <!-- 14. --> - <!-- <ctr id="appRemove" pre="" ctr-type="function">.</ctr>--> remove applications </text> - <M ref="I"/><NA ref="U"/><M ref="A"/> - <aactivity><TSS> + </Tests></aactivity></management-function><management-function id="mf-appRemove"><text> remove applications </text><M ref="I"></M><NA ref="U"></NA><M ref="A"></M><aactivity><TSS> The evaluator shall verify that the TSS includes an indication of what applications (e.g., user-installed applications, Administrator-installed applications, or Enterprise @@ -7994,15 +4229,8 @@ The evaluator shall exercise the TSF configuration as the administrator and </TSS><Tests> The evaluator shall attempt to remove applications according to the AGD guidance and verify that the TOE no longer permits users to access those - applications or their associated data.</Tests></aactivity> - </management-function> - <management-function id="mf-update"> - <text> - <!-- 15 --> - <!-- <ctr id="update" pre="" ctr-type="function">.</ctr>--> update system software </text> - <M ref="I"/><NA ref="U"/><M ref="A"/> - <app-note> - For function <xref to="mf-update"/>, the administrator capability to update the system + applications or their associated data.</Tests></aactivity></management-function><management-function id="mf-update"><text> update system software </text><M ref="I"></M><NA ref="U"></NA><M ref="A"></M><app-note> + For function <xref to="mf-update"></xref>, the administrator capability to update the system software may be limited to causing a prompt to the user to update rather than the ability to initiate the update itself. As the administrator is likely to be acting remotely, he/she would be unaware of inopportune situations, such as low power, which @@ -8010,212 +4238,108 @@ The evaluator shall exercise the TSF configuration as the administrator and to accept the update in such situations. It is expected that system architects will be cognizant of this limitation and will enforce network access controls in order to enforce enterprise-critical updates. - </app-note> - <aactivity><Tests>The evaluator shall attempt to update the TSF system software following the + </app-note><aactivity><Tests>The evaluator shall attempt to update the TSF system software following the procedures in the AGD guidance and verify that updates correctly install and that the version numbers of the system software increase. - </Tests></aactivity> - </management-function> - <management-function id="mf-appInstall"> - <text> - <!-- 16. --> - <!-- <ctr id="appInstall" pre="" ctr-type="function">.</ctr>--> install applications </text> - <M ref="I"/><NA ref="U"/><M ref="A"/> - <app-note> - Function <xref - to="mf-appInstall"/> addresses both installation and update. This protection profile + </Tests></aactivity></management-function><management-function id="mf-appInstall"><text> install applications </text><M ref="I"></M><NA ref="U"></NA><M ref="A"></M><app-note> + Function <xref to="mf-appInstall"></xref> addresses both installation and update. This protection profile does not distinguish between installation and update of applications because mobile devices typically completely overwrite the previous installation with a new installation during an application update. - </app-note> - <aactivity><Tests>The evaluator shall attempt to install an application following the + </app-note><aactivity><Tests>The evaluator shall attempt to install an application following the procedures in the AGD guidance and verify that the application is installed and - available on the TOE.</Tests></aactivity> - </management-function> - <management-function id="mf-entAppRemove"> - <text> - <!-- 17. --> - <!-- <ctr id="entAppRemove" pre="" ctr-type="function">.</ctr>--> remove Enterprise - applications </text> - <M ref="I"/><NA ref="U"/><M ref="A"/><NA ref="AO"/> - <app-note> - For function <xref - to="mf-entAppRemove"/>, "Enterprise applications" are those applications that belong + available on the TOE.</Tests></aactivity></management-function><management-function id="mf-entAppRemove"><text> remove Enterprise + applications </text><M ref="I"></M><NA ref="U"></NA><M ref="A"></M><NA ref="AO"></NA><app-note> + For function <xref to="mf-entAppRemove"></xref>, "Enterprise applications" are those applications that belong to the Enterprise application group. Applications installed by the enterprise administrator (including automatic installation by the administrator after being requested by the user from a catalog of enterprise applications) are by default placed in the Enterprise application group unless an exception has been made in function - <xref to="mf-appGroups"/> of FMT_SMF.1.1. - </app-note> - <aactivity><Tests> + <xref to="mf-appGroups"></xref> of FMT_SMF.1.1. + </app-note><aactivity><Tests> The evaluator shall attempt to remove any Enterprise applications from the device by following the administrator guidance. The evaluator shall verify that the TOE no longer permits users to access those applications or their associated - data.</Tests></aactivity> - </management-function> - <management-function id="mf-notifications"> - <text> - <!-- 18. --> - <!-- <ctr id="notifications" pre="" ctr-type="function">.</ctr>--> enable/disable - display notification in the locked state of: <selectables linebreak="yes"> - <selectable>email notifications</selectable> - <selectable>calendar appointments</selectable> - <selectable>contact associated with phone call notification</selectable> - <selectable>text message notification</selectable> - <selectable><assignable>other application-based notifications</assignable></selectable> - <selectable>all notifications</selectable> - </selectables> - </text> - <M ref="I"/> - <app-note> + data.</Tests></aactivity></management-function><management-function id="mf-notifications"><text> enable/disable + display notification in the locked state of: <selectables linebreak="yes"><selectable>email notifications</selectable><selectable>calendar appointments</selectable><selectable>contact associated with phone call notification</selectable><selectable>text message notification</selectable><selectable><assignable>other application-based notifications</assignable></selectable><selectable>all notifications</selectable></selectables></text><M ref="I"></M><app-note> If the display of notifications in the locked state is supported, the configuration of these - notifications (function <xref to="mf-notifications"/>) must be included in the + notifications (function <xref to="mf-notifications"></xref>) must be included in the selection. - </app-note> - <aactivity><Guidance>The evaluator + </app-note><aactivity><Guidance>The evaluator shall examine the AGD Guidance to determine that it specifies, for at least each - category of information selected for Function <xref to="mf-notifications"/>, + category of information selected for Function <xref to="mf-notifications"></xref>, how to enable and disable display information for that type of information in the locked state. - </Guidance> - <Tests>For each category of information listed in the AGD guidance, the evaluator + </Guidance><Tests>For each category of information listed in the AGD guidance, the evaluator shall verify that when that TSF is configured to limit the information according - to the AGD, the information is no longer displayed in the locked state.</Tests> - </aactivity> - </management-function> - <management-function id="mf-dar"> - <text> - <!-- 20. --> - <!-- <ctr id="dar" pre="" ctr-type="function">.</ctr>--> enable data-at rest protection </text> - <M ref="I"/> - <app-note> - Function <xref to="mf-dar"/> must be included in the + to the AGD, the information is no longer displayed in the locked state.</Tests></aactivity></management-function><management-function id="mf-dar"><text> enable data-at rest protection </text><M ref="I"></M><app-note> + Function <xref to="mf-dar"></xref> must be included in the selection if data-at-rest protection is not natively enabled. - </app-note> - <aactivity><Tests> + </app-note><aactivity><Tests> The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to the administrator, the user, to enable system-wide data-at-rest protection according to the AGD guidance. The evaluator shall ensure that all Evaluation Activities for DAR (FDP_DAR) are conducted with the device in this configuration. - </Tests></aactivity> - </management-function> - - <management-function id="mf-rmediaDar"> - <text> - <!-- 21. --> - <!-- <ctr id="rmediaDar" pre="" ctr-type="function">.</ctr>--> enable removable media’s - data-at-rest protection </text> - <M ref="I"/> - <app-note> - Function <xref to="mf-rmediaDar"/> is implicitly met if the TSF does not support + </Tests></aactivity></management-function><management-function id="mf-rmediaDar"><text> enable removable media’s + data-at-rest protection </text><M ref="I"></M><app-note> + Function <xref to="mf-rmediaDar"></xref> is implicitly met if the TSF does not support removable media. - </app-note> - <aactivity><Tests> + </app-note><aactivity><Tests> The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to the administrator, the user, to enable removable media’s data-at-rest protection according to the AGD guidance. The evaluator shall ensure that all Evaluation Activities for DAR (FDP_DAR) are conducted with the device in this configuration. - </Tests></aactivity> - </management-function> - <management-function id="mf-location"> - <text> - <!-- 21. --> - <!-- <ctr id="location" pre="" ctr-type="function">.</ctr>--> enable/disable location - services: <htm:ul> - <htm:li>Across device</htm:li></htm:ul> - <htm:div class="indent"><selectables linebreak="yes"> - <selectable id="mf-location-per_app">on a per-app basis</selectable> - <selectable>on a per-group of applications processes basis</selectable> - <selectable exclusive="yes">no other method</selectable> - </selectables></htm:div> - </text> - <M ref="I"/> - <app-note> - For function <xref to="mf-location"/>, location + </Tests></aactivity></management-function><management-function id="mf-location"><text> enable/disable location + services: <htm:ul><htm:li>Across device</htm:li></htm:ul><htm:div class="indent"><selectables linebreak="yes"><selectable id="mf-location-per_app">on a per-app basis</selectable><selectable>on a per-group of applications processes basis</selectable><selectable exclusive="yes">no other method</selectable></selectables></htm:div></text><M ref="I"></M><app-note> + For function <xref to="mf-location"></xref>, location services include location information gathered from GPS, cellular, and Wi-Fi. - </app-note> - <aactivity><Tests> - The evaluator shall perform the following tests. <testlist> - <test>The evaluator shall enable location services device-wide and shall + </app-note><aactivity><Tests> + The evaluator shall perform the following tests. <testlist><test>The evaluator shall enable location services device-wide and shall verify that an application (such as a mapping application) is able to access the TOE’s location information. The evaluator shall disable location services device-wide and shall verify that an application (such as a mapping - application) is unable to access the TOE’s location information. </test> - <test>[conditional] If <xref to="mf-location-per_app"/> is selected, the evaluator shall + application) is unable to access the TOE’s location information. </test><test>[conditional] If <xref to="mf-location-per_app"></xref> is selected, the evaluator shall create two applications and enable one to use access the location services and the other to not access the location services. The evaluator shall exercise each application attempting to access location services individually. The evaluator shall verify that the enabled application is able to access the location services and the disabled application is not - able to access the location services. </test> - </testlist></Tests></aactivity> - </management-function> - <management-function id="mf-authFactors"> - <text> - <!-- <ctr id="authFactors" pre="" ctr-type="function">.</ctr>--> enable/disable the use - of <selectables> - <selectable>Biometric Authentication Factor</selectable> - <selectable>Hybrid Authentication Factor</selectable> - </selectables> - </text> - <app-note> - Function <xref to="mf-authFactors"/> must be included in the ST if the TOE contains a BAF. This selection must correspond with the selection made in - FIA_UAU.5.1. If <xref to="uau_biometric"/> is selected in FIA_UAU.5.1, "Biometric Authentication Factor" + able to access the location services. </test></testlist></Tests></aactivity></management-function><management-function id="mf-authFactors"><text> enable/disable the use + of <selectables><selectable>Biometric Authentication Factor</selectable><selectable>Hybrid Authentication Factor</selectable></selectables></text><app-note> + Function <xref to="mf-authFactors"></xref> must be included in the ST if the TOE contains a BAF. This selection must correspond with the selection made in + FIA_UAU.5.1. If <xref to="uau_biometric"></xref> is selected in FIA_UAU.5.1, "Biometric Authentication Factor" must be selected and the user or admin must have the option to disable the use of - it. If multiple BAFs are claimed in FIA_MBV_EXT.1.1 in the <xref to="mod-biometrics"/>, this applies to all different - modalities. If <xref to="uau_hybr"/> is selected in FIA_UAU.5.1 it must be selected and the user + it. If multiple BAFs are claimed in FIA_MBV_EXT.1.1 in the <xref to="mod-biometrics"></xref>, this applies to all different + modalities. If <xref to="uau_hybr"></xref> is selected in FIA_UAU.5.1 it must be selected and the user or admin must have the option to disable the use of it. - </app-note> - <aactivity><Tests> + </app-note><aactivity><Tests> The evaluator shall verify that the TSS states if the TOE supports a BAF or hybrid authentication. If the TOE does not include a BAF or hybrid - authentication this test is implicitly met.<testlist> - <test>[conditional] If <xref to="uau_biometric"/> is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the <xref to="mod-biometrics"/> the evaluator shall verify that the - TSS describes the procedure to enable/disable the BAF.<!--If the TOE includes - multiple BAFs, the evaluator shall verify that the TSS describes how to - enable/disable each BAF, specifically if the different modalities can be - individually enabled/disabled.--> The evaluator shall configure the TOE to + authentication this test is implicitly met.<testlist><test>[conditional] If <xref to="uau_biometric"></xref> is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the <xref to="mod-biometrics"></xref> the evaluator shall verify that the + TSS describes the procedure to enable/disable the BAF. The evaluator shall configure the TOE to allow each supported BAF to authenticate and verify that successful authentication can be achieved using the BAF. The evaluator shall configure the TOE to disable the use of each supported BAF for authentication and - confirm that the BAF cannot be used to authenticate. </test> - <test>[conditional] If <xref to="uau_hybr"/> is selected the evaluator shall verify that + confirm that the BAF cannot be used to authenticate. </test><test>[conditional] If <xref to="uau_hybr"></xref> is selected the evaluator shall verify that the TSS describes the procedure to enable/disable the hybrid (biometric credential and PIN/password) authentication. The evaluator shall configure the TOE to allow hybrid authentication to authenticate and confirm that successful authentication can be achieved using the hybrid authentication. The evaluator shall configure the TOE to disable the use of hybrid authentication and confirm that the hybrid authentication cannot be used to - authenticate. </test> - </testlist> - </Tests></aactivity> - </management-function> - <management-function id="mf-certInvalid"> - <text> - <!-- <ctr id="certInvalid" pre="" ctr-type="function">.</ctr>--> configure whether to + authenticate. </test></testlist></Tests></aactivity></management-function><management-function id="mf-certInvalid"><text> configure whether to allow or disallow establishment of <assignable>configurable trusted channel in FTP_ITC_EXT.1.1 or FDP_UPC_EXT.1.1/APPS</assignable> if the peer or server certificate - is deemed invalid.</text> - <app-note> - <!-- TODO: Should this be something like for TLS do not approve any exceptions, for HTTP this is per FCS_HTTPS_EXT.1.3?? How do I force the selection of no exceptions for all (non-HTTPS) TLS connections? --> - Function <xref to="mf-certInvalid"/> must be included in the ST if the function is configurable on the TOE for any of the trusted channels either mandated or selected in <xref to="fel-wlan"/> or <xref to="fel-tls-app"/>. The configuration can be different depending on the specific trusted channel(s) and they must be filled in for the assignment. - </app-note> - <aactivity><Tests>The test of this function is performed in conjunction with FIA_X509_EXT.2.2, - FCS_TLSC_EXT.1.3 in the <xref to="pkg-tls"/>. </Tests></aactivity> - </management-function> - <!-- Start of the Optional to implement functions --> - <management-function id="mf-externalPorts"> - <text> - <!-- <ctr id="externalPorts" pre="" ctr-type="function">.</ctr>--> enable/disable all + is deemed invalid.</text><app-note> + Function <xref to="mf-certInvalid"></xref> must be included in the ST if the function is configurable on the TOE for any of the trusted channels either mandated or selected in <xref to="fel-wlan"></xref> or <xref to="fel-tls-app"></xref>. The configuration can be different depending on the specific trusted channel(s) and they must be filled in for the assignment. + </app-note><aactivity><Tests>The test of this function is performed in conjunction with FIA_X509_EXT.2.2, + FCS_TLSC_EXT.1.3 in the <xref to="pkg-tls"></xref>. </Tests></aactivity></management-function><management-function id="mf-externalPorts"><text> enable/disable all data signaling over <assignable>list of externally accessible hardware - ports</assignable> - </text> - <app-note> - <!-- Start of the optional to include functions --> The assignment in function - <xref to="mf-externalPorts"/> consists of all externally accessible hardware + ports</assignable></text><app-note> The assignment in function + <xref to="mf-externalPorts"></xref> consists of all externally accessible hardware ports, such as USB, the SD card, and HDMI, whose data transfer capabilities can be enabled and disabled by either the user or administrator. Disablement of data transfer over an external port must be effective during and after boot into the normal @@ -8226,12 +4350,10 @@ The evaluator shall exercise the TSF configuration as the administrator and separately. The configuration policy need not disable all ports together. In the case of USB, charging is still allowed if data transfer capabilities have been disabled. - </app-note> - <aactivity><TSS> + </app-note><aactivity><TSS> The evaluator shall verify that the TSS includes a list of each externally accessible hardware port and an indication of if data transfer over that port can - be enabled/disabled. AGD guidance will describe how to perform the enable/disable function.</TSS> - <Tests>The evaluator shall exercise the TSF configuration to enable and disable + be enabled/disabled. AGD guidance will describe how to perform the enable/disable function.</TSS><Tests>The evaluator shall exercise the TSF configuration to enable and disable data transfer capabilities over each externally accessible hardware ports (e.g. USB, SD card, HDMI) listed by the ST author. The evaluator shall use test equipment for the particular interface to ensure that while the TOE may continue to @@ -8239,83 +4361,45 @@ The evaluator shall exercise the TSF configuration as the administrator and disabled data transfer capability, the evaluator shall repeat this test by rebooting the device into the normal operational mode and verifying that the capability is disabled throughout the boot and early execution stage of the - device.</Tests> - </aactivity> - </management-function> - <management-function id="mf-serverProtocols"> - <text> - <!-- <ctr id="serverProtocols" pre="" ctr-type="function">.</ctr>--> enable/disable - <assignable id="a-server">list of protocols where the device acts as a server</assignable> - </text> - <app-note> - The assignment in function <xref to="mf-serverProtocols"/> + device.</Tests></aactivity></management-function><management-function id="mf-serverProtocols"><text> enable/disable + <assignable id="a-server">list of protocols where the device acts as a server</assignable></text><app-note> + The assignment in function <xref to="mf-serverProtocols"></xref> consists of all protocols where the TSF acts as a server, which can be enabled and disabled by either the user or administrator. - </app-note> - <aactivity><TSS> + </app-note><aactivity><TSS> The evaluator shall verify that the TSS describes how the TSF acts as a server in - each of the protocols listed in the ST, and the reason for acting as a server.</TSS> - <Tests> + each of the protocols listed in the ST, and the reason for acting as a server.</TSS><Tests> The evaluator shall attempt to disable each listed protocol in the assignment. The evaluator shall verify that remote devices can no longer access the TOE or TOE resources using any disabled protocols. - </Tests> - </aactivity> - </management-function> - <management-function id="mf-devModes"> - <text> - <!-- <ctr id="devModes" pre="" ctr-type="function">.</ctr>--> enable/disable developer - modes </text> - <app-note> - Function <xref - to="mf-devModes"/> must be included in the selection if developer modes are + </Tests></aactivity></management-function><management-function id="mf-devModes"><text> enable/disable developer + modes </text><app-note> + Function <xref to="mf-devModes"></xref> must be included in the selection if developer modes are supported by the TSF. - </app-note> - <aactivity><Tests> + </app-note><aactivity><Tests> The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to the administrator, the user, to enable and disable any developer mode. The evaluator shall test that developer mode access is not available when its configuration is disabled. The evaluator shall verify the - developer mode remains disabled during device reboot.</Tests></aactivity> - </management-function> - <management-function id="mf-authBypass"> - <text> - <!-- <ctr id="authBypass" pre="" ctr-type="function">.</ctr>--> enable/disable bypass of - local user authentication </text> - <app-note> - Function <xref to="mf-authBypass"/> must + developer mode remains disabled during device reboot.</Tests></aactivity></management-function><management-function id="mf-authBypass"><text> enable/disable bypass of + local user authentication </text><app-note> + Function <xref to="mf-authBypass"></xref> must be included in the selection if bypass of local user authentication, such as a "Forgot Password", password hint, or remote authentication feature, is supported. - </app-note> - <aactivity><Guidance>The + </app-note><aactivity><Guidance>The evaluator shall examine the AGD guidance to determine that it describes how to enable and disable any "Forgot Password", password hint, or remote authentication (to bypass local authentication mechanisms) capability. - </Guidance> - <Tests>For each mechanism listed in the AGD guidance that provides a "Forgot + </Guidance><Tests>For each mechanism listed in the AGD guidance that provides a "Forgot Password" feature or other means where the local authentication process can be bypassed, the evaluator shall disable the feature and ensure that they are not - able to bypass the local authentication process.</Tests></aactivity> - </management-function> - <management-function id="mf-wipeEntData"> - <text> - <!-- <ctr id="wipeEntData" pre="" ctr-type="function">.</ctr>--> wipe Enterprise data </text> - <NA ref="AO"/> - <aactivity><Tests> + able to bypass the local authentication process.</Tests></aactivity></management-function><management-function id="mf-wipeEntData"><text> wipe Enterprise data </text><NA ref="AO"></NA><aactivity><Tests> The evaluator shall attempt to wipe Enterprise data resident on the device according to the administrator guidance. The evaluator shall verify that the - data is no longer accessible by the user.</Tests></aactivity> - </management-function> - <management-function id="mf-appCert"> - <text> - <!-- <ctr id="appCert" pre="" ctr-type="function">.</ctr>--> approve <selectables> - <selectable>import</selectable> - <selectable>removal</selectable> - </selectables> by applications of X.509v3 certificates in the Trust Anchor - Database </text> - <app-note> - Function <xref to="mf-appCert"/> must be included in the + data is no longer accessible by the user.</Tests></aactivity></management-function><management-function id="mf-appCert"><text> approve <selectables><selectable>import</selectable><selectable>removal</selectable></selectables> by applications of X.509v3 certificates in the Trust Anchor + Database </text><app-note> + Function <xref to="mf-appCert"></xref> must be included in the selection if the TSF allows applications, other than the MDM Agents, to import or remove X.509v3 certificates from the Trust Anchor Database. The MDM Agent is considered the administrator. This function does not apply to applications trusting a @@ -8324,419 +4408,212 @@ The evaluator shall exercise the TSF configuration as the administrator and performed by the TSF for other applications. The user or administrator may be provided the ability to globally allow or deny any application requests in order to meet this requirement. - </app-note> - <aactivity><TSS> + </app-note><aactivity><TSS> The evaluator shall verify that the TSS describes how approval for an application to perform the selected action (import, removal) with respect to certificates in the Trust Anchor Database is accomplished (e.g., a pop-up, policy setting, etc.). - <htm:br/><htm:br/> The evaluator shall also verify that the API documentation - provided according to <xref to="adv"/> includes any security functions + <htm:br></htm:br><htm:br></htm:br> The evaluator shall also verify that the API documentation + provided according to <xref to="adv"></xref> includes any security functions (import, modification, or destruction of the Trust Anchor Database) allowed by applications. - </TSS> - <Tests>The evaluator shall perform one of the following tests: <testlist> - <test>[conditional] If applications may import certificates to the Trust + </TSS><Tests>The evaluator shall perform one of the following tests: <testlist><test>[conditional] If applications may import certificates to the Trust Anchor Database, the evaluator shall write, or the developer shall provide access to, an application that imports a certificate into the Trust Anchor Database. The evaluator shall verify that the TOE requires approval before - allowing the application to import the certificate: <htm:ul> - <htm:li>The evaluator shall deny the approvals to verify that the + allowing the application to import the certificate: <htm:ul><htm:li>The evaluator shall deny the approvals to verify that the application is not able to import the certificate. Failure of import shall be tested by attempting to validate a certificate that chains to the certificate whose import was attempted (as described in the - evaluation activity for FIA_X509_EXT.1). </htm:li> - <htm:li>The evaluator shall repeat the test, allowing the approval to + evaluation activity for FIA_X509_EXT.1). </htm:li><htm:li>The evaluator shall repeat the test, allowing the approval to verify that the application is able to import the certificate and that - validation occurs. </htm:li> - </htm:ul> - </test> - <test>[conditional] If applications may remove certificates in the Trust + validation occurs. </htm:li></htm:ul></test><test>[conditional] If applications may remove certificates in the Trust Anchor Database, the evaluator shall write, or the developer shall provide access to, an application that removes certificates from the Trust Anchor Database. The evaluator shall verify that the TOE requires approval before - allowing the application to remove the certificate: <htm:ul> - <htm:li>The evaluator shall deny the approvals to verify that the + allowing the application to remove the certificate: <htm:ul><htm:li>The evaluator shall deny the approvals to verify that the application is not able to remove the certificate. Failure of removal shall be tested by attempting to validate a certificate that chains to the certificate whose removal was attempted (as described in the - evaluation activity for FIA_X509_EXT.1). </htm:li> - </htm:ul> - </test> - </testlist> The evaluator shall repeat the test, allowing the approval to verify + evaluation activity for FIA_X509_EXT.1). </htm:li></htm:ul></test></testlist> The evaluator shall repeat the test, allowing the approval to verify that the application is able to remove/modify the certificate and that validation no longer occurs. - </Tests> - </aactivity> - </management-function> - <management-function id="mf-certValidity"> - <text> - <!-- <ctr id="certValidity" pre="" ctr-type="function">.</ctr>--> configure whether to + </Tests></aactivity></management-function><management-function id="mf-certValidity"><text> configure whether to allow or disallow establishment of a trusted channel if the TSF cannot establish a - connection to determine the validity of a certificate</text> - <app-note> - Function <xref to="mf-certValidity"/> must be + connection to determine the validity of a certificate</text><app-note> + Function <xref to="mf-certValidity"></xref> must be included in the ST if "administrator-configured option" is selection in FIA_X509_EXT.2.2. - </app-note> - <aactivity><Tests>The test of this function is performed in conjunction with FIA_X509_EXT.2.2.</Tests></aactivity> - </management-function> - <management-function id="mf-cellular"> - <text> - <!-- <ctr id="cellular" pre="" ctr-type="function">.</ctr>--> enable/disable the - cellular protocols used to connect to cellular network base stations </text> - <aactivity><TSS>The + </app-note><aactivity><Tests>The test of this function is performed in conjunction with FIA_X509_EXT.2.2.</Tests></aactivity></management-function><management-function id="mf-cellular"><text> enable/disable the + cellular protocols used to connect to cellular network base stations </text><aactivity><TSS>The evaluator shall ensure that the TSS describes which cellular protocols can be - disabled.</TSS> - <Guidance>The evaluator shall confirm that the AGD guidance describes the + disabled.</TSS><Guidance>The evaluator shall confirm that the AGD guidance describes the procedure for disabling each cellular protocol identified in the TSS. - </Guidance> - <Tests>The evaluator shall attempt to disable each cellular protocol according to + </Guidance><Tests>The evaluator shall attempt to disable each cellular protocol according to the administrator guidance. The evaluator shall attempt to connect the device to a cellular network and, using network analysis tools, verify that the device - does not allow negotiation of the disabled protocols.</Tests></aactivity> - </management-function> - <management-function id="mf-auditLogs"> - <text> - <!-- <ctr id="auditLogs" pre="" ctr-type="function">.</ctr>--> read audit logs kept by - the TSF </text> - <NA ref="AO"/> - <aactivity><Tests>The evaluator shall attempt to read any device audit logs according to the + does not allow negotiation of the disabled protocols.</Tests></aactivity></management-function><management-function id="mf-auditLogs"><text> read audit logs kept by + the TSF </text><NA ref="AO"></NA><aactivity><Tests>The evaluator shall attempt to read any device audit logs according to the administrator guidance and verify that the logs may be read. This test may be - performed in conjunction with the evaluation activity of FAU_GEN.1.</Tests></aactivity> - </management-function> - <management-function id="mf-digSign"> - <text> - <!-- <ctr id="digSign" pre="" ctr-type="function">.</ctr>--> configure <selectables> - <selectable>certificate</selectable> - <selectable>public-key</selectable> - </selectables> used to validate digital signature on applications </text> - <app-note> - Function <xref to="mf-digSign"/> should be + performed in conjunction with the evaluation activity of FAU_GEN.1.</Tests></aactivity></management-function><management-function id="mf-digSign"><text> configure <selectables><selectable>certificate</selectable><selectable>public-key</selectable></selectables> used to validate digital signature on applications </text><app-note> + Function <xref to="mf-digSign"></xref> should be included in the selection if FPT_TUD_EXT.5.1 is included in the ST and the configurable option is selected. - </app-note> - <aactivity><Tests> + </app-note><aactivity><Tests> The test of this function is performed in conjunction with FPT_TUD_EXT.5.1. - </Tests></aactivity> - </management-function> - <management-function id="mf-sharedKeys"> - <text> - <!-- <ctr id="sharedKeys" pre="" ctr-type="function">.</ctr>--> approve exceptions for - shared use of keys or secrets by multiple applications </text> - <app-note> - Function <xref - to="mf-sharedKeys"/> should be included in the selection if user or administrator is + </Tests></aactivity></management-function><management-function id="mf-sharedKeys"><text> approve exceptions for + shared use of keys or secrets by multiple applications </text><app-note> + Function <xref to="mf-sharedKeys"></xref> should be included in the selection if user or administrator is selected in FCS_STG_EXT.1.4. - </app-note> - <aactivity><TSS>The + </app-note><aactivity><TSS>The evaluator shall verify that the TSS describes how the approval for exceptions for shared use of keys or secrets by multiple applications is accomplished (e.g., a pop-up, policy setting, etc.).</TSS><Tests> The test of this function is performed in conjunction with FCS_STG_EXT.1. - </Tests></aactivity> - </management-function> - <management-function id="mf-keyWipeRules"> - <text> - <!-- <ctr id="keyWipeRules" pre="" ctr-type="function">.</ctr>--> approve exceptions for + </Tests></aactivity></management-function><management-function id="mf-keyWipeRules"><text> approve exceptions for destruction of keys or secrets by applications that did not import the key or secret - </text> - <app-note> - Function <xref to="mf-keyWipeRules"/> should be included in the selection if - <xref to="s-killkey-user"/> or <xref to="s-killkey-admin"/> + </text><app-note> + Function <xref to="mf-keyWipeRules"></xref> should be included in the selection if + <xref to="s-killkey-user"></xref> or <xref to="s-killkey-admin"></xref> is selected in FCS_STG_EXT.1.5. - <rule id="r-killkey-user-mf"> - <if><ref-id>s-killkey-user</ref-id></if> - <then><ref-id>mf-keyWipeRules</ref-id></then> - </rule> - <rule id="r-killkey-admin-mf"> - <if><ref-id>s-killkey-admin</ref-id></if> - <then><ref-id>mf-keyWipeRules</ref-id></then> - </rule> - </app-note> - <aactivity><TSS>The + <rule id="r-killkey-user-mf"><if><ref-id>s-killkey-user</ref-id></if><then><ref-id>mf-keyWipeRules</ref-id></then></rule><rule id="r-killkey-admin-mf"><if><ref-id>s-killkey-admin</ref-id></if><then><ref-id>mf-keyWipeRules</ref-id></then></rule></app-note><aactivity><TSS>The evaluator shall verify that the TSS describes how the approval for exceptions for destruction of keys or secrets by applications that did not import the key or secret is accomplished (e.g., a pop-up, policy setting, etc.). </TSS><Tests> The test of this function is performed in conjunction with FCS_STG_EXT.1. - </Tests> - </aactivity> - </management-function> - <management-function id="mf-unlockBanner"> - <text> - <!-- <ctr id="unlockBanner" pre="" ctr-type="function">.</ctr>--> configure the unlock - banner </text> - <M ref="I"/> <NA ref="U"/> - <app-note> - <!-- ToDo Removed because FTA_TAB is now mandatory: Function <xref to="mf-unlockBanner"/> must be - included in the selection if FTA_TAB.1 is included in the ST. !--> - </app-note> - <aactivity><TSS> + </Tests></aactivity></management-function><management-function id="mf-unlockBanner"><text> configure the unlock + banner </text><M ref="I"></M><NA ref="U"></NA><app-note></app-note><aactivity><TSS> The evaluator shall verify that the TSS describes any restrictions in banner settings (e.g., character limitations). </TSS><Tests> The test of this function is performed in conjunction with FTA_TAB.1. - </Tests></aactivity> - </management-function> - <management-function id="mf-auditItems"> - <text> - <!-- <ctr id="auditItems" pre="" ctr-type="function">.</ctr>--> configure the auditable - items </text> - <NA ref="U"/> - <app-note> - Function <xref to="mf-auditItems"/> must be included in the selection if FAU_SEL.1 + </Tests></aactivity></management-function><management-function id="mf-auditItems"><text> configure the auditable + items </text><NA ref="U"></NA><app-note> + Function <xref to="mf-auditItems"></xref> must be included in the selection if FAU_SEL.1 is included in the ST. - </app-note> - <aactivity><Tests>The test of this function is performed in conjunction with FAU_SEL.1.</Tests></aactivity> - </management-function> - <management-function id="mf-integ"> - <text> - <!-- <ctr id="integ" pre="" ctr-type="function">.</ctr>--> retrieve TSF-software - integrity verification values </text> - <aactivity><Tests>The test of this function is performed in conjunction with FPT_NOT_EXT.2.1.</Tests></aactivity> - </management-function> - <management-function id="mf-USB"> - <text> - <!-- <ctr id="USB" pre="" ctr-type="function">.</ctr>--> enable/disable <selectables - linebreak="yes"> - <selectable id="s-usbstore">USB mass storage mode</selectable> - <selectable>USB data transfer without user authentication</selectable> - <selectable>USB data transfer without authentication of the connecting - system</selectable> - </selectables> - </text> - <aactivity><TSS>The + </app-note><aactivity><Tests>The test of this function is performed in conjunction with FAU_SEL.1.</Tests></aactivity></management-function><management-function id="mf-integ"><text> retrieve TSF-software + integrity verification values </text><aactivity><Tests>The test of this function is performed in conjunction with FPT_NOT_EXT.2.1.</Tests></aactivity></management-function><management-function id="mf-USB"><text> enable/disable <selectables linebreak="yes"><selectable id="s-usbstore">USB mass storage mode</selectable><selectable>USB data transfer without user authentication</selectable><selectable>USB data transfer without authentication of the connecting + system</selectable></selectables></text><aactivity><TSS>The evaluator shall verify that the TSS includes a description of how data transfers - can be managed over USB.</TSS> - <Tests>The evaluator shall perform the following tests based on the selections made - in the table: <testlist> - <test>[conditional] The evaluator shall disable USB mass storage mode, + can be managed over USB.</TSS><Tests>The evaluator shall perform the following tests based on the selections made + in the table: <testlist><test>[conditional] The evaluator shall disable USB mass storage mode, attach the device to a computer, and verify that the computer cannot mount the TOE as a drive. The evaluator shall reboot the TOE and repeat this test - with other supported auxiliary boot modes. </test> - <test>[conditional] The evaluator shall disable USB data transfer without + with other supported auxiliary boot modes. </test><test>[conditional] The evaluator shall disable USB data transfer without user authentication, attach the device to a computer, and verify that the TOE requires user authentication before the computer can access TOE data. The evaluator shall reboot the TOE and repeat this test with other supported - auxiliary boot modes. </test> - <test>[conditional] The evaluator shall disable USB data transfer without + auxiliary boot modes. </test><test>[conditional] The evaluator shall disable USB data transfer without connecting system authentication, attach the device to a computer, and verify that the TOE requires connecting system authentication before the computer can access TOE data. The evaluator shall then connect the TOE to another computer and verify that the computer cannot access TOE data. The evaluator shall then connect the TOE to the original computer and verify - that the computer can access TOE data. </test> - </testlist></Tests> - </aactivity> - </management-function> - <management-function id="mf-backup"> - <text> - <!-- <ctr id="backup" pre="" ctr-type="function">.</ctr>--> enable/disable backup of <selectables> - <selectable id="s-backup-all-apps">all applications</selectable> - <selectable id="s-backup-sel-apps">selected applications</selectable> - <selectable id="s-backup-sel-grps">selected groups of applications</selectable> - <selectable id="s-backup-cfg">configuration data</selectable> - </selectables> to <selectables> - <selectable>locally connected system</selectable> - <selectable>remote system</selectable> - </selectables> - </text> - <aactivity><TSS>The + that the computer can access TOE data. </test></testlist></Tests></aactivity></management-function><management-function id="mf-backup"><text> enable/disable backup of <selectables><selectable id="s-backup-all-apps">all applications</selectable><selectable id="s-backup-sel-apps">selected applications</selectable><selectable id="s-backup-sel-grps">selected groups of applications</selectable><selectable id="s-backup-cfg">configuration data</selectable></selectables> to <selectables><selectable>locally connected system</selectable><selectable>remote system</selectable></selectables></text><aactivity><TSS>The evaluator shall verify that the TSS includes a description of available backup methods that can be enabled/disabled. If "selected applications" or "selected groups of applications" are selected the TSS shall include which applications of groups of - applications backup can be enabled/disabled.</TSS> - - <Tests> If <xref to="s-backup-all-apps"/> is selected, the evaluator shall disable each selected + applications backup can be enabled/disabled.</TSS><Tests> If <xref to="s-backup-all-apps"></xref> is selected, the evaluator shall disable each selected backup location in turn and verify that the TOE cannot complete a backup. The evaluator shall then enable each selected backup location in turn and verify - that the TOE can perform a backup. <htm:br/><htm:br/> + that the TOE can perform a backup. <htm:br></htm:br><htm:br></htm:br> - If <xref to="s-backup-sel-apps"/> is selected, + If <xref to="s-backup-sel-apps"></xref> is selected, the evaluator shall disable each selected backup location in turn and verify that for the selected application the TOE prevents backup from occurring. The evaluator shall then enable each selected backup location in turn and verify that for the selected application the TOE can perform a backup. - <htm:br/><htm:br/> + <htm:br></htm:br><htm:br></htm:br> - If <xref to="s-backup-sel-grps"/> is selected, the + If <xref to="s-backup-sel-grps"></xref> is selected, the evaluator shall disable each selected backup location in turn and verify that for a group of applications the TOE prevents the backup from occurring. The evaluator shall then enable each selected backup location in turn and verify for - the group of application the TOE can perform a backup. <htm:br/><htm:br/> + the group of application the TOE can perform a backup. <htm:br></htm:br><htm:br></htm:br> - If <xref to="s-backup-cfg"/> is selected, the evaluator shall disable each selected + If <xref to="s-backup-cfg"></xref> is selected, the evaluator shall disable each selected backup location in turn and verify that the TOE prevents the backup of configuration data from occurring. The evaluator shall then enable each selected backup location in turn and verify that the TOE can perform a backup of configuration data. - </Tests></aactivity> - </management-function> - <management-function id="mf-hotspot"> - <text> - <!-- <ctr id="hotspot" pre="" ctr-type="function">.</ctr>--> enable/disable <selectables - linebreak="yes"> - <selectable>Hotspot functionality authenticated by <selectables> - <selectable>pre-shared key</selectable> - <selectable>passcode</selectable> - <selectable exclusive="yes">no authentication</selectable> - </selectables></selectable> - <selectable id="s-tether"><snip>USB tethering</snip> authenticated by <selectables> - <selectable>pre-shared key</selectable> - <selectable>passcode</selectable> - <selectable exclusive="yes">no authentication</selectable> - </selectables> - </selectable> - </selectables> - </text> - <app-note> - For function <xref to="mf-hotspot"/>, + </Tests></aactivity></management-function><management-function id="mf-hotspot"><text> enable/disable <selectables linebreak="yes"><selectable>Hotspot functionality authenticated by <selectables><selectable>pre-shared key</selectable><selectable>passcode</selectable><selectable exclusive="yes">no authentication</selectable></selectables></selectable><selectable id="s-tether"><snip>USB tethering</snip> authenticated by <selectables><selectable>pre-shared key</selectable><selectable>passcode</selectable><selectable exclusive="yes">no authentication</selectable></selectables></selectable></selectables></text><app-note> + For function <xref to="mf-hotspot"></xref>, hotspot functionality refers to the condition in which the mobile device is serving as an access point to other devices, not the connection of the TOE to external hotspots. - </app-note> - <aactivity><TSS> The + </app-note><aactivity><TSS> The evaluator shall verify that the TSS includes a description of Hotspot - functionality and USB tethering to include any authentication for these.</TSS> - <Tests>The evaluator shall perform the following tests based on the selections in - Function <xref to="mf-hotspot"/>. <testlist> - <test>[conditional] The evaluator shall enable hotspot functionality with + functionality and USB tethering to include any authentication for these.</TSS><Tests>The evaluator shall perform the following tests based on the selections in + Function <xref to="mf-hotspot"></xref>. <testlist><test>[conditional] The evaluator shall enable hotspot functionality with each of the of the support authentication methods. The evaluator shall connect to the hotspot with another device and verify that the hotspot - functionality requires the configured authentication method. </test> - <test>[conditional] The evaluator shall enable USB tethering functionality + functionality requires the configured authentication method. </test><test>[conditional] The evaluator shall enable USB tethering functionality with each of the of the support authentication methods. The evaluator shall connect to the TOE over USB with another device and verify that the tethering functionality requires the configured authentication method. - </test> - </testlist></Tests></aactivity> - </management-function> - <management-function id="mf-dataSharing"> - <text> - <!-- <ctr id="dataSharing" pre="" ctr-type="function">.</ctr>--> approve exceptions for - sharing data between <selectables> - <selectable>applications</selectable> - <selectable>groups of applications</selectable> - </selectables></text> - <app-note> - Functions <xref to="mf-dataSharing"/> and <xref - to="mf-appGroups"/> correspond to FDP_ACF_EXT.1.2. - </app-note> - <aactivity><Tests>The test of this function is performed in conjunction with FDP_ACF_EXT.1.2.</Tests></aactivity> - </management-function> - <management-function id="mf-appGroups"> - <text> - <!-- <ctr id="appGroups" pre="" ctr-type="function">.</ctr>--> place applications into + </test></testlist></Tests></aactivity></management-function><management-function id="mf-dataSharing"><text> approve exceptions for + sharing data between <selectables><selectable>applications</selectable><selectable>groups of applications</selectable></selectables></text><app-note> + Functions <xref to="mf-dataSharing"></xref> and <xref to="mf-appGroups"></xref> correspond to FDP_ACF_EXT.1.2. + </app-note><aactivity><Tests>The test of this function is performed in conjunction with FDP_ACF_EXT.1.2.</Tests></aactivity></management-function><management-function id="mf-appGroups"><text> place applications into application groups based on <assignable>enterprise configuration - settings</assignable></text> - <aactivity><Tests> + settings</assignable></text><aactivity><Tests> The evaluator shall set a policy to cause a designated application to be placed into a particular application group. The evaluator shall then install the designated application and verify that it was placed into the correct group. - </Tests></aactivity> - </management-function> - <management-function id="mf-unenroll"> - <text> - <!-- <ctr id="unenroll" pre="" ctr-type="function">.</ctr>--> unenroll the TOE from - management </text> - <app-note> + </Tests></aactivity></management-function><management-function id="mf-unenroll"><text> unenroll the TOE from + management </text><app-note> For function - <xref to="mf-unenroll"/>, FMT_SMF_EXT.2.1 specifies actions to be performed when + <xref to="mf-unenroll"></xref>, FMT_SMF_EXT.2.1 specifies actions to be performed when the TOE is unenrolled from management. - </app-note> - <aactivity><Tests>The evaluator shall attempt to unenroll the device from management and + </app-note><aactivity><Tests>The evaluator shall attempt to unenroll the device from management and verify that the steps described in FMT_SMF_EXT.2.1 are performed. This test should be performed in conjunction with the FMT_SMF_EXT.2.1 evaluation activity. - </Tests></aactivity> - </management-function> - <management-function id="mf-alwaysOnVPN"> - <text> - <!-- <ctr id="alwaysOnVPN" pre="" ctr-type="function">.</ctr>--> enable/disable the + </Tests></aactivity></management-function><management-function id="mf-alwaysOnVPN"><text> enable/disable the Always On VPN protection: - <htm:ul> - <htm:li>Across device</htm:li></htm:ul> - <htm:div class="indent"><selectables linebreak="yes"> - <selectable>on a per-app basis</selectable> - <selectable>on a per-group of applications processes basis</selectable> - <selectable exclusive="yes">no other method</selectable> - </selectables></htm:div> - </text> - <app-note> - Function <_/> must be included in the ST if IPsec is selected in + <htm:ul><htm:li>Across device</htm:li></htm:ul><htm:div class="indent"><selectables linebreak="yes"><selectable>on a per-app basis</selectable><selectable>on a per-group of applications processes basis</selectable><selectable exclusive="yes">no other method</selectable></selectables></htm:div></text><app-note> + Function <_></_> must be included in the ST if IPsec is selected in FTP_ITC_EXT.1 and the native IPsec VPN client can be configured to be Always-On. Always-On is defined as when the TOE has a network connection the VPN attempts to connect, all data leaving the device uses the VPN when the VPN is connected and no data leaves that device when the VPN is disconnected. The configuration of the VPN Client itself (with information such as VPN Gateway, certificates, and algorithms) is - addressed by the <xref to="mod-vpnclient"/>. - </app-note> - <aactivity><TSS>The evaluator shall verify that the TSS contains guidance to configure the + addressed by the <xref to="mod-vpnclient"></xref>. + </app-note><aactivity><TSS>The evaluator shall verify that the TSS contains guidance to configure the VPN as Always-On. </TSS><Tests>The evaluator shall configure the VPN as Always-On and perform the following tests: - <testlist> - <test>The evaluator shall verify that when the VPN is connected all traffic + <testlist><test>The evaluator shall verify that when the VPN is connected all traffic is routed through the VPN. This test is performed in conjunction with - FDP_IFC_EXT.1.1. </test> - <test>The evaluator shall verify that when the VPN is not established, that + FDP_IFC_EXT.1.1. </test><test>The evaluator shall verify that when the VPN is not established, that no traffic leaves the device. The evaluator shall ensure that the TOE has network connectivity and that the VPN is established. The evaluator shall use a packet sniffing tool to capture the traffic leaving the TOE. The evaluator shall disable the VPN connection on the server side. The evaluator shall perform actions with the device such as navigating to websites, using provided applications, and accessing other Internet resources and verify - that no traffic leaves the device. </test> - <test>The evaluator shall verify that the TOE has network connectivity and + that no traffic leaves the device. </test><test>The evaluator shall verify that the TOE has network connectivity and that the VPN is established. The evaluator shall disable network connectivity (i.e. Airplane Mode) and verify that the VPN disconnects. The evaluator shall re-establish network connectivity and verify that the VPN - automatically reconnects. </test> - </testlist> - </Tests></aactivity> - </management-function> - <management-function id="mf-bioRevoke"> - <text> - <!-- <ctr id="bioRevoke" pre="" ctr-type="function">.</ctr>--> revoke Biometric - template</text> - <aactivity><TSS>The evaluator shall verify that the TSS describes the procedure to revoke a + automatically reconnects. </test></testlist></Tests></aactivity></management-function><management-function id="mf-bioRevoke"><text> revoke Biometric + template</text><aactivity><TSS>The evaluator shall verify that the TSS describes the procedure to revoke a biometric credential stored on the TOE. </TSS><Tests>The evaluator shall configure the TOE to use BAF and confirm that the biometric can be used to authenticate to the device. The evaluator shall revoke the biometric credential’s ability to authenticate to the TOE and confirm that the same BAF cannot be used to authenticate to the device. - </Tests></aactivity> - </management-function> - <management-function id="mf-other"> - <text> - <!-- <ctr id="other" pre="" ctr-type="function">.</ctr>--> - <assignable>list of other management functions to be provided by the - TSF</assignable></text> - <aactivity><TSS> The evaluator shall + </Tests></aactivity></management-function><management-function id="mf-other"><text><assignable>list of other management functions to be provided by the + TSF</assignable></text><aactivity><TSS> The evaluator shall verify that the TSS describes all assigned security management functions and their intended behavior. - </TSS> - <Tests>The evaluator shall design and perform tests to demonstrate that the + </TSS><Tests>The evaluator shall design and perform tests to demonstrate that the function may be configured and that the intended behavior of the function is enacted by the TOE. - </Tests></aactivity> - </management-function> - </management-function-set> - - - - The TSF shall be capable of performing <assignable>list of management functions</assignable>. - - - - compares the management functions required by this + The TSF shall be capable of performing the following management functions: : Management Functions Status Markers: M - Mandatory O - Optional/Objective + compares the management functions required by this Protection Profile. The first column lists the management functions - identified in the PP. In the following columns: - ‘M’ means Mandatory - ‘O’ means Optional/Objective - '-' means that no value (M or O) can be assigned - - The third column ("Impl.") indicates whether the function is + identified in the PP. In the following columns: ‘M’ means Mandatory‘O’ means Optional/Objective'-' means that no value (M or O) can be assigned The third column ("Impl.") indicates whether the function is to be implemented. The ST author should select which Optional functions are implemented. The fourth column ("User Only") indicates functions that are to be restricted to the user (i.e. not available to the administrator). @@ -8760,609 +4637,48 @@ The evaluator shall exercise the TSF configuration as the administrator and implemented in order for the function to be included. For functions with a "per-app basis" sub function and an assignment, the ST author must indicate which assigned features are manageable on a per-app basis and which are not by iterating the row. - - - - - - - - - - - - - - - - - - - - - - The evaluator shall verify that the TSS describes all management functions, what - roles can perform each function, and how these functions are (or can be) - restricted to the roles identified by FMT_MOF_EXT.1. The - following activities are organized according to the function number in the table. - These activities include TSS Evaluation Activities, AGD Evaluation Activities, and - test activities. Test activities specified below shall take place - in the test environment described in the evaluation activity for FPT_TUD_EXT.1. - The evaluator shall consult the AGD guidance to perform each of the - specified tests, iterating each test as necessary if both the user and administrator - may perform the function. The evaluator shall verify that the AGD guidance describes - how to perform each management function, including any configuration details. For - each specified management function tested, the evaluator shall confirm that the - underlying mechanism exhibits the configured setting. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + The evaluator shall verify + the TSS defines the allowable policy options: the range of values for both + password length and lifetime, and a description of complexity to include character + set and complexity policies (e.g., configuration and enforcement of number of + uppercase, lowercase, and special characters per password). + +The evaluator shall exercise the TSF configuration as the administrator and + perform positive and negative tests, with at least two values set for each + variable setting, for each of the following: Minimum password lengthMinimum password complexityMaximum password lifetime - - Initiation of policy update - Policy name - - - Change of settings - Role of user that changed setting, Value of new setting - - - Success or failure of function - Role of user that performed function, Function performed, Reason for failure - - - Initiation of software update - Version of update - - - Initiation of application installation or update - Name and version of application - + + Initiation of policy update + Policy name + + + Change of settings + Role of user that changed setting, Value of new setting + + + Success or failure of function + Role of user that performed function, Function performed, Reason for failure + + + Initiation of software update + Version of update + + + Initiation of application installation or update + Name and version of application + - - + + requires the TSF to automatically perform specific management functions in response to a specific event. - The following actions could be considered for the management functions in FMT: - Configuration of the functions that are performed in response to unenrollment event. - - - The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - Initiation of unenrollment. - Completion of unenrollment. - - + The following actions could be considered for the management functions in FMT: Configuration of the functions that are performed in response to unenrollment event. + The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Initiation of unenrollment.Completion of unenrollment. No dependencies. - - - The TSF shall offer <selectables> - <selectable id="s-smf-wipe-pro">wipe of protected data</selectable> - <selectable id="s-smf-wipe-sen">wipe of sensitive data</selectable> - <selectable id="s-smf-ext-2-rem-ent-app">remove Enterprise applications</selectable> - <selectable>remove all device-stored Enterprise resource data</selectable> - <selectable>remove Enterprise secondary authentication data</selectable> - <selectable><assignable>list other available remediation - actions</assignable></selectable> - </selectables> upon unenrollment and <selectables> - <selectable><assignable>other administrator-configured - triggers</assignable></selectable> - <selectable exclusive="yes"> no other triggers</selectable> - </selectables>. - - The TSF shall offer <assignable>list of remediation actions</assignable> - upon unenrollment and - <assignable>list of triggers</assignable>. + The TSF shall offer<selectables><selectable id="s-smf-wipe-pro" >wipe of protected data</selectable><selectable id="s-smf-wipe-sen" >wipe of sensitive data</selectable><selectable id="s-smf-ext-2-rem-ent-app" >remove Enterprise applications</selectable><selectable id="fmt_smf_ext.2.1_1" >remove all device-stored Enterprise resource data</selectable><selectable id="fmt_smf_ext.2.1_2" >remove Enterprise secondary authentication data</selectable><selectable id="fmt_smf_ext.2.1_4" ><assignable>list other available remediation actions </assignable></selectable></selectables>upon unenrollment and<selectables><selectable id="fmt_smf_ext.2.1_6" ><assignable>other administrator-configured triggers </assignable></selectable><selectable id="fmt_smf_ext.2.1_7" exclusive="yes" > no other triggers</selectable></selectables>. Unenrollment may consist of removing the MDM agent or removing the administrator’s policies. The functions in the selection are remediation actions that TOE may provide (perhaps via APIs) to the administrator (perhaps via an MDM @@ -9384,14 +4700,14 @@ The evaluator shall exercise the TSF configuration as the administrator and Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well. - If is selected it is assumed that the sensitive data is wiped as well. - However, if is selected, it does not imply that all non-TSF data (protected data) + If is selected it is assumed that the sensitive data is wiped as well. + However, if is selected, it does not imply that all non-TSF data (protected data) is wiped. - If or is selected the wipe must be in accordance with FCS_CKM_EXT.5.1. + If or is selected the wipe must be in accordance with FCS_CKM_EXT.5.1. Thus cryptographically wiping the device is an acceptable remediation action. - - The evaluator shall verify that the TSS describes all available remediation + + The evaluator shall verify that the TSS describes all available remediation actions, when they are available for use, and any other administrator-configured triggers. The evaluator shall verify that the TSS describes how the remediation actions are provided to the administrator. @@ -9403,24 +4719,20 @@ The evaluator shall exercise the TSF configuration as the administrator and be an application with administrator access. - - Unenrollment, Initiation of unenrollment - Identity of administrator Remediation action performed, failure of accepting command to unenroll - + + Unenrollment, Initiation of unenrollment + Identity of administrator Remediation action performed, failure of accepting command to unenroll + - - + + requires the TSF to provide users with a list of administrators and their specified functions. There are no management activities foreseen. There are no auditable events foreseen. FMT_SMR.1 Security Roles - - - The TSF shall provide a mechanism that allows users to view a list of currently - authorized administrators and the management functions that each administrator is - authorized to perform. - + The TSF shall provide a mechanism that allows users to view a list of currently authorized administrators and the management functions that each administrator is authorized to perform. + There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. The evaluator shall cause the TOE to be enrolled into management. The @@ -9429,44 +4741,30 @@ The evaluator shall exercise the TSF configuration as the administrator and is authorized to perform. - + - - - - - This family defines requirements for protecting against common types of software exploitation techniques. - - - - - - +
    + +
    + + requires the TSF to support address space layout randomization (ASLR). There are no management activities foreseen. There are no auditable events foreseen. FCS_RBG_EXT.1 Random Bit Generation - - - The TSF shall provide address space layout randomization ASLR to applications. - + The TSF shall provide address space layout randomization ASLR to applications. - The base address of any user-space memory mapping will consist of at least 8 - unpredictable bits. + The base address of any user-space memory mapping will consist of at least 8 unpredictable bits. The 8 unpredictable bits may be provided by the TSF RBG (as specified in FCS_RBG_EXT.1) but is not required. - + The evaluator shall ensure that the TSS section of the ST describes how the 8 bits are generated and provides a justification as to why those bits are - unpredictable. - - There are no guidance evaluation activities for this component. + unpredictable. + There are no guidance evaluation activities for this component. - Evaluation Activity Note: The following test require the developer to - provide access to a test platform that provides the evaluator with tools that are - typically not found on consumer Mobile Device products. The evaluator must select 3 apps included with the TSF. These must include any web browser or mail client included with the TSF. For each of these apps, @@ -9481,45 +4779,39 @@ The evaluator shall exercise the TSF configuration as the administrator and - + - - + + requires the TSF to enforce access permissions on physical memory. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. - - - The TSF shall be able to enforce read, write, and execute permissions on every - page of physical memory. - + The TSF shall be able to enforce read, write, and execute permissions on every page of physical memory. + The evaluator shall ensure that the TSS describes of the memory management unit (MMU), and ensures that this description documents the ability of the MMU to enforce read, write, and execute permissions on all pages of virtual memory. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component. - - + + - - + + requires the TSF to implement stack overflow protection. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. - - - TSF processes that execute in a non-privileged execution domain on the - application processor shall implement stack-based buffer overflow protection. + TSF processes that execute in a non-privileged execution domain on the application processor shall implement stack-based buffer overflow protection. A "non-privileged execution domain" refers to the user mode (as opposed to kernel mode, for instance) of the processor. While not all TSF processes must implement such protection, it is expected that most of the processes (to include libraries used by TSF processes) do implement buffer overflow protections. - + The evaluator shall determine that the TSS contains a description of stack-based buffer overflow protections implemented in the TSF software which runs in the non-privileged execution mode of the application processor. The exact implementation @@ -9534,21 +4826,19 @@ The evaluator shall exercise the TSF configuration as the administrator and There are no test evaluation activities for this component. - + - - + + requires the TSF to protect itself from untrusted subjects and enforce address space isolation. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. - - - The TSF shall protect itself from modification by untrusted subjects. + The TSF shall protect itself from modification by untrusted subjects. - The TSF shall enforce isolation of address space between applications. + The TSF shall enforce isolation of address space between applications. In addition to the TSF software (e.g., kernel image, device drivers, trusted applications) that resides in storage, the execution context (e.g., address space, processor registers, per-process environment variables) of the software @@ -9564,8 +4854,8 @@ The evaluator shall exercise the TSF configuration as the administrator and unauthorized users or untrusted software or hardware which may have access to the device over a wired interface, either when the device is in a screen-locked state or booted into auxiliary boot modes. - - The evaluator shall ensure that the TSS describes the mechanisms that are in + + The evaluator shall ensure that the TSS describes the mechanisms that are in place that prevents non-TSF software from modifying the TSF software or TSF data that governs the behavior of the TSF. These mechanisms could range from hardware-based means (e.g. "execution rings" and memory management functionality); @@ -9596,17 +4886,9 @@ The evaluator shall exercise the TSF configuration as the administrator and tools is not sufficient justification. Examples of sufficient justification include auditing of changes, cryptographic verification in the form of a digital signature or hash, disabling the auxiliary boot modes, and access control mechanisms that - prevent writing to files or flashing partitions. - + prevent writing to files or flashing partitions. There are no guidance evaluation activities for this component. - Evaluation Activity Note: The following tests require the vendor to - provide access to a test platform that provides the evaluator with tools that are - typically not found on consumer Mobile Device products. In addition, the vendor - provides a list of files (e.g., system files, libraries, configuration files, audit - logs) that make up the TSF data. This list could be organized by folders/directories - (e.g., /usr/sbin, /etc), as well as individual files that may exist outside of the - identified directories. The evaluator shall create and load an app onto the Mobile Device. This app shall attempt to traverse over all file systems and report any locations to @@ -9615,7 +4897,7 @@ The evaluator shall exercise the TSF configuration as the administrator and configuration files, key material, or another untrusted application’s image/data. For example, it is acceptable for a trusted photo editor app to have access to the data created by the camera app, but a calculator application shall - not have access to the pictures. + not have access to the pictures. For each available auxiliary boot mode, the evaluator shall attempt to modify a TSF file of their choosing using the software or hardware tools described in the TSS. The evaluator shall verify that the modification @@ -9624,38 +4906,31 @@ The evaluator shall exercise the TSF configuration as the administrator and - + - - + + requires the TSF to provide ASLR to the kernel. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. - - - The TSF shall provide address space layout randomization (ASLR) to the kernel. - + The TSF shall provide address space layout randomization (ASLR) to the kernel. - - The base address of any kernel-space memory mapping will consist of - <assignable>number greater than or equal to 4</assignable> - unpredictable bits. - + The base address of any kernel-space memory mapping will consist of<assignable>number greater than or equal to 4</assignable>unpredictable bits. The unpredictable bits may be provided by the TSF RBG (as specified in FCS_RBG_EXT.1). - + The evaluator shall ensure that the TSS section of the ST describes how the bits are generated and provides a justification as to why those bits are - unpredictable. - + unpredictable. There are no guidance evaluation activities for this component. - Evaluation Activity Note: The following test require the developer to + + The following test require the developer to provide access to a test platform that provides the evaluator with tools that are - typically not found on consumer Mobile Device products. + typically not found on consumer Mobile Device products. The evaluator shall reboot the TOE six times. For each of these reboots, the evaluator shall examine memory mapping locations of the kernel. The evaluator must ensure that for at least five reboots the memory mappings are not placed in the same location on @@ -9664,29 +4939,22 @@ The evaluator shall exercise the TSF configuration as the administrator and - + - - + + requires the TSF to prevent physical memory from being both writable and executable. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. - - - The TSF shall prevent write and execute permissions from being simultaneously - granted to any page of physical memory <selectables> - <selectable>with no exceptions</selectable> - <selectable> - <assignable>specific exceptions</assignable></selectable> - </selectables>. + The TSF shall prevent write and execute permissions from being simultaneously granted to any page of physical memory<selectables><selectable id="fpt_aex_ext.6.1_1" >with no exceptions</selectable><selectable id="fpt_aex_ext.6.1_3" ><assignable>specific exceptions </assignable></selectable></selectables>. Memory used for just-in-time (JIT) compilation is anticipated as an exception in this requirement; if so, the ST author must address how this exception is permitted. It is expected that the memory management unit will transition the system to a non-operational state if any violation is detected in kernel memory space. - + The evaluator shall ensure that the TSS describes how the operating system of the application processor prevents all processes executing in a non-privileged execution domain from achieving write and execute permissions on any page of memory (with only @@ -9698,26 +4966,22 @@ The evaluator shall exercise the TSF configuration as the administrator and There are no test evaluation activities for this component. - + - - + + requires the TSF to support heap-based buffer overflow protection. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. - - - The TSF shall include heap-based buffer overflow protections in the runtime - environment it provides to processes that execute on the application - processor. + The TSF shall include heap-based buffer overflow protections in the runtime environment it provides to processes that execute on the application processor. These heap-based buffer overflow protections are expected to ensure the integrity of heap metadata such as memory addresses or offsets recorded by the heap implementation to manage memory blocks. This includes chunk headers, look-aside lists, and other data structures used to track the state and location of memory blocks managed by the heap. - + The evaluator shall verify that the TSS enumerates the heap implementations provided to userspace processes. The evaluator shall ensure that the TSS lists all types of heap metadata and identifies how the integrity of each type of metadata is @@ -9734,52 +4998,32 @@ The evaluator shall exercise the TSF configuration as the administrator and allowed. - + - - - This family defines requirements for separation of baseband and application processor execution. - - - - - - + + requires the TSF to enforce separation between baseband and application processor execution except through application processor mechanisms. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. - - The TSF shall prevent code executing on any baseband processor (BP) from - accessing application processor (AP) resources except when mediated by the AP. - These resources include: - - Volatile and non-volatile memory - Control of and data from integrated and non-integrated peripherals (e.g. USB - controllers, touch screen controllers, LCD controller, codecs) - Control of and data from integrated and non-integrated I/O sensors (e.g. + The TSF shall prevent code executing on any baseband processor (BP) from accessing application processor (AP) resources except when mediated by the AP. + These resources include:Volatile and non-volatile memoryControl of and data from integrated and non-integrated peripherals (e.g. USB + controllers, touch screen controllers, LCD controller, codecs)Control of and data from integrated and non-integrated I/O sensors (e.g. camera, light, microphone, GPS, accelerometers, geomagnetic field - sensors) - - Mobile devices are becoming increasingly complex having an application + sensors) Mobile devices are becoming increasingly complex having an application processor that runs an operating system and user applications and separate - baseband processors that handle cellular and other wireless network connectivity. - - The application processor within most modern Mobile Devices is a system on a + baseband processors that handle cellular and other wireless network connectivity. The application processor within most modern Mobile Devices is a system on a chip (SoC) that integrates, for example, CPU/GPU cores and memory interface - electronics into a single, power-efficient package. - Baseband processors are becoming increasingly complex themselves delivering + electronics into a single, power-efficient package.Baseband processors are becoming increasingly complex themselves delivering voice encoding alongside multiple independent radios (LTE, Wi-Fi, Bluetooth, FM, - GPS) in a single package containing multiple CPUs and DSPs. - - Thus, the baseband processors in these requirements include such + GPS) in a single package containing multiple CPUs and DSPs. Thus, the baseband processors in these requirements include such integrated SoCs and include any radio processors (integrated or not) on the Mobile Device. All other requirements mostly, except where noted, apply to firmware/software on the application processor, but future requirements (notably, all Integrity, Access Control, and Anti-Exploitation requirements) will apply to application processors and baseband processors. - + The evaluator shall ensure that the TSS section of the ST describes at a high level how the processors on the Mobile Device interact, including which bus protocols they use to communicate, any other devices operating on that bus @@ -9792,28 +5036,16 @@ The evaluator shall exercise the TSF configuration as the administrator and There are no test evaluation activities for this component. - + - - - This family defines requirements for limiting Bluetooth capabilities without user action. - - - - - - + + requires the TSF to maintain a disabled by default posture for Bluetooth profiles. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. - - - The TSF shall disable support for <assignable>list of Bluetooth - profiles</assignable> Bluetooth profiles when they are not currently being used by - an application on the Mobile Device, and shall require explicit user action to enable - them. + The TSF shall disable support for<assignable>list of Bluetooth profiles</assignable>Bluetooth profiles when they are not currently being used by an application on the Mobile Device, and shall require explicit user action to enable them. Some Bluetooth services incur more serious consequences if unauthorized remote devices gain access to them. Such services should be protected by measures like disabling support for the associated Bluetooth profile unless it is @@ -9826,11 +5058,14 @@ The evaluator shall exercise the TSF configuration as the administrator and indicating readiness to transfer an object. After completion of the object transfer, support for the OBEX profile should be suspended until the next time the user requests its use. - + The evaluator shall ensure that the TSS lists all Bluetooth profiles that are disabled while not in use by an application and which need explicit user action in order to become enabled. - There are no guidance evaluation activities for this component.The evaluator shall perform the following tests: + There are no guidance evaluation activities for this component. + + + The evaluator shall perform the following tests: While the service is not in active use by an application on the TOE, the evaluator shall attempt to discover a service associated with a "protected" Bluetooth profile (as specified by the requirement) on the TOE via a Service @@ -9839,7 +5074,7 @@ The evaluator shall exercise the TSF configuration as the administrator and shall attempt to gain remote access to the service from a device that does not currently have a trusted device relationship with the TOE. The evaluator shall verify that this attempt fails due to the unavailability of the service and - profile. + profile. The evaluator shall repeat Test 1 with a device that currently has a trusted device relationship with the TOE and verify that the same behavior is exhibited. @@ -9847,69 +5082,45 @@ The evaluator shall exercise the TSF configuration as the administrator and - + - - - This family defines requirements for JTAG interface access limitations. - - - - - - + + requires the TSF to specify the mechanism used to restrict access to its JTAG interface. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. - - The TSF shall <selectables> - <selectable id="s-jtag-kill-hw">disable access through hardware</selectable> - <selectable id="s-jtag-control-key">control access by a signing key</selectable> - </selectables> to JTAG. - - The TSF shall <assignable>list access control mechanisms</assignable> to JTAG. - + The TSF shall<selectables><selectable id="s-jtag-kill-hw" >disable access through hardware</selectable><selectable id="s-jtag-control-key" >control access by a signing key</selectable></selectables>to JTAG. This requirement means that access to JTAG must be disabled either through hardware or restricted through the use of a signing key. - - If is selected: The evaluator shall + + If is selected: The evaluator shall examine the TSS to determine the location of the JTAG ports on the TSF, to include the order of the ports (i.e. Data In, Data Out, Clock, etc.). - If is selected: The evaluator shall examine + If is selected: The evaluator shall examine the TSS to determine how access to the JTAG is controlled by a signing key. The evaluator shall examine the TSS to determine when the JTAG can be accessed, i.e. what has the access to the signing key. There are no guidance evaluation activities for this component. - - Evaluation Activity Note: The following test requires the developer to + Evaluation Activity Note: The following test requires the developer to provide access to a test platform that provides the evaluator with chip level - access. If is + access. If is selected: The evaluator shall connect a packet analyzer to the JTAG ports. The evaluator shall query the JTAG port for its device ID and confirm that the - device ID cannot be retrieved. - + device ID cannot be retrieved. - - - - - This family defines requirements for protecting plaintext keys. - - - - - + + + + requires the TSF to avoid storage of plaintext keys in readable memory. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. - - The TSF shall not store any plaintext key material in readable non-volatile - memory. + The TSF shall not store any plaintext key material in readable non-volatile memory. The intention of this requirement is that the TOE will not write plaintext keying material to persistent storage. For the purposes of this requirement, keying material refers to authentication data, passwords, secret/private @@ -9918,18 +5129,9 @@ The evaluator shall exercise the TSF configuration as the administrator and value derived from passwords. Thus, the TOE cannot store plaintext password hashes for comparison purposes before protected data is decrypted, and the TOE should use key derivation and decryption to verify the Password Authentication Factor. - If is selected in FIA_UAU.5.1 keying + If is selected in FIA_UAU.5.1 keying material also refers to the PIN/password used as part of the hybrid authentication. - + The evaluator shall consult the TSS section of the ST in performing the Evaluation Activities for this requirement. In performing their review, the evaluator shall determine that the TSS contains a description of the activities that @@ -9945,48 +5147,33 @@ The evaluator shall exercise the TSF configuration as the administrator and (e.g., regeneration of the keys) ensure that no unencrypted key material is present in persistent storage. The evaluator shall review the TSS to determine that it makes a case that key material is not written unencrypted to the - persistent storage. + persistent storage. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component. - + - - + + requires the TSF to prevent transmitting plaintext key material to the operational environment. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. - - The TSF shall not transmit any plaintext key material outside the security - boundary of the TOE. + The TSF shall not transmit any plaintext key material outside the security boundary of the TOE. The intention of this requirement is to prevent the logging of plaintext key information to a service that transmits the information off-device. For the purposes of this requirement, key material refers to keys, passwords, and other - material that is used to derive keys. - If is selected in FIA_UAU.5.1 - keying material also refers to the PIN/password used as part of + material that is used to derive keys. + If is selected in FIA_UAU.5.1 + keying material also refers to the PIN/password used as part of the hybrid authentication. In the future, this requirement will apply to symmetric and asymmetric private keys stored in the TOE secure key storage where applications are outside the boundary of the TOE. Thus, the TSF will be required to provide cryptographic key operations (signature, encryption, and decryption) on behalf of applications (FCS_SRV_EXT.2.1) that have access to those keys. - + The evaluator shall consult the TSS section of the ST in performing the Evaluation Activities for this requirement. The evaluator shall ensure that the TSS describes the TOE security boundary. The cryptographic module may very well be a particular @@ -9999,37 +5186,26 @@ The evaluator shall exercise the TSF configuration as the administrator and that no unencrypted key material is transmitted outside the security boundary of the TOE. The evaluator shall review the TSS to determine that it makes a case that key material is not transmitted outside the security boundary of - the TOE. + the TOE. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component. - + - - + + requires the TSF to prevent the export of plaintext keys. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. - - The TSF shall ensure it is not possible for the TOE users to export plaintext - keys. + The TSF shall ensure it is not possible for the TOE users to export plaintext keys. Plaintext keys include DEKs, KEKs, and all keys stored in the secure key storage (FCS_STG_EXT.1). The intent of this requirement is to prevent the plaintext keys from being exported during a backup authorized by the TOE user or administrator. - + The ST author will provide a statement of their policy for handling and protecting keys. The evaluator shall check to ensure the TSS describes a policy in line with not exporting either plaintext DEKs, KEKs, or keys stored in the secure @@ -10038,52 +5214,28 @@ The evaluator shall exercise the TSF configuration as the administrator and There are no test evaluation activities for this component. - + - - - This family defines requirements for generation of notifications in response to completed self-tests. - - - - - + + requires the TSF to become non-operational when certain failures occur. There are no management activities foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - - Measurement of TSF software. - - - FPT_TST_EXT.1 TSF Cryptographic Functionality Testing + Measurement of TSF software. + FPT_TST_EXT.1 TSF Cryptographic Functionality Testing FPT_TST_EXT.2 TSF Integrity Checking - - The TSF shall transition to non-operational mode and <selectables> - <selectable>log failures in the audit record</selectable> - <selectable>notify the administrator</selectable> - <selectable> - <assignable>other actions</assignable></selectable> - <selectable exclusive="yes">no other actions</selectable> - </selectables> when the following types of failures occur: <htm:ul> - <htm:li>failures of the self-tests</htm:li> - <htm:li>TSF software integrity verification failures</htm:li> - <htm:li><selectables> - <selectable exclusive="yes">no other failures</selectable> - <selectable> - <assignable>other failures</assignable></selectable> - </selectables></htm:li> - </htm:ul> - - + The TSF shall transition to non-operational mode and<selectables><selectable id="fpt_not_ext.1.1_1" >log failures in the audit record</selectable><selectable id="fpt_not_ext.1.1_2" >notify the administrator</selectable><selectable id="fpt_not_ext.1.1_4" ><assignable>other actions </assignable></selectable><selectable id="fpt_not_ext.1.1_5" exclusive="yes" >no other actions</selectable></selectables>when the following types of failures occur: <htm:ul><htm:li>failures of the self-tests</htm:li><htm:li>TSF software integrity verification failures</htm:li><htm:li><selectables><selectable id="fpt_not_ext.1.1_6" exclusive="yes" >no other failures</selectable><selectable id="fpt_not_ext.1.1_8" ><assignable>other failures </assignable></selectable></selectables></htm:li></htm:ul> + The evaluator shall verify that the TSS describes critical failures that may occur and the actions to be taken upon these critical failures. There are no guidance evaluation activities for this component. - Evaluation Activity Note: The following test require the developer to + + The following test require the developer to provide access to a test platform that provides the evaluator with tools that are - typically not found on consumer Mobile Device products. + typically not found on consumer Mobile Device products. The evaluator shall use a tool provided by the developer to modify files and processes in the system that correspond to critical failures specified in the second list. The evaluator shall verify that creating these critical failures @@ -10093,28 +5245,31 @@ The evaluator shall exercise the TSF configuration as the administrator and - - Measurement of TSF softwarenone - Integrity verification valueNo additional information - - - - + + + + Measurement of TSF software + none + + + + + Integrity verification value + No additional information + + + + + + requires the TSF to generate and sign software integrity verification values. The following actions could be considered for the management functions in FMT: - - Retrieval of TSF software integrity verification values. - - + Retrieval of TSF software integrity verification values. There are no auditable events foreseen. FCS_COP.1 Cryptographic Operation - - The TSF shall <selectables> - <selectable>audit</selectable> - <selectable>provide the administrator with</selectable> - </selectables> TSF-software integrity verification values. + The TSF shall<selectables><selectable id="fpt_not_ext.2.1_1" >audit</selectable><selectable id="fpt_not_ext.2.1_2" >provide the administrator with</selectable></selectables>TSF-software integrity verification values. These notifications are typically called remote attestation and these integrity values are typically called measurements. The integrity values are calculated from hashes of critical memory and values, including executable code. The @@ -10124,19 +5279,16 @@ The evaluator shall exercise the TSF configuration as the administrator and The evaluator shall verify that the TSS describes which critical memory is measured for these integrity values and how the measurement is performed (including which TOE software performs these generates these values, how that software accesses - the critical memory, and which algorithms are used). - + the critical memory, and which algorithms are used). If the integrity values are provided to the administrator, the evaluator shall verify that the AGD guidance contains instructions for retrieving these values and information for interpreting them. For example, if multiple measurements are taken, what those measurements are and how changes to those values relate to changes - in the device state. - + in the device state. - Evaluation Activity Note: The following test may require the developer - to provide access to a test platform that provides the evaluator with tools that are - typically not found on consumer Mobile Device products. The - evaluator shall repeat the following test for each measurement: + + The + evaluator shall repeat the following test for each measurement: The evaluator shall boot the device in an approved state and record the measurement taken (either from the log or by using the administrative guidance to retrieve the value via an MDM Agent). The evaluator shall modify the critical @@ -10158,7 +5310,9 @@ The evaluator shall exercise the TSF configuration as the administrator and the method of associating the certificate with a particular device manufacturer and model. There are no guidance evaluation activities for this component. - The evaluator shall perform the following test: + + + The evaluator shall perform the following test: The evaluator shall write, or the developer shall provide, a management application that queries either the audit logs or the measurements. The evaluator shall verify that the responses to these queries are signed and verify @@ -10167,12 +5321,13 @@ The evaluator shall exercise the TSF configuration as the administrator and - + - + + - The TSF shall be able to provide reliable time stamps <refinement>for its own use</refinement>. - + The TSF shall be able to provide reliable time stamps <htm:b>for its own use</htm:b> . + The evaluator shall examine the TSS to ensure that it lists each security function that makes use of time. The TSS provides a description of how the time is maintained and considered reliable in the context of each of the time related @@ -10189,38 +5344,24 @@ The evaluator shall exercise the TSF configuration as the administrator and - + - - - This family defines requirements for execution of self-tests that are not addressed by FPT_TST in CC Part 2. - - - - - - + + requires the TSF to run self-test at start-up to verify correct operation. There are no management activities foreseen. - The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - Initiation of self-test. - Failure of self-test. - - + The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:Initiation of self-test.Failure of self-test. FCS_COP.1 Cryptographic Operation - - - The TSF shall run a suite of self-tests during initial start-up (on power on) to - demonstrate the correct operation of all cryptographic functionality. + The TSF shall run a suite of self-tests during initial start-up (on power on) to demonstrate the correct operation of all cryptographic functionality. This requirement may be met by performing known answer tests or pair-wise consistency tests. The self-tests must be performed before the cryptographic functionality is exercised (for example, during the initialization of a process that utilizes the functionality). The cryptographic functionality includes the cryptographic operations in FCS_COP, the key generation functions in FCS_CKM, and the random bit generation in FCS_RBG_EXT. - + The evaluator shall examine the TSS to ensure that it specifies the self-tests that are performed at start-up. This description must include an outline of the test procedures conducted by the TSF (e.g., rather than saying "memory is tested", a @@ -10237,35 +5378,69 @@ The evaluator shall exercise the TSF configuration as the administrator and There are no test evaluation activities for this component. - Initiation of self-test - - Failure of self-test - Algorithm that caused the failureNo additional information - - - - - + + Initiation of self-test + + + Failure of self-test + + + Algorithm that caused the failure + No additional information + + + + + + - The TSF shall verify the integrity of <assignable>TSF data</assignable> stored in mutable media - prior to its execution through the use of <assignable>cryptographic or immutable hardware mechanism</assignable>. - - + The TSF shall verify the integrity of<assignable>TSF data</assignable>stored in mutable media prior to its execution through the use of<assignable>cryptographic or immutable hardware mechanism</assignable>. + + + + + + The TSF shall verify the integrity of<selectables><selectable id="s-all-exe" >all executable code</selectable><selectable id="fpt_tst_ext.2.1_POSTKERNEL_2" ><assignable>subset of executable code </assignable></selectable></selectables>stored in mutable media prior to its execution through the use of<selectables><selectable id="fpt_tst_ext.2.1_POSTKERNEL_3" >a digital signature using an immutable hardware asymmetric + key</selectable><selectable id="fpt_tst_ext.2.1_POSTKERNEL_4" >an immutable hardware hash of an asymmetric key</selectable><selectable id="fpt_tst_ext.2.1_POSTKERNEL_5" >an immutable hardware hash</selectable><selectable id="fpt_tst_ext.2.1_POSTKERNEL_6" >a digital signature using a hardware-protected asymmetric + key</selectable><selectable id="fpt_tst_ext.2.1_POSTKERNEL_7" >hardware-protected hash</selectable></selectables>. + All executable code covered in this requirement is executed + after the kernel is loaded. If "all executable code in mutable + media" is verified, implementation in hardware or in read-only memory is a natural + logical consequence. At this time, the verification of software + executed on other processors stored in mutable media is not required; however, it may + be added in the first assignment. If all executable code (including bootloaders, + kernel, device drivers, pre-loaded applications, user-loaded applications, and + libraries) is verified, "all executable code stored in mutable media" should be + selected. + + There are no TSS evaluation activities for this component. + There are no guidance evaluation activities for this component. + The evaluation activity shall be completed in conjunction with FPT_TST_EXT.2/PREKERNEL + for all executable code specified. + + + + Detected integrity violation + none + + + + + The TSF code file that cause the integrity violation + No additional information + + + - - + + - The TSF shall verify the integrity of [<htm:i>the bootchain up through the Application - Processor OS kernel</htm:i>] stored in mutable media prior to its execution through the use of <selectables> - <selectable>a digital signature using an immutable hardware asymmetric - key</selectable> - <selectable>an immutable hardware hash of an asymmetric key</selectable> - <selectable>an immutable hardware hash</selectable> - <selectable>a digital signature using a hardware-protected asymmetric - key</selectable> - </selectables>. + The TSF shall verify the integrity of [ <htm:i>the bootchain up through the Application + Processor OS kernel</htm:i> ] stored in mutable media prior to its execution through the use of<selectables><selectable id="fpt_tst_ext.2.1_PREKERNEL_1" >a digital signature using an immutable hardware asymmetric + key</selectable><selectable id="fpt_tst_ext.2.1_PREKERNEL_2" >an immutable hardware hash of an asymmetric key</selectable><selectable id="fpt_tst_ext.2.1_PREKERNEL_3" >an immutable hardware hash</selectable><selectable id="fpt_tst_ext.2.1_PREKERNEL_4" >a digital signature using a hardware-protected asymmetric + key</selectable></selectables>. The bootchain of the TSF is the sequence of firmware and software, including ROM, bootloaders, and kernel, which ultimately result in loading the kernel on the Application Processor, regardless of which processor executes that @@ -10278,7 +5453,7 @@ The evaluator shall exercise the TSF configuration as the administrator and The cryptographic mechanism used to verify the (initial) mutable executable code must be protected, such as being implemented in hardware or in read-only memory (ROM). - + The evaluator shall verify that the TSS section of the ST includes a description of the boot procedures, including a description of the entire bootchain, of the software for the TSF’s Application Processor. The evaluator shall ensure that before @@ -10297,21 +5472,19 @@ The evaluator shall exercise the TSF configuration as the administrator and code through the kernel is verified before each execution. There are no guidance evaluation activities for this component. - Evaluation Activity Note: The following tests require the vendor to - provide access to a test platform that provides the evaluator with tools that are - typically not found on consumer Mobile Device products. The - evaluator shall perform the following tests: + + The + evaluator shall perform the following tests: The evaluator shall perform actions to cause TSF software to load and observe that the integrity mechanism does not flag any executables as containing integrity errors and that the TOE properly boots. - The evaluator shall modify a TSF executable that is integrity protected and cause that executable to be successfully loaded by the TSF. The evaluator observes that an integrity violation is triggered and the TOE does not boot. (Care must be taken so that the integrity violation is determined to be the cause of the failure to load the module, and not the fact that the module was modified so that it was rendered unable to run because its format was - corrupt). + corrupt). [conditional] If the ST author indicates that the integrity verification is performed using a public key, the evaluator shall verify that the update mechanism includes a certificate validation according to FIA_X509_EXT.1. The @@ -10325,108 +5498,72 @@ The evaluator shall exercise the TSF configuration as the administrator and - Start-up of TOE - - Detected integrity violationnone - The TSF code file that caused the integrity violationNo additional information - - - - - The TSF shall verify the integrity of <selectables> - <selectable id="s-all-exe">all executable code</selectable> - <selectable><assignable>subset of executable code</assignable></selectable> - </selectables> stored in mutable media prior to its execution through the use of <selectables> - <selectable>a digital signature using an immutable hardware asymmetric - key</selectable> - <selectable>an immutable hardware hash of an asymmetric key</selectable> - <selectable>an immutable hardware hash</selectable> - <selectable>a digital signature using a hardware-protected asymmetric - key</selectable> - <selectable>hardware-protected hash</selectable> - </selectables>. - All executable code covered in this requirement is executed - after the kernel is loaded. If "all executable code in mutable - media" is verified, implementation in hardware or in read-only memory is a natural - logical consequence. At this time, the verification of software - executed on other processors stored in mutable media is not required; however, it may - be added in the first assignment. If all executable code (including bootloaders, - kernel, device drivers, pre-loaded applications, user-loaded applications, and - libraries) is verified, "all executable code stored in mutable media" should be - selected. - - There are no TSS evaluation activities for this component. - There are no guidance evaluation activities for this component. - The evaluation activity shall be completed in conjunction with FPT_TST_EXT.2/PREKERNEL - for all executable code specified. - - - - Detected integrity violationNone - The TSF code file that cause the integrity violationNo additional information - + + Start-up of TOE + + + + + Detected integrity violation + none + + + + + The TSF code file that caused the integrity violation + No additional information + + + - + + - requires the TSF to validate a code signing certificate before the associated code is executed. There are no management activities foreseen. There are no auditable events foreseen. - FPT_TST_EXT.2 TSF Integrity Checking - FIA_X509_EXT.1 X.509 Validation of Certificates + FPT_TST_EXT.2 TSF Integrity Checking + FIA_X509_EXT.1 X.509 Validation of Certificates FIA_X509_EXT.2 X.509 Certificate Authentication - - - The TSF shall not execute code if the code signing certificate is deemed invalid. + The TSF shall not execute code if the code signing certificate is deemed invalid. Certificates may optionally be used for code signing for integrity verification (FPT_TST_EXT.2.1/PREKERNEL). - If is selected in FIA_X509_EXT.2.1, FPT_TST_EXT.3 must be included in the + If is selected in FIA_X509_EXT.2.1, FPT_TST_EXT.3 must be included in the ST. Validity is determined by the certificate path, the expiration date, and the revocation status in accordance with RFC 5280. - + There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. Testing for this component is performed in conjunction with the Evaluation Activities for FPT_TST_EXT.2.1/PREKERNEL. - - - - - This family defines requirements for trusted updates. - - - - - - + + + + requires the TSF to provide authorized users the ability to query the version of the TOE hardware, TOE software, and installed applications. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. - - - The TSF shall provide authorized users the ability to query the current version - of the TOE firmware/software. + The TSF shall provide authorized users the ability to query the current version of the TOE firmware/software. - The TSF shall provide authorized users the ability to query the current version - of the hardware model of the device. + The TSF shall provide authorized users the ability to query the current version of the hardware model of the device. The current version of the hardware model of the device is an identifier that is sufficient to indicate (in tandem with manufacturer documentation) the hardware which comprises the device. - The TSF shall provide authorized users the ability to query the current version - of installed mobile applications. + The TSF shall provide authorized users the ability to query the current version of installed mobile applications. The current version of mobile applications is the name and published version number of each installed mobile application. - The evaluator shall establish a test environment consisting of the Mobile + + The evaluator shall establish a test environment consisting of the Mobile Device and any supporting software that demonstrates usage of the management functions. This can be test software from the developer, a reference implementation of management software from the developer, or other commercially available software. The @@ -10437,42 +5574,24 @@ The evaluator shall exercise the TSF configuration as the administrator and Using the AGD guidance provided, the evaluator shall test that the - administrator and user can query: - The current version of the TSF operating system and any firmware that - can be updated separately - The hardware model of the TSF - The current version of all installed mobile applications - - - The evaluator must review manufacturer documentation to ensure that the - hardware model identifier is sufficient to identify the hardware which comprises the - device. + administrator and user can query: The current version of the TSF operating system and any firmware that + can be updated separatelyThe hardware model of the TSFThe current version of all installed mobile applications + + - + - - + + requires the TSF to ensure that system software updates are digitally signed prior to installation. The following actions could be considered for the management functions in FMT: - - Updating of system software. - - + Updating of system software. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - - Success or failure of signature verification for applications. - - + Success or failure of signature verification for applications. FCS_COP.1 Cryptographic Operation - - The TSF shall verify software updates to the Application Processor system - software and <selectables> - <selectable><assignable>other processor system software</assignable></selectable> - <selectable>no other processor system software</selectable> - </selectables> using a digital signature verified by the manufacturer trusted key - prior to installing those updates. + The TSF shall verify software updates to the Application Processor system software and<selectables><selectable id="fpt_tud_ext.2.1_2" ><assignable>other processor system software </assignable></selectable><selectable id="fpt_tud_ext.2.1_3" >no other processor system software</selectable></selectables>using a digital signature verified by the manufacturer trusted key prior to installing those updates. The digital signature mechanism is implemented in accordance with FCS_COP.1.1/SIGN. At this time, this requirement does not require verification of software updates to the software operating outside the @@ -10484,31 +5603,21 @@ The evaluator shall exercise the TSF configuration as the administrator and interface. - The TSF shall <selectables> - <selectable>never update</selectable> - <selectable>update only by verified software</selectable> - </selectables> the TSF boot integrity <selectables> - <selectable>key</selectable> - <selectable>hash</selectable> - </selectables>. + The TSF shall<selectables><selectable id="fpt_tud_ext.2.2_1" >never update</selectable><selectable id="fpt_tud_ext.2.2_2" >update only by verified software</selectable></selectables>the TSF boot integrity<selectables><selectable id="fpt_tud_ext.2.2_3" >key</selectable><selectable id="fpt_tud_ext.2.2_4" >hash</selectable></selectables>. The key or hash updated via this requirement is used for verifying software before execution in FPT_TST_EXT.2/PREKERNEL. The key or hash is verified as a part of the digital signature on an update, and the software which performs the update of the key or hash is verified by FPT_TST_EXT.2/PREKERNEL. - The TSF shall verify that the digital signature verification key used for TSF - updates <selectables> - <selectable>is validated to a public key in the Trust Anchor Database</selectable> - <selectable>matches an immutable hardware public key</selectable> - </selectables>. + The TSF shall verify that the digital signature verification key used for TSF updates<selectables><selectable id="fpt_tud_ext.2.3_1" >is validated to a public key in the Trust Anchor Database</selectable><selectable id="fpt_tud_ext.2.3_2" >matches an immutable hardware public key</selectable></selectables>. The ST author must indicate the method by which the signing key for system software updates is limited and, if selected in FPT_TUD_EXT.2.3, must indicate how this signing key is protected by the hardware. If certificates are used, certificates are validated for the purpose of software updates in accordance with FIA_X509_EXT.1 and should be selected in FIA_X509_EXT.2.1. Additionally, FPT_TUD_EXT.4 must be included in the ST. - + The evaluator shall verify that the TSS section of the ST describes all TSF software update mechanisms for updating the system software. The evaluator shall verify that the description includes a digital signature verification of the @@ -10518,8 +5627,6 @@ The evaluator shall exercise the TSF configuration as the administrator and software/firmware responsible for each stage is indicated and that the stages which perform signature verification of the update are identified. - - The evaluator shall verify that the TSS describes the method by which the digital signature is verified and that the public key used to verify the signature is either hardware-protected or is validated to chain to a public key in @@ -10541,13 +5648,14 @@ The evaluator shall exercise the TSF configuration as the administrator and There are no guidance evaluation activities for this component. - The evaluator shall verify that the developer has provided evidence that the - following tests were performed for each available update mechanism: + + + The evaluator shall verify that the developer has provided evidence that the + following tests were performed for each available update mechanism: The tester shall try to install an update without the digital signature and shall verify that installation fails. The tester shall attempt to install an - update with digital signature, and verify that installation succeeds. - + update with digital signature, and verify that installation succeeds. The tester shall digitally sign the update with a key disallowed by the device and verify that installation fails. The tester shall attempt to install an update signed with the allowed key and verify that installation succeeds. [conditional] The tester shall digitally sign the update with an invalid @@ -10562,38 +5670,30 @@ The evaluator shall exercise the TSF configuration as the administrator and - - Success or failure of signature verification for software updates - - - - + + Success or failure of signature verification for software updates + + + + requires the TSF to ensure that application software updates are digitally signed prior to installation. There are no management activities foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - - Success or failure of signature verification for applications. - - - FIA_X509_EXT.1 X.509 Validation of Certificates + Success or failure of signature verification for applications. + FIA_X509_EXT.1 X.509 Validation of Certificates FIA_X509_EXT.2 X.509 Certificate Authentication - - - The TSF shall verify mobile application software using a digital signature - mechanism prior to installation. + The TSF shall verify mobile application software using a digital signature mechanism prior to installation. This requirement does not necessitate an X.509v3 certificate or certificate validation. X.509v3 certificates and certificate validation are addressed - in . - + in . + The evaluator shall verify that the TSS describes how mobile application software is verified at installation. The evaluator shall ensure that this method uses a digital signature. There are no guidance evaluation activities for this component. - Evaluation Activity Note: The following test does not have to be tested - using the commercial application store. The evaluator shall write, or the developer shall provide access to, an application. The evaluator shall try to install this application without a @@ -10604,64 +5704,54 @@ The evaluator shall exercise the TSF configuration as the administrator and - - Success or failure of signature verification for applications - + + Success or failure of signature verification for applications + - - - + + + + requires the TSF to enforce validity of system software’s code signing certificate prior to installation. There are no management activities foreseen. There are no auditable events foreseen. - FIA_X509_EXT.1 X.509 Validation of Certificates + FIA_X509_EXT.1 X.509 Validation of Certificates FIA_X509_EXT.2 X.509 Certificate Authentication - - - The TSF shall not install code if the code signing certificate is deemed invalid. + The TSF shall not install code if the code signing certificate is deemed invalid. Certificates may optionally be used for code signing of system - software updates (FPT_TUD_EXT.2.3) and of mobile applications (). This + software updates (FPT_TUD_EXT.2.3) and of mobile applications ( ). This element must be included in the ST if certificates are used for either update element. - If either or is selected in FIA_X509_EXT.2.1, + If either or is selected in FIA_X509_EXT.2.1, FPT_TUD_EXT.4 must be included in the ST. Validity is determined by the certificate path, the expiration date, and the revocation status in accordance with RFC 5280. - + There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. Testing for this component is performed in conjunction with the Evaluation Activities for FPT_TUD_EXT.2 and FPT_TUD_EXT.5. - + - - + + requires the TSF to enforce validity of application software’s code signing certificate prior to installation. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - - Configure certificate or public key used to validate digital signature on applications. - - + Configure certificate or public key used to validate digital signature on applications. There are no auditable events foreseen. - FIA_X509_EXT.1 X.509 Validation of Certificates + FIA_X509_EXT.1 X.509 Validation of Certificates FIA_X509_EXT.2 X.509 Certificate Authentication - - - The TSF shall by default only install mobile applications cryptographically - verified by <selectables> - <selectable>a built-in X.509v3 certificate</selectable> - <selectable>a configured X.509v3 certificate</selectable> - </selectables>. + The TSF shall by default only install mobile applications cryptographically verified by<selectables><selectable id="fpt_tud_ext.5.1_1" >a built-in X.509v3 certificate</selectable><selectable id="fpt_tud_ext.5.1_2" >a configured X.509v3 certificate</selectable></selectables>. The built-in certificate is installed by the manufacturer either at time of manufacture or as a part of system updates. The configured certificate used to verify the signature is set according to FMT_SMF.1 function - . - + . + The evaluator shall verify that the TSS describes how mobile application software is verified at installation. The evaluator shall ensure that this method uses a digital signature by a code signing certificate. @@ -10672,13 +5762,13 @@ The evaluator shall exercise the TSF configuration as the administrator and application. The evaluator shall try to install this application without a digitally signature and shall verify that installation fails. The evaluator shall attempt to install an application digitally signed with an appropriate - certificate, and verify that installation succeeds. + certificate, and verify that installation succeeds. The evaluator shall digitally sign the application with an invalid certificate and verify that application installation fails. The evaluator shall digitally sign the application with a certificate that does not have the Code Signing purpose and verify that application installation fails. This test may be performed in conjunction with the Evaluation Activities for - FIA_X509_EXT.1. + FIA_X509_EXT.1. If necessary, the evaluator shall configure the device to limit the public keys that can sign application software according to the AGD guidance. The evaluator shall digitally sign the application with a certificate disallowed by @@ -10689,85 +5779,64 @@ The evaluator shall exercise the TSF configuration as the administrator and - + - - + + requires the TSF to prevent the intentional rollback of software updates. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. - - - The TSF shall verify that software updates to the TSF are a current or later - version than the current version of the TSF. + The TSF shall verify that software updates to the TSF are a current or later version than the current version of the TSF. A later version has a larger version number. The method for distinguishing newer software versions from older versions is determined by the manufacturer. - + The evaluator shall verify that the TSS describes the mechanism that prevents the TSF from installing software updates that are an older version that the currently - installed version. - + installed version. There are no guidance evaluation activities for this component. - The evaluator shall repeat the following tests to cover all allowed software + + + The evaluator shall repeat the following tests to cover all allowed software update mechanisms as described in the TSS. For example, if the update mechanism replaces an entire partition containing many separate code files, the evaluator does - not need to repeat the test for each individual file. + not need to repeat the test for each individual file. The evaluator shall attempt to install an earlier version of software (as determined by the manufacturer). The evaluator shall verify that this attempt fails by checking the version identifiers or cryptographic hashes of the privileged software against those previously recorded and checking that the - values have not changed. + values have not changed. The evaluator shall attempt to install a current or later version and shall verify that the update succeeds. - + - - - - - This family defines requirements for session locking capabilities that are not addressed by FTA_SSL in CC Part 2. - - - - - - +
    + +
    + + requires the TSF to manage the transition to a locked state and what operations can be performed. The following actions could be considered for the management functions in FMT: - - Configuring session locking policy. - Transitioning to the locked state. - - + Configuring session locking policy.Transitioning to the locked state. There are no auditable events foreseen. No dependencies. - - The TSF shall transition to a locked state after a time interval of inactivity. - + The TSF shall transition to a locked state after a time interval of inactivity. - The TSF shall transition to a locked state after initiation by either the user or - the administrator. + The TSF shall transition to a locked state after initiation by either the user or the administrator. - The TSF shall, upon transitioning to the locked state, perform the following - operations: <htm:ul> - <htm:li>Clearing or overwriting display devices, obscuring the previous contents; </htm:li> - <htm:li><assignable>Other actions performed upon transitioning to the locked - state</assignable>.</htm:li> - </htm:ul> - + The TSF shall, upon transitioning to the locked state, perform the following operations: <htm:ul><htm:li>Clearing or overwriting display devices, obscuring the previous contents; </htm:li><htm:li><assignable>Other actions performed upon transitioning to the locked state</assignable>.</htm:li></htm:ul> - The time interval of inactivity is configured using FMT_SMF.1 function . The user/administrator-initiated lock is specified in FMT_SMF.1 function . - + The time interval of inactivity is configured using FMT_SMF.1 function . The user/administrator-initiated lock is specified in FMT_SMF.1 function . + The evaluator shall verify the TSS describes the actions performed upon transitioning to the locked state. The evaluation shall verify that the AGD guidance describes the method of @@ -10780,7 +5849,7 @@ The evaluator shall exercise the TSF configuration as the administrator and after a time of inactivity (FMT_SMF.1) according to the AGD guidance. The evaluator shall wait until the TSF locks and verify that the display is cleared or overwritten and that the only actions allowed in the locked state are - unlocking the session and those actions specified in FIA_UAU_EXT.2. + unlocking the session and those actions specified in FIA_UAU_EXT.2. The evaluator shall command the TSF to transition to the locked state according to the AGD guidance as both the user and the administrator. The evaluator shall wait until the TSF locks and verify that the display is cleared @@ -10790,21 +5859,22 @@ The evaluator shall exercise the TSF configuration as the administrator and - + - + + - Before establishing a user session, the TSF shall display an advisory warning - message regarding unauthorized use of the TOE. + Before establishing a user session, the TSF shall display an advisory warning message regarding unauthorized use of the TOE. This requirement may be met with the configuration of either text or an image containing the text of the desired message. The TSF must minimally display this information at startup, but may also display the information at every - unlock. The banner is configured according to FMT_SMF.1 function . - - The TSS shall describe when the banner is displayed. + unlock. The banner is configured according to FMT_SMF.1 function . + + The TSS shall describe when the banner is displayed. There are no guidance evaluation activities for this component. - The evaluator shall also perform the following test: + + + The evaluator shall also perform the following test: The evaluator follows the operational guidance to configure a notice and consent warning message. The evaluator shall then start up or unlock the TSF. The evaluator shall verify that the notice and consent warning message is @@ -10813,94 +5883,29 @@ The evaluator shall exercise the TSF configuration as the administrator and - + - - - - - This family defines requirements for trusted channels that are not addressed by FTP_ITC in CC Part 2 because they apply specifically to channels required by a mobile device. - - - - - - +
    + +
    + + requires the TSF to manage the communication channel between itself and other trusted products. - The following actions could be considered for the management functions in FMT: - Configuring the actions that require trusted channel, if applicable. - Enabling/disabling communications protocols where the TSF acts as a server. - - - The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - Initiation and termination of trusted channel. - - + The following actions could be considered for the management functions in FMT:Configuring the actions that require trusted channel, if applicable.Enabling/disabling communications protocols where the TSF acts as a server. + The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Initiation and termination of trusted channel. No dependencies. - - - The TSF shall use <htm:ul> - <htm:li>802.11-2012 in accordance with the [<htm:i><xref to="mod-wlanclient"/></htm:i>],</htm:li> - <htm:li>802.1X in accordance with the [<htm:i><xref to="mod-wlanclient"/></htm:i>],</htm:li> - <htm:li>EAP-TLS in accordance with the [<htm:i><xref to="mod-wlanclient"/></htm:i>],</htm:li> - <htm:li>Mutually authenticated TLS in accordance with [<htm:i>the <xref to="pkg-tls"/></htm:i>]</htm:li> - </htm:ul> and <selectables linebreak="yes"> - <selectable id="s-itc-ipsec"><snip>IPsec</snip> in accordance with the <xref to="mod-vpnclient"/></selectable> - <selectable id="itc_dtls"><snip>mutually authenticated DTLS</snip> as defined in the <xref to="pkg-tls"/></selectable> - <selectable>HTTPS</selectable> - </selectables> protocols to provide a communication channel between itself and another trusted IT product that is logically distinct from other communication channels, - provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data. - - The TSF shall use <htm:ul> - <htm:li>802.11-2012 in accordance with <assignable>requirements or standards defining implementation of this protocol</assignable>,</htm:li> - <htm:li>802.1X in accordance with <assignable>requirements or standards defining implementation of this protocol</assignable>,</htm:li> - <htm:li>EAP-TLS in accordance with <assignable>requirements or standards defining implementation of this protocol</assignable>,</htm:li> - <htm:li>Mutually authenticated TLS in accordance with <assignable>requirements or standards defining implementation of this protocol</assignable></htm:li> - </htm:ul> and <assignable>other protocols</assignable> protocols to provide a communication channel between itself and another trusted IT product that is logically distinct from other communication channels, - provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data. - + The TSF shall use <htm:ul><htm:li>802.11-2012 in accordance with the [<htm:i> <xref to="mod-wlanclient"></xref></htm:i>],</htm:li><htm:li>802.1X in accordance with the [<htm:i> <xref to="mod-wlanclient"></xref></htm:i>],</htm:li><htm:li>EAP-TLS in accordance with the [<htm:i> <xref to="mod-wlanclient"></xref></htm:i>],</htm:li><htm:li>Mutually authenticated TLS in accordance with [<htm:i>the <xref to="pkg-tls"></xref></htm:i>]</htm:li></htm:ul> and<selectables><selectable id="s-itc-ipsec" > <snip>IPsec</snip> in accordance with the <xref to="mod-vpnclient"></xref></selectable><selectable id="itc_dtls" > <snip>mutually authenticated DTLS</snip> as defined in the <xref to="pkg-tls"></xref></selectable><selectable id="ftp_itc_ext.1.1_1" >HTTPS</selectable></selectables>protocols to provide a communication channel between itself and another trusted IT product that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data. The intent of the mandatory portion of the above requirement is to use the cryptographic protocols identified in the requirement to establish and maintain a trusted channel between the TOE and an access point, VPN Gateway, or other trusted IT product. The ST author must list which trusted channel protocols are implemented by the Mobile Device. - The TSF must be validated against the to satisfy the mandatory trusted channels of 802.11-2012, 802.1X, and EAP-TLS. + The TSF must be validated against the to satisfy the mandatory trusted channels of 802.11-2012, 802.1X, and EAP-TLS. To satisfy the mandatory trusted channel of TLS and - if is selected, the TSF must be validated against the , with the following selections made: - - tlsc_impltlsc_mutual_auths-tlsc-no-excep - - - itc_dtls - dtlsc_impldtlsc_mutual_auths-dtlsc-no-excep - - - - FCS_TLS_EXT.1: - - Either TLS or DTLS is selected as appropriate - Client is selected - - FCS_TLSC_EXT.1.1 or FCS_DTLSC_EXT.1.1 (as appropriate): - - The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1. - Mutual authentication must be selected - - FCS_TLSC_EXT.1.3 or FCS_DTLSC_EXT.1.3 (as appropriate): - - With no exceptions is selected. - - - - - s-itc-ipsec - mod-vpnclient - - If the ST author selects , the TSF must be validated against the . - - - + if is selected, the TSF must be validated against the , with the following selections made: + tlsc_impltlsc_mutual_auths-tlsc-no-excep itc_dtlsdtlsc_impldtlsc_mutual_auths-dtlsc-no-excepFCS_TLS_EXT.1:Either TLS or DTLS is selected as appropriateClient is selectedFCS_TLSC_EXT.1.1 or FCS_DTLSC_EXT.1.1 (as appropriate): The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.Mutual authentication must be selectedFCS_TLSC_EXT.1.3 or FCS_DTLSC_EXT.1.3 (as appropriate): With no exceptions is selected. s-itc-ipsecmod-vpnclient + If the ST author selects , the TSF must be validated against the . contains the requirements for implementing each of the other optional trusted channel protocols. The ST author must include the security functional requirements for the trusted channel protocol selected in FTP_ITC_EXT.1 in the main @@ -10909,42 +5914,36 @@ The evaluator shall exercise the TSF configuration as the administrator and protocols. - The TSF shall permit the TSF to initiate communication via the trusted channel. - + The TSF shall permit the TSF to initiate communication via the trusted channel. - The TSF shall initiate communication via the trusted channel for wireless access - point connections, administrative communication, configured enterprise connections, - and <selectables> - <selectable>OTA updates</selectable> - <selectable exclusive="yes">no other connections</selectable> - </selectables>. - - The evaluator shall examine the TSS to determine that it describes the details + The TSF shall initiate communication via the trusted channel for wireless access point connections, administrative communication, configured enterprise connections, and<selectables><selectable id="ftp_itc_ext.1.3_1" >OTA updates</selectable><selectable id="ftp_itc_ext.1.3_2" exclusive="yes" >no other connections</selectable></selectables>. + + The evaluator shall examine the TSS to determine that it describes the details of the TOE connecting to access points, VPN Gateways, and other trusted IT products in terms of the cryptographic protocols specified in the requirement, along with TOE-specific options or procedures that might not be reflected in the specifications. The evaluator shall also confirm that all protocols listed in the TSS are specified and included in the requirements in the ST. If OTA updates are selected, the TSS shall describe which trusted channel protocol is - initiated by the TOE and is used for updates. - + initiated by the TOE and is used for updates. The evaluator shall confirm that the operational guidance contains instructions for establishing the connection to access points, VPN Gateways, and - other trusted IT products. - - The evaluator shall also perform the following tests for each protocol listed: + other trusted IT products. + + + The evaluator shall also perform the following tests for each protocol listed: The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data are not sent in plaintext and that a - protocol analyzer identifies the traffic as the protocol under testing. - [conditional] If is selected, + protocol analyzer identifies the traffic as the protocol under testing. + [conditional] If is selected, the evaluator shall ensure that the TOE is able to initiate communications with a VPN Gateway, setting up the connections as described in the operational guidance and ensuring that - communication is successful. + communication is successful. [conditional]If OTA updates are selected, the evaluator shall trigger an update request according to the operational guidance and shall ensure that the - communication is successful. + communication is successful. For any other selected protocol (not tested in Test 1, 2, or 3), the evaluator shall ensure that the TOE is able to initiate communications with a trusted IT product using the protocol, setting up the connection as described in @@ -10954,616 +5953,30 @@ The evaluator shall exercise the TSF configuration as the administrator and - - Initiation and termination of trusted channel - Trusted channel protocol, non-TOE endpoint of connection - + + Initiation and termination of trusted channel + Trusted channel protocol, non-TOE endpoint of connection + - -
    -
    - The Security Objectives in - were constructed to address threats identified in - . - The Security Functional Requirements (SFRs) in are a formal - instantiation of the Security Objectives. The PP identifies the Security Assurance - Requirements (SARs) to frame the extent to which the evaluator assesses the documentation - applicable for the evaluation and performs independent testing. This section - lists the set of SARs from CC part 3 that are required in evaluations against this PP. - Individual Evaluation Activities to be performed are specified both in - as well as in this section. The general model for evaluation of TOEs - against STs written to conform to this PP is as follows: After the ST has - been approved for evaluation, the ITSEF will obtain the - TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is - expected to perform actions mandated by the Common Evaluation Methodology (CEM) for the ASE - and ALC SARs. The ITSEF also performs the Evaluation Activities contained within , which are intended to be an interpretation of the other CEM evaluation - requirements as they apply to the specific technology instantiated in the TOE. The Evaluation - Activities that are captured in also provide clarification as to what - the developer needs to provide to demonstrate the TOE is compliant with the PP. - - The TOE Security Assurance Requirements are identified in . - : Security Assurance Requirements - - - Assurance ClassAssurance Components - - - Security Target (ASE) - Conformance Claims (ASE_CCL.1) - - Extended Components Definition (ASE_ECD.1) - ST Introduction (ASE_INT.1) - Security Objectives for the Operational Environment - (ASE_OBJ.1) - Stated Security Requirements (ASE_REQ.1) - Security Problem Definition (ASE_SPD.1) - TOE Summary Specification (ASE_TSS.1) - - Development (ADV) - Basic Functional Specification (ADV_FSP.1) - - - Guidance Documents (AGD) - Operational User Guidance (AGD_OPE.1) - - Preparative Procedures (AGD_PRE.1) - - Life Cycle Support (ALC) - Labeling of the TOE (ALC_CMC.1) - - TOE CM Coverage (ALC_CMS.1) - Timely Security Updates (ALC_TSU_EXT) - - Tests (ATE) - Independent Testing – Sample (ATE_IND.1) - - - Vulnerability Assessment (AVA) - Vulnerability Survey (AVA_VAN.1) - - - The ST is evaluated as per ASE - activities defined in the CEM for ASE_CCL.1, ASE_ECD.1, ASE_INT.1, ASE_OBJ.1, ASE_REQ.1, - ASE_SPD.1, and ASE_TSS.1. In addition, there may be Evaluation Activities specified within - that call for necessary descriptions to be included in the TSS - that are specific to the TOE technology type. - The design information about the TOE is - contained in the guidance documentation available to the end user as well as the TSS portion - of the ST, and any additional information required by this PP that is not to be made public. - - The functional specification describes the TOE Security Functions Interface (TSFIs). - It is not necessary to have a formal or - complete specification of these interfaces. Additionally, because TOEs conforming to - this PP will necessarily have interfaces to the Operational Environment that are not - directly invokable by TOE users, there is little point specifying that such interfaces - be described in and of themselves since only indirect testing of such interfaces may be - possible. For this PP, the activities for this family should focus on understanding the - interfaces presented in the TSS in response to the functional requirements and the - interfaces presented in the AGD documentation. - No additional "functional specification" - documentation is necessary to satisfy the evaluation activities specified. - - - The interfaces that need to be evaluated are characterized through - the information needed to perform the evaluation activities listed, rather than as an - independent, abstract list. - - The developer shall provide a functional specification. - - - The developer shall provide a tracing from the functional specification to the - SFRs. - As indicated in the introduction to this section, the - functional specification is comprised of the information contained in the AGD_OPE, - AGD_PRE, and the API information that is provided to application developers, including - the APIs that require privilege to invoke. The developer may - reference a website accessible to application developers and the evaluator. The API - documentation must include those interfaces required in this profile. The API - documentation must clearly indicate to which products and versions each available - function applies. The evaluation activities in the functional - requirements point to evidence that should exist in the documentation and TSS section; - since these are directly associated with the SFRs, the tracing in element ADV_FSP.1.2D - is implicitly already done and no additional documentation is necessary. - - - The functional specification shall describe the purpose and method of use for - each SFR-enforcing and SFR-supporting TSFI. - - - The functional specification shall identify all parameters associated with each - SFR-enforcing and SFR-supporting TSFI. - - - The functional specification shall provide rationale for the implicit - categorization of interfaces as SFR-non-interfering. - - - The tracing shall demonstrate that the SFRs trace to - TSFIs in the functional specification. - - - The evaluator shall confirm that the information provided meets all requirements - for content and presentation of evidence. - - - The evaluator shall determine that the functional specification is an accurate - and complete instantiation of the SFRs. - There are no specific evaluation activities associated with these SARs, except - ensuring the information is provided. The functional specification documentation is - provided to support the evaluation activities described in , - and other activities described for AGD, ATE, and AVA SARs. The requirements on the - content of the functional specification information is implicitly assessed by virtue - of the other evaluation activities being performed; if the evaluator is unable to - perform an activity because there is insufficient interface information, then an - adequate functional specification has not been provided. - - - - The guidance documents will be - provided with the ST. Guidance must include a description of how the IT personnel verifies - that the Operational Environment can fulfill its role for the security functionality. The - documentation should be in an informal style and readable by the IT personnel. - Guidance must be provided for every operational environment that the - product supports as claimed in the ST. This guidance includes: - Instructions to successfully install the TSF in that environment - Instructions to manage the security of the TSF as a product and as a component of - the larger operational environment - Instructions to provide a protected administrative capability - - Guidance pertaining to particular security functionality is also provided; - requirements on such guidance are contained in the evaluation activities specified with each - requirement. - - The developer shall provide operational user guidance. - The operational user guidance does not have to be contained in - a single document. Guidance to users, administrators and application developers can be - spread among documents or web pages. Where appropriate, the guidance documentation is - expressed in the eXtensible Configuration Checklist Description Format (XCCDF) to - support security automation. Rather than repeat information here, - the developer should review the evaluation activities for this component to ascertain - the specifics of the guidance that the evaluator will be checking for. This will - provide the necessary information for the preparation of acceptable guidance. - - - The operational user guidance shall describe, for each user role, the - user-accessible functions and privileges that should be controlled in a secure - processing environment, including appropriate warnings. - User and administrator (e.g., MDM agent), and application - developer are to be considered in the definition of user role. - - - The operational user guidance shall describe, for each user role, how to use the - available interfaces provided by the TOE in a secure manner. - - - The operational user guidance shall describe, for each user role, the available - functions and interfaces, in particular all security parameters under the control of - the user, indicating secure values as appropriate. - - - The operational user guidance shall, for each user role, clearly present each - type of security-relevant event relative to the user-accessible functions that need to - be performed, including changing the security characteristics of entities under the - control of the TSF. - - - The operational user guidance shall identify all possible modes of operation of - the OS (including operation following failure or operational error), their - consequences, and implications for maintaining secure operation. - - - The operational user guidance shall, for each user role, describe the security - measures to be followed in order to fulfill the security objectives for the - operational environment as described in the ST. - - - The operational user guidance shall be clear and reasonable. - - - The evaluator shall confirm that the information provided meets all requirements - for content and presentation of evidence. - Some of the contents of the operational guidance are verified by the - evaluation activities in and evaluation of the TOE according to - the . The following additional information is also required. - The operational guidance shall contain a list of natively installed - applications and any relevant version numbers. If any third party vendors are - permitted to install applications before purchase by the end user or enterprise, these - applications shall also be listed. The operational guidance shall - contain instructions for configuring the cryptographic engine associated with the - evaluated configuration of the TOE. It shall provide a warning to the administrator - that use of other cryptographic engines was not evaluated nor tested during the CC - evaluation of the TOE. The documentation must describe the process - for verifying updates to the TOE by verifying a digital signature. The evaluator shall - verify that this process includes the following steps: - Instructions for obtaining the update itself. This should include - instructions for making the update accessible to the TOE (e.g., placement in a - specific directory). - Instructions for initiating the update process, as well as discerning - whether the process was successful or unsuccessful. This includes generation of - the hash/digital signature. - The TOE will likely contain security functionality that does not fall in the - scope of evaluation under this PP. The operational guidance shall make it clear to an - administrator which security functionality is covered by the evaluation activities. - - - - - - The developer shall provide the TOE, including its preparative - procedures. - As with the operational guidance, the developer should look to - the evaluation activities to determine the required content with respect to preparative - procedures. - - - The preparative procedures shall describe all the steps necessary for secure - acceptance of the delivered TOE in accordance with the developer's delivery - procedures. - - - The preparative procedures shall describe all the steps necessary for secure - installation of the TOE and for the secure preparation of the operational environment - in accordance with the security objectives for the operational environment as - described in the ST. - - - The evaluator shall confirm that the information provided meets all requirements - for content and presentation of evidence. - - - The evaluator shall apply the preparative procedures to confirm that the OS can - be prepared securely for operation. - As indicated in the introduction above, there are significant expectations - with respect to the documentation—especially when configuring the operational - environment to support TOE functional requirements. The evaluator shall check to - ensure that the guidance provided for the TOE adequately addresses all platforms - claimed for the TOE in the ST. - - - - At the assurance level provided - for TOEs conformant to this PP, life-cycle support is limited to end-user-visible aspects of - the life-cycle, rather than an examination of the TOE vendor’s development and configuration - management process. This is not meant to diminish the critical role that a developer’s - practices play in contributing to the overall trustworthiness of a product; rather, it is a - reflection on the information to be made available for evaluation at this assurance level. - - This component is targeted at identifying the TOE such that it can be - distinguished from other products or versions from the same vendor and can be easily - specified when being procured by an end user. - - The developer shall provide the TOE and a reference for the TOE. - - - The TOE shall be labeled with a unique reference. - - - The evaluator shall confirm that the information provided meets all requirements - for content and presentation of evidence. - The evaluator shall check the ST to ensure that it contains an identifier - (such as a product name/version number) that specifically identifies the version that - meets the requirements of the ST. Further, the evaluator shall check the AGD guidance - and TOE samples received for testing to ensure that the version number is consistent - with that in the ST. If the vendor maintains a web site advertising the TOE, the - evaluator shall examine the information on the web site to ensure that the information - in the ST is sufficient to distinguish the product. - - - - Given the scope of the TOE and its associated evaluation evidence requirements, - this component’s evaluation activities are covered by the evaluation activities listed for - ALC_CMC.1. - - The developer shall provide a configuration list for the TOE. - - - The configuration list shall include the following: the TOE itself; and the - evaluation evidence required by the SARs. - - - The configuration list shall uniquely identify the configuration items. - - - The evaluator shall confirm that the information provided meets all requirements - for content and presentation of evidence. - The "evaluation evidence required by the SARs" in this PP is - limited to the information in the ST coupled with the guidance provided to - administrators and users under the AGD requirements. By ensuring that the TOE is - specifically identified and that this identification is consistent in the ST and in - the AGD guidance (as done in the evaluation activity for ALC_CMC.1), the evaluator - implicitly confirms the information required by this component. - Life-cycle support is targeted aspects of the developer’s life-cycle and instructions - to providers of applications for the developer’s devices, rather than an in-depth - examination of the TSF manufacturer’s development and configuration management - process. This is not meant to diminish the critical role that a developer’s practices - play in contributing to the overall trustworthiness of a product; rather, it’s a - reflection on the information to be made available for evaluation. - The evaluator shall ensure that the developer has identified (in - public-facing development guidance for their platform) one or more development - environments appropriate for use in developing applications for the developer’s - platform. For each of these development environments, the developer shall provide - information on how to configure the environment to ensure that buffer overflow - protection mechanisms in the environments are invoked (e.g., compiler and linker - flags). The evaluator shall ensure that this documentation also includes an indication - of whether such protections are on by default, or have to be specifically enabled. - The evaluator shall ensure that the TSF is uniquely identified - (with respect to other products from the TSF vendor), and that documentation provided - by the developer in association with the requirements in the ST is associated with the - TSF using this unique identification. - - - - This component requires the TOE developer, in conjunction with any other - necessary parties, to provide information as to how the end-user devices are updated to - address security issues in a timely manner. The documentation describes the process of - providing updates to the public from the time a security flaw is reported/discovered, to - the time an update is released. This description includes the parties involved (e.g., - the developer, cellular carriers) and the steps that are performed (e.g., developer testing, - carrier testing), including worst-case time periods, before an update is made available - to the public. - - The developer shall provide a description in the TSS of how timely security - updates are made to the TOE. - - - The description shall include the process for creating and deploying security - updates for the TOE software. - The software to be described includes the operating systems of the application - processor and the baseband processor, as well as any firmware and applications. The - process description includes the TOE developer processes as well as any third-party - (carrier) processes. The process description includes each deployment mechanism (e.g., - over-the-air updates, per-carrier updates, downloaded updates). - - - The description shall express the time window as the length of time, in days, - between public disclosure of a vulnerability and the public availability of security - updates to the TOE. - The total length of time may be presented as a summation of the periods of time - that each party (e.g., TOE developer, mobile carrier) on the critical path consumes. - The time period until public availability per deployment mechanism may differ; each is - described. - - - The description shall include the mechanisms publicly available for reporting - security issues pertaining to the TOE. - The reporting mechanism could include web sites, email addresses, as well as a - means to protect the sensitive nature of the report (e.g., public keys that could be - used to encrypt the details of a proof-of-concept exploit). - - - The description shall include where users can seek information about the - availability of new updates including details (e.g. CVE identifiers) of the specific - public vulnerabilities corrected by each update. - The purpose of providing this information is so that users and enterprises can - determine which devices are susceptible to publicly known vulnerabilities so that they - can make appropriate risk decisions, such as limiting access to enterprise resources - until updates are installed. - - - The evaluator shall confirm that the information provided meets all requirements - for content and presentation of evidence. - The evaluator shall verify that the TSS contains a description of the timely - security update process used by the developer to create and deploy security updates. - The evaluator shall verify that this description addresses the TOE OS, the firmware, - and bundled applications, each. The evaluator shall also verify that, in addition to - the TOE developer’s process, any carrier or other third-party processes are also - addressed in the description. The evaluator shall also verify that each mechanism for - deployment of security updates is described. The evaluator shall - verify that, for each deployment mechanism described for the update process, the TSS - lists a time between public disclosure of a vulnerability and public availability of - the security update to the TOE patching this vulnerability, to include any third-party - or carrier delays in deployment. The evaluator shall verify that this time is - expressed in a number or range of days. The evaluator shall verify - that this description includes the publicly available mechanisms (including either an - email address or website) for reporting security issues related to the TOE. The - evaluator shall verify that the description of this mechanism includes a method for - protecting the report either using a public key for encrypting email or a trusted - channel for a website. The evaluator shall verify that the - description includes where users can seek information about the availability of new - security updates including details of the specific public vulnerabilities corrected by - each update. The evaluator shall verify that the description includes the minimum - amount of time that the TOE is expected to be supported with security updates, and the - process by which users can seek information about when the TOE is no longer expected - to receive security updates. - - - - Testing is specified for functional aspects of - the system as well as aspects that take advantage of design or implementation weaknesses. - The former is done through the ATE_IND family, while the latter is through the AVA_VAN - family. At the assurance level specified in this PP, testing is based on advertised - functionality and interfaces with dependency on the availability of design information. One - of the primary outputs of the evaluation process is the test report as specified in the - following requirements. Since many of the APIs are not exposed at the - user interface (e.g., touch screen), the ability to stimulate the necessary interfaces - requires a developer’s test environment. This test environment will allow the evaluator, for - example, to access APIs and view file system information that is not available on consumer - Mobile Devices. - - Testing is performed to confirm the functionality described in the TSS as well as - the administrative (including configuration and operational) documentation provided. - The focus of the testing is to confirm that the requirements specified in - being met, although some additional testing is specified for SARs in - . - The Evaluation Activities identify the additional testing - activities associated with these components. - The evaluator produces a test report - documenting the plan for and results of testing, as well as coverage arguments focused - on the platform/TOE combinations that are claiming conformance to this PP. - - The developer shall provide the TOE for testing. - - - The TOE shall be suitable for testing. - - - The evaluator shall confirm that the information provided meets - all requirements for content and presentation of evidence. - - - The evaluator shall test a subset of the TSF to confirm that the TSF operates as - specified. - The evaluator shall prepare a test plan and report documenting the testing - aspects of the system. The test plan covers all of the testing actions contained in - the and the body of this PP’s Evaluation Activities. While it is - not necessary to have one test case per test listed in an evaluation activity, the - evaluator must document in the test plan that each applicable testing requirement in - the ST is covered. The test plan identifies the platforms to be - tested, and for those platforms not included in the test plan but included in the ST, - the test plan provides a justification for not testing the platforms. This - justification must address the differences between the tested platforms and the - untested platforms, and make an argument that the differences do not affect the - testing to be performed. It is not sufficient to merely assert that the differences - have no affect; rationale must be provided. If all platforms claimed in the ST are - tested, then no rationale is necessary. The test plan describes the - composition of each platform to be tested, and any setup that is necessary beyond what - is contained in the AGD documentation. It should be noted that the evaluator is - expected to follow the AGD documentation for installation and setup of each platform - either as part of a test or as a standard pre-test condition. This may include special - test drivers or tools. For each driver or tool, an argument (not just an assertion) - should be provided that the driver or tool will not adversely affect the performance - of the functionality by the TOE and its platform. This also includes the configuration - of the cryptographic engine to be used. The cryptographic algorithms implemented by - this engine are those specified by this PP and used by the cryptographic protocols - being evaluated (IPsec, TLS/HTTPS, SSH). The test plan identifies - high-level test objectives as well as the test procedures to be followed to achieve - those objectives. These procedures include expected results. The test report (which - could just be an annotated version of the test plan) details the activities that took - place when the test procedures were executed, and includes the actual results of the - tests. This shall be a cumulative account, so if there was a test run that resulted in - a failure; a fix installed; and then a successful re-run of the test, the report would - show a "fail" and "pass" result (and the supporting details), and not just the "pass" - result. - - - - For the current generation - of this protection profile, the evaluation lab is expected to survey open sources to - discover what vulnerabilities have been discovered in these types of products. In most - cases, these vulnerabilities will require sophistication beyond that of a basic attacker. - Until penetration tools are created and uniformly distributed to the evaluation labs, the - evaluator will not be expected to test for these vulnerabilities in the TOE. The labs will - be expected to comment on the likelihood of these vulnerabilities given the documentation - provided by the vendor. This information will be used in the development of penetration - testing tools and for the development of future protection profiles. - - - The developer shall provide the TOE for testing. - - - The TOE shall be suitable for testing. - - - The evaluator shall confirm that the information provided meets all requirements - for content and presentation of evidence. - - - The evaluator shall perform a search of public domain sources to identify - potential vulnerabilities in the TOE. - Public domain sources include the Common Vulnerabilities and - Exposures (CVE) dictionary for publicly-known vulnerabilities. - - - The evaluator shall conduct penetration testing, based on the identified - potential vulnerabilities, to determine that the TOE is resistant to attacks performed - by an attacker possessing Basic attack potential. - The evaluator shall generate a report to document their findings with respect - to this requirement. This report could physically be part of the overall test report - mentioned in ATE_IND, or a separate document. The evaluator performs a search of - public information to find vulnerabilities that have been found in mobile devices and - the implemented communication protocols in general, as well as those that pertain to - the particular TOE. The evaluator documents the sources consulted and the - vulnerabilities found in the report. For each vulnerability found, - the evaluator either provides a rationale with respect to its non-applicability, or - the evaluator formulates a test (using the guidelines provided in ATE_IND) to confirm - the vulnerability, if suitable. Suitability is determined by assessing the attack - vector needed to take advantage of the vulnerability. If exploiting the vulnerability - requires expert skills and an electron microscope, for instance, then a test would not - be suitable and an appropriate justification would be formulated. - - - -
    - - - - - - - Requirement - Rationale for Satisfaction - - - FAU_SEL.1 - Selective Audit - FAU_SEL.1 has a dependency on FMT_MTD.1 since configuration of audit data is a subset of managing TSF data. This dependency is met by FMT_SMF.1, which +
    + + : Security Assurance Requirements The ST is evaluated as per ASE activities defined in the CEM for ASE_CCL.1, ASE_ECD.1, ASE_INT.1, ASE_OBJ.1, ASE_REQ.1, ASE_SPD.1, and ASE_TSS.1. In addition, there may be Evaluation Activities specified within that call for necessary descriptions to be included in the TSS that are specific to the TOE technology type. The design information about the TOE is contained in the guidance documentation available to the end user as well as the TSS portion of the ST, and any additional information required by this PP that is not to be made public. The guidance documents will be provided with the ST. Guidance must include a description of how the IT personnel verifies that the Operational Environment can fulfill its role for the security functionality. The documentation should be in an informal style and readable by the IT personnel. Guidance must be provided for every operational environment that the product supports as claimed in the ST. This guidance includes:
  • Instructions to successfully install the TSF in that environment
  • Instructions to manage the security of the TSF as a product and as a component of the larger operational environment
  • Instructions to provide a protected administrative capability Guidance pertaining to particular security functionality is also provided; requirements on such guidance are contained in the evaluation activities specified with each requirement. At the assurance level provided for TOEs conformant to this PP, life-cycle support is limited to end-user-visible aspects of the life-cycle, rather than an examination of the TOE vendor’s development and configuration management process. This is not meant to diminish the critical role that a developer’s practices play in contributing to the overall trustworthiness of a product; rather, it is a reflection on the information to be made available for evaluation at this assurance level. Testing is specified for functional aspects of the system as well as aspects that take advantage of design or implementation weaknesses. The former is done through the ATE_IND family, while the latter is through the AVA_VAN family. At the assurance level specified in this PP, testing is based on advertised functionality and interfaces with dependency on the availability of design information. One of the primary outputs of the evaluation process is the test report as specified in the following requirements. Since many of the APIs are not exposed at the user interface (e.g., touch screen), the ability to stimulate the necessary interfaces requires a developer’s test environment. This test environment will allow the evaluator, for example, to access APIs and view file system information that is not available on consumer Mobile Devices. For the current generation of this protection profile, the evaluation lab is expected to survey open sources to discover what vulnerabilities have been discovered in these types of products. In most cases, these vulnerabilities will require sophistication beyond that of a basic attacker. Until penetration tools are created and uniformly distributed to the evaluation labs, the evaluator will not be expected to test for these vulnerabilities in the TOE. The labs will be expected to comment on the likelihood of these vulnerabilities given the documentation provided by the vendor. This information will be used in the development of penetration testing tools and for the development of future protection profiles. + +
    + + RequirementRationale for SatisfactionFAU_SEL.1 - Selective AuditFAU_SEL.1 has a dependency on FMT_MTD.1 since configuration of audit data is a subset of managing TSF data. This dependency is met by FMT_SMF.1, which defines "configure the auditable items" as a management function and specifies the roles that may perform this, consistent with how FMT_MTD.1 would typically satisfy the dependency. - - - - FCS_CKM.1 - Cryptographic Key Generation - FCS_CKM.1 has a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF generates. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose. - - - FCS_CKM.1 - Cryptographic Key Generation - FCS_CKM.1 has a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF generates. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2 equivalent. - - - FCS_CKM.2 - Cryptographic Key Establishment - Both iterations of FCS_CKM.2 have a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF establishes. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose - as its CC Part 2 equivalent. - - - FCS_COP.1 - Cryptographic Operation - All iterations of FCS_COP.1 have a dependency on FCS_CKM.4 for the subsequent destruction of any residual key material the TSF creates as part of the operation. - This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2 equivalent. - - - - FCS_STG_EXT.1 - Cryptographic Key Storage - FCS_STG_EXT.1 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. - This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF. - - - FDP_ACF_EXT.1 - Access Control for System Services - FDP_ACF_EXT.1 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. - This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF. - - - FDP_ACF_EXT.2 - Access Control for System Resources - FDP_ACF_EXT.2 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. - This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF. - - - FIA_AFL_EXT.1 - Authentication Failure Handling - FIA_AFL_EXT.1 has a dependency on FIA_UAU.1 since handling of authentication failures is not possible without an authentication mechanism. This dependency is met - by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent. - - - FIA_PMG_EXT.1 - Password Management - FIA_PMG_EXT.1 has a dependency on FIA_UAU.1 since composition of authentication credentials is not possible without an authentication mechanism. This dependency is met - by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent. - - - FIA_UAU.7 - Protected Authentication Feedback - FIA_UAU.7 has a dependency on FIA_UAU.1 since protected authentication feedback is not possible without an authentication mechanism. This dependency is met - by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent. - - - FMT_SMF_EXT.3 - Current Administrator - FMT_SMF_EXT.3 has a dependency on FMT_SMR.1 through its reference to management roles in the requirement text. - This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF. - - - - - + FCS_CKM.1 - Cryptographic Key GenerationFCS_CKM.1 has a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF generates. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose.FCS_CKM.1 - Cryptographic Key GenerationFCS_CKM.1 has a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF generates. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2 equivalent.FCS_CKM.2 - Cryptographic Key EstablishmentBoth iterations of FCS_CKM.2 have a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF establishes. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose + as its CC Part 2 equivalent.FCS_COP.1 - Cryptographic OperationAll iterations of FCS_COP.1 have a dependency on FCS_CKM.4 for the subsequent destruction of any residual key material the TSF creates as part of the operation. + This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2 equivalent.FCS_STG_EXT.1 - Cryptographic Key StorageFCS_STG_EXT.1 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. + This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF.FDP_ACF_EXT.1 - Access Control for System ServicesFDP_ACF_EXT.1 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. + This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF.FDP_ACF_EXT.2 - Access Control for System ResourcesFDP_ACF_EXT.2 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. + This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF.FIA_AFL_EXT.1 - Authentication Failure HandlingFIA_AFL_EXT.1 has a dependency on FIA_UAU.1 since handling of authentication failures is not possible without an authentication mechanism. This dependency is met + by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent.FIA_PMG_EXT.1 - Password ManagementFIA_PMG_EXT.1 has a dependency on FIA_UAU.1 since composition of authentication credentials is not possible without an authentication mechanism. This dependency is met + by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent.FIA_UAU.7 - Protected Authentication FeedbackFIA_UAU.7 has a dependency on FIA_UAU.1 since protected authentication feedback is not possible without an authentication mechanism. This dependency is met + by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent.FMT_SMF_EXT.3 - Current AdministratorFMT_SMF_EXT.3 has a dependency on FMT_SMR.1 through its reference to management roles in the requirement text. + This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF. + The documentation of the entropy source should be detailed enough that, after reading, the evaluator will thoroughly understand the entropy source and why it can be relied upon to provide entropy. This @@ -11580,13 +5993,12 @@ The evaluator shall exercise the TSF configuration as the administrator and the raw outputs (hash, XOR, etc.), if/where it is stored, and finally, how it is output from the entropy source. Any conditions placed on the process (e.g., blocking) should also be described in the entropy source design. Diagrams and examples are encouraged. - This design must also include a description of the content of the security + This design must also include a description of the content of the security boundary of the entropy source and a description of how the security boundary ensures that an - adversary outside the boundary cannot affect the entropy rate. If + adversary outside the boundary cannot affect the entropy rate. If implemented, the design description shall include a description of how third-party applications can add entropy to the RBG. A description of any RBG state saving between - power-off and power-on shall be included.
    -
    + power-off and power-on shall be included.
    There should be a technical argument for where the unpredictability in the source comes from and why there is confidence in the entropy source exhibiting probabilistic behavior (an explanation of the probability @@ -11594,733 +6006,48 @@ The evaluator shall exercise the TSF configuration as the administrator and describe this). This argument will include a description of the expected entropy rate and explain how you ensure that sufficient entropy is going into the TOE randomizer seeding process. This discussion will be part of a justification for why the entropy source can be - relied upon to produce bits with entropy. The entropy justification shall + relied upon to produce bits with entropy. The entropy justification shall not include any data added from any third-party application or from any state saving between - restarts.
    -
    + restarts.
    Documentation will also include the range of operating conditions under which the entropy source is expected to generate random data. It will clearly describe the measures that have been taken in the system design to ensure the entropy source continues to operate under those conditions. Similarly, documentation shall describe the conditions under which the entropy source is known to malfunction or become - inconsistent. Methods used to detect failure or degradation of the source shall be included.
    -
    + inconsistent. Methods used to detect failure or degradation of the source shall be included.
    More specifically, all entropy source health tests and their rationale will be documented. This will include a description of the health tests, the rate and conditions under which each health test is performed (e.g., at startup, continuously, or on-demand), the expected results for each health test, and rationale indicating why each test is believed to be appropriate for detecting one or more failures in - the entropy source.
    - - - - - : References and IV Requirements for NIST-approved Cipher - Modes - - - Cipher Mode - Reference - IV Requirements - - - Electronic Codebook (ECB) - SP 800-38A - No IV - - - Counter (CTR) - SP 800-38A - "Initial Counter" shall be non-repeating. No counter value shall be repeated across - multiple messages with the same secret key. - - - Cipher Block Chaining (CBC) - SP 800-38A - IVs shall be unpredictable. Repeating IVs leak information about whether the first - one or more blocks are shared between two messages, so IVs should be non-repeating in such - situations. - - - Output Feedback (OFB) - SP 800-38A - IVs shall be non-repeating and shall not be generated by invoking the cipher on - another IV. - - - Cipher Feedback (CFB) - SP 800-38A - IVs should be non-repeating as repeating IVs leak information about the first - plaintext block and about common shared prefixes in messages. - - - XEX (XOR Encrypt XOR) Tweakable Block Cipher with Ciphertext Stealing (XTS) - SP 800-38E - No IV. Tweak values shall be non-negative integers, assigned consecutively, and - starting at an arbitrary non-negative integer. - - - Cipher-based Message Authentication Code (CMAC) - SP 800-38B - No IV - - - Key Wrap and Key Wrap with Padding - SP 800-38F - No IV - - - Counter with CBC-Message Authentication Code (CCM) - SP 800-38C - No IV. Nonces shall be non-repeating. - - - Galois Counter Mode (GCM) - SP 800-38D - IV shall be non-repeating. The number of invocations of GCM shall not exceed - $2^{32}$ for a given secret key unless an implementation only uses 96-bit IVs (default - length). - - - - - - This protection profile was developed by the Mobility Technical Community with representatives from industry, U.S. Government agencies, Common Criteria Test Laboratories, and international Common Criteria schemes. The National Information Assurance Partnership wishes to acknowledge and thank the members of this group whose dedicated efforts contributed significantly to the publication. These organizations include: - - U.S. Government - Defense Information Systems Agency (DISA) - CyberSecurity Directorate (CSD) - National Information Assurance Partnership (NIAP) - National Institute of Standards and Technology (NIST) - - International Common Criteria Schemes - Australian Information Security Evaluation Program (AISEP) - Canadian Common Criteria Evaluation and Certification Scheme (CSEC) - Information-technology Promotion Agency, Japan (IPA) - UK IT Security Evaluation and Certificate Scheme (NCSC) - - Industry - Apple, Inc. - BlackBerry - LG Electronics, Inc. - Microsoft Corporation - Motorola Solutions - Samsung Electronics Co., Ltd. - Other Members of the Mobility Technical Community - - Common Criteria Test Laboratories - EWA-Canada, Ltd. - Gossamer Security Solutions - - - - - - - If the TOE includes Bluetooth hardware, the following SFRs must be claimed: - - - + the entropy source.
    • + + This protection profile was developed by the Mobility Technical Community with representatives from industry, U.S. Government agencies, Common Criteria Test Laboratories, and international Common Criteria schemes. The National Information Assurance Partnership wishes to acknowledge and thank the members of this group whose dedicated efforts contributed significantly to the publication. These organizations include: U.S. Government + Defense Information Systems Agency (DISA) + CyberSecurity Directorate (CSD) + National Information Assurance Partnership (NIAP) + National Institute of Standards and Technology (NIST)International Common Criteria Schemes + Australian Information Security Evaluation Program (AISEP) + Canadian Common Criteria Evaluation and Certification Scheme (CSEC) + Information-technology Promotion Agency, Japan (IPA) + UK IT Security Evaluation and Certificate Scheme (NCSC)Industry + Apple, Inc. + BlackBerry + LG Electronics, Inc. + Microsoft Corporation + Motorola Solutions + Samsung Electronics Co., Ltd. + Other Members of the Mobility Technical CommunityCommon Criteria Test Laboratories + EWA-Canada, Ltd. + Gossamer Security Solutions - - CEM - - Common + + + CEM + Common Evaluation Methodology for Information Technology Security - Evaluation Methodology, CCMB-2012-09-004, Version 3.1, Revision 5, April 2017. - - - - + +     - - - - - - - - - From f0cfa0fcf557c4a628b4a7028a66e633beca466f Mon Sep 17 00:00:00 2001 From: jpham-mitre Date: Mon, 12 Aug 2024 17:39:22 -0400 Subject: [PATCH 13/13] Reverted recent change --- input/mobile-device.xml | 10683 ++++++++++++++++++++++++++++++-------- 1 file changed, 8478 insertions(+), 2205 deletions(-) diff --git a/input/mobile-device.xml b/input/mobile-device.xml index 99f6be64..d79bf295 100644 --- a/input/mobile-device.xml +++ b/input/mobile-device.xml @@ -1,14 +1,83 @@ - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Mobile Device Fundamentals 3.3 - NIAP + National Information Assurance Partnership 2022-09-12 - application; software + ?? @@ -20,32 +89,104 @@ 1.1 2014-01-12 - Typographical changes and additional clarifications in application notes. Removedassignment from FCS_TLS_EXT.1 and limited testing to those ciphersuites in bothFCS_TLS_EXT.1 and FCS_TLS_EXT.2. + Typographical changes and additional clarifications in application notes. Removed + assignment from FCS_TLS_EXT.1 and limited testing to those ciphersuites in both + FCS_TLS_EXT.1 and FCS_TLS_EXT.2. 2.0 2015-09-14 - Included changes based on Technical Rapid Response Team Decisions. Clarified manyrequirements and evaluation activities. Mandated objective requirements:Application Access Control (FDP_ACF_EXT.1.2)VPN Information Flow Control (FDP_IFC_EXT.1) Added new objective requirements:Suite B cryptography for IEEE 802.11Certificate enrollmentProtection of additional key material typesHeap overflow protectionBluetooth requirementsCryptographic operation services for applicationsRemote Attestation (FPT_NOT_EXT.1) Added transition dates for some objective requirements. Includedhardware-isolated REK and key storage selections. Allowed key derivation byREK. Clarified FTP_ITC_EXT.1 and added FDP_UPC_EXT.1. Mandated HTTPS andTLS for application use. (FDP_UPC_EXT.1) Removed Dual_EC_DRBG as an approvedDRBG. Adopted new TLS requirements. Mandated TSF Wipe upon authenticationfailure limit and required number of authentication failures be maintained acrossreboot. Clarified Management Class. Included more domain isolationdiscussion and tests. Updated Audit requirements and added Auditable Eventstable. Added SFR Category Mapping Table. Updated Use CaseTemplates. Moved Glossary to Introduction. + Included changes based on Technical Rapid Response Team Decisions. Clarified many + requirements and evaluation activities. Mandated objective requirements: + + Application Access Control (FDP_ACF_EXT.1.2) + VPN Information Flow Control (FDP_IFC_EXT.1) + Added new objective requirements: + + Suite B cryptography for IEEE 802.11 + Certificate enrollment + Protection of additional key material types + Heap overflow protection + Bluetooth requirements + Cryptographic operation services for applications + Remote Attestation (FPT_NOT_EXT.1) + Added transition dates for some objective requirements. Included + hardware-isolated REK and key storage selections. Allowed key derivation by + REK. Clarified FTP_ITC_EXT.1 and added FDP_UPC_EXT.1. Mandated HTTPS and + TLS for application use. (FDP_UPC_EXT.1) Removed Dual_EC_DRBG as an approved + DRBG. Adopted new TLS requirements. Mandated TSF Wipe upon authentication + failure limit and required number of authentication failures be maintained across + reboot. Clarified Management Class. Included more domain isolation + discussion and tests. Updated Audit requirements and added Auditable Events + table. Added SFR Category Mapping Table. Updated Use Case + Templates. Moved Glossary to Introduction. 3.0 2015-09-17 - Included changes based on Technical Rapid Response Team Decisions. Clarifiedmany requirements and evaluation activities. Mandated objective requirements:Generation of Audit Records (FAU_GEN.1)Audit Storage Protection (FAU_STG.1)Audit Storage Overwrite (FAU_STG.4)Lock Screen DAR (FDP_DAR_EXT.2)Discard Bluetooth Connection Attempts from Bluetooth Addresses with ExistingConnection (FIA_BLT_EXT.3)JTAG Disablement (FPT_JTA) Added new objective requirements:Application BackupBiometric Authentication FactorAccess ControlUser AuthenticationBluetooth Encryption WLAN client requirements moved to Extended Package for WLAN Client. AddedSFRs to support BYOD Use Case BYOD Use Case Updated key destruction SFR + Included changes based on Technical Rapid Response Team Decisions. Clarified + many requirements and evaluation activities. Mandated objective requirements: + + Generation of Audit Records (FAU_GEN.1) + Audit Storage Protection (FAU_STG.1) + Audit Storage Overwrite (FAU_STG.4) + Lock Screen DAR (FDP_DAR_EXT.2) + Discard Bluetooth Connection Attempts from Bluetooth Addresses with Existing + Connection (FIA_BLT_EXT.3) + JTAG Disablement (FPT_JTA) + Added new objective requirements: + + Application Backup + Biometric Authentication Factor + Access Control + User Authentication + Bluetooth Encryption + WLAN client requirements moved to Extended Package for WLAN Client. Added + SFRs to support BYOD Use Case BYOD Use Case Updated key destruction SFR + 3.1 2017-04-05 - Included changes based on Technical Rapid Response Team Decisions and incorporatedTechnical Decisions. Modified biometric requirements: FIA_UAU.5 - Added iris, face, voice and vein as supported modalities, in additionto fingerprint (allowed in version 3)FIA_BMG_EXT.1.1 - Clarified AA to specify that vendor evidence is acceptable andexpectations of evidence provided. FIA_BMG_EXT.1.2 - SAFAR was changed to an assignment of a SAFAR no greater than1:500. FIA_AFL_EXT.1 - Updated to allow each biometric modality to utilize an individualor shared counter. FCS_TLSC_EXT.1.1 - Removed TLS ciphersuites that utilized SHA1 and updatedoptional ciphersuites to be uniformed across PPs. FCS_STG_EXT.2.2 - Modified torequire long term trusted channel key material be encrypted by an approved method.FIA_UAU_EXT.1.1 - Modified to allow the long term trusted channel key material to beavailable prior to password being entered at start-up. + Included changes based on Technical Rapid Response Team Decisions and incorporated + Technical Decisions. Modified biometric requirements: + FIA_UAU.5 - Added iris, face, voice and vein as supported modalities, in addition + to fingerprint (allowed in version 3) + FIA_BMG_EXT.1.1 - Clarified AA to specify that vendor evidence is acceptable and + expectations of evidence provided. + FIA_BMG_EXT.1.2 - SAFAR was changed to an assignment of a SAFAR no greater than + 1:500. + FIA_AFL_EXT.1 - Updated to allow each biometric modality to utilize an individual + or shared counter. + FCS_TLSC_EXT.1.1 - Removed TLS ciphersuites that utilized SHA1 and updated + optional ciphersuites to be uniformed across PPs. FCS_STG_EXT.2.2 - Modified to + require long term trusted channel key material be encrypted by an approved method. + FIA_UAU_EXT.1.1 - Modified to allow the long term trusted channel key material to be + available prior to password being entered at start-up. + 3.2 2021-04-15 - Removed TLS SFRs and utilized TLS Functional Package Removed Bluetooth SFRsand utilized Bluetooth Module. Bluetooth SFR moved to Implementation Dependent.FPT_TUD_EXT.4.2 renumbered to + Removed TLS SFRs and utilized TLS Functional Package Removed Bluetooth SFRs + and utilized Bluetooth Module. Bluetooth SFR moved to Implementation Dependent. + FPT_TUD_EXT.4.2 renumbered to + 3.3 2022-09-12 - Integrated Biometrics cPP Module, Included changes based on Technical Rapid Response Team Decisions and open issues from GitHub.Removed biometric definitions from Tech TermsRemoved FDP_PBARemoved FIA_BMGUpdated FIA_UAU.5 to support bio cPP moduleMoved FTA_TAB.1 to mandatoryMoved FAU_SAR.1 to mandatoryAdded ECDUpdated WLAN Client reference from Extended Package to ModuleRemoved Diffie-Hellman group 14 selection from FCS_CKM.1.1 and FCS_CKM.2.1/UNLOCKED + Integrated Biometrics cPP Module, Included changes based on Technical Rapid Response Team Decisions and open issues from GitHub. + Removed biometric definitions from Tech Terms + Removed FDP_PBA + Removed FIA_BMG + Updated FIA_UAU.5 to support bio cPP module + Moved FTA_TAB.1 to mandatory + Moved FAU_SAR.1 to mandatory + Added ECD + Updated WLAN Client reference from Extended Package to Module + Removed Diffie-Hellman group 14 selection from FCS_CKM.1.1 and FCS_CKM.2.1/UNLOCKED + @@ -55,527 +196,1749 @@ https://www.niap-ccevs.org/Profile/Info.cfm?PPID=439&id=439 - https://github.com/commoncriteria/vpnclientv2.4https://github.com/commoncriteria/bluetoothv1.0https://github.com/commoncriteria/mdmagentRelease-1.0https://github.com/commoncriteria/wlanclientrelease-1.0https://github.com/biometricITC/cPP-biometrics/blob/master/Protection%20Profile/BiocPP.adoc - - The scope of this Protection Profile (PP) is to describe the security functionality of mobile devices in terms of [CC] and to define functional and assurance requirements for such devices. - - An anti-exploitation feature, + + + + https://github.com/commoncriteria/vpnclient + v2.4 + + + + + + https://github.com/commoncriteria/bluetooth + v1.0 + + + + + + https://github.com/commoncriteria/mdmagent + Release-1.0 + + + + + + https://github.com/commoncriteria/wlanclient + release-1.0 + + + + + https://github.com/biometricITC/cPP-biometrics/blob/master/Protection%20Profile/BiocPP.adoc + + + + + +The scope of this Protection Profile (PP) is to describe the security functionality of mobile devices in terms of [CC] and to define functional and assurance requirements for such devices. + + + + + + An anti-exploitation feature, which loads memory mappings into unpredictable locations. ASLR makes it more difficult for an attacker to redirect control to code that they have introduced into the address space of - a process or the kernel. - The Administrator is responsible for management activities, + a process or the kernel. + The Administrator is responsible for management activities, including setting the policy that is applied by the enterprise on the Mobile Device. This administrator is likely to be acting remotely and could be the Mobile Device Management (MDM) Administrator acting through an MDM Agent. If the device is unenrolled, the user is - the administrator. - Auxiliary boot modes are states in which the device + the administrator. + + + + + + Auxiliary boot modes are states in which the device provides power to one or more components to provide an interface that enables an unauthenticated user to interact with either a specific component or several components that - exist outside of the device’s fully authenticated, operational state. - Authentication factor, which uses + exist outside of the device’s fully authenticated, operational state. + Authentication factor, which uses biometric sample, matched to a biometric authentication template to help establish - identity. - Application developers (or software companies) + identity. + + + + + + + + + + + + + + + Application developers (or software companies) often produce many applications under the same name. Mobile devices often allow shared - resources by such applications where otherwise resources would not be shared. - Security-related information whose + resources by such applications where otherwise resources would not be shared. + Security-related information whose disclosure or modification can compromise the security of a cryptographic module or - authentication system. - Program/application or data files that are stored or transmitted by a - server or Mobile Device (MD). - A key used to encrypt data-at-rest. - Developer modes are states in which additional services are - available to a user in order to provide enhanced system access for debugging of software. - These keys are stored in the main file system encrypted - by another key and can be changed and sanitized. - The state in which the Mobile Device is managed with active - policy settings from the administrator. - Enterprise data is any data residing in the enterprise servers, + authentication system. + Program/application or data files that are stored or transmitted by a + server or Mobile Device (MD). + A key used to encrypt data-at-rest. + Developer modes are states in which additional services are + available to a user in order to provide enhanced system access for debugging of software. + + + + + + + + These keys are stored in the main file system encrypted + by another key and can be changed and sanitized. + The state in which the Mobile Device is managed with active + policy settings from the administrator. + + + Enterprise data is any data residing in the enterprise servers, or temporarily stored on Mobile Devices to which the Mobile Device user is allowed access according to security policy defined by the enterprise and implemented by the - administrator. - These keys are stored in volatile memory. - A DEK used to encrypt a file or a director when - File Encryption is used. FEKs are unique to each encrypted file or directory. - The OS can only access these keys by reference, if - at all, during runtime. - A hybrid authentication factor is one where a user has to - submit a combination of a biometric sample and a PIN or password and both must pass. If either factor fails, the entire attempt fails. The user shall not be made aware of which factor failed, if either fails. - These keys are stored as hardware-protected raw key and - cannot be changed or sanitized. - The method of using multiple layers of encryption keys to protect + administrator. + These keys are stored in volatile memory. + + + + + + + + + + + + + + A DEK used to encrypt a file or a director when + File Encryption is used. FEKs are unique to each encrypted file or directory. + + + + The OS can only access these keys by reference, if + at all, during runtime. + + + + A hybrid authentication factor is one where a user has to + submit a combination of a biometric sample and a PIN or password and both must pass. If either factor fails, the entire attempt fails. The user shall not be made aware of which factor failed, if either fails. + These keys are stored as hardware-protected raw key and + cannot be changed or sanitized. + + + + + + The method of using multiple layers of encryption keys to protect data. A top layer key encrypts a lower layer key, which encrypts the data; this method can - have any number of layers. - A key used to encrypt other keys, such as DEKs or - storage that contains keys. - Powered on but most functionality is unavailable for use. User - authentication is required to access functionality. - A device which is composed of a hardware platform and + have any number of layers. + + A key used to encrypt other keys, such as DEKs or + storage that contains keys. + + Powered on but most functionality is unavailable for use. User + authentication is required to access functionality. + + + A device which is composed of a hardware platform and its system software. The device typically provides wireless connectivity and may include software for functions like secure messaging, email, web, VPN (Virtual Private Network) connection, and VoIP (Voice over IP), for access to the protected enterprise network, enterprise data and applications, - and for communicating to other Mobile Devices. - Mobile device management (MDM) products + and for communicating to other Mobile Devices. + Mobile device management (MDM) products allow enterprises to apply security policies to mobile devices. This system consists of two - primary components: the MDM Server and the MDM Agent. - The MDM Agent is installed on a Mobile Device as an application or is + primary components: the MDM Server and the MDM Agent. + + + + The MDM Agent is installed on a Mobile Device as an application or is part of the Mobile Device’s OS. The MDM Agent establishes a secure connection back to the - MDM Server controlled by the administrator. - Friction ridge characteristics that are used to individualize a + MDM Server controlled by the administrator. + Friction ridge characteristics that are used to individualize a fingerprint image. Minutia are the points where friction ridges begin, terminate, or split into two or more ridges. In many fingerprint systems, the minutia points are compared for - recognition purposes. - The individual authorized to physically control and + recognition purposes. + The individual authorized to physically control and operate the Mobile Device. Depending on the use case, this can be the device owner or an - individual authorized by the device owner. - A type or class of biometric system, such as fingerprint + individual authorized by the device owner. + A type or class of biometric system, such as fingerprint recognition, facial recognition, iris recognition, voice recognition, signature/sign, and - others. - These keys are stored as hardware-protected raw key and can - be changed or sanitized. - Software that runs at the highest privilege level + others. + These keys are stored as hardware-protected raw key and can + be changed or sanitized. + + + + + + Software that runs at the highest privilege level and can directly control hardware resources. Modern Mobile Devices typically have at least two primary operating systems: one, which runs on the application processor and one, which runs on the cellular baseband processor. The OS of the application processor handles most user interactions and provides the execution environment for apps. The OS of the cellular baseband processor handles communications with the cellular network and may control other peripherals. The term OS, without context, may be assumed to refer to the OS of the - application processor. - A type of authentication factor requiring the - user to provide a secret set of characters to gain access. - A PIN is a set of numeric or alphabetic characters that may be used + application processor. + + + + A type of authentication factor requiring the + user to provide a secret set of characters to gain access. + A PIN is a set of numeric or alphabetic characters that may be used in addition to a biometric factor to provide a hybrid authentication factor. At this time it is not considered as a stand-alone authentication mechanism. A PIN is distinct from a password in that the allowed character set and required length of a PIN - is typically smaller than that of a password as it is designed to be input quickly. - The device has been shut down such that no TOE function can be - performed. - Protected data is all non-TSF data, including all user - or enterprise data. Some or all of this data may be considered sensitive data as well. - A key tied to the device used to encrypt other - keys. - Sensitive data shall be identified in the TSS section of the + is typically smaller than that of a password as it is designed to be input quickly. + + + The device has been shut down such that no TOE function can be + performed. + + + + + + + Protected data is all non-TSF data, including all user + or enterprise data. Some or all of this data may be considered sensitive data as well. + + A key tied to the device used to encrypt other + keys. + + + + + Sensitive data shall be identified in the TSS section of the Security Target (ST) by the ST author. Sensitive data is a subset or all of the Protected data. Sensitive data may include all user or enterprise data or may be specific application data such as emails, messaging, documents, calendar items, and contacts. Sensitive data is - protected while in the locked state (FDP_DAR_EXT.2). - The OS access the raw bytes of these keys during runtime. - A list of trusted root Certificate Authority - certificates. - Data for the operation of the TSF upon which the enforcement of the - requirements relies. - The state in which the Mobile Device is not managed. - Powered on and device functionality is available for use. Implies - user authentication has occurred (when so configured). - A task where the biometric system attempts to confirm + protected while in the locked state (FDP_DAR_EXT.2). + + + The OS access the raw bytes of these keys during runtime. + + + + + + + + + + + A list of trusted root Certificate Authority + certificates. + Data for the operation of the TSF upon which the enforcement of the + requirements relies. + + + The state in which the Mobile Device is not managed. + Powered on and device functionality is available for use. Implies + user authentication has occurred (when so configured). + + + + A task where the biometric system attempts to confirm an individual’s claimed identity by comparing a submitted sample to one or more previously - enrolled authentication templates. - -
    This assurance standard specifies information security requirements for Mobile Devices for use in an enterprise. A Mobile Device in the context of this assurance standard is a device, which is composed of a hardware platform and its system software. The device typically provides wireless connectivity and may include software for functions like secure messaging, email, web, VPN connection, and VoIP (Voice over IP), for access to the protected enterprise network, enterprise data and applications, and for communicating to other Mobile Devices. illustrates the network operating environment of the Mobile Device.
    Examples of a "Mobile Device" that should claim conformance to this Protection Profile include smartphones, tablet computers, and other Mobile Devices with similar capabilities. The Mobile Device provides essential services, such as cryptographic services, data-at-rest protection, and key storage services to support the secure operation of applications on the device. Additional security features such as security policy enforcement, application mandatory access control, anti-exploitation features, user authentication, and software integrity protection are implemented in order to address threats. This assurance standard describes these essential security services provided by the Mobile Device and serves as a foundation for a secure mobile architecture. The wireless connectivity shall be validated against the . If the mobile device contains Bluetooth functionality (i.e., has Bluetooth hardware), the Bluetooth connectivity shall be evaluated against the . As illustrated in , it is expected that a typical deployment would also include either third-party or bundled components. Whether these components are bundled as part of the Mobile Device by the manufacturer or developed by a third-party, they must be separately validated against the related assurance standards such as the PP-Module for MDM Agent, PP-Module for VPN Client, PP-Module for VVoIP, and cPP-Module for Biometrics. It is the responsibility of the architect of the overall secure mobile architecture to ensure validation of these components. Additional applications that may come pre-installed on the Mobile Device that are not validated are considered to be potentially flawed, but not malicious. Examples include email client and web browser.
    - - The Mobile Device may be operated in a number of use cases. provides use case templates that list those selections, assignments, and objective requirements that best support the use cases identified by this Protection Profile. In addition to providing essential security services, the Mobile Device includes the necessary security functionality to support configurations for these various use cases. Each use case may require additional configuration and applications to achieve the desired security. A selection of these use cases is elaborated below.Several of the use case templates include objective requirements that are strongly desired for the indicated use cases. Readers can expect those requirements to be made mandatory in a future revision of this protection profile, and industry should aim to include that security functionality in products in the near-term.As of publication of this version of the Protection Profile, meeting the requirements in is necessary for all use cases. + enrolled authentication templates. + + + + + +
    The scope of the Protection Profile within the + development and evaluation process is described in the Common Criteria for Information + Technology Security Evaluation . In particular, a PP defines the IT security + requirements of a generic type of TOE and specifies the functional and assurance security + measures to be offered by that TOE to meet stated requirements .
    +
    The target audiences of this PP are Mobile + Device developers, CC consumers, evaluators and schemes.
    +
    This assurance standard specifies information security + requirements for Mobile Devices for use in an enterprise. A Mobile Device in the context of + this assurance standard is a device, which is composed of a hardware platform and its system + software. The device typically provides wireless connectivity + and may include software for functions + like secure messaging, email, web, VPN connection, and VoIP (Voice over IP), for access to the + protected enterprise network, enterprise data and applications, and for communicating to other + Mobile Devices. + illustrates the network operating environment of the Mobile Device. +
    + + Examples of a "Mobile Device" that should claim conformance to this Protection + Profile include smartphones, tablet computers, and other Mobile Devices with similar + capabilities. The Mobile Device provides essential services, such as + cryptographic services, data-at-rest protection, and key storage services to support the + secure operation of applications on the device. Additional security features such as security + policy enforcement, application mandatory access control, anti-exploitation features, user + authentication, and software integrity protection are implemented in order to address threats. + This assurance standard describes these essential security services + provided by the Mobile Device and serves as a foundation for a secure mobile architecture. The + wireless connectivity shall be validated against the . If the + mobile device contains Bluetooth functionality (i.e., has Bluetooth hardware), the Bluetooth + connectivity shall be evaluated against the . + As illustrated in , it is expected that a typical deployment would also include either + third-party or bundled components. Whether these components are bundled as part of the Mobile + Device by the manufacturer or developed by a third-party, they must be separately validated + against the related assurance standards such as the PP-Module for MDM Agent, PP-Module for VPN + Client, PP-Module for VVoIP, and cPP-Module for Biometrics. It is the responsibility of the architect of + the overall secure mobile architecture to ensure validation of these components. Additional + applications that may come pre-installed on the Mobile Device that are not validated are + considered to be potentially flawed, but not malicious. Examples include email client and web + browser. +
    + +
    + + + The Mobile Device may be operated in a number of use cases. + provides use case templates that list those selections, + assignments, and objective requirements that best support the use cases identified by this + Protection Profile. + In addition to providing essential security services, the Mobile Device + includes the necessary security functionality to support configurations for these various use + cases. + Each use case may require additional configuration and applications to achieve the + desired security. + A selection of these use cases is elaborated below. + + Several of the use case templates include objective requirements that are strongly desired for + the indicated use cases. + Readers can expect those requirements to be made mandatory in a + future revision of this protection profile, and industry should aim to include that security + functionality in products in the near-term. + + As of publication of this version of the Protection Profile, meeting the requirements in + is necessary for all use cases. + - An enterprise-owned device for general-purpose business use is commonly called Corporately Owned, Personally Enabled (COPE). This use case entails a significant degree of enterprise control over configuration and, possibly, software inventory. The enterprise elects to provide users with Mobile Devices and additional applications (such as VPN or email clients) in order to maintain control of their Enterprise data and security of their networks. Users may use Internet connectivity to browse the web or access corporate mail or run enterprise applications, but this connectivity may be under significant control of the enterprise. - - - An enterprise-owned device with intentionally limited network connectivity, tightly controlled configuration, and limited software inventory is appropriate for specialized, high-security use cases. For example, the device may not be permitted connectivity to any external peripherals. It may only be able to communicate via its Wi-Fi or cellular radios with the enterprise-run network, which may not even permit connectivity to the Internet. Use of the device may entail compliance with policies that are more restrictive than those in any general-purpose use case, yet may mitigate risks to highly sensitive information. As in the previous case, the enterprise will look for additional applications providing enterprise connectivity and services to have a similar level of assurance as the platform. + + + An enterprise-owned device for general-purpose business use is commonly + called Corporately Owned, Personally Enabled (COPE). + This use case entails a significant degree of enterprise control over configuration + and, possibly, software inventory. + The enterprise elects to provide users with Mobile Devices and additional applications (such as + VPN or email clients) in order to maintain control of their Enterprise data and security of + their networks. + Users may use Internet connectivity to browse the web or access corporate mail + or run enterprise applications, but this connectivity may be under significant control of the + enterprise. + + + import-user + mf-location + a-serverInclude personal Hotspot connections in the assignment + mf-unlockBanner + s-usbstore + s-tether + fc-ap_med + s-all-exe + fc-crypt-veri + fc-banner + - - A personally-owned device that is used for both personal activities and enterprise data is commonly called Bring Your Own Device (BYOD). The device may be provisioned for access to enterprise resources after significant personal usage has occurred. Unlike in the enterprise-owned cases, the enterprise is limited in what security policies it can enforce because the user purchased the device primarily for personal use and is unlikely to accept policies that limit the functionality of the device. However, because the enterprise allows the user full (or nearly full) access to the enterprise network, the enterprise will require their own security controls to ensure that enterprise resources are protected from potential threats posed by the personal activities on the device. These controls could potentially be enforced by a separation mechanism built-in to the device itself to distinguish between enterprise and personal activities, or by a third-party application that provides access to enterprise resources and leverages security capabilities provided by the mobile device. Based upon the operational environment and the acceptable risk level of the enterprise, those security functional requirements outlined in of this PP along with the selections in the Use Case 3 template defined in Appendix F - Use Case Templates are sufficient for the secure implementation of this BYOD use case. + + + + + + An enterprise-owned device with intentionally limited network connectivity, tightly controlled configuration, and limited software inventory is appropriate for specialized, high-security use cases. For example, the device may not be permitted connectivity to any external peripherals. It may only be able to communicate via its Wi-Fi or cellular radios with the enterprise-run network, which may not even permit connectivity to the Internet. Use of the device may entail compliance with policies that are more restrictive than those in any general-purpose use case, yet may mitigate risks to highly sensitive information. As in the previous case, the enterprise will look for additional applications providing enterprise connectivity and services to have a similar level of assurance as the platform. + + + + + a-keygen-rsa-sizeSet to 3072 + + s-rek-syms-rek-256 + s-rek-asyms-rek-128 + + + s-kek-sym-256 + a-kek-asym-size128 + + + + s-keygen-ecc + + s-rek-syms-rek-256 + s-rek-asyms-rek-192 + + + s-kek-sym-256 + a-kek-asym-size128 + + s-tls-secp384 + + + s-locked-ecc-800-56As-locked-rsa + s-encrypt-256 + s-rbg-256 + s-dar-256 + s-revoke-admins-revoke-deny + mf-vpn + a-mf-radiosassign all radios on TSF + a-audiovisual-devsassign all audio or visual collection devices on TSF + mf-dar + mf-location + mf-unenroll + + + + + + + + A personally-owned device that is used for both personal activities and enterprise data is commonly called Bring Your Own Device (BYOD). The device may be provisioned for access to enterprise resources after significant personal usage has occurred. Unlike in the enterprise-owned cases, the enterprise is limited in what security policies it can enforce because the user purchased the device primarily for personal use and is unlikely to accept policies that limit the functionality of the device. However, because the enterprise allows the user full (or nearly full) access to the enterprise network, the enterprise will require their own security controls to ensure that enterprise resources are protected from potential threats posed by the personal activities on the device. These controls could potentially be enforced by a separation mechanism built-in to the device itself to distinguish between enterprise and personal activities, or by a third-party application that provides access to enterprise resources and leverages security capabilities provided by the mobile device. Based upon the operational environment and the acceptable risk level of the enterprise, those security functional requirements outlined in of this PP along with the selections in the Use Case 3 template defined in Appendix F - Use Case Templates are sufficient for the secure implementation of this BYOD use case. + + + s-vpn-per-apps-vpn-per-appgroups-vpn-per-apps-vpn-per-appgroup + s-audiovisual-per-apps-audiovisual-per-appgroups-audiovisual-per-apps-audiovisual-per-appgroup + mf-entAppRemove + mf-wipeEntData + mf-unenroll + s-smf-ext-2-rem-ent-app + fdp_group + fc_access_control_system + + + + + + + + - - A personally-owned device that is used for both personal activities and enterprise data is commonly called Bring Your Own Device (BYOD). This device may be provisioned for limited access to enterprise resources such as enterprise email. Because the user does not have full access to the enterprise or enterprise data, the enterprise may not need to enforce any security policies on the device. However, the enterprise may want secure email and web browsing with assurance that the services being provided to those clients by the Mobile Device are not compromised. Based upon the operational environment and the acceptable risk level of the enterprise, those security functional requirements outlined in Section 5 Security Requirements of this PP are sufficient for the secure implementation of this BYOD use case. + + + + A personally-owned device that is used for both personal activities and enterprise data is commonly called Bring Your Own Device (BYOD). This device may be provisioned for limited access to enterprise resources such as enterprise email. Because the user does not have full access to the enterprise or enterprise data, the enterprise may not need to enforce any security policies on the device. However, the enterprise may want secure email and web browsing with assurance that the services being provided to those clients by the Mobile Device are not compromised. Based upon the operational environment and the acceptable risk level of the enterprise, those security functional requirements outlined in Section 5 Security Requirements of this PP are sufficient for the secure implementation of this BYOD use case. + -     -     - - - - - - - - - - - - - - - - - - - - - Mobile devices are subject to the threats of traditional computer systems along with those entailed by their mobile nature. The threats considered in this PP are those of network eavesdropping, network attacks, physical access, malicious or flawed applications, persistent presence, and backup as detailed in the following sections. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Mobile devices are subject to the threats of traditional + computer systems along with those entailed by their mobile nature. The threats considered in + this PP are those of network eavesdropping, network attacks, physical access, + malicious or flawed applications, persistent presence, and backup + as + detailed in the following sections. - - Applications loaded onto the Mobile Device may include malicious or exploitable code. This code could be included intentionally or unknowingly by the developer, perhaps as part of a software library. Malicious apps may attempt to exfiltrate data to which they have access. They may also conduct attacks against the platform’s system software, which will provide them with additional privileges and the ability to conduct further malicious activities. Malicious applications may be able to control the device's sensors (GPS, camera, microphone) to gather intelligence about the user's surroundings even when those activities do not involve data resident or transmitted from the device. Flawed applications may give an attacker access to perform network-based or physical attacks that otherwise would have been prevented - - The threat T.MALICIOUS_APP is countered by O.AUTH as this provides the capability to authenticate the user and endpoints of a trusted path to ensure they are communicating with an authorized entity with appropriate privileges. + + An attacker is positioned on a wireless communications channel or elsewhere + on the network infrastructure. Attackers may monitor and gain access to data exchanged + between the Mobile Device and other endpoints. + + The threat T.NETWORK_EAVESDROP is countered by O.PROTECTED_COMMS as this provides the + capability to communicate using one (or more) standard protocols as a means to + maintain the confidentiality of data that are transmitted outside of the + TOE. - The threat T.MALICIOUS_APP is countered by O.CONFIG as this provides the capability to configure and apply security policies to ensure the Mobile Device can protect user and enterprise data that it may store or process. - - - The threat T.MALICIOUS_APP is countered by O.INTEGRITY as this provides the capability to perform self-tests to ensure the integrity of critical functionality, software/firmware and data has been maintained. + The threat T.NETWORK_EAVESDROP is countered by O.CONFIG as this provides a + secure configuration of the mobile device to protect data that it + processes. - - The threat T.MALICIOUS_APP is countered by O.PRIVACY as this provides separation and privacy between user activities. - - - The threat T.MALICIOUS_APP is countered by O.PROTECTED_COMMS as this provides the capability to communicate using one (or more) standard protocols as a means to maintain the confidentiality of data that are transmitted outside of the TOE. + + The threat T.NETWORK_EAVESDROP is countered by O.AUTH as this provides + authentication of the endpoints of a trusted communication path. - An attacker is positioned on a wireless communications channel or elsewhere on the network infrastructure. Attackers may initiate communications with the Mobile Device or alter communications between the Mobile Device and other endpoints in order to compromise the Mobile Device. These attacks include malicious software update of any applications or system software on the device. These attacks also include malicious web pages or email attachments, which are usually delivered to devices over the network. - - The threat T.NETWORK_ATTACK is countered by O.AUTH as this provides authentication of the endpoints of a trusted communication path. + An attacker is positioned on a wireless communications channel or elsewhere + on the network infrastructure. Attackers may initiate communications with the Mobile + Device or alter communications between the Mobile Device and other endpoints in order to + compromise the Mobile Device. These attacks include malicious software update of any + applications or system software on the device. These attacks also include malicious web + pages or email attachments, which are usually delivered to devices over the + network. + + The threat T.NETWORK_ATTACK is countered by O.PROTECTED_COMMS as this provides the + capability to communicate using one (or more) standard protocols as a means to + maintain the confidentiality of data that are transmitted outside of the + TOE. - The threat T.NETWORK_ATTACK is countered by O.CONFIG as this provides a secure configuration of the mobile device to protect data that it processes. + The threat T.NETWORK_ATTACK is countered by O.CONFIG as this provides a + secure configuration of the mobile device to protect data that it + processes. - - The threat T.NETWORK_ATTACK is countered by O.PROTECTED_COMMS as this provides the capability to communicate using one (or more) standard protocols as a means to maintain the confidentiality of data that are transmitted outside of the TOE. + + The threat T.NETWORK_ATTACK is countered by O.AUTH as this provides + authentication of the endpoints of a trusted communication path. - - An attacker is positioned on a wireless communications channel or elsewhere on the network infrastructure. Attackers may monitor and gain access to data exchanged between the Mobile Device and other endpoints. + + An attacker, with physical access, may attempt to access user data on the + Mobile Device including credentials. These physical access threats may involve attacks, + which attempt to access the device through external hardware ports, impersonate the user + authentication mechanisms, through its user interface, and also through direct and + possibly destructive access to its storage media. Note: Defending against device re-use + after physical compromise is out of scope for this Protection Profile. + + The threat T.PHYSICAL_ACCESS is countered by O.STORAGE as this provides the + capability to encrypt all user and enterprise data and authentication keys to ensure + the confidentiality of data that it stores. + - The threat T.NETWORK_EAVESDROP is countered by O.AUTH as this provides authentication of the endpoints of a trusted communication path. + The threat T.PHYSICAL_ACCESS is countered by O.AUTH as this provides the + capability to authenticate the user prior to accessing protected functionality and + data. + + + + Applications loaded onto the Mobile Device may include malicious or + exploitable code. This code could be included intentionally or unknowingly by the + developer, perhaps as part of a software library. Malicious apps may attempt to + exfiltrate data to which they have access. They may also conduct attacks against the + platform’s system software, which will provide them with additional privileges and the + ability to conduct further malicious activities. Malicious applications may be able to + control the device's sensors (GPS, camera, microphone) to gather intelligence about the + user's surroundings even when those activities do not involve data resident or + transmitted from the device. Flawed applications may give an attacker access to perform + network-based or physical attacks that otherwise would have been prevented + + The threat T.MALICIOUS_APP is countered by O.PROTECTED_COMMS as this provides the + capability to communicate using one (or more) standard protocols as a means to + maintain the confidentiality of data that are transmitted outside of the + TOE. - The threat T.NETWORK_EAVESDROP is countered by O.CONFIG as this provides a secure configuration of the mobile device to protect data that it processes. + The threat T.MALICIOUS_APP is countered by O.CONFIG as this provides the + capability to configure and apply security policies to ensure the Mobile Device can + protect user and enterprise data that it may store or process. - - The threat T.NETWORK_EAVESDROP is countered by O.PROTECTED_COMMS as this provides the capability to communicate using one (or more) standard protocols as a means to maintain the confidentiality of data that are transmitted outside of the TOE. + + The threat T.MALICIOUS_APP is countered by O.AUTH as this provides the + capability to authenticate the user and endpoints of a trusted path to ensure they are + communicating with an authorized entity with appropriate privileges. - - - Persistent presence on a device by an attacker implies that the device has lost integrity and cannot regain it. The device has likely lost this integrity due to some other threat vector, yet the continued access by an attacker constitutes an on-going threat in itself. In this case, the device and its data may be controlled by an adversary as well as by its legitimate owner. - The threat T.PERSISTENT_PRESENCE is countered by O.INTEGRITY as this provides the capability to perform self-tests to ensure the integrity of critical functionality, software/firmware and data has been maintained. + The threat T.MALICIOUS_APP is countered by O.INTEGRITY as this provides the + capability to perform self-tests to ensure the integrity of critical functionality, + software/firmware and data has been maintained. - The threat T.PERSISTENT_PRESENCE is countered by O.PRIVACY as this provides separation and privacy between user activities. + The threat T.MALICIOUS_APP is countered by O.PRIVACY as this provides + separation and privacy between user activities. - - An attacker, with physical access, may attempt to access user data on the Mobile Device including credentials. These physical access threats may involve attacks, which attempt to access the device through external hardware ports, impersonate the user authentication mechanisms, through its user interface, and also through direct and possibly destructive access to its storage media. Note: Defending against device re-use after physical compromise is out of scope for this Protection Profile. - - The threat T.PHYSICAL_ACCESS is countered by O.AUTH as this provides the capability to authenticate the user prior to accessing protected functionality and data. + + Persistent presence on a device by an attacker implies that the device has + lost integrity and cannot regain it. The device has likely lost this integrity due to + some other threat vector, yet the continued access by an attacker constitutes an + on-going threat in itself. In this case, the device and its data may be controlled by an + adversary as well as by its legitimate owner. + + The threat T.PERSISTENT_PRESENCE is countered by O.INTEGRITY as this provides + the capability to perform self-tests to ensure the integrity of critical + functionality, software/firmware and data has been maintained. - - The threat T.PHYSICAL_ACCESS is countered by O.STORAGE as this provides the capability to encrypt all user and enterprise data and authentication keys to ensure the confidentiality of data that it stores. + + The threat T.PERSISTENT_PRESENCE is countered by O.PRIVACY as this provides + separation and privacy between user activities. - - - +
    +
    The specific conditions listed below are assumed to + exist in the TOE’s Operational Environment. These include both practical realities in the + development of the TOE security requirements and the essential environmental conditions on the + use of the TOE. - It is assumed that the TOE’s security functions are configured correctly in a manner to ensure that the TOE security policies will be enforced on all applicable network traffic flowing among the attached networks. + It is assumed that the TOE’s security functions are configured correctly in a + manner to ensure that the TOE security policies will be enforced on all applicable + network traffic flowing among the attached networks. The operational environment objective OE.CONFIG is realized through A.CONFIG. - It is assumed that the mobile user will immediately notify the administrator if the Mobile Device is lost or stolen. + It is assumed that the mobile user will immediately notify the administrator + if the Mobile Device is lost or stolen. The operational environment objective OE.NOTIFY is realized through A.NOTIFY. - It is assumed that the mobile user exercises precautions to reduce the risk of loss or theft of the Mobile Device. + It is assumed that the mobile user exercises precautions to reduce the risk + of loss or theft of the Mobile Device. The operational environment objective OE.PRECAUTION is realized through A.PRECAUTION. + - Mobile Device users are not willfully negligent or hostile, and use the device within compliance of a reasonable Enterprise security policy. + Mobile Device users are not willfully negligent or hostile, and use the + device within compliance of a reasonable Enterprise security policy. The operational environment objective OE.DATA_PROPER_USER is realized through A.PROPER_USER. - - - +
    + - - -     - - - - + + + +
    - - To address the issue of loss of confidentiality of user data in the event of loss of a Mobile Device (T.PHYSICAL_ACCESS), users are required to enter an authentication factor to the device prior to accessing protected functionality and data. Some non-sensitive functionality (e.g., emergency calling, text notification) can be accessed prior to entering the authentication factor. The device will automatically lock following a configured period of inactivity in an attempt to ensure authorization will be required in the event of the device being lost or stolen. Authentication of the endpoints of a trusted communication path is required for network access to ensure attacks are unable to establish unauthorized network connections to undermine the integrity of the device. Repeated attempts by a user to authorize to the TSF will be limited or throttled to enforce a delay between unsuccessful attempts. - FIA_AFL_EXT.1 - FIA_AFL_EXT.1 supports the objective by defining the authentication mechanisms that are subject to lockout behavior and how the TSF handles repeated failed authentication attempts. - FIA_PMG_EXT.1 - FIA_PMG_EXT.1 supports the objective by defining the minimum quality threshold for passwords that the TSF must enforce. - FIA_TRT_EXT.1 - FIA_TRT_EXT.1 supports the objective by enforcing an authentication throttling mechanism that limits the rate at which authentication attempts can be made to the TOE. - FIA_UAU.5 - FIA_UAU.5 supports the objective by defining all authentication factors the TSF supports and rules for how these authentication factors are used to gain access to the TSF. - FIA_UAU.6/CREDENTIAL - FIA_UAU.6/CREDENTIAL supports the objective by requiring the TSF to re-authenticate users with their password prior to allowing them to change any other authentication data. - FIA_UAU.6/LOCKED - FIA_UAU.6/LOCKED supports the objective by requiring the TSF to re-authenticate users with a valid credential prior to allowing a locked device to be unlocked. - FIA_UAU.7 - FIA_UAU.7 supports the objective by ensuring that TSF does not disclose user authentication data as it is being input to the TOE. - FIA_UAU_EXT.1 - FIA_UAU_EXT.1 supports the objective by requiring the TSF to be provided with a valid password before access to protected data is granted. - FIA_UAU_EXT.2 - FIA_UAU_EXT.2 supports the objective by defining the TOE functions that can be accessed without authentication such that all other services require authentication. - FIA_UAU_EXT.4 - FIA_UAU_EXT.4 supports the objective by defining a secondary authentication mechanism for Enterprise resources. - FIA_X509_EXT.2 - FIA_X509_EXT.2 supports the objective by defining the functions for which the TSF uses X.509 certificates as an authentication mechanism. - FTA_SSL_EXT.1 - FTA_SSL_EXT.1 supports the objective by requiring the TSF to ensure that an idle user session is terminated after a given period of time. + + To address the network eavesdropping (T.NETWORK_EAVESDROP) and network attack + (T.NETWORK_ATTACK) threats described in , concerning wireless + transmission of Enterprise and user data and configuration data between the TOE and + remote network entities, conformant TOEs will use a trusted communication path. The TOE + must be capable of communicating using mutually authenticated TLS, EAP-TLS, HTTPS, 802.1X, and 802.11-2012. The TOE may optionally communicate using these standard protocols: IPsec, + mutually-authenticated DTLS, or Bluetooth. These protocols are specified by RFCs that offer a variety + of implementation choices. Requirements have been imposed on some of these choices + (particularly those for cryptographic primitives) to provide interoperability and + resistance to cryptographic attack. + While conformant TOEs must + support all of the choices specified in the ST including any optional SFRs defined in + this PP, they may support additional algorithms and protocols. If such additional + mechanisms are not evaluated, guidance must be given to the administrator to make clear + the fact that they were not evaluated. + FCS_CKM.1 + FCS_CKM.1 supports the objective by defining the key generation algorithms that are used for protected communications. + + FCS_CKM.2/UNLOCKED + FCS_CKM.2/UNLOCKED supports the objective by defining the key establishment algorithms that are used for protected communications. + + FCS_COP.1/ENCRYPT + + FCS_COP.1/ENCRYPT supports the objective by requiring the TSF to implement symmetric encryption algorithms that are used in support of protected communications. + + FCS_COP.1/HASH + + FCS_COP.1/HASH supports the objective by requiring the TSF to implement hash algorithms that are used in support of protected communications. + + FCS_COP.1/SIGN + + FCS_COP.1/SIGN supports the objective by requiring the TSF to implement digital signature algorithms that are used in support of protected communications. + + FCS_COP.1/KEYHMAC + + FCS_COP.1/KEYHMAC supports the objective by requiring the TSF to implement HMAC algorithms that are used in support of protected communications. + + FCS_DTLSC_EXT.1 (TLS Package) + + FCS_DTLSC_EXT.1 supports the objective by defining the TOE's implementation of DTLS as a client if this protocol is used for protected communications. + + FCS_DTLSC_EXT.2 (TLS Package) + + FCS_DTLSC_EXT.2 supports the objective by defining the TOE's implementation of mutually-authenticated DTLS as a client if this protocol is used for protected communications. + + FCS_HTTPS_EXT.1 + + FCS_HTTPS_EXT.1 supports the objective by defining the TOE's implementation of HTTPS if this protocol is used for protected communications. + + FCS_RBG_EXT.1 + + FCS_RBG_EXT.1 supports the objective by requiring the TSF to implement deterministic random bit generation algorithms that are used in support of protected communications. + + FCS_RBG_EXT.2 (Objective) + + FCS_RBG_EXT.2 supports the objective by requiring the TSF to save the DRBG state between reboots to ensure availability of this service. + + + FCS_RBG_EXT.3 (Objective) + + FCS_RBG_EXT.3 supports the objective by defining the TSF's implementation of the SP 800-90A Personalization String for applications that require this. + + FCS_SRV_EXT.1 + + FCS_SRV_EXT.1 supports the objective by defining the cryptographic services that the TSF must make available to third-party applications, which includes those that can support protected communications. + + FCS_SRV_EXT.2 (Objective) + + FCS_SRV_EXT.2 supports the objective by requiring the TSF to make keys in its secure key storage available for use in encryption and signing operations. + + FCS_TLSC_EXT.1 (TLS Package) + + FCS_TLSC_EXT.1 supports the objective by defining the TOE's implementation of TLS as a client for protected communications. + + FCS_TLSC_EXT.2 (TLS Package) + + FCS_TLSC_EXT.2 supports the objective by defining the TOE's implementation of mutually-authenticated TLS as a client for protected communications. + + FCS_TLSC_EXT.3 (TLS Package) + + FCS_TLSC_EXT.3 supports the objective by requiring the TSF to support the TLS signature algorithms extension as part of establishing TLS protected communications. + + FDP_BLT_EXT.1 (Objective) + + FDP_BLT_EXT.1 supports the objective by limiting the applications that are authorized to use the Bluetooth interface, which may include a trusted channel. + + FDP_IFC_EXT.1 + + FDP_IFC_EXT.1 supports the objective by requiring the TSF to have either its own IPsec VPN client or interface that allows a third-party VPN client to be deployed on it. + + FDP_STG_EXT.1 + + FDP_STG_EXT.1 supports the objective by requiring the TSF to implement a protected key storage that can be used to protect persistent keys used for protected communications from disclosure. + + FDP_UPC_EXT.1/APPS + + FDP_UPC_EXT.1/APPS supports the objective by defining the protected communications channels that it allows third-party applications to invoke. + + FDP_UPC_EXT.1/BLUETOOTH + + FDP_UPC_EXT.1/BLUETOOTH supports the objective by defining the Bluetooth interfaces that it allows third-party applications to invoke. + + + FIA_X509_EXT.1 + + FIA_X509_EXT.1 supports the objective by defining the rules the TSF uses to determine if a presented X.509 certificate is valid. + + FIA_X509_EXT.2 + + FIA_X509_EXT.2 supports the objective by requiring the TSF to enumerate its uses of X.509 certificates (including protected communications) and its behavior when a certificate's revocation status is undetermined. + + FIA_X509_EXT.3 + + FIA_X509_EXT.3 supports the objective by requiring the TSF to provide a certificate validation service to third-party applications. + + FIA_X509_EXT.4 (Objective) + + FIA_X509_EXT.4 supports the objective by defining the implementation of EST as a method by which the TSF can obtain an X.509 certificate for its own use. + + FIA_X509_EXT.5 (Objective) + + FIA_X509_EXT.5 supports the objective by defining the implementation of Certificate Request Messages as a method by which the TSF can obtain an X.509 certificate for its own use. + + FPT_BLT_EXT.1 (Objective) + + FPT_BLT_EXT.1 supports the objective by requiring the TSF to disable certain Bluetooth profiles when they are inactive such that explicit user authorization is required to re-enable them. + + + FTP_ITC_EXT.1 + + FTP_ITC_EXT.1 supports the objective by defining the protected communications protocols that the TSF implements. + + + To address the issue of loss of confidentiality of user data in the event of + loss of a Mobile Device (T.PHYSICAL_ACCESS), conformant TOEs will use data-at-rest protection. + The TOE will be capable of encrypting data and keys stored on the device and will + prevent unauthorized access to encrypted data. + FCS_CKM.2/LOCKED + + FCS_CKM.2/LOCKED supports the objective by defining the key establishment mechanism used for keys that protect data at rest when the TOE is in a locked state. + + FCS_CKM_EXT.1 + + FCS_CKM_EXT.1 supports the objective by defining the TOE's root encryption key that is used to protect data at rest. + + FCS_CKM_EXT.2 + + FCS_CKM_EXT.2 supports the objective by defining how the TSF creates data encryption keys that are used to protect data at rest. + + FCS_CKM_EXT.3 + + FCS_CKM_EXT.3 supports the objective by defining the key encryption keys the TOE uses to protect data at rest and how they are created. + + FCS_CKM_EXT.4 + + FCS_CKM_EXT.4 supports the objective by requiring the TSF to destroy keys and key material that could otherwise be used to compromise data at rest. + + FCS_CKM_EXT.5 + + FCS_CKM_EXT.5 supports the objective by defining the mechanism the TSF uses to perform a wipe operation that securely destroys data at rest. + + FCS_CKM_EXT.6 + + FCS_CKM_EXT.6 supports the objective by requiring the TSF to use secure salts when performing cryptographic operations that require them. + + FCS_CKM_EXT.7 (Sel-Based) + + FCS_CKM_EXT.7 supports the objective by ensuring that the TOE's root encryption key cannot be disclosed. + + FCS_COP.1/ENCRYPT + + FCS_COP.1/ENCRYPT supports the objective by defining a symmetric encryption/decryption function that can be used to protect data at rest. + + FCS_COP.1/HASH + + FCS_COP.1/HASH supports the objective by defining a hash function that can be used to protect data at rest. + + FCS_COP.1/SIGN + + FCS_COP.1/SIGN supports the objective by defining a digital signature function that can be used to protect data at rest. + + FCS_COP.1/KEYHMAC + + FCS_COP.1/KEYHMAC supports the objective by defining an HMAC function that can be used to protect data at rest. + + FCS_COP.1/CONDITION + + FCS_COP.1/CONDITION supports the objective by defining a key derivation function that can be used to protect data at rest. + + FCS_IV_EXT.1 + + FCS_IV_EXT.1 supports the objective by ensuring that any IVs the TSF generates for AES keys are generated in an appropriate manner based on the relevant standards. + + FCS_RBG_EXT.1 + + FCS_RBG_EXT.1 supports the objective by defining random bit generation function that can be used to protect data at rest. + + FCS_STG_EXT.1 + + FCS_STG_EXT.1 supports the objective by requiring the TSF to implement a hardware or software key store to protect key data at rest. + + FCS_STG_EXT.2 + + FCS_STG_EXT.2 supports the objective by defining the confidentiality mechanism used to protect stored key data from unauthorized disclosure. + + FCS_STG_EXT.3 + + FCS_STG_EXT.3 supports the objective by defining the integrity mechanism used to protect stored key data from unauthorized modification. + + FDP_ACF_EXT.3 (Objective) + + FDP_ACF_EXT.3 supports the objective by ensuring that the TSF does not permit write and execute permissions on stored data to be granted simultaneously. + + FDP_DAR_EXT.1 + + FDP_DAR_EXT.1 supports the objective by requiring the TSF to encrypt all sensitive data using data encryption keys. + + FDP_DAR_EXT.2 + + FDP_DAR_EXT.2 supports the objective by requiring the TSF to provide a mechanism to mark data as sensitive so that it can be subject to encryption. + + FIA_UAU_EXT.1 + + FIA_UAU_EXT.1 supports the objective by requiring the presentation of a valid authorization factor in order to decrypt sensitive data at rest. + + FPT_KST_EXT.1 + + FPT_KST_EXT.1 supports the objective by requiring the TSF to prevent the storage of plaintext key data in readable non-volatile memory. + + FPT_KST_EXT.2 + + FPT_KST_EXT.2 supports the objective by requiring the TSF to prevent any transmission of plaintext key material outside of the TOE boundary. + + FPT_KST_EXT.3 + + FPT_KST_EXT.3 supports the objective by requiring the TSF to prevent export of any stored plaintext keys. + + FPT_JTA_EXT.1 + FPT_JTA_EXT.1 supports the objective by requiring the TSF to enforce access controls against JTAG so that this interface cannot be used to disclose data at rest. + + - To ensure a Mobile Device protects user and enterprise data that it may store or process, conformant TOEs will provide the capability to configure and apply security policies defined by the user and the Enterprise Administrator. If Enterprise security policies are configured these must be applied in precedence of user specified security policies. - FMT_MOF_EXT.1 - FMT_MOF_EXT.1 supports the objective by specifying the TSF management functions that an end user is authorized to perform. - FMT_SMF.1 - FMT_SMF.1 supports the objective by defining the TSF management functions and the users or roles that are authorized to invoke them. - FMT_SMF_EXT.2 - FMT_SMF_EXT.2 supports the objective by defining the configuration actions that the TSF performs automatically upon unenrollment from mobile device management. - FTA_TAB.1 - FTA_TAB.1 supports the objective by requiring the TSF to display a warning banner to users that governs authorized usage of the TOE. - + To ensure a Mobile Device protects user and enterprise data that it may + store or process, conformant TOEs will provide the capability to configure and apply + security policies defined by the user and the Enterprise Administrator. If Enterprise + security policies are configured these must be applied in precedence of user specified + security policies. + FMT_MOF_EXT.1 + + FMT_MOF_EXT.1 supports the objective by specifying the TSF management functions that an end user is authorized to perform. + + FMT_SMF.1 + + FMT_SMF.1 supports the objective by defining the TSF management functions and the users or roles that are authorized to invoke them. + + FMT_SMF_EXT.2 + + FMT_SMF_EXT.2 supports the objective by defining the configuration actions that the TSF performs automatically upon unenrollment from mobile device management. + + FTA_TAB.1 + + FTA_TAB.1 supports the objective by requiring the TSF to display a warning banner to users that governs authorized usage of the TOE. + + + + To address the issue of loss of confidentiality of user data in the event of + loss of a Mobile Device (T.PHYSICAL_ACCESS), users are required to enter an authentication + factor to the device prior to accessing protected functionality and data. Some + non-sensitive functionality (e.g., emergency calling, text notification) can be accessed + prior to entering the authentication factor. The device will automatically lock + following a configured period of inactivity in an attempt to ensure authorization will + be required in the event of the device being lost or stolen. + + Authentication of the endpoints of a trusted communication path is required for network + access to ensure attacks are unable to establish unauthorized network connections to + undermine the integrity of the device. + + Repeated attempts by a user to + authorize to the TSF will be limited or throttled to enforce a delay between + unsuccessful attempts. + + + FIA_AFL_EXT.1 + + FIA_AFL_EXT.1 supports the objective by defining the authentication mechanisms that are subject to lockout behavior and how the TSF handles repeated failed authentication attempts. + + + + FIA_PMG_EXT.1 + + FIA_PMG_EXT.1 supports the objective by defining the minimum quality threshold for passwords that the TSF must enforce. + + FIA_TRT_EXT.1 + + FIA_TRT_EXT.1 supports the objective by enforcing an authentication throttling mechanism that limits the rate at which authentication attempts can be made to the TOE. + + FIA_UAU_EXT.1 + + FIA_UAU_EXT.1 supports the objective by requiring the TSF to be provided with a valid password before access to protected data is granted. + + FIA_UAU_EXT.2 + + FIA_UAU_EXT.2 supports the objective by defining the TOE functions that can be accessed without authentication such that all other services require authentication. + + FIA_UAU_EXT.4 (Optional) + + FIA_UAU_EXT.4 supports the objective by defining a secondary authentication mechanism for Enterprise resources. + + FIA_UAU.5 + + FIA_UAU.5 supports the objective by defining all authentication factors the TSF supports and rules for how these authentication factors are used to gain access to the TSF. + + FIA_UAU.6/CREDENTIAL + + FIA_UAU.6/CREDENTIAL supports the objective by requiring the TSF to re-authenticate users with their password prior to allowing them to change any other authentication data. + + FIA_UAU.6/LOCKED + + FIA_UAU.6/LOCKED supports the objective by requiring the TSF to re-authenticate users with a valid credential prior to allowing a locked device to be unlocked. + + FIA_UAU.7 + + FIA_UAU.7 supports the objective by ensuring that TSF does not disclose user authentication data as it is being input to the TOE. + + FIA_X509_EXT.2 + + FIA_X509_EXT.2 supports the objective by defining the functions for which the TSF uses X.509 certificates as an authentication mechanism. + + FTA_SSL_EXT.1 + + FTA_SSL_EXT.1 supports the objective by requiring the TSF to ensure that an idle user session is terminated after a given period of time. + + - To ensure the integrity of the Mobile Device is maintained conformant TOEs will perform self-tests to ensure the integrity of critical functionality, software/firmware and data has been maintained. The user shall be notified of any failure of these self-tests. This will protect against the threat T.PERSISTENT. To address the issue of an application containing malicious or flawed code (T.MALICIOUS_APP), the integrity of downloaded updates to software/firmware will be verified prior to installation/execution of the object on the Mobile Device. In addition, the TOE will restrict applications to only have access to the system services and data they are permitted to interact with. The TOE will further protect against malicious applications from gaining access to data they are not authorized to access by randomizing the memory layout. - FAU_GEN.1 - FAU_GEN.1 supports the objective by requiring the TSF to record actions performed against it to establish a record of potential malicious activity. - FAU_SAR.1 - FAU_SAR.1 supports the objective by requiring the TSF to provide a mechanism to review the stored audit data so administrators can diagnose the root cause of malicious usage. - FAU_SEL.1 - FAU_SEL.1 supports the objective by allowing the TSF to restrict the audit records that are generated so that records unrelated to potential malicious usage can be suppressed. - FAU_STG.1 - FAU_STG.1 supports the objective by ensuring that a malicious user cannot tamper with audit records by modifying or deleting them. - FAU_STG.4 - FAU_STG.4 supports the objective by ensuring the availability of audit records. - FCS_COP.1/HASH - FCS_COP.1/HASH supports the objective by requiring the TSF to implement hash algorithms that can be used to assert and verify integrity. - FCS_COP.1/SIGN - FCS_COP.1/SIGN supports the objective by requiring the TSF to implement digital signature algorithms that can be used to assert and verify integrity. - FDP_ACF_EXT.1 - FDP_ACF_EXT.1 supports the objective by requiring the TSF to maintain the integrity of its system services by limiting the entities that can access them. - FDP_ACF_EXT.3 - FDP_ACF_EXT.3 supports the objective by requiring the TSF to ensure that writable files cannot be executed and vice versa, such that arbitrary code or scripts cannot be executed to compromise the integrity of the TOE. - FPT_AEX_EXT.1 - FPT_AEX_EXT.1 supports the objective by requiring the TSF to implement ASLR to prevent a compromise of the TSF. - FPT_AEX_EXT.2 - FPT_AEX_EXT.2 supports the objective by requiring the TSF to enforce permissions against memory pages to prevent a compromise of the TSF. - FPT_AEX_EXT.3 - FPT_AEX_EXT.3 supports the objective by requiring the TSF to implement stack overflow protection to prevent a compromise of the TSF. - FPT_AEX_EXT.4 - FPT_AEX_EXT.4 supports the objective by requiring the TSF to enforce address space separation to prevent a compromise of the TSF. - FPT_AEX_EXT.5 - FPT_AEX_EXT.5 supports the objective by requiring the TSF to implement ASLR to prevent a compromise of the TSF. - FPT_AEX_EXT.6 - FPT_AEX_EXT.6 supports the objective by requiring the TSF to ensure that writable files cannot be executed and vice versa, such that arbitrary code or scripts cannot be executed to compromise the integrity of the TOE. - FPT_AEX_EXT.7 - FPT_AEX_EXT.7 supports the objective by requiring the TSF to implement heap overflow protection to prevent a compromise of the TSF. - FPT_BBD_EXT.1 - FPT_BBD_EXT.1 supports the objective by ensuring that isolation between the TOE's baseband processor and application processor is enforced so that access to the baseband processor is strictly controlled. - FPT_NOT_EXT.1 - FPT_NOT_EXT.1 supports the objective by requiring the TSF to take some action to prevent its integrity in the event of various failure conditions. - FPT_NOT_EXT.2 - FPT_NOT_EXT.2 supports the objective by requiring the TSF to make its integrity verification values available for the purpose of remote attestation. - FPT_STM.1 - FPT_STM.1 supports the objective by ensuring accurate system time data is applied to audit logs. - FPT_TST_EXT.1 - FPT_TST_EXT.1 supports the objective by defining the self-tests that the TSF performs to validate its own integrity. - FPT_TST_EXT.2/POSTKERNEL - FPT_TST_EXT.2/POSTKERNEL supports the objective by requiring the TSF to verify the integrity of stored executable code prior to its execution. - FPT_TST_EXT.2/PREKERNEL - FPT_TST_EXT.2/PREKERNEL supports the objective by requiring the TSF to verify the integrity of its bootchain prior to kernel load. - FPT_TST_EXT.3 - FPT_TST_EXT.3 supports the objective by requiring the TSF to block code execution if its code signing certificate is invalid. - FPT_TUD_EXT.1 - FPT_TUD_EXT.1 supports the objective by allowing users to determine the version of the TOE's hardware, software/firmware, and installed applications. - FPT_TUD_EXT.2 - FPT_TUD_EXT.2 supports the objective by requiring the TSF to validate the integrity of software updates prior to installing them. - FPT_TUD_EXT.3 - FPT_TUD_EXT.3 supports the objective by requiring the TSF to validate the integrity of third-party applications prior to installing them. - FPT_TUD_EXT.4 - FPT_TUD_EXT.4 supports the objective by requiring the TSF to block installation of code if its associated code signing certificate is invalid. - FPT_TUD_EXT.5 - FPT_TUD_EXT.5 supports the objective by specifying the X.509 certificate that the TSF uses to verify applications prior to their installation. - FPT_TUD_EXT.6 - FPT_TUD_EXT.6 supports the objective by preventing the TSF from being rolled back to an earlier version that may have known vulnerabilities that were subsequently patched. - + To ensure the integrity of the Mobile Device is maintained conformant TOEs + will perform self-tests to ensure the integrity of critical functionality, + software/firmware and data has been maintained. The user shall be notified of any + failure of these self-tests. This will protect against the threat T.PERSISTENT. + To address the issue of an application containing malicious or flawed + code (T.MALICIOUS_APP), the integrity of downloaded updates to software/firmware will be + verified prior to installation/execution of the object on the Mobile Device. In + addition, the TOE will restrict applications to only have access to the system services + and data they are permitted to interact with. The TOE will further protect against + malicious applications from gaining access to data they are not authorized to access by + randomizing the memory layout. + FAU_GEN.1 + + FAU_GEN.1 supports the objective by requiring the TSF to record actions performed against it to establish a record of potential malicious activity. + + FAU_SAR.1 + + FAU_SAR.1 supports the objective by requiring the TSF to provide a mechanism to review the stored audit data so administrators can diagnose the root cause of malicious usage. + + FAU_SEL.1 (Objective) + + FAU_SEL.1 supports the objective by allowing the TSF to restrict the audit records that are generated so that records unrelated to potential malicious usage can be suppressed. + + FAU_STG.1 + + FAU_STG.1 supports the objective by ensuring that a malicious user cannot tamper with audit records by modifying or deleting them. + + FAU_STG.4 + + FAU_STG.4 supports the objective by ensuring the availability of audit records. + + FCS_COP.1/HASH + + FCS_COP.1/HASH supports the objective by requiring the TSF to implement hash algorithms that can be used to assert and verify integrity. + + FCS_COP.1/SIGN + + FCS_COP.1/SIGN supports the objective by requiring the TSF to implement digital signature algorithms that can be used to assert and verify integrity. + + FDP_ACF_EXT.1 + + FDP_ACF_EXT.1 supports the objective by requiring the TSF to maintain the integrity of its system services by limiting the entities that can access them. + + FDP_ACF_EXT.3 (Objective) + + FDP_ACF_EXT.3 supports the objective by requiring the TSF to ensure that writable files cannot be executed and vice versa, such that arbitrary code or scripts cannot be executed to compromise the integrity of the TOE. + + FPT_AEX_EXT.1 + + FPT_AEX_EXT.1 supports the objective by requiring the TSF to implement ASLR to prevent a compromise of the TSF. + + FPT_AEX_EXT.2 + + FPT_AEX_EXT.2 supports the objective by requiring the TSF to enforce permissions against memory pages to prevent a compromise of the TSF. + + FPT_AEX_EXT.3 + + FPT_AEX_EXT.3 supports the objective by requiring the TSF to implement stack overflow protection to prevent a compromise of the TSF. + + FPT_AEX_EXT.4 + + FPT_AEX_EXT.4 supports the objective by requiring the TSF to enforce address space separation to prevent a compromise of the TSF. + + FPT_AEX_EXT.5 (Objective) + + FPT_AEX_EXT.5 supports the objective by requiring the TSF to implement ASLR to prevent a compromise of the TSF. + + FPT_AEX_EXT.6 (Objective) + + FPT_AEX_EXT.6 supports the objective by requiring the TSF to ensure that writable files cannot be executed and vice versa, such that arbitrary code or scripts cannot be executed to compromise the integrity of the TOE. + + FPT_AEX_EXT.7 (Objective) + + FPT_AEX_EXT.7 supports the objective by requiring the TSF to implement heap overflow protection to prevent a compromise of the TSF. + + FPT_BBD_EXT.1 (Objective) + + FPT_BBD_EXT.1 supports the objective by ensuring that isolation between the TOE's baseband processor and application processor is enforced so that access to the baseband processor is strictly controlled. + + FPT_NOT_EXT.1 + + FPT_NOT_EXT.1 supports the objective by requiring the TSF to take some action to prevent its integrity in the event of various failure conditions. + + FPT_NOT_EXT.2 (Objective) + + FPT_NOT_EXT.2 supports the objective by requiring the TSF to make its integrity verification values available for the purpose of remote attestation. + + FPT_STM.1 + + FPT_STM.1 supports the objective by ensuring accurate system time data is applied to audit logs. + + FPT_TST_EXT.1 + + FPT_TST_EXT.1 supports the objective by defining the self-tests that the TSF performs to validate its own integrity. + + FPT_TST_EXT.2/PREKERNEL + + FPT_TST_EXT.2/PREKERNEL supports the objective by requiring the TSF to verify the integrity of its bootchain prior to kernel load. + + FPT_TST_EXT.2/POSTKERNEL (Objective) + + FPT_TST_EXT.2/POSTKERNEL supports the objective by requiring the TSF to verify the integrity of stored executable code prior to its execution. + + FPT_TST_EXT.3 (Sel-Based) + + FPT_TST_EXT.3 supports the objective by requiring the TSF to block code execution if its code signing certificate is invalid. + + FPT_TUD_EXT.1 + + FPT_TUD_EXT.1 supports the objective by allowing users to determine the version of the TOE's hardware, software/firmware, and installed applications. + + FPT_TUD_EXT.2 + + FPT_TUD_EXT.2 supports the objective by requiring the TSF to validate the integrity of software updates prior to installing them. + + FPT_TUD_EXT.3 + + FPT_TUD_EXT.3 supports the objective by requiring the TSF to validate the integrity of third-party applications prior to installing them. + + FPT_TUD_EXT.4 (Sel-Based) + + FPT_TUD_EXT.4 supports the objective by requiring the TSF to block installation of code if its associated code signing certificate is invalid. + + FPT_TUD_EXT.5 (Objective) + + FPT_TUD_EXT.5 supports the objective by specifying the X.509 certificate that the TSF uses to verify applications prior to their installation. + + FPT_TUD_EXT.6 (Objective) + + + FPT_TUD_EXT.6 supports the objective by preventing the TSF from being rolled back to an earlier version that may have known vulnerabilities that were subsequently patched. + + - In a BYOD environment (use cases 3 and 4), a personally-owned mobile device is used for both personal activities and enterprise data. Enterprise management solutions may have the technical capability to monitor and enforce security policies on the device. However, the privacy of the personal activities and data must be ensured. In addition, since there are limited controls that the enterprise can enforce on the personal side, separation of personal and enterprise data is needed. This will protect against the T.MALICIOUS_APP and T.PERSISTENT_PRESENCE threats. - FDP_ACF_EXT.1 - FDP_ACF_EXT.1 supports the objective by enforcing restrictions on services that could compromise user privacy if accessed inappropriately. - FDP_ACF_EXT.2 - FDP_ACF_EXT.2 supports the objective by requiring the TSF to provide separate user data stores for application groups so that the privacy of that data can be maintained. - FDP_BCK_EXT.1 - FDP_BCK_EXT.1 supports the objective by allowing data to be excluded from backup operations that could compromise user privacy if disclosed. - FMT_SMF.1 - FMT_SMF.1 supports the objective by requiring the TSF to implement management functions that control the extent to which user data is collected and disseminated. - FMT_SMF_EXT.3 - FMT_SMF_EXT.3 supports the objective by requiring the TSF to identify its authorized administrators so that a user knows the extent to which various administrators have access to the device. - - - To address the network eavesdropping (T.NETWORK_EAVESDROP) and network attack (T.NETWORK_ATTACK) threats described in , concerning wireless transmission of Enterprise and user data and configuration data between the TOE and remote network entities, conformant TOEs will use a trusted communication path. The TOE must be capable of communicating using mutually authenticated TLS, EAP-TLS, HTTPS, 802.1X, and 802.11-2012. The TOE may optionally communicate using these standard protocols: IPsec, mutually-authenticated DTLS, or Bluetooth. These protocols are specified by RFCs that offer a variety of implementation choices. Requirements have been imposed on some of these choices (particularly those for cryptographic primitives) to provide interoperability and resistance to cryptographic attack. While conformant TOEs must support all of the choices specified in the ST including any optional SFRs defined in this PP, they may support additional algorithms and protocols. If such additional mechanisms are not evaluated, guidance must be given to the administrator to make clear the fact that they were not evaluated. - FCS_CKM.1 - FCS_CKM.1 supports the objective by defining the key generation algorithms that are used for protected communications. - FCS_CKM.2/UNLOCKED - FCS_CKM.2/UNLOCKED supports the objective by defining the key establishment algorithms that are used for protected communications. - FCS_COP.1/ENCRYPT - FCS_COP.1/ENCRYPT supports the objective by requiring the TSF to implement symmetric encryption algorithms that are used in support of protected communications. - FCS_COP.1/HASH - FCS_COP.1/HASH supports the objective by requiring the TSF to implement hash algorithms that are used in support of protected communications. - FCS_COP.1/KEYHMAC - FCS_COP.1/KEYHMAC supports the objective by requiring the TSF to implement HMAC algorithms that are used in support of protected communications. - FCS_COP.1/SIGN - FCS_COP.1/SIGN supports the objective by requiring the TSF to implement digital signature algorithms that are used in support of protected communications. - FCS_HTTPS_EXT.1 - FCS_HTTPS_EXT.1 supports the objective by defining the TOE's implementation of HTTPS if this protocol is used for protected communications. - FCS_RBG_EXT.1 - FCS_RBG_EXT.1 supports the objective by requiring the TSF to implement deterministic random bit generation algorithms that are used in support of protected communications. - FCS_RBG_EXT.2 - FCS_RBG_EXT.2 supports the objective by requiring the TSF to save the DRBG state between reboots to ensure availability of this service. - FCS_RBG_EXT.3 - FCS_RBG_EXT.3 supports the objective by defining the TSF's implementation of the SP 800-90A Personalization String for applications that require this. - FCS_SRV_EXT.1 - FCS_SRV_EXT.1 supports the objective by defining the cryptographic services that the TSF must make available to third-party applications, which includes those that can support protected communications. - FCS_SRV_EXT.2 - FCS_SRV_EXT.2 supports the objective by requiring the TSF to make keys in its secure key storage available for use in encryption and signing operations. - FDP_BLT_EXT.1 - FDP_BLT_EXT.1 supports the objective by limiting the applications that are authorized to use the Bluetooth interface, which may include a trusted channel. - FDP_IFC_EXT.1 - FDP_IFC_EXT.1 supports the objective by requiring the TSF to have either its own IPsec VPN client or interface that allows a third-party VPN client to be deployed on it. - FDP_STG_EXT.1 - FDP_STG_EXT.1 supports the objective by requiring the TSF to implement a protected key storage that can be used to protect persistent keys used for protected communications from disclosure. - FDP_UPC_EXT.1/APPS - FDP_UPC_EXT.1/APPS supports the objective by defining the protected communications channels that it allows third-party applications to invoke. - FDP_UPC_EXT.1/BLUETOOTH - FDP_UPC_EXT.1/BLUETOOTH supports the objective by defining the Bluetooth interfaces that it allows third-party applications to invoke. - FIA_X509_EXT.1 - FIA_X509_EXT.1 supports the objective by defining the rules the TSF uses to determine if a presented X.509 certificate is valid. - FIA_X509_EXT.2 - FIA_X509_EXT.2 supports the objective by requiring the TSF to enumerate its uses of X.509 certificates (including protected communications) and its behavior when a certificate's revocation status is undetermined. - FIA_X509_EXT.3 - FIA_X509_EXT.3 supports the objective by requiring the TSF to provide a certificate validation service to third-party applications. - FIA_X509_EXT.4 - FIA_X509_EXT.4 supports the objective by defining the implementation of EST as a method by which the TSF can obtain an X.509 certificate for its own use. - FIA_X509_EXT.5 - FIA_X509_EXT.5 supports the objective by defining the implementation of Certificate Request Messages as a method by which the TSF can obtain an X.509 certificate for its own use. - FPT_BLT_EXT.1 - FPT_BLT_EXT.1 supports the objective by requiring the TSF to disable certain Bluetooth profiles when they are inactive such that explicit user authorization is required to re-enable them. - - - To address the issue of loss of confidentiality of user data in the event of loss of a Mobile Device (T.PHYSICAL_ACCESS), conformant TOEs will use data-at-rest protection. The TOE will be capable of encrypting data and keys stored on the device and will prevent unauthorized access to encrypted data. - FCS_CKM.2/LOCKED - FCS_CKM.2/LOCKED supports the objective by defining the key establishment mechanism used for keys that protect data at rest when the TOE is in a locked state. - FCS_CKM_EXT.1 - FCS_CKM_EXT.1 supports the objective by defining the TOE's root encryption key that is used to protect data at rest. - FCS_CKM_EXT.2 - FCS_CKM_EXT.2 supports the objective by defining how the TSF creates data encryption keys that are used to protect data at rest. - FCS_CKM_EXT.3 - FCS_CKM_EXT.3 supports the objective by defining the key encryption keys the TOE uses to protect data at rest and how they are created. - FCS_CKM_EXT.4 - FCS_CKM_EXT.4 supports the objective by requiring the TSF to destroy keys and key material that could otherwise be used to compromise data at rest. - FCS_CKM_EXT.5 - FCS_CKM_EXT.5 supports the objective by defining the mechanism the TSF uses to perform a wipe operation that securely destroys data at rest. - FCS_CKM_EXT.6 - FCS_CKM_EXT.6 supports the objective by requiring the TSF to use secure salts when performing cryptographic operations that require them. - FCS_CKM_EXT.7 - FCS_CKM_EXT.7 supports the objective by ensuring that the TOE's root encryption key cannot be disclosed. - FCS_COP.1/CONDITION - FCS_COP.1/CONDITION supports the objective by defining a key derivation function that can be used to protect data at rest. - FCS_COP.1/ENCRYPT - FCS_COP.1/ENCRYPT supports the objective by defining a symmetric encryption/decryption function that can be used to protect data at rest. - FCS_COP.1/HASH - FCS_COP.1/HASH supports the objective by defining a hash function that can be used to protect data at rest. - FCS_COP.1/KEYHMAC - FCS_COP.1/KEYHMAC supports the objective by defining an HMAC function that can be used to protect data at rest. - FCS_COP.1/SIGN - FCS_COP.1/SIGN supports the objective by defining a digital signature function that can be used to protect data at rest. - FCS_IV_EXT.1 - FCS_IV_EXT.1 supports the objective by ensuring that any IVs the TSF generates for AES keys are generated in an appropriate manner based on the relevant standards. - FCS_RBG_EXT.1 - FCS_RBG_EXT.1 supports the objective by defining random bit generation function that can be used to protect data at rest. - FCS_STG_EXT.1 - FCS_STG_EXT.1 supports the objective by requiring the TSF to implement a hardware or software key store to protect key data at rest. - FCS_STG_EXT.2 - FCS_STG_EXT.2 supports the objective by defining the confidentiality mechanism used to protect stored key data from unauthorized disclosure. - FCS_STG_EXT.3 - FCS_STG_EXT.3 supports the objective by defining the integrity mechanism used to protect stored key data from unauthorized modification. - FDP_ACF_EXT.3 - FDP_ACF_EXT.3 supports the objective by ensuring that the TSF does not permit write and execute permissions on stored data to be granted simultaneously. - FDP_DAR_EXT.1 - FDP_DAR_EXT.1 supports the objective by requiring the TSF to encrypt all sensitive data using data encryption keys. - FDP_DAR_EXT.2 - FDP_DAR_EXT.2 supports the objective by requiring the TSF to provide a mechanism to mark data as sensitive so that it can be subject to encryption. - FIA_UAU_EXT.1 - FIA_UAU_EXT.1 supports the objective by requiring the presentation of a valid authorization factor in order to decrypt sensitive data at rest. - FPT_JTA_EXT.1 - FPT_JTA_EXT.1 supports the objective by requiring the TSF to enforce access controls against JTAG so that this interface cannot be used to disclose data at rest. - FPT_KST_EXT.1 - FPT_KST_EXT.1 supports the objective by requiring the TSF to prevent the storage of plaintext key data in readable non-volatile memory. - FPT_KST_EXT.2 - FPT_KST_EXT.2 supports the objective by requiring the TSF to prevent any transmission of plaintext key material outside of the TOE boundary. - FPT_KST_EXT.3 - FPT_KST_EXT.3 supports the objective by requiring the TSF to prevent export of any stored plaintext keys. - + In a BYOD environment (use cases 3 and 4), a personally-owned mobile device + is used for both personal activities and enterprise data. Enterprise management + solutions may have the technical capability to monitor and enforce security policies on + the device. However, the privacy of the personal activities and data must be ensured. In + addition, since there are limited controls that the enterprise can enforce on the + personal side, separation of personal and enterprise data is needed. This will protect + against the T.MALICIOUS_APP and T.PERSISTENT_PRESENCE threats. + FDP_ACF_EXT.1 + + FDP_ACF_EXT.1 supports the objective by enforcing restrictions on services that could compromise user privacy if accessed inappropriately. + + FDP_ACF_EXT.2 (Sel-Based) + + FDP_ACF_EXT.2 supports the objective by requiring the TSF to provide separate user data stores for application groups so that the privacy of that data can be maintained. + + FDP_BCK_EXT.1 (Objective) + + FDP_BCK_EXT.1 supports the objective by allowing data to be excluded from backup operations that could compromise user privacy if disclosed. + + FMT_SMF.1 + + FMT_SMF.1 supports the objective by requiring the TSF to implement management functions that control the extent to which user data is collected and disseminated. + + FMT_SMF_EXT.3 (Objective) + + FMT_SMF_EXT.3 supports the objective by requiring the TSF to identify its authorized administrators so that a user knows the extent to which various administrators have access to the device. + + - - - +
    +
    + The following + security objectives for the operational environment assist the OS in correctly providing its + security functionality. These track with the assumptions about the environment. - TOE administrators will configure the Mobile Device security functions correctly to create the intended security policy - - - Administrators take measures to ensure that mobile device users are adequately vetted against malicious intent and are made aware of the expectations for appropriate use of the device. + TOE administrators will configure the Mobile Device security functions + correctly to create the intended security policy - The Mobile User will immediately notify the administrator if the Mobile Device is lost or stolen. + The Mobile User will immediately notify the administrator if the Mobile + Device is lost or stolen. - The mobile device user exercises precautions to reduce the risk of loss or theft of the Mobile Device. + The mobile device user exercises precautions to reduce the risk of loss or theft of + the Mobile Device. + + + Administrators take measures to ensure that mobile device users are adequately vetted against malicious intent and are made aware of the expectations for appropriate use of the device. - - - +
    +
    - - - - - -
    - - + +
    + + + + + + + + + + + - The TSF shall be able to generate an audit record of the following auditable events: <htm:ol><htm:li>Start-up and shutdown of the audit functions</htm:li><htm:li>All auditable events for the [<htm:b>not selected</htm:b>] level of audit</htm:li><htm:li><htm:b>All administrative actions</htm:b></htm:li><htm:li><htm:b>Start-up and shutdown of the OS</htm:b></htm:li><htm:li><htm:b>Insertion or removal of removable media</htm:b></htm:li><htm:li><htm:b>Specifically defined auditable events in <xref g="t-audit-mandatory"></xref></htm:b></htm:li><htm:li><htm:b><selectables><selectable id="fau_gen.1.1_1">Audit records reaching <assignable>integer value less than 100 </assignable> percentage of audit capacity</selectable><selectable id="fau_gen.1.1_3" >Specifically defined auditable events in <xref to="t-audit-additional"></xref></selectable><selectable id="fau_gen.1.1_5" ><assignable>other auditable events derived from this Protection Profile </assignable></selectable><selectable id="s-audit-gen-no-add-audit" exclusive="yes" >no additional auditable events</selectable></selectables></htm:b></htm:li></htm:ol> + The TSF shall be able to generate an audit record of the following auditable events:<htm:br/> + <htm:ol> + <htm:li>Start-up and shutdown of the audit functions</htm:li> + <htm:li>All auditable events for the [<refinement>not selected</refinement>] level of audit</htm:li> + <htm:li><refinement>All administrative actions</refinement></htm:li> + <htm:li><refinement>Start-up and shutdown of the OS</refinement></htm:li> + <htm:li><refinement>Insertion or removal of removable media</refinement></htm:li> + <htm:li><refinement>Specifically defined auditable events in <xref g="t-audit-mandatory"/></refinement></htm:li> + <htm:li><refinement><selectables> + <selectable>Audit records reaching <assignable>integer value less than 100</assignable> percentage of audit capacity</selectable> + <selectable>Specifically defined auditable events in <xref to="t-audit-additional"/></selectable> + <selectable><assignable>other auditable events derived from this Protection Profile</assignable></selectable> + <selectable exclusive="yes" id="s-audit-gen-no-add-audit">no additional auditable events</selectable> + </selectables></refinement></htm:li> + </htm:ol> + + <!-- <htm:table> --> + <!-- <htm:caption><ctr ctr-type="Table" id="manaudit">: Mandatory Auditable Events</ctr></htm:caption> --> + <!-- <htm:tr class="header"><htm:td>Requirement</htm:td><htm:td>Auditable Events</htm:td><htm:td>Additional Audit Record Contents</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FAU_GEN.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FAU_STG.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FAU_STG.4</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_CKM_EXT.1</htm:td><htm:td><selectables> --> + <!-- <selectable>generation of a REK</selectable> --> + <!-- <selectable>None</selectable> --> + <!-- </selectables>.</htm:td><htm:td>No additional information.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_CKM_EXT.2</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_CKM_EXT.3</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_CKM_EXT.4</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_CKM_EXT.5</htm:td><htm:td><selectables> --> + <!-- <selectable>Failure of the wipe</selectable> --> + <!-- <selectable>None</selectable> --> + <!-- </selectables>.</htm:td><htm:td>No additional information.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_CKM_EXT.6</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_CKM.1</htm:td><htm:td><selectables> --> + <!-- <selectable>Failure of key generation activity for authentication keys</selectable> --> + <!-- <selectable>None</selectable> --> + <!-- </selectables>.</htm:td><htm:td>No additional information.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_CKM.2/UNLOCKED</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_CKM.2/LOCKED</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_COP.1/ENCRYPT</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_COP.1/HASH</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_COP.1/SIGN</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_COP.1/KEYHMAC</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_COP.1/CONDITION</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_IV_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_SRV_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td rowspan="2">FCS_STG_EXT.1</htm:td><htm:td>Import or destruction of key.</htm:td><htm:td rowspan="2">Identity of key. Role and identity of requester.</htm:td></htm:tr> <htm:tr><htm:td><selectables> --> + <!-- <selectable>Exceptions to use and destruction rules</selectable> --> + <!-- <selectable exclusive="yes">No other events</selectable> --> + <!-- </selectables></htm:td> --> + <!-- </htm:tr> --> + <!-- <htm:tr><htm:td>FCS_STG_EXT.2</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_STG_EXT.3</htm:td><htm:td>Failure to verify integrity of stored key.</htm:td><htm:td>Identity of key being verified.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FDP_DAR_EXT.1</htm:td><htm:td><selectables> --> + <!-- <selectable>Failure to encrypt/decrypt data</selectable> --> + <!-- <selectable>None</selectable> --> + <!-- </selectables>.</htm:td><htm:td>No additional information.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FDP_DAR_EXT.2</htm:td><htm:td>Failure to encrypt/decrypt data.</htm:td><htm:td>No additional information.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FDP_IFC_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FDP_STG_EXT.1</htm:td><htm:td>Addition or removal of certificate from Trust Anchor Database.</htm:td><htm:td>Subject name of certificate.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FIA_PMG_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FIA_TRT_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FIA_UAU_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FIA_UAU.5</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FIA_UAU.7</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FIA_X509_EXT.1</htm:td><htm:td>Failure to validate X.509v3 certificate. </htm:td><htm:td>Reason for failure of validation.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FMT_MOF_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_AEX_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_AEX_EXT.2</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_AEX_EXT.3</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_JTA_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_KST_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_KST_EXT.2</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_KST_EXT.3</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_NOT_EXT.1</htm:td><htm:td><selectables> --> + <!-- <selectable>Measurement of TSF software</selectable> --> + <!-- <selectable>None</selectable> --> + <!-- </selectables>.</htm:td><htm:td><selectables> --> + <!-- <selectable>Integrity verification value</selectable> --> + <!-- <selectable>No additional information</selectable> --> + <!-- </selectables>.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_STM.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td rowspan="2">FPT_TST_EXT.1</htm:td><htm:td>Initiation of self-test.</htm:td><htm:td rowspan="2"><selectables> --> + <!-- <selectable>Algorithm that caused the failure</selectable> --> + <!-- <selectable>none</selectable> --> + <!-- </selectables></htm:td></htm:tr><htm:tr><htm:td>Failure of self-test.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td rowspan="2">FPT_TST_EXT.2/PREKERNEL</htm:td><htm:td>Start-up of TOE.</htm:td><htm:td>No additional information.</htm:td></htm:tr><htm:tr><htm:td><selectables> --> + <!-- <selectable>Detected integrity violation</selectable> --> + <!-- <selectable>none</selectable> --> + <!-- </selectables></htm:td><htm:td><selectables> --> + <!-- <selectable>The TSF code file that caused the integrity violation</selectable> --> + <!-- <selectable>No additional information</selectable> --> + <!-- </selectables></htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_TUD_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FTA_SSL_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FTA_TAB.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FAU_SAR.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- </htm:table><htm:br/> --> + <!-- <htm:table> --> + <!-- <htm:caption><ctr ctr-type="Table" id="objaudit">: Additional Auditable Events</ctr></htm:caption> --> + <!-- <htm:tr class="header"><htm:td>Requirement</htm:td><htm:td>Auditable --> + <!-- Events</htm:td><htm:td>Additional Audit Record Contents</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FAU_SEL.1</htm:td><htm:td>All modifications to the audit --> + <!-- configuration that occur while the audit collection functions are operating. --> + <!-- </htm:td><htm:td>No additional information.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_CKM_EXT.7</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_DTLS_EXT.1 (TLS Package)</htm:td><htm:td>Failure of the --> + <!-- certificate validity check.</htm:td><htm:td>Issuer Name and Subject Name of --> + <!-- certificate. </htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_HTTPS_EXT.1</htm:td><htm:td>Failure of the certificate validity --> + <!-- check.</htm:td> --> + <!-- <htm:td>Issuer Name and Subject Name of certificate.<htm:br/> --> + <!-- <selectables> --> + <!-- <selectable>User’s authorization decision</selectable> --> + <!-- <selectable>No additional information</selectable> --> + <!-- </selectables>.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_RBG_EXT.1</htm:td><htm:td>Failure of the randomization --> + <!-- process.</htm:td><htm:td>No additional information.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_RBG_EXT.2</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_RBG_EXT.3</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_SRV_EXT.2</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td rowspan="3">FCS_TLSC_EXT.1 (TLS --> + <!-- Package)</htm:td><htm:td>Establishment/termination of a TLS --> + <!-- session.</htm:td><htm:td>Non-TOE endpoint of --> + <!-- connection.</htm:td></htm:tr><htm:tr><htm:td>Failure to establish a TLS --> + <!-- session.</htm:td><htm:td>Reason for --> + <!-- failure.</htm:td></htm:tr><htm:tr><htm:td>Failure to verify presented --> + <!-- identifier.</htm:td><htm:td>Presented identifier and reference --> + <!-- identifier.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_TLSC_EXT.2 (TLS --> + <!-- Package)</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FCS_TLSC_EXT.3 (TLS --> + <!-- Package)</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FDP_ACF_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FDP_ACF_EXT.2</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FDP_ACF_EXT.3</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FDP_BCK_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <!-\- <htm:tr><htm:td>FDP_PBA_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> ToDo: Remove per bio cPP module -\-> --> + <!-- <htm:tr><htm:td>FDP_UPC_EXT.1/APPS</htm:td><htm:td>Application initiation of trusted --> + <!-- channel.</htm:td><htm:td>Name of application. Trusted channel protocol. Non-TOE --> + <!-- endpoint of connection.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FDP_UPC_EXT.1/BLUETOOTH</htm:td><htm:td>Application initiation of trusted --> + <!-- channel.</htm:td><htm:td>Name of application. Trusted channel protocol. Non-TOE --> + <!-- endpoint of connection.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FIA_AFL_EXT.1</htm:td><htm:td>Excess of authentication failure --> + <!-- limit.</htm:td><htm:td>Authentication factor used.</htm:td></htm:tr> --> + <!-- <!-\- ToDo: Remove per bio cPP module <htm:tr><htm:td>FIA_BMG_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FIA_BMG_EXT.2</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FIA_BMG_EXT.3</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FIA_BMG_EXT.4</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FIA_BMG_EXT.5</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FIA_BMG_EXT.6</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> -\-> --> + <!-- <htm:tr><htm:td>FIA_UAU_EXT.2</htm:td><htm:td>Action performed before --> + <!-- authentication.</htm:td><htm:td>No additional information.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FIA_UAU.6</htm:td><htm:td>User changes Password Authentication --> + <!-- Factor.</htm:td><htm:td>No additional information.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FIA_UAU_EXT.4</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FIA_X509_EXT.2</htm:td><htm:td>Failure to establish connection to --> + <!-- determine revocation status.</htm:td><htm:td>No additional --> + <!-- information.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FIA_X509_EXT.3</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td rowspan="3">FIA_X509_EXT.4</htm:td><htm:td>Generation of Certificate --> + <!-- Enrollment Request.</htm:td><htm:td>Issuer and Subject name of EST Server. --> + <!-- Method of authentication. Issuer and Subject name of certificate used to --> + <!-- authenticate. Content of Certificate Request Message.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>Success or failure of enrollment.</htm:td><htm:td>Issuer and Subject --> + <!-- name of added certificate or reason for failure.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>Update of EST Trust Anchor Database</htm:td><htm:td>Subject name of --> + <!-- added Root CA.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FIA_X509_EXT.5</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td rowspan="5">FMT_SMF_EXT.1</htm:td> --> + <!-- <htm:td><selectables> --> + <!-- <selectable>Initiation of policy update</selectable> --> + <!-- <selectable>none</selectable> --> + <!-- </selectables>.</htm:td> --> + <!-- <htm:td><selectables> --> + <!-- <selectable>Policy name</selectable> --> + <!-- <selectable>none</selectable> --> + <!-- </selectables>.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td><selectables> --> + <!-- <selectable>Change of settings</selectable> --> + <!-- <selectable>none</selectable> --> + <!-- </selectables></htm:td> --> + <!-- <htm:td><selectables> --> + <!-- <selectable>Role of user that changed setting</selectable> --> + <!-- <selectable>Value of new setting</selectable> --> + <!-- <selectable>none</selectable> --> + <!-- </selectables>.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td><selectables> --> + <!-- <selectable>Success or failure of function</selectable> --> + <!-- <selectable>none</selectable> --> + <!-- </selectables></htm:td> --> + <!-- <htm:td><selectables> --> + <!-- <selectable>Role of user that performed function</selectable> --> + <!-- <selectable>Function performed</selectable> --> + <!-- <selectable>Reason for failure, none</selectable> --> + <!-- </selectables>.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>Initiation of software update.</htm:td><htm:td>Version of update. --> + <!-- </htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>Initiation of application installation or --> + <!-- update.</htm:td><htm:td>Name and version of application.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FMT_SMF_EXT.2</htm:td> --> + <!-- <htm:td><selectables> --> + <!-- <selectable>Unenrollment</selectable> --> + <!-- <selectable>Initiation of unenrollment</selectable> --> + <!-- <selectable>none</selectable> --> + <!-- </selectables></htm:td> --> + <!-- <htm:td><selectables> --> + <!-- <selectable>Identity of administrator Remediation action --> + <!-- performed</selectable> --> + <!-- <selectable>failure of accepting command to unenroll</selectable> --> + <!-- <selectable>none</selectable> --> + <!-- </selectables></htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FMT_SMF_EXT.3</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_AEX_EXT.4</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_AEX_EXT.5</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_AEX_EXT.6</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_AEX_EXT.7</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_BBD_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_BLT_EXT.1</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_NOT_EXT.2</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_TST_EXT.2/POSTKERNEL</htm:td><htm:td><selectables> --> + <!-- <selectable>Detected integrity violation</selectable> --> + <!-- <selectable>none</selectable> --> + <!-- </selectables></htm:td> --> + <!-- <htm:td><selectables> --> + <!-- <selectable>The TSF code file that caused the integrity violation</selectable> --> + <!-- <selectable>No additional information</selectable> --> + <!-- </selectables></htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_TST_EXT.3</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_TUD_EXT.2</htm:td><htm:td>Success or failure of --> + <!-- signature verification for software updates.</htm:td><htm:td>No additional --> + <!-- information.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_TUD_EXT.3</htm:td><htm:td>Success or failure of signature verification for --> + <!-- applications.</htm:td><htm:td>No additional information.</htm:td></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_TUD_EXT.4</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_TUD_EXT.5</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FPT_TUD_EXT.6</htm:td><htm:td>None.</htm:td><htm:td/></htm:tr> --> + <!-- <htm:tr><htm:td>FTP_ITC_EXT.1</htm:td><htm:td>Initiation and termination of trusted --> + <!-- channel.</htm:td><htm:td>Trusted channel protocol. Non-TOE endpoint of --> + <!-- connection.</htm:td></htm:tr> --> + <!-- </htm:table> --> + <htm:br/> + <htm:br/> + Administrator actions are defined as functions labeled as - mandatory for FMT_MOF_EXT.1.2 (i.e. ‘M-MM’ in ). If the TSF + mandatory for FMT_MOF_EXT.1.2 (i.e. ‘M-MM’ in ). If the TSF does not support removable media, number 4 is implicitly met. The - TSF must generate an audit record for all events contained in . Generating audit records for events in is currently objective. It is acceptable to include individual SFRs from in the ST, without including the entirety of . Application Note: FPT_TST_EXT.1 – + TSF must generate an audit record for all events contained in . Generating audit records for events in is currently objective. It is acceptable to include individual SFRs from in the ST, without including the entirety of . + Application Note: FPT_TST_EXT.1 – Audit of self-tests is required only at initial start-up. Since the TOE "transitions to non-operational mode" upon failure of a self-test, per FPT_NOT_EXT.1, this is considered equivalent evidence to an audit record for the failure of a self-test. @@ -583,32 +1946,54 @@ volume encryption for protected data, since it is not feasible to audit when the encryption/decryption fails. If the TOE utilizes file-based encryption for protected data and audits when this encryption/decryption fails, then that auditable event should - be selected. Application Note: If the audit event for FMT_SMF.1 is included in the ST, it is acceptable + be selected. + + Application Note: + If the audit event for FMT_SMF.1 is included in the ST, it is acceptable for the initiation of the software update to be audited without indicating the outcome - (success or failure) of the update. + (success or failure) of the update. + - The TSF shall record within each audit record at least the following information: <htm:ol><htm:li>Date and time of the event</htm:li><htm:li>Type of event</htm:li><htm:li>Subject identity</htm:li><htm:li>The outcome (success or failure) of the event</htm:li><htm:b><htm:li>Additional information in <xref g="t-audit-mandatory"></xref></htm:li><htm:li><selectables><selectable id="fau_gen.1.2_1" >Additional information in <xref to="t-audit-additional"></xref></selectable><selectable id="s-audit-no-add-info" exclusive="yes" > no additional information</selectable></selectables></htm:li></htm:b></htm:ol> + The TSF shall record within each audit record at least the following information: <htm:ol> + + <htm:li>Date and time of the event</htm:li> + <htm:li>Type of event</htm:li> + <htm:li>Subject identity</htm:li> + <htm:li>The outcome (success or failure) of the event</htm:li> + <refinement><htm:li>Additional information in <xref g="t-audit-mandatory"/></htm:li> + <htm:li> + <selectables> + <selectable>Additional information in <xref to="t-audit-additional"/></selectable> + <selectable id="s-audit-no-add-info" exclusive="yes"> no additional information</selectable> + </selectables></htm:li></refinement> + </htm:ol> + The subject identity is usually the process name/ID. The event type is often indicated by a severity level, for example, ‘info’, ‘warning’, or ‘error’. - If is selected in the - second selection of FAU_GEN.1.1, then must be selected. - s-audit-gen-no-add-audits-audit-no-add-info + If is selected in the + second selection of FAU_GEN.1.1, then must be selected. + + s-audit-gen-no-add-audit + s-audit-no-add-info + + - For each audit event selected from in + For each audit event selected from in FAU_GEN.1.1 if additional information is required to be recorded within the audit record, it should be included in this selection. - - The evaluator shall check the TSS and ensure that it lists all of the auditable + + The evaluator shall check the TSS and ensure that it lists all of the auditable events and provides a format for audit records. Each audit record format type must be covered, along with a brief description of each field. The evaluator shall check to make sure that every audit event type mandated by the PP is described and that the description of the fields contains the information required in FAU_GEN.1.2. - + + The evaluator shall also make a determination of the administrative actions that are relevant in the context of this PP including those listed in the Management section. The evaluator shall examine the administrative guide and make a @@ -618,7 +2003,8 @@ document the methodology or approach taken while determining which actions in the administrative guide are security relevant with respect to this PP. The evaluator may perform this activity as part of the activities associated with ensuring the - AGD_OPE guidance satisfies the requirements. + AGD_OPE guidance satisfies the requirements. + The evaluator shall test the TOE’s ability to correctly generate audit records by having the TOE generate audit records for the events listed in the provided table and administrative actions. This should include all instances of an event. The @@ -634,41 +2020,48 @@ testing performed to ensure that the administrative guidance provided is correct verifies that AGD_OPE.1 is satisfied and should address the invocation of the administrative actions that are needed to verify the audit records are generated as - expected. + expected. + - + - - + - The TSF shall provide [ <htm:i>the administrator</htm:i> ] with the capability to read [ <htm:i>all audited events and record contents</htm:i> ] from the audit records. + The TSF shall provide [<htm:i>the administrator</htm:i>] with the + capability to read [<htm:i>all audited events and record contents</htm:i>] + from the audit records. The administrator must have access to read the audit record, perhaps through an API or via an MDM Agent, which transfers the local records stored on the TOE to the MDM Server where the enterprise administrator may view them. If this - requirement is included in the ST, function must be + requirement is included in the ST, function must be included in the selection of FMT_SMF.1. - The TSF shall provide the audit records in a manner suitable for the userto interpret the information. - + The TSF shall provide the audit records in a manner suitable for the user <!--ToDo: administrator? -->to interpret the information. + There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. The evaluation activity for this requirement is performed in conjunction with - test for function of FMT_SMF.1. + test for function of FMT_SMF.1. - + - - + - The TSF shall be able to select the set of events to be audited from the set of all auditable events based on the following attributes:<selectables><selectable id="fau_sel.1.1_1" >[event type]</selectable><selectable id="fau_sel.1.1_2" >[success of auditable security events</selectable><selectable id="fau_sel.1.1_3" >failure of auditable security events</selectable><selectable id="fau_sel.1.1_5" ><assignable>other attributes </assignable></selectable><selectable id="fau_sel.1.1_4">]</selectable></selectables>. + The TSF shall be able to select the set of events to be audited from the set of + all auditable events based on the following attributes: <selectables linebreak="yes"> + <selectable>[event type]</selectable> + <selectable>[success of auditable security events</selectable> + <selectable>failure of auditable security events</selectable> + <selectable><assignable>other attributes</assignable>]</selectable> + </selectables>. The intent of this requirement is to identify all criteria that can be selected to trigger an audit event. This can be configured through an interface on the TSF for a user or administrator to invoke. For the ST author, the assignment is used to list any additional criteria or "none". - + There are no TSS evaluation activities for this component. The evaluator shall review the administrative guidance to ensure that the guidance itemizes all event types, as well as describes all attributes that are to @@ -677,13 +2070,14 @@ how to set the pre-selection as well as explain the syntax (if present) for multi-value pre-selection. The administrative guidance shall also identify those audit records that are always recorded, regardless of the selection criteria - currently being enforced. - + currently being enforced. + + The evaluator shall also perform the following tests: For each attribute listed in the requirement, the evaluator shall devise a test to show that selecting the attribute causes only audit events with that attribute (or those that are always recorded, as identified in the - administrative guidance) to be recorded. + administrative guidance) to be recorded. [conditional] If the TSF supports specification of more complex audit pre-selection criteria (e.g., multiple attributes, logical expressions using attributes) then the evaluator shall devise tests showing that this capability @@ -694,18 +2088,19 @@ - - All modifications to the audit configuration that occur while the audit collection functions are operating - + + All modifications to the audit configuration that + occur while the audit collection functions are operating + - - + The TSF shall protect the stored audit records in the audit trail from unauthorized deletion. - The TSF shall be able to [ <htm:i>prevent</htm:i> ] unauthorized modifications to the stored audit records in the audit trail. - + The TSF shall be able to [<htm:i>prevent</htm:i>] unauthorized + modifications to the stored audit records in the audit trail. + The evaluator shall ensure that the TSS lists the location of all logs and the access controls of those files such that unauthorized modification and deletion are prevented. @@ -722,14 +2117,14 @@ - + - - + - The TSF shall [ <htm:i>overwrite the oldest stored audit records</htm:i> ] <htm:s>and [assignment: other actions to be taken in case of audit storage failure]</htm:s> if the audit trail is full. - - The evaluator shall examine the TSS to ensure that it describes the size limits + The TSF shall [<htm:i>overwrite the oldest stored audit records</htm:i>] <htm:s>and [assignment: other actions to be taken in case of audit storage failure]</htm:s> if the audit trail is + full. + + The evaluator shall examine the TSS to ensure that it describes the size limits on the audit records, the detection of a full audit trail, and the actions taken by the TSF when the audit trail is full. The evaluator shall ensure that the actions results in the deletion or overwrite of the oldest stored record. @@ -737,23 +2132,48 @@ There are no test evaluation activities for this component. - + -
    - -
    - This section describes how keys are generated, derived, combined, released and destroyed. There are two major types of keys: DEKs and KEKs. (A REK is considered a KEK.) DEKs are used to protect data (as in the DAR protection described in FDP_DAR_EXT.1 and FDP_DAR_EXT.2). KEKs are used to protect other keys – DEKs, other KEKs, and other types of keys stored by the user or applications. The following diagram shows an example key hierarchy to illustrate the concepts of this profile. This example is not meant as an approved design, but ST authors will be expected to provide a diagram illustrating their key hierarchy in order to demonstrate that they meet the requirements of this profile. Please note if is selected in FIA_UAU.5.1, each BAF claimed in FIA_MBV_EXT.1.1 in the shall be illustrated in the key hierarchy diagram, to include a description of when and how the BAF is used to release keys. If is selected in FIA_UAU.5.1, meaning that a PIN or password must be used in conjunction with the BAF, this interaction shall be included.
     - - + + + This section describes how keys are generated, derived, combined, released and destroyed. There are two major types of keys: DEKs and KEKs. (A REK is considered a KEK.) + DEKs are used to protect data (as in the DAR protection described in FDP_DAR_EXT.1 and FDP_DAR_EXT.2). KEKs are used to protect other keys – DEKs, other KEKs, and other types of keys stored by the user or applications. + The following diagram shows an example key hierarchy to illustrate the concepts of this profile. + This example is not meant as an approved design, but ST authors will be expected to provide a diagram illustrating their key hierarchy in order to demonstrate that they meet the requirements of this profile. + Please note if is selected in FIA_UAU.5.1, each BAF claimed in FIA_MBV_EXT.1.1 in the shall be illustrated in the key hierarchy diagram, to include a description of when and how the BAF is used to release keys. + If is selected in FIA_UAU.5.1, meaning that a PIN or password must be used in conjunction with the BAF, this interaction shall be included. +
    + - The TSF shall generate <htm:b>asymmetric</htm:b> cryptographic keys in accordance with a specified cryptographic key generation algorithm<selectables><selectable id="fcs_ckm.1.1_1"><htm:b>RSA schemes using</htm:b> cryptographic key sizes of <assignable>2048-bit or greater </assignable> that meet [<htm:i>FIPS PUB 186-4, "Digital Signature Standard (DSS)", Appendix B.3</htm:i>]</selectable><selectable id="s-keygen-ecc"><htm:b>ECC schemes using: </htm:b><selectables><selectable id="fcs_ckm.1.1_3"><htm:b>"NIST curves" P-384 and </htm:b><selectables><selectable id="fcs_ckm.1.1_4" ><htm:b>P-256</htm:b></selectable><selectable id="fcs_ckm.1.1_5" ><htm:b>P-521</htm:b></selectable><selectable id="fcs_ckm.1.1_6" exclusive="yes" ><htm:b>no other - curves</htm:b></selectable></selectables> that meet the following: [<htm:i>FIPS PUB 186-4, "Digital Signature Standard (DSS)", Appendix B.4</htm:i>]</selectable><selectable id="fcs_ckm.1.1_7" ><htm:b>Curve25519 schemes</htm:b> that meet the following: [<htm:i>RFC - 7748</htm:i>]</selectable></selectables></selectable><selectable id="fcs_ckm.1.1_8"><htm:b>FFC schemes using: </htm:b><selectables><selectable id="fcs_ckm.1.1_9" >cryptographic key sizes of <htm:b>2048-bit or - greater</htm:b> that meet the following [<htm:i>FIPS PUB 186-4, - "Digital Signature Standard (DSS)", Appendix B.1</htm:i>]</selectable><selectable id="fcs_ckm.1.1_10" ><htm:b>"safe-prime" groups</htm:b> that meet the + <title> The TSF shall generate <refinement>asymmetric</refinement> cryptographic keys in + accordance with a specified cryptographic key generation algorithm + <selectables linebreak="yes"> + <selectable><readable>RSA schemes</readable><refinement>RSA schemes using</refinement> cryptographic key sizes of + <assignable id="a-keygen-rsa-size">2048-bit or greater</assignable> that meet [<htm:i>FIPS PUB + 186-4, "Digital Signature Standard (DSS)", Appendix + B.3</htm:i>]</selectable> + <selectable id="s-keygen-ecc"><readable>ECC schemes</readable><refinement>ECC schemes using: </refinement><selectables linebreak="yes"> + <selectable><refinement>"NIST curves" P-384 and </refinement><selectables> + <selectable><refinement>P-256</refinement></selectable> + <selectable><refinement>P-521</refinement></selectable> + <selectable exclusive="yes"><refinement>no other + curves</refinement></selectable></selectables> that meet the following: [<htm:i>FIPS PUB 186-4, "Digital + Signature Standard (DSS)", Appendix B.4</htm:i>]</selectable> + <selectable><refinement>Curve25519 schemes</refinement> that meet the following: [<htm:i>RFC + 7748</htm:i>]</selectable></selectables></selectable> + <selectable><refinement>FFC schemes using: </refinement> + <selectables linebreak="yes"> + <selectable>cryptographic key sizes of <refinement>2048-bit or + greater</refinement> that meet the following [<htm:i>FIPS PUB 186-4, + "Digital Signature Standard (DSS)", Appendix B.1</htm:i>]</selectable> + <!-- <selectable><refinement>Diffie-Hellman group 14 </refinement>that meet the + following: [<htm:i>RFC3526</htm:i>]</selectable> --> + <selectable><refinement>"safe-prime" groups</refinement> that meet the following: [<htm:i>NIST Special Publication 800-56A Revision 3, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete - Logarithm Cryptography"</htm:i>]</selectable></selectables></selectable></selectables>. + Logarithm Cryptography"] + + . The ST author must select all key generation schemes used for key establishment and entity authentication. When key generation is used for key establishment, the schemes in FCS_CKM.2/UNLOCKED and selected cryptographic protocols @@ -762,16 +2182,19 @@ TOE acts as a receiver in the RSA key establishment scheme, the TOE does not need to implement RSA key generation. Curve25519 can only be used for ECDH and in conjunction with FDP_DAR_EXT.2.2. - - The evaluator shall ensure that the TSS identifies the key sizes supported by + + The evaluator shall ensure that the TSS identifies the key sizes supported by the TOE. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme. The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key generation schemes - and key sizes for all uses defined in this PP. - Evaluation Activity Note: The following tests require the developer to + and key sizes for all uses defined in this PP. + + + Evaluation Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are - typically not found on factory products.Key Generation for FIPS PUB 186-4 RSA + typically not found on factory products. + Key Generation for FIPS PUB 186-4 RSA Schemes The evaluator shall verify the implementation of RSA Key Generation by the TOE using the Key Generation test. This test verifies the ability of the TSF to correctly produce values for the key @@ -779,8 +2202,20 @@ prime factors p and q, the public modulus n and the calculation of the private signature exponent d. Key Pair generation specifies 5 ways (or methods) to generate the primes - p and q. These include: Random Primes: Provable primesProbable primesPrimes with Conditions: Primes p1, p2, q1,q2, p and q shall all be provable primes Primes p1, p2, q1, and q2 shall be provable primes and p and q shall - be probable primesPrimes p1, p2, q1,q2, p and q shall all be probable primes To test the key generation method for the Random Provable primes method + p and q. These include: + Random Primes: + Provable primes + Probable primes + + + Primes with Conditions: + Primes p1, p2, q1,q2, p and q shall all be provable primes + Primes p1, p2, q1, and q2 shall be provable primes and p and q shall + be probable primes + Primes p1, p2, q1,q2, p and q shall all be probable primes + + + To test the key generation method for the Random Provable primes method and for all the Primes with Conditions methods, the evaluator must seed the TSF key generation routine with sufficient data to deterministically generate the RSA key pair. This includes the random seeds, the public exponent of the RSA key, and the @@ -790,23 +2225,49 @@ known good implementation. If possible, the Random Probable primes method should also be verified against a known good implementation as described above. Otherwise, the evaluator shall have the TSF generate 10 keys pairs - for each supported key length nlen and verify: n = p*qp and q are probably prime according to Miller-Rabin testsGCD(p-1,e) = 1GCD(q-1,e) = 12^16 < e < 2^256 and e is an odd integer|p-q| > 2^(nlen/2 – 100)p >= squareroot(2)*( 2^(nlen/2 -1) )q >= squareroot(2)*( 2^(nlen/2 -1) )2^(nlen/2) < d < LCM(p-1,q-1)e*d = 1 mod LCM(p-1,q-1)Key Generation for FIPS 186-4 Elliptic Curve Cryptography - (ECC)FIPS 186-4 ECC Key Generation Test For each + for each supported key length nlen and verify: + n = p*q + p and q are probably prime according to Miller-Rabin tests + GCD(p-1,e) = 1 + GCD(q-1,e) = 1 + 2^16 < e < 2^256 and e is an odd integer + |p-q| > 2^(nlen/2 – 100) + p >= squareroot(2)*( 2^(nlen/2 -1) ) + q >= squareroot(2)*( 2^(nlen/2 -1) ) + 2^(nlen/2) < d < LCM(p-1,q-1) + e*d = 1 mod LCM(p-1,q-1) + + + Key Generation for FIPS 186-4 Elliptic Curve Cryptography + (ECC) + FIPS 186-4 ECC Key Generation Test For each supported NIST curve, i.e. P-256, P-384 and P-521, the evaluator shall require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated using an approved random bit generator (RBG). To determine correctness, the evaluator shall submit the generated key pairs to the public key - verification (PKV) function of a known good implementation. FIPS 186-4 Public Key Verification (PKV) Test For + verification (PKV) function of a known good implementation. + FIPS 186-4 Public Key Verification (PKV) Test For each supported NIST curve, i.e. P-256, P-384 and P-521, the evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify five of the public key values so that they are incorrect, leaving five values unchanged (i.e. correct). The evaluator shall obtain in response - a set of 10 PASS/FAIL values. Key Generation for Curve25519 + a set of 10 PASS/FAIL values. + + + Key Generation for Curve25519 The evaluator shall require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated as specified in RFC 7748 using an approved random bit generator (RBG) and shall be written in little-endian order (least significant byte first). To determine correctness, the evaluator shall submit the generated key pairs to the public key verification (PKV) function of a known good implementation. Note: Assuming the PKV function of the good implementation will (using little-endian order): - Confirm the private and public keys are 32-byte valuesConfirm the three least significant bits of the first byte of the private key are zeroConfirm the most significant bit of the last byte is zeroConfirm the second most significant bit of the last byte is oneCalculate the expected public key from the private key and confirm it matches the supplied public key + + Confirm the private and public keys are 32-byte values + Confirm the three least significant bits of the first byte of the private key are zero + Confirm the most significant bit of the last byte is zero + Confirm the second most significant bit of the last byte is one + Calculate the expected public key from the private key and confirm it matches the supplied public key + + The evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify 5 of the public key values so that they are incorrect, leaving five values unchanged (i.e. correct). The evaluator shall obtain in response a set of 10 PASS/FAIL values. - Key Generation for Finite-Field Cryptography + + Key Generation for Finite-Field Cryptography (FFC) The evaluator shall verify the implementation of the Parameters Generation and the Key Generation for FFC by the TOE using the Parameter Generation and Key Generation test. This test verifies the ability of the TSF to @@ -814,10 +2275,21 @@ The evaluator shall generate 10 private/public key pairs using the key generatio p-1), the cryptographic group generator g, and the calculation of the private key x and public key y. The Parameter generation specifies 2 ways (or methods) to generate the cryptographic prime q and the field prime p: - Cryptographic and Field Primes:Primes q and p shall both be provable primesPrimes q and field prime p shall both be probable primes and two ways to generate the cryptographic group generator - g: Cryptographic Group Generator:Generator g constructed through a verifiable processGenerator g constructed through an unverifiable process The Key generation specifies 2 ways to generate the private key - x: Private Key:len(q) bit output of RBG where 1 < = x < = q-1 len(q) + 64 bit output of RBG, followed by a mod q-1 operation where - 1 < = x < =q-1 The security strength of the RBG must be at least that of the security + Cryptographic and Field Primes: + + Primes q and p shall both be provable primes + Primes q and field prime p shall both be probable primes + and two ways to generate the cryptographic group generator + g: Cryptographic Group Generator: + Generator g constructed through a verifiable process + Generator g constructed through an unverifiable process + The Key generation specifies 2 ways to generate the private key + x: Private Key: + + len(q) bit output of RBG where 1 <= x <= q-1 + len(q) + 64 bit output of RBG, followed by a mod q-1 operation where + 1<= x<=q-1 + The security strength of the RBG must be at least that of the security offered by the FFC parameter set. To test the cryptographic and field prime generation method for the provable primes method or the group generator g for a verifiable process, the evaluator must seed the TSF parameter @@ -825,110 +2297,83 @@ The evaluator shall generate 10 private/public key pairs using the key generatio set. For each key length supported, the evaluator shall have the TSF generate 25 parameter sets and key pairs. The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF - with those generated from a known good implementation. Verification must also confirmg != 0,1q divides p-1g^q mod p = 1g^x mod p = y for each FFC parameter set and key pair. - + with those generated from a known good implementation. Verification must also confirm + g != 0,1 + q divides p-1 + g^q mod p = 1 + g^x mod p = y + + for each FFC parameter set and key pair. + + - - - - Failure of key generation activity for authentication keys - none - - - - - - - - The TSF shall <htm:b>perform</htm:b> cryptographic <htm:b>key - establishment</htm:b> in accordance with a specified cryptographic key <htm:b>establishment</htm:b> method:<selectables><selectable id="s-locked-rsa" >[<htm:i>RSA-based key establishment schemes</htm:i>] that meet the following: [<htm:i>NIST Special Publication 800-56B, “Recommendation for Pair-Wise Key - Establishment Schemes Using Integer Factorization - Cryptography”</htm:i>]</selectable><selectable id="fcs_ckm.2.1_LOCKED_1">[<htm:i>Elliptic curve-based key establishment schemes</htm:i>] that meet the following: <selectables><selectable id="s-locked-ecc-800-56A" ><htm:b>NIST Special Publication 800-56A Revision 3, - "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete - Logarithm Cryptography"</htm:b></selectable><selectable id="fcs_ckm.2.1_LOCKED_2" ><htm:b>RFC 7748, "Elliptic Curves for - Security"</htm:b></selectable></selectables></selectable><selectable id="fcs_ckm.2.1_LOCKED_3" >[<htm:i>Finite field-based key establishment schemes</htm:i>] - that meet the following: [<htm:i>NIST Special Publication 800-56A Revision 3, - "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm - Cryptography"</htm:i>]</selectable></selectables><htm:b>for the purposes of encrypting sensitive data received while the device is - locked.</htm:b> - The RSA-based key establishment schemes are described in - Section 9 of NIST SP 800-56B; however, Section 9 relies on implementation of other - sections in SP 800-56B. If the TOE acts as a receiver in the RSA key establishment - scheme, the TOE does not need to implement RSA key generation. The - elliptic curves used for the key establishment scheme must correlate with the curves - specified in FCS_CKM.1.1. The domain parameters used for the finite - field-based key establishment scheme are specified by the key generation according to - FCS_CKM.1.1. - - There are no TSS evaluation activities for this component. - There are no guidance evaluation activities for this component. - The test for SP800-56A Revision 3 and SP800-56B key establishment schemes is - performed in association with FCS_CKM.2/UNLOCKED. Curve25519 Key Establishment Schemes The evaluator - shall verify a TOE's implementation of the key agreement scheme using the following - Function and Validity tests. These validation tests for each key agreement scheme - verify that a TOE has implemented the components of the key agreement scheme - according to the specification. These components include the calculation of the - shared secret K and the hash of K. Function Test The Function test verifies the - ability of the TOE to implement the key agreement schemes correctly. To conduct this - test the evaluator shall generate or obtain test vectors from a known good - implementation of the TOE supported schemes. For each supported key agreement role - and hash function combination, the tester shall generate 10 sets of public keys. - These keys are static, ephemeral or both depending on the scheme being tested. - The evaluator shall obtain the shared secret value K, and the - hash of K. The evaluator shall verify the correctness of the TSF’s - implementation of a given scheme by using a known good implementation to calculate - the shared secret value K and compare the hash generated from this value. Validity Test The Validity test verifies the - ability of the TOE to recognize another party’s valid and invalid key agreement - results. To conduct this test, the evaluator generates a set of 30 test vectors - consisting of data sets including the evaluator’s public keys and the TOE’s - public/private key pairs. The evaluator shall inject an error in - some of the test vectors to test that the TOE recognizes invalid key agreement - results caused by the following fields being incorrect: the shared secret value K or - the hash of K. At least two of the test vectors shall remain unmodified and - therefore should result in valid key agreement results (they should pass). - The TOE shall use these modified test vectors to emulate the key - agreement scheme using the corresponding parameters. The evaluator shall compare the - TOE’s results with the results using a known good implementation verifying that the - TOE detects these errors. - - - + + Failure of key generation activity for authentication keysNone + - - + - The TSF shall <htm:b>perform</htm:b> cryptographic <htm:b>key - establishment</htm:b> in accordance with a specified cryptographic key <htm:b>establishment</htm:b> method<selectables><selectable id="fcs_ckm.2.1_UNLOCKED_1">[<htm:i>RSA-based key establishment schemes</htm:i>] that meet the following <selectables><selectable id="fcs_ckm.2.1_UNLOCKED_2" >NIST Special Publication 800-56B, “Recommendation for Pair-Wise + <title>The TSF shall <refinement>perform</refinement> cryptographic <refinement>key + establishment</refinement> in accordance with a specified cryptographic key + <refinement>establishment</refinement> method <selectables linebreak="yes"> + <selectable><readable>RSA-based key establishment schemes</readable>[<htm:i>RSA-based key establishment schemes</htm:i>] that meet the following + <selectables linebreak="yes"> + <selectable>NIST Special Publication 800-56B, “Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization - Cryptography”</selectable><selectable id="fcs_ckm.2.1_UNLOCKED_3" >RSAES-PKCS1-v1_5 as specified in Section 7.2 of RFC 8017, + Cryptography”</selectable> + <selectable>RSAES-PKCS1-v1_5 as specified in Section 7.2 of RFC 8017, "Public-Key Cryptography Standards (PKCS) #1:RSA Cryptography Specifications - Version 2.2"</selectable></selectables></selectable><selectable id="fcs_ckm.2.1_UNLOCKED_4" >[<htm:i>Elliptic curve-based key establishment schemes</htm:i>] + Version 2.2"</selectable> + </selectables></selectable> + <selectable><readable>Elliptic curve-based key establishment schemes</readable>[<htm:i>Elliptic curve-based key establishment schemes</htm:i>] that meet the following: [<htm:i>NIST Special Publication 800-56A Revision 3, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm - Cryptography"</htm:i>]</selectable><selectable id="fcs_ckm.2.1_UNLOCKED_5" >[<htm:i>Finite field-based key establishment schemes</htm:i>] + Cryptography"</htm:i>]</selectable> + <selectable>[<htm:i>Finite field-based key establishment schemes</htm:i>] that meet the following: [<htm:i>NIST Special Publication 800-56A Revision 3, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm - Cryptography"</htm:i>]</selectable></selectables>. + Cryptography"] + + + + . The ST author must select all key establishment schemes used for the selected cryptographic protocols and any RSA-based key establishment schemes that may be used to satisfy FDP_DAR or FCS_STG. Also, FCS_TLSC_EXT.1 requires ciphersuites that use RSA-based key establishment schemes. The RSA-based key establishment schemes are described in Section 9 of NIST SP 800-56B; however, Section 9 relies on implementation of other sections in SP 800-56B. If the TOE only acts as a receiver in the RSA key establishment scheme, the TOE does not need to implement RSA key generation. The elliptic curves used for the key establishment scheme must correlate with the curves specified in FCS_CKM.1.1. The domain parameters used for the finite field-based key establishment scheme are specified by the key generation according to FCS_CKM.1.1. The finite field-based key establishment schemes that conform to NIST SP 800-56A Revision 3 correspond to the "safe-prime" groups selection in FCS_CKM.1.1. - - The evaluator shall ensure that the supported key establishment schemes + + + The evaluator shall ensure that the supported key establishment schemes correspond to the key generation schemes identified in FCS_CKM.1.1. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that - it identifies the usage for each scheme. + it identifies the usage for each scheme. + + + + + + The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key establishment - schemes. - Evaluation Activity Note: The following tests require the developer to + schemes. + + + Evaluation Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products. The evaluator shall verify the implementation of the key - establishment schemes supported by the TOE using the applicable tests below. SP800-56A Revision 3 Key Establishment Schemes + establishment schemes supported by the TOE using the applicable tests below. + SP800-56A Revision 3 Key Establishment Schemes The evaluator shall verify a TOE's implementation of SP800-56A Revision 3 key establishment schemes using the following Function and Validity tests. These validation tests for each key agreement scheme verify that a TOE has @@ -939,7 +2384,9 @@ The evaluator shall generate 10 private/public key pairs using the key generatio supported, the evaluator shall also verify that the components of key confirmation have been implemented correctly, using the test procedures described below. This includes the parsing of the DKM, the generation of MACdata and the calculation of - MacTag. Function Test The Function test verifies the ability of the TOE to implement + MacTag. + Function Test + The Function test verifies the ability of the TOE to implement the key agreement schemes correctly. To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each supported key agreement scheme-key agreement role @@ -957,7 +2404,9 @@ The evaluator shall generate 10 private/public key pairs using the key generatio calculate the shared secret value, derive the keying material DKM, and compare hashes or MAC tags generated from these values. If key confirmation is supported, the TSF shall perform the above for each implemented - approved MAC algorithm. Validity Test The Validity test verifies the ability of the TOE to recognize + approved MAC algorithm. + Validity Test + The Validity test verifies the ability of the TOE to recognize another party’s valid and invalid key agreement results with or without key confirmation. To conduct this test, the evaluator shall obtain a list of the supporting cryptographic functions included in the SP800-56A Revision 3 key @@ -979,7 +2428,8 @@ The evaluator shall generate 10 private/public key pairs using the key generatio these modified test vectors to emulate the key agreement scheme using the corresponding parameters. The evaluator shall compare the TOE’s results with the results using a known good implementation verifying that the TOE detects these - errors. SP800-56B Key Establishment Schemes The evaluator shall verify that + errors. + SP800-56B Key Establishment Schemes The evaluator shall verify that the TSS describes whether the TOE acts as a sender, a recipient, or both for RSA-based key establishment schemes. If the TOE acts as a sender, the following evaluation activity shall be performed to ensure the proper operation @@ -1026,10 +2476,15 @@ The evaluator shall generate 10 private/public key pairs using the key generatio ciphertext values that trigger each of the three decryption error checks described in NIST Special Publication 800-56B section 7.2.3.3, ensure that each decryption attempt results in an error, and ensure that any outputted or logged error message - is identical for each.RSAES-PKCS1-v1_5 Key Establishment Schemes The evaluator shall + is identical for each. + RSAES-PKCS1-v1_5 Key Establishment Schemes The evaluator shall verify the correctness of the TSF's implementation of RSAES-PKCS1-v1_5 by using a known good implementation for each protocol selected in FTP_ITC_EXT.1 that uses RSAES-PKCS1-v1_5. + FFC Schemes using "safe-prime" groups The evaluator shall verify the correctness of the TSF's implementation of "safe-prime" groups by using a known good implementation for each protocol selected @@ -1037,23 +2492,117 @@ The evaluator shall generate 10 private/public key pairs using the key generatio "safe-prime" group that each protocol uses. - + - - + + + The TSF shall <refinement>perform</refinement> cryptographic <refinement>key + establishment</refinement> in accordance with a specified cryptographic key + <refinement>establishment</refinement> method: <selectables linebreak="yes"> + <selectable id="s-locked-rsa"><readable>RSA-based key establishment schemes</readable>[<htm:i>RSA-based key establishment schemes</htm:i>] that meet the following: [<htm:i>NIST Special Publication 800-56B, “Recommendation for Pair-Wise Key + Establishment Schemes Using Integer Factorization + Cryptography”</htm:i>]</selectable> + <selectable><readable>Elliptic curve-based key establishment schemes</readable>[<htm:i>Elliptic curve-based key establishment schemes</htm:i>] + that meet the following: <selectables linebreak="yes"> + <selectable id="s-locked-ecc-800-56A"><readable>Pair-Wise Key Establishment Schemes Using Discrete + Logarithm Cryptography</readable><refinement>NIST Special Publication 800-56A Revision 3, + "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete + Logarithm Cryptography"</refinement></selectable> + <selectable><refinement>RFC 7748, "Elliptic Curves for + Security"</refinement></selectable> + </selectables> + </selectable> + <selectable>[<htm:i>Finite field-based key establishment schemes</htm:i>] + that meet the following: [<htm:i>NIST Special Publication 800-56A Revision 3, + "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm + Cryptography"</htm:i>]</selectable> + </selectables> + <refinement>for the purposes of encrypting sensitive data received while the device is + locked.</refinement> + + The RSA-based key establishment schemes are described in + Section 9 of NIST SP 800-56B; however, Section 9 relies on implementation of other + sections in SP 800-56B. If the TOE acts as a receiver in the RSA key establishment + scheme, the TOE does not need to implement RSA key generation. The + elliptic curves used for the key establishment scheme must correlate with the curves + specified in FCS_CKM.1.1. The domain parameters used for the finite + field-based key establishment scheme are specified by the key generation according to + FCS_CKM.1.1. + + There are no TSS evaluation activities for this component. + There are no guidance evaluation activities for this component. + The test for SP800-56A Revision 3 and SP800-56B key establishment schemes is + performed in association with FCS_CKM.2/UNLOCKED. + Curve25519 Key Establishment Schemes The evaluator + shall verify a TOE's implementation of the key agreement scheme using the following + Function and Validity tests. These validation tests for each key agreement scheme + verify that a TOE has implemented the components of the key agreement scheme + according to the specification. These components include the calculation of the + shared secret K and the hash of K. + Function Test The Function test verifies the + ability of the TOE to implement the key agreement schemes correctly. To conduct this + test the evaluator shall generate or obtain test vectors from a known good + implementation of the TOE supported schemes. For each supported key agreement role + and hash function combination, the tester shall generate 10 sets of public keys. + These keys are static, ephemeral or both depending on the scheme being tested. + The evaluator shall obtain the shared secret value K, and the + hash of K. The evaluator shall verify the correctness of the TSF’s + implementation of a given scheme by using a known good implementation to calculate + the shared secret value K and compare the hash generated from this value. + Validity Test The Validity test verifies the + ability of the TOE to recognize another party’s valid and invalid key agreement + results. To conduct this test, the evaluator generates a set of 30 test vectors + consisting of data sets including the evaluator’s public keys and the TOE’s + public/private key pairs. The evaluator shall inject an error in + some of the test vectors to test that the TOE recognizes invalid key agreement + results caused by the following fields being incorrect: the shared secret value K or + the hash of K. At least two of the test vectors shall remain unmodified and + therefore should result in valid key agreement results (they should pass). + The TOE shall use these modified test vectors to emulate the key + agreement scheme using the corresponding parameters. The evaluator shall compare the + TOE’s results with the results using a known good implementation verifying that the + TOE detects these errors. + + + + + + + + This family defines requirements for management of cryptographic keys that are not addressed by FCS_CKM in CC Part 2. + + + + + + requires the TSF to implement a Root Encryption Key (REK). There are no management activities foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - Generation of a REK. + + Generation of a REK. + FCS_RBG_EXT.1 Random Bit Generation + + - The TSF shall support<selectables><selectable id="s-immutable-hardware" >immutable hardware</selectable><selectable id="mutable_hardware" >mutable hardware</selectable></selectables>REKs with a<selectables><selectable id="s-rek-sym" >symmetric</selectable><selectable id="s-rek-asym" >asymmetric</selectable></selectables>key of strength<selectables><selectable id="fcs_ckm_ext.1.1_1" >112 bits</selectable><selectable id="s-rek-128" >128 bits</selectable><selectable id="s-rek-192" >192 bits</selectable><selectable id="s-rek-256" >256 bits</selectable></selectables>. + The TSF shall support <selectables> + <selectable id="s-immutable-hardware">immutable hardware</selectable> + <selectable id="mutable_hardware">mutable hardware</selectable></selectables> REKs with a <selectables> + <selectable id="s-rek-sym">symmetric</selectable> + <selectable id="s-rek-asym">asymmetric</selectable></selectables> key of strength <selectables> + <selectable>112 bits</selectable> + <selectable id="s-rek-128">128 bits</selectable> + <selectable id="s-rek-192">192 bits</selectable> + <selectable id="s-rek-256">256 bits</selectable></selectables>. + The TSF shall support <assignable>description of REKs</assignable> + - Each REK shall be hardware-isolated from the OS on the TSF in runtime. + Each REK shall be hardware-isolated from the OS on the TSF in runtime. - Each REK shall be generated by an RBG in accordance with FCS_RBG_EXT.1. + Each REK shall be generated by an RBG in accordance with FCS_RBG_EXT.1. Either asymmetric or symmetric keys are allowed; the ST author makes the selection appropriate for the device. Symmetric keys must be of size 128 or 256 bits in order to correspond with FCS_COP.1/ENCRYPT. Asymmetric keys may be of any @@ -1061,10 +2610,10 @@ The evaluator shall generate 10 private/public key pairs using the key generatio The raw key material of "immutable hardware" REKs is computationally processed by hardware and software - cannot access the raw key material. Thus if + cannot access the raw key material. Thus if is selected in FCS_CKM_EXT.1.1 it implicitly meets FCS_CKM_EXT.7. - If is selected + If is selected in FCS_CKM_EXT.1.1, FCS_CKM_EXT.7 must be included in the ST. The @@ -1074,8 +2623,8 @@ The evaluator shall generate 10 private/public key pairs using the key generatio key container or may be an off-device RBG. If performed by an off-device RBG, the device manufacturer must not be able to access a REK after the manufacturing process has been completed. The Evaluation Activities for these two cases differ. - - The evaluator shall review the TSS to determine that a REK is supported by the + + The evaluator shall review the TSS to determine that a REK is supported by the TOE, that the TSS includes a description of the protection provided by the TOE for a REK, and that the TSS includes a description of the method of generation of a REK. The evaluator shall verify that the description of the protection @@ -1095,72 +2644,347 @@ The evaluator shall generate 10 private/public key pairs using the key generatio a description of the key derivation function and shall verify the key derivation uses an approved derivation mode and key expansion algorithm according to FCS_CKM_EXT.3.2. The evaluator shall verify that the generation - of a REK meets the FCS_RBG_EXT.1.1 and FCS_RBG_EXT.1.2 requirements: If REKs is/are generated on-device, the TSS shall include a description + of a REK meets the FCS_RBG_EXT.1.1 and FCS_RBG_EXT.1.2 requirements: + + If REKs is/are generated on-device, the TSS shall include a description of the generation mechanism including what triggers a generation, how the functionality described by FCS_RBG_EXT.1 is invoked, and whether a separate - instance of the RBG is used for REKs.If REKs is/are generated off-device, the TSS shall include evidence that + instance of the RBG is used for REKs. + If REKs is/are generated off-device, the TSS shall include evidence that the RBG meets FCS_RBG_EXT.1. This will likely necessitate a second set of RBG documentation equivalent to the documentation provided for the RBG Evaluation Activities. In addition, the TSS shall describe the manufacturing process that - prevents the device manufacturer from accessing any REKs. + prevents the device manufacturer from accessing any REKs. + There are no guidance evaluation activities for this component. There are no test evaluation activities for this component. - - - - generation of a REK - none - - - + + generation of a REKnone + - - - requires the TSF to specify the mechanism it uses to generate Data Encryption Keys (DEKs). - There are no management activities foreseen. - There are no auditable events foreseen. - FCS_RBG_EXT.1 Random Bit Generation + + + requires the TSF to specify the mechanism it uses to generate Data Encryption Keys (DEKs). + There are no management activities foreseen. + There are no auditable events foreseen. + FCS_RBG_EXT.1 Random Bit Generation + + - All DEKs shall be<selectables><selectable id="fcs_ckm_ext.2.1_1" >randomly generated</selectable><selectable id="fcs_ckm_ext.2.1_2"> from the combination of a randomly generated DEK with another DEK or salt in a way that preserves the effective entropy of each factor by <selectables><selectable id="fcs_ckm_ext.2.1_3" >using an XOR operation</selectable><selectable id="fcs_ckm_ext.2.1_4" > concatenating the keys and using a KDF (as described in SP - 800-108)</selectable><selectable id="s-dek-800-56" >concatenating the keys and using a KDF (as described in SP - 800-56C)</selectable></selectables></selectable></selectables>with entropy corresponding to the security strength of AES key sizes of<selectables><selectable id="fcs_ckm_ext.2.1_5" >128</selectable><selectable id="s-dek-256" >256</selectable></selectables>bits. - The intent of this requirement is to ensure that the DEK cannot be recovered with less work than a full exhaust of the key space for AES. The key generation capability of the TOE uses an RBG implemented on the TOE device (FCS_RBG_EXT.1). Either 128-bit or 256-bit (or both) are allowed; the ST author makes the selection appropriate for the device. A DEK is used in addition to the KEK so that authentication factors can be changed without having to re-encrypt all of the user data on the device.The ST author selects all applicable DEK generation types implemented by the TOE.SP 800-56C specifies a two-step key derivation procedure that employs an extraction-then-expansion technique for deriving keying material from a shared secret generated during a key establishment scheme. The Randomness Extraction step as described in Section 5 of SP 800-56C is followed by Key Expansion using the key derivation functions defined in SP 800-108 (as described in Section 6 of SP 800-56C). - - The evaluator shall ensure that the documentation of the product's encryption key management is detailed enough that, after reading, the product's key management hierarchy is clear and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as separate proprietary evidence rather than being included in the TSS.The evaluator shall also examine the key hierarchy section of the TSS to ensure that the formation of all DEKs is described and that the key sizes match that described by the ST author. The evaluator shall examine the key hierarchy section of the TSS to ensure that each DEK is generated or combined from keys of equal or greater security strength using one of the selected methods.
  • If the symmetric DEK is generated by an RBG, the evaluator shall review the TSS to determine that it describes how the functionality described by FCS_RBG_EXT.1 is invoked. The evaluator uses the description of the RBG functionality in FCS_RBG_EXT.1 or documentation available for the operational environment to determine that the key size being requested is greater than or equal to the key size and mode to be used for the encryption/decryption of the data.
  • If the DEK is formed from a combination, the evaluator shall verify that the TSS describes the method of combination and that this method is either an XOR or a KDF to justify that the effective entropy of each factor is preserved. The evaluator shall also verify that each combined value was originally generated from an Approved DRBG described in FCS_RBG_EXT.1.
  • If is selected, the evaluator shall ensure the TSS includes a description of the randomness extraction step.The description must include how an approved untruncated MAC function is being used for the randomness extraction step and the evaluator must verify the TSS describes that the output length (in bits) of the MAC function is at least as large as the targeted security strength (in bits) of the parameter set employed by the key establishment scheme (see Tables 1-3 of SP 800-56C).The description must include how the MAC function being used for the randomness extraction step is related to the PRF used in the key expansion and verify the TSS description includes the correct MAC function:
  • If an HMAC-hash is used in the randomness extraction step, then the same HMAC-hash (with the same hash function hash) is used as the PRF in the key expansion step.
  • If an AES-CMAC (with key length 128, 192, or 256 bits) is used in the randomness extraction step, then AES-CMAC with a 128-bit key is used as the PRF in the key expansion step.
  • The description must include the lengths of the salt values being used in the randomness extraction step and the evaluator shall verify the TSS description includes correct salt lengths:
  • If an HMAC-hash is being used as the MAC, the salt length can be any value up to the maximum bit length permitted for input to the hash function hash.
  • If an AES-CMAC is being used as the MAC, the salt length shall be the same length as the AES key (i.e. 128, 192, or 256 bits).(conditional) If a KDF is used, the evaluator shall ensure that the TSS includes a description of the key derivation function and shall verify the key derivation uses an approved derivation mode and key expansion algorithm according to SP 800-108 or SP 800-56C. - The evaluator uses the description of the RBG functionality in FCS_RBG_EXT.1 or documentation available for the operational environment to determine that the key size being generated or combined is identical to the key size and mode to be used for the encryption/decryption of the data. - If a KDF is used, the evaluator shall perform one or more of the following tests to verify the correctness of the key derivation function, depending on the modes that are supported. maps the data fields to the notations used in SP 800-108 and SP 800-56C.Table 4: Notations used in SP 800-108 and SP 800-56C

    Data Fields

    Notations

    SP 800-108

    SP 800-56C

    Pseudorandom function

    PRF

    PRF

    Counter length

    r

    r

    Length of output of PRF

    h

    h

    Length of derived keying material

    L

    L

    Length of input values

    l length

    l length

    Pseudorandom input values I

    K1 (key derivation key)

    Z (shared secret)

    Pseudorandom salt values

    n/a

    s

    Randomness extraction MAC

    n/a

    MAC

    Counter Mode Tests:The evaluator shall determine the following characteristics of the key derivation function:
  • One or more pseudorandom functions that are supported by the implementation (PRF).
  • One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r).
  • The length (in bits) of the output of the PRF (h).
  • Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h.
  • Up to two values of L that are NOT evenly divisible by h.
  • Location of the counter relative to fixed input data: before, after, or in the middle.
  • Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value.
  • Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value.
  • Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter.
  • The length (I_length) of the input values I.For each supported combination of I_length, MAC, salt, PRF, counter location, value of r, and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it. For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output.The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. Feedback Mode Tests:The evaluator shall determine the following characteristics of the key derivation function:
  • One or more pseudorandom functions that are supported by the implementation (PRF).
  • The length (in bits) of the output of the PRF (h).
  • Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h.
  • Up to two values of L that are NOT evenly divisible by h.
  • Whether or not zero-length IVs are supported.
  • Whether or not a counter is used, and if so:
  • One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r).
  • Location of the counter relative to fixed input data: before, after, or in the middle.
  • Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value.
  • Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value.
  • Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter.
  • The length (I_length) of the input values I.For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I and pseudorandom salt values. If the KDF supports zero-length IVs, five of these test vectors will be accompanied by pseudorandom IVs and the other five will use zero-length IVs. If zero-length IVs are not supported, each test vector will be accompanied by an pseudorandom IV. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it.For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. Double Pipeline Iteration Mode Tests:The evaluator shall determine the following characteristics of the key derivation function:
  • One or more pseudorandom functions that are supported by the implementation (PRF).
  • The length (in bits) of the output of the PRF (h).
  • Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h.
  • Up to two values of L that are NOT evenly divisible by h.
  • Whether or not a counter is used, and if so:
  • One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r).
  • Location of the counter relative to fixed input data: before, after, or in the middle.
  • Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value.
  • Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value.
  • Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter.
  • The length (I_length) of the input values I.For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it.For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. + All DEKs shall be <selectables> + <selectable>randomly generated</selectable> + <selectable> from the combination of a randomly generated DEK with another DEK or + salt in a way that preserves the effective entropy of each factor by <selectables> + <selectable>using an XOR operation</selectable> + <selectable> concatenating the keys and using a KDF (as described in SP + 800-108)</selectable> + <selectable id="s-dek-800-56">concatenating the keys and using a KDF (as described in SP + 800-56C)</selectable></selectables></selectable> + </selectables> with entropy corresponding to the security strength of AES key sizes of <selectables> + <selectable>128</selectable> + <selectable id="s-dek-256">256</selectable></selectables> bits. + + All DEKs shall be <assignable>generation mechanism</assignable> with entropy corresponding + to the security strength of AES key sizes of <assignable>number greater than 128 </assignable> bits. + + The intent of this requirement is to ensure that the DEK + cannot be recovered with less work than a full exhaust of the key space for AES. The + key generation capability of the TOE uses an RBG implemented on the TOE device + (FCS_RBG_EXT.1). Either 128-bit or 256-bit (or both) are allowed; the ST author makes + the selection appropriate for the device. A DEK is used in addition to the KEK so that + authentication factors can be changed without having to re-encrypt all of the user + data on the device. The ST author selects all applicable DEK + generation types implemented by the TOE. SP 800-56C specifies a two-step key derivation + procedure that employs an extraction-then-expansion technique for deriving keying + material from a shared secret generated during a key establishment scheme. The + Randomness Extraction step as described in Section 5 of SP 800-56C is followed by Key + Expansion using the key derivation functions defined in SP 800-108 (as described in + Section 6 of SP 800-56C). + + + + The evaluator shall ensure that the documentation of the product's encryption key + management is detailed enough that, after reading, the product's key management hierarchy is clear + and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure + that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as + separate proprietary evidence rather than being included in the TSS. + The evaluator shall also examine the key hierarchy section of the TSS to ensure that + the formation of all DEKs is described and that the key sizes match that described + by the ST author. The evaluator shall examine the key hierarchy section of the TSS + to ensure that each DEK is generated or combined from keys of equal or greater + security strength using one of the selected methods. + + + If the symmetric DEK is generated by an RBG, the evaluator shall review + the TSS to determine that it describes how the functionality described by + FCS_RBG_EXT.1 is invoked. The evaluator uses the description of the RBG + functionality in FCS_RBG_EXT.1 or documentation available for the operational + environment to determine that the key size being requested is greater than or + equal to the key size and mode to be used for the encryption/decryption of the + data. + If the DEK is formed from a combination, the evaluator shall verify that + the TSS describes the method of combination and that this method is either an + XOR or a KDF to justify that the effective entropy of each factor is preserved. + The evaluator shall also verify that each combined value was originally generated + from an Approved DRBG described in FCS_RBG_EXT.1. + If is selected, + the evaluator shall ensure the TSS includes a description of the + randomness extraction step. + The description must include how an approved untruncated MAC function is + being used for the randomness extraction step and the evaluator must verify the TSS + describes that the output length (in bits) of the MAC function is at least as large + as the targeted security strength (in bits) of the parameter set employed by the key + establishment scheme (see Tables 1-3 of SP 800-56C). The + description must include how the MAC function being used for the randomness + extraction step is related to the PRF used in the key expansion and verify the TSS + description includes the correct MAC function: + If an HMAC-hash is used in the randomness extraction step, then the same + HMAC-hash (with the same hash function hash) is used as the PRF in the key + expansion step. + If an AES-CMAC (with key length 128, 192, or 256 bits) is used in the + randomness extraction step, then AES-CMAC with a 128-bit key is used as the PRF + in the key expansion step. + The description must include the lengths of the salt values being used in + the randomness extraction step and the evaluator shall verify the TSS + description includes correct salt lengths: + If an HMAC-hash is being used as the MAC, the salt length can be any value + up to the maximum bit length permitted for input to the hash function + hash. + If an AES-CMAC is being used as the MAC, the salt length shall be the same + length as the AES key (i.e. 128, 192, or 256 bits). + (conditional) If a KDF is used, the evaluator shall ensure that the TSS + includes a description of the key derivation function and shall verify the key + derivation uses an approved derivation mode and key expansion algorithm according to + SP 800-108 or SP 800-56C. + + The evaluator uses the description of the RBG functionality in + FCS_RBG_EXT.1 or documentation available for the operational environment to + determine that the key size being generated or combined is identical to the key size + and mode to be used for the encryption/decryption of the + data. + If a KDF is used, the evaluator shall perform one or more of the following + tests to verify the correctness of the key derivation function, depending on the + modes that are supported. maps the data fields to the + notations used in SP 800-108 and SP 800-56C. + + : Notations used in SP 800-108 and SP + 800-56C + + + Data FieldsNotations + + SP 800-108SP + 800-56C + Pseudorandom + functionPRFPRF + Counter + lengthrr + Length of output of + PRFhh + Length of derived keying + materialLL + Length of input valuesl lengthl + length + Pseudorandom input values IK1 (key derivation + key)Z (shared secret) + Pseudorandom salt + valuesn/as + Randomness extraction + MACn/aMAC + + + Counter Mode Tests: The evaluator shall determine + the following characteristics of the key derivation function: + One or more pseudorandom functions that are supported by the + implementation (PRF). + One or more of the values {8, 16, 24, 32} that equal the length of the + binary representation of the counter (r). + The length (in bits) of the output of the PRF (h). + Minimum and maximum values for the length (in bits) of the derived keying + material (L). These values can be equal if only one value of L is supported. + These must be evenly divisible by h. + Up to two values of L that are NOT evenly divisible by h. + Location of the counter relative to fixed input data: before, after, or in + the middle. + + Counter before fixed input data: fixed input data string length (in + bytes), fixed input data string value. + Counter after fixed input data: fixed input data string length (in + bytes), fixed input data string value. + Counter in the middle of fixed input data: length of data before + counter (in bytes), length of data after counter (in bytes), value of string + input before counter, value of string input after counter. + + The length (I_length) of the input values I. + For each supported combination of I_length, MAC, salt, PRF, counter + location, value of r, and value of L, the evaluator shall generate 10 test vectors + that include pseudorandom input values I, and pseudorandom salt values. If there is + only one value of L that is evenly divisible by h, the evaluator shall generate 20 + test vectors for it. For each test vector, the evaluator shall supply this data to + the TOE in order to produce the keying material output. The + results from each test may either be obtained by the evaluator directly or by + supplying the inputs to the implementer and receiving the results in response. To + determine correctness, the evaluator shall compare the resulting values to those + obtained by submitting the same inputs to a known good implementation. + Feedback Mode Tests: The evaluator shall determine + the following characteristics of the key derivation function: + One or more pseudorandom functions that are supported by the + implementation (PRF). + The length (in bits) of the output of the PRF (h). + Minimum and maximum values for the length (in bits) of the derived keying + material (L). These values can be equal if only one value of L is supported. + These must be evenly divisible by h. + Up to two values of L that are NOT evenly divisible by h. + Whether or not zero-length IVs are supported. + Whether or not a counter is used, and if so: + + One or more of the values {8, 16, 24, 32} that equal the length of the + binary representation of the counter (r). + Location of the counter relative to fixed input data: before, after, or + in the middle. + + Counter before fixed input data: fixed input data string length (in + bytes), fixed input data string value. + Counter after fixed input data: fixed input data string length (in + bytes), fixed input data string value. + Counter in the middle of fixed input data: length of data before + counter (in bytes), length of data after counter (in bytes), value of string + input before counter, value of string input after counter. + + + The length (I_length) of the input values I. + For each supported combination of I_length, MAC, salt, PRF, counter + location (if a counter is used), value of r (if a counter is used), and value of L, + the evaluator shall generate 10 test vectors that include pseudorandom input values + I and pseudorandom salt values. If the KDF supports zero-length IVs, five of these + test vectors will be accompanied by pseudorandom IVs and the other five will use + zero-length IVs. If zero-length IVs are not supported, each test vector will be + accompanied by an pseudorandom IV. If there is only one value of L that is evenly + divisible by h, the evaluator shall generate 20 test vectors for + it. For each test vector, the evaluator shall supply this data to + the TOE in order to produce the keying material output. The results from each test + may either be obtained by the evaluator directly or by supplying the inputs to the + implementer and receiving the results in response. To determine correctness, the + evaluator shall compare the resulting values to those obtained by submitting the + same inputs to a known good implementation. + Double Pipeline Iteration Mode Tests: The + evaluator shall determine the following characteristics of the key derivation + function: + One or more pseudorandom functions that are supported by the + implementation (PRF). + The length (in bits) of the output of the PRF (h). + Minimum and maximum values for the length (in bits) of the derived keying + material (L). These values can be equal if only one value of L is supported. + These must be evenly divisible by h. + Up to two values of L that are NOT evenly divisible by h. + Whether or not a counter is used, and if so: + + One or more of the values {8, 16, 24, 32} that equal the length of the + binary representation of the counter (r). + Location of the counter relative to fixed input data: before, after, or + in the middle. + + Counter before fixed input data: fixed input data string length (in + bytes), fixed input data string value. + Counter after fixed input data: fixed input data string length (in + bytes), fixed input data string value. + Counter in the middle of fixed input data: length of data before + counter (in bytes), length of data after counter (in bytes), value of string + input before counter, value of string input after counter. + + + The length (I_length) of the input values I. + For each supported combination of I_length, MAC, salt, PRF, counter + location (if a counter is used), value of r (if a counter is used), and value of L, + the evaluator shall generate 10 test vectors that include pseudorandom input values + I, and pseudorandom salt values. If there is only one value of L that is evenly + divisible by h, the evaluator shall generate 20 test vectors for + it. For each test vector, the evaluator shall supply this data to + the TOE in order to produce the keying material output. The results from each test + may either be obtained by the evaluator directly or by supplying the inputs to the + implementer and receiving the results in response. To determine correctness, the + evaluator shall compare the resulting values to those obtained by submitting the + same inputs to a known good implementation. + - + - - + + requires the TSF to generate and manage the strength of Key Encryption Keys (KEKs). There are no management activities foreseen. There are no auditable events foreseen. - FCS_CKM.1 Cryptographic Key Generation - FCS_COP.1 Cryptographic Operation - FCS_RBG_EXT.1 Random Bit Generation + FCS_CKM.1 Cryptographic Key Generation + FCS_COP.1 Cryptographic Operation + FCS_RBG_EXT.1 Random Bit Generation + + + - The TSF shall use<selectables><selectable id="s-kek-asym"> <snip>asymmetric KEKs</snip> of <assignable>security strength greater than or equal to 112 bits </assignable> security strength</selectable><selectable id="s-kek-sym"> <snip>symmetric KEKs</snip> of <selectables><selectable id="fcs_ckm_ext.3.1_2" >128-bit</selectable><selectable id="s-kek-sym-256" >256-bit</selectable></selectables> security strength corresponding to at least the security strength of the keys encrypted by the KEK</selectable></selectables>. + The TSF shall use <selectables> + <selectable id="s-kek-asym"><snip>asymmetric KEKs</snip> of <assignable id="a-kek-asym-size">security strength greater than or equal + to 112 bits</assignable> security strength</selectable> + <selectable id="s-kek-sym"><snip>symmetric KEKs</snip> of <selectables> + <selectable>128-bit</selectable> + <selectable id="s-kek-sym-256">256-bit</selectable></selectables> security strength corresponding to at least the security strength + of the keys encrypted by the KEK</selectable> + </selectables>. + + The TSF shall use <assignable>description of KEKs</assignable>. + The ST author selects all applicable KEK types implemented by the TOE. - The TSF shall generate all KEKs using one of the following methods: <htm:ul><htm:li>Derive the KEK from a Password Authentication Factor according to - FCS_COP.1.1<htm:b>/CONDITION</htm:b> and </htm:li></htm:ul><selectables><selectable id="fcs_ckm_ext.3.2_1" >Generate the KEK using an RBG that meets this profile (as specified in - FCS_RBG_EXT.1)</selectable><selectable id="fcs_ckm_ext.3.2_2" >Generate the KEK using a key generation scheme that meets this profile - (as specified in FCS_CKM.1)</selectable><selectable id="fcs_ckm_ext.3.2_3">Combine the KEK from other KEKs in a way that preserves the effective entropy of each factor by <selectables><selectable id="fcs_ckm_ext.3.2_4" >using an XOR operation</selectable><selectable id="fcs_ckm_ext.3.2_5" >concatenating the keys and using a KDF (as described in SP - 800-108)</selectable><selectable id="fcs_ckm_ext.3.2_6" >concatenating the keys and using a KDF (as described in SP - 800-56C)</selectable><selectable id="fcs_ckm_ext.3.2_7" >encrypting one key with another</selectable></selectables></selectable></selectables>. + The TSF shall generate all KEKs using one of the following methods: + <htm:ul><htm:li>Derive the KEK from a Password Authentication Factor according to + FCS_COP.1.1<htm:b>/CONDITION</htm:b> and </htm:li></htm:ul> + <selectables linebreak="yes"> + <selectable>Generate the KEK using an RBG that meets this profile (as specified in + FCS_RBG_EXT.1)</selectable> + <selectable>Generate the KEK using a key generation scheme that meets this profile + (as specified in FCS_CKM.1)</selectable> + <selectable>Combine the KEK from other KEKs in a way that preserves the effective + entropy of each factor by <selectables> + <selectable>using an XOR operation</selectable> + <selectable>concatenating the keys and using a KDF (as described in SP + 800-108)</selectable> + <selectable>concatenating the keys and using a KDF (as described in SP + 800-56C)</selectable> + <selectable>encrypting one key with another</selectable></selectables> + </selectable> + </selectables>. + + The TSF shall generate all KEKs using one of the following methods: + <htm:ul><htm:li>Derive the KEK from a Password Authentication Factor according to + FCS_COP.1.1 and </htm:li></htm:ul> + <selectables linebreak="yes"> + <selectable>Generate the KEK using an RBG that meets this profile (as specified in + FCS_RBG_EXT.1)</selectable> + <selectable>Generate the KEK using a key generation scheme that meets this profile + (as specified in FCS_CKM.1)</selectable> + <selectable>Combine the KEK from other KEKs in a way that preserves the effective + entropy of each factor by <selectables> + <selectable>using an XOR operation</selectable> + <selectable>concatenating the keys and using a KDF (as described in SP + 800-108)</selectable> + <selectable>concatenating the keys and using a KDF (as described in SP + 800-56C)</selectable> + <selectable>encrypting one key with another</selectable> + </selectables> + </selectable> + </selectables>. + The conditioning of passwords is performed in accordance with FCS_COP.1/CONDITION. It is expected that key generation derived from conditioning, using an RBG or generation scheme, and through combination, will each be necessary to meet the requirements set out in this document. In particular, - has KEKs of each type: KEK_3 is generated, KEK_1 is derived - from a Password Authentication Factor, and KEK_2 is combined from two KEKs. In , KEK_3 may either be a symmetric key generated from an RBG or an + has KEKs of each type: KEK_3 is generated, KEK_1 is derived + from a Password Authentication Factor, and KEK_2 is combined from two KEKs. In , KEK_3 may either be a symmetric key generated from an RBG or an asymmetric key generated using a key generation scheme according to FCS_CKM.1. If combined, the ST author should describe which method of combination is used in order to justify that the effective entropy of each factor is @@ -1170,8 +2994,8 @@ The evaluator shall generate 10 private/public key pairs using the key generatio step as described in Section 5 of SP 800-56C is followed by Key Expansion using the key derivation functions defined in SP 800-108 (as described in Section 6 of SP 800-56C). - - The evaluator shall examine the key hierarchy section of the TSS to ensure that + + The evaluator shall examine the key hierarchy section of the TSS to ensure that the formation of all KEKs are described and that the key sizes match that described by the ST author. The evaluator shall examine the key hierarchy section of the TSS to ensure that each key (DEKs, software-based key storage, and KEKs) is encrypted by @@ -1198,53 +3022,97 @@ The evaluator shall generate 10 private/public key pairs using the key generatio ensure that the TSS includes a description of the key derivation function and shall verify the key derivation uses an approved derivation mode and key expansion algorithm according to SP 800-108. (conditional) If - is selected, + is selected, the evaluator shall ensure the TSS includes a description of the randomness - extraction step. The description must include How an approved untruncated MAC function is being used for the randomness + extraction step. The description must include + How an approved untruncated MAC function is being used for the randomness extraction step and the evaluator must verify the TSS describes that the output length (in bits) of the MAC function is at least as large as the targeted security strength (in bits) of the parameter set employed by the key - establishment scheme (see Tables 1-3 of SP 800-56C).How the MAC function being used for the randomness extraction step is + establishment scheme (see Tables 1-3 of SP 800-56C). + How the MAC function being used for the randomness extraction step is related to the PRF used in the key expansion and verify the TSS description - includes the correct MAC function:If an HMAC-hash is used in the randomness extraction step, then the same + includes the correct MAC function: + + If an HMAC-hash is used in the randomness extraction step, then the same HMAC-hash (with the same hash function hash) is used as the PRF in the key - expansion step.If an AES-CMAC (with key length 128, 192, or 256 bits) is used in the + expansion step. + If an AES-CMAC (with key length 128, 192, or 256 bits) is used in the randomness extraction step, then AES-CMAC with a 128-bit key is used as the - PRF in the key expansion step.The lengths of the salt values being used in the randomness extraction + PRF in the key expansion step. + + The lengths of the salt values being used in the randomness extraction step and the evaluator shall verify the TSS description includes correct salt - lengths:If an HMAC-hash is being used as the MAC, the salt length can be any + lengths: + + If an HMAC-hash is being used as the MAC, the salt length can be any value up to the maximum bit length permitted for input to the hash function - hash.If an AES-CMAC is being used as the MAC, the salt length shall be the - same length as the AES key (i.e. 128, 192, or 256 bits). + hash. + If an AES-CMAC is being used as the MAC, the salt length shall be the + same length as the AES key (i.e. 128, 192, or 256 bits). + + The evaluator shall also ensure that the documentation of the product's encryption key management is detailed enough that, after reading, the product's key management hierarchy is clear and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as - separate proprietary evidence rather than being included in the TSS. + separate proprietary evidence rather than being included in the TSS. + There are no guidance evaluation activities for this component. If a KDF is used, the evaluator shall perform one or more of the following tests to verify the correctness of the key derivation function, depending on the - modes that are supported. maps the data fields to the - notations used in SP 800-108 and SP 800-56C. : Notations used in SP 800-108 and SP 800-56C Data FieldsNotationsSP 800-108SP - 800-56CPseudorandom - functionPRFPRFCounter - lengthrrLength of output of - PRFhhLength of derived keying - materialLLLength of input - valuesI_lengthI_lengthPseudorandom input values IK1 - (key derivation key)Z (shared secret)Pseudorandom salt - valuesn/asRandomness extraction - MACn/aMACCounter Mode Tests: The evaluator shall determine the following characteristics of - the key derivation function:One or more pseudorandom functions that are supported by the - implementation (PRF).One or more of the values {8, 16, 24, 32} that equal the length of the - binary representation of the counter (r).The length (in bits) of the output of the PRF (h).Minimum and maximum values for the length (in bits) of the derived keying + modes that are supported. maps the data fields to the + notations used in SP 800-108 and SP 800-56C. + + : Notations used in SP 800-108 and SP 800-56C + + + Data FieldsNotations + SP 800-108SP + 800-56C + Pseudorandom + functionPRFPRF + Counter + lengthrr + Length of output of + PRFhh + Length of derived keying + materialLL + Length of input + valuesI_lengthI_length + Pseudorandom input values IK1 + (key derivation key)Z (shared secret) + Pseudorandom salt + valuesn/as + Randomness extraction + MACn/aMAC + + + Counter Mode Tests: + The evaluator shall determine the following characteristics of + the key derivation function: + One or more pseudorandom functions that are supported by the + implementation (PRF). + One or more of the values {8, 16, 24, 32} that equal the length of the + binary representation of the counter (r). + The length (in bits) of the output of the PRF (h). + Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. - These must be evenly divisible by h.Up to two values of L that are NOT evenly divisible by h.Location of the counter relative to fixed input data: before, after, or in - the middle.Counter before fixed input data: fixed input data string length (in - bytes), fixed input data string value.Counter after fixed input data: fixed input data string length (in - bytes), fixed input data string value.Counter in the middle of fixed input data: length of data before + These must be evenly divisible by h. + Up to two values of L that are NOT evenly divisible by h. + Location of the counter relative to fixed input data: before, after, or in + the middle. + Counter before fixed input data: fixed input data string length (in + bytes), fixed input data string value. + Counter after fixed input data: fixed input data string length (in + bytes), fixed input data string value. + Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string - input before counter, value of string input after counter.The length (I_length) of the input values I. For each supported combination of I_length, MAC, salt, PRF, + input before counter, value of string input after counter. + + The length (I_length) of the input values I. + For each supported combination of I_length, MAC, salt, PRF, counter location, value of r, and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the evaluator shall @@ -1254,17 +3122,36 @@ The evaluator shall generate 10 private/public key pairs using the key generatio evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good - implementation. Feedback Mode Tests: The evaluator shall determine the following characteristics of the key - derivation function:One or more pseudorandom functions that are supported by the - implementation (PRF).The length (in bits) of the output of the PRF (h).Minimum and maximum values for the length (in bits) of the derived keying + implementation. + Feedback Mode Tests: + The evaluator shall determine the following characteristics of the key + derivation function: + One or more pseudorandom functions that are supported by the + implementation (PRF). + The length (in bits) of the output of the PRF (h). + Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. - These must be evenly divisible by h.Up to two values of L that are NOT evenly divisible by h.Whether or not zero-length IVs are supported.Whether or not a counter is used, and if so: One or more of the values {8, 16, 24, 32} that equal the length of the - binary representation of the counter (r).Location of the counter relative to fixed input data: before, after, - or in the middle.Counter before fixed input data: fixed input data string length (in - bytes), fixed input data string value.Counter after fixed input data: fixed input data string length (in - bytes), fixed input data string value.Counter in the middle of fixed input data: length of data before + These must be evenly divisible by h. + Up to two values of L that are NOT evenly divisible by h. + Whether or not zero-length IVs are supported. + Whether or not a counter is used, and if so: + One or more of the values {8, 16, 24, 32} that equal the length of the + binary representation of the counter (r). + Location of the counter relative to fixed input data: before, after, + or in the middle. + + Counter before fixed input data: fixed input data string length (in + bytes), fixed input data string value. + Counter after fixed input data: fixed input data string length (in + bytes), fixed input data string value. + Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of - string input before counter, value of string input after counter.The length (I_length) of the input values I. For each supported combination of I_length, MAC, salt, PRF, + string input before counter, value of string input after counter. + + + + The length (I_length) of the input values I. + For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I and pseudorandom salt values. If the KDF supports zero-length IVs, @@ -1277,18 +3164,35 @@ The evaluator shall generate 10 private/public key pairs using the key generatio may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the - same inputs to a known good implementation.Double Pipeline Iteration Mode Tests: The evaluator shall - determine the following characteristics of the key derivation function:One or more pseudorandom functions that are supported by the - implementation (PRF).The length (in bits) of the output of the PRF (h).Minimum and maximum values for the length (in bits) of the derived keying + same inputs to a known good implementation. + Double Pipeline Iteration Mode Tests: The evaluator shall + determine the following characteristics of the key derivation function: + One or more pseudorandom functions that are supported by the + implementation (PRF). + The length (in bits) of the output of the PRF (h). + Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. - These must be evenly divisible by h.Up to two values of L that are NOT evenly divisible by h.Whether or not a counter is used, and if so:One or more of the values {8, 16, 24, 32} that equal the length of the - binary representation of the counter (r).Location of the counter relative to fixed input data: before, after, - or in the middle. Counter before fixed input data: fixed input data string length - (in bytes), fixed input data string value.Counter after fixed input data: fixed input data string length (in - bytes), fixed input data string value.Counter in the middle of fixed input data: length of data before + These must be evenly divisible by h. + Up to two values of L that are NOT evenly divisible by h. + Whether or not a counter is used, and if so: + One or more of the values {8, 16, 24, 32} that equal the length of the + binary representation of the counter (r). + Location of the counter relative to fixed input data: before, after, + or in the middle. + Counter before fixed input data: fixed input data string length + (in bytes), fixed input data string value. + Counter after fixed input data: fixed input data string length (in + bytes), fixed input data string value. + Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after - counter.The length (I_length) of the input values I. For each supported combination of I_length, MAC, salt, PRF, + counter. + + + + + The length (I_length) of the input values I. + For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that @@ -1301,26 +3205,46 @@ The evaluator shall generate 10 private/public key pairs using the key generatio same inputs to a known good implementation. - + - - + + requires the TSF to be able to follow specified rules to destroy plaintext keying material and cryptographic keys when no longer needed. There are no management activities foreseen. There are no auditable events foreseen. FCS_RBG_EXT.1 Random Bit Generation + + - The TSF shall destroy cryptographic keys in accordance with the specified cryptographic key destruction methods: <htm:ul><htm:li>By clearing the KEK encrypting the target key</htm:li><htm:li>In accordance with the following rules - <htm:ul><htm:li> For volatile memory, the destruction shall be executed by a single direct overwrite <selectables><selectable id="fcs_ckm_ext.4.1_1" >consisting of a pseudorandom pattern using the TSF’s - RBG</selectable><selectable id="fcs_ckm_ext.4.1_2" >consisting of zeros</selectable></selectables>.</htm:li><htm:li>For non-volatile EEPROM, the destruction shall be executed by a single + <title>The TSF shall destroy cryptographic keys in accordance with the specified cryptographic key destruction methods: <htm:br/> + <htm:ul> + <htm:li>By clearing the KEK encrypting the target key</htm:li> + <htm:li>In accordance with the following rules + <htm:ul><htm:li> For volatile memory, the destruction shall be executed by a single direct overwrite <selectables> + <selectable>consisting of a pseudorandom pattern using the TSF’s + RBG</selectable> + <selectable>consisting of zeros</selectable></selectables>.</htm:li> + <htm:li>For non-volatile EEPROM, the destruction shall be executed by a single direct overwrite consisting of a pseudo random pattern using the TSF’s RBG (as - specified in FCS_RBG_EXT.1), followed by a read-verify.</htm:li><htm:li>For non-volatile flash memory, that is not wear-leveled, the destruction - shall be executed <selectables><selectable id="fcs_ckm_ext.4.1_3" >by a single direct overwrite consisting of zeros followed by a - read-verify</selectable><selectable id="fcs_ckm_ext.4.1_4" >by a block erase that erases the reference to memory that stores - data as well as the data itself </selectable></selectables>.</htm:li><htm:li>For non-volatile flash memory, that is wear-leveled, the destruction - shall be executed <selectables><selectable id="fcs_ckm_ext.4.1_5" >by a single direct overwrite consisting of zeros</selectable><selectable id="fcs_ckm_ext.4.1_6" >by a block erase</selectable></selectables>.</htm:li><htm:li>For non-volatile memory other than EEPROM and flash, the destruction + specified in FCS_RBG_EXT.1), followed by a read-verify.</htm:li> + <htm:li>For non-volatile flash memory, that is not wear-leveled, the destruction + shall be executed <selectables> + <selectable>by a single direct overwrite consisting of zeros followed by a + read-verify</selectable> + <selectable>by a block erase that erases the reference to memory that stores + data as well as the data itself </selectable> + </selectables>.</htm:li> + <htm:li>For non-volatile flash memory, that is wear-leveled, the destruction + shall be executed <selectables> + <selectable>by a single direct overwrite consisting of zeros</selectable> + <selectable>by a block erase</selectable></selectables>.</htm:li> + <htm:li>For non-volatile memory other than EEPROM and flash, the destruction shall be executed by a single direct overwrite with a random pattern that is - changed before each write.</htm:li></htm:ul></htm:li></htm:ul> + changed before each write. + + + + The clearing indicated above applies to each intermediate storage area for plaintext key or cryptographic critical security parameter (i.e. any storage, such as memory buffers, that is included in the path of such data) upon the @@ -1330,10 +3254,22 @@ The evaluator shall generate 10 private/public key pairs using the key generatio written to volatile memory. - The TSF shall destroy all plaintext keying material and critical security parameters when no longer needed. + The TSF shall destroy all plaintext keying material and critical security + parameters when no longer needed. For the purposes of this requirement, plaintext keying material refers to authentication data, passwords, secret/private symmetric keys, private asymmetric keys, data used to derive keys, values derived from passwords, etc. + + Key destruction procedures are performed in accordance with FCS_CKM_EXT.4.1. There are multiple situations in which plaintext keying material is no longer necessary, including when the TOE is powered off, when @@ -1341,7 +3277,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio material is no longer needed by the trusted channel per the protocol, and when transitioning to the locked state (for those values derived from the Password Authentication Factor or that key material which is protected by the password-derived - or biometric-unlocked KEK according to FCS_STG_EXT.2 – see ). + or biometric-unlocked KEK according to FCS_STG_EXT.2 – see ). For keys (or key material used to derive those keys) protecting sensitive data received in the locked state, "no longer needed" includes "while in the locked state." Trusted channels may include TLS, HTTPS, DTLS, IPsec VPNs, @@ -1351,8 +3287,8 @@ The evaluator shall generate 10 private/public key pairs using the key generatio same Application Processor as the OS, REK key material must be cleared from RAM immediately after use, and at least, must be wiped when the device is locked, as the REK is part of the key hierarchy protecting sensitive data. - - The evaluator shall check to ensure the TSS lists each type of plaintext key + + The evaluator shall check to ensure the TSS lists each type of plaintext key material (DEKs, software-based key storage, KEKs, trusted channel keys, passwords, etc.) and its generation and storage location. The evaluator shall verify that the TSS describes when each type of key material is cleared (for @@ -1364,72 +3300,145 @@ The evaluator shall generate 10 private/public key pairs using the key generatio (cryptographic erase, overwrite with zeros, overwrite with random pattern, or block erase) is listed. If different types of memory are used to store the materials to be protected, the evaluator shall check to ensure that the TSS describes the clearing - procedure in terms of the memory in which the data are stored. + procedure in terms of the memory in which the data are stored. + There are no guidance evaluation activities for this component. + Evaluation Activity Note: The following tests require the developer to + provide access to a test platform that provides the evaluator with tools that are + typically not found on factory products. For each software and + firmware key clearing situation (including on system power off, on wipe function, on + disconnection of trusted channels, when no longer needed by the trusted channel per + the protocol, when transitioning to the locked state, and possibly including + immediately after use, while in the locked state) the evaluator shall repeat the + following tests. For these tests the evaluator shall utilize + appropriate development environment (e.g. a Virtual Machine) and development tools + (debuggers, simulators, etc.) to test that keys are cleared, including all copies of + the key that may have been created internally by the TOE during normal cryptographic + processing with that key. Applied to each key held as plaintext in volatile memory and subject to destruction by overwrite by the TOE (whether or not the plaintext value is subsequently encrypted for storage in volatile or non-volatile memory). In the case where the only selection made for the destruction method key was removal of - power, then this test is unnecessary. The evaluator shall: Record the value of the key in the TOE subject to clearing.Cause the TOE to perform a normal cryptographic processing with the - key from Step #1.Cause the TOE to clear the key.Cause the TOE to stop the execution but not exit.Cause the TOE to dump the entire memory of the TOE into a binary - file.Search the content of the binary file created in Step #5 for instances - of the known key value from Step #1.Break the key value from Step #1 into 3 similar sized pieces and - perform a search using each piece. Steps 1-6 ensure that the complete key does not exist anywhere in + power, then this test is unnecessary. The evaluator shall: + + Record the value of the key in the TOE subject to clearing. + Cause the TOE to perform a normal cryptographic processing with the + key from Step #1. + Cause the TOE to clear the key. + Cause the TOE to stop the execution but not exit. + Cause the TOE to dump the entire memory of the TOE into a binary + file. + Search the content of the binary file created in Step #5 for instances + of the known key value from Step #1. + Break the key value from Step #1 into 3 similar sized pieces and + perform a search using each piece. + + Steps 1-6 ensure that the complete key does not exist anywhere in volatile memory. If a copy is found, then the test fails. Step 7 ensures that partial key fragments do not remain in memory. If a fragment is found, there is a minuscule chance that it is not within the context of a key (e.g., some random bits that happen to match). If this is the case the test should be repeated with a different key in Step #1. If a fragment is found the - test fails. + test fails. + Applied to each key held in non-volatile memory and subject to destruction by overwrite by the TOE. The evaluator shall use special tools (as needed), - provided by the TOE developer if necessary, to view the key storage location: Record the value of the key in the TOE subject to clearing.Cause the TOE to perform a normal cryptographic processing with the - key from Step #1.Cause the TOE to clear the key.Search the non-volatile memory the key was stored in for instances of + provided by the TOE developer if necessary, to view the key storage location: + + Record the value of the key in the TOE subject to clearing. + Cause the TOE to perform a normal cryptographic processing with the + key from Step #1. + Cause the TOE to clear the key. + Search the non-volatile memory the key was stored in for instances of the known key value from Step #1. If a copy is found, then the test - fails.Break the key value from Step #1 into 3 similar sized pieces and + fails. + Break the key value from Step #1 into 3 similar sized pieces and perform a search using each piece. If a fragment is found then the test is repeated (as described for test 1 above), and if a fragment is found in the - repeated test then the test fails. + repeated test then the test fails. + + + Applied to each key held as non-volatile memory and subject to destruction by overwrite by the TOE. The evaluator shall use special tools (as needed), - provided by the TOE developer if necessary, to view the key storage location: Record the storage location of the key in the TOE subject to - clearing.Cause the TOE to perform a normal cryptographic processing with the - key from Step #1.Cause the TOE to clear the key.Read the storage location in Step #1 of non-volatile memory to ensure - the appropriate pattern is utilized. The test succeeds if correct pattern is used to overwrite the key in + provided by the TOE developer if necessary, to view the key storage location: + + Record the storage location of the key in the TOE subject to + clearing. + Cause the TOE to perform a normal cryptographic processing with the + key from Step #1. + Cause the TOE to clear the key. + Read the storage location in Step #1 of non-volatile memory to ensure + the appropriate pattern is utilized. + + The test succeeds if correct pattern is used to overwrite the key in the memory location. If the pattern is not found the test fails. - + - - + + requires the TSF to implement a cryptographic or other mechanism to make TSF data unreadable. The following actions could be considered for the management functions in FMT: - TSF wipe of protected data.TSF wipe of enterprise data. + + TSF wipe of protected data. + TSF wipe of enterprise data. + The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - Failure of the wipe. + + Failure of the wipe. + FCS_RBG_EXT.1 Random Bit Generation + - The TSF shall wipe all protected data by<selectables><selectable id="fcs_ckm_ext.5.1_1" >Cryptographically erasing the encrypted DEKs or the KEKs in non-volatile memory by following the requirements in FCS_CKM_EXT.4.1</selectable><selectable id="fcs_ckm_ext.5.1_2">Overwriting all PD according to the following rules: <htm:ul><htm:li>For EEPROM, the destruction shall be executed by a single direct overwrite consisting of a pseudo random pattern using the TSF’s RBG (as specified in FCS_RBG_EXT.1, followed by a read-verify. </htm:li><htm:li>For flash memory, that is not wear-leveled, the destruction shall be executed <selectables><selectable id="fcs_ckm_ext.5.1_3" >by a single direct overwrite consisting of zeros followed by a read-verify</selectable><selectable id="fcs_ckm_ext.5.1_4" >by a block erase that erases the reference to memory that stores data as well as the data itself</selectable></selectables>. </htm:li><htm:li>For flash memory, that is wear-leveled, the destruction shall be executed <selectables><selectable id="fcs_ckm_ext.5.1_5" >by a single direct overwrite consisting of zeros</selectable><selectable id="fcs_ckm_ext.5.1_6" >by a block erase</selectable></selectables>. </htm:li><htm:li>For non-volatile memory other than EEPROM and flash, the destruction shall be executed by a single direct overwrite with a random pattern that is changed before each write. </htm:li></htm:ul></selectable></selectables>. - + The TSF shall wipe all protected data by <selectables linebreak="yes"> + <selectable>Cryptographically erasing the encrypted DEKs or the KEKs in non-volatile memory by following the requirements in FCS_CKM_EXT.4.1</selectable> + <selectable>Overwriting all PD according to the following rules: <htm:ul> + <htm:li>For EEPROM, the destruction shall be executed by a single direct overwrite consisting of a pseudo random pattern using the TSF’s RBG (as specified in FCS_RBG_EXT.1, followed by a read-verify. </htm:li> + <htm:li>For flash memory, that is not wear-leveled, the destruction shall be executed <selectables> + <selectable>by a single direct overwrite consisting of zeros followed by a read-verify</selectable> + <selectable>by a block erase that erases the reference to memory that stores data as well as the data itself</selectable></selectables>. </htm:li> + <htm:li>For flash memory, that is wear-leveled, the destruction shall be executed <selectables> + <selectable>by a single direct overwrite consisting of zeros</selectable> + <selectable>by a block erase</selectable></selectables>. </htm:li> + <htm:li>For non-volatile memory other than EEPROM and flash, the destruction shall be executed by a single direct overwrite with a random pattern that is changed before each write. </htm:li> + </htm:ul> + </selectable> + </selectables>. + + Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well. - The TSF shall perform a power cycle on conclusion of the wipe procedure. - - The evaluator shall check to ensure the TSS describes how the device is wiped, the type of clearing procedure that is performed (cryptographic erase or overwrite) and, if overwrite is performed, the overwrite procedure (overwrite with zeros, overwrite three or more times by a different alternating pattern, overwrite with random pattern, or block erase). - If different types of memory are used to store the data to be protected, the evaluator shall check to ensure that the TSS describes the clearing procedure in terms of the memory in which the data are stored (for example, data stored on flash are cleared by overwriting once with zeros, while data stored on the internal persistent storage device are cleared by overwriting three times with a random pattern that is changed before each write). + The TSF shall perform a power cycle on conclusion of the wipe procedure. + + + + The evaluator shall check to ensure the TSS describes how the device is wiped, the type of clearing procedure that is performed (cryptographic erase or overwrite) and, if overwrite is performed, the overwrite procedure (overwrite with zeros, overwrite three or more times by a different alternating pattern, overwrite with random pattern, or block erase). + If different types of memory are used to store the data to be protected, the evaluator shall check to ensure that the TSS describes the clearing procedure in terms of the memory in which the data are stored (for example, data stored on flash are cleared by overwriting once with zeros, while data stored on the internal persistent storage device are cleared by overwriting three times with a random pattern that is changed before each write). + - The evaluator shall verify that the AGD guidance describes how to enable encryption, if it is not enabled by default. Additionally the evaluator shall verify that the AGD guidance describes how to initiate the wipe command. + The evaluator shall verify that the AGD guidance describes how to enable encryption, if it is not enabled by default. Additionally the evaluator shall verify that the AGD guidance describes how to initiate the wipe command. + + Evaluation Activity Note: + The following test may require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products. - The evaluator shall perform one of the following tests. The test before and after the wipe command shall be identical. This test shall be repeated for each type of memory used to store the data to be protected. + The evaluator shall perform one of the following tests. The test before and after the wipe command shall be identical. This test shall be repeated for each type of memory used to store the data to be protected. + + For File-based Methods: + The evaluator shall enable encryption according to the AGD guidance. The evaluator shall create a user data (protected data or sensitive data) file, for example, by using an application. The evaluator shall use a tool provided by the developer to examine this data stored in memory (for example, by examining a decrypted files). The evaluator shall initiate the wipe command according to the AGD guidance provided for FMT_SMF.1. The evaluator shall use a tool provided by the developer to examine the same data location in memory to verify that the data has been wiped according to the method described in the TSS (for example, the files are still encrypted and cannot be accessed). + For Volume-based Methods: + The evaluator shall enable encryption according to the AGD guidance. The evaluator shall create a unique data string, for example, by using an application. The evaluator shall use a tool provided by the developer to search decrypted data for the unique string. The evaluator shall initiate the wipe command according to the AGD guidance provided for FMT_SMF.1. The evaluator shall use a tool provided by the developer to search for the same unique string in decrypted memory to verify that the data has been wiped according to the method described in the TSS (for example, the files are still encrypted and cannot be accessed). + + The evaluator shall cause the device to wipe and verify that the wipe concludes with a power cycle. @@ -1437,32 +3446,38 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - - - - Failure of the wipe - none - - - + + Failure of the wipenone + - - + + requires the TSF to generate salts in a specified manner. There are no management activities foreseen. There are no auditable events foreseen. FCS_RBG_EXT.1 Random Bit Generation + + - The TSF shall generate all salts using an RBG that meets FCS_RBG_EXT.1. + The TSF shall generate all salts using an RBG that meets FCS_RBG_EXT.1. This requirement refers only to salt generation. In the examples given, a salt may be used as part of the scheme/algorithm. Requirements on nonces or ephemeral keys are provided elsewhere, if needed. The list below is provided for clarity, in order to give examples of where the TSF may be generating cryptographic salts; it is not exhaustive nor is it intended to mandate implementation of all of these schemes/algorithms. Cryptographic salts are generated for various uses - including: RSASSA-PSS signature generationDSA signature generationECDSA signature generationDH static key agreement schemePBKDFKey Agreement Scheme in NIST SP 800-56BAES GCM - - The evaluator shall verify that the TSS contains a description regarding the + including: + RSASSA-PSS signature generation + DSA signature generation + ECDSA signature generation + DH static key agreement scheme + PBKDF + Key Agreement Scheme in NIST SP 800-56B + AES GCM + + + + The evaluator shall verify that the TSS contains a description regarding the salt generation, including which algorithms on the TOE require salts. The evaluator shall confirm that the salt is generated using an RBG described in FCS_RBG_EXT.1. For PBKDF derivation of KEKs, this evaluation activity may be performed in @@ -1471,127 +3486,197 @@ The evaluator shall generate 10 private/public key pairs using the key generatio There are no test evaluation activities for this component. - + - - + + requires the TSF to prevent the reading or exporting of REKs. There are no management activities foreseen. There are no auditable events foreseen. FCS_CKM_EXT.1 Cryptographic Key Support + - A REK shall not be able to be read from or exported from the hardware. - If is selected in FCS_CKM_EXT.1.1, - FCS_CKM_EXT.7 must be included in the ST. Note that if is + A REK shall not be able to be read from or exported from the hardware. + If is selected in FCS_CKM_EXT.1.1, + FCS_CKM_EXT.7 must be included in the ST. Note that if is selected in FCS_CKM_EXT.1.1 it implicitly meets FCS_CKM_EXT.7. The lack of a public/documented API for importing or exporting, when a private/undocumented API exists, is not sufficient to meet this requirement. - + The evaluation activity for this component is performed in conjunction with the evaluation activity for FCS_CKM_EXT.1. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component. - - - - - - The TSF shall perform <htm:b>conditioning</htm:b> in accordance with a specified cryptographic algorithm <htm:b>HMAC-<selectables><selectable id="fcs_cop.1.1_CONDITION_1" >SHA-256</selectable><selectable id="fcs_cop.1.1_CONDITION_2" >SHA-384</selectable><selectable id="fcs_cop.1.1_CONDITION_3" >SHA-512</selectable></selectables> using a salt, and <selectables><selectable id="fcs_cop.1.1_CONDITION_4">PBKDF2 with <assignable>number of iterations </assignable> iterations</selectable><selectable id="fcs_cop.1.1_CONDITION_7" ><assignable>key stretching function </assignable></selectable><selectable id="fcs_cop.1.1_CONDITION_8" exclusive="yes" >no other function</selectable></selectables> and output</htm:b> cryptographic key sizes <htm:b><selectables><selectable id="fcs_cop.1.1_CONDITION_9" >128</selectable><selectable id="fcs_cop.1.1_CONDITION_10" >256</selectable></selectables></htm:b> that meet the following: <htm:b><selectables><selectable id="fcs_cop.1.1_CONDITION_11" >NIST SP 800-132</selectable><selectable id="fcs_cop.1.1_CONDITION_12" exclusive="yes" >no standard</selectable></selectables>.</htm:b> - The key cryptographic key sizes in the third selection should - be made to correspond to the KEK key sizes selected in FCS_CKM_EXT.3. - This password must be conditioned into a string of bits that forms - the submask to be used as input into the KEK. Conditioning can be performed using one - of the identified hash functions and may include a key stretching function; the method - used is selected by the ST author. If selected, NIST SP 800-132 requires the use of a - pseudorandom function (PRF) consisting of HMAC with an approved hash function. The ST - author selects the hash function used, also includes the appropriate requirements for - HMAC and the hash function. Appendix A of NIST SP 800-132 - recommends setting the iteration count in order to increase the computation needed to - derive a key from a password and, therefore, increase the workload of performing a - dictionary attack. - - The evaluator shall check that the TSS describes the method by which the password - is first encoded and then fed to the SHA algorithm and verify the SHA algorithm - matches the first selection. If a key stretching function, such as - PBKDF2, is selected the settings for the algorithm (padding, blocking, etc.) shall - be described. The evaluator shall verify that the TSS contains a description of how - the output of the hash function or key stretching function is used to form the - submask that will be input into the function and is the same length as the KEK as - specified in FCS_CKM_EXT.3. If any manipulation of the key is - performed in forming the submask that will be used to form the KEK, that process - shall be described in the TSS. - There are no guidance evaluation activities for this component. - There are no test evaluation activities for this component. No explicit testing of the - formation of the submask from the input password is required. - - - + - - + - The TSF shall perform [ <htm:i>encryption/decryption</htm:i> ] in accordance with a specified cryptographic algorithm: [ <htm:i><htm:br/><htm:ul><htm:li>AES-CBC (as defined in FIPS PUB 197, and NIST SP 800-38A) mode</htm:li><htm:li>AES-CCMP (as defined in FIPS PUB 197, NIST SP 800-38C and IEEE 802.11-2012), and</htm:li><htm:li><selectables><selectable id="fcs_cop.1.1_ENCRYPT_1" >AES Key Wrap (KW) (as defined in NIST SP 800-38F)</selectable><selectable id="fcs_cop.1.1_ENCRYPT_2" >AES Key Wrap with Padding (KWP) (as defined in NIST SP 800-38F)</selectable><selectable id="fcs_cop.1.1_ENCRYPT_3" >AES-GCM (as defined in NIST SP 800-38D)</selectable><selectable id="fcs_cop.1.1_ENCRYPT_4" >AES-CCM (as defined in NIST SP 800-38C)</selectable><selectable id="fcs_cop.1.1_ENCRYPT_5" >AES-XTS (as defined in NIST SP 800-38E) mode</selectable><selectable id="fcs_cop.1.1_ENCRYPT_6" >AES-CCMP-256 (as defined in NIST SP800-38C and IEEE 802.11ac-2013)</selectable><selectable id="fcs_cop.1.1_ENCRYPT_7" >AES-GCMP-256 (as defined in NIST SP800-38D and IEEE 802.11ac-2013)</selectable><selectable id="fcs_cop.1.1_ENCRYPT_8" exclusive="yes" >no other modes</selectable></selectables></htm:li></htm:ul></htm:i> ] and cryptographic key sizes [ <htm:i>128-bit key sizes and <selectables><selectable id="s-encrypt-256" >256-bit key sizes</selectable><selectable id="fcs_cop.1.1_ENCRYPT_9" exclusive="yes" >no other key sizes</selectable></selectables></htm:i> ]. + The TSF shall perform [<htm:i>encryption/decryption</htm:i>] in accordance with a specified + cryptographic algorithm: [<htm:i> <htm:br/> + <htm:ul> + <htm:li>AES-CBC (as defined in FIPS PUB 197, and NIST SP 800-38A) mode</htm:li> + <htm:li>AES-CCMP (as defined in FIPS PUB 197, NIST SP 800-38C and IEEE 802.11-2012), and</htm:li> + <htm:li><selectables linebreak="yes"> + <selectable>AES Key Wrap (KW) (as defined in NIST SP 800-38F)</selectable> + <selectable>AES Key Wrap with Padding (KWP) (as defined in NIST SP 800-38F)</selectable> + <selectable>AES-GCM (as defined in NIST SP 800-38D)</selectable> + <selectable>AES-CCM (as defined in NIST SP 800-38C)</selectable> + <selectable>AES-XTS (as defined in NIST SP 800-38E) mode</selectable> + <selectable>AES-CCMP-256 (as defined in NIST SP800-38C and IEEE 802.11ac-2013)</selectable> + <selectable>AES-GCMP-256 (as defined in NIST SP800-38D and IEEE 802.11ac-2013)</selectable> + <selectable exclusive="yes">no other modes</selectable></selectables></htm:li> + </htm:ul> </htm:i>] and cryptographic key sizes [<htm:i>128-bit key sizes and <selectables> + <selectable id="s-encrypt-256">256-bit key sizes</selectable> + <selectable exclusive="yes">no other key sizes</selectable></selectables></htm:i>]. - For the first selection, the ST author should choose the mode or modes in which AES operates. For the second selection, the ST author should choose the key sizes that are supported by this functionality. 128-bit CBC and CCMP are required in order to comply with the . - Note that to comply with the , AES CCMP (which uses AES in CCM as specified in SP 800-38C) with cryptographic key size of 128 bits must be implemented. If CCM is only implemented to support CCMP for WLAN, AES-CCM does not need be selected. Optionally, AES-CCMP-256 or AES-GCMP-256 with cryptographic key size of 256 bits may be implemented. + For the first selection, the ST author should choose the mode or modes in which AES operates. For the second selection, the ST author should choose the key sizes that are supported by this functionality. 128-bit CBC and CCMP are required in order to comply with the . + Note that to comply with the , AES CCMP (which uses AES in CCM as specified in SP 800-38C) with cryptographic key size of 128 bits must be implemented. If CCM is only implemented to support CCMP for WLAN, AES-CCM does not need be selected. Optionally, AES-CCMP-256 or AES-GCMP-256 with cryptographic key size of 256 bits may be implemented. - - There are no TSS evaluation activities for this component. - There are no guidance evaluation activities for this component. + + There are no TSS evaluation activities for this component. + There are no guidance evaluation activities for this component. + - + Evaluation Activity Note: The following tests require the developer to + provide access to a test platform that provides the evaluator with tools that are + typically not found on factory products. + AES-CBC Tests AES-CBC Known Answer Tests There are four Known Answer Tests (KATs), described below. In all KATs, the plaintext, ciphertext, and IV values shall be 128-bit blocks. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same - inputs to a known good implementation. + inputs to a known good implementation. + + KAT-1. To test the encrypt functionality of AES-CBC, the evaluator shall + supply a set of 10 plaintext values and obtain the ciphertext value that + results from AES-CBC encryption of the given plaintext using a key value of + all zeros and an IV of all zeros. Five plaintext values shall be encrypted + with a 128-bit all-zeros key, and the other five shall be encrypted with a + 256-bit all-zeros key. To test the decrypt functionality + of AES-CBC, the evaluator shall perform the same test as for encrypt, using + 10 ciphertext values as input and AES-CBC decryption. + + KAT-2. To test the encrypt functionality of AES-CBC, the evaluator shall + supply a set of 10 key values and obtain the ciphertext value that results + from AES-CBC encryption of an all-zeros plaintext using the given key value + and an IV of all zeros. Five of the keys shall be 128-bit keys, and the + other five shall be 256-bit keys. To test the decrypt + functionality of AES-CBC, the evaluator shall perform the same test as for + encrypt, using an all-zero ciphertext value as input and AES-CBC decryption. + + KAT-3. To test the encrypt functionality of AES-CBC, the evaluator shall + supply the two sets of key values described below and obtain the ciphertext + value that results from AES encryption of an all-zeros plaintext using the + given key value and an IV of all zeros. The first set of keys shall have 128 + 128-bit keys, and the second set shall have 256 256-bit keys. Key i in each + set shall have the leftmost i bits be ones and the rightmost N-i bits be + zeros, for i in [1,N]. To test the decrypt functionality + of AES-CBC, the evaluator shall supply the two sets of key and ciphertext + value pairs described below and obtain the plaintext value that results from + AES-CBC decryption of the given ciphertext using the given key and an IV of + all zeros. The first set of key or ciphertext pairs shall have 128 128-bit + key or ciphertext pairs, and the second set of key or ciphertext pairs shall have + 256 256-bit key or ciphertext pairs. Key i in each set shall have the leftmost + i bits be ones and the rightmost N-i bits be zeros, for i in [1,N]. The + ciphertext value in each pair shall be the value that results in an + all-zeros plaintext when decrypted with its corresponding key. + + KAT-4. To test the encrypt functionality of AES-CBC, the evaluator shall + supply the set of 128 plaintext values described below and obtain the two + ciphertext values that result from AES-CBC encryption of the given plaintext + using a 128-bit key value of all zeros with an IV of all zeros and using a + 256-bit key value of all zeros with an IV of all zeros, respectively. + Plaintext value i in each set shall have the leftmost i bits be ones and the + rightmost 128-i bits be zeros, for i in [1,128]. To test + the decrypt functionality of AES-CBC, the evaluator shall perform the same + test as for encrypt, using ciphertext values of the same form as the + plaintext in the encrypt test as input and AES-CBC decryption. + + + AES-CBC Multi-Block Message Test The evaluator shall test - the encrypt functionality by encrypting an i-block message where 1 < i < = + the encrypt functionality by encrypting an i-block message where 1 < i <= 10. The evaluator shall choose a key, an IV and plaintext message of length i blocks and encrypt the message, using the mode to be tested, with the chosen key and IV. The ciphertext shall be compared to the result of encrypting the same plaintext message with the same key and IV using a known good implementation. The evaluator shall also test the decrypt functionality for - each mode by decrypting an i-block message where 1 < i < = 10. The + each mode by decrypting an i-block message where 1 < i <= 10. The evaluator shall choose a key, an IV and a ciphertext message of length i blocks and decrypt the message, using the mode to be tested, with the chosen key and IV. The plaintext shall be compared to the result of decrypting the same ciphertext message with the same key and IV using a known good implementation. + AES-CBC Monte Carlo Tests The evaluator shall test the encrypt functionality using a set of 200 plaintext, IV, and key 3-tuples. 100 of these shall use 128 bit keys, and 100 shall use 256 bit keys. The plaintext and IV values shall be 128-bit blocks. For each 3-tuple, 1000 iterations shall be - run as follows: # Input: PT, IV, Key for i = 1 to 1000: if i == 1: CT[1] = + run as follows: + # Input: PT, IV, Key for i = 1 to 1000: if i == 1: CT[1] = AES-CBC-Encrypt(Key, IV, PT) PT = IV else: CT[i] = AES-CBC-Encrypt(Key, PT) PT - = CT[i-1] The ciphertext computed in the 1000th iteration + = CT[i-1] + The ciphertext computed in the 1000th iteration (i.e. CT[1000]) is the result for that trial. This result shall be compared to the result of running 1000 iterations with the same values using a known good implementation. The evaluator shall test the decrypt functionality using the same test as for encrypt, exchanging CT and PT and replacing AES-CBC-Encrypt with AES-CBC-Decrypt. - + + AES-CCM Tests The evaluator shall test the generation-encryption and decryption-verification functionality of AES-CCM for the following input - parameter and tag lengths: 128 bit and 256 bit keysTwo payload lengths. One payload length shall be the + parameter and tag lengths: + + 128 bit and 256 bit keys + + Two payload lengths. One payload length shall be the shortest supported payload length, greater than or equal to zero bytes. The other payload length shall be the longest supported payload length, less - than or equal to 32 bytes (256 bits). Two or three associated data lengths. One associated + than or equal to 32 bytes (256 bits). + + Two or three associated data lengths. One associated data length shall be 0, if supported. One associated data length shall be the shortest supported payload length, greater than or equal to zero bytes. One associated data length shall be the longest supported payload length, less than or equal to 32 bytes (256 bits). If the implementation supports an associated data length of 216 bytes, an associated data - length of 216 bytes shall be tested. Nonce lengths. All supported nonce lengths between 7 - and 13 bytes, inclusive, shall be tested. Tag lengths. All supported tag lengths of 4, 6, 8, 10, - 12, 14 and 16 bytes shall be tested. To test the generation-encryption functionality of AES-CCM, the - evaluator shall perform the following four tests: To determine correctness in each of the above tests, the evaluator + length of 216 bytes shall be tested. + + Nonce lengths. All supported nonce lengths between 7 + and 13 bytes, inclusive, shall be tested. + + Tag lengths. All supported tag lengths of 4, 6, 8, 10, + 12, 14 and 16 bytes shall be tested. + To test the generation-encryption functionality of AES-CCM, the + evaluator shall perform the following four tests: + + For EACH supported key and associated data length and ANY supported + payload, nonce and tag length, the evaluator shall supply one key value, one + nonce value and 10 pairs of associated data and payload values and obtain + the resulting ciphertext. + + For EACH supported key and payload length and ANY supported associated + data, nonce and tag length, the evaluator shall supply one key value, one + nonce value and 10 pairs of associated data and payload values and obtain + the resulting ciphertext. + + For EACH supported key and nonce length and ANY supported associated + data, payload and tag length, the evaluator shall supply one key value and + 10 associated data, payload and nonce value 3-tuples and obtain the + resulting ciphertext. + + For EACH supported key and tag length and ANY supported associated data, + payload and nonce length, the evaluator shall supply one key value, one + nonce value and 10 pairs of associated data and payload values and obtain + the resulting ciphertext. + To determine correctness in each of the above tests, the evaluator shall compare the ciphertext with the result of generation-encryption of the same inputs with a known good implementation. To test the decryption-verification functionality of AES-CCM, for EACH combination of @@ -1601,56 +3686,92 @@ The evaluator shall generate 10 private/public key pairs using the key generatio decrypted payload. The evaluator shall supply 10 tuples that should FAIL and 5 that should PASS per set of 15. - + + AES-GCM Test The evaluator shall + test the authenticated encrypt functionality of AES-GCM for each combination of + the following input parameter lengths: + + 128 bit and 256 bit keys + + Two plaintext lengths. One of the plaintext lengths shall + be a non-zero integer multiple of 128 bits, if supported. The other plaintext + length shall not be an integer multiple of 128 bits, if supported. + + Three AAD lengths. One AAD length shall be 0, if + supported. One AAD length shall be a non-zero integer multiple of 128 bits, if + supported. One AAD length shall not be an integer multiple of 128 bits, if + supported. + + Two IV lengths. If 96 bit IV is supported, 96 bits shall + be one of the two IV lengths tested. + The evaluator shall test the encrypt functionality using a set of 10 key, plaintext, AAD, and IV tuples for each combination of parameter lengths above and obtain the ciphertext value and tag that results from AES-GCM authenticated encrypt. Each supported tag length shall be tested at least once per set of 10. The IV value may be supplied by the evaluator or the implementation being tested, as long as it is known. + The evaluator shall test the decrypt functionality using a set of 10 key, ciphertext, tag, AAD, and IV 5-tuples for each combination of parameter lengths above and obtain a Pass/Fail result on authentication and the decrypted plaintext if Pass. The set shall include five tuples that Pass and five that Fail. - - + The results from each test may either be obtained by the evaluator + directly or by supplying the inputs to the implementer and receiving the results + in response. To determine correctness, the evaluator shall compare the resulting + values to those obtained by submitting the same inputs to a known good + implementation. + XTS-AES Test The evaluator shall test the encrypt functionality of XTS-AES for each - combination of the following input parameter lengths: 256 bit (for AES-128) and 512 bit (for AES-256) - keysThree data unit (i.e. plaintext) lengths. One of the + combination of the following input parameter lengths: + + 256 bit (for AES-128) and 512 bit (for AES-256) + keys + Three data unit (i.e. plaintext) lengths. One of the data unit lengths shall be a non-zero integer multiple of 128 bits, if supported. One of the data unit lengths shall be an integer multiple of 128 bits, if supported. The third data unit length shall be either the longest supported data unit length or 216 bits, whichever is smaller. - using a set of 100 (key, plaintext and 128-bit random tweak value) + + using a set of 100 (key, plaintext and 128-bit random tweak value) 3-tuples and obtain the ciphertext that results from XTS-AES encrypt. The evaluator may supply a data unit sequence number instead of the tweak value if the implementation supports it. The data unit sequence number is a base-10 number ranging between 0 and 255 that implementations - convert to a tweak value internally. + convert to a tweak value internally. The evaluator shall test the decrypt functionality of XTS-AES using the same test as for encrypt, replacing plaintext values with ciphertext values and XTS-AES encrypt with XTS-AES decrypt. - - + + AES Key Wrap (AES-KW) and Key Wrap with Padding (AES-KWP) + Test The evaluator shall test the authenticated encryption functionality of - AES-KW for EACH combination of the following input parameter lengths: 128 and 256 bit key encryption keys (KEKs)Three plaintext lengths. One of the plaintext lengths + AES-KW for EACH combination of the following input parameter lengths: + + 128 and 256 bit key encryption keys (KEKs) + Three plaintext lengths. One of the plaintext lengths shall be two semi-blocks (128 bits). One of the plaintext lengths shall be three semi-blocks (192 bits). The third data unit length shall be the longest supported plaintext length less than or equal to 64 semi-blocks - (4096 bits). using a set of 100 key and plaintext pairs and obtain the ciphertext + (4096 bits). + using a set of 100 key and plaintext pairs and obtain the ciphertext that results from AES-KW authenticated encryption. To determine correctness, the evaluator shall use the AES-KW authenticated-encryption function of a known good - implementation. + implementation. The evaluator shall test the authenticated-decryption functionality of AES-KW using the same test as for authenticated-encryption, replacing plaintext values with ciphertext values and AES-KW authenticated-encryption with AES-KW - authenticated-decryption. + authenticated-decryption. The evaluator shall test the authenticated-encryption functionality of AES-KWP using the same test as for AES-KW authenticated-encryption with the - following change in the three plaintext lengths: One plaintext length shall be one octet. One plaintext length shall be - 20 octets (160 bits).One plaintext length shall be the longest supported plaintext length - less than or equal to 512 octets (4096 bits). + following change in the three plaintext lengths: + One plaintext length shall be one octet. One plaintext length shall be + 20 octets (160 bits). + One plaintext length shall be the longest supported plaintext length + less than or equal to 512 octets (4096 bits). + + The evaluator shall test the authenticated-decryption functionality of AES-KWP using the same test as for AES-KWP authenticated-encryption, replacing plaintext values with ciphertext values and AES-KWP authenticated-encryption @@ -1659,19 +3780,62 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - + - - + - The TSF shall perform [ <htm:i>cryptographic hashing</htm:i> ] in accordance with a specified cryptographic algorithm [ <htm:i>SHA-1 and <selectables><selectable id="s-sha-256" >SHA-256</selectable><selectable id="s-sha-384" >SHA-384</selectable><selectable id="s-sha-512" >SHA-512</selectable><selectable id="fcs_cop.1.1_HASH_1" exclusive="yes" >no other algorithms</selectable></selectables></htm:i> ] and <htm:b>message digest</htm:b> sizes [ <htm:i>160 and <selectables><selectable id="s-hash-size-256" >256 bits</selectable><selectable id="s-hash-size-384" >384 bits</selectable><selectable id="s-hash-size-512" >512 bits</selectable><selectable id="fcs_cop.1.1_HASH_2" exclusive="yes" >no other message digest sizes</selectable></selectables></htm:i> ] that meet the following: [ <htm:i>FIPS Pub - 180-4</htm:i> ]. + The TSF shall perform [<htm:i>cryptographic hashing</htm:i>] in + accordance with a specified cryptographic algorithm [<htm:i>SHA-1 and <selectables> + <selectable id="s-sha-256">SHA-256</selectable> + <selectable id="s-sha-384">SHA-384</selectable> + <selectable id="s-sha-512">SHA-512</selectable> + <selectable exclusive="yes">no other algorithms</selectable></selectables></htm:i>] and <refinement>message digest</refinement> sizes + [<htm:i>160 and <selectables> + <selectable id="s-hash-size-256">256 bits</selectable> + <selectable id="s-hash-size-384">384 bits</selectable> + <selectable id="s-hash-size-512">512 bits</selectable> + <selectable exclusive="yes">no other message digest sizes</selectable></selectables></htm:i>] that meet the following: [<htm:i>FIPS Pub + 180-4</htm:i>]. + <rule id="r-sha256"> + <or> + <and> + <ref-id>s-sha-256</ref-id><ref-id>s-hash-size-256</ref-id> + </and> + <and> + <not><ref-id>s-sha-256</ref-id></not> + <not><ref-id>s-hash-size-256</ref-id></not> + </and> + </or> + </rule> + <rule id="r-sha384"> + <or> + <and> + <ref-id>s-sha-384</ref-id><ref-id>s-hash-size-384</ref-id> + </and> + <and> + <not><ref-id>s-sha-384</ref-id></not> + <not><ref-id>s-hash-size-384</ref-id></not> + </and> + </or> + </rule> + <rule id="r-sha512"> + <or> + <and> + <ref-id>s-sha-512</ref-id><ref-id>s-hash-size-512</ref-id> + </and> + <and> + <not><ref-id>s-sha-512</ref-id></not> + <not><ref-id>s-hash-size-512</ref-id></not> + </and> + </or> + </rule> + Per NIST SP 800-131A, SHA-1 for generating digital signatures is no longer allowed, and SHA-1 for verification of digital signatures is strongly discouraged as there may be risk in accepting these signatures. It is expected that vendors will implement SHA-2 algorithms in accordance with SP 800-131A. SHA-1 is currently required in order to comply with the - . Vendors are strongly encouraged to implement updated + . Vendors are strongly encouraged to implement updated protocols that support the SHA-2 family; until updated protocols are supported, this PP allows support for SHA-1 implementations in compliance with SP 800-131A. The intent of this requirement is to specify the hashing @@ -1684,44 +3848,53 @@ The evaluator shall generate 10 private/public key pairs using the key generatio the bit­oriented mode. In this mode the TSF hashes messages of arbitrary length. The TSF may implement either bit-oriented or byte-oriented; both implementations are not required. - - The evaluator shall check that the association of the hash function with other + + The evaluator shall check that the association of the hash function with other TSF cryptographic functions (for example, the digital signature verification function) is documented in the TSS. The evaluator shall check that the TSS indicates if the hashing function is implemented in bit-oriented or - byte-oriented mode. + byte-oriented mode. + The evaluator checks the AGD documents to determine that any configuration that is required to be done to configure the functionality for the required hash - sizes is present. + sizes is present. + + Evaluation Activity Note: The following tests require the developer to + provide access to a test platform that provides the evaluator with tools that are + typically not found on factory products. The evaluator shall + perform all of the following tests for each hash algorithm implemented by the TSF + and used to satisfy the requirements of this PP. As there are different tests for + each mode, an indication is given in the following sections for the bit­oriented vs. + the byte­oriented tests. Short Messages Test: Bit-oriented Mode The evaluators devise an input set consisting of m+1 messages, where m is the block length of the hash algorithm. The length of the messages ranges sequentially from 0 to m bits. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that - the correct result is produced when the messages are provided to the TSF. + the correct result is produced when the messages are provided to the TSF. Short Messages Test: Byte-oriented Mode The evaluators devise an input set consisting of m/8+1 messages, where m is the block length of the hash algorithm. The length of the messages range sequentially from 0 to m/8 bytes, with each message being an integral number of bytes. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct - result is produced when the messages are provided to the TSF. + result is produced when the messages are provided to the TSF. Selected Long Messages Test: Bit-oriented Mode The evaluators devise an input set consisting of m messages, where m is the block length of the hash algorithm. The length of the ith message is 512 + 99*i, where 1 ≤ i ≤ m. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to - the TSF. + the TSF. Selected Long Messages Test: Byte-oriented Mode The evaluators devise an input set consisting of m/8 messages, where m is the block length of the hash algorithm. The length of the ith message is 512 + 8*99*i, where 1 ≤ i ≤ m/8. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to - the TSF. + the TSF. Pseudorandomly Generated Messages Test: Byte-oriented Mode This test is for byte­oriented implementations only. The evaluators randomly generate a seed that is n bits long, where n is the length @@ -1733,24 +3906,106 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - + - - + + + The TSF shall perform [<htm:i>cryptographic signature services (generation + and verification)</htm:i>] in accordance with a specified cryptographic + algorithm <selectables linebreak="yes"> + <selectable id="s-sign-rsa"><readable>RSA schemes</readable>[<htm:i><snip>RSA schemes</snip></htm:i>] <refinement>using</refinement> cryptographic key sizes of [<htm:i>2048-bit or + greater</htm:i>] that meet the following: [<htm:i>FIPS PUB 186-4, "Digital Signature Standard + (DSS)", Section 4</htm:i>]</selectable> + <selectable id="s-sign-ecdsa"><readable>ECDSA schemes</readable>[<htm:i>ECDSA schemes</htm:i>] <refinement>using</refinement> [<htm:i>"NIST curves" P-384 and <selectables> + <selectable>P-256</selectable> + <selectable>P-521</selectable> + <selectable exclusive="yes">no other curves</selectable></selectables></htm:i>] that meet the following: [<htm:i>FIPS PUB 186-4, "Digital Signature + Standard (DSS)", Section 5</htm:i>]</selectable> + <!-- <selectable exclusive="yes">No other algorithms</selectable> --> + </selectables>. + The ST author should choose the algorithm implemented to + perform digital signatures; if more than one algorithm is available, this requirement + should be iterated to specify the functionality. For the algorithm chosen, the ST + author should make the appropriate assignments/selections to specify the parameters + that are implemented for that algorithm. + + There are no TSS evaluation activities for this component. + There are no guidance evaluation activities for this component. + + Evaluation Activity Note: The following tests require the developer to + provide access to a test platform that provides the evaluator with tools that are + typically not found on factory products. + + [conditional] If is selected in FCS_COP.1.1/SIGN + + ECDSA FIPS 186-4 Signature Generation Test For + each supported NIST curve (i.e. P-256, P-384 and P-521) and SHA function + pair, the evaluator shall generate 10 1024-bit long messages and obtain for + each message a public key and the resulting signature values R and S. To + determine correctness, the evaluator shall use the signature verification + function of a known good implementation. + ECDSA FIPS 186-4 Signature Verification Test For + each supported NIST curve (i.e. P-256, P-384 and P-521) and SHA function + pair, the evaluator shall generate a set of 10 1024-bit message, public key + and signature tuples and modify one of the values (message, public key or + signature) in five of the 10 tuples. The evaluator shall obtain in response + a set of 10 PASS/FAIL values. + + + [conditional] If is selected in FCS_COP.1.1/SIGN + + Signature Generation Test The evaluator shall + verify the implementation of RSA Signature Generation by the TOE using the + Signature Generation Test. To conduct this test the evaluator must generate + or obtain 10 messages from a trusted reference implementation for each + modulus size/SHA combination supported by the TSF. The evaluator shall have + the TOE use their private key and modulus value to sign these messages. + The evaluator shall verify the correctness of the TSF’s + signature using a known good implementation and the associated public keys + to verify the signatures. + Signature Verification Test The evaluator shall + perform the Signature Verification test to verify the ability of the TOE to + recognize another party’s valid and invalid signatures. The evaluator shall + inject errors into the test vectors produced during the Signature + Verification Test by introducing errors in some of the public keys e, + messages, IR format, or signatures. The TOE attempts to verify the + signatures and returns success or failure. + The evaluator shall use these test vectors to emulate the signature + verification test using the corresponding parameters and verify that the TOE detects + these errors. + + + + + + + + - The TSF shall perform [ <htm:i>keyed-hash message authentication</htm:i> ] in accordance with a specified cryptographic algorithm [ <htm:i>HMAC-SHA-1 and <selectables><selectable id="fcs_cop.1.1_KEYHMAC_1" >HMAC-SHA-256</selectable><selectable id="fcs_cop.1.1_KEYHMAC_2" >HMAC-SHA-384</selectable><selectable id="fcs_cop.1.1_KEYHMAC_3" >HMAC-SHA-512</selectable><selectable id="fcs_cop.1.1_KEYHMAC_4" exclusive="yes" >no other algorithms</selectable></selectables></htm:i> ] and cryptographic key sizes<assignable>key size (in bits) used in HMAC</assignable><htm:b> and message digest sizes 160 and <selectables><selectable id="fcs_cop.1.1_KEYHMAC_6" >256</selectable><selectable id="fcs_cop.1.1_KEYHMAC_7" >384</selectable><selectable id="fcs_cop.1.1_KEYHMAC_8" >512</selectable><selectable id="fcs_cop.1.1_KEYHMAC_9" exclusive="yes" >no other</selectable></selectables> bits</htm:b> that meet the following: [ <htm:i>FIPS Pub + <title>The TSF shall perform [<htm:i>keyed-hash message authentication</htm:i>] + in accordance with a specified cryptographic algorithm [<htm:i>HMAC-SHA-1 and <selectables> + <selectable>HMAC-SHA-256</selectable> + <selectable>HMAC-SHA-384</selectable> + <selectable>HMAC-SHA-512</selectable> + <selectable exclusive="yes">no other algorithms</selectable></selectables></htm:i>] and cryptographic key sizes <assignable>key size (in + bits) used in HMAC</assignable><refinement> and message digest sizes 160 and <selectables> + <selectable>256</selectable> + <selectable>384</selectable> + <selectable>512</selectable> + <selectable exclusive="yes">no other</selectable></selectables> bits</refinement> that meet the following: [<htm:i>FIPS Pub 198-1, "The Keyed-Hash Message Authentication Code", and FIPS Pub 180-4, "Secure - Hash Standard"</htm:i> ]. + Hash Standard"]. The selection in this requirement must be consistent with the key size specified for the size of the keys used in conjunction with the keyed-hash message authentication. HMAC-SHA-1 is currently required in order to comply with the - . - - The evaluator shall examine the TSS to ensure that it specifies the following + . + + The evaluator shall examine the TSS to ensure that it specifies the following values used by the HMAC function: key length, hash function used, block size, and output MAC length used. There are no guidance evaluation activities for this component. - Evaluation Activity Note: The following tests require the developer to + + Evaluation Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products. For each of the supported parameter sets, the evaluator shall compose 15 sets of test data. Each set @@ -1760,81 +4015,141 @@ The evaluator shall generate 10 private/public key pairs using the key generatio implementation. - + - - - - The TSF shall perform [ <htm:i>cryptographic signature services (generation - and verification)</htm:i> ] in accordance with a specified cryptographic algorithm<selectables><selectable id="s-sign-rsa" >[<htm:i> <snip>RSA schemes</snip></htm:i>] <htm:b>using</htm:b> cryptographic key sizes of [<htm:i>2048-bit or - greater</htm:i>] that meet the following: [<htm:i>FIPS PUB 186-4, "Digital Signature Standard - (DSS)", Section 4</htm:i>]</selectable><selectable id="s-sign-ecdsa">[<htm:i>ECDSA schemes</htm:i>] <htm:b>using</htm:b> [<htm:i>"NIST curves" P-384 and <selectables><selectable id="fcs_cop.1.1_SIGN_1" >P-256</selectable><selectable id="fcs_cop.1.1_SIGN_2" >P-521</selectable><selectable id="fcs_cop.1.1_SIGN_3" exclusive="yes" >no other curves</selectable></selectables></htm:i>] that meet the following: [<htm:i>FIPS PUB 186-4, "Digital Signature Standard (DSS)", Section 5</htm:i>]</selectable></selectables>. - The ST author should choose the algorithm implemented to - perform digital signatures; if more than one algorithm is available, this requirement - should be iterated to specify the functionality. For the algorithm chosen, the ST - author should make the appropriate assignments/selections to specify the parameters - that are implemented for that algorithm. - - There are no TSS evaluation activities for this component. + + + The TSF shall perform <refinement>conditioning</refinement> in accordance with a + specified cryptographic algorithm <refinement>HMAC-<selectables> + <selectable>SHA-256</selectable> + <selectable>SHA-384</selectable> + <selectable>SHA-512</selectable></selectables> using a salt, and <selectables> + <selectable>PBKDF2 with <assignable>number of iterations</assignable> + iterations</selectable> + <selectable><assignable>key stretching function</assignable></selectable> + <selectable exclusive="yes">no other function</selectable></selectables> and output</refinement> cryptographic key sizes<refinement> + <selectables> + <selectable>128</selectable> + <selectable>256</selectable></selectables></refinement> that meet the following: <refinement><selectables> + <selectable>NIST SP 800-132</selectable> + <selectable exclusive="yes">no standard</selectable></selectables>.</refinement> + + The key cryptographic key sizes in the third selection should + be made to correspond to the KEK key sizes selected in FCS_CKM_EXT.3. + This password must be conditioned into a string of bits that forms + the submask to be used as input into the KEK. Conditioning can be performed using one + of the identified hash functions and may include a key stretching function; the method + used is selected by the ST author. If selected, NIST SP 800-132 requires the use of a + pseudorandom function (PRF) consisting of HMAC with an approved hash function. The ST + author selects the hash function used, also includes the appropriate requirements for + HMAC and the hash function. Appendix A of NIST SP 800-132 + recommends setting the iteration count in order to increase the computation needed to + derive a key from a password and, therefore, increase the workload of performing a + dictionary attack. + + The evaluator shall check that the TSS describes the method by which the password + is first encoded and then fed to the SHA algorithm and verify the SHA algorithm + matches the first selection. If a key stretching function, such as + PBKDF2, is selected the settings for the algorithm (padding, blocking, etc.) shall + be described. The evaluator shall verify that the TSS contains a description of how + the output of the hash function or key stretching function is used to form the + submask that will be input into the function and is the same length as the KEK as + specified in FCS_CKM_EXT.3. If any manipulation of the key is + performed in forming the submask that will be used to form the KEK, that process + shall be described in the TSS. There are no guidance evaluation activities for this component. - - - [conditional] If is selected in FCS_COP.1.1/SIGN - [conditional] If is selected in FCS_COP.1.1/SIGN - - + There are no test evaluation activities for this component. No explicit testing of the + formation of the submask from the input password is required. - + - - + + + This family defines requirements for implementation of the HTTPS protocol. + + + + + + requires the TSF to implement the HTTPS protocol in accordance with the specified standard, using TLS, and notifying the application if invalid. The following actions could be considered for the management functions in FMT: - Configuring whether to allow or disallow establishment of a trusted channel if the peer or server certificate is deemed invalid. + + Configuring whether to allow or disallow establishment of a trusted channel if the peer or server certificate is deemed invalid. + The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - Failure of the certificate validity check. - FIA_X509_EXT.1 X.509 Validation of Certificates + + Failure of the certificate validity check. + + FIA_X509_EXT.1 X.509 Validation of Certificates FMT_SMF.1 Specification of Management Functions + + - The TSF shall implement the HTTPS protocol that complies with RFC 2818. + The TSF shall implement the HTTPS protocol that complies with RFC 2818. + - The TSF shall implement HTTPS using TLS as defined in [ <htm:i>the <xref to="pkg-tls"></xref></htm:i> ]. + The TSF shall implement HTTPS using TLS as defined in [<htm:i>the <xref to="pkg-tls"/></htm:i>]. + + The TSF shall implement HTTPS using TLS as defined in + <assignable>specification that defines TLS implementation requirements</assignable>. + - The must be included in the ST, with the following selections made: FCS_TLS_EXT.1:TLS must be selectedClient must be selected + The must be included in the ST, with the following selections made: + FCS_TLS_EXT.1: + + TLS must be selected + Client must be selected + + + - The TSF shall notify the application and<selectables><selectable id="s-not-estab" >not establish the connection</selectable><selectable id="s-req-app-auth" >request application authorization to establish the - connection</selectable><selectable id="s-no-other-action" exclusive="yes" >no other action</selectable></selectables>if the peer certificate is deemed invalid. + + The TSF shall notify the application and <selectables> + <selectable id="s-not-estab">not establish the connection</selectable> + <selectable id="s-req-app-auth">request application authorization to establish the + connection</selectable> + <selectable id="s-no-other-action" exclusive="yes">no other action</selectable></selectables> if the peer certificate is deemed invalid. + The TSF shall notify the application and <assignable>a response</assignable> if the peer certificate is deemed invalid. Validity is determined by the certificate path, the expiration date, and the revocation status in accordance with RFC 5280. - If is selected then "with no exceptions" must be selected - for FCS_TLSC_EXT.1.3 in the . - s-not-estabs-tlsc-no-excep - If is selected then + If is selected then "with no exceptions" must be selected + for FCS_TLSC_EXT.1.3 in the . + + s-not-estab + s-tlsc-no-excep + + If is selected then "except when override is authorized" must be selected for FCS_TLSC_EXT.1.3 in the Package for Transport Layer Security. - s-req-app-auths-tlsc-override - If is selected either selection can be + + s-req-app-auth + s-tlsc-override + + If is selected either selection can be made in FCS_TLSC_EXT.1.3. - FMT_SMF.1 Function configures whether to allow or disallow the establishment of a + FMT_SMF.1 Function configures whether to allow or disallow the establishment of a trusted channel if the peer certificate is deemed invalid. - + + There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. + The evaluator shall attempt to establish an HTTPS connection with a webserver, observe the traffic with a packet analyzer, and verify that the connection succeeds and that the traffic is identified as TLS or HTTPS. Other tests are performed in conjunction with testing in the - . Certificate validity + . Certificate validity shall be tested in accordance with testing performed for FIA_X509_EXT.1, and the - evaluator shall perform the following test: + evaluator shall perform the following test: The evaluator shall demonstrate that using a certificate without a valid certification path results in an application notification. Using the administrative guidance, the evaluator shall then load a certificate or @@ -1846,57 +4161,100 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - - Failure of the certificate validity check. - Issuer Name and Subject Name of certificate - - - User’s authorization decision - No additional information - - - + + Failure of the certificate validity check. + Issuer Name and Subject Name of certificate + User’s authorization decisionNo additional information + - - + + + This family defines requirements for initialization vector generation in support of key generation. + + + + + + requires the TSF to generate IVs in accordance with a set of approved modes. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. + + - The TSF shall generate IVs in accordance with [ <htm:i> <xref to="ivtable"></xref>: - References and IV Requirements for NIST-approved Cipher Modes</htm:i> ]. - lists the requirements for composition of IVs according to + The TSF shall generate IVs in accordance with [<htm:i><xref to="ivtable"/>: + References and IV Requirements for NIST-approved Cipher Modes</htm:i>]. + + The TSF shall generate IVs in accordance with <assignable>standard or specification for IV generation</assignable>. + + + lists the requirements for composition of IVs according to the NIST Special Publications for each cipher mode. The composition of IVs generated for encryption according to a cryptographic protocol is addressed by the protocol. Thus, this requirement addresses only IVs generated for key storage and data storage encryption. - - The evaluator shall examine the key hierarchy section of the TSS to ensure that + + The evaluator shall examine the key hierarchy section of the TSS to ensure that the encryption of all keys is described and the formation of the IVs for each key encrypted by the same KEK meets FCS_IV_EXT.1. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component. - + - - + + + This family defines requirements for the generation of random bits. + + + + + + requires the TSF to generate random data with a certain amount of entropy and in accordance with applicable standards. There are no management activities foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - Failure of the randomization process. + + Failure of the randomization process. + No dependencies. + + - The TSF shall perform all deterministic random bit generation services in accordance with NIST Special Publication 800-90A using<selectables><selectable id="fcs_rbg_ext.1.1_1" >Hash_DRBG (any)</selectable><selectable id="fcs_rbg_ext.1.1_2" >HMAC_DRBG (any)</selectable><selectable id="fcs_rbg_ext.1.1_3" >CTR_DRBG (AES)</selectable></selectables>. + The TSF shall perform all deterministic random bit generation services in + accordance with NIST Special Publication 800-90A using <selectables> + <selectable>Hash_DRBG (any)</selectable> + <selectable>HMAC_DRBG (any)</selectable> + <selectable>CTR_DRBG (AES)</selectable></selectables>. + + The TSF shall perform all deterministic random bit generation services in + accordance with NIST Special Publication 800-90A using <assignable>list of DRBG algorithms</assignable>. + - The deterministic RBG shall be seeded by an entropy source that accumulates entropy from<selectables><selectable id="fcs_rbg_ext.1.2_1" >a software-based noise source</selectable><selectable id="fcs_rbg_ext.1.2_2" >TSF-hardware-based noise source</selectable></selectables>with a minimum of<selectables><selectable id="fcs_rbg_ext.1.2_3" >128 bits</selectable><selectable id="s-rbg-256" >256 bits</selectable></selectables>of entropy at least equal to the greatest security strength (according to NIST SP 800-57) of the keys and hashes that it will generate. + The deterministic RBG shall be seeded by an entropy source that accumulates + entropy from <selectables> + <selectable>a software-based noise source</selectable> + <selectable>TSF-hardware-based noise source</selectable> + </selectables> with a minimum of <selectables> + <selectable>128 bits</selectable> + <selectable id="s-rbg-256">256 bits</selectable></selectables> of entropy at least equal to the greatest security strength (according + to NIST SP 800-57) of the keys and hashes that it will generate. + + The deterministic RBG shall be seeded by an entropy source that accumulates + entropy from + <assignable>list of sources of random</assignable> with a minimum of + <assignable>number of bits</assignable> + of entropy at least equal to the greatest security strength (according + to NIST SP 800-57) of the keys and hashes that it will generate. + - The TSF shall be capable of providing output of the RBG to applications running on the TSF that request random bits. + The TSF shall be capable of providing output of the RBG to applications running + on the TSF that request random bits. SP 800-90A contains three different methods of generating random numbers; each of these, in turn, depends on underlying cryptographic primitives (hash functions/ciphers). The ST author will select the function used, and include the @@ -1925,11 +4283,27 @@ The evaluator shall generate 10 private/public key pairs using the key generatio contains drift and jitter over time. The output of the ring oscillator consists of the oscillating binary value sampled at a constant rate from one of the inverters – a rate that is significantly slower than the oscillator’s natural frequency. - + + + Entropy Documentation + + Documentation shall be produced and the evaluator shall perform the + activities in accordance with , the "Clarification to the + Entropy Documentation and Assessment". + + + API Documentation + + The evaluator shall verify + that the API documentation provided according to , includes the + security functions described in FCS_RBG_EXT.1.3. + There are no TSS evaluation activities for this component. The evaluator shall also confirm that the operational guidance contains - appropriate instructions for configuring the RNG functionality. - Evaluation Activity Note: The following tests require the developer to + appropriate instructions for configuring the RNG functionality. + + + Evaluation Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products. The evaluator shall perform 15 trials for the RNG implementation. If the RNG is configurable, the @@ -1954,30 +4328,40 @@ The evaluator shall generate 10 private/public key pairs using the key generatio generate. The sixth and seventh are additional input and entropy input to the call to reseed. The final value is additional input to the second generate call. The following paragraphs contain more information on some of the - input values to be generated/selected by the evaluator. Entropy input: the length of the entropy input value must - equal the seed length.Nonce: If a nonce is supported (CTR_DRBG with no Derivation + input values to be generated/selected by the evaluator. + + Entropy input: the length of the entropy input value must + equal the seed length. + Nonce: If a nonce is supported (CTR_DRBG with no Derivation Function does not use a nonce), the nonce bit length is one-half the seed - length.Personalization string: The length of the personalization - string must be ࣘ seed length. If the implementation only supports one + length. + Personalization string: The length of the personalization + string must be ࣘ seed length. If the implementation only supports one personalization string length, then the same length can be used for both values. If more than one string length is support, the evaluator shall use personalization strings of two different lengths. If the implementation does not - use a personalization string, no value needs to be supplied.Additional input: the additional input bit lengths have the - same defaults and restrictions as the personalization string lengths. + use a personalization string, no value needs to be supplied. + Additional input: the additional input bit lengths have the + same defaults and restrictions as the personalization string lengths. + + - - Failure of the randomization process - + + Failure of the randomization process + - - + + + requires the TSF to save and restore the state of the RBG when powering off and starting up. There are no management activities foreseen. There are no auditable events foreseen. FCS_RBG_EXT.1 Random Bit Generation + - The TSF shall save the state of the deterministic RBG at power-off, and shall use this state as input to the deterministic RBG at startup. + The TSF shall save the state of the deterministic RBG at power-off, and shall use + this state as input to the deterministic RBG at startup. The capability to add the state saved at power-off as input to the RBG prevents an RBG that is slow to gather entropy from producing the same output regularly and across reboots. Since there is no guarantee of the protections provided @@ -1985,9 +4369,9 @@ The evaluator shall generate 10 private/public key pairs using the key generatio that the state is 'known', and therefore cannot contribute entropy to the RBG, but can introduce enough variation that the initial RBG values are not predictable and exploitable. - + The evaluation activity for this requirement is captured in the RBG documentation - for . The evaluator shall verify that the documentation + for . The evaluator shall verify that the documentation describes how the state is generated so as to be available for the next startup, how the state is used as input to the DRBG, and any protection measures used for the state while the TOE is powered off. @@ -1995,29 +4379,29 @@ The evaluator shall generate 10 private/public key pairs using the key generatio There are no test evaluation activities for this component. - + - - + + requires the TSF to support a personalization string as a DRBG input parameter. There are no management activities foreseen. There are no auditable events foreseen. FCS_RBG_EXT.1 Random Bit Generation + - The TSF shall allow applications to add data to the deterministic RBG using the Personalization String as defined in SP 800-90A. + The TSF shall allow applications to add data to the deterministic RBG using the + Personalization String as defined in SP 800-90A. As specified in SP 800-90A, the TSF must not count data input from an application towards the entropy required by FCS_RBG_EXT.1. Thus, the TSF must not allow the only input to the RBG seed to be from an application. - - The evaluator shall verify that this function is included as an interface to - the RBG in the documentation required by and that the + The evaluator shall verify that this function is included as an interface to + the RBG in the documentation required by and that the behavior of the RBG following a call to this interface is described. The evaluator shall also verify that the documentation of the RBG describes the conditions of use and possible values for the Personalization String input to the SP 800-90A specified DRBG. There are no TSS evaluation activities for this component. - There are no guidance evaluation activities for this component. - + There are no guidance evaluation activities for this component. The evaluator shall write, or the developer shall provide, an application that adds data to the RBG via the Personalization String. The evaluator shall @@ -2026,27 +4410,65 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - + - - + + + This family defines requirements for the ability of the TOE to make its cryptographic operations available to non-TSF components. + + + + + + requires the TSF to have externally-accessible cryptographic services for making algorithm functions available to applications. There are no management activities foreseen. There are no auditable events foreseen. - FCS_CKM.1 Cryptographic Key Generation + FCS_CKM.1 Cryptographic Key Generation FCS_COP.1 Cryptographic Operation + + - The TSF shall provide a mechanism for applications to request the TSF to perform the following cryptographic operations: [ <htm:i><htm:ul><htm:li>All mandatory and <selectables><selectable id="fcs_srv_ext.1.1_1" >selected algorithms</selectable><selectable id="fcs_srv_ext.1.1_2" > selected algorithms with the exception of ECC over curve - 25519-based algorithms</selectable></selectables> in FCS_CKM.2/LOCKED</htm:li><htm:li>The following algorithms in FCS_COP.1/ENCRYPT: AES-CBC, <selectables><selectable id="fcs_srv_ext.1.1_3" >AES Key Wrap</selectable><selectable id="fcs_srv_ext.1.1_4" >AES Key Wrap with Padding</selectable><selectable id="fcs_srv_ext.1.1_5" >AES-GCM</selectable><selectable id="fcs_srv_ext.1.1_6" >AES-CCM</selectable><selectable id="fcs_srv_ext.1.1_7" exclusive="yes" >no other modes</selectable></selectables></htm:li><htm:li>All selected algorithms in FCS_COP.1/SIGN</htm:li><htm:li>All mandatory and selected algorithms in FCS_COP.1/HASH</htm:li><htm:li>All mandatory and selected algorithms in FCS_COP.1/KEYHMAC</htm:li><htm:li><selectables><selectable id="fcs_srv_ext.1.1_8">All mandatory and <selectables><selectable id="fcs_srv_ext.1.1_9" >selected algorithms</selectable><selectable id="fcs_srv_ext.1.1_10" >selected algorithms with the exception of ECC over curve - 25519-based algorithms</selectable></selectables> in FCS_CKM.1</selectable><selectable id="fcs_srv_ext.1.1_11" >The selected algorithms in FCS_COP.1<htm:b>/CONDITION</htm:b></selectable><selectable id="fcs_srv_ext.1.1_12" exclusive="yes" >No other cryptographic operations</selectable></selectables></htm:li></htm:ul></htm:i> ]. + The TSF shall provide a mechanism for applications to request the TSF to perform + the following cryptographic operations: [<htm:i><htm:ul> + <htm:li>All mandatory and <selectables> + <selectable>selected algorithms</selectable> + <selectable> selected algorithms with the exception of ECC over curve + 25519-based algorithms</selectable></selectables> in FCS_CKM.2/LOCKED</htm:li> + <htm:li>The following algorithms in FCS_COP.1/ENCRYPT: AES-CBC, <selectables> + <selectable>AES Key Wrap</selectable> + <selectable>AES Key Wrap with Padding</selectable> + <selectable>AES-GCM</selectable> + <selectable>AES-CCM</selectable> + <selectable exclusive="yes">no other modes</selectable></selectables> + </htm:li> + <htm:li>All selected algorithms in FCS_COP.1/SIGN</htm:li> + <htm:li>All mandatory and selected algorithms in FCS_COP.1/HASH</htm:li> + <htm:li>All mandatory and selected algorithms in FCS_COP.1/KEYHMAC</htm:li> + <htm:li> + <selectables linebreak="yes"> + <selectable>All mandatory and <selectables> + <selectable>selected algorithms</selectable> + <selectable>selected algorithms with the exception of ECC over curve + 25519-based algorithms</selectable></selectables> in FCS_CKM.1</selectable> + <selectable>The selected algorithms in FCS_COP.1<htm:b>/CONDITION</htm:b></selectable> + <selectable exclusive="yes">No other cryptographic operations</selectable> + </selectables> + </htm:li> + </htm:ul></htm:i>]. + + + The TSF shall provide a mechanism for applications to request the TSF to perform + the following cryptographic operations: <assignable>cryptographic operations defined by the TSF in FCS_CKM.1 or FCS_COP.1</assignable> + + For each of the listed FCS components in the bulleted list, the intent is that the TOE will make available all algorithms specified for that component in the ST. For example, if for FCS_COP.1/HASH the ST author selects SHA-256, then the TOE would have to make available an interface to perform SHA-1 (the "mandatory" portion of FCS_COP.1/HASH) and SHA-256 (the "selected" portion of FCS_COP.1/HASH). - The exception is for FCS_COP.1/ENCRYPT. The TOE is not required to make available AES_CCMP, AES_XTS, AES_GCMP-256, or AES_CCMP_256 even though they may be implemented to perform TSF-related functions. It is acceptable for the platform to not provide AES Key Wrap (KW) and AES Key Wrap with Padding (KWP) to applications even if selected in FCS_COP.1/ENCRYPT. However, the ST author is expected to select AES-GCM or AES-CCM if it is selected in the ST for the FCS_COP.1/ENCRYPT component. + The exception is for FCS_COP.1/ENCRYPT. The TOE is not required to make available AES_CCMP, AES_XTS, AES_GCMP-256, or AES_CCMP_256 even though they may be implemented to perform TSF-related functions. It is acceptable for the platform to not provide AES Key Wrap (KW) and AES Key Wrap with Padding (KWP) to applications even if selected in FCS_COP.1/ENCRYPT. However, the ST author is expected to select AES-GCM or AES-CCM if it is selected in the ST for the FCS_COP.1/ENCRYPT component. - - The evaluator shall verify that the API documentation provided according to - includes the security functions (cryptographic algorithms) + The evaluator shall verify that the API documentation provided according to + includes the security functions (cryptographic algorithms) described in these requirements. There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. @@ -2058,23 +4480,33 @@ The evaluator shall generate 10 private/public key pairs using the key generatio requirements. - + - - + + requires the TSF to support its stored keys being usable by external applications through cryptographic algorithm services. There are no management activities foreseen. There are no auditable events foreseen. FCS_COP.1 Cryptographic Operation + - The TSF shall provide a mechanism for applications to request the TSF to perform the following cryptographic operations: [ <htm:i><htm:ul><htm:li>Algorithms in FCS_COP.1/ENCRYPT</htm:li><htm:li>Algorithms in FCS_COP.1/SIGN</htm:li></htm:ul></htm:i> ] by keys stored in the secure key storage. + The TSF shall provide a mechanism for applications to request the TSF to perform + the following cryptographic operations: [<htm:i><htm:ul> + <htm:li>Algorithms in FCS_COP.1/ENCRYPT</htm:li> + <htm:li>Algorithms in FCS_COP.1/SIGN</htm:li> + </htm:ul></htm:i>] by keys stored in the secure key storage. + + The TSF shall provide a mechanism for applications to request the TSF to perform + the following cryptographic operations: + <assignable>cryptographic operations defined by the TSF in FCS_COP.1</assignable> + by keys stored in the secure key storage. + The TOE will, therefore, be required to perform cryptographic operations on behalf of applications using the keys stored in the TOE’s secure key storage. - - The evaluator shall verify that the API documentation for the secure key + The evaluator shall verify that the API documentation for the secure key storage includes the cryptographic operations by the stored keys. There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. @@ -2086,103 +4518,198 @@ The evaluator shall generate 10 private/public key pairs using the key generatio Activities in FCS_STG_EXT.1. - + -
    • - -
    + + This family defines requirements for the implementation of secure key storage with access control, confidentiality, and integrity protections. + + + + The following requirements describe how keys are protected. All keys must ultimately be protected by a REK, and may optionally be protected by the user’s authentication factor. Each key’s confidentiality and integrity must be protected. This section also describes the secure key storage services to be provided by the Mobile Device for use by applications and users, applying the same level of protection for these keys as keys internal to the OS. - - - - requires the TSF to implement a secure key storage and defines the access restrictions to be enforced on this. - The following actions could be considered for the management functions in FMT: - Importing keys or secrets into the secure key storage.Destroying imported keys or secrets in the secure key storage.Approving exceptions for shared use of keys or secrets by multiple applications.Approving exceptions for destruction of keys or secrets by applications that did not import the key or secret - The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - Import or destruction of key.Exceptions to use and destruction rules. - - [FCS_CKM.1 Cryptographic Key Generation, or - FDP_ITC.1 Import of User Data without Security Attributes, or - FDP_ITC.2 Import of User Data with Security Attributes] + + + + + + + requires the TSF to implement a secure key storage and defines the access restrictions to be enforced on this. + The following actions could be considered for the management functions in FMT: + + Importing keys or secrets into the secure key storage. + Destroying imported keys or secrets in the secure key storage. + Approving exceptions for shared use of keys or secrets by multiple applications. + Approving exceptions for destruction of keys or secrets by applications that did not import the key or secret + + + The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: + + Import or destruction of key. + Exceptions to use and destruction rules. + + + + [FCS_CKM.1 Cryptographic Key Generation, or + FDP_ITC.1 Import of User Data without Security Attributes, or + FDP_ITC.2 Import of User Data with Security Attributes] FMT_SMR.1 Security Roles - - The TSF shall provide<selectables><selectable id="fcs_stg_ext.1.1_1" >mutable hardware</selectable><selectable id="s-software-store" >software-based</selectable></selectables>secure key storage for asymmetric private keys and<selectables><selectable id="fcs_stg_ext.1.1_2" >symmetric keys</selectable><selectable id="fcs_stg_ext.1.1_3" >persistent secrets</selectable><selectable id="fcs_stg_ext.1.1_4" exclusive="yes" >no other keys</selectable></selectables>. - A hardware keystore can be exposed to the TSF through a variety + + + + The TSF shall provide <selectables> + <selectable>mutable hardware</selectable> + <selectable id="s-software-store">software-based</selectable> + </selectables> secure key storage for asymmetric private keys and <selectables> + <selectable>symmetric keys</selectable> + <selectable>persistent secrets</selectable> + <selectable exclusive="yes">no other keys</selectable> + </selectables>. + + The TSF shall provide + <assignable>storage medium</assignable> + secure key storage for asymmetric private keys and + <assignable>list of secrets</assignable> + . + + + A hardware keystore can be exposed to the TSF through a variety of interfaces, including embedded on the motherboard, USB, microSD, and Bluetooth. Immutable hardware is considered outside of this requirement and will be covered elsewhere. If the secure key storage is implemented in software that is protected as required by FCS_STG_EXT.2, the ST author must select - . - If is selected, - the ST author must select in FCS_STG_EXT.2.1. - s-software-stores-all-software-key-store + . + If is selected, + the ST author must select in FCS_STG_EXT.2.1. + + s-software-store + s-all-software-key-store + + Support for secure key storage for all symmetric keys and persistent secrets will be required in future revisions. - - - The TSF shall be capable of importing keys or secrets into the secure key storage upon request of<selectables><selectable id="import-user" >the user</selectable><selectable id="s-import-admin" >the administrator</selectable></selectables>and<selectables><selectable id="fcs_stg_ext.1.2_1" >applications running on the TSF</selectable><selectable id="fcs_stg_ext.1.2_2" exclusive="yes" >no other subjects</selectable></selectables>. - If the ST selects only , the ST author must select function in FMT_MOF_EXT.1.1. - - - The TSF shall be capable of destroying keys or secrets in the secure key storage upon request of<selectables><selectable id="fcs_stg_ext.1.3_1" >the user</selectable><selectable id="fcs_stg_ext.1.3_2" >the administrator</selectable></selectables>. - If the ST selects , the ST author must select function in FMT_MOF_EXT.1.1. - - - The TSF shall have the capability to allow only the application that imported the key or secret the use of the key or secret. Exceptions may only be explicitly authorized by<selectables><selectable id="fcs_stg_ext.1.4_1" >the user</selectable><selectable id="fcs_stg_ext.1.4_2" >the administrator</selectable><selectable id="fcs_stg_ext.1.4_3" >a common application developer</selectable></selectables>. - If the ST selects or , - the ST author must also select in FMT_SMF.1.1. - If the ST selects , the ST author must select function in FMT_MOF_EXT.1.1. + + + + The TSF shall be capable of importing keys or secrets into the secure key storage + upon request of <selectables> + <selectable id="import-user">the user</selectable> + <selectable id="s-import-admin">the administrator</selectable> + </selectables> and <selectables> + <selectable>applications running on the TSF</selectable> + <selectable exclusive="yes">no other subjects</selectable> + </selectables>. + + The TSF shall be capable of importing keys or secrets into the secure key storage + upon request of <assignable>list of users</assignable> and <assignable>list of other subjects</assignable>. + + If the ST selects only , the ST author must select function in FMT_MOF_EXT.1.1. + + + + The TSF shall be capable of destroying keys or secrets in the secure key storage + upon request of <selectables> + <selectable>the user</selectable> + <selectable>the administrator</selectable> + </selectables>. + If the ST selects , the ST author must select function in FMT_MOF_EXT.1.1. + + + + The TSF shall have the capability to allow only the application that imported the + key or secret the use of the key or secret. Exceptions may only be explicitly authorized by <selectables> + <selectable>the user</selectable> + <selectable>the administrator</selectable> + <selectable>a common application developer</selectable> + </selectables>. + If the ST selects or , + the ST author must also select in FMT_SMF.1.1. + If the ST selects , the ST author must select function in FMT_MOF_EXT.1.1. - - - The TSF shall allow only the application that imported the key or secret to request that the key or secret be destroyed. Exceptions may only be explicitly authorized by<selectables><selectable id="s-killkey-user" >the user</selectable><selectable id="s-killkey-admin" >the administrator</selectable><selectable id="fcs_stg_ext.1.5_1" >a common application developer</selectable></selectables>. - If the ST selects or , - the ST author must also select function in FMT_SMF.1.1. - If the ST selects only , - the ST author must select function in FMT_MOF_EXT.1.1. - - The evaluator shall verify that the API documentation provided according to - includes the security functions (import, use, and + + + + The TSF shall allow only the application that imported the key or secret to request + that the key or secret be destroyed. Exceptions may only be explicitly authorized by <selectables> + <selectable id="s-killkey-user">the user</selectable> + <selectable id="s-killkey-admin">the administrator</selectable> + <selectable>a common application developer</selectable> + </selectables>. + + The TSF shall allow only the application that imported the key or secret to request + that the key or secret be destroyed. Exceptions may only be explicitly authorized by + <assignable>list of subjects</assignable>. + + + If the ST selects or , + the ST author must also select function in FMT_SMF.1.1. + If the ST selects only , + the ST author must select function in FMT_MOF_EXT.1.1. + The evaluator shall verify that the API documentation provided according to + includes the security functions (import, use, and destruction) described in these requirements. The API documentation shall include the method by which applications restrict access to their keys or secrets in order to meet FCS_STG_EXT.1.4. - The evaluator shall review the TSS to determine that the TOE implements the + The evaluator shall review the TSS to determine that the TOE implements the required secure key storage. The evaluator shall ensure that the TSS contains a description of the key storage mechanism that justifies the selection of "mutable - hardware" or "software-based". - The evaluator shall review the AGD guidance to determine that it describes - the steps needed to import or destroy keys or secrets. - - - The evaluator shall test the functionality of each security function: + hardware" or "software-based". + + The evaluator shall review the AGD guidance to determine that it describes + the steps needed to import or destroy keys or secrets. + + The evaluator shall test the functionality of each security function: The evaluator shall import keys or secrets of each supported type according to the AGD guidance. The evaluator shall write, or the developer shall provide access to, an application that generates a key or secret of each supported type and calls the import functions. The evaluator shall verify that no errors occur - during import. + during import. The evaluator shall write, or the developer shall provide access to, an - application that uses an imported key or secret: For RSA, the secret shall be used to sign data.For ECDSA, the secret shall be used to sign data In the future additional types will be required to be tested: For symmetric algorithms, the secret shall be used to encrypt - data.For persistent secrets, the secret shall be compared to the imported - secret. The evaluator shall repeat this test with the application-imported + application that uses an imported key or secret: + + For RSA, the secret shall be used to sign data. + For ECDSA, the secret shall be used to sign data + + In the future additional types will be required to be tested: + + For symmetric algorithms, the secret shall be used to encrypt + data. + For persistent secrets, the secret shall be compared to the imported + secret. + + The evaluator shall repeat this test with the application-imported keys or secrets and a different application’s imported keys or secrets. The evaluator shall verify that the TOE requires approval before allowing the application to - use the key or secret imported by the user or by a different application: The evaluator shall deny the approvals to verify that the application - is not able to use the key or secret as described. The evaluator shall repeat the test, allowing the approvals to verify - that the application is able to use the key or secret as described. If the ST author has selected "common application developer", this + use the key or secret imported by the user or by a different application: + + The evaluator shall deny the approvals to verify that the application + is not able to use the key or secret as described. + The evaluator shall repeat the test, allowing the approvals to verify + that the application is able to use the key or secret as described. + + If the ST author has selected "common application developer", this test is performed by either using applications from different developers or appropriately (according to API documentation) not authorizing sharing. - + The evaluator shall destroy keys or secrets of each supported type according to the AGD guidance. The evaluator shall write, or the developer shall provide access to, an application that destroys an imported key or secret. @@ -2190,48 +4717,76 @@ The evaluator shall generate 10 private/public key pairs using the key generatio application-imported keys or secrets and a different application’s imported keys or secrets. The evaluator shall verify that the TOE requires approval before allowing the application to destroy the key or secret imported by the administrator - or by a different application: The evaluator shall deny the approvals and verify that the application - is still able to use the key or secret as described. The evaluator shall repeat the test, allowing the approvals and + or by a different application: + + The evaluator shall deny the approvals and verify that the application + is still able to use the key or secret as described. + The evaluator shall repeat the test, allowing the approvals and verifying that the application is no longer able to use the key or secret as - described. If the ST author has selected "common application developer", this + described. + + If the ST author has selected "common application developer", this test is performed by either using applications from different developers or appropriately (according to API documentation) not authorizing sharing. - - - - - Import or destruction of key - Identity of key, role and identity of requester - - - - - Exceptions to use and destruction rules - none - - - Identity of key, role and identity of requester - - - - - requires the TSF to implement confidentiality measures to protect the key storage. - There are no management activities foreseen. + + + + + Import or destruction of key + Identity of key, role and identity of requester + + + Exceptions to use and destruction rulesnone + Identity of key, role and identity of requester + + + + + + + + requires the TSF to implement confidentiality measures to protect the key storage. + There are no management activities foreseen. - There are no auditable events foreseen. + There are no auditable events foreseen. - - FCS_COP.1 Cryptographic Operation + + FCS_COP.1 Cryptographic Operation FCS_STG_EXT.1 Cryptographic Key Storage - - The TSF shall encrypt all DEKs, KEKs,<assignable>any long-term trusted channel key material</assignable>and<selectables><selectable id="s-all-software-key-store" >all software-based key storage</selectable><selectable id="fcs_stg_ext.2.1_2" exclusive="yes" >no other keys</selectable></selectables>by KEKs that are<selectables><selectable id="fcs_stg_ext.2.1_3">Protected by the REK with <selectables><selectable id="fcs_stg_ext.2.1_4" >encryption by a REK</selectable><selectable id="fcs_stg_ext.2.1_5" >encryption by a KEK chaining from a REK</selectable><selectable id="fcs_stg_ext.2.1_6" >encryption by a KEK that is derived from a REK</selectable></selectables></selectable><selectable id="fcs_stg_ext.2.1_7">Protected by the REK and the password with <selectables><selectable id="fcs_stg_ext.2.1_8" >encryption by a REK and the password-derived KEK</selectable><selectable id="fcs_stg_ext.2.1_9" >encryption by a KEK chaining to a REK and the password-derived or - biometric-unlocked KEK</selectable><selectable id="fcs_stg_ext.2.1_10" >encryption by a KEK that is derived from a REK and the - password-derived or biometric-unlocked KEK</selectable></selectables></selectable></selectables>. - The ST author must select - if is selected in FCS_STG_EXT.1.1. - If the ST author selects in FCS_STG_EXT.1.1, + + + The TSF shall encrypt all DEKs, KEKs, <assignable>any long-term trusted channel + key material</assignable> and <selectables> + <selectable id="s-all-software-key-store">all software-based key storage</selectable> + <selectable exclusive="yes">no other keys</selectable> + </selectables> by KEKs that are <selectables linebreak="yes"> + <selectable>Protected by the REK with <selectables linebreak="yes"> + <selectable>encryption by a REK</selectable> + <selectable>encryption by a KEK chaining from a REK</selectable> + <selectable>encryption by a KEK that is derived from a REK</selectable> + </selectables> + </selectable> + <selectable>Protected by the REK and the password with <selectables linebreak="yes"> + <selectable>encryption by a REK and the password-derived KEK</selectable> + <selectable>encryption by a KEK chaining to a REK and the password-derived or + biometric-unlocked KEK</selectable> + <selectable>encryption by a KEK that is derived from a REK and the + password-derived or biometric-unlocked KEK</selectable> + </selectables> + </selectable> + </selectables>. + + The TSF shall encrypt all DEKs, KEKs, <assignable>any long-term trusted channel + key material</assignable> and + <assignable>other secrets </assignable> + by KEKs that are + <assignable>protection mechanism</assignable>. + + The ST author must select + if is selected in FCS_STG_EXT.1.1. + If the ST author selects in FCS_STG_EXT.1.1, the secure key storage is not subject to this requirement. REKs are not subject to this requirement. A REK and @@ -2239,7 +4794,8 @@ The evaluator shall generate 10 private/public key pairs using the key generatio FCS_CKM_EXT.3) in order to meet this requirement. Software-based key storage must be protected by the password or biometric and REK. - All keys must ultimately be protected by a REK. In particular, has KEKs protected according to these requirements: DEK_1 meets the + All keys must ultimately be protected by a REK. In particular, has KEKs protected according to these requirements: DEK_1 meets the "encryption by a REK and the password-derived KEK" case and would be appropriate for sensitive data, DEK_2 meets the "encryption by a KEK chaining from a REK" case and would not be appropriate for sensitive data, K_1 meets the "encryption by a REK" case and is not considered a sensitive key, @@ -2249,8 +4805,8 @@ The evaluator shall generate 10 private/public key pairs using the key generatio as they may be necessary in the locked state. For clarity, the ST author must assign any Long-term trusted channel key material supported by the TOE . At a minimum, a TOE must support at least Wi-Fi and Bluetooth keys. - - The evaluator shall review the TSS to determine that the TSS includes key + + The evaluator shall review the TSS to determine that the TSS includes key hierarchy description of the protection of each DEK for data-at-rest, of software-based key storage, of long-term trusted channel keys, and of KEK related to the protection of the DEKs, long-term trusted channel keys, and software-based key @@ -2262,105 +4818,217 @@ The evaluator shall generate 10 private/public key pairs using the key generatio derived, or combined according to FCS_CKM_EXT.3), the integrity protection method for each encrypted key (FCS_STG_EXT.3), and the IV generation for each key encrypted by the same KEK (FCS_IV_EXT.1). More detail for each task follows the corresponding - requirement. The evaluator shall also ensure that the documentation of the product's encryption key + requirement. + The evaluator shall also ensure that the documentation of the product's encryption key management is detailed enough that, after reading, the product's key management hierarchy is clear and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as - separate proprietary evidence rather than being included in the TSS. - - - - DEKs, KEKs,<assignable>any long-term trusted channel key material</assignable>and<selectables><selectable id="fcs_stg_ext.2.2_2" >all software-based key storage</selectable><selectable id="fcs_stg_ext.2.2_3" exclusive="yes" >no other keys</selectable></selectables>shall be encrypted using one of the following methods:<selectables><selectable id="fcs_stg_ext.2.2_4" >using a SP800-56B key establishment scheme</selectable><selectable id="fcs_stg_ext.2.2_5">using AES in the <selectables><selectable id="fcs_stg_ext.2.2_6" >Key Wrap (KW) mode</selectable><selectable id="fcs_stg_ext.2.2_7" >Key Wrap with Padding (KWP) mode</selectable><selectable id="fcs_stg_ext.2.2_8" >GCM</selectable><selectable id="fcs_stg_ext.2.2_9" >CCM</selectable><selectable id="fcs_stg_ext.2.2_10" >CBC mode</selectable></selectables></selectable></selectables>. - The ST author selects which key encryption schemes are used by + separate proprietary evidence rather than being included in the TSS. + + + + + + + DEKs, KEKs, <assignable>any long-term trusted channel key material</assignable> + and <selectables> + <selectable>all software-based key storage</selectable> + <selectable exclusive="yes">no other keys</selectable> + </selectables> shall be encrypted using one of the following methods: <selectables> + <selectable>using a SP800-56B key establishment scheme</selectable> + <selectable>using AES in the <selectables> + <selectable>Key Wrap (KW) mode</selectable> + <selectable>Key Wrap with Padding (KWP) mode</selectable> + <selectable>GCM</selectable> + <selectable>CCM</selectable> + <selectable>CBC mode</selectable> + </selectables></selectable> + </selectables>. + The ST author selects which key encryption schemes are used by the TOE. This requirement refers only to KEKs as defined this PP and does not refer to those KEKs specified in other standards. The ST author must assign the same Long-term trusted channel key material assigned in FCS_STG_EXT.2.1. - - The evaluator shall examine the key hierarchy description in the TSS section to + + The evaluator shall examine the key hierarchy description in the TSS section to verify that each DEK and software-stored key is encrypted according to FCS_STG_EXT.2. - There are no guidance evaluation activities for this component. - There are no test evaluation activities for this component. - - - - - - - requires the TSF to implement integrity measures to protect the key storage. - There are no management activities foreseen. + There are no guidance evaluation activities for this component. + There are no test evaluation activities for this component. + + + + + + + requires the TSF to implement integrity measures to protect the key storage. + There are no management activities foreseen. - The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - Failure to verify the integrity of stored key. - - FCS_COP.1 Cryptographic Operation + The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: + + Failure to verify the integrity of stored key. + + + + FCS_COP.1 Cryptographic Operation FCS_STG_EXT.2 Encrypted Cryptographic Key Storage - - The TSF shall protect the integrity of any encrypted DEKs and KEKs and<selectables><selectable id="fcs_stg_ext.3.1_1" >long-term trusted channel key material</selectable><selectable id="fcs_stg_ext.3.1_2" >all software-based key storage</selectable><selectable id="fcs_stg_ext.3.1_3" exclusive="yes" >no other keys</selectable></selectables>by<selectables><selectable id="fcs_stg_ext.3.1_4"><selectables><selectable id="fcs_stg_ext.3.1_5" >GCM</selectable><selectable id="fcs_stg_ext.3.1_6" >CCM</selectable><selectable id="fcs_stg_ext.3.1_7" >Key Wrap</selectable><selectable id="fcs_stg_ext.3.1_8" >Key Wrap with Padding</selectable></selectables> cipher mode for encryption according to FCS_STG_EXT.2</selectable><selectable id="fcs_stg_ext.3.1_9" >a hash (FCS_COP.1<htm:b>/HASH</htm:b>) of the stored key that is encrypted by a key - protected by FCS_STG_EXT.2</selectable><selectable id="fcs_stg_ext.3.1_10" >a keyed hash (FCS_COP.1<htm:b>/KEYHMAC</htm:b>) using a key protected by a key - protected by FCS_STG_EXT.2</selectable><selectable id="fcs_stg_ext.3.1_11" >a digital signature of the stored key using an asymmetric key protected - according to FCS_STG_EXT.2</selectable><selectable id="fcs_stg_ext.3.1_12" >an immediate application of the key for decrypting the protected data + + <f-element id="fel-protect-key-what"> + <title>The TSF shall protect the integrity of any encrypted DEKs and KEKs and <selectables> + <selectable>long-term trusted channel key material</selectable> + <selectable>all software-based key storage</selectable> + <selectable exclusive="yes">no other keys</selectable> + </selectables> by <selectables linebreak="yes"> + <selectable><selectables> + <selectable>GCM</selectable> + <selectable>CCM</selectable> + <selectable>Key Wrap</selectable> + <selectable>Key Wrap with Padding</selectable> + </selectables> cipher mode for encryption according to FCS_STG_EXT.2</selectable> + <selectable>a hash (FCS_COP.1<htm:b>/HASH</htm:b>) of the stored key that is encrypted by a key + protected by FCS_STG_EXT.2</selectable> + <selectable>a keyed hash (FCS_COP.1<htm:b>/KEYHMAC</htm:b>) using a key protected by a key + protected by FCS_STG_EXT.2</selectable> + <selectable>a digital signature of the stored key using an asymmetric key protected + according to FCS_STG_EXT.2</selectable> + <selectable>an immediate application of the key for decrypting the protected data followed by a successful verification of the decrypted data with previously known - information</selectable></selectables>. - The ST author must assign the same Long-term trusted channel + information + . + + + The TSF shall protect the integrity of any encrypted DEKs and KEKs and <selectables> + <selectable>long-term trusted channel key material</selectable> + <selectable>all software-based key storage</selectable> + <selectable exclusive="yes">no other keys</selectable> + </selectables> by <selectables linebreak="yes"> + <selectable><selectables> + <selectable>GCM</selectable> + <selectable>CCM</selectable> + <selectable>Key Wrap</selectable> + <selectable>Key Wrap with Padding</selectable> + </selectables> cipher mode for encryption according to FCS_STG_EXT.2</selectable> + <selectable>a hash (FCS_COP.1) of the stored key that is encrypted by a key + protected by FCS_STG_EXT.2</selectable> + <selectable>a keyed hash (FCS_COP.1) using a key protected by a key + protected by FCS_STG_EXT.2</selectable> + <selectable>a digital signature of the stored key using an asymmetric key protected + according to FCS_STG_EXT.2</selectable> + <selectable>an immediate application of the key for decrypting the protected data + followed by a successful verification of the decrypted data with previously known + information</selectable> + </selectables>. + + + The ST author must assign the same Long-term trusted channel key material assigned in FCS_STG_EXT.2.1. - - - The TSF shall verify the integrity of the<selectables><selectable id="fcs_stg_ext.3.2_1" >hash</selectable><selectable id="fcs_stg_ext.3.2_2" >digital signature</selectable><selectable id="fcs_stg_ext.3.2_3" >MAC</selectable></selectables>of the stored key prior to use of the key. - This requirement is not applicable to derived keys that are not + + + The TSF shall verify the integrity of the <selectables> + <selectable>hash</selectable> + <selectable>digital signature</selectable> + <selectable>MAC</selectable> + </selectables> of the stored key prior to use of the key. + This requirement is not applicable to derived keys that are not stored. It is not expected that a single key will be protected from corruption by multiple of these methods; however, a product may use one integrity-protection method for one type of key and a different method for other types of keys. The explicit Evaluation Activities for each of the options will be addressed in each of the requirements (FCS_COP.1.1/HASH, FCS_COP.1.1/KEYHMAC). Key Wrapping must be implemented per SP800-38F. - - The evaluator shall examine the key hierarchy description in the TSS section to + + The evaluator shall examine the key hierarchy description in the TSS section to verify that each encrypted key is integrity protected according to one of the - options in FCS_STG_EXT.3. The evaluator shall also ensure that the documentation of the product's encryption key + options in FCS_STG_EXT.3. + The evaluator shall also ensure that the documentation of the product's encryption key management is detailed enough that, after reading, the product's key management hierarchy is clear and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as - separate proprietary evidence rather than being included in the TSS. - There are no guidance evaluation activities for this component. - There are no test evaluation activities for this component. - - - - Failure to verify integrity of stored key - Identity of key being verified - - -
    - -
    - + separate proprietary evidence rather than being included in the TSS. + + There are no guidance evaluation activities for this component. + There are no test evaluation activities for this component. + + + + Failure to verify integrity of stored key + Identity of key being verified + + + + + + A subset of the User Data Protection focuses on protecting Data-At-Rest, namely FDP_DAR_EXT.1 and FDP_DAR_EXT.2. Three levels of data-at-rest protection are addressed: TSF data, Protected Data (and keys), and sensitive data. - addresses the level of protection required for each level of data-at-rest. - : Protection of Data Levels Data LevelProtection RequiredTSF DataTSF data does not require confidentiality, but does require integrity protection. (FPT_TST_EXT.2/PREKERNEL)Protected DataProtected data is encrypted while powered off. (FDP_DAR_EXT.1)Sensitive DataSensitive data is encrypted while in the locked state, in addition to while powered off. (FDP_DAR_EXT.2) - All keys, protected data, and sensitive data must ultimately be protected by the REK. Sensitive data must be protected by the password in addition to the REK. In particular, has KEKs protected according to these requirements: DEK_1 would be appropriate for sensitive data, DEK_2 would not be appropriate for sensitive data, K_1 is not considered a sensitive key, and K_2 is considered a sensitive key. + addresses the level of protection required for each level of data-at-rest. + + : Protection of Data Levels + + + Data LevelProtection Required + TSF DataTSF data does not require confidentiality, but does require integrity protection. (FPT_TST_EXT.2/PREKERNEL) + Protected DataProtected data is encrypted while powered off. (FDP_DAR_EXT.1) + Sensitive DataSensitive data is encrypted while in the locked state, in addition to while powered off. (FDP_DAR_EXT.2) + + + All keys, protected data, and sensitive data must ultimately be protected by the REK. Sensitive data must be protected by the password in addition to the REK. In particular, has KEKs protected according to these requirements: DEK_1 would be appropriate for sensitive data, DEK_2 would not be appropriate for sensitive data, K_1 is not considered a sensitive key, and K_2 is considered a sensitive key. These requirements include a capability for encrypting sensitive data received while in the locked state, which may be considered a separate sub-category of sensitive data. This capability may be met by a key transport scheme (RSA) by using a public key to encrypt the DEK while protecting the corresponding private key with a password-derived or biometric-unlocked KEK. This capability may also be met by a key agreement scheme. To do so, the device generates a device-wide sensitive data asymmetric pair (the private key of which is protected by a password-derived or biometric-unlocked KEK) and an asymmetric pair for the received sensitive data to be stored. In order to store the sensitive data, the device-wide public key and data private key are used to generate a shared secret, which can be used as a KEK or a DEK. The data private key and shared secret are cleared after the data is encrypted and the data public key stored. Thus, no key material is available in the locked state to decrypt the newly stored data. Upon unlock, the device-wide private key is decrypted and is used with each data public key to regenerate the shared secret and decrypt the stored data. - , below, illustrates this scheme.
    - - - requires the TSF to be able to control access to its own services. - The following actions could be considered for the management functions in FMT: - Placing applications into application groups based on enterprise configuration settings.Enabling/disabling location services.Enabling/disabling data signaling over externally-accessible hardware ports. - There are no auditable events foreseen. - FMT_SMR.1 Security Roles + , below, illustrates this scheme. +
    + + + + + This family defines the rules for access control functions that are not addressed by the FDP_ACF family in CC Part 2. + + + + + + + requires the TSF to be able to control access to its own services. + The following actions could be considered for the management functions in FMT: + + Placing applications into application groups based on enterprise configuration settings. + Enabling/disabling location services. + Enabling/disabling data signaling over externally-accessible hardware ports. + + + There are no auditable events foreseen. + FMT_SMR.1 Security Roles + + - The TSF shall provide a mechanism to restrict the system services that are accessible to an application. + The TSF shall provide a mechanism to restrict the system services that are + accessible to an application. Examples of system services to which this requirement applies - include: Obtain data from camera and microphone input devicesObtain current device locationRetrieve credentials from system-wide credential storeRetrieve contacts list / address bookRetrieve stored picturesRetrieve text messagesRetrieve emailsRetrieve device identifier informationObtain network access + include: + + Obtain data from camera and microphone input devices + Obtain current device location + Retrieve credentials from system-wide credential store + Retrieve contacts list / address book + Retrieve stored pictures + Retrieve text messages + Retrieve emails + Retrieve device identifier information + Obtain network access + + The evaluator shall ensure the TSS lists all system services available for use by an application. The evaluator shall also ensure that the TSS describes how applications interface with these system services, and means by which these system services are protected by the TSF. The TSS shall describe which - of the following categories each system service falls in:No applications are allowed accessPrivileged applications are allowed accessApplications are allowed access by user authorizationAll applications are allowed access Privileged applications include any applications developed by the TSF + of the following categories each system service falls in: + + No applications are allowed access + Privileged applications are allowed access + Applications are allowed access by user authorization + All applications are allowed access + Privileged applications include any applications developed by the TSF developer. The TSS shall describe how privileges are granted to third-party applications. For both types of privileged applications, the TSS shall describe how and when the privileges are verified and how the TSF prevents unprivileged @@ -2369,9 +5037,15 @@ The evaluator shall generate 10 private/public key pairs using the key generatio whether the user is prompted for authorization when the application is installed, or during runtime. The evaluator shall ensure that the operational user guidance contains instructions for restricting application access to system services. - + + There are no guidance evaluation activities for this element. + Evaluation Activity Note: The following tests require the vendor to + provide access to a test platform that provides the evaluator with tools that are + typically not found on consumer Mobile Device products. The + evaluator shall write, or the developer shall provide, applications for the purposes + of the following tests. For each system service to which no applications are allowed access, the evaluator shall attempt to access the system service with a test application and @@ -2396,19 +5070,43 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - The TSF shall provide an access control policy that prevents<selectables><selectable id="s-fdp-app" >application</selectable><selectable id="fdp_group" >groups of applications</selectable></selectables>from accessing<selectables><selectable id="fdp_acf_ext.1.2_1" >all</selectable><selectable id="s-private" >private</selectable></selectables>data stored by other<selectables><selectable id="fdp_acf_ext.1.2_2" >application</selectable><selectable id="fdp_acf_ext.1.2_3" >groups of applications</selectable></selectables>. Exceptions may only be explicitly authorized for such sharing by<selectables><selectable id="s-acl-user" >the user</selectable><selectable id="s-acl-admin" >the administrator</selectable><selectable id="s-acl-devel" >a common application developer</selectable><selectable id="fdp_acf_ext.1.2_4" >no one</selectable></selectables>. + The TSF shall provide an access control policy that prevents <selectables> + <selectable id="s-fdp-app">application</selectable> + <selectable id="fdp_group">groups of applications</selectable> + </selectables> from accessing <selectables> + <selectable>all</selectable> + <selectable id="s-private">private</selectable> + </selectables> data stored by other <selectables> + <selectable>application</selectable> + <selectable>groups of applications</selectable> + </selectables>. Exceptions may only be explicitly authorized for such sharing by <selectables> + <selectable id="s-acl-user">the user</selectable> + <selectable id="s-acl-admin">the administrator</selectable> + <selectable id="s-acl-devel">a common application developer</selectable> + <selectable>no one</selectable> + </selectables>. + + The TSF shall provide an access control policy that prevents + <assignable>list of subjects</assignable> from accessing + <selectables><selectable>all</selectable><selectable>private</selectable> + </selectables> data stored by other <assignable>list of subjects</assignable>. + Exceptions may only be explicitly authorized for such sharing by + <assignable>list of authorized subjects</assignable>. + Application groups may be designated Enterprise or Personal. Applications installed by the user default to being in the Personal application group - unless otherwise designated by the administrator in function of FMT_SMF.1.1. Applications installed by the administrator + unless otherwise designated by the administrator in function of FMT_SMF.1.1. Applications installed by the administrator default to being in the Enterprise application group (this category includes applications that the user requests the administrator install, for instance by selecting the application for installation through an enterprise application catalog) - unless otherwise designated by the administrator in function of FMT_SMF.1.1. It is acceptable for the same application to + unless otherwise designated by the administrator in function of FMT_SMF.1.1. It is acceptable for the same application to have multiple instances installed, each in different application groups. Private data is defined as data that is accessible only by the application that wrote it. Private data is distinguished from data that an application may, by design, write to shared storage areas. - If is selected, FDP_ACF_EXT.2 must be included in the ST. + If is selected, FDP_ACF_EXT.2 must be included in the ST. The evaluator shall examine the TSS to verify that it describes which data @@ -2422,46 +5120,62 @@ The evaluator shall generate 10 private/public key pairs using the key generatio The evaluator shall write, or the developer shall provide, two applications, one that saves data containing a unique string and the other, which attempts to access that data. - If is selected, the applications + If is selected, the applications shall be placed into different groups. - If is selected, the + If is selected, the evaluator shall install the two applications. - If is selected, the + If is selected, the application shall not write to a designated shared storage area. The evaluator shall verify that the second application is unable to access the stored unique - string. If is selected, the evaluator shall grant + string. If is selected, the evaluator shall grant access as the user and verify that the second application is able to access the stored unique string. - If is selected, the + If is selected, the evaluator shall grant access as the administrator and verify that the second application is able to access the stored unique string. - If is selected, the evaluator shall grant access to + If is selected, the evaluator shall grant access to an, application with a common application developer to the first, and verify that the application is able to access the stored unique string. - - + + - - + + requires the TSF to be able to provide separate copies of system resources for different application groups. The following actions could be considered for the management functions in FMT: - Approving exceptions for sharing data between applications or groups of applications. + + Approving exceptions for sharing data between applications or groups of applications. + + There are no auditable events foreseen. - FDP_ACF_EXT.1 Access Control for System Services + FDP_ACF_EXT.1 Access Control for System Services FMT_SMR.1 Security Roles + - The TSF shall provide a separate<selectables><selectable id="fdp_acf_ext.2.1_1" >address book</selectable><selectable id="fdp_acf_ext.2.1_2" >calendar</selectable><selectable id="fdp_acf_ext.2.1_3" >keystore</selectable><selectable id="fdp_acf_ext.2.1_4">account credential database, <assignable>list of additional resources </assignable></selectable></selectables>for each application group and only allow applications within that process group to access the resource. Exceptions may only be explicitly authorized for such sharing by<selectables><selectable id="fdp_acf_ext.2.1_6" >the user</selectable><selectable id="fdp_acf_ext.2.1_7" >the administrator</selectable><selectable id="fdp_acf_ext.2.1_8" >no one</selectable></selectables>. - If is selected in FDP_ACF_EXT.1.2, + The TSF shall provide a separate <selectables> + <selectable>address book</selectable> + <selectable>calendar</selectable> + <selectable>keystore</selectable> + <selectable>account credential database, <assignable>list of additional + resources</assignable></selectable> + </selectables> for each application group and only allow applications within that + process group to access the resource. Exceptions may only be explicitly authorized for + such sharing by <selectables> + <selectable>the user</selectable> + <selectable>the administrator</selectable> + <selectable>no one</selectable> + </selectables>. + If is selected in FDP_ACF_EXT.1.2, FDP_ACF_EXT.2 must be included in the ST. - + There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. For each selected resource, the evaluator shall cause data to be placed into @@ -2470,22 +5184,29 @@ The evaluator shall generate 10 private/public key pairs using the key generatio information and verify that it cannot access the information. - - + + - - + + requires the TSF to enforce policies on applications that prohibit write and execute permissions from being granted simultaneously. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. + - The TSF shall enforce an access control policy that prohibits an application from granting both write and execute permission to a file on the device except for<selectables><selectable id="fdp_acf_ext.3.1_1" >files stored in the application's private data folder</selectable><selectable id="fdp_acf_ext.3.1_2" >no exceptions</selectable></selectables>. - + The TSF shall enforce an access control policy that prohibits an application from + granting both write and execute permission to a file on the device except for <selectables> + <selectable>files stored in the application's private data folder</selectable> + <selectable>no exceptions</selectable> + </selectables>. + There are no TSS evaluation activities for this component. - There are no guidance evaluation activities for this component. - + There are no guidance evaluation activities for this component. + Evaluation Activity Note: The following tests require the developer to + provide access to a test platform that provides the evaluator with tools that are + typically not found on consumer Mobile Device products. The evaluator shall write, or the developer shall provide, an application that attempts to store a file with both write and execute permissions. If the @@ -2502,35 +5223,52 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - - + + - - + + + This family defines requirements for managing device backups. + + + + + + requires the TSF to be able to determine which data to include in backup operations. The following actions could be considered for the management functions in FMT: - Enable/disable backup of certain applications to a local or remote system. + + Enable/disable backup of certain applications to a local or remote system. + + There are no auditable events foreseen. No dependencies. + + - The TSF shall provide a mechanism for applications to mark<selectables><selectable id="s-all-app-data" >all application data</selectable><selectable id="s-sel-app-data" >selected application data</selectable></selectables>to be excluded from device backups. + The TSF shall provide a mechanism for applications to mark <selectables> + <selectable id="s-all-app-data">all application data</selectable> + <selectable id="s-sel-app-data">selected application data</selectable> + </selectables> to be excluded from device backups. + The TSF shall provide a mechanism for applications to mark <assignable>list of data categories </assignable> to be excluded from device backups. + Device backups include any mechanism built into the TOE that allows stored application data to be extracted over a physical port or sent over the network, but does not include any functionality implemented by a specific application itself if the application is not included in the TOE. The lack of a public/documented API for performing backups, when a private/undocumented API exists, is not sufficient to meet this requirement. - + There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. - If is selected, the evaluator shall install an + If is selected, the evaluator shall install an application that has marked all of its application data to be excluded from backups. The evaluator shall cause data to be placed into the application’s storage area. The evaluator shall attempt to back up the application data and verify that the backup fails or that the application’s data was not included in the backup. - If is selected, the evaluator shall + If is selected, the evaluator shall install an application that has marked selected application data to be excluded from backups. The evaluator shall cause data covered by "selected application data" to be placed into the application’s storage area. The evaluator shall attempt to backup @@ -2538,47 +5276,111 @@ The evaluator shall generate 10 private/public key pairs using the key generatio selected data is excluded from the backup. - - + + - - + + + This family defines requirements for managing Bluetooth devices. + + + + + + requires the TSF to manage which applications communicate with Bluetooth devices. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. - - The TSF shall limit the applications that may communicate with a particular paired Bluetooth device. - + + + + The TSF shall limit the applications that may communicate with a particular paired Bluetooth device. + + Not every application with privileges to use Bluetooth should be permitted to communicate with every paired Bluetooth device. For example, the TSF may choose to require that only the application that initiated the current connection may communicate with the device, or it may strictly tie the paired device to the first application that makes a socket connection to the device following initial pairing. Additionally, for more flexibility, the TSF may choose to provide the user with a way to select which applications on the device may communicate with or observe communications with each paired Bluetooth device. - - The evaluator shall ensure that the TSS describes the mechanism used to prevent unrestricted access to paired Bluetooth devices (or their communication data) by every application with access to the Bluetooth system service on the TOE. The evaluator shall verify that this method either restricts access to a single application or provides explicit control of the applications that may communicate with the paired Bluetooth device. - The evaluator shall verify that the AGD contains the steps to configure which applications are allowed to communicate with a given Bluetooth peripheral. - The evaluator shall establish a Bluetooth connection with any peripheral. The evaluator shall verify that an application that is allowed to communicate with the Bluetooth peripheral is able to and that an application that is not allowed to communicate with that Bluetooth peripheral is unable to communicate with the peripheral. + + The evaluator shall ensure that the TSS describes the mechanism used to prevent unrestricted access to paired Bluetooth devices (or their communication data) by every application with access to the Bluetooth system service on the TOE. The evaluator shall verify that this method either restricts access to a single application or provides explicit control of the applications that may communicate with the paired Bluetooth device. + The evaluator shall verify that the AGD contains the steps to configure which applications are allowed to communicate with a given Bluetooth peripheral. + The evaluator shall establish a Bluetooth connection with any peripheral. The evaluator shall verify that an application that is allowed to communicate with the Bluetooth peripheral is able to and that an application that is not allowed to communicate with that Bluetooth peripheral is unable to communicate with the peripheral. + + + + + - + ToDo: Remove per bio cPP module --> + + + This family defines requirements for implementation of data-at-rest protection. + + + + + requires the TSF to be able to protect all data with a chosen method of encryption. The following actions could be considered for the management functions in FMT: - Enabling data-at-rest protection.Enabling removable media’s data-at-rest protection. + + Enabling data-at-rest protection. + Enabling removable media’s data-at-rest protection. + + The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - Failure to encrypt/decrypt data. + + Failure to encrypt/decrypt data. + FCS_COP.1 Cryptographic Operation + + - Encryption shall cover all protected data. + Encryption shall cover all protected data. Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well. - Encryption shall be performed using DEKs with AES in the<selectables><selectable id="fdp_dar_ext.1.2_1" >XTS</selectable><selectable id="fdp_dar_ext.1.2_2" >CBC</selectable><selectable id="fdp_dar_ext.1.2_3" >GCM</selectable></selectables>mode with key size<selectables><selectable id="fdp_dar_ext.1.2_4" >128</selectable><selectable id="s-dar-256" >256</selectable></selectables>bits. + Encryption shall be performed using DEKs with AES in the <selectables> + <selectable>XTS</selectable> + <selectable>CBC</selectable> + <selectable>GCM</selectable> + </selectables> mode with key size <selectables> + <selectable>128</selectable> + <selectable id="s-dar-256">256</selectable> + </selectables> bits. + + Encryption shall be performed using DEKs with AES in the + <assignable>list of AES modes</assignable> mode with key size + <assignable>list of acceptable key sizes</assignable> bits. + + IVs must be generated in accordance with FCS_IV_EXT.1.1. - + The evaluator shall verify that the TSS section of the ST indicates which data is protected by the DAR implementation and what data is considered TSF data. The evaluator shall ensure that this data includes all protected data. @@ -2588,8 +5390,12 @@ The evaluator shall generate 10 private/public key pairs using the key generatio user to perform any actions beyond configuration and providing the authentication credential. The evaluator shall also review the AGD guidance to determine that the configuration does not require the user to identify encryption on a per-file basis. - + + + Evaluation Activity Note: The following test requires the developer to + provide access to a test platform that provides the evaluator with tools that are + typically not found on consumer Mobile Device products. The evaluator shall enable encryption according to the AGD guidance. The evaluator shall create user data (non-system) either by creating a file or by @@ -2600,27 +5406,31 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - - - - Failure to encrypt/decrypt data - none - - - + + Failure to encrypt/decrypt datanone + - - + + requires the TSF to protect the Trust Anchor Database. - The following actions could be considered for the management functions in FMT: Importing X.509v3 certificates into the Trust Anchor Database.Removing imported X.509v3 certificates from the Trust Anchor Database.Approving import and removal by applications of X.509v3 certificates in the Trust Anchor Database. + The following actions could be considered for the management functions in FMT: + Importing X.509v3 certificates into the Trust Anchor Database. + Removing imported X.509v3 certificates from the Trust Anchor Database. + Approving import and removal by applications of X.509v3 certificates in the Trust Anchor Database. + + The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - Addition or removal of certificate from Trust Anchor Database - FCS_COP.1 Cryptographic Operation - FCS_CKM.2 Cryptographic Key Establishment + + Addition or removal of certificate from Trust Anchor Database + + FCS_COP.1 Cryptographic Operation + FCS_CKM.2 Cryptographic Key Establishment FCS_STG_EXT.2 Encrypted Cryptographic Key Storage + - The TSF shall provide a mechanism for applications to mark data and keys as sensitive. + The TSF shall provide a mechanism for applications to mark data and keys as + sensitive. Data and keys that have been marked as sensitive will be subject to certain restrictions (through other requirements) in both the locked and unlocked states of the Mobile Device. This mechanism allows an application to choose @@ -2638,17 +5448,20 @@ The evaluator shall generate 10 private/public key pairs using the key generatio keys as sensitive. This description shall also contain information reflecting how data and keys marked in this manner are distinguished from data and keys that are not (for instance, tagging, segregation in a "special" area of memory or container, - etc.). + etc.). + There are no guidance evaluation activities for this element. The evaluator shall enable encryption of sensitive data and require user authentication according to the AGD guidance. The evaluator shall try to access and create sensitive data (as defined in the ST and either by creating a file or using an application to generate sensitive data) in order to verify that no - other user interaction is required. + other user interaction is required. + - The TSF shall use an asymmetric key scheme to encrypt and store sensitive data received while the product is locked. + The TSF shall use an asymmetric key scheme to encrypt and store sensitive data + received while the product is locked. Sensitive data is encrypted according to FDP_DAR_EXT.1.2. The asymmetric key scheme must be performed in accordance with FCS_CKM.2/LOCKED. The intent of this requirement is to allow the device to receive @@ -2665,7 +5478,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio key of an asymmetric pair (the RSA private key and the device-wide private key, respectively) be cleared when transitioning to the locked state. - The evaluator shall review the TSS section of the ST to determine that the TSS + The evaluator shall review the TSS section of the ST to determine that the TSS includes a description of the process of receiving sensitive data while the device is in a locked state. The evaluator shall also verify that the description indicates if sensitive data that may be received in the locked state is treated differently @@ -2675,7 +5488,8 @@ The evaluator shall generate 10 private/public key pairs using the key generatio being decrypted by wiping all key material used to derive or encrypt the data (as described in the application note). The introduction to this section provides two different schemes that meet the requirements, but other solutions may address this - requirement. + requirement. + There are no guidance evaluation activities for this element. The evaluator shall perform the tests in FCS_CKM_EXT.4 for all key material no longer needed while in the locked state and shall ensure that keys for the @@ -2684,7 +5498,13 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - The TSF shall encrypt any stored symmetric key and any stored private key of the asymmetric keys used for the protection of sensitive data according to [ <htm:i>FCS_STG_EXT.2.1 selection 2</htm:i> ]. + The TSF shall encrypt any stored symmetric key and any stored private key of the + asymmetric keys used for the protection of sensitive data according to + [<htm:i>FCS_STG_EXT.2.1 selection 2</htm:i>]. + + The TSF shall encrypt any stored symmetric key and any stored private key of the + asymmetric keys used for the protection of sensitive data according to <assignable>mechanism for encrypted key storage</assignable>. + Symmetric keys used to encrypt sensitive data while the TSF is in the unlocked state must be encrypted with (or chain to a KEK encrypted with) the REK and password-derived or biometric-unlocked KEK. A stored private key of the @@ -2701,51 +5521,69 @@ The evaluator shall generate 10 private/public key pairs using the key generatio of any private keys of the asymmetric pairs. The evaluator shall ensure that any private keys that are not wiped and are stored by the TSF are stored encrypted by a key encrypted with (or chain to a KEK encrypted with) the REK and password-derived - or biometric-unlocked KEK. The evaluator shall also ensure that the documentation of the product's encryption key + or biometric-unlocked KEK. + The evaluator shall also ensure that the documentation of the product's encryption key management is detailed enough that, after reading, the product's key management hierarchy is clear and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as - separate proprietary evidence rather than being included in the TSS. + separate proprietary evidence rather than being included in the TSS. + There are no guidance evaluation activities for this element. There are no test evaluation activities for this element. - The TSF shall decrypt the sensitive data that was received while in the locked state upon transitioning to the unlocked state using the asymmetric key scheme and shall re-encrypt that sensitive data using the symmetric key scheme. + The TSF shall decrypt the sensitive data that was received while in the locked + state upon transitioning to the unlocked state using the asymmetric key scheme and + shall re-encrypt that sensitive data using the symmetric key scheme. The evaluator shall verify that the TSS section of the ST that describes the asymmetric key scheme includes a description of the actions taken by the TSF for the purposes of DAR upon transitioning to the unlocked state. These actions shall minimally include decrypting all received data using the asymmetric key scheme and re-encrypting with the symmetric key scheme used to store data while the device is - unlocked. + unlocked. + There are no guidance evaluation activities for this element. There are no test evaluation activities for this element. - - - - Failure to encrypt/decrypt data - none - - - + + Failure to encrypt/decrypt datanone + - - + + + This family defines requirements for handling of information flows that are not addressed by FDP_IFC in CC Part 2. + + + + + requires the TSF to be able to support the use of an IPsec VPN to protect data in transit. The following actions could be considered for the management functions in FMT: - Enabling/disabling VPN protection.Enabling/disabling Always On VPN protection. + + Enabling/disabling VPN protection. + Enabling/disabling Always On VPN protection. + + There are no auditable events foreseen. FTP_ITC_EXT.1 Trusted Channel Communication + - The TSF shall<selectables><selectable id="fdp_ifc_ext.1.1_1" >provide an interface which allows a VPN client to protect all IP traffic - using IPsec</selectable><selectable id="fdp_ifc_ext.1.1_2" >provide a VPN client which can protect all IP traffic using - IPsec <htm:b>as defined in the <xref to="mod-vpnclient"></xref></htm:b></selectable></selectables>with the exception of IP traffic needed to manage the VPN connection, and<selectables><selectable id="fdp_ifc_ext.1.1_4" ><assignable>traffic needed for correct functioning of the TOE </assignable></selectable><selectable id="fdp_ifc_ext.1.1_5" >no other traffic</selectable></selectables>, when the VPN is enabled. + The TSF shall <selectables linebreak="yes"> + <selectable>provide an interface which allows a VPN client to protect all IP traffic + using IPsec</selectable> + <selectable>provide a VPN client which can protect all IP traffic using + IPsec <htm:b>as defined in the <xref to="mod-vpnclient"/></htm:b></selectable> + </selectables> with the exception of IP traffic needed to manage the VPN + connection, and + <selectables> + <selectable><assignable>traffic needed for correct functioning of the TOE</assignable></selectable> + <selectable>no other traffic</selectable></selectables>, when the VPN is enabled. Typically, the traffic needed to manage the VPN connection is referred to as "Control Plane" traffic; whereas, the IP traffic protected by the IPsec VPN is referred to as "Data Plane" traffic. All "Data Plane" traffic must flow @@ -2757,12 +5595,13 @@ The evaluator shall generate 10 private/public key pairs using the key generatio TOE’s network stack to perform the required Information Flow Control. The ST author must select the second option if the TSF implements - a native VPN client ( is selected in ). Thus the TSF must be - validated against the and the ST author must also include - from the . It is optional for - the VPN client to be configured to be always-on per FMT_SMF.1 Function . Always-on means the establishment of an IPsec trusted channel + a native VPN client ( is selected in ). Thus the TSF must be + validated against the and the ST author must also include + FDP_IFC_EXT.1 from the . It is optional for + the VPN client to be configured to be always-on per FMT_SMF.1 Function . Always-on means the establishment of an IPsec trusted channel to allow any communication by the TSF. - + The evaluator shall verify that the TSS section of the ST describes the routing of IP traffic through processes on the TSF when a VPN client is enabled. The evaluator shall ensure that the description indicates which traffic does not go @@ -2772,11 +5611,18 @@ The evaluator shall generate 10 private/public key pairs using the key generatio TSS section describes any differences in the routing of IP traffic when using any supported baseband protocols (e.g. Wi-Fi or, LTE). The evaluator shall verify that one (or more) of the following options is - addressed by the documentation: The description above indicates that if a VPN client is enabled, all + addressed by the documentation: + + The description above indicates that if a VPN client is enabled, all configurations route all Data Plane traffic through the tunnel interface - established by the VPN client.The AGD guidance describes how the user or administrator can configure - the TSF to meet this requirement.The API documentation includes a security function that allows a VPN - client to specify this routing. + established by the VPN client. + The AGD guidance describes how the user or administrator can configure + the TSF to meet this requirement. + The API documentation includes a security function that allows a VPN + client to specify this routing. + + + If the ST author identifies any differences in the routing between Wi-Fi and @@ -2817,22 +5663,32 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - + - - + + + This family defines requirements for managing data storage. + + + + + requires the TSF to be able to label, encrypt, store, and decrypt sensitive data and keys. There are no management activities foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - Failure to encrypt/decrypt data. - FCS_COP.1 Cryptographic Operation - FCS_CKM.2 Cryptographic Key Establishment + + Failure to encrypt/decrypt data. + + FCS_COP.1 Cryptographic Operation + FCS_CKM.2 Cryptographic Key Establishment FCS_STG_EXT.2 Encrypted Cryptographic Key Storage + + - The TSF shall provide protected storage for the Trust Anchor Database. - + The TSF shall provide protected storage for the Trust Anchor Database. + The evaluator shall ensure the TSS describes the Trust Anchor Database implemented that contain certificates used to meet the requirements of this PP. This description shall contain information pertaining to how certificates are loaded into @@ -2843,62 +5699,131 @@ The evaluator shall generate 10 private/public key pairs using the key generatio There are no test evaluation activities for this component. - - Addition or removal of certificate from Trust Anchor Database - Subject name of certificate. - - - - - requires the TSF to be able to protect communication channels between products using a chosen secure method. - There are no management activities foreseen. - The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - Application initiation of trusted channel. - FTP_ITC_EXT.1 Trusted Channel Communication - - The TSF shall provide a means for non-TSF applications executing on the TOE to use<assignable>data transfer protocol</assignable>to provide a protected communication channel between the non-TSF application and another IT product that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data. - - - The TSF shall permit the non-TSF applications to initiate communication via the trusted channel. - + + Addition or removal of certificate from Trust Anchor Database + Subject name of certificate. + - - + + + + This family defines requirements for the use of trusted channel protocols to protect user data. + + + + + + + requires the TSF to be able to protect communication channels between products using a chosen secure method. + There are no management activities foreseen. + The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: + + Application initiation of trusted channel. + + FTP_ITC_EXT.1 Trusted Channel Communication + + + + The TSF shall provide a means for non-TSF applications executing on the TOE to use + <assignable>data transfer protocol</assignable> + to provide a protected communication channel between the non-TSF application and another IT product + that is logically distinct from other communication channels, + provides assured identification of its end points, protects channel data from disclosure, + and detects modification of the channel data. + + + + The TSF shall permit the non-TSF applications to initiate communication via the + trusted channel. + + + + + + + + + - The TSF shall provide a means for non-TSF applications executing on the TOE to use [ <htm:i><htm:ul><htm:li>Mutually authenticated TLS as defined in the <xref to="pkg-tls"></xref>,</htm:li><htm:li>HTTPS,</htm:li></htm:ul>and <selectables><selectable id="upc_dtls" >mutually authenticated DTLS as defined in the <xref to="pkg-tls"></xref></selectable><selectable id="s-upc-ipsec" >IPsec as defined in the <xref to="mod-vpnclient"></xref></selectable><selectable id="fdp_upc_ext.1.1_APPS_1" exclusive="yes" >no other protocol</selectable></selectables></htm:i> ] to provide a protected communication channel between the non-TSF application and another IT product that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data. + The TSF shall provide a means for non-TSF applications executing on the TOE to use [<htm:i><htm:ul> + <htm:li>Mutually authenticated TLS as defined in the <xref to="pkg-tls"/>,</htm:li> + <htm:li>HTTPS,</htm:li> + </htm:ul>and <selectables linebreak="yes"> + <selectable id="upc_dtls">mutually authenticated DTLS as defined in the <xref to="pkg-tls"/></selectable> + <selectable id="s-upc-ipsec">IPsec as defined in the <xref to="mod-vpnclient"/></selectable> + <selectable exclusive="yes">no other protocol</selectable> + </selectables> </htm:i>] to provide a protected communication channel between the non-TSF + application and another IT product that is logically distinct from other communication + channels, provides assured identification of its end points, protects channel data + from disclosure, and detects modification of the channel data. The intent of this requirement is that one of the selected protocols is available for use by user applications running on the device for use in connecting to distant-end services that are not necessarily part of the enterprise infrastructure. It should be noted that the FTP_ITC_EXT.1 requires that all TSF communications be protected using the protocols indicated in that requirement, so the protocols required by this component ride "on top of" those listed in FTP_ITC_EXT.1. It should also be noted that some applications are part of the TSF, and FTP_ITC_EXT.1 requires that TSF applications be protected by at least one of the protocols in first selection in FTP_ITC_EXT.1. It is not required to have two different implementations of a protocol, or two different protocols, to satisfy both this requirement (for non-TSF apps) and FTP_ITC_EXT.1 (for TSF apps), as long as the services specified are provided. The ST author must list which trusted channel protocols are implemented by the Mobile Device for use by non-TSF apps. - The TSF must be validated against requirements from the , with the following selections made: FCS_TLS_EXT.1:TLS is selectedClient is selectedFCS_TLSC_EXT.1.1:The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.Mutual authentication must be selectedFCS_TLSC_EXT.1.3With no exceptions is selected. - If is selected, the TSF must be validated against requirements from the , with the following selections made: FCS_TLS_EXT.1:DTLS is selectedClient is selectedFCS_DTLSC_EXT.1.1:The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.Mutual authentication must be selectedFCS_DTLSC_EXT.1.3With no exceptions is selected. - If the ST author selects , the TSF must be validated against the PP-Module for Virtual Private Network (VPN) Clients. + The TSF must be validated against requirements from the , with the following selections made: + FCS_TLS_EXT.1: + + TLS is selected + Client is selected + + FCS_TLSC_EXT.1.1: + + The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1. + Mutual authentication must be selected + + FCS_TLSC_EXT.1.3 + + With no exceptions is selected. + + + + If is selected, the TSF must be validated against requirements from the , with the following selections made: + FCS_TLS_EXT.1: + + DTLS is selected + Client is selected + + FCS_DTLSC_EXT.1.1: + + The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1. + Mutual authentication must be selected + + FCS_DTLSC_EXT.1.3 + + With no exceptions is selected. + + + + If the ST author selects , the TSF must be validated against the PP-Module for Virtual Private Network (VPN) Clients. - The TSF shall permit the non-TSF applications to initiate communication via the trusted channel. - - The evaluator shall verify that the API documentation provided according to - includes the security functions (protection channel) + The TSF shall permit the non-TSF applications to initiate communication via the + trusted channel. + The evaluator shall verify that the API documentation provided according to + includes the security functions (protection channel) described in these requirements, and verify that the APIs implemented to support this requirement include the appropriate settings/parameters so that the application can both provide and obtain the information needed to assure mutual identification of the endpoints of the communication as required by this component. - The evaluator shall examine the TSS to determine that it describes that all + The evaluator shall examine the TSS to determine that it describes that all protocols listed in the TSS are specified and included in the requirements in the - ST. + ST. + The evaluator shall confirm that the operational guidance contains instructions necessary for configuring the protocols selected for use by the - applications. + applications. + - - The + Evaluation Activity Note: The following test requires the developer to + provide access to a test platform that provides the evaluator with tools that are + typically not found on consumer Mobile Device products. The evaluator shall write, or the developer shall provide access to, an application that requests protected channel services by the TSF. The evaluator shall verify that the results from the protected channel match the expected results according to the API documentation. This application may be used to assist in verifying the protected channel Evaluation Activities for the protocol requirements. The evaluator shall also - perform the following tests: + perform the following tests: The evaluators shall ensure that the application is able to initiate communications with an external IT entity using each protocol specified in the requirement, setting up the connections as described in the operational guidance @@ -2909,51 +5834,64 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - - Application initiation of trusted channel - Name of application. Trusted channel protocol. Non-TOE endpoint of connection - + + Application initiation of trusted channel + Name of application. Trusted channel protocol. Non-TOE endpoint of connection + - - + + - The TSF shall provide a means for non-TSF applications executing on the TOE to use [ <htm:i><htm:ul><htm:li>Bluetooth BR/EDR in accordance with the <xref to="mod-bluetooth"></xref>,</htm:li></htm:ul>and <selectables><selectable id="fdp_upc_ext.1.1_BLUETOOTH_1" >Bluetooth LE in accordance with the <xref to="mod-bluetooth"></xref></selectable><selectable id="fdp_upc_ext.1.1_BLUETOOTH_2" exclusive="yes" >no other protocol</selectable></selectables></htm:i> ] to provide a protected communication channel between the non-TSF application and another IT product that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data. - If the TOE includes Bluetooth hardware, + The TSF shall provide a means for non-TSF applications executing on the TOE to + use [<htm:i><htm:ul> + <htm:li>Bluetooth BR/EDR in accordance with the <xref to="mod-bluetooth"/>,</htm:li> + </htm:ul>and <selectables linebreak="yes"> + <selectable>Bluetooth LE in accordance with the <xref to="mod-bluetooth"/></selectable> + <selectable exclusive="yes">no other protocol</selectable> + </selectables> </htm:i>] to provide a protected communication channel between the non-TSF + application and another IT product that is logically distinct from other communication + channels, provides assured identification of its end points, protects channel data + from disclosure, and detects modification of the channel data. + If the TOE includes Bluetooth hardware, this requirement must be included in the ST. The intent of this requirement is that Bluetooth BR/EDR and optionally Bluetooth LE is available for use by user applications running on the device for use in connecting to distant-end services that are not necessarily part of the enterprise infrastructure. The ST author must list which trusted channel protocols are implemented by the Mobile Device for use by non-TSF apps. The TSF must be validated against requirements from the - . It should be noted that the FTP_ITC_EXT.1 requires that all + . It should be noted that the FTP_ITC_EXT.1 requires that all TSF communications be protected using the protocols indicated in that requirement, so the protocols required by this component ride "on top of" those listed in - FTP_ITC_EXT.1. + FTP_ITC_EXT.1. + - The TSF shall permit the non-TSF applications to initiate communication via the trusted channel. - - The evaluator shall verify that the API documentation provided according to - includes the security functions (protection channel) + The TSF shall permit the non-TSF applications to initiate communication via the + trusted channel. + The evaluator shall verify that the API documentation provided according to + includes the security functions (protection channel) described in these requirements, and verify that the APIs implemented to support this requirement include the appropriate settings/parameters so that the application can both provide and obtain the information needed to assure mutual identification of the endpoints of the communication as required by this component. - The evaluator shall examine the TSS to determine that it describes that all + The evaluator shall examine the TSS to determine that it describes that all protocols listed in the TSS are specified and included in the requirements in the - ST. + ST. + The evaluator shall confirm that the operational guidance contains instructions necessary for configuring the protocols selected for use by the - applications. + applications. + - - The + Evaluation Activity Note: The following test requires the developer to + provide access to a test platform that provides the evaluator with tools that are + typically not found on consumer Mobile Device products. The evaluator shall write, or the developer shall provide access to, an application that requests protected channel services by the TSF. The evaluator shall verify that the results from the protected channel match the expected results according to the API documentation. This application may be used to assist in verifying the protected channel Evaluation Activities for the protocol requirements. The evaluator shall also - perform the following tests: + perform the following tests: The evaluators shall ensure that the application is able to initiate communications with an external IT entity using each protocol specified in the requirement, setting up the connections as described in the operational guidance @@ -2964,33 +5902,64 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - - Application initiation of trusted channel - Name of application. Trusted channel protocol. Non-TOE endpoint of connection - + + Application initiation of trusted channel + Name of application. Trusted channel protocol. Non-TOE endpoint of connection + -
    - -
    - - + + + + + + This family defines requirements for authentication failure handling that are not addressed by the FIA_AFL family in CC Part 2. + + + + + + requires the TSF be able to manage unsuccessful authentication attempts and limit the number of attempts for each method. The following actions could be considered for the management functions in FMT: - Configuration of authentication failure limit. + + Configuration of authentication failure limit. + + The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - Exceeding configured authentication failure limit. - FCS_CKM_EXT.5 TSF Wipe + + Exceeding configured authentication failure limit. + + + FCS_CKM_EXT.5 TSF Wipe FIA_UAU.1 Timing of Authentication + + - The TSF shall consider password and<selectables><selectable id="fia_afl_ext.1.1_1" > biometric in accordance with the <xref to="mod-biometrics"></xref></selectable><selectable id="fia_afl_ext.1.1_2" > hybrid</selectable><selectable id="s-authfail-noother" exclusive="yes" > no other mechanism</selectable></selectables>as critical authentication mechanisms. + The TSF shall consider password and <selectables> + <!-- ToDo: Remove per bio cPP module: + <selectable>fingerprint</selectable> + <selectable> iris</selectable> + <selectable> face</selectable> + <selectable> voice</selectable> + <selectable> vein</selectable> --> + <selectable> biometric in accordance with the <xref to="mod-biometrics"/></selectable> + <selectable> hybrid</selectable> + <selectable exclusive="yes" id="s-authfail-noother"> no other mechanism</selectable> + </selectables> as critical authentication mechanisms. + + The TSF shall consider password and + <assignable>list of acceptable authentication mechanisms</assignable> + as critical authentication mechanisms. + + A critical authentication mechanism is one in which countermeasures are triggered (i.e. wipe of the device) when the maximum number of unsuccessful authentication attempts is exceeded, rendering the other factors unavailable. If no additional authentication mechanisms are - selected in FIA_UAU.5.1, then must be selected. + selected in FIA_UAU.5.1, then must be selected. If an additional authentication mechanism is selected in FIA_UAU.5.1, then it must only be selected in FIA_AFL_EXT.1.1 if surpassing the authentication failure threshold for biometric data @@ -3003,14 +5972,28 @@ The evaluator shall generate 10 private/public key pairs using the key generatio lock screen interface. - The TSF shall detect when a configurable positive integer within<assignable>range of acceptable values for each authentication mechanism</assignable>of<selectables><selectable id="s-authfail-num-unique" >unique</selectable><selectable id="s-authfail-num-non-unique" >non-unique</selectable></selectables>unsuccessful authentication attempts occur related to last successful authentication for each authentication mechanism. + The TSF shall detect when a configurable positive integer within + <assignable>range of acceptable values for each authentication + mechanism</assignable> of <selectables> + <selectable id="s-authfail-num-unique">unique</selectable> + <selectable id="s-authfail-num-non-unique">non-unique</selectable> + </selectables> unsuccessful authentication attempts occur related to last successful + authentication for each authentication mechanism. + + The TSF shall detect when a configurable positive integer within + <assignable>range of acceptable values for each authentication + mechanism</assignable> of + <selectables><selectable>unique</selectable><selectable>non-unique</selectable> + </selectables> unsuccessful authentication attempts occur related to last successful + authentication for each authentication mechanism. + The positive integers is configured according to - FMT_SMF.1.1 function . An unique + FMT_SMF.1.1 function . An unique authentication attempt is defined as any attempt to verify a password or biometric - sample, in which the input is different from a previous attempt. " " must be + sample, in which the input is different from a previous attempt. "" must be selected if the authentication system increments the counter only for unique unsuccessful authentication attempts. For example, if the same incorrect password is - attempted twice the authentication system increments the counter once. " " must be selected if the authentication system + attempted twice the authentication system increments the counter once. "" must be selected if the authentication system increments the counter for each unsuccessful authentication attempt, regardless of if the input is unique. For example, if the same incorrect password is attempted twice the authentication system @@ -3036,7 +6019,8 @@ The evaluator shall generate 10 private/public key pairs using the key generatio unsuccessful authentication attempts. - The TSF shall maintain the number of unsuccessful authentication attempts that have occurred upon power off. + The TSF shall maintain the number of unsuccessful authentication attempts that + have occurred upon power off. The TOE may implement an Authentication Factor interface that precedes another Authentication Factor interface in the boot sequence (for example, a volume DAR decryption interface which precedes the lock screen interface) before the @@ -3045,12 +6029,17 @@ The evaluator shall generate 10 private/public key pairs using the key generatio authentication attempts need not be maintained for the second interface. - When the defined number of unsuccessful authentication attempts has exceeded the maximum allowed for a given authentication mechanism, all future authentication attempts will be limited to other available authentication mechanisms, unless the given mechanism is designated as a critical authentication mechanism. + When the defined number of unsuccessful authentication attempts has exceeded the + maximum allowed for a given authentication mechanism, all future authentication + attempts will be limited to other available authentication mechanisms, unless the + given mechanism is designated as a critical authentication mechanism. In accordance with FIA_AFL_EXT.1.3, this requirement also applies after the TOE is powered off and powered back on. - When the defined number of unsuccessful authentication attempts for the last available authentication mechanism or single critical authentication mechanism has been surpassed, the TSF shall perform a wipe of all protected data. + When the defined number of unsuccessful authentication attempts for the last + available authentication mechanism or single critical authentication mechanism has + been surpassed, the TSF shall perform a wipe of all protected data. Wipe is performed in accordance with FCS_CKM_EXT.5. Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well. If the TOE @@ -3059,11 +6048,12 @@ The evaluator shall generate 10 private/public key pairs using the key generatio applies to all available interfaces. - The TSF shall increment the number of unsuccessful authentication attempts prior to notifying the user that the authentication was unsuccessful. + The TSF shall increment the number of unsuccessful authentication attempts prior + to notifying the user that the authentication was unsuccessful. This requirement is to ensure that if power is cut to the device directly after an authentication attempt, the counter will be incremented to reflect that attempt. - + The evaluator shall ensure that the TSS describes that a value corresponding to the number of unsuccessful authentication attempts since the last successful authentication is kept for each Authentication Factor interface. The evaluator shall @@ -3085,7 +6075,8 @@ The evaluator shall generate 10 private/public key pairs using the key generatio The evaluator shall verify that the AGD guidance describes how the administrator configures the maximum number of unique unsuccessful authentication - attempts. + attempts. + The evaluator shall configure the device with all authentication mechanisms @@ -3105,7 +6096,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio multiple authentication mechanisms utilize a shared counter, then the evaluator shall verify that the maximum number of unsuccessful authentication attempts can be reached by using each individual authentication mechanism and a combination - of all authentication mechanisms that share the counter. + of all authentication mechanisms that share the counter. The evaluator shall repeat test one, but shall power off (by removing the battery, if possible) the TOE between unsuccessful authentication attempts. The evaluator shall verify that the total number of unsuccessful authentication @@ -3114,25 +6105,357 @@ The evaluator shall generate 10 private/public key pairs using the key generatio Alternatively, if the number of authentication failures is not maintained for the interface under test, the evaluator shall verify that upon booting the TOE between unsuccessful authentication attempts another authentication factor - interface is presented before the interface under test. + interface is presented before the interface under test. - - Excess of authentication failure limit - Authentication factor used - + + Excess of authentication failure limit + Authentication factor used + + + - + + + The TSF shall perform Presentation Attack Detection testing up to the attack + potential of <selectables onlyone="yes"> + <selectable>basic</selectable> + <selectable>intermediate</selectable> + <selectable>advanced</selectable> + </selectables> attacks, for each biometric modalities selected in FIA_UAU.5.1 on each + enrollment and authentication attempt, rejecting detected spoofs. When an + authentication attempt fails due to PAD testing, the TSF shall not indicate to the + user the reason for failure to authenticate. + Presentation Attack Detection (PAD) is also known as liveness + detection or spoof detection. If multiple modalities are selected in FIA_UAU.5.1, then + this SFR must be iterated for each modality. For each modality, only one attack + strength must be selected. Because Presentation Attack Detection + (PAD) is an open-ended problem much like vulnerability testing, it is neither + cost-effective nor feasible to create a complete list of attack vectors and perform + testing on all of them during the time frame for CC evaluations. Such a list would be + ever-changing, and unlike code vulnerabilities (i.e. CVEs), the equipment, skill, + time, and cost required to test highly sophisticated attacks is highly infeasible for + a testing lab given the current time frame for CC evaluations. Nevertheless, it is a + known risk that has been documented by researchers for years. + Therefore, vendors are responsible for providing their own documentation specifying + the measures the TSF takes to mitigate presentation attacks and the appropriate + pen-testing (for example, red teaming and blue teaming) performed as proof. + To be specific, basic attacks (including basic and enhanced-basic + ) refer to attacks in literature of low skill that can be + performed on a limited budget. This includes, but is not limited to, playback attacks + of a spoken utterance using a different mobile device for voice authentication, taking + a photograph of a fingerprint or facial and submitting it to the sensor, among other + examples. Intermediate (or moderate ) attacks + can include, but are not limited to, creating a foam finger to thwart fingerprint + detection and using a higher quality playback device to thwart liveness detection. + Advanced (including high and beyond high ) + attacks can include, but are not limited to, creating a synthetic hand with the given + fingerprint using an expensive 3D-printer and forcing someone to reveal one’s + credentials through coercion or threats that may cause harm (where detection of duress + is required). Many of these attack techniques may be sensitive or government + classified. + + The testing methodology specified in ISO 19989 Information technology — Security + evaluation of presentation attack detection for biometrics is to be used to determine the efficacy of the PAD for the selected attack + potential. + + There are no guidance evaluation activities for this component. + Evaluation Activity Note: ISO 19989 is in draft status at the time of + publication of this PP. Once the ISO standard is published, it shall be used to meet + the evaluation activity for this requirement. Henniger, Scheuermann, and Kniess , provide a description of attack potential calculation with + examples. Until such time as ISO 19989 is published, the vendor shall provide to the + lab a description of the PAD processing implemented in the TSF, test procedures used + to validate successful operation of PAD, and test data with results of the PAD + validation testing. The lab may analyze the test procedures and data to validate + vendor test results or, optionally, may conduct its own testing. + If the lab performs its own testing, it is highly recommended that the vendor + provides spoof testing tools, as it is not expected for the lab to create a test + procedure for modalities outside of established standards and easily implemented + procedures. Labs can also expedite the testing process by purchasing the appropriate + spoof kits and recipes from specialized biometrics testing labs. + + + --> + + + This family defines requirements for the composition of password credentials. + + + + + requires the TSF to enforce character length and composition requirements for password credentials. The following actions could be considered for the management functions in FMT: - Configuring password policy. + + Configuring password policy. + + There are no auditable events foreseen. FIA_UAU.1 Timing of Authentication + + - The TSF shall support the following for the Password Authentication Factor: <htm:ol><htm:li>Passwords shall be able to be composed of any combination of <selectables><selectable id="fia_pmg_ext.1.1_1" >upper and lower case letters</selectable><selectable id="fia_pmg_ext.1.1_3" ><assignable>a character set of at least 52 characters </assignable></selectable></selectables>, numbers, and special characters: <selectables><selectable id="fia_pmg_ext.1.1_4" >"!"</selectable><selectable id="fia_pmg_ext.1.1_5" >"@"</selectable><selectable id="fia_pmg_ext.1.1_6" >"#"</selectable><selectable id="fia_pmg_ext.1.1_7" >"$"</selectable><selectable id="fia_pmg_ext.1.1_8" >"%"</selectable><selectable id="fia_pmg_ext.1.1_9" >"^"</selectable><selectable id="fia_pmg_ext.1.1_10" >"&"</selectable><selectable id="fia_pmg_ext.1.1_11" > "*"</selectable><selectable id="fia_pmg_ext.1.1_12" >"("</selectable><selectable id="fia_pmg_ext.1.1_13" >")"</selectable><selectable id="fia_pmg_ext.1.1_15" ><assignable>other characters </assignable></selectable></selectables>; </htm:li><htm:li>Password length up to <assignable>an integer greater than or equal to 14</assignable> characters shall be supported. </htm:li></htm:ol> + The TSF shall support the following for the Password Authentication Factor: <htm:ol> + <htm:li>Passwords shall be able to be composed of any combination of <selectables> + <selectable>upper and lower case letters</selectable> + <selectable><assignable>a character set of at least 52 + characters</assignable></selectable> + </selectables>, numbers, and special characters: <selectables> + <selectable>"!"</selectable> + <selectable>"@"</selectable> + <selectable>"#"</selectable> + <selectable>"$"</selectable> + <selectable>"%"</selectable> + <selectable>"^"</selectable> + <selectable>"&"</selectable> + <selectable> "*"</selectable> + <selectable>"("</selectable> + <selectable>")"</selectable> + <selectable><assignable>other characters</assignable></selectable> + </selectables>; </htm:li> + <htm:li>Password length up to <assignable>an integer greater than or equal to + 14</assignable> characters shall be supported. </htm:li> + </htm:ol> + While some corporate policies require passwords of 14 characters or better, the use of a REK for DAR protection and key storage protection and the anti-hammer requirement (FIA_TRT_EXT.1) addresses the threat of attackers with @@ -3143,7 +6466,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio encoding standard (such as Unicode) or defined in the assignment by the ST author. The ST author also selects the special characters that are supported by the TOE; they may optionally list additional special characters supported using the assignment. - + There are no TSS evaluation activities for this component. The evaluator shall examine the operational guidance to determine that it provides guidance to security administrators on the composition of strong passwords, @@ -3163,23 +6486,36 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - + - - + + + This family defines requirements for prevention of brute-force authentication attempts. + + + + + + requires the TSF to limit authentication attempts by number of attempts in a set amount of time. There are no management activities foreseen. There are no auditable events foreseen. FIA_UAU.5 Multiple Authentication Mechanisms + - The TSF shall limit automated user authentication attempts by<selectables><selectable id="fia_trt_ext.1.1_1" >preventing authentication via an external port</selectable><selectable id="fia_trt_ext.1.1_2" >enforcing a delay between incorrect authentication attempts</selectable></selectables>for all authentication mechanisms selected in FIA_UAU.5.1. The minimum delay shall be such that no more than 10 attempts can be attempted per 500 milliseconds. + The TSF shall limit automated user authentication attempts by <selectables> + <selectable>preventing authentication via an external port</selectable> + <selectable>enforcing a delay between incorrect authentication attempts</selectable> + </selectables> for all authentication mechanisms selected in FIA_UAU.5.1. The minimum + delay shall be such that no more than 10 attempts can be attempted per 500 + milliseconds. The authentication throttling applies to all authentication mechanisms selected in FIA_UAU.5.1. The user authentication attempts in this requirement are attempts to guess the Authentication Factor. The developer can implement the timing of the delays in the requirements using unequal or equal timing of delays. The minimum delay specified in this requirement provides defense against brute forcing. - + The evaluator shall verify that the TSS describes the method by which authentication attempts are not able to be automated. The evaluator shall ensure that the TSS describes either how the TSF disables authentication via external @@ -3191,31 +6527,47 @@ The evaluator shall generate 10 private/public key pairs using the key generatio There are no test evaluation activities for this component. - + - - + - The TSF shall provide <htm:b>password and <selectables><selectable id="uau_biometric" > biometric in accordance with the <xref to="mod-biometrics"></xref></selectable><selectable id="uau_hybr" > hybrid</selectable><selectable id="fia_uau.5.1_1" exclusive="yes" >no other mechanism</selectable></selectables></htm:b> to support user authentication. + The TSF shall provide <refinement>password and <selectables> + <!-- ToDo: Remove per bio cPP module: <selectable id="uau_fing">fingerprint</selectable> + <selectable id="uau_iris"> iris</selectable> + <selectable id="uau_face"> face</selectable> + <selectable id="uau_vox"> voice</selectable> + <selectable id="uau_vein"> vein</selectable> --> + <selectable id="uau_biometric"> biometric in accordance with the <xref to="mod-biometrics"/></selectable> + <selectable id="uau_hybr"> hybrid</selectable> + <selectable exclusive="yes">no other mechanism</selectable> + </selectables> + </refinement>to support user authentication. The TSF must support a Password Authentication Factor and may - optionally implement a BAF. A hybrid authentication factor is where a user has to submit a + optionally implement a BAF. A hybrid authentication factor is where a user has to submit a combination of PIN/password and biometric sample where both have to pass and if either fails the user is not made aware of which factor failed. - If or is selected, - then the TSF must be validated against requirements from the . + If or is selected, + then the TSF must be validated against requirements from the . - If is selected, does not need to be selected, but should be + If is selected, does not need to be selected, but should be selected if the biometric authentication can be used independent of the hybrid - authentication, i.e. without having to enter a PIN/password. + authentication, i.e. without having to enter a PIN/password. + The Password Authentication Factor is configured according to FIA_PMG_EXT.1. - The TSF shall authenticate any user's claimed identity according to the<assignable>rules describing how each authentication mechanism selected in FIA_UAU.5.1 provides authentication</assignable>. + The TSF shall authenticate any user's claimed identity according to the + <assignable>rules describing how each authentication mechanism selected in FIA_UAU.5.1 provides + authentication</assignable>. Rules regarding how the authentication factors interact in terms of unsuccessful authentication are covered in FIA_AFL_EXT.1. - + The evaluator shall ensure that the TSS describes each mechanism provided to support user authentication and the rules describing how the authentication mechanisms provide authentication. @@ -3226,7 +6578,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio successful authentication (i.e. is the user input used to derive or unlock a key) and which authentication mechanism can be used at which authentication factor interfaces (i.e. if there are times, for example, after a reboot, that only specific - authentication mechanisms can be used). If multiple BAFs are claimed in FIA_MBV_EXT.1.1 in the , the interaction between the BAFs must be described. For example, whether the + authentication mechanisms can be used). If multiple BAFs are claimed in FIA_MBV_EXT.1.1 in the , the interaction between the BAFs must be described. For example, whether the multiple BAFs can be enabled at the same time. The evaluator shall verify that configuration guidance for each authentication mechanism is addressed in the AGD guidance. @@ -3241,18 +6593,17 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - + - - + - The TSF shall re-authenticate the user <htm:b>via the Password - Authentication Factor</htm:b> under the conditions [ <htm:i>attempted change - to any supported authentication mechanisms</htm:i> ]. + The TSF shall re-authenticate the user <refinement>via the Password + Authentication Factor</refinement> under the conditions [<htm:i>attempted change + to any supported authentication mechanisms</htm:i>]. The password authentication factor must be entered before either the password or biometric authentication factor, if selected in FIA_UAU.5.1, can be changed. - + There are no TSS evaluation activities for this element. There are no guidance evaluation activities for this element. @@ -3262,12 +6613,12 @@ The evaluator shall generate 10 private/public key pairs using the key generatio Authentication Factor according to the AGD guidance and verify that the TSF requires the entry of the Password Authentication Factor before allowing the factor to be changed. - [conditional] If is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the the evaluator shall + [conditional] If is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the the evaluator shall configure the TSF to use the BAF, which includes configuring the Password Authentication Factor, according to the AGD guidance. The evaluator shall change the BAF according to the AGD guidance and verify that the TSF requires the entry of the Password Authentication Factor before allowing the BAF to be changed. - [conditional] If is selected in FIA_UAU.5.1, the evaluator shall + [conditional] If is selected in FIA_UAU.5.1, the evaluator shall configure the TSF to use the BAF and PIN or password, which includes configuring the Password Authentication Factor, according to the AGD guidance. The evaluator shall change the BAF and PIN according to the AGD guidance and verify that the @@ -3278,12 +6629,11 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - - + - The TSF shall re-authenticate the user <htm:b>via an authentication factor - defined in FIA_UAU.5.1</htm:b> under the conditions <htm:b>TSF-initiated - lock, user-initiated lock, <assignable>other conditions</assignable></htm:b> . + The TSF shall re-authenticate the user <refinement>via an authentication factor + defined in FIA_UAU.5.1</refinement> under the conditions <refinement>TSF-initiated + lock, user-initiated lock, <assignable>other conditions</assignable></refinement>. Depending on the selections made in FIA_UAU.5.1, either the password (at a minimum), biometric authentication or hybrid authentication mechanisms can be used to unlock the device. TSF-initiated and user-initiated locking is described in @@ -3298,41 +6648,40 @@ The evaluator shall generate 10 private/public key pairs using the key generatio evaluator shall wait until the TSF locks and then verify that the TSF requires the entry of the Password Authentication Factor before transitioning to the unlocked state. - [conditional] If is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the the evaluator shall + [conditional] If is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the the evaluator shall repeat Test 1 verifying that the TSF requires the entry of the BAF before transitioning to the unlocked state. - [conditional] If is selected in FIA_UAU.5.1, the evaluator shall + [conditional] If is selected in FIA_UAU.5.1, the evaluator shall repeat Test 1 verifying that the TSF requires the entry of the BAF and PIN/password before transitioning to the unlocked state. - The evaluator shall configure user-initiated locking according to the AGD + The evaluator shall configure user-initiated locking according to the AGD guidance. The evaluator shall lock the TSF and then verify that the TSF requires the entry of the Password Authentication Factor before transitioning to the unlocked state. - [conditional] If is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the the evaluator shall - repeat verifying that the TSF requires the entry of the BAF before + [conditional] If is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the the evaluator shall + repeat verifying that the TSF requires the entry of the BAF before transitioning to the unlocked state. - [conditional] If is selected in FIA_UAU.5.1, the evaluator shall - repeat verifying that the TSF requires the entry of the BAF and + [conditional] If is selected in FIA_UAU.5.1, the evaluator shall + repeat verifying that the TSF requires the entry of the BAF and PIN/password before transitioning to the unlocked state. - - User changes Password Authentication Factor - + + User changes Password Authentication Factor + - - + - The TSF shall provide only [ <htm:i>obscured feedback to the device’s - display</htm:i> ] to the user while the authentication is in progress. + The TSF shall provide only [<htm:i>obscured feedback to the device’s + display</htm:i>] to the user while the authentication is in progress. This applies to all authentication methods specified in FIA_UAU.5.1. The TSF may briefly (1 second or less) display each character or provide an option to allow the user to unmask the password; however, the password must be obscured by default. - If is selected in FIA_UAU.5.1, the TSF + If is selected in FIA_UAU.5.1, the TSF must not display sensitive information regarding any BAF that could aid an adversary in identifying or spoofing the respective biometric characteristics of a given human user. While it is true that biometric samples, by themselves, are not @@ -3340,9 +6689,9 @@ The evaluator shall generate 10 private/public key pairs using the key generatio output data from these biometric algorithms, is considered sensitive and must be kept secret. Where applicable, the TSF must not reveal or make public the reasons for authentication failure. - + The evaluator shall ensure that the TSS describes the means of obscuring the - authentication entry, for all authentication methods specified in FIA_UAU.5.1. + authentication entry, for all authentication methods specified in FIA_UAU.5.1. The evaluator shall verify that any configuration of this requirement is addressed in the AGD guidance and that the password is obscured by default. @@ -3350,8 +6699,8 @@ The evaluator shall generate 10 private/public key pairs using the key generatio The evaluator shall enter passwords on the device, including at least the Password Authentication Factor at lock screen, and verify that the password is not displayed on the device. - [conditional] If is selected in FIA_UAU.5.1, - for each BAF claimed in FIA_MBV_EXT.1.1 in the the evaluator shall + [conditional] If is selected in FIA_UAU.5.1, + for each BAF claimed in FIA_MBV_EXT.1.1 in the the evaluator shall authenticate by producing a biometric sample at lock screen. As the biometric algorithms are performed, the evaluator shall verify that sensitive images, audio, or other information identifying the user are kept secret and are not @@ -3367,24 +6716,38 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - + - - + + + This family defines requirements for user authentication that are not addressed by FIA_UAU in CC Part 2. + + + + + + requires the TSF enforce data-at-rest protection until successful authentication has occurred. There are no management activities foreseen. There are no auditable events foreseen. - FDP_DAR_EXT.1 Protected Data Encryption + FDP_DAR_EXT.1 Protected Data Encryption FDP_DAR_EXT.2 Sensitive Data Encryption + + - The TSF shall require the user to present the Password Authentication Factor prior to decryption of protected data and encrypted DEKs, KEKs and<selectables><selectable id="fia_uau_ext.1.1_1" >long-term trusted channel key material</selectable><selectable id="fia_uau_ext.1.1_2" >all software-based key storage</selectable><selectable id="fia_uau_ext.1.1_3" exclusive="yes" >no other keys</selectable></selectables>at startup. + The TSF shall require the user to present the Password Authentication Factor + prior to decryption of protected data and encrypted DEKs, KEKs and <selectables> + <selectable>long-term trusted channel key material</selectable> + <selectable>all software-based key storage</selectable> + <selectable exclusive="yes">no other keys</selectable> + </selectables> at startup. The intent of this requirement is to prevent decryption of protected data before the user has authorized to the device using the Password Authentication Factor. The Password Authentication Factor is also required in order derive the key used to decrypt sensitive data, which includes software-based secure key storage. - + The evaluator shall verify that the TSS section of the ST describes the process for decrypting protected data and keys. The evaluator shall ensure that this process requires the user to enter a Password Authentication Factor and, in accordance with @@ -3392,7 +6755,11 @@ The evaluator shall generate 10 private/public key pairs using the key generatio storage and (optionally) DEKs for sensitive data, in accordance with FCS_STG_EXT.2. There are no guidance evaluation activities for this component. - + The following tests may be performed in conjunction with FDP_DAR_EXT.1 and + FDP_DAR_EXT.2. + Evaluation Activity Note: The following test require the developer to + provide access to a test platform that provides the evaluator with tools that are + typically not found on consumer Mobile Device products. The evaluator shall enable encryption of protected data and require user authentication according to the AGD guidance. The evaluator shall write, or the @@ -3402,7 +6769,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio the application data, and verify that the unique string cannot be found. The evaluator shall enter the Password Authentication Factor to access full device functionality, use a tool provided by the developer to access the unique string - within the application data, and verify that the unique string can be found. + within the application data, and verify that the unique string can be found. [conditional] The evaluator shall require user authentication according to the AGD guidance. The evaluator shall store a key in the software-based secure key storage. The evaluator shall lock the device, use a tool @@ -3410,7 +6777,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio the key cannot be retrieved or accessed. The evaluator shall enter the Password Authentication Factor to access full device functionality, use a tool provided by developer to access the key, and verify that the key can be retrieved or - accessed. + accessed. [conditional] The evaluator shall enable encryption of sensitive data and require user authentication according to the AGD guidance. The evaluator shall write, or the developer shall provide access to, an application that includes a @@ -3425,29 +6792,43 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - + - - + + requires the TSF to prevent a subject’s use of TOE until the user is authenticated. The following actions could be considered for the management functions in FMT: - Enabling/disabling display TSF notifications while in the locked state.Enabling/disabling bypass of local user authentication. + + Enabling/disabling display TSF notifications while in the locked state. + Enabling/disabling bypass of local user authentication. + + The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - Action performed before authentication. + + Action performed before authentication. + + No dependencies. + - The TSF shall allow<selectables><selectable id="fia_uau_ext.2.1_2" ><assignable>list of actions </assignable></selectable><selectable id="fia_uau_ext.2.1_3" > no actions</selectable></selectables>on behalf of the user to be performed before the user is authenticated. + The TSF shall allow <selectables> + <selectable> + <assignable>list of actions</assignable></selectable> + <selectable> no actions</selectable> + </selectables> on behalf of the user to be performed before the user is authenticated. + - The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. + The TSF shall require each user to be successfully authenticated before allowing + any other TSF-mediated actions on behalf of that user. The security relevant actions allowed by unauthorized users in locked state must be listed. At a minimum the actions that correspond to the functions available to the user in FMT_SMF.1 and are allowed by unauthorized users in locked state should be listed. For example, if the user can enable/disable the camera per - function of FMT_SMF.1 and unauthorized users can + function of FMT_SMF.1 and unauthorized users can take a picture when the device is in locked state, this action must be listed. - + The evaluator shall verify that the TSS describes the actions allowed by unauthorized users in the locked state. There are no guidance evaluation activities for this component. @@ -3456,20 +6837,24 @@ The evaluator shall generate 10 private/public key pairs using the key generatio succeed. - - Action performed before authentication. - + + Action performed before authentication. + - requires the TSF to enforce the use of a secondary authentication factor to access certain user data. There are no management activities foreseen. There are no auditable events foreseen. - FDP_ACF_EXT.2 Access Control for System Resources + FDP_ACF_EXT.2 Access Control for System Resources FIA_UAU.5 Multiple Authentication Mechanisms + - The TSF shall provide a secondary authentication mechanism for accessing Enterprise applications and resources. The secondary authentication mechanism shall control access to the Enterprise application and shared resources and shall be incorporated into the encryption of protected and sensitive data belonging to Enterprise applications and shared resources. + The TSF shall provide a secondary authentication mechanism for accessing + Enterprise applications and resources. The secondary authentication mechanism shall + control access to the Enterprise application and shared resources and shall be + incorporated into the encryption of protected and sensitive data belonging to + Enterprise applications and shared resources. For the BYOD use case, Enterprise applications and data must be protected using a different password than the user authentication to gain access to the personal applications and data, if configured. @@ -3493,14 +6878,18 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - The TSF shall require the user to present the secondary authentication factor prior to decryption of Enterprise application data and Enterprise shared resource data. - + The TSF shall require the user to present the secondary authentication factor + prior to decryption of Enterprise application data and Enterprise shared resource + data. + + + The intent of this requirement is to prevent decryption of protected Enterprise application data and Enterprise shared resource data before the user has authenticated to the device using the secondary authentication factor. Enterprise shared resource data consists of the FDP_ACF_EXT.2.1 selections. - The evaluator shall verify that the TSS section of the ST describes the process + The evaluator shall verify that the TSS section of the ST describes the process for decrypting Enterprise application data and shared resource data. The evaluator shall ensure that this process requires the user to enter an Authentication Factor and, in accordance with FCS_CKM_EXT.3, derives a KEK which is used to protect the @@ -3510,89 +6899,178 @@ The evaluator shall generate 10 private/public key pairs using the key generatio There are no test evaluation activities for this element. - + - - + + + This family defines requirements for the management and use of X.509 certificates. + + + + + specifies the rules the TSF must follow to determine if a particular X.509 certificate is valid. There are no management activities foreseen. The following action is be auditable: - Failure to validate X.509v3 certificate. + + Failure to validate X.509v3 certificate. + + FCS_COP.1 Cryptographic Operation + + - The TSF shall validate certificates in accordance with the following rules: <htm:ul><htm:li>RFC 5280 certificate validation and certificate path validation.</htm:li><htm:li>The certificate path must terminate with a certificate in the Trust Anchor Database.</htm:li><htm:li>The TSF shall validate a certificate path by ensuring the presence of the basicConstraints extension, that the CA flag is set to TRUE for all CA certificates, and that any path constraints are met.</htm:li><htm:li>The TSF shall validate that any CA certificate includes caSigning purpose in the key usage field.</htm:li><htm:li>The TSF shall validate the revocation status of the certificate using <selectables><selectable id="fia_x509_ext.1.1_1" >OCSP as specified in RFC 6960</selectable><selectable id="s-crl" >CRL as specified in RFC 5759</selectable><selectable id="fia_x509_ext.1.1_2" >an OCSP TLS Status Request Extension (OCSP stapling) as specified in RFC 6066</selectable><selectable id="fia_x509_ext.1.1_3" >OCSP TLS Multi-Certificate Status Request Extension (i.e., OCSP Multi-Stapling) as specified in RFC 6961</selectable></selectables>.</htm:li><htm:li>The TSF shall validate the extendedKeyUsage field according to the following rules:<htm:ul><htm:li>Certificates used for trusted updates and executable code integrity verification shall have the Code Signing Purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field.</htm:li><htm:li>Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.</htm:li><htm:li>Server certificates presented for EST shall have the CMC Registration Authority (RA) purpose (id-kp-cmcRA with OID 1.3.6.1.5.5.7.3.28) in the extendedKeyUsage field. [conditional]</htm:li><htm:li>Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.</htm:li><htm:li>OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field. [conditional]</htm:li></htm:ul></htm:li></htm:ul> - FIA_X509_EXT.1.1 lists the rules for validating certificates. The ST author must select whether revocation status is verified using OCSP or CRLs. OCSP stapling and OCSP multi-stapling only support TLS server certificate validation. If other certificate types are validated, either OCSP or CRL should be claimed. The , to which a MDF TOE must also conform, requires that certificates are used for EAP-TLS; this use requires that the extendedKeyUsage rules are verified. Certificates may optionally be used for trusted updates of system software and applications (FPT_TUD_EXT.2) and for integrity verification (FPT_TST_EXT.2(1)) and, if implemented, must be validated to contain the Code Signing purpose extendedKeyUsage. - While FIA_X509_EXT.1.1 requires that the TOE perform certain checks on the certificate presented by a TLS server, there are corresponding checks that the authentication server will have to perform on the certificate presented by the client; namely that the extendedKeyUsage field of the client certificate includes “Client Authentication” and that the key agreement bit (for the Diffie-Hellman ciphersuites) or the key encipherment bit (for RSA ciphersuites) be set. Certificates obtained for use by the TOE will have to conform to these requirements in order to be used in the enterprise. This check is required to support EAP-TLS for the . + The TSF shall validate certificates in accordance with the following rules: <htm:ul> + <htm:li>RFC 5280 certificate validation and certificate path validation.</htm:li> + <htm:li>The certificate path must terminate with a certificate in the Trust Anchor Database.</htm:li> + <htm:li>The TSF shall validate a certificate path by ensuring the presence of the basicConstraints extension, that the CA flag is set to TRUE for all CA certificates, and that any path constraints are met.</htm:li> + <htm:li>The TSF shall validate that any CA certificate includes caSigning purpose in the key usage field.</htm:li> + <htm:li>The TSF shall validate the revocation status of the certificate using <selectables> + <selectable>OCSP as specified in RFC 6960</selectable> + <selectable id="s-crl">CRL as specified in RFC 5759</selectable> + <selectable>an OCSP TLS Status Request Extension (OCSP stapling) as specified in RFC 6066</selectable> + <selectable>OCSP TLS Multi-Certificate Status Request Extension (i.e., OCSP Multi-Stapling) as specified in RFC 6961</selectable> + </selectables>.</htm:li> + <htm:li>The TSF shall validate the extendedKeyUsage field according to the following rules:<htm:ul> + <htm:li>Certificates used for trusted updates and executable code integrity verification shall have the Code Signing Purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field.</htm:li> + <htm:li>Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.</htm:li> + <htm:li>Server certificates presented for EST shall have the CMC Registration Authority (RA) purpose (id-kp-cmcRA with OID 1.3.6.1.5.5.7.3.28) in the extendedKeyUsage field. [conditional]</htm:li> + <htm:li>Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.</htm:li> + <htm:li>OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field. [conditional]</htm:li></htm:ul></htm:li> + </htm:ul> + + The TSF shall validate certificates in accordance with the following rules: <assignable>list of rules</assignable>. + + FIA_X509_EXT.1.1 lists the rules for validating certificates. The ST author must select whether revocation status is verified using OCSP or CRLs. OCSP stapling and OCSP multi-stapling only support TLS server certificate validation. If other certificate types are validated, either OCSP or CRL should be claimed. The , to which a MDF TOE must also conform, requires that certificates are used for EAP-TLS; this use requires that the extendedKeyUsage rules are verified. Certificates may optionally be used for trusted updates of system software and applications (FPT_TUD_EXT.2) and for integrity verification (FPT_TST_EXT.2(1)) and, if implemented, must be validated to contain the Code Signing purpose extendedKeyUsage. + While FIA_X509_EXT.1.1 requires that the TOE perform certain checks on the certificate presented by a TLS server, there are corresponding checks that the authentication server will have to perform on the certificate presented by the client; namely that the extendedKeyUsage field of the client certificate includes “Client Authentication” and that the key agreement bit (for the Diffie-Hellman ciphersuites) or the key encipherment bit (for RSA ciphersuites) be set. Certificates obtained for use by the TOE will have to conform to these requirements in order to be used in the enterprise. This check is required to support EAP-TLS for the . - The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension is present and the CA flag is set to TRUE. + The TSF shall only treat a certificate as a CA certificate if the + basicConstraints extension is present and the CA flag is set to TRUE. This requirement applies to certificates that are used and processed by the TSF and restricts the certificates that may be added to the Trust Anchor Database. - + The evaluator shall ensure the TSS describes where the check of validity of the certificates takes place. The evaluator ensures the TSS also provides a description of the certificate path validation algorithm. There are no guidance evaluation activities for this component. - - - The tests described must be performed in conjunction with the other Certificate Services evaluation activities, including the use cases in FIA_X509_EXT.2.1 and FIA_X509_EXT.3. The tests for the extendedKeyUsage rules are performed in conjunction with the uses that require those rules. The evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the self-signed Root CA. - - The evaluator shall demonstrate that validating a certificate without a valid certification path results in the function failing, for each of the following reasons, in turn:By establishing a certificate path in which one of the issuing certificates is not a CA certificate,By omitting the basicConstraints field in one of the issuing certificates,By setting the basicConstraints field in an issuing certificate to have CA=False,By omitting the CA signing bit of the key usage field in an issuing certificate, andBy setting the path length field of a valid CA field to a value strictly less than the certificate path. + The tests described must be performed in conjunction with the other Certificate Services evaluation activities, including the use cases in FIA_X509_EXT.2.1 and FIA_X509_EXT.3. The tests for the extendedKeyUsage rules are performed in conjunction with the uses that require those rules. The evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the self-signed Root CA. + + The evaluator shall demonstrate that validating a certificate without a valid certification path results in the function failing, for each of the following reasons, in turn: + By establishing a certificate path in which one of the issuing certificates is not a CA certificate, + By omitting the basicConstraints field in one of the issuing certificates, + By setting the basicConstraints field in an issuing certificate to have CA=False, + By omitting the CA signing bit of the key usage field in an issuing certificate, and + By setting the path length field of a valid CA field to a value strictly less than the certificate path. + The evaluator shall then establish a valid certificate path consisting of valid CA certificates, and demonstrate that the function succeeds. The evaluator shall then remove trust in one of the CA certificates, and show that the function fails. - - The evaluator shall demonstrate that validating an expired certificate results in the function failing. - + + The evaluator shall demonstrate that validating an expired certificate results in the function failing. + The evaluator shall test that the TOE can properly handle revoked certificates-conditional on whether CRL, OCSP, OSCP stapling, or OCSP multi-stapling is selected; if multiple methods are selected, then the following tests shall be performed for each method: The evaluator shall test revocation of the node certificate. The evaluator shall also test revocation of the intermediate CA certificate (i.e. the intermediate CA certificate should be revoked by the root CA). For the test of the WLAN use case, only pre-stored CRLs are used. If OCSP stapling per RFC 6066 is the only supported revocation method, this test is omitted. - The evaluator shall ensure that a valid certificate is used, and that the validation function succeeds. The evaluator then attempts the test with a certificate that has been revoked (for each method chosen in the selection) to ensure when the certificate is no longer valid that the validation function fails. + The evaluator shall ensure that a valid certificate is used, and that the validation function succeeds. The evaluator then attempts the test with a certificate that has been revoked (for each method chosen in the selection) to ensure when the certificate is no longer valid that the validation function fails. + - If any OCSP option is selected, the evaluator shall configure the OCSP server or use a man-in-the-middle tool to present a certificate that does not have the OCSP signing purpose and verify that validation of the OCSP response fails. If is selected, + If any OCSP option is selected, the evaluator shall configure the OCSP server or use a man-in-the-middle tool to present a certificate that does not have the OCSP signing purpose and verify that validation of the OCSP response fails. If is selected, the evaluator shall configure the CA to sign a CRL with a certificate that does not have the cRLsign key usage bit set, and verify that validation of the CRL fails. - - The evaluator shall modify any byte in the first eight bytes of the certificate and demonstrate that the certificate fails to validate (the certificate will fail to parse correctly). - - The evaluator shall modify any bit in the last byte of the signature algorithm of the certificate and demonstrate that the certificate fails to validate (the signature on the certificate will not validate). - - The evaluator shall modify any byte in the public key of the certificate and demonstrate that the certificate fails to validate (the signature on the certificate will not validate). + + The evaluator shall modify any byte in the first eight bytes of the certificate and demonstrate that the certificate fails to validate (the certificate will fail to parse correctly). + + The evaluator shall modify any bit in the last byte of the signature algorithm of the certificate and demonstrate that the certificate fails to validate (the signature on the certificate will not validate). + + The evaluator shall modify any byte in the public key of the certificate and demonstrate that the certificate fails to validate (the signature on the certificate will not validate). + + + + (Conditional on support for EC certificates as indicated in FCS_COP.1(3)). The evaluator shall establish a valid, trusted certificate chain consisting of an EC leaf certificate, an EC Intermediate CA certificate not designated as a trust anchor, and an EC certificate designated as a trusted anchor, where the elliptic curve parameters are specified as a named curve. The evaluator shall confirm that the TOE validates the certificate chain. + (Conditional on support for EC certificates as indicated in FCS_COP.1(3)). The evaluator shall replace the intermediate certificate in the certificate chain for Test 8a with a modified certificate, where the modified intermediate CA has a public key information field where the EC parameters uses an explicit format version of the Elliptic Curve parameters in the public key information field of the intermediate CA certificate from Test 8a, and the modified Intermediate CA certificate is signed by the trusted EC root CA, but having no other changes. The evaluator shall confirm the TOE treats the certificate as invalid. + - - Failure to validate X.509v3 certificate - Reason for failure of validation - + + Failure to validate X.509v3 certificate + Reason for failure of validation + - - + + defines the TSF’s usage of X.509 certificates and how it reacts to certificates with undetermined revocation status. The following actions could be considered for the management functions in FMT: - Configuring whether to allow or disallow establishment of a trusted channel if the TSF cannot establish a connection to determine the validity of a certificate. + + Configuring whether to allow or disallow establishment of a trusted channel if the TSF cannot establish a connection to determine the validity of a certificate. + + The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - Failure to establish connection to determine revocation status. - FIA_X509_EXT.1 X.509 Validation of Certificates + + Failure to establish connection to determine revocation status. + + + FIA_X509_EXT.1 X.509 Validation of Certificates FTP_ITC_EXT.1 Trusted Channel Communication + + - The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for [ <htm:i>mutually authenticated TLS as defined in the <xref to="pkg-tls"></xref>, HTTPS, <selectables><selectable id="fia_x509_ext.2.1_1" >IPsec in accordance with the <xref to="mod-vpnclient"></xref></selectable><selectable id="x509_dtls" >mutually authenticated DTLS as defined in the <xref to="pkg-tls"></xref></selectable><selectable id="fia_x509_ext.2.1_2" exclusive="yes" >no other protocol</selectable></selectables></htm:i> ] and<selectables><selectable id="x509_sys" >code signing for system software updates</selectable><selectable id="x509_apps" >code signing for mobile applications</selectable><selectable id="x509_sign" >code signing for integrity verification</selectable><selectable id="fia_x509_ext.2.1_4" ><assignable>other uses </assignable></selectable><selectable id="fia_x509_ext.2.1_5" exclusive="yes" >no additional uses</selectable></selectables>. + The TSF shall use X.509v3 certificates as defined by RFC 5280 to support + authentication for [<htm:i>mutually authenticated TLS as defined in the <xref to="pkg-tls"/>, HTTPS, <selectables> + <selectable>IPsec in accordance with the <xref to="mod-vpnclient"/></selectable> + <selectable id="x509_dtls">mutually authenticated DTLS as defined in the <xref to="pkg-tls"/></selectable> + <selectable exclusive="yes">no other protocol</selectable> + </selectables></htm:i>] and <selectables> + <selectable id="x509_sys">code signing for system software updates</selectable> + <selectable id="x509_apps">code signing for mobile applications</selectable> + <selectable id="x509_sign">code signing for integrity verification</selectable> + <selectable><assignable>other uses</assignable></selectable> + <selectable exclusive="yes">no additional uses</selectable> + </selectables>. + + + The TSF shall use X.509v3 certificates as defined by RFC 5280 to support + authentication for <assignable>trusted channel protocol</assignable> and <selectables> + <selectable>code signing for system software updates</selectable> + <selectable>code signing for mobile applications</selectable> + <selectable>code signing for integrity verification</selectable> + <selectable><assignable>other uses</assignable></selectable> + <selectable>no additional uses</selectable> + </selectables>. + + - The ST author’s first selection must match the selection of and . - Certificates may optionally be used for trusted updates of system software ( ) and mobile applications ( ) and for integrity verification ( and ). + + The ST author’s first selection must match the selection of and . + Certificates may optionally be used for trusted updates of system software () and mobile applications () and for integrity verification ( and ). - - If or is selected must be included in the ST. - If is selected must be included in the ST. - If is included in the ST, must be included in the selection. + + If or is selected must be included in the ST. + + + If is selected must be included in the ST. + + + If is included in the ST, must be included in the selection. - When the TSF cannot establish a connection to determine the revocation status of a certificate, the TSF shall<selectables><selectable id="s-revoke-admin" > <snip>allow the administrator to choose</snip> whether to accept the certificate in - these cases</selectable><selectable id="s-revoke-user" > <snip>allow the user to choose</snip> whether to accept the certificate in these - cases</selectable><selectable id="fia_x509_ext.2.2_1" >accept the certificate</selectable><selectable id="s-revoke-deny" >not accept the certificate</selectable></selectables>. + When the TSF cannot establish a connection to determine the revocation status of + a certificate, the TSF shall <selectables> + <selectable id="s-revoke-admin"><snip>allow the administrator to choose</snip> whether to accept the certificate in + these cases</selectable> + <selectable id="s-revoke-user"><snip>allow the user to choose</snip> whether to accept the certificate in these + cases</selectable> + <selectable>accept the certificate</selectable> + <selectable id="s-revoke-deny">not accept the certificate</selectable> + </selectables>. + + When the TSF cannot establish a connection to determine the revocation status of + a certificate, the TSF shall <assignable>list of acceptable actions</assignable>. + The TOE must not accept the certificate if it fails any of the other validation rules in FIA_X509_EXT.1. However, often a connection must be established to perform a verification of the revocation status of a certificate - @@ -3600,16 +7078,24 @@ The evaluator shall generate 10 private/public key pairs using the key generatio behavior in the event that such a connection cannot be established (for example, due to a network error). If the TOE has determined the certificate is valid according to all other rules in FIA_X509_EXT.1, the behavior indicated in the selection must determine - the validity. If or + the validity. If or the administrator-configured or user-configured option is selected, - the ST author must also select function in - FMT_SMF.1. s-revoke-adminmf-certValidity s-revoke-usermf-certValidity + the ST author must also select function in + FMT_SMF.1. + + s-revoke-admin + mf-certValidity + + + s-revoke-user + mf-certValidity + The TOE may behave differently depending on the trusted channel; for example, in the case of WLAN where connections are unlikely to be established, the TOE may accept the certificate even though certificates are not accepted for other channels. The ST author should select all applicable behaviors. - + The evaluator shall check the TSS to ensure that it describes how the TOE chooses which certificates to use, and any necessary instructions in the administrative guidance for configuring the operating environment so that the TOE can use the @@ -3621,7 +7107,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio action, then the evaluator shall ensure that the operational guidance contains instructions on how this configuration action is performed. - + The evaluator shall perform the following test for each trusted channel: The evaluator shall demonstrate that using a valid certificate that requires certificate validation checking to be performed in at least some part by @@ -3635,13 +7121,13 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - - - Failure to establish connection to determine revocation status - + + + Failure to establish connection to determine revocation status + - - + + requires the TSF to make a certificate validation service available to environmental components. There are no management activities foreseen. @@ -3649,17 +7135,18 @@ The evaluator shall generate 10 private/public key pairs using the key generatio FIA_X509_EXT.1 X.509 Validation of Certificates + - The TSF shall provide a certificate validation service to applications. + The TSF shall provide a certificate validation service to applications. - The TSF shall respond to the requesting application with the success or failure of the validation. + The TSF shall respond to the requesting application with the success or failure + of the validation. In order to comply with all of the rules in FIA_X509_EXT.1, multiple API calls may be required; all of these calls should be clearly documented - - The evaluator shall verify that the API documentation provided according to - includes the security function (certificate validation) + The evaluator shall verify that the API documentation provided according to + includes the security function (certificate validation) described in this requirement. This documentation shall be clear as to which results indicate success and failure. There are no TSS evaluation activities for this component. @@ -3672,77 +7159,103 @@ The evaluator shall generate 10 private/public key pairs using the key generatio by FDP_STG_EXT.1, FTP_ITC_EXT.1, FMT_SMF.1, and FIA_X509_EXT.1. - + - - + + requires the TSF to implement Enrollment over Secure Transport (EST) as a mechanism to obtain X.509 certificates. There are no management activities foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - Generation of Certificate Enrollment Request.Success or failure of enrollment.Update of EST Trust Anchor Database - FCS_CKM.1 Cryptographic Key Generation + + Generation of Certificate Enrollment Request. + Success or failure of enrollment. + Update of EST Trust Anchor Database + + + FCS_CKM.1 Cryptographic Key Generation FIA_X509_EXT.1 X.509 Validation of Certificates + - The TSF shall use the Enrollment over Secure Transport (EST) protocol as specified in RFC 7030 to request certificate enrollment using the simple enrollment method described in RFC 7030 Section 4.2. + The TSF shall use the Enrollment over Secure Transport (EST) protocol as + specified in RFC 7030 to request certificate enrollment using the simple enrollment + method described in RFC 7030 Section 4.2. - The TSF shall be capable of authenticating EST requests using an existing certificate and corresponding private key as specified by RFC 7030 Section 3.3.2. + The TSF shall be capable of authenticating EST requests using an existing + certificate and corresponding private key as specified by RFC 7030 Section + 3.3.2. - The TSF shall be capable of authenticating EST requests using HTTP Basic Authentication with a username and password as specified by RFC 7030 Section 3.2.3. + The TSF shall be capable of authenticating EST requests using HTTP Basic + Authentication with a username and password as specified by RFC 7030 Section + 3.2.3. - The TSF shall perform authentication of the EST server using an Explicit Trust Anchor following the rules described in RFC 7030, section 3.6.1. + The TSF shall perform authentication of the EST server using an Explicit Trust + Anchor following the rules described in RFC 7030, section 3.6.1. EST also uses HTTPS as specified in FCS_HTTPS_EXT.1 to establish a secure connection to an EST server. The separate Trust Anchor Database dedicated to EST operations is described as Explicit Trust Anchors in RFC 7030. - The TSF shall be capable of requesting server-provided private keys as specified in RFC 7030 Section 4.4. + The TSF shall be capable of requesting server-provided private keys as specified + in RFC 7030 Section 4.4. - The TSF shall be capable of updating its EST-specific Trust Anchor Database using the "Root CA Key Update" process described in RFC 7030 Section 4.1.3. + The TSF shall be capable of updating its EST-specific Trust Anchor Database using + the "Root CA Key Update" process described in RFC 7030 Section 4.1.3. - The TSF shall generate a Certificate Request Message for EST as specified in RFC 2986 and be able to provide the following information in the request: public key and<selectables><selectable id="fia_x509_ext.4.7_1" >device-specific information</selectable><selectable id="fia_x509_ext.4.7_2" >Common Name</selectable><selectable id="fia_x509_ext.4.7_3" >Organization</selectable><selectable id="fia_x509_ext.4.7_4" >Organizational Unit</selectable><selectable id="fia_x509_ext.4.7_5" >Country</selectable></selectables>. + The TSF shall generate a Certificate Request Message for EST as specified in RFC + 2986 and be able to provide the following information in the request: public key and <selectables> + <selectable>device-specific information</selectable> + <selectable>Common Name</selectable> + <selectable>Organization</selectable> + <selectable>Organizational Unit</selectable> + <selectable>Country</selectable> + </selectables>. The public key referenced is the public key portion of the public-private key pair generated by the TOE as specified in FCS_CKM.1. - The TSF shall validate the chain of certificates from the Root CA certificate in the Trust Anchor Database to the EST Server CA certificate upon receiving a CA Certificates Response. - + The TSF shall validate the chain of certificates from the Root CA certificate in + the Trust Anchor Database to the EST Server CA certificate upon receiving a CA + Certificates Response. + There are no TSS evaluation activities for this component. The evaluator shall check to ensure that the operational guidance contains instructions on requesting certificates from an EST server, including generating a Certificate Request Message. - + The evaluator shall also perform the following tests. Other tests are + performed in conjunction with the evaluation activity listed in the Package for + Transport Layer Security. The evaluator shall use the operational guidance to cause the TOE to request certificate enrollment from an EST server using the simple enrollment method described in RFC 7030 Section 4.2, authenticating the certificate request to the server using an existing certificate and private key as described by RFC 7030 Section 3.3.2. The evaluator shall confirm that the resulting certificate is - successfully obtained and installed in the TOE key store. + successfully obtained and installed in the TOE key store. The evaluator shall use the operational guidance to cause the TOE to request certificate enrollment from an EST server using the simple enrollment method described in RFC 7030 Section 4.2, authenticating the certificate request to the server using a username and password as described by RFC 7030 Section 3.2.3. The evaluator shall confirm that the resulting certificate is successfully obtained - and installed in the TOE key store. + and installed in the TOE key store. The evaluator shall modify the EST server to return a certificate containing a different public key than the key included in the TOE’s certificate request. The evaluator shall use the operational guidance to cause the TOE to request certificate enrollment from an EST server. The evaluator shall confirm that the TOE does not accept the resulting certificate since the public key in the issued - certificate does not match the public key in the certificate request. + certificate does not match the public key in the certificate request. The evaluator shall configure the EST server or use a man-in-the-middle tool to present a server certificate to the TOE that is present in the TOE general Trust Anchor Database but not its EST-specific Trust Anchor Database. The evaluator shall cause the TOE to request certificate enrollment from the EST - server. The evaluator shall verify that the request is not successful. + server. The evaluator shall verify that the request is not successful. The evaluator shall configure the EST server or use a man-in-the-middle tool to present an invalid certificate. The evaluator shall cause the TOE to request certificate enrollment from the EST server. The evaluator shall verify that the @@ -3750,34 +7263,34 @@ The evaluator shall generate 10 private/public key pairs using the key generatio man-in-the-middle tool to present a certificate that does not have the CMC RA purpose and verify that requests to the EST server fail. The tester shall repeat the test using a valid certificate and a certificate that contains the CMC RA - purpose and verify that the certificate enrollment requests succeed. + purpose and verify that the certificate enrollment requests succeed. The evaluator shall use a packet sniffing tool between the TOE and an EST server. The evaluator shall turn on the sniffing tool and cause the TOE to request certificate enrollment from an EST server. The evaluator shall verify that the EST protocol interaction occurs over a Transport Layer Security (TLS) protected connection. The evaluator is not expected to decrypt the connection - but rather observe that the packets conform to the TLS protocol format. + but rather observe that the packets conform to the TLS protocol format. The evaluator shall use the operational guidance to cause the TOE to request a server-provided private key and certificate from an EST server. The evaluator shall confirm that the resulting private key and certificate are successfully - obtained and installed in the TOE key store. + obtained and installed in the TOE key store. The evaluator shall modify the EST server to, in response to a server-provided private key and certificate request, return a private key that does not correspond with the public key in the returned certificate. The evaluator shall use the operational guidance to cause the TOE to request a server-provided private key and certificate. The evaluator shall confirm that the TOE does not accept the resulting private key and certificate since the - private key and public key do not correspond. + private key and public key do not correspond. The evaluator shall configure the EST server to provide a "Root CA Key Update" as described in RFC 7030 Section 4.1.3. The evaluator shall cause the TOE to request CA certificates from the EST server and shall confirm that the - EST-specific Trust Anchor Database is updated with the new trust anchor. + EST-specific Trust Anchor Database is updated with the new trust anchor. The evaluator shall configure the EST server to provide a "Root CA Key Update" as described in RFC 7030 Section 4.1.3, but shall modify part of the NewWithOld certificate’s generated signature. The evaluator shall cause the TOE to request CA certificates from the EST server and shall confirm that the EST-specific Trust Anchor Database is not updated with the new trust anchor - since the signature did not verify. + since the signature did not verify. The evaluator shall use the operational guidance to cause the TOE to generate a certificate request message. The evaluator shall capture the generated message and ensure that it conforms to the format specified by RFC @@ -3788,31 +7301,40 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - - Generation of Certificate Enrollment Request - Issuer and Subject name of EST Server. Method of authentication. Issuer and Subject name of certificate used to authenticate. Content of Certificate Request Message - - - Success or failure of enrollment - Issuer and Subject name of added certificate or reason for failure - - - Update of EST Trust Anchor Database - Subject name of added Root CA - + + Generation of Certificate Enrollment Request + Issuer and Subject name of EST Server. Method of authentication. Issuer and Subject name of certificate used to authenticate. Content of Certificate Request Message + + + + Success or failure of enrollment + Issuer and Subject name of added certificate or reason for failure + + + Update of EST Trust Anchor Database + Subject name of added Root CA + - - + + requires the TSF to generate X.509 certificate requests and validate the responses. There are no management activities foreseen. There are no auditable events foreseen. - FCS_CKM.1 Cryptographic Key Generation + FCS_CKM.1 Cryptographic Key Generation FIA_X509_EXT.1 X.509 Validation of Certificates + - The TSF shall generate a Certificate Request Message as specified in RFC 2986 and be able to provide the following information in the request: public key and<selectables><selectable id="fia_x509_ext.5.1_1" >device-specific information</selectable><selectable id="fia_x509_ext.5.1_2" >Common Name</selectable><selectable id="fia_x509_ext.5.1_3" >Organization</selectable><selectable id="fia_x509_ext.5.1_4" >Organizational Unit</selectable><selectable id="fia_x509_ext.5.1_5" >Country</selectable></selectables>. + The TSF shall generate a Certificate Request Message as specified in RFC 2986 and + be able to provide the following information in the request: public key and <selectables> + <selectable>device-specific information</selectable> + <selectable>Common Name</selectable> + <selectable>Organization</selectable> + <selectable>Organizational Unit</selectable> + <selectable>Country</selectable> + </selectables>. The public key referenced in FIA_X509_EXT.5.1 is the public key portion of the public-private key pair generated by the TOE as specified in FCS_CKM.1. The trusted channel requirements do not apply to communication with the CA for the @@ -3823,8 +7345,9 @@ The evaluator shall generate 10 private/public key pairs using the key generatio Certificate Request Messages but do not yet implement EST. - The TSF shall validate the chain of certificates from the Root CA upon receiving the CA Certificate Response. - + The TSF shall validate the chain of certificates from the Root CA upon receiving + the CA Certificate Response. + If the ST author selects "device-specific information", the evaluator shall verify that the TSS contains a description of the device-specific fields used in certificate requests. @@ -3833,15 +7356,12 @@ The evaluator shall generate 10 private/public key pairs using the key generatio "Common Name", "Organization", "Organizational Unit", or "Country", the evaluator shall ensure that this guidance includes instructions for establishing these fields before creating the certificate request message. - - - The evaluator shall also perform the following tests: - The + The evaluator shall also perform the following tests: The evaluator shall use the operational guidance to cause the TOE to generate a certificate request message. The evaluator shall capture the generated message and ensure that it conforms to the format specified. The evaluator shall confirm that the certificate request provides the public key and other required - information, including any necessary user-input information. + information, including any necessary user-input information. The evaluator shall demonstrate that validating a certificate response message without a valid certification path results in the function failing. The evaluator shall then load a certificate or certificates as trusted CAs needed to @@ -3852,26 +7372,37 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - + -
    - -
    - + + Both the user and the administrator may manage the TOE. This administrator is likely to be acting remotely and could be the Mobile Device Management (MDM) Administrator acting through an MDM Agent. - The Administrator is responsible for management activities, including setting the policy that is applied by the enterprise on the Mobile Device. These management functions are likely to be a different set than those management functions provided to the user. Management functions that are provided to the user and not the administrator are listed in FMT_MOF_EXT.1.1. Management functions for which the administrator may adopt a policy that restricts the user from performing that function are listed in FMT_MOF_EXT.1.2. compares the management functions required by this Protection Profile in the following three requirements (FMT_MOF_EXT.1.1, FMT_MOF_EXT.1.2, and FMT_SMF.1). + The Administrator is responsible for management activities, including setting the policy that is applied by the enterprise on the Mobile Device. These management functions are likely to be a different set than those management functions provided to the user. Management functions that are provided to the user and not the administrator are listed in FMT_MOF_EXT.1.1. Management functions for which the administrator may adopt a policy that restricts the user from performing that function are listed in FMT_MOF_EXT.1.2. + compares the management functions required by this Protection Profile in the following three requirements (FMT_MOF_EXT.1.1, FMT_MOF_EXT.1.2, and FMT_SMF.1). + + + This family defines requirements for authorization to manage the behavior of the TSF that are not addressed by FMT_MOF in CC Part 2. + + + - - requires the TSF to apply restrictions to access its management functions to the authorized roles. The following actions could be considered for the management functions in FMT: - Managing the group of roles that can interact with the functions in the TSF. + + Managing the group of roles that can interact with the functions in the TSF. + + There are no auditable events foreseen. FMT_SMF.1 Specification of Management Functions + + - The TSF shall restrict the ability to perform the functions [ <htm:i>in column 4 of - <xref to="fmt_smf"></xref></htm:i> ] to the user. + The TSF shall restrict the ability to perform the functions [<htm:i>in column 4 of + <xref to="fmt_smf"/></htm:i>] to the user. + + The TSF shall restrict the ability to perform the functions <assignable>reference to list of management functions</assignable> to the user. + The functions that have an "M" in the fourth column are mandatory for this component, thus are restricted to the user, meaning that the administrator cannot manage those functions. The functions that have an "O" in the @@ -3898,8 +7429,13 @@ The evaluator shall generate 10 private/public key pairs using the key generatio - The TSF shall restrict the ability to perform the functions [ <htm:i>in column 6 of - <xref to="fmt_smf"></xref></htm:i> ] to the administrator when the device is enrolled and according to the administrator-configured policy. + The TSF shall restrict the ability to perform the functions [<htm:i>in column 6 of + <xref to="fmt_smf"/></htm:i>] to the administrator when the device is enrolled and + according to the administrator-configured policy. + + The TSF shall restrict the ability to perform the functions <assignable>reference to list of management functions</assignable> to the administrator when the device is enrolled and + according to the administrator-configured policy. + As long as the device is enrolled in management, the administrator (of the enterprise) must be guaranteed that minimum security functions of the enterprise policy are enforced. Further restrictive policies can be applied at @@ -3932,7 +7468,7 @@ The evaluator shall generate 10 private/public key pairs using the key generatio The evaluator shall use the test environment to deploy policies to Mobile - Devices. + Devices. The evaluator shall create policies which collectively include all management functions which are controlled by the (enterprise) administrator and cannot be overridden/relaxed by the user as defined in FMT_MOF_EXT.1.2. The @@ -3940,47 +7476,129 @@ The evaluator shall generate 10 private/public key pairs using the key generatio setting both as the user (if a setting is available) and as an application (if an API is available), and ensure that the TSF does not permit it. Note that the user may still apply a more restrictive policy than that of the - administrator. + administrator. Additional testing of functions provided to the administrator are performed in conjunction with the testing activities for FMT_SMF.1.1. - + - - + + + This family defines requirements for security-relevant management functions that are not addressed by FMT_SMF in CC Part 2. + + + + + + - <!-- NOTE: There is currently no support for Management Function tables, so the following raw XML will be used in the XML Export --> <htm:br/> - The TSF shall be capable of performing the following management functions: <htm:br></htm:br><htm:br></htm:br><htm:b><ctr id="fmt_smf" ctr-type="Table">: Management Functions</ctr></htm:b><htm:br></htm:br><htm:br></htm:br> - Status Markers:<htm:br></htm:br> M - Mandatory<htm:br></htm:br> O - Optional/Objective<htm:br></htm:br><management-function-set default="O"><manager cid="I">Impl.</manager><manager cid="U">User Only</manager><manager cid="A">Admin</manager><manager cid="AO">Admin Only</manager><management-function id="mf-pwd"><text> configure password policy: - <htm:ul><htm:li>Minimum password length</htm:li><htm:li>Minimum password complexity</htm:li><htm:li>Maximum password lifetime</htm:li></htm:ul></text><M ref="I"></M><NA ref="U"></NA><M ref="A"></M><M ref="AO"></M><aactivity><TSS>The evaluator shall verify + <title>The TSF shall be capable of performing the following management functions: <htm:br/><htm:br/> + <htm:b><ctr id="fmt_smf" ctr-type="Table">: Management Functions</ctr></htm:b><htm:br/><htm:br/> + Status Markers:<htm:br/> M - Mandatory<htm:br/> O - Optional/Objective<htm:br/> + <!-- NOTE: management-function uses ctr variables crt-type=functions in the MOOO table, so that they do not + have to be renumbered when one is added or removed. However app notes and AAs need to be in the same order as the functions. + The list of IDs for each function is at the end of the xml.--> + <management-function-set default="O"> + <manager cid="I">Impl.</manager> + <manager cid="U">User Only</manager> + <manager cid="A">Admin</manager> + <manager cid="AO">Admin Only</manager> + <management-function id="mf-pwd"> + <text> + <!-- <ctr id="pwd" pre="" ctr-type="function">.</ctr>--> configure password policy: + <htm:ul> + <htm:li>Minimum password length</htm:li> + <htm:li>Minimum password complexity</htm:li> + <htm:li>Maximum password lifetime</htm:li> + </htm:ul> + </text> + <M ref="I"/> <NA ref="U"/><M ref="A"/><M ref="AO"/> + <aactivity> + <TSS>The evaluator shall verify the TSS defines the allowable policy options: the range of values for both password length and lifetime, and a description of complexity to include character set and complexity policies (e.g., configuration and enforcement of number of - uppercase, lowercase, and special characters per password).</TSS><Tests> + uppercase, lowercase, and special characters per password).</TSS> + <Tests> The evaluator shall exercise the TSF configuration as the administrator and perform positive and negative tests, with at least two values set for each - variable setting, for each of the following: <htm:br></htm:br><htm:ul><htm:li>Minimum password length</htm:li><htm:li>Minimum password complexity</htm:li><htm:li>Maximum password lifetime</htm:li></htm:ul></Tests></aactivity></management-function><management-function id="mf-screenlock"><text> configure session - locking policy: <htm:ul><htm:li>Screen-lock enabled/disabled</htm:li><htm:li>Screen lock timeout </htm:li><htm:li>Number of authentication failures</htm:li></htm:ul></text><M ref="I"></M><NA ref="U"></NA><M ref="A"></M><M ref="AO"></M><aactivity><TSS>The evaluator shall + variable setting, for each of the following: <htm:br/> + <htm:ul> + <htm:li>Minimum password length</htm:li> + <htm:li>Minimum password complexity</htm:li> + <htm:li>Maximum password lifetime</htm:li> + </htm:ul> + </Tests> + </aactivity> + + </management-function> + <management-function id="mf-screenlock"> + <text> + <!-- <ctr id="screenlock" pre="" ctr-type="function">.</ctr>--> configure session + locking policy: <htm:ul> + <htm:li>Screen-lock enabled/disabled</htm:li> + <htm:li>Screen lock timeout </htm:li> + <htm:li>Number of authentication failures</htm:li> + </htm:ul> + </text> + <M ref="I"/><NA ref="U"/><M ref="A"/><M ref="AO"/> + <aactivity> + <TSS>The evaluator shall verify the TSS defines the range of values for both timeout period and number of - authentication failures for all supported authentication mechanisms.</TSS><Tests> The evaluator shall exercise the TSF configuration as the administrator. + authentication failures for all supported authentication mechanisms.</TSS> + <Tests> The evaluator shall exercise the TSF configuration as the administrator. The evaluator shall perform positive and negative tests, with at least two - values set for each variable setting, for each of the following: <htm:br></htm:br><htm:ul><htm:li>Screen-lock enabled/disabled</htm:li><htm:li>Screen lock timeout</htm:li><htm:li>Number of authentication failures (may be combined with test for - FIA_AFL_EXT.1)</htm:li></htm:ul></Tests></aactivity></management-function><management-function id="mf-vpn"><text> enable/disable the VPN - protection: <htm:ul><htm:li>Across device</htm:li></htm:ul><htm:div class="indent"><selectables linebreak="yes"><selectable id="s-vpn-per-app">on a per-app basis</selectable><selectable id="s-vpn-per-appgroup">on a per-group of applications processes basis</selectable><selectable exclusive="yes">no other method</selectable></selectables></htm:div></text><M ref="I"></M><app-note><also ref-id="mf-audioVisual"></also><also ref-id="mf-location"></also> - Functions <_></_> must be implemented on a device-wide basis but may also be + values set for each variable setting, for each of the following: <htm:br/> + <htm:ul> + <htm:li>Screen-lock enabled/disabled</htm:li> + <htm:li>Screen lock timeout</htm:li> + <htm:li>Number of authentication failures (may be combined with test for + FIA_AFL_EXT.1)</htm:li> + </htm:ul> + </Tests> + </aactivity> + </management-function> + <management-function id="mf-vpn"> + <text> + <!-- <ctr id="vpn" pre="" ctr-type="function">.</ctr>--> enable/disable the VPN + protection: <htm:ul> + <htm:li>Across device</htm:li></htm:ul> + <htm:div class="indent"> + <selectables linebreak="yes"> + <selectable id="s-vpn-per-app">on a per-app basis</selectable> + <selectable id="s-vpn-per-appgroup">on a per-group of applications processes basis</selectable> + <selectable exclusive="yes">no other method</selectable> + </selectables></htm:div> + </text> + <M ref="I"/> + <app-note><also ref-id="mf-audioVisual"/><also ref-id="mf-location"/> + Functions <_/> must be implemented on a device-wide basis but may also be implemented on a per-app basis or on a per-group of applications basis in which the configuration includes the list of applications or groups of applications to which the - enable/disable applies.</app-note><app-note> - Function <_></_> addresses + enable/disable applies.</app-note> + <app-note> + Function <_/> addresses enabling and disabling the IPsec VPN only. The configuration of the VPN Client itself (with information such as VPN Gateway, certificates, and algorithms) is addressed by - the <xref to="mod-vpnclient"></xref>. The administrator options should only be listed if the + the <xref to="mod-vpnclient"/>. The administrator options should only be listed if the administrator can remotely enable/disable the VPN connection. <htm:p> - Function <xref to="mf-vpn"></xref> optionally allows the VPN to be configured per-app or + Function <xref to="mf-vpn"/> optionally allows the VPN to be configured per-app or per-groups of apps. If this configuration is selected, it does not void FDP_IFC_EXT.1. Instead FDP_IFC_EXT.1 is applied to the application or group of applications the VPN is applied to. In other words, all traffic destined for the VPN-enabled application or @@ -3988,18 +7606,24 @@ The evaluator shall exercise the TSF configuration as the administrator and application or group of applications can travel outside the VPN. When the VPN is configured across the device FDP_IFC_EXT.1 applies to all traffic and the VPN must not split tunnel. - </htm:p></app-note><aactivity><Tests> + </htm:p> + </app-note> + <aactivity> + <Tests> The evaluator shall perform the following tests: - <testlist><test>The evaluator shall exercise the TSF configuration to enable the VPN + <testlist> + <test>The evaluator shall exercise the TSF configuration to enable the VPN protection. These configuration actions must be used for the testing of the - FDP_IFC_EXT.1.1 requirement. </test><test>[conditional] If "<xref to="s-vpn-per-app"></xref>" is selected, the evaluator shall + FDP_IFC_EXT.1.1 requirement. </test> + <test>[conditional] If "<xref to="s-vpn-per-app"/>" is selected, the evaluator shall create two applications and enable one to use the VPN and the other to not use the VPN. The evaluator shall exercise each application (attempting to access network resources; for example, by browsing different websites) individually while capturing packets from the TOE. The evaluator shall verify from the packet capture that the traffic from the VPN-enabled application is encapsulated in IPsec and that the traffic from the - VPN-disabled application is not encapsulated in IPsec. </test><test>[conditional] If "<xref to="s-vpn-per-appgroup"></xref>" is selected, the + VPN-disabled application is not encapsulated in IPsec. </test> + <test>[conditional] If "<xref to="s-vpn-per-appgroup"/>" is selected, the evaluator shall create two applications and the applications shall be placed into different groups. Enable one application group to use the VPN and the other to not use the VPN. The evaluator shall exercise each application @@ -4008,9 +7632,18 @@ The evaluator shall exercise the TSF configuration as the administrator and shall verify from the packet capture that the traffic from the application in the VPN-enabled group is encapsulated in IPsec and that the traffic from the application in the VPN-disabled group is not encapsulated in IPsec. - </test></testlist></Tests></aactivity></management-function><management-function id="mf-radios"><text> enable/disable - <assignable id="a-mf-radios">list of all radios</assignable></text><M ref="I"></M><app-note> - The assignment in function <_></_> + </test> + </testlist> + </Tests> + </aactivity> + </management-function> + <management-function id="mf-radios"> + <text> + <!-- <ctr id="radios" pre="" ctr-type="function">.</ctr>--> enable/disable + <assignable id="a-mf-radios">list of all radios</assignable></text> + <M ref="I"/> + <app-note> + The assignment in function <_/> consists of all radios present on the TSF, such as Wi-Fi, cellular, NFC, Bluetooth BR/EDR, and Bluetooth LE, which can be enabled and disabled. In the future, @@ -4019,7 +7652,8 @@ The evaluator shall exercise the TSF configuration as the administrator and the radio may not be enabled in order to place emergency phone calls; however, it is not expected that a device in "airplane mode", where all radios are disabled, will automatically (without authorization) turn on the cellular radio to place emergency - calls.</app-note><aactivity><TSS> + calls.</app-note> + <aactivity><TSS> The evaluator shall verify that the TSS includes a description of each radio and an indication of if the radio can be enabled/disabled along with what role can do so. In addition the @@ -4029,30 +7663,32 @@ The evaluator shall exercise the TSF configuration as the administrator and as part of the initialization of the device. </TSS><Guidance> The evaluator shall confirm that the AGD guidance describes - how to perform the enable/disable function for each radio.<htm:br></htm:br><htm:br></htm:br></Guidance><Tests> + how to perform the enable/disable function for each radio.<htm:br/><htm:br/> + </Guidance> + <Tests> The evaluator shall ensure that minimal signal leakage enters the RF shielded enclosure (i.e. Faraday bag, Faraday box, RF shielded room) by performing the - following steps:<htm:br></htm:br><htm:br></htm:br> Step 1: Place the antenna of the spectrum - analyzer inside the RF shielded enclosure.<htm:br></htm:br><htm:br></htm:br> Step 2: Enable "Max + following steps:<htm:br/><htm:br/> Step 1: Place the antenna of the spectrum + analyzer inside the RF shielded enclosure.<htm:br/><htm:br/> Step 2: Enable "Max Hold" on the spectrum analyzer and perform a spectrum sweep of the frequency range between 300 MHz – 6000 MHz, in I kHz steps (this range should encompass 802.11, 802.15, GSM, UMTS, and LTE). This range will not address NFC 13.56.MHz, another - test should be set up with similar constraints to address NFC.<htm:br></htm:br><htm:br></htm:br> + test should be set up with similar constraints to address NFC.<htm:br/><htm:br/> If power above -90 dBm is observed, the Faraday box has too great of signal leakage and shall not be used to complete the test for - Function <xref to="mf-radios"></xref>. + Function <xref to="mf-radios"/>. The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to the administrator, the user, to enable and disable the state of each radio (e.g. Wi-Fi, cellular, NFC, Bluetooth). Additionally, the evaluator shall repeat the steps below, booting into any auxiliary boot mode - supported by the device. For each radio, the evaluator shall:<htm:br></htm:br><htm:br></htm:br> + supported by the device. For each radio, the evaluator shall:<htm:br/><htm:br/> Step 1: Place the antenna of the spectrum analyzer inside the RF shielded enclosure. Configure the spectrum analyzer to sweep desired frequency range for the radio to be tested (based on range provided in the TSS)). The ambient noise floor shall be set to -110 dBm. Place the TOE into the RF shielded enclosure to - isolate them from all other RF traffic. <htm:br></htm:br><htm:br></htm:br> Step 2: The evaluator + isolate them from all other RF traffic. <htm:br/><htm:br/> Step 2: The evaluator shall create a baseline of the expected behavior of RF signals. The evaluator shall power on the device, ensure the radio in question is enabled, power off the device, enable "Max Hold" on the spectrum analyzer and power on the device. @@ -4060,7 +7696,7 @@ The evaluator shall exercise the TSF configuration as the administrator and to entering the necessary password to complete the boot process, waiting 5 minutes after the device is fully booted. The evaluator shall observe that RF spikes are present at the expected uplink channel frequency. The evaluator shall - clear the "Max Hold" on the spectrum analyzer. <htm:br></htm:br><htm:br></htm:br> Step 3: The + clear the "Max Hold" on the spectrum analyzer. <htm:br/><htm:br/> Step 3: The evaluator shall verify the absence of RF activity for the uplink channel when the radio in question is disabled. The evaluator shall complete the following test five times. The evaluator shall power on the device, ensure the radio in @@ -4074,8 +7710,21 @@ The evaluator shall exercise the TSF configuration as the administrator and RF activity for the uplink channel of the specific radio frequency band is observed after the device is fully booted or at an Authentication Factor interface it is deemed that the radio is enabled. - </Tests></aactivity></management-function><management-function id="mf-audioVisual"><text> enable/disable - <assignable id="a-audiovisual-devs">list of audio or visual collection devices</assignable>: <htm:ul><htm:li>Across device</htm:li></htm:ul><htm:div class="indent"><selectables linebreak="yes"><selectable id="s-audiovisual-per-app">on a per-app basis</selectable><selectable id="s-audiovisual-per-appgroup">on a per-group of applications processes basis</selectable><selectable exclusive="yes">no other method</selectable></selectables></htm:div></text><M ref="I"></M><app-note>The assignment in function <_></_> + </Tests></aactivity> + </management-function> + <management-function id="mf-audioVisual"> + <text> + <!-- <ctr id="audioVisual" pre="" ctr-type="function">.</ctr>--> enable/disable + <assignable id="a-audiovisual-devs">list of audio or visual collection devices</assignable>: <htm:ul> + <htm:li>Across device</htm:li></htm:ul> + <htm:div class="indent"><selectables linebreak="yes"> + <selectable id="s-audiovisual-per-app">on a per-app basis</selectable> + <selectable id="s-audiovisual-per-appgroup">on a per-group of applications processes basis</selectable> + <selectable exclusive="yes">no other method</selectable> + </selectables></htm:div> + </text> + <M ref="I"/> + <app-note>The assignment in function <_/> consists of at least one audio or visual device, such as camera and microphone, which can be enabled and disabled by either the user or administrator. Disablement of the microphone does not imply that the microphone may not be enabled in order to place @@ -4084,7 +7733,7 @@ The evaluator shall exercise the TSF configuration as the administrator and restricted to users, then this function should be iterated in the table with the appropriate table entries. <htm:p> - Regarding functions <xref to="mf-radios"></xref> and <xref to="mf-audioVisual"></xref>, + Regarding functions <xref to="mf-radios"/> and <xref to="mf-audioVisual"/>, disablement of a particular radio or audio/visual device must be effective as soon as the TOE has power. Disablement must also apply when the TOE is booted into auxiliary boot modes, for @@ -4094,14 +7743,18 @@ The evaluator shall exercise the TSF configuration as the administrator and are disabled by default while in these states. That these devices are disabled during auxiliary boot modes does not imply that the device (particularly the cellular radio) may not be enabled in order to perform emergency phone calls. - </htm:p></app-note><aactivity><TSS> + </htm:p> + </app-note> + <aactivity><TSS> The evaluator shall verify that the TSS includes a description of each collection device and an indication of if it can be enabled/disabled along with what role can do so. The evaluator shall confirm that the AGD guidance describes how to perform the enable/disable function. - </TSS><Tests>The evaluator shall perform the following tests: - <testlist><test>The evaluator shall exercise the TSF configuration as the + </TSS> + <Tests>The evaluator shall perform the following tests: + <testlist> + <test>The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to the administrator, the user, to enable and disable the state of each audio or visual collection devices (e.g. camera, microphone) listed by the ST author. For each collection @@ -4109,111 +7762,223 @@ The evaluator shall exercise the TSF configuration as the administrator and functionality. The evaluator shall reboot the TOE and verify that disabled collection devices may not be used during or early in the boot process. Additionally, the evaluator shall boot the device into each available - auxiliary boot mode and verify that the collection device cannot be used. </test><test>[conditional] If "<xref to="s-audiovisual-per-app"></xref>" is selected, the evaluator shall + auxiliary boot mode and verify that the collection device cannot be used. </test> + <test>[conditional] If "<xref to="s-audiovisual-per-app"/>" is selected, the evaluator shall create two applications and enable one to use access the A/V device and the other to not access the A/V device. The evaluator shall exercise each application attempting to access the A/V device individually. The evaluator shall verify that the enabled application is able to access the A/V device - and the disabled application is not able to access the A/V device. </test><test>[conditional] If "<xref to="s-audiovisual-per-appgroup"></xref>" is selected, the + and the disabled application is not able to access the A/V device. </test> + <test>[conditional] If "<xref to="s-audiovisual-per-appgroup"/>" is selected, the evaluator shall create two applications and the applications shall be placed into different groups. Enable one group to access the A/V device and the other to not access the A/V device. The evaluator shall exercise each application attempting to access the A/V device individually. The evaluator shall verify that the application in the enabled group is able to access the A/V device and the application in the disabled group is not able to access - the A/V device. </test></testlist></Tests></aactivity></management-function><management-function id="mf-lockState"><text> transition to the locked - state </text><M ref="I"></M><NA ref="U"></NA><M ref="A"></M><NA ref="AO"></NA><aactivity><Tests> + the A/V device. </test> + </testlist> + </Tests> + </aactivity> + </management-function> + <management-function id="mf-lockState"> + <text> + <!-- 6. --> + <!-- <ctr id="lockState" pre="" ctr-type="function">.</ctr>--> transition to the locked + state </text> + <M ref="I"/><NA ref="U"/><M ref="A"/><NA ref="AO"/> + <aactivity><Tests> The evaluator shall use the test environment to instruct the TSF, both as a user and as the administrator, to command the device to transition to a locked state, and verify that the device transitions to the locked state upon command. - </Tests></aactivity></management-function><management-function id="mf-wipe"><text> TSF wipe of protected data </text><M ref="I"></M><NA ref="U"></NA><M ref="A"></M><NA ref="AO"></NA><app-note> - Wipe of the TSF (function <xref to="mf-wipe"></xref>) is performed according to + </Tests></aactivity> + </management-function> + <management-function id="mf-wipe"> + <text> + <!-- 7. --> + <!-- <ctr id="wipe" pre="" ctr-type="function">.</ctr>--> TSF wipe of protected data </text> + <M ref="I"/> + <NA ref="U"/> + <M ref="A"/> + <NA ref="AO"/> + <app-note> + Wipe of the TSF (function <xref to="mf-wipe"/>) is performed according to FCS_CKM_EXT.5. Protected data is all non-TSF data, including all user or enterprise data. Some or all - of this data may be considered sensitive data as well.</app-note><aactivity><Tests>The evaluator shall use the test environment to instruct the TSF, both as a user and as the administrator, to command the device to perform a wipe of protected data. - The evaluator must ensure that this management setup is used when conducting the Evaluation Activities in FCS_CKM_EXT.5.</Tests></aactivity></management-function><management-function id="mf-appInstallRules"><text> configure - application installation policy by <htm:div class="indent"><selectables linebreak="yes"><selectable id="mf-appInstallRules-restrict">restricting the sources of applications</selectable><selectable id="mf-appInstallRules-specify">specifying a set of allowed applications based on - <assignable>application characteristics</assignable> (an <snip>application allowlist</snip>)</selectable><selectable id="mf-appInstallRules-deny">denying installation of applications</selectable></selectables></htm:div></text><M ref="I"></M><NA ref="U"></NA><M ref="A"></M><M ref="AO"></M><app-note> + of this data may be considered sensitive data as well.</app-note> + <aactivity> + <Tests>The evaluator shall use the test environment to instruct the TSF, both as a user and as the administrator, to command the device to perform a wipe of protected data. + The evaluator must ensure that this management setup is used when conducting the Evaluation Activities in FCS_CKM_EXT.5.</Tests> + </aactivity> + </management-function> + <management-function id="mf-appInstallRules"> + <text> + <!--8. --> + <!-- <ctr id="appInstallRules" pre="" ctr-type="function">.</ctr>--> configure + application installation policy by <htm:div class="indent"><selectables linebreak="yes"> + <selectable id="mf-appInstallRules-restrict">restricting the sources of applications</selectable> + <selectable id="mf-appInstallRules-specify">specifying a set of allowed applications based on + <assignable>application characteristics</assignable> (an <snip>application allowlist</snip>)</selectable> + <selectable id="mf-appInstallRules-deny">denying installation of applications</selectable> + </selectables></htm:div> + </text> + <M ref="I"/><NA ref="U"/><M ref="A"/><M ref="AO"/> + <app-note> The - selection in function <xref to="mf-appInstallRules"></xref> allows the ST author to + selection in function <xref to="mf-appInstallRules"/> allows the ST author to select which mechanisms are available to the administrator through the MDM Agent to restrict the applications which the user may install. The ST author must state if application allowlist is applied device-wide or if it can be specified to apply to - either the Enterprise or Personal applications. <htm:ul><htm:li>If the administrator can restrict the sources from which applications can be - installed, the ST author selects "<xref to="mf-appInstallRules-restrict"></xref>". </htm:li><htm:li>If the administrator can specify a allowlist of allowed applications, the ST - author selects "<xref to="mf-appInstallRules-specify"></xref>". The ST author should list any application characteristics + either the Enterprise or Personal applications. <htm:ul> + <htm:li>If the administrator can restrict the sources from which applications can be + installed, the ST author selects "<xref to="mf-appInstallRules-restrict"/>". </htm:li> + <htm:li>If the administrator can specify a allowlist of allowed applications, the ST + author selects "<xref to="mf-appInstallRules-specify"/>". The ST author should list any application characteristics (e.g. name, version, or developer) based on which the allowlist can be - formed.</htm:li><htm:li>If the administrator can prevent the user from installing additional - applications, the ST author selects "<xref to="mf-appInstallRules-deny"></xref>". </htm:li></htm:ul></app-note><aactivity><TSS> + formed.</htm:li> + <htm:li>If the administrator can prevent the user from installing additional + applications, the ST author selects "<xref to="mf-appInstallRules-deny"/>". </htm:li> + </htm:ul> + </app-note> + <aactivity><TSS> The evaluator shall verify the TSS describes the allowable application installation policy options based on the selection included in the ST. - If the <xref to="mf-appInstallRules-specify"></xref> is selected, + If the <xref to="mf-appInstallRules-specify"/> is selected, the evaluator shall verify that the TSS includes a description of each application characteristic upon which the allowlist may be based. - </TSS><Tests> The evaluator shall exercise the TSF configuration as the administrator to + </TSS> + <Tests> The evaluator shall exercise the TSF configuration as the administrator to restrict particular applications, sources of applications, or application installation according to the AGD guidance. The evaluator shall attempt to install unauthorized applications and ensure that this is not possible. The evaluator shall, in conjunction, perform the following specific tests: - <testlist><test>[conditional] The evaluator shall attempt to connect to an - unauthorized repository in order to install applications. </test><test>[conditional] The evaluator shall attempt to install two applications + <testlist> + <test>[conditional] The evaluator shall attempt to connect to an + unauthorized repository in order to install applications. </test> + <test>[conditional] The evaluator shall attempt to install two applications (one allowlisted, and one not) from a known allowed repository and verify that the application not on the allowlist is rejected. The evaluator shall also attempt to side-load executables or installation packages via USB connections to determine that the white list is still adhered to - </test></testlist></Tests></aactivity></management-function><management-function id="mf-keyStorage"><text> import keys or secrets into - the secure key storage </text><M ref="I"></M><NA ref="AO"></NA><aactivity><also ref-id="mf-keyWipe"></also><TSS>The evaluator shall verify that the TSS + </test> + </testlist> + </Tests> + </aactivity> + </management-function> + <management-function id="mf-keyStorage"> + <text> + <!-- 9. --> + <!-- <ctr id="keyStorage" pre="" ctr-type="function">.</ctr>--> import keys or secrets into + the secure key storage </text> + <M ref="I"/><NA ref="AO"/> + <aactivity><also ref-id="mf-keyWipe"/> + <TSS>The evaluator shall verify that the TSS describes each category of keys or secrets that can be imported into the TSF’s secure - key storage.</TSS><Tests> + key storage.</TSS> + <Tests> The test of these functions is performed in association with FCS_STG_EXT.1. - </Tests></aactivity></management-function><management-function id="mf-keyWipe"><text> destroy imported - keys or secrets and <selectables><selectable exclusive="yes">no other keys or secrets</selectable><selectable><assignable>list of other categories of - keys or secrets</assignable></selectable></selectables> in the secure key storage </text><M ref="I"></M><NA ref="AO"></NA></management-function><management-function id="mf-certImport"><text> import X.509v3 - certificates into the Trust Anchor Database </text><M ref="I"></M><NA ref="U"></NA><M ref="A"></M><aactivity><Guidance>The evaluator shall + </Tests> + </aactivity> + </management-function> + <management-function id="mf-keyWipe"> + <text> + <!-- 10. --> + <!-- <ctr id="keyWipe" pre="" ctr-type="function">.</ctr>--> destroy imported + keys or secrets and <selectables> + <selectable exclusive="yes">no other keys or secrets</selectable> + <selectable><assignable>list of other categories of + keys or secrets</assignable></selectable> + </selectables> in the secure key storage </text> + <M ref="I"/><NA ref="AO"/> + </management-function> + <management-function id="mf-certImport"> + <text> + <!-- 11. --> + <!-- <ctr id="certImport" pre="" ctr-type="function">.</ctr>--> import X.509v3 + certificates into the Trust Anchor Database </text> + <M ref="I"/><NA ref="U"/><M ref="A"/> + <aactivity> + <Guidance>The evaluator shall review the AGD guidance to determine that it describes the steps needed to import, modify, or remove certificates in the Trust Anchor database, and that the users that have authority to import those certificates (e.g., only administrator, or both administrators and users) are identified. - </Guidance><Tests> + </Guidance> + <Tests> The evaluator shall import certificates according to the AGD guidance as the user or as the administrator, as determined by the administrative guidance. The evaluator shall verify that no errors occur during import. The evaluator should perform an action requiring use of the X.509v3 certificate to provide assurance that installation was completed properly. - </Tests></aactivity></management-function><management-function id="mf-certWipe"><text> remove imported X.509v3 - certificates and <selectables><selectable exclusive="yes">no other X.509v3 certificates</selectable><selectable><assignable>list of other categories of X.509v3 - certificates</assignable></selectable></selectables> in the Trust Anchor Database </text><M ref="I"></M><NA ref="AO"></NA><app-note> - In the future, function <xref to="mf-certWipe"></xref> may require + </Tests> + </aactivity> + </management-function> + <management-function id="mf-certWipe"> + <text> + <!-- 12. --> + <!-- <ctr id="certWipe" pre="" ctr-type="function">.</ctr>--> remove imported X.509v3 + certificates and <selectables> + <selectable exclusive="yes">no other X.509v3 certificates</selectable> + <selectable><assignable>list of other categories of X.509v3 + certificates</assignable></selectable> + </selectables> in the Trust Anchor Database </text> + <M ref="I"/><NA ref="AO"/> + <app-note> + In the future, function <xref to="mf-certWipe"/> may require destruction or disabling of any default trusted CA certificates, excepting those CA certificates necessary for continued operation of the TSF, such as the developer’s certificate. At this time, the ST author must indicate in the assignment whether pre-installed or any other category of X.509v3 certificates may be removed from the Trust Anchor Database. - </app-note><aactivity><TSS> + </app-note> + <aactivity> + <TSS> The evaluator shall verify that the TSS describes each additional category of X.509 certificates and their use within the TSF. - </TSS><Tests> + </TSS> + <Tests> The evaluator shall remove an administrator-imported certificate and any - other categories of certificates included in the assignment of function <xref to="mf-appRemove"></xref> from the Trust Anchor Database according to the AGD + other categories of certificates included in the assignment of function <xref + to="mf-appRemove"/> from the Trust Anchor Database according to the AGD guidance as the user and as the administrator. - </Tests></aactivity></management-function><management-function id="mf-enroll"><text> enroll the TOE in management </text><M ref="I"></M><O ref="U"></O><O ref="A"></O><O ref="AO"></O><app-note> - For function <xref to="mf-enroll"></xref>, the + </Tests> + </aactivity> + + </management-function> + <management-function id="mf-enroll"> + <text> + <!-- 13. --> + <!-- <ctr id="enroll" pre="" ctr-type="function">.</ctr>--> enroll the TOE in management </text> + <M ref="I"/><O ref="U"/><O ref="A"/><O ref="AO"/> + <app-note> + For function <xref to="mf-enroll"/>, the enrollment function may be installing an MDM agent and includes the policies to be applied to the device. It is acceptable for the user approval notice to require the user to intentionally opt to view the policies (for example, by "tapping" on a "View" icon) rather than listing the policies in full in the notice. - </app-note><aactivity><TSS>The evaluator shall + </app-note> + <aactivity> + <TSS>The evaluator shall examine the TSS to ensure that it contains a description of each management function that will be enforced by the enterprise once the device is enrolled. The evaluator shall examine the AGD guidance to determine that this same information is present. - </TSS><Tests> + </TSS> + <Tests> The evaluator shall verify that user approval is required to enroll the device into management. - </Tests></aactivity></management-function><management-function id="mf-appRemove"><text> remove applications </text><M ref="I"></M><NA ref="U"></NA><M ref="A"></M><aactivity><TSS> + </Tests> + </aactivity> + </management-function> + <management-function id="mf-appRemove"> + <text> + <!-- 14. --> + <!-- <ctr id="appRemove" pre="" ctr-type="function">.</ctr>--> remove applications </text> + <M ref="I"/><NA ref="U"/><M ref="A"/> + <aactivity><TSS> The evaluator shall verify that the TSS includes an indication of what applications (e.g., user-installed applications, Administrator-installed applications, or Enterprise @@ -4229,8 +7994,15 @@ The evaluator shall exercise the TSF configuration as the administrator and </TSS><Tests> The evaluator shall attempt to remove applications according to the AGD guidance and verify that the TOE no longer permits users to access those - applications or their associated data.</Tests></aactivity></management-function><management-function id="mf-update"><text> update system software </text><M ref="I"></M><NA ref="U"></NA><M ref="A"></M><app-note> - For function <xref to="mf-update"></xref>, the administrator capability to update the system + applications or their associated data.</Tests></aactivity> + </management-function> + <management-function id="mf-update"> + <text> + <!-- 15 --> + <!-- <ctr id="update" pre="" ctr-type="function">.</ctr>--> update system software </text> + <M ref="I"/><NA ref="U"/><M ref="A"/> + <app-note> + For function <xref to="mf-update"/>, the administrator capability to update the system software may be limited to causing a prompt to the user to update rather than the ability to initiate the update itself. As the administrator is likely to be acting remotely, he/she would be unaware of inopportune situations, such as low power, which @@ -4238,108 +8010,212 @@ The evaluator shall exercise the TSF configuration as the administrator and to accept the update in such situations. It is expected that system architects will be cognizant of this limitation and will enforce network access controls in order to enforce enterprise-critical updates. - </app-note><aactivity><Tests>The evaluator shall attempt to update the TSF system software following the + </app-note> + <aactivity><Tests>The evaluator shall attempt to update the TSF system software following the procedures in the AGD guidance and verify that updates correctly install and that the version numbers of the system software increase. - </Tests></aactivity></management-function><management-function id="mf-appInstall"><text> install applications </text><M ref="I"></M><NA ref="U"></NA><M ref="A"></M><app-note> - Function <xref to="mf-appInstall"></xref> addresses both installation and update. This protection profile + </Tests></aactivity> + </management-function> + <management-function id="mf-appInstall"> + <text> + <!-- 16. --> + <!-- <ctr id="appInstall" pre="" ctr-type="function">.</ctr>--> install applications </text> + <M ref="I"/><NA ref="U"/><M ref="A"/> + <app-note> + Function <xref + to="mf-appInstall"/> addresses both installation and update. This protection profile does not distinguish between installation and update of applications because mobile devices typically completely overwrite the previous installation with a new installation during an application update. - </app-note><aactivity><Tests>The evaluator shall attempt to install an application following the + </app-note> + <aactivity><Tests>The evaluator shall attempt to install an application following the procedures in the AGD guidance and verify that the application is installed and - available on the TOE.</Tests></aactivity></management-function><management-function id="mf-entAppRemove"><text> remove Enterprise - applications </text><M ref="I"></M><NA ref="U"></NA><M ref="A"></M><NA ref="AO"></NA><app-note> - For function <xref to="mf-entAppRemove"></xref>, "Enterprise applications" are those applications that belong + available on the TOE.</Tests></aactivity> + </management-function> + <management-function id="mf-entAppRemove"> + <text> + <!-- 17. --> + <!-- <ctr id="entAppRemove" pre="" ctr-type="function">.</ctr>--> remove Enterprise + applications </text> + <M ref="I"/><NA ref="U"/><M ref="A"/><NA ref="AO"/> + <app-note> + For function <xref + to="mf-entAppRemove"/>, "Enterprise applications" are those applications that belong to the Enterprise application group. Applications installed by the enterprise administrator (including automatic installation by the administrator after being requested by the user from a catalog of enterprise applications) are by default placed in the Enterprise application group unless an exception has been made in function - <xref to="mf-appGroups"></xref> of FMT_SMF.1.1. - </app-note><aactivity><Tests> + <xref to="mf-appGroups"/> of FMT_SMF.1.1. + </app-note> + <aactivity><Tests> The evaluator shall attempt to remove any Enterprise applications from the device by following the administrator guidance. The evaluator shall verify that the TOE no longer permits users to access those applications or their associated - data.</Tests></aactivity></management-function><management-function id="mf-notifications"><text> enable/disable - display notification in the locked state of: <selectables linebreak="yes"><selectable>email notifications</selectable><selectable>calendar appointments</selectable><selectable>contact associated with phone call notification</selectable><selectable>text message notification</selectable><selectable><assignable>other application-based notifications</assignable></selectable><selectable>all notifications</selectable></selectables></text><M ref="I"></M><app-note> + data.</Tests></aactivity> + </management-function> + <management-function id="mf-notifications"> + <text> + <!-- 18. --> + <!-- <ctr id="notifications" pre="" ctr-type="function">.</ctr>--> enable/disable + display notification in the locked state of: <selectables linebreak="yes"> + <selectable>email notifications</selectable> + <selectable>calendar appointments</selectable> + <selectable>contact associated with phone call notification</selectable> + <selectable>text message notification</selectable> + <selectable><assignable>other application-based notifications</assignable></selectable> + <selectable>all notifications</selectable> + </selectables> + </text> + <M ref="I"/> + <app-note> If the display of notifications in the locked state is supported, the configuration of these - notifications (function <xref to="mf-notifications"></xref>) must be included in the + notifications (function <xref to="mf-notifications"/>) must be included in the selection. - </app-note><aactivity><Guidance>The evaluator + </app-note> + <aactivity><Guidance>The evaluator shall examine the AGD Guidance to determine that it specifies, for at least each - category of information selected for Function <xref to="mf-notifications"></xref>, + category of information selected for Function <xref to="mf-notifications"/>, how to enable and disable display information for that type of information in the locked state. - </Guidance><Tests>For each category of information listed in the AGD guidance, the evaluator + </Guidance> + <Tests>For each category of information listed in the AGD guidance, the evaluator shall verify that when that TSF is configured to limit the information according - to the AGD, the information is no longer displayed in the locked state.</Tests></aactivity></management-function><management-function id="mf-dar"><text> enable data-at rest protection </text><M ref="I"></M><app-note> - Function <xref to="mf-dar"></xref> must be included in the + to the AGD, the information is no longer displayed in the locked state.</Tests> + </aactivity> + </management-function> + <management-function id="mf-dar"> + <text> + <!-- 20. --> + <!-- <ctr id="dar" pre="" ctr-type="function">.</ctr>--> enable data-at rest protection </text> + <M ref="I"/> + <app-note> + Function <xref to="mf-dar"/> must be included in the selection if data-at-rest protection is not natively enabled. - </app-note><aactivity><Tests> + </app-note> + <aactivity><Tests> The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to the administrator, the user, to enable system-wide data-at-rest protection according to the AGD guidance. The evaluator shall ensure that all Evaluation Activities for DAR (FDP_DAR) are conducted with the device in this configuration. - </Tests></aactivity></management-function><management-function id="mf-rmediaDar"><text> enable removable media’s - data-at-rest protection </text><M ref="I"></M><app-note> - Function <xref to="mf-rmediaDar"></xref> is implicitly met if the TSF does not support + </Tests></aactivity> + </management-function> + + <management-function id="mf-rmediaDar"> + <text> + <!-- 21. --> + <!-- <ctr id="rmediaDar" pre="" ctr-type="function">.</ctr>--> enable removable media’s + data-at-rest protection </text> + <M ref="I"/> + <app-note> + Function <xref to="mf-rmediaDar"/> is implicitly met if the TSF does not support removable media. - </app-note><aactivity><Tests> + </app-note> + <aactivity><Tests> The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to the administrator, the user, to enable removable media’s data-at-rest protection according to the AGD guidance. The evaluator shall ensure that all Evaluation Activities for DAR (FDP_DAR) are conducted with the device in this configuration. - </Tests></aactivity></management-function><management-function id="mf-location"><text> enable/disable location - services: <htm:ul><htm:li>Across device</htm:li></htm:ul><htm:div class="indent"><selectables linebreak="yes"><selectable id="mf-location-per_app">on a per-app basis</selectable><selectable>on a per-group of applications processes basis</selectable><selectable exclusive="yes">no other method</selectable></selectables></htm:div></text><M ref="I"></M><app-note> - For function <xref to="mf-location"></xref>, location + </Tests></aactivity> + </management-function> + <management-function id="mf-location"> + <text> + <!-- 21. --> + <!-- <ctr id="location" pre="" ctr-type="function">.</ctr>--> enable/disable location + services: <htm:ul> + <htm:li>Across device</htm:li></htm:ul> + <htm:div class="indent"><selectables linebreak="yes"> + <selectable id="mf-location-per_app">on a per-app basis</selectable> + <selectable>on a per-group of applications processes basis</selectable> + <selectable exclusive="yes">no other method</selectable> + </selectables></htm:div> + </text> + <M ref="I"/> + <app-note> + For function <xref to="mf-location"/>, location services include location information gathered from GPS, cellular, and Wi-Fi. - </app-note><aactivity><Tests> - The evaluator shall perform the following tests. <testlist><test>The evaluator shall enable location services device-wide and shall + </app-note> + <aactivity><Tests> + The evaluator shall perform the following tests. <testlist> + <test>The evaluator shall enable location services device-wide and shall verify that an application (such as a mapping application) is able to access the TOE’s location information. The evaluator shall disable location services device-wide and shall verify that an application (such as a mapping - application) is unable to access the TOE’s location information. </test><test>[conditional] If <xref to="mf-location-per_app"></xref> is selected, the evaluator shall + application) is unable to access the TOE’s location information. </test> + <test>[conditional] If <xref to="mf-location-per_app"/> is selected, the evaluator shall create two applications and enable one to use access the location services and the other to not access the location services. The evaluator shall exercise each application attempting to access location services individually. The evaluator shall verify that the enabled application is able to access the location services and the disabled application is not - able to access the location services. </test></testlist></Tests></aactivity></management-function><management-function id="mf-authFactors"><text> enable/disable the use - of <selectables><selectable>Biometric Authentication Factor</selectable><selectable>Hybrid Authentication Factor</selectable></selectables></text><app-note> - Function <xref to="mf-authFactors"></xref> must be included in the ST if the TOE contains a BAF. This selection must correspond with the selection made in - FIA_UAU.5.1. If <xref to="uau_biometric"></xref> is selected in FIA_UAU.5.1, "Biometric Authentication Factor" + able to access the location services. </test> + </testlist></Tests></aactivity> + </management-function> + <management-function id="mf-authFactors"> + <text> + <!-- <ctr id="authFactors" pre="" ctr-type="function">.</ctr>--> enable/disable the use + of <selectables> + <selectable>Biometric Authentication Factor</selectable> + <selectable>Hybrid Authentication Factor</selectable> + </selectables> + </text> + <app-note> + Function <xref to="mf-authFactors"/> must be included in the ST if the TOE contains a BAF. This selection must correspond with the selection made in + FIA_UAU.5.1. If <xref to="uau_biometric"/> is selected in FIA_UAU.5.1, "Biometric Authentication Factor" must be selected and the user or admin must have the option to disable the use of - it. If multiple BAFs are claimed in FIA_MBV_EXT.1.1 in the <xref to="mod-biometrics"></xref>, this applies to all different - modalities. If <xref to="uau_hybr"></xref> is selected in FIA_UAU.5.1 it must be selected and the user + it. If multiple BAFs are claimed in FIA_MBV_EXT.1.1 in the <xref to="mod-biometrics"/>, this applies to all different + modalities. If <xref to="uau_hybr"/> is selected in FIA_UAU.5.1 it must be selected and the user or admin must have the option to disable the use of it. - </app-note><aactivity><Tests> + </app-note> + <aactivity><Tests> The evaluator shall verify that the TSS states if the TOE supports a BAF or hybrid authentication. If the TOE does not include a BAF or hybrid - authentication this test is implicitly met.<testlist><test>[conditional] If <xref to="uau_biometric"></xref> is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the <xref to="mod-biometrics"></xref> the evaluator shall verify that the - TSS describes the procedure to enable/disable the BAF. The evaluator shall configure the TOE to + authentication this test is implicitly met.<testlist> + <test>[conditional] If <xref to="uau_biometric"/> is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the <xref to="mod-biometrics"/> the evaluator shall verify that the + TSS describes the procedure to enable/disable the BAF.<!--If the TOE includes + multiple BAFs, the evaluator shall verify that the TSS describes how to + enable/disable each BAF, specifically if the different modalities can be + individually enabled/disabled.--> The evaluator shall configure the TOE to allow each supported BAF to authenticate and verify that successful authentication can be achieved using the BAF. The evaluator shall configure the TOE to disable the use of each supported BAF for authentication and - confirm that the BAF cannot be used to authenticate. </test><test>[conditional] If <xref to="uau_hybr"></xref> is selected the evaluator shall verify that + confirm that the BAF cannot be used to authenticate. </test> + <test>[conditional] If <xref to="uau_hybr"/> is selected the evaluator shall verify that the TSS describes the procedure to enable/disable the hybrid (biometric credential and PIN/password) authentication. The evaluator shall configure the TOE to allow hybrid authentication to authenticate and confirm that successful authentication can be achieved using the hybrid authentication. The evaluator shall configure the TOE to disable the use of hybrid authentication and confirm that the hybrid authentication cannot be used to - authenticate. </test></testlist></Tests></aactivity></management-function><management-function id="mf-certInvalid"><text> configure whether to + authenticate. </test> + </testlist> + </Tests></aactivity> + </management-function> + <management-function id="mf-certInvalid"> + <text> + <!-- <ctr id="certInvalid" pre="" ctr-type="function">.</ctr>--> configure whether to allow or disallow establishment of <assignable>configurable trusted channel in FTP_ITC_EXT.1.1 or FDP_UPC_EXT.1.1/APPS</assignable> if the peer or server certificate - is deemed invalid.</text><app-note> - Function <xref to="mf-certInvalid"></xref> must be included in the ST if the function is configurable on the TOE for any of the trusted channels either mandated or selected in <xref to="fel-wlan"></xref> or <xref to="fel-tls-app"></xref>. The configuration can be different depending on the specific trusted channel(s) and they must be filled in for the assignment. - </app-note><aactivity><Tests>The test of this function is performed in conjunction with FIA_X509_EXT.2.2, - FCS_TLSC_EXT.1.3 in the <xref to="pkg-tls"></xref>. </Tests></aactivity></management-function><management-function id="mf-externalPorts"><text> enable/disable all + is deemed invalid.</text> + <app-note> + <!-- TODO: Should this be something like for TLS do not approve any exceptions, for HTTP this is per FCS_HTTPS_EXT.1.3?? How do I force the selection of no exceptions for all (non-HTTPS) TLS connections? --> + Function <xref to="mf-certInvalid"/> must be included in the ST if the function is configurable on the TOE for any of the trusted channels either mandated or selected in <xref to="fel-wlan"/> or <xref to="fel-tls-app"/>. The configuration can be different depending on the specific trusted channel(s) and they must be filled in for the assignment. + </app-note> + <aactivity><Tests>The test of this function is performed in conjunction with FIA_X509_EXT.2.2, + FCS_TLSC_EXT.1.3 in the <xref to="pkg-tls"/>. </Tests></aactivity> + </management-function> + <!-- Start of the Optional to implement functions --> + <management-function id="mf-externalPorts"> + <text> + <!-- <ctr id="externalPorts" pre="" ctr-type="function">.</ctr>--> enable/disable all data signaling over <assignable>list of externally accessible hardware - ports</assignable></text><app-note> The assignment in function - <xref to="mf-externalPorts"></xref> consists of all externally accessible hardware + ports</assignable> + </text> + <app-note> + <!-- Start of the optional to include functions --> The assignment in function + <xref to="mf-externalPorts"/> consists of all externally accessible hardware ports, such as USB, the SD card, and HDMI, whose data transfer capabilities can be enabled and disabled by either the user or administrator. Disablement of data transfer over an external port must be effective during and after boot into the normal @@ -4350,10 +8226,12 @@ The evaluator shall exercise the TSF configuration as the administrator and separately. The configuration policy need not disable all ports together. In the case of USB, charging is still allowed if data transfer capabilities have been disabled. - </app-note><aactivity><TSS> + </app-note> + <aactivity><TSS> The evaluator shall verify that the TSS includes a list of each externally accessible hardware port and an indication of if data transfer over that port can - be enabled/disabled. AGD guidance will describe how to perform the enable/disable function.</TSS><Tests>The evaluator shall exercise the TSF configuration to enable and disable + be enabled/disabled. AGD guidance will describe how to perform the enable/disable function.</TSS> + <Tests>The evaluator shall exercise the TSF configuration to enable and disable data transfer capabilities over each externally accessible hardware ports (e.g. USB, SD card, HDMI) listed by the ST author. The evaluator shall use test equipment for the particular interface to ensure that while the TOE may continue to @@ -4361,45 +8239,83 @@ The evaluator shall exercise the TSF configuration as the administrator and disabled data transfer capability, the evaluator shall repeat this test by rebooting the device into the normal operational mode and verifying that the capability is disabled throughout the boot and early execution stage of the - device.</Tests></aactivity></management-function><management-function id="mf-serverProtocols"><text> enable/disable - <assignable id="a-server">list of protocols where the device acts as a server</assignable></text><app-note> - The assignment in function <xref to="mf-serverProtocols"></xref> + device.</Tests> + </aactivity> + </management-function> + <management-function id="mf-serverProtocols"> + <text> + <!-- <ctr id="serverProtocols" pre="" ctr-type="function">.</ctr>--> enable/disable + <assignable id="a-server">list of protocols where the device acts as a server</assignable> + </text> + <app-note> + The assignment in function <xref to="mf-serverProtocols"/> consists of all protocols where the TSF acts as a server, which can be enabled and disabled by either the user or administrator. - </app-note><aactivity><TSS> + </app-note> + <aactivity><TSS> The evaluator shall verify that the TSS describes how the TSF acts as a server in - each of the protocols listed in the ST, and the reason for acting as a server.</TSS><Tests> + each of the protocols listed in the ST, and the reason for acting as a server.</TSS> + <Tests> The evaluator shall attempt to disable each listed protocol in the assignment. The evaluator shall verify that remote devices can no longer access the TOE or TOE resources using any disabled protocols. - </Tests></aactivity></management-function><management-function id="mf-devModes"><text> enable/disable developer - modes </text><app-note> - Function <xref to="mf-devModes"></xref> must be included in the selection if developer modes are + </Tests> + </aactivity> + </management-function> + <management-function id="mf-devModes"> + <text> + <!-- <ctr id="devModes" pre="" ctr-type="function">.</ctr>--> enable/disable developer + modes </text> + <app-note> + Function <xref + to="mf-devModes"/> must be included in the selection if developer modes are supported by the TSF. - </app-note><aactivity><Tests> + </app-note> + <aactivity><Tests> The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to the administrator, the user, to enable and disable any developer mode. The evaluator shall test that developer mode access is not available when its configuration is disabled. The evaluator shall verify the - developer mode remains disabled during device reboot.</Tests></aactivity></management-function><management-function id="mf-authBypass"><text> enable/disable bypass of - local user authentication </text><app-note> - Function <xref to="mf-authBypass"></xref> must + developer mode remains disabled during device reboot.</Tests></aactivity> + </management-function> + <management-function id="mf-authBypass"> + <text> + <!-- <ctr id="authBypass" pre="" ctr-type="function">.</ctr>--> enable/disable bypass of + local user authentication </text> + <app-note> + Function <xref to="mf-authBypass"/> must be included in the selection if bypass of local user authentication, such as a "Forgot Password", password hint, or remote authentication feature, is supported. - </app-note><aactivity><Guidance>The + </app-note> + <aactivity><Guidance>The evaluator shall examine the AGD guidance to determine that it describes how to enable and disable any "Forgot Password", password hint, or remote authentication (to bypass local authentication mechanisms) capability. - </Guidance><Tests>For each mechanism listed in the AGD guidance that provides a "Forgot + </Guidance> + <Tests>For each mechanism listed in the AGD guidance that provides a "Forgot Password" feature or other means where the local authentication process can be bypassed, the evaluator shall disable the feature and ensure that they are not - able to bypass the local authentication process.</Tests></aactivity></management-function><management-function id="mf-wipeEntData"><text> wipe Enterprise data </text><NA ref="AO"></NA><aactivity><Tests> + able to bypass the local authentication process.</Tests></aactivity> + </management-function> + <management-function id="mf-wipeEntData"> + <text> + <!-- <ctr id="wipeEntData" pre="" ctr-type="function">.</ctr>--> wipe Enterprise data </text> + <NA ref="AO"/> + <aactivity><Tests> The evaluator shall attempt to wipe Enterprise data resident on the device according to the administrator guidance. The evaluator shall verify that the - data is no longer accessible by the user.</Tests></aactivity></management-function><management-function id="mf-appCert"><text> approve <selectables><selectable>import</selectable><selectable>removal</selectable></selectables> by applications of X.509v3 certificates in the Trust Anchor - Database </text><app-note> - Function <xref to="mf-appCert"></xref> must be included in the + data is no longer accessible by the user.</Tests></aactivity> + </management-function> + <management-function id="mf-appCert"> + <text> + <!-- <ctr id="appCert" pre="" ctr-type="function">.</ctr>--> approve <selectables> + <selectable>import</selectable> + <selectable>removal</selectable> + </selectables> by applications of X.509v3 certificates in the Trust Anchor + Database </text> + <app-note> + Function <xref to="mf-appCert"/> must be included in the selection if the TSF allows applications, other than the MDM Agents, to import or remove X.509v3 certificates from the Trust Anchor Database. The MDM Agent is considered the administrator. This function does not apply to applications trusting a @@ -4408,212 +8324,419 @@ The evaluator shall exercise the TSF configuration as the administrator and performed by the TSF for other applications. The user or administrator may be provided the ability to globally allow or deny any application requests in order to meet this requirement. - </app-note><aactivity><TSS> + </app-note> + <aactivity><TSS> The evaluator shall verify that the TSS describes how approval for an application to perform the selected action (import, removal) with respect to certificates in the Trust Anchor Database is accomplished (e.g., a pop-up, policy setting, etc.). - <htm:br></htm:br><htm:br></htm:br> The evaluator shall also verify that the API documentation - provided according to <xref to="adv"></xref> includes any security functions + <htm:br/><htm:br/> The evaluator shall also verify that the API documentation + provided according to <xref to="adv"/> includes any security functions (import, modification, or destruction of the Trust Anchor Database) allowed by applications. - </TSS><Tests>The evaluator shall perform one of the following tests: <testlist><test>[conditional] If applications may import certificates to the Trust + </TSS> + <Tests>The evaluator shall perform one of the following tests: <testlist> + <test>[conditional] If applications may import certificates to the Trust Anchor Database, the evaluator shall write, or the developer shall provide access to, an application that imports a certificate into the Trust Anchor Database. The evaluator shall verify that the TOE requires approval before - allowing the application to import the certificate: <htm:ul><htm:li>The evaluator shall deny the approvals to verify that the + allowing the application to import the certificate: <htm:ul> + <htm:li>The evaluator shall deny the approvals to verify that the application is not able to import the certificate. Failure of import shall be tested by attempting to validate a certificate that chains to the certificate whose import was attempted (as described in the - evaluation activity for FIA_X509_EXT.1). </htm:li><htm:li>The evaluator shall repeat the test, allowing the approval to + evaluation activity for FIA_X509_EXT.1). </htm:li> + <htm:li>The evaluator shall repeat the test, allowing the approval to verify that the application is able to import the certificate and that - validation occurs. </htm:li></htm:ul></test><test>[conditional] If applications may remove certificates in the Trust + validation occurs. </htm:li> + </htm:ul> + </test> + <test>[conditional] If applications may remove certificates in the Trust Anchor Database, the evaluator shall write, or the developer shall provide access to, an application that removes certificates from the Trust Anchor Database. The evaluator shall verify that the TOE requires approval before - allowing the application to remove the certificate: <htm:ul><htm:li>The evaluator shall deny the approvals to verify that the + allowing the application to remove the certificate: <htm:ul> + <htm:li>The evaluator shall deny the approvals to verify that the application is not able to remove the certificate. Failure of removal shall be tested by attempting to validate a certificate that chains to the certificate whose removal was attempted (as described in the - evaluation activity for FIA_X509_EXT.1). </htm:li></htm:ul></test></testlist> The evaluator shall repeat the test, allowing the approval to verify + evaluation activity for FIA_X509_EXT.1). </htm:li> + </htm:ul> + </test> + </testlist> The evaluator shall repeat the test, allowing the approval to verify that the application is able to remove/modify the certificate and that validation no longer occurs. - </Tests></aactivity></management-function><management-function id="mf-certValidity"><text> configure whether to + </Tests> + </aactivity> + </management-function> + <management-function id="mf-certValidity"> + <text> + <!-- <ctr id="certValidity" pre="" ctr-type="function">.</ctr>--> configure whether to allow or disallow establishment of a trusted channel if the TSF cannot establish a - connection to determine the validity of a certificate</text><app-note> - Function <xref to="mf-certValidity"></xref> must be + connection to determine the validity of a certificate</text> + <app-note> + Function <xref to="mf-certValidity"/> must be included in the ST if "administrator-configured option" is selection in FIA_X509_EXT.2.2. - </app-note><aactivity><Tests>The test of this function is performed in conjunction with FIA_X509_EXT.2.2.</Tests></aactivity></management-function><management-function id="mf-cellular"><text> enable/disable the - cellular protocols used to connect to cellular network base stations </text><aactivity><TSS>The + </app-note> + <aactivity><Tests>The test of this function is performed in conjunction with FIA_X509_EXT.2.2.</Tests></aactivity> + </management-function> + <management-function id="mf-cellular"> + <text> + <!-- <ctr id="cellular" pre="" ctr-type="function">.</ctr>--> enable/disable the + cellular protocols used to connect to cellular network base stations </text> + <aactivity><TSS>The evaluator shall ensure that the TSS describes which cellular protocols can be - disabled.</TSS><Guidance>The evaluator shall confirm that the AGD guidance describes the + disabled.</TSS> + <Guidance>The evaluator shall confirm that the AGD guidance describes the procedure for disabling each cellular protocol identified in the TSS. - </Guidance><Tests>The evaluator shall attempt to disable each cellular protocol according to + </Guidance> + <Tests>The evaluator shall attempt to disable each cellular protocol according to the administrator guidance. The evaluator shall attempt to connect the device to a cellular network and, using network analysis tools, verify that the device - does not allow negotiation of the disabled protocols.</Tests></aactivity></management-function><management-function id="mf-auditLogs"><text> read audit logs kept by - the TSF </text><NA ref="AO"></NA><aactivity><Tests>The evaluator shall attempt to read any device audit logs according to the + does not allow negotiation of the disabled protocols.</Tests></aactivity> + </management-function> + <management-function id="mf-auditLogs"> + <text> + <!-- <ctr id="auditLogs" pre="" ctr-type="function">.</ctr>--> read audit logs kept by + the TSF </text> + <NA ref="AO"/> + <aactivity><Tests>The evaluator shall attempt to read any device audit logs according to the administrator guidance and verify that the logs may be read. This test may be - performed in conjunction with the evaluation activity of FAU_GEN.1.</Tests></aactivity></management-function><management-function id="mf-digSign"><text> configure <selectables><selectable>certificate</selectable><selectable>public-key</selectable></selectables> used to validate digital signature on applications </text><app-note> - Function <xref to="mf-digSign"></xref> should be + performed in conjunction with the evaluation activity of FAU_GEN.1.</Tests></aactivity> + </management-function> + <management-function id="mf-digSign"> + <text> + <!-- <ctr id="digSign" pre="" ctr-type="function">.</ctr>--> configure <selectables> + <selectable>certificate</selectable> + <selectable>public-key</selectable> + </selectables> used to validate digital signature on applications </text> + <app-note> + Function <xref to="mf-digSign"/> should be included in the selection if FPT_TUD_EXT.5.1 is included in the ST and the configurable option is selected. - </app-note><aactivity><Tests> + </app-note> + <aactivity><Tests> The test of this function is performed in conjunction with FPT_TUD_EXT.5.1. - </Tests></aactivity></management-function><management-function id="mf-sharedKeys"><text> approve exceptions for - shared use of keys or secrets by multiple applications </text><app-note> - Function <xref to="mf-sharedKeys"></xref> should be included in the selection if user or administrator is + </Tests></aactivity> + </management-function> + <management-function id="mf-sharedKeys"> + <text> + <!-- <ctr id="sharedKeys" pre="" ctr-type="function">.</ctr>--> approve exceptions for + shared use of keys or secrets by multiple applications </text> + <app-note> + Function <xref + to="mf-sharedKeys"/> should be included in the selection if user or administrator is selected in FCS_STG_EXT.1.4. - </app-note><aactivity><TSS>The + </app-note> + <aactivity><TSS>The evaluator shall verify that the TSS describes how the approval for exceptions for shared use of keys or secrets by multiple applications is accomplished (e.g., a pop-up, policy setting, etc.).</TSS><Tests> The test of this function is performed in conjunction with FCS_STG_EXT.1. - </Tests></aactivity></management-function><management-function id="mf-keyWipeRules"><text> approve exceptions for + </Tests></aactivity> + </management-function> + <management-function id="mf-keyWipeRules"> + <text> + <!-- <ctr id="keyWipeRules" pre="" ctr-type="function">.</ctr>--> approve exceptions for destruction of keys or secrets by applications that did not import the key or secret - </text><app-note> - Function <xref to="mf-keyWipeRules"></xref> should be included in the selection if - <xref to="s-killkey-user"></xref> or <xref to="s-killkey-admin"></xref> + </text> + <app-note> + Function <xref to="mf-keyWipeRules"/> should be included in the selection if + <xref to="s-killkey-user"/> or <xref to="s-killkey-admin"/> is selected in FCS_STG_EXT.1.5. - <rule id="r-killkey-user-mf"><if><ref-id>s-killkey-user</ref-id></if><then><ref-id>mf-keyWipeRules</ref-id></then></rule><rule id="r-killkey-admin-mf"><if><ref-id>s-killkey-admin</ref-id></if><then><ref-id>mf-keyWipeRules</ref-id></then></rule></app-note><aactivity><TSS>The + <rule id="r-killkey-user-mf"> + <if><ref-id>s-killkey-user</ref-id></if> + <then><ref-id>mf-keyWipeRules</ref-id></then> + </rule> + <rule id="r-killkey-admin-mf"> + <if><ref-id>s-killkey-admin</ref-id></if> + <then><ref-id>mf-keyWipeRules</ref-id></then> + </rule> + </app-note> + <aactivity><TSS>The evaluator shall verify that the TSS describes how the approval for exceptions for destruction of keys or secrets by applications that did not import the key or secret is accomplished (e.g., a pop-up, policy setting, etc.). </TSS><Tests> The test of this function is performed in conjunction with FCS_STG_EXT.1. - </Tests></aactivity></management-function><management-function id="mf-unlockBanner"><text> configure the unlock - banner </text><M ref="I"></M><NA ref="U"></NA><app-note></app-note><aactivity><TSS> + </Tests> + </aactivity> + </management-function> + <management-function id="mf-unlockBanner"> + <text> + <!-- <ctr id="unlockBanner" pre="" ctr-type="function">.</ctr>--> configure the unlock + banner </text> + <M ref="I"/> <NA ref="U"/> + <app-note> + <!-- ToDo Removed because FTA_TAB is now mandatory: Function <xref to="mf-unlockBanner"/> must be + included in the selection if FTA_TAB.1 is included in the ST. !--> + </app-note> + <aactivity><TSS> The evaluator shall verify that the TSS describes any restrictions in banner settings (e.g., character limitations). </TSS><Tests> The test of this function is performed in conjunction with FTA_TAB.1. - </Tests></aactivity></management-function><management-function id="mf-auditItems"><text> configure the auditable - items </text><NA ref="U"></NA><app-note> - Function <xref to="mf-auditItems"></xref> must be included in the selection if FAU_SEL.1 + </Tests></aactivity> + </management-function> + <management-function id="mf-auditItems"> + <text> + <!-- <ctr id="auditItems" pre="" ctr-type="function">.</ctr>--> configure the auditable + items </text> + <NA ref="U"/> + <app-note> + Function <xref to="mf-auditItems"/> must be included in the selection if FAU_SEL.1 is included in the ST. - </app-note><aactivity><Tests>The test of this function is performed in conjunction with FAU_SEL.1.</Tests></aactivity></management-function><management-function id="mf-integ"><text> retrieve TSF-software - integrity verification values </text><aactivity><Tests>The test of this function is performed in conjunction with FPT_NOT_EXT.2.1.</Tests></aactivity></management-function><management-function id="mf-USB"><text> enable/disable <selectables linebreak="yes"><selectable id="s-usbstore">USB mass storage mode</selectable><selectable>USB data transfer without user authentication</selectable><selectable>USB data transfer without authentication of the connecting - system</selectable></selectables></text><aactivity><TSS>The + </app-note> + <aactivity><Tests>The test of this function is performed in conjunction with FAU_SEL.1.</Tests></aactivity> + </management-function> + <management-function id="mf-integ"> + <text> + <!-- <ctr id="integ" pre="" ctr-type="function">.</ctr>--> retrieve TSF-software + integrity verification values </text> + <aactivity><Tests>The test of this function is performed in conjunction with FPT_NOT_EXT.2.1.</Tests></aactivity> + </management-function> + <management-function id="mf-USB"> + <text> + <!-- <ctr id="USB" pre="" ctr-type="function">.</ctr>--> enable/disable <selectables + linebreak="yes"> + <selectable id="s-usbstore">USB mass storage mode</selectable> + <selectable>USB data transfer without user authentication</selectable> + <selectable>USB data transfer without authentication of the connecting + system</selectable> + </selectables> + </text> + <aactivity><TSS>The evaluator shall verify that the TSS includes a description of how data transfers - can be managed over USB.</TSS><Tests>The evaluator shall perform the following tests based on the selections made - in the table: <testlist><test>[conditional] The evaluator shall disable USB mass storage mode, + can be managed over USB.</TSS> + <Tests>The evaluator shall perform the following tests based on the selections made + in the table: <testlist> + <test>[conditional] The evaluator shall disable USB mass storage mode, attach the device to a computer, and verify that the computer cannot mount the TOE as a drive. The evaluator shall reboot the TOE and repeat this test - with other supported auxiliary boot modes. </test><test>[conditional] The evaluator shall disable USB data transfer without + with other supported auxiliary boot modes. </test> + <test>[conditional] The evaluator shall disable USB data transfer without user authentication, attach the device to a computer, and verify that the TOE requires user authentication before the computer can access TOE data. The evaluator shall reboot the TOE and repeat this test with other supported - auxiliary boot modes. </test><test>[conditional] The evaluator shall disable USB data transfer without + auxiliary boot modes. </test> + <test>[conditional] The evaluator shall disable USB data transfer without connecting system authentication, attach the device to a computer, and verify that the TOE requires connecting system authentication before the computer can access TOE data. The evaluator shall then connect the TOE to another computer and verify that the computer cannot access TOE data. The evaluator shall then connect the TOE to the original computer and verify - that the computer can access TOE data. </test></testlist></Tests></aactivity></management-function><management-function id="mf-backup"><text> enable/disable backup of <selectables><selectable id="s-backup-all-apps">all applications</selectable><selectable id="s-backup-sel-apps">selected applications</selectable><selectable id="s-backup-sel-grps">selected groups of applications</selectable><selectable id="s-backup-cfg">configuration data</selectable></selectables> to <selectables><selectable>locally connected system</selectable><selectable>remote system</selectable></selectables></text><aactivity><TSS>The + that the computer can access TOE data. </test> + </testlist></Tests> + </aactivity> + </management-function> + <management-function id="mf-backup"> + <text> + <!-- <ctr id="backup" pre="" ctr-type="function">.</ctr>--> enable/disable backup of <selectables> + <selectable id="s-backup-all-apps">all applications</selectable> + <selectable id="s-backup-sel-apps">selected applications</selectable> + <selectable id="s-backup-sel-grps">selected groups of applications</selectable> + <selectable id="s-backup-cfg">configuration data</selectable> + </selectables> to <selectables> + <selectable>locally connected system</selectable> + <selectable>remote system</selectable> + </selectables> + </text> + <aactivity><TSS>The evaluator shall verify that the TSS includes a description of available backup methods that can be enabled/disabled. If "selected applications" or "selected groups of applications" are selected the TSS shall include which applications of groups of - applications backup can be enabled/disabled.</TSS><Tests> If <xref to="s-backup-all-apps"></xref> is selected, the evaluator shall disable each selected + applications backup can be enabled/disabled.</TSS> + + <Tests> If <xref to="s-backup-all-apps"/> is selected, the evaluator shall disable each selected backup location in turn and verify that the TOE cannot complete a backup. The evaluator shall then enable each selected backup location in turn and verify - that the TOE can perform a backup. <htm:br></htm:br><htm:br></htm:br> + that the TOE can perform a backup. <htm:br/><htm:br/> - If <xref to="s-backup-sel-apps"></xref> is selected, + If <xref to="s-backup-sel-apps"/> is selected, the evaluator shall disable each selected backup location in turn and verify that for the selected application the TOE prevents backup from occurring. The evaluator shall then enable each selected backup location in turn and verify that for the selected application the TOE can perform a backup. - <htm:br></htm:br><htm:br></htm:br> + <htm:br/><htm:br/> - If <xref to="s-backup-sel-grps"></xref> is selected, the + If <xref to="s-backup-sel-grps"/> is selected, the evaluator shall disable each selected backup location in turn and verify that for a group of applications the TOE prevents the backup from occurring. The evaluator shall then enable each selected backup location in turn and verify for - the group of application the TOE can perform a backup. <htm:br></htm:br><htm:br></htm:br> + the group of application the TOE can perform a backup. <htm:br/><htm:br/> - If <xref to="s-backup-cfg"></xref> is selected, the evaluator shall disable each selected + If <xref to="s-backup-cfg"/> is selected, the evaluator shall disable each selected backup location in turn and verify that the TOE prevents the backup of configuration data from occurring. The evaluator shall then enable each selected backup location in turn and verify that the TOE can perform a backup of configuration data. - </Tests></aactivity></management-function><management-function id="mf-hotspot"><text> enable/disable <selectables linebreak="yes"><selectable>Hotspot functionality authenticated by <selectables><selectable>pre-shared key</selectable><selectable>passcode</selectable><selectable exclusive="yes">no authentication</selectable></selectables></selectable><selectable id="s-tether"><snip>USB tethering</snip> authenticated by <selectables><selectable>pre-shared key</selectable><selectable>passcode</selectable><selectable exclusive="yes">no authentication</selectable></selectables></selectable></selectables></text><app-note> - For function <xref to="mf-hotspot"></xref>, + </Tests></aactivity> + </management-function> + <management-function id="mf-hotspot"> + <text> + <!-- <ctr id="hotspot" pre="" ctr-type="function">.</ctr>--> enable/disable <selectables + linebreak="yes"> + <selectable>Hotspot functionality authenticated by <selectables> + <selectable>pre-shared key</selectable> + <selectable>passcode</selectable> + <selectable exclusive="yes">no authentication</selectable> + </selectables></selectable> + <selectable id="s-tether"><snip>USB tethering</snip> authenticated by <selectables> + <selectable>pre-shared key</selectable> + <selectable>passcode</selectable> + <selectable exclusive="yes">no authentication</selectable> + </selectables> + </selectable> + </selectables> + </text> + <app-note> + For function <xref to="mf-hotspot"/>, hotspot functionality refers to the condition in which the mobile device is serving as an access point to other devices, not the connection of the TOE to external hotspots. - </app-note><aactivity><TSS> The + </app-note> + <aactivity><TSS> The evaluator shall verify that the TSS includes a description of Hotspot - functionality and USB tethering to include any authentication for these.</TSS><Tests>The evaluator shall perform the following tests based on the selections in - Function <xref to="mf-hotspot"></xref>. <testlist><test>[conditional] The evaluator shall enable hotspot functionality with + functionality and USB tethering to include any authentication for these.</TSS> + <Tests>The evaluator shall perform the following tests based on the selections in + Function <xref to="mf-hotspot"/>. <testlist> + <test>[conditional] The evaluator shall enable hotspot functionality with each of the of the support authentication methods. The evaluator shall connect to the hotspot with another device and verify that the hotspot - functionality requires the configured authentication method. </test><test>[conditional] The evaluator shall enable USB tethering functionality + functionality requires the configured authentication method. </test> + <test>[conditional] The evaluator shall enable USB tethering functionality with each of the of the support authentication methods. The evaluator shall connect to the TOE over USB with another device and verify that the tethering functionality requires the configured authentication method. - </test></testlist></Tests></aactivity></management-function><management-function id="mf-dataSharing"><text> approve exceptions for - sharing data between <selectables><selectable>applications</selectable><selectable>groups of applications</selectable></selectables></text><app-note> - Functions <xref to="mf-dataSharing"></xref> and <xref to="mf-appGroups"></xref> correspond to FDP_ACF_EXT.1.2. - </app-note><aactivity><Tests>The test of this function is performed in conjunction with FDP_ACF_EXT.1.2.</Tests></aactivity></management-function><management-function id="mf-appGroups"><text> place applications into + </test> + </testlist></Tests></aactivity> + </management-function> + <management-function id="mf-dataSharing"> + <text> + <!-- <ctr id="dataSharing" pre="" ctr-type="function">.</ctr>--> approve exceptions for + sharing data between <selectables> + <selectable>applications</selectable> + <selectable>groups of applications</selectable> + </selectables></text> + <app-note> + Functions <xref to="mf-dataSharing"/> and <xref + to="mf-appGroups"/> correspond to FDP_ACF_EXT.1.2. + </app-note> + <aactivity><Tests>The test of this function is performed in conjunction with FDP_ACF_EXT.1.2.</Tests></aactivity> + </management-function> + <management-function id="mf-appGroups"> + <text> + <!-- <ctr id="appGroups" pre="" ctr-type="function">.</ctr>--> place applications into application groups based on <assignable>enterprise configuration - settings</assignable></text><aactivity><Tests> + settings</assignable></text> + <aactivity><Tests> The evaluator shall set a policy to cause a designated application to be placed into a particular application group. The evaluator shall then install the designated application and verify that it was placed into the correct group. - </Tests></aactivity></management-function><management-function id="mf-unenroll"><text> unenroll the TOE from - management </text><app-note> + </Tests></aactivity> + </management-function> + <management-function id="mf-unenroll"> + <text> + <!-- <ctr id="unenroll" pre="" ctr-type="function">.</ctr>--> unenroll the TOE from + management </text> + <app-note> For function - <xref to="mf-unenroll"></xref>, FMT_SMF_EXT.2.1 specifies actions to be performed when + <xref to="mf-unenroll"/>, FMT_SMF_EXT.2.1 specifies actions to be performed when the TOE is unenrolled from management. - </app-note><aactivity><Tests>The evaluator shall attempt to unenroll the device from management and + </app-note> + <aactivity><Tests>The evaluator shall attempt to unenroll the device from management and verify that the steps described in FMT_SMF_EXT.2.1 are performed. This test should be performed in conjunction with the FMT_SMF_EXT.2.1 evaluation activity. - </Tests></aactivity></management-function><management-function id="mf-alwaysOnVPN"><text> enable/disable the + </Tests></aactivity> + </management-function> + <management-function id="mf-alwaysOnVPN"> + <text> + <!-- <ctr id="alwaysOnVPN" pre="" ctr-type="function">.</ctr>--> enable/disable the Always On VPN protection: - <htm:ul><htm:li>Across device</htm:li></htm:ul><htm:div class="indent"><selectables linebreak="yes"><selectable>on a per-app basis</selectable><selectable>on a per-group of applications processes basis</selectable><selectable exclusive="yes">no other method</selectable></selectables></htm:div></text><app-note> - Function <_></_> must be included in the ST if IPsec is selected in + <htm:ul> + <htm:li>Across device</htm:li></htm:ul> + <htm:div class="indent"><selectables linebreak="yes"> + <selectable>on a per-app basis</selectable> + <selectable>on a per-group of applications processes basis</selectable> + <selectable exclusive="yes">no other method</selectable> + </selectables></htm:div> + </text> + <app-note> + Function <_/> must be included in the ST if IPsec is selected in FTP_ITC_EXT.1 and the native IPsec VPN client can be configured to be Always-On. Always-On is defined as when the TOE has a network connection the VPN attempts to connect, all data leaving the device uses the VPN when the VPN is connected and no data leaves that device when the VPN is disconnected. The configuration of the VPN Client itself (with information such as VPN Gateway, certificates, and algorithms) is - addressed by the <xref to="mod-vpnclient"></xref>. - </app-note><aactivity><TSS>The evaluator shall verify that the TSS contains guidance to configure the + addressed by the <xref to="mod-vpnclient"/>. + </app-note> + <aactivity><TSS>The evaluator shall verify that the TSS contains guidance to configure the VPN as Always-On. </TSS><Tests>The evaluator shall configure the VPN as Always-On and perform the following tests: - <testlist><test>The evaluator shall verify that when the VPN is connected all traffic + <testlist> + <test>The evaluator shall verify that when the VPN is connected all traffic is routed through the VPN. This test is performed in conjunction with - FDP_IFC_EXT.1.1. </test><test>The evaluator shall verify that when the VPN is not established, that + FDP_IFC_EXT.1.1. </test> + <test>The evaluator shall verify that when the VPN is not established, that no traffic leaves the device. The evaluator shall ensure that the TOE has network connectivity and that the VPN is established. The evaluator shall use a packet sniffing tool to capture the traffic leaving the TOE. The evaluator shall disable the VPN connection on the server side. The evaluator shall perform actions with the device such as navigating to websites, using provided applications, and accessing other Internet resources and verify - that no traffic leaves the device. </test><test>The evaluator shall verify that the TOE has network connectivity and + that no traffic leaves the device. </test> + <test>The evaluator shall verify that the TOE has network connectivity and that the VPN is established. The evaluator shall disable network connectivity (i.e. Airplane Mode) and verify that the VPN disconnects. The evaluator shall re-establish network connectivity and verify that the VPN - automatically reconnects. </test></testlist></Tests></aactivity></management-function><management-function id="mf-bioRevoke"><text> revoke Biometric - template</text><aactivity><TSS>The evaluator shall verify that the TSS describes the procedure to revoke a + automatically reconnects. </test> + </testlist> + </Tests></aactivity> + </management-function> + <management-function id="mf-bioRevoke"> + <text> + <!-- <ctr id="bioRevoke" pre="" ctr-type="function">.</ctr>--> revoke Biometric + template</text> + <aactivity><TSS>The evaluator shall verify that the TSS describes the procedure to revoke a biometric credential stored on the TOE. </TSS><Tests>The evaluator shall configure the TOE to use BAF and confirm that the biometric can be used to authenticate to the device. The evaluator shall revoke the biometric credential’s ability to authenticate to the TOE and confirm that the same BAF cannot be used to authenticate to the device. - </Tests></aactivity></management-function><management-function id="mf-other"><text><assignable>list of other management functions to be provided by the - TSF</assignable></text><aactivity><TSS> The evaluator shall + </Tests></aactivity> + </management-function> + <management-function id="mf-other"> + <text> + <!-- <ctr id="other" pre="" ctr-type="function">.</ctr>--> + <assignable>list of other management functions to be provided by the + TSF</assignable></text> + <aactivity><TSS> The evaluator shall verify that the TSS describes all assigned security management functions and their intended behavior. - </TSS><Tests>The evaluator shall design and perform tests to demonstrate that the + </TSS> + <Tests>The evaluator shall design and perform tests to demonstrate that the function may be configured and that the intended behavior of the function is enacted by the TOE. - </Tests></aactivity></management-function></management-function-set> The TSF shall be capable of performing the following management functions: <htm:b> <ctr id="fmt_smf" ctr-type="Table">: Management Functions</ctr></htm:b> Status Markers: M - Mandatory O - Optional/Objective - compares the management functions required by this + + + + + + + The TSF shall be capable of performing <assignable>list of management functions</assignable>. + + + + compares the management functions required by this Protection Profile. The first column lists the management functions - identified in the PP. In the following columns: ‘M’ means Mandatory‘O’ means Optional/Objective'-' means that no value (M or O) can be assigned The third column ("Impl.") indicates whether the function is + identified in the PP. In the following columns: + ‘M’ means Mandatory + ‘O’ means Optional/Objective + '-' means that no value (M or O) can be assigned + + The third column ("Impl.") indicates whether the function is to be implemented. The ST author should select which Optional functions are implemented. The fourth column ("User Only") indicates functions that are to be restricted to the user (i.e. not available to the administrator). @@ -4637,48 +8760,609 @@ The evaluator shall exercise the TSF configuration as the administrator and implemented in order for the function to be included. For functions with a "per-app basis" sub function and an assignment, the ST author must indicate which assigned features are manageable on a per-app basis and which are not by iterating the row. - - - The evaluator shall verify - the TSS defines the allowable policy options: the range of values for both - password length and lifetime, and a description of complexity to include character - set and complexity policies (e.g., configuration and enforcement of number of - uppercase, lowercase, and special characters per password). - -The evaluator shall exercise the TSF configuration as the administrator and - perform positive and negative tests, with at least two values set for each - variable setting, for each of the following: Minimum password lengthMinimum password complexityMaximum password lifetime + + + + + + + + + + + + + + + + + + + + + + The evaluator shall verify that the TSS describes all management functions, what + roles can perform each function, and how these functions are (or can be) + restricted to the roles identified by FMT_MOF_EXT.1. The + following activities are organized according to the function number in the table. + These activities include TSS Evaluation Activities, AGD Evaluation Activities, and + test activities. Test activities specified below shall take place + in the test environment described in the evaluation activity for FPT_TUD_EXT.1. + The evaluator shall consult the AGD guidance to perform each of the + specified tests, iterating each test as necessary if both the user and administrator + may perform the function. The evaluator shall verify that the AGD guidance describes + how to perform each management function, including any configuration details. For + each specified management function tested, the evaluator shall confirm that the + underlying mechanism exhibits the configured setting. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - Initiation of policy update - Policy name - - - Change of settings - Role of user that changed setting, Value of new setting - - - Success or failure of function - Role of user that performed function, Function performed, Reason for failure - - - Initiation of software update - Version of update - - - Initiation of application installation or update - Name and version of application - + + Initiation of policy update + Policy name + + + Change of settings + Role of user that changed setting, Value of new setting + + + Success or failure of function + Role of user that performed function, Function performed, Reason for failure + + + Initiation of software update + Version of update + + + Initiation of application installation or update + Name and version of application + - - + + requires the TSF to automatically perform specific management functions in response to a specific event. - The following actions could be considered for the management functions in FMT: Configuration of the functions that are performed in response to unenrollment event. - The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Initiation of unenrollment.Completion of unenrollment. + The following actions could be considered for the management functions in FMT: + Configuration of the functions that are performed in response to unenrollment event. + + + The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: + Initiation of unenrollment. + Completion of unenrollment. + + No dependencies. + + - The TSF shall offer<selectables><selectable id="s-smf-wipe-pro" >wipe of protected data</selectable><selectable id="s-smf-wipe-sen" >wipe of sensitive data</selectable><selectable id="s-smf-ext-2-rem-ent-app" >remove Enterprise applications</selectable><selectable id="fmt_smf_ext.2.1_1" >remove all device-stored Enterprise resource data</selectable><selectable id="fmt_smf_ext.2.1_2" >remove Enterprise secondary authentication data</selectable><selectable id="fmt_smf_ext.2.1_4" ><assignable>list other available remediation actions </assignable></selectable></selectables>upon unenrollment and<selectables><selectable id="fmt_smf_ext.2.1_6" ><assignable>other administrator-configured triggers </assignable></selectable><selectable id="fmt_smf_ext.2.1_7" exclusive="yes" > no other triggers</selectable></selectables>. + The TSF shall offer <selectables> + <selectable id="s-smf-wipe-pro">wipe of protected data</selectable> + <selectable id="s-smf-wipe-sen">wipe of sensitive data</selectable> + <selectable id="s-smf-ext-2-rem-ent-app">remove Enterprise applications</selectable> + <selectable>remove all device-stored Enterprise resource data</selectable> + <selectable>remove Enterprise secondary authentication data</selectable> + <selectable><assignable>list other available remediation + actions</assignable></selectable> + </selectables> upon unenrollment and <selectables> + <selectable><assignable>other administrator-configured + triggers</assignable></selectable> + <selectable exclusive="yes"> no other triggers</selectable> + </selectables>. + + The TSF shall offer <assignable>list of remediation actions</assignable> + upon unenrollment and + <assignable>list of triggers</assignable>. Unenrollment may consist of removing the MDM agent or removing the administrator’s policies. The functions in the selection are remediation actions that TOE may provide (perhaps via APIs) to the administrator (perhaps via an MDM @@ -4700,14 +9384,14 @@ The evaluator shall exercise the TSF configuration as the administrator and Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well. - If is selected it is assumed that the sensitive data is wiped as well. - However, if is selected, it does not imply that all non-TSF data (protected data) + If is selected it is assumed that the sensitive data is wiped as well. + However, if is selected, it does not imply that all non-TSF data (protected data) is wiped. - If or is selected the wipe must be in accordance with FCS_CKM_EXT.5.1. + If or is selected the wipe must be in accordance with FCS_CKM_EXT.5.1. Thus cryptographically wiping the device is an acceptable remediation action. - - The evaluator shall verify that the TSS describes all available remediation + + The evaluator shall verify that the TSS describes all available remediation actions, when they are available for use, and any other administrator-configured triggers. The evaluator shall verify that the TSS describes how the remediation actions are provided to the administrator. @@ -4719,20 +9403,24 @@ The evaluator shall exercise the TSF configuration as the administrator and be an application with administrator access. - - Unenrollment, Initiation of unenrollment - Identity of administrator Remediation action performed, failure of accepting command to unenroll - + + Unenrollment, Initiation of unenrollment + Identity of administrator Remediation action performed, failure of accepting command to unenroll + - - + + requires the TSF to provide users with a list of administrators and their specified functions. There are no management activities foreseen. There are no auditable events foreseen. FMT_SMR.1 Security Roles + + - The TSF shall provide a mechanism that allows users to view a list of currently authorized administrators and the management functions that each administrator is authorized to perform. - + The TSF shall provide a mechanism that allows users to view a list of currently + authorized administrators and the management functions that each administrator is + authorized to perform. + There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. The evaluator shall cause the TOE to be enrolled into management. The @@ -4741,30 +9429,44 @@ The evaluator shall exercise the TSF configuration as the administrator and is authorized to perform. - + -
    - -
    - - + + + + + This family defines requirements for protecting against common types of software exploitation techniques. + + + + + + requires the TSF to support address space layout randomization (ASLR). There are no management activities foreseen. There are no auditable events foreseen. FCS_RBG_EXT.1 Random Bit Generation + + - The TSF shall provide address space layout randomization ASLR to applications. + The TSF shall provide address space layout randomization ASLR to applications. + - The base address of any user-space memory mapping will consist of at least 8 unpredictable bits. + The base address of any user-space memory mapping will consist of at least 8 + unpredictable bits. The 8 unpredictable bits may be provided by the TSF RBG (as specified in FCS_RBG_EXT.1) but is not required. - + The evaluator shall ensure that the TSS section of the ST describes how the 8 bits are generated and provides a justification as to why those bits are - unpredictable. - There are no guidance evaluation activities for this component. + unpredictable. + + There are no guidance evaluation activities for this component. + Evaluation Activity Note: The following test require the developer to + provide access to a test platform that provides the evaluator with tools that are + typically not found on consumer Mobile Device products. The evaluator must select 3 apps included with the TSF. These must include any web browser or mail client included with the TSF. For each of these apps, @@ -4779,39 +9481,45 @@ The evaluator shall exercise the TSF configuration as the administrator and - + - - + + requires the TSF to enforce access permissions on physical memory. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. + + - The TSF shall be able to enforce read, write, and execute permissions on every page of physical memory. - + The TSF shall be able to enforce read, write, and execute permissions on every + page of physical memory. + The evaluator shall ensure that the TSS describes of the memory management unit (MMU), and ensures that this description documents the ability of the MMU to enforce read, write, and execute permissions on all pages of virtual memory. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component. - - + + - - + + requires the TSF to implement stack overflow protection. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. + + - TSF processes that execute in a non-privileged execution domain on the application processor shall implement stack-based buffer overflow protection. + TSF processes that execute in a non-privileged execution domain on the + application processor shall implement stack-based buffer overflow protection. A "non-privileged execution domain" refers to the user mode (as opposed to kernel mode, for instance) of the processor. While not all TSF processes must implement such protection, it is expected that most of the processes (to include libraries used by TSF processes) do implement buffer overflow protections. - + The evaluator shall determine that the TSS contains a description of stack-based buffer overflow protections implemented in the TSF software which runs in the non-privileged execution mode of the application processor. The exact implementation @@ -4826,19 +9534,21 @@ The evaluator shall exercise the TSF configuration as the administrator and There are no test evaluation activities for this component. - + - - + + requires the TSF to protect itself from untrusted subjects and enforce address space isolation. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. + + - The TSF shall protect itself from modification by untrusted subjects. + The TSF shall protect itself from modification by untrusted subjects. - The TSF shall enforce isolation of address space between applications. + The TSF shall enforce isolation of address space between applications. In addition to the TSF software (e.g., kernel image, device drivers, trusted applications) that resides in storage, the execution context (e.g., address space, processor registers, per-process environment variables) of the software @@ -4854,8 +9564,8 @@ The evaluator shall exercise the TSF configuration as the administrator and unauthorized users or untrusted software or hardware which may have access to the device over a wired interface, either when the device is in a screen-locked state or booted into auxiliary boot modes. - - The evaluator shall ensure that the TSS describes the mechanisms that are in + + The evaluator shall ensure that the TSS describes the mechanisms that are in place that prevents non-TSF software from modifying the TSF software or TSF data that governs the behavior of the TSF. These mechanisms could range from hardware-based means (e.g. "execution rings" and memory management functionality); @@ -4886,9 +9596,17 @@ The evaluator shall exercise the TSF configuration as the administrator and tools is not sufficient justification. Examples of sufficient justification include auditing of changes, cryptographic verification in the form of a digital signature or hash, disabling the auxiliary boot modes, and access control mechanisms that - prevent writing to files or flashing partitions. + prevent writing to files or flashing partitions. + There are no guidance evaluation activities for this component. + Evaluation Activity Note: The following tests require the vendor to + provide access to a test platform that provides the evaluator with tools that are + typically not found on consumer Mobile Device products. In addition, the vendor + provides a list of files (e.g., system files, libraries, configuration files, audit + logs) that make up the TSF data. This list could be organized by folders/directories + (e.g., /usr/sbin, /etc), as well as individual files that may exist outside of the + identified directories. The evaluator shall create and load an app onto the Mobile Device. This app shall attempt to traverse over all file systems and report any locations to @@ -4897,7 +9615,7 @@ The evaluator shall exercise the TSF configuration as the administrator and configuration files, key material, or another untrusted application’s image/data. For example, it is acceptable for a trusted photo editor app to have access to the data created by the camera app, but a calculator application shall - not have access to the pictures. + not have access to the pictures. For each available auxiliary boot mode, the evaluator shall attempt to modify a TSF file of their choosing using the software or hardware tools described in the TSS. The evaluator shall verify that the modification @@ -4906,31 +9624,38 @@ The evaluator shall exercise the TSF configuration as the administrator and - + - - + + requires the TSF to provide ASLR to the kernel. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. + + - The TSF shall provide address space layout randomization (ASLR) to the kernel. + The TSF shall provide address space layout randomization (ASLR) to the kernel. + - The base address of any kernel-space memory mapping will consist of<assignable>number greater than or equal to 4</assignable>unpredictable bits. + + The base address of any kernel-space memory mapping will consist of + <assignable>number greater than or equal to 4</assignable> + unpredictable bits. + The unpredictable bits may be provided by the TSF RBG (as specified in FCS_RBG_EXT.1). - + The evaluator shall ensure that the TSS section of the ST describes how the bits are generated and provides a justification as to why those bits are - unpredictable. + unpredictable. + There are no guidance evaluation activities for this component. - - The following test require the developer to + Evaluation Activity Note: The following test require the developer to provide access to a test platform that provides the evaluator with tools that are - typically not found on consumer Mobile Device products. + typically not found on consumer Mobile Device products. The evaluator shall reboot the TOE six times. For each of these reboots, the evaluator shall examine memory mapping locations of the kernel. The evaluator must ensure that for at least five reboots the memory mappings are not placed in the same location on @@ -4939,22 +9664,29 @@ The evaluator shall exercise the TSF configuration as the administrator and - + - - + + requires the TSF to prevent physical memory from being both writable and executable. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. + + - The TSF shall prevent write and execute permissions from being simultaneously granted to any page of physical memory<selectables><selectable id="fpt_aex_ext.6.1_1" >with no exceptions</selectable><selectable id="fpt_aex_ext.6.1_3" ><assignable>specific exceptions </assignable></selectable></selectables>. + The TSF shall prevent write and execute permissions from being simultaneously + granted to any page of physical memory <selectables> + <selectable>with no exceptions</selectable> + <selectable> + <assignable>specific exceptions</assignable></selectable> + </selectables>. Memory used for just-in-time (JIT) compilation is anticipated as an exception in this requirement; if so, the ST author must address how this exception is permitted. It is expected that the memory management unit will transition the system to a non-operational state if any violation is detected in kernel memory space. - + The evaluator shall ensure that the TSS describes how the operating system of the application processor prevents all processes executing in a non-privileged execution domain from achieving write and execute permissions on any page of memory (with only @@ -4966,22 +9698,26 @@ The evaluator shall exercise the TSF configuration as the administrator and There are no test evaluation activities for this component. - + - - + + requires the TSF to support heap-based buffer overflow protection. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. + + - The TSF shall include heap-based buffer overflow protections in the runtime environment it provides to processes that execute on the application processor. + The TSF shall include heap-based buffer overflow protections in the runtime + environment it provides to processes that execute on the application + processor. These heap-based buffer overflow protections are expected to ensure the integrity of heap metadata such as memory addresses or offsets recorded by the heap implementation to manage memory blocks. This includes chunk headers, look-aside lists, and other data structures used to track the state and location of memory blocks managed by the heap. - + The evaluator shall verify that the TSS enumerates the heap implementations provided to userspace processes. The evaluator shall ensure that the TSS lists all types of heap metadata and identifies how the integrity of each type of metadata is @@ -4998,32 +9734,52 @@ The evaluator shall exercise the TSF configuration as the administrator and allowed. - + - - + + + This family defines requirements for separation of baseband and application processor execution. + + + + + + requires the TSF to enforce separation between baseband and application processor execution except through application processor mechanisms. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. + - The TSF shall prevent code executing on any baseband processor (BP) from accessing application processor (AP) resources except when mediated by the AP. - These resources include:Volatile and non-volatile memoryControl of and data from integrated and non-integrated peripherals (e.g. USB - controllers, touch screen controllers, LCD controller, codecs)Control of and data from integrated and non-integrated I/O sensors (e.g. + The TSF shall prevent code executing on any baseband processor (BP) from + accessing application processor (AP) resources except when mediated by the AP. + These resources include: + + Volatile and non-volatile memory + Control of and data from integrated and non-integrated peripherals (e.g. USB + controllers, touch screen controllers, LCD controller, codecs) + Control of and data from integrated and non-integrated I/O sensors (e.g. camera, light, microphone, GPS, accelerometers, geomagnetic field - sensors) Mobile devices are becoming increasingly complex having an application + sensors) + + Mobile devices are becoming increasingly complex having an application processor that runs an operating system and user applications and separate - baseband processors that handle cellular and other wireless network connectivity. The application processor within most modern Mobile Devices is a system on a + baseband processors that handle cellular and other wireless network connectivity. + + The application processor within most modern Mobile Devices is a system on a chip (SoC) that integrates, for example, CPU/GPU cores and memory interface - electronics into a single, power-efficient package.Baseband processors are becoming increasingly complex themselves delivering + electronics into a single, power-efficient package. + Baseband processors are becoming increasingly complex themselves delivering voice encoding alongside multiple independent radios (LTE, Wi-Fi, Bluetooth, FM, - GPS) in a single package containing multiple CPUs and DSPs. Thus, the baseband processors in these requirements include such + GPS) in a single package containing multiple CPUs and DSPs. + + Thus, the baseband processors in these requirements include such integrated SoCs and include any radio processors (integrated or not) on the Mobile Device. All other requirements mostly, except where noted, apply to firmware/software on the application processor, but future requirements (notably, all Integrity, Access Control, and Anti-Exploitation requirements) will apply to application processors and baseband processors. - + The evaluator shall ensure that the TSS section of the ST describes at a high level how the processors on the Mobile Device interact, including which bus protocols they use to communicate, any other devices operating on that bus @@ -5036,16 +9792,28 @@ The evaluator shall exercise the TSF configuration as the administrator and There are no test evaluation activities for this component. - + - - + + + This family defines requirements for limiting Bluetooth capabilities without user action. + + + + + + requires the TSF to maintain a disabled by default posture for Bluetooth profiles. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. + + - The TSF shall disable support for<assignable>list of Bluetooth profiles</assignable>Bluetooth profiles when they are not currently being used by an application on the Mobile Device, and shall require explicit user action to enable them. + The TSF shall disable support for <assignable>list of Bluetooth + profiles</assignable> Bluetooth profiles when they are not currently being used by + an application on the Mobile Device, and shall require explicit user action to enable + them. Some Bluetooth services incur more serious consequences if unauthorized remote devices gain access to them. Such services should be protected by measures like disabling support for the associated Bluetooth profile unless it is @@ -5058,14 +9826,11 @@ The evaluator shall exercise the TSF configuration as the administrator and indicating readiness to transfer an object. After completion of the object transfer, support for the OBEX profile should be suspended until the next time the user requests its use. - + The evaluator shall ensure that the TSS lists all Bluetooth profiles that are disabled while not in use by an application and which need explicit user action in order to become enabled. - There are no guidance evaluation activities for this component. - - - The evaluator shall perform the following tests: + There are no guidance evaluation activities for this component.The evaluator shall perform the following tests: While the service is not in active use by an application on the TOE, the evaluator shall attempt to discover a service associated with a "protected" Bluetooth profile (as specified by the requirement) on the TOE via a Service @@ -5074,7 +9839,7 @@ The evaluator shall exercise the TSF configuration as the administrator and shall attempt to gain remote access to the service from a device that does not currently have a trusted device relationship with the TOE. The evaluator shall verify that this attempt fails due to the unavailability of the service and - profile. + profile. The evaluator shall repeat Test 1 with a device that currently has a trusted device relationship with the TOE and verify that the same behavior is exhibited. @@ -5082,45 +9847,69 @@ The evaluator shall exercise the TSF configuration as the administrator and - + - - + + + This family defines requirements for JTAG interface access limitations. + + + + + + requires the TSF to specify the mechanism used to restrict access to its JTAG interface. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. + - The TSF shall<selectables><selectable id="s-jtag-kill-hw" >disable access through hardware</selectable><selectable id="s-jtag-control-key" >control access by a signing key</selectable></selectables>to JTAG. + The TSF shall <selectables> + <selectable id="s-jtag-kill-hw">disable access through hardware</selectable> + <selectable id="s-jtag-control-key">control access by a signing key</selectable> + </selectables> to JTAG. + + The TSF shall <assignable>list access control mechanisms</assignable> to JTAG. + This requirement means that access to JTAG must be disabled either through hardware or restricted through the use of a signing key. - - If is selected: The evaluator shall + + If is selected: The evaluator shall examine the TSS to determine the location of the JTAG ports on the TSF, to include the order of the ports (i.e. Data In, Data Out, Clock, etc.). - If is selected: The evaluator shall examine + If is selected: The evaluator shall examine the TSS to determine how access to the JTAG is controlled by a signing key. The evaluator shall examine the TSS to determine when the JTAG can be accessed, i.e. what has the access to the signing key. There are no guidance evaluation activities for this component. - Evaluation Activity Note: The following test requires the developer to + + Evaluation Activity Note: The following test requires the developer to provide access to a test platform that provides the evaluator with chip level - access. If is + access. If is selected: The evaluator shall connect a packet analyzer to the JTAG ports. The evaluator shall query the JTAG port for its device ID and confirm that the - device ID cannot be retrieved. + device ID cannot be retrieved. + - - - - + + + + + This family defines requirements for protecting plaintext keys. + + + + + requires the TSF to avoid storage of plaintext keys in readable memory. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. + - The TSF shall not store any plaintext key material in readable non-volatile memory. + The TSF shall not store any plaintext key material in readable non-volatile + memory. The intention of this requirement is that the TOE will not write plaintext keying material to persistent storage. For the purposes of this requirement, keying material refers to authentication data, passwords, secret/private @@ -5129,9 +9918,18 @@ The evaluator shall exercise the TSF configuration as the administrator and value derived from passwords. Thus, the TOE cannot store plaintext password hashes for comparison purposes before protected data is decrypted, and the TOE should use key derivation and decryption to verify the Password Authentication Factor. - If is selected in FIA_UAU.5.1 keying + If is selected in FIA_UAU.5.1 keying material also refers to the PIN/password used as part of the hybrid authentication. - + The evaluator shall consult the TSS section of the ST in performing the Evaluation Activities for this requirement. In performing their review, the evaluator shall determine that the TSS contains a description of the activities that @@ -5147,33 +9945,48 @@ The evaluator shall exercise the TSF configuration as the administrator and (e.g., regeneration of the keys) ensure that no unencrypted key material is present in persistent storage. The evaluator shall review the TSS to determine that it makes a case that key material is not written unencrypted to the - persistent storage. + persistent storage. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component. - + - - + + requires the TSF to prevent transmitting plaintext key material to the operational environment. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. + - The TSF shall not transmit any plaintext key material outside the security boundary of the TOE. + The TSF shall not transmit any plaintext key material outside the security + boundary of the TOE. The intention of this requirement is to prevent the logging of plaintext key information to a service that transmits the information off-device. For the purposes of this requirement, key material refers to keys, passwords, and other - material that is used to derive keys. - If is selected in FIA_UAU.5.1 - keying material also refers to the PIN/password used as part of + material that is used to derive keys. + If is selected in FIA_UAU.5.1 + keying material also refers to the PIN/password used as part of the hybrid authentication. In the future, this requirement will apply to symmetric and asymmetric private keys stored in the TOE secure key storage where applications are outside the boundary of the TOE. Thus, the TSF will be required to provide cryptographic key operations (signature, encryption, and decryption) on behalf of applications (FCS_SRV_EXT.2.1) that have access to those keys. - + The evaluator shall consult the TSS section of the ST in performing the Evaluation Activities for this requirement. The evaluator shall ensure that the TSS describes the TOE security boundary. The cryptographic module may very well be a particular @@ -5186,26 +9999,37 @@ The evaluator shall exercise the TSF configuration as the administrator and that no unencrypted key material is transmitted outside the security boundary of the TOE. The evaluator shall review the TSS to determine that it makes a case that key material is not transmitted outside the security boundary of - the TOE. + the TOE. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component. - + - - + + requires the TSF to prevent the export of plaintext keys. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. + - The TSF shall ensure it is not possible for the TOE users to export plaintext keys. + The TSF shall ensure it is not possible for the TOE users to export plaintext + keys. Plaintext keys include DEKs, KEKs, and all keys stored in the secure key storage (FCS_STG_EXT.1). The intent of this requirement is to prevent the plaintext keys from being exported during a backup authorized by the TOE user or administrator. - + The ST author will provide a statement of their policy for handling and protecting keys. The evaluator shall check to ensure the TSS describes a policy in line with not exporting either plaintext DEKs, KEKs, or keys stored in the secure @@ -5214,28 +10038,52 @@ The evaluator shall exercise the TSF configuration as the administrator and There are no test evaluation activities for this component. - + - - + + + This family defines requirements for generation of notifications in response to completed self-tests. + + + + + requires the TSF to become non-operational when certain failures occur. There are no management activities foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - Measurement of TSF software. - FPT_TST_EXT.1 TSF Cryptographic Functionality Testing + + Measurement of TSF software. + + + FPT_TST_EXT.1 TSF Cryptographic Functionality Testing FPT_TST_EXT.2 TSF Integrity Checking + - The TSF shall transition to non-operational mode and<selectables><selectable id="fpt_not_ext.1.1_1" >log failures in the audit record</selectable><selectable id="fpt_not_ext.1.1_2" >notify the administrator</selectable><selectable id="fpt_not_ext.1.1_4" ><assignable>other actions </assignable></selectable><selectable id="fpt_not_ext.1.1_5" exclusive="yes" >no other actions</selectable></selectables>when the following types of failures occur: <htm:ul><htm:li>failures of the self-tests</htm:li><htm:li>TSF software integrity verification failures</htm:li><htm:li><selectables><selectable id="fpt_not_ext.1.1_6" exclusive="yes" >no other failures</selectable><selectable id="fpt_not_ext.1.1_8" ><assignable>other failures </assignable></selectable></selectables></htm:li></htm:ul> - + The TSF shall transition to non-operational mode and <selectables> + <selectable>log failures in the audit record</selectable> + <selectable>notify the administrator</selectable> + <selectable> + <assignable>other actions</assignable></selectable> + <selectable exclusive="yes">no other actions</selectable> + </selectables> when the following types of failures occur: <htm:ul> + <htm:li>failures of the self-tests</htm:li> + <htm:li>TSF software integrity verification failures</htm:li> + <htm:li><selectables> + <selectable exclusive="yes">no other failures</selectable> + <selectable> + <assignable>other failures</assignable></selectable> + </selectables></htm:li> + </htm:ul> + + The evaluator shall verify that the TSS describes critical failures that may occur and the actions to be taken upon these critical failures. There are no guidance evaluation activities for this component. - - The following test require the developer to + Evaluation Activity Note: The following test require the developer to provide access to a test platform that provides the evaluator with tools that are - typically not found on consumer Mobile Device products. + typically not found on consumer Mobile Device products. The evaluator shall use a tool provided by the developer to modify files and processes in the system that correspond to critical failures specified in the second list. The evaluator shall verify that creating these critical failures @@ -5245,31 +10093,28 @@ The evaluator shall exercise the TSF configuration as the administrator and - - - - Measurement of TSF software - none - - - - - Integrity verification value - No additional information - - - - - - + + Measurement of TSF softwarenone + Integrity verification valueNo additional information + + + + requires the TSF to generate and sign software integrity verification values. The following actions could be considered for the management functions in FMT: - Retrieval of TSF software integrity verification values. + + Retrieval of TSF software integrity verification values. + + There are no auditable events foreseen. FCS_COP.1 Cryptographic Operation + - The TSF shall<selectables><selectable id="fpt_not_ext.2.1_1" >audit</selectable><selectable id="fpt_not_ext.2.1_2" >provide the administrator with</selectable></selectables>TSF-software integrity verification values. + The TSF shall <selectables> + <selectable>audit</selectable> + <selectable>provide the administrator with</selectable> + </selectables> TSF-software integrity verification values. These notifications are typically called remote attestation and these integrity values are typically called measurements. The integrity values are calculated from hashes of critical memory and values, including executable code. The @@ -5279,16 +10124,19 @@ The evaluator shall exercise the TSF configuration as the administrator and The evaluator shall verify that the TSS describes which critical memory is measured for these integrity values and how the measurement is performed (including which TOE software performs these generates these values, how that software accesses - the critical memory, and which algorithms are used). + the critical memory, and which algorithms are used). + If the integrity values are provided to the administrator, the evaluator shall verify that the AGD guidance contains instructions for retrieving these values and information for interpreting them. For example, if multiple measurements are taken, what those measurements are and how changes to those values relate to changes - in the device state. + in the device state. + - - The - evaluator shall repeat the following test for each measurement: + Evaluation Activity Note: The following test may require the developer + to provide access to a test platform that provides the evaluator with tools that are + typically not found on consumer Mobile Device products. The + evaluator shall repeat the following test for each measurement: The evaluator shall boot the device in an approved state and record the measurement taken (either from the log or by using the administrative guidance to retrieve the value via an MDM Agent). The evaluator shall modify the critical @@ -5310,9 +10158,7 @@ The evaluator shall exercise the TSF configuration as the administrator and the method of associating the certificate with a particular device manufacturer and model. There are no guidance evaluation activities for this component. - - - The evaluator shall perform the following test: + The evaluator shall perform the following test: The evaluator shall write, or the developer shall provide, a management application that queries either the audit logs or the measurements. The evaluator shall verify that the responses to these queries are signed and verify @@ -5321,13 +10167,12 @@ The evaluator shall exercise the TSF configuration as the administrator and - + - - + - The TSF shall be able to provide reliable time stamps <htm:b>for its own use</htm:b> . - + The TSF shall be able to provide reliable time stamps <refinement>for its own use</refinement>. + The evaluator shall examine the TSS to ensure that it lists each security function that makes use of time. The TSS provides a description of how the time is maintained and considered reliable in the context of each of the time related @@ -5344,24 +10189,38 @@ The evaluator shall exercise the TSF configuration as the administrator and - + - - + + + This family defines requirements for execution of self-tests that are not addressed by FPT_TST in CC Part 2. + + + + + + requires the TSF to run self-test at start-up to verify correct operation. There are no management activities foreseen. - The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:Initiation of self-test.Failure of self-test. + The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: + Initiation of self-test. + Failure of self-test. + + FCS_COP.1 Cryptographic Operation + + - The TSF shall run a suite of self-tests during initial start-up (on power on) to demonstrate the correct operation of all cryptographic functionality. + The TSF shall run a suite of self-tests during initial start-up (on power on) to + demonstrate the correct operation of all cryptographic functionality. This requirement may be met by performing known answer tests or pair-wise consistency tests. The self-tests must be performed before the cryptographic functionality is exercised (for example, during the initialization of a process that utilizes the functionality). The cryptographic functionality includes the cryptographic operations in FCS_COP, the key generation functions in FCS_CKM, and the random bit generation in FCS_RBG_EXT. - + The evaluator shall examine the TSS to ensure that it specifies the self-tests that are performed at start-up. This description must include an outline of the test procedures conducted by the TSF (e.g., rather than saying "memory is tested", a @@ -5378,69 +10237,35 @@ The evaluator shall exercise the TSF configuration as the administrator and There are no test evaluation activities for this component. - - Initiation of self-test - - - Failure of self-test - - - Algorithm that caused the failure - No additional information - - - - - - + Initiation of self-test + + Failure of self-test + Algorithm that caused the failureNo additional information + + + + + - The TSF shall verify the integrity of<assignable>TSF data</assignable>stored in mutable media prior to its execution through the use of<assignable>cryptographic or immutable hardware mechanism</assignable>. - - - - - - The TSF shall verify the integrity of<selectables><selectable id="s-all-exe" >all executable code</selectable><selectable id="fpt_tst_ext.2.1_POSTKERNEL_2" ><assignable>subset of executable code </assignable></selectable></selectables>stored in mutable media prior to its execution through the use of<selectables><selectable id="fpt_tst_ext.2.1_POSTKERNEL_3" >a digital signature using an immutable hardware asymmetric - key</selectable><selectable id="fpt_tst_ext.2.1_POSTKERNEL_4" >an immutable hardware hash of an asymmetric key</selectable><selectable id="fpt_tst_ext.2.1_POSTKERNEL_5" >an immutable hardware hash</selectable><selectable id="fpt_tst_ext.2.1_POSTKERNEL_6" >a digital signature using a hardware-protected asymmetric - key</selectable><selectable id="fpt_tst_ext.2.1_POSTKERNEL_7" >hardware-protected hash</selectable></selectables>. - All executable code covered in this requirement is executed - after the kernel is loaded. If "all executable code in mutable - media" is verified, implementation in hardware or in read-only memory is a natural - logical consequence. At this time, the verification of software - executed on other processors stored in mutable media is not required; however, it may - be added in the first assignment. If all executable code (including bootloaders, - kernel, device drivers, pre-loaded applications, user-loaded applications, and - libraries) is verified, "all executable code stored in mutable media" should be - selected. - - There are no TSS evaluation activities for this component. - There are no guidance evaluation activities for this component. - The evaluation activity shall be completed in conjunction with FPT_TST_EXT.2/PREKERNEL - for all executable code specified. + The TSF shall verify the integrity of <assignable>TSF data</assignable> stored in mutable media + prior to its execution through the use of <assignable>cryptographic or immutable hardware mechanism</assignable>. + + - - - - Detected integrity violation - none - - - - - The TSF code file that cause the integrity violation - No additional information - - - - - + + - The TSF shall verify the integrity of [ <htm:i>the bootchain up through the Application - Processor OS kernel</htm:i> ] stored in mutable media prior to its execution through the use of<selectables><selectable id="fpt_tst_ext.2.1_PREKERNEL_1" >a digital signature using an immutable hardware asymmetric - key</selectable><selectable id="fpt_tst_ext.2.1_PREKERNEL_2" >an immutable hardware hash of an asymmetric key</selectable><selectable id="fpt_tst_ext.2.1_PREKERNEL_3" >an immutable hardware hash</selectable><selectable id="fpt_tst_ext.2.1_PREKERNEL_4" >a digital signature using a hardware-protected asymmetric - key</selectable></selectables>. + The TSF shall verify the integrity of [<htm:i>the bootchain up through the Application + Processor OS kernel</htm:i>] stored in mutable media prior to its execution through the use of <selectables> + <selectable>a digital signature using an immutable hardware asymmetric + key</selectable> + <selectable>an immutable hardware hash of an asymmetric key</selectable> + <selectable>an immutable hardware hash</selectable> + <selectable>a digital signature using a hardware-protected asymmetric + key</selectable> + </selectables>. The bootchain of the TSF is the sequence of firmware and software, including ROM, bootloaders, and kernel, which ultimately result in loading the kernel on the Application Processor, regardless of which processor executes that @@ -5453,7 +10278,7 @@ The evaluator shall exercise the TSF configuration as the administrator and The cryptographic mechanism used to verify the (initial) mutable executable code must be protected, such as being implemented in hardware or in read-only memory (ROM). - + The evaluator shall verify that the TSS section of the ST includes a description of the boot procedures, including a description of the entire bootchain, of the software for the TSF’s Application Processor. The evaluator shall ensure that before @@ -5472,19 +10297,21 @@ The evaluator shall exercise the TSF configuration as the administrator and code through the kernel is verified before each execution. There are no guidance evaluation activities for this component. - - The - evaluator shall perform the following tests: + Evaluation Activity Note: The following tests require the vendor to + provide access to a test platform that provides the evaluator with tools that are + typically not found on consumer Mobile Device products. The + evaluator shall perform the following tests: The evaluator shall perform actions to cause TSF software to load and observe that the integrity mechanism does not flag any executables as containing integrity errors and that the TOE properly boots. + The evaluator shall modify a TSF executable that is integrity protected and cause that executable to be successfully loaded by the TSF. The evaluator observes that an integrity violation is triggered and the TOE does not boot. (Care must be taken so that the integrity violation is determined to be the cause of the failure to load the module, and not the fact that the module was modified so that it was rendered unable to run because its format was - corrupt). + corrupt). [conditional] If the ST author indicates that the integrity verification is performed using a public key, the evaluator shall verify that the update mechanism includes a certificate validation according to FIA_X509_EXT.1. The @@ -5498,72 +10325,108 @@ The evaluator shall exercise the TSF configuration as the administrator and - - Start-up of TOE - - - - - Detected integrity violation - none - - - - - The TSF code file that caused the integrity violation - No additional information - - - + Start-up of TOE + + Detected integrity violationnone + The TSF code file that caused the integrity violationNo additional information + + + + + The TSF shall verify the integrity of <selectables> + <selectable id="s-all-exe">all executable code</selectable> + <selectable><assignable>subset of executable code</assignable></selectable> + </selectables> stored in mutable media prior to its execution through the use of <selectables> + <selectable>a digital signature using an immutable hardware asymmetric + key</selectable> + <selectable>an immutable hardware hash of an asymmetric key</selectable> + <selectable>an immutable hardware hash</selectable> + <selectable>a digital signature using a hardware-protected asymmetric + key</selectable> + <selectable>hardware-protected hash</selectable> + </selectables>. + All executable code covered in this requirement is executed + after the kernel is loaded. If "all executable code in mutable + media" is verified, implementation in hardware or in read-only memory is a natural + logical consequence. At this time, the verification of software + executed on other processors stored in mutable media is not required; however, it may + be added in the first assignment. If all executable code (including bootloaders, + kernel, device drivers, pre-loaded applications, user-loaded applications, and + libraries) is verified, "all executable code stored in mutable media" should be + selected. + + There are no TSS evaluation activities for this component. + There are no guidance evaluation activities for this component. + The evaluation activity shall be completed in conjunction with FPT_TST_EXT.2/PREKERNEL + for all executable code specified. + + + + Detected integrity violationNone + The TSF code file that cause the integrity violationNo additional information + - - + + requires the TSF to validate a code signing certificate before the associated code is executed. There are no management activities foreseen. There are no auditable events foreseen. - FPT_TST_EXT.2 TSF Integrity Checking - FIA_X509_EXT.1 X.509 Validation of Certificates + FPT_TST_EXT.2 TSF Integrity Checking + FIA_X509_EXT.1 X.509 Validation of Certificates FIA_X509_EXT.2 X.509 Certificate Authentication + + - The TSF shall not execute code if the code signing certificate is deemed invalid. + The TSF shall not execute code if the code signing certificate is deemed invalid. Certificates may optionally be used for code signing for integrity verification (FPT_TST_EXT.2.1/PREKERNEL). - If is selected in FIA_X509_EXT.2.1, FPT_TST_EXT.3 must be included in the + If is selected in FIA_X509_EXT.2.1, FPT_TST_EXT.3 must be included in the ST. Validity is determined by the certificate path, the expiration date, and the revocation status in accordance with RFC 5280. - + There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. Testing for this component is performed in conjunction with the Evaluation Activities for FPT_TST_EXT.2.1/PREKERNEL. - - - - + + + + + This family defines requirements for trusted updates. + + + + + + requires the TSF to provide authorized users the ability to query the version of the TOE hardware, TOE software, and installed applications. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. + + - The TSF shall provide authorized users the ability to query the current version of the TOE firmware/software. + The TSF shall provide authorized users the ability to query the current version + of the TOE firmware/software. - The TSF shall provide authorized users the ability to query the current version of the hardware model of the device. + The TSF shall provide authorized users the ability to query the current version + of the hardware model of the device. The current version of the hardware model of the device is an identifier that is sufficient to indicate (in tandem with manufacturer documentation) the hardware which comprises the device. - The TSF shall provide authorized users the ability to query the current version of installed mobile applications. + The TSF shall provide authorized users the ability to query the current version + of installed mobile applications. The current version of mobile applications is the name and published version number of each installed mobile application. - - The evaluator shall establish a test environment consisting of the Mobile + The evaluator shall establish a test environment consisting of the Mobile Device and any supporting software that demonstrates usage of the management functions. This can be test software from the developer, a reference implementation of management software from the developer, or other commercially available software. The @@ -5574,24 +10437,42 @@ The evaluator shall exercise the TSF configuration as the administrator and Using the AGD guidance provided, the evaluator shall test that the - administrator and user can query: The current version of the TSF operating system and any firmware that - can be updated separatelyThe hardware model of the TSFThe current version of all installed mobile applications - - + administrator and user can query: + The current version of the TSF operating system and any firmware that + can be updated separately + The hardware model of the TSF + The current version of all installed mobile applications + + + The evaluator must review manufacturer documentation to ensure that the + hardware model identifier is sufficient to identify the hardware which comprises the + device. - + - - + + requires the TSF to ensure that system software updates are digitally signed prior to installation. The following actions could be considered for the management functions in FMT: - Updating of system software. + + Updating of system software. + + The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - Success or failure of signature verification for applications. + + Success or failure of signature verification for applications. + + FCS_COP.1 Cryptographic Operation + - The TSF shall verify software updates to the Application Processor system software and<selectables><selectable id="fpt_tud_ext.2.1_2" ><assignable>other processor system software </assignable></selectable><selectable id="fpt_tud_ext.2.1_3" >no other processor system software</selectable></selectables>using a digital signature verified by the manufacturer trusted key prior to installing those updates. + The TSF shall verify software updates to the Application Processor system + software and <selectables> + <selectable><assignable>other processor system software</assignable></selectable> + <selectable>no other processor system software</selectable> + </selectables> using a digital signature verified by the manufacturer trusted key + prior to installing those updates. The digital signature mechanism is implemented in accordance with FCS_COP.1.1/SIGN. At this time, this requirement does not require verification of software updates to the software operating outside the @@ -5603,21 +10484,31 @@ The evaluator shall exercise the TSF configuration as the administrator and interface. - The TSF shall<selectables><selectable id="fpt_tud_ext.2.2_1" >never update</selectable><selectable id="fpt_tud_ext.2.2_2" >update only by verified software</selectable></selectables>the TSF boot integrity<selectables><selectable id="fpt_tud_ext.2.2_3" >key</selectable><selectable id="fpt_tud_ext.2.2_4" >hash</selectable></selectables>. + The TSF shall <selectables> + <selectable>never update</selectable> + <selectable>update only by verified software</selectable> + </selectables> the TSF boot integrity <selectables> + <selectable>key</selectable> + <selectable>hash</selectable> + </selectables>. The key or hash updated via this requirement is used for verifying software before execution in FPT_TST_EXT.2/PREKERNEL. The key or hash is verified as a part of the digital signature on an update, and the software which performs the update of the key or hash is verified by FPT_TST_EXT.2/PREKERNEL. - The TSF shall verify that the digital signature verification key used for TSF updates<selectables><selectable id="fpt_tud_ext.2.3_1" >is validated to a public key in the Trust Anchor Database</selectable><selectable id="fpt_tud_ext.2.3_2" >matches an immutable hardware public key</selectable></selectables>. + The TSF shall verify that the digital signature verification key used for TSF + updates <selectables> + <selectable>is validated to a public key in the Trust Anchor Database</selectable> + <selectable>matches an immutable hardware public key</selectable> + </selectables>. The ST author must indicate the method by which the signing key for system software updates is limited and, if selected in FPT_TUD_EXT.2.3, must indicate how this signing key is protected by the hardware. If certificates are used, certificates are validated for the purpose of software updates in accordance with FIA_X509_EXT.1 and should be selected in FIA_X509_EXT.2.1. Additionally, FPT_TUD_EXT.4 must be included in the ST. - + The evaluator shall verify that the TSS section of the ST describes all TSF software update mechanisms for updating the system software. The evaluator shall verify that the description includes a digital signature verification of the @@ -5627,6 +10518,8 @@ The evaluator shall exercise the TSF configuration as the administrator and software/firmware responsible for each stage is indicated and that the stages which perform signature verification of the update are identified. + + The evaluator shall verify that the TSS describes the method by which the digital signature is verified and that the public key used to verify the signature is either hardware-protected or is validated to chain to a public key in @@ -5648,14 +10541,13 @@ The evaluator shall exercise the TSF configuration as the administrator and There are no guidance evaluation activities for this component. - - - The evaluator shall verify that the developer has provided evidence that the - following tests were performed for each available update mechanism: + The evaluator shall verify that the developer has provided evidence that the + following tests were performed for each available update mechanism: The tester shall try to install an update without the digital signature and shall verify that installation fails. The tester shall attempt to install an - update with digital signature, and verify that installation succeeds. + update with digital signature, and verify that installation succeeds. + The tester shall digitally sign the update with a key disallowed by the device and verify that installation fails. The tester shall attempt to install an update signed with the allowed key and verify that installation succeeds. [conditional] The tester shall digitally sign the update with an invalid @@ -5670,30 +10562,38 @@ The evaluator shall exercise the TSF configuration as the administrator and - - Success or failure of signature verification for software updates - - - - + + Success or failure of signature verification for software updates + + + + requires the TSF to ensure that application software updates are digitally signed prior to installation. There are no management activities foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - Success or failure of signature verification for applications. - FIA_X509_EXT.1 X.509 Validation of Certificates + + Success or failure of signature verification for applications. + + + FIA_X509_EXT.1 X.509 Validation of Certificates FIA_X509_EXT.2 X.509 Certificate Authentication + + - The TSF shall verify mobile application software using a digital signature mechanism prior to installation. + The TSF shall verify mobile application software using a digital signature + mechanism prior to installation. This requirement does not necessitate an X.509v3 certificate or certificate validation. X.509v3 certificates and certificate validation are addressed - in . - + in . + The evaluator shall verify that the TSS describes how mobile application software is verified at installation. The evaluator shall ensure that this method uses a digital signature. There are no guidance evaluation activities for this component. + Evaluation Activity Note: The following test does not have to be tested + using the commercial application store. The evaluator shall write, or the developer shall provide access to, an application. The evaluator shall try to install this application without a @@ -5704,54 +10604,64 @@ The evaluator shall exercise the TSF configuration as the administrator and - - Success or failure of signature verification for applications - + + Success or failure of signature verification for applications + - - - - + + + requires the TSF to enforce validity of system software’s code signing certificate prior to installation. There are no management activities foreseen. There are no auditable events foreseen. - FIA_X509_EXT.1 X.509 Validation of Certificates + FIA_X509_EXT.1 X.509 Validation of Certificates FIA_X509_EXT.2 X.509 Certificate Authentication + + - The TSF shall not install code if the code signing certificate is deemed invalid. + The TSF shall not install code if the code signing certificate is deemed invalid. Certificates may optionally be used for code signing of system - software updates (FPT_TUD_EXT.2.3) and of mobile applications ( ). This + software updates (FPT_TUD_EXT.2.3) and of mobile applications (). This element must be included in the ST if certificates are used for either update element. - If either or is selected in FIA_X509_EXT.2.1, + If either or is selected in FIA_X509_EXT.2.1, FPT_TUD_EXT.4 must be included in the ST. Validity is determined by the certificate path, the expiration date, and the revocation status in accordance with RFC 5280. - + There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. Testing for this component is performed in conjunction with the Evaluation Activities for FPT_TUD_EXT.2 and FPT_TUD_EXT.5. - + - - + + requires the TSF to enforce validity of application software’s code signing certificate prior to installation. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: - Configure certificate or public key used to validate digital signature on applications. + + Configure certificate or public key used to validate digital signature on applications. + + There are no auditable events foreseen. - FIA_X509_EXT.1 X.509 Validation of Certificates + FIA_X509_EXT.1 X.509 Validation of Certificates FIA_X509_EXT.2 X.509 Certificate Authentication + + - The TSF shall by default only install mobile applications cryptographically verified by<selectables><selectable id="fpt_tud_ext.5.1_1" >a built-in X.509v3 certificate</selectable><selectable id="fpt_tud_ext.5.1_2" >a configured X.509v3 certificate</selectable></selectables>. + The TSF shall by default only install mobile applications cryptographically + verified by <selectables> + <selectable>a built-in X.509v3 certificate</selectable> + <selectable>a configured X.509v3 certificate</selectable> + </selectables>. The built-in certificate is installed by the manufacturer either at time of manufacture or as a part of system updates. The configured certificate used to verify the signature is set according to FMT_SMF.1 function - . - + . + The evaluator shall verify that the TSS describes how mobile application software is verified at installation. The evaluator shall ensure that this method uses a digital signature by a code signing certificate. @@ -5762,13 +10672,13 @@ The evaluator shall exercise the TSF configuration as the administrator and application. The evaluator shall try to install this application without a digitally signature and shall verify that installation fails. The evaluator shall attempt to install an application digitally signed with an appropriate - certificate, and verify that installation succeeds. + certificate, and verify that installation succeeds. The evaluator shall digitally sign the application with an invalid certificate and verify that application installation fails. The evaluator shall digitally sign the application with a certificate that does not have the Code Signing purpose and verify that application installation fails. This test may be performed in conjunction with the Evaluation Activities for - FIA_X509_EXT.1. + FIA_X509_EXT.1. If necessary, the evaluator shall configure the device to limit the public keys that can sign application software according to the AGD guidance. The evaluator shall digitally sign the application with a certificate disallowed by @@ -5779,64 +10689,85 @@ The evaluator shall exercise the TSF configuration as the administrator and - + - - + + requires the TSF to prevent the intentional rollback of software updates. There are no management activities foreseen. There are no auditable events foreseen. No dependencies. + + - The TSF shall verify that software updates to the TSF are a current or later version than the current version of the TSF. + The TSF shall verify that software updates to the TSF are a current or later + version than the current version of the TSF. A later version has a larger version number. The method for distinguishing newer software versions from older versions is determined by the manufacturer. - + The evaluator shall verify that the TSS describes the mechanism that prevents the TSF from installing software updates that are an older version that the currently - installed version. + installed version. + There are no guidance evaluation activities for this component. - - - The evaluator shall repeat the following tests to cover all allowed software + The evaluator shall repeat the following tests to cover all allowed software update mechanisms as described in the TSS. For example, if the update mechanism replaces an entire partition containing many separate code files, the evaluator does - not need to repeat the test for each individual file. + not need to repeat the test for each individual file. The evaluator shall attempt to install an earlier version of software (as determined by the manufacturer). The evaluator shall verify that this attempt fails by checking the version identifiers or cryptographic hashes of the privileged software against those previously recorded and checking that the - values have not changed. + values have not changed. The evaluator shall attempt to install a current or later version and shall verify that the update succeeds. - + -
    - -
    - - + + + + + This family defines requirements for session locking capabilities that are not addressed by FTA_SSL in CC Part 2. + + + + + + requires the TSF to manage the transition to a locked state and what operations can be performed. The following actions could be considered for the management functions in FMT: - Configuring session locking policy.Transitioning to the locked state. + + Configuring session locking policy. + Transitioning to the locked state. + + There are no auditable events foreseen. No dependencies. + - The TSF shall transition to a locked state after a time interval of inactivity. + The TSF shall transition to a locked state after a time interval of inactivity. + - The TSF shall transition to a locked state after initiation by either the user or the administrator. + The TSF shall transition to a locked state after initiation by either the user or + the administrator. - The TSF shall, upon transitioning to the locked state, perform the following operations: <htm:ul><htm:li>Clearing or overwriting display devices, obscuring the previous contents; </htm:li><htm:li><assignable>Other actions performed upon transitioning to the locked state</assignable>.</htm:li></htm:ul> + The TSF shall, upon transitioning to the locked state, perform the following + operations: <htm:ul> + <htm:li>Clearing or overwriting display devices, obscuring the previous contents; </htm:li> + <htm:li><assignable>Other actions performed upon transitioning to the locked + state</assignable>.</htm:li> + </htm:ul> + - The time interval of inactivity is configured using FMT_SMF.1 function . The user/administrator-initiated lock is specified in FMT_SMF.1 function . - + The time interval of inactivity is configured using FMT_SMF.1 function . The user/administrator-initiated lock is specified in FMT_SMF.1 function . + The evaluator shall verify the TSS describes the actions performed upon transitioning to the locked state. The evaluation shall verify that the AGD guidance describes the method of @@ -5849,7 +10780,7 @@ The evaluator shall exercise the TSF configuration as the administrator and after a time of inactivity (FMT_SMF.1) according to the AGD guidance. The evaluator shall wait until the TSF locks and verify that the display is cleared or overwritten and that the only actions allowed in the locked state are - unlocking the session and those actions specified in FIA_UAU_EXT.2. + unlocking the session and those actions specified in FIA_UAU_EXT.2. The evaluator shall command the TSF to transition to the locked state according to the AGD guidance as both the user and the administrator. The evaluator shall wait until the TSF locks and verify that the display is cleared @@ -5859,22 +10790,21 @@ The evaluator shall exercise the TSF configuration as the administrator and - + - - + - Before establishing a user session, the TSF shall display an advisory warning message regarding unauthorized use of the TOE. + Before establishing a user session, the TSF shall display an advisory warning + message regarding unauthorized use of the TOE. This requirement may be met with the configuration of either text or an image containing the text of the desired message. The TSF must minimally display this information at startup, but may also display the information at every - unlock. The banner is configured according to FMT_SMF.1 function . - - The TSS shall describe when the banner is displayed. + unlock. The banner is configured according to FMT_SMF.1 function . + + The TSS shall describe when the banner is displayed. There are no guidance evaluation activities for this component. - - - The evaluator shall also perform the following test: + The evaluator shall also perform the following test: The evaluator follows the operational guidance to configure a notice and consent warning message. The evaluator shall then start up or unlock the TSF. The evaluator shall verify that the notice and consent warning message is @@ -5883,29 +10813,94 @@ The evaluator shall exercise the TSF configuration as the administrator and - + -
    - -
    - - + + + + + This family defines requirements for trusted channels that are not addressed by FTP_ITC in CC Part 2 because they apply specifically to channels required by a mobile device. + + + + + + requires the TSF to manage the communication channel between itself and other trusted products. - The following actions could be considered for the management functions in FMT:Configuring the actions that require trusted channel, if applicable.Enabling/disabling communications protocols where the TSF acts as a server. - The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Initiation and termination of trusted channel. + The following actions could be considered for the management functions in FMT: + Configuring the actions that require trusted channel, if applicable. + Enabling/disabling communications protocols where the TSF acts as a server. + + + The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: + Initiation and termination of trusted channel. + + No dependencies. + + - The TSF shall use <htm:ul><htm:li>802.11-2012 in accordance with the [<htm:i> <xref to="mod-wlanclient"></xref></htm:i>],</htm:li><htm:li>802.1X in accordance with the [<htm:i> <xref to="mod-wlanclient"></xref></htm:i>],</htm:li><htm:li>EAP-TLS in accordance with the [<htm:i> <xref to="mod-wlanclient"></xref></htm:i>],</htm:li><htm:li>Mutually authenticated TLS in accordance with [<htm:i>the <xref to="pkg-tls"></xref></htm:i>]</htm:li></htm:ul> and<selectables><selectable id="s-itc-ipsec" > <snip>IPsec</snip> in accordance with the <xref to="mod-vpnclient"></xref></selectable><selectable id="itc_dtls" > <snip>mutually authenticated DTLS</snip> as defined in the <xref to="pkg-tls"></xref></selectable><selectable id="ftp_itc_ext.1.1_1" >HTTPS</selectable></selectables>protocols to provide a communication channel between itself and another trusted IT product that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data. + The TSF shall use <htm:ul> + <htm:li>802.11-2012 in accordance with the [<htm:i><xref to="mod-wlanclient"/></htm:i>],</htm:li> + <htm:li>802.1X in accordance with the [<htm:i><xref to="mod-wlanclient"/></htm:i>],</htm:li> + <htm:li>EAP-TLS in accordance with the [<htm:i><xref to="mod-wlanclient"/></htm:i>],</htm:li> + <htm:li>Mutually authenticated TLS in accordance with [<htm:i>the <xref to="pkg-tls"/></htm:i>]</htm:li> + </htm:ul> and <selectables linebreak="yes"> + <selectable id="s-itc-ipsec"><snip>IPsec</snip> in accordance with the <xref to="mod-vpnclient"/></selectable> + <selectable id="itc_dtls"><snip>mutually authenticated DTLS</snip> as defined in the <xref to="pkg-tls"/></selectable> + <selectable>HTTPS</selectable> + </selectables> protocols to provide a communication channel between itself and another trusted IT product that is logically distinct from other communication channels, + provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data. + + The TSF shall use <htm:ul> + <htm:li>802.11-2012 in accordance with <assignable>requirements or standards defining implementation of this protocol</assignable>,</htm:li> + <htm:li>802.1X in accordance with <assignable>requirements or standards defining implementation of this protocol</assignable>,</htm:li> + <htm:li>EAP-TLS in accordance with <assignable>requirements or standards defining implementation of this protocol</assignable>,</htm:li> + <htm:li>Mutually authenticated TLS in accordance with <assignable>requirements or standards defining implementation of this protocol</assignable></htm:li> + </htm:ul> and <assignable>other protocols</assignable> protocols to provide a communication channel between itself and another trusted IT product that is logically distinct from other communication channels, + provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data. + The intent of the mandatory portion of the above requirement is to use the cryptographic protocols identified in the requirement to establish and maintain a trusted channel between the TOE and an access point, VPN Gateway, or other trusted IT product. The ST author must list which trusted channel protocols are implemented by the Mobile Device. - The TSF must be validated against the to satisfy the mandatory trusted channels of 802.11-2012, 802.1X, and EAP-TLS. + The TSF must be validated against the to satisfy the mandatory trusted channels of 802.11-2012, 802.1X, and EAP-TLS. To satisfy the mandatory trusted channel of TLS and - if is selected, the TSF must be validated against the , with the following selections made: - tlsc_impltlsc_mutual_auths-tlsc-no-excep itc_dtlsdtlsc_impldtlsc_mutual_auths-dtlsc-no-excepFCS_TLS_EXT.1:Either TLS or DTLS is selected as appropriateClient is selectedFCS_TLSC_EXT.1.1 or FCS_DTLSC_EXT.1.1 (as appropriate): The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.Mutual authentication must be selectedFCS_TLSC_EXT.1.3 or FCS_DTLSC_EXT.1.3 (as appropriate): With no exceptions is selected. s-itc-ipsecmod-vpnclient - If the ST author selects , the TSF must be validated against the . + if is selected, the TSF must be validated against the , with the following selections made: + + tlsc_impltlsc_mutual_auths-tlsc-no-excep + + + itc_dtls + dtlsc_impldtlsc_mutual_auths-dtlsc-no-excep + + + + FCS_TLS_EXT.1: + + Either TLS or DTLS is selected as appropriate + Client is selected + + FCS_TLSC_EXT.1.1 or FCS_DTLSC_EXT.1.1 (as appropriate): + + The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1. + Mutual authentication must be selected + + FCS_TLSC_EXT.1.3 or FCS_DTLSC_EXT.1.3 (as appropriate): + + With no exceptions is selected. + + + + + s-itc-ipsec + mod-vpnclient + + If the ST author selects , the TSF must be validated against the . + + + contains the requirements for implementing each of the other optional trusted channel protocols. The ST author must include the security functional requirements for the trusted channel protocol selected in FTP_ITC_EXT.1 in the main @@ -5914,36 +10909,42 @@ The evaluator shall exercise the TSF configuration as the administrator and protocols. - The TSF shall permit the TSF to initiate communication via the trusted channel. + The TSF shall permit the TSF to initiate communication via the trusted channel. + - The TSF shall initiate communication via the trusted channel for wireless access point connections, administrative communication, configured enterprise connections, and<selectables><selectable id="ftp_itc_ext.1.3_1" >OTA updates</selectable><selectable id="ftp_itc_ext.1.3_2" exclusive="yes" >no other connections</selectable></selectables>. - - The evaluator shall examine the TSS to determine that it describes the details + The TSF shall initiate communication via the trusted channel for wireless access + point connections, administrative communication, configured enterprise connections, + and <selectables> + <selectable>OTA updates</selectable> + <selectable exclusive="yes">no other connections</selectable> + </selectables>. + + The evaluator shall examine the TSS to determine that it describes the details of the TOE connecting to access points, VPN Gateways, and other trusted IT products in terms of the cryptographic protocols specified in the requirement, along with TOE-specific options or procedures that might not be reflected in the specifications. The evaluator shall also confirm that all protocols listed in the TSS are specified and included in the requirements in the ST. If OTA updates are selected, the TSS shall describe which trusted channel protocol is - initiated by the TOE and is used for updates. + initiated by the TOE and is used for updates. + The evaluator shall confirm that the operational guidance contains instructions for establishing the connection to access points, VPN Gateways, and - other trusted IT products. - - - The evaluator shall also perform the following tests for each protocol listed: + other trusted IT products. + + The evaluator shall also perform the following tests for each protocol listed: The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data are not sent in plaintext and that a - protocol analyzer identifies the traffic as the protocol under testing. - [conditional] If is selected, + protocol analyzer identifies the traffic as the protocol under testing. + [conditional] If is selected, the evaluator shall ensure that the TOE is able to initiate communications with a VPN Gateway, setting up the connections as described in the operational guidance and ensuring that - communication is successful. + communication is successful. [conditional]If OTA updates are selected, the evaluator shall trigger an update request according to the operational guidance and shall ensure that the - communication is successful. + communication is successful. For any other selected protocol (not tested in Test 1, 2, or 3), the evaluator shall ensure that the TOE is able to initiate communications with a trusted IT product using the protocol, setting up the connection as described in @@ -5953,30 +10954,616 @@ The evaluator shall exercise the TSF configuration as the administrator and - - Initiation and termination of trusted channel - Trusted channel protocol, non-TOE endpoint of connection - + + Initiation and termination of trusted channel + Trusted channel protocol, non-TOE endpoint of connection + -
    - - : Security Assurance Requirements The ST is evaluated as per ASE activities defined in the CEM for ASE_CCL.1, ASE_ECD.1, ASE_INT.1, ASE_OBJ.1, ASE_REQ.1, ASE_SPD.1, and ASE_TSS.1. In addition, there may be Evaluation Activities specified within that call for necessary descriptions to be included in the TSS that are specific to the TOE technology type. The design information about the TOE is contained in the guidance documentation available to the end user as well as the TSS portion of the ST, and any additional information required by this PP that is not to be made public. The guidance documents will be provided with the ST. Guidance must include a description of how the IT personnel verifies that the Operational Environment can fulfill its role for the security functionality. The documentation should be in an informal style and readable by the IT personnel. Guidance must be provided for every operational environment that the product supports as claimed in the ST. This guidance includes:
  • Instructions to successfully install the TSF in that environment
  • Instructions to manage the security of the TSF as a product and as a component of the larger operational environment
  • Instructions to provide a protected administrative capability Guidance pertaining to particular security functionality is also provided; requirements on such guidance are contained in the evaluation activities specified with each requirement. At the assurance level provided for TOEs conformant to this PP, life-cycle support is limited to end-user-visible aspects of the life-cycle, rather than an examination of the TOE vendor’s development and configuration management process. This is not meant to diminish the critical role that a developer’s practices play in contributing to the overall trustworthiness of a product; rather, it is a reflection on the information to be made available for evaluation at this assurance level. Testing is specified for functional aspects of the system as well as aspects that take advantage of design or implementation weaknesses. The former is done through the ATE_IND family, while the latter is through the AVA_VAN family. At the assurance level specified in this PP, testing is based on advertised functionality and interfaces with dependency on the availability of design information. One of the primary outputs of the evaluation process is the test report as specified in the following requirements. Since many of the APIs are not exposed at the user interface (e.g., touch screen), the ability to stimulate the necessary interfaces requires a developer’s test environment. This test environment will allow the evaluator, for example, to access APIs and view file system information that is not available on consumer Mobile Devices. For the current generation of this protection profile, the evaluation lab is expected to survey open sources to discover what vulnerabilities have been discovered in these types of products. In most cases, these vulnerabilities will require sophistication beyond that of a basic attacker. Until penetration tools are created and uniformly distributed to the evaluation labs, the evaluator will not be expected to test for these vulnerabilities in the TOE. The labs will be expected to comment on the likelihood of these vulnerabilities given the documentation provided by the vendor. This information will be used in the development of penetration testing tools and for the development of future protection profiles. - -
    - - RequirementRationale for SatisfactionFAU_SEL.1 - Selective AuditFAU_SEL.1 has a dependency on FMT_MTD.1 since configuration of audit data is a subset of managing TSF data. This dependency is met by FMT_SMF.1, which + +
    +
    + The Security Objectives in + were constructed to address threats identified in + . + The Security Functional Requirements (SFRs) in are a formal + instantiation of the Security Objectives. The PP identifies the Security Assurance + Requirements (SARs) to frame the extent to which the evaluator assesses the documentation + applicable for the evaluation and performs independent testing. This section + lists the set of SARs from CC part 3 that are required in evaluations against this PP. + Individual Evaluation Activities to be performed are specified both in + as well as in this section. The general model for evaluation of TOEs + against STs written to conform to this PP is as follows: After the ST has + been approved for evaluation, the ITSEF will obtain the + TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is + expected to perform actions mandated by the Common Evaluation Methodology (CEM) for the ASE + and ALC SARs. The ITSEF also performs the Evaluation Activities contained within , which are intended to be an interpretation of the other CEM evaluation + requirements as they apply to the specific technology instantiated in the TOE. The Evaluation + Activities that are captured in also provide clarification as to what + the developer needs to provide to demonstrate the TOE is compliant with the PP. + + The TOE Security Assurance Requirements are identified in . + : Security Assurance Requirements + + + Assurance ClassAssurance Components + + + Security Target (ASE) + Conformance Claims (ASE_CCL.1) + + Extended Components Definition (ASE_ECD.1) + ST Introduction (ASE_INT.1) + Security Objectives for the Operational Environment + (ASE_OBJ.1) + Stated Security Requirements (ASE_REQ.1) + Security Problem Definition (ASE_SPD.1) + TOE Summary Specification (ASE_TSS.1) + + Development (ADV) + Basic Functional Specification (ADV_FSP.1) + + + Guidance Documents (AGD) + Operational User Guidance (AGD_OPE.1) + + Preparative Procedures (AGD_PRE.1) + + Life Cycle Support (ALC) + Labeling of the TOE (ALC_CMC.1) + + TOE CM Coverage (ALC_CMS.1) + Timely Security Updates (ALC_TSU_EXT) + + Tests (ATE) + Independent Testing – Sample (ATE_IND.1) + + + Vulnerability Assessment (AVA) + Vulnerability Survey (AVA_VAN.1) + + + The ST is evaluated as per ASE + activities defined in the CEM for ASE_CCL.1, ASE_ECD.1, ASE_INT.1, ASE_OBJ.1, ASE_REQ.1, + ASE_SPD.1, and ASE_TSS.1. In addition, there may be Evaluation Activities specified within + that call for necessary descriptions to be included in the TSS + that are specific to the TOE technology type. + The design information about the TOE is + contained in the guidance documentation available to the end user as well as the TSS portion + of the ST, and any additional information required by this PP that is not to be made public. + + The functional specification describes the TOE Security Functions Interface (TSFIs). + It is not necessary to have a formal or + complete specification of these interfaces. Additionally, because TOEs conforming to + this PP will necessarily have interfaces to the Operational Environment that are not + directly invokable by TOE users, there is little point specifying that such interfaces + be described in and of themselves since only indirect testing of such interfaces may be + possible. For this PP, the activities for this family should focus on understanding the + interfaces presented in the TSS in response to the functional requirements and the + interfaces presented in the AGD documentation. + No additional "functional specification" + documentation is necessary to satisfy the evaluation activities specified. + + + The interfaces that need to be evaluated are characterized through + the information needed to perform the evaluation activities listed, rather than as an + independent, abstract list. + + The developer shall provide a functional specification. + + + The developer shall provide a tracing from the functional specification to the + SFRs. + As indicated in the introduction to this section, the + functional specification is comprised of the information contained in the AGD_OPE, + AGD_PRE, and the API information that is provided to application developers, including + the APIs that require privilege to invoke. The developer may + reference a website accessible to application developers and the evaluator. The API + documentation must include those interfaces required in this profile. The API + documentation must clearly indicate to which products and versions each available + function applies. The evaluation activities in the functional + requirements point to evidence that should exist in the documentation and TSS section; + since these are directly associated with the SFRs, the tracing in element ADV_FSP.1.2D + is implicitly already done and no additional documentation is necessary. + + + The functional specification shall describe the purpose and method of use for + each SFR-enforcing and SFR-supporting TSFI. + + + The functional specification shall identify all parameters associated with each + SFR-enforcing and SFR-supporting TSFI. + + + The functional specification shall provide rationale for the implicit + categorization of interfaces as SFR-non-interfering. + + + The tracing shall demonstrate that the SFRs trace to + TSFIs in the functional specification. + + + The evaluator shall confirm that the information provided meets all requirements + for content and presentation of evidence. + + + The evaluator shall determine that the functional specification is an accurate + and complete instantiation of the SFRs. + There are no specific evaluation activities associated with these SARs, except + ensuring the information is provided. The functional specification documentation is + provided to support the evaluation activities described in , + and other activities described for AGD, ATE, and AVA SARs. The requirements on the + content of the functional specification information is implicitly assessed by virtue + of the other evaluation activities being performed; if the evaluator is unable to + perform an activity because there is insufficient interface information, then an + adequate functional specification has not been provided. + + + + The guidance documents will be + provided with the ST. Guidance must include a description of how the IT personnel verifies + that the Operational Environment can fulfill its role for the security functionality. The + documentation should be in an informal style and readable by the IT personnel. + Guidance must be provided for every operational environment that the + product supports as claimed in the ST. This guidance includes: + Instructions to successfully install the TSF in that environment + Instructions to manage the security of the TSF as a product and as a component of + the larger operational environment + Instructions to provide a protected administrative capability + + Guidance pertaining to particular security functionality is also provided; + requirements on such guidance are contained in the evaluation activities specified with each + requirement. + + The developer shall provide operational user guidance. + The operational user guidance does not have to be contained in + a single document. Guidance to users, administrators and application developers can be + spread among documents or web pages. Where appropriate, the guidance documentation is + expressed in the eXtensible Configuration Checklist Description Format (XCCDF) to + support security automation. Rather than repeat information here, + the developer should review the evaluation activities for this component to ascertain + the specifics of the guidance that the evaluator will be checking for. This will + provide the necessary information for the preparation of acceptable guidance. + + + The operational user guidance shall describe, for each user role, the + user-accessible functions and privileges that should be controlled in a secure + processing environment, including appropriate warnings. + User and administrator (e.g., MDM agent), and application + developer are to be considered in the definition of user role. + + + The operational user guidance shall describe, for each user role, how to use the + available interfaces provided by the TOE in a secure manner. + + + The operational user guidance shall describe, for each user role, the available + functions and interfaces, in particular all security parameters under the control of + the user, indicating secure values as appropriate. + + + The operational user guidance shall, for each user role, clearly present each + type of security-relevant event relative to the user-accessible functions that need to + be performed, including changing the security characteristics of entities under the + control of the TSF. + + + The operational user guidance shall identify all possible modes of operation of + the OS (including operation following failure or operational error), their + consequences, and implications for maintaining secure operation. + + + The operational user guidance shall, for each user role, describe the security + measures to be followed in order to fulfill the security objectives for the + operational environment as described in the ST. + + + The operational user guidance shall be clear and reasonable. + + + The evaluator shall confirm that the information provided meets all requirements + for content and presentation of evidence. + Some of the contents of the operational guidance are verified by the + evaluation activities in and evaluation of the TOE according to + the . The following additional information is also required. + The operational guidance shall contain a list of natively installed + applications and any relevant version numbers. If any third party vendors are + permitted to install applications before purchase by the end user or enterprise, these + applications shall also be listed. The operational guidance shall + contain instructions for configuring the cryptographic engine associated with the + evaluated configuration of the TOE. It shall provide a warning to the administrator + that use of other cryptographic engines was not evaluated nor tested during the CC + evaluation of the TOE. The documentation must describe the process + for verifying updates to the TOE by verifying a digital signature. The evaluator shall + verify that this process includes the following steps: + Instructions for obtaining the update itself. This should include + instructions for making the update accessible to the TOE (e.g., placement in a + specific directory). + Instructions for initiating the update process, as well as discerning + whether the process was successful or unsuccessful. This includes generation of + the hash/digital signature. + The TOE will likely contain security functionality that does not fall in the + scope of evaluation under this PP. The operational guidance shall make it clear to an + administrator which security functionality is covered by the evaluation activities. + + + + + + The developer shall provide the TOE, including its preparative + procedures. + As with the operational guidance, the developer should look to + the evaluation activities to determine the required content with respect to preparative + procedures. + + + The preparative procedures shall describe all the steps necessary for secure + acceptance of the delivered TOE in accordance with the developer's delivery + procedures. + + + The preparative procedures shall describe all the steps necessary for secure + installation of the TOE and for the secure preparation of the operational environment + in accordance with the security objectives for the operational environment as + described in the ST. + + + The evaluator shall confirm that the information provided meets all requirements + for content and presentation of evidence. + + + The evaluator shall apply the preparative procedures to confirm that the OS can + be prepared securely for operation. + As indicated in the introduction above, there are significant expectations + with respect to the documentation—especially when configuring the operational + environment to support TOE functional requirements. The evaluator shall check to + ensure that the guidance provided for the TOE adequately addresses all platforms + claimed for the TOE in the ST. + + + + At the assurance level provided + for TOEs conformant to this PP, life-cycle support is limited to end-user-visible aspects of + the life-cycle, rather than an examination of the TOE vendor’s development and configuration + management process. This is not meant to diminish the critical role that a developer’s + practices play in contributing to the overall trustworthiness of a product; rather, it is a + reflection on the information to be made available for evaluation at this assurance level. + + This component is targeted at identifying the TOE such that it can be + distinguished from other products or versions from the same vendor and can be easily + specified when being procured by an end user. + + The developer shall provide the TOE and a reference for the TOE. + + + The TOE shall be labeled with a unique reference. + + + The evaluator shall confirm that the information provided meets all requirements + for content and presentation of evidence. + The evaluator shall check the ST to ensure that it contains an identifier + (such as a product name/version number) that specifically identifies the version that + meets the requirements of the ST. Further, the evaluator shall check the AGD guidance + and TOE samples received for testing to ensure that the version number is consistent + with that in the ST. If the vendor maintains a web site advertising the TOE, the + evaluator shall examine the information on the web site to ensure that the information + in the ST is sufficient to distinguish the product. + + + + Given the scope of the TOE and its associated evaluation evidence requirements, + this component’s evaluation activities are covered by the evaluation activities listed for + ALC_CMC.1. + + The developer shall provide a configuration list for the TOE. + + + The configuration list shall include the following: the TOE itself; and the + evaluation evidence required by the SARs. + + + The configuration list shall uniquely identify the configuration items. + + + The evaluator shall confirm that the information provided meets all requirements + for content and presentation of evidence. + The "evaluation evidence required by the SARs" in this PP is + limited to the information in the ST coupled with the guidance provided to + administrators and users under the AGD requirements. By ensuring that the TOE is + specifically identified and that this identification is consistent in the ST and in + the AGD guidance (as done in the evaluation activity for ALC_CMC.1), the evaluator + implicitly confirms the information required by this component. + Life-cycle support is targeted aspects of the developer’s life-cycle and instructions + to providers of applications for the developer’s devices, rather than an in-depth + examination of the TSF manufacturer’s development and configuration management + process. This is not meant to diminish the critical role that a developer’s practices + play in contributing to the overall trustworthiness of a product; rather, it’s a + reflection on the information to be made available for evaluation. + The evaluator shall ensure that the developer has identified (in + public-facing development guidance for their platform) one or more development + environments appropriate for use in developing applications for the developer’s + platform. For each of these development environments, the developer shall provide + information on how to configure the environment to ensure that buffer overflow + protection mechanisms in the environments are invoked (e.g., compiler and linker + flags). The evaluator shall ensure that this documentation also includes an indication + of whether such protections are on by default, or have to be specifically enabled. + The evaluator shall ensure that the TSF is uniquely identified + (with respect to other products from the TSF vendor), and that documentation provided + by the developer in association with the requirements in the ST is associated with the + TSF using this unique identification. + + + + This component requires the TOE developer, in conjunction with any other + necessary parties, to provide information as to how the end-user devices are updated to + address security issues in a timely manner. The documentation describes the process of + providing updates to the public from the time a security flaw is reported/discovered, to + the time an update is released. This description includes the parties involved (e.g., + the developer, cellular carriers) and the steps that are performed (e.g., developer testing, + carrier testing), including worst-case time periods, before an update is made available + to the public. + + The developer shall provide a description in the TSS of how timely security + updates are made to the TOE. + + + The description shall include the process for creating and deploying security + updates for the TOE software. + The software to be described includes the operating systems of the application + processor and the baseband processor, as well as any firmware and applications. The + process description includes the TOE developer processes as well as any third-party + (carrier) processes. The process description includes each deployment mechanism (e.g., + over-the-air updates, per-carrier updates, downloaded updates). + + + The description shall express the time window as the length of time, in days, + between public disclosure of a vulnerability and the public availability of security + updates to the TOE. + The total length of time may be presented as a summation of the periods of time + that each party (e.g., TOE developer, mobile carrier) on the critical path consumes. + The time period until public availability per deployment mechanism may differ; each is + described. + + + The description shall include the mechanisms publicly available for reporting + security issues pertaining to the TOE. + The reporting mechanism could include web sites, email addresses, as well as a + means to protect the sensitive nature of the report (e.g., public keys that could be + used to encrypt the details of a proof-of-concept exploit). + + + The description shall include where users can seek information about the + availability of new updates including details (e.g. CVE identifiers) of the specific + public vulnerabilities corrected by each update. + The purpose of providing this information is so that users and enterprises can + determine which devices are susceptible to publicly known vulnerabilities so that they + can make appropriate risk decisions, such as limiting access to enterprise resources + until updates are installed. + + + The evaluator shall confirm that the information provided meets all requirements + for content and presentation of evidence. + The evaluator shall verify that the TSS contains a description of the timely + security update process used by the developer to create and deploy security updates. + The evaluator shall verify that this description addresses the TOE OS, the firmware, + and bundled applications, each. The evaluator shall also verify that, in addition to + the TOE developer’s process, any carrier or other third-party processes are also + addressed in the description. The evaluator shall also verify that each mechanism for + deployment of security updates is described. The evaluator shall + verify that, for each deployment mechanism described for the update process, the TSS + lists a time between public disclosure of a vulnerability and public availability of + the security update to the TOE patching this vulnerability, to include any third-party + or carrier delays in deployment. The evaluator shall verify that this time is + expressed in a number or range of days. The evaluator shall verify + that this description includes the publicly available mechanisms (including either an + email address or website) for reporting security issues related to the TOE. The + evaluator shall verify that the description of this mechanism includes a method for + protecting the report either using a public key for encrypting email or a trusted + channel for a website. The evaluator shall verify that the + description includes where users can seek information about the availability of new + security updates including details of the specific public vulnerabilities corrected by + each update. The evaluator shall verify that the description includes the minimum + amount of time that the TOE is expected to be supported with security updates, and the + process by which users can seek information about when the TOE is no longer expected + to receive security updates. + + + + Testing is specified for functional aspects of + the system as well as aspects that take advantage of design or implementation weaknesses. + The former is done through the ATE_IND family, while the latter is through the AVA_VAN + family. At the assurance level specified in this PP, testing is based on advertised + functionality and interfaces with dependency on the availability of design information. One + of the primary outputs of the evaluation process is the test report as specified in the + following requirements. Since many of the APIs are not exposed at the + user interface (e.g., touch screen), the ability to stimulate the necessary interfaces + requires a developer’s test environment. This test environment will allow the evaluator, for + example, to access APIs and view file system information that is not available on consumer + Mobile Devices. + + Testing is performed to confirm the functionality described in the TSS as well as + the administrative (including configuration and operational) documentation provided. + The focus of the testing is to confirm that the requirements specified in + being met, although some additional testing is specified for SARs in + . + The Evaluation Activities identify the additional testing + activities associated with these components. + The evaluator produces a test report + documenting the plan for and results of testing, as well as coverage arguments focused + on the platform/TOE combinations that are claiming conformance to this PP. + + The developer shall provide the TOE for testing. + + + The TOE shall be suitable for testing. + + + The evaluator shall confirm that the information provided meets + all requirements for content and presentation of evidence. + + + The evaluator shall test a subset of the TSF to confirm that the TSF operates as + specified. + The evaluator shall prepare a test plan and report documenting the testing + aspects of the system. The test plan covers all of the testing actions contained in + the and the body of this PP’s Evaluation Activities. While it is + not necessary to have one test case per test listed in an evaluation activity, the + evaluator must document in the test plan that each applicable testing requirement in + the ST is covered. The test plan identifies the platforms to be + tested, and for those platforms not included in the test plan but included in the ST, + the test plan provides a justification for not testing the platforms. This + justification must address the differences between the tested platforms and the + untested platforms, and make an argument that the differences do not affect the + testing to be performed. It is not sufficient to merely assert that the differences + have no affect; rationale must be provided. If all platforms claimed in the ST are + tested, then no rationale is necessary. The test plan describes the + composition of each platform to be tested, and any setup that is necessary beyond what + is contained in the AGD documentation. It should be noted that the evaluator is + expected to follow the AGD documentation for installation and setup of each platform + either as part of a test or as a standard pre-test condition. This may include special + test drivers or tools. For each driver or tool, an argument (not just an assertion) + should be provided that the driver or tool will not adversely affect the performance + of the functionality by the TOE and its platform. This also includes the configuration + of the cryptographic engine to be used. The cryptographic algorithms implemented by + this engine are those specified by this PP and used by the cryptographic protocols + being evaluated (IPsec, TLS/HTTPS, SSH). The test plan identifies + high-level test objectives as well as the test procedures to be followed to achieve + those objectives. These procedures include expected results. The test report (which + could just be an annotated version of the test plan) details the activities that took + place when the test procedures were executed, and includes the actual results of the + tests. This shall be a cumulative account, so if there was a test run that resulted in + a failure; a fix installed; and then a successful re-run of the test, the report would + show a "fail" and "pass" result (and the supporting details), and not just the "pass" + result. + + + + For the current generation + of this protection profile, the evaluation lab is expected to survey open sources to + discover what vulnerabilities have been discovered in these types of products. In most + cases, these vulnerabilities will require sophistication beyond that of a basic attacker. + Until penetration tools are created and uniformly distributed to the evaluation labs, the + evaluator will not be expected to test for these vulnerabilities in the TOE. The labs will + be expected to comment on the likelihood of these vulnerabilities given the documentation + provided by the vendor. This information will be used in the development of penetration + testing tools and for the development of future protection profiles. + + + The developer shall provide the TOE for testing. + + + The TOE shall be suitable for testing. + + + The evaluator shall confirm that the information provided meets all requirements + for content and presentation of evidence. + + + The evaluator shall perform a search of public domain sources to identify + potential vulnerabilities in the TOE. + Public domain sources include the Common Vulnerabilities and + Exposures (CVE) dictionary for publicly-known vulnerabilities. + + + The evaluator shall conduct penetration testing, based on the identified + potential vulnerabilities, to determine that the TOE is resistant to attacks performed + by an attacker possessing Basic attack potential. + The evaluator shall generate a report to document their findings with respect + to this requirement. This report could physically be part of the overall test report + mentioned in ATE_IND, or a separate document. The evaluator performs a search of + public information to find vulnerabilities that have been found in mobile devices and + the implemented communication protocols in general, as well as those that pertain to + the particular TOE. The evaluator documents the sources consulted and the + vulnerabilities found in the report. For each vulnerability found, + the evaluator either provides a rationale with respect to its non-applicability, or + the evaluator formulates a test (using the guidelines provided in ATE_IND) to confirm + the vulnerability, if suitable. Suitability is determined by assessing the attack + vector needed to take advantage of the vulnerability. If exploiting the vulnerability + requires expert skills and an electron microscope, for instance, then a test would not + be suitable and an appropriate justification would be formulated. + + + +
    + + + + + + + Requirement + Rationale for Satisfaction + + + FAU_SEL.1 - Selective Audit + FAU_SEL.1 has a dependency on FMT_MTD.1 since configuration of audit data is a subset of managing TSF data. This dependency is met by FMT_SMF.1, which defines "configure the auditable items" as a management function and specifies the roles that may perform this, consistent with how FMT_MTD.1 would typically satisfy the dependency. - FCS_CKM.1 - Cryptographic Key GenerationFCS_CKM.1 has a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF generates. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose.FCS_CKM.1 - Cryptographic Key GenerationFCS_CKM.1 has a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF generates. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2 equivalent.FCS_CKM.2 - Cryptographic Key EstablishmentBoth iterations of FCS_CKM.2 have a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF establishes. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose - as its CC Part 2 equivalent.FCS_COP.1 - Cryptographic OperationAll iterations of FCS_COP.1 have a dependency on FCS_CKM.4 for the subsequent destruction of any residual key material the TSF creates as part of the operation. - This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2 equivalent.FCS_STG_EXT.1 - Cryptographic Key StorageFCS_STG_EXT.1 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. - This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF.FDP_ACF_EXT.1 - Access Control for System ServicesFDP_ACF_EXT.1 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. - This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF.FDP_ACF_EXT.2 - Access Control for System ResourcesFDP_ACF_EXT.2 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. - This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF.FIA_AFL_EXT.1 - Authentication Failure HandlingFIA_AFL_EXT.1 has a dependency on FIA_UAU.1 since handling of authentication failures is not possible without an authentication mechanism. This dependency is met - by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent.FIA_PMG_EXT.1 - Password ManagementFIA_PMG_EXT.1 has a dependency on FIA_UAU.1 since composition of authentication credentials is not possible without an authentication mechanism. This dependency is met - by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent.FIA_UAU.7 - Protected Authentication FeedbackFIA_UAU.7 has a dependency on FIA_UAU.1 since protected authentication feedback is not possible without an authentication mechanism. This dependency is met - by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent.FMT_SMF_EXT.3 - Current AdministratorFMT_SMF_EXT.3 has a dependency on FMT_SMR.1 through its reference to management roles in the requirement text. - This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF. - + + + + FCS_CKM.1 - Cryptographic Key Generation + FCS_CKM.1 has a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF generates. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose. + + + FCS_CKM.1 - Cryptographic Key Generation + FCS_CKM.1 has a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF generates. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2 equivalent. + + + FCS_CKM.2 - Cryptographic Key Establishment + Both iterations of FCS_CKM.2 have a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF establishes. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose + as its CC Part 2 equivalent. + + + FCS_COP.1 - Cryptographic Operation + All iterations of FCS_COP.1 have a dependency on FCS_CKM.4 for the subsequent destruction of any residual key material the TSF creates as part of the operation. + This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2 equivalent. + + + + FCS_STG_EXT.1 - Cryptographic Key Storage + FCS_STG_EXT.1 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. + This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF. + + + FDP_ACF_EXT.1 - Access Control for System Services + FDP_ACF_EXT.1 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. + This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF. + + + FDP_ACF_EXT.2 - Access Control for System Resources + FDP_ACF_EXT.2 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. + This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF. + + + FIA_AFL_EXT.1 - Authentication Failure Handling + FIA_AFL_EXT.1 has a dependency on FIA_UAU.1 since handling of authentication failures is not possible without an authentication mechanism. This dependency is met + by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent. + + + FIA_PMG_EXT.1 - Password Management + FIA_PMG_EXT.1 has a dependency on FIA_UAU.1 since composition of authentication credentials is not possible without an authentication mechanism. This dependency is met + by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent. + + + FIA_UAU.7 - Protected Authentication Feedback + FIA_UAU.7 has a dependency on FIA_UAU.1 since protected authentication feedback is not possible without an authentication mechanism. This dependency is met + by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent. + + + FMT_SMF_EXT.3 - Current Administrator + FMT_SMF_EXT.3 has a dependency on FMT_SMR.1 through its reference to management roles in the requirement text. + This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF. + + + + + The documentation of the entropy source should be detailed enough that, after reading, the evaluator will thoroughly understand the entropy source and why it can be relied upon to provide entropy. This @@ -5993,12 +11580,13 @@ The evaluator shall exercise the TSF configuration as the administrator and the raw outputs (hash, XOR, etc.), if/where it is stored, and finally, how it is output from the entropy source. Any conditions placed on the process (e.g., blocking) should also be described in the entropy source design. Diagrams and examples are encouraged. - This design must also include a description of the content of the security + This design must also include a description of the content of the security boundary of the entropy source and a description of how the security boundary ensures that an - adversary outside the boundary cannot affect the entropy rate. If + adversary outside the boundary cannot affect the entropy rate. If implemented, the design description shall include a description of how third-party applications can add entropy to the RBG. A description of any RBG state saving between - power-off and power-on shall be included.
    • + power-off and power-on shall be included.
    +
    There should be a technical argument for where the unpredictability in the source comes from and why there is confidence in the entropy source exhibiting probabilistic behavior (an explanation of the probability @@ -6006,48 +11594,733 @@ The evaluator shall exercise the TSF configuration as the administrator and describe this). This argument will include a description of the expected entropy rate and explain how you ensure that sufficient entropy is going into the TOE randomizer seeding process. This discussion will be part of a justification for why the entropy source can be - relied upon to produce bits with entropy. The entropy justification shall + relied upon to produce bits with entropy. The entropy justification shall not include any data added from any third-party application or from any state saving between - restarts.
    + restarts.
    +
    Documentation will also include the range of operating conditions under which the entropy source is expected to generate random data. It will clearly describe the measures that have been taken in the system design to ensure the entropy source continues to operate under those conditions. Similarly, documentation shall describe the conditions under which the entropy source is known to malfunction or become - inconsistent. Methods used to detect failure or degradation of the source shall be included.
    + inconsistent. Methods used to detect failure or degradation of the source shall be included.
    +
    More specifically, all entropy source health tests and their rationale will be documented. This will include a description of the health tests, the rate and conditions under which each health test is performed (e.g., at startup, continuously, or on-demand), the expected results for each health test, and rationale indicating why each test is believed to be appropriate for detecting one or more failures in - the entropy source.
    - - This protection profile was developed by the Mobility Technical Community with representatives from industry, U.S. Government agencies, Common Criteria Test Laboratories, and international Common Criteria schemes. The National Information Assurance Partnership wishes to acknowledge and thank the members of this group whose dedicated efforts contributed significantly to the publication. These organizations include: U.S. Government - Defense Information Systems Agency (DISA) - CyberSecurity Directorate (CSD) - National Information Assurance Partnership (NIAP) - National Institute of Standards and Technology (NIST)International Common Criteria Schemes - Australian Information Security Evaluation Program (AISEP) - Canadian Common Criteria Evaluation and Certification Scheme (CSEC) - Information-technology Promotion Agency, Japan (IPA) - UK IT Security Evaluation and Certificate Scheme (NCSC)Industry - Apple, Inc. - BlackBerry - LG Electronics, Inc. - Microsoft Corporation - Motorola Solutions - Samsung Electronics Co., Ltd. - Other Members of the Mobility Technical CommunityCommon Criteria Test Laboratories - EWA-Canada, Ltd. - Gossamer Security Solutions + the entropy source.
    + + + + + : References and IV Requirements for NIST-approved Cipher + Modes + + + Cipher Mode + Reference + IV Requirements + + + Electronic Codebook (ECB) + SP 800-38A + No IV + + + Counter (CTR) + SP 800-38A + "Initial Counter" shall be non-repeating. No counter value shall be repeated across + multiple messages with the same secret key. + + + Cipher Block Chaining (CBC) + SP 800-38A + IVs shall be unpredictable. Repeating IVs leak information about whether the first + one or more blocks are shared between two messages, so IVs should be non-repeating in such + situations. + + + Output Feedback (OFB) + SP 800-38A + IVs shall be non-repeating and shall not be generated by invoking the cipher on + another IV. + + + Cipher Feedback (CFB) + SP 800-38A + IVs should be non-repeating as repeating IVs leak information about the first + plaintext block and about common shared prefixes in messages. + + + XEX (XOR Encrypt XOR) Tweakable Block Cipher with Ciphertext Stealing (XTS) + SP 800-38E + No IV. Tweak values shall be non-negative integers, assigned consecutively, and + starting at an arbitrary non-negative integer. + + + Cipher-based Message Authentication Code (CMAC) + SP 800-38B + No IV + + + Key Wrap and Key Wrap with Padding + SP 800-38F + No IV + + + Counter with CBC-Message Authentication Code (CCM) + SP 800-38C + No IV. Nonces shall be non-repeating. + + + Galois Counter Mode (GCM) + SP 800-38D + IV shall be non-repeating. The number of invocations of GCM shall not exceed + $2^{32}$ for a given secret key unless an implementation only uses 96-bit IVs (default + length). + + + + + + This protection profile was developed by the Mobility Technical Community with representatives from industry, U.S. Government agencies, Common Criteria Test Laboratories, and international Common Criteria schemes. The National Information Assurance Partnership wishes to acknowledge and thank the members of this group whose dedicated efforts contributed significantly to the publication. These organizations include: + + U.S. Government + Defense Information Systems Agency (DISA) + CyberSecurity Directorate (CSD) + National Information Assurance Partnership (NIAP) + National Institute of Standards and Technology (NIST) + + International Common Criteria Schemes + Australian Information Security Evaluation Program (AISEP) + Canadian Common Criteria Evaluation and Certification Scheme (CSEC) + Information-technology Promotion Agency, Japan (IPA) + UK IT Security Evaluation and Certificate Scheme (NCSC) + + Industry + Apple, Inc. + BlackBerry + LG Electronics, Inc. + Microsoft Corporation + Motorola Solutions + Samsung Electronics Co., Ltd. + Other Members of the Mobility Technical Community + + Common Criteria Test Laboratories + EWA-Canada, Ltd. + Gossamer Security Solutions + + + + + + + If the TOE includes Bluetooth hardware, the following SFRs must be claimed: + + + - - - CEM - Common + + CEM + + Common Evaluation Methodology for Information Technology Security - Evaluation Methodology, CCMB-2012-09-004, Version 3.1, Revision 5, April 2017. - - + + + +     + + + + + + + + +