A Study on the Cryptographic Module Validation in the CC Evaluation from Vendors' point of view

Nobuhiro TAGASHIRA
Canon Inc.

Copyright (C) 2007, Canon Inc. All rights reserved.

P. 0

Contents

1. Background 2. The Common Criteria Evaluation vs The Cryptographic Module Validation 1. Proposal 1 (Developers Explanation) 2. Proposal 2 (new framework) 3. Conclusion

Copyright (C) 2007, Canon Inc. All rights reserved.

P. 1

Background in Japan

Common Criteria (CC) Evaluation :

In 2001, JISEC was established In 2003, JISEC became a member of CCRA

Cryptographic Module (CM) Validation :

In 2006, JCMVP was started a shadow testing In 2007, JCMVP was established

* JISEC : Japan Information Technology Security Evaluation and Certification Scheme * JCMVP : Japan Cryptographic Module Validation Program
Copyright (C) 2007, Canon Inc. All rights reserved.

P. 2

Activities in Canon
Common Criteria (CC) Evaluation :
CCEVS-VR-04-0063 from CCEVS (US Scheme) C0010/C0012/C0020/C0027/C0032/C0036/ C0050 from JISEC

Cryptographic Module (CM) Validation :

F0002 from JCMVP

Copyright (C) 2007, Canon Inc. All rights reserved.

P. 3

The Common Criteria Evaluation

Standard : Methodology : Target : Top Description : Flow : Levels : Action : Etc : ISO/IEC 15408 (Common Criteria) CEM TOE (a set of S/W, F/W and/or H/W) Security Target ST Evaluation -> TOE Evaluation EAL1 to EAL7 Evaluation 8 Security Assurance Classes

Copyright (C) 2007, Canon Inc. All rights reserved.

P. 4

The Cryptographic Module Validation

Standard : Methodology : Target : Top Description : Flow : Levels : Action : Etc : ISO/IEC 19790 (FIPS 140-2) DTR (Derived Test Requirements) Cryptographic Module Security Policy Algorithm Testing -> Module Testing Security Level 1 to 4 Testing 11 security areas

Copyright (C) 2007, Canon Inc. All rights reserved.

P. 5

CC Evaluation vs CM Validation
The CC Evaluation and CM Validation are different in
Abstractness Focus of tests
[B2-04][B2-05]

But these are the same in the point of the view of Third Party Validation Scheme in the IT security world. In some cases, the CM validation is very effective in the cryptographic functionality of the CC Evaluation.
[B2-04] Nithya Rachamadugu, FIPS-US Cryptographic Testing Standard, ICCC 2005 [B2-05] Axel Boness, A FIPS 140-2 evaluation could authorize CC-like tests, ICCC 2005
Copyright (C) 2007, Canon Inc. All rights reserved.

P. 6

Question!
Have the CC Evaluation and CM validation produced a synergistic effect?

Answer

NO

Copyright (C) 2007, Canon Inc. All rights reserved.

P. 7

Problems and Countermeasures under the CC Evaluation and CM Validation

Problems
1. It is difficult for an end user to understand the validity of the CC Evaluation and CM Validation.

Countermeasures
CNTM1. A developer has to explain the validity of the CC Evaluation and CM Validation to an end user in the ST. CNTM2. The CC Specifications has to define the new framework for using the CM Validation.

Copyright (C) 2007, Canon Inc. All rights reserved.

P. 8

Proposal 1 for CNTM1 (Developers Explanation)

Write a ST, which clearly describes the TOE and the CM, so that an end user can understand.
Point :
It is NOT necessary to change a structure of the ST. There are some sections, which describes the CM.

Copyright (C) 2007, Canon Inc. All rights reserved.

P. 9

ST Description (Chap. 1) for Proposal 1

Security Target

ST reference TOE reference

Identify the Cryptographic Module, which is in the TOE.

ST introduction Conformance claims Security problem definition Security objectives Extended components definition Security requirements TOE summary specification

TOE overview TOE description

In the description of the physical scope of the TOE, describe the physical scope of the CM, and a relationship between the TOE and the CM. In the description of the logical scope of the TOE, describe the logical scope of the CM, and a relationship between the TOE and the CM. If the CM has some modes of the operation (e.g. CMVP mode), describe the usages of the modes of the operation of the CM in the logical description.
Copyright (C) 2007, Canon Inc. All rights reserved.

