Cryptographic Key Ordering Manual - ITSG-13

Published date: May 2006

Table of Contents

• Foreword
• List of Figures
• List of Tables
• List of Abbreviations and Acronyms
• 1 Introduction
  • 1.1 Purpose
  • 1.2 Scope
  • 1.3 Applicability
  • 1.4 Restrictions
  • 1.5 Exceptions
  • 1.6 Document Structure
• 2 Key and Key Management Concepts
  • 2.1 Background
  • 2.2 GC EKMS Overview
    • 2.2.1 General
    • 2.2.2 Canadian Central Facility (CCF)
  • 2.3 GC EKMS Cryptographic Key
    • 2.3.1 Traditional and Modern Key
    • 2.3.2 Identification of Key
    • 2.3.3 Purposes of Cryptographic Key
    • 2.3.4 Sources of Cryptographic Key
    • 2.3.5 Applications for Cryptographic Key
    • 2.3.6 Cryptographic Key Characteristics
  • 2.4 Key Management Process
    • 2.4.1 Overview
    • 2.4.2 Identifying Requirements for Secure Communications
    • 2.4.3 Establishing a COMSEC Account
    • 2.4.4 Registration of Key Ordering Privileges
    • 2.4.5 Ordering Key
    • 2.4.6 Controlling the Use of Keys
    • 2.4.7 Replacing Key
    • 2.4.8 COMSEC Accounting
• 3 Key Ordering Roles and Responsibilities
  • 3.1 Overview
  • 3.2 Departmental Security Officer (DSO)/IT Security Coordinator (ITSC)/Departmental COMSEC Authority (DCA)
  • 3.3 Controlling Authority
  • 3.4 Traditional Key Ordering Privileges
    • 3.4.1 Ordering Privilege Manager (OPM)
    • 3.4.2 Short Title Assignment Requester (STAR)
    • 3.4.3 Authorized ID (Auth ID)
  • 3.5 Modern Key Ordering Privileges
    • 3.5.1 Key Management Authority (KMA)
    • 3.5.2 User Representative
  • 3.6 U.S. Key Ordering Privileges
    • 3.6.1 General
    • 3.6.2 U.S. Command Authority
    • 3.6.3 U.S. User Representative
• 4 Registration and Privilege Management
  • 4.1 General
    • 4.1.1 Registration
    • 4.1.2 Privilege Management
    • 4.1.3 Key Ordering
  • 4.2 Forms and Notices
  • 4.3 Appointment Certificate Form
    • 4.3.1 General
    • 4.3.2 New Appointment
    • 4.3.3 Change of Personnel
  • 4.4 STU III PER Form
    • 4.4.1 General
    • 4.4.2 Request Type
    • 4.4.3 DAO Code
    • 4.4.4 DAO Description
    • 4.4.5 EKMS Use Indicator
    • 4.4.6 Requesting Ordering Privileges for Other EKMS Accounts
    • 4.4.7 Authorized Key Type
    • 4.4.8 Maximum Key Classification
    • 4.4.9 Class 6 Codes
  • 4.5 SDNS PER Form
    • 4.5.1 General
    • 4.5.2 Request Type
    • 4.5.3 Requesting Ordering Privileges for Other EKMS IDs
    • 4.5.4 Partition Code
    • 4.5.5 Authorized Key Type
    • 4.5.6 Key Purpose
  • 4.6 MSK PER Form
    • 4.6.1 Requesting Ordering Privileges for Other EKMS IDs
    • 4.6.2 Request Type
  • 4.7 Traditional PER Form
  • 4.8 PER Confirmation/Rejection Notice (PER CRN)
  • 4.9 Ordering Privilege Notice (OPN)
• 5 Key Orders
  • 5.1 Key Ordering Process
    • 5.1.1 Overview
    • 5.1.2 Interaction with User Community to Determine Key Requirements
    • 5.1.3 Validate Security Information
    • 5.1.4 Preparation of Key Order Requests
    • 5.1.5 Submission of Key Order Requests
    • 5.1.6 Classification/Protection of Key Order Requests
    • 5.1.7 Validation of Key Order Requests
    • 5.1.8 Monitor Status of Key Order Requests
    • 5.1.9 Notification to the COMSEC Custodian
  • 5.2 STU III Key Order Request Form
    • 5.2.1 General
    • 5.2.2 EKMS Transaction Number
    • 5.2.3 Type of Key
    • 5.2.4 EKMS STU III Key Order
    • 5.2.5 Delivery Mechanism
    • 5.2.6 Classification of Key
    • 5.2.7 Class 6 Code
    • 5.2.8 DAO Code
    • 5.2.9 Additional Identification Data
    • 5.2.10 Remarks
  • 5.3 SDNS Key Order Request Form
    • 5.3.1 General
    • 5.3.2 Transaction Number
    • 5.3.3 Partition Code
    • 5.3.4 Equipment Type
    • 5.3.5 Key Type
    • 5.3.6 Access Control Schedule
    • 5.3.7 ASCII ID
    • 5.3.8 Delivery Mechanism
  • 5.4 MSK Key Order Request Form
    • 5.4.1 General
    • 5.4.2 Transaction ID
    • 5.4.3 Type of Key
    • 5.4.4 EKMS Use Indicator
    • 5.4.5 Free Form ID
  • 5.5 Traditional Key Order Request Form
    • 5.5.1 General.
    • 5.5.2 Transaction Number
    • 5.5.3 Order Types
    • 5.5.4 Short Title
    • 5.5.5 Distribution Control
    • 5.5.6 Compatible Short Title
    • 5.5.7 Authorized IDs
    • 5.5.8 Delivery Mechanism
    • 5.5.9 CRYPTO Caveat 
    • 5.5.10 Handling Restrictions
    • 5.5.11 Release
    • 5.5.12 Key Use
    • 5.5.13 Key Purpose
    • 5.5.14 Cryptonet Size
    • 5.5.15 Crypto Period
    • 5.5.16 Segment Per Edition
    • 5.5.17 Supersession Rate
    • 5.5.18 Effective Date
    • 5.5.19 In-Place Date
    • 5.5.20 Standing Order
    • 5.5.21 Edition Information
    • 5.5.22 Distribution Profile.
    • 5.5.23 Accounting Legend Code (ALC) and Rules for Transfer Report Initiating (TRI)
  • 5.6 Order Confirmation/Rejection Notice (Order CRN)
• Glossary
• Bibliography/References
• Annex A - CSEC Points of Contact
• Annex B - Directive on the Control of STU III Key for Sensitive Compartmented Information (SCI) Applications
• Annex C - Appointment Certificate
• Annex D - STU III Privilege Establishment Request (STU III PER) Form
• Annex E - SDNS Privilege Establishment Request (SDNS PER) Form
• Annex F - MSK Privilege Establishment Request (MSK PER) Form
• Annex G - Traditional Privilege Establishment Request (Traditional PER) Form.
• Annex H - Privilege Establishment Request Confirmation/Rejection Notice (PER CRN)
• Annex I - Ordering Privilege Notice (OPN)
• Annex J - STU III Key Order Request Form
• Annex K - SDNS Key Order Request Form
• Annex L - MSK Key Order Request Form
• Annex M - Traditional Key Order Request Form

Foreword

The Cryptographic Key Ordering Manual (ITSG-13) is an unclassified publication issued under the authority of the Chief, Communications Security Establishment (CSEC). CSE, as the lead agency for cryptography in the Government of Canada (GC), is responsible for approving the generation and use of cryptographic equipment and supplying keying material and related documentation to federal government departments that handle classified and designated information, and to industry where a government contract or federal sponsorship or partnership exists.

This publication is effective upon receipt and supersedes the STU III Key Management Plan (CID/01/13) dated October 1994 and the Directive on the Control of STU III Key for SCI Applications (NITSM 4/90) dated November 1990.

Suggestions for amendments or requests for additional information should be forwarded through your departmental Communications Security channels to the Head, Cryptomaterial Management and Assistance Center (CMAC) at CSE.

Requests for additional copies, changes in distribution of this publication, or for copies of other referenced publications, should be directed to the Head, CMAC at CSE by e-mail at cmac-camc@cse-cst.gc.ca or call 613-991-8826.

___________________________

Sue Greaves
Director, IT Security Mission Management

© 2006 Government of Canada, Communications Security Establishment (CSEC)
P.O. Box 9703, Terminal, Ottawa, Ontario, Canada, K1G 3Z4

This publication may be reproduced verbatim, in its entirety, without charge, for educational and personal purposes only. However, written permission from CSEC is required for use of the material in edited or excerpted form, or for any commercial purpose.

List of Figures

• Figure 1 - GC EKMS
• Figure 2 - Key Management Functions
• Figure 3 - Ordering Privilege Hierarchy
• Figure 4 - Registration of Modern Key Ordering Privileges
• Figure 5 - Registration KMA/OPM
• Figure 6 - Registration User Representative/STAR
• Figure 7 - Privilege Management - PER Rejected by the CMAC
• Figure 8 - Key Ordering Process

List of Tables

• Table 1 - STU III Key Short Title Examples
• Table 2 - SDNS Key Short Title Examples
• Table 3 - MSK Key Short Title Examples
• Table 4 - Traditional Key Short Title Examples
• Table 5 - Examples of Key Material Editions
• Table 6 - Registration and Privilege Management Request Forms
• Table 7 - Key Order Request Forms and Notices

List of Abbreviations and Acronyms

ALC

Accounting Legend Code

ASCII

American Standard Code for Information Exchange

Auth ID

Authorized Identification

BET

Bulk Encrypted Transaction

CBI

Certificate Based Infrastructure

CCD

Canadian Cryptographic Doctrine

CCEB

Combined Communications Electronic Board

CCF

Canadian Central Facility

CCF KPF

CCF Key Production Facility

CCI

Controlled Cryptographic Item

CKMS

Canadian Key Management System (Now known as GSTN)

CKMU

Canadian Key Management Unit

CMAC

Cryptomaterial Management and Assistance Centre

(C)NES

Canadian Network Encryption System

COMSEC

Communications Security

CRN

Confirmation/Rejection Notice

CRYPTO

Cryptographic

CSE

Communications Security Establishment

DAO

Department Agency Organization

DCA

Departmental COMSEC Authority

DND

Department of National Defence

DSO

Departmental Security Officer

DTD

Data Transfer Device

EKR

Electronic Key Replacement

FFK

FIREFLY Key

GC

Government of Canada

GC EKMS

GC Electronic Key Management System

GC PKI

GC Public Key Infrastructure

GSP

Government Security Policy

GSTN

Government Secure Telephone Network

GSTN KMS

Government Secure Telephone Network Key Management System

IKMS

IRIS Key Management System

ITSC

Information Technology Security Coordinator

KEK

Key Encryption Key

KMA

Key Management Authority

KMID

Key Material Identifier

KP

Key Processor

KPK

Key Production Key

KSD

Key Storage Device

LAN

Local Area Network

LMD

Local Management Device

MSK

Message Signature Key

NATO

North Atlantic Treaty Organization

NCMCS

National COMSEC Material Control System

NCOR

National Central Office of Record

NDA

National Distributing Authority

NFK

Netted FIREFLY Key

OPM

Order Privilege Manager

OPN

Order Privilege Notification

PCM

Privilege Certificate Manager

PER

Privilege Establishment Request

QKEK

Quadrant Key Encryption Key

RA

Registration Authority

SDNS

Secure Data Network System

STAR

Short Title Assignment Requester

STE

Secure Terminal Equipment

STU III

Secure Telephone Unit -Third Generation

TEK

Traffic Encryption Key

TrKEK

Transfer Key Encryption Key

TPI

Two Person Integrity

WAN

Wide Area Network

1 Introduction

1.1 Purpose

This manual sets out the minimum security standards for the ordering of cryptographic key from the Canadian Central Facility (CCF) at the Communications Security Establishment (CSE) for Type 1 and Type 2 crypto-equipment supported by the Government of Canada Electronic Key Management System (GC EKMS).

1.2 Scope

This manual provides a broad overview of cryptographic keying concepts, outlines the division of responsibility of the various entities involved in the key management process, explains the steps necessary to request key ordering privileges and the steps necessary to manually or electronically order both Canadian and U.S. cryptographic key from the CCF.

In the case of a conflict with other published directives, i.e., MG-7 STU III Operational Manual, this document will take precedence.

NOTE: When key is to be ordered from a COMSEC account equipped with a Local Management Device/Key Processor (LMD/KP), refer to the LMD/KP Operator Manual (EKMS 704).

1.3 Applicability

This manual applies to all GC departments listed in Schedule I, I.1 and II of the Financial Administration Act (FAA), including the Canadian Forces, the Royal Canadian Mounted Police (RCMP) and the Canadian Security Intelligence Service (CSIS), herein referred to as departments. As directed by the Government Security Policy (GSP), "departments must use encryption methods or other measures approved by CSE to protect electronic communications that transmit classified and extremely sensitive, designated information." While departments must use a Type 1 solution for classified information, they may use certain commercial solutions for PROTECTED A and B information that should be endorsed by CSE.

