GO-ITS 25.12 Security Requirements for the Use of Cryptography

Foreword

Government of Ontario Information Technology Standards (GO-ITS) are the official publications on the guidelines, preferred practices, standards, and technical reports adopted by the Ontario Public Service under the delegated authority of the Management Board of Cabinet (MBC). These publications support the responsibilities of the Ministry of Government and Consumer Services (MGCS) for coordinating standardization of Information & Information Technology (I&IT) in the Government of Ontario. Publications that set new or revised standards provide enterprise architecture guidance, policy guidance and administrative information for their implementation. In particular, GO-ITS describe where the application of a standard is mandatory and specify any qualifications governing the implementation of standards.

All GO-ITS 25 Standards are based on the work of recognized global authorities in information and operational security, both in government and industry.

Copies of cited GO-ITS standards may be obtained as follows:

Internet: Information Technology Standards

Summary

The Corporate Policy on Information and Information Technology Security and the Information Sensitivity Classification (ISC) Policy require that Government of Ontario employees protect information that is received, created, held by, or retained on behalf of, Ontario ministries and agencies. Programs are responsible for the implementation of appropriate safeguards, based on an assessment of the risks involved.

Cryptography is an industry standard practice for the protection of data confidentiality and integrity. All Government of Ontario staff members are required to be aware of the sensitivity of program information, and the practices and safeguards needed to ensure the ongoing security of information.

The MGCS Cyber Security Division (CSD), or a successor division, is the cryptographic authority for the Government of Ontario.

Version control and change management

Ongoing ownership and responsibility for maintenance and evolution of this document resides with the MGCS Cyber Security Division (CSD), or a successor division/branch. CSD will provide advice on the interpretation and application of these security requirements and manage any updates to the document when the need arises.

Contact information

If you have questions or require further information about this document or the GO-ITS 25 series, please contact the following Cyber Security Division staff:

1. Introduction

This document is one in a series that defines operational principles, requirements and best practices for the protection of Government of Ontario networks and computer systems.

1.1. Purpose of the standard

This document outlines the context and requirements for appropriate use of cryptography within the Government of Ontario.

The objective of this document is to ensure that cryptography of an appropriate type and strength is employed to protect Government of Ontario I&IT resources.

This document has been produced in consultation with stakeholder groups (primarily from privacy and security centres of excellence) within the Government of Ontario. It makes reference to section 10 (“Cryptography”) of the ISO/IEC 27002:2013 code of practice, and technical requirements within are stated in accordance with both ISO/IEC 27002:2013 general recommendations and guidance received from external partners.

1.2. Terms

Within this document, certain wording conventions are followed. There are precise requirements and obligations associated with the following terms:

Must: this word, or the terms "required", or "shall”, means that the statement is an absolute mandatory requirement.

Should: this word “should”, or the adjective "recommended”, means that there may exist valid reasons in particular circumstances to ignore the recommendation, but the full implications (e.g., business functionality, security, and cost) must be understood and carefully considered before deciding to ignore the recommendation.

1.3. Application and scope

GO-ITS 25 Security requirements apply to all vendors, ministries, former Schedule I and IV agencies, and third parties (including any information technology system or network that processes ministry and agency information) under contract to the Ontario government, unless exempted in a Memorandum of Understanding.

All cryptographic mechanisms protecting Government of Ontario I&IT resources must adhere to the requirements in this document (e.g., approved cryptographic algorithms and constructions, key lengths, and related protocols). Please consult Appendix A of this document for specific information.

For security involving sensitive information ^{footnote 1[1]};, if it becomes known that sensitive information is deemed to be at serious risk, immediate remedial action must be taken to mitigate the risk by applying appropriate tools, controls, methods, and procedures as per the relevant GO-ITS security document.

As new GO-ITS standards are approved, they are deemed mandatory for all project development and procurement opportunities.

The GO-ITS 25.12 Security Requirements for the Use of Cryptography must be understood to apply to:

• All entities identified above and/or which use the Government of Ontario integrated network;
• Third parties under contract to and/or services operated on behalf of the Government of Ontario, including Cloud Services, as defined by GO-ITS 25.21; and
• All information for which the Government of Ontario is accountable, during any type of transmission or transport, and while stored on any type of computing equipment or data storage device.

For the purposes of this document all references to “information” refer to digital information and data.

The MGCS Cyber Security Division should be contacted if application of this standard is not clear relative to a given environment, program, or application.

1.4. Out of scope

This document does not provide requirements for the registration of individuals or devices for the issuance of cryptographic keys or digital certificates, or describe specific password or passphrase requirements for their protection, or related access controls. Such controls are addressed in separate documents. Enterprise key management policies, requirements, and strategies for the Government of Ontario are described in additional documentation (e.g., the GO-PKI Certificate Policy). Questions about out of scope items should be directed to the contacts for this document.

1.5. Background

The Management and Use of Information & Information Technology Directive and the ISC Policy require that the confidentiality, integrity, availability, and reliability of information and information systems are safeguarded. Cryptography is the industry standard means to assure the confidentiality and integrity of sensitive information, and is referenced in the ISO/IEC 27002:2013 code of practice.

Cryptography is also commonly used to provide for reliable message authentication^{footnote 2[2]}, and enable the use of secure digital signatures^{footnote 3[3]}. Proper use of cryptography produces a result where it is computationally infeasible for attackers to compromise the confidentiality and/or integrity of the information, communication, or exchange that has been protected.

Three cryptographic techniques in particular are widely used for these purposes:

• Symmetric key (or secret key) techniques involve a single key that is used to both encrypt and decrypt information. This key is shared out of band to authorized recipients, via an alternate secure channel. The key is otherwise kept secret and protected from unauthorized access. Symmetric key techniques are primarily used as a tool to ensure confidentiality.
• Asymmetric key (or public key) techniques assign unique key pairs to each user; a key pair consists of a public encryption key that can be revealed to anyone (even over insecure channels, allowing use when no secure channel is available), and a private decryption key that is never shared, and must be kept secret.
• Hash functions map variable length input (e.g., a file or piece of data) to a fixed length bit string. Hash functions must be collision resistant (e.g., sets of unique input data must not produce the same output result) to provide for security. Secure hash functions are primarily used as a tool to assure data integrity (e.g., detection of errors, modifications, and/or corruption of data in storage or transmission).

