Privacy Framework Requirements · 2018-06-09 · B.9 Personalization-dependent Retrieval of Sec_Config Container UC1 ... This document discusses requirements for enhancing GlobalPlatform

Copyright 2012-2013 GlobalPlatform, Inc. All Rights Reserved. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights or other intellectual property rights of which they may be aware which might be necessarily infringed by the implementation of the specification or other work product set forth in this document, and to provide supporting documentation. The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information is governed by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

GlobalPlatform Government Task Force Privacy Framework Requirements Version 1.0

Public Release January 2013 Document Reference: GP_REQ_010

Privacy Framework Requirements – Member Release v1.0

Copyright 2012-2013 GlobalPlatform, Inc. All Rights Reserved. The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information is governed by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Privacy Framework Requirements – Member Release v1.0 3/43


Contents 1 Introduction ................................................................................................................................................ 7 1.1 Audience ............................................................................................................................................... 7 1.2 IPR Disclaimer....................................................................................................................................... 7 1.3 References ............................................................................................................................................ 7 1.4 Terminology and Definitions .................................................................................................................. 9 1.5 Abbreviations and Notations ............................................................................................................... 10 1.6 Revision History .................................................................................................................................. 11

2 Overview ................................................................................................................................................... 12 2.1 Scope .................................................................................................................................................. 13 2.2 Value Proposition of GlobalPlatform ................................................................................................... 14 2.3 Market Objectives ............................................................................................................................... 15

3 Privacy Properties (Informative) ............................................................................................................ 16 3.1 Untraceability....................................................................................................................................... 16 3.2 Unlinkability ......................................................................................................................................... 16 3.3 Selective Disclosure ............................................................................................................................ 16 3.4 Usage Confidentiality .......................................................................................................................... 16 3.5 Pseudonym ......................................................................................................................................... 17 3.6 Forward Secrecy ................................................................................................................................. 17 3.7 Limited Use ......................................................................................................................................... 17 3.8 Predicate Computation (Proving Computation on Attributes) ............................................................. 17 3.9 Trusted Third Party Disclosure ............................................................................................................ 17 3.10 Revocation .......................................................................................................................................... 17 3.11 Secure Messaging .............................................................................................................................. 17

4 Privacy Levels.......................................................................................................................................... 18

5 Requirements........................................................................................................................................... 20 5.1 Architecture Overview ......................................................................................................................... 20 5.2 Consequences for the Interface (APDU) ............................................................................................ 21 5.3 Consequences for the Platform (for example, API) ............................................................................ 21 5.4 Platform Requirements ....................................................................................................................... 22 5.5 Application Requirements ................................................................................................................... 27

6 Use Cases ................................................................................................................................................ 29

Annex A Publications on Privacy (Informative) ............................................................................. 30

Annex B Implementation Details (Informative) .............................................................................. 31 B.1 Privacy Level Definition ....................................................................................................................... 31 B.2 Privacy Level Retrieval ........................................................................................................................ 31 B.3 Control of Intrusive SELECT ............................................................................................................... 32 B.4 Security Configuration Format ............................................................................................................ 33 B.5 Privacy Levels and Registration Process ............................................................................................ 33 B.6 Personalization and Retrieval of Sec_Config Container ..................................................................... 35 B.7 Ability to Prevent AID or Sensitive Data Disclosure ............................................................................ 35 B.8 Recommended Generic Sequence ..................................................................................................... 37 B.9 Personalization-dependent Retrieval of Sec_Config Container UC1 ................................................. 40 B.10 Personalization-dependent Retrieval of Sec_Config Container UC2 ................................................. 40 B.11 Privacy Level Verification .................................................................................................................... 41

4/43 Privacy Framework Requirements – Member Release v1.0


B.12 Application Registration ...................................................................................................................... 42 B.13 Application Data Management ............................................................................................................ 43 B.14 Application Access to Current Security Status .................................................................................... 43



Figures Figure 1 – Platform Providing Privacy Services and Enforcing Privacy Rules ................................................. 20

Figure 2 – Use Case 1 ...................................................................................................................................... 25

Figure 3 – Use Case 2 ...................................................................................................................................... 25

Figure 4 – Use Case 3 ...................................................................................................................................... 26

Figure 5 – Existing Control of Intrusive Selection of an Application ................................................................. 32

Figure 6 – Proposed Control of Intrusive Selection of an Application .............................................................. 32

Figure 7 – Privacy Levels and Registration Model ........................................................................................... 34

Figure 8 – Excerpt from ISO DIS 7816-4:2010 (GET DATA with Odd INS) ..................................................... 35

Figure 9 – AID Protection against Unauthorized Disclosure ............................................................................ 36

Figure 10 – Starting a Privacy-Enabled Transaction / Option 1 ....................................................................... 38

Figure 11 – Starting a Privacy-Enabled Transaction / Option 2 ....................................................................... 39

Figure 12 – Diagram Applying to Use Case 1 .................................................................................................. 40

Figure 13 – Diagram Applying to Use Case 2 .................................................................................................. 41

Figure 14 – Example of Physical Interface Dependencies and Registration of Application Model .................. 42

Tables Table 1: Normative References ......................................................................................................................... 7

Table 2: Informative References ....................................................................................................................... 8

Table 3: Terminology and Definitions ................................................................................................................ 9

Table 4: Abbreviations and Notations .............................................................................................................. 10

Table 5: Revision History ................................................................................................................................. 11

Table 6: EU Legal Acts on Privacy (as of July 2012) ...................................................................................... 30

Table 7: Privacy Level Definition across Privacy Properties (Informative) ...................................................... 31



Requirements [R1] Management of SELECT Command .................................................................................................. 22

[R2] Provision of a Discovery Mechanism (Sec_Config) ............................................................................ 22

[R3.1] Privacy Policy Configuration ............................................................................................................... 23

[R3.2] Personalization and Retrieval of the Security Configuration ............................................................... 24

[R4.1] Ability to Prevent AID or Other Sensitive Data Disclosure .................................................................. 24

[R4.2] Recommended Generic Sequence ..................................................................................................... 24 [R5] Personalization-Dependent Retrieval of the Sec_Config Container: UC1 ......................................... 25

[R6] Personalization-Dependent Retrieval of the Sec_Config Container: UC2 ......................................... 25

[R7] Personalization-Dependent Retrieval of the Sec_Config Container: UC3 ......................................... 26

[R8.1] Requirement for Inter-application Communication – Varying Privacy Levels ..................................... 27

[R8.2] Requirement for Inter-application Communication – Verify Privacy Level .......................................... 27

[R8.3] Requirement for Inter-application Communication – Compare Privacy Levels .................................. 27 [R8.4] Requirement for Inter-application Communication – Coding Privacy Level ....................................... 27

[R8.5] Requirement for Inter-application Communication – Control of Internal Requests ............................ 27

[R9] Requirement for Application Registration ........................................................................................... 28

[R10] Requirement for Application Data Management ................................................................................. 28

[R11] Requirement for Privacy-Sensitive Data Handling .............................................................................. 28

[R12] Requirement for Multiple Privacy Levels in Multi-Application Context ................................................ 28 [R13] Requirement for the Follow-up of Current State of Authentication ..................................................... 28



1 Introduction This document discusses requirements for enhancing GlobalPlatform card specifications to support privacy as required for markets (including government) and mandated by various countries.

1.1 Audience

