Comment: Comment-1-
Comment: Comment-2-
Comment: Comment-3-
Comment: Comment-4-

PP-Module for Bluetooth

NIAP Logo
Version: 2.0
2025-01-31
National Information Assurance Partnership

Revision History

VersionDateComment
1.02021-04-15Initial Release
2.02025-01-31Updates based on CC:2022

Contents

1Introduction1.1Overview1.2Terms1.2.1Common Criteria Terms1.2.2Technical Terms1.3Compliant Targets of Evaluation1.3.1TOE Boundary1.4Use Cases2Conformance Claims3Security Problem Definition3.1Threats3.2Assumptions3.3Organizational Security Policies4Security Objectives4.1Security Objectives for the Operational Environment5Security Requirements5.1 Protection Profile for Mobile Device Fundamentals Security Functional Requirements Direction 5.1.1 Modified SFRs 5.1.1.1Security Management (FMT)5.1.2 Additional SFRs5.1.2.1Auditable Events for Additional SFRs when MDF is the Base-PP5.1.2.2Security Management (FMT)5.2 Protection Profile for General Purpose Operating System Security Functional Requirements Direction 5.2.1 Modified SFRs 5.2.1.1Security Management (FMT)5.2.2 Additional SFRs5.2.2.1Auditable Events for Additional SFRs when GPOS is the Base-PP5.2.2.2Security Management (FMT)5.3TOE Security Functional Requirements5.3.1Auditable Events for Mandatory SFRs5.3.2Security Audit (FAU)5.3.3Cryptographic Support (FCS)5.3.4Identification and Authentication (FIA)5.3.5Trusted Path/Channels (FTP)5.4TOE Security Functional Requirements Rationale6Consistency Rationale6.1 Protection Profile for Mobile Device Fundamentals6.1.1 Consistency of TOE Type 6.1.2 Consistency of Security Problem Definition 6.1.3 Consistency of OE Objectives 6.1.4 Consistency of Requirements 6.2 Protection Profile for General Purpose Operating System6.2.1 Consistency of TOE Type 6.2.2 Consistency of Security Problem Definition 6.2.3 Consistency of OE Objectives 6.2.4 Consistency of Requirements Appendix A - Optional SFRsA.1Strictly Optional Requirements A.2Objective Requirements A.2.1Auditable Events for Objective SFRsA.2.2Identification and AuthenticationA.3Implementation-dependent Requirements Appendix B - Selection-based Requirements B.1Auditable Events for Selection-based SFRsB.2Trusted Path/ChannelsAppendix C - Extended Component DefinitionsC.1Extended Components TableC.2Extended Component DefinitionsC.2.1Cryptographic Support (FCS)C.2.1.1FCS_CKM_EXT Cryptographic Key ManagementC.2.2Identification and Authentication (FIA)C.2.2.1FIA_BLT_EXT Bluetooth PairingC.2.3Trusted Path/Channels (FTP)C.2.3.1FTP_BLT_EXT Bluetooth Trusted CommunicationsAppendix D - Implicitly Satisfied RequirementsAppendix E - Entropy Documentation and AssessmentAppendix F - AcronymsAppendix G - Bibliography

1 Introduction

1.1 Overview

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:

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.

1.2 Terms

The following sections list Common Criteria and technology terms used in this document.

1.2.1 Common Criteria Terms

Assurance
Grounds for confidence that a TOE meets the SFRs [CC].
Base Protection Profile (Base-PP)
Protection Profile used as a basis to build a PP-Configuration.
Collaborative Protection Profile (cPP)
A Protection Profile developed by international technical communities and approved by multiple schemes.
Common Criteria (CC)
Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408).
Common Criteria Testing Laboratory
 Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations.
Common Evaluation Methodology (CEM)
Common Evaluation Methodology for Information Technology Security Evaluation.
Distributed TOE
A TOE composed of multiple components operating as a logical whole.
Extended Package (EP)
A deprecated document form for collecting SFRs that implement a particular protocol, technology, or functionality. See Functional Packages.
Functional Package (FP)
A document that collects SFRs for a particular protocol, technology, or functionality.
Operational Environment (OE)
Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy.
Protection Profile (PP)
An implementation-independent set of security requirements for a category of products.
Protection Profile Configuration (PP-Configuration)
A comprehensive set of security requirements for a product type that consists of at least one Base-PP and at least one PP-Module.
Protection Profile Module (PP-Module)
An implementation-independent statement of security needs for a TOE type complementary to one or more Base-PPs.
Security Assurance Requirement (SAR)
A requirement to assure the security of the TOE.
Security Functional Requirement (SFR)
A requirement for security enforcement by the TOE.
Security Target (ST)
A set of implementation-dependent security requirements for a specific product.
Target of Evaluation (TOE)
The product under evaluation.
TOE Security Functionality (TSF)
The security functionality of the product under evaluation.
TOE Summary Specification (TSS)
A description of how a TOE satisfies the SFRs in an ST.

