technical guidance for cc evaluation

======!"§==Systems=

Technical Guidance for CC Evaluation

Wolfgang KillmannT-Systems GEI GmbH

======!"§==Systems=

Goal of the Talk

The CC community anticipates publishing technical rationale material and guidance documents to support the application of CC and CEM.

This talk concerns the need, types and examples of technical guidance for evaluation.

8. ICCC Technical Guidance for Evaluation

Wolfgang Killmann, T-Systems GEI GmbH

20.09.2006, page 2

======!"§==Systems=

Technical Guidance for EvaluationGoal of TGE

Technical guidance for evaluation (TGE)are developed for products, which use

specific technology and security techniques, supports the application of CC to specific

security techniquesaims at high quality and comparability of

evaluation results



20.09.2006, page 3

======!"§==Systems=

Technical Guidance for EvaluationIntended audience

Evaluatorsuse it as guidance to perform “state of the

art” evaluation no substitute but “stadia rod” for expertise

Overseerensures comparability of evaluation results

between products, labs, schemesDevelopers

are interested in understanding how their products will be evaluated



20.09.2006, page 4

======!"§==Systems=

Technical Guidance for Evaluation Relation to other Documents

TGE does not extend, replace or modify any requirements of CC part 3 or CEM.It advices technically how to perform work units.

TGE may be accepted as Scheme document or CC supporting document.

TGE supplements other scheme documents e.g. for the form of evaluation evidence in ETR.



20.09.2006, page 5

======!"§==Systems=

Technical Guidance for Evaluation Types of Technical Guidance for Evaluation

TGE for specific security mechanisms e.g.Random number generators

TGE for types of security techniques e.g.Cryptographic modulesSmart cards and similar devices

TGE for assurance requirements e.g.Software development tools and techniques



20.09.2006, page 6

======!"§==Systems=

Example TGE Random Number GenerationContent

TGE of random number generatorsexplains the mathematical background defines an extended security functional

component FCS_RNG.1describes pre-defined RNG classes based

on security capabilities and quality metrics states the expected developer evidenceguides the evaluator to perform specific

RNG aspects of selected CEM work units.8. ICCC Technical Guidance for

EvaluationWolfgang Killmann, T-Systems

GEI GmbH20.09.2006, page 7

======!"§==Systems=

Example TGE Random Number GenerationSecurity Capabilities and Analysis

How to evaluatepower-up online test of the digitized noise signalestimation of entropy provided for seedingDRG.3 as cryptographic post-processing

Dokumententitel Kapitelüberschrift

FCS_RNG.1 Random number generation

FCS_RNG.1.1 The TSF shall provide a [selection: physical, non-physical true, deterministic, physical hybrid, deterministic hybrid] random number generator that implements: [assignment: list of security capabilities].

FCS_RNG.1.2 The TSF shall provide random numbers that meet [assignment: a defined quality metric].

Security capability: (PTG.3.5) The RNG must not output any random numbers before the power-up online test and

seeding of DRG.3 post-processing is successfully finished.



20.09.2006, page 8

======!"§==Systems=

Example TGE Random Number GenerationTesting

Noisesource

Digiti-sation

Post-processing

Output

Noise signal

Digitisednoisesignal

Internalrandomsequence

General Design of physical RNG

Entropy of the generated random numbers used e.g for keys

Only digital sequences can be analysed by statistical tests for entropy

Dependencies in the internal sequence standard tests are not applicable

Entropy source



20.09.2006, page 9

======!"§==Systems=

Example ETG Random Number GenerationTesting: Method A

Noisesource

Digiti-sation

Post-processing

Output

Noise signal




Statistical estimation of the entropy in the generated random numbers

Statistical test suite B for independence and Shannon entropy

Entropy source: memoryless

Post-processing must not reduce the entropy in the average of time

Method A (digital noise signal is testable)



20.09.2006, page 10

======!"§==Systems=

Example TGE Random Number GenerationTesting: Method C

Method C (digitized noise signals is not testable)

C.1 The developer shall provide a comprehensible and plausible description of a mathematical model of the physical noise source and the statistical properties of the digitised noise signal sequence derived from it.

