1

1 /27

eID and the principle of

Privacy by Design (PbD)

Denis PINKAS

President of DP Security Consulting SASU France

eIDAS WorkshopETSI Sophia Antipolis June 24, 2015

2 /27

• The topic of the Regulation that is addressed is :

Article 12 "Cooperation and interoperability".

• The presentation will identify user needs and privacy requirements.

• The presentation will identify the importance of the national

cultures with respect to privacy.

• The presentation will analyze how the ongoing standards address

eID, with and without the principle of privacy by design.

• In particular, it will explain how "secure elements" (SE)

allow to support pseudonyms using the mechanism of

"restricted identification" as specified in part 4 of draft EN 419 212 :

Privacy specific Protocol from TC 224 WG 16, and why

other mechanisms don't address privacy.

• An alternative approach to support the principle of

privacy by design using "secure elements" will be explained.

2

3 /27

The EU Regulation on eIDAS

Article 12 Cooperation and interoperability

1. The national electronic identification schemes notified pursuant to Article 9(1) shall be interoperable.

2. For the purposes of paragraph 1, an interoperability framework shall be established.

3. The interoperability framework shall meet the following criteria:

(a) it aims to be technology neutral and does not discriminate between any specific nationaltechnical solutions for electronic identificationwithin a Member State;

(b) it follows European and international standards,where possible;

(c) it facilitates the implementation of the principle of privacy by design;

4 /27

« Imagine a world where individuals can conduct sensitive business transactions online with reduced fear of identity theftor fraud and without the need to manage scores of usernames and passwords.

They can seamlessly access information and services from the private sector, other individuals, and the government.

When they need to assert their identity online, they can choose from a number of different types of credentials.

They can choose to obtain those credentials from a range of different identity providers, both private and public »

3

5 /27

Extract from the Introduction on page 4 from the NATIONAL STRATEGY FOR TRUSTED IDENTITIES IN CYBER SPACE

Enhancing Online Choice, Efficiency, Security, and Privacy

APRIL 2011

« The private sector will lead the development and implementation

of this Identity Ecosystem, and it will own and operate

the vast majority of the services within it ».

6 /27

A few definitions

• Identifier :– a unique and reproducible octet string used by a given entity to access to a given server.

It may or may not be a pseudonym.

• Identity attribute ≈ Personal attribute – any data which describes some attribute of an entity, e.g. an individual (different from the definition of PII).

• Security token :

– set of data signed by an identity server or by an attribute server which includes identity attributes.

4

7 /27

User’s needs and privacy requirements

User’s needs :

1. avoid using decades of identifiers and passwordsto access to web services.

2. allow the use of web services with an account, but without disclosing any identity attribute.

3. disclose any identity attribute only after the user's agreement.

Privacy requirements:

1. minimize the disclosure of identity attributes.

2. prevent web services to correlate unambiguously the information they store about different users.

3. prevent servers interacting with a client application before an access to know which Service Providers are or will be accessed by a user.

8 /27

Importance of national cultures with respect to privacy

• Some EU countries have already distributed smartcards which support authentication using PKCs. However, this allows easy correlations between the databases from different Service Providers using the content of the authentication certificates.

• The citizens of these countries either :– are not even aware of the issue,

– are aware of the issue, but don’t care, or

– are aware, do care and thus will use it as little as they can !

• However, some countries do care, in particular Germany and France, but also Austria.

• If a simple mechanism might be able fulfill both the user needs and the privacy requirements, then cultures and practices might evolve both within Europe and around the world.

5

9 /27

What is being proposed today ?

• ABC4Trust (U-Prove from Microsoft and Identity Mixer from IBM)

– Attribute-based Credentials for Trust is an EU-funded research and development project supporting privacy-preserving Attribute-based Credentials (Privacy-ABCs).

– It uses interesting crypto techniques allowing to hide some of the identity attributes contained inside a security token.

