Common Criteria

Common Criteria V3.1

Evaluation of IT products and IT systems

Contents 1 Background ....................................................... 1

2 Benefits of Evaluations ..................................... 3

3 Levels of Assurance .......................................... 3

3.1 EAL1 - Functionally Tested .................................. 4

3.2 EAL2 - Structurally Tested ................................... 5

3.3 EAL3 - Methodically Tested and Checked ............. 5

3.4 EAL4 - Methodically Designed, Tested and Reviewed ............................................................ 6

3.5 EAL5 - Semi formally Designed and Tested .......... 6

3.6 EAL6 Semi formally Verified Design and Tested ................................................................ 7

3.7 EAL7 - Formally Verified Design and Tested ......... 8

4 Protection Profiles and Security Targets........... 8

4.1 Protection Profile (PP) ......................................... 8

4.2 Security Target (ST) ............................................ 9

5 Classes of Assurance ........................................ 9

5.1 Development (ADV) ............................................. 9

5.2 Guidance Documents (AGD) .............................. 10

5.3 Life Cycle Support (ALC) ................................... 10

5.4 Tests (ATE) ...................................................... 10

5.5 Vulnerability Assessment (AVA) ......................... 10

6 Composition .................................................... 11

7 CC A quick Reference ................................... 13

7.1 Evaluation Assurance Levels ............................. 13

7.2 Composition ...................................................... 14

8 Evaluation and Certification ............................ 15

9 Time Schedules of Evaluations ....................... 15

Common Criteria V3.1 Page 2 | 25 TV Informationstechnik GmbH

10 CC Services offered by TViT ......................... 16

11 About TViT .................................................... 17

12 Links to the CC ............................................... 21

13 Glossary .......................................................... 21

14 Annex: Selected References ........................... 22

15 Contact ............................................................ 25


1 Background

There is no dispute that in todays world of information technology a high degree of security in terms of confidentiality, integrity and availability of IT products, systems and procedures is a must.

Since this field involves sensitive information which is collated, processed and transmitted in electronic form and viewed as obliged, simple trust in the existing characteristics of products and systems is not enough; instead, security can only be achieved and certified by means of a validated evaluation process performed according to appropriate and recognized criteria by an impartial body (like e.g. TViT) with experience in this complex field.

The Common Criteria [CC] are an appropriate instrument to review and assess the information security of IT products and systems by a combination of evaluating the related product and system documentation as well as performing practical testing.

The Common Criteria represent the outcome of efforts to develop criteria for evaluation of IT security that are widely useful within the international community. They are an alignment and development of a number of source criteria: the existing European, US and Canadian criteria (ITSEC, TCSEC and CTCPEC respectively).

The CC structure provides great flexibility in the specification of secure products. Consumers and other parties can specify the security functionality of a product in terms of standard protection profiles, and independently select the evaluation assurance level from a defined set of seven increasing Evaluation Assurance Levels, from EAL1 up to EAL7.

Version 1.0 of the CC was published for comment in January 1996. Version 2.0 took account of extensive review and trials during the following two years and was published in May 1998. Version 2.3, dated August 2005, has been published as the International Standard ISO/IEC 15408:2005. Version 3.1 is the recent version of the Common Criteria and has become official September 2006 in revision 1. Parts 2 and 3 have been upgraded to revision 2 in September 2007.


Figure 1: Developmental history of CC

CC version 3.1 consists of the following parts:

Part 1: Introduction and general model

Part 2: Security functional components

Part 3: Security assurance components

The CC is complemented by the Common Evaluation Methodology [CEM] manual, which describes the principles and model of the methodology needed to apply the Common Criteria.


2 Benefits of Evaluations

The main objective of an evaluation is to collect appropriate and reliable evidence to achieve confidence in the IT security measures implemented in a product or system (also called Target of Evaluation, TOE) on the developers as well as on the users side.

