Common Criteria Joint Interpretation Library

Created:  22 Oct 2015
Updated:  01 Aug 2016
Information for sponsors of smartcard evaluations.

Sponsors of smartcard evaluations should be aware that:

  1. 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.

  2. 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).

  3. 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.

  4. 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.

  5. 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.

  6. Test mode access should generally be protected by more than just confidential information (eg a 'password' or equivalent). The diverse methods should include hardware protection as well as software.

  7. 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.

  8. 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.

  9. 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.

  10. 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.

  11. 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.

  12. 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.


Was this information helpful?

We need your feedback to improve this content.

Yes No