Supporting Document Mandatory Technical Document Composite product evaluation for

Supporting Document Mandatory Technical Document  Composite product evaluation for

Supporting Document

Mandatory Technical Document

Composite product evaluation for

Smart Cards and similar devices

April 2012

Version 1.2

CCDB-2012-04-001

Foreword

This is a supporting document, intended to complement the Common Criteria version 2 and 3 and the associated Common Evaluation Methodology for Information Technology Security

Evaluation.

Supporting documents may be “Guidance Documents”, that highlight specific approaches and application of the standard to areas where no mutual recognition of its application is required, and as such, are not of normative nature, or “Mandatory Technical Documents”, whose application is mandatory for evaluations whose scope is covered by that of the supporting document. The usage of the latter class is not only mandatory, but certificates issued as a result of their application are recognized under the CCRA.

Technical Editor: NLNCSA

Document History:

V1.2, April 2012: Update of platform certificate validity rules for composition

V1.0, September 2007 : Initial release.

General purpose:

The security properties of both hardware and software products can be certified in accordance with CC. To have a common understanding and to ensure that CC is used for hardware integrated circuits in a manner consistent with today’s state of the art hardware evaluations, the following chapters provide guidance on the individual aspects of the CC assurance work packages in addition to the Common Evaluation Methodology [CEM].

Field of special use: Smart cards and similar devices

Acknowledgments:

The governmental organisations listed below and organised within the Joint Interpretation

Working Group contributed to the development of this version of this Common Criteria

Supporting document.

France:

Germany:

Italy :

Netherlands:

Spain:

Agence Nationale de la Sécurité des Systèmes d'Information

Bundesamt für Sicherheit in der Informationstechnik

Organismo di Certificazione della Sicurezza Informatica

Netherlands National Communications Security Agency

Ministerio de Administraciones Públicas and Centro Criptológico

Nacional

United Kingdom: Communications-Electronics Security Group(CESG)

They also acknowledge the contribution of the work done by several smart card vendors, evaluation labs, and other companies organised within:

-

eEurope

-

International Security Certification Initiative (ISCI)

CCDB-2012-04-001 Composite product evaluation for Smart Cards and similar devices

Table of contents

1

1.1

1.2

1.3

1.4

2

2.1

2.2

3

3.1

3.2

3.3

3.4

4

4.1

4.2

4.3

4.4

4.5

4.6

4.7

Introduction ..........................................................................................6

History ....................................................................................................6

Definitions...............................................................................................6

Composite product evaluation and ACO (CC V3)...................................6

Objective and scope ...............................................................................8

Definitions / Terminology ....................................................................9

Definitions...............................................................................................9

Roles ....................................................................................................10

Composite evaluation concept..........................................................12

What are the issues?............................................................................12

What information is needed?................................................................12

Case of composite product change ......................................................13

Specific case when the application is already certified .........................13

Composite evaluation activities description....................................14

Evaluation of the composite product Security Target ...........................14

Integration of the application in the configuration management system14

Compatibility check for delivery and acceptance procedures ...............15

Compliance of designs .........................................................................15

Composite product functional testing....................................................15

Composite product vulnerability analysis..............................................16

Deliveries..............................................................................................17

5

5.1

5.2

5.3

6

6.1

ETR for composite evaluation ...........................................................20

Objective of the document....................................................................20

Generic rules: .......................................................................................20

Content of the ETR for composite evaluation .......................................20

Evaluation/Certification reports and Platform certificate validity ..24

Composite evaluation based on different versions of CC .....................25

7

7.1

7.2

7.3

References ..........................................................................................27

CCV2.3 documents ..............................................................................27

CC V3 documents ................................................................................27

Supporting documents..........................................................................27

Appendix 1: Composite-specific requirements ....................................................28

Appendix 1.1: Composite-specific tasks for a composite evaluation in CC V2.x29

Appendix 1.2: Composite-specific tasks for a composite evaluation in CC V3.151

Appendix 2: ETR for composite evaluation template ...........................................73

April 2012 Version 1.2 Page 4/73

CCDB-2012-04-001 Composite product evaluation for Smart Cards and similar devices

Figures

Figure 1 - ACO composed TOE (package CAP) ....................................................................... 7

Figure 2 - Composite product evaluation (current approach) .................................................... 7

Figure 3 - Composite evaluation scope example ....................................................................... 9

Tables

Table 1 - Definition of composition documents....................................................................... 18

Table 2 - Main Deliveries between actors................................................................................ 18

Table 3 - Example of composite TOE use cases...................................................................... 19

Tabel 4 - Configuration list example for hardware Platform................................................... 22

April 2012 Version 1.2 Page 5/73

CCDB-2012-04-001

1 Introduction

Composite product evaluation for Smart Cards and similar devices

1.1 History

1

The Common Criteria (CC) are being widely used for smart card products security evaluation. Smart card evaluation showed very early a need for interpretation and supporting documents.

2

The initial reason was that a smart card is built up with a combination of two parts: a hardware integrated circuit part and a software part often developed by different actors with specific objectives.

3

4

5

6

One objective was to independently perform one evaluation of a platform to address several applications and customers.

Another objective was to create one or several applications to load on one or several certified platforms.

The objective for Application Integration was to install one or several applications onto one already certified platform to reduce the evaluation effort keeping a high level of confidence.

To achieve these objectives, a transfer of knowledge and a reuse of evidences have been defined.

1.2 Definitions

7

The hardware part and associated libraries (if applicable) is evaluated independently as it can be used with many different software applications.

8

9

The software is embedded in the hardware and is built to operate with this hardware.

The resulting product is the one which is used in the field (cellular phones, banking cards, health cards, Identity, digital signature, e-pass, e-ticketing etc.) and on which customers/users need to gain confidence.

Another specificity of the smart card type product is that the software part has to use, control, configure or activate the security mechanisms provided by the hardware.

1.3 Composite product evaluation and ACO (CC V3)

10

Although the CC version 3 introduces the specific assurance class ACO for composition, this class is not suitable for usual smart card and similar devices evaluation.

11

ACO addresses a TOE composed of two certified TOEs: the Base TOE and the

Dependent TOE (see Figure 1). The evaluation of the composed TOE consists in evaluating the interaction between both TOEs, reusing evaluation results of Base TOE and Dependent TOE.

April 2012 Version 1.2 Page 6/73

CCDB-2012-04-001

12

Composite product evaluation for Smart Cards and similar devices

The result of this evaluation is not an EAL level, but a CAP level which is not comparable to EAL level. Furthermore, ACO class is applicable up to Extended-Basic assurance level, whereas smart cards especially in banking or signature type application require ‘High Level’ assurance.

Composed TOE

Certified Dependent TOE

13

14

Certified Base TOE

Figure 1 - ACO composed TOE (package CAP)

For smart card and similar devices the composite product is the final product for which an EAL level certification is required. This allows a direct comparison with similar products certified after a single evaluation.

Considering smart card architecture, it is composed of a hardware platform and a software application. In the Composite TOE evaluation, the platform is certified, the application is evaluated and the results of the platform certification are reused. See

Figure 2 for security certification of the entire Composite TOE.

Composite TOE

Application

15

16

17

Certified Platform

Figure 2 - Composite product evaluation (current approach)

The hardware platform has no ‘strictly functional’ properties related to security. It provides mechanisms to protect the composite product assets, but the composite product behaviour depends widely on the software application having to use, to configure and activate these security mechanisms.

Therefore, the hardware platform evaluation results provide security recommendations and conditions for the software application implementation. The composite product evaluator shall examine amongst other that the combination of both products does not lead to any exploitable vulnerability.

The smart card composite evaluation methodology defines precise work units with clear statement on the information needed from the platform developer and provides an agreed “framework” for information transfer from platform to composite product evaluator.

April 2012 Version 1.2 Page 7/73

CCDB-2012-04-001

18

Composite product evaluation for Smart Cards and similar devices

The information required is already available from the platform evaluation tasks and no additional work is required from platform developer.

There is no need for details on the platform development class ADV.

The user guidance (AGD) of the platform is considered early in the development of the composite product and provides all interfaces information needed.

19

The evaluated interfaces of the platform are relied upon.

All relevant interfaces between platform and application are in the scope of the composite product evaluation.

Test (ATE) and vulnerability assessment (AVA) are performed on the composite product taking advantage of platform evaluation results.

Current concept of the Composite TOE evaluation does not limit the composite evaluation in EAL and resistance against attacks, i.e. up to ‘high’, whereas Composed

TOE (CAP package) is limited by resistance against attacks ‘extended-basic’.

1.4 Objective and scope

20

The objective of this document is to precisely define tasks for the different parties involved in the composite product evaluation.

21

22

23

The aim is not to define an additional assurance class, but to define refinements to the existing assurance requirements for a composite product evaluation.

This document does not address smart cards only, but any other security IT technology where an independently evaluated product is part of a final composite product to be evaluated.

Therefore this document addresses smart cards and similar devices.

April 2012 Version 1.2 Page 8/73

CCDB-2012-04-001

2 Definitions / Terminology

Composite product evaluation for Smart Cards and similar devices

2.1 Definitions

24

The composite product is a product consisting of at least two different parts, whereby one of them represents a single product having already been evaluated and certified.

25

The composite TOE is defined in such a way that it comprises the whole composite product, i.e. the certified product is declared to be part of the composite TOE: The composite product is equivalent to the composite TOE.

An evaluation of the composite TOE is a composite evaluation.

Usually a composite product consists of two components, whereby the first one represents an ‘underlying platform

1

and the second one constitutes an

application’ running on this platform. The underlying platform is the part of the composite product having already been evaluated (see Figure 3):

Phase 1: A Platform is certified

Part of the

Platform outside the Platform evaluation scope

Part of the Platform within the

Platform evaluation scope

Phase 2: a composite product is built using an application embedded on the certified platform

Part of the

Platform outside the Platform evaluation scope

Part of the

Application outside the composite evaluation scope

Part of the Platform within the

Platform evaluation scope

Part of the certified Platform within the composite evaluation scope

Part of the Application within the composite evaluation scope

Composite evaluation

Figure 3 - Composite evaluation scope example

Exemplifying we can mention an operating system (‘application’) running on a hardware platform (‘underlying platform’) or a JavaCard

TM

applet

(‘application’) running on a Java Card runtime environment (‘platform’).

1

such a platform might also be called ‘abstract machine’ or ‘virtual machine’

April 2012 Version 1.2 Page 9/73

CCDB-2012-04-001 Composite product evaluation for Smart Cards and similar devices

Further examples are crypto-boxes and secure terminals containing a

SAM/HSM

2

: the crypto-box hardware with a boot-loader (and perhaps with a core operating system) represents the ‘underlying platform’, a special cryptobox application running on it is the ‘application’; the evaluated SAM/HSM plays usually the server role and represents the ‘underlying platform’, the

SAM-external terminal application software playing the SAM-client-role represents the ‘application’.

In order to keep the document and terminology simple we consider only the two-component composite products and use the term ‘platform’ for the underlying certified product and the term ‘application’ for the software product running on the platform.

26

These definitions comply with ACO class definitions where:

A platform is the base component,

An application is the dependent component.

2.2 Roles

27

The following roles shall be considered in the composite evaluation activities:

Platform Developer: Entity developing the platform; it might also be the sponsor of the platform evaluation.

Platform Evaluator: Entity performing the platform evaluation.

Platform Certification Body: Entity performing the platform certification, defined in CC V3 terminology as evaluation authority.

Application Developer: Entity developing the application running on the platform.

Composite Product Integrator: Entity installing the applications on the platform.

Composite Product Evaluator: Entity performing the composite product evaluation.

Composite Product Certification Body: Entity performing the composite product certification defined in CC V3 terminology as evaluation authority.

Composite Product Evaluation Sponsor: Entity in charge of contracting the composite product evaluation.

28

Each evaluation shall associate particular organizations or persons to these generic roles.

29

In order to illustrate the role of the Composite Product Integrator let us exemplify:

2

security access module / hardware security module

April 2012 Version 1.2 Page 10/73

CCDB-2012-04-001

Composite product evaluation for Smart Cards and similar devices

Smart cards: The ‘underlying platform’ is an integrated circuit and the

Platform Developer is the integrated circuit (chip) manufacturer; the

‘application’ is a card operating system and the Application Developer is the developer of the smart card software. In this case, the role of the Composite

Product Integrator is played by (i) the chip manufacturer embedding the core of the operating system into the ROM of the chip, then by (ii) the card manufacturer usually loading some parts of the operating system and the applications into the EEPROM of the chip.

Java Card technology-enabled devices: The ‘underlying platform’ is the Java

Card runtime Environment (Java Card RE) on chip and the Platform

Developer is the card manufacturer/issuer; the ‘application’ is the Java Card applet. In this case, the role of the Composite Product Integrator is played by the domain/application service provider or by a trust centre loading the applet and often personalizing the card electronically.

Crypto-Boxes: The role of the Composite Product Integrator is often played by the crypto-box manufacturer itself: he produces the entire crypto-box including the operating system and the concrete applications and then delivers the final composite product to a customer. In general, the customizer of the crypto-box is the Composite Product Integrator.

April 2012 Version 1.2 Page 11/73

CCDB-2012-04-001

3 Composite evaluation concept

Composite product evaluation for Smart Cards and similar devices

3.1 What are the issues?

30

The assets to be protected are the final composite product assets defined in the composite product Security Target.

31

32

The security mechanisms involved in the protection of these assets are those provided by the platform and by the application itself.

Some of the security mechanisms provided by the platform may require configuration, programming or activation by the application.

33

34

35

Therefore the Application Developer needs all the information (in form of a guidance or user’s manual) related to the platform security mechanisms the application has to manage.

Furthermore he needs the platform security target in order to build the composite product security target and to ensure consistency of security definition between both developments. Evaluation is performed and validated on the final composite product.

The Composite Product Evaluator has to examine, whether the level of security required by the Security Target of the resulting composite product is achieved, when both parts are combined. Therefore the Composite Product Evaluator has to execute the evaluation tasks needed with respect to the Security Target of the final composite product and to provide the related ETR. In this perspective, the Composite Product

Evaluator should reuse the platform’s evaluation and certification result thus saving cost and time.

3.2 What information is needed?

36

The Composite Product Evaluator does not need all platform evaluation results. The security certificate and the certification report assure that the platform has been evaluated according to the Common Criteria. The Composite Product Evaluator will need complementary information on the assurance measures where both developments interfere. The Composite Product Evaluator will need the same level of knowledge about the platform as the Application Developer to check that the application meets the security recommendations on the platform usage. In addition to the standard amount of evaluation contributions according to the assurance package chosen for the composite evaluation (e.g. an EAL level) evaluation, he will need the following (see section 4.7 ‘Deliveries’ for further details):

All the information delivered from the Platform Developer to the Composite

Product Integrator,

All the information delivered from the Platform Developer to the Application

Developer,

April 2012 Version 1.2 Page 12/73

CCDB-2012-04-001

Composite product evaluation for Smart Cards and similar devices

ETR for composite evaluation prepared by the Platform Evaluator, see

37 vulnerability analysis and penetration testing),

Information on compliance of the Security Targets and the designs of the platform and the application prepared by the Application Developer,

Information on compliance of the delivery procedures of the Platform and

Application Developers with the acceptance procedure of the Composite

Product Integrator, and

Information on integration of both parts using their correct certified versions and the correct configuration parameters. This information shall be prepared by the Composite Product Integrator; it also implies assurance that the application is correctly managed by the Platform Developer (e.g. in the case of smart card where ROM code is supplied for masking on the platform).

Composite Product Certification Body will need the same amount of information as the Composite Product Evaluator.

3.3 Case of composite product change

38

In case of composite product changes due to a change of the platform or the application or both, please refer to [CC AC].

39

40

If a change comes from the platform, the assessment of the change for the platform is given by the Platform Certification Body. On this basis, the assessment of the change for the composite product is given by the Composite Product Certification

Body.