Hence an evaluation is a quality enforcing process, which increases the security level of a product or system and additionally leads to a correct and complete documentation. Since evaluation results based on Common Criteria are recognized nearly worldwide, an evaluated and certified product or system has an outstanding position in the market.

3 Levels of Assurance

The CC contains a set of defined assurance levels constructed using components from the assurance families. These levels are intended to provide internally consistent general purpose assurance packages. Other groupings of components are not excluded. To meet specific objectives, an assurance level can be augmented by one or more additional components (from assurance families not already included in the EAL) or by the substitution of assurance components (with another hierarchically higher assurance component in the same assurance family) to an EAL.

Assurance levels are defined in the CC for the rating of a TOE's assurance. Every assurance component contributes to the assurance that a TOE meets its security claims from the PP and ST. EALs provide a uniformly increasing scale which balances the level of assurance obtained with the cost and feasibility of acquiring this degree of assurance. There are seven hierarchically ordered EALs. The increase in assurance across the levels is accomplished by substituting hierarchically higher assurance components from the same assurance family, and by the addition of assurance components from other assurance families.


The seven EALs are as follows:

EAL1 - functionally tested

EAL2 - structurally tested

EAL3 - methodically tested and checked

EAL4 - methodically designed, tested and reviewed

EAL5 - semi formally designed and tested

EAL6 - semi formally verified design and tested

EAL7 - formally verified design and tested

EAL1 is the entry level. Up to EAL4 increasing rigour and detail are introduced, but without introducing significantly specialised security engineering techniques. EAL1-4 can generally be retrofitted to pre-existing products and systems.

Above EAL4 increasing application of specialised security engineering techniques is required. TOEs meeting the requirements of these levels of assurance will have to be designed and developed with the intent of meeting those requirements. At the top level (EAL7) there are significant limitations on the practicability of meeting the requirements, partly due to substantial cost impact on the developer and evaluator activities, and also because anything other than the simplest of products is likely to be too complex to submit to current state-of-the-art techniques for formal analysis.

3.1 EAL1 - Functionally Tested

EAL1 is applicable where some confidence in correct operation is required, but the threats to security are not viewed as serious. It will be of value where independent assurance is required to support the contention that due care has been exercised with respect to the protection of personal or similar information.

This level provides an evaluation of the TOE as made available to the customer, including independent testing against a specification and an examination of the guidance documentation provided. It is intended that an EAL1 evaluation could be successfully conducted without assistance from the developer of the TOE, and for minimal outlay. An evaluation at this level should provide evidence that the


TOE functions in a manner consistent with its documentation, and that it provides useful protection against identified threats. Additionally, the evaluation will confirm TOE resistance against attacks with basic attack potential, based on an evaluators search of public domain information and following penetration tests.

3.2 EAL2 - Structurally Tested

EAL2 requires the co-operation of the developer in terms of the delivery of design information and test results, but should not demand more effort on the part of the developer than is consistent with good commercial practise. As such it should not require a substantially increased investment of cost or time.

EAL2 is applicable in those circumstances where developers or users require a low to moderate level of independently assured security in the absence of ready availability of the complete development record. Such a situation may arise when securing legacy systems, or where access to the developer may be limited.

In addition to EAL1, the TOE resistance against attacks with basic attack potential is supported by an independent vulnerability analysis of the evaluator, using guidance documents, TOE design and architecture information.

3.3 EAL3 - Methodically Tested and Checked

EAL3 permits a conscientious developer to gain maximum assurance from positive security engineering at the design stage, without substantial alteration of existing sound development practices. It is applicable where the requirement is for a moderate level of independently assured security, with a thorough investigation of the TOE and its development without incurring substantial re-engineering costs.

In addition to EAL2, an EAL3 evaluation provides an analysis supported by grey box testing and selective independent confirmation of the developer test results. Development environment controls, TOE configuration management, and evidence of secure delivery procedures are also required.


3.4 EAL4 - Methodically Designed, Tested and Reviewed