This document is intended primarily for the use of GlobalPlatform members developing GlobalPlatform specifications; for instance, for use by the Card Committee’s Card Specification Working Group when defining additional features to enable privacy sensitive applications on GlobalPlatform cards. Additionally, it may provide representatives of government agencies with information about what can be expected from GlobalPlatform cards in future in respect to privacy.

1.2 IPR Disclaimer

GlobalPlatform draws attention to the fact that claims that compliance with this specification may involve the use of a patent or other intellectual property right (collectively, “IPR”) concerning this specification may be published at https://www.globalplatform.org/specificationsipdisclaimers.asp. GlobalPlatform takes no position concerning the evidence, validity, and scope of these IPR claims.

1.3 References

See also Annex A, which lists informative references on privacy.

Table 1: Normative References

Standard / Specification Description Ref

GlobalPlatform Card Specification

GlobalPlatform Card Specification v2.2 [GPCS]

GlobalPlatform ID Configuration

GlobalPlatform ID Configuration v1.0, December 2011 [ID Config]

GlobalPlatform ISO Framework

GlobalPlatform Card Specification – ISO Framework v0.9.0.6, June 2012

[ISO Fmwk]

ISO/IEC 7816-4:2005 Identification cards – Integrated circuit cards – Part 4: Organization, security and commands for interchange

[7816-4]

ISO/IEC FDIS 7816-4:2012

Draft: Identification cards – Integrated circuit cards – Part 4: Organization, security and commands for interchange

[7816-4 FDIS]

ISO/IEC 7816-6 Identification cards – Integrated circuit cards – Part 6: Interindustry data elements for interchange

[7816-6]

ISO/IEC 15408-2:2008 Information technology – Security techniques – Evaluation criteria for IT security – Part 2: Security functional components

[15408-2]

RFC 2119 Key words for use in RFCs to Indicate Requirement Levels Available at: http://www.ietf.org/rfc/rfc2119.txt

[RFC 2119]

https://www.globalplatform.org/specificationsipdisclaimers.asp

http://www.ietf.org/rfc/rfc2119.txt




ICAO TR SAC Technical Report – Supplemental Access Control for Machine Readable Travel Documents v1.0, available from: http://www2.icao.int/en/MRTD/Downloads/Technical%20Reports/Technical%20Report.pdf

[TR SAC]

EC Mandate 436 Standardisation Mandate to the European Standardisation Organisations CEN, CENELEC and ETSI in the field of Information and Communication Technologies applied to Radio Frequency Identification (RFID) and systems

[EC 436]

Table 2: Informative References


Extended Access Control v2

Extended Access Control version 2.0 with Restricted Identification; ref. [SSCD-2], [ECC-2], [BSITR]

[EACv2/RI]

modular Enhanced Role Authentication

modular Enhanced Role Authentication, ref. [SSCD-2], [ECC-2]; ref. mERA-based e-Service access with trusted third party, and Privacy Protocol semantic — criteria list and privacy-preserving credentials format, both available from: http://www.ants.interieur.gouv.fr/ias/-ias-.html

[mERA]

PACE Password Authenticated Connection Establishment, e.g. as per [ICAO], [TR SAC]

[PACE]

CEN prEN 14890-1:2012 Application Interface for smart cards used as Secure Signature Creation Devices – Part 1: Basic services (status draft)

[SSCD-1]

CEN prEN14890-2:2012 Application Interface for smart cards used as Secure Signature Creation Devices – Part 2: Additional Services (status draft)

[SSCD-2]

CEN TS 15480-2:2012 CEN/TS 15480-2: Identification card systems – European Citizen Card – Part 2: Logical data structures and card services

[ECC-2]

ISO/IEC 18013 Information technology – Personal identification – ISO compliant driving licence

[DRVLIC]

ICAO DOC 9303 Machine Readable Travel Documents and Supplement to DOC 9303, International Civil Aviation Organization, both available from: http://www.icao.int/Security/mrtd/Pages/Document9303.aspx

[ICAO]

BSI TR-03110 Technical Guideline Advanced Security Mechanisms for Machine Readable Travel Documents, version 2.10, 20. March 2012, German Federal Office for Information Security, available from: https://www.bsi.bund.de/ContentBSI/EN/Publications/Techguidelines/TR03110/BSITR03110.html

[BSITR]

http://www2.icao.int/en/MRTD/Downloads/Technical%20Reports/Technical%20Report.pdf

http://www2.icao.int/en/MRTD/Downloads/Technical%20Reports/Technical%20Report.pdf

http://www.ants.interieur.gouv.fr/ias/-ias-.html

http://www.icao.int/Security/mrtd/Pages/Document9303.aspx

http://www.icao.int/Security/mrtd/Pages/Document9303.aspx

https://www.bsi.bund.de/ContentBSI/EN/Publications/Techguidelines/TR03110/BSITR03110.html

https://www.bsi.bund.de/ContentBSI/EN/Publications/Techguidelines/TR03110/BSITR03110.html




HSPD 12 Homeland Security Presidential Directive 12: Policy for a Common Identification Standard for Federal Employees and Contractors, August 27, 2004

[HSPD 12]

USDC PIA U.S. Department of Commerce PIA based on Homeland Security Presidential Directive 12, May 2006

[USDC PIA]

TBS PIA Treasury Board of Canada Secretariat – Directive on Privacy Impact Assessment, effective April 1, 2010

[TBS PIA]

1.4 Terminology and Definitions

The following meanings apply to SHALL, SHOULD, and MAY in this document (refer to [RFC 2119]):

• SHALL indicates that the statement containing the SHALL must be specified as defined in this requirement document.

• SHOULD indicates a recommendation.

• MAY indicates an option.

• OPTIONAL indicates an option.

Table 3: Terminology and Definitions

Term Definition

Application Provider Entity that owns an application on-board the platform and is responsible for the application’s behavior.

Global Privacy Protocol Privacy requirements that apply to an entire platform (and which may be the only privacy requirements defined for certain applications).

Identity Provider ref. Glossary for OASIS SAML V2.0, OASIS Standard: http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf A kind of service provider that creates, maintains, and manages identity information for principals and provides principal authentication to other service providers within a federation, such as with web browser profiles.

Platform Kernel of functions offering services to a software layer that handles applications on top of it, and that ensures inter-application security and communication.

Privacy Level Defines the techniques to be used to achieve each privacy property, based on the privacy requirements of the application.

Privacy Manager On-card entity ensuring consistency and managing conflicts between the platform’s Global Privacy Protocol (GPP), the application’s Specific Privacy Protocol (SPP), and Privacy Levels. OPEN or an enhanced default-selected application MAY act as the Privacy Manager.

Privacy Platform Administrator

Off-card Application Management system or authority in charge of the maintenance of the Privacy Level, the SPP, and the GPP on the card.

Privacy policy Policy enforcing privacy and resulting from a combination of a Privacy Level, one or more GPP, and one or more SPP.

http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf



Term Definition

Privacy-Enabled platform Smartcard platform offering a service featuring privacy protection for the application(s) on the top of it.

Privacy-sensitive data Data that may expose the user to traceability or linkability risk if disclosed to the outside world.

Secure Element A tamper resistant component which is used in a device to provide the security, confidentiality, and multiple application environment required to support various business models. Such a Secure Element may exist in any form factor such as UICC, embedded SE, smartSD, smart microSD, etc.

Security Configuration The set of BER-TLV encoded GPP and SPP according to ASN.1 specified in this document.