– However, any software-only solution is unable to prevent collaborative users to forward a security token belonging to a legitimate user to another user.

– ABC4Trust may be used with smartcards. However, using the current documentation, it appears that “token forwarding”is possible between collaborative users.

• STORK 2.0

– Does not support user needs n° 2 and n° 3.

10 /27

What is being proposed today ?

• ABC4Trust (U-Prove from Microsoft and Identity Mixer from IBM)

– Attribute-based Credentials for Trust is an EU-funded research and development project supporting privacy-preserving Attribute-based Credentials (Privacy-ABCs).

– It uses interesting crypto techniques allowing to hide some of the identity attributes contained inside a security token.

– However, any software-only solution is unable to prevent collaborative users to forward a security token belonging to a legitimate user to another user.

– ABC4Trust may be used with smartcards. However, using the current documentation, it appears that “token forwarding”is possible between collaborative users.

6

11 /27

What is being proposed today ?

• Draft EN 419 212 (3 rd edition):

Application Interface for secure elements used as Qualified electronic Signature (Seal-) Creation Devices.

• The 2 nd edition contained 2 parts (370 pages altogether). and was hard to read, thus the 3 rd edition now contains 5 parts (372 pages altogether) … and is as hard to read.

• It allows the use “secure elements” (SE), e.g. smartcards, for signature creation, but also for a variety of other security services, i.e. much more that the title states.

12 /27

The draft in a nutshell

Digital signature creationinstead of electronic signature creation

Digital signature verification

Authentication using an authentication certificatesupported by an “e-Sign application” !

Authentication using pseudonyms supported by an “e-Sign application” !

Data decryptionsupported by an “e-Sign application” !

The title indicates “Electronic signature creation”

but this is misleading since the true service is :

7

13 /27

Authentication using authentication certificates or using pseudonyms

• Client authentication, using authentication certificates, is described in part 5, section 6.1.

– However, this mechanism does not support the users needs 2 and 3 nor the privacy requirements 1 and 2.

• “Restricted identification”, in fact “authentication using pseudonyms”, is described in part 4, section 3.3.

– « The idea of Restricted Identification is to provide a unique and reproducible identifier to each service

or set of readers (called a "sector"), but different identifiers for different sectors ».

14 /27

Restricted Identification

• Draft EN 419 212-4 describes all the APDUs (i.e. protocols instead of an “application interface”) but another document from ISO/IEC TC JTC1/SC 17/WG 4 focuses on privacy issues:

4 th WD 19286 — Identification cards — Integrated circuit cards —Protocols and services ensuring privacy.

The good news: it pre

vents collabora

tive

users

to fo

rward

an attribute belonging to

a legitim

ate user

to anoth

er user

8

15 /27

Restricted Identification

• Draft EN 419 212-4 describes all the APDUs (i.e. protocols instead of an “application interface”) but another document from ISO/IEC TC JTC1/SC 17/WG 4 focuses on privacy issues:

4 th WD 19286 — Identification cards — Integrated circuit cards —Protocols and services ensuring privacy.

(unfortunately unrelated).

• WD 19286 has been forwarded to the ISO SC 27 WG 5 experts for comments. Two experts have provided comments.

I have provided 46 comments.

– This document allows to support pseudonyms after 27 exchanges(7.3.2.2 Protocol sequence) or identity attributes after 45 exchanges(Figure 8 — Enhanced Role Authentication).

– However, the bad news is that this mechanism does not support :

