Introduction to CryptographyPublic Key Infrastructure

Authentication

An important point from the Needham-Schroeder protocol and the attackson it: authentication—knowing to whom you’re actually talking—can be asimportant as confidentialityCryptography has to provide bothSometimes, authentication has to be bidirectional

Introduction to Cryptography 2 / 47

Bidirectional Authentication

Recent phone experience: “Hi, I’m from your doctor’s office; could yougive me your date of birth and social security number so I know I’m talkingto Steve Bellovin?”Me: “No, you tell me; how do I know who you are?”Them: “I just told you!”Me: “And why should I believe you?”Them:Me:

Introduction to Cryptography 3 / 47

Authentication versus Authorization

Authentication is a way to prove who you areIt is not the same as what you’re allowed to do—that’s authorizationBut most systems use authentication as a step towards authorizationMore on this later in the term

Introduction to Cryptography 4 / 47

Finding a Key

Alice wants to talk to Bob, so she searches for his public key

Will she get the right answer?

Introduction to Cryptography 5 / 47

Certificates

A certificate is a digitally signed binding between an identity and a public key.Will this work?

Introduction to Cryptography 6 / 47

A Look at the Physical World

The certificate has to be issued bysomeone you trustThey actually have to do a good jobverifying identityThere are indications in thecertificate showing the proper form

Introduction to Cryptography 7 / 47

History of Certificates

Invented in 1978 by an MIT undergrad, Loren M. Kohnfelder, in his seniorthesis(Evidence suggests that by the early 1980s, the NSA adopted certificatesfor its secure phones)Adopted for the OSI networking standard’s “directory” projectTheir format, known as X.509, is the primary certificate standard usedtoday

Introduction to Cryptography 8 / 47

What are Certificates Used For?

Verifying website identityVerifying other encrypted communications sessionsVerifying executablesVerifying and protecting emailMore

Introduction to Cryptography 9 / 47

Checking a Certificate in Firefox

All desktop browsers have some way to display sites’ certificatesIntroduction to Cryptography 10 / 47

Columbia’s Certificate: The Basics

The certificate includes the organization name and address, and the CA’sname and address.Note the top: it shows the certificate chain from the trust anchor.

Introduction to Cryptography 11 / 47

Columbia: Other Essential Data

Note the validity period, actual domain names (called “Subject Alt Names”),and the key and algorithm.

Introduction to Cryptography 12 / 47

Expiration

Why limit certificate lifetime?Limit the damage in case of private key compromiseLimit the amount of revocation data that has to be keptOrganizations have finite lifetimes—why leave their abilities aroundforever?And algorithms age

Introduction to Cryptography 13 / 47

Columbia: Policies and Revocation

The certificate has the CA’s policies and revocation mechanisms.

Introduction to Cryptography 14 / 47

How Do You Revoke a Certificate?

Revocation is hard! Verification can be done offline; revocation requiressome form of connectivityPublish the URL of a list of revoked certificates in a Certificate RevocationList (CRL)R One reason for certificate expiration dates; you don’t need to keeprevocation data foreverOnline status checking (OCSP)—check a server in real-time for thecertificate’s statusNote: OCSP has privacy implicationsNSA secure phones apparently use a flooding algorithm to pass aroundlists of revoked certificates—works well because of comparatively closedcommunities

Introduction to Cryptography 15 / 47

Why Revoke Certificates?

Private key compromisedCancel authorization associated with certificateCA key compromised, e.g., DigiNotarAlgorithm compromised (rare use)

Introduction to Cryptography 16 / 47

Who Issues Certificates?

Who can create this binding?It’s a trust issue—the other party to the connection has to trust whoeverissued your certificateGenerally, the decision is made by our softwareCertificate issuers are called certificate authorities—CAs

Introduction to Cryptography 17 / 47

Certificate Authorities

What makes a CA a CA?More precisely, how do you know who is authorized to issue a givencertificate?And why do you trust them?

Introduction to Cryptography 18 / 47

