«Approved Cryptographic Algorithms Good Practice Guideline Programme Document Record ID Key NHS Informatics Sub-Prog/ Architecture Project Prog. ...»
Approved Cryptographic Algorithms Good Practice Guideline
Programme Document Record ID Key
Prog. Director Shaun Status APPROVED
Owner James Wood Version 3.0
Author Mark Penny Version Date 4 October, 2012
Approved Cryptographic Algorithms Good Practice
© Crown Copyright 2012
Approved Cryptographic Algorithms Good Practice Guideline th 4 October, 2012 | APPROVED | 3.0
Version Date Amendment History nd 1.0 22 February, Previously approved version by Stuart Thomas (Ref: NPFIT-FNT-TO-IGGPG-0004.01) rd 1.1 3 July, 2009 Updated draft for comment. Content transferred from published NPFITFNT-TO-IG-GPG-0004.01 (dated 22nd February, 2006) to new template.
Content reviewed and amended as required. (Content updates shown as ‘Track Changes’.) st 1.2 21 July, 2009 Updated following comments from peer review th 1.3 24 July, 2009 Draft for approval rd 1.4 3 August, Final draft for approval revised due to comments on previous draft for 2009 approval th
1.4a 15 Responses to comments on approval September, th 2.0 16 Document approved September, th 2.1 17 Amendments to recommendations for version of TLS to use (neither TLS November, 1.1 nor TLS 1.2 are as yet widely supported.) th 2.2 20 Document approved November, 2.3 17th August, Updated in line with the recommendations in NIST SP800-131A, various document reference amendments, updates to change ‘NHS CFH’ to ‘NHS Informatics’ (see companion document “Approved Cryptographic Algorithms Good Practice Guideline – changes between v2.2 and v3”) th 2.4 28 August, Further updates foll
Contents 1 About this Document
2 Secure Cryptographic Hashing Algorithms
2.1 Hashing Algorithms for Digital Signature Generation/Verification..........9
2.2 Hashing Algorithms for non-Digital Signature Generation/Verification purposes 10 2.3 Hashed Message Authentication Code (HMAC)
2.4 A Note on MD5 and SHA-1
3 Symmetric Ciphers
3.1 Block Ciphers
3.2 Stream Ciphers
4 Asymmetric Ciphers
4.1 Key Exchange and Key Agreement
Digital Signatures – Approved Signature Primitives
4.2 5 Pseudo Randomness and Entropy Sources
5.1 Cryptographically Strong Pseudo Random Numbers
5.2 Entropy Sources
6 Preferred uses of cryptographic algorithms in security protocols
6.1 Secure Socket Layer Protocol (SSL), and Transport Layer Security Protocol (TLS)
6.1.1 A Note on SSLv2
6.1.2 SSL (Secure Sockets Layer) version 3.0
6.1.3 TLS (Transport Layer Security) version 1.0, 1.1 & 1.2
6.2 Network Layer VPN protocol
7 Frequently Asked Questions
1 About this Document
1.1 Purpose This guide addresses the high-level, cryptographic algorithm requirements of NHS Informatics. These requirements apply to all NHS Informatics contractors and any associated 3rd parties. In addition, they are provided as recommendations to the NHS as a whole as current good practice in relation to cryptographic algorithms and key lengths.
This guide does not describe cryptographic policies or controls.
Please note that this guide refers to ‘NHS Informatics’ instead of ‘NHS Connecting for Health’ (NHS CFH). The term ‘NHS CFH’ is currently being phased out as the organisation merges with the NHS Information Centre to form the ‘Health and Social Care Information Centre’ (HSCIC).
1.2 Audience In order to make best use of this guidance, a reasonable understanding of the purpose and uses of cryptography is required. Deep technical knowledge of cryptographic algorithms and so forth is not necessary. This guidance is suitable for all NHS Informatics suppliers and 3rd parties as well as members of NHS organisations.
1.3 Background N3 is a private Wide Area Network (WAN). Connection is therefore strictly limited to authorised endpoints. All organisations wishing to make a new connection to N3 are responsible for ensuring that their connection to the WAN does not compromise the security measures already in place.
N3 is a private network consisting of thousands of PCs, servers, printers and other items of equipment all acting as the nodes or endpoints on the network. Information is unencrypted when transmitted over the network therefore confidentiality of sensitive information within N3 is not assured. However, all applications provisioned as part of the NHS SPINE contract encrypt data using either Secure Sockets Layer (SSL) or Transport Layer Security (TLS). It is therefore advisable for existing systems to take the appropriate measures to ensure that sensitive data is secure before connecting to N3.
N3 faces numerous threats to security as a result of incompletely protected partner networks or connections to uncontrolled external networks such as the internet.
These threats are continually evolving in both strength and frequency. On-going vigilance and the maintenance of strict security standards are essential to the continuing success of N3.
This document comprises advice and guidance on the following sections / topics:
Secure Cryptographic hashing algorithms Hashed Message Authentication Codes (HMAC) Symmetric encryption algorithms Asymmetric encryption algorithms Pseudo-randomness and entropy sources Preferred uses of cryptographic algorithms and key sizes within various security protocols (e.g. TLS) Frequently asked questions on cryptographic algorithm and key sizes
1.5 Disclaimer Reference to any specific commercial product, process or service by trade name, trademark manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favouring by NHS Informatics. The views and opinions of authors expressed within this document shall not be used for advertising or product endorsement purposes.
Any party relying on or using any information contained in this document and/or relying on or using any system implemented based upon information contained in this document should do so only after performing a risk assessment. It is important to note that a risk assessment is a prerequisite for the design of effective security countermeasures. A correctly completed risk assessment enables an NHS organisation to demonstrate that a methodical process has been undertaken which can adequately describe the rationale behind any decisions made. Risk assessments should include the potential impact to live services of implementing changes.
This means that changes implemented following this guidance are done so at the implementers’ risk. Misuse or inappropriate use of this information can only be the responsibility of the implementer.
2 Secure Cryptographic Hashing Algorithms Broadly speaking, secure hashing algorithms take an input of variable length and produce an output of fixed length. This is known as a ‘message digest’ or ‘hash value’.
The algorithm must provide output that is not invertible (i.e. is only one-way), and must not produce collisions (i.e. two different inputs produce the same output).
In general, applications use secure hashing algorithms for:
Integrity checking: e.g. a tamper-evident seal for a file.
Authentication: e.g. Digital Signatures (with asymmetric algorithms), Hashed Message Authentication Codes (HMAC) and pseudo-random number generation (PRNG).
The guidance in this part of the document is broken into four sections as follows:
Guidance on the use of hashing algorithms for digital signature generation/verification purposes Guidance on the use of hashing algorithms for non-digital signature generation/verification purposes Guidance on the use of hashing algorithms for Hashed Message Authentication Codes (HMAC) A note on the MD5 and SHA-1 hashing algorithms
2.1 Hashing Algorithms for Digital Signature Generation/Verification The following are secure cryptographic hashing algorithms for Digital Signature
Generation/Verification suitable for use in the NHS:
SHA-224: A 224-bit (28-byte) hash SHA-256: A 256-bit (32-byte) hash that provides 128 bits of security against collision attacks.1 SHA-512: A 512-bit (64-byte) hash.
Whirlpool: A 512-bit, collision-resistant, one-way hash function.2 For further details see: http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf For further details see: http://www.larc.usp.br/~pbarreto/WhirlpoolPage.html
2.2 Hashing Algorithms for non-Digital Signature Generation/Verification purposes The following are secure cryptographic hashing algorithms for all non-digital
signature generation/verification purposes, suitable for use in the NHS:
SHA-1: A 128-bit (16-byte) hash that provides 80 bits of security SHA-224: A 224-bit (28-byte) hash SHA-256: A 256-bit (32-byte) hash that provides 128 bits of security against collision attacks.3 SHA-512: A 512-bit (64-byte) hash Whirlpool: A 512-bit, collision-resistant, one-way hash function.4
2.3 Hashed Message Authentication Code (HMAC) A HMAC takes a given message, applies a secure hashing function (for integrity), and then encrypts the message digest with a shared secret (for authentication).
HMAC provides guarantees on the integrity and authenticity of messages and is utilised within various cryptographic protocols such as TLS and IPSec.
HMAC selection should be compliant with at least RFC2104, or preferably FIPS 198standard.
The following HMAC standards are suitable for NHS use:
HMAC FIPS 198-1.5 (see also SP800-1076) HMAC RFC 2104.7 For further details see: http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf For further details see: http://www.larc.usp.br/~pbarreto/WhirlpoolPage.html For further information see: http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf http://csrc.nist.gov/publications/nistpubs/800-107/NIST-SP-800-107.pdf For further information see: http://www.faqs.org/rfcs/rfc2104.html
2.4 A Note on MD5 and SHA-1 Do not use Message Digest 5 (MD5).
There is considerable lack of confidence in MD5 due to proven collision attacks. If already in place, MD5 must be phased out and replaced depending on purpose with one of the SHA family of hashing algorithms (one of the SHA-2 family for digital signing purposes or minimum SHA-1 for non-digital signing purposes.) The UK Communications Electronics Security Group (UK CESG8) and the US National Institute of Standards and Technology (US NIST9) do not recommend the use of MD5.
Do not use Secure Hash Algorithm version 1 (SHA-1) for Digital Signature Generation/Verification There is considerable lack of confidence in SHA-1 security due to proven collision attacks for the purposes of digital signature generation/verification. If already in place for digital signing, SHA-1 should be phased out and replaced with SHA-224 or greater.
UK CESG and US NIST10 no longer consider SHA-1suitable for new deployments for digital signing purposes.
http://www.cesg.gov.uk/ http://www.nist.gov/ http://csrc.nist.gov/groups/ST/hash/policy.html - statement on use of SHA-1 and SHA-2 and http://csrc.nist.gov/groups/ST/hash/statement.html - statement on cryptanalytic attacks on SHA-1
3 Symmetric Ciphers Symmetric ciphers use the same key to encrypt and decrypt data (single key or private key). These ciphers are often utilised for bulk encryption because they are generally more computationally efficient than asymmetric ciphers.
3.1 Block Ciphers A block cipher is one in which a block of plain text is treated as a whole and used to produce a cipher text block of equal length.
The following block ciphers and minimum key sizes are currently suitable for NHS
use within existing systems:
Triple-DES:11 Equal to 168 bits. (Keying option/mode 1) Also referred to as Triple Data Encryption Standard. This is a mode of the DES encryption algorithm that encrypts data three times. Three 56-bit keys are used (excluding parity bits), instead of one, for an overall key length of 168 bits (the first block of plaintext is encrypted with the first key, the resulting ciphertext is then encrypted with a second key, and the resulting cipher text is again encrypted with a third key).12 AES:13 Greater than or equal to 128 bit.14 The Advanced Encryption Standard. A cryptographic algorithm (symmetric block cipher) that supports three key sizes: 128, 192 and 256 bits. This is the preferred option for existing systems.
Blowfish15: Greater than or equal to 256 bit. Blowfish is a symmetric block cipher that can be used as a drop-in replacement for DES. It takes a variable-length key, from 32 bits to 448 bits.
For all new system deployments, the following block ciphers and minimum key sizes
http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf Due to the ‘meet in the middle’ attack, 3DES using key mode/option 1 only provides effective security of 112bits. As a result, only ‘key mode/option 1’ should be used with 3DES. No other key mode/option should be used due to possible attacks.
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf See Q1 in the FAQ at the end of this document (section 7) for information on AES-128 and AES-256 http://www.schneier.com/blowfish.html http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf McAfee Endpoint Encryption (as purchased under an Enterprise Wide Agreement for the NHS by NHS CFH) utilises AES-256 for full disk encryption.
3.2 Stream Ciphers A stream cipher encrypts a digital data stream one bit or one byte at a time.