ISO/IEC 17825:2024

International
Standard
ISO/IEC 17825
Second edition
Information technology — Security
2024-01
techniques — Testing methods
for the mitigation of non-invasive
attack classes against cryptographic
modules
Technologie de l'information — Techniques de sécurité —
Méthodes de test pour la protection contre les attaques non
intrusives des modules cryptographiques
Reference number
© ISO/IEC 2024
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
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2024 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms. 3
5 Document organization . 4
6 Non-invasive attack methods . 4
7 Non-invasive attack test methods . 7
7.1 General .7
7.2 Test strategy .7
7.3 Side-channel analysis workflow .8
7.3.1 Core test flow.8
7.3.2 Side-channel resistance test framework .8
7.3.3 Required vendor information .9
7.3.4 TA leakage analysis .10
7.3.5 SPA/SEMA leakage analysis .11
7.3.6 DPA/DEMA leakage analysis . 12
8 Side-channel analysis of symmetric-key cryptosystems .13
8.1 General . 13
8.2 Timing attacks . 13
8.3 SPA/SEMA . 13
8.3.1 Attacks on key derivation process . 13
8.3.2 Side-channel collision attacks .14
8.4 DPA/DEMA .14
9 ASCA on asymmetric cryptography .16
9.1 General .16
9.2 Detailed side-channel resistance test framework .17
9.3 Timing attacks .18
9.3.1 General .18
9.3.2 Standard timing analysis .18
9.3.3 Micro-architectural timing analysis .19
9.4 SPA/SEMA .19
9.5 DPA/DEMA .19
Annex A (normative) Non-invasive attack mitigation pass/fail test metrics .21
Annex B (informative) Requirements for measurement apparatus .24
Annex C (informative) Associated security functions .25
Annex D (informative) Emerging attacks.27
Annex E (informative) Quality criteria for measurement setups .30
Annex F (informative) Chosen-input method to accelerate leakage analysis .32
Annex G (informative) Reasons that a side-channel is assessed as not measurable .33
Annex H (informative) Information about leakage location in relation to algorithm time .34
Bibliography .35

© ISO/IEC 2024 – All rights reserved
iii
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.
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 or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of 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 www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee
SC 27, Information security, cybersecurity and privacy protection.
This second edition cancels and replaces the first edition (ISO/IEC 17825:2016), which has been technically
revised.
The main changes are as follows:
— test methods have been updated as per research trends;
— an introduction has been added which states the expectations in terms of security level of this document;
— requirements have been numbered to ensure their traceability.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.