EAL4 permits a developer to maximise assurance gained from positive security engineering based on good commercial development practices. Although rigorous, these practices do not require substantial specialist knowledge, skills and other resources. EAL4 is the highest level at which it is likely to be economically feasible to retrofit to an existing product line. It is applicable in those circumstances where developers or users require a moderate to high level of independently assured security in conventional commodity TOEs, and there is willingness to incur some additional security-specific engineering costs.

An EAL4 evaluation provides, in addition to EAL3, an analysis supported by a complete interface specification, a description of the basic modular design of the TOE, and a subset of the implementation. Testing is supported by a vulnerability analysis (also using the implementation representation), demonstrating resistance to penetration attackers with an Enhanced-Basic attack potential. Assurance is also provided through additional automated configuration management.

3.5 EAL5 - Semi formally Designed and Tested

EAL5 permits a developer to gain maximum assurance from security engineering based on rigorous commercial development practices, supported by moderate application of specialised security engineering techniques. Such a TOE will probably be designed and developed with the intent of achieving EAL5 assurance. It is likely that the additional costs attributable to EAL5 requirements, relative to rigorous development without application of specialist techniques, will not be large. EAL5 is applicable where the requirement is for a high level of independently assured security in a planned development, with a rigorous development approach, but without incurring unreasonable costs for specialised security engineering techniques.


An EAL5 evaluation provides, in addition to EAL4, an analysis supported by a modular design of the TOE Security Functionality with limited complexity. Assurance is supplemented by a semiformal presentation of the design, a structured architecture, comprehensive TOE configuration management, and an independent, methodical vulnerability analysis demonstrating resistance to penetration attackers with a moderate attack potential.

3.6 EAL6 Semi formally Verified Design and Tested

EAL6 permits a developer to gain high assurance from application of specialised security engineering techniques in a rigorous development environment, and to produce a premium TOE for protecting high value assets against significant risks. EAL6 is applicable to the development of specialised security TOEs, for application in high risk situations where the value of the protected assets justifies the additional costs.

An EAL6 evaluation, in addition to EAL5, provides an analysis which is supported by a modular and layered approach to design with minimised complexity. Assurance is additionally gained through a formal model of selected TOE security policies and a semiformal presentation of the functional specification and TOE design. The independent, methodical vulnerability analysis demonstrates resistance to penetration attackers with a high attack potential. The search for covert channels must be systematic. Configuration management controls are further strengthened by a complete automation of configuration management.


3.7 EAL7 - Formally Verified Design and Tested

EAL7 is applicable to the development of security TOEs for application in extremely high risk situations, and/or where the high value of the assets justifies the higher costs. Practical application of EAL7 is currently limited to TOEs with tightly focused security functionality that is amenable to extensive formal analysis.

For an EAL7 evaluation, additional to EAL6, the formal model is supplemented by a formal presentation of the functional specification and high level design, showing correspondence.

Evidence of developer white box testing and complete independent confirmation of developer test results are required. Complexity of the modular design must be minimised. Development environment controls are further strengthened by application of a measurable life-cycle model.

4 Protection Profiles and Security Targets

In defining the security requirements for a trusted product or system the user/developer needs to consider the threats to the IT environment. The CC contains a catalogue of components that the developers of PP and ST can collate to form the security requirements definition. The organization of these components into a hierarchy helps the user to locate the right components to counter threats. The user then presents the security requirements in the PP and the ST of the TOE.

4.1 Protection Profile (PP)

A protection profile defines an implementation-independent set of security requirements and objectives for a certain type of IT products or systems which meet similar consumer needs for IT security. A PP is intended to be reusable and to define requirements which are known to be useful and effective in meeting the identified objectives. To earn higher flexibility, the PP may request demonstrable conformance from TOEs or requests strict conformance.


The PP concept has been developed to support the definition of functional standards, and as an aid to formulating procurement specifications.

For preceding versions of the CC PPs have been developed for firewalls, relational databases, smart cards etc, and to enable backwards compatibility with TCSEC B1 and C2 ratings.

4.2 Security Target (ST)

