Protection Profile for UK Dual-Interface Authentication Card

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "Protection Profile for UK Dual-Interface Authentication Card"

Transcription

1 Protection Profile for UK Dual-Interface Authentication Card Version th July 2009 Reference: UNKT-DO-0002

2 Introduction This document defines a Protection Profile to express security, evaluation and certification requirements based on Common Criteria (ISO 15408) for a UK-issued dual (contact and contactless) interface card containing a Machine-Readable Travel Document (MRTD), a Cardholder Authentication Application (CAA), and possibly other applications. This Protection Profile captures security requirements that are in addition to those contained in separate protection profiles for security ICs [IC PP] and Machine-Readable Travel Documents [MRTD PP], and is therefore intended to apply to products that are also certified against these PPs.

3 Summary of Amendments Version July 2009 First issued version. Version 1-0 Page 3 of 38

4 0 Preface 0.1 Related Documents [9303] ICAO Doc 9303, Sixth Edition, Machine Readable Travel Documents Technical Report, PKI for Machine Readable Travel Documents Offering ICC Read-Only Access, Version - 1.1, Date - October 01, 2004, published by authority of the secretary general, International Civil Aviation Organization This document is also updated by supplementary documents. The latest at the time of writing being: Supplement to Doc 9303, Release 7, 19 November 2008, ISO/IEC JTC1 SC17 WG3/TF1 for ICAO-NTWG [CC/1] Common Criteria for Information Technology Security Evaluation Part 1: Introduction and General Model, CCMB , v3.1 Release 1, September 2006 [CC/2] Common Criteria for Information Technology Security Evaluation Part 2: Security functional components, CCMB , v3.1 Release 2, September 2007 [CC/3] Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components, CCMB , v3.1 Release 2, September 2007 [CCRA] [CEM] Arrangement on the Recognition of Common Criteria Certificates in the Field of Information Technology Security, May 2000 Common Methodology for Information Technology Security Evaluation: Evaluation Methodology, CCMB , v3.1 Release 2, September 2007 [JIL-AP] Application of Attack Potential to Smartcards, v2.5 Revision 1, April 2008, CCDB [MRTD PP] Machine Readable Travel Document with ICAO Application, Extended Access Control, BSI-PP-0026, v1.2, 19 th November 2007 [IC PP] Security IC Platform Protection Profile, Eurosmart, BSI-PP-0035, v1.0, 15 June 2007 Note that this PP is a version written for CC version 3.1. The previous version of the PP, written for CC version 2.3, is suitable as an alternative: Smartcard IC Platform Protection Profile, Eurosmart, BSI-PP-0002, v1.0, July Version 1-0 Page 4 of 38

5 [TR-03110] Technical Guideline Advanced Security Mechanisms for Machine Readable Travel Documents Extended Access Control (EAC), Version 1.11, 21 February 2008, TR-03110, Bundesamt für Sicherheit in der Informationstechnik (BSI) A reference of the form [REF, n] refers to section n of REF. 0.2 Glossary Term Application Authentication System Blocking History CAA Cardholder Authentication Application DIAC Meaning A unit of functionality and data that is loaded onto a smart card in order to meet one or more operational uses (e.g. identification and entitlement). An external system that requests authentication of the person who presents a DIAC, to demonstrate that this person is the rightful Cardholder. The Authentication System communicates with the CAA to request the authentication, and provides a challenge value to the CAA. The CAA, after determining that the correct PIN has been supplied by the Cardholder, will provide a cryptographic response incorporating the challenge (this represents the Cardholder authenticated status to the Authentication System). The Authentication System, on determining that the response is valid and correct, recognises the Cardholder as authenticated. A Cardholder Authentication Application will enter a blocked state when it receives a number of consecutive incorrect PIN values that exceeds a predefined threshold. When in the blocked state a CAA application will not respond to any requests for Cardholder authentication. The CAA leaves the blocked state (and therefore responds once more to Cardholder authentication requests) after it receives a valid unblock message from a PIN Unblocking Authority. Over its operational lifetime, a CAA will therefore have a sequence of transitions between blocked and unblocked states, and this sequence constitutes the Blocking History of that instance of the CAA. In order to prevent replay attacks, an unblock message must be specific to a point in the Blocking History. Cardholder Authentication Application an application present on the DIAC in order to authenticate a person who presents the card as the rightful Cardholder. When a correct PIN is entered in response to a prompt from the CAA then the CAA will in turn provide a response to a challenge from an Authentication System, and this response message communicates the authenticated status of the Cardholder to the Authentication System. See CAA. See Dual-Interface Authentication Card. Version 1-0 Page 5 of 38

6 Term Dual-Interface Authentication Card EAC Home Office IC ICAO Meaning The TOE for this protection profile, which is a smart card having both contact and contactless interfaces, and carrying at least an MRTD application and a Cardholder Authentication Application as described in this PP. Extended Access Control (see [TR-03110]). The UK Government department that sponsors and issues the DIAC. For these purposes the responsible agencies within the Home Office are the Identity and Passport Service and the UK Border Agency. Integrated Circuit International Civil Aviation Organisation for the purposes of this document this refers to the organisation that is responsible for issuing and maintaining the specifications for machine-readable travel documents (e.g. [9303]). MRTD Machine-Readable Travel Document (see [9303]). PIN ST TOE TSF Personal Identification Number a number allocated to a Cardholder to enable authentication of the Cardholder as the person identified by the details on the card (by entry of the PIN into an associated PINentry device at an Authentication System). Security Target an implementation-dependent statement of security needs for a specific identified TOE. ([CC/1]) Target of Evaluation a set of software, firmware and/or hardware possibly accompanied by guidance. ([CC/1]) The TOE for this protection profile is the DIAC. TOE Security Functionality a set consisting of all hardware, software, and firmware of the TOE that must be relied upon for the correct enforcement of the SFRs. ([CC/1]) For other Common Criteria (ISO 15408) terms see [CC/1], [CC/2], [CC/3], & [CEM]. For other terms related to machine-readable travel documents see [MRTD PP, 8] or [9303]. Version 1-0 Page 6 of 38

7 Table of Contents 1. Introduction PP Reference Information Introduction to the Protection Profile TOE Overview Characteristics of the Card Card Lifecycle Conformance Claims Security Problem Definition Assets Users & Subjects Human Users External IT Systems Subjects Organisational Security Policies P.MRTD_PP MRTD security evaluation P.IC_PP IC security evaluation P.CAA_Personal_Data Data protection in the Authentication System P.MRTD_Interface Threats T.CAA_Chip_ID Tracking of chip T.App_Data_Breach Unauthorised access to application data T.CAA_CH_Masquerade Cardholder masquerade T.CAA_Auth_Replay Replay of authentication status message T.CAA_PIN_Search Exhaustive search for PIN value T.CAA_Leakage Leakage of confidential CAA data Assumptions A.CAA_Personalisation Personalisation of the CAA...16 Version 1-0 Page 7 of 38

8 2.5.2 A.CAA_Operation Operation of the CAA infrastructure Security Objectives Security Objectives for the TOE O.App_Interfaces Application interface restrictions O.App_Segregation Application Segregation O.CAA_CH_Authentication CAA Cardholder authentication O.CAA_PIN_failures CAA PIN failures restriction O.CAA_Leak_Protect CAA data leakage protection Security Objectives for the Operational Environment OE.MRTD_PP MRTD PP certification requirement OE.IC_PP IC PP certification requirement OE.CAA_Personalisation CAA secure personalisation OE.CAA_Personal_Data Secure handling of CAA personal data OE.CAA_Operation Secure operation of the CAA infrastructure Security Objectives Rationale Security Requirements Security Functional Requirements Application interface restrictions Application Segregation PIN entry for Cardholder authentication Freshness and authenticity of Cardholder authentication response Cardholder Authentication Application blocking Side channel protection for CAA Fault-induction protection for CAA Security Functional Requirements Rationale SFR Dependencies Rationale SFRs and Objectives Rationale...33 Version 1-0 Page 8 of 38

9 4.3 Security Assurance Requirements Refinements of the Security Assurance Requirements Security Assurance Requirements Rationale...37 Version 1-0 Page 9 of 38

10 1. Introduction 1.1 PP Reference Information Title: Protection Profile for UK Dual-Interface Authentication Card Version number: 1-0 Sponsoring Organisation: UK Identity and Passport Service Technical editors: SiVenture Certification Body: CESG The minimum assurance level for this PP is EAL4 augmented with ALC_DVS.2 and AVA_VAN Introduction to the Protection Profile This protection profile describes the requirements for a UK-issued, dual-interface (contact and contactless) smart card containing at least two applications: a machine-readable travel document (epassport) and a Cardholder Authentication Application (these applications are discussed in more detail in section 1.3.1). This is referred to here as the Dual-Interface Authentication Card (DIAC). The security evaluation requirements for a machine-readable travel document are specified in [MRTD PP], and the DIAC follows the same lifecycle, but with extensions needed to cover the development, installation and personalisation of the additional application (CAA) covered in this PP (see section 1.3.2). The DIAC also has additional requirements for segregation of applications in the multi-application environment, and for the essential security properties of the Cardholder Authentication Application. The DIAC therefore requires and assumes conformance with [MRTD PP] as well as with this Protection Profile (this requirement is expressed as P.MRTD_PP in section 2.3.1). The TOE for this PP is a dual-interface card, having both contact and contactless interfaces, whereas [MRTD PP] assumes only a contactless interface. Because the security of both interfaces is significant in this case, the DIAC also requires that the IC used has been certified to be conformant with the Security IC Platform Protection Profile [IC PP], with both interfaces included in the scope of the evaluation. Since [IC PP] does not specify requirements for cryptographic functions, the IC used for the DIAC is also required to include any cryptographic functions used for the DIAC that are implemented in hardware within the scope of this IC evaluation against [IC PP] (these requirements are expressed as P.IC_PP in section 2.3.2). Version 1-0 Page 10 of 38