Service Provider ref. Glossary for OASIS SAML V2.0, OASIS Standard: http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf A role donned by a system entity where the system entity provides services to principals or other system entities.

Specific Privacy Protocol Privacy requirements that apply to a particular application; may be further limited as applying only to a particular physical interface and/or life cycle state.

1.5 Abbreviations and Notations Table 4: Abbreviations and Notations

Abbreviation / Notation Meaning

DO Data Object

EACv2 Extended Access Control version 2

EACv2/RI Extended Access Control version 2.0 with Restricted Identification

EC European Commission

ECC European Citizen Card

GPP A platform’s Global Privacy Protocol

IdP Identity Provider

ISD Issuer Security Domain

LCS Life Cycle State

mERA modular Enhanced Role Authentication

PACE Password Authenticated Connection Establishment

PIA Privacy Impact Assessment

PIV Personal Identity Verification

RI Restricted Identification

SAC Supplemental Access Control

SD Security Domain

http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf



Abbreviation / Notation Meaning

SE Secure Element

SP Service Provider

SPP An application’s Specific Privacy Protocol

TBS Treasury Board of Canada Secretariat

UC Use Case

WG Working Group

1.6 Revision History Table 5: Revision History

Date Version Description

January 2013 1.0 Initial release



2 Overview Although identity federation provides means to spare the user the need for multiple passwords and enables cross-domain collaboration, the user’s privacy is still subject to risks whenever his/her identification data or the data uniquely attached to his/her card are exposed to the off-card system (Service Provider, card content management system, trusted third party, etc.). Therefore, enhancing security for card bearer identification involves not only protecting the sensitive data through security protocols that provide confidentiality and integrity, but also preventing leakage of any data that would otherwise allow tracing back the card and/or the user or exposing to the outside world a collection of convergent information profiling the user’s behavior. Such measures need to be effective even if the entities intervening in the system deployment collude (e.g. Service Provider with Identity Provider), and need to apply to the entire platform in order to support the privacy by-design concept.

The variety of emerging application and cryptographic solutions (e.g. modular Enhanced Role Authentication [mERA], Extended Access Control v2 [EACv2/RI], OPACITY protocol, Microsoft’s U-Prove, IBM’s Identity Mixer (Idemix), etc.) lead to different approaches in terms of selection of the user’s identification attributes and issuance of credentials, and in terms of cryptographic algorithms employed. Therefore, regardless of the technology involved for the application layer, transport protocol, access control, attributes selection, credentials discovery, and cryptography, GlobalPlatform’s Privacy-Enabled platform is intended to provide a platform that can meet the requirements for most of the existing privacy application solutions. This privacy by-design conformant platform represents a token embedded ecosystem ensuring consistency of the rules governing applications behavior with regard to the Host and with regard to inter-application communications. Consequently, applications laid on the Privacy-Enabled platform must comply with testing procedures and must be managed by a Security Domain or Issuer Security Domain fulfilling some common rules of privacy policy. The GlobalPlatform Privacy Framework can adopt in addition to its privacy-enabling features all or part of the GlobalPlatform ISO Framework [ISO Fmwk] and the GlobalPlatform ID Configuration [ID Config] if this convergence is deemed useful.



2.1 Scope

The terms of reference of privacy need to be defined first to set the ground for further technical requirements. The privacy paradigm is contingent on the entire ecosystem involving all the stakeholders (secure platform issuer, issuer policy, Service Provider and Identity Provider policy, Integration Systems, etc).

In a multi-application provider context, the success of the privacy paradigm is contingent on all providers relying on the secure platform to deploy their services. (If one SE application easily leaks sensitive identification data, then the privacy protection measures on other SE applications may not be effective depending on the policy):

Given an SE platform policy, only applications that meet the policy can be present.

A Privacy-Enabled platform SHOULD preserve user anonymity for access to e-Services, facilities, or IT systems.

The same application on an SE platform MAY use different protection mechanisms to meet a privacy policy. For instance:

• OPACITY-FS + Secure Messaging to protect application management

• PACE [PACE] + Secure Messaging for eService access

More generally, privacy is manifold and can be achieved through:

• Confidentiality of transmitted data based on cryptography (i.e. secure messaging)

• Traceless authentication

• Avoidance of profiling

• Avoidance of correlation

• User consent and/or relying party authentication

• Selective disclosure

• etc.



2.2 Value Proposition of GlobalPlatform

The GlobalPlatform Value Proposition aims at determining how to define a migration path where the card platform provides:

• Support of current GlobalPlatform functions and protocols (GlobalPlatform Card Specification [GPCS], etc.)

o Card Content Management

o SCP03-ISO, SCP03, SCP02, and SCP10 were not designed with privacy in mind, so are recommended for card content management only.

• Incremental improvements

o Re-using existing blocks

o Not building a platform from scratch

• Privacy enforcement

o Privacy enhanced services offered to all applications within a security domain

o Choice of standalone privacy-enhanced protocols including Host, card, or user authentication or not.

o A Privacy Manager on-board controlling that the platform meets the privacy rules established for it

• Lightweight solution

o Easy migration for existing applications

o Preventing environment complexity

• User consent scheme

o User consent MAY be requested before or after authentication.

• Privacy ecosystem

o A privacy-enabler (application – discussed in Chapter 4), a platform fulfilling privacy requirements, and a deployment infrastructure

Existing GlobalPlatform protocols (i.e. SCP) relying on unique card identifier disclosure are not relevant as privacy-enabler (because they expose to traceability), but MAY still be implemented if deemed useful to set up secure channels for card content management purposes.



2.3 Market Objectives

The primary market objectives are as follows:

• To allow further role separation of application providers, issuers, and system providers by extending the separation to the privacy area; that is, avoid sharing privacy relevant data between these roles. A PIA (Privacy Impact Assessment) policy should be elaborated to provide guidelines for respective roles and responsibilities for the stakeholders deploying privacy.

• To guarantee that a given platform meets the necessary privacy requirements and thus establish a reference in terms of privacy levels. Privacy levels described in this document are intended for the sole purpose of inter-application communication in a multi-application context where consistency is required to prevent unbalanced privacy capabilities between applications on-board the platform. Privacy levels are not absolute values and their relative scalability is left up to the issuer and allow for adjustment according the platform purposes.

• To facilitate the implementation of applications with privacy requirements on a GlobalPlatform card, for example government applications (machine readable travel documents, driving licenses, National ID cards, etc.).

Of course, a platform cannot, by definition, fully control the application running on it or the purposes of the data handled by such application. Certain requirements and restrictions, which are applicable to the platform, have to be “forwarded” to the application and other actors of the value chain.

Later in this document, some examples of Privacy-Enabled platforms are given. In the field, each issuer may choose and fine tune its own privacy rules.

This document presents the requirements necessary to fulfill the market objectives stated above. The ultimate goal is to have a standardized and interoperable way to handle privacy in standardized open platforms. This is, of course, of utmost importance in the current fragmented Government ID Market, where many solutions are presented, but even more important in the upcoming connected market. There, the secure elements embedded in phones or portable devices may support even more functionalities and thus be even more privacy sensible.

For details on communications, directives, or legal acts bearing on privacy, see Annex A.

