Cryptographic Key Ordering Manual (ITSG-13)

Cryptographic Key Ordering Manual (ITSG-13) 

This page intentionally left blank. 

May 2006


Foreword 

The Cryptographic Key Ordering Manual (ITSG-13) is an unclassified publication issued under 

the authority of the Chief, Communications Security Establishment (CSE). CSE, as the lead 

agency for cryptography in the Government of Canada (GoC), 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@cse-cst.gc.ca or call (613) 991-8826. 

___________________________________________________ 

Sue Greaves 

Director, IT Security Mission Management 

© 2006 Government of Canada, Communications Security Establishment (CSE) 

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 CSE is required for use of the 

material in edited or excerpted form, or for any commercial purpose. 

Foreword May 2006 i



ii May 2006 Foreword


Record of Amendments 

Amendment No. Date Entered by 

Record of Amendments May 2006 iii



iv May 2006 Record of Amendments


Table of Contents 

Foreword......................................................................................................................... i 

Record of Amendments............................................................................................... iii 

Table of Contents.......................................................................................................... v 

List of Figures .............................................................................................................. ix 

List of Tables ................................................................................................................ xi 

List of Abbreviations and Acronyms........................................................................ xiii 

1 Introduction ........................................................................................................... 1 

1.1 Purpose........................................................................................................... 1 

1.2 Scope.............................................................................................................. 1 

1.3 Applicability ..................................................................................................... 1 

1.4 Restrictions ..................................................................................................... 1 

1.5 Exceptions....................................................................................................... 1 

1.6 Document Structure ........................................................................................ 1 

2 Key and Key Management Concepts................................................................... 3 

2.1 Background ..................................................................................................... 3 

2.2 GoC EKMS Overview...................................................................................... 4 

2.2.1 General.............................................................................................. 4 

2.2.2 Canadian Central Facility (CCF) ........................................................ 4 

2.3 GoC EKMS Cryptographic Key ....................................................................... 6 

2.3.1 Traditional and Modern Key............................................................... 6 

2.3.2 Identification of Key ........................................................................... 7 

2.3.3 Purposes of Cryptographic Key ....................................................... 10 

2.3.4 Sources of Cryptographic Key ......................................................... 10 

2.3.5 Applications for Cryptographic Key.................................................. 10 

2.3.6 Cryptographic Key Characteristics................................................... 11 

2.4 Key Management Process ............................................................................ 11 

2.4.1 Overview.......................................................................................... 11 

2.4.2 Identifying Requirements for Secure Communications .................... 12 

2.4.3 Establishing a COMSEC Account.................................................... 12 

2.4.4 Registration of Key Ordering Privileges ........................................... 12 

2.4.5 Ordering Key.................................................................................... 13 

2.4.6 Controlling the Use of Keys ............................................................. 14 

2.4.7 Replacing Key.................................................................................. 14 

2.4.8 COMSEC Accounting ...................................................................... 14 

3 Key Ordering Roles and Responsibilities ......................................................... 15 

3.1 Overview ....................................................................................................... 15 

3.2 Departmental Security Officer (DSO)/IT Security Coordinator (ITSC)/ 

Departmental COMSEC Authority (DCA)...................................................... 15 

3.3 Controlling Authority...................................................................................... 16 

3.4 Traditional Key Ordering Privileges............................................................... 16 

3.4.1 Ordering Privilege Manager (OPM) ................................................. 16 

Table of Contents May 2006 v


3.4.2 Short Title Assignment Requester (STAR) ...................................... 17 

3.4.3 Authorized ID (Auth ID).................................................................... 17 

3.5 Modern Key Ordering Privileges ................................................................... 17 

3.5.1 Key Management Authority (KMA) .................................................. 17 

3.5.2 User Representative ........................................................................ 17 

3.6 U.S. Key Ordering Privileges......................................................................... 18 

3.6.1 General............................................................................................ 18 

3.6.2 U.S. Command Authority ................................................................. 18 

3.6.3 U.S. User Representative ................................................................ 18 

4 Registration and Privilege Management ........................................................... 19 

4.1 General ......................................................................................................... 19 

4.1.1 Registration...................................................................................... 19 

4.1.2 Privilege Management ..................................................................... 20 

4.1.3 Key Ordering.................................................................................... 21 

4.2 Forms and Notices ........................................................................................ 22 

4.3 Appointment Certificate Form........................................................................ 23 

4.3.1 General............................................................................................ 23 

4.3.2 New Appointment ............................................................................ 23 

4.3.3 Change of Personnel ....................................................................... 24 

4.4 STU III PER Form ......................................................................................... 24 

4.4.1 General............................................................................................ 24 

4.4.2 Request Type .................................................................................. 24 

4.4.3 DAO Code ....................................................................................... 24 

4.4.4 DAO Description .............................................................................. 25 

4.4.5 EKMS Use Indicator ........................................................................ 26 

4.4.6 Requesting Ordering Privileges for Other EKMS Accounts ............. 26 

4.4.7 Authorized Key Type ....................................................................... 26 

4.4.8 Maximum Key Classification ............................................................ 27 

4.4.9 Class 6 Codes ................................................................................. 27 

4.5 SDNS PER Form .......................................................................................... 28 

4.5.1 General............................................................................................ 28 

4.5.2 Request Type .................................................................................. 28 

4.5.3 Requesting Ordering Privileges for Other EKMS IDs....................... 28 

4.5.4 Partition Code .................................................................................. 28 

4.5.5 Authorized Key Type ....................................................................... 28 

4.5.6 Key Purpose .................................................................................... 29 

4.6 MSK PER Form............................................................................................. 30 

4.6.1 Requesting Ordering Privileges for Other EKMS IDs....................... 30 

4.6.2 Request Type .................................................................................. 30 

4.7 Traditional PER Form.................................................................................... 30 

4.8 PER Confirmation/Rejection Notice (PER CRN) ........................................... 31 

4.9 Ordering Privilege Notice (OPN) ................................................................... 31 

5 Key Orders........................................................................................................... 33 

5.1 Key Ordering Process ................................................................................... 33 

5.1.1 Overview.......................................................................................... 33 

5.1.2 Interaction with User Community to Determine Key Requirements . 33 

vi May 2006 Table of Contents


5.1.3 Validate Security Information ........................................................... 33 

