A system is only as secure as its weakest part — the most expensive chain in the world wrapped around deeply sunk steel columns is worthless if tied together with zip ties. The same holds true for security in the API space. The most secure, authenticated, stable system is only as secure as its weakest point. By and large, this weakness lies in the data stream.

In this piece, we discuss the importance of securing your API data stream, the various technologies necessary to do so, and the benefits and drawbacks of various offerings in the point-to-point (P2P) encryption industry.

Why Encrypt Data?

Systems are tricky things — because a system is by definition a collection of objects working towards a singular goal or collection of goals, their efficiency and security are directly tied to one another. Think of a network or an API server cluster as a suit of armor — you might have the best plate steel, the most intricately laid bronze work, and the most reinforced shield, but without a sturdy and protective helmet, you might as well be walking into battle nude.

This is a basic concept in network security, but it bears repeating (and remembering) – your system is only as strong as its weakest component.

Enter encryption. Encryption can take an old decrepit server running out of data software and encrypt the outgoing data stream into a nigh-unbreakable juggernaut. Compare encrypted traffic breaking to non-encrypted traffic breaking.

Let’s say Bob sends a remote URI call to a server unencrypted. This call carries his key to the server, which then relays the information requested. With a single node in the middle listening to and capturing traffic (launching a Man-in-the-Middle Attack, this information can then be used in a session replay attack, compromising the integrity and confidentiality of your system.

Let’s say that Bob did the same remote URI call, but instead utilized a 2048-bit SSL certificate encryption system from DigiCert. Even if that node in the middle was able to completely capture the traffic, DigiCert estimates that it would take 6.4 quadrillion years to crack the data using a 2.2Ghz based system with 2GB of RAM — that’s longer than the total time the universe has existed.

This amount of security is clearly valuable, and it’s easy and cheap to implement — infrastructure/network solutions such as HTTPS, SSL, and TLS utilize ports and network technologies to secure the data stream as it leaves and enters the network, and these solutions are typically already built into most modern servers and workstations.

Third party solutions are also generally low in cost, with some solutions falling into the “open software” methodology of releasing programs for free to garner community support and iteration.

Keep in mind that encryption solutions are far different from methodologies that derive from encryption. For instance, API Keys are one way to secure your datastream, but in and of themselves, they do not encrypt traffic — this is in fact one of the greatest weaknesses of keys. Do not assume any solution that is not expressly encryption oriented will encrypt traffic.

Defining Terms

Before we dive too deeply into encryption solutions, we need to understand a few terms unique to encryption. These terms can have different meanings used in different industries, so it is very important to remember that these definitions may only apply to this very specific use-case.

In this piece, we are specifically discussing P2P encryption. While this often has connotations in the API space of payment processing, in the larger cryptanalysis field, P2P has a looser definition. P2P simply means the point-to-point cycle consisting of a provider of data, the data stream carrying the data, and a consumer of data.

When discussing encryption, the concept of the “data stream” is also very important to understand. A data stream is the flow of data from a generating point to a receiving point — that is, from the API itself to the client requesting the data. Think of it like the postal service — the process from when a letter is put into a mailbox to when it arrives in the mailbox it was addressed to is akin to a data stream.

Most important, encryption is a method by which data is codified or obfuscated, preventing unauthorized access, viewing, or modification. This can be done in a variety of ways, but all of these possibilities to date fall into two distinct categories — Block Encryption and Stream Encryption.

Block Encryption is exactly what it sounds like — the data stream is put through an encryption method in blocks or chunks of data, usually in a set size dictated by the encryption method. For example, in the AES (aka Rijndael) method of block encryption, these blocks are limited to 128 bits of information, meaning that only 128 bits of data can be encrypted at a time.

Stream Encryption, on the other hand, encrypts the data stream in real time — data is not encrypted in blocks, but rather as a series of binary signals. This method is resource intensive, and is often easily cracked due to the fact that encryption methods can be detected by simply listening to the stream and finding patterns in the ciphertext output. For this reason, Stream Encryption is not used much.

Variants of Key Encryption

There are similarly two types of encryption commonly employed in the network space.

The first, Public-key, uses algorithms like the RSA Asymmetric Block Cipher or ElGamal to encode communications. This method uses a key pair, from which both keys are derived, with one key functioning to encrypt the data, and the other to decrypt. The decrypting key is kept secret, and is typically tied to the recipient, whereas the encryption key is public, allowing anyone to encrypt data for that particular recipient.

This is the most secure version of encryption due to the fact that the codes are separate, but defined against one another. The private key is generated from a public key, and that public key is in itself a secure key. By setting up the system this way, an unauthorized user or node could intercept the full decrypted public key and still have no access to the user system; likewise, they could intercept the full decrypted private key, and again have no access to the server.

Another form of encryption is the Symmetric-key methodology, which utilizes the same two keys to both encrypt and decrypt. This method is secure for local use (such as encrypting password databases on a root server), but should not be used over a network in its plain form without encrypting the session key or data stream using a secondary assymetric encrypted protocol.

The Symmetric-key method is considered to be a less-secure solution than the Public-key method due to the fact that both the encryption and decryption key are the same key — because of this, a theoretical unauthorized user could obtain either the server key or the client key, and access any resource he or she wanted to. Public keys should not be inherently trusted either — a user must know who owns the private part of the key to ensure security. Nonetheless, Asymmetric-key encryption is typically a stronger solution despite this.

Built-in Encryption Solutions

The most common and easily implemented solution is HTTPS. HTTPS, standing for Hyper Text Transfer Protocol Secure, is a protocol by which HTTP, the language of the internet, is encrypted using a variety of algorithms, including RSA, ECDH (Elliptic curve Diffie–Hellman), and Kerberos.

This encrypted data is then sent over a secure protocol to the end user for decryption. This transportation happens over two main protocols — SSL and TLS.

SSL, or Secure Sockets Layer, utilizes a Public-key or Asymmetric algorithm to transmit Symmetric encrypted data — this two-part process provides incredible security and agility in encryption. This protocol uses an SSL Certificate that is issued in response to a Certificate Signing Request (CST), which is then validated. SSL is a complex system, but this complexity is largely hidden from consumers. This hidden complexity makes the user-experience that much better, improving the impression of your service.

Likewise, HTTPS can also utilize the TLS protocol. TLS, or Transport Layer Security, is the updated version of SSL, and is considered the modern protocol to use over SSL whenever possible. TLS functions nearly identical to SSL, with very few exceptions — notably the key derivation system and key exchange process.

It doesn’t matter which method you choose (though many administrators would suggest you utilize the version just before the most up-to-date protocol version to ensure functionality) — just remain consistent! Consistency is a key part of success in API development, so whatever you choose, stick with it.

External Encryption Solutions

While HTTPS is a very flexible system, there are certain use-cases that may require third party point-to-point encryption methods designed for very specific purposes. Luckily, the API space is populated with encryption providers utilizing a variety of technologies and systems to ensure a secure ecosystem.

Take for example the CyberSource payment encryption service. This service utilizes card-reader software tied into hardware security modules to send data remotely over secure channels, increasing security and data loss prevention success rates.

For a more general solution, a system like OAuth 1.0a pairs authorization with data encryption. Utilizing a signature, typically HMAC-SHA1, OAuth 1.0a sends this data over plain communication lines (though TLS/SSL can be used). Because OAuth 1.0a does not send the password in transit directly, this all but removes the threat of sniffed traffic and captured sessions.

Use-Case Scenarios

Given that encryption of point-to-point data transmission is so vitally import for APIs transferring secure data, such as passwords, health records, payment processing, etc., view encryption as an absolute requirement in any situation where there is a fiscal value assigned to data. If your data could be sold, it should be protected. If there’s money involved, you can be sure there are people somewhere who want to take that stream and use it for their own purposes.

In some other cases, encryption might be required. Federal contracts, government-to-civilian client implementation, and healthcare APIs may be required to encrypt traffic as part of contractual negotiations or laws such as HIPAA (the Health Insurance Portability and Accountability Act of 1996).

That’s not to say, however, that encryption is only useful for secure situations. As users increasingly value their privacy, implementing encryption standards can be as much a security feature as a selling point to potential customers.

Example Code Executions

By and large, these methods are incredibly simple for the user and the API provider to implement. For instance, in curl, you can simply use the following path command:

curl –3 -capath –ssl https://api.website.com

And with that small piece of code, you’re now utilizing a local certificate to sign and encrypt your data connection.

For consumers, using your web app or API in a secure mode is as simple as connecting over HTTPS. For example, when connecting to the Facebook web application, a variety of APIs are used to connect user accounts to data. Simply logging in under https://www.facebook.com rather than the conventional https://www.facebook.com will trigger a secure HTTPS connection utilizing the encryption chosen by the provider.

Conclusion

Security is an important thing to consider — it should be one of the first things you consider in the API lifecycle. Regardless of whether your API is public or private, first or third party, a well-deployed security solution will make your API more useful, secure, and attractive.