180 likes | 397 Views
Secure Access Control with Government Smart Cards. Dave Engberg CoreStreet, Ltd. dengberg@corestreet.com. Road Map. Definitions Background, Motivations Authentication Options Authorization Options Futures. Authentication (AuthN) “Who are you?” Authentication factors Something you have:
E N D
Secure Access Control with Government Smart Cards Dave EngbergCoreStreet, Ltd.dengberg@corestreet.com
Road Map • Definitions • Background, Motivations • Authentication Options • Authorization Options • Futures
Authentication (AuthN) “Who are you?” Authentication factors Something you have: Physical badge/token Secret/private key Something you are: Finger / eye / voice / etc. Something you know: Password PIN Authorization (AuthZ) “Are you currently allowed to access this?” More time sensitive process Terminology
Access Control Circa 2004 • Authentication and authorization require a “database” – networked or local ACL • Users, privileges, and rules specified into database • Frequently weak authentication • No federation Access Control System Readers ID # Contactless Badge
Governments Issuing Common Cards • Homeland Security Presidential Directive – 12 • All government employees and contractors • Strongly resistant to identity fraud, tampering, counterfeiting • Can be rapidly authenticated electronically • FIPS PUB 201: Personal Identity Verification (PIV) • NIST, February 2005 • Contact + ISO 14443 contactless smart card • Three factors on card: digital certificates, PIN, biometrics • NIST SP 800-73: Interfaces for PIV • March 2005 • NIST SP 800-76: Biometrics for PIV • Draft • Japan: ISO 14443 PKI driver’s licenses in 2006
Access Control Goals • Strong authentication • Without accessing a trusted database • Inter-organizational (federated) trust • Scalable to government sizes, locations • Flexible authorization • Securely determine current privileges • Support federated, offline use cases
PRO: Unique and unambiguous Serial number of legitimate card cannot be modified CON: No cryptographic or protocol protections against spoofing AuthN: Card Serial Number “What’s your manufactured serial number?” “0x18a66e098b” Authentication Assurance: Basic
PRO: Can include affiliation for federated usage Read-only on legitimate card If signed, cannot be arbitrarily modified/created CON: Can be cloned onto emulated card AuthN: Card Holder Unique ID (CHUID) “What’s your issued serial number?” JohnDoe-DoD-6128386 Digital signature Authentication Assurance: Basic
PRO: Strong anti-cloning Fast, cheap to implement on card CON: Master key distribution problem Steal master keys, clone any card Impractical for federated usage, offline devices AuthN: Symmetric Key on Card “Encrypted partial session key” “Encrypted partial session key” Authentication Assurance: High – small/closed environments
PRO: Stronger anti-cloning than (e.g.) CHUID Can include affiliation for federated usage CON: Card storage capacity Interoperability Forgery: can’t revoke biometrics Privacy AuthN: Signed Biometric Templates “Give me your biometric templates” Format metadata Format metadata Format metadata Card serial number Card serial number Card serial number Biometric template 1 Finger 1 Biometric template 2 Finger 2 Biometric template 3 Face Digital signature Digital signature Digital signature Authentication Assurance: Medium-High
PRO: Better storage Stronger anti-cloning than (e.g.) CHUID Can include affiliation for federated usage CON: Interoperability Forgery: can’t revoke biometrics Privacy AuthN: Signed Biometric References “Give me your biometric templates” Format metadata Biometric template 1 Finger 1 Card serial number Biometric template 2 Finger 2 Biometric hash 1 Biometric hash 2 Biometric hash 3 Biometric template 3 Face Digital signature Authentication Assurance: Medium-High
PRO: Strong anti-cloning None of the privacy concerts of biometrics Optional part of NIST SP 800-73 (Card authentication key) CON: Potentially higher cost per card Combo card vs. Dual Interface: Cost vs. Security? AuthN: Private Key on Card “Give me your cert” “Challenge: 12345678” “Response: 81a1bd099” Authentication Assurance: High
AuthZ: Trusted Database • Requires transaction-time connectivity • Hard to scale • Hard to federate
Status Assertion: 4/30/05 #909090909 • Employee • Clearance: High • Not a Pilot Signed: Trusted Authority Signed Status Assertions US DoD Rumsfeld, Donald ID #90909090909 From: 2004JAN01 To: 2006DEC31
Status / Privilege Assertion AuthZ: Signed Status Assertions • E.g. Attribute Certificates, SAML Assertions • Assertions of status (revocation) and/or privileges (attributes) • Using OCSP Responses due to size, PIV mandates for revocation checking • Don’t require trusted communications
AuthZ: Portable (Offline) Assertions • Synchronize to devices • Carry on the cards (aka sneaker-net) in standardized locations • Maintain local control of local privileges Authorization Application Authorization message file OCSP Response Cert ID: 1234 Status: Valid Expires: 1/7/05 17:00 Privileges: Medic Optional additional files …
Unify Assertions for Convergence • Converge Identity Management for physical and logical • Use strong PKI methodologies in physical • One large-scale infrastructure for privileges instead of two OCSP Response Cert ID: 1234 Status: Valid Expires: 1/7/05 17:00 Privileges: Medic
The Future • Short-term US PIV cards: • high assurance logical access AuthN • low assurance physical access AuthN • Contactless PKI available today, adoption as price per card decreases • PKI methodology creeping into physical access control • Embedded systems (locks, cards) can have reasonable horsepower