© ISO/IEC 2024 – All rights reserved
iv
Introduction
Testing requires defined constants, which are derived from an axiomatic analysis of the security problem.
The security assurance levels are bound to the testing and remaining risks. The testing approach can be
characterized as follows:
a) Testing soundness
1) A formal description of empirical closed-box testing provides the soundness, in the context of the
attack, because the testing adheres to an accepted methodology.
2) The application of the methodology does not ensure that all possible attacks are covered. Testing
allows for weakness detection in a system; hence, it increases the confidence in a system's ability to
withstand a set of simulated attacks. The implemented formalism allows to detect weaknesses, and
the outcome is a reasonable level attested by tests.
3) The level of assurance that can be reached with the methodology in this document is a
“controlled” level of “reasonable” confidence level, which is the level low to medium. Level high is
not reachable due to the closed-box approach. The meaning of “reasonable” is determined by the
customer's risk threshold. The tester is defining the level of reasonability, in accordance with a
security level target.
4) Testing is guided by a strategy, which allows for transparency in the methodology and outcomes.
5) The methodology is device-class specific. The pass/fail criteria should take into account the class
of devices under test. For example, the criteria for devices with a deterministic behaviour (i.e. bare
metal), and for devices with a complex software stack should be different.
6) Security testing is an “estimation” when based upon noisy measurements, or when the tester does
not have full control of the implementation under test (IUT).
b) Repeatability (as per ISO/IEC 17025:2017, 7.2.2.4)
Repeatability means similar results from the same (i.e. repeated) methodology, while reproducibility
means similar results from similar methodology. Security evaluation is an estimation based on noisy
measurements, on IUT whose behaviour is probably not in full control of the tester. In this document,
there is a prerequisite that the IUT is closed-box, which can behave in a non-deterministic manner (at
least, its internals – owing to some intentional randomization used as a protection). Furthermore, the
test can only be carried out based on external observations and findings. As a result, the objective is
to document a formal and transparent process of testing, where independent tests can be reproduced
with similar expected results (as much as possible, within reasonable bounds). The methodologies are
similar (e.g. executed by two testers) in that they yield similar outcome.
c) Cost of testing
1) The objective is to devote the right amount of effort for the testing of a given assurance level. Cost
effectiveness of the testing has a direct implication on assuring a certain level of security. Cost of
testing includes, but is not limited to:
i) Level of expertise and experience: Consequence/implication of using an already formalized
process (agnostic in the IUT). The testers require skills and competencies.
ii) Time: Elapsed time for data acquisition, even though the procedure is automated.
iii) Equipment: The cost impact of equipment is covered in ISO/IEC 20085-1:2019 (requirements)
and ISO/IEC 20085-2:2020 (calibration).
2) This document aims to keep cost moderate. A threshold is reached in the assurance level up to a
certain number of traces captured. The level of assurance does not increase significantly more
beyond the threshold. The prescribed methodology cannot exceed a certain level of assurance by its
design.
© ISO/IEC 2024 – All rights reserved
v
The following statements apply as an artefact of the methodology used:
d) Closed-box testing limits this methodology to exclusively test for leakage that does not account for
specific features of a given algorithm’s implementation (e.g. implementation specificities, such as
parallel execution of unrelated cryptographic operations, or countermeasures, such as random masking,
implementation of field arithmetic in elliptic curve cryptography).
e) Testing only considers leakage during tested cryptographic operations using keys. By design the process
does not look for other potential sources of leakage (e.g. emissions during transit of keys over internal
bus).
f) Results are dependent on the data sets and quality of equipment used during acquisition. Attackers with
larger resources can still exploit attack paths tested by this methodology, even if they had passed the
test based on increased resources and effort.
g) More sophisticated attacks can be applied and succeed. More sophisticated attacks refer to attacks
other than conventional ones, for example the attacks that are particular to asymmetric ciphers (see
9.2).
h) Each specific application/cryptographic module API instance also requires a delta evaluation on top of
the generic tests in this document. Such areas of assessment should include application-specific non-
parametric module usage threats, such as traffic analysis, manipulation of logical order or scope of
external operations.
In this document, requirements are numbered. By convention, the requirements are labelled as [CC.NN],
where CC represents the clause number (e.g. 06 means Clause 6), and NN represents the requirement
position within the Clause (e.g. the first requirement of Claude 6 is referred to as [06.01]). The purpose of
labelled requirements is to ease the generation of documents showing compliance with this document, and
their traceability for testers.

© ISO/IEC 2024 – All rights reserved
vi
International Standard ISO/IEC 17825:2024(en)
Information technology — Security techniques — Testing
methods for the mitigation of non-invasive attack classes
against cryptographic modules
1 Scope
This document specifies the non-invasive attack mitigation test metrics for determining conformance to the
requirements specified in ISO/IEC 19790:2012 for security levels 3 and 4. The test metrics are associated
with the security functions addressed in ISO/IEC 19790:2012. Testing is conducted at the defined boundary
of the cryptographic module and the inputs/outputs available at its defined boundary.
This document is intended to be used in conjunction with ISO/IEC 24759:2017 to demonstrate conformance
to ISO/IEC 19790:2012.
NOTE ISO/IEC 24759:2017 specifies the test methods used by testing laboratories to assess whether the
cryptographic module conforms to the requirements specified in ISO/IEC 19790:2012 and the test metrics specified in
this document for each of the associated security functions addressed in ISO/IEC 19790:2012.
The test approach employed in this document is an efficient “push-button” approach, i.e. the tests are
technically sound, repeatable and have moderate costs.
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 24759:2017, Information technology — Security techniques — Test requirements for cryptographic
modules
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 19790 and the following apply.
ISO and IEC maintain terminology 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
advanced side-channel analysis
ASCA
advanced exploitation of the instantaneous side-channels emitted by a cryptographic device that depends
on the data it processes and on the operation it performs to retrieve secret parameters
3.2
correlation power analysis
CPA
analysis where the correlation coefficient is used as the statistical method

