MICARDO Tachograph Version 1.0 R1.0 1 / 139 ST-Lite Document Administration 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Document Administration Recipient Department Name For the attention of Department Name Summary The following document comprises the Security Target Lite for a TOE evaluated ac- cording to Common Criteria Version 2.2. The TOE being subject of the evaluation is the smartcard product MICARDO Tachograph Version 1.0 R1.0 from Sagem Orga GmbH. The IT product under consideration shall be evaluated ac- cording to CC EAL 4 augmented with a minimum strength level for the TOE security functions of SOF-high. Keywords Target of Evaluation (TOE), Common Criteria, IC, Dedicated Software, Smartcard Em- bedded Software, Basic Software, Application Software, Tachograph Application, Se- curity Objectives, Assumptions, Threats, TOE Security Function (TSF), TOE Security Enforcing Function (SEF), Level of Assurance, Strength of Functions (SOF), Security Functional Requirement (SFR), Security Assurance Requirement (SAR), Security Function Policy (SFP) Responsibility for updating the document Dr. Susanne Pingel Sagem ORGA GmbH MICARDO Tachograph Version 1.0 R1.0 ST-Lite Document Id: 3Tachograph.CSL.0003 Archive: 3 Product/project/subject: Tachograph (Tachograph-Fahrtenschreiber für LKW) Category of document: CSL (ST-Lite) Consecutive number: 0003 Version: V1.00 Date: 21 June 2006 Author: Dr. Susanne Pingel Confidentiality: Checked report: not applicable Authorized (Date/Signature): not applicable Accepted (Date/Signature): not applicable ©Sagem ORGA GmbH, Paderborn, 2006 MICARDO Tachograph Version 1.0 R1.0 3 / 139 ST-Lite Document Organisation 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Document Organisation i Notation None of the notations used in this document need extra explanation. ii Official Documents and Standards See Bibliography. iii Revision History Version Type of change Author / team V1.00 First edition Dr. Susanne Pingel MICARDO Tachograph Version 1.0 R1.0 4 / 139 ST-Lite Table of Contents 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Table of Contents Document Organisation ...................................................................................0H3 i Notation...............................................................................................................1H3 ii Official Documents and Standards .....................................................................2H3 iii Revision History..................................................................................................3H3 Table of Contents..............................................................................................4H4 1 ST Introduction...........................................................................................5H7 1.1 ST Identification............................................................................................6H7 1.2 ST Overview.................................................................................................7H7 1.3 CC Conformance..........................................................................................8H9 2 TOE Description .......................................................................................9H11 2.1 TOE Definition ............................................................................................10H11 2.1.1 Overview.....................................................................................................11H11 2.1.2 TOE Product Scope....................................................................................12H12 2.1.3 Integrated Circuit (IC) with its Dedicated Software.....................................13H13 2.1.4 Smartcard Embedded Software .................................................................14H14 2.1.4.1 Basic Software............................................................................................15H14 2.1.4.2 Application Software...................................................................................16H15 2.2 TOE Life-Cycle ...........................................................................................17H17 2.3 TOE Environment.......................................................................................18H20 2.3.1 Development Environment .........................................................................19H20 2.3.2 Production Environment .............................................................................20H21 2.3.3 Personalisation Environment......................................................................21H22 2.3.4 End-User Environment ...............................................................................22H23 2.4 TOE Intended Usage..................................................................................23H24 3 TOE Security Environment......................................................................24H26 3.1 Assets.........................................................................................................25H26 3.2 Assumptions...............................................................................................26H28 3.2.1 General Assumptions for the TOE..............................................................27H28 3.2.2 Tachograph Card Specific Assumptions for the TOE.................................28H30 3.3 Threats .......................................................................................................29H30 3.3.1 Threats of the IC (TOE-IC) .........................................................................30H31 3.3.2 General Threats of the Smartcard Embedded Software (TOE-ES)............31H31 3.3.3 Tachograph Card Specific Threats.............................................................32H34 3.4 Organisational Security Policies of the TOE...............................................33H35 4 Security Objectives ..................................................................................34H37 4.1 Security Objectives for the TOE .................................................................35H37 4.1.1 Security Objectives for the TOE-IC ............................................................36H37 4.1.2 General Security Objectives for the TOE-ES .............................................37H37 4.1.3 Tachograph Card Specific Security Objectives ..........................................38H39 4.2 Security Objectives for the Environment ....................................................39H40 4.2.1 General Security Objectives for the Environment of the TOE ....................40H40 5 IT Security Requirements ........................................................................41H43 MICARDO Tachograph Version 1.0 R1.0 5 / 139 ST-Lite Table of Contents 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 5.1 TOE Security Requirements.......................................................................42H43 5.1.1 TOE Security Functional Requirements .....................................................43H43 5.1.1.1 TOE Security Functional Requirements for the IC (TOE-IC)......................44H43 5.1.1.2 TOE Security Functional Requirements for the Smartcard Embedded Software (TOE-ES).....................................................................................45H43 5.1.2 SOF Claim for TOE Security Functional Requirements .............................46H90 5.1.3 TOE Security Assurance Requirements.....................................................47H90 5.1.4 Refinements of the TOE Security Assurance Requirements......................48H92 5.2 Security Requirements for the Environment of the TOE ............................49H92 5.2.1 Security Requirements for the IT-Environment ..........................................50H92 5.2.2 Security Requirements for the Non-IT-Environment...................................51H92 6 TOE Summary Specification ...................................................................52H93 6.1 TOE Security Functions..............................................................................53H93 6.1.1 TOE Security Functions / TOE-IC ..............................................................54H93 6.1.2 TOE Security Functions / TOE-ES .............................................................55H93 6.2 SOF Claim for TOE Security Functions....................................................56H100 6.3 Assurance Measures................................................................................57H101 7 PP Claims................................................................................................58H105 8 Rationale .................................................................................................59H106 8.1 Security Objectives Rationale...................................................................60H106 8.1.1 Threats - Security Objectives ...................................................................61H106 8.1.1.1 Threats of the TOE-IC ..............................................................................62H106 8.1.1.2 General Threats of the TOE-ES ...............................................................63H106 8.1.1.3 Tachograph Card Specific Threats...........................................................64H107 8.1.2 Assumptions - Security Objectives...........................................................65H110 8.1.3 Organisational Security Policies - Security Objectives.............................66H110 8.2 Security Requirements Rationale.............................................................67H111 8.2.1 Security Functional Requirements Rationale ...........................................68H111 8.2.1.1 Security Objectives for the TOE-IC - Security Functional Requirements ...........................................................................................69H111 8.2.1.2 Security Objectives for the TOE-ES - Security Functional Requirements ...........................................................................................70H111 8.2.1.3 Tachograph Card Specific Security Objectives - Security Functional Requirements ...........................................................................................71H112 8.2.2 Security Functional Requirements Dependencies....................................72H117 8.2.2.1 SFRs of the TOE-IC .................................................................................73H117 8.2.2.2 SFRs of the TOE-ES ................................................................................74H117 8.2.3 Strength of Function Level Rationale .......................................................75H122 8.2.4 Security Assurance Requirements Rationale...........................................76H122 8.2.4.1 Evaluation Assurance Level Rationale.....................................................77H122 8.2.4.2 Assurance Augmentations Rationale .......................................................78H123 8.2.5 Security Assurance Requirements Dependencies ...................................79H125 8.2.6 Security Requirements – Mutual Support and Internal Consistency ........80H125 8.3 TOE Summary Specification Rationale ....................................................81H128 8.3.1 Security Functions Rationale....................................................................82H128 8.3.1.1 Security Functional Requirements for the TOE-IC – TOE Security Functions..................................................................................................83H128 8.3.1.2 Security Functional Requirements for the TOE-ES – TOE Security Functions..................................................................................................84H128 8.3.2 Assurance Measures Rationale................................................................85H132 8.3.3 TOE Security Functions – Mutual Support and Internal Consistency.......86H132 MICARDO Tachograph Version 1.0 R1.0 6 / 139 ST-Lite Table of Contents 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 8.3.4 Strength of Functions ...............................................................................87H132 Reference.......................................................................................................88H133 I Bibliography ....................................................................................................89H133 II Summary of abbreviations ..............................................................................90H138 III Glossary..........................................................................................................91H139 MICARDO Tachograph Version 1.0 R1.0 7 / 139 ST-Lite ST Introduction 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 1 ST Introduction 1.1 ST Identification This Security Target refers to the smartcard product “MICARDO Tachograph Version 1.0 R1.0” (TOE) provided by Sagem Orga GmbH for a Common Criteria evaluation. Title: ST-Lite - MICARDO Tachograph Version 1.0 R1.0 Document Category: Security Target for a CC Evaluation (Public Version) Document ID: 3Tachograph.CSL.0003 Version: Refer to document administration Publisher: Sagem Orga GmbH Confidentiality: confidential TOE: “MICARDO Tachograph Version 1.0 R1.0” (Smartcard Product containing IC with Embedded Software dedicated for the Tachograph Application) Certification ID: BSI-DSZ-CC-0358 IT Evaluation Scheme: German CC Evaluation Scheme Evaluation Body: SRC Security Research & Consulting GmbH Certification Body: Bundesamt für Sicherheit in der Informationstechnik (BSI) This Security Target has been built in conformance with Common Criteria V2.2 resp. Com- mon Criteria V2.1 (ISO 15408) under consideration of all relevant finally agreed RIs (refer to /AIS32/). Note: The new version Common Criteria V2.2 is based on the older version V2.1 and inte- grates as single difference all RIs finally agreed up to 2004. 1.2 ST Overview Target of Evaluation (TOE) and subject of this Security Target (ST) is the smartcard product “MICARDO Tachograph Version 1.0 R1.0” developed by Sagem Orga GmbH. For the delivery of the TOE two different ways are established: • The TOE is delivered to the customer in form of a complete initialised smartcard. • Alternatively, the TOE is delivered to the customer in form of an initialised module. In this case, the smartcard finishing process (embedding of the delivered modules, final card tests) is task of the customer. MICARDO Tachograph Version 1.0 R1.0 8 / 139 ST-Lite ST Introduction 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel As the form of the delivery of the TOE does not concern the security features of the TOE in any way the TOE will be named in the following with “Tachograph Card” for short, independ- ently of its form of delivery. The TOE will be employed within the Tachograph System as a security medium which car- ries a specific Tachograph Application intended for its use with the recording equipment. A Tachograph Card allows for identification of the identity (or identity group) of the cardholder by the recording equipment and allows for data transfer and storage. A Tachograph Card may be of the type Driver Card, Control Card, Workshop Card or Company Card. The TOE comprises the following components: • Integrated Circuit (IC) "Philips SmartMX P5CC036V1D Secure Smart Card Con- troller with Cryptographic Library as IC Dedicated Support Software" provided by Philips Semiconductors GmbH • Smartcard Embedded Software (based on a native implementation) with a specific Tachograph Application provided by Sagem Orga GmbH The Tachograph Application consists of a configurable software part for the Tachograph Card´s file system. The configuration of the Tachograph Card concerns the following points: • Choice of the card type: A complete Driver Card, Control Card, Workshop Card or Company Card with complete file system as defined in the Tachograph Card Specification /TachAn1B/, main body, Appendix 2, chap. 4 is produced. Alterna- tively, a General Tachograph Card set up for the different types Driver Card, Con- trol Card, Workshop Card and Company Card is generated. In this case, after ini- tialisation resp. prior to the personalisation of the card, one of the four prepared card types as desired by the customer has to be blown up by using a specific card command. • Choice of the personalisation scheme: Securing the transfer of personalisation data can be done on base of a dynamic scheme (Secure Messaging with a ses- sion key) or alternatively on base of a static scheme (Secure Messaging with a static key). The TOE is configured by Sagem Orga GmbH according to the different possibilities for con- figuration described before. The configuration of the product is defined prior to its delivery and cannot be changed after delivery. The TOE is developed and constructed in full accordance with the Tachograph Card Specifi- cation /TachAn1B/, main body, Appendix 2, Appendix 10 (Tachograph Card Generic Security Target) and Appendix 11. In particular, this implies the conformance of the Tachograph Card with the following standards: • ISO/IEC 7810 Identification cards – Physical characteristics • ISO/IEC 7816 Identification cards - Integrated circuits with contacts: - Part 1: Physical characteristics - Part 2: Dimensions and location of the contacts - Part 3: Electronic signals and transmission protocols - Part 4: Inter-industry commands for interchange - Part 8: Security related inter-industry commands MICARDO Tachograph Version 1.0 R1.0 9 / 139 ST-Lite ST Introduction 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel • ISO/IEC 10373 Identification cards – Test methods As mentioned, the TOE with all its components complies with the Tachograph Card Specifi- cation and its functional and security requirements as specified in /TachAn1B/, main body, Appendix 2, Appendix 10 (Tachograph Card Generic Security Target) and Appendix 11. Par- ticularly, this ST takes into account the “Tachograph Card Generic Security Target” for the Tachograph Card in /TachAn1B/, Appendix 10. In order to achieve the required system secu- rity, the Tachograph Card and the corresponding ST meet all the security requirements and evaluation conditions defined in the Tachograph card´s “Generic Security Target” under con- sideration of the interpretations in /JILDigTacho/. The CC evaluation and certification of the TOE against the present ST serves for the security certificate in the sense of the Tachograph Card Specification /TachAn1B/, main body, chap. VIII. 2. The CC evaluation and certification of the TOE implies the proof for the compliance of the TOE with the requirements of /TachAn1B/, Appendix 10 (Tachograph Card Generic Se- curity Target). The main objectives of this ST are • to describe the TOE as a smartcard product for the Tachograph System • to define the limits of the TOE • to describe the assumptions, threats and security objectives for the TOE • to describe the security requirements for the TOE • to define the TOE security functions 1.3 CC Conformance The CC evaluation of the TOE is based upon • Common Criteria for Information Technology Security Evaluation, Part 1: Introduc- tion and General Model, Version 2.2, January 2004 (/CC 2.2 Part1/) • Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional Requirements, Version 2.2, January 2004 (/CC 2.2 Part2/) • Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance Requirements, Version 2.2, January 2004 (/CC 2.2 Part3/) For the evaluation the following methodology will be used: • Common Methodology for Information Technology Security Evaluation, Part 2: Evaluation Methodology, Version 2.2, January 2004 (/CEM 2.2 Part2/) This Security Target is written in accordance with the above mentioned Common Criteria Version 2.2 and claims the following CC conformances: • Part 2 extended (Note: The supplement „extended“ is only relevant for the SFRs of the underlying IC with its IC Dedicated Support Software.) MICARDO Tachograph Version 1.0 R1.0 10 / 139 ST-Lite ST Introduction 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel • Part 3 conformant under consideration of all relevant RIs finally agreed up to the end of 2003 (refer to /AIS32/). Furthermore, the ST is written in view of the requirements of the „Generic Security Target“ for the Tachograph Card within the Tachograph Card Specification /TachAn1B/, Appendix 10 (Tachograph Card Generic Security Target) and the JIL interpretations and requirements in /JILDigTacho/. In particular, this ST complies with the Protection Profile PP9911 „Smartcard Integrated Circuit with Embedded Software“ (/PP9911/). The IC evaluation in compliance with the Protection Profile PP9806 (/PP9806/) as required in /TachAn1B/, Appendix 10 is replaced by the comparable IC evaluation according to the Protection Profile BSI-PP-0002 (/BSI-PP-0002/). Refer for this to the report of the BSI concerning the comparability of the Protection Profiles PP9806 and BSI-PP-0002 (/CompPP9806-BSIPP0002/). The chosen level of assurance for the TOE is EAL 4 augmented. The augmentation in- cludes the assurance components ADO_IGS.2, ADV_IMP.2, ATE_DPT.2 and AVA_VLA.4. The minimum strength level for the TOE security functions is SOF-high. In order to avoid redundancy and to minimize the evaluation efforts, the evaluation of the TOE will be conducted as a composite evaluation and will make use of the evaluation results of the CC evaluation of the underlying semiconductor "Philips SmartMX P5CC036V1D Se- cure Smart Card Controller with Cryptographic Library as IC Dedicated Support Software" provided by Philips Semiconductors GmbH. The IC incl. its IC Dedicated Software is evalu- ated according to Common Criteria EAL 4 augmented with a minimum strength level for its security functions of SOF-high and is listed under the Certification ID BSI-DSZ-CC-0368. The evaluation of the IC is based on the Protection Profile BSI-PP-0002 (/BSI-PP-0002/). MICARDO Tachograph Version 1.0 R1.0 11 / 139 ST-Lite TOE Description 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 2 TOE Description 2.1 TOE Definition 2.1.1 Overview The Target of Evaluation (TOE) is the smartcard product “ MICARDO Tachograph Version 1.0 R1.0” (Tachograph Card for short in the following) implemented in accordance with the Tachograph Card Specification /TachAn1B/, main body, Appendix 2, Appendix 10 (Tacho- graph Card Generic Security Target) and Appendix 11. In technical view the Tachograph Card is realised as a proprietary operating system with a dedicated Tachograph Application set-up on this layer. The Tachograph Card is based on the microcontroller "Philips SmartMX P5CC036V1D Se- cure Smart Card Controller with Cryptographic Library as IC Dedicated Support Software" provided by Philips Semiconductors GmbH. The IC incl. its Dedicated Software is evaluated according to Common Criteria EAL 4 augmented with a minimum strength level for its secu- rity functions of SOF-high (refer to Certification ID BSI-DSZ-CC-0368). Roughly spoken, the TOE is composed from the following parts: • Integrated Circuit (IC) with its proprietary IC Dedicated Software (TOE-IC) • Smartcard Embedded Software (TOE-ES) consisting of - Basic Software (TOE-ES/BS) - Application Software (TOE-ES/AS) While the Basic Software consists of the operating system of the TOE (realised as native implementation), the Application Software implements the specific Tachograph Application (file system with dedicated access rules and further security related data). The Tachograph Application contains in particular the code for the Tachograph Card´s file system. As each type of Tachograph Card has its own file system with own elementary and dedicated files and own access rules, the Tachograph Application depends on the respective card type. The Tachograph Application covers either the complete file system for a Driver Card, Control Card, Workshop Card or Company Card or is alternatively prepared for the four card types. In the latter case, after initialisation resp. prior to the personalisation of the card, one of the four prepared card types has to be blown up by usage of a specific card command. Furthermore, different personalisation schemes for the personalisation of the Ta- chograph Card may be defined. These two points will be considered as configuration of the TOE. The configuration will be done by Sagem Orga GmbH prior to the delivery of the prod- uct and cannot be changed afterwards. Furthermore, the Tachograph Card itself offers the possibility to check its authenticity. For this purpose, the Tachograph Card contains the private part of a dedicated authentication key pair which depends on the configuration of the Tachograph Application and may be cho- sen customer specific (for more details see chap. 92H2.1.4.2). MICARDO Tachograph Version 1.0 R1.0 12 / 139 ST-Lite TOE Description 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel The following figure shows the global architecture of the TOE and its components: The different components of the TOE depicted in the figure above will be described more detailed in the following sections. 2.1.2 TOE Product Scope The following table contains an overview of all deliverables associated to the TOE: TOE component Description / Additional Information Type Transfer Form TOE-IC Philips SmartMX P5CC036V1D Secure Smart Card Controller (incl. its IC Dedicated Software, covering in particular the Crypto Library) HW / SW --- TOE-ES/BS Smartcard Embedded Software / Part Basic Software (implemented in ROM/EEPROM of the microcontroller) SW --- TOE-ES/AS Smartcard Embedded Software / Part Applica- tion Software (depending on the TOE´s configu- ration resp. card type, implemented in the EEPROM of the microcontroller) SW --- Note: The TOE itself will be delivered as initialised smartcard or as initialised module. User Guide Per- sonaliser User guidance for the Personaliser of the Ta- chograph Card DOC Document in paper / electronic form User Guide Is- suer User guidance for the Issuer of the Tachograph Card DOC Document in paper / electronic form User Guide VU Developer User guidance for the Developer of Vehicle Units DOC Document in paper / electronic form Identification Data Sheet of the Tachograph Card Data Sheet with information on the actual iden- tification data and configuration of the Tacho- graph Card delivered to the customer DOC Document in paper / electronic form Aut-Key of the Public part of the authentication key pair rele- KEY Document in paper TOE-IC TOE-ES/AS TOE-ES/BS Application Layer Tachograph Application IC P5CC036V1D Native Platform Memory Management, I/O, Security Features, Transaction Facilities MICARDO V3.0 Initialisation Module Crypto- Lib MICARDO Tachograph Version 1.0 R1.0 13 / 139 ST-Lite TOE Description 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel TOE component Description / Additional Information Type Transfer Form Tachograph Card vant for the authenticity of the Tachograph Card Note: The card´s authentication key pair is gen- erated by Sagem Orga GmbH and depends on the TOE´s configuration delivered to the cus- tomer. Furthermore, the key pair may be cho- sen customer specific. form / electronic file Pers-Key of the Tachograph Card Public part of the personalisation key pair of the Tachograph Card necessary for the personal- isation process at the personaliser Note: The card´s personalisation key pair is generated by Sagem Orga GmbH and may depend on the TOE´s configuration delivered to the customer. Furthermore, the key pair may be chosen customer specific. KEY Document in paper form / electronic file Pers-Key Pair of the Personalisa- tion Unit (if applicable) Personalisation key pair for the personalisation unit necessary for the personalisation of the Tachograph Card delivered to the personaliser Note: The personalisation key pair is generated by the personaliser itself or alternatively by Sagem Orga GmbH. In case of a generation at Sagem Orga GmbH, the key pair may depend on the TOE´s configuration delivered to the customer and may be chosen customer spe- cific. KEY PAIR Document in paper form / electronic file Static Pers-Key (if applicable) Static personalisation key for the personalisa- tion unit necessary for the personalisation of the Tachograph Card delivered to the personaliser Note: The static personalisation key is gener- ated by the personaliser itself or alternatively by Sagem Orga GmbH. In case of a generation at Sagem Orga GmbH, the key may depend on the TOE´s configuration delivered to the cus- tomer and may be chosen customer specific. KEY Document in paper form / electronic file Note: Deliverables in paper form require a personal passing on. For deliverables in electronic form an integrity and authenticity attribute will be attached. 2.1.3 Integrated Circuit (IC) with its Dedicated Software Basis for the TOE´s Smartcard Embedded Software is the microcontroller “Philips SmartMX P5CC036V1D Secure Smart Card Controller with Cryptographic Library as IC Dedicated Support Software”. The microcontroller and its Dedicated Software are developed and pro- duced by Philips Semiconductors GmbH (within phase 2 and 3 of the smartcard product life- cycle, see chap. 93H2.2). Detailed information on the IC Hardware, the IC Dedicated Software (in particular the Crypto Library) and the IC interfaces can be found in /ST-ICPhilips/ and /ST-ICPhilips+Lib/. MICARDO Tachograph Version 1.0 R1.0 14 / 139 ST-Lite TOE Description 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 2.1.4 Smartcard Embedded Software The Smartcard Embedded Software of the TOE comprises the smartcard operating system and the specific Tachograph Application and is therefore divided into two parts with specific contents: • Basic Software (Smartcard Operating System) • Application Software (Tachograph Application) Each part of the Smartcard Embedded Software is designed and developed by Sagem Orga GmbH in phase 1 of the smartcard product life-cycle (see chap. 94H2.2) and is embedded into the TOE in the later phases 3 and 5. The main parts of the Basic Software are brought into the card by the IC manufacturer in form of the ROM mask and stored in the User-ROM of the IC (phase 3). The Application Software, and perhaps additional parts of the Basic Software, are located in the EEPROM area and are lateron loaded by specific initialisation routines of the TOE (phase 5). Hereby, the loading requires an encrypted and with a cryptographic checksum secured initialisation file. The necessary keys for securing the initialisation process are stored inside the IC during production time. 2.1.4.1 Basic Software The Basic Software of the Smartcard Embedded Software comprises the operating system of the TOE. Its main and security related parts are stored in the User-ROM of the underlying IC and are brought into the smartcard in form of the so-called ROM mask during the production process of the IC within phase 3 of the smartcard product life-cycle (see chap. 95H2.2). The operating system of the TOE is designed as proprietary software consisting of two lay- ers. In detail, the integral parts of the TOE´s operating system consist of the MICARDO op- erating system layer and the Initialisation Module. Both are based on a Native Platform which serves as an abstraction layer towards the IC. On the other side, the MICARDO layer and the Initialisation Module provide an interface between the operating system and the overlying application layer with the Tachograph Application. The MICARDO operating system layer implements the executable code necessary for the required Tachograph Card commands and the related security features according to the Ta- chograph Card Specification /TachAn1B/, main body, Appendix 2, Appendix 10 (Tachograph Card Generic Security Target) and Appendix 11. As mentioned, the Native Platform of the TOE´s operating system serves as an abstraction layer between the MICARDO operating system layer resp. the Initialisation Module and the IC. For this task, it provides essential operating system components and low level routines concerning memory management, I/O handling, transaction facilities, system management, security features and cryptographic mechanisms. For the cryptographic features, the Native Platform accesses to the IC specific Crypto Li- brary, which supports and implements the TOE´s cryptographic functionality. In view of the Smartcard Embedded Software, the Crypto Library of the IC is accessible only by the Native Platform. For the initialisation process of the TOE conducted within phase 5 of the smartcard product life-cycle (see chap. 96H2.2) the operating system of the TOE puts dedicated initialisation rou- MICARDO Tachograph Version 1.0 R1.0 15 / 139 ST-Lite TOE Description 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel tines at disposal which are solely accessible during the initialisation phase. After the initialisa- tion has been successfully completed these commands are no longer available. Furthermore, the functionality of deleting the complete initialisation file after the initialisation (deletion of the whole EEPROM area) is disabled for the TOE. The Initialisation Module puts the following features at disposal: • specific initialisation routines • specific test routines for the EEPROM area Loading of an initialisation file is only possible by use of the TOE´s specific initialisation rou- tines. Hereby, the initialisation file to be loaded has to be secured before with an encryption and a cryptographic checksum, both done with dedicated keys of the TOE. The test routines for the EEPROM area can be used for a check of the correct functioning of the memory. Furthermore, the Initialisation Module manages the specific states of the TOE´s operating system according to specified and unalterable rules. 2.1.4.2 Application Software The Application Software part of the TOE´s Smartcard Embedded Software comprises the Tachograph Application itself. The Tachograph Application is directly set-up on the TOE´s Basic Software and is imple- mented in conformance with the requirements of the Tachograph Card Specification /TachAn1B/. In detail, the Tachograph Application covers the following components: • Complete file system for a specific type of Tachograph Card (Driver Card, Work- shop Card, Company Card, Control Card) with its dedicated files, elementary files, access conditions and further cryptographic data according to the Tachograph Card Specification /TachAn1B/, main body, Appendix 2 and Appendix 10 (Tacho- graph Card Generic Security Target); alternatively, a piece of code containing in- herently the file system for the four different card types with all relevant dedicated files, elementary files, access conditions and further cryptographic data (note: in this case, one of the prepared file systems has to be blown up prior to the per- sonalisation of the Tachograph Card) • Information on the permitted personalisation scheme incl. related cryptographic key material for personalisation • Key material for the authenticity check of the Tachograph Card product The Tachograph Application will be brought into the smartcard in cryptographically secured form during the initialisation process within phase 5 of the smartcard product life-cycle (see chap. 97H2.2). The initialisation process uses the specific initialisation routines of the TOE´s op- erating system, and the Tachograph Application will be stored in the EEPROM area of the IC. After the initialisation of the Tachograph Card has been completed, the following conditions hold: MICARDO Tachograph Version 1.0 R1.0 16 / 139 ST-Lite TOE Description 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel • The Tachograph Card´s access rules for its file system as applicable for the end- usage phase of the product are neither available nor active at this time. The ac- cess rules have to be activated at the end of the personalisation of the Tacho- graph Card by a change of the status of the operating system. • There is no possibility to delete the Tachograph Application on the Tachograph Card. In particular, there will be neither a deletion of the Application itself nor a deletion of the whole EEPROM area by a regular command of the operating sys- tem possible. • The access conditions within the Tachograph Application are set in such a man- ner that there is no way to modify the (security) structure of the file system or to modify the command set and its (security) properties by using regular card com- mands. • There is no possibility for a further instantiation of the Tachograph Application on the Tachograph Card. • There is no loading of further applications on the Tachograph Card possible. Especially, the above mentioned conditions hold after the Tachograph Card has been issued. For more details about the behaviour of the Tachograph Application within the end-usage phase of the product life-cycle refer to the Tachograph Card Specification /TachAn1B/ and to chap. 98H2.4 of this document. Information on the behaviour of the product within the personal- isation phase can be found in chap. 99H2.3.3. The Tachograph Card offers the capability to check its authenticity. For this purpose, the Tachograph Application contains the private part of a dedicated authentication key pair (RSA 1024 Bit) over which by an internal authentication procedure the authenticity of the Tacho- graph Card can be proven. The authentication key pair depends on the Tachograph Applica- tion and its configuration and may be chosen customer specific. The corresponding public part of the authentication key pair is delivered through a trusted way to the external world. Furthermore, the Tachograph Application contains a data area for storing identification data of the TOE resp. of the TOE´s personalisation. The data area will be filled in the framework of the initialisation resp. the personalisation of the TOE with a specific operating system command and can be read out with a further specific operating system command. Once the identification data have been written, there is afterwards no change possible. MICARDO Tachograph Version 1.0 R1.0 17 / 139 ST-Lite TOE Description 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 2.2 TOE Life-Cycle The smartcard product life-cycle of the TOE is decomposed into seven phases. In each of these phases different authorities with specific responsibilities and tasks are involved: Phase Description Phase 1 Smartcard Embedded Software Develop- ment The Smartcard Embedded Software Developer (Sagem Orga GmbH) is in charge of • the Smartcard Embedded Software (Basic Software, Application Software) development and • the specification of IC initialisation and pre-personalisa- tion requirements (though the actual data for IC initiali- sation and pre-personalisation come from Phase 4, 5 resp. 6). The purpose of the Embedded Software designed during phase 1 is to control and protect the TOE during phases 4 to 7 (product usage).The global security requirements of the TOE are such that it is mandatory during the development phase to anticipate the security threats of the other phases. Phase 2 IC Development The IC Designer (Philips Semiconductors GmbH) • designs the IC, • develops the IC Dedicated Software, • provides information, software or tools to the Smartcard Embedded Software Developer, and • receives the Smartcard Embedded Software (only Basic Software) from the developer through trusted delivery and verification procedures. From the IC design, IC Dedicated Software and Smartcard Em- bedded Software, the IC Designer (Philips Semiconductors GmbH) • constructs the smartcard IC database, necessary for the IC photomask fabrication. Phase 3 IC Manufacturing and Testing The IC Manufacturer (Philips Semiconductors GmbH) is re- sponsible for • producing the IC through three main steps: - IC manufacturing, - IC testing, and - IC pre-personalisation. The IC Mask Manufacturer (Philips Semiconductors GmbH) • generates the masks for the IC manufacturing based upon an output from the smartcard IC database. Phase 4 IC Packaging and Testing The IC Packaging Manufacturer (Sagem Orga GmbH) is re- sponsible for MICARDO Tachograph Version 1.0 R1.0 18 / 139 ST-Lite TOE Description 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel • the IC packaging (production of modules) and • testing. Phase 5 Smartcard Product Finishing Process The Smartcard Product Manufacturer (Sagem Orga GmbH) is responsible for • the initialisation of the TOE (in form of initialisation of the modules of phase 4) and • its testing. The smartcard product finishing process comprises the embed- ding of the initialised modules for the TOE and the card production what is done alternatively by Sagem Orga GmbH or by the cus- tomer. Independent of the type of the TOE´s delivery (initialised module, initialised card), testing of the initialisation process and result is performed by Sagem ORGA prior to the delivery of the product. Final card tests only aim at checking the quality of the card pro- duction, in particular concerning the bonding and implantation of the modules. Phase 6 Smartcard Personalisation The Personaliser is responsible for • the smartcard personalisation and • final tests. Phase 7 Smartcard End-Usage The Smartcard Issuer is responsible for • the smartcard product delivery to the smartcard end- user, and the end of life process. Appropriate procedures for a secure delivery process of the TOE or parts of the TOE under construction from one development resp. production site to another site within the smartcard product life-cycle are established. This concerns any kind of delivery performed from phase 1 to 5, including: - intermediate delivery of the TOE or parts of the TOE under construction within a phase, - delivery of the TOE or parts of the TOE under construction from one phase to the next. In particular, the delivery of the Crypto Library from Philips Semiconductors GmbH to Sagem Orga GmbH follows the dedicated secured delivery process defined in /ST-ICPhilips+Lib/, chap. 2.1.5. The delivery of the ROM mask and the EEPROM pre-personalisation data from Sagem Orga GmbH to Philips Semiconductors GmbH is done by using the dedicated se- cured delivery procedure specified by Philips Semiconductors GmbH following the so-called Philips Order Entry Form P5CC036V1D. The IC manufacturer Philips Semiconductors GmbH delivers the IC with its IC Dedicated Software and the ROM mask supplied by Sagem Orga GmbH at the end of phase 3 in form of wafers according to /UG-ICPhilips/, chap. 2.1, Delivery Method 2, bullet point 1. The IC Dedicated Test Software stored in the Test-ROM is disabled before the delivery of the IC and cannot be used in the following phases. MICARDO Tachograph Version 1.0 R1.0 19 / 139 ST-Lite TOE Description 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel The FabKey procedure described in /UG-ICPhilips/, chap. 2.1, Delivery Method 2, bullet point 2 is replaced by the following procedure which provides at least equivalent security: The TOE´s operating system puts in the non-initialised status the command “Verify ROM” at dis- posal, with which a SHA-1 hash value over the complete ROM and data freely chosen by the external world can be generated. Prior to the initialisation of the IC, the authenticity of the IC with its ROM mask will be proven by using the functionality “Verify ROM” and comparing the new generated hash value over the ROM data and the data freely chosen with a correspond- ing external reference value which is accessible only for Sagem Orga GmbH. With regard to the smartcard product life-cycle of the Tachograph Card described above, the different development and production phases of the TOE with its IC incl. its IC Dedicated Software and with its Smartcard Embedded Software (Basic Software, Application Software) are part of the evaluation of the TOE. Two different ways for the delivery of the TOE are es- tablished: • The TOE is delivered at the end of phase 5 in form of complete cards, i.e. after the initialisation process of the TOE has been successfully finished, final tests have been successfully conducted and the card production has been fulfilled. • Alternatively, the TOE is delivered in form of initialised and tested modules. In this case, the smartcard finishing process (embedding of the delivered modules, final card tests) is task of the customer. MICARDO Tachograph Version 1.0 R1.0 20 / 139 ST-Lite TOE Description 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 2.3 TOE Environment Considering the TOE and its life-cycle described above, four types of environments can be distinguished: - development environment corresponding to phase 1 and 2, - production environment corresponding to phase 3 to phase 5, - personalisation environment corresponding to phase 6, - end-user environment corresponding to phase 7. 2.3.1 Development Environment Phase 1 - Smartcard Embedded Software Development To assure security of the development process of the Smartcard Embedded Software, a se- cure development environment with appropriate personnel, organisational and technical se- curity measures at Sagem Orga GmbH is established. Only authorized and experienced personnel which understands the importance and the rigid implementation of the defined security procedures is involved in the development activities. The development process comprises the specification, the design, the coding and the testing of the Smartcard Embedded Software. For design, implementation and test purposes secure computer systems preventing unauthorized access are used. For security reasons the coding and testing activities will be done independently of each other. All sensitive documentation, data and material concerning the development process of the Smartcard Embedded Software are handled in an appropriately and sufficiently secure way. This concerns both the transfer as well as the storing of all related sensitive documents, data and material. Furthermore, all development activities run under a configuration control sys- tem which guarantees for an appropriate traceability and accountability. The Smartcard Embedded Software of the developer, more precise the Basic Software part dedicated for the ROM of the IC, is delivered to the IC manufacturer through trusted delivery and verification procedures. The Application Software and additional parts of the Basic Soft- ware are delivered in form of a cryptographically secured initialisation file as well through trusted delivery and verification procedures to the initialisation center. Phase 2 – IC Development During the design and layout process only people involved in the specific development pro- ject for the IC have access to sensitive data. Different people are responsible for the design data of the IC and for customer related data. The security measures installed at Philips Semiconductors GmbH ensure a secure computer system and provide appropriate equip- ment for the different development tasks. MICARDO Tachograph Version 1.0 R1.0 21 / 139 ST-Lite TOE Description 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 2.3.2 Production Environment Phase 3 - IC Manufacturing and Testing The verified layout data are provided by the developers of Philips Semiconductors GmbH directly to the wafer fab. The wafer fab generates and forwards the layout data related to the relevant photomask to the IC mask manufacturer (Philips Semiconductors GmbH). The photomask is generated off-site and verified against the design data of the development before usage. The accountability and traceability is ensured among the wafer fab and the photomask provider. The production of the wafers includes two different steps regarding the production flow. In the first step the wafers are produced with the fixed mask independent of the customer. After that step the wafers are completed with the customer specific mask and the remaining mask. The computer tracking ensures the control of the complete process including the storage of the semifinished wafers. The test process of every die is performed by a test centre of Philips Semiconductors GmbH. Delivery processes between the involved Philips Semiconductors GmbH sites provide ac- countability and traceability of the produced wafers. The delivery of the ICs from Philips Semiconductors GmbH to Sagem Orga GmbH is made in form of wafers whereby non- functional ICs are marked on the wafer. Phase 4 – IC Packaging and Testing For security reasons the processes of IC packaging and testing at Sagem Orga GmbH are done in a secure environment with adequate personnel, organisational and technical security measures. Only authorized and experienced personnel which understands the importance and the rigid implementation of the defined security procedures is involved in these activities. All sensitive material and documentation concerning the production process of the TOE is handled in an appropriately and sufficiently secure way. This concerns both the transfer as well as the storing of all related sensitive material and documentation. All operations are done in such a way that appropriate traceability and accountability exist. Phase 5 - Smartcard Product Finishing Process To assure security of the initialisation process of the TOE, a secure environment with ade- quate personnel, organisational and technical security measures at Sagem Orga GmbH is established. Only authorized and experienced personnel which understands the importance and the rigid implementation of the defined security procedures is involved in the initialisation and test activities. The initialisation process of the TOE comprises the loading of the TOE´s Application Soft- ware and the remaining EEPROM-parts of the TOE´s Basic Software which have been MICARDO Tachograph Version 1.0 R1.0 22 / 139 ST-Lite TOE Description 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel specified, coded, tested and cryptographically secured in phase 1 of the product life-cycle. The TOE allows only the initialisation of the intended initialisation file with its Application Software and its parts of the Basic Software. For security reasons, secure systems within a separate network and preventing unauthorized access are used for the initialisation process. If the TOE is delivered in form of initialised and tested modules, the smartcard finishing proc- ess, i.e. the embedding of the delivered modules and final tests, is task of the customer. Otherwise, the smartcard finishing process is part of the production process at Sagem Orga GmbH, and the TOE is delivered in form of complete (initialised) cards. All sensitive documentation, data and material concerning the production processes of the TOE at Sagem Orga GmbH within phase 5 are handled in an appropriately and sufficiently secure way. This concerns both the transfer as well as the storing of all related sensitive documents, data and material. Furthermore, all operations run under a control system which supplies appropriate traceability and accountability. At the end of this phase, the TOE is complete as smartcard and can be supplied for delivery to the personalisation centre for personalisation. 2.3.3 Personalisation Environment Note: The phases from the TOE delivery at the end of phase 5 to phase 7 in the smartcard product life-cycle are not part of theTOE development and production process in the sense of this Security Target. Information about the phases 6 and 7 are just included to describe how the TOE is used after its development and production. The development and production of the TOE are done in such a way that the security features of the TOE are independent of the user data loaded during the TOE´s personalisation and cannot be disabled by the personal- isation data in the phases afterwards. Phase 6 - Smartcard Personalisation The security of the personalisation process of the TOE is supported by the TOE and its Ap- plication Software itself. The following personalisation schemes are provided by the Tacho- graph Card: • Dynamic scheme with Secure Messaging using a session key: The TOE allows a personalisation only after a successful preceding mutual au- thentication between the TOE and the external world with agreement of a session key and send sequence counter. The authentication protocol follows the proce- dure described in the Tachograph Card Specification /TachAn1B/, Appendix 11, chap. 4 and makes use of asymmetric keys. The keys necessary on the card for the authentication procedure, i.e. the public key of the personalisation unit and the personalisation key pair of the card, are part of the Application Software (Tacho- graph Application) and are loaded onto the card in the framework of the initialisa- tion. The following data transfer of the personalisation data has to be conducted with Secure Messaging according to /TachAn1B/, Appendix 11, chap. 5 using the session key and send sequence counter negotiated during the preceding authen- tication process. MICARDO Tachograph Version 1.0 R1.0 23 / 139 ST-Lite TOE Description 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel • Static scheme with Secure Messaging using a static key: The TOE allows a personalisation only under usage of a static symmetric person- alisation key which is stored on the card during the initialisation of the card or later within an additional pre-personalisation phase. In the latter case, the symmetric personalisation key has to be loaded with a specific card command in encrypted form (using the public key of the card´s asymmetric personalisation key pair stored during initialisation). The data transfer of the personalisation data has to be conducted with Secure Messaging according to /TachAn1B/, Appendix 11, chap. 5 using the static personalisation key (and the send sequence counter set by the card). Usage of the static personalisation key for securing the data transfer of the personalisation data is only possible after a successful preceding external authen- tication of the external world (personalisation unit). In each case, the personalisation of the Tachograph Card requires a preceding authentica- tion of the external world (personalisation unit). Key material necessary for securing the per- sonalisation process is delivered by Sagem Orga GmbH, if applicable, in a trusted manner. The personalisation schemes permitted by the delivered configuration of the Tachograph Card are set up within the Tachograph Application and are defined in the framework of the generation of the Tachograph Application within phase 1 of the product life-cycle. The establishment of a secure environment for the personalisation process with adequate personnel, organisational and technical security measures is in the responsibility of the per- sonalisation centre itself. Furthermore, the secure key management and handling of the cryp- tographic keys for securing the data transfer within the personalisation process and the se- cure handling of the personalisation data itself is task of the external world resp. the person- alisation centre. 2.3.4 End-User Environment Phase 7 – Smartcard End-usage The TOE after its personalisation is destinated for use in the Tachograph System as a secu- rity medium and data carrier for different user types which is secured against forgery and tampering. For further details concerning the use of the Tachograph Card refer to chap. 100H2.4. The TOE is constructed in such a manner that it implements all security requirements of the Tachograph Card Specification /TachAn1B/. There is no possibility, even in an unsecure end-user environment, to disable or to circumvent the security features of the TOE. MICARDO Tachograph Version 1.0 R1.0 24 / 139 ST-Lite TOE Description 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 2.4 TOE Intended Usage In this section, the intended usage of the TOE within the end-usage phase of the product life- cycle (phase 7), i.e. in personalised form will be regarded more detailed. According to the Tachograph Card Specification /TachAn1B/ and the interpretations in /JILDigTacho/ a Tachograph Card is defined as a smartcard product compliant to the Protec- tion Profiles /PP9806/ resp. /BSI-PP-0002/ and /PP9911/ and carrying a specific application intended for its use with the recording equipment. Tachograph Cards allow for identification of the identity (or identity group) of the cardholder by the recording equipment and allow for data transfer and storage. A Tachograph Card may be of the following types: • Driver Card: a Tachograph Card issued by the authorities of a Member State to a particular driver; identifies the driver and allows for storage of driver activity data • Control Card: a Tachograph Card issued by the authorities of a Member State to a national competent control authority; identifies the control body and possibly the control of- ficer and allows for getting access to the data stored in the data memory or in the driver cards for reading, printing and/or downloading • Workshop Card: a Tachograph Card issued by the authorities of a Member State to a recording equipment manufacturer, a fitter, a vehicle manufacturer or workshop approved by that Member State; identifies the cardholder and allows for testing, calibration and/or downloading of the recording equipment • Company Card: a Tachograph Card issued by the authorities of a Member State to the owner or holder of vehicles fitted with recording equipment; identifies the company and al- lows for displaying, downloading and printing of the data stored in the recording equipment which has been locked by this company The basic functions of the Tachograph Card are the following: • to store card identification and card holder identification data; these data are used by the vehicle unit to identify the cardholder, provide accordingly functions and data access rights, and ensure cardholder accountability for his activities • to store cardholder activities data, events and faults data and control activities data related to the cardholder A Tachograph Card is therefore intended to be used by a card interface device of a vehicle unit. It may also be used by any card reader (e.g. of a personal computer) which shall have full read access right on any user data. During the end-usage phase of a Tachograph Card (phase 7 of the smartcard product life- cycle), vehicle units only may write user data to the card. MICARDO Tachograph Version 1.0 R1.0 25 / 139 ST-Lite TOE Description 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Regarding the security of the Tachograph System, the system security aims at: • protecting integrity and authenticity of data exchanged between the cards and the recording equipment • protecting the integrity and authenticity of data downloaded from the cards • allowing certain write operations onto the cards to recording equipment only • ruling out any possibility of falsification of data stored in the cards • preventing tampering and detecting any attempt of that kind Especially the following security mechanisms are relevant for the Tachograph Card: • mutual authentication between a vehicle unit and a Tachograph Card, including session key agreement • confidentiality, integrity and authentication of data transferred between a vehicle unit and a Tachograph Card • integrity and authentication of data downloaded from a Tachograph Card to exter- nal storage media The Tachograph Card offers a classical RSA public-key cryptographic system to provide the following security mechanisms: • authentication between a vehicle unit and a Tachograph Card • transport of Triple-DES session keys between a vehicle unit and a Tachograph Card • digital signature of data downloaded from a Tachograph Card to external media Furthermore, the Tachograph Card offers a Triple DES symmetric cryptographic system to provide a mechanism for data integrity during user data exchange between a vehicle unit and a Tachograph Card, and to provide, where applicable, confidentiality of data exchange bet- ween a vehicle unit and a Tachograph Card. MICARDO Tachograph Version 1.0 R1.0 26 / 139 ST-Lite TOE Security Environment 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 3 TOE Security Environment 3.1 Assets Assets are security–relevant elements to be directly protected by the TOE whereby assets have to be protected in terms of confidentiality and integrity. Confidentiality of assets is al- ways intended with respect to untrusted users of the TOE and its security-critical compo- nents, whereas the integrity of assets is relevant for the correct operation of the TOE and its security-critical components. The confidentiality of the code of the TOE is included in this ST for several reasons. First, the confidentiality is needed for the protection of intellectual/industrial property on security or effectiveness mechanisms. Second, though protection shall not rely exclusively on code con- fidentiality, disclosure of the code may weaken the security of the involved application. For instance, knowledge about the implementation of the operating system or the Tachograph Application itself may benefit an attacker. This also applies to internal data of the TOE, which may similarly provide leads for further attacks. For a description of the TOE´s assets refer to /TachAn1B/, Appendix 10 (Tachograph Card Generic Security Target), /PP9911/, chap. 3.1, /BSI-PP-0002/, chap. 3.1, /ST-ICPhilips/, chap. 3.1. The assets of the TOE sorted in primary and seconday assets are listed in the tables below: Primary Assets Part of the TOE Definition IC --- Smartcard Embedded Software / Basic Soft- ware --- Smartcard Embedded Software / Application Software - application specific user data (refer to /TachAn1B/, Appendix 10, Tachograph Card Generic Security Target, chap. 2.2) as - identification data (card identification data, cardholder identifica- tion data) - activity data (cardholder activities data, events and faults data, control activity data) MICARDO Tachograph Version 1.0 R1.0 27 / 139 ST-Lite TOE Security Environment 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Secondary Assets Part of the TOE Definition IC - logical design data - physical design data - IC Dedicated Software - initialisation data - pre-personalisation data - specific development aids - test and characterisation related data - material for software development support - photomasks - the special functions for the communication with an external inter- face device - the cryptographic co-processor for Triple-DES - the FameX co-processor for basic arithmetic functions to perform asymmetric cryptographic algorithms - the random number generator - TSF data Smartcard Embedded Software / Basic Soft- ware - specifications - code - related documentation - system specific data - initialisation data - specific development aids - test and characterisation related data - material for software development support - TSF data Smartcard Embedded Software / Application Software - specifications - code - related documentation - system specific data - initialisation data - specific development aids - test and characterisation related data - material for software development support - user data related documentation - TSF data, especially the application specific security data (refer to /TachAn1B/, Appendix 10, Tachograph Card Generic Security Tar- get, chap. 2.2) MICARDO Tachograph Version 1.0 R1.0 28 / 139 ST-Lite TOE Security Environment 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 3.2 Assumptions 3.2.1 General Assumptions for the TOE The general assumptions made on the environment of the TOE are defined according to /PP9911/, chap. 3.2 and are suitably supplemented for the TOE. The complete set of as- sumptions is listed in the table below. Note: In the following table, items of /PP9911/ which are common with /PP9806/ are indicated by a “*”. Assumptions for the Environment of the TOE Name Definition Assumptions on Phase 1 to 5 A.DEV_ORG* (PP9911+supplement) Protection of the TOE under Development and Production Procedures dealing with physical, personnel, organizational, technical meas- ures for the confidentiality and integrity of the Smartcard Embedded Software (e.g. source code and any associated documents) and IC designer proprietary information (tools, software, documentation ...) shall exist and be applied in software development. All authorities involved in the development and production of the TOE shall carry out their development and production activities in a suitable and secure environment. Each party has to ensure that the development and production of the TOE (incl. IC with its Dedicated Software, Smartcard Embedded Software) is secure so that no information is unintentionally made available for the later operational phase of the TOE. In particular, the confidentiality and integrity of design information and test data shall be guaranteed, access to development and test tools, samples and other sensitive material shall be restricted to author- ised persons only etc. Assumptions on the TOE Delivery Process (Phases 4 to 7) A.DLV_PROTECT* (PP9911) Protection of the TOE under Delivery and Storage Procedures shall ensure protection of TOE material / information under delivery and storage. A.DLV_AUDIT* (PP9911) Audit of Delivery and Storage Procedures shall ensure that corrective actions are taken in case of improper operation in the delivery process and storage. MICARDO Tachograph Version 1.0 R1.0 29 / 139 ST-Lite TOE Security Environment 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel A.DLV_RESP* (PP9911) Responsibility within Delivery Procedures shall ensure that people dealing with the procedure for delivery have got the required skill. Assumptions on Phases 4 to 6 A.USE_TEST* (PP9911) Testing of the TOE It is assumed that appropriate functionality testing of the TOE is used in phases 4, 5 and 6. A.USE_PROD* (PP9911) Protection of the TOE under Testing and Manufacturing It is assumed that security procedures are used during all manufacturing and test operations through phases 4, 5, 6 to maintain confidentiality and integrity of the TOE and of its manufacturing and test data (to prevent any possible copy, modification, retention, theft or unauthorized use). Assumptions on Phase 6 A.PERS The originator of the personalisation data and the personalisation center re- sponsible for the personalisation of the TOE handles the personalisation data in an adequate secure manner. This concerns especially the security data to be personalised as secret cryptographic keys and PINs. The storage of the per- sonalisation data at the originator and at the personalisation center as well as the transfer of these data between the different sites is conducted with respect to data integrity and confidentiality. Furthermore, the personalisation center treats the data for securing the person- alisation process, i.e. the personalisation keys suitably secure. It is in the responsibility of the originator of the personalisation data to garan- tuee for a sufficient quality of the personalisation data, especially of the crypto- graphic material to be personalised. The preparation and securing of the per- sonalisation data appropriate to the Tachograph Card´s structure and according to the TOE´s personalisation requirements is as well in the responsibility of the external world and is done with care. Assumptions on Phase 7 A.USE_DIAG* (PP9911) Secure Communication It is assumed that secure communication protocols and procedures are used between smartcard and terminal. MICARDO Tachograph Version 1.0 R1.0 30 / 139 ST-Lite TOE Security Environment 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 3.2.2 Tachograph Card Specific Assumptions for the TOE There do not exist any Tachograph Card specific assumptions for the environment of the TOE. 3.3 Threats The TOE is required to counter different type of attacks against its specific assets. A threat agent could try to threaten these assets either by functional attacks or by environmental ma- nipulation, by specific hardware manipulation, by a combination of hardware and software manipulations or by any other type of attacks. Generally, threats can be split into the following types: - threats against which a specific protection by the TOE is required - threats against which a specific protection by the environment is required - threats against which a specific protection by a combination of the TOE and the environ- ment is required Before listing the general threats for the TOE, several preliminary remarks about these threats: Threats on phase 1 During phase 1, three types of threats have to be considered: - threats on the TOE-ES and its development environment, such as unauthorized disclo- sure, modification or theft of the TOE-ES and/or initialisation data - threats on the assets transmitted from the IC designer to the TOE-ES developer during the TOE-ES development - threats on the TOE-ES and initialisation data transmitted during the delivery process from the TOE-ES software developer to the IC designer Furthermore, one can consider the threats under the aspect of disclosure, theft, use or modi- fication: - Unauthorized disclosure of assets: This type of threats covers unauthorized disclosure of assets by attackers who may pos- sess a wide range of technical skills, resources and motivation. Such attackers may also have technical awareness of the product. - Theft or unauthorized use of assets: Potential attackers may gain access to the TOE and perform operations for which they are not authorized. For example, such an attacker may personalize, modify or influence the product in order to gain access to the smartcard application system. MICARDO Tachograph Version 1.0 R1.0 31 / 139 ST-Lite TOE Security Environment 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel - Unauthorized modification of assets: The TOE may be subjected to different types of logical or physical attacks which may compromise security. Due to the intended usage of the TOE (the TOE environment may be hostile), the TOE security may be bypassed or compromised reducing the integrity of the TOE security mechanisms and disabling their ability to manage the TOE security. This type of threats includes the implementation of malicious Trojan horses. Threats on delivery from phase 1 to phases 4 to 6 Threats on data transmitted during the delivery process from the TOE-ES developer to the IC packaging manufacturer, the Finishing process manufacturer or the Personalizer. Threats on phases 4 to 7 During these phases, the assumed threats could be divided in three types: - Unauthorized disclosure of assets: This type of threats covers unauthorized disclosure of assets by attackers who may pos- sess a wide range of technical skills, resources and motivation. Such attackers may also have technical awareness of the product. - Theft or unauthorized use of assets: Potential attackers may gain access to the TOE and perform operation for which they are not allowed. For example, such attackers may personalize the product in an unauthorized manner, or try to gain fraudulently access to the smartcard system. - Unauthorized modification of assets: The TOE may be subjected to different types of logical or physical attacks which may compromise security. Due to the intended usage of the TOE (the TOE environment may be hostile), the TOE security parts may be bypassed or compromised reducing the integ- rity of the TOE security mechanisms and disabling their ability to manage the TOE secu- rity. This type of threat includes the implementation of malicious Trojan horses, Trap- doors, downloading of viruses or unauthorized programs. 3.3.1 Threats of the IC (TOE-IC) For the definition of the threats related to the TOE-IC refer to /BSI-PP-0002/, chap. 3.3, /ST- ICPhilips/, chap. 3.3 and /ST-ICPhilips+Lib/, chap. 3.3. Here, only the threats concerning phase 7 of the product life-cycle are considered. 3.3.2 General Threats of the Smartcard Embedded Software (TOE-ES) The table below lists the general threats to the assets of the TOE-ES against which specific protection within the TOE or its environment is required. Several groups of threats are distin- guished according to the means used in the attack and to the phases of the TOE that are affected. The threats to the TOE-ES are defined as indicated in /PP9911/, chap. 3.3. MICARDO Tachograph Version 1.0 R1.0 32 / 139 ST-Lite TOE Security Environment 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Note: In the following table, items of /PP9911/ which are common with /PP9806/ are indicated by a “*”. Threats / TOE-ES Name Definition Threats on all Phases T.CLON* (PP9911) Cloning of the TOE Unauthorized full or partional functional cloning of the TOE. Note: This threat is derived from specific threats combining unauthorized disclosure, modification or theft of assets at different phases. Threats on Phase 1 T.DIS_INFO* (PP9911) Disclosure of IC Assets Unauthorized disclosure of the assets delivered by the IC designer to the Smartcard Embedded Software developer, such as sensitive information on IC specification, de- sign and technology, software and tools if applicable. T.DIS_DEL* (PP9911) Disclosure of the Smartcard Embedded Software / Application Data during De- livery Unauthorized disclosure of the Smartcard Embedded Software and any additional application data (such as IC Pre-personalization requirements) during the delivery from the Smartcard Embedded Software developer to the IC designer. T.DIS_ES1 (PP9911) Disclosure of the Smartcard Embedded Software / Application Data within the Development Environment Unauthorized disclosure of the Smartcard Embedded Software (technical or detailed specifications, implementation code) and/or Application Data (such as secrets, or con- trol parameters for protection system, specification and implementation for security mechanisms) within the development environment. T.DIS_TEST_ES (PP9911) Disclosure of Smartcard Embedded Software Test Programs / Information Unauthorized disclosure of the the Smartcard Embedded Software test programs or any related information. T.T_DEL* (PP9911) Theft of the Smartcard Embedded Software / Application Data during Delivery Theft of the Smartcard Embedded Software and any additional application data (such as pre-personalization requirements) during the delivery process from the Smartcard Embedded Software developer to the IC designer. T.T_TOOLS (PP9911) Theft or Unauthorized Use of the Smartcard Embedded Software Development Tools MICARDO Tachograph Version 1.0 R1.0 33 / 139 ST-Lite TOE Security Environment 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Theft or unauthorized use of the Smartcard Embedded Software development tools (such as PC, development software, data bases). T.T_SAMPLE2 (PP9911) Theft or Unauthorized Use of TOE Samples Theft or unauthorized use of TOE samples (e.g. bond-out chips with the Smartcard Embedded Software). T_MOD_DEL* (PP9911) Modification of the Smartcard Embedded Software / Application Data during Delivery Unauthorized modification of the Smartcard Embedded Software and any additional application data (such as IC prepersonalization requirements) during the delivery pro- cess from the Smartcard Embedded Software developer to the IC designer. T.MOD (PP9911) Modification of the Smartcard Embedded Software / Application Data within the Development Environment Unauthorized modification of the Smartcard Embedded Software and/or Application Data or any related information (technical specifications) within the development envi- ronment. Threats on De- livery from Phase 1 to Phases 4 / 5 / 6 T.DIS_DEL1 (PP9911) Disclosure of Application Data during Delivery Unauthorized disclosure of Application Data during delivery from the Smartcard Em- bedded Software developer to the IC Packaging manufacturer, the Finishing process manufacturer or the Personalizer. T.DIS_DEL2 (PP9911) Disclosure of Delivered Application Data Unauthorized disclosure of Application Data delivered from the Smartcard Embedded Software developer to the IC Packaging manufacturer, the Finishing process manufac- turer or the Personalizer. T.MOD_DEL1 (PP9911) Modification of Application Data during Delivery Unauthorized modification of Application Data during delivery from the Smartcard Em- bedded Software developer to the IC Packaging manufacturer, the Finishing process manufacturer or the Personalizer. T.MOD_DEL2 (PP9911) Modification of Delivered Application Data Unauthorized modification of Application Data delivered from the Smartcard Embed- ded Software developer to the IC Packaging manufacturer, the Finishing process manufacturer or the Personalizer. Threats on Phases 4 to 7 T.DIS_ES2 Disclosure of the Smartcard Embedded Software / Application Data MICARDO Tachograph Version 1.0 R1.0 34 / 139 ST-Lite TOE Security Environment 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel (PP9911) Unauthorized disclosure of the Smartcard Embedded Software and Application Data (such as data protection systems, memory partitioning, cryptographic programs and keys). T.T_ES (PP9911) Theft or Unauthorized Use of TOE Theft or unauthorized use of the TOE (e.g. bound out chips with the Smartcard Em- bedded Software). T.T_CMD (PP9911) Use of TOE Command-Set Unauthorized use of instructions or commands or sequence of commands sent to the TOE. T.MOD_LOAD (PP9911) Program Loading Unauthorized loading of programs. T.MOD_EXE (PP9911) Program Execution Unauthorized execution of programs. T.MOD_SHARE (PP9911) Modification of Program Behavior Unauthorized modification of program behavior by interaction of different programs. T.MOD_SOFT* (PP9911) Modification of Smartcard Embedded Software / Application Data Unauthorized modification of the Smartcard Embedded Software and Application Data. 3.3.3 Tachograph Card Specific Threats The following table lists the specific threats relevant for the Tachograph Application within the TOE-ES. The threats are provided by the Tachograph Card Specification /TachAn1B/, Ap- pendix 10, Tachograph Card Generic Security Target, chap. 3.3 and are supplemented for the TOE´s personalisation. Threats / TOE-ES (Tachograph Card Specific Threats) Name Definition T.Ident_Data Modification of Identification Data A successful modification of identification data held by the TOE (e.g. the type of card, or the card expiry date or the cardholder identification data) would allow a fraudulent use of the TOE and would be a major threat to the global security objective of the sys- tem. T.Activity_Data Modification of Activity Data MICARDO Tachograph Version 1.0 R1.0 35 / 139 ST-Lite TOE Security Environment 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel A successful modification of activity data stored in the TOE would be a threat to the security of the TOE. T.Data_ex- change Modification of Activity Data during Data Transfer A successful modification of activity data (addition, deletion, modification) during im- port or export would be a threat to the security of the TOE. T.Pers_Data Authentication for Personalisation A successful storage of personalisation data without authorisation (of the external world) would be a threat to the security of the TOE. T.Pers_ex- change Modification or Disclosure of Personalisation Data during Data Transfer A successful modification or disclosure of personalisation data during data import would be a threat to the security of the TOE. 3.4 Organisational Security Policies of the TOE The TOE reaches is specific security functionality only by a correct and effective implementa- tion of the underlying IC and its security functionality by the Smartcard Embedded Software (TOE-ES). In particular this means, that the TOE-ES must fulfill the assumptions for the TOE-ES as defined in the Security Target for the TOE-IC. The relevant assumptions for the TOE-ES as given in /ST-ICPhilips+Lib/, chap. 3.2 (refer also to /ST-ICPhilips/, chap. 3.2 and /BSI-PP-0002/, chap. 3.2) are suitably redefined in terms of Organisational Security Policies for the TOE as follows: Organisational Security Policy for the TOE Name Definition P.Process-Card (A.Process-Card in ST-ICPhilips+Lib) Protection during Packaging, Finishing and Personalisation Security procedures shall be used after TOE-IC delivery up to delivery to the end- user to maintain confidentiality and integrity of the TOE-IC and of its manufactur- ing and test data (to prevent any possible copy, modification, retention, theft or unauthorised use). P.Design-Software (A.Plat-Appl, A.Resp- Appl, A.Check-Init, A.Key-Function, A.Preconditions in ST-ICPhilips+Lib) Design of the Smartcard Embedded Software To ensure that the TOE-IC is used in a secure manner the Smartcard Embedded Software (TOE-ES) shall be designed so that the requirements from the following documents are met: - hardware data sheet for the TOE-IC, - TOE-IC application notes, - findings of the TOE-IC evaluation reports relevant for the Smartcard Embed- MICARDO Tachograph Version 1.0 R1.0 36 / 139 ST-Lite TOE Security Environment 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel ded Software (TOE-ES). Security relevant user data (especially cryptographic keys) are treated by the Smartcard Embedded Software (TOE-ES) as required by the security needs of the specific application context. For example the Smartcard Embedded Software (TOE-ES) will not disclose security relevant user data to unauthorised users or processes when communicating with a terminal. The Smartcard Embedded Software shall provide a function to check initialisation data. The data is defined by the customer and injected by the TOE Manufacturer into the non-volatile memory to provide the possibility for TOE identification and for traceability. The check shall include at least the Fabkey Data that is agreed between the TOE-ES developer and the TOE-IC Manufacturer. Key-dependent functions shall be implemented in the Smartcard Embedded Software in a way that they are not susceptible to leakage attacks. In case that resistance of the SHA-1 implementation against side channel attacks is required, the Smartcard Embedded Software developer shall ensure that the necessary operational preconditions are met. When using the RSA-CRT function of the Crypto Library without integrated DFA countermeasures, the Smartcard Embedded Software developer first shall ana- lyse and decide whether DFA attacks are applicable in the specific field of appli- cation, and then shall implement effective DFA countermeasures on his own, if applicable. MICARDO Tachograph Version 1.0 R1.0 37 / 139 ST-Lite Security Objectives 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 4 Security Objectives 4.1 Security Objectives for the TOE The security objectives for the TOE cover principally the following aspects: • integrity and confidentiality of the TOE´s assets • protection of the TOE and its associated documentation and environment during the development and production phases. 4.1.1 Security Objectives for the TOE-IC For the definition of the security objectives related to the TOE-IC refer to /BSI-PP-0002/, chap. 4.1, /ST-ICPhilips/, chap. 4.1 and /ST-ICPhilips+Lib/, chap.4.1. Here, only the security objectives concerning phase 7 of the product life-cycle are considered. 4.1.2 General Security Objectives for the TOE-ES Nearly all security objectives mentioned in the table below concern the general security ob- jectives for the TOE-ES as defined in /PP9911/, chap. 4.1. These security objectives are supplemented by security objectives drawn from /BSI-PP-0002/, chap. 4.2, /ST-ICPhilips/, chap. 4.2 and /ST-ICPhilips+Lib/, chap. 4.2, which will be in the current scope switched from assumptions resp. security objectives for the environment of the IC to security objectives for the TOE-ES. The complete set of security objectives for the TOE-ES is listed in the table below. Note: For clarity, within the description of the security objectives in the following table as indicated in /BSI-PP-0002/, /ST-ICPhilips/ resp. /ST-ICPhilips+Lib/ the word „TOE“ is replaced by „TOE-IC“ and the term „Smartcard Embedded Software“ is supplemented by „TOE-ES“. Note: In the following table, items of /PP9911/ which are common with /PP9806/ are indicated by a “*”. Security Objectives / TOE-ES Name Definition O.CLON* (PP9911) Cloning The TOE functionality must be protected from cloning. O.OPERATE* Correct Operation MICARDO Tachograph Version 1.0 R1.0 38 / 139 ST-Lite Security Objectives 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel (PP9911) The TOE must ensure continued correct operation of its security functions. O.FLAW* (PP9911) Flaws The TOE must not contain flaws in design, implementation or operation. O.DIS_MEMORY* (PP9911) Disclosure of Memory Contents The TOE shall ensure that sensitive information stored in memories is protected against unauthorized disclosure. O.MOD_MEMORY* (PP9911) Modification of Memory Contents The TOE shall ensure that sensitive information stored in memories is protected against any corruption or unauthorized modification. O.TAMPER_ES (PP9911) Tampering of the Smartcard Embedded Software The TOE must prevent tampering with its security critical parts. Security mechanisms have especially to prevent the unauthorized change of functional parameters, security attributes and secrets such as the life cycle sequence flags and cryptographic keys. The Smartcard Embedded Software must be designed to avoid interpretations of electrical signals from the hardware part of the TOE. O.DIS_MECHANISM2 (PP9911) Disclosure of Security Mechanisms of the Smartcard Embedded Software The TOE shall ensure that the Smartcard Embedded Software security mecha- nisms are protected against unauthorized disclosure. O.Plat-Appl (OE.Plat-Appl in ST- ICPhilips+Lib) Usage of Hardware Platform To ensure that the TOE-IC is used in a secure manner the Smartcard Embed- ded Software (TOE-ES) shall be designed so that the requirements from the following documents are met: - hardware data sheet for the TOE-IC, - TOE-IC application notes, - findings of the TOE-IC evaluation reports relevant for the Smartcard Em- bedded Software (TOE-ES). O.Resp-Appl (OE.Resp-Appl in ST- ICPhilips+Lib) Treatment of User Data Security relevant user data (especially cryptographic keys) shall be treated by the Smartcard Embedded Software (TOE-ES) as required by the security needs of the specific application context. For example the Smartcard Embedded Soft- ware (TOE-ES) shall not disclose security relevant user data to unauthorised users or processes when communicating with a terminal. O.Check-Init (OE.Check-Init in ST- ICPhilips+Lib) Check of initialisation data by the Smartcard Embedded Software To ensure the receipt of the correct TOE-IC, the Smartcard Embedded Software (TOE-ES) shall provide a function to check initialisation data. The data is defi- ned by the customer and injected by the TOE Manufacturer into the non-volatile memory to provide the possibility for TOE identification and for traceability. The check shall include at least the Fabkey Data that is agreed between the TOE- ES developer and the TOE-IC Manufacturer. O.Key-Function Usage of Key-dependent Functions MICARDO Tachograph Version 1.0 R1.0 39 / 139 ST-Lite Security Objectives 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel (A.Key-Function in ST- ICPhilips+Lib) Key-dependent functions shall be implemented in the Smartcard Embedded Software (TOE-ES) in a way that they are not susceptible to leakage attacks. O.Preconditions (OE.Preconditions in ST-ICPhilips+Lib) Operational Pre-Conditions In case that resistance of the SHA-1 implementation against side channel at- tacks is required, the Smartcard Embedded Software developer shall ensure that the necessary operational preconditions are met. When using the RSA-CRT function of the Crypto Library without integrated DFA countermeasures, the Smartcard Embedded Software developer first shall ana- lyse and decide whether DFA attacks are applicable in the specific field of ap- plication, and then shall implement effective DFA countermeasures on his own, if applicable. 4.1.3 Tachograph Card Specific Security Objectives The following table lists the specific security objectives relevant for the Tachograph Applica- tion. The security objectives are drawn from the Tachograph Card Specification /TachAn1B/, Appendix 10, Tachograph Card Generic Security Target, chap. 3.4 and 3.5 and are supple- mented by an additional security objective for the personalisation of the TOE. Security Objectives / TOE-ES (Tachograph Card Specific Security Objectives) Name Definition O.Card_Identifica- tion_Data Storage of Identification Data The TOE must preserve card identification data and cardholder identifica- tion data stored during card personalisation process. O.Card_Activity_- Storage Storage of Activity Data The TOE must preserve user data stored in the card by vehicle units. O.Data_Access User Data Write Access The TOE must limit user data write access rights to authenticated vehicle units. O.Pers_Access Personalisation Data Write Access The TOE must limit personalisation data write access rights to authenti- cated personalisation units. O.Secure_- Communications Secure Communications The TOE must be able to support secure communication protocols and procedures between the card and the card interface device when required by the application. MICARDO Tachograph Version 1.0 R1.0 40 / 139 ST-Lite Security Objectives 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 4.2 Security Objectives for the Environment 4.2.1 General Security Objectives for the Environment of the TOE Nearly all general security objectives for the environment of the TOE are defined in /PP9911/, chap. 4.2. These security objectives are supplemented by security objectives drawn from /BSI-PP-0002/, chap. 4.2, /ST-ICPhilips/, chap. 4.2 and /ST-ICPhilips+Lib/, chap. 4.2, and a further specific security objective for the TOE´s personalisation. All of these security objectives have to be fulfilled by organisational measures, thus they are security objectives for the Non-IT-Environment of the TOE. Security objectives for the IT- Environment of the TOE are not present. The complete set of security objectives for the environment is listed in the table below. Note: For clarity, within the description of the security objectives in the following table as given in /BSI-PP-0002/, /ST-ICPhilips/ resp. /ST-ICPhilips+Lib/ the word „TOE“ is replaced by „TOE- IC“ and the term „Smartcard Embedded Software“ is supplemented by „TOE-ES“. Note: In the following table, items of /PP9911/ which are common with /PP9806/ are indicated by a “*”. Security Objectives for the Environment of the TOE Name Definition Objectives on Phase 1 O.DEV_TOOLS* (PP9911) Development Tools for the Smartcard Embedded Software The Smartcard Embedded Software shall be designed in a secure manner, by using exclusively software development tools (compilers assemblers, linkers, simulators, etc.) and software-hardware integration testing tools (emulators) that will result in the integrity of program and data. O.DEV_DIS_ES (PP9911) Development of the Smartcard Embedded Software The Smartcard Embedded Software developer shall use established proce- dures to control storage and usage of the classified development tools and documentation, suitable to maintain the integrity and the confidentiality of the assets of the TOE. It must be ensured that tools are only delivered and accessible to the parties authorized personnel. It must be ensured that confidential information on de- fined assets are only delivered to the parties authorized personnel on a need to know basis. MICARDO Tachograph Version 1.0 R1.0 41 / 139 ST-Lite Security Objectives 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel O.SOFT_DLV* (PP9911) Protection of the Delivery of the Smartcard Embedded Software The Smartcard Embedded Software must be delivered from the Smartcard Em- bedded Software developer (Phase 1) to the IC designer through a trusted de- livery and verification procedure that shall be able to maintain the integrity of the software and its confidentiality, if applicable. O.INIT_ACS (PP9911) Access to Initialisation Data Initialisation Data shall be accessible only by authorized personnel (physical, personnel, organizational, technical procedures). O.SAMPLE_ACS (PP9911) Access to Samples Samples used to run tests shall be accessible only by authorized personnel. Objectives on the TOE Delivery Process (Phases 4 to 7) O.DLV_PROTECT* (PP9911) Protection of the Delivery of TOE Material / Information Procedures shall ensure protection of TOE material / information under delivery including the following objectives: - non-disclosure of any security relevant information - identification of the element under delivery - meet confidentiality rules (confidentiality level, transmittal form, reception acknowledgement) - physical protection to prevent external damage - secure storage and handling procedures (including rejected TOE’s) - traceability of TOE during delivery including the following parameters: - origin and shipment details - reception, reception acknowledgement - location material/information O.DLV_AUDIT* (PP9911) Audit of Delivery Procedures shall ensure that corrective actions are taken in case of improper operation in the delivery process (including if applicable any non-conformance to the confidentiality convention) and highlight all non-conformance to this proc- ess. O.DLV_RESP* (PP9911) Responsibility Procedures shall ensure that people (shipping department, carrier, reception department) dealing with the procedure for delivery have got the required skill, training and knowledge to meet the procedure requirements and be able to act fully in accordance with the above expectations. Objectives on Deliv- ery from Phase 1 to Phases 4, 5 and 6 O.DLV_DATA (PP9911) Delivery of Application Data MICARDO Tachograph Version 1.0 R1.0 42 / 139 ST-Lite Security Objectives 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel The Application Data must be delivered from the Smartcard Embedded Soft- ware developer (phase 1) either to the IC Packaging manufacturer, the Finish- ing Process manufacturer or the Personalizer through a trusted delivery and verification procedure that shall be able to maintain the integrity and confidenti- ality of the Application Data. Objectives on Phases 4 to 6 O.TEST_OPERATE* (PP9911) Testing of the TOE Appropriate functionality testing of the TOE shall be used in phases 4 to 6. During all manufacturing and test operations, security procedures shall be used through phases 4, 5 and 6 to maintain confidentiality and integrity of the TOE and its manufacturing and test data. O.Process-Card (OE.Process-Card in ST-ICPhilips+Lib) Protection during Packaging, Finishing and Personalisation Security procedures shall be used after TOE-IC Delivery up to delivery to the end-user to maintain confidentiality and integrity of the TOE-IC and of its manu- facturing and test data (to prevent any possible copy, modification, retention, theft or unauthorised use). Objectives on Phase 6 O.PERS Maintaining of Personalisation Data The originator of the personalisation data and the personalisation center re- sponsible for the personalisation of the TOE shall handle the personalisation data in an adequate secure manner. This concerns especially the security data to be personalised as secret cryptographic keys and PINs. The storage of the personalisation data at the originator and at the personalisation center as well as the transfer of these data between the different sites shall be conducted with respect to data integrity and confidentiality. Furthermore, the personalisation center shall treat the data for securing the personalisation process, i.e. the personalisation keys suitably secure. It is in the responsibility of the originator of the personalisation data to garan- tuee for a sufficient quality of the personalisation data, especially of the crypto- graphic material to be personalised. The preparation and securing of the per- sonalisation data appropriate to the Tachograph Card´s structure and according to the TOE´s personalisation requirements is as well in the responsibility of the external world and shall be done with care. Objectives on Phase 7 O.USE_DIAG* (PP9911) Secure Communication Secure communication protocols and procedures shall be used between the smartcard and the terminal. MICARDO Tachograph Version 1.0 R1.0 43 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 5 IT Security Requirements 5.1 TOE Security Requirements This section consists of the subsections “TOE Security Functional Requirements” and ”TOE Security Assurance Requirements”. 5.1.1 TOE Security Functional Requirements The TOE Security Functional Requirements (SFRs) define the functional requirements for the TOE using functional requirement components drawn from /CC 2.2 Part2/, functional requirement components of /CC 2.2 Part2/ with extension as well as self-defined functional requirement components (only for the IC with its IC Dedicated Software). This chapter con- tains the SFRs concerning the IC (TOE-IC) as well as the SFRs concerning the Smartcard Embedded Software (TOE-ES). Note: The SFRs for the TOE are listed in the following chapters within tables. Thereby, the tables contain in the left column the original definition of the respective SFR and its elements, de- pendencies, hierarchical information, management and audit functions. The right column supplies the iterations, selections, assignments and refinements chosen for the TOE. For the SFRs of the TOE-ES, the SFRs are numbered by taking the original name of the SFRs resp. its elements and adding “-x” for the x-th iteration. 5.1.1.1 TOE Security Functional Requirements for the IC (TOE-IC) For the definition of the SFRs related to the TOE-IC refer to /BSI-PP-0002/, chap. 5.1.1, 8.4, 8.5, 8.6, to the Security Target of the IC /ST-ICPhilips/, chap. 5.1.1 and to the Security Target of the IC incl. its Dedicated Support Software /ST-ICPhilips+Lib/, chap. 5.1.1. 5.1.1.2 TOE Security Functional Requirements for the Smartcard Embedded Software (TOE-ES) The following section gives a survey of the SFRs related to the TOE´s Smartcard Embedded Software as required in the Tachograph Card Specification /TachAn1B/, Appendix 10 (Ta- chograph Card Generic Security Target) and the JIL interpretation /JILDigTacho/, Annex B. MICARDO Tachograph Version 1.0 R1.0 44 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 5.1.1.2.1 Security Function Policies The Tachograph Card distinguishes between two different phases, more precise between the personalisation phase and the end-usage (operational) phase, each of it with its own Security Function Policy (SFP). The SFPs for these different phases of the Tachograph Card will be described in detail in the following. For a non-personalised Tachograph Card, the TOE-ES maintains a Security Function Pol- icy as defined as follows: SFP Personalisation Access Control (PERS-AC_SFP) The SFP PERS-AC_SFP is only relevant for the personalisation phase of the Tachograph Card, i.e. after the initialisation of the card has been completed and no personalisation has been conducted. Subjects: • personalisation unit • other card interface devices Security attributes for subjects: • USER_GROUP (PERSO_UNIT, NON_PERSO_UNIT) Objects: • data fields for user data as: - identification data (card identification data, cardholder identification data) - activity data (cardholder activities data, events and faults data, control activity data) • data fields for security data as: - card´s signature key pair - public keys - PIN (only relevant for Workshop Card) - static personalisation key (if applicable and if the key is loaded during pre- personalisation) • security data (loaded during initialisation resp. pre-personalisation or negotiated during personalisation): - card´s private personalisation key - card´s public personalisation key MICARDO Tachograph Version 1.0 R1.0 45 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel - personalisation unit´s public personalisation key - static personalisation key (if applicable) - session keys - card´s private authentication key • TOE software code • TOE file system (incl. file structure, additional internal structures, access conditions) • identification data of the TOE concerning the IC and the Smartcard Embedded Software • data field for identification data of the TOE´s personalisation concerning the date and time of the personalisation Security attributes for objects: Access Rules for: • data fields for user data • data fields for security data • security data • TOE file system • identification data of the TOE • data field for identification data of the TOE´s personalisation Operations (Access Modes): • data fields for user data as: - identification data: selecting (command Select), writing (command Update Binary) - activity data: selecting (command Select), writing (command Update Binary) • data fields for security data as: - card´s signature key pair: loading (command Put Key) - public keys: loading (command Put Key) - PIN (only relevant for Workshop Card): loading (command Put Key) - static personalisation key (if applicable and if the key is loaded during pre- personalisation): loading (command Store Kpers) • security data: - card´s private personalisation key: internal authentication (command Internal Au- thenticate), external authentication (command External Authenticate), import of static personalisation key (if applicable; command Store Kpers) - card´s public personalisation key: referencing over a MSE-command (for further usage within cryptographic operations as authentication) - personalisation unit´s public personalisation key: referencing over a MSE- command (for further usage within cryptographic operations as authentication) MICARDO Tachograph Version 1.0 R1.0 46 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel - static personalisation key (if applicable): activating (command Copy Kpers), after- wards securing of personalisation commands with Secure Messaging - session keys: securing of personalisation commands with Secure Messaging - card´s private authentication key: internal authentication (command Internal Au- thenticate) • TOE software code: --- • TOE file system (incl. file structure, additional internal structures, access conditions): blowing-up the file system for a chosen type of Tachograph Card (command Complete Filesystem) • identification data of the TOE: selecting (command Select), reading (command Get Data) • data field for identification data of the TOE´s personalisation (date and time of personal- isation): selecting (command Select), writing (command Append Record), reading (com- mand Get Data) The SFP PERS-AC_SFP controls the access of subjects to objects on the basis of security attributes. The TOE maintains the following type of security attributes: - Access Rule (AR) consisting of one or more Partial Access Rules (PAR) whereat each PAR consists of one Access Mode (AM) and one or more Access Conditions (AC) The AM indicates the command type for accessing the object. The AC defines the conditions under which a command executed by a subject is allowed to access the object. The access modes to the above mentioned objects are defined above. Further, the TOE maintains the following types of elementary ACs: - NEV (Never) The command can never be executed. - ALW (Always) The command can be executed without restrictions. - AUT (Key based user authentication) The right corresponding to a successful external key based authentication must be opened up (done by the command External Authenticate) before the command can be executed. - PWD (Password based user authentication) The right corresponding to a successful password based authentication must be opened up (done by the command Verify PIN) before the command can be executed. - SM CMD MAC, SM RSP MAC (Secure Messaging providing data integrity and au- thenticity for command resp. response) The command must be secured with a cryptographic checksum using Secure Messag- ing as defined in the Tachograph Card Specification (/TachAn1B/, Appendix 11, chap. 5, Appendix 2, chap. 3.6.2.2, 3.6.3.2). - SM CMD ENC, SM RSP ENC (Secure Messaging providing data confidentiality for command resp. response) MICARDO Tachograph Version 1.0 R1.0 47 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel The command must be secured with an encryption using Secure Messaging as defined in the Tachograph Card Specification (/TachAn1B/, Appendix 11, chap. 5, Appendix 2, chap. 3.6.2.2, 3.6.3.2). - OR Boolean OR relation. For rule decisions, the PERS-AC_SFP uses the actual security status set in the card as ref- erence value. The PERS-AC_SFP explicitly authorises access of subjects to objects based on the following rules: - The TSF allows access to an object for a defined access mode, if the object's access condition is valid for this access mode. - The TSF evaluates within an AC resp. PAR the logical expression of elementary AC elements according to the following rules: - AC element NEV is set to "false". - AC element AUT is set to "true", if AUT complies with the actual security status (preceding external authentication has been conducted successfully). - AC element SM CMD MAC / SM RSP MAC is set to "true", if SM CMD MAC, SM RSP MAC complies with the user indication for SM CMD MAC, SM RSP MAC and SM CMD MAC, SM RSP MAC complies with the actual security status (preceding external authentication has been conducted successfully). - AC element SM CMD ENC, SM RSP ENC is set to "true", if SM CMD ENC, SM RSP ENC complies with the user indication for SM CMD ENC, SM RSP ENC and SM CMD ENC, SM RSP ENC complies with the actual security status (preceding external authentication has been conducted successfully). The SFP PERS-AC_SFP restricts the access of subjects to the identification data of the TOE to the commands Select and Get Data. There are no further restrictions for the access to these data areas with identification data of the TOE. The SFP PERS-AC_SFP restricts the access of subjects to the data field for identification data of the TOE´s personalisation to the commands Select, Append Record and Get Data. There are no further restrictions for the access to these data areas. The SFP PERS-AC_SFP controls the access of subjects to security data, which are loaded during initialisation (i.e. card´s personalisation key pair, personalisation unit´s public person- alisation key, card´s private authentication key, static personalisation key (if applicable and loaded within the initialisation)) resp. during pre-personalisation (static personalisation key, if applicable) or are negotiated during personalisation (session keys) by access rules. Except for the static personalisation key, there are no further restrictions for the execution of the above mentioned access modes concerning these secret data. The usage resp. activation of the static personalisation key is regulated by security attributes as specified below. The SFP PERS-AC_SFP controls the access of subjects to the data fields for user data. Generally, an object of type user data can only be accessed if an access mode exists and an access rule has been attached to the object during its creation. For each type of Tachograph MICARDO Tachograph Version 1.0 R1.0 48 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Card the access rules for the different data fields for user data are implemented as follows: The personalisation of the Tachograph Card´s data fields for user data is done by using the access modes selecting and writing whereat Secure Messaging is required. The key used for Secure Messaging is either a session key which is negotiated during a preceding mutual authentication process with the initialised card´s and the personalisation unit´s personalisa- tion keys. Otherwise a static personalisation key is used which is loaded during initialisation or within an additional pre-personalisation phase. In any case, each security relevant per- sonalisation command is combined with the elementary AC elements AUT, PRO SM and ENC SM (logical AND), thus personalisation is only possible with an authenticated personal- isation unit and in a secured mode with encryption and MAC-securing using the negotiated session key resp. static personalisation key and a related send sequence counter. The SFP PERS-AC_SFP controls the access of subjects to the data fields for security data for personalisation purposes as follows: The loading of the secrets is only possible with Se- cure Messaging with the same properties as described above for the personalisation of the data fields for user data. In particular, loading of a static personalisation key after initialisation is either denied or only possible after a preceding external authentication (using the initialised card´s and personalisation unit´s personalisation keys). Furthermore, the loading of the card´s signature key pair is connected in an atomar process with the change of the Tacho- graph Card´s status from „initialised status“ to „operational status“. Afterwards, the personal- isation commands are no longer available, and from now on only the SFP Access Control (AC_SFP) as loaded in the framework of the initialisation is relevant. The SFP PERS-AC_SFP controls the access of subjects to the static personalisation key for personalisation purposes as follows: The activation of the key is either denied or only possible after a preceding external authentication (using the initialised card´s and personal- isation unit´s personalisation keys). The SFP PERS-AC_SFP controls the access of subjects to the TOE file system. Blowing up the file system for a chosen type of Tachograph Card is either denied or only possible after a preceding external authentication (using the initialised card´s and personalisation unit´s per- sonalisation keys). The access rules for loading and activating a static personalisation key as well as the access rule for blowing up the TOE file system are pre-defined during production of the Tachograph Card and cannot be changed after delivery of the TOE. These access rules allow for a con- figuration of the TOE (choice of personalisation scheme, choice of file system status at deliv- ery time) . For a personalised Tachograph Card, the TOE-ES maintains a Security Function Policy as defined as follows: SFP Access Control (AC_SFP) The SFP AC_SFP is only relevant for the end-usage phase of the Tachograph Card, i.e. after the personalisation of the card has been completed and the Tachograph Application is in the „operational status“. MICARDO Tachograph Version 1.0 R1.0 49 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Subjects: • vehicle units (in sense of the Tachograph Card specification) • other card interface devices (non-vehicle units) Security attributes for subjects: • USER_GROUP (VEHICLE_UNIT, NON_VEHICLE_UNIT) • USER_ID (Vehicle Registration Number (VRN) and Registering Member State Code (MSC), where USER_ID is only known to USER_GROUP = VEHICLE_UNIT) Objects: • user data: - identification data (card identification data, cardholder identification data) - activity data (cardholder activities data, events and faults data, control activity data) • security data: - card´s private signature key - public keys (in particular card´s public signature key; keys stored permanently on the card or imported into the card in form of certificates) - session keys - PIN (only relevant for Workshop Card) - card´s private authentication key • TOE software code • TOE file system (incl. file structure, additional internal structures, access conditions) • identification data of the TOE concerning the IC and the Smartcard Embedded Software • identification data of the TOE´s personalisation concerning the date and time of the per- sonalisation Security attributes for objects: Access Rules for: • user data • security data • TOE file system • identification data of the TOE • identification data of the TOE´s personalisation MICARDO Tachograph Version 1.0 R1.0 50 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Operations (Access Modes): • user data: - identification data: selecting (command Select), reading (command Read Binary), download function (command Perform Hash of File, command PSO Compute Digital Signature) - activity data: selecting (command Select), reading (command Read Binary), writ- ing / modification (command Update Binary), download function (command Per- form Hash of File, command PSO Compute Digital Signature) • security data: - card´s private signature key: generation of a digital signature (command PSO Compute Digital Signature), internal authentication (command Internal Authenti- cate), external authentication (command External Authenticate) - public keys (in particular card´s public signature key): referencing over a MSE- command (for further usage within cryptographic operations as authentication, verification of a digital signature etc.) - session keys: securing of commands with Secure Messaging - PIN (only relevant for Workshop Card): verification (command Verify PIN) - card´s private authentication key: internal authentication (command Internal Au- thenticate) • TOE software code: --- • TOE file system (incl. file structure, additional internal structures, access conditions): --- • identification data of the TOE: selecting (command Select), reading (command Get Data) • identification data of the TOE´s personalisation (date and time of personalisation): select- ing (command Select), reading (command Get Data) The SFP AC_SFP controls the access of subjects to objects on the basis of security attrib- utes. A description of the security attributes maintained by the TOE is given above (see SFP PERS-AC_SFP). For rule decisions, the AC_SFP uses the actual security status set in the card as reference value. The AC_SFP explicitly authorises access of subjects to objects based on the following rules: - The TSF allows access to an object for a defined access mode, if the object's access condition is valid for this access mode. - The TSF evaluates within an AC resp. PAR the logical expression of elementary AC elements according to the following rules: - AC element ALW is set to "true". - AC element NEV is set to "false". - AC element AUT is set to "true", if AUT complies with the actual security status (preceding external authentication has been conducted successfully). MICARDO Tachograph Version 1.0 R1.0 51 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel - AC element PWD is set to "true", if PWD complies with the actual security status (preceding PIN verification has been conducted successfully). - AC element SM CMD MAC / SM RSP MAC is set to "true", if SM CMD MAC / SM RSP MAC complies with the user indication for SM CMD MAC / SM RSP MAC and SM CMD MAC / SM RSP MAC complies with the actual security status (preceding external authentication has been conducted successfully). - AC element SM CMD ENC / SM RSP ENC is set to "true", if SM CMD ENC / SM RSP ENC complies with the user indication for SM CMD ENC / SM RSP ENC and SM CMD ENC / SM RSP ENC complies with the actual security status (preceding external authentication has been conducted successfully). - For the command Read Binary, the following special rules hold: - The TSF allows read access to an object as well in that case, that there does not exist an SM CMD MAC / SM RSP MAC element in the object's AC, but SM CMD MAC / SM RSP MAC is indicated by the user. (The command will then be secured accordingly with Secure Messaging.) For each type of Tachograph Card the access rules for the different objects and access modes are implemented according to the requirements in the Tachograph Card Specification /TachAn1B/, Appendix 2, chap. 4. The AC element PWD is only relevant for the Tachograph Card type Workshop Card. For a Workshop Card the actual security status reached by the AC element PWD will be evaluated. A mutual authentication process between the card and the external world is only possible if a successful preceding verification process with the PIN of the card has been taken place. Generally, an object of type user data or security data can only be accessed if an access mode exists and an access rule has been attached to the object (during its creation). The SFP AC_SFP controls the access of subjects to user data and security data by access rules. The SFP AC_SFP restricts the access of subjects to the identification data of the TOE to the commands Select and Get Data. There are no further restrictions for the access to these data areas with identification data of the TOE. The SFP AC_SFP restricts the access of subjects to the data field for identification data of the TOE´s personalisation to the commands Select and Get Data. There are no further restrictions for the access to this data area. 5.1.1.2.2 Security Functional Requirements FAU Security Audit FAU_SAA Security Audit Analysis FAU_SAA.1 Potential Violation Analysis PP9911 / TachAn1B, Appendix 10, Tachograph Card Generic Security Target, chap. 4.5 MICARDO Tachograph Version 1.0 R1.0 52 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel FAU_SAA.1.1 The TSF shall be able to apply a set of rules in moni- toring the audited events and based upon these rules indicate a potential violation of the TSP. FAU_SAA.1.2 The TSF shall enforce the following rules for monitor- ing audited events: a) Accumulation or combination of [assignment: sub- set of defined auditable events] known to indicate a potential security violation; b) [assignment: any other rules]. Hierarchical to: No other components Dependencies: - FAU_GEN.1 Audit data generation Management: a) maintenance of the rules by (adding, modifying, deletion) of rules from the set of rules Audit: a) Minimal: Enabling and disabling of any of the analysis mechanisms b) Minimal: Automated responses performed by the tool FAU_SAA.1-1: FAU_SAA.1.1-1 The TSF shall be able to apply a set of rules in moni- toring the audited events and based upon these rules indicate a potential violation of the TSP. FAU_SAA.1.2-1 The TSF shall enforce the following rules for monitor- ing audited events: a) Accumulation or combination of [ - cardholder authentication failure (5 consecu- tive unsuccessful PIN checks), - self test error, - stored data integrity error, - activity data input integrity error - error in the framework of securing of data ex- change (concerning data integrity and / or data confidentiality) - software / hardware failure ] known to indicate a potential security violation; b) [none]. Hierarchical to: No other components Dependencies: Not applicable Management: Not applicable FCO Communication FCO_NRO Non-Repudiation of Origin FCO_NRO.1 Selective Proof of Origin TachAn1B, Appendix 10, Tachograph Card Generic Security Target, chap. 4.8.2 FCO_NRO.1.1 The TSF shall be able to generate evidence of origin for transmitted [assignment: list of information types] at the request of the [selection: originator, recipient, [assignment: list of third parties]]. FCO_NRO.1.2 The TSF shall be able to relate the [assignment: list of attributes] of the originator of the information, and the [assignment: list of information fields] of the in- FCO_NRO.1-1: FCO_NRO.1.1-1 The TSF shall be able to generate evidence of origin for transmitted [user data (download function)] at the request of the [recipient]. Refinement DEX_304: The TOE shall be able to generate an evi- dence of origin for data downloaded to external me- MICARDO Tachograph Version 1.0 R1.0 53 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel formation to which the evidence applies. FCO_NRO.1.3 The TSF shall provide a capability to verify the evi- dence of origin of information to [selection: originator, recipient, [assignment: list of third parties]] given [as- signment: limitations on the evidence of origin]. Hierarchical to: No other components Dependencies: - FIA_UID.1 Timing of identification Management: a) The management of changes to information types, fields, originator attributes and recipients of evidence. Audit: a) Minimal: The identity of the user who requested that evidence of origin would be generated. b) Minimal: The invocation of the non-repudiation service. c) Basic: Identification of the information, the destina- tion, and a copy of the evidence provided. d) Detailed: The identity of the user who requested a verification of the evidence. dia. FCO_NRO.1.2-1 The TSF shall be able to relate the [card identity given by the card´s specific private signature key] of the originator of the information, and the [hash value of the data area of the currently selected transparent elementary file] of the information to which the evidence applies. Refinement DEX_306: The TOE shall be able to download data to external storage media with associated security attrib- utes such that downloaded data integrity can be veri- fied. FCO_NRO.1.3-1 The TSF shall provide a capability to verify the evi- dence of origin of information to [the recipient] given [no limitation]. Refinement DEX_305: The TOE shall be able to provide a capabil- ity to verify the evidence of origin of downloaded data to the recipient. Hierarchical to: No other components Dependencies: - FIA_UID.1-1 Timing of identification Management: Not applicable FCS Cryptographic Support FCS_CKM Cryptographic Key Management FCS_CKM.1 Cryptographic Key Generation TachAn1B, Appendix 10, Tachograph Card Generic Security Target, chap. 4.9 FCS_CKM.1.1 The TSF shall generate cryptographic keys in accor- dance with a specified cryptographic key generation algorithm [assignment: cryptographic key generation algorithm] and specified cryptographic key sizes [as- signment: cryptographic key sizes] that meet the following: [assignment: list of standards]. Hierarchical to: No other components FCS_CKM.1-1: FCS_CKM.1.1-1 The TSF shall generate cryptographic keys in accor- dance with a specified cryptographic key generation algorithm [generation of a 3-DES session key] and specified cryptographic key sizes [of double length (128 bits with 112 bits entropy, no parity bits set)] that meet the following: [ MICARDO Tachograph Version 1.0 R1.0 54 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Dependencies: - [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation] - FCS_CKM.4 Cryptographic key destruction - FMT_MSA.2 Secure security attributes Management: a) the management of changes to cryptographic key attributes. Examples of key attributes include user, key type (e.g. public, private, secret), validity period, and use (e.g. digital signature, key encryption, key agreement, data encryption) Audit: a) Minimal: Success and failure of the activity b) Basic: The object attribute(s), and object value(s) excluding any sensitive information (e.g. secret or private keys) - ISO/IEC 9798-3 Information Technology – Se- curity Techniques – Entity Authentication Mechanisms – Part 2: Entity Authentication Using a Public Key Algorithm, Second Edition 1998 - Tachograph Card specification /TachAn1B/, Appendix 11, chap. 3.1.3 (CSM_012), 3.2 (CSM_015), 4 (CSM_020) ]. Refinement CSP_301: If the TSF generates cryptographic keys, it shall be in accordance with specified cryptographic key generation algorithms and specified cryptographic key sizes. (...) Hierarchical to: No other components Dependencies: - [FCS_CKM.2-1 Cryptographic key distribution] - FCS_CKM.4-1 Cryptographic key destruction Management: Not applicable FCS_CKM.2 Cryptographic Key Distribution TachAn1B, Appendix 10, Tachograph Card Generic Security Target, chap. 4.9 FCS_CKM.2.1 The TSF shall distribute cryptographic keys in accor- dance with a specified cryptographic key distribution method [assignment: cryptographic key distribution method] that meets the following: [assignment: list of standards]. Hierarchical to: No other components Dependencies: - [FDP_ITC.1 Import of user data without security attributes or FDP_ITC.2 Import of user data with security at- tributes or FCS_CKM.1 Cryptographic key generation] - FCS_CKM.4 Cryptographic key destruction - FMT_MSA.2 Secure security attributes Management: a) the management of changes to cryptographic key attributes. Examples of key attributes include user, key type (e.g. public, private, secret), validity period, and use (e.g. digital signature, key encryption, key agreement, data encryption) Audit: FCS_CKM.2-1: FCS_CKM.2.1-1 The TSF shall distribute cryptographic keys in accor- dance with a specified cryptographic key distribution method [3-DES session key agreement (with send sequence counter) by an internal-external authen- tication mechanism] that meets the following: [ - ISO/IEC 9798-3 Information Technology – Se- curity Techniques – Entity Authentication Mechanisms – Part 2: Entity Authentication Using a Public Key Algorithm, Second Edition 1998 - Tachograph Card specification /TachAn1B/, Appendix 11, chap. 3.1.3 (CSM_012), 4 (CSM_020), Appendix 2, chap. 3.6.8, 3.6.9 ]. Refinement CSP_302: If the TSF distributes cryptographic keys, it shall be in accordance with specified cryptographic key distribution methods. Hierarchical to: No other components Dependencies: - [FCS_CKM.1-1 Cryptographic key generation] MICARDO Tachograph Version 1.0 R1.0 55 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel a) Minimal: Success and failure of the activity b) Basic: The object attribute(s), and object value(s) excluding any sensitive information (e.g. secret or private keys) - FCS_CKM.4-1 Cryptographic key destruction Management: Not applicable FCS_CKM.2-2: FCS_CKM.2.1-2 The TSF shall distribute cryptographic keys in accor- dance with a specified cryptographic key distribution method [import of public RSA-keys by certificates (non self-descriptive card verifiable certificates in conformance with ISO/IEC 7816-8)] that meets the following: [ - Tachograph Card specification /TachAn1B/, Appendix 11, chap. 3.3, esp. 3.3.1 (CSM_017), 3.3.2 (CSM_018) and 3.3.3 (CSM_019), Appen- dix 2, chap. 3.6.7 (esp. TCS_346) ]. Refinement CSP_302: If the TSF distributes cryptographic keys, it shall be in accordance with specified cryptographic key distribution methods. Hierarchical to: No other components Dependencies: - [FDP_ITC.1-1 Import of user data without security attributes] - FCS_CKM.4-2 Cryptographic key destruction Management: Not applicable FCS_CKM.2-3: FCS_CKM.2.1-3 The TSF shall distribute cryptographic keys in accor- dance with a specified cryptographic key distribution method [import of a static 3-DES key] that meets the following: [ - Cryptographically secured import (encryption using the public part of a dedicated RSA-key pair of the card) ]. Refinement CSP_302: If the TSF distributes cryptographic keys, it shall be in accordance with specified cryptographic key distribution methods. Hierarchical to: No other components Dependencies: MICARDO Tachograph Version 1.0 R1.0 56 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel - [FDP_ITC.1-1 Import of user data without security attributes] - FCS_CKM.4-1 Cryptographic key destruction Management: Not applicable FCS_CKM.3 Cryptographic Key Access PP9911 / TachAn1B, Appendix 10, Tachograph Card Generic Security Target, chap. 4.9 FCS_CKM.3.1 The TSF shall perform [assignment: type of crypto- graphic key access] in accordance with a specified cryptographic key access method [assignment: cryp- tographic key access method] that meets the follow- ing: [assignment: list of standards]. Hierarchical to: No other components Dependencies: - [FDP_ITC.1 Import of user data without security attributes or FDP_ITC.2 Import of user data with security at- tributes or FCS_CKM.1 Cryptographic key generation] - FCS_CKM.4 Cryptographic key destruction - FMT_MSA.2 Secure security attributes Management: a) the management of changes to cryptographic key attributes. Examples of key attributes include user, key type (e.g. public, private, secret), validity period, and use (e.g. digital signature, key encryption, key agreement, data encryption) Audit: a) Minimal: Success and failure of the activity b) Basic: The object attribute(s), and object value(s) excluding any sensitive information (e.g. secret or private keys) FCS_CKM.3-1: FCS_CKM.3.1-1 The TSF shall perform [the access to a private RSA- key for the generation of a digital signature] in accordance with a specified cryptographic key access method [access to the key by its implicitly known reference within the execution of the command PSO Compute Digital Signature resp. the com- mand Internal Authenticate] that meets the follow- ing: [ - Tachograph Card specification, /TachAn1B/ Appendix 2, chap. 3.6.13 (TCS_373), 3.6.8 (TCS_350) ]. Hierarchical to: No other components Dependencies: - [FDP_ITC.1-1 Import of user data without security attributes] Management: Not applicable FCS_CKM.3-2: FCS_CKM.3.1-2 The TSF shall perform [the access to a public RSA- key for the verification of a digital signature] in accordance with a specified cryptographic key access method [access to the key by its reference explic- itly set before within the execution of the com- mand PSO Verify Digital Signature resp. the com- mand External Authenticate resp. the command PSO Verify Certificate] that meets the following: [ - Tachograph Card specification /TachAn1B/, Appendix 2, chap. 3.6.14 (TCS_377), 3.6.9 MICARDO Tachograph Version 1.0 R1.0 57 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel (TCS_355), 3.6.7 (TCS_347) ]. Hierarchical to: No other components Dependencies: - [FDP_ITC.1-1 Import of user data without security attributes] - FCS_CKM.4-2 Cryptographic key destruction Management: Not applicable FCS_CKM.3-3: FCS_CKM.3.1-3 The TSF shall perform [the access to a private RSA- key for the decryption operation] in accordance with a specified cryptographic key access method [access to the key by its implicitly known refer- ence within the execution of the command Exter- nal Authenticate resp. the command Store Kpers] that meets the following: [ - Tachograph Card specification /TachAn1B/, Appendix 2, 3.6.9 (TCS_355) - PKCS#1 V2.0 (RSA primitive for decryption) ]. Hierarchical to: No other components Dependencies: - [FDP_ITC.1-1 Import of user data without security attributes] Management: Not applicable FCS_CKM.3-4: FCS_CKM.3.1-4 The TSF shall perform [the access to a public RSA- key for the encryption operation] in accordance with a specified cryptographic key access method [access to the key by its reference explicitly set before within the execution of the command Inter- nal Authenticate] that meets the following: [ - Tachograph Card specification /TachAn1B/, Appendix 2, chap. 3.6.8 (TCS_350) - PKCS#1 V2.0 (RSA primitive for encryption) ]. Hierarchical to: No other components Dependencies: MICARDO Tachograph Version 1.0 R1.0 58 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel - [FDP_ITC.1-1 Import of user data without security attributes] - FCS_CKM.4-2 Cryptographic key destruction Management: Not applicable FCS_CKM.3-5: FCS_CKM.3.1-5 The TSF shall perform [the encryption, decryption, MAC generation and MAC verification operations with a 3-DES session key resp. with a static 3-DES key for Secure Messaging] in accordance with a specified cryptographic key access method [access to the session key resp. static key by its reference implicit set by the card before within the execution of the command Read Binary resp. the command Update Binary, if Secure Messaging is required] that meets the following: [ - Tachograph Card specification /TachAn1B/, Appendix 11, chap. 3.1.3 (CSM_013), Appendix 2, chap. 3.6.2.2, 3.6.3.2 ]. Refinement CSP_301: (...) Generated cryptographic session keys shall have a limited (TBD by manufacturer and not more than 240) number of possible use. Hierarchical to: No other components Dependencies: - [FCS_CKM.1-1 Cryptographic key generation] (for session key), [FDP_ITC.1-1 Import of user data without security attributes] (for static key) - FCS_CKM.4-1 Cryptographic key destruction Management: Not applicable FCS_CKM.4 Cryptographic Key Destruction PP9911 / TachAn1B, Appendix 10, Tachograph Card Generic Security Target, chap. 4.9 FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accor- dance with a specified cryptographic key destruction method [assignment: cryptographic key destruction method] that meets the following: [assignment: list of standards]. Hierarchical to: No other components Dependencies: - [FDP_ITC.1 Import of user data without security FCS_CKM.4-1: FCS_CKM.4.1-1 The TSF shall destroy cryptographic keys in accor- dance with a specified cryptographic key destruction method [erasing of 3-DES session keys resp. of a static 3-DES key] that meets the following: [ - Tachograph Card specification /TachAn1B/, Appendix 11, chap. 3.1.3 (CSM_013), Appendix 2, chap. 3.6.8 (TCS_353) - Physical erasing (overwriting with zero) MICARDO Tachograph Version 1.0 R1.0 59 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel attributes or FDP_ITC.2 Import of user data with security at- tributes or FCS_CKM.1 Cryptographic key generation] - FMT_MSA.2 Secure security attributes Management: a) the management of changes to cryptographic key attributes. Examples of key attributes include user, key type (e.g. public, private, secret), validity period, and use (e.g. digital signature, key encryption, key agreement, data encryption) Audit: a) Minimal: Success and failure of the activity b) Basic: The object attribute(s), and object value(s) excluding any sensitive information (e.g. secret or private keys) ]. Hierarchical to: No other components Dependencies: - [FCS_CKM.1-1 Cryptographic key generation] (for session key), [FDP_ITC.1-1 Import of user data without security attributes] (for static key) Management: Not applicable FCS_CKM.4-2: FCS_CKM.4.1-2 The TSF shall destroy cryptographic keys in accor- dance with a specified cryptographic key destruction method [erasing of imported public RSA-keys and references to public RSA-keys] that meets the fol- lowing: [ - Tachograph Card specification /TachAn1B/, Appendix 2, chap. 3.6.10 (TCS_363) ]. Hierarchical to: No other components Dependencies: - [FDP_ITC.1-1 Import of user data without security attributes] Management: Not applicable FCS_COP Cryptographic Operation FCS_COP.1 Cryptographic Operation PP9911 / TachAn1B, Appendix 10, Tachograph Card Generic Security Target, chap. 4.9 FCS_COP.1.1 The TSF shall perform [assignment: list of crypto- graphic operations] in accordance with a specified cryptographic algorithm [assignment: cryptographic algorithm] and cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [as- signment: list of standards]. FCS_COP.1-1: FCS_COP.1.1-1 The TSF shall perform [the explicit signature gen- eration and verification (commands PSO Compute Digital Signature and PSO Verify Digital Signa- ture)] in accordance with a specified cryptographic algorithm [RSA] and cryptographic key sizes [of 1024 MICARDO Tachograph Version 1.0 R1.0 60 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Hierarchical to: No other components Dependencies: - [FDP_ITC.1 Import of user data without security attributes or FDP_ITC.2 Import of user data with security at- tributes or FCS_CKM.1 Cryptographic key generation] - FCS_CKM.4 Cryptographic key destruction - FMT_MSA.2 Secure security attributes Management: --- Audit: a) Minimal: Success and failure, and the type of cryp- tographic operation b) Basic: Any applicable cryptographic mode(s) of operation, subject attributes and object attributes bits] that meet the following: [ - PKCS#1 (with SHA-1) signature generation / verification scheme, RSA Encryption Standard Version 2.0, October 1998 - SHA-1, FIPS Pub. 180-1, NIST, April 1995 - Tachograph Card specification /TachAn1B/, Appendix 11, chap. 2.2.1 (CSM_003), 2.2.2 (CSM_004), 6.1 (CSM_034) and 6.2 (CSM_035) ]. Hierarchical to: No other components Dependencies: - [FDP_ITC.1-1 Import of user data without security attributes] - FCS_CKM.4-2 Cryptographic key destruction Management: --- FCS_COP.1-2: FCS_COP.1.1-2 The TSF shall perform [the implicit signature gen- eration and verification (commands Internal Au- thenticate, External Authenticate and PSO Verify Certificate)] in accordance with a specified crypto- graphic algorithm [RSA] and cryptographic key sizes [of 1024 bits] that meet the following: [ - ISO/IEC 9796-2 Information Technology – Se- curity Techniques – Digital Signature Schemes Giving Message Recovery – Part 2: Mecha- nisms Using a Hash Function, First Edition 1997 - SHA-1, FIPS Pub. 180-1, NIST, April 1995 - Tachograph Card specification /TachAn1B/, Appendix 11, chap. 2.2.1 (CSM_003), 2.2.2 (CSM_004), 4 (CSM_020), 3.3.2, 3.3.3 ]. Hierarchical to: No other components Dependencies: - [FDP_ITC.1-1 Import of user data without security attributes] - FCS_CKM.4-2 Cryptographic key destruction Management: --- FCS_COP.1-3: FCS_COP.1.1-3 The TSF shall perform [the implicit encryption and MICARDO Tachograph Version 1.0 R1.0 61 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel decryption operations concerning asymmetric cryptography (commands Internal Authenticate, External Authenticate and Store Kpers)] in accor- dance with a specified cryptographic algorithm [RSA] and cryptographic key sizes [of 1024 bits] that meet the following: [ - PKCS#1 encryption / decryption primitive, RSA Encryption Standard Version 2.0, October 1998 - Tachograph Card specification /TachAn1B/, Appendix 11, chap. 2.2.1 (CSM_003), 4 ]. Hierarchical to: No other components Dependencies: - [FDP_ITC.1-1 Import of user data without security attributes] - FCS_CKM.4-2 Cryptographic key destruction Management: --- FCS_COP.1-4: FCS_COP.1.1-4 The TSF shall perform [the encryption and decryp- tion operations concerning symmetric cryptogra- phy] in accordance with a specified cryptographic algorithm [3-DES in CBC mode with ICV = 0] and cryptographic key sizes [of 128 bits (112 bits en- tropy, no parity bits set)] that meet the following: [ - Data Encryption Standard, FIPS Pub. 46-3, NIST, Draft 1999 - ANSI X9.52 Triple Data Encryption Algorithm Modes of Operations 1998 - Tachograph Card specification /TachAn1B/, Appendix 11, chap. 2.2.3 (CSM_005) and 5.4 (CSM_031) ]. Hierarchical to: No other components Dependencies: - [FCS_CKM.1-1 Cryptographic key generation] (for session key), [FDP_ITC.1-1 Import of user data without security attributes] (for static key) - FCS_CKM.4-1 Cryptographic key destruction Management: --- FCS_COP.1-5: FCS_COP.1.1-5 MICARDO Tachograph Version 1.0 R1.0 62 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel The TSF shall perform [the MAC generation and the MAC verification concerning symmetric cryptog- raphy] in accordance with a specified cryptographic algorithm [DES Retail-MAC (with consideration of the send sequence counter)] and cryptographic key sizes [of 128 bits (112 bits entropy, no parity bits set)] that meet the following: [ - ANSI X9.19 Financial Institution Retail Mes- sage Authentication 1986 - Tachograph Card specification /TachAn1B/, Appendix 11, chap. 2.2.3 (CSM_005) and 5.3 (CSM_028)) ]. Hierarchical to: No other components Dependencies: - [FCS_CKM.1-1 Cryptographic key generation] (for session key), [FDP_ITC.1-1 Import of user data without security attributes] (for static key) - FCS_CKM.4-1 Cryptographic key destruction Management: --- FDP User Data Protection FDP_ACC Access Control Policy FDP_ACC.2 Complete Access Control PP9911 / TachAn1B, Appendix 10, Tachograph Card Generic Security Target, chap. 4.3.1, 4.4 FDP_ACC.2.1 The TSF shall enforce the [assignment: access con- trol SFP] on [assignment: list of subjects and objects] and all operations among subjects and objects cov- ered by the SFP. FDP_ACC.2.2 The TSF shall ensure that all operations between any subject in the TSC and any object within the TSC are covered by an access control SFP. Hierarchical to: FDP_ACC.1 Dependencies: - FDP_ACF.1 Security attribute based access control FDP_ACC.2-1: FDP_ACC.2.1-1 The TSF shall enforce the [AC_SFP] on [ subjects: - vehicle units (in the sense of the Tachograph Card specification) - other card interface devices (non-vehicle units) objects: - user data: - identification data (card identification data, cardholder identification data) - activity data (cardholder activities data, events and faults data, control activity MICARDO Tachograph Version 1.0 R1.0 63 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Management: --- Audit: --- data) - security data: - card´s private signature key - public keys (in particular card´s public sig- nature key, imported public keys) - session keys - PIN (only relevant for workshop card) - card´s private authentication key - TOE software code - TOE file system (incl. file structure, add. inter- nal structures, access conditions) - identification data of the TOE (-IC, -ES) - identification data of the TOE´s personalisa- tion ] and all operations among subjects and objects cov- ered by the SFP. FDP_ACC.2.2-1 The TSF shall ensure that all operations between any subject in the TSC and any object within the TSC are covered by an access control SFP. Hierarchical to: FDP_ACC.1 Dependencies: - FDP_ACF.1-1 Security attribute based access control Management: --- FDP_ACC.2-2: FDP_ACC.2.1-2 The TSF shall enforce the [PERS-AC_SFP] on [ subjects: - personalisation units - other card interface devices (non- personalisation units) objects: - data fields for user data as: - identification data (card identification data, cardholder identification data) - activity data (cardholder activities data, events and faults data, control activity data) - data fields for security data as: - card´s signature key pair - public keys - PIN (only relevant for workshop card) - static personalisation key (if applicable) - security data: - card´s private personalisation key - card´s public personalisation key MICARDO Tachograph Version 1.0 R1.0 64 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel - personalisation unit´s public personalisa- tion key - static personalisation key (if applicable) - session keys - card´s private authentication key - TOE software code - TOE file system (incl. file structure, add. inter- nal structures, access conditions) - identification data of the TOE (-IC, -ES) - data field for identification data of the TOE´s personalisation ] and all operations among subjects and objects cov- ered by the SFP. FDP_ACC.2.2-2 The TSF shall ensure that all operations between any subject in the TSC and any object within the TSC are covered by an access control SFP. Hierarchical to: FDP_ACC.1 Dependencies: - FDP_ACF.1-2 Security attribute based access control Management: --- FDP_ACF Access Control Functions FDP_ACF.1 Security Attribute Based Access Control PP9911 / TachAn1B, Appendix 10, Tachograph Card Generic Security Target, chap. 4.3.2, 4.4 / JILDigTa- cho, chap. 2.6 FDP_ACF.1.1 The TSF shall enforce the [assignment: access con- trol SFP] to objects based on the following: [assign- ment: list of subjects and objects cotrolled under the indicated SFP, and for each, the SFP-relevant secu- rity attributes, or named groups of SFP-relevant se- curity attributes]. FDP_ACF.1.2 The TSF shall enforce the following rules to deter- mine if an operation among controlled subjects and controlled objects is allowed: [assignment: rules gov- erning access among controlled subjects and con- trolled objects using controlled operations on con- trolled objects]. FDP_ACF.1.3 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-1: FDP_ACF.1.1-1 The TSF shall enforce the [AC_SFP] to objects based on [ subjects: - vehicle units (in the sense of the Tachograph Card specification) - other card interface devices (non-vehicle units) objects: - user data: - identification data (card identification data, cardholder identification data) - activity data (cardholder activities data, events and faults data, control activity data) - security data: - card´s private signature key MICARDO Tachograph Version 1.0 R1.0 65 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the [assignment: rules, based on security attributes, that explicitly deny access of sub- jects to objects]. Hierarchical to: No other components Dependencies: - FDP_ACC.1 Subset access control - FMT_MSA.3 Static attribute initialisation Management: a) Managing the attributes used to make explicit ac- cess or denial based decisions Audit: a) Minimal: Successful requests to perform an opera- tion on an object covered by the SFP b) Basic: All requests to perform an operation on an object covered by the SFP c) Detailed: The specific security attributes used in making an access check - public keys (in particular card´s public sig- nature key, imported public keys) - session keys - PIN (only relevant for workshop card) - card´s private authentication key - TOE software code - TOE file system (incl. file structure, add. inter- nal structures, access conditions) - identification data of the TOE (-IC, -ES) - identification data of the TOE´s personalisa- tion security attributes for subjects: - USER_GROUP - USER_ID security attributes for objects: - access rules ]. FDP_ACF.1.2-1 The TSF shall enforce the following rules to determine if an operation among controlled subjects and con- trolled objects is allowed: [ - GENERAL_READ: - driver card, workshop card: user data may be read from the TOE by any user - control card, company card: user data may be read from the TOE by any user, except cardholder identification data which may be read by VEHICLE_UNIT only; - IDENTIF_WRITE: all card types: identification data may only be written once and before the end of phase 6 of card’s life-cycle; no user may write or modify identification data during end-usage phase of card’s life-cycle; - ACTIVITY_WRITE: all card types: activity data may be written to the TOE by VEHICLE_UNIT only; - SOFT_UPGRADE: all card types: no user may upgrade TOE’s software; - FILE_STRUCTURE: all card types: files structure and access con- ditions shall be created before end of phase 5 of TOE’s life-cycle and then locked from any future modification or deletion by any user - IDENTIF_TOE_READ: all card types: identification data of the TOE and identification data of the TOE´s personal- isation may be read from the TOE by any user; - IDENTIF_TOE_WRITE: all card types: identification data of the TOE may only be written once and before the end of phase 5 of card’s life-cycle; no user may write or modify these identification data during MICARDO Tachograph Version 1.0 R1.0 66 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel phase 6 or end-usage phase of card’s life- cycle; - IDENTIF_ TOE_ PERS_WRITE: all card types: identification data of the TOE´s personalisation may only be written once and within phase 6 of card’s life-cycle; no user may write or modify these identification data during end-usage phase of card’s life-cycle - SECDATA_ACCESS: access to secret data stored in the framework of the initialisation or personalisation of the TOE is done by an implicit connection with the respective command whereat the access to the card´s private signature key for an external authentication, to session keys or to the PIN is only successful for VEHICLE_UNIT; for all other secret data any user will succeed ]. Note /TachAn1B/, Appendix 10, Tachograph Card Generic Security Target, chap. 4.2 and 4.3.2 (FDP_ACF.1.2 GENERAL_READ) say that only control cards may have an authentication process before exporting cardholder identification data, but /TachAn1B/, Ap- pendix 2 TCS_415 says that authentication is manda- tory for exporting cardholder identification data. Fur- thermore, there are no TSF mediated actions defined in FIA_UAU.1.1 for the company card. Agreed interpretation in /JILDigTacho/, chap. 2.6: The allowed actions for a company card seems to be miss- ing in the specification of FIA_UAU.1 in the generic security target of /TachAn1B/, Appendix 10. From the context it is clear that a company card should allow the actions as specified by /TachAn1B/, Appendix 2 (which are the same for a control card). Therefore, the specification of the TOE SFRs in /TachAn1B/, Appen- dix 10, Tachograph Card Generic Security Target should be read as follows: - GENERAL_READ: User data may be read from the TOE by any user, except cardholder identifica- tion data which may be read from control cards or company cards by VEHICLE_UNIT only. Refinements ACT_301: The TOE shall hold permanent identifica- tion data. ACT_302: There shall be an indication of the time and date of the TOE's personalisation. This indication shall remain unalterable. FDP_ACF.1.3-1 The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [none]. MICARDO Tachograph Version 1.0 R1.0 67 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel FDP_ACF.1.4-1 The TSF shall explicitly deny access of subjects to objects based on the [none]. Hierarchical to: No other components Dependencies: - FDP_ACC.2-1 Subset access control Management: Not applicable FDP_ACF.1-2: FDP_ACF.1.1-2 The TSF shall enforce the [PERS-AC _SFP] to ob- jects based on [ subjects: - personalisation units - other card interface devices (non- personalisation units) objects: - data fields for user data as: - identification data (card identification data, cardholder identification data) - activity data (cardholder activities data, events and faults data, control activity data) - data fields for security data as: - card´s signature key pair - public keys - PIN (only relevant for workshop card) - static personalisation key (if applicable) - security data: - card´s private personalisation key - card´s public personalisation key - personalisation unit´s public personalisa- tion key - static personalisation key (if applicable) - session keys - card´s private authentication key - TOE software code - TOE file system (incl. file structure, add. inter- nal structures, access conditions) - identification data of the TOE (-IC, -ES) - data field for identification data of the TOE´s personalisation security attributes for subjects: - USER_GROUP - USER_ID security attributes for objects: - access rules (for data fields for user data, data MICARDO Tachograph Version 1.0 R1.0 68 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel fields for security data, static personalisation key, TOE file system) ]. FDP_ACF.1.2-2 The TSF shall enforce the following rules to determine if an operation among controlled subjects and con- trolled objects is allowed: [ - IDENTIF_WRITE: all card types: identification data may only be written before the end of phase 6 of card’s life- cycle; within phase 6, identification data may be written by PERSO_UNIT only - ACTIVITY_WRITE: all card types: activity data may only be writ- ten during the end-usage phase of card’s life- cycle - SECDATA_WRITE: all card types: security data as the card´s per- sonalisation key pair, the personalisation unit´s public personalisation key and the card´s private authentication key may only be loaded before the end of phase 5 of card´s life- cycle; the card´s static personalisation key (if applicable) may only be loaded in phase 5 resp. in phase 6 of card´s life-cycle; the card´s signature key pair and the PIN (workshop card) may only be loaded within phase 6 - SECDATA_ACCESS: access to secret data stored in the framework of the initialisation, pre-personalisation (if ap- plicable) or personalisation of the TOE is done by an implicit connection with the respective command whereat the access to the card´s private personalisation key for an external au- thentication or for the import of the static per- sonalisation key, to session keys or to the static personalisation key is only successful for PERSO_UNIT; for all other secret data any user will succeed - SOFT_UPGRADE: all card types: no user may upgrade TOE’s software; - FILE_STRUCTURE: all card types: files structure and access con- ditions shall be created before end of phase 5 of TOE’s life-cycle and then locked from any future modification or deletion by any user (Note: This requirement holds for each con- figuration of the Tachograph Card delivered to the customer; in particular, if the card is deliv- ered at the end of phase 5 with a prepared file system, it is only possible to blow up one of the four pre-defined Tachograph Card file sys- tem types whereat no modification is possi- ble.) - IDENTIF_TOE_READ: all card types: identification data of the TOE or MICARDO Tachograph Version 1.0 R1.0 69 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel of the TOE´s personalisation may be read from the TOE by any user; - IDENTIF_TOE_WRITE: all card types: identification data of the TOE may only be written once and before the end of phase 5 of card’s life-cycle; no user may write or modify these identification data during phase 6 phase of card’s life-cycle or later; - IDENTIF_ TOE_ PERS_WRITE: all card types: identification data of the TOE´s personalisation may only be written within phase 6 of card’s life-cycle; no user may write or modify these identification data during end- usage phase of card’s life-cycle ]. Refinements ACT_301: The TOE shall hold permanent identifica- tion data. ACT_302: There shall be an indication of the time and date of the TOE's personalisation. This indication shall remain unalterable. FDP_ACF.1.3-2 The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [none]. FDP_ACF.1.4-2 The TSF shall explicitly deny access of subjects to objects based on the [none]. Hierarchical to: No other components Dependencies: - FDP_ACC.2-2 Subset access control Management: Not applicable FDP_DAU Data Authentication FDP_DAU.1 Basic Data Authentication PP9911 / TachAn1B, Appendix 10, Tachograph Card Generic Security Target, chap. 4.6.2 FDP_DAU.1.1 The TSF shall provide a capability to generate evi- dence that can be used as a guarantee of the validity of [assignment: list of objects or information types]. FDP_DAU.1.2 The TSF shall provide [assignment: list of subjects] with the ability to verify evidence of the validity of the indicated information. FDP_DAU.1-1: FDP_DAU.1.1-1 The TSF shall provide a capability to generate evi- dence that can be used as a guarantee of the validity of [activity data]. FDP_DAU.1.2-1 The TSF shall provide [any subject (i.e. vehicle units and other card interface devices (non- MICARDO Tachograph Version 1.0 R1.0 70 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Hierarchical to: No other components Dependencies: No dependencies Management: a) The assignment or modification of the objects for which data authentication may apply could be config- urable in the system Audit: a) Minimal: Successful generation of validity evidence b) Basic: Unsuccessful generation of validity evi- dence c) Detailed: The identity of the subject that requested the evidence vehicle units))] with the ability to verify evidence of the validity of the indicated information. Hierarchical to: No other components Dependencies: No dependencies Management: Not applicable FDP_ETC Export to Outside TSF Control FDP_ETC.1 Export of User Data without Security Attributes PP9911 FDP_ETC.1.1 The TSF shall enforce the [assignment: access con- trol SFP(s) and/or information flow control SFP(s)] when exporting user data, controlled under the SFP(s), outside of the TSC. FDP_ETC.1.2 The TSF shall export the user data without the user data’s associated security attributes. Hierarchical to: No other components Dependencies: - [FDP_ACC.1 Subset access control or FDP_IFC.1 Subset information flow control] Management: --- Audit: a) Minimal: Successful export of information b) Basic: All attempts to export information FDP_ETC.1-1: FDP_ETC.1.1-1 The TSF shall enforce the [for phase 6 of the prod- uct´s life-cycle: PERS-AC_SFP; for phase 7 of the product´s life-cycle: AC_SFP] when exporting user data, controlled under the SFP(s), outside of the TSC. FDP_ETC.1.2-1 The TSF shall export the user data, without the user data’s associated security attributes. Hierarchical to: No other components Dependencies: - [FDP_ACC.2-1 Subset access control] - [FDP_ACC.2-2 Subset access control] Management: --- FDP_ETC.2 Export of User Data with Security Attributes TachAn1B, Appendix 10, Tachograph Card Generic Security Target, chap. 4.8.2 FDP_ETC.2.1 The TSF shall enforce the [assignment: access con- trol SFP(s) and/or information flow control SFP(s)] when exporting user data, controlled under the SFP(s), outside of the TSC. FDP_ETC.2-1: FDP_ETC.2.1-1 The TSF shall enforce the [AC_SFP] when exporting user data within the card data download function, controlled under the SFP(s), outside of the TSC. MICARDO Tachograph Version 1.0 R1.0 71 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel FDP_ETC.2.2 The TSF shall export the user data with the user data’s associated security attributes. FDP_ETC.2.3 The TSF shall ensure that the security attributes, when exported outside the TSC, are unambiguously associated with the exported user data. FDP_ETC.2.4 The TSF shall enforce the following rules when user data is exported from the TSC: [assignment: addi- tional exportation control rules]. Hierarchical to: No other components Dependencies: - [FDP_ACC.1 Subset access control or FDP_IFC.1 Subset information flow control] Management: a) The additional exportation control rules could be configurable by a user in a defined role. Audit: a) Minimal: Successful export of information b) Basic: All attempts to export information FDP_ETC.2.2-1 The TSF shall export the user data with the user data’s associated security attributes. Refinement DEX_306: The TOE shall be able to download data to external storage media with associated security attrib- utes such that downloaded data integrity can be veri- fied. FDP_ETC.2.3-1 The TSF shall ensure that the security attributes, when exported outside the TSC, are unambiguously associated with the exported user data. FDP_ETC.2.4-1 The TSF shall enforce the following rules when user data is exported from the TSC: [none] Hierarchical to: No other components Dependencies: - [FDP_ACC.2-1 Subset access control] Management: Not applicable FDP_ITC Import from Outside TSF Control FDP_ITC.1 Import of User Data without Security Attributes PP9911 FDP_ITC.1.1 The TSF shall enforce the [assignment: access con- trol SFP(s) and/or information flow control SFP(s)] when importing user data, controlled under the SFP, from outside of the TSC. FDP_ITC.1.2 The TSF shall ignore any security attributes associ- ated with the user data when imported from outside the TSC. FDP_ITC.1.3 The TSF shall enforce the following rules when im- porting user data controlled under the SFP from out- side the TSC: [assignment: additional importation control rules]. Hierarchical to: No other components Dependencies: - [FDP_ACC.1 Subset access control FDP_ITC.1-1: FDP_ITC.1.1-1 The TSF shall enforce the [for phase 6 of the prod- uct´s life-cycle: PERS-AC_SFP; for phase 7 of the product´s life-cycle: AC_SFP] when importing user data, controlled under the SFP, from outside of the TSC. FDP_ITC.1.2-1 The TSF shall ignore any security attributes associ- ated with the user data when imported from outside the TSC. FDP_ITC.1.3-1 The TSF shall enforce the following rules when im- porting user data controlled under the SFP from out- side the TSC: [none]. Hierarchical to: No other components MICARDO Tachograph Version 1.0 R1.0 72 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel or FDP_IFC.1 Subset information flow control] - FMT_MSA.3 Static attribute initialisation Management: a) The modification of the additional control rules used for import Audit: a) Minimal: Successful import of user data, including any security attributes b) Basic: All attempts to import user data, including any security attributes c) Detailed: The specification of security attributes for imported user data supplied by an authorised user Dependencies: - [FDP_ACC.2-1 Subset access control] - [FDP_ACC.2-2 Subset access control] Management: Not applicable FDP_RIP Residual Information Protection FDP_RIP.1 Subset Residual Information Protection PP9911 FDP_RIP.1.1 The TSF shall ensure that any previous information content of a resource is made unavailable upon the [selection: allocation of the resource to, deallocation of the resource from] the following objects: [assign- ment: list of objects]. Hierarchical to: No other components Dependencies: No dependencies Management: a) The choice of when to perform residual information protection (i.e. upon allocation or deallocation) could be made configurable within the TOE Audit: --- FDP_RIP.1-1: FDP_RIP.1.1-1 The TSF shall ensure that any previous information content of a resource is made unavailable upon the [deallocation of the resource from] the following objects: [security relevant material (e.g. crypto- graphic KEYs, PINs, ...)]. Hierarchical to: No other components Dependencies: No dependencies Management: Not applicable FDP_SDI Stored Data Integrity FDP_SDI.2 Stored Data Integrity Monitoring and Action PP9911 / TachAn1B, Appendix 10, Tachograph Card Generic Security Target, chap. 4.6.1 FDP_SDI.2.1 The TSF shall monitor user data stored within the TSC for [assignment: integrity errors] on all objects, based on the following attributes: [assignment: user data attributes]. FDP_SDI.2.2 FDP_SDI.2-1: FDP_SDI.2.1-1 The TSF shall monitor user data (incl. stored se- crets) stored within the TSC for [integrity error be- fore access and processing] on all objects, based on the following attributes: [user data value, user MICARDO Tachograph Version 1.0 R1.0 73 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Upon detection of a data integrity error, the TSF shall [assignment: action to be taken]. Hierarchical to: FDP_SDI.1 Dependencies: No dependencies Management: a) The actions to be taken upon the detection of an integrity error could be configurable Audit: a) Minimal: Successful attempts to check the integrity of user data, including an indication of the results of the check b) Basic: All attempts to check the integrity of user data, including an indication of the results of the check, if performed c) Detailed: The type of integrity error that occurred d) Detailed: The action taken upon detection of an integrity error data object]. FDP_SDI.2.2-1 Upon detection of a data integrity error, the TSF shall [warn the entity connected]. Hierarchical to: FDP_SDI.1 Dependencies: No dependencies Management: Not applicable FIA Identification and Authentication FIA_AFL Authentication Failures FIA_AFL.1 Authentication Failure Handling PP9911 / TachAn1B, Appendix 10, Tachograph Card Generic Security Target, chap. 4.2.3 FIA_AFL.1.1 The TSF shall detect when [selection: [assignment: positive integer number], “an administrator configur- able positive integer within [assignment: range of acceptable values]“] unsuccessful authentication attempts occur related to [assignment: list of authen- tication events]. FIA_AFL.1.2 When the defined number of unsuccessful authenti- cation attempts has been met or surpassed, the TSF shall [assignment: list of actions]. Hierarchical to: No other components Dependencies: - FIA_UAU.1 Timing of authentication Management: a) management of the threshold for unsuccessful For all card types: Card reaction for each single user authentication fail- ure: FIA_AFL.1-1: FIA_AFL.1.1-1 The TSF shall detect when [1] unsuccessful authenti- cation attempt occurs related to [authentication of a card interface device]. FIA_AFL.1.2-1 When the defined number of unsuccessful authentica- tion attempts has been met or surpassed, the TSF shall [warn the entity connected, assume the user as NON_VEHICLE_UNIT (phase 7 of product´s life- cycle) resp. NON_PERSO_UNIT (phase 6 of prod- uct´s life-cycle)]. Hierarchical to: No other components MICARDO Tachograph Version 1.0 R1.0 74 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel authentication attempts b) management of actions to be taken in the event of an authentication failure Audit: a) Minimal: the reaching of the threshold for the un- succesful authentication attempts and the actions (e.g. disabling of a terminal) taken and the subse- quent, if appropriate, restoration to the normal state (e.g. re-enabling of a terminal) Dependencies: - FIA_UAU.1-1 Timing of authentication Management: Not applicable For workshop cards only: Card reaction in the case of a failure of the additional PIN-authentication mechanism: FIA_AFL.1-2: FIA_AFL.1.1-2 The TSF shall detect when [5] unsuccessful authenti- cation attempts occur related to [PIN check (work- shop card)]. FIA_AFL.1.2-2 When the defined number of unsuccessful authentica- tion attempts has been met or surpassed, the TSF shall [warn the entity connected, block the PIN check procedure such that any subsequent PIN check attempt will fail, be able to indicate to sub- sequent users the reason of the blocking]. Note Agreed interpretation in /JILDigTacho/, chap. 2.6: To ensure that the Tachograph Card takes care of un- successful authentication events, the sentence “The following assignments describe the card reaction in the case of failure of the additional authentication mechanism required in UIA_302.” (/TachAn1B/, Ap- pendix 10, Tachograph Card Generic Security Target, chap. 4.2.3) should be read as follows: “Additionally the following assignments describe the card reaction in the case of failure of the additional authentication mechanism required in UIA_302.” This should ensure that the Tachograph Card (here only the workshop card) only allows a mutual authentication with the Vehicle Unit after a successful PIN verification of a human user. Hierarchical to: No other components Dependencies: - FIA_UAU.1-1 Timing of authentication Management: Not applicable FIA_ATD MICARDO Tachograph Version 1.0 R1.0 75 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel User Attribute Definition FIA_ATD.1 User Attribute Definition PP9911 / TachAn1B, Appendix 10, Tachograph Card Generic Security Target, chap. 4.2.1 FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users: [assignment: list of security attributes]. Hierarchical to: No other components Dependencies: No dependencies Management: a) if so indicated in the assignment, the authorised administrator might be able to define additional secu- rity attributes for users Audit: --- FIA_ATD.1-1: FIA_ATD.1.1-1 The TSF shall maintain the following list of security attributes belonging to individual users: [ phase 6 of the product´s life-cycle: - USER_GROUP (PERSO_UNIT, NON_PERSO_UNIT) phase 7 of the product´s life-cycle: - USER_GROUP (VEHICLE_UNIT, NON_VEHICLE_UNIT) - USER_ID (VRN and Reg. MSC, where USER_ID is only known to USER_GROUP = VEHI- CLE_UNIT) ]. Hierarchical to: No other components Dependencies: No dependencies Management: Not applicable FIA_UAU User Authentication FIA_UAU.1 Timing of Authentication PP9911 / TachAn1B, Appendix 10, Tachograph Card Generic Security Target, chap. 4.2.2 / JILDigTacho, chap. 2.6 FIA_UAU.1.1 The TSF shall allow [assignment: list of TSF medi- ated actions] on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing any other TSF- medi- ated actions on behalf of that user. Hierarchical to: No other components Dependencies: - FIA_UID.1 Timing of identification Management: a) management of the authentication data by an ad- ministrator (Only phase 7 of the product´s life-cycle) FIA_UAU.1-1: FIA_UAU.1.1-1 The TSF shall allow [ driver card, workshop card: export of user data with security attributes (card data download func- tion), control card, company card: export of user data without security attributes except export of card- holder identification data ] on behalf of the user to be performed before the user is authenticated. Note /TachAn1B/, Appendix 10, Tachograph Card Generic MICARDO Tachograph Version 1.0 R1.0 76 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel b) management of the authentication data by the associated user c) managing the list of actions that can be taken be- fore the user is authenticated Audit: a) Minimal: Unsuccessful use of the authentication mechanism b) Basic: All use of the authentication mechanism c) Detailed: All TSF mediated actions performed be- fore authentication of the user Security Target, chap. 4.2 and 4.3.2 (FDP_ACF.1.2 GENERAL_READ) say that only control cards may have an authentication process before exporting cardholder identification data, but /TachAn1B/, Ap- pendix 2 TCS_415 says that authentication is manda- tory for exporting cardholder identification data. Fur- thermore, there are no TSF mediated actions defined in FIA_UAU.1.1 for the company card. Agreed interpretation in /JILDigTacho/, chap. 2.6: The allowed actions for a company card seems to be miss- ing in the specification of FIA_UAU.1 in the generic security target of /TachAn1B/, Appendix 10. From the context it is clear that a company card should allow the actions as specified by /TachAn1B/, Appendix 2 (which are the same for a control card). Therefore, the specification of the TOE SFRs in /TachAn1B/, Appen- dix 10, Tachograph Card Generic Security Target should be read as follows: - Control and company cards: Export of user data without security attributes except cardholder iden- tification data FIA_UAU.1.2-1 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. Refinements UIA_301: Authentication of a vehicle unit shall be performed by means of proving that it possesses se- curity data that only the system could distribute. UIA_302: The workshop card shall provide an addi- tional authentication mechanism by checking a PIN code (This mechanism is intended for the vehicle unit to ensure the identity of the cardholder, it is not in- tended to protect workshop card content). Hierarchical to: No other components Dependencies: - FIA_UID.1-1 Timing of identification Management: Not applicable FIA_UAU.3 Unforgeable Authentication PP9911 / TachAn1B, Appendix 10, Tachograph Card Generic Security Target, chap. 4.2.2 FIA_UAU.3.1 The TSF shall [selection: detect, prevent] use of au- thentication data that has been forged by any user of the TSF. FIA_UAU.3.2 FIA_UAU.3-1: FIA_UAU.3.1-1 The TSF shall [prevent] use of authentication data that has been forged by any user of the TSF. MICARDO Tachograph Version 1.0 R1.0 77 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel The TSF shall [selection: detect, prevent] use of au- thentication data that has been copied from any other user of the TSF. Hierarchical to: No other components Dependencies: No dependencies Management: --- Audit: a) Minimal: Detection of fraudulent authentication data b) Basic: All immediate measures taken and results of checks on the fraudulent data FIA_UAU.3.2-1 The TSF shall [prevent] use of authentication data that has been copied from any other user of the TSF. Hierarchical to: No other components Dependencies: No dependencies Management: --- FIA_UAU.4 Single-use Authentication Mechanisms PP9911 / TachAn1B, Appendix 10, Tachograph Card Generic Security Target, chap. 4.2.2 FIA_UAU.4.1 The TSF shall prevent reuse of authentication data related to [assignment: identified authentication mechanism(s)]. Hierarchical to: No other components Dependencies: No dependencies Management: --- Audit: a) Minimal: Attempts to reuse authentication data FIA_UAU.4-1: FIA_UAU.4.1-1 - The TSF shall prevent reuse of authentication data related to [key based authentication mechanisms]. Hierarchical to: No other components Dependencies: No dependencies Management: --- FIA_UID User Identification FIA_UID.1 Timing of Identification PP9911 / TachAn1B, Appendix 10, Tachograph Card Generic Security Target, chap. 4.2.1 / JILDigTacho, chap. 2.6 FIA_UID.1.1 The TSF shall allow [assignment: list of TSF- mediated actions] on behalf of the user to be per- formed before the user is identified. FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. Hierarchical to: No other components (Only phase 7 of the product´s life-cycle) FIA_UID.1-1: FIA_UID.1.1-1 The TSF shall allow [none of the TSF-mediated ac- tions] on behalf of the user to be performed before the user is identified. Note In /TachAn1B/, Appendix 10, Tachograph Card Ge- MICARDO Tachograph Version 1.0 R1.0 78 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Dependencies: No dependencies Management: a) the management of the user identities b) if an authorised administrator can change the ac- tions allowed before identification, the managing of the action lists Audit: a) Minimal: Unsuccessful use of the user identifica- tion mechanism, including the user identity provided b) Basic: All use of the user identification mechanism, including the user identity provided neric Security Target, FIA_UID.1.1(TSF mediated actions) states that the card shall allow no operations before the identification of the user, and, FDP_ACF.1.2 (GENERAL_READ) states “User data may be read from the TOE by any user, ...”. However, /TachAn1B/, Appendix 11 defines a process to iden- tify and authenticate a VEHICLE_UNIT, but no proc- ess is defined to identify other users. Agreed interpretation in /JILDigTacho/, chap. 2.6: In /TachAn1B/, Appendix 10, Tachograph Card Generic Security Target the following types of users are identi- fied:VEHICLE_UNIT and NON_VEHICLE_UNIT. The user NON_VEHICLE_UNIT is identified by the Tacho- graph Card by just putting it into a card reading device (which could be a Vehicle Unit). After a successful mutual authentication between Tachograph Card and Vehicle Unit, the Tachograph Card assumes the user VEHICLE_UNIT to be identified. (Note: This interpretation shall be applied by analogy for the TOE´s personalisation phase resp. personal- isation units.) FIA_UID.1.2-1 The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. Hierarchical to: No other components Dependencies: No dependencies Management: Not applicable FIA_USB User-Subject Binding FIA_USB.1 User-Subject Binding PP9911 FIA_USB.1.1 The TSF shall associate the following user security attributes with subjects acting on the behalf of that user: [assignment: list of user security attributes]. FIA_USB.1.2 The TSF shall enforce the following rules on the initial association of user security attributes with subjects acting on the behalf of users: [assignment: rules for the initial association of attributes]. FIA_USB.1.3 The TSF shall enforce the following rules governing FIA_USB.1-1: FIA_USB.1.1-1 The TSF shall associate the following user security attributes with subjects acting on the behalf of that user: [ phase 6 of the product´s life-cycle: - USER_GROUP (PERSO_UNIT, NON_PERSO_UNIT) phase 7 of the product´s life-cycle: - USER_GROUP MICARDO Tachograph Version 1.0 R1.0 79 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel changes to the user security attributes associated with subjects acting on the behalf of users: [assign- ment: rules for the changing of attributes]. Hierarchical to: No other components Dependencies: - FIA_ATD.1 User attribute definition Management: a) an authorised administrator can define default subject security attributes b) an authorised administrator can change subject security attributes Audit: a) Minimal: Unsuccessful binding of user security attributes to a subject (e.g. creation of a subject) b) Basic: Success and failure of binding of user secu- rity attributes to a subject (e.g. success or failure to create a subject) (VEHICLE_UNIT, NON_VEHICLE_UNIT) - USER_ID (VRN and Reg. MSC, where USER_ID is only known to USER_GROUP = VEHI- CLE_UNIT) ]. FIA_USB.1.2-1 The TSF shall enforce the following rules on the initial association of user security attributes with subjects acting on the behalf of users: [assignment in the framework of the TOE´s access rule mechanism]. FIA_USB.1.3-1 The TSF shall enforce the following rules governing changes to the user security attributes associated with subjects acting on the behalf of users: [no change of user security attributes possible]. Hierarchical to: No other components Dependencies: - FIA_ATD.1-1 User attribute definition Management: Not applicable FMT Security Management FMT_MOF Management of Functions in TSF FMT_MOF.1 Management of Security Functions Behaviour PP9911 FMT_MOF.1.1 The TSF shall restrict the ability to [selection: deter- mine the behaviour of, disable, enable, modify the behaviour of] the functions [assignment: list of func- tions] to [assignment: the authorised identified roles]. Hierarchical to: No other components Dependencies: - FMT_SMF.1 Specification of management func- tions - FMT_SMR.1 Security roles Management: a) managing the group of roles that can interact with the functions in the TSF Not applicable MICARDO Tachograph Version 1.0 R1.0 80 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Audit: a) Basic: All modifications in the behaviour of the functions in the TSF FMT_MSA Management of Security Attributes FMT_MSA.1 Management of Security Attributes PP9911 FMT_MSA.1.1 The TSF shall enforce the [assignment: access con- trol SFP, information flow control SFP] to restrict the ability to [selection: change_default, query, modify, delete, [assignment: other operations]] the security attributes [assignment: list of security attributes] to [assignment: the authorised identified roles]. Hierarchical to: No other components Dependencies: - [FDP_ACC.1 Subset access control or FDP_IFC.1 Subset information flow control] - FMT_SMR.1 Security roles Management: a) managing the group of roles that can interact with the security attributes Audit: a) Basic: All modifications of the values of security attributes Not applicable FMT_MSA.2 Secure Security Attributes PP9911 FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for security attributes. Hierarchical to: No other components Dependencies: - ADV_SPM.1 Informal TOE security policy model - [FDP_ACC.1 Subset access control or FDP_IFC.1 Subset information flow control] - FMT_MSA.1 Management of security attributes - FMT_SMR.1 Security roles Management: --- Audit: Not applicable MICARDO Tachograph Version 1.0 R1.0 81 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel a) Minimal: All offered and rejected values for a secu- rity attribute b) Detailed: All offered and accepted secure values for a security attribute FMT_MSA.3 Static Attribute Initialisation PP9911 FMT_MSA.3.1 The TSF shall enforce the [assignment: access con- trol SFP, information flow control SFP] to provide [selection: choose one of: restrictive, permissive, [assignment: other property]] default values for secu- rity attributes that are used to enforce the SFP. FMT_MSA.3.2 The TSF shall allow the [assignment: the authorised identified roles] to specify alternative initial values to override the default values when an object or infor- mation is created. Hierarchical to: No other components Dependencies: - FMT_MSA.1 Management of security attributes - FMT_SMR.1 Security roles Management: a) managing the group of roles that can specify initial values b) managing the permissive or restrictive setting of default values for a given access control SFP Audit: a) Basic: Modifications of the default setting of per- missive or restrictive rules b) Basic: All modifications of the initial values of secu- rity attributes Not applicable FMT_MTD Management of TSF Data FMT_MTD.1 Management of TSF Data PP9911 FMT_MTD.1.1 The TSF shall restrict the ability to [selection: change_default, query, modify, delete, clear, [as- signment: other operations]] the [assignment: list of TSF data] to [assignment: the authorised identified roles]. Hierarchical to: No other components Dependencies: Not applicable MICARDO Tachograph Version 1.0 R1.0 82 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel - FMT_SMR.1 Security roles Management: a) managing the group of roles that can interact with the TSF data Audit: a) Basic: All modifications to the values of TSF data FMT_SMF Specification of Management Functions FMT_SMF.1 Specification of Management Functions CC V2.2 FMT_SMF.1.1 The TSF shall be capable of performing the following security management functions: [assignment: list of security management functions to be provided by the TSF]. Hierarchical to: No other components Dependencies: No dependencies Management: --- Audit: a) Minimal: Use of the management functions Not applicable FMT_SMR Security Management Roles FMT_SMR.1 Security Roles PP9911 FMT_SMR.1.1 The TSF shall maintain the roles [assignment: the authorised identified roles]. FMT_SMR.1.2 The TSF shall be able to associate users with roles. Hierarchical to: No other components Dependencies: - FIA_UID.1 Timing of identification Management: a) managing the group of users that are part of a role Audit: Not applicable MICARDO Tachograph Version 1.0 R1.0 83 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel a) Minimal: modifications to the group of users that are part of a role b) Detailed: every use of the rights of a role FPR Privacy FPR_UNO Unobservability FPR_UNO.1 Unobservability PP9911 FPR_UNO.1.1 The TSF shall ensure that [assignment: list of users and/or subjects] are unable to observe the operation [assignment: list of operations] on [assignment: list of objects] by [assignment: list of protected users and/or subjects]. Hierarchical to: No other components Dependencies: No dependencies Management: a) the management of the behaviour of the unob- servability function Audit: a) Minimal: The invocation of the unobservability mechanism FPR_UNO.1-1: FPR_UNO.1.1-1 The TSF shall ensure that [ within phase 6 of the product´s life cycle: non-personalisation units, within phase 7 of the product´s life-cycle: non- vehicle units ] are unable to observe the operation [mutual authentication (for the agreement of ses- sion keys and send sequence counters)] on [au- thentication tokens] by [ within phase 6 of the product´s life cycle: a per- sonalisation unit, within phase 7 of the product´s life-cycle: a vehi- cle unit ]. Hierarchical to: No other components Dependencies: No dependencies Management: Not applicable FPR_UNO.1-2: FPR_UNO.1.1-2 The TSF shall ensure that [ within phase 6 of the product´s life cycle: non- personalisation units, within phase 7 of the product´s life-cycle: non- vehicle units ], if required, are unable to observe the operation MICARDO Tachograph Version 1.0 R1.0 84 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel [import function of user data, export function of user data] on [user data] by [ within phase 6 of the product´s life cycle: a per- sonalisation unit, within phase 7 of the product´s life-cycle: a vehi- cle unit ]. Hierarchical to: No other components Dependencies: No dependencies Management: Not applicable FPR_UNO.1-3: FPR_UNO.1.1-3 The TSF shall ensure that [within phase 6 of the product´s life cycle: non-personalisation units] are unable to observe the operation [import] (if ap- plicable) on [a static personalisation key] by [within phase 6 of the product´s life cycle: a per- sonalisation unit]. Hierarchical to: No other components Dependencies: No dependencies Management: Not applicable FPT Protection of the TSF FPT_FLS Fail Secure FPT_FLS.1 Failure with Preservation of Secure State PP9911 / TachAn1B, Appendix 10, Tachograph Card Generic Security Target, chap. 4.7.3, 4.7.4 FPT_FLS.1.1 The TSF shall preserve a secure state when the fol- lowing types of failures occur: [assignment: list of types of failures in the TSF]. Hierarchical to: No other components FPT_FLS.1-1: FPT_FLS.1.1-1 The TSF shall preserve a secure state when the fol- lowing types of failures occur: [ - reset - power supply cut-off MICARDO Tachograph Version 1.0 R1.0 85 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Dependencies: - ADV_SPM.1 Informal TOE security policy model Management: --- Audit: a) Basic: Failure of the TSF - power supply variations - unexpected abortion of the execution of the TSF due to external or internal events (esp. break of a transaction before completion) - system breakdown - internal Hardware- or Software failure - card life cycle corruption - application life cycle corruption ]. Refinements RLB_306: The TOE shall preserve a secure state during power supply cut-off or variations. RLB_307: If power is cut (or if power variations occur) from the TOE, or if a transaction is stopped before completion, or on any other reset conditions, the TOE shall be reset cleanly. Hierarchical to: No other components Dependencies: - ADV_SPM.1 Informal TOE security policy model Management: --- FPT_PHP Physical Protection FPT_PHP.3 Resistance to Physical Attack PP9911 FPT_PHP.3.1 The TSF shall resist [assignment: physical tampering scenarios] to the [assignment: list of TSF devices /elements] by responding automatically such that the TSP is not violated. Hierarchical to: No other components Dependencies: No dependencies Management: a) management of the automatic responses to physi- cal tampering Audit: --- FPT_PHP.3-1: FPT_PHP.3.1-1 The TSF shall resist [side channel attacks like SPA- attacks, DPA-attacks, DFA-attacks and timing at- tacks concerning all critical cryptographic opera- tions] to the [TSF interfaces] by responding auto- matically such that the TSP is not violated. Hierarchical to: No other components Dependencies: No dependencies Management: Not applicable FPT_SEP Domain Separation FPT_SEP.1 PP9911 / TachAn1B, Appendix 10, Tachograph Card MICARDO Tachograph Version 1.0 R1.0 86 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel TSF Domain Separation Generic Security Target, chap. 4.7.2 FPT_SEP.1.1 The TSF shall maintain a security domain for its own execution that protects it from interference and tam- pering by untrusted subjects. FPT_SEP.1.2 The TSF shall enforce separation between the secu- rity domains of subjects in the TSC. Hierarchical to: No other components Dependencies: No dependencies Management: --- Audit: --- FPT_SEP.1-1: FPT_SEP.1.1-1 The TSF shall maintain a security domain for its own execution that protects it from interference and tam- pering by untrusted subjects. FPT_SEP.1.2-1 The TSF shall enforce separation between the secu- rity domains of subjects in the TSC. Refinements RLB_304: There shall be no way to analyse, debug or modify TOE's software in the field. RLB_305: Inputs from external sources shall not be accepted as executable code. Hierarchical to: No other components Dependencies: No dependencies Management: --- FPT_TDC Inter-TSF TSF Data Consistency FPT_TDC.1 Inter-TSF Basic TSF Data Consistency PP9911 FPT_TDC.1.1 The TSF shall provide the capability to consistently interpret [assignment: list of TSF data types] when shared between the TSF and another trusted IT product. FPT_TDC.1.2 The TSF shall use [assignment: list of interpretation rules to be applied by the TSF] when interpreting the TSF data from another trusted IT product. Hierarchical to: No other components Dependencies: No dependencies Management: --- Audit: a) Minimal: Successful use of TSF data consistency mechanisms FPT_TDC.1-1: FPT_TDC.1.1-1 The TSF shall provide the capability to consistently interpret [ - authentication tokens with their input data for session keys and send sequence counters - session keys and send sequence counters themselves - PINs and their formats - imported certificates, their format and their included signature - imported signatures for verification - imported keys (in particular, personalisation keys) ] when shared between the TSF and another trusted IT product. FPT_TDC.1.2-1 The TSF shall use [ MICARDO Tachograph Version 1.0 R1.0 87 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel b) Basic: Use of the TSF data consistency mecha- nisms c) Basic: Identification of which TSF data have been interpreted d) Basic: Detection of modified TSF data - rules for the interpretation of the input data for session keys and send sequence counters within authentication tokens for the creation of session keys and send sequence counters: Tachograph Card specification /TachAn1B/, Appendix 11, chap. 4, 3.2, Appendix 2, chap. 3.6.8, 3.6.9 - rules for the interpretation of session keys and send sequence counters within Secure Mes- saging: Tachograph Card specification /TachAn1B/, Appendix 11, chap. 5, 3.2, Appendix 2, chap. 3.6.2.2, 3.6.3.2 - rules for the interpretation of imported PINs: Tachograph Card specification /TachAn1B/, Appendix 2, chap. 3.6.5 - rules for the interpretation of imported certifi- cates, their format and their included signa- ture: Tachograph Card specification /TachAn1B/, Appendix 11, chap. 3.3 - rules for the interpretation of imported signa- tures for verification: Tachograph Card specification /TachAn1B/, Appendix 11, chap. 6.2 - rules for the interpretation of imported keys: Tachograph Card specification /TachAn1B/, Appendix 11, chap. 3.3, specification of the TOE concerning the TOE´s personalisation schemes and procedures ] when interpreting the TSF data from another trusted IT product. Hierarchical to: No other components Dependencies: No dependencies Management: --- FPT_TST TSF Self Test FPT_TST.1 TSF Testing PP9911 / TachAn1B, Appendix 10, Tachograph Card Generic Security Target, chap. 4.7.1 FPT_TST.1.1 The TSF shall run a suite of self tests [selection: dur- ing initial start-up, periodically during normal opera- tion, at the request of the authorised user, at the con- ditions [assignment: conditions under which self test should occur]] to demonstrate the correct operation of [selection: [assignment: parts of TSF], the TSF]. FPT_TST.1.2 FPT_TST.1-1: FPT_TST.1.1-1 The TSF shall run a suite of self tests [during initial start-up, periodically during normal operation] to demonstrate the correct operation of [the TSF]. Note During initial start-up means before code is executed. MICARDO Tachograph Version 1.0 R1.0 88 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel The TSF shall provide authorised users with the ca- pability to verify the integrity of [selection: [assign- ment: parts of TSF data], TSF data]. FPT_TST.1.3 The TSF shall provide authorised users with the ca- pability to verify the integrity of stored TSF executa- ble code. Hierarchical to: No other components Dependencies: - FPT_AMT.1 Abstract machine testing Management: a) management of the conditions under which TSF self testing occurs, such as during initial start-up, regular interval, or under specified conditions b) management of the time interval if appropriate Audit: a) Basic: Execution of the TSF self tests and the re- sults of the tests Refinements RLB_301: The TOE's self tests shall include the verifi- cation of the integrity of any software code not stored in ROM. RLB_302: Upon detection of a self test error the TSF shall warn the entity connected. RLB_303: After operating system testing is com- pleted, all testing-specific commands and actions shall be disabled or removed. It shall not be possible to override these controls and restore them for use. Command associated exclusively with one life cycle state shall never be accessed during another state. The term “periodically during normal operation” is understood as follows: It is assumed that the TOE performs at least one reset-operation each day, so that the self test at each initial start-up suffices the requirement of performing the self test periodically during normal operation. FPT_TST.1.2-1 The TSF shall provide authorised users with the ca- pability to verify the integrity of [TSF data]. Refinement In this framework, the Smartcard Embedded Software of the TOE (TOE-ES) itself is understood as „author- ised user“. FPT_TST.1.3-1 The TSF shall provide authorised users with the ca- pability to verify the integrity of stored TSF executable code. Refinement This requirement concerns only the production phase, more precise the initialisation phase of the TOE (phase 5 of the product´s life cycle). Prior to the ini- tialisation of the TOE, the ROM-code of the TOE shall be verifiable by the Smartcard Embedded Software developer. The integrity of the EEPROM-code shall be provable by the TOE during the initialisation process. Hierarchical to: No other components Dependencies: Not applicable Management: Not applicable MICARDO Tachograph Version 1.0 R1.0 89 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel FTP Trusted Path/Channels FTP_ITC Inter-TSF Trusted Channel FTP_ITC.1 Inter-TSF Trusted Channel TachAn1B, Appendix 10, Tachograph Card Generic Security Target, chap. 4.8.1 FTP_ITC.1.1 The TSF shall provide a communication channel between itself and a remote trusted IT product that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure. FTP_ITC.1.2 The TSF shall permit [selection: the TSF, the remote trusted IT product] to initiate communication via the trusted channel. FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [assignment: list of functions for which a trusted channel is required]. Hierarchical to: No other components Dependencies: No dependencies Management: a) Configuring the actions that require trusted chan- nel, if supported Audit: a) Minimal: Failure of the trusted channel functions b) Minimal: Identification of the initiator and target of failed trusted channel functions c) Basic: All attempted uses of the trusted channel functions d) Basic: Identification of the initiator and target of all trusted channel functions FTP_ITC.1-1: FTP_ITC.1.1-1 The TSF shall provide a communication channel be- tween itself and a remote trusted IT product (vehicle unit, personalisation unit) that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure. Refinements DEX_301: The TOE shall verify the integrity and au- thenticity of data imported from a vehicle unit. DEX_302: Upon detection of an imported data integ- rity error, the TOE shall: - warn the entity sending the data, - not use the data. DEX_303: The TOE shall export user data to the ve- hicle unit with associated security attributes, such that the vehicle unit will be able to verify the integrity and authenticity of data received. Note The refinements above from the Tachograph Card specification shall be applied by analog for the per- sonalisation phase of the TOE. The integrity and authenticity resp. the confidentiality, if required, of the data transfer between the Tacho- graph Card and the remote trusted IT product (vehicle unit, personalisation unit) shall be conducted with Secure Messaging in accordance with ISO/IEC 7816- 4 (using a 3-DES session key or a static 3-DES key). FTP_ITC.1.2-1 The TSF shall permit [the remote trusted IT product] to initiate communication via the trusted channel. FTP_ITC.1.3-1 The TSF shall initiate communication via the trusted channel for [user data import from a remote trusted IT product, user data export to a remote trusted IT product]. Hierarchical to: No other components Dependencies: MICARDO Tachograph Version 1.0 R1.0 90 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel No dependencies Management: Not applicable 5.1.2 SOF Claim for TOE Security Functional Requirements According to the requirements in the Tachograph Card specification /TachAn1B/, main body and Appendix 10 (Tachograph Card Generic Security Target), and to the JIL interpretations /JILDigTacho/, the required level for the Strength of Function of the TOE security functional requirements listed in the preceding chap. 101H5.1.1 is “SOF-high”. This correlates to the claimed assurance level with its augmentation by the assurance component AVA_VLA.4 (refer to the following chap. 102H5.1.3). 5.1.3 TOE Security Assurance Requirements The evaluation of the Tachograph Card according to ITSEC E3 high as required in the Ta- chograph Card Specification /TachAn1B/, Appendix 10 (Tachograph Card Generic Security Target) will be replaced by a comparable evaluation according to Common Criteria, whereby the requirements in the JIL interpretations /JILDigTacho/, Annex A have to be considered. The TOE security assurance level is fixed as EAL4 augmented by ADO_IGS.2, ADV_IMP.2, ATE_DPT.2 and AVA_VLA.4, thus the CC evaluation of the TOE matches the evaluation assurance requirements stated in the Tachograph Card Specification /TachAn1B/, Appendix 10 (Tachograph Card Generic Security Target). The following table lists the security assurance requirements (SARs) for the TOE: SAR ACM_AUT.1 Partial CM Automation ACM_CAP.4 Generation Support and Acceptance Procedures Class ACM Configuration Management ACM_SCP.2 Problem Tracking CM Coverage ADO_DEL.2 Detection of Modification Class ADO Delivery and Operation ADO_IGS.2 Generation Log MICARDO Tachograph Version 1.0 R1.0 91 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel ADV_FSP.2 Fully Defined External Interfaces ADV_HLD.2 Security Enforcing High-Level Design ADV_IMP.2 Implementation of the TSF ADV_LLD.1 Descriptive Low-Level Design ADV_RCR.1 Informal Correspondence Demonstration Class ADV Development ADV_SPM.1 Informal TOE Security Policy Model AGD_ADM.1 Administrator Guidance Class AGD Guidance Documents AGD_USR.1 User Guidance ALC_DVS.1 Identification of Security Measures ALC_LCD.1 Developer Defined Life-Cycle Model Class ALC Life Cycle Support ALC_TAT.1 Well-defined Development Tools ATE_COV.2 Analysis of Coverage ATE_DPT.2 Testing: Low-Level Design ATE_FUN.1 Functional Testing Class ATE Tests ATE_IND.2 Independent Testing – Sample AVA_MSU.2 Validation of Analysis AVA_SOF.1 Strength of TOE Security Function Evaluation Class AVA Vulnerability Assessment AVA_VLA.4 Highly Resistant MICARDO Tachograph Version 1.0 R1.0 92 / 139 ST-Lite IT Security Requirements 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 5.1.4 Refinements of the TOE Security Assurance Requirements All assurance components given in the table of chap. 103H5.1.3 are used as defined in /CC 2.2 Part3/ and /CEM 2.2 Part2/. Additionally, according to /JILDigTacho/, Annex A.3, Note 2 and 9 the following refinements resp. interpretations are taken into account: ADO_IGS.2 ADO_IGS.2 is interpreted resp. refined according to ITSEC E3.32 and ITSEC-JIL, Section 16.2 as follows: - The term “generation” is always interpreted as “installation”. - "While installing the TOE, any configuration options and/or changes shall be audited in such a way that it is subsequently possible to reconstruct exactly how the TOE was initially configured and when the TOE was installed." AVA_MSU.2 ITSEC 3.33 additionally requires evaluator tests where necessary. This testing, can be part of the penetration testing under AVA_VLA. It is decided on a case by case basis if the evaluator performs misuse-testing as additional part of penetration testing to confirm or dis- prove the misuse analysis. Specifically, if high attack potential is assumed, such independent misuse-testing is performed. 5.2 Security Requirements for the Environment of the TOE 5.2.1 Security Requirements for the IT-Environment There are no security requirements for the IT-Environment of the TOE defined. 5.2.2 Security Requirements for the Non-IT-Environment There are no security requirements for the Non-IT-Environment of the TOE defined. MICARDO Tachograph Version 1.0 R1.0 93 / 139 ST-Lite TOE Summary Specification 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 6 TOE Summary Specification 6.1 TOE Security Functions 6.1.1 TOE Security Functions / TOE-IC For the definition of the TOE Security Functions (TSF) related to the TOE-IC refer to the Se- curity Targets /ST-ICPhilips/, chap. 6.1 and /ST-ICPhilips+Lib/, chap. 6.1. The TSFs defined for the TOE-IC cover the following functions which are relevant for the TOE: F.RNG, F.HW_DES, F.OPC, F.PHY, F.LOG, F.COMP, F.MEM_ACC, F.SFR_ACC, F.DES, F.RSA, F.SHA-1, F.RNG_Access, F.Object_Reuse, F.LOG 6.1.2 TOE Security Functions / TOE-ES The following section gives a survey of the TSFs of the TOE´s Smartcard Embedded Soft- ware under consideration of the requirements in the Tachograph Card Specification /TachAn1B/, Appendix 10 (Tachograph Card Generic Security Target). TOE Security Functions / TOE-ES Access Control F.ACS Security Attribute Based Access Control The TSF enforces for the personalisation phase of the TOE the SFP Personalisation Access Control (PERS-AC_SFP) and for the end-usage phase of the TOE the SFP Access Control (AC_SFP) as defined in chap. 104H5.1.1.2.1. Identification and Authentication F.IA_KEY Key Based User / TOE Authentication Users of the TOE can be authenticated with regard to the TOE by means of a challenge- response procedure using random numbers (external authentication). Vice versa, the TOE itself can be authenticated with regard to the external world as well by means of a challenge-response procedure using random numbers (internal authentication). In both cases, the TSF makes use of asymmetric cryptography (with encryption, decryption, generation of a digital signature resp. verification of a digital signature) and of the generation of random numbers and is therefore connected with the TSFs F.ENC, F.DEC, F.GEN_DIGSIG, F.VER_DIGSIG and the IC´s TSF F.RNG_Access for random number ac- cess. MICARDO Tachograph Version 1.0 R1.0 94 / 139 ST-Lite TOE Summary Specification 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel For an internal authentication, the TSF generates and returns an authentication token by using the operations “generation of a digital signature” and “encryption” on random numbers of the external world and of the TOE itself. In detail, the TSF uses the relevant private key to sign the authentication data including the randoms and then uses the public key currently selected to encrypt the signature and form the authentication token which will be returned to the external world. For an external authentication, the TSF verifies an authentication token delivered by the exter- nal world (containing random numbers of the external world and of the TOE itself) by using the operations “decryption” and “verification of a digital signature”. In detail, the TSF uses the cur- rently selected public key to decrypt the authentication token and uses then the relevant pri- vate key to verify the signature within the delivered authentication token. The external authen- tication process needs a preceding Get Challenge - operation. The private key necessary on the card´s side for authentication purposes is stored on the card (during initialisation resp. personalisation of the TOE) and is implicitly connected with the cor- responding commands. The necessary public keys whereas are already stored on the card or have to be imported in the form of certificates. In each case, they have to be explicitly refer- enced for usage. The import of a public key by a certificate is connected with the verification of the respective certificate under use of the TSF F.VER_DIGSIG. The access to the keys is controlled by the SFP Personalisation Access Control (PERS-AC_SFP) within the personalisa- tion phase of the TOE and by the SFP Access Control (AC_SFP) within the end-usage phase of the TOE as defined in chap. 105H5.1.1.2.1, which is realised by the TSF F.ACS. In case of a successful external authentication attempt a corresponding actual security state is set. The combination of a successful internal authentication process followed by a successful ex- ternal authentication process leads to the generation of a new session key (with send se- quence counter) which will be used for securing the following data transfer. In detail, the fol- lowing conditions are valid: If the internal authentication process does not fail, the current ses- sion key, if existing, is erased and no longer available. In order to have a new session key available, a following external authentication process must be successfully performed. If the external authentication does not fail, and if the first part of the session key is available from the preceding successful internal authentication, the session key is generated and set for future commands using Secure Messaging. If the first session key part is not available from a previ- ous internal authentication, the second part of the session key, sent by the external world within the authentication token, is not stored in the card. The generation of session keys is task of the TSF F.GEN_SES. For the Tachograph card type Workshop Card the mutual authentication process described above is only possible after a successful preceding password based user authentication (see F.IA_PWD). F.IA_PWD Password Based User Authentication Users of the TOE can be authenticated by means of a card holder authentication process. For the card holder authentication process, the TSF compares the cardholder verification informa- tion, here a password (PIN), provided by a subject with a corresponding secret reference data stored in the card. The TSF is internally connected with the card´s unique password stored on the card (set to a default value during initialisation resp. loaded in the framework of the TOE´s personalisation). The access to the password is controlled by the SFP Access Control (AC_SFP) as defined in chap. 106H5.1.1.2.1, which is realised by the TSF F.ACS. The TSF detects when a defined number of consecutive unsuccessful authentication attempts MICARDO Tachograph Version 1.0 R1.0 95 / 139 ST-Lite TOE Summary Specification 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel occurs related to the card holder authentication process. Each consecutive unsuccessful com- parison of the presented password with the reference value stored on the card is recorded by the TSF in order to limit the number of further authentication attempts with the password. For this purpose, the TSF manages a mandatory error counter for the password. In case of a successful authentication attempt a corresponding actual security state for the password is set and the error counter is reinitialised. If an authentication attempt with the password fails, the corresponding actual security state is reset and the password´s error counter is decreased. When the defined number of unsuccess- ful authentication attempts has been met or surpassed, the TSF blocks the corresponding password. There is no way to reset the error counter in order to unblock the password so that the password is invalid for each further authentication process. For security reasons, the initial value for the error counter is set to a sufficiently small finite value (here: 5). The TSF does not check the quality of the used password, this check is in responsibility of the external world. Furthermore, there is no possibility to change the password while the card is in operational status. The transfer of the password to the TOE for authentication attempts is executed in unsecured mode (i.e. without use of Secure Messaging) or optional in secured mode with Secure Mes- saging. In the latter case, the TSFs F.EX_CONF and F.EX_INT are involved. Integrity of Stored Data F.DATA_INT Stored Data Integrity Monitoring and Action The TSF monitors data stored within the TOE for integrity errors. This concerns all elementary files and dedicated files as well as all secrets (esp. passwords and cryptographic keys) stored outside the file system within the EEPROM area. The monitoring is based on the following attributes: - a checksum (CRC) attached to each header of a file - a checksum (CRC) attached to the data contained in a file - a checksum (CRC) attached to each secret stored outside the file system within the EEPROM area Before the TOE accesses to an elementary or dedicated file or a secret stored outside the file system, the TSF carries out an integrity check on base of the mentioned attributes. Upon de- tection of a data integrity error, the TSF informs the user about this fault. If the checksum of the header of a file has been detected as corrupted, the data contained in the affected file is no longer accessible. If the data contained in a file is not of integrity, the affected data will be treated in the following way: - For the Read access, the affected data will be exported, but the data export will be con- nected with a warning. (Exception: The command Get Data of the Tachograph Applica- tion for reading out the EF_Application_Identification will not export data in case of a corrupt checksum.) - For the Update access, the integrity error of the affected data will be ignored, and the data imported by the command will be stored and a new checksum will be computed. - For all remaining access modes, the affected data will not be used for data processing. MICARDO Tachograph Version 1.0 R1.0 96 / 139 ST-Lite TOE Summary Specification 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel If a secret stored outside the file system is corrupted, the secret will not be processed. Data Exchange F.EX_CONF Confidentiality of Data Exchange The TSF provides the capability to ensure that secret data which is exchanged between the TOE and the user remains confidential during transmission. For this purpose, encryption based on symmetric cryptography is applied to the secret data. The TSF ensures that the user and the user data's access condition have indicated confiden- tiality for the data exchange. Securing the data transfer with regard to data confidentiality will be done by Secure Messag- ing according to the standards ISO/IEC 7816-4 and /TachAn1B/, Appendix 11, chap. 5. The cryptographic key used for securing the data transfer is either a symmetric session key which is generated during a preceding mutual authentication process between the card and the external world (realised by the TSFs F.IA_KEY and F.GEN_SES) or a static symmetric key. For encryption, the TSF makes use of the TSF F.DES of the underlying IC resp. its Dedicated Support Software. F.EX_INT Integrity and Authenticity of Data Exchange The TSF provides the capability to ensure that data which is exchanged between the TOE and the user remains integer and authentic during transmission. For this purpose, cryptographic checksums based on symmetric cryptography are applied to the data. The TSF ensures that the user and the user data's access condition have indicated integrity and authenticity for the data exchange. Securing the data transfer with regard to data integrity and authenticity will be done by Secure Messaging according to the standards ISO/IEC 7816-4 and /TachAn1B/, Appendix 11, chap. 5. The cryptographic key used for securing the data transfer is either a symmetric session key which is generated during a preceding mutual authentication process between the card and the external world (realised by the TSFs F.IA_KEY and F.GEN_SES) or a static symmetric key. For checksum securing, the TSF makes use of the TSF F.DES of the underlying IC resp. its Dedicated Support Software. Object Reuse F.RIP Residual Information Protection The TSF ensures that any previous information content of a resource is explicitly erased upon the deallocation of the resource used for any of the following components: - volatile and non-volatile memories used for operations in which security relevant mate- rial (e.g. secret keys or other secrets like passwords) is involved The TSF makes use of the TSF F.Object_Reuse of the underlying IC resp. its Dedicated Sup- MICARDO Tachograph Version 1.0 R1.0 97 / 139 ST-Lite TOE Summary Specification 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel port Software. Protection F.FAIL_- PROT Hardware and Software Failure Protection The TSF preserves a secure operation state of the card when the following types of failures occur: - induced hardware or software failures (transient or permanent) during the execution of an operation resp. command - tampering The TSF makes use of hardware and software based security features and corresponding mechanisms to monitor and detect induced hardware and software failures and tampering attacks. In particular, the TSF is supported by the IC specific TSFs F.OPC and F.PHY. Upon the detection of a failure of the above mentioned type the TSF reacts in such a way that the TSP is not violated. The TOE changes immediately to a locked state and cannot be used any longer within the actual session. Depending on the type of the detected attack to the un- derlying IC (incl. its Dedicated Software) or to the Smartcard Embedded Software code the TOE will be irreversible locked resp. can be reactivated by a reset. F.SIDE_- CHAN Side Channel Analysis Control The TSF manages suitable hardware and software based mechanisms to prevent attacks by a side channel analysis like Simple Power Analysis (SPA), Differential Power Analysis (DPA), Differential Fault Analysis (DFA) and Timing attacks. The TSF ensures that all countermeasures available are used in such a way that they support each other. In particular, the TSF is supported by the TSF F.LOG of the underlying IC and its Dedicated Support Software. The TSF acts in such a manner that all security relevant operations of the TOE (esp. the TOE´s cryptographic operations) are suitably secured by these hardware and software coun- termeasures. The TSF enforces that a secure session is installed before any cryptographic key is gener- ated, loaded into volatile / non-volatile memories (esp. of dedicated IC cryptographic modules) and processed in a cryptographic operation or in an authentication process. F.SELFTEST Self Test The TSF provides the capability of conducting a self test during initial start-up, i.e. after each reset to demonstrate the correct operation of its TSFs. Under the assumption that the TOE performs at least one reset-operation each day, the self test fulfills the requirement of being performed periodically during normal operation. The TOE´s self tests consist of the verification of the integrity of any software code stored in the EEPROM area by checking a related checksum of the code. Furthermore, the TSF provides authorised users - here the Smartcard Embedded Software of the TOE (TOE-ES) itself - with the capability to verify the integrity of TSF data. For this task, the TSF is supported by the TSF F.DATA_INT. Additionally, the TSF provides authorised users with the capability to verify the integrity of stored TSF executable code. This concerns only the production phase, more precise the ini- MICARDO Tachograph Version 1.0 R1.0 98 / 139 ST-Lite TOE Summary Specification 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel tialisation phase of the TOE (phase 5 of the product´s life cycle). Prior to the initialisation of the TOE, the ROM-code of the TOE can be verified by the Smartcard Embedded Software devel- oper. The integrity of the EEPROM-code is checked by the TOE during the storage of the ini- tialisation file in the framework of the initialisation. The TSF supports all other TSFs defined for the Smartcard Embedded Software (TOE-ES). Cryptographic Operations F.GEN_SES Generation of Session Keys The TSF generates session keys for symmetric cryptography used for securing the data ex- change between the TOE and the external world with regard to data confidentiality and data integrity and authenticity. The TSF enforces that the key material meets the following requirements: - random numbers generated by the card and used in the key generation process have a high quality The TSF for generation of session keys is connected with the TSF F.RNG_Access for the generation of random numbers with high quality. Furthermore, the TSF for generation of ses- sion keys is directly connected with the TSF F.IA_KEY which realises the internal and external authentication process. F.GEN_DIG SIG Generation of Digital Signatures The TSF provides a digital signature functionality based on asymmetric cryptography, particu- larly the RSA algorithm with a key length of 1024 bit. The TSF digital signature function will be used for several purposes with different signature keys and different formats for the digital signature input: - Explicit generation of digital signatures of data using the signature scheme with appen- dix (signature generation operation) according to the standard PKCS#1 V2.0 and with hash algorithm SHA-1. In this case, the TSF digital signature function is implicitly combined with the Tacho- graph Card´s dedicated and unique private signature key stored in the card. - Within authentication processes for the creation of authentication tokens using the sig- nature scheme with message recovery (signature generation operation) according to the standard ISO 9796-2 and with hash algorithm SHA-1. In this case, the TSF digital signature function is implicitly combined with the Tacho- graph Card´s dedicated private personalisation key (during the personalisation phase) resp. with the Tachograph Card´s dedicated and unique private signature key (during the end-usage phase of the card). - For proving the authenticity of the ORGA Tachograph Card: creation of an authentica- tion token using the signature scheme with message recovery (signature generation operation) according to the standard ISO 9796-2 and with hash algorithm SHA-1. In this case, the TSF digital signature function is implicitly combined with the Tacho- graph Card´s dedicated private authentication key stored in the card. Random numbers necessary for the generation of digital signatures are generated by using the TSF F.RNG_Access of the underlying IC resp. its Dedicated Support Software for random number generation. For the signature mechanism itself, the TSF makes use of the TSF F.RSA of the underlying IC resp. its Dedicated Support Software. For the computation of hash values MICARDO Tachograph Version 1.0 R1.0 99 / 139 ST-Lite TOE Summary Specification 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel the TSF F.SHA-1 of the underlying IC resp. its Dedicated Support Software is used. Furthermore, the security of the TSF is supported by the TSFs F.LOG and F.SIDE_CHAN of the IC and its Dedicated Support Software resp. the Smartcard Embedded Software. Note: Each pivate key used for the signature generation function is generated by the external world and loaded onto the card (during initialisation resp. personalisation). It is in the respon- sibility of the external world to guarantee for a sufficient cryptographic strength of the private key and to handle the private key outside the card in a sufficient secure manner. Under the assumption that the external world meets the requirements on the key handling set above, the TSF digital signature function works in such a manner that the private key cannot be derived from the signature and the signature cannot be generated by other individuals not possessing that secret. Furthermore, the TSF digital signature function works in a manner that no information about the private key may be disclosed during the generation of the digital sig- nature. F.VER_- DIGSIG Verification of Digital Signatures The TSF provides a functionality to verify digital signatures based on asymmetric cryptogra- phy, particularly the RSA algorithm with a key length of 1024 bit. The TSF function to verify a digital signature will be used for several purposes with different keys and different formats for the digital signature input: - Explicit verification of digital signatures of data using the signature scheme with appen- dix (signature verification operation) according to the standard PKCS#1 V2.0 and with hash algorithm SHA-1. - Within authentication processes for the verification of authentication tokens using the signature scheme with message recovery (signature verification operation) according to the standard ISO 9796-2 and with hash algorithm SHA-1. - Within the verification and unwrapping of imported certificates using the signature scheme with message recovery (signature verification operation) according to the stan- dard ISO 9796-2 and with hash algorithm SHA-1. In all cases, the TSF function to verify a digital signature uses the public key which has been referenced before. In this connection, the public key is either stored in the card (e.g. within a certificate) or is loaded onto the card within a certificate by a suitable preceding operation. For the verification mechanism itself, the TSF makes use of the TSF F.RSA of the underlying IC resp. its Dedicated Support Software. For the computation of hash values the TSF F.SHA-1 of the underlying IC resp. its Dedicated Support Software is used. F.ENC Encryption The TSF provides a functionality to encrypt data based on asymmetric cryptography, particu- larly the RSA algorithm with a key length of 1024 bit. The TSF encryption function will be used for the following purpose: - Within authentication processes for the generation of authentication tokens using the encryption primitive according to the standard PKCS#1 V2.0. The TSF encryption function uses the public key which has been referenced before. In this connection, the public key is either stored in the card (e.g. within a certificate) or is loaded onto the card within a certificate by a suitable preceding operation. For the encryption mechanism itself, the TSF makes use of the TSF F.RSA of the underlying IC resp. its Dedicated Support Software. MICARDO Tachograph Version 1.0 R1.0 100 / 139 ST-Lite TOE Summary Specification 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel F.DEC Decryption The TSF provides a functionality to decrypt data based on asymmetric cryptography, particu- larly the RSA algorithm with a key length of 1024 bit. The TSF decryption function will be used for the following purposes: - Within authentication processes for the verification of authentication tokens using the decryption primitive according to the standard PKCS#1 V2.0. - For the secured import of a static symmetric personalisation key (only relevant for the personalisation phase): decryption of the imported cryptogram with the personalisation key using the decryption primitive according to the standard PKCS#1 V2.0 and recover- ing the key from the encryption input (remove of padding). The TSF decryption function is implicitly combined with the Tachograph Card´s dedicated private personalisation key (during the personalisation phase) resp. with the Tachograph Card´s dedicated and unique private signature key (during the end-usage phase of the card). The functionality for a secure import of a static personalisation key is only relevant for the per- sonalisation phase. Note: Each pivate key used for the decryption function is generated by the external world and loaded on the card (during initialisation resp. personalisation). It is in the responsibility of the external world to guarantee for a sufficient cryptographic strength of the private key and to handle the private key outside the card in a sufficient secure manner. Under the assumption that the external world meets the requirements on the key handling set above, the TSF decryption function works in such a manner that no information about the pri- vate key may be disclosed during the decryption operation. For the decryption mechanism itself, the TSF makes use of the TSF F.RSA of the underlying IC resp. its Dedicated Support Software. Furthermore, the security of the TSF is supported by the TSFs F.LOG and F.SIDE_CHAN of the IC and its Dedicated Support Software resp. the Smartcard Embedded Software. 6.2 SOF Claim for TOE Security Functions According to Common Criteria, /CC 2.2 Part1/ and /CC 2.2 Part3/, all TOE Security Func- tions (TSF) which are relevant for the assurance requirement AVA_SOF.1 are identified in this section. The TOE Security Functions using mechanisms which can be analysed for their permuta- tional or probabilistic properties and which contribute to AVA_SOF.1 are the following: • The generation of random numbers by the hardware RNG within the TSF F.RNG resp. by the software RNG within the TSF F.RNG_Access can be analysed with probabilistic methods. • The quality of the mechanisms contributing to the resistance against leakage at- tacks of the TSF F.LOG, especially for the TSF F.HW_DES can be analysed us- ing permutational or probabilistic methods on power consumption of the TOE. MICARDO Tachograph Version 1.0 R1.0 101 / 139 ST-Lite TOE Summary Specification 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel • The implementations of the algorithms for F.DES, F.RSA (only decryption part), F.GEN_DIGSIG and F.DEC are resistant to Simple Power Analysis (SPA), Differ- ential Power Analysis (DPA), Differential Fault Analysis (DFA) and timing attacks. This concerns as well all security critical mechanisms of the TSF F.IA_KEY. The quality of these mechanisms against leakage attacks can be analysed using per- mutational or probabilistic methods. • The implementation of the password based authentication mechanism as used within the TSF F.IA_PWD can be analysed with permutational methods. For each of the TOE Security Functions given in the preceding list an explicit claim of “SOF- high” is made. Notes: The implementation of the TSF F.DATA_INT will be realised by attaching CRC-checksums to defined data areas. Hereby, the mechanisms of generating and checking CRC-checksums can be analysed with permutational or probabilistic methods. But these mechanisms are not relevant for AVA_SOF.1, as the securing of data areas by CRC-checksums is intended only to secure against accidental data modification. The implementations of the TSFs F.RSA (only encryption part), F.VER_DIGSIG and F.ENC use only public keys and do not need to be considered with regard to high attack potential so that securing of the implementations against Simple Power Analysis (SPA), Differential Power Analysis (DPA), Differential Fault Analysis (DFA) and timing attacks is not necessary. Because of this fact, the TSFs – although they can be analysed with permutational or prob- abilistic methods - are not relevant for AVA_SOF.1. Nevertheless, these TSFs are secured by appropriate hardware security features. The implementation for the TSF F.SHA-1 can be analysed with permutational or probabilistic methods, but the TSF does not contribute to AVA_SOF.1 as the developers of the Crypto Library and the Smartcard Embedded Software do not see the hash algorithm as a crypto- graphic mechanism in the sense of the Common Criteria (CC). Nevertheless, this TSF is se- cured by appropriate hardware security features. The TOE´s cryptographic algorithms itself can also be analysed with permutational or prob- abilistic methods but this is not in the scope of CC evaluations. 6.3 Assurance Measures Appropriate assurance measures will be employed by the developer of the TOE to satisfy the security assurance requirements defined in chap. 107H5.1.3. For the evaluation of the TOE, the developer will provide appropriate documents describing these measures and containing further information supporting the check of the conformance of these measures against the claimed assurance requirements. For the Smartcard Embedded Software part of the TOE (TOE-ES), the following table gives a mapping between the assurance requirements and the documents containing the relevant information for the respective requirement. All these documents concerning the TOE-ES are provided by the developer of the TOE-ES. The table below contains only the directly related MICARDO Tachograph Version 1.0 R1.0 102 / 139 ST-Lite TOE Summary Specification 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel documents, references to further documentation can be taken from the mentioned docu- ments. Overview of Developer´s TOE-ES related Documents Assurance Class Family Document containing the relevant information ACM_AUT - Document Configuration Control System ACM_CAP - Document Life-Cycle Model - Document Configuration Control System ACM Configuration Management ACM_SCP - Document Configuration Control System - Document Life-Cycle Model ADO_DEL - Document Life-Cycle Model ADO Delivery and Operation ADO_IGS - Document Installation, Generation and Start-Up Procedures ADV_FSP - Document Functional Specification ADV_HLD - Document High-Level Design - Detailed development documents as system specifications, design specifications, etc. ADV_LLD - Document Low-Level Design - Detailed development documents as system specifications, design specifications, etc. ADV_IMP - Source Code - Detailed development documents as system specifications, design specifications, etc. ADV_RCR - Functional Specification - High-Level Design - Low-Level Design ADV Development ADV_SPM - Document TOE Security Policy Model AGD_ADM --- (Part of the User Guidances.) AGD Guidance Documents AGD_USR - User Guidance for the Personaliser of the Tachograph Card - User Guidance for the Developers of Vehicle Units - User Guidance for the Issuer of the Tachograph Card ALC_DVS - Document Security of the Development Environment ALC_LCD - Document Life-Cycle Model ALC Life Cycle Sup- port ALC_TAT - Configuration List ATE Tests ATE_COV - Document Test Documentation - Detailed test documentation as system test specifications, test protocols, etc. MICARDO Tachograph Version 1.0 R1.0 103 / 139 ST-Lite TOE Summary Specification 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel ATE_DPT - Document Test Documentation - Detailed test documentation as system test specifications, test protocols, etc. ATE_FUN - Document Test Documentation - Detailed test documentation as system test specifications, test protocols, etc. ATE_IND - Samples of the TOE - Source Code AVA_MSU - Document Analysis of the Guidance Documents AVA_SOF - Document TOE Security Function Evaluation AVA Vulnerability Assessment AVA_VLA - Document Vulnerability Analysis As mentioned, the evaluation of the TOE will be done as composite evaluation on basis of the evaluated IC "Philips SmartMX P5CC036V1D Secure Smart Card Controller with Cryp- tographic Library as IC Dedicated Support Software" provided by Philips Semiconductors GmbH. Therefore, for the TOE-IC the following documents will be at least provided by the IC developer: Overview of Developer´s TOE-IC related Documents Class Documents Security Target of the IC evaluation, /ST-ICPhilips/ Security Target Security Target of the IC evaluation incl. Crypto Library, /ST-ICPhilips+Lib/ Evaluation Technical Report Lite (ETR Lite) of the IC evaluation, /ETRLite- ICPhilips/ Evaluation Report Evaluation Technical Report Lite (ETR Lite) of the IC evaluation incl. Crypto Library, /ETRLite-ICPhilips+Lib/ Configuration List Configuration List for composite evaluation with ORGA, /ConfListPhilips/ User Guidance for the IC, /UG-ICPhilips/ Data Sheet for the IC, /DS-ICPhilips/ Instruction Set for the IC, /IS-ICPhilips/ User Guidances User Guidances for the Crypto Library, /UG-Lib/, /UG-Lib-RND/, /UG-Lib- DES/, /UG-Lib-SHA/, /UG-Lib-RSA/ MICARDO Tachograph Version 1.0 R1.0 104 / 139 ST-Lite TOE Summary Specification 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel MICARDO Tachograph Version 1.0 R1.0 105 / 139 ST-Lite PP Claims 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 7 PP Claims Not applicable. Refer to chap. 108H1.3. MICARDO Tachograph Version 1.0 R1.0 106 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 8 Rationale The following chapters cover the security objectives rationale, the security requirements ra- tionale and the TOE summary specification rationale. 8.1 Security Objectives Rationale According to the requirements of Common Criteria, /CC 2.2 Part1/ and /CC 2.2 Part3/, the security objectives rationale demonstrates that the stated security objectives are traceable to all of the aspects identified in the TOE security environment and are suitable to cover them. In detail, the security objectives rationale demonstrates that the stated security objectives for the TOE and its environment are suitable to counter the identified threats to security and to cover all of the identified Organisational Security Policies and assumptions. Vice versa, the security objective rationale shows that each security objective of the TOE and its environ- ment at least counters one threat or is correlated to one Organisational Security Policy or assumption. 8.1.1 Threats - Security Objectives 8.1.1.1 Threats of the TOE-IC The threats of the TOE-IC as defined in chap. 109H3.3.1 are covered completely by the security objectives for the TOE-IC in chap. 110H4.1.1. The mapping of the threats of the TOE-IC to the relevant security objectives is done within the CC evaluation of the IC resp. within the asso- ciated Security Target. 8.1.1.2 General Threats of the TOE-ES The general threats of the TOE-ES as defined in chap. 111H3.3.2 are covered completely by the general security objectives for the TOE-ES and the general security objectives for the envi- ronment of the TOE as listed in chap. 112H4.1.2 and 113H4.2.1. The mapping of the general threats of the TOE-ES to the relevant security objectives is done within the CC evaluation of the Pro- tection Profile /PP9911/, chap. 8.2.2. For the TOE-ES, the assumptions A.Plat-Appl, A.Process-Card and A.Check-Init for the TOE-IC (refer to /ST-ICPhilips+Lib/) have been redefined suitably as security objectives O.Plat-Appl, O.Process-Card and O.Check-Init for the TOE-ES resp. for the environment of the TOE. The following supplements hold concerning these additional security objectives for the TOE-ES resp. the environment of the TOE: MICARDO Tachograph Version 1.0 R1.0 107 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel O.Plat-Appl As the Smartcard Embedded Software (TOE-ES) is designed in such a manner that the re- quirements from the TOE-IC guidance documents (hardware data sheet, application notes etc.) and the findings of the TOE-IC evaluation reports relevant for the Smartcard Embedded Software are met, this security objective contributes to the defense of the threats T.CLON*, T.DIS_ES2, T.T_ES, T.T_CMD, T.MOD_LOAD, T.MOD_EXE, T.MOD_SHARE and T.MOD_SOFT* (and therefore contributes indirectly to the defense of the Tachograph Card specific threats). O.Process-Card This security objective guarantees for secure delivery procedures for the TOE or parts of it by the TOE Manufacturer during the phases 4 to 6 of the product life-cycle with the goal to maintain confidentiality and integrity of the TOE and to prevent any possible copy, modifica- tion, retention, theft or unauthorised use. It therefore counters the threats T.CLON*, T.DIS_DEL1, T.DIS_DEL2, T.MOD_DEL1, T.MOD_DEL2 and T.T_ES (and therefore con- tributes indirectly to the defense of the Tachograph Card specific threats). O.Check-Init The security objective O.Check-Init provides the capability for the external world to check the identity of the TOE-IC by specific IC data. This security objective supplements the security objective O.Identification of the TOE-IC and therefore, the mapping to the relevant threats, assumptions or organisational policies is covered by the CC evaluation of the IC. 8.1.1.3 Tachograph Card Specific Threats The Tachograph Card specific threats as defined in chap. 114H3.3.3 are covered completely by the Tachograph Card specific security objectives and some of the general security objectives for the TOE-ES as listed in chap. 115H4.1.3 and 116H4.1.2. The mapping of the Tachograph Card spe- cific threats to the relevant security objectives is done in the following. Objectives Threats O.Card_ Identifi- cation_ Data O.Card_ Activ- ity_ Storage O.Data_ Access O.Pers_ Access O.Se- cure_ Com- muni- cations O.FLAW * O.OPE- RATE* O.MOD_ MEM- ORY* O.Resp- Appl O.Key- Func- tion O.Pre- condi- tions T.Ident_ Data X X X X X T.Activi- ty_Data X X X X X X X T.Data_ ex- change X X X X X X MICARDO Tachograph Version 1.0 R1.0 108 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel T.Pers_ Data X X X X X T.Pers_ ex- change X X X X X In the following, for each Tachograph Card specific threat it will be explained why and how it is adressed by the security objectives listed in the table above. T.Ident_Data The unalterable storage of personalised identification data of the TOE (cardholder identifica- tion data, card identification data) as defined in the security objective O.Card_- Identification_Data counters directly the threat T.Ident_Data. Furthermore, the more general security objective O.MOD_MEMORY* for the TOE-ES prevents unauthorized modification of the TOE´s storage. As the Smartcard Embedded Software (TOE-ES) treats all its user data as defined for the specific application context, i.e. according to the Tachograph Card specification, the security objective O.Resp-Appl counters the Tachograph Card specific threat T.Ident_Data. The security objectives O.OPERATE* and O.FLAW* support the objectives O.Card_- Identification_Data, O.MOD_MEMORY* and O.Resp-Appl as they provide for the secure operation of the TOE resp. the absence of flaws, and therefore guarantee for a correct and effective realisation of the objectives O.Card_Identification_Data, O.MOD_MEMORY* and O.Resp-Appl. T.Activity_Data The combination of the security objectives O.Data_Access, O.Card_Activity_Storage, O.MOD_MEMORY*, O.Resp-Appl and O.Key-Function counter the threat T.Activity_Data for the following reasons: First, the Tachograph Card specific security objective O.Data_Access limits the user data write access to authenticated vehicle units so that the modification of activity data by regular card commands can be conducted only by authenticated card interface devices. The Tachograph Card specific security objective O.Card_Activity_Storage as well as the general security objective O.MOD_MEMORY* for the TOE-ES guarantee that a manipulation of the storage areas for activity data by other means than by regular card commands is not possible. As the Smartcard Embedded Software (TOE-ES) treats all its user data as defined for the specific application context, i.e. according to the Tachograph Card specification, the security objective O.Resp-Appl counters the Tachograph Card specific threat T.Activity_Data. According to the security objective O.Key-Function, key-dependent functions are imple- mented in the TOE-ES in a way that they are not susceptible to leakage attacks. This count- ers the Tachograph Card specific threat T.Activity_Data. MICARDO Tachograph Version 1.0 R1.0 109 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel The security objectives O.OPERATE* and O.FLAW* support the objectives O.Data_Access, O.Card_Activity_Storage, O.MOD_MEMORY*, O.Resp-Appl and O.Key-Function as they provide for the secure operation of the TOE resp. the absence of flaws, and therefore guar- antee for a correct and effective realisation of the objectives O.Data_Access, O.Card_Activity_Storage, O.MOD_MEMORY*, O.Resp-Appl and O.Key-Function. T.Data_exchange The Tachograph Card specific security objective O.Secure_Communications provides the support for secure communication protocols and procedures between the TOE and card in- terface devices. Especially, this objective supports the securing of the data transfer between the TOE and card interface devices with the goal to prevent modifications during data import and export. This counters directly the threat T.Data_exchange. As the Smartcard Embedded Software (TOE-ES) treats all its user data as defined for the specific application context, i.e. according to the Tachograph Card specification, the security objective O.Resp-Appl counters the Tachograph Card specific threat T.Data_exchange. According to the security objective O.Key-Function, key-dependent functions are imple- mented in the TOE-ES in a way that they are not susceptible to leakage attacks. Further- more, the data download functionality of the Tachograph Card is secured against specific side channel leakage by the security objective O.Preconditions. This counters the Tacho- graph Card specific threat T.Data_exchange. The security objectives O.OPERATE* and O.FLAW* support the objectives O.Secure_- Communications, O.Resp-Appl and O.Key-Function as they provide for the secure operation of the TOE resp. the absence of flaws, and therefore guarantee for a correct and effective realisation of the objectives O.Secure_Communications, O.Resp-Appl and O.Key-Function. T.Pers_Data The Tachograph Card specific security objective O.Pers_Access counters the threat T.Pers_Data for the following reason: The security objective O.Pers_Access limits the per- sonalisation data write access to authenticated personalisation units. As the Smartcard Embedded Software (TOE-ES) treats all its user data as defined for the specific application context, i.e. according to the Tachograph Card specification, the security objective O.Resp-Appl counters the Tachograph Card specific threat T.Pers_Data concern- ing the personalisation phase of the TOE. According to the security objective O.Key-Function, key-dependent functions are imple- mented in the TOE-ES in a way that they are not susceptible to leakage attacks. This count- ers the Tachograph Card specific threat T.Pers_Data concerning the personalisation phase of the TOE. The security objectives O.OPERATE* and O.FLAW* support the objectives O.Pers_Access, O.Resp-Appl and O.Key-Function as they provide for the secure operation of the TOE resp. the absence of flaws, and therefore guarantee for a correct and effective realisation of the objectives O.Pers_Access, O.Resp-Appl and O.Key-Function. MICARDO Tachograph Version 1.0 R1.0 110 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel T.Pers_exchange The Tachograph Card specific security objective O.Secure_Communications provides the support for secure communication protocols and procedures between the TOE and card in- terface devices. Especially, this objective supports the securing of the data transfer between the TOE and card interface devices with the goal to prevent modifications during data import and export. This counters directly the threat T.Pers_exchange. As the Smartcard Embedded Software (TOE-ES) treats all its user data as defined for the specific application context, i.e. according to the Tachograph Card specification, the security objective O.Resp-Appl counters the Tachograph Card specific threat T.Pers_exchange con- cerning the personalisation phase of the TOE. According to the security objective O.Key-Function, key-dependent functions are imple- mented in the TOE-ES in a way that they are not susceptible to leakage attacks. This count- ers the Tachograph Card specific threat T.Pers_exchange concerning the personalisation phase of the TOE. The security objectives O.OPERATE* and O.FLAW* support the objectives O.Secure_- Communications, O.Resp-Appl and O.Key-Function as they provide for the secure operation of the TOE resp. the absence of flaws, and therefore guarantee for a correct and effective realisation of the objectives O.Secure_Communications, O.Resp-Appl and O.Key-Function. 8.1.2 Assumptions - Security Objectives The assumptions for the environment of the TOE as defined in chap. 117H3.2.1 except the as- sumption A.PERS are covered completely by the general security objectives for the environ- ment of the TOE as listed in chap. 118H4.2.1. The mapping of the assumptions for the environ- ment of the TOE to the relevant security objectives is done within the CC evaluation of the Protection Profile /PP9911/, chap. 8.2.3. Furthermore, the security objective O.PERS for the environment of the TOE covers directly the assumption A.PERS, as its definition shows. 8.1.3 Organisational Security Policies - Security Objectives The security objective O.Process-Card requires the developer of the TOE to implement measures as assumed in the Organisational Security Policy P.Process-Card, thus the secu- rity objective is covered by the mentioned Organisational Security Policy. Furthermore, the Organisational Security Policy P.Design-Software obviously covers the se- curity objectives O.Plat-Appl, O.Resp-Appl, O.Check-Init, O.Key-Function and O.Preconditions as their definition shows. MICARDO Tachograph Version 1.0 R1.0 111 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 8.2 Security Requirements Rationale According to the requirements of Common Criteria, /CC 2.2 Part1/ and /CC 2.2 Part3/, the security requirements rationale demonstrates that the set of security requirements of the TOE is suitable to meet and is traceable to the security objectives for the TOE and its envi- ronment. In detail, the following will be demonstrated: • the combination of the individual functional and assurance requirements compo- nents for the TOE and its IT environment together meet the stated security objec- tives • the set of security requirements together form a mutually supportive and internally consistent whole • the choice of security requirements is justified, whereby any of the following condi- tions is specifically justified: - choice of additional requirements not contained in Parts 2 or 3 - choice of additional assurance requirements not included in EAL 4 - non-satisfaction of dependencies • the selected strength of function level for the ST is consistent with the security ob- jectives for the TOE 8.2.1 Security Functional Requirements Rationale The following section demonstrates that the set and combination of the defined security func- tional requirements (SFRs) and security assurance requirements (SARs) for the TOE is suit- able to satisfy the identified security objectives for the TOE and its environment. Further- more, this section shows that each of these SARs and SFRs contributes to at least one of the security objectives for the TOE and its environment. 8.2.1.1 Security Objectives for the TOE-IC - Security Functional Requirements The security objectives for the TOE-IC of chap. 119H4.1.1 are related to the SARs and SFRs for the TOE defined in chap. 120H5.1.3 and 121H5.1.1.1. The mapping of the security objectives for the TOE-IC to the relevant SARs and SFRs is done within the CC evaluation of the IC resp. within the associated Security Target. 8.2.1.2 Security Objectives for the TOE-ES - Security Functional Requirements The general security objectives for the TOE-ES of chap. 122H4.1.2 except O.Plat-Appl, O.Resp- Appl, O.Check-Init, O.Key-Function and O.Preconditions are related to the SARs and SFRs for the TOE defined in chap. 123H5.1.3 and 124H5.1.1.2. The mapping of these general security objec- MICARDO Tachograph Version 1.0 R1.0 112 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel tives for the TOE-ES to the relevant SARs and SFRs is done within the CC evaluation of the Protection Profile /PP9911/, chap. 8.3.1. For the TOE-ES, as mentioned before, the assumptions A.Plat-Appl, A.Resp-Appl, A.Check- Init, A.Key-Function and A.Preconditions of the TOE-IC (refer to /ST-ICPhilips+Lib/) have been redefined suitably as security objectives for the TOE-ES. The following supplements hold concerning these additional security objectives for the TOE-ES: O.Plat-Appl, O.Resp-Appl The design of the TOE-ES in such a manner, that the requirements from the TOE-IC guid- ance documents (hardware data sheet, application notes etc.), from the findings of the TOE- IC evaluation reports relevant for the Smartcard Embedded Software and from the require- ments of the Tachograph Card specification are met (O.Plat-Appl, O.Resp-Appl), is covered by the SARs for the whole TOE. In particular, the components of the class ADV with its de- sign documentation and implementation representation (refer to chap. 125H5.1.3) contribute to the fulfillment of the security objectives O.Plat-Appl and O.Resp-Appl. O.Key-Function, O.Preconditions The design of the TOE-ES in such a manner, that the key-dependent functions are imple- mented in the TOE-ES in such a way that they are not susceptible to leakage attacks (O.Key-Function) is covered by the SARs for the whole TOE. The same holds for hash value calculations and RSA operations with private keys in the case that side channel attacks have to be taken into account (O.Preconditions). In particular, the components of the class ADV with its design documentation and implementation representation and the components of the class AVA for vulnerability analysis (refer to chap. 126H5.1.3) contribute to the fulfillment of the security objectives O.Key-Function and O.Preconditions. O.Check-Init The security objective O.Check-Init provides the capability for the external world to check the initialisation data brought into the TOE during the IC manufacturing. This security objective supplements the security objective O.Identification of the TOE-IC and therefore, the mapping to the relevant SFRs and SARs is covered by the CC evaluation of the IC. Furthermore, this security objective is covered by the SARs for the whole TOE, in particular by the components of the class ADV with its design documentation and implementation representation (refer to chap. 127H5.1.3). 8.2.1.3 Tachograph Card Specific Security Objectives - Security Functional Requirements The Tachograph Card specific security objectives as defined in chap. 128H4.1.3 are related to the SFRs for the TOE-ES as defined in chap. 129H5.1.1.2. The mapping of the Tachograph Card specific security objectives to the relevant SFRs is done in the following. MICARDO Tachograph Version 1.0 R1.0 113 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel The table below gives an overview which SFRs for the TOE-ES contribute to the satisfaction of each Tachograph Card specific security objective. For clarity, the table does not identify indirect dependencies. SFRs Security Objectives Principal SFRs Supporting SFRs O.Card_- Identification_Data FAU_SAA.1-1 FDP_ACC.2-1 FDP_ACF.1-1 FDP_SDI.2-1 FPT_FLS.1-1 FPT_PHP.3-1 FPT_SEP.1-1 FPT_TST.1-1 O.Card_- Activity_Storage FAU_SAA.1-1 FDP_ACC.2-1 FDP_ACF.1-1 FDP_SDI.2-1 FPT_FLS.1-1 FPT_PHP.3-1 FPT_SEP.1-1 FPT_TST.1-1 O.Data_Access FDP_ACC.2-1 FDP_ACF.1-1 FIA_AFL.1-1 FIA_ATD.1-1 FIA_UAU.1-1 FIA_UAU.3-1 FIA_UID.1-1 FIA_USB.1-1 FPT_FLS.1-1 FPT_PHP.3-1 FPT_SEP.1-1 FPT_TST.1-1 O.Pers_Access FDP_ACC.2-2 FDP_ACF.1-2 FIA_AFL.1-1 FIA_ATD.1-1 FIA_UAU.1-1 FIA_UAU.3-1 FIA_UID.1-1 FIA_USB.1-1 FPT_FLS.1-1 FPT_PHP.3-1 FPT_SEP.1-1 FPT_TST.1-1 O.Secure_- Communications FAU_SAA.1-1 FCO_NRO.1-1 FCS_CKM.1-1 FCS_CKM.2-1 FCS_CKM.2-2 FCS_CKM.2-3 FCS_CKM.3-1 FCS_CKM.3-2 FCS_CKM.3-3 FCS_CKM.3-4 FCS_CKM.3-5 FCS_CKM.4-1 FCS_CKM.4-2 FCS_COP.1-1 FCS_COP.1-2 FCS_COP.1-3 FCS_COP.1-4 FCS_COP.1-5 FDP_DAU.1-1 FDP_ACC.2-1 FDP_RIP.1-1 FPT_FLS.1-1 FPT_PHP.3-1 FPT_SEP.1-1 FPT_TST.1-1 MICARDO Tachograph Version 1.0 R1.0 114 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel FDP_ACF.1-1 FDP_ACC.2-2 FDP_ACF.1-2 FDP_ETC.1-1 FDP_ETC.2-1 FDP_ITC.1-1 FIA_UAU.3-1 FIA_UAU.4-1 FPR_UNO.1-1 FPR_UNO.1-2 FPR_UNO.1-3 FPT_TDC.1-1 In the following, for each Tachograph Card specific security objective it will be explained why and how it is satisfied by the SFRs listed in the preceding table. O.Card_Identification_Data According to the security objective O.Card_Identification_Data, the TOE preserves identifica- tion data stored in the framework of the card´s personalisation. Within phase 7 of the TOE´s life-cycle (end-usage phase), the access to the TOE´s data, especially to the identification data is regulated by the security function policy AC_SFP as defined in chap. 130H5.1.1.2.1. This SFP, accomplished by the components FDP_ACC.2-1 and FDP_ACF.1-1, denies explicitly the write access to personalised identification data. The integrity of the stored data within the TOE, especially the integrity of the identification data is secured by the component FDP_SDI.2-1. In case of an integrity error detected by the component FAU_SAA.1-1, the TOE will indicate a violation of the TSP. Finally, the components FPT_FLS.1-1, FPT_PHP.3-1, FPT_SEP.1-1 and FPT_TST.1-1 sup- port the correct and secure operation of the TOE with regard to the stored identification data and their modification. O.Card_Activity_Storage According to the security objective O.Card_Activity_Storage, the TOE preserves user data stored in the card by vehicle units. Within phase 7 of the TOE´s life-cycle (end-usage phase), the access to the TOE´s data, especially to the user data is regulated by the security function policy AC_SFP as defined in chap. 131H5.1.1.2.1. This SFP, accomplished by the components FDP_ACC.2-1 and FDP_ACF.1-1, restricts explicitly the write access to user data to authenticated vehicle units. The integrity of the stored data within the TOE, especially the integrity of the user data writ- ten by vehicle units is secured by the component FDP_SDI.2-1. In case of an integrity error detected by the component FAU_SAA.1-1, the TOE will indicate a violation of the TSP. MICARDO Tachograph Version 1.0 R1.0 115 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Finally, the components FPT_FLS.1-1, FPT_PHP.3-1, FPT_SEP.1-1 and FPT_TST.1-1 sup- port the correct and secure operation of the TOE with regard to the user data written by vehi- cle units and their modification. O.Data_Access The security objective O.Data_Access limits the user data write access in the TOE´s end- usage phase to authenticated vehicle units. Within phase 7 of the TOE´s life-cycle (end-usage phase), the access to the TOE´s data, especially to the user data is regulated by the security function policy AC_SFP as defined in chap. 132H5.1.1.2.1. This SFP, accomplished by the components FDP_ACC.2-1 and FDP_ACF.1-1, restricts explicitly the write access to user data to authenticated vehicle units. The component FIA_USB.1-1 together with FIA_ATD.1-1 with its definition of the user secu- rity attributes supplies a distinction between vehicle units and other card interface devices (which complies with the definitions in the security function policy AC_SFP). The components FIA_UID.1-1 and FIA_UAU.1-1 ensure that especially write access to user data is not possi- ble without a preceding successful authentication process. If the authentication fails, the component FIA_AFL.1-1 reacts with a warning to the connected entity, and the user will be assumed as different from a vehicle unit. The component FIA_UAU.3-1 prevents the use of forged authentication data. Finally, the components FPT_FLS.1-1, FPT_PHP.3-1, FPT_SEP.1-1 and FPT_TST.1-1 sup- port the correct and secure operation of the TOE with regard to user data write access. O.Pers_Access The security objective O.Pers_Access limits the personalisation data write access in the TOE´s personalisation phase to authenticated personalisation units. Within phase 6 of the TOE´s life-cycle (personalisation phase), the access to the TOE´s per- sonalisation data is regulated by the security function policy AC-PERS_SFP as defined in chap. 133H5.1.1.2.1. This SFP, accomplished by the components FDP_ACC.2-2 and FDP_ACF.1-2, restricts explicitly the write access to personalisation data to authenticated personalisation units. The component FIA_USB.1-1 together with FIA_ATD.1-1 with its definition of the user secu- rity attributes supplies a distinction between personalisation units and other card interface devices (which complies with the definitions in the security function policy AC-PERS_SFP). The components FIA_UID.1-1 and FIA_UAU.1-1 ensure that especially write access to per- sonalisation data is not possible without a preceding successful authentication process. If the authentication fails, the component FIA_AFL.1-1 reacts with a warning to the connected en- tity, and the user will be assumed as different from a personalisation unit. The component FIA_UAU.3-1 prevents the use of forged authentication data. Finally, the components FPT_FLS.1-1, FPT_PHP.3-1, FPT_SEP.1-1 and FPT_TST.1-1 sup- port the correct and secure operation of the TOE with regard to personalisation data write access. MICARDO Tachograph Version 1.0 R1.0 116 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel O.Secure_Communications The security objective O.Secure_Communications contains the capability of the TOE to sup- port secure communication protocols and procedures between the card and the card inter- face device when required by the application. This concerns on the one side a secured data exchange between the TOE and the card interface device over a trusted channel, and on the other side a special data download functionality. For the end-usage phase of the TOE as well as for the personalisation of the TOE on base of the dynamic personalisation scheme (see chap. 134H2.3.3) the following secure communication protocol is implemented: The component FTP_ITC.1-1 together with FDP_ETC.1-1 and FDP_ITC.1-1 offers the possibility to secure the data exchange (i.e. the data import and ex- port) between the TOE and the card interface device by using a trusted channel assuring identification of its end points and protection of the data transfer from modification and dis- closure. Hereby, both parties are capable of verifying the received data with regard to their integrity and authenticity. The trusted channel assumes a successful preceding mutual key based authentication process between the TOE and the card interface device with agree- ment of session keys which is covered by the components FCS_CKM.1-1, FCS_CKM.2-1, FCS_CKM.2-2, FCS_CKM.3-1, FCS_CKM.3-2, FCS_CKM.3-3, FCS_CKM.3-4, FCS_COP.1- 2 and FCS_COP.1-3 for cryptographic support. The cryptographic components FCS_CKM.3- 5, FCS_COP.1-4 and FCS_COP.1-5 realise the securing of the data exchange itself. The components FPR_UNO.1-1 and FPR_UNO.1-2 guarantee for the unobservability of the in- stall process of the trusted channel and for the unobservability of the data exchange itself which both contributes to a secure data transfer. As well, the components FIA_UAU.3-1 and FIA_UAU.4-1 support the security of the trusted channel as the TOE prevents the use of forged authentication data and as the TOE´s input for the authentication tokens and for the session keys within the preceding authentication process is used only one time. During data exchange, upon detection of an integrity error of the imported data, the TOE will indicate a violation of the TSP and will send a warning to the entity sending the data, which is realised by the component FAU_SAA.1-1. Erasing of key material at the end of the personalisation phase is given with the components FCS_CKM.4-1 and FCS_CKM.4-2. The personalisation procedure for the TOE on base of the static scheme (see chap. 135H2.3.3) implements in an analogue manner a secure communication protocol. As realised for the dynamic personalisation scheme described above, the components FTP_ITC.1-1, FDP_ETC.1-1 and FDP_ITC.1-1 provide for the static scheme the possibility of a secure data exchange (i.e. the data import and export) between the TOE and the card interface device by using a trusted channel. Only authenticated personalisation units are allowed to personalize the TOE, and protection of the data transfer from modification and disclosure is guaranteed. The trusted channel assumes a successful preceding external key based authentication pro- cess of the card interface device. The external authentication is necessary for activating a static personalisation key stored on the card and covers the components FCS_CKM.3-2, FCS_CKM.3-3, FCS_COP.1-2 and FCS_COP.1-3 for cryptographic support. The static per- sonalisation key is stored on the card during the TOE´s production phase or is alternatively loaded in an additional pre-personalisation phase, covered by the components FCS_CKM.2- 3, FCS_CKM.3-3 and FCS_COP.1-3. The cryptographic components FCS_CKM.3-5, FCS_COP.1-4 and FCS_COP.1-5 realise the securing of the data exchange itself. The com- ponents FPR_UNO.1-3, FPR_UNO.1-2, FIA_UAU.3-1, FIA_UAU.4-1 and FAU_SAA.1-1 con- tribute to the requirement for a secure communication protocol in an analogue manner as described above for the dynamic personalisation scheme. Erasing of the static personalisa- tion key at the end of the personalisation phase is given with the component FCS_CKM.4-1. Furthermore, within the TOE´s end-usage phase, the TOE offers a data download functional- ity with specific properties. The TOE provides the capability to generate an evidence of origin MICARDO Tachograph Version 1.0 R1.0 117 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel for the data downloaded to the external media, to verify this evidence of origin by the recipi- ent of the data downloaded and to download the data to external media in such a manner that the data integrity can be verified. All these requirements are covered by FDP_ETC.2-1, FCO_NRO.1-1 and FDP_DAU.1-1. The corresponding cryptographic components for con- ducting the data download process with its security features are given with FCS_CKM.3-1, FCS_CKM.3-2 and FCS_COP.1-1. For each secure communication protocol described above, the component FPT_TDC.1-1 ensures for a consistent interpretation of the security related data shared between the TOE and the external world. The necessity for the usage of a secure communication protocol as well as the access to the relevant card´s keys is deposited in the security function policies AC_SFP (for the end-usage phase of the TOE´s life-cycle) resp. AC-PERS_SFP (for the personalisation phase of the TOE´s life-cycle). These policies correspond directly to the SFRs FDP_ACC.2-1 and FDP_ACF.1-1 resp. FDP_ACC.2-2 and FDP_ACF.1-2. Finally, the components FDP_RIP.1-1, FPT_FLS.1-1, FPT_PHP.3-1, FPT_SEP.1-1 and FPT_TST.1-1 support the correct and secure operation of the TOE with regard to the secure communication protocols of the security objective O.Secure_Communications. 8.2.2 Security Functional Requirements Dependencies The following section demonstrates that all dependencies between the identified security functional requirements included in this ST are satisfied. 8.2.2.1 SFRs of the TOE-IC The dependencies under the SFRs for the TOE-IC of chap. 136H5.1.1 are considered in the scope of the CC evaluation of the IC resp. within the associated Security Target. 8.2.2.2 SFRs of the TOE-ES The table below gives an overview of all SFRs defined for the TOE-ES and their dependen- cies. For each SFR, an information is provided about which dependency is relevant and wether and by which other SFRs of this ST the dependency is satisfied. Hereby, if there exist according to the definitions in /CC 2.2 Part2/ alternative dependencies, only the chosen one is listed. Furthermore, only direct dependencies are considered. Num- ber SFR (Direct) Dependencies Comment / Line Num- ber 1 FAU_SAA.1-1 Potential Violation Analysis - FAU_GEN.1 Audit data genera- tion See below. MICARDO Tachograph Version 1.0 R1.0 118 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 2 FCO_NRO.1-1 Selective Proof of Origin - FIA_UID.1-1 Timing of identifica- tion 34 3 FCS_CKM.1-1 Cryptographic Key Generation - [FCS_CKM.2-1 Cryptographic key distribution] - FCS_CKM.4-1 Cryptographic key destruction 4, 11 4 FCS_CKM.2-1 Cryptographic Key Distribution - [FCS_CKM.1-1 Cryptographic key generation] - FCS_CKM.4-1 Cryptographic key destruction 3, 11 5 FCS_CKM.2-2 Cryptographic Key Distribution - [FDP_ITC.1-1 Import of user data without security attributes] - FCS_CKM.4-2 Cryptographic key destruction 25, 12 5a FCS_CKM.2-3 Cryptographic Key Distribution - [FDP_ITC.1-1 Import of user data without security attributes] - FCS_CKM.4-1 Cryptographic key destruction 25, 11 6 FCS_CKM.3-1 Cryptographic Key Access - [FDP_ITC.1-1 Import of user data without security attributes] 25 7 FCS_CKM.3-2 Cryptographic Key Access - [FDP_ITC.1-1 Import of user data without security attributes] - FCS_CKM.4-2 Cryptographic key destruction 25, 12 8 FCS_CKM.3-3 Cryptographic Key Access - [FDP_ITC.1-1 Import of user data without security attributes] 25 9 FCS_CKM.3-4 Cryptographic Key Access - [FDP_ITC.1-1 Import of user data without security attributes] - FCS_CKM.4-2 Cryptographic key destruction 25, 12 10 FCS_CKM.3-5 Cryptographic Key Access - [FCS_CKM.1-1 Cryptographic key generation] (for session key) resp. [FDP_ITC.1-1 Import of user data without security attributes] (for static key) - FCS_CKM.4-1 Cryptographic key destruction 3, 25, 11 11 FCS_CKM.4-1 Cryptographic Key Destruction - [FCS_CKM.1-1 Cryptographic key generation] (for session key) resp. [FDP_ITC.1-1 Import of user data without security attributes] (for static key) 3, 25 12 FCS_CKM.4-2 Cryptographic Key Destruction - [FDP_ITC.1-1 Import of user data without security attributes] 25 13 FCS_COP.1-1 Cryptographic Opera- - [FDP_ITC.1-1 Import of user data 25, 12 MICARDO Tachograph Version 1.0 R1.0 119 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel tion without security attributes] - FCS_CKM.4-2 Cryptographic key destruction 14 FCS_COP.1-2 Cryptographic Opera- tion - [FDP_ITC.1-1 Import of user data without security attributes] - FCS_CKM.4-2 Cryptographic key destruction 25, 12 15 FCS_COP.1-3 Cryptographic Opera- tion - [FDP_ITC.1-1 Import of user data without security attributes] - FCS_CKM.4-2 Cryptographic key destruction 25, 12 16 FCS_COP.1-4 Cryptographic Opera- tion - [FCS_CKM.1-1 Cryptographic key generation] (for session key) resp. [FDP_ITC.1-1 Import of user data without security attributes] (for static key) - FCS_CKM.4-1 Cryptographic key destruction 3, 25, 11 17 FCS_COP.1-5 Cryptographic Opera- tion - [FCS_CKM.1-1 Cryptographic key generation] (for session key) resp. [FDP_ITC.1-1 Import of user data without security attributes] (for static key) - FCS_CKM.4-1 Cryptographic key destruction 3, 25, 11 18 FDP_ACC.2-1 Complete Access Control - FDP_ACF.1-1 Security attribute based access control 20 19 FDP_ACC.2-2 Complete Access Control - FDP_ACF.1-2 Security attribute based access control 21 20 FDP_ACF.1-1 Security Attribute Based Access Control - FDP_ACC.2-1 Complete access control 18 (higher hierachical element) 21 FDP_ACF.1-2 Security Attribute Based Access Control - FDP_ACC.2-2 Complete access control 19 (higher hierachical element) 22 FDP_DAU.1-1 Basic Data Authenti- cation none --- 23 FDP_ETC.1-1 Export of User Data without Security At- tributes - [FDP_ACC.2-1 Complete access control - [FDP_ACC.2-2 Complete access control 18, 19 (higher hier- achical ele- ments) 24 FDP_ETC.2-1 Export of User Data with Security Attrib- utes - [FDP_ACC.2-1 Complete access control 18 (higher hierachical element) 25 FDP_ITC.1-1 Import of User Data without Security At- - [FDP_ACC.2-1 Complete access control 18, 19 (higher hier- MICARDO Tachograph Version 1.0 R1.0 120 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel tributes - [FDP_ACC.2-2 Complete access control achical ele- ments) 26 FDP_RIP.1-1 Subset Residual In- formation Protection none --- 27 FDP_SDI.2-1 Stored Data Integrity Monitoring and Action none --- 28 FIA_AFL.1-1 Authentication Failure Handling - FIA_UAU.1-1 Timing of authenti- cation 31 29 FIA_AFL.1-2 Authentication Failure Handling - FIA_UAU.1-1 Timing of authenti- cation 31 30 FIA_ATD.1-1 User Attribute Defini- tion none --- 31 FIA_UAU.1-1 Timing of Authentica- tion - FIA_UID.1-1 Timing of identifica- tion 34 32 FIA_UAU.3-1 Unforgeable Authen- tication none --- 33 FIA_UAU.4-1 Single-use Authenti- cation Mechanisms none --- 34 FIA_UID.1-1 Timing of Identifica- tion none --- 35 FIA_USB.1-1 User-Subject Binding - FIA_ATD.1-1 User attribute defini- tion 30 36 FMT_MOF.1 Management of Secu- rity Functions Behav- iour SFR not applicable (see below). 37 FMT_MSA.1 Management of Secu- rity Attributes SFR not applicable (see below). 38 FMT_MSA.2 Secure Security At- tributes SFR not applicable (see below). 39 FMT_MSA.3 Static Attribute Ini- tialisation SFR not applicable (see below). 40 FMT_MTD.1 Management of TSF Data SFR not applicable (see below). 40a FMT_SMF.1 Specification of Man- agement Functions SFR not applicable (see below). 41 FMT_SMR.1 Security Roles SFR not applicable (see below). 42 FPR_UNO.1-1 Unobservability none --- 43 FPR_UNO.1-2 Unobservability none --- MICARDO Tachograph Version 1.0 R1.0 121 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 43a FPR_UNO.1-3 Unobservability none --- 44 FPT_FLS.1-1 Failure with Preserva- tion of Secure State - ADV_SPM.1 Informal TOE secu- rity policy model Given by assurance class (see below). 45 FPT_PHP.3-1 Resistance to Physi- cal Attack none --- 46 FPT_SEP.1-1 TSF Domain Separa- tion none --- 47 FPT_TDC.1-1 Inter-TSF Basic TSF Data Consistency none --- 48 FPT_TST.1-1 TSF Testing - FPT_AMT.1 Abstract machine testing See below. 49 FTP_ITC.1-1 Inter-TSF trusted channel none --- The preceding table shows that the functional component dependencies are satisfied by any functional component defined in this ST except for the components stated in the fourth row in bold characters and the FMT-components, which is explained as follows: The dependency of FAU_SAA.1-1 with FAU_GEN.1 (Audit Data Generation) is not appli- cable to the TOE. The FAU_GEN.1 component forces many security relevant events to be recorded (due to dependencies with other functional security components) and this is not achievable in a smartcard since many of these events result in card being in an insecure state where recording of the event itself could cause a security breach. The function FAU_SAA.1-1 is still be used and the specific audited events are defined in the ST inde- pendently of FAU_GEN.1. The dependency of FPT_TST.1-1 with FPT_AMT.1 (Abstract Machine Testing) is not rele- vant for a smartcard. FPT_TST.1-1 is self-consistent for the TOE (hardware and software) and does not require the FPT_AMT.1 function. The TOE software is not tested inside the scope of FPT_TST.1-1. In its relations with external devices, the TOE is always the slave. This is why FPT_TST.1-1 is-self consistent, and FPT_AMT.1 is not applicable. The dependency of FCS_CKM.3-1 and FCS_CKM.3-3 with FCS_CKM.4 (Cryptographic key destruction) is not applicable as the SFRs FCS_CKM.3-1 and FCS_CKM.3-3 contain the access to a private RSA-key which is stored permanently on the card. This private key is stored during personalisation, and afterwards no key destruction will happen. The dependency of FCS_COP.1-1, FCS_COP.1-2 and FCS_COP.1-3 with FCS_CKM.4 (Cryptographic key destruction) is only relevant for cryptographic operations with public keys. As the TOE´s functionality as defined in the Tachograph Card specification /TachAn1B/ re- quires no functionality regarding the management of TOE Security Functions, security attrib- utes, roles or TSF Data, all FMT-components of /PP9911/ are not applicable for the TOE. MICARDO Tachograph Version 1.0 R1.0 122 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 8.2.3 Strength of Function Level Rationale Due to the requirements in the Tachograph Card specification /TachAn1B/, main body and Appendix 10 (Tachograph Card Generic Security Target), and under consideration of the JIL interpretations /JILDigTacho/, the level for the strength of the TOE´s security functional re- quirements is claimed as SOF-high. The TOE is considered as a product with critical security mechanisms which only have to be defeated by attackers possessing a high level of exper- tise, opportunity and resources, and whereby successful attack is judged beyond normal practicality. 8.2.4 Security Assurance Requirements Rationale The assurance requirements of this ST defined in chap. 137H5.1.3 are summarized in the follow- ing table: Assurance Require- ments Name Type EAL4 Methodically Designed, Tested and Reviewed Assurance Level / Class ADO_IGS.2 Generation Log Higher hierarchical component ADV_IMP.2 Implementation of the TSF Higher hierarchical component ATE_DPT.2 Testing: Low-Level Design Higher hierarchical component AVA_VLA.4 Highly Resistant Higher hierarchical component 8.2.4.1 Evaluation Assurance Level Rationale Due to the requirements in the Tachograph Card specification /TachAn1B/, main body and Appendix 10 (Tachograph Card Generic Security Target) concerning the evaluation level of the TOE and under consideration of the JIL interpretations /JILDigTacho/, chap. 2.2 and An- nex A, the assurance level for the TOE is chosen as EAL4 augmented by ADO_IGS.2, ADV_IMP.2, ATE_DPT.2 and AVA_VLA.4. Hereby, all assurance components will be used as defined in /CC 2.2 Part3/ and /CEM 2.2 Part2/ with the refinements as noted in the JIL interpretations /JILDigTacho/, Annex A.3 and A.5 (refer to chap. 138H5.1.4 of this ST). The choice of the CC assurance components for the TOE incl. the chosen augmentations and refine- ments provides an assurance level comparable to the evaluation level ITSEC E3 high. MICARDO Tachograph Version 1.0 R1.0 123 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel The evaluation assurance level of EAL4 augmented is selected for the TOE since this level provides an adequate and meaningful level of assurance for the TOE, with regard to the se- curity of the development process of the TOE as well as with regard to the TOE´s security and resistance against attacks with high attack potential in its operational use. The chosen assurance level permits the developer to gain maximum assurance from positive security engineering based on good commercial practices and represents a sufficiently high practical level of assurance expected for the security product. Furthermore, to guarantee for a suffi- ciently secure product, the evaluators should have access especially to the low level design and source code, whereby the lowest assurance level for such access is given with the as- surance class EAL4. A more detailed rationale for the chosen augmentations of the evaluation assurance class EAL4 is provided in the following chap. 139H8.2.4.2. The assurance level EAL4 augmented requires knowledge of the Common Criteria evalua- tion scheme and process, but does not make use of specialist techniques on the part of the developer. 8.2.4.2 Assurance Augmentations Rationale The following section gives reason for the choice of the assurance components augmenting the evaluation assurance class EAL4. Apriori, the assurance components ADO_IGS.2, ADV_IMP.2, ATE_DPT.2 and AVA_VLA.4 are chosen with respect to the requirements in the JIL interpretations /JILDigTacho/, Annex A.3 and A.5 in order to achieve a CC assurance level comparable to ITSEC E3 high as re- quired in the Tachograph Card specification /TachAn1B/, main body and Appendix 10 (Ta- chograph Card Generic Security Target). In detail, the following deliberations are of interest: ADO_IGS.2 Generation Log Installation, generation and start-up procedures are useful for ensuring that the TOE has been installed, generated and started up in a secure manner as intended by the developer. The requirements for installation, generation and start-up call for a secure transition from the TOE’s implementation representation being under configuration control to its initial operation in the user environment. The assurance component ADO_IGS.2 is a higher hierarchical component to EAL4, which only requires ADO_IGS.1 „Installation, generation, and start-up procedures“. The augmentation by ADO_IGS.2 with the interpretation and refinement given in the JIL in- terpretations /JILDigTacho/, Annex A.3 Note 2 (refer to chap. 140H5.1.4 of this ST) is required with regard to the evaluation level ITSEC E3 high. It is important for the TOE and its assur- ance that the evaluator does not evaluate only the steps necessary for a secure installation, generation and start-up of the TOE. Moreover, the procedures shall be capable of creating a log containing the generation options used to generate the TOE in such a way that it is pos- sible to determine exactly how and when the TOE was generated. MICARDO Tachograph Version 1.0 R1.0 124 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel ADV_IMP.2 Implementation of the TSF The implementation representation is used to express the notion of the least abstract repre- sentation of the TSF, specifically the one that is used to create the TSF itself without further design refinement. The assurance component ADV_IMP.2 is a higher hierarchical component to EAL4, which only requires ADV_IMP.1 „Subset of the implementation of the TSF“. The augmentation by ADV_IMP.2 with the interpretation given in the JIL interpretations /JILDigTacho/, Annex A.3 Note 5 is required with regard to the evaluation level ITSEC E3 high. It is important for the TOE and its assurance that the evaluator evaluates the implemen- tation representation of the entire TSF to determine that the SFRs as defined in the ST are addressed by the representation of the TSF and that the implementation representation is an accurate and complete instantiation of the TOE´s SFRs. This provides a direct correspon- dence between the TOE´s SFRs and the implementation representation, in addition to the pairwise correspondences required by the ADV_RCR family. ATE_DPT.2 Testing: Low-Level Design Testing of the TSFs and their internal structure is done with the objective to counter the risk of missing an error or malicious code in the development of the TOE. Testing that exercises specific internal interfaces can provide assurance not only that the TSF exhibits the desired external security behaviour, but also that this behaviour stems from correctly operating inter- nal mechanisms. The assurance component ATE_DPT.2 is a higher hierarchical component to EAL4, which only requires ATE_DPT.1 „Testing: high-level design“. The augmentation by ATE_DPT.2 with the interpretation given in the JIL interpretations /JILDigTacho/, Annex A.3 Note 8 is required with regard to the evaluation level ITSEC E3 high. It is important for the TOE and its assurance that testing of the TSFs is not only done on basis of the high-level description of the internal workings of the TSF (level of the subsys- tems) in order to demonstrate the absence of any flaws and to provide assurance that the TSF subsystems have been correctly realised. Moreover, the testing of the TSFs shall cover tests on the modules of the TSFs providing a low-level description of the internal workings of the TSF with the goal to demonstrate the absence of any flaws and to provide assurance that the TSF modules have been correctly realised. The depth analysis shall demonstrate that the tests identified in the test documentation are sufficient to demonstrate that the TSF operates in accordance with its high-level design and low-level design. AVA_VLA.4 Highly Resistant According to the definition of the TOE, it must be shown to be highly resistant to penetration attacks. This is due to the fact that the TOE can be placed in a hostile environment. This assurance requirement is achieved by the assurance component AVA_VLA.4. Inde- pendent vulnerability analysis is based on highly detailed technical information. The attacker is assumed to be thoroughly familiar with the specific implementation of the TOE and is pre- sumed to have a high level of technical sophistication. MICARDO Tachograph Version 1.0 R1.0 125 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel The assurance component AVA_VLA.4 is a higher hierarchical component to EAL4, which only requires AVA_VLA.2 „Independent vulnerability anaysis“. The augmentation by AVA_VLA.4 with the interpretation given in the JIL interpretations /JILDigTacho/, Annex A.3 Note 9 and 11 is required with regard to the evaluation level IT- SEC E3 high. For AVA_VLA.4, a systematical vulnerability analysis is performed by the de- veloper to ascertain the presence of security vulnerabilities, and to confirm that they cannot be exploited in the intended environment for the TOE. Hereby, the analysis shall provide a justification that the analysis completely addresses the TOE deliverables. The evaluator per- forms independent penetration testing, supported by the evaluator’s independent vulnerabil- ity analysis, to determine that the TOE is resistant to penetration attacks performed by at- tackers possessing a high attack potential. 8.2.5 Security Assurance Requirements Dependencies The security assurance requirements specified by this ST are drawn from the assurance class EAL4 with its augmentation by the higher hierarchical components ADO_IGS.2, ADV_IMP.2, ATE_DPT.2 and AVA_VLA.4. EAL4 is asserted to be a known set of assurance components for which all dependencies are satisfied. For the components of the augmentation the following deliberation shows that all further dependencies resulting from the augmentation are satisfied: ADO_IGS.2 has a dependency with AGD_ADM.1“ Administrator Guidance”. This depend- ency is satisfied by EAL4. ADV_IMP.2 has dependencies with ADV_LLD.1 „Descriptive Low-Level design”, ADV_RCR.1 „Informal correspondence demonstration”, ALC_TAT.1 „Well defined develop- ment tools”. These components are included in EAL4, and so these dependencies are satis- fied. ATE_DPT.2 has dependencies with ADV_HLD.2 „Security enforcing high-level design“, ADV_LLD.1 „Descriptive low-level design“ and ATE_FUN.1 „Functional testing“. All these dependencies are satisfied by EAL4. AVA_VLA.4 has dependencies with ADV_FSP.1 „Informal functional specification”, ADV_HLD.2 „Security enforcing high-level design”, ADV_LLD.1 „Descriptive low level de- sign”, ADV_IMP.1 „Subset of the implementation of the TSF”, AGD_ADM.1“ Administrator Guidance” and AGD_USR.1 „User Guidance”. All these dependencies are satisfied by EAL4. 8.2.6 Security Requirements – Mutual Support and Internal Consistency The following part of the security requirements rationale shows that the set of security re- quirements for the TOE consisting of the security assurance requirements (SARs) and the security functional requirements (SFRs) together forms a mutually supportive and internally consistent whole. The analysis of the TOE´s security requirements with regard to their mutual support and in- ternal consistency demonstrates: MICARDO Tachograph Version 1.0 R1.0 126 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel • The assurance class EAL4 is an established set of mutually supportive and inter- nally consistent assurance requirements. • The dependency analysis for the additional assurance components in chap. 141H8.2.5 shows that the assurance requirements are mutually supportive and internally consistent as all (additional) dependencies are satisfied and no inconsistency ap- pears. • The dependency analysis in chap. 142H8.2.2 for the security functional requirements of the TOE-IC and the TOE-ES shows that the basis for mutual support and internal consistency between all defined functional requirements is satisfied. All depend- encies between the chosen functional components are analysed, and non- dissolved dependencies are appropriately explained. The mutual support and internal consistency of the functional requirements is shown for the TOE-IC relevant SFRs in the scope of the CC evaluation of the TOE-IC resp. in the correlated ST and for the TOE-ES relevant SFRs in chap. 143H8.2.1.2 and 144H8.2.1.3 within the mapping of the security objectives to the SFRs. Concerning the SFRs of the TOE-ES, the SFRs drawn from /PP9911/ build as shown in the rationale of the protection profile a mutually supportive and internally consistent whole. The additional SFRs resulting from the Tachograph Card speci- fication /TachAn1B/, Appendix 10 (Tachograph Card Generic Security Target) and the JIL interpretations /JILDigTacho/, Annex B suitably supplement the SFRs of the protection profile and do not lead to any inconsistency or any weakness as can be seen from the deliberations in chap. 145H8.2.1.2 and 146H8.2.1.3. • All operations conducted on the CC functional components lead to a consistent and meaningful whole. For the TOE-IC relevant SFRs the evidence is done within the scope of the CC evaluation of the TOE-IC resp. in the correlated ST. For the TOE-ES relevant SFRs the following deliberations are important. First, all operations on the chosen SFRs are done under consideration of the requirements in the Tachograph Card specification /TachAn1B/, Appendix 10 (Tachograph Card Generic Security Target ) and the JIL interpretations /JILDigTacho/, Annex B. Fur- thermore, the following holds: - Assignment and selection operations: All assignment and selection operations are conducted in such a way that they do not contradict each other and build an internally consistent security system which reflects the security requirements of the Tachograph Card system as specified in the Tachograph Card specification /TachAn1B/. Es- pecially, this concerns the defined access control policies AC_SFP and AC-PERS_SFP. - Iteration operations: The iteration of the functional components FDP_ACC.2 and FDP_ACF.1 are necessary to differentiate between the personalisation phase and the end-usage phase of the TOE and their phase-specific access control func- tionality. The iteration of the functional components for cryptographic support, MICARDO Tachograph Version 1.0 R1.0 127 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel FCS_CKM.2, FCS_CKM.3, FCS_CKM.4 and FCS_COP.1, are necessary to differentiate between the different cryptographic algorithms and mecha- nisms of the TOE. The iteration of the functional component FIA_AFL.1 is necessary to differ- entiate between the two different authentication mechanisms of the TOE. - Refinement operations: Not conducted. • Inconsistency between functional and assurance requirements can only arise if there are functional-assurance dependencies which are not met, a possibility which has been shown not to arise in chap. 147H8.2.2. Furthermore, as discussed in chap. 148H8.2.4, the chosen assurance components are adequate for the functionality of the TOE what underlines that the assurance requirements and security func- tional requirements support each other and that there are no inconsistencies be- tween these two groups of security requirements. MICARDO Tachograph Version 1.0 R1.0 128 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel 8.3 TOE Summary Specification Rationale According to the requirements of Common Criteria, /CC 2.2 Part1/ and /CC 2.2 Part3/, the TOE summary specification rationale demonstrates that the TOE security functions (TSFs) and assurance measures are suitable to meet the TOE security requirements. In detail, the following will be demonstrated: • the combination of the specified TOE´s IT security functions work together so as to satisfy the TOE security functional requirements • the strength of the TOE function claims made are valid, or assertions that such claims are unnecessary are valid • the claim that the stated assurance measures are compliant with the assurance requirements is justified 8.3.1 Security Functions Rationale The following section demonstrates that the set and combination of the defined TOE security functions (TSFs) is suitable to satisfy the identified TOE security functional requirements (SFRs). Furthermore, this section shows that each of the TSFs is related to at least one se- curity functional requirement. 8.3.1.1 Security Functional Requirements for the TOE-IC – TOE Security Func- tions The SFRs for the TOE-IC of chap. 149H5.1.1.1 are related to the TSFs of the TOE-IC defined in chap. 150H6.1.1. The mapping of the SFRs for the TOE-IC to the relevant TSFs is done within the CC evaluation of the IC resp. within the associated Security Target. 8.3.1.2 Security Functional Requirements for the TOE-ES – TOE Security Func- tions The SFRs for the TOE-ES of chap. 151H5.1.1.2 are related to the TSFs of the TOE-ES defined in chap. 152H6.1.2. The mapping of the SFRs for the TOE-ES to the relevant TSFs is done in the following. The tables below give an overview of which TSFs of the TOE-ES contribute to the satisfac- tion of the SFRs for the TOE-ES. MICARDO Tachograph Version 1.0 R1.0 129 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel SFR TOE Security Function FAU_ SAA. 1-1 FCO_ NRO. 1-1 FCS_ CKM. 1-1 FCS_ CKM. 2-1 FCS_ CKM. 2-2 FCS_ CKM. 2-3 FCS_ CKM. 3-1 FCS_ CKM. 3-2 FCS_ CKM. 3-3 FCS_ CKM. 3-4 FCS_ CKM. 3-5 FCS_ CKM. 4-1 F.ACS X (X) (X) X X X X X F.IA_KEY X X X F.IA_- PWD X F.DATA_- INT X F.EX_- CONF X F.EX_INT X F.RIP X F.FAIL_- PROT X F.SIDE_- CHAN F.SELF- TEST X F.GEN_- SES X X F.GEN_- DIGSIG X X F.VER_- DIGSIG X X X F.ENC X F.DEC X X SFR TOE Security Function FCS_ CKM. 4-2 FCS_ COP. 1-1 FCS_ COP. 1-2 FCS_ COP. 1-3 FCS_ COP. 1-4 FCS_ COP. 1-5 FDP_ ACC. 2-1 FDP_ ACC. 2-2 FDP_ ACF. 1-1 FDP_ ACF. 1-2 FDP_ DAU. 1-1 FDP_ ETC. 1-1 F.ACS (X) (X) (X) (X) (X) X X X X X F.IA_KEY F.IA_- PWD MICARDO Tachograph Version 1.0 R1.0 130 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel F.DATA_- INT F.EX_- CONF X X F.EX_INT X X F.RIP X F.FAIL_- PROT F.SIDE_- CHAN F.SELF- TEST F.GEN_- SES F.GEN_- DIGSIG X X X F.VER_- DIGSIG X X X F.ENC X F.DEC X SFR TOE Security Function FDP_ ETC. 1-2 FDP_ ITC. 1-1 FDP_ RIP. 1-1 FDP_ SDI. 2-1 FIA_ AFL. 1-1 FIA_ AFL. 1-2 FIA_ ATD. 1-1 FIA_ UAU. 1-1 FIA_ UAU. 3-1 FIA_ UAU. 4-1 FIA_ UID. 1-1 FIA_ USB. 1-1 F.ACS X X X X X F.IA_KEY X X X F.IA_- PWD X X F.DATA_- INT X F.EX_- CONF X F.EX_INT X F.RIP X F.FAIL_- PROT MICARDO Tachograph Version 1.0 R1.0 131 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel F.SIDE_- CHAN F.SELF- TEST F.GEN_- SES F.GEN_- DIGSIG X F.VER_- DIGSIG F.ENC F.DEC SFR TOE Security Function FMT FPR_ UNO. 1-1 FPR_ UNO. 1-2 FPR_ UNO. 1-3 FPT_ FLS. 1-1 FPT_ PHP. 3-1 FPT_ SEP. 1-1 FPT_ TDC. 1-1 FPT_ TST. 1-1 FPT_ ITC. 1-1 F.ACS Not appli- cable X F.IA_KEY X X X F.IA_- PWD X F.DATA_- INT F.EX_- CONF X X X F.EX_INT X X F.RIP F.FAIL_- PROT X F.SIDE_- CHAN X F.SELF- TEST X F.GEN_- SES X X F.GEN_- DIGSIG X MICARDO Tachograph Version 1.0 R1.0 132 / 139 ST-Lite Rationale 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel F.VER_- DIGSIG X F.ENC X F.DEC X X In the following, for each SFR of the TOE it will be explained why and how the TSFs listed in the preceding tables meet the respective SFR. The rationale here is presented in form of tables. The full rationale as given in the TOE´s Security Target is not intended to be published and hence not part of the ST-Lite. 8.3.2 Assurance Measures Rationale The assurance measures of the developer as mentioned in chap. 153H6.3 are considered to be suitable and sufficient to meet the CC assurance level EAL4 augmented by ADO_IGS.2, ADV_IMP.2, ATE_DPT.2 and AVA_VLA.4 as claimed in chap. 154H5.1.3. Especially the deliver- ables listed in chap. 155H6.3 are seen to be suitable and sufficient to document the fulfillment of the assurance requirements in detail. As the development and production process of the TOE is very complex and a great number of assurance measures are implemented by the developer, a detailed description of these measures beyond the information given in chap. 156H2.2 and 157H2.3 as well as a detailed mapping of the assurance measures to the assurance requirements is not in the scope of this ST. 8.3.3 TOE Security Functions – Mutual Support and Internal Consistency The detailed description and analysis of the TOE Security Functions in chap. 158H6.1 demon- strate how the defined functions work together and support each other. Furthermore, this description shows that no inconsistencies exist. The deliberations in chap. 159H8.3.1 support this result. Additionally, for the TSFs of the TOE-IC as defined in chap. 160H6.1.1 such analysis is done in the scope of the IC evaluation resp. within the correlated ST. 8.3.4 Strength of Functions The selected Strength of Functions level for the TOE´s security functions of SOF-high is con- sistent with the security objectives for the TOE, as the TOE is considered as a security prod- uct with critical security mechanisms which shall be resistant against attacks with high attack potential. MICARDO Tachograph Version 1.0 R1.0 133 / 139 ST-Lite Reference 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Reference I Bibliography /CC 2.2 Part1/ Title: Common Criteria for Information Technology Security Evalua- tion, Part 1: Introduction and General Model Identification: CCIMB-2004-01-001 Version: Version 2.2 Revision 256 Date: January 2004 Author: CC Project Sponsoring Organisations CSE, SCSSI, BSI, NLNCSA, CESG, NIST, NSA /CC 2.2 Part2/ Title: Common Criteria for Information Technology Security Evalua- tion, Part 2: Security Functional Requirements Identification: CCIMB-2004-01-002 Version: Version 2.2 Revision 256 Date: January 2004 Author: CC Project Sponsoring Organisations CSE, SCSSI, BSI, NLNCSA, CESG, NIST, NSA /CC 2.2 Part3/ Title: Common Criteria for Information Technology Security Evalua- tion, Part 3: Security Assurance Requirements Identification: CCIMB-2004-01-003 Version: Version 2.2 Revision 256 Date: January 2004 Author: CC Project Sponsoring Organisations CSE, SCSSI, BSI, NLNCSA, CESG, NIST, NSA /CEM 0.6 Part1/ Title: Common Methodology for Information Technology Security Evaluation, Part 1: Introduction and General Model Identification: CEM99/045 Version: Draft 0.6 Date: Jan. 1997 Author: CC Project Sponsoring Organisations CSE, SCSSI, BSI, NLNCSA, CESG, NIST, NSA /CEM 2.2 Part2/ Title: Common Methodology for Information Technology Security Evaluation, Part 2: Evaluation Methodology Identification: CCIMB-2004-01-004 Version: Version 2.2 Revision 256 Date: January 2004 Author: CC Project Sponsoring Organisations CSE, SCSSI, BSI, NLNCSA, CESG, NIST, NSA MICARDO Tachograph Version 1.0 R1.0 134 / 139 ST-Lite Reference 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel /AIS32/ Title: Übernahme international abgestimmter CC Interpretationen Identification: AIS 32 Date: 02.07.2001 Publisher: Bundesamt für Sicherheit in der Informationstechnik /JILDigTacho/ Title: JIL Security Evaluation and Certification of Digital Tachographs Version: Version 1.12 Date: June 2003 Author: JIL Working Group (BSI, CES, DCSSI, NLNCSA) /PP9806/ Title: Protection Profile - Smartcard Integrated Circuit Identification: Registered at the French Certification Body (DCSSI) under the number PP/9806 Version: Version 2.0 Date: Sept. 1998 Author: Motorola Semiconductors, Philips Semiconductors, Service Central de la Securite des Systemes d´Information, Siemens AG Semiconductors, ST Microelectronics, Texas-Instruments Semiconductors /PP9911/ Title: Protection Profile - Smartcard Integrated Circuit with Embedded Software Identification: Registered at the French Certification Body (DCSSI) under the number PP/9911 Version: Version 2.0 Date: June 1999 Author: Atmel Smart Card ICs, Bull-SC&T, De la Rue – Card Systems, Eurosmart, Gemplus, Giesecke & Devrient GmbH, Hitachi Europe Ltd, Infineon Technologies AG, Microelectronica Es- pana, Motorola SPS, NEC Electronics, Oberthur Smart Card, ODS, ORGA Kartensysteme GmbH, Philips Semiconductors Hamburg, Schlumberger Cards Devision, Service Central de la Securite des Systemes d´Information, ST Microelectronics /BSI-PP-0002/ Title: Smartcard IC Platform Protection Profile Identification: Registered and Certified by Bundesamt für Sicherheit in der In- formationstechnik (BSI) under the reference BSI-PP-0002 Version: Version 1.0 Date: July 2001 Author: Atmel Smart Card ICs, Hitachi Europe Ltd, Infineon Technolo- gies AG, Philips Semiconductors MICARDO Tachograph Version 1.0 R1.0 135 / 139 ST-Lite Reference 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel /CompPP9806-BSIPP0002/ Title: Assessment on the Substitution of an Evaluation based on PP/9806 by an Evaluation based on BSI-PP-0002-2001 Version: Version 1.1 Date: May 2002 Publisher: Bundesamt für Sicherheit in der Informationstechnik (BSI) /DS-ICPhilips/ Title: Data Sheet: SmartMX – P5CC036 Secure Smart Card Control- ler Version: Revision 3.0 Date: Sept. 21st 2004 Publisher: Philips Semiconductors GmbH /IS-ICPhilips/ Title: Instruction Set SmartMX-Family, Secure Smart Card Controller, Objective Specification Version: Revision 1.0 Date: May 9th 2003 Publisher: Philips Semiconductors GmbH /UG-ICPhilips/ Title: Guidance, Delivery and Operation Manual: Evaluation of the Philips P5CC036V1D Secure Smart Card Controller Version: Revision 1.0 Date: March 18th 2005 Publisher: Philips Semiconductors GmbH /UG-Lib/ Title: User Guidance: Secured Crypto Library on the P5CC036V1D Version: Revision 2.0 Date: Nov. 23rd 2005 Publisher: Philips Semiconductors GmbH /UG-Lib-RND/ Title: User Guidance: Crypto Library on SmartMX – Pseudo Random Number Generator & Chi-Squared Test Library Version: Revision 3.0 Date: Nov. 23rd 2005 Publisher: Philips Semiconductors GmbH /UG-Lib-DES/ Title: User Guidance: Crypto Library on SmartMX – Secured DES Li- brary Version: Revision 2.0 Date: Nov. 23rd 2005 Publisher: Philips Semiconductors GmbH MICARDO Tachograph Version 1.0 R1.0 136 / 139 ST-Lite Reference 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel /UG-Lib-SHA/ Title: User Guidance: Crypto Library on SmartMX – SHA-1 Library Version: Revision 3.0 Date: Nov. 23rd 2005 Publisher: Philips Semiconductors GmbH /UG-Lib-RSA/ Title: User Guidance: Crypto Library on SmartMX – Secured RSA Li- brary Version: Revision 3.0 Date: Nov. 23rd 2005 Publisher: Philips Semiconductors GmbH /ST-ICPhilips/ Title: Security Target - Evaluation of the Philips P5CC036V1D Se- cure Smart Card Controller Identification: BSI-DSZ-CC-0293 Version: Version 1.0 Date: March 18th 2005 Publisher: Philips Semiconductors GmbH /ST-ICPhilips+Lib/ Title: Security Target Lite - Evaluation of the Secured Crypto Library on the P5CC036V1D Identification: BSI-DSZ-CC-0368 Version: Version 2.2.0 Date: Jan. 30th 2006 Publisher: Philips Semiconductors GmbH /ETRLite-ICPhilips/ Titel: BSI-DSZ-CC-0293: ETR-lite for composition according to AIS 36 Version: Version 1.0 Date: July 6th 2005 Publisher: T-Systems GEI GmbH /ETRLite-ICPhilips+Lib/ Titel: BSI-DSZ-CC-0368: ETR-lite for composition according to AIS 36 Version: Version 1.20 Date: Feb. 8th 2006 Publisher: T-Systems GEI GmbH /ConfListPhilips/ Title: Customer specific Appendix of the Configuration List for com- posite evaluation with ORGA (P5CC036V1D) MICARDO Tachograph Version 1.0 R1.0 137 / 139 ST-Lite Reference 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Version: Version 1.0 Publisher: Philips Semiconductors GmbH /TachAn1B/ Title: Annex 1B of Commission Regulation (EC) No.1360/2002 on re- cording equipment in road transport: Requirements for Con- struction, Testing, Installation and Inspection (in: Official Journal of the European Communities, L 207 / 1 ff.) Date: 05.08.2002 Publisher: Commission of the European Communities /ISO9796-2/ Title: Information Technology – Security Techniques – Digital Signa- ture Schemes Giving Message Recovery – Part 2: Mechanisms Using a Hash Function Identification: ISO/IEC 9796-2 Version: First Edition Date: 1997 Publisher: ISO / IEC /ISO9798-3/ Title: Information Technology – Security Techniques – Entity Authen- tication Mechanisms – Part 3: Entity Authentication Using a public key algorithm Identification: ISO/IEC 9798-3 Version: Second Edition Date: 1998 Publisher: ISO / IEC /ISO 7816-4/ Title: Integrated circuit(s) cards with contacts. Part 4: Interindustry commands for interchange Identification: ISO/IEC 7816-4 Version: First edition Date: September 1.1995 Publisher: International Organization for Standardization/International Electrotechnical Commission /ISO 7816-8/ Title: Integrated circuit(s) cards with contacts. Part 8: Interindustry commands for interchange Identification: ISO/IEC FDIS 7816-8 Date: June 1998 Publisher: International Organization for Standardization/International Electrotechnical Commission /ISO 7816-9/ MICARDO Tachograph Version 1.0 R1.0 138 / 139 ST-Lite Reference 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel Title: Integrated circuit(s) cards with contacts. Part 9: Enhanced inter- industry commands Identification: ISO/IEC 7816-9 Version: First Edition Date: Sept. 2000 Publisher: International Organization for Standardization/International Electrotechnical Commission /SHA-1/ Title: Secure Hash Standard Identification: FIPS Publication 180-1 Date: April 1995 Publisher: National Institute of Standards and Technology (NIST) /TDES/ Title: Data Encryption Standard Identification: FIPS Publication 46-3 Date: Draft 1999 Publisher: National Institute of Standards and Technology (NIST) /TDES-OP/ Title: Triple Data Encryption Algorithm Modes of Operation Identification: ANSI X9.52 Date: 1998 Publisher: American National Standards Institute /PKCS1/ Title: RSA Encryption Standard Identification: PKCS#1 Version: Version 2.0 Date: Oct. 1998 Publisher: RSA Laboratories II Summary of abbreviations A.x Assumption AC Access Condition AID Application Identifier ALW Always AM Access Mode AR Access Rule AS Application Software ATR Answer To Reset AUT Key Based Authentication BS Basic Software CC Common Criteria DES Data Encryption Standard DF Dedicated File MICARDO Tachograph Version 1.0 R1.0 139 / 139 ST-Lite Reference 3Tachograph.CSL.0003 V1.00 21 June 2006 Sagem ORGA GmbH Dr. Susanne Pingel DFA Differential Fault Analysis DPA Differential Power Analysis EAL Evaluation Assurance Level EF Elementary File ES Embedded Software IC Integrated Circuit IFD Interface Device ITSEC Information Technology Security Evaluation Criteria JIL Joint Interpretation Library MAC Message Authentication Code MF Master File O.x Security Objective OS Operating System PAR Partial Access Rule P.x Organisational Security Policy PIN Personal Identification Number PP Protection Profile PW Password PWD Password Based Authentication RSA Rivest-Shamir-Adleman Algorithm SAR Security Assurance Requirement SFP Security Function Policy SFR Security Functional Requirement SM Secure Messaging SOF Strength of Functions SPA Simple Power Analysis SPM TOE Security Policy Model SSC Send Sequence Counter ST Security Target T.x Threat TOE Target of Evaluation TSC TSF Scope of Control TSF TOE Security Function TSP TOE Security Policy VU Vehicle Unit III Glossary For explanation of technical terms refer to the following documents: /PP9911/, Annex A /BSI-PP-0002/, Chap. 8.7 /ST-ICPhilips+Lib/, Glossary /TachAn1B/, main body, Chap. I Definitions /TachAn1B/, Appendix 10, Tachograph Card Generic Security Target, Chap. 2