If a change comes from the application, the assessment of the change for the composite product is given by the Composite Product Certification Body.

3.4 Specific case when the application is already certified

41

In the case where both platform and application have already been certified, a partial evaluation work may be performed regarding the results already obtained from previous application evaluation. Nevertheless, the composite evaluation tasks as defined in this document are still required.

April 2012 Version 1.2 Page 13/73

CCDB-2012-04-001 Composite product evaluation for Smart Cards and similar devices

4 Composite evaluation activities description

42

43

44

45

The current approach can be applied independent of the evaluation assurance level

(EAL) for the composite product aimed. Where some evaluation activities are not applicable due to the EAL chosen, they are also not expected to be applied.

For the following paragraphs, we assume that the level of assurance of the platform is equivalent or higher compared to the composite product evaluation level.

Other cases must be discussed within the schemes.

The composite-specific developer and evaluator action elements as well as the evaluator actions (work units) belonging to the composition activities are defined as the refinements for composite evaluation, see Appendix 1: Composite-specific requirements.

4.1 Evaluation of the composite product Security Target

46

A Security Target for the composite product has to be written and evaluated.

47

The Composite Product Evaluator has to examine that the Security Target of the composite product

3

does not contradict the Security Target of the underlying platform

4

. In particular, it means that the Composite Product Evaluator has to examine the Composite- and the Platform- Security Target for any conflicting assumptions, compatibility of security objectives, security requirements and security functionality needed by the application.

[R1] This task can be reduced, if some matching has been checked for Protection

Profiles claimed by each Security Target.

[R2] The Composite Product Evaluation Sponsor must ensure that the security target of the platform is available to the Application Developer, to the

Composite Product Evaluator and to the Composite Product Certification

Body. The information available in public version of the security target may not be sufficient.

4.2 Integration of the application in the configuration management system

[R3] The Composite Product Evaluator shall verify that the evaluated version of the application has been installed onto / embedded into the evaluated version of the underlying platform.

[R4] The Composite Product Evaluation Sponsor must ensure that appropriate evidence generated by the Composite Product Integrator is available to the

Composite Product Evaluator. This evidence may include, amongst other,

3

denoted by Composite-ST in the following

4

denoted by Platform-ST in the following

April 2012 Version 1.2 Page 14/73

CCDB-2012-04-001 Composite product evaluation for Smart Cards and similar devices the configuration list of the Platform Developer provided within its acknowledgement statement.

4.3 Compatibility check for delivery and acceptance procedures

[R5] The Composite Product Evaluator shall verify that delivery procedures of the Application and Platform Developers are compatible with the acceptance procedure used by the Composite Product Integrator.

[R6] The Composite Product Evaluator shall verify that all configuration parameters prescribed by the Application and Platform Developers (e.g. prepersonalization data, pre-personalisation scripts) are used by the Composite

Product Integrator.

[R7] The Composite Product Evaluation Sponsor must ensure that appropriate evidences generated by the Composite Product Integrator are available to the

Composite Product Evaluator. These evidences may include, amongst other, the

 Element of evidence for the application reception, acceptance and parameterisation by the Platform Developer (in form of acknowledgement statement).

4.4 Compliance of designs

[R8] The Composite Product Evaluator shall verify that stipulations for the

Application Developer imposed by the Platform Developer in its certified user guidance and referenced in the platform certification report are fulfilled by the composite product, i.e. have been taken into account by the Application

Developer.

[R9] The Composite Product Evaluation Sponsor must ensure that the following are made available to the Composite Product Evaluator:

 The platform-related user guidance,

ETR for Composition prepared by the Platform Evaluator, see chapter

5 ‘ETR for composite evaluation’,

 The Certification Report for the platform prepared by the Platform

Certification Body,

 A rationale for secure composite product implementation including evidences prepared by the Application Developer.

4.5 Composite product functional testing

[R10] Some application functionality testing can only be performed on emulators, before its embedding/integration onto the platform, as effectiveness of this testing (pass/fail) may not be visible using the interfaces of the composite product. Nevertheless, functional testing of the composite product shall be

April 2012 Version 1.2 Page 15/73

CCDB-2012-04-001 Composite product evaluation for Smart Cards and similar devices performed also on composite product samples according to description of the security functions of the composite TOE and using the standard approach as required by the relevant assurance class. No additional developer’s action is required here.

[R11] The Composite Product Evaluator shall check the minimal amount of the testing necessary for the current composite evaluation having been performed on the composite product as a whole. That is what is called further in the document integration testing.

[R12] Since the amount, the coverage and the depth of the functional tests of the platform have already been validated by the platform certificate, it is not necessary to re-perform these tasks in the composite evaluation. Please note that ETR for Composition (see chapter 5 ‘ETR for composite evaluation’) does not provide any information on functional testing for the platform.

[R13] The Composite Product Evaluation Sponsor must ensure that the following is available to the Composite Product Evaluator:

 Composite product samples suitable for testing.

4.6 Composite product vulnerability analysis

[R14] The Composite Product Evaluator shall perform a vulnerability analysis for the composite product using, amongst other, the results of the platform evaluation and certification. This vulnerability analysis shall be confirmed by penetration testing.

[R15] In special cases, the vulnerability analysis and the definition of attacks might be difficult, need considerable time and require extensive pre-testing, if only documentation is available. The platform may also be used in a way that was not foreseen by the Platform Developer and Platform Evaluator, or the

Application Developer may not have followed the stipulations provided with the platform certification. Different possibilities exist to shorten composite vulnerability analysis in such cases:

The Composite Product Evaluator can consult the Platform

Evaluator and draw on his experience gained during the platform evaluation.

 Separation of vulnerabilities of application and platform with the use of

“open samples” (“open samples” are samples of the platform on which the Composite Product Evaluator can load software on his own discretion). The intention is to use test software without the application countermeasures without deactivating any platform inherent countermeasure. The aim is clearly not to repeat the platform evaluation. (Refer to [JIL AP] for further details).

[R16] The Composite Product Evaluation Sponsor must ensure that the following are made available to the Composite Product Evaluator:

April 2012 Version 1.2 Page 16/73

CCDB-2012-04-001 Composite product evaluation for Smart Cards and similar devices

The ETR for Composition (ETR_COMP) prepared by the Platform

Evaluator, see chapter 5 ‘ETR for composite evaluation’ below, and

The Certification Report for the platform prepared by the Platform

Certification Body.

4.7 Deliveries

48

The tables below summarize the documentation deliveries that are exchanged between parties to enable the composite evaluation activities as defined in the previous paragraphs.

49

50

The Composite Product Evaluation Sponsor is in charge of the initialization of the process.

The Composite Product Evaluation Sponsor is responsible for maintaining or creating any Non Disclosure Agreement (NDA) that would be necessary between all the parties involved in the composition activities.

51

The Non Disclosure Agreement should be established according to the sensitivity and ownership of the information to be exchanged

## Document / Contribution

1 Platform Security Target

Description

Security Target of the platform as referenced in the platform certification report.

2 Platform open samples for testing

3 Platform user guidance

4 Platform ETR_COMP

Platform samples as defined in [JIL AP] Chapter

3.8.

It encompasses all platform user guidance and manuals needed for the Application Developer and the Composite Product Integrator being referenced in the platform certification report.

ETR for composition as defined in chapter 5 and referenced in the platform certification report.

5 Platform certification report Platform certification report issued by authorized

Platform Certification Body.

6 Design compliance evidence It enfolds evidence elements on how the requirements on the application design, imposed by the platform’s guidance and certification report, are fulfilled in the composite product.

If such a requirement was not followed, a rationale that the chosen composite product implementation is still secure shall be given here.

April 2012 Version 1.2 Page 17/73

CCDB-2012-04-001

## Document / Contribution

Composite product evaluation for Smart Cards and similar devices evidence

Description

It comprises

(i) Identification elements of the composite product

- proving that the correct, certified version of the platform is used in the composite product,

8 Delivery and acceptance procedures evidence

- proving that the correct, evaluated version of the application has been integrated; and

(ii) Evidence elements that configuration parameters prescribed by the Platform and

Application Developers are actually being used by the Composite Product Integrator.

Evidence elements how the delivery procedures of the Platform and Application Developers are compatible with the acceptance procedure of the

Composite Product Integrator

Table 1 - Definition of composition documents

52

The following table shows which documents/contributions of Table 1 shall be provided to which actor within the composite evaluation process:

Actors

## Documents/contributions having to be provided to

Composite product evaluation

Composite product integrator

Applica- tion developer

Composite product

Evaluator

Composite product

Certifica-

Sponsor tion Body

1

Platform Security

Target

2 Platform open samples

5

No No No Yes No

3 Platform user guidance

4 Platform No

5

Platform certification report

No No Yes Yes

Yes Yes Yes Yes Yes

6

Design compliance evidence

No Yes Yes Yes Yes

No No No Yes Yes

7

8

Composite configuration evidence

Delivery and acceptance procedures evidence

No No No Yes Yes

No No No Yes Yes

Table 2 - Main Deliveries between actors

5

Only if requested by composite product evaluator as defined in [CC-AP]

April 2012 Version 1.2 Page 18/73

CCDB-2012-04-001

53

Composite product evaluation for Smart Cards and similar devices

The next table shows some example of Composite TOE use cases with definition of the components and the roles.

Components & roles definitions

The Platform is

The Application is

The Platform Developer is

The Application

Developer is

The Composite Product

Integrator is

Smartcard –I

The composite TOE is built of

- a Security IC with an application code loaded in

ROM (Masking operation) and application data loaded in EEPROM.

The Security IC

The Operating System code plus additional data files

The Security IC

Manufacturer:

- Develops and manufactures the Security

IC

The Smartcard Software developer:

- Develops the application;

- Provides the application to Composite product integrator

The Security IC

Manufacturer:

- is in charge of OS masking in ROM and of loading Application data in EEPROM;

- Delivers the Composite

TOE to be evaluated

Composite TOE example

Smartcard –II

The composite TOE is built of

- a Security IC without

ROM, but offering Flash technology and Flash loader

- an application code and data loaded into the flash by a smart Card manufacturer

The Security IC with the

Flash memory and the

Flash Loader

The Operating System code, Flash memory initialization data and application data

The Security IC

Manufacturer:

- Develops, manufactures and delivers the Security

IC with Flash technology to the Composite Product

Integrator

The Smartcard Software developer:

- Develops the application;

- Delivers the application to the Composite Product

Integrator

The Card Manufacturer:

- is in charge of loading the application into the flash using Security IC flash loader;

- Delivers the Composite

TOE to be evaluated

Java Card

The composite TOE is built of

- a Java Card Platform

- a Java card application: the applet

The JavaCard Platform including Card Manager with Applet loader facility

The Applet

The Java Card Platform developer:

- Develops the Java Card with applet loading mechanism to the

Composite Product

Integrator.

The Applet developer:

- Develops the applet;

- Delivers the applet to the

Composite Product

Integrator

The Card Issuer:

- Loads the applet on the

Java Card platform using applet loading mechanism;

- Delivers the Composite

TOE to be evaluated

Table 3 - Example of composite TOE use cases

April 2012 Version 1.2 Page 19/73

CCDB-2012-04-001

5 ETR for composite evaluation

Composite product evaluation for Smart Cards and similar devices

5.1 Objective of the document

54

A standard Evaluation Technical Report (ETR) contains proprietary information that cannot be made public. The ETR for composite evaluation (ETR_COMP) document is compiled from the ETR in order to provide sufficient information for composite product evaluation with a certified platform. It should enable the Composite Product

Evaluator and the respective Certification Body to understand the considered attack paths, the performed tests and the effectiveness of countermeasures implemented by the platform.

55

A template for an ETR_COMP document is given in Appendix 2: ETR for composite evaluation template.

[R17] The ETR for composite evaluation should be produced by the Platform

Evaluator based on the platform evaluation results. This task should be considered when determining the evaluation work program to reduce additional cost and effort.

[R18] The content of ETR_COMP has to strike the right balance between protecting platform developer’s and/or Platform Evaluator’s proprietary information and providing sufficient information for the Composite Product Evaluator and the respective Certification Body, cf. Table 2 above.

[R19] ETR_COMP shall not include information affecting national security.

[R20] The information provided must be approved by all parties involved in the platform evaluation (i.e. the Evaluator, the Certification Body, the developer and sponsor of the evaluation). The platform Certification Body shall validate its consistency with the original ETR. The platform certification report shall reference the ETR for composite evaluation.

[R21] If the current ETR_COMP itself relies on a composite evaluation, and if there is direct interface with the previous platform, the reference to this previous composite evaluation ETR_COMP must be supplied.

5.3 Content of the ETR for composite evaluation

[R22] The information required is focused on: a) Formal information about the platform like its exact identification, reference to the certification report etc. b) Information about the Platform design. c) Information about the evaluated configuration of the Platform. d) Information on delivery procedures and data exchange.

April 2012 Version 1.2 Page 20/73

CCDB-2012-04-001 Composite product evaluation for Smart Cards and similar devices e) Information about penetration testing of the Platform including the considered attack paths and summary of test results. f) Observations and recommendations for users.

5.3.1 Formal information

[R23] This section of ETR_COMP shall provide formal information on the platform evaluation as:

 product identification,

 sponsor and developer identities,

 identities of the evaluation facility and the certification body,

 assurance level of the evaluation,

 formal evaluation and certification results like pass/fail,

 references to the ETR.

[R24] This section of ETR_COMP shall provide a high-level description of the IT product and its major components based on the deliverables required by the assurance class ADV of the Common Criteria. The intent of this section is to characterize the degree of architectural separation of the major components and to show possible technical dependencies between the platform and an application using the platform (e.g. dependencies between HW platform and

SW application).

[R25] This section of ETR_COMP shall provide information about the evaluated configuration of the Platform based on the developer’s configuration list or relevant parts as needed or on a case by case basis. The platform must unambiguously be identifiable and this identification shall be commensurate with the evaluated configuration as stated in the platform certification report.

[R26] If applicable, generation and installation parameter settings being security relevant for the Platform should be explained and their effect on the defence against attacks be outlined (e.g. key length, counters limits).

[R27] Evidence about the evaluation of the configuration management coverage (CC

V2.x: ACM_CAP; CC V3 ALC_CMC) can be necessary for a specific type of

Platform, if it is relevant for supporting composite evaluations (e.g. evidence about integration of a SW-application in the configuration management of a combined HW/SW-production). Therefore, beside the evaluation evidence about the principle capability of the configuration management system, specific composite configuration evidence may be necessary.

April 2012 Version 1.2 Page 21/73

CCDB-2012-04-001 Composite product evaluation for Smart Cards and similar devices

More precisely, as a platform may have several evaluated configurations, one dedicated configuration list for composition shall be delivered to the

Composite Product Evaluator. With this document the evaluator should be able to make the link between the evaluated platform configuration items and the composite product configuration.

An example of hardware platform and embedded OS configuration list document is shown in the table below:

Hardware platform evaluated configurations list document

Identification of the TOE:

Identification of the configuration for the ROM:

Identification of the configuration for the EEPROM:

Configuration options:

Identification of Mask Set:

Layout file:

Embedded IC software identification:

Configuration list of the composite product

(Additional information to be supplied for composite evaluation)

Identification of the composite TOE:

Identification of the configuration for the ROM:

Identification of the configuration for the EEPROM:

Configuration options:

Additional information if any

Tabel 4 - Configuration list example for hardware Platform

5.3.4 Delivery procedures and data exchange

[R28] For supporting composite evaluation, evaluation evidence can be necessary for delivery of the platform, and acceptance procedures of the application and related data to be integrated during development and production. Therefore, evaluation evidence about ADO_IGS (CC V2.x) resp. AGD_PRE

6

(CC V3) and ADO_DEL (CC V2.x) resp. ALC_DEL + AGD_PRE

7

(CC V3) might be relevant.

[R29] This section of ETR_COMP shall provide information about the independent vulnerability analysis performed by the Platform Evaluator with the attack scenarios having been considered, the penetration testing having been performed and the reference to the corresponding rating (quotation) of the attack potential.

