PP-Module for Bluetooth 2.0 National Information Assurance Partnership 2026-04-03 Bluetooth; NFC 1.0 2021-04-15 Initial Release 2.0 2025-01-31 Updates based on CC:2022 TDs Applied The scope of the Bluetooth PP-Module is to describe the security functionality of Bluetooth technology in terms of [CC] and to define functional and assurance requirements for the Bluetooth capability of mobile devices and operating systems. Bluetooth is a communications standard for short-range wireless transmissions. Bluetooth is implemented in many commercial devices as a method for wirelessly connecting devices or accessories. This PP-Module is intended for use with the following base PPs: Protection Profile for Mobile Device Fundamentals (PP_MDF), Version 4.0 Protection Profile for General Purpose Operating Systems (PP_GPOS), Version 5.0 These base PPs are valid because consumer-grade desktop and mobile devices may both have Bluetooth hardware radios and so both desktop and mobile operating systems have the software/firmware capability to allow products to use them. Verifying the identity of communicating devices based on their Bluetooth address. Bluetooth does not provide native user authentication. Allowing the control of resources by ensuring that a device is authorized to use a service before permitting it to do so. The Bluetooth device Address, which is used to identify a Bluetooth device. A wireless communication link operating in the unlicensed ISM band at 2.4 GHz using a frequency hopping transceiver. It allows real-time AV and data communications between Bluetooth Hosts. The link protocol is based on time slots. The part of the Bluetooth system that specifies or implements the medium access and physical layer procedures to support the exchange of real-time voice, data information streams, and ad hoc networking between Bluetooth devices. A generic term referring to a Primary Controller with or without a Secondary Controller. A device that is capable of short-range wireless communications using the Bluetooth system. A 48 bit address used to identify each Bluetooth device. Bluetooth basic rate (BR) and enhanced data rate (EDR). A term referring to the Bluetooth Radio, Baseband, Link Manager, and HCI layers. A Channel that is divided into time slots in which each slot is related to an RF hop frequency. Consecutive hops normally correspond to different RF hop frequencies and occur at a standard hop rate of 1600 hops per second. These consecutive hops follow a pseudo-random hopping sequence, hopping through a 79 RF channel set, or optionally fewer channels when Adaptive Frequency Hopping (AFH) is in use. BR/EDR/LE Bluetooth basic rate (BR), enhanced data rate (EDR) and low energy (LE). The establishment of a connection to a service. If not already done, this also includes establishment of a physical link, logical transport, logical link and L2CAP channel. A BR/EDR device in range that periodically listens on its page scan physical channel and will respond to a page on that channel. An LE device that is advertising using a connectable advertising event. Two BR/EDR devices and with a physical link between them. Connecting A phase in the communication between devices when a connection between the devices is being established. The connecting phase follows after the link establishment phase is completed. An interaction between two peer applications or higher layer protocols mapped onto an L2CAP channel. A procedure for creating a connection mapped onto a channel. A series of one or more pairs of interleaving data packets sent between a master and a slave on the same physical channel. A procedure of establishing a connection, including authentication and encryption. A procedure where the remote device is marked as a trusted device. This includes storing a common link key for future authentication, or pairing, when a link key is not available. A procedure for retrieving the Bluetooth device address, clock, class-of-device field and used page scan mode from discoverable devices. A BR/EDR device in range that periodically listens on an inquiry scan physical channel and will respond to an inquiry on that channel. An LE device in range that is advertising with a connectable or scannable advertising event with a discoverable flag set in the advertising data. This device is in the discoverable mode. A Bluetooth device that is performing inquiry scans in BR/EDR or advertising with a discoverable or connectable advertising event with a discoverable flag set in LE. A Bluetooth device that is carrying out the inquiry procedure in BR/EDR or scanning for advertisers using a discoverable or connectable advertising event with a discoverable flag set in LE. A logical entity defined as all of the layers below the non-core profiles and above the Host Controller interface (HCI); i.e. Bluetooth Host attached to a Bluetooth Controller may communicate with other Bluetooth Hosts attached to their Controllers as well. A data link protocol used in the Bluetooth protocol stack. A logical connection on L2CAP level between two devices serving a single application or higher layer protocol. A procedure for establishing a logical connection on L2CAP level. Shorthand for a logical link. A procedure for establishing the default ACL link and hierarchy of links and channels between devices. A secret that is known by two devices and is used to authenticate the link. An LMP level procedure for verifying the identity of a remote device. A procedure that authenticates two devices and creates a common link key that can be used as a basis for a trusted relationship or a (single) secure connection. The lowest architectural level used to offer independent data transport services to clients of the Bluetooth system. A procedure for retrieving the user-friendly name (the Bluetooth device name) of a connectable device. A method of Bluetooth one-way file transfer that is initiated by the entity that is providing the file. A Bluetooth device for which a link key has been created (either before connection establishment was requested or during connecting phase). A collection of devices occupying a shared physical channel where one of the devices is the Piconet Master and the remaining devices are connected to it. The BR/EDR device in a piconet whose Bluetooth Clock and Bluetooth Device Address are used to define the piconet physical channel characteristics. Any BR/EDR device in a piconet that is not the Piconet Master, but is connected to the Piconet Master. A user-friendly value that can be used to authenticate connections to a device before pairing has taken place. A transport protocol used in the Bluetooth protocol stack that emulates RS-232 serial port connections. A device that has a fixed relationship with another device and has full access to all services. A Bluetooth device for which no information (Bluetooth Device Address, link key or other) is stored. A device that does not have an established relationship with another Bluetooth device, which results in the untrusted device receiving restricted access to services.

