Government of Ontario IT Standard (GO

____________________________________________________________________________
Government of Ontario IT Standard (GO-ITS)
Number 25.12
Security Requirements for the Use of Cryptography
Version #: 1.2
Status: Approved
Prepared under the delegated authority of the Management Board of Cabinet
UNCLASSIFIED
© Queen's Printer for Ontario, 2012
Last Review Date: 2012-11-15
GO-ITS 25.12
Status: Approved
Version 1.2
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 Services (MGS)
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:
Intranet: http://intra.collaboration.gov.on.ca/mgs/occio/occto/our-services/technologyadoption/technical-standards-1/approved-go-its-standards/
Internet: http://www.ontario.ca/itstandards/
Summary
The Corporate Policy on Information and Information Technology Security requires 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 MGS Corporate Security Branch (CSB) is the cryptographic authority for the Government of
Ontario.
UNCLASSIFIED
2
GO-ITS 25.12
Status: Approved
Version 1.2
Version control and change management
Date
Version
Author
Comment
September 17, 2008
1.0
Tim Dafoe, CSB
Endorsed by IT Standards Council
October 16, 2008
1.0
Tim Dafoe, CSB
Approved by Architecture Review Board
October 24, 2008
1.1
Tim Dafoe, CSB
Changes per document history
March 9, 2012
Tim Dafoe, CSB
Updated, changes per document history
June 12, 2012
Tim Dafoe, CSB
Updated as per SADWG input
Tim Dafoe, CSB
Updates approved by Information Technology
Executive Leadership Council (ITELC).
Approved document version number set to 1.2
November 15, 2012
1.2
Ongoing ownership and responsibility for maintenance and evolution of this document resides
with the Corporate Security Branch, Office of the Corporate Chief Information Officer. The
Corporate Security Branch 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 Corporate Security Branch staff:
Contact 1
Contact 2
Name/Title
Charlotte Ward, Manager, Policy &
Administration
Tim Dafoe, Senior Security Policy
Advisor
Organization/Ministry
Ministry of Government Services
Ministry of Government Services
Division
OCCIO
OCCIO
Branch
Corporate Security Branch
Corporate Security Branch
Section/Unit
Policy & Administration
Security Policy
Office Phone
(416) 327-9385
(416) 327-1260
E-mail
Charlotte.Ward@ontario.ca
Tim.Dafoe@ontario.ca
UNCLASSIFIED
3
GO-ITS 25.12
Status: Approved
Version 1.2
Table of Contents
1.
1.1
1.2
1.3
1.4
1.5
1.6
2.
2.1
2.2
2.3
2.4
3.
4.
5.
6.
7.
8.
9.
INTRODUCTION ................................................................................................................ 5
Purpose of the standard .................................................................................................. 5
Terms .............................................................................................................................. 5
Application and scope ..................................................................................................... 5
Out of scope .................................................................................................................... 6
Background ..................................................................................................................... 6
Principles......................................................................................................................... 8
REQUIREMENTS ............................................................................................................... 9
Education and training ..................................................................................................... 9
Information in storage ...................................................................................................... 9
Communications security ...............................................................................................10
Management of cryptography .........................................................................................11
RESPONSIBILITIES ..........................................................................................................15
ACKNOWLEDGEMENTS ..................................................................................................18
DOCUMENT HISTORY .....................................................................................................19
APPENDIX A: APPROVED ALGORITHMS AND PROTOCOLS ......................................19
APPENDIX B: DEFINITIONS ............................................................................................23
APPENDIX C: ACRONYMS ..............................................................................................27
APPENDIX D: ADDITIONAL INFORMATION ...................................................................29
UNCLASSIFIED
4
GO-ITS 25.12
Status: Approved
Version 1.2
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 the section “Information systems acquisition, development and maintenance”
from the ISO/IEC 27002:2005 code of practice, and technical requirements within are stated
in accordance with both ISO/IEC 27002:2005 recommendations and external guidance
received by CSB.
1.2 Terms
Within this document, certain wording conventions are followed. There are precise
requirements and obligations associated with the following terms:
Must
The requirement is mandatory. Without it, the system is not considered secure.
Should
The requirement ought to be adhered to, unless exigent business needs dictate
otherwise and the full implications of non-compliance are understood. All
exceptions are to be documented and approved in writing by management,
identifying the rationale for the exception to standard practice.
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, key
lengths, and related protocols). Please consult Appendix A of this document for specific
information.
UNCLASSIFIED
5
GO-ITS 25.12
Status: Approved
Version 1.2
For security involving sensitive information1, 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, 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; 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 MGS Corporate Security Branch 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 describe specific password or pass phrase
requirements for the protection of keys 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.,
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
Information Security and Privacy Classification (ISPC) 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:2005 code of practice.
Cryptography is also commonly used to provide for reliable message authentication2, and
enable the use of secure digital signatures3. Proper use of cryptography produces a result
1
As determined via the Government’s Information Security and Privacy Classification (ISPC) policy
(http://intra.ops.myops.gov.on.ca/cms/tiles.nsf/(vwReadResourcesByRefId_Content)/cpd2008.08.18.14.3
4.52.PSU_res/$File/InformationSecurity&PrivacyClassificationPolicy-Aug05.pdf) and/or TRA process.
2
Message authentication codes involve the use of cryptography to detect both accidental (e.g., errors)
and intentional (e.g., attacks) modifications to transmitted information.
UNCLASSIFIED
6
GO-ITS 25.12
Status: Approved
Version 1.2
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 both to
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, useful 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 for 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 protect the transmission of symmetric keys over insecure media, which are
used in turn to quickly encrypt large amounts of information (via 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).
3
Digital signatures are used to authenticate the identity of an individual either prior to providing access to
information or services, or subsequently, to verify the author/source of a document or transaction (e.g.,
non-repudiation). Digital signatures can also be used to detect unauthorized changes to a document or
transaction (e.g., electronic payments, funds transfers, contracts).
UNCLASSIFIED
7
GO-ITS 25.12
Status: Approved
Version 1.2
1.6 Principles
The following guiding principles support, and are stated in accordance with, the Corporate
Policy on Information and Information Technology Security and the ISPC policy:
4