11 1.3 TOE Overview Characteristics of the Card The DIAC is a multi-application dual-interface smart card containing at least: An international machine-readable travel document (MRTD) application implementing Extended Access Control according to [TR-03110] and accessed only via the contactless interface. This application will be used both for national identity verification within the UK and for international travel within the EU. A Cardholder Authentication Application accessed only via the contact interface, and requiring the Cardholder to enter a PIN in order to enable the card to engage in a challenge-response protocol with a host system, thus authenticating the Cardholder. This application will be used as a means of establishing identity to UK government. Other applications may also be present on the card, and there is therefore an essential requirement for segregation of applications so that no application has unauthorised access to the resources of any other application Card Lifecycle The TOE lifecycle is essentially the same as that in [MRTD PP], which divides the lifecycle into 4 phases. These phases are listed below with the extensions needed to deal with the Cardholder Authentication Application (CAA). Phase 1 Development: this is extended to include the development of the CAA. Phase 2 Manufacturing: this is extended to include creation of the CAA Phase 3 Personalisation of the MRTD: this is extended to include personalisation of the CAA, which will include writing any Cardholder-specific data for this application. Phase 4 Operational Use: this is extended to include use and maintenance of the CAA (e.g. preparation and distribution of CAA unblock messages). Cryptographic keys for CAA and the Cardholder PIN value will be inserted into the TOE during one or more of these phases, and the relevant data and phases should be identified in Security Targets claiming conformance with this PP. It will be decided by the Issuer, on the basis of the mapping of CAA application creation and personalisation to the phases above, which phases will be in the scope of the evaluation of an individual TOE. 1.4 Conformance Claims This Protection Profile is conformant to the Common Criteria version 3.1 revision 2. It is CC Part 2 conformant and CC Part 3 conformant. Version 1-0 Page 11 of 38

12 The Protection Profile requires demonstrable conformance according to the definition in [CC/1, Annex D.2], for any ST or PP claiming conformance to this PP. This PP does not claim conformance to any other PP. However, it assumes that it is used in conjunction with the Machine-Readable Travel Document Protection Profile [MRTD PP] and the Security IC Protection Profile [IC PP]. Version 1-0 Page 12 of 38

13 2. Security Problem Definition Since the DIAC assumes that the TOE is also certified to be conformant with [MRTD PP] and [IC PP], parts of the security problem related to those Protection Profiles are not repeated here, however the requirement for conformance with these protection profiles is established by organisational security policies (see section 2.3). The security problem definition below focuses on the additional aspects of the security problem arising from the multi-application environment and the Cardholder Authentication Application. 2.1 Assets The assets to be protected by the TOE are as follows. Application data The DIAC contains multiple applications, and each application must have control over its own data. The operating system itself will also have data that must not be accessible to the applications, and in this sense the operating system is considered as another application with its own application data. Application data must be protected against unauthorised attempts to read, modify, or use 1 the data. For the CAA application in particular, the application data will include cryptographic keys used in the challenge-response protocol with the Authentication System (cf. section 4.1.4), keys used to protect unblocking messages (cf. section 4.1.5), any other keys used to protect PIN values, and the Cardholder s correct PIN value). Cardholder authenticated status When a Cardholder has supplied a correct PIN during the current session 2, the Cardholder Authentication Application is used to communicate an authenticated status to an external Authentication System. This authenticated status is itself an asset that would be useful to an attacker. 2.2 Users & Subjects Users of the TOE are either authorised human users, or external IT systems. Subjects are the active components of the TOE that act on behalf of users. 1 Use of data here means that the data may be used without necessarily being known: for example, a private key might be used to sign data, imparting it with an undeserved appearance of authenticity, without the key being known. 2 A session is defined for these purposes as, at a maximum, the period during which the DIAC remains inserted into a smart card reader. A session may also be shorter than this (e.g. a period between resets even though the card remains in the reader). Version 1-0 Page 13 of 38

14 2.2.1 Human Users Cardholder Issuer The Cardholder is the rightful holder of the DIAC, for whom the Issuer personalised the card. The Issuer represents the organisations and individuals involved in personalising and issuing the DIAC 3. In particular, this involves personalising and issuing the Cardholder Authentication Application External IT Systems Authentication System PIN Unblocking Authority An external system that requests authentication of the person who presents a DIAC, to demonstrate that this person is the rightful Cardholder. The Authentication System communicates with the CAA to request the authentication, and provides a challenge value to the CAA. The CAA, after determining that the correct PIN has been supplied by the Cardholder, will provide a cryptographic response incorporating the challenge (this represents the Cardholder authenticated status to the Authentication System). The Authentication System, on determining that the response is valid and correct, recognises the Cardholder as authenticated. An external system that generates unblocking messages for CAAs that have been blocked due to exceeding the defined threshold for receipt of consecutive incorrect PIN values. The unblocking messages are cryptographically protected to enable the receiving CAA to recognise that they are authentic (i.e. that they originate from the PIN Unblocking Authority), fresh (i.e. that it has been produced for a specific instance of the CAA and to address a specific blocked state in the Blocking History of a specific CAA instance) Subjects Application The DIAC contains at least two separate applications: the MRTD application and the Cardholder Authentication Application. The operating system may also be treated as an application in the context that it may authorise access to its own data to other applications (the operating system has, by definition, authorised access to all other applications data). 3 In this respect the Issuer may correspond in certain ways with the Personalisation Agent and/or Manufacturer defined for the MRTD in [MRTD PP, 3.1]. Version 1-0 Page 14 of 38

15 2.3 Organisational Security Policies P.MRTD_PP MRTD security evaluation The TOE is required to be certified for conformance with the Machine-Readable Travel Document Protection Profile [MRTD PP], or whatever equivalent may be approved by the UK Home Office at the time of card issuance. It is noted that [MRTD PP] is based on Common Criteria version 2.3, whereas the current PP uses version 3.1. However, since assurance levels are accepted as being equivalent between the two versions, this does not raise any compatibility problems for the DIAC P.IC_PP IC security evaluation The IC used in the TOE is required to be certified to be conformant with the Security IC Platform Protection Profile [IC PP], or whatever equivalent may be approved by the UK Home Office at the time of card issuance. Both contact and contactless interfaces and all hardware cryptographic functions used in the TOE are required to be in the scope of the evaluation against [IC PP] 4. It is noted that [IC PP] is based on Common Criteria version 3.1, but that an earlier version of that PP based on Common Criteria version 2.3 is also available (see section 0.1). Since assurance levels are accepted as being equivalent between the two versions of Common Criteria, either of these versions of [IC PP] is acceptable for the DIAC P.CAA_Personal_Data Data protection in the Authentication System It is required that the Authentication System protects any of the Cardholder s personal data that it receives, against unauthorised disclosure, modification or use P.MRTD_Interface It is required that the MRTD application is available only over the contactless interface of the DIAC. 2.4 Threats The threats to the TOE are defined as follows. 4 It is possible that the cryptographic functions may have been included in a different certification, such as the certification of an operating system, but not in the IC certification. In this case, the separate certification is acceptable provided that it covers the precise cryptographic functions used in implementing the CAA and any supporting functions examined during vulnerability analysis of the DIAC. Version 1-0 Page 15 of 38

16 2.4.1 T.CAA_Chip_ID Tracking of chip An attacker may use data provided by the CAA to trace the movements of the Cardholder from a distance. The attacker cannot read the data printed on the DIAC, and does not know in advance the details of the DIAC. (This threat extends T.Chip_ID in [MRTD PP] to cover data available from the CAA.) T.App_Data_Breach Unauthorised access to application data An application on the DIAC may gain unauthorised access to the executable code or data of another application on the DIAC T.CAA_CH_Masquerade Cardholder masquerade An attacker may obtain Cardholder authenticated status from the CAA, without correctly authenticating, in order to masquerade as the Cardholder T.CAA_Auth_Replay Replay of authentication status message An attacker may replay to the Authentication System previous authentication details from the CAA in order to misleadingly appear to have Cardholder authenticated status T.CAA_PIN_Search Exhaustive search for PIN value An attacker may attempt to obtain Cardholder authenticated status from the CAA by repeatedly entering possible PIN values for verification by the CAA T.CAA_Leakage Leakage of confidential CAA data Confidential application data held by the CAA (such as private or secret keys, or the Cardholder s correct PIN value) may be revealed to an attacker via side channels (such as timing, power or electromagnetic emanations analysis) or by fault induction attacks. (This threat extends T.Information_Leakage and T.Malfunction in [MRTD PP] to cover secret data used by the CAA.) 2.5 Assumptions A.CAA_Personalisation Personalisation of the CAA It is assumed that the Cardholder Authentication Application is correctly and securely loaded and personalised on the DIAC. This includes loading the relevant keys and PIN value, as well as the personal details of the Cardholder. All of these details must be generated, stored and used (e.g. during the personalisation process) in ways that provide adequate protection against disclosure, modification or unauthorised use. Version 1-0 Page 16 of 38

17 2.5.2 A.CAA_Operation Operation of the CAA infrastructure It is assumed that the infrastructure for the Cardholder Authentication Application is correctly and securely operated. In particular, the following assumptions are made: unblock messages are only issued under authorised circumstances, and applicable to the current point in the Blocking History of a target CAA instance the infrastructure will enable any required confirmation that a Cardholder authenticated status received from a DIAC is not only fresh but current 5 applications on the DIAC will only be loaded or deleted under the control of the Home Office; any applications approved for load will be reviewed for their security impact on the DIAC, and appropriate measures put in place to preserve the authenticity and integrity of the reviewed application. 5 The freshness of a Cardholder authenticated status means that it applies to the relevant point in the history of the CAA, i.e. the point at which the Cardholder entered a correct PIN in response to the request from the CAA. For the status to be current, it must have been generated at the point in time appropriate to the need for the authentication context in which the status is being used (and not, for example, generated but not used previously and then received and used by the Authentication System in a different context). Version 1-0 Page 17 of 38

