identification and authentication tokensdecockd/slides/20190606...2019/06/06 · identification...

eID Security

Danny De Cock

KU Leuven ESAT/COSIC

Slides: www.godot.be/slides

http://www.godot.be/slides

Identification & Authentication Chips & Tokens

◼ Identification

Requires passive interaction

◼ Visually – Eyes

◼ Wireless – RFID

◼ Authentication

Requires active interaction

◼ Challenge-response

◼ Approve actions

Knowledge, biometry

◼ Chip

Tamper evident device

◼ Identity verification

Physical identification

◼ Opening bank account

◼ Access control

◼ Electronic transactions

2-factor authentication

◼ SSL/TLS

◼ Control sign/file access

PIN, fingerprint, iris,…

◼ Smartcard = Token

Advanced/qualified

signatures

© K.U.Leuven ESAT/COSIC, Danny De Cock 36 June 2019

Signature Types – EU Directive 1999/93/EC

Electronic Signatures

Advanced Electronic SignaturesArticle 2.2 (PKI technology)

Qualified Electronic Signature

+Annex I: Q-Cert

+Annex II: Q-CSP

+Annex III: SSCD

Article 5.1 (identification/enrolment)

E.g., email footer

E.g., digital signature

E.g., digital signature

combined with

qualified certificate


EIDAS & GDPR

◼ eIDAS = electronic IDentification And electronic trust Services Key enabler for secure cross-border electronic transactions

Central building blocks of the Digital Single Market

◼ Formal EIDAS: Regulation 910/2014 on electronic identification and trust services for

electronic transactions in the internal market builds on EU directive 1999/93/EC on electronic signatures

GDPR: General Data Protection Regulation 2016/679 – replaces Data Protection Directive 95/46/EC

◼ EIDAS Focuses on EU Milestone to provide predictable regulatory framework

Enable secure and seamless electronic interactions

Between businesses, citizens, public authorities

Aims to increase effectiveness of ◼ Public and private online services

◼ eBusiness

◼ Electronic commerce


Country Details

◼ Austria – middleware based – in use Government-issued Burgerkarte

EID + mobile id open and usable by anyone

No citizen identifier included in certificate

◼ Belgium – in use Government-issued eID card

EID usable by anyone, authentication + non-repudiation

Citizen identifier included in certificate

◼ Denmark – in use Non-government-ussued eID cards

Advanced eGovernment, outsourced to private sector

◼ Estonia – in use Government and privately-issued eID cards (bank cards), mutual

recognition

Very pragmatic solution-centered mentality, eID + mobile ID

◼ Finland – in use Government-issued eID cards: FINeID, TUPAS (mobile)

Pioneer in European eID cards

◼ France No eID cards in the field

Low-level userid/password system in place for certain sectors

Prepared for eID card solutions for national eID, but rejected

◼ Germany – middleware based Government-issued eID

Very strictly regulated

◼ Greece ERMIS Portal – in use

National ID – in development

◼ Hungary eSzemelyi, smartcard, in use

◼ Ireland MyGovId, web login, in use

◼ Latvia eParaksts, smartcard, in use

◼ Lithuania National ID, in use

◼ Luxembourg Government and privately issued eID cards coexist

Hybrid system:◼ Privately issued eIDs usable for government + private sector

◼ Government eID usable for eGovernment

◼ Netherlands DigiD – national eID scheme for citizens, in use

eRecognition – national eID scheme for businesses, in use

Idenssys – developed

◼ Poland National ID, smartcard, in use

◼ Portugal Government-issued eID

EID card + mobile ID

◼ Romania National ID, smartcard, in development

◼ Slovakia National ID, smartcard, in use

◼ Slovenia uPrava, certificates, in use

◼ Spain Government and privately issued eID cards coexist

Mandatory eID card, considers mobile ID

Also supports different userid/password systems for eGovernment

◼ Sweden Government and privately issued eID cards coexist

◼ United Kingdom No plans for national eID cards

