GlobalPlatform Technology

Secure Element AccessControl
Version 1.1.0.10
Public Review
August 2024
Document Reference: GPD_SPE_013

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.
Recipients of this document are invited to submit, with their comments, notification of any
relevant patents or other intellectual property rights of which they may be aware which might benecessarily infringed by the implementation of the specification or other work product set forth in
this document, and to provide supporting documentation. This document (and the information
herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be
disseminated without restriction. Use of the information herein (whether or not obtained directlyfrom GlobalPlatform) is subject to the terms of the corresponding GlobalPlatform license
agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to
sublicensing) inconsistent with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 2 / 128

THIS SPECIFICATION OR OTHER WORK PRODUCT IS BEING OFFERED WITHOUT ANY WARRANTYWHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NON-INFRINGEMENT IS EXPRESSLYDISCLAIMED. ANY IMPLEMENTATION OF THIS SPECIFICATION OR OTHER WORK PRODUCT SHALL
BE MADE ENTIRELY AT THE IMPLEMENTER’S OWN RISK, AND NEITHER THE COMPANY, NOR ANY
OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY
IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER DIRECTLY OR
INDIRECTLY ARISING FROM THE IMPLEMENTATION OF THIS SPECIFICATION OR OTHERWORK PRODUCT.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 3 / 128

Contents
1

Introduction .............................................................................................................................. 82

Architecture ............................................................................................................................ 17

3

Access Control Rules ............................................................................................................ 24

4

Device Interface ...................................................................................................................... 31

1.1
1.2
1.3
1.4
1.5
1.6
2.1
2.2

Audience ...............................................................................................................................................8
IPR Disclaimer ......................................................................................................................................9
References ............................................................................................................................................9
Terminology and Definitions ...............................................................................................................11
Abbreviations and Notations ...............................................................................................................12
Revision History ..................................................................................................................................15

Rules in Issuer Security Domain Only ................................................................................................18
Rules in Issuer and Application Provider Security Domains ...............................................................192.2.1 Limitations on Rule Retrieval .......................................................................................................20
2.2.2 ARA-M and ARA-C Architecture and Security Considerations ....................................................20
2.3
Architecture with Access Rule File (ARF) Support .............................................................................21
2.4
Rule Enforcement ...............................................................................................................................23
3.1

Device Application Identifier (DeviceAppID) .......................................................................................25
3.1.1 UUID as DeviceAppID..................................................................................................................25
3.1.2 Certificate as DeviceAppID ..........................................................................................................25
3.1.3 DeviceAppID Retrieval .................................................................................................................25
3.2
Specific Features for NFC Access Rule Enforcement ........................................................................26
3.3
Introduction to Access Control Rule Conflict Resolution ....................................................................27
3.3.1 Specific Rules Have Priority .........................................................................................................27
3.3.2 End-Entity Certificates Have Priority ............................................................................................28
3.3.3 Restrictive Rules Have Priority ....................................................................................................28
3.4
Access Control Rule Combination and Conflict Resolution ................................................................29
3.4.1 Algorithm to Solve Conflicts or Combine Rules ...........................................................................30
4.1

GET DATA Command.........................................................................................................................32
4.1.1 Command Message .....................................................................................................................33
4.1.1.1 Command Message Tags ...................................................................................................34
4.1.1.2 Command Message Data Objects.......................................................................................34
4.1.2 Response Message .....................................................................................................................35
4.1.2.1 Response Message Data Objects .......................................................................................35
4.1.2.2 Response Message Status Words ......................................................................................38
4.2
Access Control Evaluation Steps ........................................................................................................40
4.2.1 Usage with Rules Cached in the Device ......................................................................................40
4.2.2 Usage with Instant Query to the ARA-M (Deprecated) ................................................................424.2.3 Algorithm for Applying Rules ........................................................................................................43
4.3
Managing Certificate Chains ...............................................................................................................45
4.4Managing the Version of the Device Interface ....................................................................................47
4.4.1 Managing Backward Compatibility with Previous Versions .........................................................47
4.4.1.1 Identifying ARA-M Version ..................................................................................................47
4.4.1.2 Identifying Access Control Enforcer Version .......................................................................47
4.4.1.3 Managing ARA-M Backward Compatibility ..........................................................................47
4.4.1.4 Managing ACE Backward Compatibility ..............................................................................48

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 4 / 128

5

Remote Interface Based on RAM .......................................................................................... 49

5.1

STORE DATA Command....................................................................................................................50
5.1.1 Command Message .....................................................................................................................50
5.1.1.1 Command Message Data Objects.......................................................................................53
5.1.2 Response Message .....................................................................................................................61
5.1.2.1 Response Message Data Objects .......................................................................................61
5.1.2.2 Response Message Status Words ......................................................................................63

6

General Data Objects ............................................................................................................. 65

7

Structure of Access Rule Files (ARF) ................................................................................... 75

6.1
6.2
6.3

Access Rule Reference Data Objects.................................................................................................66
Access Rule Data Objects ..................................................................................................................69
Configuration Management Data Objects ...........................................................................................72

7.1

Background .........................................................................................................................................75
7.1.1 File Padding .................................................................................................................................75
7.1.2 PKCS#15 Selection......................................................................................................................75
7.1.3 PKCS#15 DODF ..........................................................................................................................76
7.1.4 The Access Control Main File (ACMF) ........................................................................................77
7.1.5 The Access Control Rules File (ACRF) .......................................................................................78
7.1.6 The Access Control Conditions File (ACCF) ...............................................................................80
7.2
ASN.1 Definition ..................................................................................................................................83
7.3
File System Validity .............................................................................................................................85
7.4
ARF Parsing ........................................................................................................................................85

Annex A

Summary of Data Object Nesting ........................................................................... 86

Annex B

Data Object Tags ..................................................................................................... 89

Annex C

Example of Access Control Data ........................................................................... 90

Annex D

Rules Conflict Management Examples ................................................................ 104

Annex EAPDU Process Flows ............................................................................................ 111

Annex F

Migration Scenarios for the UICC ........................................................................ 127

Annex G

Access Rule Interpretation ................................................................................... 128

C.1
C.2
C.3
C.4

E.1
E.2

First Example ......................................................................................................................................90
Second Example .................................................................................................................................93
Third Example .....................................................................................................................................96
Fourth Example ...................................................................................................................................99

Device Interface APDU Flow ............................................................................................................112
Remote Interface Based on RAM APDU Flow .................................................................................116
E.2.1 Remote Management with Admin Agent on Device ..................................................................116
E.2.2 Remote Management with Direct OTA Connection ...................................................................122
E.2.3 Remote Management with Direct OTA Connection and Limited Buffers...................................125

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 5 / 128

TablesTable 1-1: Normative References......................................................................................................................9
Table 1-2: Informative References ..................................................................................................................10
Table 1-3: Terminology and Definitions ...........................................................................................................11
Table 1-4: Abbreviations..................................................................................................................................12
Table 1-5: Revision History .............................................................................................................................15
Table 3-1: Determining Priority of Rules .........................................................................................................27
Table 3-2: Access Control Rules Conflict Resolution ......................................................................................30
Table 4-1: GET DATA Command Message ....................................................................................................33
Table 4-2: Response-ALL-REF-AR-DO ..........................................................................................................35
Table 4-3: Response-AR-DO ..........................................................................................................................36
Table 4-4: Response-Refresh-Tag-DO ...........................................................................................................36
Table 4-5: Response-ARAM-Config-DO .........................................................................................................37
Table 4-6: GET DATA Response Message Status Words ..............................................................................38
Table 5-1: STORE DATA Command Message ...............................................................................................50
Table 5-2: Command-Store-REF-AR-DO ........................................................................................................53
Table 5-3: Overwrite Scenarios .......................................................................................................................55
Table 5-4: Command-Delete ...........................................................................................................................56
Table 5-5: REF-AR-DO in Command-Delete ..................................................................................................56
Table 5-6: Command-Update-Refresh-Tag-DO ..............................................................................................57
Table 5-7: Command-Register-Client-AIDs-DO ..............................................................................................57
Table 5-8: Command-Get ................................................................................................................................58
Table 5-9: Command-Get-All...........................................................................................................................58
Table 5-10: Command-Get-Client-AIDs-DO....................................................................................................59
Table 5-11: Command-Get-Next .....................................................................................................................59
Table 5-12: Command-Get-Device-Config-DO ...............................................................................................60
Table 5-13: Response-ARAC-AID-DO ............................................................................................................61
Table 5-14: Response-Device-Config-DO .......................................................................................................62
Table 5-15: STORE DATA Response Message Status Words.......................................................................64
Table 6-1: Reserved Data Object Tags for GlobalPlatform SEAC Specification ............................................65
Table 6-2: Reserved Data Object Tags for Proprietary Usage .......................................................................65
Table 6-3: AID-REF-DO ..................................................................................................................................66
Table 6-4: DeviceAppID-REF-DO ...................................................................................................................67
Table 6-5: REF-DO ..........................................................................................................................................68
Table 6-6: REF-AR-DO ...................................................................................................................................68
Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 6 / 128
Table 6-7: AR-DO ............................................................................................................................................69
Table 6-8: APDU-AR-DO .................................................................................................................................70
Table 6-9: NFC-AR-DO ...................................................................................................................................71
Table 6-10: Device-Config-DO ........................................................................................................................72
Table 6-11: ARAM-Config-DO .........................................................................................................................72
Table 6-12: Device-Interface-Version-DO .......................................................................................................73
Table 6-13: Block-DO ......................................................................................................................................73
Table 7-1: Access Control Main File (ACMF) ..................................................................................................77
Table 7-2: Access Control Rules File (ACRF) .................................................................................................78
Table 7-3: Access Control Conditions File (ACCF) .........................................................................................80
Table 7-4: Required Interpretation If Undefined Attribute in Condition Object ................................................82
Table A-1: Data Object Nesting in GET DATA Command ..............................................................................86
Table A-2: Data Object Nesting in GET DATA Response ..............................................................................87
Table A-3: Data Object Nesting in STORE DATA Command .........................................................................88
Table A-4: Data Object Nesting in STORE DATA Response .........................................................................88
Table B-1: Data Object Tags ...........................................................................................................................89
Table D-1: Terms Used in Table D-2.............................................................................................................105
Table D-2: Rules Conflict Management ........................................................................................................106
Table G-1: Interpretation of Access Rules Stored in the ARA ......................................................................128
Table G-2: Interpretation of Access Rules Stored in ARF .............................................................................128

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 7 / 128

FiguresFigure 2-1: Access Control Architecture – Rules in ISD Only .........................................................................18
Figure 2-2: Access Control Architecture – Rules in ISD and APSDs ..............................................................19
Figure 2-3: Access Control Architecture with ARF Support ............................................................................21
Figure 2-4: Access Control Architecture with Access Rule File System Fallback...........................................22
Figure 3-1: Example of Architecture for Access Rule Enforcement ................................................................26
Figure 4-1: Device Interface Sequence with Rules Caching ...........................................................................40
Figure 4-2: Device Interface Sequence with Instant Query to the ARA-M ......................................................42
Figure 4-3: Processing of Chained Certificates ...............................................................................................45
Figure E-1: Access Control Rules Retrieval from ARA-M .............................................................................112
Figure E-2: Specific Access Rule Retrieval from ARA-M (Deprecated) ........................................................113
Figure E-3: Access Rule Retrieval Sequence (Deprecated) .........................................................................114
Figure E-4: Chained Certificate Querying (Deprecated) ...............................................................................115
Figure E-5: Provisioning Directly to ARA with Admin Agent on Device ........................................................117
Figure E-6: Deletion Directly to ARA with Admin Agent on Device ...............................................................118
Figure E-7: Provisioning through Security Domain with Admin Agent on Device .........................................119
Figure E-8: Deletion through Security Domain with Admin Agent on Device ...............................................120
Figure E-9: Rules Retrieval through Security Domain with Admin Agent on Device ....................................121
Figure E-10: Provisioning through Security Domain Using Direct OTA Connection .....................................122
Figure E-11: Deletion through Security Domain Using Direct OTA Connection ...........................................123
Figure E-12: Rules Retrieval through Security Domain Using Direct OTA Connection ................................124
Figure E-13: Provisioning Using Direct OTA Connection with Limited Buffer ...............................................125
Figure E-14: Rules Retrieval Using Direct OTA Connection with Limited Buffer ..........................................126

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 8 / 128

1

1 INTRODUCTION

2
3
4
5
6

GlobalPlatform has defined a standard that enables several parties to independently and securely manage
their stakes in a single Secure Element. This security model has allowed applications such as banking andtransport to be deployed in a variety of situations. As these services reach the context of personal devices
such as mobile phones, service owners start to leverage the device’s capabilities to enrich their customers’
experiences.

7
8
9
10

These applications will rely both on the device itself and on Secure Elements. An API (such as[Open Mobile API] or [GP TEE SE API]), referred to in this document as the Secure Element Access API, isused by the device applications to exchange data with their counterpart applications running in the Secure
Element.

11
12
13This specification considers two types of device applications: those that run in the Regular Execution
Environment (REE, e.g. Android, Windows Phone environment) and those that run in the Trusted Execution
Environment (TEE).

14
15
16

Restricting the use of such an API is necessary since modern mobile operating systems do not efficiently
prevent unauthorized parties from abusing the API and potentially causing damage to the Secure Element
itself.

17
18
19
20
21

This security mechanism, called Secure Element access control, defined in this specification, is used inaddition to existing protection mechanisms (such as permissions or security OS policy limiting access tosensitive APIs). The access control is designed to prevent unauthorized access to resources in the Secure
Elements and typically to prevent denial of services attacks (PIN blocking, selection of non multi-selectableapplets, etc.).

22
23This access control mechanism is transparent to client applications running in the device and is enforced within
the device operating system itself.

24
25This document specifies how the access policy is stored in the Secure Element, and how it can be accessed
and applied by the device.

26
27
28
29
30
31

In this specification, some elements are identified as “deprecated”, and either have been replaced by new
functions as noted in their descriptions or have been flagged for later removal. These elements will be removed
from the specification in a future version. There is no guarantee that these elements will be present in a future
release of this specification. Therefore, it is not recommended to include deprecated elements in new products
or to reference them in new specification documents.

32
33
34
35

Note: In this version of the specification, access rules retrieval using GET DATA [Specific] isdeprecated. GET DATA [Specific] is still allowed for ARA-M implementations that support older
versions of Access Control Enforcers. It is recommended that Access Control Enforcer
implementations use GET DATA [All] to retrieve access rules.

36

1.1 Audience

37
38This specification is intended primarily for Secure Elements manufacturers, handset manufacturers, andSecure Element issuers.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 9 / 12839

1.2 IPR Disclaimer

40
41
42
43
44
45

Attention is drawn to the possibility that some of the elements of this GlobalPlatform specification or other work
product may be the subject of Intellectual Property Rights (IPR) held by GlobalPlatform members or others.
For additional information regarding any such IPR that have been brought to the attention of GlobalPlatform,
please visit https://www.globalplatform.org/specificationsipdisclaimers.asp. GlobalPlatform shall not be held
responsible for identifying any or all such IPR, and takes no position concerning the possible existence or theevidence, validity, or scope of any such IPR.

46

1.3 References

47
48

The tables below list references applicable to this specification. The latest version of each reference applies
unless a publication date or version is explicitly stated.

49

Table 1-1: Normative References
Standard / Specification

Description

Ref

GPC_SPE_034

GlobalPlatform Technology[GP Card Spec]

Card Specification v2.3
GPD_SPE_009

GlobalPlatform Technology[GP Sys Arch]TEE System Architecture
GPD_SPE_010

GlobalPlatform Technology[GP Internal API]TEE Internal Core API Specification
ETSI TS 102 221

Smart cards; UICC – Terminal interface; Physical andlogical characteristics, Release 6, 2004

[102 221]ETSI TS 102 225

Smart cards; Secured packet structure for UICC based
applications, Release 6, 2004

[102 225]ETSI TS 102 226

Smart cards; Remote APDU structure for UICC based
applications, Release 6, 2004

[102 226]ETSI TS 102 622

Smart Cards; UICC – Contactless Front end (CLF)
Interface; Host Controller Interface (HCI), Release 7, 2009

[102 622]

ISO/IEC 7816-4

Identification cards – Integrated circuit cards – Part 4:
Organization, security and commands for interchange[7816-4]

ISO/IEC 7816-5

Identification cards – Integrated circuit cards – Part 5:
Registration of application providers[7816-5]

ISO/IEC 8825-1| ITU-T
Recommendation X.690

Information technology – ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules(DER), 2002

[X.690]

PKCS#15

PKCS #15 v1.1: Cryptographic Token Information Syntax
Standard; RSA Laboratories; June 6, 2000

[PKCS15]50

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 10 / 128
Table 1-2: Informative References

51
Standard / Specification

Description

Ref

GPC_SPE_007

GlobalPlatform Technology[GP Amd A]

Confidential Card Content Management – Card
Specification v2.3 – Amendment A
GPC_SPE_011

GlobalPlatform Technology[GP Amd B]

Remote Application Management over HTTP – Card
Specification v2.3 – Amendment B
GPC_SPE_025

GlobalPlatform Technology[GP Amd C]

Contactless Services – Card Specification v2.3 –Amendment C
GPD_SPE_024

GlobalPlatform Technology[GP TEE SE API]TEE Secure Element API
GPD_SPE_007

GlobalPlatform Technology[GP TEE Client API]TEE Client API Specification
GPD_SPE_008

GlobalPlatform Technology[GP SE OTA]

Secure Element Remote Application Management
GPD_SPE_075

GlobalPlatform Technology[Open Mobile API]

Open Mobile API Specification
ETSI TS 102 241

Smart cards; UICC Application Programming Interface(UICC API) for Java Card™, Release 6, 2004

[102 241]

GSMA APIs

GSMA NFC Handset APIs & Requirements
Version 3.0[GSMA]

ISO/IEC 7816-6

Identification cards – Integrated circuit cards withcontacts – Part 6: Interindustry data elements forinterchange[7816-6]

ISO/IEC 7816-15

Identification cards – Integrated circuit cards withcontacts – Part 15: Cryptographic information
application[7816-15]

ISO/IEC 14443-3

Identification cards – Contactless integrated circuit(s)cards – Proximity cards – Part 3: Initialization andanticollision[14443-3]

ISO/IEC 14443-4

Identification cards – Contactless integrated circuit
cards – Proximity cards – Part 4: Transmission
protocol[14443-4]

PKCS#1

PKCS #1 v2.0: RSA Cryptography Standard,
RSA Laboratories, October 1998 (RFC 2437).

[PKCS1]

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 11 / 128
Standard / Specification

Description

Ref

Java Card

Go to the following website for Java Card™
documentation: 1[Java Card]

http://www.oracle.com/technetwork/java/javacard/overv
iew/index.html
RFC 4122

A Universally Unique IDentifier (UUID) URN
Namespace[RFC 4122]

52
53

1.4 Terminology and Definitions
Table 1-3: Terminology and Definitions

54
Term

Definition

Access Control Enforcer(ACE)

Software that is part of the Secure Element Access API, it obtains accessrules from the Secure Element and applies those rules to restrict device
application access to the various Applets.

AppletGeneral term for a Secure Element application: An application as
described in GlobalPlatform Card Specification ([GP Card Spec]) that is
installed in the SE and runs within the SE.

Application Provider

Entity responsible for the security of an application.

Device application

A third party application running on the open mobile OS.

Mobile device

Any device that includes a secure element, such as a mobile phone.

Regular Execution
Environment (REE)An Execution Environment comprising at least one Regular OS and allother components of the device (IC packages, other discrete components,
firmware, and software) that execute, host, and support the Regular OSes
(excluding any Secure Components included in the device).
From the viewpoint of a Secure Component, everything in the REE isconsidered untrusted, though from the Regular OS point of view there
may be internal trust structures.
(Formerly referred to as a Rich Execution Environment (REE).)
Contrast Trusted Execution Environment (TEE).

Regular OS

An OS executing in a Regular Execution Environment. May be anythingfrom a large OS such as Linux down to a minimal set of statically linked
libraries providing services such as a TCP/IP stack.
(Formerly referred to as a Rich OS or Device OS.)
Contrast Trusted OS.

Secure Element (SE)1

A tamper-resistant secure hardware component that is used in a device toprovide the security, confidentiality, and multiple application environment
required to support various business models. May exist in any form factor,
such as embedded or integrated SE, SIM/UICC, smart card, smart
microSD, etc.

Java Card is a trademark of Oracle and/or its affiliates.
Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 12 / 128
Term

Definition

Secure Element Access API

An API used by device applications to exchange data with theircounterpart applications running in the Secure Element.

Secure Element Issuer

Holds the ultimate responsibility for the GlobalPlatform card. Responsiblefor developing the card product profile, choosing the platform andapplication technologies, and designing the card layout.
Usually holds a particular Security Domain in the SE: the Issuer Security
Domain (ISD).

Security Domain (SD)Application having the Security Domain privilege. This on-card entity
provides support for the control, security, and communication
requirements of an off-card entity such as the Card Issuer, an Application
Provider, or a Controlling Authority.

Trusted Execution
Environment (TEE)An execution environment that runs alongside but isolated from Execution
Environments outside of the TEE. A TEE has security capabilities andmeets certain security-related requirements: It protects TEE assets
against a set of defined threats which include general software attacks aswell as some hardware attacks, and defines rigid safeguards as to data
and functions that a program can access. There are multiple technologies
that can be used to implement a TEE, and the level of security achieved
varies accordingly. (For more information, see [GP Sys Arch].)Contrast Regular Execution Environment.

Universally Unique Identifier(UUID)

An identifier as specified in [RFC 4122].

55
56

1.5 Abbreviations and Notations
Table 1-4: Abbreviations

57
Abbreviation

Meaning

AC

Access Control

ACCF

Access Control Conditions File

ACE

Access Control Enforcer

ACMF

Access Control Main File

ACRF

Access Control Rules File

AID

Application IDentifier, following ISO/IEC 7816-5 ([7816-5])

APDU

Application Protocol Data Unit

API

Application Programming Interface

APSD

Application Provider Security Domain

AR

Access Rule

ARA

Access Rule Application

ARA-C

Access Rule Application Client

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 13 / 128
Abbreviation

Meaning

ARA-M

Access Rule Application Master

AR-DO

Access Rule Data Object

ARF

Access Rule Files

ASN.1

Abstract Syntax Notation One, defined in [X.690]

BER

Basic Encoding Rules

DeviceAppID

Device Application IdentifierDF

Directory FileDO

Data Object (BER encoded TLV)

DODF

Data Object Directory File

EFdir

Application Directory Elementary FileETSIEuropean Telecommunications Standards Institute

EVT

Event

GSM

Global System for Mobile Communication

GSMA

GSM Association

HCI

Host Controller Interface

ISD

Issuer Security Domain

ISOInternational Organization for StandardizationMF

Master File

NFC

Near Field Communication

ODF

Object Directory File

OID

Object Identifier

oidDO

Object identifier for Data Object

OTA

Over The Air

PKCS

Public Key Cryptography Standards

RAM

Remote Application Management

REE

Regular Execution Environment

RFM

Remote File Management

RID

Registered Application Provider Identifier

SD

Security Domain

SE

Secure Element

SEAC

Secure Element Access Control

SHA-1

Secure Hash Algorithm 1

SHA-256

Secure Hash Algorithm 2 with 256-bit hash length

SW

Status Word

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 14 / 128
Abbreviation

Meaning

SWP

Single Wire Protocol

TA

Trusted Application

TEE

Trusted Execution Environment

TLV

Tag Length Value

TSM

Trusted Service Manager

UUID

Universally Unique IDentifier

58

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 15 / 128
59

1.6 Revision History

60
61
62
63
64

GlobalPlatform technical documents numbered n.0 are major releases. Those numbered n.1, n.2, etc., areminor releases where changes typically introduce supplementary items that do not impact backward
compatibility or interoperability of the specifications. Those numbered n.n.1, n.n.2, etc., are maintenancereleases that incorporate errata and clarifications; all non-trivial changes are indicated, often with revisionmarks.

65

Table 1-5: Revision History
Date

VersionDescription

May 2012

1.0

Initial publication.

Sep 2014

1.1

Extension for applications in a Trusted Execution Environment.
Extension for applications in Windows Phone 8 environment.
New section 2.4, Rule Enforcement, to clarify the rule enforcement by thedevice.
New section 3.1, Device Application Identifier (DeviceAppID). The new term
DeviceAppID was introduced to generalize the mechanism of device
identification and replaces the term “Hash” used in the former version of thisdocument.
New section 3.2, Specific Features for NFC Access Rule Enforcement, toclarify the basic concept of access control for NFC event.
Refinements in sections 3.3 and 3.4 regarding access control rule
combination and conflict resolution.
Corrections in section 4.2.3, Algorithm for Applying Rules.
New section 4.4, Management of the Version of the Device Interface, tomanage backward compatibility of versions of this specification.
Configuration management data objects were introduced:

Response-ARAM-Config-DO, in Chapter 4, Device Interface.
Command-Get-Device-Config-DO and Response-Device-ConfigDO, in Chapter 5, Remote Interface Based on RAM.
Device-Config-DO, ARAM-Config-DO, and Device-InterfaceVersion-DO, in new section 6.3, Configuration Management Data
Objects.
In Chapter 5, Remote Interface Based on RAM, clarifications on expectedbehavior on receipt of Command-Store-REF-AR-DO (formerly CommandStore-AR-DO).
In section 4.1, GET DATA Command, explanation of concurrency of rule
retrieval and rule storage.
In Chapter 6, General Data Objects, clarification on how a BER-TLV with an
unknown tag shall be handled by an ARA.
In Chapter 6, Block-DO was introduced to perform rule storage or retrieval
over several OTA sessions when using SCP80.
In section 6.1, Access Rule Reference Data Objects, explanation of support ofpartial AIDs for SELECT [by name] [first occurrence] / [next occurrence]commands.
— continues —Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 16 / 128
Date

VersionDescription

Sep 2014

1.1(continued)

In Chapter 7, Structure of Access Rule Files, clarification on the expectedinterpretation of ARF structures.
GET DATA [Specific] is deprecated in this version.
Changed the names of the following data objects:
Prior Name

Name as of v1.1

Response-ALL-AR-DO

Response-ALL-REF-AR-DO

Response-RefreshTag-DO

Response-Refresh-Tag-DO

Command-Store-AR-DO

Command-Store-REF-AR-DO

Command-Delete-AR-DO

Command-Delete

Command-UpdateRefreshTag-DO

Command-Update-Refresh-TagDO

Command-RegisterClientAIDs-DO

Command-Register-ClientAIDs-DO

Command-Get-AR-DO

Command-Get

Command-GetAll-AR-DO

Command-Get-All

Command-Get-ClientAIDs-DO

Command-Get-Client-AIDs-DO