18 3. Security Objectives 3.1 Security Objectives for the TOE The Security Objectives for the TOE are defined as follows O.App_Interfaces Application interface restrictions The MRTD application shall be available only over the contactless interface of the DIAC, and the CAA shall be available only over the contact interface of the DIAC O.App_Segregation Application Segregation The DIAC shall provide segregation of applications such that no application can gain unauthorised access to the code or data of another application O.CAA_CH_Authentication CAA Cardholder authentication The CAA shall require the Cardholder to enter a PIN assigned by the Issuer in order to achieve Cardholder authenticated status. On receipt of the correct PIN value from the Cardholder, the CAA shall report the Cardholder authenticated status to the Authentication System in a manner that demonstrates the authenticity and freshness of the status message O.CAA_PIN_failures CAA PIN failures restriction After receiving a defined number of consecutive incorrect PIN values for authentication, the CAA shall enter a blocked state in which it will not perform Cardholder authentication until after it has received a valid unblock message. (The blocked state shall not affect the functionality of the MRTD application.) After receiving the unblock, the CAA shall return to its normal state and shall provide Cardholder authentication O.CAA_Leak_Protect CAA data leakage protection The DIAC shall protect secret data (including private or secret keys, and the Cardholder s correct PIN value) from being revealed via side channels (such as timing, power or electromagnetic emanations analysis) or by fault induction attacks. 6 The authenticity of the message means that it applies to the claimed Cardholder and originates from the claimed card. The freshness of the messages means that it applies to the relevant (i.e. current) point in the history of the CAA. Version 1-0 Page 18 of 38

19 3.2 Security Objectives for the Operational Environment OE.MRTD_PP MRTD PP certification requirement The TOE shall be certified for conformance with the Machine-Readable Travel Documents Protection Profile [MRTD PP], or whatever equivalent may be approved by the UK Home Office at the time of card issuance OE.IC_PP IC PP certification requirement The IC used in the TOE is required to be certified for conformance with the Security IC Platform Protection Profile [IC PP], or whatever equivalent may be approved by the UK Home Office at the time of card issuance. Both contact and contactless interfaces and all hardware cryptographic functions used in the TOE are required to be in the scope of the evaluation against [IC PP] OE.CAA_Personalisation CAA secure personalisation The Issuer shall ensure that the Cardholder Authentication Application is correctly and securely loaded and personalised on the DIAC. This includes loading the relevant keys and PIN value, as well as the personal details of the Cardholder. All of these details shall be generated, stored and used (e.g. during the personalisation process) in ways that provide adequate protection against disclosure, modification or unauthorised use OE.CAA_Personal_Data Secure handling of CAA personal data The Authentication System and its operators shall protect any of the Cardholder s personal data that it receives against unauthorised disclosure, modification or use OE.CAA_Operation Secure operation of the CAA infrastructure The infrastructure for the Cardholder Authentication Application shall be correctly and securely operated. In particular: unblock messages shall only be issued under authorised circumstances, and applicable to the current point in the Blocking History of a target CAA instance the infrastructure shall enable any required confirmation that a Cardholder authenticated status received from a DIAC is not only fresh but current 5 applications on the DIAC shall only be loaded or deleted under the control of the Home Office; any applications approved for load shall be reviewed for their security impact on 7 As noted for P.IC_PP in section 2.3.2, it is possible that the cryptographic functions may have been included in a different certification, such as the certification of an operating system, but not in the IC certification. In this case, the separate certification is acceptable provided that it covers the precise cryptographic functions used in implementing the CAA and any supporting functions examined during vulnerability analysis of the DIAC. Version 1-0 Page 19 of 38

20 the DIAC, and appropriate measures shall be put in place to preserve the authenticity and integrity of the reviewed application. 3.3 Security Objectives Rationale P.MRTD_PP is addressed by OE.MRTD_PP, which specifically requires that the DIAC must also be certified to be conformant with [MRTD PP] or an approved equivalent. Note that some threats in the current PP are related to threats in [MRTD PP] 8 : T.CAA_Chip_ID extends T.Chip_ID in [MRTD PP] to cover data available from the CAA which might also be used to track a Cardholder T.CAA_Leakage extends T.Information_Leakage and T.Malfunction in [MRTD PP] to cover the application of side channel and fault induction attacks to secret data used by the CAA. P.IC_PP is addressed by OE.IC_PP, which specifically requires that the DIAC must also be certified to be conformant with [IC PP] or an approved equivalent. Note that some threats in the current PP are related to threats in [IC PP], in particular T.CAA_Leakage extends T.Leak- Inherent, T.Leak-Forced, and T.Malfunction in [IC PP] 8. P.CAA_Personal_Data is addressed by OE.CAA_Personal_Data, which specifically requires protection of the relevant personal data in the operation of the Authentication System. P.MRTD_Interface is addressed by O.App_Interfaces, which ensures that the MRTD application is only available over the contactless interface of the DIAC. T.CAA_Chip_ID is addressed by O.App_Interfaces, which ensures that the CAA is only available by using the contact interface of the DIAC. This means that an attacker cannot trace the movements of the Cardholder by using the CAA from a distance. T.App_Data_Breach is addressed by O.App_Segregation, which requires that the TOE provides segregation between applications such that unauthorised access from one application to the code or data of another is not permitted. T.CAA_CH_Masquerade is addressed by O.CAA_CH_Authentication, which sets a basic requirement for Cardholder to enter a correct PIN value before Cardholder authenticated status is granted by the CAA. 8 The threats identified in the rationale for P.MRTD_PP represent those threats for which the additional presence of the CAA introduces new potential sources of vulnerabilities that would not have been considered during an evaluation against [MRTD PP]. In particular, the CAA adds the potential for different identification data that might be used to track a user hence the spirit of T.Chip_ID in [MRTD] needs to be extended with T.CAA_Chip_ID here. CAA also adds different embedded software, using different secret data, and hence provides the potential for new sources of side channel and fault induction attacks hence T.Information_Leakage and T.Malfunction in [MRTD] need to be extended with T.CAA_Leakage. Other threats in [MRTD PP] relating to physical attacks on the chip, such as T.Abuse_Func and T.Phys_Tamper are generic threats: their assessment against the original PP does not depend on the embedded software that operates on the device. Hence these threats do not need to be extended in this PP. A similar argument applies to threats in [IC PP]. Version 1-0 Page 20 of 38

21 T.CAA_Auth_Replay is also addressed by O.CAA_CH_Authentication, which requires that the message conveying the Cardholder authenticated status to the Authentication System implements a method to demonstrate freshness of the message hence any replayed message would be detected by the Authentication System. T.CAA_PIN_Search is addressed by O.CAA_PIN_failures, which requires that the DIAC limits the number of consecutive failed authentication attempts that it will accept. OE.CAA_Operation ensures that unblock messages (that could allow an attacker to continue entering PIN attempts by unblocking the application whenever it blocks) are suitably controlled. T.CAA_Leakage is addressed by O.CAA_Leak_Protect, which requires the DIAC to implement suitable countermeasures against side channel and fault induction attacks 9. A.CAA_Personalisation is addressed by OE.CAA_Personalisation, which specifically requires correct and secure personalisation of the CAA. A.CAA_Operation is addressed by OE.CAA_Operation, which specifically requires correct and secure operation of the CAA infrastructure. The table below summarises the mappings to security objectives in the rationale above. Assumption, Threat or Organisational Security Policy P.MRTD_PP P.IC_PP P.CAA_Personal_Data P.MRTD_Interface T.CAA_Chip_ID T.App_Data_Breach T.CAA_CH_Masquerade T.CAA_Auth_Replay T.CAA_PIN_Search T.CAA_Leakage Security Objective OE.MRTD_PP OE.IC_PP OE.CAA_Personal_Data O.App_Interfaces O.App_Interfaces O.App_Segregation O.CAA_CH_Authentication O.CAA_CH_Authentication O.CAA_PIN_failures OE.CAA_Operation O.CAA_Leak_Protect 9 In general this will require the CAA to follow guidance for programmers provided for the operating system and/or the IC. Version 1-0 Page 21 of 38

22 Assumption, Threat or Organisational Security Policy A.CAA_Personalisation A.CAA_Operation Security Objective OE.CAA_Personalisation OE.CAA_Operation Version 1-0 Page 22 of 38

23 4. Security Requirements 4.1 Security Functional Requirements The security functional requirements are structured as follows: Application interface restrictions: the requirements to use the MRTD application only over the contactless interface and the CAA only over the contact interface are expressed as information flow rules (FDP_IFC.1/App_IF and FDP_IFF.1/App_IF) Application segregation: this is expressed as an access control rule (FDP_ACF.1/Multi- App), with a management function in FMT_MOF.1/Multi-App to represent any ability to authorise inter-application access authorisation CAA functional requirements: these are divided into 3 aspects: o PIN entry for Cardholder authentication (FIA_UAU.1/CAA) o Freshness and authenticity of the Cardholder authentication response message (FDP_DAU.1/CAA) o CAA blocking (FIA_AFL.1/CAA), Side channel protection for the CAA (FDP_IFC.1/CAA) Fault-induction protection for the CAA (FPT_FLS.1/CAA and FRU_FLT.2/CAA). In the statements of security functional requirements, the requirement text is taken from [CC/2], and the following conventions are adopted: Where SFRs have been completed, the convention in [MRTD PP] is used: completion text is underlined and the original SFR operation text is recorded in a footnote Where refinements have been made that change the text of an SFR, these are indicated by using bold font. Other refinements (to the meaning of the SFR) are described under a Refinement heading Application interface restrictions FDP_IFC.1/App_IF Hierarchical to: Dependencies: Subset information flow control No other components. FDP_IFF.1 Simple security attributes Version 1-0 Page 23 of 38

24 FDP_IFC.1.1/App_IF The TSF shall enforce the Application Interface SFP 10 on subjects: MRTD application, CAA objects: interface used for communication with external entities operations: all communication between the MRTD application and external entities, and between CAA and external entities 11. FDP_IFF.1/App_IF Hierarchical to: Dependencies: Simple security attributes No other components. FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute initialisation FDP_IFF.1.1/App_IF The TSF shall enforce the Application Interface SFP 12 based on the following types of subject and information security attributes: subjects: MRTD application, CAA information: all data communicated between the MRTD application and external entities, and between the CAA and external entities attributes: interface used for communication with external entities 13. FDP_IFF.1.2/App_IF The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: communications between external entitiesand the MRTD application shall take place only over the contactless interface (and not the contact interface) of the DIAC communications between external entitiesand the CAA shall take place only over the contact interface (and not the contactless interface) of the DIAC 14. FDP_IFF.1.3/App_IF The TSF shall enforce the [assignment: additional information flow control SFP rules]. 10 [assignment: information flow control SFP] 11 [assignment: list of subjects, information, and operations that cause controlled information to flow to and from controlled subjects covered by the SFP] 12 [assignment: information flow control SFP] 13 [assignment: list of subjects and information controlled under the indicated SFP, and for each, the security attributes] 14 [assignment: for each operation, the security attribute-based relationship that must hold between subject and information security attributes] Version 1-0 Page 24 of 38