The main advantages of asymmetric cryptography include support for digital signatures, and practical key management within large groups of users (in particular, the ability to manage and distribute unique public keys over public networks). The primary advantage of symmetric cryptography is its high speed of operation (as implementations of symmetric cryptography typically offer significantly higher performance, given identical resources), and low overhead for the distribution of shared keys within small groups of users (or devices).

In general, asymmetric cryptography should be used for an open multi-user environment, or public infrastructure where secure out of band channels are not available or economically feasible. The overhead associated with the use of symmetric cryptography in such environments (e.g., the protection of secret keys while they are being shared and distributed) can quickly become difficult to manage.

Asymmetric and symmetric cryptography are frequently used in concert to obtain the key management advantages of a public key system, and the computational advantages of symmetric encryption. For example, an asymmetric system can be used to authenticate identities and to secure key agreement or protect the transmission of symmetric keys over insecure media, which are used in turn to quickly encrypt larger amounts of information (often using a symmetric block cipher). In situations where symmetric keys can be readily and securely managed, symmetric cryptography alone may be sufficient (e.g., within small environments, or for a small number of managed devices with static key configuration and a secure keying method). Combinations of such components and additional cryptographic methods can also enable other functionality, such as message authentication and non-repudiation.

1.6. Principles

The following guiding principles support, and are stated in accordance with, the Corporate Policy on Information and Information Technology Security, and ISC policy/guidelines:

• Cryptography alone cannot address the entire range of security concerns associated with the storage, processing, and transmission of sensitive information; its use does not diminish the need for Program Managers to ensure that formal, documented risk assessments are conducted, employees are trained, and appropriate physical and logical access controls are implemented to protect Government assets;
• The secure management of cryptographic keys is essential to the effective use of cryptographic techniques. Any compromise or loss of key material may lead to a compromise of the confidentiality, integrity, and availability of information;
• The Government of Ontario retains ownership of cryptographic keys that it has created, issued, or otherwise relies upon to protect Government information;
• Cryptographic material (e.g., a key) intended to protect sensitive information will require protection itself, at a level commensurate with the sensitivity of that information;
• Confidence in the strength of a given cryptographic system generally decreases with the passage of time, as both the efficacy of techniques and processing power available to potential attackers are likely to increase;
• The use of encryption should not disrupt other critical security mechanisms and processes (e.g., implementation of security patches or software upgrades), nor should it create unintentional and adverse impact to the availability of time-critical information (e.g., in emergency situations); and
• Program Managers have a responsibility to ensure that all legislative/regulatory and legal discovery requirements applicable to their operations can be satisfied when data encryption is deployed as a technical safeguard, including within third-party services.

2. Requirements

Cryptographic material must be securely protected and managed. This includes secure processes for the issuance, renewal, revocation, destruction, and recovery of cryptographic keys. The following requirements are mandatory for all cryptographic implementations and technology deployments governed by this document:

2.1. Education and training

Technical staff that develop, implement, and/or manage systems must be aware of the requirements regarding the use of cryptography as described in this document.

All government staff must be aware of the sensitivity of program information and the procedures and practices (e.g., ISC policy and guidelines) needed to protect sensitive information, including relevant legislative requirements or directives.

2.2. Information in storage

Sensitive electronic information that requires a significant degree of protection as stated within ISC policy and guidelines should be encrypted in storage, or when operationally feasible, stored using endorsed secure hash algorithms in conjunction with appropriate constructions and techniques^{footnote 4[4]}. The Privacy Impact Assessment (PIA) or Threat and Risk Assessment (TRA) for the relevant/local program area or service, or other sources/metrics, may also indicate that an enhanced level of cryptographic protection is required to address high-risk situations or environments (consult Appendix A of this document for more details).

Encrypted sensitive information held as data in storage for more than two years^{footnote 5[5]} must be encrypted in a manner suitable for a high-risk environment (see Appendix A).

If the responsibility for encrypted information is transferred to a different organization, and access by the previous owner is no longer authorized, the transferred information must be encrypted with a new key by the new organization/custodian.

Digital signatures should be applied to stored information when needed to address risks relating to integrity and/or non-repudiation (as determined by a TRA, program specifications/metrics/design, or through other means). Digital signature implementations should also include the use and checking of timestamps generated from a validated reference time source.

If practical, a central, securely managed automatic encryption mechanism (e.g., an application intended for this function) should be used to encrypt sensitive information.

The following additional requirements apply to specific modes of storage:

Mobile devices

Government of Ontario mobile devices (e.g., portable computers, smartphones, tablets, and removable media) intended to process or store sensitive information must incorporate functionality whereby the entirety of device storage capacity can be encrypted.

Mobile encryption systems must be enterprise-managed. Such systems must be endorsed by Cyber Security Division for such use with the Government of Ontario, must offer comprehensive protection via cryptographic and other security mechanisms, and must be suitable for high-risk environments.

Refer to GO-ITS 25.10 Security Requirements for Mobile Devices for additional direction.

Desktop computers

Government desktop computers are typically not adequately protected against high resource threat agents (e.g., a focused and determined adversary such as an organized, funded group). Their local storage capacity should not be used to store sensitive information.

If operational requirements are such that it is necessary to store sensitive information on a desktop computer, the information must be encrypted using an encryption mechanism specifically endorsed by Cyber Security Division for this purpose, and additional security measures may be required for high-risk environments.

Data repositories

Sensitive information must be encrypted at the column or data field/cell level before it is written to a data repository if column or data field/cell protection has been indicated by ISC requirements, a PIA, or a TRA for a given project. For other use cases and projects, program areas should review available repository/platform encryption options, and any relevant PIA/TRA, prior to safeguard selection. When operationally feasible, appropriate constructions and techniques should be used for comparisons and verification of sensitive fields (avoiding additional storage or exposure of the actual sensitive information). All mechanisms described in this section must employ secure components and constructions endorsed by Cyber Security Division (see Appendix A for more information).

When deploying encryption within data repositories, careful consideration should be given to any limitations present within repository/platform encryption options, and any impact on software development, deployment, performance, administration, or legal duties.

2.3. Communications security

Sensitive information and data must be safeguarded when transmitted (i.e., encryption “in transit”).