5.1.4 Preparation of Key Order Requests................................................. 33 

5.1.5 Submission of Key Order Requests................................................. 34 

5.1.6 Classification/Protection of Key Order Requests ............................. 34 

5.1.7 Validation of Key Order Requests.................................................... 34 

5.1.8 Monitor Status of Key Order Requests ............................................ 34 

5.1.9 Notification to the COMSEC Custodian ........................................... 35 

5.2 STU III Key Order Request Form .................................................................. 35 

5.2.1 General............................................................................................ 35 

5.2.2 EKMS Transaction Number ............................................................. 35 

5.2.3 Type of Key...................................................................................... 35 

5.2.4 EKMS STU III Key Order ................................................................. 36 

5.2.5 Delivery Mechanism ........................................................................ 36 

5.2.6 Classification of Key ........................................................................ 37 

5.2.7 Class 6 Code ................................................................................... 37 

5.2.8 DAO Code ....................................................................................... 37 

5.2.9 Additional Identification Data ........................................................... 37 

5.2.10 Remarks .......................................................................................... 38 

5.3 SDNS Key Order Request Form ................................................................... 38 

5.3.1 General............................................................................................ 38 

5.3.2 Transaction Number ........................................................................ 38 

5.3.3 Partition Code .................................................................................. 38 

5.3.4 Equipment Type............................................................................... 38 

5.3.5 Key Type.......................................................................................... 38 

5.3.6 Access Control Schedule................................................................. 39 

5.3.7 ASCII ID........................................................................................... 39 


5.4 MSK Key Order Request Form ..................................................................... 40 

5.4.1 General............................................................................................ 40 

5.4.2 Transaction ID ................................................................................. 40 

5.4.3 Type of Key...................................................................................... 40 

5.4.4 EKMS Use Indicator ........................................................................ 40 

5.4.5 Free Form ID ................................................................................... 41 

5.5 Traditional Key Order Request Form ............................................................ 41 

5.5.1 General............................................................................................ 41 

5.5.2 Transaction Number ........................................................................ 41 

5.5.3 Order Types..................................................................................... 41 

5.5.4 Short Title ........................................................................................ 42 

5.5.5 Distribution Control .......................................................................... 42 

5.5.6 Compatible Short Title ..................................................................... 42 

5.5.7 Authorized IDs ................................................................................. 42 


5.5.9 CRYPTO Caveat ............................................................................. 42 

5.5.10 Handling Restrictions....................................................................... 43 

5.5.11 Release............................................................................................ 43 

5.5.12 Key Use ........................................................................................... 43 

Table of Contents May 2006 vii


5.5.13 Key Purpose .................................................................................... 43 

5.5.14 Cryptonet Size ................................................................................. 43 

5.5.15 Crypto Period................................................................................... 44 

5.5.16 Segment Per Edition........................................................................ 44 

5.5.17 Supersession Rate .......................................................................... 44 

5.5.18 Effective Date .................................................................................. 44 

5.5.19 In-Place Date ................................................................................... 44 

5.5.20 Standing Order ................................................................................ 44 

5.5.21 Edition Information........................................................................... 44 

5.5.22 Distribution Profile............................................................................ 44 

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

Initiating (TRI) .................................................................................. 44 

5.6 Order Confirmation/Rejection Notice (Order CRN) ....................................... 45 

Glossary....................................................................................................................... 47 

Bibliography/References ............................................................................................ 59 

Annex A – CSE Points of Contact.............................................................................. 61 

Annex B – Directive on the Control of STU III Key for Sensitive Compartmented 

Information (SCI) Applications................................................................ 63 

Annex C – Appointment Certificate ........................................................................... 65 

Annex D – STU III Privilege Establishment Request (STU III PER) Form .............. 67 

Annex E – SDNS Privilege Establishment Request (SDNS PER) Form ................. 69 

Annex F – MSK Privilege Establishment Request.................................................... 71 

(MSK PER) Form.......................................................................................................... 71 

Annex G – Traditional Privilege Establishment Request (Traditional PER) Form. 73 

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

CRN) .......................................................................................................... 75 

Annex I – Ordering Privilege Notice (OPN) ............................................................... 77 

Annex J – STU III Key Order Request Form.............................................................. 79 

Annex K – SDNS Key Order Request Form............................................................... 81 

Annex L – MSK Key Order Request Form................................................................. 83 

Annex M – Traditional Key Order Request Form...................................................... 85 

viii May 2006 Table of Contents


List of Figures 

Figure 1 – GoC EKMS..................................................................................................... 4 

Figure 2 – Key Management Functions......................................................................... 12 

Figure 3 – Ordering Privilege Hierarchy ........................................................................ 15 

Figure 4 – Registration of Modern Key Ordering Privileges .......................................... 19 

Figure 5 – Registration KMA/OPM ................................................................................ 20 

Figure 6 – Registration User Representative/STAR...................................................... 20 

Figure 7 – Privilege Management – PER Rejected by the CMAC................................. 21 

Figure 8 – Key Ordering Process .................................................................................. 22 

List of Figures May 2006 ix



x May 2006 List of Figures


List of Tables 

Table 1 – STU III Key Short Title Examples .................................................................... 7 

Table 2 – SDNS Key Short Title Examples ..................................................................... 8 

Table 3 – MSK Key Short Title Examples ....................................................................... 8 

Table 4 – Traditional Key Short Title Examples............................................................... 8 

Table 5 – Examples of Key Material Editions .................................................................. 9 

Table 6 – Registration and Privilege Management Request Forms .............................. 22 

Table 7 – Key Order Request Forms and Notices......................................................... 33 

List of Tables May 2006 xi



xii May 2006 List of Tables


List of Abbreviations and Acronyms 

ALC 

ASCII 

Auth ID 

BET 

CBI 

CCD 

CCEB 

CCF 

CCF KPF 

CCI 

CKMS 

CKMU 

CMAC 

(C)NES 

COMSEC 

CRN 

CRYPTO 

CSE 

DAO 

DCA 

DND 

DSO 

DTD 

EKR 

FFK 

GoC 

GoC EKMS 

GoC PKI 

GSP 

GSTN 

GSTN KMS 

IKMS 

ITSC 

KEK 

KMA 

KMID 

KP 

KPK 