Further to the present requirements, in order to consolidate GlobalPlatform Privacy Framework terms of references and applicability, it is advisable to consider elaborating on related guidelines for a PIA (Privacy Impact Assessment) framework preferably in a normative context, e.g. EC Mandate 436 [EC 436]. PIAs are used to identify the potential privacy risks of new or redesigned government programs or services (e.g. federal programs, Personal Identity Verification (PIV), etc). They help eliminate or reduce those risks to an acceptable level. PIA policy is intended to describe the privacy protections for the personal information that is collected and maintained in the process of registration and issuance and during the design, implementation, and evolution of programs and services that raise privacy issues; it ensures as well the security and privacy fulfillment during electronic transactions. Such initiatives are already in place; e.g. the U.S. Department of Commerce PIA [USDC PIA] based on Homeland Security Presidential Directive 12 [HSPD 12], the Treasury Board of Canada Secretariat’s Directive on Privacy Impact Assessment [TBS PIA], etc.

Note: The requirements in this document can be considered as part of a more global PIA Policy and can be employed as a starting point to further determine a GlobalPlatform adjusted PIA.



3 Privacy Properties (Informative) Privacy Levels (discussed in Chapter 4) can be defined in terms of privacy properties as discussed in this chapter. This list is informative and not exhaustive but includes the most significant and usual properties that can be achieved by implementation measures. This list may be extended with additional privacy properties if deemed useful. For more accurate definition of these respective properties, ISO/IEC 15408-2:2008 [15408-2].

3.1 Untraceability

Untraceability denotes the ability to prevent user identification even if the secure platform issuer and the Identity Provider (IdP) or the Service Provider collude: They cannot track a credential back to the user. This SHOULD remain true even if the user authenticates strongly to the issuer (or to the Identity Provider). This SHOULD also remain true if several verifications are performed at different times and different locations; there SHOULD be no way to correlate those verifications.

For example: Issuer and Service Provider can never link a token issued to a token presented to an SP, so there is no way for an issuer or a verifier to track the tokens back to their users.

Note: For the purposes of legal or judicial inquiry, it remains useful to allow for recovering of user identification by cryptographic means that are not merely accessible thru unauthorized collusion.

3.2 Unlinkability

Unlinkability denotes the ability to prevent the establishment of a link between different attributes presented by the same user: Two credentials cannot be linked to the same user, even if issued by the same issuer (or IdP), at the same time, and for the same purposes.

For example: The user can choose, when proving his right to access a service, whether he wants to be recognized by simply reusing the same credential, or else choosing another one.

3.3 Selective Disclosure

Selective Disclosure denotes the ability to disclose only the minimal amount of user identification data necessary for a selected action: This could be a minimal set of necessary attributes as well as identification data derived from attributes such as age verification or community verification (see section 3.8). A credentials token can contain multiple attributes (what the user accepts to prove), and the user can choose to disclose only some of them to the SP. The SP still has the highest level of trust in the proof.

Examples:

User consent required upon each criterion.

Different levels of user authentication or Host or context authentication required prior to releasing specific attributes.

3.4 Usage Confidentiality

Usage Confidentiality denotes the ability to ensure that communicated data does not reveal the nature and details of the transaction, such as identification data, application identifier, and execution success or failure.



3.5 Pseudonym

Pseudonym denotes the ability to generate a unique pseudonym which will identify the user in a unique way without disclosing his/her data. To enforce unlinkability, the pseudonym SHOULD be different for each Service Provider.

For example: The credentials token contains a cryptographically protected unique pseudonym available to the Service Provider; this pseudonym cannot be used to guess the actual user identity. The pseudonym MAY be renewed before each session with the Service Provider.

3.6 Forward Secrecy

Forward Secrecy denotes limited risk in case of attack: the ability to protect the secure channel exchange even if the Service Provider key is compromised at a later date.

For example: Ensure that a session key derived from a set of long-term public and private keys will not be compromised if one of the (long-term) private keys is compromised in the future.

3.7 Limited Use

Limited Use denotes the ability to limit the use of credentials to a determined period of time or to restrict their use to a determined number of presentations.

3.8 Predicate Computation (Proving Computation on Attributes)

Predicate Computation denotes the ability to prove computations on the attributes rather than disclosing the attributes themselves. The actual value of user identification attributes is not disclosed whereas the user can prove some computation on these attributes

For example: Functionality of COMPARE APDU command (ISO/IEC 7816-4 [7816-4]).

3.9 Trusted Third Party Disclosure

Trusted Third Party Disclosure denotes the ability to protect an attribute by allowing its disclosure only by a trusted third party (e.g. by encoding the attribute in the credential). The credentials can contain some verifiable encrypted attributes that can be checked by the Service Provider.

For example: Signature of Identity Provider on the credentials.

3.10 Revocation

Revocation denotes the ability to revoke a credential.

Warning: This procedure may result in authorized exchange of information leading to user identification in some cases.

3.11 Secure Messaging

Secure Messaging denotes the ability to provide secure messaging to protect commands exchanged.



4 Privacy Levels The following and non-exhaustive Privacy Levels are defined as examples:

• Basic

• Enhanced

• Paranoid

It is understood that “Paranoid” may be renamed.

Further categories MAY be defined by the Privacy Platform Administrator.

Privacy levels derived from the combination of all or part of determined privacy properties (see Chapter 3) are relative values allowing for scalability of application privacy-enabling features.

Privacy Levels are not absolute evaluation of the privacy protection capability between platforms from different issuers; they are instead a means for scalability under control of each Issuer/Privacy Platform Administrator applicable to a specific Privacy-Enabled platform with a specific purpose.

GlobalPlatform will not assign Privacy Levels to cryptographic protocols; this assignment is the task of the issuer.

To achieve the desired Privacy Level, privacy preserving protocols such as those listed below MAY be used:

• mERA-based Privacy Enabler protocol

• EACv2/Restricted Identification protocol

• OPACITY-ZKM protocol (SE authentication)

• OPACITY-FS protocol (mutual authentication)

• Password Based Protocol (PACEv2)

Note: Ongoing research and development on privacy mechanisms may lead in the near future to convergent solutions incorporating combined privacy features (e.g. presentation tokens and Restricted Identification or pseudonym).

Applications implementing those privacy preserving protocols are called herein “Privacy-enablers”; they fit on top of the platform for which requirements are specified in this document. Accordingly, a privacy ecosystem is comprised at least of a Privacy-enabler laid on a privacy-conformant platform and interacting with a Service Provider supporting the Privacy-enabler specifics. The requirements listed in this document address only the platform aspects.

Privacy usage depends on issuer or Privacy Platform Administrator policy as follows:

• Usage under control of:

o Application Security Domain

o Privacy enabled default-selected (I)SD

o All security domains: ISD and other Security Domain (coherent privacy control across all applications on the card platform): Policy is managed by a Privacy-controlling security domain.

The enrolment and publication of the privacy policy SHALL be performed according to requirements [R3.1] and [R9].

Figure 7 on page 34 illustrates the GlobalPlatform registration process conforming to [R3.1] and [R9].



Privacy Level definitions are likely to vary depending on issuer or Privacy Platform Administrator policy, so it is recommended that the Privacy Level be registered as a bitmap (i.e. over two bytes) in order to allow for flexibility. See section B.1.



5 Requirements Section 5.1 introduces the main actors in the privacy-by-design platform ecosystem and related terminology, including Issuer, Privacy Platform Administrator, Application Provider, Privacy Manager (on-card), and the entity in charge of privacy-related testing procedures. Sections 5.2 and 5.3 elaborate on the consequences of privacy measures on the APDU interface (card edge) and the Platform (internal API, etc.) respectively. Related requirements are listed in sections 5.4 and 5.5.