[R30] Information about penetration testing should include details necessary for understanding the attack scenarios/paths and the assessment of penetration results.

6

[1.2C]

7

[1.1C]

April 2012 Version 1.2 Page 22/73

CCDB-2012-04-001 Composite product evaluation for Smart Cards and similar devices

[R31] The attack scenario descriptions should provide sufficient details to reproduce attacks, which require additional countermeasures in the composite TOE.

[R32] In accordance with the requirements of CEM

8

, this information is available within the ETR. So it can be compiled for ETR_COMP.

[R33] This section shall also mention the rating of access to ‘open samples’, if they exist (public/restricted/sensitive/critical).The use of ‘open samples’ shall be considered in the assessment of the attack path. Please note that ‘open samples’ are evaluation tools, but do not represent a TOE.

5.3.6 Observations and recommendations

[R34] The evaluated user guidance documentation shall contain all information required to use the TOE in a secure way as defined in the platform security target including recommendations on how to avoid residual vulnerabilities and unexpected behaviour.

[R35] However, in specific cases detailed information might be required in addition to the guidance documents such as:

 Observations on the evaluation results (e.g. specific TOE configuration for the evaluation),

 Recommendations/stipulations for the Composite Product Evaluator: specific information on use of the evaluation results (e.g. about specific testing necessary during a composition evaluation).

Any such observation or recommendation/stipulation may come from both the

Platform Evaluator or the Platform Certification Body.

8

Evaluation Methodology; depends on the version of CC chosen

April 2012 Version 1.2 Page 23/73

CCDB-2012-04-001 Composite product evaluation for Smart Cards and similar devices

validity

[R36] Results of a composite evaluation shall be provided to the Composite Product

Certification Body in form of an Evaluation Technical Report for the composite product. This Composite Product ETR shall contain, amongst others, the final overall verdict for the composite evaluation based on the partial verdicts for each assurance component being in scope of the current composite evaluation. There shall be a reference to this CC supporting document in the Composite Product ETR and the Composite Product

Certification Report.

[R37] As the composite product certificate covers also the platform, the composite product certificate validity is linked to the validity of the platform certificate.

[R38] The Composite Product Certification Body needs an up-to-date certificate or an assessment from the Platform Certification Body on the status of the platform certificate in question.

[R39] As a general rule the Composite Product Certification Body will ask for a reassessment of the platform if the date of the platform’s ETR for Composition is more than one and a half year before the submission of the report containing the full results of the composition penetration tests. This reassessment consists of either a re-evaluation of the platform focussing on a renewal of the vulnerability analysis (surveillance task) or alternatively, a confirmation statement of the Platform Certification Body may be requested.

[R40] Note that in the case the entire composite product is set up as a chain of composite products constructed on top of each other (e.g. the platform itself is already a composite product) the maximum validity period of 18 months is related to the eldest ETR for Composition used in this chain of composite products. In addition, dependencies from a lower level ETR for Composition to a higher level ETR for Composition need to be considered when reusing the results in the composite evaluation on top.

[R41] Note also that if the platform’s ETR for Composition was issued less than a year and a half ago before submission of the related composite evaluation tasks, but there was a major change in the state of the art in performing relevant attacks on the platform (e.g. a major change in the “Application of

Attack Potential to Smart Cards” document [JIL AP] or a major change in attack methods or attack ratings) then the Composite Product Certification

Body has the right to require a reassessment focusing on the new attack method.

[R42] Validity and relevance of the platform certificate for the current composite product certification shall be acknowledged by the Composite Product

Certification Body and includes the determination of equivalence of single assurance components (and, hence, of assurance levels) belonging to different

CC versions, if the platform certification was according to another CC version

April 2012 Version 1.2 Page 24/73

CCDB-2012-04-001 Composite product evaluation for Smart Cards and similar devices than the current composite certification is. Such equivalence shall be established / acknowledged by the Composite Product Certification Body

(see section 6.1).

[R43] The Composite Product Certification Body can issue a security certificate for the composite product, if

 the verdicts for the Composite Product ETR is PASS and

 validity and topicality of the platform certificate for the current composite product is acknowledged by the Composite Product

Certification Body.

[R44] Note that, if the Composite Product Evaluator detects some failures resulting from Platform ‘Open Samples’ testing, the results are communicated to the

Composite Product Certification Body. The Composite Product

Certification Body shall then take appropriate steps together with the

Platform Certification Body.

6.1 Composite evaluation based on different versions of CC

[R45] Due to CCRA rules, any new evaluation shall be performed using CC version

3.1, but today, a number of certified PPs are only available in CC version 2.3.

Also a significant number of HW platforms are on the market that were only certified under CC version 2.3. Therefore, in accordance with discussions at the JIWG and CCDB level, the CBs allow to perform:

 evaluations under CC v3.1, with the security target conformant to PPs certified under CC version 2.3.

 a composite evaluation based on CCv3.1 using a platform that was certified under CC2.3.

[R46] The certification body allows this specific mixture of Common Criteria version based on the following rule:

 The assurance gained under a specific EAL is equivalent between version 2.3 and 3.1 of the CC.

[R47] Based on this rule it is also valid to state that vulnerability assurance family

AVA_VLA.3 is equivalent to AVA_VAN.4 and AVA_VLA.4 is equivalent to

AVA_VAN.5.

[R48] As a consequence there are no issues for composite evaluation except for the following augmentation:

ADV_IMP:

[R49] The PPs in CC v2.3 generally have the augmentation IMP.2, meaning that the security target in CC v3.1 should claim this augmentation to remain conformant to the PP. Considering that:

April 2012 Version 1.2 Page 25/73

CCDB-2012-04-001 Composite product evaluation for Smart Cards and similar devices

 IMP.2 in CC v3.1 has a dependency on ALC_CMC.5 which means more work than before; and

 the CC v3.1 Eurosmart PP (PP0035) does not claim the augmentation

IMP.2, meaning that the composite product cannot claim this augmentation if the underlying IC is certified with CC v3.1.

[R50] The CBs will:

 consider the package EAL4 + DVS.2, IMP.2, VLA.4 in CC v2.3 equivalent to EAL4+ DVS.2, VAN.5 in CC v3.1.

 accept a security target in CC v3.1 with only IMP.1, but claiming a conformity to the PP v2.3 (i.e. despite the lack of IMP.2).

April 2012 Version 1.2 Page 26/73

CCDB-2012-04-001

7 References

Composite product evaluation for Smart Cards and similar devices

[CC23] CCMB-2005-08-001 : Part 1: Introduction and General Model,

Version 2.3

CCMB-2005-08-002 : Part 2: Security Functional Requirements,

Version 2.3

CCMB-2005-08-003 : Part 3: Security Assurance Requirements,

Version 2.3

[CEM23] CCMB-2005-08-004 : Evaluation Methodology, Version 2.3

7.2 CC V3 documents

[CC3] CCMB-2009-07-001 : Part 1 Introduction and general model,

Version 3.1, Revision 3

CCMB-2009-07-002 : Part 2 Security Functional components,

Version 3.1, Revision 3

CCMB-2009-07-003 : Part 3 Security Assurance Components,

Version 3.1, Revision 3

[CEM3] CCMB-2009-07-004 : Evaluation Methodology, Version 3.1, Revision 1

[JIL AP] Joint Interpretation Library Application of Attack Potential to Smart

Cards V2.7 February 2009

[CC AC] CCIMB-2004-02-009 Assurance continuity: CCRA requirements

April 2012 Version 1.2 Page 27/73

CCDB-2012-04-001

Appendix 1

Composite product evaluation for Smart Cards and similar devices

Appendix 1: Composite-specific requirements

In the following, the Composite-specific developer and evaluator action elements as well as the evaluator actions (work units) belonging to the composition activities (cf. chapter 4 above) are defined. They require the evidences as listed in section 4.7.

These refinements to the assurance requirements aim to give the Composite Product

Developer and Evaluator a precise guidance on which relevant aspects have to be described and assessed in the context of a composite evaluation and the tasks to be performed.

It allows the Composite Product Certification Body to check using the composite product

ETR that the required (mandatory) tasks have properly been performed.

All composite-specific evaluator actions have to be documented according to the scheme rules and finalised by one of the verdicts PASS, FAIL or INCONCLUSIVE. As these actions are refinements of the traditional actions focused on the composition activities, these verdicts have to be integrated to the overall verdict.

This approach can be applied independent of the aimed evaluation assurance level (EAL) for the composite product. Where some evaluation activities are not applicable due to the EAL chosen, the related composite-specific tasks are also not expected to be applied.

The composite evaluation methodology described by the current document is in principle independent of the CC version (V2.x or V3). However, due to differences in the content details of the related assurance classes and for the sake of a simpler applicability, the composite-specific tasks are defined twice:

– Composite-specific tasks for a composite evaluation in CC V2.x in Appendix 1.1, and

– Composite-specific tasks for a composite evaluation in CC V3 in Appendix 1.2.

So, if the CC version chosen for the composite evaluation is e.g. V2.3, the user of the current document shall directly address the description in Appendix 1.1; if the CC version chosen for the composite evaluation is e.g. V3, the user of the current document shall directly address the description in Appendix 1.2.

For convenience of composite-specific activities and associated work units identification, each refinement is named as *_COMP, where * is the name of the assurance class it is related to.

April 2012 Version 1.2 Page 28/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

Composite product evaluation for Smart Cards and similar devices

Appendix 1.1: Composite-specific tasks for a composite evaluation in CC V2.x

1. Consistency of composite product Security Target (ASE_COMP)

The composite-specific work units defined in this chapter are intended to be integrated as refinements to the evaluation activities of the ASE class listed in the following table. The other activities of ASE class do not require composite-specific work units.

Assurance family Evaluation activity

Evaluation work unit

Composite-specific work unit

ASE_ENV ASE_ENV.1.2E ASE_COMP.1-6

ASE_ENV.1-4

ASE_ENV.1-4

ASE_ENV.1-4

ASE_COMP.1-7

ASE_COMP.1-8

ASE_COMP.1-9

ASE_OBJ

ASE_REQ

ASE_TSS

ASE_OBJ.1.2E

ASE_OBJ.1.3C

ASE_REQ.1.4C

ASE_REQ.1.2E

ASE_TSS.1.6C

ASE_ENV.1-4

ASE_OBJ.1-7

ASE_OBJ.1-3

ASE_REQ.1-8

ASE_REQ.1-24

ASE_REQ.1-24

ASE_TSS.1-7

ASE_TSS.1-7

ASE_COMP.1-5

ASE_COMP.1-10

ASE_COMP.1-3

ASE_COMP.1-4

ASE_COMP.1-11

ASE_COMP.1-1

ASE_COMP.1-2

ASE_COMP.1

Objectives

Consistency of Security Target

1

2

The aim of this activity is to determine whether the Security Target of the composite product

9

does not contradict the Security Target of the underlying platform

10

.

Application notes

These application notes aid the developer to create as well as the evaluator to analyze a composite Security Target and describe a general methodology for it. For detailed information / guidance please refer to the single work units below.

3

In order to create a composite Security Target the developer should perform the following steps:

4

Step 1: The developer formulates a preliminary Security Target for the composite product (Composite-ST) using the standard code of practice.

9

denoted by Composite-ST in the following

10

denoted by Platform-ST in the following. Generally, a Security Target expresses a security policy for the TOE defined.

April 2012 Version 1.2 Page 29/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

Composite product evaluation for Smart Cards and similar devices

The Composite-ST can be formulated independently of the Security

Target of the underlying platform (Platform-ST) – at least as long as there are no formal PP conformance claims.

5

Step 2: The developer determines the intersection of the Composite-ST and the Platform-ST analysing and comparing their TSF

11

:

6

7

8

9

Composite-SP

Platform-SP

Step 3: The developer determines under which conditions he can trust in and rely on the Platform-TSF being used by the Composite-ST without a new examination.

Having undertaken these steps the developer completes the preliminary

Security Target for the composite product.

It is not mandatory that the platform is and the composite TOE is being certified according to same version of the CC. It is due to the fact that the application can rely on some security services of the platform, if (i) the assurance level of the platform covers the intended assurance level of the composite TOE and (ii) the platform’s security certificate is valid and upto-date. Equivalence of single assurance components (and, hence, of assurance levels) belonging to different CC versions shall be established

/ acknowledged by the Composite Product Certification Body, cf. chapter

6.

If a PP conformance is claimed (e.g. composite ST claim conformance to a PP that claims conformance to a hardware PP), the consistency check can be reduced to the elements of the Security Targets having not already been covered by these Protection Profiles.

The fact of compliance to a PP is not sufficient to avoid inconsistencies.

Assume the following situation, where  stands for “complies with”

Composite-ST  SW PP  HW PP  Platform-ST

The SW PP may require any kind of conformance

12

, but this does not change the ‘additional elements’ that the Platform-ST may introduce to the HW PP. In conclusion, these additions are not necessarily consistent with the composite-ST/SW PP additions: There is no scenario that ensures the consistency ‘by construction’.

Note that consistency may not be direct matching: e.g. objectives for the platform environment may become objectives for the composite TOE.

11

Because TSF enforce the Security Target (together with the TOE assurance measures). Please note that TSF means ‘TOE Security Functions’ in CC V2.x

12

e.g. “exact”, “strict” or “demonstrable” according to CC V2.4; there can only be “strict” for CC V2.1 to V2.3.

April 2012 Version 1.2 Page 30/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

Dependencies:

10

No dependencies.

Composite product evaluation for Smart Cards and similar devices

Developer action elements:

ASE_COMP.1.1D

11

The developer shall provide a statement of compatibility between the

Composite Security Target and the Platform Security Target. This statement can be provided within the Composite Product Security Target.

Content and presentation of evidence elements:

ASE_COMP.1.1C

12

The statement of compatibility shall describe the separation of the

Platform-TSF into relevant Platform-TSF being used by the Composite-

ST and others.

ASE_COMP.1.2C

13

The statement of compatibility between the Composite Security Target and the Platform Security Target shall show (e.g. in form of a mapping) that the Security Targets of the composite product and of the underlying platform match, i.e. that there is no conflict between security environments, security objectives, and security requirements of the

Composite Security Target and the Platform Security Target. It can be provided by indicating of the concerned elements directly in the Security

Target for the composite product followed by explanatory text, if necessary.

Evaluator action elements:

ASE_COMP.1.1E

14

The evaluator shall confirm that information provided meets all requirements for content and presentation of evidence.

Evaluator actions:

Action ASE_COMP.1.1E

ASE_COMP.1.1C

ASE_COMP.1-1

The evaluator shall check that the statement of compatibility describes the separation of the Platform-TSF into relevant Platform-TSF being used by the Composite-ST and others.

15

16

This work unit relates to the Step 2 of the Application Notes above. In order to determine the intersection area the evaluator considers the list of the Platform-TSF (given in the ST of the underlying platform) as its security services. To give an example, let us assume that there are the following Platform-TSF: Cryptographic functions RSA, AES, TDES,

TRNG as well as tamper-resistance.

These Platform-TSF shall be separated in two groups:

IP_SF: Irrelevant Platform-TSF not being used by the Composite-ST, and

RP_SF: Relevant Platform-TSF being used by the Composite-ST.

April 2012 Version 1.2 Page 31/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

17

Composite product evaluation for Smart Cards and similar devices

The second group RP_SF exactly represents the intersection area in question. For example, IP_SF = {AES} and RP_SF = {RSA, TDES,

TRNG, tamper-resistance}, i.e. AES is not used by the composite TOE, but all other Platform-TSF are used.

18

The amount of the intersection area (i.e. the content of the group RP_SF) results from the concrete properties of the Platform-ST and the

Composite-ST. If the Composite-ST does not use any property of the

Platform-ST and, hence, the intersection area is an empty set (RP_SF =

{

}), no further composite evaluation activities are necessary at all: In such a case there is a technical, but not a security composition.