KSD 

Accounting Legend Code 

American Standard Code for Information Exchange 

Authorized Identification 

Bulk Encrypted Transaction 

Certificate Based Infrastructure 

Canadian Cryptographic Doctrine 

Combined Communications Electronic Board 

Canadian Central Facility 

CCF Key Production Facility 

Controlled Cryptographic Item 

Canadian Key Management System (Now known as GSTN) 

Canadian Key Management Unit 

Cryptomaterial Management and Assistance Centre 

Canadian Network Encryption System 

Communications Security 

Confirmation/Rejection Notice 

Cryptographic 

Communications Security Establishment 

Department Agency Organization 

Departmental COMSEC Authority 

Department of National Defence 

Departmental Security Officer 

Data Transfer Device 

Electronic Key Replacement 

FIREFLY Key 

Government of Canada 

GoC Electronic Key Management System 

GoC Public Key Infrastructure 

Government Security Policy 

Government Secure Telephone Network 

Government Secure Telephone Network Key Management System 

IRIS Key Management System 

Information Technology Security Coordinator 

Key Encryption Key 

Key Management Authority 

Key Material Identifier 

Key Processor 

Key Production Key 

Key Storage Device 

List of Abbreviations and Acronyms May 2006 xiii


LAN 

LMD 

MSK 

NATO 

NCMCS 

NCOR 

NDA 

NFK 

OPM 

OPN 

PCM 

PER 

QKEK 

RA 

SDNS 

STAR 

STE 

STU III 

TEK 

TrKEK 

TPI 

WAN 

Local Area Network 

Local Management Device 

Message Signature Key 

North Atlantic Treaty Organization 

National COMSEC Material Control System 

National Central Office of Record 

National Distributing Authority 

Netted FIREFLY Key 

Order Privilege Manager 

Order Privilege Notification 

Privilege Certificate Manager 

Privilege Establishment Request 

Quadrant Key Encryption Key 

Registration Authority 

Secure Data Network System 

Short Title Assignment Requester 

Secure Terminal Equipment 

Secure Telephone Unit – Third Generation 

Traffic Encryption Key 

Transfer Key Encryption Key 

Two Person Integrity 

Wide Area Network 