A security target contains the IT security objectives and requirements of a specific identified TOE and defines the functional and assurance measures offered by that TOE to meet stated requirements. The ST may claim strict or demonstrable conformance to one or more PPs, and forms the basis for an evaluation.

5 Classes of Assurance

To demonstrate the security of a TOE during development and operation the CC require information structured according to the following classes. Basically each class implies one or more deliverable to be provided by the sponsor to the evaluators.

5.1 Development (ADV)

The development class encompasses requirements for structuring and representing the TSF at various levels and varying forms of abstraction. These requirements are concerned with the refinement of the TSF from the specification defined in the ST to the implementation. Additionally, a survey of TOE self-protection, called architecture, is included for EAL2 and higher. The knowledge obtained by this information is used as the basis for conducting vulnerability analysis and testing upon the TOE, as described in the AVA and ATE classes.


5.2 Guidance Documents (AGD)

Guidance documents are concerned with the secure preparation and operational use of the TOE, by the users and administrators.

5.3 Life Cycle Support (ALC)

Life-cycle support is an aspect of establishing discipline and control in the processes of refinement of the TOE during its development and maintenance. The requirements of the families include lifecycle definition, CM capabilities and scope, tools and techniques, security of the development environment as well as delivery of the TOE, and the remediation of flaws found by TOE consumers.

5.4 Tests (ATE)

The class Tests provides assurance that the TSF behaves as described (in the functional specification, TOE design, and implementation representation). It addresses coverage and depth of developer testing, and requirements for independent testing.

5.5 Vulnerability Assessment (AVA)

This class defines requirements directed at the identification of vulnerabilities which could be introduced in the development or occur during operation of the TOE. Development vulnerabilities are based on tampering, bypassing, monitoring or direct attack of the TOE security functions. Operational vulnerabilities take advantage of weaknesses in non-technical countermeasures to violate the TOE Security Functional Requirements (SFRs), e.g. misuse or incorrect configuration.


6 Composition

The levels of assurance EAL1-EAL7 are particularly suitable to evaluate products made by a single vendor. However, if assurance is required on a product which consists of components made by different vendors, it may be impossible to obtain the information necessary to perform an evaluation at EAL2 or above. This is due to the fact that cooperation agreements usually do not stretch to the extent of providing internal design documents and development process evidence.

In this situation, an evaluation of the composite product may be performed according to the Composition class of the Common Criteria. Thus, assurance on the interactions between components can be achieved, if the following prerequisites are met:1

The composite product consists of a base and a dependent component, which are both certified or at least in the process of evaluation.

The EAL of the dependent component is smaller than or equal to the EAL of the base component.

All evaluation evidence of the dependent component is (or will be) available.

The Security Target of the base component

Figure 2: Composition structure

Figure 2 illustrates the structure of the composite product. The evaluation is also possible if the composite product consists of multiple components, or if a classification into base and dependent

1 For Smart Cards and similar devices other rules apply, because usually an EAL

certification is required.


component is not feasible. However, in this case the process will be more complex, because the available structure needs to be mapped to the structure in figure 6 for each of the interfaces.

In order to measure the level of assurance obtained by a composition evaluation, the CC defines Composed Assurance Packages CAP-A, CAP-B and CAP-C, similar to EAL2, EAL3 and EAL4. CAPs comparable to EAL5 and above are not available.

The main advantage of CAP over EAL is that only little information is needed from the developer of the base component. Specifically, no design document or source code of the base component is required. Therefore, the composition evaluation is very cost-efficient.

There are some drawbacks, however. Descriptions of the base component interfaces which are used by the developer of the dependent component have to be provided, and this might not be possible due to a non-disclosure agreement. Furthermore, if the dependent component implements its security functions by using interfaces which were not part of the base components evaluation, additional information from the vendor of the base component might be required. Last but not least, the maximum assurance level CAP-C may not be sufficient for products with high assurance requirements, especially with regard to vulnerability assessment.


7 CC A quick Reference

