Next-Generation Secure Public-Key Infrastructures Paweł Szałachowski Network Security Group, ETH Zürich
Public Key Infrastructure (PKI) ▪ Scalability issues with symmetric crypto • Distribution • Challenges in managing n secrets Symmetric keys 2
Public Key Infrastructure (PKI) ▪ Scalability issues with symmetric crypto • Distribution • Challenges in managing n secrets ▪ Asymmetric crypto (DH, RSA, … ) solves the scalability problems, ... but creates a new one: ▪ How to ensure that public-key is accessible and authentic ? Symmetric keys PKI (public keys) 3
Current SSL/TLS PKI Model ▪ SSL/TLS Protocol ▪ Certification Authority (CA) is trusted by clients and domains ▪ Step (1) performed one-time per certificate CA a.com (1) a.com Client a.com 4
Current SSL/TLS PKI Model ▪ SSL/TLS Protocol ▪ Certification Authority (CA) is trusted by clients and domains ▪ Step (1) performed one-time per certificate CA a.com (1) a.com ClientHello (2a) ServerHello a.com (2b) Client a.com 5
Problem with current SSL/TLS PKI: Weak certificate authentication ▪ Certificates signed by single CA • Currently, cannot sign certificate by multiple CAs ▪ Weakest-link security with too many trusted entities • Current browsers trust ~1500 keys that can issue valid certificates Man-In-The-Middle attack: ... CA4 CA1 CA3 CA2 a.com Attacker a.com Client 6
Problem with current SSL/TLS PKI: Weak certificate authentication ▪ Certificates signed by single CA • Currently, cannot sign certificate by multiple CAs ▪ Weakest-link security with too many trusted entities • Current browsers trust ~1500 keys that can issue valid certificates Man-In-The-Middle attack: ... CA4 CA1 CA3 CA2 (2) (1) ClientHello (3) ServerHello a.com Attacker a.com a.com Client 7
Problem with current SSL/TLS PKI: Weak certificate authentication ▪ Certificates signed by single CA • Currently, cannot sign certificate by multiple CAs ▪ Weakest-link security with too many trusted entities • Current browsers trust ~1500 keys that can issue valid certificates Man-In-The-Middle attack: ... CA4 CA1 CA3 CA2 (2) (1) (4) ClientHello ClientHello (5) (3) ServerHello ServerHello a.com Attacker a.com a.com Client 8
Problems with current SSL/TLS PKI 9
Problems with current SSL/TLS PKI ▪ Weakest-link security ▪ Revocation system is insecure and inefficient • Various schemes • Some CAs are too-big-to-fail ▪ Trust agility • Domains cannot state which CAs are trusted ▪ Transparency • CAs’ actions are not transparent ▪ Imbalance • CAs have almost unlimited power ▪ Misconfigurations • SSLv2, weak crypto, NULL cipher suites 10
Problems with current SSL/TLS PKI: Security warnings and error handling ▪ Drawbacks of TLS error handling by browsers and users • Users prefer to ignore errors and visit web sites • Browsers prefer to avoid hard fail to cater to users • However hard fail is the only effective protection against an attack! • Observation : Domain should decide on error handling ClientHello ? ServerHello a.com a.com Attacker User 11
Problems with current SSL/TLS PKI: Security warnings and error handling ▪ Drawbacks of TLS error handling by browsers and users • Users prefer to ignore errors and visit web sites • Browsers prefer to avoid hard fail to cater to users • However hard fail is the only effective protection against an attack! • Observation : Domain should decide on error handling ClientHello ? ServerHello a.com a.com Attacker User Browser Hard/Soft fail 12
PoliCert: Secure and Flexible TLS Certificate Management [CCS’14] ▪ Observation: many problems can be solved when domains can express their own security policies • Many domains have multiple certificates (and servers) and want to ensure consistent policy across all certificates (and servers) • Desire to enforce security policy for all subdomains ▪ PoliCert allows domains to express security policies (certificates, connections, policy inheritance rules for subdomains, and TLS error handling controls) • Subject Certificate Policy ( SCP ) – infrequently updated • Multi Signature Certificate ( MSC ) – frequently updated ▪ How to create and make policies accessible? 13
PoliCert: Parties ▪ Clients/CAs/Domains as today ▪ Logs are public and highly available ▪ Auditors monitor Logs Certificate Issuance CA and Registration Domain Log Log Audit Certificate Validation Client Auditor 14
SCP and MSC Creation ▪ SCP (one per domain): a.com’s • Used for management SCP • Signed by long-term CAs’ keys CA1 • Describes MSCs and connections: ▪ Who is trusted by Domain (list of trusted CAs and Logs)? CA2 ▪ When should MSC be accepted? ▪ Security parameters of connection ▪ Failure scenario (errors handling) CA3 ▪ Inheritance (to enforce subdomains) ▪ How can SCP be updated? • SCP’s key can be stored off-line CA4 ▪ MSC (many per domain): a.com • Used for TLS connection setup CA5 • Must be signed by SCP’s key CA6 15
SCP and MSC Creation ▪ SCP (one per domain): a.com’s • Used for management SCP • Signed by long-term CAs’ keys CA1 • Describes MSCs and connections: ▪ Who is trusted by Domain (list of trusted CAs and Logs)? CA2 ▪ When should MSC be accepted? ▪ Security parameters of connection ▪ Failure scenario (errors handling) CA3 ▪ Inheritance (to enforce subdomains) ▪ How can SCP be updated? a.com’s • SCP’s key can be stored off-line MSC CA4 ▪ MSC (many per domain): a.com • Used for TLS connection setup CA5 • Must be signed by SCP’s key CA6 16
SCP Registration and Update ▪ Registration and update are synchronized among Logs (these operations are Log1 infrequent) (1) (2) SCP Reg/Upd ▪ Update must be be a.com’s SCP Confirmation Log2 compliant with update (3) a.com parameters of current SCP Log3 observe Auditor Log4 17
MSC Registration and Revocation ▪ Registration and revocation does not require any Log1 synchronization MSC Reg/Rev a.com’s MSC a.com’s MSC Confirmation Log2 a.com Log3 observe Auditor Log4 18
Append-Only Log ▪ Log (on demand) can prove: ▪ What is current SCP for a Domain ▪ That MSC is logged and (not) revoked ▪ That one snapshot of the log is an extension of another 19
MSC validation (every 2h) proof request proofs Log inf.ethz.ch (periodically) synchronize Auditor Client ▪ Client checks if: • MSC and SCP are logged • MSC is not revoked • MSC is compliant with SCPs ▪ Client can contact Auditor to verify Log’s proofs 20
MSC validation (every 2h) proof request proofs Log inf.ethz.ch (1a) MSC, SCPs (inf.ethz.ch, ethz.ch, ch), proofs (1a) (2) Saves SCPs Auditor Client ▪ Client checks if: • MSC and SCP are logged • MSC is not revoked • MSC is compliant with SCPs ▪ Client can contact Auditor to verify Log’s proofs 21
MSC validation (every 2h) proof request proofs Log inf.ethz.ch (1a) MSC, SCPs (inf.ethz.ch, ethz.ch, ch), proofs (1a) Are proofs (2) correct ? Saves SCPs (3) Auditor Client ▪ Client checks if: • MSC and SCP are logged • MSC is not revoked • MSC is compliant with SCPs ▪ Client can contact Auditor to verify Log’s proofs 22
Parameters Inheritance ▪ SCPs can have parameters that are inherited by subdomains (i.e., subdomains have to adhere to them) ▪ In case of inheritance parameter can only be changed if it makes the parameter more secure inf.ethz.ch's policy ethz.ch's policy ch's policy *CA ={B,C,D,E,F,G} CA={A,B,C,D,E} *CA ={A,B,C,D} *SSL_SEC =Medium SSL_SEC=Low *SSL_SEC =High ... ... ... CA – list of trusted CAs SSL_SEC – minimum security level of SSL/TLS connection *PARAM – value is inherited by subdomains 23
Parameters Inheritance ▪ SCPs can have parameters that are inherited by subdomains (i.e., subdomains have to adhere to them) ▪ In case of inheritance parameter can only be changed if it makes the parameter more secure inf.ethz.ch's policy ethz.ch's policy ch's policy *CA ={B,C,D,E,F,G} CA={A,B,C,D,E} *CA ={A,B,C,D} *SSL_SEC =Medium SSL_SEC=Low *SSL_SEC =High ... ... ... Step 1 CA={A,B,C,D,E} SSL_SEC=Low ... 24
Parameters Inheritance ▪ SCPs can have parameters that are inherited by subdomains (i.e., subdomains have to adhere to them) ▪ In case of inheritance parameter can only be changed if it makes the parameter more secure inf.ethz.ch's policy ethz.ch's policy ch's policy *CA ={B,C,D,E,F,G} CA={A,B,C,D,E} *CA ={A,B,C,D} *SSL_SEC =Medium SSL_SEC=Low *SSL_SEC =High ... ... ... Step 2 Step 1 CA={A,B,C,D,E} CA={A,B,C,D,E} SSL_SEC= High SSL_SEC=Low ... ... 25
Parameters Inheritance ▪ SCPs can have parameters that are inherited by subdomains (i.e., subdomains have to adhere to them) ▪ In case of inheritance parameter can only be changed if it makes the parameter more secure inf.ethz.ch's policy ethz.ch's policy ch's policy *CA ={B,C,D,E,F,G} CA={A,B,C,D,E} *CA ={A,B,C,D} *SSL_SEC =Medium SSL_SEC=Low *SSL_SEC =High ... ... ... Final Step 2 Step 1 CA={A,B,C,D,E} CA={A,B,C,D,E} CA={A,B,C,D,E} SSL_SEC= High SSL_SEC= High SSL_SEC=Low ... ... ... 26
Use Cases bank.com's policy *SSL_SEC =High *FAIL_SSL_SEC =Hard ... www1.bank.com TLS 1.2 www4.bank.com TLS 1.2 www2.bank.com Client SSL 2.0 www3.bank.com TLS 1.2 27
Recommend
More recommend
