|
|
The following documents have been produced by the Joint Interpretation
Working Group (JIWG) which is composed of IT certification experts
from France, Germany, the Netherlands and the UK. The aim of
the documents is to set a framework for a common understanding
and approach so that evaluation results are comparable.The documents
contain guidelines for developers, evaluators and certifiers.
They support the main principles of evaluation and certification,
which are repeatability, reproducibility impartiality and objectivity.
Some JIWG documents now appear as Supporting Documents on the www.commoncriteriaportal.org.
| Collection
of Developer Evidence |
The
objective of this document is to facilitate effective
and flexible application of the Criteria. There is considerable
flexibility in the form in which developers may supply
deliverables as inputs to evaluation. This interpretation
examines some of the alternatives that the developer may
choose and the ways in which the evaluator may respond.
Version 1.0 August 2000 |
23k |
| Security Evaluation and
Certification of Digital Tachographs |
The European Union
has issued a Directive concerning the application of EEC
Regulations on recording equipment used in road transport.
These require the security features of the Digital Tachograph
to be evaluated and certified against ITSEC. This paper
provides guidance for those who wish to use Common Criteria
as an alternative to ITSEC and also clarifies a number
of other issues. Revised version 1.12 June 2003 |
161k |
|
The following documents address the particular challenges associated
with smart card evaluations. Smart cards are a combination of
both hardware and software and typically contain an embedded
operating system and one or more applications. Special to smart
cards are the attack scenarios, a multiphase life cycle and
the high risks associated with their operational use, e.g. in
applications for banking and digital signature.
| Requirement
to perform Integrated Circuit Evaluations |
This
describes the minimun set of capabilities that an ITSEF
must possess to carry out hardware testing. Version 1.1
July 2003 |
41k |
| Requirement to perform
Integrated Circuit Evaluations. Annex A Examples of Smartcard
Specific Attacks |
This annex provides
some examples of attacks that an ITSEF should be able
to execute during the evaluation of an integrated circuit.
Version 1.1 July 2003 |
54k |
CESG would add the following points for sponsors of smartcard
evaluations to be aware of:
- The developer needs to be made aware from an early stage
that hardware evaluation is required for any smart card
certification. This should be confirmed at least at the
evaluation start-up meeting, and probably also in the course
of evaluation of the Security Target.
- Hardware security requirements should be made clear and
explicit in the ST. This could be either by treating the
TOE as a composite TOE (the preferred approach), or at least
by identifying the hardware dependencies clearly and explicitly
in the description of threats, objectives, SFRs and (perhaps
most importantly) SARs (particularly AVA_VLA).
- For smart card ICs, technical attacks such as timing,
SPA, DPA, DFA, probing, and test mode activation should
be considered 'obvious vulnerabilities' and relevant to
AVA_VLA.2.
- TOEs using random number generation should have the quality
of random numbers assessed against a metric, and this should
be adopted as part of developer testing.
- Where cryptographic functions are used in a TOE, the way
in which cryptography is used should be examined for accuracy
and appropriateness, at least wherever claims are made about
it. This should be distinguished from the general exclusion
of cryptographic strength from the scope of evaluation.
- Test mode access should generally be protected by more
than just confidential information (e.g. a 'password' or
equivalent). The diverse methods should include hardware
protection as well as software.
- For a smart card product combining hardware and software,
the hardware part of the evaluation should be started at
an early stage (possibly even before the software). The
idea of 'adding' hardware evaluation later is similar to
the idea of 'adding' security later.
- A smart card IC should be evaluated separately if there
is a requirement to use the hardware result again, in re-evaluation
or related TOEs.
- Where a smart card IC is evaluated in the context of specific
software, there should be early agreement of the scope of
hardware and software work between the CB and the hardware
and software evaluators, to ensure that the scope of analysis
is understood and no 'gaps' are left in the TOE.
- Where a smart card IC is evaluated in the context of specific
software, the hardware evaluators should gain a good understanding
of the software context in which hardware functions are
used, in order to optimise the hardware analysis.
- Where a smart card IC is included in an evaluation, best
practice would be to include the hardware aspects of an
IC PP (even if conformance to the PP is not directly claimed).
Developers should be advised of this at an early stage.
- Developers who have no, or limited, experience of IC security
evaluation are advised to include a preliminary analysis
of the main security features to be evaluated, to allow
obvious weaknesses and vulnerabilities to be identified
at an early stage, without incurring the cost of a complete
evaluation.
|
