ISO/IEC DIS 29128-3:2025(en)

ISO/IEC JTC1/SC 27/WG 3

Date: 2025-11-05

Secretariat: DIN

Information security, cybersecurity and privacy protection — Verification of cryptographic protocols — Part 3: Evaluation methods and activities for protocol implementation verification

© ISO 2025

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

Contents

Foreword v

Introduction vi

1 Scope 1

2 Normative references 1

3 Terms and definitions 1

4 Overview 3

5 Formal evaluation methods and activities for cryptographic protocol implementation 3

5.1 General 3

5.2 Evaluation method 3

5.2.1 General 3

5.2.2 Required inputs 4

5.2.3 Cryptographic Protocol Implementation Model 5

5.2.4 Adversarial Model 5

5.2.5 Scope of cryptographic protocol implementation evaluation methodology 6

5.2.6 Pass/Fail Criteria of theoretical proof 6

5.2.7 Pass/Fail Criteria of Vulnerability Analysis 6

5.2.8 Analysis of the Attack Scenarios 6

5.2.9 Attack feasibility 6

5.2.10 Security coverage 7

5.3 Evaluation Activities 7

5.3.1 General 7

5.3.2 Identification of evaluation activities 7

5.3.3 Objective of evaluation activities 8

5.3.4 Required developer inputs 8

5.3.5 Required Evaluator Activities 8

6 Implementation Assurance Levels 8

6.1 General 8

6.2 IAL 1 9

6.2.1 Requirements 9

6.3 IAL 2 9

6.3.1 Requirements 9

6.4 IAL 3 9

6.4.1 Requirements 9

6.5 IAL 4 9

6.5.1 Requirements 9

6.6 IAL 5 10

6.6.1 Requirements 10

6.7 IAL 6 10

6.7.1 Requirements 10

6.8 IAL 7 10

6.8.1 Requirements 10

6.9 Additional information on combined assurance and confidence levels 11

7 Vulnerability Assessment 12

Annex A (informative) Example of Known Attacks 13

A.1 Attacks on TLS 13

A.2 Attacks on HSM 13

A.3 Secure-Boot 13

Annex B (informative) Example Evaluation based on Common Criteria CEM 14

B.1 Example evaluation 14

Annex C (informative) Example of Testing Tools 15

C.1 Example Testing tool 15

Bibliography 16

Foreword

ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.

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 ISO documents 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).

ISO draws attention to the possibility that the implementation of this document may involve the use of (a) patent(s). ISO takes 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 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. ISO 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.

This document was prepared by Technical Committee ISO/IEC/JTC 1, Information technology, Subcommittee SC 27, Information security, cybersecurity and privacy protection.

A list of all parts in the ISO/IEC 29128 series can be found on the ISO website.

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.

Introduction

The assurance in a cryptographic protocol implementation is key to a secure cryptographic application. This assurance requires a thorough evaluation to ensure correct functionality and security principles. ISO/IEC 29128-1 highlights the importance of the formal verification of cryptographic protocols.

In ISO/IEC 29128-2 a framework of evaluation methods and evaluation activities for verifying cryptographic protocols derived from ISO/IEC 15408-4 is presented which contain four different assurance levels and three different confidence levels in a two-dimensional score matrix. These levels are based on the theoretical proof obtained from evaluations using automated provers.

In this document, the next step in cryptographic protocol evaluation is provided, working at the implementation level. The provided methods and activities can be utilized to evaluate any cryptographic protocol implementation at a hardware level, and determine its associated assurance level, in this document defined as an Implementation Assurance Level (IAL). The IAL is based on the combination of the theoretical proof obtained when the method or activity as specified in ISO/IEC 29218-2 is applied to the cryptographic protocol, and the vulnerability analysis in terms of security is obtained by performing AVA_VAN evaluation of the implementation.