The Target of Evaluation (TOE) in this PP-Module is a product that implements Bluetooth functionality. This PP-Module describes the extended security functionality of Bluetooth in terms of CC. This PP-Module extends the Protection Profile for General Purpose Operating Systems or Mobile Device Fundamentals. A compliant TOE will meet all mandatory SFRs defined in this PP-Module in addition to the mandatory SFRs of its claimed base PP. For each base PP, this PP-Module refines several of the base PP's SFRs so that they can accommodate the Bluetooth functionality defined by the PP-Module. A compliant TOE will claim all selection-based SFRs from this PP-Module and its base PP as needed based on the relevant selections in other requirements being chosen. Note that evaluation activities require certain tests to be performed against all radios present on the device. When the TOE also claims conformance to a PP-Configuration that includes this PP-Module, those tests are executed against the Bluetooth radio as well. Also note that each base PP defines its own requirements for protection of data at rest. When the TOE also claims conformance to a PP-Configuration that includes this PP-Module, any data that is used by the TOE's Bluetooth implementation is expected to be stored using the same protection mechanisms. The Bluetooth implementation is a logical component executing on an end user personal computing or mobile device. As such, the TOE must rely heavily on the TOE's operational environment (host platform, network stack, and operating system) for its execution domain and its proper usage. The TOE will rely on the IT environment to address much of the security functionality related to administrative functions. The physical boundary of the TOE includes the physical device on which it is installed, as this device will contain an internal or external Bluetooth radio that is used as the physical medium for transmitting and receiving data over the Bluetooth logical channel.

Requirements in this PP-Module are designed to address the security problems in at least the following use cases. These use cases are intentionally very broad, as many specific use cases exist within these larger categories. This use case is for a Bluetooth TOE that is part of a general-purpose operating system. Specifically, the Bluetooth TOE is expected to be part of the operating system itself and not a standalone third-party application that is installed on top of it. This use case is for a Bluetooth TOE that is part of a mobile operating system that runs on a mobile device. Specifically, the Bluetooth TOE is expected to be part of the mobile operating system itself and not a standalone third-party application that is acquired from the mobile vendor's application store.

exact extended extended Protection Profile for General Purpose Operating Systems, Version 5.0 Protection Profile for Mobile Device Fundamentals, Version 4.0 PP-Module for VPN Client, version 3.0 PP-Module for Bluetooth, version 2.0 PP-Module for MDM Agent, version 2.0 PP-Module for WLAN Client, version 2.0 cPP-Module for Biometric Enrolment and Verification, version 2.0 All threats, assumptions, organizational security policies, and/or objectives that apply to this PP-Module are inherited from the base PP to which the TOE also conforms. This PP-Module does not add or remove any elements to the security problem definition given in the base PP. The SFRs defined in this PP-Module provide additional mechanisms for mitigating the threats already defined in the base PPs due to the fact that including a Bluetooth implementation introduces a new external interface to the underlying general-purpose OS or mobile device platform. This PP-Module defines no additional threats beyond those defined in the base PPs. Note however that the SFRs defined in this PP-Module will assist in the mitigation of the following threats defined in the base PPs: See PP_MDF, Section 3.1 and PP_GPOS, Section 3.1. This threat comes directly from both base PPs. FMT_SMF_EXT.1 (modified from PP_MDF)Mitigates the threat of network eavesdrop by allowing the TSF to be configured to implement the functionality to enforce secure behavior. FMT_SMF_EXT.1/BT (additional to PP_MDF)Mitigates the threat of network eavesdrop by allowing the TSF to be configured to implement the functionality to enforce secure behavior. FMT_MOF_EXT.1 (modified from PP_GPOS)Mitigates the threat of network eavesdrop by allowing the TSF to be configured to implement the functionality to enforce secure behavior. FMT_MOF_EXT.1/BT (additional to PP_GPOS)Mitigates the threat of network eavesdrop by allowing the TSF to be configured to implement the functionality to enforce secure behavior. FMT_SMF_EXT.1 (modified from PP_GPOS)Mitigates the threat of network eavesdrop by allowing the TSF to be configured to implement the functionality to enforce secure behavior. FMT_SMF_EXT.1/BT (additional to PP_GPOS)Mitigates the threat of network eavesdrop by allowing the TSF to be configured to implement the functionality to enforce secure behavior. FCS_CKM_EXT.8Mitigates the threat by ensuring that key pairs are regenerated to reduce the risk of disclosure. FIA_BLT_EXT.3Mitigates the threat of network eavesdrop by preventing multiple requests to connect to the same Bluetooth device address. FIA_BLT_EXT.4Mitigates the threat of network eavesdrop by using Secure Simple Pairing to prevent the disclosure of Bluetooth connection parameters. FTP_BLT_EXT.1Mitigates the threat of network disclosure by enforcing the use of encryption for Bluetooth data in transit. FTP_BLT_EXT.2Mitigates the threat of network disclosure by ensuring that encryption is persisted for the entire duration of a Bluetooth connection. FTP_BLT_EXT.3/BRMitigates the threat of network disclosure by enforcing the use of appropriate encryption parameters for Bluetooth data in BR/EDR mode. FTP_BLT_EXT.3/LE (selection-based)Mitigates the threat of network disclosure by enforcing the use of appropriate encryption parameters for Bluetooth data in LE mode. FIA_BLT_EXT.5 (objective)Mitigates the threat of network disclosure by enforcing the use of Secure Connections Only mode to block insecure communications. See PP_MDF, Section 3.1 and PP_GPOS, Section 3.1. This threat comes directly from both base PPs. FMT_SMF_EXT.1 (modified from PP_MDF)Mitigates the threat of network eavesdrop by allowing the TSF to be configured to implement the functionality to enforce secure behavior. FMT_SMF_EXT.1/BT (additional to PP_MDF)Mitigates the threat of network eavesdrop by allowing the TSF to be configured to implement the functionality to enforce secure behavior. FMT_MOF_EXT.1 (modified from PP_GPOS)Mitigates the threat of network eavesdrop by allowing the TSF to be configured to implement the functionality to enforce secure behavior. FMT_MOF_EXT.1/BT (additional to PP_GPOS)Mitigates the threat of network eavesdrop by allowing the TSF to be configured to implement the functionality to enforce secure behavior. FMT_SMF_EXT.1 (modified from PP_GPOS)Mitigates the threat of network eavesdrop by allowing the TSF to be configured to implement the functionality to enforce secure behavior. FMT_SMF_EXT.1/BT (additional to PP_GPOS)Mitigates the threat of network eavesdrop by allowing the TSF to be configured to implement the functionality to enforce secure behavior. FAU_GEN.1/BTMitigates the threat of network attack by generating audit data that could be used to determine if an attack has occurred. FIA_BLT_EXT.1Mitigates the threat of network attack by blocking connections that do not have explicit authorization. FIA_BLT_EXT.2Mitigates the threat of network attack by enforcing mutual authentication so that unrecognized endpoints are not authorized. FIA_BLT_EXT.3Mitigates the threat of network attack by rejecting duplicate connections, which mitigates the risk of device impersonation. FIA_BLT_EXT.4Mitigates the threat of network attack by using Secure Simple Pairing to prevent unauthorized connections. FIA_BLT_EXT.6Mitigates the threat of network attack by preventing the TOE from establishing a connection with an unauthorized or unknown device. FIA_BLT_EXT.7Mitigates the threat of network attack by requiring certain services to be accessed only through explicit user authorization. No environmental security objectives have been identified that are specific to Bluetooth technology. However, any environmental security objectives defined in the base PPs will also apply to the portion of the TOE that implements Bluetooth. This chapter describes the security requirements which have to be fulfilled by the . Those requirements comprise functional components from Part 2 and assurance components from Part 3 of . The following notations are used: Refinement operation (denoted by bold text): Is used to add details to a requirement, and thus further restricts a requirement. Selection operation (denoted by italicized text): Is used to select one or more options provided by the [CC] in stating a requirement. Assignment operation (denoted by italicized text): Is used to assign a specific value to an unspecified parameter, such as the length of a password. Iteration operation: Identified with a slash followed by a unique text string (e.g. "/WLAN") or a number inside parentheses (e.g. "(1)") https://github.com/commoncriteria/mobile-device release-4.0 https://www.niap-ccevs.org/static_html/protection-profile/468/MDF%203.3%20PP/index.html

