Which protocol ensures there is a government grade data encryption in place to help protect your personal data?

Back

Use strong data encryption to transmit restricted data or restricted information, as necessary.

CONTROL ID
00564

CONTROL TYPE
Technical Security

CLASSIFICATION
Preventive

SUPPORTING AND SUPPORTED CONTROLS

This Control directly supports the implied Control(s):

• Manage the use of encryption controls and cryptographic controls., CC ID: 00570

This Control has the following implementation support Control(s):

• Configure the encryption strength to be appropriate for the encryption methodology of the cryptographic controls., CC ID: 12492
• Encrypt traffic over public networks with trusted cryptographic keys., CC ID: 12490
• Authorize transactions of data transmitted over public networks or shared data networks., CC ID: 00566
• Implement non-repudiation for transactions., CC ID: 00567
• Establish trusted paths to transmit restricted data or restricted information over public networks or wireless networks., CC ID: 00568
• Protect application services information transmitted over a public network from unauthorized modification., CC ID: 12021
• Protect application services information transmitted over a public network from unauthorized disclosure., CC ID: 12020
• Protect application services information transmitted over a public network from contract disputes., CC ID: 12019
• Protect application services information transmitted over a public network from fraudulent activity., CC ID: 12018

SELECTED AUTHORITY DOCUMENTS COMPLIED WITH

In detail

• Choose the right algorithm
• Choose the right key size
• Choose the right software
• Keep the key secure

Choose the right algorithm

An encryption algorithm is a mathematical function that transforms plaintext into ciphertext. Choosing the right algorithm is important because vulnerabilities may be discovered over time, or advances in computing processing power may mean that a brute-force attack (ie attempting every possible key) is no longer a time-consuming task.

Example

The ‘Data Encryption Standard’ or DES was developed in the 1970s and standardised as a ‘Federal Information Processing Standard’ in 1977 (FIPS 46). It had a total of 72 quadrillion possible keys.

By the late 1990s, computing power had advanced to the point that it was possible to ‘crack’ a DES key in less than 24 hours by conducting a brute-force search of all possible keys.

The Advanced Encryption Standard (AES) was subsequently published as a replacement for DES as FIPS 197. AES with a 256-bit key size has a potential 115 quattuorvigintillion possible keys, or 115 with 78 digits following it. There is presently no known practical attack that could brute-force an AES 256 key.

You should therefore regularly assess whether your encryption method remains appropriate.

Rather than develop a custom algorithm it is recommended that you use a trusted and verified algorithm. Accredited products can provide an assurance of suitability and also permit you to demonstrate a level of compliance with legal obligations. However, it is important to keep the products being used under regular review, due to the nature of technical development over time.

Choose the right key size

Algorithms use keys to encrypt and decrypt data. Encrypting the same data with a different key will produce a different result. Just as it is important to choose the right algorithm, it is also important to ensure that the key size is sufficiently large to defend against an attack over the lifetime of the data. As computing processing power increases or new mathematical attack methods are discovered, a key must remain sufficiently large to ensure that an attack remains a practical impossibility.

Example

The RSA algorithm is one of the first public-key systems and is used for secure data transmission. It has a potential maximum key size of 4096-bits.

For a number of years, key sizes of 1024-bits were commonplace. However, in 2007, the National Institute of Standards and Technology recommended increasing minimum key size due to advances in computing power. The minimum recommended was 2048-bits up to the year 2030, and 3072-bits after 2030.

This required some certificate providers to increase the key size of their certificates to take account of the recommendation. In other cases, operating system providers took the decision to issue security updates informing administrators of the change.

You should therefore regularly assess whether your encryption keys remain sufficiently large to prevent a brute force or other method of attack. You should also assess the risks and likelihood of an attack given the amount and type of personal data you hold.

Choose the right software

The way that encryption software is put together is also crucially important. Software can use a state-of-the-art algorithm and a suitably long key to output encrypted data, but if its development did not follow good practice, or the product itself is poorly tested or subject to insufficient review, there may be vulnerabilities or other opportunities for attackers to intercept data or break the encryption without the users’ knowledge. It is also possible that the encryption software includes an intentional weakness or backdoor to enable those with knowledge of that weakness to bypass the protection and access the data.

In cases where it is critical to have an assurance that these vulnerabilities do not exist, it is important to gain an external assessment of encryption software. An assessment may also assist you in defining an appropriate algorithm and key size.

It is recommended that you ensure that any solution that you, or a processor acting on your behalf, implement meets current standards such as FIPS 140-2 (cryptographic modules, software and hardware) and FIPS 197 (PDF). Encryption products certified via the National Cyber Security Centre’s CAPS scheme would also meet the current standard. (You should also note that the reference to certification here is not to certification under Articles 42 and 43 of the UK GDPR.)

You can also find additional information on the current status of encryption algorithms in the following publications:

• guidance from the European Union Agency for Network and Information Security (ENISA) on Recommended cryptographic measures as well as its Algorithms, key sizes and parameters report (2014); 
• ECRYPT-CSA’s Algorithms, Key Size and Protocols Report (2018) which builds on the ENISA publications above and may have more up-to-date information; and
• the United States National Institute of Standards and Technology Special Publication 800-131A Revision 1 (Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths). 

In some instances such specific assurances may not be available. For example, many open source software products do not have sufficient capital to fund an appropriate external assessment. However, government security agencies and private IT security organisations can offer advice regarding which specific protocols or algorithms which should be considered appropriate, although you should be aware of the limited assurances when no assurance or guidance is available. An example of such advice from the NCSC on the use of TLS includes:

‘The lack of formal assurance in TLS implementations means there may be implementation weaknesses. Using recent, supported and fully patched versions of TLS implementations from reputable sources will help to manage this risk.’

This statement highlights the importance of keeping software up to date as vulnerabilities in the code may be discovered over time, eg Heartbleed and Shellshock.  

Keep the key secure

It is important to ensure that symmetric keys and private keys remain secret as these provide the ability to decrypt the data.

In many cases keys are stored in a hierarchy for ease of management. The top level key is used to encrypt the keys below it and must therefore be managed securely.
All keys should have a finite lifespan and you need processes in place to generate a new key and re-encrypt the data. The old key should then be archived and securely deleted when no longer required.

In symmetric encryption, the key is sometimes derived from a shorter, more memorable password. It is therefore imperative that any password used to derive or secure the keys also remains secret. A poor choice or a compromise of the password can significantly lower, or even eliminate, the level of protection offered by an encryption product.

In the event that the key is compromised, or even if this possibility cannot be excluded, it may be necessary to revoke the existing key and generate a new key or key pair to protect data in the future.

It is also the case that loss of the decryption key will likely mean that no-one will be able to gain access to the data. Depending on the circumstances, loss of the decryption key could constitute ‘accidental loss, destruction or damage’ to personal data and would therefore be a contravention of the UK GDPR’s security principle; additionally, if you cannot restore the data, this may also constitute a personal data breach due to a lack of availability, depending on the risks this poses.

Example

A laptop is protected using a secure full disk encryption product. This means that when the laptop is switched off the personal data is stored in an encrypted form.

The laptop is stolen. The thief powers on the laptop and is challenged for the password. Without knowledge of the password the thief is unable to access the data.

However, if the laptop user’s username and password were written on a piece of paper stored alongside the laptop the thief has all the necessary information in order to decrypt the data and gain full access to it, thereby rendering the encryption ineffective.

What is WEP and WPA?

What is WPA protocol?

What is WPA and WPA2?

Do I have WEP or WPA?