General transmission and communication

Sensitive information and data must be encrypted using appropriate means (see Appendix A) for all types of communications, other than those that occur within the same designated security zone, and that do not employ wireless technology.^{footnote 6[6]}

Wireless transfers of Government of Ontario information using lightweight protocols and/or external services (e.g., mobile wireless data, satellite, or Bluetooth) must be further encrypted using approved means (see Appendix A) during data communications, unless a specific, secure service has been endorsed by CSD for use ^{footnote 7[7]}. Adequate cryptographic functionality is present in some wireless protocols, and this possibility should be investigated prior to deployment.

The integrity of sensitive data, business information, or transactions sent via a wireless protocol, or that crosses a managed perimeter boundary in either direction, must be verified using an approved message authentication code (e.g., HMAC or similar functions described in Appendix A), or a digital signature upon receipt. This functionality is present in many systems/applications and should be investigated prior to deployment.

Digital signatures must be used if the identified integrity requirements (e.g., as documented in a PIA or TRA, detailed in enterprise security architecture, or per program specifications/metrics/design) include support for high-risk situations/environments and/or non-repudiation, even if sensitive data does not cross a managed perimeter boundary. This functionality is available in several existing messaging protocols and should be investigated prior to deployment.

Digital signature implementations must include the use and checking of an accurate timestamp from a validated and redundant reference time source.

Mainframe communications

Mainframe traffic must be encrypted within the Government of Ontario if the communication includes sensitive information and does not occur within the same designated zone, or via a dedicated physical connection.

Management of cryptography

Cryptography must be appropriately deployed and managed if it is to be effective. All cryptographic schemes and internal key management procedures deployed within the Government of Ontario must be managed and documented.

Procurement of cryptography

All products supporting cryptography that are procured for use within or on behalf of the Government of Ontario, including any services described in section 1.3 of this document, must comply with the requirements in this document. Other relevant sources of information may be consulted for general guidance (e.g., CAVP standards, CMVP FIPS 140-2 evaluations, ISO/IEC 19790:2012 / FIPS 140-3 evaluations, ISO/IEC 24759:2017, and relevant ISO/IEC updates/notices).

Cryptographic products must be configurable using administrator-controlled rules including, but not limited to:

• Specific cryptographic algorithm(s), mode of operation, and the minimum effective key lengths and/or security strengths to be used; and
• Password and authentication schemes that meet the access control and password management requirements described in GO-ITS 25.0 General Security Requirements.

Cryptographic agility

For various reasons, including both gradual deprecation and more immediate security concerns, encryption algorithms, methods, and supporting protocols may require migration or replacement. Systems and services that incorporate cryptography as a safeguard should therefore be designed, implemented, and deployed in a manner that supports cryptographic agility. This can include:

• The use of open, modular designs, abstraction, loose coupling, APIs, API gateways, etc. – instead of in-built, rigid constructions;
• The ability to incorporate more than one cryptographic method or construction by design, and either expeditiously switch between them if required, or operate in a hybrid manner (as defined by industry standard formats and protocols, where possible);
• The ability to expeditiously migrate a system or service;
• Anticipation of needs regarding backward compatibility, interoperability, etc.; and
• Adherence to cryptographic standards.

Deployment of cryptography

Cryptographic mechanisms within the Government of Ontario must be deployed and configured in compliance with the requirements in this document (consult Appendix A), applicable implementation standards, and any requirements mandated through the TRA process. Cyber Security Division should be consulted to determine how best to address security requirements where uncertainty exists.

The ability to modify the configuration of cryptographic mechanisms must be restricted to qualified and specifically authorized administrators.

Cryptographic mechanisms deployed for users, applications and services must be kept current and updated when necessary to address vulnerabilities, as advised by CSD.

All applications and services using cryptography must:

• Employ a random number generation (RNG) or high-quality pseudo-random number generation (PRNG) / deterministic random bit generator (DRBG) implementation that is considered and validated to be cryptographically adequate (consult NIST SP 800-131A Rev. 2, CMVP and FIPS materials, ISO/IEC 18031:2011, and relevant ISO/IEC updates/notices for more information);
• Check the validity of certificates, and not use certificates that are revoked, expired, or otherwise invalid; and
• Securely delete decrypted information retained in temporary memory and/or caches immediately upon completion of the related transaction or activity.

Applications and services that process and may provide access to sensitive information must undergo security testing and evaluation (STE) prior to implementation, and when changes are made that may introduce vulnerabilities, alter configurations, or both.

Development of cryptography

Ministries and agencies of the Government of Ontario must not develop any type of unique or proprietary cryptographic algorithm, protocol, RNG/PRNG/DRBG, or cryptographic implementation for the purpose of safeguarding information; all cryptography used to secure Government of Ontario I&IT assets within the scope of this document must be acquired via peer-reviewed, industry standard products, software, or services endorsed by CSD. Such products, software, and services must meet the requirements in this document, and be procured through appropriate channels.

Protection of cryptographic material

Access to cryptographic material must be limited to its intended use and restricted to authorized entities (e.g., an individual, application, or service).

Cryptographic material for Government use, and all technology used for its generation, transmittal, use, storage, and disposal, must be protected using physical, logical, virtual, network, and personnel security measures, in addition to other applicable security guidance.

Cryptographic keys must be protected to a degree commensurate with the sensitivity of the information they are intended to protect, while in storage or in transit. The integrity of the material should be confirmed prior to each use (e.g., validation of labels, digital signatures, MAC, etc.).

Keys or certificates must be issued by the Government of Ontario, or supplied by an organization endorsed by Cyber Security Division as a provider of cryptographic services (consult the section of this document titled Management of Cryptographic Services). Keys should be generated via a secure software module or Hardware Security Module, where possible. For generation of keys used to protect sensitive information, or in programs/services subject to high-risk situations or environments, such modules should be both on-premises and OPS-managed, where operationally feasible.

If cryptographic material protecting sensitive program information is assigned to an entity other than a person (e.g., an application or service):