This document aims at providing the developer and implementer of a cryptographic protocol with a framework to estimate the security capabilities of the cryptographic protocol and its implementation in a generic manner and therefore provide a basis for improvement in terms of security. Additionally, it provides a means to generalize the security evaluation process of different cryptographic protocols and their implementations with an implementation assurance level framework.

Information security, cybersecurity and privacy protection — Verification of Cryptographic Protocols — Part 3: Evaluation Methods and Activities for Protocol Implementation Verification

This document explains how to conduct an evaluation of a cryptographic protocol implementation based on the method framework provided in ISO/IEC 15408-4.

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 29128‑1, Information security, cybersecurity and privacy protection — Verification of cryptographic protocols — Part 1: Framework

ISO/IEC 29218‑2, Verification of cryptographic protocols — Part 2: Evaluation methods and activities for cryptographic protocols

ISO/IEC 15408‑4:2022, Information security, cybersecurity and privacy protection — Evaluation criteria for IT security — Part 4: Framework for the specification of evaluation methods and activities

ISO/IEC 15408‑5:2022, Information security, cybersecurity and privacy protection — Evaluation criteria for IT security — Part 5: Pre-defined packages of security requirements

ISO/IEC 18045:2022, Information security, cybersecurity and privacy protection — Evaluation criteria for IT security — Methodology for IT security evaluation

For the purposes of this document, the following terms and definitions 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

attack scenario

adversarial setting that an evaluator identifies in which an underlying asset can be exploited by performing an attack

3.2

attack feasibility

degree of complexity of performing an attack with respect to an identified attack path pertaining to an attack scenario (3.1)

3.3

cryptographic protocol implementation under test

cryptographic protocol implementation model in cryptographic protocol implementation submission package (3.4) provided by a submitter to the evaluator to perform security evaluation (3.8) based on the evaluation method provided in this document

3.4

cryptographic protocol implementation submission package

formally verified cryptographic protocol specification from ISO/IEC 29128-2 and finite state model (FSM) representation of the cryptographic protocol implementation, and implementation of the cryptographic protocol combined with the evaluator capabilities (following 3.5) and a set of security properties that the evaluator must test the implementation for

3.5

common evaluation methodology (CEM)

evaluation methodology framework provided by Common Criteria standard scheme as ISO/IEC 18045:2022

3.6

implementation assurance level (IAL)

assurance metric denoting the security of the cryptographic protocol implementation under test (3.3) by the combination of the prover assurance level evaluated of the cryptographic protocol from the evaluation activity based on ISO/IEC 29128-2 and the prover assurance achieved by performing the evaluation activity based on this document.

3.7

security coverage

rationale indicating full coverage of the evaluation activity performed by the evaluator describing how all threat/attack scenarios applicable to the cryptographic protocol implementation under test (3.3) are covered

3.8

security evaluation

evaluation of the security strength and robustness of a cryptographic protocol implementation model by performing vulnerability assessment (3.9)

3.9

vulnerability assessment

security verification performed to measure the security robustness of a cryptographic protocol implementation model (3.4) following the CEM (3.5) within the scope of this document to prove the correctness of the cryptographic protocol implementation under test (3.3) and the security robustness of the design and implementation

The fundamental relationship between the three parts of the ISO/IEC 29128 is shown in Figure 1. This document provides evaluation methods and activities dedicated to evaluating the cryptographic protocol implementation. Combining the theoretical proof obtained as a result of applying the ISO/IEC 29128-2 framework with the result of applying the methods described in this document will lead to the determination of the Implementation Assurance Level (IAL) of the cryptographic protocol as described in clause 6.

Figure 1 — Evaluation relationship between different parts of the ISO/IEC 29128 with evaluation method and activities to determine the protocol Implementation Assurance Level of a cryptographic protocol

Evaluator actions provided in this clause are based on the framework contained in ISO/IEC 15408-4.

The evaluation method for a cryptographic protocol implementation depends on the type of implementation and model available. There are certain assumptions about the cryptographic protocol implementation to be made before initiating the evaluation which shall include the following:

— The functional specifications of the cryptographic protocol implementation shall satisfy the same as the original cryptographic protocol specifications.

— The protocol is implemented on generic testable system within a defined cryptographic boundary. The cryptographic boundary definitions shall follow the definitions from the ISO/IEC 19790:2025^[6].

— The implementation model shall satisfy the same security properties as in the original protocol specification.

— The implementation model shall not have any more or less capabilities than specified in the original cryptographic protocol or included in the model prepared for the ISO/IEC 29128-2 evaluation.

— The implementation model shall meet all the network communication capabilities as specified in the original cryptographic protocol specification.

— All the underlying functions for the operation of the protocol shall exist in the implementation model akin to the cryptographic protocol model prepared for the automated prover tool in the ISO/IEC 29128-2 evaluation.

— The cryptographic protocol associated with the implementation is considered to have qualified at least one qualitative analysis based on the evaluation method in ISO/IEC 29128-2, for instance, to have at least Prover Confidence Level 1 and Prover Assurance Level 1.

Similar to the scope of evaluation of symbolic cryptographic protocol models, it is also assumed that all the underlying cryptographic algorithm implementation(s) do not possess any inherent security flaws i.e., there are no security threats originating from the implementation of the cryptographic algorithms.

The following information shall be formally presented for evaluation adhering to the assumptions provided in clause 5.2.1:

— The cryptographic protocol implementation model for evaluation,

— Design description of the cryptographic protocol implementation under test with an architectural diagram,

— Interconnection and interface description of all internal modules participating in the cryptographic protocol,

— Technical specification of the cryptographic protocol implementation along with all security mechanisms implemented in the design to mitigate active and passive threats,

— A guidance document detailing the standard usage of the cryptographic protocol implementation,

— The associated firmware and software necessary to operate the cryptographic protocol implementation,

— A list of all API commands or similar details used for interfacing with other logic within the system internally on the chip or externally via the network,

— Description with respect to storage, execution and transfer, within or external to the protocol implementation boundary (the cryptographic boundary of the cryptographic protocol implementation as described in 5.2.1), of the memory and storage capabilities of the protocol implementation with associated mechanisms for handling the stored data or sensitive security parameters,

— cryptographic protocol implementation submission package with a comprehensive functional mapping demonstrating clear correspondence between:

— The formally verified cryptographic protocol specification from ISO/IEC 29128-2,

— The finite state model (FSM) representation of the implementation,

— The source code of the protocol implementation

Specifically, mapping within cryptographic protocol implementation submission shall explicitly indicate alignment for all functions, security properties, message exchanges, and capabilities between FSM and source code of the protocol implementation, following ADV_IMP component of the Assurance Development Class as described in the ISO/IEC 15408-5. Detailed mapping information shall be provided, clearly linking FSM elements and clauses such as 4.3.3 Formal protocol specification from ISO/IEC 29128-2 to insure unambiguous correspondence between protocol specification and implementation.

The cryptographic protocol implementation model shall follow all the assumptions presented in 5.2.1 and shall be accompanied by elements as listed in 5.2.2.

In addition, the protocol model shall be robust to any fault or perturbation in the system by providing sufficient protection mechanism to ensure no leakage or violation of any security properties and provide error signals by reaching an error state upon identification of any manipulation activity. This could be achieved by introducing security mechanisms such as internal self-checks and memory protection and correction mechanisms.

The adversary or evaluator in this document is a user who has full access to the cryptographic protocol implementation with all the additional information about its construction and usage. An adversary would therefore:

— Be able to operate the cryptographic protocol implementation to the fullest of its usability based on the protocol specifications,

— Be able to test for inaccuracies and leakages through any or all attack surfaces identified in the implementation by means of side channel analysis and/or by introducing perturbation through means of fault injection such as (not limited to) electromagnetic, power or clock glitch fault injections,

