NIAP: View Technical Decision Details
NIAP/CCEVS
  NIAP  »»  Protection Profiles  »»  Technical Decisions  »»  View Details  
TD0712:  Support for Bluetooth Standard 5.3

Publication Date
2023.04.04

Protection Profiles
PP_OS_V4.3

Other References
FCS_CKM.1, FCS_COP.1/Encrypt, Appendix F

Issue Description

Bluetooth Core 5.3 standard only supports the use of AES-128-CCM and curves P-192 and P-256. The PP-Module for Bluetooth v1.0 cannot currently be used with PP OS V4.3 because of lack of support for those selections. Additionally, AES-GCM was incorrectly removed in OS v4.3.

Resolution

PP_OS_V4.3 is updated as follows, with yellow highlight indicating additions and red highlight indicating deletions:

 

FCS_CKM.1 is updated as follows:

 

FCS_CKM.1 Cryptographic Key Generation (Refined)

FCS_CKM.1.1

The OS shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm [selection:

·       RSA schemes using cryptographic key sizes of 3072-bit or greater that meet the following: FIPS PUB 186-4, "Digital Signature Standard (DSS)", Appendix B.3

·       ECC schemes using "NIST curves" P-384 and [selectionP-256, P-521, no other curves ] that meet the following: FIPS PUB 186-4, "Digital Signature Standard (DSS)", Appendix B.4

·       FFC schemes using [selection: cryptographic key sizes of 3072-bit or greater that meet the following: FIPS PUB 186-4, "Digital Signature Standard (DSS)", Appendix B.1, safe primes that meet the following: NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes" ]

].

Application Note: 

The ST author will select all key generation schemes used for key establishment and entity authentication. When key generation is used for key establishment, the schemes in FCS_CKM.2 and selected cryptographic protocols must match the selection. When key generation is used for entity authentication, the public key is expected to be associated with an X.509v3 certificate.

If the OS acts only as a receiver in the RSA key establishment scheme, the OS does not need to implement RSA key generation.

“P-256” may only be selected if the PP-Module for Bluetooth V1.0 is included in the ST and may only be used specifically for Bluetooth functions.

Validation Guidelines:

Rule #1

Rule #2

Rule #3

Rule #11

 

Evaluation Activities

FCS_CKM.1

TestsTSS

The evaluator will ensure that the TSS identifies the key sizes supported by the OS. If the ST specifies more than one scheme, the evaluator will examine the TSS to verify that it identifies the usage for each scheme. If “P-256” is selected, the evaluator will examine the TSS to verify that it is only used for Bluetooth functions.

Guidance

The evaluator will verify that the AGD guidance instructs the administrator how to configure the OS to use the selected key generation scheme(s) and key size(s) for all uses defined in this PP.

Tests

Evaluation Activity Note: The following tests may require the vendor to furnish a developer environment and developer tools that are typically not available to end-users of the OS.

The following content should be included if:

Key Generation for FIPS PUB 186-4 RSA Schemes

The evaluator will verify the implementation of RSA Key Generation by the OS using the Key Generation test. This test verifies the ability of the TSF to correctly produce values for the key components including the public verification exponent e, the private prime factors p and q, the public modulus n and the calculation of the private signature exponent d. Key Pair generation specifies 5 ways (or methods) to generate the primes p and q. These include:

1.    Random Primes:

o   Provable primes

o   Probable primes

2.    Primes with Conditions:

o   Primes p1, p2, q1,q2, p and q shall all be provable primes

o   Primes p1, p2, q1, and q2 shall be provable primes and p and q shall be probable primes

o   Primes p1, p2, q1,q2, p and q shall all be probable primes

To test the key generation method for the Random Provable primes method and for all the Primes with Conditions methods, the evaluator must seed the TSF key generation routine with sufficient data to deterministically generate the RSA key pair. This includes the random seed(s), the public exponent of the RSA key, and the desired key length. For each key length supported, the evaluator shall have the TSF generate 25 key pairs. The evaluator will verify the correctness of the TSF's implementation by comparing values generated by the TSF with those generated from a known good implementation.

If possible, the Random Probable primes method should also be verified against a known good implementation as described above. Otherwise, the evaluator will have the TSF generate 10 keys pairs for each supported key length nlen and verify:

·       n = pq,

·       p and q are probably prime according to Miller-Rabin tests,

·       GCD(p-1,e) = 1,

·       GCD(q-1,e) = 1,

·       216 ≤ e ≤ 2256 and e is an odd integer,

·       |p-q| > 2nlen/2 - 100,

·       p ≥ 2nlen/2 -1/2,

·       q ≥ 2nlen/2 -1/2,

·       2(nlen/2) < d < LCM(p-1,q-1),

·       ed = 1 mod LCM(p-1,q-1).

The following content should be included if:

Key Generation for Elliptic Curve Cryptography (ECC)

FIPS 186-4 ECC Key Generation Test

For each supported NIST curve, i.e., P-256, P-384 and P-521, the evaluator will require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated using an approved random bit generator (RBG). To determine correctness, the evaluator will submit the generated key pairs to the public key verification (PKV) function of a known good implementation.

FIPS 186-4 Public Key Verification (PKV) Test

For each supported NIST curve, i.e., P-256, P-384 and P-521, the evaluator will generate 10 private/public key pairs using the key generation function of a known good implementation and modify five of the public key values so that they are incorrect, leaving five values unchanged (i.e., correct). The evaluator will obtain in response a set of 10 PASS/FAIL values.

The following content should be included if:

Key Generation for Finite-Field Cryptography (FFC)

The evaluator will verify the implementation of the Parameters Generation and the Key Generation for FFC by the TOE using the Parameter Generation and Key Generation test. This test verifies the ability of the TSF to correctly produce values for the field prime p, the cryptographic prime q (dividing p-1), the cryptographic group generator g, and the calculation of the private key x and public key y.

The Parameter generation specifies 2 ways (or methods) to generate the cryptographic prime q and the field prime p:

·  Cryptographic and Field Primes:

·       Primes q and p shall both be provable primes

·       Primes q and field prime p shall both be probable primes

and two ways to generate the cryptographic group generator g:

·  Cryptographic Group Generator:

·       Generator g constructed through a verifiable process

·       Generator g constructed through an unverifiable process

The Key generation specifies 2 ways to generate the private key x:

·  Private Key:

·       len(q) bit output of RBG where 1 ≤ x ≤ q-1

·       len(q) + 64 bit output of RBG, followed by a mod q-1 operation where 1 ≤ x ≤ q-1

The security strength of the RBG must be at least that of the security offered by the FFC parameter set. To test the cryptographic and field prime generation method for the provable primes method and/or the group generator g for a verifiable process, the evaluator must seed the TSF parameter generation routine with sufficient data to deterministically generate the parameter set. For each key length supported, the evaluator will have the TSF generate 25 parameter sets and key pairs. The evaluator will verify the correctness of the TSF's implementation by comparing values generated by the TSF with those generated from a known good implementation. Verification must also confirm:

·       g != 0,1

·       q divides p-1

·       gq mod p = 1

·       gx mod p = y

for each FFC parameter set and key pair.

 

 

FCS_COP.1/Encrypt is updated as follows:

 

FCS_COP.1/ENCRYPT Cryptographic Operation - Encryption/Decryption (Refined)

FCS_COP.1.1/ENCRYPT

The OS shall perform [encryption/decryption services for data] in accordance with a specified cryptographic algorithm [selection:

·       AES-XTS (as defined in NIST SP 800-38E)

·       AES-CBC (as defined in NIST SP 800-38A)

·       AES-CTR (as defined in NIST SP 800-38A)

] and [selection:

·       AES Key Wrap (KW) (as defined in NIST SP 800-38F)

·       AES Key Wrap with Padding (KWP) (as defined in NIST SP 800-38F)

·       AES-CCMP-256 (as defined in NIST SP 800-38C and IEEE 802.11ac-2013)

·       AES-GCMP-256 (as defined in NIST SP 800-38D and IEEE 802.11ac-2013)

·       AES-CCM (as defined in NIST SP 800-38C)

·       AES-GCM (as defined in NIST SP 800-38D)

·       no other modes

] and cryptographic key sizes 256-bit and [selection: 128-bit, no other bit size] that meet the following: [assignment: list of standards].

Application Note: 

AES CCMP (which uses AES in CCM as specified in SP 800-38C) becomes mandatory and must be selected if the ST includes the PP-Module for Wireless LAN Clients, version 1.0.

AES-CCM becomes mandatory and must be selected if the ST includes the PP-Module for Bluetooth, version 1.0.

For the second selection, the ST author should choose the mode or modes in which AES operates.

For the third selection, the ST author should choose the key sizes that are supported by this functionality may only choose 128-bit if the ST includes the PP-Module for Bluetooth, version 1.0, and it may only be used specifically for with AES-CCM for Bluetooth functions.

Validation Guidelines:

Rule #4

Rule #11

 

 

The following is added to the evaluation activity section of FCS_COP.1/Encrypt:

 

TSS

 

If “128-bit” is selected, the evaluator will examine the TSS to verify that 128-bit is only used with AES-CCM for Bluetooth functions.

 

 

The Test activity for AES-CCMP in FCS_COP.1/Encrypt is updated as follows:

 

The following content should be included if:

AES-CCM Tests

The evaluator will test the generation-encryption and decryption-verification functionality of AES-CCM for the following input parameter and tag lengths:

·       128 bit (if selected) and 256 bit keys

·       Two payload lengths. One payload length will be the shortest supported payload length, greater than or equal to zero bytes. The other payload length will be the longest supported payload length, less than or equal to 32 bytes (256 bits).

·       Two or three associated data lengths. One associated data length will be 0, if supported. One associated data length will be the shortest supported payload length, greater than or equal to zero bytes. One associated data length will be the longest supported payload length, less than or equal to 32 bytes (256 bits). If the implementation supports an associated data length of 2 16 bytes, an associated data length of 216 bytes will be tested.

·       Nonce lengths. The evaluator will test all nonce lengths between 7 and 13 bytes, inclusive, that are supported by the OS.

·       Tag lengths. The evaluator will test all of the following tag length values that are supported by the OS: 4, 6, 8, 10, 12, 14 and 16 bytes.

To test the generation-encryption functionality of AES-CCM, the evaluator will perform the following four tests:

·       Test 13: For EACH supported key and associated data length and ANY supported payload, nonce and tag length, the evaluator will supply one key value, one nonce value and 10 pairs of associated data and payload values and obtain the resulting ciphertext.

·       Test 14: For EACH supported key and payload length and ANY supported associated data, nonce and tag length, the evaluator will supply one key value, one nonce value and 10 pairs of associated data and payload values and obtain the resulting ciphertext.

·       Test 15: For EACH supported key and nonce length and ANY supported associated data, payload and tag length, the evaluator will supply one key value and 10 associated data, payload and nonce value 3-tuples and obtain the resulting ciphertext.

·       Test 16: For EACH supported key and tag length and ANY supported associated data, payload and nonce length, the evaluator will supply one key value, one nonce value and 10 pairs of associated data and payload values and obtain the resulting ciphertext.

To determine correctness in each of the above tests, the evaluator will compare the ciphertext with the result of generation-encryption of the same inputs with a known good implementation.

To test the decryption-verification functionality of AES-CCM, for EACH combination of supported associated data length, payload length, nonce length and tag length, the evaluator will supply a key value and 15 nonce, associated data and ciphertext 3-tuples and obtain either a FAIL result or a PASS result with the decrypted payload. The evaluator will supply 10 tuples that should FAIL and 5 that should PASS per set of 15.

Additionally, the evaluator will use tests from the IEEE 802.11-02/362r6 document "Proposed Test vectors for IEEE 802.11 TGi", dated September 10, 2002, Section 2.1 AESCCMP Encapsulation Example and Section 2.2 Additional AES CCMP Test Vectors to further verify the IEEE 802.11-2007 implementation of AES-CCMP.

 

 

Appendix F is updated to include the following rule:

Rule #11

DECISION A

 

 

CHOICE A1

Exclude the PP-Module for Bluetooth, Version 1.0 module from the ST

 

CHOICE A2

Include the PP-Module for Bluetooth, Version 1.0 module in the ST

DECISION B

 

 

CHOICE B1

From FCS_CKM.1.1:

* do not select “P-256”

From FCS_COP.1.1/ENCRYPT:

* do not select “AES-CCM”

* select “256”

 

CHOICE B2

From FCS_CKM.1.1:

* select at least “P-256”

From FCS_COP.1.1/ENCRYPT:

* select at least “AES-CCM”

* select at least “128”

 

 

 

Justification

P-256 and AES-128-CCM are being added back in only for Bluetooth use to allow the Bluetooth PP-Module to be used with OS V4.3. AES-GCM is being added back in.

 
 
Site Map              Contact Us              Home