7.1 Evaluation Assurance Levels

The following table provides a quick reference of the minimum information which is mandatory and has to be delivered by the sponsor of an evaluation and reviewed by the evaluation body according to the respective evaluation assurance level.

The notation is as follows.

not required for this level

N mandatory for this level

where N = {1; ; 6} is an indicator for the detail of the required information.

Assurance Class Deliverable EAL 1 2 3 4 5 6 7

Development

Security Architecture 1 1 1 1 1 1 Functional Specification 1 2 3 4 5 5 6 Implementation (Source Code) 1 1 2 2

TSF Internals 2 3 3 Security Policy Modeling 1 1 TOE Design 1 2 3 4 5 6

Guidance Documents

Operational User Guidance 1 1 1 1 1 1 1

Preparative Procedures 1 1 1 1 1 1 1

Life-Cycle Support

CM Capabilities 1 2 3 4 4 5 5 CM Scope 1 2 3 4 5 5 5 Delivery 1 1 1 1 1 1 Development Security 1 1 1 2 2 Flaw Remediation Life-Cycle Defintion 1 1 1 1 2 Tools and Techniques 1 2 3 3

Security Target

Conformance Claims ST 1 1 1 1 1 1 1 Extended Components Definition 1 1 1 1 1 1 1

Introduction 1 1 1 1 1 1 1 Security Objectives 1 2 2 2 2 2 2 Security Requirements 1 2 2 2 2 2 2 Security Problem Definition 1 1 1 1 1 1

TOE Summary Specification 1 1 1 1 1 1 1


Assurance Class Deliverable EAL 1 2 3 4 5 6 7

Tests

Coverage of Testing 1 2 2 2 3 3 Depth of Testing 1 2 3 3 4 Functional Tests 1 1 1 1 2 2 Independent Testing 1 2 2 2 2 2 3

Vulnerability Assessment

Vulnerability Analysis 1 2 2 3 4 5 5

Table 1: EAL summary

Note: The table above defines the minimum information which is required to achieve a certain evaluation assurance level. Beyond that it is possible to fulfil requirements taken from a higher assurance level. This procedure is called augmentation and a + sign is added to the evaluation assurance level to indicate this (e.g. EAL4+).

7.2 Composition

The following table shows a quick reference of the information and level of detail required for the corresponding CAP level. The notation is similar to Table 1: EAL summary.

Assurance Class Deliverable CAP A B C

Composition

Composition Rationale 1 1 1 Interface Testing 1 2 2 Functional Description 1 2 3 Basic Reliance Information 1 1 2 Composition Vulnerability Review 1 2 3

Guidance Documents

Operational User Guidance 1 1 1 Preparative Procedures 1 1 1

Life-Cycle Support CM Capabilities 1 1 1 CM Scope 2 2 2

Security Target

Conformance Claims ST 1 1 1 Extended Components Definition 1 1 1 Introduction 1 1 1 Security Objectives 1 2 2 Security Requirements 1 2 2 Security Problem Definition 1 1 TOE Summary Specification 1 1 1

Table 2: CAP summary


8 Evaluation and Certification

A security evaluation based on the CC comprises on the whole the review of the required documentation and the independent testing of the TOE by an accredited evaluation body. The result is a final evaluation technical report (ETR) compiling all single findings of the evaluation and the concluding verdict passed or not passed.

A certification is the review whether the evaluation process was performed successfully and in accordance to the CC by an accredited certification body. The result is an IT security certificate stating the achieved evaluation assurance level and the related certification report summarizing the certification.

An IT security certificate - issued by a (national) certification body who is a member of the international Common Criteria Recognition Arrangement (CCRA) - is internationally recognized and valid in all participating countries of the CCRA.

In Germany the Federal Office for Information Security (FOIS/BSI) acts as the national certification body.

9 Time Schedules of Evaluations

The following figure shows a typical time schedule of an EAL4 evaluation process.

Figure 3: Typical evaluation schedule