This SFR is unchanged from its definition in the base PP; the only change required by this PP-Module is how to interpret it in the context of Bluetooth capabilities. This PP-Module does not modify this SFR as it is defined in the PP_MDF. However, note that this PP-Module requires the list of radios specified in the assignment for management function 4 ("enable/disable [assignment: list of all radios]") to include Bluetooth radios. Bluetooth BR/EDR and Bluetooth LE will be listed separately if the TSF provides the ability to enable/disable them separately (i.e., if management function BT-3 below is claimed). Otherwise, both interfaces will be treated as one radio for that assignment.

The ST author is instructed to complete an assignment in the SFR with information related to Bluetooth, and to include additional management functions in this SFR based on the Bluetooth capability defined by the PP-Module. As is the case with the [PP_MDF], the first column lists the management function, the second column lists whether it is mandatory to implement the function and the remaining columns indicate whether it is mandatory, optional, or prohibited to implement the function by role as follows: The third column indicates functions that are to be restricted to the user (i.e. not available to the administrator). The fourth column indicates functions that are available to the administrator. These functions can still be available to the user, as long as the function is not restricted to the administrator (column 5). The fifth column indicates whether the function is to be restricted to the administrator when the device is enrolled and the administrator applies the indicated policy (i.e., MDM administration). This does not prevent the user from modifying a setting to make the function stricter, but the user cannot undo the configuration enforced by the administrator. For columns 2-5, an 'M' indicates that it is mandatory, an 'O' indicates that it is optional, and a '-' indicates that it is prohibited. (BT-1.) Management of the Discoverable and Advertising mode and management of the Bluetooth device name are mandatory. All other management functions for Bluetooth are currently objective. (BT-2. optional) Requires management of the Bluetooth device name separately for BR/EDR and LE radios. (BT-4. optional) May include disabling Wi-Fi being used as a part of Bluetooth High Speed and/or disabling NFC as an Out of Band pairing method for Bluetooth. May also include other wireless technologies beyond those already specified. (BT-8. optional) The Bluetooth services and/or profiles that may be disabled should be listed for the user or administrator either by service and/or profile name or by the types of applications for which the service and/or profile is used. (BT-9. optional) The minimum level of security permitted may be configurable for each individual pairing or for all Bluetooth pairings. If the TSF supports any of the BR/EDR security modes in the following list; it should provide a mechanism for the user to choose the minimum level of security to enforce for a particular device during the pairing process: Security Mode 1 (any level); Security Mode 2; (any level); Security Mode 3; (any level); Security Mode 4; Levels 0;1;2 (aside from the services permitted to use Mode 4; Level 0 in Bluetooth Core Specification version 4.2; Vol. 3; Part C; p. 325). If the TSF supports any of the LE security modes in the following list; it should provide a mechanism for the user to choose the minimum level of security to enforce for a particular device during the pairing process: Security Mode 1: Levels 1, 2; Security Mode 2, (any level). Examples of levels of security are the use of legacy pairing; the use of different types of Secure Simple Pairing; a requirement for Man-in-the-Middle protection; the enforcement of Secure Connections Only mode; etc. The evaluator shall ensure that the TSS includes a description of the Bluetooth profiles and services supported and the Bluetooth security modes and levels supported by the TOE. The evaluator shall ensure that the management functions defined in the PP-Module are described in the guidance to the same extent required for the base PP management functions. The evaluator shall use a Bluetooth-specific protocol analyzer to perform the following tests: If this PP-Module is used to extend the PP_MDF, the TOE type for the overall TOE is still a mobile device. However, one of the functions of the device must be the ability for it to have Bluetooth capability. The TOE boundary is simply extended to include that functionality. The threats that apply to this PP-Module are inherited from the base PP to which the TOE also conforms. This PP-Module does not add or remove any elements to the security problem definition given in the PP_MDF. The objectives that apply to this PP-Module are inherited from the base PP to which the TOE also conforms. This PP-Module does not add or remove any elements to the objectives given in the PP_MDF. This SFR extends the audit functionality already present in the base PP to address auditing of behavior that is specific to this PP-Module. This SFR applies to the frequency of key generation activity. This does not conflict with the base PP because it involves a key generation mechanism defined in the base PP and relates exclusively to Bluetooth functionality so it does not affect any other key generation activities required by the base PP. This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the base PP. This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the base PP. This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the base PP. This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the base PP. This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the base PP. This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the base PP. This SFR applies to encryption of Bluetooth communications. This is a trusted channel that is not discussed in the base PP, but it relies on the same cryptographic algorithms specified in the base PP to function. This SFR applies to encryption of Bluetooth communications. This is a trusted channel that is not discussed in the base PP, but it relies on the same cryptographic algorithms specified in the base PP to function. This SFR applies to encryption of Bluetooth communications. This is a trusted channel that is not discussed in the base PP, but it relies on the same cryptographic algorithms specified in the base PP to function. This SFR applies to encryption of Bluetooth communications. This is a trusted channel that is not discussed in the base PP, but it relies on the same cryptographic algorithms specified in the base PP to function. This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the base PP. https://github.com/commoncriteria/operatingsystem release-4.0 https://www.niap-ccevs.org/static_html/protection-profile/469/OS%204.3%20PP/index.html