1.2.2 Technical Terms

Authentication
Verifying the identity of communicating devices based on their Bluetooth address. Bluetooth does not provide native user authentication.
Authorization
Allowing the control of resources by ensuring that a device is authorized to use a service before permitting it to do so.
BD_ADDR
The Bluetooth device Address, which is used to identify a Bluetooth device.
BR/EDR
Bluetooth basic rate (BR) and enhanced data rate (EDR).
BR/EDR Controller
A term referring to the Bluetooth Radio, Baseband, Link Manager, and HCI layers.
BR/EDR Piconet Physical Channel
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).
Bluetooth
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.
Bluetooth Baseband
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.
Bluetooth Controller
A generic term referring to a Primary Controller with or without a Secondary Controller.
Bluetooth Device
A device that is capable of short-range wireless communications using the Bluetooth system.
Bluetooth Device Address
A 48 bit address used to identify each Bluetooth device.
Connect (to service)
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.
Connectable device
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.
Connected devices
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.
Connection
An interaction between two peer applications or higher layer protocols mapped onto an L2CAP channel.
Connection establishment
A procedure for creating a connection mapped onto a channel.
Connection event
A series of one or more pairs of interleaving data packets sent between a master and a slave on the same physical channel.
Creation of a secure connection
A procedure of establishing a connection, including authentication and encryption.
Creation of a trusted relationship
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.
Device discovery
A procedure for retrieving the Bluetooth device address, clock, class-of-device field and used page scan mode from discoverable devices.
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.
Discoverable device
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.
Discovery procedure
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.
Host
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.
L2CAP Channel
A logical connection on L2CAP level between two devices serving a single application or higher layer protocol.
L2CAP Channel establishment
A procedure for establishing a logical connection on L2CAP level.
LMP authentication
An LMP level procedure for verifying the identity of a remote device.
LMP pairing
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.
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.
A data link protocol used in the Bluetooth protocol stack.
The lowest architectural level used to offer independent data transport services to clients of the Bluetooth system.
Name discovery
A procedure for retrieving the user-friendly name (the Bluetooth device name) of a connectable device.
OBEX Push
A method of Bluetooth one-way file transfer that is initiated by the entity that is providing the file.
PIN
A user-friendly value that can be used to authenticate connections to a device before pairing has taken place.
Paired device
A Bluetooth device for which a link key has been created (either before connection establishment was requested or during connecting phase).
Piconet
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.
Piconet Master
The BR/EDR device in a piconet whose Bluetooth Clock and Bluetooth Device Address are used to define the piconet physical channel characteristics.
Piconet Slave
Any BR/EDR device in a piconet that is not the Piconet Master, but is connected to the Piconet Master.
RFCOMM
A transport protocol used in the Bluetooth protocol stack that emulates RS-232 serial port connections.
Trusted Device
A device that has a fixed relationship with another device and has full access to all services.
Unknown device
A Bluetooth device for which no information (Bluetooth Device Address, link key or other) is stored.
Untrusted Device
A device that does not have an established relationship with another Bluetooth device, which results in the untrusted device receiving restricted access to services.

1.3 Compliant Targets of Evaluation

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 [MDF] 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.

1.3.1 TOE Boundary

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.

1.4 Use Cases

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.
[USE CASE 1] General-Purpose Operating System
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.
[USE CASE 2] Mobile Device
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.

2 Conformance Claims

Conformance Statement

An ST must claim exact conformance to this PP-Module.

The evaluation methods used for evaluating the TOE are a combination of the workunits defined in [CEM] as well as the Evaluation Activities for ensuring that individual SFRs and SARs have a sufficient level of supporting evidence in the Security Target and guidance documentation and have been sufficiently tested by the laboratory as part of completing ATE_IND.1. Any functional packages this PP claims similarly contain their own Evaluation Activities that are used in this same manner.
CC Conformance Claims

This PP-Module is conformant to Part 2 (extended) and Part 3 (extended) of Common Criteria CC:2022, Revision 1.
PP Claim

This PP-Module does not claim conformance to any Protection Profile.

The following PPs and PP-Modules are allowed to be specified in a PP-Configuration with this PP-Module:
Package Claim

The functional packages to which the PP conforms may include SFRs that are not mandatory to claim for the sake of conformance. An ST that claims one or more of these functional packages may include any non-mandatory SFRs that are appropriate to claim based on the capabilities of the TSF and on any triggers for their inclusion based inherently on the SFR selections made.

3 Security Problem Definition

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.

3.1 Threats

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:
T.NETWORK_EAVESDROP
See MDF PP, Section 3.1 and GPOS PP, Section 3.1.
T.NETWORK_ATTACK
See MDF PP, Section 3.1 and GPOS PP, Section 3.1.

3.2 Assumptions