C.2 The developer shall perform specific statistical tests and document the results to estimate the entropy of the digitized noise signal sequences.

C.3 The test results shall show that the internal number sequences pass the statistical test suite B under the environmental conditions insofar as these can influence the function of the noise source and may be affected by an attacker with the attack potential identified in the security target.

C.4 The developer shall provide a rationale that the tests in C.3 are suitable taking into account the mathematical post-processing and the statistical properties of the noise signal sequence derived from the mathematical model of the noise source

Noisesource

Digiti-sation

Post-processing

Output

Noise signal






20.09.2006, page 11

======!"§==Systems=

Example TGE Cryptographic ModulesOverview

PPs for cryptographic modules of different security levels are developed

TGE for Cryptographic modules (CM)explains cryptographic techniques

addressed in the PPsdescribes the application of CC evaluation

methodology to cryptographic modulesgives support to the evaluatorsaims at comparability of evaluation results



20.09.2006, page 12

======!"§==Systems=

Example TGE Cryptographic ModulesSurvey of Topics

Some topics explained in the TGEappropriate usage of Endorsed

cryptographic algorithms and protocolscryptographic key managementphysical protection of keys testing the implementation of cryptographic

algorithms and protocolsvulnerability assessment of CM

(without cryptanalysis of endorsed cryptographic algorithms and protocols)



20.09.2006, page 13

======!"§==Systems=

Example TGE Cryptographic ModulesCryptographic Key Management (examples only!)

Root key

Data encr. key

Key encr. key

Encrypted data

• stored in protected area• internally generated or

imported by key components• usage controlled by Crypto

officer, security attributes• …

• only used for key management operation

• separation of key domains• erased in case of error• …

• protects all data encrypted with this key

• side channel attacksagainst keys(timing, power, emanation)

• …

•FPT_PHP.3, FCS_CKM.4•FCS_CKM.1, FCS_CKM.2,FTP_ITC.1

•FDP_ACC.1, FDP_ACF.1,FMT_MSA.x

• …

•FDP_ACC.1, FDP_ACF.1,FCS_COP.1

•ADV_ARC.1•FPT_FLS.1•…

•FDP_ACC.1, FDP_ACF.1,FCS_COP.1

•FDP_IFF.2, FDP_IFC.1, FPT_EMSEC.1

•…

• side channel attacksagainst confidential data(timing, power, emanation)

• …

•FDP_IFF.2, FDP_IFC.1, FPT_EMSEC.1

•…



20.09.2006, page 14

======!"§==Systems=

Example TGE Cryptographic ModulesSide channels

TGE explains specific aspects of the evaluator work units e.g. vulnerability analysis: side channel attacksADV_ARC.1-2: domain separation for keys,

(red) plaintext and (black) ciphertextADV_TDS.3: description of countermeasures AVA_VAN.4-6: penetration tests for CM

- timing analysis (e.g. Bleichenbacher attack on SSL server)

- power analysis (e.g. for smart cards and multi-chip devices)

- emanation analysis (passive and active)



20.09.2006, page 15

======!"§==Systems=

Example Smart Card and similar DevicesSupporting Documents

Supporting documents for smart cards and similar devices are currently updated for the application of CC / CEM version 3.1.

The JIL Hardware-related Attacks Subgroup (JHAS) updated the international agreed document for attack potential quotation related to smart cards and similar devices.



20.09.2006, page 16

======!"§==Systems=

Example Smart Card and similar DevicesHow to analyse

These documents should be supplemented by a document on vulnerability assessments methodology how to find vulnerabilities and to perform

penetration test (not only how to assess the results)

requires evaluation labs to use state of the art methods of the analysis

helps to ensure comparability of results based on commonly accepted methods



20.09.2006, page 17

======!"§==Systems=

Conclusion

Technical guidance for evaluation support evaluation of products using specific security techniques aims at soundness and comparability of evaluation results.

Technical guidance documents were developed and approved by practical experience.

They shall be updated and adapted to progress in security technique and developments of the CC and CEM.



20.09.2006, page 18

======!"§==Systems=

Contact information

Wolfgang KillmannT-Systems GEI GmbH

Rabinstrasse 8D-53111 Bonn

[email protected]