Cryptographic fundamentals
Purpose of cryptography
The purpose of cryptography is to provide confidentiality, integrity, authentication and non-repudiation of data. In doing so, confidentiality protects data by making it unreadable to all but authorised entities, integrity protects data from accidental or deliberate manipulation by entities, authentication ensures that an entity is who they claim to be, and non-repudiation provides proof that an entity performed a particular action.
Using encryption
Encryption of data at rest can be used to protect sensitive or classified data stored on ICT equipment and media. In addition, encryption of data in transit can be used to protect sensitive or classified data communicated over public network infrastructure. However, when an organisation uses encryption for data at rest, or data in transit, they are not reducing the sensitivity or classification of the data, they are simply reducing the immediate consequences of the data being accessed by malicious actors.
International standards for cryptographic modules
International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 19790:2012, Information technology – Security techniques – Security requirements for cryptographic modules, and ISO/IEC 24759:2017, Information technology – Security techniques – Test requirements for cryptographic modules, are international standards for the design and validation of hardware and software cryptographic modules.
Federal Information Processing Standard (FIPS) 140-3, Security Requirements for Cryptographic Modules and National Institute of Standards and Technology (NIST) Special Publication (SP) 180-140, FIPS 140-3 Derived Test Requirements (DTR): CMVP Validation Authority Updates to ISO/IEC 24759 are United States standards based upon ISO/IEC 19790:2012 and ISO/IEC 24759:2017.
Communications security doctrine
The Australian Signals Directorate (ASD) specifies additional communications security requirements in Australian Communications Security Instructions that must be complied with when operating High Assurance Cryptographic Equipment (HACE). Such requirements supplement these guidelines and, where conflicts occur, take precedence.
Control: ISM-0499; Revision: 11; Updated: Sep-23; Applicability: S, TS; Essential Eight: N/A
Communications security doctrine produced by ASD for the management and operation of HACE is complied with.
Approved High Assurance Cryptographic Equipment
In order to ensure interoperability and maintain trust, all HACE must be issued an Approval for Use by ASD and be operated in accordance with the latest version of their associated Australian Communications Security Instructions.
Control: ISM-1802; Revision: 1; Updated: Sep-23; Applicability: S, TS; Essential Eight: N/A
HACE are issued an Approval for Use by ASD and operated in accordance with the latest version of their associated Australian Communications Security Instructions.
Cryptographic key management processes and procedures
Well documented cryptographic key management processes and procedures can assist with the secure use and management of cryptographic keys and associated hardware and software. In doing so, cryptographic key management processes and procedures should cover cryptographic key generation, registration, distribution, installation, usage, protection, storage, access, recovery and destruction.
Control: ISM-0507; Revision: 5; Updated: Dec-22; Applicability: All; Essential Eight: N/A
Cryptographic key management processes, and supporting cryptographic key management procedures, are developed, implemented and maintained.
Encrypting data at rest
When encryption is applied to data at rest it provides an additional layer of defence against unauthorised access by malicious actors. In doing so, it is important that full disk encryption is used as it provides a greater level of protection than file-based encryption. This is due to the fact that while file-based encryption may encrypt individual files, there is the possibility that unencrypted copies of files may be left in temporary locations used by an operating system. When selecting cryptographic equipment or software for this purpose, the level of assurance required will depend on the sensitivity or classification of the data.
Control: ISM-1080; Revision: 5; Updated: Jun-22; Applicability: All; Essential Eight: N/A
An ASD-Approved Cryptographic Algorithm (AACA) or high assurance cryptographic algorithm is used when encrypting media.
Control: ISM-0457; Revision: 9; Updated: Mar-22; Applicability: OS, P; Essential Eight: N/A
Cryptographic equipment or software that has completed a Common Criteria evaluation against a Protection Profile is used when encrypting media that contains OFFICIAL: Sensitive or PROTECTED data.
Control: ISM-0460; Revision: 13; Updated: Sep-23; Applicability: S, TS; Essential Eight: N/A
HACE is used when encrypting media that contains SECRET or TOP SECRET data.
Control: ISM-0459; Revision: 4; Updated: Dec-21; Applicability: All; Essential Eight: N/A
Full disk encryption, or partial encryption where access controls will only allow writing to the encrypted partition, is implemented when encrypting data at rest.
Encrypting data in transit
When data is communicated over network infrastructure, encryption should be used to protect the data from unauthorised access or manipulation. When selecting cryptographic equipment or software for this purpose, the level of assurance required will depend on the sensitivity or classification of the data and the environment in which it is being applied.
Control: ISM-0469; Revision: 6; Updated: Jun-22; Applicability: All; Essential Eight: N/A
An ASD-Approved Cryptographic Protocol (AACP) or high assurance cryptographic protocol is used to protect data when communicated over network infrastructure.
Control: ISM-0465; Revision: 9; Updated: Mar-22; Applicability: OS, P; Essential Eight: N/A
Cryptographic equipment or software that has completed a Common Criteria evaluation against a Protection Profile is used to protect OFFICIAL: Sensitive or PROTECTED data when communicated over insufficiently secure networks, outside of appropriately secure areas or via public network infrastructure.
Control: ISM-0467; Revision: 12; Updated: Sep-23; Applicability: S, TS; Essential Eight: N/A
HACE is used to protect SECRET and TOP SECRET data when communicated over insufficiently secure networks, outside of appropriately secure areas or via public network infrastructure.
Data recovery
To ensure that access to encrypted data is not lost due to the loss, damage or failure of an encryption key, it is important that where practical cryptographic equipment and software provides a means of data recovery.
Control: ISM-0455; Revision: 3; Updated: Mar-22; Applicability: All; Essential Eight: N/A
Where practical, cryptographic equipment and software provides a means of data recovery to allow for circumstances where the encryption key is unavailable due to loss, damage or failure.
Handling encrypted ICT equipment and media
When a user authenticates to the encryption functionality of ICT equipment or media, encrypted data is made available. At such a time, the ICT equipment or media should be handled according to its original sensitivity or classification. Once the user deauthenticates from the encryption functionality, such as shutting down a device or activating a lock screen, the ICT equipment or media can be considered to be protected by the encryption functionality again.
Control: ISM-0462; Revision: 7; Updated: Mar-22; Applicability: All; Essential Eight: N/A
When a user authenticates to the encryption functionality of ICT equipment or media, it is treated in accordance with its original sensitivity or classification until the user deauthenticates from the encryption functionality.
Transporting cryptographic equipment
Transporting cryptographic equipment in a keyed state may expose its keying material to potential compromise. Therefore, if cryptographic equipment is transported in a keyed state it should be done based on the sensitivity or classification of its keying material.
Control: ISM-0501; Revision: 6; Updated: Mar-22; Applicability: All; Essential Eight: N/A
Keyed cryptographic equipment is transported based on the sensitivity or classification of its keying material.
Reporting cryptographic-related cyber security incidents
If cryptographic equipment or associated keying material is compromised, or suspected of being compromised, then the confidentiality and integrity of previous and future communications may also be compromised. In such cases, the cyber security incident should be reported to the Chief Information Security Officer, or one of their delegates, as soon as possible after it occurs and all keying material should be changed.
Control: ISM-0142; Revision: 5; Updated: Jun-23; Applicability: All; Essential Eight: N/A
The compromise or suspected compromise of cryptographic equipment or associated keying material is reported to the Chief Information Security Officer, or one of their delegates, as soon as possible after it occurs.
Control: ISM-1091; Revision: 6; Updated: Dec-21; Applicability: All; Essential Eight: N/A
Keying material is changed when compromised or suspected of being compromised.
Further information
Further information on cryptographic key management practices can be found in NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: Part 1 – General.
Further information on cryptographic key management practices for HACE is available from ASD.
Further information on cyber supply chain risk management can be found in the cyber supply chain risk management section of the Guidelines for Procurement and Outsourcing.
Further information on evaluated products can be found in the evaluated product procurement section of the Guidelines for Evaluated Products.
Further information on the evaluation of cryptographic modules, including testing requirements, is available as part of the Cryptographic Module Validation Program which is jointly operated by NIST and the Canadian Centre for Cyber Security.
Further information on the protection of ICT equipment and media can be found in the Department of Home Affairs’ Protective Security Policy Framework, Physical security for entity resources policy.
ASD-Approved Cryptographic Algorithms
High assurance cryptographic algorithms
High assurance cryptographic algorithms, which are not covered in this section, can be used for the protection of SECRET and TOP SECRET data if they are suitably implemented in HACE. Further information on high assurance cryptographic algorithms can be obtained from ASD.
ASD-Approved Cryptographic Algorithms
There is no guarantee of an algorithm’s resistance to currently unknown attacks. However, the algorithms listed in this section have been extensively scrutinised by industry and academic communities in a practical and theoretical setting. Approval for the use of the algorithms listed in this section is limited to cases where they are implemented in accordance with these guidelines.
The 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 key exchange
- 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 only approved hashing algorithm is Secure Hashing Algorithm 2 (SHA-2).
The only approved symmetric encryption algorithm is Advanced Encryption Standard (AES).
Where there is a range of key sizes for an algorithm, some of the smaller key sizes are not approved as they do not provide an adequate safety margin against possible future attacks. For example, advances in integer factorisation methods could render smaller RSA moduli vulnerable.
The targets used for the effective security strength of algorithms listed within this section are 112 bits for PROTECTED and below data, 128 bits for SECRET data and 192 bits for TOP SECRET data. However, some key sizes and curves are preferred in order to ensure interoperability with the United States’ initial Commercial National Security Algorithm Suite (now referred to as CNSA 1.0).
Using ASD-Approved Cryptographic Algorithms
If cryptographic equipment or software implements unapproved algorithms, it is possible that these algorithms could be used without a user’s knowledge. In combination with an assumed level of security confidence, this can represent a security risk. As such, an organisation can ensure that only AACAs or high assurance cryptographic algorithms can be used by disabling all unapproved algorithms (preferred) or by advising users not to use the unapproved algorithms via usage policies.
Control: ISM-0471; Revision: 7; Updated: Dec-21; Applicability: All; Essential Eight: N/A
Only AACAs or high assurance cryptographic algorithms are used by cryptographic equipment and software.
Asymmetric/public key algorithms
DH and DSA are vulnerable to different types of attacks than ECDH and ECDSA. As a result, ECDH and ECDSA offer more effective security per bit increase. This leads to smaller data requirements which in turn means that elliptic curve variants have become de facto global standards. For reduced data cost, and to promote interoperability, ECDH and ECDSA should be used where possible.
Control: ISM-0994; Revision: 6; Updated: Dec-21; Applicability: All; Essential Eight: N/A
ECDH and ECDSA are used in preference to DH and DSA.
Using Diffie-Hellman
A modulus of 2048 bits for correctly implemented DH provides 112 bits of effective security strength. Taking into account projected technological advances, it is assessed that 112 bits of effective security strength will remain secure until 2030.
When DH in a prime field is used, the prime modulus impacts the security of the algorithm. The security considerations when creating such a prime modulus can be found in NIST SP 800-56A Rev. 3, along with a collection of commonly used secure moduli.
Control: ISM-0472; Revision: 6; Updated: Mar-22; Applicability: OS, P; Essential Eight: N/A
When using DH for agreeing on encryption session keys, a modulus of at least 2048 bits is used, preferably 3072 bits.
Control: ISM-1759; Revision: 0; Updated: Mar-22; Applicability: S, TS; Essential Eight: N/A
When using DH for agreeing on encryption session keys, a modulus of at least 3072 bits is used, preferably 3072 bits.
Control: ISM-1629; Revision: 1; Updated: Dec-21; Applicability: All; Essential Eight: N/A
When using DH for agreeing on encryption session keys, a modulus and associated parameters are selected according to NIST SP 800-56A Rev. 3.
Using the Digital Signature Algorithm
A modulus of 2048 bits for correctly implemented DSA provides 112 bits of effective security strength. Taking into account projected technological advances, it is assessed that 112 bits of effective security strength will remain secure until 2030.
Control: ISM-0473; Revision: 5; Updated: Dec-20; Applicability: OS, P; Essential Eight: N/A
When using DSA for digital signatures, a modulus of at least 2048 bits is used.
Control: ISM-1630; Revision: 2; Updated: Mar-22; Applicability: OS, P; Essential Eight: N/A
When using DSA for digital signatures, a modulus and associated parameters are generated according to FIPS 186-4.
Control: ISM-1760; Revision: 0; Updated: Mar-22; Applicability: S, TS; Essential Eight: N/A
DSA is not used for digital signatures.
Using Elliptic Curve Cryptography
The curve used within an elliptic curve algorithm impacts the security of the algorithm. As such, only suitable curves from FIPS 186-4 should be used.
Control: ISM-1446; Revision: 2; Updated: Dec-21; Applicability: All; Essential Eight: N/A
When using elliptic curve cryptography, a curve from FIPS 186-4 is used.
Using Elliptic Curve Diffie-Hellman
When using a curve from FIPS 186-4, a base point order and key size of at least 224 bits for correctly implemented ECDH provides 112 bits of effective security strength. Security of a curve selected from another source cannot be assumed to have the same security using base point order and key size alone.
Control: ISM-0474; Revision: 6; Updated: Mar-22; Applicability: OS, P; Essential Eight: N/A
When using ECDH for agreeing on encryption session keys, a base point order and key size of at least 224 bits is used, preferably the NIST P-384 curve.
Control: ISM-1761; Revision: 0; Updated: Mar-22; Applicability: S; Essential Eight: N/A
When using ECDH for agreeing on encryption session keys, NIST P-256, P-384 or P-521 curves are used, preferably the NIST P-384 curve.
Control: ISM-1762; Revision: 0; Updated: Mar-22; Applicability: TS; Essential Eight: N/A
When using ECDH for agreeing on encryption session keys, NIST P-384 or P-521 curves are used, preferably the NIST P-384 curve.
Using the Elliptic Curve Digital Signature Algorithm
When using a curve from FIPS 186-4, a base point order and key size of 224 bits for correctly implemented ECDSA provides 112 bits of effective security strength. Security of a curve selected from another source cannot be assumed to have the same security using base point order and key size alone.
Control: ISM-0475; Revision: 6; Updated: Mar-22; Applicability: OS, P; Essential Eight: N/A
When using ECDSA for digital signatures, a base point order and key size of at least 224 bits is used, preferably the P-384 curve.
Control: ISM-1763; Revision: 0; Updated: Mar-22; Applicability: S; Essential Eight: N/A
When using ECDSA for digital signatures, NIST P-256, P-384 or P-521 curves are used, preferably the NIST P-384 curve.
Control: ISM-1764; Revision: 0; Updated: Mar-22; Applicability: TS; Essential Eight: N/A
When using ECDSA for digital signatures, NIST P-384 or P-521 curves are used, preferably the NIST P-384 curve.
Using Rivest-Shamir-Adleman
A modulus of 2048 bits for correctly implemented RSA provides 112 bits of effective security strength. Taking into account projected technological advances, it is assessed that 112 bits of effective security strength will remain secure until 2030.
Control: ISM-0476; Revision: 7; Updated: Mar-22; Applicability: OS, P; Essential Eight: N/A
When using RSA for digital signatures, and passing encryption session keys or similar keys, a modulus of at least 2048 bits is used, preferably 3072 bits.
Control: ISM-1765; Revision: 0; Updated: Mar-22; Applicability: S, TS; Essential Eight: N/A
When using RSA for digital signatures, and passing encryption session keys or similar keys, a modulus of at least 3072 bits is used, preferably 3072 bits.
Control: ISM-0477; Revision: 8; Updated: Mar-22; Applicability: All; Essential Eight: N/A
When using RSA for digital signatures, and for passing encryption session keys or similar keys, a different key pair is used for digital signatures and passing encrypted session keys.
Using hashing algorithms
For most purposes, a hashing algorithm with an output size of 224 bits provides 112 bits of effective security strength. Similarly, a hashing algorithm with an output size of 256 bits provides 128 bits of effective security strength, and an output size of 384 bits provides 192 bits of effective security strength. Only hashing algorithms from the SHA-2 family are approved for use.
Control: ISM-1766; Revision: 0; Updated: Mar-22; Applicability: OS, P; Essential Eight: N/A
When using SHA-2 for hashing, an output size of at least 224 bits is used, preferably SHA-384.
Control: ISM-1767; Revision: 0; Updated: Mar-22; Applicability: S; Essential Eight: N/A
When using SHA-2 for hashing, an output size of at least 256 bits is used, preferably SHA-384.
Control: ISM-1768; Revision: 0; Updated: Mar-22; Applicability: TS; Essential Eight: N/A
When using SHA-2 for hashing, an output size of at least 384 bits is used, preferably SHA-384.
Using symmetric encryption algorithms
The use of Electronic Codebook Mode with block ciphers allows repeated patterns in plaintext to appear as repeated patterns in ciphertext. Most plaintext, including written language and formatted files, contains significant repeated patterns. As such, malicious actors can use this to deduce possible meanings of ciphertext. The use of other modes, such as Cipher Block Chaining, Cipher Feedback, Galois/Counter Mode or Output Feedback, can prevent such attacks, although each has different properties which can make them inappropriate for certain use cases. AES is the only approved symmetric encryption algorithm.
Control: ISM-1769; Revision: 0; Updated: Mar-22; Applicability: OS, P, S; Essential Eight: N/A
When using AES for encryption, AES-128, AES-192 or AES-256 is used, preferably AES-256.
Control: ISM-1770; Revision: 0; Updated: Mar-22; Applicability: TS; Essential Eight: N/A
When using AES for encryption, AES-192 or AES-256 is used, preferably AES-256.
Control: ISM-0479; Revision: 5; Updated: Dec-21; Applicability: All; Essential Eight: N/A
Symmetric cryptographic algorithms are not used in Electronic Codebook Mode.
Further information
Further information on the United States’ Commercial National Security Algorithm Suite is available from the United States’ National Security Agency.
Further information on post-quantum cryptographic algorithms can be found in ASD’s Planning for Post-Quantum Cryptography publication.
ASD-Approved Cryptographic Protocols
High assurance cryptographic protocols
High assurance cryptographic protocols, which are not covered in this section, can be used for the protection of SECRET and TOP SECRET data if they are suitably implemented in HACE. Further information on high assurance cryptographic protocols can be obtained from ASD.
ASD-Approved Cryptographic Protocols
There is no guarantee of a protocol’s resistance to currently unknown attacks. However, the protocols listed in this section have been extensively scrutinised by industry and academic communities in a practical and theoretical setting. Approval for the use of the protocols listed in this section is limited to cases where they are implemented in accordance with these guidelines.
The AACPs 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
- Wi-Fi Protected Access 3.
Using ASD-Approved Cryptographic Protocols
If cryptographic equipment or software implements unapproved protocols, it is possible that these protocols could be used without a user’s knowledge. In combination with an assumed level of security confidence, this can represent a security risk. As such, an organisation can ensure that only AACPs or high assurance cryptographic protocols can be used by disabling unapproved protocols (preferred) or by advising users not to use unapproved protocols via usage policies.
Control: ISM-0481; Revision: 6; Updated: Dec-21; Applicability: All; Essential Eight: N/A
Only AACPs or high assurance cryptographic protocols are used by cryptographic equipment and software.
Further information
Further information on AACPs can be found in the following sections of these guidelines.
Further information on the use of Wi-Fi Protected Access 2 and Wi-Fi Protected Access 3 can be found in the wireless networks section of the Guidelines for Networking.
Transport Layer Security
Using Transport Layer Security
When using ICT equipment or software that implements TLS, controls for using AACAs and AACPs in the ASD-Approved Cryptographic Algorithms and ASD-Approved Cryptographic Protocols sections of these guidelines will also need to be consulted.
Configuring Transport Layer Security
The terms Secure Sockets Layer and TLS have traditionally been used interchangeably. However, Secure Sockets Layer and earlier versions of TLS are no longer considered suitable for use as an AACP. As such, an organisation implementing TLS should implement TLS version 1.3. In addition, a number of security risks exist when TLS is configured in an insecure manner. To mitigate these security risks, TLS should be configured as per the configuration settings below.
Control: ISM-1139; Revision: 6; Updated: Mar-22; Applicability: All; Essential Eight: N/A
Only the latest version of TLS is used for TLS connections.
Control: ISM-1369; Revision: 3; Updated: Mar-22; Applicability: All; Essential Eight: N/A
AES-GCM is used for encryption of TLS connections.
Control: ISM-1370; Revision: 3; Updated: Mar-22; Applicability: All; Essential Eight: N/A
Only server-initiated secure renegotiation is used for TLS connections.
Control: ISM-1372; Revision: 3; Updated: Mar-22; Applicability: All; Essential Eight: N/A
DH or ECDH is used for key establishment of TLS connections.
Control: ISM-1448; Revision: 2; Updated: Mar-22; Applicability: All; Essential Eight: N/A
When using DH or ECDH for key establishment of TLS connections, the ephemeral variant is used.
Control: ISM-1373; Revision: 2; Updated: Mar-22; Applicability: All; Essential Eight: N/A
Anonymous DH is not used for TLS connections.
Control: ISM-1374; Revision: 3; Updated: Mar-22; Applicability: All; Essential Eight: N/A
SHA-2-based certificates are used for TLS connections.
Control: ISM-1375; Revision: 4; Updated: Mar-22; Applicability: All; Essential Eight: N/A
SHA-2 is used for the Hash-based Message Authentication Code (HMAC) and pseudorandom function (PRF) for TLS connections.
Control: ISM-1553; Revision: 1; Updated: Mar-22; Applicability: All; Essential Eight: N/A
TLS compression is disabled for TLS connections.
Control: ISM-1453; Revision: 1; Updated: Sep-18; Applicability: All; Essential Eight: N/A
Perfect Forward Secrecy (PFS) is used for TLS connections.
Further information
Further information on implementing TLS can be found in in ASD’s Implementing Certificates, TLS, HTTPS and Opportunistic TLS publication.
Further information on TLS filtering in gateways can be found in the web content filters section of the Guidelines for Gateways.
Secure Shell
Using Secure Shell
When using ICT equipment or software that implements SSH, controls for using AACAs and AACPs in the ASD-Approved Cryptographic Algorithms and ASD-Approved Cryptographic Protocols sections of these guidelines will also need to be consulted.
Configuring Secure Shell
SSH version 1 was found to have a number of vulnerabilities, and was subsequently replaced by SSH version 2. As such, an organisation implementing SSH should disable the use of SSH version 1. In addition, a number of security risks exist when SSH is configured in an insecure manner. To mitigate these security risks, SSH should be configured as per the configuration settings below.
The configuration settings below are based on OpenSSH. An organisation using other implementations of SSH should adapt these settings to suit their SSH implementation.
Control: ISM-1506; Revision: 1; Updated: Mar-22; Applicability: All; Essential Eight: N/A
The use of SSH version 1 is disabled for SSH connections.
Control: ISM-0484; Revision: 6; Updated: Dec-21; Applicability: All; Essential Eight: N/A
The SSH daemon is configured to:
- only listen on the required interfaces (ListenAddress xxx.xxx.xxx.xxx)
- have a suitable login banner (Banner x)
- have a login authentication timeout of no more than 60 seconds (LoginGraceTime 60)
- disable host-based authentication (HostbasedAuthentication no)
- disable rhosts-based authentication (IgnoreRhosts yes)
- disable the ability to login directly as root (PermitRootLogin no)
- disable empty passwords (PermitEmptyPasswords no)
- disable connection forwarding (AllowTCPForwarding no)
- disable gateway ports (GatewayPorts no)
- disable X11 forwarding (X11Forwarding no).
Authentication mechanisms
As public key-based authentication schemes offer stronger authentication than passphrase-based authentication schemes, due to being much less susceptible to brute-force attacks, they should be used for SSH connections. Furthermore, in order to protect SSH private keys, access to such keys should be protected via the use of passphrases or key encryption keys.
Control: ISM-0485; Revision: 3; Updated: Sep-18; Applicability: All; Essential Eight: N/A
Public key-based authentication is used for SSH connections.
Control: ISM-1449; Revision: 1; Updated: Sep-18; Applicability: All; Essential Eight: N/A
SSH private keys are protected with a passphrase or a key encryption key.
Automated remote access
If using logins without a passphrase for automated purposes, a number of security risks may arise, specifically:
- if access from unknown Internet Protocol (IP) addresses is not restricted, malicious actors could automatically authenticate to systems without needing to know any passphrases
- if port forwarding is not disabled, or it is not configured securely, access may be gained to forwarded ports, thereby, creating a communication channel between malicious actors and a host
- if agent credential forwarding is enabled, malicious actors could connect to the stored authentication credentials and use them to connect to other trusted hosts, or even intranet hosts if port forwarding has been allowed as well
- if X11 display remoting is not disabled, malicious actors could gain control of displays as well as keyboard and mouse control functions
- if console access is allowed, every user who logs into the console could run programs that are normally restricted to authenticated users.
To assist in mitigating these security risks, it is essential that the ‘forced command’ option is used to specify what command is executed and parameter checking is enabled.
Control: ISM-0487; Revision: 4; Updated: Mar-22; Applicability: All; Essential Eight: N/A
When using logins without a passphrase for SSH connections, the following are disabled:
- access from IP addresses that do not require access
- port forwarding
- agent credential forwarding
- X11 display remoting
- console access.
Control: ISM-0488; Revision: 4; Updated: Mar-22; Applicability: All; Essential Eight: N/A
If using remote access without the use of a passphrase for SSH connections, the ‘forced command’ option is used to specify what command is executed and parameter checking is enabled.
SSH-agent
SSH-agent and similar key caching programs manage private keys stored on workstations and servers. Specifically, when an SSH-agent launches, it requests a user’s passphrase to unlock the user’s private key. Subsequent access to remote systems is then performed by the SSH-agent and does not require the user to re-enter their passphrase. Screen locks and expiring key caches can be used to ensure that a user’s private key is not left unlocked for a long period of time.
Control: ISM-0489; Revision: 5; Updated: Mar-22; Applicability: All; Essential Eight: N/A
When SSH-agent or similar key caching programs are used, it is limited to workstations and servers with screen locks and key caches that are set to expire within four hours of inactivity.
Further information
Further information on configuring OpenSSH is available from the OpenSSH project.
Secure/Multipurpose Internet Mail Extension
Using Secure/Multipurpose Internet Mail Extension
When using ICT equipment or software that implements S/MIME, controls for using AACAs and AACPs in the ASD-Approved Cryptographic Algorithms and ASD-Approved Cryptographic Protocols sections of these guidelines will also need to be consulted.
Configuring Secure/Multipurpose Internet Mail Extension
S/MIME version 2.0 required the use of weaker cryptography than approved for use in these guidelines. As such, S/MIME version 3.0 was the first version to be approved for use as an AACP.
Control: ISM-0490; Revision: 4; Updated: Mar-22; Applicability: All; Essential Eight: N/A
Versions of S/MIME earlier than S/MIME version 3.0 are not used for S/MIME connections.
Internet Protocol Security
Using Internet Protocol Security
When using ICT equipment or software that implements IPsec, controls for using AACAs and AACPs in the ASD-Approved Cryptographic Algorithms and ASD-Approved Cryptographic Protocols sections of these guidelines will also need to be consulted.
Mode of operation
IPsec can be operated in tunnel mode or transport mode. The tunnel mode of operation is preferred as it provides full encapsulation of IP packets while the transport mode of operation only encapsulates the payload of IP packets.
Control: ISM-0494; Revision: 3; Updated: Sep-18; Applicability: All; Essential Eight: N/A
Tunnel mode is used for IPsec connections; however, if using transport mode, an IP tunnel is used.
Protocol selection
IPsec contains two major protocols, the Authentication Header (AH) protocol and the Encapsulating Security Payload (ESP) protocol. In order to provide a secure Virtual Private Network style connection, both authentication and encryption are needed. While the AH and ESP protocols can both provide authentication, for the IP packet and the payload respectively, only the ESP protocol can provide encryption.
As the combined use of the AH protocol and the ESP protocol is not supported by Internet Key Exchange (IKE) version 2, the ESP protocol should be used for authentication and encryption of IPsec connections.
Control: ISM-0496; Revision: 5; Updated: Mar-22; Applicability: All; Essential Eight: N/A
The ESP protocol is used for authentication and encryption of IPsec connections.
Key exchange
There are several methods for establishing shared keying material for IPsec connections, including manual keying and the IKE protocol. As the IKE protocol addresses a number of security risks associated with manual keying, it is the preferred method for key establishment. Note, as IKE version 1 has been deprecated, IKE version 2 should be used.
Control: ISM-1233; Revision: 2; Updated: Mar-22; Applicability: All; Essential Eight: N/A
IKE version 2 is used for key exchange when establishing IPsec connections.
Encryption algorithms
The only approved encryption algorithm for IPsec connections is AES. IKE version 2 supports the use of AES with Cipher Block Chaining, Counter Mode, Counter with Cipher Block Chaining Message Authentication Code, and Galois/Counter Mode. Note, however, supported modes may vary between different cryptographic equipment and software.
Control: ISM-1771; Revision: 0; Updated: Mar-22; Applicability: All; Essential Eight: N/A
AES is used for encrypting IPsec connections, preferably ENCR_AES_GCM_16.
Pseudorandom function algorithms
IKE version 2 requires the use of a PRF in order to generate random data for cryptographic operations. The approved algorithms that can be used for PRF are HMAC-SHA256, HMAC-SHA384 and HMAC-SHA512.
Control: ISM-1772; Revision: 0; Updated: Mar-22; Applicability: All; Essential Eight: N/A
PRF_HMAC_SHA2_256, PRF_HMAC_SHA2_384 or PRF_HMAC_SHA2_512 is used for IPsec connections, preferably PRF_HMAC_SHA2_512.
Integrity algorithms
The approved integrity algorithms for IPsec connections are HMAC-SHA256, HMAC-SHA384 and HMAC-SHA512. However, if using AES with Galois/Counter Mode as the encryption algorithm, it can also be used for authentication purposes. In such cases, the integrity algorithm should be configured as NONE.
Control: ISM-0998; Revision: 5; Updated: Mar-22; Applicability: All; Essential Eight: N/A
AUTH_HMAC_SHA2_256_128, AUTH_HMAC_SHA2_384_192, AUTH_HMAC_SHA2_512_256 or NONE (only with AES-GCM) is used for authenticating IPsec connections, preferably NONE.
Diffie-Hellman groups
A sufficiently large DH modulus provides greater security for key exchanges when establishing IPsec connections.
Control: ISM-0999; Revision: 6; Updated: Mar-22; Applicability: All; Essential Eight: N/A
DH or ECDH is used for key establishment of IPsec connections, preferably 384-bit random ECP group, 3072-bit MODP Group or 4096-bit MODP Group.
Security association lifetimes
Using a security association lifetime of less than four hours (14400 seconds) can provide a balance between security and usability.
Control: ISM-0498; Revision: 4; Updated: Mar-22; Applicability: All; Essential Eight: N/A
A security association lifetime of less than four hours (14400 seconds) is used for IPsec connections.
Perfect Forward Secrecy
Using PFS reduces the impact of the compromise of a security association.
Control: ISM-1000; Revision: 4; Updated: Sep-18; Applicability: All; Essential Eight: N/A
PFS is used for IPsec connections.
