1 X.509-style PKI Revolves around the distribution and management of digital identity certificates Invented in 1978 to facilitate message encryption In line with original goal, X.509 certificates provide: – Confidentiality of data in transit (through encryption) – User authentication (ensures messages are encrypted under right public key & prevents man-in-the-middle attack) – Data integrity (prevent tampering with data in transit) – Non-repudiation (proof of sender’s identity) Access control was never a design requirement (irrelevant for message encryption infrastructure!)

2 Applying PKI to access control PKI vendors currently distorting their technology to do access control (encryption is not big market need …) Their approach: – Individual to provide digital identity certificate to gain access – Certificate serves as strongly authenticated pointer to on- line databases entries – Access provider to retrieve all data for authorization decision = Credit card infrastructure on steroids … Authentication for message encryption very different from access control to sensitive data (unique needs for privacy, security, scalability & performance)

3 The irony; a historical perspective Diffie-Hellman invention of asymmetric crypto (1976): – Setting: Encrypted communication over open network – Sender to encrypt message with public key of recipient – To prevent man-in-the-middle attack, on-line & secure (read-only) database lists “name”– “public key” bindings Kohnfelder’s bachelor’s thesis (1978): – Database problems: bottleneck & vulnerable to attacks – Identity certificates proposed to address both problems Irony of digital identity certificates for access control: – Both problems are back with a vengeance – New problems that were irrelevant in original setting

4 Verifiers must look up all authorization data themselves … … but all these databases may be in different trust / administrative domains … … not to mention the revocation database, common to everyone

5 PKI & access control: problems (1) Non-scalable beyond pre-established trust domains: – Access provider relies on the availability, correctness, and timeliness of authorization data Poor security: – Access right cloning and lending: no cryptographic protection – Misuse of online databases by hackers and insiders – Vulnerable to denial-of-service attacks: Strong reliance on real-time availability of online databases Online certificate status validation – Increases risk of identity theft: Inescapable system-wide identification Strong reliance on central databases

6 PKI & access control: problems (2) Not suitable for use with smartcards: – Cannot use low-cost smartcards: Storage problem Need crypto co-processor for exponentiations Elliptic-Curve cryptography is only partial solution – Application provider must place very strong trust in parties involved in smartcard manufacturing, masking, initialization, application loading, and personalization. Attacks: Overt or covert leakage of secrets and other confidential data Uniqueness, randomness, and secrecy of secret keys?? Fake-terminal attacks Selective “failure” attacks based on dynamic inputs – Problems worsen for multi-application smartcards

7 PKI & access control: problems (3) Managed services are intrusive: – Online Certificate Status Providers able to learn competitive/sensitive data in real time: Identities of access requestors (and access providers) Peak hours Typically: nature of the transaction Possibly: transaction details – Certificate Authorities must know the identity and any other attributes that go into the certificates they issue – Online Certificate Status Providers & Certificate Authorities & on-line database maintainers can disrupt operations on the basis of transaction-specific knowledge in real time

8 PKI & access control: problems (4) Privacy-invasive (roots inescapable systemic identification deep into information infrastructure): – Public keys = strongly authenticated “super-SSNs”: Globally unique identification numbers Inescapably travel along with each and every action taken Obtained by access provider & third parties (providers of authorization databases & online certificate status verifiers) – Always leave behind undeniable digital evidence of the requestor’s identity (due to digital signing of nonces) – Problems with data protection legislation, unbridled use of PKI may be unconstitutional – Access providers & third parties cannot prevent receiving identifiable data

9 Bad “solutions” (quick fixes) Identity certificates that specify a “pseudonym” or a “role” instead of a real name: – Does not address privacy problems (remember: tracing can be done on the basis of the public keys in certificates) – May weaken security (accountability, fraud containment, …) Issue different identity certificates for different uses: – False sense of privacy: like using SSNs, credit card numbers, and health insurance numbers for all actions! – Damages functionality: creates separate “islands” that cannot communicate (bridge-CAs undo purpose & create new scalability and trust problems) – Scalability & smartcard inefficiency even worse

10 Another bad “solution” Privilege Management infrastructure (PMI): – X.509 attribute certificates specify relevant attribute data – Addresses availability problem, but exacerbates all other problems: Attribute certificates must be linked to (and sent along with) base identity certificate to prevent pooling of privileges Even more devastating for privacy (all the attributes within a certificate must be known to the CA & must be disclosed when showing the certificate) No mechanisms to prevent discarding, updating-prevention, lending, and cloning Smartcard inefficiency even worse Must manage and revoke an abundance of certificates