What You Need to Know About Encrypted Communication

You’ve also heard the term encryption used in various contexts and in combination with other terms. Encryption, in general, is the name given to the mathematical operation that prevents a message from being read except for the person or persons who have a key to decrypt that message.

Throughout history, people have sent messages that they hope only the person they want will read, using encryption. Today, we have computers that can do this encryption for us. Today, digital encryption technology, which goes beyond confidential messaging, can also be used for particular purposes such as authenticating the author of messages.

Encryption technology, which is almost impossible to crack when appropriately used, is one of the most important tools we have today to protect our information from bad actors, governments, and service providers.

See Also: Securing Card Data in Transit: PCI DSS Requirement 4

There are two primary methods in which encryption is used; basically, the scrambling of stored data and the encryption applied at the time of transmission. We will take a look at the encryption method applied at the time of communication.

Data transferred is the name given to information that moves from one network to another. For example, messages you send using a messaging application go first to the company’s servers where you use the service, then to the recipient’s device. Surfing the internet is another example of data being transferred: when you visit a site, the page’s data is transferred from the site’s server to your computer.

It is essential to verify the encryption method and verify that your communication with the person you are talking to is encrypted.

There are two ways to encrypt the transferred data: transport-layer encryption and end-to-end encryption.

What is Transport Layer Encryption (TLS)?

Transport layer encryption, also known as transport layer security (TLS), encrypts your messages as they are transmitted to the servers of the application you use and from the application’s servers to the recipient.

The messaging service provider in the middle of the transfer process, the website you visit, or the application you use can read unencrypted copies of your messages. Your messages, which can be read and stored by company servers, are not protected against data leaks experienced by the company or legal requests for user information.

Have you noticed the “HTTPS: //” text and the green lock to the left of pcidssguide.com in the browser’s address line? HTTPS is an example of transport layer encryption that we often encounter on the internet. HTTPS is more secure than unprotected HTTP.

See Also: Public Key Cryptography and PGP Fundamentals

Because when you browse sites using HTTPS, although the site sees the information you enter (your messages, calls, credit card numbers, login information, etc.), it cannot be seen by the actors who monitor your internet network.

HTTP does not provide any protection against people who monitor your network or try to monitor the sites you browse. HTTPS hides individual pages of the sites you visit from these actors. When you browse a site using HTTPS, an attacker monitoring your network can only see the address before the split (/).

The internet is currently going through a considerable period when all sites are starting to use HTTPS. The reason behind this transition is that HTTPS is secure. Sites that use HTTP are vulnerable to tracking, content modification, cookie stealing, username and password stealing, targeted censorship, and many other problems.

VPN as an Example of Transport Layer Encryption

Virtual Private Networks (VPN) is another example of transport layer encryption. Without a VPN, your internet service provider transfers your internet traffic. When you use a VPN, your internet traffic is encrypted between you and your VPN provider, even though your internet service provider transmits your internet traffic. If anyone gains access to your local network and tracks your internet traffic, they will find that you are using a VPN but not the websites you visit. Your internet service provider can detect the VPN service you are using.

When you use a VPN, your internet traffic cannot be tracked by your internet service provider but can be monitored by the VPN service you use. The VPN service you use can monitor, store, or modify your internet traffic. Using a VPN shifts your trust from the internet service provider to the VPN provider. As a result, you must ensure that your VPN service is trustworthy.

What is End-to-End Encryption?

End-to-end encryption protects your messages from the sender until they are transmitted to the recipient. In end-to-end encryption, the data is converted into an encrypted message by its original sender (first end), and this message is decrypted by the receiver (second end). No factors in between, including the application you are using, can monitor your activities or give you an ear.

See Also: What You Need to Know About PCI Validated Point-to-Point Encryption (P2PE) Solutions

Accessing end-to-end encrypted messages via an application with your device means that the application development company cannot read those messages. One of the main features of good encryption is that individuals or institutions that design and implement encryption cannot be cracked.

Transport Layer Encryption or End-to-End Encryption?

Before making this decision, ask yourself some fundamental questions: Do you trust the service or application you use? Do you trust the technical infrastructure of these systems? Do you believe that these services will defend their users against legal requests for user information?