This document does not define any additional assumptions.

3.3 Organizational Security Policies

An organization deploying the TOE is expected to satisfy the organizational security policy listed below in addition to all organizational security policies defined by the claimed Base-PP.

This document does not define any additional OSPs.

4 Security Objectives

4.1 Security Objectives for the Operational Environment

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.

5 Security Requirements

This chapter describes the security requirements which have to be fulfilled by the product under evaluation. Those requirements comprise functional components from Part 2 and assurance components from Part 3 of [CC]. The following conventions are used for the completion of operations:

5.1 Protection Profile for Mobile Device Fundamentals Security Functional Requirements Direction

In a PP-Configuration that includes the MDF PP, the TOE is expected to rely on some of the security functions implemented by the Mobile Device as a whole and evaluated against the MDF PP. The following sections describe any modifications that the ST author must make to the SFRs defined in the MDF PP in addition to what is mandated by Section 5.3 TOE Security Functional Requirements.

5.1.1 Modified SFRs

The SFRs listed in this section are defined in the MDF PP and relevant to the secure operation of the TOE.

5.1.1.1 Security Management (FMT)

FMT_SMF_EXT.1: Specification of Management Functions

This PP-Module does not modify this SFR as it is defined in the MDF PP. 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.

5.1.2 Additional SFRs

This section defines additional SFRs that must be added to the TOE boundary in order to implement the functionality in any PP-Configuration where the MDF PP is claimed as the Base-PP.

5.1.2.1 Auditable Events for Additional SFRs when MDF is the Base-PP

Table 1: Auditable Events for MDF PP Additional SFRs
RequirementAuditable EventsAdditional Audit Record Contents
FMT_SMF_EXT.1/BT
No events specifiedN/A

5.1.2.2 Security Management (FMT)

FMT_SMF_EXT.1/BT Specification of Management Functions

The TSF shall be capable of performing the following Bluetooth management functions:
#Management FunctionImpl.User OnlyAdminAdmin Only
BT-1Configure the Bluetooth trusted channel.
  • Disable/enable the Discoverable (for BR/EDR) and Advertising (for LE) modes;
MMandatory
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
BT-2Change the Bluetooth device name (separately for BR/EDR and LE);
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
BT-3Provide separate controls for turning the BR/EDR and LE radios on and off;
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
BT-4Allow/disallow the following additional wireless technologies to be used with Bluetooth: [selection: Wi-Fi, NFC, [assignment: other wireless technologies]];
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
BT-5Configure allowable methods of Out of Band pairing (for BR/EDR and LE);
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
BT-6Disable/enable the Discoverable (for BR/EDR) and Advertising (for LE) modes separately;
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
BT-7Disable/enable the Connectable mode (for BR/EDR and LE);
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
BT-8Disable/enable the Bluetooth [assignment: list of Bluetooth service and/or profiles available on the OS (for BR/EDR and LE)];
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
BT-9Specify minimum level of security for each pairing (for BR/EDR and LE);
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
OOptional/Conditional
Application Note: As is the case with the [MDF PP], 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.


Function-specific Application Notes:

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.

Function BT-3 requires management of the Bluetooth device name separately for BR/EDR and LE radios.

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.

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.

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.

5.2 Protection Profile for General Purpose Operating System Security Functional Requirements Direction

In a PP-Configuration that includes the GPOS PP, the TOE is expected to rely on some of the security functions implemented by the Operating System as a whole and evaluated against the GPOS PP. The following sections describe any modifications that the ST author must make to the SFRs defined in the GPOS PP in addition to what is mandated by Section 5.3 TOE Security Functional Requirements.

5.2.1 Modified SFRs

The SFRs listed in this section are defined in the GPOS PP and relevant to the secure operation of the TOE.

5.2.1.1 Security Management (FMT)

FMT_MOF_EXT.1: Management of Functions Behavior

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.

FMT_SMF_EXT.1: Specification of Management Functions

This PP-Module does not modify this SFR as it is defined in the GPOS PP. 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.

5.2.2 Additional SFRs

This section defines additional SFRs that must be added to the TOE boundary in order to implement the functionality in any PP-Configuration where the GPOS PP is claimed as the Base-PP.

5.2.2.1 Auditable Events for Additional SFRs when GPOS is the Base-PP

Table 2: Auditable Events for GPOS PP Additional SFRs
RequirementAuditable EventsAdditional Audit Record Contents
FMT_MOF_EXT.1/BT
No events specifiedN/A
FMT_SMF_EXT.1/BT
No events specifiedN/A

5.2.2.2 Security Management (FMT)

FMT_MOF_EXT.1/BT Management of Security Functions Behavior

The OS shall restrict the ability to perform the function indicated in the "Administrator" column in FMT_SMF_EXT.1.1/BT to the administrator.
Application Note: 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.

FMT_SMF_EXT.1/BT Specification of Management Functions