• A responsible, accountable custodian role must be devised and assigned for the protection of the key material, and to ensure that it is deployed in compliance with applicable requirements;
• Protection of the assigned cryptographic material must be changed when a new individual is appointed (e.g., the previous appointee or custodian must no longer have access);
• The Program Manager must be aware of the current appointee’s contact information and responsibilities, and the other positions that require access to the cryptographic material to fulfill their responsibilities (e.g., members of operations units); and
• The appointee must document all access to the cryptographic material (by name of the individual granted access), and must take caution and/or measures to prevent access by an individual who is no longer authorized. Access documents and logs must be regularly reviewed and subject to audit.

Hardware security modules

Hardware security modules (HSMs) are an industry-standard means to protect keys and enable cryptographic operations. HSM devices allow for secure key generation, storage, management, and cryptographic acceleration in production services, and typically represent the highest commercially available level of protection for keys and critical security parameters. In modern I&IT environments, HSMs may be dedicated hardware, assigned to a specific organizational unit or service/program, or shared hardware that relies on virtualization and strongly isolated partitions to provide multi-tenancy.

HSMs are typically evaluated products, due to their design considerations and the high assurance and integrity required. While virtual or “vault” offerings based entirely in software are sometimes referred to as “virtual HSMs”, and third-party “Key Management Services” may leverage hardware HSMs, certain aspects of validated hardware integrity and purpose-built security may not be available on all such platforms^{footnote 8[8]}.

At a minimum, hardware security modules intended to store key material for Government use:

• Must be validated to be compliant with (and capable of configured security policy to support) FIPS 140-2 or FIPS 140-3 / ISO/IEC 19790:2012 level 2;
• When intended to protect High Sensitivity information, and located off-premises and/or subject to high-risk situations or environments^{footnote 9[9]}, HSMs should be validated to be compliant with (and capable of configured security policy to support) FIPS 140-2 or FIPS 140-3 / ISO/IEC 19790:2012 level 3;
• Must be deployed and sited in a manner that strongly reduces exposure to attack (both electronic and physical);
• Must be operated (including deployment, access control, logging, and ongoing management) according to the segregation of duties and least privilege principles described in GO-ITS 25.0;
• Must be subject to secure management of HSM firmware, authentication/validation of installed firmware, and integrated self-tests; and
• Must be subject to monitoring and audit.

Should an HSM be located and operated/managed off-premises in the context of commodity Cloud Services (e.g., as part of a Key Management Service offered by a Cloud Service Provider), the requirements stated in GO-ITS 25.21 will additionally apply to such devices and services.

Key management

Internal key management procedures must be developed for all applications employing cryptographic systems for the protection of sensitive information. These procedures must address separation of duties, privileges, re-keying requirements, key generation, key assignment, revocation processes (including related timelines), secure distribution, and secure destruction of cryptographic material.

Cryptographic keys issued for test purposes must not be used in a production environment, and production cryptographic keys must not be used in a test environment.

Internal staff responsible for the issuance and/or management of cryptographic keys should be organizationally separated from operations (i.e., separation of duties), and must possess a valid Government of Ontario Personnel Screening result.

Recovery of encrypted information

Cryptographic services must include a secure mechanism for the recovery of symmetric and asymmetric decryption keys when needed to recover encrypted information in storage (e.g., lost password, departing employee, a corrupted key, legal discovery requirements, or forensics investigation). Government of Ontario key material must not however be held in escrow by a third party (please see definition of key escrow in the glossary for this document).

The potential for regulatory and/or legal obligations to provide information that may have been encrypted must be considered for all encryption systems. Decryption keys must be recoverable after their expiry or termination to enable the future decryption of information, including archived backups.

Only the user or the responsible area Director may request recovery of encrypted information. The identity of the requester must be verified before the recovery is carried out. The responsible Director must confirm the legitimacy of requests for access to encrypted information (e.g., court order or other authority) before requesting recovery.

If the recovery of encrypted information causes the generation of an identity credential under the user’s name, the recovery procedure must prevent the use of the identity credential by anyone other than the user.

A secure self-recovery mechanism endorsed by Cyber Security Division should be provided for users to recover encrypted material themselves when they cannot recover, or remember, their credentials (e.g., without interactive assistance from an administrator or help desk).

Management of cryptographic services

An organization that provides cryptographic services for the Government of Ontario must establish and adhere to operating policy and procedures that comply with the requirements in this document, and other relevant government security standards and policies (e.g., other GO-ITS 25 series standards, and ISC policy and guidelines). Should a Cloud Service Provider provide such services, the requirements stated in GO-ITS 25.21 will additionally apply.

Emerging threats

The passage of time alone, and associated, incremental advances in cryptanalytic ability, are not the only threat to cryptographic systems. Emerging, and more immediate, technical threats that could pose significant challenges to existing cryptography (e.g., unprecedented advances in computational ability) must also be expected and addressed. In cases, such developments could result in the failure of some widely-deployed encryption systems.

Sound, forward-looking specifications, cryptographic agility, asset/implementation inventory, an understanding of relevant supply chains and interoperability requirements, risk management, and information management practices are at present the best course of action regarding potential emerging threats to existing cryptography, and should be included where appropriate in plans and documentation (e.g., strategy, enterprise architecture artifacts, service design, etc.) for new systems.

3. Responsibilities

Users

All Government of Ontario employees and staff using I&IT resources are responsible for:

• Complying with directives, policies, and agreements when accessing or using Government of Ontario information, equipment, and services;
• Understanding information sensitivity and their duties to protective sensitive information as per the ISC policy and guidelines;
• Using the cryptographic technology provided to them for the protection of Government information; and
• Reporting any suspected security breaches to the IT Service Desk.

Program managers

Program managers are responsible for:

• Being aware of any custodian roles within their area;
• Maintaining relevant contact information and organizational details regarding those who interact with custodians;
• Ensuring ISC compliance and the completion of PIA and TRA work products;
• Ensuring required security safeguards are in place to protect Government of Ontario information, including additional safeguards recommended and approved via the PIA and TRA processes; and
• Reporting any security exposures or suspected security incidents.

Directors

Directors are responsible for:

• Ensuring that staff members are aware of and adequately trained in their responsibilities as set out in this document, ISC, and other relevant policies and standards;
• Ensuring that agreements with consulting firms and service providers, including Cloud Service Providers, include provisions that outline the organization’s responsibilities for the cryptographic protection of Government I&IT resources;
• Ensuring required security safeguards are in place to protect Government of Ontario information, including additional safeguards recommended and approved via the PIA and TRA processes;
• Initiating and managing requests for recovery from encryption keys;
• Confirming the legitimacy of any such requests that originate from within their area; and
• Reporting any security exposures or suspected security incidents.