25 FDP_IFF.1.4/App_IF The TSF shall explicitly authorise an information flow based on the following rules: [assignment: rules, based on security attributes, that explicitly authorise information flows]. FDP_IFF.1.5/App_IF The TSF shall explicitly deny an information flow based on the following rules: [assignment: rules, based on security attributes, that explicitly deny information flows]. Application Note: The communications in FDP_IFF.1.2/App_IF relate to communications with external entities and do not include any authorised communications between applications (or between an application and the operating system) on the card (such communications would use internal communications channels mediated by the operating system) Application Segregation The following SFRs express the requirement that an application s data should only be accessible to another application if there has been an authorisation step that allows this 15. FDP_ACC.1/Multi-App Hierarchical to: Dependencies: Subset access control No other components. FDP_ACF.1 Security attribute based access control FDP_ACC.1.1/Multi-App The TSF shall enforce the Application Segregation SFP 16 on subjects: Applications objects: all application data operations: all 17. FDP_ACF.1/Multi-App Hierarchical to: Dependencies: Security attribute based access control No other components. FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation FDP_ACF.1.1/Multi-App The TSF shall enforce the Application Segregation SFP 18 objects based on the following: to 15 The mechanism for authorisation is not specified here in order not to unnecessarily constrain implementations. 16 [assignment: access control SFP] 17 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] Version 1-0 Page 25 of 38

26 subjects: Applications information: all application data attributes: owner of the data 19. FDP_ACF.1.2/Multi-App The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: access for any operation, by any application to code or data owned by another application shall only be possible if the accessing application has been explicitly authorised for access to the code or data for the operation concerned 20. FDP_ACF.1.3/Multi-App The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]. FDP_ACF.1.4/Multi-App The TSF shall explicitly deny access of subjects to objects based on the [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]. Application Note: Every item of data shall have an application owner (the owner of an application s code is taken to be the application itself). The method of authorisation should be identified in a Security Target in an Application Note. FMT_MOF.1/Multi-App Hierarchical to: Dependencies: Management of security functions behaviour No other components. FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions FMT_MOF.1.1/Multi-App The TSF shall restrict the ability to enable 21 the function authorisation of an application to access the code or data of another application 22 to [assignment: the authorised identified roles]. 18 [assignment: access control SFP] 19 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes] 20 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects] 21 [selection: determine the behaviour of, disable, enable, modify the behaviour of] 22 [assignment: list of functions] Version 1-0 Page 26 of 38

27 Application Note: An implementation of the DIAC may use static properties in the implementation of application segregation. For example, the implementation might prevent any access to the code or data of another application. In this case the final assignment of a role in FMT_MOF.1/Multi-App in the ST may be completed with None. The role might alternatively be an off-card role that is not represented by a user or subject defined in this PP (see section 2.2), in which case the ST should add the relevant role as an additional type of user or subject (this applies even if the role is only active during initial creation of the TOE and has no separate role during the operational lifetime of the DIAC) PIN entry for Cardholder authentication The SFR below deals with the use of the CAA to provide Cardholder authentication by means of PIN entry. The usual use of this SFR in CC would be as a precursor to giving a user access to other TOE functions, but in this case the authentication is provided by the TOE as a service, and hence the first part of the SFR does not require the TOE to prevent access to other operations before authentication using the CAA (indeed, it must not prevent access to other functions such as the MRTD authentication functions). A refinement is added to the SFR text since this iteration of the SFR applies only to the CAA (a separate use of FIA_UAU.1 is found in [MRTD PP]). FIA_UAU.1/CAA Hierarchical to: Dependencies: Timing of authentication No other components. FIA_UID.1 Timing of identification FIA_UAU.1.1/CAA The TSF shall allow any TOE operation except provision of a PIN check response by the CAA 23 on behalf of the user to be performed before the user is authenticated by the Cardholder Authentication Application. FIA_UAU.1.2/CAA The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. Application Note: This SFR refers to the use of a PIN verification check by the CAA, which then provides a Cardholder authenticated message intended for the Authentication System, rather than for the TOE. Hence any TOE operation is allowed before PIN authentication, except for an operation that would send a response indicating the result of a PIN check operation. For the purposes of FIA_UAU.1.2/CAA therefore, the only TSF-mediated action remaining is the provision of a PIN check response. 23 [assignment: list of TSF mediated actions] Version 1-0 Page 27 of 38

28 4.1.4 Freshness and authenticity of Cardholder authentication response FDP_DAU.1/CAA Hierarchical to: Dependencies: Basic Data Authentication No other components. No dependencies. FDP_DAU.1.1/CAA The TSF shall provide a capability to generate evidence that can be used as a guarantee of the validity of PIN verification responses from the Cardholder Authentication Application 24. FDP_DAU.1.2/CAA The TSF shall provide the Authentication System 25 with the ability to verify evidence of the validity of the indicated information. Refinement: Validity in this case means the authenticity of the message (to prove that the response comes from a specific, genuine CAA) and freshness (to prove that the message applies to the relevant (i.e. current) point in the history of the CAA) Cardholder Authentication Application blocking This SFR deals with the blocking of the CAA after a number of consecutive PIN verification failures. FIA_AFL.1/CAA Hierarchical to: Dependencies: Authentication failure handling No other components. FIA_UAU.1 Timing of authentication FIA_AFL.1.1/CAA The TSF shall detect when [assignment: number less than or equal to 9] 26 unsuccessful authentication attempts occur related to PIN verification by the Cardholder Authentication Application 27. FIA_AFL.1.2/CAA When the defined number of unsuccessful authentication attempts has been surpassed 28, the TSF shall block the Cardholder Authentication Application and prevent 24 [assignment: list of objects or information types] 25 [assignment: list of subjects] 26 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] 27 [assignment: list of authentication events] 28 [selection: met, surpassed] Version 1-0 Page 28 of 38

29 further PIN verification attempts until after the receipt of an authentic, fresh unblock message 29. Application Note: Only the CAA is blocked when the threshold is exceeded: the MRTD application, for example, shall be unaffected. The unblock message shall be authentic in the sense that the card can prove that it comes from a genuine PIN Unblocking Authority, and fresh in the sense that the CAA can prove that the message applies to the current point in its own Blocking History (and therefore has not been replayed, nor was it originally intended for a different instance of the CAA) Side channel protection for CAA Side channels represent ways in which the PIN value, or a cryptographic key value (or other confidential data item), may be gained by an attacker because of correlations between the value of the data item and some observable activity of the DIAC. Typically the observations are related to time taken for processing, power consumed, or electromagnetic radiation emitted. Since OE.IC_PP requires that the underlying IC has been certified against [IC PP] (including relevant cryptographic algorithms) then some of the side channel protection will have been assessed at the IC level. However, the inclusion of this SFR in the current PP is necessary because some side channel attacks are specific to the software being executed. In [MRTD PP], the danger of side channels is dealt with using the (part 2 extended) SFR FPT_EMSEC.1 for two specific assets: the Personalization Agent Authentication Key and the Chip Authentication Private Key. For the DIAC, protection needs to be applied to at least the PIN value and CAA (non-public) keys introduced to meet other SFRs in this PP (e.g. for proving the authenticity of PIN verification responses as in section and PIN unblock messages as in section 4.1.5). The extension in the current PP is made using an approach similar to that of [IC PP]: an information flow policy is defined that requires that confidential data is only to be revealed when (and if) the TOE intends to communicate it hence any leakage of confidential data would be in breach of the requirement. FDP_IFC.1/CAA Hierarchical to: Dependencies: Subset information flow control No other components. FDP_IFF.1 Simple security attributes FDP_IFC.1.1/CAA The TSF shall enforce the CAA Data Confidentiality Policy 30 on all confidential CAA data when they are processed or transferred internally by the TOE [assignment: list of actions] 30 [assignment: information flow control SFP] Version 1-0 Page 29 of 38

30 The CAA Data Confidentiality Policy is defined as follows: CAA Data Confidentiality Policy: CAA data required to remain confidential (in order for the CAA to successfully implement the SFRs) shall not be accessible from the TOE except when (and if) the TOE software decides to communicate the data via an external interface. The protection shall be applied to confidential data only but without reference to attributes controlled by the TOE software. Application Note: The confidential data for the CAA would typically include the Cardholder PIN value, and non-public cryptographic keys to support the freshness and authenticity of both PIN verification check responses (see FDP_DAU.1/CAA in section 4.1.4) and PIN unblock messages (see FIA_AFL.1/CAA in section 4.1.5) Fault-induction protection for CAA Confidential data items may be compromised by inducing faults in the operation of the DIAC, so that software execution leads to the secret value being exposed as a result of the faulty behaviour, whether directly (e.g. because the secret value is erroneously transmitted unencrypted over an interface) or indirectly (e.g. where mathematical analysis of erroneous encryption results may enable the unencrypted value to be found). The following SFRs are used in the same way as in [IC PP], and require protection against fault-induction attacks to be extended to cover the Cardholder Authentication Application. The essence of the approach is (as described in [IC PP, 6.1]) that FPT_FLS.1 ensures that when the TOE is taken outside its usable limits then it fails securely, while FRU_FLT.2 ensures that when operating within its usable limits then the TOE will handle induced faults (which might include voltage, frequency, or laser-induced faults) securely. Since OE.IC_PP requires that the underlying IC has been certified against [IC PP] then much of the routine fault-resistance will have been assessed for the IC. However, the inclusion of these SFRs in the current PP is necessary because some fault induction attacks are specific to the software being executed (CAA in this case 32 ). FPT_FLS.1/CAA Hierarchical to: Dependencies: Failure with preservation of secure state No other components. No dependencies. FPT_FLS.1.1/CAA The TSF shall preserve a secure state when the following types of failures occur: exposure to operating conditions which may not be tolerated according to the 31 [assignment: list of subjects, information, and operations that cause controlled information to flow to and from controlled subjects covered by the SFP] 32 [MRTD PP] also includes FPT_FLS.1 applied to the MRTD application. Version 1-0 Page 30 of 38

