Encryption in transit for GDPR
Our series of GDPR blog posts highlight how the new regulation will impact your data transfer and file sharing processes and systems. ‘Encryption in transit for GDPR‘ looks at this key part of processing.
Your data transfer responsibilities can be open to interpretation in some areas of the GDPR. One thing that’s abundantly clear, however, is the need to encrypt personal data during processing (i.e. during the transfer).
Article 32 tells both the controller and processor to “implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including…encryption of personal data”.
Obviously, this is where Secure File Transfer becomes necessary. Transfers are generally going to be secured using either SSL (both FTP & HTTP) or SSH.
We’re all familiar with SSL and tend to use it to describe both the “Secure Sockets Layer” and “Transport Layer Security” (TLS) cryptographic protocols. Only TLS, however, can still be considered secure. SSL is no longer safe to use (In 2016, the PCI Council updated the PCI-DSS standard to exclude all SSL versions plus TLS 1.0 as well). Whilst TLS 1.1 is still considered secure, it’s preferable to only use TLS 1.2, which is considered by some to be “more secure”.
Unfortunately though, many older computers cannot transfer using TLS. This leaves some organisations with a dilemma. Allow these older insecure protocols or insist that clients upgrade their computers? With the introduction of GDPR, this is no longer an option.
SSL relies on certificates, which need managing and ensuring they are properly signed. It is safe to say that self-signed certificates will not be acceptable from a GDPR perspective.
SFTP (SSH file transfer) is generally considered to be secure and in many cases is preferred to SSL because it only requires one firewall port to be opened. SSH public keys should be exchanged between the client and server in advance of use, to ensure that the correct keys are accepted.
In either case, regardless of which protocol you decide to employ, you will also need to be aware of ciphers and algorithms. In the same way that some cryptographic protocols are considered insecure, some ciphers and algorithms are too. For example, for SSL you would disable DES and RC4 and for SSH you would disable arcfour. Your data protection officer should be able to tell you the full list of which ciphers to disable.
Another important point to consider is whether you need to play the client or server role. In other words, will you transfer the files, or provide a secure location for people to exchange files. As a client, you are somewhat at the mercy of the server owner who will dictate which protocols may be used. Conversely, as the server owner, you need to ensure that either the software that you select supports a broad variety of clients, or else distribute client software to your trading partners.