Only privately-issued identification is possible using userid/password


EIDAS – Eat your own Dog Food

◼ Connecting Europe Facility (CEF) building

blocks

eID

eDelivery

eInvoicing

eSignature

eTranslation


What does EIDAS regulate?

◼ EIDAS Ensures that people and businesses can use their

national eID scheme to access public services in other EU countries where eIDs are available

Creates European internal market for electronic Trust Services (electronic signatures, electronic seals, time stamps, electronic delivery services and web authentication)◼ Works across borders and with same legal validity as natural way

of interaction with services, businesses and citizens

◼ Goal: Provide safe way for users to conduct business online

Both signatory and relying party have increased confidence security across Member State borders


What is a Smart Card?

◼ Secure portable device

◼ Protected piece of hardware

◼ Contains and handles sensitive data◼ transactions

◼ electronic cash

◼ identity / healthcare profile

◼ Contains secret codes and keys

◼ Performs cryptographic computations for◼ authentication / digital signatures

◼ confidentiality by decryption

◼ key management protocols

◼ data protection


The Smart Card...

◼The smart card stores electronic data and

programs in a protected file system

Protection by advanced security features

Tamper evidence

◼Several types of smart cards

Contact◼ Memory cards

◼ Microprocessor cards

Contact less◼ RFID chips


1 March 2007

Contact Smart Cards

Communication through electrical contacts

Credits: Gemplus (FR)116 June 2019

1 March 2007

Contactless Smart Cards

Communication over the air

Credits: Gemplus (FR)126 June 2019

Typical Identification Tokens

RFID-based Passport

Contactless Identification

Anti-cloning

RFID-Chip Smartcard

Access Control

Smartcard

eID Card

Contact-based

Strong Authentication

RFID-Tag

Product identification

One-time Deactivation


Citizen’s Paper Token – Level 2


eID – Level 3 + 4



eID Card = 4 Functions

◼ Non-electronic

1. Visual Identification

◼ Electronic

2. Digital identification

◼ Data capture

3. Prove your identity

◼ Authentication signature

4. Digitally sign information

◼ Non-repudiation signature

eID Card Content

ID ADDRESS

Authentication

Signature

PKI Citizen Identity Data

RRN = National Register

Root CA

CA

RRN

RRN SIGNATURE

RRNSIGNATURE

140x200 Pixels8 BPP3.224 Bytes



ePassports = 3 Functions

◼ Non-electronic

1. Visual Identification

◼ Electronic

2. Digital identification

◼ Data capture

3. Document authenticity

◼ Anti-cloning


Visual Identification – Passports

◼ Physical Document – Booklet Data page

◼ Name, first name, gender

◼ Digital photo, nationality

◼ Place of issue, birth

◼ Document number, validity

Machine-Readable Zone◼ Document type, number, validity

◼ Name, gender, birth date

◼ Checksums

Physical security features

◼ Digital Document – RFID Chip Storage media

Cryptographic coprocessor

Biometrics

Cryptographic security features

◼ ICAO standardizes (e)Passports

Passport


ePassports Security Requirements

◼ Unforgeability

Digital content of the chip

◼ Copy protection

Copies of the digital document must be

detectable

◼ Access control

Unauthorized reading of personal data must be

prevented


ICAO Logical Data Structure (LDS)

◼ ePassport Application DG1: Machine readable zone (MRZ)

(mandatory)

DG2: Facial Image (JPEG encoded)(mandatory)

DG3: Fingerprint (no specific encoding)(optional)

DG4: Iris (no specific encoding)(optional)

DG5: Displayed portrait (JPEG encoded)(optional)

DG6: RFU

DG7: Displayed signature (JPEG encoded) (optional)

DG8: Data features(optional)

DG9: Structure features(optional)

DG10: Substance features(optional)

DG11: Additional personal details(optional)

DG12: Additional document details(optional)

DG13: Optional details(optional)

DG14: RFU

DG15: Active Authentication Public Key(optional)