If you replied “no” to all of these questions, end-to-end encryption is the way to go. If your answer to the questions is “yes,” a service that supports transport layer encryption may be sufficient for you; however, it is generally a better decision to opt for services that use end-to-end encryption whenever possible.

What are the Situations in which Encryption During Transfer Does Not Work?

Encryption is not a panacea. Even if you send your messages in encrypted form, the person you are talking to will decrypt those messages. If your endpoints’ security (the devices you use to communicate) has been compromised, the security of encrypted correspondence on these devices can also be compromised. The person you are communicating with can also take screenshots of your correspondence or save conversation logs.

See Also: PCI Compliance and Email Security

If you encrypt your data in transit, your correspondence’s content is preserved, but the metadata is not encrypted. For example, you can encrypt the content of your messages and change them so that others cannot understand, but this is encryption:

• With whom you are communicating,
• That you are using encryption while communicating,
• does not protect other information such as location, time, and correspondence time.

Also, if you use encryption on a network, your metadata may appear suspicious. This is why the supporters of encryption encourage everyone to use encryption tools: more use of encryption normalizes it.

What are the PCI DSS Encrypted Communication Requirements?

PCI DSS Requirement 3 details technical guidelines and encryption requirements to protect stored cardholder data and provide high-level details on encryption. At a minimum, it requires making the PAN (primary account number) unreadable wherever it is stored, including PCI, portable digital media, backup media, and logs.

Note, however, that even if an organization encrypts all of its data, it will still need to be PCI compliant if involved in the storage, processing, or transmission of cardholder information. The PCI Standards Security Council (PCI SSC) is clear that encrypting cardholder information does not exclude PCI compliance.

See Also: What You Should Know About PCI Compliant File Transfer

Although PCI DSS requires encryption or another concealment of PAN, the payments industry as a whole still has some perceived shortcomings. In particular, PCI does not require encryption of data in transit over a private or internal network.

For example, some public networks consist of multi-protocol Label Switching (MPLS) and Flat Legacy Telephone System (POTS) and are the most general by nature. Still, PCI DSS requirements make exceptions to them.

See Also: What Are the PCI DSS Encryption Requirements

There is also some confusion about whether satellite-based data networks are public or private and therefore need encryption capabilities.

But this subjectivity is the position taken so far by the PCS SSC and major card brands regarding PCI compatibility of satellite networks. The general or private satellite network status’s final decision is left to the individual PCI QSA (Qualified Security Assessor), who reviews the relevant applications. Therefore, there may be some differences of opinion regarding actual compliance between different QSAs.

Remember that sensitive data is not just credit card data but can be personal data, financial information, health information, or information that makes your company strong against your competitors or your customers trust you.

When it comes to communication security, PCI DSS requirement 4 may be one of the most straightforward requirements to comply with, but it depends on the infrastructure you have. The most commonly used protocols for this purpose are TLS, SSH, and VPN. Almost any transmission protocol can be tunneled through one of these three methods.

You can use FTP over a TLS channel, SMTP over TLS, or of course, HTTP over TLS (HTTPS); Therefore, you can use HTTPS, FTP/S, or SMTP/S as per the requirement with the right TLS protocol configuration on all your networks.

When using TLS to secure communication, there are a few things to bear in mind:

• Use a current acceptable TLS version.
• Allow only secure password packets.
• Use x.509 certificates issued by a certified Certificate Authority (CA) within their validity period.
• Avoid TLS 1.0, RC4, DES or 3DES, SHA-1, DH, or RSA with 1024 bit key length in encryption packets and releases.
• Try not to use self-signed certificates either, as you will need to justify why you are not using a certificate issued by a reputable CA, even though there are now entirely free well-issued certificates for cloud applications such as Let’s encrypt or AWS Certificate Manager.
• Check the strength of your HTTPS application.

However, because TLS is widely adopted, there are some environments where companies do not respect the privacy of TLS and set up networks to open TLS tunnels and control traffic. They can achieve this using root certificates installed on corporate machines and an exemplary proxy configuration.

To protect traffic against these media types, you must encrypt information in a different layer than transmission. Typically, the application layer and information must be encrypted before being sent through the tunnel. You can ensure communication security by creating two layers of protection, one on the transport layer and one on the application layer. If someone decides to open the TLS tunnel, they will be faced with an application layer encryption.

