Machine identities

Foundational to cybersecurity

Authored by: Hari Nair

Human-Computer Interaction and Cybersecurity Handbook

Print publication date:  October  2018
Online publication date:  October  2018

Print ISBN: 9781138739161
eBook ISBN: 9781315184319
Adobe ISBN:




The Oxford Dictionary defines trust as the “firm belief in the reliability, truth, ability, or strength of someone or something.” A wonderful article on offers multiple interpretations for trust. When considering trust in the digital world, one in particular is especially relevant:

Trust means making an exchange with someone when you do not have full knowledge about them, their intent and the things they are offering to you. (Trust—changingminds 2017)

 Add to shortlist  Cite

Machine identities

3.1  Trust in the digital world

The Oxford Dictionary defines trust as the “firm belief in the reliability, truth, ability, or strength of someone or something.” A wonderful article on offers multiple interpretations for trust. When considering trust in the digital world, one in particular is especially relevant:

Trust means making an exchange with someone when you do not have full knowledge about them, their intent and the things they are offering to you. (Trust—changingminds 2017)

In the physical world, trust is established based on identity or context, built on familiarity (the frequency of our interactions), and ultimately dependent on experience. Just as importantly, trust is nuanced: We do not trust everyone equally. For example, we generally find that people trust friends and family more than neighbors or casual acquaintances. There are exceptions, of course, but in general, the notion of trust in an entity is built over time and dependent on the frequency and the nature of our interactions with that entity.

Yet frequently, we must trust people that we do not see often, such as doctors, mechanics, and tax accountants. What gives us the confidence to depend on these people? Specifically, how do we know that a doctor is a doctor? The fact that we can “see” that the doctor is accredited or affiliated with a well-known hospital certainly helps, as do physical attributes such as the doctor’s office, location, and the notion of reviews by other people.

Now let us contrast how we build trust in the physical world with how we establish trust in the digital world, where we cannot see anything. For example, I connect to my bank, my e-mail provider, and a variety of e-commerce sites—each of which requires me to provide personally identifiable information (PII) and, in some cases, credit card data. I can identify the websites I frequently visit based on the logo, colors, and layout, but attacks such as phishing have long since rendered my ability to recognize the “look and feel” of an (online) entity practically useless. Without a tangible identity, there is no way I can build familiarity and, hence, trust.

How then do I know I am connecting to the online service provider that I want to use? This is where digital keys and certificates have such an important role to play. A certificate, much like a credit card or a passport, is issued by a “trusted” authority (an enterprise or a financial or government institution in the real world) and has an associated validity and purpose.

The similarities end there, however. Although we can “view” certificates, the attributes that make them unique (and, hence, linked irrevocably to a physical entity) can only be “verified” by applications such as a web browser or an e-mail client. Theoretically, it should then be possible for an application to identify and, over time, trust an entity, should it not?

Not so fast. There are a couple of reasons that this is not practical yet:

  • Unlike a physical attribute (such as a face, voice, or fingerprint), a digital attribute is inherently transient in nature. The digital “key” that serves as the unique attribute to identify an online entity is valid for a specified period of time and must then be replaced. Periodically replacing a digital key mitigates the risk of the key being duplicated. The more a key is used, the greater the chance it will be compromised. As such, best practices recommend the periodic regeneration of keys. The familiarity with a specific key (sometimes referred to as “certificate pinning”) is not particularly useful—especially when the keys themselves get replaced as often as every 90 days.
  • Unlike the physical world, on the Internet, the concept of trust is not as tangible. We cannot establish identity based on sight, and digital keys—the mechanism designed to verify identity and establish trust—are frequently updated, rendering familiarity impractical. Trust must be established every time and cannot be based on frequent interactions.

3.2  Human and machine identities

As the lines between the physical and the digital world blur, the role of identity in establishing trust that translates across both worlds becomes critical. As we look at the interactions in our daily lives, we can see the increasing dependence on smart “things” to enable us in our functions and responsibilities—phones, cars, homes, utilities, health, finance, and education. As the famed futurist Larry Kurzweil notes, in the next 10–15 years, the following will take place:

  • Self-driving cars will start to take over the roads.
  • “Nanobots” will become smarter than current medical technology.
  • The Turing test will start to become passable, rendering humans incapable of distinguishing between human and machine.