EPASSPORT WITH BASIC ACCESS CONTROL AND ACTIVE AUTHENTICATION

EPASSPORT WITH BASIC ACCESS CONTROL AND ACTIVE AUTHENTICATION COMMON CRITERIA PROTECTION PROFILE EPASSPORT WITH BASIC ACCESS CONTROL AND ACTIVE AUTHENTICATION Draft Version 1.0 TURKISH STANDARDS INSTITUTION TABLE OF CONTENTS Common Criteria Protection Profile...

More information

Mobile Billing System Security Target

Mobile Billing System Security Target Mobile Billing System Security Target Common Criteria: EAL1 Version 1.2 25 MAY 11 Document management Document identification Document ID Document title Product version IDV_EAL1_ASE IDOTTV Mobile Billing

More information

Smartcard IC Platform Protection Profile

Smartcard IC Platform Protection Profile Smartcard IC Platform Protection Profile Version 1.0 July 2001 developed by Atmel Smart Card ICs Hitachi Europe Ltd. Infineon Technologies AG Philips Semiconductors Registered and Certified by Bundesamt

More information

Security IC Platform Protection Profile

Security IC Platform Protection Profile Security IC Platform Protection Profile Version 1.0 15.06.2007 developed by Atmel Infineon Technologies AG NXP Semiconductors Renesas Technology Europe Ltd. STMicroelectronics Registered and Certified

More information

CERTIFICATION REPORT

CERTIFICATION REPORT REF: 2011-11-INF-837 v1 Target: Público Date: 17.04.2012 Created by: CERT8 Revised by: CALIDAD Approved by: TECNICO CERTIFICATION REPORT File: 2011-11 KONA 102J1 epassport EAC v1.1 Applicant: KEBTechnology

More information

Common Criteria Protection Profile. Electronic Identity Card (ID_Card PP) BSI-CC-PP-0061. Approved by the Federal Ministry of Interior. Version 1.

Common Criteria Protection Profile. Electronic Identity Card (ID_Card PP) BSI-CC-PP-0061. Approved by the Federal Ministry of Interior. Version 1. Common Criteria Protection Profile Approved by the Federal Ministry of Interior Version 1.03, 1 Common Criteria Protection Profile Version 1.03, Foreword This Protection Profile is issued by Bundesamt

More information

MIFARE DESFire EV1 MF3ICD81

MIFARE DESFire EV1 MF3ICD81 MIFARE DESFire EV1 MF3ICD81 Rev.1.5 10 May 2011 BSI-DSZ-CC-0712 Evaluation Documentation Document information Info Keywords Abstract Content, MF3ICD81 Evaluation of the NXP Secure Smart Card Controller

More information

Common Criteria Protection Profile

Common Criteria Protection Profile Machine Readable Travel Document using Standard Inspection Procedure with PACE (PACE PP) Version 1.01, 22th July 2014 Foreword This Protection Profile Electronic Passport using Standard Inspection procedure

More information

Common Criteria Protection Profile for Inspection Systems (IS) BSI-CC-PP-0064. Version 1.01 (15 th April 2010)

Common Criteria Protection Profile for Inspection Systems (IS) BSI-CC-PP-0064. Version 1.01 (15 th April 2010) Common Criteria Protection Profile for BSI-CC-PP-0064 Version 1.01 (15 th April 2010) Federal Office for Information Security Postfach 20 03 63 53133 Bonn Phone: +49 228 99 9582-0 e-mail: zertifizierung@bsi.bund.de

More information

Supporting Document Guidance. Security Architecture requirements (ADV_ARC) for smart cards and similar devices. April 2012. Version 2.

Supporting Document Guidance. Security Architecture requirements (ADV_ARC) for smart cards and similar devices. April 2012. Version 2. Supporting Document Guidance Security Architecture requirements (ADV_ARC) for smart cards and similar devices April 2012 Version 2.0 CCDB-2012-04-003 Foreword This is a supporting document, intended to

More information

Joint Interpretation Library

Joint Interpretation Library for smart cards and similar devices Document purpose: provide requirements to developers and guidance to evaluators to fulfill the Security Architecture requirements of CC V3 ADV_ARC family. Version 2.0

More information

Cryptographic Modules, Security Level Enhanced. Endorsed by the Bundesamt für Sicherheit in der Informationstechnik

Cryptographic Modules, Security Level Enhanced. Endorsed by the Bundesamt für Sicherheit in der Informationstechnik Common Criteria Protection Profile Cryptographic Modules, Security Level Enhanced BSI-CC-PP-0045 Endorsed by the Foreword This Protection Profile - Cryptographic Modules, Security Level Enhanced - is issued

More information

Firewall Protection Profile V2.0 2008. 4. 24

Firewall Protection Profile V2.0 2008. 4. 24 Firewall Protection Profile V2.0 2008. 4. 24 (This page left blank on purpose for double-side printing) Protection Profile Title Firewall Protection Profile for Government Evaluation Criteria Version This

More information

Joint Interpretation Library. Security Evaluation and Certification of Digital Tachographs

Joint Interpretation Library. Security Evaluation and Certification of Digital Tachographs Joint Interpretation Library Security Evaluation and Certification of Digital Tachographs JIL interpretation of the Security Certification according to Commission Regulation (EC) 1360/2002, Annex 1B Version

More information

BSI-PP-0004-2002. for. Protection Profile Secure Signature-Creation Device Type 1, Version 1.05. developed by

BSI-PP-0004-2002. for. Protection Profile Secure Signature-Creation Device Type 1, Version 1.05. developed by BSI-PP-0004-2002 for Protection Profile Secure Signature-Creation Device Type 1, Version 1.05 developed by CEN/ISSS Information Society Standardization System, Workshop on Electronic Signatures - Bundesamt

More information

LEGIC advant Series. LEGIC card-in-card AFS4096-JP12 V1.2. Security Target Lite. Common Critera ISO 15408 EAL4+

LEGIC advant Series. LEGIC card-in-card AFS4096-JP12 V1.2. Security Target Lite. Common Critera ISO 15408 EAL4+ LEGIC advant Series Security Target Lite LEGIC card-in-card AFS4096-JP12 V1.2 Common Critera ISO 15408 EAL4+ Classification: Public Document No.: LA-23-615a-en / BSI-DSZ-CC-0812 Edition: 6.2012 www.legic.com

More information

Protection Profile for Portable Storage Media (PSMPP) Common Criteria Protection Profile BSI-CC-PP-0081-2012 Version 1.0

Protection Profile for Portable Storage Media (PSMPP) Common Criteria Protection Profile BSI-CC-PP-0081-2012 Version 1.0 Protection Profile for Portable Storage Media (PSMPP) Common Criteria Protection Profile BSI-CC-PP-0081-2012 Version 1.0 German Federal Office for Information Security PO Box 20 03 63 D-53133 Bonn Tel.:

More information

Low Assurance Protection Profile for a VPN gateway

Low Assurance Protection Profile for a VPN gateway LAPP VPN gateway Low Assurance Protection Profile for a VPN gateway Version: 1.4 Date: 29/04/2005 Filename: lapp4_14 Product: VPN gateway Sponsor: SRC Security Research & Consulting GmbH, Graurheindorfer

More information

Security Target. Astaro Security Gateway V8 Packet Filter Version 1.000. Assurance Level EAL4+ Common Criteria v3.1

Security Target. Astaro Security Gateway V8 Packet Filter Version 1.000. Assurance Level EAL4+ Common Criteria v3.1 Astaro Security Gateway V8 Packet Filter Version 1.000 Assurance Level EAL4+ Common Criteria v3.1 This Security Target also covers the secunet wall 2 packet filter Version : 1.03 Date: 2011-05-20 Author:

More information

Australasian Information Security Evaluation Program

Australasian Information Security Evaluation Program Australasian Information Security Evaluation Program Certification Report Certificate Number: 2010/70 23 November 2010 Version 1.0 Commonwealth of Australia 2010. Reproduction is authorised provided that

More information

EAL4+ Security Target

EAL4+ Security Target EAL4+ Security Target Common Criteria: EAL4 augmented with ALC_FLR.3 Version 1.0 21-DEC-10 Document management Document identification Document ID Document title Release authority E14_EAL4_ASE Microsoft

More information

C038 Certification Report

C038 Certification Report C038 Certification Report TAXSAYA Online File name: Version: v1a Date of document: 15 August 2013 Document classification: For general inquiry about us or our services, please email: mycc@cybersecurity.my

More information

Common Criteria Security Target For XenApp 6.0 for Windows Server 2008 R2 Platinum Edition

Common Criteria Security Target For XenApp 6.0 for Windows Server 2008 R2 Platinum Edition Common Criteria Security Target For XenApp 6.0 for Windows Server 2008 R2 Platinum Edition Version 1-0 7 February 2011 2011 Citrix Systems, Inc. All rights reserved. Summary of Amendments Version 1-0 7

More information

JMCS Northern Light Video Conferencing System Security Target

JMCS Northern Light Video Conferencing System Security Target JMCS Northern Light Video Conferencing System Security Target Common Criteria: EAL2 Version 1.2 22 FEB 12 Document management Document identification Document ID Document title Product version NLVC_ST_EAL2

More information

CardOS V4.4 CNS. Edition 04/2010. Security Target CardOS V4.4 CNS with Application for QES

CardOS V4.4 CNS. Edition 04/2010. Security Target CardOS V4.4 CNS with Application for QES CardOS V4.4 CNS Security Target CardOS V4.4 CNS with Application for QES Edition 04/2010 CardOS V4.4 CNS: ST Edition 04/2010 Public 1 The reproduction, transmission or use of this document or its contents

More information

Secuware Virtual System (SVS)