xiv May 2006 List of Abbreviations and Acronyms


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 (GoC 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 GoC 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. 

Introduction May 2006 1



2 May 2006 Introduction


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 GoC 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 GoC EKMS, includes the CKMS, which is now 

referred to as the GSTN Key Management System (GSTN KMS). The GoC EKMS is one of 

three national key management systems operated by the CCF at CSE. The other two systems are 

the GoC Public Key Infrastructure (GoC PKI) and the GoC FORTEZZA Certificate Based 

Infrastructure (GoC FORTEZZA CBI). For the purposes of this publication, all references to the 

CCF encompass only the GoC EKMS portion of the CCF. The CCF responsibilities associated 

with the GoC PKI and the GoC FORTEZZA CBI are described separately from this document. 

Key and Key Management Concepts May 2006 3


2.2 GoC EKMS Overview 

2.2.1 General 

The GoC 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 GoC 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 GoC EKMS, refer to the 

Canadian Cryptographic Doctrine for the Government of Canada Electronic Key Management 

System (GoC EKMS) (CCD-06). 

Telephone Network 

Government Secure 

Telephone (GSTN) Network e.g. 

STEs 

eg . 

STU IIIs 

CipherTACs 

STEs 

STU - IIIs 

Systems 

GoC Departments 

Support Personnel 

Point Point - to to - Point Point 

Link Encryption 

Link 

eg 

Encryption 

. 

KG - 

KG - 81 

KG - 84 

KIV - 7 

LMD/KP 

LANs 

Facility 

(CCF) 

Systems 

DSO/ITSC 

DCA 

Secure Radio 

Communications 

Secure Radio 

Communications 

e.g. Light 

Assault Eg . Light Radio 

(AN/PRC Assault Radio 521) 

- 

LMD/KP 

DTDs 

LMD/DTD 

CKMU 

NDA 

LMD/KP 

LAN 

CMAC 

NCOR Assistance 

• RA Centre 

• PCM 

• Account Managers 

CCF 

KPF 

Support Personnel 

NCOR 

LMD/KP 

LAN 

Key 

Requirements 

•Key Order 

• Managers 

CCF KPF 

•U.S. KMA 

• U.S. User Rep 

• Key Generators 

• Key Distributors 

Controlling Authority 

Auth ID 

KMA 

User Reps 

STAR 

OPM 

Secure Network 

Secure Encryption Network Systems 

Encryption e.g. Systems 

TACLANE eg . 

TACLANE CNES 

FASTLANE 

CNES 

Figure 1 – GoC EKMS 

2.2.2 Canadian Central Facility (CCF) 

2.2.2.1 General 

The CCF is responsible for the overall management of the GoC EKMS and is privileged for all 

GoC EKMS root functions. The CCF is comprised of automated systems and the personnel who 

provide user assistance, operational support and systems administration. 

4 May 2006 Key and Key Management Concepts


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: 

a. Registering Key Management Authority (KMA), Ordering Privilege Manager (OPM), User 

Representatives and Short Title Assignment Requestor (STAR); 

b. Processing Privilege Establishment Requests (PERs); 

c. Receiving and processing orders for cryptographic key; and 

d. Establishing and maintaining lead time schedules for the distribution of cryptographic key. 

The NCOR is responsible for: 

a. Maintaining a master inventory of accountable COMSEC material, including cryptographic 

key produced in or entrusted to Canada; 

b. Ensuring that the minimum COMSEC accounting standards detailed in the COMSEC 

Material Control Manual (ITSG-10) are met; 

c. Acting as the national Registration Authority (RA) for the establishment of COMSEC 

accounts and the registration of account personnel; and 

d. Acting as Privilege Certificate Manager (PCM) for the assignment of account level 

privileges. 

The Assistance Centre is responsible for: 

a. Providing day-to-day operational support for users via telephone, email, voice mail, fax and 

the EKMS Message Server; 

b. 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; 

c. Providing on-line support through the CMAC Web Site 

(http://www.cse-cst.gc.ca/en/services/cmac/cmac.html); and 

d. Providing assistance with all key management problems related to the GoC 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 GoC 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 GoC EKMS Cryptographic Key 

2.3.1 Traditional and Modern Key 


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 Ciphertext : Encrypted message. 



a. STU III Key; 

b. Secure Data Network System (SDNS) Communications Key; and 

c. Message Signature Key (MSK). 

2.3.2 Identification of Key 


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 

Canadian STU III 

Key Short Title 

Key Type & 

Classification 

Delivery Method 

Equipment Type 

CDNAU 1001 Type 1 Operational – 

PROTECTED CRYPTO 


CONFIDENTIAL CRYPTO 


SECRET CRYPTO 


TOP SECRET CRYPTO 

CDNAU 1005 Type 1 Seed – 

All Classifications 

CDGAU 1006 Type 2 Operational – 

UNCLASSIFIFED 

Key Storage Device STU III, KOV 14C, STE 





Key Storage Device STU III Type 2 



Table 2 – SDNS Key Short Title Examples 

Canadian SDNS 

Key Short Titles 



Key Purpose Delivery Method Equipment Types 

CAFAU 2001 Type 1 Operational – 


Operational 

Key Storage 

Device 

CNES 

CAFZU 2002 Type 1 Operational – 

UNCLASSIFIED 

CRYPTO 

Test 

CNES 

CAFZE 3001 

845550 

Type 1 Operational – 

UNCLASSIFIED 

CRYPTO 

Test 

Data Transfer 

Device 

TACLANE KG 175 

CAFZD 3001 

845550 


UNCLASSIFIED 

CRYPTO 

Test 

Bulk Encrypted 

Transaction 


CAFAD 3002 

845550 



Operational 


Transaction 


CAFAE 3002 

845550 



Operational 

Data Transfer 

Device 


Table 3 – MSK Key Short Title Examples 

Canadian MSK 

Key Short Titles 




CAKAU 11111 Type 1 Operational – 


Operational 


Device 

CNES 

CAKZU 11111 Type 1 Operational – 

UNCLASSIFIED 

CRYPTO 

Test 


Device 

CNES 

Table 4 – Traditional Key Short Title Examples 

Canadian 

Traditional Key 

Short Titles 




CSE/537/878 Type 1 Operational – 


CAKZE 2 8455550 Type 1 Operational – 

UNCLASSIFIED 

CRYPTO 

CAKZD 2 8455550 Type 1 Operational – 

UNCLASSIFIED 

CRYPTO 

PC 841000 

845999 

Certificate – 

UNCLASSIFIED 

Operational Key tape KG 84 

Test 

Test 

Operational 

Data Transfer 

Device 


Transactions 

Electronic via CCF 

Message Server 



KOK 22 



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 

Product Equipment Type Short Title Edition 

STU III Key STU III CDNAU 1005 PD 

STU III Key Changeover Period STU III CDNAU 1005 PD, PE 

Key tape KG 84 CSE 53799 AA 

SDNS Key KG 175 CAFAD 3002 845550 020001 

MSK Key KOK 22 CAKAU 11111 000201 

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: 

a. 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; 

b. 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; 

c. 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. 

e. 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; 

f. 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; 

g. 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: 

a. 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; 



b. 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; 

c. Disk and file encryption – The process whereby information held on a computer is encrypted 

using software or hardware encryption/decryption products; 

d. 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; 

e. Radio – Field radios used for both tactical and strategic operations encrypt both voice and 

data communications within a selected group; 

f. 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 

h. 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 cryptoequipment 

(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 cryptoequipment 

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. 



COMSEC 

Accounting 

Identify 

Requirement 

for Key 

Register 

COMSEC 

Account 

Update 

Replace 

Destroy Key 

Register Key 

Ordering 

Privileges 

Control Use 

of Key 

Order Key 

Distribute 


Generate 


Figure 2 – Key Management Functions 

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: 

a. Appointment of departmental personnel authorized to order key; and 

b. Registration of key ordering privileges for an EKMS account. 



2.4.5 Ordering Key 


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: 

a. Allow two to three weeks for delivery of all types of key generated by the CCF; and 

b. 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 GoC. 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: 

a. Paper Media (Key Tape, Books); 

Key and Key Management Concepts May 2006 13


b. Bulk Encrypted Transaction (BET); 

c. Magnetic Media; 

d. Data Transfer Device (DTD); 

e. Key Storage Device (KSD); 

f. PCMCIA Card; and 

g. 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: 

a. Seed Key Conversion - load new seed key and electronically download operational key from 

the CCF; 

b. Real-time rekey - electronically replace operational key via secure communications with the 

CCF; 

c. Store-and-forward rekey - electronically replace operational key via request and response 

transactions with the CCF; and 

d. 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). 

Departmental Security Officer (DSO) / Information Technology Security Coordinator (ITSC) / 

Departmental COMSEC Authority (DCA) 

Modern Key Ordering Privileges 

Traditional Key Ordering Privileges 

| | 

Key Management Authority (KMA) 

Ordering Privilege Manager (OPM) 

| | 

User Representative 

Short Title Assignment Requester (STAR) 

| 

Authorized ID (Auth ID) 

Figure 3 – Ordering Privilege Hierarchy 

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: 

a. Appointing a new KMA, OPM and Controlling Authority, as applicable; 

b. Terminating the appointment of the KMA and OPM, when required; and 

c. Ensuring that the KMA and OPM receive the training necessary to perform their duties. 

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. 

Key Ordering Roles and Responsibilities May 2006 15


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: 

a. The number of cryptonet members and any changes to this number; 

b. 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; 

c. The key change time for the cryptonet; 

d. The purpose, use and type of key required; 

e. The method of delivery for the key; 

f. Any special handling and distribution controls or restrictions; 

g. The prescribed amount of reserve or contingency key to be ordered to ensure an adequate 

supply for potential emergency supersessions and other unplanned events; 

h. The supersession of the key; 

i. The promulgation of status information; and 

j. 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: 

a. Authorized to perform all the ordering functions associated with the OPM, STAR and 

Auth ID privileges; 

b. Responsible for selecting individuals and requesting an EKMS account’s OPM and STAR 

privileges from the CCF; 

c. Responsible for the key ordering training through the ITS Learning Centre at CSE; and 

d. 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. 

16 May 2006 Key Ordering Roles and Responsibilities


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: 

a. Cause the generation of key for a specific short title; 

b. Specify/revise the distribution profile for a specific short title; 

c. Grant or revoke other accounts’ Auth ID privilege for a specific short title; 

d. Request revision of the attributes of a specific short title; and 

e. 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: 

a. The selection and registration of User Representatives who will be permitted to order 

Modern key from the CCF; 

b. 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; 

c. The training of User Representatives through the ITS Learning Centre at CSE; 

d. 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. 

Key Ordering Roles and Responsibilities May 2006 17


The User Representative is responsible to: 

a. Interact with the user community to determine key requirements to support newly acquired 

equipment, changes in identification information or to rekey an equipment; 

b. Verify that users are cleared to the classification level of the key that they are requesting; 

c. Prepare and submit key orders to CMAC; 

d. Interact with the CMAC to monitor the status of key orders; and 

e. 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 GoC 

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 GoC departments requesting U.S. 

key and submits these orders to the U.S. Central Facility for processing and generation. The 

GoC department submitting the order must have U.S. key ordering privileges registered with the 

CMAC. 

18 May 2006 Key Ordering Roles and Responsibilities


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. 

Key Management 

Authority (KMA) 

EKMS Account 

Appointment Certificate (User Representative) 

Registration CRN 

STU III PER/SDNS PER/MSK PER 

PER CRN 

Cryptomaterial 

Management & 

Assistance Centre 

(CMAC) 

User 

Representative 

EKMS Account 

Ordering Privilege Notice (OPN) 

Ordering Privilege Notice (OPN) 

Appointment 

Certificate (KMA) 

Registration CRN 

COR 

Of User 

Representative’s 

EKMS Account 

Departmental 

COMSEC 

Authority 

(DCA) 

4.1.1 Registration 

Figure 4 – Registration of Modern Key Ordering Privileges 

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 and Privilege Management May 2006 19


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. 

Departmental 

Security Officer 

(DSO) 

or 

Departmental 

COMSEC Authority 

(DCA) 

Appointment Certificate 

Registration Acknowledgement 


Management & 

Assistance 

Centre (CMAC) 

Figure 5 – Registration KMA/OPM 

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. 



or 


Registration Acknowledgement 


Management & 

Assistance 

Centre (CMAC) 

Order Privilege 

Manager (OPM) 

4.1.2 Privilege Management 

Figure 6 – Registration User Representative/STAR 

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 

20 May 2006 Registration and Privilege Management


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 



Or 

Order Privilege 

Manager (OPM) 

SDNS PER/MSK PER/STU III PER 

PER CRN 

Traditional PER 

Traditional PER CRN 


Management & 


(CMAC) 

Privileged 

EKMS ID 

SDNS OPN / MSK OPN 

Privileged 

EKMS ID’s 

COR 

SDNS OPN / MSK OPN 

Figure 7 – 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. 



EKMS ID 

submitting key 

order 

SDNS/MSK/Trad/STU III key order 

SDNS/MSK/ Trad/STU III order CRN 


Management & 


(CMAC) 

Figure 8 – Key Ordering Process 

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 

Form/Notice Description/Use Sample 

Form 

Article 

Reference 


STU III Privilege 

Establishment Request 

(STU III PER) 

SDNS Privilege Establishment 

Request (SDNS PER) 

MSK Privilege Establishment 

Request (MSK PER) 

Traditional Privilege 


(Traditional PER) 

PER Confirmation/Rejection 

Notice (PER CRN) 

Identifies all of the information required to appoint 

or terminate the appointment of departmental 

personnel authorized to perform a key order role 

Identifies all of the information required to add, 

replace or delete Department/Agency/ Organization 

(DAO) Codes, DAO descriptions and the attributes 

associated with the DAO Code 

Identifies all the information required to add, 

replace or delete SDNS key ordering privileges at 

an EKMS ID 

Identifies all of the information required to add or 

delete MSK key ordering privileges at an EKMS ID 

Identifies all of the information required to add, 

replace or cancel OPM or STAR ordering privileges 

associated with an EKMS ID 

Identifies the privileges granted or revoked in 

response to a Traditional, STU III, SDNS or MSK 

PER 

Annex C 4.3 

Annex D 4.4 

Annex E 4.5 

Annex F 4.6 

Annex G 4.7 

Annex H 4.8 



Form/Notice Description/Use Sample 

Form 

Article 

Reference 

Ordering Privilege Notice 

(OPN) 

Identifies the OPM, STAR, or User Representative 

privileges granted by the generating EKMS ID 

(CCF) to another EKMS ID in response to an 

approved Traditional, SDNS or MSK PER 

Annex I 4.9 

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: 

a. Is a Canadian citizen; 

b. Has been granted a security clearance commensurate with the highest sensitivity level of the 

information or material being accessed; 

c. Has received a COMSEC briefing, if required to physically handle the key (i.e., also the 

COMSEC Custodian, Alternate Custodian, End User); and 

d. 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: 

a. Add: selecting this option will result in one STU III privilege being added to the EKMS ID. 

The CMAC will assign the DAO code; 

b. Modify: selecting this option will result in modifying an existing STU III privilege. Provide 

the DAO code that will be modified; 

c. 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 


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: 

a. The first line of the DAO description must specify the sponsoring DAO, or a major portion 

thereof, or a Government Contractor; 

b. The department specified in the DAO description must be representative of the DAO for 

which the KMA is appointed; 

c. Each DAO description must be unique not only to the department but also within all 

departments; 

d. Each DAO description can only be registered and used by one User Representative; 

e. 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: 

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



f. Two keyboard symbols that cannot be used in the DAO description are the asterisk (*) and 

the backward slash (\); 

g. DAO descriptions should be displayed in bilingual format; 

h. 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 

i. 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 


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: 

a. 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 

b. 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: 

a. The only valid classification for Type 2 Operational key is UNCLASSIFIED, this also 

includes PROTECTED A and B; 

b. 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 

c. 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: 

Code 

Displayed Message 

01 PROTECTC 

02 PROTECTB 

03 PROTECTA 

10 SCI 

20 US 

99 TEST 

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. 


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. 


a. Add: selecting this option will result in one SDNS privilege being added to the EKMS ID; 

b. 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 


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 





The possible key type levels for SDNS key include: 

a. 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); 



b. Type 1 key is used to denote key that is authorized for the protection of classified, 

unclassified and protected 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: 

a. Foreign; 

b. Coalition; 

c. CCEB; 

d. NATO; and 

e. 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: 

a. 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; 



b. 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; 

c. 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. 

d. 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; 

e. 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; 

f. 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 



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. 


a. Add: selecting this option will result in one MSK privilege being added to the EKMS ID; 

b. 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: 

a. Initial action allows the DCA to add either OPM or STAR privileges; and 



b. 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: 

a. Key an equipment when it is first acquired and installed; 

b. Restore an equipment to service after it has been zeroized (e.g., operational key erased to 

facilitate maintenance action or repairs); 

c. Change identification information as a result of a re-organization, etc.; 

d. Perform testing or maintenance on equipment; and 

e. 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 

Key Order Request 

Forms/Notices 

Description/Use 

Sample 

Form 

Article 

Reference 

STU III Key Order 

Request 

SDNS Key Order 

Request 

MSK Key Order 

Request 

Used to order seed key or operational key for the STU III, 

CipherTAC and KOV 14C 

Annex J 5.2 

Used to order FIREFLY key for SDNS equipment Annex K 5.3 

Used to order message signature key for the Key 

Processor (KP) 

Annex L 5.4 

Key Orders May 2006 33


Key Order Request 

Forms/Notices 

Description/Use 

Sample 

Form 

Article 

Reference 

Traditional Key Order 

Request 

Order Confirmation/ 

Rejection Notice 

(Order CRN) 

Ordering Privilege 

Notice (OPN) 

Used to order physical key tape or KG 175 TACLANE 

Pre-Placed key 

Used to notify the EKMS account submitting the order of 

the status of each item that was ordered 

Used to notify the EKMS account that they are authorized 

to order key from the account named in the OPN 

Annex M 5.5 

Annex N 5.6 

Annex I 4.9 

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: 

a. EKMS x.400; 

b. Message Server; 

c. First class mail; 

d. Courier; 

e. Secure or non-secure facsimile; 

f. 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. 

34 May 2006 Key Orders


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 





The possible key type levels for STU III key include: 

a. 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 

b. 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. 



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: 

a. 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; 

b. If the PROTECTED designation is indicated, the appropriate Class 6 Code must be included; 

c. The only valid classification for Type 2 Operational key is UNCLASSIFIED; 

d. 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 

e. 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 





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.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 GoC 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. 


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: 

NOTE 2: 

If TPI is selected for key delivered in electronic format, certain LMD/KP 

operations will require that a second operator be logged on. 

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: 

a. 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; 

b. KEK – Key Encryption Key – used to encrypt keys; 

c. KPK – Key Production Key – used to produce keys; 

d. NFK – Netted FIREFLY Key; 

e. QKEK – Quadrant Key Encryption Key; 

f. TEK – Traffic Encryption Key – used to encrypt traffic over a communications channel; 

g. TSK – TRANSEC Key – used to protect a communications channel from traffic analysis; 

h. 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 GoC EKMS, continuously accountable, with or without an 

accounting number, to a COR. 

ALC-7: Electronic key tracked by GoC 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: 

i) Key Purpose = M (maintenance); 