— Using any means available, be able to extract stored sensitive parameters that could:

— Disrupt the normal functioning of the protocol,

— Violate any security properties of the protocol,

— Extract sensitive information from the protocol implementation such as keys and unique identifiers of other users or parties involved in the protocol,

— Inject adversarial information into the protocol implementation to alter the execution parameters,

— Be able to bypass the security checks or internal security mechanisms put in place to counter such adversarial threats.

Apart from the adversarial capabilities, in the adversarial model there shall also be the provision to ensure availability of at least three or more unique parties (real or virtual) mimicking the normal behaviour of all unique protocol participants as described in the protocol specification of which the adversarial participant (evaluator) would act upon to disrupt the security properties of the protocol implementation in the events of evaluation. The requirement of at least three parties, mentioned above, is based on a protocol’s inherent communication requirements, in an adversarial context, which consists of at least one initiator, one responder and one attacker.

The scope of the evaluation is based on the assurance level that is expected from the evaluation. These assurance metrics are based on the AVA_VAN evaluation as existing in the methodology described in ISO/IEC 15408 series with five different levels of coverage as explained in Table 2.

The cryptographic protocol implementation model evaluation requires the theoretical security proof of the protocol to be available and reach at least Prover Assurance Level 1 and Prover Confidence Level 1 following the evaluation framework provided in ISO/IEC 29128-2. The theoretical proof requires the evaluation to pass the Evaluation Activity set for all security properties according to ISO/IEC 29128-2. The proof is successful only if all tests are passed.

The vulnerability analysis of the cryptographic protocol implementation model is based on the AVA_VAN method to insure that all risks, including ones of design and implementation are mitigated by some means either through secure design principles or by implementing specific security measures. The evaluator shall test the implementation model against all identifiable attack scenarios, and the proof is considered to “fail” if any of the adversarial tests are successfully executed thereby violating the security of the implementation.

The attack analysis shall comprise the following:

— Identification of all possible attack surfaces, i.e. all externally accessible interfaces, message fields, and state transitions of the cryptographic protocol implementation that can be invoked, observed, or perturbed by an adversary, in the design,

— Identification of all assets within the design to be protected. Assets can be:

— Security properties of the cryptographic protocol,

— Sensitive security parameters such as keys and data of users or parties involved in the cryptographic protocol,

— Security mechanisms or system inside the implementation boundary,

— Functional capabilities of the cryptographic protocol, and

— Control parameters.

— Creating an attack plan which contains possible attack scenarios (based on evaluator’s experience as well as on state-of-the-art information available at the time of evaluation) targeting the assets, security properties and functionality of the cryptographic protocol implementation under test,

— For each attack scenario, identifying all possible attack paths,

— Ranking each identified attack path using the metrics provided in ISO/IEC 18045:2022 for attack potential calculation with associated rationale.

The attack feasibility evaluation would depend on:

— Any available attack path to perform at least one exploitation of any asset or sensitive parameter or disruption of security properties and/or functionality of the cryptographic protocol under test, and

— Security assurance coverage expected from the cryptographic protocol implementation as in Table 2.

Security coverage is the rationale for proving that the attack analysis covers all possible threat scenarios applicable to the cryptographic protocol implementation.

The evaluation activities shall follow the work unit and evaluation activity identification as defined in Figure 2 which is adapted from ISO/IEC 15408-4.

Figure 2 — Evaluation method and evaluation activities of cryptographic protocol implementation with rationale

The evaluator shall ensure:

— The correctness of the cryptographic protocol implementation model submitted,

— The availability of all necessary capabilities and information as described in 5.2.2,

— There are no underlying faults or inherent mechanisms in the evaluation platform that may in any way disrupt the security evaluation of the cryptographic protocol implementation under test,

— All the vulnerabilities and threats are identified following the description provided in 5.2.8.,

— All the security analyses are documented following the framework provided in Figure 2,