Trust Anchors

All cryptographic trust has to start somewhereFor any given application, you need to pick your trust anchorsFor the Web, that choice has been made for you: every OS or browser hasa built-in CAThe collection of hardware, software, people, policies, and procedures toissue certificates is called a PKI: public key infrastructure

Introduction to Cryptography 19 / 47

Who Should Issue Your Certificates?

Three situations1 Public-facing website2 Internal corporate website3 Your app talking to your server

Introduction to Cryptography 20 / 47

Certificates for Public-Facing Website

Remember that the other party has to trust your CAThat means that everyone else’s browser has to trust the CA you chooseAnd that in turn means that you have to use a CA trusted by mostbrowsers in the worldMicrosoft can add its own CAs to Edge, Apple can with Safari, Mozilla canfor Firefox, and Google can for Chrome—but even they want their sites tobe reachable by everyone elseConclusion: you have to trust the common set of CAs, even if you’re reallybig

Introduction to Cryptography 21 / 47

Certificates for Internal Websites

In medium or larger-size enterprises, the IT group manages most internalcomputersIt generally has the power to install new CAs on employee machinesAccordingly, companies can use their own CAs internally if they want—butthey have to know how to run a CA(This is sometimes done for firewalls—more on that later in the term)

Introduction to Cryptography 22 / 47

How to Issue Certificates

Typically, user generates a key pair, and presents the public key, identity,and proof of identityCertificate Authority (CA) signs the certificate and gives it backNote: certificates are self-secured; they can be verified offline

Introduction to Cryptography 23 / 47

Mystique

“Organizations are regularly told that they are complex, require ultra-highsecurity, and perhaps are best outsourced to competent parties. Setting up acertificate authority (CA) requires a “ceremony”, a term with a technicalmeaning but nevertheless redolent of high priests in robes, acolytes withcensers, and more. This may or may not be true in general; for most IPsecuses, however, little of this is accurate. (High priests and censers are definitelynot needed; we are uncertain about the need for acolytes. . . )”

Introduction to Cryptography 24 / 47

Can You Run Your Own CA?

Yes, but it’s hardIt’s not inherently hard, but the documentation is pretty poorTwo major issues: verifying the identity of the requester, and protectingthe certificate-signing keyThere are decent web pages on how to create “self-signed certificates”Should I give a homework assignment on creating certificates? Maybe. . .

Introduction to Cryptography 25 / 47

Certificate Lifecycle

1 Generate a key pair2 Request a certificate from a CA3 Use the certificate4 The private key is compromised5 Revoke the certificate

Introduction to Cryptography 26 / 47

Let’s Encrypt

The Electronic Frontier Foundation started a free CA calledletsencrypt.org

It verifies identity by making sure the requester has control of the web siteor the DNS entriesThere are automated client tools, e.g., certbot for obtaining certificates

Introduction to Cryptography 27 / 47

Your Own App

If you control the app, you control whom it trustsYour own app can verify that your own CA issued the certificate yourserver is usingYou not only don’t need a popular CA, you shouldn’t use one

Introduction to Cryptography 28 / 47

But What About Identity?

Certificates are about binding identity to a public keyWhat identity should be there?It depends on the type of certificate

Introduction to Cryptography 29 / 47

Web Site Identities

For web sites, you need to verifythe user-visible name: thedomain nameBut many websites have multiplenames—if nothing else,example.com andwww.example.com

Those names must all be listed inthe subject Alt Names field

Introduction to Cryptography 30 / 47

Other Certificates

Email The sender’s or the recipient’s email addressExecutables The vendor

iPhone Executables Apple!

Introduction to Cryptography 31 / 47

Verifying Certificates

Verifying certificates is a complex businessThere are many things to check, and many ways to get it wrongIf you can, use a standard library to do this checking

Introduction to Cryptography 32 / 47

The Certificate Itself

Is it syntactically correct?Is it expired?Does the resource’s name match what’s in the certificate?Who signed it?

