Security and interoperability
1 like585 views
The document discusses security and interoperability in electronic identification (eID) environments. It describes a federated architecture with 3 high-level actors: citizens, government, and business. The architecture is built around authoritative data sources, maximizes reuse of information, and includes an integrated user and access management system. Authentication relies on unique eID cards or tokens at different levels of assurance. Standards like XACML and SAML enable interoperability and security across sectors like eGovernment, eHealth, and eCommerce. The architecture supports flexibility, avoids data replication, and guarantees interoperability to enhance security.
Security and interoperability
- 1. Security and Interoperability Danny De Cock January 16th, 2012 Moldova E-mail: Danny.DeCock@esat.kuleuven.be Slides: godot.be/slides
- 2. Secrets of Successful eID Environments • 3 High-level actors Citizen/Customer • Different sectors – eGovernment Government Business • Collect and store data once, reuse where possible – eHealth • Make patient records available to health care service providers – eCommerce & eBusiness • Provide ability to correctly identify involved parties – Avoiding online fraud, preparing effective anti-spam measures
- 3. Secrets of Successful eID Environments • Success depends on joined forces of public and private sector – Private sector requires return on investment (ROI) • Number of contacts between a citizen and its eGovernment only does not justify huge investments – Public sector prefers eID enablers for use in public and private sector • Avoid reinventing the wheel – Need to exchange of experience with successes and *failures* – Risk of lacking focus to create interoperable solutions • Caveat: Systems focusing on any single sector are inherently incompatible with *similar* systems
- 4. Design Decisions – Basic Concepts • Federated architecture – Each sector operates autonomously – Interfaces with other sectors through bus system • Built around authoritative sources – Master copy of data is available at exactly one repository – Master copy = authoritative source • Maximal reuse of information – No data replication – Administrations cannot re-request data already available • Integrated system for user and access management – eID for all – Citizens & organizations – Autonomous management of access & use policies
- 5. Design Decisions – Benefits • Guaranteed interoperability enhances security! – Modularity respects each organization’s sovereignty • Prevents vender-lock-in – Exchanging information using standard and open protocols and data formats • Guaranteed flexibility – Modularity allows updating and following • Security standards • Good/best practices
- 6. Identification & Authentication • Unique identification of – Citizens – Professionals – Companies and other Service Providers (public and private sector) • eID for all: Authentication & Identification tokens – Federal token – eID card – Belgian citizens & foreigners – Other tokens – companies, organizations, individuals
- 7. eID Card Types Citizens Kids Aliens eID card Kids-ID Foreigners’ card
- 8. eID Card Content PKI Citizen Identity Data ID ADDRESS Authentication Signature RRN RRN Root CA SIGNATURE SIGNATURE CA 140x200 Pixels RRN 8 BPP 3.224 Bytes RRN = National Register
- 9. eID Card = 4 Functions • Non-electronic 1. Visible Identification of a person • Electronic Enabler of eServices 2. Digital identification • Data capture 3. Prove your identity • Authentication signature eFunctionality 4. Digitally sign information • Non-repudiation signature
- 10. Levels of Assurance (LoA) of Authentication • Federated identity management model – E.g., Shibboleth, Liberty Alliance, CardSpace… LoA 4+ Setting access policies (qualified plus biometric) LoA 4 Sensitive medical records (e.g. HIV), (qualified cert with smart card EAL4+) Consultant notes containing opinions. Ability to Break the Glass. Bank to bank transfers LoA 3 Patient confidential records (non- (2-factor authentication, non-qualified sensitive) cert, EAL4 smart card) LoA 2 Some Internet banking applications (one time password) System administration LoA 1 Retrieve degree certificate. Completing (uid/password, Verisign Class 1 cert) public service employment application LoA 0 Public data (no authentication)
- 11. eID – Level 3 + 4
- 12. Citizen’s Federal Token – Level 2
- 13. How to Choose a Security Level? • Responsibility of the service provider under supervision of the Privacy Commission • Based on risk assessment and depending on – Type of processing: communication, consultation, alteration,… – Scope of the service: does the processing only concern the user or also concern other persons ? – Degree of sensitivity of the data processed – Possible impact of the processing • In addition to right security level – Use of an electronic & time-stamped signature might be needed
- 14. Interoperable & Secure by Design • Mandates & authorization credentials based on open standards, e.g., – XACML – SAML • Revocation services setup by mandate manager and certification authority – OCSP – CRL • Certificates, Signatures and timestamps, e.g., – X.509 – XADES-* • Communication protocols – SSL/TLS
- 15. XAXML – Allow/Deny Service Requests… Joe Policy Enforcement Point Service Provider 6 1 Execute OK Service Y Execute Service Y Check Policy Compliance 2 5 Permit / Deny Service Request Authorization Domain 3 4 Retrieve Relevant Retrieve Policy Policies Validation Information Policy Decision Point Policy Information Policy Access Point Point
- 16. Generic Policy Enforcement Model XACML-based Action on application DENIED Policy Action on application User Enforcement PERMITTED (PEP) Application Action on application Decision Decision Request Reply Information Policy Request/Reply Retrieval Policy Decision (PDP) Information Request/Reply Policy Management Policy Administration Policy Information Policy Information (PAP) (PIP) (PIP) Manager Policy Repository Authentic Source Authentic Source Slide inspired by Frank Robben
- 17. Re-using Architecture Be-Health Social sector Non social FPS USER USER (CBSS) USER (FedICT) APPLICATIONS APPLICATIONS APPLICATIONS Authen - Authorization Authen - Authorization Authen - Authorization tication PEP WebApp tication PEP WebApp tication PEP WebApp Role Role Role Mapper XYZ Mapper XYZ Mapper XYZ Role Role Role Mapper Mapper Mapper DB DB DB PDP Role PDP Role PDP Role PAP PAP PAP Role Provider Role Provider ‘’Kephas’’ Role Provider ‘’Kephas’’ Provider DB ‘’Kephas’’ Provider DB Provider DB PIP PIP PIP PIP PIP PIP PIP PIP PIP Attribute Attribute Attribute Attribute Attribute Attribute Attribute Attribute Attribute Provider Provider Provider Provider Provider Provider Provider Provider Provider Management Management DB DB DB Management DB DB DB DB RIZIV UMAF Bailiffs XYZ XYZ Mandates XYZ VAS Mandates XYZ VAS VAS Slide inspired by Frank Robben
- 18. Conclusion • eGovernment Services are accessible – Via open standards – With strong authentication & access management • Federated system permits use of common basic services securely – Without losing any autonomy! • System allows permanent evolution – Continuously changing user & organization requirements
- 19. Food for Thought • Trust is Good – Control is Better!
- 20. Th@nk you! Danny De Cock Researcher Applied Cryptography Danny.DeCock@esat.kuleuven.be Slides: www.godot.be/slides © fedict 2011. All rights reserved
- 21. eID Card Issuing Procedure Card Personalizer (CP) Card Initializer (CI) (5) (4) (6) (10a”) (8) National Certification Register (RRN) (9) Authority (CA) (10a’) (3) (7) Municipality (2) (0) (10b) Citizen PIN & PUK (11) Face to face identification (1) Citizen (12) (13)
- 22. eID Certificates Hierarchy 2048-bit RSA 2048-bit RSA 1024-bit RSA Card Administration: Certificates for update address, key Government web servers, pair generation, store signing citizen files, public certificates,… information,…
- 23. Abstract eGovernment Ecosystem A F C Context 1 E D H G B Introducting Belgian eID Cards & eGovernment Slide 24 16 January 2012 Context 2 Context 3