I&IT clusters

The I&IT clusters are responsible for:

• Supporting Program Managers and Directors in ensuring that Government information is protected by appropriate security safeguards, and in accordance with ISC requirements;
• Working with relevant Cyber Security Branch cluster service liaison staff when appropriate;
• Procuring, deploying and maintaining information technology products that incorporate cryptographic components, in compliance with these requirements;
• Ensuring that applications and services appropriately employ cryptography in compliance with these requirements;
• Providing users with instruction and support;
• Supporting security incident reporting and handling procedures as required;
• Ensuring that agreements with service providers, including Cloud Service Providers, address security requirements; and
• Monitoring for compliance with this document.

Infrastructure Technology Services (ITS)

ITS is responsible for:

• Ensuring that agreements that they enter into with cryptographic service providers will address the requirements in this document;
• Enterprise network management in support of systems and/or services described in this document;
• Monitoring provided services for compliance with the requirements in this document; and
• Operation of the IT Service Desk, and provision of assistance to clients.

Custodians

Any appointed custodian of cryptographic material is responsible for:

• Ongoing management and due protection of any key material assigned, at an appropriate level, given the role of the assigned material and sensitivity of associated protected information;
• Formally documenting all access to the protected cryptographic material, subsequent to validation of all requests to ensure they are authorized;
• Review of access and other logs associated with assigned material;
• Appropriate management of responsibilities, including access to audit, and relinquishing the custodian role to any appointed replacement custodian as required; and
• Reporting any security exposures or suspected security incidents.

Cryptographic service providers

Any Cryptographic service provider to the Government of Ontario is responsible for:

• Establishing and adhering to operating policy and procedures that comply with this standard, relevant Government directives and policies, and applicable industry standards and practices;
• Due diligence in the operation of all systems and processes related to the cryptographic services and techniques provided; and
• Accommodation of audit to validate sound operation of systems and processes, and due co-operation regarding disclosure of practices and documentation.

Cyber Security Division

Cyber Security Division, or a successor division/branch, is responsible for:

• Authorship of security policies and standards for the Government of Ontario, subject to appropriate approval;
• Maintaining documentation regarding the Certificate Authority for the Government of Ontario PKI service (GO-PKI) for the Ontario Public Service (OPS), and assisting its service partners in ongoing GO-PKI operations;
• Monitoring the evolution of technology and products, assessing their strengths and vulnerabilities, and endorsing cryptography for Government use;
• Advising appropriate levels of protection to address business risks relative to identified threats, and identifying technology best suited to address such security and business requirements;
• Providing timely guidance on the procurement, deployment, and use of security products and services to ITS and the I&IT Clusters;
• Supporting procurement processes for and evaluation of cryptographic products for the OPS;
• Maintaining any relevant procedures and related documentation;
• Monitoring compliance with security requirements and obligations in conjunction with ITS and the I&IT Clusters; and
• Liaising with cryptographic and security authorities at other levels of Government.

Ontario Internal Audit

The Ontario Internal Audit Division is responsible for:

• Conducting periodic audits of pertinent activities to test compliance with security standards;
• Communicating with appropriate management about the risks identified and the severity of those risks; and
• Working with management to identify the needed management action plans to mitigate the risks noted during the course of an audit, and conducting follow-up as required.

4. Acknowledgements

Editors

Contributors

Reviewers

The following groups have reviewed this standard:

Security Architecture Domain Working Group

5. Document history

Endorsed: 2008-09-17

• IT Standards Council

Approved: 2008-10-16

• Architecture Review Board. Version 1.0

Revised: 2008-10-24

• Updated to enhance technical specificity; document version set to Version 1.1
  • Document aligned with GO-ITS 25.11
  • Updated protocol versions and requirements
  • Updated definitions and added glossary items

Revised: 2012-03-09

• General update; document version set to Version 1.2
  • Updated roles and responsibilities
  • Updated hyperlinks to directives and policies and document titles
  • Updated ISO/IEC references
  • Updated protocol versions and requirements
  • Updated Appendix A table

Revised: 2012-06-12

• Minor update as per SADWG input
  • Clarified wording
  • Adjusted presentation of Appendix A table
  • Updated roles and responsibilities

Revised: 2012-11-15

• Approved by Information Technology Executive Leadership Council (ITELC). Approved document version number set to 1.2
  • Updated document information

Revised: 2015-01-19

• General update; document version set to Version 1.3
  • Updated roles and responsibilities
  • Updated ISO/IEC content for reference to 27002:2013
  • Updated Appendix A for accuracy

Revised: 2016-01-27

• General update; document version set to Version 1.4
  • Reworded RNG/PRNG, TLS, and operating mode guidance
  • Updated Appendix A table
  • Editorial, format, glossary updates, ISO/IEC 19790:2012 revision update
  • Version control updates

Endorsed: 2016-02-03

• Architecture Review Board

Approved: 2016-03-31

• IT Executive Leadership Council

Revised: 2020-04-28

• General update; document version set to Version 1.5
  • HSM Guidance, agility/threats guidance
  • Updated ISO/IEC, IEEE, FIPS/NIST, RFC references
  • Updated Appendix A table
  • Editorial, format, glossary updates, updates to informative references
  • AR Review input/amendments

Endorsed: 2020-05-06

• Architecture Review Board

Approved: 2020-06-18

• IT Executive Leadership Council

6. Appendix A: Approved algorithms and protocols

Cryptographic algorithms

The cryptographic algorithms, key lengths, and operating modes approved for Government of Ontario use are listed below, including those required for high-risk^{footnote 10[10]} situations as determined by a TRA^{footnote 11[11]}. When determining the cryptographic requirements for the system, consideration must be given not only to the present extent of identified risk, but also the anticipated lifetime of the system and resulting retention of associated information.

Table 1: Approved cryptographic algorithms and minimum strengths / key lengths

Modes of operation

Various modes of operation may be used for symmetric block cipher algorithms. Many of these modes are defined in NIST SP800-38A. Consult additional NIST Cryptographic Toolkit references for this document for more information on these and additional and/or emerging modes.