Introduction to Cryptography 33 / 47

Certificate Chains

Very few CAs sign certificates directly—and that’s the correct decisionCAs issue a lot of certificates, which means that the signing key has to beonline a lot, and hence could be hackableInstead, they periodically issue themselves an intermediate certificatewith a limited lifespan

R Limit the effect of any compromise!So: you need to verify the certificate all the way up the chain

Introduction to Cryptography 34 / 47

Certificate Scope

Some intermediate certificates restrict the scope of the certificates theythemselves can signExample: if a company has an “official” CA certificate for internal use, thatcertificate can only sign other certificates within the companyThis has to be verified, too

Introduction to Cryptography 35 / 47

Checking the Cryptography

Are all of the algorithms listed acceptable to you?Example: you do not want MD5 or short RSA moduli anywhere in thecertificate chainDoes the message or file in question have the right hash?Does the signature of that hash validate?You then have to verify the signatures on every certificate up to a CA youtrust

Introduction to Cryptography 36 / 47

Security Analysis: Is PKI Secure?

What are the weak points?Who can attack them?

Introduction to Cryptography 37 / 47

Attacking the Cryptography

Today’s standards—SHA256; 2048-bit RSA or 256-bit ECDSA—are believedto be secureBut when web encryption started, people used MD5 and 1024-bit RSA;both are currently believed to be insecureSome sites continued using older algorithms well after they were known tobe badAnd there have been exploits—but probably by intelligence agencies

Introduction to Cryptography 38 / 47

Flame

The Flame malware relied on a software vendor using MD5 in itscertificates, well after they should have stopped (and well after Windowsshould have rejected such certificates)MD5 was known to be weak—but Flame used a previously unknowncryptanalytic mechanism to attack MD5Most hackers are not expert cryptanalysts. . .Flame also exploited a design error by Microsoft and hijacked the WindowsUpdate mechanism

Introduction to Cryptography 39 / 47

Microsoft and MD5

Microsoft has excellent cryptographers; they knew that MD5 was brokenBut: they had to preserve backwards compatibility for long enough for allof their customers to migrate to a stronger hash functionSites that had upgraded their own infrastructure could still be vulnerableto Microsoft’s decision

Introduction to Cryptography 40 / 47

Private Key Compromise

Sites’ private keys can be stolenStuxnet relied on two different stolen vendor code-signing keys(Were these keys in HSMs? They should be)

Introduction to Cryptography 41 / 47

Identity Spoofing

In 2001, someone impersonated Microsoft and got two fake code-signingcertificates from VeriSignVeriSign employees did not check the requester’s credentials properlyBut: their back-end audit process caught the problemRevocation didn’t really wrok then, so Microsoft shipped a patch to ignorethose two certificates

Introduction to Cryptography 42 / 47

Buggy Code

Windows 10 recently had a certificate-checking bug: under somecircumstances, it would accept anythingThis bug was found by the NSA, which thought it was so scary it toldMicrosoft and issued its own advisory

Introduction to Cryptography 43 / 47

Blind Trust

Code-signing certificates are (at best) statements of where code camefrom, not that it’s harmlessSome hackers have purchased genuine code-signing certificates fromApple or MicrosoftVictims’ operating systems accept the malware, because it’s digitallysignedThere is a confusion of identity with authorization and/or benignity

Introduction to Cryptography 44 / 47

Hacking

Hackers, believed to be linked to Iran, compromised the DigiNotar andComodo CAsThe DigiNotar private keys were stored in an HSM, but the attackercontrolled the computer that controlled the HSM, and hence was able toget it to sign bogus certificatesThe attack put DigiNotar out of business

Introduction to Cryptography 45 / 47

Conclusions

Certificates are useful but they aren’t panaceasBuggy code can beat good cryptoNote the analysis: at some point, every piece of the security chain forcertificates has been compromised

Introduction to Cryptography 46 / 47

Questions?

(American redstart, Morningside Park, September 21, 2020)