The OS shall be capable of performing the following Bluetooth management functions:
Function Administrator User
BT-1. Configure the Bluetooth trusted channel.
  • Disable/enable the Discoverable (for BR/EDR) and Advertising (for LE) modes;
 X O
BT-2. Change the Bluetooth device name (separately for BR/EDR and LE); O O
BT-3. Provide separate controls for turning the BR/EDR and LE radios on and off; O O
BT-4. Allow/disallow the following additional wireless technologies to be used with Bluetooth: [selection: Wi-Fi, NFC, [assignment: other wireless technologies]]; O O
BT-5. Configure allowable methods of Out of Band pairing (for BR/EDR and LE); O O
BT-6. Disable/enable the Discoverable (for BR/EDR) and Advertising (for LE) modes separately; O O
BT-7. Disable/enable the Connectable mode (for BR/EDR and LE); O O
BT-8. Disable/enable the Bluetooth [assignment: list of Bluetooth service and/or profiles available on the OS (for BR/EDR and LE)]; O O
BT-9. Specify minimum level of security for each pairing (for BR/EDR and LE); O O
Application Note:

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.

5.3 TOE Security Functional Requirements

The following section describes the SFRs that must be satisfied by any TOE that claims conformance to this PP-Module. These SFRs must be claimed regardless of which PP-Configuration is used to define the TOE.

5.3.1 Auditable Events for Mandatory SFRs

Table 3: Auditable Events for Mandatory Requirements
RequirementAuditable EventsAdditional Audit Record Contents
FAU_GEN.1/BT
No events specifiedN/A
FCS_CKM_EXT.8
No events specifiedN/A
FIA_BLT_EXT.1
Failed user authorization of Bluetooth device.User authorization decision (e.g., user rejected connection, incorrect pin entry).
Failed user authorization for local Bluetooth Service.
  • [selection: complete, last [assignment: integer greater than or equal to 2] octets of the] BD_ADDR and [selection: name of device, uniquely generated nonce for each pairing, no other information].
  • Bluetooth profile. Identity of local service with [selection: service ID, profile name]
FIA_BLT_EXT.2
Initiation of Bluetooth connection.[selection: complete, last [assignment: integer greater than or equal to 2] octets of the] BD_ADDR and [selection: name of device, uniquely generated nonce for each pairing, no other information].
Failure of Bluetooth connection.Reason for failure.
FIA_BLT_EXT.3
Duplicate connection attempt.[selection: complete, last [assignment: integer greater than or equal to 2] octets of the] BD_ADDR of connection attempt.
FIA_BLT_EXT.4
No events specifiedN/A
FIA_BLT_EXT.6
No events specifiedN/A
FIA_BLT_EXT.7
No events specifiedN/A
FTP_BLT_EXT.1
No events specifiedN/A
FTP_BLT_EXT.2
No events specifiedN/A
FTP_BLT_EXT.3/BR
No events specifiedN/A

5.3.2 Security Audit (FAU)

FAU_GEN.1/BT Audit Data Generation (Bluetooth)

The TSF shall be able to generate audit data of the following auditable events:

  1. Start-up and shutdown of the audit functions
  2. All auditable events for the [not specified] level of audit
  3. [all auditable events for mandatory SFRs specified in Table 3].
The TSF shall record within the audit data at least the following information:
  1. Date and time of the event
  2. Type of event
  3. Subject identity
  4. The outcome (success or failure) of the event
  5. For each audit event type, based on the auditable event definitions of the functional components included in the PP, PP-Module, functional package or ST, [all auditable events for mandatory SFRs specified in Table 3].
Application Note: 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.

5.3.3 Cryptographic Support (FCS)

FCS_CKM_EXT.8 Bluetooth Key Generation

The TSF shall generate public/private ECDH key pairs every [assignment: frequency of and/or criteria for new key pair generation].
Application Note:

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.

5.3.4 Identification and Authentication (FIA)

FIA_BLT_EXT.1 Bluetooth User Authorization

The TSF shall require explicit user authorization before pairing with a remote Bluetooth device.
Application Note:

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.

Because 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.

FIA_BLT_EXT.2 Bluetooth Mutual Authentication

The TSF shall require Bluetooth mutual authentication between devices prior to any data transfer over the Bluetooth link.
Application Note: 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.

FIA_BLT_EXT.3 Rejection of Duplicate Bluetooth Connections

The TSF shall discard pairing and session initialization attempts from a Bluetooth device address (BD_ADDR) to which an active session already exists.
Application Note: 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.

FIA_BLT_EXT.4 Secure Simple Pairing

The TOE shall support Bluetooth Secure Simple Pairing, both in the host and the controller.
The TOE shall support Secure Simple Pairing during the pairing process.
Application Note: 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).

FIA_BLT_EXT.6 Trusted Bluetooth Device User Authorization