One thing that will not change, however, is the necessity to identify (and eventually, trust) who we interact with, regardless if they are humans or machines. The notion of human identity, even in the digital world, is relatively well understood—whether it is for e-mail, social networking, or logging into travel portals, we normally identify ourselves using a “username” (typically an e-mail address) and a “password.” We normally set our own passwords and end up using some form of mnemonic device that is easy enough for us to remember, instead of having to write it down. However, since these passwords are generated by humans, they are inherently easy to “crack” as well—today, there are automated password-cracking tools that can run more than a million variations of a password in about 24 hours. As such, we are very sensitive to password security:

  • We have encouraged users to move from passwords to longer “passphrases.”
  • Regulations such as the Sarbanes–Oxley act have required organizations of all types to force users to not just use long and strong passwords but also change them frequently.
  • There is a plethora of “password manager” tools that users can use to store, change, and use passwords.

Organizations such as National Institute of Standards and Technology have mapped out the different types of identities through documents such as SP 800-63 and the risk/assurance they provide in establishing trust online (SP800-63 2017). Passwords/passphrases are generally regarded as having the lowest level of “assurance.” On the other end of the scale are cryptographic keys, generally not only associated with high value systems—think of these as “machine identities”—but also used by security-focused organizations such as the government and the military to protect humans through the use of devices such as smart cards.

Unlike humans, machines have the capability to generate long and complex passwords to identify themselves, both to humans and to other machines. Machines, however, do not (yet) have the cognitive capability to remember passwords without having to store them—power down a machine, and it loses its ability to recollect the password/passphrase it is required to use for its interactions. It is for these reasons that cryptographic keys have been widely adopted and accepted as the best practice to identify machines. Cryptographic keys are generally much longer and stronger than passwords, rendering them comparatively immune to cracking attempts.