Secuware Virtual System (SVS) Secuware Virtual System (SVS) SECURITY TARGET EAL2 Copyright 2008 by SECUWARE All rights reserved. The information in this document is exclusive property of SECUWARE and may not be changed without express

More information

CERTIFICATION REPORT

CERTIFICATION REPORT REF: 2011-12-INF-1089 v1 Target: Expediente Date: 17.12.2012 Created by: CERT8 Revised by: CALIDAD Approved by: TECNICO CERTIFICATION REPORT File: 2011-12 POLYMNIE LDS BAC applet Applicant: B340709534

More information

Certification Report

Certification Report Bundesamt für Sicherheit in der Informationstechnik BSI-PP-0017-2005 Protection Profile for Machine Readable Travel Document with ICAO Application", Basic Access Control Version 1.0 developed on behalf

More information

Common Criteria for Information Technology Security Evaluation. Part 1: Introduction and general model. August 1999. Version 2.

Common Criteria for Information Technology Security Evaluation. Part 1: Introduction and general model. August 1999. Version 2. Common Criteria for Information Technology Security Evaluation Part 1: Introduction and general model August 1999 Version 2.1 CCIMB-99-031 Part 1: Introduction and general model Foreword This version of

More information

Certification Report - Firewall Protection Profile and Firewall Protection Profile Extended Package: NAT

Certification Report - Firewall Protection Profile and Firewall Protection Profile Extended Package: NAT Template: CSEC_mall_doc.dot, 7.0 Ärendetyp: 6 Diarienummer: 14FMV10188-21:1 Dokument ID CB-015 HEMLIG/ enligt Offentlighets- och sekretesslagen (2009:400) 2015-06-12 Country of origin: Sweden Försvarets

More information

IMPP. Identity Management Protection Profile BSI-PP-0024

IMPP. Identity Management Protection Profile BSI-PP-0024 Identity Management Protection Profile IMPP BSI-PP-0024 Version Number 1.17 Date: January 12, 2006 Status: Final Author: David Ochel Owner: Brian Matthiesen Note: This document will become a public document

More information

Firewall Protection Profile

Firewall Protection Profile samhällsskydd och beredskap 1 (38) ROS-ISÄK Ronny Janse 010-2404426 ronny.janse@msb.se Firewall Protection Profile samhällsskydd och beredskap 2 (38) Innehållsförteckning 1. Introduction... 4 1.1 PP reference...

More information

Protection Profile Secure Signature-Creation Device Type 3

Protection Profile Secure Signature-Creation Device Type 3 Protection Profile Secure Signature-Creation Device Type 3 Version: 1.05, EAL 4+ Wednesday, 25 July 2001 Prepared By: ESIGN Workshop - Expert Group F Prepared For: CEN/ISSS Note: This Protection Profile

More information

Korean National Protection Profile for Voice over IP Firewall V1.0 Certification Report

Korean National Protection Profile for Voice over IP Firewall V1.0 Certification Report KECS-CR-16-36 Korean National Protection Profile for Voice over IP Firewall V1.0 Certification Report Certification No.: KECS-PP-0717-2016 2016. 6. 10 IT Security Certification Center History of Creation

More information

Common Criteria Security Target

Common Criteria Security Target Common Criteria Security Target for Citrix XenDesktop 5.6 Platinum edition Version 1-1 16 November 2012 2012 Citrix Systems, Inc. All rights reserved Summary of Amendments Version Date Notes 1-1 16 November

More information

Common Criteria Protection Profile. electronic Health Card (ehc) elektronische Gesundheitskarte (egk)

Common Criteria Protection Profile. electronic Health Card (ehc) elektronische Gesundheitskarte (egk) electronic Health Card (ehc) elektronische Gesundheitskarte (egk) BSI-CC-PP-0020-V3-2010-MA-01 Approved by the Federal Ministry of Health Version 2.9, 19th April 2011 electronic Health Card Version 2.9,

More information

COMMON CERTIFICATE POLICY FOR THE EXTENDED ACCESS CONTROL INFRASTRUCTURE FOR PASSPORTS AND TRAVEL DOCUMENTS ISSUED BY EU MEMBER STATES

COMMON CERTIFICATE POLICY FOR THE EXTENDED ACCESS CONTROL INFRASTRUCTURE FOR PASSPORTS AND TRAVEL DOCUMENTS ISSUED BY EU MEMBER STATES COMMON CERTIFICATE POLICY FOR THE EXTENDED ACCESS CONTROL INFRASTRUCTURE FOR PASSPORTS AND TRAVEL DOCUMENTS ISSUED BY EU MEMBER STATES BSI TR-03139 Version 2.1 27 May 2013 Foreword The present document

More information

Network Intrusion Prevention System Protection Profile V1.1

Network Intrusion Prevention System Protection Profile V1.1 Network Intrusion Prevention System Protection Profile V1.1 December 21, 2005 (This page left blank on purpose for double-side printing) Protection Profile Title Network Intrusion Prevention System Protection

More information

Common Criteria Protection Profile Standard Reader - Smart Card Reader with PIN-Pad supporting eid based on Extended Access Control BSI-CC-PP-0083

Common Criteria Protection Profile Standard Reader - Smart Card Reader with PIN-Pad supporting eid based on Extended Access Control BSI-CC-PP-0083 Common Criteria Protection Profile Standard Reader - Smart Card Reader with PIN-Pad supporting eid based on Extended Access Control BSI-CC-PP-0083 Common Criteria Protection Profile Standard Reader Version

More information

Common Criteria Protection Profile. electronic Health Card (ehc) elektronische Gesundheitskarte (egk) BSI-PP-0020-V2-2007-MA01

Common Criteria Protection Profile. electronic Health Card (ehc) elektronische Gesundheitskarte (egk) BSI-PP-0020-V2-2007-MA01 VERSION 2.50 (ehc) elektronische Gesundheitskarte (egk) BSI-PP-0020-V2-2007-MA01 Approved by the Federal Ministry of Health Version 2.50, 2 nd January 2008 Version 2.50, 2nd January 2008 this page was

More information

Common Criteria Protection Profile. Electronic Identity Card (ID_Card PP)

Common Criteria Protection Profile. Electronic Identity Card (ID_Card PP) elektronischer Die PDF-Datei der amtlichen Veröffentlichung ist aus Sicherheitsgründen mit einer qualifizierten elektronischen Signatur gemäß 2 Nr. 3 Signaturgesetz (SigG) versehen. Solange die elektronische

More information

Preventing fraud in epassports and eids

Preventing fraud in epassports and eids Preventing fraud in epassports and eids Security protocols for today and tomorrow by Markus Mösenbacher, NXP Machine-readable passports have been a reality since the 1980s, but it wasn't until after 2001,

More information

Protection Profile for the Security Module of a Smart Meter Gateway (Security Module PP)

Protection Profile for the Security Module of a Smart Meter Gateway (Security Module PP) Protection Profile for the Security Module of a Smart Meter Gateway (Security Module PP) Schutzprofil für das Sicherheitsmodul der Kommunikationseinheit eines intelligenten Messsystems für Stoff- und Energiemengen

More information

Low Assurance Protection Profile for a VoIP Infrastructure

Low Assurance Protection Profile for a VoIP Infrastructure Low Assurance Protection Profile for a VoIP Infrastructure Version 1.1 Date Author(s) Dirk-Jan Out Certification ID Sponsor File name No of pages 12 TNO-ITSEF BV VoIP Low Assurance Protection Profile 1.1

More information

Security Target Sophos UTM V9 Packet Filter Version 1.000

Security Target Sophos UTM V9 Packet Filter Version 1.000 Sophos UTM V9 Packet Filter Version 1.000 Assurance Level EAL4+ Common Critera v3.1 Revision 4 Document version: 1.00 Document date: 2015-03-25 Document History Version Date Change(s) Author(s) 0.90 2014-02-19

More information

C015 Certification Report

C015 Certification Report C015 Certification Report NexCode National Security Suite Release 3 File name: Version: v1a Date of document: 15 June 2011 Document classification: For general inquiry about us or our services, please

More information

Forefront Identity Manager (FIM) 2010

Forefront Identity Manager (FIM) 2010 Forefront Identity Manager (FIM) 2010 Security Target Common Criteria: EAL4 augmented with ALC_FLR.3 Version 1.0 24-MAR-2012 Document history Version Date Description 0.1 28-APR-11 Initial draft for review.

More information

PKD Board ICAO PKD unclassified B-Tec/37. Procedures for the ICAO Public Key Directory

PKD Board ICAO PKD unclassified B-Tec/37. Procedures for the ICAO Public Key Directory Procedures for the ICAO Public Key Directory last modification final 1/13 SECTION 1 INTRODUCTION 1.1 As part of the MRTD initiative by ICAO, the Participants will upload to and download from the PKD, their

More information

U.S. Government Protection Profile for Application-level Firewall In Basic Robustness Environments

U.S. Government Protection Profile for Application-level Firewall In Basic Robustness Environments U.S. Government Protection Profile for Application-level Firewall In Basic Robustness Environments Information Assurance Directorate Version 1.1 July 25, 2007 Forward This Protection Profile US Government

More information

C033 Certification Report

C033 Certification Report C033 Certification Report Mobile Billing System File name: Version: v1a Date of document: 15 June 2011 Document classification: For general inquiry about us or our services, please email: mycc@cybersecurity.my

More information

Windows Mobile 6.5 Security Target

Windows Mobile 6.5 Security Target EAL4 augmented with ALC_FLR.1 Version 1.0 January 2010 The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication.

More information

MINISTERIO DE DEFENSA CENTRO NACIONAL DE INTELIGENCIA CENTRO CRIPTOLÓGICO NACIONAL ORGANISMO DE CERTIFICACIÓN

MINISTERIO DE DEFENSA CENTRO NACIONAL DE INTELIGENCIA CENTRO CRIPTOLÓGICO NACIONAL ORGANISMO DE CERTIFICACIÓN REF: 2010-12-INF-626 V1 Distribution: Public Date: 29.04.2011 Created: CERT3 Reviewed: TECNICO Approved: JEFEAREA CERTIFICATION REPORT FOR EADS GROUND SEGMENT SYSTEMS PROTECTION PROFILE (GSS-PP) ISSUE