The TSF shall require explicit user authorization before granting trusted remote devices access to services associated with the following Bluetooth profiles: [assignment: list of Bluetooth profiles].
Application Note:

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.

FIA_BLT_EXT.7 Untrusted Bluetooth Device User Authorization

The TSF shall require explicit user authorization before granting untrusted remote devices access to services associated with the following Bluetooth profiles: [assignment: list of Bluetooth profiles].
Application Note: 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.

5.3.5 Trusted Path/Channels (FTP)

FTP_BLT_EXT.1 Bluetooth Encryption

The TSF shall enforce the use of encryption when transmitting data over the Bluetooth trusted channel for BR/EDR and [selection: LE, no other connections].
Application Note: 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 TSF shall use key pairs per FCS_CKM_EXT.8 for Bluetooth encryption.

FTP_BLT_EXT.2 Persistence of Bluetooth Encryption

The TSF shall [selection: restart encryption, terminate the connection] if the remote device stops encryption while connected to the TOE.
Application Note: 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.

FTP_BLT_EXT.3/BR Bluetooth Encryption Parameters (BR/EDR)

The TSF shall set the minimum encryption key size to [assignment: key size larger than or equal to 128 bits] for [BR/EDR] and not negotiate encryption key sizes smaller than the minimum size.
Application Note: 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.

5.4 TOE Security Functional Requirements Rationale

The following rationale provides justification for each SFR for the TOE, showing that the SFRs are suitable to address the specified threats:

Table 4: SFR Rationale
ThreatAddressed byRationale
T.NETWORK_​EAVESDROP
FMT_SMF_EXT.1 (modified from MDF PP)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 MDF PP)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 GPOS PP)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 GPOS PP)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 GPOS PP)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 GPOS PP)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.
T.NETWORK_​ATTACK
FMT_SMF_EXT.1 (modified from MDF PP)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 MDF PP)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 GPOS PP)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 GPOS PP)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 GPOS PP)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 GPOS PP)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.

6 Consistency Rationale

6.1 Protection Profile for Mobile Device Fundamentals

6.1.1 Consistency of TOE Type

If this PP-Module is used to extend the MDF PP, 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.

6.1.2 Consistency of Security Problem Definition

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 MDF PP.
Table 5: Consistency of Security Problem Definition (MDF PP base)
PP-Module Threat, Assumption, OSPConsistency Rationale
T.NETWORK_EAVESDROPThis threat comes directly from both base PPs.
T.NETWORK_ATTACKThis threat comes directly from both base PPs.

6.1.3 Consistency of OE Objectives

6.1.4 Consistency of Requirements

This PP-Module identifies several SFRs from the MDF PP that are needed to support Bluetooth functionality. This is considered to be consistent because the functionality provided by the MDF PP is being used for its intended purpose. The PP-Module identifies new SFRs that are used entirely to provide functionality for Bluetooth. The rationale for why this does not conflict with the claims defined by the MDF PP are as follows:
Table 6: Consistency of Requirements (MDF PP base)
PP-Module RequirementConsistency Rationale
Modified SFRs
FMT_SMF_EXT.1This 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.
Additional SFRs
FMT_SMF_EXT.1/BTThe 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.
Mandatory SFRs
FAU_GEN.1/BTThis SFR extends the audit functionality already present in the Base-PP to address auditing of behavior that is specific to this PP-Module.
FCS_CKM_EXT.8This 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.
FIA_BLT_EXT.1This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the Base-PP.
FIA_BLT_EXT.2This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the Base-PP.
FIA_BLT_EXT.3This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the Base-PP.
FIA_BLT_EXT.4This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the Base-PP.
FIA_BLT_EXT.6This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the Base-PP.
FIA_BLT_EXT.7This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the Base-PP.
FTP_BLT_EXT.1This 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.
FTP_BLT_EXT.2This 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.
FTP_BLT_EXT.3/BRThis 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.
Optional SFRs
This PP-Module does not define any Optional requirements.
Objective SFRs
FIA_BLT_EXT.5This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the Base-PP.
Implementation-dependent SFRs
This PP-Module does not define any Implementation-dependent requirements.
Selection-based SFRs
FTP_BLT_EXT.3/LEThis 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.

6.2 Protection Profile for General Purpose Operating System

6.2.1 Consistency of TOE Type

If this PP-Module is used to extend the [GPOS PP], 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.

6.2.2 Consistency of Security Problem Definition

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 GPOS PP.
Table 7: Consistency of Security Problem Definition (GPOS PP base)
PP-Module Threat, Assumption, OSPConsistency Rationale
T.NETWORK_EAVESDROPThis threat comes directly from both base PPs.
T.NETWORK_ATTACKThis threat comes directly from both base PPs.

6.2.3 Consistency of OE Objectives

6.2.4 Consistency of Requirements