DG16: Persons to notify(optional)

DG17: Automated Border Clearance Details (optional)

DG18: Electronic Visas(optional)

DG19: Travel Record Details(optional)

SOD: Document Security Object(mandatory)◼ PKCS#7 signed data

◼ Protects integrity of all DGs

DG = Data Group

SOD =

RFU = Reserved for Future Use

Visual Aspects of a Belgian eID card

Front:

◼ Name

◼ First two names

◼ First letter of 3rd name

◼ Title

◼ Nationality

◼ Birth place and date

◼ Gender

◼ Card number

◼ Photo of the holder

◼ Begin and end validity dates of the card

◼ Hand written signature of the holder

Back side:

◼ Place of delivery of the card

◼ National Register identification number

◼ Hand written signature of the civil servant

◼ Main residence of the holder (cards produced before 1/1/2004)

◼ International Civil Aviation Organization (ICAO)-specified zone (cards produced since 1/1/2005)


Visual Security Mechanisms

◼ Rainbow and guilloche printing

◼ Changeable Laser Image (CLI)

◼ Optical Variable Ink (OVI)

◼ Alpha gram

◼ Relief and UV print

◼ Laser engraving

12345678


eSecurity – Certificates bind people to keys

◼ How does Bob know that a public

key belongs to Alice?

◼ Belgian government issues a

statement “this public key belongs

to Alice”

Statement is called a “certificate”

One certificate per key pair

Private key can only be used by

certified entity


Certificates for

Government web servers,

signing citizen files, public

information,…

Card Administration:

update address, key

pair generation, store

certificates,…

eID Certificates Hierarchy

2048-bit

RSA

2048-bit

RSA

2048-bit

RSA



Belgian eID card: Signing Keys & Certificates

◼ 2 key pairs for the citizen: Citizen-authentication

◼ X.509v3 authentication certificate

Advanced electronic (non-repudiation) signature◼ X.509v3 qualified certificate

◼ Can be used to produce digital signatures equivalent to handwritten signatures, cfr. European Directive 1999/93/EC

◼ 1 key pair for the card: eID card authentication (basic key pair)

◼ No corresponding certificate: RRN (Rijksregister/Registre National) knows which public key corresponds to which eID card


Typical Token Life Cycle

Token

Request

Token

Personalization(Printing, Embossing, Engraving)

User Registration

Token

Delivery

Token

Initialization(Key generation)

Token

Renewal

Token

Reactivation

Token

Expiration

Token

Deactivation

Token

Activation

12

3

4

5

6

7

eID Card Issuing Procedure (1/2)

(8)

(9)

(10b)

Citizen PIN & PUK

Certification Authority (CA)

Municipality

National

Register (RRN)

Card Personalizer (CP)

Card Initializer (CI)

(0)

(3)

(4)

(5)

(7)

(6)

(13)

(12)

(11)

Citizen

(10a2)

(10a1)

(2)

(1)

Face to face identification

286 June 2019

eID Card Issuing Procedure (2/2)

0: Citizen receives a convocation letter or takes the initiative

1: Visit municipality with photo

2: Formal eID request is signed

3,4: CP receives eID request via RRN

5: CP prints new eID card, CI starts on-card key pairs generation

6: RRN receives part of the eID card activation code PUK1

7: CA receives certificate requests

8: CA issues two new certificates and issues new CRLs

9: CI stores these certificates on the eID card

10a: CI writes citizen data (ID, address,…) to the card, deactivates the card

10b: CI sends invitation letter with citizen’s PIN and activation code PUK2

11: Citizen receives invitation letter

12: Civil servant starts eID card activation procedure

13: eID card computes a signature with each private key, CA removes certificates from CRL


The Belgian eID card…

◼ Uses On-board key pair generation Private keys cannot leave the eID card

Key pair generation is activated during the initialization of the eID card

◼ Uses JavaCard technology

◼ Can be used using software/middleware – free of charge – provided the Government

