P5CD080/ P5CN080/ P5CC080/
P5CC073V0B
Security Target Lite
Rev. 1.9 — 14 July 2010 Evaluation Documentation
BSI-DSZ-CC-0410-2007 PUBLIC
Document information
Info Content
Keywords B; P5CN080V0B;
SI-DSZ-CC-
0410-20
Abstract the
0/ P5CC073V0B
Secure Smart Card Controller
NXP Semiconductors, Business Unit Identification
according to the
Common Criteria for Information Technology
Evaluation (CC) at Level EAL5 augmented
Security Target Lite; SmartMX; P5CD080V0
P5CC0 ; EAL5+; AVA_VLA.4; B
80V0B; P5CC073V0B; NXP
07; AES; DES
Evaluation of
NXP P5CD080/ P5CN080/ P5CC08
developed and provided by
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 2 of 72
Contact information
For additional information, please visit: http://www.nxp.com
For sales office addresses, please send an email to: salesaddresses@nxp.com
vision his ory
test R n: Rev. 1.9, 1
Re
La
t
evisio 4 July 2010
Rev Date Description Remarks
1.9 14-Jul-2010 Bibliography updated OEF, Guidance Manual References
1.8 2010 egal in n 4 Byte ID related docs
04-Jun- Bibliography updated , l formatio
updated
1.7 28-Sep-2009 Table 6
Generalize module type Xn,
1.6 25-Feb-2009 XD” , able 6,
., update to US-eng
“Silver Modules”
Additional delivery form “
formatting, typo corr
T
1.5 29-Aug-2008 Delivery type X3 added PDM1.1 (only antenna bonding)
1.4 008 ule and inlays added
4-Febr2 MOB6 mod
1.3 2007 ded
9-May- P5CC073V0B ad
1.2 007 Bibliography updated
7-Mar-2
1.1 2007 Bibliography updated
16-Feb-
1.0 9-Feb-2007 Conversion to NXP template
0.92 13-Oct-2006 Update after internal review
0.8 28-Sep-2006 Derived from P5CD040 ST
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 3 of 72
1. ST Introduction
This chapter is divided into the following sections: “ST Identification”, “ST Overview” and
nce and Evaluation Assurance Level”.
This Security Target (st_lite_p5cd080v0b_v1_9.doc, Rev. 1.9, 14 July 2010) refers to the
D080V0B Secure Smart Card Controller" (TOE) provided by NXP
ductors, Business Unit Identification for a Common Criteria evaluation.
1.
V0B of the Smart Card
Dedicated Test
Software for test purposes and IC Dedicated Support Software, both stored in the Test-
mprises an 8-bit
emory
nts and three
n Set and the
of the architecture, the
rd Embedded Software.
an integral part of the
e. Several security
are. Other security
software or
s. With the different CPU modes and the memory
t unit the TOE is intended to support multi-application projects.
It contains high
ility cells which guarantee data integrity. This is ideal for applications requiring non-
programs. Security
t data in the on-chip ROM, EEPROM and RAM. In particular when being
rce applications the smart
Hence the TOE shall
• maintain the integrity and the confidentiality of code and data stored in the memories
of it and
• maintain the different CPU modes with the related capabilities for configuration and
memory access and
• maintain the integrity, the correct operation and the confidentiality of security
functions (security mechanisms and associated functions) provided by the TOE.
“CC Conforma
1.1 ST Identification
"NXP P5C
Semicon
1.2 ST Overview
2.1 Introduction
The TOE is the hardware of the microcontroller chip P5CD080
Controller IC family produced by NXP. The TOE includes also IC
ROM of the microcontroller. The Smart Card Controller hardware co
processing unit, volatile and non-volatile memories accessible via a m
management unit, cryptographic co-processors, security compone
communication interfaces.
The TOE includes a Data Sheet, a document describing the Instructio
Guidance Document. This documentation contains a description
secure configuration and usage of the chip by the Smartca
The security measures of the P5CD080V0B are designed to act as
complete security system in order to strengthen the design as a whol
measures are completely implemented in and controlled by the hardw
measures are controlled by the hardware and allow a configuration by
software guided exception
managemen
The non-volatile EEPROM can be used as data or program memory.
reliab
volatile data storage and important for the use as memory for native
functions protec
used in the banking and finance market or in electronic comme
card must provide high security.
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 4 of 72
These features are ensured by the construction of the TOE and the security functions it
provides. The "NXP P5CD080V0B Secure Smart Card Controller" (TOE) mainly provides
S) with up to three
ys,
with different key
iplication, addition and logical) operations,
hy and elliptic curve cryptography.
r,
guration
n P5CN080V0B).
In ad in hardware or
contr ion as well as integrity and
confid ry protection
and s
Note: arithmetic operations is
yptographic
s to be
tions provided by the
ware does not
s means that
he RSA
tion. Nevertheless the
ssor is part of the Smartcard IC and therefore a security relevant
component of the TOE that must resist to the attacks mentioned in this
Security Target and that must operate correctly as specified in the Data
Sheet. The same scope for the evaluation is applied to the CRC module.
The TOE can be delivered in different configurations. This influences the availability of
the contact-less interface (including the functions provided by the MIFARE Operating
System) and other not security relevant features. For the detailed description of the
differences refer to section 2.2.
a hardware platform for a smart card with
• functions to calculate the Data Encryption Standard (Triple-DE
ke
• functions to calculate the Advanced Encryption Standard (AES)
lengths,
• support for large integer arithmetic (mult
suited for public key cryptograp
• a random number generato
• memory management control features,
• cyclic redundancy check calculation (CRC),
• ISO 7816 contact interface with UART,
• contact-less interface supporting MIFARE and ISO 14443A (confi
P5CD080V0B) or S²C interface (configuratio
dition several security features independently implemented
olled by software will be provided to ensure proper operat
entiality of stored data. This includes for example measures for memo
ensors to allow operation only under specified conditions.
The arithmetic co-processor for large integer
intended to be used for the calculation of asymmetric cr
algorithms. Any asymmetric cryptographic algorithm need
implemented in software by using the calculation func
co-processor. Therefore the co-processor without soft
provide a security function itself e.g. cryptographic support. Thi
Smartcard Embedded Software that implements e.g. t
cryptographic algorithm is not included in the evalua
co-proce
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 5 of 72
1.
rd IC Platform Protection
le”, [7] section 8.1), the development and the production phase of the IC with its
part of the
nd of phase 3 or of
authentic delivery using the
FabKey feature (refer to the Product Data Sheet, P5Cx012/02x/040/073/080/144 family
al for the
family of Secure Smart Card Controllers).
During the design and the layout process only people involved in the specific
people are
curity measures
riate
ductors, Business
rds the
f the photo masks.
n data of the
tability and the traceability is ensured among
duction flow.
pendent of the
customer specific mask and
ng ensures the control of the complete
ed wafers.
performed by a test centre of NXP. Delivery processes
rovide accountability and traceability of the produced wafers.
sed on customer
tic/optical media
enclosed with the delivery or the non-functional items are physically marked.
In summary the TOE can be delivered in three different forms:
• Dice on wafers
• Smart Card Modules on a module reel
• Packaged devices in tubes or reels
For each delivery form multiple types are supported. The different (package) types are
described in detail in section 2.3.
2.2 Life-Cycle
Regarding the life cycle of the smartcard (refer to the “Smartca
Profi
dedicated software as described for the Target of Evaluation (TOE) is
evaluation.
Referring to the description in the PP [7], the TOE is delivered at the e
phase 4 as described in section 2.1.
Regarding the Application Note 1 of [7] the TOE supports the
and the Guidance, Delivery and Operation Manu
P5Cx012/02x/040/073/080/144V0B
Security during Development and Production
development project for an IC have access to sensitive data. Different
responsible for the design data and for customer related data. The se
installed within NXP ensure a secure computer system and provide approp
equipment for the different development tasks.
The verified layout data is provided by the developers of NXP Semicon
Unit Identification directly to the wafer fab. The wafer fab generates and forwa
layout data related to the different photo masks to the manufacturer o
The photo masks are generated off-site and verified against the desig
development before the usage. The accoun
the wafer fab and the photo mask provider.
The production of the wafers includes two different steps regarding the pro
In the first step the wafers are produced with the fixed masks inde
customer. After that step the wafers are completed with the
the remaining fixed masks. The computer tracki
process including the storage of the semi-finish
The test process of every die is
between the involved sites p
NXP embeds the dice into smartcard modules or other packages ba
demand. Information about non-functional items is stored on magne
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 6 of 72
1. iteria
nal functionality which is
d in the “Smartcard IC Platform Protection Profile”. These additional
functionality is added using the policy “P.Add-Components” (see section 3.4 of this
Security Target).
vel
luation – Part 1:
B-2005-08-001, [1]
• Common Criteria for Information Technology Security Evaluation – Part 2: Security
functional requirements, Version 2.3, August 2005, CCMB-2005-08-002, [2]
ology Security Evaluation – Part 3: Security
5-08-003, [3]
used:
nology Security Evaluation CEM-99/045
2.3, August 2005, CCMB-2005-08-004, [4]
trength level for the
arget claims the following CC conformances:
• P
• C tection Profile”, [7]
The level of evaluation and the functionality of the TOE are chosen in order to allow the
confirmation that the TOE is suitable for use within devices compliant with the German
Digital Signature Law.
Note: The “Smartcard IC Platform Protection Profile”, [7] requires the assurance
level EAL4 augmented. Regarding the Application Note 3 of [7] the
changes which are needed for EAL5 are described in the different relevant
sections of this Security Target.
2.3 Specific Issues of Smartcard Hardware and the Common Cr
Regarding the Application Note 2 of [7] the TOE provides additio
not covere
1.3 CC Conformance and Evaluation Assurance Le
The evaluation is based upon
• Common Criteria for Information Technology Security Eva
Introduction and general model, Version 2.3, August 2005, CCM
• Common Criteria for Information Techn
Assurance Requirements, Version 2.3, August 2005, CCMB-200
For the evaluation the following methodology will be
• Common Methodology for Information Tech
Part 2: Evaluation Methodology, Version
The chosen level of assurance is EAL 5 augmented. The minimum
TOE security functions is SOF-high (Strength of functions high).
This Security T
s
art 2 extended, Part 3 conformant, EAL 5 augmented
onformance to the Protection Profile “Smartcard IC Platform Pro
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 7 of 72
2. TOE Description
This chapter is divided into the following sections: “TOE Definition”, “
configurations
Evaluated hardware
efinition has the sub-
Description”, “Documentation”, “Interface of
nd Delivery of the TOE”, “TOE Intended Usage”, “TOE User
” as well as “General IT features of the TOE”.
depicted in Fig 1as
CD080V0B is manufactured in an advanced CMOS
process. The TOE includes IC Designer/Manufacturer proprietary IC Dedicated Test
Software and IC Dedicated Support Software. All other software is called Smartcard
Embedded Software and is not part of the TOE.
” and “Further Definitions and Explanations”. TOE D
sections “Hardware Description”, “Software
the TOE”, “Life Cycle a
Environment
2.1 TOE Definition
The Target of Evaluation (TOE) is the smartcard integrated circuit
block diagram. The TOE named P5
Fig 1. Block Diagram of the P5CD080V0B (grey areas are different for the configurations)
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 8 of 72
There are differences in the configurations, indicated in grey in the figure. Refer t
section
o
2.2 for information about the configurations. The following tables list the TOE
s.
he
component
TOE components
Table 1. Components of t TOE
Type Name Release Date Form of delivery
Hardware NXP P5CD080V0B Secure
ntro
V0B T 060904 Wafer, modules
and package (dice
include reference
T035B)
Softw est ROM Software (the IC
Softw )
63 Nov 29 , 2006 Test ROM on the
chip (tmfos_63.lst)
Smart Card Co ller
035B_20
(GDS 2 File)
are T
Dedicated Test are
th
Softw ftware (part of
edicated Support
63 Test ROM on the
chip (tmfos_63.lst)
are Boot ROM So
the IC D
Software)
Nov 29
th
, 2006
Softw MIFARE Operating System
of the IC Ded d
ort Software)
2.0 Aug 24 , 2006 Test ROM on the
chip (tmfos_63.lst)
are
(part
Supp
icate
th
Docu She
73/080/1
010 Electronic
document
ment Product Data
P5Cx012/02x/040/0
4 family
et,
4
3.7 June 4th, 2
Docum 1.1 July 04th, 2006 Electronic
document
ent Instruction Set
Document Guidance, Delivery and
Operation Manual for the
12/02x/040/073/080/14
1.8 February 15th,
2010
Electronic
document
P5Cx0
4V0B family of Secure Smart
Card Controllers
Note that there are no differences between the major configuration options with regard to
2.1.1 are Description
set that is
cases the second
guishes
between five different CPU modes, displayed in the following table.
Table 2. Different CPU modes of the TOE
the TOE components.
Hardw
The CPU of the P5CD080V0B has an 8-bit architecture with an instruction
extended from the 80C51 family instruction set. The first and in some
byte of an instruction are used for operation encoding. The P5CD080V0B distin
Super System Mode
Boot Mode Test Mode Mifare Mode System Mode User Mode
As shown in the table the three modes Boot Mode, Test Mode and Mifare Mode are sub-
modes of the so-called Super System Mode. These three modes are not available for the
Smartcard Embedded Software developer, they are reserved for the three software
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 9 of 72
components that belong to the TOE (refer to the beginning of sectio
of modes and software components is one-to-one: In Boot Mode the TOE executes the
n 2.1). The mapping
Software and in
that the Super
E is in Super System Mode, it is
n the settings of an
are.
he hardware
d specific Special
Mode software can
e components are
on Registers. These
anagement unit,
ontact-less interface and
be performed through
e, the contact-less
owever the major
43 and the
tion. The
n the following.
rt of Smartcard
pecific fixed vector address the
stem Mode or the User
ctors (CVEC) and 32
e Mifare Mode and
xplicitly called by
d separates
ther.
PROM (80 kByte)
access control is enforced for all three memory types by a memory
very memory in two
est-ROM. The
for the
MIFARE
ion, either 0 and
size is displayed as 200 kByte in
the block diagram (Fig 1) because only 200 kBytes are available for the Smartcard
Embedded Software.
In Test Mode the CPU has unrestricted access to the whole memory. In Boot Mode and
Mifare Mode access is limited to the Test-ROM and the smaller parts of the EEPROM (0,
1, 4 kByte plus 128 Byte) and RAM (0 or 128 Byte). In System Mode and User Mode the
respective other parts are accessible, namely the Application-ROM and the larger parts
of EEPROM and RAM. The User Mode is further restricted by the memory management
unit, which can be configured in System Mode.
Boot ROM Software, in Test Mode the TOE executes the Test ROM
Mifare Mode the TOE executes the MIFARE Operating System. Note
System Mode is not a mode on its own: When the TO
always either in Boot Mode, Test Mode or Mifare Mode, depending o
internal register not available for the Smartcard Embedded Softw
Available for the developer of the Smartcard Embedded Software are the System Mode
and the User Mode. The System Mode provides unlimited access to t
components. In the User Mode the access is restricted to the CPU an
Function Registers. Access rights to hardware components for User
be granted by software running in System Mode. The on-chip hardwar
controlled by the Smartcard Embedded Software via Special Functi
registers are correlated to the activities of the CPU, the memory m
interrupt control, I/O configuration, EEPROM, timers, UART, c
the co-processors. The communication with the P5CD080V0B can
an UART or the direct usage of the I/O ports for the contact interfac
communication is done with the contact-less interface unit (CIU), h
configuration P5CD080V0B is compatible with MIFARE and ISO 144
configuration P5CN080V0B is compatible with Near Field Communica
P5CD080V0B provides two different types of interrupts: (i) exception interrupts, called
“exception” in the following and (ii) event interrupts, called “interrupts” i
These interrupts force the jump to specific fixed vector addresses in the ROM. Every
different interrupt can therefore be controlled and guided by a specific pa
Embedded Software. In conjunction with the jump to a s
hardware always enables a pre-defined CPU mode, either the Sy
Mode. In addition the TOE provides 8 so-called configuration ve
system call vectors (SVEC), of which the configuration vectors force th
the system call vectors the System Mode. These vectors have to be e
the Smartcard Embedded Software. Special on-chip hardware protects an
every mode, especially the Boot Mode and Test Mode, from each o
The device includes ROM (224 kByte), RAM (6144 Byte) and EE
memory. The
management unit (MMU). The memory management unit partitions e
parts: The ROM is split in 200 kByte Application-ROM and 24 kByte T
EEPROM is split depending on the configuration, 128 Bytes are always reserved
manufacturer and either 0, 1 or 4 kBytes are additionally reserved for the
Operating System. The RAM is also split depending on the configurat
6144 or 128 and 6016 Bytes size. Note that the ROM
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 10 of 72
Note that the RAM is also furthermore split in two parts 3584 Bytes g
RAM and 2560 Bytes FameXE RAM. The whole RAM is accessible fo
FameXE co-processor can only access the FameXE RAM. The Fame
RAM part without control (with regard to access rights) by the m
Since the MMU does not control accesses of the FameXE, software
the FameXE implicitly has access to this part of the RAM. This ho
eneral purpose
r the CPU, but the
XE can access its
emory management unit.
which has access to
lds also for the
EEPROM: FameXE accesses to the EEPROM are not controlled by the MMU, software
of the EEPROM.
.
ns. Only
co-processor support AES operation with three different key lengths. The FameXE co-
ric crypto algorithms
enerator provides
The P5CD080V0B operates with a single 1.8V, 3V or 5V nominal power supply. The
ontroller can be
time for security
activity: the IDLE
ode.
the secret data stored in and operated by the TOE against physical
ed Software
curity functionality
n the TOE security
bedded Software.
2.
y the customers
. The Smartcard
EEPROM and is not
usage of the
OM of the TOE is
o test the functionality of the chip. The
ard by disabling the
is developed by
mbedded in the Test-ROM. The IC Dedicated Test Software includes the
test operating system, test routines for the various blocks of the circuitry, control flags for
the status of the EEPROM’s security row and shutdown functions to ensure that security
relevant test operations cannot be executed illegally after phase 3.
The TOE also contains IC Dedicated Support Software which is also stored in the Test-
ROM. The IC Dedicated Support Software consists of two parts:
• The Boot ROM Software: This software is executed after each reset of the TOE, i.e.
every time when the TOE starts. It sets up the TOE and does some basic
configuration.
which has access to the FameXE implicitly has access to this part
However, the separation into parts is enforced also for the FameXE
The Triple-DES co-processor supports single DES and Triple-DES operatio
Triple-DES will be used in this evaluation, either in 2-key or 3-key operation. The AES
processor supplies basic arithmetic functions to perform asymmet
implemented by the Smartcard Embedded Software. The random g
true random numbers without pseudo random calculation.
nominal maximum external clock frequency is 10 MHz. The micro c
operated with the internal clock especially to decrease the calculation
algorithms. The controller provides power saving modes with reduced
Mode and the SLEEP Mode, which includes the CLOCK STOP M
The TOE protects
tampering. Within the composition of this TOE (with Smartcard Embedd
comprising the operating system and the smart card application) the se
is only partly provided by the TOE and causes dependencies betwee
functions and the functions on top provided by the Smartcard Em
1.2 Software Description
The smart card operating system and the application are developed b
and they are called Smartcard Embedded Software in the following
Embedded Software is stored in the Application-ROM and/or in the
part of the TOE. The Smartcard Embedded Software depends on the
smartcard.
The IC Dedicated Test Software (Test ROM Software) in the Test-R
used by the TOE Manufacturer of the smartcard t
test functionality is disabled before the operational use of the smart c
Test Mode of the CPU by hardware. The IC Dedicated Test Software
Philips and e
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 11 of 72
• The MIFARE Operating System: This software provides MIFARE functio
ard Embedded Software. The MIFARE Operat
nality to the
ing System provides support for
less communication. Please refer to [24] for more information.
2.
It contains a functional
ecurity features.
arate document [10]. Additional
spects of the program interface and the use of programming
prove the security [11]. The provided documentation can be used by the
2.
power supply, reset
und, serial communication pads I/O1, I/O2 and I/O3 as well as two
ontact-less interface unit. Note that in the
r the connection to a
also called SIGIN
s executed which provides no interface.
) the logical
e IC Dedicated Test
operating system and
In the Mifare Mode the the CPU – only on
re
• In e software interface
is gisters that are related to
these mo dress map of the CPU including memories. The
ries depends on the
Note: The logical interface of the TOE that is visible on the electrical interface
and authentication
of the user for the different CPU modes must be controlled by the
Smartcard Embedded Software.
The chip surface can be seen as an interface of the TOE, too. This interface must be
taken into account regarding environmental stress e.g. like temperature and in the case
of an attack where the attacker manipulates the chip surface.
Note: An external voltage and timing supply as well as a data interface are
necessary for the operation of the TOE. Beyond the physical behaviour the
data interface is defined by the Smartcard Embedded Software.
Smartc
contact-
1.3 Documentation
The Data Sheet [9] of the P5CD080V0B is also part of the TOE.
description needed to develop software and guidelines for the use of s
The instruction set of the TOE is described in a sep
Guidance describe a
techniques to im
software developer to develop the Smartcard Embedded Software.
1.4 Interface of the TOE
The electrical interface of the TOE are the pads to connect the lines
input, clock input, gro
pads (called LA and LB) for the antenna of the c
major configuration P5CN080V0B the pads I/O3 and LB are used fo
helper IC for Near Field Communication. In this configuration I/O3 is
and LB is also called SIGOUT.
The software interface of the TOE depends on the CPU mode:
• In the Boot Mode the Boot ROM Software i
There is no possibility to interact with this software.
• In the Test Mode (used after production before delivery of the TOE
interface that is visible on the electrical interface is defined by th
Software. This IC Dedicated Test Software comprises the test
the package of test function calls stored in the Test-ROM.
• MIFARE Operating System is executed by
quest by the Smartcard Embedded Software.
the System Mode and User Mode (used after TOE Delivery) th
the set of instructions, the bits in the special function re
des and the physical ad
access to the special function registers as well as to the memo
CPU mode configured by the Smartcard Embedded Software.
after TOE Delivery is based on the Smartcard Embedded Software
developed by the software developer. The identification
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 12 of 72
2.
ted in a credit card sized
r sealed package.
to applications and multiple
rd applications will be
sms
E for physical
t the end of phase 3 in
IC Dedicated
section 2.1.2.
ogical phases. After production of the chip every
to the Test Mode and the execution of the IC Dedicated Test Software.
. With disabled Test
e CPU executing the
2.
the Smartcard
e product in this
ed in an unsecured
s, and is designed for
ontactless applications.
the smartcard may
nvironment.
store and process secrets of several systems that must be
protected from each other. So the TOE must meet security requirements to be applied to
security modules. The secret data shall be used as input for the calculation of
authentication data, the calculation of signatures and the encryption of data and keys.
The software developer and the system integrators such as the terminal software
developer may use samples of the TOE during the development phases for their testing
purposes. It is not intended that they are able to change the behaviour of the smartcard
in another way than an end-user.
1.5 Life Cycle and Delivery of the TOE
For the usage phase the P5CD080V0B chip will be implemen
plastic card (micro-module embedded into the plastic card) or anothe
The chip provides a hardware computing platform
applications executed by a smart card operating system. Smart ca
used to store secret data and calculate cryptographic functions.
The module and card embedding of the TOE provide external security mechani
because they make it harder for an attacker to access parts of the TO
manipulation.
Regarding the Application Note 4 of [7] NXP will deliver the TOE a
form of wafers or at the end of phase 4 in packaged form.
Regarding the Application Note 5 of [7] NXP will deliver the TOE with
Support Software. The IC Dedicated Support Software is described in
The TOE is able to control two different l
start-up will lead
At the end of the production test the chip the Test Mode is disabled
Mode every start-up of the chip will lead to the System Mode with th
Smartcard Embedded Software.
1.6 TOE Intended Usage
Regarding to phase 7, the combination of the smartcard hardware and
Embedded Software is used by the end-user. The method of use of th
phase depends on the application. The TOE is intended to be us
environment that does not avoid a threat.
The device is developed for most high-end safeguarded application
embedding into chip cards according to ISO 7816 [19] and for c
Usually the smart card is assigned to a single individual only although
be expected to be used for multiple applications in a multi-provider e
Therefore the TOE may
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 13 of 72
2.
The TOE user environment is the environment from TOE Delivery to phase 7. At the
nvironment.
ide range of
ch are Pay-TV,
s, Health cards, Transportation cards.
The e different functions,
thus m
Note: ard life cycle are
f this Security
out those phases are just included to describe how
used after its construction. Nevertheless the security features of
rd IC hardware that are independent of the software are active
ery and cannot be disabled by the Smartcard Embedded
n the phases afterwards.
correct operation in the specified range
, AES co-processor)
large integer numbers (FameXE co-processor for the
s)
ns
ct names. The
interfaces: The P5CD080V0B is equipped with the ISO
N080V0B differs in the
cation. The
nabled, the
d EEPROM size.
n.
Common minor configuration options of all configurations are described in section 2.2.5.
2.2.1 Major configuration P5CD080V0B
The P5CD080V0B supports all minor configuration options presented in subsection
2.2.5. The major differences between the configurations are as follows:
• The contact-less interface is enabled and configured for contact-less communication
according to ISO14443 [21], [22].
• All three I/O pads can be used for contact communication.
1.7 TOE User Environment
phases up to 6, the TOE user environment must be a controlled e
In the end-user environment (phase 7) Smartcard ICs are used in a w
applications to assure authorized conditional access. Examples of su
Banking Cards, Portable communication SIM card
nd-user environment therefore covers a wide spectrum of very
aking it difficult to avoid and monitor any abuse of the TOE.
The phases from TOE Delivery to phase 7 of the smart c
not part of the TOE construction process in the sense o
Target. Information ab
the TOE is
the Smartca
at TOE Deliv
Software i
2.1.8 General IT features of the TOE
The TOE IT functionality consists of:
rage
• tamper resistant data sto
• control of operation conditions to provide
• basic cryptographic functions (Triple-DES co-processor
• basic arithmetic functions for
calculation of public key and elliptic curve cryptography algorithm
• physical random number generator
• memory management to separate different applications
• data communication via three different interfaces
2.2 Evaluated hardware configuratio
There are four major configuration options, denoted by different produ
products differ in the available
7816 interface and the ISO 14443 contact-less interface. The P5C
configuration of the contact-less interface for Near Field Communi
P5CC080V0B and P5CC073V0B do have only the ISO 7816 interface e
contact-less interface is disabled, and the P5CC073V0B has a reduce
Details are described in the subsections of this sectio
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 14 of 72
2.
The P5CN080V0B supports all minor configuration options presented in subsection
s:
is a special mode in
cted to IO3/SIGIN
le
n antenna is
lper IC and can not be
ted in subsection
s:
munication via the
that the TOE gets powered in an
sed by the TOE,
uted. This applies
ation features
in effective.
sed for contact communication.
RE Emulation and the
er to section 2.2.5) do not have any
rating
minor configuration options presented in subsection
s:
munication via the
that the TOE gets powered in an
sed by the TOE,
uted. This applies
tion features
in effective.
• The available EEPROM memory space for the Smartcard Embedded Software is
reduced to 72 kBytes – minus the reserved areas Security Row (128 Bytes) and
configuration data (128 Bytes).
• All three I/O pads can be used for contact communication.
Note that the minor configuration options with regard to the MIFARE Emulation and the
further MIFARE and contact-less related options (refer to section 2.2.5) do not have any
effect in this configuration, since the contactless interface and the MIFARE Operating
System are disabled in the P5CC073V0B.
2.2 Major configuration P5CN080V0B
2.2.5. The major differences between the configurations are as follow
• The contact-less interface is configured in the S²C mode, which
which the TOE can be used (with an additional helper IC conne
and LB/SIGOUT) for Near Field Communication (NFC) [23]. However, it is possib
that the TOE gets powered in an appropriate electrical field when a
connected to LA and LB.
• The I/O3 pad is used as communication line with the NFC he
used for contact communication according to ISO 7816.
2.2.3 Major configuration P5CC080V0B
The P5CC080V0B supports all minor configuration options presen
2.2.5. The major differences between the configurations are as follow
• The contact-less interface is disabled, which means that no com
interface is possible. However, it is possible
appropriate electrical field. Furthermore CVEC calls are suppres
which means that the MIFARE Operating System cannot be exec
to the functionality of the MIFARE Operating System, the separ
provided by the MMU rema
• All three I/O pads can be u
Note that the minor configuration options with regard to the MIFA
further MIFARE and contact-less related options (ref
effect in this configuration, since the contact-less interface and the MIFARE Ope
System are disabled in the P5CC080V0B.
2.2.4 Major configuration P5CC073V0B
The P5CC073V0B supports all
2.2.5. The major difference between the configurations is as follow
• The contact-less interface is disabled, which means that no com
interface is possible. However, it is possible
appropriate electrical field. Furthermore CVEC calls are suppres
which means that the MIFARE Operating System cannot be exec
to the functionality of the MIFARE Operating System, the separa
provided by the MMU rema
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 15 of 72
2.
All major configurations provide different configurations. The following options can be
. E inor
2.5 Common minor configuration options
selected by the customer:
Table 3 valuated m configuration options
Name Values Description
EDATASCA 10h to D f the memory area
pointer. Refer to
Card Disable Yes or Card Disable Function is enabled, the TOE
e set by the Smartcard
artcard
Embedded Software is inhibited after the next reset.
Refer to section 29.5 of [9].
LE 0h This value determines the size o
available for the extended stack
section 10.5 of [9].
No When the
Function can be locked completely. Onc
Embedded Software, the execution of the Sm
Block ROM
instructions
executed from
M
Yes or ROM are allowed or
0.1.1.9
of [9].
read
EEPRO
No Instructions executed from EEP
not to read ROM contents. Refer to section 1
Inverse EEPROM
Error Correction
Yes or tivated the detection
probability of fault injections to the EEPROM can be
.9 of [9].
No If inverse error correction is ac
increased. Refer to section 10.9
128 Byte Pa
Mode
ge Yes or ytes of
simultaneously,
fer to section 10.9.1 of
No In the 128 Byte Page Mode up to 128 B
EEPROM can be programmed
instead of up to 64 Bytes. Re
[9].
MIFARE Em or B4 Different MIFARE configurations, refer to chapter 21
of [9].
ulation A, B1
UID in MIFARE
ion A
le or Double The size of the UID can be 4 bytes (Single UID) or 7
o section 11.1.1 of [9].
Emulat
Sing
bytes (Double UID). Refer t
Contact-less
communication
(i) “Proprietary”, (ii)
“Proprietary,
Refer to section 21 of [9].
protocol compliant to ISO
14443-3”, and (iii)
“T=CL, compliant to
ISO 14443-3/-4”
Maximum CIU
Baudrate
106, 212, 424 or
848 KBaud
Defines the maximum available baudrate of the
contact-less interface. Refer to section 21 of [9].
The values of all options listed in Table 3 can be freely chosen.
The Order Entry Forms ([12], [13], [14] and [15]) list a further option which must be
selected with a fixed value:
• The option “Allow execution from RAM” must be selected with “No”.
• The option “Extended Voltage Class B activated” must be selected with “No”.
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 16 of 72
2.
rview about the major configuration options:
. ns overview
2.6 Configuration summary
The following table provides an ove
Table 4 Major configuration optio
TOE contact-less interface I/O pads for ISO 7816 EEPROM
P5CD080 enabled, configured for ISO 14443 3 80 kBytes
80 enabled, configured for NFC 2 80 kBytes
V0B
P5CN0 V0B
P5CC080V0B disabled 3 80 kBytes
P5CC073V0B disabled 3 72 kBytes
2.3 Evaluated package types
pported for the TOE. Each package type has a
commercial type name for the TOE has the following
0B
• P5CC073pp/T0Brrffz for the P5CC080V0B
ending on the package type - indicated by the
ria and the Smartcard Embedded Software. - indicated by the variables “rr”,
“ff” a
The wing definition:
Table
A number of package types are su
different commercial type name. A
format:
• P5CD080pp/T0Brrffz for the P5CD080V0B
• P5CN080pp/T0Brrffz for the P5CN080V0B
• P5CC080pp/T0Brrffz for the P5CC080V
The commercial type name is different dep
va ble “pp” –
nd “z”.
variables have the follo
5. Variable definitions for commercial type names
Variable Definition
pp ntifier for the package type, e.g. “UA” for a sawn wafer of
e different package types
number, different for every Smartcard Embedded Software
This is a two character ide
150µm thickness which electronically marked defects. Th
are defined in the next table.
rr ROM code
ff Fabkey number, for each Smartcard Embedded Software multiple Fabkeys are
supported
z Mifare Configuration (0=A, 1=B1, 4=B4)
The following package types are supported in this Security Target. For each major
configuration (the first four columns) the two characters in the table cells are the package
identifier. If a cell is empty the respective major configuration/package combination is not
supported in this Security Target.
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 17 of 72
Table 6. por package types
Sup ted
P5CD080V0B
P5CN080V0B
P5CC080V0B
P5CC073V0B
U A s
U4 sawn wafer, inkless
A UA U UA 150µm sawn wafer, inkles
150µm un
U3 3 , inkless
U3 U 150µm unsawn wafer on sticky tape
UE sawn wafer, inkless
75µm
Xn Xn
le, n= [0…9, A---Z], identify different modules,
able delivery types can be found in the Data Sheet
Xn
Modu
avail
A4 MOB4 module
A6 MOB6 module
TS SSOP20 package
Ai Inlay (index i contains capital character [A-Z])
For example, the commercial type name “P5CC080TS/T0Brrffz” deno
in a SSOP20 package and “P5CD080UA/T0Brrffz” denotes a P5CD08
sawn wafer inkless, which means that the defect IC are electronicall
there is no cell “A4” for the P5CC080V0B, the commercial type “P5C
tes a P5CC080V0B
0V0B on a 150µm
y marked. Since
C080A4/T0Brrffz” is
ot influence the security functionality of the TOE. It does only
e the chip (with the
is not dependent on
roduct can be
onnection himself.
For all package types listed above the security during development and production is
name is dependent
uence this means
bed in Table 6
determines that the hardware is an evaluated product, however this gives no conclusion
on the software and if the software does use the proper hardware configuration as
described by section 2.2.5.
2.4 Further Definitions and Explanations
Since the Security Target claims conformance to the PP “Smartcard IC Platform
Protection Profile”, the concepts are used in the same sense. For the definition of terms
refer to the Protection Profile [7]. This chapter does not need any supplement in the
Security Target.
not part of this evaluation.
The package type does n
define which pads are connected in the package and for what purpos
appropriate package) can be used. Note that the security of the TOE
which pad is connected or not – the connections just define how the p
used. If the TOE is delivered as wafer the customer can choose the c
ensured (refer to section 1.2.2).
As already described above the complete resulting commercial type
on the customer software (Smartcard Embedded Software). In conseq
that a full commercial product name that fits in the variable forms descri
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 18 of 72
3. TOE Security Environment
This Security Target claims conformance to the Smartcard IC Pla
The Assets, Assumptions, Threats and Organisational Security Po
taken fr
tform Protection Profile.
licies are completely
om the Protection Profile. In the following only the extension of the different
s of the sections that are not extended are cited here for
claims conformance to the PP “Smartcard IC Platform
1 of the Protection Profile are
n this Security Target.
ta, physical design data, IC Dedicated Software,
e-personalization Data, specific development aids, test and
t support, and photo
ard Embedded Software
cial functions for the communication with an external interface device, the
yptographic co-processor for AES,
the FameXE co-processor for basic arithmetic functions to perform asymmetric and
urve cryptographic algorithms, the random number generator
s for the cryptographic co-processors are seen as User Data.
3 ssumptio
is Sec artcard IC Platform
ection Pro s defined in section 3.2 of the Protection Profile are
valid for this Security Target. The following table lists the assumptions of the Protection
.
Table 7. Assumptions defined in the Protection Profile
sections are listed. The title
completeness.
3.1 Description of Assets
Since this Security Target
Protection Profile” [7], the assets defined in section 3.
applied and the assets regarding threats are clarified i
The assets regarding the threats are:
• logical design da
• Initialisation Data and Pr
characterization related data, material for software developmen
masks
• the TOE correct operation
• the Smartc
• the spe
cryptographic co-processor for Triple-DES, the cr
elliptic c
• the User Data and
• the TSF Data.
The key
.2 A ns
Since th urity Target claims conformance to the PP “Sm
Prot file” [7], the assumption
Profile
Name Title
A.Process-Card Protection during Packaging, Finishing and Personalisation
A.Plat-Appl Usage of Hardware Platform
A.Resp-Appl Treatment of User Data
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 19 of 72
The fo ditional assumptions are considered in this Secu
llowing ad rity Target.
A.Check-Init Check of initialisation data by the Smartcard Embedded
rovide a function
customer and injected by the TOE Manufacturer into the non-
[7] related to the
ion hardware of the TOE (refer to the augmentation paper [8]).
eloper o tware must ensure the appropriate
“Usage of Key-d ing this software in
Phase 1 as spec
A.Key-Function unctions
plemented in the
that they are not
bed under
Note that here the routines which may compromise keys when
being executed are part of the Smartcard Embedded
ats T.Leak-Inherent and
c routines which
cessing of User Data
including cryptographic keys.
3.3 Threats
Since this Security Target claims conformance to the PP “Smartcard IC Platform
on Pro reats defined in section 3.3 of the Protection Profile are valid
Securi s the threats defined by the PP:
. Thre ction Profile
Software
The Smartcard Embedded Software must p
to check initialisation data. The data is defined by the
volatile memory to provide the possibility for TOE identification
and for traceability.
The following assumption considers the Application Notes 8 and 9 of
specialized encrypt
The dev f the Smartcard Embedded Sof
ependent Functions (A.Key-Function)” while develop
ified below.
Usage of Key-dependent F
Key-dependent functions (if any) shall be im
Smartcard Embedded Software in a way
susceptible to leakage attacks (as descri
T.Leak-Inherent and T.Leak-Forced).
Software. In contrast to this the thre
T.Leak-Forced address (i) the cryptographi
are part of the TOE and (ii) the pro
Protecti file” [7], the th
for this ty Target. The following table list
Table 8 ats defined by the Prote
Name Title
T.Leak-Inheren on Leakage
T.Phys-Probing Physical Probing
t Inherent Informati
T.Malfunction Malfunction due to Environmental Stress
T.Phys-Manipulation Physical Manipulation
T.Leak-Forced Forced Information Leakage
T.Abuse-Func Abuse of Functionality
T.RND Deficiency of Random Numbers
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 20 of 72
Considering the Application Notes 10 and 11 of [7] there are no additional high-level
ew threats defined in this Security Target.
to the PP “Smartcard IC Platform
TOE Development
d by the Smartcard
curity functionality is listed which is not
it can only be decided
, against which threats the Smartcard
ctionality.
The IC Develope al Specific Security
Components (P.
P.Add-Co ents
g additional security
tionality to the Smartcard Embedded Software:
ding on the
rocessor in the major
ware parts (including IC
bedded Software)
• Special Function Register Access Control.
• Protection of configuration data. The TOE prevents
modification of configuration data – including configuration
data for TSF – after TOE delivery. This can be used to
enable or disable specific blocks on the TOE.
Regarding the Application Note 12 of [7] there are no other additional policies defined in
this Security Target.
security concerns or additional n
3.4 Organisational Security Policies
Since this Security Target claims conformance
Protection Profile” [7], the policy P.Process-TOE “Protection during
and Production” of the Protection Profile is applied here also.
The TOE provides specific security functionality which can be use
Embedded Software. In the following specific se
derived from threats identified for the TOE’s environment because
in the context of the smartcard application
Embedded Software will use the specific security fun
r / Manufacturer must apply the policy “Addition
Add-Components)” as specified below.
mpone ts Additional Specific Security Compon
n
The TOE shall provide the followin
func
• Triple DES encryption and decryption
• AES encryption and decryption, depen
availability of the AES co-p
configuration
• Area based Memory Access Control
• Memory separation for different soft
Dedicated Software and Smartcard Em
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 21 of 72
4. Security Objectives
This chapter contains the following sections: “Security Objectives for the TOE” and
vironment”.
e TOE
g security objectives, taken from the Protection Profile
[7]:
Sec
“Security Objectives for the En
4.1 Security Objectives for th
The TOE shall provide the followin
Smartcard IC Platform Protection Profile
Table 9. urity objectives defined in the PP
Name Title
O.Leak-Inherent Protection against Inherent Information Leakage
-Probing obing
O.Phys Protection against Physical Pr
O.Malfunction ctions
Protection against Malfun
O.Phys-Manipu ction against Physical Manipulation
lation Prote
O.Leak-Forced tion against Forced Information Leakage
Protec
O.Abuse-Func Protection against Abuse of Functionality
O.Identification TOE Identification
O.RND Random Numbers
Regarding the A dditional security
objectives are de the TOE as specified
below.
O.HW_DES3
cryptographic functionality to
DES encryption and decryption to the
TOE supports directly
ree keys.
nfidentiality of the User Data
Triple DES
Inherent.
O.HW_AES AES Functionality
The TOE shall provide the cryptographic functionality to
calculate a AES encryption and decryption to the Smartcard
Embedded Software. The TOE supports directly the
calculation of AES with three different key lengths.
Note: The TOE will ensure the confidentiality of the User Data
(and especially cryptographic keys) during AES operation.
This is supported by O.Leak-Inherent.
pplication Notes 13 and 14 of [7] the following a
fined based on additional functionality provided by
Triple DES Functionality
The TOE shall provide the
calculate a Triple
Smartcard Embedded Software. The
the calculation of Triple DES with up to th
Note: The TOE will ensure the co
(and especially cryptographic keys) during
operation. This is supported by O.Leak-
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 22 of 72
O.MF_FW
etween the “MIFARE
ed Support Software and the
Software. The separation shall
comprise software execution and data access.
O.MEM_ACCES
areas is
based on the CPU
r
uration of the Memory Management
to the memory
ction is allowed.
O.SFR_ACCESS ol
all provide access control to the Special Function
al Function
ted to the memory
cuting code. The
access control is used to restrict access to hardware
e TOE.
ons to specialized
be restricted to code
O.CONFIG Protection of configuration data
configuration data –
ery.
More specifically it shall be ensured that the configuration
the test phase are fixed after TOE
delivery.
4.2 y Objectives for the Environment
t e s for the
en
Table 10. S s for the envir taken from the PP
MIFARE Firewall
The TOE shall provide separation b
Operating System” IC Dedicat
Smartcard Embedded
S Area based Memory Access Control
Access by processor instructions to memory
controlled by the TOE. The TOE decides
mode (Boot Mode, Test Mode, Mifare Mode, System Mode o
User Mode) and the config
Unit (MMU) if the requested type of access
area addressed by the operands in the instru
Special Function Register Access Contr
The TOE sh
Registers depending on the purpose of the Speci
Register or based on permissions associa
area from which the CPU is currently exe
components of th
The possibility to define access permissi
hardware components of the TOE shall
running in System Mode.
The TOE prevents modification of
including configuration data for TSF – after TOE deliv
values determined during
Securit
According
environm
o the Protection Profile [7], th
t are specified:
following security objective
ecurity objective onment,
Security objective Description Applies to phase...
OE.Plat-Appl Usage of Hardware Platform Phase 1
OE.Resp-Appl Treatment of User Data Phase 1
OE.Process-TOE Protection during TOE Development
and Production
Phase 2 up to the TOE Delivery at
the end of phase 3
OE.Process-Card Protection during Packaging, Finishing
and Personalisation
Begin of phase 4 up to the end of
phase 6
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 23 of 72
Clarification of “Usage of Hardware Platform (OE.Plat-Appl)”
The TOE supports cipher schemes as additional specific security
the Smartcard Embedded Software shall use these cryptographic
and their interface as specified. When key-dependent functions im
Smartcard Embedded Software are just being executed, the Smar
Software must provide protection against disclosure of confidential
functionality. If required
services of the TOE
plemented in the
tcard Embedded
data (User Data)
stored and/or processed in the TOE by using the methods described under “Inherent
eakage (T.Leak-
sures, cryptographic
se)
st be tested appropriately.
d Software (Operating System) can
features of the TOE to
ser Data. The
se only proper
aphic function of the
strength of
are treated as confidential as soon as they are generated. The
phically strong. For
t is not possible to
efined in this Security
m other keys, quality and
be maintained. This implies that appropriate key management has to
operating system is
implemented as part of the Smartcard Embedded Software on the TOE. In this case the
plication ant user data of one
an the TOE.
Check of initial
The TOE provide s the TOE
Manufacturer to of the TOE. Therefore,
OE.Check-Init is ow a TOE specific implementation (refer also to A.Check-
Init).
OE.Check-Init Check of initialisation data by the Smartcard Embedded
Software
To ensure the receipt of the correct TOE, the Smartcard
Embedded Software shall check a sufficient part of the pre-
personalization data. This shall include at least the FabKey
Data that is agreed between the customer and the TOE
Manufacturer.
Information Leakage (T.Leak-Inherent)” and “Forced Information L
Forced)“.
If the random number generator is used for leakage countermea
operations (e.g. key generation) or cryptographic protocols (e.g. challenge respon
these random numbers mu
For multi-applications the Smartcard Embedde
implement a memory management scheme based upon security
ensure the separation of applications.
Clarification of “Treatment of User Data (OE.Resp-Appl)”
By definition cipher or plain text data and cryptographic keys are U
Smartcard Embedded Software shall treat these data appropriately, u
secret keys (chosen from a large key space) as input for the cryptogr
TOE and use keys and functions appropriately in order to ensure the
cryptographic operation.
This means that keys
keys must be unique with a very high probability, as well as cryptogra
example, if asymmetric algorithms are used, it must be ensured that i
derive the private key from a related public key using the attacks d
Target. If keys are imported into the TOE and/or derived fro
confidentiality must
be realized in the environment.
The treatment of User Data is also required when a multi-application
multi-ap operating system will not disclose security relev
application to other application when it is processed or stored on
isation data
s specific support for OE.Process-TOE that require
implement measures for the unique identification
defined to all
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 24 of 72
5. IT Security Requirements
5.1 TOE Security Requirements
This section consists of the subsections “TOE Security Functional Requirements”, “TOE
” and “Refinements of the TOE Security Assurance
5.1.1
derstanding of the combination Protection Profile vs. Security
ctions.
5.1
Table 11 below shows all SFRs which are specified in the Protection Profile Smartcard
rofile [7] (in the order of definition in the PP). Some of the SFRs
are CC Part ended and defined in the Protectio is is shown in the third
n of th
Table 11. SFRs taken from the PP
Security Assurance Requirements
Requirements”.
TOE Security Functional Requirements
To support a better un
Target, the TOE SFRs are presented in the following two different se
.1.1 SFRs of the Protection Profile
IC Platform Protection P
2 ext n Profile. Th
colum e table.
SFR Title Defined in ...
FAU_SAS.1 Audit storage PP, Section 8.6
_RND.1 andom number PP, Section 8.4
FCS Quality metric for r s
FDP_IFC.1 ntrol CC, Part 2
Subset information flow co
FDP_ITT.1 ection CC, Part 2
Basic internal transfer prot
FMT_LIM.1 ities PP, Section 8.5
Limited capabil
FMT_LIM.2 Limited availability PP, Section 8.5
FPT_FLS.1 Failure with preservation of secure state CC, Part 2
FPT_ITT.1 Basic internal TSF data transfer protection CC, Part 2
FPT_PHP.3 Resistance to physical attack CC, Part 2
FPT_SEP.1[PP] TSF domain separation CC, Part 2
FRU_FLT.2 Limited fault tolerance CC, Part 2
Note that the SFR FPT_SEP.1 from the PP is iterated to FPT_SEP.1[PP] to distinguish it
from the SFR that will be defined in section 5.1.1.2. The operation just renames the SFR.
With one exception, all assignment and selection operation re performed. The
exception is the left open definition of a quality metric for the random numbers required
by FCS_RND.1. This assignment operation is filled in by the following statement:
s a
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 25 of 72
FCS_RN Quality metric for random numbers
The TSF shall p
D.1
FCS_RND.1.1 rovide a mechanism to generate random
the requirement to provide an entropy of at
each byte 1
.
Dependencies: es.
Note: The ent th easured by the
Shannon-Entropy as follows:
the probability that the
is equal as binary number. Here
Entropy.
The value “7.976” is assigned due to the requirements of
selection operations are performed. This Security Target does not
file.
ering the Application Note 15 of [7] in the following paragraphs the additional
. These SFRs are not
dditional generation of audit is not defined
n of secure state”
dditional requirement is defined for the
n chapter 3.2.
5.1 nal SFRs
The (DES co-pro yptographic operation
(FCS_COP.1[DE
FCS_COP.1[DES] Cr
Hierarchical to:
all perform encryption and decryption
2
in
ce with a specified cryptographic algorithm Triple
Data Encryption Algorithm (TDEA) 3
and cryptographic key
sizes of 112 or 168 bit 4
that meet the following list of
standards 5
:
FIPS PUB 46-3 FEDERAL INFORMATION PROCESSING
STANDARDS PUBLICATION DATA ENCRYPTION
numbers that meet
least 7.976 bit in
No dependenci
ropy of e random number is m
∑ ⋅
−
=
255
log p
p
E , where p is
=0
2
i
i
i i
byte )
,
,
,
( 0
6
7 b
b
b K to i
term “bit” means measure of the Shannon-
AIS31, [5].
By this, all assignment/
perform any other/further operations than stated in the Protection Pro
Consid
functions for cryptographic support and access control are defined
required in the Protection Profile.
Regarding the Application Note 16 of [7] an a
for “Limited fault tolerance” (FRU_FLT.2) and “Failure with preservatio
(FPT_FLS.1).
Considering the Application Note 17 of [7] no a
TOE itself but refer to “A.Check-Init” i
.1.2 Additio regarding cryptographic functionality
cessor of the) TOE shall meet the requirement “Cr
S])” as specified below.
yptographic operation
No other components.
FCS_COP.1.1 The TSF sh
accordan
1
[assignment: a defined quality metric]
2
[assignment: list of cryptographic operations]
3
[assignment: cryptographic algorithm]
4
[assignment: cryptographic key sizes]
5
[assignment: list of standards]
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 26 of 72
STANDARD (DES) Reaffirmed 1999 October 25, keying
Dependencies: ata without security attributes or
ata with security attributes, or
c key generation],
,
T_MSA.2 Secure security attributes.
t the requirement “Cryptographic operation
ow.
Hierarchical to:
FCS_COP.1.1 encryption and decryption 6
in
orithm
gorithm 7
and
r 256 bit 8
that meet the
ndards 9
:
ON PROCESSING
N, ADVANCED ENCRYPTION
l Institute of Standards and
ber 26.
curity attributes or
ity attributes, or
FCS_CKM.1 Cryptographic key generation],
Cryptographic key destruction,
.2 Secure security attributes.
5.1 nal SFRs
The TOE shall meet the requirement “T
FPT_SEP.1[CO ration
nts.
e TSF shall maintain a security domain for its own
execution that protects it from interference and tampering by
untrusted subjects.
FPT_SEP.1.2 The TSF shall enforce separation between the security
domains of subjects in the TSC.
Dependencies: No dependencies
options 1 and 2.
[FDP_ITC.1 Import of user d
FDP_ITC.2 Import of user d
FCS_CKM.1 Cryptographi
FCS_CKM.4 Cryptographic key destruction
FM
The (AES co-processor of the) TOE shall mee
(FCS_COP.1[AES])” as specified bel
FCS_COP.1[AES] Cryptographic operation
No other components.
The TSF shall perform
accordance with a specified cryptographic alg
Advanced Encryption Standard (AES) al
cryptographic key sizes of 128, 192 o
following list of sta
FIPS PUB 197 FEDERAL INFORMATI
STANDARDS PUBLICATIO
STANDARD (AES), Nationa
Technology, 2001 Novem
Dependencies: [FDP_ITC.1 Import of user data without se
FDP_ITC.2 Import of user data with secur
FCS_CKM.4
FMT_MSA
.1.3 Additio regarding protection of configuration data
SF domain separation (FPT_SEP.1[CONF])” as
specified below.
NF] TSF domain sepa
Hierarchical to: No other compone
FPT_SEP.1.1 Th
6
[assignment: list of cryptographic operations]
7
[assignment: cryptographic algorithm]
8
[assignment: cryptographic key sizes]
9
[assignment: list of standards]
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 27 of 72
Refinement:
before TOE delivery.
isable certain
aces and to limit
mory blocks. Before
not be changed
martcard Embedded Software.
Therefore the TSF maintain a security domain for its own
ion that protects it from interference and tampering by
the Smartcard Embedded Software.
5.1
ed Software and
cated Software and
and
anagement of access to code and data as well as the
cated modes. The
(i.e. parts of the
icitly granted
permission, an application shall not be able to access hardware components directly to
between the “xD/xN”-
d the “xC figuration of the TOE. onsidered for the
access control policy and the related Secur rements.
Table 12. Differences between TOE configurations with regar ess Control Policy
The TOE allows to configure the TSF derived by the
organizational policy P.Add-Components
In this phase it is possible to enable or d
functional blocks of the TOE including interf
the available memory space for the me
TOE delivery the configuration is fixed and can
or influenced by the S
execut
.1.4 Additional SFRs regarding access control
Access Control Policy
The hardware shall provide different CPU modes to the IC Dedicat
Smartcard Embedded Software. The TOE shall separate IC Dedi
Smartcard Embedded Software from each other by both partitioning of memory
different CPU modes. The m
configuration of the hardware shall be performed in respective dedi
hardware shall enforce a separation between different applications
Smartcard Embedded Software) running on the TOE. Unless expl
support the separation of applications.
The following table provides an overview on the differences
configuration an
following
”-con This must be c
ity Functional Requi
d to the Acc
P5CD080V0B and P5CN080V0B P5CC080V0B and P5CC073V0B Remark
Access to
special area
in the
EEPROM
depends on the Mifare
configuration
fixed described in detail
below, function in
general not
influenced by the
configuration
Access to
RAM
depends on the Mifare
configuration
completely accessible described in detail
below, function in
general not
influenced by the
configuration
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 28 of 72
P5CD080V0B and P5CN080V0B P5CC080V0B an 3V0B
d P5CC07 Remark
Mifa
fire
re
wal
the RAM
access
he
ts the se
dicated
Software and Smartcar
Embedded Software
l
u
e
0
de and the User Mode
access to the RAM.
can only allow
MIFARE
Operating System to a RAM
indow in .
on o
t
refer to the
description of the
Mifare firewall
below, function in
general not
influenced by the
configuration
l for
the configuration of t
firewall suppor
between IC De
Mifare
paration
Support
d
the Mifare firewa
configured beca
Function Regist
as for the P5CD
System Mo
always have
The configuration
the access of the
l can be
se the Special
rs are accessible
80V0B. The
memory w
Therefore the c
impact because
is disabled.
addition
figuration has n
he Mifare Mode
Mifare
firewall for
p
Register
access
the configuration of the
firewall restricts the access of the
Sys
ware related Speci
Registers
rewal
configured becau al
for the P5CD0
configuration has nce
the Mifare Mode i
refer to the
description of the
Mifare firewall
below, function in
general not
influenced by the
configuration
the S
Functi
ecial
on
MIFARE Operating
hard
Mifare the Mifare fi
tem to the
al Function
Function Registe
as
l can be
se the Speci
rs are accessible
80V0B but the
no impact si
s disabled.
supported
CPU mode
System Mode, User Mode and
Mifare Mode
The Mifare Mode
this configuration
If the Mifare Mode is
suppressed the
related “lcall”
commands (CVEC
calls) do not force a
change of the CPU
mode. Thereby they
are executed as a
ormal “lcall”
command.
is suppressed in
n
The Security Function Policy (SFP) Access Control Policy uses the following
cts are
i.e. data in the memories of the TOE executed
ftware” as part of the IC Dedicated Support Software
• The “MIFARE Operating System” as part of the IC Dedicated Support Software
The objects are
• the memories consisting of
− ROM which is partitioned into Test-ROM and Application-ROM,
− EEPROM which is partitioned into two parts. For the ease of referencing the part
reserved for the MIFARE Operating System is called Mifare-EEPROM, the other
part Application-EEPROM.
definitions:
The subje
• The Smartcard Embedded Software
as instructions by the CPU
• The “Test ROM Software” as IC Dedicated Test Software
• The “Boot ROM So
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 29 of 72
− RAM which is partitioned into two parts. For the ease of referencing the part
M, the other part
gments defined by the Memory Management
plication-RAM.
mory is a subset of the first three.
used by the MMU
on. This group
gisters that define the pointer to the MMU Segment Table.
number of Special
ded to be used for overall system management
ewall. These Special
g data exchange
egister access control.
. The MIFARE
a number of internal Special Function Registers.
ial Function Registers
tion Registers related to hardware components. These Special
ers are used to utilize hardware components like the co-
nterrupt system.
Registers related to general CPU functionality. This group
tor, stack pointer and data pointers.
•
• CPU mode: There are five different CPU modes based on the configuration of the
Special Function Register “Program Status Word High (PSWH)” and two internal bits
defining whether the instruction is executed in the Boot Mode, Test Mode, Mifare
Mode, System Mode or User Mode.
• The values of the Special Function Registers to configure the MMU
segmentation and Special Function Registers related to system management.
These groups contain the pointer to the MMU Segment Table and those relevant for
the overall system management of the TOE, especially PSWH.
reserved for the MIFARE Operating System is called Mifare-RA
Application-RAM.
− the code and data in the Memory Se
Unit (MMU) in Application-ROM, Application-EEPROM and Ap
Note that this me
• the physical memory locations within the three memories that are
for the MMU Segment Table.
• the Special Function Registers consisting of
− Special Function Registers to configure the MMU segmentati
contains the re
− Special Function Registers related to system management, a
Function Registers that are inten
by the operating system.
− Special Function Registers to configure the MIFARE fir
Function Registers allow to modify the MIFARE firewall regardin
and Special Function R
− Special Function Registers used by the MIFARE Operating System
Operating System uses
− Special Function Registers related to testing. These Spec
are reserved for testing purposes.
− Special Func
Function Regist
processors or the i
− Special Function
contains e.g. the accumula
The memory operations are
• read data from the memory,
write data into the memory and
• execute data in the memory.
The Special Function Register operations are
• read data from a Special Function Register and
• write data into a Special Function Register.
The security attributes are
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 30 of 72
• MMU Segment Table: Configuration of the Memory Segments c
rights (read, write and execute), the virtual code memory base a
and last valid address, and the relocation offset to the physical me
omprising access
ddress of the first
mory location for
t also the access
onents are defined.
LH, MXBASL,
belonging to the group Special Function Registers to
configure the MIFARE firewall that define the access rights to the Special Function
Registers related to hardware components for code executed in Mifare Mode and the
In the .g. “code running
in Sy
s permissions are
emory Segments, the
segments up to the
ependent on the
uration of the TOE. For the P5CD080V0B and P5CN080V0B it depends on the
ection 2.2.1. For the P5CC080V0B and
served for the manufacturer, but the
E shall m CC.1)” as specified
below.
o:
FDP_ACC.1.1 olicy 10
on all code
emory
operations .
rity attribute based access control
tion Not ss 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
r to accessing the
respective memory address, the MMU checks if the access is
allowed.
FDP_ACC.1[SFR] Subset access control
Hierarchical to: No other components.
each of the 64 possible Memory Segments. For every segmen
rights to the Special Function Registers related to hardware comp
• The values of the Special Function Registers FWCTRLL, FWCTR
MXBASH, MXSZL and MXSZH
RAM area used for data exchange.
following the term “code running” combined with a CPU mode (e
stem Mode”) will be used to name subjects.
Note: A Memory Segment will be disabled for use if no acces
granted. It is not necessary to define all 64 possible M
MMU is capable of managing an arbitrary number of
limit of 64.
The amount of the partitioned memory for the EEPROM and RAM is d
config
MIFARE configuration A, B1 or B4, refer to s
P5CC073V0B 128 bytes of the EEPROM are re
RAM is accessible in total.
The TO eet the requirements “Subset access control (FDP_A
FDP_ACC.1[MEM] Subset access control
Hierarchical t No other components.
The TSF shall enforce the Access Control P
running on the TOE, all memories and all m
11
Dependencies: FDP_ACF.1 Secu
Applica e: The Acce
physical addresses by the MMU. Prio
10
[assignment: access control SFP]
11
[assignment: list of subjects, objects, and operations among subjects and objects covered by the
SFP]
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 31 of 72
FDP_ACC.1.1 12
on all code
nction Registers, and all
ns 13
.
ies: control
Application Not ed by implementing
l Function Register.
to determine if the
tion in User Mode
Special Function
s are provided by
cial Function Registers
ied read access
lue, a denied write access
r write access to a Special
Function Register may be not allowed depending on the
mode to enforce the
sure a secure operation.
The TOE shall meet the requirement “Security attribute based access control
CF.1)” a
FDP_ACF.1[ME l
Hierarchical to:
CF.1.1 l Policy
14
to objects
jects and the
attributes CPU mode, the MMU Segment Table, the Special
to configure the MMU segmentation and
the Special Function Registers related to system
FDP_ACF.1.2 to determine if an
n among controlled subjects and controlled objects is
Code executed in the Boot Mode
• has read and execute access to all code/data in the Test-
• has read, write and execute access to all code/data in the
• has read and write access to l data in the Mifare-RAM
Code executed in the Test Mode
The TSF shall enforce the Access Control Policy
running on the TOE, all Special Fu
Special Function Register operatio
Dependenc FDP_ACF.1 Security attribute based access
e: The Access Control Policy shall be enforc
hardware access control to each Specia
For every access the CPU mode is used
access shall be granted or denied. In addi
and Mifare Mode the access rights to the
Registers related to hardware component
the MMU Segment Table and the Spe
to configure the MIFARE firewall. A den
returns “0” instead of the actual va
is in fact ignored. The read and/o
function of the register or on the CPU
access control policy or en
(FDP_A s specified below.
M] Security attribute based access contro
No other components.
FDP_A The TSF shall enforce the Access Contro
based on the following: all subjects and ob
Function Registers
management 15
.
The TSF shall enforce the following rules
operatio
allowed:
ROM,
Mifare-EEPROM
al
12
[assignment: access control SFP]
13
[assignment: list of subjects, objects, and operations among subjects and objects covered by the
SFP]
14
[assignment: access control SFP]
15
[assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-
relevant security attributes, or named groups of SFP-relevant security attributes]
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 32 of 72
• data in the whole
o all code/data in the
n the whole RAM
Code executed in the Mifare Mode
ead and execute access to all code/data in the Test-
d execute access to all code/data in the
ad and write access to all data in the Mifare-RAM
ode/data in the
Application-ROM,
nd execute access to all code/data in the
n the Application-
ode/data in the
U Segment Table
used by the MMU,
ess to code/data
the MMU
a in the Application-
able used by the
FDP_ACF.1.3 f subjects to objects
: Code running in Mifare
Application-ROM
cess Condition Matrix”. Code running in Mifare
Mode has access to the Application-RAM defined by the
L, MXBASH, MXSZL and
Mifare Mode has read
the Application-
EEPROM. The FameXE co-processor has read access to the
EEPROM and read/write access to the FameXE RAM. 17
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects
based on the rules: none 18
.
has read and execute access to all code/
ROM,
• has read, write and execute access t
whole EEPROM
• has read and write access to all data i
• has r
ROM,
• has read, write an
Mifare-EEPROM
• has re
Code executed in the System Mode
• has read and execute access to all c
• has read, write a
Application-EEPROM,
• has read and write access to all data i
RAM,
Code executed in the User Mode
• has read and/or execute access to c
Application-ROM controlled by the MM
• has read and/or write and/or execute acc
in the Application-EEPROM controlled by
Segment Table used by the MMU,
• has read and/or write access to dat
RAM controlled by the MMU Segment T
MMU. 16
The TSF shall explicitly authorize access o
based on the following additional rules
Mode has read access to 64 bytes in the
storing the “Ac
Special Function Register MXBAS
MXSZH. Code running in Boot Mode or
access to the Security Row stored in
16
[assignment: rules governing access among controlled subjects and controlled objects using
controlled operations on controlled objects]
17
[assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects]
18
[assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 33 of 72
Dependencies: ntrol
e initialisation
F.1[SFR sed access control
cal to:
FDP_ACF.1.1 trol Policy 19
to objects
objects and the
able and the
20
.
FDP_ACF.1.2 to determine if an
rolled subjects and controlled objects is
allowed to access all
wed to access all
is allowed to read
e the MIFARE
tion Registers used
ss to Special
components is
by the Special
egisters FWCTRLL and FWCTRLH.
allowed to access
ure the MMU
ters related to system
tion Registers to configure the
egisters related to
is allowed to access
rdware
ghts defined in the
e MMU Segment Table
ted 21
.
The TSF shall explicitly authorize access of subjects to objects
In any CPU mode
gisters related to general
ctionality is allowed. The Special Function Register
PSWH belonging to group Special Function Registers related
to system management is additionally readable in Mifare
Mode and User Mode. The Special Function Register
CLKSEL of the group Special Function Registers related to
FDP_ACC.1 Subset access co
FMT_MSA.3 Static attribut
FDP_AC ] Security attribute ba
Hierarchi No other components.
The TSF shall enforce the Access Con
based on the following: all subjects and
attributes CPU mode, the MMU Segment T
Special Function Registers FWCTRLL and FWCTRLH
The TSF shall enforce the following rules
operation among cont
allowed:
• The code executed in Boot Mode is
Special Function Register groups.
• The code executed in Test Mode is allo
Special Function Register groups.
• The code executed in Mifare Mode
Special Function Registers to configur
firewall and to read/write Special Func
by the MIFARE Operating System. Acce
Function Registers related to hardware
based on the access rights determined
Function R
• The code executed in System Mode is
Special Function Registers to config
segmentation, Special Function Regis
management, Special Func
MIFARE firewall and Special Function R
hardware components.
• The code executed in the User Mode
Special Function Registers related to ha
components based on the access ri
respective Memory Segment in th
from which the code is actually execu
FDP_ACF.1.3
based on the following additional rules:
access to the Special Function Re
CPU fun
19
[assignment: access control SFP]
20
[assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-
relevant security attributes, or named groups of SFP-relevant security attributes]
21
[assignment: rules governing access among controlled subjects and controlled objects using
controlled operations on controlled objects]
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 34 of 72
hardware components can be read in the Mifare Mo
rega
de
rdless of the MIFARE firewall settings given by FWCTRLL
FDP_ACF.1.4 jects to objects
ction Registers to
in all CPU modes
unction Registers RPT0,
ction Registers
adable. The Special
ial Function
ated to hardware components is read-only. The
isters AKEY and DKEY of the group
rs related to hardware components
t readable. 23
ccess Control Policy
rom the policy and
erful and used to
uted in System Mode
memories provided
hange between the
re. Furthermore,
System Mode.
de executed in the System Mode can administrate the configuration of MMU,
s. Configuration
t Table and also
of it (as long as the table is located in write-able memory).
ration of the MMU,
se it has no access to the Special Function Registers to configure the MMU
pointer to the MMU Segment Table is not
ible.
• It may be possible for User Mode code to modify the MMU Segment Table contents if
the table itself is residing in a memory location that is part of a Memory Segment that
The TOE shall meet the requirement “Static attribute initialisation (FMT_MSA.3)” as
specified below.
FMT_MSA.3[MEM] Static attribute initialisation
Hierarchical to: No other components.
and FWCTRLH. 22
The TSF shall explicitly deny access of sub
based on the rules: Access to Special Fun
configure the MMU segmentation is denied
except System Mode. The Special F
RPT1 and RPT2 of the group Special Fun
related to system management are not re
Function Register RNR of the group Spec
Registers rel
Special Function Reg
Special Function Registe
are no
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
Implications of the A
The Access Control Policy has some implications, that can be drawn f
that are essential parts of the TOE security functions.
• Code executed in the Boot Mode or the Test Mode is quite pow
configure and test the TOE.
• Code executed in the Mifare Mode is separated from code exec
or User Mode. The separation is enforced by the partition of the
by the MMU. Only small memory areas are used for data exc
MIFARE Operating System and the Smartcard Embedded Softwa
the exchange area in RAM is fully controlled by code running in
• Co
because it has access to the respective Special Function Register
means that the code can change the address of the MMU Segmen
modify the contents
• Code executed in the User Mode cannot administrate the configu
becau
segmentation. Therefore changing the
poss
the code has write access to.
22
[assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects]
23
[assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 35 of 72
FMT_MSA.3.1 24
to provide
ve 25
default values for security attributes that are used
FMT_MSA.3.2 shall allow no subject 26
to specify alternative initial
alues when an object or
created.
ies: utes
Application Not s of the Special
MMU Segment
es any memory
e executed by the
configured
ot provide objects or information that can be
ince it provides access to memory areas. The
definition of objects that are stored in the TOE’s memory is
are.
FMT_MSA.3[SF ttribute initialisation
cal to:
FMT_MSA.3.1 The TSF shall enforce the Access Control Policy 27
to provide
security attributes that are used
SFP.
ify alternative initial
an object or
Dependencies: FMT_MSA.1 Management of security attributes
Application Note: The TOE does not provide objects or information that can be
created, since no further security attributes can be derived
Special Function Registers that contain security
efinition of objects that are stored in
ct to the Smartcard Embedded
The TOE shall meet the requirement “Management of security attributes (FMT_MSA.1)”
as specified below.
The TSF shall enforce the Access Control Policy
restricti
to enforce the SFP.
The TSF
values to override the default v
information is
Dependenc FMT_MSA.1 Management of security attrib
FMT_SMR.1 Security roles
e: Restrictive means here that the reset value
Function Register regarding the address of the
Table are set to zero, which effectively disabl
segment so that no User Mode code can b
CPU. Furthermore the memory partition can not be
at all.
The TOE does n
created, s
subject to the Smartcard Embedded Softw
R] Static a
Hierarchi No other components.
restrictive 28
default values for
to enforce the
FMT_MSA.3.2 The TSF shall allow no subject 29
to spec
values to override the default values when
information is created.
FMT_SMR.1 Security roles
(i.e. the set of
attributes is fixed). The d
the TOE’s memory is subje
Software.
24
[assignment: access control SFP, information flow control SFP]
25
[selection, choose one of: restrictive, permissive, [assignment: other property]]
26
[assignment: the authorized identified roles]
27
[assignment: access control SFP, information flow control SFP]
28
[selection, choose one of: restrictive, permissive, [assignment: other property]]
29
[assignment: the authorized identified roles]
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 36 of 72
FMT_MS M] Managem
A.1[ME ent of security attributes
ical to:
FMT_MSA.1.1 trol Policy 30
to restrict
d 31
the security attributes Special Function
tation 32
to code
the System Mode 33
.
Dependencies: l or FDP_IFC.1 Subset
Functions
Application Note: uded in this requirement
OE and access to
ccess to the respective
clude any management
ity for the configuration of the memory partition. This
ot be
FMT_MSA.1[SF
Hierarchical to: o other components.
FMT_MSA.1.1 all enforce the Access Control Policy 34
to restrict
odify 35
the security attributes defined in Special
d in a CPU mode which
Special Function
Registers .
s control or FDP_IFC.1 Subset
n flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
Management Functions
ied below.
ment Functions
r components.
Hierarch No other components.
The TSF shall enforce the Access Con
the ability to mo ify
Registers to configure the MMU segmen
executed in
[FDP_ACC.1 Subset access contro
information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management
The MMU Segment Table is not incl
because it is located in the memory of the T
it is possible for every role that has a
memory locations.
This component does not in
functional
is because the memory partition is fixed and cann
changed after TOE delivery.
R] Management of security attributes
N
The TSF sh
the ability to m
Function Registers
36
to code execute
has write access to the respective
37
Dependencies: [FDP_ACC.1 Subset acces
informatio
The TOE shall meet the requirement “Specification of
(FMT_SMF.1)” as specif
FMT_SMF.1 Specification of Manage
Hierarchical to: No othe
30
[assignment: access control SFP, information flow control SFP]
31
[selection: change_default, query, modify, delete, [assignment: other operations]]
32
[assignment: list of security attributes]
33
[assignment: the authorized identified roles]
34
[assignment: access control SFP, information flow control SFP]
35
[selection: change_default, query, modify, delete, [assignment: other operations]]
36
[assignment: list of security attributes]
37
[assignment: the authorized identified roles]
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 37 of 72
FMT_SMF.1.1 all be capable of performing the following security
system vector (SVEC)
ess,
exception or
e by finishing an exception/interrupt
with a special
the CPU mode by writing to the respective bits in
Register and
the Special Function Registers containing
ble. 38
Dependencies:
FMT_MSA.1 with the dependency to
f the Specification of
_SMF.1 is not
needed because all management functions rely on the same
features implemented in the hardware.
tional requirements
level for the
nts level is
“SOF-high”.
5.
valid for this Security
see section 1.3) or
Considering the Application Note 18 of [7] the column “Required by” shows the
e components between the PP and
the Security Target. The entry “EAL5 / PP” denotes that a SAR is required by both EAL5
and the requirement of the PP, “EAL5” means that this requirement is due to EAL5 and
beyond the requirement of the PP, and “PP” identifies this component as a requirement
of the PP which is beyond EAL5. The Security Target does not include additional
augmentations. The refinements of the PP “Smartcard IC Platform Protection Profile” that
must be adapted for EAL5 are described in section 5.1.3.
The TSF sh
management functions:
Change of the CPU mode by calling a
or configuration vector (CVEC) addr
change of the CPU mode by invoking an
interrupt,
change of the CPU mod
(with a RETI instruction),
change of the CPU mode
LCALL/ACALL/ECALL address,
change of
the PSWH Special Function
modification of
security attributes and
modification of the MMU Segment Ta
No dependencies
Application Note: The iteration of
FMT_SMF.1 may imply a separation o
Management Functions. Iteration of FMT
5.1.1.5 SOF claim for TOE security func
Since the assurance level is augmented with AVA_VLA.4 the required
Strength of Function (SOF) of the above listed security functional requireme
1.2 TOE Security Assurance Requirements
Table 13 below lists all security assurance components that are
Target. These security assurance components are required by EAL5 (
by the Protection Profile.
differences in the requirements of security assuranc
38
[assignment: list of security management functions to be provided by the TSF]
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 38 of 72
Table 13. rity Assurance Requirements EAL5 and ns
Secu PP augmentatio
SAR Title Required by
ACM_AUT. EAL5 / PP
ACM_CAP.4 Generation support and acceptance procedures EAL5 / PP
1 Partial CM automation
ACM_SCP e EAL5
.3 Development tools CM coverag
ADO_DEL. tion EAL5 / PP
2 Detection of modifica
ADO_IGS.1 eration, and start-up pr es EAL5 / PP
Installation, gen ocedur
ADV_FSP. nctional specification EAL5
3 Semiformal fu
ADV_HLD.3 Semiformal high-level design EAL5
ADV_IMP.2 Implementation of the TSF EAL5 / PP
ADV_INT.1 EAL5
Modularity
ADV_LLD.1 low-level design EAL5 / PP
Descriptive
ADV_RCR. iformal correspondence demonstra EAL5
2 Sem tion
ADV_SPM.3 Formal TOE security policy model EAL5
AGD_ADM EAL5 / PP
.1 Administrator guidance
AGD_USR nce EAL5 / PP
.1 User guida
ALC_DVS. f security measures PP
2 Sufficiency o
ALC_LCD.2 rdized life-cycle model EAL5
Standa
ALC_TAT.2 Compliance with implementation standards EAL5
ATE_COV.2 Analysis of coverage EAL5 / PP
ATE_DPT. EAL5
2 Testing: low-level design
ATE_FUN. tional testing EAL5 / PP
1 Func
ATE_IND.2 Independent testing – sample EAL5 / PP
AVA_CCA.1 Covert channel analysis EAL5
AVA_MSU.3 Analysis and testing for insecure states PP
AVA_SOF.1 Strength of TOE security function evaluation EAL5/ PP
AVA_VLA.4 Highly resistant PP
5.1.3 Refinements of the TOE Security Assurance Requirements
The ST claims conformance to the Protection Profile “Smartcard IC Platform Protection
Profile”, and therefore it has to be conform to the refinements of the TOE security
assurance requirements (see Application Note 19 of the PP). Because the refinements in
the PP are defined for the security assurance components of EAL4, some refinements
have to be applied to assurance components of the higher level EAL5 stated in the
Security Target.
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 39 of 72
Table 14 lists the influences of the refinements of the PP on the S
security assurance components have the same level in both docum
T. Most of the refined
ents (Protection
Profile and Security Target). The following two subsections apply the refinements to
P and the ST.
14. rview of differences of refinements
ACM_SCP.3 and ADV_FSP.3 which are different between the P
Table Security Assurance Requirements, ove
Refined in PP Influence on ST
ACM_CAP without change
_SCP to be adapted
.4 Same as in PP, refinement valid
ACM .2 ACM_SCP.3, refinements have
ADO_DEL.2 Same as in PP, refinement valid without change
ADO_IGS.1 Same as in PP, refinement valid without change
ADV_FSP. to be adapted
2 ADV_FSP.3, refinements have
AGD_ADM without change
.1 Same as in PP, refinement valid
AGD_USR.1 Same as in PP, refinement valid without change
ALC_DVS.2 Same as in PP, refinement valid without change
ATE_COV.2 Same as in PP, refinement valid without change
5.1
C family ACM_SCP,
P regarding
ACM_SCP.2 is a clarification of the configuration item “TOE implementation
nt and presentation of evidence element
n item to the list of items to be tracked by
ntation” of
[7] and is not cited
5.1.3.2
mily ADV_FSP,
e PP regarding
ith the description of the TSF and its external interfaces, the
te representation of
pleteness of the TOE SFR instantiations. The
refinement is not a change in the wording of the action elements, but a more detailed
definition of the above items.
Since the higher level ADV_FSP.3 requires a Functional Specification in a “semiformal
style, supported by informal, explanatory text where appropriate” (ADV_FSP.3.1C) the
changes only affect the style of description, the refinements can be applied without
changes and are valid for ADV_FSP.3.
The refinement of the original component ADV_FSP.2 can be found in section 5.1.3.5 of
the Protection Profile [7] and is not cited here.
.3.1 Refinements regarding CM scope (ACM_SCP)
This Security Target requires a higher evaluation level for the C
namely ACM_SCP.3 instead of ACM_SCP.2. The refinement of the P
representation”. Since in ACM_SCP.3, the conte
ACM_SCP.3.1C only adds a further configuratio
the CM system, the refinement can be applied without changes.
The refinement of the configuration item “TOE implementation represe
ACM_SCP.2 can be found in section 5.1.3.3 of the Protection Profile
here.
Refinements regarding functional specification (ADV_FSP)
This Security Target requires a higher evaluation level for the CC fa
namely ADV_FSP.3 instead of ADV_FSP.2. The refinement of th
ADV_FSP.2 is concerned w
purpose and method of use of all external TSF interfaces, the comple
the TSF and the accuracy and com
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 40 of 72
5.2 Security Requirements for the Environment
This chapter consists of the sections Security Requirements for the IT-Environment and
Security Requirements for the Non-IT-Environment.
5.
in the PP “Smartcard
ded security
S] and
FMT_MSA.1[SFR]) as well as for Static attribute initialisation (FMT_MSA.3[MEM] and
nvironment in this
mented Smartcard
nvironment.
phic
ily FDP_ITC) that is
.
SA.1[SFR] as well as
] are related to security roles. The security
roles m zed mo sed but the associated identification of the user must be
ar ust define the number
h u
Table 15 ui
2.1 Security Requirements for the IT-Environment
There are no Security Requirements for the IT-Environment defined
IC Platform Protection Profile”. The dependencies derive from the ad
functional requirements for cryptographic operation (FCS_COP.1[DE
FCS_COP.1[AES]) and for Management of security attributes (FMT_MSA.1[MEM] and
FMT_MSA.3[SFR]) are defined as Security Requirements for the IT-E
Security Target. Since the requirements must be fulfilled by the imple
Embedded Software it is consequently seen as IT-E
The dependencies of FCS_COP.1[DES] and FCS_COP.1[AES] deal with cryptogra
key management (CC family FCS_CKM) and import of data (CC fam
subject to the applications and cannot be provided by the hardware
The dependency of FMT_MSA.1[MEM] and FMT_M
FMT_MSA.3[MEM] and FMT_MSA.3[SFR
ay be reali de-ba
implem
and be
ented by the Sm
aviour of the sec
. Security Req
tcard Embedded Software that also m
rity roles.
rements for the IT Environment
SFR Name Note
FDP_IT
FDP_ITC.2
CK
of u
ithout securit
utes
user data
urity at
a
generation
alized by the
Smartcard Embedded Software. Although the Random
derive random
ration of keys at least require
access the Random
to create a key.
FCS_CKM.4 Cryptographic key
destruction
Keys can only be deleted by the Smartcard Embedded
Software
C.1 or
or
Import
w
FCS_ M.1 attrib
ser data
y
Any import of user data must be re
/ Import of
with
Number Generator can be used to
numbers, the gene
sec
Cryptogr
tributes /
phic key
Smartcard Embedded Software to
Number Generator several times
FMT_MSA.2 Secure security
attributes
The security attributes must be defined and assigned by
the Smartcard Embedded Software.
FMT_SMR.1 Security roles The hardware provides different CPU modes that shall
be used by the Smartcard Embedded Software to
realize the required security roles.
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 41 of 72
5.
Since this ST claims conformance to the PP “Smartcard IC Platform Protection Profile”,
ing security requirements for the Non-IT-Environment are taken from the PP:
rocess-Card
irements for the Non-
uirements “Cipher Schemata
(RE.Cipher)” as
RE.Cipher
st not
mpromise keys
re executed as part of the Smartcard
ch access
r to misuse these
ey which is used in
n as they are generated.
high probability, as well
cryptographically strong. For example, it must be ensured
ossible to derive the private key from a public
key if asymmetric algorithms are used. If keys are imported
r keys, quality and
mplies that an
alized in the
RE.RNG
ers of Smartcard Embedded Software must
st routines dependent on the usage of the
sting the
umber generator
Guidance,
2/02x/040/073/080/144V0B family of Secure Smart
Card Controllers.
RE.Check-Init Check of initialisation data
The Card Manufacturer shall use appropriate measures to
protect and check a sufficient part of the pre-personalization
data. This shall include at least the FabKey data that is part of
the pre-personalization data (to prevent the use of Smartcard
ICs that are not correctly tested and pre-personalized by the
TOE Manufacturer).
2.2 Security Requirements for the Non-IT-Environment
the follow
• RE.Phase-1
• RE.P
The Security Target specifies the following additional security requ
IT-Environment.
The Smartcard Embedded Software shall meet the req
specified below.
Cipher Schemata
The developers of Smartcard Embedded Software mu
implement routines in a way which may co
when the routines a
Embedded Software. Performing functions whi
cryptographic keys could allow an attacke
functions to gather information about the k
the computation of the function.
Keys must be kept confidential as soo
The keys must be unique with a very
as
that it is not p
into the TOE and/or derived from othe
confidentiality must be maintained. This i
appropriate key management has to be re
environment.
Test of Random Numbers
The develop
implement te
random number generator. The requirements for te
random numbers provided by the random n
are given by the AIS31 and described in the
Delivery and Operation Manual for the
P5Cx01
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 42 of 72
6. TOE Summary Specification
This chapter is divided in the sections “TOE Security Functions” and “Assurance
ns
nd to the TOE security functional
requi
The f
end of phase 3 and all
from phase 3 to
res that are not listed as security function in the
ete security function by themselves but they can
Embedded
phic algorithms or the
length of
byte. The TOE implements the F.RNG by means of a physical hardware random
by F.OPC (operational
e Smartcard
Software to detect faults in the hardware implementing the random number
nt of the
umber generator is
eys for symmetric
fs and generation of
ording to the Data
hic function which
TDEA algorithm as defined by FIPS PUB 46 by means of a hardware co-
processor and supports (a) the 3-key Triple-DEA algorithm according to keying option 1
and (b) the 2-key Triple DEA algorithm according to keying option 2 in FIPS PUB 46-3
[16]. The two/three 56 bit keys (112/168 bit) for the 2-key/3-key Triple DES algorithm
shall be provided by the Smartcard Embedded Software. For encryption the Smartcard
Embedded Software provides 8 bytes of the plain text and F.HW_DES calculates 8 bytes
cipher text. The calculation output is read by the Smartcard Embedded Software. For
decryption the Smartcard Embedded Software also provides 8 bytes of cipher text and
F.HW_DES calculates 8 bytes plain text. The calculation output is read by the Smartcard
Embedded Software.
Measures”.
6.1 TOE Security Functio
The TOE Security Functions (TSF) directly correspo
rements defined in chapter 5.1.1.
ollowing security functions are applicable to the phases 4 to 7.
Note: Some of the security functions are configured at the
security functions are already active during the delivery
phase 4.
The TOE comprises additional featu
following. They do not provide a compl
be used to support security functions implemented by the Smartcard
Software, e.g. the FameXE co-processor for asymmetric cryptogra
CRC calculation for the control of data integrity.
F.RNG: Random Number Generator
The random number generator continuously produces random numbers with a
one
number generator working stable within the limits guaranteed
conditions).
The TSF provides a hardware test functionality that can be used by th
Embedded
generator.
According to AIS31 the random number generator claims the fulfillme
requirements of functionality class P2. This means that the random n
suitable for generation of signature key pairs, generation of session k
encryption mechanisms, random padding bits, zero-knowledge proo
seeds for DRNGs.
F.HW_DES: Triple-DES Co-processor
The TOE provides the Triple Data Encryption Algorithm (TDEA) acc
Encryption Standard (DES). F.HW_DES is a modular basic cryptograp
provides the
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 43 of 72
F.HW_AES: AES Co-processor
The TOE provides the Advanced Encryption Standard (AES) algo
Advanced Encryption Standard.
rithm according to the
ographic function
7 [17] by means of a
ifferent key lengths
ided by the
ed Software
cipher text. The
ulation output is read by the Smartcard Embedded Software. For decryption the
also provides 16 bytes of cipher text and F.HW_AES
martcard Embedded
d by the
well as the Triple-DES co-processor, AES
O interfaces and
d Support Software
features of the
n using the following
monitoring of power
p by means of sensors.
ensors for the different ISO 7816 supply voltage classes and the
ip surface and
eters are defined
ditionally to the light
PROM provides two functions to detect light attacks. The Smartcard
ctions of the
uitry to detect a number
c that
ssor and the
(i) a reset is forced
am is aborted or (ii) an exception is raised which interrupts
oftware. A reset is
n exception is
tection circuitry. If
the inverse error correction of the EEPROM is enabled (refer to section 2.2.5) the
probability to detect fault injection errors increases and the error correction logic will also
raise an exception if an error is detected. If the TOE is reset all components of the TOE
are initialized with their reset values. In addition the TOE provides a reset cause indicator
to the Smartcard Embedded Software. In the case an exception is raised an indicator for
the reason of the exception is provided.
Before TOE delivery the Test Mode is disabled. In all other modes except the Test Mode
the TOE enables the sensors automatically when operated. Furthermore the TOE
prevents that the Smartcard Embedded Software disables the sensors. The assignment
F.HW_AES is a modular basic crypt
which provides the AES algorithm as defined by FIPS PUB 19
hardware co-processor and supports the AES algorithm with three d
of 128, 192 or 256 bit. The keys for the AES algorithm shall be prov
Smartcard Embedded Software. For encryption the Smartcard Embedd
provides 16 bytes of the plain text and F.HW_AES calculates 16 bytes
calc
Smartcard Embedded Software
calculates 16 bytes plain text. The calculation output is read by the S
Software.
F.OPC: Control of Operating Conditions
The function F.OPC ensures the correct operation of the TOE (functions offere
micro-controller including the standard CPU as
co-processor, the arithmetic co-processor, the memories, registers, I/
the other system peripherals) during the execution of the IC Dedicate
and Smartcard Embedded Software. This includes all specific security
TOE which are able to provide an active response.
The TOE ensures its correct operation and prevents any malfunctio
sub-functions: filtering of power supply and clock input as well as
supply, the frequency of the clock and the temperature of the chi
There are multiple s
contact-less operation mode. Light sensors are distributed over the ch
used to detect light attacks. The thresholds allowed for these param
within the range where the TOE ensures its correct operation. Ad
sensors the EE
Embedded Software can select one function and also disable both fun
EEPROM detection function.
Specific functional units of the TOE are equipped with special circ
of single fault injection attacks: The Program Counter, the stack pointer, the logi
implements the PSWH register, the DES co-processor, AES co-proce
FameXE co-processor.
If one of the monitored parameters is out of the specified range, either
and the actual running progr
the program flow and allows a reaction of the Smartcard Embedded S
forced by the sensors for voltage, frequency, temperature and light. A
forced by the EEPROM light detector and the single fault injection de
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 44 of 72
which sensor raises an exception or forces a reset is hard-wired and cannot be changed
. The stack pointer
old for the User Mode, System Mode and
e Mode). In case the
curity function comprises an additional sensor to check the
EEPROM during every write sequence. The
s not force
the hardware, (ii) the IC
re in the ROM and
including the
ta or TSF data against
ed by the TOE.
n and construction
hese features
d specific
for the memory blocks. The security function F.PHY supports the
EEPROM is able to
. The EEPROM
error forces a reset.
formation that might
ween events found
gnals on the
the terminal or the Smartcard Embedded Software.
r TSF data stored
the power
essing. The protection of the TOE
ther security functions.
t the calculation time is
The AES co-processor includes special features to prevent SPA/DPA analysis of shape
and amplitude of the power consumption and ensures that the calculation time is with
respect to the key length independent from any plain/cipher text.
The FameXE co-processor provides measures to prevent timing attacks on basic
modular function. The calculation time of one operation depends on the lengths of the
operands but not on the value of the operands, with the following exceptions:
multiplication with reduction, modular inversion and modular division. These three
operations have no constant timing due to correction cycles that are needed based on
by software.
In addition, the TOE controls the specified range of the stack pointer
and the control logic is implemented threef
Super System Mode (comprising Boot Mode, Test Mode and Mifar
specified limits are reached an exception is generated.
Beside the sensors the se
high voltage for the write process to the
result of this sensor must be read from a Special Function Register and doe
an automatic event (e.g. exception).
F.PHY: Protection against Physical Manipulation
The function F.PHY protects the TOE against manipulation of (i)
Dedicated Software in the ROM, (iii) the Smartcard Embedded Softwa
the EEPROM, (iv) the application data in the EEPROM and RAM
configuration data in the security row. It also protects User Da
disclosure by physical probing when stored or while being process
The protection of the TOE comprises different features within the desig
which make reverse-engineering and tamper attacks more difficult. T
comprise dedicated shielding techniques for different components an
encryption features
efficiency of other security functions.
F.PHY also supports the integrity of the EEPROM and the ROM. The
correct a 1-bit error within each byte. The ROM provides a parity check
corrects errors automatically without user interaction, a ROM parity
F.LOG: Logical Protection
The function F.LOG implements measures to limit or eliminate the in
be contained in the shape and amplitude of signals or in the time bet
by measuring such signals. This comprises the power consumption and si
other pads that are not intended by
Thereby this security function prevents the disclosure of User Data o
and/or processed in the smartcard IC through the measurement of
consumption and subsequent complex signal proc
comprises different features within the design that support the o
The Triple-DES co-processor includes special features to prevent SPA/DPA analysis of
shape and amplitude of the power consumption and ensures tha
independent from any key and plain/cipher text.
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 45 of 72
the calculation method. In addition special features are included t
the capability for the analysis of shape and amplitude of the powe
o provide limitations of
r consumption. Of
nd algorithm-specific
d Software
ions and (ii) CPU
ck configurations that can be used to prevent the possibility to synchronize the internal
cs of the power
ryption features) and
tection.
oot Mode, (ii) Test
fuses stored in a
ility to store
a”.
Mifare Mode
prevents the abuse of test functions after TOE delivery. Additionally it also ensures that
ed. The initial – but not
mines whether the
Dedicated Test
em Mode – the initial
dded Software.
guration- and
e changes
s from
these two modes
back to Boot Mode are prevented. The switch to the Test Mode is prevented after TOE
oot Mode
annot be invoked
time the TOE has
vailable when the PSWH.SSM bit is
ant with
ronic fuses especially ensures that configuration options with
regard to Security Functions cannot be changed, abused or influenced in any way.
F.COMP ensures that activation or deactivation of security features can not be influenced
by the Smartcard Embedded Software so that the TSF maintain a security domain for its
own execution that protects it from interference and tampering.
The TSF controls access to the Security Row, the top-most 128 Bytes of the EEPROM
memory, accessible at reserved addresses within the memory map. The available
EEPROM memory space for the Smartcard Embedded Software is reduced by this area.
F.COMP provides three memory areas within the security row that can be used by the
Smartcard Embedded Software:
course the FameXE does not realize an algorithm on its own a
leakage countermeasures have to be added for the FameXE.
Additional features that can be configured by the Smartcard Embedde
comprise (i) the FameXE HIGHSEC mode which adds dummy calculat
clo
operation with the external clock or to synchronize with the characteristi
consumption that can be used as trigger signal to support leakage attacks (DPA or timing
attacks)
Specific features as described for the function F.PHY (e.g. the enc
for the function F.OPC (e.g. the filter feature) support the logical pro
F.COMP: Protection of Mode Control
The function F.COMP provides a control of the CPU mode for (i) B
Mode and (iii) Mifare Mode. This includes the protection of electronic
protected memory area, the so-called “Security Row”, and the possib
initialisation or pre-personalization data in the so-called “FabKey Are
The control of the CPU mode according to Boot Mode, Test Mode and
features used at boot time to configure the TOE can not be abus
user visible – CPU mode is the Boot Mode. Hardware circuitry deter
Test Mode is available or not. If it is available, the TOE starts the IC
Software in the Test Mode. Otherwise, the TOE switches to the Syst
user visible CPU mode – and starts execution of the Smartcard Embe
The protection of electronic fuses ensures the secure storage of confi
calibration data stored in the Test Mode. F.COMP protects CPU mod
regarding Boot Mode, Test Mode and Mifare Mode in the following way: Switche
Boot Mode to Test Mode or Mifare Mode are allowed, switches from
delivery, therefore it is permanently disabled. F.COMP also ensures that the B
is only active during the boot phase of the TOE after every reset and c
afterwards. Therefore, once the TOE has left the test phase and every
started up, the Mifare Mode is the only CPU mode a
set. All three CPU modes Boot Mode, Test Mode and Mifare Mode are me
“Super System Mode” and F.COMP controls which mode is used if the PSWH.SSM bit
indicates the Super System Mode.
The protection of elect
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 46 of 72
• the User Read Only Area
otected Area and
Smartcard
es that can be write-
protected by the Smartcard Embedded Software on demand. The User Write Once Area
‘1’ – not reset to
rity function F.COMP
Smartcard
ntification data can
is not protected by
w can be used by
s are set during chip testing and pre-personalization. They
per and are included
Write Once Area
ard or a sequence
r of bits set to
des test personnel during
ation and/or pre-personalization data
EEPROM. The security
that protects it from
ode and in the other
s of subjects
Software.
y Access Control
ing processor
nt Unit (MMU).
addresses that are mapped to physical addresses.
nt Unit performs the
sses are provided
s. The access control is
• Partition of the memories: Every memory type (RAM, EEPROM, ROM) is split into
two parts. In Boot Mode, Mifare Mode, System Mode and User Mode the CPU has
access to only one part of each memory. In the Test Mode access to both parts is
allowed in order to test the memory blocks.
• Segmentation of the memory in the User Mode: All three accessible parts (RAM,
EEPROM, ROM) of the memory can be segmented into smaller areas and access
rights (readable, writeable or executable) can be defined for these segments.
Additionally access rights to Special Function Registers related to hardware
components can be defined for code that is executed from a segment.
• the User Write Pr
• the User Write Once Area.
The User Read Only Area contains 32 bytes that are read-only for the
Embedded Software. The User Write Protected area contains 16 byt
contains 32 bytes in which each bit independently can be – once set to
‘0’.
If the Card Disable Function is used (refer to section 2.2.5) the secu
prevents any start-up of the Smartcard Embedded Software once the
Embedded Software disables the card.
F.COMP also provides the FabKey Area in which initialisation or ide
be stored. The FabKey area does not belong to the Security Row and
hardware mechanisms. The FabKey Area as well as the Security Ro
F.COMP to store a unique identification for each die.
For all areas the initial value
depend on the choice of the Smartcard Embedded Software develo
in the Order Entry Form. The User Write Protected Area and the User
are designed to store the identification of a (fully personalized) smartc
of events over the life cycle that can be coded by an increasing numbe
"one" or protecting bytes, respectively.
F.COMP limits the capabilities of the test functions and provi
phase 3 with the capability to store the identific
and/or supplements of the Smartcard Embedded Software in the
function F.COMP maintains the security domain for its own execution
interference and tampering by untrusted subjects both in the Test M
modes. It also enforces the separation between the security domain
regarding the IC Dedicated Software and the Smartcard Embedded
F.MEM_ACC: Memor
F.MEM_ACC controls access of any subject (program code compris
instructions) to the memories of the TOE through the Memory Manageme
Memory access is based on virtual
The CPU always uses virtual addresses. The Memory Manageme
translation from virtual to physical addresses and the physical addre
from the MMU to the memory interfaces to access the memorie
performed in two ways:
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 47 of 72
The memory partition is fixed and cannot be changed. It is determined during production
refer to section 2.2).
he segmentation is
ss rights to
d in the MMU
ch segment: The
rtual end address of
ights for Special
ffset is used to
ng address computed by
gments can be
the memory access rights allow to
everal parts.
therefore the table
ode.
Special Function
s
s allowed or not.
ction Registers
ut the
he other CPU modes: In Boot Mode, Test Mode and System Mode
cated the
d in the
ss to the 16
. Note that F.MEM_ACC only
to F.SFR_ACC, the access control is
C permanently checks whether the selected addresses are within
ations (i.e. access
the boundary of the
ented memory range are notified by raising an exception.
sters and the
sters as specified in
CC.1[SFR]
Based on the function of the register or on the CPU mode, the read and/or write access
for a specific Special Function Register is not allowed. Examples for this are read access
to DES key register or write access to the output register of the random number
generator. The TSF will ignore any operation on the Special Function Register that is not
allowed. Ignored means that the write access has no influence and/or that the read
access always provides a fixed return value independent of the content of the Special
Function Register. Some Special Function Register are implemented threefold, for User
Mode, System Mode and Super System Mode (comprising Boot Mode, Test Mode and
Mifare Mode) which by its nature separates the Special Function Registers.
of the TOE and is solely dependent on the MIFARE configuration (
The memory segmentation can be defined in the System Mode. T
active when the CPU switches to the User Mode. The segments and the acce
Special Function Registers related to hardware components are define
Segment Table. The MMU Segment Table stores five values for ea
memory access rights, the virtual start address of the segment, the vi
the segment, the address offset for the segment and the access r
Function Registers accessible from within the segment. The address o
relocate the segment anywhere in the memory map. The resulti
the MMU is also subject to the partition of the memories. Up to 64 se
defined in the MMU Segment Table. Special values in
specify less segments and to distribute the MMU Segment Table in s
Note that the MMU Segment Table itself is stored in the memory and
itself can be placed within a segment accessible for User Mode c
As stated above the MMU provides information about access rights to
Registers related to hardware components for code running in User Mode. Thi
information is used by the TSF F.SFR_ACC to determine if the access i
The access rights can be defined for up to 16 groups of Special Fun
related to 16 peripheral components. The MMU provides the information abo
access rights also in t
the MMU indicates full access to the 16 groups, in Mifare Mode the MMU indi
access rights defined in two Special Function Registers which cannot be modifie
Mifare Mode. Therefore, the Mifare Mode can be restricted in the acce
groups on demand of the Smartcard Embedded Software
provides information about the access rights
enforced by F.SFR_ACC itself.
In addition F.MEM_AC
the boundary of the physical implemented memory range. Access viol
to forbidden memory addresses in User Mode) and accesses outside
physical implem
F.SFR_ACC: Special Function Register Access Control
The function F.SFR_ACC controls access to the Special Function Regi
switch between the CPU modes.
The TSF implements the access control to the Special Function Regi
the Access Control Policy and the Security Functional Requirements FDP_A
and FDP_ACF.1[SFR].
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 48 of 72
F.SFR_ACC used information provided by F.MEM_ACC in order to determi
the Special Function Registers related to hardware co
ne access to
mponents. Access to all other
_AES can only be
e Special Function
nted by code running in the System Mode. This holds for all
ers belonging to the
U modes based on
contains two bits,
the PSWH.SSM and PSWH.SM bit. The PSWH.SSM indicates one of three modes
amely Boot Mode, Test Mode or Mifare Mode.
User
ation vector (CVEC) call
ystem Mode, a call
e. Calls of SVEC
tion will be raised. For
s will not set the
other call.
the execution of an
in User Mode or
in System Mode can
n PSWH.SM is
ction. This will
lue of the PSWH to the value before the event occurred. Since the
nterrupts are
ctive, otherwise an
dress. Calls of
nd start execution at
no return address is
• Direct modification of the two bits in PSWH. Hardware logic provided by F.SFR_ACC
sible for code
stem Mode.
Only two modes are available to the Smartcard Embedded Software, the System Mode
and the User Mode. The System Mode is the more privileged mode since it allows
access to all Special Function Registers for the peripheral components and for system
management (i.e. configuring the MMU, clock settings or additional features provided by
F.LOG). The User Mode is the less privileged mode, but at least with regard to the
peripheral components it can be made as powerful as the System Mode.
The combination of F.SFR_ACC and F.COMP ensures that the other CPU modes are
not available for the Smartcard Embedded Software, but reserved for specific purposes
Special Function Registers is pre-defined and cannot be changed.
This implies that the security functions F.RNG, F.HW_DES and F.HW
used in User Mode or Mifare Mode if the access right to the respectiv
Registers are explicitly gra
specific hardware components controlled by Special Function Regist
16 groups mentioned above.
The TSF also implements mode transitions between the different CP
the PSWH Special Function Register. This Special Function Register
belonging to the Super System Mode, n
The PSWH.SM bit indicates the System Mode. If both bits are zero, the CPU is in
Mode.
The following operations can switch the CPU mode:
• Call of a system vector (SVEC) call address or configur
address. A call of a SVEC sets the PSWH.SM bit and enables S
of a CVEC sets the PSWH.SSM bit and enables Mifare Mod
addresses are only allowed in User Mode, otherwise an excep
the configuration P5CC080V0B calls to the CVEC addresse
PSWH.SSM bit. Instead, the call is executed normally like any
• Execution of an exception or interrupt. Any event that leads to
exception sets the PSWH.SM bit. Interrupts can be executed
System Mode. The Smartcard Embedded Software running
configure this option at run time and based on this configuratio
modified or not.
• Return from an exception/interrupt or vector call with a RETI instru
restore the va
User Mode is the least privileged mode, a RETI is only allowed if i
allowed to execute in User Mode and an interrupt actually a
exception will be raised.
• Execution a LCALL/ACALL/ECALL instruction with a specific ad
address 0x800000 in System Mode will enable the User Mode a
this (virtual) address. This is similar to a CVEC or SVEC call, but
pushed onto the stack.
ensures that the bits can only be cleared. Therefore it is not pos
running in User Mode to enter more privileged modes like the Sy
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 49 of 72
fulfilled by the IC Dedicated Software. In addition F.MEM_ACC provides separation of
emories and access control information.
sms which can be
ment AVA_SOF.1.
e identified, which can be
permutational or probabilistic properties:
lyzed with
abilistic methods.
f F.LOG especially
.HW_DES can be analyzed using probabilistic methods on power consumption
3. T s of F.LOG especially
fo ower consumption
o
igh” is made for these mechanisms.
W_AES can also be
es will be employed to satisfy the security assurance
rovide documents containing
r information needed to examine conformance of the measures
e en the
quir i n needed for the
ctive require her directly or referring to s containing this
information.
f g the assurance
require
the m
SOF claim
According to the CEM [4] a Security Target shall identify all mechani
assessed according to the assurance require
The following mechanisms contributing to these functions wer
analyzed for their
1. The output of the Random Number Generator F.RNG can be ana
prob
2. The quality of the mechanism contributing to the leakage attacks o
for F
of the TOE.
he quality of the mechanism contributing to the leakage attack
r F.HW_AES can be analyzed using probabilistic methods on p
f the TOE.
Therefore an explicit SOF claim of “h
Note: The cryptographic algorithms of F.HW_DES and F.H
analyzed with permutational or probabilistic methods but that this is not in
the scope of CC evaluations.
6.2 Assurance Measures
Appropriate assurance measur
requirements defined in section 5.1.1.5. The developer will p
the measures and furthe
to the assuranc
assurance re
respe
requirements. The following table
ements and the documents conta
ment eit
gives a mapping betwe
ning the informatio
further document
Table 16. List o documents describing the measure
ments
s regardin
Document containing or
referring the relevant
information
Input evidence according to CC Part 3,
which is contained or re the
ferred to in
document
Input for assurance
classes and families
(according to
developer actions in
CC Part 3)
semiformal functional specification ADV_FSP
Functional Specification,
Data Sheet, Instruction Set
correspondence analysis between the TOE
summary specification and the functional
specification
ADV_RCR
Formal Model TSP model (formal) ADV_SPM
High Level Design, high-level design (semiformal) ADV_HLD
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 50 of 72
Document containing or
referring the relevant
information
Input evidence according to CC Part 3,
which is contained or referred to in the
document
Input for assurance
classes and families
(according to
developer actions in
CC Part 3)
Design Report ondence analysis b
ctional specification an l
ADV_RCR
corresp
fun
etween
d high-leve
design
low level design ADV_LLD
architectural description ADV_INT
correspondence analysis between high-
d low-level
ADV_RCR
level design an design
Correspondence
Demonstration,
Design Report
correspondence analysis between low-level
sentation
ADV_RCR
design and implementation repre
Implementation
representation, Source
Code
presenta ADV_IMP
implementation re tion
configuration management documentation ACM
development tools documentation
development security documentation
life cycle definition documentation
ALC
Quality Management
Manual and Securi
an
rts of the delivery docum ADO
ty
Management M ual
pa entation
administrator guidance AGD_ADM,
AVA_MSU
secure in
procedure
stallation, generation, and start-up
s
ADO_IGS
user guidance AGD_USR,
AVA_MSU
Guidance, Delivery
Operation Manual, Data
ivery documentation ADO_DEL
and
Sheet, Instruction Set
parts of the del
vulnerability assessment
covert channel analysis
Vulnerability Assessment,
Design Report
strength of function claims analysis
AVA
test documentation
test coverage analysis
Test Documentation
Roadmap,
Verification Test,
Characterization Report,
Electrical Test Specification depth of testing analysis
ATE
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 51 of 72
7. PP Claims
This Security Target claims conformance to the following Protection Profile:
IC Platform Protection Profile, Version 1.0, July 2001; registered and certified
e reference BSI-
1, [7]
The short term for this Protection Profile used in this document is “Smartcard IC Platform
Protection Profile”.
8. Rationa
Smartcard
by Bundesamt für Sicherheit in der Informationstechnik (BSI) under th
PP-0002-200
le
This chapter contains the following sections: "Security Objectives Rationale", "Security
nd "PP Claims
8.1 Security Objectives Rationale
e how the assumptions, threats,
ssed by the objectives that are subject of
P “Smartcard IC Pla tion Profile”. The following Table 17 reproduces the
in section 7.1 of [7].
Table 17. Security Objec ssumptions, Threats or Policies
Requirements Rationale", "TOE Summary Specification Rationale" a
Rationale”.
Section 7.1 of the
and organizational security polici
Protection Profile provides a rational
es are addre
the P tform Protec
table
tives versus A
Assumption, Threat or OSP Security Objective Note
A.Plat-Appl E.Plat-Appl (Phase 1)
Appl E.Resp-Ap (Phase 1)
O
A.Resp- O pl
P.Process-TOE OE.Process-TOE
ntificati
(Phase 2 – 3)
O.Ide on
A.Process-Card (Phase 4 – 6)
OE.Process-Card
T.Leak-Inherent O.Leak-Inherent
T.Phys-Probing O.Phys-Probing
T.Malfunction O.Malfunction
T.Phys-Manipulation O.Phys-Manipulation
T.Leak-Forced O.Leak-Forced
T.Abuse-Func O.Abuse-Func
T.RND O.RND
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 52 of 72
The following Table 18 provides the justification for the additional secu
They are in line with the security objectives of the Protection Profile and suppl
rity objectives.
ement
nizational security policy.
Additional Secu ves versus A sumptions or Policies
these according to the additional assumptions and orga
Table 18. rity Objecti s
Assumption/Policy Security Objective Note
P.Add-Components O.HW_DES3
W_AES
O.MF_FW
O.MEM_ACC
O.CONFIG
A.Key-Function OE.Plat-Appl
OE.Resp-Appl
(Phase 1)
O.H
ESS
O.SFR_ACCESS
A.Check-Init OE.Check-Init (Phase 1) and
(Phase 4 – 6)
The justification related to the policy “Additional Specific Security Co
Com
mponents (P.Add-
ponents)” is as follows:
W_AES, O.MF_FW,
nce these
ecurity functionality
, the organizational security policy is covered by the
ction,
anipulation and O.Leak-Forced define how to implement the specific security
urity objectives are also valid for
e related threats also
aration of users.
fluenced or used
ws:
bjective “Usage of
card Embedded Software
shall use the cryptographic service of the TOE and their interface as specified. In
addition, the Smartcard Embedded Software (i) must implement operations on keys
(if any) in such a manner that they do not disclose information about confidential data
and (ii) must configure the memory management in a way that different applications
are sufficiently separated. If the Smartcard Embedded Software uses random
numbers provided by the security function F.RNG these random numbers must be
tested as appropriate for the intended purpose. This addition ensures that the
assumption A.Key-Function is still covered by the objective OE.Plat-Appl although
additional functions are being supported according to P.Add-Components.
The justification related to the security objectives O.HW_DES3, O.H
O.MEM_ACCESS, O.SFR_ACCESS and O.CONFIG is as follows: Si
objectives requires the TOE to implement exactly the same specific s
as required by P.Add-Components
objectives.
Nevertheless the security objectives O.Leak-Inherent, O.Phys-Probing, O.Malfun
O.Phys-M
functionality required by P.Add-Components. These sec
the additional specific security functionality since they must avert th
for the components added related to the policy.
The requirements for a multi-application platform necessitate the sep
Therefore it is volitional that most of the security functions cannot be in
in the User Mode.
The justification related to the assumption A.Key-Function is as follo
• Compared to [7] a clarification has been made for the security o
Hardware Platform (OE.Plat-Appl)”: If required the Smart
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 53 of 72
• Compared to [7] a clarification has been made for the securi
of User Data (OE.Resp-Appl)”: By definition cipher or plain tex
cryptographic keys are User Data. So, the Smartcard Embedde
protect such data if required and use keys and functions approp
ensure the strength of cryptographic operation. Quality and confi
maintained for keys that are imported and/or derived from oth
that appropriate key management has to be realized in the envir
the treatment of User Data comprises the implementation of a m
operating system that does not disclose security
ty objective “Treatment
t data and
d Software will
riately in order to
dentiality must be
er keys. This implies
onment. In addition
ulti-application
relevant User Data of one
ssumption A.Key-
curity objective OE.Resp-Appl although additional
on data by the Smartcard
quires the Smartcard Embedded Software developer to implement
a function assumed in A.Check-Init, the assumption is covered by the objective.
he additional assumptions show that they do
ection Profile for the assumptions,
8.2 Security Requirements Rationale
Section 7.2 of artcard IC Platform file” provides a rationale for
ping req ity objectives defined in
the Protection he mapping is reprod ing table.
Table 19. Se curity Objectives
application to another one. These measures make sure that the a
Function is still covered by the se
functions are being supported according to P.Add-Components.
The justification related to the assumption "Check of initialisati
Embedded Software (A.Check-Init)" is as follows:
Since OE.Check-Init re
The justification of the additional policy and t
not contradict to the rationale already given in the Prot
policy and threats defined there.
8.2.1 nal
Rationale for the security functio
the PP “Sm
requirements
Protection Pro
the map between security functional
Profile. T
uirements and secur
uced in the follow
curity Requirements versus Se
Objective TOE Security Functional
Requirements
Security Requirements for
the environment
O.Leak-Inhere FDP_ITT.1 “Basic intern
protection”
tern TSF data
C.1 “Subset information flow
.Phase-1 “Design and
Implementation of the
Smartcard Embedded
Software”
O.Phys-Probing FPT_PHP.3 “Resistance to physical
attack”
RE.Phase-1 “Design and
Implementation of the
Smartcard Embedded
ware”
nt al transfer RE
FPT_ITT.1 “Basic in al
transfer protection”
FDP_IF
control”
Soft
O.Malfunction FRU_FLT.2 “Limited fault tolerance
FPT_FLS.1 “Failure with preservation
of secure state”
FPT_SEP.1[PP] “TSF domain
separation”
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 54 of 72
Objective TOE Security Functional
Requirements
Security Requirements for
the environment
O.Phys-Manipulation FPT_PHP.3 “Resistance
attack”
.Phase-1 “Design and
mentation of the
ded
Software” (e.g. by
enting FDP_SDI.1
d data integrity
nitoring)
to physical RE
Imple
Smartcard Embed
implem
Store
mo
O.Leak-Forced for
ent
_ITT.1, FDP_IFC.1
r O.M lfunction and
ion
_FLS.1,
FPT_PHP.3
RE.Phase-1 “Design and
Implementation of the
Smartcard Embedded
Software”
All requirements listed
O.Leak-Inher
FDP_ITT.1, FPT
plus those listed fo a
O.Phys-Manipulat
FRU_FLT.2, FPT
FPT_SEP.1[PP],
O.Abuse-Func apabilities”
ailability”
plus those for O.Leak-Inherent,
s-Probing, O.Malfunction,
hys-Manipulation, O.Leak-Forced
FPT_PHP.3, FRU_FLT.
FMT_LIM.1 “Limited c
FMT_LIM.2 “Limited av
O.Phy
O.P
FDP_ITT.1, FPT_ITT.1, FDP_IFC.1,
2, FPT_FLS.1,
FPT_SEP.1[PP]
O.Identification FAU_SAS.1
“Audit storage”
O.RND _RND.1 “Quality metric for random
numbers”
plus those for O.Leak-In
O.Phys-Probing, O.Malf
O.Phys-Manipulation, O.Leak-Forced
FDP_ITT.1, FPT_ITT.1,
FPT_PHP.3, FRU_FLT.
FPT_SEP.1[PP]
RE.Phase-1 “Design and
mentation of the
artcard Embedded
ftware” (e.g. by
implementing FPT_AMT.1
tract machine testing”)
FCS
herent,
unction,
Imple
Sm
So
FDP_IFC.1,
2, FPT_FLS.1,
“Abs
OE.Plat-Appl hase-1 “Design and
Implementation of the
card Embedded
are”
RE.P
Smart
Softw
OE.Resp-Appl RE.Phase-1 “Design and
Implementation of the
Smartcard Embedded
Software”
OE.Process-TOE FAU_SAS.1 “Audit storage” Assurance Components:
refer to below ’
OE.Process-Card RE.Process-Card possibly
supported by RE.Phase-1
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 55 of 72
’ Assurance Components: Delivery (ADO_DEL); Installation, gene
(ADO_IGS) (using Administrator Guidance (AGD_ADM), User guidan
CM automation
ration, and start-up
ce (AGD_USR));
(ACM_AUT); CM Capabilities (ACM_CAP); CM Scope (ACM_SCP);
ools and
d in Table 20.
vironment are defined. The following table
s an over ments are security objectives.
20. Ma y objectives and
Development Security (ALC_DVS); Life Cycle Definition (ALC_LCD); T
Techniques (ALC_TAT)
The Security Target additionally defines the SFRs for the TOE that are liste
In addition Security Requirements for the En
give view, how the require combined to meet the
Table pping of securit requirements
Objective TOE Security Functional
Requirement
Security Requirements for
the environment
O.HW_DES3 OP.1[DES] RE.Phase-1 with RE.Cipher
S OP.1[AES] hase-1 with RE.Cipher
FCS_C
O.HW_AE FCS_C RE.P
O.MF_FW CC.1[MEM]
CF.1[MEM]
EM]
FDP_A
FDP_A
FMT_MSA.3[M
O.MEM_ACCESS FDP_ACC.1[MEM]
ACF.1[MEM]
MSA.3[MEM]
EM]
FR]
MT_SMF.1
1 “Design and
Implementation of the
Smartcard Embedded
Software” (e.g. definition of
separated memory segments
and sufficiently graded
exception handling)
FDP_
FMT_
FMT_MSA.1[M
FMT_MSA.1[S
F
RE.Phase-
O.SFR_ACCE S FDP_ACC.1[SFR]
FDP_ACF.1[SFR]
FMT_MSA.3[SFR]
FMT_MSA.1[SFR]
FMT_SMF.1
S
O.CONFIG FPT_SEP.1[CONF]
OE.Plat-Appl
(clarification) and RE.R
RE.Phase-1 with RE.Cipher
NG
OE.Resp-Appl RE.Phase-
(clarification)
1 with RE.Cipher
OE.Check-Init RE.Check-Init
The justification related to the security objective “Triple DES Functionality”
(O.HW_DES3) is as follows:
O.HW_DES3 requires the TOE to support Triple DES encryption and decryption. Exactly
this is the requirement of FCS_COP.1[DES]. Therefore FCS_COP.1[DES] is suitable to
meet O.HW_DES3.
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 56 of 72
The justification related to the security objective “AES Functionality” (O.HW_AES) is as
_AES requires the TOE to support AES encryption and decryption. Exactly this is
] is suitable to meet
.HW_AES.
MF_FW) is as
rol (FDP_ACC.1[MEM])” with the
icy” exactly require to
re,
jective.
s control
FP) “Access Control
y O.MF_FW.
ecurity objective.
_MSA.3[MEM])”
used by the
default values are
generated by the reset procedure and the Boot ROM Software for the related Special
s that the partition
hat the initial setting
d by
e this requirement (as
eet the security objective.
utes (FMT_MSA.1)”
attributes is restricted to privileged
MT_MSA.1 that
ement function is
d cannot be
ry Access Control
al requirement “Subset access control (FDP_ACC.1[MEM])” with the
tly require to
by O.MEM_ACCESS.
curity objective.
The security functional requirement “Security attribute based access control
(FDP_ACF.1[MEM])” with the related Security Function Policy (SFP) “Access Control
Policy” defines the rules to implement the area based memory access control as
demanded by O.MEM_ACCESS. Therefore, FDP_ACF.1[MEM] with its SFP is suitable
to meet the security objective.
The security functional requirement “Static attribute initialisation (FMT_MSA.3[MEM])”
requires that the TOE provide default values for the security attributes used by the
memory management units. Since the TOE is a hardware platform these default values
follows:
O.HW
the requirement of FCS_COP.1[AES]. Therefore FCS_COP.1[AES
O
The justification related to the security objective “MIFARE Firewall” (O.
follows:
The security functional requirement “Subset access cont
related Security Function Policy (SFP) “Access Control Pol
implement a memory partition as demanded by O.MF_FW. Therefo
FDP_ACC.1[MEM] with its SFP is suitable to meet the security ob
The security functional requirement “Security attribute based acces
(FDP_ACF.1[MEM])” with the related Security Function Policy (S
Policy” defines the rules to implement the partition as demanded b
Therefore, FDP_ACF.1[MEM] with its SFP is suitable to meet the s
The security functional requirement “Static attribute initialisation (FMT
requires that the TOE provide default values for the security attributes
memory management unit to enforce the memory partition. These
Function Register. Restrictive with respect to memory partition mean
cannot be changed at all and for the memory segmentation means t
is very restrictive since it effectively disables any memory segment. They are neede
the TOE to provide a default configuration after reset. Therefor
dependency from FDP_ACF.1) is suitable to m
The security functional requirement “Management of security attrib
requires that the ability to update the security
subject(s). No management ability is specified in the two iterations of F
can be used to change the memory partition. Also no related manag
specified by FMT_SMF.1. Therefore the memory partition is fixed an
changed any subject, which is the requirement of O.MF_FW.
The justification related to the security objective “Area based Memo
(O.MEM_ACCESS)” is as follows:
The security function
related Security Function Policy (SFP) “Access Control Policy” exac
implement an area based memory access control as demanded
Therefore, FDP_ACC.1[MEM] with its SFP is suitable to meet the se
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 57 of 72
are generated by the reset procedure for the related Special Function
needed by the TOE to provide a default configuration after reset. Therefo
Register. They are
re this
he security objective.
s (FMT_MSA.1)”
d to privileged
ss control can be
FMT_MSA.1 into
e different types of
Memory
y the Smartcard Embedded Software. Since the
m Mode and this
l Function Registers,
gement Functions
specification of the management functions to be provided
F.1 is suitable to
Register Access
Control (O.SFR_ACCESS)” is as follows:
.1[SFR])” with the
ment
_ACCESS.
urity objective.
CPU mode. The Special
d in the System Mode.
nts like e.g. the co-
the System Mode as
ntrol Policy”. In the User
CPU are accessible by default.
components can be
rol
related Security Function Policy (SFP) “Access Control
lement the access control to
fore,
tive.
The security functional requirement “Static attribute initialisation (FMT_MSA.3[SFR])”
requires that the TOE provides default values for the Special Function Register (values
as well as access control). The default values are needed to ensure a defined setup for
the operation of the TOE. Therefore this requirement (as dependency from FDP_ACF.1)
is suitable to meet the security objective.
The security functional requirement “Management of security attributes
(FMT_MSA.1[SFR])” is realized in a way that – besides the definition of access rights to
Special Function Registers related to hardware components in User Mode and Mifare
requirement (as dependency from FDP_ACF.1) is suitable to meet t
The security functional requirement “Management of security attribute
requires that the ability to update the security attributes is restricte
subject(s). These management functions ensure that the required acce
realized using the functions provided by the TOE. The iteration of
FMT_MSA.1[MEM] and FMT_MSA.1[SFR] is needed because th
objects have different security attributes. The security attributes of the
Management Unit can be changed b
pointer to the MMU Segment Table can only be changed in Syste
protection is implemented by access control to the respective Specia
both iterations are needed for O.MEM_ACCESS.
Finally, the security functional requirement “Specification of Mana
(FMT_SMF.1)” is used for the
by the TOE as demanded by O.MEM_ACCESS. Therefore, FMT_SM
meet the security objective.
The justification related to the security objective “Special Function
The security functional requirement “Subset access control (FDP_ACC
related Security Function Policy (SFP) “Access Control Policy” require to imple
access control for Special Function Register as demanded by O.SFR
Therefore, FDP_ACC.1[SFR] with its SFP is suitable to meet the sec
The access to Special Function Register is related to the
Function Register used to configure the MMU can only be accesse
The Special Function Register required to use hardware compone
processors or the Random Number Generator can be accessed in
specified by the Security Function Policy (SFP) “Access Co
Mode only Special Function Register required to run the
In addition specific Special Function Registers related to hardware
made accessible for the User Mode if the MMU is configured to allow this.
The security functional requirement “Security attribute based access cont
(FDP_ACF.1[SFR])” with the
Policy” exactly require certain security attributes to imp
Special Function Register as demanded by O.SFR_ACCESS. There
FDP_ACF.1[SFR] with its SFP is suitable to meet the security objec
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 58 of 72
Mode - no management of the security attributes is possible because the attributes are
ement Functions
sed for the specification of the management functions to be provided
.1 is suitable to
spective dependencies
ey have different security
n data”
G) is as follows:
is the requirement of FPT_SEP.1[CONF]. Therefore FPT_SEP.1[CONF] is suitable to
e of Hardware
sp-Appl)” is as follows:
se they
with a very high
e TOE (usually after
maintained.
artcard IC as well as
If keys are generated by the Smartcard
numbers must be
pplemented with
age of the random
appropriate
dom numbers are
must ensure that the
Data processed by these
ng a multi-application
of different
mechanisms of the
RE.Phase-1 defined
under RE.Phase-1 "findings of the TOE
evaluation reports relevant for the Smartcard Embedded Software"). These measures
are addressed in the Guidance, Delivery and Operation Manual for the
P5Cx012/02x/040/073/080/144V0B family of Secure Smart Card Controllers.
In addition RE.Phase-1 requires beside the specified usage of all security functions the
treatment of User Data that means security relevant user data of one application cannot
be disclosed to another application when a multi-application operating system is
implemented as part of the Smartcard Embedded Software. Therefore the developer of
the Smartcard Embedded Software shall design mainly the operating system in a way
that user data cannot be disclosed to an unauthorized subject.
implemented in the hardware and cannot be changed.
Finally, the security functional requirement “Specification of Manag
(FMT_SMF.1)” is u
by the TOE as demanded by O.SFR_ACCESS. Therefore, FMT_SMF
meet the security objective.
Note that the iteration of FDP_ACF.1 and FDP_ACC.1 with the re
are needed to separate the different types of objects because th
attributes.
The justification related to the security objective “Protection of configuratio
(O.CONFI
O.CONFIG requires the TOE to protect configuration data after TOE delivery. Exactly this
meet O.CONFIG.
The justification related to the clarification of the security objectives “Usag
Platform (OE.Plat-Appl)” and “Treatment of User Data (OE.Re
The usage of cryptographic algorithms requires to use appropriate keys. Otherwi
do not provide security. RE.Cipher requires that keys must be unique
probability, cryptographically strong etc. If keys are imported into th
TOE Delivery), it must be ensured that quality and confidentiality is
RE.Cipher addresses the usage of keys generated inside the Sm
keys downloaded into the Smartcard IC.
Embedded Software using the security function F.RNG these random
tested since F.RNG does include hardware tests that have to be su
statistical tests. The required test effort depends on the intended us
numbers. The requirements RE.Cipher and RE.RNG for the usage of
cryptographic keys for the cryptographic functions and strong ran
suitable to meet OE.Plat-Appl and OE.Resp-Appl.
Nevertheless, the developer of the Smartcard Embedded Software
additional functions are used as specified and that the User
functions are protected as defined for the application context. Usi
operating system may add additional requirements for the separation
applications by a memory management scheme based upon security
TOE. These issues are addressed by the requirement RE.Phase-1. The Smartcard
Embedded Software must implement additional measures regarding
in [7] (refer to the third point of the enumeration
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 59 of 72
The justification related to the security objective for the environment “Check of
Check-Init)” is as follows:
t is part of the pre-
ctly tested and
e secret
TOE
Manufacturer. F.COMP supports the storage of the FabKey data at the end of the test
ck this data in
meet OE.Check-
The justification of the additional security objective and the additional requirements (both
ty Requirements for the Environment) show
tion Profile for the
8. pendencies of security functional requirements
tection Profile are
the Protection Profile and at least one dependency is considered to be
ependencies defined by Part 2 of the
ite ments specif .1.2, 0 and 5.1.1.4 are
d.
The dependen d in the Common Criteria are listed in the table below:
Table 21. Dep f security functional requirements
initialisation data by the Smartcard Embedded Software (OE.
RE.Check-Init requires at least to check the FabKey data tha
personalization data to prevent the use of Smartcard ICs that are not corre
pre-personalized by the TOE Manufacturer. The FabKey may compris
information that is exchanged between the Card Manufacturer and the
phase in the Test Mode. The Smartcard Embedded Software is able to che
the System Mode or User Mode. Therefore RE.Check-Init is suitable to
Init.
Security Functional Requirements and Securi
that they do not contradict to the rationale already given in the Protec
assumptions, policy and threats defined there.
2.2 De
The dependencies listed in the Protection Profile [7] are independent form the additional
dependencies listed in the table below. The dependency of the Pro
fulfilled within
satisfied.
The following discussion demonstrates how the d
Common Cr
satisfie
ria for the require ied in sections 5.1
cies define
endencies o
Security Functional
Requirement
Dependencies Fulfilled by security
requirements in this ST
FCS_COP.1[DE DP_ITC.1, or FDP_ITC.2 or
FCS_CKM.1
FCS_CKM.4
T_MSA.2
Yes (by the environment)
.1[AE C.1, or FDP_IT
CKM.1
S_CKM.4
FMT_MSA.2
y the environment)
S] F
FM
FCS_COP S] FDP_IT C.2 or Yes (b
FCS_
FC
FPT_SEP.1[CONF] None Not applicable
FDP_ACC.1[MEM] FDP_ACF.1 Yes, by
FDP_ACF.1[MEM]
FDP_ACC.1[SFR] FDP_ACF.1 Yes, by FDP_ACF.1[SFR]
FDP_ACF.1[MEM] FDP_ACC.1
FMT_MSA.3
Yes, by
FDP_ACC.1[MEM]
Yes
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 60 of 72
Security Functional
Requirement
Dependencies Fulfilled by security
requirements in this ST
FDP_ACF.1[SFR] FDP_ACC.1
FMT_MSA.3
Yes, by FDP_ACC.1[SFR]
Yes
FMT_MSA.3[MEM] FMT_MSA.1
MT_SMR.1 EM]
e discussion below
F
Yes, by
FMT_MSA.1[M
Se
FMT_MSA.3[SF
MT_SMR.1
Yes, by FMT_MSA.1[SFR]
e discussion below
R] FMT_MSA.1
F Se
FMT_MSA.1[MEM] FDP_ACC.1 or FDP_IFC.1
MT_SMF.1
Yes, by
CC.1[MEM]
e discussion below
Yes
FMT_SMR.1
F
FDP_A
Se
FMT_MSA.1[SFR] FDP_ACC.1 or FDP_IFC.1
FMT_SMR.1
FMT_SMF.1
Yes, by F
See disc
Yes
DP_ACC.1[SFR]
ussion below
The developer of the Smartcard Embedded Software must ensure t
security functional requirements
hat the additional
P.1[AES] are used as
nction is protected
the requirement
completely
the specified
as specified for the
management
) according
.Phase-1 and RE.Cipher.
E only provides a
s for the handling of
explicitly moved to the
curity Requirements for the IT-Environment" because the Smartcard Embedded
Software is seen as "IT-Environment" that must fulfill these requirements related to the
needs of the realized application.
The dependency FMT_SMR.1 introduced by the two components FMT_MSA.1 and
FMT_MSA.3 is also addressed by the requirement RE.Phase-1 and more specific by the
security functional requirements as stated in the chapter "Security Requirements for the
IT-Environment". The definition and maintenance of the roles that act on behalf of the
functions provided by the hardware must be subject of the Smartcard Embedded
Software.
FCS_COP.1[DES] and FCS_CO
specified and that the User Data processed by the related security fu
as defined for the application context. These issues are addressed by
RE.Phase-1.
The dependent requirements of FCS_COP.1[DES] and FCS_COP.1[AES]
address the appropriate management of cryptographic keys used by
cryptographic function and the management of access control rights
memory access control function. All requirements concerning these
functions shall be fulfilled by the environment (Smartcard Embedded Software
to the requirements RE
The functional requirements [FDP_ITC.1, or FDP_ITC.2 or FCS_CKM.1], FCS_CKM.4
and FMT_MSA.2 are not included in this Security Target since the TO
pure engine for encryption and decryption without additional feature
cryptographic keys. These security functional requirements are
"Se
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 61 of 72
8.2.3 Rationale for the Assurance Requirements and the Strength of Function
Protection Profile [7].
, but chooses a higher
in order to meet assurance expectations of
nally, the
surance level EAL5
e components in an
te set of
ents chosen for augmentation do not add any dependencies,
tained in EAL 5.
t the mutual support
3, it has to be assumed that attackers with
ature applications or
n by the PP in order to
OE. For the same
nction level “high” is required.
ntegrated Circuit
as considered
ments are
8. uirements are Mutually Supportive and Internally Consistent
onents in the
re given for both
urance components
at the security functional and
inconsistencies
tives O.Leak-
ng, O.Malfunction, O.Phys-Manipulation and O.Leak-Forced also
ion control function
ted according to the
and
ntrol Policies
M] and FDP_ACF.1[SFR]. Therefore, these security functional
requirements support the secure implementation and operation of FCS_COP.1[DES],
FCS_COP.1[AES] and of FDP_ACC.1 with FDP_ACF.1 as well as the dependent
security functional requirements.
A smartcard platform requires Smartcard Embedded Software to build a secure product.
Thereby the Smartcard Embedded Software must support the security functions of the
hardware and implement a sufficient management of the security functions implemented
in the hardware. The realization of the Security Functional Requirements within the TOE
provide a good balance between flexible configuration and restrictions to ensure a secure
behaviour of the TOE.
Level
The selection of assurance components is based on the underlying
The Security Target uses the same augmentations as the PP
assurance level. The level EAL5 is chosen
digital signature applications and electronic payment systems. Additio
requirement of the PP to choose at least EAL4 is fulfilled.
The rationale for the augmentations is the same as in the PP. The as
is an elaborated pre-defined level of the CC, part 3 [3]. The assuranc
EAL level are chosen in a way that they build a mutually supportive and comple
components. The requirem
which are not already fulfilled for the corresponding requirements con
Therefore, these components add additional assurance to EAL 5, bu
of the requirements is still guaranteed.
As stated in the Protection Profile, section 7.2.
high attack potential try to attack smart cards used for digital sign
payment systems. Therefore specifically AVA_VLA.4 was chose
assure that even these attackers cannot successfully attack the T
reason the Strength of Fu
Note that for the augmentation to EAL5 the document “Smartcard I
Platform Augmentations” [8] as supposed by Application Note 21 w
regarding assurance requirements, but no additional assurance require
proposed in the document.
2.4 Security Req
The discussion of security functional requirements and assurance comp
preceding sections has shown that mutual support and consistency a
groups of requirements. The arguments given for the fact that the ass
are adequate for the functionality of the TOE also show th
assurance requirements support each other and that there are no
between these groups.
The security functional requirements required to meet the security objec
Inherent, O.Phys-Probi
protect the cryptographic algorithms and the memory access/separat
as well as the access control to Special Function Register implemen
security functional requirement FCS_COP.1[DES], FCS_COP.1[AES]
FDP_ACC.1[MEM], FDP_ACC.1[SFR] with reference to the Access Co
defined in FDP_ACF.1[ME
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 62 of 72
8.3 TOE Summary Specification Rationale
8.
The following table provides a mapping of TSF to SFR. The mapping is described in
rget).
Table 22. Mapping of cur Fu on equireme and the TOE Security Functions
3.1 Rationale for TOE security functions
detail in the text following the table (only in the full version of the Security Ta
Se ity ncti al R nts
F.RNG
F.HW_DES
F.HW_AES
F.OPC
F.PHY
F.LOG
F.COMP
F.MEM_ACC
F.SFR_ACC
FAU_SAS.1 X X
FCS_RND.1 X X
FDP_IFC.1 X X
FDP_ITT.1 X X
FMT_LIM.1 X X
FMT_LIM.2 X X
FPT_FLS.1 X X
FPT_ITT.1 X X
FPT_PHP.3 X
FPT_SEP.1[PP] X X
X
FRU_FLT.2 X X
FCS_COP.1[DES] X X
FCS_COP.1[AES X
] X
FPT_SEP.1[CON X
F]
FDP_ACC.1[MEM X X
]
FDP_ACC.1[SFR] X X
FDP_ACF.1[MEM] X X
FDP_ACF.1[SFR] X X
FMT_MSA.1[MEM] X X
FMT_MSA.1[SFR] X X
FMT_MSA.3[MEM] X X
FMT_MSA.3[SFR] X X
FMT_SMF.1 X X X
The "X" means that the TOE Security Function realizes or supports the functionality
required by the respective Security Functional Requirement.
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 63 of 72
As already stated in the definition of the security function there are a
features that can contribute to the security of the TOE when they are
controlled by the Smartcard Embedded Software. The CRC-co
verify
dditional security
sufficiently
mponent can be used to
the integrity of memory areas defined by the Smartcard Embedded Software, the
used to build leakage-resistant asymmetric crypto
8.
ll the assurance
ile defines assurance
s of EAL4, all input deliverables as
equirements of the PP. The
d production of
ment and
great number of
assurance measures, a detailed mapping of the assurance measures to the assurance
requirements is beyond the scope of this Security Target. Nevertheless the suitability of
asures is subject of different evaluation tasks. The documents "Quality
ual" and "Security Management Manual" describe the general
e Protection Profile
; registered and certified
he reference BSI-
rity requirements are
nd
r all additional
stated items in this ST do not contradict to the items included from the PP (see the
respective sections in this document). The operations done for the SFRs taken from the
PP are also clearly indicated.
The evaluation assurance level claimed for this target (EAL5+) is shown in section
5.1.1.5 to include respectively exceed the requirements claimed by the PP (EAL4+).
These considerations show that the Security Target correctly claims conformance to the
Smartcard IC Platform Protection Profile, [7].
FameXE co-processor can be
algorithms.
3.2 Rationale for assurance measures
The assurance measures defined in section 6.2 are considered to fulfi
requirements of the CC [3] level EAL5. Since the Protection Prof
measures that are suitable to fulfill the requirement
listed in section 6.2 shall be sufficient to fulfill the assurance r
assurance measures are defined especially for the development an
Smartcard ICs and observe also the refinements made in the PP.
As already explained in the Protection Profile, annex 8.1, the develop
production process of a smartcard IC is complex. Regarding the
the assurance me
Management Man
benchmark of NXP.
8.4 PP Claims Rationale
According to chapter 7 this Security Target claims conformance to th
“Smartcard IC Platform Protection Profile, Version 1.0, July 2001
by Bundesamt für Sicherheit in der Informationstechnik (BSI) under t
PP-0002-2001” [7].
The sections of this document where threats, objectives and secu
defined, clearly state which of these items are taken from the Protection Profile a
which are added in this ST. Therefore this is not repeated here. Moreove
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 64 of 72
9. Annexes
9.1 Further Information contained in the PP
The Annex of the Protection Profile ([7], chapter 9) provides fur
8.1 of the PP describes the development and production process o
containing a detailed life-cycle description and a description of the a
Integrated Circuits Designer/Manufacturer. Se
ther information. Section
f smartcards,
ssets of the
ction 8.2 is concerned with security
aspects of the Smartcard Embedded Software (further information regarding A.Resp-
ecific Functional Requirements for the Smartcard Embedded
ary and Voc
Note: To ease underst tection Profile [7]
is included here.
Administrator ria) The TOE may
ide security functions which can or need to be
mbedded Software
r delivery to
privileged user (in the sense of the
below) becomes
Boot Mode to the start-up of the
is not accessible for
.
Card Manufacturer rer who receives
ard Manufacturer
includes all roles after TOE Delivery up to Phase 7
nd Section 8.1.1).
facturer has the following roles (i) the
hase 5) and (ii) the
is delivered after
wn wafers (dice) he has
nufacturer (Phase 4) in
CPU mode he TOE supports
de, Mifare Mode,
Exception interrupts ble interrupt of program execution starting
from fixed (depending on exception source)
addressees and enabling the System Mode. The
sources of exceptions ar hardware breakpoints,
single fault injection detection, illegal instructions, stack
overflow, unauthorized system, User Mode execution
of RETI instruction and access violations or collisions.
FabKey Area A memory area in the EEPROM that contains data that
is programmed during testing by the IC Manufacturer.
The amount of data and the type of information can be
selected by the customer.
Appl and examples of sp
Software). Section 8.3 gives examples of Attack Scenarios.
9.2 Gloss abulary
anding of the used terms the glossary of the Pro
(in the sense of the Common Crite
prov
administrated (i) by the Smartcard E
or (ii) using services of the TOE afte
Phases 4-6. Then a
Common Criteria, refer to definition
an administrator.
CPU mode of the TOE dedicated
TOE after every reset. This mode
the Smartcard Embedded Software
The customer of the TOE Manufactu
the TOE during TOE Delivery. The C
(refer to [7], Figure 4 on page 17 a
The Card Manu
Smartcard Product Manufacturer (P
Personalizer (Phase 6). If the TOE
Phase 3 in form of wafers or sa
the role of the IC Packaging Ma
addition.
Mode in which the CPU operates. T
five modes, the Boot Mode, Test Mo
System Mode and User Mode.
Non-maska
e:
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 65 of 72
Integrated Circuit (IC) Electronic component(s) designed to pe
processing and/or memory function
IC proprietary software embedded in a smartcard I
(also known as IC firmware) and de
Developer. Such software is required for testing
purpose (IC Dedicated Test Software
rform
s.
IC Dedicated Software C
veloped by the IC
) but may provide
sage of the hardware
vices (IC Dedicated
rt Software (refer to above)
Delivery. The
oftware might be
IC Dedicated Test Sof efer to above)
e TOE Delivery but
ality thereafter.
tialisation Data nufacturer and
-volatile memory by the Integrated
r
r TOE identification
Memory , ROM and the
Memory Management sses used by the CPU
M, ROM and
ined by (a) the
ry segments in
ts are supported
ory partition is
ually (i) positioned
(iii) controlled by
write and execute and (iv)
nction Registers
e executed in
Memory Segment emory Management
MMU Segment
e which memory
ing in User Mode.
nd EEPROM.
MIFARE tandard, complying
Mifare Mode CPU mode of the TOE d icated for the execution of
IC Dedicated Support Software, i.e. the MIFARE
Operating System. This mode is not accessible for the
Smartcard Embedded Software.
MMU Segment Table This structure defines the segments that the Memory
Management Unit will used for code running in User
Mode. The structure can be located anywhere in the
available memory for System Mode code. It also
contains access rights for Special Function Registers
related to hardware components for User Mode code.
additional services to facilitate u
and/or to provide additional ser
Support Software).
IC Dedicated Suppo Part of the IC Dedicated Software
which provides functions after TOE
usage of parts of the IC Dedicated S
restricted to certain phases.
tware Part of the IC Dedicated Software (r
which is used to test the TOE befor
which does not provide any function
Ini Any data defined by the TOE Ma
injected into the non
Circuits manufacturer (Phase 3). These data are fo
instance used for traceability and fo
(identification data).
The memory comprises of the RAM
EEPROM of the TOE.
Unit The MMU maps the virtual addre
into the physical addresses of the RA
EEPROM. The mapping is determ
memory partition and (b) the memo
User Mode. Up to 64 memory segmen
for the User Mode, whereas the mem
fixed. Each segment can be individ
and sized (ii) enabled or disabled,
access permissions for read,
assigns access rights for Special Fu
related to hardware components for cod
User Mode from this segment.
Address spaces provided by the M
Unit based on its configuration (the
Table). The memory segments defin
areas are accessible for code runn
They are located in RAM, ROM a
Contact-less smart card interface s
with ISO14443A.
ed
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 66 of 72
Pre-personalization Da cturer that is
memory by the Integrated
ufacturer (Phase 3). These data are for
/or to secure
shipment between phases.
lying with ISO-
Security Row EEPROM memory reserved
as dedicated
mbedded Software to
bout the TOE.
[7]) Composition of
dded Software, User
rd carrier).
Smartcard Embedded d IC and not being
Smartcard
Phase 1 and
hase 3 or in later
ife-cycle.
tually implement a
provide standard
n doesn’t matter
ed Software can be
ependent whereas
itely not.
tion Regi onfigure the functions
ommunication with an external interface
rocessors for Triple-DES
ssor for basic arithmetic
ic cryptographic
e random numbers generator and chip
Super System Mode oot Mode, Test
e Mode.
em Mode cess to the
the memory
t Unit can be
Test Features All features and functions (implemented by the IC
Dedicated Test Software and/or hardware) which are
designed to be used before TOE Delivery only and
delivered as part of the TOE.
Test Mode CPU mode for configurat n of the TOE executing the
IC Dedicated Test Software. The Test Mode is
permanently and irreversible disabled after production
testing. In the Test Mode specific Special Function
Registers are accessible for test purposes.
ta Any data supplied by the Card Manufa
injected into the non-volatile
Circuits man
instance used for traceability and
S²C Smart card interface standard, comp
IEC-18092.
Top-most 128 bytes of the
for configuration purposes as well
memory area for the Smartcard E
store life-cycle information a
Smartcard (as used in the Protection Profile
the TOE, the Smartcard Embe
Data and the package (the smartca
Software Software embedded in a smartcar
developed by the IC Designer. The
Embedded Software is designed in
embedded into the Smartcard IC in P
phases of the smartcard product l
Some part of that software may ac
smartcard application others may
services. Nevertheless, this distinctio
here so that the Smartcard Embedd
considered as being application d
the IC Dedicated Software is defin
Special Func sters Registers used to access and c
for the c
device, the cryptographic co-p
or AES, the FameXE co-proce
functions to perform asymmetr
algorithms, th
configuration.
This mode represents either the B
Mode or Mifar
Syst The System Mode has unlimited ac
hardware resources (with respect to
partition). The Memory Managemen
configured in this mode.
io
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 67 of 72
TOE Delivery vered which is (refer to
elivered in form of
wafers or sawn wafers (dice) or (ii) after Phase 4 (or
is delivered in form of
TOE Manufacturer e TOE Manufacturer must ensure that all
evelopment and
(refer to [7], Figure
rer has the following roles: (i) IC
nufacturer (Phase
se 4 in form of
le of the (iii) IC Packaging
n.
TSF data hat might affect the
configuration data).
C.
tegrated Circuits
nd to keep track of
life-cycle phases
User ria) The TOE serves
ded Software.
AGD: guidance) is
ftware. Guidance is given
re Developer.
ith the TOE as a
inal where
e ISO interface
refore, another “user” of the
TOE is the terminal (with its software).
User Data All data managed by the Smartcard Embedded
Software in the application context. User data comprise
all data in the final Smartcard IC except the TSF data.
User Mode The User Mode has access to the memories under
control of the Memory Management Unit. The access
to the Special Function Registers is limited.
The period when the TOE is deli
[7], Figure 4 on page 17) either (i) after Phase 3 (or
before Phase 4) if the TOE is d
before Phase 5) if the TOE
modules.
Th
requirements for the TOE and its d
production environment are fulfilled
4 on page 17).
The TOE Manufactu
Developer (Phase 2) and (ii) IC Ma
3). If the TOE is delivered after Pha
modules, he has the ro
Manufacturer (Phase 4) in additio
Data created by and for the TOE, t
operation of the TOE (for example
Note that the TOE is the Smartcard I
Initialisation Data defined by the In
manufacturer to identify the TOE a
the product’s production and further
are also considered as belonging to the TSF data.
(in the sense of the Common Crite
as a platform for the Smartcard Embed
Therefore, the “user” of the TOE (as used in the
Common Criteria assurance class
the Smartcard Embedded So
for the Smartcard Embedded Softwa
On the other hand the Smartcard (w
major element) is used in a term
communication is performed through th
provided by the TOE. The
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 68 of 72
9.3 viations
Common Crite
List of Abbre
CC ria Version 2.0 or Version 2.1. Note that the
ically identical with Version
mmon Criteria.
EA .
mber Generator
ECC Cryptography
MMU agement Unit
A Non eement.
PP
PSW(H) h byte)
SAR Assurance Requirement.
SFR viation of the CC term: Security Functional
breviation of the technical term of the
mily: Special Function Register39
SIM Identity Module.
ST Target.
TSF Scope of control.
TSF TOE Security functions.
TSFI TSF Interface.
TSP TOE Security Policy.
UART Universal Asynchronous Receiver and Transmitter.
Version 2.1 (ISO 15408) is techn
2.0 of the Co
CIU Contact-less Interface Unit
CPU Central Processing Unit
D Data Encryption Algorithm
DES Data Encryption Standard.
DRNG Deterministic Random Nu
EAL Evaluation Assurance Level.
Elliptic Curve
IC Integrated circuit.
IT Information Technology.
Memory Man
MX Memory eXtension
ND Disclosure Agr
NFC Near Field Communication
PKC Public Key Cryptography
Protection Profile.
g
Program Status Word (Hi
Security
SF Security function.
as abbre
Requirement, as ab
SmartMX-fa
Subscriber
SOF Strength of function.
Security
TOE Target of Evaluation.
TRNG True Random Number Generator
TSC
39
This security target does not use SFR as abbreviation of Special Function Register in the explanatory
text to avoid confusion. However, the abbreviation is used in objective or security function identifiers
and to distinct iterations.
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 69 of 72
9.4 Bibliography
9.4.1
aluation – Part 1:
MB-2005-08-001
aluation – Part 2:
MB-2005-08-002
tion – Part 3:
B-2005-08-003
y Security Evaluation CEM-
05, CCMB-2005-
IS31:
dologie für physikalische
t für Sicherheit in der
stechnik
32: Übernahme
erpretationen ins deutsche
erheit in der
C Platform Protection Profile, Version 1.0, July 2001; registered and
k (BSI) under the
[8] Smartcard Integrated Circuit Platform Augmentations, Version 1.00, March 8th,
9.
cure dual interface
on 3.7,
Controller, Philips
4th, 2006
3/080/144V0B family of Secure Smart Card Controllers, NXP
Semiconductors, Business Line Identification, Version 1.8, February 15th, 2010
[12] Order Entry Form, P5CD080, NXP Semiconductors, Business Unit Identification,
Release 4.5, June 4th, 2010
[13] Order Entry Form, P5CN080, NXP Semiconductors, Business Line Identification,
Release 4.5, June 4th, 2010
[14] Order Entry Form, P5CC080, NXP Semiconductors, Business Line Identification,
Release 4.2, January 6th, 2010
Evaluation Documents
[1] Common Criteria for Information Technology Security Ev
Introduction and general model, Version 2.3, August 2005, CC
[2] Common Criteria for Information Technology Security Ev
Security functional requirements, Version 2.3, August 2005, CC
[3] Common Criteria for Information Technology Security Evalua
Security Assurance Requirements, Version 2.3, August 2005, CCM
[4] Common Methodology for Information Technolog
99/045 Part 2: Evaluation Methodology, Version 2.3, August 20
08-004
[5] Anwendungshinweise und Interpretationen zum Schema, A
Funktionalitätsklassen und Evaluationsmetho
Zufallszahlengeneratoren, Version 1, 25.09.2001, Bundesam
Information
[6] Anwendungshinweise und Interpretationen zum Schema, AIS
international abgestimmter CC-Int
Zertifizierungsschema, Version 1, 02.07.2001, Bundesamt für Sich
Informationstechnik
[7] Smartcard I
certified by Bundesamt für Sicherheit in der Informationstechni
reference BSI-PP-0002-2001
2002
4.2 Developer Documents
[9] Product Data Sheet, P5Cx012/02x/040/073/080/144 family, Se
and contact PKI smart card controller, NXP Semiconductors, Revisi
Document Number: 126537, June 4th, 2010
[10] Instruction Set, SmartMX-Family, Secure and PKI Smart Card
Semiconductors, Revision 1.1, Document Number: 084111, July 0
[11] Guidance, Delivery and Operation Manual for the
P5Cx012/02x/040/07
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 70 of 72
[15] Order Entry Form, P5CC073, NXP Semiconductors, Business Line Identification,
e 4.2, January 6th, 2010
9.4.3
PUB 46-3 FEDERAL INFORMATION PROCESSING STANDARDS
S) Reaffirmed 1999
), National Institute
of Standards and Technology, 2001 November 26
. RSA Laboratories,
s – Integrated
circuit(s) cards with contacts – Part 2: Dimensions and location of contacts
Identification cards – Integrated
d transmission
s integrated circuit(s)
integrated circuit(s)
cards – Proximity cards – Part 4: Transmission protocol
[23] ISO/IEC 18092:2004: Information technology – Telecommunications and
information exchange between systems – Near Field Communication – Interface
and Protocol (NFCIP-1)
[24] Mifare Interface Platform, V2.11, Philips Semiconductors, BL Identification
Releas
Other Documents
[16] FIPS
PUBLICATION DATA ENCRYPTION STANDARD (DE
October 25
[17] FIPS PUB 197 FEDERAL INFORMATION PROCESSING STANDARDS
PUBLICATION, ADVANCED ENCRYPTION STANDARD (AES
[18] PKCS #1: RSA Cryptography Specifications, Version 2.0
September 1998
[19] ISO/IEC 7816-2:1996 Information technology – Identification card
[20] ISO/IEC 7816-3:1997 Information technology –
circuit(s) cards with contacts – Part 3: Electronic signals an
protocols
[21] ISO/IEC 14443-3:2001 Identification cards – Contactles
cards – Proximity cards – Part 3: Initialization and anticollision
[22] ISO/IEC 14443-4:2001 Identification cards – Contactless
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073V0B
Security Target Lite
PUBLIC
© NXP B.V. 2010. All rights reserved.
Evaluation Documentation Rev. 1.9 — 14 July 2010 71 of 72
10. Legal information
10.1 Definitions
Draft — The document is a draft version only. The content is
internal review and subject to formal approval, which may res
modifications or addition
still u
ult in
s. NXP Semiconductors does not give any
s as to the accuracy or completeness
shall have no liability for the conse
s believ
es not ve any
irect, inciden
ithout limi -
d to the removal
er or not such
ch of
any reason
abi
cts described herein shall be limited in
of NXP
righ
itho
nd w
mation su
desi
rt, life-critical or
failure or
y be expected
on 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
itable and fit for the
nd products planned, as well as for the planned
stomer(s). Customers should
s to minimize the risks
any liability related to any default,
y weakness or default in the
application or use by customer’s
for doing all necessary
ducts using NXP
efault of the applications and
cation or use by customer’s third party
customer(s). NXP does not accept any liability in this respect.
ntrol — This document as well as the item(s) described herein
bject to export control regulations. Export might require a prior
rities.
.
10.3
nder
of
quences
application and use of customer’s third party cu
provide appropriate design and operating safeguard
associated with their applications and products.
NXP Semiconductors does not accept
damage, costs or problem which is based on an
customer’s applications or products, or the
representations or warrantie
information included herein and
of use of such information.
10.2 Disclaimers
Limited warranty and liability — Information in this document i
be accurate and reliable. However, NXP Semiconductors do
representations or warranties, expressed or implied, as to the
completeness of such information and shall have no liabilit
consequences of use of such information.
ed to
third party customer(s). Customer is responsible
testing for the customer’s applications and pro
Semiconductors products in order to avoid a d
the products or of the appli
gi
accuracy or
y for the
Export co
may be su
In no event shall NXP Semiconductors be liable for any ind
punitive, special or consequential damages (including - w
lost profits, lost savings, business interruption, costs relate
or replacement of any products or rework charges) wheth
tal,
authorization from national autho
tation
damages are based on tort (including negligence), warranty, brea
contract or any other legal theory.
Notwithstanding any damages that customer might incur for
whatsoever, NXP Semiconductors’ aggregate and cumulative li
towards customer f
lity
or the produ
accordance with the Terms and conditions of commercial sale
Semiconductors.
Right to make changes — NXP Semiconductors reserves the
changes to information published in this document, including w
limitation specifications and product descriptions, at any time a
notice. This document supersedes and replaces all infor
t to make
ut
ithout
pplied prior
to the publication hereof.
Suitability for use — NXP Semiconductors products are not
authorized or warranted to be suitable for use in life suppo
gned,
safety-critical systems or equipment, nor in applications where
malfunction of an NXP Semiconductors product can reasonabl
to result in personal injury, death or severe property or environmental
damage. NXP Semiconductors accepts no liability for inclusi
whether the NXP Semiconductors product is su
customer’s applications a
Licenses
ICs wi tion
th DPA Countermeasures func
NXP ICs containing functionality
implementing countermeasures to Differential
Power Analysis and Simple Power Analysis
d and sold under applicable
Cryptography Research, Inc.
are produce
license from
10.4 Trademarks
Notice: All referenced brands, product names, service names and
trademarks are property of their respective owners.
FabKey — is a trademark of NXP B.V.
Mifare — is a trademark of NXP B.V.
Mifare Plus — is a trademark of NXP B.V.
NXP Semiconductors P5CD080/ P5CN080/ P5CC080/ P5CC073 0B
Security Target Lite
V
PUBLIC
Please be aware that important notices concerning this document and the product(s)
described herein, have been included in the section 'Legal information'.
© NXP Semiconductors 2010. All rights reserved.
For more information, please visit: http://www.nxp.com
For sales office addresses, email to: sales.addresses@www.nxp.com
Date of release: 14 July 2010
1.
1 Contents
1. ST Introduction......................................... ..3
... 3
.... 3
1.2.1 .... ....3
2.2 .... ... ..5
a
.......... ..6
rance
... ....6
... ....
... ......
1 ... ....
2 ... ..10
3 ... 11
4 .......... 11
5 ... 12
6 .... 12
7 ... 13
8 ... 13
............13
2.1 ... 13
2.2 ... 14
2.3 ... 14
2.4 ... ...1
2.5 ... ..15
2.6 ... ..16
... ..16
4 ... 17
... 18
1 ... 18
... ..1
... 19
20
... 21
4.1 ... ..2
t ..........22
............................24
5.1 TOE Security Requirements.............................24
5.1.1 TOE Security Functional Requirements ...........24
5.1.1.1 SFRs of the Protection Profile..........................24
5.1.1.2 Additional SFRs regarding cryptographic
functionality ......................................................25
5.1.1.3 Additional SFRs regarding protection of
configuration data.............................................26
5.1.1.4 Additional SFRs regarding access control........27
5.1.1.5 SOF claim for TOE security functional
..................... ......37
quirements...........37
curity Assurance
..................... .....38
cope (ACM_SCP)39
tional specification
..................... .....39
e Environme .....40
e IT-Environment.40
e Non-IT-
..................... .....41
.............................42
..................... .....42
..................... .....49
..................... .....51
..................... .....51
le...........................51
ale .....................53
unctional requirements
..................... .....53
nctional
..................... ......59
Requirements and
el..........................61
utually Supportive
..................... .....61
Rationale ............62
unctions ................62
sures...................63
..................... .....63
..................... ......64
d in the PP...........64
..................... .....64
..................... .....68
..................... .....69
9.4.1 Evaluation Documents .....................................69
9.4.2 Developer Documents......................................69
9.4.3 Other Documents .............................................70
10. Legal information ..............................................71
10.1 Definitions.........................................................71
10.2 Disclaimers.......................................................71
10.3 Licenses ...........................................................71
10.4 Trademarks ......................................................71
11. Contents.............................................................72
......... requirements ................. ...
1.1 ST Identification ............................... ...
..
.
.
.
s
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
s
........... 5.1.2 TOE Security Assurance e
1.2 ST Overview......................................
Introduction ...................................... ...
........... 5.1.3 Refinements of the TOE S
Requirements................ ..
......
5.1.3.1 Refinements regarding C s
1. Life-Cycle ...................................... ...
Specific Issues of Smartcard Hardwa
..
.........
5.1.3.2 Refinements regarding fu c
1.2.3 re
Common Criteria..............................
nd the
..
...
(ADV_FSP).................... ..
...
1.3 CC Conformance and Evaluation As u
...
Level .............................................. ... .......
nt
5.2.1 Security Requirements fo th
2. TOE Description .............................. ... ... ...
5.2.2 Security Requirements fo th
...
. 7
... 7
Environment .................. ..
...
2.1 TOE Definition................................ ...
...
..
..... 8 6. TOE Summary Specificat n
...
2.1. Hardware Description..................... ... ..
6.1 TOE Security Functions.
2.1. Software Description ...................... ... ....... ..
6.2 Assurance Measures..... ..
...
2.1. Documentation............................... ...
..
.........
7. PP Claims........................ ..
2. Interface of the TOE.......................
1. ...
2. Life Cycle and Delivery of the TOE
..
......... 8. Rationale ......................... ...
a
1. ...
...
2.1. TOE Intended Usage ..................... ... ........
.........
8.1 Security Objectives Ration
8.2 Security Requirements Ration
..
2.1. TOE User Environment .................. ...
...
2.1. General IT features of the TOE...... ... ......... 8.2.1 Rationale for the security f
......................................
...
2.2 Evaluated hardware configurations
...
...
2 Major configuration P5CD080V0B .
...
. ...
. Major configuration P5CN080V0B .
.......
..
..
.......
8.2.2 Dependencies of securit u
2 ... ..
...
requirements ................. ..
2. Major configuration P5CC080V0B . ... ......
.
8.2.3 Rationale for the Assuran e
2. Major configuration P5CC073V0B . ... ..... 4 the Strength of Function v
2. Common minor configuration option ... ....... 8.2.4 Security Requirements a M
2. Configuration summary .................. ...
...
...
s
....... and Internally Consistent
2.3 Evaluated package types ............... ... .......
..
8.3 TOE Summary Specifica
2 Further Definitions and Explanation
. ... .......
n
.. 8.3.1 Rationale for TOE securi f
3. TOE Security Environment............. ...
...
...
...
...
...
...
...
R
e
....
M
n
....
r
r
r
....
io
....
....
....
...
....
y f
....
c
Le
re
......... 8.3.2 Rationale for assurance a
3. Description of Assets ..................... ... ......... 8.4 PP Claims Rationale ..... ..
3.2 Assumptions................................... ... ....... 8 9. Annexes........................... ..
3.3 Threats........................................... ... ......... 9.1 Further Information conta
3.4 Organisational Security Policies.......................
....... ...
e
4. Security Objectives..................
Security Objectives for the TOE..... ...
......... 9.3 List of Abbreviations ...... ..
....... 1 9.4 Bibliography................... ..
4.2 Security Objectives for the Environmen
5. IT Security Requirements .....
5.2 Security Requirements fo th
...
...
tio
ty
me
....
....
in
9.2 Glossary and Vocabulary ..
..
....
....