eidas token - etsi · service provider establishes connection to card service provider tries to...
TRANSCRIPT
eIDAS Token
Jens BenderFederal Office for Information Security
ETSI Security Workshop
16.01.2014
Jens Bender Slide 2
In 2012 the EU Commission published a proposal for a regulation for
Electronic Identities Qualified signatures and related trust services
Currently under discussion in parliament and council
Trust Services Replaces “old” signature directive Adds seals, [documents, delivery services, website
authentication]
Electronic Identities Mutual recognition of national eIDs
COM 238“eIDAS Regulation”
Jens Bender Slide 3
eID and eSign
eID
Authentication of (some) identity information (amount of information
application dependent)
Equivalent to presentation of ID-Card in physical world
No transferable proof, verifiable only by relying party
Ephemeral – identity only verified for one moment
eSign
Legally binding transaction (contract, full identity of signer)
Equivalent to written signature
Transferable proof, verifiable by everyone
Perpetual – signature valid and verifiable in eternity (up to cryptography)
Jens Bender Slide 4
MS A
MS B
MS A
MS B
Middleware Approach Proxy Approach
STORKSecure idenTity acrOss boRders linKed
Jens Bender Slide 5
Gateway vs. End-to-End
Problems of gateways: No end-to-end relationship between citizen and service
No mutual authentication possible
Who is the data processing party? Which national law is relevant in which stage of the authentication?
The gateway is a central authentication tracker …
Secure transmission of data requires identification of the recipient
Encrypted data are encrypted for a recipient At least at Assurance Level 4 SSL is not enough
We think for Assurance Level 4 end-to-end is mandatory
Jens Bender Slide 6
eIDAS Token Project
Interoperability is easier if systems interoperate without additional interoperability layer necessary
Collaboration of ANSSI and BSI, together with industry partners (ACSIEL, DIF)
At the core: Smart Card Specification Data groups/structures, Cryptographic protocols, Interfaces Suitable for Assurance Level 4
Covering all existing use cases (to the best of our knowledge)
One (interoperable) specification covering different national deployments
Incl. emerging use cases like server signing
Jens Bender Slide 7
Principles
Privacy and Security by Design
Reuse of proven
technology
Ease of use
Interoperability
Covering different national deployment
scenarios
Modular – adaptable to
issuer's needs
Mutual authentication
Jens Bender Slide 8
Supported Deployments:No-Third-Party
No-Third-Party(General Authentication Procedure)
Direct relationship card ↔ service provider
No ID-Provider No tracking No central point of failure
ID Attributes stored on card … and only on card … some special privacy
functions (e.g. AgeVerify, Pseudonym)
Offline-capable
eIDAS Token
Service Provider
Jens Bender Slide 9
Supported Deployments:Trusted Third Party
Trusted Third Party(Enhanced Role Authentication)
Direct relationship card ↔ service provider
Attribute provider, can ... … provide attributes not
available on card … provide authorizations … information from
registers
No relationship service provider ↔ attribute provider
Card as “privacy firewall” Different from ID Provider
eIDAS Token
Service Provider
Attribute Provider
Jens Bender Slide 10
Service Provider's View
Easy to use from service provider's view
Service provider establishes connection to card Service provider tries to read attributes from card
If successful → done If not → client-middleware connects to attribute provider
(missing attributes are stored) and afterwards reconnects to the service provider
From the service provider's view it doesn't matter if attributes are coming from an attribute provider or not, the attributes
are always read directly from the card
Jens Bender Slide 11
eIDAS Token
The eIDAS token specification combines both scenarios
“Base attributes” stored on card “Extension attributes” via attribute provider Issuer decides which attributes are available as
base and/or extensions attributes
Jens Bender Slide 12
Mutual Authentication
Authentication of the service provider is necessary To securely identify the recipient of personal data To securely restrict the access rights to the necessary data
Authentication via PKI The specification uses the same PKI for all scenarios Cross-border interoperability
via cross certification Proven technology (ePassport)
CVCAIssuer A
CVCAIssuer B
DV DV DV
SP
SP
SP
SPAP
AP
Jens Bender Slide 13
Status / Way forward
Specification feature complete Common LDS (Logical Data Structure) Cryptographic protocols (including security proofs!)
ToDo Technical details (currently worked on) Conformity Tests (to be started soon) Protection Profiles (based on existing PPs) Middleware (Profile of ISO 24727)
The eIDAS Token specification allows interoperability between different national deployments without
additional interoperability layer
Jens Bender Slide 14
Available at https://www.bsi.bund.de/EN/Publications/TechnicalGuidelines/TR03110/BSITR03110.html
Comments/suggestions welcome: [email protected] / [email protected]
Jens Bender Slide 15
Contact
Bundesamt für Sicherheit in der Informationstechnik (BSI)
Jens BenderGodesberger Allee 185-18953175 Bonn
Tel: +49 (0)22899-9582-5051Fax: +49 (0)22899-109582-5051
Jens Bender Slide 16
eID and eSign
TransactionWritten
SignatureQualifiedSignature
Example banking ID-Card/eID for identification (e.g. to facilitate database query about
creditworthiness of customer) – no provable authorization
Signature/electronic signature to start actual transaction (e.g. opening of an account) – provable authorization of transaction
Identification(Authentication)
Presentation ofID-Card
Traditional
Smart cardbased eID
Electronic
TAN
Username/Password
(1-factor) (card & PIN)
Jens Bender Slide 17
Transaction
Jens Bender Slide 18
Deployment ScenariosI
No-Third-Party Trusted Third Party
eIDAS Token
Service Provider Service Provider
Attribute Provider
eIDAS Token