19

ASE_COMP.1-2

The result of this work unit shall be integrated to the result of

ASE_TSS.1.6C/ ASE_TSS.1-7.

The evaluator shall examine the statement of compatibility to determine that the list of the Platform-TSF being used by the Composite-ST is complete and consistent for the current composite TOE.

20

21

22

In order to determine the completeness of the list of the Platform-TSF being used by the Composite-ST, the evaluator shall verify that:

– Platform-TSF = IP_SF

 RP_SF

– Elements that belong to RP_SF actually reflect the composite TOE

In order to determine the consistency of the list of the Platform-TSF being used by the Composite-ST, the evaluator shall verify that there are no ambiguities and contradictory statements.

More details on the consistency analysis can be found in common CC documents.

23

The result of this work unit shall be integrated to the result of

ASE_TSS.1.6C/ ASE_TSS.1-7.

ASE_COMP.1.2C

ASE_COMP.1-3

The evaluator shall check that the assurance requirements of the composite evaluation represent a subset of the assurance requirements of the underlying platform

13

.

24

This work unit relates to the Step 2 of the Application Notes above. In order to ensure a sufficient degree of trustworthiness of the Platform-TSF the evaluator compares the TOE assurance requirements

14

of the composite evaluation with those of the underlying platform. The evaluator decides that the degree of trustworthiness of the Platform-TSF

13

Please note that assurance measures can be derived from assurance requirements in a direct way, e.g. as a one to one assignment.

14

denoted by SAR in the following

April 2012 Version 1.2 Page 32/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

Composite product evaluation for Smart Cards and similar devices is sufficient, if the Composite-SAR represent a subset of the Platform-

SAR:

Platform-SAR

 Composite-SAR, e.g. the EAL chosen for the composite evaluation does not exceed the

EAL applied to the evaluation of the platform.

25

ASE_COMP.1-4

The result of this work unit shall be integrated to the result of

ASE_REQ.1.4C/ ASE_REQ.1-8.

The evaluator shall examine the statement of compatibility to determine that all performed operations on the relevant TOE security functional requirements of the platform are appropriate for the Composite-ST.

26

27

This work unit relates to Step 3 of the Application Notes above. The

relevant TOE security functional requirements

15

of the platform are the functional requirements being enforced by the Platform-TSF of the group

RP_SF (cf. the work unit ASE_COMP.1-1), or, shortly, being mapped

(in the rationale of the Platform-ST) to the TSF belonging to the group

RP_SF.

In order to perform this work unit the evaluator compares single parameters the relevant TOE security functional requirements of the platform with those of the composite evaluation. For example, the evaluator compares the properties of the component FCS_COP.1/RSA and determines that the Composite-ST requires a key length of 2048 bit and the Platform-ST enforces the RSA-function with a key length of

1024 and 2048 bit, i.e. this parameter of the platform is appropriate for the Composite-ST. Note, that the Composite-TSFR need not necessarily be the same as the Platform-TSFR, e.g. a trusted channel (FTP_ITC.1) in the composite product can be built using an RSA implementation

(FCS_COP.1/RSA) of the platform.

28

ASE_COMP.1-5

29

The result of this work unit shall be integrated to the result of

ASE_REQ.1.2E/ ASE_REQ.1-24.

The evaluator shall examine the statement of compatibility to determine that the relevant TOE security objectives of the Platform-ST are not contradictory to those of the Composite-ST.

This work unit relates to Step 3 of the Application Notes above. The

relevant TOE security objectives of the Platform-ST are those that are mapped to the relevant TOE security functional requirements of the

Platform-ST (cf. the work unit ASE_COMP.1-4).

15

TSFR

April 2012 Version 1.2 Page 33/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

30

Composite product evaluation for Smart Cards and similar devices

In order to perform this work unit the evaluator compares the relevant

TOE security objectives of the Platform-ST with those of the Composite-

ST and determines whether they are not contradictory.

31

ASE_COMP.1-6

32

The result of this work unit shall be integrated to the result of

ASE_OBJ.1.2E/ ASE_OBJ.1-7.

The evaluator shall examine the statement of compatibility to determine that the relevant threats of the Platform-ST are not contradictory to those of the Composite-ST.

This work unit relates to Step 3 of the Application Notes above. The evaluator compares the relevant threats (i.e. being mapped to the relevant

TOE security objectives, cf. the work unit ASE_COMP.1-5) of the

Platform-ST with those of the Composite-ST and determines whether they are not contradictory. The evaluator can decide on noncontradiction, if the threats of the Composite-ST referring to the platform-part of the composite product are covered by the threats of the

Platform-ST. For example, there may be a threat T.Physical_Attack of the Composite-ST covered by the threat T.Tamper of the Platform-ST.

33

ASE_COMP.1-7

34

35

36

ASE_COMP.1-8

The result of this work unit shall be integrated to the result of

ASE_ENV.1.2E/ ASE_ENV.1-4.

The evaluator shall examine the statement of compatibility to determine that the relevant organisational security policies of the Platform-ST are not contradictory to those of the Composite-ST.

This work unit relates to Step 3 of the Application Notes above. The evaluator compares the relevant organisational security policies (i.e. being mapped to the relevant TOE security objectives, cf. the work unit

ASE_COMP.1-5) of the Platform-ST with those of the Composite-ST and determines whether they are not contradictory.

Beyond it, a special organisational security policy OSP.Composite could be formulated within the Composite-ST, e.g. ‘The application is running on a certified platform and compatible with it’. Then the developer can define the special security objectives for the TOE and its environment exactly reflecting the conditions and restrictions of the certification report of the underlying platform.

The result of this work unit shall be integrated to the result of

ASE_ENV.1.2E/ ASE_ENV.1-4.

The evaluator shall examine the statement of compatibility to determine that the relevant organisational security policies of the Platform-ST are not contradictory to the threats of the Composite-ST and vice versa.

April 2012 Version 1.2 Page 34/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

37

Composite product evaluation for Smart Cards and similar devices

This work unit relates to Step 3 of the Application Notes above. The evaluator compares the relevant organisational security policies (i.e. being mapped to the relevant TOE security objectives, cf. the work unit

ASE_COMP.1-5) of the Platform-ST with the threats of the Composite-

ST and determines whether they are not contradictory.

38

An example for contradictive items: The organisational security policy of the Platform-ST “Cryptographic algorithms used shall be in accordance with international standards” is contradictory to the threat of the

Composite-ST “An attacker discloses the secrets being used by the TOE proprietary cryptographic algorithm”.

39

ASE_COMP.1-9

40

41

The result of this work unit shall be integrated to the result of

ASE_ENV.1.2E/ ASE_ENV.1-4.

The evaluator shall examine the statement of compatibility to determine that the list of the assumptions of the Platform-ST being significant for the Composite-ST is complete and consistent for the current composite

TOE.

This work unit relates to Step 3 of the Application Notes above. In order to determine which assumptions of the Platform-ST are significant for the Composite-ST the evaluator analyses the assumptions of the

Platform-ST and their separation in the following groups:

IrPA: The assumptions being not relevant for the Composite-ST, e.g. the assumptions about the developing and manufacturing phases of the platform.

CfPA: The assumptions being fulfilled by the Composite-ST

automatically. Such assumptions of the Platform-ST can always be assigned to the TOE security objectives of the Composite-ST. Due to this fact they will be fulfilled either by the Composite-TSF or by the

Composite-TAM automatically.

To give an example, let there be an assumption A.Resp-Appl of the Platform-ST: ‘

All User Data are owned by Smartcard Embedded Software. Therefore, it must be assumed that security relevant User Data (especially cryptographic keys) are treated by the

Smartcard Embedded Software as defined for the specific application context

’ and a TOE security objective OT.Key_Secrecy of the

Composite-ST: ‘

The secrecy of the signature private key used for signature generation is reasonably assured against attacks with a high attack potential.

If the private key is the only sensitive data element, then the assumption A.Resp-Appl is covered by the TOE security objective

OT.Key_Secrecy automatically.

SgPA: The remaining assumptions of the Platform-ST belonging neither to the group IrPA nor CfPA. Exactly this group makes up the

significant assumptions for the Composite-ST, which shall be included into the Composite-ST.

The result of this work unit shall be integrated to the result of

ASE_ENV.1.2E/ ASE_ENV.1-4.

April 2012 Version 1.2 Page 35/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

ASE_COMP.1-10

Composite product evaluation for Smart Cards and similar devices

The evaluator shall examine the statement of compatibility to determine that the significant security objectives for the operational environments of the Platform-ST are not contradictory to those of the Composite-ST.

42

43

44

45

This work unit relates to Step 3 of the Application Notes above. The

significant security objectives for the operational environment of the

Platform-ST are the security objectives for the operational environment being assigned to the assumptions classified as the group SgPA of the

Platform-ST (cf. the work unit ASE_COMP.1-9).

In order to accomplish this work unit the evaluator compares the

significant security objectives for the operational environment of the

Platform-ST with those of the Composite-ST and determines whether they are not contradictory. If necessary, the significant security objectives for the operational environment of the Platform-ST shall be included into the Composite-ST and assigned to the assumptions from the group SgPA, cf. the work unit ASE_COMP.1-9. The inclusion is not necessary, if the Composite-ST already contains equivalent (or similar) security objectives (covering all relevant aspects).

Since assurance of the development and manufacturing environment of the platform is confirmed by the platform certificate, the respective platform-objectives, if any, belong to the group IrPA.

Assurance of development and manufacturing environment is usually completely addressed by the assurance class ALC, and, hence, requires no explicit security objective.

46

ASE_COMP.1-11

47

The result of this work unit shall be integrated to the result of

ASE_OBJ.1.3C/ ASE_OBJ.1-3.

The evaluator shall examine the statement of compatibility to determine that the significant security functional requirements for the environment of the Platform-ST are not contradictory to those of the Composite-ST.

This work unit relates to Step 3 of the Application Notes above. The evaluator compares the significant security functional requirements for the environment of the Platform-ST (i.e. being mapped to the significant security objectives for the environment, cf. the work unit ASE_COMP.1-

10) with those of the Composite-ST and determines whether they are not contradictory. If necessary, the significant security functional requirements for the environment of the Platform-ST shall be included into the Composite-ST and assigned to the significant security objectives

(cf. the work unit ASE_COMP.1-9). The inclusion is not necessary, if the

Composite-ST already contains equivalent (or similar) security functional requirements (covering all relevant aspects). Note that non-IT requirements are optional.

April 2012 Version 1.2 Page 36/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

48

Composite product evaluation for Smart Cards and similar devices

The result of this work unit shall be integrated to the result of

ASE_REQ.1.2E/ ASE_REQ.1-24.

2. Integration of composition parts (ACM_COMP)

The composite-specific work units defined in this chapter are intended to be integrated as refinements to the evaluation activities of the ACM class listed in the following table. The other activities of ACM class do not require composite-specific work units.

CC Assurance family

Evaluation activity

Evaluation work unit

Composite-specific work unit

ACM_CAP ACM_CAP.2.5C ACM_CAP.2-6 ACM_COMP.1-1

NB: If the level of the assurance requirement chosen is higher than those identified in this table, the composite-specific work unit is also applicable.

ACM_COMP.1

Objectives

Integration of the application into the underlying platform

49

The aim of this activity is to determine whether the correct version of the application is installed onto/into the correct version of the underlying platform.

Dependencies:

50

No dependencies.

Developer action elements:

ACM_COMP.1.1D

51

The developer shall provide components identification evidence; cf. item

#7-(i) in Table 1, section 4.7.

Content and presentation of evidence elements:

ACM_COMP.1.1C

52

The components identification evidence shall show that the evaluated version of the application has been installed onto / embedded into the certified version of the underlying platform.

Evaluator action elements:

ACM_COMP.1.1E

53

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

Evaluator actions:

Action ACM_COMP.1.1E

ACM_COMP.1-1

The evaluator shall check the evidence that the evaluated version of the application has been installed onto / embedded into the correct, certified version of the underlying platform.

54

The general information of the CM capabilities is represented and has to be examined in the context of the assurance family ACM_CAP. The

April 2012 Version 1.2 Page 37/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

Composite product evaluation for Smart Cards and similar devices

special composite evaluator activity is to check the evidence of the version correctness for both parts of the composite product.

55

56

57

For the underlying platform, the evaluator shall determine that the actual identification of the platform is commensurate with the respective data in the platform certificate.

For the application, the relevant task is trivial due to the fact that the

Composite Product Evaluator has to perform this task in the context of the assurance family ACM_CAP.

Components identification evidence can be supplied in two different ways: technical and organisational. A technical evidence of version correctness is being generated by the composite product itself: the platform and the application return – in each case – strings containing unambiguous version numbers as answers to the respective commands.

E.g. it can be the return string of a command or the hard copy of the

Windows-Information (like ‘About’); in case of smart cards it can be an appropriate ATR.

58

59

60

61

62

A technical evidence of version correctness for hardware can also be supplied, if applicable, by reading off the unambiguous inscription on its surface. Note that there are no physical indication existing on most smart cards microcontrollers.

Technical evidence is recommended to be provided.

An organisational evidence of version correctness is being generated by the Composite Product Integrator on the basis of his configuration lists containing unambiguous version information of the platform and the application having been composed into the final composite product.

For example, in case of smart cards it can be an acknowledgement statement (e.g. configuration list) of the integrated circuit

16

manufacturer to the embedded software

17

manufacturer containing the evidence for the versions of the chip, the embedded software and its pre-personalisation parameters

18

.

Organisational evidence is always possible and, hence, shall be provided.

63

The result of this work unit shall be integrated to the result of

ACM_CAP.2.5C/ ACM_CAP.2-6 (or the equivalent higher components if a higher assurance level is selected).

16

-> underlying platform

17

-> application

18

Any data supplied by the embedded software manufacturer that is injected into the non-volatile memory by the integrated circuits manufacturer. These data are for instance used for traceability and/or to secure shipment between phases (cf. [Smartcard IC Platform Protection Profile, Version 1.0, July 2001, registration number

BSI-PP-0002], sec. 8.7).

April 2012 Version 1.2 Page 38/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

3.

Composite product evaluation for Smart Cards and similar devices

Consistency of delivery procedures (ADO_COMP)

The composite-specific work units defined in this chapter are intended to be integrated as refinements to the evaluation activities of the ADO class listed in the following table. The other activities of ADO class do not require composite-specific work units.

Assurance family Evaluation activity

Evaluation work unit

Composite-specific work units

ADO_IGS ADO_IGS.1.2E ADO_IGS.1-2 ADO_COMP.1-2

NB: If the level of the assurance requirement chosen is higher than those identified in this table, the composite-specific work unit is also applicable.

ADO_COMP.1

Objectives

Consistency check for delivery and acceptance procedures

64

The aim of this activity is to determine whether the delivery procedures of Platform and Application Developers are compatible with the acceptance procedure of the Composite Product Integrator.

Dependencies:

65

No dependencies.

Developer action elements:

ADO_COMP.1.1D

66

67

The developer shall provide an evidence for delivery and acceptance compatibility; cf. item #8 in Table 1, section 4.7.

ADO_COMP.1.2D

The developer shall provide a configuration parameters evidence; cf. item #7-(ii) in Table 1, section 4.7.

Content and presentation of evidence elements:

ADO_COMP.1.1C

68

The evidence for delivery and acceptance compatibility shall show that the delivery procedures of the Platform and Application Developers are compatible with the acceptance procedure of the Composite Product

Integrator.

ADO_COMP.1.2C

69

The configuration parameters evidence shall show that configuration parameters prescribed by the Platform and Application Developers are actually being used by the Composite Product Integrator.

Evaluator action elements:

ADO_COMP.1.1E

70

The evaluator shall confirm that the evidence for delivery compatibility is complete, coherent, and internally consistent.

April 2012 Version 1.2 Page 39/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

ADO_COMP.1.2E

71

Composite product evaluation for Smart Cards and similar devices

The evaluator shall confirm that the information provided meets all requirements for presentation of evidence.