Cryptography alone cannot address the entire range of security concerns associated
with the storage, processing, and transmission of sensitive information4; 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 Government of Ontario retains ownership of cryptographic keys that it has
created, or otherwise relies upon, to protect Government information;

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;

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;

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;

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

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.
Sensitive information refers to sensitivity as defined within ISPC policy.
UNCLASSIFIED
8
GO-ITS 25.12
Status: Approved
Version 1.2
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., ISPC Policy) 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 ISPC policy and procedures should be encrypted in storage, or when operationally
feasible, stored as a hash5. The Privacy Impact Assessment (PIA) or TRA for the relevant
program area may also indicate that an enhanced level of cryptographic protection is
required for high-risk environments (please consult Appendix A of this document).
Encrypted sensitive information held as data in storage for more than two years6 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 or through other
means). Digital signature implementations should include the use and checking of
timestamps generated from a validated 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:
5
Hashes are commonly used to store password values, but can also be considered for other types of
sensitive information if a comparison operation with a hash value will be sufficient for the business
operation, and the information itself need not be stored. Additional measures (e.g., salting, iteration) may
be required to provide for adequate security when this technique is used.
6
When systems are migrated to new technologies, compatibility issues may be introduced for encrypted
information in long-term storage (e.g., archives); such eventualities should be identified and addressed.
UNCLASSIFIED
9
GO-ITS 25.12
Status: Approved
Version 1.2
2.2.1 Mobile devices
Government of Ontario mobile devices (e.g., portable computers 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 centrally managed. Such systems must be
endorsed by CSB 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.
2.2.2 Desktop computers
Government desktop computers are typically not adequately protected against high
resource threat agents (e.g., a focused and determined electronic attacker such as an
organized, funded group). Their local storage capacity should not be used to store
sensitive information.
If operations 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 CSB for this purpose, and additional security measures may be
required for high-risk environments.
2.2.3 Data repositories
Sensitive information must be encrypted at the data field level before it is written to a
data repository, when such protection is required by ISPC or a TRA. When operationally
feasible, hashes of sensitive information should be used for comparisons and verification
(thereby avoiding storage of the actual sensitive information). Such hash values must be
generated using a secure hash function endorsed by CSB (see Appendix A).
When deploying encryption within data repositories, careful consideration should be
given to any limitations present within the encryption options, and any impact on
software development, deployment, performance, administration, or legal duties.
2.3 Communications security
Sensitive information must be safeguarded when transmitted.
UNCLASSIFIED
10
GO-ITS 25.12
Status: Approved
Version 1.2
2.3.1 General transmission and communication
Sensitive information 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 do not employ wireless technology).
Wireless transfers of Government of Ontario information using lightweight protocols
and/or external services (e.g., mobile wireless data7, 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 CSB for use. Adequate
cryptographic functionality is present in some wireless protocols, and 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 a digital
signature upon receipt. This functionality is present in many such systems, and should
be investigated prior to deployment.
Digital signatures must be used if the identified integrity requirements (e.g., documented
in a TRA) include support for high-risk environments and/or non-repudiation, even if
sensitive data does not cross the 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 time source.
2.3.2 Mainframe communications
Mainframe SNA traffic (such as SNA over IP) must be encrypted within the Government
of Ontario if the communication includes sensitive information, and does not occur within
the same designated Zone (e.g., via a dedicated physical connection).
2.4 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.
7
Wireless cellular data communications (e.g., those associated with GSM, CDMA protocols) do not
provide for an adequate degree of communications security, and must not be relied upon to safeguard
confidentiality.
UNCLASSIFIED
11
GO-ITS 25.12
Status: Approved
Version 1.2
2.4.1 Procurement of cryptography
All products supporting cryptography that are procured for use within the Government of
Ontario 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, and ISO/IEC 19790:2006).
Cryptographic products must be configurable using administrator-controlled rules
including:


Specific cryptographic algorithm(s), mode of operation, and the minimum
effective key lengths to be used; and
Password and authentication schemes that meet the security requirements
described in GO-ITS 25.15 Security Requirements for Password Management
and Use.
2.4.2 Deployment of cryptography
Cryptographic mechanisms within the Government must be deployed and configured in
compliance with the requirements in this document (please consult Appendix A),
applicable implementation standards, and any requirements mandated through the TRA
process. CSB should be consulted to determine how best to address security
requirements.
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 CSB.
All applications and services using cryptography must:



Employ a random number generation (RNG) or high-quality pseudo-random
number generation (PRNG) implementation considered (and validated, in highrisk environments) to be cryptographically adequate (consult CMVP materials,
FIPS 140-2 and ISO/IEC 18031:2011 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 provide access to sensitive information must undergo
security testing and evaluation (STE) prior to implementation, and when changes are
made that may introduce vulnerabilities.
2.4.3 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, 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
UNCLASSIFIED
12
GO-ITS 25.12
Status: Approved
Version 1.2
acquired via peer-reviewed, industry standard products, software, or services endorsed
by CSB. Such products, software, and services must meet the requirements in this
document, and be procured through appropriate channels.
2.4.4 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, 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 a digital signature
or MAC).
Keys or certificates must be generated by the Government of Ontario, or supplied by an
organization endorsed by CSB as a provider of cryptographic services (see the section
entitled Management of Cryptographic Services). Keys should be generated via a secure
module (e.g., FIPS 140-2 level 2 or better) where possible.
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.
2.4.5 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, re-keying requirements, key generation, key
assignment, revocation processes (including related timelines), secure distribution, and
secure destruction of cryptographic material.
UNCLASSIFIED
13
GO-ITS 25.12
Status: Approved
Version 1.2
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 (e.g., separation of duties) and
must possess a valid Government of Ontario Personnel Screening result.
2.4.6 Recovery of encrypted information
The cryptography service 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, 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 back-ups.
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 CSB 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).
2.4.7 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 ISPC).
UNCLASSIFIED
14
GO-ITS 25.12
Status: Approved
Version 1.2
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 ISPC policy and operating procedures;
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
interacting with custodians;
Ensuring ISPC 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, ISPC, and other relevant policies and
standards;
Ensuring that agreements with consulting firms and 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.
UNCLASSIFIED
15
GO-ITS 25.12
Status: Approved
Version 1.2
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 ISPC
requirements;
Working with relevant CSB 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 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;
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:
UNCLASSIFIED
16
GO-ITS 25.12