— A rationale for evaluation coverage is prepared that may consists of the rationale within the evaluation activity for each attack scenario identified.

— The completeness and correctness of the submitted functional mapping between the formal protocol specification (ISO/IEC 29128-2), the FSM, and the source code.

The evaluator shall:

— Ensure that the full formal correctness of the evaluation is maintained and reported for the security evaluation at the selected AVA_VAN level, and

— Verify if the cryptographic protocol implementation meets the minimum security requirements for the selected assurance level following the evaluation activities in 5.3.2.

The information required as stated in 5.2.2  shall be complemented with any secure design principles that had been followed during the implementation of the cryptographic protocol.

The evaluator activities shall consist in:

— Conducting assessments for all security measures as defined in this document,

— Derive analyses for attack rationale based on the implementation design,

— Conduct attack feasibility analysis based on real test metrics either by performing physical tests as defined in this document,

— Report all findings in a standardized manner following the framework provided in this document.

— Verification of the completeness and correctness of the submitted functional mapping between the formal protocol specification (ISO/IEC 29128-2), the FSM, and the source code.

— Source Code Review, as part of the CEM, ensuring accuracy and consistency of the mapping down to the source code level.

The evaluation activities of the implementation assurance determine the vulnerability assurance level of the cryptographic protocol implementation and, combined with the theoretical proof the evaluator can determine the IAL. Table 1 presents a summary of the mapping.

The IAL 1 provides enhanced basic assurance coverage for the vulnerability assessment of cryptographic protocol implementations and the verification of security properties in the Dolev–Yao model with a bounded number of sessions. This verification shall be achieved using a tool validated through a known-answer test methodology.

To meet IAL 1, the following activities shall be successfully completed:

— AVA_VAN.1 (ISO/IEC 18045:2022)

— Prover Assurance Level 1 (ISO/IEC 29128-2)

— Prover Confidence Level 1 (ISO/IEC 29128-2)

The IAL 2 provides enhanced basic assurance coverage for the vulnerability assessment of cryptographic protocol implementations and the verification of security properties in the Dolev–Yao model with bounded number of sessions. This verification shall be achieved using a tool validated through a known-answer test methodology.

To meet IAL 2, the following activities shall be successfully completed:

— AVA_VAN.2 (ISO/IEC 18045:2022)

— Prover Assurance Level 1 (ISO/IEC 29128-2)

— Prover Confidence Level 1 (ISO/IEC 29128-2)

The IAL 3 provides enhanced basic assurance coverage for the vulnerability assessment of cryptographic protocol implementations and the verification of security properties in the Dolev–Yao model with unbounded number of sessions. This verification shall be achieved using a tool validated through a known-answer test methodology.

To meet IAL 3, the following activities shall be successfully completed:

— AVA_VAN.2 (ISO/IEC 18045:2022)

— Prover Assurance Level 1 (ISO/IEC 29128-2)

— Prover Confidence Level 2 (ISO/IEC 29128-2)

The IAL 4 provides moderate assurance coverage for the vulnerability assessment of cryptographic protocol implementations and the verification of security properties in the Dolev–Yao model with unbounded number of sessions and in computational model considering cryptographic functions. This verification shall be achieved using a tool validated through a known-answer test methodology and a double-blind validation with different independent tool.

To meet IAL 4, the following activities shall be successfully completed:

— AVA_VAN.3 (ISO/IEC 18045:2022)

— Prover Assurance Level 2 (ISO/IEC 29128-2)

— Prover Confidence Level 3 (ISO/IEC 29128-2)

The IAL 5 provides high coverage assurance for the vulnerability assessment of cryptographic protocol implementations and the verification of security properties in the Dolev–Yao model with an unbounded number of sessions and in a computational model considering cryptographic functions. This verification shall be achieved using a tool validated through a known-answer test methodology and a machine-checked proof of the tool’s output correctness.