5.1 Architecture Overview Figure 1 – Platform Providing Privacy Services and Enforcing Privacy Rules

One of the main assets under privacy protection by the platform is the list of Application Identifiers present on-card. The knowledge of the application(s) on-board may become a source of user profiling and may to some extent weaken the privacy.



5.2 Consequences for the Interface (APDU)

Usually, applications Management Systems need information about a Security Domain before they can start to interact with it. This includes the kind of Security Domain it is and what Secure Channel Protocol it supports. The mechanism for providing information about a Security Domain is the Security Domain Management Data (tag '73') that is returned in the response to the SELECT command when present. Security Domain Management Data is also returned in response to a GET DATA command with tag '66'. The information provided in template '66' enables initial communication with the card.

However, in a privacy ecosystem, card related information such as Card Recognition Data, Card Management Type, Card Identification Scheme, Card Configuration details, ISD Certificate information, and so on, also jeopardize the privacy paradigm if exposed systematically to the Host. At the moment no minimum security requirements are applicable to SELECT APDU command; control of response to this command SHOULD be considered for the sake of privacy.

An ISD or supplementary SD acting as a selected application SHALL execute and respond to APDU commands. Therefore, any APDU command (i.e. SELECT, GET DATA) likely to disclose information unique to the card or to the card user during the initial communication SHALL be prohibited to the Card Manager or the default-selected application or OPEN to comply with privacy requirements. A set of requirements is described in section 5.4.

5.3 Consequences for the Platform (for example, API)

The Host needs the container nesting the application security configuration fulfilling privacy policy to take the necessary measures prior to performing a transaction with the application. Depending on the so-called container location on-card, its retrieval MAY resort to different approaches (including API calls).

• A default-selected ISD MAY need to identify the SD managing the application sought for the transaction and MAY have to get the security configuration from it. For this purpose, an appropriate API primitive is required.

• The security configuration item MAY be shaped as a Data Object or as a bitmap or even both if deemed useful, which entails adapted input/output parameters to retrieve the security configuration.

• Inter-application communication usually relying on a shareable interface MAY become subject to some restrictions to prevent unauthorized exchange of data between applications. For instance, two applications on the same platform SHOULD not exchange data that is under privacy protection rules within one application (data sending entity) if no such rules apply or less stringent rules apply in the context of the second application (data receiving entity). Consequently, the shareable interfaces on a Privacy-Enabled platform SHOULD filter the access to their API, e.g. by security level control before data exchange, mutual authentication, enhancement of GPRegistryEntry API, etc. For instance, the called application MAY require the Privacy Level of the calling application before releasing any privacy-sensitive information; the lowest privacy level of the calling application (e.g. hybrid application endowed with two physical interfaces) SHOULD determine the decision of the called application. See section B.2.



5.4 Platform Requirements

This section describes requirements for the platform; associated implementation proposals are suggested only to illustrate a means of realization. It is up to the Card Specification WG to adopt another alternative for implementation if considered more appropriate.

[R1] Management of SELECT Command

• The SELECT command MAY remain optional functionality for Backwards Compatibility (trial and error)

• In [GPCS], the OPEN processes only those SELECT commands indicating the SELECT [by name] option, and all options other than SELECT [by name] are passed to the currently selected Security Domain or application on the indicated logical channel. To prevent leakage of traceability-purported data, the response to the SELECT command SHOULD not convey the FCI (File Control Information) template.

• The application, the OPEN, or the SD SHALL respond to unauthenticated read attempts with status word '69 XY'.

o For example: Security status not satisfied SW1-SW2 = '69 82'

• Upon SELECT, the application on-card SHOULD no longer systematically query its security level before its Security Domain, and OPEN SHOULD respond with Status Word '69 XY'; optionally, OPEN or the default-selected application MAY respond according to the application’s Privacy Level.

• The response to the SELECT command SHALL be independent of the life cycle state of the targeted application. For example, the Status Word '69 xx' SHOULD be returned when the targeted application is in the non instantiated state or in one of the GlobalPlatform life cycle states (INSTALLED, SELECTABLE, LOCKED).

• The response time and the power consumption of the SELECT command SHALL be independent of the position of the targeted application instance in the GlobalPlatform registry.

• After SELECT [by name], the OPEN or the default selected application SHALL behave as if no application has been selected. See section B.3.

[R2] Provision of a Discovery Mechanism (Sec_Config)

If the issuer’s policy allows returning application or platform dependent information, then:

• The following information (security configuration data) SHALL be delivered to the terminal:

o Sequence of available AID (optional)

o Object identifiers of applicable privacy protocols

o Required and optional protocol data

• Sec_Config MAY be retrieved by the Host for awareness about platform or application security requirements related to the local communication segment (for instance the segment likely to be protected by PACE) or the remote communication channel. See section B.4 for the Sec_Config format.

• Sec_Config MAY list the entire set of protocols that are required by the application privacy policy to allow a transaction to take place. Each protocol SHALL be assigned its unique OID along with its required and/or optional data necessary to its proper execution.

o Example list of protocols: PACE + Terminal Authentication + Passive Authentication + Chip Authentication



[R3.1] Privacy Policy Configuration

The configuration of the privacy policy SHALL be performed according to the following rules (see section B.5):

• An application privacy policy SHALL be determined by the combination of three parameters defined in this document as a Privacy Level, a Global Privacy Protocol (GPP), and a Specific Privacy Protocol (SPP).

• A Privacy Level (as discussed in Chapter 4) SHALL be quantified as a relative value according to the issuer’s policy for a platform and SHALL be derived from verifiable privacy properties (as discussed in Chapter 3).

• A preferred default Privacy Level MAY be determined for a platform through a set of mandatory privacy properties, the rest being optional and up to each Service Provider.

• A Privacy Level is either by-default or respective to a physical interface.

• With regard to the physical interface, a Privacy Level MAY depend on the card Life Cycle State (LCS).

• The by-default Global Privacy Protocol MAY vary according the physical interface.

• The Security Configuration (Sec_Config) belonging to an application represents the set of GPP and SPP, i.e. a privacy-enabling application MAY require both the GPP and an SPP.

• A Privacy Level SHALL be enforced through the implementation of a GPP and/or an SPP. Therefore, each Privacy Level SHALL be associated to one platform by-default GPP, and/or to one application-specific SPP.

• At installation time on a Privacy-Enabled platform, the privacy policy SHALL be declared to allow the default-selected application or OPEN to check whether the conditions are fulfilled whenever this application is selected.

• If not installed with a dedicated privacy policy, the by-default GPP SHALL apply to the application.

• The GPP SHALL apply to the entire platform whereas the SPP is specific to the application.

• An SPP MAY be shared by more than one application.

• GPP and SPP MAY be updated post-issuance by an authorized entity, i.e. Privacy Platform Administrator or Issuer.

• During SPP and/or GPP update, the GPP by-default SHALL be executable.

• The update of GPP and/or SPP during the platform lifespan SHALL only be authorized by the Privacy Manager if the GPP and/or SPP crypto-suites remain in the security range of their related Privacy Level, i.e. an updated GPP and/or SPP SHALL not downgrade the Privacy Level declared at registration time by their parent Security Domain.

• An application MAY be assigned one or more SPP.

• A platform MAY be assigned one or more by-default GPP, e.g. physical interface dependent GPP.