ii) Key Purpose = T (training); 

iii) Key Purpose = Z (on-the-air testing); and 

iv) 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) 

Account Registration 

Allied Key 

Authentication 

Authorized ID 

Benign 

Benign Fill Key 

Benign Keying 

Bulk Encrypted Transaction (BET) 

Numeric code used to indicate the minimum 

accounting controls for COMSEC items included 

in the National COMSEC Material Control 

System (NCMCS). 

Process by which GoC EKMS accounts are 

identified and associated with their administrative 

and configuration attributes. 

Key used by at least two different nations. Allied 

key is generated by one of the nations and 

released for use to other nations. 

A measure designed to provide protection against 

fraudulent transmissions or imitations by 

establishing the validity of a transmission, 

message or originator. 

EKMS accounts that are authorized to order a 

specific short title of Traditional key. 

Condition of cryptographic data such that it 

cannot be compromised by human access to the 

data. 

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. 

Keying method that generates and encrypts key in 

GoC 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. 

An EKMS transaction containing encrypted 

key(s), encrypted key attributes, and encrypted 

accounting reports (transfer or issue). 

Glossary May 2006 47


Canadian Central Facility (CCF) 

Class 6 Code 

Class 6 Field 

Classified Information 

Command Authority 

Communications Security (COMSEC) 