• the user’s need n° 3 (to disclose any identity attribute only after the user's agreement), nor

• the privacy requirement n° 3 (to prevent eID servers interacting with a client application before an access to know which Service Providers will be used by a user).

• WD 19286 contains two main clauses: 6 and 7 ...

16 /27

9

17 /27

P R I V A C Y W A S H I N G

18 /27

Would there be a mechanism simpler than this one ?

Since the user can only observe “ping-pong balls”, in case of an error, it will be quite hard to diagnose what is wrong.

10

19 /27

Would there be a mechanism simpler than this one ?

In French : “une usine à gaz" (i.e. a gas plant)

20 /27

Would there be a mechanism simpler than this one ?

In American : a Rube Golberg machineIn English: a Heath Robinson machine

11

21 /27

Another view of draft EN 419 212-4 : “A white elephant "

A “white elephant” is a possession whose cost, particularly that of maintenance, is out of proportion to its usefulness.

22 /27

Let us look now at a different approach supporting

the principle of privacy by design

using "secure elements"

Applying the privacy principle of “data minimization”mandates the use of pseudonyms.

Published in The New Yorker

July 5, 1993.

12

23 /27

FIDO (Fast IDentification On-line) Alliance

• FISO uses pseudonyms, with one and only one pseudonym per server.

• The protocols described in the Universal Authentication Framework(UAF) from the FIDO Alliance support pseudonyms with the creation of user accounts on every server.

See https://fidoalliance.org/specifications/download/

1 In order to create an account on a server, four messages are needed.

2 In order to authenticate to a server, four messages are needed.

Note: an optimization with two messages would be possible ...

Wouldn't be nice extending the FIDO mechanisms to allow the use of security tokens ?

1 Registration

2 Authentication

24 /27

An eID privacy-based mechanism using ICCs, pseudonyms and security tokens

• Rather than enjoying the use of new cryptographic algorithms, starting from FIDO, using privacy principles and taking advantage of ICC properties, a new eID privacy-based mechanism has been constructed.

• This eID mechanism uses “conventional” cryptographic algorithms.

• In order to prevent “token forwarding”, the use of an ICC supporting

specific requirements is mandatory for each user.

Service Provider

�

Attribute-Server

�

User + Client application + ICC

�

eID-Server

13

25 /27

Some of the advantages of this mechanism

• Usable both for the public sector (eIDAS) and the private sector.

• For every server, the ICC will store (as in FIDO – UAF):

(a) a dedicated identifier [i.e. a pseudonym] and

(b) authentication data allowing the user to authenticate to that server.

• A client application requests and pushes in a security token (i.e. a string of bits)

the identity attributes that the user has accepted to disclose.

• In order to obtain a security token from an eID-Server or from an Attribute-Server, four functional messages will be needed.

• Security tokens allow direct trust relationships. (no Pan-European Proxy Service (PEPS), as in STORK 2.0, is necessary).

• eID-Servers and/or Attribute-Servers are unable to know where the security tokens they issue will be used.

26 /27

Some of the advantages of this e-ID mechanism over draft EN 419 212

• Worldwide scalable, i.e. not limited to EU countries.

• National eID-smartcards are not mandatory, but may be used.

• The PACE protocol is only required for contactless ICCs.

• ICCs are kept ignorant of the syntax of the certificates :

all certificates are opaque to the ICCs (no use of CV certificates).

• ICCs do not contain any root key, nor self-signed certificate.

• ICCs do not need to build nor to verify any certification path.

• ICCs do not need to be administered for pseudo “CA” recognition

and for CHAT (Certificate Holder Authorization Template) objects.

Why complicate things when they can be simple ?

14

27 /27

We all want the smart card industry to be successful,

for eID (and for electronic signatures),

hence we need an ICC supporting an eID architecture simpler

than the one implicitly mandated

by the draft EN 419 212 (3rd edition)

With only four countries ready to participate, Part 4 (Privacy specific protocols) & Part 5 (Trusted eServices)

have not met the requirements for approval as a NWI on June 16, 2015.

The three other parts will be under a CEN “Unique Acceptance Procedure (UAP)".

It is effectively possible to fulfill the user needs,

the security requirements and the privacy requirements for eID

using simple protocols and a simple architecture

that will allow to establish an interoperability framework

able to support the principle of “privacy by design”.

Application developers will appreciate !