The Electronic Codebook (ECB) mode of operation must not be used. Caution must be exercised and appropriate modes deployed if the mode of operation for a block cipher is to be manually determined or selected within a given system.

Should concerns exist regarding the AES Cipher Block Chaining (CBC) mode and a particular implementation or protocol, an alternate, endorsed mode such as the Galois/Counter mode (GCM) of operation, or a ciphertext stealing mode (per NIST SP 800-38A addenda)^{footnote 14[14]}, should be used instead of CBC mode. Due to known issues, caution is also recommended regarding the strong need to avoid repeating IVs with a given key, or encrypting more than 2⁶⁴ blocks with a given key (2³², if IVs are random), when using GCM.

Approved modes of operation for authentication and confidentiality are listed under Message Authentication Codes in the table above. More information is also available from the Modes of Operation sections of the NIST Cryptographic Toolkit site, included in the references for this document. For storage implementations, the XTS-AES (NIST SP 800-38E, IEEE P1619) mode for storage is also endorsed for use.

Cyber Security Division monitors the evolution of modes of operation and must be consulted prior to the deployment of new and/or novel modes.

Approved key establishment and exchange protocol implementations

With the exception of GO-PKI and related infrastructure, the following implementations of asymmetric protocols should be used for the derivation, agreement, or exchange of a symmetric key for the encryption of subsequent network communications:

• Secure Shell protocol 2.0 or newer/stronger;
• Transport Layer Security (TLS) v1.2, v1.3 (e.g., DHE/ECDHE), or newer/stronger;
• Internet Key Exchange v2 (used by Internet Protocol Security [IPsec]); and
• Special purpose protocols endorsed by CSD for specific use and/or high-risk environments.

Key establishment should use NIST SP 800-56A and RSA-based NIST SP 800-56B schemes accepted by industry. When these schemes are used, their associated security strength parameters must be consistent with their relevant requirements or equivalents in Appendix A (“Asymmetric Cryptography”), including parameters for high-risk situations.

TLS support and implementation

Government of Ontario Internet clients, browsers, applications, and systems must support TLS. TLS versions 1.2 and 1.3 should be preferred.

The SSL protocol must not be specified for use as a safeguard, as it does not provide for acceptable levels of security, and suffers from documented weaknesses. Some early versions of TLS also contain weaknesses.

TLS cipher suite selection must be performed in a manner such that all components of the cipher suite satisfy the requirements of the Approved cryptographic algorithms and minimum key lengths table published in this document (relative to the sensitivity of the information being handled by the TLS session). Client or server connections requesting weaker protocols or a reduction in the strength of cryptographic systems must be denied. Attempts to initiate protocol version downgrades should be carefully negotiated to deter the use of downgrades and renegotiation as an attack technique. If TLS 1.3 is not used, cipher suites which include AEAD (such as, but not limited to, AES-GCM cipher suites) should be preferred for use with TLS 1.2 implementations.

Implementations of various network services may use the above (or similar) protocols to establish a secure connection; these protocols should be identified, and only used in conjunction with cryptography that satisfies the Approved cryptographic algorithms and minimum strengths / key lengths table published in this document.

7. Appendix B: definitions

Access: The ability to enter a physical area or use a resource, which may include viewing, adding, modifying, or deleting data, and/or executing applications (running computer programs).

Access controls: Procedures/devices designed to restrict entry to a physical area (physical access controls) or to limit use of a computer/communications system or stored data (logical access controls).

Authenticate: To establish confidence in the reliability of an assertion (e.g., use of passwords, access cards, or other credentials), and verify the claimed identity of a user prior to granting access.

Authentication: A process of testing assertions to establish a level of confidence (assurance) in their reliability as an indication of identity.

Authorization: The procedural and technical allowance of specific privileges and access.

Availability: The degree of readiness expected of information systems and IT resources to deliver an appropriate and timely level of service, regardless of circumstances.

Block cipher: A cryptographic algorithm that processes fixed units of information as plaintext input, and produces encrypted output of that length via the use of a static key (e.g., AES).

Canadian Centre for Cyber Security: A “unified source” of cyber security advice in Canada founded in 2018, which acts as a national response hub and source of GC documentation and training.

Certificate: The public key of an entity, together with other information, made authentic when digitally signed with the private key of the CA that issued it. Certificate formats are described within the X.509 and RFC 2459 / RFC 5280 specifications.

Cloud Service Provider: The party, possibly a third party and/or vendor, operating, maintaining and providing a Cloud Service to a customer.

Communications Security Establishment: “Canada’s national cryptologic agency … [it] provides the Government of Canada with two key services: foreign signals intelligence in support of defence and foreign policy, and the protection of electronic information and communication …” [from the CSE public web site].

Confidentiality: Ensuring that information is accessible only to those authorized to have access. Unauthorized disclosure of the information constitutes a loss of confidentiality. The protection of confidentiality must be consistent with the sensitivity of information and legislative requirements (e.g., FIPPA, PHIPA).

Cryptography: The discipline which embodies principles, means and methods for the transformation of data in order to hide its information content, detect unauthorized modification, or prevent its unauthorized use. Cryptography is commonly used to provide confidentiality, integrity, message authentication, identity authentication, and digital signatures.

Cryptographic algorithm: A well-defined computational procedure that takes variable inputs including a cryptographic key and produces an output.

Cryptographic key: A parameter used in conjunction with a cryptographic algorithm that determines its operation in such a way that an entity with knowledge of the key can reproduce or reverse the operation, while an entity without knowledge of the key cannot.

Data: Any formalized representation of facts, concepts or instructions suitable for communication, interpretation or processing by a person or by automatic means.

Decryption: The process of changing ciphertext (encrypted information) into plaintext using a cryptographic algorithm and key.

Digital signature: A cryptographic technique based on a uniquely related pair of keys where one key is used to create a signature (the private signing key) and the other to check the signature (the public verification key). A digital signature enables the recipient to verify the source (e.g., the signer) of a message or document and confirm its integrity.

Elliptic curve cryptography: A cryptographic design whereby the strength of the system is predicated on the demonstrated difficulty of determining points on a plane curve when defined over large finite groups. This known property of large finite fields is also referred to as the discrete logarithm problem.