Compromise 

COMSEC Account 

A facility located at CSE which provides 

centralized key management services for all forms 

of key. 

A two-digit numeric code corresponding to a 

specific 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. 

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. 

See Key Management Authority (KMA). 

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. 

Unauthorized disclosure, destruction, removal, 

modification or interruption. 

Administrative entity, identified by an EKMS ID, 

used to maintain accountability, custody and 

control of accountable COMSEC material. 

48 May 2006 Glossary


COMSEC Custodian 

COMSEC Equipment 

COMSEC Incident 

COMSEC Material 

Confidentiality 

Confirmation/Rejection Notice (CRN) 

Controlled Cryptographic Item (CCI) 

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. 

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. 

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. 

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. 

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. 

A notice created as a result of processing a key 

order or a Privilege Establishment Request (PER). 

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 

CRYPTO 

Cryptonet 

Cryptoperiod 

DAO Code 

Data Transfer Device (DTD) 

Decryption 

Departmental COMSEC Authority 

(DCA) 

Departmental Security Officer (DSO) 

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. 

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. 

See ITSG-10 or ITSD-01 for definition. 

A specific period of time during which a 

cryptographic key is in effect. 

A unique Department/Agency/Organization 

identifier for use in the user specific parts of a 

FIREFLY key. 

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. 

A process that converts encrypted voice or data 

information into plain form by reversing the 

encryption process. 

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. 

The individual responsible for developing, 

implementing, maintaining, coordinating and 

monitoring a departmental security program 

consistent with the GSP and its standards. 



Destruction 

Digital Signature 

Digraph 

Distribution Profile 

DTD TrKEK 

Dual Media Key 

Edition 

Effective Date 

EKMS Account 

EKMS ID 

Encryption 

The process of destroying (e.g., shredding, 

burning, etc.) physical COMSEC material or 

