ISO/IEC TS 20540:2018

TECHNICAL ISO/IEC TS
SPECIFICATION 20540
First edition
2018-05
Information technology — Security
techniques — Testing cryptographic
modules in their operational
environment
Technologies de l'information — Techniques de sécurité — Test de
modules cryptographiques dans leur environnement d'exploitation
Reference number
©
ISO/IEC 2018
© ISO/IEC 2018
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2018 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Abbreviated terms . 5
5 Document organization . 5
6 Context of operational testing . 6
7 Cryptographic modules . 7
7.1 General . 7
7.2 Types of cryptographic modules . 7
7.2.1 General. 7
7.2.2 Software module . 8
7.2.3 Firmware module . 8
7.2.4 Hardware module . 8
7.2.5 Hybrid software module . 8
7.2.6 Hybrid firmware module . 8
7.3 Cryptographic module application environments . 8
7.4 Security products with cryptographic modules . 9
7.5 Security requirements for cryptographic modules .10
7.5.1 General.10
7.5.2 Security Level 1 .10
7.5.3 Security Level 2 .11
7.5.4 Security Level 3 .11
7.5.5 Security Level 4 .12
7.6 Life-cycle assurance of cryptographic modules .12
7.7 Cryptographic module security policy .12
7.7.1 General.12
7.7.2 Cryptographic module specification .13
7.7.3 Cryptographic module interfaces .13
7.7.4 Roles, services, and authentication .13
7.7.5 Software/firmware security .13
7.7.6 Operational environment .14
7.7.7 Physical security .14
7.7.8 Non-invasive security .14
7.7.9 Sensitive security parameters management.14
7.7.10 Self-tests .14
7.7.11 Life-cycle assurance .15
7.7.12 Mitigation of other attacks .15
7.8 Intended purpose of validated cryptographic modules .15
8 The application environment .16
8.1 Organizational security .16
8.2 Architecture of the application environment .16
9 The operational environment .17
9.1 Security requirements related to cryptographic modules for their operational
environment .17
9.1.1 General.17
9.1.2 Entropy sources .17
9.1.3 Audit mechanism .17
9.1.4 Physically unclonable function .17
9.2 Security assumptions for the operational environment .17
© ISO/IEC 2018 – All rights reserved iii

9.2.1 General.17
9.2.2 Security Level 1 .18
9.2.3 Security Level 2 .18
9.2.4 Security Level 3 .19
9.2.5 Security Level 4 .20
10 How to select cryptographic modules .21
10.1 General .21
10.2 Use policy .21
10.3 Cryptographic module assurance .23
10.4 Interoperability .23
10.5 Selection of security rating for SSP protection .23
11 Principles for operational testing .23
11.1 General .23
11.2 Assumptions .24
11.3 Operational testing activities .24
11.4 Competence for operational testers .25
11.5 Use of validated evidence .25
11.6 Documentation .25
11.7 Operational testing procedure .26
12 Recommendations for operational testing .26
12.1 General .26
12.2 Recommendations for assessing the installation, configuration, and operation of
the cryptographic module .26
12.2.1 General.26
12.2.2 Assessing installation of the cryptographic module .27
12.2.3 Assessing the configuration of the cryptographic module .27
12.2.4 Assessing the correct operation of the cryptographic module .29
12.3 Recommendations for inspecting a key management system .29
12.4 Recommendations for inspecting the security requirements of authentication
credentials .30
12.5 Recommendations for assessing the availability of cryptographic modules .31
12.6 Recommendations for identifying potential residual vulnerabilities of
cryptographic modules .31
12.7 Checking for the organization’s security policies .32
13 Reporting the results of operational testing .33
Annex A (informative) Examples of validated cryptographic modules lists .34
Annex B (informative) Checklist for operational testing of cryptographic modules .35
Bibliography .39
iv © ISO/IEC 2018 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following
URL: www .iso .org/iso/foreword .html.
This document was prepared by Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, IT Security techniques.
© ISO/IEC 2018 – All rights reserved v