◼ Can only be managed by the Belgian government Citizen identity/address data is read/write for the National

Registry

eID card refuses update attempts from other parties than the government


Current Versions

◼ eID card valid for 10 years

All cards issued since 1 March 2014

◼ Used to be 5 years

Today: Citizen certificates with 2048-bit RSA key pairs

◼ Used to be 1024-bit RSA

Tomorrow: Citizen certificates with ECDSA

Cards will be used more – increased uptake

◼ More prone to physical damage to the card & chip

◼ Migration with other cards?

Social Security Identification card?

Loyalty cards?

Public transport?© K.U.Leuven ESAT/COSIC, Danny De Cock 316 June 2019

Citizen Certificate Details

Qualified certificateVersion: 3 (0x2)

Serial Number:10:00:00:00:00:00:8d:8a:fa:33:d3:08:f1:7a:35:b2

Signature Algorithm: sha1WithRSAEncryption (1024 bit)

Issuer: C=BE, CN=Citizen CA

Not valid before: Nov 12 22:41:00 2003 GMT

Not valid after: Nov 12 22:41:00 2008 GMT

Subject: C=BE, CN=Sophie Dupont (Signature), SN=Dupont, GN=Sophie Nicole/serialNumber=60050100093

Subject Public Key Info:RSA Public Key: [Modulus (1024 bit): 4b:e5:7e:6e: … :86:17,

Exponent: 65537 (0x10001)]

X509v3 extensions:Certificate Policies:

Policy: 2.16.56.1.1.1.2.1

CPS: http://repository.eid.belgium.be

Key Usage: critical, Non Repudiation

Authority Key Identifier: [D1:13: … :7F:AF:10]

CRL Distribution Points:URI:http://crl.eid.belgium.be/eidc0002.crl

Netscape Cert Type: S/MIME

Authority Information Access: CA Issuers - URI:http://certs.eid.belgium.be/belgiumrs.crt

OCSP - URI:http://ocsp.eid.belgium.be

Qualified certificate statements: [00......F..]

Signature: [74:ae:10: … :e0:91]

Authentication certificate

Version: 3 (0x2)

Serial Number:10:00:00:00:00:00:0a:5d:9a:91:b1:21:dd:00:a2:7a

Signature Algorithm: sha1WithRSAEncryption (1024 bit)

Issuer: C=BE, CN=Citizen CA

Not valid before: Nov 12 22:40:52 2003 GMT

Not valid after: Nov 12 22:40:52 2008 GMT

Subject: C=BE, CN=Sophie Dupont (Authentication), SN=Dupont, GN=Sophie Nicole/serialNumber=60050100093

Subject Public Key Info:RSA Public Key: [Modulus (1024 bit): cf:ca:7a:77: … :5c:c5,

Exponent: 65537 (0x10001)]

X509v3 extensions:Certificate Policies:

Policy: 2.16.56.1.1.1.2.2

CPS: http://repository.eid.belgium.be

Key Usage: critical, Digital Signature

Authority Key Identifier: [D1:13: … 7F:AF:10]

CRL Distribution Points:URI:http://crl.eid.belgium.be/eidc0002.crl

Netscape Cert Type: SSL Client, S/MIME

Authority Information Access:CA Issuers - URI:http://certs.eid.belgium.be/belgiumrs.crt

OCSP - URI:http://ocsp.eid.belgium.be

Signature: [10:ac:04: … :e9:04]


Comparing eID and Bank Card

◼ Citizen Identification

◼ Data Capture

◼ Strong Authentication Authentication

Digital Signatures

eID Card

◼ Access Control Container Park, Swimming

Pool, Library,…

◼ Customer Identification

◼ Data Capture

◼ Authentication Electronic Transactions

ATM Transactions

Electronic Purse

◼ Access Control Self-Bank


eID & Bank Cards Crypto

◼ 2 Citizen Key Pairs Citizen-authentication

◼ X.509v3 authentication certificate

