Data encryption standard

Document type:

Standard

Version:

Final v2.0.0

Status:

CurrentMandated

Owner:

CDSB

Effective:

March 2025–current

Security classification:

OFFICIAL-Public

Category:

Cyber security

Introduction

This Data encryption standard (DES) supports the Queensland Government Information and cyber security policy (IS18). It is mandated under the IS18 Policy Requirement 3 as part of meeting minimum information security requirements and supports conformance to ISO27001:2022 (A.8.24).

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 this information is appropriately secured.

The DES outlines the minimum requirements for cryptography and the use of encryption to protect data that is owned by or entrusted to the Queensland Government. Alignment with or adoption of the DES by agencies will assist alignment with ISO27002:2022 section 8.2.4 requiring a topic-specific policy for cryptography.

The DES closely aligns to the Australian Signals Directorate (ASD) Information Security Manual’s (ISM) Guidelines for cryptography, Guidelines for system hardening and Guidelines for networking and should be used in conjunction with the Queensland Government’s cyber security suite of mandatory policies including Information and cyber security policy (IS18), Information security classification framework (QGISCF) and the Queensland Government authentication framework (QGAF).

Background

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 appropriately encrypted, the likelihood of the encrypted information being accessed by unauthorised parties is considered to be lower. This enables a reduction in handling, storage and transmission requirements.

This document 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
• to provide clearer mapping to the ISO/IEC 27001:2022 control domains to assist with implementation of agency Information Security Management Systems’ (ISMS)
• 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.

Scope

This standard provides a direction and processes for choosing and implementing encryption for data in transit and data at rest. The standard also sets the minimum required standard for encryption of Queensland Government data.

The DES 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)
• the Australian Government Information Security Manual (ISM).

Further information and advice is also available from the Queensland Police Service’s Agency Security Advisor, via email qsctc.secretariat@police.qld.gov.au.

This document may contribute to controls required for applicable entities to meet Payment Card Industry Data Security Standard (PCI DSS) requirements, it does not cover all scenarios or controls required for PCI DSS compliance, entities should satisfy themselves, and their auditors that all applicable controls are implemented.

Out of Scope

Guidelines for establishing a Public Key Infrastructure (PKI) based on digital certificates are out of the scope of the DES.

Audience

The DES is intended for use by:

• network and security architects, system administrators, 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 and information on behalf of the Queensland Government.

Conventions

This standard adopts the following conventions, as specified in RFC2119:

• MUST indicates a core requirement of this standard that is mandatory under IS18
• SHALL indicates an item that is recommended to be mandatory in entities internal encryption policies
• SHOULD indicates something that is recommended to be included in entities internal encryption policies
• MAY indicates something that is permitted under this framework but is not required
• SHOULD NOT indicates something that is not recommended under this framework, unless circumstances make other approaches unfeasible
• SHALL NOT indicates something that is recommended to be not permitted in entities internal encryption policies.

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.

External references

This document references several external documents, while it is intended that the content within this standard will be updated regularly, it is likely it will be out of phase with some references. Where a requirement references an external document which has been updated (potentially at a different location), the agency may substitute the intent of the updated document for written requirement.

The following references were used to inform this standard:

• Australian Government Using the Information security manual
• ISO 27001:2022 /27002:2022
• ISO 11770
• National Institute of Standards and Technology (NIST) Security and Privacy Controls for Information Systems and Organisations SP 800-53
• National Institute of Standards and Technology (NIST) Key Management SP 800-57

Overview

This standard is to be used to:

• provide agencies with rules and guidelines in developing 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
• identify acceptable configurations and supplementary controls which must or should be applied to cryptographic algorithms and protocols when being implemented
• inform solution architecture and design activities on the appropriate use of encryption.

Policy requirements

Agencies MUST:

• implement policy, processes and procedures on the use of encryption, cryptographic controls, and key management, using implementation section of this document as a starting point [ISM-0507]
• risk assess and record any gaps where a control specified in implementation section has not been implemented in the agency risk register or documented risk control suite.

Agencies SHOULD:

• compare the mandatory requirements of the DES 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
• establish and maintain end-to-end encryption for all applications and systems and where this is not viable ensure data is encrypted when transmitted over network infrastructure which the agency does not have physical control over.

Risk considerations

This standard is intended to control the following risk events, which SHOULD be considered for the purposes of any risk assessment considering non-adherence to this standard:

• business impact as a result of loss of confidentiality due to network traffic being intercepted by an interested party
• business impact as a result of loss of confidentiality due to the loss or inappropriate access of a data storage device
• business impact as a result of loss of non-repudiation of material that is relied on as coming from an authorised source
• business impact as a result of loss of integrity of systems/information due to tampering enabled by compromised authentication processes due to broken cryptographic controls.

When implementing cryptographic controls, agencies should also consider operational risks such as:

• loss of integrity of information due to transfer errors between parties
• loss of availability of information resulting from inability to decrypt previously encrypted information
• loss of availability of systems resulting from expired certificates.

