Open NFC - Security Stack
Document Type:
Reference:
Release Date:
File Name:
Security Level:
Functional Specification
FRS_NFC_1104-241 Version 0.4 (14516)
Dec. 27, 2011
FRS_NFC_1104-241 Open NFC - Security Stack.pdf
General Business Use
Check document version before use.
Copyright © 2011 Inside Secure
Open NFC - Security Stack
General Business Use
Page :
2/20
Date :
Dec. 27, 2011
Ref. :
FRS_NFC_1104-241 v0.4(14516)
Disclaimer
This document is licensed under the Creative Commons Attribution 3.0 license
(http://creativecommons.org/licenses/by/3.0/). (You may use the content of this document in
any way that is consistent with this license and if you give proper attribution
(http://www.open-nfc.org/license.html#attribution).
Copyright © 2011 Inside Secure
Open NFC and the Open NFC logo are trademarks or registered trademarks of Inside
Secure.
Other brand, product and company names mentioned herein may be trademarks, registered
trademarks or trade names of their respective owners.
Check document version before use.
Copyright © 2011 Inside Secure
Open NFC - Security Stack
General Business Use
Page :
3/20
Date :
Dec. 27, 2011
Ref. :
FRS_NFC_1104-241 v0.4(14516)
History
Version Date
0.1
0.2
0.3
0.4
Comments
April 20, 2011 Draft
May 15, 2011 Review for Comment
May 22, 2011 Release
Dec. 27, 2011 Release
for
Open
NFC
4.4.0
Adding alternative support for the GSMA specifications
Adding the support for the STK REFRESH event
Check document version before use.
Copyright © 2011 Inside Secure
Open NFC - Security Stack
General Business Use
Page :
4/20
Date :
Dec. 27, 2011
Ref. :
FRS_NFC_1104-241 v0.4(14516)
References
[FRS_NFC] FRS_NFC_0707-252 Open NFC - Functional Requirement Specification.pdf
(9962)
[GP211]
Card Specification, version 2.1.1, March 2003
GlobalPlatform
http://www.globalplatform.org
[GSMANFC]
NFC Handset APIs and Requirements - Version 2.0 – November 2011
GSM Association - http://www.gsm.org
[ISO7816-4] ISO/IEC 7816-4
Information technology – Identification cards - Integrated circuit(s) cards with
contacts - Part 4: Interindustry commands for interchange
Second edition, 2005-01-15
http://www.iso.org
[PKCS15]
PKCS #15 v1.1: Cryptographic Token Information Syntax Standard
RSA Laboratories; June 6, 2000
http://www.rsa.com/rsalabs/node.asp?id=2141
Check document version before use.
Copyright © 2011 Inside Secure
Open NFC - Security Stack
General Business Use
Page :
5/20
Date :
Dec. 27, 2011
Ref. :
FRS_NFC_1104-241 v0.4(14516)
Summary of Contents
1
Introduction ........................................................................................................ 6
1.1 Acronyms ............................................................................................................. 6
1.2 Overview .............................................................................................................. 8
1.2.1
1.2.2
1.2.3
Configuration .................................................................................................... 8
Main Components............................................................................................. 9
Integration ...................................................................................................... 10
2
Access Control File ......................................................................................... 12
2.1 INSIDE PKCS#15 Applet ................................................................................... 12
2.2 GSMA Access Control File ................................................................................ 13
3
Stack Functions ............................................................................................... 14
3.1 Configuration Detection ..................................................................................... 14
3.2 Policy Loading ................................................................................................... 15
3.3 Policy Checking ................................................................................................. 15
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.3.6
3.3.7
3.3.8
Filter Sessions ................................................................................................ 15
Select AID APDU ............................................................................................ 15
Select APDU with a partial/complete AID........................................................ 16
Select APDU with an empty AID ..................................................................... 16
Processing the answer of the Select AID command........................................ 17
Select APDU for a file ..................................................................................... 17
APDU Filtering ................................................................................................ 17
Transaction Event Filtering ............................................................................. 17
3.4 Policy Update..................................................................................................... 17
3.4.1
3.4.2
4
Checking the Policy Update ............................................................................ 18
Change Notifications....................................................................................... 18
Security ............................................................................................................ 19
4.1 Cryptographic Operations .................................................................................. 19
4.2 Security Assumptions ........................................................................................ 19
Check document version before use.
Copyright © 2011 Inside Secure
Open NFC - Security Stack
General Business Use
Page :
6/20
Date :
Dec. 27, 2011
Ref. :
FRS_NFC_1104-241 v0.4(14516)
1 Introduction
The Security Stack of Open NFC is a set of software protecting the access of the applets in
the stacked Secure Element or in the UICC.
The behavior of the stack is identical for the stacked Secure Element or for the UICC. In this
specification, both elements are called “SE”. The SE Applets are already protected by the
GlobalPlatform (GP) framework of the SE OS. The SE Applets protect themselves by
checking the APDU value received and using various encryption and authentication
mechanisms.
Above these protection mechanisms, the Security Stack provides an additional level of
control based on the signature of the device applications accessing the SE.
The Security Stack is in charge of the access control from the device applications. It does not
control or restrict the access from the RF interface.
The Security Stack is designed to manage different implementations and representations of
the access control rules. Access control rules are stored in an applet or files that comply with
the PKCS#15 specification (See [PKCS15]). There are no restriction to read the control
rules, a.k.a. ACL (applets and files are not protected for the read access). However, the
update of the access control rules is protected using an implementation-specific security
mechanism (eg. a PIN code or a secure channel).
The Security Stack currently supports two “ACL processor implementations”:
1. The Inside Secure PKCS#15 applet “INSIDE PKCS#15 Applet”.
2. The GSMA compliant PKCS#15 application or DF (as per [GSMA-NFC]).
1.1 Acronyms
Acronym
Meaning
ACE
Access Control Entry
ACIE
Access Control Index Entry
ACF
Access Control File
ACL
Access Control List
AID
Application identifier (ISO/IEC 7816)
APDU
Application Protocol Data Unit
BIP
Bearer Independent Protocol
DF
Dedicated File
EF
Elementary File
FCI
File Control Information
GP
GlobalPlatform
MF
Master File
OS
Operating System
OTA
Over The air
Check document version before use.
Copyright © 2011 Inside Secure
Open NFC - Security Stack
General Business Use
Acronym
Meaning
PIN
Personal Identification Number
PKCS
Public-Key Cryptography Standards
SCP
Secure Channel Protocol
SE
Secure Element
TLV
Tag Length Value
UICC
SIM card
Check document version before use.
Page :
7/20
Date :
Dec. 27, 2011
Ref. :
FRS_NFC_1104-241 v0.4(14516)
Copyright © 2011 Inside Secure
Open NFC - Security Stack
General Business Use
Page :
8/20
Date :
Dec. 27, 2011
Ref. :
FRS_NFC_1104-241 v0.4(14516)
1.2 Overview
1.2.1 Configuration
There are two types of configuration for the Security Stack:
Master Configuration
One of the configurations is used for the embedded SEs or the UICCs. In this configuration,
every communication with the SE/UICC is filtered by the Security Stack.
OTA Server
Application
OS API
OTA Agent
NFC API
OS
OS
Security
NFC
Stack
checking
appli.
signature
Security
Stack
Open NFC Library
Modem
Stack/RIL
SE communication
UICC communication
SE or UICC
PKCS#15 Applet/Files
Access Control
File
Check document version before use.
SE Applet
(identified by AID)
SE Applet
(identified by AID)
…
Copyright © 2011 Inside Secure
Open NFC - Security Stack
General Business Use
Page :
9/20
Date :
Dec. 27, 2011
Ref. :
FRS_NFC_1104-241 v0.4(14516)
Slave Configuration
The Slave Configuration is only used for the UICCs. In this configuration, the UICC may be
accessed through parallel channels independently of the Security Stack. For example the
OTA provisioning may be performed through a BIP stack.
OTA Server
Application
OS API
OS
OS
Security
NFC
Stack
checking
appli.
signature
Security
Stack
NFC API
Modem
Stack/RIL
Open NFC
Library
BIP Stack
UICC
PKCS#15 Applet/Files
SE Applet
(identified by AID)
Access Control
File
1.2.2 Main Components
Application and SE Applet
An Application, executed on top of the NFC Stack is accessing the SE Applet(s) located in
the SE. The Security Stack, included in the NFC Stack, is in charge of controlling the access
rights of the Application for the communication with the SE Applet(s).
There is no specific API introduced with the Security Stack. The Application is using the
normal SE communication functions of the NFC API. If the access is allowed by the Security
Stack, the communication with the SE Applet(s) is performed transparently. If the access is
not allowed, a security error is returned by the communication function to the Application and
the communication is not performed.
The Application does not need to be designed or modified for the Security Stack. The
Application code should just handle properly the errors returned by the SE communication
functions.
Check document version before use.
Copyright © 2011 Inside Secure
Open NFC - Security Stack
General Business Use
Page :
10/20
Date :
Dec. 27, 2011
Ref. :
FRS_NFC_1104-241 v0.4(14516)
The SE Applet does not need to be modified for the Security Stack.
PKCS #15 Applet (GSMA of INSIDE PKCS#15 Applet)
A specific applet, designed for the Security Stack is included in the SE. The purpose of this
application is to store the Access Control File (ACF) describing the access rights for all the
applets in the SE, including the PKCS#15 Applet itself. The PKCS#15 Applet implements a
simple file system defined in the PKCS#15 Specification [PKCS15].
The Security Stack reads the ACF from the PKCS #15 Applet. The ACF is not confidential;
there is not protection to read this file.
PKCS #15 Files (GSMA)
The policy files may also be stored in the file system of the SE/UICC. The Security stack
automatically detects this type of implementation.
OTA Agent (Master Configuration only)
A specific Application, the OTA Agent, executed on the Device is in charge of the
provisioning of the SE. This application downloads, removes, or configures the SE Applets
located in the SE. The OTA Agent communicates with the PKCS#15 Applet to update the
ACF with a content reflecting the changes in the SE Applets.
The integrity of the ACF is protected by the PKCS#15 Applet. The PKCS#15 Applet requires
the authentication of the Application for the update operations on the ACF.
Usually, the OTA Agent is just a proxy connected to a remote OTA Server.
An example of OTA Agent/OTA Server is provided with the Security Stack. They are just
meant to demonstrate the OTA functionality with the Security Stack.
1.2.3 Integration
Most of the Security Stack implementation is portable and independent of the OS where is
integrated the NFC stack. When the access policy is checked, the Security Stack has to
check that the Application is signed with a certificate included in the Policy File. This
identification operation is specific of the OS.
Check document version before use.
Copyright © 2011 Inside Secure
Open NFC - Security Stack
General Business Use
Page :
11/20
Date :
Dec. 27, 2011
Ref. :
FRS_NFC_1104-241 v0.4(14516)
The following figure details the architecture of the Security Stack:
Application
exchange APDU
OS
OS
Security
checking
appli.
signature
NFC
Stack
check
Security
Stack
load
read ACF
SE API
use
local copy
of ACF
APDU
Filter
exchange APDU
SE or UICC
PKCS#15 Applet
SE Applet
(identified by AID)
Access Control
File
The Security Stack is an optional component of Open NFC. The integration of this feature is
specified when the stack is compiled. If the Security Stack is not included in Open NFC,
there is no access control for the communication with the SE.
Check document version before use.
Copyright © 2011 Inside Secure
Open NFC - Security Stack
General Business Use
Page :
12/20
Date :
Dec. 27, 2011
Ref. :
FRS_NFC_1104-241 v0.4(14516)
2 Access Control File
2.1 INSIDE PKCS#15 Applet
The access policy applied by the Security Stack is defined by the content of the ACF. The
ACF follows the principle of the white list: The information in the file defines what is allowed.
If an access right is not explicitly defined in the ACF, the access is not granted. The content
of the ACF is defined by the PKCS#15 specification.
The following figure depicts the structure of the ACF:
Access Control File
ACE #1
ACIE #1
Cert Hash A
AID #1
Cert Hash B
…
ACIE #2
AID #1
Cert Hash X
APDU | Mask
ACIE #3
AID #1
…
APDU | Mask
…
APDU | Mask
ACIE #N
ACE #2
no AID
Cert Hash
…
Cert Hash
APDU | Mask
…
APDU | Mask
…
ACE #M
Access Control Index Entries
The file is organized with a list of Access Control Index Entries (ACIE). Each ACIE contains
an AID identifying the SE Applet protected by the ACIE. A specific ACIE without AID may be
present in the file. This specific ACIE defines the access to the SE Applet without dedicated
ACIE.
Several ACIE with the same AID may be present.
Check document version before use.
Copyright © 2011 Inside Secure
Open NFC - Security Stack
General Business Use
Page :
13/20
Date :
Dec. 27, 2011
Ref. :
FRS_NFC_1104-241 v0.4(14516)
Access Control Entries
The file contains a list of Access Control Entries (ACE). An ACE contains a list of application
principals and an APDU Filter. An application principal is generally the hash value of the
certificate required to check the signature of an Application. The exact nature of the principal
value may depend on the OS security system. If the list of principals is empty, the ACE
applies to any Application regardless of its signature.
Each ACIE is linked to one ACE. An ACE may be linked by several ACIEs.
APDU Filter
An APDU Filter defines the APDU allowed by an ACE. An APDU Filter is a list of entries
containing the 4 first bytes of the APDU and a 4-bytes mask used to compare with the APDU
value. An empty APDU Filter means that all APDUs are allowed.
2.2 GSMA Access Control File
The format of the access control files for the GSMA is specified in [GSMA-NFC].
Check document version before use.
Copyright © 2011 Inside Secure
Open NFC - Security Stack
General Business Use
Page :
14/20
Date :
Dec. 27, 2011
Ref. :
FRS_NFC_1104-241 v0.4(14516)
3 Stack Functions
The main functions of the stack are the following:
 Loading the ACL from the SE,
 Filtering the communication with the SE using the ACL information, and
 Updating the policy when the ACL is updated in the SE.
3.1 Configuration Detection
The ACL associated with a SE are stored in binary files organized as per specification
[PKCS15]. These files are themselves located either in a PKCS#15 application or under the
PKCS#15 DF. In both cases, the PKCS#15 files are read the same way, using SELECT and
READ BINARY commands.
The ACL may be represented using different encodings on the SE. However, once read, the
Security Stack uses a unified representation of the ACL. The purpose of “ACL processors” is
to read the ACL from a specific SE and build a unified ACL. The Security Stack shall then
use this unified ACL to perform APDU filtering. Two ACL processors are current defined:
1. The [GSMA-NFC]-compliant PKCS#15 ACL processor.
This ACL processor does not have rules for SE applet APDU filtering (Filtering is only
performed on the SE applet selection).
2. The ACL processor for the INSIDE PKCS#15 Applet.
This ACL processor does not manage “Default AID” rules and does not have negative
rules (that is, rules that explicitly deny access).
To read the ACL, the Security Stack proceeds as follows:
1. The Security Stack tries to select the PKCS#15 application by its well-known AID.
1.1. If the PKCS#15 application is present, the Security Stack asks each ACL processor
in sequence if it can process the access rules.
1.1.1. If an ACL processor fits, it then reads and builds the ACL.
1.1.2. Otherwise, the ACL is assumed to be empty.
Processing ends.
1.2. If the PKCS#15 application is not present, the Security Stack then tries to read the
EF(DIR) file under the MF to locate the PKCS#15 DF.
1.3. If the PKCS#15 DF is present, the Security Stack asks each ACL processor in
sequence if it can process the access rules.
1.3.1. If an ACL processor fits, it then reads and builds the ACL.
1.3.2. Otherwise, the ACL is assumed to be empty.
Processing continues on step 1.4 below.
If neither the PKCS#15 application nor the PKCS#15 DF is present on the SE, depending on
a Security Stack configuration option, access to the SE shall be either granted or denied. The
latter option is that recommended by [GSMA-NFC].
If the PKCS#15 application or DF is present on the SE, and the ACL is empty, then access to
the SE shall be denied, unless the calling application has DEFAULT_PRINCIPAL privileges.
Check document version before use.
Copyright © 2011 Inside Secure
Open NFC - Security Stack
General Business Use
Page :
15/20
Date :
Dec. 27, 2011
Ref. :
FRS_NFC_1104-241 v0.4(14516)
3.2 Policy Loading
The Security Stack loads the ACL from the SE when the NFC stack is booted, when a
removable SE is connected and when the ACL content is updated.
The read operation is performed without authentication using the ISO 7814-4 protocol
[ISO7816-4]. The complete ACL is read and copied in RAM.
For each Secure Element, a default access control right can be defined in the Security Stack.
This default access right is optional. If it is defined, the value is hardcoded in the code of the
security stack during the compilation. The default access control is defined by the principal
value DEFAULT_PRINCIPAL.

If the PKCS#15 applet is not found, depending on a Security Stack configuration
option, either no access control is performed or no application can access the Secure
Element (even if the application is signed with DEFAULT_PRINCIPAL).

If the PKCS#15 applet is found but the version of the applet is not valid, the ACL is
not loaded and the following policy is applied: For any AID, the applications signed
with DEFAULT_PRINCIPAL have unrestricted access. The other applications have
no access. If DEFAULT_PRINCIPAL is not defined, no application can access the
Secure Element.

If the PKCS#15 applet is found with the right version, the ACL is loaded. The
following policy is applied: For any AID, the applications signed with
DEFAULT_PRINCIPAL have unrestricted access. The other applications have the
access defined in the ACL. If DEFAULT_PRINCIPAL is not defined, the applications
have the access defined in the ACL.
3.3 Policy Checking
The security stack includes a hook in the API used to communicate with the SE. This hook
does not modify the APDUs exchanged with the SE. The value of the APDUs sent to the SE
is checked with the optional value of DEFAULT_PRINCIPAL and the policy information
included in the local copy of the ACF. If the APDU is not allowed, the APDU is not sent and
an error code is returned to the Application.
Only one Application can communicate with the SE at a given time.
3.3.1 Filter Sessions
A filter session starts with a “Select AID” APDU and includes the following APDUs
exchanged with the selected SE Applet. A filter session ends up when a new “Select AID”
APDU is sent or when the connection with the SE is cut off. The Security Stack interprets the
“manage logical channel” APDUs and can manage several filter sessions in parallel on
different logical channels. The Security Stack can be configured to manage between 4 and
20 logical channels in parallel.
3.3.2 Select AID APDU
There are 4 types of “Select AID” commands managed by the Security Stack:
 Select APDU including a complete AID
 Select APDU with partial AID
 Select APDU without AID
Check document version before use.
Copyright © 2011 Inside Secure
Open NFC - Security Stack
General Business Use

Page :
16/20
Date :
Dec. 27, 2011
Ref. :
FRS_NFC_1104-241 v0.4(14516)
Select APDU for a file
Select APDU commands with a complete AID or a partial AID cannot be distinguished in
practice (the only case the AID is complete is when its length is 16 bytes).
3.3.3 Select APDU with a partial/complete AID
A Filter Session starts with a “Select AID” APDU with an AID length in range 5 to 16. When
this APDU is intercepted by the Security Stack, the AID included in the APDU is used to
identify an ACIE in the local copy of the ACL. If no ACIE entry is found, the APDU is rejected.
When a matching ACIE is found, the Security Stack selects the corresponding ACE. If the
ACE explicitly denies access, the APDU is rejected. If the ACE contains an empty list of
principals, the Application does not need to be identified. Otherwise the Security Stack sends
the list of principals to the Security System of the OS. The Security System of the OS checks
if the calling Application is signed with one of the corresponding principals. If the Application
signature does not match any of the principals, the Security Stack looks for the next ACIE
with the same AID.
If the Application does not match any of the ACIE/ACE, the APDU is rejected.
If the Application matches one of the principals, the “Select AID” APDU is sent to the SE and
the APDU Filter of the selected ACE is associated to the Filter Session for the current logical
channel.
To deal with the case of selection with a partial AID, the answer to the “Select AID” command
shall be analyzed and checked against the ACL. See section 3.3.5 below.
3.3.4 Select APDU with an empty AID
A Filter Session starts with a “Select AID” APDU with an AID length of 0. When this APDU is
intercepted by the Security Stack, the empty AID is used to identify an ACIE in the local copy
of the ACL. If no ACIE entry is found, and if the ACL supports default AIDs, the APDU is
rejected.
When a matching ACIE is found, the Security Stack selects the corresponding ACE. If the
ACE explicitly denies access, the APDU is rejected. If the ACE contains an empty list of
principals, the Application does not need to be identified. Otherwise the Security Stack sends
the list of principals to the Security System of the OS. The Security System of the OS checks
if the calling Application is signed with one of the corresponding principals. If the Application
signature does not match any of the principals, the Security Stack looks for the next ACIE
with the same AID.
If the Application does not match any of the ACIE/ACE, and if the ACL supports default AIDs,
the APDU is rejected.
If the Application matches one of the principals, the “Select AID” APDU is sent to the SE and
the APDU Filter of the selected ACE is associated to the Filter Session for the current logical
channel.
To deal with the case of ACL not supporting the default AID, the answer to the “Select AID”
command shall be analyzed and checked against the ACL. See section 3.3.5 below.
Check document version before use.
Copyright © 2011 Inside Secure
Open NFC - Security Stack
General Business Use
Page :
17/20
Date :
Dec. 27, 2011
Ref. :
FRS_NFC_1104-241 v0.4(14516)
3.3.5 Processing the answer of the Select AID command
In case the “Select AID” APDU returns with success, which indicates that the SE Applet has
been selected, the FCI returned by the SE Applet is parsed to extract the Application AID
data element. The FCI is assumed to be formatted as a TLV with a tag ‘6F’ that contains the
Application AID in tag ‘84’. If the FCI is malformed or does not contain an Application AID,
the extracted AID is assumed to be initial AID.
In case the initial AID and the extracted AID are both empty, the empty AID is checked
against the ACL (that may contain a general rule). If the ACL denies access, the APDU is
rejected.
In case the initial AID was empty (cf section 3.3.4), the extracted AID is checked against the
ACL. If the ACL does not grant access, the APDU is rejected.
In case the initial AID is longer than the extracted AID, of if the initial AID does not match the
starting bytes of the extracted AID (which means the initial AID was not a partial AID), the
APDU is rejected.
In case the initial AID and the extracted AID are not the same (which may occur if the initial
AID was a partial AID), the extracted AID is checked against the ACL. If the ACL does not
explicitly grants access, the APDU is rejected.
3.3.6 Select APDU for a file
The only supported Select APDU command is the selection of the MF. The AID of the MF is
assumed to be ‘3F00’ (2-byte long).
The same rules as for the Select APDU command with a partial/complete AID apply, except
that the answer to the SELECT [MF] command is not analyzed.
3.3.7 APDU Filtering
After a “Select AID” APDU and the creation of a Filter Session for a logical channel, the
succeeding APDUs on this logical channel are controlled with the APDU filter of the ACE
linked to the Filter Session. If the APDU does not match the filter, the APDU is rejected and a
security error is returned. Otherwise the APDU is transmitted unmodified. If the APDU filter is
empty, no APDU filtering is performed.
3.3.8 Transaction Event Filtering
Transaction events are sent by the Secure Element or the NFC Controller when a transaction
event occurred between the Secure Element and the RF interface. The transaction events
include the AID(s) of the Secure Element application(s) accessed during the transaction. To
avoid the eavesdropping of the transaction events, the security stacks filters the transaction
event content. To receive a transaction event with a specific AID, an application shall have
access to the specified AID.
3.4 Policy Update
During the boot sequence of the Open NFC stack, the initial value of the ACF file is loaded in
the Security Stack. This chapter describes how the Security Stack is detecting a change in
the policy of the Secure Element. The purpose of the implementation is to download the new
version of the ACF each time the policy is modified while limiting the exchanges with the SE.
Check document version before use.
Copyright © 2011 Inside Secure
Open NFC - Security Stack
General Business Use
Page :
18/20
Date :
Dec. 27, 2011
Ref. :
FRS_NFC_1104-241 v0.4(14516)
3.4.1 Checking the Policy Update
The update of the ACL is triggered by a “modification flag” managed by the Security Stack. If
the modification flag is set, the ACL is loaded at the beginning of the next application
communication or before checking the access rights of next transaction event. When the
ACL is updated, the modification flag is reset.
Loading the ACL
Each time an Application modifies the content of the policy file, a time stamp or a counter is
updated in the PKCS#15 Applet/Files. This time stamp/counter feature is described in the
PKCS#15 specifications. The Security stack stores the value of the time stamp/counter with
the local copy of the ACL. The Security Stack detects a modification of the ACF by
comparing the local value with the value of the PKCS#15 Applet/Files.
3.4.2 Change Notifications
There are three strategies to detect an update of the policy file. The selection of the strategy
depends on the type of configuration (Master or Slave) and on the capabilities of the Secure
Element.
Master Configuration
In this configuration, the Security Stack monitors every communication with the SE so it can
detect the modification of the ACL. For the Security Stack, the OTA Agent is an application
like any other. The detection of a modification of the ACL is performed regardless of the
Application type. The Security Stack cannot monitor the payload of the update APDUs send
to the PKCS#15 Applet/Files because the update operation is performed on a Secure
Channel. The Security Stack detects that the PKCS#15 Applet/File was selected and an
update APDU was sent.
If a modification is detected, the Security Stack sets the “modification flag”.
Slave Configuration with Refresh Events
In this configuration, the policy may be changed through a communication link out of control
for the Security Stack. In case of modification, the SE sends a Refresh notification to inform
the Security stack of a change. A “modification flag” is set if the Policy files are modified.
Slave Configuration without Refresh Events
This is the worst case because the Security stack is not informed of the modification of the
Policy file. In this configuration the “modification flag” is always set so the ACL is loaded at
the beginning of each Application communication and before checking the access rights of
next transaction event.
Known Issue: This may create some latency at the beginning of each SE communication with
an Application.
Check document version before use.
Copyright © 2011 Inside Secure
Open NFC - Security Stack
General Business Use
Page :
19/20
Date :
Dec. 27, 2011
Ref. :
FRS_NFC_1104-241 v0.4(14516)
4 Security
The SE Applets are already protected by the GP framework of the SE OS. The SE Applets
protects themselves by checking the APDU values received and using various encryption,
integrity checking and authentication mechanisms.
Above these mechanisms, the Security Stack provides an additional level of protection based
on the signature of the device applications accessing the SE. This protection relies on the
device OS integrity and on the application signature checking of the device OS. The Security
Stack provides no additional control for the identity checking of the application. So the
perimeter of the protection provided by the Security Stack is limited by the potential
weakness of the OS.
The Security Stack is in charge of the access control from the device applications. It does not
control or restrict the access from the RF interface.
4.1 Cryptographic Operations
The Security Stack does not perform any cryptographic operations (encryption,
authentication, hash operation, or signature verification); the stack does not store
cryptographic keys. This is due to the architecture of the stack:
 The Security Stack performs only reading operations with the PKCS#15 Applet.
Reading operations are performed in clear, without Secure Channel Protocol (SCP).
 The update operation of the ACF file is performed by a remote OTA Server. The
communication is transmitted transparently through the OTA Agent and possibly
through the Security Stack.
 The Security Stack delegates the verification of the Application signature to the OS.
Special Case: INSIDE PKCS#15 Applet
Updating the ACF and the time stamp in the PKCS#15 applet requires a successful
GlobalPlatform-compliant mutual authentication, using Secure Channel Protocol (SCP) '02'
option i=15, with a C-MAC security level (See [GP211]).
The PKCS#15 Applet does not perform any cryptographic operations (encryption,
authentication, hash operation, or signature verification) the applet does not store
cryptographic keys. This is due to the architecture of the applet:
 The PKCS#15 Applet does not control the content of the ACF.
 The PKCS#15 Applet does not control the content of the update Time Stamp.
 The PKCS#15 Applet delegates the management of the Secure Channel Protocol
(SCP) to the GlobalPlatform framework of the SE OS.
Special Case: UICC with OTA provisioning
In most cases the UICC is provisioned via the BIP protocol, independently of the Security
Stack.
4.2 Security Assumptions
The following assumptions shall all be true to guaranty the functionality of the Security Stack:
 The integrity of Device hardware is not compromised. This includes the Device, the
NFC Controller, the SE and the communication links between these elements.
 The integrity of the Device OS is not compromised
 The integrity of the code, data and behavior of the NFC Stack and Security Stack OS
is not compromised
Check document version before use.
Copyright © 2011 Inside Secure
Open NFC - Security Stack
General Business Use








Page :
20/20
Date :
Dec. 27, 2011
Ref. :
FRS_NFC_1104-241 v0.4(14516)
The integrity of the Security System of the Device OS checking the Application
signature is not compromised
An Application cannot fake its identity (no identity spoofing).
The OS guaranties that the integrity of the code and data of an Application cannot be
compromised before its execution without being detected by the signature checking
of the Device OS.
The OS guaranties that the integrity of the code, data and behavior of an Application
cannot be compromised during its execution.
The integrity of NFC Controller firmware is not compromised.
The integrity of GP security system of the SE is not compromised.
The provisioning of the SE maintains the consistency of the ACF in the PKCS#15
applet with the SE Applets.
The provisioning of the SE updates the time stamp of the PKCS#15 applet when the
content of the ACF is updated.
Then the Security Stack, including the PKCS#15 Applet, guarantees that:
 An Application can send APDUs to a SE Applet only if the Application signature and
the APDU values are authorized for this SE Applet in the ACF stored in the PKCS#15
Applet.
 The integrity of the ACF stored in the PKCS#15 Applet is not compromised.
Check document version before use.
Copyright © 2011 Inside Secure