With the advent of e-commerce came an important question: how can users verify that an entity on the other end of a web connection is who it says it is? The answer wasn't immediately clear in the Internet's early days. But in subsequent years, a suitable method slowly entered into focus.
Public Key Infrastructure to the Rescue!
The solution came in the form of public key infrastructure (PKI), a set of requirements which detail the implementation of public key cryptography for authenticating parties involved in a web transaction. At the heart of public key infrastructure are two keys: a public key, which is widely available, and a private key, which is known only to its owner. The keys work together in that an entity can use a public key to verify that someone holding the private key indeed sent a message. On the flip side, the public key infrastructure also supports asymmetric encryption by restricting the decryption of a message encrypted with a public key to someone holding the corresponding private key.
Public and private keys meet in what are known as digital signatures. These coded messages abide by public key infrastructure which enables signers to use their private keys to create the digital signature. The mathematical algorithm underlying the private key creates a hash and encrypts the data, thereby producing a digital signature.
Electronic signature technology provider Docusign provides an example of how digital signatures can help authenticate an individual involved in a transaction:
"… Jane signs an agreement to sell a timeshare using her private key. The buyer receives the document. The buyer who receives the document also receives a copy of Jane’s public key. If the public key can’t decrypt the signature (via the cipher from which the keys were created), it means the signature isn’t Jane’s, or has been changed since it was signed. The signature is then considered invalid."
It's imperative that parties can ensure the integrity of a digital signature. As a result, public key infrastructure frequently requires the sender of a document and the recipient to agree on using reputable Certificate Authorities (CAs) for creating, conducting, and saving their asymmetric keys. A type of service provider, CAs are third-party organizations that help ensure key security. They're responsible for issuing security certificates, electronic documents which contain a digital signature's public key and the identity associated with that key. Security certificates therefore help confirm the owner of a public key and are essential to creating a digital signature.
Security certificates don't last forever; CAs issue them for a specified period of time and then require owners to renew them. Once issued, these certificates appear in security certificate management systems and tie into the central directory, a repository of stored and indexed keys maintained by the public key infrastructure. If a CA has any reason to revoke a security certificate before it reaches its expiration, that document likely ends up in a certificate revocation list (CRLs). Browsers can use this list to not trust revoked security certificates, thereby protecting web users against bad actors who might seek to abuse expired/revoked security certificates.
The Evolution of Security Certificates
Security certificates come in many different forms. Most commonly, an organization purchases a security certificate and installs it on a web server. Doing so authenticates the identity of the website for web browsers and visitors as well as encrypts data transmitted between the website and the visitor.
To establish these secure communication channels, domain owners often obtain Secure Sockets Layer (SSL) security certificates. Netscape Communications originally developed SSL in 1994, which means it's most likely the first cryptographic protocol developed for the Internet. Today, SSL helps secure emails sent using the Simple Mail Transfer Protocol (SMTP), phone calls placed via the Voice over Internet Protocol (VoIP), files exchanged over the File Transfer Protocol (FTP), and processes that make use of other protocols. Of course, it also works with the Hypertext Transfer Protocol (HTTP) to produce Hypertext Transfer Protocol Secure (HTTPS), which establishes encrypted communications on the web.
The most recent version of Secure Sockets Layer is SSL 3.0. In January 1999, Internet Engineering Task Force adopted an enhanced version of SSL 3.0 called Transport Layer Security (TLS). This successor protocol's latest version is TLS 1.2.
AES: Its Role and Key Sizes
Underlying the actual data transmission of SSL and TLS is the Advanced Encryption Standard (AES). A successor of the Data Encryption Standard (DES), AES is an encryption standard technique used by many cryptographic libraries. Organizations traditionally use AES for symmetric key cryptography, or use of the same key to encrypt and decrypt messages.
AES candidates support a fixed block length of 126 bits. But the standard supports three key lengths: 128 bits, 192 bits, and 256 bits. Most organizations require their employees use AES 256-bit encryption because of the 2256 possible key combinations that a brute force attacker would need to try in order to guess the key.
To put things into perspective, it would take one billion billion years to crack 128-bit key. This is already older than the age of the universe (13.82 billion years) and is therefore considered uncrackable. 256-bit encryption keys, by comparison, require 2128 times the computational power needed to break a 128-bit key. This size considerably raises the stakes of cracking a 256-bit encryption key. Using a hypothetical scenario provided by Wikipedia, say 50 super computers have the ability to try one billion billion key combinations each second. It would still take them 3×1051 years to exhaust the key space under 256-bit encryption.
Gain visibility into your encryption environment today.
Digital Certificates, Keys, and Machine Identities
Security certificates and 256-bit encryption keys managed by the public key infrastructure all constitute machine identities. These capabilities enable authentication and encryption for security protocols like SSL and TLS. But if not adequately protected, digital attackers could abuse them to target an organization's IT infrastructure. Indeed, attackers could abuse access to machine identities to steal trusted credentials and thereby bypass other security controls. Attackers could then steal private (including 256-bit encryption) keys, forge security certificates, compromise Certificate Authorities (CAs), leverage encrypted tunnels, and exploit machine identities to steal data and/or conduct digital espionage.
Machine identities are high-value targets for digital attackers and malicious insiders. Acknowledging this risk, organizations need to strengthen their machine identity management infrastructure. This effort begins with gaining global visibility into all certificates and keys used in internal and external infrastructures, the cloud, and other environments.
Related Posts