Evaluator actions:

Action ADO_COMP.1.1E

ADO_COMP.1-1

The evaluator shall examine the evidence for compatibility of delivery interfaces to determine that delivery procedures of the Platform and

Application Developers are compatible with the acceptance procedure of the Composite Product Integrator.

72

73

The general information of the delivery procedures is represented and has to be examined in the context of the assurance family ADO_DEL.

The additional composite activity of the evaluator is to examine each delivery interface between the Platform Developer and the Composite

Product Integrator on the one side and between the Application

Developer and the Composite Product Integrator on the other side. As a result, the evaluator confirms or disproves the justification for delivery compatibility.

If there are no delivery interfaces between the Platform and Application

Developers and the Composite Product Integrator or the assurance package chosen does not contain the family ADO_DEL (e.g. EAL1), this work unit is not applicable.

74

The result of this work unit shall be integrated to the result of

ADO_DEL.1.1C/ ADO_DEL.1-1 (or the equivalent higher components if a higher assurance level is selected).

Action ADO_COMP.1.2E

ADO_COMP.1-2

The evaluator shall examine the evidence for using configuration parameters to determine that the Composite Product Integrator uses the configuration parameters prescribed by the Platform and Application

Developers.

75

76

77

The general information of the configuration parameters required is represented and has to be examined in the context of the assurance family

ADO_IGS. The special evaluator activity is to examine the developer’s evidence and to decide whether the Composite Product Integrator appropriately treats this special subset of the configuration parameters.

For example, for a Java Card as composite TOE, the Card Issuer has to set all parameters as prescribed by the Java Card Platform and the Applet

Developers while installing the applet onto the Java Card platform; cf.

Table 3, section 4.7.

The result of this work unit shall be integrated to the result of

ADO_IGS.1.2E/ ADO_IGS.1-2.

April 2012 Version 1.2 Page 40/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

4.

Composite product evaluation for Smart Cards and similar devices

Composite design compliance (ADV_COMP)

The composite-specific work units defined in this chapter are intended to be integrated as refinements to the evaluation activities of the ADV class listed in the following table. The other activities of ADV class do not require composite-specific work units.

CC Assurance family

Evaluation activity

Evaluation work unit

Composite specific work unit

ADV_IMP ADV_IMP.1.2E ADV_IMP.1−4 ADV_COMP.1-1

ADV_INT ADV_INT.1.2E ADV_INT.1-4 ADV_COMP.1-2

ADV_LLD ADV_LLD.1.2E ADV_LLD.1−11 ADV_COMP.1-1

NB: If the level of the assurance requirement chosen is higher than those identified in this table, the composite-specific work unit is also applicable.

ADV_COMP.1 Design compliance with the platform certification report, guidance and ETR_COMP

Objectives

78

The aim of this activity is to determine whether the requirements on the application, imposed by the underlying platform, are fulfilled in the composite product.

Application notes

79

The requirements on the application, imposed by the underlying platform, can be formulated in the relevant certification report (e.g. in form of constraints and recommendations), user guidance and

ETR_COMP (in form of observations and recommendations) for the platform. The developer of the composite product shall regard each of these sources, if available (cf. Table 2, section 4.7), and implement the composite product in such a way that the applicable requirements are fulfilled.

80

81

The TSF of the composite product are represented at various levels of abstraction in the families of the development class ADV. Experiential, the appropriate levels of design representation for examining, whether the requirements of the platform are fulfilled by the composite product, are the low-level design and the implementation. In case, these design representation levels are not available (e.g. due to the assurance package chosen), the high-level design can be used for providing the relevant information.

Due to the definition of the composite TOE (cf. section 2.1 ‘Definitions’) the interface between the underlying platform and the application is the

internal one, hence, a functional specification (ADV_FSP) as representation level is not appropriate for analysing the design compliance.

April 2012 Version 1.2 Page 41/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

82

Composite product evaluation for Smart Cards and similar devices

Since consistency of the composite product security policy has already been considered in the context of the Security Target in the assurance family ASE_COMP (see page 29 above), there is no necessity to consider non-contradictoriness of the security policy model (ADV_SPM) of the composite TOE and the security policy model of the underlying platform.

83

There is no affinity between the family correspondence demonstration

(ADV_RCR) and the examination of the design compliance.

Dependencies:

84

No dependencies.

Developer action elements:

ADV_COMP.1.1D

85

The developer shall provide a design compliance justification; cf. item #6 as well as items #3, #4, #5 in Table 1, section 4.7.

Content and presentation of evidence elements:

ADV_COMP.1.1C

86

The design compliance justification shall provide a rationale for design compliance – on an appropriate representation level – of how the requirements on the application, imposed by the underlying platform, are fulfilled in the composite product.

Evaluator action elements:

ADV_COMP.1.1E

87

The evaluator shall confirm that the rationale for design compliance is complete, coherent, and internally consistent.

Evaluator actions:

Action ADV_COMP.1.1E

ADV_COMP.1-1

The evaluator shall examine the rationale for design compliance to determine that all applicable requirements on the application, imposed by the underlying platform, are fulfilled by the composite product.

88

89

In order to perform this work unit the evaluator shall use the rationale for design compliance as well as the TSF representation on the ADV_LLD and ADV_IMP levels on the one side and the input of the platform developer in form of the certification report, guidance and ETR_COMP on the other side. The evaluator shall analyse which platform requirements are applicable for the current composite product. The evaluator shall compare each of the applicable requirements with the actual specification and/or implementation of the composite product and determine, for each requirement, whether it is fulfilled. As result, the evaluator confirms or disproves the rationale for design compliance.

For example, platform guidance may require the application to perform a special start-up sequence testing the current state of the platform and initialising its self-protection mechanisms. Such information might be

April 2012 Version 1.2 Page 42/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

Composite product evaluation for Smart Cards and similar devices found in the description of low-level design ADV_LLD and/or

ADO_IGS of the composite TOE.

90

The appropriate representation level (ADV_LLD and ADV_IMP), what the analysis is being performed on, can be chosen and mixed flexibly depending on the concrete composite TOE and the requirement in question. Where it is not self-explaining, the evaluator shall justify why the representation level chosen is appropriate. In case there is no information available on the representation levels ADV_LLD and

ADV_IMP due to the assurance package chosen (e.g. EAL2, EAL3), the high-level design ADV_HLD shall be used for providing the relevant information and performing the corresponding analysis.

91

92

93

ADV_COMP.1-2

The evaluator activities in the context of this work unit can be spread over different single evaluation aspects (e.g. over ADV_LLD and

ADV_IMP). In this case the evaluator performs the partial activity in the context of the corresponding single evaluation aspect. Then the notation for this work unit shall be ADV_COMP.1-1-HLD, ADV_COMP.1-1-

LLD and ADV_COMP.1-1-IMP, respectively.

If the assurance package chosen does not contain the families

ADV_HLD, ADV_LLD or ADV_IMP (e.g. EAL1), this work unit is not applicable (cf. Application Note above).

The result of this work unit shall be integrated to the result of

ADV_HLD.1.2E/ ADV_HLD.1-9

19

, ADV_LLD.1.2E/ ADV_LLD.1−11,

ADV_IMP.1.2E/ ADV_IMP.1−4 (or the equivalent higher components if a higher assurance level is selected).

The evaluator shall check the TSF internals of the composite TOE to determine that they do not contradict any design requirement imposed by the underlying platform.

94

95

The TSF internals are represented and evaluated in the context of the assurance family ADV_INT. The evaluator shall compare the internal structure of the TSF with the design requirements of the platform and search for obvious contradictions.

If there are no requirements of the platform concerning the TSF internal structure or the assurance package chosen does not contain the family

ADV_INT, this work unit is not applicable.

96

The result of this work unit shall be integrated to the result of

ADV_INT.1.2E/ ADV_INT.1-4 (or the equivalent higher components if a higher assurance level is selected).

19

ADV_HLD.3.2E might be not relevant for this activity due to the fact, that the evaluator should use

ADV_LLD, if available.

April 2012 Version 1.2 Page 43/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

5.

Composite product evaluation for Smart Cards and similar devices

Composite functional testing (ATE_COMP)

The composite-specific work units defined in this chapter are intended to be integrated as refinements to the evaluation activities of the ATE class listed in the following table. The other activities of ATE class do not require composite-specific work units.

CC Assurance family

Evaluation activity Evaluation work unit

Composite specific work unit

ATE_COMP.1-2

NB: If the level of the assurance requirement chosen is higher than those identified in this table, the composite-specific work unit is also applicable.

ATE_COMP.1

Objectives

Composite product functional testing

97

The aim of this activity is to determine whether composite product as a

whole exhibits the properties necessary to satisfy the functional requirements of its Security Target.

Application notes

98

99

100

A composite product can be tested separately and integrative. Separate testing means that the platform and the application are being tested independent of each other. A lot of tests of the platform may have been performed within the scope of its accomplished evaluation. The application may be tested on a simulator or an emulator, which represent a virtual machine.

Integration testing means that the composite product is being tested as it is: the application is running on the platform.

Some TSF can depend on properties of the underlying platform as well as of the application (e.g. correctness of the measures of the composite product to withstand a side channel attack or of the TSF implementing tamper resistance against physical attacks). In such a case the TSF shall be tested on the final composite product, but not on a simulator or an emulator.

This activity focuses exclusively on testing of the composite product as a

whole and represents merely partial efforts within the general test approach being covered by the assurance ATE. These integration tests shall be specified and performed, whereby the approach of the standard 20 assurance families of the class ATE shall be applied.

20

i.e. as required by CEM

April 2012 Version 1.2 Page 44/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

101

Composite product evaluation for Smart Cards and similar devices

- A correct behaviour of the Platform-TSF being relevant for the

Composite-ST (the group RP_SF in the work unit ASE_COMP.1-1 above), and

- absence of exploitable vulnerabilities (sufficient effectiveness) in the context of the Platform-ST are confirmed by the valid Platform

Certificate, cf. chapter 6 above.

Dependencies:

102

No dependencies.

Developer action elements:

ATE_COMP.1.1D

103

104

The developer shall provide a set of tests as required by the assurance package chosen.

ATE_COMP.1.2D

The developer shall provide the composite TOE for testing.

Content and presentation of evidence elements:

ATE_COMP.1.1C

105

Content and presentation of the specification and documentation of the

integration tests shall correspond to the standard

21

requirements of the assurance families ATE_FUN and ATE_COV.

106

ATE_COMP.1.2C

The composite TOE provided shall be suitable for testing.

Evaluator action elements:

ATE_COMP.1.1E

107

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

ATE_COMP.1.2E

108

The evaluator shall specify, perform and document a set of own

integration tests to confirm that the composite TOE operates as specified.

Evaluator actions:

Action ATE_COMP.1.1E

ATE_COMP.1-1

The evaluator shall examine that the developer performed the

integration tests for all TSF having to be tested on the composite product as a whole.

109

In order to perform this work unit the evaluator shall analyse, for each

TSF, whether it directly depends on security properties of the platform and of the application. Then the evaluator shall verify that the integration tests performed by the developer cover at least all such TSF.

110

If the assurance package chosen does not contain the families ATE_FUN and ATE_COV (e.g. EAL1), this work unit is not applicable.

21

i.e. as defined by CEM

April 2012 Version 1.2 Page 45/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

111

Composite product evaluation for Smart Cards and similar devices

The result of this work unit shall be integrated to the result of

ATE_COV.1.1C/ ATE_COV.1-1 and ATE_FUN.1.3C/ ATE_FUN.1−6

(or the equivalent higher components if a higher assurance level is selected).

Action ATE_COMP.1.2E

ATE_COMP.1-2

The evaluator shall determine the minimal amount of the integration tests being necessary for the current composite evaluation.

112

The evaluator shall perform the following steps:

1) The evaluator determines the share of the platform part of the TOE in enforcing of the Composite-ST. In order to do this, the evaluator refers to the TOE design (ADV_HLD might possess an appropriate representation level for this purpose) as well as to the Composite-ST and lists all

Composite-SFRs using the security services of the platform

22

. Hereby the evaluator shall understand/document, for each such Composite-SFR, what concretely the platform does (so called platform’s share).

For example, there is a Composite-SFR FCS_CKM.1 fulfilled by the

TSF ‘Key Generation’. The share of the platform in implementing this

SFR is generating random numbers for key generation.

2) The evaluator checks, for each such Composite-SFR, whether the

platform’s share has been covered by the Platform Certificate; in order to do this the evaluator refers to the platform user guidance, ETR_COMP and the platform certification report.

For our example with the random number generator (RNG), the evaluator might find an advice in ETR_COMP that (i) the RNG is regularly being tested (online tests), (ii) its behaviour concerning power consumption analysis was evaluated and (iii) a sufficient (for generation of static keys) random numbers quality was confirmed by the Platform Certificate. In such a case the evaluator can decide that no integration tests are necessary for FCS_CKM.1/Key Generation

23

.

The next example represents a situation, where additional integration tests are necessary. There let be a Composite-SFR FPT_EMSEC.1

(electromagnetic emanation) fulfilled by the following TSF:

- ‘User Authentication’; the platform’s share in implementing this SFR is scrambling the reference authentication data stored in the TOE;

- ‘Key Generation’; the platform’s share in implementing this SFR is disguising information about the value of the key being generated while

22

Such security services of the platform are represented by the group RP_SF, cf. the work unit ASE_COMP.1-1 above

23

Of course, the evaluator might (and, perhaps, would) decide to test ‘Key Generation’-TSF as an integration test on the final TOE. A methodological reason for this test would then be rather a general check of the respective functionality, but not the confirmation of security behaviour of the platform-RNG.

April 2012 Version 1.2 Page 46/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

Composite product evaluation for Smart Cards and similar devices observing power consumption;

- ‘Signature Creation’; the platform’s share in implementing this SFR is disguising information about the value of the signature key being used while observing power consumption;

For scrambling, the evaluator might find the advice in ETR_COMP that the platform scrambling engine has been evaluated, but it must be correctly initialised by the application. Hence, the evaluator has to specify an integration test for initialising the scrambling engine.

For disguising during key generation, the evaluator might find no advices in ETR_COMP. Hence, the evaluator has to assume that this behaviour of the platform was not included in consideration. Therefore, the evaluator has to specify an integration test for power consumption while generating the signature keys.

For disguising during signature creation, the evaluator might find an advice in ETR_COMP that DPA and SPA on RSA have been evaluated, but no advice of Timing on RSA. Hence, the evaluator has to assume that the Timing-on-RSA behaviour of the platform was not included in consideration. Therefore, the evaluator has to specify an integration

Timing-on-RSA test for power consumption while using the signature key.

3) The evaluator refers to ETR_COMP and checks for any explicit requirements for performing tests in the context of the composite evaluation. Such explicit requirements might sound like ‘Such test has to be performed during the SW evaluation’.

All platform tests being necessary for the current composite evaluation, but not covered by the Platform Certificate, and all tests explicitly required by ETR_COMP, encompass the minimal amount of the integration tests being necessary for the current composite evaluation.

This work unit is the complementary part to the work unit

ASE_COMP.1-1: In ASE_COMP.1-1 the evaluator determines, on which part of the Platform-ST the Composite-ST can rely (the group RP_SF); in the current work unit the evaluator determines, whether the Composite-

ST can also rely on the platform’s functional behaviour being not covered by the Platform-ST.

113

The result of this work unit shall be integrated to the result of

ATE_COV.1.1C/ATE_COV.1-1 (or the equivalent higher components if a higher assurance level is selected).

ATE_COMP.1-3

The evaluator shall perform the standard evaluator actions in the context of the assurance family ATE_IND on the set of the integration tests using the composite product as a whole.

April 2012 Version 1.2 Page 47/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

114

Composite product evaluation for Smart Cards and similar devices

The set of the integration tests for this activity shall embrace at least the minimal amount of the integration tests as determined in the previous work unit.

115

The result of this work unit shall be integrated to the result of

