Open NFC - Security Stack Specification

Open NFC - Security StackSpecificationDocument Type: Software Technical SpecificationReference: STS_NFC_1104-242 Version 0.6 (14516)Release Date: Dec. 27, 2011File Name: STS_NFC_1104-242 Open NFC - Security Stack Specification.pdfSecurity Level: General Business UseCheck document version before use.Copyright © 2011 Inside Secure

Open NFC - Security Stack SpecificationGeneral Business UsePage : 2/20Date : Dec. 27, 2011Ref. : STS_NFC_1104-242 v0.6(14516)DisclaimerThis 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 inany way that is consistent with this license and if you give proper attribution(http://www.open-nfc.org/license.html#attribution).Copyright © 2011 Inside SecureOpen NFC and the Open NFC logo are trademarks or registered trademarks of InsideSecure.Other brand, product and company names mentioned herein may be trademarks, registeredtrademarks or trade names of their respective owners.Check document version before use.Copyright © 2011 Inside Secure

Open NFC - Security Stack SpecificationGeneral Business UsePage : 3/20Date : Dec. 27, 2011Ref. : STS_NFC_1104-242 v0.6(14516)HistoryVersion DateComments0.1 April 20, 2011 First Draft0.2 May 13, 2011 Fixing issue in the PKCS#15 applet install methodUpdating the PKCS#15 applet documentation (fixed the description ofthe SELECT[AID] command)0.3 May 16, 2011 Review for Comment0.4 Aug. 17, 2011 Technology preview for Open NFC 4.3.1Adding the UICC support0.5 Sept. 7, 2011 Release for Open NFC 4.3.1Adding the UICC support0.6 Dec. 27, 2011 Release for Open NFC 4.4.0Adding alternative support for the GSMA specificationsAdding the support for the STK REFRESH eventCheck document version before use.Copyright © 2011 Inside Secure

Open NFC - Security Stack SpecificationGeneral Business UsePage : 4/20Date : Dec. 27, 2011Ref. : STS_NFC_1104-242 v0.6(14516)References[FRS-SEC] FRS_NFC_1104-241 Open NFC - Security Stack.pdf (14516)[PKCS15-INSIDE]STS_NFC_1104-240 Open NFC - PKCS15 Applet 1.0 Specification.pdf(14516)[STA-NFC] STA_NFC_0708-007 Open NFC - Global Architecture.pdf (14516)[GP211] Card Specification, version 2.1.1, March 2003GlobalPlatformhttp://www.globalplatform.org[GSMA-NFC]NFC Handset APIs and Requirements - Version 2.0 – November 2011GSM Association - http://www.gsm.org[HCI]Smart Cards; UICC - Contactless Front-end (CLF) Interface; Host ControllerInterface (HCI) (Release 10)ETSI TS 102 622 V10.2.0 (2011-03)[ISO7816-4] ISO/IEC 7816-4Information technology – Identification cards - Integrated circuit(s) cards withcontacts - Part 4: Interindustry commands for interchangeSecond edition, 2005-01-15http://www.iso.org[PKCS15]PKCS #15 v1.1: Cryptographic Token Information Syntax StandardRSA Laboratories; June 6, 2000http://www.rsa.com/rsalabs/node.asp?id=2141Check document version before use.Copyright © 2011 Inside Secure

Open NFC - Security Stack SpecificationGeneral Business UsePage : 5/20Date : Dec. 27, 2011Ref. : STS_NFC_1104-242 v0.6(14516)Summary of Contents1 Introduction ........................................................................................................ 61.1 Overview .............................................................................................................. 62 Global Architecture ........................................................................................... 72.1 Type of Secure Element ...................................................................................... 92.1.1 ISO 14443 Interface .......................................................................................... 92.1.2 SE HAL ............................................................................................................. 92.1.3 HCI over SWP .................................................................................................. 92.2 Authentication ...................................................................................................... 92.2.1 Client Identifier .................................................................................................. 92.2.2 Authentication Data ........................................................................................ 102.2.3 Authentication Procedure ................................................................................ 112.2.4 Example of Implementation: ........................................................................... 122.3 ACL management .............................................................................................. 122.3.1 ACL format ..................................................................................................... 122.3.2 ACL checking algorithm .................................................................................. 132.3.3 Specific behavior ............................................................................................ 152.4 ACL Loading ...................................................................................................... 152.4.1 Initial Loading ................................................................................................. 162.4.2 ACL Processors .............................................................................................. 162.4.3 Selection of the PKCS#15 application or DF ................................................... 172.4.4 Processing of the access control rules in the GSMA ACL Processor .............. 172.4.5 Processing of the access control rules in the PKCS15 ACL Processor ........... 182.4.6 Update Loading .............................................................................................. 193 Integration ........................................................................................................ 20Check document version before use.Copyright © 2011 Inside Secure

Open NFC - Security Stack SpecificationGeneral Business UsePage : 6/20Date : Dec. 27, 2011Ref. : STS_NFC_1104-242 v0.6(14516)1 IntroductionThis document describes the implementation of the security stack of Open NFC.1.1 OverviewThe Security Stack of Open NFC is a set of software protecting the access of the applets inthe stacked Secure Element or in the UICC. The following figure depicts the maincomponents of the system:OTA ServerApplicationOTA AgentOS APINFC APIOSOSSecurityNFCStackOpen NFC Librarycheckingappli.signatureSecurityStackModemStack/RILSE communicationUICC communicationSE or UICCPKCS#15 AppletAccess ControlFileSE Applet(identified by AID)…SE Applet(identified by AID)Check document version before use.Copyright © 2011 Inside Secure

Open NFC - Security Stack SpecificationGeneral Business UsePage : 7/20Date : Dec. 27, 2011Ref. : STS_NFC_1104-242 v0.6(14516)2 Global ArchitectureThe following figure details the functional architecture of the Security Stack:ApplicationOSexchange APDUOSSecurityNFCStackSE APIcheckingappli.signaturecheckSecurityStackloadlocal copyof ACFuseAPDUFilterread ACFexchange APDUSE or UICCPKCS#15 AppletAccess ControlFileSE Applet(identified by AID)Check document version before use.Copyright © 2011 Inside Secure

Open NFC - Security Stack SpecificationGeneral Business UsePage : 8/20Date : Dec. 27, 2011Ref. : STS_NFC_1104-242 v0.6(14516)The following figures details the modules and the interfaces involved with the security stack:Logical channel interfaceRaw interfaceApplicationAPI 14443 4API 7816ClientImplementationRF Card7816 SMSE (SE or UICC)adapterISO 14443 4ISO 14443 4 cleint/serverSE Client/ServerServerImplementationSecurity StackSEUICCSWP7816 SMchannel over SE HAL7816 SMRF Card orSEISO 14443 4raw over 14443raw over SWPSWPPortingExample on Windows7816 SMSE HALConnection Centerraw over PCSCPCSCCheck document version before use.Copyright © 2011 Inside Secure

Open NFC - Security Stack SpecificationGeneral Business UsePage : 9/20Date : Dec. 27, 2011Ref. : STS_NFC_1104-242 v0.6(14516)2.1 Type of Secure ElementThere are 3 types of Secure Element: The Secure Element accessed through the ISO 14443RF interface (Stacked Secure Element), the Secure Element accessed through the SE HALor the Secure Element accessed through HCI over SWP.2.1.1 ISO 14443 InterfaceThe Secure Elements are accessed with the RF as if they were external cards. A specificswitch in the NFC Controller activates the communication with the SE.2.1.2 SE HALThe Secure Elements are accessed through a specific Secure Element HAL.2.1.3 HCI over SWPA proprietary protocol is used to communicate with the Secure Element on top of SWP. TheHCI standard (see [HCI]) does not include a command to exchange APDU.The SE SHALL implement the following proprietary command on the connectivity pipe:On the connectivity gate ‘41’, the SE shall accept the exchange APDU command:Value Command‘15’ EXCHANGE_APDUThis command has following parameters:DescriptionLengthThe T=1 APDU buffer N != 0Upon reception of this command, the SE SHALL execute the APDU and send the responseAPDU with the answer ANY_OK with parameter as follows:2.2 AuthenticationDescriptionLengthThe T=1 R- APDU buffer N != 0This section describes the authentication process used by the security stack.2.2.1 Client IdentifierThe client identifier is a set of data “CLIENT_ID_DATA” representing the identity of anapplication calling the Open NFC stack. This set of data is created by the porting layer in thekernel/server part of the stack when the application connects to the stack.Example of client identifier:Configuration OS Client IdentifierMonolithic any The process/task identifier of the current process/task.On Linux, the group id and the user id of the processis added.Check document version before use.Copyright © 2011 Inside Secure

Open NFC - Security Stack SpecificationGeneral Business UsePage : 10/20Date : Dec. 27, 2011Ref. : STS_NFC_1104-242 v0.6(14516)User/Driver any The process/task identifier of the user process/task.On Linux, the group id and the user id of the processis added.Client/Server Win XP/7 The process identifier of the client application retrievedfrom the pipe.Client/ServerLinux (includingother Linuxbased OS)Client/Server Other OS The process/task identifierThe process identifier, the group id and the user id ofthe calling process. This information is sent with acredential message on the socket, checked by theLinux kernel.The client identifier data is kept in kernel/server part of the stack and stored in a structurerepresenting the client application instance.The CLIENT_ID_DATA structure is opaque for the Open NFC stack. The content is createdand used by the porting layer of Open NFC. A CLIENT_ID_DATA structure is allocated andfilled by the porting layer when a new client application is connected to the stack. The portinglayer destroys/frees the structure when the application is disconnected for any reason.2.2.2 Authentication DataA new API is added to authenticate a calling application: WSecurityAuthenticate(). Thisfunction creates the OS-specific authentication information for the application, theAUTH_DATA.Some application authentication data (APP_AUTH_DATA) is provided by the caller ofWSecurityAuthenticate(). This data is provided directly by the caller for a native application.When Open NFC is integrated in a framework such as Android, APP_AUTH_DATA iscreated by the framework, transparently for the application. The APP_AUTH_DATA structureis opaque for the Open NFC stackExample of application authentication data:OS/callerAndroidapplicationAndroid nativeapplicationWin XP/7J2ME AppletApplication Authentication DataThe certificate list used to sign the APK of the calling application.This value cannot be counterfeited by the application because thefunction WSecurityAuthenticate() is only accessible from the portinglayer.nullnullThe certificate list used to sign the package of the calling application.The isolate identifier may be added is isolate are supported.This value cannot be counterfeited by the application because thefunction WSecurityAuthenticate() is only accessible from the portinglayer.The function sends APP_AUTH_DATA from the user/client library to the security manager inthe kernel/server part of the stack. The security manager calls the porting functionCheck document version before use.Copyright © 2011 Inside Secure

Open NFC - Security Stack SpecificationGeneral Business UsePage : 11/20Date : Dec. 27, 2011Ref. : STS_NFC_1104-242 v0.6(14516)CSecurityCreateAuthenticationData() with APP_AUTH_DATA and the currentCLIENT_ID_DATA of the calling application.CSecurityCreateAuthenticationData() is a porting function building AUTH_DATA fromAPP_AUTH_DATA and CLIENT_ID_DATA. The implementation ofCSecurityCreateAuthenticationData() and the content of AUTH_DATA is specific to theporting layer of Open NFC.The AUTH_DATA structure is opaque for the Open NFC stack. The content is created andused by the porting layer of Open NFC. Open NFC allocates the AUTH_DATA structurewhen an authentication is performed. The AUTH_DATA structure is kept in kernel/server partof the stack and stored in a structure representing the client application instance. Open NFCfrees the structure when the application is disconnected for any reason.Simple Implementation:A simple implementation of CSecurityCreateAuthenticationData() would be to create astructure including both CLIENT_ID_DATA and APP_AUTH_DATA.2.2.3 Authentication ProcedureThe Security Stack uses the AUTH_DATA of the current application to check the identity ofthe caller. The Security Stacks compares AUTH_DATA with the values of the “principals”(calling application identifiers stored in the PKCS#15 Application, see [PKCS15-APP]). Theactual comparison is performed by the porting function CSecurityCheckIdentity().ApplicationconnectionPorting(client/server)(user/driver)(monolithic)SecurityStackSecurityManagerHAL PortingBuild CLIENT_ID_DATAWSecurityAuthenticate()APP_AUTH_DATACSecurityCreateAuthenticationData()CLIENT_ID_DATAAPP_AUTH_DATABuild AUTH_DATAAUTH_DATAExchange APDUWSecurityCheckIdentity()Principal dataresultCSecurityCheckIdentity()AUTH_DATAPrincipal dataresultCheck PrincipalresultCheck document version before use.Copyright © 2011 Inside Secure

Open NFC - Security Stack SpecificationGeneral Business UsePage : 12/20Date : Dec. 27, 2011Ref. : STS_NFC_1104-242 v0.6(14516)2.2.4 Example of Implementation:The following table describes the implementation of the Security functions for some currentimplementations.Porting for J2ME on top of any OSObjectImplementationCLIENT_ID_DATA The process/task identifier of the currentprocess/task.On Linux, the group id and the user id of the processis added.APP_AUTH_DATAThe certificate list used to sign the package of thecalling application. The certificate value are replacedby their SHA1 hash value.The isolate identifier may be added is isolate aresupported.This value cannot be counterfeited by the applicationbecause the function WSecurityAuthenticate() is onlyaccessible from the porting layer.CSecurityCreateAuthenticationData() Create AUTH_DATA as the concatenation ofCLIENT_ID_DATA and APP_AUTH_DATA.CSecurityCheckIdentity()Checks that the principal value (ie. The SHA1 hashvalue of a certificate), matches the SHA1 hash valueof one of the certificate in the certificate list ofAPP_AUTH_DATA.2.3 ACL managementWhen the Security Stack reads the ACL from a Secure Element, it builds in RAM an internalrepresentation that is used when APDU commands sent to that Secure Element must bechecked against the ACL.The Security Stack currently supports two formats for the ACL:1. The GSMA format (a.k.a. GlobalPlatform format)2. The PKCS15 Applet formatThese ACL formats differ in the way they are stored and accessed in the Secure Element.Basically, the APDU command set used to read the ACL differs and the ACL encoding isspecific to each format.2.3.1 ACL formatThe internal representation of an ACL contains a list of ACIE (Access Control Index Entry)and a list of ACE (Access Control Entry) data elements.An ACIE represents an access condition associated with an AID value. The AID may be thedefault AID (empty AID), a specific AID or all AIDs. The access condition is coded into anACE and pointed to from the ACIE. Several ACIE may point to the same ACE.An ACE represents a list of Principal IDs and a list of APDU permissions.Check document version before use.Copyright © 2011 Inside Secure

Open NFC - Security Stack SpecificationGeneral Business UsePage : 13/20Date : Dec. 27, 2011Ref. : STS_NFC_1104-242 v0.6(14516)• The list of Principal IDs is associated with a type that indicates whether the listedPrincipal IDs must be denied or granted. An empty list of Principal IDs is used to refer toall Principal IDs.The three following configurations are possible:- Access is denied to all Principals.- Access is granted to all Principals.- Access is granted to a non-empty list of Principals.• The list of APDU Permissions is associated with a type that indicates whether thespecified APDU commands must be allowed or forbidden. An empty list of APDUPermissions is used to refer to all APDU Permissions.The three following configurations are possible:- Access is denied for all APDU commands- Access is granted for all APDU commands- Access is granted for a non-empty list of APDU commands2.3.2 ACL checking algorithmWhen the Security Stack uses the ACL to check whether an APDU command can be sent tothe Secure Element, it must handle three possible cases:1. The AID to be checked is the AID passed to a SELECT [AID] command. This AID can beeither the default AID (empty AID) or a non-empty AID.2. The AID to be checked is the AID extracted from the FCI returned by the SELECT [AID]command. This AID may be different from the AID passed to the SELECT [AID]command, mandatorily if the passed AID was the default AID or a partial AID.3. The APDU command to be checked is sent to an application previously successfullyselected on the basic channel or a supplementary logical channel. The APDU commandheader along with the application AID (which may be empty in case it is unknown) arechecked against the ACL.During the verification of the APDU and AID against the ACL, the Security Stack first checksthe specific rules (that is, the ACIE containing the default AID or a specific AID) and, if norule applies, then checks the general rules (that is, the ACIE associated with all AIDs).A rule applies if the AID, the APDU command and the Principal ID of the currently executingapplication all match the data elements of an ACIE and its associated ACE. If at least amatching rule denies access, then the Security Stack returns a W_ERROR_SECURITYerror, which forbids the APDU to be sent to the Secure Element. Otherwise, if a matchingrule grants access, then the Security Stack returns a W_SUCCESS error code, which allowsthe APDU command to be sent to the Secure Element. Under some conditions during thefiltering of the SELECT [AID] command, the Security Stack may need to analyze the answerof SELECT [AID], which is likely a FCI that contains the AID of the selected application.The following algorithm is implemented by the PSecurityStackCheckAcl function:1. Processing of the specific rules: For each ACIE, do the following:1.1. AID matching1.1.1. If the ACIE AID is “All AIDs”, then remember that a general rule has beenfound and continue on step 1.2.1.1.2. If the ACIE AID is the default AID and the checked AID is the default AID (rulefound), then continue on step 1.2.Check document version before use.Copyright © 2011 Inside Secure

Open NFC - Security Stack SpecificationGeneral Business UsePage : 14/20Date : Dec. 27, 2011Ref. : STS_NFC_1104-242 v0.6(14516)1.1.3. If the ACIE AID is a specific AID, and the checked AID is the same as thisspecific AID (rule found), then continue on step 1.2.1.1.4. Otherwise, continue on step 1 with the next ACIE.1.2. Principal ID matching1.2.1. If the ACIE principals are “all granted” (rule found), then continue on step 1.3.1.2.2. If the ACIE principals are “all denied”, then return with a security error.1.2.3. If the ACIE principals are a list, then check whether the Principal ID of thecalling application is present in the list. If not, continue on step 1 with the nextACIE. Otherwise (rule found), continue on step 1.3.1.3. APDU permission matching1.3.1. If the ACIE APDU permissions are “all granted”, then continue on step 1.4.1.3.2. If the ACIE APDU permissions are “all granted”, then return with a securityerror.1.3.3. If the ACIE APDU permissions are a list and if the checked APDU is not aSELECT [AID] command, then check whether the checked APDU matches oneof the APDU permissions. If not (rule not found), continue on step 4 with the nextACIE. Otherwise (rule found), continue on step 1.4.Check document version before use.Note: A matching APDU verifies the following condition:APDUPermission.Header = APDU.Header AND APDUPermission.Mask1.3.4. Continue on step 1.4.1.4. Access is granted.This ACIE grants access, but other ACIE may deny access: Continue on step 1.2. If access was granted by at least a specific rule:2.1. If the checked APDU is a SELECT [AID] command and the checked AID is thedefault AID, return success: APDU is accepted.2.2. If the checked APDU is a SELECT [AID] command, return success and indicate thatthe answer to SELECT [AID] must be analyzed to check the FCI AID against theACL.2.3. Otherwise, return success.3. If access was not granted by a specific rule, and if no general rule was found, then returna security error.4. Processing of the general rules: For each ACIE, do the following:4.1. AID matching4.1.1. If the ACIE AID is “All AIDs”, then continue on step 4.2.4.1.2. Otherwise, continue on step 4 with the next ACIE.4.2. Principal ID matching4.2.1. If the ACIE principals are “all granted” (rule found), then continue on step 4.3.4.2.2. If the ACIE principals are “all denied”, then return with a security error.4.2.3. If the ACIE principals are a list, then check whether the Principal ID of thecalling application is present in the list. If not (rule not found), continue on step 4with the next ACIE. Otherwise (rule found), continue on step 4.3.4.3. APDU permission matching4.3.1. If the ACIE APDU permissions are “all granted”, then continue on step 4.4.Copyright © 2011 Inside Secure

Open NFC - Security Stack SpecificationGeneral Business UsePage : 15/20Date : Dec. 27, 2011Ref. : STS_NFC_1104-242 v0.6(14516)4.3.2. If the ACIE APDU permissions are “all granted”, then return with a securityerror.4.3.3. If the ACIE APDU permissions are a list and if the checked APDU is not aSELECT [AID] command, then check whether the checked APDU matches oneof the APDU permissions. If not (rule not found), continue on step 4 with the nextACIE. Otherwise (rule found), continue on step 4.4.4.3.4. Continue on step 4.4.4.4. Access is granted.This ACIE grants access, but other ACIE may deny access: Continue on step 4.5. If access was granted by at least a general rule:5.1. If the checked APDU is a SELECT [AID] command and the checked AID is thedefault AID, return success: APDU is accepted.5.2. If the checked APDU is a SELECT [AID] command, return success and indicate thatthe answer to SELECT [AID] must be analyzed to check the FCI AID against theACL.5.3. Otherwise, return success.6. If the checked AID is the default AID and if the ACL manages default AIDs (which is notthe case of the PKCS15 Applet), return success and indicate that the answer to SELECT[AID] must be analyzed to check the FCI AID against the ACL.7. Otherwise, return a security error.2.3.3 Specific behaviorThe Security Stack implements the following behavior in case the PKCS#15 application orDF is absent, or if the ACL reading failed.• If the PKCS#15 application or DF is absent, there are two cases:1. If the GSMA requirements are mandated (that is, if the “porting_config.h” filedefines the P_NO_UICC_ACCESS_BY_DEFAULT symbol), then access to theSE is denied, even if the calling application has DEFAULT_PRINCIPAL privileges.2. If the GSMA requirements are not mandated, access to the SE is granted to allapplications.• If the PKCS#15 application or DF is present, and if the ACL is empty (that is, the ACLreading failed for whatever reason), access to the SE is granted to applications that havethe DEFAULT_PRINCIPAL privilege. Otherwise, access to the SE is denied.• If the PKCS#15 application or DF is present, and if the ACL is valid, access to the SE isgranted to applications that have the DEFAULT_PRINCIPAL privilege. Otherwise, accessto the SE is controlled by the ACL (see section 2.3.2).2.4 ACL LoadingThis section describes the ACL Loading process. The ACL is loaded from the PKCS#15Applet or DF when the NFC stack is started and when the ACL file is modified.Check document version before use.Copyright © 2011 Inside Secure

Open NFC - Security Stack SpecificationGeneral Business UsePage : 16/20Date : Dec. 27, 2011Ref. : STS_NFC_1104-242 v0.6(14516)2.4.1 Initial LoadingThe initial loading of the ACL is performed during the Open NFC boot sequence for all SEconnected to the Open NFC stack. As many tSecurityStackInstance data structures asconnected SE are then allocated.The loading of the ACL is performed in the PSecurityStackLoadAcl function, which is alsocalled each time a client application connects to the SE. This function reloads the ACL onlyin case the ACL have been or may have changed since the last call to this function.2.4.2 ACL ProcessorsThe Security Stack can manage different implementations of the ACL stored into thePKCS#15 application or DF of the SE. The specific management is grouped into a so-calledACL processor that is responsible for loading and building the ACL.Differences may reside in the APDU command set supported (although, with PKCS#15, onlythe standard SELECT and READ BINARY commands hall be used) and in the way the ACLis encoded into the PKCS#15 application or DF.There are currently two ACL Processors:1. The ACL Processor compliant with the [GSMA-NFC] specification, implemented in file“wme_security_stack_acl_processor_gp.c”.2. The ACL Processor compliant with the proprietary [PKCS15-INSIDE] specification,implemented in file “wme_security_stack_acl_processor_pkcs15.c”.The interface of an ACL Processor is defined in file “wme_security_stack_acl_processor.h”.• The pCreateInstance function (constructor) is called to build an ACL processor instancein case the passed answer to SELECT can be managed by this ACL Processor.• The pUpdateInstance function is used to check whether the ACL should be updated.• The pReadAcl function is used to read the access control rules from the SE and build aninternal representation of the ACL.• The optional pFilterApdu function is used to filter the APDU commands sent to the SE, incase the update strategy is “master”. This way, if the ACL processor intercepts acommand that modifies the PKCS#15 application, it sets an internal “update flag” toremember that the ACL should be read again from the SE.• The optional pNotifyStkRefresh function is used when the update strategy is “slave withnotification”.• The pDestroyInstance is the destructor.The pReadAcl function reads the access control rules from the SE and returns the built ACLin a “tPSecurityStackAclProcessorReadAclCallbackFunction” callback function passed to it.The following cases may occur:1. nResult is not W_SUCCESS (pAcl is then null): An error occurred during the reading ofthe ACL. The Security Stack must then assume that there is no ACL any longer.2. nResult is W_SUCCESS and pAcl is null: The ACL reading succeeded, but the ACL didnot changed since the last time it has been read.3. nResult is W_SUCCESS and pAcl is not null: The ACL reading succeeded, and a newACL is available (the previous ACL must be discarded).Check document version before use.Copyright © 2011 Inside Secure

Open NFC - Security Stack SpecificationGeneral Business UsePage : 17/20Date : Dec. 27, 2011Ref. : STS_NFC_1104-242 v0.6(14516)2.4.3 Selection of the PKCS#15 application or DFBefore the access control rules are read, the PKCS#15 application or DF must be selected.This step is also important to determine whether the PKCS15 application or DF is present ornot on the SE. The following algorithm is used.1. Assume that the PKCS#15 application is absent.2. Open a supplementary logical channel and select the PKCS#15 application by its AID.2.1. If the selection failed (because either there is no available logical channel or thePKCS#15 application is absent), close the supplementary logical channel (ifopened). Continue on step 3.2.2. If the selection succeeded, it is now assumed that there is a PKCS#15 application.Continue on step 5.3. Open a supplementary logical channel and select the MF.3.1. If the selection failed (because either there is no available logical channel or the MFis absent), close the supplementary logical channel (if opened). End processing.3.2. If the selection succeeded:3.2.1. Select the EF(DIR) file under the MF, and read EF(DIR) records to find anentry that contains the PKCS#15 AID.3.2.2. If an errors occurs during the preceding operations, or if no PKCS#15 entry isfound in the EF(DIR) record, then it is assumed that there is no PKCS#15application. End processing.3.2.3. Otherwise, the EF(DIR) record associated with the PKCS#15 applicationcontains the FID of the PKCS#15 DF.4. Select the PKCS#15 DF by its FID.4.1. If the selection failed (because the PKCS#15 DF is absent), close the supplementarylogical channel. End processing.5. Read access control rules from the currently selected PKCS#15 application or DF, whichis now assumed to be present.5.1. Ask each ACL processor in turn whether it can process the currently selectedPKCS#15 application or DF. If none is found, end processing.5.2. Ask the current ACL processor to read the access control rules and build the ACL.6. Close the supplementary logical channel.2.4.4 Processing of the access control rules in the GSMA ACL ProcessorDuring the PKCS#15 application selection:• The pCreateInstance function of the GSMA ACL processor parses the answer to theSELECT command. If it is malformed (missing tag, unexpected tag, invalid tag length) ordoes not contain an enclosing ‘62’ tag (FCP template), or does not contain a ‘82’ tag (filedescriptor) with contents ’78 21’ (DF/Linear variable, Data Coding:Write Or/2 nibbles), theACL processor refuses to process this PKCS#15 application.Check document version before use.Copyright © 2011 Inside Secure

Open NFC - Security Stack SpecificationGeneral Business UsePage : 18/20Date : Dec. 27, 2011Ref. : STS_NFC_1104-242 v0.6(14516)During ACL reading/updating (The PKCS#15 applet is assumed to be selected):1. The EF(ODF) file is selected (its FID ‘5031’ is well-known). Its size is extracted from thereturned FCP and the EF(ODF) is read. In case of any error, continue on step 12.2. The contents of the EF(ODF) is parsed to extract the FID of the EF(DODF) file. If an erroroccurs or if the EF(DODF) FID is not found, continue on step 12.3. The EF(DODF) file is selected by its FID and read. In case of any error, continue on step12.4. The contents of the EF(DODF) file is parsed to look for the entry containing the FID of theEF(ACMF) file. This data object entry is identified by the { iso(1) member-body(2)country-USA(840) Global-Platform(114283) device(200) seAccessControl(1)accessControlMainFile(1) } OID. In case of any error, continue on step 12.5. The EF(ACMF) file is selected by its FID and read. The contents of the EF(ACMF) is thenparsed to extract the refresh tag and the FID of the EF(ACRF) file. In case of any error,continue on step 12.6. If the refresh tag did not change since the last ACL reading, the W_SUCCESS code anda null ACL are returned.7. The EF(ACRF) file is selected and read. In case of any error, continue on step 12.8. If the EF(ACRF) file is empty, the W_ERROR_SECURITY error code is returned.9. An ACL instance is created with default access control rules: All APDU are denied for allprincipals.10. For each entry of the EF(ACRF) file, the AID is extracted and the EF(ACCondition) filethat is pointed to from the entry is selected and read. If an error occurs during theselection, reading or parsing of the EF(ACCondition) file, the access control condition isassumed to be “deny all”. An ACIE with the extracted AID and the access controlcondition is then created and added to the ACL.11. The ACL reading succeeded: The W_SUCCESS code and the new ACL are returned.12. An error occurred during a file selection, reading or parsing: TheW_ERROR_RF_COMMUNICATION error code is returned.2.4.5 Processing of the access control rules in the PKCS15 ACL ProcessorDuring the PKCS#15 application selection:1. The pCreateInstance function of the PKCS15 ACL processor parses the answer to theSELECT command. If it is malformed (missing tag, unexpected tag, invalid tag length) orcontains a PKCS#15 application version number different from 0x0100, the ACLprocessor refuses to process this PKCS#15 application.2. Otherwise, the contents of the EF(SE-LastUpdate) file (returned in the answer toSELECT) is stored internally, and memory for the EF(SE-ACF) file (which size is returnedin the answer to SELECT) is dynamically allocated. If allocation failed, the ACL processorrefuses to process this PKCS#15 application.Check document version before use.Copyright © 2011 Inside Secure

Open NFC - Security Stack SpecificationGeneral Business UsePage : 19/20Date : Dec. 27, 2011Ref. : STS_NFC_1104-242 v0.6(14516)During ACL reading/updating (The PKCS#15 applet is assumed to be selected):1. If the EF(SE-LastUpdate) file did not change since the last ACL reading, theW_SUCCESS code and a null ACL are returned.2. The EF(SE-ACF) file is read. As many READ BINARY commands as needed are sentuntil the file is read entirely.• If a command times out, a W_ERROR_TIMEOUT error code is returned. Processingcontinues on step 4 below.• If the command does not return a valid response (that is, with at least a status word),a W_ERROR_RF_COMMUNICATION error code is returned. Processing continueson step 4.• Otherwise, read data are accumulated.3. The contents of the EF(SE-ACF) file is then parsed. If any error occurs during parsing,the W_ERROR_SECURITY error code is returned. Processing continues on step Error!Reference source not found..4. The ACL reading succeeded: The W_SUCCESS code and the new ACL are returned.5. If an error has been encountered during the loading, the ACL previously stored internallyby the Security Stack shall be deleted.2.4.6 Update LoadingUpdate loading may be performed before each connection to an SE is opened. The OpenNFC stack then calls the PSecurityStackReadAcl function that decides if the ACL need to beread again from the SE.This decision is based on the update strategy:• In case the update strategy is “master”, the ACL Processor intercepts the APDUcommands sent to the SE and, if it detects an APDU command that may modify thecontents of the access control rules, it sets the “update flag”.• In case the update strategy is “slave with notification”, the ACL Processor has processedSTK REFRESH commands and optionally set the “update flag”.• In case the update strategy is “slave with no notification”, the “update flag is alwaysassumed to be set.When the “update flag” is set, the ACL is read again from the SE. Otherwise, nothing is done.Check document version before use.Copyright © 2011 Inside Secure

Open NFC - Security Stack SpecificationGeneral Business UsePage : 20/20Date : Dec. 27, 2011Ref. : STS_NFC_1104-242 v0.6(14516)3 IntegrationThe security stack is integrated in the driver/server part of Open NFC. The access to theSecure Element is done directly from this layer, transparently for the user/client part of thestack.The APDU for the SE are intercepted in the server part of the ISO 14443 layer or in the UICCaccess layer.New functions are added in the OS HAL to perform the identification operations.Check document version before use.Copyright © 2011 Inside Secure