Introduction
In information technology, there is an ever-increasing need to use cryptographic mechanisms such as
the protection of data against unauthorized disclosure or manipulation, for entity authentication and
for non-repudiation. The security and reliability of such mechanisms are directly dependent on the
cryptographic modules in which they are implemented. Cryptographic modules are utilized within a
security system to protect sensitive information in their application environment.
The purpose of this document is to describe the recommendations and checklists which help in the
selection of cryptographic modules for deployment in a diversity of application environments. This
document is helpful for a user and operational tester to verify correct deployment in the application
environment.
Operational tests are performed to determine the suitability and proper usage of a cryptographic
module in its application environment.
Cryptographic modules and their application environments are generally complex. When cryptographic
modules are deployed in an operational environment, a minor error or mistake can affect the security
of the whole operational and application environment. It is important to perform operational tests to
ensure the proper usage of a cryptographic module in their operational environment. This document
identifies the operational tests by providing:
— recommendations to perform a secure assessment of the cryptographic module installation,
configuration and operation;
— recommendations for inspecting the key management system, protection of authentication
credentials, and public and critical security parameters in the operational environment;
— recommendations for identifying cryptographic module vulnerabilities;
— checklists for the cryptographic algorithm policy, security guidance and regulation, security
manage requirements, security level for each of the 11 requirement areas, the strength of the
security function, etc.; and
— inspection recommendations to determine that the cryptographic module’s deployment satisfies
the security requirements.
When the operational testing is performed by using this document, access to the text of ISO/IEC 19790
and ISO/IEC 24759 can be required.
vi © ISO/IEC 2018 – All rights reserved

TECHNICAL SPECIFICATION ISO/IEC TS 20540:2018(E)
Information technology — Security techniques — Testing
cryptographic modules in their operational environment
1 Scope
This document provides recommendations and checklists which can be used to support the
specification and operational testing of cryptographic modules in their operational environment within
an organization’s security system.
The cryptographic modules have four security levels which ISO/IEC 19790 defines to provide for a
wide spectrum of data sensitivity (e.g. low-value administrative data, million-dollar funds transfers,
life-protecting data, personal identity information, and sensitive information used by government)
and a diversity of application environments (e.g. a guarded facility, an office, removable media, and a
completely unprotected location).
This document includes:
a) recommendations to perform secure assessing for cryptographic module installation, configuration
and operation;
b) recommendations to inspecting the key management system, protection of authentication
credentials, and public and critical security parameters in the operational environment;
c) recommendations for identifying cryptographic module vulnerabilities;
d) checklists for the cryptographic algorithm policy, security guidance and regulation, security
manage requirements, security level for each of the 11 requirement areas, the strength of the
security function, etc.; and
e) recommendations to determine that the cryptographic module’s deployment satisfies the security
requirements of the organization.
This document assumes that the cryptographic module has been validated as conformant with ISO/
IEC 19790.
It can be used by an operational tester along with other recommendations if needed.
This document is limited to the security related to the cryptographic module. It does not include
assessing the security of the operational or application environment. It does not define techniques for
the identification, assessment and acceptance of the organization’s operational risk.
The organization’s accreditation, deployment and operation processes, shown in Figure 1, is not
included to the scope of this document.
This document addresses operational testers who perform the operational testing for the cryptographic
modules in their operational environment authorizing officials of cryptographic modules.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 19790:2012, Information technology — Security techniques — Security requirements for
cryptographic modules
© ISO/IEC 2018 – All rights reserved 1

ISO/IEC 24759, Information technology — Security techniques — Test requirements for cryptographic
modules
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at https: //www .electropedia .org/
3.1
accreditation
administrative process whereby authority is granted for the operation of the cryptographic module in
its full operational environment including all of its non-IT parts
Note 1 to entry: The results of the operational testing (3.12) process may be an input to the accreditation process.
3.2
administrator guidance
written material that is used by the Crypto Officer and/or other administrative roles for the correct
configuration, maintenance, and administration of the cryptographic module
[SOURCE: ISO/IEC 19790:2012, 3.2]
3.3
application environment
set of all software and hardware consisting of an operating system and hardware platform required for
an application, which will call a cryptographic module for services, to operate securely
Note 1 to entry: The application environment may be identical to the operational environment (e.g. both the
crypto module and application are executing in the same environment).
3.4
competence
ability to apply knowledge and skills to achieve intended results
Note 1 to entry: It represents the set of knowledge, skill, and effectiveness needed to carry out the job activities
associated with one or more roles in an employment position.
[SOURCE: ISO/IEC 17024:2012, 3.6, modified — Note 1 to entry has been added,]
3.5
critical security parameter
CSP
security-related information whose disclosure or modification can compromise the security of a
cryptographic module
EXAMPLE Secret and private cryptographic keys, authentication data such as passwords, PINs, certificates
or other trust anchors.
Note 1 to entry: A CSP can be plaintext or encrypted.
[SOURCE: ISO/IEC 19790:2012, 3.18]
2 © ISO/IEC 2018 – All rights reserved