destroying electronic key through zeroization or 

fill into an end equipment. 

A cryptographic transformation of data which, 

when appended to a data unit, provides the 

services of origin authentication, data integrity, 

and signer non-repudiation. 

A two character code that identifies the number of 

key segments in an edition and the key segment 

cryptoperiod. 

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. 

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. 

Compatible key that exists in both electronic and 

physical format. 

Alpha or numeric string that identifies one 

issuance of a series, or specific version of, 

COMSEC material associated with the same short 

title. 

Date when a key or other data is intended to be 

first used. 

A generic term that encompasses an EKMS 

Element or a COMSEC Account. 

Unique identifier of an EKMS account. 

The transformation of readable data into an 

unreadable stream of characters using a reversible 

coding process. 



Exercise Key 

Explicit Key 

Fill 

Fill Device 

Foreign Key 

Key intended to safeguard transmissions 

associated with exercises. 

Any key which is provided automatic control by 

EKMS in accordance with distribution restrictions 

prescribed by the controlling authority. 

The process of providing key material to an end 

crypto-equipment for its internal use. 

COMSEC item used to transfer or store key in 

electronic form or to insert key into a cryptoequipment. 

National key from another nation. 

NOTE: Only under extreme circumstances 

should national key be used by another nation or 

alliance. 

Generation 

GoC EKMS 

Government Secure Telephone Network 

(GSTN) 

Handling Restrictions 

Hard Copy Key Products 

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. 

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. 

A computer based system which supports key 

management for the STU III through provision of 

key generation and distribution within Canada. 

A means of controlling the use of Traditional key. 

The choices are no restrictions, Two Person 

Integrity (TPI), or Benign Fill only. 

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

physical format. 



Implicit Key 

Integrity 


Key Attributes 

Key Distribution 

Key Encryption Key (KEK) 


Key Management Authority (KMA) 

Any key whose handling characteristics are 

determined solely by policy and procedural 

means. 

The accuracy and completeness of information 

and assets and the authenticity of transactions. 

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. 

The characteristics assigned to a specific key 

short title (e.g., ALC, key purpose, key use, etc.). 

Secure controlled movement of key from the 

point of generation or storage to the point of use 

or re-distribution. 

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. 

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) 

Key Production Key (KPK) 

Key Storage Device (KSD) 

Local Management Device (LMD) 

Message Signature Key (MSK) 

Modern Key 

National Affiliation Identifier (NAI) 

National Central Office of Record 

(NCOR) 

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 used to initialize a key stream generator for 

the production of other electronically generated 

keys. 

A fill device used to store, transport, and transfer 

key and other system data. 

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. 

Cryptographic material used in a digital signature 

process that operates on a message to assure 

message source authentication, message integrity, 

and source non-repudiation. 

A collective name for FIREFLY-based key such 

as STU III key, SDNS Communications key and 

MSK. 

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. 

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) 

National Key 

NATO Key 

Netted FIREFLY Key 

Non-Repudiation 

Operational Key 

Ordering Privilege Manager (OPM) 

Privilege Certificate Manager (PCM) 

Privilege Establishment Request (PER) 

Register Number 

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. 

Key used solely by the nation that generated the 

key. 

Key that has been produced for use by NATO 

countries. 

A FIREFLY key that is managed in the same way 

as a Traditional cryptonet. 

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. 

Key intended for use on-the-air for protection of 

operational information or for the production of 

secure electrical transmission of key streams. 

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. 

An EKMS account which is authorized to create 

KP Privilege Certificates for a specific set of KPequipped 

EKMS accounts. 

Transaction to request the registration, 

modification, or deletion of key ordering 

privileges (i.e., OPM, STAR, User 

Representative) at a generating account. 

Used to uniquely identify individual copies of key 

which have the same short title and edition. 

Synonymous with accounting number. 



Rekey 

Release Field - LCMS 

Secure Data Network System (SDNS) 

Secure Terminal Equipment (STE) 

Secure Telephone Unit – Third 

Generation (STU III) 

Seed Key 

Segment 

Sensitive Compartmented Information 

(SCI) 

SCI Key 

Short Title 

The process by which all FIREFLY keying 

material, including Benign fill FIREFLY, is 

periodically replaced. 

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. 

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. 

A government approved telecommunication 

terminal designed to provide secure voice and 

data connectivity, conferencing capability, and 

other capabilities based on a layered 

communications model. 

A government approved telecommunication 

terminal designed to protect the transmission of 

sensitive or classified information in the voice, 

data, or facsimile mode. 

Initial key containing unique information used to 

start an updating or key generation process. 

Traditional key that is valid for one cryptoperiod. 

Intelligence information requiring special controls 

indicating restricted access. 

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. 

Identifying combination of letters and numbers 

assigned to certain COMSEC items to facilitate 

handling, accounting, and control. 



Short Title Assignment Requester 

(STAR) 

Supersession 

Tactical Key 

Test Key 

Traditional Key 

Traffic Encryption Key (TEK) 

Transfer Key Encryption Key (TrKEK) 

Two-person Integrity (TPI) 

Type 0 Key 

Type 1 Cryptographic Equipment 


An EKMS account privileged to request 

assignment of new short titles at a generating 

account. 

Scheduled or unscheduled replacement of a key or 

COMSEC aid with a different edition. 

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. 

Key intended for on-the-air testing of COMSEC 

equipment or systems. 

Term used to reference non-FIREFLY-based key 

that is generated in accordance with established 

procedures. 

Key used to encrypt plain text or to superencrypt 

previously encrypted text and/or decrypt cipher 

text. 

Key used to encrypt and decrypt user key. 

Procedure whereby material is never handled or 

made available to one person only. 

Cryptographic key used to generate a Key 

Encryption Key (KEK) that can be used to bulkencrypt 

keys. 

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. 

Cryptographic key used for the protection of 

classified information up to and including Top 

Secret. 








Zeroize 

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. 

Cryptographic key used for the protection of 

designated information up to and including 

Protected C. 

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. 

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. 

An individual appointed by the Key Management 

Authority (KMA) authorized to order STU III 

key, SDNS key and/or Message Signature Key 

(MSK). 

Remove or eliminate the key from a cryptoequipment 

or fill device. 



Bibliography/References 

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