Implementation

Define agency policies on encryption, cryptographic controls, and key management

Agencies SHALL develop and implement a policy on the use of encryption, cryptographic controls, and key management for the protection of information. The DES should be adopted or used as a basis for department and agency policies regarding encryption, cryptographic controls, and key management.

Agencies MAY also consider reviewing the National Institute of Standards and Technology (NIST) SP800-53 and SP800-57, ISO/IEC 27002:2022, ISO/IEC 11770:2021, and the Australian Cyber Security Centre’s (ACSC) Information Security Manual (ISM) when developing their policies and supplemental controls.

Determine appropriate encryption requirements

The encryption requirements for data are determined by their Business Impact Level across confidentiality, integrity and availability, as assessed against the QGISCF. If 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 account for the highest level of security classified information being processed.

Agencies SHALL consider the integrity requirements of the information, data and information system when implementing controls. The DES only enforces minimum control sets based on the confidentiality classification; however, encryption can also provide additional assurance when handling information, data and information systems with higher integrity requirements.

Note: As of the ISM update (September 2024), the encryption standards outlined for encrypting government information, whether classified as OFFICIAL: Sensitive, or PROTECTED, are identical. This supports standardisation of control requirements which is aimed at simplifying implementation and compliance by adopting a consistent set of encryption practices across various levels of information sensitivity, ensuring a streamlined approach to the protection of data.

Encryption of data in transit

Data in transit (data being transferred from computer to computer), includes data being transferred from client to server, server to client, server to server, and in some cases client to client. Data in transit, particularly in public networks, is exposed to the risks of interception, sniffing and tampering. Encrypting this traffic helps to ensure its confidentiality and integrity.  In consideration of the principles of zero trust, the location of the endpoints SHOULD NOT be used as a consideration for not enabling encryption of network traffic.

Encryption in transit requirements

All network traffic SHALL be encrypted using ASD Approved Cryptographic Protocols [ISM-0469] where possible.

Use of unencrypted protocols SHALL be avoided where possible, noting that some unencrypted traffic is unavoidable (such as DHCP, ARP, DNS) or required for establishing encrypted sessions (such as SMTP Opportunistic Encryption).

Common Criteria evaluated cryptographic hardware or software SHOULD be used when encrypting network traffic containing SENSITIVE or PROTECTED information for transit over public or insufficiently secure networks. [ISM-0465].

Additional care SHALL be taken to ensure that authentication traffic, such as LDAP, is encrypted using appropriate methods (as per this document).

Use of HTTPS

Given the pervasive nature of web application traffic and the risks of session interception and redirection, potentially exposing users to malicious content from apparently trustworthy sources it is necessary to ensure that all web traffic is protected in transit.

HTTPS SHALL be used for all web site and web application traffic [ISM-1552].

HTTP services, without TLS, SHALL only be used to redirect users to a HTTPS service [ISM-1552].

All web sites, services and applications SHALL be covered by a Strict Transport Security policy, covering the hostname or a parent domain which includes subdomains [ISM-1424].

Encryption of data at rest

Data at rest is data that is not considered ‘moving’ (i.e. not being transmitted over a network or actively used in memory). Data at rest includes data that resides in databases, file systems, hard drives, USB keys, memory, and any other structured storage method.

Encrypting data at rest provides several advantages:

• reduces the risk of information confidentiality loss if the device is accessed by an unauthorised party
• simplifies and speeds data destruction as the information can be rendered effectively erased simply by destroying the encryption key [Note: this is not sufficient for SECRET or above classified information].

Note, however that encryption of data at rest (particularly full disk encryption) does not protect against application-level attacks or attacks which access the operating system while the encryption is unlocked.

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, however this only applies while the encryption is in place and ceases while the encryption key is in memory.

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 unencrypted 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 SHALL be accompanied with appropriate access control that prevents sensitive information being written to unencrypted locations to limit accidental leakage.

Note: Full disk encryption is primarily effective in protecting data in case a device is lost or stolen. However, it may not safeguard against unauthorised access resulting from a compromised user account on that system. If encryption-based protection against such breaches is required, consideration of other approaches, such as user-based encryption, will be required. These are designed to secure data of other users if another (non-admin) account on the machine is compromised.

Encryption at rest requirements

There are legitimate reasons why information owners choose not to encrypt data at rest including:

• difficulties in the recovery of any corrupted data (especially if cipher block chaining is used)
• conflict with compression algorithms
• environmental – increased use of CPU cycles to undertake tasks
• implementation/management complexity.

Agencies SHOULD implement full disk encryption on internal storage of devices that exist/travel outside of secure facilities and any removeable media to protect data at rest and reduce the impact of device theft.

Agencies SHOULD implement full disk encryption on internal storage to protect data at rest and reduce the impact of device theft [ISM-0869] [ISM-1059].

Agencies SHALL implement encryption for backups when stored outside an agencies physical premises.