1.4 Restrictions

This manual is intended for the establishment of privileges and ordering of cryptographic key from the CCF by non-automated accounts. Automated accounts (i.e., using LCMS) should use this manual in concert with the LMD/KP Operator's Manual (EKMS 704).

1.5 Exceptions

Any request for exceptions to the procedures in this publication should be forwarded to the Head, CMAC at CSE.

1.6 Document Structure

This guide provides descriptions of key types available from the CMAC at CSE followed by explanations of the processes that have been established to order each type of key. The enclosed annexes provide the forms that must be completed to order key and instructions for each form.

2 Key and Key Management Concepts

2.1 Background

For more than 50 years, CSE, as the national authority for COMSEC material in Canada, has been generating and producing cryptographic key in support of national and NATO requirements. Until the last decade, key was primarily produced and distributed in physical unencrypted format. This unencrypted physical key passes through many hands prior to being filled into end equipment and this leaves the possibility for the key to become compromised by any person with access to it. Security is enhanced by requiring frequent key updates, which provided greater assurance that future encrypted messages would not be compromised by previously disclosed key.

In 1989, the Canadian Key Management System (CKMS) was implemented to order, generate, produce and manage cryptographic key in support of the Government Secure Telephone Network (GSTN). This network is based upon the third generation of secure telephone unit known as the STU III. The STU III is a dual-purpose telephone terminal, which serves as both a standard telephone and a secure communications device capable of encrypting, transmitting, and decrypting both voice and data. The introduction of this electronic key management system reduced or eliminated access to plain text key by encrypting and distributing it in electronic form from the point of generation to the point of use, whenever possible.

Following the implementation of the CKMS, another electronic key management system, called the IRIS Key Management System (IKMS) was developed to support a unique Canadian Forces requirement. This system became operational in 2000. The IKMS offers decentralized key generation and encrypted key distribution using a Canadian Key Management Unit (CKMU). For additional information on the IKMS and CKMU, refer to the Canadian Cryptographic Doctrine for the Canadian Key Management Unit (CKMU) (CCD-05).

In 2001, key management in the GC was improved to include support to the Secure Data Network System (SDNS) equipment (e.g., Key Processor (KP), TACLANE) to further reduce access to plain text key by encrypting and distributing it in electronic or physical form. This new key management system, referred to as the GC EKMS, includes the CKMS, which is now referred to as the GSTN Key Management System (GSTN KMS). The GC EKMS is one of three national key management systems operated by the CCF at CSE. The other two systems are the GC Public Key Infrastructure (GC PKI) and the GC FORTEZZA Certificate Based Infrastructure (GC FORTEZZA CBI). For the purposes of this publication, all references to the CCF encompass only the GC EKMS portion of the CCF. The CCF responsibilities associated with the GC PKI and the GC FORTEZZA CBI are described separately from this document.

2.2 GC EKMS Overview

2.2.1 General

The GC EKMS provides for the ordering, generation, production, distribution and accounting of national, allied and NATO key in physical and electronical format and the management of all accountable COMSEC material. As depicted in below, the GC EKMS provides these services in support of both secure voice and data communications and the initialization of key generation and production systems. For detailed information and doctrine for the GC EKMS, refer to the Canadian Cryptographic Doctrine for the Government of Canada Electronic Key Management System (GC EKMS) (CCD-06).

2.2.2 Canadian Central Facility (CCF)

2.2.2.1 General

The CCF is responsible for the overall management of the GC EKMS and is privileged for all GC EKMS root functions. The CCF is comprised of automated systems and the personnel who provide user assistance, operational support and systems administration.

2.2.2.2 Cryptomaterial Management and Assistance Centre (CMAC)

The CMAC consists of the Cryptomaterial Requirements office, the National Central Office of Record (NCOR) and an Assistance Centre to support the activities of these offices.

The Cryptomaterial Requirements Office is responsible for:

1. Registering Key Management Authority (KMA), Ordering Privilege Manager (OPM), User Representatives and Short Title Assignment Requestor (STAR);
2. Processing Privilege Establishment Requests (PERs);
3. Receiving and processing orders for cryptographic key; and
4. Establishing and maintaining lead time schedules for the distribution of cryptographic key.

The NCOR is responsible for:

1. Maintaining a master inventory of accountable COMSEC material, including cryptographic key produced in or entrusted to Canada;
2. Ensuring that the minimum COMSEC accounting standards detailed in the COMSEC Material Control Manual (ITSG-10) are met;
3. Acting as the national Registration Authority (RA) for the establishment of COMSEC accounts and the registration of account personnel; and
4. Acting as Privilege Certificate Manager (PCM) for the assignment of account level privileges.

The Assistance Centre is responsible for:

1. Providing day-to-day operational support for users via telephone, email, voice mail, fax and the EKMS Message Server;
2. Providing services during normal business hours (0800 – 1600 hours) for the Eastern Time zone. Voice mail service, pager service and/or extended hours of operation may be implemented for silent hours or during a crisis or as operationally required;
3. Providing on-line support through the CMAC Web Site (http://www.cse-cst.gc.ca/its-sti/services/cmac-cagmc/index-eng.html); and
4. Providing assistance with all key management problems related to the GC EKMS.

2.2.2.3 Canadian Central Facility Key Production Facility (CCF KPF)

The CCF KPF plays a major role in key generation, production, distribution and accounting. It consists of specialized key generation and production systems, which are capable of generating and producing national, allied and NATO key.

Departments equipped with the GC EKMS Local Management Device/Key Processor (LMD/KP) functionality shall produce Traditional electronic key to fulfill their departmental requirements.

2.2.2.4 National Distributing Authority (NDA)

The NDA is the primary intermediary for nationally accountable COMSEC material entering or leaving Canada. The NDA also provides support for the quality control and bulk distribution of key produced by the CCF KPF, as required.

2.3 GC EKMS Cryptographic Key

2.3.1 Traditional and Modern Key

2.3.1.1 General

Cryptographic key is a sequence of letters, symbols or numbers rather like a very long password that is used in conjunction with a cryptographic algorithm to control either the encryption or decryption of information. Key provides the means not only to hide the information but also to protect it from unauthorized modification, undetected modification and unauthorized use. In addition to encryption and decryption, some key can also provide digital signatures. Encryption provides for confidentiality of information and the digital signature provides for authentication, non-repudiation and integrity of the data. There are two basic types of key: Traditional (symmetric) key and Modern (asymmetric) key.

2.3.1.2 Traditional (Symmetric) Key

Traditional key is common key that is shared by two (or more) parties to encrypt plain text messages and decrypt the ciphertext[1]. The parties who share copies of this common key must rely on each other not to disclose the key and to protect it against modification. Traditional key technology has existed for a long time and is well understood. It is relatively fast and can handle large volumes of data without significantly degrading the quantity. However, secure distribution of this key, especially when in plaintext format, becomes a key management problem. The intended key must be in the possession of all the intended recipients and only those intended recipients and the recipients must know when to use the key. Additionally, when key is required for widespread use in communication networks among users who do not know each other, the security of the network may be at a greater risk of compromise.

2.3.1.3 Modern (Asymmetric) Key

Modern key is based on a FIREFLY key management protocol, which uses public key cryptography. The Modern or FIREFLY key is used to establish a session key between two entities. The session key generated from a FIREFLY exchange is then used in a symmetric encryption algorithm. Two separate (but mathematically related) input keys (i.e., asymmetric keys) are used to perform encryption or decryption functions. This key pair consists of a private key and a public key. Either key can be used for encryption or decryption but once one of them is used for encryption, the other one must be used for decryption.

The three types of Modern key supported by the CCF are:

1. STU III Key;
2. Secure Data Network System (SDNS) Communications Key; and
3. Message Signature Key (MSK).

2.3.2 Identification of Key

2.3.2.1 General

Key is accountable COMSEC material, which must be controlled and accounted for in accordance with the COMSEC Material Control Manual (ITSG-10). For identification, control and tracking purposes, it is assigned a short title, an edition, an Accounting Legend Code (ALC), an accounting number and a security classification.

2.3.2.2 Short Title

A short title is an unclassified method of labeling COMSEC material to facilitate handling, accounting and control. These titles can be found in a variety of locations on physical material. Electronic material short titles may be viewed from equipment supported by EKMS such as, but not limited to, the Data Transfer Device (DTD), Local Management Device (LMD), and KP).

There are a number of different national short title standards in existence today. The EKMS short title standard will be employed for all keying material generated to support new systems, while existing material, such as key tape, will continue to be assigned their legacy titles until all production systems are migrated to the EKMS standard.

For more information on key short titles, refer to the Short Title Nomenclature in Canada (ITSG-09).

Table 1 – STU III Key Short Title Examples

Table 2 – SDNS Key Short Title Examples

Table 3 – MSK Key Short Title Examples

Table 4 – Traditional Key Short Title Examples

2.3.2.3 Editions

Key editions identify one issuance of a series, or specific version of, COMSEC material associated with the same short title. A key edition may appear as a letter (s) or a number(s). Key identified with an edition is time sensitive and is superseded when the next edition becomes effective. The effective period of key is referred to as its supersession rate. The supersession rate for classified key is classified at a minimum of CONFIDENTIAL unless specified higher by the Controlling Authority (CA). The supersession rate for protected key is designated at a minimum of Protected A unless specified higher by the CA.

During a universal changeover of MSK, SDNS and STU III key, which occurs every five years or at the discretion of the CCF, the key received will contain dual edition key. Notification of the universal changeover is issued by the CMAC to the departments who hold the affected key.

Table 5 – Examples of Key Material Editions

2.3.2.4 Key Segments

Key segments distinguish the individual keys delivered in one edition. Each segment is identified uniquely and is augmented by one for each subsequent segment within an edition. The effective period of a segment is referred to as its cryptoperiod. A cryptoperiod is classified in the same manner as the supersession rate of the edition identified in 2.3.2.3.

2.3.2.5 ALC

ALCs indicate the accounting controls and reporting requirements for the key. The ALC normally does not appear on the key but will be included on the accounting report for use by the COMSEC Custodian. Description of ALCs can be found in the ITSG-10 and further information regarding ALCs associated with key ordering can be found in Chapter 5.

2.3.2.6 Accounting Number

Most COMSEC material is assigned a unique accounting (register, serial or copy) number at the point of origin, to facilitate accounting. The accounting number for Traditional key is often referred to as the register number (or reg. number) and the accounting number for Modern key is also called the Key Material Identifier (KMID).

2.3.3 Purposes of Cryptographic Key

There are six main purposes of cryptographic key:

1. Operational – if the privileged EKMS ID requires key intended for use over-the-air for protection or for the production of operational information or for the production or secure electrical transmission of key streams. The key classification will include the caveat CRYPTO;
2. Test – if the privileged EKMS ID requires key intended for over-the-air testing of COMSEC equipment or systems. The key classification will include the caveat CRYPTO;
3. Training –
   • Classroom – if key required is intended for over-the-air or off-the-air classroom training. If the key is for over-the-air training, classification will include the caveat CRYPTO.
   • Exercise – if key is intended to safeguard transmissions associated with exercises. If used over-the-air, classification will include CRYPTO.
4. Maintenance – if the privileged EKMS ID requires key intended only for off-the-air or in-shop use, the key classification will not include the caveat CRYPTO;
5. Developmental – if the privileged EKMS ID requires key intended for the "in-process" production of COMSEC material or equipment, the key classification will include the caveat CRYPTO;
6. Sample – if the privileged EKMS ID requires key intended for off-the-air demonstration use only, the classification may include the caveat CRYPTO.

2.3.4 Sources of Cryptographic Key

CSE is responsible for providing departments with, or authorizing the generation of, national and/or foreign key. The CCF supports the processing of key orders for the generation and production of all types of Traditional and Modern keys and the acquisition of keying material from allied nations. The CCF has the capability to produce key for distribution in electronic and physical format. COMSEC accounts equipped with an LMD/KP may be authorized to generate specified short titles of national and/or allied Traditional key in electronic format only.

2.3.5 Applications for Cryptographic Key

Cryptographic systems normally use either Traditional (e.g., KG 84 key) or Modern key (e.g., STU III key). However, some equipment like TACLANE can use both Modern and Traditional key for the same function, while other equipment use both types in a complimentary manner with each performing a different function. For example, Modern key can be used for transmitting Traditional keys or to sign messages. Cryptographic key can be used for:

1. Point-to-point (Link) encryption – The application of on-line cryptography to individual links of a communications system such that all information (including routing/address data) passing over the link is encrypted in its entirety;
2. End-to-end encryption – The process whereby all data is encrypted from the originator to the recipient. Although data remains encrypted while being passed through a network, routing information remains visible;
3. Disk and file encryption – The process whereby information held on a computer is encrypted using software or hardware encryption/decryption products;
4. Telephone – Specialized telephones such as the STU III and Secure Terminal Equipment (STE/KOV 14) can be used to encrypt voice and data (e.g., facsimiles) communications;
5. Radio – Field radios used for both tactical and strategic operations encrypt both voice and data communications within a selected group;
6. Local Area Network (LAN)/Wide Area Network (WAN) – Network encryption systems such as the CNES or TACLANE can be installed to encrypt communications of whole networks; and
7. Digital Signature – A cryptographic transformation of data that ensures origin authentication, data integrity, and signer non-repudiation.