This PP-Module identifies several SFRs from the GPOS PP that are needed to support Bluetooth functionality. This is considered to be consistent because the functionality provided by the GPOS PP is being used for its intended purpose. The PP-Module identifies new SFRs that are used entirely to provide functionality for Bluetooth. The rationale for why this does not conflict with the claims defined by the GPOS PP are as follows:
Table 8: Consistency of Requirements (GPOS PP base)
PP-Module RequirementConsistency Rationale
Modified SFRs
FMT_MOF_EXT.1This 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.
FMT_SMF_EXT.1This 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.
Additional SFRs
FMT_MOF_EXT.1/BTThe 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.
FMT_SMF_EXT.1/BTThe 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.
Mandatory SFRs
FAU_GEN.1/BTThis SFR extends the audit functionality already present in the Base-PP to address auditing of behavior that is specific to this PP-Module.
FCS_CKM_EXT.8This 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.
FIA_BLT_EXT.1This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the Base-PP.
FIA_BLT_EXT.2This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the Base-PP.
FIA_BLT_EXT.3This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the Base-PP.
FIA_BLT_EXT.4This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the Base-PP.
FIA_BLT_EXT.6This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the Base-PP.
FIA_BLT_EXT.7This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the Base-PP.
FTP_BLT_EXT.1This 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.
FTP_BLT_EXT.2This 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.
FTP_BLT_EXT.3/BRThis 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.
Optional SFRs
This PP-Module does not define any Optional requirements.
Objective SFRs
FIA_BLT_EXT.5This SFR applies to the establishment of Bluetooth connectivity, which is behavior not described in or prevented by the Base-PP.
Implementation-dependent SFRs
This PP-Module does not define any Implementation-dependent requirements.
Selection-based SFRs
FTP_BLT_EXT.3/LEThis 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.

Appendix A - Optional SFRs

A.1 Strictly Optional Requirements

This PP-Module does not define any Strictly Optional SFRs or SARs.

A.2 Objective Requirements

A.2.1 Auditable Events for Objective SFRs

Table 9: Auditable Events for Objective Requirements
RequirementAuditable EventsAdditional Audit Record Contents
FIA_BLT_EXT.5
No events specifiedN/A

A.2.2 Identification and Authentication

FIA_BLT_EXT.5 Bluetooth Secure Connections

The TOE shall support Secure Connections Only mode for Bluetooth BR/EDR and [selection: Bluetooth LE, no other Bluetooth protocol].
Application Note: 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."

A.3 Implementation-dependent Requirements

This PP-Module does not define any Implementation-dependent SFRs.

Appendix B - Selection-based Requirements

B.1 Auditable Events for Selection-based SFRs

Table 10: Auditable Events for Selection-based Requirements
RequirementAuditable EventsAdditional Audit Record Contents
FTP_BLT_EXT.3/LE
No events specifiedN/A

B.2 Trusted Path/Channels

FTP_BLT_EXT.3/LE Bluetooth Encryption Parameters (LE)

The inclusion of this selection-based component depends upon selection in FTP_BLT_EXT.1.1.
The TSF shall set the minimum encryption key size to [assignment: key size larger than or equal to 128 bits] for [LE] and not negotiate encryption key sizes smaller than the minimum size.
Application Note: 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.

Appendix C - Extended Component Definitions

This appendix contains the definitions for all extended requirements specified in the PP-Module.

C.1 Extended Components Table

All extended components specified in the PP-Module are listed in this table:
Table 11: Extended Component Definitions
Functional ClassFunctional Components
Cryptographic Support (FCS)FCS_CKM_EXT Cryptographic Key Management
Identification and Authentication (FIA)FIA_BLT_EXT Bluetooth Pairing
Trusted Path/Channels (FTP)FTP_BLT_EXT Bluetooth Trusted Communications

C.2 Extended Component Definitions

C.2.1 Cryptographic Support (FCS)

This PP-Module defines the following extended components as part of the FCS class originally defined by CC Part 2:

C.2.1.1 FCS_CKM_EXT Cryptographic Key Management

Family Behavior

Components in this family define requirements for cryptographic key management beyond those which are specified in the Part 2 family FCS_CKM.

Component Leveling

FCS_CKM_EXT8

FCS_CKM_EXT.8, Bluetooth Key Generation, requires the TSF to generate key pairs used for Bluetooth over a specified time period or in response to some observed event.

Management: FCS_CKM_EXT.8

No specific management functions are identified.

Audit: FCS_CKM_EXT.8

There are no auditable events foreseen.

FCS_CKM_EXT.8 Bluetooth Key Generation

Hierarchical to:No other components.
Dependencies to:FCS_CKM.1 Cryptographic Key Generation
FPT_STM.1 Reliable Time Stamps
FTP_BLT_EXT.1 Bluetooth Encryption

FCS_CKM_EXT.8.1