Advanced electronic (non-repudiation) signature◼ X.509v3 qualified certificate

◼ Can be used to produce digital signatures equivalent to handwritten signatures, cfr. European Directive 1999/93/EC

◼ 1 eID Card-specific Key Pair eID card authentication (basic

key pair)◼ No corresponding certificate:

RRN (Rijksregister/Registre National) knows which public key corresponds to which eID card

◼ Transactions with vending machines, ATMs, phone booths, parking meters,… MAC-based use chip card

◼ Home banking MAC-based

◼ Family of secret master keys

◼ Uses chip card or Digipass

◼ MAC authenticates login, transaction

PKI-based◼ Closed user group PKI

◼ Key pair stored in key file or smart card

◼ Banking organization issues certificate

◼ Digital signature authenticateslogin, transaction


Secure eID & Banking Functionalities

eID Credit Debit Digipass Mobile

Visual functions

◼ Identification ✓ ✓/

◼ Card holder signature ✓ ✓ ✓

◼ Card holder picture ✓ Some ✓

Electronic functions

◼ Data Capture ✓ ✓ ✓ ✓

◼ Physical Access Control ✓ ✓ ✓ ✓

◼ Challenge Response Authentication ✓ ✓ ✓

◼ Transaction Authentication ✓ ✓ ✓ ✓ ✓

◼ Authentication Requires PIN PIN PIN PIN Finger/PIN/-

◼ Purse Loading NA NA PIN NA ✓

◼ Use Card Reader ✓ ✓ ✓ Some Rare

Cryptographic functions

◼ Digital Signatures ✓

◼ MAC Calculation ✓ ✓ ✓

◼ En/Decryption ✓


eID Security

Using eID cards in

Applications


Typical Smartcard Architecture

Smartcard

ReaderPIN Pad

DisplayLook

Feel

Citizen’s Computer SystemBrowser

ISO

7816

eID Middleware

PCSCKeyboard

Mouse,…

Using an Authentication Certificate

1. The web server Alice visits sends a random challenge to her browser

2. Alice confirms she wants to log in on the web site by presenting her PIN to her eID card and authorizes the signature generation

3. The browser sends the hashed challenge to Alice’s eID card to sign it

4. The browser retrieves the signature and Alice’s certificate from her eID card

5. The web server receives Alice’s signature and certificate

We

b S

ite

Bro

wse

r

eID

card

Citiz

en

5.

1.

4.

2. PIN

Case study: Alice visits a website which uses client authentication

3.


Signature Generation/Verification

Hash

1

5

86

Signature

Verification

Engine

Bob

9

12

11

11

1. Compute hash of message

2. Prepare signature

3. Present user PIN

4. SCD generates digital signature

5. Collect digital signature

6. Retrieve signer certificate 10. Compute hash on received message

7. Verify the certificate’s revocation status 11. Verify digital signature

8. Retrieve public key from signer certificate 12. SVD outputs ‘valid signature’

9. Retrieve digital signature on the message or ‘invalid signature’

Beware – Bob should validate Alice’s certificate – Beware

P

4

Signature

Creation

Engine

PIN

32

10

11

7Alice

OCSP

CRL

Hash


Signature Generation Steps

Alice’s application

1. Calculates the cryptographic hash on the data to be signed

2. Prepares her eID card to generate an authentication signature or to generate a non-repudiation signature

3. Alice presents her PIN to her eID card

4. Her card generates the digital signature on the cryptographic hash

5. The application collects the digital signature from her eID card

Bob receives an envelope with a digitally signed message and a certificate

hash

1

5

AliceP

4

Signature

Creation

Engine

PIN

32


Signature Verification Steps

Bob

6. Retrieves the potential sender’s certificate

7. Verifies the certificate’s revocation status

8. Extracts Alice’s public key from her certificate

9. Retrieves the signature from the message

10. Calculates the hash on the received message

11. Verifies the digital signature with the public key and the hash

12. If the verification succeeds, Bob knows that the eID card of Alice was used to produce the digital signature