Status: Approved
Version 1.2
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.
Corporate Security Branch
The MGS Corporate Security Branch is responsible for:

Authorship of security policies and standards for the Government of Ontario, subject to
appropriate approval;

Securely managing and operating the Certificate Authority for the Government of
Ontario PKI service (GO-PKI) for the Ontario Public Service (OPS) and its service
partners;

Monitoring the evolution of technology and products, assessing their strengths and
vulnerabilities, and endorsing cryptography for Government use;

Supporting procurement processes for and evaluation of cryptographic products for the
OPS;

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 deployment and use of security products and
services to OCCIO ITS and the I&IT Clusters;

Maintaining relevant policies and procedures, such as the Information Security and
Privacy Policy and related documentation;

Monitoring compliance with security requirements and obligations in conjunction with
OCCIO 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.
UNCLASSIFIED
17
GO-ITS 25.12
Status: Approved
Version 1.2
4. ACKNOWLEDGEMENTS
4.1 Editors
Full Name
Tim Dafoe
Cluster, Ministry and/or Area
MGS Corporate Security Branch
4.2 Contributors
Full Name
Earl Kuntz
Cluster, Ministry and/or Area
MGS Corporate Security Branch
4.3 Consultations
The following individuals were consulted:
Charlotte Ward, MGS Corporate Security Branch
Muriel Petersen, MGS OCIPO
Lynette Craig, MGS OCIPO
Brady Thompson, MGS OCIPO
4.4 Reviewers
The following groups have reviewed this standard:
Security Architecture Domain Working Group
UNCLASSIFIED
18
Pat Antliff, MGS Corporate Security Branch
GO-ITS 25.12
Status: Approved
Version 1.2
5. DOCUMENT HISTORY
Endorsed: 2008-09-17

IT Standards Council
Approved: 2008-10-16

Architecture Review Board
Revised: 2008-10-24

Updated to enhance technical specificity; document version set to Version 1.1:
o
Document aligned with GO-ITS 25.11
o
Updated protocol versions and requirements
o
Updated definitions and added glossary items
Revised: 2012-03-09

General update; document version set to Version 1.2:
o
Updated roles and responsibilities
o
Updated hyperlinks to directives and policies and document titles
o
Updated ISO/IEC references
o
Updated protocol versions and requirements
o
Updated Appendix A table
Revised: 2012-06-12

Minor update as per SADWG input
o
Clarified wording
o
Adjusted presentation of Appendix A table
o
Updated roles and responsibilities
Revised: 2012-11-15