The TSF shall generate public/private ECDH key pairs every [assignment: frequency of and/or criteria for new key pair generation].

C.2.2 Identification and Authentication (FIA)

This PP-Module defines the following extended components as part of the FIA class originally defined by CC Part 2:

C.2.2.1 FIA_BLT_EXT Bluetooth Pairing

Family Behavior

Components in this family define Bluetooth-specific identification and authentication requirements.

Component Leveling

FIA_BLT_EXT1234675

FIA_BLT_EXT.1, Bluetooth User Authorization, requires the TSF to have explicit user authorization before allowing a Bluetooth pairing.

FIA_BLT_EXT.2, Bluetooth Mutual Authentication, requires the TSF to enforce mutual authentication for Bluetooth.

FIA_BLT_EXT.3, Rejection of Duplicate Bluetooth Connections, requires the TSF to reject duplicate attempts to connect to Bluetooth.

FIA_BLT_EXT.4, Secure Simple Pairing, requires the TSF to support Secure Simple Pairing.

FIA_BLT_EXT.6, Trusted Bluetooth Device User Authorization, requires the TSF to have explicit user authentication before associating trusted services with Bluetooth.

FIA_BLT_EXT.7, Untrusted Bluetooth Device User Authorization, requires the TSF to have explicit user authentication before associating untrusted services with Bluetooth.

FIA_BLT_EXT.5, Bluetooth Secure Connections, requires the TSF to support Secure Connections Only mode.

Management: FIA_BLT_EXT.1

No specific management functions are identified.

Audit: FIA_BLT_EXT.1

The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:

  • Failed user authorization of Bluetooth device.
  • Failed user authorization for local Bluetooth device.

FIA_BLT_EXT.1 Bluetooth User Authorization

Hierarchical to:No other components.
Dependencies to:No dependencies.

FIA_BLT_EXT.1.1

The TSF shall require explicit user authorization before pairing with a remote Bluetooth device.

Management: FIA_BLT_EXT.2

No specific management functions are identified.

Audit: FIA_BLT_EXT.2

The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:

  • Initiation of Bluetooth connection.
  • Failure of Bluetooth connection.

FIA_BLT_EXT.2 Bluetooth Mutual Authentication

Hierarchical to:No other components.
Dependencies to:FIA_BLT_EXT.1 Bluetooth User Authorization

FIA_BLT_EXT.2.1

The TSF shall require Bluetooth mutual authentication between devices prior to any data transfer over the Bluetooth link.

Management: FIA_BLT_EXT.3

No specific management functions are identified.

Audit: FIA_BLT_EXT.3

The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:

  • Duplicate connection attempt.

FIA_BLT_EXT.3 Rejection of Duplicate Bluetooth Connections

Hierarchical to:No other components.
Dependencies to:FIA_BLT_EXT.1 Bluetooth User Authorization

FIA_BLT_EXT.3.1

The TSF shall discard pairing and session initialization attempts from a Bluetooth device address (BD_ADDR) to which an active session already exists.

Management: FIA_BLT_EXT.4

No specific management functions are identified.

Audit: FIA_BLT_EXT.4

There are no auditable events foreseen.

FIA_BLT_EXT.4 Secure Simple Pairing

Hierarchical to:No other components.
Dependencies to:FIA_BLT_EXT.1 Bluetooth User Authorization

FIA_BLT_EXT.4.1

The TOE shall support Bluetooth Secure Simple Pairing, both in the host and the controller.

FIA_BLT_EXT.4.2

The TOE shall support Secure Simple Pairing during the pairing process.

Management: FIA_BLT_EXT.6

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.

Audit: FIA_BLT_EXT.6

There are no auditable events foreseen.

FIA_BLT_EXT.6 Trusted Bluetooth Device User Authorization

Hierarchical to:No other components.
Dependencies to:FIA_BLT_EXT.1 Bluetooth User Authorization

FIA_BLT_EXT.6.1

The TSF shall require explicit user authorization before granting trusted remote devices access to services associated with the following Bluetooth profiles: [assignment: list of Bluetooth profiles].

Management: FIA_BLT_EXT.7

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.

Audit: FIA_BLT_EXT.7

There are no auditable events foreseen.

FIA_BLT_EXT.7 Untrusted Bluetooth Device User Authorization

Hierarchical to:No other components.
Dependencies to:FIA_BLT_EXT.1 Bluetooth User Authorization

FIA_BLT_EXT.7.1

The TSF shall require explicit user authorization before granting untrusted remote devices access to services associated with the following Bluetooth profiles: [assignment: list of Bluetooth profiles].

Management: FIA_BLT_EXT.5

No specific management functions are identified.

Audit: FIA_BLT_EXT.5

There are no auditable events foreseen.

FIA_BLT_EXT.5 Bluetooth Secure Connections

Hierarchical to:No other components.
Dependencies to:FIA_BLT_EXT.1 Bluetooth User Authorization

