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

2. 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.

3. 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.

4. Page  4 Proof of Non-Possession http://www.cs.washington.edu/education/courses/csep590/06wi/finalprojects/Hullender-Greg-Project.doc

5. 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)

6. 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: - http://world.std.com/~cme/non-repudiation.htm http://world.std.com/~cme/non-repudiation.htm - http://www.firstmonday.org/issues/issue5_8/mccullagh/ http://www.firstmonday.org/issues/issue5_8/mccullagh/

7. 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

8. 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)

9. Sign-then-Encrypt

10. 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“

11. 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

12. 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 emails when you sign them

13. 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 30 82 01 0a 02 82 01 01 00 b2 d8 fb 99 f5 07 a9 6e ee 2d 8a 97 c0 de 60 40 bb 64 a7 ec 04 b6 01 be 3c 5c 8e 41 8c d1 6f c6 bb 72 81 b7 15 52 dc a2 fe 96 64 04 79 6c 88 01 94 21 74 63 55 cc c4 d8 07 46 60 45 93 65 d1 ce a6 b2 39 8a 9b b8 7d 49 7d 81 54 bb 20 07 95 b9 a1 86 37 d1 31 28 2b 0b 7a c1 c0 07 3b 96 6b 48 ab 25 0d 74 77 33 03 22 ae 6f fd 09 6b 6a 68 dd 4f 2b 5c 9d 7a 7f a9 17 50 fe 4c 3b 6f a5 fd b4 26 d8 16 b8 32 b3 ad 89 7b 27 14 d0 01 98 48 57 41 0d 9d fc 91 50 1c 83 ce 5c 95 ff 53 ff 13 40 bd 2c 6a e9 41 56 6a c9 46 b2 51 87 94 55 39 1b 62 48 cb bb 10 a2 a8 0a 09 20 67 7c 7d 73 a6 79 72 6c 58 51 5c 5f 54 09 63 df a6 7e f3 0c a0 e0 07 ba 48 bf 3b 2f 4b 84 1d 7b fb 67 35 0d b0 51 77 fa 26 e6 5a 6f d8 f8 c6 ca dc 74 70 92 e1 66 52 88 8e c5 30 06 09 bb 33 d1 2c 4f 45 f1 61 27 02 03 01 00 01 11 Private key …

14. 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)

15. 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? - http://weblogs.mozillazine.org/gerv/archives/ 2005/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“

16. Page  16 Auditing

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

18. 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