Command-GetNext-AR-DO

Command-Get-Next

Feb 2023v1.1.0.3

Committee Review

Feb 2024v1.1.0.5

Member Review

Aug 2024v1.1.0.10

Public Review

TBD

1.2

Public Release• Incorporated prior Errata and Precisions:o Added section 7.4, ARF Parsing, clarifying the exact behavior of theAccess Control Enforcer if parsing errors occur.
o In section 3.2, Specific Features for NFC Access Rule Enforcement,
clarified the exact behavior of the Access Control Enforcer to retrieve
updated NFC rules.
• Updated the reference to OMAPI to GPD_SPE_075.
• Changed the meaning of REE from Rich Execution Environment toRegular Execution Environment.
• Removed references to Windows Phone 8 environment.
• Added support for SHA-256 to derive DeviceAppIDs from the certificateof the device Application Provider (deprecated SHA-1).
• Added support for SHA-256 in ARF.
• Added a Fourth Example to Annex C where both DODF(1) and DODF(2)are present.
• Replaced “Secure Element application” with “Applet” in keeping with
GlobalPlatform approved terminology.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 17 / 128
66

2 ARCHITECTURE

67
68
69

This specification defines a generic mechanism for Secure Element access control, usable for any kind of
Secure Element (e.g. embedded SE, microSD card with security controller, UICC, etc.). It supports application
management by multiple entities and allows each entity to set the access rules for its Applets.

70
71
72

Secure Element access rule data is stored in the Secure Element (SE) and used by an Access Control Enforcer(ACE) on the device. The ACE shall retrieve the access rules from the Secure Element and apply those rules
to restrict device application access to the various Applets.

73

The following types of device applications are considered in this version of the specification:

74
75• Applications running in the REE (e.g. Android environments), called REE applications in thisdocument76• Applications running in the TEE environment, called Trusted Applications (TAs)

77
78This chapter illustrates several variations on the system architecture. The following topics are included:

79
80
81
82
83

2.1
2.2
2.3
2.4

Rules in Issuer Security Domain Only ................................................................................................18
Rules in Issuer and Application Provider Security Domains ...............................................................19
Architecture with Access Rule File (ARF) Support .............................................................................21
Rule Enforcement ...............................................................................................................................23

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 18 / 128
84

2.1 Rules in Issuer Security Domain Only

85
86

In the most basic implementation of this specification, all Access Control rules are defined by the Secure
Element Issuer and stored in the Issuer Security Domain (ISD) as illustrated in Figure 2-1.

87

Figure 2-1: Access Control Architecture – Rules in ISD Only
DeviceSecure Element

SE Access API

Issuer SD

DeviceDeviceApplication
DeviceApplication
Application

SE
SE
Application
SE
Application
Application
AccessControl
Enforcer

ARA-M

AccessControl Data

Application
ManagerKey

SecureElement
IssuerAccess control data storage
Interface described in this document
OTA channel interface described in this document
Other interface

88
89
90
91
92

The Secure Element Issuer defines access control rules for the Applets, and supplies those rules to the Access
Rule Application Master (ARA-M). (The Secure Element Issuer may delegate administration to a Trusted
Service Manager (TSM).)

93
94
95

When a device application attempts to access an Applet, the ACE shall use the device interface provided by
the ARA-M to retrieve access rules from the SE (or shall consult the full set of rules that it obtained in advance),and shall permit the access only if the rules indicate that it is acceptable.

96

The ARA-M is an ordinary Applet which can be selected by a GlobalPlatform-defined AID, as follows:
Executable Load File AID:

'A00000015141434C'

Executable Module AID:

'A00000015141434C00'

Application AID:

'A00000015141434C00'

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 19 / 128
97
98
99

The ARA-M application is unique. Although access rule data can be stored in different locations within the SE(as discussed in the following sections), the ARA-M is in charge of retrieving all available access rules after arequest from the ACE on the device.

100
101

The interface between the ACE and the ARA-M is described in Chapter 3. The interface between the Secure
Element Issuer (or TSM) and the ARA-M is described in section 4.3.

102

2.2 Rules in Issuer and Application Provider Security Domains

103
104
105

Application Providers may wish to define access control rules for the applications in their Security Domains
and manage these rules by themselves. To support rules defined by both Secure Element Issuers andApplication Providers, this specification is implemented as illustrated in Figure 2-2.

106

Figure 2-2: Access Control Architecture – Rules in ISD and APSDs
DeviceSecure Element
Application Provider SD

SE Access API
DeviceDeviceApplication
DeviceApplication
Application

Application Provider SD

ARA-C
SE
Application Provider SD
ARA-C
Application
SE
ARA-C
Application
SE
Application
AccessControl Data

AccessControl
Enforcer

Application
ProviderApplication
ProviderApplication
ProviderIssuer SD
ARA-M

Application
ManagerKey

AccessControl Data

SecureElement
IssuerAccess control data storage
Interface described in this document
OTA channel interface described in this document
Interface to be described in future version of this document

107
108
109
110
111

Other interface

Each Application Provider may define access rules for the applications in its Security Domain (SD), and supply
those rules to an Access Rule Application Client (ARA-C). (An Application Developer may delegate
administration to a TSM.)

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 20 / 128
112
113
114
115

When a device application attempts to access an Applet, the ACE shall request the pertinent rules from the
ARA-M. The ARA-M shall provide the appropriate rules, whether they are stored on the ARA-M or on an
ARA-C. (As mentioned in section 2.1, the ACE may obtain the full set of rules in advance.) The ACE shallpermit the access only if the rules indicate that it is acceptable.

116
117
118

The interface between the ACE and the ARA-M is described in Chapter 3. The interface between the
Application Provider (or TSM) and the ARA-C is described in section 4.3. The interface between the ARA-M
and the ARA-C is out of scope of this specification.

119

2.2.1

120

If an ARA-C is deleted, it is expected that all the rules stored to that ARA-C will be deleted.

121
122

If an ARA-C is locked as defined by GlobalPlatform Card Specification ([GP Card Spec]), then the ARA-M shall
ignore all rules stored to that ARA-C.

123

2.2.2

124
125
126

An ARA-C shall register to the ARA-M so that all the rules stored to that ARA-C shall be taken into account by
the ARA-M. This registration process can be performed by the ARA-C itself or can be performed by sending a
STORE DATA (Command-Register-Client-AIDs-DO) command to the ARA-M.

127
128

This STORE DATA command could be used if the ARA-M has been replaced in the field, and therefore needs
to be informed about already existing ARA-Cs on the SE.

129
130
131

However, in this version of the GlobalPlatform SE Access Control specification, the interface between the
ARA-M and the ARA-C is not yet defined. In the current version of this specification, the following items are
implementation dependent:

Limitations on Rule Retrieval

ARA-M and ARA-C Architecture and Security Considerations

132• Authentication of ARA-C by ARA-M

133• Authorization to define access rights by ARA-C

134• Architecture and interaction between the ARA-M and the ARA-C

135• Internal API for registration of ARA-C to ARA-M

136
137
138

In this version of the specification, due to GlobalPlatform card API restrictions, it is not possible for an
ARA-M/ARA-C to determine whether an access rule is associated with an Applet belonging to the same SD
hierarchy.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 21 / 128
139

2.3 Architecture with Access Rule File (ARF) Support

140
141
142
143

This specification can be used by any kind of Secure Element (e.g. embedded SE, microSD card with security
controller, UICC, etc.). For some existing UICC implementations, access to applications is controlled via a setof elementary files, which are updated using Remote File Management (RFM) rather than Remote Application
Management (RAM). This specification supports that mechanism as well, as illustrated in Figure 2-3.

144

Figure 2-3: Access Control Architecture with ARF Support
DeviceSecure Element
SE
Application Provider SD
Application
SE
ARA-C
Application

SE Access API
DeviceDeviceApplication
DeviceApplication
Application

SE
Application

AccessControl Data

Application
ProviderIssuer SD

Application
Manager

AccessControl
Enforcer

ARA-M

AccessControl Data

SE File Systemused only if ARA-M
does not exist

Key

SecureElement
IssuerAccessRules File

Access control data storage
Interface described in this document
Interface described in this document, optional in this implementation
Interface to be described in future version of this document
OTA channel interface described in this document
Other OTA channel interface

145
146
147
148

Other interface

The Secure Element Issuer defines access control rules for the Applets, and supplies those rules to the ARA-M(as discussed in Chapter 4) or to the Access Rule File (ARF) (as discussed in Chapter 7).

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 22 / 128
149
150
151
152
153

When a device application attempts to access an Applet, the ACE shall request the pertinent rules from the
ARA-M. The ARA-M shall provide the appropriate rules, whether they are stored on the ARA-M, an ARA-C, or
the ARF. (As mentioned in section 2.1, the ACE may obtain the full set of rules in advance.) The ACE shallpermit the access only if the rules indicate that it is acceptable. It is the issuer’s choice to decide whether or
not the ARA-M has the ARF reading capability.

154
155

For the UICC, the following fallback shall be implemented: If the ARA-M is not present, the ACE shall retrieve
the access rules from the Access Rule Files (ARF), as illustrated in Figure 2-4.

156

Figure 2-4: Access Control Architecture with Access Rule File System Fallback
DeviceDeviceDeviceApplication
DeviceApplication
Application

Secure Element

SE Access API
SE
Application
AccessControl
Enforcer

SE File System
AccessRules File

Application
ManagerKey

SecureElement
IssuerAccess control data storage
Interface described in this document
OTA channel interface
Other interface

157
158
159

For information about migration from the legacy system support described in this section, see Annex F.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 23 / 128
160

2.4 Rule Enforcement

161
162
163
164
165
166

If an execution environment provides an API for device applications to interact with applications hosted by a
Secure Element, this specification can be implemented to prevent unauthorized device applications gaining
access to a specific Applet. The device API providing the access to the Secure Element can be the
GlobalPlatform Open Mobile API ([Open Mobile API]) that is available in the REE or the GlobalPlatform TEE
Secure Element API ([GP TEE SE API]) that is available in the Trusted Execution Environment (TEE). Suchan API is called an “SE Access API” in this specification.

167
168
169
170
171
172
173
174
175

In order to be compliant with this specification, the SE Access API shall be connection oriented and shall
implement an ACE as defined in this document. When a device application requests to open a connection witha given application in the Secure Element (usually identified by its AID), the SE Access API implementation
shall invoke the ACE with the identifier of the device application requesting the connection and the identifier ofthe Applet to which connection is requested. Then, the ACE is in charge of retrieving the access rules
applicable for the corresponding device application and Applet. If the access is granted, the SE Access API
connection request shall be accepted and the device application shall be allowed to exchange commands (i.e.
APDUs) with the Applet. If the access is not granted, the SE Access API connection request shall be rejected
and the device application shall not be able to exchange commands (i.e. APDUs) with the Applet.

176

In this version of the specification, two types of device execution environment are considered:

177
178
179
180
181

• Device execution environments that support device applications signed with a key of the Application
Provider. In this case, device applications are provided (i.e. in the application container) with acertificate of the Application Provider. This certificate is verified by the application installer of the
Execution Environment. This certificate will be used by the ACE as the application identifier to retrieve
the access rule that is applicable for this device application.

182
183
184
185
186
187

• Device execution environments in which device applications are uniquely identified with an application
identifier which is included in the application and cannot be forged. This identifier will be used by theACE to retrieve the access rule that is applicable for this device application. This is typically the caseof the Trusted Execution Environment defined in the GlobalPlatform TEE System Architecture([GP Sys Arch]), where Trusted Applications (TAs) are uniquely identified by their UUID (as defined in[RFC 4122]), as defined in the GlobalPlatform TEE Internal Core API ([GP Internal API]).

188

More details on device application identifiers are given in section 3.1.

189
190
191
192

The device may also host several REEs or several TEEs. This specification does not distinguish between
multiple REEs or TEEs and a rule assigned to a specific application applies to this application no matter inwhich execution environment this application is installed.

193
194
195

This specification allows the definition of wildcard rules. Such a wildcard rule can be defined to allow aparticular access for all device applications, whether installed in the REE or in the TEE.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 24 / 128
196

3 ACCESS CONTROL RULES

197

Each access control rule stored on the Secure Element specifies that:198• for a specific Applet, or for all other Applets on a given SE

199• a given device application or all other device applications have access rights to:200

o all APDUs, no APDUs, or selected APDUs

201

o all NFC events or no NFC events

202
203
204
205

Because an access control rule may apply to an individual application or to multiple applications, and because
separate rules may be defined in different places on the Secure Element (for example, in the ARA-M and in
an ARA-C), access control rules may overlap and conflict, and a method must be defined to determine which
rule to apply.

206

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 25 / 128
207

3.1 Device Application Identifier (DeviceAppID)

208
209
210
211

An ACE denies or allows device applications access to Applets based on access rules stored on the Secure
Element. In order to identify the device applications and to associate device applications and access rules, theACE uses device application identifiers (called DeviceAppID in this specification). The DeviceAppID
identifies the application, depends on the device runtime, and is included in an access rule.

212

3.1.1

213
214

For Trusted Execution Environments (TEEs), the UUID of each device application is used as its
DeviceAppID.

215

3.1.2

216
217

For some REEs, such as Android, the SHA-256 (or deprecated SHA-1) hash value of the certificate of thedevice Application Provider is used as the DeviceAppID.

218

The following considerations apply when the hash value of a certificate is used as the DeviceAppID:UUID as DeviceAppID

Certificate as DeviceAppID

219
220

• An Application Provider certificate may be used to sign several applications. If so, a rule based on thatcertificate will apply to all those applications.

221
222
223
224
225

• For a REE application, several DeviceAppIDs can exist. This might occur if the REE application
contains several signatures based on several certificates or if the REE application is bearing the wholecertificate chain alongside the child certificate used to sign the application. In both cases thecertificates are available in the application and each certificate has to be considered when determining
the access rights of the application.

226
227

• For a REE application, DeviceAppIDs can exist for each of the supported hash algorithms (SHA-1
and SHA-256 in this version of the specification) to derive DeviceAppIDs from certificates.

228
229
230

Note: This section discusses access control rules that apply to a device application as though the rules wereidentified by a certificate. In fact, the access control rules are stored and retrieved based on the hash of device
application’s certificate, not the certificate itself

231
232
233

This specification does not require the ACE to check the validity of any certificate. The developer of the ACE
may choose to offer that functionality. It is assumed that the Regular OS providing the application certificate
to the ACE can be trusted about the validity of the certificates and the corresponding signatures.

234

3.1.3

235
236
237

The way the ACE retrieves the DeviceAppID (UUID or hash value of the certificate) is out of scope for thisspecification because it is specific to the runtime provided by the operating system. The ACE does not perform
any check on the DeviceAppID provided by the operating system.

DeviceAppID Retrieval

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 26 / 128
238

3.2 Specific Features for NFC Access Rule Enforcement

239
240
241

The NFC trigger event access rules are usually enforced by the NFC API implementation (also called NFC
stack). This implies that the NFC API implementation contains an ACE. This ACE might work completely
independently from the ACE in the SE Access API.

242

Figure 3-1: Example of Architecture for Access Rule Enforcement
DeviceDevice application
trigger event

send APDUNFC APISE Access API

NFC API Implementation

SE Access API Implementation

Access Control Enforcer

Access Control Enforcer
read rules

read rules
SE
SEAC Access Rules

HCI EVT_TRANSACTION over SWP
SE application

243
244
245
246
247
248
249

The ACE requires capabilities from the NFC API to determine which Secure Element sent the HCI
EVT_TRANSACTION. Then the ACE shall apply the NFC rules retrieved from this Secure Element. For thesake of efficiency, the NFC rules shall be cached in the device (the cache could be implemented in the NFC
stack or somewhere else in the device). The ACE has to apply these rules following the process defined in
section 4.2.1 with the following precisions:

250
251
252
253
254

• When an NFC Transaction Event targeting a Device application is received, the ACE shall fetch therefresh tag using the GET DATA [Refresh tag] from the ARA-M on the targeted Secure Element. If therefresh tag returned is different from the value previously obtained from this Secure Element, then,before evaluating the rules, the ACE shall fetch a new copy of the whole rule set for the targeted
Secure Element.

255

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 27 / 128
256

3.3 Introduction to Access Control Rule Conflict Resolution

257
258

This section discusses access control rule conflict resolution at a high level. Additional detail is provided laterin this document.

259

The priority of a rule is not based on its reading order among other rules.

260

The policy to manage conflicting rules is based on three basic principles (in order):261

1. Specific rules have priority.

262

2. Rules associated with end-entity certificates have priority (in the case of certificate chains).

263

3. Restrictive rules have priority.

264

3.3.1

Specific Rules Have Priority

265

A specific rule is a rule that associates:

266• An Applet by specifying its AID or by specifying the implicitly selected application

267

AND

268

• A device application by specifying its DeviceAppID

269
270

All other rules are considered as generic rules. A generic rule is a rule that applies to:

271
272

• An Applet by specifying its AID or by specifying the implicitly selected application for device
applications not explicitly specified (i.e. no DeviceAppID specified in the rule)

273

OR

274
275

• A device application by specifying its DeviceAppID for Applet not explicitly specified (i.e. no AID
specified in the rule)

276

OR

277
278

• Undefined Applets with undefined device applications (i.e. this rule will be applied when neither the
AID nor the DeviceAppID is present in any other rule)

279
280
281

Note: As a general matter when considering the rules, the implicitly selected application is seen as “a specificapplication with an unknown AID”.

282
283
284

Security Warning: On a GlobalPlatform Secure Element supporting the notion of a different implicitly selected
application per logical channel, the “implicitly selected application” will apply regardless of the logical channel.

285

Rules are evaluated as most to least specific as defined in Table 3-1.
Table 3-1: Determining Priority of Rules

286
Appletexplicitly referenced?

Device Application
explicitly referenced?

Priorityyes

yeshighest (specific)

yes

no

high (generic)

no

yes

low (generic)nonoleast (generic)

287
Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 28 / 128
288

3.3.2

End-Entity Certificates Have Priority

289
290
291
292
293

If a device application is signed with a certificate within a certificate chain, then during the search for the most
specific rules, the search is based first on the certificate used to sign the application (the end entity certificate),then the next certificate up the chain, and so on, until either a certificate is found that has the appropriate levelof specificity, or it is determined that no certificate in the chain has that level. Only then does the search
proceed to the next lower level of specificity.

294This is described further in section 4.3.

295
296

3.3.3

Restrictive Rules Have Priority

297
298
299

The most restrictive rules are those that forbid access the device application to access the Applet. Less
restrictive rules permit access, but only when using certain APDUs. The least restrictive rules always permit
the device application to access the Applet. The most restrictive rules have priority.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 29 / 128
300

3.4 Access Control Rule Combination and Conflict Resolution

301
302

When several rules apply to the same access request, aggregation and conflict resolution shall be performed
either by the ARA-M or by the ACE:

303
304

• If the ACE fetches all the rules from the Secure Element using GET DATA [All], then the ACE is
responsible for the merging and conflict resolution, if any.

305
306
307
308
309
310

• If the ACE fetches the access rules for a particular access request using GET DATA [Specific](deprecated), it is the responsibility of the ARA-M to merge and resolve the potential conflicts. The
ARA-M shall determine whether several rules exist (e.g. in different storage locations within the SE)
that apply to the defined reference (consisting of a specific or generic device application identifier anda specific or generic Applet identifier). Then the ARA-M shall resolve the conflicts, if any, and return
access rule data merged as described below.

311
312
313
314

• If the ACE uses certificate hash values as DeviceAppIDs, multiple DeviceAppIDs represent thesame device application. This is because the application might be signed by several certificates, andbecause all supported hash algorithms (i.e. supported by ARA-M) shall be used to derive all possible
DeviceAppIDs from the device application.

315
316
317
318

When a set of rules exist for the same device application, i.e. when rules exists for DeviceAppIDs
derived using the SHA-1 (deprecated) and SHA-256 hash algorithms, the ACE shall use the rules
associated to the DeviceAppIDs that were derived with SHA-256. This is further detailed in
section 4.2.3.

319
320

Rule conflicts might occur, especially if rules are stored in different locations (ARA-C, ARA-M, or ARF).
Potential conflicts shall be avoided by the ARA implementation as much as possible:

321
322
323

Any ARA shall reject provisioning of a rule if a rule for the same target (AID and DeviceAppID) alreadyexists in another ARA in the SE. The Service Provider shall be informed with the dedicated status word
'6A 89'.

324

An ARA will not be able to detect conflicts with rules stored in the ARF.

325
326

However, in the following scenarios it might happen that rules applying to the same target (AID and
DeviceAppID) exist in the SE:

327
328

• If the rules are pre-installed in an ARA and are available immediately after the ARA instantiation orregistration to the ARA-M.

329
330
331
332

Note: Pre-installation of access rules in an ARA is not specified in this specification and might not be
implemented by ARAs.
• If the ARA-M reads the rules from the ARF.
Note: The reading of access rules from an ARF by the ARA-M is an optional feature.

333
334

• If an ARA-C is locked and later unlocked again and the ARA-M or another ARA-C is updated in themeantime.

335
336
337

If the ARA-M/ARA-C implementation guarantees that only one rule exists in the SE for the same target (AID,
DeviceAppID) then the ARA-M does not need to consider the following algorithm to solve conflicts or combine
rules.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 30 / 128
338

3.4.1

339
340
341

As described in section 3.3, specific rules have priority over generic rules. This strict priority shall be enforcedby the ACE. Thus, the ACE shall first look for rules that apply to the targeted Applet and the targeted device
application and shall look for generic rules only if no specific rule was found. 2

342
343

If several rules apply to the same target (AID and DeviceAppID), then these rules are aggregated and more
restrictive rules have priority over more permissive rules.

344

The following logic shall apply if several rules apply to the same target:

345
346

Algorithm to Solve Conflicts or Combine Rules• If the access rules conflict, only the rule with the highest priority shall apply, based on the following
priority orders:

347

NEVER (APDU) > APDU filter > ALWAYS (APDU)

348

NEVER (NFC) > ALWAYS (NFC)

349
350

• If the access rules are of different types (i.e. NFC permission, APDU permission), both rules are
combined and thus both rules apply.

351
352

• If multiple access rules contain APDU filters, then these shall be combined per OR operation. Thismeans an APDU is allowed if one of these filters matches:

353

AR1-APDU filter || AR2-APDU filter || AR3-APDU filter || AR4-APDU filter

354
355
356

Table 3-2 summarizes which rule is applied when two rules (R1, R2) conflict. See also Annex D, which provides
detailed examples. In this table ‘R1+R2’ refers to the combination of two rules where APDU policies (neverallowed, APDU filter, or always allowed) and NFC event policies (never allowed, always allowed) are merged.

357

Table 3-2: Access Control Rules Conflict Resolution
Conflicting rule resolution

All
R2

R1

AlwaysAll
APDU filter

Never

Always

R1=R2

R1

R1

APDU filter

R2

R1+R2

R1

Never

R2

R2

R1=R2

AlwaysAID

APDU filter

R2

Never

AlwaysAID
APDU filter

Never

R1

R1=R2

R1

R1

R2

R1+R2

R1

R2

R2

R1=R2

358
359

The following logic shall apply if rules apply to a specific Applet:

360
361

• If only one rule exists which associates the DeviceAppID of a device application with the AID of aparticular Applet, then access to that Applet from all other device applications is denied.

362
363
364

• If multiple specific rules exist, each of which associates the DeviceAppID of a different device
application with the AID of the same Applet, then access to that Applet is denied for all device
applications for which such a rule does not exist.

2

The search for the right rules is described in detail in section 4.2.3 and section 4.3.
Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 31 / 128
365

4 DEVICE INTERFACE

366
367
368
369

The ACE shall retrieve the SE access rules from the ARA-M installed on the targeted SE. Therefore the ARA-M
provides an interface for retrieving the access rules. On this interface the ACE can request either a specificaccess rule (corresponding to a specific Applet and a specific device application and a specific DeviceAppID)[deprecated], or the complete set of access rules stored in the SE. The ARA-M shall support both options.

370
371

The ARA-M of each SE and the ACE shall implement the GET DATA command, as defined in this section, tomanage the access rules.

372
373

For a UICC, the ACE shall implement in addition the following mechanism: If the ARA-M is not present, it shall
retrieve the access rules from the Access Rule Files (ARF) as defined in Chapter 7.

374
375

The ACE is in charge of interpreting the fetched access rules correctly and filtering the access according tothese rules.

376
377
378

The ARA-M shall support several logical channels for ACE(s) to retrieve rules. However, the number of
supported logical channels might be limited. An ARA-M has to return SW '69 84' on GET DATA if all supported
logical channels are already in use. In this case the ACE may retry later to select the ARA-M.

379

Secure Element is a UICC

380

Access to a UICC is denied in all of the following cases:

381• The ARA-M is not accessible (e.g. not installed, not selectable, or locked) and the ARF is not present.

382• The ARA-M is accessible but does not provide an access rule explicitly granting access.

383
384

• The ARA-M is not accessible and the ARF is present but does not provide an access rule explicitly
granting access.

385• An error occurs during the reading and interpretation of the access rules (as discussed in section 7.3)

386
387

In other words, when the SE is a UICC, a device application can access an Applet in all of the following
cases:

388• The ARA-M is accessible and provides a rule which explicitly allows the access.

389• The ARA-M is not accessible but the ARF contains a rule which allows the access.

390
391

Secure Element is not a UICC

392

Access to an SE which is not a UICC is denied in all of the following cases:

393• The ARA-M is accessible but does not provide an access rule explicitly granting access.

394• An error occurs during the reading and interpretation of the access rules.

395
396

In other words, when the SE is not a UICC, a device application can access an Applet in all of the following
cases:

397• The ARA-M is not accessible on the SE (e.g. not installed, not selectable, or locked).

398• The ARA-M is accessible and provides a rule which explicitly allows the access.

399

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 32 / 128
400

4.1 GET DATA Command

401

The GET DATA command is used to retrieve the access rules from the ARA-M and provides different modes:

402

Mode 1: Retrieve all access rules stored in the Secure Element.

403
404
405
406
407
408
409
410
411

This mode can be used to cache all access rules on the device to avoid repeatedly retrieving access rules
from the Secure Element. Since the GET DATA command in this mode can be very time-consuming, it isrecommended that this mode be performed only during the boot process of the device.

Mode 2: Retrieve a refresh tag indicating whether any access rules have been updated.
This mode can be used in conjunction with the previous one to determine whether the cached access ruleson the device need to be refreshed. When using a cached version of the rule set, the ACE shall check
whether a new version of the rules is available prior to applying cached rules.

Mode 3 (deprecated): Retrieve a specific access rule for a defined Applet (identified by theApplet’s AID) and a device application (identified by the device application’s DeviceAppID).

412
413
414
415