3.6
cryptographic algorithm
well-defined computational procedure that takes variable inputs, which may include cryptographic
keys, and produces an output
[SOURCE: ISO/IEC 19790:2012, 3.20]
3.7
cryptographic module
CM
module
set of hardware, software, and/or firmware that implements security functions and are contained
within the cryptographic boundary
[SOURCE: ISO/IEC 19790:2012, 3.25, modified — CM has been added as an admitted term.]
3.8
cryptographic module security policy
security policy
precise specification of the security rules under which a cryptographic module (3.7) shall operate,
including the rules derived from the requirements specified in ISO/IEC 19790:2012, Annex B and
additional rules imposed by the module or validation authority (3.22)
[SOURCE: ISO/IEC 19790:2012, 3.26, modified — In the definition, “this document” has been changed to
reference ISO/IEC 19790.]
3.9
non-administrator guidance
written material that is used by the users (3.20) and/or other non-administrative roles for operating
the cryptographic module (3.7) in an approved mode of operation
Note 1 to entry: The non-administrator guidance describes the security functions of the cryptographic module
and contains information and procedures for the secure use of the cryptographic module, including instructions,
guidelines, and warnings.
[SOURCE: ISO/IEC 19790:2012, 3.77]
3.10
operational environment
set of all software and hardware consisting of an operating system and hardware platform required for
the module to operate securely
[SOURCE: ISO/IEC 19790:2012, 3.83]
3.11
operational tester
tester
individual assigned by an organization (3.15) to perform test activities in accordance with the
operational testing process (3.13)
3.12
operational testing
OT
test to determine the correct installation, configuration and operation of a module and that it operates
securely in the operational environment (3.10)
3.13
operational testing process
OTP
process to support determining the correct installation, configuration and operation of a module and
that it operates securely in the operational environment (3.10)
© ISO/IEC 2018 – All rights reserved 3

3.14
operator
individual or a process (subject) operating on behalf of the individual, authorized to assume one or
more roles
[SOURCE: ISO/IEC 19790:2012, 3.85]
3.15
organization
entity specifying, deploying and operating a cryptographic module (3.7)
3.16
pre-operational test
operational testing (3.12) to be performed by a vendor (3.23) during the development of a cryptographic
module (3.7) or on behalf of a validation authority (3.22) during the validation under ISO/IEC 19790:2012
for the intended operational environment (3.10)
3.17
public security parameter
PSP
security-related public information whose modification can compromise the security of a cryptographic
module (3.7)
EXAMPLE Public cryptographic keys, public key certificates, self-signed certificates, trust anchors, one-time
passwords associated with a counter and internally held date and time.
Note 1 to entry: A PSP is considered protected if it cannot be modified or if its modification can be determined by
the module.
[SOURCE: ISO/IEC 19790:2012, 3.99]
3.18
random bit generator
RBG
device or algorithm that outputs a sequence of bits that appears to be statistically independent and
unbiased
[SOURCE: ISO/IEC 19790:2012, 3.100]
3.19
sensitive security parameter
SSP
critical security parameters (CSP) (3.5) and public security parameters (PSP) (3.17)
[SOURCE: ISO/IEC 19790:2012, 3.110]
3.20
user
role taken by an individual or process (i.e. subject) acting on behalf of an individual that accesses a
cryptographic module (3.7) in order to obtain cryptographic services
[SOURCE: ISO/IEC 19790:2012, 3.130]
3.21
validated
assurance of tested conformance by a validation authority (3.22)
[SOURCE: ISO/IEC 19790:2012, 3.131]
4 © ISO/IEC 2018 – All rights reserved

3.22
validation authority
entity that will validate the testing results for conformance to an International Standard
[SOURCE: ISO/IEC 19790:2012, 3.132, modified — In the definition, “this” has been changed to “an”.]
3.23
vendor
entity, group or association that submits the cryptographic module (3.7) for testing and validation
Note 1 to entry: The vendor has access to all relevant documentation and design evidence regardless if they did
or did not design or develop the cryptographic module.
[SOURCE: ISO/IEC 19790:2012, 3.133]
4 Abbreviated terms
The abbreviated terms given in ISO/IEC 19790:2012, Clause 4 apply.
5 Document organization
Clause 6 describes the context of operational testing in an organization’s environment and the
relationships with other key stakeholders in the production and specification of cryptographic modules.
Clause 7 specifies the types of cryptographic modules, security requirements, life-cycle assurance,
security policy requirements and guidance, and intended purpose that should be satisfied by the
cryptographic module’s compliance to ISO/IEC 19790.
Clause 8 describes the operational environment which cryptographic modules are utilized in and
security requirements related to cryptographic modules for their operational environment.
Clause 9 provides guidance on how to select cryptographic modules in their operational environment.
Clause 10 describes the principles for operational testing, including the assumptions to be made testing
activities to be performed, expected competence requirements of operational testers, use of evidences
that has been gained from the validation of cryptographic modules, documentation requirements for
operational testing, and procedures for operational testing.
Clause 11 describes the principles for operational testing including:
— assessing the installation, configuration, and operation;
— identifying the residual vulnerabilities;
— inspecting the key management system;
— inspecting the security requirements of authentication credentials;
— assessing the availability of cryptographic modules;
— checking the security policies.
Clause 12 describes how to report the results of operational testing, describing the contents of a report
giving the results of operational testing.
© ISO/IEC 2018 – All rights reserved 5