Approved by Information Technology Executive Leadership Council (ITELC). Approved
document version number set to 1.2
o
Updated document information
UNCLASSIFIED
19
GO-ITS 25.12
Status: Approved
Version 1.2
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 situations as determined by a
TRA. 8 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
Approved
Algorithms
Type
Triple DES
(3DES)
(FIPS 46-3 WITHDRAWN)
Symmetric
Cryptography
Required Strength
Minimum
Requirement
High-risk
Situations
Use AES for all new implementations.
Must use 3
distinct 56 bit
keys (EDE3)
Should not use CAST5-128 (RFC 2144) is an acceptable alternative to
AES-128 if the latter presents an implementation
3DES
challenge for a particular system.
Applications using 3DES or unapproved algorithms (e.g.,
DES) should migrate to AES wherever practical.
128
256
64 bit DES keys are effectively 56 bits long; this
reduction in effective length similarly impacts 3DES
implementations and should be considered prior to
deployment.
(ANSI X9.31 /
FIPS 186-3)
2048
3072
Non-compliant implementations should be migrated
wherever practical.
DSA
L = 2048
L = 3072
N = 224
N = 256
P-256
P-384
B-283
B-409
AES
(FIPS 197)
RSA
(FIPS 186-3 /
(ANSI X9.42)
Asymmetric
Cryptography
ECC
(ANSI X9.62 &
9.63 /
FIPS 186-3 / SP
800-57)
Secure Hash
Functions
Digital
Signatures
and Hashes
SHA-256 or
stronger
SHA-256 or
stronger
The symbols “L” and “N” refer to public and private DSA
key lengths respectively.
The minimum key length for Elliptic Curve systems
depends on whether the curve is defined over a prime
(P) or binary (B) field (e.g., P-xxx, B-xxx). Deploy
validated and cryptographically secure implementations
only. Consult CSB for use of other curves.
Legacy hash function implementations (e.g., MD5)
must be migrated whenever practical to SHA-256 or
stronger. MD5 should be considered deprecated.
New implementations should not use SHA-1.
The risk of hash collisions must be assessed and
addressed appropriately.
(FIPS 180-4)
8
Additional Requirements / Comments
Special purpose cryptography may be endorsed by CSB for specific use and/or high-risk environments.
UNCLASSIFIED
20
GO-ITS 25.12
Status: Approved
Approved
Algorithms
Type
Required Strength
Minimum
Requirement
High-risk
Situations
SHA-256 or
stronger
SHA-256 or
stronger
HMAC
(ANSI X9.71-2000
/ FIPS 198-1)
Message
Authentication
Codes
Consult Symmetric
CBC-MAC / Cryptography entries for
CMAC / CCM approved key lengths.
(SP 800-38
A/B/C)
Version 1.2
AES should be used as the
block cipher for MAC operation
wherever practical.
Additional Requirements / Comments
New HMAC implementations should not be based on
SHA-1.
The cryptographic strength of HMAC depends on the
underlying hash function.
The same symmetric key should not be used for
encryption and MAC operations that are performed
separately.
CCM is a component within the 802.11i standard for
wireless LAN authentication & encryption.
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 (please consult additional references for this document
for more information on these and additional modes).
The Electronic Codebook (ECB) mode of operation must not be used. Caution must be
exercised and an appropriate mode deployed if the mode of operation for a block cipher must
be manually determined or selected within a given system.
Approved modes of operation for authentication and confidentiality are listed under Message
Authentication Codes in the table above. More information is also available from Modes of
Operation sections of the NIST Cryptographic Toolkit site.
The Corporate Security Branch monitors the evolution of modes of operation and must be
consulted prior to the deployment of new modes.
Approved key establishment and exchange protocol implementations
With the exception of GO-PKI and related infrastructure, the following implementations of
asymmetric key protocols should be used for the establishment and exchange of a symmetric
key for the encryption of subsequent communications:

Secure Shell protocol 2.0 or newer/stronger;

Secure Sockets Layer (SSL) v3.0 or newer/stronger (with preference for TLS);

Transport Layer Security (TLS) v1.2 or newer/stronger (preferred);

Wireless TLS;

Internet Key Exchange (used by Internet Protocol Security [IPsec]); and

Special purpose protocols endorsed by CSB for specific use and/or high-risk environments.
UNCLASSIFIED
21
GO-ITS 25.12
Status: Approved
Version 1.2
TLS/SSL support and implementation
Government supplied Internet clients / browsers must support TLS. Previous versions of SSL
should not be supported (with preference given to current TLS implementations) as they do not
provide for acceptable levels of security and/or suffer from documented weaknesses. More
recent versions of these protocols should be used as they become validated and implemented.
The selection of TLS/SSL cipher suites 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 data being passed via the TLS/SSL session). Client or server connections requesting
weaker protocols or a reduction in the strength of cryptographic systems must be denied.
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.
UNCLASSIFIED
22
GO-ITS 25.12
Status: Approved
Version 1.2
6. 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).
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 specifications.
Communications Security Establishment Canada: “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 CSEC 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
UNCLASSIFIED
23
GO-ITS 25.12
Status: Approved
Version 1.2
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.
FIPS: (Federal Information Processing Standards): 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.
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 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.
UNCLASSIFIED
24
GO-ITS 25.12
Status: Approved
Version 1.2
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.
Pass phrase: 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 and use the personal
information needed for the delivery of a specific program or service.
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.
Secret key: See symmetric key.
UNCLASSIFIED
25
GO-ITS 25.12
Status: Approved
Version 1.2
Secure sockets layer (SSL): A protocol that protects the confidentiality of data exchange
between applications and users on the Internet. Early versions of SSL should be avoided (e.g.,
prior to SSL 3.2), and preference given to TLS implementations.
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 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 (e.g., RC4).
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 between communicating
applications and their users on the Internet. TLS evolved from earlier Secure Sockets Layer
(SSL) protocols, and is preferred over previous SSL versions.
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.
UNCLASSIFIED
26
GO-ITS 25.12
Status: Approved
Version 1.2
7. APPENDIX C: ACRONYMS
The following abbreviations and acronyms are used in this standard:
3DES: Triple Data Encryption Standard
AES: Advanced Encryption Standard (specified in FIPS 197)
ANSI: American National Standards Institute
CMAC: Cipher-based MAC
CAVP: Cryptographic Algorithm Validation Program (NIST/CSEC effort)
CMVP: Cryptographic Module Validation Program (NIST/CSEC effort)
CSEC: Communications Security Establishment Canada
CSB: Corporate Security Branch (MGS)
DES: Data Encryption Standard (deprecated; do not implement)
DSA: Digital Signature Algorithm (specified in FIPS 186-3)
ECB: Electronic Codebook (a mode of operation)
EDE2: A 3DES mode of operation using two unique keys
EDE3: A 3DES mode of operation using three unique keys (more secure than EDE2)
FIPS: Federal Information Processing Standard
GO-PKI: Government of Ontario Public Key Infrastructure
HMAC: Keyed-Hash Message Authentication Code (specified in FIPS 198)
IEC:
International Electrotechnical Commission
IPsec: Internet Protocol Security
ISO:
International Organization for Standardization
ISPC: Government of Ontario Information Security and Privacy Classification Policy
ITS:
Infrastructure Technology Services
MAC: Message Authentication Code
MGS: Ministry of Government Services
NIST: National Institute of Standards and Technology
OPS: Ontario Public Service (the employees of the Government of Ontario)
PDA: Personal Digital Assistant (e.g., Palm, RIM Blackberry)
PIA:
Privacy Impact Assessment
PKI:
Public Key Infrastructure
RSA: Rivest, Shamir, Adelman (an algorithm)
SHA: Secure Hash Algorithm
SNA: Systems Network Architecture (an IBM networking protocol for mainframes)
SSH: Secure Shell
UNCLASSIFIED
27
GO-ITS 25.12
Status: Approved
SSL: Secure Socket Layer
STE: Security Testing and Evaluation
TLS:
Transport Layer Security
TRA: Threat Risk Assessment
VPN: Virtual Private Network
UNCLASSIFIED
28
Version 1.2
GO-ITS 25.12
Status: Approved
Version 1.2
9. APPENDIX D: ADDITIONAL INFORMATION
Type of standard
Check
One

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).

