Cryptography Standards

Introduction

Cryptography is one of the more advanced topics of information security, and one whose understanding requires the most schooling and experience. It is difficult to get right because there are many approaches to encryption, each with advantages and disadvantages that need to be thoroughly understood by web solution architects and developers. In addition, serious cryptography research is typically based on advanced mathematics and number theory, providing a serious barrier to entry.

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 and rending the crypto implementation useless against serious attacks.

Definitions

Cryptography

Cryptography is about 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, which is the transformation of plain data into encoded data by the use of encryption and the decoding of encoded data by decryption. Cryptography relies on two basic components: a cryptographic algorithm and a cryptographic key.

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

  • Symmetric
  • Asymmetric
  • Hash functions

Symmetric Algorithms

In symmetric algorithms for a message encryption and decryption process, the same key is used.

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 that only you can read.

These keys will 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 digitally sign a document (Digital Signature). Encrypt it with your private key, and I’ll be able to verify your signature by decrypting with your public key. I have confidence that the message came from you because only someone who holds 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 are. RSA is the most common today, but Elliptic Curve appears to be on its way to becoming the next standard.

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.

Key Pair

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

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 except variable key lengths. Typically, the larger the key the more difficult a well-written algorithm becomes to break. 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 (!)

Key Storage

As highlighted above, crypto relies on keys to assure an object identity, provide confidentiality and integrity as well as 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.

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 have the property 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 common hashing algorithm used today.

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 rainbow table or brute force style attacks.  There are specialized algorithms such as bCrypt or sCrypt which 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.

Goals

This standard specifies the requirements for the use of cryptography and all information technology systems used or developed in Resolvers.

Standards

  • !!! Do not implement cryptographic algorithms on your own !!!
  • TLS v1.2 – PCI Mandate to Retire TLS 1.0 starting June 30, 2016.
  • SHA1 and MD5 hash Algorithms PROHIBITED TO USE anywhere (obvious, just a reminder)
  • Support for Forward Secrecy (FS also, known as Perfect Forward Secrecy (PFS))
  • Support for TLS v1.2 (only) with ciphers suites supporting Authenticated Encryption with Associated Data (AEAD), e.g. AES-GCM, AES-CCM.
  • Do not use a fast hashing algorithm to store Passwords

Approved Algorithms and Minimum Key Lengths

1.1 Do not implement cryptographic algorithms on your own.
It is required that industry has proven implementations of algorithms (i.e. cryptographic toolkits that have stood the test of time), mature and trusted crypto libraries and security providers (e.g.: OpenSSL, JSSE, Bouncy Castle, Schannel,)

1.2 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.

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

  • AES – preferred key length of 256-bit

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

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

1.5 The following asymmetric protocols for a 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

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

  • RSA
  • ECDHE

 

Symmetric encryption mode of operation

  • CCM, GCM

Message Authentication Codes (MAC)

2.1 Message authentication code

  • CCM, GCM, GMAC, CMAC, HMAC

 

Practical recommendations for deployments

Data at rest:

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

Data in transit:

  • Data in transit should follow latest Encryption best practices according to Application Layer protocol (Layer 7) is utilized in Application.
  • In Transport Layer (Layer 4) TCP layer, application should be configured to utilize ONLY TLS v1.1 and TLS v1.2 with ciphers suites supporting Authenticated Encryption with Associated Data (AEAD), e.g. AES-GCM, AES-CCM

Password Hashing:

  • Strongly recommended to utilize slow Password Hashing Functions like bCrypt.

Web Application front end should be configured to use ONLY:

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

Digital signature algorithm:

Algorithm name

Comments

SHA256RSA

 

SHA256ECDSA

Recommended for mobile application usage, since more efficient

 

Key size

Algorithm name

Public Key size

Comments

RSA

2048

 

RSA

4096

Recommended

ECC

256

Recommended

ECC

384

Optional

 

Hash Algorithm:

Algorithm name

 

SHA256

Recommended

SHA384

Optional

SHA512

Optional

 

Tokenization

  • If Server side implementation using Tokenization mechanism in combination with Token Signing/Verification like JWT:
  • Token should be signed using the following algorithms:

Algorithm name

 

HS256

Recommended for testing environment

RS256

Recommended+, Standard for distributed, microservice architecture with one Token issuer and multiple validation points

ES256

Recommended+, since more efficient

 

Page was last updated: April 2017