ATE_IND.1.2E/ATE_IND.1−5 (or the equivalent higher components if a higher assurance level is selected).

6. Composite vulnerability assessment (AVA_COMP)

The composite-specific work units defined in this chapter are intended to be integrated as refinements to the evaluation activities of the AVA class listed in the following table. The other activities of AVA class do not require composite-specific work units.

CC Assurance family

Evaluation activity

Evaluation work unit

Composite-specific work unit

AVA_VLA AVA_VLA.1.2E AVA_VLA.1−4 AVA_COMP.1-1

NB: If the level of the assurance requirement chosen is higher than those identified in this table, the composite-specific work unit is also applicable.

AVA_COMP.1

Objectives

Composite product vulnerability assessment

116

117

The aim of this activity is to determine the exploitability of flaws or weaknesses in the composite TOE as a whole in the intended environment.

Application notes

This activity focuses exclusively on vulnerability assessment of the composite product as a whole and represents merely partial efforts within the general approach being covered by the standard

24

assurance families of the class AVA.

118

119

The results of the vulnerability assessment for the underlying platform represented in the ETR_COMP can be reused, if they are up to date and all composite activities for correctness – ASE_COMP.1, ACM_COMP.1,

ADO_COMP.1, ADV_COMP.1 and ATE_COMP.1 – are finalised with the verdict PASS.

Due to composing of the platform and the application a new quality arises, which can cause additional vulnerabilities of the platform which might be not mentioned in the ETR_COMP.

24

i.e. defined by CEM

April 2012 Version 1.2 Page 48/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

Dependencies:

120

No dependencies.

Composite product evaluation for Smart Cards and similar devices

Developer action elements:

AVA_COMP.1.1D

121

122

The developer shall provide the vulnerability assessment for the composite product, where aspects of interaction between the platform and the application are addressed.

AVA_COMP.1.2D

The developer shall provide the composite TOE for penetrating testing.

Content and presentation of evidence elements:

AVA_COMP.1.1C

123

Content and presentation of evidence elements shall correspond to the requirements of the assurance class AVA as defined by CEM. The focus of this Composite-special information lies on the aspects of interaction between the platform and the application.

124

AVA_COMP.1.2C

The composite TOE provided shall be suitable for testing as a whole.

Evaluator action elements:

AVA_COMP.1.1E

125

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The focus of this

Composite-special information lies on the aspects of interaction between the platform and the application.

AVA_COMP.1.2E

126

The evaluator shall conduct penetration testing of the composite product

as a whole building on the developer vulnerability analysis, to ensure that obvious and identified vulnerabilities have been addressed.

Evaluator actions:

Action AVA_COMP.1.1E

AVA_COMP.1-1

The evaluator shall examine the results of the vulnerability assessment for the underlying platform to determine that they can be reused for the composite evaluation.

127

The results of the vulnerability assessment for the underlying platform are usually represented in the ETR_COMP. They can be reused, if they are up to date and all composite activities for correctness –

ASE_COMP.1, ACM_COMP.1, ADO_COMP.1, ADV_COMP.1 and

ATE_COMP.1 – are finalised with the verdict PASS. The evaluator shall also consider the relevant determinations in the Platform Certification

Report. For validity of the platform security certificate please refer to chapter 6 above.

April 2012 Version 1.2 Page 49/73

CCDB-2012-04-001

Appendix 1.1: CC v2.x

128

Composite product evaluation for Smart Cards and similar devices

The result of this work unit shall be integrated to the result of

AVA_VLA.1.2E/AVA_VLA.1−4 (or the equivalent higher components if a higher assurance level is selected).

Action AVA_COMP.1.2E

AVA_COMP.1-2

The evaluator shall specify, conduct and document penetration testing of the composite product as a whole, using the standard approach of the assurance family AVA_VLA.

129

130

131

132

If the correctness activities – ASE_COMP.1, ACM_COMP.1,

ADO_COMP.1, ADV_COMP.1 and ATE_COMP.1 – are finalised with the verdict PASS and the certificate for the platform covers all security properties needed for the composite product, composing of the platform and the application must not create additional vulnerabilities of the platform.

If the evaluator determined that composing of the platform and the application creates additional vulnerabilities of the platform

25

, a contradiction to the verdict PASS for the correctness activities (see paragraph 118 above) has to be supposed or the certificate for the platform does not cover all security properties needed for the current composite product.

If the assurance package chosen does not contain the family AVA_VLA

(e.g. EAL1), this work unit is not applicable.

The result of this work unit shall be integrated to the result of

AVA_VLA.2.4E/ AVA_VLA.2-11, AVA_VLA.2.4E/ AVA_VLA.2-12 and AVA_VLA.2.4E/ AVA_VLA.2-13 (or the equivalent higher components if a higher assurance level is selected).

25

not mentioned in the ETR_COMP

April 2012 Version 1.2 Page 50/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

Composite product evaluation for Smart Cards and similar devices

Appendix 1.2: Composite-specific tasks for a composite evaluation in CC V3.1

1. Consistency of composite product Security Target (ASE_COMP)

The composite-specific work units defined in this chapter are intended to be integrated as refinements to the evaluation activities of the ASE class listed in the following table. The other activities of ASE class do not require composite-specific work units.

CC assurance family

Evaluation activity Evaluation work unit

Composite-specific work unit

ASE_OBJ

ASE_REQ

ASE_SPD

ASE_OBJ.2.1С ASE_OBJ.2-1 ASE_COMP.1-5

ASE_OBJ.2.1C ASE_OBJ.2-1 ASE_COMP.1-10

ASE_OBJ.2.3C ASE_OBJ.2-3 ASE_COMP.1-10

ASE_REQ.1.6C ASE_REQ.1-10 ASE_COMP.1-1

ASE_REQ.2.9C. ASE_REQ.2-13 ASE_COMP.1-1

ASE_REQ.1.6C ASE_REQ.1-10 ASE_COMP.1-2

ASE_REQ.2.9C. ASE_REQ.2-13 ASE_COMP.1-2

ASE_REQ.2.8C ASE_REQ.2-12 ASE_COMP.1-3

ASE_REQ.2.3C ASE_REQ.2-4 ASE_COMP.1-4

ASE_SPD.1.1C ASE_SPD.1-1 ASE_COMP.1-6

ASE_SPD.1.3C ASE_SPD.1-3 ASE_COMP.1-7

ASE_SPD.1.3C ASE_SPD.1-3 ASE_COMP.1-8

ASE_SPD.1.4C ASE_SPD.1-4 ASE_COMP.1-9

ASE_COMP.1

Objectives

Consistency of Security Target

1

2

The aim of this activity is to determine whether the Security Target of the composite product 26 does not contradict the Security Target of the underlying platform 27 .

Application notes

These application notes aid the developer to create as well as the evaluator to analyze a composite Security Target and describe a general methodology for it. For detailed information / guidance please refer to the single work units below.

3

In order to create a composite Security Target the developer should perform the following steps:

26

denoted by Composite-ST in the following

27

denoted by Platform-ST in the following. Generally, a Security Target expresses a security policy for the TOE defined.

April 2012 Version 1.2 Page 51/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

4

Composite product evaluation for Smart Cards and similar devices

Step 1: The developer formulates a preliminary Security Target for the composite product (the Composite-ST) using the standard code of practice. The Composite-ST can be formulated independently of the

Security Target of the underlying platform (Platform-ST) – at least as long as there are no formal PP conformance claims.

5

Step 2: The developer determines the intersection of the Composite-ST and the Platform-ST analysing and comparing their TOE Security

Functionality (TSF)

2829

:

Composite-SP

Platform-SP

6

7

Step 3: The developer determines under which conditions he can trust in and rely on the Platform-TSF being used by the Composite-ST without a new examination.

Having undertaken these steps the developer completes the preliminary

Security Target for the composite product.

8

It is not mandatory that the platform is and the composite TOE is being certified according to same version of the CC. It is due to the fact that the application can rely on some security services of the platform, if (i) the assurance level of the platform covers the intended assurance level of the composite TOE and (ii) the platform’s security certificate is valid and upto-date. Equivalence of single assurance components (and, hence, of assurance levels) belonging to different CC versions shall be established

/ acknowledged by the Composite Product Certification Body, cf. chapter

6.

9

If a PP conformance is claimed (e.g. composite ST claim conformance to a PP that claims conformance to a hardware PP), the consistency check can be reduced to the elements of the Security Target having not already been covered by these Protection Profiles.

The fact of compliance to a PP is not sufficient to avoid inconsistencies.

Assume the following situation, where  stands for “complies with”

Composite-ST  SW PP  HW PP  platform-ST

The SW PP may require any kind of conformance

30

, but this does not change the ‘additional elements’ that the platform-ST may introduce to the HW PP. In conclusion, these additions are not necessarily consistent

28

because the TSF enforce the Security Target (together with organisational measures enforcing security objectives for the operational environment of the TOE).

29

The comparison shall be performed on the abstraction level of SFRs. If the developer defined security functionality groups (TSF-groups) in the TSS part of his Security Target, the evaluator should also consider them in order to get a better understanding for the context of the security services offered by the TOE.

30

e.g. “strict” or “demonstrable” according to CC V3.

April 2012 Version 1.2 Page 52/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

Composite product evaluation for Smart Cards and similar devices with the composite-ST/SW PP additions: There is no scenario that ensures the consistency ‘by construction’.

Note that consistency may not be direct matching: e.g. objectives for the platform environment may become objectives for the composite TOE.

Dependencies:

10

No dependencies.

Developer action elements:

ASE_COMP.1.1D

11

The developer shall provide a statement of compatibility between the

Composite Security Target and the Platform Security Target. This statement can be provided within the Composite Product Security Target.

Content and presentation of evidence elements:

ASE_COMP.1.1C

12

13

The statement of compatibility shall describe the separation of the

Platform-TSF into relevant Platform-TSF being used by the Composite-

ST and others.

ASE_COMP.1.2C

The statement of compatibility between the Composite Security Target and the Platform Security Target shall show (e.g. in form of a mapping) that the Security Targets of the composite product and of the underlying platform match, i.e. that there is no conflict between security environments, security objectives, and security requirements of the

Composite Security Target and the Platform Security Target. It can be provided by indicating of the concerned elements directly in the Security

Target for the composite product followed by explanatory text, if necessary.

Evaluator action elements:

ASE_COMP.1.1E

14

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

Evaluator actions:

Action ASE_COMP.1.1E

ASE_COMP.1.1C

ASE_COMP.1-1

The evaluator shall check that the statement of compatibility describes the separation of the Platform-TSF into relevant Platform-TSF being used by the Composite-ST and others.

15

Please note that TSF means ‘TOE Security Functionality’ in CC V3, whereby the TSF content is represented by SFRs

31

. The respective TOE summary specification (TSS) shall provide, for each SFR, a description on how each SFR is met

32

. The evaluator shall use this description in order to understand the contextual frame of the SFRs.

31

security functional requirements

32

cf. CC part 3, ASE_TSS.1.1C

April 2012 Version 1.2 Page 53/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

Composite product evaluation for Smart Cards and similar devices

If the developer defined security functionality groups (TSF-groups) in the TSS part of his Security Target as such contextual frame of the SFRs, the evaluator should also consider them in order to get a better understanding for the context of the security services offered by the

TOE.

16

This work unit relates to the Step 2 of the Application Notes above. In order to determine the intersection area the evaluator considers the list of the Platform-SFRs (given in the ST of the underlying platform) as single properties of the platform’s security services.

To give an example, let us assume that there are the following Platform-

SFRs: Cryptographic operations FCS_COP.1/RSA, FCS_COP.1/AES,

FCS_COP.1/EC, FCS_COP.1/RNG as well as tamper-resistance

FPT_PHP.3.

17

18

19

These Platform-SFRs shall be separated in two groups:

IP_SFR: Irrelevant Platform-SFRs not being used by the Composite-

ST, and

RP_SFR: Relevant Platform-SFRs being used by the Composite-ST.

The second group RP_SFR exactly represents the intersection area in question. For example, IP_SFR = {FCS_COP.1/AES} and RP_SFR =

{FCS_COP.1/RSA, FCS_COP.1/EC, FCS_COP.1/RNG, FPT_PHP.3}, i.e. AES is not used by the composite TOE, but all other Platform-SFRs are used.

The amount of the intersection area (i.e. the content of the group

RP_SFR) results from the concrete properties of the Platform-ST and the

Composite-ST. If the Composite-ST does not use any property of the

Platform-ST and, hence, the intersection area is an empty set (RP_SFR =

{

}), no further composite evaluation activities are necessary at all: In such a case there is a technical, but not a security composition.

20

ASE_COMP.1-2

21

22

The result of this work unit shall be integrated to the result of

ASE_REQ.1.6C/ ASE_REQ.1-10 (or the equivalent higher components if a higher assurance level is selected) and ASE_REQ.2.9C/

ASE_REQ.2-13.

The evaluator shall examine the statement of compatibility to determine that the Platform-TSF being used by the Composite-ST is complete and consistent for the current composite TOE.

In order to determine the completeness of the list of the Platform-TSF being used by the Composite-ST, the evaluator shall verify that:

– Platform-SFR = IP_SFR

 RP_SFR

– elements that belong to RP_SFR actually reflect the composite TOE

In order to determine the consistency of the list of the Platform-TSF being used by the Composite-ST, the evaluator shall verify that there are no ambiguities and contradictory statements.

April 2012 Version 1.2 Page 54/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

23

Composite product evaluation for Smart Cards and similar devices

More details on the consistency analysis can be found in common CC documents.

24

ASE_COMP.1-3

The result of this work unit shall be integrated to the result of

ASE_REQ.1.6C/ ASE_REQ.1-10 (or the equivalent higher components if a higher assurance level is selected) and ASE_REQ.2.9C/

ASE_REQ.2-13.

ASE_COMP.1.2C

The evaluator shall check that the security assurance requirements of the composite evaluation represent a subset of the security assurance requirements of the underlying platform.

25

26

ASE_COMP.1-4

27

28

This work unit relates to the Step 2 of the Application Notes above. In order to ensure a sufficient degree of trustworthiness of the Platform-TSF the evaluator compares the TOE security assurance requirements 33 of the composite evaluation with those of the underlying platform. The evaluator decides that the degree of trustworthiness of the Platform-TSF is sufficient, if the Composite-SAR represent a subset of the Platform-

SAR:

Platform-SAR

 Composite-SAR, e.g. the EAL chosen for the composite evaluation does not exceed the

EAL applied to the evaluation of the platform.

The result of this work unit shall be integrated to the result of

ASE_REQ.2.8C/ ASE_REQ.2-12.

The evaluator shall examine the statement of compatibility to determine that all performed operations on the relevant TOE security functional requirements of the platform are appropriate for the Composite-ST.

This work unit relates to Step 3 of the Application Notes above. The

relevant TOE security functional requirements of the platform are exactly the elements of the group RP_SFR (cf. the work unit

ASE_COMP.1-1).

In order to perform this work unit the evaluator compares single parameters of the relevant SFRs of the platform with those of the composite evaluation. For example, the evaluator compares the properties of the respective components FCS_COP.1/RSA and determines that the Composite-ST requires a key length of 2048 bit and the Platform-ST enforces the RSA-function with a key length of 1024 and 2048 bit, i.e. this parameter of the platform is appropriate for the

Composite-ST. Note, that the Composite-SFRs need not necessarily be the same as the Platform-SFRs, e.g. a trusted channel (FTP_ITC.1) in the

33

denoted by SAR in the following

April 2012 Version 1.2 Page 55/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

Composite product evaluation for Smart Cards and similar devices composite product can be built using an RSA implementation

(FCS_COP.1/RSA) of the platform.

29

ASE_COMP.1-5

The result of this work unit shall be integrated to the result of

ASE_REQ.2.3C/ ASE_REQ.2-4.

The evaluator shall examine the statement of compatibility to determine that the relevant TOE security objectives of the Platform-ST are not contradictory to those of the Composite-ST.