Agencies SHOULD implement encryption for backups when stored on their physical premises.

Common Criteria evaluated cryptographic hardware or software SHALL be used when encrypting media containing SENSITIVE or PROTECTED information [ISM-0457].

To prevent data inadvertently leaving an encrypted storage area where partial disk encryption is used agencies SHALL, use access controls to limit write access to encrypted areas [ISM-0459].

Key management

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.

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 plaintext, 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.

When developing key management policies and plans, agencies MAY want to consider:

• AS11770-1
• ACSC ISM
• NIST SP 800-57
• FIPS 140-2.

These industry standards provide a holistic view of key management and offer guidance on control sets.

Key management requirements

An agency policy on the use, protection and lifetime of cryptographic keys SHALL be developed and implemented through their whole lifecycle. Agencies SHALL develop their key management policies to comply with the ACSC ISM key management requirements and consider guidance from ISO27002:2022.

A key management plan SHALL include an agreed set of standards, procedures and secure methods covering the following topics:

• generating keys for different cryptographic systems and different applications
• issuing and obtaining public key certificates
• Segregation of duties (e.g. Key Custodian/Registration Authority) to maintain integrity of the key handling processes
• 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 [ISM-1091]
• 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) [ISM-1091]
• recovering keys that are lost or corrupted
• backing up or archiving keys [ISM-0455]
• 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.

Keys used for encryption SHALL be handled according to the classification of the (unencrypted) data that they are used to protect, or higher and stored with either a suitable passphrase or appropriate access controls.

Control sets

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

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 untrusted 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 (public key), symmetric (shared secret key), hash and key-hash message authentication code (HMAC) cryptography.

To maximise efficacy of the cryptographic control and increase trust in the algorithm, those 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 SHALL have been reviewed by the Australian Government and currently have approval as an “ASD Approved Cryptographic Algorithm” (AACA) [ISM-0471, ISM-1080] 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.

ASD approved cryptographic algorithms 2024 *
Family	Algorithms	Approved purpose	Minimum requirements
Asymmetric / public key	Diffie-Hellman (DH)	Agreeing session keys	2048+ Modulus (3072+ preferred) [ISM-0472] ECDH SHOULD be used in preference to DH [ISM-0994]
	Elliptic Curve Diffie-Hellman (ECDH)	Agreeing session keys	224+ bits field/key size [ISM-0475] [ISM-0474] NIST Curve P-384 SHOULD be used [ISM-1446]
	Elliptic Curve Digital Signature algorithm (ECDSA)	Digital signatures
	Rivest-Shamir-Adleman (RSA)	Digital signatures	2048+ Modulus (3072+ preferred) [ISM-0476]
Hash	Secure Hashing Algorithm 2 (SHA-2)	Passing session keys	SHA-224, SHA-256, preferably SHA-384 or SHA-512 [ISM-1766]
Symmetric encryption	Advanced Encryption Standard (AES)	Hashing	128, 192 or preferably 256 bits [ISM-1769]

Table 1: ASD approved cryptographic algorithms requirements

* This list is current as of September 2024, refer to the ACSC ISM for the current list of AACAs and supplementary controls in this section.

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 period (e.g. decades), this should be considered.

When using AACAs agencies SHALL 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 (which is no longer an approved algorithm). 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 SHALL use a curve from the USA Federal Information Processing Standard 186-4 (FIPS 186-4), with preference for curve NIST P-384.

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 SHALL be used. [ISM-0477].

AES SHALL not be configured to use Electronic Codebook (ECB) mode [ISM-0479]. Electronic Codebook (ECB) mode in block ciphers allows repeated patterns in plaintext to appear as repeated patterns in the ciphertext, making cryptoanalysis trivial.

Cryptographic protocols

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 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 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 PKI. The most used digital certificate standard is X.509 and this is considered the industry default. There are many cryptographic protocols that operate at different layers of granularity based on how information is secured for transmission.

The DES is aligned with the ACSC ISM and where appropriate recommends the use of AACP [ISM-0481], the current ASD AACP 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)
• Wi-Fi Protected Access 3 (WPA3).

When implementing AACPs agencies shall ensure the implementation is aligned with the associated controls in the current ACSC ISM (this includes cryptographic protocol versioning), noting that the required configuration may vary based on the QGISCF classification.

Factsheets for the secure configuration of TLS, SSH, Wi-Fi and IPSec are available, see Appendix A and B at the end of this document.

Planning for post quantum cryptography

Most current cryptographic algorithms are not considered to be secure against attacks from quantum computers once they reach sufficient capacity. Given the potential security threats introduced by the advent of a quantum computer powerful enough for cryptographic purposes, it's recommended that agencies be proactive in foreseeing future needs and dependencies of systems at risk.

Agencies SHOULD monitor advancements in quantum-resistant algorithms and quantum computing capabilities and plan for the transition to post-quantum cryptographic standards [ISM-1917].

Further advice on Planning for post-quantum cryptography is available from ACSC.