Of course, you will need to have good key management for this technique to be useful. If you encrypt or decrypt an asset beyond your control, such as client-side, mobile applications, client / desktop applications, never use a symmetric algorithm for encryption.

You will also need to use asymmetric techniques and algorithms. If you have control over the encryption and decryption environment, you can use symmetric encryption. Especially in symmetric encryption, you need to consider key rotation, key generation, distribution, and more.

Keep in mind that special care is taken when transmitting and when using public networks in public networks. The internet and other networks such as WiFi, Bluetooth, GPRS, GSM, 3G, 4G, Satellite, and more are considered to be public. When using any of these networks, strictly encrypt the message at the application layer.

Don’t Use Old Version TLS Versions.

In response to the well-known POODLE exploit on SSL and NIST’s latest SSL conclusions, the PCI Council decided that SSL and TLS 1.0 would no longer be available after June 30, 2016. Likewise, as of April 2014, it was declared that SSL was not approved for use in protecting Federal information.

The key point is that TLS implementations allow for a downgrade negotiation phase, in which the client and server agree to use a weaker SSL protocol even though they started the exchange with TLS 1.2.

Because of this throttling mechanism, the SSL-targeted POODLE attack could potentially be used to take a bite out of TLS by forcing servers to use legacy SSL. Security researchers discovered in December 2014 that a POODLE-style attack could be launched directly on TLS without the need to negotiate a downgrade.

As a result, the PCI Council says you should altogether remove SSL 3.0 and TLS 1.0 support. In short, servers and clients should disable SSL and then preferably switch everything to TLS 1.2.

However, TLS 1.1 can be accepted if appropriately configured. You can refer to the NIST publication to examine how to do this configuration.

Secure End-User Messaging

Most of the PCI DSS requirements focus on protecting PANs. PCI DSS Requirement 4 sets out some specific rules for forwarding PANs over open networks. As a result, technologies your organization typically uses, such as end-user messaging, may need to be adapted, changed, or stopped while cardholder data is transmitted.

The main limitations of PCI DSS Requirement 4 are as follows:

• PANs can never be sent over commercial technology like e-mail, instant messaging, or chat app
• s without being encrypted.
• You must ensure the PANs are made unreadable through strong cryptography before using any of these end-user technologies.
• If a third party demands a PAN, the third party must have a mechanism or means to secure the PAN or render it unreadable before transmitting it.

Summary

Sensitive data is highly vulnerable when transmitted over open networks, including the internet, public or otherwise untrusted wireless networks, and cellular networks. Trusted keys/certificates, secure transfer protocols, and strong encryption are all required by the PCI Security Standards Council. The PCI Council also gives you the task of reviewing your security protocols to ensure they follow industry best practices for secure communications.

See Also: Email Security Best Practices

Many potential attackers are eavesdroppers trying to exploit known security weaknesses. PCI DSS includes the following requirements for connecting with other systems:

• Continue only when you have trusted keys/certificates. You are expected to verify these keys and certificates and make sure they do not expire.
• Configure your systems to use only secure protocols and do not accept connection requests from systems using weaker protocols or insufficient encryption key lengths.
• Apply strong PCI DSS encryption for authentication and transmission over wireless networks that transmit cardholder data or are connected to the cardholder data environment.

Encrypting data both while transferring and storing it will provide more comprehensive protection. This is what security experts mean when they say “full protection.” Protecting your data using different methods is a complete security solution.

For example, suppose you send unencrypted messages (data in transit is not encrypted) with an encrypted device (stored data is encrypted). In that case, your messages will not be protected against network trackers, governments, service providers technically competent enemies. The data you save on your laptop, on the other hand, would be safe from an intruder who has physical access to it but does not know your password.

Conversely, suppose you send your end-to-end encrypted messages (encrypted in transit) with an unencrypted device (stored data is not encrypted). In that case, your messages will not be read by others on the network. However, the information you hold on your device will not be protected against an attacker who has physical access to the device.

As the examples show, encrypting your data both while transferring and storing it will protect your data more comprehensively against different attacks that they may be exposed to.