Version | Date | Comment |
---|---|---|
1.0 | 2021-04-15 | Initial Release |
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. |
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. |
Link | Shorthand for a logical link. |
Link establishment | A procedure for establishing the default ACL link and hierarchy of links and channels between devices. |
Link key | A secret that is known by two devices and is used to authenticate the link. |
Logical Link Control and Adaptation Protocol (L2CAP) | A data link protocol used in the Bluetooth protocol stack. |
Logical link | 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. |
This PP-Module inherits exact conformance as required from the specified Base-PP and as defined in the CC and CEM addenda for Exact Conformance, Selection-based SFRs, and Optional SFRs (dated May 2017).
The following PPs and PP-Modules are allowed to be specified in a PP-Configuration with this PP-Module.
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.Threat, Assumption, or OSP | Security Objectives | Rationale |
T.NETWORK_EAVESDROP | O.PROTECTED_COMMS | The threat T.NETWORK_EAVESDROP is countered by O.PROTECTED_COMMS as this provides the capability to communicate using Bluetooth as a means to maintain the confidentiality of data that are transmitted outside of the TOE. |
T.NETWORK_ATTACK | O.PROTECTED_COMMS | The threat T.NETWORK_ATTACK is countered by O.PROTECTED_COMMS as this provides the capability to communicate using Bluetooth as a means to maintain the confidentiality of data that are transmitted outside of the TOE. |
# | Management Function | Impl. | User Only | Admin | Admin Only |
BT-1 | Configure the Bluetooth trusted channel. | MMandatory | OOptional | OOptional | OOptional |
BT-2 | Change the Bluetooth device name (separately for BR/EDR and LE); | OOptional | OOptional | OOptional | OOptional |
BT-3 | Provide separate controls for turning the BR/EDR and LE radios on and off; | OOptional | OOptional | OOptional | OOptional |
BT-4 | Allow/disallow the following additional wireless technologies to be used with Bluetooth: [selection: Wi-Fi, NFC, [assignment: other wireless technologies] ]; | OOptional | OOptional | OOptional | OOptional |
BT-5 | Configure allowable methods of Out of Band pairing (for BR/EDR and LE); | OOptional | OOptional | OOptional | OOptional |
BT-6 | Disable/enable the Discoverable (for BR/EDR) and Advertising (for LE) modes separately; | OOptional | OOptional | OOptional | OOptional |
BT-7 | Disable/enable the Connectable mode (for BR/EDR and LE); | OOptional | OOptional | OOptional | OOptional |
BT-8 | Disable/enable the Bluetooth [assignment: list of Bluetooth service and/or profiles available on the OS (for BR/EDR and LE)]; | OOptional | OOptional | OOptional | OOptional |
BT-9 | Specify minimum level of security for each pairing (for BR/EDR and LE); | OOptional | OOptional | OOptional | OOptional |
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.
Function | Administrator | User |
---|---|---|
BT-1. Configure the Bluetooth trusted channel. | 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 |
Requirement | Auditable Events | Additional Audit Record Contents |
---|---|---|
FCS_CKM_EXT.8 | None. | |
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. | Bluetooth address and name of device. Bluetooth profile. Identity of local service with [selection: service ID, profile name ]. | |
FIA_BLT_EXT.2 | Initiation of Bluetooth connection. | Bluetooth address and name of device. |
Failure of Bluetooth connection. | Reason for failure. | |
FIA_BLT_EXT.3 (optional) | Duplicate connection attempt. | BD_ADDR of connection attempt. |
FIA_BLT_EXT.4 | None. | |
FIA_BLT_EXT.5 (if claimed) | None. | |
FIA_BLT_EXT.6 | None. | |
FIA_BLT_EXT.7 | None. | |
FTP_BLT_EXT.1 | None. | |
FTP_BLT_EXT.2 | None. | |
FTP_BLT_EXT.3/BR | None. | |
FTP_BLT_EXT.3/LE (if claimed) | None. |
The following rationale provides justification for each security objective for the TOE,
showing that the SFRs are suitable to meet and achieve the security objectives:
Objective | Addressed by | Rationale |
---|---|---|
O.PROTECTED_COMMS | FIA_BLT_EXT.1 | FIA_BLT_EXT.1 supports the objective by ensuring that Bluetooth communications are not initiated without user approval. |
FIA_BLT_EXT.2 | FIA_BLT_EXT.2 supports the objective by requiring the TSF to implement Bluetooth mutual authentication. | |
FIA_BLT_EXT.3 | FIA_BLT_EXT.3 supports the objective by preventing Bluetooth spoofing by rejecting connections with duplicate device addresses. | |
FIA_BLT_EXT.4 | FIA_BLT_EXT.4 supports the objective by defining the TSF's implementation of Bluetooth Secure Simple Pairing. | |
FIA_BLT_EXT.5 | FIA_BLT_EXT.5 supports the objective by requiring the TSF to support Secure Connections Only mode for the supported Bluetooth communication channels. | |
FIA_BLT_EXT.6 | FIA_BLT_EXT.6 supports the objective by requiring the TSF to specify the Bluetooth profiles that it requires explicit user authorization to grant access to for trusted devices. | |
FTP_BLT_EXT.1 | FTP_BLT_EXT.1 supports the objective by requiring the TSF to implement encryption to protect Bluetooth communications | |
FTP_BLT_EXT.2 | FTP_BLT_EXT.2 supports the objective by requiring the TSF to prevent data transmission over Bluetooth if the paired device is not using encryption. |
PP-Module Threat, Assumption, OSP | Consistency Rationale |
---|---|
T.NETWORK_EAVESDROP | This threat comes directly from both base PPs. |
T.NETWORK_ATTACK | This threat comes directly from both base PPs. |
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 MDF PP. The objectives for the TOEs are consistent with the Bluetooths PP based on the following rationale:
PP-Module TOE Objective | Consistency Rationale |
---|---|
O.PROTECTED_COMMS | This objective comes directly from the PP. |
PP-Module Requirement | Consistency Rationale |
---|---|
Modified SFRs | |
FMT_SMF_EXT.1 | 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. |
Additional SFRs | |
FMT_SMF_EXT.1/BT | 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. |
Mandatory SFRs | |
FAU_GEN.1/BT | The PP-Module defines auditable events for Bluetooth that extends the audit functionality defined in each Base-PP. |
FCS_CKM_EXT.8 | |
FIA_BLT_EXT.1 | |
FIA_BLT_EXT.2 | |
FIA_BLT_EXT.3 | |
FIA_BLT_EXT.4 | |
FIA_BLT_EXT.6 | |
FIA_BLT_EXT.7 | |
FTP_BLT_EXT.1 | |
FTP_BLT_EXT.2 | |
FTP_BLT_EXT.3/BR | |
Optional SFRs | |
This PP-Module does not define any Optional requirements. | |
Objective SFRs | |
FIA_BLT_EXT.5 | |
Implementation-based SFRs | |
This PP-Module does not define any Implementation-based requirements. | |
Selection-based SFRs | |
FTP_BLT_EXT.3/LE |
PP-Module Threat, Assumption, OSP | Consistency Rationale |
---|---|
T.NETWORK_EAVESDROP | This threat comes directly from both base PPs. |
T.NETWORK_ATTACK | This threat comes directly from both base PPs. |
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 GPOS PP. The objectives for the TOEs are consistent with the Bluetooths PP based on the following rationale:
PP-Module TOE Objective | Consistency Rationale |
---|---|
O.PROTECTED_COMMS | This objective comes directly from the PP. |
PP-Module Requirement | Consistency Rationale |
---|---|
Modified SFRs | |
FMT_MOF_EXT.1 | 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. |
FMT_SMF_EXT.1 | 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. |
Additional SFRs | |
FMT_MOF_EXT.1/BT | 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. |
FMT_SMF_EXT.1/BT | 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. |
Mandatory SFRs | |
FAU_GEN.1/BT | The PP-Module defines auditable events for Bluetooth that extends the audit functionality defined in each Base-PP. |
FCS_CKM_EXT.8 | |
FIA_BLT_EXT.1 | |
FIA_BLT_EXT.2 | |
FIA_BLT_EXT.3 | |
FIA_BLT_EXT.4 | |
FIA_BLT_EXT.6 | |
FIA_BLT_EXT.7 | |
FTP_BLT_EXT.1 | |
FTP_BLT_EXT.2 | |
FTP_BLT_EXT.3/BR | |
Optional SFRs | |
This PP-Module does not define any Optional requirements. | |
Objective SFRs | |
FIA_BLT_EXT.5 | |
Implementation-based SFRs | |
This PP-Module does not define any Implementation-based requirements. | |
Selection-based SFRs | |
FTP_BLT_EXT.3/LE |
This PP-Module does not define any Strictly Optional SFRs.
This PP-Module does not define any Implementation-based SFRs.
Functional Class | Functional 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 |
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.
No specific management functions are identified.
There are no auditable events foreseen.
Hierarchical to: No other components.
Dependencies to: FCS_CKM.1 Cryptographic Key Generation
FPT_STM.1 Reliable Time StampsFTP_BLT_EXT.1 Bluetooth EncryptionFIA_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.
No specific management functions are identified.
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Hierarchical to: No other components.
Dependencies to: No dependencies.
No specific management functions are identified.
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Hierarchical to: No other components.
Dependencies to: FIA_BLT_EXT.1 Bluetooth User Authorization
No specific management functions are identified.
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Hierarchical to: No other components.
Dependencies to: FIA_BLT_EXT.1 Bluetooth User Authorization
No specific management functions are identified.
There are no auditable events foreseen.
Hierarchical to: No other components.
Dependencies to: FIA_BLT_EXT.1 Bluetooth User Authorization
The following actions could be considered for the management functions in FMT:
There are no auditable events foreseen.
Hierarchical to: No other components.
Dependencies to: FIA_BLT_EXT.1 Bluetooth User Authorization
The following actions could be considered for the management functions in FMT:
There are no auditable events foreseen.
Hierarchical to: No other components.
Dependencies to: FIA_BLT_EXT.1 Bluetooth User Authorization
No specific management functions are identified.
There are no auditable events foreseen.
Hierarchical to: No other components.
Dependencies to: FIA_BLT_EXT.1 Bluetooth User Authorization
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.
No specific management functions are identified.
There are no auditable events foreseen.
Hierarchical to: No other components.
Dependencies to: FCS_CKM_EXT.8 Bluetooth Key Generation
FIA_BLT_EXT.1 Bluetooth User AuthorizationNo specific management functions are identified.
There are no auditable events foreseen.
Hierarchical to: No other components.
Dependencies to: FTP_BLT_EXT.1 Bluetooth Encryption
The following actions could be considered for the management functions in FMT:
There are no auditable events foreseen.
Hierarchical to: No other components.
Dependencies to: FTP_BLT_EXT.1 Bluetooth Encryption
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. |
Acronym | Meaning |
---|---|
ACL | Asynchronous Connection-Less |
AES | Advanced Encryption Standard |
AES-CCM | AES Counter with CBC-MAC Mode |
AFH | Adaptive Frequency Hopping |
API | Application Programming Interface |
Base-PP | Base Protection Profile |
BR | Basic Rate |
CC | Common Criteria |
CEM | Common Evaluation Methodology |
cPP | Collaborative Protection Profile |
ECDH | Elliptic Curve Diffie-Hellman |
EDR | Enhanced Data Rate |
EP | Extended Package |
FP | Functional Package |
FTP | File Transfer Protocol |
HCI | Host Controller Interface |
L2CAP | Logical Link Control and Adaptation Protocol |
LE | Low Energy |
LMP | Link Manager Protocol |
MDF | Mobile Device Fundamentals |
OBEX | Object Exchange |
OE | Operational Environment |
PP | Protection Profile |
PP-Configuration | Protection Profile Configuration |
PP-Module | Protection Profile Module |
SAR | Security Assurance Requirement |
SFR | Security Functional Requirement |
ST | Security Target |
TOE | Target of Evaluation |
TSF | TOE Security Functionality |
TSFI | TSF Interface |
TSS | TOE Summary Specification |
Identifier | Title |
---|---|
[Bluetooth] | Bluetooth Core Specifications, version 5.2; December 2019, |
[CC] | Common Criteria for Information Technology Security Evaluation -
|
[CEM] | Common Evaluation Methodology for Information Technology Security - Evaluation Methodology, CCMB-2017-04-004, Version 3.1, Revision 5, April 2017. |
[GPOS] | Protection Profile for General Purpose Operating Systems, Version 4.2.1, April 22, 2019 |
[MDF] | Protection Profile for Mobile Device Fundamentals, Version 3.2, April 15, 2021 |