Attacks on the Internet Trust Fabric

Transcription

1 Attacks on the Internet Trust Fabric The Impact to Enterprise Trust +1 (801)

2 About DigiCert Table of Contents Slide Title 3 Recent Attacks On Certification Authorities 4 Why Attack CAs? 9 Proposed Solutions to Mitigate Attacks 18 DigiCert Your Trust Partner 19 Who Uses DigiCert? 20 Testimonials 22 Features & Innovations 23 Products 25 Managed PKI 26 Promotional Code

3 Recent Attacks On Certification Authorities Comodo Mar 2011 Multiple RA breaches : mis-issuance of at least 9 certificates Italian & Brazilian RAs were targeted StartCom Jun 2011 Breach of Server : no certificates mis-issued DoS of services to StartCom customers result DigiNotar Jul 2011 (didn't disclose until Aug 2011) Major Breach : 500+ certs issued caused by poor security CA now out of business Globalsign Sept 2011 Breach of Server : but no certificates were mis-issued DigiCert Malaysia (no relationship to US company) Oct 2011 Issues certificates with weak keys, lacking extensions to revoke them Bad certs were re-purposed to sign malware CA certificate was revoked KPN (Dutch CA related to DigiNotar) Nov 2011 Breach of Server : no certificates mis-issued DoS of services to KPN customers result

4 Why Attack CAs? There are a number CA Trust Anchor (TA) certificates that come pre-installed in various Applications that are trusted to perform various security tasks Verify identity of web sites, establish secure connections, encrypt data to/from Verify identity of software makers, applications or plug-ins given kernel level privileges i.e. trusted extension of the Operating System Verify identity of individuals, or source/destination of communications/data Many applications trust the set of pre-installed TAs in the underlying Operating System Depending which application on which operating system you are using, there may be a different set of TAs to contend with Original architecture for TAs was aimed at having/dealing with just around 100 of these, yet current currently many platforms now have several hundred pre-installed

5 Why Attack CAs? Not only are there TAs that must be trusted, but any subordinate CA to a TA must also be trusted There are various methods (platform specific) for how these sub- CAs are managed For an application to trust a credential, it must be issued by an authority (TA, or sub-ca that chains back to a TA) that is trusted for the intended purpose by the OS Warnings are given to the user when this is not the case Attackers are trying to get control of a credential issued by a trusted CA so that unsuspecting users can be fooled into trusting a transaction that comes from a malicious source, without getting any warnings

6 Why Attack CAs? PKI certificates are only ½ of the equation When creating a request, you generate a key pair, a private key, and a public key Public keys are embedded into the certificate, but private keys MUST be secured because that is how you prove you are the one authorized behind the public certificate that represents you Instead of attacking a web site directly to try to gain access to its private key, and thus impersonate you, and be trusted just like they were you, an attack is more efficient if it can target the issuing CA directly This allows the attacker to generate as many keys as it wants and submit to a trusted CA : as long as they can convince the CA that they are really you Instead of just one domain compromise resulting from the attack, they can potentially get many for the price of one

7 Why Attack CAs? Not all CAs are created equal Out of the many hundreds of CAs trusted as TAs for an application, some perform better than others in protecting their customers with better processes and more secure systems As evidenced earlier, attackers are targeting lots of different CAs looking for any weaknesses they can exploit One issue identified with the current TA system, is that all CAs are typically treated equally trusted, when in fact they should/are not An important decision for service owners is to choose a CA that is more secure, more trusted, less likely to be compromised

8 Overhaul the whole CA system? Some folks are calling for an overhaul of the entire CA system To eliminate the weakest link issue To standardize the processes used in identity verification and issuance To be able to represent TAs as having differing levels of trust for different purposes (rather than a one size fits all) To be better able to manage the TAs and the certificates that are issued by them

9 Proposed Solutions to Mitigate Attacks DANE Convergence Perspectives MECAI (Mutually Endorsing CA Infrastructure) CA Pinning CAA Record in DNSSEC Sovereign Keys HSTS Pinning Minimum Identification/Issuance Requirements

10 DANE DANE see - Overview: DANE stands for DNS-based Authentication of Named Entities and is actually an IETF working group item. The basis of the DANE approach is to leverage signed DNS entries (DNSSEC) to make some inferences about the legitimate certificates or potentially just keys that are protecting web sites. If a certificate (or public key) is seen by a client (e.g. browser) that isn t consistent with the DANE record, it can be treated with suspicion - this will help eliminate Man-In-The-Middle (MITM) attacks, and can also facilitate elimination of false issuance problems from the set of authorized CAs An issue with DANE relying upon DNSSEC is that DNSSEC only provides integrity checks on source data and not authentication of that data. It also potentially moves the responsibility of web site security into the span of control of DNS operators who typically have not needed to deal with security elements.

11 Perspectives Perspectives see - Overview: This is a project that began around 2008 at Carnegie-Mellon. The objective was to improve the security of "trust on first use" (TOFU) services e.g. typical SSH connections or (relevant to SSL industry), browser based SSL connections using self-signed certificates. The idea is to reduce Man-In-The-Middle (MITM) attacks in these scenarios by not letting an attacker inject an untrusted key at that critical first use point. Using a set of distributed notary servers, one is able to get a "perspective" of what key was expected from the target service from a number of different locations, and over time. This reduces the vulnerability of localized attacks (the typical attack vector of most MITM) by exposing them with the broad "perspective" required for consensus by multiple notaries.

12 Convergence Convergence see- Overview : This is a project started by security researcher Moxie Marlinspike, and announced at this year's Black Hat conference, and is based on previous work from the Perspectives Project as detailed previously. This project however, is aimed squarely at replacing the existing SSL CA system - that is its stated goal. Similar to the Perspectives strategy, Convergence authenticates connections by contacting external notaries, but unlike the Carnegie based notaries, Convergence notaries can also use a number of different strategies beyond network perspective in order to reach a verdict - it calls this extensible trust agility. Technologies touted as additional mechanisms within the system that might allow a trust decision to "Converge" are DNSSEC, BGP data, "SSL observatory" results, or even the existing CA validation system it seeks to subvert. Another difference from Perspectives is that ANYONE can run a Convergence notary, there is no notary authority, and it is a much more flexible mechanism (in terms of operations and configurability) of managing trust.

13 Mutually Endorsing CA Infrastructure MECAI see- Overview : The MECAI system makes use of Vouching Servers (VS), in which a CA that did NOT issue the certificate in question acts as a Vouching Authority (VA) for others Similar to the Perspectives and Convergence strategy, MECAI authenticates connections by contacting external notaries (the VS), but unlike the previous notary proposed systems, MECAI notaries MUST be actually other CAs. When a client connects to a server, the client may pick a vouching CA (or list of candidate vouching CAs) that it trusts. A VS is required to keep a list of the currently accepted root CA certificates (trust anchors) as accepted by each of the Trust Lists the VA supports. A VS is required to be in active human contact with the people that maintain the various Trust Lists

14 CA Pinning CA Pinning / HSTS Pinning / CAA record in DNSSEC / Sovereign Keys Overview : Sites may want to also restrict the CAs who can issue certificates for their domain to one or a few that they trust. This can be accomplished via a list of certificate fingerprints/names/keys that are exclusively allowed to act as trust anchors for a given domain This list can be included in specific site HTML or HSTS headers or in a DNS record served up over DNSSEC

15 CA Common Requirements Another approach to mitigating attacks on CAs is to implement a common set of requirements on any CA that is trusted as a TA EV standards already exist as published by the CAB forum for high assurance in e-commerce transactions EV certificates are identified as higher assurance controls in browsers Green Bar or equivalent recognition in browsers CAB Forum has drafted a new set of Basic Requirements for Internet CA BR certificates will become a new minimum requirement for TAs from July 2012

16 CABF Basic Requirements 12 Commandments for BR: Minimum standards in validation of certificate information RA audit requirements (applicable where the RA can cause cert issuance Sunset date for 5 year certificates CAs are required to provide a notice to applicants that the use of certificates containing an internal (NetBIOS) name has been deprecated. CAs are not allowed to issue certificates with internal names that have an expiration date after Nov 1, 2015 On October , all CAs are required to revoke certificates with internal names. Elimination of issuance directly from a root cert Mandatory OCSP Mandatory background checks on employees and sub contractors (including RAs) Document and data retention requirements (7 years) Minimum audit standards and self-audit requirements Security requirements (these are being expanded in the Forum's minimum security guidelines, currently under discussion) Private Key Protection requirements Key Ceremony requirements

17 Choosing Your CA There are a number of considerations to take into account when choosing a CA for issuing your certificates Is your CA trusted in the platforms/applications you wish to support? Does you CA have high standards for identity verification and issuance processes Does you CA support EV certificates Will your CA support BR standards Review the identity practices utilized in identifying and issuing certificates Does your CA have a record of strong security practices? Does your CA proactively provide you with information that might be pertinent to the protection of your certificates? How good is the Customer Service? Can you rely upon your CA to respond quickly and efficiently if you have any issues, concerns or problems with your certificates?

18 DigiCert Your Trust Partner Third largest High-Assurance certificate provider Member of:

19 About DigiCert Who Uses DigiCert? DigiCert provides encryption and authentication services to around 50,000 customers globally.

20 About DigiCert Testimonials DigiCert features more 5-star reviews than any other Certificate Authority on sslshopper.com. Here are a few user-generated quotes: This company is 5/5 for me, and I m the kind of guy who could rate something as 4.97 / 5 out of sheer pickiness (Dec 16, 2010) These guys have provided the best level of customer service I have ever experienced anywhere. (Dec 22, 2010) Miles above the other well known names. Thanks a million to DigiCert and their team (Oct 22, 2010)

21 Customer Ratings

22 About DigiCert Features DigiCert SSL Certificates Feature: 99.5% Browser Compatibility Unlimited Server License Issues Extended Validation Certificates Supports BRs and is already compliant Has certified Security Practices in place Secure Trust Seal Award-winning 24/7 customer support $1,000,000 Warranty

23 About DigiCert Products DigiCert provides strong encryption and authentication services for SSL Certificates.

24 About DigiCert Support DigiCert provides an extensive set of online tools to support customers.

25 About DigiCert Managed-PKI Easily manage thousands of SSL certificates with our enterprise-grade, web-based PKI. Instantly approve or reject certificate requests. Intuitive user interface with multiple levels of authority. Assign business units to subaccounts with limited access. Centralize control while distributing workload. Issue trusted Client and SMIME certificates

26 About DigiCert Make the Switch Make the switch to DigiCert today and receive 15% off your next certificate order! Promotional Code 15% Discount Valid till February 29, 2012

27 DigiCert Competition Raffle DigiCert is offering 5 lucky attendees at tonight s presentation the chance to win a DigiCert Helicopter prizes will be sent directly to your listed address: DigiCert remote controlled helicopter actually flies with control unit to perform precise forward, backward, rotation, hover maneuvers. USB charging capability included.

28 DigiCert Contacts Website: Scott Rea: (801) ,