This mode is an alternative to mode 1. This mode could be applied if mode 2 indicates that some SE accessrules have been updated. Because the ACE cannot know which rules have been updated, it shall either
apply Mode 1 again to retrieve all access rules, or apply Mode 3 for each specific rule that is required before
the device is rebooted.

416
417

The ARA-M shall consolidate all the access rules present in the SE (including access rules stored in the filesystem and the ARA-C).

418
419

Access rules specify that for a given Applet (or all Applets on a given SE), all or selected device applications
have access rights to:420• all APDUs, no APDUs, or selected APDUs

421• NFC transaction events or no NFC transaction events

422
423
424

For NFC transaction events, if no rule explicitly specifies NFC permissions, permission shall be granted basedon APDU channel rules. A device application authorized to establish an APDU channel with an Applet is
implicitly authorized to receive NFC events from this application.

425

Concurrency of Rule Retrieval and Rule Storage

426

An ARA shall support concurrency of rule retrieval and rule storage. The following behavior shall apply:

427
428
429
430
431

• If a process to retrieve all access rules has been launched with a GET DATA [All] command and all
the rules have not yet been retrieved using one or several GET DATA [Next] commands, but anaccess rule is updated, the GET DATA [Next] command will be rejected by the ARA-M with
SW '69 84'. The ACE shall discard the access rules or part of the access rules already retrieved andshall restart the full rule retrieval procedure by sending a GET DATA [All] command.

432
433
434
435
436
437
438

• If a process to retrieve a specific access rule has been launched with a GET DATA [Specific](deprecated) command and the whole rule has not yet been retrieved using one or several
GET DATA [Next] commands, but an access rule associated with the same REF-DO (i.e. concerning
the same AID and the same DeviceAppID) is updated, the GET DATA [Next] command will berejected by the ARA-M with SW '69 84'. The ACE shall discard the part of the access rule already
retrieved and shall restart the specific access rule retrieval procedure by a sending a
GET DATA [Specific] (deprecated) command.

439
440
441

Note that an access rule is considered as updated only once the whole access rule (i.e. the whole REF-ARDO) has been received. It may require several STORE DATA commands if the REF-AR-DO is too long to fit asingle STORE DATA (Command-Store-REF-AR-DO) command.
Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 33 / 128
442

4.1.1

Command Message

443

The GET DATA command message shall be coded according to Table 4-1.
Table 4-1: GET DATA Command Message

444
Code

Value

Meaning

CLA'80' – '8F', 'C0' – 'CF', or 'E0' – 'EF'

As specified in [GP Card Spec]

INS

'CA'

GET DATA as specified in [GP Card Spec]

P1 P2

One of the following:

All:

Request to obtain all access rules.

Specific:

Request to obtain specific accessrules. (deprecated)'DF 20': Refresh tag

Refresh tag:

Request to obtain the refresh tag.

'FF 60': Next

Next:

Request to obtain the remaining bytes
which couldn’t be fetched with the lastcommand APDU.

Config:Sends the configuration of the ACE
and requests the configuration of the
ARA-M'FF 40': All'FF 50': Specific (deprecated)'DF 21': Config

Lc

Absentor
Length of REF-DO
or
Length of Device-Config-DO

Data

Absentor

REF-DOor

Device-Config-DO

Absent:If P1 P2 = [All], [Next], or [Refresh tag]

REF-DO:If P1 P2 = [Specific] (deprecated): REF-DO
references a specific access rule.

Device-Config-DO:
If P1 P2 = [Config]: Device-Config-DO contains
the ACE configuration.

Le

'00'

Expected length of the returned block

445
446
447

Note: Some CLA values might not be implemented by the ARA-M as no Secure Messaging is currently
required between the ACE and the ARA-M.

448

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 34 / 128449

4.1.1.1 Command Message Tags

450
451
452
453
454
455

The GET DATA command can be applied iteratively with subsequent GET DATA commands if the access rule
data to be fetched from the ARA is too large for one GET DATA command. The length field of the returned
Access Rule Data Object Response-ALL-REF-AR-DO/Response-AR-DO shall always indicate the full lengthof all expected AR-DOs (even if not all AR-DO bytes are present in the GET DATA response field) so that theACE can determine whether a subsequent GET DATA command is needed. The GET DATA command
supports the iteration as follows:

456

1. GET DATA [All]: Fetches the first bytes of the Response-ALL-REF-AR-DO.

457

2. GET DATA [Next]: Fetches the next (succeeding) bytes of the Response-ALL-REF-AR-DO.

458

or:

459

1. GET DATA [Specific] (deprecated): Fetches the first bytes of the Response-AR-DO.

460

2. GET DATA [Next]: Fetches the next (succeeding) bytes of the Response-AR-DO.

461
462
463
464

To retrieve access rules from the ARA-M, the command GET DATA [All] / GET DATA [Specific] (deprecated)must always be applied as the first command. A GET DATA [Next] command must be rejected by the ARA-M
with SW '69 85' if the data retrieval process did not start with a GET DATA [All] / GET DATA [Specific](deprecated).

465
466
467

The GET DATA [Config] command shall be sent by the ACE after selection of the ARA-M (i.e. it shall be sent
as the next command after the SELECT command); see section 4.4. A GET DATA [Config] command must
be rejected by the ARA-M with SW '69 85' if not received just after the SELECT command.

468
469

4.1.1.2 Command Message Data Objects

470
471
472
473
474

If the GET DATA command includes P1 P2 = [Specific] (deprecated), then a REF-DO must be included in the
Data field. This REF-DO contains an AID-REF-DO and a DeviceAppID-REF-DO which uniquely referencea specific set of access rules assigned for a given Applet (which is identified by its AID) and a device application(which is identified by its DeviceAppID). REF-DO, AID-REF-DO, and DeviceAppID-REF-DO are definedin Chapter 6.

475
476

If the GET DATA command includes P1 P2 = [Config], then a Device-Config-DO must be included in the
Data field. This Device-Config-DO contains the configuration of the ACE, as defined in Chapter 6.

477

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 35 / 128
478

4.1.2

Response Message

479
480

The command GET DATA returns the requested access rules in different data objects (depending on thecommand request) in the response message Data field.

481

4.1.2.1 Response Message Data Objects

482
483

Depending on the GET DATA request, the response message Data field contains a Response-ALL-REFAR-DO, a Response-AR-DO, a Response-Refresh-Tag-DO, or a Response-ARAM-Config-DO:

484• The Response-ALL-REF-AR-DO is mandatory for a GET DATA [All] request.

485• The Response-AR-DO is mandatory for a GET DATA [Specific] (deprecated) request.

486• The Response-Refresh-Tag-DO is mandatory for a GET DATA [Refresh tag] request.

487• The Response-ARAM-Config-DO is mandatory for a GET DATA [Config] request.

488

Response-ALL-REF-AR-DO

489

Note: Formerly named Response-ALL-AR-DO.

490
491
492
493
494
495
496

In response to a GET DATA [All] command, the ARA-M shall return all access rules stored in the Secure
Element in the response message Data field within a Response-ALL-REF-AR-DO. The length field of the
Response-ALL-REF-AR-DO shall always contain the full length of the values of all the REF-AR-DOs. If the
Response-ALL-REF-AR-DO is too large to fit in the GET DATA [All] response, then the remaining
Response-ALL-REF-AR-DO bytes can be retrieved using GET DATA [Next] commands. In this case, theresponse of the GET DATA [Next] doesn’t include any Tag and Length fields but only the next bytes of the
REF-AR-DO.

497

Table 4-2: Response-ALL-REF-AR-DO
Tag

LengthValue

Meaning

Presence'FF 40'n or 0REF-AR-DO1 | … |REF-AR-DOx

Value:

Mandatory

or
Empty

If access rules exist, a concatenation of all
REF-AR-DOs on the SE.
Empty if access rules do not exist.
Length:n is the full length of all the REF-AR-DOs.
0 if there are no rules to fetch.

498

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 36 / 128499

Response-AR-DO (deprecated)

500
501
502
503
504
505
506

If access rules exist in the Secure Element that corresponds to the REF-DO specified in the
GET DATA [Specific] (deprecated) command, then the ARA-M must return those access rules in the response
message Data field within a Response-AR-DO. The length field of the Response-AR-DO shall always containthe full length of the data object’s value. If the Response-AR-DO is too large to fit in the GET DATA [Specific](deprecated) response, then the remaining Response-AR-DO bytes can be retrieved using GET DATA [Next]
commands. In this case, the response of the GET DATA [Next] doesn’t include any Tag and Length fields but
only the next bytes of the AR-DO.

507

Table 4-3: Response-AR-DO
Tag

LengthValue

Meaning

Presence'FF 50'n or 0

AR-DO

Value:

Mandatory

An AR-DO if the referenced access rules exist.

or
Empty

Empty if access rules do not exist for thedefined reference.
Length:n is the full length of the AR-DO.
0 if there are no rules to fetch.

508
509

Response-Refresh-Tag-DO

510

Note: Formerly named Response-RefreshTag-DO.

511
512
513
514

The GET DATA [Refresh tag] command shall return a Response-Refresh-Tag-DO containing a refresh tag
that indicates whether changes have occurred in the access control data. This refresh tag is an attribute (8-byte
random number) of the ARA-M and is newly generated when the ARA-M detects an update of access control
data in the Secure Element. The ARA-M shall ensure that the new value is different from the previous one.

515

Table 4-4: Response-Refresh-Tag-DO
Tag

LengthValue

Meaning

Presence'DF 20'8

RefreshTag

Value:

Mandatory

RefreshTag is an 8-byte random number. A
new RefreshTag value indicates changes in
the access control data stored in the SE.
516

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 37 / 128517

Response-ARAM-Config-DO

518
519

The GET DATA [Config] command shall return a Response-ARAM-Config-DO containing the configurationof the ARA-M.

520
521

If the GET DATA [Config] command returns an error SW, the ACE shall consider that the ARA-M implements
version 1.0 of the specification. See section 4.4 for details on Device Interface version management.

522

Table 4-5: Response-ARAM-Config-DO
Tag

LengthValue

Meaning

Presence'DF 21'n

ARAM-Config-DO

Value:

Mandatory

The ARAM-Config-DO containing theconfiguration of the ARA-M.
Length:n is the full length of the ARAM-Config-DO.
523

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 38 / 128524

4.1.2.2 Response Message Status Words

525

A successful execution of the command shall be indicated by status bytes '90 00'.
Table 4-6: GET DATA Response Message Status Words

526
SW1

SW2

Meaning

'65'

'81'

Memory problem

'67'

'00'

Wrong length in Lc

'69'

'84'

Either of the following:• Rules have been updated and must be read again to ensure consistency, or• All the supported logical channels are already in use.
Note: In either case, the ACE shall read the rules by re-sending the command
GET DATA [All] / GET DATA [Specific] (deprecated).

'69'

'85'

Conditions not satisfied

'6A'

'80'

Incorrect values in the command data

'6A'

'86'

Incorrect P1 P2

'6A'

'88'

Referenced data not found

'6D'

'00'

Invalid instruction

'6E'

'00'

Invalid class

527
528

Response to GET DATA [Specific] (deprecated) and GET DATA [All]

529
530

ARA-M implementations shall respond to the GET DATA [Specific] (deprecated) and GET DATA [All]commands as follows:531• If no access rule is available, return one of the following:

532

o SW '6A 88', Referenced data not found (see Table 4-6)

533
534

o SW '90 00' but a response data with a Response-AR-DO of null length ('FF5000') for a
GET DATA [Specific] (deprecated)

535
536

o SW '90 00' but a response data with a Response-ALL-REF-AR-DO of null length ('FF4000')
respectively for a GET DATA [All]

537
538
539
540
541
542

Response to GET DATA [Next]
The ARA-M shall reject a GET DATA [Next] command with SW '69 85' if the data retrieval process did notstart with a GET DATA [All] / GET DATA [Specific] (deprecated).

Response to GET DATA [Config]
The ARA-M shall reject a GET DATA [Config] command with SW '69 85' if this command is not the next
command after the SELECT command.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 39 / 128543

Concurrency of Rule Retrieval and Rule Storage544

An ARA shall manage the retrieval and storage of rules at the same time.

545• If an access rule has been updated during the access rule retrieval process, then:546

o The ARA-M shall reject any GET DATA [Next] command with SW '69 84'.

547
548
549

o The ACE shall discard the access rules or part of the access rules already retrieved and shallrestart the full rule retrieval procedure by re-sending either a GET DATA [All] or a
GET DATA [Specific] (deprecated) command.

550

See section 4.1 for detail on concurrency between rule retrieval and rule storage.

551

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 40 / 128
552

4.2 Access Control Evaluation Steps

553
554

This section describes how the ACE on the device shall behave when evaluating rules from ARA-M to becompliant with the SE access control policy.

555
556
557

There are two distinct ways that the device can use the access control mechanisms on the Secure Element.
Either the device fetches all the rules in advance from the Secure Element, or it queries the Applet each time
access is requested. The following sections explain each of those usage scenarios.

558

4.2.1

Usage with Rules Cached in the Device
Figure 4-1: Device Interface Sequence with Rules Caching559

DeviceDeviceApplication
1 - request

Secure Element

Application Manager

Transport Layer
2 - forward
3 – getDeviceAppID(s)6 - access

Secure Element
Application

5 - response

Access Control
Enforcer0 – fetch rules
4 – check tag/rules

ARA-M

Secure Element
Access API
Access Control
Data

560
561

Sequence when the device uses caching of the rules:

562
563
564
565

Preliminary step: During initialization of the device execution environment, the ACE fetches rules from all
the Secure Elements available, using the GET DATA [All] command. Following this operation, rules muststay associated with the Secure Element they were fetched from, and apply only to access to that Secure
Element.

566
567

Step 1: The device application uses the SE Access API to open a communication channel with anapplication residing in a Secure Element.

568

Step 2: This request is forwarded to the ACE on the device.

569
570
571
572

Step 3: The ACE retrieves the DeviceAppID(s) of the calling application. If the device application isrunning in the REE and has multiple signatures, the ACE retrieves each certificate of each signature. The
ACE then computes the hashes (SHA-256 and SHA-1 (deprecated)) of each of these certificates. If thedevice application is signed by chained certificates, consider the more detailed explanation in section 4.3.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 41 / 128
573
574
575
576

Step 4: The ACE fetches the refresh tag using the GET DATA [Refresh tag] from the ARA-M on thetargeted Secure Element. If the refresh tag returned is different from the value previously obtained fromthis Secure Element, then the ACE fetches a new copy of the whole rule set for the targeted Secure
Element.

577
578
579
580
581

Step 5: The ACE evaluates rules based on the calling application’s DeviceAppID(s) and the targeted
AID on the Secure Element. See section 4.2.3. If the access is not granted, an error is returned to thecalling application and no further action is taken. If the access is granted, then the SE Access API performs
all operations necessary to open the channel to the Secure Element (e.g. manage channel command andapplication selection).

582

Step 6: Upon APDU transmission, the ACE applies the APDU filtering applicable to the connection (if any).

583

Note: This section is also applicable when evaluating rules from ARF on UICC if the ARA-M is not present.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 42 / 128
584
585
586
587

4.2.2

Usage with Instant Query to the ARA-M (Deprecated)
Note: This whole section shall be considered as deprecated in this version of the specification.
Therefore, it is recommended that the ACE does not use the Instant Query mechanism in new products
but instead uses the Rules Cached mechanism described in section 4.2.1.
Figure 4-2: Device Interface Sequence with Instant Query to the ARA-M

588

DeviceDeviceApplication
1 - request

Application Manager

Transport Layer
2 - forward
3 – getDeviceAppID(s)Secure Element
6 - access

Secure Element
Application4 – check rules

ARA-M

5 - response

Access Control
Enforcer
Secure Element
Access API

Access Control
Data

589
590

Sequence when the device uses instant query of the rules:

591
592

Step 1: The device application uses the SE Access API to open a communication channel with anapplication residing in a Secure Element.

593

Step 2: This request is forwarded to the ACE on the device.

594
595
596
597
598

Step 3: The ACE retrieves the DeviceAppID(s) of the calling device application. If the device application
is running in the REE and has multiple signatures, the ACE retrieves each certificate of each signature.
The ACE then computes the hashes (SHA-256 and SHA-1 (deprecated)) of each of these certificates. If
the device application is signed by chained certificates, consider the more detailed explanation insection 4.3.

599
600
601

Step 4: The ACE interrogates the ARA-M on the targeted Secure Element using the GET DATA [Specific](deprecated). The ARA-M returns the requested rules, including APDU filter details, if any. See
section 4.2.3.

602
603
604
605

Step 5: The ACE evaluates the rules to determine whether the application is allowed to access the Applet.
If the access is not granted, an error is returned to the calling application and no further action is taken. If
the access is granted, then the SE Access API performs all operations necessary to open the channel to
the Secure Element (e.g. manage channel command and application selection).

606

Step 6: Upon APDU transmission, the ACE applies the APDU filtering applicable to the connection (if any).

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 43 / 128
607

4.2.3

608
609
610
611

The ACE shall retrieve the rules that shall be applied by checking for rules associated with the device
application’s DeviceAppID(s) according to the algorithm defined below. If not using cache, the ACE may
have to issue several GET DATA [Specific] (deprecated) commands to the ARA-M to ensure that the right rule
is retrieved.

612
613

The ACE uses the following algorithm to retrieve an access rule for the device application (identified by one ormore DeviceAppIDs) and the Applet (identified by its AID):

614
615

Algorithm for Applying Rules

A) Search for a rule that is specific to the device application and to the Applet with AID:

SearchRuleFor(DeviceAppID, AID)

616
617

When the hash value of a certificate is used as the DeviceAppID, this step shall be performed
as follows:

618
619
620
621
622

• If the ARA-M supports both the SHA-256 and the SHA-1 (deprecated) hash algorithms,
search for rules corresponding to the DeviceAppID derived using the SHA-256
algorithm.
If no rule found, search for rules corresponding to the DeviceAppID derived using thedeprecated SHA-1 algorithm.

623
624

• If the ARA-M does not support the SHA-256 algorithm, search for rules corresponding to
the DeviceAppID derived using the deprecated SHA-1 algorithm.

625
626
627
628

If a rule exists, apply this rule and stop the rule search.
B) If no rule fits condition A: Search for a generic rule that applies to all device applications and the Applet
identified by AID:

629

SearchRuleFor(<AllDeviceApplications>, AID)

630
631

B-1)

632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647

Search for any specific rule that associates another device application with the Applet
identified by AID.
According to the rule conflict resolution process defined in section 3.4.1, if a specific rule
exists that associates another device application with the Applet identified by AID (e.g.
there is a rule associating AID with the DeviceAppID of another device application), thenthe ARA-M (when using GET DATA [Specific] (deprecated)) or the ACE (when using
GET DATA [All]) shall set the result of SearchRuleFor(<AllDeviceApplications>,
AID) to NEVER (i.e. precedence of specific rules over generic rules) and stop the rulesearch.

B-2)

Search for any generic rule that associates all device applications with the Applet identified by
AID.
If a rule exists, then apply this rule and stop the rule search.

C) If no rule fits condition A or B: Search for a generic rule that specifies the device application and thatapplies to all Applets:

SearchRuleFor(DeviceAppID, <AllSEApplications>)
When the hash value of a certificate is used as the DeviceAppID, this step shall be performed
as follows:

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 44 / 128
648
649
650
651
652

• If the ARA-M supports both the SHA-256 and the SHA-1 (deprecated) hash algorithms,
search for rules corresponding to the DeviceAppID derived using the SHA-256
algorithm.
If no rule found, search for rules corresponding to the DeviceAppID derived using thedeprecated SHA-1 algorithm.

653
654

• If the ARA-M does not support the SHA-256 algorithm, search for rules corresponding to
the DeviceAppID derived using the deprecated SHA-1 algorithm.

655
656
657
658

If a rule exists, apply this rule and stop the rule search.
D) If no rule fits condition A, B, or C: Search for a generic rule that applies to all device applications andto all Applets:

659

SearchRuleFor(<AllDeviceApplications>, <AllSEApplications>)

660

D-1)

661
662
663
664
665
666
667
668
669
670

Search for any generic rule that associates another device application with all Applets.
According to the rule conflict resolution process defined in section 3.4.1, if a rule exists thatassociates another device application and applies to all Applets (e.g. there is a rule
associating all Applets with the DeviceAppID of another device application), then the
ARA-M (when using GET DATA [Specific] (deprecated)) or the ACE (when using
GET DATA [All]) shall set the result of SearchRuleFor(<AllDeviceApplications>,<AllSEApplications>) to NEVER and stop the rule search.

D-2)

Search for any generic rule that associates all device applications with all Applets.
If a rule exists, then apply this rule.

Note: This section also applies when evaluating rules from the ARF on a UICC if the ARA-M is not present.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 45 / 128
671

4.3 Managing Certificate Chains

672
673
674

Note: This section applies only to the REE environment, where several certificates can be associated with a
REE application. It is not applicable to the TEE environment where the UUID is used to identify the Trusted
Application (TA).

675
676
677
678

As discussed in section 3.3.2, if the device application is signed with a certificate within a chain and if morethan one certificate of that chain is associated with access control rules, then the rule associated with thecertificate at the lowest hierarchical level in the chain that has an associated rule (which may be the end entity
certificate) shall apply.

679
680

A chain of certificates is typically embedded in the installation package (called application container in someREE systems) of the device application by the Application Provider.

681

Figure 4-3: Processing of Chained Certificates
DeviceDeviceApplication
Secure Element

1 - request

Transport Layer

2 - forward

5 - response

Device Application Certificate Container
Cert 2: Intermediate
Cert 3: End entity

Secure Element
Application

Cert 3 rules apply if exist

Application Manager

Cert 1: Root

6 - access

3 (c) - get Cert 1
3 (b) - get Cert 2
3 (a) - get Cert 3otherwise Cert 2 rules apply if exist
otherwise Cert 1 rules apply if exist

Access Control
Enforcer

ARA-M

4 - check rules for Cert 3, 2, 1

Secure Element
Access API
Access Control
Data

682
683
684
685

Figure 4-3 shows how the ACE queries the rules from the ARA-M when a device application is signed by acertificate within a chain.

686
687
688
689

In the case of certificate chains, the ACE shall retrieve the rules that shall be applied by checking the rules
associated with the different certificates of the certificate chain according to the algorithm defined below. The
ACE may have to issue several GET DATA [Specific] (deprecated) commands to the ARA-M to ensure thatthe right rule is retrieved.

690
691

In steps A) and C) of the procedure in section 4.2.3, the ACE uses the following algorithm to retrieve an accessrule for the appropriate certificate in the certificate chain.

692
693

A) Search for a rule that is specific to the device application and to the Applet with AID:
1. SearchRuleFor(EndEntityCertificate, AID)694

If a rule exists, then apply this rule and stop the rule search.

695

2. SearchRuleFor(IntermediateCertificate<1>, AID)696

If a rule exists, then apply this rule and stop the rule search.

697

...
Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 46 / 128
698

3. SearchRuleFor(IntermediateCertificate<n>, AID)699

If a rule exists, then apply this rule and stop the rule search.

700

4. SearchRuleFor(RootCertificate, AID)

701
702
703
704
705

If a rule exists, then apply this rule and stop the rule search.
B) If no rule fits condition A: Search for a generic rule that applies to all device applications and the Applet
identified by AID:
1. SearchRuleFor(<AllDeviceApplications>, AID)

706
707
708
709
710

If a rule exists, then apply this rule and stop the rule search.
C) If no rule fits condition A or B: Search for a generic rule specifies the device application and that applies
to all Applets:
1. SearchRuleFor(EndEntityCertificate, <AllSEApplications>)

711
712

If a rule exists, then apply this rule and stop the rule search.
2. SearchRuleFor(IntermediateCertificate<1>, <AllSEApplications>)713

If a rule exists, then apply this rule and stop the rule search.

714

...

715

3. SearchRuleFor(IntermediateCertificate<n>, <AllSEApplications>)

716
717
718
719
720
721
722
723

If a rule exists, then apply this rule and stop the rule search.
4. SearchRuleFor(RootCertificate, <AllSEApplications>)
If a rule exists, then apply this rule and stop the rule search.
D) If no rule fits condition A, B, or C: Search for a generic rule that applies to all device applications andto all Applets:
1. SearchRuleFor(<AllDeviceApplications>, <AllSEApplications>)
If a rule exists, then apply this rule.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 47 / 128
724

4.4 Managing the Version of the Device Interface

725
726
727
728

The ACE shall send a GET DATA [Config] to the ARA-M after the selection of the ARA-M (i.e.
GET DATA [Config] command shall be sent right after the SELECT command selecting the ARA-M) in order
to inform the ARA-M of the version of the Device Interface implemented by the ACE. In response to thiscommand the ARA-M will send back the version of the Device Interface it implements.

729

4.4.1

730
731
732

ACEs and ARA-Ms deployed in the field might implement different versions of this specification. This section
describes how ACE or ARA-M that follow this current version of the specification shall identify ACE and ARA-M
following previous versions of this specification.

733

4.4.1.1 Identifying ARA-M Version

734
735
736

The GET DATA [Config] command was not defined in version 1.0 of the specification. An ACE that implements
this version of the specification can use that fact to manage interoperability with an ARA-M implementing aformer version of the Device Interface:

737
738
739

• If the ARA-M rejects the GET DATA [Config] command with an error SW (for example SW '6A 86',
Incorrect P1 P2), the ACE shall consider that the ARA-M implements the Device Interface as definedin version 1.0 of this specification.

740
741
742
743

• If the ARA M responds to the GET DATA [Config] command with specific version information, the ACE
shall consider that the ARA M implements the Device Interface version reported in ARAM-Config-DO.
If the reported version is 1.2.0, the ARA-M supports the current version of the specification; otherwise
it supports version 1.1 of this specification.

Managing Backward Compatibility with Previous Versions744

4.4.1.2 Identifying Access Control Enforcer Version

745
746
747

The GET DATA [Config] command was not defined in version 1.0 of the specification. An ARA-M that
implements this version of the specification can use that fact to manage interoperability with an ACE
implementing a former version of the Device Interface.

748
749
750

• If the ARA-M does not receive a GET DATA [Config] command right after the ARA-M selection (i.e.
SELECT command), the ARA-M shall consider that the ACE implements version 1.0 of the Device
Interface.

751
752
753
754

• If the ARA-M receives a GET DATA [Config] command right after the ARA-M selection (i.e. SELECT
command), the ARA-M shall consider the version reported in Device-Config-DO. If the reported
version is 1.2.0, the ACE supports the current version of the specification; otherwise it supports
version 1.1 of this specification.

755

4.4.1.3 Managing ARA-M Backward Compatibility

756
757
758
759

When the ACE following this version of the specification has identified an ARA-M following version 1.0 or 1.1of this specification, it should not search for rules for DeviceAppIDs derived via SHA-256 from the device
application certificate. This means that the ACE should not attempt to provide SHA-256 hashes for
DeviceAppIDs in DeviceAppID-REF-DO when sending GET DATA [Specific] (deprecated) commands.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 48 / 128760