FIA_BLT_EXT.5.1

The TOE shall support Secure Connections Only mode for Bluetooth BR/EDR and [selection: Bluetooth LE, no other Bluetooth protocol].

C.2.3 Trusted Path/Channels (FTP)

This PP-Module defines the following extended components as part of the FTP class originally defined by CC Part 2:

C.2.3.1 FTP_BLT_EXT Bluetooth Trusted Communications

Family Behavior

Components in this family define requirements for Bluetooth encryption.

Component Leveling

FTP_BLT_EXT123

FTP_BLT_EXT.1, Bluetooth Encryption, requires the TSF to enforce encryption when transmitting over Bluetooth.

FTP_BLT_EXT.2, Persistence of Bluetooth Encryption, requires the TSF to ensure encryption for the duration of the use of the Bluetooth channel.

FTP_BLT_EXT.3, Bluetooth Encryption Parameters, specifies the key sizes used for Bluetooth.

Management: FTP_BLT_EXT.1

No specific management functions are identified.

Audit: FTP_BLT_EXT.1

There are no auditable events foreseen.

FTP_BLT_EXT.1 Bluetooth Encryption

Hierarchical to:No other components.
Dependencies to:FCS_CKM_EXT.8 Bluetooth Key Generation
FIA_BLT_EXT.1 Bluetooth User Authorization

FTP_BLT_EXT.1.1

The TSF shall enforce the use of encryption when transmitting data over the Bluetooth trusted channel for BR/EDR and [assignment: list of other connection modes].

FTP_BLT_EXT.1.2

The TSF shall use key pairs per FCS_CKM_EXT.8 for Bluetooth encryption.

Management: FTP_BLT_EXT.2

No specific management functions are identified.

Audit: FTP_BLT_EXT.2

There are no auditable events foreseen.

FTP_BLT_EXT.2 Persistence of Bluetooth Encryption

Hierarchical to:No other components.
Dependencies to:FTP_BLT_EXT.1 Bluetooth Encryption

FTP_BLT_EXT.2.1

The TSF shall [selection: restart encryption, terminate the connection] if the remote device stops encryption while connected to the TOE.

Management: FTP_BLT_EXT.3

The following actions could be considered for the management functions in FMT:

  • Specification of minimum encryption key size.

Audit: FTP_BLT_EXT.3

There are no auditable events foreseen.

FTP_BLT_EXT.3 Bluetooth Encryption Parameters

Hierarchical to:No other components.
Dependencies to:FTP_BLT_EXT.1 Bluetooth Encryption

FTP_BLT_EXT.3.1

The TSF shall set the minimum encryption key size to [assignment: key size larger than or equal to 128 bits] for [assignment: Bluetooth protocol] and not negotiate encryption key sizes smaller than the minimum size.

Appendix D - Implicitly Satisfied Requirements

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 [MDF], this dependency is satisfied explicitly through the Base-PP's definition of FPT_STM.1. When the TOE claims conformance to [GPOS], 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.

Appendix E - Entropy Documentation and Assessment

The TOE does not require any additional supplementary information to describe its entropy sources beyond the requirements outlined in the Base-PPs.

Appendix F - Acronyms

Table 12: Acronyms
AcronymMeaning
ACLAsynchronous Connection-Less
AESAdvanced Encryption Standard
AES-CCMAES Counter with CBC-MAC Mode
AFHAdaptive Frequency Hopping
APIApplication Programming Interface
Base-PPBase Protection Profile
BRBasic Rate
CCCommon Criteria
CEMCommon Evaluation Methodology
cPPCollaborative Protection Profile
ECDHElliptic Curve Diffie-Hellman
EDREnhanced Data Rate
EPExtended Package
FPFunctional Package
FTPFile Transfer Protocol
HCIHost Controller Interface
L2CAPLogical Link Control and Adaptation Protocol
LELow Energy
LMPLink Manager Protocol
MDFMobile Device Fundamentals
OBEXObject Exchange
OEOperational Environment
PPProtection Profile
PP-ConfigurationProtection Profile Configuration
PP-ModuleProtection Profile Module
SARSecurity Assurance Requirement
SFRSecurity Functional Requirement
STSecurity Target
TOETarget of Evaluation
TSFTOE Security Functionality
TSFITSF Interface
TSSTOE Summary Specification

Appendix G - Bibliography

Table 13: Bibliography
IdentifierTitle
[Bluetooth] Bluetooth Core Specifications, version 5.2; December 2019,
[CC]Common Criteria for Information Technology Security Evaluation -
[CEM]Common Methodology for Information Technology Security Evaluation -
[GPOS]Protection Profile for General Purpose Operating Systems, Version 5.0, September 27, 2022 Adjust date when finalized
[MDF]Protection Profile for Mobile Device Fundamentals, Version 4.0, September 12, 2022 Adjust date when finalized