“The message comes from Alice” is a business decision

86

Signature

Verification

Engine

Bob

9

12

11

11

hash10

11

7

OCSP

CRL


Secure PIN Entry = Secure eID

◼ Advantages of a secure PIN entry device over a simple smart card reader: Citizen’s PIN cannot easily be intercepted by a PC

application

◼ Simply relying on a secure PIN entry device is not enough: The text displayed on the device during a “Verify PIN”

command is usually specified by the PC application

WYSIWYS: The cardholder does not know which data and commands are sent to the card

◼ Accepting a cardholder PIN through the PC keyboard should be avoided!!

WYSIWYS: what you see is what you sign


Authentication Interfaces

◼ Electronic functionality of smart cards

requires interface with PC

Common smart card reader

◼ MAC or signature creation requires PIN or

finger…

Popular PIN entry methods:


Trustworthiness of Authentication Interfaces

◼ Authentication of a transaction, client

authentication, digital signature,… requires a

PIN to be presented to reflect the

cardholder’s consent

Low Level of Confidence High



Using a Non-repudiation Certificate?

Alice uses her eID card to generate a non-repudiation signature on a form for Bob

1. Alice’s computer application asks her whether she wishes to digitally sign the information

2. If she approves, she inserts her eID card in the computer’s smartcard reader

3. She enters her PIN to authorize the generation of the digital signature

4. Bob receives from Alice: The form

The digital signature

Alice’s non-repudiation certificate

Alice

Bob

E.g., Contract,

Tax Declaration,

Certified Mail,…

EIDAS Regulatory Environment

◼ Focus on electronic transactions: Advanced electronic signatures

◼ Uniquely links information to its signatory, e.g., XAdES, PAdES, CAdES standards for digital signatures

Qualified electronic signature◼ Advanced electronic signature produced by secure signature creation

device (SSCD)

Qualified digital certificate for electronic signatures◼ Attestation that links a signatory to a physical person, issued by a

qualified trust service provider

Trust services provided by Trust Service Providers◼ Electronic services that create, validate and verify electronic

signatures, time stamps, seals and certificates

◼ May provide website authentication and preservation of created electronic signatures, certificates and seals


Implementing acts – Trust Services

◼ Electronic trust services Regulation 22 may 2015 specifies EU trust mark for qualified trust

services◼ Trust mark differentiates qualified trust services from other trust services to

foster confidence in and of essential online services for users to fully benefit and consciously rely on electronic services

Decision of 8 sep 2015 lays down technical specifications and formats relating to trusted lists to ensure certainty and building trust among market operators◼ Trust lists indicate the status of a service provider at the moment of

supervision

◼ Enhances interoperability of qualified trust services by validating e-signatures and e-seals

◼ Technology independent specifications of formats of advanced signatures and advanced seals to be recognized by public sector bodies and in cross-border transactions with public sector bodies in a different member state

Decision of 25 april 2016 lays down standards for security assessment of qualified signatures and seal creation devices◼ Lists standards for security assessment of qualified signatures and seal

creation devices


Implementing decision – 8 September 2015

Interesting Trusted List Qualification Extensions

◼ E.g., “SSCD support”, “Legal person as subject”, similar to KeyUsage extension in X.509 certificate

◼ Qualified service providers indicate: “QCStatement”: certificate qualified under EU Digital Signature Directive 1999/93/EC

“QCForESig”: certificate qualified for signatures under eIDAS regulation

“QCForESeal”: certificate qualified for signatures under eIDAS regulation

“QCForWSA”: certificate qualified for web site authentication under eIDAS regulation

◼ Non-qualified certificates “NotQualified”: certificate not to be considered as qualified

◼ SSCD Supported “QCWithSSCD”: private key of certificate resides in SSCD

“QCNoSSCD”: private key of certificate does not reside in SSCD

“QCSSCDStatusAsInCert”: qualified certificate specifies location of private key