Encryption: The transformation of data via cryptography into a form unreadable by anyone not in possession of the required key. It can provide for data confidentiality by keeping the information hidden from any individual or entity for which it was not intended.

Federal Information Processing Standards (FIPS): A set of standards developed by the National Institute of Standards and Technology (NIST) for use by the United States Government. FIPS deals with a wide range of computer system components, including those relating to security and assurance.

Hash function: A function that maps a bit string of arbitrary length to a fixed length bit string. Common names for the output of a hash function include hash value, hash, message digest and digital fingerprint. Approved hash functions satisfy the following properties:

• One-way: it is computationally infeasible to find any input that maps to any pre-specified output, and
• Collision resistant: it is computationally infeasible to find any two distinct inputs that map to the same output.

Hardware Security Module: A purpose-designed hardware device, typically an evaluated product, intended for secure key generation, storage, management, and cryptographic acceleration.

Identifier: A bit string that is associated with a person, device or organization. It may be an identifying name, or may be something more abstract (for example, a string consisting of an IP address and timestamp), depending on the application.

Identity authentication: A process that uses a credential(s) to verify the identity of a user who is attempting to access resources and/or services.

Information: The meaning derived from or assigned to facts or data, within a specified context.

Information technology assets: Those resources (hardware, software, data etc.) associated with the creation, storage, processing and communication of information in the form of data, text, image and voice.

Integrity: The property that information has not been modified or deleted in an unauthorized and undetected manner.

Key escrow: an arrangement in which keys needed to decrypt encrypted data are held in escrow by a third party, such that authorized individuals may obtain them if required.

Key management: The activities involving the handling of cryptographic keys and other related security parameters during the entire life cycle of the keys, including their generation, storage, establishment, entry and output, and destruction.

Key Management Service: A third-party service key storage and management service that may leverage Hardware Security Modules.

Key recovery: A function in the lifecycle of keying material that uses mechanisms and processes that enable authorized entities to retrieve keying material from key backup or archive.

Key revocation: A function in the lifecycle of keying material; a process whereby a notice is made available to affected entities that keying material should be removed from operational use prior to the established expiry date for that keying material.

Managed perimeter boundary: The portion of the Government of Ontario network connected to the internal Corporate Firewall cluster interface points.

Message authentication code (MAC): A cryptographic checksum on data to detect both accidental and intentional modifications of data.

Network attached storage (NAS): A server specifically designed for handling files (rather than block data). Network-attached storage is accessible directly on the local area network (LAN) through LAN protocols such as TCP/IP. This is as opposed to storage that is internal to or directly connected to a server (e.g., via parallel SCSI cables) and only accessible from that server.

Non-repudiation: A service that enables the integrity and origin of information to be verified by a third party. This service prevents the originating entity from successfully denying involvement. Non-repudiation is supported cryptographically though the use of a digital signature created using a private key known only by the signer (the originating entity).

Password: A string of characters (letters, numbers and other symbols) that are used to authenticate an identity or to verify access authorization.

Passphrase: A lengthy string of characters intended to provide for significantly increased complexity compared to traditional passwords, in a format users can readily recall from memory.

Privacy: The ability of an individual or group to control personal information and prevent it from being used by people or for purposes other than those they consented to when they provided the information. Organizations must have controls to restrict the collection, use and/or disclosure of personal information to that authorized by the individual or group. In the case of Government organizations, legislative authority is required to collect, use, and disclose the personal information needed for the delivery of a specific program or service.

Privacy Impact Assessment: A process that assists program managers in fulfilling their responsibilities to protect privacy and for privacy risk management; PIAs are used to:

• Identify and analyze privacy-related risks;
• Avoid, eliminate or minimize negative impacts on privacy;
• Make informed policy, business, procurement, architecture and security decisions; and
• Comply with relevant privacy legislation and meet privacy-related corporate governance requirements.

Private key: A cryptographic key, used with a public key cryptographic algorithm that is uniquely associated with an entity and is not made public. In an asymmetric (public) cryptosystem, the private key is associated with a public key.

Program manager: The person responsible for the continued development, operational control, implementation, monitoring, etc. of a specific program or service within a Ministry.

Public key: A cryptographic key that is used with a public key cryptographic algorithm. The public key is uniquely associated with an entity and may be made public. In an asymmetric (public key) cryptosystem, the public key is associated with a private key. The public key may be known by anyone and, depending on the algorithm, may be used to:

• Verify a digital signature that is signed by the corresponding private key (public verification key); and/or
• Encrypt data that can be decrypted by the corresponding private key (public encryption key).

Public key certificate: A public key that has been digitally signed by the issuing organization (Certification Authority). The integrity of the public key can be confirmed by verifying the digital signature associated with it.

Responsibility: The obligation to perform a given task or tasks associated with a specific role.

Risk: An estimation of the likelihood and impact of potential events on an organization’s ability to meet its business objectives.

Safeguard: A protective and precautionary measure intended to prevent a threat agent from reducing security, or causing harm or adverse impact.

Secret key: See symmetric key.

Secure sockets layer (SSL): A deprecated protocol created to protect the confidentiality of data exchange between web applications and Internet users. SSL must be avoided, with preference given to recent TLS implementations (e.g., versions 1.2/1.3).

Security: The effort to create managed environments within which agents can only perform authorized actions and gain prescribed access, once appropriately authenticated.

Storage area network (SAN): A specialized network that provides access to high performance and highly available storage subsystems using block storage protocols. The main characteristic of a SAN is that the storage subsystems are generally available to multiple physical or virtual hosts at the same time, which makes them scalable and flexible.

Stream cipher: A cryptographic algorithm that processes a large series of bits (or pieces of information) by combining plaintext data of variable length with a key stream.

Symmetric key: A single cryptographic key (used with a symmetric key cryptographic algorithm) uniquely associated with one or more entities that must be protected from disclosure.

Symmetric key algorithm: A cryptographic algorithm that uses the same secret key (symmetric key) for all operations (e.g., encryption and decryption).

Threat risk assessment (TRA): A tool to assist Program Managers in fulfilling their responsibilities for security risk management and the development of security plans. A Threat Risk Assessment (TRA) is used to:

• Assess the sensitivity of program assets and information;
• Identify and analyse potential threats and vulnerabilities;
• Assess the level of risk taking into consideration the effectiveness of current security measures; and
• Recommend appropriate measures to protect assets and information from loss, theft, destruction, modification, or misuse.