4.4.1.4 Managing ACE Backward Compatibility

761
762

When an ARA-M following this version of the specification has identified an ACE following version 1.0 of thisspecification:

763
764

• In the case of concurrency of rule retrieval and rule storage, the ARA-M shall send the error SW'69 85' rather than the error SE '69 84' defined in section 4.1.

765
766
767

• The ARA-M should not return ARA rules containing SHA-256 DeviceAppIDs on receipt of a
GET DATA [All] command, or a GET DATA [Specific] (deprecated) command with an empty
DeviceAppID-REF-DO.

768
769
770
771
772

When an ARA-M following this version of the specification has identified an ACE following version 1.1 of thisspecification:• The ARA-M should not return ARA rules containing SHA-256 DeviceAppIDs on receipt of a
GET DATA [All] command, or a GET DATA [Specific] (deprecated) command with an empty
DeviceAppID-REF-DO.

773

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 49 / 128
774

5 REMOTE INTERFACE BASED ON RAM

775
776
777
778

Access rules for a Secure Element can be managed via Remote Application Management (RAM) update
commands. Therefore the ARA-M and the ARA-C each provide a remote interface which allows storing ordeleting access rules in the ARA. Any remote management of the access control data should be done only
over a secure channel protocol as defined by [GP Card Spec].

779
780
781

Each time some access rules are updated in the SE (either in the ARA-M or the ARA-C), the refresh tag ownedby the ARA-M shall be updated. If the refresh tag has been updated, the device shall update the set of accessrules previously retrieved via the GET DATA [All] command.

782
783

All update operations must be atomic: If an update procedure fails (e.g. due to power loss or communication
errors) then the ARA must keep the previous state until a successful update is completed.

784

Access rules stored in the ARA-M or in an ARA-C can also be retrieved via RAM commands.

785
786
787
788

RAM commands can be accomplished by the TSM directly targeting the Secure Element via OTA (using
SCP80 or SCP81 as defined respectively in [GP Card Spec] and in GlobalPlatform Remote Application
Management over HTTP ([GP Amd B])), or via a Remote Admin Agent on the device (as defined in
GlobalPlatform Secure Element Remote Application Management ([GP SE OTA])).

789
790
791
792

In some cases remote application management can also be performed via a standalone device application(e.g. in a TEE); however, that is not standardized within GlobalPlatform. If a device application is used toforward RAM commands to the Secure Element, this access of this device application to the Secure Element
shall be explicitly granted by an access rule already stored in the Secure Element.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 50 / 128793

5.1 STORE DATA Command

794
795

The STORE DATA command is used to store access rules to the ARA-M or an ARA-C for a defined Applet(identified by the Applet’s AID) and device application (identified by the device application’s DeviceAppID).

796

The STORE DATA command can also be used to retrieve the access rules stored to the ARA-M or an ARA-C.

797
798
799

Note: In the case of SCP80, the maximum length of a REF-AR-DO which can be stored in an ARA depends
on the size of some input buffers of the SE, and the retrieval of the access rules is limited to the buffer size of
the SE.

800
801

This command can be sent directly to the ARA or through its security domain, using the standard
GlobalPlatform INSTALL [for personalization] command.

802

5.1.1

803

The STORE DATA command message shall be coded according to Table 5-1.

804
805
806

Note: When the remote management on the ARA can be performed through different interfaces, the ARA
shall terminate an already running STORE DATA session on a given interface if a STORE DATA command isreceived on another interface.

807

Table 5-1: STORE DATA Command Message

Command Message

Code

Value

Meaning

CLA'80' - '8F', 'C0' - 'CF', or 'E0' - 'EF'

As specified in [GP Card Spec]
Note: Only CLA '80' is applicable with SCP80 and SCP81.

INS

'E2'

STORE DATA as specified in [GP Card Spec]

P1 P2

P1: Reference control parameter

Reference control parameter as specified in [GP Card Spec]with:

P2: Block number• b8 indicating whether the command contains the last
block of a command chain• b5 b4 set to 10, indicating a BER-TLV formatted
command Data field• b1 set as follows:
0 for

Command-Store-REF-AR-DO
Command-Delete
Command-Update-Refresh-Tag-DO
Command-Register-Client-AIDs-DO

1 forCommand-Get
Command-Get-All
Command-Get-Client-AIDs-DO
Command-Get-Next
Command-Get-Device-Config-DO

Block number as specified in [GP Card Spec].
Lc

Length of the DO in the Data field

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 51 / 128
Code

Value

Meaning

Data

Block-DO | Command_Type

Block-DOor

Command_Type
Command_Type is one of thefollowing:
Command-Store-REF-AR-DO

The presence of Block-DO
is only applicable toCommand-Store-REF-ARDO, Command-Get,
Command-Get-All, andCommand-Get-Next.

Command-Delete
Command-Update-RefreshTag-DO
Command-Register-ClientAIDs-DO
Command-Get
Command-Get-All
Command-Get-Client-AIDsDO
Command-Get-Next
Command-Get-DeviceConfig-DO

Used to specify the data
block sent to the ARA, when
the STORE DATA istransmitted over SCP80 andsome buffer sizes arelimited.

Command-Store-REF-ARDO

Sent to an ARA to store
access rules to this ARA of
the SE

Command-Delete

Sent to an ARA to delete
access rules from this ARAof the SE

Command-UpdateRefresh-Tag-DO

Sent to an ARA to update
the refresh tag managed by
the ARA-M

Command-RegisterClient-AIDs-DO

Sent to the ARA-M toregister an ARA-C identified
by its AID.

Command-Get

Sent to an ARA to retrieveaccess rules stored in this
ARA

Command-Get-All

Sent to the ARA-M toretrieve all access rules fromthe SE

Command-Get-ClientAIDs-DO

Sent to the ARA-M toretrieve the AID of all the
ARA-Cs registered to the
ARA-M.

Command-Get-Next

Sent to an ARA to retrieve
the remaining access rules
from this ARA.

Command-Get-DeviceConfig-DO

Sent to the ARA-M toretrieve the configuration of
the ACE.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 52 / 128
Code

Value

Meaning

Le

AbsentNot present for:

or
'00'

Command-Store-REF-AR-DO
Command-Delete
Command-Update-Refresh-Tag-DO
Command-Register-Client-AIDs-DO'00' for:Command-Get
Command-Get-All
Command-Get-Client-AIDs-DO
Command-Get-Next
Command-Get-Device-Config-DO
808

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 53 / 128809

5.1.1.1 Command Message Data Objects

810
811

The access rules within an ARA-M/ARA-C can be managed with the access rule command data objects
described in this section:

812
813
814
815
816
817
818
819
820
821

Command-Store-REF-AR-DO ..........................................................................................................................53
Command-Delete..............................................................................................................................................56
Command-Update-Refresh-Tag-DO ................................................................................................................57
Command-Register-Client-AIDs-DO ................................................................................................................57
Command-Get ..................................................................................................................................................58
Command-Get-All .............................................................................................................................................58
Command-Get-Client-AIDs-DO ........................................................................................................................59
Command-Get-Next .........................................................................................................................................59
Command-Get-Device-Config-DO....................................................................................................................60822

Command-Store-REF-AR-DO

823

Note: Formerly named Command-Store-AR-DO.

824

This data object stores access rules to the ARA.

825
826
827

In this case, no response data is expected; therefore, bit 1 (the rightmost bit) of the reference control parameterP1 shall be set to 0 to indicate to the card that the command is an ISO/IEC 7816-4 ([7816-4]) Case 3 command,and the Le field shall not be present.

828

Table 5-2: Command-Store-REF-AR-DO
Tag

LengthValue

Meaning

Presence'F0'

n

REF-AR-DO

Stores the specified access rule to the
ARA-M/ARA-C.

Mandatory

Value:The REF-AR-DO that shall be stored in the
ARA-M/ARA-C.
Length:n is the full length of all value bytes even if not
all value bytes are present in the command
Data field. The remaining value bytes canfollow in subsequent STORE DATA
commands.
829

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 54 / 128
830

Storage of a rule831

A STORE DATA (Command-Store-REF-AR-DO) command can contain only a single REF-AR-DO.

832

If the REF-AR-DO to be stored in the ARA cannot be transmitted in a single STORE DATA command:

833
834

• The initial STORE DATA (Command-Store-REF-AR-DO) command can be followed by subsequent
STORE DATA commands.

835
836
837

• The access rule shall be stored in the ARA only when subsequent STORE DATA commands
containing the whole REF-AR-DO have been received. That is, the ARA shall drop the alreadyreceived parts of the REF-AR-DO in either of the following cases:

838
839

o No subsequent STORE DATA command is received and the whole REF-AR-DO has not been
received.

840
841

o P1 is set to “last block” in a subsequent STORE DATA command before all the value bytes of the
REF-AR-DO have been received.

842
843
844
845
846
847
848
849
850
851

Storage of several rules
If several REF-AR-DOs are to be stored, each REF-AR-DO needs to be transmitted using a separate
STORE DATA (Command-Store-REF-AR-DO) command. These STORE DATA (Command-Store-REFAR-DO) commands can be transmitted in a single INSTALL [for personalization] session.

Atomicity
The ARA-M/ARA-C shall ensure that the operation to update a REF-AR-DO and to update the refresh tag
owned by the ARA-M is atomic. In other words, a rule downloaded over several STORE DATA commands(REF-AR-DO too long to fit a single STORE DATA (Command-Store-REF-AR-DO) command) will be stored
in the ARA-M/ARA-C and the refresh tag updated, only once the whole rule has been received.

Rule overwrites in the current ARA

852
853
854

If a STORE DATA (Command-Store-REF-AR-DO) command contains a REF-DO already used by anexisting access rule defined in the current ARA (i.e. concerning the same AID and the same
DeviceAppID), the command is successful and the following behavior shall apply:

855
856
857
858
859
860

• If the access rule already existing in the ARA contains only an APDU-AR-DO and the rule being
stored contains only an APDU-AR-DO, then the access rule stored in the ARA will be overwritten by
the content of the APDU-AR-DO provided in the Command-Store-REF-AR-DO. Similarly, if theaccess rule already existing in the ARA contains only an NFC-AR-DO and the rule being storedcontains only an NFC-AR-DO, then the access rule stored in the ARA will be overwritten by thecontent of the NFC-AR-DO provided in the Command-Store-REF-AR-DO.

861
862
863
864
865
866
867

• If the access rule already existing in the ARA contains only an APDU-AR-DO and the rule being
stored contains only an NFC-AR-DO, then the access rule stored in the ARA will be updated by adding
an NFC-AR-DO as provided in the Command-Store-REF-AR-DO, and the existing APDU-AR-DO
remains unchanged. Similarly, if the access rule already existing in the ARA contains only an NFCAR-DO and the rule being stored contains only an APDU-AR-DO, then the access rule stored in the
ARA will be updated by adding an APDU-AR-DO as provided in the Command-Store-REF-AR-DO
command, and the existing NFC-AR-DO remains unchanged.

868
869
870
871

• If the access rule already existing in the ARA contains an APDU-AR-DO and an NFC-AR-DO and therule being stored also contains an APDU-AR-DO and an NFC-AR-DO, then the access rule stored in
the ARA will be overwritten by content of the APDU-AR-DO and NFC-AR-DO provided in theCommand-Store-REF-AR-DO.

872

Table 5-3 shows all possible overwrite scenarios.
Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 55 / 128
Table 5-3: Overwrite Scenarios

873
Rule in ARA

Rule in STORE DATA

ResultNFC-AR-DO1

APDU-AR-DO2(APDU-AR-DO2, NFC-AR-DO1)

APDU-AR-DO1

NFC-AR-DO2(APDU-AR-DO1, NFC-AR-DO2)

APDU-AR-DO1

APDU-AR-DO2(APDU-AR-DO2)

NFC-AR-DO1

NFC-AR-DO2(NFC-AR-DO2)(APDU-AR-DO1, NFC-AR-DO1)

APDU-AR-DO2(APDU-AR-DO2, NFC-AR-DO1)(APDU-AR-DO1, NFC-AR-DO1)

NFC-AR-DO2(APDU-AR-DO1, NFC-AR-DO2)

NFC-AR-DO1(APDU-AR-DO2, NFC-AR-DO2)(APDU-AR-DO2, NFC-AR-DO2)

APDU-AR-DO1(APDU-AR-DO2, NFC-AR-DO2)(APDU-AR-DO2, NFC-AR-DO2)(APDU-AR-DO1, NFC-AR-DO1)(APDU-AR-DO2, NFC-AR-DO2)(APDU-AR-DO2, NFC-AR-DO2)

874
875
876
877
878
879
880

Conflict detection between ARA instances
If a STORE DATA (Command-Store-REF-AR-DO) command contains a REF-AR-DO with a REF-DO
which exactly corresponds to the REF-DO of an access rule already defined in another ARA (i.e. concerning
the same AID and the same DeviceAppID), then the STORE DATA (Command-Store-REF-AR-DO)
command is rejected with SW '6A 89'.

Specific versus generic rules

881
882

If a specific rule is to be stored and a generic rule with the same AID or DeviceAppID already exists (inthe same ARA or in another ARA), then the specific rule will be stored.

883
884

If a generic rule is to be stored and a specific rule with the same AID or DeviceAppID already exists, thenthe generic rule will be stored.

885
886
887
888
889
890
891
892
893
894

ARA-M not available
A STORE DATA (Command-Store-REF-AR-DO) must be rejected by an ARA-C with the error SW '69 85'
if an ARA-M does not exist in the SE, or an existing ARA-M is disabled, or the ARA-C is not connected toan existing ARA-M.

Management of unknown BER-TLVs
If a STORE DATA (Command-Store-REF-AR-DO) command contains a REF-AR-DO including all required
data objects as defined in this specification and also unknown BER-TLV tags, the ARA-M/ARA-C shalldiscard the unknown BER-TLV objects and all associated data and respond with the warning SW '63 82'.
If required data objects are missing, the ARA-M/ARA-C shall discard the whole rule (REF-AR-DO) andanswer with the error SW '6A 80'.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 56 / 128895

Command-Delete

896

Note: Formerly named Command-Delete-AR-DO.

897

This data object deletes access rules in this ARA.

898
899
900

In this case, no response data is expected; therefore, bit 1 (the rightmost bit) of the reference control parameterP1 shall be set to 0 to indicate to the card that the command is a [7816-4] Case 3 command, and the Le fieldshall not be present.

901

If the Command-Delete refers to a rule already deleted, then the response shall be SW '6A 88'.
Table 5-4: Command-Delete

902
Tag

LengthValue

Meaning

Presence'F1'

n or 0One of the following:

Deletes the specified access rule from thecurrent ARA.

MandatoryAID-REF-DO
REF-DOREF-AR-DO
Empty

Value:AID-REF-DO:
All access rules assigned to thisAID-REF-DO are deleted.

REF-DO:All access rules assigned to this REF-DO
are deleted.

REF-AR-DO:
The data objects in the REF-AR-DO (APDUAR-DO, NFC-AR-DO, or both) must be empty(tag present, length field set to 0, value field
empty).
The effect on the access rule depends onwhether the REF-AR-DO contains an
APDU-AR-DO, an NFC-AR-DO, or both, as
described in Table 5-5.
Empty:All access rules are deleted.
Length:n is the full length of all value bytes
0 if no data object is specified.
903
Table 5-5: REF-AR-DO in Command-Delete

904

REF-AR-DO contains:

If an APDU-AR-DO exists in theaccess rule:

If an NFC-AR-DO exists in theaccess rule:

APDU-AR-DO only

The APDU-AR-DO is deleted.

The NFC-AR-DO remains
unchanged.

NFC-AR-DO only

The APDU-AR-DO remains unchanged.

The NFC-AR-DO is deleted.

NFC-AR-DO and
APDU-AR-DO

The APDU-AR-DO is deleted.

The NFC-AR-DO is deleted.

905
Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 57 / 128906

Command-Update-Refresh-Tag-DO

907

Note: Formerly named Command-UpdateRefreshTag-DO.

908

This data object updates the refresh tag managed by the ARA-M.

909
910
911

In this case, no response data is expected; therefore, bit 1 (the rightmost bit) of the reference control parameterP1 shall be set to 0 to indicate to the card that the command is a [7816-4] Case 3 command, and the Le fieldshall not be present.

912

Table 5-6: Command-Update-Refresh-Tag-DO
Tag

LengthValue

Meaning

Presence

'F2'

0

Empty

Request the ARA-M to update the refresh tag.

Mandatory

913
914

Command-Register-Client-AIDs-DO

915

Note: Formerly named Command-Register-ClientAIDs-DO.

916
917
918

This data object can be used to register an ARA-C to the ARA-M. An ARA-C is identified by its AID. Several
ARA-Cs can be registered by submitting this data object several times with the AIDs of the different ARA-Cs.
(Registration of multiple ARA-Cs in a single data object is deprecated.)

919
920
921

This data object shall only be processed by the ARA-M. The ARA-M shall register the ARA-C(s) identified by
the provided AID(s). If a provided AID does not correspond to an installed ARA-C, then this AID shall beignored by the ARA-M.

922
923
924

In this case, no response data is expected; therefore, bit 1 (the rightmost bit) of the reference control parameterP1 shall be set to 0 to indicate to the card that the command is a [7816-4] Case 3 command, and the Le fieldshall not be present.

925

Table 5-7: Command-Register-Client-AIDs-DO
Tag

LengthValue

Meaning

Presence'F7'

n

AID-REF-DO1 | … |AID-REF-DOx(deprecated)

Register an ARA-C to the ARA-M provided the
ARA-C is installed on the SE.

Mandatoryor

AID-REF-DO[Deprecated: Register ARA-Cs to the ARA-M
provided these ARA-Cs are installed on theSE.]
Value:AID-REF-DO corresponding to the AID of an
ARA-C to be registered to the ARA-M.
[Deprecated: More than one AID-REF-DO,
each corresponding to the AID of an ARA-C
to be registered to the ARA-M.]
Length:n is the full length of all value bytes even if not
all value bytes are present in the command
Data field. The remaining value bytes canfollow in subsequent STORE DATA
commands.
926

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 58 / 128927

Command-Get

928

Note: Formerly named Command-Get-AR-DO.

929

This data object is used to retrieve all the access rules stored to the ARA.

930
931
932

In this case, bit 1 (the rightmost bit) of the reference control parameter P1 shall be set to 1 to indicate to thecard that the command is a [7816-4] Case 4 command, the Le field shall be set to '00', and therefore, response
data is expected.

933

Table 5-8: Command-Get
Tag

LengthValue

Meaning

Presence'F3'

n or 0

Empty

Get the access rules stored in the ARA-M or
ARA-C.

Mandatoryor

AID-REF-DO

Value:
Empty:
If this STORE DATA (Command-Get) is sent
to an ARA-C, get all the access rules stored
to this ARA-C.
If this STORE DATA (Command-Get) is sent
to the ARA-M, get all the access rules stored
to the ARA-M itself.

AID-REF-DO:
This data object can only be used in a
STORE DATA (Command-Get) sent to the
ARA-M.
The AID-REF-DO shall correspond to the
AID of an ARA-C already registered to the
ARA-M. In this case, the ARA-M shall return
only all the rules stored to this ARA-C.
Length:n is the full length of the AID-REF-DO.
0 if no AID-REF-DO is specified.
934
935

Command-Get-All

936

Note: Formerly named Command-GetAll-AR-DO.

937
938

This data object is used to retrieve all the access rules stored to the SE. This data object can only be sent to
the ARA-M.

939
940
941

In this case, bit 1 (the rightmost bit) of the reference control parameter P1 shall be set to 1 to indicate to thecard that the command is a [7816-4] Case 4 command, the Le field shall be set to '00', and therefore, response
data is expected.

942

Table 5-9: Command-Get-All
Tag

LengthValue

Meaning

Presence

'F4'

0

Empty

Get all the access rules stored in the SE as
sent to the ACE using a GET DATA [All]command.

Mandatory

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 59 / 128943
944

Command-Get-Client-AIDs-DO

945

Note: Formerly named Command-Get-ClientAIDs-DO.

946

This data object retrieves AIDs of ARA-Cs registered to the ARA-M.

947
948
949

This data object shall only be processed by the ARA-M. The ARA-M shall return the Response-ARAC-AIDDO (as described in Table 5-13) holding a list of AID-REF-DOs indicating the AID of each of the ARA-Cs
registered to the ARA-M.

950
951
952

In this case, bit 1 (the rightmost bit) of the reference control parameter P1 shall be set to 1 to indicate to thecard that the command is a [7816-4] Case 4 command, the Le field shall be set to '00', and therefore, response
data is expected.

953

Table 5-10: Command-Get-Client-AIDs-DO
Tag

LengthValue

Meaning

Presence

'F6'

0

Empty

Get the AIDs of all ARA-Cs registered to the
ARA-M.

Mandatory

954
955

Command-Get-Next

956

Note: Formerly named Command-GetNext-AR-DO.

957
958
959

This data object is used to retrieve the remaining data after a first Command-Get, Command-Get-All,
Command-Get-Client-AIDs-DO, or Command-Get-Device-Config-DO when all the requested rules
couldn’t be fetched in response to the first command.

960
961
962

In this case, bit 1 (the rightmost bit) of the reference control parameter P1 shall be set to 1 to indicate to thecard that the command is a [7816-4] Case 4 command, the Le field shall be set to '00', and therefore, response
data is expected.

963
964
965

If the data retrieval process did not start with a Command-Get, Command-Get-All, Command-Get-ClientAIDs-DO, or Command-Get-Device-Config-DO, then the Command-Get-Next shall be rejected with
SW '69 85'.

966

Table 5-11: Command-Get-Next

967
968

Tag

LengthValue

Meaning

Presence

'F5'

0

Empty

Get the remaining data after a first Command-Get,
Command-Get-All, Command-Get-Client-AIDs-DO, or
Command-Get-Device-Config-DO when all therequested rules couldn’t be fetched in response to this firstcommand

Mandatory

Note: An ARA shall manage the retrieval and storage of rules at the same time. For the RAM interface:969

If an access rule has been updated during the access rule retrieval process, then:970• The ARA shall reject the STORE DATA (Command-Get-Next) command with SW '69 84'.

971
972
973
974

• The remote management entity shall discard the access rules or part of the access rules already
retrieved and shall restart the full rule retrieval procedure by re-sending either a STORE DATA(Command-Get-All) or a STORE DATA (Command-Get) command. See section 4.1 for detail on
concurrency between rule retrieval and rule storage.
Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 60 / 128975

Command-Get-Device-Config-DO

976
977
978

This data object is used to retrieve the configuration of the ACE implemented in the device or the list of thedifferent configurations if several ACEs are implemented in the device. This configuration includes the versionof the Device Interface implemented by the ACE.

979

This data object shall only be processed by the ARA-M.

980
981
982

In this case, bit 1 (the rightmost bit) of the reference control parameter P1 shall be set to 1 to indicate to thecard that the command is a [7816-4] Case 4 command, the Le field shall be set to '00', and therefore, response
data is expected.

983

Table 5-12: Command-Get-Device-Config-DO
Tag

LengthValue

Meaning

Presence

'F8'

0

Empty

Get the configuration(s) of the ACE(s)implemented in the device

Mandatory

984

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 61 / 128
985

5.1.2

Response Message

986

5.1.2.1 Response Message Data Objects

987
988
989

If the command data object used in the STORE DATA request is Command-Store-REF-AR-DO, CommandDelete, Command-Update-Refresh-Tag-DO, or Command-Register-Client-AIDs-DO, then there is no
response data.

990
991

If the command data object used in the STORE DATA request is Command-Get or Command-Get-All, thenthe response message Data field contains a Response-ALL-REF-AR-DO as defined in Table 4-2:

992
993

• In response to STORE DATA (Command-Get), Response-ALL-REF-AR-DO includes all the accessrules stored in the current ARA.

994
995

• In response to STORE DATA (Command-Get-All), Response-ALL-REF-AR-DO includes all theaccess rules stored in the SE as sent to the ACE in response to the command GET DATA [All].

996
997
998

If the command data object used in the STORE DATA request is Command-Get-Client-AIDs-DO, then the
response message Data field contains a Response-ARAC-AID-DO as defined in Table 5-13. The ResponseARAC-AID-DO includes the AIDs of all the ARA-Cs registered to the ARA-M.

999
1000

If the command data object used in the STORE DATA request is Command-Get-Device-Config-DO, thenthe response message Data field contains a Response-Device-Config-DO as defined in Table 5-14.

1001
1002
1003
1004

In each case (Command-Get, Command-Get-All, Command-Get-Client-AIDs-DO, or Command-GetDevice-Config-DO), if the Response-ALL-REF-AR-DO, Response-ARAC-AID-DO, or ResponseDevice-Config-DO is too large to fit in the STORE DATA response, then the remaining bytes can be
retrieved using STORE DATA (Command-Get-Next) commands.

1005
1006
1007
1008
1009
1010

In response to STORE DATA (Command-Get-Next), the response data includes the remaining bytes of the
Response-ALL-REF-AR-DO, Response-ARAC-AID-DO, or Response-Device-Config-DO that couldn’t befetched in response to the initial STORE DATA (Command-Get), STORE DATA (Command-Get-All), STOREDATA (Command-Get-Client-AIDs-DO), or STORE DATA (Command-Get-Device-Config-DO). The
response to the STORE DATA (Command-Get-Next) doesn’t include any Tag Length fields but only the next
bytes of the Response-ALL-REF-AR-DO, Response-ARAC-AID-DO, or Response-Device-Config-DO.

1011

Response-ARAC-AID-DO

1012
1013

In response to STORE DATA (Command-Get-Client-AIDs-DO), the ARA-M shall return the AID of each of
the ARA-Cs currently registered within a Response-ARAC-AID-DO.

1014

Table 5-13: Response-ARAC-AID-DO
Tag

LengthValue

Meaning

Presence'FF 70'n

AID-REF-DO1 | … |AID-REF-DOx

Value:

Mandatory

or
Empty

The list of the AIDs of all the ARA-Cs
registered to the ARA-M.
Empty if no ARA-C is registered to the
ARA-M.
Length:n is the length of all the AIDs returned.
0 if no ARA-C is registered to the ARA-M.

1015

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 62 / 1281016

Response-Device-Config-DO

1017
1018
1019

In response to STORE DATA (Command-Get-Device-Config-DO), the ARA-M shall return the configurationof the ACEs that have accessed the ARA-M since the last device initialization. More specifically, the ARA-M
shall return a Response-Device-Config-DO (as defined in Table 5-14) as follows:

1020
1021

• If no ACE has accessed the ARA-M since the last device initialization, the Response-DeviceConfig-DO shall be empty.

1022
1023

