This class contains families of functional requirements that relate to the integrity and management of the mechanisms that provide the TSF (independent of TSP-specifics), and to the integrity of TSF data (independent of the specific contents of the TSP data). In some sense, families in this class may appear to duplicate components in the FDP (User data protection) class and may even be implemented using the same mechanisms. However, FDP focuses on user data protection, while FPT focuses on TSF data protection. In fact, components from the FPT class are necessary in order to provide requirements that the SFPs in the TOE cannot be tampered with or bypassed.
Figure J.1 - Protection of the TOE Security Functions class decomposition
Figure J.2 - Protection of the TOE Security Functions class decomposition (Cont.)
From the point of view of this class, there are three significant portions that make up the TSF:
a) The TSF's abstract machine, which is the virtual or physical machine upon which the specific TSF implementation under evaluation executes.
b) The TSF's implementation, which executes on the abstract machine and implements the mechanisms that enforce the TSP.
c) The TSF's data, which are the administrative databases that guide the enforcement of the TSP.
All of the families in the FPT class can be related to these areas, and fall into the following groupings:
a) FPT_PHP (TSF physical protection), which provides an authorised user with the ability to detect external attacks on the parts of the TOE that comprise the TSF.
b) FPT_AMT (Underlying abstract machine test) and FPT_TST (TSF self test), which provide an authorised user with the ability to verify the correct operation of the underlying abstract machine and the TSF as well as the integrity of the TSF data and executable code.
c) FPT_SEP (Domain separation) and FPT_RVM (Reference mediation), which protect the TSF during execution and ensure that the TSF cannot be bypassed. When appropriate components from these families are combined with the appropriate components from ADV_INT (TSF internals), the TOE can be said to have what has been traditionally called a "Reference Monitor."
d) FPT_RCV (Trusted recovery), FPT_FLS (Fail secure), and FPT_TRC (Internal TOE TSF data replication consistency), which address the behaviour of the TSF when failure occurs and immediately after.
e) FPT_ITA (Availability of exported TSF data), FPT_ITC (Confidentiality of exported TSF data), FPT_ITI (Integrity of exported TSF data), which address the protection and availability of TSF data between the TSF and a remote trusted IT product.
f) FPT_ITT (Internal TOE TSF data transfer), which addresses protection of TSF data when it is transmitted between physically-separated parts of the TOE.
g) FPT_RPL (Replay detection), which addresses the replay of various types of information and/or operations.
h) FPT_SSP (State synchrony protocol), which addresses the synchronisation of states, based upon TSF data, between different parts of a distributed TSF.
i) FPT_STM (Time stamps), which addresses reliable timing.
j) FPT_TDC (Inter-TSF TSF data consistency), which addresses the consistency of TSF data shared between the TSF and a remote trusted IT product.
This family defines the requirements for the TSF's testing of security assumptions made about the underlying abstract machine upon which the TSF relies. This "abstract" machine could be a hardware/firmware platform, or it could be some known and assessed hardware/software combination acting as a virtual machine. Examples of such testing could be testing hardware page protection, sending sample packets across a network to ensure receipt, and verifying the behaviour of the virtual machine interface. 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 in FPT_RCV Trusted recovery .
User notes
The term "underlying abstract machine" typically refers to the hardware components upon which the TSF has been implemented. However, the phrase can also be used to refer to an underlying, previously evaluated hardware and software combination behaving as a virtual machine upon which the TSF relies.
The tests of the abstract machine may take various forms:
a) Power-On Tests. These are tests that ensure the correct operation of the underlying platform. For hardware and firmware, this might include tests of elements such as memory boards, data paths, buses, control logic, processor registers, communication ports, console interfaces, speakers, and peripherals. For software elements (virtual machine), this would include verification of correct initialisation and behaviour.
b) Loadable Tests. These are tests that might be loaded and executed by an authorised user or be activated by specific conditions. This might include processor component stress tests (logic units, calculation units, etc.) and control memory.
Evaluator Notes
The tests of the underlying abstract machine should be sufficient to test all of the characteristics of the underlying abstract machine upon which the TSF relies.
FPT_AMT.1 Abstract machine testing
User application notes
This component provides support for the periodic testing of the security assumptions of the underlying abstract machine 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.
Evaluator application notes
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.
Operations
Selection:
In FPT_AMT.1.1 the PP/ST author should specify when the TSF will execute the abstract machine testing, during initial start-up, periodically during normal operation, at the request of an authorised user, or under other conditions. In the case of the latter option, the PP/ ST author should refine what those conditions are. The PP/ST author, through this selection, has the ability to indicate the frequency with which the self tests will be run. If the tests are run often, then the end users should have more confidence that the TOE is operating correctly then 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, self tests may delay the normal operation of a TOE.
The requirements of this family ensure that the TOE will not violate its TSP in the event of certain types of failures in the TSF.
FPT_FLS.1 Failure with preservation of secure state
User application notes
The term "secure state" refers to a state in which the TSF data are consistent and the TSF continues correct enforcement of the TSP. The "secure state" is defined in the TSP model. If the developer provided a clear definition of the secure state and the reason why it should be considered secure, the dependency from FPT_FLS.1 to ADV_SPM.1 can be argued away.
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.
Operations
Assignment:
For FPT_FLS.1.1, 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 TSP.
This family defines the rules for the prevention of loss of availability of TSF data moving between the TSF and a remote trusted IT product. This data could be TSF critical data such as passwords, keys, audit data, or TSF executable code.
User notes
This family is used in a distributed system context where the TSF is providing TSF data to a remote 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.
FPT_ITA.1 Inter-TSF availability within a defined availability metric
Operations
Assignment:
For FPT_ITA.1.1, the PP/ST author should specify the types of TSF data that are subject to the availability metric.
For FPT_ITA.1.1, the PP/ST should specify the availability metric for the applicable TSF data.
For FPT_ITA.1.1, 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 the remote trusted IT product.
This family defines the rules for the protection from unauthorised disclosure of TSF data moving between the TSF and a remote trusted IT product. Examples of this data are TSF critical data such as passwords, keys, audit data, or TSF executable code.
User notes
This family is used in a distributed system context where the TSF is providing TSF data to a remote 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.
FPT_ITC.1 Inter-TSF confidentiality during transmission
Evaluator application notes
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 defines the rules for the protection, from unauthorised modification, of TSF data during transmission between the TSF and a remote trusted IT product. Examples of this data are TSF critical data such as passwords, keys, audit data, or TSF executable code.
User notes
This family is used in a distributed system context where the TSF is exchanging TSF data with a remote trusted IT product. Note that a requirement that addresses modification, detection, or recovery at the remote trusted IT product cannot be specified, as the mechanisms that a remote 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 the remote trusted IT product can use.
FPT_ITI.1 Inter-TSF detection of modification
User application notes
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 the remote 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.
Operations
Assignment:
For FPT_ITI.1.1, 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.
For FPT_ITI.1.2, 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".
FPT_ITI.2 Inter-TSF detection and correction of modification
User application notes
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.
Evaluator Notes
Some possible means of satisfying this requirement involves the use of cryptographic functions or some form of checksum.
Operations
Assignment:
For FPT_ITI.2.1, 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.
For FPT_ITT.2.2, 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".
For FPT_ITI.2.3, the PP/ST author should define the types of modification from which the TSF should be capable of recovering.
This family provides requirements that address protection of TSF data when it is transferred between separate parts of a TOE across an internal channel.
User notes
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.
Evaluator Notes
One practical mechanism available to a TSF to provide this protection is cryptographically-based.
FPT_ITT.1 Basic internal TSF data transfer protection
Operations
Selection:
In FPT_ITT.1.1, the PP/ST author should specify the desired type of protection to be provided from the choices: disclosure, modification.
FPT_ITT.2 TSF data transfer separation
User application notes
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.
Operations
Selection:
In FPT_ITT.1.1, the PP/ST author should specify the desired type of protection to be provided from the choices: disclosure, modification.
FPT_ITT.3 TSF data integrity monitoring
Operations
Selection:
In FPT_ITT.3.1, 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.
Assignment:
In FPT_ITT.3.1, 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.
In FPT_ITT.3.2, 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 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.
User notes
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.
FPT_PHP.1 Passive detection of physical attack
User application notes
FPT_PHP.1 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. The dependency on FMT_MOF.1 is required to specify who can make use of that capability, and how they can make use of that capability. If this function is realised by non-IT mechanisms (e.g. physical inspection) it could be justified that the dependency on FMT_MOF.1 is not satisfied.
FPT_PHP.2 Notification of physical attack
User application notes
FPT_PHP.2 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.
Operations
Assignment:
For FPT_PHP.2.3, the PP/ST author should provide a list of TSF devices/elements for which active detection of physical tampering is required.
For FPT_PHP.2.3, 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 FMT_MOF.1 family) included in the PP/ST.
FPT_PHP.3 Resistance to physical attack
For some forms of tampering, it is necessary that the TSF not only detects the tampering, but actually resists it or delays the attacker.
User application notes
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.
Operations
Assignment:
For FPT_PHP.3.1, 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.
For FPT_PHP.3.1, 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.
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:
a) 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).
b) 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).
c) 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.
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 Class FMT Security management . If FMT 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 TSP.
Mechanisms designed to detect exceptional conditions during operation fall under FPT_TST TSF self test, FPT_FLS Fail secure, and other areas that address the concept of "Software Safety."
User notes
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. The "secure state" is defined in the TSP model. If the developer provided a clear definition of the secure state and the reason why it should be considered secure, the dependency from FPT_FLS.1 to ADV_SPM.1 can 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.
User application notes
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.
Evaluator application notes
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.
Automated recovery is considered to be more useful than manual recovery, as it allows the machine to operate in an unattended fashion.
User application notes
The component FPT_RCV.2 Automated recovery extends the feature coverage of FPT_RCV.1 Manual recovery 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.
Evaluator application notes
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 FPT_RCV.2.1, 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.
Operations
Assignment:
For FPT_RCV.2.2, the PP/ST author should specify the list of failures or other discontinuities for which automated recovery must be possible.
FPT_RCV.3 Automated recovery without undue loss
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.
User application notes
The component FPT_RCV.3 extends the feature coverage of FPT_RCV.2 by requiring that there not be undue loss of TSF data or objects within the TSC. At FPT_RCV.2, 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 FPT_RCV.3.
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 within the TSC.
Evaluator application notes
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.
Operations
Assignment:
For FPT_RCV.3.2, the PP/ST author should specify the list of failures or other discontinuities for which automated recovery must be possible.
For FPT_RCV.3.3, the PP/ST author should provide a quantification for the amount of loss of TSF data or objects that is acceptable.
Function recovery requires that if there should be some failure in the TSF, that certain SFs in the TSF should either complete successfully or recover to a secure state.
Operations
Assignment:
In FPT_RCV.4.1, the PP/ST author should specify a list the SFs and failure scenarios. In the event that any of the identified failure scenarios happen, the SFs that have been specified must either complete successfully or recover to a consistent and secure state.
This family addresses detection of replay for various types of entities and subsequent actions to correct.
User application notes
The entities included here are, for example, messages, service requests, service responses, or sessions.
Operations
Assignment:
In FPT_RPL.1.1, 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.
In FPT_RPL.1.2, 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.
The components of this family address the "always invoked" aspect of a traditional reference monitor. The goal of these components is to ensure, with respect to the TSC, that all actions requiring policy enforcement invoked by subjects untrusted with respect to any or all of that SFP to objects controlled by that SFP are validated by the TSF against the SFP. If the portion of the TSF that enforces the SFP also meets the requirements of appropriate components from FPT_SEP (Domain separation) and ADV_INT (TSF internals), than that portion of the TSF provides a "reference monitor" for that SFP.
The Reference Monitor is that portion of the TSF responsible for the enforcement of the TSP; it has the following three characteristics:
a) Untrusted subjects cannot interfere with its operation; i.e. it is tamperproof. This is addressed by the components in the FPT_SEP family.
b) Untrusted subjects cannot bypass its checks; i.e. it is always invoked. This is addressed by the components in the FPT_RVM family.
c) It is simple enough to be analysed and its behaviour understood (i.e. its design is conceptually simple.) This is addressed by the components in the ADV_INT family.
This component states that, "the TSF shall ensure that TSP enforcement functions are invoked and succeed before each and every function within the TSC is allowed to proceed." In any system (distributed or otherwise) there are a finite number of functions responsible for enforcing the TSP. There is nothing in this requirement that mandates or prescribes that a single function is invoked to handle security. Rather, it allows multiple functions to fill the role of reference monitor, and the collection of them responsible for enforcing the TSP are simply called, collectively, the reference monitor. However, this must be balanced by the goal of keeping the "reference monitor" simple.
A TSF that implements a SFP provides effective protection against unauthorised functions if and only if all enforceable actions (e.g. accesses to objects) requested by subjects untrusted with respect to any or all of that SFP are validated by the TSF before succeeding, If the enforceable action is incorrectly enforced or bypassed, the overall enforcement of the SFP has been compromised. "Untrusted" subjects could then bypass the SFP in a variety of unauthorised ways (e.g. circumvent access checks for some subjects or objects, bypass checks for objects whose protection was assumed by applications, retain access rights beyond their intended lifetime, bypass auditing of audited actions, or bypass authentication). Note that the term "untrusted subjects" refers to subjects untrusted with respect to any or all of the specific SFPs being enforced; a subject may be trusted with respect to one SFP and untrusted with respect to a different SFP.
FPT_RVM.1 Non-bypassability of the TSP
User application notes
In order to obtain the equivalent of a reference monitor, this component must be used with either FPT_SEP.2 (SFP domain separation) or FPT_SEP.3 (Complete reference monitor), and ADV_INT.3 (Minimisation of complexity). Further, if complete reference mediation is required, the components from Class FDP User data protection must cover all objects.
The components of this family ensure that at least one security domain is available for the TSF's own execution, and that the TSF is protected from external interference and tampering (e.g. by modification of TSF code or data structures) by untrusted subjects. Satisfying the requirements of this family makes the TSF self-protecting, meaning that an untrusted subject cannot modify or damage the TSF.
This family requires the following:
a) The resources of the TSF's security domain ("protected domain") and those of subjects and unconstrained entities external to the domain are separated such that the entities external to the protected domain cannot observe or modify data structures or code internal to the protected domain.
b) The transfer of subjects between domains are controlled such that arbitrary entry to, or return from, the protected domain is not possible.
c) The user or application parameters passed to the protected domain by addresses are validated with respect to the protected domain's address space, and those passed by value are validated with respect to the values expected by the protected domain.
d) The security domains of subjects are distinct except for controlled sharing via the TSF.
User notes
This family is needed whenever confidence is required that the TSF has not been subverted.
In order to obtain the equivalent of a reference monitor, the components FPT_SEP.2 (SFP domain separation) or FPT_SEP.3 (Complete reference monitor) from this family must be used in conjunction with FPT_RVM.1 (Non-bypassability of the TSP), and ADV_INT.3 (Minimisation of complexity). Further, if complete reference mediation is required, the components from Class FDP User data protection must cover all objects.
FPT_SEP.1 TSF domain separation
Without a separate protected domain for the TSF, there can be no assurance that the TSF has not been subjected to any tampering attacks by untrusted subjects. Such attacks may involve modification of the TSF code and/or TSF data structures.
FPT_SEP.2 SFP domain separation
The most important function provided by a TSF is the enforcement of its SFPs. In order to simplify the design and increase the likelihood that those significant SFPs exhibit the characteristics of a reference monitor (RM), in particular, being tamperproof, they must be in a domain distinct from the remainder of the TSF.
Evaluator application notes
It is possible that a reference monitor in a layered design may provide functions beyond those of the SFPs. This arises out of the practical nature of layered software design. The goal should be to minimise the non-SFP related functions.
Note that it is acceptable for the reference monitors for all included SFPs to be in a single distinct reference monitor domain, as well as having multiple reference monitor domains (each enforcing one or more SFPs). If multiple reference monitor domains for SFPs are present, it is acceptable for them to be either peers or in a hierarchical relationship.
For FPT_SEP.2.1, the phrase "unisolated portion of the TSF" refers to that portion of the TSF consisting of those functions in the TSF not covered by FPT_SEP.2.3.
Operations
Assignment:
For FPT_SEP.2.3, the PP/ST author should specify the access control and/or information flow control SFPs in the TSP that should have a separate domain.
FPT_SEP.3 Complete reference monitor
The most important function provided by a TSF is the enforcement of its SFPs. This component builds upon the intentions of the previous component by requiring that all access control and/or information flow control FSPs be enforced in a domain distinct from the remainder of the TSF. This further simplifies the design and increases the likelihood that the characteristics of a reference monitor (RM), in particular, being tamperproof, are found in the TSF.
Evaluator application notes
It is possible that a reference monitor in a layered design may provide functions beyond those of the SFPs. This arises out of the practical nature of layered software design. The goal should be to minimise the non-SFP related functions.
Note that it is acceptable for the reference monitors for all included SFPs to be in a single distinct reference monitor domain, as well as having multiple reference monitor domains (each enforcing one or more SFPs). If multiple reference monitor domains for SFPs are present, it is acceptable for them to be either peers or in a hierarchical relationship.
Distributed systems may give rise to greater complexity than monolithic systems through the potential for differences in state between parts of the system, 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.
FPT_SSP establishes the requirement for certain critical security functions of the TSF to use a trusted protocol. FPT_SSP ensures that two distributed parts of the TOE (e.g. hosts) have synchronised their states after a security-relevant action.
User notes
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 systems. 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).
FPT_SSP.1 Simple trusted acknowledgement
User application notes
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.
FPT_SSP.2 Mutual trusted acknowledgement
User application notes
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.
This family addresses requirements for a reliable time stamp function within a TOE.
User notes
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.
FPT_STM.1 Reliable time stamps
User application notes
Some possible uses of this component include providing reliable time stamps for the purposes of audit as well as for security attribute expiration.
In a distributed or composite system 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.
User notes
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 FPT_ITI family. These components specify requirements for the TSF to be able to detect or detect and correct modifications to TSF data in transit.
FPT_TDC.1 Inter-TSF basic TSF data consistency
User application notes
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.
Operations
Assignment:
In FPT_TDC.1.1, 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.
In FPT_TDC.1.2, the PP/ST should assign the list of interpretation rules to be applied by the TSF.
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.
User notes
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.
FPT_TRC.1 Internal TSF consistency
Operations
Assignment:
In FPT_TRC.1.2, the PP/ST author should specify the list of SFs 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 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 executable code (i.e. TSF software) and TSF data 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.
User notes
The term "correct operation of the TSF" refers primarily to the operation of the TSF software and the integrity of the TSF data. The abstract machine upon which the TSF software is implemented is tested via dependency on FPT_AMT.
User application notes
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.
Evaluator application notes
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.
Operations
Selection:
In FPT_TST.1 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.
Assignment:
In FPT_TST.1.1 the PP/ST author should, if selected, specify the conditions under which the self test should take place.