This SFR is unchanged from its definition in the base PP; the only change required by this PP-Module is how to interpret it in the context of Bluetooth capabilities. There is no change to the text of this SFR. The SFR references FMT_SMF_EXT.1 and states that the OS shall permit the administrator role to perform the relevant functions listed in FMT_SMF_EXT.1. The function "Enable/Disable the Bluetooth interface" is listed as an optional management function in FMT_SMF_EXT.1 for both users and administrators. When this PP-Module is claimed, the administrator or user role must be able to enable/disable the Bluetooth interface. In other words, the function itself is moved from optional to mandatory, but this PP-Module does not require that it be implemented by a specific role. If the ST indicates that the administrator role can perform this function, then the restrictions imposed by FMT_MOF_EXT.1 will apply to it. This SFR is unchanged from its definition in the base PP; the only change required by this PP-Module is how to interpret it in the context of Bluetooth capabilities. This PP-Module does not modify this SFR as it is defined in the PP_GPOS. However, note that this PP-Module requires the function "Enable/disable Bluetooth interface" to be implemented, though this PP-Module does not mandate whether it be assigned to the Administrator or User role.

The ST author is required to associate all claimed management functions with the administrative privileges required to execute them. This PP-Module simply extends this requirement to apply to the management functions added and mandated by the PP-Module. The management functions in FMT_SMF_EXT.1/BT require the function BT-1 to be supported by the TOE and manageable by an Administrator at minimum. All other management functions, and what roles may perform them, are optional. The ST must make it clear which of these functions are provided by the TOE and which roles are able to manage them. The evaluator shall examine the TSS to ensure that it identifies the Bluetooth-related management functions that are supported by the TOE and the roles that are authorized to perform each function. The evaluator shall examine the operational guidance to ensure that it provides sufficient guidance on each supported Bluetooth management function to describe how the function is performed and any role restrictions on the subjects that are authorized to perform the function. For each function that is indicated as restricted to the administrator, the evaluation shall perform the function as an administrator, as specified in the Operational Guidance, and determine that it has the expected effect as outlined by the Operational Guidance and the SFR. The evaluator will then perform the function (or otherwise attempt to access the function) as a non-administrator and observe that they are unable to invoke that functionality. The ST author is required to include an optional management function defined in the base PP that relates to Bluetooth, and to include additional management functions in this SFR based on the Bluetooth capability defined by the PP-Module. The ST should indicate which of the optional management functions are implemented in the TOE. This can be done by adjusting the "Administrator" and "User" columns to "X" according to which capabilities are present or not present, and for which privilege level. (BT-1.) Management of the Discoverable and Advertising mode and management of the Bluetooth device name are mandatory. All other management functions for Bluetooth are currently objective. (BT-2. optional) Requires management of the Bluetooth device name separately for BR/EDR and LE radios. (BT-4. optional) May include disabling Wi-Fi being used as a part of Bluetooth High Speed and/or disabling NFC as an Out of Band pairing method for Bluetooth. May also include other wireless technologies beyond those already specified. (BT-8. optional) The Bluetooth services and/or profiles that may be disabled should be listed for the user or administrator either by service and/or profile name or by the types of applications for which the service and/or profile is used. (BT-9. optional) The minimum level of security permitted may be configurable for each individual pairing or for all Bluetooth pairings. If the TSF supports any of the BR/EDR security modes in the following list; it should provide a mechanism for the user to choose the minimum level of security to enforce for a particular device during the pairing process: Security Mode 1 (any level); Security Mode 2; (any level); Security Mode 3; (any level); Security Mode 4; Levels 0;1;2 (aside from the services permitted to use Mode 4; Level 0 in Bluetooth Core Specification version 4.2; Vol. 3; Part C; p. 325). If the TSF supports any of the LE security modes in the following list; it should provide a mechanism for the user to choose the minimum level of security to enforce for a particular device during the pairing process: Security Mode 1: Levels 1, 2; Security Mode 2, (any level). Examples of levels of security are the use of legacy pairing; the use of different types of Secure Simple Pairing; a requirement for Man-in-the-Middle protection; the enforcement of Secure Connections Only mode; etc. The evaluator shall ensure that the TSS includes a description of the Bluetooth profiles and services supported and the Bluetooth security modes and levels supported by the TOE. If function BT-4, "Allow/disallow additional wireless technologies to be used with Bluetooth," is selected, the evaluator shall verify that the TSS describes any additional wireless technologies that may be used with Bluetooth, which may include Wi-Fi with Bluetooth High Speed and/or NFC as an Out of Band pairing mechanism. If function BT-5, "Configure allowable methods of Out of Band pairing (for BR/EDR and LE)," is selected, the evaluator shall verify that the TSS describes when Out of Band pairing methods are allowed and which ones are configurable. If function BT-8, "Disable/enable the Bluetooth services and/or profiles available on the OS (for BR/EDR and LE)," is selected, the evaluator shall verify that all supported Bluetooth services are listed in the TSS as manageable and, if the TOE allows disabling by application rather than by service name, that a list of services for each application is also listed. If function BT-9, "Specify minimum level of security for each pairing (for BR/EDR and LE)," is selected, the evaluator shall verify that the TSS describes the method by which the level of security for pairings are managed, including whether the setting is performed for each pairing or is a global setting. The evaluator shall ensure that the management functions defined in the PP-Module are described in the guidance to the same extent required for the base PP management functions. The evaluator shall use a Bluetooth-specific protocol analyzer to perform the following tests: If this PP-Module is used to extend the [PP_GPOS], the TOE type for the overall TOE is still a generic operating system. However, one of the functions of the generic operating system must be the ability for it to have Bluetooth capability. The TOE boundary is simply extended to include that functionality. The threats that apply to this PP-Module are inherited from the base PP to which the TOE also conforms. This PP-Module does not add or remove any elements to the security problem definition given in the PP_GPOS. The objectives that apply to this PP-Module are inherited from the base PP to which the TOE also conforms. This PP-Module does not add or remove any elements to the objectives given in the PP_GPOS. This SFR extends the audit functionality already present in the base PP to address auditing of behavior that is specific to this PP-Module. This SFR applies to the frequency of key generation activity. This does not conflict with the base PP because it involves a key generation mechanism defined in the base PP and relates exclusively to Bluetooth functionality so it does not affect any other key generation activities required by the base PP. This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the base PP. This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the base PP. This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the base PP. This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the base PP. This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the base PP. This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the base PP. This SFR applies to encryption of Bluetooth communications. This is a trusted channel that is not discussed in the base PP, but it relies on the same cryptographic algorithms specified in the base PP to function. This SFR applies to encryption of Bluetooth communications. This is a trusted channel that is not discussed in the base PP, but it relies on the same cryptographic algorithms specified in the base PP to function. This SFR applies to encryption of Bluetooth communications. This is a trusted channel that is not discussed in the base PP, but it relies on the same cryptographic algorithms specified in the base PP to function. This SFR applies to encryption of Bluetooth communications. This is a trusted channel that is not discussed in the base PP, but it relies on the same cryptographic algorithms specified in the base PP to function. This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the base PP.