Information Standard – specifications for a data format (e.g. XML schema, metadata,
and/or related data models)

Technical Standard - networking and communications specifications, protocols,
interfaces (API’s) (e.g., standards adopted from recognized standards development
organizations such as W3C, OASIS or IETF such as TCP/IP, XML, SOAP, etc.)
Architecture Standard – application patterns, architecture and standards principles
governing the design and technology decisions for the development of major enterprise
applications


Product Standard – an enterprise-wide product which is mandatory for use such as a
single corporate-wide application, which all ministries and agencies use to record and
access their HR information.
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.
Check
One
UNCLASSIFIED
Publish as Internal or External

Internal Standard

External Standard
29
GO-ITS 25.12
Status: Approved
Version 1.2
Consultation
Check
Date:
(month/year)
Area

Strategy, Policy and Planning Branch, ICS

Controllership Branch, (Corporate Architecture) ICS

Corporate Security Branch

Information Privacy and Archives (IPA)
Corporate ACT and Domain Working Groups

-
Information Architecture Domain (IADWG)

-
Technology Architecture Domain (TADWG)

-
Application Architecture Domain (AADWG)

-
Security Architecture Working Group (SAWG)


Infrastructure Consolidation projects:
- Enterprise Email Services
- Servers and Data Centres
- Desktop Management
- Service Management
IT Standards Council (ITSC)
UNCLASSIFIED
30
Sept. 17, 2008
GO-ITS 25.12
Status: Approved
Version 1.2
Impacts to standards
List any existing GO-ITS that may be impacted or associated with this standard.
GO-ITS #
Describe Impact
GO-ITS 25.0
Other GO-ITS 25 documents
supplement this document.
Recommended Action (or page
number where details can be
found)
Impacts to existing environment
List any significant impacts this standard may have on the existing I&IT environment.
Application(s) Describe Impact
or
Infrastructure
Impacted
Adherence to these security
All
requirements will reduce the risks to
Government I&IT resources.
All
Implementation of these security
requirements will produce some
impact due to additional complexity
and/or some increase in
computational overhead.
UNCLASSIFIED
31
Recommended Action (or page
number where details can be found)
Compliance with these requirements.
Compliance with these requirements.
GO-ITS 25.12
Status: Approved
Version 1.2
References
Management and Use of Information & Information Technology (I&IT) Directive:
http://intra.ops.myops.gov.on.ca/cms/tiles.nsf/(vwReadResourcesByRefId_Content)/cpd2008.04.11.09.46
.33.J6N_res/$File/ManagementOfITDir.pdf
Corporate Policy on Information and Information Technology (I&IT) Security:
http://intra.ops.myops.gov.on.ca/cms/tiles.nsf/(vwReadResourcesByRefId_Content)/cpd2011.08.09.10.22
.28.JV4_res/$File/corporatePolicyIandITSecurity.pdf
Information Security & Privacy Classification Policy
http://intra.ops.myops.gov.on.ca/cms/tiles.nsf/(vwReadResourcesByRefId_Content)/cpd2008.08.18.14.34
.52.PSU_res/$File/InformationSecurity&PrivacyClassificationPolicy-Aug05.pdf
ISO/IEC Standards:
http://www.iso.org
FIPS standards:
http://csrc.nist.gov/publications/fips/index.html
NIST/CSEC CAVP:
http://csrc.nist.gov/groups/STM/cavp
NIST/CSEC CMVP:
http://csrc.nist.gov/groups/STM/cmvp/index.html
NIST Cryptographic Toolkit - Current Modes of Operation:
http://csrc.nist.gov/groups/ST/toolkit/BCM/current_modes.html
NIST Cryptographic Toolkit - Modes of Operation in Development:
http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html
NIST Special Publications:
http://csrc.nist.gov/publications/PubsSPs.html
800-38A Recommendation for Block Cipher Modes of Operation – Methods and Techniques
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-57 Recommendation for Key Management – Parts 1-3
800-63-1 Electronic Authentication Guideline
Copyright
© Queen's Printer for Ontario 2012
UNCLASSIFIED
32