While we as an industry have spent billions of dollars trying to protect passwords, there has been very little thought and effort put into the security of machine identities. This gap becomes all the more glaring when we consider the rate at which encryption has become ubiquitous, while the pace of innovation reaches dizzying heights. In 2017, the volume of encrypted Internet traffic surpassed traffic that is unencrypted, hitting a seminal milestone that signals the increase in the usage of keys and certificates (Encrypted Web 2017). This will only continue to grow as browsers such as Google Chrome have started to penalize web sites that are not encrypted by default. In addition, as organizations start to embrace the cloud and development and operations (DevOps) practices, infrastructures will become a lot more ephemeral, necessitating more identities to be generated and trusted for short periods. Indeed, banks such as Monzo ( have shown the way to become viable financial institutions while maintaining literally no physical presence.

On a related, but different note, every connected device in the Internet of things (IoT) space will need keys to identify itself. Autonomous vehicles, such as self-driving cars, will have millions of certificates. We expect that 34 billion IoT devices will be connected by 2020, and considering that these devices will all need identities in order to be able to communicate and trust each other, the implications of the protection of machine identities assume truly staggering proportions (IOT stats 2015).

3.3  Keys and certificates: Foundations of cybersecurity

All organizations rely on cryptographic keys and digital certificates to secure their business. These software devices were designed to solve the original Internet security problem—accurately identifying servers and browsers so that they could safely communicate back and forth independently. Machines rely exclusively on keys and certificates to know what to trust and what not to trust in our digital world. Any time data are being transferred, whether it be your business or personal information, there is a key or certificate that is being used to protect it. If the communication channel is not trusted, your data are not secure.

Secure sockets layer (SSL) was first introduced in the 1990s by Netscape to protect digital communication just as the Internet, and e-commerce, was taking off and was implemented in their Navigator browser. It served as the de facto standard for encryption for a number of years and has been updated over the years (the last, SSLv3 was only deprecated in 2015) to address vulnerabilities and account for stronger security standards. It is for this reason that cryptographic protocols are often referred to as “SSL.”

At a high level—there are two primary benefits that keys and certificates afford in the context of digital interactions:

  1. They identify (and potentially authenticate) the participants in a transaction (depending on the nature of the transaction, the participants may be referred to as clients, servers, or peers).
  2. They protect the data that get transferred between the participants.

There are a number of common applications of keys and certificates that readers may be familiar with.

  • Identity—This enables users to authenticate themselves to access sensitive content. This is typically limited to government and military personnel, typically using smart cards initiatives such as the common access card or the personal identity verification program. The higher security associated with these credentials has also made it attractive for e-government applications. Countries such as Canada (using concepts such as meaningless but unique numbers or MBUN), Estonia, and New Zealand, among others, have rolled out government-to-citizen programs built on the bedrock of security that cryptographic keys and certificates provide (MBUN 2017). Elsewhere, countries around the world have implemented “national identification” initiatives to enable access to electronic voting, utility, transportation, and medical programs.
  • Document signing—European entities, both government and business, have adopted standards such as XML DSig, XAdES, PAdES, and CAdES to standardize the document signing process and allow for interoperability within and between organizations. Tax returns are a common application of document signing, and countries around the world have standardized on keys and certificates as a means to not only digitize the process, but also secure it from the perspective of both nonrepudiation (guaranteeing the source and integrity of the content) and auditability. While these practices are being adopted in the United States as well, we have a fair way to go before we catch up with our European counterparts.
  • Code signing—The notion of signing an application code to prove its integrity and trustworthiness has assumed particular significance in the last 20 years because of the explosive growth of malicious software (commonly referred to as “malware”). To date, there have been more than 120 million instances of known malicious software, a number that will continue to grow exponentially as a direct result of the adoption of mobile applications, devices, and IoT. Partly in response to this threat, operating system vendors, including Microsoft, Apple, and Google flag unsigned code, requiring users to consciously acknowledge and accept the risks of running unsigned code. Sadly, though, the practice of requiring and then validating signed code is not as prevalent. The WannaCry malware exploit in 2017 had a particularly catastrophic impact on more than 100 countries around the world and could have been thwarted if strong code validation processes were in place. Controls are much stricter for mobile operating systems, where the plethora of mobile application developers (as of March 2017, there were more than five million applications on Apple iOS and Google Android) has increased the risk of infecting devices that are increasingly used for personal and business transactions (App statistics 2017). Apple, for example, insists on self-signing all code that can run on its mobile devices.
  • Encryption—In addition to guaranteeing the “integrity” of the date, cryptographic keys and certificates can also be used to protect data from being accessed by malicious entities. This is true for data at rest (data being stored on user, server, and cloud systems) and data in motion (data being transferred from one location to another). While the technology that is used to protect the data in each case is slightly different, cryptographic keys are used in both cases to minimize the risk of data being compromised. For data at rest, encrypted storage/backups are particularly important today, when sensitive data can be accessed on devices that are inherently insecure—most organizations have a “bring your own device” initiative to allow users to access data on their personal devices, including mobile phone and tablets. Unfettered access to their devices or, worse yet, loss of these devices puts user’s personal and professional data at risk, and encryption provides a necessary safeguard in the worst-case scenario of a device getting in the hands of a malicious entity. For data in motion, the process is relatively simpler—most common data transfer applications (browsers, file, and e-mail transfer clients) have encryption controls built into them, and the standards that govern the implementation of these controls are fairly mature and robust. Another common application of encryption is to protect e-mail communications. While the advent of text messaging and social networks has given users other options, e-mails remain the most commonly used means for communication for business and personal use. There are many sensitive data that are typically accessible in users’ e-mail communications, which makes e-mail providers a prime target for malicious actors. While the data themselves are stored and transmitted securely between e-mail senders and recipients, it is possible to intercept this traffic while it is in transit, and this is where encryption comes in handy to provide an additional layer of security. Essentially, e-mail traffic is protected such that even if the communication channel (sometimes referred to as a tunnel) is compromised, only the recipient(s) have the capability to read the actual contents of the e-mail. While e-mail encryption is essentially a user-specific task and as such is challenging to roll out to individuals (training users to implement e-mail encryption is an onerous process, especially for nontechnical users), organizations have frequently deployed encryption at the enterprise gateway in an attempt to minimize the risk of compromise when data are in transit between the sender and the recipient.
  • Network/Wi-Fi access—Accessing the Internet, whether over wired or wireless networks, within and outside the enterprise, is another critical application of digital keys and certificates, independent of whether the access happens at work, at home, or in public spots. While the process is essentially transparent to the user, in the background, both the client device (desktops, laptops, tablets, and phones) and the network essentially need to authenticate each other before they attempt to provide or use access. Kerberos, remote authentication dial-in user service, Network Access Control, and 802.11 are all standards related to secure network access that are built on a foundation of keys and certificates.

In summary, keys and certificates are in play any time you are moving data via SSL/transport layer security (TLS); secure shell (SSH); and mobile, cloud, and IoT connections. While these are common applications of keys and certificates, in truth, any application that is used today, whether it is for personal, professional, or public access, needs to be secured, and cryptography is the foundation of cybersecurity. At the very minimum, every interface of applications, whether it be for administrative interfaces [for example, information technology (IT) administrators configuring their web application firewalls] or user interfaces (citizens checking their private e-mail), needs to be protected using digital keys and certificates. By extension, a compromise of the underlying cryptolayer can end up compromising the entire security fabric of the organization’s application.

3.4  Encryption fundamentals

Now that we have identified some of the reasons why keys and certificates are foundational to security for digital transactions, let us consider some of the concepts that will be useful to become familiar with. Public key cryptography (sometimes referred to as asymmetric cryptography) uses pairs of keys, which are derived from two random long prime numbers. The private key is, as the name indicates, meant to keep secret and is only known to the owner of the key. The public key, on the other hand, is meant to be shared with relying entities in digital transactions. Typically, the public key is shared in a standard format—a digital certificate—that provides data about the key owner and the intended usage for the key pair (which includes the private key). The private and public keys are cryptographically related by the fact that operations performed by one of the keys can be verified by, and only by, the other key. Which key is used depends on the function being performed.

For public key encryption, the sender of the information encrypts data to be transmitted with the public key of the recipient (that is accessible using the recipient’s digital certificate). Once encrypted, only someone with access to the private key (which should be the recipient—hence the reason to keep it private) can decrypt data that were sent. This ensures the confidentiality of data for the intended recipient—all the sender needs is the recipient’s certificate, which is shareable.

For public key signatures, the sender of the information attaches a hash of the data that are being sent, encrypts this hash with their private key, and appends it to the data. To verify the integrity of the data (that is, to ensure that what was sent by the sender has not been modified in transit by a malicious actor or corrupted by other means), the recipient decrypts the hash using the public key from the sender’s certificate and compares it a hash of raw data that the recipient generates on their own. If the two hashes are identical, it proves that only someone with access to the private key (which should be the sender) could have sent the message. This ensures both the origin of the data and its integrity.

Figures 3.1 and 3.2 serve to illustrate the two processes:

Public key encryption. (Courtesy of US Naval Academy, Annapolis, MD,

Figure 3.1   Public key encryption. (Courtesy of US Naval Academy, Annapolis, MD,

Figure 3.2   Public key signatures and encryption. (Courtesy of US Naval Academy, Annapolis, MD,

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  Encryption key and certificate risks

There are a number of risks associated with encryption keys and certificates:

  • Downtime and system outages—Certificates that are not renewed and replaced before they expire can cause serious downtime and outages.
  • Key compromise—Direct access to keys by administrators, weak access controls, administrative turnover, and inability to regularly replace keys.
  • Compliance violations—Auditors are increasingly scrutinizing encryption key management practices to ensure that there are policies that govern their issuance, storage, and distribution.
  • Data loss—Losing access to all copies of a key such that data that were encrypted by it cannot be decrypted.
  • High administrative costs—Certificates and private keys require four hours per year to manage on average. SSH keys must be continuously tracked and managed on all systems. Additionally, because of the lack of identifying information about SSH keys, keys that have not been used in some predetermined period must be removed. Conversely, a baseline must be maintained of all keys and certificates so that anomalies can be identified.
  • CA compromise—Certificate authorities are attractive targets for hackers. The compromise of a CA enables attackers to conduct much broader attacks, a number of instances of which have been described in Section 3.6.

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 ( 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 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 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 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 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  Attacks on trust

As we have established in previous chapters, cryptographic credentials are foundational to cybersecurity. It is no surprise, therefore, that they are high-value targets for malicious actors. In a recent survey conducted by the Ponemon Institute, 100% of respondents from Global 2000 companies reported that they have had at least one attack on keys and certificates in the last 2 years.

Digital keys and certificates are being stolen—and increasingly often. Individuals and state-sponsored organizations are targeting them with the specific goal of misrepresenting themselves to steal sensitive information. Given the fact that keys and certificates are the most widely used means for establishing online identity, they are constantly under attack. This is borne out by the analysis of stolen data that is available on the dark web. While a stolen social security number goes for as little as $3, a stolen code-signing certificate goes for much as $1500—orders of magnitude more than what is considered PII.

As recent research from McAfee Labs (Q1, 2017) shows, SSL/TLS vulnerabilities account for as much as 33% of network attacks today, and this number is only growing as encryption is being rolled out across almost all web-facing infrastructure (McAfee Threat Report 2017).

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 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 (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, 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 (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 (], 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  What does the future look like?

While keys and certificates are here to stay as evidenced by the use cases that they address, and the lack of viable alternatives, there are a number of initiatives, at varying degrees of maturity, that are poised to impact the growth of machine identities, and the resulting dependency on them, even further.

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 ( 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,

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 “” 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.

3.8  In summary

Hopefully, this chapter has established that cryptographic keys and certificates are the bedrock on which trust is established in the digital world and serve to enable many mission-critical use cases, including access to the Internet through wired/wireless networks, encryption of data (both at-rest and in-motion), messaging/communication platforms, and pretty much every application that needs to be secured for privileged access.

Keys and certificates are poised for explosive growth fueled in part by trends in virtualization, cloud, DevOps, and IoT. Yet they are also among the least understood concepts of cybersecurity, as evidenced by the low investment in good cryptography management practices. This is especially stark when compared to the billions of dollars we spend as an industry to protect older, less secure technology such as usernames and passwords.

It is because of this lack of awareness that malicious actors, whether it be private groups of individuals or nation states, target vulnerabilities in the implementation of cryptographic security—SSL/TLS attacks dwarf all other forms of network attacks today, and this difference will only continue to grow. The technology itself is mature and, when implemented correctly does what it is supposed to do, it secures sensitive data, protects its integrity, and authenticates the participants in any digital interaction. This robustness of the technology is now being utilized for malicious purposes, leading to an ongoing debate between the benefits afforded by security/confidentiality on one hand and the threats they pose to citizens from all walks of life on the other.


ACME spec, 2017: Automatic Certificate Management Environment (ACME) draft-ietf-acme-acme-06, by R. Barnes , J. Hoffman-Andrews , and J. Kasten —Mar 13, 2017. Accessed on Jun 3, 2017.
ANSSI mis-issuance, 2013a: French Intermediate Certificate Authority Issues Rogue Certs for Google Domains, by Lucian Constantin —Dec 9, 2013. Accessed on May 28, 2017.
ANSSI mis-issuance, 2013b: Further Improving Digital Certificate Security, by Adam Langley —Dec 7, 2013. Accessed on May 28, 2017.
App statistics, 2017: Number of Apps Available in Leading App Stores as of Mar 2017, May 23, 2017.
CNNIC, 2015a: Google to Drop China’s CNNIC Root Certificate Authority after Trust Breach, by Owen Williams —Apr 1, 2015. Accessed on May 28, 2017.
CNNIC, 2015b: Google Chrome Will Banish Chinese Certificate Authority for Breach of Trust, by Dan Goodin —Apr 1, 2015. Accessed on May 28, 2017.
Code-signing requirements, 2016: Minimum Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates—Version 1.1, Sep 22, 2016. Accessed on May 25, 2017.
DigiCert-BusterPaperm 2013: Malware Strikes with Valid Digital Certificate, by Thor Olavsrud —Feb 4, 2013. Accessed on May 28, 2017.
DigiNotar, 2011a: Comodo Hacker: I Hacked DigiNotar Too; Other CAs Breached, by Peter Bright —Sep 6, 2011. Accessed on May 25, 2017.
DigiNotar, 2011b: DigiNotar Certificate Authority Breach Crashes e-Government in the Netherlands, by Robert Charette —Sep 9, 2011. Accessed on May 25, 2017.
DigiNotar, 2011c: Hacking Scandal Roils Dutch Public, by John W. Miller and Maarten Van Tartwijk —Sep 7, 2011. Accessed on May 25, 2017.
DigiNotar, 2012: Black Tulip—Report of the Investigation into the DigiNotar Certificate Authority Breach. Published by Fox IT—August 13, 2012. Accessed on May 25, 2017.
Encrypted Web, 2017: EFF: Half of Web Traffic Is Now Encrypted, by Sarah Perez —Feb 22, 2017. Accessed on Jun 3, 2017.
Flame Collision, 2012a: Flame Malware Collision Attack Explained, by Microsoft SWI—Jun 6, 2012. Accessed on May 28, 2017.
Flame Collision, 2012b: Flame Attackers Used Collision Attack to Forge Microsoft Certificate, by Dennis Fisher —Jun 5, 2012. Accessed on May 28, 2017.
Flame Collision, 2012c: sKyWIper (a.k.a. Flame a.k.a. Flamer): A Complex Malware for Targeted Attacks, by Laboratory of Cryptography and System Security (CrySyS Lab)—May 31, 2012. Accessed on May 28, 2017.
Flame Collision, 2013d: Flame Windows Update Attack Could Have Been Repeated in 3 Days, Says Microsoft, by Kim Zetter —Mar 1, 2013. Accessed on May 28, 2017.
INIC Compromise, 2014: Microsoft Revokes Trust in Certificate Authority Operated by the Indian Government, by Lucian Constantin —Jul 11, 2014. Accessed on May 28, 2017.
IOT stats, 2015: Gartner Says 6.4 Billion Connected Things Will Be in Use in 2016, Up 30 Percent from 2015, by Gartner —Nov 10, 2015. Accessed on Jun 3, 2017.
Let’s Encrypt, 2014: Launching in 2015: A Certificate Authority to Encrypt the Entire Web, by Peter Eckersley —Nov 18, 2014. Accessed on Jun 3, 2017.
Let’s Encrypt, 2017: 14,766 Let’s Encrypt SSL Certificates Issued to PayPal Phishing Sites, by Catalin Cimpanu —Mar 24, 2017. Accessed on Jun 3, 2017.
McAfee Threat Report, 2016: McAfee Labs Threats Report, March 2016. Accessed on May 25, 2017.
McAfee Threat Report, 2017: McAfee Labs Threat Report, April 2017. Accessed on May 25, 2017.
MBUN, 2017: An Overview of Public Key Certificate Support for Canada’s Government On-Line (GOL) Initiative, by Mike Just . Accessed on May 23, 2017.
MD5 Hash Clash, 2008: MD5 Considered Harmful Today—Creating a Rogue CA Certificate, by Alexander Sotirov , Marc Stevens , Jacob Appelbaum , Arjen Lenstra , David Molnar, Dag Arne Osvik , and Benne de Weger —Dec 30, 2008. Accessed on May 28, 2017.
Microsoft unauthorized issuance, 2012: Unauthorized Digital Certificates Could Allow Spoofing, by Microsoft—Jun 3, 2012. Updated: Jun 13, 2012. Accessed on May 28, 2017.
Mirai Malware, 2017: Mirai (Malware). Published by Wikipedia. Accessed on Jun 3, 2017.
Mozilla mis-issuance, 2008: CA Issues No-Questions Asked Mozilla Cert, by John Leyden —Dec 29, 2008. Accessed on May 25, 2017.
PKI Failures, 2017: Timeline of PKI Security Failures. Accessed on May 25, 2017.
Snowden, 2013: Edward Snowden: How to Make Sure the NSA Can’t Read Your Email, by Dylan Love —Jun 17, 2013. Accessed on Jun 3, 2017.
Snowden, 2017a: Edward Snowden. Published by Wikipedia. Accessed on Jun 3, 2017.
Snowden, 2017b: Spy Chief Complains That Edward Snowden Sped Up Spread of Encryption by 7 Years, by Jenna McLaughlin —Apr 25 2016. Accessed on Jun 3, 2017.
SP800-63, 2017: SP 800-63: Digital Identity Guidelines. Accessed on May 23, 2017.
StartSSL compromise, 2017: CA STARTSSL Compromised, but Says Certificates Not Affected, by Dennis Fisher —Jun 21, 2011. Accessed on May 25, 2017.
StuxNet, 2011: How Digital Detectives Deciphered Stuxnet, the Most Menacing Malware in History, by Kim Zetter —Jul 11, 2011. Accessed on May 25, 2017.
StuxNet, 2013: The Real Story of Stuxnet—How Kaspersky Lab Tracked Down the Malware That Stymied Iran’s Nuclear-Fuel Enrichment Program, by David Kushner —Feb 26, 2013. Accessed on May 25, 2017.
Symantec mis-issuance, 2016: Update on Test Certificate Incident, by Symantec—May 25, 2016. Accessed on May 28, 2017.
Symantec mis-issuance, 2015: Symantec Fires Staff Caught Up in Rogue Google SSL Cert Snafu, by John Leyden —Sep 21, 2015. Accessed on May 28, 2017.
Trust—changingminds, 2017: What Is Trust. Published by Accessed on May 23, 2017.
TurkTrust Fiasco, 2013: The TURKTRUST SSL Certificate Fiasco—What Really Happened, and What Happens Next? by Paul Ducklin —Jan 8, 2013. Accessed on May 25, 2017.
VeriSign mis-issuance, 2001: Erroneous VeriSign-Issued Digital Certificates Pose Spoofing Hazard, by Microsoft—Mar 22, 2001, Updated: Jun 23, 2003. Accessed on May 25, 2017.
Search for more...
Back to top

Use of cookies on this website

We are using cookies to provide statistics that help us give you the best experience of our site. You can find out more in our Privacy Policy. By continuing to use the site you are agreeing to our use of cookies.