sales@digicert.com www.digicert.com +1 (801) 877-2100

Attacks on the Internet Trust

Fabric

The Impact to Enterprise Trust

About DigiCert

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

Table of Contents

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

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

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

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

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

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

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

DANE

• DANE see - https://datatracker.ietf.org/wg/dane/charter/

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

Perspectives

• Perspectives see - http://perspectives-project.org/

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

Convergence

• Convergence see- http://convergence.io/

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

Mutually Endorsing CA Infrastructure

• MECAI see- https://kuix.de/mecai/

• 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

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

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

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 1 2016, 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

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?

DigiCert – Your Trust Partner

Third largest

High-Assurance

certificate provider

Member of:

About DigiCert

DigiCert provides encryption and authentication services to around 50,000 customers globally.

Who Uses DigiCert?

About DigiCert

DigiCert features more 5-star reviews than any other Certificate Authority on

sslshopper.com. Here are a few user-generated quotes:

Testimonials

“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)

Customer Ratings

About DigiCert

DigiCert SSL Certificates Feature:

Features

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

About DigiCert

DigiCert provides strong encryption and authentication services for SSL Certificates.

Products

About DigiCert

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

Support

About DigiCert

Easily manage thousands of SSL certificates with our enterprise-grade, web-based PKI.

Managed-PKI

Instantly approve or reject

certificate requests.

Intuitive user interface with

multiple levels of authority.

Centralize control while

distributing workload.

Assign business units to sub-

accounts with limited access.

Issue trusted Client

and SMIME certificates

About DigiCert

Make the switch to DigiCert today and receive 15% off your next certificate order!

Make the Switch

Promotional Code

https://www.digicert.com/order/order-1.php?promo_code=1kpji3q

15% Discount

Valid till February 29, 2012

DigiCert Competition

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:

Raffle

DigiCert remote controlled helicopter actually flies – with control unit to perform precise forward, backward, rotation,

hover maneuvers. USB charging capability included.

DigiCert Contacts

Website: http://www.DigiCert.com/

Email: support@DigiCert.com

Scott Rea: (801) 701-9636, Scott@DigiCert.com