Corporate Cryptography Policy and Standards

1. Introduction

The proper and accurate implementation and usage of cryptography are extremely critical to its efficiency. A small mistake in configuration or coding will result in removing a large degree of the protection it affords, rendering the crypto implementation useless against serious attacks.

2. Purpose, scope, and users

The purpose of this document is to define rules for the use of encryption controls, as well as rules for the use of cryptographic keys, to protect the confidentiality, integrity, authenticity, privacy, and non-repudiation of information.

This document applies to the entire Information Security Management System (ISMS) and Privacy Information Management System (PIMS) scope and all personal data processing activities.

If users are in doubt as to the definitions or methods contained in this document, they must contact the InfoSec team or send an e-mail to infosec@resolver.com before implementing or utilizing algorithms, crypto libraries, or crypto functions.

The users of this document are IT, Development, DevOps, and QE team members.

3. Reference documents

• ISO/IEC 27001:2013 standard, controls A.10.1.1, A.10.1.2, A.18.1.5
• ISO/IEC 27701:2019 standard, control 6.7.1
• EU GDPR Article 32
• Information Security and Data Privacy Policy

4.  Definitions

4.1. Cryptography

Cryptography is the practice of constructing and analyzing protocols that prevent third parties or the public from reading private messages. Cryptography prior to the modern age was effectively synonymous with encryption, the conversion of information from a readable state to apparent nonsense. This involves the transformation of plain data into encoded data by applying encryption and the decoding of encoded data by decryption.

Cryptography relies on two basic components: a cryptographic algorithm and a cryptographic key.

4.2. Cryptographic Algorithm

A cryptographic algorithm is a mathematical function used for the encryption and decryption of data. The fundamental set of cryptographic algorithms can be divided into three groups:

• Symmetric
• Asymmetric
• Hash functions

4.3. Symmetric Algorithms

The same key is used for message encryption and decryption in symmetric algorithms.

4.4. Asymmetric Cryptography

In asymmetric cryptography, different keys (a public key and its corresponding private key) must be used for encryption and decryption. The encrypting key is called the public key, and the decrypting key is the private key. If you hold the private key, I can send you a message only you can read.

These keys also work in the opposite direction. That is, anything you encrypt with your private key, I can decrypt with your public key. You can use this to sign a document (Digital Signature) digitally.

Encrypt a message with your private key, and I’ll be able to verify your signature by decrypting it with your public key. I am confident that the message came from you because only someone holding your private key could have produced a working signature.

Asymmetric cryptography is synonymous with public key infrastructure (PKI).

There are three asymmetric algorithms in use today:

• Diffie-Hellman
• RSA
• Elliptic Curve

Diffie-Hellman is not quite suitable for establishing identity (Digital Signature) as described above, but the other two algorithms are. RSA is the most commonly used today, but the Elliptic Curve does appear to be on its way to becoming the next standard.

4.5. Encryption Key

The encryption key is a random string of bits used in conjunction with a cryptographic algorithm to encrypt and decrypt (scrambling and unscrambling) data. The key acts as a lock to the encryption process. Knowledge of the appropriate key is required to encrypt or decrypt the data. Keys used in asymmetric cryptography are normally referred to as ‘private’ and ‘public’ keys, whilst those used in symmetric cryptography are referred to as ‘secret’ keys or ‘shared secrets’.

Encryption keys are designed with algorithms intended to ensure that every key is unpredictable and unique.

4.6. Key Pair

A public and private keys are mathematically related; whatever is encrypted with a Public Key may only be decrypted by its corresponding Private Key and vice versa.

4.7. Key Length

The key length describes the amount of data required for the cryptographic key. In the case of cryptographic keys for computer-based algorithms, this is normally expressed as a number of bits. Some algorithms require a fixed key length, while others accept variable key lengths. Typically, the larger the key, the harder a well-written algorithm breaks. It is important to note that it is not normally possible to directly compare the comparative strength of different algorithms based on key length alone.

4.8. Key Storage

As highlighted above, crypto relies on keys to ensure an object’s identity provides confidentiality, integrity, privacy where applicable and non-repudiation. It is vital that the keys are adequately protected. Should a key be compromised, it can no longer be trusted.

Any system that has been compromised in any way should have all its cryptographic keys replaced.

4.9. Hash Functions

Hash functions take some data of an arbitrary length (and possibly a key or password) and generate a fixed-length hash based on this input. Hash functions used in cryptography are such that it is easy to calculate the hash but difficult or impossible to re-generate the original input if only the hash value is known.

In addition, hash functions useful for cryptography have the property that it is difficult to craft an initial input such that the hash will match a specific desired value.

SHA-256 is a common hashing algorithm used today.

4.10. Password Hashing Functions

Password hashing functions are hashing algorithms designed explicitly for the verification of password credentials.  Typically, you do not want to use a fast hashing algorithm such as SHA-256 for this purpose, as it enables a rainbow table or brute force style attacks.  There are specialized algorithms such as bCrypt or sCrypt that serve this purpose well – they are complex and CPU-intensive to utilize, and they typically have a separate salt for every hash, making rainbow table style attacks impossible.

Password hashing functions also utilize a strategy known as key stretching to increase the cost complexity of the hash over time – which enables these algorithms to scale as computing power increases, without having to swap implementations.

For bCrypt, it is important to use key stretching, and you should use a minimum of 10 salt rounds to ensure the hash is secure.

5. Goals

This standard specifies the requirements for using cryptography and all information technology systems used or developed in Resolver. It also defines procedures for ensuring that rules related to the processing of PII are enforced throughout and outside of the system as described below:

5.1. Use of portable devices

• Any portable devices used by Resolver’s employees must have encryption enabled if they store sensitive information.
• When using portable devices, corporate and personally identifiable information MUST NOT be stored or transferred using an unencrypted device.
• Non-sensitive or non-personal information may be stored and transferred using non-encrypted devices. Whilst the security of data is greatly increased when using encrypted equipment, it does not remove responsibility from the user who must always exercise due care and attention when using these devices.
• When data at rest encryption is used, it is only effective when the device is fully powered down or in hibernation. While the device is in use or sleep mode, the encryption is not active and therefore the data is less protected.
• Additionally, data at rest encryption does not protect from a network-borne attack, e.g. using Wi-Fi or a mobile phone network while the device is in use or loss/theft where the device is unlocked.
• Devices must never be left logged on and unattended by the user. Auto-screen locking must be enabled at all times.
• Users must ensure that no other person accesses Resolver’s information systems with their device log-on.
• Resolver’s devices must not be given to others to operate e.g. Resolver’s laptops must not be operated by family members or friends.
• If you suspect your device may have a virus or other form of malicious software, you must immediately notify the IT and InfoSec teams by emailing infosec@resolver.com.

5.2. Information on Resolver portable devices

• Confidential information may only be held on the organization’s portable devices with the permission of IT or InfoSec. This arrangement should be recorded on a Service Information Asset Register and an updated copy sent to the Information Governance Team.
• The Information must be virus checked before transferring onto any Resolver computer. This is done automatically for information that is sent via email.

6. Standards

6.1. Approved Algorithms and Minimum Key Lengths

Do not implement a cryptographic algorithm on your own.
Industry-proven implementations of algorithms (i.e., cryptographic toolkits that have been established over time), using mature and trusted crypto libraries and security providers (e.g.: OpenSSL, JSSE, Bouncy Castle, Schannel,) must be employed.

In the following sections, cryptographic algorithms are listed in order of preference. It is
required that where multiple algorithms are supported, the preferred algorithm be selected. These are the minimum baseline algorithms that should be used.

A stronger version of these approved algorithms is perfectly acceptable (e.g., AES-256-bit versus 128-bit). The use of any algorithm not listed below will require approval.

The following block ciphers (symmetric algorithms) are approved for use:

• AES – preferred key length of 256-bit

The following cryptographic checksums/hashing algorithms are approved for use:

• SHA-256
• SHA-384
• SHA-512

The following asymmetric protocols for digital signature are approved:

• RSA – minimum key length 2048-bit, approved for digital signatures with SHA-256.
• ECDSA – minimum key length 256-bit, approved for digital signatures with SHA-256.

The following key exchange algorithms are approved for use within Resolver:

• RSA
• ECDHE

Symmetric encryption mode of operation:

• CCM, GCM

Message Authentication Codes (MAC):

• CCM, GCM, GMAC, CMAC, HMAC

6.2. Practical recommendations for deployments

Data at rest:

• Data at rest should be encrypted utilizing FIPS 140-2 compliant algorithms for data storage. Currently, it’s ONLY AES 256 Symmetric-Key algorithm.

Data in transit:

• To protect the Privacy, Confidentiality, Integrity, Authenticity, and Non-Repudiation of Data in transit, the latest Encryption best practices should be implemented in the Application Layer protocols (Layer 7).
  • For Web-based Applications, HTTPS over TLS (the latest version).
  • For external file transfer applications FTPS or SFTP over TLS (the latest version).
• In the Transport Layer (Layer 4) TCP layer, the application should be configured to utilize ONLY TLS v1.2 and TLS v1.3 (the latest version) with cipher suites supporting Authenticated Encryption with Associated Data (AEAD), e.g., AES-GCM, AES-CCM.

6.3. Password Hashing

• It is strongly recommended to utilize slow Password Hashing Functions like bCrypt.

6.4. Web Applications

Web application front end should be configured to use ONLY:

• HTTPS Secure Protocol over TLS v1.2 and TLS v1.3 with cipher suites supporting Authenticated Encryption with Associated Data (AEAD), e.g. AES-GCM, AES-CCM.
• Digital Server certificate should utilize:

Digital signature algorithm:

Key size:

Hash Algorithm:

6.5. Tokenization

If Server-side implementation using a Tokenization mechanism in combination with Token Signing/Verification like JWT:

The Token should be signed using the following algorithms:

6.6. Cryptographic keys

InfoSec team is responsible for these rules. However, the activities related to key management are the DevOps responsibility:

• Generating private and public cryptographic keys.
• Activation and distribution of cryptographic keys.
• Defining the time limit for the use of keys and their regular updating (in accordance with risk assessment).
• Archiving inactive keys, which are necessary for encrypted electronic archives.
• Destruction of keys.

Keys are managed by their owners in line with the abovementioned rules.

Cryptographic keys should be protected against loss, change, or destruction in the best secure way that is available in the system where this key is deployed.
In the case of loss, corruption, or destruction, keys will be revoked, and new ones will be issued and deployed instead of revoked.

7.  Validity and document management

This document is valid as of August 2023.

The owner of this document is an Information Security Analyst who must check and, if necessary, update the document at least once a year.

When evaluating the effectiveness and adequacy of this document, the following criteria need to be considered:

• The number of incidents arising from the unclear definition of the Cryptography Policy.

EFFECTIVE ON: August 2023

REVIEW CYCLE: Annual at least and as needed