◼ Qualified Signature Creation Device (QSCD) “QCWithQSCD”: private key of certificate resides in QSCD

“QCNoQSCD”: private key of certificate of qualified trust service provider does not reside in QSCD

“QCQSCDStatusAsInCert”: qualified certificate mentions location of corresponding private key

“QCSCDManagedOnBehalf”: private key resides in QSCD for which generation and management is done by qualified trust service provider on behalf of the entity whose identity is certified in the certificate

◼ Legal persons “QCForLegalPerson”: qualified certificate is issued to legal person under EU Digital Signature Directive

1999/93/EC


Implementing decision – 25 April 2016

Qualified Signature and Seal devices

◼ Electronic signature/seal creation data is held in entirely (but not necessarily exclusively) in a user-managed environment

◼ Only qualified trust service provider can manage electronic signature/seal creation data on behalf of a signatory

◼ Different security requirements and certification specifications depending if Signatory physically possesses signature creation data, or

Qualified trust service provider operates on behalf of signatory

◼ Currently, only hardware security module-based solutions can be certified No standards yet exist for certified remote products not using HSMs


Hardware Requirement

◼ Smartcards become smartcard devices Tamper-evident crypto chip

Reasonable CPU + storage

Contact interface

Visual feedback

Keypad

Smartcard slot

Biometric sensor

Contactless interface◼ RFID, Bluetooth, Infrared

Audible feedback

Large battery pack

Document type: Contract

Parties: <your name>,

abbreviated “you”, and <Louis

Cipher>, abbreviated “me”.

Scope: “you” donates “me” all

the money that belongs to

“you”, completely free of

charge.

Date: 6 June 2019.

Signed: <signature of “you”>.

Signed: <signature of “me”>.


Using Smartcard Devices

◼ Smartcard Devices need high-level operations: Digital signatures: Sign/Verify this data

◼ Input: data to be signed

◼ Internal processing: Authentication of the user

Hashing, signing, encapsulation

◼ Output: envelope with signed data

Data encryption: Decrypt this data◼ Input: encrypted data

◼ Internal processing: Authentication of the user

Decryption

◼ Output: cleartext data

◼ Strong link with DRM technology!

(DRM: Digital rights management)

1. Is it ok to decrypt

the information

contained in the file

<ciphertext.pgp>?

Y/N

2. View the

decrypted file before

sending it to

<APP>?

Y/N


Proof-of-concept with Smartphone

◼ Smartcard → Smartcard Device Device = smartcard + reader + user interface

☺ Solves all issues, but…

Not cheap…

◼ Open source implementation of JavaCard applet Functionally equivalent with Belgian eID card

http://code.google.com/p/eid-quick-key-toolset/

◼ Applied to Android phone Using secure microSD card

Exact Copy of eID card files

Same signing functions◼ eID card keys cannot be copied


Challenges & Concerns…

◼ Linking device to user

Reliable registration

◼ Impossible to implement visual security

measures

eID card contains visual security measures

◼ What about malware on phone’s OS?


Really Secure eID System Architecture

54

Back Office

HSM

Usage

Validation

App

Connector

Encrypted

Keys + Certs

User

Smartphone/Tablet

Secure App

Computer to

Authenticate,

Sign or Seal

6 June 2019

That’s it…

Contact:

- Danny De Cock

- [email protected]

mailto:[email protected]

Implementing regulation – 8 September 2015

Assurance levels of eID Schemes

◼ Low EID means with limited degree of confidence in claimed or

asserted identity of a person and with few measures in place to decrease the risk of misuse or alteration of the identity

◼ Substantial EID means with substantial degree of confidence in claimed or

asserted identity of a person and with more important measures in place to decrease the risk of misuse or alteration of the identity

◼ High EID means with higher degree of confidence in claimed or

asserted identity of a person than the substantial level and with more measures in place to decrease the risk of misuse or alteration of the identity


identification and authentication tokensdecockd/slides/20190606...2019/06/06 · identification...

Documents