P. 10

ST Description (Chap. 2/3/4/5) for Proposal 1

Security Target

Conformance claims Security problem definition Security objectives Extended components definition

ST introduction Conformance claims Security problem definition Security objectives Extended components definition Security requirements TOE summary specification

Same descriptions as the normal ST

Copyright (C) 2007, Canon Inc. All rights reserved.

P. 11

ST Description (Chap. 6.1) for Proposal 1

Security Target ST introduction

Security functional requirements

Conformance claims Security problem definition

Refinement operations are required. Security objectives e.g. From The TSF shall Extended components definition to The TSF (CM) shall . Security requirements TOE summary specification If the ST selects some components from FCS/FPT classes, the developer has to do Refinement operations of the requirement that the CM enforces. FCS_COP : Cryptographic services FCS_CKM : Cryptographic key management FPT_TST : Self-tests FPT_PHP : Physical security (if the CM is validated at the level 3 or 4)
Copyright (C) 2007, Canon Inc. All rights reserved.

P. 12

ST Description (Chap. 6.1) (cont)

Security Target ST introduction

Security functional requirements

Conformance claims Security problem definition

If the CSPs in CM are user data of the TOE, Security objectives the developer may have to do Extended components definition Refinement operations of Security requirements TOE summary specification some components in FDP classes. If the CSPs in CM are TSF data, the developer may have to do Refinement operations of some components in FMT classes. If the CM is validated at the level 1 or higher, especially level 3 or 4, the developer may have to do Refinement operations of some components in FIA classes.

CSP : Critical Security Parameter. (e.g. Cryptographic keys, authentication data)

Copyright (C) 2007, Canon Inc. All rights reserved.

P. 13

ST Description (Chap. 6.2/6.3) for Proposal 1

Security Target

Security assurance requirements Security requirements rationale

ST introduction Conformance claims Security problem definition Security objectives Extended components definition Security requirements TOE summary specification

Same descriptions as the normal ST

Copyright (C) 2007, Canon Inc. All rights reserved.

P. 14

ST Description (Chap. 7) for Proposal 1

Security Target

TOE summary specification

ST introduction Conformance claims Security problem definition Security objectives Extended components definition Security requirements TOE summary specification

Same descriptions as the normal ST

Copyright (C) 2007, Canon Inc. All rights reserved.

P. 15

Proposal 2 for CNTM2 (new framework)

Define the new CC framework, which effectively reuse the CM Validation.
Point :
The Cryptographic Module may be a COTS product, and a developer may be a user of that. In this case, it is difficult for the developer to make design documents for the CC Evaluation. This situation is a very similar problem to a composed TOE, so we could use the same analogy as ACO class.

Copyright (C) 2007, Canon Inc. All rights reserved.

P. 16

Study 1 (I/F, functionality) for Proposal 2

Interfaces and functionalities of the CM are tested while testing.

There are NO big impact on Composition rationale (ACO_COR), Development evidence (ACO_DEV), Reliance of dependent component (ACO_REL), And Composed TOE testing (ACO_CTT).
Copyright (C) 2007, Canon Inc. All rights reserved.

P. 17

Study 2 (vulnerability) for Proposal 2

There are no vulnerability analysis of the CM.

There are big impact on Composition vulnerability analysis (ACO_VUL).

Copyright (C) 2007, Canon Inc. All rights reserved.

P. 18

Countermeasures for Proposal 2

1. Propose to ISO/IEC 19790 WG that vulnerability analysis is tested while testing the CM.
or 2. Define a new family that supports a new Composition vulnerability analysis (ACO_VUL) for an independent cryptographic module test.

Copyright (C) 2007, Canon Inc. All rights reserved.

P. 19

Conclusion
This paper shows
the problem between the CC Evaluation and the CM Validation. the proposal for the developer, and CC schemes.

This paper is also useful, during the acquisition of the some CC/CM validated products.
Future work
We have to examine a proposal 2 in detail in the viewpoint of feasibility. FIPS 140-3 is planned. We have to examine between the CC Evaluation and the new CM Validation.
Copyright (C) 2007, Canon Inc. All rights reserved.

P. 20

Thank you
Nobuhiro TAGASHIRA tagashira.nobuhiro@canon.co.jp Canon Inc.

Copyright (C) 2007, Canon Inc. All rights reserved.

P. 21