• If a single ACE has accessed the ARA-M since the last device initialization, the Response-DeviceConfig-DO shall contain the configuration of that ACE.

1024
1025

• If several ACEs have accessed the ARA-M since the last device initialization, the ResponseDevice-Config-DO shall contain a list of the different configurations implemented by those ACEs.

1026
1027
1028
1029

o If one of the ACEs did not sent a Device-Config-DO by using the command
GET DATA [Config], the ARA-M shall assume that this ACE implements v1.0 of this specificationand shall append a Device-Config-DO with the Device-Interface-Version-DO ‘01 00 00’
in the Response-Device-Config-DO.

1030
1031

o If several ACEs implement the same Device-Config-DO, the ARA-M shall append only one
instance of this Device-Config-DO in the Response-Device-Config-DO.

1032
1033
1034

o A maximum of five Device-Config-DOs can be returned. If more than five Device-ConfigDOs are required, only the first five Device-Config-DOs will be returned in the ResponseDevice-Config-DO.

1035

Table 5-14: Response-Device-Config-DO
Tag

LengthValue

Meaning

Presence'FF 7F'n

Device-Config-DO

Value:

Mandatoryor

Device-ConfigDO1 |…| DeviceConfig-DOx
or
Empty

If a single ACE has accessed the ARA-M
since the last device initialization, DeviceConfig-DO containing the configuration ofthat ACE.
If several ACEs have accessed the ARA-M
since the last device initialization, list of
Device-Config-DOs containing no morethan five different configurations implemented
by those ACEs.
Empty if no ACE has accessed the ARA-M
since the last Secure Element power up.
Length:n is the length of all the Device-ConfigDOs.
0 if no ACE has accessed the ARA-M since
the last Secure Element power up.

1036

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 63 / 1281037

5.1.2.2 Response Message Status Words

1038
1039
1040

If the STORE DATA command is rejected due to inconsistencies or wrong coding within the data objects
defined in this specification, the ARA-M/ARA-C shall reject the STORE DATA command with the appropriate
error SW as defined in Table 5-15.

1041

Block-DO

1042

If Block-DO is received, but is not supported by the ARA-M/ARA-C, SW '69 81' shall be returned.

1043
1044
1045
1046
1047

The presence of a Block-DO is only applicable for a STORE DATA (Command-Store-REF-AR-DO,
Command-Get, Command-Get-All, or Command-Get-Next). If any other STORE DATA (CommandDelete, Command-Update-Refresh-Tag-DO, Command-Register-Client-AIDs-DO, Command-GetClient-AIDs-DO, or Command-Get-Device-Config-DO) includes a Block-DO, the ARA-M/ARA-C
shall reject the STORE DATA command with the SW '69 85'.

1048
1049

Note: As Block-DO was not defined in version 1.0 of the specification, an ARA-M/ARA-C implementing
v1.0 of this specification may reject a STORE DATA with a Block-DO with an error SW '6A 80'.

1050
1051
1052
1053
1054

Unknown BER-TLVs
If the STORE DATA (Command-Store-REF-AR-DO) command includes one or more unknown BER-TLVs
inside the REF-AR-DO but all other consistency checks are performed successfully, the ARA-M/ARA-C
shall discard the unknown BER-TLVs in the REF-AR-DO and all associated data, store the rest of the
REF-AR-DO, and respond with the warning SW '63 82'.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 64 / 128
1055
1056

A successful execution of the command (other than one that requires the warning SW '63 82') shall be
indicated by status bytes '90 00'.

1057

Table 5-15: STORE DATA Response Message Status Words
SW1

SW2

Meaning

'63'

'81'

Rule successfully stored but an access rule already exists for this target (deprecated– see note following table)

'63'

'82'

Rule successfully stored but the access rule contained at least one unknown
BER-TLV that has been discarded

'65'

'81'

Memory problem

'67'

'00'

Wrong length in Lc

'69'

'81'

DO is not supported by the ARA-M/ARA-C

'69'

'82'

Security status not satisfied

'69'

'84'

Rules have been updated and must be read again to ensure consistency

'69'

'85'

Conditions not satisfied

'6A'

'80'

Incorrect values in the command data

'6A'

'84'

Not enough memory space

'6A'

'86'

Incorrect P1 P2

'6A'

'88'

Referenced data not found

'6A'

'89'

Conflicting access rule already exists in the Secure Element

'6D'

'00'

Invalid instruction

'6E'

'00'

Invalid class

1058
1059
1060
1061

Note: Some ARA vendors may use SW '63 81', which was defined in v1.0 of this specification, but the
behavior of the ARA in this case was implementation dependent. With the clarification of conflict detection
between ARA instances in section 5.1.1.1, SW '63 81' is no longer applicable.

1062

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 65 / 1281063

6 GENERAL DATA OBJECTS

1064
1065

When storing and retrieving access rules from and to the Secure Element, the access rules and access rulereferences shall be coded in BER-TLV data objects to indicate the type and length of values.

1066
1067

In the definitions below, when a data object (DO) is constructed from other DOs, the order as defined in the
DO description shall be enforced.

1068

Tags

1069
1070
1071

The ranges of tag values listed in Table 6-1 are reserved for data objects in this specification and shall not be
used in additional BER-TLVs (considered as unknown BER-TLVs in this specification) supported in customized
ARA and ACE implementations.

1072

Table 6-1: Reserved Data Object Tags for GlobalPlatform SEAC Specification
Tag Ranges Reserved for GlobalPlatform SEAC Specification• '4F'• 'E0' to 'EB'

• 'C0' to 'CB'

• 'F0' to 'FB'

• 'D0' to 'DB'

• 'FF 1F' to 'FF 7F'• 'DF 1F' to 'DF 7F'
1073
1074

Currently defined data object tags are summarized in Annex B.

1075

Unknown BER-TLVs

1076
1077

When receiving a BER-TLV with an unknown tag, the ACE and the ARA-M/ARA-C shall discard the BER-TLV
object and all data within it.

1078
1079

If the ARA-M/ARA-C implements additional BER-TLVs for custom purpose, those additional BER-TLVs might
be processed by a customized ACE implementation. However, this specification guarantees that:

1080
1081

• A non-customized ARA will be able to manage customized access rules received from a customized
Remote Administration server: The customized part of the access rule will be discarded.

1082
1083

• A non-customized ACE will be able to manage customized access rules received from a customized
ARA-M: The customized part of the access rule will be discarded.

1084
1085
1086
1087

Those additional BER-TLVs are considered as unknown BER-TLVs in this specification and might besupported by customized ARA and ACE implementations. The handling of such additional BER-TLVs, to be
implemented by a customized ARA and ACE, depends on individual schemes and is completely out of thescope of this GlobalPlatform specification.

1088

Additional BER-TLVs to be defined for custom purpose have to use tags that comply with the following table:

1089

Table 6-2: Reserved Data Object Tags for Proprietary Usage
Tag Ranges Reserved for Proprietary Usage• 'CC' to 'CE'

• 'EC' to 'EE'

• 'DC' to 'DE'

• 'FC' to 'FE'

• 'DF 80' to 'DF 8F'• 'FF 80' to 'FF 8F'

1090

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 66 / 128
1091

6.1 Access Rule Reference Data Objects

1092
1093

The GET DATA and STORE DATA command require a set of data objects in the Data field for referencing andassigning the access rule data which shall be read from the SE or stored in the SE.

1094
1095
1096
1097
1098
1099

The AID and DeviceAppID reference data objects assign access rules to a specific Applet and device
application. If access rules shall be stored in the ARA or retrieved from the ARA it is necessary to specify theApplet and device application to create a unique assignment to these access rules. The Applet is uniquely
identified by the AID specified in the AID reference data object (AID-REF-DO) whereas the device applicationis uniquely identified by the DeviceAppID specified in the DeviceAppID reference data object(DeviceAppID-REF-DO).

1100

AID-REF-DO

1101
1102
1103

The AID-REF-DO shall be used to store and retrieve the corresponding access rules for an Applet (which is
identified by its AID) to and from the ARA. Two different AID reference data objects exist and one of these canbe chosen and applied for a GET DATA and STORE DATA command:

1104

Table 6-3: AID-REF-DO
Tag

LengthValue

Meaning'4F'

5-16 or 0

AID

Value:

or

AID:

Empty

Identifies the specific Applet for which rules are to be stored or
retrieved. This AID can also be a partial AID (containing for example
only the RID, as defined in [7816-5]).
Empty:
Indicates that the rules to be stored or retrieved are associated with allApplets not covered by a specific rule
Length:5-16 for an AID according to [7816-5]
0 for empty value field

'C0'

0

Empty

Implicitly selected application (all channels)

1105
1106
1107
1108
1109
1110
1111
1112

When trying to find a rule corresponding to an Applet, the AID targeted can be a full AID or a partial AID. A
partial AID is used to perform SELECT [by name] [first occurrence] command and then one or more SELECT[by name] [next occurrence] commands as defined in [7816-4]. In both cases, full AID and partial AID, the
ARA-M (when ACE uses GET DATA [Specific] (deprecated)) or the ACE (when using GET DATA [All]) shall
only consider rules having an AID-REF-DO with an AID value matching exactly with the AID given in the
AID-REF-DO of the GET DATA [Specific] (deprecated) or specified by the device application to the ACE
through the SE Access API.

1113
1114

Note: When a device application is selecting Applets using selection by partial AID, access to the Applets by
the device application will only be granted if there is an access rule defined for this partial AID.

1115

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 67 / 128
1116

DeviceAppID-REF-DO

1117
1118

The DeviceAppID-REF-DO shall be used to store and retrieve the corresponding access rules for a device
application (which is identified by the DeviceAppID) to and from the ARA:

1119

Table 6-4: DeviceAppID-REF-DO
Tag

LengthValue

Meaning'C1'

32, 20, or 0

DeviceAppID

Value:or
Empty

DeviceAppID:
o Identifies the specific device application that the rules
apply to.
o Contains one of following values:

 Hash of the certificate of the Application Provider:
Used in most cases when the application is running in
the REE.

 Unique identifier (this could be a TA UUID) of theapplication: Used when the application is running in
the TEE or when it is running in the REE but thecertificate is not an appropriate identifier (seesection 3.1.2). This unique identifier shall be paddedwith 'FF' in order to provide a length of 20 bytes.
Empty:
Indicates that the rules apply to all device applications notcovered by a specific rule.
Length:32 for 32-byte SHA-256 hash value
20 for 20-byte SHA-1 hash value (deprecated)
20 for unique identifier (padded with 'FF' if necessary)
0 for empty value field
1120
1121
1122

To allow transitions from SHA-1 (deprecated) to SHA-256, support for both SHA-1 (deprecated) and SHA-256
hash values is mandatory for ARA and ACE compliant with this version of the document.

1123
1124

While support for SHA-1 is deprecated for future versions, support for SHA-256 hash values will remain
mandatory for ARA and ACE compliant to future Device Interface Versions.

1125

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 68 / 128
1126

REF-DO

1127
1128
1129

The REF-DO contains an AID-REF-DO and a DeviceAppID-REF-DO which uniquely reference a specific
set of access rules assigned for a given Applet (which is identified by its AID) and a device application (which
is identified by the DeviceAppID).

1130

Table 6-5: REF-DO
Tag

LengthValue

Meaning'E1'

n

AID-REF-DO |DeviceAppID-REF-DO

Value:A concatenation of an AID-REF-DO and a DeviceAppIDREF-DO.
Length:n is the total length of all data objects in Value.

1131
1132

REF-AR-DO

1133
1134

The REF-AR-DO contains an Access Rule Data Object and its corresponding references for the Applet (AID
reference) and device application (DeviceAppID reference).

1135

Table 6-6: REF-AR-DO
Tag

LengthValue

Meaning'E2'

n

REF-DO | AR-DO

Value:A concatenation of a REF-DO and an AR-DO.
The REF-DO must correspond to the succeeding AR-DO.
Length:n is the total length of all data objects in Value.

1136

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 69 / 128
1137

6.2 Access Rule Data Objects

1138
1139

The ARA in the Secure Element can store and retrieve access rules for APDU access and for NFC event
access, which are defined in different Access Rule Data Objects.

1140

AR-DO

1141

The AR-DO contains one or two access rules of type APDU or NFC.
Table 6-7: AR-DO

1142
Tag

LengthValue

Meaning'E3'n

One of the following:

Value:APDU-AR-DO
NFC-AR-DO
APDU-AR-DO | NFC-AR-DO

An APDU-AR-DO, or an NFC-AR-DO, or aconcatenation of an APDU-AR-DO and an NFC-ARDO.
Length:n is the total length of all data objects in value.

1143

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 70 / 128
1144

APDU-AR-DO

1145
1146
1147

An APDU Access Rule Data Object defines an access rule for APDU access. The APDU access can either be
restricted by a generic rule based on an “access is NEVER/ALWAYS allowed” policy or by a specific rule basedon APDU filters which defines the range of allowed APDUs more precisely.

1148

Table 6-8: APDU-AR-DO
Tag

LengthValue

Meaning'D0'

1 or n*8

One of the following:

Value:'00'

Contains a generic APDU access rule:'01'

NEVER ('00'): APDU access is not allowed

APDU filter 1 | … |APDU filter n

ALWAYS ('01'): APDU access is allowedorContains a specific APDU access rule based on one or more
APDU filter(s):APDU filter: 8-byte APDU filter consists of:
4-byte APDU filter header (defines the header ofallowed APDUs, i.e. CLA, INS, P1, and P2 as definedin [7816-4])
4-byte APDU filter mask (bit set defines the bits whichshall be considered for the APDU header comparison)
An APDU filter shall be applied to the header of the APDU
being checked, as follows:if((APDU_header & APDU_filter_mask) ==APDU_filter_header)then allow APDU
Length:1 if value contains a generic APDU access rule.
n*8 if value contains a specific APDU access rule, where n is
the number of APDU filters included in value.
1149

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 71 / 128
1150

NFC-AR-DO

1151
1152
1153
1154
1155
1156
1157

In the NFC use case, a mobile device application gathers information from its associated Applet using the SE
Access API. However, when the Applet wants to trigger its associated mobile application, it sends an HCIEVT_TRANSACTION according to ETSI TS 102 622 ([102 622]) over SWP to the device. This event is handled
by the device, which starts the corresponding device application. In some other implementations, this event isgenerated by the selection of the application on the Secure Element, and then publicized by the NFC driverstack on the device. Disclosure of such events to malicious applications can lead to phishing and denial ofservice attacks.

1158
1159

To prevent this, it shall be possible to use the device application’s DeviceAppID to authorize device
applications to receive NFC events issued by the Applet.

1160
1161
1162

An NFC event data object defines an access rule for generating NFC events for a specific device application.
The NFC event access can be restricted by a rule based on an “event access is NEVER/ ALWAYS allowed”
policy.

1163

Table 6-9: NFC-AR-DO
Tag

LengthValue

Meaning'D1'1'00', '01'

Value:
Contains an NFC event access rule:
NEVER ('00'): NFC event access is not allowed.
ALWAYS ('01'): NFC event access is allowed.

1164
1165
1166
1167

If no NFC event access rule exists, then the ACE shall not allow the sending of the NFC event to the targeted
device application, unless this device application is explicitly allowed by an APDU access rule to access theApplet which is referenced by the AID parameter in the HCI EVT_TRANSACTION as defined in [102 622].

1168

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 72 / 128
1169

6.3 Configuration Management Data Objects

1170
1171

The GET DATA and STORE DATA commands require a set of data objects in the Data field for retrieving theconfiguration of the ACE and of the ARA-M.

1172

Device-Config-DO

1173
1174

The ACE shall use the Device-Config-DO to inform the ARA-M of its configuration, when sending the
GET DATA [Config] command.

1175
1176

The TSM can retrieve the Device-Config-DO by sending the STORE DATA (Command-Get-DeviceConfig-DO) command to the ARA-M.

1177
1178

In this version of the specification, Device-Config-DO contains only the version of the Device Interface
implemented by the ACE (Device-Interface-Version-DO).

1179

Table 6-10: Device-Config-DO
Tag

LengthValue

Meaning'E4'5

Device-Interface-Version-DO

Value:
Version of the Device Interface implemented by
the ACE.

1180
1181

ARAM-Config-DO

1182
1183

The ARA-M shall use the ARAM-Config-DO to inform the ACE of its configuration, in response to the
GET DATA [Config] command.

1184
1185

In this version of the specification, ARAM-Config-DO contains only the version of the Device Interface
implemented by the ARA-M (Device-Interface-Version-DO).

1186

Table 6-11: ARAM-Config-DO
Tag

LengthValue

Meaning'E5'5Device-Interface-Version-DO

Value:
Version of the Device Interface implemented by
the ARA-M.

1187

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 73 / 128
1188

Device-Interface-Version-DO

1189
1190

The Device-Interface-Version-DO shall be used to identify which version of the Device Interface isimplemented either by the ACE or the ARA-M.

1191
1192

The version of the device interface is incremented only when there is a change in the specification of theDevice Interface defined in Chapter 4.

1193

Table 6-12: Device-Interface-Version-DO
Tag

LengthValue

Meaning'E6'3

VersionValue:
Version of the Device Interface implemented by the ARA-M or the ACE.
Version is a 3-byte number ‘xyz’, corresponding to the coding of aversion x.y.z.
In this version of the specification, v1.2.0, the Version shall be set to'01 02 00'.

1194
1195

Block-DO

1196
1197
1198
1199
1200
1201
1202
1203
1204

The Block-DO is used to specify a data block which shall be stored in the ARA or retrieved from an ARA.
The data block is specified by offset and length. Block-DO may be included in STORE DATA (CommandStore-REF-AR-DO), STORE DATA (Command-Get-All), STORE DATA (Command-Get), and STORE DATA(Command-Get-Next) as an additional data object. Block-DO allows adaptation to certain payload size
constraints for transmissions. The Remote Administration Server shall use Block-DO only if many accessrules or long access rules need to be transmitted over SCP80 and the incoming or the outgoing buffer size is
too small to perform this transmission within one INSTALL [for personalization] session. In this case data canbe stored or retrieved block by block over several INSTALL [for personalization] sessions by using BlockDO.

1205

Table 6-13: Block-DO
Tag

LengthValue

Meaning'E7'3offset | length

3 bytes: 2 bytes offset, 1 byte length
The offset and length specify the data block of access rule data whichshall be:o stored in the session of STORE DATA (Command-Store-REFAR-DO)oro retrieved in the session of STORE DATA (Command-Get-All)or STORE DATA (Command-Get) and the following STOREDATA (Command-Get-Next).
The 2 bytes of offset are stored in big-endian (high byte first) order.

1206

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 74 / 128
1207

Usage of Block-DO for the storage of an access rule:

1208
1209

• For a Block-DO included in the initial STORE DATA (Command-Store-REF-AR-DO), the offset must
be set to 0.

1210• For a Block-DO included in any subsequent STORE DATA (Command-Store-REF-AR-DO):

1211
1212

o If the offset is not equal to the (offset + length) of the previous command, the ARA shall returnSW '6A 80'. However, the ARA shall not reject a repetition of the previous command.

1213
1214

o If the offset exceeds the length of the remaining part of the REF-AR-DO being stored, the ARA
returns SW '6A 80'.

1215

• The length in the Block-DO is the length of the part of the REF-AR-DO being stored.

1216
1217

Note: When computing the length of the Block-DO, the Remote Administration Server shall consider
that additional bytes are needed and also have to fit into the SE incoming buffer:

1218
1219

o Additional bytes for the ETSI TS 102 225 ([102 225]) command packet header and ETSITS 102 226 ([102 226]) command script format, as required by SCP801220

o Additional bytes for coding of the STORE DATA (Command-Store-REF-AR-DO)

1221
1222

• If the length is not equal to the length of the part of the REF-AR-DO being stored, the ARA returns
SW '6A 80'.

1223
1224
1225

• If a rule storage session has been initiated with a STORE DATA (Command-Store-REF-AR-DO)
including a Block-DO, all the following STORE DATA () shall include a Block-DO, otherwise the
ARA shall return SW '69 85'.

1226

Usage of Block-DO for the retrieval of access rules:

1227
1228

• The offset in a Block-DO included in a STORE DATA (Command-Get-All) or STORE DATA(Command-Get) must be set to 0.

1229
1230
1231

• If the offset in a STORE DATA (Command-Get-Next) is not equal to the (offset + length) of theprevious command, the ARA shall return SW '6A 80'. However, the ARA shall not reject a repetition of
the previous command.

1232
1233

• If the offset is longer than the whole Response-ALL-REF-AR-DO being retrieved, the ARA returns
SW '6A 80'.

1234
1235

• The length in the Block-DO shall not exceed the length of data which is available for the ARA in theSE outgoing buffer to transfer the response data to the Remote Administration Server.

1236
1237
1238

Note: When computing the length of the Block-DO, the Remote Administration Server shall consider
that additional bytes have to fit into the SE outgoing buffer for the [102 225] response packet header
and [102 226] response script format, which are required by SCP80.

1239
1240
1241

• If the length exceeds the length of the remaining part of the Response-All-REF-AR-DO being
retrieved, the ARA returns SW '90 00' and only the remaining data of the Response-All-REF-ARDO is sent.

1242
1243
1244

• If a rule retrieval session has been initiated with a STORE DATA (Command-Get-All) or STOREDATA (Command-Get) including a Block-DO, the following STORE DATA (Command-Get-Next)
shall include a Block-DO; otherwise the ARA shall return SW '69 85'.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 75 / 128
1245

7 STRUCTURE OF ACCESS RULE FILES (ARF)1246

7.1 Background

1247
1248
1249

The Access Rule Files (ARF) can be stored in a PKCS#15 file structure in the Secure Element. The following
sections define the file structure. The ASN.1 object description is based on the implicit ASN.1 encoding(see [X.690]), except when explicitly mentioned (e.g. AID).

1250

There may be two different file structures in the Secure Element:

1251
1252
1253

• DODF(1), a file structure for SHA-1 (deprecated) hash algorithm derived DeviceAppIDs. This filestructure is identical to the one defined in previous versions of this specification and will potentially beremoved in future versions of this specification.

1254
1255

• DODF(2), a file structure introduced in version 1.2 of this specification for SHA-256 hash algorithm
derived DeviceAppIDs.

1256
1257

Each file structure is in a separate DODF file under the PKCS#15 ODF file. See section 7.1.3 for the registered
OIDs of the two file structures.

1258
1259
1260

DODF(1) and DODF(2) have the same file content and file structure; they differ only in the hash algorithm
used to derive the DeviceAppID in the Condition object of the Access Control Conditions File (ACCF),
defined in section 7.1.6.

1261

File Paths

1262
1263
1264

All the paths used for the access control mechanism described in this specification (DODF, ACMF, and ACRF
files) shall be relative paths from a PKCS#15 directory. The full path starting from the UICC Master File (MF)shall not be used. The path encoding is defined in [PKCS15].

1265

7.1.1

1266
1267

If needed, the end of the files shall be padded using 'FF', and only 'FF', bytes. The parsing engine used to
manage the files involved in the access control mechanism shall support such padding.

1268

7.1.2

1269
1270
1271

Selection of the PKCS#15 file structure or application is not within the scope of this specification and can be
managed in different ways by the devices. However, the following sequence is a recommended way to performthe selection of the PKCS#15 application:

1272
1273
1274

Step 1: The device sends a SELECT_BY_NAME command with PKCS#15 AID(A0 00 00 00 63 50 4B 43 53 2D 31 35). If the select is successful, the device can start reading
PKCS#15 files (ODF, DODF…)

1275
1276
1277
1278

Step 2: If the previous select fails, the device sends SELECT commands to select the MF and the EFdir,
and then reads the EFdir in order to locate an entry with the PKCS#15 AID. If a matching entry isfound, the device must select the PKCS#15 DF path, and then it can start reading PKCS#15 files(ODF, DODF…)File Padding

PKCS#15 Selection

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 76 / 128
1279

7.1.3

PKCS#15 DODF

1280
1281

PKCS#15 DODFs used as the entry point to access control data have an oidDO entry with an OID that must
be in the GlobalPlatform scope (under {iso(1) member-body(2) country-USA(840) globalPlatform(114283)} ).

1282

There may be two DODF files for this specification:

1283
1284

• DODF(1), for rules where the SHA-1 (deprecated) hash algorithm is used to derive DeviceAppIDs:
The registered OID for this DODF(1) is the same as the OID in previous versions of this specification:

1285
1286

{iso(1) member-body(2) country-USA(840) globalPlatform(114283) device(200) seAccessControl(1)accessControlMainFile(1)}1287This file exists for backward compatibility with ACEs that support previous versions of this specification.

1288
1289

• DODF(2), for rules where the SHA-256 hash algorithm is used to derive DeviceAppIDs:
The registered OID for this DODF(2) is:

1290
1291

{iso(1) member-body(2) country-USA(840) globalPlatform(114283) device(200) seAccessControl(1)accessControlMainFileV2(2)}

1292
1293
1294

This file is used by ACEs that support the current version of this specification. Such ACEs should firstattempt to read this SHA-256 based DODF(2), and if not found, should then attempt to read thedeprecated SHA-1 based DODF(1).

1295
1296
1297
1298

An ACE complying with v1.2 or later of this specification and using ARF MUST first search for a matching rulein DODF(2). If no matching rule is found in DODF(2), and if DODF(1) is present, it then searches for a matchingrule in DODF(1).

1299
1300

For backward compatibility with previous versions of this specification DODF(1) shall come first in the ODF(i.e. before DODF(2), if both DODFs are present).

1301
1302
1303
1304

According to [PKCS15], a DODF shall include a DataType with an oidDO entry. The DataType oidDO
entry is defined as PKCS15Object {CommonDataObjectAttributes, NULL, oidDO}. The presence ofthe oidDO entry is mandatory in a DODF.

1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321