© ISO/IEC 2024 – All rights reserved
3.3
critical security parameter class
CSP class
class into which a critical security parameter (3.3) is categorised
EXAMPLE Cryptographic keys, authentication data such as passwords, PINs, biometric authentication data.
3.4
differential electromagnetic analysis
DEMA
analysis of the variations of the electromagnetic field emanated from a cryptographic module, using
statistical methods on a large number of measured electromagnetic emanations values for determining
whether the assumption of the divided subsets of a secret parameter is correct, for the purpose of extracting
information correlated to security function operation
3.5
differential power analysis
DPA
analysis of the variations of the electrical power consumption of a cryptographic module, for the purpose of
extracting information correlated to cryptographic operation
3.6
electromagnetic analysis
EMA
analysis of the electromagnetic field emanated from a cryptographic module as the result of its logic
circuit switching, for the purpose of extracting information correlated to security function operation and
subsequently the values of secret parameters such as cryptographic keys
3.7
implementation under test
IUT
implementation which is tested based on non-invasive methods
3.8
power analysis
PA
analysis of the electric power consumption of a cryptographic module, for the purpose of extracting
information correlated to the security function operation and subsequently the values of secret parameters
such as cryptographic keys
3.9
side-channel analysis
SCA
exploitation of the fact that the instantaneous side-channels emitted by a cryptographic device depends on
the data it processes and on the operation it performs to retrieve secret parameters
3.10
side-channel collision attack
powerful category of side-channel analysis (3.9) that usually combines leakage from distinct points in time,
making them inherently bivariate
3.11
simple electromagnetic analysis
SEMA
direct (primarily visual) analysis of patterns of instruction execution or logic circuit activities, obtained
through monitoring the variations in the electromagnetic field emanated from a cryptographic module, for
the purpose of revealing the features and implementations of cryptographic algorithms and subsequently
the values of secret parameters

© ISO/IEC 2024 – All rights reserved
3.12
simple power analysis
SPA
direct (primarily visual) analysis of patterns of instruction execution (or execution of individual
instructions), in relation to the electrical power consumption of a cryptographic module, for the purpose of
extracting information correlated to a cryptographic operation
3.13
timing analysis
TA
analysis of the variations of the response or execution time of an operation in a security function, which can
reveal knowledge of or about a security parameter such as a cryptographic key or PIN
4 Symbols and abbreviated terms
ASCA advanced side-channel analysis
AES advanced encryption standard
CPA correlation power analysis
CSP critical security parameter
DEMA differential electromagnetic analysis
DES data encryption standard
DLC discrete logarithm cryptography
DPA differential power analysis
DSA digital signature algorithm
ECC elliptic curve cryptography
ECDSA elliptic curve digital signature algorithm
EM electromagnetic
EMA electromagnetic analysis
HMAC keyed-hashing message authentication code
IFC integer factorization cryptography
IUT implementation under test
MAC message authentication code
PA power analysis
PC personal computer
PCB printed circuit board
PKCS public-key cryptography standards
RBG random bit generator
RNG random number generator
© ISO/IEC 2024 – All rights reserved
RSA Rivest Shamir Adleman
SCA side-channel analysis
SEMA simple electromagnetic analysis
SHA secure hash algorithm
SNR signal to noise ratio
SPA simple power analysis
USB universal serial bus
TA timing analysis
· multiplication symbol
5 Document organization
Clause 6 specifies the non-invasive attack methods that a cryptographic module shall mitigate against for
conformance to ISO/IEC 19790:2012.
Clause 7 specifies the non-invasive attack test methods.
Clause 8 specifies the test methods for side-channel analysis of symmetric-key cryptosystems.
Clause 9 specifies the test methods for side-channel analysis of asymmetric-key cryptosystems.
This document shall be used together with ISO/IEC 24759:2017 to demonstrate conformance to
ISO/IEC 19790:2012.
6 Non-invasive attack methods
This clause specifies the non-invasive attack methods that shall [06.01] be addressed to ensure conformance
with ISO/IEC 19790:2012.
The non-invasive attacks use side-channels (information gained from the physical implementation of a
cryptosystem) emitted by the implementation under test (IUT), such as:
— the power consumption of the IUT,
— the electromagnetic emissions of the IUT,
— the computation time of the IUT.
[49]
The number of possible side-channels can increase in the future (e.g. photonic emissions, acoustic
emanations).
In order to be more formal in the taxonomy of the attacks, a formalism allows the relationships to be
highlighted between the different attacks and to have a systematic way to describe a new attack.
An attack is described in the following way:
----
KKK refers to the order of the attack (e.g. “2O” for second order attack).