The actual time schedule strongly depends on the evaluation assurance level and the complexity of the TOE (e.g. the implemented security functionality, lines of code). Additionally the resources available on the sponsors side to prepare the deliverables required by the CC are a limiting figure. Typical durations of an evaluation are as follows:

EAL Duration 1 2 months 2 3 to 4 months

3 4 to 6 months

4 5 to 9 months

5 6 to 10 months

6/7 more than 9 months

10 CC Services offered by TViT

The Evaluation Body for IT Security of TViT is accredited according to the international laboratory standard ISO 17025 and fully licensed (EAL1 to EAL7) by the German Federal Office for Information Security (FOIS/BSI) to perform CC security evaluations of any IT product or system. Since FOIS/BSI is a member of the international CC Recognition Arrangement (CCRA), certificates based on the evaluation results of TViT will be accepted and recognized all over the world.

Annex 1 provides a list of selected security evaluation performed by TViT.

With an experience of about eighteen years in the area of security evaluations TViT can offer the following services related to the CC.

CC evaluations of IT products and systems

CC trainings of developers

CC trainings of evaluators

Support during set-up of evaluation bodies and security laboratories


11 About TViT

TV Informationstechnik GmbH TViT in short is a member of the TV NORD Group, based in Hannover, Germany. TV NORD has a workforce of more than 10.000 staff worldwide and is active in 70 countries in Europe, Asia and America besides Germany. Over a TV tradition reaching back 140 years, TV NORD has performed and developed technical tests and inspections in very many different areas. The principles upon which the company operates stipulate that the TV NORD Group must offer and implement its services independently and on a neutral and impartial basis.

As an intermediary with the role of creating trust in IT security and IT quality, TViT has specialised in the inspection, evaluation and certification of IT products, IT systems and IT processes of all kinds, and also on assessment in relation to special requirements, laws, guidelines and directives (eCompliance). TVIT develops evaluations and assessments for manufacturers, operators and users based on general requirements and national/international standards. In this process, TViT makes use of recognised processes and also offers advice and professional services in the area of information technology.

TViT is accredited by national and international organisations, and official authorities and bodies, for the scope of IT security and IT quality. Accreditations are the official recognition by a higher-level organisation of the expert competency of an inspection body. The accreditations are confirmed by means of regular audits and therefore demonstrate the expert competency of TViT in these areas.


Federal Office for Information Security

Accreditation according to DIN EN ISO/IEC 17025:2005 for evaluations according to ITSEC/ITSEM/CC/CEM as well as BSI-TR 03104, BSI-TR 03105 Part 3 and Part 5, BSI-TR 03121-1, BSI-TR 03121-3, BSI-TR 03132 and BSI-TR 01201

Licensed auditors for IT-Grundschutz, ISO/IEC 27001 on the basis of IT-Grundschutz and for De-Mail

IT-Security Service Provider in the field of IS-Revision and IS-Consulting

German Accreditation Body

Testing Laboratory for IT Quality: Competence for evaluations in the field of IT Ergonomics and IT Security, accredited according to DIN EN ISO/IEC 17025

Evaluation Body for IT Security: Accreditation for evaluations according to CC/CEM/ITSEC/ITSEM

Evaluation Body for IT Usability: Accreditation for evaluations according to DIN EN ISO 9241-110, DIN EN ISO 9241-11, DIN ISO/IEC 25051, DIN EN ISO 13407 and ISO 9241-210

Certification Body: Competence for certifications of products in the field of IT Security, accredited according to DIN EN 45011

Federal Network Agency

Confirmation Body according to Signatures Act/Signatures Ordinance for the confirmation of products for qualified electronic signatures

Confirmation Body according to Signatures Act/Signatures Ordinance for the confirmation of the implementation of security concepts for certification service providers

German Banking Industry Committee

Listed Testing Body for Electronic Payment Transactions


Independent Centre for Privacy Protection Schleswig-Holstein

Test Centre for Privacy (legal/technical)

