Document version 0.3 as of 2015-10-13 Hans-Ulrich Buchmüller Security Target Lite M7892 B11 Recertification Including optional Software Libraries RSA - EC - SHA-2 - Toolbox Common Criteria CCv3.1 EAL6 augmented (EAL6+) Resistance to attackers with HIGH attack potential Chipcard & Security M7892 B11 Security Target Lite Public Security Target Lite 2 2015-10-13 Edition 2015-10-13 Published by Infineon Technologies AG, 81726 Munich, Germany. © 2015 Infineon Technologies AG All Rights Reserved. Legal Disclaimer The information given in this document shall in no event be regarded as a guarantee of conditions or characteristics.With respect to any examples or hints given herein, any typical values stated herein and/or any information regardingthe application of the device, Infineon Technologies hereby disclaimsany and all warranties and liabilitiesof any kind, includingwithoutlimitation,warrantiesof non-infringement of intellectual property rights of any third party. Information For further information on technology, delivery terms and conditions and prices,pleasecontactthe nearest Infineon Technologies Office(www.infineon.com). Warnings Due to technical requirements, components may contain dangerous substances.For information on the types in question, pleasecontact the nearest Infineon Technologies Office. Infineon Technologies components may be used in life-supportdevices or systems only with the express written approval of Infineon Technologies, if a failureof such components can reasonably beexpected to causethe failureof that life- supportdevice or system or to affect the safety or effectiveness of that device or system. Life support devices or systems are intended to be implanted in the human body or to supportand/or maintain and sustain and/or protecthuman life. If they fail,itis reasonableto assumethat the health of the user or other persons may be endangered. M7892 B11 Security Target Lite Public Security Target Lite 3 2015-10-13 Miscellaneous The term "Mifare" in this document is only used as an indicator of product compatibility to the correspondingestablished technology. This applies to the entire document wherever the term is used. Trademarks of Infineon Technologies AG AURIX, C166, CROSSAVE, CanPAK, CIPOS, CoolGaN, CoolMOS, CoolSET, CoolSiC, CORECONTROL, DAVE, DI-POL, DrBLADE, EasyPIM, EconoBRIDGE, EconoDUAL, EconoPACK, EconoPIM, EiceDRIVER, eupec, FCOS, HITFET, HybridPACK, ISOFACE, IsoPACK, MIPAQ, ModSTACK, my-d, NovalithIC, OmniTune, OPTIGA, OptiMOS, ORIGA, POWERCODE, PRIMARION, PrimePACK, PrimeSTACK, PROFET, PRO-SIL, RASIC, REAL3, ReverSave, SatRIC, SIEGET, SIPMOS, SmartLEWIS, SOLID FLASH, SPOC, TEMPFET, thinQ!, TRENCHSTOP, TriCore. Trademarks as of January,2015. M7892 B11 Security Target Lite Public Security Target Lite 4 2015-10-13 RevisionHistory Date Version Change Description 2015-08-18 0.1 Initial version 2015-09-07 0.2 Editorial changes based on 0782-V2_OR_All_150902_v1 2015-10-13 0.3 Update of literaturetable, new release of the HRM version M7892 B11 Security Target Lite Public Security Target Lite 5 2015-10-13 Table of Contents 1 Security Target Introduction (ASE_INT) ...........................................................................................................................7 1.1 Security Target and Target of Evaluation Reference...............................................................................................7 1.2 Remarks to the Target of Evaluation (TOE) ..............................................................................................................8 1.3 Target of Evaluation overview .................................................................................................................................14 2 Target of Evaluation Description....................................................................................................................................18 2.1 TOE Definition.............................................................................................................................................................18 2.2 Scope of the TOE ........................................................................................................................................................21 2.2.1 Hardware of the TOE .....................................................................................................................................22 2.2.2 Firmware and software of the TOE .............................................................................................................23 2.2.3 Interfaces of the TOE.....................................................................................................................................25 2.2.4 Guidance documentation.............................................................................................................................26 2.2.5 Forms of delivery............................................................................................................................................26 2.2.6 Production sites..............................................................................................................................................27 3 Conformance Claims (ASE_CCL) .....................................................................................................................................28 3.1 CC Conformance Claim..............................................................................................................................................28 3.2 PP Claim........................................................................................................................................................................28 3.3 Package Claim.............................................................................................................................................................28 3.4 Conformance Rationale.............................................................................................................................................29 3.5 Application Notes .......................................................................................................................................................30 4 Security Problem Definition (ASE_SPD) ........................................................................................................................31 4.1 Threats..........................................................................................................................................................................31 4.1.1 Additional Threat due to TOE specific Functionality................................................................................31 4.1.2 Assets regarding the Threats........................................................................................................................32 4.2 Organizational Security Policies...............................................................................................................................33 4.2.1 Augmented Organizational Security Policy...............................................................................................33 4.3 Assumptions................................................................................................................................................................35 4.3.1 Augmented Assumptions..............................................................................................................................36 5 Security objectives (ASE_OBJ) ........................................................................................................................................37 5.1 Security objectives for the TOE ................................................................................................................................37 5.2 Security Objectives for the development and operational Environment ........................................................38 5.2.1 Clarification of “Usage of Hardware Platform (OE.Plat-Appl)”..............................................................39 5.2.2 Clarification of “Treatment of User Data (OE.Resp-Appl)”.....................................................................39 5.2.3 Clarification of “Protection during Composite product manufacturing (OE.Process -Sec-IC)”.......40 5.3 Security Objectives Rationale...................................................................................................................................40 6 Extended Component Definition (ASE_ECD) ...............................................................................................................42 6.1 Component “Subset TOE security testing (FPT_TST)” .........................................................................................42 6.2 Definition of FPT_TST.2 .............................................................................................................................................42 6.3 TSF self test (FPT_TST) ...............................................................................................................................................43 6.4 Family “Generation of Random Numbers (FCS_RNG)” .......................................................................................44 6.5 Definition of FCS_RNG.1............................................................................................................................................44 7 Security Requirements (ASE_REQ) ................................................................................................................................46 7.1 TOE Security Functional Requirements ..................................................................................................................46 7.1.1 Extended Components FCS_RNG.1 and FAU_SAS.1 ................................................................................47 M7892 B11 Security Target Lite Public Security Target Lite 6 2015-10-13 7.1.1.1 FCS_RNG................................................................................................................................................47 7.1.1.2 FAU_SAS ................................................................................................................................................48 7.1.2 Subset of TOE testing ....................................................................................................................................49 7.1.3 Memory access control.................................................................................................................................49 7.1.4 Support of Cipher Schemes ..........................................................................................................................53 7.1.4.1 Preface regarding Security Level related to Cryptography ..........................................................53 7.1.4.2 Triple-DES Operation...........................................................................................................................55 7.1.4.3 AES Operation.......................................................................................................................................56 7.1.4.4 Rivest-Shamir-Adleman (RSA) operation.........................................................................................57 7.1.4.5 Rivest-Shamir-Adleman (RSA) key generation................................................................................58 7.1.4.6 Generally with regard to Elliptic Curves ..........................................................................................58 7.1.4.7 Elliptic Curve DSA (ECDSA) operation...............................................................................................59 7.1.4.10 SHA-2 Operation ..................................................................................................................................62 7.1.5 Data Integrity..................................................................................................................................................63 7.2 TOE Security Assurance Requirements...................................................................................................................63 7.2.1 Refinements ....................................................................................................................................................65 7.2.1.1 Development (ADV).............................................................................................................................65 7.2.1.2 Life-cycle Support (ALC) ......................................................................................................................67 7.2.1.3 Tests (ATE).............................................................................................................................................68 7.3 Security Requirements Rationale............................................................................................................................68 7.3.1 Rationale for the Security Functional Requirements...............................................................................68 7.3.1.1 Dependencies of Security Functional Requirements ....................................................................72 7.3.2 Rationale of the Assurance Requirements ................................................................................................75 7.3.2.1 ALC_FLR.1 Basic Flaw Remediation..................................................................................................75 8 TOE Summary Specification (ASE_TSS) .........................................................................................................................76 8.1 SF_DPM: Device Phase Management .....................................................................................................................76 8.2 SF_PS: Protection against Snooping........................................................................................................................77 8.3 SF_PMA: Protection against Modifying Attacks....................................................................................................78 8.4 SF_PLA: Protection against Logical Attacks ...........................................................................................................80 8.5 SF_CS: Cryptographic Support..................................................................................................................................80 8.5.1 3DES..................................................................................................................................................................80 8.5.2 AES ....................................................................................................................................................................81 8.5.3 RSA....................................................................................................................................................................81 8.5.4 Elliptic Curves EC............................................................................................................................................82 8.5.5 SHA-2 ................................................................................................................................................................84 8.5.6 Toolbox Library...............................................................................................................................................84 8.5.7 Base Library.....................................................................................................................................................84 8.5.8 PTRNG respectively TRNG ............................................................................................................................85 8.6 Assignment of Security Functional Requirements to TOE’s Security Functionality........................................85 8.7 Security Requirements are internally Consistent .................................................................................................87 9 Referenced Literature......................................................................................................................................................88 10 Appendix.............................................................................................................................................................................90 11 List of Abbreviations.........................................................................................................................................................92 12 Glossary..............................................................................................................................................................................94 M7892 B11 Security Target Lite Public Security Target Lite 7 2015-10-13 1 Security Target Introduction (ASE_INT) 1.1 Security Target and Target of Evaluation Reference The title of this document is Security Target Lite for Common Criteria EAL6 augmented (EAL6+) M7892 B11 including optional Software Libraries RSA- EC - SHA-2 - Toolbox and comprises the Infineon Technologies Security Controller M7892 B11 with three specific IC dedicated alternativesoftware packages and optional RSA v1.02.013, EC v1.02.013, SHA-2 v1.01 and Toolbox v1.02.013 libraries. The target of evaluation (TOE) M7892 B11 is described in the following.This confidential Security Targethas the revision 0.3 and is dated 2015-10-13. The Target of Evaluation (TOE) is the Infineon Security Controller M7892 B11 with optional RSA2048/4096 v1.02.013,EC v1.02.013, SHA-2 v1.01 and Toolbox v1.02.013 librariesand with specific IC dedicated software (firmware). The design step is B11. The Security Target is based on the Protection ProfilePP-0035 “Smartcard IC PlatformProtection Profile”[1] as publicly availablefor download at https://www.bsi.bund.de. The Protection Profileand the Security Target arebuiltin compliancewith Common Criteria v3.1. The ST takes into accountall relevantcurrent final interpretations. This TOE is build fromthe equal design sources regardingfirmware,hardware and optional software as already certified in the process BSI-DSZ-CC-0782-2012-MA-01. This Security Target is an update of the confidential Security Target of the forerunner process BSI-DSZ-CC-0782-2012-MA- 01 with a version update of the user guidance.The update is required due to security relevant recommendations in the user guidance. M7892 B11 Security Target Lite Public Security Target Lite 8 2015-10-13 Table 1: Identification Version Date Registration Confidential Security Target 0.3 2015-10-13 M7892 B11 Target of Evaluation B11 with FW-Identifier 78.015.14.0 or FW-Identifier 78.015.14.1 or FW-Identifier 78.015.14.2 and optional SW: RSA2048 v1.02.013 (optional) RSA4096 v1.02.013 (optional) EC v1.02.013 (optional) SHA-2 v1.01 (optional) Toolbox v1.02.013 (optional) and Guidancedocumentation Guidance Documentation The guidancedocumentation is listed in chapter 9. Protection Profile 1.0 2007-06-15 Security IC PlatformProtection ProfilePP0035 Common Criteria 3.1 Revision 4 2012-09 Common Criteria for Information Technology Security Evaluation Part1: Introduction and general model CCMB-2012-09-001 Part2: Security functional requirements CCMB-2012-09-002 Part3: Security AssuranceComponents CCMB-2012-09-003 (1) Mifareis only used as an indicator of product compatibility to the respective technology. This holds for the entire document, whenever the term Mifareis used. A customer can identify the TOE and its configuration usingtheNon-ISO ATR in combination with firmware functions. The TOE answers the Non-ISO-ATR with the Generic Chip Identification Mode(GCIM). The GCIM outputs a chip identifier byte, design step, firmware identifier version and further configuration information.The identification data and configuration details aredescribed in the confidential Security Target [10] and in the Family HardwareReference Manual [6]. 1.2 Remarks to the Target of Evaluation (TOE) This TOE is represented by various products,differentiated by various configuration possibilities and order options. Despite these configuration possibilities,all products arederived from the equal hardware design results,the M7892 B11. The GCIM mode is explained and detailed in the user guidancedocument hardwarereference manual HRM. M7892 B11 Security Target Lite Public Security Target Lite 9 2015-10-13 All product derivatives areidentical in moduledesign,basic layoutand footprint,but are adapted to connect to different types of antennas or to a contact based interface only.Therefore, the TOE is represented and made out of different mask sets with followingTOE internal and security irrelevantdifferences: The main difference between the mask sets of the TOE is to implement different input capacitances in theanaloguepart of the radio frequency interface (RFI). One of the inputcapacitances iszero and marks a derivativedeemed for contact based communication only.This differentiation in the input capacitances allows theconnection to a wider range of various antenna types, or respectively,to a contact based interface only.Note that external antennas or interfaces are not partof the TOE. The derivatives without availableinputcapacitancearedeemed for contact based communication only. A further additional mask settakes one of the previous mask sets and adds an additional mask on top of the very last mask of the TOE. This lastmask is deemed to produce a metal layer,justrerouting the pads for a special packagetype. This additional top metal layer is comparableto an outer package, which would simply reconnect the TOE pads in a different way. This lastreroutinglayer does not change the function of the TOE itself and is,in addition,subjectof the design requirements of the users.This lastlayer is flexiblein design,namingand is of course,not relevantfor the securi ty of the TOE. It is comparableto the scenario where someone takes a piece of wire and reconnects the pads of a smartcard in a different way. For logistical reasonsand dueto user demands the TOE products produced with this fifth mask set output a different design step C1x, where “x” represents a number from 1 up to 9. The number depends on the design variants of the additional top metal layer and of the package,which can be customer specific. To each of the capacitances related mask sets,an individual valueis assigned,which is partof the data output of the Generic Chip Identification Mode (GCIM). This number is located in the GCIM and allows clearly differentiating between the mask sets related to the different input capacitances. In addition, users can identify derivatives produced with the additional top metal layer by the design step output “C1x” as described above. On those “C1x” derivatives the GCIM remains unchanged and allows the identification of which of the other mask sets was used to produce the TOE wi th the additional top metal layer.Therefore, the GCIM design step output C11 up to C19 of this extra top metal layer TOE products correspond always to the TOE silicon design step B11. Thereby, the clear identification of the silicon design step is given. There are no other differences between the mask sets the TOE is produced with. Details areexplained in the user guidancehardwarereference manual HRM [6] and the Errata Sheet [15]. The M7892 B11 product allows for a maximum of configuration possibilities followingthemarket needs. For example, a M7892 B11 product can come in one project with the fully availableSOLID FLASH™ NVM 1 or in another project with any other SOLID FLASH™ NVM -sizebelow the physical implementation size,or with a different RAM size. And more, the user has the free choice,whether he needs the symmetric co-processor SCP, or the asymmetric co-processor Crypto2304T,or both, or none of them. In addition,the user decides, whether the TOE comes with a free combination of software libraries 1 SOLID FLASH™ NVMis an InfineonTrade Mark and stands for theInfineon EEPROMworking as Flash memory. M7892 B11 Security Target Lite Public Security Target Lite 10 2015-10-13 or without any. And, to be even more flexible,various interfaceoptions can bechosen as well. To sum up the major selections,the user defines by his order:  the availablememory sizes of the SOLID FLASH™ NVM and RAM. Note that there is no user availableROMon the TOE.  the availability of the cryptographic coprocessors,  the availability and free combinations of the cryptographic libraries,  the availability of the Flash Loader for availableinterfaces likeISO-7816,contactless ISO-14443  the availability of various interfaceoptions,and  the possibility to tailor the product by blockingon his own premises. The degree of freedom of the chip configuration is predefined by Infineon Technologies AG and made availablevia the order tool. Beside fix TOE configurations,which can beordered as usual,this TOEimplements optiona lly the so called Bill-Per-Use (BPU) ability.This solution enables our customer to tailor theproduct on his own to the required configuration – project by project. By that BPU allows for significantreduction of logistic costatall participatingparties and serves for acceleration of delivery of tailored productto the end-user. The blockinginformation can be modified by the users applyingspecificAPDUs.Once final locking isdone,further modifications aredisabled. The BPU software partis only present on predefined products, which have been ordered with the BPU option. In all other cases this softwareis not present on the product. More details can beobtained in the confidential Security Target [10]. In addition,after strong and successful authentication,the Flash Loader firmware partallows the download of user software, or justparts of it, to the SOLID FLASH™ NVM. By this the user is free to decide:  whether Infineon downloads (flashes) theuser software entirely duringthe TOE production phase,  or if this is done by the user himself after Infineon has delivered the TOE without user software,  or Infineon downloaded only parts of the user software and the user completes his softwareat his own premises. If Infineon is required to download the user software or parts of it, the user is of course required to provideInfineon the code deemed for the download,prior production of the TOE. This user software transfer to Infineon is be done by a secure channel,of coursebeing also partof this certificate. Therefore, the user is entirely flexiblein his process,regardlesswhether he intends to flash his codeentirely on his own, or sends his complete code or justparts of it to Infineon for high parallel flashingduringproduction. After the flashing steps have been completed, the Flash Loader firmwareis permanently deactivated. A reactivation is then no more possible. Beside all configuration possibilities,itis self-evidentthat Of course,exclusively all security relevantsettings are contained in the IFX-only part. The Flash Loader BPU software does not access and has no access to the IFX-only part. Once the user blockingby applyingthe APDU has been finalized,the configuration pageis no more accessiblefor changes. After the final deactivation of the Flash Loader the product is permanently fixed regardingits configurations and M7892 B11 Security Target Lite Public Security Target Lite 11 2015-10-13 software. A reactivation of the Flash Loader is not possible.At the next start-up, the STS apply the settings, and, if called, a RMS-function can output the finally made chip configuration for verification and information purposes. The entire configuration storagearea is protected againstmanipulation,perturbation and falseaccess.Note that the IFX- only part of the configuration pageis already accessprotected prior delivery to the user and the TOE leaves the Infineon Technology premises only locked into User Mode. Beside the various TOEconfigurations further possibilities of how the user inputs his softwareon the TOE, i.e. the operating system and applications,arein place.This provides a maximumof flexibility for the entire process of how users keep and manage their data. An overview is given in the followingtable: Table 2: Options to implement user software at Infineon production premises 1. The user or/and a subcontractor downloads the software into the SOLID FLASH™ NVM on his own. Infineon Technologies has not received user software and there are no user data in the ROM. The Flash Loader can be activated or reactivated by the user or subcontractor to download his software in the SOLID FLASH™ NVM. 2 The user provides softwarefor the download into the SOLID FLASH™ NVM to Infineon Technologies AG. The software is downloaded to the SOLID FLASH™ NVM duringchip production.I.e. there are no user data in the ROM. There is no Flash Loader present. 3 The user provides softwarefor the download into the SOLID FLASH™ NVM to Infineon Technologies AG. The software is downloaded to the SOLID FLASH™ NVM duringchip production.I.e. there are no user data in the ROM. The Flash Loader is blocked afterwards but can be activated or reactivated by the user or subcontractor to download his softwarein the SOLID FLASH™ NVM. Precondition is thatthe user has provided an own reactivation procedurein software prior chip production to Infineon Technologies AG. For the cases with Flash Loader on board and whenever the user has finalized his SW-download,the user is obligated to lock the Flash Loader.The final lockingof the FL results in a permanent deactivation of the Flash Loader. This means that once being in the locked status,the Flash Loader cannot be reactivated anymore. The followinglistingcontains a selection of configuration possibilities.Moreinformation is given in the confidential Security Target [10], Note that within those limitations theTOE configurations can vary under only one equal IC-hardware and one development code – the M7892 B11 – and without impact on security. Note also thatfollowingconfiguration possibilities arevalid unchanged throughout all differentmask sets. M7892 B11 Security Target Lite Public Security Target Lite 12 2015-10-13 Table 3: Configuration ranges and blocking options for the user Module / Feature (User view) Max-Value (User view) Min-Value (User view) Blocking possible Blocking Step Memories SOLID FLASH™ NVM Max. 404 kBytes Min. 0 kBytes Yes 1 kBytes ROM Not available Not available No None RAM for the user 8 kBytes 1 kBytes Yes 1kBytes Modules Crypto2304T Available Not available Yes On/off SCP Available Not available Yes On/off Interfaces ISO 7816-3 slave Available Not available Yes On/off RFI – ISO 14443 generally Available Not available Yes On/off ISO 14443 Type A card mode Available Not available By order only None ISO 14443 Type B card mode Available Not available By order only None ISO 18092 NFC passivemode Available Not available By order only None Mifarehardware supportfor card mode Available Not available By order only None SW supportfor Mifare compatible4k cards (1) Available Not available By order only None SW supportfor Mifare compatible1k cards (1) Available Not available By order only None (1) Mifareemulation All possibleTOE configurations equal and/or within the below specified ranges arecovered by the certificate. Note that there is no user availableon-chip ROMmodule anymore. The user software and data are now located in a dedicated and protected partof the SOLID FLASH™ NVM. The long lifestorageendurance, the automatic management of often used memory pages, together with the means for error detection and correction serves at leastfor equal or even higher reliability and endurance,compared to a dedicated ROM. Beside the above listed flexibleranges,the user guidancecontains a number of predefined configurations for those customers not making useof the BPU option. All of these configurations belongto the TOE as well and are of course made of the equal hardwareand areinsidethe above declared ranges. M7892 B11 Security Target Lite Public Security Target Lite 13 2015-10-13 Today’s predefined configurations of the TOE are listed in the hardwarereference manual [6].These predefined products come with the most requested configurations and allowto produce volumes on stock in order to simplify logistic processes. Accordingto the BPU option, a non limited number of configurations of the TOE may occur in the field. The number of various configurationsdepends on the user and purchasecontractonly. Note that the TOE answers to the Non-ISO-ATR with the Generic Chip Identification Mode(GCIM) answer. This GCIM outputs a coded clear identifier for the type of the GCIM, the platform identifier,the design step and further configuration information.The hardwarereference manual [6],being part of the user guidance,enables then for the clear interpretation of the read out GCIM data. These GCIM data enablethe user for clear identification of the TOE and also of one of the different mask sets and therewith for checking the validity of the certificate. In addition,a dedicated RMS function allows readingoutthe present configuration in detail.Again,together with hardwarereference manual [6], this allows for clear identification of a productand its configuration. All these steps for gathering identification and detailed configuration information can bedone by the user himself, without involvingInfineon Technologies AG. The TOE consists of the hardwarepart, the firmware parts and the optional software parts. The software parts are differentiated into: the cryptographic libraries RSA 1 ,EC 2 and SHA-2 3 and the supportinglibrariesToolbox and Base. RSA, EC, SHA-2 and Toolbox provide certain functionality via an API to the Smartcard Embedded Software. The Base Library is only used internally by the RSA, EC and Toolbox libraries and has no user interface. If none the three libraries RSA, EC and Toolbox is delivered,also the Base Library is noton board.The SHA-2 library does not use the Base Library. The firmware parts arethe RMS library,the ServiceAlgorithm Minimal (SAM), the STS firmwarefor test purpose(see chapter 2.2.2), providingsome functionality via an API to the Smartcard Embedded Software, the Flash Loader for downloadinguser software to the SOLID FLASH™ NVM and the Mifare compatiblesoftware interface.The STS is implemented in a separated Test-ROM being part of the TOE. The Smartcard Embedded Software, i.e. the operating system and applicationsarenotpart of the TOE. The TOE can be delivered including - in free combinations - or not includingany of the functionality of the cryptographic libraries EC,RSA, SHA-2 and the supportingToolbox library.If RSA or EC or Toolbox is delivered, automatically theBase Library is partof the shipment too. If the user decides not to use one or all of the crypto library(s),the specific library(s) is (are) notdelivered to the user and the accompanying“Additional Specific Security Functionality (O.Add-Functions)”Rivest-Shamir-Adleman (RSA) and/ or EC and/or SHA-2 is/arenot provided by the TOE. 1 Rivest-Shamir-Adlemanasymmetriccryptographic algorithm 2 The Elliptic CurveCryptography is abbreviatedwith EC only in the further,in orderto avoid conflicts withtheabbreviationfor theError Correction Code ECC. 3 SHA Secure Hash Algorithm M7892 B11 Security Target Lite Public Security Target Lite 14 2015-10-13 The Toolbox library provides theuser optionally basicarithmetic and modular arithmetic operations,in order to support user software development usinglonginteger operations.These basic arithmetic operations do not provideany security functionality,implement no security mechanism,and do not proved additional specific security functionality - as defined for the cryptographic libraries. The user developed software usingthe Toolbox basic operations isnotpartof the TOE. The Base Library provides the low level interface to the asymmetric cryptographic coprocessorand has no user available interface. The baselibrary does not provideany security functionality,implements no security mechanism, and does not provideadditional specificsecurity functionality. Deselecting one of the libraries does notincludethe code implementing functionality,which the user decided not to use. Not includingthecode of the deselected functionality has no impactof any other security policy of the TOE; itis exactly equivalentto the situation where the user decides justnot to use the functionality. The RSA, EC, SHA-2 and Toolbox libraries can beloaded,together with the Smartcard Embedded software, into the SOLID FLASH™ NVM. This holds also for the Base Library,if the RSA, EC or Toolbox or combinations hereof is/arepartof the shipment. All other Smartcard Embedded Software does not belong to the TOE and is notsubject of the evaluation. 1.3 Target of Evaluation overview The TOE comprises the Infineon Technologies Dual InterfaceSecurity Controller M7892 B11 with specific IC dedicated software and optional RSA, EC, SHA-2 and Toolbox libraries. The TOE is a member of the Infineon Technologies AG high security controller family SLE70 meeting the highest requirements in terms of performance and security.A summary product description is given in this Security Target Lite (ST). The SLE70 family provides a common architecture upon which specific products can betailored for markets rangingfrom basic security applications(SLE76) up to high security and contactless applications (SLE78). The TOE is intended to be used in any applicationsand devices with highest security requirements. For example in smart cards and also in other applications,such as secureelement in various devices.This new product family features a progressivesecurity philosophy focusingon data integrity.By that three main principles combined in closesynergy are utilized in the new security concept called the “Integrity Guard”. The Integrity Guard implements the main principles full error detection, full encryption and intelligentactiveshielding. With these capabilitiesthis TOEcan be used almosteverywhere, where highly secureapplicationsarein useand of coursein any other application aswell.This TOE is deemed for governmental, corporate,transportand payment markets, or wherever a secure root of trust is required.Various types of applicationscan usethis TOE, for example in closed loop logical accesscontrols,physical accesscontrols,secureinternet access control and internet authentication,or as multi - application token or simply as encrypted storage. This dual interfacecontroller is ableto communicate usingeither the contact based or the contactless interface.The implemented dual interfaceprovides a maximum flexibility in usingfollowingcommunication protocols: ISO 7816,ISO 14443 Type A and Type B, ISO/IEC 18092 NFC passivemode, Mifare compatibleInterfaceas well as further M7892 B11 Security Target Lite Public Security Target Lite 15 2015-10-13 communication modes, allowingalso theimplementation of user defi ned concepts for contactbased or contactless communication.More details aregiven the confidential Security Target [10] and the hardwarereference manual [6]. In order to increasethe contactless interfaceperformance even more, the RFI can be configured in terms of baud rates for reception and transmission and the setting of the sub-carrier frequency used for the load modulation.More details are given in the hardwarereference manual [6]. Table 4: Interface combinations excerpt of the TOE Protocol ISO7816 ISO14443 A ISO14443 B ISO18092 NFC passive mode Mifare compatible interface Interface Options in brief Further details and options aredescribed in the confidential Security Target [10]. The TOE provides a real 16-bitCPU-architecture and is compatibleto the Intel 80251 architecture.The major components of the core system are the two CPUs (Central ProcessingUnits),the MMU (Memory Management Unit) and MED (Memory Encryption/Decryption Unit). The two CPUs control each other in order to detect faults and serve by this for data integrity. The TOE implements a full 16 MByte linear addressablememory spacefor each privilegelevel,a simple scalableMemory Management concept and a scalablestack size.The flexiblememory concept consists of ROM- and Flash-memory as partof the non volatilememory (NVM), respectively SOLID FLASH™ NVM. For the SOLID FLASH™ NVM the Unified Channel Programming(UCP) memory technology is used. The RMS library providingsomefunctionality via an API to the Smartcard Embedded Software contains for example SOLID FLASH™ NVM serviceroutines.The Service Algorithm provides functionality for the tearing savewrite into the SOLID FLASH™ NVM. The STS firmware is used for test purposes duringstart-up and the Flash Loader allows downloadinguser software to the SOLID FLASH™ NVM duringthe manufacturingprocess.The STS is implemented in a separated Test-ROM being part of the TOE. The BSI has changed names and abbreviations for RandomNumber Generators, which is clarified as follows:The Physical True Random Number Generator (PTRG), also named True Random Number Generator (TRNG) is a physical random number generator and meets the requirements of the functionality classAIS31 PTG.2, see [5]. Itis used for provision of random number generation as a security serviceto the user and for internal purposes.The produced genuine random numbers can be used directly or as seed for the Deterministic Random Number Generator (DRNG), former named as Pseudo Random Number Generator (PRNG). The DRNG respectively PRNG is not in the scope of the evaluation.The TRNG respectively PTRNG is specially designed for smartcards,but can also beused in any other application whereexcellent physical randomdata arerequired. The two cryptographic co-processorsservethe need of modern cryptography: The symmetric co-processor (SCP) combines both AES and Triple-DES with dual-key or triple-key hardware acceleration.The Asymmetric Crypto Co- processor,called Crypto2304Tin the following,is performance optimized for RSA-2048 bit(4096-bitwith CRT) and Elliptic Curve (EC) cryptography. The software part of the TOE consists of the cryptographic RSA-, EC- and the SHA-2 librariesand the supportingToolbox and Base libraries.If RSA or EC or Toolbox or combinations hereof are part of the shipment, automatically theBase Library is included. M7892 B11 Security Target Lite Public Security Target Lite 16 2015-10-13 The RSA library isused to providea high level interfaceto RSA (Rivest, Shamir,Adleman) cryptography implemented on the hardwarecomponent Crypto2304T and includes countermeasures againstSPA, DPA and DFA attacks.The routines are used for the generation of RSA Key Pairs (RsaKeyGen),the RSA signatureverification (RsaVerify),the RSA signature generation (RsaSign) and the RSA modulus recalculation (RsaModulus).The hardwareCrypto2304T unitprovides the basic longnumber calculations(add,subtract,multiply,squarewith 1100 bit numbers) with high performance. The RSA library is delivered as object code and in this way integrated in the user software. The RSA library can performRSA operations from 512 to 4096 bits. Followingthe BSI 1 recommendations, key lengths below 1024 bit are not included in the certificate. The EC library isused to provide a high level interface to Elliptic Curvecryptography implemented on the hardware component Crypto2304Tand includes countermeasures againstSPA,DPA and DFA attacks.The routines are used for ECDSA signaturegeneration, ECDSA signatureverification,ECDSA key generation and Elliptic CurveDiffie-Hellman key agreement. In addition,the EC library provides an additional function for calculatingprimitiveelliptic curveoperations likeEC Add and EC Double. EC curves over prime field Fp, as well as over GF(2 n ) finitefield are supported too. The EC library isdelivered as objectcode and in this way integrated in the user software. The certification covers the standard NIST [17] and Brainpool [18] Elliptic Curves with key lengths of 160, 163, 192,224, 233, 256, 283, 320,384, 409, 512 or 521 bits,due to national AIS32 regulations by the BSI. Note that there are further uncounted side-channel-secure curve types which the user can optionally add in the composition certification process. The SHA-library provides the calculation of a hash valueof freely chosen data input in the CPU. The SHA-library is delivered as objectcode and is in this way availablefor the user software. This secure hash-algorithmSHA-2 is intended to be used for signaturegeneration, verification and generic data integrity checks. The use for keyed hash operations likeHMAC or similarsecurity critical operationsinvolvingkeys,is notsubjectof this TOE and requires specific security improvements and DPA analysisincludingtheoperating system, which is not part of this TOE. The toolbox library does not providecryptographic supportor additional security functionality as itprovides only the followingbasiclonginteger arithmetic and modular functions in software, supported by the cryptographic coprocessor: Addition, subtraction,division,multiplication,comparison,reduction,modular addition,modular subtraction,modular multiplication,modular inversion and modular exponentiation.No security relevantpolicy,mechanismor function is supported. The toolbox library isdeemed for software developers as supportfor simplified implementation of long integer and modular arithmetic operations. The Base Library provides the low level interface to the asymmetric cryptographic coprocessorand has no user available interface. The baselibrary does not provideany security functionality,implements no security mechanism, and does not provideadditional specificsecurity functionality. Note that this TOE can come with both cryptographic co-processorsaccessible,or with a blocked SCP or with a blocked Crypto2304T, or with both cryptographic co-processors blocked.The blockingdepends on the user’s choice. No accessibility of the deselected cryptographic co-processors iswithoutimpacton any other security policy of the TOE; it is 1 BSI Bundesamt für Sicherheitin der Informationstechnik –Federal office for information security M7892 B11 Security Target Lite Public Security Target Lite 17 2015-10-13 exactly equivalentto the situation where the user decides justnot to use the cryptographic co-processors.The TOE can be delivered without a specific library.In this casethe TOE does not providethe Additional Specific Security Functionality Rivest-Shamir-Adleman Cryptography (RSA) or/and Elliptic CurveCryptography (EC) or/and SHA-2. To fulfill thehighest security standards for smartcardstoday and also in thefuture, this TOE implements a progressive digital security concept,which already has been certified in various forerunner processes.Thereby, this TOE utilizes digital security features to includecustomer friendly security,combined with a robust design overcoming the disadvantages on analogueprotection technologies.The TOE provides full on-chip encryption coveringthe complete core, busses, memories and cryptographic co-processorsleavingno plaintexton the chip.Therefore the attractiveness for attackers is extremely reduced as encrypted signalsareof no use for the attacker – neither for manipulation nor for eavesdropping. In addition,the TOE is equipped with a full error detection capability for the complete data path. The dual CPU approach allows error detection even while processing.Acomparator detects whether a calculation was performed without errors. This approach does not leave any parts of the circuitry unprotected. The concept allows thatthe relevant attack scenarios are detected, whereas other conditions thatwould not lead to an error would mainly be ignored. And more, the TOE is equipped with signal protection implemented by an Infineon-specific shieldingcombined with secure wiring and shielding of security critical signals. In the confidential Security Target [10] the TOE is described and a summary specification is given.The security environment of the TOE duringits different phases of the lifecycleis defined.The assets areidentified which have to be protected through the security policy.The threats againstthese assets aredescribed.The security objectives and the security policy aredefined, as well as the security requirements. These security requirements are builtup of the security functional requirements as part of the security policy and the security assurancerequirements. These are the steps during the evaluation and certification showingthatthe TOE meets the targeted requirements. In addition,the functionality of the TOE matching the requirements is described. The assets,threats, security objectives and the security functional requirements are defined in this Security Target and in the Protection Profile(PP) [1] and arereferenced here. These requirements build up a minimal standard common for all Smartcards. The security functions aredefined here in the Security Target as property of this specific TOE.Here it is shown how this specific TOEfulfillstherequirements for the standard defined in the Protection Profile[1]. M7892 B11 Security Target Lite Public Security Target Lite 18 2015-10-13 2 Target of Evaluation Description The TOE description helps to understand the specific security environment and the security policy.In this context the assets,threats, security objectives and security functional requirements can be employed. The followingis a more detailed description of the TOE than in the PP [1] as itbelongs to the specific TOE. 2.1 TOE Definition This TOE consists of Security Dual InterfaceControllers as integrated circuits,meeting the highest requirements in terms of performance and security.They are manufactured by Infineon Technologies in a 90 nm CMOS-technology (L90). This TOE is intended to be used in smart cards for particularly security-relevantapplications and for its previous useas developing platformfor smartcard operating systems accordingto the lifecyclemodel from the PP [1] The term Smartcard Embedded Software is used in the followingfor all operatingsystems and applications stored and executed on the TOE regardless whether itis a smartcard or another application of form factor.The TOE is the platform for the Smartcard Embedded Software. The Smartcard Embedded Software itself is not partof the TOE. The TOE consists of a coresystem, memories, co-processors,peripherals,security modules and analogueperipherals.The major components of the core system are the two CPUs (Central ProcessingUnits),the MMU (Memory Management Unit) and MED (Memory Encryption/Decryption Unit). The co-processor block contains theprocessors for RSA/EC and DES/AES processing,whilethe peripheral block contains therandom number generation and the external interfaces service.The peripheral block contains also thetimers and a watchdog. All data of the memory block is encrypted and all memory types are equipped with an error detection code (EDC), the SOLID FLASH™ NVM in addition with an error correction code (ECC). The security modules serve for operation within the specified range and manage the alarms. This dual interfacecontroller is ableto communicate usingeither the contact based or the contactless interface.The implemented dual interfaceprovides a maximum flexibility in usingfollowingcommunication protocols:ISO 7816,ISO 14443 Type A and Type B, ISO/IEC 18092 NFC passivemode, Mifare compatibleInterface as well as further communication modes, allowingalso theimplementation of user defined concepts for contactbased or contactless communication. The flexibility of the communication interfaces enablefor example also the use cases involving external analoguemodems, which aretypically deemed for applicationsrunningin mobiledevices.Pleasenote that these external parts areof coursenot part of this TOE. More details aregiven the confidential Security Target [10] and the hardware reference manual [6]. The availability of the various communication options depends on the configuration and customer order. Supporting a MifarecompatibleInterface application requires a dedicated small spaceof memory. In this context and depending on user’s choice,various memory sections of 1 up to 4 kByte each can be defined. The number and location of these memory sections is simply limited by the availableSOLID FLASH™ NVM space.Also these memory sections are read/write protected and are defined and generated by the user. Note that there is a small setof sensors leftin order to detect excessivedeviations fromthe specified operational range, whilenot being over-sensitive.These digital features do not need adjustment or calibration and makes the chip even more robust. Conditions thatwould not be harmful for the operation would in most cases not influencethe proper M7892 B11 Security Target Lite Public Security Target Lite 19 2015-10-13 function. Havingthe integrity guard concept in place, the sensors areno more required for the TOE security.The sensors are assigned to be security supporting.The only sensors contributingto a security mechanismis the frequency sensor. The CPU – here the two processors (CPU1 and CPU2) are seen from functional perspectiveas one - is compatiblewith the instruction setof the forerunner family 66-PEand is multipletimes faster than the standard processor.Itprovides additional powerful instructionsfor smartcard or other applications.Itthus meets the requirements for the new generation of operating systems. Despite its compatibility the CPU implementation is enti rely proprietary and not standard. The CPU accesses thememory via the integrated Memory Encryption and Decryption unit(MED). The access rights of the application to the memories can be controlled with the memory management unit(MMU). Errors in the memories are automatically detected (EDC) and in terms of the SOLID FLASH™ NVM certain errors arealso corrected (ECC). The two processors of the CPU control each other in order to detect faults and maintain by this the data integrity. A comparator detects whether a calculation was performed without errors and allows error detection even whileprocessing.Therefore the TOE is equipped with a full error detection capability for the complete data path, which does not leave any parts of the circuitry unprotected. The controllers of this TOE store both code and data in a linear 16-MByte memory space, allowingdirectaccesswithout the need to swap memory segments in and out of memory usinga memory management unit. The error detection unit(EDU) automatically manages the error detection of the individual memories and detects incorrecttransfer of data between the memories by means of error code comparison. The CACHE memory – or simply,the CACHE – is a high-speed memory-buffer located between the CPU and the (external) main memories holdinga copy of some of the memory contents to enable access to the copy, which is considerably faster than retrievingthe information fromthe main memory. In addition to its fastaccess speed,the CACHE also consumes less power than the main memories. All CACHE systems own their usefulness to the principleof locality,meaningthat programs are inclined to utilizea particular section of the address spacefor their processingover a shortperiod of time. By includingmostor all of such a specific area in theCACHE, system performance can be dramatically enhanced.The implemented post failuredetection identifies and manages errors if appeared during storage. The TRNG respectively PTRNG is specially designed for smartcards,but can also beused in any other application where excellent physical randomdata arerequired. The TRNG respectively PTRNG fulfills therequirements from the functionality classPTG.2 of the AIS31 and produces genuine random numbers which then can be used directly or as seed for the Deterministic Random Number Generator (DRNG), former named as Pseudo Random Number Generator (PRNG). The DRNG respectively PRNG is not in the scope of the evaluation. The implemented sleep mode logic (clock stop mode per ISO/IEC 7816-3) is used to reduce the overall power consumption. Contactless products providea low-power haltmode for operation with reduced power. The timer permits easy implementation of communication protocols such as T=1 and all other time-critical operations. The UART-controlled I/O interface allows thesecurity controller and the terminal interfaceto be operated independently. The Clock Unit (CLKU) supplies theclocks for all components of the TOE. The Clock Unit can work in an internal and external clock mode. When operating in the internal clock mode the system frequency may be varied in a range of approximately 1 MHz up to 33 MHz in steps of roughly 1 MHz. Some derivatives provide also frequencies beyond 33 MHz, M7892 B11 Security Target Lite Public Security Target Lite 20 2015-10-13 which enables a programmer to choosethe best-fittingfrequency for an application in consideration of a potential current limitand a demanded application performance. In this external clock mode, the system clock is derived from an externally applied interfaceclock accordingto a defined dependency. The system frequency may be 1 up to 8 times the externally applied frequency but is of courselimited to the maximum system frequency. More details aregiven in the confidential Security Target [10] and in the hardware reference manual [6]. Two co-processors for cryptographic operationsareimplemented on the TOE: The Crypto2304T for calculation of asymmetric algorithms likeRSA and Elliptic Curve(EC) and the Symmetric Cryptographic Processor (SCP) for dual -key or triple-key triple-DES and AES calculations.These co-processors areespecially designed for smartcard applicationswith respect to the security and power consumption,but can of coursebe used in any other application of form factor where suitable.The SCP module computes the complete DES algorithmwithin a few clock cycles and is especially designed to counter attacks likeDPA, EMA and DFA. Note that this TOE can come with both crypto co-processors accessible,or with a blocked SCP or with a blocked Crypto2304T, or with both crypto co-processors blocked.The blockingdepends on the customer demands prior to the production of the hardware. No accessibility of the deselected cryptographic co-processorsis withoutimpacton any other security policy of the TOE; it is exactly equivalentto the situation where the user decides justnot to use the cryptographic co-processors. The STS (self-test software), RMS (Resource Management System), ServiceAlgorithm Minimal (SAM) and Flash Loader together compose the TOE firmware stored in the ROM and the patches hereof in the SOLID FLASH™ NVM. All mandatory functions for internal testing, production usage and start-up behavior (STS), and also the RMS and SAM functions are grouped together in a common privilegelevel. These privilegelevels areprotected by a hardwired Memory Management Unit (MMU) setting. The user software can be implemented in various options dependingon the user’s choice as described in chapter 2.2.2. Thereby the user software, or parts of it, can be downloaded into the SOLID FLASH™ NVM, either duringproduction of the TOE or at customer side.In the latter case, the user downloads his softwareor the final parts of itat his own premises,usingthe Flash Loader software. The TOE uses also Special Function Registers SFR.These SFR registers are used for general purposes and chip configuration.The start-up register values arestored in the SOLID FLASH™ NVM, in the configuration pagearea. The bus system comprises two separatebus entities: a memory bus supporting and an peripheral bus for high-speed communication with the peripherals. An intelligentshielding algorithmfinishes theupper layers abovesecurity critical signalsand wires, finally providing theso called “I 2 -shield”. The followingis a listof features provided by this TOE:  24-bitlinear addressing  Up to 16 MByte of addressablememory  Register-based architecture(registers can be accessed as bytes, words (2 bytes), and doubl ewords (4 bytes))  2-stage instruction pipeline  Extensive set of powerful instructions,including16- and 32-bitarithmetic and logic instructions M7892 B11 Security Target Lite Public Security Target Lite 21 2015-10-13  CACHE with single-cycleaccesssearching  16-bitALU The TOE sets a new, improved standard of integrated security features, thereby meeting the requirements of all smart card and other related applicationsor formfactors,such as information integrity,access control,mobiletelephone and identification,as well as uses in electronic funds transfer and healthcare systems. To sumup, the TOE is a powerful dual interfacesecurity controller with a largeamount of memory and special peripheral devices with improved performance, optimized power consumption, free to choose contact based or contactless operation, at minimal chip sizewhileimplementing high security.It therefore constitutes the basis for futuresmart card and other related applicationsor form factors. Figure 1: Simplified block diagram of the TOE Peripherals Control Core Core Cache Cache Co- Processors Crypto 2304T SCP Co- Processors Crypto 2304T Crypto 2304T SCP SCP ITP/PEC ITP/PEC ICO Clock Unit ICO Clock Unit Power Mgmt./ Voltage Regulator IMM/Res UmSLC IMM/Res UmSLC TRNG TRNG CRC CRC PRNG PRNG Timer & WDT Timer & WDT RF Interface RF Interface MMU MMU Memories Memories IFX-ROM IFX-ROM RAM RAM Solid Flash™ MED EDU MED EDU Security Peripherals Filters Filters Sensors Sensors Memory Bus (32 bit) UART UART CPU1 CPU2 Peripheral Bus (16 bit) 2.2 Scope of the TOE The TOE comprises: The silicon die,respectively the IC or hardware,in several versions: Each version differences from each other justby the inputcapacity of the radio frequency interface (RFI) or by the additional metal layer on top, with accordingfirmwareand optional softwareof the security controller,as defined in the chapters above. The TOE is delivered in various configurations,achieved by means of blocking. All product derivatives of this TOE, includingall configuration possibilities,regardless whether comingwith or without top metal layer,are manufactured by Infineon Technologies. In the followingdescriptions,the term “manufacturer” stands shortfor Infineon Technologies, the manufacturer of the TOE. M7892 B11 Security Target Lite Public Security Target Lite 22 2015-10-13 New configurations can occur atany time, but in any casethe user is ableto clearly identify the TOE hardware,its configuration and proof the validity of the certificateindependently, meaning without involving the manufacturer. Entirely all means of blockingand the, for the blockinginvolved firmwarerespectively software parts, have been subject of the evaluation.All resultingconfigurationsof a TOE derivativeare subjectof the certificate. All resultingconfigurations are either at the predefined limits or within the predefined configuration ranges. The firmware used for the TOE internal testing and TOE operation, the firmware and software parts exclusively used for the blocking,the parts of the firmware and software required for cryptographic supportarepart of the TOE and therefore part of the certification.The documents as described in chapter 2.2.4 and listed in chapter 9, aresupplied as user guidance. Not part of the TOE and not partof the certification are the Smartcard Embedded Software respectively user software, and commercial parts of the Billing-Per-Usesoftware. 2.2.1 Hardware of the TOE The hardwarepart of the TOE (see Figure) as defined in the PP [1] is comprised of: Core System Proprietary CPU implementation of the Intel MCS251 standard architecturefrom functional perspective, represented by two CPUs from hardwareperspective CACHE with Post FailureDetection Memory Encryption/Decryption Unit (MED) and Error Detection Unit (EDU) Memory Management Unit (MMU) Memories Read-Only Memory (ROM), not user available Random Access Memory (RAM) Note that the TOE has implemented an Electrical ErasableProgrammableRead Only Memory (EEPROM) module. This EERPOM module is configured to actfor the most part as a flash memory. Therefore, the module is called the SOLID FLASH™ NVM module. Peripherals True Random Number Generator (TRNG) respectively Physical TrueRandom Number Generator (PTRNG) Deterministic Random Number Generator (DRNG) respectively Pseudo Random Number Generator (PRNG) Watchdog and Timers Universal Asynchronous Receiver/Transmitter (UART) Checksum module (CRC) RF interface (radio frequency power and signal interface) Control Dynamic Power Management Internal Clock Oscillator (ICO) Interrupt and Peripheral Event Channel Controller (ITP and PEC) M7892 B11 Security Target Lite Public Security Target Lite 23 2015-10-13 Interface Management Module (IMM) User mode Security Life Control (UmSLC) Voltage Regulator Coprocessors Crypto2304T for asymmetric algorithms likeRSA and EC (optionally blocked) Symmetric Crypto Co-processor for 3DES and AES Standards (optionally blocked) Security Peripherals Filters Sensors Buses Memory Bus Peripheral Bus 2.2.2 Firmware and software of the TOE The entire firmwareof the TOE consists of different parts: One part comprises the RMS and SAM routines for SOLID FLASH™ NVM programming, security functions test, and random number onlinetesting (Resource Management System, IC Dedicated Support Software in PP [1]). The RMS and SAM routines arestored from Infineon Technologies in the ROM. The ROM is only availablefor Infineon Technologies,the user has no access. The second partis the STS, consistingof test and initialization routines (Self TestSoftware, IC Dedicated Test Software in PP [1]). The STS routines are stored in the especially protected test ROM and are not accessiblefor the user software. The third part is the Flash Loader. This piece of software is located in the ROM and enables the download of the user software or parts of itto the SOLID FLASH™ NVM. After completion of the download the Flash Loader shall belocked by the by the user. The fourth part is the Mifare compatibleInterfaceroutines, called via RMS routines,if the related interfaceoption is active. Note that these routines are always present,but aredeactivated, in caseof the derivatives comingwithout this option. Thus the user interface is identically in both cases and consequently the related interfaceroutines can be called in each of the derivatives.In casethe related interfaceroutines are called in derivatives withoutthis option, an error code is returned. In the other casethe related function is performed. All parts of the firmware above arecombined together by the TOE generation process to a singlefileand stored then in the data files,the TOE is produced from. This comprises the firmware files for the ROM, where only Infineon Technologies has access,as well as thedata to be flashed in the SOLID FLASH™ NVM. This TOE can come with alternatively three firmware packages. The optional softwarepart of the TOE consists of the RSA-, the EC, the SHA-2 and the toolbox libraries. The RSA library isused to providea high level interfaceto the RSA cryptography implemented on the hardware component Crypto2304Tand includes countermeasures againstSPA,DPA and DFA attacks.The routines are used for the generation of RSA Key Pairs (RsaKeyGen),the RSA signatureverification (RsaVerify),the RSA signaturegeneration M7892 B11 Security Target Lite Public Security Target Lite 24 2015-10-13 (RsaSign) and the RSA modulus recalculation (RsaModulus).Themodule provides the basic longnumber calculations(add, subtract,multiply,squarewith 1100 bit numbers) with high performance. The RSA library isdelivered as objectcode and in this way integrated in the user software. The RSA library can perform RSA operations from 512 to 4096 bits.Depending on the customer’s choice,the TOE can be delivered with the 4096 code portion or with the 2048 code portion only.The 2048 code portion is included in both. Partof the evaluation arethe RSA straightoperations with key length from 1024 bits to 2048 bits,and the RSA CRT 1 operations with key lengths of 1024 Bits to 4096 Bits. The EC library isused to provide a high level interface to Elliptic Curvecryptography and includes countermeasures againstSPA, DPA and DFA attacks.The routines areused for ECDSA signaturegeneration, ECDSA signatureverification, ECDSA key generation and Elliptic CurveDiffie-Hellman key agreement. In addition,the EC library provides an interfaceto an addition function for primitiveellipticcurveoperations likeECC Add and ECC Double. ECC curves over prime field Fp, as well as over GF(2^n) finitefield are supported too. The EC library isdelivered as objectcode and in this way integrated in the user software. The certification covers the standard NIST [17] and Brainpool [18] Elliptic Curves with key lengths of 160, 163, 192,224, 233, 256,283, 320,384, 409, 512 or 521 bits,due to national AIS32 regulations by the BSI. Note that there are further uncounted side-channel-secure curve types which the user can optionally add in the composition certification process. The SHA-2 library provides thecalculation of a hash valueof freely chosen data input in the CPU. The SHA-2 library is delivered as objectcode and is in this way availablefor the user software. This secure hash-algorithmSHA-2 is intended to be used for signaturegeneration, verification and generic data integrity checks. The use for keyed hash operations like HMAC or similarsecurity critical operations involvingkeys,is notsubject of this TOE and requires specific security improvements and DPA analysisincludingtheoperating system, which is not part of this TOE. The toolbox library does not providecryptographic supportor additional security functionality as itprovides only the followingbasiclonginteger arithmetic and modular functions in software, supported by the cryptographic coprocessor: Addition, subtraction,division,multiplication,comparison,reduction,modular addition,modular subtraction,modular multiplication,modular inversion and modular exponentiation.No security relevantpolicy,mechanismor function is supported. The toolbox library isdeemed for software developers as supportfor simplified implementation of long integer and modular arithmetic operations. The Base Library provides the low level interface to the asymmetric cryptographic coprocessorand has no user available interface. The baselibrary does not provideany security functionality,implements no security mechanism, and does not provideadditional specificsecurity functionality. 1 CRT: Chinese RemainderTheorem M7892 B11 Security Target Lite Public Security Target Lite 25 2015-10-13 Note 1: The cryptographic libraries RSA,EC and SHA-2 are delivery options.Therefore the TOE may come with free combinations of or without these libraries.In the caseof coming without one or any combination of these librariesthe TOE does not providethe Additional Specific Security Functionality Rivest-Shamir-Adleman Cryptography (RSA) and/or Elliptic Curve Cryptography (EC) and/or SHA-2. End of note. 2.2.3 Interfaces of the TOE The interfaces are constituted out of:  The physical interfaceof the TOE to the external environment is the entire surfaceof the IC.  The electrical interfaceof the TOE to the external environment is constituted by the pads of the chip,particularly the contacted RES, I/O,CLK lines and supply lines VCC and GND, as well as by the contactless RF interface. The contact based communication is accordingto ISO 7816/ETSI/EMV. Further combinations involvingthepads and parts of the RF interface are also possibleand described in the confidential Security Target [10] and in the hardwarereference manual [6].  The RF interface(radio frequency power and signal interface) enables contactless communication between a PICC (proximity integration chip card,PICC) and a PCD reader/writer (proximity couplingdevice,PCD). Power supply is received and data are received or transmitted by an antenna which consists of a coil with a few turns directly connected to the IC. Depending on customer orders the contactless interfaceoptions are set by means of blockingeither at Infineon premises or atthe premises of the user. Note that further interface options are availableand described in the confidential Security Target [10].  The data-oriented I/O interface to the TOE is formed by the I/O pad and by the various RF options.  The interface to the firmware is constituted by special registers used for hardwareconfiguration and control (Special Function Registers,SFR).  The interface of the TOE to the operatingsystem is constituted on one hand by the RMS routine callsand on the other by the instruction setof the TOE.  The interface of the TOE to the test routines is formed by the STS test routinecall,i.e.entry to test mode (STS-TM entry).  The interface to the RSA calculationsis defined from the RSA library interface.  The interface to the EC calculationsisdefined from the EC library interface  The interface to the SHA-2 calculation isdefined from the SHA-2 library interface.  Note that the interfaces to the cryptographic libraries (RSA, EC and SHA-2) are optionally dependingon the customer order. M7892 B11 Security Target Lite Public Security Target Lite 26 2015-10-13 2.2.4 Guidance documentation The guidancedocumentation consists of the:  M7892, Controller Family for Security Applications,HardwareReference Manual.  SLx 70 Family Production and Personalization.  SLE 70 Family Programmer’s Reference User’s Manual.  SLE 70 Asymmetric Crypto Library for Crypto@2304T, RSA, ECC, Toolbox, User Interface (optional),contains all interfaces of the cryptographic RSA- and EC libraries,as well as of the Toolbox library.This document is only delivered to the user in casethe RSA library and/or theEC library and/or theToolbox library is/arepartof the delivered TOE.  SLx 70 Family,Secure Hash Algorithm SHA-2, (SHA 256/224,SHA 512/384),Confidential Application Note. This document contains all interfaces of the SHA-2 library and is only delivered to the user in casethe SHA-2 library is part of the delivered TOE.  Crypto@2304T User Manual,describingthearchitectureof cryptographic coprocessoron register level. It also provides a functional description of the register architecture,instruction setand gives programmingguidance.  SLx 70 Family,additional user guidancehowto use the Advanced Mode for Mifare Technology (AMM). This documentation is provisioned to the user if the AMM option has been ordered. This user guidancedescribes the interface and how to use this communication mode. This is an addendum to the HRM [6].  M7892, Controller Security Guidelines User Manual.This document discusses and provides codeexamples of how the user can consider the secure programmingrecommendations.  M7892 Controller Family for Security Applications,Errata Sheet. It can occur that the TOE or related documentation can be updated duringthe lifecycle.This is reported to the users by the confidential Errata Sheet. The exact versions of the above listed user guidancedocuments are given in Table1: Identification. Finally thecertification reportmay contain an overview of the recommendations to the software developer regardingthe secure use of the TOE. These recommendations are also included in the ordinary documentation. 2.2.5 Forms of delivery The TOE can be delivered in any form of complete module, package, with or without inlay mounting, in form of plain wafers or in an IC case(e.g. DSO20) or in bare dies.The delivery can therefore be at the end of phase3 or at the end of phase4 which can also includepre-personalization steps accordingto PP [1]. Nevertheless in both cases the TOE is finished and the extended test features areremoved. In this document are always both cases mentioned to avoid incorrectness butfrom the security policy pointof view the two cases areidentical. The delivery to the software developer (phase2  phase1) contains the development package and is delivered in form of documentation as described above, data carriers containingthe tools and emulators as development and debugging tool. Partof the software delivery is also theFlash Loader program, provided by Infineon Technologies,runningon the TOE and receivingthe transmitted information of the user software to be loaded into the SOLID FLASH™ NVM. The download is M7892 B11 Security Target Lite Public Security Target Lite 27 2015-10-13 only possibleafter successful authentication.The user software download can also be done in an encrypted way. After the user has finished his download,hepermanently disables further useof the Flash Loader by lockingit.Whether the Flash Loader program is present or not depends on the procurement order. 2.2.6 Production sites The TOE may be handled in different production sites but the silicon of this TOE is produced in Dresden, Germany only,as listed below. To distinguish thedifferent production sites of various products in thefield,the siteis coded into the Generic Chip Ident Mode (GCIM) data. The exact codingof the generic hip identification data is described in the hardware reference manual,[6]. The delivery measures aredescribed in the ALC_DVS aspect. Table 5: Production site in chip identification Production Site Chip Identification Dresden, Germany Byte number 13: 02h M7892 B11 Security Target Lite Public Security Target Lite 28 2015-10-13 3 Conformance Claims (ASE_CCL) 3.1 CC Conformance Claim This Security Target (ST) and the TOE claimconformanceto Common Criteria version v3.1 part1 [2], part 2 [3] and part 3 [4]. Conformance of this ST is claimed for: Common Criteria part2 extended and Common Criteria part3 conformant. 3.2 PP Claim This Security Target is in strict conformance to the Security IC PlatformProtection Profile[1]. The Security IC Platform Protection Profileis registered and certified by the Bundesamt für Sicherheitin der Informationstechnik 1 (BSI) under the reference BSI-PP-0035,Version 1.0, dated 2007-06-15. The security assurancerequirements of the TOE are accordingto the Security IC PlatformProtection Profile[1]. They are all drawn from Part3 of the Common Criteria version v3.1. The targeted EAL6+ level includes already theaugmentations of the Protection Profile[1] AVA_VAN.5 and ALC_DVS.2. Further augmentation is achieved - with regard to CCv3.1 Part 3: Security assurancecomponents – as follows: Table 6: Augmentations of the assurance level of the TOE Assurance Class Assurance components Description Life-cycle support ALC_FLR.1 Basic flaw remediation 3.3 Package Claim This Security Target does not claimconformanceto a package of the PP [1]. The assurancelevel for the TOE is EAL6 augmented with the component ALC_FLR.1 The assurance level for the TOE is: EAL6 augmented (EAL6+) with the component ALC_FLR.1. 1 Bundesamt für Sicherheit in der Informationstechnik(BSI) is the German Federal Officefor InformationSecurity M7892 B11 Security Target Lite Public Security Target Lite 29 2015-10-13 3.4 Conformance Rationale This Security Target claims strictconformanceonly to one PP, the PP [1]. The Target of Evaluation (TOE) is a typical security IC as defined in PP chapter 1.2.2 comprising:  the circuitry of the IC (hardwareincludingthe physical memories),  configuration data,initialization data related to the IC Dedicated Software and the behavior of the security functionality  the IC Dedicated Software with the parts  the IC Dedicated Test Software,  the IC Dedicated Support Software. The TOE is designed, produced and/or generated by the TOE Manufacturer. Security Problem Definition: Followingthe PP [1], the security problemdefinition is enhanced by addingan additional threat,an organization security policy and an augmented assumption.Includingthese add-ons,the security problem definition of this Security Target is consistentwith the statement of the security problem definition in the PP [1], as the security target claimed strict conformance to the PP [1]. Conformance Rationale: The augmented organizational security policy P.Add-Functions,comingfrom the additional security functionality of the cryptographic libraries,theaugmented assumption A.Key-Function, related to the usage of key-depending function, and the threat memory access violation T.Mem-Access, due to specific TOEmemory access control functionality,havebeen added. These add-ons have no impact on the conformance statements regardingCC [2] and PP [1], with following rational:  The Security Target remains conformantto CC [2], claim482 as the possibility to introduce additional restrictions is given.  The Security Target fulfillsthe strictconformanceclaimof the PP [1] due to the application notes 5, 6 and 7 which apply here. By those notes the addition of further security functions and security services arecovered, even without derivingparticular security functionality froma threat but from a policy. Due to additional security functionality,one coming from the cryptographic libraries - O.Add-Functions,and due to the memory access control - O.Mem-Access, additional security objectives havebeen introduced. These add-ons have no impacton the conformance statements regardingCC [2] and PP [1], with followingrational:  The Security Target remains conformantto CC [2], claim482 as the possibility to introduce additional restrictions is given.  The Security Target fulfillsthe strictconformanceof the PP [1] due to the application note9 applyinghere. This note allows the definition of high-level security goals dueto further functions or services provided to the Security IC Embedded Software. Therefore, the security objectives of this Security Target are consistentwith the statement of the security objectives in the PP [1], as the Security Target claimed strictconformanceto the PP [1]. M7892 B11 Security Target Lite Public Security Target Lite 30 2015-10-13 All security functional requirements defined in the PP [1] are included and completely defined in this ST. The security functional requirements listed in the followingareall taken from Common Criteria part2 [3] and additionally included and completely defined in this ST:  FDP_ACC.1 “Subset access control”  FDP_ACF.1 “Security attribute based access control”  FMT_MSA.1 “Management of security attributes”  FMT_MSA.3 “Static attribute initialization”  FMT_SMF.1 “Specification of Management functions”  FCS_COP.1 “Cryptographic support”  FCS_CKM.1 “Cryptographic key generation”  FDP_SDI.1 “Stored data integrity monitoring  FDP_SDI.2 “Stored data integrity monitoring and action The security functional requirement  FPT_TST.2 “Subset TOE security testing“(Requirement from [3])  FCS_RNG.1 “Generation of Random Numbers” are included and completely defined in this ST, section 6. All assignments and selections of the security functional requirements are done in the PP [1] and in this Security Target, in chapter 7.2. The AssuranceRequirements of the TOE obtain the Evaluation AssuranceLevel 6 augmented with the assurance component ALC_FLR.1 for the TOE. 3.5 Application Notes The functional requirement FCS_RNG.1 is a refinement of the FCS_RNG.1 defined in the Protection Profile[1] accordingto AIS31, see reference [5]. M7892 B11 Security Target Lite Public Security Target Lite 31 2015-10-13 4 Security Problem Definition (ASE_SPD) The content of the PP [1] applies to this chapter completely. 4.1 Threats The threats are directed againstthe assets and/or the security functions of the TOE. For example, certain attacks are only one step towards a disclosureof assets whileothers may directly lead to a compromiseof the application security.The more detailed description of specific attacks is given later on in the process of evaluation and certification.An overview on attacks is given in PP [1] section 3.2. The threats to security aredefined and described in PP [1] section 3.2. Table 7: Threats according PP [1] T.Phys-Manipulation Physical Manipulation T.Phys-Probing Physical Probing T.Malfunction Malfunction due to Environmental Stress T.Leak-Inherent Inherent Information Leakage T.Leak-Forced Forced Information Leakage T.Abuse-Func Abuse of Functionality T.RND Deficiency of Random Numbers 4.1.1 Additional Threat due to TOE specific Functionality The additional functionality of introducingsophisticated privilegelevels and access control allows thesecure separation between the operation system(s) and applications,thesecure downloadingof applicationsafter personalization and enables multitaskingby separatingmemory areas and performingaccess controls between different applications.Dueto this additional functionality “area based memory access control”a new threat is introduced. The Smartcard Embedded Software is responsiblefor its User Data accordingto the assumption “Treatment of User Data (A.Resp-Appl)”. However, the Smartcard Embedded Software may comprisedifferent parts,for instancean operating system and one or more applications.In this case,such parts may accidentally or deliberately accessdata (includingcode) of other parts,which may resultin a security violation. M7892 B11 Security Target Lite Public Security Target Lite 32 2015-10-13 The TOE shall avertthe threat “Memory Access Violation (T.Mem-Access)” as specified below. T.Mem-Access Memory Access Violation Parts of the Smartcard Embedded Software may cause security violations by accidentally or deliberately accessing restricted data (which may include code) or privilege levels. Any restrictions are defined by the security policy of the specific application context and must be implemented by the Smartcard Embedded Software. Table 8: Additional threats due to TOE specific functions and augmentations T.Mem-Access Memory Access Violation For details seePP [1] section 3.2. 4.1.2 Assets regarding the Threats The primary assets concern the User Data which includes the user data as well as programcode (Security IC Embedded Software) stored and in operation and the provided security services.These assets haveto be protected whilebeing executed and or processed and on the other hand, when the TOE is not in operation. This leads to four primary assets with its related security concerns:  SC1 Integrity of User Data and of the Security IC Embedded Software (whilebeing executed/processed and while being stored in the TOE’s memories),  SC2 Confidentiality of User Data and of the Security IC Embedded Software (while being processed and while being stored in the TOE’s memories)  SC3 Correct operation of the security services provided by the TOE for the Security IC Embedded Software.  SC4 Continuous availability of randomnumbers SC4 is an additional security serviceprovided by this TOE which is the availability of random numbers. These random numbers are generated either by a true random number or a deterministic random number generator or by both, when a true random number is used as seed for the deterministic randomnumber generator. Note that the generation of random numbers is a requirement of the PP [1]. To be ableto protect the listed assets the TOE shall protect its security functionality as well.Therefore critical information about the TOE shall beprotected. Critical information includes:  logical design data,physical design data,IC Dedicated Software, and configuration data  Initialization Data and Pre-personalization Data,specificdevelopment aids,testand characterization related data, material for software development support, and reticles. The information and material produced and/or processed by the TOE Manufacturer in the TOE development and production environment (Phases 2 up to TOE Delivery) can be grouped as follows:  logical design data,  physical design data, M7892 B11 Security Target Lite Public Security Target Lite 33 2015-10-13  IC Dedicated Software, Security IC Embedded Software, Initialization Data and Pre-personalization Data,  specific development aids,  test and characterization related data,  material for software development support, and  reticles and products in any form as longas they are generated, stored, or processed by the TOE Manufacturer. For details seePP [1] section 3.1. 4.2 Organizational Security Policies The TOE has to be protected duringthe firstphases of their lifecycle(phases 2 up to TOE delivery which can be after phase3 or phase4). Later on each variantof the TOE has to protect itself.The organisational security policy covers this aspect. P.Process-TOE Protection during TOE Development and Production An accurate identification must be established for the TOE. This requires that each instantiation of the TOE carries this unique identification. The organizational security policies aredefined and described in PP [1] section 3.3. Due to the augmentations of PP [1] an additional policy is introduced and described in the next chapter. Table 9: Organizational Security Policies according PP [1] P.Process-TOE Protection duringTOE Development and Production 4.2.1 Augmented Organizational Security Policy Due to the augmentations of the PP [1] an additional policy isintroduced. The TOE provides specific security functionality,which can beused by the Smartcard Embedded Software. In the followingspecific security functionality is listed which is notderived from threats identified for the TOE’s environment because itcan only be decided in the context of the smartcard application,againstwhich threats the Smartcard Embedded Software will usethe specific security functionality. The IC Developer / Manufacturer must apply the policy “Additional Specific Security Functionality (P.Add-Functions)”as specified below. M7892 B11 Security Target Lite Public Security Target Lite 34 2015-10-13 P.Add-Functions Additional Specific Security Functionality The TOE shall provide the following specific security functionality to the Smartcard Embedded Software  Advanced Encryption Standard (AES)  TripleData Encryption Standard (3DES)  Rivest-Shamir-Adleman Cryptography (RSA),  Elliptic CurveCryptography (EC)  Secure Hash Algorithm SHA-2 Note 2: The cryptographic libraries RSA,EC, SHA-2 and the Toolbox library aredelivery options.Therefore the TOE may come with free combinations of or even without these libraries.In the caseof coming without one or any combination of the cryptographic libraries RSA,EC and SHA-2, the TOE does not providethe Additional Specific Security Functionality Rivest- Shamir-Adleman Cryptography (RSA) and/or Elliptic CurveCryptography (EC) and/or SHA-2. The Toolbox library isno cryptographic library and provides no additional specific security functionality.If RSA, EC or Toolbox are partof the shipment, the BaseLibrary is automatically included.The Base Library does not proved additional specific functionality. End of note. Note 3: This TOE can come with both crypto co-processors accessible,or with a blocked SCP or with a blocked Crypto2304T, or with both crypto co-processors blocked. The blockingdepends on the customer demands prior to the production of the hardware. In casethe SCP is blocked,no AES and 3DES computation supported by hardwareis possible.In casethe Crypto2304T is blocked,no RSA and EC computation supported by hardwareis possible.The use of the SHA-2 library is also possiblewith both crypto coprocessors blocked.No accessibility of the deselected cryptographic co-processors is without impacton any other security policy of the TOE; it is exactly equivalentto the situation where the user decides just not to use the cryptographic co-processors. End of note. M7892 B11 Security Target Lite Public Security Target Lite 35 2015-10-13 4.3 Assumptions The TOE assumptions on the operational environmentare defined and described in PP [1] section 3.4. The assumptions concern the phases where the TOE has left the chip manufacturer. A.Process-Sec-IC Protection during Packaging, Finishing and Personalization It is assumed that security procedures are used after delivery of the TOE by the TOE Manufacturer up to delivery to the end-consumer to maintain confidentiality and integrity of the TOE and of its manufacturing and test data (to prevent any possible copy, modification, retention, theft or unauthorised use). A.Plat-Appl Usage of Hardware Platform The Security IC Embedded Software is designed so that the requirements from the following documents are met: (i) TOE guidance documents (refer to the Common Criteria assurance class AGD) such as the hardware data sheet, and the hardware application notes, and (ii) findings of the TOE evaluation reports relevant for the Security IC Embedded Software as documented in the certification report. A.Resp-Appl Treatment of User Data All User Data are owned by Security IC Embedded Software. Therefore, it must be assumed that security relevantUser Data (especially cryptographic keys) are treated by the Security IC Embedded Software as defined for its specific application context. The support of cipher schemas needs to make an additional assumption. Table 10: Assumption according PP [1] A.Process-Sec-IC Protection duringPackaging,Finishingand Personalization A.Plat-Appl Usage of Hardware Platform A.Resp-Appl Treatment of User Data M7892 B11 Security Target Lite Public Security Target Lite 36 2015-10-13 4.3.1 Augmented Assumptions The developer of the Smartcard Embedded Software must ensure the appropriate“Usage of Key-dependent Functions (A.Key-Function)” whiledeveloping this software in Phase1 as specified below. A.Key-Function Usage of Key-dependent Functions Key-dependent functions (if any) shall beimplemented in the Smartcard Embedded Software in a way that they are not susceptibleto leakageattacks (as described under T.Leak-Inherent and T.Leak-Forced). Note that here the routines which may compromisekeys when being executed are part of the Smartcard Embedded Software. In contrastto this the threats T.Leak-Inherent and T.Leak-Forced address (i) the cryptographic routines which are partof the TOE For details seePP [1] section 3.4. M7892 B11 Security Target Lite Public Security Target Lite 37 2015-10-13 5 Security objectives (ASE_OBJ) This section shows the subjects and objects where arerelevant to the TOE. A shortoverview is given in the following. The user has the followingstandard high-level security goalsrelated to the assets:  SG1 maintain the integrity of User Data and of the Security IC Embedded Software  SG2 maintain the confidentiality of User Data and of the Security IC Embedded Software  SG3 maintain the correctoperation of the security services provided by the TOE for the Security IC Embedded Software  SG4 provision of randomnumbers. 5.1 Security objectives for the TOE The security objectives of the TOE are defined and described in PP [1] section 4.1. Table 11: Objectives for the TOE according to PP [1] O.Phys-Manipulation Protection againstPhysical Manipulation O.Phys-Probing Protection againstPhysical Probing O.Malfunction Protection againstMalfunction O.Leak-Inherent Protection againstInherent Information Leakage O.Leak-Forced Protection againstForced Information Leakage O.Abuse-Func Protection againstAbuseof Functionality O.Identification TOE Identification O.RND Random Numbers The TOE provides “Additional Specific Security Functionality (O.Add-Functions)”as specified below. O.Add-Functions Additional Specific Security Functionality The TOE must provide the followingspecificsecurity functionality to the Smartcard Embedded Software:  Advanced Encryption Standard (AES)  TripleData Encryption Standard (3DES),  Rivest-Shamir-Adleman (RSA)  Elliptic CurveCryptography (EC)  Secure Hash Algorithm (SHA-2) M7892 B11 Security Target Lite Public Security Target Lite 38 2015-10-13 Note 4: The cryptographic libraries RSA,EC, SHA-2 and the Toolbox library aredelivery options.If one of the libraries RSA, EC and Toolbox or combination hereof aredelivered, the BaseLib is automatically partof it.Therefore the TOE may come with free combinations of or even without these libraries.In the caseof coming without one or any combination of the cryptographic libraries RSA,EC and SHA-2, the TOE does not providethe Additional Specific Security Functionality Rivest- Shamir-Adleman Cryptography (RSA) and/or Elliptic CurveCryptography (EC) and/or SHA-2. The Toolbox and Base Library are no cryptographic librariesand provideno additional specificsecurity functionality. End of note. Note 5: This TOE can come with both crypto co-processors accessible,or with a blocked SCP or with a blocked Crypto2304T, or with both crypto co-processors blocked.The blockingdepends on the customer demands prior to the production of the hardware. In casethe SCP is blocked,no AES and 3DES computation supported by hardwareis possible.In casethe Crypto2304T is blocked,no RSA and EC computation supported by hardwareis possible.The use of the SHA-2 library is also possiblewith both crypto coprocessors blocked.No accessibility of the deselected cryptographic co-processors is without impacton any other security policy of the TOE; it is exactly equivalentto the situation where the user decides just not to use the cryptographic co-processors. End of note. The TOE shall provide“Area based Memory Access Control (O.Mem-Access)” as specified below. O.Mem-Access Area based Memory Access Control The TOE must provide the Smartcard Embedded Software with the capability to define restricted access memory areas. The TOE must then enforce the partitioning of such memory areas so that access of software to memory areas and privilege levels is controlled as required, for example, in a multi-application environment. Table 12: Additional objectives due to TOE specific functions and augmentations O.Add-Functions Additional specificsecurity functionality O.Mem-Access Area based Memory Access Control 5.2 Security Objectives for the development and operational Environment The security objectives for the security IC embedded software development environment and the operational environment is defined in PP [1] section 4.2 and 4.3. The tablebelow lists thesecurity objectives. M7892 B11 Security Target Lite Public Security Target Lite 39 2015-10-13 Table 13: Security objectives for the environment according to PP [1] Phase1 OE.Plat-Appl Usage of Hardware Platform OE.Resp-Appl Treatment of User Data Phase5 – 6 optional Phase4 OE.Process-Sec-IC Protection duringcomposite product manufacturing 5.2.1 Clarification of “Usage of Hardware Platform (OE.Plat-Appl)” Regarding the cryptographic services thisobjectiveof the environment has to be clarified.The TOE supports cipher schemes as additional specific security functionality.If required the Smartcard Embedded Software shall usethese cryptographic services of the TOE and their interface as specified.When key-dependent functions implemented in the Smartcard Embedded Software are justbeing executed, the Smartcard Embedded Software must provide protection againstdisclosureof confidential data (User Data) stored and/or processed in the TOE by usingthe methods described under “Inherent Information Leakage (T.Leak-Inherent)” and “Forced Information Leakage (T.Leak-Forced)“. The objectives of the environment regardingthe memory, software and firmware protection and the SFR and peripheral - access-rights-handlinghaveto be clarified.For the separation of different applications theSmartcard Embedded Software (OperatingSystem) may implement a memory management scheme based upon security functions of the TOE. 5.2.2 Clarification of “Treatment of User Data (OE.Resp-Appl)” Regarding the cryptographic services thisobjectiveof the environment has to be clarified.By definition cipher or plain text data and cryptographic keys are User Data. The Smartcard Embedded Software shall treatthese data appropriately, use only proper secret keys (chosen from a largekey space) as inputfor the cryptographic function of the TOE and use keys and functions appropriately in order to ensure the strength of cryptographic operation. This means that keys are treated as confidential as soon as they are generated. The keys must be unique with a very high probability,as well as cryptographically strong.For example, itmust be ensured that itis beyond practicality to derive the privatekey from a public key if asymmetric algorithms areused. If keys are imported into the TOE and/or derived from other keys, quality and confidentiality mustbe maintained.This implies thatappropriatekey management has to be realised in the environment. Regarding the memory, software and firmware protection and the SFR and peripheral access rights handlingthese objectives of the environment has to be clarified.The treatment of User Data is also required when a multi-application operating system is implemented as partof the Smartcard Embedded Software on the TOE. In this casethe multi - application operatingsystemshould not disclosesecurity relevantuser data of one application to another application when it is processed or stored on the TOE. M7892 B11 Security Target Lite Public Security Target Lite 40 2015-10-13 5.2.3 Clarification of “Protection during Composite product manufacturing (OE.Process-Sec-IC)” The protection duringpackaging,finishingand personalization includes also thepersonalization process(Flash Loader software) and the personalization data (TOEsoftware components) duringPhase4, Phase5 and Phase6. 5.3 Security Objectives Rationale The security objectives rationaleof the TOE aredefined and described in PP [1] section 4.4. For orga nizational security policy P.Add-Functions,OE.Plat-Appl and OE.Resp-Appl the rationaleis given in the followingdescription. Table 14: Security Objective Rationale Assumption, Threat or Organisational Security Policy Security Objective P.Add-Functions O.Add-Functions A.Key-Function OE.Plat-Appl OE.Resp-Appl T.Mem-Access O.Mem-Access The justification related to the security objective “Additional Specific Security Functionality (O.Add-Functions)”is as follows:SinceO.Add-Functions requires the TOE to implement exactly the same specific security functionality as required by P.Add-Functions; the organisational security policy iscovered by the objective. Nevertheless the security objectives O.Leak-Inherent, O.Phys-Probing,O.Malfunction,O.Phys-Manipulation and O.Leak- Forced define how to implement the specific security functionality required by P.Add-Functions. (Note that these objectives supportthat the specific security functionality is provided in a secureway as expected from P.Add-Functions.) Especially O.Leak-Inherentand O.Leak-Forced refer to the protection of confidential data (User Data or TSF data) in general. User Data arealso processed by the specific security functionality required by P.Add-Functions. Compared to PP [1] clarification has been made for the security objective“Usage of Hardware Platform(OE.Plat-Appl)”: If required the Smartcard Embedded Software shall usethese cryptographic services of the TOE and their interface as specified.In addition,the Smartcard Embedded Software must implement functions which perform operations on keys (if any) in such a manner that they do not discloseinformation aboutconfidential data.The non disclosuredueto leakage A.Key-Function attacks is included in this objectiveOE.Plat-Appl.This addition ensures that the assumption A.Plat-Appl is still covered by the objectiveOE.Plat-Appl although additional functionsarebeingsupported accordingto O.Add-Functions. Compared to the PP [1] a clarification has been made for the security objective “Treatment of User Data (OE.Resp-Appl)”: By definition cipher or plain text data and cryptographic keys are User Data. So, the Smartcard Embedded Software will protect such data if required and use keys and functions appropriately in order to ensure the strength of cryptographic operation. Quality and confidentiality mustbe maintained for keys that are imported and/or derived from other keys. This implies thatappropriatekey management has to be realised in the environment. That i s expressed by the M7892 B11 Security Target Lite Public Security Target Lite 41 2015-10-13 assumption A.Key—Function which is covered from OE.Resp–Appl. These measures make surethat the assumption A.Resp-Appl is still covered by the security objective OE.Resp-Appl although additional functions arebeingsupported accordingto P.Add-Functions. Compared to the PP [1] an enhancement regardingmemory area protection has been established.The clear definition of privilegelevels for operated software establishes theclear separation of different restricted memory areas for running the firmware, downloadingand/or runningthe operating system and to establish a clear separation between different applications.Nevertheless, itis also possibleto define a shared memory section where separated applicationsmay exchange defined data.The privilegelevels clearly defineby usinga hierarchical model the access rightfrom one level to the other. These measures ensure that the threat T.Mem-Access is clearly covered by the security objective O.Mem- Access. The justification of the additional policy and the additional assumption showthat they do not contradictto the rationale already given in the Protection Profilefor the assumptions,policy and threats defined there. M7892 B11 Security Target Lite Public Security Target Lite 42 2015-10-13 6 Extended Component Definition (ASE_ECD) There are four extended components defined and described for the TOE:  the family FCS_RNG at the class FCS Cryptographic Support  the family FMT_LIM at the class FMTSecurity Management  the family FAU_SAS at the classFAU Security Audit  the component FPT_TST.2 at the class FPTProtection of the TSF The extended components FMT_LIM and FAU_SAS aredefined and described in PP [1] section 5. The components FCS_RNG and FPT_TST.2 are defined in the following. 6.1 Component “Subset TOE security testing (FPT_TST)” The security is strongly dependent on the correctoperation of the security functions.Therefore, the TOE shall support that particular security functions or mechanisms aretested in the operational phase(Phase7).The tests can be initiated by the Smartcard Embedded Software and/or by the TOE or is done automatically and continuously. Part2 of the Common Criteria provides the security functional component “TSF testing (FPT_TST.1)”. The component FPT_TST.1 provides the ability to test the TSF’s correct operation. For the user it is importantto know which security functions or mechanisms can be tested. The functional component FPT_TST.1 does not mandate to explicitly specify the security functions beingtested. In addition,FPT_TST.1 requires verification of the integrity of TSF data and of the stored TSF executable code which might violatethe security policy. Therefore, the functional component ”Subset TOE security testing (FPT_TST.2)” of the family TSF self test has been newly created. This component allows thatparticular parts of the security mechanisms and functions provided by the TOE are tested. 6.2 Definition of FPT_TST.2 The functional component “Subset TOE security testing (FPT_TST.2)” has been newly created (Common Criteria Part2 extended). This component allows thatparticular parts of the security mechanisms and functions provided by the TOE can be tested after TOE Delivery or are tested automatically and continuously duringnormal operation transparentfor the user. This security functional component is used instead of the functional component FPT_TST.1 from Common Criteria Part2. For the user it is importantto know which security functions or mechanisms can be tested. The functional component FPT_TST.1 does not mandate to explicitly specify the security functions beingtested. In addition,FPT_TST.1 requires verifyingthe integrity of TSF data and stored TSF executable code which might violatethe security policy. The functional component “Subset TOE testing (FPT_TST.2)” is specified as follows (Common Criteria Part2 extended). M7892 B11 Security Target Lite Public Security Target Lite 43 2015-10-13 6.3 TSF self test (FPT_TST) Family Behavior The Family Behavior is defined in [3] section 15.14 (442, 443). Component leveling FPT_TST TSF self test 1 2 FPT_TST.1 The component FPT_TST.1 is defined in [3] section 15.14 (444, 445, 446). FPT_TST.2 Subset TOE security testing, provides the ability to test the correct operation of particular security functions or mechanisms. These tests may be performed at start-up, periodically, at the request of the authorized user, or when other conditions are met. It also provides the ability to verify the integrity of TSF data and executable code. Management: FPT_TST.2 The followingactions could beconsidered for the management functions in FMT:  Management of the conditions under which subset TSF self testing occurs,such as duringinitial start-up,regular interval or under specified conditions  Management of the time of the interval appropriate. Audit: FPT_TST.2 There are no auditable events foreseen. FPT_TST.2 Subset TOE testing Hierarchical to No other components. Dependencies: No dependencies. FPT_TST.2.1 The TSF shall run a suite of self tests [selection: during initial start-up, periodically during normal operation, at the request of the authorized user, and/or at the conditions [assignment:conditions under which self test should occur]] to demonstrate the correct operation of [assignment: functions and/or mechanisms]. M7892 B11 Security Target Lite Public Security Target Lite 44 2015-10-13 6.4 Family “Generation of Random Numbers (FCS_RNG)” The family “Generation of Random Numbers (FCS_RNG.1)” has to be newly created accordingthe new version of the “Anwendungshinweise und Interpretationen zum Schema (AIS)” respectively “Functionality classes and evaluation methodology for physical randomnumber generators”, AIS31, [5]. This security functional componentis used instead of the functional component FCS_RNG.1 defined in the protection profile[1]. The family “Generation of Random Numbers (FCS_RNG.1)” is specified as follows (Common Criteria Part2 extended). 6.5 Definition of FCS_RNG.1 This section describes the functional requirements for the generation of random numbers, which may be used as secrets for cryptographic purposes or authentication.The IT security functional requirements for the TOE are defined in an additional family (FCS_RNG) of the Class FCS (Cryptographic support). FCS_RNG Generationofrandom numbers Family Behavior This family defines quality requirements for the generation of randomnumbers that are intended to be used for cryptographic purposes. Component leveling: Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here. Datei: (EvF) Error! No text of specified style in document. FCS_RNG: Generation of random numbers TSF self test 1 FCS_RNG.1 Generation of random numbers Requires that the random number generator implements defined security capabilities and thatthe randomnumbers meet a defined quality metric. Management: FCS_RNG.1 There are no management activities foreseen. Audit: FCS_RNG.1 There are no actions defined to be auditable. M7892 B11 Security Target Lite Public Security Target Lite 45 2015-10-13 FCS_RNG.1 Random number generation Hierarchical to No other components. Dependencies: No dependencies. FCS_RNG.1.1 The TSF shall provide a [selection: physical, non-physical true, deterministic, hybrid physical, hybrid deterministic] random number generator that implements: [assignment: list of security capabilities]. FCS_RNG.1.2 The TSF shall provide random numbers that meet [assignment: a defined quality metric]. Application Note 1: The functional requirement FCS_RNG.1 is a refinement of the FCS_RNG.1 defined in the Protection Profile[1] accordingto AIS31 [5]. M7892 B11 Security Target Lite Public Security Target Lite 46 2015-10-13 7 Security Requirements (ASE_REQ) For this section the PP [1] section 6 can be applied completely. 7.1 TOE Security Functional Requirements The security functional requirements (SFR) for the TOE aredefined and described in the PP [1] section 6.1 and in the followingdescription. The Table 15 provides an overview of the functional security requirements of the TOE, defined in the in PP [1] section 6.1. In the lastcolumn itis marked if the requirement is refined. The refinements are also valid for this ST. Table 15: Security functional requirements defined in PP [1] Security Functional Requirement Refined in PP [1] FRU_FLT.2 “Limited faulttolerance“ Yes FPT_FLS.1 “Failurewith preservation of securestate” Yes FMT_LIM.1 “Limited capabilities” No FMT_LIM.2 “Limited availability” No FAU_SAS.1 “Audit storage” No FPT_PHP.3 “Resistanceto physical attack” Yes FDP_ITT.1 “Basic internal transfer protection” Yes FPT_ITT.1 “Basic internal TSF data transfer protection Yes FDP_IFC.1 “Subset information flowcontrol” No The Table 16 provides an overview about the augmented security functional requirements, which are added additional to the TOE and defined in this ST. All requirements are taken from Common Criteria Part2 [3], with the exception of the requirement FPT_TST.2 and FCS_RNG, which are defined in this ST completely. Table 16: Augmented security functional requirements Security Functional Requirement FPT_TST.2 “Subset TOE security testing“ FDP_ACC.1 “Subset access control” FDP_ACF.1 “Security attribute based access control” FMT_MSA.1 “Management of security attributes” FMT_MSA.3 “Static attribute initialisation” FMT_SMF.1 “Specification of Management functions” FCS_COP.1 “Cryptographic support” M7892 B11 Security Target Lite Public Security Target Lite 47 2015-10-13 Security Functional Requirement FCS_CKM.1 “Cryptographic key management” FDP_SDI.1 “Stored data integrity monitoring FDP_SDI.2 “Stored data integrity monitoring and action” FCS_RNG.1 “Quality metric for randomnumbers” All assignments and selections of the security functional requirements of the TOE are done in PP [1] and in the following description. The above marked extended components FMT_LIM.1 and FMT_LIM.2 are introduced in PP [1] to define the ITsecurity functional requirements of the TOE as an additional family (FMT_LIM) of the Class FMT(Security Management). This family describes the functional requirements for the Test Features of the TOE. The new functional requirements were defined in the classFMTbecause this classaddresses themanagement of functions of the TSF. The additional componentFAU.SAS is introduced to define the security functional requirements of the TOE of the Class FAU (Security Audit). This family describes thefunctional requirements for the storage of auditdata and is described in the next chapter. The requirement FPT_TST.2 is the subset of TOE testing and originated in [3]. This requirement is given as the correct operation of the security functions is essential.TheTOE provides mechanisms to cover this requirement by the smartcard embedded software and/or by the TOE itself. 7.1.1 Extended Components FCS_RNG.1 and FAU_SAS.1 7.1.1.1 FCS_RNG To define the IT security functional requirements of the TOE an additional family (FCS_RNG) of the Class FCS (cryptographic support) is defined here. This family describes the functional requirements for random number generation used for cryptographic purposes. FCS_RNG.1 Random number generation Hierarchical to No other components. Dependencies: No dependencies. FCS_RNG.1 Random numbers generation Class PTG.2 according to [5] FCS_RNG.1.1 The TSF shall provide a physical random number generator that implements:  PTG.2.1 A total failure test detects a total failure of entropy source immediately when the RNG has started. When a total failure is detected, no random numbers will be output.  PTG.2.2 If a total failure of the entropy source occurs while the RNG is being operated, the RNG prevents the output of any internal random number that M7892 B11 Security Target Lite Public Security Target Lite 48 2015-10-13 depends on some raw random numbers that have been generated after the total failure of the entropy source.  PTG.2.3 The online test shall detect non-tolerable statistical defects of the raw random number sequence (i) immediately when the RNG has started, and (ii) while the RNG is being operated. The TSF must not output any random numbers before the power-up online test has finished successfully or when a defect has been detected.  PTG.2.4 The online test procedure shall be effective to detect non-tolerable weaknesses of the random numbers soon.  PTG.2.5 The online test procedure checks the quality of the raw random number sequence. It is triggered continuously. The online test is suitable for detecting non- tolerable statistical defects of the statistical properties of the raw random numbers within an acceptable period of time. FCS_RNG.1.2 The TSF shall provide numbers in the format 8- or 16-bit that meet:  PTG.2.6 Test procedure A, as defined in [5] does not distinguish the internal random numbers from output sequences of an ideal RNG.  PTG.2.7 The average Shannon entropy per internal random bit exceeds 0.997. Application Note 2: The functional requirement FCS_RNG.1 is a refinement of the FCS_RNG.1 defined in the Protection Profile[1] accordingto AIS31, [5]. The physical randomnumber generator implements total failuretest of the random sourceand a continuous RNG test accordingto followingstandard: National Instituteof Standards and Technology, Security Requirements for Cryptographic Modules,Federal Information ProcessingStandards Publication (FIPS) 140-2,2002-03-12,chapter 4.9.2. 7.1.1.2 FAU_SAS To define the security functional requirements of the TOE an additional family (FAU_SAS) of the Class FAU(Security Audit) is defined here. This family describes thefunctional requirements for the storageof auditdata.It has a more general approach than FAU_GEN, because itdoes not necessarily requirethe data to be generated by the TOE itself and because it does not give specific detailsof the content of the auditrecords. M7892 B11 Security Target Lite Public Security Target Lite 49 2015-10-13 The TOE shall meet the requirement “Audit storage(FAU_SAS.1)” as specified below(Common Criteria Part2 extended). FAU_SAS.1 Audit Storage Hierarchical to No other components. Dependencies: No dependencies. FAU_SAS.1.1 The TSF shall provide the test process before TOE Delivery with the capability to store the Initialization Data and/or Pre-personalization Data and/or supplements of the Security IC Embedded Software in the not changeable configuration page area and non- volatile memory. 7.1.2 Subset of TOE testing The security is strongly dependent on the correctoperation of the security functions.Therefore, the TOE shall support that particular security functions or mechanisms aretested in the operational phase(Phase7).The tests can be initiated by the Smartcard Embedded Software and/or by the TOE. The TOE shall meet the requirement “Subset TOE testing (FPT_TST.2)” as specified below(Common Criteria Part2 extended). FPT_TST.2 Subset TOE testing Hierarchical to No other components. Dependencies: No dependencies. FPT_TST.2.1 The TSF shall run a suite of self tests at the request of the authorised user to demonstrate the correct operation of the alarm lines and/or following environmental sensor mechanisms:  Pleaserefer to the confidential security target[10] 7.1.3 Memory access control Usage of multipleapplications in oneSmartcard often requires code and data separation in order to prevent that one application can accesscodeand/or data of another application.For this reason the TOE provides Area based Memory Access Control. The underlyingmemory management unit(MMU) is documented in section 4 of the hardware reference manual [6]. The security servicebeing provided is described in the Security Function Policy (SFP) Memory Access Control Policy. The security functional requirement “Subset access control (FDP_ACC.1)” requires that this policy is in placeand defines the scope were it applies.The security functional requirement “Security attribute based access control (FDP_ACF.1)” defines security attribute usageand characteristicsof policies.Itdescribes therules for the function that implements the Security Function Policy (SFP) as identified in FDP_ACC.1. The decision whether an access is permitted or not is taken based upon attributes allocated to the software. The Smartcard Embedded Software defines the attributes and memory areas.The M7892 B11 Security Target Lite Public Security Target Lite 50 2015-10-13 correspondingpermission control information isevaluated “on-the-fly” by the hardwareso that access is granted/effective or denied/inoperable. The security functional requirement “Static attribute initialization (FMT_MSA.3)” ensures that the defaultvalues of security attributes are appropriately either permissiveor restrictivein nature. Alternative values can be specified by any subjectprovided that the Memory Access Control Policy allows that.This is described by the security functional requirement “Management of security attributes (FMT_MSA.1)”. The attributes are determined duringTOE manufacturing(FMT_MSA.3) or set at run-time (FMT_MSA.1). From TOE’s pointof view the different roles in the Smartcard Embedded Software can be distinguished accordingto the memory based access control.However the definition of the roles belongs to the user software. The followingSecurity Function Policy (SFP) Memory Access Control Policy is defined for the requirement “Security attribute based access control (FDP_ACF.1)”: Memory Access Control Policy The TOE shall control read, write, delete and execute accesses of software running at the privilege levels as defined below. Any access is controlled, regardless whether the access is on code or data or a jump on any other privilege level outside the current one. The memory model provides distinct, independent privilege levels separated from each other in the virtual address space. More information is given in the confidential security target [10]. The TOE shall meet the requirement “Subset access control (FDP_ACC.1)” as specified below. FDP_ACC.1 Subset access control Hierarchical to No other components. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.1.1 The TSF shall enforce the Memory Access Control Policy on all subjects (software running at the defined and assigned privilege levels), all objects (data including code stored in memories) and all the operations defined in the Memory Access Control Policy, i.e. privilege levels. M7892 B11 Security Target Lite Public Security Target Lite 51 2015-10-13 The TOE shall meet the requirement “Security attribute based access control (FDP_ACF.1)” as specified below. FDP_ACF.1 Security attribute based access control Hierarchical to No other components. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization FDP_ACF.1.1 The TSF shall enforcethe Memory Access Control Policy to objects based on the following: Subject:  software runningat the IFX, OS1 and OS2 privilegelevels required to securely operate the chip.This includes also privilegelevels runninginterruptroutines.  software runningat the privilegelevels containingtheapplication software Object:  data includingcodestored in memories Attributes:  the memory area where the access is performed to and/or the operation to be performed. FDP_ACF.1.2 The TSF shall enforcethe followingrules to determine if an operation among controlled subjects and controlled objects is allowed: evaluate the corresponding permission control information of the relevant memory range before, during or after the access so that accesses to be denied can not be utilized by the subject attempting to perform the operation. FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none. FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none. M7892 B11 Security Target Lite Public Security Target Lite 52 2015-10-13 The TOE shall meet the requirement “Static attribute initialisation (FMT_MSA.3)” as specified below. FMT_MSA.3 Static attribute initialisation Hierarchical to No other components. Dependencies: FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1 The TSF shall enforce the Memory Access Control Policy to provide well defined 1 default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2 The TSF shall allow any subject, provided that the Memory Access Control Policy is enforced and the necessary access is therefore allowed 2 , to specify alternative initial values to override the default values when an object or information is created. The TOE shall meet the requirement “Management of security attributes (FMT_MSA.1)” as specified below: FMT_MSA.1 Management of security attributes Hierarchical to No other components. Dependencies: [FDP_ACC.1 Subset access control or FDP_IFC.1 Subset information flow control] FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MSA.1.1 The TSF shall enforce the Memory Access Control Policy to restrict the ability to change default, modify or delete the security attributes permission control information to the software running on the privilege levels. The TOE shall meet the requirement “Specification of management functions (FMT_SMF.1)” as specified below: FMT_SMF.1 Specification of management functions Hierarchical to No other components. Dependencies: No dependencies. FMT_SMF.1.1 The TSF shall be capable of performing the following security management functions: access the configuration registers of the MMU. 1 The staticdefinition oftheaccess rules is documented in [7] 2 The Smartcard Embedded Softwareis intended to setthememory access control policy M7892 B11 Security Target Lite Public Security Target Lite 53 2015-10-13 7.1.4 Support of Cipher Schemes The followingadditional specificsecurity functionality is implemented in the TOE: FCS_COP.1 Cryptographic operation requires a cryptographic operation to be performed in accordancewith a specified algorithmand with a cryptographic key of specified sizes.The specified algorithmand cryptographic key sizes can be based on an assigned standard;dependencies are discussed in Section 7.3.1.1. The followingadditional specificsecurity functionality is implemented in the TOE:  Advanced Encryption Standard (AES)  TripleData Encryption Standard (3DES)  Elliptic CurveCryptography (EC)  Rivest-Shamir-Adleman (RSA) 1  Secure Hash Algorithm (SHA-2) Note that the additional function of the EC library,providingtheprimitiveelliptic curveoperations,does not add specific security functionality. 7.1.4.1 Preface regarding Security Level related to Cryptography The strength of the cryptographic algorithms was notrated in the courseof the product certification (see[27] Section 9, Para.4,Clause2).But cryptographic functionalities with a security level of lower than 100 bits can no longer be regarded as securewithout consideringthe application context.Therefore, for these functions itshall bechecked whether the related cryptographic operations areappropriatefor the intended system. Some further hints and guidelines can be derived from the “Technische RichtlinieBSI TR-02102”, www.bsi.bund.de. Any cryptographic functionality thatis marked in the column “Security level above 100 Bits”of the followingtablewith a “no” achieves a security level of lower than 100 Bits (in general context). 1 For the casetheTOEcomes without RSA and/orEC library, the TOE provides basicHW-relatedroutines for RSAand/orEC calculations. For a secure library implementation theuser has to implement additional countermeasures himself. M7892 B11 Security Target Lite Public Security Target Lite 54 2015-10-13 Table 17: Cryptographic TOE functionality Cryptographic Mechanism Standard Key size in Bits Security level above 100 Bits ECDH [20] Key sizes correspondingto the used elliptic curves P-192, K-163 [17] and brainpool P{160,192}r1, brainpool P{160,192}t1 [18] No ECDH [21] Key sizes correspondingto the used elliptic curves P- {224, 256,384, 521}, K-{233, 409}, B-{233, 283,409} [17], brainpoolP{224,256,320,384,512}r1, brainpoolP{224,256,320,384,512}t1 [18] Yes ECDSA signaturegeneration / verification [25] Key sizes correspondingto the used elliptic curves P-192, K-163 [17] and brainpool P{160,192}r1, brainpool P{160,192}t1 [18] No ECDSA signaturegeneration / verification [26] Key sizes correspondingto the used elliptic curves P- {224, 256,384, 521}, K-{233, 409}, B-{233, 283,409} [17], brainpool P{224,256,320,384,512}r1,brainpool P{224,256,320,384,512}t1 [18]) Yes TDES [22] |k| = 112 No TDES [22] |k| = 168 Yes AES [23] |k| = 128, 192,256 Yes RSA encryption / decryption/ signaturegeneration / verification (only modular exponentiation part) [24] Modulus length = 1024 - 1975 No RSA encryption / decryption/ signaturegeneration / verification (only modular exponentiation part) [24] Modulus length = 1976 - 4096 Yes SHA-{256, 512} [19] None Yes Physical TrueRNG PTG.2 [5] n.a. n.a. M7892 B11 Security Target Lite Public Security Target Lite 55 2015-10-13 7.1.4.2 Triple-DES Operation The DES Operation of the TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)” as specified below. FCS_COP.1/DES Cryptographic operation 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 attributes, or FCS_CKM.1 Cryptographic key management] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/DES The TSF shall perform encryption and decryption in accordance with a specified cryptographic algorithm Triple Data Encryption Standard (3DES) and cryptographic key sizes of 2 x 56 bit or 3 x 56 bit, that meet the following standards: National Institute of Standards and Technology (NIST), Technology Administration, U.S. Department of Data Encryption Standard (DES), NIST Special Publication 800-67, Version 1.1 Note 6: The TOE implements the followingalternativeblock cipher modes for the user: the Electronic Codebook Mode (ECB), the Cipher Block ChainingMode (CBC), the BlindingFeedback Mode (BLD) and the Cipher Feedback Mode (CFB)1 The BLD is described in the hardwarereference manual [6] while the implementations of ECB, CBC and CFB followthe standard: National Instituteof Standards and Technology (NIST), Technology Administration,U.S. Department of Data Encryption Standard (DES), NIST Special Publication 800-38A,2001 Edition. This TOE can come with both crypto co-processors accessible,or with a blocked SCP or with a blocked Crypto2304T, or with both crypto co-processors blocked.The blockingdepends on the customer demands prior to the production of the hardware. In casethe SCP is blocked,no AES and 3DES computation supported by hardwareis possible.In casethe Crypto2304T is blocked,no RSA and EC computation supported by hardwareis possible.In case of a blocked Crypto2304T the optionally delivered cryptographic and the supportingToolbox and Base Library can not be used in that TOE product. The use of the SHA-2 library isalso possiblewith both crypto coprocessors blocked.No accessibility of the deselected cryptographic co-processorsiswithoutimpacton any other security policy of the TOE; itis exactly equivalentto the situation where the user decides justnot to use the cryptographic co-processors. End of note. 1 The CFB is alsocalled Recrypt Mode. M7892 B11 Security Target Lite Public Security Target Lite 56 2015-10-13 7.1.4.3 AES Operation The AES Operation of the TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)” as specified below. FCS_COP.1/AES Cryptographic operation 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 attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/AES The TSF shall perform encryption and decryption in accordance with a specified cryptographic algorithm Advanced Encryption Standard (AES) and cryptographic key sizes of 128 bit or 192 bit or 256 bit that meet the following standards: U.S. Department of Commerce, National Institute of Standards and Technology, Information Technology Laboratory (ITL), Advanced Encryption Standard (AES), FIPS PUB 197 Note 7: This TOE can come with both crypto co-processors accessible,or with a blocked SCP or with a blocked Crypto2304T, or with both crypto co-processors blocked.The blockingdepends on the customer demands prior to the production of the hardware. In casethe SCP is blocked,no AES and 3DES computation supported by hardwareis possible.In casethe Crypto2304T is blocked,no RSA and EC computation supported by hardwareis possible.In caseof a blocked Crypto2304T the optionally delivered cryptographic and the supportingToolbox and Base Library can not be used in that TOE product. The use of the SHA-2 library isalso possiblewith both crypto coprocessors blocked.No accessibility of the deselected cryptographic co-processorsiswithoutimpacton any other security policy of the TOE; itis exactly equivalent to the situation where the user decides justnot to use the cryptographic co-processors. Pleaseconsider also thestatement of chapter 7.1.4.1. End of note. M7892 B11 Security Target Lite Public Security Target Lite 57 2015-10-13 7.1.4.4 Rivest-Shamir-Adleman (RSA) operation The Modular Arithmetic Operation of the TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)” as specified below. FCS_COP.1/RSA Cryptographic operation 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 attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/RSA The TSF shall perform encryption and decryption in accordance with a specified cryptographic algorithm Rivest-Shamir-Adleman (RSA) and cryptographic key sizes 1024 - 4096 bits that meet the following standards Encryption: According to section 5.1.1 RSAEP in PKCS v2.1 RFC3447 without 5.1.1.1. Decryption (with or without CRT): According to section 5.1.2 RSADP in PKCS v2.1 RFC3447 for u = 2, i.e., without any (r_i, d_i, t_i), i >2, therefore without 5.1.2.2.b (ii)&(v), without 5.1.2.1. 5.1.2.2.a, only supported up to n < 2 2048 Signature Generation (with or without CRT): According to section 5.2.1 RSASP1 in PKCS v2.1 RFC3447 for u = 2, i.e., without any (r_i, d_i, t_i), i >2, therefore without 5.2.1.2.b (ii)&(v), without 5.2.1.1. 5.2.1.2.a, only supported up to n < 2 2048 Signature Verification: According to section 5.2.2 RSAVP1 in PKCS v2.1 RFC3447 without 5.2.2.1. Pleaseconsider also thestatement of chapter 7.1.4.1. M7892 B11 Security Target Lite Public Security Target Lite 58 2015-10-13 7.1.4.5 Rivest-Shamir-Adleman (RSA) key generation The key generation for the RSA shall meet the requirement “Cryptographic key generation (FCS_CKM.1)” FCS_CKM.1/RSA Cryptographic key generation Hierarchical to No other components. 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 FCS_CKM.1.1/RSA The TSF shall generatecryptographic keys in accordance with a specified cryptographic key generation algorithm rsagen1 (PKCS v2.1 RFC3447) and specified cryptographic key sizes of 1024 – 4096 bits that meet the following standard: According to section 3.2(2) in PKCS v2.1 RFC3447, for u=2, i.e., without any (r_i, d_i, t_i), i > 2. For p x q < 2 2048 additionally according to section 3.2(1). Note 8: For easy integration of RSA functions into the user’s operatingsystem and/or application,thelibrary containssingle cryptographic functions respectively primitives which arecompliantto the standard.The primitives arereferenced above. Therefore, the library supports theuser to develop an application representingthe standard if required. Pleaseconsider also thestatement of chapter 7.1.4.1. End of note. Note 9: The TOE can be delivered with or without the RSA library.If the TOE comes with, automatically theBase Library is partof the shipment. In the caseof coming without the RSA library the TOE does not providethe Additional Specific Security Functionality Rivest-Shamir-Adleman Cryptography (RSA) realized with the security functional requirements FCS_COP.1/RSA and FCS_CKM.1/RSA. In caseof a blocked Crypto2304T the optionally delivered cryptographic and the supportingToolbox and BaseLibrary can not be used in that TOE product. . End of note. 7.1.4.6 Generally with regard to Elliptic Curves The EC library isdelivered as objectcode and in this way integrated in the user software. The certification covers the standard NIST [17] and Brainpool [18] Elliptic Curves with key lengths of 160, 163, 192,224, 233, 256, 283, 320,384, 409, 512 or 521 bits,due to national AIS32 regulations by the BSI. Note that there are further uncounted side-channel secure curve types, which the user can optionally add in the composition certification process. M7892 B11 Security Target Lite Public Security Target Lite 59 2015-10-13 7.1.4.7 Elliptic Curve DSA (ECDSA) operation The Modular Arithmetic Operation of the TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)” as specified below. FCS_COP.1/ECDSA Cryptographic operation 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 attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/ECDSA The TSF shall perform signature generation and signature verification in accordance with a specified cryptographic algorithmECDSA and cryptographic key sizes of 160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 bits that meet the following standard: Signature Generation: 1. According to section 7.3 in ANSI X9.62 - 2005 Not implemented is step d) and e) thereof. The output of step e) has to be provided as input to our function by the caller. Deviation of step c) and f): The jumps to step a) were substituted by a return of the function with an error code, the jumps are emulated by another call to our function. 2. According to sections 6.2 (6.2.2. + 6.2.3) in ISO/IEC 15946-2:2002 Not implemented is section 6.2.1: The output of 5.4.2 has to be provided by the caller as input to the function. Signature Verification: 1. According to section 7.4.1 in ANSI X9.62–2005 Not implemented is step b) and c) thereof. The output of step c) has to be provided as input to our function by the caller. Deviation of step d): Beside noted calculation, our algorithm adds a random multiple of BasepointerOrder n to the calculated values u1 and u2. 2. According to sections 6.4 (6.4.1. + 6.4.3 + 6.4.4) in ISO/IEC 15946-2:2002 Not implemented is section 6.4.2: The output of 5.4.2 has to be provided by the caller as input to the function. M7892 B11 Security Target Lite Public Security Target Lite 60 2015-10-13 Note 10: For easy integration of EC functions into the user’s operating system and/or application,the library contains single cryptographic functions respectively primitives which arecompliantto the standard.The primitives arereferenced above. Therefore, the library supports theuser to develop an application representingthe standard if required. End of note. 7.1.4.8 Elliptic Curve (EC) key generation The key generation for the EC shall meet the requirement “Cryptographic key generation (FCS_CKM.1)” FCS_CKM.1/EC Cryptographic key generation Hierarchical to No other components. Dependencies: FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction FCS_CKM.1.1/EC The TSF shall generatecryptographic keys in accordance with a specified cryptographic key generation algorithm Elliptic Curve EC specified in ANSI X9.62-2005 and ISO/IEC 15946-1:2002 and specified cryptographic key sizes of 160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 bits that meet the following standard: ECDSA Key Generation: 1. According to the appendix A4.3 in ANSI X9.62-2005: The cofactor h is not supported. 2. According to section 6.1 (not 6.1.1) in ISO/IEC 15946-1:2002 Note 11: For easy integration of EC functions into the user’s operating system and/or application,the library contains single cryptographic functions respectively primitives which arecompliantto the standard.The primitives arereferenced above. Therefore, the library supports theuser to develop an application representingthe standard if required. End of note. M7892 B11 Security Target Lite Public Security Target Lite 61 2015-10-13 7.1.4.9 Elliptic Curve Diffie-Hellman (ECDH) key agreement The Modular Arithmetic Operation of the TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)” as specified below. FCS_COP.1/ECDH Cryptographic operation 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 attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1/ECDH The TSF shall perform elliptic curve Diffie-Hellman key agreement in accordance with a specified cryptographic algorithm ECDH and cryptographic key sizes 160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 bits that meet the following standard: 1. According to section 5.4.1 in ANSI X9.63 -2001 Unlike section 5.4.1.3 our, implementation not only returns the x-coordinate of the shared secret, but rather the x-coordinate and y-coordinate. 2. According to sections 8.4.2.1, 8.4.2.2, 8.4.2.3, and 8.4.2.4 in ISO/IEC 15946-3:2002: The function enables the operations described in the four sections. Note 12: The certification covers the standard NIST [17] and Brainpool [18] Elliptic Curves with key lengths of 160, 163,192, 224, 233, 256,283, 320, 384,409, 512 or 521 bits,due to national AIS32 regulations by the BSI. Note that there are further uncounted side-channel securecurvetypes, which the user can optionally add in the composition certification process. End of note Note 13: For easy integration of EC functions into the user’s operating system and/or application,the library contains single cryptographic functions respectively primitives which arecompliantto the standard.The primitives arereferenced above. Therefore, the library supports theuser to develop an application representingthe standard if required. End of note. Note 14: The TOE can be delivered with or without the EC library.If the TOE comes with, automatically theBaseLibrary is partof the shipment. In the casethe TOE comes without, it does not provide the Additional Specific Security Functionality Elliptic Curve Cryptography realized with the security functional requirements FCS_COP.1/ECSA, FCS_COP.1/ECDH and FCS_CKM.1/EC. In caseof a blocked Crypto2304T, the RSA and EC cryptographic library can notbe used. In caseof a blocked Crypto2304T the optionally delivered cryptographic RSAand EC, as well as the supportingToolbox and Base Library can not be used in that TOE product. End of note. M7892 B11 Security Target Lite Public Security Target Lite 62 2015-10-13 Note 15: The EC primitives allowthe selection of various curves.The selection of the curves depends to the user. End of note. 7.1.4.10 SHA-2 Operation The SHA-2 Operation of the TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)” as specified below. FCS_COP.1/SHA Cryptographic Operation 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 attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1/SHA The TSF shall perform hash-value calculation of user chosen data in accordance with a specified cryptographic algorithm SHA-2 and with cryptographic key sizes of none that meet the following standards: FIPS 180-4 as of 2015-08 [19] Note that the SHA-2 cryptographic operation is a keyless operation. In caseof a blocked Crypto2304T, the cryptographic libraries RSA, EC and Toolbox are not delivered, but the SHA library still can bepartof the TOE. Note 16: The TOE can be delivered without the SHA-2 library.In this casethe TOE does not providethe Additional Specific Security Functionality SHA-2 library,realized with the security functional requirements FCS_COP.1/SHA. End of note. Note 17: The secure hash-algorithmSHA-2 is intended to be used for signaturegeneration, verification and generic data integrity checks. The use for keyed hash operations likeHMAC or similarsecurity critical operationsinvolvingkeys,is notsubjectof this TOE and requires specific security improvements and DPA analysisincludingtheoperating system, which is not part of this TOE. End of note. M7892 B11 Security Target Lite Public Security Target Lite 63 2015-10-13 7.1.5 Data Integrity The TOE shall meet the requirement “Stored data integrity monitoring (FDP_SDI.1)” as specified below: FDP_SDI.1 Stored data integrity monitoring Hierarchical to No other components. Dependencies: No dependencies. FDP_SDI.1.1 The TSF shall monitor user data stored in containers controlled by the TSF for inconsistencies between stored data and corresponding EDC on all objects, based on the following attributes: EDC value for the RAM, ROM and SOLID FLASH™ NVM. The TOE shall meet the requirement “Stored data integrity monitoring and action (FDP_SDI.2)” as specified below: FDP_SDI.2 Stored data integrity monitoring and action Hierarchical to FDP_SDI.1 stored data integrity monitoring Dependencies: No dependencies. FDP_SDI.2.1 The TSF shall monitor user data stored in containers controlled by the TSF for data integrity and one- and/or more-bit-errors on all objects, based on the following attributes: corresponding EDC value for RAM, ROM and SOLID FLASH™ NVM and error correction ECC for the SOLID FLASH™ NVM. FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall correct 1 bit errors in the SOLID FLASH™ NVM automatically and inform the user about more bit errors. 7.2 TOE Security Assurance Requirements The evaluation assurancelevel is EAL6 augmented with ALC_FLR.1. In the followingtable,the security assurancerequirements are given. The augmentation of the assurancecomponents compared to the Protection Profile[1] is expressed with bold letters. M7892 B11 Security Target Lite Public Security Target Lite 64 2015-10-13 Table 18: Assurance components Aspect Acronym Description Refinement Development ADV_ARC.1 Security Architecture Description In PP [1] ADV_FSP.5 Complete semi-formal functional specification with additional error information in ST ADV_IMP.2 Complete mapping of the implementation representation of the TSF in ST ADV_INT.3 Minimally complex internals ADV_TDS.5 Complete semi-formal modular design ADV_SPM.1 Formal TOE security policy model Guidance Documents AGD_OPE.1 Operational user guidance in PP [1] AGD_PRE.1 Preparativeprocedures in PP [1] Life-Cycle Support ALC_CMC.5 Advanced support in ST ALC_CMS.5 Development tools CM coverage in ST ALC_DEL.1 Delivery procedures in PP [1] ALC_DVS.2 Sufficiency of security measures in PP [1] ALC_LCD.1 Developer defined life-cyclemodel ALC_TAT.3 Compliance with implementation standards – all parts ALC_FLR.1 Basic Flaw Remediation Security Target Evaluation ASE_CCL.1 Conformance claims ASE_ECD.1 Extended components definition ASE_INT.1 ST introduction ASE_OBJ.2 Security objectives ASE_REQ.2 Derived security requirements ASE_SPD.1 Security problem definition ASE_TSS.1 TOE summary specification Tests ATE_COV.3 Rigorous analysis of coverage In ST ATE_DPT.3 Testing: modular design ATE_FUN.2 Ordered functional testing ATE_IND.2 Independent testing - sample Vulnerability Assessment AVA_VAN.5 Advanced methodical vulnerability analysis in PP [1] M7892 B11 Security Target Lite Public Security Target Lite 65 2015-10-13 7.2.1 Refinements Some refinements aretaken unchanged from the PP [1]. In some cases a clarification is necessary.In the table above an overview is given where the refinement is done. The refinements from the PP [1] have to be discussed here in the Security Target, as the assurancelevel is increased.The refinements from the PP [1] are included in the chosen assurancelevel EAL 6 augmented with ALC_FLR.1. 7.2.1.1 Development (ADV) ADV_IMP Implementation Representation: The refined assurancepackageADV_IMP.1 implementation representation of the TSF requires the availability of the entire implementation representation, a mapping of the design description to the implementation representation with a level of detail that the TSF can be generated without further design decisions.In addition,thecorrespondence of design description and implementation representation shall bedemonstrated. The covered higher assurancepackageADV_IMP.2 requires a complete and not curtailed mappingof the implementation representation of the TSF, and the mappingof the design description to the entire implementation representation. In addition,the correspondenceof design description and the implementation representati on shall bedemonstrated. The ADV_IMP.1 aspectand refinement remains therefore valid.The enhancement underlines the refinement in the PP [1] and by that the entirely complete design i.e. not curtailed representation with accordingmappingwas provided, demonstrated and reviewed. ADV_INT TSF Internals: The assurancepackageADV_INT.2 well-structured internals isextended to ADV_INT.3 minimally complex internals requiringthe documentation to minimally complex internals with the intension that the entire TSF has been designed and implemented usingsound engineering principles.The ADV_INT.2 aspectremains applicableas well structured internals are fundamental for achievingsound engineering principles.ADV_INT.2 and its refinements in the PP [1] remain therefore valid.The assuranceand evidencewas provided accordingly. ADV_FSP Functional Specification: The ADV_FSP.4 packagerequires a functional description of the TSFIs and there assignmentto SFR-enforcing, SFR- supporting,SFR-non-interfering, including related error messages,the assurancepackage.The enhancement of ADV_FSP.5 requires additionally a completesemi-formal functional specification with additional error information.In addition the package includes a tracingfromthe functional specification to the SFRs, as well as the TSFIs descriptions includingerror messages not resultingfroman invocation of a TSFI. These aspects from ADV_FSP.5 are independent from the ADV_FSP.4 refinements from the PP [1] but constitute an enhancement of it. By that the aspects of ADV_FSP.4 and its refinement in the PP [1] apply also here. The assuranceand evidence was provided accordingly. ADV_SPM Formal Security Policy Model: It is the objective of this family to provideadditional assurancefromthe development of a formal security policy model of the TSF, and establishing a correspondence between the functional specification and this security policy model. M7892 B11 Security Target Lite Public Security Target Lite 66 2015-10-13 Preservinginternal consistency thesecurity policy model is expected to formally establish the security principles from its characteristics by means of a mathematical proof. The assurance and evidence was provided. ADV_SPM.1 Formal TOE security policy model Hierarchical to: No other components Dependencies: ADV_FSP.4 Complete function description ADV_SPM.1.1D The developer shall providea formal security policy model for the Memory Access Control Policy and the corresponding SFRs  FDP_ACC.1 Subset Access Control  FDP_ACF.1 Security attribute based access control  FMT_MSA.1 Management of Security Attributes  FMT_MSA.3 Static Attribute initialisation. Moreover, the following SFRs shall be addressed by the formal security policy model:  FDP_SDI.1 Stored data integrity monitoring  FDP_SDI.2 Stored data integrity monitoring and action  FDP_ITT.1 Basic Internal Transfer Protection  FDP_IFC.1 Information Flow Control  FPT_ITT.1 Basic internal TSF data transfer protection  FPT_PHP.3 Resistance to physical attack  FPT_FLS.1 Failure with preservation of secure state  FRU_FLT.2 Limited fault tolerance  FMT_LIM.1 Limited capabilities  FMT_LIM.2 Limited availability  FAU_SAS.1 Audit storage  FMT_SMF.1 Specification of Management Functions ADV_SPM.1.2D For each policy covered by the formal security policy model, the model shall identify the relevant portions of the statement of SFRs that make up that policy. ADV_SPM.1.3D The developer shall provide a formal proof of correspondence between the model and any formal functional specification. M7892 B11 Security Target Lite Public Security Target Lite 67 2015-10-13 ADV_SPM.1.4D The developer shall provide a demonstration of correspondence between the model and the functional specification. ADV_TDS TOE Design: The assurancepackageADV_TDS.4 Semiformal modular design is extended to ADV_TDS.5 Complete semiformal modular design requires the complete semiformal design description.As the package ADV_TDS.5 is an enhancement of ADV_TDS.4 the package and its refinements in the PP [1] remain valid.The assuranceand evidence was provided accordingly. 7.2.1.2 Life-cycle Support (ALC) ALC_CMS Configuration Management Scope: The Security IC embedded firmware and the optional softwareare partof TOE and delivered together with the TOE as the firmware and optional softwareare stored in the ROM and/or SOLID FLASH™ NVM. The presence of the optional parts belongs to the user order. Both, the firmware and software delivered with the TOE are controlled entirely by Infineon Technologies. In addition,the TOE offers the possibility thatthe user can download his softwareat his own premises. These parts of the software are user controlled only and are not partof this TOE. The download of this solely user controlled software into the SOLID FLASH™ NVM is protected by strong authentication means. In addition,the download itself could also beencrypted. By the augmentation of ALC_CMS.4 to ALC_CMS.5 the configuration listincludes additional the development tools. The packageALC_CMS.5 is therefore an enhancement to ACL_CMS.4 and the packagewith its refinement in the PP [1] remains valid.The assuranceand evidence was provided accordingly. ALC_CMC Configuration Management Capabilities: The PP [1] refinement from the assurancepackageALC_CMC.4 Production support,acceptance procedures and automation points out that the configuration items compriseall items defined under ALC_CMS to be tracked under configuration management. In addition a production control systemis required guaranteeing the traceability and completeness of different charges and lots.Also the number of wafers, dies and chips must be tracked by this system as well as procedures applied for managingwafers, dies or complete chips beingremoved from the production process in order to verify and to control predefined quality standardsand production parameters.Ithas to be controlled that these wafers, dies or assembled devices arereturned to the same production stage from which they aretaken or they have to be securely stored or destroyed otherwise. The additionally covered extended packageof ALC_CMC.5 Advance Support requires advanced supportconsideringthe automatisms configuration management systems, acceptance and documentation procedures of changes, roleseparation with regard to functional roles of personnel,automatisms for trackingand version controllingin thosesystems , and includes also production control systems.The additional aspects of ADV_CMC.5 constitute an enhancement of ACL_CMC.4 and therefore the aspects and ACL_CMC.4 refinements in the PP [1] remain valid.The assuranceand evidence was provided. ALC_DVS Development Security: The assurancepackageALC_DVS.1 identification of security measures is extended to ALC_DVS.2 requiringthe evidence of sufficiency of security measures.The evidence was given and reviewed that the design and implementation and its M7892 B11 Security Target Lite Public Security Target Lite 68 2015-10-13 development environment is protected with regard to confidentiality and integrity.The ALC_DVS.2 package is an enhancement of ALC_DVS.1. Therefore, this packageand its refinement in the PP [1] remain valid.The assuranceand evidence was provided accordingly. ALC_TAT Tools and Techniques: The assurancepackageALC_TAT.2 Compliancewith implementation standards isextended to ALC_TAT.3 Compliancewith implementation standards - all parts requiringthatall implemented parts arecompliantto implementation standards. The evidence has been given that all parts havebeen developed and implemented accordingto implementation standards,processes and rules. 7.2.1.3 Tests (ATE) ATE_COV Test Coverage: The PP [1] refined assurancepackageATE_COV.2 Analysisof coverage addresses the extent to which the TSF is tested, and whether or not the testing is sufficiently extensiveto demonstrate that the TSF operates as specified.Itincludes the test documentation of the TSFIs in the functional specification.In particulartherefinement requires that The TOE must be tested under different operating conditions within the specified ranges.In addition,the existence and effectiveness of mechanisms againstphysical attacksshould becovered by evidence that the TOE has the particularphysical characteristics.This is furthermoredetailed in the PP [1]. This assurancepackageATE_COV.2 has been enhanced to ATE_COV.3 to cover the rigorous analysisof coverage. This requires the presence of evidence that exhaustivetesting on rigorous entirely all interfaces as documented in the functional specification was conducted.By that ATE_COV.2 and refinements as given in the PP [1] are enhanced by ATE_COV.3 and remain as well.The TSFIs were completely tested accordingto ATE_COV.3 and the assuranceand evidence was provided. ATE_FUN Functional Tests: The assurancepackageATE_FUN.1 Functional testingis extended to ATE_FUN.2 Ordered functional testingrequiring which means to includeconsiderations of dependency aspects.The packageATE_FUN.2 is an enha ncement to ATE_FUN.1 in terms of describingdependencies and sequences of the functional testingdocumented with ATE_FUN.1. Therefor e, the refinements in the PP [1] remain valid.The testing systems, processes and toolinghavebeen analyzed and reviewed wi th regard to intrinsicdependencies. AVA_VAN Vulnerability Analysis: The assurancepackageAVA_VAN remains unchanged compared to the forerunner processes and requires advanced methodical vulnerability analysis. 7.3 Security Requirements Rationale 7.3.1 Rationale for the Security Functional Requirements The security functional requirements rationaleof the TOE are defined and described in PP [1] section 6.3 for the following security functional requirements: FDP_ITT.1, FDP_IFC.1, FPT_ITT.1, FPT_PHP.3, FPT_FLS.1, FRU_FLT.2, FMT_LIM.1, FMT_LIM.2, FCS_RNG.1, and FAU_SAS.1. M7892 B11 Security Target Lite Public Security Target Lite 69 2015-10-13 The security functional requirements FPT_TST.2, FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3, FMT_SMF.1, FCS_COP.1, FCS_CKM.1, FDP_SDI.1 and FDP_SDI.2 are defined in the followingdescription: Table 19: Rational for additional SFR in the ST Objective TOE Security Functional Requirements O.Add-Functions - FCS_COP.1/DES „Cryptographic operation“ - FCS_COP.1/AES „Cryptographic operation“ - FCS_COP.1/SHA „Cryptographic operation“ - FCS_COP.1/RSA „Cryptographic operation“ - FCS_COP.1/ECDSA „Cryptographic operation“ - FCS_COP.1/ECDH „Cryptographic operation“ - FCS_CKM.1/RSA „Cryptographic key generation “ - FCS_CKM.1/EC „Cryptographic key generation“ O.Phys-Manipulation - FPT_TST.2 „ Subset TOE security testing “ O.Mem-Access - FDP_ACC.1 “Subset access control” - FDP_ACF.1 “Security attribute based access control” - FMT_MSA.3 “Static attribute initialisation” - FMT_MSA.1 “Management of security attributes” - FMT_SMF.1 “Specification of Management Functions” O.Malfunction - FDP_SDI.1 „Stored data integrity monitoring“ - FDP_SDI.2 „Stored data integrity monitoringand action“ The table above gives an overview, how the security functional requirements are combined to meet the security objectives.The detailed justification is given in the following: The justification related to the security objective “Additional Specific Security Functionality (O.Add-Functions)”is as follows: The security functional requirement(s) “Cryptographic operation (FCS_COP.1)” exactly requires those functions to be implemented which are demanded by O.Add-Functions. FCS_CKM.1/RSA supports the generation of RSA keys, the FCS_CKM.1/EC supports the generation of EC keys needed for this cryptographic operations.Therefore, FCS_COP.1/RSA, FCS_COP.1/ECDSA, FCS_COP.1/ECDH and FCS_CKM.1/RSA and FCS_CKM/EC are suitableto meet the security objective. The FCS_COP.1/SHA is a keyless algorithmand has no dependencies to FCS_CKM.1. The use of the supportinglibraries Toolbox and Basehas no impacton any security functional requirement nor does the use generate additional requirements. Nevertheless, the developer of the Smartcard Embedded Software must ensure that the additional functions areused as specified and that the User Data processed by these functions areprotected as defined for the application context.These issues areaddressed by the specific security functional requirements: M7892 B11 Security Target Lite Public Security Target Lite 70 2015-10-13  [FDP_ITC.1 Import of user data without security attributes or FDP_ITC.2 Import of user data with security attributes or FCS_CKM.1 Cryptographic key generation],  FCS_CKM.4 Cryptographic key destruction, All these requirements have to be fulfilled to support OE.Resp-Appl for FCS_COP.1/DES (3DES algorithm) and for FCS_COP.1/AES (AES algorithm).For the FCS_COP.1/RSA (RSA algorithm) and FCS_COP.1/ECDSA and FCS_COP.1/ECDH (both EC algorithms) the FCS_CKM.1/RSA and FCS_CKM.1/EC are optional,sincethey arefulfilled by the TOE or may be fulfilled by the environment as the user can generate keys externally additionally. The security functional requirements required to meet the security objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction,O.Phys-Manipulation and O.Leak-Forced define how to implement the specific security functionality. However, key-dependent functions could be implemented in the Smartcard Embedded Software. The usage of cryptographic algorithms requires the useof appropriatekeys.Otherwise these cryptographic functions do not providesecurity.The keys have to be unique with a very high probability,and musthave a certain cryptographic strength etc. In caseof a key import into the TOE (which is usually after TOE delivery) ithas to be ensured that quality and confidentiality aremaintained.Keys for 3DES and AES are provided by the environment. Keys for RSA and EC algorithms can be provided either by the TOE or the environment. In this ST the objectives for the environment OE.Plat-Appl and OE.Resp-Appl have been clarified.The Smartcard Embedded Software defines the use of the cryptographic functions FCS_COP.1 provided by the TOE. The requirements for the environment FDP_ITC.1, FDP_ITC.2, FCS_CKM.1 and FCS_CKM.4 supportan appropriatekey management. These security requirements are suitableto meet OE.Resp-Appl. The justification of the security objective and the additional requirements (both for the TOE and its environment) show that they do not contradictto the rationalealready given in the Protection Profilefor the assumptions,policy and threats defined there. The security functional component Subset TOE security testing(FPT_TST.2) has been newly created (Common Criteria Part2 extended). This component allows thatparticular parts of the security mechanisms and functions provided by the TOE can be tested after TOE Delivery. This security functional component is used instead of the functional component FPT_TST.1 from Common Criteria Part2. For the user it is importantto know which security functions or mechanisms can be tested. The functional component FPT_TST.1 does not mandate to explicitly specify the security functions beingtested. In addition,FPT_TST.1 requires verification of the integrity of TSF data and stored TSF executable code which might violatethe security policy. The tested security enforcingfunctions areSF_DPM Device PhaseManagement, SF_CS Cryptographic Support and SF_PMA Protection againstmodifyingattacks. The security functional requirement FPT_TST.2 will detect attempts to conduce a physical manipulation on the monitoring functions of the TOE. The objective of FPT_TST.2 is O.Phys-Manipulation.The physical manipulation will betried to overcome security enforcingfunctions. The security functional requirement “Subset access control (FDP_ACC.1)” with the related Security Functi on Policy (SFP) “Memory Access Control Policy”exactly require the implementation of an area based memory access control as required M7892 B11 Security Target Lite Public Security Target Lite 71 2015-10-13 by O.Mem-Access. The related TOE security functional requirements FDP_ACC.1, FDP_ACF.1, FMT_MSA.3, FMT_MSA.1 and FMT_SMF.1 cover this security objective. The implementation of these functional requirements is represented by the dedicated privilegelevel concept. The justification of the security objective and the additional requirements showthat they do not contradictto the rationalealready given in the Protection Profilefor the assumptions,policy and threats defined there. Moreover, these additional security functional requirements cover the requirements by [3] user data protection of chapter 11 which are not refined by the PP [1]. Nevertheless, the developer of the Smartcard Embedded Software must ensure that the additional functions areused as specified and that the User Data processed by these functions areprotected as defined for the application context.The TOE only provides the tool to implement the policy defined in the context of the application. The justification related to the security objective “Protection againstMalfunction dueto Environmental Stress (O.Malfunction)”is as follows: The security functional requirement “Stored data integrity monitoring(FDP_SDI.1)” requires the implementation of an Error Detection (EDC) algorithmwhich detects integrity errors of the data stored in all memories.By this the malfunction of the TOE usingcorruptdata is prevented. Therefore FDP_SDI.1 is suitableto meet the security objective. The security functional requirement “Stored data integrity monitoringand action (FDP_SDI.2)” requires the implementation of an integrity observation and correction which is implemented by the Error Detection (EDC) and Error Correction (ECC) measures. The EDC is present throughout all memories of the TOE whilethe ECC is realized in the SOLID FLASH™ NVM. These measures detect and inform aboutone and more biterrors.In caseof the SOLID FLASH™ NVM 1 bit errors of the data are corrected automatically.By the ECC mechanisms itis prevented that the TOE uses corruptdata. Therefore FDP_SDI.2 is suitableto meet the security objective. The CC part 2 defines the component FIA_SOS.2, which is similar to FCS_RNG.1, as follows: FIA_SOS.2 TSF Generation of secrets Hierarchical to No other components. Dependencies: No dependencies. FIA_SOS.2.1 The TSF shall provide a mechanism to generate secrets that meet [assignment:a defined quality metric]. FIA_SOS.2.2 The TSF shall be able to enforce the use of TSF generated secrets for [assignment: list of TSF functions]. The CC part 2, annex G.3, [3], states: “This family defines requirements for mechanisms that enforce defined quality metrics on provided secrets, and generate secrets to satisfy thedefined metric“. Even the operation in the element FIA_SOS.2.2 allows listingthe TSF functions usingthe generated secrets.Because all applicationsdiscussed in annex G.3 are related to authentication,the component FIA_SOS.2 is also intended for authentication purposes whilethe term “secret” is not limited to authentication data (cf. CC part 2, paragraphs 39-42). M7892 B11 Security Target Lite Public Security Target Lite 72 2015-10-13 Paragraph 685 in the CC part 2, [3], recommends the use of the component FCS_CKM.1 to address r andomnumber generation. However, this may hidethe nature of the secrets used for key generation and does not allowdescribing random number generation for other cryptographic methods (e.g., challenges,padding),authentication (e.g., password seeds), or other purposes (e.g., blindingas a countermeasure againstsidechannel attacks). The component FCS_RNG addresses general RNG includingtheuse of but no limitation to cryptographic mechanisms. FCS_RNG allows specifyingrequirements for the generation of randomnumbers includingnecessary information for the intended use. These details describethe quality of the generated data where other security services rely on.Thus by using FCS_RNG a ST or PP author is ableto express a coherent set of SFRs that includeor use the generation of random numbers as a security service. 7.3.1.1 Dependencies of Security Functional Requirements The dependence of security functional requirements aredefined and described in PP [1] section 6.3.2 for the following security functional requirements: FDP_ITT.1, FDP_IFC.1, FPT_ITT.1, FPT_PHP.3, FPT_FLS.1, FRU_FLT.2, FMT_LIM.1, FMT_LIM.2, FCS_RNG.1 and FAU_SAS.1. The dependence of security functional requirements for the security functional requirements FPT_TST.2, FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3, FMT_SMF.1, FCS_COP.1, FCS_CKM.1, FDP_SDI.1 and FDP_SDI.2 are defined in the followingdescription. Table 20: Dependency for cryptographic operation requirement Security Functional Requirement Dependencies Fulfilled by security requirements FCS_COP.1/DES FCS_CKM.1 Yes, see comment 3 FDP_ITC.1 or FDP_ITC.2 (if not FCS_CKM.1) FCS_CKM.4 Yes, see comment 3 FCS_COP.1/AES FCS_CKM.1 Yes, see comment 3 FDP_ITC.1 or FDP_ITC.2 (if not FCS_CKM.1) FCS_CKM.4 Yes, see comment 3 FCS_COP.1/RSA FCS_CKM.1 Yes, see comment 3 FDP_ITC.1 or FDP_ITC.2 (if not FCS_CKM.1) FCS_CKM.4 Yes, see comment 3 FCS_CKM.1/RSA FCS_CKM.2 or FCS_COP.1 Yes FCS_CKM.4 Yes, see comment 3 FCS_COP.1/ECDSA FCS_CKM.1 Yes, see comment 3 FDP_ITC.1 or FDP_ITC.2 (if not FCS_CKM.1) FCS_CKM.4 Yes, see comment 3 FCS_CKM.1/EC FCS_CKM.2 or FCS_COP.1 Yes FCS_CKM.4 Yes, see comment 3 FCS_COP.1/ECDH FCS_CKM.1 Yes, see comment 3 M7892 B11 Security Target Lite Public Security Target Lite 73 2015-10-13 Security Functional Requirement Dependencies Fulfilled by security requirements FDP_ITC.1 or FDP_ITC.2 (if not FCS_CKM.1) FCS_CKM.4 Yes, see comment 3 FCS_COP.1/SHA No dependencies, see comment 4 Yes, see comment 3 FPT_TST.2 No dependencies, see comment 1 No, see comment 1 FDP_ACC.1 FDP_ACF.1 Yes FDP_ACF.1 FDP_ACC.1 FMT_MSA.3 Yes Yes FMT_MSA.3 FMT_MSA.1 FMT_SMR.1 Yes Not required, see comment 2 FMT_MSA.1 FDP_ACC.1 or FDP_IFC.1 FMT_SMR.1 FMT_SMF.1 Yes see comment 2 Yes FMT_SMF.1 None N/A FDP_SDI.1 None N/A FDP_SDI.2 None N/A Comment 1: The TOE is already a platformrepresenting the lowest level in a Smartcard.There is no lower or »underlyingabstract machine« used by the TOE which can be tested. Therefore, the former dependency to FPT_AMT.1 is fulfilled without further and by that dispensable.CC in the Revision 3 considered this and dropped this dependency. The requirement FPT_TST.2 is satisfied. End of comment. Comment 2: The dependency FMT_SMR.1 introduced by the two components FMT_MSA.1 and FMT_MSA.3 is considered to be satisfied becausethe access control specified for the intended TOE is not role-based but enforced for each subject. Therefore, there is no need to identify roles in form of a security functional requirement FMT_SMR.1. End of comment. Comment 3: The security functional requirement “Cryptographic operation (FCS_COP.1)”, met by the TOE, has the following dependencies:  [FDP_ITC.1 Import of user data without security attributes,or  FDP_ITC.2 Import of user data with security attributes, or  FCS_CKM.1 Cryptographic key generation] M7892 B11 Security Target Lite Public Security Target Lite 74 2015-10-13  FCS_CKM.4 Cryptographic key destruction. The security functional requirement “Cryptographic key management (FCS_CKM)” met by the TOE, has the following dependencies:  [FCS_CKM.2 Cryptographic key distribution,or  FCS_COP.1 Cryptographic operation]  FCS_CKM.4 Cryptographic key destruction. These requirements all addresstheappropriatemanagement of cryptographic keys used by the specified cryptographic function and arenot partof the PP [1]. Most requirements concerningkey management shall befulfilled by the environment sincethe Smartcard Embedded Software is designed for a specific application contextand uses the cryptographic functions provided by the TOE. For the security functional requirement FCS_COP.1/DES and FCS_COP.1/AES the respective dependencies FCS_CKM.1, FCS_CKM.4 and FDP_ITC.1 or FDP_ITC.2 have to be fulfilled by the environment. That mean, that the environment shall meet the requirements FCS_CKM.1 and FCS_CKM.4 as defined in [3], section 10.1 and shall meet the requirements FDP_ITC.1 or FDP_ITC.2 as defined in [3], section 11.7. For the security functional requirement FCS_COP.1/RSA, FCS_COP.1/ECDSA and FCS_COP.1/ECDH the respective dependencies FCS_CKM.4 and FDP_ITC.1 or FDP_ITC.2 have to be fulfilled by the environment. That mean, that the environment shall meet the requirements FDP_ITC.1 or FDP_ITC.2 as defined in [3], section 11.7. The respective dependency FCS_CKM.1 has to be fulfilled by the TOE with the security functional requirement FCS_CKM.1/RSA (for FCS_COP.1/RSA) and FCS_CKM.1/EC (for FCS_COP.1/ECDSA and FCS_COP.1/ECDH) as defined in section 7.1.4. Additionally therequirement FCS_CKM.1 can be fulfilled by the environment as defined in [3], section 10.1. For the security functional requirement FCS_CKM.1/RSA and FCS_CKM.1/EC the respective dependency FCS_COP.1 is fulfilled by the TOE. The environment covers the respective dependency FCS_CKM.4. That mean, that the environment shall meet the requirement FCS_CKM.4 as defined in [3], section 10.1. The cryptographic libraries RSA,EC, SHA-2 and the Toolbox library aredelivery options.If one of the libraries RSA, EC and Toolbox or combination hereof aredelivered, the BaseLib is automatically partof it.Therefore the TOE ma y come with free combinations of or even without these libraries.In the caseof coming without one or any combination of the cryptographic libraries RSA,EC and SHA-2, the TOE does not providethe Additional Specific Security Functionality Rivest- Shamir-Adleman Cryptography (RSA) and/or Elliptic CurveCryptography (EC) and/or SHA-2. The Toolbox and Base Library are no cryptographic librariesand provideno additional specificsecurity functionality. In caseof a blocked Crypto2304T the optionally delivered cryptographic libraries and thesupportingToolbox and Base Libraries cannotbe used in that TOE product. The SHA-2 library iscomputed in the CPUs. Therefore the IT environment has to fulfill therequirements of this chapter depending if the TOE comes with or without a/the library/ies.In caseof a blocked Crypto2304T, the cryptographic librariesRSA and EC arenot delivered. End of comment. M7892 B11 Security Target Lite Public Security Target Lite 75 2015-10-13 Comment 4 The dependencies FCS_CKM.1 and FMT_CKM.4 are not required for the SHA-2 algorithm,becausethe SHA-2 algorithmis a keyless operation. So the environment is not obligated to meet certain requirements for key management. End of comment. 7.3.2 Rationale of the Assurance Requirements The chosen assurancelevel EAL6 is augmentation with the requirements comingfrom ALC_FLR.1. In Table18 the different assurancelevels areshown as well as the augmentations. The augmentations are in compliancewith the Protection Profile. An assurancelevel EAL6 with the augmentations ALC_FLR.1 is required for this type of TOE sinceitis intended to defend againsthighly sophisticated attacks without protective environment over a targeted longlifetime. Thereby, the TOE must withstand attackers with high attack potential, which is achieved by fulfillingthe assuranceclass AVA_VAN.5. In order to providea meaningful level of assuranceand thatthe TOE provides an adequate level of defense againstsuch high potential attacks,the evaluators haveaccess to all information regardingtheTOE includingtheTSF internals,the low level design and sourcecode includingthe testing of the modular design. Additionally themandatory technical document “Application of Attack Potential to Smartcards”[16] shall betaken as a basis for the vulnerability analysisof the TOE. Due to the targeted longlifetime of the Infineon Technologies products,a comprehensive flaw remediation process and databaseis in placeto maintain the TOE also in future. Reported flaws of any kind,meaning, regardless whether the flaws reported have a more directed towards quality,functional or security,aretracked by a dedicated databasea nd related processes. And more, in order to continuously improvealso futureproducts reported flaws areanalyzed whether they could affect also future products.Due to its overall importancefor future development, the assuranceclass ALC_FLR.1 is included in this certification process. This evaluation assurancepackagewas selected to permit a developer gainingmaximumassurancefrompositivesecurity engineering based on good commercial practices as well as theassurancethatthe TOE is maintained during its targeted lifetime. The evaluation assurancepackagefollows theEAL6 assuranceclasses as given in [4]. 7.3.2.1 ALC_FLR.1 Basic Flaw Remediation Flaws of any kind are entered into a dedicated databasewith related processes to solvethose. At the point in time where a flawis entered, itis automatically logged who entered a flawand who is responsiblefor solvingit.In addition,itis also documented if, when and how an individual flawhas been solved. Flaws areprioritized and assigned to a responsibility. The assuranceclassALC_FLR.1 has no dependencies. M7892 B11 Security Target Lite Public Security Target Lite 76 2015-10-13 8 TOE Summary Specification (ASE_TSS) The product overview is given in section 2.1. In the followingthe Security Features are described and the relation to the security functional requirements is shown. The TOE is equipped with followingSecurity Features to meet the security functional requirements:  SF_DPM Device PhaseManagement  SF_PS Protection againstSnooping  SF_PMA Protection againstModification Attacks  SF_PLA Protection againstLogical Attacks  SF_CS Cryptographic Support The followingdescription of the Security Features is a complete representation of the TSF. 8.1 SF_DPM: Device Phase Management The lifecycleof the TOE is split-up in several phases.Chip development and production (phase2, 3, 4) and final use (phase4-7) is a rough split-up fromTOE point of view. These phases areimplemented in the TOE as test mode (phase 3) and user mode (phase 4-7). In addition a chip identification modeexists which is activein all phases.The chip identification data (O.Identification) is stored in a in the not changeableconfiguration pagearea and non-volatilememory. In the same area further TOE configuration data is stored.In addition,user initialization data can bestored in the non-volatilememory duringthe production phaseas well. Duringthis firstdata programming, the TOE is still in the secureenvironment and in Test Mode. The covered security functional requirement is FAU_SAS.1 “Audit storage”. Duringstart-up of the TOE the decision for one of the various operation modes is taken dependent on phaseidentifiers. The decision of accessinga certain mode is defined as phaseentry protection. The phases followalso a defined and protected sequence. The sequence of the phases is protected by means of authentication. The covered security functional requirements are FMT_LIM.1 and FMT_LIM.2. Duringthe production phase (phase3 and 4) or after the delivery to the customer (phase5 or phase6), the TOE provides the possibility to download,after a successful authentication process,a user specificencryption key and user code and data into the empty (erased) SOLID FLASH™ NVM area as specified by the associated control information of the Flash Loader software. This process is only possibleafter a successful authentication process.The integrity of the loaded data is checked with a signatureprocess.The data to be loaded may be transferred optionally in encrypted form. After finishing the load operation,the Flash Loader can be permanently deactivated, so that no further load operation with the Flash Loader is possible.These procedures aredefined as phaseoperation limitation. The covered security functional requirement is FPT_LIM.2 “Limited availability”. Duringoperation within a phasethe accesses to memories are granted by the MMU controlled access rights and related privilegelevel. The covered security functional requirements are FDP_ACC.1, FDP_ACF.1 and FMT_MSA.1. M7892 B11 Security Target Lite Public Security Target Lite 77 2015-10-13 In addition,duringeach start-up of the TOE the address ranges and access rights areinitialized by the STS with predefined values.The covered security functional requirementis FMT_MSA.3. The TOE clearly defines access rights and privilegelevels in conjunction with the appropriatekey management in dependency of the firmware or software to be executed. By this clearly defined management functions areimplemented, enforced by the MMU, and the covered security functional requirement is FMT_SMF.1. Duringthe testing phasein production within the secure environment the entire SOLID FLASH™ NVM is deleted. The covered security functional requirement is FPT_PHP.3. Each operation phaseis protected by means of authentication and encryption. The covered security functional requirements areFDP_ITT.1 and FPT_ITT.1. The SF_DPM “Device PhaseManagement” covers the security functional requirements FAU_SAS.1, FMT_LIM.1, FMT_LIM.2, FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3, FMT_SMF.1, FPT_PHP.3, FDP_ITT.1 and FPT_ITT.1. 8.2 SF_PS: Protection against Snooping All contents of all memories of the TOE areencrypted on chip to protect againstdata analysison stored data as well as on internally transmitted data.There is no plain data on the chip. In addition the data transferred over the busses, the SFRs and the peripheral devices (CRC, RNG and Timer) are encrypted as well. The memory content and bus encryption is done by the MED usinga complex key management and by the memories SOLID FLASH™ NVM, RAM, CACHE and the bus are entirely encrypted. Note that the ROM contains the firmware only and no user data. Therefore, no data in plain arehandled anywhere on the TOE and thus also the two CPUs compute entirely masked. The symmetric cryptographic co-processor isentirely masked as well. The encryption covers the data processingpolicy and FDP_IFC.1 “Subset information flowcontrol“. The covered security functional requirements are FPT_PHP.3, FDP_IFC.1, FPT_ITT.1 and FDP_ITT.1. The user can define his own key for an SOLID FLASH™ NVM area to protect his data.This user individually chosen key is then delivered by the operating system and included in the dynamic SOLID FLASH™ NVM encryption. The user specified SOLID FLASH™ NVM area is then encrypted with his key and another component. The encryption of the memories is performed by the memory encryption and decryption unitMED providingprotection againstcryptographicanalysis attacks.The keys which have to be stored on the chip areprotected againstread out. The covered security functional requirements are FPT_PHP.3, FDP_IFC.1, FPT_ITT.1, and FDP_ITT.1. The CPU has no standard command set and discloses therefore no possibility for deeper analysis.Thecovered security functional requirement is FPT_PHP.3. The entire design is kept in a non standard way to aggravateattacks usingstandard analysismethods to an almostnot practical condition.Aproprietary CPU with a non public bus protocol is implemented, which makes analysis very complicated and time consuming. Important parts of the chip areespecially designed to counter leakage or sidechannel attacks likeDPA/SPA or EMA/DEMA. Therefore, even the physical data gainingis difficultto perform, sincetimingand current consumption is almostindependent of the processed data,protected by a bunch of other protecting means. M7892 B11 Security Target Lite Public Security Target Lite 78 2015-10-13 In the design a number of components are automatically synthesized and mixed up to disguisetheir physical boarders and to make an analysis moredifficult. A further protective design method implements special routingmeasures againstprobing. The covered security functional requirements areFPT_PHP.3, FPT_ITT.1 and FDP_ITT.1. In addition to their protection duringprocessingof code and data their storage in the SOLID FLASH™ NVM is protected againstsidechannel attacks too:Even if users operate with direct and static addressingfor storingtheir secrets,the addresses arealways translated and modified.In addition the correctprivilegelevel is controlled by the MMU. The covered security functional requirements are FPT_PHP.3, FPT_ITT.1 and FDP_ITT.1. In contrastto the linear virtual address range,the physical SOLID FLASH™ NVM pages are transparently and dynamically scrambled.These measures causethat the physical location of data is differentfrom chip to chip.Even user software would always call the equal physical addresses. An observation of the clock is used to prevent the TOE from singlestepping. This is tested by the user mode security life control UMSLC. The covered security functional requirements are FPT_PHP.3 and FPT_FLS.1. An induced error which can not be corrected will berecognized by the Integrity Guard and leads to an alarm.In caseof security critical detections a security alarm and resetis generated. The covered security functional requirement is FPT_FLS.1. The SF_PS “Protection againstSnooping”covers the security functional requirements FPT_PHP.3, FDP_IFC.1, FPT_ITT.1, FDP_ITT.1 and FPT_FLS.1. 8.3 SF_PMA: Protection against Modifying Attacks Firstof all wecan say that all security mechanisms effectiveagainstsnooping SF_PS apply also here sincea reasonable modification of data is almostimpossibleon dynamically encrypted, masked, scrambled,transparently relocated, randomized and topologically protected hardware. Due to this the covered security functional requirements are FPT_PHP.3, FDP_IFC.1, FPT_ITT.1, FDP_ITT.1 and FPT_FLS.1. The TOE is equipped with an error detection code (EDC) which covers the memory system of RAM, ROM and SOLID FLASH™ NVM and includes also theMED, MMU and the bus system. Thus introduced failures aredetected and in certain errors are also automatically corrected (FDP_SDI.2). In order to prevent accidental bitfaults duringproduction in the ROM, over the data stored in ROM an EDC valueis calculated (FDP_SDI.1). The covered security functional requirements are FRU_FLT.2, FPT_PHP.3, FDP_SDI.1 and FDP_SDI.2. If a user tears the card resultingin a power off situation duringa SOLID FLASH™ NVM programmi ng operation or if other perturbation is applied,no data or content loss occursand the TOE restarts power on. The SOLID FLASH™ NVM tearing savewrite functionality covers FPT_FLS.1 “Failurewith preservation of secure state” sinceif the programming was not successful,theold data arestill presentand valid,which ensures a secure state although a programming failureoccurred. This action includes also FDP_SDI.1 “Stored data integrity monitoring” as the new data to be programmed are checked for integrity and correct programming before the page with the old data becomes the new physical pagefor the next new M7892 B11 Security Target Lite Public Security Target Lite 79 2015-10-13 data. The covered security functional requirement is also FPT_PHP.3 “Resistanceto physical attack“, sincethese measures make itdifficultto manipulatethe write process of the SOLID FLASH™ NVM. The covered security functional requirements are FPT_FLS.1, FPT_PHP.3 and FDP_SDI.1. The TOE is protected againstfaultand modifyingattacks.The core provides the functionality of double-computing and resultcomparison of all tasks to detect incorrectcalculations.The detection of an incorrectcalculation isstored and the TOE enters a defined secure state which causes the chip internal reset process. The implementation of two CPUs computing on the same data is by this one of the most important security features of this platform.As the results of both CPUs are compared at the end, a faultinduction of modifyingattacks would have to be done on both CPUs at the correct placewith the correct timing – despite all other countermeasures likedynamic masking,encryption and others. As the comparison and the register files arealso protected by various measures successful manipulativeattacks areseen as being not practical. Duringstartup, the STS performs various configurationsand subsystemtests. After the STS has finished,the operating system or application can call theUser Mode Security Life Control (UMSLC) test. The UMSLC checks the alarmlines and number of functions and sensors for correct operation. This test can be released actively by the user software duringnormal chip operation atany time. In the casethat a physical manipulation or a physical probingattack is detected, the processingof the TOE is immediately stopped and the TOE enters a secure state called security reset. The covered security functional requirements are FPT_FLS.1, FPT_PHP.3 and FPT_TST.2. As physical effects or manipulativeattacks may also addresstheprogram flow of the user software, a watchdog timer and a check point register areimplemented. These features allowthe user to check the correct processingtimeand the integrity of the program flowof the user software. Another measure againstmodifyingand perturbation respectively differential faultattacks (DFA) is the implementation of backward calculation in the SCP. By this induced errors arediscovered. The covered security functional requirements are FPT_FLS.1, FDP_IFC.1, FPT_ITT.1, FDP_ITT.1 and FPT_PHP.3. The RMS provides the user also the testing of all security features enabled to generate an alarm.This security testingis called user mode security lifecontrol (UMSLC). As attempts to modify the security features will be detected from the test, the covered security functional requirement is FPT_TST.2. All communication via the busses is in addition protected by a monitored hardwarehandshake.If the handshakewas not successful an alarmis generated. The covered security functional requirements are FPT_FLS.1 and FPT_PHP.3. The virtual memory system and privilege level model are enforced by the MMU. This controls the access rights throughout the TOE. There is a clear differentiation within the privilegelevels defined. The covered security functional requirements areFDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3 and FMT_SMF1. The SF_PMA “Protection againstModifyingAttacks”covers the security functional requirements FPT_PHP.3, FDP_IFC.1, FPT_ITT.1, FDP_ITT.1, FMT_MSA.1, FMT_MSA.3, FMT_SMF.1, FDP_ACC.1, FDP_ACF.1, FRU_FLT.2, FPT_TST.2, FDP_SDI.1, FDP_SDI.2 and FPT_FLS.1. M7892 B11 Security Target Lite Public Security Target Lite 80 2015-10-13 8.4 SF_PLA: Protection against Logical Attacks The memory access control of the TOE uses a memory management unit (MMU) to control the access to the available physical memory by usingvirtual memory addresses and to segregate the code and data to a privil egelevel model. The MMU controls the address permissions of the privileged levels and gives the software the possibility to define different access rights.The address permissionsof the privilegelevels arecontrolled by the MMU. In caseof an access violation the MMU will trigger a reset and then a trap serviceroutinecan reacton the access violation.The policy of setting up the MMU and specifyingthe memory ranges,to a certain extend, for the privilegelevels – with the exception of the IFX level - is defined from the user software (OS). As the TOE provides supportfor separation of memory areas the covered security functional requirements are FDP_ACC.1 “Subset access control”,FDP_ACF.1 “Security attribute based access control”,FMT_MSA.3 “Static attribute initialization”, FMT_MSA.1 “Management of security attributes”and FMT_SMF.1 “Specification of Management functions”. The TOE provides the possibility to protect the property rights of user code and data by the encryption of the SOLID FLASH™ NVM areas with a specific key defined by the user. Due to this key management FDP_ACF.1 is fulfilled.In addition,all memories present on the TOE are individually encrypted usingindividual keys assigned by complex key management. All data areprotected by means of encryption or maskingalso duringtransportation viathebusses. Induced errors arerecognized by the Integrity Guard concept and lead to an alarm.In caseof security critical errors a security alarmis generated and the TOE ends up in a secure state. The covered security functional requirements are FPT_PHP.3, FDP_ITT.1, FDP_IFC.1 and FPT_FLS.1. Beside the access protection and key management, also the use of illegal operation codeis detected and will releasea security reset. The SF_PLA “Protection againstLogical Attacks”covers the security functional requirements FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3, FPT_PHP.3, FDP_ITT.1, FDP_IFC.1, FPT_FLS.1 and FMT_SMF.1. 8.5 SF_CS: Cryptographic Support The TOE is equipped with several hardwareaccelerators and softwaremodules to supportthe standard symmetric and asymmetric cryptographic operations.This security function is introduced to includethe cryptographic operation in the scope of the evaluation as the cryptographic function respectively mathematic algorithmitself is notused from the TOE security policy.On the other hand these functions areof special interestfor the use of the hardwareas platformfor the software. The components are a co-processor supportingthe DES and AES algorithms and a combination of a co- processor and software modules to supportRSA cryptography, RSA key generation, ECDSA signaturegeneration and verification,ECDH key agreement and EC public key calculation and publi ckey testing. 8.5.1 3DES The TOE supports the encryption and decryption in accordancewith the specified cryptographic algorithmTripleData Encryption Standard (3DES) with cryptographic key sizes of 112 bitor 168 bit meeting the standard: National Instituteof Standards and Technology (NIST), Technology Administration,U.S. Department of Data Encryption Standard (DES), NIST Special Publication 800-67,Version 1.1. M7892 B11 Security Target Lite Public Security Target Lite 81 2015-10-13 The TOE implements the followingalternativeblock cipher modes for the user: the Electronic Codebook Mode (ECB), the Cipher Block ChainingMode (CBC), the BlindingFeedback Mode (BLD) and the Cipher Feedback Mode (CFB). The BLD is described in the hardwarereference manual [6] while the implementations of ECB, CBC and CFB followthe standard: National Instituteof Standards and Technology (NIST), Technology Administration,U.S. Department of Data Encryption Standard (DES), NIST Special Publication 800-38A,2001 Edition. Pleaseconsider also thestatement of chapter 7.1.4.1. The covered security functional requirements are FCS_COP.1/DES. 8.5.2 AES The TOE supports the encryption and decryption in accordancewith the specified cryptographic algorithmAdvanced Encryption Standard (AES) and cryptographic key sizes of 128 bitor 192 bit or 256 bit that meet the standard: U.S. Department of Commerce, National Instituteof Standards and Technology, Information Technology Laboratory (ITL), Advanced Encryption Standard (AES), FIPS PUB 197. Pleaseconsider also thestatement of chapter 7.1.4.1. The covered security functional requirement is FCS_COP.1/AES. 8.5.3 RSA Encryption, Decryption, Signature Generation and Verification The TSF shall performencryption and decryption in accordancewith a specified cryptographic algorithmRivest-Shamir- Adleman (RSA) and cryptographic key sizes 1024 - 4096 bits that meet the followingstandards Encryption: According to section 5.1.1 RSAEP in PKCS v2.1 RFC3447, without 5.1.1.1. Decryption (with or without CRT): According to section 5.1.2 RSADP in PKCS v2.1 RFC3447 for u = 2, i.e., without any (r_i, d_i, t_i), i >2, therefore without 5.1.2.2.b (ii)&(v), without 5.1.2.1. 5.1.2.2.a, only supported up to n < 2 2048 Signature Generation (with or without CRT): According to section 5.2.1 RSASP1 in PKCS v2.1 RFC3447 for u = 2, i.e., without any (r_i, d_i, t_i), i >2, therefore without 5.2.1.2.b (ii)&(v), without 5.2.1.1. 5.2.1.2.a, only supported up to n < 2 2048 Signature Verification: According to section 5.2.2 RSAVP1 in PKCS v2.1 RFC3447, without 5.2.2.1. Please consider also the statement of chapter 7.1.4.1. M7892 B11 Security Target Lite Public Security Target Lite 82 2015-10-13 Asymmetric Key Generation The TSF shall generatecryptographic keys in accordancewith a specified cryptographic key generation algorithm RSA specified in PKCS#1 v2.1 and specified cryptographic key sizes of 1024 – 4096 bits that meet the following standard: According to section 3.2(2) in PKCS v2.1 RFC3447, for u=2, i.e., without any (r_i, d_i, t_i), i > 2. For p x q < 22048 additionally according to section 3.2(1). Note 18: For easy integration of RSA functions into the user’s operatingsystem and/or application,thelibrary containssingle cryptographic functions respectively primitives which arecompliant to the standard.The primitives arereferenced above. Therefore, the library supports theuser to develop an application representingthe standard if required. Pleaseconsider also thestatement of chapter 7.1.4.1. End of note. The covered security functional requirement is FCS_COP.1/RSA and FCS_CKM.1/RSA. 8.5.4 Elliptic Curves EC The certification covers the standard NIST [17] and Brainpool [18] Elliptic Curves with key lengths of 160, 163,192, 224, 233, 256,283, 320, 384,409, 512 or 521 bits,due to national AIS32 regulations by the BSI. Note that there are further uncounted sidechannel securecurve types, which the user can optionally add in the composition certification process. Signature Generation and Verification The TSF shall performsignaturegeneration and signatureverification in accordancewith a specified cryptographic algorithmECDSA and cryptographic key sizes of 160, 163,192, 224,233, 256, 283,320, 384, 409,512 or 521 bits that meet the followingstandard: Signature Generation: 1. Accordingto section 7.3 in ANSI X9.62 - 2005 Not implemented is step d) and e) thereof. The output of step e) has to be provided as inputto our function by the caller. Deviation of step c) and f): The jumps to step a) were substituted by a return of the function with an error code, the jumps areemulated by another call to our function. 2. Accordingto sections 6.2 (6.2.2. + 6.2.3) in ISO/IEC 15946-2:2002 Not implemented is section 6.2.1: M7892 B11 Security Target Lite Public Security Target Lite 83 2015-10-13 The output of 5.4.2 has to be provided by the caller as inputto the function. Signature Verification: 1. Accordingto section 7.4.1 in ANSI X9.62–2005 Not implemented is step b) and c) thereof. The output of step c) has to be provided as inputto our function by the caller. Deviation of step d): Beside noted calculation,our algorithmadds a randommultipleof BasepointerOrder n to the calculated values u1 and u2. 2. Accordingto sections 6.4 (6.4.1. + 6.4.3 + 6.4.4) in ISO/IEC 15946-2:2002 Not implemented is section 6.4.2: The output of 5.4.2 has to be provided by the caller as inputto the function. Asymmetric Key Generation The TSF shall generatecryptographic keys in accordancewith a specified cryptographic key generation algorithmElliptic Curve EC specified in ANSI X9.62-1998 and ISO/IEC 15946-1:2002 and specified cryptographic key sizes 160,163,192, 224, 233, 256,283, 320, 384,409, 512 or 521 bits that meet the followingstandard: ECDSA Key Generation: 1. According to the appendix A4.3 in ANSI X9.62-2005 the cofactor h is not supported. 2. According to section 6.1 (not 6.1.1) in ISO/IEC 15946-1:2002 Asymmetric Key Agreement The TSF shall performellipticcurveDiffie-Hellman key agreement in accordancewith a specified cryptographic algorithm ECDH and cryptographic key sizes 160,163, 192, 224,233, 256,283, 320, 384,409, 512 or 521 bits that meet the followingstandard: 1. According to section 5.4.1 in ANSI X9.63 -2001 Unlike section 5.4.1.3 our, implementation not only returns the x-coordinate of the shared secret, but rather the x-coordinate and y-coordinate. 2. According to sections 8.4.2.1, 8.4.2.2, 8.4.2.3, and 8.4.2.4 in ISO/IEC 15946-3:2002: The function enables the operations described in the four sections. M7892 B11 Security Target Lite Public Security Target Lite 84 2015-10-13 Note 19: For easy integration of EC functions into the user’s operating system and/or application,the l ibrary contains single cryptographic functions respectively primitives which arecompliantto the standard.The primitives arereferenced above. Therefore, the library supports theuser to develop an application representingthe standard if required. End of note. The covered security functional requirements are FCS_COP.1/ECDSA, FCS_CKM.1/EC and FCS_COP.1/ECDH. 8.5.5 SHA-2 The TOE comes optionally with the SHA-2 library for hash valuecalculation.Regardingthe SHA-2 library ithas to be noted that the secure hash-algorithmSHA-2 is intended to be used for signaturegeneration, verification and generic data integrity checks.The use for keyed hash operations likeHMAC or similar security critical operationsinvolvingkeys,is not subjectof this TOE and requires specific security improvements and DPA analysisincludingtheoperating system, which is not partof this TOE. Nevertheless, followingis valid: The TSF shall performhash-valuecalculation of user chosen data in accordancewith a specified cryptographic al gorithm SHA-2 and with cryptographic key sizes of none that meet the followingstandards: U.S. Department of Commerce / National Institute of Standards and Technology, Secure Hash Standard (SHS), FIPS PUB 180-4,2012-March, section 6.2 SHA-256 and section 6.4 SHA-512. The covered security functional requirement is FCS_COP.1/SHA. 8.5.6 Toolbox Library The toolbox provides the followingbasic longinteger arithmetic and modular functions in software,supported by the cryptographic coprocessor:Addition,subtraction,division,multiplication,comparison,reduction,modular addition, modular subtraction,modular multiplication,modular inversion and modular exponentiation.No security relevantpolicy, mechanismor function is supported. The toolbox library is deemed for software developers as supportfor simplified implementation of long integer and modular arithmetic operations. The toolbox does not cover security functional requirements. 8.5.7 Base Library The Base Library provides the low level interface to the asymmetric cryptographic coprocessorand has no user available interface. The baselibrary does not provideany security functionality,implements no security mechanism, and does not provideadditional specificsecurity functionality. The Base Library does not cover security functional requirements and has no user interface. M7892 B11 Security Target Lite Public Security Target Lite 85 2015-10-13 8.5.8 PTRNG respectively TRNG Random data is essential for cryptography as well as for security mechanisms.The TOE is equipped with a physical True Random Number Generator (TRNG, FCS_RNG.1). The random data can be used from the Smartcard Embedded Software and is also used from the security features of the TOE, likemasking.The PTRNG or TRNG implements also self testing features. The PTRNG or TRNG meets the requirements of the functionality classPTG2 of the AIS31 [5]. The covered security functional requirement is FCS_RNG.1, FPT_PHP.3, FDP_ITT.1, FPT_ITT.1, FPT_TST.2 and FPT_FLS.1. The SF_CS “Cryptographic Support” covers the security functional requirements FCS_COP.1/DES, FCS_COP.1/AES, FCS_COP.1/RSA, FCS_CKM.1/RSA, FCS_COP.1/ECDSA, FCS_CKM.1/EC, FCS_COP.1/ECDH, FCS_COP.1/SHA, FPT_PHP.3, FDP_ITT.1, FPT_ITT.1, FPT_TST.2, FPT_FLS.1 and FCS_RNG.1. Note 20: The cryptographic libraries RSA,EC, SHA-2 and the Toolbox library aredelivery options.If one of the libraries RSA, EC and Toolbox or combination hereof aredelivered, the BaseLib is automatically partof it. Therefore the TOE may come with free combinations of or even without these libraries.In the caseof coming without one or any combination of the cryptographic libraries RSA,EC and SHA-2, the TOE does not providethe Additional Specific Security Functionality Rivest- Shamir-Adleman Cryptography (RSA) and/or Elliptic CurveCryptography (EC) and/or SHA-2. The Toolbox and Base Library are no cryptographic librariesand provideno additional specificsecurity functionality. End of note. Note 21: This TOE can come with both crypto co-processors accessible,or with a blocked SCP or with a blocked Crypto2304T, or with both crypto co-processors blocked.The blockingdepends on the customer demands prior to the production of the hardware. In casethe SCP is blocked,no AES and 3DES computation supported by hardwareis possible.In casethe Crypto2304T is blocked,no RSA and EC computation supported by hardwareis possible.The use of the SHA-2 library is also possiblewith both crypto coprocessors blocked.No accessibility of the deselected cryptographic co-processors is without impacton any other security policy of the TOE; it is exactly equivalentto the situation where the user decides just not to use the cryptographic co-processors. End of note. 8.6 Assignment of Security Functional Requirements to TOE’s Security Functionality The justification and overviewof the mapping between security functional requirements (SFR) and the TOE’s security functionality (SF) is given in sections the sections above.The results areshown in Table 21. The security functional requirements areaddressed by at leastone relatingsecurity feature. The various functional requirements are often covered manifold.As described above the requirements ensure that the TOE is checked for correctoperating conditions and if a not correctablefailureoccurs thata stored securestate is M7892 B11 Security Target Lite Public Security Target Lite 86 2015-10-13 achieved, accompanied by data integrity monitoring and actions to maintain the integrity although failures occurred.An overview is given in the table below. Table 21: Mapping of SFR and SF Security Functional Requirement SF_DPM SF_PS SF_PMA SF_PLA SF_CS FAU_SAS.1 X FMT_LIM.1 X FMT_LIM.2 X FDP_ACC.1 X X X FDP_ACF.1 X X X FPT_PHP.3 X X X X X FDP_ITT.1 X X X X X FDP_SDI.1 X FDP_SDI.2 X FDP_IFC.1 X X X FMT_MSA.1 X X X FMT_MSA.3 X X X FMT_SMF.1 X X X FRU_FLT.2 X FPT_ITT.1 X X X X FPT_TST.2 X X FPT_FLS.1 X X X X FCS_RNG.1 X FCS_COP.1/DES X FCS_COP.1/AES X FCS_COP.1/RSA X FCS_COP.1/ECDSA X FCS_COP.1/ECDH X FCS_COP.1/SHA X FCS_CKM.1/RSA X M7892 B11 Security Target Lite Public Security Target Lite 87 2015-10-13 Security Functional Requirement SF_DPM SF_PS SF_PMA SF_PLA SF_CS FCS_CKM.1/EC X 8.7 Security Requirements are internally Consistent For this chapter the PP [1] section 6.3.4 can be applied completely. In addition to the discussion in section 6.3 of PP [1] the security functional requirement FCS_COP.1 is introduced.The security functional requirements required to meet the security objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction,O.Phys-Manipulation and O.Leak-Forced also protectthe cryptographic algorithms implemented accordingto the security functional requirement FCS_COP.1. Therefore, these security functional requirements support the secure implementation and operation of FCS_COP.1. As disturbing,manipulatingduringor forcingthe results of the test checking the security functions after TOE delivery, this security functional requirement FPT_TST.2 has to be protected. An attacker could aimto switch off or disturb certain sensors or filters and preserve the detection of his manipulation by blockingthe correct operation of FPT_TST.2. The security functional requirements required to meet the security objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction,O.Phys-Manipulation and O.Leak-Forced also protectthe security functional requirement FPT_TST.2. Therefore, the related security functional requirements support the secure implementation and operation of FPT_TST.2. The requirement FPT_TST.2 allows testingof some security mechanisms by the Smartcard Embedded Software after delivery. In addition,the TOE provides an automated continuous user transparenttesting of certain functions. The implemented privilegelevel concept represents the area based memory access protection enforced by the MMU. As an attacker could attempt to manipulatethe privilegelevel definition as defined and present in the TOE, the functional requirement FDP_ACC.1 and the related other requirements have to be protected themselves. The security functional requirements required to meet the security objectives O.Leak-Inherent, O.Phys-Probing,O.Malfunction,O.Phys- Manipulation and O.Leak-Forced also protect the area based memory access control function implemented accordingto the security functional requirement described in the security functional requirement FDP_ACC.1 with reference to the Memory Access Control Policy and details given in FDP_ACF.1. Therefore, those security functional requirements support the secure implementation and operation of FDP_ACF.1 with its dependent security functional requirements. The requirement FDP_SDI.2.1 allows detection of integrity errors of data stored in memory. FDP_SDI.2.2 in addition allows correction of one bit errors or takingfurther action.Both meet the security objective O.Malfunction.The requirements FRU_FLT.2, FPT_FLS.1, and FDP_ACC.1 which also meet this objective areindependent from FDP_SDI.2 sincethey deal with the observation of the correct operation of the TOE and not with the memory content directly. M7892 B11 Security Target Lite Public Security Target Lite 88 2015-10-13 9 Referenced Literature The table is continued on next page. Ref. Version As of Titel [1] 1.0 2007-06-15 Security IC Platform Protection Profile PP0035 [2] V3.1 Rev 4 2012-09 Common Criteria for Information Technology Security Evaluation Part 1: Introduction and General Model; Version 3.1 Revision 4 September 2012, CCMB- 2012-09-001 [3] V3.1 Rev 4 2012-09 Common Criteria for Information Technology Security Evaluation Part 2: Security Functional Requirements; Version 3.1 Revision 4 September 2012, CCMB-2012-09- 002 [4] V3.1 Rev 4 2012-09 Common Criteria for Information Technology Security Evaluation Part 3: Security Assurance Requirements; Version 3.1 Revision 4 September 2012, CCMB-2012-09- 003 [5] 3.0 2013-05-15 Functionality classes and evaluation methodology for physical random number generators AIS31, Version 3.0, 2013-05-15, Bundesamt für Sicherheit in der Informationstechnik and belonging “A proposal for: Functionality classes for random number generators”, Version 2.0, 2011-09-18, Wolfgang Killmann, T- Systems GEI GmbH, Werner Schindler, Bundesamt für Sicherheit in der Informationstechnik [6] Rev.1.7.1 2015-09-21 M7892 SOLID FLASH™ Controller Family for Security Applications, 16-bit Security Controller Family, 90nm Technology, Hardware Reference Manual [7] 2015-04-01 SLx 70 Family Production and Personalization, User’s Manual [8] Rev. 8.4 2015-05-06 16-bit Controller Family, SLE 70, Programmer's Reference Manual [9] v1.02.013 2011-06-07 SLE70 Asymmetric Crypto Library Crypto@2304T, RSA / ECC / Toolbox, Users Interface [10] 0.3 2015-10-13 The confidential Security Target for this TOE [11] 2009-11 Chipcard and Security ICs, SLx70 Family, Secure Hash Algorithm SHA-2, (SHA 256/224, SHA 512/384) (optional) [12] 2010-03-23 Crypto@2304T User Manual [13] 1.1 2013-09-24 AMM Advanced Mode for Mifare-Compatible Technology, M7892_HRM_Addendum_AMM [14] 2015-08-17 M7892 SOLID FLASH™ Controller for Security Applications, 16-bit Security Controller Family, 90nm Technology, Security Guidelines [15] Rev. 1.9 2015-03-26 M7892, 16-bit Security Controller Family, 90nm Technology, Errata Sheet [16] 2.9 2013-01 Application of Attack Potential to Smartcard, mandatory technical document, CCDB-2013-05-002, http://www.commoncriteriaportal.org [17] 2009-06 NIST: FIPS publication 186-3: Digital Signature Standard (DSS), June 2009 [18] 2010-03 IETF: RFC 5639, Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation, March 2010, http://www.ietf.org/rfc/rfc5639.txt [19] FIPS 180-4 2015-08 Information Technology Laboratory, National Institute of Standards and Technology, Gaithersburg, MD 20899-8900, Federal Information Processing Standards Publication, Secure Hash Standard (SHS), FIPS 180-4 as of 2015-08 [20] ANSI X9.63 2001-11-20 American National Standard for Financial Services X9.63-2001, Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography, American National Standards Institute M7892 B11 Security Target Lite Public Security Target Lite 89 2015-10-13 Ref. Version As of Titel [21] ISO/IEC 15496-3 2002 ISO/IEC 15946-3:2002 Information Technology - Security Techniques - Cryptographic techniques based on elliptic curves - part 3: Key Establishment [22] NIST 800-67 v1.1 National Institute of Standards and Technology (NIST), Technology Administration, U.S. Department of Data Encryption Standard (DES), NIST Special Publication 800- 67, Version 1.1 [23] FIPSPub 197 U.S. Department of Commerce, National Institute of Standards and Technology, Information Technology Laboratory (ITL), Advanced Encryption Standard (AES), FIPS PUB 197 [24] PKCS RFC 3447 v2.1 Public Key Cryptographic Standard #1: RSA Cryptography [25] ANSI X9.62 2005-11-16 American National Standard for Financial Services ANS X9.62-2005, Public Key Cryptography for the Financial Services Industry, The Elliptic Curve Digital Signature Algorithm (ECDSA), American National Standards Institute [26] ISO/IEC 15496-2 2002 ISO/IEC 15946-2:2002 Information Technology - Security Techniques - Cryptographic techniques based on elliptic curves - part 2: Digital Signatures [27] I 2009-08-14 Act on the Federal Office for Information Security (BSI-Gesetz - BSIG), Bundesgesetzblatt I p. 2821. M7892 B11 Security Target Lite Public Security Target Lite 90 2015-10-13 10 Appendix In Table 21 the hash signatures of the respective CL70 Crypto Library filearedocumented. For convenience purpose several hash values arereferenced. Table 22: Reference hash values of the CL70 Crypto Libraries RSA, EC, Toolbox Version v1.02.013: Cl70-LIB-base-XSMALL-HUGE.lib: MD5=d080392bc14a65de9094d846498f28a3 SHA1=4149318953b22876c6d9f712e084f00dccaac88f SHA256=c08bf0778baf3a25123e1ff45590eeec6bff29cb38ede2a07a377f968d5eeade Cl70-LIB-2k-XSMALL-HUGE.lib: MD5=e1829fa50cbd46f912e40528e92e77d4 SHA1=41a4c013fe08cbcf4917753076d8c035657040a0 SHA256=afe2dc4b3ecebbd67dab8add2581f3ceb4f6268d5f6c0091f7d975afbbec86ca Cl70-LIB-4k-XSMALL-HUGE.lib: MD5=3c2ac3030c2abbc9e6d32b46c244f59b SHA1=0867b74168c2b228a12c2835de92262d9536bdde SHA256=11736a910bdc9e8a2d74b56db60d2002ff8bd9ba49be8c8fc08d744128ac6e3b Cl70-LIB-ecc-XSMALL-HUGE.lib: MD5=9ccf23232e16645448323670e8fa3171 SHA1=315952fc79e4e711e6f95e2b9d547a5c91d88d1c SHA256=69ad0d5bfaf2308c24d19ee8824d61952a73c273dd57ee19612dace6ba92e772 Cl70-LIB-toolbox-XSMALL-HUGE.lib: MD5=4c577bcf9853c8c030b84ebe19d22b8d SHA1=4c12dc67dad4bbe88c4b23c43a275b3ad3be71f3 SHA256=e6de94b27ffce43b8a023c04ceb86795585617b4cac8e7a53a78cf273b1fe8fc M7892 B11 Security Target Lite Public Security Target Lite 91 2015-10-13 SHA-2 Library Version 1.01: SHA-2 values computed from: SLE70-SHA2-Lib_RE_1v01_2009-06-29.LIB MD5=70d2df490185b419fb820d597d82d117 SHA1= df15ff79b5f5ab70bbad0ee031953e1877cabd47 SHA256=765fc5d47cf8274833476406b24010a56ebcfd4b0972704ddd27e2d3e3e086f8 M7892 B11 Security Target Lite Public Security Target Lite 92 2015-10-13 11 List of Abbreviations AES Advanced Encryption Standard AIS31 “Anwendungshinweise und Interpretationen zu ITSEC und CC Funktionalitätsklassen und Evaluationsmethodologiefür physikalischeZufallszahlengeneratoren” API Application Programming Interface BPU Bill Per Use CC Common Criteria CI Chip Identification Mode (STS-CI) CIM Chip Identification Mode (STS-CI), same as CI CPU Central Processing Unit CRC Cyclic Redundancy Check Crypto2304T Asymmetric Cryptographic Processor CRT Chinese Reminder Theorem DES Data Encryption Standard DPA Differential Power Analysis DFA Differential Failure Analysis DTRNG Deterministic Random Number Generator EC Elliptic Curve Cryptography ECC Error Correction Code and Elliptic Curve Cryptography depending on the context EDC Error Detection Code EDU Error Detection Unit SOLID FLASH™ NVM Electrically Erasable and Programmable Read Only Memory (EEPROM) a Non Volatile Memory EMA Electro magnetic analysis FL Flash Loader HW Hardware IC Integrated Circuit ICO Internal Clock Oscillator ID Identification IMM Interface Management Module ITP Interrupt and Peripheral Event Channel Controller I/O Input/Output IRAM Internal Random Access Memory ITSEC Information Technology Security Evaluation Criteria M Mechanism MED Memory Encryption and Decryption MMU Memory Management Unit M7892 B11 Security Target Lite Public Security Target Lite 93 2015-10-13 NVM Non Volatile Memory O Object OS Operating system PEC Peripheral Event Channel PRNG Pseudo Random Number Generator PROM Programmable Read Only Memory PTRNG Physical Random Number Generator RAM Random Access Memory RFI Radio Frequency Interface RMS Resource Management System RNG Random Number Generator ROM Read Only Memory RSA Rives-Shamir-Adleman Algorithm SAM Service Algorithm Minimal SCP Symmetric Cryptographic Processor SF Security Feature SFR Special Function Register, as well as Security Functional Requirement The specific meaning is given in the context SPA Simple power analysis STS Self Test Software SW Software SO Security objective T Threat TM Test Mode (STS) TOE Target of Evaluation TRNG True Random Number Generator TSC TOE Security Functions Control TSF TOE Security Functionality UART Universal Asynchronous Receiver/Transmitter UM User Mode (STS) UmSLC User mode Security Life Control WDT Watch Dog Timer XRAM eXtended Random Access Memory 3DES Triple DES Encryption Standard M7892 B11 Security Target Lite Public Security Target Lite 94 2015-10-13 12 Glossary Application Program/Data Software which implements the actual TOE functionality provided for the user or the data required for that purpose Bill-Per-Use Bill-Per-Useconcept allowingtheuser to configure the chips Central ProcessingUnit Logic circuitry for digital information processing Chip Integrated Circuit] Chip Identification Data Data stored in the SOLID FLASH™ NVM containingthe chip type, lot number (includingtheproduction site), die position on wafer and production week and data stored in the ROM containingthe STS version number Chip Identification Mode Operational status phaseof the TOE, in which actions for identifyingthe individual chip by transmittingthe Chip Identification Data takeplace Controller IC with integrated memory, CPU and peripheral devices Crypto2304T Cryptographic coprocessor for asymmetric cryptographic operations (RSA,Elliptic Curves) Cyclic Redundancy Check Process for calculatingchecksums for error detection Electrically Erasableand ProgrammableRead Only Memory (SOLID FLASH™ NVM) Non-volatilememory permitting electrical read and write operations End User Person in contactwith a TOE who makes use of its operational capability Firmware Is software essential to put the chip into operation.The firmwareis located in the ROM and parts of itin the SOLID FLASH™ NVM Flash Loader Software enablingto download software after delivery Hardware Physically presentpart of a functional system(item) Integrated Circuit Component comprisingseveral electronic circuits implemented in a highly miniaturized deviceusingsemiconductor technology Security Target Description of the intended state for countering threats Mechanism Logic or algorithmwhich implements a specific security function in hardwareor software Memory Encryption and Decryption Module for encoding/decodingdata transfer between CPU and memory Memory Hardware partcontainingdigital information (binary data) Microprocessor CPU with peripherals Object Physical or non-physical partof a system which contains information and is acted upon by subjects OperatingSystem Software which implements the basic TOEactions necessary to run the user application ProgrammableRead Only Memory Non-volatilememory which can be written once and then only permits read operations Random Access Memory Volatilememory which permits write and read operations Random Number Generator Hardware partfor generating random numbers M7892 B11 Security Target Lite Public Security Target Lite 95 2015-10-13 Read Only Memory Non-volatilememory which permits read operations only Resource Management System Partof the firmwarecontainingSOLID FLASH™ NVM programming routines, AIS31 testbench etc. SCP Is the symmetric cryptographic coprocessorfor symmetric cryptographic operations (3DES, AES). Self Test Software Partof the firmwarewith routines for controllingthe operatingstate and testing the TOE hardware Security Function Part(s) of the TOE used to implement part(s) of the security objectives Smart Card Is a plastic card in creditcard formatwith built-in chip.Other form factors are also possible,i.e. if integrated into mobile devices Software Information (non-physical partof the system) which is required to implement functionality in conjunction with the hardware(program code) Subject Entity, generally in the form of a person, who performs actions Target of Evaluation Product or system which is beingsubjected to an evaluation Test Mode Operational status phaseof the TOE in which actions to test the TOE hardware take place Threat Action or event that might prejudicesecurity User Mode Operational status phaseof the TOE in which actions intended for the user takes place w w w . i n f i n e o n . c o m Published byInfineon Technologies AG