© ISO/IEC 2024 – All rights reserved
YYY refers to the statistical treatment used in the attack (e.g. “S” for simple, “C” for correlation, “MI” for
mutual information, “ML” for maximum likelihood, “D” for difference of means, “LR” for linear regression,
etc.).
NOTE 1 Other statistical treatments can be inserted like “dOC” which corresponds to a correlation treatment
exploiting dth order moments (obtained for instance, by raising each targeted point in the traces to a power d, or by
combining d points per trace before processing the correlation).
XXX refers to the kind of observed side channel: e.g. “PA” for power analysis, “EMA” for electromagnetic
analysis, “TA” for timing analysis, etc.
ZZZ can refer to the profiled (“P”) or unprofiled (“UP”) characteristic of the attack. This is optional and the
default value is “UP”.
[43]
TTT refers to the direction of the attack (e.g. “V” for vertical, “H” for horizontal, “R” for rectangle).
Figure 1 — Taxonomy of non-invasive attacks
NOTE 2 Instead of just splitting advanced side-channel analysis (ASCA) into univariate and multivariate cases, the
classification can still be refined by separating attacks based on “variable distinguishers” (which focus on a particular
moment of the distribution of the target variable) from those based on “pdf distinguishers” (non-invasive analysis
distinguisher which requires as input an estimation of the leakage probability density function knowing the secret
key). The first category includes ASCA based on correlation or on the linear regression techniques. The second one
includes maximum likelihood and mutual information attacks for instance.
NOTE 3 The simple power analysis (SPA) and simple electromagnetic analysis (SEMA) attack methods include some
extensions to basic SPA and SEMA attacks (i.e. template attack). The differential power analysis (DPA) and differential
electromagnetic analysis (DEMA) attack methods include some extensions to basic DPA and DEMA attacks [i.e.
correlation power analysis (CPA) and higher-order DPA attacks]. It is not mandatory to test them in this document.

© ISO/IEC 2024 – All rights reserved
The taxonomy of non-invasive attacks is illustrated in Figure 1. The scope of this document focuses on first-
order attacks, i.e. the first two columns of Figure 1. Emerging non-invasive attacks and side-channels are
described in Annex D but are not applicable currently as required test method in this document.
The variables used in the description of ASCA are:
A cryptographic processing
C observation processing
D number of predictions
d_C multivariate degree
d_D multivariate degree
d_o dimension of observation
F function, i.e. manipulation
h observation
i index
K secret key
k1 sub key 1
k2 sub key 2
M model of leakage
N number of observations
o_i observation interval
(o_i)_i observation interval number i
pred_i prediction
t_i i iteration of time
x1_i i iteration of x1
x2_i i iteration of x2
X known data
ASCA is described in the following steps:
1) Measure N observation intervals o_i related to a cryptographic processing A parameterized by a known
input X and a secret key K.
2) (Optional) Choose a model of leakage M for the device leakage.
3) (Optional) Choose an observation processing C (by default C is set to the identity function).
4) Make all hypothesis h on the value of K or a subpart of it.
5) Select as the most likely key the hypothesis with the largest statistical test.
NOTE 4 The observations o_i can be univariate or multivariate. In the latter case, each coordinate of o_i, viewed as a
vector, corresponds to a different time t_i. The dimension of o_i is denoted by d_o in the rest of this note.