To meet IAL 5, the following activities shall be successfully completed:

— AVA_VAN.4 (ISO/IEC 18045:2022)

— Prover Assurance Level 3 (ISO/IEC 29128-2)

— Prover Confidence Level 3 (ISO/IEC 29128-2)

The IAL 6 provides beyond high coverage assurance for the vulnerability assessment of cryptographic protocol implementations and the verification of security properties in the Dolev–Yao model with an unbounded number of sessions and in a computational model considering cryptographic functions. This verification shall be achieved using a tool validated through a known-answer test methodology and a machine-checked proof of the tool’s output correctness.

To meet IAL 6, the following activities shall be successfully completed:

— AVA_VAN.5 (ISO/IEC 18045:2022)

— Prover Assurance Level 3 (ISO/IEC 29128-2)

— Prover Confidence Level 3 (ISO/IEC 29128-2)

The IAL 7 provides beyond high coverage assurance for the vulnerability assessment of cryptographic protocol implementations and the verification of security properties in the Dolev–Yao model with an unbounded number of sessions and in a computational model considering cryptographic functions. This verification shall be achieved using a tool validated through a known-answer test methodology and by formal verification of a tool.

To meet IAL 7, the following activities shall be successfully completed:

— AVA_VAN.5 (ISO/IEC 18045:2022)

— Prover Assurance Level 4 (ISO/IEC 29128-2)

— Prover Confidence Level 3 (ISO/IEC 29128-2)

Table 1 — is referenced from ISO/IEC 18045:2022 in relation to the assurance coverage of the implementation assurance evaluation of the cryptographic protocol based on AVA_VAN vulnerability assessment

Table 2 — Assurance coverage of AVA_VAN levels based on ISO/IEC 18045:2022

The IAL structure reflects that Prover Confidence Levels serve primarily as thresholds or additional validation layers on top of Prover Assurance Levels. While Prover Assurance Levels (as defined in ISO/IEC 29128-2) provide the foundational evidence about correctness, Prover Confidence Levels (associated with AVA_VAN assessments) introduce further validation that the implementation resists practical attacks and meets specified robustness criteria.

Hence, at the lower IALs (IAL1-IAL3), Prover Assurance Levels remain modest, with Prover Confidence Levels gradually increasing to demonstrate resistance against realistic vulnerabilities. At IAL4 and above, the hierarchy is explicitly designed so that an elevated Prover Confidence Level 3 (AVA_VAN.3 and above) ensures implementations have been practically assessed for vulnerabilities in addition to their theoretical correctness.

Thus, the hierarchy emphasizes that higher IALs (IAL5-IAL7) must first enhance Prover Assurance Levels before further escalating Prover Confidence Levels, reflecting the primacy of formal correctness while recognizing practical robustness as an essential complementary criterion.

The vulnerability assessment (ISO/IEC 15408:2022) shall be performed based on the different metrics for evaluating an attack potential provided in the CEM for attack potential (using which, attack quotation of every identified attack path shall be computed) calculation. The metrics for calculating the attack feasibility are:

— Elapsed time

— Knowledge of Target of Evaluation (TOE)

— Window of opportunity

— Equipment

— Expertise

Each of these metrics is utilized for both identification and exploitation of every attack path in any attack scenario to estimate the feasibility and exploitability of the underlying asset.

The detailed description of these metrics is provided in Appendix B.6.2.4 and an example of using the metrics is provided in Appendix B.7 of the ISO/IEC 18045:2022 (CEM).

1. 
   (informative)
   
   Example of Known Attacks
   1. Attacks on TLS

— Heartbleed, a buffer over-read bug in the handling of the TLS Heartbeat extension in OpenSSL: https://heartbleed.com/

— Protocol state fuzzing of TLS implementations: https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/de-ruiter

— A Messy State of the Union: Taming the Composite State Machines of TLS: https://www.computer.org/csdl/proceedings-article/sp/2015/6949a535/17D45VsBU4g