6 Context of operational testing
A vendor designs, develops and manufactures a cryptographic module. The vendor may have the module
validated by a validation authority in support of a claim that the module is compliant to ISO/IEC 19790.
NOTE For some organizations, there can be an organizational security policy such that the module validated
by a named validation authority can be acquired by an organization for deployment in a security system or
application environment.
Figure 1 shows the scope of this document in context with a generalized life-cycle of a cryptographic
module. It depicts both the development life-cycle of the module by the vendor, and the life-cycle of the
module in the organization’s environment.
The vendor starts with a risk assessment process to determine the security requirements for
cryptographic modules. This risk assessment, which is based on the intended operational environment
and the intended market, defines the modules security requirements for each specific area in ISO/
IEC 19790. Once defined, the vendor proceeds with the module's development which includes the
design, implementation and testing processes.
Typically, validation by a validation authority, is initiated by the vendor, but validation can also be
initiated by an original equipment manufacturer, an integrator, or by the organization itself.
An organization performs a risk assessment and defines security requirements for their operational
environment. To address this risk assessment, the organization may procure a validated cryptographic
module which satisfies the security requirements, and performs the operational testing process, before
the module is deployed. The cryptographic modules reflected by their assurance maintenance should
be used in operational testing.
The operational testing process, as shown in Figure 1, is performed to select a proper cryptographic
module for use in a specific operational environment. The result of the operational testing process may
be used to perform the organization’s accreditation of the cryptographic module.
The operational testing process is located between module's validation and organization accreditation.
The scope of this document is the operational testing process, shown in Figure 1 as a gray box.
6 © ISO/IEC 2018 – All rights reserved

Figure 1 — Process for developing, validating, accreditation, deploying and operation of a
cryptographic module
7 Cryptographic modules
7.1 General
This clause specifies the types of cryptographic modules, security requirements, life-cycle assurance,
security policy requirements and guidance, and intended purpose that are satisfied when a
cryptographic module is in compliance with ISO/IEC 19790.
The vendor provides the security policy document and the required guidance that is specified in ISO/
IEC 19790. The vendor may also provide other documentation, guidance, tools or specifications that
were not specified as part of the compliance with ISO/IEC 19790.
7.2 Types of cryptographic modules
7.2.1 General
Cryptographic modules can take various forms of modules as illustrated in Figure 2, and contain
various kinds of security functions, different security function strengths, etc. Cryptographic modules
may contain the same algorithms with appropriate security strengths.
Figure 2 — Various types of cryptographic modules
© ISO/IEC 2018 – All rights reserved 7

