Crypto Motion - Securing Data in Transit

Unlike data at rest, which primarily uses symmetric encryption, data in motion is most commonly security that uses asymmetric cryptography. Asymmetric crypto uses two different keys for encryption and decryption; a public key to encrypt a message and a private key for decryption. The private key is a completely random number, whereas the public key derives from the private key using a mathematically challenging problem. The math needs to be an operation that is "easy" to perform but "hard" to reverse (or crack). The three main types of math problems used are:

• Integer-based
• Elliptic curves
• Lattice reduction

I won't get into the math problems used; however, it is helpful to know that the most popular implementations of the three math problems above are RSA crypto (integer-based), ECC (Elliptic-curve-based), and NTRU (lattice reduction). Both RSA and ECC have proven to be susceptible to a quantum computer brute-force attack. This means that given enough time and compute power; those two cryptosystems can be cracked. Quantum computers make this almost trivial using an attack called Schor's algorithm. There is no polynomial-time algorithm to solve the lattice reduction problem on which NTRU is based (i.e., it is resistant to quantum computer brute-force attack).

In this blog, I focus on secure, authentic, and confidential channels. I also touch upon tampering and some of the attacks against protected communications. I also introduce the concept of secure tunnels and VPNs and transport layer security (TLS).

Protected Communications

Cryptography was initially used to protect communications and is still one of its primary uses. There are three types of protected communications channels:

• Authentic channel is resistant to tampering but not necessarily resistant to disclosure.
• Confidential channel is resistant to disclosure but not necessarily resistant to tampering. 
• Secure channel is resistant to both disclosure and tampering.

Remember, cryptography can create a false sense of security if not implemented correctly – and it's tough to get right. Let's explore these three channels and discuss tradeoffs between them. The total cost of any crypto solution should be weighed against the value of the information being handled.

Authentic Channels

The integrity of the message is the first concern here, that is, proving the message was not modified. A digital signature or Message Authentication Code (MAC) provides that proof.

The authenticity of the sender must also be assured or verifying that the sender is legitimate. A trusted 3rd-party usually validates this in the image below GlobalSign. GlobalSign (known as a certificate authority or CA) gives the sender a public key certificate to sign messages, so the receiver has confidence in the sender's identity. Asserting proof of who sent the message covers the anti-spoofing aspects of authenticity.

The 3rd consideration for authentic channels is the authenticity of the message; that is, the message is not a forgery and is not a "replay" of a previous message. Asserting proof of legitimacy verifies that a message has not been forged. The exchange between the sender and 3rd-party also confirms this via the certificate used. 

The availability aspect of anti-tampering is ensured via proof of delivery. However, no element of cryptography can confirm the delivery and receipt of a message and prevent a denial of service (DOS) attack by flooding a server with duplicates of the same message. That is up to the system or application itself.

Here's an example (right) from an everyday work environment: a digitally-signed email sent with a delivery receipt request.

✔️ Integrity is covered through the digital signature. The digital signature verifies the authenticity of the sender and that the message was not forged. The email application itself should have a feature to detect a replay attack by flagging such messages as a duplicate.

✔️ Availability is covered through the delivery receipt generated by the mail server.

Confidential Channels

Confidential channels are disclosure resistant but not tamper-resistant. Most network communications channels are confidential channels. They are often mistakenly called "secure" channels when, in fact, they are not.

Few channels are truly secure. Creating truly secure channels is impacted most by the assurance of availability, which is often impossible to achieve with most network protocols and physical layer implementations. It is essential to know you are working with a confidential channel and not a secure channel to fully understand the risks that exist without additional processes and controls.

Let's take another commonly known example: Hypertext Transfer Protocol Secure (HTTPS). To be a truly secure channel, HTTPS would need to be disclosure resistant and would also need to address the integrity of each message, the authenticity of the sender of each message, the authenticity of the message itself against forgery and replay, and the availability of the channel. In fact, HTTPS offers no availability assurance and weak integrity assurance; thus, HTTPS is really a confidential channel and not a secure one.

Other channels can be secure or confidential, depending on how they are configured. For example, Secure Shell (SSH) mutually authenticates both ends of the channel. However, the integrity provided depends on the protocols configured on both client and server, and the actual protocol negotiated during connection setup. SSH also provides features to promote high availability, but, like all network protocols, it provides only limited availability assurances. SSH connections are not necessarily confidential, so improper configuration can result in weak or unencrypted connections.

Secure Channels

These provide a secured point-to-point connection between two systems or networks, providing resistance to both tampering and data disclosure. You can create secure channels in several ways:

• Virtual private network (VPN) is a widely deployed mechanism that provides a secured connection in which the remote client network appears to be a part of the host's local network. All communication is cryptographically protected with messages both authenticated and encrypted.
• Transport Layer Security (TLS) is a crypto protocol explicitly used to secure data in transit in computing networks. TLS is sometimes called a Secure Sockets Layer (SSL) VPN, which is inaccurate. TLS actually replaced SSL, which should not be used anymore. TLS prevents eavesdropping and tampering. TLS uses symmetric and asymmetric crypto during a "handshake" process between client and server. It uses digital certificates for authenticity. 
• Secure Shell Protocol (SSH) is widely used in the Unix and Linux worlds. SSH is used to create secure tunnels, usually between clients and servers, and is most often applied to create a secured connection between a client and a server that does not support any protocol-level security. For example, an SSH tunnel can be used to provide a secure Internet Message Access Protocol (IMAP) connection for a mail server that does not support IMAP over SSL (IMAPS). The open-source version of SSH, OpenSSH, now uses NTRU crypto by default for key exchange.

Secure Application Protocols

Many internet protocols were developed without considering security, and now communication over these protocols needs to be secure. As a result, TLS has been bolted onto original protocols to create secured client-server communication without developing new secure protocols.

TLS provides a simple, cost-effective means to secure an existing network protocol without the expense of developing a new secure protocol from the ground up. Examples of where TLS has been added to existing protocols include:

• HTTPS for HTTP
• LDAPS for LDAP
• IMAPS, POPS, and SMTPS for email related protocols
• SIPS, SRTP, and SRTCP for VoIP networking
• IRCS, TELNETS, and FTPS for IRC, Telnet, and FTP

About Ed Adams, CEO

Ed Adams is a software quality and security expert with over 20 years of experience in the field. He served as a member of the Security Innovation Board of Directors since 2002 and as CEO since 2003. Ed has held senior management positions at Rational Software, Lionbridge, Ipswitch, and MathSoft. He was also an engineer for the US Army and Foster-Miller earlier in his career.

Ed is a Ponemon Institute Research Fellow, Privacy by Design Ambassador by the Information & Privacy Commissioner of Canada, Forbes Technology Council Member, and recipient of multiple SC Magazine’s Reboot Leadership Awards. He sits on the board of Cyversity, a non-profit committed to advancing minorities in the field of cyber security,  and is a BoSTEM Advisory Committee member.