2.3.6 Cryptographic Key Characteristics

Keys can be ordered to fulfill a variety of purposes (e.g., operational, training, etc.), uses (e.g., FIREFLY), and classification, etc. A full list and description is available in Chapter 5.

2.3.6.1 Type 1 Cryptographic Equipment (crypto-equipment)

Only Type 1 crypto-equipment and systems that have been endorsed or approved by CSE shall be used to protect electronic communications that transmit classified and PROTECTED C information. Type 1 crypto-equipment, also known as High Grade equipment, includes classified COMSEC equipment such as the Key Processor (KOK 22A) and Controlled Cryptographic Items (CCI) such as the STU III, KG 84 and TACLANE (KG 75).

2.3.6.2 Type 2 Crypto-equipment

Type 2 crypto-equipment, also known as Low Grade equipment, includes unclassified crypto-equipment (e.g., STU III Type 2) that has been endorsed or approved by CSE. It may be used to protect electronic communications that transmit designated information. Type 2 crypto-equipment shall not be used for the protection of classified information.

2.4 Key Management Process

2.4.1 Overview

To be effective, key requires a process which governs how and when the key is to be used. These key management services need to be provided from the point of introduction of a new cryptographic device through to the ordering, generation, production, distribution, accounting, use and destruction of the key. The primary key management activities or functions are shown in Figure 2. Subsequent articles provide a brief overview of the key management process and the relationship of each key management activity to the ordering of cryptographic key.

2.4.2 Identifying Requirements for Secure Communications

When a department has determined that there is a need to electronically process classified or designated information, they should contact Head, Client Services, Cryptographic Security at CSE. The consultants at CSE will provide advice and guidance on the types of equipment available and the requirements for establishing new cryptonets.

2.4.3 Establishing a COMSEC Account

Once approval has been obtained from Head, Client Services, Cryptographic Security to procure cryptographic equipment, the department shall contact the CMAC to establish a COMSEC Account to oversee the control and handling of accountable COMSEC material. This process involves the registration of the account information and the appointment of account personnel. Detailed information regarding the establishment of a COMSEC account is available in the ITSG-10.

2.4.4 Registration of Key Ordering Privileges

The registration of key ordering privileges includes the:

1. Appointment of departmental personnel authorized to order key; and
2. Registration of key ordering privileges for an EKMS account.

2.4.5 Ordering Key

2.4.5.1 General

The submission of a key order to the CMAC initiates the process that results in the generation of key and the subsequent placement of that key on the required fill device media (e.g., paper, KSD, DTD). Instructions for the completion of key orders are detailed in Chapter 5 of this publication.

2.4.5.2 Lead-Time

Sufficient lead-time must be provided to allow the CCF KPF time to process the key order, schedule the key for generation, generate the key, produce the key and deliver the key prior to its scheduled use. General guidelines for the lead-time for submitting key orders are as follows:

1. Allow two to three weeks for delivery of all types of key generated by the CCF; and
2. Allow six to eight weeks for delivery of all types of key to be generated at a foreign central facility.

2.4.5.3 Contingency Key

Only a minimum amount of key should be held at any time to satisfy operational requirements and unplanned events such as equipment failure, inadvertent equipment zeroization, damaged key, faulty key or compromised key. Points to consider when determining how much contingency or reserve key to maintain in storage include the number of equipments actually in use and the time required for re-supply of the key. The length of time for re-supply depends upon the type of key required and the delivery method. See ITSG-10, Chapter 6 for more details.

2.4.5.4 Generating and Producing Key

The generation process is highly sensitive and must employ the use of CSE-approved and certified equipment. CSE, as the national authority, is authorized to generate all types of national keying material and specific foreign key. Currently, the CCF KPF at CSE generates the majority of key required by the GC. Once implemented, fully-automated accounts, equipped with an LMD/KP, will generate Traditional electronic key if privileged to do so. The CCF KPF will continue to be the only entity with the capability to generate Modern key and hard copy Traditional key products.

2.4.5.5 Distributing Key

The distribution process is the process of moving key securely from the location at which it is generated to the crypto-equipment into which it is ultimately loaded. The CCF distributes the key to the COMSEC account(s) as indicated in the key order. The key is then redistributed within the COMSEC account or to other COMSEC accounts as authorized by the controlling authority for the key. The CCF KPF initially generates all key as an electronic image. This electronic image is converted to the format specified for delivery by the type of key and the delivery requirements on the key order. A variety of delivery mechanisms supported by the CCF KPF may include:

1. Paper Media (Key Tape, Books);
2. Bulk Encrypted Transaction (BET);
3. Magnetic Media;
4. Data Transfer Device (DTD);
5. Key Storage Device (KSD);
6. PCMCIA Card; and
7. Electronic rekey.

2.4.6 Controlling the Use of Keys

Key is to be used only under the specific conditions as determined by the CA for the cryptonet and, as detailed in the operational doctrine for the cryptosystem in use. Any deviation from this procedure could result in a compromise. In particular, the key shall not be in use longer than the specific cryptoperiod for the key (i.e., time period during which a particular key is in effect).

2.4.7 Replacing Key

To reduce the possibility of compromise of the information protected by the key, users are required to replace the key according to the effective date and supersession rate specified in the key order. In some instances, this requires the physical destruction or zeroization of the key being replaced. For detailed information, see the ITSG-10.

The four methods to replace key in equipment are:

1. Seed Key Conversion - load new seed key and electronically download operational key from the CCF;
2. Real-time rekey - electronically replace operational key via secure communications with the CCF;
3. Store-and-forward rekey - electronically replace operational key via request and response transactions with the CCF; and
4. Load new operational key.

2.4.8 COMSEC Accounting

Because key is the most vulnerable part of any system, it is subject to COMSEC material control procedures even more rigorous than those associated with other types of COMSEC material. It is controlled and accounted for within the National COMSEC Material Control System (NCMCS) from the point of generation until it is destroyed. Refer to ITSG-10 for details.

3 Key Ordering Roles and Responsibilities

3.1 Overview

Key ordering roles and their associated privileges provide the means for departments to control and coordinate the supply and use of key required for their secure communication links/systems. Ordering roles and responsibilities differ according to type of key and the capabilities at the generating account. Certain privileges are applicable to Traditional key while others apply to Modern key. Ordering privileges are not universal (e.g., there is no single privilege, which allows an EKMS account to order any short title). All ordering privileges are restricted (e.g., by a short title, partition code, DAO code, key type, key classification, key purpose, etc.).

Figure 3 illustrates the hierarchy of roles for ordering Traditional key and Modern key. Each EKMS account ordering key or requesting the establishment of key ordering privileges must have its privileges registered at the account that will generate the key (e.g., CCF, LMD/KP).

3.2 Departmental Security Officer (DSO)/IT Security Coordinator (ITSC)/ Departmental COMSEC Authority (DCA)

Each department that requires key for the protection of classified or extremely sensitive designated information should appoint a DCA to establish and maintain effective communications security within their department. In small departments, the DCA may also perform any or all of the key ordering roles required by the department. In addition to those responsibilities listed in the Directives for the Application of Communications Security in the Government of Canada (ITSD-01), the DCAs[2] responsibilities involving key ordering include:

1. Appointing a new KMA, OPM and Controlling Authority, as applicable;
2. Terminating the appointment of the KMA and OPM, when required; and
3. Ensuring that the KMA and OPM receive the training necessary to perform their duties.

3.3 Controlling Authority

A Controlling Authority, who is designated by the DSO/ITSC/DCA, is required only when cryptographic networks (cryptonet) use Traditional key. The role of the Controlling Authority is required to establish and maintain order, to supervise cryptographic logistics and to respond to security issues affecting the cryptonet. The Controlling Authority may also perform any or all of the key ordering roles required by the department. The Controlling Authority is responsible for:

1. The number of cryptonet members and any changes to this number;
2. The status of the key, including the date on which the first edition will become effective, the effective dates for the remaining key, the number of segments per edition and any changes to the key status;
3. The key change time for the cryptonet;
4. The purpose, use and type of key required;
5. The method of delivery for the key;
6. Any special handling and distribution controls or restrictions;
7. The prescribed amount of reserve or contingency key to be ordered to ensure an adequate supply for potential emergency supersessions and other unplanned events;
8. The supersession of the key;
9. The promulgation of status information; and
10. The development and management of key management plans.

NOTE: A Controlling Authority can only be assigned to department-specific key.

3.4 Traditional Key Ordering Privileges

3.4.1 Ordering Privilege Manager (OPM)

The OPM is appointed by the DSO or DCA via the submission of an Appointment Certificate to the CCF. The OPM is responsible for registering an EKMS account's OPM and STAR privileges at the CCF. The OPM, as the highest level in the hierarchy, is:

1. Authorized to perform all the ordering functions associated with the OPM, STAR and Auth ID privileges;
2. Responsible for selecting individuals and requesting an EKMS account's OPM and STAR privileges from the CCF;
3. Responsible for the key ordering training through the ITS Learning Centre at CSE; and
4. Responsible for the implementation of national doctrine for all Traditional key management related activities within their department and the promulgation of any additional or clarifying guidance.

3.4.2 Short Title Assignment Requester (STAR)

The STAR is appointed by the OPM via the submission of an Appointment Certificate to the CCF. The OPM must already be registered at the CCF. The STAR is responsible for submitting orders to the CMAC to create new short titles and assign EKMS IDs as Auth IDs for the short title. If required, the STAR can perform all the functions associated with an Auth ID.

3.4.3 Authorized ID (Auth ID)

The Auth ID privilege is assigned by the STAR, OPM or another Auth ID through the submission of a Traditional PER. The Auth ID privilege at the CCF allows the Auth ID to submit Traditional Key Orders to:

1. Cause the generation of key for a specific short title;
2. Specify/revise the distribution profile for a specific short title;
3. Grant or revoke other accounts' Auth ID privilege for a specific short title;
4. Request revision of the attributes of a specific short title; and
5. Cancel the short title.

3.5 Modern Key Ordering Privileges

3.5.1 Key Management Authority (KMA)

The KMA is appointed by the DCA. The role of the KMA is normally assigned to a senior person in the security or COMSEC field. In large departments, more than one KMA may be appointed. In such cases, the area of responsibility for each KMA must be clearly delineated without overlap. For small departments, the DCA may also decide to serve as the KMA.

The KMA primary responsibilities include:

1. The selection and registration of User Representatives who will be permitted to order Modern key from the CCF;
2. The registration of key ordering privileges for each User Representative, including the establishment of the Department/Agency/Organization (DAO) descriptions for which the User Representative will have authority to order key;
3. The training of User Representatives through the ITS Learning Centre at CSE;
4. The implementation of national doctrine for all Modern key management related activities within their department and the promulgation of any additional or clarifying guidance.

3.5.2 User Representative

The User Representative is selected and registered at the CCF by the KMA. The number of individuals selected by the KMA to serve in the role of the User Representative depends upon the department's structure, location of facilities and security concerns. The User Representative function is normally assigned to a person who has security and/or COMSEC responsibilities within the department. The User Representative must be a Canadian citizen but does not necessarily require a security clearance to order key unless access to classified information (e.g., effective date) is required.

The User Representative is responsible to:

1. Interact with the user community to determine key requirements to support newly acquired equipment, changes in identification information or to rekey an equipment;
2. Verify that users are cleared to the classification level of the key that they are requesting;
3. Prepare and submit key orders to CMAC;
4. Interact with the CMAC to monitor the status of key orders; and
5. Interact with the COMSEC Custodian to advise of any key that can be expected.

3.6 U.S. Key Ordering Privileges

3.6.1 General

The CCF is registered with the U.S. Central Facility in the same manner that all GC departments are registered with the CCF.

3.6.2 U.S. Command Authority

The Command Authority at the CCF is appointed by the DCA for CSE. The Command Authority is responsible for appointing User Representatives and registering their privileges with the U.S. Central Facility.

NOTE: The Command Authority is the U.S. equivalent to KMA.

3.6.3 U.S. User Representative

The U.S. User Representative validates all key orders from GC departments requesting U.S. key and submits these orders to the U.S. Central Facility for processing and generation. The GC department submitting the order must have U.S. key ordering privileges registered with the CMAC.

4 Registration and Privilege Management

4.1 General

There are 3 steps involved in ordering key: registration, privilege establishment and ordering. These steps are defined below. Figure 4 illustrates the registration and privilege establishment process for Modern key. Figure 5 to Figure 8 provide a breakdown of the registration and privilege management processes identified in Figure 4.

4.1.1 Registration

Registration is the process that allows individuals to perform certain key management responsibilities within an account. Registration of an account is accomplished with the Account Registration Form and registration of an individual is accomplished with the Appointment Certificate Form.