a. Canadian Cryptographic Doctrine for the AN/CYZ-10/10A Data Transfer Device (CCD-01), 

dated May 1998, Communications Security Establishment. 

b. Canadian Cryptographic Doctrine for the Canadian Network Encryption System (CCD-02), 

dated September 1998, Communications Security Establishment. 

c. Canadian Cryptographic Doctrine for the CipherTAC 2000 (CCD-04), dated January 1999, 

Communications Security Establishment. 

d. Canadian Cryptographic Doctrine for the Canadian Key Management Unit (CKMU) 

(CCD-05), dated April 2000, Communications Security Establishment. 

e. Canadian Cryptographic Doctrine for the Government of Canada Electronic Key 

Management System (GoC EKMS) (CCD-06), draft dated June 2000, Communications 

Security Establishment. 

f. Guidelines for the Application of Communications Security in the Government of Canada 

(ITSD-01), draft dated May 2001, Communications Security Establishment. 

g. Short Title Nomenclature in Canada (ITSG-09), dated October 2001, Communications 

Security Establishment. 

h. Canadian Cryptographic Doctrine for the FORTEZZA PLUS Cryptographic Card 

(KOV 14C) and associated Secure Terminal Equipment (STE) (CCD-11), dated April 2002, 


i. COMSEC Material Control Manual (ITSG-10) (formerly MG-14), January 2003, 


j. Canadian Cryptographic Doctrine for the Local Management Device/ Key Processor 

(LMD/KP) (CCD-07), dated August 2002, Communications Security Establishment. 

Bibliography/References May 2006 59



60 May 2006 Bibliography/References


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@cse-cst.gc.ca 

Unclassified Facsimile: (613) 991- 7440 

Secure Facsimile: (613) 991-8709 

A.3 National COMSEC Incidents Office (NCIO) 


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

Unclassified Facsimile: (613) 991-8565 

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

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


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

A.5 Head, Client Services, Cryptographic Security 


E-mail address: its.client.services@cse-cst.gc.ca 

Unclassified Facsimile number: (613) 991-8565 


A.6 CSE General Inquiries 

Telephone Number: (613) 991-7600 

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

Unclassified Facsimile: (613) 991-8565 


Annex A – CSE Points of Contact May 2006 61


CSE Mailing Address: 


P.O. Box 9703 

Ottawa Postal Terminal 

Ottawa, Ontario, Canada 

K1G 3Z4 

Attn: __________________________________ 

Name Building Position 

CSE Shipping Address: 


719 Heron Road 

Ottawa, Ontario, Canada 

K1G 3Z4 

Attn: __________________________________ 

Name Building Position 

62 May 2006 Annex A – CSE Points of Contact


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 (GoC). 

B.2 Applicability 

This directive applies to all GoC 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 

Departmental Security 

Officer (DSO) 



Sensitive 

Compartmented 

Information (SCI) 

SCI Key 


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. 

The individual responsible for developing, implementing, 

maintaining, coordinating and monitoring a departmental security 

program consistent with the GSP and its standards. 

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. 

Intelligence information requiring special controls indicating 

restricted access. 

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. 

An individual appointed by the Key Management Authority 

(KMA) authorized to order STU III key, SDNS key and/or 

Message Signature Key (MSK). 

Annex B – Directive on the Control 

of STU III Key for SCI Applications 

May 2006 63


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: 

a. Verify the clearance and SCI indoctrination level of the intended users; 

b. Verify that the area in which the STU III terminal is located has been authorized for SCI; and 

c. 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 GoC has no requirement at this time to release SCI key to contractors. 

64 May 2006 Annex B – Directive on the Control of 

STU III Key for SCI Applications


Annex C – Appointment Certificate 

Annex C – Appointment Certificate May 2006 65


66 May 2006 Annex C – Appointment Certificate


Annex D – STU III Privilege Establishment Request 

(STU III PER) Form 

Annex D – STU III Privilege Establishment 

Request 

May 2006 67


68 May 2006 Annex D – STU III Privilege Establishment 

Request


Annex E – SDNS Privilege Establishment Request 

(SDNS PER) Form 

Annex E – SDNS Privilege Establishment 

Request 

May 2006 69


70 May 2006 Annex E – SDNS Privilege Establishment 

Request


Annex F – MSK Privilege Establishment Request 

(MSK PER) Form 

Annex F – MSK Privilege Establishment 

Request 

May 2006 71


72 May 2006 Annex F – MSK Privilege Establishment 

Request


Annex G – Traditional Privilege Establishment Request 

(Traditional PER) Form 

Annex G – Traditional Privilege 


May 2006 73


74 May 2006 Annex G – Traditional Privilege 

Establishment Request


Annex H – Privilege Establishment Request 

Confirmation/Rejection Notice (PER CRN) 

PER CRN 

A 

Protected 

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 Transaction ID Transaction Information Label 

SDNS PER CRN 845550-20050302-55240 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: 

---------------------------------------------------------------------------------------------------------------------- 

NOTHING FOLLOWS 

Annex H – Privilege Establishment Request 

Confirmation/Rejection Notice 

May 2006 75



76 May 2006 Annex H – Privilege Establishment Request 

Confirmation/Rejection Notice


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 Transaction ID Transaction Information Label 

Order Privilege Notice 845550-20050302-55241 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 Seed/Op Ind. EKR Priv. Ind. ALC 

3001 Operational N 

NOTHING FOLLOWS 

Annex I – Ordering Privilege Notice May 2006 77



78 May 2006 Annex I – Ordering Privilege Notice


Annex J – STU III Key Order Request Form 

Annex J – STU III Key Order Request Form May 2006 79


80 May 2006 Annex J – STU III Key Order Request Form


Annex K – SDNS Key Order Request Form 

Annex K – SDNS Key Order Request Form May 2006 81


82 May 2006 Annex K – SDNS Key Order Request Form


Annex L – MSK Key Order Request Form 

Annex L – MSK Key Order Request Form May 2006 83


84 May 2006 Annex L – MSK Key Order Request Form


Annex M – Traditional Key Order Request Form 

Annex M – Traditional Key Order Request 

Form 

May 2006 85


86 May 2006 Annex M – Traditional Key Order Request 

Form

Cryptographic Key Ordering Manual (ITSG-13)

Create successful ePaper yourself

Delete template?

Save as template?