© ISO/IEC 2024 – All rights reserved
NOTE 5 In side-channel collision attacks against block ciphers, the second step is skipped and the third step
simply consists in a point selection in the traces o_i. Then, the hypothesis h typically corresponds to a hypothesis
between the difference (k1-k2) of two parts of the targeted key K (e.g. two sub-keys in a block cipher implementation).
Eventually, the predictions are deduced from the observations (o_i)_i and the difference h. If for instance the attack
targets the manipulation of a value F(x1_i+k1) [i.e. C(o_i) corresponds to the part of the observation related to the
manipulation of F(x1_i+k1)], then the attack will extract from the o_i the observations during the manipulation of
another values F(x2_i+k2). Those observations will be re-arranged such that x2_i – x1_i = h. Then h_i corresponds
to the part of the observation related to the manipulation of F(x2_i+k2) = F(x1_i+k1) if h is correct. To validate the
hypothesis, a correlation coefficient is usually used for D. Additionally, all the attacks described in Clause 6 can be
vertical, horizontal or rectangle (i.e. horizontal and vertical). An attack is said to be vertical if each observation o_i
corresponds to a different algorithm processing. If all the o_i correspond to a same algorithm processing, then the
attack is said to be horizontal. If some o_i share the same algorithm processing while some other o_i do not, then the
attack is said to be rectangle. The classical attacks specified in literature are vertical and this modus operandi will
hence be defined as the default one. Examples of attacks performed in the horizontal mode can be found in References
[43] and [44].
NOTE 6 An approval authority can modify, add or delete non-invasive attack methods, the association with security
functions (see Table C.1) and non-invasive attack mitigation test metrics specified in this document.
7 Non-invasive attack test methods
7.1 General
This clause presents an overview of the non-invasive attack test methods for the corresponding non-invasive
attack methods specified in Clause 6.
7.2 Test strategy
The goal of non-invasive attack testing is to assess whether a cryptographic module utilizing non-invasive
attack mitigation techniques can provide resistance to attacks at the desired security level. No standardized
testing programme can guarantee complete protection against attacks. Rather, effective programmes
validate that sufficient care was taken in the design and implementation of non-invasive attack mitigations.
Non-invasive attacks exploit a bias latent in the physical quantities which are non-invasively measured on or
around the IUT. Such a bias is induced from and depends on the secret information that the attacks target.
For further details, see Reference [16]. The bias can be subtle but is generally persistent. In this document,
the biased information that depends on the secret information is referred to as leakage hereinafter. A device
can fail one or more tests if experimental evidence suggests that leaking information exceeds permitted
leakage thresholds. This implies that leakage demonstrates a potential vulnerability. Conversely, attacks fail
and the test passes unless leakage is observed. The test of existence of leakage is called leakage analysis
(leak analysis) hereinafter.
The goal is to collect and analyse measurements within certain test limitations such as maximum waveforms
collected, elapsed test time, and to determine the extent of the CSP information leakage. The test limitations
and leakage thresholds constitute the test criteria. The maximum acquisition time shall [07.01] also be
bounded. The values for security Level 3 and Level 4 are detailed in Annex A.
Consider timing the attack testing. If the test reveals that the computation time is biased relative to the CSP,
the IUT fails. For DPA, if the test reveals that the power consumption during CSP-related processes is biased
relative to the CSP, the IUT fails. The testing approach uses statistical hypothesis testing to determine the
likelihood that a bias is present. Thus, this document provides a leakage threshold in terms of statistical
significance. The test fails if a bias exceeds the leakage threshold. The pass/fail conditions for the desired
security level are given in Annex A.

