3.4.1  Key and certificate properties

Now that we have talked about how keys and certificates can be used to guarantee the integrity and confidentiality of data that are transmitted electronically, let us look into different types of keys and certificates that are commonly used.

Keys are used to encrypt data, and there are different types of algorithms that are used to generate these keys. The most commonly used key algorithm is RSA, originally pioneered by Ron Rivest, Adi Shamir, and Leonard Adleman in 1977, out of the Massachusetts Institute of Technology. While RSA keys are still the de facto standard, there are a number of other algorithms that have also been used over the years: Digital signature algorithm and elliptic curve cryptography (ECC). Of these, ECC offers the advantage of smaller key sizes (for the same amount of computational complexity) that makes it ideal for resource-constrained environments such as IoT devices.

Certificates are vehicles that make it possible to share the public key component of an entity’s key pair (Figure 3.3). X509 is a standard that is widely deployed and understood when it comes to defining the format of digital certificates. A typical certificate, much like a physical passport, has a number of properties that can be used to identify the owner of the key pair and its intended usage. Some of these are as follows:

• Validity: governs when a certificate was issued and when it expires to ensure that keys are periodically regenerated (much like passwords) to ensure that they do not become susceptible to cracking attempts
• Subject distinguished name: who the certificate was issued to—this could be a human or a machine identity
• Issuer distinguished name: who issued the certificate—depending on whether the issuer is a known or unknown entity; this can be used to determine the level of trust placed in the owner of the certificate
• Key usage and extended key usage: controls what the certificate can be used for (to authenticate digital identities, to encrypt messages, for smart card authentication, etc.)
• Public key: records the public key part of the entity’s key pair that can be used to send encrypted messages to the entity

Figure 3.3   Digital certificate properties.

3.4.2  Public key infrastructure

Public key infrastructure (PKI) is used to refer to the ecosystem that controls the issuance, storage, and distribution of digital certificates and includes the following components:

• Certification authority (CA)—This issues digital certificates. CAs can be public (trusted by anyone on the Internet) or private [trusted only by specific organization(s) for the purposes of internal transactions] and are the root of trust.
• Registration authority (RA)—This is responsible for the verification of identities prior to the issuance of certificates.
• Certificate database—This maintains a record of certificates that have been issued or revoked for audit purposes.
• Key escrow/archival server—This is used to store copies of private keys corresponding to entities to audit/inspect communications between human and machine entities or for disaster recovery purposes.
• Certificate management system—This uses centrally defined policies that govern the issuance, distribution, and life cycle management of certificates.
• Certificate revocation lists (CRLs)—Certificates that have been issued but do not need to be trusted any longer (for a variety of reasons such as key compromise and entities that have left the organization) are revoked by the issuing authority (CA) and put on a “blacklist” called a CRL that can be used by relying entities to check on the status of known/unknown parties in a transaction.

3.4.3  Cryptographic protocols (SSL and TLS)

As described earlier, public key cryptography provides two distinct benefits—authentication and encryption. Cryptographic protocols utilize both of these benefits to secure communications over computer networks. In any such interaction, there is a “client” (for example, a browser) that initiates the transaction to a “server” (say, a website). To secure the data that are being transmitted (say, credit card information in an e-commerce transaction), and to ensure that the data are being sent to the right server (for example, a retail website), an elaborate exchange takes place between the two parties in the transaction:

1. The client initiates the transaction by sending a “Client Hello.”
2. The server responds with a “Server Hello” and its (public key) certificate.
3. The client creates a (symmetric) session key.
4. The client encrypts the session key with the public key extracted from the server certificate and sends the encrypted session key to server—this ensures that only the server can decrypt and access the client generated session key.
5. The server decrypts the session key.
6. The session key is used for the remainder of the SSL session.

We introduced SSL earlier in this section. TLS was proposed as a stronger alternative to SSL in 1999 and is now the required by most modern applications for encryption. Like with SSL, TLS has gone through multiple versions with TLS 1.3 being the latest version of the protocol.

While SSL/TLS are most often associated with websites, where the client application is typically a web browser, these protocols can also be used by other applications such as e-mail, instant messaging, voice over Internet protocol (VoIP) and printing/faxing.

3.4.4  Symmetric keys