The PP-Module defines auditable events for Bluetooth that extends the audit functionality defined in each base PP. It is not feasible for the FIA_BLT_EXT.3 event to be audited if the rejection is performed at the HCI layer because the Bluetooth standard does not provide a notification interface for this behavior in the HCI. This is why the event is labeled as optional. However, if the rejection is performed above the HCI layer, it is expected that a conformant TOE should implement this functionality. There are additional auditable events that serve to extend the FAU_GEN.1 SFR found in each base PP. This SFR is evaluated in the same manner as defined by the Evaluation Activities for the claimed base PP. The only difference is that the evaluator shall also assess the auditable events required for this PP-Module in addition to those defined in the claimed base PP. Components in this family define requirements for cryptographic key management beyond those which are specified in the Part 2 family FCS_CKM. requires the TSF to generate key pairs used for Bluetooth over a specified time period or in response to some observed event. No specific management functions are identified. There are no auditable events foreseen. FCS_CKM.1 Cryptographic Key Generation FPT_STM.1 Reliable Time Stamps FTP_BLT_EXT.1 Bluetooth Encryption There are multiple acceptable ways of keeping ECDH key pairs adequately fresh, including a time-based approach such that the same key pairs will not be used for more than, for instance, 24 hours. Alternatively, the criteria might be linked to the number of passed or failed authentication attempts. As a starting point to determine reasonable authentication attempt-based replacement criteria, note that the Bluetooth specification (v4.1, Vol. 2, 5.1) suggests mitigating repeated authentication attempts by changing a device's private key after three failed authentication attempts from any BD_ADDR, after ten successful pairings from any BD_ADDR, or after a combination of these such that any three successful pairings count as one failed pairing. This requirement also applies to Bluetooth LE if the TOE supports LE Secure Connections, which was introduced in version 4.2 of the specification. The evaluator shall ensure that the TSS describes the criteria used to determine the frequency of generating new ECDH public/private key pairs. In particular, the evaluator shall ensure that the implementation does not permit the use of static ECDH key pairs. There are no guidance evaluation activities for this component. The evaluator shall perform the following steps: Step 1: Pair the TOE to a remote Bluetooth device and record the public key currently in use by the TOE. (This public key can be obtained using a Bluetooth protocol analyzer to inspect packets exchanged during pairing.) Step 2: Perform necessary actions to generate new ECDH public/private key pairs. (Note that this test step depends on how the TSS describes the criteria used to determine the frequency of generating new ECDH public/private key pairs.) Step 3: Pair the TOE to a remote Bluetooth device and again record the public key currently in use by the TOE. Step 4: Verify that the public key in Step 1 differs from the public key in Step 3. Components in this family define Bluetooth-specific identification and authentication requirements. requires the TSF to have explicit user authorization before allowing a Bluetooth pairing. No specific management functions are identified. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Failed user authorization of Bluetooth device. Failed user authorization for local Bluetooth device. No dependencies. User authorization includes explicit actions like affirming the remote device's name, expressing an intent to connect to the remote device, and entering relevant pairing information (e.g. PINs; numeric codes; or "yes/no" responses). The user must have to explicitly permit all pairing attempts; even when bonding is not taking place. Explicit user action must be required to permit pairing. It must not be possible for applications to programmatically enter pairing information (e.g., PINs; numeric codes; or "yes/no" responses) during the pairing process. The absence of public APIs for programmatic authorization is not sufficient to meet this requirement; hidden or private APIs must be absent as well. The evaluator shall examine the TSS to ensure that it contains a description of when user permission is required for Bluetooth pairing; and that this description mandates explicit user authorization via manual input for all Bluetooth pairing; including application use of the Bluetooth trusted channel and situations where temporary (non-bonded) connections are formed. The evaluator shall examine the API documentation provided as a means of satisfying the requirements for the ADV assurance class (see section 5.2.2 in the PP_MDF and PP_GPOS) and verify that this API documentation does not include any API for programmatic entering of pairing information (e.g. PINs; numeric codes; or "yes/no" responses) intended to bypass manual user input during pairing. The evaluator shall examine the guidance to verify that these user authorization screens are clearly identified and instructions are given for authorizing Bluetooth pairings. The evaluator shall perform the following steps: Step 1: Initiate pairing with the TOE from a remote Bluetooth device that requests no man-in-the-middle protection; no bonding; and claims to have NoInput/NoOutput (IO) capability. Such a device will attempt to evoke behavior from the TOE that represents the minimal level of user interaction that the TOE supports during pairing. Step 2: Verify that the TOE does not permit any Bluetooth pairing without explicit authorization from the user (e.g. the user must have to minimally answer "yes" or "allow" in a prompt). Failed user authorization of Bluetooth device. User authorization decision (e.g., user rejected connection, incorrect pin entry). Failed user authorization for local Bluetooth Service. complete last integer greater than or equal to 2 octets of the BD_ADDR and name of device uniquely generated nonce for each pairing no other information. Bluetooth profile. Identity of local service with service ID profile name requires the TSF to enforce mutual authentication for Bluetooth. No specific management functions are identified. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Initiation of Bluetooth connection. Failure of Bluetooth connection. FIA_BLT_EXT.1 Bluetooth User Authorization If devices are not already paired, the pairing process must be initiated. If the devices are already paired, mutual authentication based on the current link key must succeed before any data passes over the link. The evaluator shall ensure that the TSS describes how data transfer of any type is prevented before the Bluetooth pairing is completed. The TSS shall specifically call out any supported RFCOMM and L2CAP data transfer mechanisms. The evaluator shall ensure that the data transfers are only completed after the Bluetooth devices are paired and mutually authenticated. There are no guidance evaluation activities for this component. The evaluator shall use a Bluetooth tool to attempt to access TOE files using the OBEX Object Push service (OBEX Push) and verify that pairing and mutual authentication are required by the TOE before allowing access. If the OBEX Object Push service is unsupported on the TOE; a different service that transfers data over Bluetooth L2CAP and/or RFCOMM may be used in this test. Initiation of Bluetooth connection. complete last integer greater than or equal to 2 octets of the BD_ADDR and name of device uniquely generated nonce for each pairing no other information. Failure of Bluetooth connection. Reason for failure. requires the TSF to reject duplicate attempts to connect to Bluetooth. No specific management functions are identified. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Duplicate connection attempt. FIA_BLT_EXT.1 Bluetooth User Authorization Session is defined as the time interval for which the TSF is actively connected to another device. Thus, the session terminates when the device disconnects from the TSF. If the TOE has an active session to a remote Bluetooth device, new session initialization and/or pairing attempts from devices claiming the same Bluetooth device address may be malicious and should be rejected/ignored. Only one session to a single remote BD_ADDR may be supported at a time. The evaluator shall ensure that the TSS describes how Bluetooth sessions are maintained such that at least two devices with the same Bluetooth device address are not simultaneously connected and such that the initial session is not superseded by any following session initialization attempts. There are no guidance evaluation activities for this component. The evaluator shall perform the following steps: Step 1: Pair the TOE with a remote Bluetooth device (DEV1) with a known address BD_ADDR. Establish an active session between the TOE and DEV1 with the known address BD_ADDR. Step 2: Attempt to pair a second remote Bluetooth device (DEV2) claiming to have a Bluetooth device address matching DEV1 BD_ADDR to the TOE. Using a Bluetooth protocol analyzer, verify that the pairing attempt by DEV2 is not completed by the TOE and that the active session to DEV1 is unaffected. Step 3: Attempt to initialize a session to the TOE from DEV2 containing address DEV1 BD_ADDR. Using a Bluetooth protocol analyzer, verify that the session initialization attempt by DEV2 is ignored by the TOE and that the initial session to DEV1 is unaffected. Duplicate connection attempt. complete last integer greater than or equal to 2 octets of the BD_ADDR of connection attempt. requires the TSF to support Secure Simple Pairing. No specific management functions are identified. There are no auditable events foreseen. FIA_BLT_EXT.1 Bluetooth User Authorization The Bluetooth host and controller each support a particular version of the Bluetooth Core Specification and a particular set of features. Support for various features is indicated by each side during the Link Manager Protocol (LMP) Features Exchange. Refer to the Bluetooth specification [Bluetooth] for feature definitions, including the definitions of Secure Simple Pairing (Controller Support) and Secure Simple Pairing (Host Support). The evaluator shall verify that the TSS describes the secure simple pairing process. There are no guidance evaluation activities for this component. The evaluator shall perform the following steps: Step 1: Initiate pairing with the TOE from a remote Bluetooth device that supports Secure Simple Pairing. Step 2: During the pairing process; observe the packets in a Bluetooth protocol analyzer and verify that the TOE claims support for both "Secure Simple Pairing (Host Support)" and "Secure Simple Pairing (Controller Support)" during the LMP Features Exchange. Step 3: Verify that Secure Simple Pairing is used during the pairing process. requires the TSF to have explicit user authentication before associating trusted services with Bluetooth. The following actions could be considered for the management functions in FMT: Ability to specify the services that require explicit user authorization before trusted devices can use them. There are no auditable events foreseen. FIA_BLT_EXT.1 Bluetooth User Authorization In addition to pairing, it may be appropriate to require explicit user action to authorize a particular remote device to access certain Bluetooth services. The TSF may choose to require this additional action for all devices or only for those devices that do not have a required level of trust. It is strongly preferred that for each device, the TSF maintains a list of devices trusted to use for that particular service. However, the TSF might designate certain devices as having a trusted device relationship with the TOE and granting them "blanket" access to all services. Furthermore, it may be the case that the TSF allows movement of devices from the untrusted to the trusted category for a particular service after the user provides explicit authorization for the device to use the service. For example, it may be appropriate to require that the user provide explicit, manual authorization before a remote device may use the OBEX service for an object transfer the first time. The user might be given the option to permit future connections to that service by the particular device without requiring explicit authorization each time. The evaluator shall verify that the TSS describes all Bluetooth profiles and associated services for which explicit user authorization is required before a remote device can gain access. The evaluator shall also verify that the TSS describes any difference in behavior based on whether or not the device has a trusted relationship with the TOE for that service (i.e. whether there are any services that require explicit user authorization for untrusted devices that do not require such authorization for trusted devices). The evaluator shall also verify that the TSS describes the method by which a device can become 'trusted'. There are no guidance evaluation activities for this component. The evaluator shall perform the following tests: While the service is in active use by an application on the TOE, the evaluator shall attempt to gain access to a "protected" Bluetooth service (as specified in the assignment in FIA_BLT_EXT.6.1) from a "trusted" remote device. The evaluator shall verify that the user is explicitly asked for authorization by the TOE to allow access to the service for the particular remote device. The evaluator shall deny the authorization on the TOE and verify that the remote attempt to access the service fails due to lack of authorization. The evaluator shall repeat Test 1, this time allowing the authorization and verifying that the remote device successfully accesses the service. requires the TSF to have explicit user authentication before associating untrusted services with Bluetooth. The following actions could be considered for the management functions in FMT: Ability to specify the services that require explicit user authorization before untrusted devices can use them. There are no auditable events foreseen. FIA_BLT_EXT.1 Bluetooth User Authorization FIA_BLT_EXT.7 differs from FIA_BLT_EXT.6 because a conformant TOE may distinguish between "trusted" and "untrusted" devices such that the TSF grants "untrusted" devices access to fewer services following pairing. However, this behavior is not required; if the TSF does not treat "trusted" and "untrusted" devices any differently, the ST author may complete the assignments in FIA_BLT_EXT.6.1 and FIA_BLT_EXT.7.1 with lists of Bluetooth profiles. The TSS evaluation activities for this component are addressed by FIA_BLT_EXT.6. There are no guidance evaluation activities for this component. The evaluator shall perform the following tests if the TSF differentiates between "trusted" and "untrusted" devices for the purpose of granting access to services. If it does not, then the test evaluation activities for FIA_BLT_EXT.6 are sufficient to satisfy this component. While the service is in active use by an application on the TOE, the evaluator shall attempt to gain access to a "protected" Bluetooth service (as specified in the assignment in FIA_BLT_EXT.7.1) from an "untrusted" remote device. The evaluator shall verify that the user is explicitly asked for authorization by the TOE to allow access to the service for the particular remote device. The evaluator shall deny the authorization on the TOE and verify that the remote attempt to access the service fails due to lack of authorization. The evaluator shall repeat Test 1, this time allowing the authorization and verifying that the remote device successfully accesses the service. (conditional): If there exist any services that require explicit user authorization for access by untrusted devices but not by trusted devices (i.e. a service that is listed in FIA_BLT_EXT.7.1 but not FIA_BLT_EXT.6.1), the evaluator shall repeat Test 1 for these services and observe that the results are identical. That is, the evaluator shall use these results to verify that explicit user approval is required for an untrusted device to access these services, and failure to grant this approval will result in the device being unable to access them. (conditional): If test 3 applies, the evaluator shall repeat Test 2 using any services chosen in Test 3 and observe that the results are identical. That is, the evaluator shall use these results to verify that explicit user approval is required for an untrusted device to access these services, and granting this approval will result in the device being able to access them. (conditional): If test 3 applies, the evaluator shall repeat Test 3 except this time designating the device as "trusted" prior to attempting to access the service. The evaluator shall verify that access to the service is granted without explicit user authorization (because the device is now trusted and therefore FIA_BLT_EXT.7.1 no longer applies to it). That is, the evaluator shall use these results to demonstrate that the TSF will grant a device access to different services depending on whether or not the device is trusted. Components in this family define requirements for Bluetooth encryption. requires the TSF to enforce encryption when transmitting over Bluetooth. No specific management functions are identified. There are no auditable events foreseen. FCS_CKM_EXT.8 Bluetooth Key Generation FIA_BLT_EXT.1 Bluetooth User Authorization LE is selectable because not all conformant TOEs include support for LE. If LE is supported, it is expected that the TSF be able to provide encryption for this interface. Selection of LE in FTP_BLT_EXT.1.1 requires the inclusion of the selection-based SFR FTP_BLT_EXT.3/LE. The evaluator shall verify that the TSS describes the use of encryption, the specific Bluetooth protocol(s) it applies to, and whether it is enabled by default. The evaluator shall verify that the TSS includes the protocol used for encryption of the transmitted data and the key generation mechanism used. The evaluator shall verify that the operational guidance includes instructions on how to configure the TOE to require the use of encryption during data transmission (unless this behavior is enforced by default). There are no test EAs for this component. Testing for this SFR is addressed through the evaluation of FTP_BLT_EXT.3/BR and, if claimed, FTP_BLT_EXT.3/LE. requires the TSF to ensure encryption for the duration of the use of the Bluetooth channel. No specific management functions are identified. There are no auditable events foreseen. FTP_BLT_EXT.1 Bluetooth Encryption Permitting devices to terminate and/or restart encryption in the middle of a connection weakens user data protection. Note that an encryption pause request, which includes a request to stop encryption, stops encryption only temporarily. This requirement is not intended to address the encryption pause feature. The evaluator shall verify that the TSS describes the TSF's behavior if a remote device stops encryption while connected to the TOE. The evaluator shall verify that the operational guidance describes how to enable/disable encryption (if configurable). The evaluator shall perform the following steps using a Bluetooth protocol analyzer to observe packets pertaining to the encryption key size: Step 1: Initiate pairing with the TOE from a remote Bluetooth device that has been configured to have a minimum encryption key size that is equal to or greater than that of the TOE. Step 2: After pairing has successfully finished and while a connection exists between the TOE and the remote device; turn off encryption on the remote device. This can be done using commercially-available tools. Step 3: Verify that the TOE either restarts encryption with the remote device or terminates the connection with the remote device. specifies the key sizes used for Bluetooth. The following actions could be considered for the management functions in FMT: Specification of minimum encryption key size. There are no auditable events foreseen. FTP_BLT_EXT.1 Bluetooth Encryption Encryption is mandatory for BR/EDR connections when both devices support Secure Simple Pairing. Minimum encryption requirements will be set and verified for each Bluetooth profile/application. However, when the TOE is in the Bluetooth Observer role, one-way devices (e.g., unconnectable Bluetooth Broadcasters) can send unencrypted communications (e.g., beacon or advertisement messages) to the TOE and the TOE can accept them because they are outside the Trusted Channel. The evaluator shall examine the TSS and verify that it specifies the minimum key size for BR/EDR encryption, whether this value is configurable, and the mechanism by which the TOE will not negotiate keys sizes smaller than the minimum. The evaluator shall verify that the guidance includes instructions on how to configure the minimum encryption key size for BR/EDR encryption, if configurable. The evaluator shall perform the following tests: The evaluator shall perform the following steps using a Bluetooth protocol analyzer to observe packets pertaining to the encryption key size: Step 1: Initiate BR/EDR pairing with the TOE from a remote Bluetooth device that has been configured to have a minimum encryption key size that is equal to or greater than that of the TOE. This can be done using certain commercially-available tools that can send the appropriate command to certain commercially-available Bluetooth controllers. Step 2: Use a Bluetooth packet sniffer to verify that the encryption key size negotiated for the connection is at least as large as the minimum encryption key size defined for the TOE. (conditional): If the encryption key size is configurable, configure the TOE to support a different minimum key size, then repeat Test 1 and verify that the negotiated key size is at least as large as the new minimum value. The evaluator shall perform the following steps using a Bluetooth protocol analyzer to observe packets pertaining to the encryption key size: Step 1: Initiate BR/EDR pairing with the TOE from a remote Bluetooth device that has been configured to have a maximum encryption key size of 1 byte. This can be done using certain commercially-available tools that can send the appropriate command to certain commercially-available Bluetooth controllers. Step 2: Verify that the encryption key size suggested by the remote device is not accepted by the TOE and that the connection is not completed.