30

31

This work unit relates to Step 3 of the Application Notes above. The

relevant TOE security objectives of the Platform-ST are those that are mapped to the relevant SFRs of the Platform-ST (cf. the work unit

ASE_COMP.1-4).

In order to perform this work unit the evaluator compares the relevant

TOE security objectives of the Platform-ST with those of the Composite-

ST and determines whether they are not contradictory.

32

ASE_COMP.1-6

33

34

ASE_COMP.1-7

35

The result of this work unit shall be integrated to the result of

ASE_OBJ.2.1С/ ASE_OBJ.2-1.

The evaluator shall examine the statement of compatibility to determine that the relevant threats of the Platform-ST are not contradictory to those of the Composite-ST.

This work unit relates to Step 3 of the Application Notes above. The evaluator compares the relevant threats (i.e. being mapped to the relevant

TOE security objectives, cf. the work unit ASE_COMP.1-5) of the

Platform-ST with those of the Composite-ST and determines whether they are not contradictory. The evaluator can decide on noncontradiction, if the threats of the Composite-ST referring to the platform-part of the composite product are covered by the threats of the

Platform-ST. For example, there may be a threat T.Physical_Attack of the Composite-ST covered by the threat T.Tamper of the Platform-ST.

The result of this work unit shall be integrated to the result of

ASE_SPD.1.1C/ ASE_SPD.1-1.

The evaluator shall examine the statement of compatibility to determine that the relevant organisational security policies of the Platform-ST are not contradictory to those of the Composite-ST.

This work unit relates to Step 3 of the Application Notes above. The evaluator compares the relevant organisational security policies (i.e. being mapped to the relevant TOE security objectives, cf. the work unit

April 2012 Version 1.2 Page 56/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

Composite product evaluation for Smart Cards and similar devices

ASE_COMP.1-5) of the Platform-ST with those of the Composite-ST and determines whether they are not contradictory.

36

Beyond it, a special organisational security policy OSP.Composite could be formulated within the Composite-ST, e.g. ‘The application is running on a certified platform and compatible with it’. Then the developer can define the special security objectives for the TOE and its environment exactly reflecting the conditions and restrictions of the certification report of the underlying platform.

37

ASE_COMP.1-8

38

39

40

ASE_COMP.1-9

41

The result of this work unit shall be integrated to the result of

ASE_SPD.1.3C/ ASE_SPD.1-3.

The evaluator shall examine the statement of compatibility to determine that the relevant organisational security policies of the Platform-ST are not contradictory to the threats of the Composite-ST and vice versa.

This work unit relates to Step 3 of the Application Notes above. The evaluator compares the relevant organisational security policies (i.e. being mapped to the relevant TOE security objectives, cf. the work unit

ASE_COMP.1-5) of the Platform-ST with the threats of the Composite-

ST and determines whether they are not contradictory.

An example for contradictive items: The organisational security policy of the Platform-ST “Cryptographic algorithms used shall be in accordance with international standards” is contradictory to the threat of the

Composite-ST “An attacker discloses the secrets being used by the TOE proprietary cryptographic algorithm”.

The result of this work unit shall be integrated to the result of

ASE_SPD.1.3C/ ASE_SPD.1.3C.

The evaluator shall examine the statement of compatibility to determine that the list of the assumptions of the Platform-ST being significant for the Composite-ST is complete and consistent for the current composite

TOE.

This work unit relates to Step 3 of the Application Notes above. In order to determine which assumptions of the Platform-ST are significant for the Composite-ST the evaluator analyses the assumptions of the

Platform-ST and their separation in the following groups:

IrPA: The assumptions being not relevant for the Composite-ST, e.g. the assumptions about the developing and manufacturing phases of the platform.

CfPA: The assumptions being fulfilled by the Composite-ST

automatically. Such assumptions of the Platform-ST can always be assigned to the TOE security objectives of the Composite-ST. Due to this fact they will be fulfilled either by the Composite-SFR or by the

April 2012 Version 1.2 Page 57/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

Composite product evaluation for Smart Cards and similar devices

Composite-SAR automatically.

To give an example, let there be an assumption A.Resp-Appl of the Platform-ST: ‘

All User Data are owned by Smartcard Embedded Software. Therefore, it must be assumed that security relevant User Data (especially cryptographic keys) are treated by the

Smartcard Embedded Software as defined for the specific application context

’ and a TOE security objective OT.Key_Secrecy of the

Composite-ST: ‘

The secrecy of the signature private key used for signature generation is reasonably assured against attacks with a high attack potential.

If the private key is the only sensitive data element, then the assumption A.Resp-Appl is covered by the TOE security objective

OT.Key_Secrecy automatically.

SgPA: The remaining assumptions of the Platform-ST belonging neither to the group IrPA nor CfPA. Exactly this group makes up the

significant assumptions for the Composite-ST, which shall be included into the Composite-ST.

42

ASE_COMP.1-10

The result of this work unit shall be integrated to the result of

ASE_SPD.1.4C/ ASE_SPD.1-4.

The evaluator shall examine the statement of compatibility to determine that the significant security objectives for the operational environments of the Platform-ST are not contradictory to those of the Composite-ST.

43

44

45

46

47

This work unit relates to Step 3 of the Application Notes above. The

significant security objectives for the operational environment of the

Platform-ST are the security objectives for the operational environment being assigned to the assumptions classified as the group SgPA of the

Platform-ST (cf. the work unit ASE_COMP.1-9).

In order to accomplish this work unit the evaluator compares the

significant security objectives for the operational environment of the

Platform-ST with those of the Composite-ST and determines whether they are not contradictory. If necessary, the significant security objectives for the operational environment of the Platform-ST shall be included into the Composite-ST and assigned to the assumptions from the group SgPA, cf. the work unit ASE_COMP.1-8. The inclusion is not necessary, if the Composite-ST already contains equivalent (or similar) security objectives (covering all relevant aspects).

Since assurance of the development and manufacturing environment of the platform is confirmed by the platform certificate, the respective platform-objectives, if any, belong to the group IrPA.

Assurance of development and manufacturing environment is usually completely addressed by the assurance class ALC, and, hence, requires no explicit security objective.

The result of this work unit shall be integrated to the result of

ASE_OBJ.2.1C/ ASE_OBJ.2-1 and ASE_OBJ.2.3C/ ASE_OBJ.2-3.

April 2012 Version 1.2 Page 58/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

Composite product evaluation for Smart Cards and similar devices

2. Integration of composition parts and Consistency of delivery procedures (ALC_COMP)

The composite-specific work units defined in this chapter are intended to be integrated as refinements to the evaluation activities of the ALC class listed in the following table. The other activities of ALC class do not require composite-specific work units.

CC assurance family

Evaluation activity Evaluation work unit

Composite-specific work unit

NB: If the level of the assurance requirement chosen is higher than those identified in this table, the composite-specific work unit is also applicable.

ALC_COMP.1 Integration of the application into the underlying platform and

Consistency check for delivery and acceptance procedures

Objectives

48

The aims of this activity are to determine whether

the correct version of the application is installed onto/into the correct version of the underlying platform, and

– the delivery procedures of Platform and Application Developers are compatible with the acceptance procedure of the Composite Product

Integrator.

Dependencies:

49

No dependencies.

Developer action elements:

ALC_COMP.1.1D

50

The developer shall provide components configuration evidence; cf. item

#7 in Table 1, section 4.7.

ALC_COMP.1.2D

51

The developer shall provide an evidence for delivery and acceptance compatibility; cf. item #8 in Table 1, section 4.7.

Content and presentation of evidence elements:

ALC_COMP.1.1C

52

The components configuration evidence shall show that

(i) the evaluated version of the application has been installed onto / embedded into the certified version of the underlying platform and

April 2012 Version 1.2 Page 59/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

Composite product evaluation for Smart Cards and similar devices

(ii) the configuration parameters evidence shall show that configuration parameters prescribed by the Platform and

Application Developers are actually being used by the Composite

Product Integrator.

53

ALC_COMP.1.2C

The evidence for delivery and acceptance compatibility shall show that the delivery procedures of the Platform and Application Developers are compatible with the acceptance procedure of the Composite Product

Integrator.

Evaluator action elements:

ALC_COMP.1.1E

54

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

ALC_COMP.1.2E

55

The evaluator shall confirm that the evidence for delivery compatibility is complete, coherent, and internally consistent.

Evaluator actions:

Action ALC_COMP.1.1E

ALC_COMP.1-1

The evaluator shall check the evidence that the evaluated version of the application has been installed onto / embedded into the correct, certified version of the underlying platform.

56

57

The general information of the CM capabilities is represented and has to be examined in the context of the assurance family ALC_CMC. The

special composite evaluator activity is to check the evidence of the version correctness for both parts of the composite product.

For the underlying platform, the evaluator shall determine that the actual identification of the platform is commensurate with the respective data in the platform certificate.

58

59

60

For the application, the relevant task is trivial due to the fact that the

Composite Product Evaluator has to perform this task in the context of the assurance family ALC_CMC.

Components identification evidence can be supplied in two different ways: technical and organisational. A technical evidence of version correctness is being generated by the composite product itself: the platform and the application return – in each case – strings containing unambiguous version numbers as answers to the respective commands.

E.g. it can be the return string of a command or the hard copy of the

Windows-Information (like ‘About’); in case of smart cards it can be an appropriate ATR.

A technical evidence of version correctness for hardware can also be supplied, if applicable, by reading off the unambiguous inscription on its

April 2012 Version 1.2 Page 60/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

Composite product evaluation for Smart Cards and similar devices surface. Note that there are no physical indication existing on most smart cards microcontrollers.

61

62

Technical evidence is recommended to be provided.

An organisational evidence of version correctness is being generated by the Composite Product Integrator on the basis of his configuration lists containing unambiguous version information of the platform and the application having been composed into the final composite product.

63

64

65

For example, in case of smart cards it can be an acknowledgement statement (e.g. configuration list) of the integrated circuit

34

manufacturer to the embedded software

35

manufacturer containing the evidence for the versions of the chip, the embedded software and its pre-personalisation parameters

36

.

Organisational evidence is always possible and, hence, shall be provided.

The result of this work unit shall be integrated to the result of

ALC_CMS.1.2C/ ALC_CMS.1-2 (or the equivalent higher components if a higher assurance level is selected).

ALC_COMP.1-2

66

67

68

The evaluator shall examine the evidence for using configuration parameters to determine that the Composite Product Integrator uses the configuration parameters prescribed by the Platform and Application

Developers.

The general information of the configuration parameters required is represented and has to be examined in the context of the assurance family

AGD_PRE [1.2C]. The special evaluator activity is to examine the developer’s evidence and to decide whether the Composite Product

Integrator appropriately treats this special subset of the configuration parameters.

For example, for a Java Card as composite TOE, the Card Issuer has to set all parameters as prescribed by the Java Card Platform and the Applet

Developers while installing the applet onto the Java Card platform; cf.

Table 3, section 4.7.

The result of this work unit shall be integrated to the result of

AGD_PRE.1.2C/AGD_PRE.1-4.

34

-> underlying platform

35

-> application

36

Any data supplied by the embedded software manufacturer that is injected into the non-volatile memory by the integrated circuits manufacturer. These data are for instance used for traceability and/or to secure shipment between phases (cf. [Smartcard IC Platform Protection Profile, Version 1.0, July 2001, registration number

BSI-PP-0002], sec. 8.7).

April 2012 Version 1.2 Page 61/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

Action ALC_COMP.1.2E

ALC_COMP.1-3

Composite product evaluation for Smart Cards and similar devices

The evaluator shall examine the evidence for compatibility of delivery interfaces to determine that delivery procedures of the Platform and

Application Developers are compatible with the acceptance procedure of the Composite Product Integrator.

69

70

The general information of the delivery procedures is represented and has to be examined in the context of the assurance families ALC_DEL and AGD_PRE [1.1C]. The additional composite activity of the evaluator is to examine each delivery interface between the Platform

Developer and the Composite Product Integrator on the one side and between the Application Developer and the Composite Product

Integrator on the other side. As a result, the evaluator confirms or disproves the justification for delivery compatibility.

If there are no delivery interfaces between the Platform and Application

Developers and the Composite Product Integrator or the assurance package chosen does not contain the family ALC_DEL (e.g. EAL1), this work unit is not applicable.

71

The result of this work unit shall be integrated to the result of

ALC_DEL.1.1C/ ALC_DEL.1-1.

3. Composite design compliance (ADV_COMP)

The composite-specific work units defined in this chapter are intended to be integrated as refinements to the evaluation activities of the ADV class listed in the following table. The other activities of ADV class do not require composite-specific work units.

CC assurance family

Evaluation activity Evaluation work unit

Composite-specific work unit

ADV_ARC.1-1

ADV_IMP.1-1

ADV_COMP.1-1

ADV_INT ADV_INT.2.1E ADV_INT.2.1C/

ADV_INT.2-1

ADV_COMP.1-2

NB: If the level of the assurance requirement chosen is higher than those identified in this table, the composite-specific work unit is also applicable.

April 2012 Version 1.2 Page 62/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

ADV_COMP.1

Composite product evaluation for Smart Cards and similar devices

Design compliance with the platform certification report, guidance and ETR_COMP

Objectives

72

73

The aim of this activity is to determine whether the requirements on the application, imposed by the underlying platform, are fulfilled in the composite product.

Application notes

The requirements on the application, imposed by the underlying platform, can be formulated in the relevant certification report (e.g. in form of constraints and recommendations), user guidance and

ETR_COMP (in form of observations and recommendations) for the platform. The developer of the composite product shall regard each of these sources, if available (cf. Table 2, section 4.7), and implement the composite product in such a way that the applicable requirements are fulfilled.

74

75

76

The TSF of the composite product is represented at various levels of abstraction in the families of the development class ADV. Experiential, the appropriate levels of design representation for examining, whether the requirements of the platform are fulfilled by the composite product, are the TOE design (ADV_TDS), security architecture (ADV_ARC) and the implementation (ADV_IMP). In case, these design representation levels are not available (e.g. due to the assurance package chosen is

EAL1), the current activity is not applicable (see the next paragraph for the reason).

Due to the definition of the composite TOE (cf. section 2.1 ‘Definitions’) the interface between the underlying platform and the application is the

internal one, hence, a functional specification (ADV_FSP) as representation level is not appropriate for analysing the design compliance.

Security architecture ADV_ARC as assurance family is dedicated to ensure that integrative security services like domain separation, selfprotection and non-bypassability properly work. It is impossible and not the sense of the composite evaluation to have an insight into the architectural internals of the underlying platform (it is a matter of the platform evaluation). What the Composite Evaluator has to do in the context of ADV_ARC is

(i) to determine whether the application uses services of the underlying platform within its own Composite-ST to provide domain separation, self-protection, non-bypassability and protected start-up; if no, there is no further composite activities for ADV_ARC; if yes, then

