この規格 プレビューページの目次
※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。
導入
テストには、セキュリティ問題の公理的分析から導出される定義された定数が必要です。セキュリティ保証レベルは、テストおよび残りのリスクに依存します。テストのアプローチは次のように特徴づけられます。
- a)健全性のテスト
- 1)実証的なクローズドボックス テストの正式な説明は、テストが受け入れられた方法論に準拠しているため、攻撃の状況において健全性を提供します。
- 2)この手法を適用しても、考えられるすべての攻撃が確実にカバーされるわけではありません。テストにより、システムの弱点を検出できます。したがって、一連のシミュレートされた攻撃に耐えるシステムの能力の信頼性が高まります。実装された形式主義により弱点を検出でき、結果はテストによって妥当なレベルであることが証明されています。
- 3)この文書の方法論で達成できる保証レベルは、「合理的な」信頼レベルの「管理された」レベルであり、低から中程度のレベルです。クローズドボックスアプローチのため、高いレベルには到達できません。 「合理的」の意味は、顧客のリスク閾値によって決まります。テスターは、セキュリティ レベルの目標に従って妥当性のレベルを定義します。
- 4)テストは戦略に基づいて行われ、方法論と結果の透明性が確保されます。
- 5)この方法はデバイスクラス固有です。合否判定基準では、テスト対象のデバイスのクラスを考慮する必要があります。たとえば、決定的な動作を行うデバイス (ベアメタルなど) と、複雑なソフトウェア スタックを備えたデバイスの基準は異なる必要があります。
- 6)セキュリティテストは、ノイズの多い測定に基づく場合、またはテスターがテスト対象の実装 (IUT) を完全に制御できない場合には「推定」となります。
b)再現性 (ISO/IEC 17025:2017, 7.2.2.4 に準拠)
再現性は、同じ（つまり、繰り返された）方法論からの同様の結果を意味し、再現性は、同様の方法論からの同様の結果を意味します。セキュリティ評価は、IUT の動作がおそらくテスターによって完全に制御されていない、ノイズの多い測定に基づいた推定です。この文書では、IUT がクローズドボックスであるという前提条件があり、IUT は非決定論的な方法で動作する可能性があります (少なくともその内部は、保護として使用される意図的なランダム化により)さらに、テストは外部の観察と発見に基づいてのみ実行できます。その結果、目的は、正式かつ透明性のあるテストのプロセスを文書化することでありここで, 独立したテストを（合理的な範囲内で可能な限り）同様の期待される結果で再現できるようになります。これらの方法論は、同様の結果をもたらすという点で類似しています (たとえば、2 人のテスターによって実行されます)
c)テストの費用
- 1)目的は、特定の保証レベルのテストに適切な量の労力を費やすことです。テストの費用対効果は、一定レベルのセキュリティの保証に直接関係します。テストの費用には以下が含まれますが、これらに限定されません。
- i)専門知識と経験のレベル: すでに形式化されたプロセスを使用することの結果/影響 (IUT では不可知論的)テスターにはスキルと能力が必要です。
- ii)時間: 手順が自動化されている場合でも、データ収集の経過時間。
- iii)機器: 機器のコストへの影響は、ISO/IEC 20085-1:2019 (要件) および ISO/IEC 20085-2:2020 (校正) でカバーされています。
2)この文書はコストを適度に抑えることを目的としています。一定数のトレースがキャプチャされるまで、保証レベルはしきい値に達します。保証レベルは、しきい値を超えて大幅に増加することはありません。規定された方法論は、その設計により一定レベルの保証を超えることはできません。
- 1)目的は、特定の保証レベルのテストに適切な量の労力を費やすことです。テストの費用対効果は、一定レベルのセキュリティの保証に直接関係します。テストの費用には以下が含まれますが、これらに限定されません。
次のステートメントは、使用された方法論の成果物として適用されます。
- d)クローズドボックステストは、この方法論を、特定のアルゴリズムの実装の特定の機能 (たとえば、無関係な暗号操作の並列実行などの実装仕様、またはランダム マスキング、暗号化の実装などの対策) を考慮しない漏洩のテストのみに限定します。楕円曲線暗号における体演算)
- e)テストでは、キーを使用してテストされた暗号操作中の漏洩のみが考慮されます。設計により、このプロセスは他の潜在的な漏洩源 (内部バスを介したキーの転送中の放出など) を探しません。
- f)結果はデータセットと取得中に使用された機器の品質によって異なります。より大きなリソースを持つ攻撃者は、リソースと労力の増加に基づいてテストに合格したとしても、この方法論でテストされた攻撃パスを悪用する可能性があります。
- g)より高度な攻撃が適用され、成功する可能性があります。より高度な攻撃とは、従来の攻撃以外の攻撃、たとえば非対称暗号に特有の攻撃を指します (9.2 を参照)
- h)特定のアプリケーション/暗号モジュール API インスタンスごとに、このドキュメントの一般的なテストに加えてデルタ評価も必要です。このような評価領域には、トラフィック分析、論理順序の操作、外部操作の範囲など、アプリケーション固有のノンパラメトリック モジュール使用の脅威が含まれる必要があります。
この文書では、要件に番号が付けられています。慣例により、要件は [CC.NN]ここで, CC は条項番号を表し (例: 06 は条項 6 を意味します)、NN は条項内の要件の位置を表します (例: クロード 6 の最初の要件は、 [06.01])ラベル付き要件の目的は、この文書への準拠を示す文書の生成と、テスターのトレーサビリティを容易にすることです。
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 ここで, 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.
- 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:
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] ここで, 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.