Registration of KMA/OPM

The DSO / ITSC or DCA submits an Appointment Certificate to register KMA's or OPM's to the CMAC. The CMAC responds with an Acknowledgement.

Registration of User Representative/STAR

The KMA submits an Appointment Certificate to register User Representatives and the OPM submits an Appointment Certificate to register the STAR at the CMAC. The CMAC responds with a Registration Acknowledgement.

4.1.2 Privilege Management

Privilege Management is the process that assigns, maintains and enforces access controls for individuals and accounts. The process to grant, modify or revoke a key management privilege is accomplished with a Privilege Establishment Request (PER).

The KMA submits the SDNS, MSK or STU III PER to request key ordering privileges to the CMAC for the EKMS ID. The OPM submits a Traditional PER to request STAR privileges at

the CMAC for the EKMS ID. The CMAC will respond to each PER with a PER CRN to advise if the PER has been approved or rejected. The PER CRN is sent to the EKMS ID that submitted the PER.

Privilege Management – PER Rejected by the CMAC

NOTE: STU III OPN's are not sent from the CMAC to the Privileged EKMS ID or the Privileged EKMS ID's COR.

4.1.3 Key Ordering

Key Ordering is the process that initiates the production and delivery of key to a COMSEC account authorized to receive it. The process to order key is accomplished with a Key Order Form.

The privileged EKMS ID submits the SDNS, MSK, Traditional or STU III key order to the CMAC. The key order is either approved or rejected based on privileges assigned to that EKMS ID. The CMAC will respond to each key order with an order CRN.

4.2 Forms and Notices

Table 6 lists the forms and notices used for the registration of key ordering personnel and their privileges. Samples of these forms and notices can be found in the referenced annexes. Many of the boxes on the forms are self-explanatory. A brief explanation of the other boxes on the form is contained in the article references and on the form itself.

It is important that all sections of the forms be completed legibly so that CMAC staff can correctly process the information. Incorrect information may result in incorrect user identification or invalid key orders. Completed forms are submitted to the CMAC.

Table 6 – Registration and Privilege Management Request Forms

4.3 Appointment Certificate Form

4.3.1 General

The Appointment Certificate form found in Annex C is used to appoint individuals or terminate the appointment of individuals authorized to order key or to assign ordering privileges to an EKMS account.

4.3.2 New Appointment

4.3.2.1 Authorization

Personnel performing the following roles are required to be formally appointed:

• The DSO/ITSC appoints the DCA;
• The DSO/ITSC/DCA appoints the KMA and the OPM;
• The KMA appoints the User Representatives and Alternate User Representatives;
• The OPM appoints the STARs.
  

The individual authorizing the appointment must ensure that the appointee:

1. Is a Canadian citizen;
2. Has been granted a security clearance commensurate with the highest sensitivity level of the information or material being accessed;
3. Has received a COMSEC briefing, if required to physically handle the key (i.e., also the COMSEC Custodian, Alternate Custodian, End User); and
4. Is fully conversant with the duties and responsibilities of the appointment.

4.3.2.2 Security Clearance

Unless the appointees will physically handle the key (i.e., the COMSEC Custodian, Alternate COMSEC Custodian, End User), they need not be cleared to the highest level of the key that they are authorized to order.

4.3.2.3 Personnel Training

Prior to appointment, or within three months following appointment, each new KMA, User Representative, OPM, STAR appointee must attend the formal Cryptographic Key Ordering Course. COMSEC Custodians, DSOs and DCAs are also encouraged to attend this course.

Course schedules and registration information are available from the ITS Learning Centre at CSE.

The DCA or currently appointed key ordering personnel should provide interim training to ensure that each appointee thoroughly understands the procedures for assigning privileges and ordering key. If this interim training is not possible at the appointee's department, it can be provided by the CMAC.

4.3.3 Change of Personnel

The individual authorizing the new appointment must submit an Appointment Certificate for the new appointee and complete the Termination of Appointment section on a copy of the original Appointment Certificate for the individual being replaced. The change of personnel shall be performed prior to the departure of the currently appointed personnel.

4.4 STU III PER Form

4.4.1 General

The STU III PER form in Annex D is used by the KMA to register key ordering privileges for the STU III User Representative currently appointed to the EKMS account. The form specifies the STU III User Representative's privileges for specific DAO Codes and DAO descriptions for which the User Representative may order key. It also includes the types of key authorized and the highest security classification of the key.

4.4.2 Request Type

The form is used to add, modify or delete one or more DAO Codes and their associated attributes. Changes must be forwarded to the CMAC promptly to maintain current records and to permit new DAO Codes to be assigned and forwarded to the appropriate User Representative.

The above actions are described below:

1. Add: selecting this option will result in one STU III privilege being added to the EKMS ID. The CMAC will assign the DAO code;
2. Modify: selecting this option will result in modifying an existing STU III privilege. Provide the DAO code that will be modified;
3. Delete: selecting this option will result in all STU III ordering privileges associated with the specified DAO code being deleted. Provide the DAO code that will be deleted.

4.4.3 DAO Code

When adding a new DAO description, leave the DAO Code field blank. The CMAC will assign the six-digit DAO code to the DAO description. This code will be returned to the KMA and User Representative via the STU III PER Confirmation/Rejection Notice (STU III CRN) (formerly known as the Key Order Authorization Form). DAO Codes are used by the User Representative for ordering key. When modifying or deleting a DAO description and/or the associated attributes, the assigned DAO Code must be entered. Each DAO Code will be assigned to only one User Representative but a User Representative may have several DAO

Codes assigned. The DAO description may contain up to 16 characters (including spaces) and corresponds to a line of display on the STU III terminal.

4.4.4 DAO Description

4.4.4.1 General

User identification is a critical part of STU III key and is displayed by the distant STU III telephone when a secure call is initiated. Each user's identification is expressed in two parts: a DAO Description and an additional identification data field (i.e., free form field). The KMA is responsible for specifying the contents of the DAO description while the User Representative is responsible for the additional identification data field. The User Representative will provide the additional identification data on the STU III Key Order Request form (see article 5.2.10).

4.4.4.2 Line 1

Line one of the DAO description is mandatory. The first line of a DAO description is displayed on the distant terminal for the duration of each secure call. It should be a bilingual (optional for foreign key), recognizable, common description of the department rather than cryptic abbreviations or numeric designators that would not be easily recognized by persons calling that STU III telephone. Widely accepted government acronyms such as DND/MDN, GRC/RCMP and CSE/CST are acceptable. Each line may contain up to 16 characters (including spaces) and corresponds to a line of display on the STU III terminal.

4.4.4.3 Line 2

Line two of the DAO description is optional. The second line will be displayed momentarily to the distant user during the secure call set-up. It should be used by the KMA for additional DAO description information such as location, section, unit or position designator. Alternatively, it can be left blank. This leaves one line available for use as additional identification data. The second line must not be used for names of individuals.

4.4.4.4 Rules for DAO Description

The rules for the identification of DAO descriptions are as follows:

1. The first line of the DAO description must specify the sponsoring DAO, or a major portion thereof, or a Government Contractor;
2. The department specified in the DAO description must be representative of the DAO for which the KMA is appointed;
3. Each DAO description must be unique not only to the department but also within all departments;
4. Each DAO description can only be registered and used by one User Representative;
5. Each line may contain up to 16 characters including spaces. Valid characters are uppercase letters (A to Z), digits (0 to 9), and the following special characters:

   , . / [ ] ! " # $ % & ‘ ( ) + - = ; < > ?

6. Two keyboard symbols that cannot be used in the DAO description are the asterisk (*) and the backward slash (\);
7. DAO descriptions should be displayed in bilingual format;
8. Line 2 of the DAO description for STU III key used for communications between EKMS accounts equipped with an LMD or LMD/KP will be populated with the account's EKMS ID; and
9. DAO descriptions may only be created, changed and deleted by the KMA.

4.4.5 EKMS Use Indicator

Key identified for use as EKMS may only be used by the EKMS account for which it is authorized. The STU III EKMS key is required for authentication purposes during direct communications between fully automated and/or partially automated EKMS accounts and for electronic communications to the CCF.

The STU III EKMS key may be used by the EKMS account personnel for classified communications other than EKMS communications. When the STU III is used for non-EKMS communications, the LMD must be disconnected and turned off.

4.4.6 Requesting Ordering Privileges for Other EKMS Accounts

An account may request ordering privileges for other EKMS accounts.

4.4.7 Authorized Key Type

4.4.7.1 General

Key type includes the key type level, which refers to the highest level of protection provided by the key, and the operational status of the key.

4.4.7.2 Key Type Level

The possible key type levels for STU III key include:

1. Type 1 key is used to denote key that is authorized for the protection of classified, unclassified and protected information. Type 1 key can only be used in Type 1 equipment; and
2. Type 2 key is used to denote key that is authorized for the protection of information up to and including PROTECTED B. Type 2 key can only be used in Type 2 equipment.

4.4.7.3 Seed/Operational Indicator

Key is distinguished as either seed key or operational key by the type of electronic information that is stored on the delivery mechanism (i.e., KSD). Operational key can be used for secure communications immediately upon load into the end equipment whereas seed key must be converted to operational key before secure communications are initiated (i.e., electronic rekey). The user initiates this conversion by placing a call to the CCF 613-991-8600, during which the seed key in the end equipment is converted to operational key.

Operational key is available for Type 1 STU IIIs, Type 2 STU IIIs, and KOV 14C cryptographic cards. Seed key is only available for Type 1 STU III terminals.

The KMA must indicate all of the types of key that may be ordered by the STU III User Representative for each DAO Code and DAO description.

4.4.7.4 U.S. STU III Key

If communications are required with U.S. organizations on the American STU III network, the KMA must obtain authorization from the CMAC to order U.S. national key. To obtain authorization, the KMA must provide a written explanation of the requirement including specific Canadian and U.S. individuals involved and the nature of the discussions to take place. The CMAC will review the request and determine if authorization will be granted. U.S. national key orders will not be processed by the CMAC unless authorization is granted. U.S. key ordering privileges must be tied to specific DAO Codes, DAO descriptions and User Representatives.

4.4.8 Maximum Key Classification

Select the highest classification of key that the User Representative can order for each DAO Code using the following guidelines:

1. The only valid classification for Type 2 Operational key is UNCLASSIFIED, this also includes PROTECTED A and B;
2. The highest classification for STU III key with a Class 6 Code of 25 - Mobile (i.e., for use in a CipherTAC) is SECRET; and
3. The maximum classification selected must be equal to or higher than the highest classification of Class 6 Code(s) selected.

4.4.9 Class 6 Codes

When ordering key, it is necessary for the User Representative to use the Class 6 Code section to specify a Class 6 requirement. Currently there are six Class 6 Codes:

Class 6 Code 10 (TOP SECRET ‘SCI' Key) is for use in areas approved for the discussion or processing of sensitive compartmented information (SCI). This description appears in a terminal's display only when both terminals contain key with the ‘SCI' description. All other Class 6 Code descriptions will appear on a terminal's display if one or both terminals contain key with that Class 6 Code.

Any additional Class 6 Codes will be announced as they become available, with instructions to the user community for their use.

4.5 SDNS PER Form

4.5.1 General

The SDNS PER form found in Annex E is used by the KMA to register key ordering privileges for User Representatives who are currently appointed to the EKMS account. The form specifies the User Representative's privileges for specific Partition Codes for which the User Representative may order key and includes the types of key and types of equipment associated with the Partition Code. Completed SDNS PERs are submitted to the CMAC.

4.5.2 Request Type

The form is used to add or delete one or more Partition Codes and their associated attributes. Changes must be forwarded to the CMAC promptly to maintain current records and to permit new Partition Codes to be assigned and forwarded to the appropriate User Representative.

The above actions are described below:

1. Add: selecting this option will result in one SDNS privilege being added to the EKMS ID;
2. Delete: selecting this option will result in all SDNS privileges that have the specified EKMS ID and partition code combination being deleted.

4.5.3 Requesting Ordering Privileges for Other EKMS IDs

An account may request ordering privileges for other EKMS accounts.

4.5.4 Partition Code

Open partition privileges allow User Representatives to order SDNS key for users who want to communicate with all other open partition subscribers. The open partition is similar to the GSTN in that no subscribers are excluded from the communications network.

Closed partition privileges allow User Representatives to order SDNS key for a select set of users as determined by the network administrator and/or Controlling Authority who determines who can communicate in the network. Closed partitions can be further segregated within networks by utilizing access controls.

Partition codes will be approved by ITS Client Services and assigned by the CMAC.

4.5.5 Authorized Key Type

4.5.5.1 General

Key type includes the key type level, which refers to the highest level of protection provided by the key, and the operational status of the key.

4.5.5.2 Key Type Level

The possible key type levels for SDNS key include:

1. Type 0 key is used to generate a Key Encryption Key (KEK), which can be used to bulk encrypt keys. The only valid equipment type for Type 0 key is the KP (KOK 22A);
2. Type 1 key is used to denote key that is authorized for the protection of classified, unclassified and protected information.

4.5.5.3 Seed/Operational Indicator

Key is distinguished as either seed key or operational key by the type of electronic information that is stored on the delivery mechanism (e.g., KSD, DTD). Operational key can be used immediately for secure communications upon load into the end equipment whereas seed key must be converted to operational key before secure communications are initiated (i.e., electronic rekey). The user initiates this conversion by placing a call to the CCF, during which the seed key in the end equipment is converted to operational key.

NOTE: Seed key and electronic rekey for SDNS key is not currently available at the CCF.

4.5.5.4 Maximum Key Classification

The selected maximum key classification shall not exceed the classification level of the account receiving the privilege nor the maximum classification level allowed by the equipment's doctrine.

4.5.5.5 Foreign SDNS Key

If initial communications are required with foreign entities, the KMA must obtain authorization from the Head, Client Services, Cryptographic Security, CSE to order foreign key. To obtain authorization, the KMA must provide a written explanation of the requirement including specific Canadian and foreign organizations involved and the nature of the information to be exchanged. The Head, Client Services, Cryptographic Security, CSE will review the request and determine if authorization will be granted. Foreign key orders will not be processed by the CMAC unless authorization is granted. Foreign key ordering privileges must be tied to specific Partition Codes. Foreign key may consist of the following:

1. Foreign;
2. Coalition;
3. CCEB;
4. NATO; and
5. Allied.

NOTE: SDNS rekey is available at the U.S. Central Facility for certain devices. Contact the CMAC for further information.

4.5.6 Key Purpose

The key purpose provides the function of the key as described below:

1. Operational – if the privileged EKMS ID requires key intended for use over-the-air for protection of operational information or for the production or secure electrical transmission of key streams. The key classification will include the caveat CRYPTO;
2. Test – if the privileged EKMS ID requires key intended for over-the-air testing of COMSEC equipment or systems. The key classification will include the caveat CRYPTO;
3. Training:
   1. Classroom – if key required is intended for over-the-air or off-the-air classroom training. If the key is for over-the-air training classification will include the caveat CRYPTO;
   2. Exercise – if key required is intended to safeguard transmissions associated with exercises. If used over-the-air classification will include CRYPTO.
4. Maintenance – if the privileged EKMS ID requires key intended only for off-the-air or in-shop use the key classification will not include the caveat CRYPTO;
5. Developmental – if the privileged EKMS ID requires key intended for the "in-process" production of COMSEC material or equipment. The key classification will include the caveat CRYPTO;
6. Sample – if the privileged EKMS ID requires key intended for off-the-air demonstration use only. The key classification may include the caveat CRYPTO.

4.6 MSK PER Form

The MSK PER form found in Annex F is used by the KMA to register key ordering privileges for MSK User Representatives who are currently appointed to the EKMS account. The KMA can add or delete the privilege to order Canadian or U.S. MSK for use in a KP (i.e., KOK 22A) in an operational or test mode.

4.6.1 Requesting Ordering Privileges for Other EKMS IDs

An account may request ordering privileges for other EKMS accounts.

4.6.2 Request Type

This form is used to add or delete one or more MSK key ordering privileges. Changes must be forwarded to the CMAC promptly to maintain current records.

The above actions are described below:

1. Add: selecting this option will result in one MSK privilege being added to the EKMS ID;
2. Delete: selecting this option will result in the deletion of all MSK privileges that have the specified EKMS ID and DAO combination.

4.7 Traditional PER Form

The Traditional PER form found in Annex G is used by the DCA to register OPM and STAR key ordering privileges at the CCF for their department. The form is used to add or cancel OPM or STAR privileges as follows:

1. Initial action allows the DCA to add either OPM or STAR privileges; and
2. Cancel action allows the DSO/DCA to delete either the OPM or STAR privilege.

4.8 PER Confirmation/Rejection Notice (PER CRN)

The CCF generates a PER CRN for the EKMS account submitting the request in response to the processing of each PER. It confirms or rejects the requested ordering privileges. Any changes submitted on a PER will result in a new PER CRN. See Annex H for sample PER CRNs.

4.9 Ordering Privilege Notice (OPN)

The CCF generates an OPN for the EKMS account being privileged and the privileged account's COR in response to the processing of each PER. The OPN identifies the OPM, STAR or User Representative ordering privileges granted, revoked or modified by a generating account to another EKMS account in response to an approved Traditional PER, STU III PER, SDNS PER or MSK PER. See Annex I for sample OPNs.

5 Key Orders

5.1 Key Ordering Process

5.1.1 Overview

A key order initiates the process that results in the generation and distribution of key. Key orders are submitted to the CMAC on various forms via mail or courier, secure or non-secure fax and the CCF EKMS Message Server. After the CMAC processes the key order, an Order Confirmation/Rejection Notice (Order CRN) will be sent to the EKMS account that submitted the order. If the key order cannot be processed (e.g., not signed, missing information), the CMAC will contact the department by phone.

5.1.2 Interaction with User Community to Determine Key Requirements

Requirements may come from a number of sources. Users may request key to:

1. Key an equipment when it is first acquired and installed;
2. Restore an equipment to service after it has been zeroized (e.g., operational key erased to facilitate maintenance action or repairs);
3. Change identification information as a result of a re-organization, etc.;
4. Perform testing or maintenance on equipment; and
5. Replace expired key in circumstances where electronic rekeying cannot be performed.

5.1.3 Validate Security Information

The personnel ordering the key (e.g., User Representatives, OPMs, STARs) must validate, through the appropriate departmental channels, that the user has a security clearance equal to or higher than the classification of the requested key. If the request is not valid, the key order must not be placed with the CMAC.

5.1.4 Preparation of Key Order Requests

Samples of the key order request forms and notices listed in Table 7 can be found in the referenced annexes. An explanation of the boxes on the form is contained in the article references and on the form itself. It is important that all sections of the forms be completed legibly so that CMAC staff can correctly process the information. Incorrect information may result in incorrect user identification or invalid key orders.

Table 7 – Key Order Request Forms and Notices

5.1.5 Submission of Key Order Requests

The submission of a key order request must take into consideration the time required to generate, produce and distribute the key (see also Section 2.4.5.2). Depending on sensitivity, key orders can be submitted to the CMAC via:

1. EKMS x.400;
2. Message Server;
3. First class mail;
4. Courier;
5. Secure or non-secure facsimile;
6. Secure or non-secure telephone.

5.1.6 Classification/Protection of Key Order Requests

Key orders may be classified or protected in accordance to their content. Specific instructions are provided with each form.

5.1.7 Validation of Key Order Requests

Once the CMAC receives the key order request, it will be validated against the registered ordering privileges as described in Chapter 4 prior to filling the order. Once approved, an Order CRN will be generated and returned to the EKMS account that submitted the order. The User Representative, OPM or STAR must verify that the Order CRN accurately reflects the key that was ordered. The Order CRN will list the status of each item ordered (e.g., approved, rejected). If an item is approved, then the CCF will proceed with the production and delivery of the key that was approved. If an item is rejected, the reason will be provided and a new key order must be submitted. If an Order CRN is received for an order that was not submitted by the EKMS account, or there is any discrepancy in the order, the User Representative, OPM or STAR or Custodian must call the CMAC immediately.

5.1.8 Monitor Status of Key Order Requests

The Order CRN will contain an Order Transaction ID. This Order Transaction ID should be referenced when contacting the CMAC to request information on the status of the order.

5.1.9 Notification to the COMSEC Custodian

COMSEC Custodians who will receive the key must be notified of the order. The best method for this notification is for the User Representative, OPM or STAR to provide the COMSEC Custodian of the receiving EKMS account with a copy of the key order and the Order CRN. This will enable the COMSEC Custodian to verify that the received key matches what was ordered.

5.2 STU III Key Order Request Form

5.2.1 General

The STU III Key Order Request form found in Annex J is used by the User Representative to order STU III Type 1 and Type 2 key.

5.2.2 EKMS Transaction Number

Each key order request must contain an identifier called a transaction number. The format for this number is YYMMXXXX, where YY is the last two digits of the year, MM is the month, and XXXX is the sequence number of the order within the month. With each subsequent month, the transaction number will start with 0001 again. For example, 01080005 is the fifth key order submitted by this User Representative during the month of August 2001. This field must have a total of eight digits. No alphabetical characters can be used.

5.2.3 Type of Key

5.2.3.1 General

Key type includes the key type level, which refers to the highest level of protection provided by the key, and the operational status of the key.

5.2.3.2 Key Type Level

The possible key type levels for STU III key include:

1. Type 1 key is used to denote key that is authorized for the protection of classified, unclassified and protected information. Type 1 key can only be used in Type 1 equipment; and
2. Type 2 key is used to denote key that is authorized for the protection of information up to and including PROTECTED B. Type 2 key can only be used in Type 2 equipment.

5.2.3.3 Seed/Operational Indicator

Key is distinguished as either seed key or operational key by the type of electronic information that is stored on the KSD. Operational key can be used for secure communications immediately upon load into the end equipment whereas seed key must be converted to operational key (via electronic rekey) before secure communications are initiated. The user initiates this conversion by placing a call to the CCF, during which the seed key in the end equipment is converted to operational key.

Operational key is available for Type 1 STU IIIs, Type 2 STU IIIs, CipherTAC 2000s and KOV-14C cryptographic cards. Seed key is only available for Type 1 STU III terminals.

Operational key enables a user to make a secure call without having to be converted; therefore it is more vulnerable to compromise than seed key. For this reason only seed keys should be ordered, unless there are special circumstances (e.g., requirement for contingency key) at your department.

5.2.4 EKMS STU III Key Order

Automated accounts that have a requirement for a connection to the CCF Message Server must order EKMS STU III key. The EKMS ID of the account where the EKMS STU III key will be used must be entered for each applicable line item.

5.2.5 Delivery Mechanism

STU III key is delivered on KSD 64 or via electronic rekey. STU III key may be loaded into the following equipment types:

5.2.5.1 STU III (includes CipherTAC 2000)

Both seed key and operational key are available for use in all STU III terminals, other than CipherTAC 2000, as indicated above. The CipherTAC 2000 uses only operational key from a KSD, and is loaded directly into the CipherTAC 2000 at the CCF. This includes initial keying as well as rekey since there is no electronic rekey capability for the CipherTAC 2000. STU III key for one or more CipherTAC 2000s may be requested on a single order form. The serial number of the CipherTAC 2000 must be included in the remarks column for each line item identified as Class 6 Code 25 (Mobile). Contact the CMAC to make arrangements for the loading of CipherTAC 2000s.

NOTE: For additional information on the CipherTAC 2000 refer to the Canadian Cryptographic Doctrine for the CipherTAC 2000 (CCD-04).

5.2.5.2 Secure Terminal Equipment (STE)

STU III key for use with the STE is loaded directly onto the KOV 14C Cryptographic Card at the CCF. STU III key for one or more than one KOV 14C may be requested on a single order form. The serial number of the KOV 14C must be included in Block 13 of the STU III Key Order Request form (Remarks column) for each applicable line item. The completed STU III Order Request form and the associated SDNS Key Order Request form, if applicable, must be sent to the CMAC and the zeroized KOV 14C(s) must be sent to the NDA at the CCF via the NCMCS. For additional information on the STE/KOV 14C refer to the Canadian Cryptographic Doctrine for the FORTEZZA PLUS Cryptographic Card (KOV 14C) and associated Secure Terminal Equipment (STE) (CCD-11).

NOTE: For additional information on the STU III and KSDs refer to STU III Key Management Plan (CID/01/13) and STU III Operational Manual (MG-7).

5.2.6 Classification of Key

Enter the classification or designation of the key for each line item. Note the following restrictions:

1. Key may have a designation or classification up to the maximum that the User Representative is permitted to order for the specified DAO Code and DAO description specified for each line item;
2. If the PROTECTED designation is indicated, the appropriate Class 6 Code must be included;
3. The only valid classification for Type 2 Operational key is UNCLASSIFIED;
4. The highest classification for STU III key with a Class 6 Code of 25 - Mobile (i.e., for use in a CipherTAC 2000) is SECRET; and
5. The maximum classification selected must be equal to or higher than the highest classification of Class 6 Code(s) selected.

5.2.7 Class 6 Code

Enter the Class 6 Code, if required. Some users require additional authentication information, such as compartmental security classifications. This can be provided through the use of Class 6 Codes. Each Class 6 Code is assigned a two-digit number by the CMAC. Class 6 Codes are described in article 4.4.9 of this publication.

5.2.8 DAO Code

Enter the appropriate DAO Code for each key ordered. The DAO Codes that an EKMS Account is authorized to request are indicated on the STU III User Representative Key Ordering Authorization Form. Key ordered using a particular DAO code automatically contains the description associated with that code. See also Article 4.4.4 for additional detail.

5.2.9 Additional Identification Data

5.2.9.1 Description

The additional identification data (e.g., free form field) is an additional two lines to the existing DAO description for the key and is displayed on the STU III immediately after the DAO description. Each line of the identification data may contain up to 16 characters including spaces, but the sum of all four (4) lines shall not exceed 50 characters. The additional identification data field allows customization of a department's key to specific sub-elements and users. For example, it can specify geographic location or position title, but shall not include personal names. Additional identification data is optional. The following are examples of complete user identification including the DAO description and the additional identification data field:

• Line 1 HEALTH CANADA DAO Description
• Line 2 SANTE CANADA DAO Description
• Line 3 DIRECTOR SECURITY Free Form
• Line 4 OTTAWA Free Form

5.2.10 Remarks

This is an optional field to indicate any special instructions such as special shipping requests or urgency of order.

5.3 SDNS Key Order Request Form

5.3.1 General

The SDNS Key Order Request form, found in Annex K, is used by the User Representative to order Canadian or U.S. SDNS key for a specified equipment type.

NOTE: The User Representative must have the specific SDNS ordering privileges at the CCF before submitting an SDNS key order.

5.3.2 Transaction Number

Each SDNS Key Order Request must contain an identifier called a Transaction ID. The Transaction Number consists of the EKMS ID submitting the order, the date (YYYYMMDD) on which the order is generated and a one-up serial number beginning at one each calendar year.

5.3.3 Partition Code

Select either open or closed partition for the key being ordered. Only one partition type can be ordered per key order. If closed partition is selected, enter a ten-digit Partition Code previously registered by the KMA. Partition codes are described in article 4.5.4 of this publication.

5.3.4 Equipment Type

Select the equipment type in which the key will be used. Select only one equipment type per key order. If the equipment type of KP (KOK 22A) is selected, the EKMS ID of the account that will use the key must be entered for each key ordered.

5.3.5 Key Type

5.3.5.1 General

Key type includes the key type level, which refers to the highest level of protection provided by the key, and the operational status of the key.

5.3.5.2 Key Type Level

The possible key type levels for SDNS key include:

1. Type 0 key is used to generate a Key Encryption Key (KEK), which can be used to bulk encrypt keys for distribution. The only valid equipment type for Type 0 key is the KP (KOK 22A);
2. Type 1 key is used to denote key that is authorized for the protection of classified information up to and including TOP SECRET and is only used in Type 1 equipment.

5.3.5.3 Seed/Operational Indicator

Key is distinguished as either seed key or operational key by the type of electronic information that is stored on the delivery mechanism (e.g., KSD, DTD). Operational key can be used immediately for secure communications upon load into the end equipment whereas seed key must be converted to operational key before secure communications are initiated (i.e., electronic rekey). The user initiates this conversion by placing a call to the CCF, during which the seed key in the end equipment is converted to operational key.

NOTE: Seed key and electronic rekey for SDNS key is not currently available at the CCF. The U.S. Central Facility supports electronic rekey for most SDNS equipment.

5.3.6 Access Control Schedule

There are three optional fields to select for the Access Control Schedule. If this feature is not required, select "None". If the key type is Type 1 Operational, select "Comms". If the key type is Type O Operational (for keys ordered for the LMD/KP), select "Distribution".

5.3.7 ASCII ID

Any additional identification information for each key such as the 14-character free form information that appears in the CNES display can be entered.

ASCII ID and Authenticated ASCII ID Data provide human-readable access control and identification information. The information may describe a network, account or end-user. The data is contained in the key and may consist of up to 32 characters.

ASCII ID is used when ordering CNES key. User Representatives ordering the key must supply the CMAC with the appropriate ASCII ID.

Authenticated ASCII ID is used when ordering STE/KOV 14 key. User Representatives ordering the key must supply the CMAC with a registered DAO code and the associated DAO descriptor in the proper format. If a new DAO code and DAO descriptor is required, the account's STU III Key Management Authority must complete and submit a STU III PER to the CMAC (see article 4.4). The CMAC will respond to the STU III PER with a STU III User Representative Key Ordering Authorization form.

5.3.8 Delivery Mechanism

5.3.8.1 Bulk Encrypted Transaction (BET)

This delivery mechanism is used to electronically distribute SDNS key and their associated attributes and accounting reports. Only accounts equipped with an LMD/KP can receive key through the BET delivery mechanism. Currently a BET can accommodate a maximum of 16 SDNS keys. The Accounting Legend Code (ALC) for keys delivered in a BET is either ALC 6 or ALC 7.

5.3.8.2 Data Transfer Device (DTD)

The DTD is a fill device designed to securely store, transport and transfer key electronically. Currently a DTD can accommodate a maximum of 22 SDNS keys during non-Universal

changeover periods and a maximum of 11 SDNS keys during Universal changeover period. Refer to the specific equipment doctrine to determine if the equipment can be filled via a DTD. For further information on the DTD refer to the Canadian Cryptographic Doctrine for the AN/CYZ-10/10A Data Transfer Device (CCD-01).

NOTE: When ordering key that will be loaded into a DTD, the User Representative must also advise the CCF of the preferred cryptoperiod option for the DTD Transfer Key Encryption Key (TrKEK) (i.e., quarterly or yearly).

5.3.8.3 Key Storage Device (KSD)

The KSD is referred to as a fill device when it contains operational or seed key. The only valid ALCs for SDNS key delivered on a KSD are ALC 1 or ALC 4.

5.3.8.4 KOV 14C

SDNS key for use with the STE is loaded directly onto the KOV 14C Cryptographic Card at the CCF. SDNS key for one or more than one KOV 14C may be requested on a single order form. The serial number of the KOV 14C must be included in the remarks column for each applicable line item. The completed SDNS Order form and the associated STU III Order form, if applicable, must be sent to the CMAC and the zeroized KOV 14C(s) must be sent to the NDA via the NCMCS. The transaction number of the associated STU III Key Order must be entered in the Remarks Column of the related SDNS Key Order to link the orders.

NOTE: For additional information on the STE/KOV 14C refer to CCD-11.

5.4 MSK Key Order Request Form

5.4.1 General

The MSK Key Order Request form found in Annex L is used by the User Representative to order Canadian or U.S. MSK for the KP.

5.4.2 Transaction ID

Each MSK Key Order Request must contain an identifier called a Transaction ID. The Transaction ID consists of the EKMS ID submitting the order, the date (YYYYMMDD) on which the order is generated and a one-up number beginning at one each calendar year.

5.4.3 Type of Key

The only valid key types for MSK are Type 1 Canadian operational key or Type 1 U.S. operational key. This key is always delivered on a KSD as an ALC 1 or ALC 4 item.

5.4.4 EKMS Use Indicator

The EKMS Use Indicator denotes that the key is used in support of EKMS-only transactions. Key identified for use as EKMS may only be used by the account for which it is authorized. Currently, the only MSKs in use in Canada are EKMS related.

5.4.5 Free Form ID

The Free Form ID consists of the EKMS ID of the account that will use the MSK followed by a colon and then the Privilege Certificate Manager's EKMS ID. The Privilege Certificate Manager's EKMS ID, for GC departments other than DND DCOR is 845999. The Privilege Certificate Manager's EKMS ID for DND DCOR is 844111.

5.5 Traditional Key Order Request Form

5.5.1 General

The Traditional Key Order Request form, found in Annex M, is used by the STAR or Auth ID to order Canadian or U.S. Traditional key for a specified equipment type.

Articles 5.5.3, 5.5.5, 5.5.6, 5.5.7, 5.5.10, 5.5.11, and 5.5.12 relate specifically to partially automated/LCMS accounts.

5.5.2 Transaction Number

Each Traditional Key Order Request must contain an identifier called a transaction number. The transaction number consists of the EKMS ID submitting the order, the date (YYYYMMDD) on which the order is generated and a one-up number beginning at one each calendar year.

5.5.3 Order Types

5.5.3.1 Short Title Assignment Order

The STAR creates a Short Title Assignment Order to assign a new short title to a cryptonet, provide the attributes of the short title and register the EKMS IDs for the Auth IDs who are authorized to place orders for this short title. All the information contained in Blocks A, B and D must be completed.

5.5.3.2 Generation Order

The Auth ID creates a Generation Order to initiate the generation and distribution of a specific short title of key. The EKMS ID for the Auth ID must have been listed on the Short Title Assignment Order for this short title. The information in Blocks A, C and D must be completed.

5.5.3.3 Short Title Assignment/Generation Order

The STAR creates a Short Title Assignment/Generation Order using a single Order form when there is no requirement to request the assignment of a new short title prior to requesting the generation of the key. The entire form must be completed.

5.5.3.4 Revision Order

The Auth ID creates a Revision Order to change the key attributes, to change the Auth IDs and to provide revised generation or distribution information for a specific short title. The information in Blocks A and D and any required changes in Blocks B and C must be completed.

5.5.3.5 Cancellation Order

The Auth ID creates a Cancellation Order to cancel the production of a short title of key and to disassociate the privileges related to the short title from all EKMS IDs. Blocks A and D must be completed.

5.5.4 Short Title

The short title for Traditional key must be entered for Generation, Revision and Cancellation orders. The short title will be provided by the CCF on the Order CRN resulting from the processing of a Short Title Assignment Order or Short Title Assignment/Generation Order.

5.5.5 Distribution Control

The implicit or explicit selection for distribution control applies only to Traditional key in electronic format. It identifies whether or not there are restrictions on the distribution of this short title of Traditional electronic key. If the key is implicitly controlled, it can be distributed in accordance with the distribution profile for the short title or at the discretion of the Controlling Authority for the short title. When key is explicitly controlled, the EKMS account holding the key must have generated or received an electronic distribution instruction directing the distribution of the key prior to its distribution.

5.5.6 Compatible Short Title

The compatible short title selection identifies if the key is required for delivery in two different formats (i.e., dual media key). Dual media key is identical key in two different formats (e.g., paper key tape and electronic) with two different short titles, which can be used on a single cryptonet. Dual key is not yet available from the CCF.

5.5.7 Authorized IDs

This box on the key order allows an OPM, STAR or Auth ID to assign responsibility for the ordering of this short title of key. The EKMS IDs listed will be privileged to submit generation, revision and cancellation orders and distribution instructions for this short title.

5.5.8 Delivery Mechanism

If the key is to be loaded directly on an accountable COMSEC device (e.g., DTD) by the CCF for delivery, the serial number of the COMSEC device (i.e., crypto-equipment) must be included. The completed order form and the zeroized crypto-equipment must be sent to the NDA via the NCMCS.

5.5.9 CRYPTO Caveat

The caveat CRYPTO is used to indicate the unique sensitivity of the key. The key is subject to more stringent controls governing access, distribution, storage, accounting, use, and disposal or destruction. The CRYPTO marking will appear in bold letters on the covers of printed keying material and codes, on disks, on individual key variables or linked as an attribute to the short title of electronic key. It is applied (in addition to the security classification or designation) to

operational, seed, test, and exercise keying material. Maintenance and classroom training key normally do not bear the CRYPTO caveat.

5.5.10 Handling Restrictions

This selection identifies any handling restrictions. The benign fill only restriction indicates that the key can only be delivered to the crypto-equipment using benign techniques. The TPI restriction indicates that two-person integrity is required when handling the key.

NOTE 1: If TPI is selected for key delivered in electronic format, certain LMD/KP operations will require that a second operator be logged on.

NOTE 2: Benign key is not currently available from the CCF.

5.5.11 Release

This box is used to indicate whether or not the key can be released outside of Canada and to whom it is authorized for release (i.e., U.S., NATO).

5.5.12 Key Use

The intended use for the key includes:

1. FFK – FIREFLY Key – used to establish a Key Encryption Key (KEK) or a Traffic Encryption Key between two entities. The KEK or TEK generated from a FIREFLY exchange is then used in a symmetric encryption algorithm;
2. KEK – Key Encryption Key – used to encrypt keys;
3. KPK – Key Production Key – used to produce keys;
4. NFK – Netted FIREFLY Key;
5. QKEK – Quadrant Key Encryption Key;
6. TEK – Traffic Encryption Key – used to encrypt traffic over a communications channel;
7. TSK – TRANSEC Key – used to protect a communications channel from traffic analysis;
8. TrKEK – Transfer Key Encryption Key – used by the KP and DTD.

5.5.13 Key Purpose

Not all key purpose selections are available for each equipment type. Contact the CMAC for assistance on determining which selection is appropriate for the equipment being keyed.

5.5.14 Cryptonet Size

When a cryptonet is being planned, the Head, Client Services, Cryptographic Security at CSE must be informed of the size of the cryptonet and the proposed Controlling Authority for the cryptonet. Significant changes to the size of the cryptonet must be reported to CSE for reevaluation.

5.5.15 Crypto Period

The crypto period identified in terms of the number of hours, days, weeks, months or years that each key remains in effect must be entered.

5.5.16 Segment Per Edition

The number of segments that are required within an edition of the key must be entered.

5.5.17 Supersession Rate

The rate of supersession identified in terms of the number of hours, days, weeks, months or years that each segment of key remains in effect must be entered.

5.5.18 Effective Date

When completed, the Key Order Request must be classified at a minimum of CONFIDENTIAL if it contains the effective date and UNCLASSIFIED if not included.

5.5.19 In-Place Date

The date at which the key must be received by the EKMS accounts listed in the Distribution Profile must be entered. This date must take into consideration the lead-time that is required to process the key order, generate the key and deliver the key. The lead time for the generation and distribution of hard copy products is significantly longer than for electronic key.

5.5.20 Standing Order

Standing orders are established when a regular requirement for key is established and a resupply schedule is known. This eliminates the need for any re-orders, subsequent to the initial orders, unless there is a change in the attributes of the original order (e.g., addition of new net members) at which time a revision order must be submitted. If it is not a standing order, the key is scheduled for generation once only. If standing order is specified, key will be automatically rescheduled for generation.

5.5.21 Edition Information

The first edition (e.g., A, EB), the last edition and the total number of editions to be generated for this key order must be identified.

5.5.22 Distribution Profile

The distribution profile lists which EKMS accounts are to receive a key or group of keys, what editions they are to receive and how many copies of each edition.

5.5.23 Accounting Legend Code (ALC) and Rules for Transfer Report Initiating (TRI)

The ALC is a numeric code used to indicate the minimum accounting controls for COMSEC items included in the NCMCS.

ALC-1: Continuously accountable by an accounting number or register number to a COR.

ALC-2: Continuously accountable by quantity to a COR.

ALC-4: Initial receipt required and accountable according to local directives thereafter.

ALC-6: Electronic key tracked by GC EKMS, continuously accountable, with or without an accounting number, to a COR.

ALC-7: Electronic key tracked by GC EKMS, initial receipt to the sender required, no subsequent reporting; automated local record maintained (locally accountable thereafter).

1. A TRI line item's ALC will default to ALC 1 if the TRI is not in a BET, except as defined below in (3).
2. A TRI line item's ALC will default to ALC 6 if the TRI is in a BET, except as defined in (3).
3. A TRI line item's ALC will default to ALC 4 instead of ALC 1, and ALC 7 instead of ALC 6 when:
   1. Key Purpose = M (maintenance);
   2. Key Purpose = T (training);
   3. Key Purpose = Z (on-the-air testing); and
   4. Classification = unclassified.

Contact the CMAC for assistance with ALC selection for accountable COMSEC material.

5.6 Order Confirmation/Rejection Notice (Order CRN)

The CCF generates an Order CRN for the EKMS account submitting the request in response to the processing of each key order. It confirms or rejects the requested order. See Annex N for a sample Order CRN.

NOTE: CRNs for Traditional Key Orders are not supported by the CCF at this time.

Glossary

Accounting Legend Code (ALC)

Numeric code used to indicate the minimum accounting controls for COMSEC items included in the National COMSEC Material Control System (NCMCS).

Account Registration

Process by which GC EKMS accounts are identified and associated with their administrative and configuration attributes.

Allied Key

Key used by at least two different nations. Allied key is generated by one of the nations and released for use to other nations.

Authentication

A measure designed to provide protection against fraudulent transmissions or imitations by establishing the validity of a transmission, message or originator.

Authorized ID

EKMS accounts that are authorized to order a specific short title of Traditional key.

Benign

Condition of cryptographic data such that it cannot be compromised by human access to the data.

Benign Fill Key

Benign fill FIREFLY key material is the keying material used by the Key Processors and end crypto-equipment to create keys used to encrypt/decrypt application key material and user data.

Benign Keying

Keying method that generates and encrypts key in GC EKMS components, such as the Key Processor or Canadian Central Facility, and delivers the key to the end user without decrypting the key until loaded into the end cryptographic equipment.

Bulk Encrypted Transaction (BET)

An EKMS transaction containing encrypted key(s), encrypted key attributes, and encrypted accounting reports (transfer or issue).

Canadian Central Facility (CCF)

A facility located at CSE which provides centralized key management services for all forms of key.

Class 6 Code

A two-digit numeric code corresponding to a specific Class 6 field.

Class 6 Field

A field that appears in the distant STU III terminal's two line display. The field contains additional Class 6 data that is part of the authentication process. The top line of the display indicates the highest common classification level on the left and the Class 6 Code Field information (e.g., SCI) on the right.

Classified Information

Information related to the national interest that may qualify for an exception or exclusion under the Access to Information Act or Privacy Act and the compromise of which could reasonably be expected to cause injury to the national interest.

Command Authority

See Key Management Authority (KMA).

Communications Security (COMSEC)

Protection resulting from applying cryptographic, transmission and emission security measures to telecommunication emissions, and information handling equipment, and from applying other measures appropriate to COMSEC information and material. COMSEC also includes the instruction required to effect this protection. These measures are designed to prevent compromise of information stored, transmitted or processed on an information technology system. COMSEC is also designed to ensure the authenticity of telecommunications.

Compromise

Unauthorized disclosure, destruction, removal, modification or interruption.

COMSEC Account

Administrative entity, identified by an EKMS ID, used to maintain accountability, custody and control of accountable COMSEC material.

COMSEC Custodian

The individual designated by a proper authority to be responsible for the receipt, custody, issue, transfer, accounting, safeguarding and destruction of COMSEC material assigned to a COMSEC account.

COMSEC Equipment

Equipment designed to provide communications security by converting information to a form unintelligible to an unauthorized interceptor and, subsequently, by reconverting such information to its original form for authorized recipients; also equipment designed specifically to aid in, or as an essential element of, the conversion process.

COMSEC Incident

A COMSEC incident is any occurrence which potentially jeopardizes the security of classified or designated Government information while it is being stored, processed, transmitted or received during the telecommunications process.

COMSEC Material

Material designed to secure or authenticate telecommunications. COMSEC Material includes, but is not limited to, key, equipment, devices, documents, firmware or software that embodies or describes cryptographic logic and other items that perform COMSEC functions.

Confidentiality

The sensitivity of information or assets to unauthorized disclosure, recorded as classification or designation, each of which implies a degree of injury should unauthorized disclosure occur.

Confirmation/Rejection Notice (CRN)

A notice created as a result of processing a key order or a Privilege Establishment Request (PER).

Controlled Cryptographic Item (CCI)

Secure telecommunications or information handling equipment, or associated cryptographic component or ancillary device that is unclassified when unkeyed (or when keyed with an unclassified key) but controlled through an accounting system.

Controlling Authority

Designated official responsible for directing the operation of a cryptonet and for managing the operational use and control of keying material assigned to the cryptonet.

CRYPTO

A caveat which is applied to keying material indicating that items so marked are subject to specific controls governing access, distribution, storage, accounting, disposal, and destruction.

Cryptonet

See ITSG-10 or ITSD-01 for definition.

Cryptoperiod

A specific period of time during which a cryptographic key is in effect.

DAO Code

A unique Department/Agency/Organization identifier for use in the user specific parts of a FIREFLY key.

Data Transfer Device (DTD)

Fill device designed to securely store, transport, and transfer electronically both COMSEC and TRANSEC key, designed to be backwards compatible with the previous generation of COMSEC common fill devices, and programmable to support modern mission systems.

Decryption

A process that converts encrypted voice or data information into plain form by reversing the encryption process.

Departmental COMSEC Authority (DCA)

The individual responsible to the Departmental Security Officer (DSO) for developing, implementing, maintaining, coordinating, and monitoring a departmental COMSEC program which is consistent with the GSP and its standards.

Departmental Security Officer (DSO)

The individual responsible for developing, implementing, maintaining, coordinating and monitoring a departmental security program consistent with the GSP and its standards.

Destruction

The process of destroying (e.g., shredding, burning, etc.) physical COMSEC material or destroying electronic key through zeroization or fill into an end equipment.

Digital Signature

A cryptographic transformation of data which, when appended to a data unit, provides the services of origin authentication, data integrity, and signer non-repudiation.

Digraph

A two character code that identifies the number of key segments in an edition and the key segment cryptoperiod.

Distribution Profile

A list provided by a key orderer or controlling authority detailing who should receive a key or group of keys and how many copies of each key they should receive.

DTD TrKEK

Used to encrypt a key issued by a KP to a DTD. It is also filled into a DTD to permit it to decrypt the key for filling into end equipment.

Dual Media Key

Compatible key that exists in both electronic and physical format.

Edition

Alpha or numeric string that identifies one issuance of a series, or specific version of, COMSEC material associated with the same short title.

Effective Date

Date when a key or other data is intended to be first used.

EKMS Account

A generic term that encompasses an EKMS Element or a COMSEC Account.

EKMS ID

Unique identifier of an EKMS account.

Encryption

The transformation of readable data into an unreadable stream of characters using a reversible coding process.

Exercise Key

Key intended to safeguard transmissions associated with exercises.

Explicit Key

Any key which is provided automatic control by EKMS in accordance with distribution restrictions prescribed by the controlling authority.

Fill

The process of providing key material to an end crypto-equipment for its internal use.

Fill Device

COMSEC item used to transfer or store key in electronic form or to insert key into a crypto-equipment.

Foreign Key

National key from another nation.

NOTE: Only under extreme circumstances should national key be used by another nation or alliance.

Generation

The process by which the first instance of a key is created and all Mission System independent or Mission System dependent data, derivable from a key order are formed in the format required to fill the destination COMSEC equipment.

GC EKMS

An interoperable collection of automated systems, facilities and components which provide services for the ordering, generation, distribution and management of Canadian COMSEC Material for the Government of Canada key management user community.

Government Secure Telephone Network (GSTN)

A computer based system which supports key management for the STU III through provision of key generation and distribution within Canada.

Handling Restrictions

A means of controlling the use of Traditional key. The choices are no restrictions, Two Person Integrity (TPI), or Benign Fill only.

Hard Copy Key Products

Key, publications, key lists, etc. which exist in physical format.

Implicit Key

Any key whose handling characteristics are determined solely by policy and procedural

Integrity

The accuracy and completeness of information and assets and the authenticity of transactions.

Key

Information (usually a sequence of random or pseudo random binary digits) used initially to set up and periodically change the operations performed in crypto-equipment for the purpose of encrypting or decrypting electronic signals, for determining electronic counter-counter-measures patterns (e.g., frequency hopping or spread spectrum), or for producing other keys.

Key Attributes

The characteristics assigned to a specific key short title (e.g., ALC, key purpose, key use, etc.).

Key Distribution

Secure controlled movement of key from the point of generation or storage to the point of use or re-distribution.

Key Encryption Key (KEK) Key Management

Key that encrypts or decrypts other keys for transmission or storage.

Procedures and mechanisms for generating, disseminating, replacing, storing, archiving, and destroying keys which control encryption or authentication processes.

Key Management Authority (KMA)

A senior person appointed by a department, an agency, or an organization to co-ordinate and oversees STU III, SDNS, and/or MSK key management within their department, agency, or organization.

NOTE: The U.S. refers to the Key Management Authority as the Command Authority.

Key Material Identification (KMID)

A number that uniquely identifies a FIREFLY key. It is the identifier used in adding to or removing from the Compromise Key List (CKL) and to account for FIREFLY key.

Key Processor (KP)

Cryptographic component in EKMS designed to provide for the local generation of keying material, encryption and decryption of key, key loading into fill devices, and message signature and verification functions.

Key Production Key (KPK)

Key used to initialize a key stream generator for the production of other electronically generated keys.

Key Storage Device (KSD)

A fill device used to store, transport, and transfer key and other system data.

Local Management Device (LMD)

Component in EKMS that provides automated services for the management of key and other COMSEC material, and an interface by which additional functionality may be incorporated to enhance its local capabilities. It is composed of the user-supplied platform, operating system and EKMS software.

Message Signature Key (MSK)

Cryptographic material used in a digital signature process that operates on a message to assure message source authentication, message integrity, and source non-repudiation.

Modern Key

A collective name for FIREFLY-based key such as STU III key, SDNS Communications key and MSK.

National Affiliation Identifier (NAI)

A two-letter country code derived from the ISO 3166, the International Standards Organization document on codes for the representation of countries and their subdivisions.

National Central Office of Record (NCOR)

The entity within the COMSEC control section of CSE which is charged with the responsibility of maintaining records of accountability for all accountable COMSEC material produced in or entrusted to Canada.

National Distributing Authority (NDA)

The national entity within the Canadian COMSEC community responsible for secure receipt, storage, distribution and disposal of COMSEC material originating at CSE or received from or destined to foreign countries.

National Key

Key used solely by the nation that generated the key.

NATO Key

Key that has been produced for use by NATO countries.

Netted FIREFLY Key

A FIREFLY key that is managed in the same way as a Traditional cryptonet.

Non-Repudiation

Non-repudiation provides proof that the transaction occurred, or that the message was sent and received thus the parties cannot deny that the exchange occurred.

Operational Key

Key intended for use on-the-air for protection of operational information or for the production of secure electrical transmission of key streams.

Ordering Privilege Manager (OPM)

An EKMS account privileged to appoint and remove other accounts as an OPM or Short Title Assignment Requester (STAR) at a generating account where they are registered as an OPM.

Privilege Certificate Manager (PCM)

An EKMS account which is authorized to create KP Privilege Certificates for a specific set of KP-equipped EKMS accounts.

Privilege Establishment Request (PER)

Transaction to request the registration, modification, or deletion of key ordering privileges (i.e., OPM, STAR, User Representative) at a generating account.

Register Number

Used to uniquely identify individual copies of key which have the same short title and edition. Synonymous with accounting number.

Rekey

The process by which all FIREFLY keying material, including Benign fill FIREFLY, is periodically replaced.

Release Field - LCMS

An attribute of an electronic key that identifies the countries, via the country's National Affiliation Indicator (NAI), which are authorized to have a specific key.

Secure Data Network System (SDNS)

Mission system which is a subscriber of EKMS services and provides end-to-end security services for the exchange of data between automatic data processing systems over common carrier communication networks where no security services are provided by the common carriers.

Secure Terminal Equipment (STE)

A government approved telecommunication terminal designed to provide secure voice and data connectivity, conferencing capability, and other capabilities based on a layered communications model.

Secure Telephone Unit - Third Generation (STU III)

A government approved telecommunication terminal designed to protect the transmission of sensitive or classified information in the voice, data, or facsimile mode.

Seed Key

Initial key containing unique information used to start an updating or key generation process.

Segment

Traditional key that is valid for one cryptoperiod.

Sensitive Compartmented Information (SCI)

Intelligence information requiring special controls indicating restricted access.

SCI Key

STU III keying material which provides for the SCI authenticator to be displayed in the Class 6 field of a distant terminal in the secure mode if both terminals contain that same designator.

Short Title

Identifying combination of letters and numbers assigned to certain COMSEC items to facilitate handling, accounting, and control.

Short Title Assignment Requester (STAR)

An EKMS account privileged to request assignment of new short titles at a generating account.

Supersession

Scheduled or unscheduled replacement of a key or COMSEC aid with a different edition.

Tactical Key

Traffic encryption key, key encryption key, or transmission security key intended to secure information or data that is perishable, has low intelligence value (i.e., low national or international sensitivity), and is classified no higher than SECRET.

Test Key

Key intended for on-the-air testing of COMSEC equipment or systems.

Traditional Key

Term used to reference non-FIREFLY-based key that is generated in accordance with established procedures.

Traffic Encryption Key (TEK)

Key used to encrypt plain text or to superencrypt previously encrypted text and/or decrypt cipher text.

Transfer Key Encryption Key (TrKEK)

Key used to encrypt and decrypt user key.

Two-person Integrity (TPI)

Procedure whereby material is never handled or made available to one person only.

Type 0 Key

Cryptographic key used to generate a Key Encryption Key (KEK) that can be used to bulk-encrypt keys.

Type 1 Cryptographic Equipment

Classified cryptographic or CCI equipment containing an encryption and/or key exchange algorithm that has been approved by CSE for the protection of classified and designated information.

Type 1 Key

Cryptographic key used for the protection of classified information up to and including Top Secret.

Type 2 Cryptographic Equipment

Unclassified cryptographic equipment, assembly or component containing encryption provided by government and/or key exchange algorithms that have been approved by CSE for the protection of designated information.

Type 2 Key

Cryptographic key used for the protection of designated information up to and including Protected C.

Type 3 Cryptographic Equipment

Cryptographic equipment containing a public or proprietary encryption and/or key exchange algorithm that has been approved by CSE for use in protecting designated information.

Type 4 Cryptographic Equipment

Cryptographic equipment containing a public or proprietary encryption and/or key exchange algorithm that has not been approved by CSE for the protection of information.

User Representative

An individual appointed by the Key Management Authority (KMA) authorized to order STU III key, SDNS key and/or Message Signature Key (MSK).

Zeroize

Remove or eliminate the key from a crypto-equipment or fill device.

Bibliography/References

The following references were used in the preparation of this publication:

1. Canadian Cryptographic Doctrine for the AN/CYZ-10/10A Data Transfer Device (CCD-01), dated May 1998, Communications Security Establishment.
2. Canadian Cryptographic Doctrine for the Canadian Network Encryption System (CCD-02), dated September 1998, Communications Security Establishment.
3. Canadian Cryptographic Doctrine for the CipherTAC 2000 (CCD-04), dated January 1999, Communications Security Establishment.
4. Canadian Cryptographic Doctrine for the Canadian Key Management Unit (CKMU) (CCD-05), dated April 2000, Communications Security Establishment.
5. Canadian Cryptographic Doctrine for the Government of Canada Electronic Key Management System (GC EKMS) (CCD-06), draft dated June 2000, Communications Security Establishment.
6. Guidelines for the Application of Communications Security in the Government of Canada (ITSD-01), draft dated May 2001, Communications Security Establishment.
7. Short Title Nomenclature in Canada (ITSG-09), dated October 2001, Communications Security Establishment.
8. Canadian Cryptographic Doctrine for the FORTEZZA PLUS Cryptographic Card (KOV 14C) and associated Secure Terminal Equipment (STE) (CCD-11), dated April 2002, Communications Security Establishment.
9. COMSEC Material Control Manual (ITSG-10) (formerly MG-14), January 2003, Communications Security Establishment.
10. Canadian Cryptographic Doctrine for the Local Management Device/ Key Processor (LMD/KP) (CCD-07), dated August 2002, Communications Security Establishment.

Annex A – CSE Points of Contact

A.1 General

This Annex provides the telephone numbers and the electronic and mailing addresses for points of contact at CSE.

A.2 Cryptomaterial Management and Assistance Centre (CMAC)

Telephone number: 613-991-8600

E-mail address: cmac-camc@cse-cst.gc.ca

Unclassified Facsimile: 613-991-7440 Secure

Facsimile: 613-991-8709

A.3 National COMSEC Incidents Office (NCIO)

Telephone number: 613-991-8498

E-mail address: ncio@cse-cst.gc.ca

Unclassified Facsimile: 613-991-8565

Secure Facsimile: 613-991-8565 (Call 613-991-8132 for set-up)

A.4 National Cryptographic Procedures, Audits and Training (NCPAT)

Telephone number: 613-991-8173

E-mail address: ncpat@cse-cst.gc.ca

A.5 Head, Client Services, Cryptographic Security

Telephone number: 613-991-8495

E-mail address: itsclientservices@cse-cst.gc.ca

Unclassified Facsimile number: 613-991-8565

Secure Facsimile: 613-991-8565 (Call 991-8132 for set-up)

A.6 CSE General Inquiries

Telephone Number: 613-991-7600

Web Site address: http://www.cse-cst.gc.ca

Unclassified Facsimile: 613-991-8565

Secure Facsimile: 613-991-8565 (Call 991-8132 for set-up)

Annex B – Directive on the Control of STU III Key for Sensitive Compartmented Information (SCI) Applications

B.1 Purpose

This directive establishes procedures and assigns responsibilities for the acquisition and control of STU III key for Sensitive Compartmented Information (SCI) applications. It is intended to ensure that uniform procedures are implemented throughout the STU III user community in the Government of Canada (GC).

B.2 Applicability

This directive applies to all GC departments participating in the STU III based Government Secure Telephone Network (GSTN) in conjunction with the acquisition and deployment of STU III Type 1 terminals within areas authorized to handle SCI.

B.3 Definitions

Class 6 Code

A two-digit numeric code corresponding to a specific Class 6 field.

Class 6 Field

A field that appears in the distant STU III terminal's two line display. The field contains additional Class 6 data that is part of the authentication process. The top line of the display indicates the highest common classification level on the left and the Class 6 Code Field information (e.g., SCI) on the right.

Departmental Security Officer (DSO)

The individual responsible for developing, implementing, maintaining, coordinating and monitoring a departmental security program consistent with the GSP and its standards.

Key Management Authority (KMA)

A senior person appointed by a department, agency, or organization to co-ordinate and oversees STU III, SDNS, and/or MSK key management within their department, agency, organization.

Sensitive Compartmented Information (SCI)

Intelligence information requiring special controls indicating restricted access.

SCI Key

STU III keying material which provides for the SCI authenticator to be displayed in the Class 6 field of a distant terminal in the secure mode if both terminals contain that same designator.

User Representative

An individual appointed by the Key Management Authority (KMA) authorized to order STU III key, SDNS key and/or Message Signature Key (MSK).

B.4 Departmental Procedures and Responsibilities

The Key Management Authority (KMA) will establish the departmental need for SCI key and appoint one or more User Representatives from their department through the User Representative registration process. The User Representative will be assigned the authority to order SCI key from the Canadian Central Facility (CCF) at CSE as specified in the STU III Privilege Establishment Request (STU III PER) (Annex D). The DAO Code and description specified for the SCI key shall include the word "CANADA" in Line 1.

The User Representative will specify the department's need for SCI key through consultation with the Departmental Security Officer (DSO).

The DSO will:

1. Verify the clearance and SCI indoctrination level of the intended users;
2. Verify that the area in which the STU III terminal is located has been authorized for SCI; and
3. Authenticate STU III orders for SCI key, using the SCI Key Acknowledgement Form (Annex O).

The User Representative will prepare and submit the STU III Key Order form (Annex J) for SCI key to the Cryptomaterial Management and Assistance Centre (CMAC) at CSE and notify the COMSEC Custodian of this action. The User Representative will also submit the SCI Key Acknowledgement form to the CMAC.

The COMSEC Custodian will instruct SCI cleared users on procedures for loading, operating and protecting the SCI key.

B.5 CCF Procedures and Responsibilities

The CMAC will verify that all STU III Key Orders for SCI key are consistent with the privileges assigned to the User Representative by the KMA and check for the DSO's co-signature. In addition, the CMAC will ensure that the department has a valid TOP SECRET COMSEC Account registered with the National Central Office of Record (NCOR) as required for the receipt of TOP SECRET SCI key.

The CMAC will forward the STU III Key Order requesting SCI key to the authority in CSE responsible for the initial accreditation and continued security oversight, in conjunction with the DSO, of facilities in which SCI is handled. The CSE authority provides the final authorization for the SCI key request.

The CMAC will begin processing the STU III Key Order requesting SCI key and forward a STU III Order Confirmation/Rejection Notice to the User representative.

The department's security procedures and facilities must be inspected and approved prior to receiving SCI key. CSE may perform this function or delegate it to authorized elements within the requesting department.

B.6 Contractors

The GC has no requirement at this time to release SCI key to contractors.

Annex H – Privilege Establishment Request Confirmation/Rejection Notice (PER CRN)

PER CRN

Protected A

Printed: Mar 02, 2005 02:18 PM

Page 1 of 1

EKMS MESSAGE:

Message ID: 845550-20050302-54239

Message Date: Mar 02, 2005

Source EKMS ID: 845550

Source Element Name:

Destination EKMS ID: 841234

Destination Element Name:

Subject:

Transaction Type: SDNS PER CRN

Transaction ID: 845550-20050302-55240

Transaction Information Label: FOUO

PER CRN TRANSACTION :

Transaction ID: 845550-20050302-55240

Transaction Date: Mar 02, 2005

Source EKMS ID: 845550

Source Element Name:

Destination EKMS ID:841234

Destination Element Name:

CCF KPF Transaction Status: Approved

Transmission Method: Electronic

Overall Status: Confirmation

Per Type: SDNS

PER Transaction ID: 841234-20050209-2

Privilege For EKMS ID: 841234

Element Name: 841234

Comments:

Annex I – Ordering Privilege Notice (OPN)

SNDS OPN (Privilege Recipient)

Protected A

Printed: Mar 02, 2005 02:18 PM

Page 1 of 1

EKMS MESSAGE:

Message ID: 845550-20050302-54240

Message Date: Mar 02, 2005

Source EKMS ID: 845550

Source Element Name:

Destination EKMS ID: 841234

Destination Element Name:

Subject:

Transaction Type: Order Privilege Notice

Transaction ID: 845550-20050302-55241

Transaction Information Label: FOUO

PER CRN TRANSACTION:

Transaction ID: 845550-20050302-55241

Transaction Date: Mar 02, 2005

Source EKMS ID : 845550

Source Element Name :

Destination EKMS ID: 841234

Destination Element Name:

CCF KPF Transaction Status: Approved

Transmission Method: Paper

Overall Status: Sent

Privileged At EKMS ID: 845550

Element Name:

Privileging EKMS ID: 841234

Element Name:

Privilege For EKMS ID: 841234

Element Name:

Privilege Est. Request Type: Add

Equipment (Device) Type: KG 175

Maximum Classification: Unclassified

Key Type Level: Type 1

Key Purpose (OP/Test Indicator): Testing

EKMS Use (Allowed)Ind.: N

Partition Code: 3001

Seed/Op Ind.: Operational

EKR Priv. Ind.: N

ALC:

Notes

• [1] Ciphertext : Encrypted message.
• [2] In the absence of the DCA, the Departmental Security Officers (DSO) or the Information Technology Security Coordinator (ITSC), is consider to be the COMSEC Authority and is responsible to fulfill the responsibilities of the DCA.