• A Privacy Level SHALL be registered along with the physical interface to which it applies, the platform life cycle states to which it applies, and the links to its respective GPP(s) and SPP(s). A bitmap representation is recommended for setting Privacy Level features. (See section B.1 regarding bitmap representation.)



[R3.2] Personalization and Retrieval of the Security Configuration

• Sec_Config SHOULD be hosted as either of the following:

o a container in the current template, i.e. current context in (I)SD

o a container in the context of the application

• An APDU command SHOULD be designed to retrieve the container in an interoperable way (see section B.6).

[R4.1] Ability to Prevent AID or Other Sensitive Data Disclosure

• Before authenticating an external entity to the necessary extent, the platform SHALL not reveal any sensitive data. In this context, sensitive data could be (see section B.7):

o Unique identifier

o List of available AIDs on the card

o Identifier of the card issuer

o FCI information

• Applications’ AID MAY be protected as part of the sensitive data.

• The platform SHALL provide a mechanism to prevent AID disclosure before authenticating the external entity to the necessary extent.

[R4.2] Recommended Generic Sequence

The different alternatives described by the present requirement SHOULD be specified.

• For privacy enforcement with AID protection, SELECT by name is considered not necessary. The Host being generally application-dedicated, it MAY start the transaction with the card by first executing the OPTIONAL primary security measures if any (i.e. Global Privacy Protocol applying to all the applications on-card without need for application selection); then the Host MAY apply the privacy protocol specific to the application (i.e. the SPP).

• The GPP measures may not necessarily be useful and some use cases may not resort to the GPP Sec_Config container since the Host is aware of the security measures and can directly perform the SPP appropriate to the application with which it wants to transact. Accordingly, the GPP MAY be empty or MAY offer a set of crypto suites amongst which the Host can select.

• Once the Sec_Config container is retrieved by the default-selected application it MAY remain internally to the card and not be exposed to the Host.

• The ISO APDU command from a Host setting the security context (MSE SET) MAY convey parameters relating implicitly to a given Sec_Config container; such parameters can be algorithm identifiers, key identifier, role certificate (e.g. CVC), Certificate Holder Authorization Template (CHAT), etc. Therefore the default-selected application MAY determine which application is concerned/targeted by the transaction and MAY hand on the APDU commands to it. The entire sequence would be performed without a SELECT command, thereby preventing AID-based traceability. See section B.8.



[R5] Personalization-Dependent Retrieval of the Sec_Config Container: UC1

Depending on its personalization and on the platform Privacy Level, the Specific Privacy Policy Sec_Config container SHOULD be retrieved in a specific way depending on the use case.

In use case 1, Sec_Config data is nested in the ISD and applies to all applications managed by this ISD.

Figure 2 – Use Case 1

See section B.9 for diagram applying to Use Case 1.



In use case 2, Sec_Config data is nested in SDs managing their respective applications.

• A new entry point in the SecureChannel shareable interface MAY be dedicated to the retrieval of the Sec_Config denoted by application name. See example of implementation in section B.10.






Use case 3, illustrated in Figure 4, is a mix of UC1 [R5] and UC2 [R6]: Sec_Config data is nested both in ISD and SD managing their respective applications. The flow depends on the Privacy Level; see [R4.2] for a recommended generic transaction flow for AID protection.


• The retrieval of Sec_Config data for UC3 MAY rely on the procedures described in both [R5] and [R6].



5.5 Application Requirements

This section describes requirements for the application; associated implementation proposals are suggested only to illustrate a means of realization. It is up to the Card Specification WG to adopt another alternative for implementation if considered more appropriate.

[R8.1] Requirement for Inter-application Communication – Varying Privacy Levels

Applications on the same platform MAY have different respective Privacy Levels.

[R8.2] Requirement for Inter-application Communication – Verify Privacy Level

Privacy-related transaction data or user identification data may be shared between applications with different respective Privacy Levels, thereby risking information leakage to a non-authorized application. Therefore control of the respective Privacy Levels of the applications SHALL be performed. See section B.11.

[R8.3] Requirement for Inter-application Communication – Compare Privacy Levels

The Privacy Level MAY be considered as part of application private data, accordingly the communication of the Privacy Level to another application MAY be restricted such as:

• To share privacy-related transaction data or user identification data, two applications SHOULD have compatible Privacy Levels.

[R8.4] Requirement for Inter-application Communication – Coding Privacy Level

[R8.2] and [R8.3] entail that the application on-card SHALL interpret the Privacy Level from another application; thus, for the sake of interoperability, a bitmap or OID fixed meaning is necessary and discretionary data SHOULD not be allowed (refer to [R2]).

[R8.5] Requirement for Inter-application Communication – Control of Internal Requests

• OPEN or the default-selected application SHALL be in charge of checking whether the requirements respective to the Privacy Level, i.e. the GPP and SPP declared by the application at registration time, are verified by the Host during the transaction.

• Each application on-board the platform SHALL control internal requests (i.e. sharing interface) coming from any other application before delivering a handle (i.e. shareable interface object) or passing any assumed privacy-sensitive data. The assessment of privacy-sensitive quality is out of scope of the present requirements and MAY vary according to the use case and the issuer’s policy.



[R9] Requirement for Application Registration

The platform SHALL allow for application registration with reference to a GPP, an SPP; that is, a protection mechanism.

Each application on card MAY register with both an SD and an applicable “protection mechanism” (see section B.12). Such a protection mechanism may be a GPP or an SPP. Usually the handling of the cryptographic protocols assumed by these mechanisms are undertaken by an SD, therefore to allow for maximum re-use of existing interfaces, the protection mechanism SHALL fit with existing GlobalPlatform entities (SD, CSD, Global Service, etc.). The protection mechanism MAY become a Global Service if it caters to all the applications on-card.

[R10] Requirement for Application Data Management

In addition to requirement series [R8], an application (e.g. a Privacy-enabler laid on top on the platform described in this document) may host privacy-sensitive data in containers; if so, these containers SHOULD be protected with access rules, see section B.13.

[R11] Requirement for Privacy-Sensitive Data Handling

The Application Provider may generate data at runtime or may host data that is likely to infringe the privacy requirements defined in this document. The very nature of such data being out of scope of Privacy Manager control, the Application Provider SHALL ensure that these data are securely hosted by the application and under appropriate security rules that MAY be GPP, SPP, or any relevant access rules (see requirement [R10]). That is, in addition to GPP and SPP, the application MAY use further security conditions to control access to its application-specific privacy-sensitive data.

[R12] Requirement for Multiple Privacy Levels in Multi-Application Context

If the card hosts applications with different Privacy Levels, the OPEN SHALL ensure that no privacy breach will occur if these applications are used in parallel.

[R13] Requirement for the Follow-up of Current State of Authentication

During the execution of GPP and SPP, an application SHALL be able to obtain the current state of authentication. This state MAY be privacy protocol dependent (see section B.14).



6 Use Cases The following use cases were considered in developing the requirements outlined in this document:

• A multi-application privacy-enhanced ID card implementation

A platform featuring the requirements of this document can be exported, i.e. embedded on a variety of devices, for different purposes (eHealth; Smart Metering; multiple secure elements in one mobile device, such as a UICC, an e-SE, and a µSD).

• Remote management of the privacy level

• Remote management of the GPP

• Remote management of the SSP



Annex A Publications on Privacy (Informative) This annex gathers a non-exhaustive list of communications, directives, or legal acts on privacy.