© ISO/IEC 2024 – All rights reserved
7.3 Side-channel analysis workflow
7.3.1 Core test flow
The tester collects measurement data from the IUT and applies a suite of statistical tests on the collected
data. See Annex B for the requirements for measurement apparatus. Core test refers to testing for a
single security function with a single critical security parameter (CSP) class, where CSP classes include
cryptographic keys, biometric data or PINs. If some security functions deal with more than one CSP class,
leakage analysis for every applicable CSP class is performed for each security function. The test method
requires repeating core tests with different CSP classes until the first fail of test occurs or all the CSP classes
pass. If a core test is unable to continue if the IUT limits the number of repeated operations, the result is
a pass and the core test is continued with the next CSP class. The core test is shown in Figure 2. The side-
channel resistance test framework is depicted in Figure 3. Leakage analysis for TA is shown in Figure 4,
SPA/SEMA in Figure 5 and DPA/DEMA in Figure 6.
Figure 2 — Core test flow
Figure 2 shows the flow of a core test. First, the vendor document is verified for the specified CSP class.
Second, the practicality of measuring the physical characteristics is determined. If the measurement cannot
be made, the test result is pass. The testing laboratory shall [07.02] provide a reason why the side-channel
is not measurable. A list of accepted reasons for a laboratory to assess a side-channel as not measurable
is given in Annex G. Third, a set of CSPs determined by the testing laboratory is configured into the IUT.
Finally, the essential part of the core test, the analysis, which is shown in Figures 3, 4, 5, 6, 7, 8, and D.1, is
performed and significant leakage is either observed or not.
7.3.2 Side-channel resistance test framework
As explained in 7.3.4, 7.3.5 and 7.3.6, a testing laboratory shall [07.03] check the security of IUTs against TA,
SPA, and DPA.
The sequential test of the three attacks leads to the attack framework depicted in Figure 3. The testing
laboratory should follow the order of the operations. For example, the SPA can be tested only if TA passed.

© ISO/IEC 2024 – All rights reserved
Figure 3 — Side-channel resistance test framework
The proposed methodology for side-channel resistance assessment does not require full key extraction to
fail a device: an IUT can fail if significant sensitive information leakage can be demonstrated. Nevertheless,
it should be noted that the primary purpose of the pass/fail criteria is that the IUT can be failed only if there
is a risk of revealing the CSP/sensitive information.
7.3.3 Required vendor information
The vendor shall [07.04] provide the following information about the algorithms and countermeasures
implemented in the IUT:
a) implemented cryptographic algorithms;
b) design of the implementation;
c) the conditions/mode(s) of usage where the IUT is susceptible to side-channel analysis.
Moreover, the testing laboratory shall [07.05] be able to modify CSPs and cipher text when performing side-
channel testing.
When performing side-channel analysis, it is common to perform signal alignment so that different traces
can be compared at the same point during the cryptographic calculation. For the purposes of side-channel
testing, the vendor should provide the testing laboratory with the best synchronization signal for the start
of the cryptographic operation. For example, in testing mode the device can provide an external trigger
point to indicate when the cryptographic operation starts or stops. If such start and stop information is not
available, the testing laboratory should adopt standard signal processing- and matching-based techniques
to perform alignment. In cases where traces are well aligned at the start of the cryptographic operation,
the laboratory can be required to use standard signal matching to perform better alignment on specific
internals of the algorithm; the number and locations of these alignment points are specified by the testing
laboratory.
The vendor should then provide a function that allows the testing laboratory to:
d) synchronize its measurements,

