Final | June 2019 | v1.0.2 | OFFICIAL - Public | QGCDG
The Queensland Government uses a range of information and communications technology systems to process, store and transmit information. The Queensland Government is responsible for ensuring it applies adequate security for this information.
The Data encryption standard outlines the minimum requirements for encryption and management of encrypted, Queensland Government owned data (in use, in transit, and at rest). The Data encryption standard is enforced by the Information security policy (IS18:2018) requirement 3: Agencies must meet minimum security requirements, with all information transmitted over data communication networks secured in line with the Data encryption standard.
The Data encryption standard corresponds to the ISO/IEC 27001:2013 control domain of cryptography (A.10). Conformance with ISO 27001 requires consideration of the development and implementation of policies on cryptographic controls and a policy on cryptographic key management where appropriate.
- implement policy on the use of encryption, cryptographic controls, and key management
- implement controls at least equivalent to those outlined in the appendix A.1 “Required Controls” of the Data encryption standard
This standard provides a direction and processes for choosing and implementing encryption for data-in-transit, data-in-use, and data-at-rest. The standard also sets the minimum required standard for encryption of Queensland Government data.
The Data encryption standard is mandated through the Information security policy (IS18:2018). For further information on applicability see the Information security policy (IS18:2018).
By design, this standard does not provide specific guidance for handling national security information, classified material or systems that are assessed to have confidentiality requirements above PROTECTED. Where an agency has cause to handle such material/systems, it should refer to the Australian Government Protective Security Policy Framework (PSPF) and the Security and Counter-Terrorism Group in Queensland Police Service. Telephone 07 3364 4549 or email firstname.lastname@example.org.
For more details on information security classification, please refer to the Queensland Government Information Security Classification Framework (QGISCF).
The Data encryption standard is intended for use by:
- Network and security architects, project managers, information security professionals, and those responsible for Queensland Government data and information.
- Third-Party service providers developing or providing systems and services that will be storing and managing data/information on behalf of the Queensland Government.
Readers should be familiar with the concepts and workings of the QGISCF.
The Data encryption standard supersedes the Network Transmission Security Assurance Framework (NTSAF). References to the NTSAF in other QGEA documents should be taken to refer to the Data encryption standard.
Data can exist in various states or locations throughout its life-cycle. The following terms and definitions have been used within this document to describe the state or location of data:
- Data-at-rest: the stored location of data, be it on a storage device, server or other storage system.
- Data-in-transit: data that is currently being transmitted between locations.
- Data-in-use: data which is in use on a client device or session.
The Data encryption standard has been designed and written to replace the NTSAF. This document has changed from focusing primarily on the security of network transmission. It now covers the security of data and information in all its forms for the following reasons:
- to remove the minimum-security assurance levels applied to networking technologies encouraging agencies to independently risk assess technologies
- to focus the document to the topics of encryption, cryptography, and key management, removing extraneous topics
- to simplify implementation and understanding of the standard
- no other industry standards or frameworks require controls to the same detail as the NTSAF on the topic of network transmission security
- to provide clearer mapping to the ISO/IEC 27001:2013 control domains to assist with implementation of agency ISMS’s
- to align with the Australian Government’s minimum encryption control sets and support information sharing
- to expand the scope of the standard to incorporate data in its various states.
Overview of use
This standard is intended to be used to:
- assist agencies in developing and implementing policies on encryption, cryptographic controls, and key management
- determine appropriate encryption requirements considering the security classification of information and data
- ensure that the risk of data security being breached is effectively reduced through the appropriate implementation of cryptographic controls
- identifying acceptable configurations and supplementary controls which must or should be applied to cryptographic algorithms and protocols when being implemented.
Each of the above are explained in more detail in the following sections. Dot point 4 is further discussed in the control set sections “Cryptographic algorithms” and “Cryptographic protocols”.
Assist agencies in developing and implementing policies on encryption, cryptographic controls, and key management
In order to conform with ISO27001 requirements, agencies must consider and where appropriate develop and implement a policy on the use of cryptographic controls for the protection of information. The Data encryption standard enforces that agencies MUST Implement policy on the use of encryption, cryptographic controls, and key management. The Data encryption standard should be used as a basis for department and agency policies regarding encryption, cryptographic controls, and key management.
Iterating upon the minimum requirements and controls described in “control sets” to align with internal departmental requirements, should effectively fulfil the cryptography policy requirements of ISO27001. Agencies may also consider reviewing National Institute of Standards and Technology (NIST) SP800-53, ISO/IEC 27002, ISO/IEC 11700, The Australian Cyber Security Centre (ACSC) Information Security Manual (ISM) when developing their policies and supplemental controls.
Determine appropriate encryption requirements considering the security classification of data
The encryption requirements for data are determined by their confidentiality security classifications, assessed against the QGISCF. If the data does not have a security classification refer to the QGISCF for details on classification.
When considering the security classification of a system it is important to consider the highest level of confidentiality security classified information being processed. When processing PROTECTED information or data the cryptographic requirements greatly increase.
Agencies must consider the integrity requirements of the information/data/information system when implementing controls. The Data encryption standard only enforces minimum control sets based on the confidentiality classification, however encryption can also provide additional assurance when handling information/data/information systems with higher integrity requirements.
Where agencies are expected to align controls with the current ACSC ISM:
- ACSC ISM OFFICIAL (O) controls are applied to QGISCF classified information/data at the OFFICIAL and SENSITIVE levels
- ACSC ISM PROTECTED (P) controls are applied to QGISCF classified information/data at the PROTECTED levels.
Ensure the risk of data security being breached is effectively reduced through the appropriate implementation of cryptographic controls
Based on the security classifications derived from the QGISCF confidentiality assessment, agencies must
- implement the mandatory controls and requirements described in Control sets
- consider all recommended controls described with a should statement
- record the gaps where a mandatory or recommended control has not been implemented in the agency risk register.
Agencies should also:
- compare the mandatory requirements of the Data encryption standard against their currently implemented control sets to identify any control gaps in their existing systems
- develop and implement additional supplementary cryptographic controls where deemed necessary to provide a higher level of assurance or mitigate an existing risk
- keep a comprehensive identification of the controls that have been implemented in an auditable format and reviewed regularly through the ISMS process
- select the appropriate means of securing data with consideration of a range of factors including cost, ease of use, and appropriateness to the business.
Cryptography is the practice and study of techniques for secure communication in the presence of third parties, including adversaries. The application of cryptographic processes is designed to provide confidentiality, integrity, authentication, and non-repudiation of information and data.
Cryptography is used to encrypt information and data to provide additional assurances to their security. Organisations that use encryption for data at rest, or in transit, are not reducing the sensitivity or classification of the information. However, when information is encrypted, the consequences of the encrypted information being accessed by unauthorised parties is considered lower. This enables reduction in handling, storage and transmission requirements.
There are two key aspects of cryptography: the cryptographic algorithm, and the cryptographic protocol. The cryptographic algorithm is the mathematical means for concealing data and verifying integrity, whereas the cryptographic protocol is a transmission mechanism that applies additional security to data transmission using cryptography.
Cryptographic algorithms can be used to secure data during storage and, when used within an appropriate network protocol, can provide a trusted communications channel through un-trusted communication paths. A cryptographic algorithm creates a cipher by performing a set of mathematical functions using keys, which are then used to encrypt data.
There are several categories of cryptographic algorithms used for information security. The most widely adopted forms are asymmetric (AKA public-key), symmetric-key (AKA secret key), hash and key-hash message authentication code (HMAC) cryptography.
To ensure security, cryptographic algorithms that have been subjected to rigorous testing by cryptographers in the international community should be selected over lesser known algorithms.
The fundamental security principle for selecting cryptographic algorithms is to only use algorithms where the security is given through the computational difficulty of the algorithm. Cryptographic algorithms that rely on the secrecy of the algorithm itself to provide security are considered vulnerable to having their secret revealed, stolen or inadvertently discovered.
The strength of cryptographic algorithms is generally influenced by two factors. The first factor is the structure of the algorithm in providing computational complexity. The second is the length of the key fed into the algorithm to create the unique cipher. A longer key generally equates to a stronger cipher and requires an exponentially greater time to decipher. It should however be noted that equivalent key strengths can differ substantially between different types of algorithms.
Cryptographic strength is measured by the number of computing cycles required to decipher information. The length of time it takes to run the computing cycles has dramatically decreased as the speed of new processors has exponentially increased. In this way, advancements in computing power have rendered several once-strong algorithms obsolete, and new algorithms or key lengths continue to be required to maintain strength in the face of improving hardware capabilities.
Cryptographic algorithm requirements
When implementing cryptography or a cryptographic product the algorithm must have been reviewed by the Australian Government and currently have approval as an “ASD Approved Cryptographic Algorithm” (AACA) unless the associated risks are assessed, understood, and formally accepted at the departmental level.
AACAs fall into three categories: asymmetric/public key algorithms, hashing algorithms and symmetric encryption algorithms.
The currently approved asymmetric/public key algorithms are:
- Diffie-Hellman (DH) for agreeing on encryption session keys
- Digital Signature Algorithm (DSA) for digital signatures
- Elliptic Curve Diffie-Hellman (ECDH) for agreeing on encryption session keys
- Elliptic Curve Digital Signature algorithm (ECDSA) for digital signatures
- Rivest-Shamir-Adleman (RSA) for digital signatures and passing encryption session keys or similar keys
The approved hashing algorithm is:
- Secure Hashing Algorithm 2 (SHA-224, SHA-256, SHA-384 and SHA-512)
The approved symmetric encryption algorithms are:
- AES using key lengths of 128, 192 and 256 bits
- Triple Data Encryption Standard (3DES) using three distinct keys.
Where there is a range of possible key sizes for an algorithm, some of the smaller key sizes do not provide an adequate safety margin against intrusion methods that might be found in the future. For example, future advances in integer factorisation methods rendering smaller RSA moduli vulnerable to applicable attacks. If the information to be secured is expected retain high confidentiality requirements over a long periods (e.g decades), this should be taken into account.
ASD approved cryptographic algorithms 2018 [Official and Protected*]**
Minimum Key Strengths
160+ bits field/key size
SHA-224, SHA-256, SHA-384 and SHA-512
128, 192 and 256 bits
Triple Data Encryption Standard (3DES)
3 Distinct Keys
Table 1: ASD approved cryptographic algorithms requirements
* See appendix B for mapping to QGISCF classified information
** This list is current as of December 2018, refer to the ACSC ISM for the current list of AACAs and supplementary controls in this section.
When using AACAs agencies must ensure the implementation is aligned with the associated controls in the current ACSC ISM.
Agencies should use ECDH and ECDSA in preference to DH and DSA due to an increase in successful sub-exponential index-calculus based attacks on DH and DSA. ECDH and ECDSA offer more security per bit increase in key size than either DH or DSA and are considered more secure alternatives.
When using elliptic curve cryptography, agencies must use a curve from the USA Federal Information Processing Standard 186-4 (FIPS 186-4).
When using RSA for digital signatures, and for passing encryption session keys or similar keys, a key pair for passing encrypted session keys that is different from the key pair used for digital signatures must be used.
AES and 3DES must not use Electronic Codebook (ECB) mode. Electronic Codebook (ECB) mode in block ciphers allows repeated patterns in plaintext to appear as repeated patterns in the ciphertext.
Correctly implementing cryptographic protocols is the primary way to protect against network-based attacks and provide encryption-in-transit.
Although many cryptographic protocols use strong standards-based cryptographic algorithms, they may still be vulnerable to weaknesses in the protocol structure or weakness in the implementation. Like cryptographic algorithms, the most secure protocols are typically based on mature industry standards as they have undergone international scrutiny to ensure there are minimal vulnerabilities. It is more likely that lesser known cryptographic protocols will contain vulnerabilities that could potentially be exploited.
Many secure protocols rely on digital certificate technology to provide entity authentication. Digital certificates are created using a combination of public-key and cryptographic hash algorithms, and their security relies on a trust-based infrastructure model known as public key infrastructure (PKI). The most commonly used digital certificate standard is X.509 and this is considered the industry default.
Guidelines for establishing a PKI based on digital certificates are out of the scope of the Data encryption standard.
Transmission networks consist of many protocol layers working together to ensure that information is delivered to its intended recipient and in an appropriate way, based on the type of information. There are many cryptographic protocols that operate at different layers of granularity based on how information is secured for transmission.
Cryptographic protocol requirements
The Data encryption standard is aligned with the ACSC ISM and where appropriate recommends the use of ASD Approved Cryptographic Protocols (AACP), the current ASD Approved Cryptographic Protocols are:
- Transport Layer Security (TLS)
- Secure Shell (SSH)
- Secure Multipurpose Internet Mail Extension (S/MIME)
- OpenPGP Message Format
- Internet Protocol Security (IPsec)
- Wi-Fi Protected Access 2 (WPA2).
When implementing AACPs agencies must ensure the implementation is aligned with the associated controls in the current ACSC ISM (this includes cryptographic protocol versioning). Cryptographic Protocol implementation must align to the QGISCF confidentiality classification of the information being transmitted and required controls can be found in the ASD Approved Cryptographic Protocols section of the Cryptography chapter in the current ACSC ISM.
Agencies should establish and maintain end-to-end encryption for all applications, and where an agency does not have physical control over the network infrastructure used for transmission data should be encrypted by default.
Encryption at rest
Encryption at rest (or data-at-rest) is the result of encrypting data that is not considered ‘moving’ (i.e not being transmitted). Data-at-rest includes data that resides in databases, file systems, hard drives, USB keys, memory, and any other structured storage method. There are different methods to implement encryption at rest, the primary methods include full disk encryption, partial disk encryption, and file-based encryption. Encryption of data at rest can be used to reduce the physical storage and handling requirements for media or systems containing sensitive information.
When implementing encryption at rest, full disk encryption is the preferred implementation method. Full disk encryption provides a greater level of protection than file-based encryption. File-based encryption can be used to encrypt individual files, however there is the possibility of temporary copies remaining on the device in an un-encrypted form.
Partial disk encryption can also be used to ensure specifically sensitive data can be stored in a secured manner. Partial disk encryption can be implemented by partitioning the storage in a device or database and encrypting a specific partition(s). Partial disk encryption must be accompanied with appropriate access control that will only allow writing to the encrypted partition.
Encryption at rest can be implemented to protect files and data from external attackers and malicious insiders. If encryption at rest is implemented appropriately alongside access control measures it should mitigate the likelihood of inappropriate access to information and reduce the impact of data theft.
Encryption at rest requirements
There are legitimate reasons why information owners choose not to encrypt data at rest including:
- difficulties in recovery of any corrupted data, especially if there is cipher block chaining.
- conflict with compression algorithms.
- environmental – increased use of CPU cycles to undertake tasks.
Following an assessment of risk Queensland Government agencies should, where possible, implement full disk encryption to protect data at rest and reduce the impact of device theft and data leakage.
In all other cases, encryption at rest may be implemented with a business owners' approval to mitigate an existing risk or reduce the physical storage and handling requirements of the data/information.
Cryptographic systems are comprised of equipment and keying material. Keying material is the data (e.g., keys and initialisation vectors) necessary to establish and maintain cryptographic keying relationship. Keying material is either symmetric or asymmetric in nature, although there are several different types of keys defined. Keys can be identified according to their classifications as public (asymmetric), private (asymmetric), symmetric, and relating to their use, for more information regarding types of keys see NIST SP 800-57 Pt. 1 section 5.1.1.
Cryptographic equipment is the aspect of the cryptographic system that allows the users to encrypt and decrypt data/information while keyed. While cryptographic equipment is usually a physical device it can be a part of encryption software.
Key management is susceptible to several threats and vulnerabilities. These can have significant affects to the confidentiality or integrity of the encrypted information, some of these threats and vulnerabilities include:
- disclosure of the keying material: Either the keying material is in plain text, is not protected and can be accessed, or is enciphered and can be deciphered.
- modification of keying material: Changing the keying material so that it does not operate as intended.
- unauthorised deletion of keying material: Removal of the key or key related data.
- Incomplete destruction of keying material: This may lead to the compromise of current or future keys.
- unauthorised revocation: The direct or indirect removal of a valid key or keying material.
- masquerade: The impersonation of an authorised user or entity.
- delay in executing key management functions: This may result in a failure to generate, distribute, revoke or register a key, update the key repository in a timely manner, maintain a user’s authorisation levels, and so on. The delay threat may result from any of the previously mentioned threats or from physical failure of the key related equipment.
- misuse of keys: The use of a key for a purpose for which it is not authorised, excessive use of a key, provision of keys to an unauthorised recipient, and the use of a key management facility for a purpose which it is not authorised.
Key management requirements
An agency policy on the use, protection and lifetime of cryptographic keys must be developed and implemented through their whole lifecycle. Agencies must develop their key management policies to comply with the ACSC ISM key management requirements and ISO27002:2015.
ISO27002:2015 and the ACSC ISM both require the implementation of a key management plan that must include an agreed set of standards, procedures and secure methods the following topics:
- generating keys for different cryptographic systems and different applications
- issuing and obtaining public key certificates
- distributing keys to intended entities, including how keys should be activated when received
- storing keys, including how authorised users obtain access to keys
- changing or updating keys including rules on when keys should be changed and how this will be done
- dealing with compromised keys
- revoking keys including how keys should be withdrawn or deactivated, e.g. when keys have been compromised or when a user leaves an organisation (in which case keys should also be archived)
- recovering keys that are lost or corrupted
- backing up or archiving keys
- destroying keys
- logging and auditing of key management related activities.
When utilising a third party for the storage and/or transmission of information deemed to require encryption Agencies should where possible, appropriate, and economic seek to control the encryption keys.
When developing key management policies and plans, agencies should review ISO/IEC 27002:2015, AS11770-1, ACSC ISM, NIST SP 800-57, and FIPS 140-2. These industry standards provide a holistic view of key management and offer minimum control sets.
Australian Government information security
Australian Government Protective Security Policy Framework
Appendix A Required controls
|Policy||Implement policies on the use of encryption, cryptographic controls, and key management||Must|
|Implement controls at least equivalent to those outlined in the Data encryption standard||Must|
|Any required control with a “should” or “must” statement that is not implemented must be recorded in the agency risk register||Must|
|Algorithm||When implementing cryptography or a cryptographic product the algorithm must have approval as an AACA, unless the risk is formally accepted by the agency accountable officer (i.e. Director-General or equivalent executive delegate)||Must|
|Agencies must ensure the implementation of AACAs is aligned with the associated controls in the current ACSC ISM||Must|
|ECDH and ESDSA should be used in preference to DH and DSA||Should|
|Elliptic curve cryptography must use a curve from the FIPS 186-4||Must|
|RSA must use a key pair for passing encrypted session keys that is different from the key pair used for digital signatures||Must|
|AES and 3DES must not use Electronic Codebook (ECB) mode||Must|
|Protocols||Where an agency does not have physical control over the network infrastructure used for transmission by default data should be encrypted||Should|
|Where appropriate agencies should use ASD Approved Cryptographic Protocols (AACP)||Should|
|When implementing AACPs agencies must ensure the implementation is aligned with the associated controls in the current ACSC ISM||Must|
|Protocol implementation must align to the confidentiality classification of the information being transmitted||Must|
|At-rest||Where possible full disk encryption at rest should be implemented||Should|
|Partial disk encryption must be accompanied with appropriate access control||Must|
|Key management||Policy on the use, protection and lifetime of cryptographic keys must be developed and implemented through their whole lifecycle||Must|
|Agencies must develop their key management policies to comply with the ISM key management requirements and ISO27002:2015||Must|
|Agencies should control encryption keys when storing and/or transmitting information deemed to require encryption on a third-party system||Should|
|Agencies must implement a key management plan includes an agreed set of standards, procedures and secure methods for the listed topics in section 4.1.4||Must|
Appendix B Control classification mapping
Information Security Manual 2017
Information Security Manual
UD: Baseline controls
O: Official controls
P: Protected controls
P: Protected controls
Depending on risk assessment