Table 6 provides a list of European legal acts related to privacy. This list is descriptive only and not restrictive; other country-specific regulations/legislations may apply as well.

Table 6: EU Legal Acts on Privacy (as of July 2012)

Legal Act Scope

Directive 1995/46/EC Protection of individuals regarding the processing of personal data and on the free movement of such data

Regulation (EC) 45/2001 on the protection of individuals with regard to the processing of personal data by the Community institutions and bodies and on the free movement of such data

Commission Decision 2001/497/EC

on standard contractual clauses for the transfer of personal data to third countries, under Directive 95/46/EC

Directive 2002/58/EC concerning the processing of personal data and the protection of privacy in the electronic communications sector (Directive on privacy and electronic communications


on standard contractual clauses for the transfer of personal data to processors established in third countries, under Directive 95/46/EC


amending Decision 2001/497/EC as regards the introduction of an alternative set of standard contractual clauses for the transfer of personal data to third countries

Directive 2006/24/EC on the retention of data generated or processed in connection with the provision of publicly available electronic communications services or of public communications networks and amending Directive 2002/58/EC

COM(2007) 228 final on Promoting Data Protection by Privacy Enhancing Technologies (PETs)

COM(2007) 87 final on the follow-up of the Work Program for better implementation of the Data Protection Directive

COM(2012) 10 final 2012/0010 (COD)

on the protection of individuals with regard to the processing of personal data by competent authorities for the purposes of prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties, and the free movement of such data

Other miscellaneous communications on privacy:

• Privacy Control Catalog, (Appendix J of Security Controls for Federal Information Systems and Organizations, NIST Special Publication 800-53, Revision 4)

• ENISA position paper, Privacy Features of European eID Card Specifications, Jan 27, 2009, Version 1.0.1, European Network and Information Security Agency

Recent bibliography:

Privacy, The Frontier of Social Evolution, by Timothy M. Jurgensen, Midori Press, Austin, Texas



Annex B Implementation Details (Informative) This annex suggests means of implementing some requirements described in section 5.4 and 5.5 respectively for the Platform and the Application. Each implementation proposal is intended to provide insight into the purpose of the requirement to which it relates but other appropriate alternatives can be adopted by the Card Committee whenever relevant.

B.1 Privacy Level Definition

A bitmap representation is appropriate to define the Privacy Level features. Once the categories of privacy levels are determined (based on the issuer’s needs related to a platform), each category may be populated by privacy properties (as illustrated in Table 7). The combination of privacy properties can be implemented by appropriate crypto-suites referred to by unique Object Identifiers that in turn comprise the GPP and/or SPP assigned to an application.

Table 7: Privacy Level Definition across Privacy Properties (Informative)

Example of Privacy Level (per Physical Interface and Card LCS) Privacy Property Basic Enhanced Paranoid

Untraceability

Unlinkability

Selective Disclosure

Usage Confidentiality

Pseudonym

Forward Secrecy

Limited Use

Predicate Computation

Trusted Third Party Disclosure

Revocation

Secure Messaging

B.2 Privacy Level Retrieval

Before inter-application communication and particularly before data exchange on a privacy-by-design platform, the privacy level of the calling application should be discoverable and exposed to the called application.

The Privacy Level MAY be described as a bitmap returned in response to a getPrivacyLevel() function implemented by the instance controlling the calling application. (See section B.10.)



B.3 Control of Intrusive SELECT Figure 5 – Existing Control of Intrusive Selection of an Application

Figure 6 – Proposed Control of Intrusive Selection of an Application

Host APDU interface

Default-selected (I)SD

(privacy-enabled) or OPEN

GP APIApplication

SELECT RESPONSESW1SW2=’69XY’

SELECT (AID)

getAID()

GPRegistryEntry

isAssociated()

SD Hosting Security

Configurations

getSecConfig()

getPrivacyLevel()

optional



B.4 Security Configuration Format

• The Sec_Config container MAY be structured as a constructed Data Object.

• Sec_Config SHOULD contain the SecurityInfos data according to TR_SAC [TR SAC] clause 3 along with OPTIONAL indication of the application AID. Whether the AID relating to the Security Configuration is present within this Security Configuration Data Object depends on the Privacy Level.

• The Privacy Level MAY itself be part of the Sec_Config DO, i.e. incorporated as an additional attribute within the Sec_Config definition (to be defined).

• Sec_Config ASN.1 definition MAY conform to the following:

Sec_Config ::= SEQUENCE { appAID AID OPTIONAL, securityInfos SET OF SecurityInfo }

SecurityInfo ::= SEQUENCE { protocol OBJECT IDENTIFIER, requiredData ANY DEFINED BY protocol, optionalData ANY DEFINED BY protocol OPTIONAL }

AID::= [APPLICATION 15] OCTET STRING

• Sec_Config MAY preferably be returned as a DER-encoded contents to the Host.

• Sec_Config container MAY be extended with further OPTIONAL items (e.g. application’s Privacy Level indication).

B.5 Privacy Levels and Registration Process

Figure 7 describes the proposed registration model allowing for privacy level declaration whenever an application is associated with a Security Domain. Privacy Levels are values only applicable to applications associated with the same Security Domain. Consistency of Privacy Levels may vary between different Security Domains on the same platform depends on Issuer’s policy.



Figure 7 – Privacy Levels and Registration Model



B.6 Personalization and Retrieval of Sec_Config Container

• A GET DATA APDU command with a general reference template (ref. ISO/IEC FDIS 7816-4:2012 [7816-4 FDIS]) MAY retrieve the Sec_Config.

The general reference template is generic: It allows pointing to a DO, a file, a record in a file, or a data string in a file.

• In order to prevent a privacy breach, a GET DATA command in clear (without Secure Messaging) SHOULD only be allowed to retrieve the Security Configuration generic to the entire platform (Global Privacy Protocol or “GPP”, i.e. Sec_Config Data Object available by default).

• GET DATA can retrieve one or more Sec_Config.

• Sec_Config MAY be encapsulated in a DO tag of applicable class if deemed useful (to be registered with ISO/IEC 7816-6 [7816-6] if applied).

• The syntax of GET DATA SHOULD be determined for all expected usage.

• A Common GET DATA command with odd INS code to retrieve Sec_Config is built according to [7816-4 FDIS], as illustrated in Figure 8.

Figure 8 – Excerpt from ISO DIS 7816-4:2010 (GET DATA with Odd INS)

B.7 Ability to Prevent AID or Sensitive Data Disclosure

GET DATA command attempts may happen to detect AID present on-card and to read their respective security configuration objects. Such data mining may allow cross-checking and traceability as well as user behavior assessment.

This potential attack MAY be prevented/minimized if deemed useful by, for example, establishing a Secure Channel through Password-Based Mechanism (i.e. PACEv2) requiring user consent with a PIN code. Depending on application purposes (e.g. transport, payment, government) and on the required transaction speed, different Global Privacy Protocols MAY be applied.

• The example approach guarantees user consent before acceptance of GET DATA command(s) seeking the security configuration DO.

• By doing so, a contactless card couldn’t reply to GET DATA unwillingly.

• A global PIN/password MAY be shared by all applications on-card to perform the Global Privacy Protocol.



Figure 9 – AID Protection against Unauthorized Disclosure

This AID protection MAY be implemented as follows:

• A global security configuration DO representing the Global Privacy Protocol (GPP) for the entire card is needed.

• This GPP MAY set the crypto-suite for a preliminary protocol involving user consent.

• Local security configuration DO(s) representing Specific Privacy Protocols can apply to on-card applications.

• AID discovery MAY be performed by the Privacy Manager thru parameters conveyed in a security command APDU (see requirement [R4.2] for details).



B.8 Recommended Generic Sequence

To prevent AID traceability, the following sequence MAY be employed:

1. Optionally, the Host MAY send a GET DATA with reference to the GPP (i.e. SC_DO available by default). The retrieval of GPP SC_DO is OPTIONAL and MAY be skipped by the Host if the global security measures of the platform are known.

2. If step (1) is applied, the default-selected application (e.g. ISD) delivers the SC_DO that is generic to the platform and that does not disclose any crypto-suite that could be related to any of the applications. There MAY be several crypto alternatives proposed by this platform-generic SC_DO (e.g. DH, ECDH, RSA, ECDSA, a variety of key lengths, Hash algorithms, ciphering 3DES, AES, a variety of mapping, a variety of paddings, etc.); this SC_DO represents the platform’s Global Privacy Protocol (GPP).

3. The Host is either capable of achieving the security mechanism described in GPP or not. If not, the transaction is rejected by the card without any further exchange. The GPP requirements reflect the Privacy Level to which the platform belongs (currently “Basic”, “Enhanced”, or “Paranoid”).

4. The Host does one of the following:

4.a Sends an enciphered SELECT [by name] then a GET DATA with reference to the specific requirements (SC_DO corresponding to SPP) from the targeted application; see Figure 10.

or

4.b Establishes a security context that is known beforehand: Host sends a security command (see Figure 11, e.g. MSE SET with parameters allowing the default-selected application to relate them to a given unique application on-card; these parameters can be algorithm reference, key reference, or certificate field exposing the role of the Host (e.g. part of a Card Verifiable Certificate). This approach remains ISO compliant.

5. Once the link to the application AID is made by the default-selected application, the latter MAY seek with GPRegistryEntry for the SD associated with the target-application, then MAY retrieve the Privacy Level indicator and/or the SPP SC_DO (Specific Privacy Protocol data object) from the SD in order to check whether the requirements were fulfilled by the Host before allowing the transaction to go ahead. (That is, if the Privacy Level requires a GPP to be applied whereas the Host directly sent a security command implicitly addressed to a given application without performing the GPP, the default-selected application MAY reject any further incoming command from the Host.)

6. If step (5) is achieved correctly, the commands from the Host are handed on by the default-selected application to the appropriate targeted application.

7. The SD associated to the application will then proceed with the SPP requirement. Once either the explicit or implicit SPP requirements are fulfilled, the actual transaction can start.



Figure 10 – Starting a Privacy-Enabled Transaction / Option 1



Figure 11 – Starting a Privacy-Enabled Transaction / Option 2



B.9 Personalization-dependent Retrieval of Sec_Config Container UC1 Figure 12 – Diagram Applying to Use Case 1

The default-selected SD returns the Sec_Config related to the application named within the GET DATA command. This approach exposes the AID and as such MAY be forbidden by some Privacy Levels.

B.10 Personalization-dependent Retrieval of Sec_Config Container UC2

• A new entry point in the SecureChannel shareable interface MAY be dedicated to the retrieval of the Sec_Config denoted by application name:

For example:

public short getSecurityConfig(byte[] baBuffer, short sOffset, javacard.framework.AID appAID)

with parameters:

baBuffer: The byte array where Sec_Config is to be stored

sOffset: The offset in baBuffer at which to start the Sec_Config bytes

javacard.framework.AID: The application for which Sec_Config is requested

returns:

short: sOffset + length of Sec_Config

• A new entry point in the SecureChannel shareable interface MAY be dedicated to the retrieval of the Privacy Level (e.g. bitmap structure). Alternatively, the Privacy Level MAY be part of the Sec_Config Data Elements (see section B.4) and retrieved along with the Sec_Config.



Figure 13 – Diagram Applying to Use Case 2

• Alternatively, a new entry point MAY be envisioned in the GPRegistryEntry shareable interface.

B.11 Privacy Level Verification

As a security measure, the sharing mechanism SHOULD require Privacy Level verification as a pre-condition.

For example:

• Privacy Level MAY be considered as a specific Privilege. This option entails an extension (as using RFU bits of third Privilege byte).

• Verification of the Privacy Level Privilege MAY be done through the GPRegistryEntry interface, allowing an application to verify whether a Privacy-policy Privilege is registered in the GPRegistryEntry of another application (using the commands shown below). This option MAY require an extension of the Privilege number (ref. [GPCS] Table 6-1).

public short getPrivileges (byte[] baBuffer, short sOffset)

public boolean isPrivileged(bPrivilege)



B.12 Application Registration

The platform MAY embed several GPP in order for applications to register with their preferred GPP. Accordingly, the privilege list (as per [GPCS] Table 6-1) MAY be expanded with further Privilege(s) denoting, for example:

1. The GPP (or Global Privacy Protocol) privilege attached to the application and indicated during the INSTALL [for install] command

2. The physical interface-dependent SPP privilege

3. The life cycle state dependent SPP privilege

4. A timing requirement privilege (in order to apply the most time efficient GPP with the application)

Section B.5 illustrates the registration model for the Privacy-Enabled platform.

Figure 14 – Example of Physical Interface Dependencies and Registration of Application Model

• During the installation of an application or during the registry update for an already installed application, an application MAY be assigned the Global Privacy Protocol (GPP) privilege which means that it will benefit from and mandates the execution of the GPP service by the default-selected application as part of its privacy policy. Accordingly, the Global Privacy Protocol parameters shall be recorded in the GlobalPlatform Registry entry for this application.

• If an application is registered with a GPP and the GPP security measures are not executed properly by the Host, the default-selected application shall reject the transaction with this Host.



• An application MAY register with a physical interface-dependent Specific Privacy Protocol (SPP) privilege which means that the SPP crypto suite to be applied will depend on the electrical interface, i.e. contact/contactless.

• An application MAY register with a life cycle state-dependent SPP privilege which means that the SPP crypto suite to be applied will depend on the application life cycle state.

For information, [7816-4 FDIS] defines in its clause 7.4.10 and 7.4.11 how security attributes can be implemented in order to be physical interface and life cycle state dependent.

B.13 Application Data Management

In addition to requirement series [R8], an application (e.g. a Privacy-enabler laid on top on the platform described in this document) MAY host privacy-sensitive data in constructed data object container(s) protected by control parameters with access rules according to [7816-4 FDIS]. These access rules MAY encode GPP and/or SPP as security conditions controlling access to the aforementioned data.

Note: Privacy-sensitive data denotes data that may expose the user to traceability or linkability risk if disclosed to the outside world.

B.14 Application Access to Current Security Status

An application needs to know the state – including the achieved level of authentication – of the used authentication protocol while performing an authentication.

For example, a passport authentication consists of the following steps:

1. SAC (Supplemental Access Control)

2. EAC (access rights I)

3. EAC (access rights II)

Before performing any authentication, no data is accessible to the outside world. After step 1, less sensitive data could be available, while after step 2 and step 3. depending on the supplied access rights, different data groups could be retrieved by the terminal.

To enable this use case, the application needs to know the current state of authentication. For this purpose, an interface shall be available to be used by an application that may want to know the current state of authentication during the execution of either a GPP or an SPP. An extension of SecureChannel API may be envisioned or alternatively the design of a new API.