(ii) the evaluator has to determine, whether the application uses these platform-services in an appropriate/secure way (please refer to the platform user guidance, cf. item #3 in Table 1, section 4.7.).

April 2012 Version 1.2 Page 63/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

77

Composite product evaluation for Smart Cards and similar devices

Since consistency of the composite product security policy has already been considered in the context of the Security Target in the assurance family ASE_COMP (see page 51 above), there is no necessity to consider non-contradictoriness of the security policy model (ADV_SPM) of the composite TOE and the security policy model of the underlying platform.

Dependencies:

78

No dependencies.

Developer action elements:

ADV_COMP.1.1D

79

The developer shall provide a design compliance justification; cf. item #6 as well as items #3, #4, #5 in Table 1, section 4.7..

Content and presentation of evidence elements:

ADV_COMP.1.1C

80

The design compliance justification shall provide a rationale for design compliance – on an appropriate representation level – of how the requirements on the application, imposed by the underlying platform, are fulfilled in the composite product.

Evaluator action elements:

ADV_COMP.1.1E

81

The evaluator shall confirm that the rationale for design compliance is complete, coherent, and internally consistent.

Evaluator actions:

Action ADV_COMP.1.1E

ADV_COMP.1-1

The evaluator shall examine the rationale for design compliance to determine that all applicable requirements on the application, imposed by the underlying platform, are fulfilled by the composite product.

82

83

In order to perform this work unit the evaluator shall use the rationale for design compliance as well as the TSF representation on the ADV_TDS,

ADV_ARC and ADV_IMP levels on the one side and the input of the platform developer in form of the certification report, guidance and

ETR_COMP on the other side. The evaluator shall analyse which platform requirements are applicable for the current composite product.

The evaluator shall compare each of the applicable requirements with the actual specification and/or implementation of the composite product and determine, for each requirement, whether it is fulfilled. As result, the evaluator confirms or disproves the rationale for design compliance.

For example, platform guidance may require the application to perform a special start-up sequence testing the current state of the platform and initialising its self-protection mechanisms. Such information might be found in the description of secure architecture ADV_ARC of the composite TOE; see also the Application Note above.

April 2012 Version 1.2 Page 64/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

84

Composite product evaluation for Smart Cards and similar devices

The appropriate representation level (ADV_TDS, ADV_ARC and/or

ADV_IMP), what the analysis is being performed on, can be chosen and mixed flexibly depending on the concrete composite TOE and the requirement in question. Where it is not self-explaining, the evaluator shall justify why the representation level chosen is appropriate.

85

86

The evaluator activities in the context of this work unit can be spread over different single evaluation aspects (e.g. over ADV_TDS and

ADV_IMP). In this case the evaluator performs the partial activity in the context of the corresponding single evaluation aspect. Then the notation for this work unit shall be ADV_COMP.1-1-TDS, ADV_COMP.1-1-

ARC and ADV_COMP.1-1-IMP, respectively.

If the assurance package chosen does not contain the families

ADV_TDS, ADV_ARC or ADV_IMP (e.g. EAL1), this work unit is not applicable (cf. Application Note above).

87

ADV_COMP.1-2

88

89

90

The result of this work unit shall be integrated to the result of

ADV_TDS.1−2E/ ADV_TDS.1-7, ADV_ARC.1.1E/ ADV_ARC.1.1C/

ADV_ARC.1-1, ADV_IMP.1.1E/ ADV_IMP.1.1C/ ADV_IMP.1-1 (or the equivalent higher components if a higher assurance level is selected).

The evaluator shall check the TSF internals of the composite TOE to determine that they do not contradict any design requirement imposed by the underlying platform.

The TSF internals are represented and evaluated in the context of the assurance family ADV_INT. The evaluator shall compare the internal structure of the TSF with the design requirements of the platform and search for obvious contradictions.

If there are no requirements of the platform concerning the TSF internal structure or the assurance package chosen does not contain the family

ADV_INT, this work unit is not applicable.

The result of this work unit shall be integrated to the result of

ADV_INT.2.1E / ADV_INT.2.1C/ ADV_INT.2-1 (or the equivalent higher components if a higher assurance level is selected).

April 2012 Version 1.2 Page 65/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

4.

Composite product evaluation for Smart Cards and similar devices

Composite functional testing (ATE_COMP)

The composite-specific work units defined in this chapter are intended to be integrated as refinements to the evaluation activities of the ATE class listed in the following table. The other activities of ATE class do not require composite-specific work units.

CC assurance family

Evaluation activity Evaluation work unit

Composite-specific work unit

ATE_COV

ATE_COV.1.1C ATE_COV.1-1 ATE_COMP.1-1

ATE_COV.1.1C ATE_COV.1-1 ATE_COMP.1-2

NB: If the level of the assurance requirement chosen is higher than those identified in this table, the composite-specific work unit is also applicable.

ATE_COMP.1

Objectives

Composite product functional testing

91

The aim of this activity is to determine whether composite product as a

whole exhibits the properties necessary to satisfy the functional requirements of its Security Target.

Application notes

92

93

94

A composite product can be tested separately and integrative. Separate testing means that the platform and the application are being tested independent of each other. A lot of tests of the platform may have been performed within the scope of its accomplished evaluation. The application may be tested on a simulator or an emulator, which represent a virtual machine.

Integration testing means that the composite product is being tested as it is: the application is running on the platform.

Behaviour of implementation of some SFRs can depend on properties of the underlying platform as well as of the application (e.g. correctness of the measures of the composite product to withstand a side channel attack or correctness of the implementation of tamper resistance against physical attacks). In such a case the SFR implementation shall be tested on the final composite product, but not on a simulator or an emulator.

This activity focuses exclusively on testing of the composite product as a

whole and represents merely partial efforts within the general test approach being covered by the assurance ATE. These integration tests shall be specified and performed, whereby the approach of the standard

37 assurance families of the class ATE shall be applied.

37

i.e. as defined by CEM

April 2012 Version 1.2 Page 66/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

95

Composite product evaluation for Smart Cards and similar devices

- A correct behaviour of the Platform-TSF being relevant for the

Composite-ST (corresponding to the group RP_SFR in the work unit 0 above), and

- absence of exploitable vulnerabilities (sufficient effectiveness) in the context of the Platform-ST are confirmed by the valid Platform Certificate, cf. chapter 6 above.

Dependencies:

96

No dependencies.

Developer action elements:

ATE_COMP.1.1D

97

The developer shall provide a set of tests as required by the assurance package chosen.

ATE_COMP.1.2D

98

The developer shall provide the composite TOE for testing.

Content and presentation of evidence elements:

ATE_COMP.1.1C

99

Content and presentation of the specification and documentation of the

integration tests shall correspond to the standard

38

requirements of the assurance families ATE_FUN and ATE_COV.

100

ATE_COMP.1.2C

The composite TOE provided shall be suitable for testing.

Evaluator action elements:

ATE_COMP.1.1E

101

102

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

ATE_COMP.1.2E

The evaluator shall specify, perform and document a set of own

integration tests to confirm that the composite TOE operates as specified.

Evaluator actions:

Action ATE_COMP.1.1E

ATE_COMP.1-1

The evaluator shall examine that the developer performed the

integration tests for all SFRs having to be tested on the composite product as a whole.

103

In order to perform this work unit the evaluator shall analyse, for each

SFR, whether it directly depends on security properties of the platform and of the application. Then the evaluator shall verify that the integration tests performed by the developer cover at least all such SFRs.

104

If the assurance package chosen does not contain the families ATE_FUN and ATE_COV (e.g. EAL1), this work unit is not applicable.

38

i.e. as defined by CEM

April 2012 Version 1.2 Page 67/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

105

Composite product evaluation for Smart Cards and similar devices

The result of this work unit shall be integrated to the result of

ATE_COV.1−1C/ ATE_COV.1-1 and ATE_FUN.1.2C/ ATE_FUN.1-3

(or the equivalent higher components if a higher assurance level is selected).

106

Action ATE_COMP.1.2E

ATE_COMP.1-2

The evaluator shall determine the minimal amount of the integration tests being necessary for the current composite evaluation.

107

The evaluator shall perform the following steps:

1) The evaluator determines the share of the platform part of the TOE in enforcing of the Composite-ST. In order to do this, the evaluator refers to the TOE design (ADV_TDS and ADV_ARC might possess an appropriate representation level for this purpose) as well as to the

Composite-ST and lists all Composite-SFRs using the security services of the platform 39 . Hereby the evaluator shall understand/document, for each such Composite-SFR, what concretely the platform does (so called

platform’s share).

For example, there is a Composite-SFR FCS_CKM.1 fulfilled by the

TSF-portion ‘Key Generation’. The share of the platform in implementing this SFR is generating random numbers for key generation.

2) The evaluator checks, for each such Composite-SFR, whether the

platform’s share has been covered by the Platform Certificate; in order to do this the evaluator refers to the platform user guidance, ETR_COMP and the platform certification report.

For our example with the random number generator (RNG), the evaluator might find an advice in ETR_COMP that (i) the RNG is regularly being tested (online tests), (ii) its behaviour concerning power consumption analysis was evaluated and (iii) a sufficient (for generation of static keys) random numbers quality was confirmed by the Platform Certificate. In such a case the evaluator can decide that no integration tests are necessary for FCS_CKM.1/Key Generation

40

.

The next example represents a situation, where additional integration tests are necessary. There let be a Composite-SFR FPT_EMSEC.1

(electromagnetic emanation) fulfilled by the following TSF-portions:

- ‘User Authentication’; the platform’s share in implementing this SFR is

39

Such security services of the platform are represented by the group RP_SFR, cf. the work unit 0 above

40

Of course, the evaluator might (and, perhaps, would) decide to test ‘Key Generation’-TSF as an integration test on the final TOE. A methodological reason for this test would then be rather a general check of the respective functionality, but not the confirmation of security behaviour of the platform-RNG.

April 2012 Version 1.2 Page 68/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

Composite product evaluation for Smart Cards and similar devices scrambling the reference authentication data stored in the TOE;

- ‘Key Generation’; the platform’s share in implementing this SFR is disguising information about the value of the key being generated while observing power consumption;

- ‘Signature Creation’; the platform’s share in implementing this SFR is disguising information about the value of the signature key being used while observing power consumption;

For scrambling, the evaluator might find the advice in ETR_COMP that the platform scrambling engine has been evaluated, but it must be correctly initialised by the application. Hence, the evaluator has to specify an integration test for initialising the scrambling engine.

For disguising during key generation, the evaluator might find no advices in ETR_COMP. Hence, the evaluator has to assume that this behaviour of the platform was not included in consideration. Therefore, the evaluator has to specify an integration test for power consumption while generating the signature keys.

For disguising during signature creation, the evaluator might find an advice in ETR_COMP that DPA and SPA on RSA have been evaluated, but no advice of Timing on RSA. Hence, the evaluator has to assume that the Timing-on-RSA behaviour of the platform was not included in consideration. Therefore, the evaluator has to specify an integration

Timing-on-RSA test for power consumption while using the signature key.

3) The evaluator refers to ETR_COMP and checks for any explicit requirements for performing tests in the context of the composite evaluation. Such explicit requirements might sound like ‘Such test has to be performed during the SW evaluation’.

All platform tests being necessary for the current composite evaluation, but not covered by the Platform Certificate, and all tests explicitly required by ETR_COMP, encompass the minimal amount of the integration tests being necessary for the current composite evaluation.

This work unit is the complementary part to the work unit

ASE_COMP.1-1 In ASE_COMP.1-1 the evaluator determines, on which part of the Platform-ST the Composite-ST can rely (the group RP_SFR); in the current work unit the evaluator determines, whether the

Composite-ST can also rely on the platform’s functional behaviour being not covered by the Platform-ST.

108

The result of this work unit shall be integrated to the result of

ATE_COV.1.1C/ ATE_COV.1-1 (or the equivalent higher components if a higher assurance level is selected).

April 2012 Version 1.2 Page 69/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

ATE_COMP.1-3

Composite product evaluation for Smart Cards and similar devices

The evaluator shall perform the standard

41

evaluator actions in the context of the assurance family ATE_IND on the set of the integration tests using the composite product as a whole.

109

110

The set of the integration tests for this activity shall embrace at least the minimal amount of the integration tests as determined in the previous work unit.

The result of this work unit shall be integrated to the result of

ATE_IND.1.2E/ ATE_IND.1-5) (or the equivalent higher components if a higher assurance level is selected).

41

i.e. as defined by CEM

April 2012 Version 1.2 Page 70/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

5.

Composite product evaluation for Smart Cards and similar devices

Composite vulnerability assessment (AVA_COMP)

The composite-specific work units defined in this chapter are intended to be integrated as refinements to the evaluation activities of the AVA class listed in the following table. The other activities of AVA class do not require composite-specific work units.

CC assurance family

Evaluation activity Evaluation work unit

Composite-specific work unit

AVA_VAN.1.3E AVA_VAN.1-5 AVA_COMP.1-1

AVA_VAN.1.3E. AVA_VAN.1-6 AVA_COMP.1-2

AVA_VAN.1.3E AVA_VAN.1-7 AVA_COMP.1-2

AVA_VAN

AVA_VAN.1.3E AVA_VAN.1-8 AVA_COMP.1-2

NB: If the level of the assurance requirement chosen is higher than those identified in this table, the composite-specific work unit is also applicable.

AVA_COMP.1

Objectives

Composite product vulnerability assessment

111

112

The aim of this activity is to determine the exploitability of flaws or weaknesses in the composite TOE as a whole in the intended environment.

Application notes

This activity focuses exclusively on vulnerability assessment of the composite product as a whole and represents merely partial efforts within the general approach being covered by the standard

42

assurance family of the class AVA: AVA_VAN.

113

The results of the vulnerability assessment for the underlying platform represented in the ETR_COMP can be reused, if they are up to date and all composite activities for correctness – ASE_COMP.1, ALC_COMP.1,

ADV_COMP.1 and ATE_COMP.1 – are finalised with the verdict

PASS.

114

Due to composing of the platform and the application a new quality arises, which can cause additional vulnerabilities of the platform which might be not mentioned in the ETR_COMP.

Dependencies:

115

No dependencies.

Developer action elements:

AVA_COMP.1.1D

116

The developer shall provide the composite TOE for penetrating testing.

Content and presentation of evidence elements:

AVA_COMP.1.1C

117

The composite TOE provided shall be suitable for testing as a whole.

42

i.e. as defined by CEM

April 2012 Version 1.2 Page 71/73

CCDB-2012-04-001

Appendix 1.2: CC v3.1

Evaluator action elements:

AVA_COMP.1.1E

118

Composite product evaluation for Smart Cards and similar devices

The evaluator shall conduct penetration testing of the composite product

as a whole building on evaluator’s own vulnerability analysis, to ensure that the vulnerabilities being relevant for the Composite-ST are not exploitable.

Evaluator actions:

Action AVA_COMP.1.1E

AVA_COMP.1-1

The evaluator shall examine the results of the vulnerability assessment for the underlying platform to determine that they can be reused for the composite evaluation.

119

120

The results of the vulnerability assessment for the underlying platform are usually represented in the ETR_COMP. They can be reused, if they are up to date and all composite activities for correctness –

ASE_COMP.1, ALC_COMP.1, ADV_COMP.1 and ATE_COMP.1 – are finalised with the verdict PASS. The evaluator shall also consider the relevant determinations in the Platform Certification Report. For validity of the platform security certificate please refer to chapter 6 above.

The result of this work unit shall be integrated to the result of

AVA_VAN.1.3E/ AVA_VAN.1-5 (or the equivalent higher components if a higher assurance level is selected).

AVA_COMP.1-2

121

The evaluator shall specify, conduct and document penetration testing of the composite product as a whole, using the standard approach of the assurance family AVA_VAN.

If the correctness-related activities – ASE_COMP.1, ALC_COMP.1,

ADV_COMP.1 and ATE_COMP.1 – are finalised with the verdict PASS and the certificate for the platform covers all security properties needed for the composite product, composing of the platform and the application must not create additional vulnerabilities of the platform.

122

123

If the evaluator determined that composing of the platform and the application creates additional vulnerabilities of the platform

43

, a contradiction to the verdict PASS for the correctness activities (see paragraph 113 above) has to be supposed or the certificate for the platform does not cover all security properties needed for the current composite product.

The result of this work unit shall be integrated to the result of

AVA_VAN.1.3E/ AVA_VAN.1-6, AVA_VAN.1-7, AVA_VAN.1-8 (or the equivalent higher components if a higher assurance level is selected).

43

i.e. not mentioned in the ETR_COMP

April 2012 Version 1.2 Page 72/73

CCDB-2012-04-001

Appendix 2

Composite product evaluation for Smart Cards and similar devices

Appendix 2: ETR for composite evaluation template

The related document “JIL-ETR-template-for-composition” shall be used as a template by the

Platform Developer to issue the ETR_COMP. Please note that the layout can be customized according to the evaluation facilities company standard, but the contents and structure are mandatory.

April 2012 Version 1.2 Page 73/73

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project