More information

Lessons learnt in writing PP/ST. Wolfgang Killmann T-Systems

Lessons learnt in writing PP/ST. Wolfgang Killmann T-Systems Lessons learnt in writing PP/ST Wolfgang Killmann T-Systems Overview of the talk Lessons learnt in writing PP/ST Practical experience of PP/ST writing Issues with and suggestions for PP/ST writing Conformance

More information

Security Target Lite STARCOS 3.4 Health HBA C1

Security Target Lite STARCOS 3.4 Health HBA C1 Security Target Lite STARCOS 3.4 Health HBA C1 Version 2.0/09.06.2011 Author: Giesecke & Devrient GmbH Document status: Final Giesecke & Devrient GmbH Prinzregentenstr. 159 Postfach 80 07 29 81607 München

More information

Certification Report. NXP Secure Smart Card Controller P40C012/040/072 VD

Certification Report. NXP Secure Smart Card Controller P40C012/040/072 VD TÜV Rheinland Nederland B.V. Version 20101101 Certification Report NXP Secure Smart Card Controller P40C012/040/072 VD Sponsor and developer: NXP Semiconductors Germany GmbH, Business Unit Identification

More information

Common Criteria Protection Profile. electronic Health Card (ehc) elektronische Gesundheitskarte (egk) BSI-PP-0020-V2-2007

Common Criteria Protection Profile. electronic Health Card (ehc) elektronische Gesundheitskarte (egk) BSI-PP-0020-V2-2007 VERSION 2.00 (ehc) elektronische Gesundheitskarte (egk) BSI-PP-0020-V2-2007 Approved by the Federal Ministry of Health Version 2.00, 29 th January 2007 Version 2.00, 29 th January 2007 this page was intentionally

More information

Common Criteria for IT security evaluation

Common Criteria for IT security evaluation STMicroelectronics ST33F1M/1M0/896/768/640/512E, SC33F1M0/896/768/640/512/384E, SM33F1M/1M0/896/768/640/512E, SE33F1M/1M0/896/768/640/512E, SL33F1M/1M0/896/768/640/512E, SP33F1ME, with dedicated software

More information

EMC Documentum. EMC Documentum Content Server TM V5.3. and EMC Documentum Administrator TM V5.3. Security Target V2.0

EMC Documentum. EMC Documentum Content Server TM V5.3. and EMC Documentum Administrator TM V5.3. Security Target V2.0 EMC Documentum EMC Documentum Content Server TM V5.3 and EMC Documentum Administrator TM V5.3 Security Target V2.0 December 8, 2005 ST prepared by Suite 5200, 4925 Jones Branch Drive McLean, VA 22102-3305

More information

BSI-DSZ-CC-S-0040-2015. for. Dream Chip Technologies GmbH Germany. Dream Chip Technologies GmbH

BSI-DSZ-CC-S-0040-2015. for. Dream Chip Technologies GmbH Germany. Dream Chip Technologies GmbH BSI-DSZ-CC-S-0040-2015 for Dream Chip Technologies GmbH Germany of Dream Chip Technologies GmbH BSI - Bundesamt für Sicherheit in der Informationstechnik, Postfach 20 03 63, D-53133 Bonn Phone +49 (0)228

More information

Common Criteria for Information Technology Security Evaluation. Part 1: Introduction and general model. September 2012. Version 3.

Common Criteria for Information Technology Security Evaluation. Part 1: Introduction and general model. September 2012. Version 3. Common Criteria for Information Technology Security Evaluation Part 1: Introduction and general model September 2012 Version 3.1 Revision 4 CCMB-2012-09-001 Foreword This version of the Common Criteria

More information

TRUSTED SECURITY FILTER SECURITY TARGET

TRUSTED SECURITY FILTER SECURITY TARGET TRUSTED SECURITY FILTER SECURITY TARGET Edition: 4 29 Oct 07 Previous editions: Ed. 1 11 May 2006 Ed. 2 16 Aug 2006 Ed. 3 28 June 2007 Author: KKK Appr.: PÅT All pages in this document shall have the same

More information

ΙΒΜ SECURITY TARGET LITE. NXP P521G072V0P (JCOP 21 v2.3.1) Secure Smart Card Controller. Version 1.0

ΙΒΜ SECURITY TARGET LITE. NXP P521G072V0P (JCOP 21 v2.3.1) Secure Smart Card Controller. Version 1.0 ΙΒΜ SECURITY TARGET LITE NXP P521G072V0P (JCOP 21 v2.3.1) Secure Smart Card Controller Version 1.0 2007-07-23 IBM Deutschland Entwicklung GmbH Smart Card Development Schoenaicher Str. 220 D-71032 Boeblingen

More information

Microsoft Forefront UAG 2010 Common Criteria Evaluation Security Target Microsoft Forefront Unified Access Gateway Team

Microsoft Forefront UAG 2010 Common Criteria Evaluation Security Target Microsoft Forefront Unified Access Gateway Team Microsoft Forefront UAG 2010 Common Criteria Evaluation Security Target Microsoft Forefront Unified Access Gateway Team Author: Microsoft Corp. Version: 1.0 Last Saved: 2011-03-10 File Name: MS_UAG_ST_1.0.docx

More information

Oracle Business Intelligence Enterprise Edition (OBIEE) Version 10.1.3.3.2 with Quick Fix 090406 running on Oracle Enterprise Linux 4 update 5 x86_64

Oracle Business Intelligence Enterprise Edition (OBIEE) Version 10.1.3.3.2 with Quick Fix 090406 running on Oracle Enterprise Linux 4 update 5 x86_64 122-B CERTIFICATION REPORT No. CRP250 Business Intelligence Edition (OBIEE) Version 10.1.3.3.2 with Quick Fix 090406 running on update 5 Issue 1.0 June 2009 Crown Copyright 2009 All Rights Reserved Reproduction

More information

Common Criteria Security Target For 1E Power and Patch Management Pack

Common Criteria Security Target For 1E Power and Patch Management Pack Intelligent Windows Management Common Criteria Security Target For 1E Power and Patch Management Pack 30 September 2009 Document Version 1-0 1E Limited. All Rights reserved. Summary of Amendments Version

More information

Supporting Document Mandatory Technical Document. Evaluation Activities for Stateful Traffic Filter Firewalls cpp. February-2015. Version 1.

Supporting Document Mandatory Technical Document. Evaluation Activities for Stateful Traffic Filter Firewalls cpp. February-2015. Version 1. Supporting Document Mandatory Technical Document Evaluation Activities for Stateful Traffic Filter Firewalls cpp February-2015 Version 1.0 CCDB-2015-01-002 Foreword This is a supporting document, intended

More information

October 2014 Issue No: 2.0. Good Practice Guide No. 44 Authentication and Credentials for use with HMG Online Services

October 2014 Issue No: 2.0. Good Practice Guide No. 44 Authentication and Credentials for use with HMG Online Services October 2014 Issue No: 2.0 Good Practice Guide No. 44 Authentication and Credentials for use with HMG Online Services Good Practice Guide No. 44 Authentication and Credentials for use with HMG Online Services

More information

PKD Board ICAO PKD unclassified B-Tec/36. Regulations for the ICAO Public Key Directory

PKD Board ICAO PKD unclassified B-Tec/36. Regulations for the ICAO Public Key Directory Regulations for the ICAO Public Key Directory last modification final 1/8 SECTION 1 AUTHORITY These Regulations are issued by ICAO on the basis of Paragraph 3 b) of the Memorandum of Understanding (MoU)

More information

IY2760/CS3760: Part 6. IY2760: Part 6

IY2760/CS3760: Part 6. IY2760: Part 6 IY2760/CS3760: Part 6 In this part of the course we give a general introduction to network security. We introduce widely used security-specific concepts and terminology. This discussion is based primarily

More information

Joint Interpretation Library. ETR-lite for composition : Annex A Composite smartcard evaluation : Recommended best practice. IC and ES composition

Joint Interpretation Library. ETR-lite for composition : Annex A Composite smartcard evaluation : Recommended best practice. IC and ES composition ETR-lite for composition : Annex A Composite smartcard evaluation : Recommended best practice IC and ES composition Version 1.2 March 2002 ETR-lite for Composition Annex A Table of Contents 1. Foreword...

More information

Citrix Password Manager, Enterprise Edition Version 4.5

Citrix Password Manager, Enterprise Edition Version 4.5 122-B COMMON CRITERIA CERTIFICATION REPORT No. CRP235 Citrix Password Manager, Enterprise Edition Version 4.5 running on Microsoft Windows and Citrix Presentation Server Issue 1.0 June 2007 Crown Copyright

More information

TÜBİTAK BİLGEM ULUSAL ELEKTRONİK & KRİPTOLOJİ ARAŞTIRMA ENSTİTÜSÜ AKİS PROJESİ AKİS V1.4N

TÜBİTAK BİLGEM ULUSAL ELEKTRONİK & KRİPTOLOJİ ARAŞTIRMA ENSTİTÜSÜ AKİS PROJESİ AKİS V1.4N The contents of this document are the property of TÜBİTAK TÜBİTAK BİLGEM ULUSAL ELEKTRONİK & KRİPTOLOJİ ARAŞTIRMA ENSTİTÜSÜ AKİS PROJESİ AKİS-PASAPORT SECURITY TARGET LITE AKİS V1.4N Revision No 06 Revision

More information

SECURITY TARGET FOR FORTIANALYZER V4.0 MR3 CENTRALIZED REPORTING

SECURITY TARGET FOR FORTIANALYZER V4.0 MR3 CENTRALIZED REPORTING SECURITY TARGET FOR FORTIANALYZER V4.0 MR3 CENTRALIZED REPORTING Document No. 1735-005-D0001 Version: 1.0, 3 June 2014 Prepared for: Fortinet, Incorporated 326 Moodie Drive Ottawa, Ontario Canada, K2H

More information

Extended Package for Mobile Device Management Agents

Extended Package for Mobile Device Management Agents Extended Package for Mobile Device Management Agents 31 December 2014 Version 2.0 REVISION HISTORY Version Date Description 1.0 21 October 2013 Initial Release 1.1 7 February 2014 Typographical changes

