Encryption

Encryption is a mathematical method of ensuring confidentiality by preventing information from being read by unauthorised parties.

The information is “locked up” using a key and cannot be read until it has been unlocked using the right key. The key that is used to unlock the information does not need to be the same as the one used to lock it up in the first place.

Symmetric encryption

Symmetric encryption means that the same key is used to lock up and to unlock the data. The sender and recipient must send the key between them in a secure manner.

Asymmetric encryption

Asymmetric encryption is also often called public key encryption. Asymmetric encryption involves using a pair of keys: one is private and the other is public, and the keys are mathematically related to each another. The public key can be made available to anyone, while the private key is known only to its owner. Although there is a mathematical relationship between the two keys, it is not possible to deduce either key from the other. The public key can be freely distributed. The validity and authenticity of the public key must, however, be verified and managed.

These two methods require keys of different lengths.

What requirements does Itera set in relation to encryption?

Itera generally refers to the Norwegian National Security Authority’s NSM Cryptographic Recommendations, as well as to the recommendations it provides in its security blog.

What adequately safeguards confidentiality?

The most important factor is to employ extensively used and well-regarded algorithms and methods, as well as sufficiently long keys.

Three elements determine whether something is encrypted securely enough:

1. Functions – cryptographic mechanisms. If using symmetric encryption to safeguard confidentiality, AES with a 128 or 256-bit key is recommended. If using a hash algorithm, an SHA-2 algorithm that is at least 256-bits strong is recommended. If using an RSA algorithm, a 3072-bit key is recommended.
2. Confidence in the cryptographic module: Cryptographic modules that generate, protect and use private keys or session keys should be evaluated against the Common Criteria, FIPS 140-2 or similar.
3. Key management. Keys can be created in software (for personal use) for data communication purposes (data in transit). Keys must be created and used in hardware for long-term storage (data at rest). The lifetime of keys depends on the extent to which they are protected. Long-term keys must be asymmetric and digital certificates, and PKI must be used for key management. Keys must be deleted properly after use.

If any of these elements is missing or is weak, the level of protection will not be sufficient.

Who decides if the level of protection provided is sufficient?

As the controller, Itera itself carries out a risk assessment of the content that needs to be protected. A payslip is an example of a document that can contain sensitive personal data and that therefore needs to be kept confidential.

The passwords used to encrypt data and how these are managed also have to be risk-assessed in relation to each individual need for processing and processing method chosen.

What information does Itera think it is necessary to encrypt?

We think confidentiality is necessary when the information that is transferred comprises:

1. Special categories of personal data (sensitive personal data)
2. National identity numbers
3. Personal data about multiple people
4. Personal data that a controller has classified as requiring protection.

When and how does information have to be encrypted?

When data communication is used (data in transit)

Personal data that is to be transferred between two or more locations by means of data communications. This could be:

• Between the company’s (data controller’s) own locations
• Between the company and a provider (data processor or security partner)
• Between a supplier and a sub-contractor, or
• Between suppliers’ data centres.

Transfers by email and website

The most usual means is HTTPS. The highest version of TLS (Transport Layer Security) should be used, and SSL 3.0 (or below), which has known weaknesses, should be avoided. TLS 1.0 is an improvement on SSL 3.0, TLS 1.2 has its own problems as well, but this depends on the algorithm and client. TLS 1.3 is in draft form and will soon be released.

Encryption of individual files

If, in connection with transferring individual files, it is not possible to encrypt the email or to be certain that the email transfer is encrypted, it may be appropriate to use the encryption mechanisms that are built into some software systems. Examples of these include ZIP, PDF and more recent versions of MS Office. These all support AES 256.

The encryption key must be secured and sent separately to the recipient. An alternative is to send the key as an SMS or to communicate it orally over the telephone. Such approaches must be risk-assessed and we only recommend doing this in instances where it is not possible to encrypt the communication itself. The problem is that it may not be possible to adequately control the destination points and it is not possible to completely protect against being overheard or hacked.

Hard disk encryption

Hard disk encryption primarily protects the confidentiality of data when a computer is turned off. The data is thereby protected if your computer is lost or stolen. Hard disk encryption has become a standard function in modern operating systems. Examples include FileVault for MacOS, BitLocker for Windows, and hardware-based hard disk encryption from Intel.