We introduced the notion of “symmetric keys” as part of the discussion on cryptographic protocols in the previous section. Unlike asymmetric key encryption where there are separate public and private keys, symmetric key algorithms use the same keys for both encryption and decryption. Symmetric keys are preferred over asymmetric keys as they offer better encryption performance, yet have the requirement of both parties in a transaction needing access to the (same) symmetric key. It is for this reason that symmetric keys are typically used to secure data at rest—disk encryption, file encryption, database encryption, etc. To secure data in motion, symmetric key encryption is used (to encrypt the data) in conjunction with asymmetric key pairs (to authenticate the participants and encrypt the symmetric key used for a session).

3.4.5  SSH

SSH is another example of a cryptographic protocol that is best known for accessing and administering remote servers, mostly for non-Windows platforms, although Microsoft has recently added support for SSH in Windows 2016. SSH can be used to establish secure communication channels over unsecured networks, typically for remote login scenarios. If SSL/TLS is how applications interact with one another, SSH is how users can administer these applications. SSH can also be used by machines to move data between machines in different networks and hence serves as an identification and access protocol. While SSH also depends on asymmetric key cryptography, there are important differences—there is not a notion of certificates with SSH, only keys. As such, there is no identifying meta-data about SSH keys, beyond where they are located, that can be used to identify the owner of the SSH key pair (be it a human or a machine identity). There is also no validity associated with an SSH key pair—SSH keys can live forever. Most importantly, SSH keys are typically self-generated—there is no notion of an issuing authority such as a CA for certificates. This last distinction becomes important in the context of how trust is established for SSH sessions, a concept that will be described in detail in the next section.

3.5.1  Trust models