The TOE must implement encryption for Bluetooth BR/EDR as required by FTP_BLT_EXT.1.1. A conformant TOE does not need to support Bluetooth LE; however, if it does, then it must also support encryption for it. FTP_BLT_EXT.3/LE must therefore be claimed if 'LE' is selected in FTP_BLT_EXT.1.1. The evaluator shall examine the TSS and verify that it specifies the minimum key size for LE encryption, whether this value is configurable, and the mechanism by which the TOE will not negotiate keys sizes smaller than the minimum. The evaluator shall verify that the guidance includes instructions on how to configure the minimum encryption key size for LE encryption, if configurable. The evaluator shall perform the following tests: The evaluator shall perform the following steps using a Bluetooth protocol analyzer to observe packets pertaining to the encryption key size: Step 1: Initiate LE pairing with the TOE from a remote Bluetooth device that has been configured to have a minimum encryption key size that is equal to or greater than that of the TOE. This can be done using certain commercially-available tools that can send the appropriate command to certain commercially-available Bluetooth controllers. Step 2: Use a Bluetooth packet sniffer to verify that the encryption key size negotiated for the connection is at least as large as the minimum encryption key size defined for the TOE. (conditional): If the encryption key size is configurable, configure the TOE to support a different minimum key size, then repeat Test 1 and verify that the negotiated key size is at least as large as the new minimum value. The evaluator shall perform the following steps using a Bluetooth protocol analyzer to observe packets pertaining to the encryption key size: Step 1: Initiate LE pairing with the TOE from a remote Bluetooth device that has been configured to have a maximum encryption key size of 1 byte. This can be done using certain commercially-available tools that can send the appropriate command to certain commercially-available Bluetooth controllers. Step 2: Verify that the encryption key size suggested by the remote device is not accepted by the TOE and that the connection is not completed.