More information

NXP Secure Smart Card Controllers P5CC008, P5CC012 V1A/ V1A(s)

NXP Secure Smart Card Controllers P5CC008, P5CC012 V1A/ V1A(s) NXP Secure Smart Card Controllers Document information Info Content Keywords CC, Security Evaluation,, Functional Requirements, Security Functionality, Assurance Level, P5CC008, P5CC012 V1A/ V1A(s) Abstract

More information

Courtesy Translation

Courtesy Translation Direction centrale de la sécurité des systèmes d information Protection Profile Electronic Signature Creation Application Date : July 17th, 2008 Reference : Version : 1.6 Courtesy Translation Courtesy

More information

CC V3 application to Smart Cards and similar devices

CC V3 application to Smart Cards and similar devices CC V3 application to Smart Cards and similar devices 8th ICCC Rome, 25-27 September 2007 ISCI-WG1 speaker: Françoise Forge 25-27 September 2007 8th ICCC Rome 1 Presentation overview ISCI - a Eurosmart

More information

Security Target for Cisco Secure PIX Firewall 515, 520, 525 Version 5.2(3)

Security Target for Cisco Secure PIX Firewall 515, 520, 525 Version 5.2(3) Security Target for Cisco Secure PIX Firewall 515, 520, 525 Version 5.2(3) Reference: ST January 2001 Version: 1.6 Europe: USA: CISCO Systems Ltd CISCO Systems Inc. 3 The Square 170 West Tasman Drive Stockley

More information

Low Assurance Protection Profile for a Software Based Personal Firewall for home Internet use

Low Assurance Protection Profile for a Software Based Personal Firewall for home Internet use TNO report PP-Software Based Personal Firewall-1.2 Low Assurance Protection Profile for a Software Based Personal Firewall for home Internet use Version 1.2 Date 6 th April 2005 Author(s) Rob Hunter Dirk-Jan

More information

NXP Secure Smart Card Controllers P5CD016V1D / P5CD021V1D / P5CD041V1D / P5Cx081V1D with DESFire EV1

NXP Secure Smart Card Controllers P5CD016V1D / P5CD021V1D / P5CD041V1D / P5Cx081V1D with DESFire EV1 NXP Secure Smart Card Controllers P5CD016V1D / P5CD021V1D / P5CD041V1D / P5Cx081V1D with DESFire EV1 Rev. 1.1 24 October 2011 BSI-DSZ-CC-0707 Evaluation documentation Document information Info Keywords

More information

Protection Profile Digital Tachograph Vehicle Unit (VU PP) Version 1.0 BSI-CC-PP-0057-2010

Protection Profile Digital Tachograph Vehicle Unit (VU PP) Version 1.0 BSI-CC-PP-0057-2010 Protection Profile Digital Tachograph Vehicle Unit (VU PP) Version 1.0 BSI-CC-PP-0057-2010 Dipl.-Phys. Certification Federal Office for Information Security (BSI), Germany Topics of VU-PP CC 3.1 R3 Overview

More information

BSI-DSZ-CC-S-0035-2014. for. GLOBALFOUNDRIES Singapore Pte. Ltd. GLOBALFOUNDRIES Singapore Pte. Ltd.

BSI-DSZ-CC-S-0035-2014. for. GLOBALFOUNDRIES Singapore Pte. Ltd. GLOBALFOUNDRIES Singapore Pte. Ltd. BSI-DSZ-CC-S-0035-2014 for GLOBALFOUNDRIES Singapore Pte. Ltd. of GLOBALFOUNDRIES Singapore Pte. Ltd. BSI - Bundesamt für Sicherheit in der Informationstechnik, Postfach 20 03 63, D-53133 Bonn Phone +49

More information

Certification Report

Certification Report Certification Report EAL 2 Evaluation of Revenue Administration Department of Turkey/Gelir İdaresi Başkanlığı Common Criteria Protection Profile for New Generation Cash Register Fiscal Application Software-2

More information

PROTECTION PROFILE DEVELOPMENT

PROTECTION PROFILE DEVELOPMENT PROTECTION PROFILE DEVELOPMENT FOR CARD ACCEPTANCE DEVICE (CAD) WITH BIOMETRIC Norahana Salimin norahana@cybersecurity.my ICCC 2013 Sept 10-12 Orlando Content PPWG Background Challenge Lesson Learn Sneak

More information

Joint Interpretation Library

Joint Interpretation Library Document purpose: provide rules to ensure that CC is used for hardware integrated circuits in a manner consistent with today s state of the art hardware Version 3.0 February 2009 Joint Interpretation Library

More information

Courtesy Translation

Courtesy Translation PREMIER MINISTRE Secrétariat général de la défense et de la sécurité nationale Agence nationale de la sécurité des systèmes d'information Certification Report ANSSI-CC-PP-2010/04 (ref. PU-2009-RT-79, version

More information

Common Criteria Protection Profile. Machine Readable Travel Document with ICAO Application, Basic Access Control BSI-CC-PP-0055

Common Criteria Protection Profile. Machine Readable Travel Document with ICAO Application, Basic Access Control BSI-CC-PP-0055 Common Criteria Protection Profile Machine Readable Travel Document with ICAO Application, Basic Access Control BSI-CC-PP-0055 Common Criteria Protection Profile Version 1.10, 25 th March 2009 Foreword

More information

Biometrics for Public Sector Applications

Biometrics for Public Sector Applications Technical Guideline TR-03121-2 Biometrics for Public Sector Applications Part 2: Software Architecture and Application Profiles Version 2.3 Bundesamt für Sicherheit in der Informationstechnik Postfach

More information

Security Target. McAfee Enterprise Mobility Management 9.7. Document Version 0.9. July 5, 2012

Security Target. McAfee Enterprise Mobility Management 9.7. Document Version 0.9. July 5, 2012 Security Target McAfee Enterprise Mobility Management 9.7 Document Version 0.9 July 5, 2012 Document Version 0.9 McAfee Page 1 of 39 Prepared For: Prepared By: McAfee, Inc. 2821 Mission College Blvd. Santa

More information

Network Device Collaborative Protection Profile (NDcPP) Extended Package Session Border Controller. July 24, 2015 Version 1

Network Device Collaborative Protection Profile (NDcPP) Extended Package Session Border Controller. July 24, 2015 Version 1 Network Device Collaborative Protection Profile (NDcPP) Extended Package Session Border Controller July 24, 2015 Version 1 1 Table of Contents 1 Introduction... 4 1.1 Conformance Claims...4 1.2 How to

More information

USB Portable Storage Device: Security Problem Definition Summary

USB Portable Storage Device: Security Problem Definition Summary USB Portable Storage Device: Security Problem Definition Summary Introduction The USB Portable Storage Device (hereafter referred to as the device or the TOE ) is a portable storage device that provides

More information

Description of the Technical Component:

Description of the Technical Component: Confirmation concerning Products for Qualified Electronic Signatures according to 15 Sec. 7 S. 1, 17 Sec. 4 German Electronic Signature Act 1 and 11 Sec. 2 and 15 German Electronic Signature Ordinance

More information

SECURITY TARGET: SQ-PHOENIX DIGITAL ENCRYPTOR

SECURITY TARGET: SQ-PHOENIX DIGITAL ENCRYPTOR SECURITY TARGET: SQ-PHOENI DIGITAL ENCRYPTOR VERSION 2.7 Prepared by and for: CES Communications Ltd Version 1.3 TABLE OF CONTENTS 1 Security Target Introduction... 1 1.1 ST and TOE Identification... 1

More information

Common Criteria for Information Technology Security Evaluation. Part 2: Security functional components. September 2007. Version 3.

Common Criteria for Information Technology Security Evaluation. Part 2: Security functional components. September 2007. Version 3. Common Criteria for Information Technology Security Evaluation Part 2: Security functional components September 2007 Version 3.1 Revision 2 CCMB-2007-09-002 Foreword This version of the Common Criteria

More information

SECURITY TARGET CITADEL HERCULES ENTERPRISE VULNERABILITY MANAGEMENT (EVM) VERSION 4.1

SECURITY TARGET CITADEL HERCULES ENTERPRISE VULNERABILITY MANAGEMENT (EVM) VERSION 4.1 SECURITY TARGET CITADEL HERCULES ENTERPRISE VULNERABILITY MANAGEMENT (EVM) VERSION 4.1 Document No. 1517-011-D001 Version 1.1, 3 August 2006 Prepared for: Citadel Security Software Inc. Two Lincoln Centre

More information

Certification Report

Certification Report Certification Report EAL 4 Evaluation of SecureDoc Disk Encryption Version 4.3C Issued by: Communications Security Establishment Certification Body Canadian Common Criteria Evaluation and Certification

More information

Security Target SQL Server 2012 Team

Security Target SQL Server 2012 Team Microsoft SQL Server 2012 Database Engine Common Criteria Evaluation (EAL2) Security Target SQL Server 2012 Team Author: Version: 1.2 Roger French (Microsoft Corporation) Date: 2012-08-07 Abstract This

More information

Open Smart Card Infrastructure for Europe

Open Smart Card Infrastructure for Europe Open Smart Card Infrastructure for Europe v2 Volume 8: Part 3-1: Authors: Security and Protection Profiles (Common Criteria Supporting Document) eesc TB3 Protection Profiles, Security Certification NOTICE

More information

Security Target for Citrix Presentation Server 4.0 For Windows

Security Target for Citrix Presentation Server 4.0 For Windows Security Target for Citrix Presentation Server 4.0 For Windows Reference: ST/T488 July 2005 Version: 1.0 This document has been prepared on behalf of: Prepared by: Citrix Systems, Inc BT 851 West Cypress

More information

Security Target. Security Target SQL Server 2008 Team. Author: Roger French Version: 1.04 Date: 2011-09-26

Security Target. Security Target SQL Server 2008 Team. Author: Roger French Version: 1.04 Date: 2011-09-26 SQL Server 2008 Team Author: Roger French Version: 1.04 Date: 2011-09-26 Abstract This document is the (ST) for the Common Criteria certification of the database engine of Microsoft SQL Server 2008 R2.

More information