CAs, as described earlier, can be public or private. The list of publicly trusted CAs is maintained and managed by the CA Browser (CAB) forum (https://cabforum.org/) and is dependent on the community to control which CAs are trusted by default on various computer systems. With private CAs, it is typically up to the enterprise that owns and operates the CA to govern where they are trusted. Regardless of public or private CAs, one of the biggest advantages of a PKI is the ability to scale trust within and outside the enterprise. There are essentially two trust models:

• Direct trust model—The public key certificate of the entity is directly trusted by the relying party. Any changes to the certificate (upon renewal, reissuance, etc.) will require that trust be reestablished, manually. SSH is an example of a direct trust model, where every SSH (public) needs to be explicitly trusted in order to gain access with the private key.
• Derived or delegated trust model—The issuing authority (CA) is what is trusted by the relying party—in essence, any (server or client) certificate that chains up under the trusted CA is considered trustworthy. This allows for certificate reissuance or new identities to be established without having to redefine the trust relationship (as long as the issuing CA continues to operate within its defined parameters). Trust is established at the CA level and inherited by any entity that chains up under that CA. This is why digital certificates are so essential to managing trust within and outside the enterprise. Assuming the list of trusted CAs is secured and controlled, new certificates or identities can be established seamlessly allowing the system to scale, effectively infinitely.

3.5.2  Attack vectors

Keeping the aforementioned trust models in mind, there are a few well-understood attack vectors that malicious actors have tried to exploit to circumvent the security afforded by the PKI trust models:

• CA compromise and fraudulent certificate scenarios
  • Impersonation: Trick RA into issuing a fraudulent certificate.
  • RA compromise: Infiltrate RA or steal credentials and authorize fraudulent certificates.
  • CA system compromise: Malware or other infiltration used to get fraudulent certificate signed by a trusted CA (without getting copy of the CA’s private key).
  • CA key theft: Stolen or derived copy of the CA private key is used to issue fraudulent certificates.
  • Root CA compromise: Issue fraudulent certificates from the root CA (via system or signing key compromise).
• Impersonation Bob authenticates Bank.com using the server’s certificate. Eve routes Bob to a fraudulent site by poisoning the domain name system (DNS) (typically by attracting Bob to connect to a rogue Wi-Fi network) or sending him a message with a specially crafted address (URL). By using an unauthorized certificate, Eve fools Bob into thinking that he is interacting with Bank.com. Most phishing campaigns attempt to exploit this vulnerability.
• Forged digital signatures Bob digitally signs documents authorizing fund transfers. Eve is able to forge Bob’s signature using the fraudulent certificate.
• Encryption eavesdropping (man-in-the-middle) Bob normally connects to Gmail.com directly and verifies the authenticity of the server using its certificate. Bob is redirected through Eve’s server and presented with a fraudulent certificate that claims to represent Gmail.com. Bob (more accurately, the application Bob uses) accepts the certificate that was presented. Eve can view all encrypted data. As instances of inbound malware continue to threaten corporate security, enterprises have resorted to implementing “controlled” man-in-the-middle (MITM) to inspect all inbound traffic. This is facilitated by the distribution of asymmetric key pairs to specialized SSL/TLS inspection devices, which then use the (shared) keys to intercept inbound traffic and scan for malware.

3.5.3  Code signing

Just as with web sites, a code also needs to be identified before applications or operating systems allow the code to be executed. The goal is to provide assurance about the publisher of the code and that the originator code has not been tampered with (this mitigates the threat of a malicious actor modifying otherwise legitimate code for nefarious purposes). As such, the signing of code is considered to be an important business function, but is rarely a centralized process today. Instead, most organizations enable developers or build systems to have direct access to code-signing keys, which leads to very little visibility about what is being signed and by whom. Even worse, the distributed nature of these credentials makes it hard to secure them, and thus, they are a popular target for malware. As such, code-signing keys are the most attacked type of cryptographic credentials, which is borne out by data—the total number of signed malicious binaries exceeded 20 million in 2016 (McAfee Threat Report 2016). In response to this threat vector, the CA Security Council released recommendations on best practices (Code-signing requirements 2016), which include the need for the following:

• Minimizing direct access to code signing keys
• Protecting private keys by storing them on hardware security modules
• Time-stamping all signed codes
• Validating and virus scanning code before signing
• Rotating code-signing keys periodically, to prevent the overuse of key material

3.6.1  Significant events

Here is a brief history of significant key- and certificate-related attacks and breaches—mostly as a result of lax security controls implemented by the issuers of these credentials (CAs):

• 2001—VeriSign issues Microsoft Corporation code-signing certificate to a non-Microsoft employee. VeriSign, Inc. advised Microsoft that on January 29 and 30, 2001, it issued two VeriSign class 3 code-signing digital certificates to an individual who fraudulently claimed to be a Microsoft employee. The common name assigned to both certificates is “Microsoft Corporation” (VeriSign mis-issuance 2001).
• 2008
  • Thawte issues certificate for Live.com to a non-Microsoft employee.
  • Attacker uses an unauthorized e-mail address to obtain a valid certificate for a Microsoft domain (PKI Failures 2017).
  • Comodo issues unauthorized Mozilla certificate.
  • Certstar, a Comodo reseller, failed to perform basic validation checks as part of its RA responsibilities prior to issuing a publicly trusted certificate to http://www.mozilla.com (Mozilla mis-issuance 2008).
• 2009—code-signing certificates used to sign malware (“StuxNet”) In what was probably the first certificate-based attack that was attributed to a nation state as part of a cyberwarfare campaign, stolen certificates from RealTek Semiconductor, a hardware manufacturer in Taiwan, and JMicron Technology, a circuit maker, also located in the same business park in Taiwan, were used to mask and trust malware. The malicious code was then used to allegedly conduct attacks that caused significant disruption and damage to Iran’s nuclear program. The level of sophistication used to craft these attacks was stunning and served as a blueprint for a number of cyberattacks for years to come (StuxNet 2011, StuxNet 2013).
• 2011—Comodo issues nine counterfeit certificates (Google, Yahoo, Live, Skype, and Mozilla).
  • Much like in 2008, Comodo depended on resellers to validate the ownership of domains prior to issuing certificates, instead of enforcing these requirements or doing it themselves. At least two of Comodo’s resellers (GlobalTrust and InstantSSL) were among those.
  • StartSSL CA compromise.
  • While the details of the compromise were not made public, the StartSSL CA essentially suspended services for a week because of a breach. The breach did not impact the validity of previously issued certificates (StartSSL compromise 2017).
  • Dutch CA DigiNotar compromised. In what was probably the most disruptive of CA-related breaches, DigiNotar ended up issuing hundreds (531 to be exact) of rogue certificates for highly trafficked websites (to a total of 344 domains, including Google.com), which were subsequently abused in a large scale attack in August 2011 to conduct mass surveillance of Internet users in Iran (DigiNotar 2012). A hacker was able to exploit a vulnerability in DigiNotar’s externally deployed application servers to get on to the company’s network. Once there, the hacker took advantage of poor network security controls, including the Windows Remote Desktop and weak domain administrative passwords to get access to the CA infrastructure. DigiNotar was a relatively popular CA, with multiple CA instances, including one that issued certificates to the Dutch government. The impact was so severe that the Dutch government allegedly asked their citizens to return to using pen and paper in their interactions with the government (DigiNotar 2011b). As a result of the compromise, browser vendors Microsoft (Internet Explorer), Google (Chrome), Mozilla (Firefox), and Apple (Safari) blacklisted and removed the Diginotar CA hierarchy from their trust stores. In the wake of this devastating hack, DigiNotar filed for bankruptcy (DigiNotar 2011c). In what was a troubling footnote, the hacker also claimed to have hacked into other CAs, including GobalSign and four others that he would not name (DigiNotar 2011a).
  • Turktrust The Turkish CA inadvertently issued two unauthorized intermediate CA certificates to its customers (TurkTrust Fiasco 2013). While one was immediately found and revoked, the other continued to operate with the trusted intermediate cert. As part of its efforts to inspect encrypted outbound traffic, this customer then used the intermediate CA certificate to issue certificates to popular sites like Google.com (again!). Google Chrome’s “public key pinning” feature surfaced this issue, and manifested itself as warnings to the user in their browsing experience.
• 2012—Microsoft CA certificates forged by exploiting MD5 (Flame) Malicious actors were able to forge a fake intermediate CA, taking advantage of a by then weak digital signature algorithm (MD5) (Flame Collision 2012a, MD5 Hash Clash 2008). They then used this forged CA (Microsoft unauthorized issuance 2012) to issue certificates that made it look like they were approved by Microsoft (Flame Collision 2012b). These certificates were used to sign a malicious code that was then distributed as Microsoft software updates, which was then used to perform an MITM attack against victims (Flame Collision 2013d). Much like with the StuxNet attack from a couple of years earlier, analysis of the attack vector by the Laboratory of Cryptography and System Security (CrySyS) at the Budapest University of Technology and Economics suggested a “a government or nation state with significant budget and effort, and may be related to cyber warfare activities” (Flame Collision 2012c).
• 2013
  • DigiCert issues bogus code signing certificate to Buster Paper Comercial, a Brazilian company. In yet another instance of malware that was found signed with a legitimate code-signing certificate, malicious actors used a signed PDF document to steal banking passwords. Unlike incidents like StuxNet or flame, the certificates did not appear to be stolen or forged. Instead, the attackers exploited lax security controls at the issuing CA (DigiCert) to obtain a certificate that was issued to Buster Paper, a Brazilian company—probably by spoofing the e-mail address that was used to validate ownership of the domain that the certificate was issued to (DigiCert-BusterPaper 2013).
  • ANSSI issues rogue certificates for Google domains. The Agence nationale de la sécurité des systèmes d’information (ANSSI), affiliated with the French Ministry of Finance, and chartered with the responsibility to protect government systems against cyberattacks, was found to have issued several certificates to Google domains without authorization (ANSSI mis-issuance 2013b). ANSSI operated an intermediate CA that chained under a root authority that is trusted by most browsers, and it signed certificates that were allegedly used to inspect encrypted traffic on a private network. ANSSI stated that the certificates were issued as a result of human error and preemptively revoked the issuing CA certificate (ANSSI mis-issuance 2013a).
• 2014—Indian National Informatics Center (INIC) issues unauthorized Google domain certificates. In July, security engineers from Google stated that they had identified several certificates for Google domains that had been issued without authorization by the National Informatics Centre, a branch of the Indian Ministry of Communications and Information Technology. In all, at least 45 SSL certificates were found to be improperly issued to Google and Yahoo web properties, through the issuance of an unauthorized intermediate CA. In the aftermath of this incident, Microsoft, Google, and other vendors updated their list of trusted issuers to revoke trust in this particular CA (INIC Compromise 2014).
• 2015—Chinese Root CA China Internet Network Information Center (CNNIC) issues subordinate CA cert to MCS Holdings, which then issues certificates for Google domains In an incident that had a lot of parallels to the INIC incident from 2014, a root authority operated by the CNNIC) issued a certificate to an intermediate entity, MCS Holdings, based out of Egypt. The intermediate CA issued a number of unauthorized certificates to Gmail and several other Google web properties in efforts to implement controlled MITM SSL inspection (CNNIC 2015a). Much like with the INIC incident, browsers such as Google Chrome and Mozilla Firefox proceeded to revoke trust in the entire CA chain, starting with the CNNIC root CA (CNNIC 2015b). Symantec (formerly VeriSign) issued certificates to unregistered and unauthorized domains. At the onset of an event that would have much bigger ramifications down the line, Symantec was found to have generated a number of internal test certificates for popular websites such as Google and Yahoo in a manner that was not consistent with its certificate issuance policies. At the time, 162 unauthorized certificates were found to be issued, but this number seemed to grow substantially later (Symantec mis-issuance 2016). In what was an indicator of things to come, Symantec fired the engineers responsible for the incident, but all signs pointed to a bigger, more systemic problem (Symantec mis-issuance 2015).
• 2016—more (allegedly as many as 30,000) misissued certificates by Symantec In what has thus far been the most disruptive certificate authority-related event, with global ramifications, an audit of Symantec’s certificate issuance practices revealed a much bigger problem with how the CA ran its operations. Specifically, the CA, which has historically been one of the world’s well-known and trusted issuer of certificates, employed poor validation practices at its registration authorities. A number of registration authorities around the world were found to be not vetting the identities of certificate requestors with potential impact on nearly 30,000 certificates that could have been mis-issued. In reaction to this event, and a brewing battle between the CA and browser community [both part of the CAB forum (https://cabforum.org/)], which serves as the custodians of what can be trusted by browsers, applications, and devices around the world) over the control of trust lists, Google took the drastic step of requiring Symantec to reissue all of its certificates. Additionally, the browser vendor revoked the CA’s ability to issue extended validation (EV) certificates and imposed the restriction of issuing all new certificates with shorter validity times. The CA took exception to this course of action, disputed the alleged extent of the mis-issuance, and argued for a more collaborative approach that would not impact their ability to continue to run as a business while not being as disruptive to the ecosystem as a whole. Most importantly, organizations that had contractual agreements with Symantec to issue their digital certificates, and thus their reputation and brand on the Internet, were left in the uncomfortable position of having to either reissue all of certificates and then update all their websites and applications that depended on these certificates or have to move off Symantec and to another certificate issuer. Both options were severely disruptive and surfaced lots of talk in the industry about both the dependency on the prevalent hierarchical trust model and the ability of a few vendors to impact so many that depended on the Internet for critical functions. At the time of writing, this incident has yet to be played out to its conclusion, but it does speak to the foundational impact of how trust needs to be established and maintained on the Internet.

While not related to certificate mis-issuance, there are a couple of other noteworthy events that speak to the overall impact of encryption technology on our lives today that cross the boundaries between normal, day-to-day business or personal interactions and the trade-off between security and privacy in general.

3.6.2  Edward Snowden

Edward Snowden was a former Central Intelligence Agency employee and contractor for the US government who copied and leaked classified information to several news publications, without authorization, in 2013, from the National Security Agency (NSA) while employed by Booz Allen Hamilton (Snowden 2017). The contents of the classified documentation revealed several global surveillance programs that were run by the US government, with the cooperation of telecommunication companies and several European governments.

While the intent of his actions has been under a lot of debate, what was noteworthy was this comment:

Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. (Snowden 2013)

Put another way, Snowden disclosed aspects of encryption that were being exploited by nation states to monitor individuals and organizations around the world. Yet Snowden himself leveraged encrypted channels to exfiltrate data from the NSA, one of the most security-conscious organizations in the world. His preceding comment was to highlight the difference between the theoretical and practical aspects of implementing encryption.

A number of the tools and applications that were used by Snowden became popular in the aftermath of this incident—so much so that James Clapper, then director of National Intelligence, had this to say:

As a result of the Snowden revelations, the onset of commercial encryption has accelerated by seven years. (Snowden 2016)

Asked to explain this comment, he then followed up with the following:

The projected growth maturation and installation of commercially available encryption—what they (the NSA) had forecasted for seven years ahead, three years ago, was accelerated to now, because of the revelation of the leaks.

Indeed, the Internet hit a seminal milestone early in 2017—more than 50% of all web traffic is now encrypted, per the Electronic Frontier Foundation (EFF) (Encrypted Web 2017). Most popular messaging applications have implemented “end-to-end” encryption today, with the intent of reassuring their customers about the security and privacy of their data and communications. This extra layer of security afforded by encryption has in turn been leveraged by malicious actors and terrorists to escape detection in their attempts to cause damage. One such incident is outlined next.

3.6.3  Apple vs FBI

In response to the San Bernadino terror attacks of 2015 in the United States, the Federal Bureau of Investigation (FBI) needed to inspect the communication of the perpetrators to identify enablers of the attack and determine the possibility of other terrorist cells within the country. The data in question were encrypted on the iPhone of one of the attackers, and because of how encryption is implemented within the Apple ecosystem, getting access to the data proved to be especially hard for the FBI that was tasked with identifying the origins of the attack and potentially others in the future. As such, the FBI requested Apple’s help in decrypting the encrypted content, but the vendor refused, citing privacy concerns about the implications of providing a “backdoor” to government agencies that could then exploit these data to spy on other citizens or foreign nationals. A six-week-long legal battle ensued, potentially setting the landscape for the battle for the balance between privacy and law enforcement in an age where communications are increasingly conducted online. On one hand, bad actors are exploiting the advantages of end-to-end encryption built in to popular apps such as WhatsApp, iMessage, and Signal to cover their tracks and advance their agenda. On the other, governments around the world including the United States, United Kingdom, and Russia are stipulating requirements that grant them access to sensitive data that can be used to work around privacy stipulations. In a worrisome twist to the proceedings, the Department of Justice ultimately was able to decrypt the communications via as yet undisclosed means, precluding Apple from having to implement and hand over a decryption mechanism to the government. While this particular incident ended without requiring cooperation with the government, more events will surely occur in the not too distant future, which will reinvigorate this debate.

The United States is not alone in their attempts to crack encryption—a number of governments around the world have required access to technology that can inspect encrypted traffic, leading to intense debate around the line that exists between protecting data . . . and exploiting it.

3.7.1  Virtualization and cloud

While the notion of virtualization has been around since the age of the mainframe (originally conceived in the 1960s), the use of cloud computing to improve the efficiency of resource utilization is relatively newer. As organizations increasingly look to the use of DevOps and cloud (Gartner expects that by 2020, a corporate “no cloud” policy will be as rare as a “no Internet” policy today) to accelerate innovation without incurring significant expenses, they have started to look at ephemeral, “immutable” infrastructures that are deployed only for as long as they need to exist. How this impacts machine identities is that there is now a need for rapid certificate issuance, in response to elastic workloads, and that machine identities are relatively short lived. Organizations are now building up and tearing down their IT infrastructures multiple times a day as they embrace the idea of “infrastructure as code” as they attempt to realize efficiencies of operation and cost savings.

This has surfaced a need for better management frameworks for keys and certificates—how do you effectively address the trust issues caused by continuously changing identities, wherein new credentials are being issued, and reissued, at very high frequencies? Additionally, since certificates will not need to “live” long, hitherto recommended best practices such as expiration monitoring, instance validation, etc. will cease to be as important as these credentials will be replaced well before they expire. Conversely, machine identities that are no longer current will need to be effectively destroyed to mitigate the impact of unauthorized access to a trusted credential.

Popular cloud providers such as Amazon (AWS), Microsoft (Azure), and Google (GCP) now offer some level of certificate issuance and management capabilities as they bolster their infrastructure-as-a-service and platform-as-a-service offerings to address customer needs.

3.7.2  Certificate transparency

As was referenced in previous sections, one of the most viable, and hence exploited, threat vectors relevant to keys and certificates is to attack the issuers of these machine identities—the CAs that are trusted by computing systems of all types and sizes. As malicious actors and nation states attempt to get access to sensitive data, e-mail communications are a popular target. E-mail providers such as Google and Yahoo are as such among the most targeted vendors, as evidenced by the attacks listed earlier in this section. In response to these attacks, most notably the DigiNotar CA compromise, Google proposed the Certificate Transparency (CT) initiative (https://www.certificate-transparency.org/) in 2011.

CT is essentially a framework for monitoring and auditing the issuance of certificates in near real time. Google has helped promote this by requiring that certificates have publicly accessible issuance records in order to be treated as the most trustworthy within the Chrome browser—currently indicated by a green lock icon in the browser’s address bar, which can be interpreted by Internet users as Google-provided confidence in the validity of the site that they intend to visit. Conversely, websites that operate with certificates that do not have CT records (in essence, those without a publicly auditable record of issuance) will be treated as potentially insecure. Google currently only requires that EV certificates be logged in CT log servers, but has signaled an intent to extend CT requirements to cover all types of certificates, including domain validation and organization validation certificates by early 2018. This will force all public CAs to log all their certificates to Google-approved CT log servers to prevent a degraded user experience, which will in turn impact their customers.

One of the effects of recording the issuance of certificates and having this be publicly auditable is that anyone can monitor the generation of these credentials. This is particularly revealing in the case of machine identities as the certificate provides information about both who it was issued to and who issued it, in effect exposing the list of CAs’ customers to potential competition in a market which is increasingly commoditized and hence fiercely competitive. This was understandably met with opposition by the CA community when first proposed to the CAB forum—which the vendor wants to publish their rolodex of customers?—but because of Google’s significant market share and increasing frequency of incidents of certificate misissuance, CT has started to gain traction, with Firefox and Opera being popular browsers that support the initiative and a number of CAs starting to participate in it as well.

While CT is still in “experimental” status with the Internet Engineering Task Force (IETF), it has garnered widespread support, partly because of the popularity of the Google Chrome browser. CT is both an open standard and an open-source framework, and this has helped other vendors, most notably Mozilla, both contribute to and benefit from this initiative. There is now an ecosystem of CT log operators and CT log monitors that help sustain the viability of this initiative and have helped surface instances of unauthorized issuance around the world, including the aforementioned incidents with CNNIC, INIC, and Symantec.

In addition to certificate transparency, there are other initiatives such as pubic key pinning, DNS-based authentication of named entities and CA authorization records that have been implemented with varying degrees of success, all with intent to improve the digital certificate system that serves as the backbone (of trust) for the Internet.

3.7.3  Let’s Encrypt

As part of their efforts to transition the Internet to run over secure, encrypted channels, the EFF, an international nonprofit digital rights group that is funded by industry heavyweights such as Cisco, Akamai and Mozilla, launched a free CA in 2016—Let’s Encrypt (the web) (Let’s Encrypt 2014). In a relatively short period, Let’s Encrypt has risen to become, by far, the most popular CA for Internet-facing systems—in early 2017, they hit the milestone of 1 million issued certificates a day, which is orders of magnitude more than the number issued by any other public CA. As a means of comparison, the next most popular CA issues 100,000 certificates a month.

In addition to the no-cost aspect to getting a certificate, what has heavily accelerated the adoption of this particular CA is a protocol that they introduced that essentially automates the certificate issuance (and, down the line, renewal) process—Automatic Certificate Management Environment (ACME spec 2017). ACME is currently an IETF draft and was designed to simplify the process by which certificates were issued, while attempting to validate the legitimacy of the requestor. As the need for ubiquitous encryption rises, the number of ACME implementations has exploded, as is evidenced by the wide variety of development frameworks that support this protocol. ACME/Let’s Encrypt issues only domain-validated certificates today, as certificates with a higher level of assurance require a level of verification that is currently not possible via automated means.

This access to a free, publicly trusted CA with limited vetting capabilities has made Let’s Encrypt attractive to exploits as well. Over 15,000 unauthorized certificates have been issued thus far to Paypal, a popular online payments platform, as part of phishing campaigns intended to trick Paypal customers into revealing their access credentials (Let’s Encrypt 2017).

Figure 3.4 captures the criticality of this problem very well.

Figure 3.4   Top network attacks. (From Lawrence, Eric, Certified Malice, Text/Plain, https://textslashplain.com/2017/01/16/certified-malice.)

To the average Internet user, there is no difference between the website on the left and the one on the right—both are treated as trusted by the browser, as they were issued by trusted CAs. Yet only one of these is a legitimate PayPal property, while the other has been issued to “paypal.com.summary-spport.com” that may look like a PayPal website, especially on a resource-constrained device such as a smartphone, but has nothing to do with the PayPal brand. What is more worrisome is the fact that the phishing campaign used perfectly legal techniques to register their domain and obtain a trusted certificate in an automated manner that allows the perpetrator to, in effect, repeat the attack (by registering a different domain) and incur very little cost. Even if this certificate were to be detected, there is very little PayPal or the CA can do to mitigate its use. Partly in response to these attack vectors, the US government enacted the Anti-cybersquatting Consumer Protection Act in 1999 to prevent using domain names that are confusingly similar to, or dilutive of a trademark belonging to, another entity. CT, as previously noted, can help surface these kinds of issues since the certificates that are used in these sort of attacks will be publicly logged, monitored, and audited.

3.7.4  IoT

The IoT is a rapidly growing market, poised to exceed 20 billion devices by 2020, per estimates from Gartner. IoT is the quintessential machine-to-machine interaction use case, and while that is not a new concept, what is unique is the dependence on the Internet to serve as the backbone for these communications—and the possibilities and challenges it affords. On one hand, access to the Internet has significantly accelerated innovation in markets such as home automation, autonomous vehicles, and “smart” utilities. On the other hand, the rate at which these devices are being rolled out has made it necessary to depend on the Internet to scale to administer and manage these devices. This is where unrestricted access to these devices by anyone on the Internet has significantly increased their risk of compromise while exposing another threat surface—hacking these devices and using them to attack other Internet-facing systems, essentially simplifying the capability to launch “distributed denial of service” attacks at very little cost to malicious actors.

The Mirai attacks of 2016 serve as a glaring example of the risks posed by Internet-enabled systems that have been improperly secured. Mirai is malware that infects consumer IoT devices such as IP cameras and home routers and utilizes them as part of a “botnet” to conduct large-scale network attacks. The source code for Mirai is freely accessible and has been adapted and used to disrupt a number of highly networked websites including those belonging to Twitter, Netflix, Airbnb, Reddit, and GitHub (Mirai Malware 2017). Mirai attacks IoT devices by attempting to gain administrative access to these devices, exploiting poor access credentials (typically weak usernames/passwords that are shared across multiple devices) to take control of the device and then redirecting its traffic to attack other Internet-facing applications. This is where the enhanced security afforded by keys and certificates can significantly reduce the probability of compromise:

• Using strong, cryptographically generated access credentials mitigates the possibility of brute force attacks that would allow an attacker to attempt access using common passwords (admin/password is a frequently used access credential) or to guess a password—the cost of cracking an RSA or ECC key renders the cost of such attacks unviable.
• Using unique, automatically generated machine identities mitigates the possibility of large-scale device compromise—each device would have to be attacked separately, which would make it cost prohibitive to get access to the number of devices necessary to construct a viable botnet.
• Requiring all software downloads to be cryptographically signed and verified prior to installation on these devices further reduces the possibility of malicious actors taking control of these devices—the malware would have to be signed by a valid code-signing certificate that is issued by a CA that is trusted by the device manufacturer or consumer before it would be allowed to run on these devices.

As such, IoT vendors need to look at machine identities to enhance their security postures and reduce the possibility of compromise and subsequent attacks. As this area of additional security afforded by cryptography is not very well understood, there is a need for IoT security vendors to offer strong machine identities as part of their platform offerings.

3.7.5  Distributed ledgers (Blockchain)

While still relatively new, the concept of Blockchain has received a lot attention in recent years, primarily because of the success of Bitcoin as a cryptocurrency, and the disruption it has caused to the peer-to-peer payment industry. This has taken out the need for an intermediary, typically a financial institution such as a bank, to enable the transfer of money between the participants in the transaction. Additionally, details of the transaction are then signed for integrity and logged into a readable “ledger” using nodes (“blocks”) that can be distributed, but cryptographically connected (and secured) in that one block builds on top of another, providing an auditable, tamper-resistant system that is decentralized as well. It is for this reason that Blockchain is sometimes referred to as a distributed ledger. In reality, Bitcoin, which is a very compelling alternative to current payment networks because of the security, transparency, and financial implications, is just the most well-known implementation of a distributed ledger network.

The use cases for distributed ledgers are still being developed—in addition to payment networks, land registries are another practical example where a distributed ledger brings significant advantages over currently used methods.