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 [email protected] [email protected] 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
© Copyright 2024