What is wrong with PKI? Risks, Misconceptions, Design-issues,...

Page  2 Proof of Non-Possession Proof of Possession: The CA has to check that the user that applies for a certificate possesses the private key. This is usually done by the user digitally signing a so called certificate request which contains the public key, the identity that is demanded for the certificate, and sometimes a nonce.

Page  3 Proof of Non-Possession Proof of Possession: The CA has to check that the user that applies for a certificate possesses the private key. This is usually done by the user digitally signing a so called certificate request which contains the public key, the identity that is demanded for the certificate, and sometimes a nonce. Proof of Non-Possession: The CA has to check that nobody else than the user that applies for the certificate possesses the private key This is a much harder problem Problem: It was forgotten to require a proof of non-possession.

Page  4 Proof of Non-Possession

Page  5 Proof of Non-Possession  Reasons for duplicates: - Vhosts - Bad Random Number generators - old Netscape - old PGP - Java Vendors shipping private keys to their users - ~ 10 vendors identified - Installation images which include private keys („Imaging“ e.g. Norton Ghost) - Virtualisation issues - Insecure workflows (OpenSSL textfile management)

Page  6 Non-repudiation  Non-repudiation is the concept of ensuring that a contract cannot later be denied by either of the parties involved. - Non-repudiation is the opposite of plausible deniability.  X.509 added a „Non-Repudiation“ bit into the certificates  “It is defined as being able to prove that if you have a digital signature that verifies with public key K, then you know that the associated private key was used to make that signature.“  References:

Page  7 Man in the Browser 1 The trojan infects your computer (any way you like) 2 The trojan installs itself into your browser 3 The trojan manipulates the data before sending 4 The trojan manipulates the data received from the server 5 Invisibly. Agenda

Page  8 Man in the Browser Effects  Results: - What you See is What you do - fundamentaly broken - All Authentication mechanisms (PKI, 2 Factor, SmartCards, Certs, Biometry,...) „circumvented“ - Phising – Old technology - Browsers are selling this as a feature – So they won´t protect you from that  What do we need? - Transaction security - Tamper-Detection for Browsers - Secure Second Channels (SMS)

Sign-then-Encrypt

Page  10 Sign-then-Encrypt Message: „I love you“ AliceBob Signed by Alice: Message: „I love you“ Enc Bob Signed by Alice: Message: „I love you“ Signed by Alice: Message: „I love you“

Page  11 Sign-then-Encrypt Message: „I love you“ AliceBob Signed by Alice: Message: „I love you“ Enc Bob Signed by Alice: Message: „I love you“ Signed by Alice: Message: „I love you“ Enc Eve Signed by Alice: Message: „I love you“ Eve

Page  12 Sign-then-Encrypt Effects  Affected - PGP Inline - S/Mime -...  How to solve - Include the recipient of the message in the data that is signed - Always write „Dear Mr. John Doe,“ in your s when you sign them

Page  13 Stale certificates  Information about the owner of the certificate  Information about the certificate authority  Electronic fingerprints for the validation of the certificate and the owner of the certificate.  Issuing date and expiration date of the certificate  A public key which allows your communication partner to decrypt hash values of your signed mails and which allows him to encrypt mails he is sending to you.  A private key which allows you the decryption of messages sent to you and which is needed to create the hash value in the signature of your outgoing mails. Elements of a digital certificate Public key a b2 d8 fb 99 f5 07 a9 6e ee 2d 8a 97 c0 de bb 64 a7 ec 04 b6 01 be 3c 5c 8e 41 8c d1 6f c6 bb b dc a2 fe c cc c4 d d1 ce a6 b2 39 8a 9b b8 7d 49 7d bb b9 a d b 0b 7a c1 c0 07 3b 96 6b 48 ab 25 0d ae 6f fd 09 6b 6a 68 dd 4f 2b 5c 9d 7a 7f a fe 4c 3b 6f a5 fd b4 26 d8 16 b8 32 b3 ad 89 7b d d 9d fc c 83 ce 5c 95 ff 53 ff bd 2c 6a e a c9 46 b b cb bb 10 a2 a8 0a c 7d 73 a c c 5f df a6 7e f3 0c a0 e0 07 ba 48 bf 3b 2f 4b 84 1d 7b fb d b fa 26 e6 5a 6f d8 f8 c6 ca dc e e c bb 33 d1 2c 4f 45 f Private key …

Page  14 Certificate Expiration CA created CA created Cert created Cert created Document Signed Document Signed Cert Expired Cert Expired Document Verified Document Verified  Non Repudiation was the try to define the problem away  CA´s could accidently revoke your certificate  CA´s are valid for ~30 years  Certs are valid for ~2 years  Documents are valid for ~20 years  SSL Certificate Validation is Realtime.  Document Signature Validation happens long afterwards  happens after the cert expired  Industry standard: 30 Years  Financial standard: 7 Years  Remember what happened when Verisign´s CA expired, and MS Office stopped working?  Solution: Non-expiring keys for OpenPGP Revocation!?! *not available in all countries anymore (for example: Germany)

Page  15 Misconceptions What people think PKI provides vs. what it really does  Has anyone held the passport issuing agency liable for fraud convicted with passports? /05/godaddys_1000_w.html  Can anyone sell me an Acrobat Reader? In Hardware?  „If the CA doesn´t help me to get the other one into jail, the certificate is worthless for me“

Page  16 Auditing

Page  17 Any questions? Just ask. I am here to answer them!

Page  18 TODO Bürgerkarte in Software  Stale Certs vs. Credentials  Authentifzierung  Single-Sign-On vs. XSS  Client Certificates vs. XSS  Unqualified Signature Verification  Qualified certificates  Published Audit Criteria  Qualified SmartCards  Class3 PINs  Qualified Certificates in Software  Quadratic usage of CRLs  Timestamping Business Models  SSH-style PK change detection for HTTPS  Pricing