requires the TSF to support Secure Connections Only mode. No specific management functions are identified. There are no auditable events foreseen. FIA_BLT_EXT.1 Bluetooth User Authorization The specification states that Secure Connections Only Mode, also called "FIPS Mode," should be used when security is more important than backwards compatibility. From the specification, "The Host will enforce that the P-256 elliptic curve is used during pairing; the secure authentication sequences are used; and AES-CCM is used for encryption." Also, "if a BR/EDR/LE device is configured in Secure Connections Only Mode, then a transport will only be used when Secure Connections is supported by both devices." The evaluator shall ensure that the TSS describes support for Secure Connections Only mode for BR/EDR and, if supported, Bluetooth LE. The evaluator shall ensure that the guidance includes instructions on how to place the TOE into Secure Connections Only mode for BR/EDR and, if supported, Bluetooth LE. The evaluator shall perform the following tests, once for BR/EDR and once for LE (if applicable): The evaluator shall place the TOE into Secure Connections Only mode. The evaluator shall then attempt a pairing to a remote device that does not support Secure Connections Only mode and verify that the attempt fails. The evaluator shall place the TOE into Secure Connections Only mode. The evaluator shall attempt a pairing to a remote device that supports Secure Connections Only mode and has it enabled. The evaluator shall verify that the pairing attempt succeeds. The evaluator shall also use a Bluetooth packet sniffer to verify that the parameters of the pairing and encryption are consistent with Secure Connections. As indicated in , the baseline requirements (those that must be performed by the TOE are contained in the body of this PP. Additionally, there are three other types of requirements specified in , , and . The first type (in this appendix) are requirements that can be included in the , but are not required in order for a TOE to claim conformance to this PP-Module. The second type (in ) are requirements based on selections in the body of the PP-Module: if certain selections are made, then additional requirements in that appendix must be included. The third type (in are components that are not required in order to conform to this PP-Module, but will be included in the baseline requirements in future versions of this PP-Module, so adoption by vendors is encouraged. As indicated in the introduction to this PP-Module, the baseline requirements are contained in the body of this PP-Module. There are additional requirements based on selections in the body of the PP-Module: if certain selections are made, then additional requirements below will need to be included. This appendix includes requirements that specify security functionality which also addresses threats. The requirements are not currently mandated in the body of this PP-Module as they describe security functionality not yet widely available in commercial technology. However, these requirements may be included in the ST such that the TOE is still conformant to this PP-Module, and it is expected that they be included as soon as possible. This appendix lists requirements that should be considered satisfied by products successfully evaluated against this PP-Module. However, these requirements are not featured explicitly as SFRs and should not be included in the ST. They are not included as standalone SFRs because it would increase the time, cost, and complexity of evaluation. This approach is permitted by [CC] Part 1, 8.2 Dependencies between components. This information benefits systems engineering activities which call for inclusion of particular security controls. Evaluation against the PP-Module provides evidence that these controls are present and have been evaluated. Requirement Rationale for Satisfaction FCS_CKM.1 - Cryptographic Key Generation FCS_CKM_EXT.8 has a dependency on FCS_CKM.1 for the generation of ECDH key pairs. This dependency is implicitly satisfied in this PP-Module because both base PPs the PP-Module is intended to extend define this SFR and specify ECDH key generation as a required capability of the TOE. Therefore, a conformant TOE will always have this capability. FPT_STM.1 - Reliable Time Stamps FCS_CKM_EXT.8 has a dependency on FPT_STM.1 because key generation may be triggered by a given time period elapsing. When the TOE claims conformance to , this dependency is satisfied explicitly through the base PP's definition of FPT_STM.1. When the TOE claims conformance to , this dependency is satisfied implicitly through that PP's A.PLATFORM assumption of a trustworthy computing platform, which can be reasonably assumed to include a hardware real-time clock. The TOE does not require any additional supplementary information to describe its entropy sources beyond the requirements outlined in the base PPs. CSA Computer Security Act of 1987, H.R. 145, June 11, 1987. Errata Errata and Interpretation for CC:2022 (Release 1) and CEM:2022 (Release 1) OMB Reporting Incidents Involving Personally Identifiable Information and Incorporating the Cost for Security in Agency Information Technology Investments, OMB M-06-19, July 12, 2006.