© ISO/IEC 2024 – All rights reserved
e) check the quality of its measurements (see 7.3.6 for more details).
7.3.4 TA leakage analysis
Figure 4 — Leakage analysis for timing attacks
Figure 4 shows the leakage analysis flow for timing attacks. The flow can be divided into two stages. For
the first stage, execution times with several different CSPs and fixed text are measured. If the measured
execution time does not show dependency with the CSP used through statistical analysis, then the test
continues to the second stage. Otherwise, the test fails. For the second stage, execution times with several
different texts and a fixed CSP are measured. If the measured execution time does not show dependency
with the text used, the test passes. Otherwise, the test fails. If the execution time is difficult to measure, a
tolerance value ε which equals a clock cycle related to the algorithm co-processer of the targeted chip should
be used. To compare the two time values (or two average time values) T and T , the test passes if |T - T | < ε,
1 2 1 2
and fails otherwise. Timing analysis shall [07.07] be performed with a sufficient number of measurements.
Detailed requirements for security level 3 and level 4 are given in Annex A.
Not only the difference of means, but also of variances, shall be computed, so as to detect second-order
[58]
timing leakage. Indeed, high-order timing attacks are practical threats.

© ISO/IEC 2024 – All rights reserved
7.3.5 SPA/SEMA leakage analysis
Figure 5 — SPA (SEMA) leakage analysis
Figure 5 shows the SPA/SEMA leakage analysis flow. The flow can be divided into two stages.
First, the testing laboratory shall [07.08] capture the number of side-channel measurements related to the
desired security level, as specified in Annex A.
Asymmetric cryptography repeatedly uses elementary operations. For RSA these are modular square
(denoted “S”) and multiply (denoted “M”) operations. For ECC, these are point doubling and addition
operations. Since the key can be derived from the order of operations, it is important for the testing laboratory
to distinguish these operations. As side-channel measurements can be noisy (see Annex E for quality criteria
for measurement setups), it can be difficult to recognize these operations visually. A good method to identify
a repeating operation is called “cross-correlation”. This method also helps to remove subjective assessment
from the testing laboratory. When the correlation is so weak that no definite statement can be taken, the
testing laboratory can mount a cluster analysis.
For all the side-channel measurements, if the cross-correlation process leads to a non-regular operation
sequence which leads to the CSP, the test result is fail. It is important to note that the IUT can only be failed if
the CSP has been revealed from the non-regular operation sequence.

© ISO/IEC 2024 – All rights reserved
7.3.6 DPA/DEMA leakage analysis
Figure 6 — DPA (DEMA) leakage analysis
Figure 6 shows the DPA/DEMA leakage analysis flow. The test lab shall [07.09] collect enough traces. The
method for calculating the number of required traces is sketched in Figure 7 and detailed in Annex A. The
result represented indicates whether or not significant leakage has been observed. In case of doubt, clear
box or white box are required to clarify the ambiguity (see Reference [45]). Indeed, if the test is a Student’s
t-test, not all leakages are sensitive: typically, possible test violations are incurred by non-CSP variables,
such as the plaintext or the ciphertext of a block cipher (see Annex H). Therefore, based on the analysis
of the IUT documentation, it can be decided whether test violations depend on the CSP or not. The same
expressions apply to Figure 6.
As a general rule, it is supposed that the cryptographic operations occur always in the same moment in
each measurement (consumptions or emanations). Nonetheless, the developers have the possibility to
include internal clocks modifying the operation frequency or introduce randomly non-operative wait status
in the algorithms execution, thus the time is no longer constant and the cryptographic operations are not
performed in the same instant. This produces the well-known misalignments in the set of traces, making
the analysis difficult and much more costly in terms of the number of traces needed to be processed. These
modifications of the original behaviour are countermeasures implemented by the developers to counteract
the possibility of acquiring information through side channels, breaking the assumptions that characterize
the known attacks.
In cryptographic implementations without specific countermeasures, misalignments come from errors in
the measurement configuration, different clock domains, bus contention, OS interrupts, etc., when starting
the power consumption (or emanations) acquisition. In this case, the traces can be aligned if the vagueness
can be determined when launching the measurement, properly displacing the traces. This process is called
static alignment. This vagueness can also be mitigat
...