Guía de Seguridad de las TIC

CCN-STIC 2100

Cryptographic Mechanisms Evaluation Methodology

Metodología de Evaluación de Mecanismos Criptográficos
(MEMeC)

Noviembre de 2024
 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

cpage.mpr.gob.es
Catálogo de Publicaciones de la Administración General del Estado
https://cpage.mpr.gob.es

Edita:
CENTRO CRIPTOLOGICO
NACIONAL
cn=CENTRO CRIPTOLOGICO
NACIONAL, 2.5.4.97=VATES-
Pº de la Castellana 109, 28046 Madrid S2800155J, ou=CENTRO
 Centro Criptológico Nacional, 2024 CRIPTOLOGICO NACIONAL,
o=CENTRO CRIPTOLOGICO
Fecha de Edición: noviembre de 2024 NACIONAL, c=ES
NIPO: pendiente de asignación. 2025.01.24 13:05:46 +01'00'
LIMITACIÓN DE RESPONSABILIDAD
El presente documento se proporciona de acuerdo con los términos en él recogidos, rechazando
expresamente cualquier tipo de garantía implícita que se pueda encontrar relacionada. En ningún caso, el
Centro Criptológico Nacional puede ser considerado responsable del daño directo, indirecto, fortuito o
extraordinario derivado de la utilización de la información y software que se indican incluso cuando se
advierta de tal posibilidad.

AVISO LEGAL
Quedan rigurosamente prohibidas, sin la autorización escrita del Centro Criptológico Nacional, bajo las
sanciones establecidas en las leyes, la reproducción parcial o total de este documento por cualquier medio
o procedimiento, comprendidos la reprografía y el tratamiento informático, y la distribución de
ejemplares del mismo mediante alquiler o préstamo públicos.

Centro Criptológico Nacional 2

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

TABLE OF CONTENTS
2
1 INTRODUCTION.................................................................................................... 9
1.1 OBJECTIVE ................................................................................................................9
1.2 STRUCTURE OF THE DOCUMENT .............................................................................9
1.3 CERTIFICATION LEVELS ...........................................................................................10
1.4 INPUTS ....................................................................................................................11
1.5 EVALUATION PROCESS ...........................................................................................14
2 CCN CRYPTOGRAPHIC REQUIREMENTS ............................................................... 16
2.1 OBJECTIVE ..............................................................................................................16
2.2 DEFINITIONS ...........................................................................................................16
2.3 CRYPTOGRAPHIC EVALUATION TASKS ...................................................................18
2.3.1 CRYPTOGRAPHIC EVALUATION TESTS DEFINITION ...........................................21
3 CCN AGREED CRYPTOGRAPHIC MECHANISMS .................................................... 57
3.1 OBJECTIVE ..............................................................................................................57
3.2 DEFINITIONS ...........................................................................................................57
3.3 CRYPTOGRAPHIC EVALUATION TASKS ...................................................................58
3.3.1 CRYPTOGRAPHIC EVALUATION TESTS DEFINITION ...........................................61
4 CONFORMITY TESTING ..................................................................................... 128
4.1 OBJECTIVE ............................................................................................................128
4.2 DEFINITIONS .........................................................................................................128
4.3 CONFORMITY TESTING PROCESS .........................................................................129
4.4 CRYPTOGRAPHIC EVALUATION TASK ...................................................................130
4.4.1 CRYPTOGRAPHIC EVALUATION TEST DEFINITION...........................................131
5 AVOIDANCE OF IMPLEMENTATION PITFALLS .................................................... 160
5.1 OBJECTIVE ............................................................................................................160
5.2 DEFINITIONS .........................................................................................................160
5.3 CRYPTOGRAPHIC EVALUATION TASK ...................................................................160
5.3.1 CRYPTOGRAPHIC EVALUATION TEST DEFINITION...........................................162
6 ANNEX A: TRACEABILITY OF EVALUATION TASKS .............................................. 183
6.1 SYMMETRIC CRYPTOGRAPHIC MECHANISMS .....................................................183
6.1.1 HASH FUNCTIONS ............................................................................................183
6.1.2 SECRET SHARING .............................................................................................184
6.1.3 SYMMETRIC ENCRYPTION (CONFIDENTIALITY ONLY) .....................................184
6.1.4 DISK ENCRYPTION............................................................................................188
6.1.5 INTEGRITY MODES: MESSAGE AUTHENTICATION CODE ................................189
6.1.6 SYMMETRIC ENTITY AUTHENTICATION SCHEMES ..........................................193
6.1.7 AUTHENTICATED ENCRYPTION (AE) ................................................................194
6.1.8 KEY PROTECTION .............................................................................................198
6.1.9 KEY DERIVATION FUNCTIONS ..........................................................................199
6.1.10 PASSWORD PROTECTION/HASHING MECHANISMS .......................................202
6.2 ASYMMETRIC CRYPTOGRAPHIC MECHANISMS ...................................................205
6.2.1 ASYMMETRIC ENCRYPTION SCHEMES ............................................................205
6.2.2 DIGITAL SIGNATURE ........................................................................................207

Centro Criptológico Nacional 3

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

6.2.3 KEY ESTABLISHMENT .......................................................................................218

6.3 RANDOM NUMBER GENERATION ........................................................................223
6.3.1 TRUE RANDOM NUMBER GENERATORS .........................................................223
6.3.2 DETERMINISTIC RANDOM NUMBER GENERATORS ........................................224
6.4 GENERAL EVALUATION TASKS .............................................................................227
6.4.1 SENSITIVE SECURITY PARAMETER MANAGEMENT .........................................227
6.4.2 CRYPTOGRAPHIC MECHANISMS SELF-TEST ....................................................227
6.4.3 MITIGATION OF OTHER ATTACKS....................................................................227
6.4.4 CRYPTOGRAPHIC PROTOCOLS IMPLEMENTATION .........................................228
7 ANNEX B: CONFORMITY TESTS SPECIFICATION ................................................. 229
8 REFERENCES..................................................................................................... 230
9 ABBREVIATIONS............................................................................................... 238

Centro Criptológico Nacional 4

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

INDEX OF TABLES
Table 1. Security Strength of Keyed Cryptographic Mechanisms .................................. 17
Table 2. Cryptographic Evaluation Tests defined for CCN Requirements ...................... 21
Table 3. CSP Definition for each Cryptographic Mechanism.......................................... 36
Table 4. PSP Definition for each Cryptographic Mechanism.......................................... 37
Table 5. Temporally Sensitive Data for each Cryptographic Mechanism ...................... 54
Table 6. Cryptographic Evaluation Tests defined for CCN Agreed & Protocol ............... 60
Table 7. Agreed Block Ciphers ........................................................................................ 61
Table 8. Agreed Stream Cipher....................................................................................... 62
Table 9. Agreed Hash Functions ..................................................................................... 63
Table 10. Agreed Secret Sharing Primitives.................................................................... 64
Table 11. Agreed XOF Primitives .................................................................................... 65
Table 12. Agreed Symmetric Encryption Cryptographic Constructions ......................... 67
Table 13. Agreed Disk Encryption Cryptographic Constructions ................................... 69
Table 14. Agreed MAC Constructions............................................................................. 71
Table 15. Agreed Entity Authentication Challenges ....................................................... 74
Table 16. Agreed Authenticated Encryption Constructions ........................................... 75
Table 17. Agreed Key Protection Constructions............................................................. 77
Table 18. Agreed Key Derivation Constructions ............................................................. 78
Table 19. Agreed Password Protection/Hashing Constructions .................................... 79
Table 20. Agreed Asymmetric Primitives based on Integer Factorization ..................... 82
Table 21. Agreed RSA Key Generation Schemes ............................................................ 83
Table 22. Agreed Asymmetric Primitives based on FFDLOG .......................................... 84
Table 23. Agreed Asymmetric Primitives based on ECDLOG ......................................... 86
Table 24. Agreed Asymmetric Encryption Constructions............................................... 88
Table 25. Agreed Digital Signature Constructions .......................................................... 90
Table 26. Agreed Key Establishment Constructions ....................................................... 94
Table 27. Agreed Physical True Random Number Generators Classes .......................... 98
Table 28. Agreed Non-Physical True Random Number Generators Classes .................. 99
Table 29. Agreed Deterministic Random Number Generator Classes ......................... 101
Table 30. Agreed Deterministic Random Number Generators .................................... 103
Table 31. Agreed Schemes for Random Uniform Modular Distributions .................... 105
Table 32. Agreed Methods for Prime Random Generation ......................................... 105
Table 33. Agreed TLS Protocol Versions ....................................................................... 107
Table 34. Agreed TLS v1.3 Protocol Cipher suites ........................................................ 108
Table 35. Agreed TLS v1.3 PSK modes .......................................................................... 109
Table 36. Agreed TLS v1.3 Diffie-Hellman Groups ....................................................... 110
Table 37. Agreed TLS v1.3 Server-Client Digital Signature Schemes ............................ 111
Table 38. Agreed TLS v1.3 Digital Signature Algorithms on Certificates ...................... 112
Table 39. Agreed TLS v1.2 Protocol Cipher Suites ........................................................ 114
Table 40. Agreed TLS v1.2 Protocol Cipher Suites with PSK ......................................... 116
Table 41. Agreed TLS v1.2 Diffie-Hellman Groups ....................................................... 116
Table 42. Agreed TLS v1.2 Digital Signature Schemes.................................................. 117
Table 43. Agreed TLS v1.2 Hash Functions ................................................................... 117
Table 44. Agreed SSH Protocol Version ........................................................................ 118

Centro Criptológico Nacional 5

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Table 45. Agreed SSH Diffie-Hellman Groups............................................................... 119

Table 46. Agreed SSH Encryption Mechanisms ............................................................ 120
Table 47. Agreed SSH Origin Integrity and Authenticity Mechanisms ......................... 121
Table 48. Agreed SSH Server-Client Authentication Mechanisms ............................... 122
Table 49. Agreed IPsec Protocol Versions .................................................................... 123
Table 50. Agreed IKEv2 Diffie-Hellman Groups ............................................................ 125
Table 51. Agreed IKEv2 and ESP Origin Integrity and Authenticity Mechanisms ........ 126
Table 52. Agreed IKEv2 Pseudo-Random Functions..................................................... 126
Table 53. Agreed IKEv2 Digital Signature Schemes ...................................................... 127
Table 54. Cryptographic Evaluation Test defined for CCN Conformity ........................ 131
Table 55. Hash Functions Conformity Testing .............................................................. 133
Table 56. XOF Conformity Testing ................................................................................ 133
Table 57. Symmetric Encryption Conformity Testing ................................................... 134
Table 58. Disk Encryption Conformity Testing ............................................................. 135
Table 59. MAC Conformity Testing............................................................................... 136
Table 60. Symmetric Entity Authentication Conformity Testing.................................. 136
Table 61. Authenticated Encryption Conformity Testing ............................................. 137
Table 62. Key Protection Conformity Testing............................................................... 138
Table 63. Key Derivation Functions Conformity Testing .............................................. 146
Table 64. Password Protection/Hashing Mechanisms Conformity Testing ................. 147
Table 65. Asymmetric Encryption Conformity Testing ................................................. 149
Table 66. Digital Signature Conformity Testing ............................................................ 156
Table 67. Key Establishment Conformity Testing ......................................................... 158
Table 68. DRNG Conformity Testing ............................................................................. 159
Table 69. Cryptographic Evaluation Tests defined for CCN Pitfall ............................... 162
Table 70. Summary of Evaluation Tasks for SHA-2 Primitives...................................... 183
Table 71. Summary of Evaluation Tasks for SHA-3 Primitives...................................... 184
Table 72. Summary of Evaluation Tasks for Secret Sharing Primitives ........................ 184
Table 73. Summary of Evaluation Tasks for CBC Encryption Constructions ................ 185
Table 74. Summary of Evaluation Tasks for CBC-CS Encryption Constructions ........... 186
Table 75. Summary of Evaluation Tasks for CFB Encryption Constructions................. 187
Table 76. Summary of Evaluation Tasks for CTR Encryption Constructions ................ 187
Table 77. Summary of Evaluation Tasks for OFB Encryption Constructions ................ 188
Table 78. Summary of Evaluation Tasks for XTS Disk Encryption Constructions ......... 189
Table 79. Summary of Evaluation Tasks for CMAC Constructions based on AES ........ 190
Table 80. Summary of Evaluation Tasks for CBC-MAC Constructions based on AES ... 190
Table 81. Summary of Evaluation Tasks for HMAC Constructions based on SHA ....... 191
Table 82. Summary of Evaluation Tasks for GMAC Constructions based on AES ........ 192
Table 83. Summary of Evaluation Tasks for KMAC Constructions based on XOF ........ 193
Table 84. Summary of Evaluation Tasks for Entity Authentication Schemes............... 193
Table 85. Summary of Evaluation Tasks Encrypt-then-MAC Constructions ................ 194
Table 86. Summary of Evaluation Tasks for CCM AE Constructions ............................ 195
Table 87. Summary of Evaluation Tasks for GCM AE Constructions ............................ 196
Table 88. Summary of Evaluation Tasks for EAX AE Constructions.............................. 197
Table 89. Summary of Evaluation Tasks for ChaCha20-Poly1305 AE Constructions ... 197

Centro Criptológico Nacional 6

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Table 90. Summary of Evaluation Tasks for SIV Key Protection Constructions ........... 198
Table 91. Summary of Evaluation Tasks for Keywrap Key Protection Constructions .. 199
Table 92. Summary of Evaluation Tasks for NIST SP800-56 A/B/C KDF ....................... 200
Table 93. Summary of Evaluation Tasks for NIST SP800-108 KDF................................ 200
Table 94. Summary of Evaluation Tasks for ANSI-X9.63 KDF ....................................... 201
Table 95. Summary of Evaluation Tasks for PBKDF2 Key Derivation Constructions .... 202
Table 96. Summary of Evaluation Tasks for HKDF Key Derivation Constructions........ 202
Table 97. Summary of Evaluation Tasks for Argon2id Password Protection ............... 203
Table 98. Summary of Evaluation Tasks for PBKDF2 Password Protection ................. 204
Table 99. Summary of Evaluation Tasks for SCRYPT Password Protection .................. 204
Table 100. Summary of Evaluation Tasks for RSA OAEP Asymmetric Encryption........ 206
Table 101. Summary of Evaluation Tasks for RSA PKCS#1v1.5 Encryption Scheme .... 207
Table 102. Summary of Evaluation Tasks for RSA-PSS Digital Signature...................... 208
Table 103. Summary of Evaluation Tasks for KCDSA Digital Signature ........................ 209
Table 104. Summary of Evaluation Tasks for Schnorr Digital Signature ...................... 210
Table 105. Summary of Evaluation Tasks for DSA Digital Signature ............................ 211
Table 106. Summary of Evaluation Tasks for EC-KCDSA Digital Signature................... 212
Table 107. Summary of Evaluation Tasks for EC-DSA Digital Signature ....................... 213
Table 108. Summary of Evaluation Tasks for EC-GDSA Digital Signature .................... 214
Table 109. Summary of Evaluation Tasks for EC-Schnorr Digital Signature ................. 215
Table 110. Summary of Evaluation Tasks for EdDSA Digital Signature ........................ 216
Table 111. Summary of Evaluation Tasks for RSA PKCS#1v1.5 Digital Signature......... 217
Table 112. Summary of Evaluation Tasks for XMSS Digital Signature.......................... 218
Table 113. Summary of Evaluation Tasks for DH Key Establishment Constructions ... 219
Table 114. Summary of Evaluation Tasks for DLIES-KEM Constructions ..................... 220
Table 115. Summary of Evaluation Tasks for ECDH Key Establishment Constructions 221
Table 116. Summary of Evaluation Tasks for ECIES-KEM Constructions...................... 222
Table 117. Summary of Evaluation Tasks for PTRNGs.................................................. 223
Table 118. Summary of Evaluation Tasks for NPTRNGs ............................................... 223
Table 119. Summary of Evaluation Tasks for HMAC-DRBG Constructions .................. 224
Table 120. Summary of Evaluation Tasks for Hash-DRBG Constructions .................... 225
Table 121. Summary of Evaluation Tasks for CTR-DRBG Constructions ...................... 226
Table 122. Summary of Evaluation Tasks for Generic DRNG Constructions ................ 226
Table 123. Summary of Evaluation Tasks for SSP Management .................................. 227
Table 124. Summary of Evaluation Tasks for Self-Test Implementation ..................... 227
Table 125. Summary of Evaluation Tasks for the Mitigation of Other Attacks ............ 228
Table 126. Summary of Evaluation Tasks for Cryptographic Protocols ....................... 228

Centro Criptológico Nacional 7

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

INDEX OF FIGURES
Figure 1. Conformity Testing Process Flow Diagram .................................................... 130

Centro Criptológico Nacional 8

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

1 INTRODUCTION
1. The use of cryptography is becoming more and more present in technological
products due to the necessity of protecting the information to ensure its
confidentiality, integrity, and authenticity. Thus, it is necessary to verify the
cryptographic mechanisms implemented on these technological products to
guarantee their correct operativity and their correct usage and implementation
by the vendors.

1.1 OBJECTIVE
2. The objective of this document is to define a common methodology to evaluate
the cryptographic implementations included in technological products that are
going to be evaluated under the Common Criteria (CC), LINCE, or STIC
certifications according to the security requirements related to the certification
levels defined in the following sections.
3. This methodology provides the steps to verify that the cryptographic
mechanisms implemented in the Target Of Evaluation (TOE) and its
parameterization comply with the requirements defined by the Centro
Criptológico Nacional (CCN). Moreover, this methodology defines the steps to
check the correct operativity of each cryptographic mechanism employing test
vectors as input to carry out the conformity testing for each of them.
4. On top of providing the steps to check the correct parameterization and
operativity of each cryptographic mechanism, this methodology also defines
how to check that each of them is implemented and executed avoiding common
implementation pitfalls that may cause misbehavior on the cryptographic
mechanism, and that could incur in revealing sensitive information such as user
data and Sensitive Security Parameters (SSPs).
5. Finally, the methodology includes specific tasks to verify that the TOE checks the
correct operativity of the implemented cryptographic mechanisms using self-
tests, that the SSP management performed by the TOE complies with the CCN
requirements and is based on approved cryptographic mechanisms, and that the
TOE implements additional protections for the mitigation of other attacks.

1.2 STRUCTURE OF THE DOCUMENT

6. The definition of the cryptographic requirements to be met by the TOE and the
evaluation tasks to be performed by the tester has been made following this
structure:
• The cryptographic requirements start with the words “The TOE shall”
followed by the description of the requirement to be met by the TOE.
• The evaluation tasks are defined in a table composed of two main parts.

Centro Criptológico Nacional 9

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

o The first part specifies an evaluation task ID and a brief description of

the tasks to be performed by the tester, which begins with the words
“The tester shall” followed by a brief description and the required
inputs by the tester to carry out the evaluation. The task ID is denoted
using bold typography with the following format CCN-NAME, where
“NAME” is the name assigned to the task.
o The second part defines the certification levels for which the
evaluation task shall be executed. The format of an evaluation task is
as detailed below:

CRYPTOGRAPHIC CERTIFICATION
CCN-NAME
EVALUATION TASK LEVEL

The tester shall… CL1, CL2,

[Cryptographic Evaluation Task Definition] and/or CL3

7. The cryptographic tests associated with each evaluation task are defined in a
table divided into two columns.
• The first column contains the identifier (ID) of the test and a brief description
of the activities to be performed by the tester.
• The second column specifies the inputs required to perform the test. The ID
is written in bold typography following the format CCN-NAME/TestName,
where “CCN-NAME” is the ID of the evaluation task associated with the test,
and “TestName” is the specific name of the cryptographic test to be
performed:

CCN-NAME/TestName Inputs

[Cryptographic Evaluation Test Definition]

1.3 CERTIFICATION LEVELS

8. This methodology defines three increasing certification levels:
 Certification Level 1 (CL1): This is the lowest certification level. At this level,
the main objective is to verify the compliance of the cryptographic primitives
and constructions implemented in the TOE according to the [CCN-STIC-221]
guidance. Therefore, it only requires performing the CCN-AGREED and CCN-
PROTOCOL evaluation tasks and verifying the correct operativity of the
cryptographic mechanisms by executing the CCN-CONFORMITY evaluation
task.
 Certification Level 2 (CL2): This is the intermediate certification level. At this
level, all the evaluation tasks defined in this methodology shall be performed.

Centro Criptológico Nacional 10

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Regarding the Management of SSPs related to the CCN-SSP evaluation task,

this certification level only requires evidence of zeroization of the SSPs
managed by the TOE.
 Certification Level 3 (CL3): This is the most advanced certification level. At
this level, all the evaluation tasks defined in this methodology shall be
performed. The difference with the CL2 level is that, in this case, evidence of
the entire lifecycle of the SSPs (from its creation to its destruction) is required
to perform the CCN-SSP evaluation task.

1.4 INPUTS
9. To simplify the revision process of the documentation and to reduce the
evaluation time of the evaluation tasks defined in this methodology, the vendor
shall provide the following inputs as part of the documentation required to
perform the cryptographic mechanisms evaluation:
I1: Cryptographic Mechanisms Evaluation Vendor Questionnaire and, optionally,
Vendor Documentation
10. The documentation package provided by the vendor is composed of:
- Vendor Questionnaire (VQ): a document with answers to a battery of
questions provided by the laboratory in order to extract the main
information related to the cryptographic mechanisms implemented by the
TOE. These questions aim to demonstrate that the implementation of the
cryptographic mechanisms (primitives and constructions) complies with the
cryptographic requirements detailed throughout this methodology. For
those cases for which the space provided in the VQ is not enough, the vendor
can provide the required information by adding annexes to the VQ. In the
case of CL1 evaluations, a lite version is available where only the evaluation
tasks that apply to this level are contemplated.
- Vendor Documentation: the vendor documentation may encompass any
document supplied by the vendor to provide additional information to that
contained in the Vendor Questionnaire. This information may be used by the
vendor to support the information specified in the VQ, but in no case it will
be a substitute since it will not be considered part of the evaluation.
I2: Test and operation interfaces to verify the TOE functionality
11. On the one hand, the vendor shall specify operational interfaces that allow the
tester to verify the correct operation of the TOE according to the cryptographic
implementation described in I1.
12. On the other hand, the vendor shall also specify how the cryptographic
mechanisms can be addressed, allowing the submission of input values, such as
the key value in the case of keyed mechanisms. For randomized mechanisms,
this testing interface may also possibly allow the submission of values to be used
instead of the output of a random generator. The exact formatting conventions

Centro Criptológico Nacional 11

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

for the external interface of the mechanism implementation of the system under
evaluation, e.g., whether the input and output parameters are represented as
binary strings or byte strings, shall be provided. I2 also specifies how to collect
the corresponding output values. For all mechanisms of the system under
evaluation, this interface shall allow the tester to directly access the primitives
and not only the modes.
13. These interfaces can either be operational interfaces or testing interfaces that
might not be implemented in the final design to address the cryptographic
mechanisms. In fact, such interfaces might be deliberately unavailable for
security considerations. It is not mandatory to provide such interfaces in the final
system under evaluation. A modified system that permits access to such
interfaces is acceptable input. Sub-systems containing such interfaces, before
the system integration, also constitute an acceptable input. In either case, a
detailed description of the differences with the final system is necessary to
justify that the tests will be valid in the final system.
I3: Conformity testing tools
14. The tester is responsible for verifying the correct operation of the cryptographic
mechanisms implemented in the TOE by executing the conformity tests
associated with each cryptographic mechanism (primitives and constructions),
according to Section 4 Conformity Testing, to obtain the response files detailed
in I4.
15. Taking into account that the evaluation time is limited, the vendor shall provide
the tester with the necessary test environment to demonstrate the conformity
of the cryptographic mechanisms. This test environment shall be composed of a
set of software/firmware tools (e.g., test harnesses, scripts) that will allow the
tester to generate and validate the results from each cryptographic mechanism
using the conformity test vectors as input.
16. In addition, the vendor shall provide the tester with the necessary guidelines to
properly configure and execute the test environment.
17. There may be some specific cases where the design and architecture of the TOE
difficult the possibility to provide the tester with scripts to verify the conformity
testing results. In such cases, on-site audits or telematic sessions will be allowed
in order to demonstrate to the tester that the TOE successfully performs the
conformity test.
I4: RSPs obtained from the conformity testing
18. The RSPs are the response files composed of the results obtained from the TOE
when the conformity test vectors are used as input for each cryptographic
mechanism. They shall be obtained using the test vectors generated by the
laboratory. They will be the result of the conformity testing process. For more
details, please consult Section 4 Conformity Testing.

Centro Criptológico Nacional 12

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

I5: Evidence of the avoidance of implementation pitfalls

19. The vendor shall provide evidence of the avoidance of the implementation
pitfalls associated with each cryptographic mechanism implemented in the TOE.
The evidence shall consist of a piece of source code for CL2 evaluations or
pointers to I6 for CL3 evaluations.
I6: Implementation representation
20. For each cryptographic mechanism of the system under evaluation, the
implementation representation is the most abstract representation of the
mechanism. The representation is used to create the implementation. It may be
software source code, firmware source code, hardware diagrams, and/or
hardware design language code or layout data. Source code annotations are also
required to help the tester establish the correspondence between the
specification and the implementation.
21. If the cryptographic implementation is provided by an external library, I6 shall
include the source code that calls the library functions. This allows the tester to
analyze the correctness of the library calls.
22. Additional information such as compilers, compilation options, and scripts are
part of the implementation if they contribute to the generation of the
mechanism implementation. Programming language specifications shall be
provided. Compilation configuration files may also be part of the evaluation
inputs if they contribute to the implementation of cryptographic mechanisms.
I7: Self-Test input vectors
23. The tester is responsible for verifying the validity of the self-test input vectors
implemented for each cryptographic mechanism using the CCN Cryptographic
Tool as the cryptographic reference implementation.
24. To perform this validation process, the tester shall generate a self-test template
file in JSON format for each cryptographic mechanism implemented in the TOE,
containing the parameters associated with the supported configuration. The
vendor shall complete these templates with the test vectors used in each of the
cryptographic mechanisms self-tests implemented.
25. Finally, the tester shall use the self-test files to perform the validation of the
input vectors using the CCN Cryptographic Tool. For more details, please consult
Section 2.3.1.3 “Cryptographic Mechanisms Self-Test”.
I8: Random Number Generation Vendor Questionnaire
26. In this document, the vendor shall include all the necessary evidence to evaluate
the compliance of the TRNGs and DRNGs implemented by the TOE in accordance
with the AIS-31 and AIS-20 functionality classes respectively, agreed in this
methodology.

Centro Criptológico Nacional 13

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

27. The document shall include all the evidence needed by the tester to evaluate all
the requirements described in the [FCRNG] document for each functionality
class.
28. This document follows the same philosophy as I1 but for the RNG design
implemented by the TOE.

1.5 EVALUATION PROCESS

29. This section describes the steps to be followed by the tester to perform a
cryptographic mechanisms evaluation once the inputs detailed above have been
received from the vendor.
30. The tester shall go through the sections of this document executing the
cryptographic evaluation tasks associated with the certification level related to
the TOE evaluation. Considering that each evaluation task is composed of one or
several tests, the tester shall execute those categorized as mandatory and those
categorized as Implementation-Dependent (Impl-Dep), only in case the TOE
supports the associated functionality. At the beginning of each section, a
summary table is provided specifying the cryptographic tests of each evaluation
task, along with their categorization. The table format is detailed below, the first
column indicates the associated evaluation task, the second column the test
name, and the last column the test categorization:

Cryptographic Cryptographic
Test Categorization
Evaluation Task Evaluation Test

CCN-NAME CCN-NAME/TestName Mandatory or Impl-Dep

31. To determine which Implementation-Dependent tests related to the

cryptographic mechanisms shall be executed, the tester shall verify I1 to identify
the cryptographic primitives and constructions implemented by the TOE, and
use the summary tables defined in “Annex A: Traceability of Evaluation Tasks”.
32. Following this scheme, the tester shall verify that the implemented
cryptographic mechanisms meet the cryptographic requirements defined by
CCN in Section 2 “CCN Cryptographic Requirements” and that they are
considered agreed upon and use a valid parameterization according to Section 3
“CCN Agreed Cryptographic Mechanisms”.
33. In the case of CCN-approved cryptographic mechanisms that employ a valid
parameterization, the tester shall verify their correct operation by executing the
conformity tests, as detailed in Section 4 “Conformity Testing” using the CCN
Cryptographic Tool as the cryptographic reference implementation. In addition,
the tester shall verify that the cryptographic mechanisms have been
implemented avoiding the common implementation pitfalls defined in Section 5
“Avoidance of Implementation Pitfalls”.

Centro Criptológico Nacional 14

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

34. Following the same approach as for the cryptographic mechanisms, the tester
shall use I1 and the summary tables defined in “Annex A: Traceability of
Evaluation Tasks” to identify the cryptographic evaluation tests that shall be
executed regarding SSP management, implementation of self-tests, and
mitigation of other attacks.

Centro Criptológico Nacional 15

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

2 CCN CRYPTOGRAPHIC REQUIREMENTS

2.1 OBJECTIVE
35. This chapter defines the security requirements directly related to the correct
implementation of the cryptographic mechanism supported by the TOE. The
security requirements have been defined by CCN in conjunction with those
specified in the [SOGIS-HEP] document by the SOG-IS participants.
36. Therefore, this section provides vendors with the cryptographic requirements
that shall be met by the TOE in order to perform a valid implementation of the
cryptographic mechanisms. In addition, it provides testers with the evaluation
tasks necessary to verify the correct compliance with the requirements during
the cryptographic mechanisms’ evaluation process.

2.2 DEFINITIONS
Cryptographic Mechanisms
37. The cryptographic mechanisms can be classified according to the following main
criteria:
a) Key Type:
 Symmetric mechanisms: cryptographic mechanisms that employ the
same key for encryption and decryption operations. Therefore, this
key must be secret and a key agreement protocol or a secure channel
must be used to distribute it between the sender and receiver.
 Asymmetric mechanisms: cryptographic mechanisms that use public-
private key pairs to perform cryptographic operations.
 Message digest functions: cryptographic mechanisms that do not
require the use of keys. Their functionality is to provide a fixed-length
digest from a variable-length input.
b) Security Strength: the security strength is usually expressed according to the
attack complexity required to break the mechanism; therefore, an attack
complexity of n bits means that it takes 2n operations to perform the attack.
The following table summarizes the cryptographic mechanisms that provide
equivalent security strength.

Asymmetric Mechanisms
Symmetric
Security DSA, RSA, and Elliptic
Mechanisms Key
Strength (Bits) Diffie-Hellman Curves order
Length (in bits)
modulus length of base point
(in bits) G (in bits)

112 112 2048 224

Centro Criptológico Nacional 16

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Asymmetric Mechanisms
Symmetric
Security DSA, RSA, and Elliptic
Mechanisms Key
Strength (Bits) Diffie-Hellman Curves order
Length (in bits)
modulus length of base point
(in bits) G (in bits)

128 128 3072 256

192 192 7680 384

256 256 15360 512

Table 1. Security Strength of Keyed Cryptographic Mechanisms

Primitives and Constructions
38. It is common to distinguish cryptographic mechanisms according to their
complexity. Cryptographic mechanisms are often built from more primary
mechanisms, denoted as cryptographic primitives, in order to achieve higher-
level security objectives. When this is the case, they are denoted as
cryptographic constructions. The construction of cryptographic mechanisms
upon an established cryptographic primitive(s) allows one to derive confidence
from the prior analysis of the primitive(s): typically, the security of the
cryptographic construction can be expressed in terms of the security of the
underlying primitive(s), possibly together with some quantifiable bounded loss
of assurance.
Self-Test Known Answer Tests (KATs)
39. Self-Test Known Answer Tests (KATs) are basic functional tests of the
cryptographic mechanisms implemented in the TOE based on calculating the
results for precalculated known inputs. These KATs are automatically executed
by the TOE under certain conditions in order to verify that the implemented
cryptographic mechanisms are working properly before their execution. In most
cases, the self-test KATs are executed to produce valid results from known
inputs. However, there are some cases in which is necessary to test invalid
results.
Sensitive Data
40. Sensitive data refers to any data that shall be protected by the TOE in the sense
of confidentiality and/or integrity in order to prevent disclosure to an attacker
who might use advanced techniques such as side-channel attacks. Specifically,
sensitive data encompass any cryptographic parameter whose disclosure could
compromise the operation of any cryptographic mechanism, allowing an
attacker to derive the encryption key, input, or outputs of the cryptographic
mechanism.

Centro Criptológico Nacional 17

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

41. Some examples of sensitive data are:

- Sensitive Security Parameters (SSPs): they are divided into critical security
parameters (CSP) and public security parameters (PSP).
- Critical Security Parameters (CSPs): security-related information whose
disclosure or modification can compromise the security of a TOE (e.g., secret
and private cryptographic keys, authentication data such as passwords, PINs,
etc.).
- Public Security Parameters (PSPs): security-related public information whose
modification can compromise the security of the TOE (e.g., public
cryptographic keys, public key certificates, self-signed certificates, etc.).
- Internal States of Cryptographic Primitives: they are related to the internal
operations performed by some cryptographic mechanisms, for example,
block ciphers and hashing cryptographic mechanisms.

2.3 CRYPTOGRAPHIC EVALUATION TASKS

42. This section contains the cryptographic requirements established by CCN that
shall be considered by the vendors in the case of implementing a TOE with
cryptographic capabilities.
43. In particular, the list of cryptographic requirements has been grouped into the
following main topics:
• Implementation of the Cryptographic Mechanisms (constructions and
primitives) to ensure that they correspond to those declared by the vendor.
• Secure Management of SSPs during their life cycle, from generation to
destruction, employing approved cryptographic mechanisms for generation,
entry/output, storage, and zeroization.
• Implementation of Self-Tests for the cryptographic mechanisms
implemented by the TOE to ensure their correct operativity.
• Implementation of Security Protections to ensure mitigation of other
attacks based on side-channel and differential fault analysis (DFA).
44. Therefore, the following list of cryptographic evaluation tasks related to the
cryptographic implementation requirements established by CCN and comprising
all the topics described above have been defined:

CRYPTOGRAPHIC CERTIFICATION
CCN-MECHANISM
EVALUATION TASK LEVEL

The tester shall verify that all the cryptographic mechanisms

implemented by the TOE match with those declared by the CL2 and CL3
vendor in I1.

Centro Criptológico Nacional 18

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CRYPTOGRAPHIC CERTIFICATION
CCN-SSP
EVALUATION TASK LEVEL

The tester shall verify that the TOE performs secure

management of Security Sensitive Parameters (SSPs) during
their lifecycle, from generation to destruction, using CL2 and CL3
approved cryptographic mechanisms for generation,
entry/output, storage, and zeroization.

CRYPTOGRAPHIC CERTIFICATION
CCN-SELFTEST
EVALUATION TASK LEVEL

The tester shall verify that the TOE correctly implements and
executes the self-tests of the implemented cryptographic CL2 and CL3
mechanisms.

CRYPTOGRAPHIC CERTIFICATION
CCN-MITIGATION
EVALUATION TASK LEVEL

The tester shall verify that the TOE correctly implements

security protections for the mitigation of other attacks based CL2 and CL3
on side-channel attacks and differential fault analysis (DFA).

45. For the correct completion of the evaluation tasks, each one has been divided
into a set of cryptographic evaluation tests. The tester shall perform the
associated mandatory tests, and also the implementation-dependent tests, if
applicable, according to the TOE implementation.

Cryptographic Test
Cryptographic Evaluation Test
Evaluation Task Categorization

CCN-MECHANISM/BlockCipher Impl-Dep

CCN-MECHANISM/StreamCipher Impl-Dep
CCN-MECHANISM CCN-MECHANISM/Hash Impl-Dep
Cryptographic
Mechanisms CCN-MECHANISM/SecretSharing Impl-Dep

CCN-MECHANISM/XOF Impl-Dep

CCN-MECHANISM/SymEncryption Impl-Dep

Centro Criptológico Nacional 19

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Test
Cryptographic Evaluation Test
Evaluation Task Categorization

CCN-MECHANISM/DiskEncryption Impl-Dep

CCN-MECHANISM/MAC Impl-Dep

CCN-MECHANISM/EntityAuth Impl-Dep

CCN-MECHANISM/AuthEncryption Impl-Dep

CCN-MECHANISM/KeyProtection Impl-Dep

CCN-MECHANISM/KeyDerivation Impl-Dep

CCN-
Impl-Dep
MECHANISM/PasswordMechanisms

CCN-MECHANISM/RSA Impl-Dep

CCN-MECHANISM/FFDLOG Impl-Dep

CCN-MECHANISM/ECDLOG Impl-Dep

CCN-MECHANISM/AsymEncryption Impl-Dep

CCN-MECHANISM/DigitalSignature Impl-Dep

CCN-MECHANISM/KeyEstablishment Impl-Dep

CCN-MECHANISM/TRNG Impl-Dep

CCN-MECHANISM/DRNG Impl-Dep

CCN-SSP/Generation Impl-Dep

CCN-SSP/Transport Impl-Dep
CCN-SSP
CCN-SSP/Storage Mandatory
SSP Management
CCN-SSP/Zeroization.1 Mandatory

CCN-SSP/Zeroization.2 Mandatory

CCN-SELFTEST
CCN-SELFTEST/Implementation Mandatory
Self-Tests

Centro Criptológico Nacional 20

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Test
Cryptographic Evaluation Test
Evaluation Task Categorization

CCN-MITIGATION
Mitigation of CCN-MITIGATION/Mitigation Mandatory
Other Attacks

Table 2. Cryptographic Evaluation Tests defined for CCN Requirements

2.3.1 CRYPTOGRAPHIC EVALUATION TESTS DEFINITION

46. This subsection defines the cryptographic evaluation tests that shall be
performed by the tester to accomplish the evaluation tasks, based on the
cryptographic implementation requirements established by CCN.

2.3.1.1 CRYPTOGRAPHIC MECHANISMS IMPLEMENTATION

47. This first topic defines the cryptographic evaluation tests to verify the correct
implementation by the TOE of each cryptographic mechanism declared by the
vendor in I1, in order to fulfill the CCN-MECHANISM evaluation task.

2.3.1.1.1 Symmetric Elementary Primitives

2.3.1.1.1.1 Block Cipher

48. In case the TOE implements cryptographic primitives based on approved block
ciphers:
• The TOE shall:
- Include a self-test KAT for each block cipher cryptographic primitive
implemented in the TOE, even if they are not in use.
- Include a self-test KAT for each key length (128, 192, and 256 bits)
implemented in the TOE, even if they are not in use.
- Include a self-test KAT for each direction (ciphering and deciphering)
implemented in the TOE, even if they are not in use.
• The tester shall perform the following cryptographic evaluation test:

CCN-MECHANISM/BlockCipher Inputs

In the case of CL2 evaluations, operate the TOE (using I2) to verify I1
that the block cipher cryptographic primitives implemented by the I2
TOE match with those declared by the vendor in I1.
I6

Centro Criptológico Nacional 21

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-MECHANISM/BlockCipher Inputs
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned.

2.3.1.1.1.2 Stream Cipher

49. In case the TOE implements cryptographic primitives based on approved stream
ciphers:
• The TOE shall:
- Include a self-test KAT for each stream cipher cryptographic primitive
implemented in the TOE, even if they are not in use.
- Include a self-test KAT for each direction (ciphering and deciphering)
implemented in the TOE, even if they are not in use.
• The tester shall perform the following cryptographic evaluation test:

CCN-MECHANISM/StreamCipher Inputs

In the case of CL2 evaluations, operate the TOE (using I2) to verify
that the stream cipher cryptographic primitives implemented by I1
the TOE match with those declared by the vendor in I1.
I2
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above- I6
mentioned.

2.3.1.1.1.3 Hash Functions

50. In case the TOE implements cryptographic primitives based on approved hash
functions:
• The TOE shall include a self-test KAT for each hash primitive implemented in the
TOE, even if they are not in use.
• The tester shall perform the following cryptographic evaluation test:

CCN-MECHANISM/Hash Inputs

In the case of CL2 evaluations, operate the TOE (using I2) to verify
that the hash cryptographic primitives implemented by the TOE I1
match with those declared by the vendor in I1.
I2
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above- I6
mentioned.

Centro Criptológico Nacional 22

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

2.3.1.1.1.4 Secret Sharing

51. In case the TOE implements approved secret-sharing cryptographic primitives:
• The TOE shall include a self-test KAT for the shared secret recombination and
generation operations.
• The tester shall perform the following cryptographic evaluation test:

CCN-MECHANISM/SecretSharing Inputs

In the case of CL2 evaluations, operate the TOE (using I2) to verify
that the secret-sharing cryptographic primitives implemented by I1
the TOE match with those declared by the vendor in I1.
I2
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above- I6
mentioned.

2.3.1.1.1.5 Extendable-Output Functions (XOF)

52. In case the TOE implements cryptographic primitives based on approved
extendable-output functions (XOF):
• The TOE shall include a self-test KAT for each XOF primitive implemented in the
TOE, even if they are not in use.
• The tester shall perform the following cryptographic evaluation test:

CCN-MECHANISM/XOF Inputs

In the case of CL2 evaluations, operate the TOE (using I2) to verify
that the XOF cryptographic primitives implemented by the TOE I1
match with those declared by the vendor in I1.
I2
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above- I6
mentioned.

2.3.1.1.2 Symmetric Constructions

2.3.1.1.2.1 Symmetric Encryption (Confidentiality Only)

53. In case the TOE implements symmetric encryption based on approved block
cipher constructions:
• The TOE shall:
- Include a self-test KAT for each symmetric encryption construction
implemented in the TOE, even if they are not in use.
- Include a self-test KAT for each key length (128, 192, and 256 bits)
implemented in the TOE, even if they are not in use.

Centro Criptológico Nacional 23

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

- Include a self-test KAT for each direction (ciphering and deciphering)

implemented in the TOE, even if they are not in use.
• The tester shall perform the following cryptographic evaluation test:

CCN-MECHANISM/SymEncryption Inputs

In the case of CL2 evaluations, operate the TOE (using I2) to verify
that the symmetric encryption cryptographic constructions
implemented by the TOE match with those declared by the vendor I1
in I1. I2
In the case of CL3 evaluations, operate the TOE (using I2) and I6
perform a source code review (using I6) to verify the above-
mentioned.

2.3.1.1.2.2 Disk Encryption

54. In case the TOE implements symmetric disk encryption based on approved block
cipher constructions:
• The TOE shall:
- Include a self-test KAT for each disk encryption construction implemented
in the TOE, even if they are not in use.
- Include a self-test KAT for each key length (256 and 512 bits for XTS
operation mode) implemented in the TOE, even if they are not in use.
- Include a self-test KAT for each direction (ciphering and deciphering)
implemented in the TOE, even if they are not in use.
• The tester shall perform the following cryptographic evaluation test:

CCN-MECHANISM/DiskEncryption Inputs

In the case of CL2 evaluations, operate the TOE (using I2) to verify
that the disk encryption cryptographic constructions implemented I1
by the TOE match with those declared by the vendor in I1.
I2
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above- I6
mentioned.

2.3.1.1.2.3 Integrity Modes: Message Authentication Code

55. In case the TOE implements integrity modes based on approved message
authentication code constructions:

Centro Criptológico Nacional 24

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

• The TOE shall:

- Include a self-test KAT (with correct and incorrect MAC values) for each
MAC construction implemented in the TOE, even if they are not in use.
- Include the self-test KATs for the underlying mechanisms:
 For MAC constructions relying on AES constructions, see section
2.3.1.1.2.1 “Symmetric Encryption (Confidentiality Only)”.
 For MAC constructions relying on Hash primitives, see section
2.3.1.1.1.3 “Hash Functions”.
 For the MAC constructions relying on XOF primitives, see section
2.3.1.1.1.5 “Extendable-Output Functions (XOF)”.
• The tester shall perform the following cryptographic evaluation test:

CCN-MECHANISM/MAC Inputs

In the case of CL2 evaluations, operate the TOE (using I2) to verify
that the MAC cryptographic constructions implemented by the I1
TOE match with those declared by the vendor in I1.
I2
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above- I6
mentioned.

2.3.1.1.2.4 Symmetric Entity Authentication Schemes

56. In case the TOE implements approved symmetric entity authentication
constructions to prove the identity against a verifier by demonstrating
knowledge of a certain secret in a random challenge-response protocol:
• The TOE shall:
- Include a self-test KAT for each symmetric entity authentication
construction implemented in the TOE, even if they are not in use.
- Include the self-test KATs for the underlying mechanisms:
 For symmetric entity authentication constructions relying on AES
constructions, see section 2.3.1.1.2.1 “Symmetric Encryption
(Confidentiality Only)”.
 For symmetric entity authentication constructions relying on MAC
constructions, see section 2.3.1.1.2.3 “Integrity Modes: Message
Authentication Code”.
• The tester shall perform the following cryptographic evaluation test:

Centro Criptológico Nacional 25

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-MECHANISM/EntityAuth Inputs

In the case of CL2 evaluations, operate the TOE (using I2) to verify
that the symmetric entity authenticated constructions
implemented by the TOE match with those declared by the vendor I1
in I1. I2
In the case of CL3 evaluations, operate the TOE (using I2) and I6
perform a source code review (using I6) to verify the above-
mentioned.

2.3.1.1.2.5 Authenticated Encryption (AE)

57. In case the TOE implements approved authenticated encryption cryptographic
constructions to provide confidentiality and integrity:
• The TOE shall:
- Include a self-test KAT for each authenticated encryption construction
implemented in the TOE, even if they are not in use.
- Include a self-test KAT for each key length (128, 192, and 256 bits)
implemented in the TOE, even if they are not in use.
- Include a self-test KAT for each direction (ciphering and deciphering)
implemented in the TOE, even if they are not in use.
- Include the self-test KATs for the underlying mechanisms:
 For AE constructions relying on AES constructions, see section
2.3.1.1.2.1 “Symmetric Encryption (Confidentiality Only)”.
 For AE constructions relying on MAC constructions, see section
2.3.1.1.2.3 “Integrity Modes: Message Authentication Code”.
 For AE constructions relying on Stream cipher primitives, see
section 2.3.1.1.1.2 “Stream Cipher”.
• The tester shall perform the following cryptographic evaluation test:

CCN-MECHANISM/AuthEncryption Inputs

In the case of CL2 evaluations, operate the TOE (using I2) to verify
that the authenticated encryption cryptographic constructions
implemented by the TOE match with those declared by the vendor I1
in I1. I2
In the case of CL3 evaluations, operate the TOE (using I2) and I6
perform a source code review (using I6) to verify the above-
mentioned.

Centro Criptológico Nacional 26

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

2.3.1.1.2.6 Key Protection

58. In case the TOE implements approved key protection constructions to secure
store and transmit CSPs:
• The TOE shall:
- Include a self-test KAT for each key protection construction implemented
in the TOE, even if they are not in use.
- Include a self-test KAT for each key length implemented in the TOE, even
if they are not in use.
- Include a self-test KAT for each direction (ciphering and deciphering)
implemented in the TOE, even if they are not in use.
- Include the self-test KATs for the underlying mechanisms:
 For key protection constructions relying on AES constructions, see
section 2.3.1.1.2.1 “Symmetric Encryption (Confidentiality Only)”.
 For key protection constructions relying on MAC constructions,
see section 2.3.1.1.2.3 “Integrity Modes: Message Authentication
Code”.
- In the case of implementing an authenticated encryption cryptographic
construction for key protection functionality, include the self-test KATs
described in section 2.3.1.1.2.5 “Authenticated Encryption (AE)”.
• The tester shall perform the following cryptographic evaluation test:

CCN-MECHANISM/KeyProtection Inputs

In the case of CL2 evaluations, operate the TOE (using I2) to verify
that the key protection cryptographic constructions implemented I1
by the TOE match with those declared by the vendor in I1.
I2
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above- I6
mentioned.

2.3.1.1.2.7 Key Derivation Function (KDF)

59. In case the TOE implements approved key derivation functions to derive
cryptographic keys:
• The TOE shall:
- Include a self-test KAT for each key derivation function implemented in
the TOE, even if they are not in use.
- Include the self-test KATs for the underlying mechanisms:
 For KDF constructions relying on Hash primitives, see section
2.3.1.1.1.3 “Hash Functions”.

Centro Criptológico Nacional 27

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

 For KDF constructions relying on MAC constructions, see section

2.3.1.1.2.3 “Integrity Modes: Message Authentication Code”.
 For KDF constructions relying on other KDF constructions, the
ones described in this section.
• The tester shall perform the following cryptographic evaluation test:

CCN-MECHANISM/KeyDerivation Inputs

In the case of CL2 evaluations, operate the TOE (using I2) to verify
that the key derivation cryptographic constructions implemented I1
by the TOE match with those declared by the vendor in I1.
I2
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above- I6
mentioned.

2.3.1.1.2.8 Password Protection/Hashing Mechanisms

60. In case the TOE implements approved password protection/hashing
constructions to protect/hash cryptographic keys:
• The TOE shall:
- Include a self-test KAT for each password protection/hashing
construction implemented in the TOE, even if they are not in use.
- Include the self-test KATs for the underlying mechanisms:
 For password protection/hashing constructions relying on Hash
primitives, see section 2.3.1.1.1.3 “Hash Functions”.
 For password protection/hashing constructions relying on MAC
constructions, see section 2.3.1.1.2.3 “Integrity Modes: Message
Authentication Code”.
• The tester shall perform the following cryptographic evaluation test:

CCN-MECHANISM/PasswordMechanisms Inputs

In the case of CL2 evaluations, operate the TOE (using I2) to verify
that the password protection/hashing cryptographic
constructions implemented by the TOE match with those declared I1
by the vendor in I1. I2
In the case of CL3 evaluations, operate the TOE (using I2) and I6
perform a source code review (using I6) to verify the above-
mentioned.

Centro Criptológico Nacional 28

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

2.3.1.1.3 Asymmetric Elementary Primitives

2.3.1.1.3.1 RSA/Integer Factorization

61. In case the TOE implements approved cryptographic primitives based on the
integer factorization problem (RSA):
• The tester shall perform the following cryptographic evaluation test:

CCN-MECHANISM/RSA Inputs

In the case of CL2 evaluations, operate the TOE (using I2) to verify
that the RSA cryptographic primitives implemented by the TOE I1
match with those declared by the vendor in I1.
I2
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above- I6
mentioned.

2.3.1.1.3.2 Multiplicative Discrete Logarithm Problem

62. In case the TOE implements approved cryptographic primitives based on the
multiplicative discrete logarithm problem (FFDLOG):
• The tester shall perform the following cryptographic evaluation test:

CCN-MECHANISM/FFDLOG Inputs

In the case of CL2 evaluations, operate the TOE (using I2) to verify
that the FFDLOG cryptographic primitives implemented by the I1
TOE match with those declared by the vendor in I1.
I2
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above- I6
mentioned.

2.3.1.1.3.3 Additive Discrete Logarithm Problem

63. In case the TOE implements approved cryptographic primitives based on the
additive discrete logarithm problem (ECDLOG):
• The tester shall perform the following cryptographic evaluation test:

CCN-MECHANISM/ECDLOG Inputs

I1
In the case of CL2 evaluations, operate the TOE (using I2) to verify
that the ECDLOG cryptographic primitives implemented by the I2
TOE match with those declared by the vendor in I1. I6

Centro Criptológico Nacional 29

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-MECHANISM/ECDLOG Inputs
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned.

2.3.1.1.4 Asymmetric Constructions

2.3.1.1.4.1 Asymmetric Encryption Schemes

64. In case the TOE implements asymmetric encryption constructions to provide
data confidentiality based on approved RSA schemes:
• The TOE shall:
- Include a self-test KAT (with correct and incorrect operations) for each
RSA encryption scheme and modulus length implemented in the TOE,
even if they are not in use.
- Include the self-test KATs for the underlying mechanisms:
 For RSA encryption schemes relying on Hash primitives, see
section 2.3.1.1.1.3 “Hash Functions”.
• The tester shall perform the following cryptographic evaluation test:

CCN-MECHANISM/AsymEncryption Inputs

In the case of CL2 evaluations, operate the TOE (using I2) to verify
that the asymmetric encryption cryptographic constructions
implemented by the TOE match with those declared by the I1
vendor in I1. I2
In the case of CL3 evaluations, operate the TOE (using I2) and I6
perform a source code review (using I6) to verify the above-
mentioned.

2.3.1.1.4.2 Digital Signature

65. In case the TOE implements digital signature constructions to provide data
authentication based on approved asymmetric primitives:
• The TOE shall:
- Include a self-test KAT for each digital signature construction
implemented in the TOE:
 For digital signature constructions based on the RSA asymmetric
primitive, a self-test KAT for each RSA scheme and each modulus
length implemented in the TOE, even if they are not in use.

Centro Criptológico Nacional 30

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

 For digital signature constructions based on the FFDLOG

asymmetric primitive, a self-test KAT for each finite field group
implemented in the TOE, even if they are not in use.
 For digital signature constructions based on the ECDLOG
asymmetric primitive, a self-test KAT for each elliptic curve
implemented in the TOE, even if they are not in use.
- Include a self-test KAT for each operation (generation and verification)
implemented in the TOE, even if they are not in use. For the verification
operation, include correct and incorrect signature values.
- Include the self-test KATs for the underlying mechanisms:
 For digital signature constructions relying on Hash primitives, see
section 2.3.1.1.1.3 “Hash Functions”.
 For digital signature constructions relying on XOF primitives, see
section 2.3.1.1.1.5 “Extendable-Output Functions (XOF)”.
• The tester shall perform the following cryptographic evaluation test:

CCN-MECHANISM/DigitalSignature Inputs

In the case of CL2 evaluations, operate the TOE (using I2) to verify
that the digital signature cryptographic constructions
implemented by the TOE match with those declared by the I1
vendor in I1. I2
In the case of CL3 evaluations, operate the TOE (using I2) and I6
perform a source code review (using I6) to verify the above-
mentioned.

2.3.1.1.4.3 Key Establishment

66. In case the TOE implements key establishment constructions to perform key
agreements based on approved asymmetric primitives:
• The TOE shall:
- Include a self-test KAT for each key establishment construction
implemented in the TOE:
 For key establishment constructions based on the FFDLOG
asymmetric primitive, a self-test KAT for each finite field group
implemented in the TOE, even if they are not in use.
 For key establishment constructions based on the ECDLOG
asymmetric primitive, a self-test KAT for each elliptic curve
implemented in the TOE, even if they are not in use.
- Include the self-test KATs for the underlying mechanisms:

Centro Criptológico Nacional 31

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

 For key establishment constructions relying on key derivation

functions, see section 2.3.1.1.2.7 “Key Derivation Function (KDF)”.
• The tester shall perform the following cryptographic evaluation test:

CCN-MECHANISM/KeyEstablishment Inputs

In the case of CL2 evaluations, operate the TOE (using I2) to verify
that the key establishment cryptographic constructions
implemented by the TOE match with those declared by the I1
vendor in I1. I2
In the case of CL3 evaluations, operate the TOE (using I2) and I6
perform a source code review (using I6) to verify the above-
mentioned.

2.3.1.1.5 Random Number Generators

2.3.1.1.5.1 True Random Number Generators

67. In case the TOE implements approved true random number generators (TRNGs):
• The tester shall perform the following cryptographic evaluation test:

CCN-MECHANISM/TRNG Inputs

In the case of CL2 evaluations, operate the TOE (using I2) to verify
that the true random number generators (TRNGs) implemented I1
by the TOE match with those declared by the vendor in I1.
I2
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above- I6
mentioned.

2.3.1.1.5.2 Deterministic Random Number Generator Constructions

68. In case the TOE implements approved deterministic random number generator
constructions to generate random data sequences:
• The TOE shall:
- Include a self-test KAT for each DRNG construction implemented in the
TOE, even if they are not in use, that executes all DRNG functions
(instantiate, generated, and reseed).
- Include the self-test KATs for the underlying mechanisms:
 For DRNG constructions relying on MAC constructions, see
section 2.3.1.1.2.3 “Integrity Modes: Message Authentication
Code”.

Centro Criptológico Nacional 32

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

 For DRNG constructions relying on Hash primitives, see section

2.3.1.1.1.3 “Hash Functions”.
 For DRNG constructions relying on AES constructions, see section
2.3.1.1.2.1 “Symmetric Encryption (Confidentiality Only)”.
• The tester shall perform the following cryptographic evaluation test:

CCN-MECHANISM/DRNG Inputs

In the case of CL2 evaluations, operate the TOE (using I2) to verify
that the DRNG cryptographic constructions implemented by the I1
TOE match with those declared by the vendor in I1.
I2
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above- I6
mentioned.

2.3.1.2 SENSITIVE SECURITY PARAMETER MANAGEMENT

69. This second topic defines the cryptographic evaluation tests to verify the correct
implementation by the TOE of the SSP management process declared by the
vendor in I1, in order to fulfill the CCN-SSP evaluation task.
70. The SSP management process encompasses the entire lifecycle of SSPs managed
by the TOE, taking into account their secure generation, establishment,
entry/output, storage, transport, usage, and zeroization.
71. The following table summarizes the list of CSPs related to each cryptographic
mechanism detailed in the “Sensitive Data” subsections of the [SOGIS-HEP]
document.

Cryptographic Cryptographic Critical Security Parameter (CSP)

Mechanism Mode/Scheme Description

Stream Cipher
ChaCha20 Encryption or Decryption Key
Primitive

Secret Sharing Shared secret obtained using Shamir’s

Shamir
Primitive Scheme

AES-CBC
Symmetric
AES-CBC-CS
Encryption
Encryption or Decryption Key
(Confidentiality
AES-CFB
Only) Construction
AES-CTR

Centro Criptológico Nacional 33

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Cryptographic Critical Security Parameter (CSP)

Mechanism Mode/Scheme Description

AES-OFB

Disk Encryption
AES-XTS Encryption or Decryption Key
Construction

AES-CMAC

AES-CBC-MAC

HMAC
Authentication Key used by the MAC
MAC Construction
cryptographic construction
AES-GMAC

KMAC

Poly1305

Encryption or Decryption Key used by

Encrypt-then- the symmetric encryption construction
MAC and Authentication Key used by the
MAC cryptographic construction

CCM
Authenticated
Authenticated Encryption or Decryption
Encryption GCM
Key
Construction
EAX

Encryption or Decryption Key used by

ChaCha20- the ChaCha20 stream cipher primitive
Poly1305 and Authentication Key used by the
Poly1305 cryptographic construction

SIV
Key Protection
Key Encryption or Decryption Key
Construction
AES-Keywrap

NIST SP800-56
A/B/C

Key Derivation NIST SP800-108 Input Secret to generate the new

Construction derived key
ANSI X9.63 KDF

PBKDF2

Centro Criptológico Nacional 34

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Cryptographic Critical Security Parameter (CSP)

Mechanism Mode/Scheme Description

HKDF

Argon2id
Password
Input Secret to perform password
Protection/Hashing PBKDF2
protection/hashing operations
Construction
SCRYPT

RSA OAEP
Asymmetric The private component of RSA key pairs
Encryption Scheme in asymmetric decryption operations
RSA PKCS#1v1.5

RSA PSS The private component of RSA key pairs

in digital signature generation
RSA PKCS#1v1.5 operations

KCDSA
The private component of FFDLOG key
Schnorr pairs in digital signature generation
operations
DSA

EC-KCDSA

EC-DSA
Digital Signature
The private component of ECDLOG key
Construction
EC-GDSA pairs in digital signature generation
operations
EC-Schnorr

EdDSA

XMSS

ML-DSA
The private component of key pairs in
digital signature generation operations
Falcon

SLH-DSA

DH Shared Secret obtained as a result of

Key Establishment the key establishment procedure
EC-DH
Scheme The private component of key pairs in
DLIES-KEM secret-sharing computation operations

Centro Criptológico Nacional 35

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Cryptographic Critical Security Parameter (CSP)

Mechanism Mode/Scheme Description

ECIES-KEM

ML-KEM Shared Secret obtained as a result of

the key encapsulation and
decapsulation mechanisms

FrodoKEM The private component of key pairs

(the decapsulation key) in key
encapsulation computation operations

HMAC-DRBG Seed used to initialize or re-seed the

Deterministic
Random Number DRNG
Hash-DRBG
Generator The internal state of DRNG generated
Construction in each generation operation
CTR-DRBG (AES)

Table 3. CSP Definition for each Cryptographic Mechanism

72. The following table summarizes the list of PSPs related to each cryptographic
mechanism detailed in the “Sensitive Data” subsections of the [SOGIS-HEP]
document.

Cryptographic Cryptographic Public Security Parameter (PSP)

Mechanism Mode/Scheme Description

RSA OAEP
Asymmetric The public component of RSA key pairs
Encryption Scheme in asymmetric encryption operations
RSA PKCS#1v1.5

RSA PSS The public component of RSA key pairs

in digital signature verification
RSA PKCS#1v1.5 operations

KCDSA
The public component of FFDLOG key
Schnorr pairs in digital signature verification
operations
Digital Signature
DSA
Construction
EC-KCDSA

EC-DSA The public component of ECDLOG key

pairs in digital signature verification
EC-GDSA operations

EC-Schnorr

Centro Criptológico Nacional 36

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Cryptographic Public Security Parameter (PSP)

Mechanism Mode/Scheme Description

EdDSA

XMSS

ML-DSA
The public component of key pairs in
digital signature verification operations
Falcon

SLH-DSA

The public component of FFDLOG key

DH pairs in secret-sharing computation
operations

The public component of ECDLOG key

EC-DH pairs in secret sharing computation
operations

The public component of FFDLOG key

Key Establishment
DLIES-KEM pairs in secret-sharing computation
Scheme
operations

The public component of ECDLOG key

ECIES-KEM pairs in secret sharing computation
operations

ML-KEM The public component of key pairs (the

encapsulation key) in key decapsulation
FrodoKEM computation operations

Table 4. PSP Definition for each Cryptographic Mechanism

2.3.1.2.1 Sensitive Security Parameter Generation and Establishment

73. In case the TOE implements sensitive security parameter generation:
• The TOE shall:
- Implement one of the following approved cryptographic mechanisms to
perform SSP generation:
 An approved random number generator, according to the
following configurations:
o For symmetric mechanisms, an approved DRNG (see
section 3.3.1.1.5.2 “Deterministic Random Number
Generators”).

Centro Criptológico Nacional 37

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

o For asymmetric keys based on RSA, an approved RSA key

pair generation scheme (see section 3.3.1.1.3.1
“RSA/Integer Factorization”).
o For asymmetric private keys based on FFDLOG, an
approved random uniform modular distribution (see
section 3.3.1.1.3.2 “Multiplicative Discrete Logarithm
Problem”).
o For asymmetric private keys based on ECDLOG, an
approved random uniform modular distribution (see
3.3.1.1.3.3 “Additive Discrete Logarithm Problem”).
 An approved key establishment construction (see section
3.3.1.1.4.3 “Key Establishment”). In this case:
o Implement an approved key derivation function
establishment as a postprocessing method (see section
3.3.1.1.2.7 “Key Derivation Functions”).
o For any key establishment construction that relies on pre-
existing secrets (e.g., ephemeral components in Diffie-
Hellman or master secret in TLS Record Protocol), employ
at least 125 bits of entropy for the generation of pre-
existing secrets.
 An approved key derivation function (see section 3.3.1.1.2.7 “Key
Derivation Functions”).
• The tester shall perform the following cryptographic evaluation test:

CCN-SSP/Generation Inputs

In the case of CL2 evaluations, verify in I1 that the SSP generation

methods declared by the vendor are one of the following
approved cryptographic mechanisms:
 An approved random number generator, in this case, verify
that it complies with the following configurations:
- For symmetric mechanisms, an approved DRNG.
I1
- For asymmetric keys based on RSA, an approved RSA
I2
key pair generation scheme.
I6
- For asymmetric private keys based on FFDLOG, an
approved random uniform modular distribution.
- For asymmetric private keys based on ECDLOG, an
approved random uniform modular distribution.
 An approved key establishment construction, in this case,
verify that:

Centro Criptológico Nacional 38

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-SSP/Generation Inputs
- The key establishment construction declared by the
vendor uses an approved key derivation function as
a postprocessing method.
- The generation of any pre-existing secret in SSP
establishment is performed using at least 125 bits of
entropy.
 An approved key derivation function.
In addition, operate the TOE (using I2) to verify that:
- The SSP generation methods implemented by the TOE
match with those declared by the vendor in I1.
In the case of CL3 evaluations, use I1, operate the TOE (using I2),
and perform a source code review (using I6) to verify the above-
mentioned.

2.3.1.2.2 Sensitive Security Parameter Entry/Output

74. In case the TOE implements sensitive security parameter entry/output:
• The TOE shall:
- Implement a secure key distribution channel ensuring the authenticity
and integrity of the PSPs using approved cryptographic mechanisms.
- Implement a secure key distribution channel ensuring the authenticity,
integrity, and confidentiality of the CSPs using approved key protection
mechanisms.
• The tester shall perform the following cryptographic evaluation test:

CCN-SSP/Transport Inputs

In the case of CL2 evaluations, verify in I1 that:

- The PSP entry/output is protected in authenticity and
integrity using an approved cryptographic mechanism.
I1
- The CSP entry/output is protected in authenticity,
integrity, and confidentiality using an approved key I2
protection mechanism. I6
In addition, operate the TOE (using I2) to verify that:
- The SSP transport methods implemented by the TOE
match with those declared by the vendor in I1.

Centro Criptológico Nacional 39

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-SSP/Transport Inputs

In the case of CL3 evaluations, use I1, operate the TOE (using I2),
and perform a source code review (using I6) to verify the above-
mentioned.

2.3.1.2.3 Sensitive Security Parameter Storage

75. Regarding the storage of sensitive security parameters:
• The TOE shall:
- Ensure the authenticity and integrity of the stored PSPs to protect them
from unauthorized modifications or substitutions using approved
cryptographic mechanisms.
- Ensure the confidentiality, authenticity, and integrity of the stored CSPs
to protect them from disclosure using approved key protection
mechanisms.
• The tester shall perform the following cryptographic evaluation test:

CCN-SSP/Storage Inputs

In the case of CL2 evaluations, verify in I1 that:

- The PSP storage is protected in authenticity and integrity
using an approved cryptographic mechanism.
- The CSP storage is protected in authenticity, integrity, and
confidentiality using an approved key protection I1
mechanism.
I2
In addition, operate the TOE (using I2) to verify that:
I6
- The SSP storage methods implemented by the TOE match
with those declared by the vendor in I1.
In the case of CL3 evaluations, use I1, operate the TOE (using I2),
and perform a source code review (using I6) to verify the above-
mentioned.

2.3.1.2.4 Sensitive Security Parameter Zeroization

76. Regarding the zeroization of sensitive security parameters, it is necessary to
perform the zeroization of critical security parameters (CSP) stored in volatile
and non-volatile TOE memory, therefore:
• The TOE shall:
- Implement a zeroization mechanism to destroy all stored CSPs
automatically without operator intervention once they are no longer

Centro Criptológico Nacional 40

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

needed, making it impossible to recover them after the zeroization. The

only approved zeroization procedure is to overwrite CSPs with zeros,
ones, or random values. Therefore, overwriting any CSP with another CSP
is not considered a valid zeroization mechanism.
Note: For unprotected CSPs stored in non-volatile memory, the term “zeroize
once they are no longer needed” means “zeroize after the usage of the CSP”.
• The tester shall perform the following cryptographic evaluation test:

CCN-SSP/Zeroization.1 Inputs

In the case of CL2 evaluations, verify that the list of CSPs declared
by the vendor in I1 encompasses all the CSPs related to each
implemented cryptographic mechanism as detailed in Table 3
“CSP Definition for each Cryptographic Mechanism”.
In addition, operate the TOE (using I2) and review the evidence
provided in I1 to verify that:
I1
- All the CSPs are zeroized using only approved zeroization
mechanisms and without any operator intervention once I2
they are no longer needed. I6
- No CSP is being directly overwritten by another CSP.
- It is not possible to recover any zeroized CSP.
In the case of CL3 evaluations, operate the TOE (using I2), review
the evidence provided in I1, and perform a source code review
(using I6) to verify the above-mentioned.

77. Moreover, it is necessary to perform the zeroization of the temporally sensitive

data (temporally stored CSPs, key components, and ephemeral CSPs) used in the
operation of the different implemented cryptographic mechanisms once they
are no longer needed, therefore:
• The TOE shall:
- In the case of CL2 evaluations, overwrite sensitive data with new data or
use an approved zeroization procedure to overwrite them with zeros,
ones, or random values.
- In the case of CL3 evaluations, zeroize sensitive data using an approved
zeroization procedure to overwrite temporally sensitive data with zeros,
ones, or random values. Moreover, sensitive data shall not be stored
even partially, in volatile or non-volatile memory.
78. Temporally sensitive data are those obtained from the execution of a
cryptographic mechanism, as detailed in the “Sensitive Data” subsections in the
[SOGIS-HEP] document, except the CSPs listed in Table 3 “CSP Definition for each

Centro Criptológico Nacional 41

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Mechanism”. The following table summarizes the list of

temporally sensitive data related to each cryptographic mechanism:
Cryptographic Cryptographic
Temporally Sensitive Data for CL2 and CL3
Mechanism Mode/ Scheme
- Each round key in the AES algorithm
execution
- Erroneous ciphertexts
Block Cipher - Plaintext on the encryption side
AES
Primitive - Temporally variables such as the state and
counter of each round
- Initialization vectors on the encryption side
- Counters on the encryption side
- Internal states of each round
- The output of each round
- Plaintext
- Nonce
Stream Cipher
ChaCha20 - Erroneous ciphertexts
Primitive
- During the encryption, the inputs of the
XOR operation
- During the decryption, the input and the
output of the XOR operation

SHA-2 Family - The input of the hash function

Hash Primitive SHA-3 Family - Internal states during the execution
because they could be used to derive the
BLAKE2b input or the output of the function
Secret Sharing Each of the parts (specific to each user) that
Shamir
Primitive are needed to generate the shared secret
- The input of the XOF
SHAKE - Internal states during the execution
XOF
cSHAKE because they could be used to derive the
input or the output of the function
Sensitive data related to the AES block
cipher primitive shall be zeroized
Symmetric AES-CBC
No additional sensitive data related to this
Encryption scheme
(Confidentiality
Only) Sensitive data related to the AES block
Construction cipher primitive shall be zeroized
AES-CBC-CS
No additional sensitive data related to this
scheme

Centro Criptológico Nacional 42

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Cryptographic
Temporally Sensitive Data for CL2 and CL3
Mechanism Mode/ Scheme
Sensitive data related to the AES block
cipher primitive shall be zeroized
Additional sensitive data related to this
scheme:
- Considering that CFB is a stream mode,
AES-CFB each output of the block cipher is sensitive
data because it allows to derive the plaintext
- During the encryption, the inputs of the
XOR operation
- During the decryption, one input (the key
stream) and the output of the XOR operation
Sensitive data related to the AES block
cipher primitive shall be zeroized
Additional sensitive data related to this
scheme:
- Considering that CTR is a stream mode,
AES-CTR each output of the block cipher is sensitive
data because it allows to derive the plaintext
- During the encryption, the inputs of the
XOR operation
- During the decryption, one input (the key
stream) and the output of the XOR operation
Sensitive data related to the AES block
cipher primitive shall be zeroized
Additional sensitive data related to this
scheme:
- Considering that OFB is a stream mode,
AES-OFB each output of the block cipher is sensitive
data because it allows to derive the plaintext
- During the encryption, the inputs of the
XOR operation
- During the decryption, one input (the key
stream) and the output of the XOR operation
Sensitive data related to the AES block
cipher primitive shall be zeroized
Disk Encryption
AES-XTS Additional sensitive data related to this
Construction
scheme:
- Encrypted tweak values

Centro Criptológico Nacional 43

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Cryptographic
Temporally Sensitive Data for CL2 and CL3
Mechanism Mode/ Scheme
Sensitive data related to the AES block
cipher primitive shall be zeroized
Additional sensitive data related to this
scheme:
- The input message and the generated MAC
- Key k0 derived from the initial key by
AES-CMAC encrypting a constant message with the
initial key
- Keys k1 and k2 derived from k0 using shift
and XOR operations that are used to
generate the MAC with intermediate values
- The input and output of shifts and XOR
operations
Sensitive data related to the AES block
cipher primitive shall be zeroized
AES-CBC-MAC Additional sensitive data related to this
scheme:
- The input message and the generated MAC
Sensitive data related to the hash primitive
MAC shall be zeroized
Construction Additional sensitive data related to this
HMAC scheme:
- The input message and the generated MAC
- Results of the XOR operations internally
performed
Sensitive data related to the AES block
cipher primitive shall be zeroized
Additional sensitive data related to this
AES-GMAC scheme:
- The input message and the generated MAC
- The secret H derived using the
authentication key computed as Ek(0128)
Sensitive data related to the cSHAKE
primitive shall be zeroized
Additional sensitive data related to this
KMAC scheme:
- The input message and the generated MAC
- Internal states during the execution
Poly1305 - The input message and the generated MAC

Centro Criptológico Nacional 44

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Cryptographic
Temporally Sensitive Data for CL2 and CL3
Mechanism Mode/ Scheme
Sensitive data related to the underlying AES
block cipher primitive and the underlying
Encrypt-then- MAC cryptographic construction shall be
MAC zeroized
No additional sensitive data related to this
scheme
Sensitive data related to the AES CTR and
the CBC-MAC cryptographic constructions
AES-CCM shall be zeroized
No additional sensitive data related to this
scheme
Sensitive data related to the AES block
cipher primitive shall be zeroized
Additional sensitive data related to this
scheme:
Authenticated - The secret H derived using the
Encryption authentication key computed as Ek(0128)
AES-GCM
Construction - The output of the block cipher because it
allows to derive the plaintext
- During the encryption, the inputs of the
XOR operation
- During the decryption, one input (the key
stream) and the output of the XOR operation
Sensitive data related to the AES CTR and
the CMAC cryptographic constructions shall
AES-EAX be zeroized
No additional sensitive data related to this
scheme
Sensitive data related to the ChaCha20
stream primitive and Poly1305 construction
ChaCha20- shall be zeroized
Poly1305
No additional sensitive data related to this
scheme
Sensitive data related to the AES CTR and
the CMAC cryptographic constructions shall
Key Protection be zeroized
AES-SIV
Construction
No additional sensitive data related to this
scheme

Centro Criptológico Nacional 45

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Cryptographic
Temporally Sensitive Data for CL2 and CL3
Mechanism Mode/ Scheme
Sensitive data related to the AES block
cipher primitive shall be zeroized
AES-Keywrap
No additional sensitive data related to this
scheme
If relies on a hash function, sensitive data
related to the hash primitive shall be
zeroized
If relies on an HMAC function, sensitive data
related to the HMAC construction shall be
NIST SP800-56 zeroized
A/B/C OneStep
If relies on a KMAC function, sensitive data
related to the KMAC construction shall be
zeroized
No additional sensitive data related to this
scheme
If relies on an HMAC function, sensitive data
related to the HMAC construction shall be
zeroized
If relies on a CMAC function, sensitive data
related to the CMAC construction shall be
NIST SP800-56 zeroized
A/B/C TwoStep
Key Derivation Sensitive data related to the NIST SP800-108
Construction KDF cryptographic construction shall be
zeroized
No additional sensitive data related to this
scheme
If relies on an HMAC function, sensitive data
related to the HMAC construction shall be
zeroized
If relies on a CMAC function, sensitive data
related to the CMAC construction shall be
zeroized
If relies on a KMAC function, sensitive data
NIST SP800-108 related to the KMAC construction shall be
zeroized
Additional sensitive data related to this
scheme:
- The temporary KDKs used to derivate the
final key
- The intermediate results of the iterations

Centro Criptológico Nacional 46

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Cryptographic
Temporally Sensitive Data for CL2 and CL3
Mechanism Mode/ Scheme
If relies on a hash function, sensitive data
related to the hash primitive shall be
ANSI X9.63 KDF zeroized
No additional sensitive data related to this
scheme
Sensitive data related to the HMAC
PBKDF2 construction shall be zeroized

Sensitive data related to the HMAC

construction shall be zeroized
Additional sensitive data related to this
HKDF
scheme:
- The pseudo-random key computed in the
“extract” phase
Sensitive data related to the BLAKE2b
primitive shall be zeroized
Additional sensitive data related to this
Argon2id
scheme:
- The derived password when used for
password verification
Sensitive data related to the HMAC
construction shall be zeroized
Password
Additional sensitive data related to this
Protection/ PBKDF2
scheme:
Hashing
Mechanisms - The derived password when used for
password verification
Sensitive data related to the PBKDF2
construction shall be zeroized
Additional sensitive data related to this
SCRYPT scheme:
- All the blocks obtained through PBKDF2
outputs, as well as intermediate states in the
computations that involve those blocks
- The result of the exponentiation
- Temporary variables within the
Asymmetric exponentiation
RSA
Primitive - When using the CRT mode, the modulus,
and possible erroneous outputs
- Other erroneous outputs

Centro Criptológico Nacional 47

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Cryptographic
Temporally Sensitive Data for CL2 and CL3
Mechanism Mode/ Scheme
- The temporary variables within the
exponentiation
- The output in exponentiations using
unintended subgroups
- Erroneous computed results during
modular exponentiations
- Other erroneous outputs
FFDLOG
In addition, depending on the mechanism
used to perform simple or multi-
exponentiation, the following parameter
may be considered sensitive data:
- The base(s)
- The exponent(s)
- The result
- The temporary variables within the
multiplication
- The output in multiplications using
unintended curves or corrupted parameters
- Erroneous computed results during EC
scalar multiplications
- Other erroneous outputs
ECDLOG
In addition, depending on the mechanism
used to perform the simple or EC multi-
scalar multiplication, the following
parameter may be considered sensitive data:
- The base(s)
- The scalar(s)
- The resulting point
Sensitive data related to the RSA asymmetric
primitive and SHA hash primitive shall be
zeroized
Additional sensitive data related to this
scheme:
Asymmetric - The plaintext to be encrypted in the
Encryption RSA-OAEP encryption operation
Scheme
- The ciphertext (encoded plaintext) in the
case of decryption operations
- Output of the hash function employed
- Intermediate values for OAEP encoding and
decoding operations

Centro Criptológico Nacional 48

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Cryptographic
Temporally Sensitive Data for CL2 and CL3
Mechanism Mode/ Scheme
Sensitive data related to the RSA asymmetric
primitive shall be zeroized
Additional sensitive data related to this
scheme:
RSA-PKCS#1v1.5
- The plaintext to be encrypted in the
encryption operation
- The ciphertext (encoded plaintext) in the
case of decryption operations
Sensitive data related to the RSA asymmetric
primitive and SHA hash primitive shall be
zeroized
Additional sensitive data related to this
RSA-PSS scheme:
RSA-PKCS#1v1.5 - The message to be signed is generally
considered public data, however, in some
situations it needs to be kept secret. In that
case, it is a sensitive parameter as well as its
digest and the signature
Sensitive data related to the FFDLOG
asymmetric primitive and SHA hash primitive
shall be zeroized
Additional sensitive data related to this
Digital scheme:
Signature - The message to be signed is generally
Construction considered public data, however, in some
situations it needs to be kept secret. In that
case, it is a sensitive parameter as well as its
DSA digest and the signature
KCDSA - If the message and/or signature are
considered sensitive, then all the
Schnorr intermediary results for signature generation
and verification are considered sensitive
- During the signature generation, the
random per-message value (k) is considered
sensitive data because it is the exponent
used in the modular exponentiation
- All the intermediary results for the
computation of the signature(s) where the
private key and the per-message value are
involved

Centro Criptológico Nacional 49

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Cryptographic
Temporally Sensitive Data for CL2 and CL3
Mechanism Mode/ Scheme
Sensitive data related to the ECDLOG
asymmetric primitive and SHA hash primitive
shall be zeroized (if applicable)
Additional sensitive data related to this
scheme:
- The message to be signed is generally
considered public data, however, in some
situations it needs to be kept secret. In that
case, it is a sensitive parameter as well as its
EC-DSA digest and the signature
EC-KCDSA - If the message and/or signature are
EC-GDSA considered sensitive, then all the
EC-Schnorr intermediary results for signature generation
and verification are considered sensitive
- During the signature generation, the
random per-message value (k) is considered
sensitive data because it is a scalar in EC
scalar multiplication
- All the intermediary results for the
computation of the signature(s) where the
private key and the per-message value are
involved
Sensitive data related to the ECDLOG
asymmetric primitive, SHA hash primitive,
and XOF primitive shall be zeroized (if
applicable)
Additional sensitive data related to this
scheme:
- The message to be signed is generally
considered public data, however, in some
situations it needs to be kept secret. In that
case, it is a sensitive parameter as well as its
EdDSA digest and the signature
- If the message and/or signature are
considered sensitive, then all the
intermediary results for signature generation
and verification are considered sensitive
- All the intermediary value that uses the
output of the private key hash
- All the intermediary results for the
computation of the signature(s) where the
private key and the per-message value are
involved

Centro Criptológico Nacional 50

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Cryptographic
Temporally Sensitive Data for CL2 and CL3
Mechanism Mode/ Scheme
Sensitive data related to the SHA hash and
XOF primitives shall be zeroized
Additional sensitive data related to this
scheme:
- The message to be signed is generally
considered public data, however, in some
situations it needs to be kept secret. In that
case, it is a sensitive parameter as well as its
digest and the signature
- If the message and/or signature are
considered sensitive, then all the
XMSS
intermediary results for signature generation
and verification are considered sensitive
- All the intermediary results for the
computation of the signature(s) where the
private key and the per-message value are
involved
- All the intermediate result values in the
WOTS+ algorithm (such as the message in
base w or the checksum)
- All sensitive parameters of the pseudo-
random function
Sensitive data related to the underlying
mechanisms shall be zeroized
Additional sensitive data related to this
scheme:
- The message to be signed is generally
considered public data, however, in some
situations it needs to be kept secret. In that
ML-DSA case, it is a sensitive parameter as well as its
digest and the signature
Falcon
- If the message and/or signature are
considered sensitive, then all the
intermediary results for signature generation
and verification are considered sensitive
- All the intermediary results for the
computation of the signature(s) where the
private key and the per-message value are
involved
Sensitive data related to the underlying
mechanisms shall be zeroized
SLH-DSA
Additional sensitive data related to this
scheme:

Centro Criptológico Nacional 51

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Cryptographic
Temporally Sensitive Data for CL2 and CL3
Mechanism Mode/ Scheme
- The message to be signed is generally
considered public data, however, in some
situations it needs to be kept secret. In that
case, it is a sensitive parameter as well as its
digest and the signature
- If the message and/or signature are
considered sensitive, then all the
intermediary results for signature generation
and verification are considered sensitive
- All the intermediary results for the
computation of the signature(s) where the
private key and the per-message value are
involved
- The hypertree node keys and the WOTS+
private keys
Sensitive data related to the FFDLOG
asymmetric primitive and the KDF
construction shall be zeroized
Additional sensitive data related to this
DH
scheme:
- The random secret values used as the
exponent in DH to produce the shared secret
and all the data derived from the base secret
Sensitive data related to the ECDLOG
asymmetric primitive and the KDF
construction shall be zeroized
Additional sensitive data related to this
EC-DH
scheme:
Key
Establishment - The random secret values used as the
Scheme scalar in ECDH to produce the shared secret
and all the data derived from the base secret
Sensitive data related to the FFDLOG
asymmetric primitive and the KDF
construction shall be zeroized
Additional sensitive data related to this
scheme:
DLIES-KEM - The random secret values used as the
exponent in the DLIES-KEM key generation
operation to produce the shared secret
- The random secret value applied to the
other party’s public key as the exponent in
the DLIES-KEM encapsulation operation to
produce the shared secret is considered

Centro Criptológico Nacional 52

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Cryptographic
Temporally Sensitive Data for CL2 and CL3
Mechanism Mode/ Scheme
sensitive data. Moreover, the data derived
during the operation is considered sensitive
data
Sensitive data related to the ECDLOG
asymmetric primitive and the KDF
construction shall be zeroized
Additional sensitive data related to this
scheme:
- The random secret values used as the
scalar in the ECIES-KEM key generation
ECIES-KEM operation to produce the shared secret
- The random secret value applied to the
other party’s public key as the scalar in the
ECIES-KEM encapsulation operation to
produce the shared secret is considered
sensitive data. Moreover, the data derived
during the operation is considered sensitive
data
Sensitive data related to the underlying
mechanisms shall be zeroized
ML-KEM
No additional sensitive data related to this
scheme
Sensitive data related to the underlying
mechanisms shall be zeroized
FrodoKEM
No additional sensitive data related to this
scheme
Sensitive data related to the HMAC
construction shall be zeroized
Additional sensitive data related to this
scheme:
HMAC-DRBG
- The random bit output by the DRNG
mechanism is often considered sensitive
Deterministic data because they are usually used to
Random generate secret keys
Number
Generator Sensitive data related to the hash function
Construction shall be zeroized
Additional sensitive data related to this
scheme:
Hash-DRBG
- The random bit output by the DRNG
mechanism is often considered sensitive
data because they are usually used to
generate secret keys

Centro Criptológico Nacional 53

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Cryptographic
Temporally Sensitive Data for CL2 and CL3
Mechanism Mode/ Scheme
Sensitive data related to the AES block cipher
primitive and AES-CTR construction shall be
zeroized
Additional sensitive data related to this
CTR-DRBG scheme:
- The random bit output by the DRNG
mechanism is often considered sensitive
data because they are usually used to
generate secret keys

Table 5. Temporally Sensitive Data for each Cryptographic Mechanism

• The tester shall perform the following cryptographic evaluation test:

CCN-SSP/Zeroization.2 Inputs

In the case of CL2 and CL3 evaluations, verify that the list of
temporally sensitive data declared by the vendor in I1
encompasses all the temporally sensitive data related to each
implemented cryptographic mechanism as detailed in Table 5
“Temporally Sensitive Data for each Cryptographic Mechanism”.
In the case of CL2 evaluations, operate the TOE (using I2) and
review the evidence provided in I1 to verify that:
- All temporally sensitive data are overwritten with new
data or zeroized using only approved zeroization
I1
mechanisms and without any operator intervention once
they are no longer needed. I2
- It is not possible to recover any zeroized temporally I6
sensitive data.
In the case of CL3 evaluations, operate the TOE (using I2), review
the evidence provided in I1, and perform a source code review
(using I6) to verify that:
- All temporally sensitive data are zeroized using only
approved zeroization mechanisms and without any
operator intervention once they are no longer needed.
- It is not possible to recover any zeroized temporally
sensitive data.

Centro Criptológico Nacional 54

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

2.3.1.3 CRYPTOGRAPHIC MECHANISMS SELF-TEST

79. This third topic defines the cryptographic evaluation test to verify the correct
implementation by the TOE of the cryptographic mechanisms self-tests declared
by the vendor in I1, in order to fulfill the CCN-SELFTEST evaluation task.
80. The cryptographic mechanisms self-tests are diagnostic procedures used to
verify the correct operativity of the implemented cryptographic mechanisms.
81. Regarding the implementation of the cryptographic mechanisms self-tests:
• The TOE shall implement and execute the self-tests associated with the
implemented cryptographic mechanisms. These are defined throughout section
2.3.1.1 “Cryptographic Mechanisms Implementation”.
• The vendor shall provide the self-test input vectors associated with the
implemented cryptographic mechanisms (I7) to allow the tester to perform the
self-test validation process using the CCN Cryptographic Tool.
• The tester shall perform the following cryptographic evaluation test:

CCN-SELFTEST/Implementation Inputs

In the case of CL2 evaluations, operate the TOE (using I2), use the
self-test input vectors (I7), and review the evidence provided in I1
to verify that:
- The parameterization used in the self-test KATs complies
with the requirements defined in Section 3 “CCN Agreed
Cryptographic Mechanisms”.
I1
- The self-test KATs implemented for each cryptographic
mechanism are valid. For this purpose, the CCN I2
Cryptographic Tool shall be used as the cryptographic I6
reference implementation.
I7
- The TOE correctly implements and executes all the
cryptographic mechanisms self-tests.
In the case of CL3 evaluations, operate the TOE (using I2), use the
self-test input vectors (I7), review the evidence provided in I1, and
perform a source code review (using I6) to verify the above-
mentioned.

2.3.1.4 MITIGATION OF OTHER ATTACKS

82. This fourth topic defines the cryptographic evaluation test to verify the
implementation by the TOE of countermeasures to mitigate other attacks
declared by the vendor in I1, in order to fulfill the CCN-MITIGATION evaluation
task.

Centro Criptológico Nacional 55

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

83. Nowadays, products can be attacked without requiring the attacker to modify or
access them. These attacks are known as side-channel attacks and they target
the leakage of secret information through unintended channels in the
implementation of a mechanism. These channels are related to physical effects
such as power consumption, timing characteristics, and electromagnetic
radiation.
84. This kind of attack can change the behavior of an integrated circuit (IC) in order
to modify its normal operation by causing an exploitable error. This modification
can occur by causing the IC to operate outside voltage, temperature, and clock
frequency ranges or by applying more than one external power source during IC
operation.
• Therefore, to protect the critical security parameters against side-channel
attacks and differential fault analysis (DFA), the TOE shall implement
countermeasures to mitigate these attacks.
• The tester shall perform the following cryptographic evaluation test:

CCN-MITIGATION/Mitigation Inputs

In the case of CL2 evaluations, review the evidence provided in I1

to verify that the TOE implements countermeasures to mitigate
side-channel attacks and differential fault analysis (DFA). I1
In the case of CL3 evaluations, review the evidence provided in I1 I2
and perform a source code review (using I6) to verify the above- I6
mentioned. Moreover, these countermeasures shall be tested
according to the lab experience.

Centro Criptológico Nacional 56

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

3 CCN AGREED CRYPTOGRAPHIC MECHANISMS

3.1 OBJECTIVE
85. This chapter defines the cryptographic mechanisms and protocols that are
considered as agreed upon by CCN according to the [CCN-STIC-221] guidance.
86. Therefore, it provides vendors with recommendations and additional
considerations that shall be met by the TOE to perform a secure implementation
of the cryptographic mechanisms and protocols. In addition, it provides testers
with the evaluation tasks necessary to verify the correct compliance with the
requirements during the cryptographic mechanisms’ evaluation process.

3.2 DEFINITIONS
Cryptographic Mechanisms
87. Agreed cryptographic mechanisms are subdivided into two categories, according
to their estimated robustness. For each category of agreed mechanisms, the
principles governing the management of the terms of their validity are
summarized below.
a) Recommended Mechanisms (R): they fully reflect the current state-of-the-
art in cryptographic security engineering. They currently offer a security level
of at least 128 bits, are supported by strong security mechanisms, and can
provide an adequate level of security against all known and suspected threats,
even taking into account the generally anticipated increases in computing
power. Residual threats to their security may arise from potential innovative
developments.
b) Legacy Mechanisms (L): they are deployed on a large scale, currently offer a
security level of at least 100 bits, and are considered to provide acceptable
security in the short term, but should be phased out as soon as possible
because they no longer fully reflect the state-of-the-art and suffer from some
security assurance limitations compared to the recommended mechanisms.
Consequently, a validity period is defined for legacy mechanisms.
For legacy mechanisms that are expected to become vulnerable shortly, the
validity period is given by a deprecation deadline: the mechanism is no longer
accepted after the given deadline. The notation L[2030] indicates that the
acceptance of the mechanisms expires on December 31, 2030.
For legacy mechanisms that do not suffer from these limitations, the given
validity period should be interpreted as a minimum validity period, during
which the mechanism is expected to remain acceptable. The notation
L[2030+] indicates that the acceptance of the legacy mechanism goes at least
until the end of 2030.

Centro Criptológico Nacional 57

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Primitives and Constructions

88. Cryptographic mechanisms are often built upon more elementary mechanisms,
denoted as cryptographic primitives, to achieve higher-level security goals.
When this is the case, we call them cryptographic constructions.
89. The construction of cryptographic mechanisms from one or more established
cryptographic primitives allows to derive confidence from the prior analysis
of the primitive(s): usually, the security of the cryptographic construction
can be expressed in terms of the security of the underlying primitive(s),
possibly together with some quantifiable and limited loss of assurance.
Note: For a construction to be considered agreed, only agreed primitives shall be
used unless explicitly stated otherwise. Moreover, for a construction that is marked
“recommended” to result in a recommended mechanism, the underlying
primitive(s) shall also be recommended. If it is marked “recommended” but an
underlying primitive is marked “legacy”, the resulting mechanism is considered
“legacy”. It is also noted that specific notes related to a cryptographic primitive also
apply to constructions involving that primitive, even if these notes are not
repeated.

3.3 CRYPTOGRAPHIC EVALUATION TASKS

90. This section contains the cryptographic mechanisms and protocols agreed upon
by CCN that shall be considered by the vendors in the case of implementing a
TOE with cryptographic capabilities.
91. The following cryptographic evaluation tasks related to the cryptographic
mechanisms and protocols agreed upon by CCN have been defined:

CRYPTOGRAPHIC CERTIFICATION
CCN-AGREED
EVALUATION TASK LEVEL

The tester shall verify that all the cryptographic

mechanisms implemented by the TOE are considered as
agreed according to this methodology and comply with the
specific notes.
- For CL1, agreed means legacy or recommended
cryptographic mechanisms. CL1, CL2 and
CL3
- For CL2 and CL3, agreed means only recommended
cryptographic mechanisms.

Note: In the case of CL2 and CL3 evaluations, all

implemented cryptographic mechanisms shall be
verified, even if they are not in use.

Centro Criptológico Nacional 58

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CRYPTOGRAPHIC CERTIFICATION
CCN-PROTOCOL
EVALUATION TASK LEVEL

The tester shall verify that all the cryptographic protocols

implemented by the TOE are considered as agreed
according to this methodology and comply with the specific
notes.
- For CL1, agreed means legacy or recommended
cryptographic protocols and configurations. CL1, CL2 and
CL3
- For CL2 and CL3, agreed means only recommended
cryptographic protocols and configurations.

Note: In the case of CL2 and CL3 evaluations, all

implemented cryptographic protocols shall be verified,
even if they are not in use.

92. For the correct completion of the evaluation tasks, each one of them has been
divided into a set of cryptographic evaluation tests. The tester shall perform the
associated implementation-dependent tests, if applicable, according to the TOE
implementation.

Cryptographic Test
Cryptographic Evaluation Test
Evaluation Task Categorization

CCN-AGREED/BlockCipher Impl-Dep

CCN-AGREED/StreamCipher Impl-Dep

CCN-AGREED/Hash Impl-Dep

CCN-AGREED/SecretSharing Impl-Dep
CCN-AGREED
CCN-AGREED/XOF Impl-Dep
Agreed
Cryptographic CCN-AGREED/SymEncryption Impl-Dep
Mechanisms
CCN-AGREED/DiskEncryption Impl-Dep

CCN-AGREED/MAC Impl-Dep

CCN-AGREED/EntityAuth Impl-Dep

CCN-AGREED/AuthEncryption Impl-Dep

Centro Criptológico Nacional 59

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Test
Cryptographic Evaluation Test
Evaluation Task Categorization

CCN-AGREED/KeyProtection Impl-Dep

CCN-AGREED/KeyDerivation Impl-Dep

CCN-AGREED/PasswordMechanisms Impl-Dep

CCN-AGREED/RSA Impl-Dep

CCN-AGREED/RSAKeys Impl-Dep

CCN-AGREED/FFDLOG Impl-Dep

CCN-AGREED/FFDLOGKeys Impl-Dep

CCN-AGREED/ECDLOG Impl-Dep

CCN-AGREED/ECDLOGKeys Impl-Dep

CCN-AGREED/AsymEncryption Impl-Dep

CCN-AGREED/DigitalSignature Impl-Dep

CCN-AGREED/KeyEstablishment Impl-Dep

CCN-AGREED/TRNGEntropy Impl-Dep

CCN-AGREED/PTRNG Impl-Dep

CCN-AGREED/NPTRNG Impl-Dep

CCN-AGREED/DRNG Impl-Dep

CCN-AGREED/DRNGScheme Impl-Dep

CCN-PROTOCOL CCN-PROTOCOL/TLS Impl-Dep

Agreed CCN-PROTOCOL/SSH Impl-Dep
Cryptographic
Protocols CCN-PROTOCOL/IPsec Impl-Dep

Table 6. Cryptographic Evaluation Tests defined for CCN Agreed & Protocol

Centro Criptológico Nacional 60

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

3.3.1 CRYPTOGRAPHIC EVALUATION TESTS DEFINITION

93. This subsection defines the cryptographic evaluation tests that shall be
performed by the tester to accomplish the evaluation tasks, based on the agreed
cryptographic mechanisms and protocols established by CCN.

3.3.1.1 CRYPTOGRAPHIC MECHANISMS IMPLEMENTATION

94. This first topic defines the cryptographic evaluation tests to verify that each
cryptographic mechanism declared by the vendor in I1 is considered agreed
upon by CCN, in order to fulfill the CCN-AGREED evaluation task.

3.3.1.1.1 Symmetric Elementary Primitives

95. Symmetric primitives utilize the same cryptographic key for both encryption and
decryption operations (except for hash and XOF functions which are keyless
functions). For these primitives, the security consists of the confidentiality of the
key shared by legitimate users.

3.3.1.1.1.1 Block Cipher

96. A block cipher is a symmetric elementary primitive based on a family of
permutations of {0,1}n applied to a data block with size n defined by the key size
k, expressed in bits.
97. In case the TOE implements cryptographic primitives based on block ciphers:
• The TOE shall only implement agreed block ciphers according to the table below:

Agreed Block Ciphers

Primitive Parameter’s Sizes R/L Notes
k = 128 bits R
AES
[FIPS-197] k = 192 bits R
[ISO-18033-3]
k = 256 bits R

Table 7. Agreed Block Ciphers

• The tester shall perform the following cryptographic evaluation test:

Centro Criptológico Nacional 61

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-AGREED/BlockCipher Inputs

In the case of CL1 evaluations, verify in I1 that:

- The parameterization used for the block cipher
cryptographic primitives implemented by the TOE is
considered as agreed upon according to Table 7. I1
In the case of CL2 evaluations, operate the TOE (using I2) to verify I2
the above-mentioned. I6
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned.

3.3.1.1.1.2 Stream Cipher

98. A synchronous binary stream cipher allows encrypting a plaintext of arbitrary
length L bits by deriving a binary L-bit keystream sequence from a k-bit key and
an n-bit initialization value, and bitwise combining modulo 2 the plaintext
sequence and the keystream sequence. The obtained L-bit sequence represents
the ciphertext.
99. In case the TOE implements cryptographic primitives based on stream ciphers:
• The TOE shall only implement agreed stream ciphers according to the table
below and follow the specific notes:

Agreed Stream Ciphers

Primitive Parameter’s Sizes R/L Notes
k = 256 bits
ChaCha20
nonce = 96 bits R Note 1
[RFC-8439]
20 rounds

Table 8. Agreed Stream Cipher

Note 1 [ChaCha20 Implementation] CL1, CL2 and CL3

The ChaCha20 stream cipher primitive shall always be implemented in

conjunction with the Poly1305 message authentication code as an
authenticated encryption cryptographic construction to provide
confidentiality, integrity, and authenticity to the processed information.

• The tester shall perform the following cryptographic evaluation test:

Centro Criptológico Nacional 62

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-AGREED/StreamCipher Inputs

In the case of CL1 evaluations, verify in I1 that:

- The parameterization used for the stream cipher
cryptographic primitives implemented by the TOE is
considered as agreed upon according to Table 8.
I1
- The stream cipher cryptographic primitives implemented
by the TOE comply with the specific notes. I2
In the case of CL2 evaluations, operate the TOE (using I2) to verify I6
the above-mentioned.
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned.

3.3.1.1.1.3 Hash Functions

100. Cryptographic hash functions are keyless functions that take a bit string of
arbitrary length as input and produce a fixed-length hash value.
101. In case the TOE implements cryptographic primitives based on hash functions:
• The TOE shall only implement agreed hash functions according to the table
below and follow the specific notes:

Agreed Hash Functions

Primitive Parameter’s Sizes R/L Notes
h = 256 bits (SHA2-256) R
SHA-2 h = 384 bits (SHA2-384) R
[FIPS-180-4]
[ISO-10118-3] h = 512 bits (SHA2-512) R
h = 256 bits (SHA2-512/256) R
h = 256 bits (SHA3-256) R
SHA-3
h = 384 bits (SHA3-384) R
[FIPS-202]
h = 512 bits (SHA3-512) R
BLAKE2b
h = 512 bits R Note 2
[RFC-7693]

Table 9. Agreed Hash Functions

Note: Although SHA-1 is not an agreed hash function, a particular message

authentication code whose construction is based on SHA-1, namely HMAC-
SHA-1, is accepted as a legacy scheme.

Centro Criptológico Nacional 63

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Note 2 [Agreed BLAKE2b] CL1, CL2 and CL3

The BLAKE2b cryptographic primitive shall always be implemented as the

underlying primitive of the Argon2id cryptographic construction for password
hashing purposes. Therefore, their standalone use is considered not
recommended.

• The tester shall perform the following cryptographic evaluation test:

CCN-AGREED/Hash Inputs

In the case of CL1 evaluations, verify in I1 that:

- The scheme used for the hash cryptographic primitives
implemented by the TOE is considered as agreed upon
according to Table 9.
I1
- The hash cryptographic primitives implemented by the
TOE comply with the specific notes. I2
In the case of CL2 evaluations, operate the TOE (using I2) to verify I6
the above-mentioned.
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned.

3.3.1.1.1.4 Secret Sharing

102. Secret sharing (also called secret splitting) refers to methods for distributing a
secret amongst a group of participants, each of whom is allocated a share of the
secret. The secret can be reconstructed only when a sufficient number, of
possibly different types, of shares are combined; individual shares are of no use
on their own.
103. In case the TOE implements cryptographic primitives based on secret sharing:
• The TOE shall only implement agreed secret-sharing primitives according to the
table below:

Agreed Secret Sharing Primitives

Primitive R/L Notes
Shamir’s Secret Sharing
R
[Sha79]

Table 10. Agreed Secret Sharing Primitives

Centro Criptológico Nacional 64

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

• The tester shall perform the following cryptographic evaluation test:

CCN-AGREED/SecretSharing Inputs

In the case of CL1 evaluations, verify in I1 that:

- The scheme used for the secret sharing cryptographic
primitives implemented by the TOE is considered as agreed
upon according to Table 10. I1
In the case of CL2 evaluations, operate the TOE (using I2) to verify I2
the above-mentioned. I6
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned.

3.3.1.1.1.5 Extendable-Output Functions (XOF)

104. Extendable-output functions (XOFs) are an extension of the cryptographic hash
functions that can generate outputs of arbitrary length, which is a significant
departure from fixed-length output hash functions. They find their utility in
various cryptographic applications where variable or very long hash values are
desirable.
105. Of particular note are those based on Keccak, which employs a unique sponge
construction that allows arbitrary output lengths, facilitating a variety of
cryptographic applications. Keccak is known for its robust security against
cryptographic attacks, its efficiency in hardware implementations, and its
versatility, making it a valuable asset in modern cryptographic practices.
106. In case the TOE implements cryptographic primitives based on XOF:
• The TOE shall only implement agreed XOF primitives according to the table
below and follow the specific notes:

Agreed XOF Primitives

Primitive Security Strength R/L Notes

SHAKE s = 128 bits (SHAKE128) R Note 3

[FIPS-202] s = 256 bits (SHAKE256) R Note 3
cSHAKE s = 128 bits (cSHAKE128) R Note 3
[SP800-185] s = 256 bits (cSHAKE256) R Note 3

Table 11. Agreed XOF Primitives

Centro Criptológico Nacional 65

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Note 3 [Agreed XOF] CL1, CL2 and CL3

The XOF cryptographic primitives shall always be implemented as underlying

primitives of cryptographic constructions such as KMAC or XMSS. Therefore,
their standalone use is considered not recommended.

• The tester shall perform the following cryptographic evaluation test:

CCN-AGREED/XOF Inputs

In the case of CL1 evaluations, verify in I1 that:

- The scheme used for the XOF cryptographic primitives
implemented by the TOE is considered as agreed upon
according to Table 11.
I1
- The XOF cryptographic primitives implemented by the TOE
comply with the specific notes. I2
In the case of CL2 evaluations, operate the TOE (using I2) to verify I6
the above-mentioned.
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned.

3.3.1.1.2 Symmetric Constructions

107. Symmetric constructions are built upon symmetric elementary primitives and
enable them to address a large variety of security objectives. The security of
keyed symmetric schemes relies on the confidentiality and integrity of a secret
key shared by legitimate parties.

3.3.1.1.2.1 Symmetric Encryption (Confidentiality Only)

108. Confidentiality modes are schemes that provide an encryption procedure that
transforms the plaintext into ciphertext using a secret key, and a decryption
procedure that allows the plaintext to be recovered from the ciphertext and the
key. They are based on a block cipher cryptographic primitive.
109. In case the TOE implements symmetric encryption cryptographic constructions
to provide only confidentiality to the processed information:
• The TOE shall only implement agreed symmetric encryption constructions
according to the table below and follow the specific notes:

Centro Criptológico Nacional 66

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Agreed Symmetric Encryption (Confidentiality Only) Constructions

Operation Mode R/L Notes
CBC Note 4
[SP800-38A] R* Note 5
[ISO-10116] Note 7
CBC-CS Note 4
R*
[SP800-38A-Addendum] Note 5
CFB Note 4
[SP800-38A] R* Note 5
[ISO-10116] Note 7
CTR Note 4
[SP800-38A] R* Note 5
[ISO-10116] Note 6
OFB Note 4
[SP800-38A] R* Note 5
[ISO-10116] Note 6

Table 12. Agreed Symmetric Encryption Cryptographic Constructions

Note 4 [IV Type] CL2 and CL3

The encryption scheme must either be probabilistic and generate a random

initialization vector to bootstrap encryption or require an additional input,
whose value can only be used once with a given key (nonce). The
specifications of modes of operation describe what is expected (nonce or
random IV) and implementations shall follow these specifications, e.g., CBC
with a constant or more generally a predictable IV does not follow the CBC
specification [SP800-38A] and is not accepted.
This specific note is addressed in the CCN-PITFALL/SymEncryption.1
evaluation test.

Note 5 [Add Integrity] CL1, CL2 and CL3

Authenticated encryption schemes provide superior privacy security

guarantees than encryption-only mechanisms. As a consequence, while all
encryption-only modes considered above are recommended for mode
construction their standalone use is considered legacy. This is the reason why
the expression R* appears in Table 12.

Centro Criptológico Nacional 67

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Note 6 [Stream Mode] CL2 and CL3

Some symmetric confidentiality schemes operate by masking the plaintext by

a keystream generated from the key and IV. When using these so-called
stream modes of operation, it is of utmost importance to make sure that no
two generated key streams ever overlap. This can be achieved
deterministically in some modes, e.g., CTR. It is ensured with overwhelming
probability in other modes, e.g., OFB mode, as long as the same IV-key pair is
not used (or only with negligible probability) to encrypt two messages under
the same key.
This specific note is addressed in CCN-PITFALL/SymEncryption.1 and CCN-
PITFALL/CTR evaluation tests.

Note 7 [Padding] CL2 and CL3

Some encryption modes cannot handle naturally the encryption of a last

incomplete block. For such modes, a specific operation must be performed on
the last block. A widespread procedure consists of padding the plaintext with
some structured data to ensure its size is a multiple of the block size. The
verification of the format of the padding during decryption may leak
information on the decrypted value in a way that could be used to decrypt any
ciphertext. More generally, any verification performed on the format of the
decrypted ciphertext may leak information. Vendors/testers should ensure
that the implementation of decryption does not provide an attacker with any
such padding or format oracle. An alternative to the application of the padding
scheme is the use of ciphertext stealing [SP800-38A-Addendum].
This specific note is addressed in the CCN-PITFALL/SymEncryption.2
evaluation test.

• The tester shall perform the following cryptographic evaluation test:

CCN-AGREED/SymEncryption Inputs

In the case of CL1 evaluations, verify in I1 that:

- The scheme used for the symmetric encryption
cryptographic constructions implemented by the TOE is I1
considered as agreed upon according to Table 12.
I2
- The symmetric encryption cryptographic constructions
implemented by the TOE comply with the specific notes. I6

In the case of CL2 evaluations, operate the TOE (using I2) to verify
the above-mentioned.

Centro Criptológico Nacional 68

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-AGREED/SymEncryption Inputs
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned.

3.3.1.1.2.2 Disk Encryption

110. Encryption modes require an expansion of the data to be ciphered of at least
one block due to the addition of an initialization vector or nonce. Moreover, they
cannot efficiently decrypt a specific part of the ciphertext. Because of these
topics, there exist deterministic modes for disk encryption.
111. In case the TOE implements symmetric encryption cryptographic constructions
to perform disk encryption operations:
• The TOE shall only implement agreed disk encryption constructions according to
the table below and follow the specific notes:

Agreed Disk Encryption Constructions

Operation Mode R/L Notes
XTS Note 8
R
[SP800-38E] Note 9

Table 13. Agreed Disk Encryption Cryptographic Constructions

Note: The XTS mode supports key lengths of 256 and 512 bits.

Note 8 [Unique Tweak] CL2 and CL3

The tweak value used to encrypt each complete or incomplete block position
in each disk sector shall be unique, i.e., a (set of) disk(s) encrypted under the
same key shall never contain two distinct blocks encrypted under the same
key and the same tweak value. In the former sentence, blocks are meant as n-
bit elements of the alphabet of the block cipher.
This specific note is addressed in the CCN-PITFALL/DiskEncryption evaluation
test.

Centro Criptológico Nacional 69

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Note 9 [XTS Key] CL2 and CL3

An implementation of XTS-AES that improperly generates the key so that key1

= key2 is vulnerable to a chosen ciphertext attack.
Therefore, key1 and key2 shall be generated and/or established independently
according to the rules for component symmetric keys from [SP800-133] rev2,
section 6.3. The TOE shall check explicitly that key1 ≠ key2 before using the
keys in the XTS algorithm to process data with them.
This specific note is addressed in the CCN-PITFALL/XTS evaluation test.

• The tester shall perform the following cryptographic evaluation test:

CCN-AGREED/DiskEncryption Inputs

In the case of CL1 evaluations, verify in I1 that:

- The scheme used for the disk encryption cryptographic
constructions implemented by the TOE is considered as
agreed upon according to Table 13. I1
In the case of CL2 evaluations, operate the TOE (using I2) to verify I2
the above-mentioned and that it complies with the specific notes. I6
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned and that it complies with the specific notes.

3.3.1.1.2.3 Integrity Modes: Message Authentication Code

112. These schemes provide data integrity and data origin authentication based on
symmetric mechanisms. They contain a message authentication code (MAC)
generation function (inputs: a secret key K and a message m, output: μ), and a
MAC verification function (inputs: K, m, μ, output: True or False).
113. In case the TOE implements MAC cryptographic constructions:
• The TOE shall only implement agreed MAC cryptographic constructions
according to the table below and follow the specific notes:

Agreed MAC Constructions

Scheme Parameter’s Sizes R/L Notes
CMAC
Note 10
[SP800-38B] R
Note 11
[ISO-9797-1]

Centro Criptológico Nacional 70

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Agreed MAC Constructions

Scheme Parameter’s Sizes R/L Notes
Note 10
CBC-MAC
R Note 11
[ISO-9797-1]
Note 12
Note 10
HMAC k ≥ 128 bits R
Note 11
[RFC-2104]
[ISO-9797-2] Note 10
k ≥ 100 bits L
Note 11
HMAC-SHA-1 Note 10
[RFC-2104] k ≥ 100 bits L[2030] Note 11
[ISO-9797-2] [FIPS-180-4] Note 13
Note 14
GMAC
R Note 15
[SP800-38D]
Note 16
KMAC-128
k ≥ 128 bits R Note 17
[SP800-185]
KMAC-256
k ≥ 256 bits R Note 17
[SP800-185]
Poly1305
R Note 18
[RFC-8439]

Table 14. Agreed MAC Constructions

Note 10 [MAC Truncation 96 bits] CL1, CL2 and CL3

Unless stated otherwise explicitly for a given mechanism, the truncation of a

MAC generated by an agreed MAC mechanism to at least 96 bits is agreed. A
necessary condition, this may not be sufficient for specific MAC schemes, e.g.,
GMAC (see Note 16).

Note 11 [MAC Truncation 64 bits] CL1, CL2 and CL3

Unless stated otherwise explicitly for a given mechanism, the truncation of a

MAC generated by an agreed MAC mechanism to at least 64 bits is considered
legacy under the condition that the maximal number of MAC verifications
performed for a given key over its lifetime can be bound by 220.

Centro Criptológico Nacional 71

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Note 12 [Fixed Input Length] CL2 and CL3

CBC-MAC is agreed upon only in contexts where the sizes of all the inputs for
which MAC is computed under the same key are identical. Trivial length
extension forgeries can be performed when variable length inputs are
allowed.
This specific note is addressed in the CCN-PITFALL/CBCMAC evaluation test.

Note 13 [HMAC-SHA-1] CL1, CL2 and CL3

The HMAC construction does not require the collision resistance of the
underlying hash function. For the time being, HMAC-SHA-1 is considered an
acceptable legacy mechanism, even though SHA-1 is not considered an
acceptable general-purpose hash function. It is recommended however to
phase out HMAC-SHA-1.

Note 14 [GMAC-GCM Nonce] CL2 and CL3

The IV must be managed within the security perimeter of the authenticated

encryption process. For example, it is crucial to ensure that no adversary can
cause the same IV to be reused to protect different (plaintext, associated data)
pairs under the same key.

Note 15 [GMAC-GCM Options] CL1, CL2 and CL3

Only the following GCM options are agreed upon: the IV length must be equal
to 96 bits; the deterministic IV construction method [SP800-38D] section 8.2.1
must be used; the MAC length must be 128 bits.

Note 16 [GMAC-GCM Bounds] CL1, CL2 and CL3

As the unforgeability bounds of the agreed GMAC and GCM options of Note
15 are not optimal, the MAC length must be at least 128 bits. Thus, no
truncation to a final MAC length, such as 96 bits, must be performed.

Note 17 [KMAC Security Settings] CL1, CL2 and CL3

KMAC is not allowed to be used in XOF mode.

Centro Criptológico Nacional 72

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Note 17 [KMAC Security Settings] CL1, CL2 and CL3

It is important to note that Note 10 and Note 11 also apply to KMAC schemes.
However, they will be applied directly to the output length of KMAC, without
applying truncation.

Note 18 [Poly1305 Implementation] CL1, CL2 and CL3

The Poly1305 message authentication code construction shall be always

implemented in conjunction with the ChaCha20 stream cipher primitive as an
authenticated encryption cryptographic construction to provide
confidentiality, integrity, and authenticity to the processed information.

• The tester shall perform the following cryptographic evaluation test:

CCN-AGREED/MAC Inputs

In the case of CL1 evaluations, verify in I1 that:

- The scheme used for the MAC cryptographic constructions
implemented by the TOE is considered as agreed upon
according to Table 14.
I1
- The MAC cryptographic constructions implemented by the
TOE comply with the specific notes. I2
In the case of CL2 evaluations, operate the TOE (using I2) to verify I6
the above-mentioned.
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned.

3.3.1.1.2.4 Symmetric Entity Authentication Schemes

114. These schemes allow an entity to prove its identity to a correspondent by
demonstrating its knowledge of a secret. They are interactive by nature and
generally consist of using a MAC scheme or an encryption scheme in a random
challenge-response protocol. The same key should not be used by integrity
modes and symmetric entity authentication schemes.
115. In case the TOE implements entity authentication cryptographic constructions
based on challenges:
• The TOE shall only implement agreed entity authentication challenges according
to the table below and follow the specific notes:

Centro Criptológico Nacional 73

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Agreed Entity Authentication Challenges

Challenge Size R/L Notes
l ≥ 125 bits R Note 19
96 bits ≤ l ≤ 125 bits L Note 19

Table 15. Agreed Entity Authentication Challenges

Note 19 [Challenge-Response Protocol] CL2 and CL3

The tester must ensure that a challenge cannot be replayed with non-
negligible probability. The challenge could for example be implemented by a
random value, whose size is large enough, and that is generated by the tester.

• The tester shall perform the following cryptographic evaluation test:

CCN-AGREED/EntityAuth Inputs

In the case of CL1 evaluations, verify in I1 that:

- The scheme used for the symmetric entity authentication
cryptographic constructions implemented by the TOE is
considered as agreed upon according to Table 15. I1
In the case of CL2 evaluations, operate the TOE (using I2) to verify I2
the above-mentioned and that it complies with the specific notes. I6
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned and that it complies with the specific notes.

3.3.1.1.2.5 Authenticated Encryption (AE)

116. The purpose of authenticated encryption (AE) is to achieve confidentiality,
integrity, and data origin authentication of messages. An AE scheme provides an
encryption function that transforms a plaintext into a ciphertext using a given
key, and a decryption function that retrieves the plaintext from the ciphertext
and the key. In comparison with an encryption-only scheme, an AE scheme
decryption function may fail to return a decrypted value if the ciphertext does
not respect some redundancy pattern, usually, some part of the ciphertext acts
as a verification value that is checked during decryption.
117. An extra feature is often provided, namely combining the authentication of the
encrypted data with the authentication of additional unencrypted data.
Authenticated encryption with that feature is often referred to as Authenticated
Encryption with Associated Data (AEAD). An AE or AEAD scheme may result from
the combination of an encryption scheme and a message authentication code.

Centro Criptológico Nacional 74

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

118. In case the TOE implements authenticated encryption cryptographic

constructions:
• The TOE shall only implement agreed authenticated encryption constructions
according to the table below and follow the specific notes:

Agreed Authenticated Encryption Constructions

Scheme R/L Notes
Encrypt-then-MAC Note 20
R
[BN00] Note 21
CCM
Note 20
[SP800-38C] R
Note 21
[ISO-19772]
Note 14
Note 15
GCM
Note 16
[SP800-38D] R
Note 20
[ISO-19772]
Note 21
Note 22
EAX Note 20
R
[ISO-19772] Note 21
ChaCha20-Poly1305
R Note 23
[RFC-8439]

Table 16. Agreed Authenticated Encryption Constructions

Note 20 [Authenticated Encryption Schemes] CL1, CL2 and CL3

It should be noted that the authorized symmetric authenticated encryption

schemes are all cryptographic constructions. Some of them use a single block
cipher as a primitive, such as CCM or GCM; others are based on a primitive
encryption scheme and on a message authentication scheme, which describes
only how they are composed; for example, Encrypt-then-MAC. In such cases,
the primitives must be authorized.
It is important to note that Note 10 and Note 11 also apply to symmetric
authenticated encryption schemes.

Note 21 [Decryption Order] CL2 and CL3

If the integrity of the ciphertexts is not properly checked before decryption,

the vendor/tester should ensure that the implementation does not instantiate
any padding or other error oracle. This means that the implementation does
not give away any information on the padding or the format of the plaintext

Centro Criptológico Nacional 75

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Note 21 [Decryption Order] CL2 and CL3

obtained through the decryption of an arbitrary ciphertext. Otherwise, an
adversary may be able to decrypt a target ciphertext by exploiting, e.g., error
messages, or time side-channel information. Plaintexts should never be sent
to consumer applications before their integrity has been checked.
This specific note is addressed in the CCN-PITFALL/AuthEncryption evaluation
test.

Note 22 [GCM Plaintext Length] CL2 and CL3

By specification, at each invocation of GCM, the length of the plaintext must

be at most 232 − 2 blocks of the underlying block cipher. Checking that this
maximal length is not exceeded is required in environments where this might
potentially happen.
This specific note is addressed in the CCN-PITFALL/GCM.1 evaluation test.

Note 23 [ChaCha20-Poly1305 IV] CL2 and CL3

The IV shall be processed within the boundary of the authenticated encryption

scheme. It is essential to ensure that an attacker can never cause the same IV
to be used to protect two different pairs of messages and associated data with
the same key. The utilization of an IV can affect confidentiality.

• The tester shall perform the following cryptographic evaluation test:

CCN-AGREED/AuthEncryption Inputs

In the case of CL1 evaluations, verify in I1 that:

- The scheme used for the authenticated encryption
cryptographic constructions implemented by the TOE is
considered as agreed upon according to Table 16.
I1
- The authenticated encryption cryptographic constructions
implemented by the TOE comply with the specific notes. I2
In the case of CL2 evaluations, operate the TOE (using I2) to verify I6
the above-mentioned.
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned.

Centro Criptológico Nacional 76

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

3.3.1.1.2.6 Key Protection

119. The key protection mechanisms enable to secure storage or transmission of
keys, ensuring the confidentiality, integrity, and data origin authentication of the
key.
120. In case the TOE implements key protection cryptographic constructions:
• The TOE shall only implement agreed key protection constructions according to
the table below and follow the specific notes:

Agreed Key Protection Constructions

Scheme R/L Notes
SIV
R
[RFC-5297]
AES-Keywrap
R
[SP800-38F] Mechanisms KW and KWP
Notes
Authenticated Encryption Construction
R according to
(Table 16)
the Table 16

Table 17. Agreed Key Protection Constructions

Note: The SIV mode supports key lengths of 256, 384, and 512 bits.

• The tester shall perform the following cryptographic evaluation test:

CCN-AGREED/KeyProtection Inputs

In the case of CL1 evaluations, verify in I1 that:

- The scheme used for the key protection cryptographic
constructions implemented by the TOE is considered as
agreed upon according to Table 17 and/or Table 16.
- The authenticated encryption cryptographic constructions I1
implemented by the TOE (used for key protection
I2
capabilities) comply with the specific notes.
I6
In the case of CL2 evaluations, operate the TOE (using I2) to verify
the above-mentioned.
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned.

3.3.1.1.2.7 Key Derivation Functions (KDF)

121. A key derivation mechanism enables to derivation of several keys from a single
master key. It generally takes three arguments as input, a secret value K, a

Centro Criptológico Nacional 77

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

(possibly) public value N, and a length n, and then generates n bits that can be
split into several keys that appear to be independent.
122. In case the TOE implements key derivation cryptographic constructions:
• The TOE shall only implement agreed key derivation functions according to the
table below and follow the specific notes:

Agreed Key Derivation Constructions

Scheme R/L Notes
NIST SP800-56 A/B/C
R
[SP800-56A] [SP800-56B] [SP800-56C]
NIST SP800-108
R
[SP800-108]
ANSI-X9.63 KDF
R
[ANSI-X9.63]
PBKDF2
R Note 24
[RFC-8018] [SP800-132]
HKDF
R
[RFC-5869]

Table 18. Agreed Key Derivation Constructions

Note 24 [PBKDF2 PRF] CL2 and CL3

PBKDF2 is built over a pseudo-random function, that can be instantiated using

a MAC generation function. This pseudo-random function shall be an agreed
mechanism. In the case where HMAC is used, care has to be taken regarding
the key length. Indeed, if the HMAC key is longer than the hash function
message block length, the key is hashed. This pre-hashing in HMAC can lower
the effective entropy of the key derived using PBKDF2.

• The tester shall perform the following cryptographic evaluation test:

Centro Criptológico Nacional 78

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-AGREED/KeyDerivation Inputs

In the case of CL1 evaluations, verify in I1 that:

- The scheme used for the key derivation cryptographic
constructions implemented by the TOE is considered as
agreed upon according to Table 18. I1
In the case of CL2 evaluations, operate the TOE (using I2) to verify I2
the above-mentioned and that it complies with the specific notes. I6
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned and that it complies with the specific notes.

3.3.1.1.2.8 Password Protection/Hashing Mechanisms

123. Password protection/hashing mechanisms associate a password with a
verification value. Systems relying on passwords to authenticate users store
these verification values. This enables them to test passwords without storing
them. Even in the case of the verification values being compromised, an
adversary should not be able to recover a strong password.
124. In case the TOE implements password protection/hashing cryptographic
constructions:
• The TOE shall only implement agreed password protection/hashing functions
according to the table below and follow the specific notes:

Agreed Password Protection/Hashing Constructions

Scheme R/L Notes
Argon2id Note 25
R
[RFC-9106] Note 26
PBKDF2 Note 27
R
[RFC-8247] Note 28
SCRYPT
R
[RFC-7914]

Table 19. Agreed Password Protection/Hashing Constructions

Centro Criptológico Nacional 79

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Note 25 [Use of Argon2id] CL1, CL2 and CL3

There are two recommended configurations for the use of Argon2id

depending on the environment.
The first configuration, default in all environments, is the variant with
parameters number of passes t = 1 and 2 GB of memory because it is secure
against side-channel attacks and maximizes the cost of confrontation on
dedicated brute-force hardware.
The second configuration, default for memory-limited environments, is the
variant with parameters number of passes t = 3 and 64 MB of memory.

Note 26 [Argon2id Parameters]

In addition to following one of the recommended configurations described in

Note 25, the following parameterization shall be complied with:
- Password length not greater than 232 – 1 bytes
- Degree of parallelism (p) of 4 lanes
- 128-bit Salt and unique for each password
- 256-bit Tag
If optional parameters such as secret value (K) or associated data (X) are used,
the length must not be greater than 232 – 1 bytes.

Note 27 [Number of Iterations] CL1, CL2 and CL3

Password hashing mechanisms offer parameters controlling the complexity of

the hashing execution. This allows to increase in the work factor of brute-force
attacks: a legitimate use of the password hashing requires only one execution,
while a brute-force attack requires a large number of executions. Thus, the
number of iterations of PBKDF2 should be selected as large as possible so that
it does not impede legitimate use.

Note 28 [Salt] CL1, CL2 and CL3

Salt is a random value, generated when the password is registered, and that
is stored along with the password verification value. Salting a password
hashing mechanism counters pre-computation attacks. The length of the salt
shall be at least 128 bits.

• The tester shall perform the following cryptographic evaluation test:

Centro Criptológico Nacional 80

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-AGREED/PasswordMechanisms Inputs

In the case of CL1 evaluations, verify in I1 that:

- The scheme used for the password protection/hashing
cryptographic constructions implemented by the TOE is
considered as agreed upon according to Table 19.
- The password protection/hashing cryptographic I1
constructions implemented by the TOE comply with the
I2
specific notes.
I6
In the case of CL2 evaluations, operate the TOE (using I2) to verify
the above-mentioned.
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned.

3.3.1.1.3 Asymmetric Elementary Primitives

125. In asymmetric cryptography, security is based on the discrepancy between the
computational difficulties of two mathematical problems: one is easy whereas
the other is hard. That asymmetry is needed in order to ensure the possibility of
generating pairs of private and public keys for which it is computationally hard
to recover the private key from the public key. There should be no polynomial
mechanism to deduce the private key from the public key.
126. This section contains the asymmetric atomic primitives and corresponding
mathematical problems, moreover, the next section describes the asymmetric
constructions that can be achieved by building upon these primitives.

3.3.1.1.3.1 RSA/Integer Factorization

127. The RSA primitive consists of a public permutation parametrized by a public key
and a private inverse permutation parametrized by the associated private key.
This primitive is invoked in various RSA encryption or RSA signature schemes
addressed in the next section. These schemes also specify padding and
redundancy check conventions.
128. Note that the primitive alone must not be considered in a complete encryption
or signature scheme since its use without extra conventions would be highly
insecure.
129. In case the TOE implements asymmetric cryptographic primitives based on
integer factorization:
• The TOE shall only implement agreed integer factorization schemes according to
the table below:

Centro Criptológico Nacional 81

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Agreed Asymmetric Primitives based on Integer Factorization

Primitive Parameter’s Sizes R/L Notes
n ≥ 3000
R
RSA log 2 𝑒𝑒 > 16
[RSA78] n ≥ 1900
L[2025]
log 2 𝑒𝑒 > 16
Table 20. Agreed Asymmetric Primitives based on Integer Factorization
• The tester shall perform the following cryptographic evaluation test:

CCN-AGREED/RSA Inputs

In the case of CL1 evaluations, verify in I1 that:

- The parameterization used for the asymmetric
cryptographic primitives based on integer factorization
implemented by the TOE is considered as agreed upon I1
according to Table 20.
I2
In the case of CL2 evaluations, operate the TOE (using I2) to verify
the above-mentioned. I6

In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned.

130. In case the TOE implements RSA key pair generation:

• The TOE shall only implement agreed RSA key pair generation schemes according
to the table below and follow the specific notes. This also implies the
implementation of:
- An agreed prime random number generation method for the generation
of primes p and q (see section 3.3.1.1.5.3.2 “Random Prime Number
Generation”), that makes use of the Miller-Rabin as the primality test.
- An agreed random uniform distribution method for the generation of the
testing candidates and the basis parameter in each iteration of the Miller-
Rabin algorithm (see section 3.3.1.1.5.3.1 “Random Uniform Modular
Distributions”).

Agreed RSA Key Generation Schemes

Scheme Notes
RSA Key-Pair Generation
[SOGIS-HEP] Append. B.3 Note 29
[CCN-STIC-221] Algorithm 6

Centro Criptológico Nacional 82

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Table 21. Agreed RSA Key Generation Schemes

Note 29 [Primes] CL2 and CL3

As described in the scheme, the generation of primes p and q shall be done by

means of an agreed prime number generation method (see section
3.3.1.1.5.3.2 “Random Prime Number Generation”).
The conditions for Test(p) and Test(q) to be employed by the prime generation
method used to generate p and q are defined by the agreed scheme.

• The tester shall perform the following cryptographic evaluation test:

CCN-AGREED/RSAKeys Inputs

In the case of CL2 evaluations, use I1 and operate the TOE (using
I2) to verify that:
For the key pair generation:
- The scheme used for the RSA key pair generation processes
implemented by the TOE is considered as agreed upon
according to Table 21.
- The RSA key pair generation schemes implemented by the
TOE comply with the specific notes.
For the generation of primes p and q:
- The method used for the random prime generation
implemented by the TOE is considered as agreed upon I1
according to Table 32.
I2
- The random prime generation methods implemented by
I6
the TOE comply with the specific notes.
For the generation of the testing candidates and the Miller-Rabin
basis parameter in each iteration:
- The scheme used for the random uniform modular
distribution implemented by the TOE is considered as
agreed upon according to Table 31.
- The random uniform modular distribution methods
implemented by the TOE comply with the specific notes.
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned.

Centro Criptológico Nacional 83

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

3.3.1.1.3.2 Multiplicative Discrete Logarithm Problem

131. The security of several asymmetric cryptographic schemes relies on the difficulty
of the discrete logarithm problem (DLP) in the multiplicative group of finite
fields, in comparison to the easiness of modular exponentiation (MODP) in finite
fields.
132. In case the TOE implements asymmetric cryptographic primitives based on the
multiplicative discrete logarithm problem over a finite prime field (FFDLOG):
• The TOE shall only implement agreed FFDLOG schemes according to the table
below:

Agreed Asymmetric Primitives based on FFDLOG

Primitive Parameter’s Sizes R/L Notes
3072 bits group R
4096 bits group R
MODP
6144 bits group R
[RFC-3526]
8192 bits group R
2048 bits group L[2025]
3072 bits group R
4096 bits group R
FFDHE
6144 bits group R
[RFC-7919]
8192 bits group R
2048 bits group L[2025]

Table 22. Agreed Asymmetric Primitives based on FFDLOG

• The tester shall perform the following cryptographic evaluation test:

CCN-AGREED/FFDLOG Inputs

In the case of CL1 evaluations, verify in I1 that:

- The parameterization used for the asymmetric
cryptographic primitives based on FFDLOG implemented
by the TOE is considered as agreed upon according to Table I1
22.
I2
In the case of CL2 evaluations, operate the TOE (using I2) to verify
the above-mentioned. I6

In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned.

Centro Criptológico Nacional 84

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

133. In case the TOE implements FFDLOG key pair generation:

• The TOE shall only generate private keys using an agreed random uniform
modular distribution according to Table 31 and follow the associated specific
notes.
• The tester shall perform the following cryptographic evaluation test:

CCN-AGREED/FFDLOGKeys Inputs

In the case of CL2 evaluations, use I1 and operate the TOE (using
I2) to verify that:
- The scheme used for the FFDLOG private key generation
processes implemented by the TOE uses an agreed random I1
uniform modular distribution according to Table 31.
I2
- The FFDLOG private key generation schemes implemented
by the TOE comply with the specific notes. I6

In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned.

3.3.1.1.3.3 Additive Discrete Logarithm Problem

134. The difficulty of the discrete logarithm problem can also be considered in the
group of rational points of an elliptic curve over a finite field. In this case, the
problem is called the discrete logarithm problem on elliptic curves, elliptic,
additive, or ECDLP (Elliptic Curve Discrete Logarithm Problem), as opposed to the
previous case, in which the operation considered was multiplication in a finite
group. In this case, the primitive is known as the discrete logarithm on elliptic
curves and in abbreviated form as ECDLOG (Elliptic Curve Discrete Logarithm).
135. In comparison with the discrete logarithm problem in finite fields, there are a
couple of choices to be made in the case of elliptic curves: first, the finite field
over which the elliptic curve will be defined, and second the elliptic curve itself.
As in the case of finite fields, only elliptic curves defined over prime fields are
agreed upon.
136. In case the TOE implements asymmetric cryptographic primitives based on the
additive discrete logarithm problem over elliptic curves (ECDLOG):
• The TOE shall only implement agreed ECDLOG schemes according to the table
below and follow the specific notes:

Centro Criptológico Nacional 85

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Agreed Asymmetric Primitives based on ECDLOG

Curve Family Curve R/L Notes
BrainpoolP256r1 R
Note 30
Brainpool
BrainpoolP384r1 R Note 31
[RFC-5639]
Note 32
BrainpoolP512r1 R
NIST P-256 R Note 30
NIST Note 31
NIST P-384 R
[SP800-186] Note 32
NIST P-521 R Note 33
Note 30
FR
FRP256v1 R Note 31
[ANS11]
Note 32
Curve25519 R Note 30
Montgomery
Note 31
[SP800-186] Curve448 R Note 32
Twisted Edwards Edwards25519 R Note 30
[SP800-186] Note 31
[FIPS-186-5] Edwards448 R Note 32

Table 23. Agreed Asymmetric Primitives based on ECDLOG

Note 30 [Points on the Curve] CL2 and CL3

Special precautions should be taken to ensure that manipulated points lie on

the curve, i.e., they verify the curve equation.
This specific note is addressed in the CCN-PITFALL/ECDLOG evaluation test.

Note 31 [Points on a Subgroup] CL2 and CL3

In case a curve with non-prime order is used, it should be ensured that the
manipulated points lie in the intended subgroup and have order divisible by r.
This specific note is addressed in the CCN-PITFALL/ECDLOG evaluation test.

Note 32 [Prime Order] CL2 and CL3

If the subgroup order is chosen to be prime, i.e., q = r, and such that r2 does
not divide #E(GF(p)), the verifications for Note 31 boil down to checking that
the manipulated points are of exact order r.

Centro Criptológico Nacional 86

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Note 33 [Prime Selection] CL2 and CL3

The special form of the prime number p used to construct the finite field GF(p)
makes side-channel attacks more efficient than with a random prime (and not
only because the arithmetic of the underlying finite field is faster).

• The tester shall perform the following cryptographic evaluation test:

CCN-AGREED/ECDLOG Inputs

In the case of CL1 evaluations, verify in I1 that:

- The parameterization used for the asymmetric
cryptographic primitives based on ECDLOG implemented
by the TOE is considered as agreed upon according to Table I1
23.
I2
In the case of CL2 evaluations, operate the TOE (using I2) to verify
the above-mentioned and that it complies with the specific notes. I6

In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned and that it complies with the specific notes.

137. In case the TOE implements ECDLOG key pair generation:

• The TOE shall only generate private keys using an agreed random uniform
modular distribution according to Table 31 and follow the associated specific
notes.
• The tester shall perform the following cryptographic evaluation test:

CCN-AGREED/ECDLOGKeys Inputs

In the case of CL2 evaluations, use I1 and operate the TOE (using
I2) to verify that:
- The scheme used for the ECDLOG private key generation
processes implemented by the TOE uses an agreed random I1
uniform modular distribution according to Table 31.
I2
- The ECDLOG private key generation schemes implemented
by the TOE comply with the specific notes. I6

In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned.

Centro Criptológico Nacional 87

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

3.3.1.1.4 Asymmetric Constructions

138. Asymmetric mathematical problems can be used to build asymmetric schemes.
Typically, in such schemes, each user has attributed a key pair, consisting of a
public key pk that can be published, and an associated private key sk that should
remain confidential. The difficulty of the underlying mathematical problem
guarantees that neither the private key can be recovered from the public key,
nor the sensitive operation of the scheme (e.g., decryption, or signature
generation) can be performed without the private key.
139. The security of asymmetric schemes relies on the security of a mathematical
problem and can also rely on the security of a symmetric primitive or scheme.
For a cryptographic construction to be agreed upon, it has to be based on agreed
primitives. In particular, the requirements on parameter sizes established in the
previous section also apply to the schemes in this section.
140. The security of keyed asymmetric schemes relies on the confidentiality and
integrity of the private key and the integrity and data origin authentication of
the public key.

3.3.1.1.4.1 Asymmetric Encryption Schemes

141. An asymmetric encryption scheme contains two functions. The encryption
transforms any message m, using the public key pk, into a ciphertext c. The
decryption function enables to recover m from c and sk.
142. In case the TOE implements asymmetric encryption cryptographic constructions:
• The TOE shall only implement agreed asymmetric encryption schemes according
to the table below and follow the specific notes:

Agreed Asymmetric Encryption Constructions

Primitive Scheme R/L Notes
OAEP (PKCS#1v2.1) Note 34
R
[RFC-8017] Note 35
RSA
PKCS#1v1.5
L Note 34
[RFC-8017]

Table 24. Agreed Asymmetric Encryption Constructions

Note 34 [Random Padding] CL2 and CL3

The asymmetric encryption schemes use randomized padding that shall be

generated by an agreed deterministic random number generator.

Centro Criptológico Nacional 88

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Note 35 [Padding-OAEP Attack] CL2 and CL3

In case the OAEP decryption procedure is not correctly implemented, that is

to say, the checks performed by EME-OAEP decoding are not performed in the
specified order, RSA OAEP may also be vulnerable to an Oracle attack.
This specific note is addressed in the CCN-PITFALL/AsymEncryption
evaluation test.

• The tester shall perform the following cryptographic evaluation test:

CCN-AGREED/AsymEncryption Inputs

In the case of CL1 evaluations, verify in I1 that:

- The scheme used for the asymmetric encryption
cryptographic constructions implemented by the TOE is
considered as agreed upon according to Table 24. I1
In the case of CL2 evaluations, operate the TOE (using I2) to verify I2
the above-mentioned and that it complies with the specific notes. I6
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned and that it complies with the specific notes.

3.3.1.1.4.2 Digital Signature

143. A digital signature scheme offers a signature generation function (inputs: a
private key sk and a message m, output: a signature σ), and a verification
function (inputs: the public key pk, the message m, and the signature σ, output:
True or False). Digital signature schemes offer data authentication and non-
repudiation.
144. In case the TOE implements digital signature cryptographic constructions:
• The TOE shall only implement agreed digital signature schemes according to the
table below and follow the specific notes:

Agreed Digital Signature Constructions

Primitive Scheme R/L Notes
PSS (PKCS#1v2.1)
RSA [RFC-8017] R Note 36
[ISO-9796-2]
KCDSA Note 36
FFDLOG R
[ISO-14888-3] Note 38

Centro Criptológico Nacional 89

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Agreed Digital Signature Constructions

Primitive Scheme R/L Notes
Schnorr Note 36
R
[ISO-14888-3] Note 38
DSA
Note 36
[FIPS-186-4] R
Note 38
[ISO-14888-3]
EC-KCDSA Note 36
R
[ISO-14888-3] Note 38
EC-DSA
Note 36
[FIPS-186-5] R
Note 38
[ISO-14888-3]
EC-GDSA Note 36
ECDLOG R
[TR-03111] Note 38
EC-Schnorr Note 36
R
[ISO-14888-3] Note 38
EdDSA
[FIPS-186-5] R
[RFC-8032]
PKCS#1v1.5
Note 36
RSA [RFC8017] L
Note 37
[ISO-9796-2]
Note 39
Note 40
XMSS
Note 41
Hash and XOF [RFC-8391] R
Note 42
[SP800-208]
Note 43
Note 44
ML-DSA
Lattice R Note 45
[FIPS-204]
Falcon
Lattice R Note 45
[PFH+20]
SLH-DSA
Hash and XOF R Note 45
[FIPS-205]

Table 25. Agreed Digital Signature Constructions

Centro Criptológico Nacional 90

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Note 36 [Hash Function] CL1, CL2 and CL3

The schema is agreed as long as the underlying hash function is agreed.

Note 37 [PKCS Format Check] CL2 and CL3

Format checks should be carefully implemented to avoid attacks à la

Bleichenbacher.

Note 38 [DSA Randomness] CL2 and CL3

In DSA and its elliptic curve variants, the digital signature generation
procedure generates a random value k. This random value shall be chosen
according to a uniform distribution making use of the agreed schemes (see
section 3.3.1.1.5.3.1 “Random Uniform Modular Distributions”).
In the case of private keys generation, the cryptographic evaluation tests CCN-
AGREED/FFDLOGKeys or CCN-AGREED/ECDLOGKeys shall be considered.

Note 39 [XMSS Underlying Primitives] CL1, CL2 and CL3

This scheme shall only be used with SHA2-256 and SHAKE256/256 underlying
primitives.

Note 40 [Stateful Post-quantum Digital Signatures1] CL1, CL2 and CL3

This scheme shall only be used for FW/SW verification.

Note 41 [Stateful Post-quantum Digital Signatures2] CL2 and CL3

In XMSS the private key is updated each time a message is signed. If the key is
stored in non-volatile memory, it shall be ensured that the private key is
updated in non-volatile memory before exporting the corresponding
signature.
This specific note is addressed in the CCN-PITFALL/XMSS.1 evaluation test.

Centro Criptológico Nacional 91

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Note 42 [Precautions for XMSS Backups] CL2 and CL3

The security of XMSS signatures is weakened when the same private key and
counter are used to sign different documents. Appropriate precautions shall
be taken to prevent this problem from occurring during the backup recovery
process.
This specific note is addressed in the CCN-PITFALL/XMSS.2 evaluation test.

Note 43 [Stateful Post-quantum Digital Signatures3] CL2 and CL3

Before generating the signature of a message, it shall be verified that the

private key counter does not exceed the maximum allowed by the established
parameterization.
This specific note is addressed in the CCN-PITFALL/XMSS.3 evaluation test.

Note 44 [Stateful Post-quantum Digital Signatures4] CL2 and CL3

It shall be verified that the derivation of the WOTS+ keys is performed

according to [SP800-208], i.e. using the PRF_keygen function to avoid multi-
target attacks.
This specific note is addressed in the CCN-PITFALL/XMSS.4 evaluation test.

Note 45 [Post-quantum Digital Signatures

CL1, CL2 and CL3
Implementation]

The ML-DSA and SLH-DSA cryptographic mechanisms shall be implemented

according to the guidelines provided in the final NIST standard.
The Falcon mechanism is not recommended to be implemented until NIST
publishes the final standard, since until then, the mechanism may undergo
variations.

• The tester shall perform the following cryptographic evaluation test:

Centro Criptológico Nacional 92

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-AGREED/DigitalSignature Inputs

In the case of CL1 evaluations, verify in I1 that:

- The scheme used for the digital signature cryptographic
constructions implemented by the TOE is considered as
agreed upon according to Table 25.
I1
- The digital signature cryptographic constructions
implemented by the TOE comply with the specific notes. I2
In the case of CL2 evaluations, operate the TOE (using I2) to verify I6
the above-mentioned.
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned.

3.3.1.1.4.3 Key Establishment

145. Asymmetric key establishment schemes allow two or more parties to generate
a common secret without using any pre-shared secret values. They are usually
combined with asymmetric or symmetric authentication based on a public-
private key pair or a shared secret key.
146. The most widely used two-party key establishment scheme has been proposed
by Diffie and Hellman and relies on the discrete logarithm problem (instantiated
in any suitable group).
147. In case the TOE implements key establishment cryptographic constructions:
• The TOE shall only implement agreed key establishment schemes according to
the table below and follow the specific notes:

Agreed Key Establishment Constructions

Primitive Scheme R/L Notes
DH Note 46
[SP800-56A] R Note 47
[ISO-11770-3] Note 50
FFDLOG Note 46
DLIES-KEM Note 47
R
[ISO-18033-2] Note 48
Note 50
EC-DH Note 46
ECDLOG [SP800-56A] R Note 47
[ISO-11770-3] Note 50

Centro Criptológico Nacional 93

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Agreed Key Establishment Constructions

Primitive Scheme R/L Notes
Note 46
ECIES-KEM Note 47
R
[ISO-18033-2] Note 49
Note 50
ML-KEM Note 46
R
[FIPS-203] Note 51
Lattice
FrodoKEM Note 46
R
[ISO-18033-2] Note 51

Table 26. Agreed Key Establishment Constructions

Note 46 [Authentication] CL2 and CL3

These key establishment schemes are unauthenticated and may fall to man-
in-the-middle attacks. In order to ensure security, it is necessary to
authenticate both parties and the data exchanged during the key
establishment scheme, such as public points and identities. This
authentication requires long-term secrets.

Note 47 [DH/EC-DH Subgroup Attacks] CL2 and CL3

Whether the Diffie-Hellman protocol is defined over the multiplicative group

of a finite field (DH) or the group of rational points of an elliptic curve (EC-DH),
it should be ensured that the manipulated values lie in the intended subgroup
and have a large enough order (see Note 30 and Note 31).
This specific note is addressed in CCN-PITFALL/FFKeyEstablishment and CCN-
PITFALL/ECKeyEstablishment evaluation tests.

Note 48 [DLIES Key Length] CL1, CL2 and CL3

A requirement to ensure the security of the DLIES is that it is impossible to

determine the discrete logarithm in the subgroup generated by g.
According to the current state of the art, the difficulty of DLP on 𝐹𝐹𝑃𝑃∗ can be
significantly reduced by precomputations that only rely on p and not, for
example, on the chosen subgroup or its generator. Therefore, this requires
that the length of the prime number p to be at least 3000 bits and the length
of the prime number q to be at least 250 bits.

Centro Criptológico Nacional 94

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Note 49 [ECIES Key Length] CL1, CL2 and CL3

Given that for ECIES the same requirement must be verified as that indicated
in Note 48 concerning the difficulty of solving the DLP in the subgroup
generated by the point of the curve considered with a given order. The length
of this order must be at least 250 bits.

Note 50 [Uniform Distributions] CL2 and CL3

DH, EC-DH, DLIES-KEM, and ECIES-KEM are probabilistic mechanisms since

random values belonging to certain integer intervals are selected, for private
key generation. Thus, such values must be chosen following a uniform
distribution (see section 3.3.1.1.5.3.1 “Random Uniform Modular
Distributions”).
The cryptographic evaluation tests CCN-AGREED/FFDLOGKeys or CCN-
AGREED/ECDLOGKeys shall be considered.

Note 51 [Post-quantum KEMs Implementation] CL1, CL2 and CL3

The ML-KEM cryptographic mechanism shall be implemented according to the

guidelines provided in the final NIST standard.
The FrodoKEM cryptographic mechanism shall be implemented according to
the guidelines provided in the final ISO standard.

• The tester shall perform the following cryptographic evaluation test:

CCN-AGREED/KeyEstablishment Inputs

In the case of CL1 evaluations, verify in I1 that:

- The scheme used for the key establishment cryptographic
constructions implemented by the TOE is considered as
agreed upon according to Table 26.
I1
- The key establishment cryptographic constructions
implemented by the TOE comply with the specific notes. I2
In the case of CL2 evaluations, operate the TOE (using I2) to verify I6
the above-mentioned.
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned.

Centro Criptológico Nacional 95

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

3.3.1.1.5 Random Number Generators

148. A random number generator (RNG) is composed of a true random number
generator, which generates unpredictable digital data, and a deterministic
component that processes this data to produce the RNG's output sequence
(internal random numbers).
149. The standards AIS 20 and AIS 31 contain guidelines and requirements developed
by the German Federal Office for Information Security (BSI) for the testing and
evaluation of DRNGs and TRNGs. These guidelines provide a comprehensive
framework for assessing the quality, security, and randomness of the output
produced by RNGs.
150. Both standards are based on the document “A Proposal for Functionality Classes
for Random Number Generators”, referred to in this methodology as [FCRNG].
This defines various functionality classes, organizing and specifying the
requisites that both, Deterministic and True Random Number Generators must
adhere to.
151. As will be explained in the following sections, CCN requires that the RNGs
employed by the TOE comply with the requirements specified in the
mathematical-technical reference document [FCRNG].
Note: The mathematical-technical document [FCRNG] is currently being updated by
the BSI, this guide refers to versions of the document as of June 2023 onward.

3.3.1.1.5.1 True Random Number Generators

152. A TRNG is a device or mechanism for which the output random values depend
on an entropy source; a source of unpredictable data. A distinction is made
between physical true random number generators (PTRNG) and non-physical
true random number generators (NPTRNG). In most cases, it is necessary to
employ deterministic post-processing of the digitized digital noise data as
acquired from the source (raw noise data), aiming to eliminate any bias or
dependence on the random output distribution.
153. A TRNG can be understood as a probabilistic procedure that provides random
bits. The main objective when evaluating a TRNG is to obtain an estimate of the
entropy per bit that the TRNG is capable of producing, which is a measure of the
unpredictability of the random distribution on which the TRNG is based. An ideal
TRNG would produce 1 bit of Shannon entropy per bit.
154. In case the TOE makes use of random number generation:
• The TOE shall only make use of True Random Number Generators for which the
average entropy per internal random bit, ℎ𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 , fulfills the following conditions:
- In the case of PTRNGs, the average Shannon entropy per internal random
bit is greater or equal to 0.9998 or the min-entropy per internal random
bit is greater or equal to 0.98.

Centro Criptológico Nacional 96

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

- In the case of NPTRNGs, the min-entropy per internal random bit is

greater or equal to 0.98.

Note 52 [TRNG Use] CL2 and CL3

Due to the difficulty of evaluating the quality of a true random source, its use
should be limited to obtaining the seed and optionally reseeding a
deterministic random number generator.

• The tester shall perform the following cryptographic evaluation test:

CCN-AGREED/TRNGEntropy Inputs

In the case of CL2 and CL3 evaluations, verify using I8 that:

- The average entropy per internal random bit, ℎ𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 , fulfills
the following conditions:
 In the case of PTRNGs, the average Shannon entropy
per internal random bit is greater or equal to 0.9998 or
the min-entropy per internal random bit is greater or
equal to 0.98. I8

 In the case of NPTRNGs, the min-entropy per internal

random bit is greater or equal to 0.98.

Note: In order to verify this test, the tester shall perform the
CCN-AGREED/PTRNG or the CCN-AGREED/NPTRNG evaluation
tests.

Note: The internal random bits refer to the final stage of the random bits of
an RNG that are ready to be output. For TRNGs, this means random bits after
post-processing.

3.3.1.1.5.1.1 Physical True Random Number Generators

155. A physical true random number generator (PTRNG) is based on an entropy
source that exploits physical phenomena (thermal noise, shot noise, jitter,
metastability, radioactive decay, etc.) from dedicated hardware designs (using
diodes, ring oscillators, etc.) or physical experiments to produce digitized
random data. In many cases, it is necessary to use a deterministic post-
processing of the digitally captured noise data obtained from the source (raw
noise data) in order to eliminate any bias or dependency.

Centro Criptológico Nacional 97

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

156. In case the TOE implements a physical true random number generator as TRNG:
• The TOE shall only implement PTRNGs that belong to an agreed AIS-31
functionality class according to the table below and follow the specific notes:

Agreed Physical True Random Number Generators Classes

Functionality Class R/L Notes
PTG.3 Note 52
R
[FCRNG] Note 53
PTG.2 Note 52
R
[FCRNG] Note 53

Table 27. Agreed Physical True Random Number Generators Classes

Note 53 [PTRNG Evaluation] CL2 and CL3

The PTRNG functionality classes defined in the [FCRNG] technical reference

(PTG.2 and PTG.3) are nothing more than a set of requirements; if a PTRNG
meets all of them, then it belongs to that functionality class.
In order to prove that a PTRNG belongs to a certain functionality class, the TOE
shall meet the requirements for functionality class PTG.2 or PTG.3.

• The tester shall perform the following cryptographic evaluation test:

CCN-AGREED/PTRNG Inputs

In the case of CL2 and CL3 evaluations, verify in I1 that:

- The physical true random number generators
implemented by the TOE belong to one of the agreed AIS-
31 PTRNG functionality classes according to Table 27.
- The physical true random number generators
implemented by the TOE comply with the specific notes.
In addition, the tester shall perform a full evaluation against the
AIS-31 requirements defined in the [FCRNG] technical reference I1
for all the PTRNGs implemented by the TOE. I8
To do so, the tester shall:
1) Verify that, for each PTRNG defined in I1, the vendor has
provided in I8 all the required evidence.
2) Verify that all the data used by the vendor to perform
statistical tests have been outputted by the PTRNG
implemented by the TOE. This can be done by performing
a witnessing session.

Centro Criptológico Nacional 98

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-AGREED/PTRNG Inputs
3) Repeat all statistical tests performed by the vendor and
check that the results are valid.
4) Verify that the Stochastic Model provided in I8 is
mathematically sound, that the model starts from the
analog noise source, that the digitalization is properly
assessed, and that the derived entropy bound is derived
from the model. For this purpose, the tester shall follow all
the derivation steps and mathematical arguments given by
the vendor and check their validity.
5) Verify that the Stochastic Model conforms to the real
PTRNG behavior. For this purpose, the tester shall
reproduce the verification method employed by the
vendor and consider it sufficient.
6) Verify that the Online Test is tailored to the Stochastic
Model.
7) Verify all the AIS-31 requirements for PTG.2 or PTG.3 using
I8. For this purpose, the tester may ask the vendor for
more pieces of evidence, if needed.
Note: The successful verification of this test implies the successful
verification of the CCN-AGREED/TRNGEntropy evaluation test.
The inverse is not true.

3.3.1.1.5.1.2 Non-Physical True Random Number Generators

157. Just like in PTRNGs, NPTRNGs also generate truly random numbers, so they must
produce sufficient entropy, but they do not use dedicated hardware. Instead,
they utilize specific system resources (such as system time, RAM content, etc.)
or interactions with the user (like mouse movement, keyboard input timing,
etc.).
158. In case the TOE implements a non-physical true random number generator as
TRNG:
• The TOE shall only implement NPTRNGs that belong to an agreed AIS-31
functionality class according to the table below and follow the specific notes:

Agreed Non-Physical True Random Number Generators Classes

Functionality Class R/L Notes
NTG.1 Note 52
R
[FCRNG] Note 54

Table 28. Agreed Non-Physical True Random Number Generators Classes

Centro Criptológico Nacional 99

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Note 54 [NPTRNG Evaluation] CL2 and CL3

The NPTRNG functionality classes defined in the [FCRNG] technical reference

(NTG.1) are nothing more than a set of requirements; if an NPTRNG meets all
of them, then it belongs to NTG.1.
In order to prove that an NPTRNG belongs to NTG.1, the TOE shall meet the
requirements for functionality class NTG.1.

• The tester shall perform the following cryptographic evaluation test:

CCN-AGREED/NPTRNG Inputs

In the case of CL2 and CL3 evaluations, verify in I1 that:

- The non-physical true random number generators
implemented by the TOE belong to one of the agreed AIS-
31 NPTRNG functionality classes according to Table 28.
- The non-physical true random number generators
implemented by the TOE comply with the specific notes.
In addition, the tester shall perform a full evaluation against the
AIS-31 requirements defined in the [FCRNG] technical reference
for all the NPTRNGs implemented by the TOE.
To do so, the tester shall:
1) Verify that, for each NPTRNG defined in I1, the vendor has
provided in I8 all the required evidence.
I1
2) Verify that all the data used by the vendor to perform
I8
statistical tests have been outputted by the NPTRNG
implemented by the TOE. This can be done by performing
a witnessing session.
3) Repeat all statistical tests performed by the vendor and
check that the results are valid.
4) Verify that the theoretical description and justification for
entropy estimates provided in I8 are mathematically
sound. For this purpose, the tester shall follow all the
derivation steps and mathematical and heuristic
arguments given by the vendor and check their validity.
5) Verify all the AIS-31 requirements for NTG.1 using I8. For
this purpose, the tester may ask the vendor for more
pieces of evidence, if needed.

Centro Criptológico Nacional 10

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-AGREED/NPTRNG Inputs
Note: The successful verification of this test implies the successful
verification of the CCN-AGREED/TRNGEntropy cryptographic test.
The inverse is not true.

3.3.1.1.5.2 Deterministic Random Number Generators

159. The output of a TRNG shall be processed by a Deterministic Random Number
Generator (DRNG). This is a (deterministic) cryptographic construction, built
around an internal state, that can be seeded and refreshed by the output of
random sources, and from which (pseudo-)random bits can be extracted.
160. In the case of functionality classes PTG.3 and NTG.1, their post-processing
functions are required to be DRG.3 compliant DRNGs. So they can be seen as
“hybrid RNGs” that already contain a DRNG.
161. Similarly to the case of TRNGs, the BSI's AIS-20 standard defines requirements
for deterministic random number generators (DRNGs). The technical reference
[FCRNG] organizes DRNG requirements into various functionality classes.
162. In case the TOE implements random number generation:
• The TOE shall only implement DRNGs that belong to an agreed AIS-20
functionality class according to the table below and follow the specific notes:

Agreed Deterministic Random Number Generator Classes

Functionality Class R/L Notes
DRG.3
R Note 55
[FCRNG]
DRG.4
R Note 55
[FCRNG]

Table 29. Agreed Deterministic Random Number Generator Classes

Note 55 [DRNG Evaluation] CL2 and CL3

The DRNG functionality classes defined in the [FCRNG] technical reference

(DRG.3 and DRG.4) are nothing more than a set of requirements; if a DRNG
meets all of them, then it belongs to that functionality class.
In order to prove that a DRNG belongs to a certain functionality class, the TOE
shall meet the requirements for functionality class DRG.3 or DRG.4.

• The tester shall perform the following cryptographic evaluation test:

Centro Criptológico Nacional 10

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-AGREED/DRNG Inputs

In the case of CL2 and CL3 evaluations, verify in I1 that:

- The deterministic random number generators
implemented by the TOE belong to one of the agreed AIS-
20 DRNG functionality classes according to Table 29.
- The deterministic random number generators
implemented by the TOE comply with the specific notes.
In addition, the tester shall perform a full evaluation against the
I1
AIS-20 requirements defined in the [FCRNG] technical reference
for all the DRNGs implemented by the TOE. I8
To do so, the tester shall verify all the AIS-20 requirements for
DRG.3 or DRG.4 using I8.
Note: If the DRNG scheme is HMAC-DRBG or Hash-DRBG and
complies with the specific notes (Note 56 or Note 57 respectively),
it can be considered as a DRG.3 deterministic random number
generator. Therefore, no additional verification will be required to
accomplish this test.

163. On the other hand, some of the most employed DRNG schemes are Hash-DRBG,
HMAC-DRBG, and CTR-DRBG from [SP800-90A]. For Hash-DRBG and HMAC-
DRBG, the document [FCRNG] provides conformity proofs to the functionality
class DRG.3 under certain conditions. Such conformity proof does not exist for
CTR-DRBG, which means its evaluation process would be more time-consuming.
164. It shall be noted that HMAC-DRBG and Hash-DRBG can be proven to be AIS-20
compliant by the BSI. Thus, it is highly recommended to use them in CL2 and CL3
levels, as it is not known whether CTR-DRBG can be regarded as AIS-20
compliant.
165. In case the TOE implements an [SP800-90A] compliant DRNG:
• The TOE shall only implement agreed deterministic random number generator
schemes according to the table below and follow the specific notes:

Agreed Deterministic Random Number Generator Schemes

Schemes R/L Notes
Note 56
HMAC-DRBG
R Note 58
[SP800-90A] [ISO-18031]
Note 59
Note 57
Hash-DRBG
R Note 58
[SP800-90A] [ISO-18031]
Note 59

Centro Criptológico Nacional 10

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Agreed Deterministic Random Number Generator Schemes

Schemes R/L Notes
CTR-DRBG Note 58
R
[SP800-90A] [ISO-18031] Note 59

Table 30. Agreed Deterministic Random Number Generators

Note 56 [DRNG HMAC-DRBG Conformity Proof] CL2 and CL3

According to the conformity proof described in the technical reference

[FCRNG], if the DRNG implemented by the TOE is the HMAC-DRBG as defined
in the [SP800-90A] and fulfills all of the following conditions:
- The hash primitive used is one of the following: SHA2-256, SHA2-
512/256, SHA2-384, SHA2-512, SHA3-256, SHA3-384 or SHA3-512.
- The entropy_input (seed) (as defined in [SP800-90A]) string consists of
≥ 256 bits that have been generated by a TRNG that is compliant with
class PTG.2, PTG.3 or NTG.1.
Then, HMAC-DRBG can be claimed to belong to the DRG.3 functionality class.

Note 57 [DRNG Hash-DRBG Conformity Proof] CL2 and CL3

According to the conformity proof described in the technical reference

[FCRNG], if the DRNG implemented by the TOE is the Hash-DRBG as defined
in the [SP800-90A] and fulfills all of the following conditions:
- The hash primitive used is one of the following: SHA2-256, SHA2-
512/256, SHA2-384, SHA2-512, SHA3-256, SHA3-384 or SHA3-512.
- The entropy_input (seed) (as defined in [SP800-90A]) string consists of
≥ 256 bits that have been generated by a TRNG that is compliant with
class PTG.2, PTG.3 or NTG.1.
Then, Hash-DRBG can be claimed to belong to the DRG.3 functionality class.

Note 58 [DRNG Seeding] CL2 and CL3

The security of a DRNG derives from the proper seeding and reseeding of its
internal state, which shall be done using a true random number generator that
belongs to an agreed AIS-31 functionality class as described in the TRNG
section of this methodology.

Centro Criptológico Nacional 10

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Note 59 [DRNG Backtracking Resistance] CL2 and CL3

In systems that aim at providing perfect forward secrecy (PFS), an attacker

who has recovered the current state of the random number generator which
was used in previous key exchanges to produce ephemeral keys will be able
to break the PFS property if it is possible to practically compute past DRNG
outputs from the present state of the DRNG. Therefore, only DRNG which
does not allow such backward computation should be used.

• The tester shall perform the following cryptographic evaluation test:

CCN-AGREED/DRNGScheme Inputs

In the case of CL1 evaluations, verify in I1 that:

- The scheme utilized for the deterministic random number
generation implemented by the TOE is considered as
agreed upon according to Table 30. I1
In the case of CL2 evaluations, operate the TOE (using I2) to verify I2
the above-mentioned and that it complies with the specific notes. I6
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned and that it complies with the specific notes.

3.3.1.1.5.3 Random Number Generators with Specific Distributions

166. Many asymmetric cryptographic mechanisms require generating integers that
follow a specific distribution. For such mechanisms, a random number generator
cannot be used directly since it does not provide the required distribution
directly. Therefore, random generators that offer specific output distributions
must be implemented using random number generators.

3.3.1.1.5.3.1 Random Uniform Modular Distributions

167. In particular, asymmetric mechanisms that require using randomly generated
integers that belong to a specific interval [0, q - 1], where q is usually not a power
of 2, stand out. This is especially relevant when it comes to randomly generating
an element within a finite group whose order is a prime power. In these cases,
the authorized generators are known as modulo q uniform distribution
generators.
168. In case the TOE implements random number generation following a uniform
modular distribution:
• The TOE shall only implement agreed schemes for random uniform modular
distributions according to the table below:

Centro Criptológico Nacional 10

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Agreed Schemes for Random Uniform Modular Distributions

Scheme R/L Notes
Testing Technique
R Note 60
[CCN-STIC-221] Algorithm 1
Extra Random Technique
R Note 60
[CCN-STIC-221] Algorithm 2

Table 31. Agreed Schemes for Random Uniform Modular Distributions

Note 60 [DRNG as Input] CL2 and CL3

Agreed Random Uniform Distribution schemes shall be applied to the output

of an agreed deterministic random number generator. The schemes take a
string of random bits (the output of an agreed DRNG) as input and output a
random integer.

3.3.1.1.5.3.2 Random Prime Number Generation

169. The generation of asymmetric parameters and RSA keys requires to generate
random prime numbers. The generation of random primes adopts the following
strategy: initially an integer of the appropriate size is drawn at random from a
uniform distribution. Then, it is tested whether it satisfies some properties and
a primality test is applied. As long as these tests fail, the candidate integer is
updated and tested anew.
170. In case the TOE implements prime random number generation:
• The TOE shall only implement agreed methods for prime random number
generation according to the table below and follow the specific notes:

Agreed Methods for Prime Random Generation

Method R/L Notes
Method 1 Note 61
[SOGIS-HEP] Append. B.1 R Note 62
[CCN-STIC-221] Algorithm 3 Note 63
Method 2 Note 61
[SOGIS-HEP] Append. B.2 R Note 62
[CCN-STIC-221] Algorithm 4 Note 63

Table 32. Agreed Methods for Prime Random Generation

Centro Criptológico Nacional 10

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Note 61 [Primes from Uniform Distributions] CL2 and CL3

Both prime number generation methods described above make use of agreed
uniform modular distributions as described in section 3.3.1.1.5.3.1 “Random
Uniform Modular Distributions” for the generation of the testing candidate p.

Note 62 [Miller-Rabin as Primality Test] CL2 and CL3

Method 1 and Method 2 for prime number generation entail the use of a
primality test for the testing candidate which is described in the mentioned
algorithms as TestPrime(p).
If the TOE implements prime random generation, the methods shall make use
of the Miller-Rabin algorithm as described, for example, in Algorithm 5 of the
[CCN-STIC-221] guidance for primality testing.

Note 63 [Miller-Rabin Parameters] CL2 and CL3

The Miller-Rabin algorithm shall be implemented according to the following

conditions:
 In addition to the number p to be examined, the algorithm needs a
random value a ∈ {2, 3, ... p − 2}, the so-called basis. This parameter
shall be generated from a uniform modular distribution [2, p-2] by an
approved method (section 3.3.1.1.5.3.1 “Random Uniform Modular
Distributions”). This condition shall be taken into account for each
iteration.
 The number of iterations employed shall be large enough so that the
probability that the testing candidate p is composite is lower than
2-125.

3.3.1.2 CRYPTOGRAPHIC PROTOCOLS IMPLEMENTATION

171. This second topic defines the cryptographic evaluation tests to verify that each
cryptographic protocol and its underlying cryptographic mechanisms declared
by the vendor in I1 are considered agreed upon by CCN, in order to fulfill the
CCN-PROTOCOL evaluation task.

3.3.1.2.1 Transport Layer Security Protocol (TLS)

172. The Transport Layer Security (TLS) protocol, previously known as the Secure
Socket Layer (SSL) protocol, is a protocol that enables the protection of
communications over the Internet. This includes secure connections such as
those established through the Hypertext Transfer Protocol Secure (HTTPS) or the
File Transfer Protocol Secure (FTPS), for instance. In essence, the TLS protocol

Centro Criptológico Nacional 10

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

allows for the configuration and use of secure channels between the two parties
in a connection: the client and the server.
173. In case the TOE implements the TLS cryptographic protocol to establish secure
communications:
• The TOE shall only implement agreed TLS versions according to the table below:

Agreed TLS Protocol Versions

Protocol R/L Notes
TLS v1.3
R
[RFC-8446]
TLS v1.2
R
[RFC-5246]

Table 33. Agreed TLS Protocol Versions

• The tester shall perform the following cryptographic evaluation test:

CCN-PROTOCOL/TLS Inputs

In the case of CL1 evaluations, verify in I1 that:

- The version used for the TLS protocol implemented by the
TOE is considered as agreed upon according to Table 33.
- The configuration used for the TLS v1.3 and TLS v1.2
protocol implemented by the TOE is considered as agreed
upon. To be verified:
 Cipher suites
 Key Establishment Mechanisms
 Digital Signature Mechanisms I1
- The TLS protocol configurations implemented by the TOE I2
comply with all the associated specific notes.
I6
- All the underlying cryptographic mechanisms involved in
the TLS protocol implemented by the TOE have been
successfully evaluated in the CCN-AGREED evaluation task.
In the case of CL2 evaluations, operate the TOE (using I2) to verify
the above-mentioned. In addition, verify that the TLS protocol
configuration implemented by the TOE matches with those
declared by the vendor in I1.
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned. In addition, verify that the TLS protocol configuration

Centro Criptológico Nacional 10

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-PROTOCOL/TLS Inputs
implemented by the TOE matches with those declared by the
vendor in I1.

3.3.1.2.1.1 TLS v1.3

174. The convention followed for TLS v1.3 cipher suites is TLS_ENC_Long_Mod_Hash,
where ENC represents the encryption system, Long is the key length considered,
Mod is the encryption mode, and Hash refers to the hash function considered.
175. In case the TOE implements the TLS v1.3 cryptographic protocol:
• The TOE shall only implement agreed TLS v1.3 cipher suites according to the
table below:

Agreed TLS v1.3 Protocol Cipher Suites

Code Cipher Suite R/L Notes
TLS_AES_256_GCM_SHA384
0x1302 R
[RFC-8446]
TLS_AES_128_GCM_SHA256
0x1301 R
[RFC-8446]
TLS_AES_128_CCM_SHA256
0x1304 R
[RFC-8446]
TLS_CHACHA20_POLY1305_SHA256
0x1303 R
[RFC-7905]

Table 34. Agreed TLS v1.3 Protocol Cipher suites

176. In addition to the Diffie-Hellman key agreement over finite fields or elliptic
curves, TLS v1.3 offers additional handshake protocol modes using Pre-Shared
Keys (PSK). In this context, PSK refers to keys that are provided out of band or to
keying material that has been established in a previous session through the
session ticket mechanism.
177. In case the TOE implements the TLS v1.3 key establishment based on Pre-Shared
Keys (PSK):
• The TOE shall only implement agreed PSK modes according to the table below
and follow the specific notes:

Agreed TLS v1.3 Pre-Shared keys modes

Code Mode R/L Notes
psk_ke Note 64
0x0000 L[2026]
[RFC-8446] Note 65

Centro Criptológico Nacional 10

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Agreed TLS v1.3 Pre-Shared keys modes

Code Mode R/L Notes
psk_dhe_ke
0x0001 R Note 65
[RFC-8446]

Table 35. Agreed TLS v1.3 PSK modes

Note 64 [psk_ke mode] CL1, CL2 and CL3

The PSK mode “psk_ke” does not provide perfect persistent forward secrecy.

Note 65 [0-RTT Data] CL1, CL2 and CL3

TLS v1.3 offers an option to include application data in the first message of a
PSK protocol, known as zero Round-Trip Time data or 0-RTT data. These data
are not protected against replay attacks, so it is not recommended to send or
accept this type of data.

178. There are some extensions for the TLS v1.3 protocol that will be shown below,
and they relate to the groups that can be used for key establishment, signature
algorithms, etc.
o The client and the server can use the “supported_groups” extension to
inform each other about the Diffie-Hellman groups they wish to use for
(EC)DHE.
o The client and the server can utilize the “signature_algorithms” and
“signature_algorithms_cert” extensions to mutually convey their desired
signature algorithms for certificate-based authentication. The
“signature_algorithms” extension pertains to signatures generated by
the client or server for their CertificateVerify message, whereas the
“signature_algorithms_cert” extension pertains to signatures on
certificates.
179. In case the TOE implements DH or ECDH for the “supported_groups” extension
to perform key establishment procedures in TLS v1.3 protocol:
• The TOE shall only implement agreed DH or ECDH groups according to the table
below:

Agreed TLS v1.3 Diffie-Hellman Groups

Code DH / ECDH Group R/L Notes
ffdhe2048
0x0100 L[2025]
[RFC-7919]

Centro Criptológico Nacional 10

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Agreed TLS v1.3 Diffie-Hellman Groups

Code DH / ECDH Group R/L Notes
ffdhe3072
0x0101 R
[RFC-7919]
ffdhe4096
0x0102 R
[RFC-7919]
P-256 (secp256r1)
0x0017 R
[RFC-8422]
P-384 (secp384r1)
0x0018 R
[RFC-8422]
P-521 (secp521r1)
0x0019 R
[RFC-8422]
BrainpoolP256r1tls13
0x001F R
[RFC-8734]
BrainpoolP384r1tls13
0x0020 R
[RFC-8734]
BrainpoolP512r1tls13
0x0021 R
[RFC-8734]
x25519
0x001D R
[RFC-8422] [RFC-7748]
x448
0x001E R
[RFC-8422] [RFC-7748]

Table 36. Agreed TLS v1.3 Diffie-Hellman Groups

180. In case the TOE implements digital signature cryptographic constructions for the
“signature_algorithms” extension to perform client-server digital signature
operations in TLS v1.3 protocol:
• The TOE shall only implement agreed digital signature schemes according to the
table below:

Agreed TLS v1.3 Server-Client Digital Signature Schemes

Code Signature Mechanism R/L Notes
rsa_pss_rsae_sha256
0x0804 R
[RFC-8446]
rsa_pss_rsae_sha384
0x0805 R
[RFC-8446]
rsa_pss_rsae_sha512
0x0806 R
[RFC-8446]

Centro Criptológico Nacional 11

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Agreed TLS v1.3 Server-Client Digital Signature Schemes

Code Signature Mechanism R/L Notes
ed25519
0x0807 R
[RFC-8446]
ed448
0x0808 R
[RFC-8446]
rsa_pss_pss_sha256
0x0809 R
[RFC-8446]
rsa_pss_pss_sha384
0x080A R
[RFC-8446]
rsa_pss_pss_sha512
0x080B R
[RFC-8446]
ecdsa_secp256r1_sha256
0x0403 R
[RFC-8446]
ecdsa_secp384r1_sha384
0x0503 R
[RFC-8446]
ecdsa_secp521r1_sha512
0x0603 R
[RFC-8446]
ecdsa_brainpoolP256r1tls13_sha256
0x081A R
[RFC-8734]
ecdsa_brainpoolP384r1tls13_sha384
0x081B R
[RFC-8734]
ecdsa_brainpoolP512r1tls13_sha512
0x081C R
[RFC-8734]

Table 37. Agreed TLS v1.3 Server-Client Digital Signature Schemes

181. In case the TOE implements digital signature cryptographic constructions for the
“signature_algorithms_cert” extension to perform digital signature operations
on certificates in TLS v1.3 protocol:
• The TOE shall only implement agreed digital signature schemes according to the
table below:

Agreed TLS v1.3 Digital Signature Schemes on Certificates

Code Signature Mechanism R/L Notes
rsa_pkcs1_sha256
0x0401 L[2025]
[RFC-8446]
rsa_pkcs1_sha384
0x0501 L[2025]
[RFC-8446]

Centro Criptológico Nacional 11

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Agreed TLS v1.3 Digital Signature Schemes on Certificates

Code Signature Mechanism R/L Notes
rsa_pkcs1_sha512
0x0601 L[2025]
[RFC-8446]
rsa_pss_rsae_sha256
0x0804 R
[RFC-8446]
rsa_pss_rsae_sha384
0x0805 R
[RFC-8446]
rsa_pss_rsae_sha512
0x0806 R
[RFC-8446]
ed25519
0x0807 R
[RFC-8446]
ed448
0x0808 R
[RFC-8446]
rsa_pss_pss_sha256
0x0809 R
[RFC-8446]
rsa_pss_pss_sha384
0x080A R
[RFC-8446]
rsa_pss_pss_sha512
0x080B R
[RFC-8446]
ecdsa_secp256r1_sha256
0x0403 R
[RFC-8446]
ecdsa_secp384r1_sha384
0x0503 R
[RFC-8446]
ecdsa_secp521r1_sha512
0x0603 R
[RFC-8446]
ecdsa_brainpoolP256r1tls13_sha256
0x081A R
[RFC-8734]
ecdsa_brainpoolP384r1tls13_sha384
0x081B R
[RFC-8734]
ecdsa_brainpoolP512r1tls13_sha512
0x081C R
[RFC-8734]

Table 38. Agreed TLS v1.3 Digital Signature Algorithms on Certificates

3.3.1.2.1.2 TLS v1.2

182. In the TLS v1.2 version, the cryptographic mechanisms of a connection are
defined by a cryptographic suite that specifies a key establishment mechanism

Centro Criptológico Nacional 11

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

(with authentication) for the TLS Handshake protocol, an authenticated

encryption mechanism for the TLS Record protocol, and a hash function for the
key derivation process. Depending on the cipher suite, a group for the Diffie-
Hellman key establishment must also be specified, either in a subgroup of a finite
field or in an elliptic curve over a finite field, and a digital signature construction.
183. For these cipher suites, the following notation is typically used:
TLS_AKE_WITH_ENC_Hash, where AKE denotes a key establishment mechanism
(with authentication), ENC is an encryption algorithm including its key length and
mode of operation, and Hash refers to the hash function. The hash function is
used for an HMAC that is used in a pseudo-random function (PRF), which is used
for key derivation. In the case where the system under consideration uses the
CCM mode of operation, no hash function is indicated and it is assumed that it
uses SHA2-256 as the underlying hash function for the PRF. If ENC were not an
authenticated encryption cryptographic construction, then HMAC is also used
for integrity protection in the TLS Record protocol.
184. In case the TOE implements the TLS v1.2 cryptographic protocol:
• The TOE shall only implement agreed TLS v1.2 cipher suites according to the
table below and follow the specific notes:

Agreed TLS v1.2 Protocol Cipher Suites

Code Cipher Suite R/L Notes
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_
0xC02C R
SHA384 [RFC-5289]
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_
0xC02B R
SHA256 [RFC-5289]
TLS_ECDHE_ECDSA_WITH_AES_256_CCM
0xC0AD R
[RFC-7251]
TLS_ECDHE_ECDSA_WITH_AES_128_CCM
0xC0AC R
[RFC-7251]
TLS_ECDHE_ECDSA_WITH_CHACHA20_
0xCCA9 R
POLY1305_SHA256 [RFC-7905]
TLS_ECDHE_RSA_WITH_AES_256_GCM_
0xC030 L
SHA384 [RFC-5289]
TLS_ECDHE_RSA_WITH_AES_128_GCM_
0xC02F L
SHA256 [RFC-5289]
TLS_ECDHE_RSA_WITH_CHACHA20_
0xCCA8 L
POLY1305_SHA256 [RFC-7905]
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_
0xC024 L[2025] Note 66
SHA384 [RFC-5289]

Centro Criptológico Nacional 11

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Agreed TLS v1.2 Protocol Cipher Suites

Code Cipher Suite R/L Notes
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_
0xC023 L[2025] Note 66
SHA256 [RFC-5289]
TLS_ECDHE_RSA_WITH_AES_256_CBC_
0xC028 L[2025] Note 66
SHA384 [RFC-5289]
TLS_ECDHE_RSA_WITH_AES_128_CBC_
0xC027 L[2025] Note 66
SHA256 [RFC-5289]
TLS_DHE_RSA_WITH_AES_256_GCM_
0x009F L
SHA384 [RFC-5288]
TLS_DHE_RSA_WITH_AES_128_GCM_
0x009E L
SHA256 [RFC-5288]
TLS_DHE_RSA_WITH_AES_256_CCM
0xC09F L
[RFC-6655]
TLS_DHE_RSA_WITH_AES_128_CCM
0xC09E L
[RFC-6655]
TLS_DHE_RSA_WITH_AES_256_CBC_
0x006B L[2025] Note 66
SHA256 [RFC-5246]
TLS_DHE_RSA_WITH_AES_128_CBC_
0x0067 L[2025] Note 66
SHA256 [RFC-5246]
0x009D TLS_RSA_WITH_AES_256_GCM_SHA384 L Note 67
0x009C TLS_RSA_WITH_AES_128_GCM_SHA256 L Note 67
0xC09D TLS_RSA_WITH_AES_256_CCM L Note 67
0xC09C TLS_RSA_WITH_AES_128_CCM L Note 67
Note 66
0x003D TLS_RSA_WITH_AES_256_CBC_SHA256 L[2025]
Note 67
Note 66
0x003C TLS_RSA_WITH_AES_128_CBC_SHA256 L[2025]
Note 67
TLS_DHE_RSA_WITH_CHACHA20_
0xCCAA L
POLY1305_SHA256 [RFC-7905]
TLS_DHE_DSS_WITH_AES_256_CBC_
0x006A L
SHA256 [RFC-5246]
TLS_DHE_DSS_WITH_AES_256_GCM_
0x00A3 L
SHA384 [RFC-5288]

Table 39. Agreed TLS v1.2 Protocol Cipher Suites

Centro Criptológico Nacional 11

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Note 66 [TLS Encrypt and then MAC] CL1, CL2 and CL3

TLS cryptographic suites whose encryption mechanisms are based on CBC

shall be used in conjunction with the “encrypt_then_mac” extension.

Note 67 [TLS with RSA] CL1, CL2 and CL3

Key exchange with RSA does not provide Perfect Forward Secrecy (PFS).

185. In case the TOE implements the TLS v1.2 cryptographic protocol using cipher
suites with Pre-Shared Key (PSK) mode:
• The TOE shall only implement agreed TLS v1.2 cipher suites with Pre-Shared Key
(PSK) mode according to the table below:

Agreed TLS v1.2 Protocol Cipher Suites with PSK

Code Cipher Suite R/L Notes
TLS_ECDHE_PSK_WITH_AES_128_CBC_
0xC037 R
SHA256 [RFC-5489]
TLS_ECDHE_PSK_WITH_AES_256_CBC_
0xC038 R
SHA384 [RFC-5489]
TLS_ECDHE_PSK_WITH_AES_128_GCM_
0xD001 R
SHA256 [RFC-8442]
TLS_ECDHE_PSK_WITH_AES_256_GCM_
0xD002 R
SHA384 [RFC-8442]
TLS_ECDHE_PSK_WITH_AES_128_CCM_
0xD005 R
SHA256 [RFC-8442]
TLS_DHE_PSK_WITH_CHACHA20_
0xCCAD R
POLY1305_SHA256 [RFC-7905]
TLS_DHE_PSK_WITH_AES_128_CBC_
0x00B2 R
SHA256 [RFC-5487]
TLS_DHE_PSK_WITH_AES_256_CBC_
0x00B3 R
SHA384 [RFC-5487]
TLS_DHE_PSK_WITH_AES_128_GCM_
0x00AA R
SHA256 [RFC-5487]
TLS_DHE_PSK_WITH_AES_256_GCM_
0x00AB R
SHA384 [RFC-5487]
TLS_DHE_PSK_WITH_AES_128_CCM
0xC0A6 R
[RFC-6655]

Centro Criptológico Nacional 11

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Agreed TLS v1.2 Protocol Cipher Suites with PSK

Code Cipher Suite R/L Notes
TLS_DHE_PSK_WITH_AES_256_CCM
0xC0A7 R
[RFC-6655]

Table 40. Agreed TLS v1.2 Protocol Cipher Suites with PSK
186. In case the TOE implements DH or ECDH for the “supported_groups” extension
to perform key establishment procedures in TLS v1.2 protocol:
• The TOE shall only implement agreed DH or ECDH groups according to the table
below:

Agreed TLS v1.2 Diffie-Hellman Groups

Code DH / ECDH Group R/L Notes
ffdhe2048
0x0100 L[2025]
[RFC-7919]
ffdhe3072
0x0101 R
[RFC-7919]
ffdhe4096
0x0102 R
[RFC-7919]
P-256 (secp256r1)
0x0017 R
[RFC-8422]
P-384 (secp384r1)
0x0018 R
[RFC-8422]
P-521 (secp521r1)
0x0019 R
[RFC-8422]
BrainpoolP256r1
0x001F R
[RFC-7027]
BrainpoolP384r1
0x0020 R
[RFC-7027]
BrainpoolP512r1
0x0021 R
[RFC-7027]
x25519
0x001D R
[RFC-8422] [RFC-7748]
x448
0x001E R
[RFC-8422] [RFC-7748]

Table 41. Agreed TLS v1.2 Diffie-Hellman Groups

Centro Criptológico Nacional 11

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

187. In case the TOE implements digital signature cryptographic constructions for the
“signature_algorithms” extension in TLS v1.2 protocol:
• The TOE shall only implement agreed digital signature schemes and hash
functions according to the tables below:

Agreed TLS v1.2 Digital Signature Schemes

Code Signature Mechanism R/L Notes
rsa
0x0001 L[2025]
[RFC-5246]
dsa
0x0002 R
[RFC-5246]
ecdsa
0x0003 R
[RFC-5246]
ed25519
0x0007 R
[RFC-8422]
ed448
0x0008 R
[RFC-8422]

Table 42. Agreed TLS v1.2 Digital Signature Schemes

Agreed TLS v1.2 Hash Functions

Code Hash Function R/L Notes
SHA2-256
0x0004 R
[RFC-5246]
SHA2-384
0x0005 R
[RFC-5246]
SHA2-512
0x0006 R
[RFC-5246]

Table 43. Agreed TLS v1.2 Hash Functions

3.3.1.2.2 Secure Shell (SSH)

188. SSH is a cryptographic security protocol originally designed to replace insecure
remote connection protocols such as Telnet. This protocol can be used to
establish a secure channel within an insecure network. The most common
applications of the SSH protocol are logging into a remote system and running
commands or applications on remote systems.
189. The SSH protocol consists of three subprotocols: Transport Layer Protocol, User
Authentication Protocol, and Connection Protocol. The Transport Layer Protocol
allows server authentication, encryption, integrity protection, and optionally
data compression. It is based on the TCP/IP protocol. The User Authentication

Centro Criptológico Nacional 11

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Protocol is used to authenticate the user to the server and is based on the
Transport Layer Protocol. Finally, the Connection Protocol is responsible for
creating and managing logical channels within the encrypted tunnel and is based
on the User Authentication Protocol.
190. In case the TOE implements the SSH cryptographic protocol to establish secure
remote connections:
• The TOE shall only implement the agreed SSH version according to the table
below:

Agreed SSH Protocol Version

Protocol R/L Notes
SSH-2
R
[RFC-4251]

Table 44. Agreed SSH Protocol Version

• The tester shall perform the following cryptographic evaluation test:

CCN-PROTOCOL/SSH Inputs

In the case of CL1 evaluations, verify in I1 that:

- The version used for the SSH protocol implemented by the
TOE is considered as agreed upon according to Table 44.
- The configuration used for the SSH protocol implemented
by the TOE is considered as agreed upon. To be verified:
 Key Establishment Mechanisms
 Encryption Mechanisms
 Origin Integrity and Authenticity Mechanisms
 Server-Client Authentication Mechanisms I1
- The SSH protocol configurations implemented by the TOE I2
comply with all the associated specific notes. I6
- All the underlying cryptographic mechanisms involved in
the SSH protocol implemented by the TOE have been
successfully evaluated in the CCN-AGREED evaluation task.
In the case of CL2 evaluations, operate the TOE (using I2) to verify
the above-mentioned. In addition, verify that the SSH protocol
configuration implemented by the TOE matches with those
declared by the vendor in I1.
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned. In addition, verify that the SSH protocol configuration

Centro Criptológico Nacional 11

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-PROTOCOL/SSH Inputs
implemented by the TOE matches with those declared by the
vendor in I1.

3.3.1.2.2.1 SSH Key Establishment

191. The key exchange mechanism of the SSH protocol is based on Diffie-Hellman. In
fact, there are several recommended groups, all of them using the SHA2-512
function.
192. Regarding the DH or ECDH mechanisms implemented by the TOE for the key
establishment of the SSH protocol:
• The TOE shall only implement agreed DH or ECDH groups according to the table
below and follow the specific notes:

Agreed SSH Diffie-Hellman Groups

DH / ECDH Group R/L Notes
DH-exchange-SHA256 Note 68
R
[RFC-4419] Note 69
DH-group15-SHA512
R Note 69
[RFC-3526]
DH-group16-SHA512
R Note 69
[RFC-3526]
DH-group17-SHA512
R Note 69
[RFC-3526]
DH-group18-SHA512
R Note 69
[RFC-3526]
ECDH-SHA2-* Note 69
R
[RFC-5656] Note 70

Table 45. Agreed SSH Diffie-Hellman Groups

Note 68 [Diffie-Hellman-group-exchange-SHA256] CL2 and CL3

The size of the prime number to be used, p, should be at least 3000 bits.
Additionally, the order of the generator should have a size of at least 2250.
Finally, p should be a safe prime. Remember that a safe prime, p, is a prime of
the form p = 1 + 2q, where q is another prime. Therefore, the order of the
generator g can only be a divisor of p − 1 = 2 · q, which means it can either be
2 or q. This implies that the size of q should be much larger than the
recommended minimum of 2250 for the order of g.

Centro Criptológico Nacional 11

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Note 69 [Key Renewal] CL2 and CL3

In order to further complicate attacks against session keys, it is recommended

to renew the key used in a connection after a certain period or a certain
amount of transmitted data. With SSH, this process can be initiated by both
the client and the server by sending the SSH_MSG_KEXINIT message.
Therefore, session keys should be renewed after one hour or after one
gigabyte of data has been transmitted, whichever occurs first.

Note 70 [ECDH-SHA2-*] CL1, CL2 and CL3

The ECDH key exchange is defined by a family of method names. Each method
name is the concatenation of the string “ECDH-SHA2-” with the domain
parameter of the corresponding elliptic curve. The agreed-upon elliptic curves
are as follows: secp256r1, secp384r1, and secp521r1. The agreed-upon hash
function is the SHA2-512.

3.3.1.2.2.2 SSH Encryption Mechanisms

193. Regarding the encryption and decryption mechanisms implemented by the TOE
for the SSH protocol:
• The TOE shall only implement agreed encryption mechanisms according to the
table below and follow the specific notes:

Agreed SSH Encryption Mechanisms

Encryption Mechanism R/L Notes
AEAD_AES_128_GCM
R Note 71
[RFC-5647]
AEAD_AES_256_GCM
R Note 71
[RFC-5647]
AES128-CTR
R Note 71
[RFC-4344]
AES192-CTR
R Note 71
[RFC-4344]
AES256-CTR
R Note 71
[RFC-4344]

Table 46. Agreed SSH Encryption Mechanisms

Centro Criptológico Nacional 12

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Note 71 [Security Statement] CL1, CL2 and CL3

To the extent possible, the AEAD_AES_128_GCM and AEAD_AES_256_GCM

algorithms should be used because there are verifiable security statements
for the GCM mode concerning the security goal of authenticated encryption.
If unauthenticated encryption is chosen (i.e., AES-CTR), it will be mandatory
to use one of the recommended options to protect the integrity and
authenticity of messages (i.e., HMAC-SHA2).

3.3.1.2.2.3 SSH Origin Integrity and Authenticity Mechanisms

194. Regarding the origin integrity and authenticity mechanisms implemented by the
TOE for the SSH protocol:
• The TOE shall only implement agreed origin integrity and authenticity
mechanisms according to the table below:

Agreed SSH Origin Integrity and Authenticity Mechanisms

Scheme R/L Notes
HMAC-SHA1
L[2030]
[RFC-4253]
HMAC-SHA2-256
R
[RFC-4344]
HMAC-SHA2-512
R
[RFC-4344]
AEAD_AES_128_GCM
R
[RFC-5647]
AEAD_AES_256_GCM
R
[RFC-5647]

Table 47. Agreed SSH Origin Integrity and Authenticity Mechanisms

3.3.1.2.2.4 SSH Server and Client Authentication Mechanisms

195. Regarding server-client authentication mechanisms implemented by the TOE for
the SSH protocol:
• The TOE shall only implement agreed server-client authentication mechanisms
according to the table below and follow the specific notes:

Agreed SSH Server-Client Authentication Mechanisms

Scheme R/L Notes
ECDSA-SHA2-*
R Note 72
[RFC-5656]

Centro Criptológico Nacional 12

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Agreed SSH Server-Client Authentication Mechanisms

Scheme R/L Notes
x509v3-ECDSA-SHA2-*
R Note 73
[RFC-6187]

Table 48. Agreed SSH Server-Client Authentication Mechanisms

Note 72 [ECDSA-SHA2-*] CL1, CL2 and CL3

The ECDSA scheme is defined by a family of method names. Each method

name is the concatenation of the string “ECDSA-SHA2-” with the domain
parameter of the corresponding elliptic curve. The agreed-upon elliptic curves
are as follows: secp256r1, secp384r1, and secp521r1.

Note 73 [x509v3-ECDSA-SHA2-*] CL1, CL2 and CL3

The x509v3-ECDSA scheme is defined by a family of method names. Each

method name is the concatenation of the string “x509v3-ECDSA-SHA2-” with
the domain parameter of the corresponding elliptic curve. The agreed-upon
elliptic curves are as follows: secp256r1, secp384r1, and secp521r1.

3.3.1.2.3 Internet Protocol Security (IPsec) with IKEv2

196. The most important use of IPsec is to create Virtual Private Networks or VPNs,
which means establishing secure communication channels over insecure IP
networks. IPsec is a standard that provides security at the network layer of the
Internet Protocol (IP) in the TCP/IP protocol stack (Transmission Control
Protocol/Internet Protocol). Unlike TLS and SSH protocols, IPsec provides
security at higher layers, including the application layer.
197. In case the TOE implements the IPsec cryptographic protocol to establish secure
remote connections:
• The TOE shall only implement agreed IPsec versions according to the table below
and follow the specific notes:

Agreed IPsec Protocol Versions

Protocol R/L Notes
IPsec Note 74
R
[RFC-8221] Note 75
IKEv2
R Note 74
[RFC-7296] [RFC-8247]
ESP Note 74
R
[RFC-4303] Note 75

Centro Criptológico Nacional 12

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Table 49. Agreed IPsec Protocol Versions

Note 74 [Tunnel Mode – Transport Mode] CL2 and CL3

IPsec can be deployed in tunnel mode and transport mode. In tunnel mode,
the entire IP packet is cryptographically protected, while in transport mode,
the original IP packet header is preserved, and some security fields are added.
It can be stated that tunnel mode provides more security than transport
mode, so the former should be used before the latter. Transport mode is
justified only if packet size becomes problematic due to network-imposed
restrictions.

Note 75 [IPsec Attacks] CL1, CL2 and CL3

There are known attacks when IPsec is implemented in any MAC-then-Encrypt

configuration (such as using AH in transport mode before ESP with only
encryption in tunnel mode). However, no attacks are known against IPsec
when using ESP with only encryption followed by AH or ESP with authenticity
and integrity protection without another AH following it. Therefore, it is
recommended to use ESP with integrity and authenticity protection options in
addition to confidentiality.

• The tester shall perform the following cryptographic evaluation test:

Centro Criptológico Nacional 12

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-PROTOCOL/IPsec Inputs

In the case of CL1 evaluations, verify in I1 that:

- The versions used for the IPsec protocol implemented by
the TOE are considered as agreed upon according to Table
49.
- The configuration used for the IPsec protocol implemented
by the TOE is considered as agreed upon. To be verified:
 IKEv2 Key Establishment Mechanisms
 IKEv2 and ESP Encryption Mechanisms
 IKEv2 and ESP Origin Integrity and Authenticity
Mechanisms
 IKEv2 and ESP Pseudo-Random Functions
I1
 IKEv2 Authentication Mechanisms
I2
- The IPsec protocol configurations implemented by the TOE
comply with all the associated specific notes. I6
- All the underlying cryptographic mechanisms involved in
the IPsec protocol implemented by the TOE have been
successfully evaluated in the CCN-AGREED evaluation task.
In the case of CL2 evaluations, operate the TOE (using I2) to verify
the above-mentioned. In addition, verify that the IPsec protocol
configuration implemented by the TOE matches with those
declared by the vendor in I1.
In the case of CL3 evaluations, operate the TOE (using I2) and
perform a source code review (using I6) to verify the above-
mentioned. In addition, verify that the IPsec protocol
configuration implemented by the TOE matches with those
declared by the vendor in I1.

3.3.1.2.3.1 IKEv2 Key Establishment

198. The key exchange mechanism used in the IKEv2 protocol is based on Diffie-
Hellman.
199. Regarding the DH or ECDH mechanisms implemented by the TOE for the key
establishment of the IKEv2 protocol:
• The TOE shall only implement agreed DH or ECDH groups according to the table
below:

Centro Criptológico Nacional 12

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Agreed IKEv2 Diffie-Hellman Groups

DH / ECDH Group R/L Notes
3072-bit MODP
R
[RFC-3526]
4096-bit MODP
R
[RFC-3526]
6144-bit MODP
R
[RFC-3526]
8192-bit MODP
R
[RFC-3526]
256-bit random ECP
R
[RFC-5903]
384-bit random ECP
R
[RFC-5903]
521-bit random ECP R
[RFC-5903]
brainpoolP256r1 R
[RFC-6954]
brainpoolP384r1 R
[RFC-6954]
brainpoolP512r1 R
[RFC-6954]
x25519 R
[RFC-8031]
x448 R
[RFC-8031]

Table 50. Agreed IKEv2 Diffie-Hellman Groups

3.3.1.2.3.2 IKEv2 and ESP Encryption Mechanisms

200. Regarding the encryption and decryption mechanisms implemented by the TOE
for the IKEv2 and ESP protocols:
• The TOE shall only implement agreed symmetric encryption cryptographic
constructions (according to Table 12) and agreed authenticated encryption
cryptographic constructions (according to Table 16).

3.3.1.2.3.3 IKEv2 and ESP Origin Integrity and Authenticity Mechanisms

201. Regarding the origin integrity and authenticity mechanisms implemented by the
TOE for the IKEv2 and ESP protocols:

Centro Criptológico Nacional 12

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

• The TOE shall only implement agreed origin integrity and authenticity
mechanisms according to the table below and follow the specific notes:

Agreed IKEv2 and ESP Origin Integrity and Authenticity Mechanisms

MAC Construction R/L Notes
HMAC-SHA2-256_128
R Note 76
[RFC-4868]
HMAC-SHA2-384_192
R Note 76
[RFC-4868]
HMAC-SHA2-512_256
R Note 76
[RFC-4868]
AES-CMAC-96
R
[RFC-4494]
AES-GMAC
R
[RFC-4543]

Table 51. Agreed IKEv2 and ESP Origin Integrity and Authenticity Mechanisms

Note 76 [HMAC-SHA-XXX-YYY] CL1, CL2 and CL3

Each of these schemes uses a fixed key length of XXX bits, truncating the
output to YYY bits.

3.3.1.2.3.4 IKEv2 Pseudo-Random Functions

202. Regarding the pseudo-random functions implemented by the TOE for the IKEv2
protocol key derivation:
• The TOE shall only implement agreed pseudo-random functions according to the
table below:

Agreed IKEv2 Pseudo-Random Functions

MAC Schemes R/L Notes
HMAC-SHA2-256
R
[RFC-4868]
HMAC-SHA2-384
R
[RFC-4868]
HMAC-SHA2-512
R
[RFC-4868]
AES128-CMAC
R
[RFC-4615]

Table 52. Agreed IKEv2 Pseudo-Random Functions

Centro Criptológico Nacional 12

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

3.3.1.2.3.5 IKEv2 Authentication Mechanisms

203. The cryptographic authentication mechanism for IKEv2 is the digital signature,
recommending the use of X.509 certificates.
204. Regarding the authentication mechanisms implemented by the TOE to perform
digital signature operations for the IKEv2 protocol:
• The TOE shall only implement agreed digital signature cryptographic
constructions according to the table below and follow the specific notes:

Agreed IKEv2 Digital Signature Schemes

Signature Mechanism R/L Notes
RSA (RSASSA-PSS)
R Note 77
[RFC-4055]
ECDSA-SHA-256 and P-256
R
[RFC-4754]
ECDSA-SHA-384 and P-384
R
[RFC-4754]
ECDSA-SHA-512 and P-521
R
[RFC-4754]
ECDSA-256-BrainpoolP256r1
R
[RFC-7427]
ECDSA-384-BrainpoolP384r1
R
[RFC-7427]
ECDSA-512-BrainpoolP512r1
R
[RFC-7427]
ECGDSA-256-BrainpoolP256r1
R
[RFC-7427]
ECGDSA-384-BrainpoolP384r1
R
[RFC-7427]
ECGDSA-512-BrainpoolP512r1
R
[RFC-7427]

Table 53. Agreed IKEv2 Digital Signature Schemes

Note 77 [RSASSA-PSS] CL1, CL2 and CL3

This scheme should only be used with PSS and with a SHA-2 family function.

Centro Criptológico Nacional 12

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

4 CONFORMITY TESTING

4.1 OBJECTIVE
205. This chapter defines the conformity testing process for the cryptographic
mechanisms implemented by the TOE to verify the correct operation.
206. Therefore, it provides vendors with the conformity testing requirements that
shall be met by the TOE to perform a correct operation of the cryptographic
mechanisms. In addition, it provides testers with the evaluation task necessary
to verify the correct execution and implementation of the cryptographic
mechanisms during the evaluation process.

4.2 DEFINITIONS
207. The conformity testing process is based on the use of test vectors that will be
used as input to stimulate the operation of the cryptographic mechanisms
implemented in the TOE to obtain their output which will be compared with the
output obtained by the reference implementation to determine the correct
operation of each cryptographic mechanism and for each parameterization
independently.
208. To thoroughly evaluate the functionality of cryptographic implementations,
three types of conformity tests are utilized. These tests provide a comprehensive
assessment of the implementation's behavior, uncovering any potential
weaknesses or deviations from expected results.
Monte Carlo Tests (MCT)
209. The Monte Carlo Test consists of iteratively applying the cryptographic function,
starting from a predefined seed or a randomly generated seed, to test against a
large number of pseudo-random values. In the case of a predefined seed, the
final result is compared to a reference value. When using a randomly generated
seed, the same Monte Carlo Test is run on a reference implementation (using
the same seed), and the final results of both are then compared.
210. Monte Carlo Tests are designed to thoroughly test cryptographic primitives,
including block ciphers, fixed-length input hash functions, modular
exponentiations, EC scalar multiplications, multi-scalar multiplications, etc.
211. To do so, the cryptographic function 𝑓𝑓 is applied to values that are updated by
encoding functions based on previous outputs of 𝑓𝑓.
212. A pseudocode description of the Monte Carlo mechanisms is provided in “Annex
B: Conformity Tests Specification”.
Conformity Known Answer Tests (KATs)
213. The Known Answer Test consists of applying a cryptographic mechanism to a
fixed set of inputs and comparing the output to the expected results. While MCTs
are useful for intensively testing a primitive, conformity KATs are designed to

Centro Criptológico Nacional 12

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

complement them by allowing for more specific testing of a cryptographic

mechanism's behavior.
214. Depending on the type of mechanism, different types of conformity Known
Answer Tests are used:
a) Non-Specific KATs: conformity KATs can include non-specific inputs to
provide a rough check of the implementation's correct performance, which is
especially useful for complex mechanisms like asymmetric constructions that
rely on multiple other primitives.
b) Length Tests: length tests are relevant for mechanisms with variable input or
output lengths, such as hash functions or MAC with truncation. These tests
verify the implementation's chaining mechanism and padding
implementation and ensure that limitations on the range of input length are
being enforced.
c) Corner Cases: while MCTs, non-specific conformity KATs, and length tests all
allow for testing the normal behavior of a mechanism, some corner cases may
not be triggered by chance. These corner cases, including padding
verification, can be tested through the use of specific inputs designed to
trigger them.
Validation Tests (VAL)
215. Validation Tests consist of the generation of a certain number of test vectors by
the vendor and their subsequent verification by the tester. This allows verifying
the correct generation of asymmetric key pairs, the generation of digital
signatures, and the key establishment process.

4.3 CONFORMITY TESTING PROCESS

Generation of Test Vectors
216. In the first step, the tester shall generate a request file (REQ) for each
cryptographic mechanism implemented in the TOE, containing the test vectors
associated with the supported configuration. Additionally, the tester shall
generate a sample file (SAM) for each cryptographic mechanism implemented in
the TOE, containing an example solution to indicate the format of the expected
result.
217. The tester shall send the vendor a file package containing the REQ and SAM files
associated with all the cryptographic mechanisms implemented in the TOE.
Generation of TOE Results
218. In the second step, the vendor shall implement a test harness (I3) to obtain the
response files for all the cryptographic mechanisms implemented in the TOE (I4),
as part of the conformity testing process.
219. The test harness shall receive as input the REQ file associated with a
cryptographic mechanism and shall generate an RSP output file containing the

Centro Criptológico Nacional 12

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

result of the TOE cryptographic operation. The test harness shall maintain the
format presented in the REQ and SAM files for the generation of the RSP file.
220. Using this test harness (I3), the tester shall generate a response file (RSP)
associated with each cryptographic mechanism implemented, which shall
contain the output provided by the TOE for each of the test vectors provided in
the REQ file.
221. The tester shall ensure that the set of methods or functions defined in the test
harness (I3) is complete and performs the appropriate calls to the TOE.
Generation of Results
222. In the third step, the tester shall generate the RSP file associated with each
cryptographic mechanism implemented in the TOE, using the CCN Cryptographic
Tool as the cryptographic reference implementation.
223. The tester shall maintain the format presented in the REQ and SAM files for the
generation of the RSP file.
Validation of Results
224. In the fourth step, the tester shall validate the RSP files for each cryptographic
mechanism implemented in the TOE, comparing the results provided with those
obtained in the previous phase using the CCN Cryptographic Tool.
225. The tester shall determine if the TOE correctly implements the cryptographic
constructions and primitives used and declared.

Figure 1. Conformity Testing Process Flow Diagram

4.4 CRYPTOGRAPHIC EVALUATION TASK

226. This section contains the conformity testing process for all the cryptographic
mechanisms implemented by the TOE that shall be performed by the tester in
order to verify their correct operation.
227. A cryptographic evaluation task related to the conformity testing procedure of
the cryptographic mechanisms implemented has been defined:

Centro Criptológico Nacional 13

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CRYPTOGRAPHIC CERTIFICATION
CCN-CONFORMITY
EVALUATION TASK LEVEL

The tester shall perform the conformity testing process to

verify the correct operation of all the cryptographic
mechanisms implemented by the TOE. CL1, CL2 and
CL3
Note: In the case of CL2 and CL3 evaluations, all
implemented cryptographic mechanisms shall be
verified, even if they are not in use.

228. For the correct completion of the entire evaluation task, it has been assigned to
a cryptographic evaluation test that the tester shall perform for all the
cryptographic mechanisms implemented by the TOE.

Cryptographic Test
Cryptographic Evaluation Test
Evaluation Task Categorization

CCN-CONFORMITY
Cryptographic CCN-
Mandatory
Mechanisms CONFORMITY/Mechanisms
Conformity Testing

Table 54. Cryptographic Evaluation Test defined for CCN Conformity

4.4.1 CRYPTOGRAPHIC EVALUATION TEST DEFINITION

229. This subsection defines the cryptographic evaluation test that shall be
performed by the tester to accomplish the evaluation task, based on the
conformity testing process for each of the cryptographic mechanisms
implemented by the TOE.

4.4.1.1 CRYPTOGRAPHIC MECHANISMS IMPLEMENTATION

230. This topic defines the cryptographic evaluation test to verify the correct
operation of each cryptographic mechanism declared by the vendor in I1, in
order to fulfill the CCN-CONFORMITY evaluation task.
231. For each construction and cryptographic primitive implemented:
• The vendor shall provide a testing interface (test harness) of the cryptographic
mechanisms (I3) to perform the conformity testing process using the TOE
cryptographic implementation.
• The tester shall perform the following cryptographic evaluation test:

Centro Criptológico Nacional 13

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-CONFORMITY/Mechanisms Inputs

For CL1, CL2, and CL3 evaluations, verify the correct operation of
all the cryptographic mechanisms implemented by the TOE and
defined by the vendor in I1. For this purpose:
- Perform the conformity testing process of all the
cryptographic mechanisms using I3 to generate the TOE I1
results files (I4).
I3
- Validate the TOE results files (I4) using the CCN
Cryptographic Tool as the cryptographic reference I4
implementation.
Note: In the case of conformity testing on cryptographic
constructions, it is also mandatory to perform the conformity
testing process of the underlying cryptographic primitives.

232. In the following, a set of tables is defined to identify the required conformity
tests to be performed for each cryptographic construction. They are organized
by constructions rather than by primitives because primitives are not used
independently by the TOE (except for hash and XOF primitives) but as part of a
cryptographic construction. Each conformity test corresponds to a unique ID.
Details of the properties of each test are given in “Annex B: Conformity Tests
Specification”.

4.4.1.1.1 Symmetric Cryptographic Mechanisms

4.4.1.1.1.1 Hash Functions

233. For hashing cryptographic primitives, the following conformity tests have been
defined:

Hash Functions Conformity Testing

Primitive Conformity Test ID
Primitive (SHA-2)
MCT_SHA.1
SHA-2 KAT_SHA.1 for SHA2-256
KAT_SHA.2 for all except SHA2-
256
Primitive (SHA-3)
MCT_SHA3.1 for SHA3-256
SHA-3 MCT_SHA3.2 for SHA3-384
MCT_SHA3.3 for SHA3-512
KAT_SHA3.1 for SHA3-256

Centro Criptológico Nacional 13

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Hash Functions Conformity Testing

Primitive Conformity Test ID
KAT_SHA3.2 for SHA3-384
KAT_SHA3.3 for SHA3-512
Underlying Primitive (Keccak)
MCT_KECCAK.1
Primitive (BLAKE2b)
BLAKE2b MCT_BLAKE2b.1
KAT_BLAKE2b.1

Table 55. Hash Functions Conformity Testing

4.4.1.1.1.2 Extendable-Output Functions (XOF)

234. For XOFs, the following conformity tests have been defined:

XOF Conformity Testing

Primitive Conformity Test ID
Primitive (SHAKE)
KAT_SHAKE.1 for SHAKE128
SHAKE KAT_SHAKE.2 for SHAKE256
Underlying Primitive (Keccak)
MCT_KECCAK.1
Primitive (cSHAKE)
KAT_CSHAKE.1 for cSHAKE128
KAT_CSHAKE.2 for cSHAKE256
Underlying Primitive (SHAKE)
cSHAKE
KAT_SHAKE.1 for cSHAKE128
KAT_SHAKE.2 for cSHAKE256
Underlying Primitive (Keccak)
MCT_KECCAK.1

Table 56. XOF Conformity Testing

4.4.1.1.1.3 Symmetric Encryption (Confidentiality Only)

235. For symmetric encryption cryptographic constructions that provide only
confidentiality to the processed information, the following conformity tests have
been defined:

Centro Criptológico Nacional 13

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Symmetric Encryption (Confidentiality Only) Conformity Testing

Underlying Operation Mode Conformity Test ID
Construction (AES-CBC)
KAT_CBC.1 for No-Padding
KAT_CBC.2 for ISO-7816 Padding
CBC
KAT_CBC.3 for PKCS#7 Padding
Underlying Primitive (AES)
MCT_AES.1
Construction (AES-CBC-CS)
KAT_CBC-CS.1
CBC-CS
Underlying Primitive (AES)
MCT_AES.1
Construction (AES-CFB)
AES
KAT_CFB.1
CFB
Underlying Primitive (AES)
MCT_AES.1
Construction (AES-CTR)
KAT_CTR.1
CTR
Underlying Primitive (AES)
MCT_AES.1
Construction (AES-OFB)
KAT_OFB.1
OFB
Underlying Primitive (AES)
MCT_AES.1

Table 57. Symmetric Encryption Conformity Testing

4.4.1.1.1.4 Disk Encryption

236. For symmetric encryption cryptographic constructions that perform disk
encryption operations, the following conformity tests have been defined:

Disk Encryption Conformity Testing

Underlying Operation Mode Conformity Test ID
Construction (AES-XTS)
KAT_XTS.1 for XTS-256
AES XTS KAT_XTS.2 for XTS-512
Underlying Primitive (AES)
MCT_AES.1

Centro Criptológico Nacional 13

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Table 58. Disk Encryption Conformity Testing

4.4.1.1.1.5 Integrity Modes: Message Authentication Code

237. For MAC cryptographic constructions, the following conformity tests have been
defined:

MAC Conformity Testing

Underlying Scheme Conformity Test ID
Construction (AES-CMAC)
KAT_CMAC.1
CMAC
Underlying Primitive (AES)
MCT_AES.1
AES
Construction (AES-CBC-MAC)
KAT_CBC-MAC.1
CBC-MAC
Underlying Primitive (AES)
MCT_AES.1
Construction (HMAC)
KAT_HMAC.1 for all except SHA2-
512/256
KAT_HMAC.2 for SHA2-512/256
SHA-2 HMAC Underlying Primitive (SHA-2)
MCT_SHA.1
KAT_SHA.1 for SHA2-256
KAT_SHA.2 for all except SHA2-
256
Construction (HMAC)
KAT_HMAC.1
Underlying Primitive (SHA-3)
MCT_SHA3.1 for SHA3-256
MCT_SHA3.2 for SHA3-384
SHA-3 HMAC MCT_SHA3.3 for SHA3-512
KAT_SHA3.1 for SHA3-256
KAT_SHA3.2 for SHA3-384
KAT_SHA3.3 for SHA3-512
Underlying Primitive (Keccak)
MCT_KECCAK.1
Construction (HMAC)
SHA-1 HMAC-SHA1
KAT_HMAC-1.1

Centro Criptológico Nacional 13

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

MAC Conformity Testing

Underlying Scheme Conformity Test ID
Construction (AES-GMAC)
KAT_GMAC.1
AES GMAC
Underlying Primitive (AES)
MCT_AES.1
Construction (KMAC)
KAT_KMAC.1
Underlying Primitive (cSHAKE128)
KAT_CSHAKE.1
KMAC-128
Underlying Primitive (SHAKE128)
KAT_SHAKE.1
Underlying Primitive (Keccak)
MCT_KECCAK.1
cSHAKE
Construction (KMAC)
KAT_KMAC.1
Underlying Primitive (cSHAKE256)
KAT_CSHAKE.2
KMAC-256
Underlying Primitive (SHAKE256)
KAT_SHAKE.2
Underlying Primitive (Keccak)
MCT_KECCAK.1

Table 59. MAC Conformity Testing

4.4.1.1.1.6 Symmetric Entity Authentication Schemes

238. For symmetric entity authentication constructions, the following conformity
tests have been defined:

Symmetric Entity Authentication Conformity Testing

Underlying Scheme Conformity Test ID
Underlying Construction (AES)
Symmetric Entity See Table 57
AES mode or MAC
Authentication Underlying Construction (MAC)
See Table 59

Table 60. Symmetric Entity Authentication Conformity Testing

4.4.1.1.1.7 Authenticated Encryption (AE)

Centro Criptológico Nacional 13

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

239. For authenticated encryption cryptographic constructions, the following

conformity tests have been defined:

Authenticated Encryption Conformity Testing

Underlying Scheme Conformity Test ID
Underlying Construction (AES)
AES mode + MAC
See Table 57
(construction + Encrypt-then-MAC
Underlying Construction (MAC)
construction)
See Table 59
Construction (AES-CCM)
KAT_CCM.1
CCM
Underlying Primitive (AES)
MCT_AES.1
Construction (AES-GCM)
KAT_GCM.1 for 128-bit key
KAT_GCM.2 for 192-bit key
GCM
KAT_GCM.3 for 256-bit key
AES
Underlying Primitive (AES)
MCT_AES.1
Construction (AES-EAX)
KAT_EAX.1 for 128-bit key
KAT_EAX.2 for 192-bit or 256-bit
EAX
keys
Underlying Primitive (AES)
MCT_AES.1
Construction (ChaCha20-
Poly1305)
KAT_CHACHA20-POLY1305.1
ChaCha20 + Underlying Construction
Poly1305 ChaCha20- (Poly1305)
(primitive + Poly1305 MCT_POLY1305.1
construction) KAT_POLY1305.1
Underlying Primitive (ChaCha20)
MCT_CHACHA20.1
KAT_CHACHA20.1

Table 61. Authenticated Encryption Conformity Testing

4.4.1.1.1.8 Key Protection

Centro Criptológico Nacional 13

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

240. For key protection cryptographic constructions, the following conformity tests
have been defined:

Key Protection Conformity Testing

Underlying Scheme Conformity Test ID
Construction (AES-SIV)
KAT_SIV.1 for SIV-256
KAT_SIV.2 for SIV-384
KAT_SIV.3 for SIV-512
Underlying Construction (AES-
AES-CMAC CMAC)
SIV
AES-CTR KAT_CMAC.1
Underlying Construction (AES-
CTR)
KAT_CTR.1
Underlying Primitive (AES)
MCT_AES.1
Construction (AES-KW)
KAT_KW.1 for 128-bit key
KAT_KW.2 for 192-bit key
AES KW
KAT_KW.3 for 256-bit key
Underlying Primitive (AES)
MCT_AES.1
Construction (AES-KWP)
KAT_KWP.1 for 128-bit key
KAT_KWP.2 for 192-bit key
AES KWP
KAT_KWP.3 for 256-bit key
Underlying Primitive (AES)
MCT_AES.1

Table 62. Key Protection Conformity Testing

Note: In case the TOE implements key protection based on Authenticated Encryption
cryptographic mechanisms, the tester shall execute the conformity tests defined in
section 4.4.1.1.1.7 “Authenticated Encryption (AE)” depending on the implemented
mechanisms.

4.4.1.1.1.9 Key Derivation Functions (KDF)

241. For key derivation cryptographic constructions, the following conformity tests
have been defined:

Centro Criptológico Nacional 13

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Key Derivation Functions Conformity Testing

Underlying Scheme Conformity Test ID
Construction (SP800-56C KDF)
KAT_SP80056C-KDF.1
Underlying Construction (HMAC)
KAT_HMAC.1 for all except SHA2-
512/256 and SHA-1
KAT_HMAC.2 for SHA2-512/256
KAT_HMAC-1.1 for SHA-1
Underlying Primitive (SHA-2)
MCT_SHA.1
KAT_SHA.1 for SHA2-256
NIST SP800-56
HMAC KAT_SHA.2 for all except SHA2-
A/B/C OneStep
256
Underlying Primitive (SHA-3)
MCT_SHA3.1 for SHA3-256
MCT_SHA3.2 for SHA3-384
MCT_SHA3.3 for SHA3-512
KAT_SHA3.1 for SHA3-256
KAT_SHA3.2 for SHA3-384
KAT_SHA3.3 for SHA3-512
Underlying Primitive (Keccak)
MCT_KECCAK.1 for SHA-3 family
Construction (SP800-56C KDF)
KAT_SP80056C-KDF.2
Underlying Construction (KMAC)
KAT_KMAC.1
Underlying Primitive (cSHAKE)
NIST SP800-56 KAT_CSHAKE.1 for KMAC-128
KMAC
A/B/C OneStep KAT_CSHAKE.2 for KMAC-256
Underlying Primitive (SHAKE)
KAT_SHAKE.1 for KMAC-128
KAT_SHAKE.2 for KMAC-256
Underlying Primitive (Keccak)
MCT_KECCAK.1

Centro Criptológico Nacional 13

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Key Derivation Functions Conformity Testing

Underlying Scheme Conformity Test ID
Construction (SP800-56C KDF)
KAT_SP80056C-KDF.3
Underlying Primitive (SHA-2)
MCT_SHA.1
KAT_SHA.1 for SHA2-256
KAT_SHA.2 for all except SHA2-
256
NIST SP800-56 Underlying Primitive (SHA-3)
SHA
A/B/C OneStep MCT_SHA3.1 for SHA3-256
MCT_SHA3.2 for SHA3-384
MCT_SHA3.3 for SHA3-512
KAT_SHA3.1 for SHA3-256
KAT_SHA3.2 for SHA3-384
KAT_SHA3.3 for SHA3-512
Underlying Primitive (Keccak)
MCT_KECCAK.1 for SHA-3 family

Centro Criptológico Nacional 14

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Key Derivation Functions Conformity Testing

Underlying Scheme Conformity Test ID
Construction (SP800-56C KDF)
KAT_SP80056C-KDF.4
Underlying Construction (HMAC)
KAT_HMAC.1 for all except SHA2-
512/256 and SHA-1
KAT_HMAC.2 for SHA2-512/256
KAT_HMAC-1.1 for SHA-1
Underlying Construction (SP800-
108)
KAT_SP800108-KDF.2 for NIST
SP800-108 KDF in Counter mode
KAT_SP800108-KDF.3 for NIST
SP800-108 KDF in Feedback mode
KAT_SP800108-KDF.4 for NIST
HMAC NIST SP800-56 SP800-108 KDF in Double Pipeline
A/B/C TwoStep mode
NIST SP800-108
Underlying Primitive (SHA-2)
MCT_SHA.1
KAT_SHA.1 for SHA2-256
KAT_SHA.2 for all except SHA2-
256
Underlying Primitive (SHA-3)
MCT_SHA3.1 for SHA3-256
MCT_SHA3.2 for SHA3-384
MCT_SHA3.3 for SHA3-512
KAT_SHA3.1 for SHA3-256
KAT_SHA3.2 for SHA3-384
KAT_SHA3.3 for SHA3-512
Underlying Primitive (Keccak)
MCT_KECCAK.1 for SHA-3 family

Centro Criptológico Nacional 14

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Key Derivation Functions Conformity Testing

Underlying Scheme Conformity Test ID
Construction (SP800-56C KDF)
KAT_SP80056C-KDF.5
Underlying Construction (AES-
CMAC)
KAT_CMAC.1
Underlying Construction (SP800-
108)
CMAC NIST SP800-56 KAT_SP800108-KDF.2 for NIST
NIST SP800-108 A/B/C TwoStep SP800-108 KDF in Counter mode
KAT_SP800108-KDF.3 for NIST
SP800-108 KDF in Feedback mode
KAT_SP800108-KDF.4 for NIST
SP800-108 KDF in Double Pipeline
mode
Underlying Primitive (AES)
MCT_AES.1

Centro Criptológico Nacional 14

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Key Derivation Functions Conformity Testing

Underlying Scheme Conformity Test ID
Construction (SP800-108)
KAT_SP800108-KDF.2 for Counter
mode
KAT_SP800108-KDF.3 for
Feedback mode
KAT_SP800108-KDF.4 for Double
Pipeline mode
Underlying Construction (HMAC)
KAT_HMAC.1 for all except SHA2-
512/256 and SHA-1
KAT_HMAC.2 for SHA2-512/256
KAT_HMAC-1.1 for SHA-1
Underlying Primitive (SHA-2)
HMAC NIST SP800-108 MCT_SHA.1
KAT_SHA.1 for SHA2-256
KAT_SHA.2 for all except SHA2-
256
Underlying Primitive (SHA-3)
MCT_SHA3.1 for SHA3-256
MCT_SHA3.2 for SHA3-384
MCT_SHA3.3 for SHA3-512
KAT_SHA3.1 for SHA3-256
KAT_SHA3.2 for SHA3-384
KAT_SHA3.3 for SHA3-512
Underlying Primitive (Keccak)
MCT_KECCAK.1 for SHA-3 family

Centro Criptológico Nacional 14

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Key Derivation Functions Conformity Testing

Underlying Scheme Conformity Test ID
Construction (SP800-108)
KAT_SP800108-KDF.2 for Counter
mode
KAT_SP800108-KDF.3 for
Feedback mode
KAT_SP800108-KDF.4 for Double
CMAC NIST SP800-108 Pipeline mode
Underlying Construction (AES-
CMAC)
KAT_CMAC.1
Underlying Primitive (AES)
MCT_AES.1
Construction (SP800-108)
KAT_SP800108-KDF.1 for KMAC
KAT_SP800108-KDF.2 for Counter
mode
KAT_SP800108-KDF.3 for
Feedback mode
KAT_SP800108-KDF.4 for Double
Pipeline mode
Underlying Construction (KMAC)
KMAC NIST SP800-108 KAT_KMAC.1
Underlying Primitive (cSHAKE)
KAT_CSHAKE.1 for KMAC-128
KAT_CSHAKE.2 for KMAC-256
Underlying Primitive (SHAKE)
KAT_SHAKE.1 for KMAC-128
KAT_SHAKE.2 for KMAC-256
Underlying Primitive (Keccak)
MCT_KECCAK.1

Centro Criptológico Nacional 14

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Key Derivation Functions Conformity Testing

Underlying Scheme Conformity Test ID
Construction (ANSI-X9.63 KDF)
KAT_X9.63-KDF.1 for all except
SHA2-512 and SHA3-512
KAT_X9.63-KDF.2 for SHA2-512
and SHA3-512
Underlying Primitive (SHA-2)
MCT_SHA.1
KAT_SHA.1 for SHA2-256
KAT_SHA.2 for all except SHA2-
SHA ANSI-X9.63 KDF 256
Underlying Primitive (SHA-3)
MCT_SHA3.1 for SHA3-256
MCT_SHA3.2 for SHA3-384
MCT_SHA3.3 for SHA3-512
KAT_SHA3.1 for SHA3-256
KAT_SHA3.2 for SHA3-384
KAT_SHA3.3 for SHA3-512
Underlying Primitive (Keccak)
MCT_KECCAK.1 for SHA-3 family
Construction (PBKDF2)
KAT_PBKDF2.1
Underlying Construction (HMAC)
KAT_HMAC.1 for all except SHA2-
512/256 and SHA-1
KAT_HMAC.2 for SHA2-512/256
HMAC PBKDF2
KAT_HMAC-1.1 for SHA-1
Underlying Primitive (SHA-2)
MCT_SHA.1
KAT_SHA.1 for SHA2-256
KAT_SHA.2 for all except SHA2-
256

Centro Criptológico Nacional 14

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Key Derivation Functions Conformity Testing

Underlying Scheme Conformity Test ID
Construction (HKDF)
KAT_HKDF.1 for SHA-1
KAT_HKDF.2 for SHA2-256
KAT_HKDF.3 for SHA2-384
KAT_HKDF.4 for SHA2-512
Underlying Construction (HMAC)
HMAC HKDF KAT_HMAC.1 for SHA-2 family
KAT_HMAC-1.1 for SHA-1
Underlying Primitive (SHA-2)
MCT_SHA.1
KAT_SHA.1 for SHA2-256
KAT_SHA.2 for all except SHA2-
256

Table 63. Key Derivation Functions Conformity Testing

4.4.1.1.1.10 Password Protection/Hashing Mechanisms

242. For password protection/hashing cryptographic constructions, the following
conformity tests have been defined:

Centro Criptológico Nacional 14

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Password Protection/Hashing Mechanisms Conformity Testing

Underlying Scheme Conformity Test ID
Construction (Argon2id)
KAT_Argon2id.1
BLAKE2b Argon2id Underlying Primitive (BLAKE2b)
MCT_BLAKE2b.1
KAT_BLAKE2b.1
Construction (PBKDF2)
KAT_PBKDF2.1
Underlying Construction (HMAC)
KAT_HMAC.1 for all except SHA2-
512/256 and SHA-1
KAT_HMAC.2 for SHA2-512/256
HMAC PBKDF2
KAT_HMAC-1.1 for SHA-1
Underlying Primitive (SHA-2)
MCT_SHA.1
KAT_SHA.1 for SHA2-256
KAT_SHA.2 for all except SHA2-
256
Construction (SCRYPT)
KAT_SCRYPT.1
Underlying Construction
(PBKDF2)
KAT_PBKDF2.1
PBKDF2 SCRYPT
Underlying Construction (HMAC)
KAT_HMAC.1
Underlying Primitive (SHA-2)
MCT_SHA.1
KAT_SHA.1

Table 64. Password Protection/Hashing Mechanisms Conformity Testing

4.4.1.1.2 Asymmetric Cryptographic Mechanisms

4.4.1.1.2.1 Asymmetric Encryption Schemes

243. For asymmetric encryption cryptographic constructions, the following
conformity tests have been defined:

Centro Criptológico Nacional 14

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Asymmetric Encryption Conformity Testing

Underlying Scheme Conformity Test ID
Construction (RSA-OAEP)
KAT_OAEP.1
Underlying Primitive (RSA)
MCT_RSA.1 for modular
exponentiation operations with
an RSA public key
MCT_RSA.2 for modular
exponentiation operations with
an RSA public key, when the value
e is equal to 65537
MCT_RSA.3 for modular
exponentiation operations with
an RSA private key
MCT_RSA.4 for modular
exponentiation operations with
extended parameters with a
Chinese Remainder Theorem
RSA OAEP (CRT) recombination
SHA (PKCS#1v2.1) KAT_M-R.1 for Miller-Rabin in
case of RSA Key Generation
Underlying Primitive (SHA-2)
MCT_SHA.1
KAT_SHA.1 for SHA2-256
KAT_SHA.2 for all except SHA2-
256
Underlying Primitive (SHA-3)
MCT_SHA3.1 for SHA3-256
MCT_SHA3.2 for SHA3-384
MCT_SHA3.3 for SHA3-512
KAT_SHA3.1 for SHA3-256
KAT_SHA3.2 for SHA3-384
KAT_SHA3.3 for SHA3-512
Underlying Primitive (Keccak)
MCT_KECCAK.1 for SHA-3 family
Construction (RSA-PKCS#1v1.5)
RSA PKCS#1v1.5 KAT_PKCS.1
Underlying Primitive (RSA)

Centro Criptológico Nacional 14

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

MCT_RSA.1 for modular

exponentiation operations with
an RSA public key
MCT_RSA.2 for modular
exponentiation operations with
an RSA public key, when the value
e is equal to 65537
MCT_RSA.3 for modular
exponentiation operations with
an RSA private key
MCT_RSA.4 for modular
exponentiation operations with
extended parameters with a
Chinese Remainder Theorem
(CRT) recombination
KAT_M-R.1 for Miller-Rabin in
case of RSA Key Generation

Table 65. Asymmetric Encryption Conformity Testing

4.4.1.1.2.2 Digital Signature

244. For digital signature cryptographic constructions, the following conformity tests
have been defined:

Digital Signature Conformity Testing

Underlying Scheme Conformity Test ID
Construction (RSA-PSS)
VAL_PSS.1 for Signature
Generation
KAT_PSS.1 for Signature
Verification
Underlying Primitive (RSA)
MCT_RSA.1 for modular
RSA PSS exponentiation operations with
SHA (PKCS#1v2.1) an RSA public key
MCT_RSA.2 for modular
exponentiation operations with
an RSA public key, when the value
e is equal to 65537
MCT_RSA.3 for modular
exponentiation operations with
an RSA private key

Centro Criptológico Nacional 14

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

MCT_RSA.4 for modular

exponentiation operations with
extended parameters with a
Chinese Remainder Theorem
(CRT) recombination
KAT_M-R.1 for Miller-Rabin in
case of RSA Key Generation
Underlying Primitive (SHA-2)
MCT_SHA.1
KAT_SHA.1 for SHA2-256
KAT_SHA.2 for all except SHA2-
256
Underlying Primitive (SHA-3)
MCT_SHA3.1 for SHA3-256
MCT_SHA3.2 for SHA3-384
MCT_SHA3.3 for SHA3-512
KAT_SHA3.1 for SHA3-256
KAT_SHA3.2 for SHA3-384
KAT_SHA3.3 for SHA3-512
Underlying Primitive (Keccak)
MCT_KECCAK.1 for SHA-3 family
Construction (KCDSA)
VAL_KCDSA.1 for Signature
Generation
KAT_KCDSA.1 for Signature
Verification
Underlying Primitive (FFDLOG)
MCT_FFDLOG.1
Underlying Primitive (SHA-2)
FFDLOG MCT_SHA.1
KCDSA
SHA KAT_SHA.1 for SHA2-256
KAT_SHA.2 for all except SHA2-
256
Underlying Primitive (SHA-3)
MCT_SHA3.1 for SHA3-256
MCT_SHA3.2 for SHA3-384
MCT_SHA3.3 for SHA3-512
KAT_SHA3.1 for SHA3-256
KAT_SHA3.2 for SHA3-384

Centro Criptológico Nacional 15

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

KAT_SHA3.3 for SHA3-512

Underlying Primitive (Keccak)
MCT_KECCAK.1 for SHA-3 family
Construction (Schnorr)
VAL_SDSA.1 for Signature
Generation
KAT_SDSA.1 for Signature
Verification
Underlying Primitive (FFDLOG)
MCT_FFDLOG.1
Underlying Primitive (SHA-2)
MCT_SHA.1
KAT_SHA.1 for SHA2-256
Schnorr KAT_SHA.2 for all except SHA2-
256
Underlying Primitive (SHA-3)
MCT_SHA3.1 for SHA3-256
MCT_SHA3.2 for SHA3-384
MCT_SHA3.3 for SHA3-512
KAT_SHA3.1 for SHA3-256
KAT_SHA3.2 for SHA3-384
KAT_SHA3.3 for SHA3-512
Underlying Primitive (Keccak)
MCT_KECCAK.1 for SHA-3 family
Construction (DSA)
VAL_DSA.1 for Signature
Generation
KAT_DSA.1 for Signature
Verification
Underlying Primitive (FFDLOG)
MCT_FFDLOG.1
DSA
Underlying Primitive (SHA-2)
MCT_SHA.1
KAT_SHA.1 for SHA2-256
KAT_SHA.2 for all except SHA2-
256
Underlying Primitive (SHA-3)
MCT_SHA3.1 for SHA3-256

Centro Criptológico Nacional 15

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

MCT_SHA3.2 for SHA3-384

MCT_SHA3.3 for SHA3-512
KAT_SHA3.1 for SHA3-256
KAT_SHA3.2 for SHA3-384
KAT_SHA3.3 for SHA3-512
Underlying Primitive (Keccak)
MCT_KECCAK.1 for SHA-3 family
Construction (EC-KCDSA)
VAL_ECKCDSA.1 for Signature
Generation
KAT_ECKCDSA.1 for Signature
Verification
Underlying Primitive (ECDLOG)
MCT_ECDLOG.1 for EC Scalar
Multiplication operations
MCT_ECDLOG.2 for EC Scalar
Multiplication with Fixed Base
Point operations
MCT_ECDLOG.3 for EC Multi-
scalar Multiplication operations
Underlying Primitive (SHA-2)
EC-KCDSA
MCT_SHA.1
KAT_SHA.1 for SHA2-256
ECDLOG
KAT_SHA.2 for all except SHA2-
SHA
256
Underlying Primitive (SHA-3)
MCT_SHA3.1 for SHA3-256
MCT_SHA3.2 for SHA3-384
MCT_SHA3.3 for SHA3-512
KAT_SHA3.1 for SHA3-256
KAT_SHA3.2 for SHA3-384
KAT_SHA3.3 for SHA3-512
Underlying Primitive (Keccak)
MCT_KECCAK.1 for SHA-3 family
Construction (EC-DSA)
VAL_ECDSA.1 for Signature
EC-DSA Generation
KAT_ECDSA.1 for Signature
Verification

Centro Criptológico Nacional 15

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Underlying Primitive (ECDLOG)

MCT_ECDLOG.1 for EC Scalar
Multiplication operations
MCT_ECDLOG.2 for EC Scalar
Multiplication with Fixed Base
Point operations
MCT_ECDLOG.3 for EC Multi-
scalar Multiplication operations
Underlying Primitive (SHA-2)
MCT_SHA.1
KAT_SHA.1 for SHA2-256
KAT_SHA.2 for all except SHA2-
256
Underlying Primitive (SHA-3)
MCT_SHA3.1 for SHA3-256
MCT_SHA3.2 for SHA3-384
MCT_SHA3.3 for SHA3-512
KAT_SHA3.1 for SHA3-256
KAT_SHA3.2 for SHA3-384
KAT_SHA3.3 for SHA3-512
Underlying Primitive (Keccak)
MCT_KECCAK.1 for SHA-3 family
Construction (EC-GDSA)
VAL_ECGDSA.1 for Signature
Generation
KAT_ECGDSA.1 for Signature
Verification
Underlying Primitive (ECDLOG)
MCT_ECDLOG.1 for EC Scalar
Multiplication operations
EC-GDSA
MCT_ECDLOG.2 for EC Scalar
Multiplication with Fixed Base
Point operations
MCT_ECDLOG.3 for EC Multi-
scalar Multiplication operations
Underlying Primitive (SHA-2)
MCT_SHA.1
KAT_SHA.1 for SHA2-256

Centro Criptológico Nacional 15

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

KAT_SHA.2 for all except SHA2-

256
Underlying Primitive (SHA-3)
MCT_SHA3.1 for SHA3-256
MCT_SHA3.2 for SHA3-384
MCT_SHA3.3 for SHA3-512
KAT_SHA3.1 for SHA3-256
KAT_SHA3.2 for SHA3-384
KAT_SHA3.3 for SHA3-512
Underlying Primitive (Keccak)
MCT_KECCAK.1 for SHA-3 family
Construction (EC-Schnorr)
VAL_ECSDSA.1 for EC-SDSA
Signature Generation
KAT_ECSDSA.1 for EC-SDSA
Signature Verification
VAL_ECFSDSA.1 for EC-FSDSA
Signature Generation
KAT_ECFSDSA.1 for EC-FSDSA
Signature Verification
Underlying Primitive (ECDLOG)
MCT_ECDLOG.1 for EC Scalar
Multiplication operations
MCT_ECDLOG.2 for EC Scalar
Multiplication with Fixed Base
EC-Schnorr Point operations
MCT_ECDLOG.3 for EC Multi-
scalar Multiplication operations
Underlying Primitive (SHA-2)
MCT_SHA.1
KAT_SHA.1 for SHA2-256
KAT_SHA.2 for all except SHA2-
256
Underlying Primitive (SHA-3)
MCT_SHA3.1 for SHA3-256
MCT_SHA3.2 for SHA3-384
MCT_SHA3.3 for SHA3-512
KAT_SHA3.1 for SHA3-256
KAT_SHA3.2 for SHA3-384

Centro Criptológico Nacional 15

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

KAT_SHA3.3 for SHA3-512

Underlying Primitive (Keccak)
MCT_KECCAK.1 for SHA-3 family
Construction (EdDSA)
VAL_EDDSA.1 for Signature
Generation
KAT_EDDSA.1 for Signature
Verification
Underlying Primitive (ECDLOG)
MCT_ECDLOG.1 for EC Scalar
Multiplication operations
MCT_ECDLOG.2 for EC Scalar
Multiplication with Fixed Base
ECDLOG Point operations
SHA2-512 EdDSA MCT_ECDLOG.3 for EC Multi-
scalar Multiplication operations
SHAKE256
MCT_ECDLOG.6 for EC Base Point
Multi-Scalar Multiplication
operations
Underlying Primitive (SHA2-512)
MCT_SHA.1
KAT_SHA.2
Underlying Primitive (SHAKE256)
KAT_SHAKE.2
Underlying Primitive (Keccak)
MCT_KECCAK.1 for SHAKE256
Construction (RSA-PKCS#1v1.5)
VAL_PKCS.1 for Signature
Generation
KAT_PKCS.2 for Signature
Verification
RSA Underlying Primitive (RSA)
PKCS#1v1.5 MCT_RSA.1 for modular
SHA
exponentiation operations with
an RSA public key
MCT_RSA.2 for modular
exponentiation operations with
an RSA public key, when the value
e is equal to 65537

Centro Criptológico Nacional 15

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

MCT_RSA.3 for modular

exponentiation operations with
an RSA private key
MCT_RSA.4 for modular
exponentiation operations with
extended parameters with a
Chinese Remainder Theorem
(CRT) recombination
KAT_M-R.1 for Miller-Rabin in
case of RSA Key Generation
Underlying Primitive (SHA-2)
MCT_SHA.1
KAT_SHA.1 for SHA2-256
KAT_SHA.2 for all except SHA2-
256
Construction (XMSS)
VAL_XMSS.1 for Signature
Generation
KAT_XMSS .1 for Signature
Verification
SHA2-256 Underlying Primitive (SHA2-256)
XMSS MCT_SHA.1
SHAKE256
KAT_SHA.1
Underlying Primitive (SHAKE256)
KAT_SHAKE.2
Underlying Primitive (Keccak)
MCT_KECCAK.1 for SHAKE256

Table 66. Digital Signature Conformity Testing

4.4.1.1.2.3 Key Establishment

245. For key establishment cryptographic constructions, the following conformity
tests have been defined:

Key Establishment Conformity Testing

Underlying Scheme Conformity Test ID
Construction (DH)
VAL_DH.1 in case of Key
FFDLOG
DH Generation
KDF
VAL_DH.2
KAT_DH.1

Centro Criptológico Nacional 15

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Underlying Construction (KDF)

See Table 63 for underlying KDF
Underlying Primitives (FFDLOG)
MCT_FFDLOG.1
Construction (DLIES-KEM)
KAT_DLIES-KEM.1
FFDLOG Underlying Construction (KDF)
DLIES-KEM
KDF See Table 63 for underlying KDF
Underlying Primitive (FFDLOG)
MCT_FFDLOG.1
Construction (DH)
VAL_ECDH.1 in case of Key
Generation
VAL_ECDH.2
KAT_ECDH.1
Underlying Construction (KDF)
See Table 63 for underlying KDF
Underlying Primitive (ECDLOG)
MCT_ECDLOG.1 for EC Scalar
Multiplication operations with
regular curves (NIST-P curves,
ECDLOG Brainpool-P curves, and FRP256v1
EC-DH curve)
KDF
MCT_ECDLOG.2 for EC Scalar
Multiplication with Fixed Base
Point operations with regular
curves (NIST-P curves, Brainpool-P
curves, and FRP256v1 curve)
MCT_ECDLOG.4 for EC Scalar
Multiplication operations for
Curve25519 and Curve448
MCT_ECDLOG.5 for EC Scalar
Multiplication with the Fixed Base
point operations for Curve25519
and Curve448
Construction (ECIES-KEM)
ECDLOG KAT_ECIES-KEM.1
ECIES-KEM
KDF Underlying Construction (KDF)
See Table 63 for underlying KDF

Centro Criptológico Nacional 15

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Underlying Primitive (ECDLOG)

MCT_ECDLOG.1 for EC Scalar
Multiplication operations
MCT_ECDLOG.2 for EC Scalar
Multiplication with Fixed Base
Point operations

Table 67. Key Establishment Conformity Testing

4.4.1.1.3 Deterministic Random Number Generators

246. For deterministic random number generator (DRNG) constructions, the
following conformity tests have been defined:

DRNG Conformity Testing

Underlying Scheme Conformity Test ID
Construction (HMAC-DRBG)
KAT_HMAC-DRBG.1 for NR
configuration
KAT_HMAC-DRBG.2 for NPR
configuration
KAT_HMAC-DRBG.3 for PR
configuration
Underlying Construction (HMAC)
HMAC HMAC-DRBG KAT_HMAC.1 for all except HMAC-
SHA2-512/256 and SHA-1
KAT_HMAC.2 for SHA2-512/256
KAT_HMAC-1.1 for SHA-1
Underlying Primitive (SHA-2)
MCT_SHA.1
KAT_SHA.1 for SHA2-256
KAT_SHA.2 for all except SHA2-256
Construction (Hash-DRBG)
KAT_HASH-DRBG.1 for NR
configuration
KAT_HASH-DRBG.2 for NPR
SHA HASH-DRBG configuration
KAT_HASH-DRBG.3 for PR
configuration
Underlying Primitive (SHA-2)
MCT_SHA.1 for SHA-2

Centro Criptológico Nacional 15

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

KAT_SHA.1 for SHA2-256

KAT_SHA.2 for all except SHA2-256
Construction (CTR-DRBG)
KAT_CTR-DRBG.1 for NR with DF
configuration
KAT_CTR-DRBG.2 for NR without
DF configuration
KAT_CTR-DRBG.3 for NPR with DF
configuration
KAT_CTR-DRBG.4 for NPR without
AES-CTR CTR-DRBG DF configuration
KAT_CTR-DRBG.5 for PR with DF
configuration
KAT_CTR-DRBG.6 for PR without
DF configuration
Underlying Construction (AES-CTR)
KAT_CTR.1
Underlying Primitive (AES)
MCT_AES.1

Table 68. DRNG Conformity Testing

Centro Criptológico Nacional 15

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

5 AVOIDANCE OF IMPLEMENTATION PITFALLS

5.1 OBJECTIVE
247. This chapter defines the common implementation pitfalls for the cryptographic
mechanisms implemented by the TOE and how to avoid them. The common
implementation pitfalls have been defined by CCN according to the [CCN-STIC-
221] guidance in conjunction with the specified in the [SOGIS-HEP] document by
the SOG-IS participants.
248. Therefore, it provides vendors with the common implementation pitfalls that
shall be avoided by the TOE. In addition, it provides testers with the evaluation
task necessary to verify that the TOE implements mechanisms to avoid the
implementation pitfalls associated with the implemented cryptographic
mechanisms.

5.2 DEFINITIONS
Cryptographic Mechanisms
249. The implementation of cryptographic mechanisms is a process where several
errors might be introduced. These are common implementation errors that have
been identified considering their impact on the security of the implemented
mechanisms. These errors may be linked to non-conformities of the
implementation or bad implementation choices of mechanisms weakening the
security of the mechanisms.

5.3 CRYPTOGRAPHIC EVALUATION TASK

250. This section contains common implementation pitfalls that shall be avoided by
the vendors in the case of implementing a TOE with cryptographic capabilities.
251. A cryptographic evaluation task related to the avoidance of implementation
pitfalls has been defined:

CRYPTOGRAPHIC CERTIFICATION
CCN-PITFALL
EVALUATION TASK LEVEL

The tester shall verify the proper avoidance of the

implementation pitfalls associated with all the
CL2 and CL3
cryptographic mechanisms implemented by the TOE (even
if they are not in use).

252. For the correct completion of the entire evaluation task, it has been divided into
a set of cryptographic evaluation tests that the tester shall perform if applicable
for the TOE.

Centro Criptológico Nacional 16

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Test
Cryptographic Evaluation Test
Evaluation Task Categorization

CCN-PITFALL/SymEncryption.1 Impl-Dep

CCN-PITFALL/SymEncryption.2 Impl-Dep

CCN-PITFALL/CTR Impl-Dep

CCN-PITFALL/DiskEncryption Impl-Dep

CCN-PITFALL/XTS Impl-Dep

CCN-PITFALL/CBCMAC Impl-Dep

CCN-PITFALL/AuthEncryption Impl-Dep

CCN-PITFALL/AuthEncryptionComb.1 Impl-Dep

CCN-PITFALL/AuthEncryptionComb.2 Impl-Dep

CCN-PITFALL/CCM Impl-Dep
CCN-PITFALL
CCN-PITFALL/GCM.1 Impl-Dep
Avoidance of
Implementation CCN-PITFALL/GCM.2 Impl-Dep
Pitfalls
CCN-PITFALL/EAX Impl-Dep

CCN-PITFALL/SIV.1 Impl-Dep

CCN-PITFALL/SIV.2 Impl-Dep

CCN-PITFALL/Keywrap Impl-Dep

CCN-PITFALL/KeyDerivation Impl-Dep

CCN-PITFALL/RSA Impl-Dep

CCN-PITFALL/RSAParameter.1 Impl-Dep

CCN-PITFALL/RSAParameter.2 Impl-Dep

CCN-PITFALL/FFDLOG.1 Impl-Dep

CCN-PITFALL/FFDLOG.2 Impl-Dep

Centro Criptológico Nacional 16

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Cryptographic Test
Cryptographic Evaluation Test
Evaluation Task Categorization

CCN-PITFALL/ECDLOG Impl-Dep

CCN-PITFALL/AsymConstruction Impl-Dep

CCN-PITFALL/AsymEncryption Impl-Dep

CCN-PITFALL/RSAPKCS Impl-Dep

CCN-PITFALL/AsymAuth Impl-Dep

CCN-PITFALL/XMSS.1 Impl-Dep

CCN-PITFALL/XMSS.2 Impl-Dep

CCN-PITFALL/XMSS.3 Impl-Dep

CCN-PITFALL/XMSS.4 Impl-Dep

CCN-PITFALL/KeyEstablishment Impl-Dep

CCN-PITFALL/FFKeyEstablishment Impl-Dep

CCN-PITFALL/ECKeyEstablishment Impl-Dep

CCN-PITFALL/DRG.1 Impl-Dep

CCN-PITFALL/DRG.2 Impl-Dep

CCN-PITFALL/CTRDRBG Impl-Dep

CCN-PITFALL/KeyManagement Impl-Dep

CCN-PITFALL/KeyTransport Impl-Dep

CCN-PITFALL/KeyUsage Impl-Dep

Table 69. Cryptographic Evaluation Tests defined for CCN Pitfall

5.3.1 CRYPTOGRAPHIC EVALUATION TEST DEFINITION

253. This subsection defines the cryptographic evaluation tests that shall be
performed by the tester to accomplish the evaluation tasks, based on the
avoidance of implementation pitfalls.

Centro Criptológico Nacional 16

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

5.3.1.1 CRYPTOGRAPHIC MECHANISMS IMPLEMENTATION

254. This topic defines the cryptographic evaluation process to verify the correct
avoidance of implementation pitfalls for each cryptographic mechanism
implemented by the TOE, in order to fulfill the CCN-PITFALL evaluation task.

5.3.1.1.1 Symmetric Constructions

255. Symmetric constructions are built upon symmetric elementary primitives and
enable them to address a large variety of security objectives. The security of
keyed symmetric schemes relies on the confidentiality and integrity of a secret
key shared by legitimate parties.

5.3.1.1.1.1 Symmetric Encryption (Confidentiality Only)

256. In case the TOE implements symmetric encryption cryptographic constructions
to provide only confidentiality to the processed information:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with symmetric encryption cryptographic constructions.
• The tester shall perform the following cryptographic evaluation test:

CCN-PITFALL/SymEncryption.1 Inputs

In the case of CL2 evaluations, verify using I5 that the TOE

implementation ensures that the expected property of the initial
vector or the counter is satisfied:
- For CBC, CBC-CS, and CFB modes, the IV must be
unpredictable.
- For the OFB mode, the IV must only be unique for each
encryption process. In this case, the IV is called nonce.
- For the CTR mode, the counters shall be generated in such
a way that all counters are unique across all plaintexts (and
not only within a single plaintext). I5
Analysis: For OFB, reusing a nonce with the same key voids the I6
confidentiality guarantees of the mode. For the CTR mode, the
standard [SP800-38A] specifies input blocks that are encrypted to
produce the key stream. Using a counter twice also voids the
confidentiality guarantee of the mode. Appendix B of [SP800-38A]
recommends two methods to generate such counters. Also, the
generation method of the first counter and the next counters for
GCM [SP800-38D] in section 8.2.1 is more formal and accurate.
This method can be used for the CTR mode as well. In this case,
the first counter is generated from the concatenation of an IV and
a counter buffer initialized with zero. For this method, the unicity
of the IV guarantees the unicity of all counters.

Centro Criptológico Nacional 16

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-PITFALL/SymEncryption.1 Inputs
For CBC, CBC-CS, and CFB, reusing an IV with the same key leaks
some information about the first block of the message. In addition,
it must be unpredictable. [SP800-38A] recommends, in Appendix
C, two methods to generate unpredictable IV. The first method is
to generate an IV by encrypting a nonce with the same key that is
used for the encryption of the plaintext. The second method is to
generate a random IV with a strong DRNG.
Overall, especially for stream modes of operation, care shall be
taken when a nonce or IV is chosen at random. This is due to the
birthday paradox. As an example, if a nonce or IV of size 64 bits is
chosen (for example if a random nonce of size 64 bits is
concatenated with a 64-bit buffer block), then the probability of
collision is greater than 2−32 after 92681 draws. The number of
draws corresponds to the number of messages being encrypted.
Thus, the possible number of messages encrypted with the same
key shall be analyzed to conclude this test. For 96 bits, the
probability that a collision occurs is greater than 2−32 after
6074000999 draws, which can be an issue for very long lifetime
keys.
Determining whether each nonce is unique and each IV is unique
and unpredictable is not achievable through known answer tests.
It rather requires an analysis of the cryptographic specification’s
rationale of the implementation, possibly supported by a source
code analysis.
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

257. In case the TOE implements symmetric encryption cryptographic constructions

to provide only confidentiality to the processed information based on padding
schemes:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with symmetric encryption cryptographic constructions based on
padding schemes.
• The tester shall perform the following cryptographic evaluation test:

Centro Criptológico Nacional 16

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-PITFALL/SymEncryption.2 Inputs

In the case of CL2 evaluations, verify using I5 that an attacker has

no access to the correctness of the padding or format of the
deciphered ciphertext (it corresponds to the output blocks when
applying the decryption mode of operation. It is equal to the
“plaintext” if no padding is used. It is equal to the “padded
plaintext” if padding is used in the scheme, with possibly an
incorrect padding) of arbitrary ciphertexts, chosen by the attacker.
Analysis: This applies in particular to schemes with paddings and I5
the attack is then called a padding oracle attack [Vau02]. However,
this test more generally applies to all schemes where any I6
verification is performed on the format of the deciphered
ciphertext. In this case, the attack is called a format oracle attack.
Such attacks can be used to decrypt any ciphertext. It is pointed
out that these attacks can be mounted if the attacker can submit
arbitrary data to be deciphered.
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

258. In case the TOE implements symmetric encryption cryptographic constructions

to provide only confidentiality to the processed information based on CTR
operation mode:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with symmetric encryption cryptographic constructions based on CTR
operation mode.
• The tester shall perform the following cryptographic evaluation test:

CCN-PITFALL/CTR Inputs

In the case of CL2 evaluations, verify using I5 that the counter

block is unique for each plaintext block that is encrypted under a
given key.
Analysis: Appendix B.2 of [SP800-38A] provides two methods to I5
select the initial counter value for the counter mode to satisfy this
uniqueness requirement. CCN-PITFALL.1/SymEncryption.1 can be I6
ignored because of this implementation pitfall.
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

Centro Criptológico Nacional 16

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

5.3.1.1.1.2 Disk Encryption

259. In case the TOE implements symmetric encryption cryptographic constructions
to perform disk encryption operations:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with disk encryption cryptographic constructions.
• The tester shall perform the following cryptographic evaluation test:

CCN-PITFALL/DiskEncryption Inputs

In the case of CL2 evaluations, verify using I5 that the

implementation ensures that the tweak value (for XTS) is unique
for each encryption with the same key.
Analysis: Indeed, like a nonce, the tweak value must be unique.
This is similar to CCN-PITFALL.1/SymEncryption.1. The tweak I5
value is usually derived from the address where the ciphertext is
stored. Extra care shall be applied for storage devices or disk I6
drivers that determine the used tweak from logical address rather
than physical address.
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

260. In case the TOE implements disk encryption cryptographic constructions based
on XTS operation mode:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with disk encryption cryptographic constructions based on XTS
operation mode.
• The tester shall perform the following cryptographic evaluation test:

CCN-PITFALL/XTS Inputs

In the case of CL2 evaluations, verify using I5 that the

implementation checks that key1 ≠ key2 before using the keys in
the XTS algorithm to process data with them.
Analysis: An improper key generation that results in key1 = key2
introduces a vulnerability to chosen ciphertext attacks. Therefore, I5
section 6.3 of [SP800-133] rev2 provides the rules for component I6
symmetric keys to independently generate and/or establish key1
and key2.
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

Centro Criptológico Nacional 16

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

5.3.1.1.1.3 Integrity Modes: Message Authentication Code

261. In case the TOE implements message authentication code cryptographic
constructions based on the CBC-MAC scheme:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with message authentication code cryptographic constructions based
on CBC-MAC.
• The tester shall perform the following cryptographic evaluation test:

CCN-PITFALL/CBCMAC Inputs

In the case of CL2 evaluations, verify using I5 that the size of all the
inputs for which CBC-MAC is computed under the same key is the
same.
I5
Analysis: Otherwise, the attacker can trivially forge MAC with two
known pairs (message, MAC). I6

In the case of CL3 evaluations, use I5 and perform a source code

review (using I6) to verify the above-mentioned.

5.3.1.1.1.4 Authenticated Encryption (AE)

262. In case the TOE implements authenticated encryption cryptographic
constructions:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with authenticated encryption cryptographic constructions.
• The tester shall perform the following cryptographic evaluation test:

CCN-PITFALL/AuthEncryption Inputs

In the case of CL2 evaluations, verify using I5 that, if the integrity

of the ciphertext is not properly checked before decryption, the
attacker cannot access the specific error condition (format error
or MAC error) that can occur in the system.
Analysis: This applies to schemes with paddings in order to avoid
so-called padding oracle attacks [Vau02]. However, the task I5
applies to all schemes if any verification is performed on the I6
format of the deciphered ciphertext and if the deciphered
ciphertexts are sent to consuming applications. Such verifications
may lead to a format oracle attack.
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

Centro Criptológico Nacional 16

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

263. In case the TOE implements authenticated encryption cryptographic

constructions based on the Encrypt-then-MAC scheme:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with authenticated encryption cryptographic constructions based on
the Encrypt-then-MAC scheme.
• The tester shall perform the following cryptographic evaluation tests:

CCN-PITFALL/AuthEncryptionComb.1 Inputs

In the case of CL2 evaluations, verify using I5 that the

implementation pitfalls of the underlying mechanisms are
considered.
I5
In particular, the ones referring to symmetric encryption and MAC
constructions. I6

In the case of CL3 evaluations, use I5 and perform a source code

review (using I6) to verify the above-mentioned.

CCN-PITFALL/AuthEncryptionComb.2 Inputs

In the case of CL2 evaluations, verify using I5 that the keys used
for encryption and MAC operations are different. I5
In the case of CL3 evaluations, use I5 and perform a source code I6
review (using I6) to verify the above-mentioned.

264. In case the TOE implements authenticated encryption cryptographic

constructions based on the CCM scheme:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with authenticated encryption cryptographic constructions based on
the CCM scheme.
• The tester shall perform the following cryptographic evaluation test:

CCN-PITFALL/CCM Inputs

In the case of CL2 evaluations, verify using I5 that all the

implementation pitfalls of the CTR operation mode and the CBC-
MAC scheme are considered.
I5
Analysis: CCM relies on the CTR mode for encryption and the CBC-
MAC mechanism for authentication. I6

In the case of CL3 evaluations, use I5 and perform a source code

review (using I6) to verify the above-mentioned.

Centro Criptológico Nacional 16

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

265. In case the TOE implements authenticated encryption, cryptographic

constructions based on the GCM scheme:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with authenticated encryption cryptographic constructions based on
the GCM scheme.
• The tester shall perform the following cryptographic evaluation tests:

CCN-PITFALL/GCM.1 Inputs

In the case of CL2 evaluations, verify using I5 that no message of

length strictly greater than 232 - 2 blocks can be encrypted.
Analysis: The counters are generated with the concatenation of a I5
unique IV of 96 bits and an incremented counter of 32 bits. This
test avoids the overflow of the counter. I6

In the case of CL3 evaluations, use I5 and perform a source code

review (using I6) to verify the above-mentioned.

CCN-PITFALL/GCM.2 Inputs

In the case of CL2 evaluations, verify using I5 that an IV can never

be reused in encryption under the same key with differing inputs.
Analysis: GCM relies on the CTR mode. Then, all the I5
implementation pitfalls of the CTR operation shall be considered. I6
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

266. In case the TOE implements authenticated encryption cryptographic

constructions based on the EAX scheme:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with authenticated encryption cryptographic constructions based on
the EAX scheme.
• The tester shall perform the following cryptographic evaluation test:

Centro Criptológico Nacional 16

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-PITFALL/EAX Inputs

In the case of CL2 evaluations, verify using I5 that all the

implementation pitfalls of the CTR operation mode and the CMAC
scheme are considered.
Analysis: EAX relies on the CTR mode for encryption and the I5
OMAC mechanism (which is very similar or equivalent to CMAC) I6
for authentication.
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

5.3.1.1.1.5 Key Protection

267. In case the TOE implements key protection cryptographic constructions based
on the SIV scheme:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with key protection cryptographic constructions based on the SIV
scheme.
• The tester shall perform the following cryptographic evaluation tests:

CCN-PITFALL/SIV.1 Inputs

In the case of CL2 evaluations, verify using I5 that all the

implementation pitfalls of the CTR operation mode and the CMAC
scheme are considered.
I5
Analysis: SIV relies on the CTR mode for encryption and the CMAC
mechanism for authentication. I6

In the case of CL3 evaluations, use I5 and perform a source code

review (using I6) to verify the above-mentioned.

CCN-PITFALL/SIV.2 Inputs

In the case of CL2 evaluations, verify using I5 that, when the SIV
scheme uses associated data, at most 𝑛𝑛 - 2 associated data
components are used as inputs of the SIV scheme, where 𝑛𝑛
denotes the block size of the underlying block cipher. I5
Analysis: As AES is the only underlying function in SIV specification I6
[RFC-5297], it limits the number of associated data to 126.
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

Centro Criptológico Nacional 17

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

268. In case the TOE implements key protection cryptographic constructions based
on the Keywrap scheme:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with key protection cryptographic constructions based on the
Keywrap scheme.
• The tester shall perform the following cryptographic evaluation test:

CCN-PITFALL/Keywrap Inputs

In the case of CL2 evaluations, verify using I5 that plaintexts are

not larger than 254 - 1 semi blocks for Key Wrap without padding
and 232 - 1 bytes for Key Wrap with padding [SP800-38F]. I5
Analysis: This is to avoid any collision. I6
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

Note: In case the TOE implements key protection based on Authenticated Encryption
cryptographic mechanisms, the tester shall perform the evaluation tests from section
5.3.1.1.1.4 “Authenticated Encryption (AE)” depending on the implemented
mechanisms.

5.3.1.1.1.6 Key Derivation Functions (KDF)

269. In case the TOE implements key derivation cryptographic constructions:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with key derivation cryptographic constructions.
• The tester shall perform the following cryptographic evaluation test:

CCN-PITFALL/KeyDerivation Inputs

In the case of CL2 evaluations, verify using I5 that invalid requests

for the keying data generation are not possible.
Analysis: The computation of the derived key starts with some size
controls and that shall not be ignored. In particular, the tester shall
verify that no derived key is larger than:
I5
- 255 × ℎ for HKDF constructions
I6
- (232 - 1) × ℎ for the rest of the key derivation functions
where ℎ is the length (in bits) of the output block of the
underlying hash function or pseudo-random function.
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

Centro Criptológico Nacional 17

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

5.3.1.1.2 Asymmetric Elementary Primitives

5.3.1.1.2.1 RSA/Integer Factorization

270. In case the TOE implements asymmetric cryptographic primitives based on the
integer factorization problem (RSA):
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with an asymmetric cryptographic primitive based on the integer
factorization problem (RSA).
• The tester shall perform the following cryptographic evaluation tests:

CCN-PITFALL/RSA Inputs

In the case of CL2 evaluations, verify using I5 that all RSA public
exponents in the system are greater than 216.
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned. I5
Note: If the TOE implements RSA key pair generation, the I6
successful verification of the CCN-AGREED/RSAKeys evaluation
test implies the successful verification of this test. The inverse is
not true.

CCN-PITFALL/RSAParameter.1 Inputs

In the case of CL2 evaluations, verify using I5 that 𝑝𝑝 and 𝑞𝑞, have
the same bit length and that their product has the required
modulus bit length. Moreover, the following condition shall be
satisfied:
𝑛𝑛
|𝑝𝑝 − 𝑞𝑞| ≥ 22 −100
where n denotes the bit length of the modulus.
Analysis: For this test, the tester shall check if the condition is
I5
implemented in the source code or check the randomness of 𝑝𝑝 and
𝑞𝑞. In the latter case, the probability that the condition is not I6
satisfied is negligible [FIPS-186-4].
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.
Note: If the TOE implements RSA key pair generation, the
successful verification of the CCN-AGREED/RSAKeys evaluation
test implies the successful verification of this test. The inverse is
not true.

Centro Criptológico Nacional 17

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-PITFALL/RSAParameter.2 Inputs

In the case of CL2 evaluations, verify using I5 that 𝑑𝑑 is larger than

2𝑛𝑛/2, where n denotes the bit length of the modulus.
Analysis: For this test, the tester shall check if the condition is
implemented in the source code or check that 𝑑𝑑 has been chosen
after a small public exponent 𝑒𝑒 has been generated.
I5
In the case of CL3 evaluations, use I5 and perform a source code
I6
review (using I6) to verify the above-mentioned.
Note: If the TOE implements RSA key pair generation, the
successful verification of the CCN-AGREED/RSAKeys evaluation
test implies the successful verification of this test. The inverse is
not true.

5.3.1.1.2.2 Multiplicative Discrete Logarithm Problem

271. In case the TOE implements asymmetric cryptographic primitives based on
FFDLOG:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with asymmetric cryptographic primitives based on FFDLOG.
• The tester shall perform the following cryptographic evaluation tests:

CCN-PITFALL/FFDLOG.1 Inputs

In the case of CL2 evaluations, verify using I5 that 𝑟𝑟 is greater than

200 bits.
Analysis: In addition, it is recommended that the size of 𝑟𝑟 be I5
greater than 250 bits. I6
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

CCN-PITFALL/FFDLOG.2 Inputs

In the case of CL2 evaluations, verify using I5 that the system only
manipulates correct values 𝑦𝑦. These values must have order
divisible by 𝑟𝑟 and dividing 𝑞𝑞. Particularly, points received from I5
another entity shall be verified by the system.
I6
Analysis: This requirement ensures that the manipulated values
do not lie in subgroups of small size (i.e., ≤ 250 bits) or outside the
intended group.

Centro Criptológico Nacional 17

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-PITFALL/FFDLOG.2 Inputs

If 𝑞𝑞 is prime, 𝑟𝑟 = 𝑞𝑞 and the system shall verify that manipulated

values have exact order 𝑞𝑞. It is advised to pick a subgroup of prime
numbers.
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

5.3.1.1.2.3 Additive Discrete Logarithm Problem

272. In case the TOE implements asymmetric cryptographic primitives based on
ECDLOG:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with asymmetric cryptographic primitives based on ECDLOG.
• The tester shall perform the following cryptographic evaluation test:

CCN-PITFALL/ECDLOG Inputs

In the case of CL2 evaluations, verify using I5 that the system only
manipulates points lying on the intended curve. In addition, if a
curve with a non-prime order is used, the points shall be in the
intended subgroup. Particularly, points received from another
entity shall be verified.
Analysis: This test is required when points are received from
another entity. In this case, the system shall verify that, before
I5
being used, the manipulated points lie on the curve and are in the
intended subgroup. Otherwise, the Invalid Curve Attack [JSS15] I6
can be possible.
If 𝑞𝑞 is prime, 𝑟𝑟 = 𝑞𝑞 and the tester shall verify that manipulated
points have exact order 𝑞𝑞. It is advised to pick a subgroup of prime
numbers.
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

5.3.1.1.3 Asymmetric Constructions

273. In case the TOE implements asymmetric cryptographic constructions:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with asymmetric cryptographic constructions.
• The tester shall perform the following cryptographic evaluation test:

Centro Criptológico Nacional 17

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-PITFALL/AsymConstruction Inputs

In the case of CL2 evaluations, verify using I5 that all the

implementation pitfalls of the underlying mechanisms are
considered.
I5
Analysis: Pitfalls related to the asymmetric primitives, the hash
functions, the DRG, and/or block ciphers shall be considered. I6

In the case of CL3 evaluations, use I5 and perform a source code

review (using I6) to verify the above-mentioned.

5.3.1.1.3.1 Asymmetric Encryption Scheme

274. In case the TOE implements asymmetric encryption cryptographic constructions
based on the RSA asymmetric primitive:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with asymmetric encryption cryptographic constructions based on
the RSA primitive.
• The tester shall perform the following cryptographic evaluation test:

CCN-PITFALL/AsymEncryption Inputs

In the case of CL2 evaluations, verify using I5 that the attacker

cannot access the specific error condition that can occur during
the decoding of an encoded message.
I5
Analysis: If the attacker can distinguish errors, attacks such as the
chosen ciphertext attack [Man01] for OAEP can be performed. I6

In the case of CL3 evaluations, use I5 and perform a source code

review (using I6) to verify the above-mentioned.

275. In case the TOE implements asymmetric encryption cryptographic constructions

based on the RSA-PKCS#1v1.5 scheme:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with asymmetric encryption cryptographic constructions based on
the RSA-PKCS#1v1.5 scheme.
• The tester shall perform the following cryptographic evaluation test:

Centro Criptológico Nacional 17

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-PITFALL/RSAPKCS Inputs

In the case of CL2 evaluations, verify using I5 that a padding oracle

is not available to an attacker, or that all attacks similar to
Bleichenbacher's attack are taken care of with efficient
countermeasures.
Analysis: Bleichenbacher’s attack is an example of an attack
targeting this encryption scheme using an oracle. In the case
where countermeasures are applied, the tester shall equivalently I5
verify that the system handles in the same way:
I6
- An incorrectly encoded ciphertext, and,
- A correctly encoded ciphertext that has been obtained
from a relation with another valid ciphertext rather than
the encryption operation.
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

5.3.1.1.3.2 Digital Signature

276. In case the TOE implements digital signature cryptographic constructions:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with digital signature cryptographic constructions.
• The tester shall perform the following cryptographic evaluation test:

CCN-PITFALL/AsymAuth Inputs

In the case of CL2 evaluations, verify using I5 that the private key
is not used for different purposes (signature and authentication). I5
In the case of CL3 evaluations, use I5 and perform a source code I6
review (using I6) to verify the above-mentioned.

277. In case the TOE implements digital signature constructions based on the XMSS
scheme:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with digital signature constructions based on the XMSS scheme.
• The tester shall perform the following cryptographic evaluation tests:

Centro Criptológico Nacional 17

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-PITFALL/XMSS.1 Inputs

In the case of CL2 evaluations, verify using I5 that the private key
is updated each time a message is signed.
Analysis: The method employed by the TOE to perform the
verification shall be evaluated. If the key is stored in non-volatile I5
memory, it must be ensured that the private key is updated in the
non-volatile memory before exporting the corresponding I6
signature.
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

CCN-PITFALL/XMSS.2 Inputs

In the case of CL2 evaluations, verify using I5 that the same private
key and the same counter are not used to sign different
documents.
Analysis: The method employed by the TOE to perform the I5
verification shall be evaluated. Moreover, appropriate
precautions must be taken to prevent this issue during the process I6
of recovering a backup copy.
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

CCN-PITFALL/XMSS.3 Inputs

In the case of CL2 evaluations, verify using I5 that, before

generating the signature of a message, the private key counter
does not exceed the maximum allowed by the established
parameters. I5
Analysis: The method employed by the TOE to perform the I6
verification shall be evaluated.
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

Centro Criptológico Nacional 17

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-PITFALL/XMSS.4 Inputs

In the case of CL2 evaluations, verify using I5 that the derivation

of the WOTS+ keys is performed as specified in [SP800-208], that
is, using the PRF_keygen function to prevent multi-target attacks.
I5
Analysis: The method employed by the TOE to perform the
verification shall be evaluated. I6

In the case of CL3 evaluations, use I5 and perform a source code

review (using I6) to verify the above-mentioned.

5.3.1.1.3.3 Key Establishment

278. In case the TOE implements key establishment cryptographic constructions:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with key establishment cryptographic constructions.
• The tester shall perform the following cryptographic evaluation test:

CCN-PITFALL/KeyEstablishment Inputs

In the case of CL2 evaluations, verify using I5 that, if a secret is

generated from a preexisting secret, this preexisting secret has at
least 100 bits of entropy.
Analysis: Ephemeral keys generated using the Diffie-Hellman
scheme and master secret used in TLS record protocol are
examples of such preexisting secrets. In accordance with the
entropy of such preexisting secrets, e.g., each ephemeral Diffie-
Hellman private key in the former example, must be at least 100
bits for legacy mechanisms and 125 bits for recommended
I5
mechanisms.
I6
The successful verification of the CCN-AGREED/TRNGEntropy
evaluation test ensures that the average entropy per internal
random bit exceeds a certain minimum close to 1. If the previous
minimum is met, verifying that a bit string contains at least 100
bits of entropy entails checking that its length is at least 101 bits.
Verifying that a bit string contains at least 125 bits of entropy
entails checking that its length is at least 126 bits.
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

279. In case the TOE implements key establishment cryptographic constructions

based on FFDLOG primitive:

Centro Criptológico Nacional 17

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

• The TOE shall implement mechanisms to avoid implementation pitfalls

associated with key establishment cryptographic constructions based on
FFDLOG.
• The tester shall perform the following cryptographic evaluation test:

CCN-PITFALL/FFKeyEstablishment Inputs

In the case of CL2 evaluations, verify using I5 that CCN-

PITFALL/FFDLOG.1 and CCN-PITFALL/FFDLOG.2 are considered.
Analysis: The manipulated values have order divisible by 𝑟𝑟 and I5
dividing 𝑞𝑞. I6
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

280. In case the TOE implements key establishment cryptographic constructions

based on ECDLOG primitive:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with key establishment cryptographic constructions based on
ECDLOG.
• The tester shall perform the following cryptographic evaluation test:

CCN-PITFALL/ECKeyEstablishment Inputs

In the case of CL2 evaluations, verify using I5 that CCN-

PITFALL/ECDLOG is considered.
Analysis: The point from the other entity shall lie on the curve and I5
be in the intended subgroup. I6
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

5.3.1.1.4 Random Number Generators

5.3.1.1.4.1 Deterministic Random Number Generators

281. In case the TOE implements deterministic random number generators (DRNG):
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with deterministic random number generator (DRNG)
implementations.
• The tester shall perform the following cryptographic evaluation tests:

Centro Criptológico Nacional 17

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-PITFALL/DRG.1 Inputs

In the case of CL2 evaluations, verify using I5 that the entropy of

the seed is at least 125 bits long. For this purpose, identify the
random sources used to seed for instantiating and reseed for
updating the internal state of the DRG, and analyze their random
quality.
Analysis: The successful verification of the CCN- I5
AGREED/TRNGEntropy evaluation test ensures that the average
entropy per internal random bit exceeds a certain minimum close I6
to 1. If the previous minimum is met, verifying that the seed
contains at least 125 bits of entropy entails checking that its length
is at least 126 bits.
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

CCN-PITFALL/DRG.2 Inputs

In the case of CL2 evaluations, verify using I5 that the internal state
of the DRG is periodically reseeded with the random source to
ensure enough entropy in case of the generation of a large random
quantity.
Analysis: In some implementations (such as smartcards), I5
reseeding may not be possible and an alternative to reseeding I6
shall be to create an entirely new instantiation (to obtain a new
seed and guarantee enough entropy in the DRG internal state).
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

282. In case the TOE implements deterministic random number generators (DRNG)
based on CTR symmetric encryption constructions:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with deterministic random number generator (DRNG) based on CTR
symmetric encryption constructions.
• The tester shall perform the following cryptographic evaluation test:

Centro Criptológico Nacional 18

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-PITFALL/CTRDRBG Inputs

In the case of CL2 evaluations, verify using I5 that a single

invocation of the CTR-DRBG generate function is not done for the
generation of several different keys, if the property of perfect
forward secrecy is required in the system. I5
Analysis: The backtracking resistance of CTR-DRBG is only given I6
for the transition function between different invocations.
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

5.3.1.1.5 Key Management

283. In case the TOE implements key management procedures:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with key management procedures.
• The tester shall perform the following cryptographic evaluation test:

CCN-PITFALL/KeyManagement Inputs

In the case of CL2 evaluations, verify using I5 that the variable

memory allocated for a key is locked when it is manipulated by the
I5
system.
I6
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

5.3.1.1.5.1 Key Storage and Transport

284. In case the TOE implements key transport procedures:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with key transport procedures.
• The tester shall perform the following cryptographic evaluation test:

Centro Criptológico Nacional 18

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

CCN-PITFALL/KeyTransport Inputs

In the case of CL2 evaluations, verify using I5 that the key

distribution channel is protected in authenticity and integrity for
public keys and secret keys. In addition, secret keys shall be
protected in confidentiality.
Analysis: Some cryptographic keys must be distributed between
identified users, allowing them to access sensitive data protected I5
by the related cryptosystems. So, the protection of the key I6
distribution channel is crucial. Also, if the system allows users to
load their secret key generated outside the system, the tester shall
check that the secret key has not been modified during import.
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

5.3.1.1.5.2 Key Usage

285. In case the TOE implements key usage procedures:
• The TOE shall implement mechanisms to avoid implementation pitfalls
associated with key usage procedures.
• The tester shall perform the following cryptographic evaluation test:

CCN-PITFALL/KeyUsage Inputs

In the case of CL2 evaluations, verify using I5 that each key has
only one usage.
Analysis: A key must not be used with different mechanisms or
contexts, otherwise an attacker could exploit a source of errors in I5
the usage of the key. This does not forbid to derive various keys I6
from a master key.
In the case of CL3 evaluations, use I5 and perform a source code
review (using I6) to verify the above-mentioned.

Centro Criptológico Nacional 18

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

6 ANNEX A: TRACEABILITY OF EVALUATION TASKS

286. This annex summarizes the evaluation tasks related to each cryptographic
mechanism. The objective is to provide the tester with the complete list of
evaluation tasks to be performed in order to evaluate each agreed cryptographic
mechanism.
287. The reason to list the evaluation tasks for each construction instead of for each
primitive is that the cryptographic functionality of the TOE relies on the
execution of cryptographic constructions instead of primitives. Moreover, for
each construction, the evaluation tasks related to its underlying primitives will
be performed.

6.1 SYMMETRIC CRYPTOGRAPHIC MECHANISMS

6.1.1 HASH FUNCTIONS

288. The following table summarizes the evaluation tasks to be performed for the
SHA-2 family of the hash cryptographic functions:

Summary of Evaluation Tasks for SHA-2 Primitives

Evaluation Task Evaluation Test Code
Primitive
CCN-MECHANISM
CCN-MECHANISM/Hash
Primitive
CCN-AGREED
CCN-AGREED/Hash
Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 55)
Primitive
CCN-PITFALL N/A because there are no implementation pitfalls for
the SHA cryptographic primitive

Table 70. Summary of Evaluation Tasks for SHA-2 Primitives

289. The following table summarizes the evaluation tasks to be performed for the
SHA-3 family of the hash cryptographic functions:

Summary of Evaluation Tasks for SHA-3 Primitives

Evaluation Task Evaluation Test Code
Primitive
CCN-MECHANISM
CCN-MECHANISM/Hash
Primitive
CCN-AGREED
CCN-AGREED/Hash

Centro Criptológico Nacional 18

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for SHA-3 Primitives

Evaluation Task Evaluation Test Code
Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 55)
Primitive
CCN-PITFALL N/A because there are no implementation pitfalls for
the SHA cryptographic primitive

Table 71. Summary of Evaluation Tasks for SHA-3 Primitives

6.1.2 SECRET SHARING

290. The following table summarizes the evaluation tasks to be performed for the
Secret Sharing cryptographic primitives:

Summary of Evaluation Tasks for Secret Sharing Primitives

Evaluation Task Evaluation Test Code
Primitive
CCN-MECHANISM
CCN-MECHANISM/SecretSharing
Primitive
CCN-AGREED
CCN-AGREED/SecretSharing
Primitive
CCN-CONFORMITY N/A because there are no conformity tests for the
Secret Sharing cryptographic primitive
Primitive
CCN-PITFALL N/A because there are no implementation pitfalls for
the Secret Sharing cryptographic primitive

Table 72. Summary of Evaluation Tasks for Secret Sharing Primitives

6.1.3 SYMMETRIC ENCRYPTION (CONFIDENTIALITY ONLY)

291. The following table summarizes the evaluation tasks to be performed for the CBC
operation mode of the AES symmetric cryptographic primitive:

Summary of Evaluation Tasks for CBC Encryption Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM
CCN-MECHANISM/SymEncryption

Centro Criptológico Nacional 18

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for CBC Encryption Constructions

Evaluation Task Evaluation Test Code
Underlying Primitive
CCN-MECHANISM/BlockCipher
Construction
CCN-AGREED/SymEncryption
Notes
Note 4 [IV Type]
CCN-AGREED
Note 5 [Add Integrity]
Note 7 [Padding]
Underlying Primitive
CCN-AGREED/BlockCipher
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 57)
Construction
CCN-PITFALL/SymEncryption.1
CCN-PITFALL/SymEncryption.2
CCN-PITFALL
Underlying Primitive
N/A because there are no implementation pitfalls for
the AES cryptographic primitive

Table 73. Summary of Evaluation Tasks for CBC Encryption Constructions

292. The following table summarizes the evaluation tasks to be performed for the
CBC-CS operation mode of the AES symmetric cryptographic primitive:

Summary of Evaluation Tasks for CBC-CS Encryption Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/SymEncryption
CCN-MECHANISM
Underlying Primitive
CCN-MECHANISM/BlockCipher
Construction
CCN-AGREED/SymEncryption
CCN-AGREED Notes
Note 4 [IV Type]
Note 5 [Add Integrity]

Centro Criptológico Nacional 18

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for CBC-CS Encryption Constructions

Evaluation Task Evaluation Test Code
Underlying Primitive
CCN-AGREED/BlockCipher
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 57)
Construction
CCN-PITFALL/SymEncryption.1
CCN-PITFALL Underlying Primitive
N/A because there are no implementation pitfalls for
the AES cryptographic primitive

Table 74. Summary of Evaluation Tasks for CBC-CS Encryption Constructions

293. The following table summarizes the evaluation tasks to be performed for the CFB
operation mode of the AES symmetric cryptographic primitive:

Summary of Evaluation Tasks for CFB Encryption Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/SymEncryption
CCN-MECHANISM
Underlying Primitive
CCN-MECHANISM/BlockCipher
Construction
CCN-AGREED/SymEncryption
Notes
Note 4 [IV Type]
CCN-AGREED
Note 5 [Add Integrity]
Note 7 [Padding]
Underlying Primitive
CCN-AGREED/BlockCipher
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 57)
Construction
CCN-PITFALL CCN-PITFALL/SymEncryption.1
Underlying Primitive

Centro Criptológico Nacional 18

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for CFB Encryption Constructions

Evaluation Task Evaluation Test Code
N/A because there are no implementation pitfalls for
the AES cryptographic primitive

Table 75. Summary of Evaluation Tasks for CFB Encryption Constructions

294. The following table summarizes the evaluation tasks to be performed for the CTR
operation mode of the AES symmetric cryptographic primitive:

Summary of Evaluation Tasks for CTR Encryption Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/SymEncryption
CCN-MECHANISM
Underlying Primitive
CCN-MECHANISM/BlockCipher
Construction
CCN-AGREED/SymEncryption
Notes
Note 4 [IV Type]
CCN-AGREED
Note 5 [Add Integrity]
Note 6 [Stream Mode]
Underlying Primitive
CCN-AGREED/BlockCipher
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 57)
Construction
CCN-PITFALL/SymEncryption.1
CCN-PITFALL/CTR
CCN-PITFALL
Underlying Primitive
N/A because there are no implementation pitfalls for
the AES cryptographic primitive

Table 76. Summary of Evaluation Tasks for CTR Encryption Constructions

295. The following table summarizes the evaluation tasks to be performed for the
OFB operation mode of the AES symmetric cryptographic primitive:

Centro Criptológico Nacional 18

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for OFB Encryption Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/SymEncryption
CCN-MECHANISM
Underlying Primitive
CCN-MECHANISM/BlockCipher
Construction
CCN-AGREED/SymEncryption
Notes
Note 4 [IV Type]
CCN-AGREED
Note 5 [Add Integrity]
Note 6 [Stream Mode]
Underlying Primitive
CCN-AGREED/BlockCipher
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 57)
Construction
CCN-PITFALL/SymEncryption.1
CCN-PITFALL Underlying Primitive
N/A because there are no implementation pitfalls for
the AES cryptographic primitive

Table 77. Summary of Evaluation Tasks for OFB Encryption Constructions

6.1.4 DISK ENCRYPTION

296. The following table summarizes the evaluation tasks to be performed for the XTS
operation mode of the AES symmetric cryptographic primitive:

Summary of Evaluation Tasks for XTS Disk Encryption Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/DiskEncryption
CCN-MECHANISM
Underlying Primitive
CCN-MECHANISM/BlockCipher
Construction
CCN-AGREED
CCN-AGREED/DiskEncryption

Centro Criptológico Nacional 18

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for XTS Disk Encryption Constructions

Evaluation Task Evaluation Test Code
Notes
Note 8 [Unique Tweak]
Note 9 [XTS Key]
Underlying Primitive
CCN-AGREED/BlockCipher
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 58)
Construction
CCN-PITFALL/DiskEncryption
CCN-PITFALL/XTS
CCN-PITFALL
Underlying Primitive
N/A because there are no implementation pitfalls for
the AES cryptographic primitive

Table 78. Summary of Evaluation Tasks for XTS Disk Encryption Constructions

6.1.5 INTEGRITY MODES: MESSAGE AUTHENTICATION CODE

297. The following table summarizes the evaluation tasks to be performed for the
CMAC scheme based on the AES symmetric cryptographic primitive:

Summary of Evaluation Tasks for CMAC Constructions based on AES

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/MAC
CCN-MECHANISM
Underlying Primitive
CCN-MECHANISM/BlockCipher
Construction
CCN-AGREED/MAC
Notes
CCN-AGREED Note 10 [MAC Truncation 96 bits]
Note 11 [MAC Truncation 64 bits]
Underlying Primitive
CCN-AGREED/BlockCipher
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 59)

Centro Criptológico Nacional 18

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for CMAC Constructions based on AES

Evaluation Task Evaluation Test Code
Construction
N/A because there are no implementation pitfalls for
the CMAC cryptographic construction
CCN-PITFALL
Underlying Primitive
N/A because there are no implementation pitfalls for
the AES cryptographic primitive

Table 79. Summary of Evaluation Tasks for CMAC Constructions based on AES
298. The following table summarizes the evaluation tasks to be performed for the
CBC-MAC scheme based on the AES symmetric cryptographic primitive:

Summary of Evaluation Tasks for CBC-MAC Constructions based on AES

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/MAC
CCN-MECHANISM
Underlying Primitive
CCN-MECHANISM/BlockCipher
Construction
CCN-AGREED/MAC
Notes
Note 10 [MAC Truncation 96 bits]
CCN-AGREED
Note 11 [MAC Truncation 64 bits]
Note 12 [Fixed Input Length]
Underlying Primitive
CCN-AGREED/BlockCipher
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 59)
Construction
CCN-PITFALL/CBCMAC
CCN-PITFALL Underlying Primitive
N/A because there are no implementation pitfalls for
the AES cryptographic primitive

Table 80. Summary of Evaluation Tasks for CBC-MAC Constructions based on AES
299. The following table summarizes the evaluation tasks to be performed for the
HMAC scheme based on SHA cryptographic primitive:

Centro Criptológico Nacional 19

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for HMAC Constructions based on SHA

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/MAC
CCN-MECHANISM
Underlying Primitive
CCN-MECHANISM/Hash
Construction
CCN-AGREED/MAC
Notes
Note 10 [MAC Truncation 96 bits]
CCN-AGREED
Note 11 [MAC Truncation 64 bits]
Note 13 [HMAC-SHA-1]
Underlying Primitive
CCN-AGREED/Hash
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 59)
Construction
N/A because there are no implementation pitfalls for
the HMAC cryptographic constructions
CCN-PITFALL
Underlying Primitive
N/A because there are no implementation pitfalls for
the SHA cryptographic primitive

Table 81. Summary of Evaluation Tasks for HMAC Constructions based on SHA
300. The following table summarizes the evaluation tasks to be performed for the
GMAC scheme based on the AES symmetric cryptographic primitive:

Summary of Evaluation Tasks for GMAC Constructions based on AES

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/MAC
CCN-MECHANISM
Underlying Primitive
CCN-MECHANISM/BlockCipher
Construction
CCN-AGREED CCN-AGREED/MAC
Notes

Centro Criptológico Nacional 19

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for GMAC Constructions based on AES

Evaluation Task Evaluation Test Code
Note 14 [GMAC-GCM Nonce]
Note 15 [GMAC-GCM Options]
Note 16 [GMAC-GCM Bounds]
Underlying Primitive
CCN-AGREED/BlockCipher
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 59)
Construction
N/A because there are no implementation pitfalls for
the GMAC cryptographic construction
CCN-PITFALL
Underlying Primitive
N/A because there are no implementation pitfalls for
the AES cryptographic primitive

Table 82. Summary of Evaluation Tasks for GMAC Constructions based on AES
301. The following table summarizes the evaluation tasks to be performed for the
KMAC scheme based on XOF cryptographic primitive:

Summary of Evaluation Tasks for KMAC Constructions based on XOF

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/MAC
CCN-MECHANISM
Underlying Primitive
CCN-MECHANISM/XOF
Construction
CCN-AGREED/MAC
Notes
Note 17 [KMAC Security Settings]
CCN-AGREED
Underlying Primitive
CCN-AGREED/XOF
Notes
Note 3 [Agreed XOF]
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 59)

Centro Criptológico Nacional 19

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for KMAC Constructions based on XOF

Evaluation Task Evaluation Test Code
Construction
N/A because there are no implementation pitfalls for
the KMAC cryptographic construction
CCN-PITFALL
Underlying Primitive
N/A because there are no implementation pitfalls for
the XOF cryptographic primitive

Table 83. Summary of Evaluation Tasks for KMAC Constructions based on XOF

6.1.6 SYMMETRIC ENTITY AUTHENTICATION SCHEMES

302. The following table summarizes the evaluation tasks to be performed for the
symmetric entity authentication schemes (challenge-response protocol). It is
mandatory to perform the evaluation tasks associated with the underlying
constructions:
- The tester shall perform the evaluation tasks defined in section 6.1.3
“Symmetric Encryption (Confidentiality Only)” for the underlying
symmetric encryption constructions.
- The tester shall perform the evaluation tasks defined in section 6.1.5
“Integrity Modes: Message Authentication Code” for the underlying MAC
constructions.

Summary of Evaluation Tasks for Entity Authentication Schemes

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM
CCN-MECHANISM/EntityAuth
Construction
CCN-AGREED/EntityAuth
CCN-AGREED
Notes
Note 19 [Challenge-Response Protocol]
Construction and Underlying Mechanisms
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 60)
Construction
CCN-PITFALL N/A because there are no implementation pitfalls for
the symmetric entity authentication schemes

Table 84. Summary of Evaluation Tasks for Entity Authentication Schemes

Centro Criptológico Nacional 19

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

6.1.7 AUTHENTICATED ENCRYPTION (AE)

303. The following table summarizes the evaluation tasks to be performed for the
Encrypt-then-MAC schemes. It is mandatory to perform the evaluation tasks
associated with the underlying constructions:
- The tester shall perform the evaluation tasks defined in section 6.1.3
“Symmetric Encryption (Confidentiality Only)” for the underlying
symmetric encryption constructions.
- The tester shall perform the evaluation tasks defined in section 6.1.5
“Integrity Modes: Message Authentication Code” for the underlying MAC
constructions.

Summary of Evaluation Tasks for Encrypt-then-MAC Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM
CCN-MECHANISM/AuthEncryption
Construction
CCN-AGREED/AuthEncryption
CCN-AGREED Notes
Note 20 [Authenticated Encryption Schemes]
Note 21 [Decryption Order]
Construction and Underlying Mechanisms
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 61)
Construction
CCN-PITFALL/AuthEncryption
CCN-PITFALL
CCN-PITFALL/AuthEncryptionComb.1
CCN-PITFALL/AuthEncryptionComb.2

Table 85. Summary of Evaluation Tasks Encrypt-then-MAC Constructions

304. The following table summarizes the evaluation tasks to be performed for the
CCM scheme of the AES symmetric cryptographic primitive:

Summary of Evaluation Tasks for CCM AE Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/AuthEncryption
CCN-MECHANISM
Underlying Primitive
CCN-MECHANISM/BlockCipher
CCN-AGREED Construction

Centro Criptológico Nacional 19

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for CCM AE Constructions

Evaluation Task Evaluation Test Code
CCN-AGREED/AuthEncryption
Notes
Note 20 [Authenticated Encryption Schemes]
Note 21 [Decryption Order]
Underlying Primitive
CCN-AGREED/BlockCipher
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 61)
Construction
CCN-PITFALL/AuthEncryption
CCN-PITFALL/CCM
CCN-PITFALL
Underlying Primitive
N/A because there are no implementation pitfalls for
the AES cryptographic primitive

Table 86. Summary of Evaluation Tasks for CCM AE Constructions

305. The following table summarizes the evaluation tasks to be performed for the
GCM scheme of the AES symmetric cryptographic primitive:

Summary of Evaluation Tasks for GCM AE Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/AuthEncryption
CCN-MECHANISM
Underlying Primitive
CCN-MECHANISM/BlockCipher
Construction
CCN-AGREED/AuthEncryption
Notes
Note 14 [GMAC-GCM Nonce]
Note 15 [GMAC-GCM Options]
CCN-AGREED
Note 16 [GMAC-GCM Bounds]
Note 20 [Authenticated Encryption Schemes]
Note 21 [Decryption Order]
Note 22 [GCM Plaintext Length]
Underlying Primitive

Centro Criptológico Nacional 19

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for GCM AE Constructions

Evaluation Task Evaluation Test Code
CCN-AGREED/BlockCipher
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 61)
Construction
CCN-PITFALL/AuthEncryption
CCN-PITFALL/GCM.1
CCN-PITFALL CCN-PITFALL/GCM.2
Underlying Primitive
N/A because there are no implementation pitfalls for
the AES cryptographic primitive

Table 87. Summary of Evaluation Tasks for GCM AE Constructions

306. The following table summarizes the evaluation tasks to be performed for the
EAX scheme of the AES symmetric cryptographic primitive:

Summary of Evaluation Tasks for EAX AE Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/AuthEncryption
CCN-MECHANISM
Underlying Primitive
CCN-MECHANISM/BlockCipher
Construction
CCN-AGREED/AuthEncryption
Notes
CCN-AGREED Note 20 [Authenticated Encryption Schemes]
Note 21 [Decryption Order]
Underlying Primitive
CCN-AGREED/BlockCipher
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 61)
Construction
CCN-PITFALL/AuthEncryption
CCN-PITFALL CCN-PITFALL/EAX
Underlying Primitive

Centro Criptológico Nacional 19

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for EAX AE Constructions

Evaluation Task Evaluation Test Code
N/A because there are no implementation pitfalls for
the AES cryptographic primitive

Table 88. Summary of Evaluation Tasks for EAX AE Constructions

307. The following table summarizes the evaluation tasks to be performed for the
ChaCha20-Poly1305 symmetric cryptographic construction:

Summary of Evaluation Tasks for ChaCha20-Poly1305 AE Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/AuthEncryption
CCN-MECHANISM Underlying Primitive and Construction
CCN-MECHANISM/StreamCipher
CCN-MECHANISM/MAC
Construction
CCN-AGREED/AuthEncryption
Notes
Note 23 [ChaCha20-Poly1305 IV]
Underlying Primitive and Construction
CCN-AGREED
CCN-AGREED/StreamCipher
CCN-AGREED/MAC
Notes
Note 1 [ChaCha20 Implementation]
Note 18 [Poly1305 Implementation]
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 61)
Construction
CCN-PITFALL/AuthEncryption
CCN-PITFALL Underlying Primitive and Construction
N/A because there are no implementation pitfalls for
the ChaCha20 and Poly1305 cryptographic mechanisms

Table 89. Summary of Evaluation Tasks for ChaCha20-Poly1305 AE Constructions

Centro Criptológico Nacional 19

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

6.1.8 KEY PROTECTION

308. The following table summarizes the evaluation tasks to be performed for the SIV
scheme of the AES symmetric cryptographic primitive. It is mandatory to
perform the evaluation tasks associated with the underlying constructions:
- The tester shall perform the evaluation tasks defined in Table 76 for the
CTR underlying construction.
- The tester shall perform the evaluation tasks defined in Table 79 for the
CMAC underlying construction.

Summary of Evaluation Tasks for SIV Key Protection Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM
CCN-MECHANISM/KeyProtection
Construction
CCN-AGREED
CCN-AGREED/KeyProtection
Construction and Underlying Mechanisms
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 62)
Construction
CCN-PITFALL CCN-PITFALL/SIV.1
CCN-PITFALL/SIV.2

Table 90. Summary of Evaluation Tasks for SIV Key Protection Constructions
309. The following table summarizes the evaluation tasks to be performed for the
Keywrap scheme of the AES symmetric cryptographic primitive:

Summary of Evaluation Tasks for Keywrap Key Protection Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/KeyProtection
CCN-MECHANISM
Underlying Primitive
CCN-MECHANISM/BlockCipher
Construction
CCN-AGREED/KeyProtection
CCN-AGREED
Underlying Primitive
CCN-AGREED/BlockCipher
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 62)

Centro Criptológico Nacional 19

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for Keywrap Key Protection Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-PITFALL/Keywrap
CCN-PITFALL Underlying Primitive
N/A because there are no implementation pitfalls for
the AES cryptographic primitive

Table 91. Summary of Evaluation Tasks for Keywrap Key Protection Constructions
Note: In case the TOE implements key protection based on Authenticated Encryption
cryptographic mechanisms, the tester shall perform the evaluation task detailed in
section 6.1.7 “Authenticated Encryption (AE)” depending on the implemented
mechanisms.

6.1.9 KEY DERIVATION FUNCTIONS

310. The following table summarizes the evaluation tasks to be performed for the
NIST SP800-56 A/B/C key derivation cryptographic construction. It is mandatory
to perform the evaluation tasks associated with the underlying mechanisms.
• For NIST SP800-56 A/B/C OneStep KDF based in HMAC:
- The tester shall perform the evaluation tasks defined in Table 81 for the
HMAC underlying constructions.
• For NIST SP800-56 A/B/C OneStep KDF based in KMAC:
- The tester shall perform the evaluation tasks defined in Table 83 for the
KMAC underlying constructions.
• For NIST SP800-56 A/B/C OneStep KDF based in SHA:
- The tester shall perform the evaluation tasks defined in Table 70 and/or
Table 71 for the hash underlying primitive.
• For NIST SP800-56 A/B/C TwoStep KDF based in HMAC:
- The tester shall perform the evaluation tasks defined in Table 81 for the
HMAC underlying constructions.
- The tester shall perform the evaluation tasks defined in Table 93 for the
SP800-108 KDF underlying constructions based on HMAC.
• For NIST SP800-56 A/B/C TwoStep KDF based in CMAC:
- The tester shall perform the evaluation tasks defined in Table 79 for the
CMAC underlying constructions.
- The tester shall perform the evaluation tasks defined in Table 93 for the
SP800-108 KDF underlying constructions based on CMAC.

Centro Criptológico Nacional 19

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for NIST SP800-56 A/B/C KDF

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM
CCN-MECHANISM/KeyDerivation
Construction
CCN-AGREED
CCN-AGREED/KeyDerivation
Construction and Underlying Mechanisms
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 63)
Construction
CCN-PITFALL
CCN-PITFALL/KeyDerivation

Table 92. Summary of Evaluation Tasks for NIST SP800-56 A/B/C KDF
311. The following table summarizes the evaluation tasks to be performed for the
NIST SP800-108 key derivation cryptographic construction. It is mandatory to
perform the evaluation tasks associated with the underlying constructions:
- The tester shall perform the evaluation tasks defined in Table 79 for the
CMAC underlying constructions.
- The tester shall perform the evaluation tasks defined in Table 81 for the
HMAC underlying constructions.
- The tester shall perform the evaluation tasks defined in Table 83 for the
KMAC underlying constructions.

Summary of Evaluation Tasks for NIST SP800-108 KDF

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM
CCN-MECHANISM/KeyDerivation
Construction
CCN-AGREED
CCN-AGREED/KeyDerivation
Construction and Underlying Mechanisms
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 63)
Construction
CCN-PITFALL
CCN-PITFALL/KeyDerivation

Table 93. Summary of Evaluation Tasks for NIST SP800-108 KDF

312. The following table summarizes the evaluation tasks to be performed for the
ANSI-X9.63 key derivation cryptographic construction:

Centro Criptológico Nacional 20

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for ANSI-X9.63 KDF

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/KeyDerivation
CCN-MECHANISM
Underlying Primitive
CCN-MECHANISM/Hash
Construction
CCN-AGREED/KeyDerivation
CCN-AGREED
Underlying Primitive
CCN-AGREED/Hash
Construction and Underlying Mechanisms
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 63)
Construction
CCN-PITFALL/KeyDerivation
CCN-PITFALL Underlying Primitive
N/A because there are no implementation pitfalls for
the SHA cryptographic primitive

Table 94. Summary of Evaluation Tasks for ANSI-X9.63 KDF

313. The following table summarizes the evaluation tasks to be performed for the
PBKDF2 key derivation cryptographic construction. It is mandatory to perform
the evaluation tasks associated with the underlying constructions:
- The tester shall perform the evaluation tasks defined in Table 81 for the
HMAC underlying constructions.

Summary of Evaluation Tasks for PBKDF2 Key Derivation Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM
CCN-MECHANISM/KeyDerivation
Construction
CCN-AGREED/KeyDerivation
CCN-AGREED
Notes
Note 24 [PBKDF2 PRF]
Construction and Underlying Mechanisms
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 63)
CCN-PITFALL Construction

Centro Criptológico Nacional 20

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for PBKDF2 Key Derivation Constructions

Evaluation Task Evaluation Test Code
CCN-PITFALL/KeyDerivation

Table 95. Summary of Evaluation Tasks for PBKDF2 Key Derivation Constructions
314. The following table summarizes the evaluation tasks to be performed for the
HKDF key derivation cryptographic construction. It is mandatory to perform the
evaluation tasks associated with the underlying constructions:
- The tester shall perform the evaluation tasks defined in Table 81 for the
HMAC underlying constructions.

Summary of Evaluation Tasks for HKDF Key Derivation Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM
CCN-MECHANISM/KeyDerivation
Construction
CCN-AGREED
CCN-AGREED/KeyDerivation
Construction and Underlying Mechanisms
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 63)
Construction
CCN-PITFALL
CCN-PITFALL/KeyDerivation

Table 96. Summary of Evaluation Tasks for HKDF Key Derivation Constructions

6.1.10 PASSWORD PROTECTION/HASHING MECHANISMS

315. The following table summarizes the evaluation tasks to be performed for the
Argon2id password protection/hashing mechanism.

Summary of Evaluation Tasks for Argon2id Password Protection

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/PasswordMechanisms
CCN-MECHANISM
Underlying Primitive
CCN-MECHANISM/Hash
Construction
CCN-AGREED CCN-AGREED/PasswordMechanisms
Notes

Centro Criptológico Nacional 20

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for Argon2id Password Protection

Evaluation Task Evaluation Test Code
Note 25 [Use of Argon2id]
Note 26 [Argon2id Parameters]
Underlying Primitive
CCN-AGREED/Hash
Notes
Note 2 [Agreed BLAKE2b]
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 64)
Construction
N/A because there are no implementation pitfalls for
the Argon2id cryptographic construction
CCN-PITFALL
Underlying Primitive
N/A because there are no implementation pitfalls for
the BLAKE2b cryptographic primitive

Table 97. Summary of Evaluation Tasks for Argon2id Password Protection

316. The following table summarizes the evaluation tasks to be performed for the
PBKDF2 password protection/hashing mechanism. It is mandatory to perform
the evaluation tasks associated with the underlying constructions:
- The tester shall perform the evaluation tasks defined in Table 81 for the
HMAC underlying constructions.

Summary of Evaluation Tasks for PBKDF2 Password Protection

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM
CCN-MECHANISM/PasswordMechanisms
Construction
CCN-AGREED/PasswordMechanisms
CCN-AGREED Notes
Note 27 [Number of Iterations]
Note 28 [Salt]
Construction and Underlying Mechanisms
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 64)
Construction
CCN-PITFALL
CCN-PITFALL/KeyDerivation

Centro Criptológico Nacional 20

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Table 98. Summary of Evaluation Tasks for PBKDF2 Password Protection

317. The following table summarizes the evaluation tasks to be performed for the
SCRYPT password protection/hashing mechanism. It is mandatory to perform
the evaluation tasks associated with the underlying constructions:
- The tester shall perform the evaluation tasks defined in Table 98 for the
PBKDF2 underlying construction.
- The tester shall perform the evaluation tasks defined in Table 81 for the
HMAC-SHA2-256 underlying construction.

Summary of Evaluation Tasks for SCRYPT Key Derivation Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM
CCN-MECHANISM/KeyDerivation
Construction
CCN-AGREED
CCN-AGREED/KeyDerivation
Construction and Underlying Mechanisms
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 64)
Construction
CCN-PITFALL
CCN-PITFALL/KeyDerivation

Table 99. Summary of Evaluation Tasks for SCRYPT Password Protection

Centro Criptológico Nacional 20

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

6.2 ASYMMETRIC CRYPTOGRAPHIC MECHANISMS

6.2.1 ASYMMETRIC ENCRYPTION SCHEMES

318. The following table summarizes the evaluation tasks to be performed for the
RSA OAEP asymmetric encryption construction:

Summary of Evaluation Tasks for RSA OAEP Encryption Scheme

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/AsymEncryption
CCN-MECHANISM Underlying Primitive
CCN-MECHANISM/RSA
CCN-MECHANISM/Hash
Construction
CCN-AGREED/AsymEncryption
Notes
Note 34 [Random Padding]
Note 35 [Padding-OAEP Attack]
Underlying Primitive
CCN-AGREED/RSA
CCN-AGREED/Hash
CCN-AGREED
RSA Key Pair Generation (if applicable)
CCN-AGREED/RSAKeys
Notes
Note 29 [Primes]
Note 61 [Primes from Uniform Distributions]
Note 62 [Miller-Rabin as Primality Test]
Note 63 [Miller-Rabin Parameters]
Note 60 [DRNG as Input]
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 65)
Construction
CCN-PITFALL/AsymConstruction
CCN-PITFALL CCN-PITFALL/AsymEncryption
Underlying Primitive

Centro Criptológico Nacional 20

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for RSA OAEP Encryption Scheme

Evaluation Task Evaluation Test Code
CCN-PITFALL/RSA
CCN-PITFALL/RSAParameter.1
CCN-PITFALL/RSAParameter.2

Table 100. Summary of Evaluation Tasks for RSA OAEP Asymmetric Encryption
319. The following table summarizes the evaluation tasks to be performed for the
RSA PKCS#1v1.5 asymmetric encryption construction:

Summary of Evaluation Tasks for RSA PKCS#1v1.5 Encryption Scheme

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/AsymEncryption
CCN-MECHANISM
Underlying Primitive
CCN-MECHANISM/RSA
Construction
CCN-AGREED/AsymEncryption
Notes
Note 34 [Random Padding]
Underlying Primitive
CCN-AGREED/RSA

CCN-AGREED RSA Key Pair Generation (if applicable)

CCN-AGREED/RSAKeys
Notes
Note 29 [Primes]
Note 61 [Primes from Uniform Distributions]
Note 62 [Miller-Rabin as Primality Test]
Note 63 [Miller-Rabin Parameters]
Note 60 [DRNG as Input]
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 65)
Construction
CCN-PITFALL/AsymConstruction
CCN-PITFALL
CCN-PITFALL/AsymEncryption
CCN-PITFALL/RSAPKCS

Centro Criptológico Nacional 20

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for RSA PKCS#1v1.5 Encryption Scheme

Evaluation Task Evaluation Test Code
Underlying Primitive
CCN-PITFALL/RSA
CCN-PITFALL/RSAParameter.1
CCN-PITFALL/RSAParameter.2

Table 101. Summary of Evaluation Tasks for RSA PKCS#1v1.5 Encryption Scheme

6.2.2 DIGITAL SIGNATURE

320. This table summarizes the evaluation tasks to be performed for Digital Signature
constructions based on approved RSA-PSS schemes:

Summary of Evaluation Tasks for RSA-PSS Digital Signature

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/DigitalSignature
CCN-MECHANISM Underlying Primitive
CCN-MECHANISM/RSA
CCN-MECHANISM/Hash
Construction
CCN-AGREED/DigitalSignature
Notes
Note 36 [Hash Function]
Underlying Primitive
CCN-AGREED/RSA
CCN-AGREED/Hash
CCN-AGREED RSA Key Pair Generation (if applicable)
CCN-AGREED/RSAKeys
Notes
Note 29 [Primes]
Note 61 [Primes from Uniform Distributions]
Note 62 [Miller-Rabin as Primality Test]
Note 63 [Miller-Rabin Parameters]
Note 60 [DRNG as Input]
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 66)

Centro Criptológico Nacional 20

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for RSA-PSS Digital Signature

Evaluation Task Evaluation Test Code
Construction
CCN-PITFALL/AsymConstruction
CCN-PITFALL/AsymAuth
CCN-PITFALL Underlying Primitive
CCN-PITFALL/RSA
CCN-PITFALL/RSAParameter.1
CCN-PITFALL/RSAParameter.2

Table 102. Summary of Evaluation Tasks for RSA-PSS Digital Signature

321. This table summarizes the evaluation tasks to be performed for the Digital
Signature constructions based on approved KCDSA schemes:

Summary of Evaluation Tasks for KCDSA Digital Signature

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/DigitalSignature
CCN-MECHANISM Underlying Primitive
CCN-MECHANISM/FFDLOG
CCN-MECHANISM/Hash
Construction
CCN-AGREED/DigitalSignature
Notes
Note 36 [Hash Function]
Note 38 [DSA Randomness]
Underlying Primitive
CCN-AGREED
CCN-AGREED/FFDLOG
CCN-AGREED/Hash
FFDLOG Key Pair Generation (if applicable)
CCN-AGREED/FFDLOGKeys
Notes
Note 60 [DRNG as Input]
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 66)
CCN-PITFALL Construction

Centro Criptológico Nacional 20

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for KCDSA Digital Signature

Evaluation Task Evaluation Test Code
CCN-PITFALL/AsymConstruction
CCN-PITFALL/AsymAuth
Underlying Primitive
CCN-PITFALL/FFDLOG.1
CCN-PITFALL/FFDLOG.2

Table 103. Summary of Evaluation Tasks for KCDSA Digital Signature

322. This table summarizes the evaluation tasks to be performed for the Digital
Signature constructions based on approved Schnorr schemes:

Summary of Evaluation Tasks for Schnorr Digital Signature

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/DigitalSignature
CCN-MECHANISM Underlying Primitive
CCN-MECHANISM/FFDLOG
CCN-MECHANISM/Hash
Construction
CCN-AGREED/DigitalSignature
Notes
Note 36 [Hash Function]
Note 38 [DSA Randomness]
Underlying Primitive
CCN-AGREED
CCN-AGREED/FFDLOG
CCN-AGREED/Hash
FFDLOG Key Pair Generation (if applicable)
CCN-AGREED/FFDLOGKeys
Notes
Note 60 [DRNG as Input]
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 66)
Construction
CCN-PITFALL CCN-PITFALL/AsymConstruction
CCN-PITFALL/AsymAuth

Centro Criptológico Nacional 20

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for Schnorr Digital Signature

Evaluation Task Evaluation Test Code
Underlying Primitive
CCN-PITFALL/FFDLOG.1
CCN-PITFALL/FFDLOG.2

Table 104. Summary of Evaluation Tasks for Schnorr Digital Signature

323. This table summarizes the evaluation tasks to be performed for the Digital
Signature constructions based on approved DSA schemes:

Summary of Evaluation Tasks for DSA Digital Signature

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/DigitalSignature
CCN-MECHANISM Underlying Primitive
CCN-MECHANISM/FFDLOG
CCN-MECHANISM/Hash
Construction
CCN-AGREED/DigitalSignature
Notes
Note 36 [Hash Function]
Note 38 [DSA Randomness]
Underlying Primitive
CCN-AGREED
CCN-AGREED/FFDLOG
CCN-AGREED/Hash
FFDLOG Key Pair Generation (if applicable)
CCN-AGREED/FFDLOGKeys
Notes
Note 60 [DRNG as Input]
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 66)
Construction
CCN-PITFALL/AsymConstruction
CCN-PITFALL CCN-PITFALL/AsymAuth
Underlying Primitive

Centro Criptológico Nacional 21

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for DSA Digital Signature

Evaluation Task Evaluation Test Code
CCN-PITFALL/FFDLOG.1
CCN-PITFALL/FFDLOG.2

Table 105. Summary of Evaluation Tasks for DSA Digital Signature

324. This table summarizes the evaluation tasks to be performed for Digital Signature
constructions based on approved EC-KCDSA schemes:

Summary of Evaluation Tasks for EC-KCDSA Digital Signature

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/DigitalSignature
CCN-MECHANISM Underlying Primitive
CCN-MECHANISM/ECDLOG
CCN-MECHANISM/Hash
Construction
CCN-AGREED/DigitalSignature
Notes
Note 36 [Hash Function]
Note 38 [DSA Randomness]
Underlying Primitive
CCN-AGREED/ECDLOG
CCN-AGREED/Hash
CCN-AGREED Notes
Note 30 [Points on the Curve]
Note 31 [Points on a Subgroup]
Note 32 [Prime Order]
Note 33 [Prime Selection]
ECDLOG Key Pair Generation (if applicable)
CCN-AGREED/ECDLOGKeys
Notes
Note 60 [DRNG as Input]
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 66)
Construction
CCN-PITFALL
CCN-PITFALL/AsymConstruction

Centro Criptológico Nacional 21

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for EC-KCDSA Digital Signature

Evaluation Task Evaluation Test Code
CCN-PITFALL/AsymAuth
Underlying Primitive
CCN-PITFALL/ECDLOG

Table 106. Summary of Evaluation Tasks for EC-KCDSA Digital Signature

325. This table summarizes the evaluation tasks to be performed for Digital Signature
constructions based on approved EC-DSA schemes:

Summary of Evaluation Tasks for EC-DSA Digital Signature

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/DigitalSignature
CCN-MECHANISM Underlying Primitive
CCN-MECHANISM/ECDLOG
CCN-MECHANISM/Hash
Construction
CCN-AGREED/DigitalSignature
Notes
Note 36 [Hash Function]
Note 38 [DSA Randomness]
Underlying Primitive
CCN-AGREED/ECDLOG
CCN-AGREED/Hash
CCN-AGREED Notes
Note 30 [Points on the Curve]
Note 31 [Points on a Subgroup]
Note 32 [Prime Order]
Note 33 [Prime Selection]
ECDLOG Key Pair Generation (if applicable)
CCN-AGREED/ECDLOGKeys
Notes
Note 60 [DRNG as Input]
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 66)

Centro Criptológico Nacional 21

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for EC-DSA Digital Signature

Evaluation Task Evaluation Test Code
Construction
CCN-PITFALL/AsymConstruction
CCN-PITFALL CCN-PITFALL/AsymAuth
Underlying Primitive
CCN-PITFALL/ECDLOG

Table 107. Summary of Evaluation Tasks for EC-DSA Digital Signature

326. This table summarizes the evaluation tasks to be performed for Digital Signature
constructions based on approved EC-GDSA schemes:

Summary of Evaluation Tasks for EC-GDSA Digital Signature

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/DigitalSignature
CCN-MECHANISM Underlying Primitive
CCN-MECHANISM/ECDLOG
CCN-MECHANISM/Hash
Construction
CCN-AGREED/DigitalSignature
Notes
Note 36 [Hash Function]
Note 38 [DSA Randomness]
Underlying Primitive
CCN-AGREED/ECDLOG
CCN-AGREED/Hash
CCN-AGREED Notes
Note 30 [Points on the Curve]
Note 31 [Points on a Subgroup]
Note 32 [Prime Order]
Note 33 [Prime Selection]
ECDLOG Key Pair Generation (if applicable)
CCN-AGREED/ECDLOGKeys
Notes
Note 60 [DRNG as Input]

Centro Criptológico Nacional 21

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for EC-GDSA Digital Signature

Evaluation Task Evaluation Test Code
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 66)
Construction
CCN-PITFALL/AsymConstruction
CCN-PITFALL CCN-PITFALL/AsymAuth
Underlying Primitive
CCN-PITFALL/ECDLOG

Table 108. Summary of Evaluation Tasks for EC-GDSA Digital Signature

327. This table summarizes the evaluation tasks to be performed for Digital Signature
constructions based on approved EC-Schnorr schemes:

Summary of Evaluation Tasks for EC-Schnorr Digital Signature

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/DigitalSignature
CCN-MECHANISM Underlying Primitive
CCN-MECHANISM/ECDLOG
CCN-MECHANISM/Hash
Construction
CCN-AGREED/DigitalSignature
Notes
Note 36 [Hash Function]
Note 38 [DSA Randomness]
Underlying Primitive
CCN-AGREED/ECDLOG
CCN-AGREED CCN-AGREED/Hash
Notes
Note 30 [Points on the Curve]
Note 31 [Points on a Subgroup]
Note 32 [Prime Order]
Note 33 [Prime Selection]
ECDLOG Key Pair Generation (if applicable)
CCN-AGREED/ECDLOGKeys

Centro Criptológico Nacional 21

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for EC-Schnorr Digital Signature

Evaluation Task Evaluation Test Code
Notes
Note 60 [DRNG as Input]
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 66)
Construction
CCN-PITFALL/AsymConstruction
CCN-PITFALL CCN-PITFALL/AsymAuth
Underlying Primitive
CCN-PITFALL/ECDLOG

Table 109. Summary of Evaluation Tasks for EC-Schnorr Digital Signature

328. This table summarizes the evaluation tasks to be performed for Digital Signature
constructions based on approved EdDSA schemes:

Summary of Evaluation Tasks for EdDSA Digital Signature

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/DigitalSignature
Underlying Primitive
CCN-MECHANISM
CCN-MECHANISM/ECDLOG
CCN-MECHANISM/Hash
CCN-MECHANISM/XOF
Construction
CCN-AGREED/DigitalSignature
Underlying Primitive
CCN-AGREED/ECDLOG
CCN-AGREED/Hash
CCN-AGREED/XOF
CCN-AGREED
Notes
Note 30 [Points on the Curve]
Note 31 [Points on a Subgroup]
Note 32 [Prime Order]
Note 3 [Agreed XOF]
ECDLOG Key Pair Generation (if applicable)

Centro Criptológico Nacional 21

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for EdDSA Digital Signature

Evaluation Task Evaluation Test Code
CCN-AGREED/ECDLOGKeys
Notes
Note 60 [DRNG as Input]
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 66)
Construction
CCN-PITFALL/AsymConstruction
CCN-PITFALL CCN-PITFALL/AsymAuth
Underlying Primitive
CCN-PITFALL/ECDLOG

Table 110. Summary of Evaluation Tasks for EdDSA Digital Signature

329. This table summarizes the evaluation tasks to be performed for Digital Signature
constructions based on approved RSA-PKCS#1v1.5 schemes:

Summary of Evaluation Tasks for RSA PKCS#1v1.5 Digital Signature

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/DigitalSignature
CCN-MECHANISM Underlying Primitive
CCN-MECHANISM/RSA
CCN-MECHANISM/Hash
Construction
CCN-AGREED/DigitalSignature
Notes
Note 36 [Hash Function]
Note 37 [PKCS Format Check]
Underlying Primitive
CCN-AGREED
CCN-AGREED/RSA
CCN-AGREED/Hash
RSA Key Pair Generation (if applicable)
CCN-AGREED/RSAKeys
Notes
Note 29 [Primes]

Centro Criptológico Nacional 21

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for RSA PKCS#1v1.5 Digital Signature

Evaluation Task Evaluation Test Code
Note 61 [Primes from Uniform Distributions]
Note 62 [Miller-Rabin as Primality Test]
Note 63 [Miller-Rabin Parameters]
Note 60 [DRNG as Input]
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 66)
Construction
CCN-PITFALL/AsymConstruction
CCN-PITFALL/AsymAuth
CCN-PITFALL Underlying Primitive
CCN-PITFALL/RSA
CCN-PITFALL/RSAParameter.1
CCN-PITFALL/RSAParameter.2

Table 111. Summary of Evaluation Tasks for RSA PKCS#1v1.5 Digital Signature
330. The following table summarizes the evaluation tasks to be performed for the
XMSS scheme based on hash and XOF primitives:

Summary of Evaluation Tasks for XMSS Digital Signature

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/DigitalSignature
CCN-MECHANISM Underlying Primitive
CCN-MECHANISM/Hash
CCN-MECHANISM/XOF
Construction
CCN-AGREED/DigitalSignature
Notes
Note 39 [XMSS Underlying Primitives]
Note 40 [Stateful Post-quantum Digital Signatures1]
CCN-AGREED
Note 41 [Stateful Post-quantum Digital Signatures2]
Note 42 [Precautions for XMSS Backups]
Note 43 [Stateful Post-quantum Digital Signatures3]
Note 44 [Stateful Post-quantum Digital Signatures4]
Underlying Primitive

Centro Criptológico Nacional 21

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for XMSS Digital Signature

Evaluation Task Evaluation Test Code
CCN-AGREED/Hash
CCN-AGREED/XOF
Notes
Note 3 [Agreed XOF]
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 66)
Construction
CCN-PITFALL/AsymConstruction
CCN-PITFALL/AsymAuth
CCN-PITFALL/XMSS.1
CCN-PITFALL/XMSS.2
CCN-PITFALL
CCN-PITFALL/XMSS.3
CCN-PITFALL/XMSS.4
Underlying Primitive
N/A because there are no implementation pitfalls for
hash and XOF primitives

Table 112. Summary of Evaluation Tasks for XMSS Digital Signature

6.2.3 KEY ESTABLISHMENT

331. The following table summarizes the evaluation tasks to be performed for the DH
key establishment constructions. It is mandatory to perform the evaluation tasks
associated with the underlying constructions:
- The tester shall perform the evaluation tasks defined in section 6.1.9
“Key Derivation Functions” for the underlying key derivation
cryptographic constructions.

Summary of Evaluation Tasks for DH Key Establishment Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/KeyEstablishment
CCN-MECHANISM
Underlying Primitive
CCN-MECHANISM/FFDLOG
Construction
CCN-AGREED
CCN-AGREED/KeyEstablishment

Centro Criptológico Nacional 21

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for DH Key Establishment Constructions

Evaluation Task Evaluation Test Code
Notes
Note 46 [Authentication]
Note 47 [DH/EC-DH Subgroup Attacks]
Note 50 [Uniform Distributions]
Underlying Primitive
CCN-AGREED/FFDLOG
FFDLOG Key Pair Generation (if applicable)
CCN-AGREED/FFDLOGKeys
Notes
Note 60 [DRNG as Input]
Construction and Underlying Mechanisms
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 67)
Construction
CCN-PITFALL/AsymConstruction
CCN-PITFALL/KeyEstablishment
CCN-PITFALL CCN-PITFALL/FFKeyEstablishment
Underlying Primitive
CCN-PITFALL/FFDLOG.1
CCN-PITFALL/FFDLOG.2

Table 113. Summary of Evaluation Tasks for DH Key Establishment Constructions

332. The following table summarizes the evaluation tasks to be performed for the
DLIES-KEM constructions. It is mandatory to perform the evaluation tasks
associated with the underlying constructions:
- The tester shall perform the evaluation tasks defined in section 6.1.9
“Key Derivation Functions” for the underlying key derivation
cryptographic constructions.

Summary of Evaluation Tasks for DLIES-KEM Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/KeyEstablishment
CCN-MECHANISM
Underlying Primitive
CCN-MECHANISM/FFDLOG
CCN-AGREED Construction

Centro Criptológico Nacional 21

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for DLIES-KEM Constructions

Evaluation Task Evaluation Test Code
CCN-AGREED/KeyEstablishment
Notes
Note 46 [Authentication]
Note 47 [DH/EC-DH Subgroup Attacks]
Note 48 [DLIES Key Length]
Note 50 [Uniform Distributions]
Underlying Primitive
CCN-AGREED/FFDLOG
FFDLOG Key Pair Generation (if applicable)
CCN-AGREED/FFDLOGKeys
Notes
Note 60 [DRNG as Input]
Construction and Underlying Mechanisms
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 67)
Construction
CCN-PITFALL/AsymConstruction
CCN-PITFALL/KeyEstablishment
CCN-PITFALL CCN-PITFALL/FFKeyEstablishment
Underlying Primitive
CCN-PITFALL/FFDLOG.1
CCN-PITFALL/FFDLOG.2

Table 114. Summary of Evaluation Tasks for DLIES-KEM Constructions

333. The following table summarizes the evaluation tasks to be performed for ECDH
key establishment constructions. It is mandatory to perform the evaluation tasks
associated with the underlying constructions:
- The tester shall perform the evaluation tasks defined in section 6.1.9
“Key Derivation Functions” for the underlying key derivation
cryptographic constructions.

Summary of Evaluation Tasks for ECDH Key Establishment Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM
CCN-MECHANISM/KeyEstablishment

Centro Criptológico Nacional 22

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for ECDH Key Establishment Constructions

Evaluation Task Evaluation Test Code
Underlying Primitive
CCN-MECHANISM/ECDLOG
Construction
CCN-AGREED/KeyEstablishment
Notes
Note 46 [Authentication]
Note 47 [DH/EC-DH Subgroup Attacks]
Note 50 [Uniform Distributions]
Underlying Primitive
CCN-AGREED/ECDLOG
CCN-AGREED Notes
Note 30 [Points on the Curve]
Note 31 [Points on a Subgroup]
Note 32 [Prime Order]
Note 33 [Prime Selection]
ECDLOG Key Pair Generation (if applicable)
CCN-AGREED/ECDLOGKeys
Notes
Note 60 [DRNG as Input]
Construction and Underlying Mechanisms
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 67)
Construction
CCN-PITFALL/AsymConstruction
CCN-PITFALL/KeyEstablishment
CCN-PITFALL
CCN-PITFALL/ECKeyEstablishment
Underlying Primitive
CCN-PITFALL/ECDLOG

Table 115. Summary of Evaluation Tasks for ECDH Key Establishment

Constructions
334. The following table summarizes the evaluation tasks to be performed for ECIES-
KEM constructions. It is mandatory to perform the evaluation tasks associated
with the underlying constructions:

Centro Criptológico Nacional 22

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

- The tester shall perform the evaluation tasks defined in section 6.1.9
“Key Derivation Functions” for the underlying key derivation
cryptographic constructions.

Summary of Evaluation Tasks for ECIES-KEM Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/KeyEstablishment
CCN-MECHANISM
Underlying Primitive
CCN-MECHANISM/ECDLOG
Construction
CCN-AGREED/KeyEstablishment
Notes
Note 46 [Authentication]
Note 47 [DH/EC-DH Subgroup Attacks]
Note 49 [ECIES Key Length]
Note 50 [Uniform Distributions]
Underlying Primitive
CCN-AGREED/ECDLOG
CCN-AGREED
Notes
Note 30 [Points on the Curve]
Note 31 [Points on a Subgroup]
Note 32 [Prime Order]
Note 33 [Prime Selection]
ECDLOG Key Pair Generation (if applicable)
CCN-AGREED/ECDLOGKeys
Notes
Note 60 [DRNG as Input]
Construction and Underlying Mechanisms
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 67)
Construction
CCN-PITFALL/AsymConstruction
CCN-PITFALL/KeyEstablishment
CCN-PITFALL
CCN-PITFALL/ECKeyEstablishment
Underlying Primitive
CCN-PITFALL/ECDLOG

Table 116. Summary of Evaluation Tasks for ECIES-KEM Constructions

Centro Criptológico Nacional 22

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

6.3 RANDOM NUMBER GENERATION

6.3.1 TRUE RANDOM NUMBER GENERATORS

335. The following table summarizes the evaluation tasks to be performed for
physical true random number generators (PTRNG):

Summary of Evaluation Tasks for Physical TRNGs

Evaluation Task Evaluation Test Code
TRNG
CCN-MECHANISM
CCN-MECHANISM/TRNG
PTRNG
CCN-AGREED/PTRNG
Notes
CCN-AGREED Note 52 [TRNG Use]
Note 53 [PTRNG Evaluation]
TRNG
CCN-AGREED/TRNGEntropy

Table 117. Summary of Evaluation Tasks for PTRNGs

336. The following table summarizes the evaluation tasks to be performed for non-
physical true random number generators (NPTRNG):

Summary of Evaluation Tasks for Non-Physical TRNGs

Evaluation Task Evaluation Test Code
TRNG
CCN-MECHANISM
CCN-MECHANISM/TRNG
NPTRNG
CCN-AGREED/NPTRNG
Notes
CCN-AGREED Note 52 [TRNG Use]
Note 54 [NPTRNG Evaluation]
TRNG
CCN-AGREED/TRNGEntropy

Table 118. Summary of Evaluation Tasks for NPTRNGs

Centro Criptológico Nacional 22

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

6.3.2 DETERMINISTIC RANDOM NUMBER GENERATORS

337. The following table summarizes the evaluation tasks to be performed for
deterministic random number generators based on HMAC-DRBG [SP800-90A]
construction. It is mandatory to perform the evaluation tasks associated with the
underlying constructions:
- The tester shall perform the evaluation tasks defined in Table 81 for the
HMAC underlying constructions.

Summary of Evaluation Tasks for HMAC-DRBG Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM
CCN-MECHANISM/DRNG
Construction
CCN-AGREED/DRNG
CCN-AGREED/DRNGScheme
Notes
CCN-AGREED
Note 55 [DRNG Evaluation]
Note 56 [DRNG HMAC-DRBG Conformity Proof]
Note 58 [DRNG Seeding]
Note 59 [DRNG Backtracking Resistance]
Construction and Underlying Mechanisms
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 68)
Construction
CCN-PITFALL CCN-PITFALL/DRG.1
CCN-PITFALL/DRG.2

Table 119. Summary of Evaluation Tasks for HMAC-DRBG Constructions

338. The following table summarizes the evaluation tasks to be performed for
deterministic random number generators based on Hash-DRBG [SP800-90A]
construction.

Summary of Evaluation Tasks for Hash-DRBG Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM/DRNG
CCN-MECHANISM
Underlying Primitive
CCN-MECHANISM/Hash
CCN-AGREED Construction

Centro Criptológico Nacional 22

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for Hash-DRBG Constructions

Evaluation Task Evaluation Test Code
CCN-AGREED/DRNG
CCN-AGREED/DRNGScheme
Notes
Note 55 [DRNG Evaluation]
Note 57 [DRNG Hash-DRBG Conformity Proof]
Note 58 [DRNG Seeding]
Note 59 [DRNG Backtracking Resistance]
Underlying Primitive
CCN-AGREED/Hash
Construction and Underlying Primitive
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 68)
Construction
CCN-PITFALL/DRG.1
CCN-PITFALL/DRG.2
CCN-PITFALL
Underlying Primitive
N/A because there are no implementation pitfalls for
the SHA cryptographic primitive

Table 120. Summary of Evaluation Tasks for Hash-DRBG Constructions

339. The following table summarizes the evaluation tasks to be performed for
deterministic random number generators based on CTR-DRBG [SP800-90A]
construction. It is mandatory to perform the evaluation tasks associated with the
underlying constructions:
- The tester shall perform the evaluation tasks defined in Table 76 for the
CTR underlying symmetric encryption constructions.

Summary of Evaluation Tasks for CTR-DRBG Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM
CCN-MECHANISM/DRNG
Construction
CCN-AGREED/DRNG
CCN-AGREED CCN-AGREED/DRNGScheme
Notes
Note 55 [DRNG Evaluation]

Centro Criptológico Nacional 22

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for CTR-DRBG Constructions

Evaluation Task Evaluation Test Code
Note 58 [DRNG Seeding]
Note 59 [DRNG Backtracking Resistance]
Construction and Underlying Mechanisms
CCN-CONFORMITY
CCN-CONFORMITY/Mechanisms (Table 68)
Construction
CCN-PITFALL/DRG.1
CCN-PITFALL
CCN-PITFALL/DRG.2
CCN-PITFALL/CTRDRBG

Table 121. Summary of Evaluation Tasks for CTR-DRBG Constructions

340. In case of any other DRNG construction, the following table summarizes the
evaluation tasks to be performed. It is mandatory to perform the evaluation
tasks associated with the underlying constructions:
- The tester shall perform the evaluation tasks defined in the tables
corresponding to the appropriate underlying constructions.

Summary of Evaluation Tasks for Generic DRNG Constructions

Evaluation Task Evaluation Test Code
Construction
CCN-MECHANISM
CCN-MECHANISM/DRNG
Construction
CCN-AGREED/DRNG
CCN-AGREED
Notes
Note 55 [DRNG Evaluation]
Construction and Underlying Mechanisms
CCN-CONFORMITY CCN-CONFORMITY/Mechanisms (Table depends on
DRNG construction)
Construction
CCN-PITFALL CCN-PITFALL/DRG.1
CCN-PITFALL/DRG.2

Table 122. Summary of Evaluation Tasks for Generic DRNG Constructions

Centro Criptológico Nacional 22

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

6.4 GENERAL EVALUATION TASKS

341. This section contains general evaluation tasks, related to the management of
SSPs, the execution of cryptographic mechanisms self-tests, the mitigation of
other attacks, and the implementation of cryptographic protocols, as part of the
evaluation of cryptographic mechanisms. The evaluation tasks shall be
performed depending on the usage or implementation of the cryptographic
mechanisms.

6.4.1 SENSITIVE SECURITY PARAMETER MANAGEMENT

342. The following table summarizes the evaluation tasks to be performed for the
sensitive security parameter management:

Summary of Evaluation Tasks for SSP Management

Evaluation Task Evaluation Test Code
CCN-SSP/Generation
CCN-SSP/Transport
CCN-SSP CCN-SSP/Storage
CCN-SSP/Zeroization.1
CCN-SSP/Zeroization.2
CCN-PITFALL/KeyManagement

CCN-PITFALL CCN-PITFALL/KeyTransport

CCN-PITFALL/KeyUsage

Table 123. Summary of Evaluation Tasks for SSP Management

6.4.2 CRYPTOGRAPHIC MECHANISMS SELF-TEST

343. The following table summarizes the evaluation tasks to be performed for the
implementation of cryptographic mechanisms self-test:

Summary of Evaluation Tasks for Self-Test Implementation

Evaluation Task Evaluation Test Code
CCN-SELFTEST CCN-SELFTEST/Implementation

Table 124. Summary of Evaluation Tasks for Self-Test Implementation

6.4.3 MITIGATION OF OTHER ATTACKS

344. The following table summarizes the evaluation tasks to be performed for the
mitigation of other attacks:

Centro Criptológico Nacional 22

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Summary of Evaluation Tasks for the Mitigation of Other Attacks

Evaluation Task Evaluation Test Code
CCN-MITIGATION CCN-MITIGATION/Mitigation

Table 125. Summary of Evaluation Tasks for the Mitigation of Other Attacks

6.4.4 CRYPTOGRAPHIC PROTOCOLS IMPLEMENTATION

345. The following table summarizes the evaluation tasks to be performed for the
cryptographic protocols implementation. It is mandatory to perform the
evaluation tasks associated with the underlying cryptographic mechanisms.

Summary of Evaluation Tasks for the Cryptographic Protocols

Evaluation Task Evaluation Test Code
Protocol Implementation
CCN-PROTOCOL/TLS
Notes
Note 64 [psk_ke mode]
Note 65 [0-RTT Data]
Note 66 [TLS Encrypt and then MAC]
Note 67 [TLS with RSA]
Protocol Implementation
CCN-PROTOCOL/SSH
Notes
Note 68 [Diffie-Hellman-group-exchange-SHA256]
CCN-PROTOCOL Note 69 [Key Renewal]
Note 70 [ECDH-SHA2-*]
Note 71 [Security Statement]
Note 72 [ECDSA-SHA2-*]
Note 73 [x509v3-ECDSA-SHA2-*]
Protocol Implementation
CCN-PROTOCOL/IPsec
Notes
Note 74 [Tunnel Mode – Transport Mode]
Note 75 [IPsec Attacks]
Note 76 [HMAC-SHA-XXX-YYY]
Note 77 [RSASSA-PSS]

Table 126. Summary of Evaluation Tasks for Cryptographic Protocols

Centro Criptológico Nacional 22

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

7 ANNEX B: CONFORMITY TESTS SPECIFICATION

346. This annex contains the definition of the test vectors of the conformity testing
process. It is located in the external document [CCN-MEMeC-B].

Centro Criptológico Nacional 22

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

8 REFERENCES

[ANS11] ANSSI. Avis relatif aux paramètres de courbes ellitpiques

définis pas l'État français. Agence Nationale de la Sécurité des
Systèmes d'Information, Journal O-ciel 0241 (Oct. 2011), p.
17533, 2011.
[ANSI-X9.63] ANSI. Public Key Cryptography for the Financial Services
Industry: Key Agreement and Key Transport Using Elliptic
Curve Cryptography (R2017). American National Standards
Institute, ANSI X9.63:2011, 2017.
[BN00] M. Bellare and C. Namprempre. Authenticated encryption:
Relations among notions and analysis of the generic
composition paradigm. In Proc. International Conference on
the Theory and Application of Cryptology and Information
Security, Advances in Cryptology - ASIACRYPT 2000, Lecture
Notes Comput. Sci., volume 1976, pages 531-545, 2000.
[CCN-MEMeC-B] CCN Cryptographic Mechanisms Evaluation Methodology
Annex B: Conformity Tests Specification v1.3.3. November
2024.
[CCN-STIC-221] CCN. Guía de Mecanismos Criptográficos autorizados por el
CCN v2.1. Octubre 2024.
[FCRNG] BSI. A Proposal for Functionality Classes for Random Number
Generators, version v3.0, 2024.
[FIPS-180-4] NIST. Digital Signature Standard (DSS). National Institute of
Standard and Technology, NIST FIPS 186-4, 2013.
[FIPS-186-4] NIST. Digital Signature Standard (DSS). National Institute of
Standard and Technology, NIST FIPS 186-4, 2013.
[FIPS-186-5] NIST. Digital Signature Standard (DSS). National Institute of
Standard and Technology, NIST FIPS 186-5, 2023.
[FIPS-197] NIST. Advanced Encryption Standard. National Institute of
Standard and Technology, Federal Information Processing
Standard Publication, FIPS 197, 2001.
[FIPS-202] NIST. SHA-3 Standard: Permutation-Based Hash and
Extendable-Output Functions. National Institute of Standard
and Technology, NIST FIPS 202, 2015.
[FIPS-203] NIST. Module-Lattice-Based Key-Encapsulation Mechanism
Standard. National Institute of Standard and Technology, NIST
FIPS 203, 2024.

Centro Criptológico Nacional 23

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

[FIPS-204] NIST. Module-Lattice-Based Digital Signature Standard.

National Institute of Standard and Technology, NIST FIPS 204,
2024.
[FIPS-205] NIST. Stateless Hash-Based Digital Signature Standard.
National Institute of Standard and Technology, NIST FIPS 205,
2024.
[ISO-10116] ISO/IEC 10116. Information technology – Security techniques
– Modes of operation for an n-bit block cipher. International
Organization for Standardization/International
Electrotechnical Commission, 2017.
[ISO-10118-3] ISO/IEC 10118-3. ISO/IEC 10118-3:2018 – Information
technology Security techniques – Hash-functions – Part 3:
Dedicated hash-functions. ISO/IEC10118-3:2018.
International Organization for Standardization/International
Electrotechnical Commission, 2018.
[ISO-11770-3] ISO/IEC 11770-3. Information technology – Security
techniques – Key management, Part 3: Mechanisms using
asymmetric techniques, ISO/IEC 11770-3. International
Organization for Standardization, 2015.
[ISO-14888-3] ISO/IEC 14888-3. Information technology – Security
techniques – Digital signatures with appendix, Part 3: Discrete
logarithm based mechanisms, ISO/IEC 14888-3. International
Organization for Standardization, 2018.
[ISO-18031] ISO/IEC 18031. Information Technology – Security Techniques
– Random bit generation, ISO/IEC 18031. International
Organization for Standardization/International
Electrotechnical Commission, 2011.
[ISO-18033-2] ISO/IEC 18033-2. Information Technology – Security
Techniques – Encryption Algorithms-Part 2: Asymmetric
Ciphers. International Organization for
Standardization/International Electrotechnical Commission,
2006.
[ISO-18033-3] ISO/IEC. Information Technology – Security Techniques –
Encryption Algorithms – Part 3: Block Ciphers. International
Organization for Standardization/International
Electrotechnical Commission, 2010.
[ISO-19772] ISO/IEC 19772. Information Technology – Authenticated
encryption. International Organization for
Standardization/International Electrotechnical Commission,
2020.

Centro Criptológico Nacional 23

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

[ISO-9796-2] ISO/IEC 9796-2. Information technology Security techniques –

Digital signature schemes giving message recovery, Part 2:
Integer factorization based mechanisms, ISO/IEC 9796-2.
International Organization for Standardization, 2010.
[ISO-9797-1] ISO/IEC 9797-1. Information technology Security techniques –
Message Authentication Codes (MACs), Part 1: Mechanisms
using a block cipher, ISO/IEC 9797-1. International
Organization for Standardization/International
Electrotechnical Commission, 2011.
[ISO-9797-2] ISO/IEC 9797-2. Information technology Security techniques –
Message Authentication Codes (MACs), Part 2: Mechanisms
using a dedicated hash-function. International Organization
for Standardization/International Electrotechnical
Commission, 2011.
[JSS15] “Practical Invalid Curve Attacks on TLS-ECDH”, J. Jager, J.
Schwenk, J. Somorovsky, ESORICS’15.
[Man01] “A Chosen Ciphertext Attack on RSA Optimal Asymmetric
Encryption Padding (OAEP) as Standardized in PKCS #1 v2.0”,
J. Manger, CRYPTO’01.
[PFH+20] T. Prest, P.-A. Fouque, J. Hostein, P. Kirchner, V.
Lyubashevsky, T. Pornin, T. Ricosset, G. Seiler, W. Whyte, and
Z. Zhang.FALCON. Online publication, 2020. https://falcon-
sign.info/.
[RFC-2104] HMAC: Keyed-Hashing for Message Authentication. Internet
Engineering Task Force, RFC 2104, 1997.
[RFC-3526] More Modular Exponential (MODP) Diffie-Hellman groups for
Internet Key Exchange (IKE). NetworkWorking Group, 2003.
[RFC-4055] Additional Algorithms and Identifiers for RSA Cryptography
for use in the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile.
Internet Engineering Task Force, RFC 4055, 2005.
[RFC-4251] The Secure Shell (SSH) Protocol Architecture. Internet
Engineering Task Force, RFC 4251, 2006.
[RFC-4253] The Secure Shell (SSH) Transport Layer Protocol. Internet
Engineering Task Force, RFC 4253, 2006.
[RFC-4303] IP Encapsulating Security Payload (ESP). Internet Engineering
Task Force, RFC 4303, 2005.
[RFC-4344] The Secure Shell (SSH) Transport Layer Encryption Modes.
Internet Engineering Task Force, RFC 4344, 2006.

Centro Criptológico Nacional 23

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

[RFC-4419] Diffie-Hellman Group Exchange for the Secure Shell (SSH)

Transport Layer Protocol. Internet Engineering Task Force,
RFC 4419, 2006.
[RFC-4494] The AES-CMAC-96 Algorithm and Its Use with IPsec. Internet
Engineering Task Force, RFC 4494, 2006.
[RFC-4543] Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specication. Internet Engineering
Task Force, RFC 4543, 2006.
[RFC-4615] The Advanced Encryption Standard-Cipher-based Message
Authentication Code-Pseudo-Random Function-128 (AES-
CMAC-PRF-128) Algorithm for the Internet Key Exchange
Protocol (IKE). Internet Engineering Task Force, RFC 4615,
2006.
[RFC-4754] IKE and IKEv2 Authentication Using the Elliptic Curve Digital
Signature Algorithm (ECDSA). Internet Engineering Task Force,
RFC 4754, 2007.
[RFC-4868] Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512
with IPsec. Internet Engineering Task Force, RFC 4868, 2007.
[RFC-5246] The Transport Layer Security (TLS) Protocol, Version 1.2.
Internet Engineering Task Force, RFC 5246, 2008.
[RFC-5288] AES Galois Counter Mode (GCM) Cipher Suites for TLS.
Internet Engineering Task Force, RFC 5288, 2008.
[RFC-5289] TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES
Galois Counter Mode (GCM). Internet Engineering Task Force,
RFC 5289, 2008.
[RFC-5297] Synthetic Initialization Vector (SIV) Authenticated Encryption
Using the Advanced Encryption Standard (AES). Internet
Engineering Task Force, RFC 5297, 2008.
[RFC-5487] Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and
AES Galois Counter Mode. Internet Engineering Task Force,
RFC 5487, 2009.
[RFC-5639] Elliptic Curve Cryptography (ECC) Brainpool Standard Curves
and Curve generation. Internet Engineering Task Force, RFC
5639, 2010.
[RFC-5647] AES Galois Counter Mode for the Secure Shell Transport Layer
Protocol. Internet Engineering Task Force, RFC 5647, 2009.
[RFC-5656] Elliptic Curve Algorithm Integration in the Secure Shell
Transport Layer. Internet Engineering Task Force, RFC 5656,
2009.

Centro Criptológico Nacional 23

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

[RFC-5869] HMAC-based Extract-and-Expand Key Derivation Function

(HKDF). Internet Engineering Task Force, RFC 5689, 2010.
[RFC-5903] Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE
and IKEv2. Internet Engineering Task Force, RFC 5903, 2010.
[RFC-6187] X.509v3 Certicates for Secure Shell Authentication. Internet
Engineering Task Force, RFC 6187, 2011.
[RFC-6655] AES-CCM Cipher Suites for Transport Layer Security TLS.
Internet Engineering Task Force, RFC 6655, 2008.
[RFC-6954] Using the Elliptic Curve Cryptography (ECC) Brainpool Curves
for the Internet Key Exchange Protocol Version 2 (IKEv2).
Internet Engineering Task Force, RFC 6954, 2013.
[RFC-7027] Elliptic Curve Cryptography (ECC) Brainpool Curves for
Transport Layer Security (TLS). Internet Engineering Task
Force, RFC 7027, 2013.
[RFC-7251] AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for
TLS. Internet Engineering Task Force, RFC 7251, 2014.
[RFC-7296] Internet Key Exchange Protocol Version 2 (IKEv2). Internet
Engineering Task Force, RFC 7296, 2014.
[RFC-7427] Signature Authentication in the Internet Key Exchange
Version 2 (IKEv2). Internet Engineering Task Force, RFC 7427,
2015.
[RFC-7693] The BLAKE2 Cryptographic Hash and Message Authentication
Code (MAC). Internet Engineering Task Force, RFC 7693, 2015.
[RFC-7748] Elliptic curves for security. Internet Engineering Task Force,
RFC 7748, 2016.
[RFC-7905] ChaCha20-Poly1305 Cipher Suites for Transport Layer Security
(TLS). Internet Engineering Task Force, RFC 7905, 2016.
[RFC-7914] The SCRYPT Password-Based Key Derivation Function.
Internet Engineering Task Force, RFC 7914, 2016.
[RFC-7919] Negotiated Finite Field Di-e-Hellman Ephemeral Parameters
for Transport Layer Security (TLS). Internet Engineering Task
Force, RFC 7919, 2016.
[RFC-8017] PKCS #1: RSA Cryptography Specications Version 2.2. Internet
Engineering Task Force, RFC 8017, 2016.
[RFC-8018] PKCS #5: Password-Based Cryptography Specication. Version
2.1. Internet Engineering Task Force, RFC 8018, 2017.

Centro Criptológico Nacional 23

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

[RFC-8031] Curve25519 and Curve448 for the Internet Key Exchange

Protocol Version 2 (IKEv2) Key Agreement. Internet
Engineering Task Force, RFC 8031, 2016.
[RFC-8032] Edwards-Curve Digital Signature Algorithm (EdDSA). Internet
Engineering Task Force, RFC 8032, 2017.
[RFC-8221] Cryptographic Algorithm Implementation Requirements and
Usage Guidance for Encapsulating Security Payload (ESP) and
Authentication Header (AH). Internet Engineering Task Force,
RFC 8221, 2017.
[RFC-8247] Algorithm Implementation Requirements and Usage
Guidance for the Internet Key Exchange Protocol Version 2
(IKEv2). Internet Engineering Task Force, RFC 8247, 2017.
[RFC-8391] XMSS: extended Merkle signature scheme. Internet
Engineering Task Force, RFC 8391, 2018.
[RFC-8422] Elliptic Curve Cryptography (ECC) Cipher Suites for Transport
Layer Security (TLS) Versions 1.2 and Earlier. Internet
Engineering Task Force, RFC 8422, 2013.
[RFC-8439] ChaCha20 and Poly1305 for IETF Protocols. Internet
Engineering Task Force, RFC 8439, 2018.
[RFC-8446] The Transport Layer Security (TLS) Protocol Version 1.3.
Internet Engineering Task Force, RFC 8446, 2018.
[RFC-8734] Elliptic Curve Cryptography (ECC) Brainpool Curves for
Transport Layer Security (TLS) Version 1.3. Internet
Engineering Task Force, RFC 8734, 2020.
[RFC-9106] Argon2 Memory-Hard Function for Password Hashing and
Proof-of-Work Applications. Internet Engineering Task Force,
RFC 9106, 2021.
[RSA78] R. Rivest, A. Shamir, and L. M. Adleman. A method for
obtaining digital signatures and public-key cryptosystems.
Commun. ACM, 21(2):120-126, 1978.
[Sha79] A. Shamir. How to share a secret. Communications of the
ACM, 22(11):612-613, 1979.
[SOGIS-HEP] SOG-IS Crypto Evaluation Scheme Harmonised Cryptographic
Evaluation Procedures v0.16. December 2020.
[SP800-108] NIST. Recommendation for Key Derivation Using
Pseudorandom Functions. National Institute of Standard and
Technology, Special Publication SP800-108, Revision 1, 2022.

Centro Criptológico Nacional 23

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

[SP800-132] NIST. Recommendation for Password-Based Key Derivation.

Part 1: Storage Applications. National Institute of Standard
and Technology, Special Publication SP800-132, Addendum to
SP800-132, 2010.
[SP800-133] NIST. Recommendation for Cryptographic Key Generation.
National Institute of Standard and Technology, Special
Publication SP800-133, Revision 2, 2020.
[SP800-185] NIST. SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash,
and ParallelHash. National Institute of Standard and
Technology, Special Publication, SP800-185, Rev 1 (November
2014 draft), 2016.
[SP800-186] NIST. Recommendations for Discrete Logarithm-based
Cryptography: Elliptic Curve Domain Parameters. National
Institute of Standard and Technology, Special Publication,
SP800-186 (February 2022), 2023.
[SP800-208] NIST. Recommendation for Stateful Hash-Based Signature
Schemes. National Institute of Standard and Technology,
Special Publication, SP800-208, 2020.
[SP800-38A] NIST. Recommendation for Block Cipher Modes of Operation.
Methods and Techniques. National Institute of Standards and
Technology, Special Publication SP800-38A, March 2001.
[SP800-38A- NIST. Recommendation for Block Cipher Modes of Operation:
Addendum] Three Variants of Ciphertext Stealing for CBC Mode. National
Institute of Standard and Technology, Special Publication,
Addendum to SP800-38A, 2012.
[SP800-38B] NIST. Recommendation for Block Cipher Modes of Operation:
The CMAC Mode for Authentication. National Institute of
Standards and Technology, Special Publication SP800-38B,
May 2005.
[SP800-38C] NIST. Recommendation for Block Cipher Modes of Operation:
The CCM Mode for Authentication and Confidentiality.
National Institute of Standards and Technology, Special
Publication SP800-38C, May 2007.
[SP800-38D] NIST. Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC. National Institute of
Standards and Technology, Special Publication SP800-38D,
November 2007.
[SP800-38E] NIST. Recommendation for Block Cipher Modes of Operation:
The XTS-AES Mode for Condentiality on Storage Devices.
National Institute of Standards and Technology, Special
Publication SP800-38E, November 2010.

Centro Criptológico Nacional 23

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

[SP800-38F] NIST. Recommendation for Block Cipher Modes of Operation:

Methods for Key Wrapping. National Institute of Standards
and Technology, Special Publication SP800-38F, December
2012.
[SP800-56A] NIST. Recommendation for Pair-Wise Key-Establishment
Schemes Using Discrete Logarithm Cryptography. National
Institute of Standard and Technology, Special Publication,
SP800-56A, Rev. 3, 2018.
[SP800-56B] NIST. Recommendation for Pair-Wise Key-Establishment
Using Integer Factorization Cryptography. National Institute
of Standard and Technology, Special Publication, SP800-56B,
Rev. 2, 2019.
[SP800-56C] NIST. Recommendation for Key-Derivation Methods in Key
Establishment Schemes. National Institute of Standard and
Technology, Special Publication, SP800-56C, Rev. 2, 2020.
[SP800-90A] NIST. Recommendation for Random Number Generation
Using Deterministic Random Bit Generators. National
Institute of Standard and Technology, Special Publication,
SP800-90A, Rev. 1, 2015.
[TR-03111] BSI. Elliptic curve cryptography. Bundesamt für Sicherheit in
der Informationstechnik, BSI TR-03111 version 2.0, 2012.
[Vau02] “Security Flaws Induced by CBC Padding Applications to SSL,
IPsec, WTLS, …”, S. Vaudenay, EUROCRYPT'02.

Centro Criptológico Nacional 23

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

9 ABBREVIATIONS
AES Advanced Encryption Scheme
CBC Cipher Block Chaining
CCM Counter with Cipher Block Chaining MAC
CCN Centro Criptológico Nacional
CFB Cipher Feedback
CL1 Certification Level 1
CL2 Certification Level 2
CL3 Certification Level 3
CRT Chinese Remainder Theorem
CSP Critical Security Parameter
CTR Counter
DRBG Deterministic Random Bit Generator
DRNG Deterministic Random Number Generator
DSA Digital Signature Mechanism
EAX Encrypt-then-Authenticate-then-Translate
EC Elliptic Curve
ECDLOG Discrete Logarithm in Elliptic Curves
EC-DSA Elliptic Curve Digital Signature Scheme
EC-FSDSA Elliptic Curve Full Schnorr Signature Scheme
EC-GDSA Elliptic Curve German Digital Signature Scheme
EC-KCDSA Elliptic Curve Korean Certificate-based Digital Signature Scheme
EC-SDSA Elliptic Curve Schnorr Signature Scheme
EdDSA Edwards-curve Digital Signature Scheme
ENS Esquema Nacional de Seguridad.
FFDLOG Discrete Logarithm in Finite Fields
GCM Galois/Counter
GMAC Galois Message Authentication Code
HMAC Hash-Based Message Authentication Code
Cryptographic Mechanisms Evaluation Vendor Questionnaire and/or
I1
Vendor Documentation
I2 Test and operation interfaces to verify the TOE functionality
I3 Conformity testing tools
I4 RSPs obtained from the conformity testing
I5 Evidence of the avoidance of implementation pitfalls
I6 Implementation representation
I7 Self-Test input vectors
I8 Random Number Generation Vendor Questionnaire
IC Integrated Circuit
KAT Known Answer Test
KCDSA Korean Certificate-based Digital Signature Mechanism
MAC Message Authentication Code
MCT Monte Carlo Test
NPTRNG Non-Physical True Random Number Generator

Centro Criptológico Nacional 23

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

OFB Output Feedback

PSP Public Security Parameter
PTRNG Physical True Random Number Generator
RNG Random Number Generator
RSA Rivest-Shamir-Adleman Mechanism
SSP Sensitive Security Parameter
TOE Target Of Evaluation
TRNG True Random Number Generator
VAL Validation Test
XOF Extended-Output Functions

Centro Criptológico Nacional 23

 CCN-STIC 2100 Cryptographic Mechanisms Evaluation Methodology v1.3.3 (MEMeC)

Centro Criptológico Nacional 24