eID Security
Danny De Cock
KU Leuven ESAT/COSIC
Slides: 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
© K.U.Leuven ESAT/COSIC, Danny De Cock 46 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 56 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 66 June 2019
EIDAS – Eat your own Dog Food
◼ Connecting Europe Facility (CEF) building
blocks
eID
eDelivery
eInvoicing
eSignature
eTranslation
© K.U.Leuven ESAT/COSIC, Danny De Cock 76 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 86 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 96 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 106 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 136 June 2019
Citizen’s Paper Token – Level 2
© K.U.Leuven ESAT/COSIC, Danny De Cock 146 June 2019
eID – Level 3 + 4
© K.U.Leuven ESAT/COSIC, Danny De Cock 156 June 2019
© K.U.Leuven ESAT/COSIC, Danny De Cock 166 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 176 June 2019
© K.U.Leuven ESAT/COSIC, Danny De Cock 186 June 2019
ePassports = 3 Functions
◼ Non-electronic
1. Visual Identification
◼ Electronic
2. Digital identification
◼ Data capture
3. Document authenticity
◼ Anti-cloning
© K.U.Leuven ESAT/COSIC, Danny De Cock 196 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 206 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 216 June 2019
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)
© K.U.Leuven ESAT/COSIC, Danny De Cock 226 June 2019
Visual Security Mechanisms
◼ Rainbow and guilloche printing
◼ Changeable Laser Image (CLI)
◼ Optical Variable Ink (OVI)
◼ Alpha gram
◼ Relief and UV print
◼ Laser engraving
12345678
© K.U.Leuven ESAT/COSIC, Danny De Cock 236 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 246 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 256 June 2019
© K.U.Leuven ESAT/COSIC, Danny De Cock 266 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 276 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 296 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 306 June 2019
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]
© K.U.Leuven ESAT/COSIC, Danny De Cock 326 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 336 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 346 June 2019
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 ✓
© K.U.Leuven ESAT/COSIC, Danny De Cock 356 June 2019
eID Security
Using eID cards in
Applications
© K.U.Leuven ESAT/COSIC, Danny De Cock 376 June 2019
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.
© K.U.Leuven ESAT/COSIC, Danny De Cock 386 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 396 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 406 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 416 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 426 June 2019
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:
© K.U.Leuven ESAT/COSIC, Danny De Cock 436 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 446 June 2019
© K.U.Leuven ESAT/COSIC, Danny De Cock 456 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 466 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 476 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 486 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 496 June 2019
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”>.
© K.U.Leuven ESAT/COSIC, Danny De Cock 506 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 516 June 2019
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 526 June 2019
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?
© K.U.Leuven ESAT/COSIC, Danny De Cock 536 June 2019
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
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
© K.U.Leuven ESAT/COSIC, Danny De Cock 566 June 2019
Top Related