A Survey on CA Compromises
André Niemann and Jacqueline Brendel
TU Darmstadt
Abstract. In this paper we will provide the essentials of WebPKI and
give an overview of basic CA Compromise scenarios and best practices to
avoid them. The focus of the work lies in the survey on CA compromises
in the recent years, including their extents, time frames, media coverage
and the reaction of the involved parties.
1
Introduction of the WebPKI Structure
For securing the transport layer of network communication, block and stream
ciphers are used. These are symmetric ciphers and need unique keys for each
session in order to ensure secure communication. Therefore a key agreement
protocol is needed, like Diffie–Hellman (DHE) or ellicptic curve Diffie-Hellman
(ECDHE). To prevent Man in the Middle (MitM) attacks and server authentication, public keys are distributed before connection establishment, since DHEprotocols are not tamper proof.
For the distribution and verification of these cryptographic public keys, publickey infrastructures (PKIs) are needed.
1.1
What is a PKI
To handle the key exchange and validation of the authenticity, two concepts
have been established. The Web of Trust (WoT) approach, well known from
OpenPGP where users sign the public keys of other known users, creating a
graph with paths of trust. Which works well for humans, but is not very well
tailored for machines and hierarchical structures as found in departments and
companies. Therefore there exists also a hierarchical system, where a root entity,
which signs the entities to be trusted, is trusted by the user.
Along with these trust delegations there exist following demands to know
about a public key: Is the key (still) valid? To which entity does the key belong
to? For which purpose was the key created? Do I trust this key?
To match these requirements the public key is put into a X.509 certificate.
The certificate holds the information of the issuer, the validity time range, information about the holder and the subject. X.509 allows also additional fields
for defining the usage, location of revocation information about the issuer and
much more.
Fig. 1. entities interactions
In figure 1 are the interactions between the participating entities are outlined.
a) The serviceprovider(black) has to verify herself at the registration authority(brown) while submitting the certificate signing request (CSR). b) After successful verification the request is forwarded to a intermediate Certificate Authority (CA)(light green), which is often a subsidiary of a Root-CA, or (b’)directly
to the Root-CA(green). They process the CSR and issue the signed X.509 certificate. c) After the service got the certificate1 , it can be installed and presented
to the user.
To establish the trust into a certain certificate(1), the user must have the
certificate of the Root CA or intermediate CAs down to the certificate of the
service and trust at least one of these(2). Additionally the User can also ask the
CA if the certificate is still valid.
1.2
The Specialty of WebPKI
What is very straight forward for narrowed environments, like a company or a
Virtual Private Network (VPN) setup, gets messy in the wild. To fit the demands
of the stake holders of the Web, there exists not only one CA, there exist about
600[1] Authorities with commercial or political interests.
So every CA can sign any certificate request. There are no limitations2 . That
also means, that every trusted authority can undermine the trust in every in
certificate for a TLS client, when issuing a rogue certificate.
This makes CAs for an interesting target for criminals, governments and spy
agencies.
1.3
Motivation of Breaking into a CA
There are several motivations to break in a CA, or lets say to issue malicious
certificates. Because not every malicious certificate originates of a breach.
1
2
the complete trust path is needed, from a trusted certificate to the Transport Layer
Security (TLS)-certificate
At least no widely deployed ones. E.g. Google limited the further use of an intermediate certificate from ANSSI after an incident to domains related to .fr
A classical reason was to gain money from the further use of the certificates. After 2000 the users and companies started to care about security and
all important traffic like payment transactions are encrypted. To intercept the
communication to a trusted site, the attacker needs a certificates which fools the
webbrowser. Not only for the MitM also for phishing valid certificates are useful.
To install malware a software signing certificate it useful, too. It show the user,
that the software is trusted by the operating system. This is useful for installing
scareware like the ukash trojans or configuring a proxy for the MitM.
Governments and spy agencies are also interested in intercepting the connections to update services or signing malware. After the unsuccessful efforts in the
90s to get key escrow systems the governments needed different ways to intercept
network communication and get access to private keys. While spy agencies doing
this for industry espionage, law enforcement is an other reason for the attacks.
2
2.1
CA Compromises and Issuance of Counterfeit
Certificates
Scenarios
If the issuance of counterfeit certificates becomes known, it is crucial to identify
the extent of the compromise fully because the responsive measures that need
to be taken highly depend on the kind of attack that occurred. In the following
we will give a brief overview over the basic scenarios while in the next chapter
we will then see how to prepare for CA compromises in the first place and what
has to be done in case of an exploited security breach. In the description of
the scenarios we follow the guide-lining iTL Bulletin of July 2012 issued by the
National Institute of Standards and Technology (NIST)[2].
Impersonation Attackers might simply want to pass themselves off to be a
specific company or another person, e.g. for money transfer authorizations. To
accomplish this they have to convince the Registration Authority which sends
Certificate Signing Requests to the CA of this stolen identity. If they are successful a certificate will be issued for the wished for identity to the impostor.
This kind of attack is called Impersonation and is basically a so called Man-inthe-Middle Attack.
RA Compromise Not only malicious attacks aimed at the CA can lead to the
issuance of fraudulent certificates. As seen in chapter 1 there is another important component involved in the process: the RA. If the RA is infiltrated, the
attacker is enabled to authorize Certificate Signing Requests at will which then
are obediently signed by the CA.
In the next two scenarios the CA itself is the actual target of the attack.
CA System Compromise A CA system compromise occurs if the attacker is
able to take over the internal infrastructure of the CA without actually owning a
copy of the private key belonging to the CA. The attacker is nevertheless able to
issue one or more certificates and above that signed fraudulent CRLs (Certificate
Revocation Lists) can be distributed which proclaim the counterfeit certificates
as perfectly valid. As the attacker has widespread access within the system, he
can also manipulate the log files in order to conceal his activities and make it
impossible to determine if and which certificates have been fraudulently issued.
CA Signing Key Compromise The worst case scenario is if the attacker is
able to infiltrate the CA and obtain its signing key. Then the attacker can sign
certificates and CRLs as he or she pleases. There are two possibilities how the
attacker can take possession of the key. He can either steal an existing copy of the
key or attack the key and its underlying algorithm to determine it by factoring
or brute force.
As the standards for key generation within CA systems are typically rather
high according to the nature of the business, the prospect of obtaining a copy
of the key is generally much more promising for the perpetrator. But lately an
increasing advance in the methods and resources of attackers could be observed
and with ever prominent problems like weaknesses in the software itself (e.g.
poor random number generation), this scenario cannot be put aside.
If in the last two scenarios a Root CA is concerned, we speak of a Root CA
Compromise.
2.2
Prevention and Responding to CA Compromises
The appropriate treatment of a CA compromise starts before anything has actually happened. In case of a CA Compromise it is vital to react quickly, in a most
coordinated manner and including all possibly involved parties (in particular
subjects, relying parties and vendors). To be able to do so a company has to be
well prepared.
In a presentation from US based software company Venafi Inc. titled Five
Must Haves to Prevent Encryption Disasters[3] an overview of preparatory as
well as remedial actions concerning CA compromises are proposed. As they are
self-explanatory, we will simply state those steps in the following:
Preparing for a CA Compromise
1.
2.
3.
4.
5.
6.
Document Clear Certificate Policies
Create CA Compromise Response Plan
Educate all Stakeholders
Review CA Security and Communications Policies
Establish Backup CA Plan
Inventory Server-side and Client-Side Certs
7.
8.
9.
10.
11.
Verify that only Approved CAs are used
Identify Cert Owners (Subjects) and Relying Parties
Enforce Revocation Checking on Relying Party Systems
Inventory Root CAs that are Trusted on Relying Party Systems
Ensure only Approved Roots are Trusted
Responding to a CA Compromise
1. Establish Clear Understanding of What Occurred (What Type of Compromise etc.)
2. Activate Helpdesk
3. Revoke Certificates and Establish New CA(s)
4. Notify Subjects, Relying Parties, and Vendors
5. Replace Certificates
6. Remove/ Replace Root Certificates
7. Validate that Revocation Checking is Enabled on Relying Party Systems
8. Validate Cert & Root Replacement
9. Track and Report on Progress
The degree of revocation and removal of certificates depends on the scenario
that occurred (cf. Section 2.1). The following Table 1, also taken from aforementioned presentation [3] shows the necessary actions:
Revoke
Revoke
Replace
Counterfeit CA Cert All
Certificates
CA Certs
Impersonation
•
RA Compromise
•
CA System Compromise
•
•
CA Signing Key Compromise
•
•
Root CA Compromise
•
Table 1. Remediation Matrix
Remove Root Cert
from
Relying Parties
•
3
Incidents
In the following we will look at some actual incidents that occurred—or rather
those that became public—within the last few years. They are not sorted chronologically but rather starting with those that had the biggest impact with respect
to media coverage and gravity of incident.
3.1
DigiNotar
One of the famous incidents is the DigiNotar breach. DigiNotar was not only a
public CA but runs also the PKIoverheid, the PKI program of the Dutch.
On the evening of the 29th August 2011 it became public that rogue wildcard
certificates for googles domains where presented to users in Iran. The certificates
were immediately revoked. Mozilla was only notified by Google[4]. On the next
day, external IT Security experts started the investigation.
Prior to this investigations, other audits discovered already that between
the 17th June and 22th July attackers gained administrative access on several
servers. An overview of at this time already by DigiNotar staff and other auditing
experts recorded incidents:
– On the 19th of July 128 rogue signed certificates were detected and intermediately revoked.
– The day after were again 129 signed certificates detected and revoked on
21th.
– Until the end of July much more certificates were detected.
– Also verification requests from Iranian users were recorded.
When Fox-IT started to investigate on 30th of August, they installed network monitor sensors, including the OCSP-Service3 . The OSCP-Requests are
important, because the fraudulent *.google.com certificate had a not recorded
serial number. So it was impossible to say how much certificates were issued.
The attacks of the DigiNotar were still monitored.
On 1st September the OSCP behavior was changed to whitelist based responses in order to the unknown issues. On the 2nd and 3rd September Fox-IT
discovered that also the CA server used for the qualified certificates and the
PKIoverheid were compromised. GovERT.nl, the Dutch’s Computer Emergency
Response Team, was informed and changed its agreement with Mozilla to exempt
intermediate certificate from untrust. The first agreement was, to only untrust
DigiNotar certificates, which are not connected with the certificates which are
chained up to the governmental certs. DigiNotar was running several separate
CAs.
The interim report of the breach was published by Fox-IT on the 5th September 2011. Nine days later OPTA, a government agency for enforcing Dutch law
on telecommunication, post and TV, revoked the registration of DigiNotar as a
3
Online certificate status protocol, is provided by a CA for checking the status of a
certificate, like CRLs, but online
CA for official qualified signatures. Only 5 days later, Diginotar filed bankruptcy
declaration and was declared bankrupt on the 20th December 2011.
The PKIoverheid and qualified certificates issued by DigiNotar were only
revoked 8 days later. During this time all users were in potential danger. The
remaining public certificates where revoked on the 1th of November, excluding
three DigiNotar operated CAs for which the remaining risk was rated as ok.
The fraudulent certificates seems to be used against users from Iran, nearly
all recorded OCSP request were from irani IPs. Samples of the remaining IPs
were mostly allocated to Tor exit nodes or other servers used as proxies or VPN
node.
The most (known) certificates were issued for high value domains like
*.google.com, *.skype.com, *.torpoject.com and other communication and messaging sites. Also certificates for CAs like Equifax, Thawte and Verisign were issued. Also software vendors were affected with certificates for addons.mozilla.com
or www.update.micrsoft.com.
In conclusion: the attacks and breach were detected early and issued (discovered) certificates were revoked intermediately. But there was no communication
of the breaches until it was too late. No software vendor was informed. Mozilla
stated in there security blog, that Google informed them. The lack of communication and the known flaws of revocation weakened not only the web security
for all users of the world, also the lives of Irani.
3.2
Comodo
On March 15, 2011 the New Jersey based company Comodo Group Inc. was
target of an RA attack.
A user account of one of their partner’s RAs in Italy was successfully compromised and then used to first create a new username and password. With this account the issuance of nine certificates for seven domains including Google, Yahoo,
Skype, Microsoft and Mozilla was requested. It is not clear if all certificates—
except for one which could temporarily be found on a web server in Iran—were
actually received[5].
According to Comodo[6] the attack was carried out ”with clinical accuracy”
and most of the IP addresses associated with the attack appeared to have their
origin in Iran. Since the fraudulently issued certificates focused on means of communication and since at that time the Iranian government was already accused
of intercepting encrypted communications, Comodo came to the conclusion that
it was probably a state-driven attack.
Comodo pointed out that their CA infrastructure was not affected by the
attack. Neither the keys in their Hardware Security Modules (HSMs) nor other
RAs or other RA accounts were compromised. Nevertheless Comodo quickly
informed leading browser providers and domain owners of the attack and revoked
the certificates in question within a few hours.
The incident became public a week later after the browser vendors blacklisted
the certificates and rolled out patches for their products.
A few days later on March, 31 Comodo reported of an attempted hack into
another reseller user account. The attack dated March 26 failed as the previously
installed new control mechanisms efficiently detected and stopped the intrusion
before any certificates could be requested or issued.
On pastebin a 21 year old Iranian, calling himself Comodohacker, claimed to
be the sole hacker responsible for the attack[7]. He published a few alleged proofs
including a decompiled part of the Trust.dll of the Comodo partner, account
information and the fraudulent Mozilla Add-on certificate.
3.3
TürkTrust
On the evening of December 24, 2012 Google noticed through their certificate
pinning mechanisms within its browser Chrome, that users were presented with
an unauthorized certificate for the *.google.com domain[8].
After taking a closer look at the certificate, it could be traced back to an intermediate CA certificate which itself was issued by Turkish company TürkTrust
Information Security Services Inc. which is a subsidiary company of Turkish
Armed Forces ELELE Foundation Company[9].
Google immediately got into touch with TürkTrust and other browser vendors[8].
The following investigation revealed that in August 2011 a misconfiguration
after a software change led to the fact that two certificates were mistakenly issued
as SubCA certificates and not end entity SSL certificates and were thus enabling
the receiving customers to issue certificates for arbitrary domains themselves[10].
The subordinate CA certificates in question were issued to the domains eislem.kktcmerkezbankasi.org and *.EGO.GOV.TR[11].
The latter is an agency working for the the Municipality of Ankara and is
responsible for the issuance of the google.com wildcard certificate. TürkTrust
said that this was the result of an ”unfortunate event” and that there were no
hints to suggest an abuse of the certificates with the wrongly set extension[10].
The browser vendors dealt differently with the case. On December 25, Google
blocked the *.EGO.GOV.TR certificate in their browser Chrome, a day later
they also added the second CA certificate. In January another update stopped
to indicate Extended Validation status for certificates issued by TürkTrust[8].
Microsoft released a Security Advisory on January 03, 2013 and updated their
Certificate Trust List, thus removing trust in the *.google.com certificate issued
by *.EGO.GOV.TR and the mistakenly issued subsidiary CA certificates[11].
Mozilla also revoked trust in the two SubCA certificates with an update
released on January 08, 2013. Furthermore at that time, they also suspended
TürkTrust’s request of inclusion of the “TÜRKTRUST Bilgi İletişim ve Bilişim
Güvenliği Hizmetleri A.Ş. (c) Aralık 2007” root certificate [12].
3.4
Cyberroam
On July 03, 2012 the Torproject[13] reported about a fake certificate discovered
by a user from Jordan. During the investigation of the issue, they discovered
that Cyberoam wasn’t tricked into signing that certificate, but also offer Deep
Package Inspection (DPI) capable devices. These devices are all equipped with
the same CA certificate. So every owner of such a DPI capable device is able
to intercept the traffic. This is not the only vulnerability, Ben Laurie and Runa
where also able to extract the private from the DPI device.
They wrote a security advisory and informed the vendor at the afternoon on
June 30, with the note, that the findings will be published on the 3rd July. They
asked the browser vendors to blacklist concurrently. Only Users which added
the Cyberoam CA self where in danger of undetected MitM. It was not trusted
in the public certificate stores. Cyberoam acknowledged the vulnerability and
stated to have look into it.
3.5
Etisalat
On July 08, 2009 the Emirates Telecommunication Corporation Etisalat based
in the United Arab Emirates offered a software update containing spyware to
around 145.000 BlackBerry users via SMS. The update held the official signature
of Research in Motion (RIM, now BlackBerry). Etisalat claimed that the update
was to simplify the ”handover between 2G and 3G networks” and was labelled as
a ”performance enhancing patch” but users recognized a significant drop in their
battery life which led to the detection of the fraud, as gulfnews.com reported[14].
The case became officially known on July 14. A day later, Chris Eng, Vice
President of Security at Veracode, examined the software in the company’s
blog[15]. He found that the messages sent to the costumer’s phones were UTF8
encoded, zipped, AES encrypted and finally Base64 encoded. These packets
would then be queued. Regularly the spyware would check if there were items in
this queue and if so they would be sent back to a server. In particular, this regular connection caused the aforementioned battery drain. As for PGP encrypted
messages, they were packaged along with the available device information and
forwarded to the server. Furthermore, messages that were sent from ”Costumer
Service” and were PIN-based were immediately discarded —probably without
ever reaching the inbox of the user. The spyware also implemented a way to be
turned on and off from a remote location.
Research in Motion issued an eight page long statement[16], in which the
company clarified ”that this software is not a patch and it is not a RIM authorized upgrade. RIM did not develop this software application and RIM was not
involved in any way in the testing, promotion or distribution of this software
application”. RIM reminded its users that authorized updates would be offered
on the company’s website and never via WAP push or SMS and warned that
Etisalat might try to spread the spyware again by claiming to offer a patch which
is supposed to uninstall the previous update.
Etisalat did not comment or investigate on this issue[17].
Etisalat holds a SSL CA certificate signed by Cybertrust, which is now a
division of Verizon. In an open letter the Electronic Frontier Foundation (EFF)
asked Verizon to ”investigate the security and privacy implications of the SSL
CA certificate”[18] in 2010.
The certificate is still trusted in browsers[17].
Browser vendors, including Mozilla and Microsoft, fully delegate the responsibility to Verizon, saying for example that ”the behavior of Etisalat is subject
to the contract between Verizon and Etisalat, and should be dealt with by Verizon.”[19]
But Verizon never reacted either[17].
3.6
ANSSI
On December 03, 2013 it came to Google’s attention that—again—a number
of unauthorized digital certificates for its domains were circulating. The incident was discussed on their Online Security Blog[20] on December 07 and revealed that investigation led to the intermediate CA associated with the French
Network and Information Security Agency Agence nationale de la sécurite des
systèmes d’information, short ANSSI. It issued an intermediate certificate which
was used on a network monitoring device thus allowing MitM - supposedly with
the knowledge of all users on that network.
According to ANSSI the issuance was a ”human error which was made during
a process aimed at strengthening the overall IT security of the French Ministry
of Finance” and the incident had ”no consequences on the overall network security”[21].
Adam Langely, Security Engineer at Google and author of the blog post,
called it a ”serious breach” and in response Google immediately blocked this
intermediate CA. In a next step ANSSI as well as the other browser vendors
were notified[20].
A few days later Google decided to take a more drastic step and limit ANSSI
CA to the top-level domains of France (.fr) and also of Gouadeloupe, Guyane,
Martinique, Réunion, Mayotte, Saint-Pierre et Miquelon, Saint Barthélemy, Saint
Martin, Qallis et Futuna, Polynésie française, Nouvelle Calédonie and Terres
australes et antarctiques françaises[20].
Mozilla revoked trust in the subordinate CA certificate in question on December 09, since using certificates for interception of ”domains or websites that
the certificate holder did not own or control” is not in accordance with Mozilla’s
CA Certificate Policy[22].
Microsoft and Opera followed suit on the same day[23].
ANSSI promised to revise its processes ”to make sure no incident of this kind
will ever happen again”[21].
3.7
StartSSL
The Certificate Authority branch StartSSL of the Israeli company StartCom,
which is trusted by all major browsers, has been attacked more than once. In
the following we will give the an overview of the two major incidents in 2008
and 2011.
Incident in 2008 After a disclosure of an issue with scam mails for renewing
certificates in combination with sloppy validation of a competing CA[24] someone
tested the service of the company behind the person who disclosed - StartSSL.
The whole event took place in the last hour of 20th December 2008 and the
following day.
The attacker registered at 23:24 at StartSSL and tried a fraudulent domain
validation, which failed. The next attempts to validate domains succeeded using
a certain gmail.com mail address and manipulation the traffic between browser
and website. He was able to validate and issue four bogus certificate for sites
he didn’t own that way. The fifth attempt, issuing a certificate for verisign.com,
succeeded only in the first step – the domain validation – at 00:54. In contrast
to the other attempts, which succeeded through all steps, the issuing of that
high value domain4 failed automatically signing and the certificate was flagged
for review at 1:09.
At 1:17 the attack was detected and further steps were taken. The attackers
IP was immediately blocked at the firewall and all certificates requested by that
user were revoked. Including the creation of a new Certificate Revocation List
(CRL).
Also the upper management was informed during night. The attacker cooperated to investigate the flaw in the system and the attack was fully disclosed
at 2:00.
At 3:20 the first emergency fix were applied to the system and tested. During
the day further modification were applied and other components which might
be also been vulnerable were analyzed and patched. At 16:00 the incident was
finished.
The whole incident was discovered and the flaws fixed within fourteen hours.
No further steps like contacting software vendors or owners of the original domains were needed, because the certificates were revoked within one hour after
creating and only low-assurance class 1 certificates.
It is safe to say no relying party was damaged.
Incident in 2011 On June 15, 2011 StartSSL was target of yet another attack.
The Register [25] reported further that Founder, COO and CTO of StartCom,
Eddy Nigg, indicated that the case was not unlike the hack of Comodo earlier
that year as the perpetrators partially aimed at the very same domains, e.g.
Google, Twitter and Yahoo[26].
The attack could be warded off. Neither fraudulent certificates were issued
nor was the CA’s private encryption key in any danger since it is stored physically
separate from any component connected to the internet[25].
StartSSL decided to put the issuance of new certificates and related services
on hold for a short period of time[27].
On pastebin, Comodohacker claimed to be responsible for this hack as well,
saying that ”[...]StartCom was lucky enough, I already connected to their HSM,
4
popular domains, which belongs to well known companies and brands, often mentioned as high value domains
got access to their HSM, sent my request, but lucky Eddy (CEO) was sitting
behind HSM and was doing manual verification.”[28]
Nigg confirmed this in an e-mail to informationweek.com: ”That’s the way he
experienced it, [but] from the technical point of view it’s obviously a bit different.
But I don’t want to spoil it and provide unnecessary information, as you might
understand.”[29]
As no harm was done browser vendors were not forced to react in any kind
of way.
3.8
VeriSign
Other noteworthy incidents happened at VeriSign, an US-based company which
not only operates public CAs but also being the DNS registrar for .net .com and
.gov.
The Incidents become public due to a research of Reuters of public companies
financial reports. They were interested in the whether security incidents are
mentioned in this reports.
In October 2011 VeriSign released the information of breaches in its quarterly
Report[30]. The headline of the Section says ”We experienced security breaches
in the corporate network in 2010 which were not sufficiently reported to Management.”. So they had several breaches into their internal corporate network
and parts of the upper management didn’t get notice of it until the Reuters
article[31] got released, as some managers stated in interviews.
They claim to have the breaches investigated and the information security
group implemented countermeasures and detectors. They believe that server
which operate the DNS were not breached into. But they are also aware of
the fact, that as an victim, you can never say if discovered the full breach and
detected all malicious activities.
They have also no clue which data has been copied and how it could be affect
the Web in the future.
In summary, VeriSign hat in 2010 several breaches into the corporate network
and Servers and kept it in secret until fall 2011, where they have to state it
into a SEC Report. The public got no information about what got hacked and
how. They only claim that the DNS operation was not affected, but give no
evidence. They do not say, that there CA business was unaffected, which reveals
a uncertainty in the trust of VeriSign operated CAs.
3.9
Weak key issues
It is also important to keep in mind that not only CAs can be compromised it
is also important, that the private keys are generated properly.
As researchers proved[32], it is important to care for the randomness of the
privates key, because with weak randomness it is possible to factor the public
key efficiently.
Back in may 2008, the Debian project announced, that a vulnerability in its
OpenSSL package was found. A patch to the random number generator (RNG)code made the RNG-output predictable. As a result, tools for checking the key
material for being weak was created immediately and several administrator and
users of Debian based distribution where recommended to check all their SSL
and SSH keys.
In their paper[33], Heninger et al analyzed public accessible key material and
discovered that factorable keys are widely used. But they indicate, that most of
the vulnerable hosts are embedded devices. Which leads to the assumption that
during the production phase nobody cares for enough entropy.
In August 2013 after some cases of Bitcoin theft become public, a vulnerability in in the Java OpenSSL connector used by Android was found. The lack
of entropy resulted again weak key material.
An other Openssl Issue[34] was discovered later in August. Under certain
circumstances it was possible that child processes getting the same randomness
from the pseudorandom number generator (PRNG).
In short, there where several flaws in SSL implementations and usage discovered the last year. The problems critical to the key material are all about poor
or predictable randomness during the key creation.
4
Conclusion
We have now seen various attacks on CAs and their related services. It is difficult
to compare the incidents to each other since the amount of media coverage,
hence publicly available information, differs greatly from case to case and it is
not always clear if the full extent of the compromise has been made public.
In the following Table 2 we will nevertheless try to compare the incidents
with respect to the known facts, i.e. the kind of incident, the approximate date
the incident took place, when the media first reported about it and within which
time frame the involved parties first responded to the breach. In some cases, e.g.
TürkTrust, the incident cannot be directly categorized as one of the scenarios
described in the Chapter 2.1 since the incident occurred due to a (deliberate or
unintended) proceeding within the company itself. We will categorize these kind
of breaches as ”Internal” from the point of view of the company mentioned in
the first column, e.g. TürkTrust; from Google’s point of view this must of course
be evaluated differently.
But the most incidents rely on three kind of attacks. The CA gets hacked
and the attackers create the keys themselves. The validation check, if the signing
request is valid, fails. Or there are problems with the key material. These among
other issues cause disbelief in the trustworthiness of the WebPKI.
What has become clear is that the concept of revocation itself has considerable flaws and is not efficiently dealing with CA compromises. The EFF states
in their SSL Survey, that in the published CRLs also the reason of a certificate
revocation is flagged. During 2010 was an increasing number flagged with ”ca
compromise”. It seems the attacks and compromises increasing much since 2008,
Incidents
DigiNotar
Comodo
Scenario
Date of
Incident
Date of First
Media Coverage
CA System 17th June - August
ComproAutumn 2011 29,2011
mise
Etisalat
RA
Com- March
15, March
23,
promise
2011
2011
Internal
August, 2011 January 03,
2013
Internal/
built in device July 03, 2012
Signing Key
Internal
July 08, 2009 July 14,2009
ANSSI
Internal
TürkTrust
Cyberroam
not disclosed December 07,
2013
StartSSL 2008 Impersonation
StartSSL 2011 attempted
CA
Compromise
VeriSign
unkown
December,
January 01,
19/20, 2008 2009
June 15, 2011 June 21, 2011
2010
(Date of)
First Actions taken
19th July, only internal.starting 30th August
also public ones (tuning
OCSP,Browser)
Revocation and notification within a few hours
Revocation on December
25, 2012
Company said they look
at
RIM statement and removal tool on July 17,
2009
Revocation and notification on December 03,
2013
flaw was detected and
fixed within hours
Suspension of Service
exact date unknown,
within max. 5 days
unkown
January 02,
2012
Table 2. Comparison of Incidents
but not every breach gets public (soon) as the VeriSign breaches show, but it
is also not fully clear if earlier in time really only that little amount of incident
happened that are publicly known.
The attackers are highly professional and well equipped. Often there are
indicators of states behind the attacks.
Since revocation doesn’t work well, it would be useful to have a public log
about issued certificates like certificate transparency. This might would have
revealed some of the incidents of the past earlier.
The most of the breaches caused by hacks are revealed while MitM attacks
on chrome users. Google uses pining techniques and detect these attacks between
their products and services. So it is needed to strengthen TLS applications with
techniques like pining, notary services and public logs, because we cannot rely
on detection of the breaches and revocation.
References
1. Eckersley, P.:
How secure is https today? how often is it attacked?
(January 2014) available at https://www.eff.org/deeplinks/2011/10/
how-secure-https-today.
2. NIST: Itl bulletin for july 2012 (July 2012) available at http://csrc.nist.gov/
publications/nistbul/july-2012_itl-bulletin.pdf.
3. Venafi:
Five
must
haves
to
prevent
encryption
disasters
(April
2013)
available
at
http://de.slideshare.net/Venafi/
five-must-haves-to-prevent-encryption-disasters.
4. Nightingale,
J.:
Fraudulent
*.google.com
certificate
(January
2014)
available
at
https://blog.mozilla.org/security/2011/08/29/
fraudulent-google-com-certificate/.
5. Eckersley, P.: Iranian hackers obtain fraudulent https certificates: How close to a
web security meltdown did we get? (March 2011) available at https://www.eff.
org/deeplinks/2011/03/iranian-hackers-obtain-fraudulent-https.
6. Comodo: Comodo fraud incident report (March 2011) available at http://www.
comodo.com/Comodo-Fraud-Incident-2011-03-23.html.
7. COMODOHACKER: A message from comodo hacker (March 2011) available at
http://pastebin.com/74KXCaEZ.
8. Langley, A.:
Enhancing digital certificate security (January 2013)
available
at
http://googleonlinesecurity.blogspot.de/2013/01/
enhancing-digital-certificate-security.html.
9. TürkTrust:
Corporate identity (January 2014) available at http://www.
turktrust.com.tr/en/hakkimizda.html.
10. [email protected]: Turktrust subca abuse and mitm’ing (January 2013) available at https://groups.google.com/d/msg/mozilla.dev.security.policy/
aqn0Zm-KxQ0/x1hfTMGwE2AJ.
11. Microsoft: Fraudulent digital certificates could allow spoofing (January 2013) available at http://technet.microsoft.com/en-us/security/advisory/2798897.
12. Coates, M.:
Revoking trust in two turktrust certificates (January
2013)
available
at
https://blog.mozilla.org/security/2013/01/03/
revoking-trust-in-two-turktrust-certficates/.
13. Runa:
Security
vulnerability
found
in
cyberoam
dpi
devices.
https://blog.torproject.org/blog/
security-vulnerability-found-cyberoam-dpi-devices-cve-2012-3372
(November 2013)
14. Lawati, A.A.: Etisalat’s blackberry update intercepts communication, says
rim (July 2009) available at http://gulfnews.com/business/telecoms/
etisalat-s-blackberry-update-intercepts-communication-says-rim-1.
502062.
15. Eng, C.: Blackberry spyware dissected (July 2009) available at http://www.
veracode.com/blog/2009/07/blackberry-spyware-dissected/.
16. RIM: Rim customer statement regarding etisalat/ss8 software (July 2009)
available at http://chirashi.zenconsult.net/wp-content/uploads/2009/07/
BlackBerry_Customer_Statement_July_17_2009.pdf.
17. Choice, T.H.: Ssl/tls in a post-prism era available at https://wiki.thc.org/ssl#
EtisalatBreach.
18. Eckersley, P.: Eff to verizon: Etisalat certificate authority threatens web security (August 2010) available at https://www.eff.org/deeplinks/2010/08/
open-letter-verizon.
19. Wilson, K.: Verizon and etisalat (August 2010) available at https://groups.
google.com/forum/#!msg/mozilla.dev.security.policy/OBrPLsoMAR8/
murllApydRUJ.
20. Langely, A.:
Further improving digital certificate security (December
2013) available at http://googleonlinesecurity.blogspot.de/2013/12/
further-improving-digital-certificate.html.
21. ANSSI: Revocation of an igc/a branch (December 2013) available at http://www.
ssi.gouv.fr/en/the-anssi/events/revocation-of-an-igc-a-branch-808.
html.
22. Wilson, K.:
Revoking trust in one anssi certificate (December
2013)
available
at
https://blog.mozilla.org/security/2013/12/09/
revoking-trust-in-one-anssi-certificate/.
23. Microsoft: Improperly issued digital certificates could allow spoofing (December
2013) available at http://technet.microsoft.com/en-us/security/advisory/
2916652.
24. Nigg, E.: Untrusted certificates (January 2014) available at https://blog.
startcom.org/?p=145.
25. Goodin, D.: Web authentication authority suffers security breach (June 2011)
available at http://www.theregister.co.uk/2011/06/21/startssl_security_
breach/.
26. Nigg, E.: Cyber war (September 2011) available at https://blog.startcom.org/
?p=229.
27. heise
Security:
Angriff
auf
israelischen
zertifikatsherausgeber
(June
2011)
available
at
http://www.heise.de/security/meldung/
Angriff-auf-israelischen-Zertifikatsherausgeber-1263969.html.
28. COMODOHACKER: Another status update message (September 2011) available
at http://pastebin.com/85WV10EL.
29. Schwartz, M.J.:
How startcom foiled comodohacker: 4 lessons (September
2011)
available
at
http://www.informationweek.com/attacks/
how-startcom-foiled-comodohacker-4-lessons/d/d-id/1100043?
30. VeriSign, I.: ”form 10-q quarterly report” (October 2011) available at https:
//investor.verisign.com/secfiling.cfm?filingID=1193125-11-285850&CIK=
1014473.
31. Menn, J.:
”exclusive: Hacked companies still not telling investors”
(January 2014) available at http://www.reuters.com/article/2012/02/02/
us-hacking-disclosures-idUSTRE8110YW20120202.
32. Heninger,
N.:
”new
research:
There’s
no
need
to
panic
over
factorable
keys–just
mind
your
ps
and
qs”
(January
2014)
available
at
https://freedom-to-tinker.com/blog/nadiah/
new-research-theres-no-need-panic-over-factorable-keys-just-mind-your-ps-and-qs/.
33. Heninger, N., Durumeric, Z., Wustrow, E., Halderman, J.A.: Mining your Ps and
Qs: Detection of widespread weak keys in network devices. In: Proceedings of the
21st USENIX Security Symposium. (2012)
34. Boßlet, M.:
Openssl prng is not (really) fork-safe (January
2014)
available
at
http://emboss.github.io/blog/2013/08/21/
openssl-prng-is-not-really-fork-safe/.