— Multiple attacks on TLS: https://en.wikipedia.org/wiki/Security_of_Transport_Layer_Security

— Insecure primitives (e.g., RC4 is unbalanced, SWEET32: plaintext is too short)

— Insecure modes of operations (CBC is malleable, combining CBC & CMAC with same key)

— Side-channel analysis:

— compression oracle

— timing attacks on padding

• 1. Attacks on HSM

— Type confusion (data vs key) http://www.lsv.fr/Publis/PAPERS/PDF/BCFS-ccs10.pdf. Inconsistent access control on keys.

— CVE-2020-0601 - A spoofing vulnerability exists in the way Windows CryptoAPI (Crypt32.dll) validates Elliptic Curve Cryptography (ECC) certificates. An attacker could exploit the vulnerability by using a spoofed code-signing certificate to sign a malicious executable, making it appear the file was from a trusted, legitimate source, aka 'Windows CryptoAPI Spoofing Vulnerability'.

• 1. Secure-Boot

Secure boot consists in the cryptographic verification of firmware authenticity before executing them.

Secure boot consists in a chain of verifications, that can be challenged.

Example of known attack is the "Baton Drop" bootkit exploit referred to as CVE-2022-21894.

1. 
   (informative)
   
   Example Evaluation based on Common Criteria CEM
   1. Example evaluation

Attack name: Sweet32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN^[5]

CEM Attack Quotation metrics:

— Elapsed time:

— Rationale: requires 32 Gigabytes of intercepted data, about 1h of data collection, etc. "1h" elapsed time directly translate into a category of the CEM Table B.2, factor "elapsed time", score value 0 (for <= 1 day).

— CEM Table B.2 value: 0

— Knowledge of Target of Evaluation (TOE)

— Rationale: The target is available in public domain. There is no requirement to have detailed internal knowledge. This is equivalent to the “Public” factor in the CEM Table B.2.

— CEM Table B.2 value: 0

— Window of opportunity

— Rationale: Available publicly with unlimited access via internet which is equivalent to the “Unnecessary/Unlimited” factor in the CEM Table B.2.

— CEM Table B.2 value: 0

— Equipment

— Rationale: Standard equipment is sufficient, and no special setup is required which is equivalent to the “Standard” factor in the CEM Table B.2.

— CEM Table B.2 value: 0

— Expertise

— Rationale: Basic cryptography knowledge is necessary which is equivalent to “Proficient” factor in the CEM Table.

— CEM Table B.2 value: 3

Therefore, the attack quotation of the attack presented in^[5] is equivalent to 3 which is equivalent to “Basic” attack potential required to exploit the attack scenario as defined in the CEM Table B.3.

1. 
   (informative)
   
   Example of Testing Tools
   1. Example Testing tool

An example of a testing tool that can be used to complement the automated prover tools used when completing the evaluation specified in Part 2 of the ISO/IEC 29128 standard is CRYScanner^[4].

Bibliography

[1] ISO/IEC 15408‑4:2022, Information security, cybersecurity and privacy protection — Evaluation criteria for IT security — Part 4: Framework for the specification of evaluation methods and activities

[2] ISO/IEC 29128‑1:2022, Information security, cybersecurity and privacy protection — Verification of cryptographic protocols — Part 1: Framework

[3] ISO/IEC 18045:2022, Information security, cybersecurity and privacy protection — Evaluation criteria for IT security — Methodology for IT security evaluation

[4] Choudhari A., Guilley S., Karray K. “CRYScanner: Finding cryptographic libraries misuse”, 2021 8th NAFOSTED Conference on Information and Computer Science (NICS), DOI: 10.1109/NICS54270.2021.9701469

[5] Sweet32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN [online]. Available: https://sweet32.info/

[6] ISO/IEC 19790:2025, Information security, cybersecurity and privacy protection — Security requirements for cryptographic modules