The oidDO structure of the DODF DataType oidDO entry shall contain an id value set to one of theregistered OIDs defined above and a value that is a path structure to the respective Access Control Main File.
This path structure is defined with the following ASN.1 syntax:
Path ::= SEQUENCE {path OCTET STRING,
index INTEGER (0..65535) OPTIONAL,
length [0] INTEGER (0..65535) OPTIONAL}( WITH COMPONENTS {..., index PRESENT, length PRESENT}|WITH COMPONENTS {..., index ABSENT, length ABSENT})-- the path of the Access Control Main File (as per PKCS#15)
The CommonDataObjectAttributes structure of a DODF DataType oidDO entry may contain an
applicationName or an applicationOID. The applicationName and the applicationOID are
considered as informative in this specification. The detection of the presence of the ARF structure shall bedone by checking whether the id value of the DataType oidDO entry is one of the registered OIDs defined
above.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 77 / 128
1322

7.1.4

The Access Control Main File (ACMF)

1323

The Access Control Main File or ACMF (referenced from the DODF) has the following structure:
Table 7-1: Access Control Main File (ACMF)

1324

Identifier: 'xxxx'
File length: n bytes
Access Conditions:READ
UPDATE
DEACTIVATEACTIVATE
Bytes
1 to nStructure: transparent file
Mandatory
Update activity: low
ALW
ADM
ADM
ADM

Description
AccessControlMainFile

M/OM

Lengthn bytes

1325
1326
1327
1328

There shall be only one ACMF file per DODF. If a DODF contains several ACMF files, then the security shallbe considered compromised and the ACE shall forbid access to all the Applets for, and only for, this specific
Secure Element.

1329

The AccessControlMainFile object is related to the Secure Element that contains it.

1330
1331

The AccessControlMainFile object contains the refresh tag and the path to the rules (i.e. the path to the AccessControl Rules File); additional fields may be added in future versions of this specification.

1332

The AccessControlMainFile object is defined using the following ASN.1 syntax:

1333
1334
1335
1336
1337
1338
1339
1340

-- The access control main file object
AccessControlMainFile ::= SEQUENCE {-- the refresh tag
refreshTag OCTET STRING (SIZE(8)),}-- the path to the access control rules filerulesFile Path

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 78 / 128
1341

7.1.5

The Access Control Rules File (ACRF)

1342
1343

The rules are stored in the Access Control Rules File or ACRF (referenced from the ACMF), which has thefollowing structure:1344

Table 7-2: Access Control Rules File (ACRF)
Identifier: 'xxxx'
File length: n bytes
Access Conditions:READ
UPDATE
DEACTIVATEACTIVATE
Bytes
1 to n

List of Rules

Structure: transparent file
Mandatory
Update activity: low
ALW
ADM
ADM
ADM
Description

M/OM

Lengthn bytes

1345
1346
1347
1348

There shall be only one ACRF file per DODF. If a DODF contains several ACRF files, then the security shallbe considered compromised and the ACE shall forbid access to all the Applets for, and only for, this specific
Secure Element.

1349
1350

Each Rule object explicitly or implicitly identifies a set of Applets, and refers to the Access Control Conditions
File that describes how these applications can be accessed.

1351

The Rule object is defined using the following ASN.1 syntax:

1352
1353
1354
1355
1356
1357
1358
1359
1360
1361

-- An access control rule entry
Rule ::= SEQUENCE {-- the target of this policy entry,
target Target,}-- the path to the access control conditions file applicable-- for this target
conditionsFile Path

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 79 / 128
1362
1363

The Target object indicates whether the rule applies to one Applet (identified by its AID), or the implicitly
selected application, or all other applications (all the Applets that are not explicitly protected by a specific rule).

1364

It is defined using the following ASN.1 syntax:

1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388

-- An access control target: either a named Applet,-- the implicitly selected Applet, or all other Applets-- When defining an APDUAccessRule the access control target shallbe the AID of the Applet to be selected for APDU exchange.
-- When defining an NFCAccessRule the access control target shall be
the one referenced by the AID parameter in HCI EVT_TRANSACTION as
defined in ETSI TS 102 622 ([102 622]).
Target ::= CHOICE {-- the AID of the targeted Applet
aid [0]EXPLICIT AID,-- the (unnamed) default selected Applet-- (applies to implicitly selected Applet-- on all logical channels)
default [1]NULL,}-- identifies all other Applets-- that are not referenced in another ruleothers [2]NULL

The AID object uses the following ASN.1 syntax:-- as per ISO7816-5
AID ::= OCTET STRING

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 80 / 128
1389

7.1.6

The Access Control Conditions File (ACCF)

1390

The conditions referred to by a Rule object are stored in the Access Control Conditions File or ACCF.

1391
1392

The conditions are expressed as a list of entries, each entry containing a DeviceAppID identifying an
authorized application issuer.

1393
1394

If this file is empty, then any Rule object pointing to this file is denying all device applications access to theApplets pointed to by the Rule object.

1395
1396

If this file contains a condition without a DeviceAppID, then any Rule object pointing to this file is granting
any device application access to the Applets pointed to by the Rule object.

1397

Table 7-3: Access Control Conditions File (ACCF)
Identifier: 'xxxx'
File length: n bytes
Access Conditions:READ
UPDATE
DEACTIVATEACTIVATE
Bytes
1 to n

List of Conditions

Structure: transparent file
Mandatory
Update activity: low
ALW
ADM
ADM
ADM
Description

M/OM

Lengthn bytes

1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427

The Condition object is defined using the following ASN.1 syntax:-- A Condition entry
Condition ::= SEQUENCE {-- the DeviceAppID of the authorized device application;-- if not indicated, then the Rule pointing to this Condition-- applies to all the device applications
deviceAppID DeviceAppID OPTIONAL,
accessRules [0]AccessRules OPTIONAL}-- DeviceAppID contains one of following values:-Hash of the certificate of the device application provider.
-Unique identifier (this could be a TA UUID)-padded with 'FF' in order to provide a length of 20 bytes (in-DODF(1), or 32 bytes in DODF(2)) .
DeviceAppID ::= OCTET STRING (SIZE(20|32))-- Each type of AccessRule can occur not more than once-- in this sequence
AccessRules ::= SEQUENCE OF AccessRule
AccessRule ::=CHOICE {apduAccessRule [0]APDUAccessRule,nfcAccessRule [1]NFCAccessRule}
APDUAccessRule ::= CHOICE {apduPermission [0]APDUPermission,
apduFilters [1]APDUFilters
Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 81 / 128
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448

The size of the DeviceAppID in the Condition Object depends on the DODF that references the Condition
Object.

1449
1450
1451

• If the Condition Object is referenced from DODF(1), the size of DeviceAppID is 20 bytes. In thiscase the DeviceAppID is a SHA-1 (deprecated) hash derived from the application certificate or aunique identifier (e.g. the TA UUID) padded with 'FF'.

1452
1453
1454

• If the Condition Object is referenced from DODF(2), the size of DeviceAppID is 32 bytes. In thiscase the DeviceAppID is a SHA-256 hash derived from the application certificate or a unique
identifier (e.g. the TA UUID) padded with 'FF'.

}-- TRUE means APDU access is allowed,-- FALSE means APDU access is not allowed
APDUPermission ::= BOOLEAN-- Each APDU filter is a 8 byte octet string:-- 4-byte header and 4-byte mask
APDUFilters ::= SEQUENCE OF APDUFilter
APDUFilter ::= OCTET STRING (SIZE(8))
NFCAccessRule ::= CHOICE {nfcPermission [0]NFCPermission}-- TRUE means NFC event is allowed,-- FALSE means NFC event is not allowed
NFCPermission ::= BOOLEAN

1455

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 82 / 128
1456

Undefined Attributes in Condition Object

1457
1458
1459
1460

The Condition object includes the optional attribute AccessRules, which includes optional attributes
APDUAccessRule and NFCAccessRule. If, when retrieving rules from the Access Rule Files (ARF), the
ARA-M or the ACE determines that one of these attributes is not defined, it shall interpret the missing attributeas specified in Table 7-4.

1461

Table 7-4: Required Interpretation If Undefined Attribute in Condition Object

1

Policy Being Checked,
for a Specific AID or
for Other AIDs

Attributes in Condition Object
Specified in ARF

Required Interpretation

APDU permission policy

AccessRules attribute not present orAccessRules attribute present but empty

APDU permission ALWAYS
allowed policy

AccessRules attribute present• For v1.0 of thisspecification, APDU
permission ALWAYS
allowed policy

2• No APDUAccessRule attribute• NFCAccessRule attribute present• For v1.1 (or newer) of thisspecification, APDU
permission NEVER allowed
policy3

NFC event policy

AccessRules attribute not present orAccessRules attribute present but empty

NFC event ALWAYS allowed
policyAccessRules attribute present• No NFCAccessRule attribute• APDUAccessRule attribute present
4o APDUAccessRule set to
ALWAYS or contains APDU filter

NFC event ALWAYS allowed
policy5o APDUAccessRule set to NEVER

NFC event NEVER allowed
policy1462
1463

Notes:

1464
1465• The AccessRules attribute is set as optional to ensure backward compatibility with the former
implementation of the ARF.

1466
1467
1468
1469

• Management of missing attributes was clarified in this release to ensure consistency between ARA
and ARF behaviors. As a result, different versions of this specification specify different behavior whenthe APDUAccessRule attribute is not present but the NFCAccessRule attribute is present, as shown inrow 2 in the table above.

1470
1471

To avoid any interoperability issue, it is strongly recommended that the attributes for both APDU
permission and NFC event are defined explicitly when setting a rule.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 83 / 128
1472

7.2 ASN.1 Definition

1473
1474

This section includes all ASN.1 types, values, and information object class definitions contained in thisdocument, in the form of the ASN.1:

1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522

module PKCS-15
GP ACP { iso(1) member-body(2) country-USA(840)globalPlatform(114283) device(200) seAccessControl(1)accessControlMainFile(1) }DEFINITIONS IMPLICIT TAGS ::=BEGIN
AID ::= OCTET STRING
DeviceAppID ::= OCTET STRING (SIZE(20|32))
APDUPermission ::= BOOLEAN
NFCPermission ::= BOOLEAN
APDUFilter ::= OCTET STRING (SIZE(8))
AccessControlMainFile ::= SEQUENCE {refreshTag OCTET STRING (SIZE(8)),
rulesFile Path}
Target ::= CHOICE {aid [0]EXPLICIT AID,
default [1]NULL,
others [2]NULL}
Rule ::= SEQUENCE {target Target,
conditionsFile Path}
Condition ::= SEQUENCE {deviceAppID DeviceAppID OPTIONAL,
accessRules [0]AccessRules OPTIONAL}
AccessRules ::= SEQUENCE OF AccessRule
AccessRule ::=CHOICE {apduAccessRule [0]APDUAccessRule,nfcAccessRule [1]NFCAccessRule}
Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 84 / 128
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535

APDUAccessRule ::= CHOICE {apduPermission [0]APDUPermission,
apduFilters [1]APDUFilter}
APDUFilters ::= SEQUENCE OF APDUFilter
NFCAccessRule ::= CHOICE {nfcPermission [0]NFCPermission}
END

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 85 / 128
1536

7.3 File System Validity

1537
1538

When the device is determining whether access control rules are available in the file system of the Secure
Element, different cases may occur:

1539

The File System is correctly provisioned when either of the following is true:

1540
1541

• There is a PKCS#15 application (selectable using the standard AID) in the Secure Element and the
OID of this access control mechanism is specified in a DODF provisioning file.

1542
1543

• If the Secure Element is a UICC, a PKCS#15 application/file structure is referenced in the Secure
Element EFdir and the OID of this access control mechanism is specified in a DODF provisioning file.

1544

The File System has no access rules (as described in this specification) when any of the following is true:

1545
1546

• There is no PKCS#15 application (selectable using the standard AID) and if the Secure Element is a
UICC, there is no EFdir file.

1547
1548

• There is no PKCS#15 application (selectable using the standard AID) and if the Secure Element is a
UICC, no PKCS#15 application/file structure is referenced in its EFdir.

1549
1550

• There is a PKCS#15 provisioning in the Secure Element (either an application or a file structure) but
none of the OIDs of the access control mechanism is referenced in a valid DODF file.

1551
1552

All other cases shall be treated as parsing error cases, which should lead to denying access to the whole
Secure Element.

1553
1554

7.4 ARF Parsing

1555
1556

Errors may occur when parsing the access control mechanism structure (ACMF, ACRF, ACCF files) after thereading of the OID in the DODF:

1557
1558

• If the ACMF file cannot be found or cannot be read or its content is invalid, then the device SHALL bedenied any access to these Applets.

1559
1560

• If the ACRF file cannot be found or cannot be read or its content is invalid, then the device SHALL bedenied any access to these Applets.

1561
1562

• If one ACCF file referenced in the ACRF file cannot be found or cannot be read or its content isinvalid, then:

1563
1564
1565

o Rules applied to Secure Elements application(s) identified by their AIDs and using this ACCF,
access SHALL be denied. Other rules referenced in the ACRF and applied to other Applet(s)remain valid and SHALL be used.

1566
1567

o Rules applied to ALL Secure Elements applications and using this ACCF SHALL be discarded.
Other rules referenced in the ACRF remain valid and SHALL be used.

1568

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 86 / 128
1569

Annex ASUMMARY OF DATA OBJECT NESTING

1570
1571
1572

This annex summarizes the nesting of data objects in the GET DATA command and response, and the
STORE DATA command and response. For detailed information about the messages and data objects, see
Chapters 4 through 6.

1573
1574

Where a data object name is shown in bold blue letters, the full nesting follows. (Otherwise, the full nesting isshown elsewhere in this annex.)1575

Note: The following data objects were renamed in v1.1:

1576• Response-ALL-AR-DO => Response-ALL-REF-AR-DO

1577• Response-RefreshTag-DO => Response-Refresh-Tag-DO

1578• Command-Store-AR-DO => Command-Store-REF-AR-DO

1579• Command-Delete-AR-DO => Command-Delete

1580• Command-UpdateRefreshTag-DO => Command-Update-Refresh-Tag-DO

1581• Command-Register-ClientAIDs-DO => Command-Register-Client-AIDs-DO

1582• Command-Get-AR-DO => Command-Get

1583• Command-GetAll-AR-DO => Command-Get-All

1584• Command-Get-ClientAIDs-DO => Command-Get-Client-AIDs-DO

1585• Command-GetNext-AR-DO => Command-Get-Next
Table A-1: Data Object Nesting in GET DATA Command

1586
Command

P1 P2

Data

GET DATA[All]

absent[Specific]

REF-DOValue

AID-REF-DO | DeviceAppID-REF-DO(deprecated)

AID-REF-DO

AID
Empty

DeviceAppID-REF-DO

DeviceAppID(see section 3.1)
Empty

[Refresh tag]absent[Next]

absent[Config]

Device-ConfigDO

Device-InterfaceVersion-DO

Version1587

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 87 / 128
Table A-2: Data Object Nesting in GET DATA Response

1588
P1 P2 ofGET DATA
Command

GET DATA Response Includes[All]

Response-ALL-REF-AR-DO
Empty

REF-AR-DO1 | ... | REF-AR-DOx, first bytes
REF-DO | AR-DO[Specific](deprecated)

Response-AR-DO
Empty

AR-DO, first bytes
APDU-AR-DO'00' (NEVER)'01' (ALWAYS)

APDU filter 1 | ... | APDU filter n
4-byte APDU filter header | 4-byte APDU
filter mask

NFC-AR-DO'00' (NEVER)'01' (ALWAYS)

APDU-AR-DO | NFC-AR-DO[Refresh tag]

Response-Refresh-Tag-DO
RefreshTag (8-byte random number)[Next]
next bytes of REF-AR-DO
next bytes of AR-DO[Config]

Response-ARAM-Config-DO
ARAM-Config-DO
Device-Interface-Version-DO

1589

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 88 / 128
Table A-3: Data Object Nesting in STORE DATA Command

1590
Command

Data

Value

STORE DATA

Command-Store-REF-AR-DO

REF-AR-DO

Command-Delete

AID-REF-DO
REF-DOREF-AR-DO
Empty

Command-Update-Refresh-Tag-DO

Empty

Command-Register-Client-AIDsDO

AID-REF-DO1 | … | AID-REF-DOx, first bytes(deprecated)
AID-REF-DO

Command-Get

Empty

AID-REF-DO
Command-Get-All

Empty

Command-Get-Client-AIDs-DO

Empty

Command-Get-Next

Empty

Command-Get-Device-Config-DO

Empty

1591
Table A-4: Data Object Nesting in STORE DATA Response

1592

STORE DATA Command

STORE DATA Response Includes(Command-Get)

Response-ALL-REF-AR-DO(Command-Get-All)

Response-ALL-REF-AR-DO(Command-Get-Client-AIDs-DO)

Response-ARAC-AID-DO
Empty

AID-REF-DO1 | ... | AID-REF-DOx, first bytes(Command-Get-Next)
Next bytes of REF-AR-DO
Next bytes of AID-REF-DO(Command-Get-Device-ConfigDO)

Response-Device-Config-DO
Empty

Device-Config-DO
Device-Config-DO1 |…| Device-Config-DOx
1593

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 89 / 128
1594

Annex BDATA OBJECT TAGS

1595

This annex lists the tags assigned to all data objects defined in this specification.
Table B-1: Data Object Tags

1596
Tag

Data Object'4F'

AID-REF-DO

Specific application or all Applets not covered by aspecific rule

'C0'

AID-REF-DO

Implicitly selected application (all channels)'C1'

DeviceAppID-REF-DO'D0'

APDU-AR-DO'D1'

NFC-AR-DO'DF 20'

Response-Refresh-Tag-DO'DF 21'

Response-ARAM-Config-DO'E1'

REF-DO'E2'

REF-AR-DO

'E3'

AR-DO

'E4'

Device-Config-DO'E5'

ARAM-Config-DO'E6'

Device-Interface-Version-DO'E7'

Block-DO'F0'

Command-Store-REF-AR-DO'F1'

Command-Delete'F2'

Command-Update-Refresh-Tag-DO'F3'

Command-Get'F4'Command-Get-All'F5'Command-Get-Next'F6'

Command-Get-Client-AIDs-DO'F7'

Command-Register-Client-AIDs-DO'F8'

Command-Get-Device-Config-DO'FF 40'

Response-ALL-REF-AR-DO'FF 50'

Response-AR-DO'FF 70'

Response-ARAC-AID-DO'FF 7F'

Response-Device-Config-DO

1597

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 90 / 128
1598

Annex C

EXAMPLE OF ACCESS CONTROL DATA

1599
1600
1601

For the sake of simplicity, in the following examples, AIDs are all in the form of A0 00 00 01 51 xx, and theDeviceAppID of the REE device applications (certificate hashes) are fake values like 111…, 222…, 333…,
etc.

1602
1603
1604

Note: All these examples use a DeviceAppID based on a hash value. When using a DeviceAppID basedon a Unique Identifier, the hash values in these examples shall be replaced by the unique identifier paddedwith 'FF'.

1605
1606

C.1 First Example

1607

In this example, the setup is:

1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638

AID1 = A0 00 00 01 51 01

 access denied for all apps

 conditions 1

AID2 = A0 00 00 01 51 02

 access allowed for 1 app (hash1)

 conditions 2

AID3 = A0 00 00 01 51 03

 access allowed for 1 app (hash1)

 conditions 2

Any other AIDs

 access allowed for all apps

 conditions 3

Here’s a summary of the PKCS#15 file system personalization:
Hierarchical view (file system):MF (3F00)|-EF DIR (2F00)||-DF PKCS-15 (7F50)|-ODF (5031)|-DODF (5207)|-EF ACMain (4200)|-EF ACRules (4300)|-EF ACConditions1 (4310)|-EF ACConditions2 (4311)|-EF ACConditions3 (4312)--> reference DF PKCS-15--> reference DODF--> reference EF ACMain--> reference EF ACRules--> reference EF ACConditions...

Hierarchical view (PKCS#15 application):
PKCS#15 application (AID: A0 00 00 00 63 50 4B 43 53 2D 31 35)|-ODF (5031)--> reference DODF|-DODF (5207)--> reference EF ACMain|-EF ACMain (4200)--> reference EF ACRules|-EF ACRules (4300)--> reference EF ACConditions...
|-EF ACConditions1 (4310)|-EF ACConditions2 (4311)|-EF ACConditions3 (4312)

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 91 / 128
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690

EF DIR: 3F00/2F00
Based on this ASN.1 syntax:
DIRRecord ::= [APPLICATION 1] SEQUENCE {aid [APPLICATION 15] OCTET STRING,
label [APPLICATION 16] UTF8String OPTIONAL,
path [APPLICATION 17] OCTET STRING,
ddo [APPLICATION 19] DDO OPTIONAL}
aid PKCS-15 = A0 00 00 00 63 50 4B 43 53 2D 31 35
label = "PROVISIONING" = 50 52 4F 56 49 53 49 4F 4E 49 4E 47
path = 3F00/7F50
binary coding:
61 22 4F 0C A0 00 00 00 63 50 4B 43 53 2D 31 35 50 0C 50 52 4F 56 49 53 49
4F 4E 49 4E 47 51 04 3F 00 7F 50
ODF: 3F00/7F50/5031
References file 5207.
Binary coding
A7 06 30 04 04 02 52 07
DODF: 3F00/7F50/5207
OID GlobalPlatform ::= {iso(1) member-body(2) country-USA(840)globalPlatform(114283) device(200) seAccessControl(1)accessControlMainFile(1)}http://www.oid-info.com/get/1.2.840.114283==> HEX encoding = 2A 86 48 86 FC 6B 81 48 01 01
application name = "GP SE Acc Ctl" (example)
path to EF ACMain = 4200
binary coding:A1 29 30 00 30 0F 0C 0D 47 50 20 53 45 20 41 63 63 20 43 74 6C A1 14 30 12
06 0A 2A 86 48 86 FC 6B 81 48 01 01 30 04 04 02 42 00
EF ACMain: 3F00/7F50/4200
Refresh tag value is 01 02 03 04 05 06 07 08
path to EF ACRules = 4300
binary coding:
30 10 04 08 01 02 03 04 05 06 07 08 30 04 04 02 43 00

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 92 / 128
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722

EF ACRules: 3F00/7F50/4300
AID1 --> EFConditions 4310 --> access denied for all apps
AID2 --> EFConditions 4311 --> access allowed for 1 app (hash1)
AID3 --> EFConditions 4311 --> access allowed for 1 app (hash1)*--> EFConditions 4312 --> access allowed for all apps
binary coding:
30 10 A0 08 04 06 A0 00 00 01 51 01
30 10 A0 08 04 06 A0 00 00 01 51 02
30 10 A0 08 04 06 A0 00 00 01 51 03
30 08 82 00

30 04 04 02 43 10
30 04 04 02 43 11
30 04 04 02 43 11
30 04 04 02 43 12

EF ACConditions1: 3F00/7F50/4310 (access denied for all apps)
binary coding:(empty file)EF ACConditions2: 3F00/7F50/4311 (access allowed for 1 app)Hash1 has the value 111…
binary coding:
30 16 04 14 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11
EF ACConditions3: 3F00/7F50/4312 (access allowed for all apps)
binary coding:
30 00

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 93 / 128
1723

C.2 Second Example

1724

In this example, the setup is:

1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764

AID1 = A0 00 00 01 51 01

 access allowed for all apps

 conditions 1

AID2 = A0 00 00 01 51 02

 access allowed for 1 app (hash1)

 conditions 2

AID3 = A0 00 00 01 51 03

 access allowed for 3 apps (h1, h2, h3)

 conditions 3

AID4 = A0 00 00 01 51 04

 access denied for all apps

 conditions 4

AID5 = A0 00 00 01 51 05

 access denied for all apps

 conditions 4

Any other AIDs

 access denied for all apps

 conditions 4

Here’s a summary of the PKCS#15 file system personalization:
Hierarchical view (file system):MF (3F00)|-EF DIR (2F00)||-DF PKCS-15 (7F50)|-ODF (5031)|-DODF (5207)|-EF ACMain (4200)|-EF ACRules (4300)|-EF ACConditions1 (4310)|-EF ACConditions2 (4311)|-EF ACConditions3 (4312)|-EF ACConditions4 (4313)--> reference DF PKCS-15--> reference DODF--> reference EF ACMain--> reference EF ACRules--> reference EF ACConditions...

Hierarchical view (PKCS#15 application):
PKCS#15 application (AID: A0 00 00 00 63 50 4B 43 53 2D 31 35)|-ODF (5031)--> reference DODF|-DODF (5207)--> reference EF ACMain|-EF ACMain (4200)--> reference EF ACRules|-EF ACRules (4300)--> reference EF ACConditions...
|-EF ACConditions1 (4310)|-EF ACConditions2 (4311)|-EF ACConditions3 (4312)|-EF ACConditions4 (4313)
EF DIR: 3F00/2F00
Based on this ASN.1 syntax:
DIRRecord ::= [APPLICATION 1] SEQUENCE {aid [APPLICATION 15] OCTET STRING,
label [APPLICATION 16] UTF8String OPTIONAL,
path [APPLICATION 17] OCTET STRING,
ddo [APPLICATION 19] DDO OPTIONAL
Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 94 / 128
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816

}
aid PKCS-15 = A0 00 00 00 63 50 4B 43 53 2D 31 35
label = "PROVISIONING" = 50 52 4F 56 49 53 49 4F 4E 49 4E 47
path = 3F00/7F50
binary coding:
61 22 4F 0C A0 00 00 00 63 50 4B 43 53 2D 31 35 50 0C 50 52 4F 56 49 53 49
4F 4E 49 4E 47 51 04 3F 00 7F 50
ODF: 3F00/7F50/5031
References file 5207.
binary coding:
A7 06 30 04 04 02 52 07
DODF: 3F00/7F50/5207
OID GlobalPlatform ::= {iso(1) member-body(2) country-USA(840)globalPlatform(114283) device(200) seAccessControl(1)accessControlMainFile(1)}http://www.oid-info.com/get/1.2.840.114283==> HEX encoding = 2A 86 48 86 FC 6B 81 48 01 01
application name = "GP SE Acc Ctl" (example)
path to EF ACMain = 4200
binary coding:A1 29 30 00 30 0F 0C 0D 47 50 20 53 45 20 41 63 63 20 43 74 6C A1 14 30 12
06 0A 2A 86 48 86 FC 6B 81 48 01 01 30 04 04 02 42 00
EF ACMain: 3F00/7F50/4200
Refresh tag value is 01 02 03 04 05 06 07 08
path to EF ACRules = 4300
binary coding:
30 10 04 08 01 02 03 04 05 06 07 08 30 04 04 02 43 00
EF ACRules: 3F00/7F50/4300
AID1 --> EFConditions 4310 --> access allowed for all apps
AID2 --> EFConditions 4311 --> access allowed for 1 app (h1)
AID3 --> EFConditions 4312 --> access allowed for 3 apps (h1, h2, h3)
AID4 --> EFConditions 4313 --> access denied for all apps
AID5 --> EFConditions 4313 --> access denied for all apps*--> EFConditions 4313 --> access denied for all apps
Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 95 / 128
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850

binary coding:
30 10 A0 08 04 06 A0 00 00 01 51 01
30 10 A0 08 04 06 A0 00 00 01 51 02
30 10 A0 08 04 06 A0 00 00 01 51 03
30 10 A0 08 04 06 A0 00 00 01 51 04
30 10 A0 08 04 06 A0 00 00 01 51 05
30 08 82 00

30 04 04 02 43 10
30 04 04 02 43 11
30 04 04 02 43 12
30 04 04 02 43 13
30 04 04 02 43 13
30 04 04 02 43 13

EF ACConditions: 3F00/7F50/4310 (access allowed for all apps)
binary coding:
30 00
EF ACConditions: 3F00/7F50/4311 (access allowed for 1 app)binary coding:
30 16 04 14 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11
EF ACConditions: 3F00/7F50/4312 (access allowed for 3 apps)
binary coding:
30 16 04 14 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 1130 16 04 14 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22
30 16 04 14 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33
EF ACConditions: 3F00/7F50/4313 (access denied for all apps)
binary coding:(empty file)

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 96 / 128
1851

C.3 Third Example

1852

In this example, the setup is:

1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895

Default AID

 access allowed for 1 app (hash0) conditions 1

AID1 = A0 00 00 01 51 01

 access allowed for 1 app (hash1)

 conditions 2

AID2 = A0 00 00 01 51 02

 access allowed for 1 app (hash2) + APDU Filter conditions 3

AID3 = A0 00 00 01 51 03

 access allowed for all apps

 conditions 4

Here’s a summary of the PKCS#15 file system personalization:
Hierarchical view (file system):MF (3F00)|-EF DIR (2F00)||-DF PKCS-15 (7F50)|-ODF (5031)|-DODF (5207)|-EF ACMain (4200)|-EF ACRules (4300)|-EF ACConditions1 (4380)|-EF ACConditions2 (4381)|-EF ACConditions3 (4382)|-EF ACConditions4 (4383)--> reference DF PKCS-15--> reference DODF--> reference EF ACMain--> reference EF ACRules--> reference EF ACConditions...

Hierarchical view (PKCS#15 application):
PKCS#15 application (AID: A0 00 00 00 63 50 4B 43 53 2D 31 35)|-ODF (5031)--> reference DODF|-DODF (5207)--> reference EF ACMain|-EF ACMain (4200)--> reference EF ACRules|-EF ACRules (4300)--> reference EF ACConditions...
|-EF ACConditions1 (4380)|-EF ACConditions2 (4381)|-EF ACConditions3 (4382)|-EF ACConditions4 (4383)
EF DIR: 3F00/2F00
Based on this ASN.1 syntax:
DIRRecord ::= [APPLICATION 1] SEQUENCE {aid [APPLICATION 15] OCTET STRING,
label [APPLICATION 16] UTF8String OPTIONAL,
path [APPLICATION 17] OCTET STRING,
ddo [APPLICATION 19] DDO OPTIONAL}
aid PKCS-15 = A0 00 00 00 63 50 4B 43 53 2D 31 35
Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 97 / 128
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947

label = "PROVISIONING" = 50 52 4F 56 49 53 49 4F 4E 49 4E 47
path = 3F00/7F50
binary coding:
61 22 4F 0C A0 00 00 00 63 50 4B 43 53 2D 31 35 50 0C 50 52 4F 56 49 53 49
4F 4E 49 4E 47 51 04 3F 00 7F 50
ODF: 3F00/7F50/5031
References file 5207.
binary coding:
A7 06 30 04 04 02 52 07
DODF: 3F00/7F50/5207
OID GlobalPlatform ::= {iso(1) member-body(2) country-USA(840)globalPlatform(114283) device(200) seAccessControl(1)accessControlMainFile(1)}http://www.oid-info.com/get/1.2.840.114283==> HEX encoding = 2A 86 48 86 FC 6B 81 48 01 01
application name = "GP SE Acc Ctl" (example)
path to EF ACMain = 4200
binary coding:A1 29 30 00 30 0F 0C 0D 47 50 20 53 45 20 41 63 63 20 43 74 6C A1 14 30 12
06 0A 2A 86 48 86 FC 6B 81 48 01 01 30 04 04 02 42 00
EF ACMain: 3F00/7F50/4200
Refresh tag value is 01 02 03 04 05 06 07 08
path to EF ACRules = 4300
binary coding:
30 10 04 08 01 02 03 04 05 06 07 08 30 04 04 02 43 00
EF ACRules: 3F00/7F50/4300
Default AID --> EFConditions 4380 --> access allowed for 1 app (h0)
AID1--> EFConditions 4381 --> access allowed for 1 app (h1)
AID2--> EFConditions 4382 --> access allowed for 1 app (h2)...
AID3--> EFConditions 4383 --> access allowed for all apps
binary coding:
30 08 81 00
30 10 A0 08 04 06 A0 00 00 01 51 01
30 10 A0 08 04 06 A0 00 00 01 51 02
Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

30 04 04 02 43 80
30 04 04 02 43 81
30 04 04 02 43 82

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 98 / 128
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981

30 10

A0 08 04 06 A0 00 00 01 51 03

30 04 04 02 43 83

EF ACConditions: 3F00/7F50/4380 (access allowed for 1 app)
Hash0 has the value 000…
binary coding:
30 16 04 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
EF ACConditions: 3F00/7F50/4381 (access allowed for 1 app)Hash1 has the value 111…
binary coding:
30 16 04 14 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11
EF ACConditions: 3F00/7F50/4382 (access allowed for 1 app)Hash2 has the value 222…
APDU filter : 80 F2 00 00 / FF FF FF FF + 80 CA 00 00 / FF FF 00 00
NFC event : NEVER
binary coding:
30 35 04 14 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 A0
1D A0 16 A1 14 04 08 80 F2 00 00 FF FF FF FF 04 08 80 CA 00 00 FF FF 00 00
A1 03 80 01 00
EF ACConditions: 3F00/7F50/4383 (access allowed for all apps)
binary coding:
30 00

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 99 / 128
1982

C.4 Fourth Example

1983

The setup is in this example is equal to the Third Example but with both DODFs provisioned:

1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026

Default AID

 access allowed for 1 app (hash0, hash2-0)

 conditions 1

AID1 = A0 00 00 01 51 01

 access allowed for 1 app (hash1, hash2-1)

 conditions 2

AID2 = A0 00 00 01 51 02

 access allowed for 1 app (hash2, hash2-2) + APDU Filter  conditions 3

AID3 = A0 00 00 01 51 03

 access allowed for all apps

 conditions 4

Here’s a summary of the PKCS#15 file system personalization:
Hierarchical view (file system):MF (3F00)|-EF DIR (2F00)||-DF PKCS-15 (7F50)|-ODF (5031)|-DODF(1) (5207)|-EF ACMain(1) (4200)|-EF ACRules(1) (4300)|-EF ACConditions1(1) (4380)|-EF ACConditions2(1) (4381)|-EF ACConditions3(1) (4382)|-EF ACConditions4(1) (4383)|-DODF(2) (5217)|-EF ACMain(2) (4210)|-EF ACRules(2) (4310)|-EF ACConditions1(2) (4390)|-EF ACConditions2(2) (4391)|-EF ACConditions3(2) (4392)|-EF ACConditions4(2) (4393)--> reference DF PKCS-15--> reference DODF(1), DODF(2)--> reference EF ACMain(1)--> reference EF ACRules(1)--> reference EF ACConditions(1)...

--> reference EF ACMain(2)--> reference EF ACRules(2)--> reference EF ACConditions(2)...

Hierarchical view (PKCS#15 application):
PKCS#15 application (AID: A0 00 00 00 63 50 4B 43 53 2D 31 35)|-ODF (5031)--> reference DODF(1), DODF(2)|-DODF(1) (5207)--> reference EF ACMain(1)|-EF ACMain(1) (4200)--> reference EF ACRules(1)|-EF ACRules(1) (4300)--> reference EF ACConditions(1)...
|-EF ACConditions1(1) (4380)|-EF ACConditions2(1) (4381)|-EF ACConditions3(1) (4382)|-EF ACConditions4(1) (4383)|-DODF(2) (5217)--> reference EF ACMain(2)|-EF ACMain(2) (4210)--> reference EF ACRules(2)|-EF ACRules(2) (4310)--> reference EF ACConditions(2)...
|-EF ACConditions1(2) (4390)|-EF ACConditions2(2) (4391)|-EF ACConditions3(2) (4392)|-EF ACConditions4(2) (4393)
Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 100 / 128
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078

EF DIR: 3F00/2F00
Based on this ASN.1 syntax:
DIRRecord ::= [APPLICATION 1] SEQUENCE {aid [APPLICATION 15] OCTET STRING,
label [APPLICATION 16] UTF8String OPTIONAL,
path [APPLICATION 17] OCTET STRING,
ddo [APPLICATION 19] DDO OPTIONAL}
aid PKCS-15 = A0 00 00 00 63 50 4B 43 53 2D 31 35
label = "PROVISIONING" = 50 52 4F 56 49 53 49 4F 4E 49 4E 47
path = 3F00/7F50
binary coding:
61 22 4F 0C A0 00 00 00 63 50 4B 43 53 2D 31 35 50 0C 50 52 4F 56 49 53 49
4F 4E 49 4E 47 51 04 3F 00 7F 50
ODF: 3F00/7F50/5031
References files 5207 and 5217.
binary coding:
A7 06 30 04 04 02 52 07
A7 06 30 04 04 02 52 17
DODF(1): 3F00/7F50/5207
OID GlobalPlatform ::= {iso(1) member-body(2) country-USA(840)globalPlatform(114283) device(200) seAccessControl(1)accessControlMainFile(1)}http://www.oid-info.com/get/1.2.840.114283==> HEX encoding = 2A 86 48 86 FC 6B 81 48 01 01
application name = "GP SE Acc Ctl" (example)
path to EF ACMain(1) = 4200
binary coding:A1 29 30 00 30 0F 0C 0D 47 50 20 53 45 20 41 63 63 20 43 74 6C A1 14 30 12
06 0A 2A 86 48 86 FC 6B 81 48 01 01 30 04 04 02 42 00
EF ACMain(1): 3F00/7F50/4200
Refresh tag value is 01 02 03 04 05 06 07 08
path to EF ACRules(1) = 4300
binary coding:
30 10 04 08 01 02 03 04 05 06 07 08 30 04 04 02 43 00
Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 101 / 128
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130

EF ACRules(1): 3F00/7F50/4300
Default AID --> EFConditions1(1) 4380 --> access allowed for 1 app (h0)
AID1--> EFConditions2(1) 4381 --> access allowed for 1 app (h1)
AID2--> EFConditions3(1) 4382 --> access allowed for 1 app (h2)...
AID3--> EFConditions4(1) 4383 --> access allowed for all apps
binary coding:
30 08 81 00
30 10 A0 08 04 06 A0 00 00 01 51 01
30 10 A0 08 04 06 A0 00 00 01 51 02
30 10 A0 08 04 06 A0 00 00 01 51 03

30 04 04 02 43 80
30 04 04 02 43 81
30 04 04 02 43 82
30 04 04 02 43 83

EF ACConditions1(1): 3F00/7F50/4380 (access allowed for 1 app)
Hash0 has the value 000…
binary coding:
30 16 04 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
EF ACConditions2(1): 3F00/7F50/4381 (access allowed for 1 app)Hash1 has the value 111…
binary coding:
30 16 04 14 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11
EF ACConditions3(1): 3F00/7F50/4382 (access allowed for 1 app)Hash2 has the value 222…
APDU filter : 80 F2 00 00 / FF FF FF FF + 80 CA 00 00 / FF FF 00 00
NFC event : NEVER
binary coding:
30 35 04 14 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 A0
1D A0 16 A1 14 04 08 80 F2 00 00 FF FF FF FF 04 08 80 CA 00 00 FF FF 00 00
A1 03 80 01 00
EF ACConditions4(1): 3F00/7F50/4383 (access allowed for all apps)
binary coding:
30 00

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 102 / 128
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182

DODF(2): 3F00/7F50/5217
OID GlobalPlatform ::= {iso(1) member-body(2) country-USA(840)globalPlatform(114283) device(200) seAccessControl(1)accessControlMainFileV2 (2)}http://www.oid-info.com/get/1.2.840.114283==> HEX encoding = 2A 86 48 86 FC 6B 81 48 01 02
application name = "GP SE Acc Ctl" (example)
path to EF ACMain(2) = 4210
binary coding:A1 29 30 00 30 0F 0C 0D 47 50 20 53 45 20 41 63 63 20 43 74 6C A1 14 30 12
06 0A 2A 86 48 86 FC 6B 81 48 01 02 30 04 04 02 42 10
EF ACMain(2): 3F00/7F50/4210
Refresh tag value is 01 02 03 04 05 06 07 08
path to EF ACRules(2) = 4310
binary coding:
30 10 04 08 01 02 03 04 05 06 07 08 30 04 04 02 43 10
EF ACRules(2): 3F00/7F50/4310
Default AID --> EFConditions1(2) 4390 --> acc. allowed for 1 app (h2-0)
AID1--> EFConditions2(2) 4391 --> acc. allowed for 1 app (h2-1)
AID2--> EFConditions3(2) 4392 --> acc. allowed for 1 app (h2-2)...
AID3--> EFConditions4(2) 4393 --> access allowed for all apps
binary coding:
30 08 81 00
30 10 A0 08 04 06 A0 00 00 01 51 01
30 10 A0 08 04 06 A0 00 00 01 51 02
30 10 A0 08 04 06 A0 00 00 01 51 03

30 04 04 02 43 90
30 04 04 02 43 91
30 04 04 02 43 92
30 04 04 02 43 93

EF ACConditions1(2): 3F00/7F50/4390 (access allowed for 1 app)Hash2-0 has the value 000…
binary coding:
30 16 04 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00
EF ACConditions2(2): 3F00/7F50/4391 (access allowed for 1 app)Hash2-1 has the value 111…
Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 103 / 128
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204

binary coding:
30 16 04 20 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11
11 11 11 11 11 11 11 11 11 11 11
EF ACConditions3(2): 3F00/7F50/4392 (access allowed for 1 app)Hash2 has the value 222…
APDU filter : 80 F2 00 00 / FF FF FF FF + 80 CA 00 00 / FF FF 00 00
NFC event : NEVER
binary coding:
30 35 04 20 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22
22 22 22 22 22 22 22 22 22 22 22 A0 1D A0 16 A1 14 04 08 80 F2 00 00 FF FF
FF FF 04 08 80 CA 00 00 FF FF 00 00 A1 03 80 01 00
EF ACConditions4(2): 3F00/7F50/4393 (access allowed for all apps)
binary coding:
30 00

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 104 / 128
2205

Annex DRULES CONFLICT MANAGEMENT EXAMPLES

2206

Table D-2 shows some examples of how the ACE shall apply combinations of the rules provided by the ARA-M.

2207

Some examples in Table D-2 show multiple rules with the same target (AID, DeviceAppID).

2208
2209
2210
2211

There will never be multiple rules for the same target in the same ARA: If a Command-Store-REF-AR-DO is
submitted with a target that exactly matches the target of a rule that already exists in the current ARA, theCommand-Store-REF-AR-DO will merge or overwrite the preceding stored rule, as described in
section 5.1.1.1.

2212
2213
2214

Similarly, if a Command-Store-REF-AR-DO is submitted with a target that exactly matches the target of arule that already exists in an ARA other than the current ARA, the Command-Store-REF-AR-DO will not store
the rule, but instead will return error SW '6A 89', as described in section 5.1.1.1.

2215(A partial target match does not prevent a rule from being stored, as discussed in section 5.1.1.1.)

2216
2217

Nonetheless, rules with the same target can exist in different ARAs (possible scenarios are discussed in
section 3.4) and conflict resolution occurs when the rules are fetched.

2218

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 105 / 128
Table D-1: Terms Used in Table D-2

2219
Term

Meaning in Table D-2

Rxx

A certain rule defined in the Secure Element, regardless of where it isstored.

DID#yDeviceAppID contains one of following values:• Hash of the certificate of the Application Provider• Unique identifier (this could be a TA UUID) padded with 'FF' in order toprovide a length of 20 (or 32) bytes

DID#x.y

A certain certificate (CER) within a certificate chain of a REE application
when hash is used as the DeviceAppID.

DID#y*

A certain certificate or any child certificate thereof; applies only if
certificate chains are used.

All

Indicates a generic reference which applies to all device applications
which are not covered by a specific reference.

Ref

Reference to an access rule (AR); either one that refers to a specific
DeviceAppID (DeviceAppID-Ref) or the generic reference “for all
device applications” (ALL-Ref).

(Ref)-AR-APDU-ALWAYS

The access rule containing the “APDU always allowed” policy for a device
application.

(Ref)-AR-APDU-NEVER

The access rule containing the “APDU never allowed” policy for a device
application.

(Ref)-AR-APDU-Filter

The access rule containing the APDU filter for a device application.

(Ref)-AR-NFC-ALWAYS

The access rule containing the “NFC event always allowed” policy for adevice application.

(Ref)-AR-NFC-NEVER

The access rule containing the “NFC event never allowed” policy for adevice application.

NOT EXIST

Access rules for the Applet are not defined. This means the access rules
contain no reference – neither “aid”, “default”, nor “others” – to thecorresponding Applet. Thus, no access conditions are assigned to thisApplet and all access is denied.

2220

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 106 / 128
Table D-2: Rules Conflict Management

2221

1

Applet #1

Applet #2

Other AIDs
(generic rule)R0: (DID#1-Ref)-AR-APDUALWAYSNOT EXISTNOT EXIST

Access Result for the Applets• Device applications signed with DID#1* are granted access toApplet #1.
• Access to any other Applet is denied.

2

R0: (DID#1-Ref)-AR-APDUALWAYSNOT EXISTNOT EXIST• Device applications signed with DID#1* or with DID#2* aregranted access to Applet #1.
• Access to any other Applet is denied.

R1: (DID#2-Ref)-AR-APDUALWAYS
3

R0: (DID#1-Ref)-AR-APDUNEVERNOT EXISTNOT EXIST• Access to any Applet is denied.

4

R0: (DID#1-Ref)-AR-APDUALWAYSNOT EXISTNOT EXIST• Access to Applet #1 is denied because NEVER rule hashigher priority.
• Access to any other Applet is denied.

R1: (DID#1-Ref)-AR-APDUNEVER
5

R0: (DID#1-Ref)-AR-APDU-Filter

NOT EXISTNOT EXIST• Device applications signed with DID#1* are granted access toApplet #1, but only with an APDU matching the APDU filter.
• Access to any other Applet is denied.

6

R0: (DID#2-Ref)-AR-APDUNEVER

R0: (DID#2-Ref)-AR-APDUFilter

R0: (DID#2-Ref)-ARAPDU-ALWAYS• All device applications are denied access to SE App #1.
• Device applications signed with DID#2* are granted access toApplet #2, but only with an APDU matching the APDU filter.
• Device applications signed with DID#2* are granted access toany other Applet.

7

R0: (DID#1-Ref)-AR-APDUNEVERNOT EXIST

R1: (DID#2-Ref)-AR-APDU-Filter
Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

NOT EXIST• Device applications signed with DID#2* are granted access toApplet #1, but only with an APDU matching the APDU filter.
• Access to any other Applet is denied.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without restriction. Use of the information herein (whether or not obtained
directly from GlobalPlatform) is subject to the terms of the corresponding GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing)inconsistent with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 107 / 128

8Applet #1

Applet #2

Other AIDs
(generic rule)R0: (DID#1.2-Ref)-AR-APDUFilter

NOT EXISTNOT EXIST

R1: (DID#1.2.1-Ref)-AR-APDUFilter

Access Result for the Applets• Device applications signed with DID#1.2.1* are granted
access to Applet #1, but only with an APDU matching the R1
APDU filter.
• Device applications signed with DID#1.2* are granted accessto Applet #1, but only with an APDU matching the R0 APDU
filter.
• Access to any other Applet is denied.

9

R0: (DID#1-Ref)-AR-APDUALWAYSNOT EXISTNOT EXIST• Access to any other Applet is denied

R1: (ALL-Ref)-AR-APDU-NEVER
10

R0: (DID#1-Ref)-AR-APDUNEVERNOT EXISTNOT EXIST

R0: (DID#1-Ref)-AR-APDUNEVER• Device applications signed with DID#1* have no access toApplet #1.
• All other device applications don’t have access to Applet #1
because there is a specific rule protecting access toApplet #1.

R1: (ALL-Ref)-AR-APDUALWAYS
11• Device applications signed with DID#1* have an access toApplet #1.

NOT EXISTNOT EXIST• Access to all Applets is denied.

NOT EXISTNOT EXIST• Device applications signed with DID#1* have access toApplet #1.

R1: (ALL-Ref)-AR-APDU-NEVER
12

R0: (DID#1-Ref)-AR-APDUALWAYS• All other device applications don’t have access to any Applet(including Applet #1).

R1: (ALL-Ref)-AR-APDUALWAYS
13

NOT EXISTNOT EXIST

R0: (ALL-Ref)-ARAPDU-ALWAYS• All device applications have access to all Applets.

14

R0: (ALL-Ref)-AR-APDU-NEVER

R0: (ALL-Ref)-AR-APDUNEVER

R0: (ALL-Ref)-ARAPDU-ALWAYS• Access to Applet #1 and Applet #2 is denied for all device
applications.
• All other Applets can be accessed by all device applications.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without restriction. Use of the information herein (whether or not obtained
directly from GlobalPlatform) is subject to the terms of the corresponding GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing)inconsistent with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 108 / 128

15Applet #1

Applet #2

Other AIDs
(generic rule)

Access Result for the Applets

R0: (ALL-Ref)-AR-APDUALWAYS

R0: (ALL-Ref)-AR-APDUALWAYS

R0: (ALL-Ref)-ARAPDU-NEVER• Access to Applet #1 and Applet #2 is granted for all device
applications.
• All other Applets cannot be accessed by any device
application.

16

R0: (DID#1-Ref)-AR-APDUNEVER

R0: (DID#1-Ref)-AR-APDUALWAYS

R0: (DID#1-Ref)-ARAPDU-NEVER• A device application signed with DID#1 or any othercertificate has no access to Applet #1.

R1: (ALL-Ref)-AR-APDUALWAYS

R1: (ALL-Ref)-AR-APDUNEVER

R1: (ALL-Ref)-ARAPDU-ALWAYS• A device application signed with DID#1 is allowed to accessApplet #2.
• All other device applications have no access to Applet #2.
• Access to all other Applets is denied for all device
applications because there is a rule associating all otherApplets with a specific device application.

17

R0: (DID#1-Ref)-AR-APDUNEVER

R0: (DID#1-Ref)-AR-APDUALWAYS

R0: (DID#1-Ref)-ARAPDU-ALWAYS

R1: (DID#2-Ref)-AR-APDUNEVER

R1: (DID#2-Ref)-AR-APDUNEVER

R1: (DID#2-Ref)-ARAPDU- ALWAYS

R2: (DID#3-Ref)-AR-APDUNEVER

R2: (DID#3-Ref)-AR-APDUNEVER

R2: (DID#3-Ref)-ARAPDU- ALWAYS

R3: (ALL-Ref)-AR-APDUALWAYS

R3: (ALL-Ref)-AR-APDUALWAYS

R3: (ALL-Ref)-ARAPDU-NEVER

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

• Applet #1 can never be accessed.
• Applet #2 can only be accessed by device applications
signed with DID#1*.
• All other Applets can be accessed by all device applications
that are signed with DID#1, DID#2, DID#3.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without restriction. Use of the information herein (whether or not obtained
directly from GlobalPlatform) is subject to the terms of the corresponding GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing)inconsistent with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 109 / 12818

19Applet #1

Applet #2

Other AIDs
(generic rule)

Access Result for the Applets

R0: (DID#1-Ref)-AR-APDUALWAYS

R0: (DID#4-Ref)-AR-APDUALWAYS

R0: (DID#7-Ref)-ARAPDU-ALWAYS• Applet #1 can be accessed by all device applications that are
signed with DID#1, DID#2, DID#3.

R1: (DID#2-Ref)-AR-APDUALWAYS

R1: (DID#5-Ref)-AR-APDUALWAYS

R1: (DID#8-Ref)-ARAPDU-ALWAYS• Applet #2 can be accessed by all device applications that are
signed with DID#4, DID#5, DID#6.

R2: (DID#3-Ref)-AR-APDUALWAYS

R2: (DID#6-Ref)-AR-APDUALWAYS

R2: (DID#9-Ref)-ARAPDU-ALWAYS• All other Applets can only be accessed by device applications
signed with DID#7, DID#8, DID#9.

R3: (ALL-Ref)-AR-APDUNEVER

R3: (ALL-Ref)-ARAPDU-NEVERNOT EXISTNOT EXIST• Access to any Applet is denied.

R0: (DID#1-Ref)-AR-APDUFilter

NOT EXIST• Device applications signed with DID#1* can receive NFC
events from Applet #1.

NOT EXISTNFC Events Management20

R0: (DID#1-Ref)-AR-NFCALWAYS• Device applications signed with DID#1* are granted access toApplet #2, but only with an APDU matching the APDU filter.
• Device applications signed with DID#1 can receive NFC
events from Applet #2.
• Access to any other Applet is denied.
21

R0: (DID#1-Ref)-AR-APDUALWAYSNOT EXISTNOT EXIST• Device applications signed with DID#1* can receive NFC
events from Applet #1, because this application is allowed
APDU access to Applet #1.
• Other device applications cannot receive NFC events.

22

R0: (DID#1-Ref)-AR-NFCALWAYSNOT EXISTNOT EXIST• NFC events cannot be received by any device application.

R1: (DID#1-Ref)-AR-NFC-NEVER

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without restriction. Use of the information herein (whether or not obtained
directly from GlobalPlatform) is subject to the terms of the corresponding GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing)inconsistent with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 110 / 128

23

Applet #1

Applet #2

Other AIDs
(generic rule)

Access Result for the Applets

R0: (DID#1-Ref)-AR-NFC-NEVERNOT EXISTNOT EXIST• NFC events cannot be received by any device application.
• Device applications signed with DID#1* are granted APDU
access to Applet #1.

R1: (DID#1-Ref)-AR-APDUALWAYS• Access to any other Applet is denied.
24

R0: (DID#1-Ref)-AR-NFCALWAYSNOT EXISTNOT EXIST• Device applications signed with DID#1* can receive NFC
events.
• Other device applications cannot receive NFC events.

R1: (DID#1-Ref)-AR-APDUALWAYS• Device applications signed with DID#1* are granted APDU
access to Applet #1.
• Access to any other Applet is denied.

25

NOT EXISTNOT EXISTNOT EXIST• Access to any Applet is denied.

2222

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without restriction. Use of the information herein (whether or not obtained
directly from GlobalPlatform) is subject to the terms of the corresponding GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing)inconsistent with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 111 / 128

2223

Annex E

2224

The following diagrams give an overview of the APDU flows.

2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239

APDU PROCESS FLOWS

Figure E-1: Access Control Rules Retrieval from ARA-M ......................................................................112
Figure E-2: Specific Access Rule Retrieval from ARA-M (Deprecated) ................................................113
Figure E-3: Access Rule Retrieval Sequence (Deprecated) ..................................................................114
Figure E-4: Chained Certificate Querying (Deprecated) ........................................................................115
Figure E-5: Provisioning Directly to ARA with Admin Agent on Device .................................................117
Figure E-6: Deletion Directly to ARA with Admin Agent on Device .......................................................118
Figure E-7: Provisioning through Security Domain with Admin Agent on Device ..................................119
Figure E-8: Deletion through Security Domain with Admin Agent on Device ........................................120
Figure E-9: Rules Retrieval through Security Domain with Admin Agent on Device .............................121
Figure E-10: Provisioning through Security Domain Using Direct OTA Connection .............................122
Figure E-11: Deletion through Security Domain Using Direct OTA Connection ....................................123
Figure E-12: Rules Retrieval through Security Domain Using Direct OTA Connection .........................124
Figure E-13: Provisioning Using Direct OTA Connection with Limited Buffer........................................125
Figure E-14: Rules Retrieval Using Direct OTA Connection with Limited Buffer ...................................126

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 112 / 128
2240

E.1 Device Interface APDU Flow

2241
2242

Figure E-1 shows how the ACE (Off-card Entity) shall retrieve all access rules via the ARA-M, as described in
section 4.2.1.

2243

Figure E-1: Access Control Rules Retrieval from ARA-M
AC Enforcer

ARA-M

Security Domain

Open Channel

SELECT ARA-M

GET DATA (all)Response-ALL-REF-AR-DO
Tag=’all’LengthFirst data bytes

Process command

GET DATA (next)
Next data bytes

Process command

Retrieve next
data part
Close Channel

2244

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 113 / 128
2245
2246
2247

Figure E-2 shows how the ACE (Off-card Entity) shall retrieve specific access rules from the ARA-M using
GET DATA [Specific] (deprecated), as described in section 4.2.2. (See Figure E-3 for a more complete versionof the same process.)

2248
2249

Note: Figure E-2, Figure E-3, and Figure E-4 demonstrate access rule retrieval based on
GET DATA [Specific], which is deprecated.

2250

Figure E-2: Specific Access Rule Retrieval from ARA-M (Deprecated)
AC Enforcer

Security Domain

ARA-M

Open Channel

SELECT ARA-M

GET DATA (specific)
Tag=’specific’

REF-DO

Response-AR-DO
First data bytes
LengthProcess command

GET DATA (next)
Next data bytes

Process command

Retrieve next
data part
Close Channel

2251

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 114 / 128
2252
2253

Figure E-3 shows how the ACE (Off-card Entity) shall retrieve specific access rules from the ARA-M with thewhole retrieval sequence, as described in section 4.2.2.

2254

Figure E-3: Access Rule Retrieval Sequence (Deprecated)
AC Enforcer

ARA-M

Security Domain

Open Channel
SELECT ARA-M
A) Searching a rule which is specific for the device application and for the SE application with AID1GET DATA (specific) with REF-DO (DeviceAppID, AID1)
Stop the rule search and apply
the rules in AR-DO

Response-AR-DO with AR-DO
SW1SW2 = ’6A 88’ (Referenced data not found)

Rules exist for REF-DO. Set
rules into AR-DO
Rules do not exist exist for REF-DO

B) Searching a rule which applies for all device applications and is specific for the SE application with AID1GET DATA (specific) with REF-DO (<AllDeviceApplications>, AID1)
Stop the rule search and apply
the rules in AR-DO

Response-AR-DO with AR-DO
SW1SW2 = ’6A 88’ (Referenced data not found)

Rules exist for REF-DO. Set
rules into AR-DO
Rules do not exist exist for REF-DOC) Searching a rule which is specific for the device application and applies for all SE applications

GET DATA (specific) with REF-DO (DeviceAppID, <AllSEApplications>)
Stop the rule search and apply
the rules in AR-DO

Response-AR-DO with AR-DO
SW1SW2 = ’6A 88’ (Referenced data not found)

Rules exist for REF-DO. Set
rules into AR-DO
Rules do not exist exist for REF-DOD) Searching a rule which applies for all device applications and for all SE applications

GET DATA (specific) with REF-DO (<AllDeviceApplications>, <AllSEApplications>)
Stop the rule search and apply
the rules in AR-DO

Response-AR-DO with AR-DO
SW1SW2 = ’6A 88’ (Referenced data not found)

Rules exist for REF-DO. Set
rules into AR-DO
Rules do not exist exist for REF-DO

No matching rules found for the device
application: Deny the Access

Close Channel

2255
2256
2257
2258

Note for Figure E-3 and Figure E-4: If a rule is not found, then the ARA-M returns either an SW '6A 88'(Referenced data not found) or an SW '90 00' with response data (Response-AR-DO or a Response-ALLREF-AR-DO of null length ('FF5000' or 'FF4000')).

2259
2260
2261

Figure E-4 shows how the ACE (Off-card Entity) shall retrieve specific access rules from the ARA-M when thedevice application has a certificate chain.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 115 / 128
2262

Figure E-4: Chained Certificate Querying (Deprecated)
AC Enforcer

ARA-M

Security Domain

Open Channel
SELECT ARA-M
A) Searching a rule which is specific for the device application and for the SE application with AID1GET DATA (specific) with REF-DO (EndEntityCertHash, AID1)
Stop the rule search and apply
the rules in AR-DO

Response-AR-DO with AR-DO
SW1SW2 = ’6A 88’ (Referenced data not found)

Rules exist for REF-DO. Set
rules into AR-DO
Rules do not exist exist for REF-DO

Continue the rule search

GET DATA (specific) with REF-DO (IntermediateCertHash, AID1)
Stop the rule search and apply
the rules in AR-DO

Response-AR-DO with AR-DO
SW1SW2 = ’6A 88’ (Referenced data not found)

Rules exist for REF-DO.
Set rules into AR-DO
Rules do not exist exist for REF-DO

Continue the rule search

GET DATA (specific) with REF-DO (RootCertHash, AID1)
Stop the rule search and apply
the rules in AR-DO

Response-AR-DO with AR-DO
SW1SW2 = ’6A 88’ (Referenced data not found)

Rules exist for REF-DO. Set
rules into AR-DO
Rules do not exist exist for REF-DO

B) Searching a rule which applies for all device applications and is specific for the SE application with AID1GET DATA (specific) with REF-DO (<AllDeviceApplications>, AID1)
Stop the rule search and apply
the rules in AR-DO

Response-AR-DO with AR-DO
SW1SW2 = ’6A 88’ (Referenced data not found)

Rules exist for REF-DO. Set
rules into AR-DO
Rules do not exist exist for REF-DOC) Searching a rule which is specific for the device application and applies for all SE applications

GET DATA (specific) with REF-DO (EndEntityCertHash, <AllSEApplications>)
Stop the rule search and apply
the rules in AR-DO

Response-AR-DO with AR-DO
SW1SW2 = ’6A 88’ (Referenced data not found)

Rules exist for REF-DO. Set
rules into AR-DO
Rules do not exist exist for REF-DO

Continue the rule search

GET DATA (specific) with REF-DO (IntermediateCertHash, <AllSEApplications>)
Stop the rule search and apply
the rules in AR-DO

Response-AR-DO with AR-DO
SW1SW2 = ’6A 88’ (Referenced data not found)

Rules exist for REF-DO. Set
rules into AR-DO
Rules do not exist exist for REF-DO

Continue the rule search

GET DATA (specific) with REF-DO (RootCertHash, <AllSEApplications>)
Stop the rule search and apply
the rules in AR-DO

Response-AR-DO with AR-DO
SW1SW2 = ’6A 88’ (Referenced data not found)

Rules exist for REF-DO. Set
rules into AR-DO
Rules do not exist exist for REF-DOD) Searching a rule which applies for all device applications and for all SE applications

GET DATA (specific) with REF-DO (<AllDeviceApplications>, <AllSEApplications>)
Stop the rule search and apply
the rules in AR-DO

Response-AR-DO with AR-DO
SW1SW2 = ’6A 88’ (Referenced data not found)

Rules exist for REF-DO. Set
rules into AR-DO
Rules do not exist exist for REF-DO

No matching rules found for the device
application: Deny the Access

Close Channel

2263

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 116 / 128
2264

E.2 Remote Interface Based on RAM APDU Flow

2265
2266

This section describes different scenarios for remote management of access rules depending on the available
OTA channels to access the Secure Element:2267• Remote management using an Admin Agent on device

2268• Remote management using a direct OTA connection to the Secure Element2269• Remote management using a direct OTA connection to the Secure Element, with limited buffers

2270

E.2.1 Remote Management with Admin Agent on Device

2271
2272
2273

This section illustrates remote management scenarios using an Admin Agent on device as described in[GP SE OTA]: Between the Admin Agent and the Secure Element the communication is managed by SCP02
or SCP03 by sending the commands either directly to the ARA or to its SD as defined in [GP Card Spec].

2274

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 117 / 128
2275
2276
2277
2278

Figure E-5 shows how a remote administration server can store access rule data with an Admin Agent on
device to the ARA (ARA-M or ARA-C) by sending a STORE DATA (Command-Store-REF-AR-DO) commanddirectly to the ARA. This figure shows the storage of two access rules. The first rule is stored by using several
STORE DATA commands and the second access rule is stored by using only one STORE DATA command.

2279

Figure E-5: Provisioning Directly to ARA with Admin Agent on Device
Admin Agent on device

ARA

Security Domain

Open Logical Channel
SELECT ARA
Open Secure Channel

Open Secure Channel

Command-Store-REF-AR-DO

STORE DATA

Tag=’store’

LengthFirst data bytes

Decrypt & verify if necessary

P1: More blocks, P2: Block n=‘00'

Plain data if encrypted
Buffer first data bytes

SW1SW2 = ’90 00’

STORE DATA

Next data bytes

Decrypt & verify if necessary

P1: More blocks, P2: Block n=‘01' or ‘nl+1‘

Plain data if encrypted

Send next data part

Buffer next data bytes

SW1SW2 = ’90 00’

STORE DATA

Last data bytes

Decrypt & verify if necessary

Option1: P1: More blocks, P2: Block n=‘nl+1'
Option2: P1: Last block, P2: Block n=‘nl+1'

Plain data if encrypted
Store Access Rule

SW1SW2 = ’90 00’
Command-Store-REF-AR-DO

STORE DATA

Tag=’store’

LengthData bytes

If Option1, then: P1: Last block, P2: Block n=‘nl+1'
If Option2, then: P1: Last block, P2: Block n=‘00'

SW1SW2 = ’90 00’

Decrypt & verify if necessary
Plain data if encrypted
Store Access Rule

Close Channel

2280
2281

Note: ‘nl’ = block number of the last command

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 118 / 128
2282
2283
2284

The deletion of access rule data can be performed in the same way with a STORE DATA (Command-Delete).
Since the value of Command-Delete is always short, this command can always be transferred with one APDU.
This figure shows the deletion of two access rules.

2285

Figure E-6: Deletion Directly to ARA with Admin Agent on Device
Admin Agend on device

ARA

Security Domain

Open Logical Channel
SELECT ARA
Open Secure Channel

Open Secure Channel

Command-Delete

STORE DATA

Tag=’delete’

LengthValue

Decrypt & verify if necessary

Option1: P1: More blocks, P2: Block n=‘00‘
Option2: P1: Last block, P2: Block n=‘00‘

Plain data if encrypted
Delete Access Rule

SW1SW2 = ’90 00’
Command-Delete

STORE DATA

Tag=’delete’

LengthValue

If Option1, then: P1: Last block, P2: Block n=‘01‘
If Option2, then: P1: Last block, P2: Block n=‘00‘

SW1SW2 = ’90 00’

Decrypt & verify if necessary
Plain data if encrypted
Delete Access Rule

Close Channel

2286
2287

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 119 / 128
2288
2289
2290
2291
2292

Figure E-7 shows how a remote administration server can store access rule data with an Admin Agent on
device to the ARA (ARA-M or ARA-C) by sending to the associated Security Domain an INSTALL [forpersonalization] command and then a STORE DATA (Command-Store-REF-AR-DO) command. This figure
shows the storage of two access rules. The first access rule is stored by using several STORE DATA
commands and the second access rule is stored by using only one STORE DATA command.

2293

Figure E-7: Provisioning through Security Domain with Admin Agent on Device
Admin Agent on device

Security Domain

ARA

Open Logical Channel
SELECT Security Domain
Open Secure Channel
INSTALL [for personalization]

Reference to ARA

Command-Store-REF-AR-DO

STORE DATA

Tag=’store’

LengthFirst data bytes

P1: More blocks, P2: Block n=‘00‘

Decrypt & verify if necessary
Plain data
statusSW1SW2 = ’90 00’

Buffer next data bytes
STORE DATA

Next data bytes

P1: More blocks, P2: Block n=‘01‘ or ’nl+1‘

Decrypt & verify if necessary

Send next data part

Plain data
statusSW1SW2 = ’90 00’

Buffer next data bytes
STORE DATA

Last data bytes

P1: More blocks, P2: Block n=‘nl+1‘

Decrypt & verify if necessary
Plain data
statusSW1SW2 = ’90 00’

Store Access Rule
Command-Store-REF-AR-DO

STORE DATA

Tag=’store’

LengthData bytes

P1: Last block, P2: Block n=‘nl+1‘

Decrypt & verify if necessary
Plain data

SW1SW2 = ’90 00’

statusStore Access Rule

Close Channel

2294
2295

Note: ‘nl’ = block number of the last command

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 120 / 128
2296
2297
2298

The deletion of access rule data can be performed in the same way with a STORE DATA (Command-Delete).
Since the value of Command-Delete is always short, this command can always be transferred with one APDU.
This figure shows the deletion of two access rules.

2299

Figure E-8: Deletion through Security Domain with Admin Agent on Device
Admin Agent on device

Security Domain

ARA

Open Logical Channel
SELECT Security Domain
Open Secure Channel
INSTALL [for personalization]

Reference to ARA

Command-Delete

STORE DATA

Tag=’delete’

LengthValue

P1: More blocks, P2: Block n=‘00‘

Decrypt & verify if necessary
Plain data
statusSW1SW2 = ’90 00’

Delete Access Rule
Command-Delete

STORE DATA

Tag=’delete’

LengthValue

P1: Last block, P2: Block n=‘01‘

Decrypt & verify if necessary
Plain data

SW1SW2 = ’90 00’

statusDelete Access Rule

Close Channel

2300

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 121 / 128
2301
2302
2303

The retrieval of access rule data can be performed in the same way with a STORE DATA (Command-Get) ora STORE DATA (Command-Get-All). When the requested rules couldn’t be fetched in response to this firstcommand, a command STORE DATA (Command-Get-Next) can be performed to retrieve the remaining data.

2304

Figure E-9: Rules Retrieval through Security Domain with Admin Agent on Device
Admin Agent on device

Security Domain

ARA

Open Logical Channel
SELECT Security Domain
Open Secure Channel
INSTALL [for personalization]

Reference to ARA

Command-Get

STORE DATA

Tag=’Get’

Length=0

P1: More blocks, P2: Block n=‘00‘

Decrypt & verify if necessary

Response-ALL-REF-AR-DO
Tag=’FF40’

LengthFirst data bytes

Plain data
statusProcesscommandCommand-Get-Next

STORE DATA

Tag=’GetNext’

Length=0

P1: More blocks, P2: Block n=‘01‘ or ‘nl+1‘

Decrypt & verify if necessary

Send next data part

Plain data
statusNext data bytes

ProcesscommandCommand-Get-Next

STORE DATA

Tag=’GetNext’

Length=0

P1: Last block, P2: Block n=‘nl+1‘

Decrypt & verify if necessary
Plain data

Next data bytes

statusProcesscommandClose Channel

2305
2306

Note: ‘nl’ = block number of the last command

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 122 / 1282307

E.2.2 Remote Management with Direct OTA Connection

2308
2309

This section illustrates remote management scenarios using a direct OTA connection between the remoteadministration server and the Secure Element based on SCP80 or SCP81.

2310
2311
2312
2313
2314
2315

Figure E-10 shows how a remote administration server can store access rule data to the ARA (ARA-M or
ARA-C) by sending an INSTALL [for personalization] command and then a STORE DATA (Command-StoreREF-AR-DO) command to the associated SD. This figure shows the storage of two access rules. The first
access rule is stored by using several STORE DATA commands and the second access rule is stored by using
only one STORE DATA command.

2316

Figure E-10: Provisioning through Security Domain Using Direct OTA Connection
Remote Administration Server

Security Domain

INSTALL [for personalization]

ARA

Reference to ARA

Command-Store-REF-AR-DO

STORE DATA

Tag=’store’

LengthFirst data bytes

P1: More blocks, P2: Block n=‘00‘

Decrypt & verify if necessary
Plain data
statusSW1SW2 = ’90 00’

Buffer next data bytes
STORE DATA

Next data bytes

P1: More blocks, P2: Block n=‘01‘ or ‘nl+1‘

Decrypt & verify if necessary

Send next data part

Plain data
statusSW1SW2 = ’90 00’

Buffer next data bytes
STORE DATA

Last data bytes

P1: More blocks, P2: Block n=‘nl+1‘

Decrypt & verify if necessary
Plain data
statusSW1SW2 = ’90 00’

Store Access Rules
Command-Store-REF-AR-DO

STORE DATA

Tag=’store’

LengthData bytes

P1: Last block, P2: Block n=‘nl+1‘

Decrypt & verify if necessary
Plain data

SW1SW2 = ’90 00’

statusStore Access Rules

2317
2318

Note: ‘nl’ = block number of the last command

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 123 / 128
2319
2320
2321

The deletion of access rule data can be performed in the same way with a STORE DATA (Command-Delete).
Since the value of Command-Delete is always short this command can always be transferred with one APDU.
This figure shows the deletion of two access rules.

2322

Figure E-11: Deletion through Security Domain Using Direct OTA Connection
ARA

Security Domain

Remote Administration Server
INSTALL [for personalization]

Reference to ARA

Command-Delete

STORE DATA

Tag=’delete’

LengthValue

P1: More blocks, P2: Block n=‘00‘

Decrypt & verify if necessary
Plain data
statusSW1SW2 = ’90 00’

Delete Access Rule

Command-Delete

STORE DATA

Tag=’delete’

LengthValue

P1: Last block, P2: Block n=‘01‘

Decrypt & verify if necessary
Plain data

SW1SW2 = ’90 00’

statusDelete Access Rule2323

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 124 / 128
2324
2325
2326

The retrieval of access rule data can be performed in the same way with a STORE DATA (Command-Get) ora STORE DATA (Command-Get-All). When the requested rules couldn’t be fetched in response to this firstcommand, a command STORE DATA (Command-Get-Next) can be performed to retrieve the remaining data.

2327

Figure E-12: Rules Retrieval through Security Domain Using Direct OTA Connection
Remote Administration Server

ARA

Security Domain

INSTALL [for personalization]

Reference to ARA

Command-Get

STORE DATA

Length=0

Tag=’Get’

P1: More blocks, P2: Block n=‘00‘

Decrypt & verify if necessary

Response-ALL-REF-AR-DO
Tag=’FF40’

LengthFirst data bytes

Plain data
statusProcesscommandCommand-Get-Next

STORE DATA

Tag=’GetNext’

Length=0

P1: More blocks, P2: Block n=‘01‘ or ‘nl+1‘

Decrypt & verify if necessary

Send next data part

Plain data
statusNext data bytes

ProcesscommandCommand-Get-Next

STORE DATA

Tag=’GetNext’

Length=0

P1: Last block, P2: Block n=‘nl+1‘

Decrypt & verify if necessary
Plain data

Next data bytes

status2328
2329

Note: ‘nl’ = block number of the last command

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 125 / 1282330

E.2.3 Remote Management with Direct OTA Connection and Limited Buffers

2331
2332

This section illustrates remote management scenarios using a direct OTA connection between the remoteadministration server and the Secure Element based on SCP80 with limited incoming and outgoing buffers.

2333
2334
2335
2336

The incoming buffer might be too small to store an access rule to an ARA within an INSTALL [forpersonalization] session. In this case the Block-DO may be used to store access rule data block by block
over several INSTALL [for personalization] sessions.

2337
2338

Figure E-13: Provisioning Using Direct OTA Connection with Limited Buffer
Remote Administration Server

Security Domain
INSTALL [for personalization]
Block-DO

ARA

Reference to ARA

Command-Store-REF-AR-DO

STORE DATA Tag=‘Block‘ Length offset=0, length=200 Tag=’store’

LengthFirst data bytes

P1: Last block, P2: Block n=‘00‘

Decrypt & verify if necessary
Plain data
SW1SW2 = ’90 00’

statusINSTALL [for personalization]

Reference to ARA

Buffer next data bytes

Block-DO

STORE DATA Tag=‘Block‘ Length

offset=ol, length=200

Next data bytes

P1: Last block, P2: Block n=‘00‘

Decrypt & verify if necessary
Plain data

Send next data part

statusSW1SW2 = ’90 00’

Buffer next data bytes
INSTALL [for personalization]

Reference to ARA

Block-DO

STORE DATA Tag=‘Block‘ Length offset=ol, length=length of last data bytes

Last data bytes

P1: Last block, P2: Block n=‘00‘

Decrypt & verify if necessary
Plain data
SW1SW2 = ’90 00’

Store Access Rules

2339
2340

statusNote: ‘ol’ = offset + length of last command

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 126 / 128
2341
2342
2343

The outgoing buffer might be too small to retrieve all access rules from an ARA within an INSTALL [forpersonalization] session. In this case the Block-DO may be used to retrieve access rule data block by block
over several INSTALL [for personalization] sessions.

2344

Figure E-14: Rules Retrieval Using Direct OTA Connection with Limited Buffer
Security Domain

Remote Administration Server
INSTALL [for personalization]

Reference to ARA
Command-Get

Block-DO

STORE DATA Tag=’Block’ Length

ARA

Tag=’Get’

offset=0, length=200

Length=0

P1: Last block, P2: Block n=‘00‘

Decrypt & verify if necessary
Plain data

Response-ALL-REF-AR-DO
Tag=’FF40’

LengthstatusFirst data bytes

Processcommand
INSTALL [for personalization]
Command-Get-Next

Block-DO

STORE DATA Tag=’Block’ Length

offset=ol, length=200

Reference to ARA

Tag=’GetNext’

Length=0

P1: Last block, P2: Block n=‘00‘

Decrypt & verify if necessary
Plain data

Send next data part

statusNext data bytes

Processcommand

INSTALL [for personalization]
STORE DATA
Tag=’Block’ Length

Reference to ARA
Command-Get-Next

Block-DO

offset=ol, length=length of last data bytes Tag=’GetNext’

P1: Last block, P2: Block n=‘00‘

Length=0

Decrypt & verify if necessary
Plain data
Last data bytes

Processcommand2345
2346

statusNote: ‘ol’ = offset + length of last command

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 127 / 128
2347

Annex FMIGRATION SCENARIOS FOR THE UICC

2348
2349
2350

Prior to the publication of this specification, GSMA issued a document ([GSMA]) where access to applications
on a UICC is defined by a set of elementary files. This solution is identical to ARF defined in Chapter 7. GSMA
indicated that a long term solution would be based on this GlobalPlatform specification.

2351
2352

To guarantee compatibility with UICCs issued according to [GSMA] with ARF only, this specification makes it
mandatory that the ACE must support fallback to ARF for a UICC.

2353

The following transition scenarios for UICCs can be expected:

2354
2355

• A UICC that is deployed with ARF only can be upgraded to the solution in this specification by loading
and installing the ARA applets over-the-air.

2356
2357
2358

• A UICC issuer may decide to install (at production or over-the-air) an ARA-M applet that is able toevaluate the ARF rules. This would allow a Network Operator that uses (only) RFM to manage its
UICCs to continue to do so and to provide its rules to the ARF file system.

2359
2360
2361

• Another UICC issuer may decide to install (at production or over-the-air) an ARA-M applet that is notable to evaluate the ARF rules, migrate all rules from the ARF to the ARA-M, and remove the ARF
completely from the UICC.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Secure Element Access Control
Public Review v1.1.0.10
Page 128 / 128
2362

Annex GACCESS RULE INTERPRETATION

2363
2364

Table G-1 defines how ARA access rule policies shall be interpreted by the ACE, when using GET DATA [All]to retrieve the rules.

2365

Table G-1: Interpretation of Access Rules Stored in the ARA
Access Rule Policies

Granted Access1

no APDU / no NFC policy

N/A

2

APDU (ALWAYS/APDUFilter) / no NFC

APDU (ALWAYS/APDUFilter) / NFC (ALWAYS)

3

no APDU / NFC (ALWAYS)

APDU (NEVER) / NFC (ALWAYS)

4APDU (NEVER) / no NFC

APDU (NEVER) / NFC (NEVER)

5

no APDU / NFC (NEVER)

APDU (NEVER) / NFC (NEVER)

6APDU (ALWAYS/APDUFilter) / NFC (ALWAYS)

APDU (ALWAYS/APDUFilter) / NFC (ALWAYS)

7

APDU (NEVER) / NFC (NEVER)

APDU (NEVER) / NFC (NEVER)

8APDU (ALWAYS/APDUFilter) / NFC (NEVER)

APDU (ALWAYS/APDUFilter) / NFC (NEVER)

9APDU (NEVER) / NFC (ALWAYS)

APDU (NEVER) / NFC (ALWAYS)

2366
2367
2368

Table G-2 defines how ARF access rule policies shall be interpreted by the ACE when retrieving rules fromthe ARF or by the ARA-M having an ARF reading capability.

2369

Table G-2: Interpretation of Access Rules Stored in ARF
Access Rule Policies

Granted Access1

no APDU / no NFC policy

APDU (ALWAYS) / NFC (ALWAYS)

2

APDU (ALWAYS/APDUFilter) / no NFC

APDU (ALWAYS/APDUFilter) / NFC (ALWAYS)

3

no APDU / NFC (ALWAYS)

APDU (NEVER) / NFC (ALWAYS)

4APDU (NEVER) / no NFC

APDU (NEVER) / NFC (NEVER)

5

no APDU / NFC (NEVER)

APDU (NEVER) / NFC (NEVER)

6APDU (ALWAYS/APDUFilter) / NFC (ALWAYS)

APDU (ALWAYS/APDUFilter) / NFC (ALWAYS)

7

APDU (NEVER) / NFC (NEVER)

APDU (NEVER) / NFC (NEVER)

8APDU (ALWAYS/APDUFilter) / NFC (NEVER)

APDU (ALWAYS/APDUFilter) / NFC (NEVER)

9APDU (NEVER) / NFC (ALWAYS)

APDU (NEVER) / NFC (ALWAYS)

2370
2371
2372
2373
2374

Note: When several rules apply to the same access request, aggregation and conflict resolution shall be
performed by the ACE, using the algorithm defined in section 3.4.1. However, that algorithm doesn’t consider
missing attributes. Rules shall be interpreted as defined in Table G-1 (rules read from ARA-M) or Table G-2(rules read from ARF) only if attributes are missing from the result of the rule conflict resolution or combination.

Copyright  2012-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.