Transport layer security (TLS): A protocol that ensures privacy/confidentiality between communicating web applications and their users on the Internet. TLS evolved from earlier Secure Sockets Layer (SSL) protocols and is now required for use.

User: A person authorized to access and use Information and Information Technology resources.

Zone: A controlled, managed environment with defined interface points that employs technical safeguards and access controls in accordance with a defined scheme. Network components and systems must be housed within an appropriate Zone, and in cases, separated from other parts of the Government of Ontario network by approved policy enforcement and access controls.

8. Appendix C: acronyms

The following abbreviations and acronyms are used in this standard:

3DES: Triple Data Encryption Standard
AEAD: Authenticated Encryption with Associated Data
AES: Advanced Encryption Standard (specified in FIPS 197)
ANSI: American National Standards Institute
CAST: A design procedure for creation of block cipher algorithms; CAST-128 and CAST-256 are such algorithms, and are described in RFC 2144 and RFC 2612 respectively
CBC: Cipher Block Chaining Mode
CCCS: Canadian Centre for Cyber Security
CCM: Counter with CBC-MAC
CMAC: Cipher-based MAC
CAVP: Cryptographic Algorithm Validation Program (NIST/CSE/CCCS effort)
CMVP: Cryptographic Module Validation Program (NIST/CSE/CCCS effort)
CSD: Cyber Security Division
CSE: Communications Security Establishment
DES: Data Encryption Standard (deprecated; do not implement)
DSA: Digital Signature Algorithm (specified in FIPS 186-3)
ECB: Electronic Codebook (a mode of operation)
ECC: Elliptic Curve Cryptography
ECDSA: Elliptic Curve Digital Signature Algorithm
EdDSA: Edwards-Curve Digital Signature Algorithm
EDE2: A 3DES mode of operation using two unique keys – not endorsed
EDE3: A 3DES mode of operation using three unique keys (more secure than EDE2)
FIPS: Federal Information Processing Standard
GCM: Galois/Counter Mode (AES)
GO-PKI: Government of Ontario Public Key Infrastructure
HMAC: Keyed-Hash Message Authentication Code (specified in FIPS 198-1)
HSM: Hardware Security Module
IEC: International Electrotechnical Commission
IKE: Internet Key Exchange
IPsec: Internet Protocol Security
ISO: International Organization for Standardization
ISC: Government of Ontario Information Sensitivity Classification
ITS: Infrastructure Technology Services
MAC: Message Authentication Code
MD5: A hash function/algorithm (deprecated; do not implement)
MGS: Ministry of Government Services
NIST: National Institute of Standards and Technology
OPS: Ontario Public Service (the employees of the Government of Ontario)
PCI: Payment Card Industry
PIA: Privacy Impact Assessment
PKI: Public Key Infrastructure
PRNG: Pseudo-random Number Generator
RNG: Random Number Generator
RSA: Rivest, Shamir, Adelman (an algorithm)
SCS: I&IT Strategy and Cyber Security Division (now Cyber Security Division)
SHA: Secure Hash Algorithm (versions 1, 2, and 3)
SSH: Secure Shell
SSL: Secure Sockets Layer (deprecated; do not implement)
STE: Security Testing and Evaluation
TLS: Transport Layer Security
TRA: Threat Risk Assessment
VPN: Virtual Private Network
XEX: XOR–encrypt–XOR
XTS: XEX-based tweaked-codebook mode with ciphertext stealing
XOR: Exclusive disjunction / exclusive OR

9. Appendix D: Additional information

Type of standard

Implementation or Process Standards – requirements or specifications, which may include best practices and guidance, for the implementation of a technology or the performance of an activity related to the use of technology, applicable throughout the provincial government (e.g., mandatory O/S  configuration requirements, security procedures, change management procedures, web page design requirements).

Publication

Please indicate if this standard should be restricted to publishing on the Internal (Intranet) IT Standards web site or whether it is intended for publishing on the public (internet) Government of Ontario IT Standards web site.

Consultation

Impacts to standards

List any existing GO-ITS that may be impacted or associated with this standard.

GO-ITS 25.0 is impacted since other GO-ITS 25 documents supplement this document.">

Impacts to existing environment

List any significant impacts this standard may have on the existing I&IT environment.

References

Management and Use of Information & Information Technology (I&IT) Directive
Corporate Policy on Information and Information Technology (I&IT) Security
Government of Ontario Information Sensitivity Classification Policy
FIPS standards: FIPS Publications
IAB, IETF, IRTF, etc. RFCs:

RFC 2144 The CAST-128 Encryption Algorithm
RFC 2612 The CAST-256 Encryption Algorithm
RFC 2459 Internet X.509 Public Key Infrastructure Certificate and CRL Profile
RFC 4543 The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
RFC 7748 Elliptic Curves for Security
RFC 7905 ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)
RFC 8032 Edwards-Curve Digital Signature Algorithm (EdDSA)
RFC 8439 ChaCha20 and Poly1305 for IETF Protocols
RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3

ISO/IEC Standards: ISO Standards
NIST/CSE CAVP: Cryptographic Algorithm Validation Program (CAVP)
NIST/CSE CMVP: Cryptographic Module Validation Program (CMVP)
NIST Cryptographic Toolkit: Current Modes of Operation
NIST Cryptographic Toolkit: Modes of Operation in Development: Modes Development
NIST Special Publications:

800-38A Recommendation for Block Cipher Modes of Operation – Methods and Techniques
800-38A Addenda – Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode
800-38B Recommendation for Block Cipher Modes of Operation: the CMAC Mode of Authentication
800-38C Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality
800-38D Recommendation for Block Cipher Modes of Operation: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC
800-38E Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices
800-56A Rev. 3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography
800-56B Rev. 2 Recommendation for Pair-Wise Key-Establishment Using Integer Factorization Cryptography
800-57 Recommendation for Key Management – Parts 1-3
800-63-1 Electronic Authentication Guideline
800-107 Recommendation for Applications Using Approved Hash Algorithms
800-131A Rev. 2 Transitioning the Use of Cryptographic Algorithms and Key Lengths

PCI PTS HSM Modular Security Requirements Version 3.0