Home

NXP J3E145_M64, J3E120_M65, J3E082_M65

1. 119 7 1 5 iier adis 121 7 1 6 121 7 1 7 SF PIN diete terere 122 7 1 8 SF Loadlntegrity 123 7 1 9 SF Transaction 123 7 1 10 SF Hardware 123 7 1 11 SF OryptoLib ro eet 124 7 2 Logical 125 7 3 Physical 125 7 4 Security Features of Hardware 126 8 Bibliography eere 127 9 Legal information esses 130 9 1 130 9 2 2156 1 5 130 9 3 LICENSES 130 9 4 alc 130 9 5 Trademarks 130 10 List of 131 11 List of tables eese 132 12 Contents naia 133 Please be aware that important notices concerning this document and the product s described herein have been included in the section Legal information NXP B V 2013 All rights reserved For more information please visit http www nxp com For sales office addresses please
2. 22 Security problem definition ASE SPD 23 Introduction ssssesseseseeeenne 23 ASSGUS E M 23 User 23 BICI 25 Threats not contained in 5 26 Unauthorized full or partial Cloning of the TOE 26 Threats on TOE operational environment 26 Software 27 Threat on Random Numbers 27 Threats from 5 nte 28 Confidentiality eene 28 IMETI fr 28 Identity Usurpation 29 Unauthorized Execution 29 Denial of 30 Card Management 30 Cel 30 Miscellaneous 30 Organisational security policies OSPs 31 ASSUMPIONS 31 Security Aspects 32 Confidentiality eene 32 MEg pe 33 Unauthorized Executions 33 3 6 3 1 3 6 3 2 3 6 3 3 3 6 3 4 3 6 4 3 6 5 4 4 1 1 4 1 2 4 1 2 1 4 1 2 2 4 1 2 3 4 1 2 4 4 1 2 5 4 1 2 6 4 1 2 7 4 1 2 8 4 2 4 2 1 4 2 1 1 4 2 2 4
3. 44 Security Objectives Rationale 44 Security Objectives Rationale from 5 46 dic E 46 Organisational Security Policies 51 Assumptions eeseenenm 51 Security Objectives Rationale for Objectives not lE E 51 ge 51 Organisational Security Policies 51 Assumlptions reiten orent oki odes 51 Extended Components Definition ASE ECD 52 Definition of Family FCS RNG 52 Definition of the Family 53 Definition of Family FAU SAS 54 Security requirements ASE REQ 54 CoreG LC Security Functional Requirements 60 Firewall Policy emen 60 FDP ACC 2 FIREWALL Complete Access COMO iit 60 ACF 1 FIREWALL Security Attribute based 5 oer iei 60 Please be aware that important notices concerning this document and the product s described herein have been included in the section Legal information NXP B V 2013 All rights reserved For more information please visit http www nxp com For sales office addresses please send an please send an email to salesaddresses nxp com Date of release 2nd August 2013 NXP Semiconductors JCOP 2 4 2 R3 6 1 1 3 6 1 1 6 6 1 1 7 6 1 1 8 6 1 1 9 6 1 1 10 6 1 1 11 6 1 1 12 6 1 2 6 1 2 1 6 1 2 2 6 1 2
4. Evaluation documentation Rev 00 02 2nd August 2013 132 of 135 NXP Semiconductors JCOP 2 4 2 R3 12 Contents Security Target Lite 2 4 2 4 1 2 4 2 2 4 3 2 4 4 3 1 3 2 3 2 1 3 3 3 3 1 3 3 1 1 3 3 1 2 3 3 1 3 3 3 1 4 3 3 2 3 3 2 1 3 3 2 2 3 3 2 3 3 3 2 4 3 3 2 5 3 3 2 6 3 3 2 7 3 3 2 8 3 4 3 5 3 6 3 6 1 3 6 2 3 6 3 ST Introduction ASE INT 8 ST reference and TOE reference 8 TOE Overview iieri e Een hie epus TOE description TOE abstract and definition 9 Non TOE hardware software firmware 12 TOE Life Cycle iiie ence cant 12 TOE Identification esses 14 Java Card Technology 17 Smart Card Platform 18 Native 19 19 Conformance claims ASE CCL 20 CC Conformance Claim 20 Package 20 PPG tex mei esce 20 Conformance claim rationale 21 TOE Typ6 iine co reiecit beide 21 SPD Statement ssssssssssessss 21 Security Objectives Statement 21 Security Requirements Statement
5. OT SID OT FIREWALL OT GLOBAL ARRAYS CONFID OT GLOBAL ARRAYS INTEG OT REALLOCATION OT RESOURCES OT ALARM OT CIPHER OT TRANSACTION OT NATIVE OT OPERATE OT KEY MNGT OT PIN MNGT OT REMOTE OT OBJ DELETION OT DELETION OT LOAD OT INSTALL OT CARD MANAGEMENT OT SCP IC OT SCP RECOVERY OT SCP SUPPORT OT EXT MEM OT IDENTIFICATION OT RND OT MF FW Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 45 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC Table 13 Assignment threats assumptions OSP security objectives for the environment o z o o X u 0 qa x J w f a o0 cw a 2 D gt O O O T CONFID APPLI DATA x T CONFID JCS CODE T CONFID JCS DATA x T INTEG APPLI CODE X T INTEG APPLI DATA x T INTEG JCS CODE x T INTEG JCS DATA X T EXE CODE 1 X T EXE CODE 2 X T NATIVE x x A USE_DIAG X A USE KEY x A PROCESS SEC IC x A APPLET x A VERIFICATION X OSP VERIFICATION x 4 3 1 Security Objectives Rationale from 5 The following chapters have been taken from 5 without modifications 4 3 1 1 Threats Confidentiality T CONFID APPLI DATA This threat is countered by the security objective for the operational environment regarding bytecode v
6. NXP Semiconductors JCOP 2 4 2 H3 Approved Security Target Lite PUBLIC The TSF shall perform assignment data encryption and decryption in accordance with a specified cryptographic algorithm assignment Triple DES in ECB CBC Mode without padding or with padding method 1 or method 2 and cryptographic key sizes for 2 key TDES 112 bit or 3 key TDES 168 bit that meet the following assignment ANSI X9 52 1998 40 ECB and CBC mode without Padding I809791 1 padding Method 1 or padding method 2 25 Application Notes 1 The security functionality is resistant against side channel analysis and similar techniques To fend off attackers with high attack potential an adequate key length must be used references can be found in national and international documents and standards 2 The CBC mode is to be understood as outer CBC mode i e CBC mode as defined in 36 and 40 applied to the block cipher algorithm either DES or Triple DES FCS COP 1 1 AES The TSF shall perform assignment data encryption and decryption in accordance with a specified cryptographic algorithm assignment AES in ECB CBC Mode and cryptographic key sizes assignment 128 192 and 256 Bit that meet the following assignment FIPS Publication 197 21 Advanced Encryption Standard AES NIST Special Publication 800 38A 2001 37 ECB and CBC mode Application Notes 1 The security functionality is resistant against side cha
7. Select Applet Initialize Update with object APDU BUFFER External Authenticate with object APDU BUFFER 13 Note All measures described in guidance of the underlying hardware platform concerning power consumption and timing will be taken into account for the TOE development Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 122 of 135 NXP Semiconductors JCOP 2 4 2 R3 Security Target Lite PUBLIC 7 1 8 SF Loadintegrity SF LIT OIP 7 1 9 SF Transaction SF TRA PRO 7 1 10 SF Hardware The TSF ensures the origin and the integrity of a received package see sections 6 1 9 1 FCO NRO 2 CM and 6 1 9 4 FDP_UIT 1 CM The algorithm used for providing integrity protection is RSASSA PKCS1 v1 5 22 with a key length of 2048 bit according to 14 The TSF permits the rollback of operations OP JAVA OP CREATE on objects OB JAVAOBJECTS These operations can be rolled back within the calls select deselect process or install notwithstanding the restrictions given in Java Card Runtime Environment 18 87 7 within the bounds of the Commit Capacity 18 87 8 and those described in Java Card API 17 see 6 1 2 11 FDP ROL 1 FIREWALL The certified hardware part of the TOE features the following TSF The exact formulation can be found in the hardware security target 10 S
8. Security Target Lite PUBLIC and all aspects related to confidentiality and integrity of code and data Note This threat from 5 was refined to cover additional aspects not contained in 5 3 4 Organisational security policies OSPs OSP VERIFICATION OSP PROCESS TOE Note 3 5 Assumptions This policy shall ensure the consistency between the export files used in the verification and those used for installing the verified file The policy must also ensure that no modification of the file is performed in between its verification and the signing by the verification authority See 4 VERIFICATION p 34 for details An accurate identification must be established for the TOE This requires that each instantiation of the TOE carries this identification The IC Developer Manufacturer must apply the policy Protection during TOE Development and Production OSP PROCESS TOE as specified above This section is partly taken from 5 and introduces the assumptions made on the environment of the TOE A APPLET A VERIFICATION Applets loaded post issuance do not contain native methods The Java Card specification explicitly does not include support for native methods 19 83 3 outside the API All the bytecodes are verified at least once before the loading before the installation or before the execution depending on the card capabilities in order to ensure that each bytecode is valid at execution time In addit
9. NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 19 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC e Transport and ticketing granting pre paid access to a transport system like the metro and bus lines of a city e Telephony through the subscriber identification module SIM for digital mobile telephones e Personal identification for granting access to secured sites or providing identification credentials to participants of an event e Electronic passports and identity cards e Secure information storage like health records or health insurance cards e Loyalty programs like the Frequent Flyer points awarded by airlines Points are added and deleted from the card memory in accordance with program rules The total value of these points may be quite high and they must be protected against improper alteration in the same way that currency value is protected 2 Conformance claims ASE CCL This chapter is divided into the following sections CC Conformance Claim Package claim PP claim and Conformance claim rationale 2 4 CC Conformance Claim This Security Target claims to be conformant to version 3 1 of Common Criteria for Information Technology Security Evaluation according to e Common Criteria for Information Technology Security Evaluation Part 1 Version 3 1 Revision 4 September 2012 1 Common Criteria for Informatio
10. 6 1 13 1 ACC 1 LifeCycle Subset Access Control FDP ACC 1 1 LifeCycle The TSF shall enforce the assignment LIFE CYCLE MANAGEMENT access control SFP on assignment subjects S ROOTAPP S PACKAGE CM S PACKAGE S JCRE objects D ADMIN CONF DATA D PERSO CONF DATA and all operations among subjects and objects covered by the SFP 6 1 13 2 ACF 1 LifeCycle Security Attribute based Access Control FDP ACF 1 1 LifeCycle The TSF shall enforce the assignment LIFE CYCLE MANAGEMENT access control SFP to objects based on assignment the security attributes of S PACKAGE CM Card Life Cycle State as defined in 14 Section 5 1 OP READY INITIALIZED SECURED CARD LOCKED TERMINATED OS Internal Life Cycle States PROTECTED FUSED and the security attributes of SSROOTAPP AUTHENTICATED ADMIN AUTHENTICATED TRANSPORT FDP ACF 1 2 LifeCycle The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed assignment 1 S PACKAGE CM is allowed to set the Card Life Cycle OP READY INITIALIZED SECURED CARD LOCKED and TERMINATED 2 S JCRE is allowed to set the Card Life Cycle to TERMINATED 3 S ROOTAPP is allowed to set the OS Internal Life Cycle States PROTECTED and FUSED 4 S ROOTAPP is allowed to read and write DLADMIN CONF DATA and D PERSO CONF DATA in the state AUTHENTICATED ADMIN 5 S ROOTAPP is allowed to read and write D PERSO CONF DATA in t
11. CARG Security Functional Requirements This group includes requirements for preventing the installation of packages that has not been bytecode verified or that has been modified after bytecode verification FCO NRO 2 CM Enforced proof of origin FCO NRO 2 1 CM The TSF shall enforce the generation of evidence of origin for transmitted application packages at all times FCO NRO 2 2 CM Editorially Refined The TSF shall be able to relate the identity of the originator of the information and the application package contained in the information to which the evidence applies FCO NRO 2 3 CM The TSF shall provide a capability to verify the evidence of origin of information to recipient given assignment at the time when the package is received because no evidence is kept on the card for future verifications All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 84 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC 6 1 9 2 FDP IFC 2 CM Complete information flow control FDP IFC 2 1 CM The TSF shall enforce the PACKAGE LOADING information flow control SFP on S INSTALLER S BCV S CAD and I APDU and all operations that cause that information to flow to and from subjects covered by the SFP FDP IFC 2 2 CM The TSF shall ensure that all operations that cause any information in the TOE to flo
12. 86 FMT_MSA 1 CM Management of security 86 FMT_MSA 3 CM Static attribute initialisation 87 FMT_SMF 1 CM Specification of Management FUNCTIONS 87 FMT SMR 1 CM Security 87 FTP_ITC 1 CM Inter TSF trusted channel 87 EMG Security Functional Requirements 88 FDP ACC EXT MEM Subset access control88 FDP ACF 1 EXT MEM Security attribute based access control sssssssssssseneee 88 Please be aware that important notices concerning this document and the product s described herein have been included in the section Legal information NXP B V 2013 All rights reserved For more information please visit http www nxp com For sales office addresses please send an please send an email to salesaddresses nxp com Date of release 2nd August 2013 NXP Semiconductors JCOP 2 4 2 R3 6 1 6 1 6 1 6 1 6 1 6 1 6 1 12 3 6 1 6 1 12 5 6 1 6 1 6 1 6 1 6 1 6 1 6 1 6 1 6 1 6 1 6 1 6 1 6 1 6 1 6 1 6 1 6 1 6 1 6 1 6 2 6 3 10 3 10 4 10 5 12 12 1 12 2 12 4 12 6 13 13 1 13 2 13 3 13 4 14 14 1 14 2 14 3 6 1 14 4 14 5 14 6 15 15 1 15 2 15 3 15 4 15 5 FMT MSA 4 EXT MEM Management of security Eie X 88 FMT MSA S3 EXT MEM Static attribute initialization
13. EEPROM e has read and write access to all data in the Application RAM Code executed in the User Mode e has read and or execute access to code data in the Application ROM controlled by the MMU Segment Table used by the MMU e has read and or write and or execute access to code data in the Application EEPROM controlled by the MMU Segment Table used by the MMU e has read and or write access to data in the Application RAM controlled by the MMU Segment Table used by the MMU FDP ACF 1 3 SCP The TSF shall explicitly authorize access of subjects to objects based on the following additional rules assignment Code running in MIFARE Mode has read access to 64 bytes in the Application ROM storing the Access Condition Matrix Code running in MIFARE Mode has access to the Application RAM defined by the Special Function Register MXBASL MXBASH MXSZL and MXSZH Code running in Boot Mode or MIFARE Mode has read access to the Security Row stored in the Application EEPROM The FameXE co processor has read access to the EEPROM and read write access to the FameXE RAM FDP_ACF 1 4 SCP The TSF shall explicitly deny access of subjects to objects based on the following additional rules assignment none 6 1 12 6 FMT MSA 3 SCP Static Attribute Initialization 6 1 13 Approved FMT MSA 3 1 SCP The TSF shall enforce the assignment Access Control Policy to provide selection restrictive default values for security attributes that a
14. Security Target Lite PUBLIC NXP Semiconductors Subject Object Security attributes S PACKAGE LC Selection Status S JCVM Active Applets Currently Active Context S JCRE Selected Applet Context O JAVAOBJECT Sharing Context LifeTime FDP ACF 1 2 FIREWALL The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed e R JAVA 1 18 86 2 8 S PACKAGE may freely perform OP ARRAY ACCESS OP INSTANCE FIELD OP INVK VIRTUAL OP INVK INTERFACE OP THROW or OP TYPE ACCESS upon any O JAVAOBJECT whose Sharing attribute has value JCRE entry point or global array e R JAVA 2 18 86 2 8 S PACKAGE may freely perform OP ARRAY ACCESS OP INSTANCE FIELD OP INVK VIRTUAL OP INVK INTERFACE or OP THROW upon any O JAVAOBJECT whose Sharing attribute has value Standard and whose Lifetime attribute has value PERSISTENT only if O JAVAOBJECT s Context attribute has the same value as the active context e R JAVA 3 18 6 2 8 10 S PACKAGE may perform OP TYPE ACCESS upon an O JAVAOBJECT whose Sharing attribute has value SIO only if O JAVAOBJECT is being cast into checkcast or is being verified as being an instance of instanceof an interface that extends the Shareable interface e R JAVA 4 18 6 2 8 6 S PACKAGE may perform OP INVK INTERFACE upon an O JAVAOBJECT whose Sharing attribute has the value SIO and whose Context attribute has the value
15. eeeeeeeeeeee eee 88 FMT SMF 1 EXT MEM Specification of Management 89 Further Functional Requirements not contained A m 89 SCPG Security Functional Requirements 89 FPT_FLS 1 SCP Failure with preservation of a Secure State 89 FRU FLT 2 SCP Limited Fault Tolerance 89 FPT PHP 3 SCP Resistance to Physical Attack 89 FDP_ACC 1 SCP Subset Access Control 90 FDP ACF 1 SCP Security Attribute based Access Control 90 FMT MSA S3 SCP Static Attribute Initialization 91 LifeCycle Security Functional Requirements 91 FDP ACC 1 LifeCycle Subset Access Control 92 ACF 1 LifeCycle Security Attribute based Access Control 92 FMT MSA 1 LifeCycle Management of Security AI IDUIGS iacuit 92 FMT MSA 3 LifeCycle Static Attribute Initialization re 93 Further Functional Requirements 93 FIA AFL 1 PIN Basic Authentication Failure Handling 9 FTP ITC 1 LifeCycle Inter TSF Trusted Channel uox uUum I E MM MUT 93 FAU SAS 1 SCP Audit Data Storage 93 FCS RNG 1 Quality metric for Random N tnbets 5 94 FCS RNG 1 RNG2 Quality metric for Random Nurnb ets testes 94 EMSEC 1 TOE Emanation 95 Functional Requirements for the Secure Box 95 FDP ACC 2 SecureBox Complete Access ern c 95
16. n nnnnnennenrnrnrnrnrnrnrnrnrnrnrnnnnnnnnnnn nenna 72 FDP_RIP 1 KEYS Subset Residual Information ed 0 lt 0 0 73 FDP_RIP 1 TRANSIENT Subset Residual Information Protection 73 FDP ROL 1 FIREWALL Basic Rollback 73 Card Security Management FAU ARP 1 Security Alarms FDP SDI 2 Stored Data Integrity Monitoring and y Yell E M P FPR UNO 1 Unobservability FPT FLS 1 Failure with Preservation of Secure Stale adiungi eI Bie 76 FPT TDC 1 Inter TSF basic TSF data CONSISTENCY 76 Aid Management 77 FIA ATD 1 AID User Attribute Definition 77 FIA UID 2 AID User Identification before any rre p XS 77 FIA USB 1 AID User Subject Binding 77 FMT MTD 1 JCRE Management of TSF Data 78 6 1 4 5 6 1 5 6 1 5 1 6 1 5 2 6 1 5 3 6 1 5 4 6 1 6 6 1 6 1 6 1 6 2 6 1 6 3 6 1 6 4 6 1 6 5 6 1 6 6 6 1 6 7 6 1 6 8 6 1 7 6 1 7 1 6 1 7 2 6 1 8 6 1 8 1 6 1 8 2 6 1 9 6 1 9 1 6 1 9 2 6 1 9 3 6 1 9 4 6 1 9 5 6 1 9 6 6 1 9 7 6 1 9 8 6 1 9 9 6 1 9 10 6 1 10 6 1 10 1 6 1 10 2 Security Target Lite FMT_MTD 3 JCRE Secure TSF Data 78 INSTG Security Functional Requirements 78 FDP ITC 2 Installer Import of User Data with Security Attributes 78 FMT_SMR 1 Installer Security roles 78 FPT FLS 1 I
17. 15 Hardware data sheet JCOP V2 4 2 Revision 3 145 J2E145 Secure smart card controller Rev 0 2 26 March 2013 Doc No 258502 16 ISO IEC 15946 1 Information technology Security techniques Cryptographic techniques based on elliptic curves Part 1 General 2008 17 Application Programming Interface Java Card tm Platform Version 3 0 1 Classic Edition May 2009 Sun Microsystems Inc 18 Runtime Environment Specification Java Card tm Platform Version 3 0 1 Classic Edition May 2009 Sun Microsystems Inc 19 Virtual Machine Specification Java Card tm Platform Version 3 0 1 Classic Edition May 2009 Sun Microsystems Inc 20 FIPS PUB 46 3 FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION DATA ENCRYPTION STANDARD DES Reaffirmed 1999 Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 127 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC October 25 U S DEPARTMENT OF COMMERCE National Institute of Standards and Technology 21 FIPS PUB 197 Federal Information Processing Standards Publication 197 Announcing the ADVANCED ENCRYPTION STANDARD AES November 26 2001 22 PKCS1 v2 1 RSA Cryptography Standard RSA Laboratories June 2002 23 ISO IEC 11770 Part 3 Information technology Security techniques Key management Mechanisms usin
18. ADELG Remote Method Invocation RMIG Object deletion ODELG Secure carrier CarG Extended Memory EMG Description related to the Java Card API Logical channels are a Java Card specification version 2 2 feature This group is the union of requirements from the Core CoreG and the Logical channels LCG groups defined in 6 cf Java Card System Protection Profile 5 The InstG contains the security requirements concerning the installation of post issuance applications It does not address card management issues in the broad sense but only those security aspects of the installation procedure that are related to applet execution The ADELG contains the security requirements for erasing installed applets from the card a feature introduced in Java Card specification version 2 2 The RMIG contains the security requirements for the remote method invocation feature which provides a new protocol of communication between the terminal and the applets This was introduced in Java Card specification version 2 2 The ODELG contains the security requirements for the object deletion capability This provides a safe memory recovering mechanism This is a Java Card specification version 2 2 feature The CarG group contains minimal requirements for secure downloading of applications on the card This group contains the security requirements for preventing in those configurations that do not support on card static or dynamic b
19. FPR_UNO 1 SF SMG_MIE The TSF monitors user data CODE D APP I DATA D PIN D APP_KEYs for integrity errors If an error occurs for D APP KEYs or D PIN the TSF maintain a secure state lock card session If an error occurs for DL APP CODE or D APP DATA a SecurityException is thrown see 6 1 3 2 501 2 SF SMG PIU The TSF makes any previous information content of a resource unavailable upon see 6 1 1 5 FDP RIP 1 OBJECTS 6 1 2 7 FDP RIP 1 APDU 6 1 2 8 FDP RIP 1 bArray 6 1 2 10 FDP_RIP 1 TRANSIENT 6 1 2 6 FDP_RIP 1 ABORT 6 1 2 9 FDP_RIP 1 KEYS 6 1 6 3 FDP_RIP 1 ADEL 6 1 8 1 FDP RIP 1 ODEL e allocation of class instances arrays and the APDU buffer e de allocation of bArray object any transient object any reference to an object instance created during an aborted transaction and cryptographic buffer D CRYPTO e de allocation of applets and objects Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 121 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC SF SMG NSC NO SIDE CHANNEL The TSF ensures that during command execution there are no usable variations in power consumption measurable at e g electrical contacts or timing measurable at e g electrical contacts that might disclose cryptographic keys or PINs All functions of SF Cry
20. be accurate and reliable However NXP Semiconductors does not give any representations or warranties expressed or implied as to the accuracy or completeness of such information and shall have no liability for the consequences of use of such information In no event shall NXP Semiconductors be liable for any indirect incidental punitive special or consequential damages including without limitation lost profits lost savings business interruption costs related to the removal or replacement of any products or rework charges whether or not such damages are based on tort including negligence warranty breach of contract or any other legal theory Notwithstanding any damages that customer might incur for any reason whatsoever NXP Semiconductors aggregate and cumulative liability towards customer for the products described herein shall be limited in accordance with the Terms and conditions of commercial sale of NXP Semiconductors Right to make changes NXP Semiconductors reserves the right to make changes to information published in this document including without limitation specifications and product descriptions at any time and without notice This document supersedes and replaces all information supplied prior to the publication hereof Suitability for use NXP Semiconductors products are not designed authorized or warranted to be suitable for use in life support life critical or safety critical systems or equipment n
21. it is assumed that the TOE is developed consistently with the SCP functions including memory management I O functions and cryptographic functions Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 76 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC 6 1 4 Aid Management 6 1 4 1 FIA ATD 1 AID User Attribute Definition FIA ATD 1 1 AID The TSF shall maintain the following list of security attributes belonging to individual users e Package AID e Applet s version number e Registered applet AID e Applet Selection Status 19 6 5 Refinement Individual users stand for applets 6 1 4 2 UID 2 AID User Identification before any Action FIA UID 2 1 AID The TSF shall require each user to be successfully identified before allowing any other TSF mediated actions on behalf of that user Application note e By users here it must be understood the ones associated to the packages or applets that act as subjects of policies In the Java Card System every action is always performed by an identified user interpreted here as the currently selected applet or the package that is the subject s owner Means of identification are provided during the loading procedure of the package and the registration of applet instances e The role Java Card RE defined in FMT SMR 1 is attached t
22. world The precise list of operations and objects is left unspecified but should at least concern secret keys and PIN codes when they exists on the card as well as the cryptographic operations and comparisons performed on them 6 1 34 FLS 1 Failure with Preservation of Secure State FPT_FLS 1 1 The TSF shall preserve a secure state when the following types of failures occur those associated to the potential security violations described in FAU_ARP 1 Application note The Java Card RE Context is the Current context when the Java Card VM begins running after a card reset 18 6 2 3 or after a proximity card PICC activation sequence 18 Behavior of the TOE on power loss and reset is described in 18 3 6 and 7 1 Behavior of the TOE on RF signal loss is described in 18 3 6 1 6 1 3 5 TDC 1 Inter TSF basic TSF data consistency FPT_TDC 1 1 The TSF shall provide the capability to consistently interpret the CAP files the bytecode and its data arguments when shared between the TSF and another trusted IT product FPT_TDC 1 2 The TSF shall use e the rules defined in 19 specification e the API tokens defined in the export files of reference implementation e assignment The ISO 7816 6 rules assignment The EMV specification when interpreting the TSF data from another trusted IT product Application note Concerning the interpretation of data between the TOE and the underlying Java Card platform
23. 02 2nd August 2013 130 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite 10 List of figures Fig 1 JCOP Architecture 10 Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 131 of 135 NXP Semiconductors JCOP 2 4 2 R3 11 List of tables Security Target Lite Table 1 Table 2 Table 3 Table 4 Table 5 Table 6 Table 7 Table 8 Table 9 Table 10 Table 11 Table 12 Table 13 Table 14 Table 15 Table 16 Table 17 Table 18 Table 19 Table 20 Table 21 Table 22 Table 23 Table 24 Table 25 Table 26 Table 27 Table 28 Table 30 Table 31 Approved ST reference and TOE reference 8 Underlying 8 TOE Life 12 Delivery Items 14 Product Identification 14 Products commercial names 15 JCOP Commercial Name Format 15 TOE Groups 17 TING AUS seeders Se 25 Security Objectives for the TOE 38 Security Objectives for the operational environment
24. 1 FMT MTD 1 ves FMT_MTD 3 JCRE i FMT_MTD 1 JCRE i FDP_ACF 1 ies FDP_ACC 1 LifeCycle Ur FDP ACF 1 LifeCycle FDP ACF 1 LifeCycle FDP ACF 1 E y FDP_ACC 1 LifeCycle or IFC 1 FMT MSA 1 LifeCycle FMT SMR 1 FDP ACC 1 LifeCycle EMT SMF 1 FMT SMR 1 CM FMT_SMF 1 Yes FMT MSA 3 Lifecycle ida FMT MSA 1 Lifecycle gt FMT SMR 1 CM FIA AFL 1 PIN FIA UAU 1 No rationale in Section 6 4 1 FDP_ACC 1 or FTP_ITC 1 LifeCycle FDP_IFC 1 E ini cT FMT_MSA 3 en y FAU SAS 1 SCP No dependencies FCS RNG 1 RNG2 No dependencies FCS RNG 1 No dependencies FPT EMSEC 1 No dependencies Yes FDP_ACC 2 SecureBox FDP_ACF 1 FDP_ACF 1 Secure box FDP_ACC 1 or Yes FDP_IFC 1 FDP_ACC 1 SecureBox FMT_SMR 1 FMT_SMF 1 SecureBox FMT_SMF 1 FMT_SMR 1 ie ee MSA 1 S b FMT_MSA 3 SecureBox FMT_SMR 1 cr 1 Securebox And FMT_SMR 1 FDP_ACC 1 or Yes FDP_IFC 1 FDP_ACC 1 SecureBox FMT_MSA 1 SecureBox FMT SMR 1 FMT SMR 1 FMT SMF 1 FMT SMF 1 SecureBox FMT SMF 1 SecureBox No dependencies Rationale for the Exclusion of Dependencies The dependency FIA UID 1 of FMT SMR 1 Installer is unsupported This PP does not require the identification of the installer since it can be considered as part of the TSF The dependency FIA UID 1 of FMT_SMR 1 ADEL is unsupported This PP does not require the identification of the deletion manager since it can be considered as par
25. 168 Bit based on random numbers according to AIS 20 8 class DRG 3 or class DRG 2 see 6 1 2 1 FCS CKM 1 and 6 1 14 4 FCS HNG 1 and 6 1 14 5 FCS HNG 1 RHNG2 SF CRK GRS Generation of RSA keys with length from 512 to 2048 Bit based on random numbers according to AIS 20 8 class DRG 3 see 6 1 2 1 FCS CKM 1 and 6 1 14 4 FCS_RNG 1 and 6 1 14 5 FCS_RNG 1 RNG2 SF CRK_GAE Generation of AES keys with length of 128 192 and 256 Bit based on random numbers according to AIS 20 8 class DRG 3 or DRG 2 6 1 2 1 FCS_CKM 1 and 6 1 14 4 FCS_RNG 1 and 6 1 14 5 FCS_RNG 1 RNG2 SF CRK_DDE Distribution of DES keys according to Java Card API 17 or proprietary 30 see 6 1 2 2 FCS_CKM 2 SF CRK_DRS Distribution of RSA keys according to Java Card API 17 or proprietary API 30 see 6 1 2 2 FCS_CKM 2 SF CRK_DAE Distribution of AES keys according to Java Card API 17 or proprietary API 30 see 6 1 2 2 FCS_CKM 2 All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 118 of 135 NXP Semiconductors JCOP 2 4 2 R3 SF CRK MOK SF CRK DOK SF CRK GEC SF CRK DEC SF CRK DST Security Target Lite PUBLIC Management of DES AES RSA RSA CRT and EC keys with methods defined in packages javacard security of Java Card API 17 and proprietary methods defined in 30 see 6 1 2 3 FCS CKM 3 Destr
26. 5 OT SCP RECOVERY This objective is met by the component FRU FLT 2 SCP OT SCP SUPPORT This objective is met by the components FDP ROL 1 FIREWALL FCS COP 1 FCS CKM 1 FCS CKM 4 OT SCP IC This objective is met by the components FAU_ARP 1 FPT FLS 1 SCP FRU FLT 2 SCP FPT_PHP 3 and FPT_EMSEC 1 OT CARD MANAGEMENT This objective shall control the access to the card and implement the card issuers policy and is met by the components FDP ACC 1 LifeCycle All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 107 of 135 JCOP 2 4 2 R3 Security Target Lite PUBLIC NXP Semiconductors ACF 1 LifeCycle FMT MSA 1 LifeCycle FMT MSA 3 LifeCycle and FTP ITC 1 LifeCycle OT IDENTIFICATION Obviously the operations for FAU_SAS 1 SCP are chosen in a way that they require the TOE to provide the functionality needed for OT IDENTIFICATION The Initialisation Data or parts of them are used for TOE identification OT RND OT RND requires random numbers of a good cryptographic quality FCS_RNG 1 requires the TOE to provide random numbers of good quality by specifying class DRG 3 or DRG 2 of AIS 20 thus fulfilling OT RND It was chosen to define FCS_RNG 1 explicitly because Part 2 of the Common Criteria does not contain generic security functional requirements for Random Number generation Note that ther
27. APP KEYs FPT EMSEC 1 2 The TSF shall ensure assignment that unauthorized users are unable to use the following interface assignment electrical contacts to gain access to assignment TSF data D JCS KEYs and D CRYPTO and assignment User data D PIN D APP KEYs Functional Requirements for the Secure Box This group contains the functional requirements for the Secure Box which is part of the TOE FDP ACC 2 SecureBox Complete Access Control FDP ACC 2 1 SecureBox The TSF shall enforce the assignment Secure Box access control SFP on assignment S SBNativeCode O SB Content O NON SB Content O SB SFR O NON SB SFR and all operations among subjects and objects covered by the SFP Refinement The operations involved in the policy are eOP SB_ACCESS All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 95 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC eOP SB ACCESS SFR FDP ACC 2 2 SecureBox The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered by an access control SFP 6 1 15 2 ACF 1 SecureBox Security Attribute based Access Control FDP ACF 1 1 SecureBox The TSF shall enforce the assignment Secure Box access control SFP to all objects based on the following assignment S SBNativeCod
28. August 2013 39 of 135 NXP Semiconductors JCOP 2 4 2 R3 4 1 2 4 1 2 1 4 1 2 2 Approved OT RND Security Target Lite PUBLIC Smartcard Embedded Software The separation shall comprise software execution and data access Random Numbers The TOE will ensure the cryptographic quality of random number generation For instance random numbers shall not be predictable and shall have sufficient entropy The TOE will ensure that no information about the produced random numbers is available to an attacker since they might be used for instance to generate cryptographic keys Security Objectives for the TOE from 5 Identification OT SID Execution OT FIREWALL The TOE shall uniquely identify every subject applet or package before granting it access to any service The TOE shall ensure controlled sharing of data containers owned by applets of different packages or the JCRE and between applets and the TSFs See FIREWALL p 34 for details OT GLOBAL ARRAYS CONFID The TOE shall ensure that the APDU buffer that is shared by all applications is always cleaned upon applet selection The TOE shall ensure that the global byte array used for the invocation of the install method of the selected applet is always cleaned after the return from the install method OT GLOBAL ARRAYS INTEG The TOE shall ensure that only the currently selected OT NATIVE OT OPERATE OT REALLOCATION Note applications may have a writ
29. Card platform The TOE must provide a means to execute a set of operations atomically See 44 TRANSACTION p 38 for details OT KEY MNGT OT PIN MNGT OT TRANSACTION and OT CIPHER are actually provided to applets in the form of Java Card APIs Vendor specific libraries can also be present on the card and made available to applets those may be built on top of the Java Card API or independently The TOE shall ensure the object deletion shall not break references to objects See O0BJ DELETION p 36 for further details The TOE shall ensure that both applet and package deletion perform as expected See DELETION for details Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 41 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC OT LOAD The TOE shall ensure that the loading of a package into the card is safe Application Note Usurpation of identity resulting from a malicious installation of an applet on the card may also be the result of perturbing the communication channel linking the CAD and the card Even if the CAD is placed in a secure environment the attacker may try to capture duplicate permute or modify the packages sent to the card He may also try to send one of its own applications as if it came from the card issuer Thus this objective is intended to ensure the
30. Control 28 The additional family FPT_EMSEC TOE Emanation of the Class FPT Protection of the TSF is defined here to describe the IT security functional requirements of the TOE The TOE shall prevent attacks against the private signature key and other secret data where the attack is based on external observable physical phenomena of the TOE Examples of such attacks are evaluation of TOE s electromagnetic radiation simple power analysis SPA differential power analysis DPA timing attacks etc This family describes the functional requirements for the limitation of intelligible emanations which are not directly addressed by any other component of Common Criteria 1 part 2 Family behavior This family defines requirements to mitigate intelligible emanations Component leveling FPT EMSEC TOE emanation 1 FPT EMSECO 1 TOE emanation has two constituents FPT EMSEC 1 1 Limit of emissions requires to not emit intelligible emissions enabling access to TSF data or user data FPT EMSEC 1 2 Interface emanation requires not emit interface emanation enabling access to TSF data or user data Management FPT EMSEC 1 There are no management activities foreseen Audit FPT EMSEC 1 There are no actions defined to be auditable FPT EMSEC 1 TOE Emanation Hierarchical to No other components FPT EMSEC 1 1 The TOE shall not emit assignment types of emissions in excess of assignment specified limits enabli
31. Installer FAU ARP 1 Its security critical parts and procedures are also protected safe recovery from failure is ensured FPT_RCV 3 Installer applets installation may be cleanly aborted FDP ROL 1 FIREWALL communication with external users and their internal subjects is well controlled FDP ITC 2 Installer FIA ATD 1 AID FIA USB 1 AID to prevent alteration of TSF data also protected by components of the FPT class Furthermore authentication is protected by FIA AFL 1 PIN Almost every objective and or functional requirement indirectly contributes to this one too OT REALLOCATION This security objective is satisfied by the following SFRs FDP RIP 1 APDU FDP RIP 1 bArray FDP_RIP 1 ABORT RIP 1 KEYS FDP RIP 1 TRANSIENT FDP RIP 1 ODEL FDP RIP 1 OBJECTS RIP 1 ADEL which imposes that the contents of the re allocated block shall always be cleared before delivering the block OT RESOURCES Refined The TSFs detects stack memory overflows during execution of applications FAU ARP 1 FPT FLS 1 ADEL FPT FLS 1 FPT FLS 1 ODEL FPT FLS 1 Installer Failed installations are not to create memory leaks FDP ROL 1 FIREWALL FPT_RCV 3 Installer as well Memory management is controlled by the TSF FMT MTD 1 JCRE FMT_MTD 3 JCRE FMT SMR 1 Installer FMT SMR 1 FMT SMF 1 FMT SMR 1 ADEL FMT SMF 1 ADEL FMT SMF 1 CM FMT SMF 1 EXT MEM FMT SMR 1 CM Services OT ALARM This security objective is met by FPT_FLS 1 Installe
32. O CODE_PKG or O APPLET for the purpose of deleting them from the card Application note FDP ACF 1 2 ADEL e This policy introduces the notion of reachability which provides a general means to describe objects that are referenced from a certain applet instance or package e S ADEL calls the uninstall method of the applet instance to be deleted if implemented by the applet to inform it of the deletion request The order in which these calls and the dependencies checks are performed are out of the scope of this protection profile 6 1 6 3 RIP 1 ADEL Subset residual information protection FDP RIP 1 1 ADEL Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 81 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC The TSF shall ensure that any previous information content of a resource is made unavailable upon the deallocation of the resource from the following objects applet instances and or packages when one of the deletion operations in FDP ACC 2 1 ADEL is performed on them Application note Deleted freed resources both code and data may be reused depending on the way they were deleted logically or physically Requirements on de allocation during applet package deletion are described in 18 11 3 4 1 11 3 4 2 and 11 3 4 3 6 1 64 FMT MSA 1 ADEL Management
33. Package AID only if the invoked interface method extends the Shareable interface and one of the following conditions applies o The value of the attribute Selection Status of the package whose AID is Package AID is Multiselectable o The value of the attribute Selection Status of the package whose AID is Package AID is Non multiselectable and either Package AID is the value of the currently selected applet or otherwise Package AID does not occur in the attribute Active Applets e R JAVA 5 S PACKAGE may perform OP CREATE only if the value of the Sharing parameter is Standard FDP ACF 1 3 FIREWALL For this operation there is no accessed object the Sharing value thus refers to the parameter of the operation This rule simply enforces that shareable transient objects are not allowed Note parameters can be seen as security attributes whose value is under the control of the subject For instance during the creation of an object the JavaCardClass attribute s value is chosen by the creator NXP B V 2013 All rights reserved 61 of 135 Approved All information provided in this document is subject to legal disclaimers Evaluation documentation Rev 00 02 2nd August 2013 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC The TSF shall explicitly authorise access of subjects to objects based on the following additional rules e The subject S JCRE can freely perform OP JAVA and O
34. The card manager is part of the TOE and therefore the assumption is no longer relevant Leaving out the assumption makes the SPD in the ST more restrictive then the SPD in the PP 5 The card manager is part of the TOE is making sure that the Deletion of applets through the card manager is secure instead of assuming that it is handled by the card manager in the environment of the TOE Besides the assumptions from the PP are also three assumptions added e PROCESS SEC IC e USE_DIAG e USE_KEYS The assumption A PROCESS SEC IC is taken from the underlying certified hardware platform 10 which is compliant to 6 The assumptions A USE DIAG and A USE KEYS are included because the card manager is part of the TOE and no longer part of the environment Adding these assumptions this SPD is equivalent to the SPD in the PP 5 2 4 8 Security Objectives Statement The statement of security objectives in the ST presented in chapter 4 includes all security objectives as presented in the PP 5 but also includes a number of additional security objectives These security objectives are Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 21 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC e OT SEC BOX FW OT IDENTIFICATION e OT RND e OT MF_FW The security objectives OT IDENTIFI
35. also contributes to counter this threat T INTEG APPLI CODE LOAD This threat is countered by the security objective OT LOAD which ensures that the loading of packages is done securely and thus preserves the integrity of packages code By controlling the access to card management functions such as the installation update or deletion of applets the objective OT CARD MANAGEMENT contributes to cover this threat T INTEG APPLI DATA This threat is countered by bytecode verification OE VERIFICATION and the isolation commitments stated in the OT FIREWALL objective This latter objective also relies in its turn on the correct identification of applets stated in OT SID Moreover as the firewall is dynamically enforced it shall never stop operating as stated in the OT OPERATE objective As the firewall is a software tool automating critical controls the objective OT ALARM asks for it to provide clear warning and error messages so that the appropriate countermeasure can be taken The objectives OT CARD MANAGEMENT and OE VERIFICATION contribute to cover this threat by controlling the access to card management functions and by checking the bytecode respectively The objectives OT SCP RECOVERY and OT SCP SUPPORT are intended to support the OT OPERATE and OT ALARM objectives of the TOE so they are indirectly related to the threats that these latter objectives contribute to counter Concerning the confidentiality and integrity of application sensitive d
36. assignment EC 160 192 224 256 320 bits with the domain parameters provided in NIST DSS standard FIPS 186 3 42 Appendix D or in Brainpool ECC Standard Curves 34 chapters 3 1 to 3 5 that meet the following assignment ISO 14888 3 26 Application Notes 1 The input and output values of this function have to be treated as secret values 2 The security functionality is resistant against side channel analysis and similar techniques It is demonstrated for curves defined by NIST 42 and Brainpool 34 only To fend off attackers with high attack potential an adequate key length must be used references can be found in national and international documents and standards FCS COP 1 1 SHA 1 The TSF shall perform assignment secure hash computation in accordance with a specified cryptographic algorithm assignment SHA 1 and cryptographic key sizes assignment none that meet the following assignment FIPS 180 3 27 Section 6 Application note The SHA and SHA 2 functions provide limited side channel resistance when the same input is used for a limited number of times The composite evaluator is advised to consult the ETR for composition when performing composite certifications FCS COP 1 1 SHA 224 The TSF shall perform assignment secure hash computation in accordance with a specified cryptographic algorithm assignment SHA 224 and cryptographic key sizes assignment none that meet the following assignment FIPS 1
37. code is available and released by the TOE designer The users are applet developers the card manager developers and possibly the final user of the TOE The applet and API packages programmers should have a complete understanding of the concepts defined in 18 and 19 They must delegate key management PIN Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 97 of 135 NXP Semiconductors JCOP 2 4 2 H3 Approved Security Target Lite PUBLIC management and cryptographic operations to dedicated APIs They should carefully consider the effect of any possible exception or specific event and take appropriate measures such as catch the exception abort the current transaction and so on They must comply with all the recommendations given in the platform programming guide as well Failure to do so may jeopardize parts of or even the whole applet and its confidential data This guidance also includes the fact that sharing object s or data between applets through shareable interface mechanism for instance must include some kind of authentication of the involved parties even when no sensitive information seems at stake so called defensive development e AGD PRE 1 Preparative procedures This SAR ensures the integrity of the TOE and its documentation during the transfer of the TOE between all the a
38. described in Section 1 3 3 Applets are only considered in their CAP format and the process of compiling the source code of an application and converting it into the CAP format does not regard the TOE or its environment On the contrary the process of verifying applications in its CAP format and loading it on the card is a crucial part of the TOE environment and plays an important role as a complement of the TSFs Smart Card Platform The smart card platform SCP is composed of a micro controller and hardware abstraction layer containing the cryptographic library see Section 1 3 1 No separate operating system is present in this card It provides memory management functions such as separate interface to RAM and NVRAM I O functions that are compliant with ISO standards transaction facilities and secure implementation of cryptographic functions All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 18 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC 1 3 7 Native Applications Apart from Java Card applications the final product may contain native applications as well Native applications are outside the scope of the TOE security functions TSF and they are usually written in the assembly language of the platform hence their name This term also designates software libraries providing ser
39. disclose a piece of code Native applications are also harmless because of the objective OT NATIVE so no application can be run to disclose a piece of code The 4 VERIFICATION security aspect is addressed in this PP by the objective for the environment OE VERIFICATION The objectives OT CARD MANAGEMENT and OE VERIFICATION contribute to cover this threat by controlling the access to card management functions and by checking the bytecode respectively Finally the objective OT EXT MEM provides access control for external memory and therefore also contributes to counter this threat T CONFID JCS DATA This threat is covered by bytecode verification OE VERIFICATION and the isolation commitments stated in the OT FIREWALL security objective This latter objective also relies in its turn on the correct identification of applets stated in OT SID Moreover as the firewall is dynamically enforced it shall never stop operating as stated in the OT OPERATE objective As the firewall is a software tool automating critical controls the objective OT ALARM asks for it to provide clear warning and error messages so that the appropriate countermeasure can be taken The objectives OT CARD MANAGEMENT and OE VERIFICATION contribute to cover this threat by controlling the access to card management functions and by checking the bytecode respectively The objectives OT SCP RECOVERY and OT SCP SUPPORT are intended to support the OT OPERATE and OT ALARM object
40. enforce the FIREWALL access control SFP and the JCVM information flow control SFP to permit the rollback of the operations OP JAVA and OP CREATE on the object O JAVAOBJECT FDP ROL 1 2 FIREWALL The TSF shall permit operations to be rolled back within the scope of a select deselect process install or uninstall call notwithstanding the restrictions given in 18 87 7 within the bounds of the Commit Capacity 18 7 8 and those described in 17 Application note Transactions are a service offered by the APIs to applets It is also used by some APIs to guarantee the atomicity of some operation This mechanism is either implemented in Java Card platform or relies on the transaction mechanism offered by the underlying platform Some operations of the API are not conditionally updated as documented in 17 see for instance PIN blocking PIN checking update of Transient objects Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 73 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC 6 1 3 Card Security Management 6 1 3 1 FAU ARP 1 Security Alarms FAU ARP 1 1 The TSF shall take one of the following actions e throw an exception e lock the card session e reinitialize the Java Card System and its data e assignment apply a set of rules to monitor and audit these
41. following events also see 6 1 3 1 SF AUD VFJ SF AUD AOF SF AUD ORE SF AUD CDT Violation of the Firewall or JCVM SFPs in fulfillment of FAU 7 and FLS 1 Array overflow in fulfillment of FAU AHP 1 and FPT_FLS 1 Other runtime errors like uncaught exceptions CAP file inconsistency errors in operands of a bytecode access violations in fulfillment of FAU ARP 1 and FPT_FLS 1 Card tearing unexpected removal of the Card out of the CAD and power failure in fulfillment of FAU_ARP 1 and FPT_FLS 1 SF Audit shall throw an exception lock the card session or reinitialize the Java Card System and its data upon detection of one or more of these potential security violations or respond automatically in the specified way see 6 1 12 3 according to the ST lite 10 Note The following reactions by the TOE based on indication of a potential violation of the TSP are possible a Throw an exception b O d Terminate the card Life cycle state TERMINATED Reinitialize the Java Card System warm reset responding automatically according to FPT_PHP 3 10 integrity of the EEPROM and the ROM The EEPROM is able to correct a 1 bit error within each byte The ROM provides a parity check The EEPROM corrects errors automatically without user interaction a ROM parity error forces a reset e Lock the card session simply stops processing escape with reset the session Card tearing Based on th
42. functional cloning is indirectly covered by the threats described below 3 3 1 2 Threats TOE operational environment The TOE is intended to protect itself against the following threats e Manipulation of User Data and of the Smart Card Native Operating System while being executed processed and while being stored in the TOE s memories and e Disclosure of User Data and of the Smart Card NOS while being processed and while being stored in the TOE s memories The TOE s countermeasures are designed to avert the threats described below Nevertheless they may be effective in earlier phases phases 4 to 6 Though the Native Operating System normally stored in the ROM will in many cases not contain secret data or algorithms it must be protected from being disclosed since for instance knowledge of specific implementation details may assist an attacker In many cases critical User Data and NOS configuration data TSF data will be stored in the EEPROM Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 26 of 135 NXP Semiconductors JCOP 2 4 2 R3 3 3 1 3 Software Threats Security Target Lite PUBLIC The most basic function of the Native Operating System is to provide data storage and retrieval functions with a variety of access control mechanisms which can be configured to suit the embedded appl
43. implemented algorithms 1 7 4 The security functionality is resistant against side channel analysis and similar techniques It is demonstrated for curves defined by NIST 42 and Brainpool 34 only All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 66 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC 5 To fend off attackers with high attack potential an adequate key length must be used references can be found in national and international documents and standards 6 The suggested key length for the RSA algorithm according to BSI TR 02102 39 is 2000 bits 6 1 2 2 FCS 2 Cryptographic Key Distribution FCS CKM 2 1 The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method assignment methods set keys and components of DES AES RSA RSA CRT secure messaging and EC that meets the following assignment 17 30 Application note e The keys can be accessed as specified in 17 Key class and 30 for proprietary classes e This component shall be instantiated according to the version of the Java Card API applying to the security target and the implemented algorithms 17 and 30 for proprietary classes 6 1 2 3 FCS CKM 3 Cryptographic Key Access FCS CKM 3 1 The TSF shall perform assignment management of D
44. included 6 5 Security Assurance Requirements Rationale 6 5 1 1 Evaluation Assurance Level Rationale An assurance requirement of EAL5 is required for this type of TOE since it is intended to defend against sophisticated attacks This evaluation assurance level was selected since itis designed to permit a developer to gain maximum assurance from positive security engineering based on good commercial practices EAL5 represents the highest practical level of assurance expected for a commercial grade product In order to provide a meaningful level of assurance that the TOE provides an adequate level of defense against such attacks the evaluators should have access to the low level design and source code The lowest for which such access is required is EAL5 The assurance level EAL5 is achievable since it requires no specialist techniques on the part of the developer 6 5 1 2 Assurance Augmentations Rationale Additional assurance requirements are also required due to the definition of the TOE and the intended security level to assure ALC DVS 2 Sufficiency of security measures Development security is concerned with physical procedural personnel and other technical measures that may be used in the development environment to protect the TOE This assurance component is a higher hierarchical component to EAL5 only ALC DVS 1 is found in EAL5 Due to the nature of the TOE there is a need to justify the sufficiency of these procedures to p
45. initialization is initiated at startup when the first APDU is received using the PTRNG of the HW platform conform to class P2 in 32 generates output for which assignment 225 strings of bit length 128 are mutually different with probability above assignment 1 27 e DRG 3 5 Statistical test suites cannot practically distinguish the random numbers from output sequences of an ideal RNG The random numbers must pass test procedure A assignment no additional tests Application note 1 DRG 3 1 DRG 3 4 With perspective to DRNG seeding with P2 and PTG 2 can be considered as equivalent 32 Application note 2 The selection of the DRNG class is done via fab key settings during pre personalization which allows running the DRNG either as class DRG 3 or class DRG 2 compatible DRNG The default setting is DRG 2 6 1 14 5 FCS RNG 1 RNG2 Quality metric for Random Numbers FCS RNG 1 1 RNG2 The TSF shall provide a deterministic random number generator that implements e Class DRG 2 of 8 e DRG 2 1 If initialized with a random seed selection assignment using the PTRNG of the HW platform conform to class P2 in AIS31 32 the internal state of the RNG shall selection have at least 100 bit MIN entropy e DRG 2 2 The RNG provides forward secrecy e DRG 2 3 The RNG provides backward secrecy Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evalu
46. integrity and authenticity of loaded CAP files OT INSTALL The TOE shall ensure that the installation of an applet performs as expected See INSTALL for details 4 1 2 6 Card Management The TOE Security Objective for the card manager is a Security Objective for the environment in 5 In the present case the card manager belongs to the TOE and the corresponding Security Objective is listed here OT CARD MANAGEMENT The card manager shall control the access to card management functions such as the installation update or deletion of applets It shall also implement the card issuer s policy on the card The card manager is an application with specific rights which is responsible for the administration of the smart card This component will in practice be tightly connected with the TOE which in turn shall very likely rely on the card manager for the effective enforcing of some of its security functions Typically the card manager shall be in charge of the life cycle of the whole card as well as that of the installed applications applets The card manager should prevent that card content management loading installation deletion is carried out for instance at invalid states of the card or by non authorized actors It shall also enforce security policies established by the card issuer Note The Security Objective from 5 for the environment OE CARD MANAGEMENT is listed as TOE security objective for the TOE in section 4 1 2 6 as
47. is generally not implemented because of limited memory resources and or limitations due to exportation Therefore the following requirements only apply to the implemented subset It should be noticed that the execution of the additional native code is not within the TSF Nevertheless access to API native methods from the Java Card System is controlled by TSF because there is no difference between native and interpreted methods in their interface or invocation mechanism FCS CKM 1 Cryptographic Key Generation FCS CKM 1 1 The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm assignment JCOP RNG and specified cryptographic key sizes assignment DES 112 168 Bit RSA 1976 2048 Bit 39 AES 128 192 256 Bit EC key generation EC 160 192 224 256 320 bits with the domain parameters provided in NIST DSS standard FIPS 186 3 42 Appendix D or in Brainpool ECC Standard Curves 34 chapters 3 1 to 3 5 that meet the following assignment ISO 15946 1 2008 16 Application note 1 The keys can be generated and diversified in accordance with 17 specification in classes KeyBuilder and KeyPair at least Session key generation 2 RSA key pairs in straightforward format or CRT format are supported EC FP is supported but EC F2M is not supported 3 This component shall be instantiated according to the version of the Java Card API applying to the security target and the
48. is therefore equivalent to the security objectives in the PP JCPP to which conformance is claimed 2 4 4 Security Requirements Statement The statement of security functional requirements copies most SFRs as defined in the PP 5 with the exception from a number of options For the copied set of SFRs the ST is considered equivalent to the statement of SFRs in the PP 5 The TOE restricted remote access from the CAD to the services implemented by the applets on the card to none and as a result FDP_ACF 1 JCRMI is modified The remaining SFRs FDP_IFC 1 JCRMI IFF 1 JCRMI FMT MSA 1 EXPORT FMT MSA 1 REM REFS FMT MSA 3 JCRMI FMT_SMF 1 JCRMI FMT REV 1 JCRMI and FMT SMR 1 JCRMI are not included the ST By removing the RMI the statement of security functional requirements is more restrictive then the PP 5 The ST includes the relevant SFRs from the platform ST 10 of this composite product These SFRs are FPT_FLS 1 SCP FRU FLT 2 SCP FPT_PHP 3 SCP FDP ACC 1 SCP FDP_ACF 1 SCP FMT MSA 3 SCP FAU SAS 1 SCP For this set of SFRs the ST is considered equivalent to the statement of SFRs in the PP 5 because it realizes a 6 conformant platform which fully meets the objectives as stated in section 1 2 of the PP 5 Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 22 of 135 NXP Se
49. maintenance mode where the ability to return to a secure state is provided FPT RCV 3 2 Installer For assignment a failure during load installation of a package applet the TSF shall ensure the return of the TOE to a secure state using automated procedures FPT RCV 3 3 Installer The functions provided by the TSF to recover from failure or service discontinuity shall ensure that the secure initial state is restored without exceeding assignment 096 for loss of TSF data or objects under the control of the TSF FPT_RCV 3 4 Installer The TSF shall provide the capability to determine the objects that were or were not capable of being recovered ADELG Security Functional Requirements This group consists of the SFRs related to the deletion of applets and or packages enforcing the applet deletion manager ADEL policy on security aspects outside the runtime Deletion is a critical operation and therefore requires specific treatment This policy is better thought as a frame to be filled by ST implementers FDP ACC 2 ADEL Complete access control FDP ACC 2 1 ADEL The TSF shall enforce the ADEL access control SFP on S ADEL S JCRE S JCVM O JAVAOBJECT O APPLET and O CODE_PKG and all operations among subjects and objects covered by the SFP Refinement The operations involved in the policy are e OP DELETE APPLET e OP DELETE PCKG e OP DELETE PCKG APPLET FDP ACC 2 2 ADEL The TSF shall ensure that all operations between any subject co
50. memory feature is a objective described in Appendix A of the PP 5 and comes with the compliance to Java Card 3 0 1 OT EXT MEM The TOE shall provide controlled access means to the external memory and ensure that the external memory does not address Java Card System memory containing User Data and TSF Data 4 2 Security objectives for the operational environment The Security Objectives for the operational environment are summarized in the following table Table 11 Security Objectives for the operational environment Name Source Refined OE USE DIAG OE USE KEYS OE PROCESS_SEC_IC OE VERIFICATION 5 no OE APPLET 5 no 4 2 1 Security Objectives for the operational environment not contained in 5 4 2 1 1 Objectives on Phase 7 OE USE DIAG Secure TOE communication protocols shall be supported and used by the environment OE USE KEYS During the TOE usage the terminal or system in interaction with the TOE shall ensure the protection integrity and confidentiality of their own keys by operational means and or procedures Note Objectives for the TOE environment are usually not satisfied by the TOE Security Functional Requirements Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 43 of 135 NXP Semiconductors JCOP 2 4 2 R3 4 2 2 OE PROCESS SEC IC Security Ta
51. resource from the following objects any reference to an object instance created during an aborted transaction Application note The events that provoke the de allocation of a transient object are described in 18 5 1 6 1 2 7 FDP_RIP 1 APDU Subset Residual Information Protection FDP RIP 1 1 APDU The TSF shall ensure that any previous information content of a resource is made unavailable upon the allocation of the resource to the following objects the APDU buffer Application note The allocation of a resource to the APDU buffer is typically performed as the result of a call to the process method of an applet 6 1 2 8 FDP RIP 1 bArray Subset Residual Information Protection FDP RIP 1 1 bArray The TSF shall ensure that any previous information content of a resource is made unavailable upon the de allocation of the resource from the following objects the bArray object Application note resource is allocated to the bArray object when a call to an applet s install method is performed There is no conflict with FDP ROL 1 here because of the Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 72 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC bounds on the rollback mechanism FDP_ROL 1 2 FIREWALL the scope of the rollback does not extend outside the execution of the ins
52. the CPU Mode e Change the values in the MMU Segment Table to assign RAM to the Secure Box e Change the values in the MMU Segment Table to assign EEPROM to the Secure Box 6 2 Security Assurance Requirements The assurance requirements of this evaluation are EAL5 augmented by ALC_DVS 2 ASE TSS 2 and AVA VAN 5 The assurance requirements ensure among others the security of the TOE during its development and production We present here some application notes on the assurance requirements included in the EAL of the ST e ADV FSP 5 Complete semi formal functional specification with additional error information e ADV ARCA Security architecture description e ADV TDS 4 Semiformal modular design e ADV INT 2 Well structured internals These SARs ensure that the TOE will be able to meet its security requirements and fulfill its objectives The Java Card System shall implement the Java Card API 17 The implementation of the Java Card API shall be designed in a secure manner including specific techniques to render sensitive operations resistant to state of art attacks e OPE 1 Operational user guidance These SARs ensure proper installation and configuration the TOE will be correctly configured and the TSFs will be put in good working order The administrator is the card issuer the platform developer the card embedder or any actor who participates in the fabrication of the TOE once its design and development is complete its source
53. the FIREWALL access control SFP to restrict the ability to modify the security attributes Selected Applet Context to the Java Card RE S JCRE Note The modification of the Currently Active Context should be performed in accordance with the rules given in 18 4 and 19 3 4 6 1 1 7 FMT_MSA 1 JCVM Management of Security Attributes FMT_MSA 1 1 JCVM The TSF shall enforce the FIREWALL access control SFP and the JCVM information flow control SFP to restrict the ability to modify the security attributes Currently Active Context and Active Applets to the Java Card VM S JCVM Note The modification of the Currently Active Context should be performed in accordance with the rules given in 18 4 and 19 3 4 For this TOE there are no native methods Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 64 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC 6 1 1 8 FMT MSA 2 FIREWALL JCVM Secure Security Attributes FMT MSA 2 1 FIREWALL JCVM The TSF shall ensure that only secure values are accepted for all the security attributes of subjects and objects defined in the FIREWALL access control SFP and the JCVM information flow control SFP 6 1 1 9 FMT MSA 3 FIREWALL Static Attribute Initialisation FMT MSA 3 1 FIREWALL The TSF shall enforce the FIREWALL access control SFP to
54. the applet that owns the deleted objects by invoking a specific API method FDP RIP 1 ODEL Subset residual information protection FDP RIP 1 1 ODEL The TSF shall ensure that any previous information content of a resource is made unavailable upon the deallocation of the resource from the following objects the objects owned by the context of an applet instance which triggered the execution of the method javacard framework JCSystem requestObjectDeletion Application note e Freed data resources resulting from the invocation of the method javacard framework JCSystem requestObjectDeletion may be reused Requirements on deallocation after the invocation of the method are described in 17 e There is no conflict with ROL 1 here because of the bounds on the rollback mechanism the execution of requestObjectDeletion is not in the scope of the rollback because it must be performed in between APDU command processing and therefore no transaction can be in progress 6 1 8 2 FPT FLS 1 ODEL Failure with preservation of secure state 6 1 9 1 Approved FPT FLS 1 1 ODEL The TSF shall preserve a secure state when the following types of failures occur the object deletion functions fail to delete all the unreferenced objects owned by the applet that requested the execution of the method Application note The TOE may provide additional feedback information to the card manager in case of potential security violation see FAU_ARP 1
55. the class of the object This is the object s information to which the CAD can access O EXT MEM INSTANCE Any External Memory Instance created from the MemoryAccess Interface of the Java Card API 17 O SB Content The code and data elements of the native code library residing in the Secure Box O NON SB Content Any code and data elements not assigned to the native code library residing in the Secure Box O SB SFR The pool of SFR s assigned to be accessible by native code residing in the Secure Box O NON SB SFR All SFR s which are not assigned to the Secure Box Especially the SFR s used to configure the MMU Information prefixed with an I is described in the following table Table 17 Information Descriptions Information Description APDU Any APDU sent to or from the card through the communication channel IDATA JCVM Reference Data objectref addresses of APDU buffer JCRE owned instances of APDU class and byte array for install method I RORD Remote object reference descriptors which provide information concerning i the identification of the remote object and ii the implementation class of the object or the interfaces implemented by the class of the object The descriptor is the only object s information to which the CAD can access Security attributes linked to these subjects objects and information are described in the following table with their values Table 18 Security Attribute Descriptions S
56. the objects Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 106 of 135 NXP Semiconductors JCOP 2 4 2 H3 Approved 6 3 3 Security Target Lite PUBLIC OT REMOTE Refined The access to the TOE s internal data and the flow of information from the card to the CAD required by the JCRMI service is under control of the JCRMI access control policy FDP_ACC 2 JCRMI FDP_ACF 1 JCRMI OT TRANSACTION Directly met by FDP_ROL 1 FIREWALL FDP RIP 1 ABORT RIP 1 ODEL RIP 1 APDU RIP 1 bArray FDP RIP 1 KEYS FDP RIP 1 ADEL FDP_RIP 1 TRANSIENT and FDP RIP 1 OBJECTS more precisely by the element RIP 1 1 ABORT Object Deletion OT OBJ DELETION This security objective specifies that deletion of objects is secure The security objective is met by the security functional requirements FDP RIP 1 ODEL and FPT FLS 1 ODEL Applet Management OT DELETION This security objective specifies that applet and package deletion must be secure The non introduction of security holes is ensured by the ADEL access control policy FDP_ACC 2 ADEL ACF 1 ADEL The integrity and confidentiality of data that does not belong to the deleted applet or package is a by product of this policy as well Non accessibility of deleted data is met by FDP RIP 1 ADEL and the TSFs are protected against possi
57. timing attacks Enhanced security sensors for clock frequency range low and high temperature sensor supply voltage sensors Single Fault Injection SFI attack detection Light sensors included integrated memory light sensor functionality Implementation of protection of the code fetch from ROM RAM and EEPROM Security of memory is based on encryption and physical measures for RAM EEPROM and ROM Memory Management Unit MMU The in hardware implemented MMU is able to perform access control to all types of memory and the special functions registers depending on the current CPU mode Secure Lock of Testmode The testmode of the hardware is disabled after the production test The hardware prevents that this mode can be enabled or reached afterwards to disclose or manipulate TSF data Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 126 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC 8 Bibliography 1 Common Criteria for Information Technology Security Evaluation Part 1 Version 3 1 Revision 4 September 2012 2 Common Criteria for Information Technology Security Evaluation Part 2 Version 3 1 Revision 4 September 2012 3 Common Criteria for Information Technology Security Evaluation Part 3 Version 3 1 Revision 4 September 2012 4 Common Methodo
58. to modify assignment create the security attributes assignment keys used to secure the communication between S PACKAGE CM and S CAD to assignment S PACKAGE CM Note This requirement is no contradiction to ACF 1 LifeCycle which allows S ROOTAPP to manipulate keys because FMT_MSA 1 CM describes the behaviour starting with the OS Internal Life Cycle State FUSED which is mandatory for phase 7 of the lyfe cycle model 6 1 9 7 FMT MSA 3 CM Static attribute initialisation FMT MSA 3 1 CM The TSF shall enforce the PACKAGE LOADING information flow control SFP to provide restrictive default values for security attributes that are used to enforce the SFP FMT MSA 3 2 CM The TSF shall allow the assignment none to specify alternative initial values to override the default values when an object or information is created 6 1 9 8 FMT SMF 1 CM Specification of Management Functions FMT SMF 1 1 CM The TSF shall be capable of performing the following management functions assignment e modification and creation of the keys used to secure the communication between S PACKAGE CM and S CAD e modify the behaviour of functions modify the list of registered applets AID modify the card life cycle state attribute 6 1 9 9 FMT SMR 1 CM Security roles FMT SMR 1 1 CM The TSF shall maintain the roles assignment S PACKAGE CM S ROOTAPP FMT SMR 1 2 CM The TSF shall be able to associate users with roles 6 1 9 10 FTP IT
59. 1 Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 100 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC Table 26 Assignment Security Objectives for the TOE Security Requirements 2 FMT MTD 3 JCRE x FDP ITC 2 Installer FPT FLS 1 Installer FMT_MSA 3 ADEL FMT SMF 1 ADEL FMT SMR 1 ADEL FPT FLS 1 ADEL FDP RIP 1 ADEL FMT MSA 1 ADEL FPT FLS 1 FMT SMR 1 Installer FDP ACF 1 JCRMI FDP ACF 1 ADEL FDP ACC 2 JCRMI FPT TDC 1 FIA_ATD 1 AID FPT RCV 3 Installer FDP ACC 2 ADEL FIA UID 2 AID x FIA USB 1 AID FMT MTD 1 JCRE FPR UNO 1 OT SID OT FIREWALL OT GLOBAL ARRAYS CONFID x OT GLOBAL ARRAYS INTEG OT NATIVE OT OPERATE X X X X x X x OT REALLOCATION x OT RESOURCES x X x X X X X X X OT ALARM x OT CIPHER x OT KEY MNGT X OT PIN MNGT x x OT REMOTE X x OT TRANSACTION x OT OBJ DELETION OT DELETION X X X X X X X X OT LOAD OT INSTALL X x OT SCP IC OT SCP RECOVERY OT SCP SUPPORT OT EXT MEM Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 101 of 135 JCOP 2 4 2 R3 NXP Semiconductors
60. 1 ADEL FMT_SMF 1 ADEL No dependencies FMT_SMR 1 ADEL FIA_UID 1 No rationale in Section 6 4 1 FPT_FLS 1 ADEL No dependencies FDP_ACC 2 JCRMI FDP_ACF 1 Yes Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 108 of 135 NXP Semiconductors JCOP 2 4 2 R3 Security Target Lite PUBLIC SFR Dep Met FDP ACF 1 JCRMI No not fully rationale in FDP ACC 1 Section 6 4 1 FHFERGESUJERMI FMT_MSA 3 FDP_ACC 2 JCRMI FDP_RIP 1 ODEL No dependencies FPT_FLS 1 ODEL No dependencies Yes ae PASTO FIA UID 1 CM Yes FO 20 FDP_IFF 1 CM Yes FDP_IFC 1 FDP_IFF 1 CM IFC 1 CM ridi FMT_MSA 3 CM Yes FDO ACC 1 or FDP_IFC 1 FDP UIT 1 CM FTP ITC1 TRP 1 EDP_IFC 2 CM FTP_ITC 1 CM FIA UID 1 CM No dependencies FDP_ACC 1 or Yes FDP_IFC 1 and FDP_IFC 2 CM FMT_MSA 1 CM FMT_SMF 1 and FMT_SMF 1 CM FMT_SMR 1 FMT_SMR 1 CM FMT_MSA 1 FMT MSA 3 CM FMT SMR 1 FMT MSA 1 CM FMT_SMR 1 CM FMT_SMF 1 CM No dependencies Yes FMT SMR 1 CM FIA UID 1 FIA UID 1 CM FTP ITC 1 CM No dependencies FDP ACC 2 FIREWALL FDP ACF 1 li FDP ACF 1 FIREWALL FDP ACC 1 Yes FDP_ACF 1 FIREWALL TMSA FDP ACC 2 FIREWALL FMT MSA 3 FMT MSA 3 FIREWALL Yes FDP_IFF 1 JC
61. 197 Federal Information Processing Standards Publication 197 Announcing the ADVANCED ENCRYPTION STANDARD AES November 26 2001 42 Digital Signature Standard DSS FIPS PUB 186 3 FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION June 2009 43 RFC 5639 ECC Brainpool Standard Curves amp Curve Generation March 2010 available at http tools ietf org html rfc5639 44 ISO IEC 14888 3 Information technology Security techniques Digital signatures with appendix Part 3 Discrete logarithm based mechanisms 2008 45 PKCS 3 Diffie Hellman Key Agreement Standard RSA Laboratories Technical Note Version 1 4 Revised November 1 1993 1 1993 Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 129 of 135 NXP Semiconductors JCOP 2 4 2 R3 9 Legal information Security Target Lite 9 1 Definitions Draft The document is a draft version only The content is still under internal review and subject to formal approval which may result in modifications or additions NXP Semiconductors does not give any representations or warranties as to the accuracy or completeness of information included herein and shall have no liability for the consequences of use of such information 9 2 Disclaimers Limited warranty and liability Information in this document is believed to
62. 2_ M65 65 NX250A 01 Note Differences between Mask 64 and Mask 65 The difference between Mask 64 and Mask 65 is not in the functionality it is only in the way the implementation resides in the TOE for Mask 64 all sources are compiled to be located in the ROM for Mask 65 the EC implementation resides in the EEPROM Furthermore in mask 65 the implementations of Korean SEED and FIPS selftests are not available The two configurations of Mask 65 differ in the EEPROM which is available for the applications Namely 120 KB for the 120 and 80 KB for the 82 this is also reflected in the explanations for the commercial product name The commercial product names of JCOP products have the following form Jabcccxdd d mvsrrff o The hardware guidance manual is only required for developers of native libraries Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 14 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC In case of a pure contact product a 1 or a 2 the option field o is absent Pure contact products cannot support MIFARE With respect to MIFARE these products correspond to contactless products in Config A 0 0 The J is constant the other letters are variables For a detailed description of these variables please see Table 7 For the certified products some va
63. 3 4 3 1 4 3 1 1 4 3 1 2 4 3 1 8 4 3 2 4 3 2 1 4 3 2 2 4 3 2 3 5 5 1 5 2 5 3 6 6 1 6 1 1 6 1 1 1 6 1 1 2 Bytecode 34 CAP File Verification 34 Integrity and Authentication 35 Linking and Verification 35 Card 35 KIT c 36 Security objectives for the TOE 38 Security Objectives for the TOE not contained in 39 Security Objectives for the TOE from 5 40 Identification sssssssseseeeeeeee 40 E PEE 40 KIC T E 41 Object 41 Applet 41 Card 42 Smart Card 42 EMG Extended 43 Security objectives for the operational ENVIFONMENL oii iH Aeneas 43 Security Objectives for the operational environment not contained in 5 43 Objectives on Phase 7 43 Security Objectives for the operational environment from 5
64. 3 6 1 2 4 6 1 2 5 6 1 2 6 6 1 2 7 6 1 2 8 6 1 2 9 6 1 2 10 6 1 2 11 6 1 3 6 1 3 1 6 1 3 2 6 1 3 3 6 1 3 4 6 1 3 5 6 1 4 6 1 4 1 6 1 4 2 6 1 4 3 6 1 4 4 FDP_IFC 1 JCVM Subset Information Flow e 63 IFF 1 JCVM Simple Security Attributes 63 RIP 1 OBJECTS Subset Residual Information Protection 64 FMT MSA 1 JCRE Management of Security Attributes iacente ecc eed 64 FMT_MSA 1 JCVM Management of Security Attributes 64 FMT MSA 2 FIREWALL JCVM Secure Security Attributes 65 FMT_MSA 3 FIREWALL Static Attribute Initialisation sesssseseeeeeeese 65 FMT MSA 3 JCVM Static Attribute Initialisation nne 65 FMT SMF 1 Specification of Management FUNCTIONS TREE 65 FMT SMR 1 Security roles 66 Application Programming Interface 66 FCS CKM 1 Cryptographic Key Generation 66 FCS CKM 2 Cryptographic Key Distribution 67 FCS CKM 3 Cryptographic Key Access 67 FCS CKM 4 Cryptographic Key Destruction 67 FCS COP 1 Cryptographic Operation 67 FDP RIP 1 ABORT Subset Residual Information Protection nnnnnnnnnnrnrnrnrnrnrnrnrnrnrnnnnnnnnnnnnn nenna 72 FDP_RIP 1 APDU Subset Residual Information 72 RIP 1 bArray Subset Residual Information Protection
65. 3 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 15 of 135 NXP Semiconductors JCOP 2 4 2 R3 Security Target Lite PUBLIC Variable ccc dd d Meaning JCOP version EEPROM size in KB JCOP type Delivery type Manufacturing Site Code Silicon Version Code Silicon Version Subcode ROM Code ID FabKey ID Option Example Values A C D E G 145 120 82 G C others UO UA UE XS XT A4 A6 HN1 others 0 1 Parameter settings JCOP V2 4 1 R3 JCOP V2 4 2 R1 JCOP V2 4 2 R2 JCOP V2 4 2 R3 JCOP V3 0 144 KB EEPROM 120 KB EEPROM 80 KB EEPROM Generic Customized others are possible and are application dependent 729um unsawn unthinned wafer inkless 150 sawn wafer inkless 75um sawn wafer inkless PDM PCM module PDM PCM Pd Silver not for 5 0145 MOB6 HVQFN32 package other delivery forms Config A MIFARE Flex with No MIFARE Classic Config B1 MIFARE FleX with MIFARE Classic 1K Config B4 MIFARE FleX with MIFARE Classic4k Config A No MIFARE DESFire With the introduction of the P5Cx081 family the EEPROM size of the product name has been increased by one to indicate the new family This means that P5Cx081 only has 80 KB EEPROM and the P5Cx145 has only 144 KB EEPROM Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reser
66. 5 for details Directly threatened asset s D SEC DATA any other asset may be jeopardized should this attack succeed depending on the virulence of the installed application 3 3 2 7 Services T OBJ DELETION The attacker keeps a reference to a garbage collected object in order to force the TOE to execute an unavailable method to make it to crash or to gain access to a memory containing data that is now being used by another application See O0BJ DELETION 36 for further details Directly threatened asset s D APP C DATA D APP I DATA and D APP KEYs 3 3 2 8 Miscellaneous T PHYSICAL The attacker discloses or modifies the design of the TOE its sensitive data TSF and User Data or application code or disables security features of the TOE by physical opposed to logical tampering means This threat includes IC failure analysis electrical probing unexpected tearing and DPA That also includes the modification of the runtime execution of Java Card System or SCP software through alteration of the intended execution order of set of instructions through physical tampering techniques This threatens all the identified assets This threat refers to the point 7 of the security aspect 4 SCP Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 30 of 135 NXP Semiconductors JCOP 2 4 2 R3
67. 80 3 27 Section 6 Application note The SHA and SHA 2 functions provide limited side channel resistance when the same input is used for a limited number of times The composite evaluator is advised to consult the ETR for composition when performing composite certifications FCS COP 1 1 SHA 256 The TSF shall perform assignment secure hash computation in accordance with a specified cryptographic algorithm assignment SHA 256 and cryptographic key sizes assignment none that meet the following assignment FIPS 180 3 27 Section 6 Application note The SHA and SHA 2 functions provide limited side channel resistance when the same input is used for a limited number of times The composite evaluator is advised to consult the ETR for composition when performing composite certifications FCS COP 1 1 AES CMAC The TSF shall perform assignment message authentication and verification in accordance with a specified cryptographic algorithm assignment AES CMAC and cryptographic key sizes assignment 128 192 256 bit that meet the following Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 71 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC assignment Advanced Encryption Standard AES FIPS Publication 197 21 NIST Special Publication 800 38B 29 Section 5 an
68. C 1 CM Inter TSF trusted channel FTP ITC 1 1 CM The TSF shall provide a communication channel between itself and another trusted IT product that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure ITC 1 2 CM Editorially Refined The TSF shall permit the CAD placed in the card issuer secured environment to initiate communication via the trusted channel FTP ITC 1 3 CM The TSF shall initiate communication via the trusted channel for loading installing a new application package on the card Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 87 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC Application note There is no dynamic package loading on the Java Card platform New packages can be installed on the card only on demand of the card issuer 6 1 10 EMG Security Functional Requirements This group includes requirements for managing the external memory 6 1 10 1 FDP ACC 1 EXT MEM Subset access control ACC A 1 EXT MEM The TSF shall enforce the EXTERNAL MEMORY access control SFP on subject S APPLET object O EXT MEM INSTANCE and operations OP CREATE EXT MEM INSTANCE OP READ EXT MEM and OP WRITE EXT MEM 6 1 10 2 ACF 1 EXT MEM Securit
69. CATION OT RND OT MF_FW are part of the security objectives of the Certified IC and Crypto Library which is the component TOE ST from this composite product Therefore the security objective statement is equivalent to the PP 5 for these security objectives OT IDENTIFICATION is also included for the pre personalisation feature of the TOE which is additional functionality the PP allows The security objective OT SEC_BOX_FW is the related to the introduction of the secure box which is additional to the Java Card System functionality The statement of security objectives is therefore equivalent to the security objectives in the PP 5 to which conformance is claimed The ST introduces two additional security objectives for the environment besides part of the security objectives for the environment included from the PP 5 The other security objectives for the environment are know security objectives for the TOE e OE USE_DIAG e OE USE_KEYS e OE PROCESS_SEC_IC The security objective for the environment OE PROCESS SEC is from the platform certified IC and crypto library that is part from this composite product evaluation Therefore the statement of security objectives for the environment is equivalent to the statement in the PP 5 OE USE KEYS and OE USE DIAG are included because the card manager is part of the TOE and not a security objective for the environment as in PP 5 The statement of security objectives for the environment
70. CESS SFR Any read write access to a SFR s CoreG LC Security Functional Requirements This group is focused on the main security policy of the Java Card System known as the firewall Firewall Policy FDP ACC 2 FIREWALL Complete Access Control FDP ACC 2 1 FIREWALL The TSF shall enforce the FIREWALL access control SFP on S PACKAGE S JCRE S JCVM O JAVAOBJECT and all operations among subjects and objects covered by the SFP Refinement The operations involved in the policy are e OP CREATE OP INVK INTERFACE eOP INVK VIRTUAL OP JAVA e OP THROW eOP TYPE ACCESS OP ARRAY ACCESS eOP INSTANCE FIELD FDP ACC 2 2 FIREWALL The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered by an access control SFP Note It should be noticed that accessing array s components of a static array and more generally fields and methods of static objects is an access to the corresponding O JAVAOBJECT 6 1 1 2 ACF 1 FIREWALL Security Attribute based Access Control Approved FDP ACF 1 1 FIREWALL The TSF shall enforce the FIREWALL access control SFP to objects based on the following Table 20 Security Attributes Subject Object Security attributes All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 60 of 135 JCOP 2 4 2 R3
71. COP 2 4 2 R3 Approved Shareable interface SIO SOF ST Subject T xxx TOE Transient object TSF User VM All information provided in this document is subject to legal disclaimers Security Target Lite PUBLIC An interface declaring a collection of methods that an applet accepts to share with other applets These interface methods can be invoked from an applet in a context different from the context of the object implementing the methods thus traversing the firewall An object of a class implementing a shareable interface Strength Of Function Security Target An active entity within the TOE that causes information to flow among objects or change the system s status It usually acts on the behalf of a user Objects can be active and thus are also subjects of the TOE Threats Target of Evaluation An object whose contents is not preserved across CAD sessions The contents of these objects are cleared at the end of the current CAD session or when a card reset is performed Writes to the fields of a transient object are not affected by transactions TOE Security Functions Any application interpretable by the JCRE That also covers the packages The associated subject s if applicable is are an object s belonging to the Jjavacard framework applet class Virtual Machine NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 7 of 135 NXP Semiconduc
72. CS_CKM 4 FCS COP 1 1 FDP_ITC 1 or FDP_ITC 2 yeg TDES CMAC n ve FCS CKM 1 and FCS_CKM 4 FDP RIP 1 ABORT No dependencies FDP RIP 1 APDU No dependencies FDP RIP 1 bArray No dependencies FDP RIP 1 KEYS No dependencies FDP RIP 1 TRANSIENT No dependencies FDP ACC 1 or FDP_ROL 1 FIREWALL FDP_ACC 2 FIREWALL FDP_IFC 1 FDP_IFC 1 JCVM FDP_ACC 1 EXT_MEM FDP_ACF 1 FDP_ACF 1 EXT_MEM FDP_ACC 1 FDP_ACC 1 EXT_MEM FOR SCE FMT_MSA 3 FMT_MSA 3 EXT_MEM FMT_MSA 1 EXT_MEM FDP_ACC 1 or FDP_IFC 1 FMT_SMF 1 FDP_ACC 1 EXT_MEM FMT SMF 1 EXT MEM FMT_SMR 1 FMT_SMR 1 FMT_MSA 1 FMT_MSA 1 EXT_MEM EMTOMSAISIEOSTOMEM FMT SMR 1 FMT SMR1 FMT SMF 1 EXT MEM No dependencies FAU ARP 1 FAU SAA 1 No rationale in Section 6 4 1 FDP SDI 2 No dependencies FPR UNO 1 No dependencies FPT FLS 1 No dependencies FPT TDC 1 No dependencies FIA ATD 1 AID No dependencies FIA UID 2 AID No dependencies Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 111 of 135 NXP Semiconductors JCOP 2 4 2 R3 6 4 1 Approved Security Target Lite PUBLIC SFR Dep Met Yes FIA USB 1 AID FIA_ATD 1 RU eae FMT SMF 1 and Yes FMT MTD 1 JCRE FMT SMR 1 FMT SMF 1 FMT SMR
73. ERIFICATION No applet loaded post issuance shall contain native methods All the bytecodes shall be verified at least once before the loading before the installation or before the execution depending on the card capabilities in order to ensure that each bytecode is valid at execution time See 3 VERIFICATION p 34 for details 4 3 Security Objectives Rationale In this section it is proven that the security objectives described in section 4 can be traced for all aspects identified in the TOE security environment and that they are suited Approved to cover them At least one security objective results from each assumption OSP and each threat At least one threat one OSP or assumption exists for each security objective All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 44 of 135 NXP Semiconductors JCOP 2 4 2 R3 Table 12 Security Target Lite PUBLIC Assignment threats OSP security objectives for the TOE T OS OPERATE T SEC BOX BORDER T RND T CONFID APPLI DATA T CONFID JCS CODE T CONFID JCS DATA T INTEG APPLI CODE T INTEG APPLI CODE LOAD T INTEG APPLI DATA T INTEG APPLI DATA LOAD T INTEG JCS CODE T INTEG JCS DATA T SID 1 T SID 2 T EXE CODE REMOTE T NATIVE T RESOURCES T DELETION T INSTALL T OBJ DELETION T PHYSICAL OSP PROCESS TOE OT SEC BOX FW
74. ES AES RSA RSA CRT and EC keys in accordance with a specified cryptographic key access method assignment methods commands defined in packages javacard security of 17 and 30 for proprietary classes that meets the following assignment 17 30 Application note e The keys can be accessed as specified in 17 Key class and 30 for proprietary classes e This component shall be instantiated according to the version of the Java Card API applicable to the security target and the implemented algorithms 17 and 30 for proprietary classes 6 1 24 FCS 4 Cryptographic Key Destruction FCS CKM 4 1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method assignment physically overwriting the keys with zeros by method e g clearKey of 17 that meets the following assignment none Application note e The keys are reset as specified in 17 Key class with the method clearKey Any access to a cleared key for ciphering or signing shall throw an exception e This component shall be instantiated according to the version of the Java Card API applicable to the security target and the implemented algorithms 17 6 1 2 5 FCS _COP 1 Cryptographic Operation FCS_COP 1 1 TripleDES Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 67 of 135
75. EXT and ATTRIBUTES Only the JCRE S JCRE can modify the the SELECTed applet Context security attribute and can change the list of registered applets AID see 6 1 1 6 FMT MSA 1 JCRE 6 1 4 4 FMT MTD 1 JCRE 6 1 1 11 FMT SMF 1 6 1 1 12 FMT_SMR 1 Only the JCVM S JCVM can modify the active context and the active applet security attribute see 6 1 1 7 FMT MSA 1 JCVM 6 1 1 11 FMT_SMF 1 6 1 1 12 FMT SMR 1 Furthermore only the JCRE can set up the security attribute address space see 6 1 10 3 FMT MSA 1 EXT MEM and 6 1 10 5 FMT SMF 1 EXT MEM Management of roles and functions Only specified roles are allowed to use specified management functions and security attributes see 6 1 1 12 FMT_SMR 1 6 1 9 6 FMT_MSA 1 CM 6 1 9 8 FMT_SMF 1 CM 6 1 9 9 FMT SMR 1 OM 6 1 15 5 Note that the TOE does not support multiple logical channels Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 115 of 135 NXP Semiconductors JCOP 2 4 2 R3 Approved SF ACC SVA SF ACC_RDNOV SF ACC_RDV SF ACC_SDV SF Audit Security Target Lite PUBLIC FMT_SMF 1 SecureBox 6 1 15 4 FMT_MSA 1 SecureBox 6 1 6 4 FMT_MSA 1 ADEL 6 1 6 6 FMT_SMF 1 ADEL 6 1 6 7 FMT_SMR 1 ADEL SECURE VALUES and ATTRIBUTES Only secure values are accepted for TSF data and security attributes see 6 1 1 8 FMT_MSA 2 FIREWAL
76. F HW RNG SF HW TDC SF HW AEC SF HW COC SF HW PPM SF HW LOG SF HW PMC SF HW MACC SF HW RAC Random Number Generator F RNG used for SF COP RNG see 6 1 14 4 FCS HNG 1 and SF COP RNG2 see 6 1 14 5 FCS_RNG 1 RNG2 Triple DES Co processor F HW_DES used for SF CYL_SDE and SF COP RNG and SF COP RNG2 see 6 1 2 5 FCS_COP 1 TripleDES FCS COP 1 DESMAC FCS COP 1 TDES CMAC and 6 1 14 4 FCS RNG 1 and 6 1 14 5 FCS_RNG 1 RNG2 AES Co processor F HW_AES used for SF COP_AES see 6 1 2 5 FCS_COP 1 AES FCS_COP 1 AESMAC and FCS_COP 1 AES_CMAC Control of Operating Conditions F OPC see 6 1 12 1 FPT FLS 1 SCP 6 1 12 2 FRU_FLT 2 SCP Protection against Physical Manipulation F PHY see 6 2 2 5 FCS_COP 1 TripleDES and FCS_COP 1 AES 6 1 14 4 FCS_RNG 1 6 1 14 5 FCS_RNG 1 RNG2 6 1 2 5 FPT_FLS 1 SCP 6 1 12 3 FPT_PHP 3 SCP 6 1 12 2 FRU FLT Z SCP 6 1 14 3 FAU SAS 1 SCP 6 1 12 4 FDP_ACC 1 SCP 6 1 12 5 FDP ACF 1 SCP and 6 1 12 6 FMT_MSA 3 SCP Logical Protection F LOG see 6 1 14 6 FPT EMSEC 1 Protection of Mode Control F COMP see 6 1 14 3 FAU SAS 1 SCP Memory Access Control F MEM ACC The functionality of the hardware is used for the MIFARE firewall see 6 1 12 4 FDP_ACC 1 SCP 6 1 12 5 FDP ACF 1 SCP and 6 1 12 6 FMT_MSA 3 SCP and to implement the Secure Box see 6 1 15 1 ACC 2 SecureBox 6 1 15 2 FDP_ACF 1 SecureBox Special Function Register Access Control F SFR ACC The fu
77. FDP ACF 1 SecureBox Security Attribute based Access Control 96 FMT MSA S3 SecureBox Static attribute initialisation esseesseeeeeeeeneeee 96 FMT MSA 1 SecureBox Management of security attributes E 97 FMT SMF 1 SecureBox Specification of Management 97 Security Assurance Requirements 97 Security Requirements Rationale 99 Security Target Lite 6 3 1 Security Functional Requirements Rationale for SFRS 1 8 99 6 3 2 Security Functional Requirements Rationale from Elf 105 6 3 2 1 Security Objectives for the 105 6 3 3 Security Functional Requirements Rationale not from 5 107 6 4 SFRs Dependencies 108 Table 29 SFR dependencies and their fullfilment 108 6 4 1 Rationale for the Exclusion of Dependencies 112 6 5 Security Assurance Requirements Rationale 113 6 5 1 1 Evaluation Assurance Level Rationale 113 6 5 1 2 Assurance Augmentations Rationale 113 7 TOE summary specification ASE TSS 114 7 1 Security Functionality 114 7 1 1 115 7 1 2 SE AUGI s deett E de 116 7 1 3 SF GryptoKey e enitiinecedsdiees 118 7 1 4 SF CryptoOperation
78. FDP_ITC 1 or FDP_ITC 2 Vos or FCS_CKM 1 FES COP EOS l FCS_CKM 1 and FCS_CKM 4 FDP_ITC 1 or FDP_ITC 2 Ves FCS_COP 1 1 TripleDES 1 FCS CKM 1 and FCS_CKM4 FCS COP 1 1 FDPITC2 Yes RSACiper SEP E FCS CKM 1 and CKM 4 FCS COP 1 1 E FDP_ITC 2 Yes RSASingature IS09796 ECC PM l FCS_CKM 1 and FCS_CKM 4 FCS COP 1 1 nm FDP_ITC 2 Yes RSASingaturePKCS 1 a FCS 1 and 4 FCS COP 1 1 aedes FDP_ITC 2 Yes RSASingaturePKCS 1_PSS E CRM l FCS_CKM 1 and FCS_CKM 4 FCS COP 1 1 FDP_ITC 1 orFDP ITC 2 Yes ECSingature or FCS_CKM 1 FCS CKM 1 and FCS CKM 4 Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 110 of 135 NXP Semiconductors JCOP 2 4 2 R3 Security Target Lite PUBLIC SFR pem FCS_CKM4 FCS COP 1 1 FDP_ITC 1 or FDP_ITC 2 vu Een FCS 1 and 4 FCS COP 1 1 or FDP ITC 2 vis DHKeyExchange nc FCS CKM 1 and 4 FCS COP 1 1 ITC 1 or FDP ITG 2 m oic E cni th FCS_CKM 1 and FCS_CKM 4 FCS COP 1 1 FDP_ITC 1 or FDP_ITC 2 Yeg iiic PCS CRM 1 FCS CKM 1 and FCS_CKM 4 FCS COP 1 1 FDP_ITC 1 or FDP_ITC 2 Yeg SHA 256 a FCS CKM 1 and FCS_CKM 4 FCS COP 1 1 FDP_ITC 1 or FDP_ITC 2 yeg AES CMAC A FCS_CKM 1 and F
79. IFE CYCLE MANAGEMENT access control SFP see sections 6 1 13 1 FDP_ACC 1 LifeCycle and 6 1 13 2 FDP_ACF 1 LifeCycle setting the card life cycle state via a trusted channel see section 6 1 14 2 FTP_ITC 1 LifeCycle FIREWALL access control SFP see sections 6 1 1 1 FDP_ACC 2 FIREWALL and 6 1 1 2 FDP_ACF 1 FIREWALL JCVM information flow control SFP see section 6 1 1 3 FDP_IFC 1 JCVM and 6 1 1 4 FDP_IFF 1 JCVM Secure Box access control SFP see sections 6 1 15 1 FDP_ACC 2 SecureBox and 6 1 15 2 FDP_ACF 1 SecureBox PACKAGE LOADING information flow control SFP see sections 6 1 9 2 FDP_IFC 2 CM 6 1 9 3 FDP_IFF 1 CM for the import of user data see section 6 1 5 1 FDP_ITC 2 INSTALLER post issuance loading of applets is done via a trusted channel see 6 1 9 10 FTP_ITC 1 CM ADEL access control SFP for deleting applets see sections 6 1 6 1 FDP_ACC 2 ADEL 6 1 6 2 FDP_ACF 1 ADEL JCRMI Java Card Remote Method Invocation access control SFP see sections 6 1 7 1 FDP_ACC 2 JCRMI 6 1 7 2 FDP_ACF 1 JCRMI EXTERNAL MEMORY access conirol SFP see sections 6 1 10 1 FDP ACC 1 EXT MEM and 6 1 10 2 FDP_ACF 1 EXT_MEM It further ensures the management of the necessary security attributes SF ACC_MCL SF ACC_MCA SF ACC_MRF MANAGEMENT CARD LIFE CYCLE Only S PACKAGE CM is allowed to modify the card life cycle state see sections 6 1 13 3 _ MSA 1 LifeCycle 6 1 9 8 FMT SMF 1 CM and 6 1 9 9 FMT_SMR 1 CM MANAGEMENT CONT
80. L_JCVM 6 1 4 5 FMT_MTD 3 JCRE 6 1 1 11 FMT_SMF 1 6 1 1 12 FMT_SMR 1 6 1 9 9 FMT_SMR 1 CM i e Context attribute of a JAVAOBJECT must correspond to that of an installed applet or be JCRE An OB JAVAOBJECT whose Sharing attribute is a JCRE entry point or a global array necessarily has JCRE as the value for its Context security attribute An OB JAVAOBJECT whose Sharing attribute value is a global array necessarily has array of primitive Java Card System type as a JavaCardClass security attribute s value OB JAVAOBJECT whose Sharing attribute value is not Standard has a PERSISTENT LifeTime attribute s value Any OB JAVAOBJECT whose LifeTime attribute value is not PERSISTENT has an array type as JavaCardClass attribute s value Restrictive default non overwriteable values are used for the security attributes see 6 1 13 4 FMT MSA 3 LifeCycle 6 1 1 9 FMT_MSA 3 FIREWALL 6 1 1 10 FMT_MSA 3 JCVM 6 1 9 7 FMT_MSA 3 CM 6 1 6 5 FMT_MSA 3 ADEL Restrictive default values are used for the security attributes which be overwritten see 6 1 15 3 MSA S3 SecureBox The JCRE sets default values when an object or information is created see 6 1 10 4 MSA S EXT SF Audit shall be able to accumulate or combine in monitoring the following auditable events and indicate a potential violation of the TSP SF AUD AEC SF AUD PHT SF AUD EFA SF AUD CLI SF AUD OLI Abnorm
81. NAGEMENT contributes to cover this threat Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 48 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC T INTEG JCS CODE This threat is countered by the list of properties described in the 4 VERIFICATION security aspect Bytecode verification ensures that each of the instructions used on the Java Card platform is used for its intended purpose and in the intended scope of accessibility As none of these instructions enables modifying a piece of code no Java Card applet can therefore be executed to modify a piece of code Native applications are also harmless because of the objective OT NATIVE so no application can be run to modify a piece of code The 4 VERIFICATION security aspect is addressed in this configuration by the objective for the environment OE VERIFICATION The objectives OT CARD MANAGEMENT OE VERIFICATION contribute to cover this threat by controlling the access to card management functions and by checking the bytecode respectively Finally the objective OT EXT MEM provides access control for external memory and therefore also contributes to counter this threat T INTEG JCS DATA This threat is countered by bytecode verification OE VERIFICATION and the isolation commitments stated in the OT FIREWALL objective This lat
82. NXP J3E145 M64 J3E120 M65 J3E082 M65 J2E145 M64 J2E120 M65 and J2E082 M65 Secure Smart Card Controller Revision 3 Security Target Lite Rev 00 02 2nd August 2013 Evaluation documentation NSCIB CC 13 37760 PUBLIC Document information Info Content Keywords JCOP ST Security Target Lite Abstract This is the Security Target Lite for JCOP v2 4 2 Revision 3 It defines the Contract for the certification according to Common Criteria NXP Semiconductors JCOP 2 4 2 R3 Revision history Security Target Lite PUBLIC Rev Date 00 01 20130725 00 02 20130802 Approved Description Derived from Security Target Fixed TOE name All information provided in this document is subject to legal disclaimers Evaluation documentation Rev 00 02 2nd August 2013 NXP B V 2013 All rights reserved 2 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC Glossary A XXX Assumptions AID Application identifier an ISO 7816 data format used for unique identification of Java Card applications and certain kinds of files in card file systems The Java Card platform uses the AID data format to identify applets and packages AIDs are administered by the International Standards Organization ISO so they can be used as unique identifiers AIDs are also used in the security policies see Context below applets AIDs are related to the selection mechanisms packages AIDs ar
83. Objectives Rationale for Objectives not in 5 4 3 2 1 Threats T OS OPERATE OT OPERATE and OT MF FW addresses directly the threat OPERATE by ensuring the correct continuation of operation of the TOE logical security functions Security mechanisms have to be implemented to avoid fraudulent usage of the TOE usage of certain memory regions or usage of incorrect or unauthorized instructions or commands or sequence of commands The security mechanisms must be designed to always put the TOE in a known and secure state T SEC BOX BORDER 5 BOX FW addresses directly the threat T SEC BOX BORDER by ensuring that the native code separated in the Secure Box and the data belonging to this native code is completely sealed off from the Java Card System Due to the separation the native code in the Secure Box cannot harm the code and data outside the Secure Box T RND The objective OT RND directly covers T RND The TOE ensures the cryptographic quality of random number generation For instance random numbers shall not be predictable and shall have sufficient entropy Furthermore the TOE ensures that no information about the produced random numbers is available to an attacker 4 3 2 2 Organisational Security Policies OSP PROCESS TOE This organizational security policy is upheld by the security objective for the TOE OT IDENTIFICATION which ensures that the TOE can be uniquely identified 4 3 2 3 Assumptions A USE_DIAG This assumption is uphe
84. P CREATE with the exception given in FDP ACF 1 4 FIREWALL provided it is the Currently Active Context e The only means that the subject S JCVM shall provide for an application to execute native code is the invocation of a Java Card API method through OP INVK INTERFACE or OP INVK VIRTUAL FDP ACF 1 4 FIREWALL The TSF shall explicitly deny access of subjects to objects based on the following additional rules e Any subject with OP JAVA upon an O JAVAOBJECT whose LifeTime attribute has value CLEAR ON DESELECT if O JAVAOBJECT s Context attribute is not the same as the Selected Applet Context e Any subject attempting to create an object by the means of OP CREATE and a CLEAR ON DESELECT LifeTime parameter if the active context is not the same as the Selected Applet Context Note The deletion of applets may render some O JAVAOBJECT inaccessible and the Java Card RE may be in charge of this aspect This can be done for instance by ensuring that references to objects belonging to a deleted application are considered as a null reference In the case of an array type fields are components of the array 12 2 14 82 7 7 as well as the length the only methods of an array object are those inherited from the Object class The Sharing attribute defines four categories of objects e Standard ones whose both fields and methods are under the firewall policy e Shareable interface Objects SIO which provide a secure mechanism for i
85. PLI CODE LOAD The attacker modifies part of its own or another application code when an application package is transmitted to the card for installation See INTEG APPLI CODE p 33 for details Directly threatened asset s D APP CODE T INTEG APPLI DATA The attacker executes an application to alter part of another application s data See INTEG APPLI DATA p 33 for details Directly threatened asset s D APP DATA D PIN and D APP KEYs Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 28 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC T INTEG APPLI DATA LOAD The attacker modifies part of the initialization data contained in an application package when the package is transmitted to the card for installation See 4 INTEG APPLI DATA p 33 for details Directly threatened asset s D APP DATA and D APP KEY T INTEG JCS CODE The attacker executes an application to alter part of the Java Card System code See INTEG JCS CODE p 33 for details Directly threatened asset s D JCS_CODE T INTEG JCS DATA The attacker executes an application to alter part of Java Card System or API data See INTEG JCS DATA p 33 for details Directly threatened asset s D API DATA D SEC DATA D JCS DATA D JCS KEYs and D CRYPTO Other attacks are in general rela
86. R I DATA is allowed if and only if the Currently Active Context is Java Card RE e other OP PUT operations are allowed regardless of the Currently Active Context s value FDP_IFF 1 3 JCVM The TSF shall enforce assignment no additional information flow control SFP rules FDP_IFF 1 4 JCVM The TSF shall explicitly authorise an information flow based on the following rules assignment none FDP_IFF 1 5 JCVM The TSF shall explicitly deny an information flow based on the following rules assignment none Note The storage of temporary Java Card RE owned objects references is runtime enforced 18 6 2 8 1 3 It should be noticed that this policy essentially applies to the execution of bytecode Native methods the Java Card RE itself and possibly some API methods can be granted specific rights or limitations through the FDP_IFF 1 3 JCVM to FDP_IFF 1 5 JCVM elements 6 1 1 5 FDP_RIP 1 OBJECTS Subset Residual Information Protection FDP_RIP 1 1 OBJECTS The TSF shall ensure that any previous information content of a resource is made unavailable upon the allocation of the resource to the following objects class instances and arrays Note The semantics of the Java programming language requires for any object field and array position to be initialized with default values when the resource is allocated 12 2 5 1 6 1 1 6 FMT_MSA 1 JCRE Management of Security Attributes FMT_MSA 1 1 JCRE The TSF shall enforce
87. S dHd Ldd dOS cll4 nua dOS L S14 ldd WAW LX3 L3WS WAIN LlX3 vVSW WAW LX3 LFVSW WAW LX3 l 40V dad WAW lX3 LF99V dl WO FYINS W L SINS WO VSW WO LVSIN LIN Vis W2 V33l 09 24 WO cOHN O04 T3G0 L S14 ldd T300 L diH OT REMOTE OT TRANSACTION OT OBJ DELETION OT DELETION X X X X X OT LOAD OT INSTALL OT SCP IC OT SCP RECOVERY OT SCP SUPPORT OT EXT MEM OT MF FW OT CARD MANAGEMENT OT IDENTIFICATION OT RND OT SEC_BOX_FW Table 28 Assignment Security Objectives for the TOE Security Requirements 4 xogeunoes L AINS xogeunoes L VSIN xogeunoes e VSW LIS xogeunoeg L 429v dds xogeinoeg z 99V 09503 Ldd ONY S34 cONH L ONH SOS dOS L SVS ep Ao9erT roll dis NId L 13V Vld ejoA9ejri e VSIW eioA9eir EvSIW ejoA9eirq Ed9v ejoA9eir L29v dds dOS VSIN OT SID OT FIREWALL OT GLOBAL ARRAYS CONFID NXP B V 2013 All rights reserved All information provided in this document is subject to legal disclaimers Approved 103 of 135 Rev 00 02 2nd August 2013 Evaluation documentation NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC ycle ycle ycle ycle FMT MSA 1 LifeC ycle FAU SAS 1 SCP FCS RNG 1 RNG2 FMT MSA 1 SecureBox FMT SMF 1 SecureBox ACC 1 L
88. Security Target Lite PUBLIC IINHOf LJOV dds IINHOr ZO9V dds T3av r s14 ldd T3av EFHWS LINAS T3av L3WS T3av e vsW T3av EFvSsW T3av Fdid dds T3av rd3ov T3av ec 99v Jejelsu AOH ld4 Jejeisu L S14 193 Jejeisu L HINS Jejeisu Z 21l 3HOor alNw LWA 3HOf LGlN LWA aiv rasn via via aiv raiv via OGL 149 LS14 Ldd VONN OT MF FW OT CARD MANAGEMENT OT IDENTIFICATION OT RND OT SEC_BOX_FW Table 27 Assignment Security Objectives for the TOE Security Requirements 3 dOS L 49V ddd dOS L 99V dOS dHd ldJ d S Z 174 nus dOS L S1d 189 WAW LX3 L3WS WAIN LlX3 VSW WAIN LX3 FVSW WAW L1X3 L4OV dds WAW lX3 L929oV W2 L O1l dls WO FYINS WO VAWS WO EVSW WO FVSIN WO2 Ldimn Vis W E LIN ddd W2 V 33l dds W2 c23l ddd WO c OHN O04 T300 L S1J ld4 T300 FdlH OT SID X X X X OT FIREWALL OT GLOBAL ARRAYS CONFID x OT GLOBAL ARRAYS INTEG OT NATIVE OT OPERATE OT REALLOCATION OT RESOURCES OT ALARM OT CIPHER OT KEY MNGT OT PIN MNGT NXP B V 2013 All rights reserved All information provided in this document is subject to legal disclaimers Approved 102 of 135 Rev 00 02 2nd August 2013 Evaluation documentation JCOP 2 4 2 R3 NXP Semiconductors Security Target Lite PUBLIC dOS LJOV ddd dOS L 99V dO
89. T MTD 3 JCRE Secure TSF Data 6 1 5 1 FMT MTD 3 1 JCRE The TSF shall ensure that only secure values are accepted for the registered applets AIDs INSTG Security Functional Requirements This group consists of the SFRs related to the installation of the applets which addresses security aspects outside the runtime The installation of applets is a critical phase which lies partially out of the boundaries of the firewall and therefore requires specific treatment In this PP loading a package or installing an applet modelled as importation of user data that is user application s data with its security attributes such as the parameters of the applet used in the firewall rules FDP ITC 2 Installer Import of User Data with Security Attributes FDP ITC 2 1 Installer The TSF shall enforce the PACKAGE LOADING information flow control SFP when importing user data controlled under the SFP from outside of the TOE FDP ITC 2 2 Installer The TSF shall use the security attributes associated with the imported user data FDP ITC 2 3 Installer The TSF shall ensure that the protocol used provides for the unambiguous association between the security attributes and the user data received FDP_ITC 2 4 Installer The TSF shall ensure that interpretation of the security attributes of the imported user data is as intended by the source of the user data FDP_ITC 2 5 Installer The TSF shall enforce the following rules when importing user data cont
90. VERIFICATION This threat particularly concerns the point 8 of the security aspect VERIFICATION access modifiers and scope of accessibility for classes fields and methods The OT FIREWALL objective is also concerned because it prevents the execution of non shareable methods of a class instance by any subject apart from the class instance owner T EXE CODE 2 Unauthorized execution of a method fragment or arbitrary data is prevented by the objective OE VERIFICATION This threat particularly concerns those points of the security aspect related to control flow confinement and the validity of the method references used in the bytecodes T EXE CODE REMOTE The OT REMOTE security objective contributes to prevent the invocation of a method that is not supposed to be accessible from outside the card T NATIVE This threat is countered by OT NATIVE which ensures that a Java Card applet can only access native methods indirectly that is through an API OE APPLET also covers this threat by ensuring that no native applets shall be loaded in post issuance In addition to this the bytecode verifier also prevents the program counter of an applet to jump into a piece of native code by confining the control flow to the currently executed method OE VERIFICATION Denial of Service T RESOURCES This threat is directly countered by objectives on resource management OT RESOURCES for runtime purposes and good working order OT OPERATE in a general manner Co
91. VM FMT_MSA 3 FIREWALL FMT MSA 3 JCVM FMT_SMF 1 FMT_SMR 1 FCS CKM 1 FDP R FDP ACF 1 FIREWALL FDP R FAU ARP 1 IFC 1 JCVM IFF 1 JCVM FDP RIP 1 OBJECTS FMT MSA 1 JCRE FCS CKM 2 FCS CKM 3 FCS 4 FCS COP FDP R FDP R FDP ACC 2 FIREWALL FDP R OT GLOBAL ARRAYS CONFID X X X X X X X X Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 99 of 135 NXP Semiconductors JCOP 2 4 2 R3 Security Target Lite PUBLIC OT GLOBAL ARRAYS INTEG OT NATIVE OT OPERATE OT REALLOCATION OT RESOURCES OT ALARM OT CIPHER OT KEY MNGT OT PIN MNGT OT REMOTE OT TRANSACTION OT OBJ DELETION OT DELETION OT LOAD OT INSTALL OT SCP IC OT SCP RECOVERY OT SCP SUPPORT OT EXT MEM OT MF FW OT CARD MANAGEMENT OT IDENTIFICATION OT RND OT SEC BOX FW FDP ACC 2 FIREWALL FDP ACF 1 FIREWALL FDP IFC 1 JCVM P 1 FMT MSA 1 JCVM FMT MSA 2 FIREWALL JCVM FMT_MSA 3 FIREWALL FMT_MSA 3 JCVM FMT_SMF 1 FMT_SMR 1 FCS CKM 1 FCS CKM 2 FCS_CKM 3 FCS CKM 4 FCS CO IFF 1 JCVM FDP RIP 1 OBJECTS FMT MSA 1 JCRE X X X X X X X X X X X FDP R P 1 ABORT P 1 APDU FDP R FDP R P 1 TRANSIENT P 1 bArray P 1 KEYS FDP ROL 1 FIREWALL FDP R FDP SDI 2 FDP R FAU ARP
92. VM B FDP IFC 1 JCVM End FMT_MSA 3 JCVM FDP_IFC 1 E FDP_IFC 1 JCVM FMT MSA 3 FDP_IFC 1 JCVM FMT_MSA 3 JCVM FDP_RIP 1 OBJECTS No dependencies FDP_ACC 1 or Not fully rationale in Section FDP_IFC 1 6 4 1 FMT_MSA 1 JCRE aaa FDP_ACC 2 FIREWALL FMT_SMR 1 FMT_SMR 1 FDP_ACC 1 TFC 1 FDP ACC 2 FIREWALL FMT MSA 1 JCVM EMT EME FDP IFC 1 JCVM E FMT SMF 1 z f FMT_SMR 1 Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 109 of 135 NXP Semiconductors JCOP 2 4 2 R3 Security Target Lite PUBLIC SFR Dep Met FDP_ACC 1 or FDP IFC 1 Yes ACC 2 FIREWALL IFC 1 JCVM FMT_MSA 2 FIREWALL_JCVM mo FMT MSA T UCR a HG FMT MSA 1 JCVM FMT_SMR 1 Yes FMT_MSA 1 FMT_MSA 1 JCRE FMT_MSA 3 FIREWALL Mena FMT SMR 1 FMT MSA 1 JCVM FMT SMR 1 Yes FMT MSA 3 JCVM Pera FMT MSA 1 JCVM FMT_SMR 1 FMT_SMF 1 No dependencies Yes FMT_SMR 1 FIA_UID 1 FIA UID 2 AID FCS CKM 2 or Yes FCS COP 1 FDP_ITC 1 or FDP_ITC 2 or Yes FCS CKM 1 FCS CKM 1 FCS CKM 4 4 ITC 1 FCS CKM3 FDP ITC 2 or Yes ee FCS_CKM 1 FCS CKM 1 FCS CKM 4 4 ITC 1 or FDP ITC 2 or Yes TA FCS CKM 1 FCS CKM 1 4
93. a Management FAU SAS 1 There are no management activities foreseen Audit FAU SAS 1 There are no actions defined to be auditable FAU SAS 1 Audit storage Hierarchical to No other components FAU SAS 1 1 The TSF shall provide assignment list of subjects with the capability to store assignment list of audit information in the assignment type of persistent memory Dependencies No dependencies 6 Security requirements ASE REQ This section states the security functional requirements for the TOE For readability requirements are arranged into groups The permitted operations assignment iteration selection and refinement of the SFRs given in Common Criteria 1 and are printed in bold Completed operations related to the PP are additionally marked within where assignments are additionally marked with the keyword assignment Table 14 Requirement Groups Group Description Core with Logical The CoreG LC contains the requirements concerning the runtime Channels CoreG LC environment of the Java Card System implementing logical channels This includes the firewall policy and the requirements Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 54 of 135 NXP Semiconductors JCOP 2 4 2 R3 Security Target Lite PUBLIC Group Installation InstG Applet deletion
94. additional usage recommendation must also be followed in order to ensure that the TOE is correctly and securely handled and that shall be not damaged or compromised This ST assumes A USE DIAG A USE KEYS that users handle securely the TOE and related Objectives for the environment are defined OE USE DIAG OE USE KEYS Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 13 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC 1 3 4 TOE Identification The delivery comprises the following items Table4 Delivery Items Type Name Version Date Hardware NXP J3E145 M64 J3E120 M65 J3E082 M65 J2E145 M64 J2E120 M65 and J2E082 M65 Secure Smart Card Controller Revision 3 ROM Code Mask ID See Table 5 Patch Code Patch ID Document User Manual AGD OPE for the applet 0 6 16 July 2013 developer 30 Document Administrator Manual AGD PRE 31 0 5 16 July 2013 Document HW Data Sheet 15 0 2 26 March 2013 Document Secure Box User Manual 33 3 4 18th March 2013 optional HW Guidance Manual 11 1 7 24 January Document 2013 Table 5 lists the product identification for all products covered by this security target Table 5 Product Identification Product Mask ID Mask Name Patch ID J2E145 M64 J3E145 M64 64 NX250B 01 J8E120 M65 J8E082 M65 J2E120 M65 2 08
95. al environmental conditions frequency voltage temperature in fulfillment of AHP 1 and FLS f1 Physical tampering in fulfillment of FAU ARP 1 FPT FLS 1 EEPROM failure audited by detection of broken EEPROM cells during write operations in fulfillment of ARP 1 and 1 Card life cycle state inconsistency audited through the life cycle checks in all administrative operations and the self test mechanism on start up in fulfillment of ARP 1 FPT_FLS 1 OS internal life cycle state inconsistency audited through the life cycle checks in all administrative operations root applet in fulfillment of FAU_ARP 1 and FPT_FLS 1 All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 116 of 135 NXP Semiconductors JCOP 2 4 2 R3 SF AUD ALI SF AUD CCS SF AUD UOR SF AUD AOT Security Target Lite PUBLIC Applet life cycle inconsistency in fulfillment of 1 and FPT FLS 1 Corruption of check summed objects in fulfillment of ARP 1 and FPT FLS 1 Unavailability of resources audited through the object allocation mechanism in fulfillment of ARP 1 and FPT_FLS 1 Abortion of a transaction in an unexpected context see 17 and 18 87 6 2 in fulfillment of ARP 1 and FPT_FLS 1 Based on the events listed above and the
96. all ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered by an access control SFP 6 1 7 2 FDP ACF 1 JCRMI Security attribute based access control FDP ACF 1 1 JCRMI The TSF shall enforce the JCRMI access control SFP to objects based on the following Table 23 Security Attributes Subject Object Security attributes S JCRE Selected Applet Context O REMOTE OBJ Owner Class Identifier ExportedInfo O REMOTE MTHD Identifier O RMI SERVICE Owner Returned References FDP_ACF 1 2 JCRMI The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed e none FDP ACF 1 3 JCRMI The TSF shall explicitly authorise access of subjects to objects based on the following additional rules none FDP ACF 1 4 JCRMI Editorially Refined Editorially Refined NXP Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 83 of 135 NXP Semiconductors JCOP 2 4 2 H3 6 1 8 1 Security Target Lite PUBLIC The TSF shall explicitly deny access of any subject to O REMOTE OBJ and O REMOTE MTHD for the purpose of performing a remote method invocation ODELG Security Functional Requirements The following requirements concern the object deletion mechanism This mechanism is triggered by
97. arget Lite PUBLIC supported schemes and padding algorithms see 6 1 2 5 FCS COP 1 RSASignaturePKCS 1 RSA digital signature generation and verification with SHA 1 SHA 224 and SHA 256 as hash function and cryptographic key sizes from 512 to 2048 Bit according to PKCS 1 22 for details especially on the supported schemes and padding algorithms see 6 1 2 5 FCS_COP 1 RSASignaturePKCS 1_PSS Secure hash computation with SHA 1 according to FIPS 180 3 27 for details especially on the supported schemes and padding algorithms see 6 1 2 5 FCS_COP 1 SHA 1 Random number generation according to AIS 20 8 class DRG 3 see 6 1 14 4 FCS_RNG 1 Random number generation according to AIS 20 8 class DRG 2 see 6 1 14 5 FCS RNG 1 RNG2 EC Digital signature generation and verification with SHA 1 SHA 224 and SHA 256 as hash functions and cryptographic key sizes from 128 to 320 Bit according to 15014888 3 26 for details especially on the supported schemes and padding algorithms see 6 1 2 5 FCS COP 1 ECSignature Secure hash computation with SHA 224 according to FIPS 180 3 27 for details especially on the supported schemes and padding algorithms see 6 1 2 5 FCS COP 1 SHA 224 Secure hash computation with SHA 256 according to FIPS 180 3 27 for details especially on the supported schemes and padding algorithms see 6 1 2 5 FCS COP 1 SHA 256 Secure Messaging functionality for ICAO either encryption and decryptio
98. asset s D APP CODE T EXE CODE REMOTE The attacker performs an unauthorized remote execution of a method from the CAD See EXE APPLI CODE p 33 for Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 29 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC details Directly threatened asset s DLAPP CODE T NATIVE An applet executes a native method to bypass a TOE Security Function such as the firewall See 4 NATIVE p 34 for details Directly threatened asset s D JCS DATA 3 3 2 5 Denial of Service T RESOURCES An attacker prevents correct operation of the Java Card System through consumption of some resources of the card RAM or NVRAM See z RESOURCES p 37 for details Directly threatened asset s D JCS DATA 3 3 2 6 Card Management T DELETION The attacker deletes an applet or a package already in use on the card or uses the deletion functions to pave the way for further attacks putting the TOE in an insecure state See DELETION 36 for details Directly threatened asset s D SEC DATA and D APP CODE T INSTALL The attacker fraudulently installs post issuance of an applet on the card This concerns either the installation of an unverified applet or an attempt to induce a malfunction in the TOE through the installation process See INSTALL p 3
99. assignment 1976 2048 Bit that meet the following assignment RSASSA PKCS1 v1 5 22 Section 8 2 Application Notes All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 68 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC 1 The security functionality is resistant against side channel analysis and similar techniques To fend off attackers with high attack potential an adequate key length must be used references can be found in national and international documents and standards 2 The input data for the encryption operation is not protected against SCA and fault attacks FCS COP 1 1 RSASignaturePKCS 1_PSS The TSF shall perform assignment digital signature generation and verification in accordance with a specified cryptographic algorithm assignment RSA signature algorithm with EMSA PSS encoding and SHA 1 SHA 224 and SHA 256 38 and cryptographic key sizes assignment 1976 2048 Bit that meet the following assignment RSASSA PSS 22 Section 8 1 Application Notes 1 The security functionality is resistant against side channel analysis and similar techniques To fend off attackers with high attack potential an adequate key length must be used references can be found in national and international documents and standards 2 The input data for the encryption operatio
100. ata as applets may need to share some data or communicate with the CAD cryptographic functions are required to actually protect the exchanged information OT CIPHER Remark that even if the TOE shall provide access to the appropriate TSFs it is still the responsibility of the applets to use them Keys and PIN s are particular cases of an application s sensitive data the Java Card System may possess keys as well that ask for appropriate management OT KEY MNGT OT PIN MNGT OT TRANSACTION If the PIN class of the Java Card API is used the objective OT FIREWALL is also concerned Other application data that is sent to the applet as clear text arrives to the APDU buffer which is a resource shared by all applications The integrity of the information stored in that buffer is ensured by the objective OT GLOBAL ARRAYS INTEG Finally any attempt to read a piece of information that was previously used by an application but has been logically deleted is countered by the OT REALLOCATION objective That objective states that any information that was formerly stored in a memory block shall be cleared before the block is reused T INTEG APPLI DATA LOAD This threat is countered by the security objective OT LOAD which ensures that the loading of packages is done securely and thus preserves the integrity of applications data By controlling the access to card management functions such as the installation update or deletion of applets the objective OT CARD MA
101. ation controlled by the FIREWALL access control SFP The operation shall fail anyway if the created object would have had security attributes whose value violates FMT MSA 2 1 FIREWALL JCVM 6 1 1 10 FMT MSA 3 JCVM Static Attribute Initialisation FMT MSA 3 1 CVM The TSF shall enforce the JCVM information flow control SFP to provide restrictive default values for security attributes that are used to enforce the SFP FMT MSA 3 2 JCVM Editorially Refined The TSF shall not allow any role to specify alternative initial values to override the default values when an object or information is created 6 1 1 11 FMT SMF 1 Specification of Management Functions FMT SMF 1 1 Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 65 of 135 NXP Semiconductors JCOP 2 4 2 H3 Approved Security Target Lite PUBLIC The TSF shall be capable of performing the following management functions e modify the Currently Active Context the Selected Applet Context and the Active Applets 6 1 1 12 FMT SMR 1 Security roles 6 1 2 6 1 2 1 FMT SMR 1 1 The TSF shall maintain the roles e Java Card RE JCRE e Java Card VM JCVM FMT SMR 1 2 The TSF shall be able to associate users with roles Application Programming Interface The following SFRs are related to the Java Card API The whole set of cryptographic algorithms
102. ation documentation Rev 00 02 2nd August 2013 94 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC FCS RNG 1 2 RNG2 The TSF shall provide random numbers that meet e Class DRG 2 of 8 e DRG 2 4 The RNG initialized with a random seed assignment initialization is initiated at startup when the first APDU is received using the PTRNG of the HW platform conform to class P2 in 32 generates output for which assignment 25 strings of bit length 128 are mutually different with probability above assignment 1 27 e DRG 2 5 Statistical test suites cannot practically distinguish the random numbers from output sequences of an ideal RNG The random numbers must pass test procedure A assignment no additional tests Application note 1 DRG 2 1 DRG 2 4 With perspective to DRNG seeding with P2 and PTG 2 can be considered as equivalent 32 Application note 2 The selection of the DRNG class is done via fab key settings during pre personalization which allows running the DRNG either as class DRG 3 or class DRG 2 compatible DRNG The default setting is DRG 2 6 1 14 6 EMSEC 1 TOE Emanation 6 1 15 6 1 15 1 Approved FPT EMSEC 1 1 The TOE shall not emit assignment variations in power consumption or timing during command execution in excess of assignment non useful information enabling access to assignment TSF data D JCS8 KEYs and D CRYPTO and assignment User data D PIN D
103. ats and objectives The description is based on 5 and supplemented by the description of 6 3 2 Assets Assets are security relevant elements to be directly protected by the TOE Confidentiality of assets is always intended with respect to un trusted people or software as various parties are involved during the first stages of the smart card product life cycle details are given in threats hereafter Assets have to be protected some in terms of confidentiality and some in terms of integrity or both integrity and confidentiality These assets are concerned by the threats on the TOE and include a TOE including NOS code b TSF data as initialization data configuration data cryptographic keys random numbers for key generation and all data used by the TOE to execute its security functions This includes also configuration of hardware specific security features c User Data as application code applets specific sensitive application values as well as application specific PIN and authentication data The assets to be protected by the TOE are listed below They are grouped according to whether it is data created by and for the user User data or data created by and for the TOE TSF data The definition is taken from section 5 1 of 5 3 2 1 User Data D APP_CODE The code of the applets and libraries loaded on the card To be protected from unauthorized modification Approved All information provided in this document is
104. ble failures of the deletion procedures FPT FLS 1 ADEL FPT_RCV 3 Installer The security functional requirements of the class FMT FMT MSA 1 ADEL FMT MSA 3 ADEL FMT SMR 1 ADEL included in the group ADELG also contribute to meet this objective OT LOAD This security objective specifies that the loading of a package into the card must be secure Evidence of the origin of the package is enforced FCO 2 and the integrity of the corresponding data is under the control of the PACKAGE LOADING information flow policy IFC 2 CM FDP IFF 1 CM and FDP UIT 1 CM Appropriate identification FIA UID 1 CM and transmission mechanisms are also enforced FTP_ITC 1 CM OT INSTALL This security objective specifies that installation of applets must be secure Security attributes of installed data are under the control of the FIREWALL access control policy FDP_ITC 2 Installer and the TSFs are protected against possible failures of the installer FPT_FLS 1 Installer FPT RCV 3 Installer O EXT MEM The Java Card System memory is protected against applet s attempts of unauthorized access through the external memory facilities by the EXTERNAL MEMORY access control policy FDP ACC 1 EXT MEM FDP ACF 1 EXT MEM which first controls the accessible address space then controls the effective read and write operations External memory management is controlled by the TSF FMT SMF 1 EXT MEM Security Functional Requirements Rationale not from
105. c attribute initialisation FMT MSA 3 1 SecureBox The TSF shall enforce the assignment Secure Box access control SFP to provide selection restrictive default values for security attributes that are used to enforce the SFP FMT MSA 3 2 SecureBox The TSF shall allow assignment JCRE to specify alternative initial values to override the default values when an object or information is created Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 96 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC Application note During the prepersonalisation of the TOE the initial restrictive values for the security attributes can be overridden by the JCRE Application note The dependency to FMT_SMR 1 is fulfilled by Section 6 1 1 12 6 1 15 4 FMT MSA 1 SecureBox Management of security attributes FMT MSA 1 1 SecureBox The TSF shall enforce the assignment Secure Box access control SFP to restrict the ability to selection modify the security attributes assignment CPU Mode and the MMU Segment Table to assignment JCRE Application note The dependency to FMT_SMR _1 is fulfilled by Section 6 1 1 12 6 1 15 5 FMT SMF 1 SecureBox Specification of Management Functions FMT SMF 1 1 SecureBox The TSF shall be capable of performing the following management functions assignment e Switch
106. cedures From the IC design IC Dedicated Software and Smartcard Embedded Software the IC Developer e constructs the smartcard IC database necessary for the IC photomask fabrication 3 IC Manufacturing The IC Manufacturer is responsible for e producing the IC through three main steps IC manufacturing IC testing and IC pre personalization The IC Mask Manufacturer e generates the masks for the IC manufacturing based upon an output from the smartcard IC Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 12 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC Phase Name Description database 4 IC Packaging The IC Packaging Manufacturer is responsible for e IC packaging and testing 5 Composite Product The Composite Product Manufacturer is responsible for Integration e smartcard product finishing process including applet loading and testing 6 Personalization The Personalizer is responsible for e smartcard including applet personalization and final tests Applets may be loaded onto the chip at the personalization process 7 Operational Usage The Consumer of Composite Product is responsible for e smartcard product delivery to the smartcard end user and the end of life process e applets may be loaded onto the chip The evaluation process is limited to phas
107. ces capable of replacing paper transactions by electronic data processing Data processing is performed by a piece of software embedded in the smart card chip usually called an application The Java Card System is intended to transform a smart card into a platform capable of executing applications written in a subset of the Java programming language The intended use of a Java Card platform is to provide a framework for implementing IC independent applications conceived to safely coexist and interact with other applications into a single smart card Applications installed on a Java Card platform can be selected for execution when the card is inserted into a card reader In some configurations of the TOE the card reader may also be used to enlarge or restrict the set of applications that can be executed on the Java Card platform according to a well defined card management policy Notice that these applications may contain other confidentiality or integrity sensitive data than usual cryptographic keys and PINs for instance passwords or pass phrases are as confidential as the PIN and the balance of an electronic purse is highly sensitive with regard to arbitrary modification because it represents real money So far the most important applications are e Financial applications like Credit Debit ones stored value purse or electronic commerce among others Approved All information provided in this document is subject to legal disclaimers
108. ction against forgery the AID of an applet is under the control of the TSFs or re use of identities FIA_UID 2 AID FIA_USB 1 AID Execution OT FIREWALL Refined This objective is met by the FIREWALL access control policy FDP_ACC 2 FIREWALL and FDP_ACF 1 FIREWALL the JCVM information flow control policy FDP_IFF 1 JCVM FDP_IFC 1 JCVM the JCRMI access control policy FDP_ACC 2 JCRMI FDP_ACF 1 JCRMI and the functional requirement FDP_ITC 2 Installer The functional requirements of the class FMT FMT_MTD 1 JCRE FMT_MTD 3 JCRE FMT_SMR 1 Installer FMT_SMR 1 FMT_SMF 1 FMT_SMR 1 ADEL FMT_SMF 1 ADEL FMT_SMF 1 CM FMT_SMF 1 EXT_MEM FMT MSA 1 EXT MEM FMT_MSA 3 EXT_MEM FMT_MSA 1 CM FMT_MSA 3 CM FMT_SMR 1 CM FMT_MSA 2 FIREWALL_JCVM FMT_MSA 3 FIREWALL FMT_MSA 3 JCVM FMT_MSA 1 ADEL FMT_MSA 3 ADEL FMT MSA 1 JCRE FMT_MSA 1 JCVM also indirectly contribute to meet this objective OT GLOBAL_ARRAYS_CONFID Only arrays can be designated as global and the only global arrays required in the Java Card API are the APDU buffer and the global byte array input parameter bArray to an applet s install method The clearing requirement of these arrays is met by FDP_RIP 1 APDU and FDP_RIP 1 bArray respectively The JCVM information flow control policy FDP_IFF 1 JCVM FDP_IFC 1 JCVM prevents an application from keeping a pointer to a shared buffer which could be used to read its contents when the buffer is being used by another application Pro
109. ctors appearing in the first two stages Procedures shall ensure protection of TOE material information under delivery and storage that corrective actions are taken in case of improper operation in the delivery process and storage and that people dealing with the procedure for delivery have the required skills e ALC_CMC 4 Production support acceptance procedures and automation e ALC CMS 5 Development tools CM coverage These components contribute to the integrity and correctness of the TOE during its development Procedures dealing with physical personnel organizational technical measures for the confidentiality and integrity of Java Card System software source code and any associated documents shall exist and be applied in software development e ALC DEL 1 Delivery procedures e ALC LCD 1 Developer defined life cycle model e ALC TAT 2 Compliance with implementation standards It is assumed that security procedures are used during all manufacturing and test operations through the production phase to maintain confidentiality and integrity of the TOE and of its manufacturing and test data to prevent any possible copy modification retention theft or unauthorized use e ATE COV2 Analysis of coverage ATE DPT 3 Testing modular design e ATE FUN 1 Functional testing e ATE IND 2 Independent testing sample The purpose of these SARs is to ensure whether the TOE behaves as specified in the design documentation and in accordance with th
110. d 6 Application notes The security functionality is resistant against side channel analysis and similar techniques To fend off attackers with high attack potential an adequate key length must be used references can be found in national and international documents and standards FCS COP 1 1 TDES CMAC The TSF shall perform assignment message authentication and verification in accordance with a specified cryptographic algorithm assignment Triple DES CMAC and cryptographic key sizes assignment 112 and 168 bit that meet the following assignment ANSI X9 52 1998 40 ECB and CBC mode 29 NIST Special Publication 800 38B 29 Section 5 and 6 Application notes 1 The TOE shall provide a subset of cryptographic operations defined in 17 see javacardx crypto Cipher and javacardx security packages 2 This component shall be instantiated according to the version of the Java Card API applicable to the security target and the implemented algorithms 17 3 The security functionality is resistant against side channel analysis and similar techniques To fend off attackers with high attack potential an adequate key length must be used references can be found in national and international documents and standards 6 1 2 6 FDP RIP 1 ABORT Subset Residual Information Protection FDP RIP 1 1 ABORT The TSF shall ensure that any previous information content of a resource is made unavailable upon the de allocation of the
111. d and supplemented by Java Card specific threats from 5 Only threats on TOE information during phase 7 are considered They are summarized in the following table Table 9 Threats Security Target Lite PUBLIC Name T OS OPERATE T SEC BOX BORDER T RND T CONFID APPLI DATA T CONFID JCS CODE T CONFID JCS DATA T INTEG APPLI CODE T INTEG APPLI CODE LOAD T INTEG APPLI DATA T INTEG APPLI DATA LOAD T INTEG JCS CODE T INTEG JCS DATA T SID 1 T SID 2 T EXE CODE 1 T EXE CODE 2 T EXE CODE REMOTE T NATIVE T RESOURCES T DELETION T INSTALL T OBJ DELETION T PHYSICAL Source 6 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 Refined no no no no no no no no no no no no no no no no no no no no yes Approved 3 Refinement to cover additional aspects of O SCP IC not contained in 5 All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 25 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC 3 3 4 Threats not contained in 5 The TOE is required to counter the threats described hereafter a threat agent wishes to abuse the assets either by functional attacks or by environmental manipulation by specific hardware manipulation by a combination of hardware and software manipulations or by any ot
112. des that is any pointer to a bytecode class method object local variable etc actually points to the beginning of piece of data of the expected kind 10 enforcement of rules for binary compatibility full details are given in 19 12 The actual set of checks performed by the verifier is implementation dependent but shall at least enforce all the must clauses imposed in 19 on the bytecodes and the correctness of the CAP files format As most of the actual JCVMs do not perform all the required checks at runtime mainly because smart cards lack memory and CPU resources CAP file verification prior to execution is mandatory On the other hand there is no requirement on the precise moment when the verification shall actually take place as far as it can be ensured that the verified file is not modified thereafter Therefore the bytecodes can be verified either before the loading of the file on to the card or before the installation of the file in the card or before the execution depending on the card capabilities in order to ensure that each bytecode is valid at execution time Note In the present case bytecode verification is performed before loading This concerns in particular the arrays which are considered as instances of the Object class in the Java programming language All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentat
113. ductors JCOP 2 4 2 R3 Self Test Attack Counter Secure AES Secure RSA Secure DES Secure ECC Security Target Lite PUBLIC The OS runs a suite of self tests including tests of RNG and consistency checks on configuration data The system maintains a attack counter which counts the number of detected attacks and ensures the termination of the card when the threshold value is reached The software part of the AES implementation is done in a way to support the protection against DPA DFA and timing attacks The implementation of the RSA algorithm is done in a way which offers protection against DPA DFA and timing attacks The software part of the DES implementation is done in a way to support the protection against DPA DFA and timing attacks the OS ads here additional features to protect from DFA DPA measures are part of the certified platform The implementation of the ECC algorithm is done in a way which offers protection against DPA DFA and timing attacks the implementation is fully done in the certified platform 7 4 Security Features of Hardware This section gives a short overview of the security features of the underlying CC certified hardware which support the overall security architecture of the TOE Coprocessor Security Sensors Secure Fetch Memory security The hardware features cryptographic coprocessors for AES DES and a coprocessor for PKI with protection mechanisms against DPA DFA and
114. e O SB Content O NON SB Content O SB SFR O NON SB SFR and the attributes CPU mode the MMU Segment Table the Special Function Registers to configure the MMU segmentation and the Special Function Registers related to system management FDP ACF 1 2 SecureBox The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed assignment e Code assigned to S SBNativeCode shall only be executed in User Mode e Code assigned to S SBNativeCode shall only be able to perform OP SB ACCESS to O SB CONTENT The ROM EEPROM and RAM which belongs to O SB CONTENT is controlled by the MMU Segment Table used by the Memory Management Unit e Code assigned to S SBNativeCode is able to perform OP SB ACCESS SFR to O SB SFR O SB SFR is defined by the access rights defined in the respective Memory Segment O SB CONTENT in the MMU Segment Table from which the code is actually executed FDP ACF 1 3 SecureBox The TSF shall explicitly authorise access of subjects to objects based on the following additional rules assignment none FDP ACF 1 4 SecureBox The TSF shall explicitly deny access of subjects to objects based on the following additional rules assignment e For S SBNative Code it shall not be possible to perform OP SB ACCESS to O NON SB CONTENT e For S SBNative Code it shall not be possible to perform OP SB ACCESS SFR to O NON SB SFR 6 1 15 3 FMT MSA 3 SecureBox Stati
115. e MIFARE application accessible via contactless interface and via Java Card API availability depends on configuration and hardware 1 3 2 Non TOE hardware software firmware In order to communicate the TOE has to be connected to a terminal that supports the 1507816 or 15014443 protocols In order to communicate 15014443 the TOE may be connected to an antenna or appropriate communication interface e g S 2C which is not part of the scope of this evaluation It is noted that the TOE fulfils its security functions independent of the terminal or other communication interface 1 3 3 TOE Life Cycle The life cycle for this Java Card is based on the general smart card life cycle defined in the Smart Card IC PP 6 and has been adapted to Java Card specialties The main actors are marked with bold letters Table 3 Life Cycle Phase Name Description 1 IC Embedded The IC Embedded Software Developer is in charge of Software Development e smartcard embedded software development including the development of Java applets and e specification of IC pre personalization requirements though the actual data for IC pre personalization come from phase 4 5 or 6 2 IC Development The IC Developer e designs the IC e develops IC Dedicated Software e provides information software or tools to the IC Embedded Software Developer and e receives the smartcard embedded software from the developer through trusted delivery and verification pro
116. e TOE security functional requirements This is accomplished by determining that the developer has tested the security functions against its functional specification and high level design gaining confidence in those tests results by performing a sample of the developer s tests and by independently testing a subset of the security functions e ASE CCL 1 Conformance claims e ASE ECD 1 Extended components definition e ASE_INT 1 ST introduction e ASE OBJ2 Security objectives e ASE_REQ 2 Derived security requirements All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 98 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC e ASE SPD 1 Security problem definition e ASE TSS 1 TOE summary specification These requirements are covered by this document Augmentation of level EAL5 results from the selection of the following three SARs e ALC DVS 2 Sufficiency of security measures EAL5 requires for the development security the assurance component DVS 1 This dictates a documentation and check of the security measures in the development environment The component ALC_DVS 2 requires additionally a justification that the measures provide the necessary level of protection e ASE TSS 2 TOE summary specification with architectural design summary EAL5 requires for the development security the assu
117. e access to the APDU buffer and the global byte array used for the invocation of the install method of the selected applet The only means that the Java Card VM shall provide for an application to execute native code is the invocation of a method of the Java Card API or any additional API See 3 NATIVE p 34 for details The TOE must ensure continued correct operation of its security functions Especially the TOE must prevent the unauthorized use of TOE or use of incorrect or unauthorized instructions or commands or sequence of commands See 3 OPERATE p 37 for details The TOE shall ensure that the re allocation of a memory block for the runtime areas of the JCVM does not disclose any information that was previously stored in that block To be made unavailable means to be physically erased with a default value Except for local variables that do not correspond to method parameters the default values to be used are specified in Java Card Virtual Machine Specification 19 All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 40 of 135 NXP Semiconductors JCOP 2 4 2 R3 OT RESOURCES 4 1 2 3 Services OT ALARM OT CIPHER OT KEY MNGT OT PIN MNGT Note OT REMOTE OT TRANSACTION Note 4 1 2 4 Object Deletion OT OBJ DELETION 4 1 2 5 Applet Management OT DELETION Security Target Li
118. e are security functional requirements in Part 2 of the Common Criteria which refer to random numbers However they define requirements only for the authentication context which is only one of the possible applications of random numbers OT MF_FW The access control mechanisms described by OT MF_FW are directly addressed by the SFP defined by the security functional requirements FDP_ACC 1 SCP FDP_ACF 1 and FMT_MSA 3 SCP OT SEC_BOX_FW The access control mechanisms described by OT SEC_BOX_FW are directly addressed by the SFP defined by the security functional requirements FDP_ACC 2 SecureBox FDP_ACF 1 SecureBox FMT_MSA 3 SecureBox FMT_MSA 1 SecureBox and FMT SMF 1 SecureBox 6 4 SFRs Dependencies Table 29 SFR dependencies and their fullfilment SFR Dep Met FDP_ITC 2 Installer FDP_ACC 1 or FDP_IFC 1 FPT TDC 1 ITC 1 or FTP TRP 1 Yes IFC 2 OM FTP ITC 1 CM FPT TDC 1 FMT_SMR 1 Installer FIA_UID 1 No rationale in Section 6 4 1 FPT_FLS 1 Installer No dependencies Yes FPT_RCV 3 Installer AGD_OPE 1 AGD_OPE 1 Yes FDP_ACC 2 ADEL FDP_ACF 1 EDP ACF 1 ADEL Yes FDP_ACC 1 FDP ACF 1 ADEL FMT_MSA 3 FDP_ACC 2 ADEL FMT_MSA 3 ADEL FDP_RIP 1 ADEL No dependencies FDP_ACC 1 or FDP_IFC 1 Yes FDP_ACC 2 ADEL FMT MSA 1 ADEL FMT SWF Eun SEA ABE ZUM FMT SMR 1 ADEL FMT MSA 3 ADEL FMT MSA 1 EN MSA 1 ADEL MSA FMT_SMR 1 MSA FMT_SMR
119. e understood as outer CBC mode i e CBC mode as defined in 36 and 40 applied to the block cipher algorithm either DES or Triple DES The CBC MAC mode of operation as defined in ISO 9797 1 25 MAC Algorithm 1 also described in Appendix F of 36 is similar to CBC mode but the output of the CBC MAC is restricted to the output of the last Triple DES operation i e only the last block of the ciphertext is returned 8 The input of DES CMAC is not protected against fault injection attacks FCS COP 1 1 AESMAC The TSF shall perform assignment 16 byte AES MAC generation and verification in accordance with a specified cryptographic algorithm assignment AES CBC MAC Mode without Padding and cryptographic key sizes assignment 128 192 256 Bit that meet the following assignment ISO 9797 1 25 MAC Algorithm 1 CBC MAC mode Application Notes 1 The security functionality is resistant against side channel analysis and similar techniques To fend off attackers with high attack potential an adequate key length must be used references can be found in national and international documents and standards 2 The CBC mode is to be understood as outer CBC mode i e CBC mode as defined in 36 and 40 applied to the block cipher algorithm The CBC MAC mode of operation as defined in ISO 9797 1 25 Algorithm 1 and also described in Appendix F of 36 is similar to CBC mode but the output of the CBC MAC is rest
120. e used in the enforcement of the firewall Note although they serve different purposes they share the same name space APDU Application Protocol Data Unit an ISO 7816 4 defined communication format between the card and the off card applications Cards receive requests for service from the CAD in the form of APDUs These are encapsulated in Java Card System by the javacard framework APDU class 17 APDUs manage both the selection cycle of the applets through JCRE mediation and the communication with the Currently selected applet APDU buffer The APDU buffer is the buffer where the messages sent received by the card depart from arrive to The JCRE owns an APDU object which is a JCRE Entry Point and an instance of the javacard framework APDU class that encapsulates APDU messages in an internal byte array called the APDU buffer This object is made accessible to the currently selected applet when needed but any permanent access out of selection scope is strictly prohibited for security reasons Applet The name is given to a Java Card technology based user application An applet is the basic piece of code that can be selected for execution from outside the card Each applet on the card is uniquely identified by its AID Applet deletion manager The on card component that embodies the mechanisms necessary to delete an applet or library and its associated data on smart cards using Java Card technology BCV The bytecode verifie
121. eature It enables complete isolation between applets or controlled communication through additional mechanisms that allow them to share objects when needed The JCRE allows such sharing using the concept of shareable interface objects SIO and static public variables The JCVM should ensure that the only way for applets to access any resources are either through the JCRE or through the Java Card API or other vendor specific APIs This objective can only be guaranteed if applets are correctly typed all the must clauses imposed in chapter 7 of 19 on the byte codes and the correctness of the CAP file format are satisfied The Card Manager is conformant to the Global Platform Card Specification 2 2 1 14 and is responsible for the management of applets in the card For the present TOE the post issuance of applets is allowed For more details of the Java card functionality see Section 1 3 5 The native application MIFARE grey box in Fig 1 is logically only available in the Minor Configuration options MIFARE Emulation B1 and MIFARE Emulation B4 In the Minor Configuration option MIFARE Emulation the grey box is not available in the hardware The Java card design and implementation is based on the Java Card 3 0 1 and on the GlobalPlatform 2 2 1 industry standards The following features comprise the logical scope of the TOE e 3 different communication protocols Approved All information provided in this document is subj
122. ect to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 10 of 135 NXP Semiconductors JCOP 2 4 2 H3 Approved Security Target Lite PUBLIC a ISO 7816 T 1 b ISO 7816 T 0 c ISO 14443 T CL contact less available on J3E145 M64 J3E120 M65 J3E082 M65 not available on J2E145 M64 J2E120 M65 J2E082 M65 e Cryptographic algorithms and functionality a 3DES 112 and 168 bit keys for en decryption CBC and ECB MAC generation and verification Retail MAC CMAC and CBC MAC b AES Advanced Encryption Standard with key length of 128 192 and 256 Bit for en decryption CBC and ECB and MAC generation and verification CMAC CBC MAC c RSA and RSA CRT 1976 up to 2048 bits keys for en decryption and signature generation and verification d RSA and RSA CRT key generation 1976 up to 2048 bits keys e SHA 1 SHA 224 and SHA 256 hash algorithm f ECC over GF p algorithm that can be used for signature generation and signature verification ECDSA from 128 to 320 bits g ECC over GF p key generation algorithm that can be used to generate ECC over GF p key pairs h Random number generation according to class DRG 3 and DRG 2 of AIS 20 8 i Secure point addition for Elliptic Curves over GF p j Diffie Hellman key agreement and EC DH over GF p Java Card 3 0 1 functionality a Garbage Collection fully implemented with complete mem
123. ected code or data nor should they alter integrity or confidentiality of remaining applets The deletion procedure should not be maliciously used to bypass the TSFs 2 Erasure if deemed successful shall ensure that any data owned by the deleted applet is no longer accessible shared objects shall either prevent deletion or be made inaccessible A deleted applet cannot be selected or receive APDU commands Package deletion shall make the code of the package no longer available for execution 3 Power failure or other failures during the process shall be taken into account in the implementation so as to preserve the TSPs This does not mandate however the process to be atomic For instance an interrupted deletion may result in the loss of user data as long as it does not violate the TSPs The deletion procedure and its characteristics whether deletion is either physical or logical what happens if the deleted application was the default applet the order to be observed on the deletion steps are implementation dependent The only commitment is that deletion shall not jeopardize the TOE or its assets in case of failure such as power shortage Deletion of a single applet instance and deletion of a whole package are functionally different operations and may obey different security rules For instance specific packages can be declared to be undeletable for instance the Java Card API packages or the dependency between installed packag
124. ection of its private data and code against disclosure or modification from the Java Card System 3 It provides secure low level cryptographic processing to the Java Card System 4 It supports the needs for any update to a single persistent object or class field to be atomic and possibly a low level transaction mechanism 5 It allows the Java Card System to store data in persistent technology memory or in volatile memory Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 37 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC depending on its needs for instance transient objects must not be stored in non volatile memory The memory model is structured and allows for low level control accesses segmentation fault detection 6 It safely transmits low level exceptions to the TOE arithmetic exceptions checksum errors when applicable We finally require that 7 the IC is designed in accordance with a well defined set of policies and standards likely specified in another protection profile and will be tamper resistant to actually prevent an attacker from extracting or altering security data like cryptographic keys by using commonly employed techniques physical probing and sophisticated analysis of the chip This especially matters to the management storage and operati
125. ecurity attribute Description Value Active Applets The set of the active applets AIDs An active applet is an applet that is selected on at least one of the logical channels Applet Selection Status Selected or Deselected Applet s Version number version number of an applet package indicated in the export file Class Identifies the implementation class of the remote object Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 57 of 135 NXP Semiconductors JCOP 2 4 2 R3 Security Target Lite PUBLIC Security attribute Context Currently Active Context Dependent package AID ExportedInfo Identifier LC Selection Status LifeTime Owner Package AID Registered Applets Remote Resident Packages Returned References Selected Applet Context Sharing Static References Address space Description Value Package AID or Java Card RE Package AID or Java Card RE Allows the retrieval of the Package AID and Applet s version number 18 4 5 2 Boolean indicates whether the remote object is exportable or not The Identifier of a remote object or method is a number that uniquely identifies the remote object or method respectively Multiselectable Non multiselectable or None CLEAR ON DESELECT or PERSISTENT The Owner of an object is either the ap
126. ed disclosure or modification The runtime security data of the JCRE like for instance the AIDs used to identify the installed applets the currently selected applet the current context of execution and the owner of each object To be protected from unauthorized disclosure and modification Private data of the API like the contents of its private fields To be protected from unauthorized disclosure and modification Cryptographic data used in runtime cryptographic computations like a seed used to generate a key To be protected from unauthorized disclosure and modification Private data of the System accessible via the root applet if authenticated with a admin key like quality parameters for key generation memory layout settings transport key Private data of the System accessible via the root applet if authenticated with a transport or admin key like protocol parameters compliance settings Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 24 of 135 NXP Semiconduc tors JCOP 2 4 2 R3 3 3 Threats This section introduces the threats to the assets against which specific protection within the TOE or its environment is required It is assumed that all attackers have high level of expertise opportunity and resources General threats for smart card native operating systems were define
127. ed and 4KB MIFARE EEPROM memory is reserved For the P5CC145V0B hardware of this TOE only one configuration exists This is equivalent to MIFARE Emulation A of P5CD145VOB From 6 relevant requirements for the hardware platform were taken The relevant requirements for the Java Card functionality were taken from 5 JCOP 2 4 2 R3 is based on Java Card 3 0 1 and Global Platform 2 2 1 industry standards and allows post issuance downloading of applications that have been previously verified by an off card trusted IT component It implements high security mechanisms and supports various protocols cryptographic algorithms and the Secure Box see Section 1 3 1 1 3 TOE description This part of the document describes the TOE to provide an understanding of its security requirements and addresses the product type and the general IT features of the TOE 1 3 1 TOE abstract and definition The target of evaluation TOE is the JCOP 2 4 2 R3 It consists of e Smart card platform SCP parts of the hardware platform and hardware abstraction layer e Embedded software Java Card Virtual Machine Runtime Environment Java Card API Card Manager e Native MIFARE application physically always present but logical availability depends on configuration see section 2 2 5 of the HW Security Target 10 The TOE does not include any software on the application layer Java Card applets This is shown schematically in Fig 1 The Smart Ca
128. ent by the CAD has occurred Application note Modification errors should be understood as modification substitution unrecoverable ordering change of data and any other integrity error that may cause the application package to be installed on the card to be different from the one sent by the CAD 6 1 9 5 FIA UID 1 CM Timing of identification FIA UID 1 1 CM The TSF shall allow assignment the following TSF mediated command on behalf of the user to be performed before the user is identified Table 24 TSF mediated commands for FIA UID 1 Command Objects Get Data ISD DATA ISSUER IDENTIFICATION NUMBER ISD DATA CARD IMAGE NUMBER PLATFORM DATA CARD RECOGNITION DATA ISD DATA KEY INFORMATION TEMPLATE ISD DATA SCP INFORMATION PLATFORM DATA MANUFACTURING Select Applet Initialize Update APDU BUFFER External Authenticate APDU BUFFER Identify FIA UID 1 2 CM The TSF shall require each user to be successfully identified before allowing any other TSF mediated actions on behalf of that user 6 1 9 6 FMT MSA 1 CM Management of security attributes FMT MSA 1 1 CM Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 86 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC The TSF shall enforce the PACKAGE LOADING information flow control SFP to restrict the ability
129. erification OE VERIFICATION It is also covered by the isolation commitments stated in the OT FIREWALL objective It relies in its turn on the correct identification of applets stated in OT SID Moreover as the firewall is dynamically enforced it shall never stop operating as stated in the OT OPERATE objective As the firewall is a software tool automating critical controls Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 46 of 135 NXP Semiconductors JCOP 2 4 2 H3 Approved Security Target Lite PUBLIC the objective OT ALARM asks for it to provide clear warning and error messages so that the appropriate countermeasure can be taken The objectives OT CARD MANAGEMENT and OE VERIFICATION contribute to cover this threat by controlling the access to card management functions and by checking the bytecode respectively The objectives OT SCP RECOVERY and OT SCP SUPPORT are intended to support the OT OPERATE and OT ALARM objectives of the TOE so they are indirectly related to the threats that these latter objectives contribute to counter As applets may need to share some data or communicate with the CAD cryptographic functions are required to actually protect the exchanged information OT CIPHER Remark that even if the TOE shall provide access to the appropriate TSFs it is still the responsibility
130. es FCS HNG 1 1 FCS RNG 1 2 Generation of random numbers requires that random numbers meet a defined quality metric FCS_RNG 1 There are no management activities foreseen FCS_RNG 1 There are no actions defined to be auditable Quality metric for random numbers No other components No dependencies The TSF shall provide a selection physical non physical true deterministic hybrid random number generator that implements assignment list of security capabilities The TSF shall provide random numbers that meet assignment a defined quality metric Application Note A physical random number generator RNG produces the random number by a noise source based on physical random processes A non physical true RNG uses a noise source based on non physical random processes like human interaction key strokes mouse movement A deterministic RNG uses an random Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 52 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC seed to produce a pseudorandom output A hybrid RNG combines the principles of physical and deterministic RNGs 5 2 Definition of the Family FPT EMSEC This section has been taken over from the certified BSI PP 0017 Protection Profile Machine Readable travel Document with ICAO Application Basic Access
131. es may forbid the deletion like a package using super classes or super interfaces declared in another package 3 6 5 Services ALARM The TOE shall provide appropriate feedback upon detection of a potential security violation This particularly concerns the type errors detected by the bytecode verifier the security Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 36 of 135 NXP Semiconductors JCOP 2 4 2 R3 0PERATE RESOURCES CIPHER KEY MNGT PIN MNGT 5 Security Target Lite PUBLIC exceptions thrown by the JCVM or any other security related event occurring during the execution of a TSF 1 The TOE must ensure continued correct operation of its security functions 2 In case of failure during its operation the TOE must also return to a well defined valid state before the next service request The TOE controls the availability of resources for the applications and enforces quotas and limitations in order to prevent unauthorized denial of service or malfunction of the TSFs This concerns both execution dynamic memory allocation and installation static memory allocation of applications and packages The TOE shall provide a means to the applications for ciphering sensitive data for instance through a programming interface to low level highly secure crypto
132. es 1 to 6 Applet development is outside the scope of this evaluation Applets can be loaded into ROM or EEPROM Applet loading into ROM can only be done in phase 3 Applet loading into EEPROM can be done in phases 3 4 5 and 6 Applet loading in phase 7 is also allowed This means post issuance loading of applets can be done for a certified TOE It is possible to load patch code into EEPROM in phases 3 4 5 and 6 The certification is only valid for the ROM code version and the patch code version if applicable as stated in Table 4 The delivery process from NXP to their customers to phase 4 or phase 5 of the life cycle guarantees that the customer is aware of the exact versions of the different parts of the TOE as outlined above TOE documentation is delivered in electronic form encrypted according to defined mailing procedures Note The TOE development and manufacturing environment phases 1 to 3 is in the scope of this ST These phases are under the TOE developer scope of control Therefore the objectives for the environment related to phase 1 to 3 are covered by Assurance measures which are materialized by documents process and procedures evaluated through the TOE evaluation process The product usage phases phase 4 to 7 not in the scope of the evaluation During these phases the TOE is no more under the developer control In this environment the TOE protects itself with its own Security functions But some
133. ese types of response reaction the events listed above will have the following mapping Table 31 Response Reaction on SF Audit events F HW Reset 3 Terminate Lock card Event Exception IC or other card session HW action Abnormal environmental conditions X Physical tampering X X X X EEPROM failure audited X Card Manager life cycle state inconsistency X Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 117 of 135 NXP Semiconductors JCOP 2 4 2 R3 Approved Security Target Lite PUBLIC HW Reset Event Exception IC or other UU session HW action audited through the life cycle checks in all administrative operations OS internal life cycle X Applet life cycle inconsistency X Corruption of check summed objects X X Unavailability of resources audited through X the object allocation mechanism Abortion of a transaction in an unexpected X context Violation of the Firewall or JCVM SFPs X Array overflow X Other runtime errors X X X Card tearing unexpected removal of the X Card out of the CAD and power failure SF CryptoKey This TSF is responsible for secure cryptographic key management Cryptographic operation is provided by the following TSF This TSF provides the following functionality SF CRK_GDE Generation of DES keys with length of 112 and
134. et of objects that share a common structure and behavior Each class declares a collection of fields and methods associated to its instances The contents of the fields determine the internal state of a class instance and the methods the operations that can be applied to it Classes are ordered within a class hierarchy A class declared as a specialization a subclass of another class its super class inherits all the fields and methods of the latter Java platform classes should not be confused with the classes of the functional requirements FIA defined in the CC Card Manger A context is an object space partition associated to a package Applets within the same Java technology based package belong to the same context The firewall is the boundary between contexts see Current context The JCRE keeps track of the current Java Card System context also called the active context When a virtual method is invoked on an object and a context switch is required and permitted the current context is changed to correspond to the context of the applet that owns the object When that method returns the previous context is restored Invocations of static methods have no effect on the current context The current context and sharing status of an object together determine if access to an object is permissible The applet has been selected for execution in the current session The JCRE keeps track of the currently selected Java Card apple
135. events and based upon these rules indicate a potential violation of the enforcement of the SFRs upon detection of a potential security violation Refinement The potential security violation stands for one of the following events e CAP file inconsistency e typing error in the operands of a bytecode e applet life cycle inconsistency e card tearing unexpected removal of the Card out of the CAD and power failure e abort of a transaction in an unexpected context see abortTransaction 17 and 18 7 6 2 e violation of the Firewall or JCVM SFPs e unavailability of resources e array overflow e assignment Card Manager life cycle state OP_READY INITIALIZED SECURED CARD_LOCKED TERMINATED inconsistency audited through the life cycle checks in all administrative operations and the self test mechanism on start up e OS Internal life cycle state FUSED PROTECTED inconsistency audited through the life cycle checks in all administrative operations e Abnormal environmental conditions frequency voltage temperature e Physical tampering e EEPROM failure audited through exceptions in the read write operations and consistency integrity check e Corruption of check summed objects e Access violation access to memory not defined as accessible or available Application note e The developer shall provide the exhaustive list of actual potential security violations the TOE reacts to For instance other runtime er
136. f an applet on the card is covered by the objective OT INSTALL The installation parameters of an applet like its name are loaded into a global array that is also shared by all the applications The disclosure of those parameters which could be used to impersonate the applet is countered by the objectives OT GLOBAL ARRAYS CONFID and OT GLOBAL ARRAYS INTEG The objective OT CARD MANAGEMENT contributes by preventing usurpation of identity resulting from a malicious installation of an applet on the card to counter this threat T SID 2 This is covered by integrity of TSF data subject identification OT SID the firewall OT FIREWALL and its good working order OT OPERATE The objective OT INSTALL contributes to counter this threat by ensuring that installing an applet has no effect on the state of other applets and thus can t change the TOE s attribution of privileged roles The objectives OT SCP RECOVERY and OT SCP SUPPORT are intended to support the OT OPERATE objective of the TOE so they are indirectly related to the threats that this latter objective contributes to counter Unauthorized Execution Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 49 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC T EXE CODE 1 Unauthorized execution of a method is prevented by the objective OT
137. for assignment setting the Card Life Cycle State and setting the OS Internal Life Cycle State 6 1 14 3 FAU SAS 1 SCP Audit Data Storage This functional requirement has been taken over from the ST of the certified hardware platform P5CD145VOB that is conformant to 6 FAU SAS 1 1 SCP Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 93 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC The TSF shall provide assignment test personnel before TOE Delivery with the capability to store the assignment Initialisation Data and or Prepersonalisation Data and or supplements of the Smartcard Embedded Software in the assignment audit records 6 1 14 4 FCS RNG 1 Quality metric for Random Numbers FCS RNG 1 1 The TSF shall provide a deterministic random number generator that implements e Class DRG 3 of 8 e DRG 3 1 If initialized with a random seed selection assignment using the PTRNG of the HW platform conform to class P2 in AIS31 32 the internal state of the RNG shall selection have at least 100 bit MIN entropy e DRG 3 2 The RNG provides forward secrecy e DRG 3 3 The RNG provides enhanced backward secrecy FCS RNG 1 2 The TSF shall provide random numbers that meet e Class DRG 3 of 8 e DRG 3 4 The RNG initialized with a random seed assignment
138. g asymmetric techniques 24 ISO IEC 9796 2 2002 Information technology Security techniques Digital signature schemes giving message recovery Part 2 Integer factorization based mechanisms 25 ISO IEC 9797 1 1999 Information technology Security techniques Message Authentication Codes MACs Part 1 Mechanisms using a block cipher 26 ISO IEC 14888 3 Information technology Security techniques Digital signatures with appendix Part 3 Discrete logarithm based mechanisms 2008 27 FIPS PUB 180 3 Secure Hash Standard Federal Information Processing Standards Publication October 2008 US Department of Commerce National Institute of Standards and Technology 28 Common Criteria Protection Profile Machine Readable Travel Document with ICAO Application Basic Access Control Version 1 0 18 08 2005 registered at BSI under Registration number BSI PP 0017 29 NIST Special Publication 800 38B Recommendation for Block Cipher Modes of Operation The CMAC Mode for Authentication Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg MD 20899 8930 May 2005 30 JCOP V2 4 2 Revision 3 Secure Smart Card Controller User Manual Rev 0 6 16th July 2013 Docstore ID 258406 31 JCOP V2 4 2 Revision 3 Secure Smart Card Controller Administrator Manual Rev 0 5 16 July 2013 Docstore ID 258605 32 Anwendungshinweise und Interpretationen zum Schema AIS 31 F
139. g to NIST 800 38B 29 with cryptographic key length of 128 192 and 256 see 6 1 2 5 FCS COP 1 AES CMAC SF COP TDC TDES CMAC computation according to NIST 800 38B 29 with cryptographic key length of 112 bit see 6 1 2 5 FCS COP 1 TDES CMAC 7 1 5 SF 1 amp A The TSF provides the following functionality with respect to card manager administrator authentication SF l amp A CRM The TSF provides a challenge response mechanism for card manager authentication and ensures that the session authentication data cannot be reused After successful authentication a trusted channel that is protected in integrity and confidentiality is established 6 1 14 2 1 ifeCycle SF l amp A The TSF blocks the card when 66 consecutive unsuccessful card manager authentication attempts via secure messaging using D APP KEY occur see 6 1 9 3 FDP_IFF 1 CM SF l amp A Package execution is possible before authentication 6 1 9 5 FIA UID 1 CM 7 1 6 SF SecureManagment The TSF provide a secure management of TOE resources SF SMG AID The TSF maintain a unique AID and version number for each package the AID of each registered applet and whether a registered applet is currently selected for execution 19 86 5 see 6 1 4 1 FIA ATD 1 AID 6 1 4 2 FIA UID Z AID and 6 1 4 3 USB 1 AID SF SMG The TSF ensures that packages are unable to observe operations on secret keys and PIN codes by other subjects see 6 1 3 3
140. gistered on the card and especially the default applet and the currently selected applet and all other active applets in Java Card System 2 2 1 A change of identity especially standing for an administrative role like an applet impersonating the JCRE is Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 35 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC a severe violation of the TOE Security Policy TSP Selection controls the access to any data exchange between the TOE and the CAD and therefore must be protected as well The loading of a package or any exchange of data through the APDU buffer which can be accessed by any applet can lead to disclosure of keys application code or data and so on OBJ DELETION Deallocation of objects must be secure 1 It should not introduce security holes in the form of references pointing to memory zones that are not longer in use or have been reused for other purposes Deletion of collection of objects should not be maliciously used to circumvent the TSFs 2 Erasure if deemed successful shall ensure that the deleted class instance is no longer accessible DELETION Deletion of applets must be secure 1 Deletion of installed applets or packages should not introduce security holes in the form of broken references to garbage coll
141. graphic services In particular those services must support cryptographic algorithms consistent with cryptographic usage policies and standards The TOE shall provide a means to securely manage cryptographic keys This includes 1 Keys shall be generated in accordance with specified cryptographic key generation algorithms and specified cryptographic key sizes 2 Keys must be distributed in accordance with specified cryptographic key distribution methods 3 Keys must be initialized before being used 4 Keys shall be destroyed in accordance with specified cryptographic key destruction methods The TOE shall provide a means to securely manage PIN objects This includes 1 Atomic update of PIN value and try counter 2 No rollback on the PIN checking function 3 Keeping the PIN value once initialized secret for instance no clear PIN reading function 4 Enhanced protection of PIN s security attributes state try counter in confidentiality and integrity The smart card platform must be secure with respect to the TSP Then 1 After a power loss or sudden card removal prior to completion of some communication protocol the SCP will allow the TOE on the next power up to either complete the interrupted operation or revert to a secure state 2 It does not allow the TSFs to be bypassed or altered and does not allow access to other low level functions than those made available by the packages of the API That includes the prot
142. gust 2013 55 of 135 NXP Semiconductors JCOP 2 4 2 R3 Security Target Lite PUBLIC Subject Description S APPLET Any applet instance S BCV The bytecode verifier BCV which acts on behalf of the verification authority who is in charge of the bytecode verification of the packages This subject is involved in the PACKAGE LOADING security policy defined in 7 1 7 S CAD The CAD represents the actor that requests by issuing commands to the card for RMI services It also plays the role of the off card entity that communicates with the S INSTALLER S INSTALLER The installer is the on card entity which acts on behalf of the card issuer This subject is involved in the loading of packages and installation of applets S JCRE The runtime environment under which Java programs in a smart card are executed S JCVM The bytecode interpreter that enforces the firewall at runtime S LOCAL Operand stack of a JCVM frame or local variable of a JCVM frame containing an object or an array of references S MEMBER S MEMBER Any object s field static field or array position S PACKAGE A package is a namespace within the Java programming language that may contain classes and interfaces and in the context of Java Card technology it defines either a user library or one or several applets S ROOTAPP The root applet behaves like an applet from the user point of view S SBNativeCode even though it is part of the OS It is used in the pre per
143. hat all operations are performed entirely or get rolled back at next power up cycle Secure Channel OS provides secure channels for communication with off card systems to ensure the confidentiality integrity and authenticity of the transferred data Authentication Retry Counter OS limits the number of unsuccessful authentications to a predefined number Physical Protection In the course of this chapter an overview of mechanisms to protect against physical manipulation is given Protected Values For security relevant values the OS uses values coded in a redundant manner to allow the detection of manipulations Secure Copy It is a mechanism to securely move data from one location to another In particular this mechanism protects against leakage of data through side channels Clear Memory Memory areas containing sensitive data are cleared after usage This is also supported by the used crypto library which also clears all used memory areas after usage Secure Compare It is a mechanism to securely compare data In particular this mechanism protects against leakage of data through side channels and hardens fault attacks Secure Boolean Conversion It is a mechanism to securely cast Boolean variables into a Secure Value All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 125 of 135 NXP Semicon
144. he state AUTHENTICATED TRANSPORT FDP ACF 1 3 LifeCycle The TSF shall explicitly authorize access of subjects to objects based on the following additional rules assignment none ACF 1 4 LifeCycle The TSF shall explicitly deny access of subjects to objects based on the following additional rules assignment 6 If the card life cycle state is TERMINATED the TOE is blocked and the access of subjects is no more allowed 7 If the OS Internal Life Cycle is FUSED the TOE blocks any read or write access by S ROOTAPP 6 1 13 3 FMT_MSA 1 LifeCycle Management of Security Attributes FMT MSA 1 1 LifeCycle The TSF shall enforce the assignment LIFE CYCLE MANAGEMENT access control SFP to restrict the ability to selection modify the security attributes assignment Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 92 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC card life cycle state to assignment S PACKAGE CM and S JCRE and the security attributes assignment OS Internal Life Cycle States to assignment S ROOTAPP 6 1 13 4 FMT MSA 3 LifeCycle Static Attribute Initialization FMT MSA 3 1 LifeCycle The TSF shall enforce the assignment LIFE CYCLE MANAGEMENT access control SFP to provide restrictive default values for security attributes that are used t
145. hen the Currently Active Context is the object s context All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 58 of 135 NXP Semiconductors JCOP 2 4 2 R3 Security Target Lite PUBLIC Operation OP CREATE Sharing LifeTime OP DELETE_APPLET O APPLET OP DELETE_PCKG O CODE_PKG OP DELETE_PCKG_APPLET O CODE_ PKG OP GET_ROR O APPLET OP INSTANCE FIELD O JAVAOBJECT field OP INVK VIRTUAL O JAVAOBJECT method arg1 OP INVK INTERFACE O JAVAOBJECT method arg1 OP INVOKE O RMI SERVICE OP JAVA OP PUT S1 S2 l OP RET RORD S JCRE S CAD I RORD OP THROW O JAVAOBJECT OP TYPE ACCESS O JAVAOBJECT class OP CREATE EXT MEM INSTANCE OP READ EXT MEM O EXT MEM IN STANCE address OP WRITE EXT MEM O EXT MEM IN STANCE address Description Creation of an object new or makeTransient call Delete an installed applet and its objects either logically or physically Delete a package either logically or physically Delete a package and its installed applets either logically or physically Retrieves the initial remote object reference of a RMI based applet This reference is the seed which the CAD client application needs to begin remote method invocations Read Write a field of an instance of a class in the Java programming lang
146. her type of attacks Threats have to be split in e Threats against which specific protection within the TOE is required e Threats against which specific protection within the environment is required 3 3 1 1 Unauthorized full or partial Cloning of the TOE The cloning of the functional behavior of the Smart Card on its ISO command interface is the highest level security concern in the application context The cloning of that functional behavior requires e To develop a functional equivalent of the Smart Card Native Operating System and its applications to disclose to interpret and employ the secret User Data stored in the TOE and e To develop and build a functional equivalent of the Smart Card using the input from the previous steps The Native Operating System must ensure that especially the critical User Data are stored and processed in a secure way but also ensures that critical User Data are treated as required in the application context In addition the personalization process supported by the Smart Card Native Operating System and by the Smart Card Integrated Circuit in addition must be secure This last step is beyond the scope of this Security Target As a result the threat cloning of the functional behavior of the Smart Card on its ISO command interface is averted by the combination of measures which split into those being evaluated according to this Security Target and the corresponding personalization process Therefore
147. ical component to EAL5 only ASE TSS 1 is found in EAL5 Due to the nature of the TOE there is a need to explain the architecture in more detail 7 TOE summary specification ASE TSS This section provides a description of the security functions and assurance measures of the TOE that meet the TOE security requirements 7 1 Security Functionality The following table provides a list of all security functions Table 30 List of all security functions TOE Security Function Short Description SF AccessControl enforces the access control SF Audit Audit functionality SF CryptoKey Cryptographic key management SF CryptoOperation Cryptographic operation SF I amp A Identification and authentication SF SecureManagement Secure management of TOE resources SF PIN PIN management SF Loadlntegrity Package integrity check SF Transaction Transaction management SF Hardware TSF of the underlying IC SF CryptoLib TSF of the certified crypto library Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 114 of 135 NXP Semiconductors JCOP 2 4 2 R3 Security Target Lite PUBLIC 7 1 1 SF AccessControl This security function ensures the access and information flow control policies of the TOE SF ACC LCM SF ACC FW SF ACC IFC SF ACC SBX SF ACC PLI SF ACC SF ACC RMI SF ACC EME L
148. ication is performed before loading 3 6 3 4 Linking and Verification Beyond functional issues the installer ensures at least a property that matters for security the loading order shall guarantee that each newly loaded package references only packages that have been already loaded on the card The linker can ensure this property because the Java Card platform does not support dynamic downloading of classes 3 6 4 Card Management CARD MANAGEMENT 1 The card manager CM shall control the access to card management functions such as the installation update or deletion of applets 2 The card manager shall implement the card issuer s policy on the card INSTALL Installation of a package or an applet is secure 1 The TOE must be able to return to a safe and consistent state should the installation fail or be cancelled whatever the reasons 2 Installing an application must have no effect on the code and data of already installed applets The installation procedure should not be used to bypass the TSFs In short it is a secure atomic operation and free of harmful effects on the state of the other applets 3 The procedure of loading and installing a package shall ensure its integrity and authenticity SID 1 Users and subjects of the TOE must be identified 2 The identity of sensitive users and subjects associated with administrative and privileged roles must be particularly protected this concerns the JCRE the applets re
149. ication s context requirements Each authorized role has certain specified privileges which allow access only to selected portions of the TOE and the information it contains Access beyond those specified privileges could result in exposure of assets On another hand an attacker may gain access to sensitive data without having permission from the entity that owns or is responsible for the information or resources T OS OPERATE Complementary note T SEC BOX BORDER Modification of the correct NOS behavior by unauthorized use of TOE or use of incorrect or unauthorized instructions or commands or sequence of commands in order to obtain an unauthorized execution of the TOE code An attacker may cause a malfunction of TSF or of the Smart Card embedded NOS in order to 1 bypass the security mechanisms i e authentication or access control mechanisms or 2 obtain unexpected result from the embedded NOS behavior Different kind of attack path may be used as e Applying incorrect unexpected or unauthorized instructions commands or command sequences e Provoking insecure state by insertion of interrupt reset premature termination of transaction or communication between IC and the reading device Any implementation flaw in the NOS itself can be exploited with this attack path to lead to an unsecured state of the state machine of the NOS The attacker uses the available interfaces of the TOE A user could have certain specified privi
150. ifeC FIA AFL 1 PIN FDP ACF 1 SecureBox FMT MSA 3 SecureBox ACF 1 LifeC FCS RNG 1 FPT EMSEC 1 FDP ACC 2 SecureBox FTP ITC 1 LifeC FMT MSA 3 SCP FMT MSA 3 LifeC OT GLOBAL ARRAYS INTEG OT NATIVE OT OPERATE x OT REALLOCATION OT RESOURCES OT ALARM OT CIPHER OT KEY MNGT OT PIN MNGT OT REMOTE OT TRANSACTION OT OBJ DELETION OT DELETION OT LOAD OT INSTALL OT SCP IC x OT SCP RECOVERY OT SCP SUPPORT OT EXT MEM OT MF_FW x OT CARD MANAGEMENT X X X X x OT IDENTIFICATION x OT RND X x OT SEC BOX FW X X X X X Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 104 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC 6 3 2 Security Functional Requirements Rationale from 5 The following chapters have been taken from 5 without modifications 6 3 2 1 Security Objectives for the TOE Identification OT SID Refined Subjects identity is AID based applets packages and is met by the following SFRs ITC 2 Installer FIA ATD 1 AID FMT MSA 1 JCRE FMT_MSA 1 JCVM FMT_MSA 1 ADEL FMT_MSA 1 CM FMT_MSA 3 ADEL FMT_MSA 3 FIREWALL FMT_MSA 3 JCVM FMT_MSA 3 CM FMT_SMF 1 CM FMT_SMF 1 ADEL FMT_SMF 1 ADEL FMT_MTD 1 JCRE FMT_MTD 3 JCRE FMT_SMF 1 EXT_MEM FMT_MSA 1 EXT_MEM and FMT_MSA 3 EXT_MEM Lastly installation procedures ensure prote
151. ility status of O is that of O The following access control rules determine when an operation among controlled subjects and objects is allowed by the policy e R JAVA 14 18 11 3 4 1 Applet Instance Deletion S ADEL may perform OP DELETE APPLET upon an O APPLET only if 1 S ADEL is currently selected 2 there is no instance in the context of O APPLET that is active in any logical channel and 3 there is no O JAVAOBJECT owned by O APPLET such that either O JAVAOBJECT is reachable from an applet instance distinct from O APPLET O JAVAOBJECT is reachable from a package P or 18 88 5 O JAVAOBJECT is remote reachable e R JAVA 15 18 11 3 4 1 Multiple Applet Instance Deletion S ADEL may perform OP DELETE APPLET upon several O APPLET only if 1 S ADEL is currently selected 2 there is no instance of any of the O APPLET being deleted that is active in any logical channel and 3 there is no O JAVAOBJECT owned by any of the O APPLET being deleted such that either O JAVAOBJECT is reachable from an applet instance distinct from any of those O APPLET or Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 80 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC O JAVAOBJECT is reachable from a package or 18 58 5 O JAVAOBJECT is remote reachab
152. ion Rev 00 02 2nd August 2013 34 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC Another important aspect to be considered about bytecode verification and application downloading is first the assurance that every package required by the loaded applet is indeed on the card in a binary compatible version binary compatibility is explained in 19 4 4 second that the export files used to check and link the loaded applet have the corresponding correct counterpart on the card 3 6 3 3 Integrity and Authentication Verification off card is useless if the application package is modified afterwards The usage of cryptographic certifications coupled with the verifier in a secure module is a simple means to prevent any attempt of modification between package verification and package installation Once a verification authority has verified the package it signs it and sends it to the card Prior to the installation of the package the card verifies the signature of the package which authenticates the fact that it has been successfully verified In addition to this a secured communication channel is used to communicate it to the card ensuring that no modification has been performed on it Alternatively the card itself may include a verifier and perform the checks prior to the effective installation of the applet or provide means for the bytecodes to be verified dynamically Note In the present case bytecode verif
153. ion to the assumptions taken from 5 an additional assumption is made which is describing the protection during packaging finishing and personalization A USE DIAG A USE KEYS Note A PPROCESS SEC IC It is assumed that the operational environment supports and uses the secure communication protocols offered by TOE It is assumed that the keys which are stored outside the TOE and which are used for secure communication and authentication between Smart Card and terminals are protected for confidentiality and integrity in their own storage environment This is to assume that the keys used in terminals or systems are correctly protected for confidentiality and integrity in their own environment as the disclosure of such information which is shared with the TOE but is not under the TOE control may compromise the security of the TOE It is assumed that security procedures are used after delivery of the TOE by the TOE Manufacturer up to delivery to the endconsumer to maintain confidentiality and integrity of the TOE and of its manufacturing and test data to prevent any possible Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 31 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC copy modification retention theft or unauthorised use This means that the Phases after TOE De
154. ives of the TOE so they are indirectly related to the threats that these latter objectives contribute to counter Finally the objective OT EXT MEM provides access control for external memory and therefore also contributes to counter this threat Integrity All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 47 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC T INTEG APPLI CODE This threat is countered by the list of properties described in the 4 VERIFICATION security aspect Bytecode verification ensures that each of the instructions used on the Java Card platform is used for its intended purpose and in the intended scope of accessibility As none of these instructions enables modifying a piece of code no Java Card applet can therefore be executed to modify a piece of code Native applications are also harmless because of the objective OT NATIVE so no application can run to modify a piece of code The 4 VERIFICATION security aspect is addressed in this configuration by the objective for the environment OE VERIFICATION The objectives OT CARD MANAGEMENT and OE VERIFICATION contribute to cover this threat by controlling the access to card management functions and by checking the bytecode respectively Finally the objective OT EXT MEM provides access control for external memory and therefore
155. ker may gather information about the produced random numbers which might be a problem because they may be used for instance to generate cryptographic keys Here the attacker is expected to take advantage of statistical properties of the random numbers generated by the TOE without specific knowledge about the TOE s generator Malfunctions or premature ageing are also considered which may assist in getting information about random numbers 3 3 2 Threats from 5 The following threats specific for the Java Card functionality were taken from 5 3 3 2 1 Confidentiality T CONFID APPLI DATA The attacker executes an application to disclose data belonging to another application See 4 CONFID APPLI DATA p 32 for details Directly threatened asset s D APP C DATA D PIN and D APP KEYs T CONFID JCS CODE _ The attacker executes an application to disclose the Java Card System code See CONFID JCS CODE p 32 for details Directly threatened asset s D JCS CODE T CONFID JCS DATA The attacker executes an application to disclose data belonging to the Java Card System See CONFID JCS DATA p 32 for details Directly threatened asset s D API DATA D SEC DATA D JCS DATA D JCS KEYs and D CRYPTO 3 3 2 2 Integrity T INTEG APPLI CODE The attacker executes an application to alter part of its own or another application s code See INTEG APPLI CODE p 33 for details Directly threatened asset s D APP CODE T INTEG AP
156. l analysis and similar techniques It is demonstrated for curves defined by NIST 42 and Brainpool 34 only To fend off attackers with high attack potential an adequate key length must be used references can be found in national and international documents and standards 2 The supported Diffie Hellman key exchange algorithm is defined in ISO 11770 3 23 Key agreement mechanism 1 FCS COP 1 1 DESMAC Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 69 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC The TSF shall perform assignment 8 byte MAC generation and verification in accordance with a specified cryptographic algorithm assignment Triple DES in outer CBC MAC Mode without padding or with padding method 1 or method 2 and cryptographic key sizes assignment 112 168 Bit that meet the following assignment I509797 1 MAC Algorithm 1 without Padding MAC Algorithm 1 with padding Method 1 or Method 2 MAC Algorithm 3 with padding Method 1 or Method 2 25 Application Notes 1 The security functionality is resistant against side channel analysis and similar techniques To fend off attackers with high attack potential an adequate key length must be used references can be found in national and international documents and standards 2 The CBC mode is to b
157. l attacks at runtime in order to gain write access to the memory zone where executable code is stored If the configuration allows post issuance application loading this threat also concerns the modification of application code in transit to the card Application data must be protected against unauthorized modification This concerns logical attacks at runtime in order to gain unauthorized write access to application data If the configuration allows post issuance application loading this threat also concerns the modification of application data contained in a package in transit to the card For instance a package contains the values to be used for initializing the static fields of the package Java Card System code must be protected against unauthorized modification This concerns logical attacks at runtime in order to gain write access to executable code Java Card System data must be protected against unauthorized modification This concerns logical attacks at runtime in order to gain write access to Java Card System data Java Card System data includes the data managed by the Java Card runtime environment the virtual machine and the internal data of Java Card API classes as well 3 6 3 Unauthorized Executions EXE APPLI CODE EXE JCS CODE Application byte code must be protected against unauthorized execution This concerns 1 invoking a method outside the scope of the visibility rules provided by the public private access
158. ld by the security objective on the operational environment OE USE_DIAG which guarantees that secure TOE communication protocols are supported and used by the environment Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 51 of 135 NXP Semiconductors JCOP 2 4 2 R3 A USE KEYS A PROCESS SEC IC Security Target Lite PUBLIC This assumption is upheld by the security objective on the operational environment OE USE KEYS which guarantees that during the TOE usage the terminal or system in interaction with the TOE ensures the protection integrity and confidentiality of their own keys by operational means and or procedures This assumption is upheld by the security objective on the operational environment OE PROCESS SEC which guarantees protection during composite product manufacturing 5 Extended Components Definition ASE ECD 5 1 Definition of Family FCS_RNG This section has been taken over from the certified BSI PP 0035 Smartcard IC Platform Protection profile 6 Family behavior This family defines quality requirements for the generation of random numbers which are intended to be use for cryptographic purposes Component leveling FCS RNG Generation of random numbers 1 FCS RNG 1 Management Audit FCS RNG 1 Hierarchical to Dependenci
159. le e R JAVA 16 18 11 3 4 2 Applet Library Package Deletion S ADEL may perform OP DELETE PCKG upon an O CODE_PKG only if 1 S ADEL is currently selected 2 no reachable O JAVAOBJECT from a package distinct from O CODE PKG that is an instance of a class that belongs to O CODE exists on the card and 3 there is no resident package on the card that depends on O CODE PKG e R JAVA 17 18 11 3 4 3 Applet Package and Contained Instances Deletion S ADEL may perform OP DELETE PCKG APPLET upon an O CODE_PKG only if 1 S ADEL is currently selected 2 no reachable O JAVAOBJECT from a package distinct from O CODE which is an instance of a class that belongs to O CODE exists on the card 3 there is no package loaded on the card that depends on O CODE PKG and 4 for every O APPLET of those being deleted it holds that i there is no instance in the context of O APPLET that is active in any logical channel and ii there is no O JAVAOBJECT owned by O APPLET such that either O JAVAOBJECT is reachable from an applet instance not being deleted or O JAVAOBJECT is reachable from a package not being deleted or 18 58 5 O JAVAOBJECT is remote reachable FDP ACF 1 3 ADEL The TSF shall explicitly authorise access of subjects to objects based on the following additional rules none FDP ACF 1 4 ADEL Editorially Refined The TSF shall explicitly deny access of any subject but S ADEL to
160. le 2 4 44 TOE Type The TOE type as stated in section 1 3 1 of this ST corresponds to the TOE type of the PP as stated in section 1 2 of 5 namely a Java Card platform implementing the java card specification version 3 0 1 2 4 2 SPD Statement The SPD statement is presented in chapter 3 includes the threats as presented in the PP 5 but also includes a number of additional threats These threats are e T OS_ OPERATE e T SEC_BOX_BORDER e T RND The treat T RND is taken from 6 This Protection Profile does not require formal compliance to a specific IC Protection Profile or a smart card OS Protection Profile but those IC and OS evaluated against 6 and 7 respectively fully meet the objectives By adding these threat the SPD is equivalent to the PP 5 The threats T OS OPERATE and T SEC BOX BORDER are introduced to formulate the threats concerned with the secure box which is identified as part of additional native code as defined in section 1 2 of the PP 5 These threats are thus related to additional functionality for which the PP offers the ability The SPD statement presented in chapter 3 copies the OSP from the PP 5 and adds OSP PROCESS TOE this OSP is introduced for the pre personalisation feature of the TOE which is additional functionality for which the certified PP 5 offers the ability The SPD statement includes two of the three Assumptions from the PP 5 The assumption A Deletion is excluded
161. leges that allow loading of selected programs Unauthorized programs if allowed to be loaded may include either the execution of legitimate programs not intended for use during normal operation such as patches filters Trojan horses etc or the unauthorized loading of programs specifically targeted at penetration or modification of the security functions Attempts to generate a non secure state in the Smart Card may also be made through premature termination of transactions or communications between the IC and the card reading device by insertion of interrupts or by selecting related applications that may leave files open An attacker may try to use malicious code placed in the Secure Box to modify the correct behavior of the NOS With the aim to 1 disclose the Java Card System code 2 disclose or alter Applet code disclose or alter Java Card System data or disclose or alter Applet data 3 3 1 4 Threat on Random Numbers The following threat was taken over from 6 Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 27 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC T RND Deficiency of Random Numbers An attacker may predict or obtain information about random numbers generated by the TOE for instance because of a lack of entropy of the random numbers provided An attac
162. lications and Java Card applets e For integrity sensitive application their data shall be monitored D APP DATA applications may need to protect information against unexpected modifications and explicitly control whether a piece of information has been changed between two accesses For example maintaining the integrity of an electronic purse s balance is extremely important because this value represents real money Its modification must be controlled for illegal ones would denote an important failure of the payment system Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 75 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC e A dedicated library could be implemented and made available to developers to achieve better security for specific objects following the same pattern that already exists in cryptographic APIs for instance 6 1 3 3 FPR_UNO 1 Unobservability FPR_UNO 1 1 The TSF shall ensure that assignment subjects S Package are unable to observe the operation assignment all operations on assignment secret keys and PIN codes by assignment other subjects S Package Application note Although it is not required in 18 specifications the non observability of operations on sensitive information such as keys appears as impossible to circumvent in the smart card
163. livery refer to Section 1 3 3 are assumed to be protected appropriately The assets to be protected are The information and material produced and or processed by the Security IC Embedded Software Developer in Phase 1 and by the Composite Product Manufacturer can be grouped as follows the Security IC Embedded Software including specifications implementation and related documentation pre personalisation and personalisation data including specifications of formats and memory areas test related data the User Data and related documentation and material for software development support as long as they are not under the control of the TOE Manufacturer Details must be defined in the Protection Profile or Security Target for the evaluation of the Security IC Embedded Software and or Security IC 3 6 Security Aspects This section is partly taken from 5 Security aspects are intended to define the main security issues that are to be addressed in the PP and this ST in a CC independent way In addition to this they also give a semi formal framework to express the CC security environment and objectives of the TOE They can be instantiated as assumptions threats objectives for the TOE and the environment or organizational security policies and are referenced in their definition For instance the security aspect NATIVE is instantiated in assumption A NATIVE and objectives OE NATIVE and the security aspect FIREWALL is ins
164. logy for Information Technology Security Evaluation Evaluation Methodology Version 3 1 Revision 4 September 2012 CCMB 2012 09 004 5 Java Card System Open Configuration Protection Profile Version 2 6 Certified by ANSSI the French Certification Body April 19th 2010 6 Smartcard IC Platform Protection Profile SSVG PP Version 1 0 June 2007 registered and certified by BSI under the reference BSI PP 0035 2007 7 Embedded Software for Smart Secure Devices Protection Profile v1 0 November 27th 2009 ANSSI 8 Anwendungshinweise und Interpretationen zum Schema AIS 20 Funktionalitaetsklassen und Evaluationsmethodologie fuer deterministische Zufallszahlengeneratoren Version 2 1 02 12 2011 Bundesamt fuer Sicherheit in der Informationstechnik 9 Crypto Library V2 7 2 9 on SmartMX P5Cx128 P5Cx145 VOv VOB s Security Target Lite Rev 1 5 08 May 2013 BSI DSZ CC 0750 10 NXP Secure Smart Card Controllers P5Cx128V0v P5Cx145V0v VOB s Security Target Lite Rev 2 1 16 November 2013 BSI DSZ CC 0858 11 NXP Secure Smartcard Controllers P5Cx128 P5Cx145 Guidance Delivery and Operation Manual NXP Semiconductors Business Unit Identification Rev 1 7 24 January 2013 Doc ID 185117 12 The Java Virtual Machine Specification Lindholm Yellin ISBN 0 201 43294 3 13 The Java Language Specification Gosling Joy and Steele ISBN 0 201 63451 1 14 GlobalPlatform Card Specification Version 2 2 1 January 2011
165. miconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC The set of SFRs that define the Secure Box realize additional security functionality making the security requirements statement equivalent to the PP 5 This set of SFRs comprise FDP_ACC 2 SecureBox FDP_ACF 1 SecureBox FMT MSA 3 SecureBox FMT MSA 1 SecureBox and FMT SMF 1 SecureBox The set of SFRs that are included because of inclusion of the Card Manager and a pre personalisation feature in the TOE add the following SFRs FDP_ACC 1 LifeCycle FDP ACF 1 LifeCycle FMT MSA 1 LifeCycle FMT MSA 3 LifeCycle FMT SMR 1 LifeCycle and FTP_ITC 1 LifeCycle The SFRs FIA_AFL 1 PIN FCS_RNG 1 FCS_RNG 1 RNG2 and FPT_EMSEC 1 add functionality to the TOE making the statement of security requirements more restrictive then the PP 5 3 Security problem definition ASE SPD 3 1 Introduction This chapter describes the security problem to be addressed by the TOE and the operational environment of the TOE The security problem is described by threats for the assets The assets are described in Section 3 2 whereas threats are described in section 3 3 Organisational Security Policies are given in Section 3 4 and the Assumptions are made in Section 3 5 Finally Section 3 6 defines some security aspects Security aspects are intended to define the main security issues that are to be addressed in the PP and this ST in a CC independent way They can be instantiated as assumptions thre
166. modifiers of the Java programming language 13 6 6 2 jumping inside a method fragment or interpreting the contents of a data memory area as if it was executable code 3 unauthorized execution of a remote method from the CAD Java Card System byte code must be protected against unauthorized execution Java Card System byte code includes any code of the JCRE or API This concerns 1 invoking a method outside the scope of the visibility rules provided by the public private access modifiers of the Java programming language 13 6 6 2 jumping inside a method fragment or interpreting the contents of a data memory area as if it was executable code Note that execute access to native code of the Java Card System and applications is the concern of NATIVE Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 33 of 135 NXP Semiconductors JCOP 2 4 2 H3 3 6 3 1 Security Target Lite PUBLIC FIREWALL The Java Card System shall ensure controlled sharing of class instances4 and isolation of their data and code between packages that is controlled execution contexts 1 An applet shall neither read write nor compare a piece of data belonging to an applet that is not in the same context nor execute one of the methods of an applet in another context without its authorization NATIVE Because
167. n Technology Security Evaluation Part 2 Version 3 1 Revision 4 September 2012 2 Common Criteria for Information Technology Security Evaluation Part 3 Version 3 1 Revision 4 September 2012 3 The following methodology will be used for the evaluation Common Methodology for Information Technology Security Evaluation Evaluation Methodology Version 3 1 Revision 4 September 2012 CCMB 2012 09 004 4 This Security Target claims to be CC Part 2 extended and CC Part 3 conformant The extended Security Functional Requirements are defined in Chapter 5 2 2 Package claim This Security Target claims conformance to the assurance package EAL5 augmented The augmentations to EAL5 ALC DVS 2 VAN 5 and ASE_TSS 2 2 3 PP claim This Security Target claims conformance to the Protection Profile PP Java Card System Open Configuration Protection Profile Version 2 6 Certified by ANSSI the French Certification Body April 19th 2010 5 Since the Security Target claims conformance to this PP 5 the concepts are used in the same sense The TOE provides additional functionality which is not covered in the PP 5 Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 20 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC 2 4 Conformance claim rationa
168. n is not protected against SCA and fault attacks FCS COP 1 1 RSASignaturelSO9796 The TSF shall perform assignment digital signature generation and verification in accordance with a specified cryptographic algorithm assignment RSA SignaturelSO9796 with SHA 1 SHA 256 38 and cryptographic key sizes assignment 1976 2048 Bit that meet the following assignment ISO IEC 9796 2 2002 24 Application Notes 1 The security functionality is resistant against side channel analysis and similar techniques To fend off attackers with high attack potential an adequate key length must be used references can be found in national and international documents and standards 2 Message recovery as defined in 24 is not supported 8 The input data for the encryption operation is not protected against SCA and fault attacks FCS COP 1 1 DHKeyExchange The TSF shall perform assignment Diffie Hellman key agreement in accordance with a specified cryptographic algorithm assignment ECC DH over GF p Diffie Hellman key exchange and cryptographic key sizes assignment EC 160 192 224 256 320 bits with the domain parameters provided in NIST DSS standard FIPS 186 3 42 Appendix D or in Brainpool ECC Standard Curves 34 chapters 3 1 to 3 5 1976 2048 BIT PKCS 3 that meet the following assignment for ECC DH ISO 11770 3 23 for PKCS 3 45 Application Note 1 The security functionality is resistant against side channe
169. n with Triple DES in CBC mode and cryptographic key size of 112 bit FIPS 46 3 20 as well as message authentication code with Retail MAC and cryptographic key size of 112 bit according to ISO 9797 1 25 or encryption and decryption with AES in CBC mode see FIPS 197 21 and message authentication wit AES CMAC NIST 800 38B both with cryptographic key sizes of 128 192 or 256 for details especially on the supported schemes and padding algorithms see 6 1 2 5 FCS_COP 1 AES and FCS COP 1 AES Diffie Hellman key agreement with ECC over GF p and RSA supporting cryptographic key sizes from 128 to 320 bit for ECC and from 512 to 2048 bit for RSA according to ISO 11770 3 23 for details especially on the supported schemes and padding algorithms see 6 1 2 5 FCS COP 1 DHKeyExchange Secure point addition in accordance with the specified cryptographic algorithm ECC over GF p and cryptographic key sizes 128 to 320 Bit according to 15014888 3 26 see 6 1 2 5 FCS_COP 1 ECAdd 12 Other secure messaging functionality is part of the SF COP DES and SF COP MAC Key destruction for ICAO functionality is part of SF CRK DST Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 120 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC SF COP AEC AES CMAC computation accordin
170. nce deletion must be atomic The secure state referred to in the requirement must comply with Java Card specification 18 11 3 4 Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 82 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC 6 1 7 RMIG Security Functional Requirements This group specifies the policies that control the access to the remote objects and the flow of information that takes place when the RMI service is used The rules relate mainly to the lifetime of the remote references Information concerning remote object references can be sent out of the card only if the corresponding remote object has been designated as exportable Array parameters of remote method invocations must be allocated on the card as global arrays Therefore the storage of references to those arrays must be restricted as well The JCRMI policy embodies both an access control and an information flow control policy 6 1 7 1 ACC 2 JCRMI Complete access control ACC 2 1 JCRMI The TSF shall enforce the JCRMI access control SFP on S CAD S JCRE O APPLET O REMOTE OBJ O REMOTE MTHD O ROR O RMI SERVICE and all operations among subjects and objects covered by the SFP Refinement The operations involved in this policy are e OP GET_ROR OP INVOKE FDP_ACC 2 2 JCRMI The TSF sh
171. nctionality of the hardware is used by the TOE to implement the Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 123 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC Secure Box see 6 1 15 1 FDP_ACC 2 SecureBox 6 1 15 2 FDP ACF 1 SecureBox 7 1 11 SF CryptoLib The certified cryptographic library part of the TOE features the following TSF The exact formulation can be found in the crypto library security target 9 SF GYL SDE Software DES F DES based on SF HW DES used for SF COP DES SF COP MAC SF COP SMI and SF COP TDC see 6 1 2 5 1 TripleDES FCS COP 1 DESMAC SF CYL ECS ECC Signature Generation and Signature Verification GF p ECDSA used for SF COP ESI see 6 1 2 5 FCS COP 1 ECSignature SF CYL DHK Diffie Hellman Key Exchange GF p DH KeyExch used for SF COP DHK see 6 1 2 5 FCS COP 1 DHKeyExchange SF CYL EKG Key Generation GF p KeyGen used for SF CRK GEC see 6 1 2 1 FCS_CKM 1 according to ISO IEC 15946 1 16 and 48 SF CYL CSH Compute the Secure Hash Algorithms F SHA used for SF COP HS1 SF COP HS2 and SF COP HS5 see 6 1 2 5 FCS COP 1 SHA 1 6 1 2 5 FCS _COP 1 SHA 224 6 1 2 5 FCS COP 1 SHA 256 SF CYL CMA Clear memory areas used by the Crypto Library after usage F Object Reuse is used f
172. nd Permanent ones As part of the firewall functionality the JCRE detects and restricts attempts to store references to these objects Java Card Remote Method Invocation is the Java Card System version 2 2 2 mechanism enabling a client application running on the CAD platform to invoke a method on a remote object on the card Notice that in Java Card Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 5 of 135 NXP Semiconductors JCOP 2 4 2 R3 Java Card System JCVM Logical channel MMU NOS OT xxx Object deletion OE xxx OSP xxx Package SCP PP RAM RMI ROM RTE SC SF xxx All information provided in this document is subject to legal disclaimers Security Target Lite PUBLIC System version 2 1 1 the only method that may be invoked from the CAD is the process method of the applet class The Java Card System the JCRE JCVM the installer and the on card BCV if the configuration includes one The embedded interpreter of bytecodes The JCVM is the component that enforces separation between applications firewall and enables secure data sharing A logical link to an application on the card A new feature of the Java Card System version 2 2 2 that enables the opening of up to four simultaneous sessions with the card one per logical channel Commands issued t
173. ng access to assignment list of types of TSF data and assignment list of types of user data FPT EMSEC 1 2 The TSF shall ensure assignment type of users are unable to use the following interface assignment type of connection to gain access to assignment list of types of TSF data and assignment list of types of user data Dependencies No other components Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 53 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC 5 3 Definition of Family FAU SAS This section has been taken over from the certified BSI PP 0035 Smartcard IC Platform Protection profile 6 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 the functional requirements for the storage of audit data It has a more general approach than FAU GEN because it does not necessarily require the data to be generated by the TOE itself and because it does not give specific details of the content of the audit records Family behavior This family defines functional requirements for the storage of audit data Component leveling FAU SAS Audit data storage 1 FAU SAS 1 Requires the TOE to provide the possibility to store audit dat
174. nnel analysis and similar techniques To fend off attackers with high attack potential an adequate key length must be used references can be found in national and international documents and standards 2 The CBC mode is to be understood as outer CBC mode i e CBC mode as defined in 36 and 40 applied to the block cipher algorithm FCS COP 1 1 RSACipher The TSF shall perform assignment data encryption and decryption in accordance with a specified cryptographic algorithm assignment RSA encryption decryption algorithm without or with EME PKCS1 v1 5 encoding and cryptographic key sizes assignment 1976 2048 bits that meet the following assignment PKCS 1 v2 1 22 Section 7 2 RSAES PKCS1 v1 5 ENCRYPT RSAES PKCS1 v1 5 DECRYPT and Section 5 1 RSAEP RSADP Application Notes 1 The security functionality is resistant against side channel analysis and similar techniques To fend off attackers with high attack potential an adequate key length must be used references can be found in national and international documents and standards 2 The input data for the encryption operation is not protected against SCA and fault attacks FCS COP 1 1 RSASignaturePKCS 1 The TSF shall perform assignment digital signature generation and verification in accordance with a specified cryptographic algorithm assignment RSA signature algorithm with EMSA PKCS1 v1 5 encoding and SHA 1 and SHA 256 38 and cryptographic key sizes
175. nstaller Failure with preservation of SOCUIE Sale seiner e 78 FPT ROV 3 Installer Automated recovery without undue loss eeeeenenee 79 ADELG Security Functional Requirements 79 FDP ACC 2 ADEL Complete access control 79 FDP ACF 1 ADEL Security attribute based access control sssssssssssseneee 79 FDP RIP 1 ADEL Subset residual information Protect nennen 81 FMT MSA 1 ADEL Management of security ail IDUEeS TEE 82 FMT_MSA 3 ADEL Static attribute initialization82 FMT SMF 1 ADEL Specification of Management FUNCIONS m 82 FMT SMR 1 ADEL Security roles 82 FPT FLS 1 ADEL Failure with preservation of Secure stale netter trino 82 RMIG Security Functional Requirements 83 ACC 2 JCRMI Complete access control 83 FDP ACF 1 JCRMI Security attribute based access CONT Ol sid E 83 ODELG Security Functional Requirements 84 RIP 1 ODEL Subset residual information PFOLSCHON e 84 FPT FLS 1 ODEL Failure with preservation of Secure State ennerien eainiie neia 84 CARG Security Functional Requirements 84 FCO_NRO 2 CM Enforced proof of origin 84 FDP_IFC 2 CM Complete information flow rene 85 IFF 1 CM Simple security attributes 85 FDP UIT 1 CM Data exchange integrity 86 FIA UID 1 CM Timing of identification
176. nsumption of resources during installation and other card management operations are covered in case of failure by OT INSTALL It should be noticed that for what relates to CPU usage the Java Card platform is singlethreaded and it is possible for an ill formed application either native or not to monopolize the CPU However a smart card can be physically interrupted card removal or hardware reset and most CADs implement a timeout policy that prevent them from being blocked should a card fails to answer That point is out of scope of this Protection Profile though Finally the objectives OT SCP RECOVERY and OT SCP SUPPORT are intended to support the OT OPERATE and OT RESOURCES objectives of the TOE so they are indirectly related to the threats that these latter objectives contribute to counter Card Management T DELETION This threat is covered by the OT DELETION security objective which ensures that both applet and package deletion perform as expected The objective OT CARD MANAGEMENT controls the access to card management functions and thus contributes to cover this threat T INSTALL This threat is covered by the security objective OT INSTALL which ensures that the installation of an applet performs as expected and the security objectives OT LOAD which ensures that the loading of a package into the card is safe The objective OT CARD MANAGEMENT controls the access to card management functions and thus contributes to cover this threat Se
177. nter applet communication e JCRE entry points Temporary or Permanent who have freely accessible methods but protected fields e Global arrays having both unprotected fields including components refer to JavaCardClass discussion above and methods When a new object is created it is associated with the Currently Active Context But the object is owned by the applet instance within the Currently Active Context when the object is instantiated 18 86 1 3 An object is owned by an applet instance by the JCRE or by the package library where it has been defined these latter objects can only be arrays that initialize static fields of packages 18 Glossary Selected Applet Context The Java Card RE keeps track of the currently selected Java Card applet Upon receiving a SELECT command with this applet s AID the Java Card RE makes this applet the Selected Applet Context The Java Card RE sends all APDU commands to the Selected Applet Context While the expression Selected Applet Context refers to a specific installed applet the relevant aspect to the policy is the context package AID of the selected applet In this policy the Selected Applet Context is the AID of the selected package Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 62 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Targe
178. nter physical manipulation and physical probing Due to the nature of these attacks especially manipulation the TOE can by no means detect attacks on all of its elements Therefore permanent protection against these attacks is required ensuring that the TSP could not be violated at any time Hence automatic response means here i assuming that there might be an attack at any time and ii countermeasures are provided at any time 6 1 12 4 ACC 1 SCP Subset Access Control This functional requirement has been taken over from the ST of the certified hardware platform P5CD145VOB that is conformant to 6 FDP ACC 1 1 SCP The TSF shall enforce the assignment Access Control Policy on assignment all code running on the TOE all memories and all memory operations Application note The Access Control Policy shall be enforced by implementing a MMU which maps virtual addresses to physical addresses The CPU always uses virtual addresses which are mapped to physical addresses by the MMU Prior to accessing the respective memory address the MMU checks if the access is allowed 6 1 12 5 ACF 1 SCP Security Attribute based Access Control This functional requirement has been taken over from the ST of the certified hardware platform P5CD145VOB that is conformant to 6 FDP ACF 1 1 SCP The TSF shall enforce the assignment Access Control Policy to objects based on the following assignment all subjects and objects and
179. ntrolled by the TSF and any object controlled by the TSF are covered by an access control SFP 6 1 6 2 ACF 1 ADEL Security attribute based access control Approved FDP ACF 1 1 ADEL The TSF shall enforce the ADEL access control SFP to objects based on the following All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 79 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC Table 22 Security Attributes Subject Object Security attributes S JCVM Active Applets S JCRE Selected Applet Context Registered Applets Resident Packages O CODE PKG Package AID Dependent Package AID Static References O APPLET Applet Selection Status O JAVAOBJECT Owner Remote FDP ACF 1 2 ADEL The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed In the context of this policy an object O is reachable if and only one of the following conditions hold 1 the owner of O is a registered applet instance A O is reachable from A 2 a static field of a resident package P contains a reference to O O is reachable from P 3 there exists a valid remote reference to O O is remote reachable 4 there exists an object O that is reachable according to either 1 or 2 or 3 above and O contains a reference to O the reachab
180. o a specific logical channel are forwarded to the active applet on that logical channel Memory management unit Native Operating System For this ST NOS means the TOE without the underlying hardware platform i e NOS is equivalent to the smart card embedded software Security objectives for the TOE The Java Card System version 2 2 2 mechanism ensures that any unreferenced persistent transient object owned by the current context is deleted The associated memory space is recovered for reuse prior to the next card reset Security objectives for the environment Organizational security policies A package is a name space within the Java programming language that may contain classes and interfaces A package defines either a user library or one or more applet definitions A package is divided in two sets of files export files which exclusively contain the public interface information for an entire package of classes for external linking purposes export files are not used directly in a Java Card virtual machine and CAP files Smart card platform It is comprised of the integrated circuit the operating system and the dedicated software of the smart card Protection Profile Random Access Memory Remote Method Invocation Read Only Memory Runtime Environment Smart Card Security function NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 6 of 135 NXP Semiconductors J
181. o an IT security function rather than to a user of the CC terminology The Java Card RE does not identify itself to the TOE but it is part of it 6 1 4 3 USB 1 AID User Subject Binding FIA USB 1 1 AID The TSF shall associate the following user security attributes with subjects acting on the behalf of that user Package AID FIA USB 1 2 AID The TSF shall enforce the following rules on the initial association of user security attributes with subjects acting on the behalf of users assignment rules defined in FDP ACF 1 1 FIREWALL FMT MSA 2 1 FIREWALL JCVM and FMT MSA 3 1 FIREWALL and corresponding application notes FIA USB 1 3 AID The TSF shall enforce the following rules governing changes to the user security attributes associated with subjects acting on the behalf of users assignment rules defined in FMT MSA 1 1 JCRE Application note The user is the applet and the subject is the S PACKAGE The subject security attribute Context shall hold the user security attribute package AID Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 77 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC 6 1 4 4 FMT MTD 1 JCRE Management of TSF Data FMT_MTD 1 1 JCRE The TSF shall restrict the ability to modify the list of registered applets AIDs to the JCRE 6 1 4 5 FM
182. o enforce the SFP FMT_MSA 3 2 LifeCycle The TSF shall allow the assignment no roles to specify alternative initial values to override the default values when an object or information is created 6 1 14 Further Functional Requirements 6 1 14 1 FIA_AFL 1 PIN Basic Authentication Failure Handling FIA_AFL 1 1 PIN The TSF shall detect when selection an administrator configurable positive integer within 1 and 127 unsuccessful authentication attempts occur related to assignment any user authentication using D PIN FIA_AFL 1 2 PIN When the defined number of unsuccessful authentication attempts has been surpassed the TSF shall assignment block the authentication with D PIN Note The dependency with FIA_UAU 1 is not applicable The TOE implements the firewall access control SFP based on which access to the object implementing FIA_AFL 1 PIN is organized 6 1 14 2 FTP ITC 1 LifeCycle Inter TSF Trusted Channel FTP_ITC 1 1 LifeCycle The TSF shall provide a communication channel between itself and another trusted IT product that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure FTP_ITC 1 2 LifeCycle The TSF shall permit assignment another trusted IT product to initiate communication via the trusted channel FTP_ITC 1 3 LifeCycle The TSF shall initiate communication via the trusted channel
183. of security attributes FMT MSA 1 1 ADEL The TSF shall enforce the ADEL access control SFP to restrict the ability to modify the security attributes Registered Applets and Resident Packages to the Java Card RE 6 1 6 5 FMT MSA 3 ADEL Static attribute initialization FMT MSA 3 1 ADEL The TSF shall enforce the ADEL access control SFP to provide restrictive default values for security attributes that are used to enforce the SFP FMT MSA 3 2 ADEL The TSF shall allow the following role s none to specify alternative initial values to override the default values when an object or information is created 6 1 6 6 FMT SMF 1 ADEL Specification of Management Functions FMT SMF 1 1 ADEL The TSF shall be capable of performing the following management functions modify the list of registered applets AIDs and the Resident Packages 6 1 6 7 FMT SMR 1 ADEL Security roles FMT SMR 1 1 ADEL The TSF shall maintain the roles applet deletion manager FMT SMR 1 2 ADEL The TSF shall be able to associate users with roles 6 1 6 8 FPT FLS 1 ADEL Failure with preservation of secure state FPT FLS 1 1 ADEL The TSF shall preserve a secure state when the following types of failures occur the applet deletion manager fails to delete a package applet as described in 18 11 3 4 Application note e The TOE may provide additional feedback information to the card manager in case of a potential security violation see FAU_ARP 1 e The Package applet insta
184. of the applets to use them Keys PIN s are particular cases of an application s sensitive data the Java Card System may possess keys as well that ask for appropriate management OT KEY MNGT OT PIN MNGT OT TRANSACTION If the PIN class of the Java Card API is used the objective OT FIREWALL shall contribute in covering this threat by controlling the sharing of the global PIN between the applets Other application data that is sent to the applet as clear text arrives to the APDU buffer which is a resource shared by all applications The disclosure of such data is prevented by the security objective OT GLOBAL ARRAYS CONFID Furthermore any attempt to read a piece of information that was previously used by an application but has been logically deleted is countered by the OT REALLOCATION objective That objective states that any information that was formerly stored in a memory block shall be cleared before the block is reused Finally the objective OT EXT MEM provides access control for external memory and therefore also contributes to counter this threat T CONFID JCS CODE This threat is countered by the list of properties described in the 4 VERIFICATION security aspect Bytecode verification ensures that each of the instructions used on the Java Card platform is used for its intended purpose and in the intended scope of accessibility As none of those instructions enables reading a piece of code no Java Card applet can therefore be executed to
185. of the hardware and the cryptographic library Table 2 gives the details of the underlying evaluations of the cryptographic library and the underlying hardware platforms The hardware is compliant to the protection profile Smartcard IC Platform Protection Profile SSVG PP Version 1 0 June 2007 registered and certified by BSI under the reference BSI PP 0035 2007 6 Table 2 Underlying evaluations Cert ID Name Reference BSI DSZ CC 0750 BSI DSZ CC 0858 Crypto Library V2 7 2 9 on SmartMX P5Cx128 P5Cx145 VOv VOB s Security Target Lite Rev 1 5 08 May 2013 9 BSI DSZ CC 0750 NXP Secure Smart Card Controllers P5Cx128VOv 10 P5Cx145V0v VOB s Security Target Lite Rev 2 1 16 10 All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 8 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC Cert ID Name Reference November 2013 BSI DSZ CC 0858 For the P5CD145V0B hardware of this TOE three minor configuration options can be freely chosen during Smartcard IC Personalization see section 2 2 5 of the Hardware Security Target 10 e MIFARE Emulation A in which MIFARE interface is disabled e MIFARE Emulation B1 in which MIFARE interface is enabled and 1KB MIFARE EEPROM memory is reserved e MIFARE Emulation B4 in which MIFARE interface is enabl
186. on of cryptographic keys Note In the present case a certified hardware platform is used see chapter 2 TRANSACTION The TOE must provide a means to execute a set of operations atomically This mechanism must not endanger the execution of the user applications The transaction status at the beginning of an applet session must be closed no pending updates 4 Security objectives for the TOE The Security Objectives for the TOE are summarized in the following table Table 10 Security Objectives for the TOE Name Source Refined OT SEC BOX FW OT IDENTIFICATION OT SID 5 no OT FIREWALL 5 no OT GLOBAL ARRAYS CONFID 5 no OT GLOBAL ARRAYS INTEG 5 no OT NATIVE 5 no OT OPERATE 5 no OT REALLOCATION 5 no OT RESOURCES 5 no OT ALARM 5 no OT CIPHER 5 no OT KEY MNGT 5 no OT PIN MNGT 5 no Approved All information provided in this document is subject to legal disclaimers B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 38 of 135 NXP Semiconductors JCOP 2 4 2 R3 Approved Security Target Lite PUBLIC Name OT REMOTE OT TRANSACTION OT OBJ DELETION OT DELETION OT LOAD OT INSTALL OT CARD MANAGEMENT OT SCP IC OT SCP RECOVERY OT SCP SUPPORT OT EXT MEM OT RND OT MF FW Source 5 5 5 5 5 5 5 5 5 5 5 6 10 Refined no no no no no no no These Security Objectives f
187. ons which may not be tolerated according to the requirement Limited fault tolerance FRU FLT 2 SCP and where therefore a malfunction could occur 6 1 12 2 FRU FLT 2 SCP Limited Fault Tolerance This functional requirement has been taken over from the ST of the certified hardware platform P5CD145VOB that is conformant to 6 FRU FLT 2 1 SCP The TSF shall ensure the operation of all the TOE capabilities when the following failures occur assignment exposure to operating conditions which may not be tolerated according to the requirement Failure with preservation of a secure state FPT FLS 1 SCP Refinement The term failure above means circumstances The TOE prevents failures for the circumstances defined above 6 1 12 3 PHP 3 SCP Resistance to Physical Attack Approved This functional requirement has been taken over from the ST of the certified hardware platform P5CD145VOB that is conformant to 6 FPT PHP 3 1 SCP The TSF shall resist assignment physical manipulation and physical probing to the assignment TSF by responding automatically such that the SFRs are always enforced All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 89 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC Refinement The TOE will implement appropriate measures to continuously cou
188. or SF CYL SDE SF CYL ECS SF CYL DHK and SF CYL_EKG see 6 1 2 9 FDP_RIP 1 Keys SF CYL_LOG Logical Protection F LOG extends F LOG of the Hardware and is used for SF CYL_SDE SF CYL_ECS SF CYL_DHK SF CYL_EKG SF CYL CSH and SF CYL MCP see 6 1 14 6 FPT_EMSEC 1 and 6 1 12 1 FPT_FLS 1 SCP Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 124 of 135 NXP Semiconductors JCOP 2 4 2 H3 7 2 7 3 Approved Security Target Lite PUBLIC SF CYL ECC Point addition FCS_COP 1 ECC_ADD in F ECC_GF_p_ ECDSA used for SF COP_SPA see 6 1 2 5 FCS COP 1 ECAdd Logical Protection The following chapter gives a short overview of the logical protection mechanisms implemented in the OS Applet firewall The applet firewall is used to separate the different applications and their data from each other and from the Java Card OS MMU The hardware based Memory Management Unit is used to separate native code which is executed as a library inside the Secure Box feature from the OS It limits and controls the access of this native code to all recourses ROM RAM non volatile memory and SFRs of the hardware Transaction Mechanism This mechanism ensures that in case of a tearing event sudden loss of power the operating system as well as the executing applet is kept in a consistent state This means t
189. or in applications where failure or malfunction of an NXP Semiconductors product can reasonably be expected to result in personal injury death or severe property or environmental damage NXP Semiconductors accepts no liability for inclusion and or use of NXP Semiconductors products in such equipment or applications and therefore such inclusion and or use is at the customer s own risk Applications Applications that are described herein for any of these products are for illustrative purposes only NXP Semiconductors makes no representation or warranty that such applications will be suitable for the specified use without further testing or modification Customers are responsible for the design and operation of their applications and products using NXP Semiconductors products and NXP Semiconductors accepts no liability for any assistance with applications or customer product design It is customer s sole responsibility to determine whether the NXP Semiconductors product is suitable and fit for the Approved customer s applications and products planned as well as for the planned application and use of customer s third party customer s Customers should provide appropriate design and operating safeguards to minimize the risks associated with their applications and products NXP Semiconductors does not accept any liability related to any default damage costs or problem which is based on any weakness or default in the customer s applications
190. or products or the application or use by customer s third party customer s Customer is responsible for doing all necessary testing for the customer s applications and products using NXP Semiconductors products in order to avoid a default of the applications and the products or of the application or use by customer s third party customer s NXP does not accept any liability in this respect Export control This document as well as the item s described herein may be subject to export control regulations Export might require a prior authorization from national authorities 9 3 Licenses ICs with DPA Countermeasures functionality NXP ICs containing functionality implementing countermeasures to Differential Power Analysis and Simple Power Analysis are produced and sold under applicable license from Cryptography Research Inc LICENSED DPA COUNTERMEASURES All information provided in this document is subject to legal disclaimers 9 4 Patents Notice is herewith given that the subject device uses one or more of the following patents and that each of these patents may have corresponding patents in other jurisdictions Patent ID owned by Company name gt 9 5 Trademarks Notice All referenced brands product names service names and trademarks are property of their respective owners Name is a trademark of NXP B V NXP B V 2013 All rights reserved Evaluation documentation Rev 00
191. or the environment of 5 are Security Objectives for the TOE in the present evaluation Therefore the label changed OT XYZ instead of OE XYZ but not the content no refinement Security Objectives for the TOE not contained in 5 The security objectives of the TOE must cover the following aspects e Maintain the integrity of User Data and of the Smart Card Native Operating System when being executed processed and when being stored in the TOE s memories and e Maintain the confidentiality of User Data and of the Smart Card Native Operating System when being processed and when being stored in the TOE s memories as well as e Provide access control to execution of the TOE code e Ensure correct operation of the code and maintain the TOE in a secure state OT SEC BOX FW OT IDENTIFICATION OT MF_FW All information provided in this document is subject to legal disclaimers The TOE shall provide separation between the Secure Box native code and the Java Card System The separation shall comprise software execution and data access The TOE must provide means to store Initialization Data and Pre personalization Data in its non volatile memory The Initialization Data or parts of them are used for TOE identification The TOE shall provide separation between the MIFARE Operating System IC Dedicated Support Software and the NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd
192. ory reclamation incl compactification b Support for Extended Length APDUs GlobalPlatform 2 2 1 functionality a CVM Management Global PIN fully implemented all described APDU and API interfaces for this feature are present b Secure Channel Protocol SCP01 SCP02 and SCP03 is supported c Card manager d Delegated management Proprietary SM Accelerator Interface secure massaging API of JCOP 2 4 2 R3 The purpose of this API is to increase the performance of the secure messaging It is specially designed for LDS applets which are used for the electronic passport as defined by ICAO Post issuance installation and deletion of applets packages and objects Pre personalization mechanism A Secure Box concept is implemented within JCOP 2 4 2 R3 The Secure Box is a construct which allows to run non certified third party native code and ensures that this code cannot harm influence or manipulate the JCOP 2 4 2 R3 operating system or any of the applets executed by the operating system The separation of the native All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 11 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC code in the Secure Box from other code and or data residing on the hardware is ensured by the Hardware MMU which has been certified in the hardware evaluation see 10
193. plet instance that created the object or the package library where it has been defined these latter objects can only be arrays that initialize static fields of the package The owner of a remote object is the applet instance that created the object The AID of each package indicated in the export file The set of AID of the applet instances registered on the card An object is Remote if it is an instance of a class that directly or indirectly implements the interface java rmi Remote The set of AIDs of the packages already loaded on the card The set of remote object references that have been sent to the CAD during the applet selection session Package AID or None Standards SIO Java Card RE entry point or global array Static fields of a package may contain references to objects The Static References attribute records those references Accessible memory portion Operations prefixed with OP are described in the following table Each operation has parameters given between brackets among which there is the accessed object the first one when applicable Parameters may be seen as security attributes that are under the control of the subject performing the operation Table 19 Operation Descriptions Operation Description OP ARRAY ACCESS O JAVAOBJECT Read Write an array component field Transient objects of type CLEAR ON RESET behave like persistent objects in that they can be accessed only w
194. provide restrictive default values for security attributes that are used to enforce the SFP FMT MSA 3 2 FIREWALL Editorially Refined The TSF shall not allow any role to specify alternative initial values to override the default values when an object or information is created Application note FMT MSA 3 1 FIREWALL e Objects security attributes of the access control policy are created and initialized at the creation of the object or the subject Afterwards these attributes are no longer mutable FMT MSA 1 JCRE At the creation of an object OP CREATE the newly created object assuming that the FIREWALL access control SFP permits the operation gets its Lifetime and Sharing attributes from the parameters of the operation on the contrary its Context attribute has a default value which is its creator s Context attribute and AID respectively 18 86 1 3 There is one default value for the Selected Applet Context that is the default applet identifier s Context and one default value for the Currently Active Context that is Java Card RE e The knowledge of which reference corresponds to a temporary entry point object or a global array and which does not is solely available to the Java Card RE and the Java Card virtual machine FMT MSA 3 2 FIREWALL e The intent is that none of the identified roles has privileges with regard to the default values of the security attributes It should be noticed that creation of objects is an oper
195. ptoOperation except with SHA are resistant to side channel attacks e g timing attack SPA DPA DFA EMA DEMA see 6 1 14 6 FPT EMSEC 1 SF SMG CAP CAP files the bytecode and its data arguments are consistently interpreted using the following rules see 6 1 3 5 FPT_TDC 1 a The virtual machine specification 19 b Reference export files c The ISO 7816 6 rules d The EMV specification SF SMG SSI The TSF ensures a secure state when the installer fails to install or load a package or applet see 6 1 5 3 FPT_FLS 1 Installer 6 1 5 4 FPT_RCV 3 Installer SF SMG_AOD The TSF ensures a secure state when the applet or object deletion fails see 6 1 6 8 FPT_FLS 1 ADEL 6 1 8 2 FPT_FLS 1 ODEL 7 1 7 SF PIN The TSF provides the following functionality with respect to user authentication with the global PIN D PIN SF PIN NUP The maximum possible number of consecutive unsuccessful PIN authentication attempts is user configurable number from 1 to 127 see 6 1 14 1 FIA_AFL 1 PIN SF PIN PAB When this number has been met or surpassed the PIN authentication is blocked F A AFL 1 PIN SF PIN CBI Only the following commands are allowed before successful identification see 6 1 9 5 FIA_UID 1 CM Get Data with objects ISD DATA ISSUER IDENTIFICATION NUMBER ISD DATA CARD IMAGE NUMBER PLATFORM DATA CARD RECOGNITION DATA ISD DATA KEY INFORMATION TEMPLATE ISD DATA SCP INFORMATION PLATFORM DATA MANUFACTURING
196. r FPT FLS 1 FPT FLS 1 ADEL FPT FLS 1 ODEL which guarantee that a secure state is preserved by the TSF when failures occur and FAU_ARP 1 which defines TSF reaction upon detection of a potential security violation OT CIPHER This security objective is directly covered by FCS CKM 1 FCS CKM 2 FCS CKM 3 FCS CKM 4 and FCS COP 1 The SFR FPR UNO 1 contributes in covering this security objective and controls the observation of the cryptographic operations which may be used to disclose the keys It is supported by FRU FLT 2 SCP by preserving a secure state in case of operating conditions which may not be tolerated OT KEY MNGT This relies on the same security functional requirements as O CIPHER plus FDP_RIP 1 and FDP SDI 2 as well Precisely it is met by the following components FCS_CKM 1 FCS CKM 2 FCS_CKM 3 FCS CKM 4 FCS COP 1 FPR UNO 1 FDP RIP 1 ODEL FDP RIP 1 OBJECTS FDP RIP 1 APDU RIP 1 bArray FDP RIP 1 ABORT RIP 1 KEYS FDP RIP 1 ADEL and FDP RIP 1 TRANSIENT OT PIN MNGT This security objective is ensured by FDP RIP 1 ODEL RIP 1 OBJECTS RIP 1 APDU RIP 1 bArray FDP RIP 1 ABORT FDP RIP 1 KEYS FDP RIP 1 ADEL FDP RIP 1 TRANSIENT FPR UNO 1 FDP ROL 1 FIREWALL and FDP SDI 2 security functional requirements The TSFs behind these are implemented by API classes The firewall security functions FDP ACC 2 FIREWALL FDP ACF 1 FIREWALL shall protect the access to private and internal data of
197. r is the software component performing a static analysis of the code to be loaded on the card It checks several kinds of properties like the correct format of CAP files and the enforcement of the typing rules associated to bytecodes If the component is placed outside the card ina secure environment then it is called an off card verifier If the component is part of the embedded software of the card it is called an on card verifier BSI Bundesamt f r Sicherheit in der Informationstechnik German national certification body Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 3 of 135 NXP Semiconductors JCOP 2 4 2 R3 Approved CAD CAP file CC Class CM Context Current context Currently selected applet Security Target Lite PUBLIC Card Acceptance Device or card reader The device where the card is inserted and which is used to communicate with the card A file in the Converted applet format A CAP file contains a binary representation of a package of classes that can be installed on a device and used to execute the package s classes on a Java Card virtual machine A CAP file can contain a user library or the code of one or more applets Common Criteria In object oriented programming languages a class is a prototype for an object A class may also be considered as a s
198. rance component ASE TSS 1 This ensures that The TOE summary specification describes how the TOE meets each SFR The component ASE TSS 2 requires additionally that the TOE summary specification describes how the TOE protects itself against interference and logical tampering and how the TOE protects itself against bypass e AVA VAN 5 Advanced methodical vulnerability analysis EAL5 requires for the vulnerability assessment the assurance component AVA VAN 4 Its aim is to determine whether the TOE in its intended environment has vulnerabilities exploitable by attackers processing moderate attack potential In order to provide the necessary level of protection EAL5 is augmented with the component AVA VAN 5 which requires that the TOE is resistant against attackers processing high attack potential 6 3 Security Requirements Rationale 6 3 1 This section proves that the given security requirements TOE and environment cover the security objectives described in Section 4 Security Functional Requirements Rationale for SFRs tables All security objectives of the TOE are met by the security functional requirements At least one security objective exists for each security functional requirement Table 25 Assignment Security Objectives for the TOE Security Requirements 1 OT SID OT FIREWALL P 1 ABORT P 1 APDU P 1 bArray P 1 KEYS P 1 TRANSIENT FDP ROL 1 FIREWALL FMT MSA 1 JCVM FDP SDI 2 FMT MSA 2 FIREWALL JC
199. rd Platform SCP consists of the Hardware Abstraction Layer HAL and the Hardware Platform The cryptographic library Crypto Library is part of the Hardware Abstraction Layer HAL Not all functionality of the Crypto Library is used by the Embedded Software this unused functionality is not linked with the code and is therefore not part of the HAL All functions in the HAL are used by the TOE Not all functionality of the Hardware Platform is used for the TOE functionality and exposed at external interfaces Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 9 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC x I l MIFARE TOE Fig 1 JCOP Architecture The Java Card virtual machine JCVM is responsible for ensuring language level security the JCRE provides additional security features for Java Card technology enabled devices The basic runtime security feature imposed by the JCRE enforces isolation of applets using an applet firewall It prevents objects created by one applet from being used by another applet without explicit sharing This prevents unauthorized access to the fields and methods of class instances as well as the length and contents of arrays The applet firewall is considered as the most important security f
200. rd System Moreover the locking should occur when clean re initialization seems to be impossible e The locking may be implemented at the level of the Java Card System as a denial of service through some systematic fatal error message or return value that lasts up to the next RESET event without affecting other components of the card such as the card manager Finally because the installation of applets is a sensitive process security alertsin this case should also be carefully considered herein 6 1 3 2 FDP SDI 2 Stored Data Integrity Monitoring and Action FDP SDI 2 1 The TSF shall monitor user data stored in containers controlled by the TSF for assignment integrity errors on all objects based on the following attributes assignment D APP CODE D APP I DATA D PIN D APP KEYs FDP SDI 2 2 Upon detection of a data integrity error the TSF shall assignment maintain a secure state and return an error message Application note e Although no such requirement is mandatory in the Java Card specification at least an exception shall be raised upon integrity errors detection on cryptographic keys PIN values and their associated security attributes Even if all the objects cannot be monitored cryptographic keys and PIN objects shall be considered with particular attention by ST authors as they play a key role in the overall security It is also recommended to monitor integrity errors in the code of the native app
201. rding to ISO 9797 1 25 for details especially on the supported schemes and padding algorithms see 6 1 2 5 FCS COP 1 DESMAC 16 byte MAC generation and verification with AES in CBC Mode and cryptographic key size of 128 Bit according to ISO 9797 1 25 for details especially on the supported schemes and padding algorithms see 6 1 2 5 FCS COP 1 AESMAC Data encryption and decryption with AES in ECB CBC Mode and cryptographic key sizes of 128 192 and 256 Bit that meets FIPS 197 21 for details especially on the supported schemes and padding algorithms see 6 1 2 5 FCS COP 1 AES RSA digital signature generation and verification with SHA 1 and SHA 256 as hash function and cryptographic key sizes from 1976 to 2048 Bit according to ISO 9796 2 24 for details especially on the supported schemes and padding algorithms see 6 1 2 5 FCS COP 1 RSASignaturelSO9796 RSA digital signature generation and verification with SHA 1 and SHA 256 as hash function and cryptographic key sizes from 512 to 2048 Bit according to PKCS 1 22 for details especially on the All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 119 of 135 NXP Semiconductors JCOP 2 4 2 R3 SF COP RSS SF COP HS1 SF COP RNG SF COP RNG2 SF COP ESI SF COP HS2 SF COP HS5 SF COP SMI SF COP DHK SF COP SPA Security T
202. re used to enforce the SFP FMT MSA 3 2 SCP The TSF shall allow assignment no subject to specify alternative initial values to override the default values when an object or information is created Application note Restrictive means here that the reset values of the Special Function Register regarding the address of the MMU Segment Table are set to zero which effectively disables any memory segment so that no User Mode code can be executed by the CPU Furthermore the memory partition cannot be configured at all The TOE does not provide objects or information that can be created since it provides access to memory areas The definition of objects that are stored in the TOE s memory is subject to the Smartcard Embedded Software LifeCycle Security Functional Requirements This group contains the security requirements for life cycle control mechanism For this evaluation the life cycle management belongs to the TOE and the functional requirements are stated here as functional requirements for the TOE Beside the global All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 91 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC platform life cycle states defined in 14 Section 5 1 the systems has an OS Internal Life Cycle which defines the following states no specific state FUSED and PROTECTED
203. rget Lite PUBLIC The TOE development and manufacturing environment phases 1 to 3 is in the scope of this ST These phases are under the TOE developer scope of control Therefore the objectives for the environment related to phase 1 to 3 are covered by Assurance measures which are materialized by documents process and procedures evaluated through the TOE evaluation process The product usage phases phase 4 to 7 are not in the scope of the evaluation During these phases the TOE is no more under the developer control In this environment the TOE protects itself with its own Security functions But some additional usage recommendation must also be followed in order to ensure that the TOE is correctly and securely handled and that shall be not damaged or compromised This ST assumes A USE DIAG A USE KEYS that users handle securely the TOE and related Objectives for the environment are defined OE USE DIAG OE USE KEYS Protection during composite product manufacturing Security procedures shall be used after TOE Delivery 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 This means that Phases after TOE Delivery up to the end of Phase 6 refer to Section 1 3 3 must be protected appropriately Security Objectives for the operational environment from 5 OE APPLET OE V
204. riables need to have defined settings These settings are given in Table 6 Table 6 Products commercial names Variable Must have one of these values details see Table 7 a 2 3 b E ccc 145 120 82 X Depends on the application of possible applets in ROM A letter can be chosen e g V for Visa dd These 2 letters indicate the package All package types which are covered by the certification of the used hardware are allowed For the list of certified packages please refer to the public security target of the corresponding hardware 10 m TS vs OB 3 6 for 145 M64 J3E120 M65 J3E082 M65 for az2 variable o is absent 3 The values for rr ff are customer dependent The following table explains the naming conventions of the commercial product name of the JCOP products Every JCOP product gets assigned such a commercial name which includes also customer and application specific data This table does not give any information about which commercial products are Common Criteria certified Table 7 JCOP Commercial Name Format Variable Meaning Example Parameter settings Values a Hardware Type 1 SC hardware no PKI no contactless interface 2 CC hardware no contactless interface 3 CD hardware 4 USB hardware 5 NFC S C hardware 6 CL hardware for uSD 7 Authentication IC and or SPI Approved All information provided in this document is subject to legal disclaimers NXP B V 201
205. ricted to the output of the last AES operation i e only the last block of the ciphertext is returned FCS COP 1 1 ECSignature The TSF shall perform assignment digital signature generation and verification in accordance with a specified cryptographic algorithm assignment ECDSA with SHA 1 SHA 224 and SHA 256 38 and cryptographic key sizes assignment EC 160 192 224 256 320 bits with the domain parameters provided in NIST DSS standard FIPS 186 3 42 Appendix D or in Brainpool ECC Standard Curves 34 chapters 3 1 to 3 5 that meet the following assignment ISO 14888 3 26 and FIPS 186 3 42 ECDSA Application Note The security functionality is resistant against side channel analysis and similar techniques It is demonstrated for curves defined by NIST 42 and Brainpool 34 only To fend off attackers with high attack potential an adequate key length must Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 70 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC be used references can be found in national and international documents and standards FCS COP 1 1 ECAdd The TSF shall perform assignment secure point addition in accordance with a specified cryptographic algorithm assignment ECC over GF p EC point addition and cryptographic key sizes sizes
206. rm for the JCVM to execute the code they contain It is a subsystem of what is usually called card manager as such it can be seen as the portion of the card manager that belongs to the TOE The installer has an AID that uniquely identifies him and may be implemented as a Java Card applet However it is granted specific privileges on an implementation specific manner 18 810 A special kind of Java programming language class which declares methods but provides no implementation for them A class may be declared as being the implementation of an interface and in this case must contain an implementation for each of the methods declared by the interface see also shareable interface The Java Card runtime environment consists of the Java Card virtual machine the Java Card API and its associated native methods This notion concerns all those dynamic features that are specific to the execution of a Java program in a smart card like applet lifetime applet isolation and object sharing transient objects the transaction mechanism and so on An object owned by the JCRE context but accessible by any application These methods are the gateways through which applets request privileged JCRE system services the instance methods associated to those objects may be invoked from any context and when that occurs a context switch to the JCRE context is performed There are two categories of JCRE Entry Point Objects Temporary ones a
207. rolled under the SFP from outside the TOE Package loading is allowed only if for each dependent package its AID attribute is equal to a resident package AID attribute the major minor Version attribute associated to the dependent package is lesser than or equal to the major minor Version attribute associated to the resident package 19 4 5 2 6 1 5 2 FMT SMR 1 Installer Security roles FMT SMR 1 1 Installer The TSF shall maintain the roles Installer FMT SMR 1 2 Installer The TSF shall be able to associate users with roles 6 1 5 3 FPT FLS 1 Installer Failure with preservation of secure state Approved FPT FLS 1 1 Installer All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 78 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC The TSF shall preserve a secure state when the following types of failures occur the installer fails to load install a package applet as described in 18 11 1 4 Application note The TOE may provide additional feedback information to the card manager in case of potential security violations see FAU ARP 1 6 1 5 4 FPT_RCV 3 Installer Automated recovery without undue loss 6 1 6 1 FPT RCV 3 1 Installer When automated recovery from assignment a failure during load installation of a package applet is not possible the TSF shall enter a
208. rors related to applet s failure like uncaught exceptions Applet life cycle states are INSTALLED SELECTABLE LOCKED In addition to these Application Life Cycle States the Application may define its own Application dependent states Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 74 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC e The bytecode verification defines a large set of rules used to detect a potential security violation The actual monitoring of these events within the TOE only makes sense when the bytecode verification is performed on card e Depending on the context of use and the required security level there are cases where the card manager and the TOE must work in cooperation to detect and appropriately react in case of potential security violation This behavior must be described in this component It shall detail the nature of the feedback information provided to the card manager like the identity of the offending application and the conditions under which the feedback will occur any occurrence of the java lang SecurityException exception e The locking of the card session may not appear in the policy of the card manager Such measure should only be taken in case of severe violation detection the same holds for the re initialization of the Java Ca
209. rotect the confidentiality and the integrity of the TOE ALC DVS 2 has no dependencies AVA VAN 5 Advanced methodical vulnerability analysis Vulnerability analysis is an assessment to determine whether vulnerabilities identified during the evaluation of the construction and anticipated operation of the TOE or by other methods e g by flaw hypotheses could allow users to violate the TSP Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 113 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC This assurance component is a higher hierarchical component to EAL5 only VANA is found in EAL5 AVA VAN 4 has dependencies with ADV ARC 1 Security architecture description ADV FSP 4 Complete functional specification ADV TDS 3 Basic modular design ADV IMP 1 Implementation representation of the TSF AGD OPE 1 Operational user guidance and AGD PRE 1 Preparative procedures These components are included in EAL5 and so these dependencies are satisfied ASE TSS 2 TOE summary specification with architectural design summary The TOE summary specification shall describe how the TOE protects itself against interference and logical tampering and the TOE summary specification shall describe how the TOE protects itself against bypass This assurance component is a higher hierarch
210. rvices T OBJ DELETION This threat is covered by the OT OBJ DELETION security objective which ensures that object deletion shall not break references to objects Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 50 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC Miscellaneous T PHYSICAL Covered by OT SCP IC Physical protections rely on the underlying platform and are therefore an environmental issue 4 3 1 2 Organisational Security Policies OSP VERIFICATION This policy is upheld by the security objective of the environment OE VERIFICATION which guarantees that all the bytecodes shall be verified at least once before the loading before the installation or before the execution in order to ensure that each bytecode is valid at execution time 4 3 1 3 Assumptions A APPLET This assumption is upheld by the security objective for the operational environment OE APPLET which ensures that no applet loaded post issuance shall contain native methods A VERIFICATION This assumption is upheld by the security objective on the operational environment OE VERIFICATION which guarantees that all the bytecodes shall be verified at least once before the loading before the installation or before the execution in order to ensure that each bytecode is valid at execution time 4 3 2 Security
211. send an please send an email to salesaddresses nxp com Date of release 2nd August 2013
212. sonalization to configure several parameters of the OS Is the native code library residing in the Secure Box Objects prefixed with an O are described in the following table Table 16 Object Descriptions Object Description O APPLET Any installed applet its code and data O CODE PKG The code of a package including all linking information On the Java Card platform a package is the installation unit O JAVAOBJECT Java class instance or array It should be noticed that KEYS PIN arrays and applet instances are specific objects in the Java programming language O REMOTE MTHD A method of a remote interface O REMOTE OBJ A remote object is an instance of a class that implements one or more remote interfaces A remote interface is one that extends directly or indirectly the interface java rmi Remote 17 O RMI SERVICE These are instances of the class javacardx rmi RMIService They Approved All information provided in this document is subject to legal disclaimers Rev 00 02 2nd August 2013 56 of 135 NXP B V 2013 All rights reserved Evaluation documentation NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC Object Description are the objects that actually process the RMI services O ROR A remote object reference It provides information concerning i the identification of a remote object and ii the Implementation class of the object or the interfaces implemented by
213. sssssssssssseeeeeeeeenneee 43 Assignment threats OSP security objectives for the TOE einer teret iet 45 Assignment threats assumptions OSP security objectives for the environment 46 Requirement 54 Subject Descriptions 55 Object 5 56 Information Descriptions 57 Security Attribute Descriptions 57 Operation Descriptions 58 Security Attributes esses 60 Security Attributes esses 63 Security Attributes 80 Security Attributes 83 TSF mediated commands for FIA UID 1 86 Assignment Security Objectives for the TOE Security Requirements 1 99 Assignment Security Objectives for the TOE Security Requirements 2 101 Assignment Security Objectives for the TOE Security Requirements 3 102 Assignment Security Objectives for the TOE Security Requirements 4 103 List of all security functions 114 Response Reaction on SF Audit events 117 All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved
214. subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 23 of 135 NXP Semiconductors JCOP 2 4 2 R3 D APP C DATA D APP DATA D PIN D APP KEYs D JCS8 CODE D JCS DATA D SEC DATA D API DATA D CRYPTO D ADMIN CONF DATA D PERSO CONF DATA Security Target Lite PUBLIC Confidential sensitive data of the applications like the data contained in an object a static field of a package a local variable of the currently executed method or a position of the operand stack To be protected from unauthorized disclosure Integrity sensitive data of the applications like the data contained in an object a static field of a package a local variable of the currently executed method or a position of the operand stack To be protected from unauthorized modification Any end user s PIN To be protected from unauthorized disclosure and modification Cryptographic keys owned by the applets To be protected from unauthorized disclosure and modification TSF Data The code of the Java Card System To be protected from unauthorized disclosure and modification The internal runtime data areas necessary for the execution of the JCVM such as for instance the frame stack the program counter the class of an object the length allocated for an array any pointer used to chain data structures To be protected from monopolization and unauthoriz
215. t Upon receiving a SELECT command from the CAD with this applet s AID the JCRE makes this applet the currently selected applet The JCRE sends all APDU commands to the currently selected applet 18 Glossary Default applet The applet that is selected after a card reset 18 84 1 DCSSI Direction Centrale de la S curit des Syst mes d Information French national certification body EAL Evaluation Assurance Level EEPROM Electrically Erasable Programmable ROM All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 4 of 135 NXP Semiconductors JCOP 2 4 2 R3 Embedded Software ES Firewall HAL IC Installer Interface JCRE JCRE Entry Point JCRMI Security Target Lite PUBLIC Pre issuance loaded software Embedded Software The mechanism in the Java Card technology for ensuring applet isolation and object sharing The firewall prevents an applet in one context from unauthorized access to objects owned by the JCRE or by an applet in another context Hardware Abstraction Layer Integrated Circuit The installer is the on card application responsible for the installation of applets on the card It may perform or delegate mandatory security checks according to the card issuer policy for bytecode verification for instance loads and link packages CAP file s on the card to a suitable fo
216. t Lite PUBLIC 18 6 1 2 1 At any point in time there is only one active context within the Java Card VM this is called the Currently Active Context It should be noticed that the invocation of static methods or access to a static field is not considered by this policy as there are no firewall rules They have no effect on the active context as well and the acting package is not the one to which the static method belongs to in this case It should be noticed that the Java Card platform version 2 2 x and version 3 Classic Edition introduces the possibility for an applet instance to be selected on multiple logical channels at the same time or accepting other applets belonging to the same package being selected simultaneously These applets are referred to as multiselectable applets Applets that belong to a same package are either all multiselectable or not 19 82 2 5 Therefore the selection mode can be regarded as an attribute of packages No selection mode is defined for a library package An applet instance will be considered an active applet instance if it is currently selected in at least one logical channel An applet instance is the currently selected applet instance only if it is processing the current command There can only be one currently selected applet instance at a given time 18 4 It should be noted that the TOE does not support multiple logical channels 6 1 1 3 FDP IFC 1 JCVM Subset Information Flo
217. t of the TSF All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 112 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC The dependency FMT SMF 1 of FMHT MSA 1 JCRE is unsupported The dependency between FMT MSA 1 JCRE and FMT_SMF 1 is not satisfied because no management functions are required for the Java Card RE The dependency FAU SAA 1 of FAU ARP 1 is unsupported The dependency of FAU ARP 1 on FAU SAA 1 assumes that a potential security violation generates an audit event On the contrary the events listed in FAU ARP 1 are self contained arithmetic exception ill formed bytecodes access failure and ask for a straightforward reaction of the TSFs on their occurrence at runtime The JCVM or other components of the TOE detect these events during their usual working order Thus there is no mandatory audit recording in this ST The dependency FIA UAU 1 of FIA AFL 1 PIN is unsupported The TOE implements the firewall access control SFP based on which access to the object Implementing FIA AFL 1 PIN is organized The dependency FDP ACF 1 JCRMI of FMT MSA 3 JCRMI is unsupported The TOE restricts the access to any subject for access to the RMI functionality the security attributes that are part of this functionality are not used and therefore no management of security attributes is
218. tG The InstG contains the security requirements TOE concerning the installation of post issuance applications It does not address card management issues in the broad sense but only those security aspects of the installation procedure that are related to applet execution RMI RMIG The RMIG contains the security requirements for the remote method invocation features which provides a new protocol of communication between the terminal and the applets This group is not implemented and therefore outside the scope of evaluation Logical channels LCG The LCG contains the security requirements for the logical channels which provide a runtime environment where several applets can be simultaneously selected or a single one can be selected more than once This group is not within the scope of evaluation Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 17 of 135 NXP Semiconductors JCOP 2 4 2 H3 1 3 6 Approved Security Target Lite PUBLIC Group Description Scope Object deletion ODELG The ODELG contains the security requirements for the object deletion capability This provides a safe memory recovering mechanism Bytecode verification BCVG The BCVG contains the security requirements IT concerning the bytecode verification of the application code to be loaded on the card In
219. tall method and the de allocation occurs precisely right after the return of it 6 1 2 9 FDP_RIP 1 KEYS Subset Residual Information Protection FDP_RIP 1 1 KEYS The TSF shall ensure that any previous information content of a resource is made unavailable upon the de allocation of the resource from the following objects the cryptographic buffer D CRYPTO Application note The javacard security amp javacardx crypto packages do provide secure interfaces to the cryptographic buffer in a transparent way See javacard security KeyBuilder and Key interface of 17 6 1 2 10 FDP_RIP 1 TRANSIENT Subset Residual Information Protection FDP RIP 1 1 TRANSIENT The TSF shall ensure that any previous information content of a resource is made unavailable upon the de allocation of the resource from the following objects any transient object Application note e The events that provoke the de allocation of any transient object are described in 18 85 1 e The clearing of CLEAR ON DESELECT objects is not necessarily performed when the owner of the objects is deselected In the presence of multiselectable applet instances CLEAR ON DESELECT memory segments may be attached to applets that are active in different logical channels Multiselectable applet instances within a same package must share the transient memory segment if they are concurrently active 18 4 2 6 1 2 11 FDP ROL 1 FIREWALL Basic Rollback FDP ROL 1 1 FIREWALL The TSF shall
220. tantiated in the objective OT FIREWALL The following sections present several security aspects from 5 that are relevant for this ST 3 6 1 Confidentiality CONFID APPLI DATA Application data must be protected against unauthorized disclosure This concerns logical attacks at runtime in order to gain read access to other application s data CONFID JCS CODE Java Card System code must be protected against unauthorized disclosure This concerns logical attacks at runtime in order to gain a read access to executable code typically by executing an application that tries to read the memory area where a piece of Java Card System code is stored CONFID JCS DATA Java Card System data must be protected against unauthorized disclosure This concerns logical attacks at runtime in order to gain a read access to Java Card System data Java Card System data includes the data managed by Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 32 of 135 NXP Semiconductors JCOP 2 4 2 R3 3 6 2 Integrity INTEG APPLI CODE INTEG APPLI DATA INTEG JCS CODE INTEG JCS DATA Security Target Lite PUBLIC the Java Card runtime environment the virtual machine and the internal data of Java Card API classes as well Application code must be protected against unauthorized modification This concerns logica
221. te PUBLIC The TOE shall control the availability of resources for the applications See RESOURCES p 37 for details The TOE shall provide appropriate feedback information upon detection of a potential security violation See t ALARM 36 for details The TOE shall provide a means to cipher sensitive data for applications in a secure way In particular the TOE must support cryptographic algorithms consistent with cryptographic usage policies and standards See CIPHER p 37 for details The TOE shall provide a means to securely manage cryptographic keys This concerns the correct generation distribution access and destruction of cryptographic keys See KEY MNGT p 37 The TOE shall provide a means to securely manage PIN objects See PIN MNGT p 37 for details Application Note PIN objects may play key roles in the security architecture of client applications The way they are stored and managed in the memory of the smart card must be carefully considered and this applies to the whole object rather than the sole value of the PIN For instance the try counter s value is as sensitive as that of the PIN For this Java Card such libraries do not exist All necessary functionality is implemented by the TOE The TOE shall provide restricted remote access from the CAD to the services implemented by the applets on the card This particularly concerns the Java Card RMI services introduced in version 2 2 x of the Java
222. tection of the array parameters of remotely invoked methods which are global as well is covered by the general initialization of method parameters FDP_RIP 1 ODEL FDP_RIP 1 OBJECTS FDP_RIP 1 ABORT FDP_RIP 1 KEYS FDP_RIP 1 ADEL and FDP_RIP 1 TRANSIENT OT GLOBAL ARRAYS INTEG This objective is met by the JCVM information flow control policy FDP_IFF 1 JCVM FDP_IFC 1 JCVM which prevents an application from keeping a pointer to the APDU buffer of the card or to the global byte array of the applet s install method Such a pointer could be used to access and modify it when the buffer is being used by another application OT NATIVE This security objective is covered by FDP ACF 1 FIREWALL the only means to execute native code is the invocation of a Java Card API method This objective mainly relies on the environmental objective OE APPLET which uphold the assumption A APPLET OT OPERATE The TOE is protected in various ways against applets actions FPT TDC 1 the FIREWALL access control policy FDP_ACC 2 FIREWALL and Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 105 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC FDP ACF 1 FIREWALL and is able to detect and block various failures or security violations during usual working FPT_FLS 1 ADEL FPT FLS 1 FPT FLS 1 ODEL FPT FLS 1
223. ted to one of the above and aimed at disclosing or modifying on card information Nevertheless they vary greatly on the employed means and threatened assets and are thus covered by quite different objectives in the sequel That is why a more detailed list is given hereafter 3 3 2 3 Identity Usurpation T SID 1 An applet impersonates another application or even the JCRE in order to gain illegal access to some resources of the card or with respect to the end user or the terminal See SID p 35 for details Directly threatened asset s D SEC DATA other assets may be jeopardized should this attack succeed for instance if the identity of the JCRE is usurped D PIN and D APP_KEYs T SID 2 The attacker modifies the TOE s attribution of a privileged role e g default applet and currently selected applet which allows illegal impersonation of this role See SID p 35 for further details Directly threatened asset s D SEC_DATA any other asset may be jeopardized should this attack succeed depending on whose identity was forged 3 3 2 4 Unauthorized Execution T EXE CODE 1 An applet performs an unauthorized execution of a method See EXE JCS CODE p 33 and EXE APPLI CODE p 33 for details Directly threatened asset s DLAPP CODE T EXE CODE 2 An applet performs an unauthorized execution of a method fragment or arbitrary data See EXE JCS CODE p 33 and EXE APPLI CODE p 33 for details Directly threatened
224. ter objective also relies in its turn on the correct identification of applets stated in OT SID Moreover as the firewall is dynamically enforced it shall never stop operating as stated in the OT OPERATE objective As the firewall is a software tool automating critical controls the objective OT ALARM asks for it to provide clear warning and error messages so that the appropriate countermeasure can be taken The objectives OT CARD MANAGEMENT and OE VERIFICATION contribute to cover this threat by controlling the access to card management functions and by checking the bytecode respectively The objectives OT SCP RECOVERY and OT SCP SUPPORT are intended to support the OT DPERATE and OT ALARM objectives of the TOE so they are indirectly related to the threats that these latter objectives contribute to counter Finally the objective OT EXT MEM provides access control for external memory and therefore also contributes to counter this threat Identity Usurpation T SID 1 As impersonation is usually the result of successfully disclosing and modifying some assets this threat is mainly countered by the objectives concerning the isolation of application data like PINs ensured by the OT FIREWALL Uniqueness of subject identity OT SID also participates to face this threat It should be noticed that the AIDs which are used for applet identification are TSF data In this configuration usurpation of identity resulting from a malicious installation o
225. the present case this group of SFRs applies to the IT environment Applet deletion ADELG The ADELG contains the security requirements for TOE erasing installed applets from the card It can also be used as a basis for any other application deletion requirements Secure carrier CarG The CarG group contains minimal requirements for TOE secure downloading of applications on the card This group contains the security requirements for preventing in those configurations which do not support on card static or dynamic verification of bytecodes the installation of a package that has not been bytecode verified or that has been modified after bytecode verification Card Lifecycle Management The Lifecycle Group contains the minimal TOE LifeCycle requirements that allow defining a policy for controlling access to card lifecycle management operations and for expressing card issuer security concerns This group is within the scope of evaluation External Memory EMG The EMG contains the requirements for a secure TOE management of the external memory accessible to applet instances As asummary of this table the scope of this TOE evaluation corresponds to the Open Configuration as defined in the Java Card Protection Profile Note that the code of the applets is not part of the code of the TOE but just data managed by the TOE Moreover the scope of the ST does not include all the stages in the development cycle of a Java Card application
226. the Card Manager belongs to the TOE for this evaluation 4 1 2 7 Smart Card Platform These TOE Security Objectives for the smart card platform are Security Objectives for the environment in 5 In the present case the certified smart card platform belongs to the TOE and the corresponding Security Objectives are listed here OT SCP IC The SCP shall provide all IC security features against physical attacks See SCP 7 p 37 OT SCP RECOVERY If there is a loss of power or if the smart card is withdrawn from the CAD while an operation is in progress the SCP must Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 42 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC allow the TOE to eventually complete the interrupted operation successfully or recover to a consistent and secure state 4 SCP 1 p 37 OT SCP SUPPORT The SCP shall support the TSFs of the TOE This security objective for the environment refers to the security aspects 2 3 4 and 5 of SCP p 37 Note The Security Objectives from 5 for the environment OE SCP RECOVERY OE SCP SUPPORT and OT SCP IC are listed as TOE security objectives for the TOE in section 4 1 2 7 as the smart card platform belong to the TOE for this evaluation 4 1 2 8 EMG Extended Memory This TOE Security Objective for the extended
227. the attributes CPU mode the MMU Segment Table the Special Function Registers to configure the MMU segmentation and the Special Function Registers related to system management FDP_ACF 1 2 SCP The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed assignment Code executed in the Boot Mode e has read and execute access to all code data in the Test ROM e has read write and execute access to all code data in the MIFARE EEPROM e has read and write access to all data in the MIFARE RAM Code executed in the Test Mode e has read and execute access to all code data in the whole ROM e has read write and execute access to all code data in the whole EEPROM e has read and write access to all data in the whole RAM Code executed in the MIFARE Mode e has read and execute access to all code data in the Test ROM e has read write and execute access to all code data in the MIFARE EEPROM e has read and write access to all data in the MIFARE RAM Code executed in the System Mode Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 90 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC e has read and execute access to all code data in the Application ROM e has read write and execute access to all code data in the Application
228. the execution of native code is outside of the TOE Scope Control TSC it must be secured so as to not provide ways to bypass the TSFs No untrusted native code may reside on the card Loading of native code which is as well outside the TSC is submitted to the same requirements Should native software be privileged in this respect exceptions to the policies must include a rationale for the new security framework they introduce Bytecode Verification VERIFICATION All bytecode must be verified prior to being executed Bytecode verification includes 1 how well formed CAP file is and the verification of the typing constraints on the bytecode 2 binary compatibility with installed CAP files and the assurance that the export files used to check the CAP file correspond to those that will be present on the card when loading occurs 3 6 3 2 CAP File Verification Approved Bytecode verification includes checking at least the following properties 3 bytecode instructions represent a legal set of instructions used on the Java Card platform 4 adequacy of bytecode operands to bytecode semantics 5 absence of operand stack overflow underflow 6 control flow confinement to the current method that is no control jumps to outside the method 7 absence of illegal data conversion and reference forging 8 enforcement of the private public access modifiers for class and class members 9 validity of any kind of reference used in the byteco
229. tialization FMT MSA 3 1 EXT MEM Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 88 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC The TSF shall enforce the EXTERNAL MEMORY access control SFP to provide no default values for security attributes that are used to enforce the SFP FMT MSA 3 2 EXT MEM The TSF shall allow the Java Card RE to specify alternative initial values to override the default values when an object or information is created 6 1 10 5 FMT SMF 1 EXT MEM Specification of Management Functions 6 1 11 6 1 12 6 1 12 1 FMT SMF 1 1 EXT MEM The TSF shall be capable of performing the following management functions set up the address space security attribute Further Functional Requirements not contained in 5 SCPG Security Functional Requirements For this evaluation the smart card platform belongs to the TOE and the functional requirements are stated here as functional requirements for the TOE FPT FLS 1 SCP Failure with preservation of a Secure State This assignment operation of the functional requirement has been taken over from the ST of the certified hardware platform P5CD145VOB that is conformant to 6 FPT FLS 1 1 SCP The TSF shall preserve a secure state when the following types of failures occur assignment exposure to operating conditi
230. tors JCOP 2 4 2 R3 1 Security Target Lite PUBLIC ST Introduction ASE INT Approved 1 1 ST reference and TOE reference 1 2 Table 1 Title Version Date Author s Developer Product Type TOE name version Certification ID TOE hardware CC used ST reference and TOE reference NXP J3E145 M64 J3E120 M65 J3E082 M65 J2E145 M64 J2E120 M65 and J2E082 M65 Secure Smart Card Controller Revision 3 Security Target Rev 00 02 2nd August 2013 NXP Semiconductors NXP Semiconductors Java Card NXP J3E145 M64 J3E120 M65 J3E082 M65 J2E145 M64 J2E120 M65 and J2E082 M65 Secure Smart Card Controller Revision 3 NSCIB CC 13 37760 P5CD145V0B VOB s P5CC145VOB VOB s Common Criteria for Information Technology Security Evaluation Version 3 1 Revision 4 September 2012 Part 1 Part 2 and Part 3 TOE overview This document details the security target lite for NXP J3E145 M64 J3E120 M65 J3E082 M65 J2E145 M64 J2E120 M65 and J2E082 M65 Secure Smart Card Controller Revision 3 also named JCOP 2 4 2 R3 It is compliant to the protection profile Java Card System Open Configuration Protection Profile Version 2 6 Certified by ANSSI the French Certification Body April 19th 2010 5 The ST fulfils all requirements of 5 This ST chooses a hierarchically higher EAL namely EAL5 augmented by ALC_DVS 2 AVA VAN 5 and ASE TSS 2 The basis of this composite evaluation is the composite evaluation
231. trolled subject and controlled information via a controlled operation if the following rules hold assignment 1 S PACKAGE CM should only accept packages sent by S CAD after S CAD has been authenticated 2 S PACKAGE CM should only accept packages from S CAD for which all APDUS have been received and are unmodified and in the correct order FDP IFF 1 3 CM The TSF shall enforce the additional information flow control SFP rules assignment none FDP IFF 1 4 CM The TSF shall explicitly authorise an information flow based on the following rules assignment none Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 85 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC FDP IFF 1 5 CM The TSF shall explicitly deny an information flow based on the following rules assignment If the authentication retry counter has reached its maximum number of 66 6 1 9 4 UIT 1 CM Data exchange integrity FDP UIT 1 1 CM The TSF shall enforce the PACKAGE LOADING information flow control SFP to receive user data in a manner protected from modification deletion insertion replay errors FDP UIT 1 2 CM Editorially Refined The TSF shall be able to determine on receipt of user data whether modification deletion insertion replay of some of the pieces of the application s
232. uage Invoke a virtual method either on a class instance or an array object Invoke an interface method OP INVOKE O RMI SERVICE Requests remote method invocation on the remote object Any access in the sense of 18 6 2 8 It stands for one of the operations OP ARRAY ACCESS OP INSTANCE FIELD OP INVK VIRTUAL OP INVK INTERFACE OP THROW OP TYPE ACCESS OP PUT S1 S2 I Transfer a piece of information from S1 to S2 RORD S JCRE S CAD I RORD Send a remote object reference descriptor to the CAD Throwing of an object athrow see 18 6 2 8 7 Invoke checkcast or instanceof on an object in order to access to classes standard or shareable interfaces objects Creation of an instance of the MemoryAccess Interface Reading the external memory Writing the external memory 7 For this operation there is no accessed object This rule enforces that shareable transient objects are not allowed For instance during the creation of an object the JavaCardClass attribute s value is chosen by the creator Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 59 of 135 NXP Semiconductors JCOP 2 4 2 H3 6 1 6 1 1 6 1 1 1 Security Target Lite PUBLIC Operation Description OP SB ACCESS Any read write or execution access to a memory area OP SB AC
233. uction of DES AES RSA RSA CRT and EC keys by physically overwriting the keys by method clearKey of Java Card API 17 see 6 1 2 4 FCS CKMA Generation of ECC over GF p keys with length from 128 to 320 Bit based on random numbers according to AIS 20 8 class DRG 3 or DRG 2 see 6 1 2 1 FCS CKM 1 Distribution of ECC over GF p keys according toJava Card API 17 see 6 1 2 2 FCS_CKM 2 Destruction of session keys by physically overwriting the keys by overwriting them with zeros when explicitly deleted or when the applet is deselected see 6 1 2 4 FCS_CKM 4 7 1 4 SF CryptoOperation This TSF is responsible for secure cryptographic operation Cryptographic key management is provided by the previous TSF This TSF provides the following functionality SF COP DES SF COP RSA SF COP MAC SF COP AMC SF COP AES SF COP RSI SF COP RSP Approved Data encryption and decryption with Triple DES in ECB CBC Mode and cryptographic key sizes of 112 and 168 Bit that meets ANSI X9 52 1998 40 for details especially on the supported schemes and padding algorithms see 6 1 2 5 FCS COP 1 TripleDES Data encryption and decryption with RSA and PKCS 1 padding 22 Key sizes range from 512 to 2048 Bit for details especially on the supported schemes and padding algorithms see 6 1 2 5 FCS COP 1 RSACipher 8 byte MAC generation and verification with Triple DES in outer CBC Mode and cryptographic key size of 112 and 168 Bit acco
234. unktionalitaetsklassen und Evaluationsmethodologie fuer physikalische Zufallszahlengeneratoren Version 1 25 09 2001 Bundesamt fuer Sicherheit in der Informationstechnik 33 UM SecureBox JCOP V2 4 2 221134 Rev 3 4 34 RFC 5639 ECC Brainpool Standard Curves amp Curve Generation March 2010 available at http tools ietf org html rfc5639 35 FIPS PUB 186 2 U S DEPARTMENT OF COMMERCE National Institute of Standards and Technology Issued January 27 2000 36 FIPS PUB 81 DES modes of operation Federal Information Processing Standards Publication December 2 1980 US Department of Commerce National Institute of Standards and Technology 37 Recommendation for Block Cipher Modes of Operation Methods and Techniques NIST Special Publication 800 38A National Institute of Standards and Technology 2001 Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 128 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC 38 SECURE HASH STANDARD Federal Information Processing Standards Publication 180 4 October 2008 39 Kryptographische Verfahren Empfehlungen und Schlissellangen BSI Technische Richtlinie BSI TR 02102 v1 0 20 06 2008 40 American National Standard Triple data encryption algorithm modes of operation ANSI X9 52 November 9 1998 41 FIPS PUB
235. ved Evaluation documentation Rev 00 02 2nd August 2013 16 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC Variable Meaning Example Parameter settings Values B Config D2 MIFARE DESFire 2k C Config D4 MIFARE DESFire 4K D Config D8 MIFARE DESFire 8K 1 3 5 Java Card Technology For an overview on Java Card technology the reader is referred to Section 2 of the Java Card Protection Profile 5 In the Java Card Protection Profile the Java Card System is divided into so called groups For a detailed explanation of these groups please see the Java Card Protection Profile 5 For the TOE of this certification the groups marked with TOE are part of the TOE evaluation Groups marked with IT are considered in the TOE IT environment and groups marked with are out of scope of this evaluation Table 8 TOE Groups Overview Group Description Scope Core CoreG The CoreG contains the basic requirements TOE concerning the runtime environment of the Java Card System such as the firewall policy and the requirements related to the Java Card API This group is within the scope of evaluation Smart card platform SCPG The SCPG contains the security requirements for TOE the smart card platform that is operating system and chip that the Java Card System is implemented upon In the present case this group applies to the TOE and is within the scope of evaluation Installer Ins
236. vices to other applications including applets under the control of the TOE It is obvious that such native code presents a threat to the security of the TOE and to user applets Therefore Java Card Protection Profile will require for native applications to be conformant with the TOE so as to ensure that they do not provide a means to circumvent or jeopardize the TSFs For the present products on J3E145 M64 J3E120 M65 J3E082 M65 and J2E145 M64 J2E120 M65 J2E082 M65 the certified hardware contains a native MIFARE application that belongs to the TOE A TOE configured with the minor configuration option MIFARE Emulation A does not provide an additional interface to the environment because the MIFARE application is logically disabled For J3E145 M64 J3E120 M65 J3E082 M65 the minor configurations MIFARE Emulation B1 and MIFARE Emulation B4 implement the contactless MIFARE Classic OS and have access to 1KB or 4KB of EEPROM memory respectively Except native code which resides in the Secure BOX the final product does not contain any other native applications according to JC PP To completely securely separate the User OS and the MIFARE OS the smart card platform provides the so called MIFARE firewall see platform Security Targets 10 9 1 4 TOE Usage Smart cards are mainly used as data carriers that are secure against forgery and tampering More recent uses also propose them as personal highly reliable small size devi
237. w Control IFC 1 1 7CVM The TSF shall enforce the JCVM information flow control SFP on S JCVM S LOCAL S MEMBER I DATA and OP PUT S1 S2 I Note It should be noticed that references of temporary Java Card RE entry points which cannot be stored in class variables instance variables or array components are transferred from the internal memory of the Java Card RE TSF data to some stack through specific APIs Java Card RE owned exceptions or Java Card RE invoked methods such as the process APDU apdu these are causes of OP PUT S1 S2 I operations as well 6 1 1 4 IFF 1 JCVM Simple Security Attributes FDP_IFF 1 1 JCVM The TSF shall enforce the JCVM information flow control SFP based on the following types of subject and information security attributes Table 21 Security Attributes Subject Object Security attributes S JCVM Currently Active Context S LOCAL Currently Active Context S MEMBER Currently Active Context I DATA Currently Active Context FDP_IFF 1 2 JCVM The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd August 2013 63 of 135 NXP Semiconductors JCOP 2 4 2 H3 Security Target Lite PUBLIC e An operation OP PUT S1 S MEMBE
238. w to and from any subject in the TOE are covered by an information flow control SFP Application note e The subjects covered by this policy are those involved in the loading of an application package by the card through a potentially unsafe communication channel e The operations that make information to flow between the subjects are those enabling to send a message through and to receive a message from the communication channel linking the card to the outside world It is assumed that any message sent through the channel as clear text can be read by an attacker Moreover an attacker may capture any message sent through the communication channel and send its own messages to the other subjects e The information controlled by the policy is the APDUs exchanged by the subjects through the communication channel linking the card and the CAD Each of those messages contain part of an application package that is required to be loaded on the card as well as any control information used by the subjects in the communication protocol 6 1 9 3 FDP IFF 1 CM Simple security attributes FDP IFF 1 1 CM The TSF shall enforce the PACKAGE LOADING information flow control SFP based on the following types of subject and information security attributes assignment 1 The keys used by S BCV S CAD and S PACKAGE CM to secure the communication channel 2 Authentication retry counter FDP IFF 1 2 CM The TSF shall permit an information flow between a con
239. y attribute based access control FDP ACF 1 1 EXT MEM The TSF shall enforce the EXTERNAL MEMORY access control SFP to objects based on the following object O EXT MEM INSTANCE and security attribute Address space FDP ACF 1 2 EXT MEM The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed e R JAVA 20 Any subject S APPLET that performs OP CREATE_EXT_MEM_INSTANCE obtains an object O EXT_MEM_INSTANCE that addresses a memory space different from that of the Java Card System e R JAVA 21 Any subject S APPLET may perform OP READ EXT MEM O EXT MEM INSTANCE address provided the address belongs to the space of the O EXT MEM INSTANCE R JAVA 22 Any subject S APPLET may perform OP WRITE EXT MEM O EXT MEM INSTANCE address provided the address belongs to the space of the O EXT MEM INSTANCE FDP ACF 1 3 EXT MEM The TSF shall explicitly authorise access of subjects to objects based on the following additional rules assignment none FDP ACF 1 4 EXT MEM The TSF shall explicitly deny access of subjects to objects based on the following additional rules assignment none 6 1 10 3 FMT MSA 1 EXT MEM Management of security attributes FMT MSA 1 1 EXT MEM The TSF shall enforce the EXTERNAL MEMORY access control SFP to restrict the ability to set up the security attributes address space to the Java Card RE 6 1 10 4 FMT MSA 3 EXT MEM Static attribute ini
240. ytecode verification the installation of a package that has not been bytecode verified or that has been modified after bytecode verification The EMG group contains security requirements for the management of external memory Subjects are active components of the TOE that essentially act on the behalf of users The users of the TOE include people or institutions like the applet developer the card issuer the verification authority hardware like the CAD where the card is inserted or the PCD and software components like the application packages installed on the card Some of the users may just be aliases for other users For instance the verification authority in charge of the bytecode verification of the applications may be just an alias for the card issuer Subjects prefixed with an S are described in the following table Table 15 Subject Descriptions Subject S ADEL Description The applet deletion manager which also acts on behalf of the card issuer It may be an applet 18 11 but its role asks anyway for a specific treatment from the security viewpoint This subject is unique and is involved in the ADEL security policy defined in 87 1 3 1 5 The PP refers to Java Card Specification 2 2 we use Java Card Specification 3 0 1 Approved All information provided in this document is subject to legal disclaimers NXP B V 2013 All rights reserved Evaluation documentation Rev 00 02 2nd Au

NXP J3E145_M64, J3E120_M65, J3E082_M65

Contents

Download Pdf Manuals

Related Search

Related Contents