Vulnerabilities / Threats

4/4/2016
03:00 PM
Adam Shostack
Adam Shostack
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

CAs Need To Force Rules Around Trust

Google Symantec flap reveals worrisome weakness in the CA system.

There was some talk a few months ago about Google's decision to revoke a Certificate Authority (“CA”) certificate. That went quiet, which I think is a shame. 

Before I get into the details and some analysis, I want to be clear that I want to discuss the Certificate Trust Infrastructure, not Symantec, whose certificate is being revoked.  I have no knowledge or opinion about their culture or motivations, and I don't mean to impugn either in what I'm writing here.  All of what I say could apply to any certificate authority.

Also, before I get into it, I want to say that I've recently read Philip Rogaway's excellent paper The Moral Character of Cryptographic Work, and so I'm going to talk about a "Certificate Trust Infrastructure" ("CTI") rather than "Public Key Infrastructure," since the latter term neuters the import of the system. I'm using the term trust here because the betrayal of these systems matters to you.  A misused CA certificate can break the security of every or any computer on which it’s installed.

So the story, in a nutshell, is that Symantec operates a part of the CTI and so does Google.  Symantec made some vague statement about "other purposes" to which a specific certificate might be used, and Google objected, then objected more by stating that they would distrust that particular certificate.

What's interesting to me is that Google is choosing to distrust that certificate, and only that certificate. This is the third time that Google has scolded Symantec in public in about as many months. (Curiouser and curiouser, as Alice said.)

So what's curious is that, through all of this, Google is taking the very moderate step of banning a single Symantec certificate, not all of them.

Now, perhaps the goal is to gradually increase pressure on Symantec, which is an admirable approach, all other things being equal. Here's the trouble: there exists some unknown set of purposes (We'll call them P.) which the CA is unwilling to disclose.  We might thus assume that P is not in the interests of those who rely on the CTI, otherwise, the CA would disclose them.  We cannot know how widespread the use will be, or at how senior a level it was approved.


What A "CA Certificate" Can Do

CAs, or Certificate Authorities are trusted to do the right thing when they sign things. In short, a CA certificate can break your security in two main ways. First, it can lie about the creators of software, and second, it can lie about the identity of web sites enabling phishing and other attacks.  (It can do other things, but for simplicity, think about those two.)  The way it does this is that the authenticity of various things are vouched for by a CA, which signs a certificate, say one labeled "Google" or "Symantec," and your software displays those names for the creator of software, or the owner of a web site.


What we might guess is that there is an employee of the CA who has P as a goal for the time period, and that said employee's bonus, or some fraction thereof, is dependent on P. So once the certificate is revoked, what might happen?  The employee might be given new goals for the year, or not. The business driver that led to P may go away, or it may double down either with carrots, sticks, or both.  We cannot know.  We might believe that Certificate Transparency will detect the P uses of the certificate.

Even if we believe that, there is going to be some period of time between Google's revocation of the certificate and the June 2016 deadline for Certificate Transparency from the CA when there will only be partial protection in place.

P violates the rules. Absent strong evidence that P is not being achieved, it's hard to fathom why this violation of trust is being accepted.  Without knowing what P is, it's hard to decide if it's being attempted or achieved.  There's a claim that Certificate Transparency makes unusual certificates detectable. That's true.

There are other, stronger claims -- such as it will lead to detection, which is perhaps true.  When someone with sufficient moxie looks at the logs, they'll likely notice. (This is of course, the 'no true Scotsman' fallacy: anyone who doesn't notice obviously lacks appropriate levels of skill.)

The CA needs to either come clean about P, or be removed by those who are trusted to select CAs.

Related Content:

Interop 2016 Las VegasFind out more about security threats at Interop 2016, May 2-6, at the Mandalay Bay Convention Center, Las Vegas. Click here for pricing information and to register.

Adam is an entrepreneur, technologist, author and game designer. He's a member of the BlackHat Review Board, and helped found the CVE and many other things. He's currently building his fifth startup, focused on improving security effectiveness, and mentors startups as a ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Google Engineering Lead on Lessons Learned From Chrome's HTTPS Push
Kelly Sheridan, Staff Editor, Dark Reading,  8/8/2018
Election Websites, Backend Systems Most at Risk of Cyberattack in Midterms
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/14/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-8405
PUBLISHED: 2018-08-15
An elevation of privilege vulnerability exists when the DirectX Graphics Kernel (DXGKRNL) driver improperly handles objects in memory, aka "DirectX Graphics Kernel Elevation of Privilege Vulnerability." This affects Windows Server 2012 R2, Windows RT 8.1, Windows Server 2016, Windows 8.1, ...
CVE-2018-8406
PUBLISHED: 2018-08-15
An elevation of privilege vulnerability exists when the DirectX Graphics Kernel (DXGKRNL) driver improperly handles objects in memory, aka "DirectX Graphics Kernel Elevation of Privilege Vulnerability." This affects Windows Server 2016, Windows 10, Windows 10 Servers. This CVE ID is unique...
CVE-2018-8412
PUBLISHED: 2018-08-15
An elevation of privilege vulnerability exists when the Microsoft AutoUpdate (MAU) application for Mac improperly validates updates before executing them, aka "Microsoft (MAU) Office Elevation of Privilege Vulnerability." This affects Microsoft Office.
CVE-2018-8414
PUBLISHED: 2018-08-15
A remote code execution vulnerability exists when the Windows Shell does not properly validate file paths, aka "Windows Shell Remote Code Execution Vulnerability." This affects Windows 10 Servers, Windows 10.
CVE-2018-8398
PUBLISHED: 2018-08-15
An information disclosure vulnerability exists when the Windows GDI component improperly discloses the contents of its memory, aka "Windows GDI Information Disclosure Vulnerability." This affects Windows 7, Windows Server 2012 R2, Windows RT 8.1, Windows Server 2008, Windows Server 2012, W...