EuroPriSe Experts (legal/technical)

Information-technology Promotion Agency, Japan

IT Security Evaluation Facility: Competence for evaluations according to CC/CEM

National Institute of Technology and Evaluation, Japan

Evaluation Body for IT Security: Accreditation according to DIN EN ISO/IEC 17025 in the field of IT / Common Criteria evaluations (Lab Code: ASNITE0019T)

National Institute of Standards and Technology, USA National Voluntary Laboratory Accreditation Program, USA

Evaluation Body for IT Security (NVLAP Lab Code: 200636-0) for Cryptographic Module Testing (scopes 17BCS, 17CAV/01, 17CMH1/01, 17CMH1/02, 17CMH2/01, 17CMH2/02, 17CMS1/01, 17CMS1/02, 17CMS2/01, 17CMS2/02) and Biometrics Testing

Europay, MasterCard and Visa, USA/United Kingdom/Japan

Full Service Laboratory for evaluations of ICs and IC cards according to EMVCo Security Guidelines

Visa, USA

Test House for performing Visa Chip Product security evaluations

MasterCard, United Kingdom

Accredited to perform CAST (Compliance Assessment and Security Testing) evaluations

Betaalvereniging Nederland, The Netherlands

Evaluation Laboratory


In the field of testing/evaluation services, TViT, as an independent authority, strengthens the adequate trust in quality, security and efficiency. Thus, TViT enhances the acceptance of products and systems as well as their operation in the financial sector, industry and public administration. In national and international research projects and bodies, TViT participates actively in developing the state of the technology.

Related to this is, for instance, TViT is involved in the shaping of auditing and certification practices according to IT-Grundschutz method of the Federal Office for Information Security and ISO/IEC 27001. TViT deploys auditors for IT-Grundschutz and ISO/IEC 27001.

TViT meets its customers high expectations with an active and responsive quality management system certified according to ISO 9001:2008.

Furthermore, TViT performs comprehensive training courses and consultancy for all eCompliance topics.


12 Links to the CC

[CC] Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 2, September 2007.

[CEM] Common Methodology for Information Technology Security Evaluation, Version 3.1, Revision 2, September 2007.

[ORG] www.commoncriteriaportal.org, official CC website.

[TViT] www.tuvit.de, English, German website of TViT

13 Glossary

BSI Bundesamt fr Sicherheit in der Informationstechnik (English: FOIS)

CC Common Criteria

CCRA Common Criteria Recognition Arrangement

CM Configuration Management

EAL Evaluation Assurance Level

ETR Evaluation Technical Report

FOIS Federal Office for Information Security (German: BSI)

IT Information Technology

PP Protection Profile

ST Security Target

TOE Target of Evaluation

SFR Security Functional Requirement

TSF TOE Security Functionality

TViT TV Informationstechnik GmbH


14 Annex: Selected References

The following table lists ongoing or already completed projects of TViT, Division Information Security.

These projects have been and are performed by the Evaluation Body for IT Security, which is an independent organizational unit within TViT and in charge of conducting security evaluations according to CC, ITSEC and FIPS PUB 140-2. This Evaluation Body engages more than 35 evaluators, all accredited and licensed to work on CC evaluation and certification projects.

CLIENT PRODUCT TYPE/LEVEL CERTIFIER CC Product Evaluation

GEMPLUS S.A., FRANCE

JAVA smart card operating system

CC EAL5+ BSI

GIESECKE & DEVRIENT (G&D)

ePassport BAC operating system

CC EAL4+ BSI

GIESECKE & DEVRIENT (G&D)

Smart card operating system (native)

CC EAL4+ BSI

HITACHI, LTD., JAPAN

Hacker Safe for Windows V1.1

CC EAL3 TViT

INFINEON TECHNOLOGIES

Smart card security controller SLE66CXxxxP/E-series

CC EAL5+ BSI

INFINEON TECHNOLOGIES TPM

2 device CC EAL4+ TViT

IT SOLUTION GMBH Electronic signature Component CC EAL3+ TViT