The following cryptographic module types are defined by ISO/IEC 19790: software cryptographic
module, firmware cryptographic module, hardware cryptographic module, and hybrid cryptographic
module. Precise descriptions of the types of cryptographic modules are given in ISO/IEC 19790:2012,
7.2.2, and are reproduced below.
7.2.2 Software module
A software module is a module whose cryptographic boundary delimits the software exclusive
component(s) (can be one or multiple software components) that execute(s) in a modifiable operational
environment. The computing platform and operating system of the operational environment which the
software executes in are external to the defined software module boundary.
The maximum overall security rating of software module is Security Level 2.
7.2.3 Firmware module
A firmware module is a module whose cryptographic boundary delimits the firmware exclusive
component(s) that execute(s) in a limited or non-modifiable operational environment. The computing
platform and operating system of the operational environment which the firmware executes in are
external to the defined firmware module boundary but explicitly bound to the firmware module.
The maximum overall security rating of firmware module is Security Level 4.
7.2.4 Hardware module
A hardware module is a module whose cryptographic boundary is specified at a hardware perimeter.
Firmware and/or software, which may also include an operating system, may be included within this
hardware cryptographic boundary.
The maximum overall security rating of hardware module is Security Level 4.
7.2.5 Hybrid software module
A hybrid software module is a module whose cryptographic boundary delimits the composite of a
software component that executes in a modifiable operational environment and a disjoint hardware
component (i.e. the software component is not contained within the hardware module boundary). The
computing platform and operating system of the operational environment which the software executes
in are external to the defined hybrid software module boundary.
The maximum overall security rating of hybrid software module is Security Level 2.
7.2.6 Hybrid firmware module
A hybrid firmware module is a module whose cryptographic boundary delimits the composite of a
firmware component that executes in a limited or non-modifiable operational environment and a
disjoint hardware component (i.e. the firmware component is not contained within the hardware
module boundary). The computing platform and operating system of the operational environment
which the firmware executes in are external to the defined hybrid firmware module boundary but
explicitly bound to the hybrid firmware module.
The maximum overall security rating of hybrid firmware cryptographic module is Security Level 4.
7.3 Cryptographic module application environments
Cryptographic modules are used in context with a wide spectrum of data sensitivities (e.g. low value
administrative data, million-dollar funds transfer, life protecting data, personal identity information,
and sensitive information used by government) and in a diverse set of application environments (e.g. a
guarded facility, and office, removable media, and completely unprotected location) as Figure 3.
8 © ISO/IEC 2018 – All rights reserved

Figure 3 — A diverse set of application environments
7.4 Security products with cryptographic modules
Vendors develop and market products that include cryptographic functionality. A product may be a
cryptographic module whose boundary is identical to the validated module. A product may incorporate
an embedded validated cryptographic module in addition to other functionalities. Therefore, the
boundary of the product is not the same boundary as the validated cryptographic module.
A cryptographic module may be composed of validated cryptographic modules. A product may
incorporate the composition of validated cryptographic modules in addition to other functionalities.
Figure 4, below describes the various composition types of the cryptographic modules. The composition
types are classified as modules included by the component, modules connected in the network, and
modules composed by layering.
Figure 4 — Types of composition of cryptographic modules
If the product consists only of the validated modules, the organization can verify the validation against
the validation authorities listing of validated modules by comparing the versioning information
provided with the module's documentation from the vendor and by directly querying the module (see
ISO/IEC 19790:2012 7.2.3.1 and 7.4.3.1).
It can be difficult to perform such verification of the validated module if it is an embedded component
within a larger product. The vendor should provide product documentation that includes references to
the versioning information for the embedded validated cryptographic module. The product should also
provide a mechanism for the user to query the embedded validated module to determine the embedded
module's versioning information. When the validated cryptographic module is part of a larger product
boundary, there is no validation authority assurance on the correct operation of the larger product
utilizing the embedded module. The vendor should provide a statement of assurance that all the
cryptographic functionality within the product boundary is provided solely by the embedded validated
cryptographic modules.
If a product contains a composite of a validated cryptographic module which implements approved
security functions and a non-validated cryptographic module which implements non-approved
security functions (e.g. key establishment, key storage etc.), and the security services provided by the
module are a composite of the two embedded modules, the organization should recognize that the
© ISO/IEC 2018 – All rights reserved 9

product service can be approved or not. If the organization utilizes non-approved security services, the
operational environment can create a risk to operational security.
EXAMPLE 1 If data is encrypted by the non-validated module, and then encrypted by the validated module,
the composite result can be considered approved.
EXAMPLE 2 If a security function on the validated module utilizes key establishment function from the non-
validated module, the composite result can be considered non-approved.
If a product contains multiple cryptographic modules, each individual module's versioning information
should be verified separately against the validation authorities’ list of validated modules.
If the validated cryptographic module is a component of a larger product which contains many
components (i.e. non-security components and security components), the vendor documentation should
provide information on how to assemble or compose the components together correctly.
If the validated cryptographic module is distributed as open source code, the module’s security
policy document provides information to verify the integrity of the source code files and specify the
compilers and control parameters required to compile the code into an executable format (see ISO/
IEC 19790:2012, B.2.5).
7.5 Security requirements for cryptographic modules
7.5.1 General
The security requirements for cryptographic modules are specified in ISO/IEC 19790. There are
11 security areas in the security requirements. These areas include cryptographic module specification;
cryptographic module interfaces; roles, services, and authentication; software/firmware security;
operational environment; physical security; non-invasive security; sensitive security parameter
management; self-tests; life-cycle assurance; and mitigation of other attacks.
Four security levels are specified for each of the 11 requirement areas. Each security level o
...