MICROSOFT CORPORATION

Exchange Server 2003 and 2007

CC EAL4+ BSI


Internet Security and Acceleration Server (ISA) 2004 and 2006

CC EAL4+ BSI

MICROSOFT CORPORATION SQL Server 2005

CC EAL4+ BSI


Internet Security and Acceleration Server (ISA) 2000

CC EAL2 BSI

ORGA Smart card operating system CC EAL5 TViT

PANASONIC Smart card security controllers MN67S140/360 CC EAL4+ BSI

RICOH, LTD., JAPAN Document storage system

CC EAL3 TViT

RICOH, LTD., JAPAN

Intelligent multifunctional printing system

CC EAL3 TViT

SAMSUNG ELECTRONICS. CO., LTD.

Smart card security controller S3CC9xx-series

CC EAL4+ and EAL5+

BSI

SCHWEERS INTEC Firmware Politess 600 handheld (ESIA) CC EAL1 TViT

T-SYSTEMS, ePassport BAC operating CC BSI

2 Trusted Platform Module


CLIENT PRODUCT TYPE/LEVEL CERTIFIER TELESEC system EAL4+ T-SYSTEMS, TELESEC

ePassport EAC operating system

CC EAL4+ BSI

VOICETRUST Biometric (Voice) Verification System CC EAL2 TViT

WINBOND TPM device CC EAL3+ TViT

CC Protection Profile (PP) BAROC Evaluation: Smart Card

Protection Profile, V1.2 (BSI-PP-0021)

EAL4 BSI

BAROC Evaluation: CC 3.1 Smart Card Protection Profile, V1.0 (BSI-CC-PP-0038) (CC3.1)

EAL4 BSI

BSI Preparation: PP for Biometric Verification Mechanisms, V1.04 (BSI-PP-0016)

EAL2 BSI

BSI Preparation: PP for Electronic Health Card Terminals (BSI-PP-0032)

EAL2 BSI

BSI Preparation: PP for Mobile Electronic Health Card Terminals (under preparation) (CC3.1)

EAL2 BSI

CEN/ISSS, EUROPE Evaluation: Signature Creation Device Protection Profiles (SSCD PP) (BSI-PP-0004/5/6)

EAL4+ BSI

HANSESTADT HAMBURG

Evaluation: Protection Profile Digitales Wahlstift System (Electronic Voting Pen System), V1.0.1 (BSI-PP-0031)

EAL2 BSI

SMART CARD SECURITY USER GROUP, EUROPE AND USA

Evaluation: SCSUG Protection Profile V3.0 (BSI-PP-0003)

EAL4+ BSI

TCG Evaluation: PC Client Specific Trusted Platform Module Family 1.2; Level 2 Version 1.1 (BSI-PP-0030) (CC3.1)

EAL4 BSI


CLIENT PRODUCT TYPE/LEVEL CERTIFIER CC Training

CHINA INFORMATION TECHNOLOGY SECURITY CERTIFICATION CENTER (CNITSEC)

CC Training CC EAL4/EAL5

NA

ELECTRONIC COMMERCE SECURITY TECHNOLOGY RESEARCH ASSOCIATION (ECSEC), JAPAN


NA

KOREA INFORMATION SECURITY AGENCY (KISA), KOREA


NA

STANDARDISATION, TESTING AND QUALITY CERTIFICATION (STQC) DIRECTORATE, INDIA

CC Training CC EAL2 - EAL4

NA

TELECOM TECHNOLOGY CENTER (TTC), TAIWAN

CC Training CC EAL2 - EAL4

NA

Table 3: References


15 Contact

Dipl.-Math. Wolfgang Peter

IT Security Director Evaluation Body IT Security TV Informationstechnik GmbH Member of TV NORD GROUP Langemarckstrasse 20 45141 Essen, Germany Phone: +49 201 8999-624 Fax: +49 201 8999-666 [email protected] www.tuvit.de

Version: 2.7