IT Security Bulletin Bulletin de sécurité TI

mindasparagusNetworking and Communications

Jul 14, 2012 (5 years and 1 month ago)

504 views

UNCLASSIFIED / NON CLASSIFIÉ


1


IT Security Bulletin
Bulletin de sécurité TI

December 2008
ITSB-61
décembre 2008

Guidance on the Use of the IP
Security Protocol within the
Government of Canada

Conseils sur l’utilisation du
protocole de sécurité IP (IPsec) au
sein du gouvernement du Canada
Purpose

Objet
The purpose of this Bulletin is to provide
Government of Canada (GC) departments with
guidance on:

• using the Internet Protocol Security (IPsec)
protocol for the protection of Protected A and
Protected B information;

• the approved cryptographic protocols and
algorithms that the Communications Security
Establishment Canada (CSEC) recommends for
use with IPsec; and

• standards and NIST Special Publications that
describe the recommended cryptographic
protocols and algorithms and provide additional
information on IPsec.

This Bulletin is to be used in conjunction with
CSEC IT Security Alert 11d (ITSA-11d),
published on August 2008.

Le présent bulletin vise à fournir aux ministères du
gouvernement du Canada (GC) des conseils sur :

• l’utilisation du protocole de sécurité IP (IPsec pour
Internet Protocol Security) pour la protection des
renseignements PROTÉGÉ A et PROTÉGÉ B;

• les protocoles et algorithmes cryptographiques
approuvés que le Centre de la sécurité des
télécommunications Canada (CSTC) recommande
d’utiliser conjointement avec le protocole IPSec;

• les normes et publications spéciales du NIST qui
décrivent les protocoles et algorithmes
cryptographiques recommandés et fournissent des
renseignements additionnels sur le protocole IPSec.

Le présent bulletin doit être utilisé en conjonction
avec l’Alerte de sécurité TI 11d (ITSA-11d) du
CSTC, publiée en août 2008.
UNCLASSIFIED / NON CLASSIFIÉ



December 2008 ITSB-61 décembre 2008

2


Scope

Portée
This Bulletin provides guidance on using an
implementation of the IPsec protocol that conforms
to Internet Engineering Task Force (IETF) standards
4301, 4302, 4303, and 4306.

Guidance provided in this Bulletin is relevant only
for the protection of Protected A and Protected B
information; the protection of Protected C and
classified information is beyond the scope of this
Bulletin.

This Bulletin does not provide guidance on the
implementation of cryptographic protocols and
algorithms used in IPsec such as key exchange
protocols, block ciphers, hash functions, or random
bit generation. References for cryptographic
protocols and algorithms are highlighted in the
References section.

Le présent bulletin fournit des conseils sur l’utilisation
d’une mise en oeuvre du protocole IPSec qui est
conforme aux normes 4301, 4302, 4303 et 4306 de
l’Internet Engineering Task Force (IETF).

Les conseils formulés ci-après concernent uniquement
la protection des renseignements PROTÉGÉ A et
PROTÉGÉ B; la protection des renseignements
PROTÉGÉ C et classifiés dépassent les limites du
présent bulletin.

Le présent bulletin n’offre aucune orientation quant à la
mise en oeuvre des protocoles et algorithmes
cryptographiques utilisés dans le protocole IPSec, tels
les protocoles d’échange de clés, les algorithmes de
chiffrement par bloc, les fonctions de hachage ou la
génération de bits aléatoires. Les références pour les
protocoles et algorithmes cryptographiques sont
données dans la section Références.
Background

Contexte
IPsec is a suite of open standard protocols which
operate at the network layer of the Open System
Interconnection Basic Reference Model (OSI Model)
to add security to the Internet Protocol (IP). The
network layer is responsible for routing packets from
the source node to the destination node. The security
functions that IPsec provides include access control,
data integrity, data origin authentication, protection
against replay and injection attacks, and
confidentiality. IPsec is the foundation to create a
virtual private network (VPN), which is a secure
virtual network that exists over a larger unsecured
network.


IPsec est une suite de protocoles de norme ouverte qui
fonctionne au niveau de la couche réseau du modèle de
référence de base d’interconnexion de systèmes ouverts
(Modèle OSI) pour sécuriser davantage le protocole
Internet (IP pour Internet Protocol). La couche réseau
est responsable du routage des paquets du noeud source
vers le noeud destination. Les fonctions de sécurité
fournies par IPSec comprennent entre autres le contrôle
d’accès, l’intégrité des données, l’authentification de la
source des données, la protection contre les attaques par
rejeu (replay) ou injection, et la confidentialité. Le
protocole IPsec est le fondement de la création du
réseau privé virtuel (RPV), qui consiste en un réseau
virtuel sécurisé à l’intérieur d’un réseau non sécurisé
plus grand.
Overview of the IP Security Protocol

Aperçu du protocole IPsec
IPsec can be configured in different combinations to
provide a variety of security services.

IPsec protects IP packets or upper-layer protocols
with two protocols: the Authentication Header (AH)
protocol and the Encapsulating Security Payload

IPsec peut être configuré selon diverses combinaisons
afin de fournir une gamme variée de services de
sécurité.

IPsec protège les paquets IP ou les protocoles de
couches supérieures à l’aide de deux protocoles :
UNCLASSIFIED / NON CLASSIFIÉ



December 2008 ITSB-61 décembre 2008

3

(ESP). The AH protocol provides authentication but
not confidentiality (encryption). The ESP protocol
provides confidentiality and optionally provides
authentication. The AH and ESP protocols may be
used alone or in combination with each other.

The AH and ESP protocols operate in two different
modes. The transport mode provides protection to
upper layer protocols. In tunnel mode, the entire IP
packet is encapsulated and protected.

The most common configuration for IPsec is
authenticated ESP in tunnel mode.

A security association (SA) is a set of policies and
keys used to manage the security requirements of a
logical connection. The SA consists of a destination
address, the security protocol which is either AH or
ESP, and a security parameter index (SPI) that allows
the destination system to process the packet with the
appropriate SA. All traffic associated with the SA is
processed with the same security requirements. Each
SA has an associated lifetime which determines when
the SA expires. A security association database stores
all active SAs.

The Internet Key Exchange (IKE) protocol is used to
negotiate, establish, provide authenticated keying
material, and maintain active SAs. IKE version 1
(IKEv1) is performed in two phases. The first phase
secures an authenticated channel to communicate
with the main or aggressive mode of operation. The
second phase negotiates the SAs with the quick,
informational, or group mode of operation. Version 2
of IKE (IKEv2) does not use the two phase
establishment process with mode selection. IKEv2
does not interoperate with IKEv1.

The IP Payload Compression Protocol (IPComp) may
optionally be used to compress IP packets.

l’en-tête d’authentification (AH pour Authentication
Header) et l’encapsulation (ESP pour Encapsulating
Security Payload). Le protocole AH assure
l’authentification mais non la confidentialité
(chiffrement), tandis que le protocole ESP assure la
confidentialité et, en option, l’authentification. Ces deux
protocoles peuvent être utilisés séparément ou
ensemble.

Les protocoles AH et ESP fonctionnent dans deux
modes différents. Le mode transport fournit la
protection aux protocoles de couches supérieures. Dans
le mode tunnel, le paquel IP au complet est encapsulé et
protégé.

La configuration la plus commune pour l’IPSec est le
protocole ESP authentifié en mode tunnel.

Une association de sécurité (SA pour Security
Association) est un ensemble de politiques et de clés
servant à gérer les exigences de sécurité d’une
connexion logique. La SA comprend l’adresse de
destination, le protocole de sécurité (soit AH ou ESP) et
un index de paramètre de sécurité (SPI pour Security
Parameter Index) qui permet au système destinataire de
traiter le paquet au moyen de la SA appropriée. Tout le
trafic associé à la SA est traité selon les mêmes
exigences de sécurité. Chaque SA a une durée de vie
connexe qui détermine la date d’expiration de la SA.
L’ensemble des SA actives est géré à l’aide d’une base
de données.

Le protocole d’échange de clés par Internet (IKE pour
Internet Key Exchange) sert à négocier, à établir et à
fournir le matériel de chiffrement authentifié, de même
qu’à maintenir les SA actives. La version 1 du protocole
IKE (IKEv1) s’exécute en deux phases. La première
phase sécurise un canal authentifié pour communiquer
dans le mode de fonctionnement principal ou agressif.
La deuxième phase négocie les SA dans le mode de
fonctionnement rapide, informationnel ou groupe. La
version 2 du protocole IKE (IKEv2) ne fait pas appel au
processus d’établissement à deux phases avec sélection
de mode. IKEv2 n’est pas interopérable avec IKEv1.

Le protocole de compression (IPComp pour IP Payload
Compression) peut être utilisé en option pour
comprimer les paquets IP.
UNCLASSIFIED / NON CLASSIFIÉ



December 2008 ITSB-61 décembre 2008

4

Recommendation

Recommandation
Government of Canada departments are strongly
recommended to adhere to the following CSEC
security guidelines when using IPsec to protect
Protected A and Protected B information.

Only IPsec clients that contain cryptographic
modules that have been validated to Federal
Information Processing Standard (FIPS) 140-2 under
the Cryptographic Module Validation Program
(CMVP) shall be used. If the IPsec client also
contains cryptographic algorithm implementations
that are not validated under the Cryptographic
Algorithm Validation Program (CAVP), the client
shall be configured so that those implementations are
not used.

IPsec clients used for the protection of Protected A
and Protected B information shall use digital
signatures for authentication. Pre-shared keys shall
not be used for authentication. IPsec shall provide
confidentially protection through encryption. IPsec
shall also provide integrity protection, forward
perfect secrecy, and replay protection.

The lifetime of a security association for the
protection of Protected A and Protected B
information shall not be longer than 4 hours, after
which another SA must be established.

Table 1 lists the approved cryptographic protocols
and algorithms that shall be used in IPsec for the
protection of Protected A and Protected B
information. Table 1 is to be used in conjunction with
ITSA-11d, which states that SKIPJACK, KEA, SHA-
1, and 80-bit CAST5 shall be discontinued by the end
of 2010 for the protection of Protected A and
Protected B information.



Il est recommandé fortement aux ministères d’adhérer
aux lignes directrices du CSTC en matière de sécurité
au moment d’utiliser le protocole IPSec pour protéger
les renseignements PROTÉGÉ A et PROTÉGÉ B.

Seuls les clients IPSec qui contiennent des modules
cryptographiques validés au niveau de la Federal
Information Processing Standard (FIPS) 140-2 en vertu
du Programme de validation des modules
cryptographiques (PVMC) doivent être utilisés. Si le
client IPSec contient également des mises en oeuvre
d’algorithmes cryptographiques qui n’ont pas été
validées en vertu du Cryptographic Algorithm
Validation Program (CAVP), il faudra le configurer de
sorte que ces mises en oeuvre ne soient pas utilisées.

Les clients IPSec utilisés pour la protection de
renseignements PROTÉGÉ A et PROTÉGÉ B doivent
faire appel aux signatures numériques pour
l’authentification. Les clés prépartagées ne doivent pas
être utilisées pour l’authentification. IPSec assurera la
confidentialité au moyen du chiffrement. Il assurera
également la protection de l’intégrité, le service du
secret parfait (FPS pour Forward Perfect Secrecy) et la
protection contre le rejeu.

La durée d’une association de sécurité pour la
protection de renseignements PROTÉGÉ A et
PROTÉGÉ B ne doit pas dépasser 4 heures, après quoi
une autre SA doit être établie.

Le tableau 1 comprend la liste des protocoles et
algorithmes cryptographiques approuvés qui doivent
être utilisés dans le protocole IPSec pour la protection
des renseignements PROTÉGÉ A et PROTÉGÉ B.
Le tableau 1 doit être utilisé conjointement avec
l’ITSA-11d, dans lequel il est indiqué que SKIPJACK,
KEA, SHA-1 et CAST5 à 80 bits doivent être
discontinués d’ici la fin de 2010 pour la protection des
renseignements PROTÉGÉ A et PROTÉGÉ B.


UNCLASSIFIED / NON CLASSIFIÉ



December 2008 ITSB-61 décembre 2008

5

Tableau 1: Approved Cryptographic Protocols and Algorithms for IPsec/
Protocoles et algorithmes cryptographiques approuvés pour IPsec

Key
Establishment/
Établissement
de clé
Block
Ciphers/
Chiffrement
par bloc
Hash
Functions/
Fonctions
de hachage
Digital
Signatures/
Signatures
numériques
Random Bit
Generation/
Génération de bits
aléatoires
Integrity
Protection/
Protection de
l’intégrité
RSA

Diffie-Hellman

Key Exchange
Algorithm (KEA)

Elliptic Curve
Diffie-Hellman/
Diffie-Hellman à
courbe elliptique

Elliptic Curve
MQV/ MQV à
courbe elliptique
AES

Triple DES

CAST5

SKIPJACK

SHA-1

SHA-224

SHA-256

SHA-384

SHA-512
DSA

RSA

Elliptic Curve
DSA/DSA à
courbe
elliptique

Hash_DRBG

HMAC_DRBG

CTR_DRBG

Dual_EC_DRBG

Legacy DRBGs
based on DES,
Triple DES, AES,
SHA-1, and
HMAC/Anciens
générateurs de bits
aléatoires
déterministes
fondés sur DES,
Triple DES, AES,
SHA-1 et HMAC
HMAC

CMAC

When using Diffie-Hellman or Elliptic Curve Diffie-
Hellman for key exchange, only the ephemeral
Diffie-Hellman key exchange shall be used. Fixed
Diffie-Hellman and anonymous Diffie-Hellman shall
not be used. Furthermore, it should be noted that
Menezes-Qu-Vanstone (MQV) is a patented protocol.

IKEv2 is preferred over IKEv1. IKEv1 shall use
main mode for phase 1 and quick mode for phase 2.
IKEv1 shall not use the aggressive, informational,
and group mode.

Both versions of the IKE protocol require a Diffie-
Hellman group to establish a shared secret. The
cryptographic parameters for key establishment
algorithms for exponentiation in finite fields or
elliptic curve algorithms are specified in ITSA-11d.

Approved elliptic curve parameters used shall
conform to the recommendations given in ITSA-11d.
Recommended curves can be found in Appendix 6 of
FIPS 186-2.


Lorsque le protocole Diffie-Hellman ou Diffie-Hellman à
courbe elliptique est utilisé pour l’échange de clés, seul
l’échange de clés Diffie-Hellman éphémère doit être
utilisé. Les protocoles Diffie-Hellman fixe et anonyme ne
doivent pas l’être. De plus, il est à noter que le protocole
Menezes-Qu-Vanstone (MQV) est breveté.

Utiliser IKEv2 de préférence à IKEv1. IKEv1 doit
utiliser le mode principal pour la phase 1 et le mode
rapide pour la phase 2. IKEv1 ne doit pas utiliser le mode
agressif, informationnel ou groupe.

Les deux versions du protocole IKE nécessitent un
groupe Diffie-Hellman pour établir un secret partagé. Les
paramètres cryptographiques pour les algorithmes
d’établissement de clé pour l’exponentiation dans un
corps fini ou les algorithmes à courbe elliptique sont
précisés dans l’ITSA-11d.

Les paramètres de courbe elliptique approuvés utilisés
doivent être conformes aux recommandations formulées
dans l’ITSA-11d. Les courbes recommandées sont
données à l’appendice 6 de la FIPS 186-2.
UNCLASSIFIED / NON CLASSIFIÉ



December 2008 ITSB-61 décembre 2008

6

Integrity protection algorithms through a Hash-based
Message Authentication Code (HMAC) or Cipher-
based Message Authentication Code (CMAC) are
specified in IT Security Alert 11d.

Approved modes of operations for block ciphers as
well as padding schemes for key establishment and
digital signatures used with IPsec shall conform to
the recommendations given in ITSA-11d.

The use of random bit generators evaluated by the
CMVP is strongly recommended. Approved random
bit generators are specified in ITSA-11d.

The NULL parameter shall not be used with any
cryptographic protocol or algorithm.

Les algorithmes de protection de l’intégrité à l’aide d’un
code d’authentification de message à base de fonction de
hachage (HMAC pour Hash-based Message
Authentication Code) ou d’un MAC à base de fonction de
chiffrement (CMAC pour Cipher-based Message
Authentication Code) sont précisés dans l’ITSA-11d.

Les modes d’exploitation approuvés pour les algorithmes
de chiffrement par bloc, de même que les protocoles de
remplissage pour l’établissement des clés et les
signatures numériques, utilisés avec IPSec doivent être
conformes aux recommandations formulées dans
l’ITSA-11d.

L’utilisation de générateurs de bits aléatoires évalués par
le PVMC est fortement recommandée. Les générateurs de
bits aléatoires approuvés sont précisés dans l’ITSA-11d.

Le paramètre NULL ne doit pas être utilisé pour un
protocole ou algorithme cryptographique quelconque.
References

Références
There are numerous standards and NIST Special
Publications which define the cryptographic
protocols and algorithms used in this Bulletin as well
as documents to provide guidance on security
parameters.

If there are any discrepancies between this guidance
and the following references, then the guidance for
security parameters in this Bulletin and in ITSA-11d
shall be followed.

IT Security Alert 11d


CSEC Approved Cryptographic Algorithms for
the Protection of Protected Information and for
Electronic Authentication and Authorization
Applications within the Government of Canada
(ITSA-11d)
The ITSA-11d provides guidance on approved
protocols and algorithms for encryption, key
establishment, digital signatures, hashing, data
integrity, and padding schemes.
http://www.cse-cst.gc.ca/documents/publications/gov
-pubs/itsa/itsa11d-e.pdf


Il existe de nombreuses normes et publications spéciales
du NIST qui définissent officiellement les protocoles et
algorithmes cryptographiques utilisés dans le présent
bulletin, de même que des documents offrant des
conseils sur les paramètres de sécurité.

En cas de divergence entre ces conseils et les références
qui suivent, il faudra suivre les conseils liés aux
paramètres de sécurité donnés dans le présent bulletin et
dans l’ITSA-11d.

Alerte de sécurité TI 11d


Algorithmes cryptographiques approuvés par le
CSTC pour la protection des renseignements désignés
PROTÉGÉ et pour les applications d’authentification
et d’autorisation électroniques au sein du
gouvernement du Canada (ITSA-11d)
L’ITSA-11d fournit une orientation sur les protocoles et
algorithmes approuvés pour le chiffrement,
l’établissement des clés, les signatures numériques, le
hachage, l’intégrité des données et les protocoles de
remplissage.
http://www.cse-cst.gc.ca/documents/publications/gov-
pubs/itsa/itsa11d-f.pdf
UNCLASSIFIED / NON CLASSIFIÉ



December 2008 ITSB-61 décembre 2008

7

IP Security


 IETF RFC 4301
This standard specifies the security architecture
for the Internet Protocol (IP).
http://tools.ietf.org/html/rfc4301

 IETF RFC 4302
This standard specifies the IP Authentication
Header (AH).
http://tools.ietf.org/html/rfc4302

 IETF RFC 4303
This standard specifies the IP Encapsulating
Security Payload (ESP).
http://tools.ietf.org/html/rfc4303

 IETF RFC 2409
This standard specifies version 1 of the Internet
Key Exchange (IKEv1).
http://tools.ietf.org/html/rfc2409

 IETF RFC 4306
This standard specifies version 2 of the Internet
Key Exchange (IKEv2).
http://tools.ietf.org/html/rfc4306

 IETF RFC 3173
This standard specifies the IP Payload
Compression Protocol (IPComp).
http://tools.ietf.org/html/rfc3173

 NIST Special Publication 800-77
This special publication provides guidelines and
recommendations on security parameters for IPsec
and virtual private networks.
http://csrc.nist.gov/publications/nistpubs/800-
77/sp800-77.pdf

Elliptic Curves


 FIPS 186-2, FIPS 186-3
The Digital Signature Standard provides guidance
on generating digital signatures. Appendix 6 of
the standard defines the parameters for approved
elliptic curves as well as provides guidance on
implementing elliptic curve cryptography. Note
that FIPS 186-3 is currently a draft.
Sécurité IP


 IETF RFC 4301
Cette norme précise l’architecture de sécurité pour le
protocole Internet (IP).
http://tools.ietf.org/html/rfc4301

 IETF RFC 4302
Cette norme précise l’en-tête d’authentification IP
(AH pour Authentication Header).
http://tools.ietf.org/html/rfc4302

 IETF RFC 4303
Cette norme précise l’encapsulation IP ESP (IP
Encapsulating Security Payload).
http://tools.ietf.org/html/rfc4303

 IETF RFC 2409
Version 1 de l’échange de clés Internet (IKEv1).
http://tools.ietf.org/html/rfc2409

 IETF RFC 4306
Version 2 de l’échange de clés Internet (IKEv2).
http://tools.ietf.org/html/rfc4306

 IETF RFC 3173
Cette norme précise le protocole de compression des
données IP (IPComp pour Payload Compression
Protocol).
http://tools.ietf.org/html/rfc3173

 Publication spéciale 800-77 du NIST
Cette publication spéciale fournit les directives et les
recommandations sur les paramètres de sécurité pour
IPsec et les réseaux privés virtuels.
http://csrc.nist.gov/publications/nistpubs/800-
77/sp800-77.pdf

Courbes elliptiques


 FIPS 186-2, FIPS 186-3
Le document Digital Signature Standard fournit les
directives sur la génération de signatures numériques.
L’appendice 6 définit les paramètres pour les courbes
elliptiques approuvées de même que des conseils sur
la mise en oeuvre de la cryptographie à courbe
elliptique. Il est à noter que la FIPS 186-3 est à l’état
d’ébauche.
UNCLASSIFIED / NON CLASSIFIÉ



December 2008 ITSB-61 décembre 2008

8

http://csrc.nist.gov/publications/fips/fips186-
2/fips186-2-change1.pdf

http://csrc.nist.gov/publications/drafts/fips_186-
3/Draft-FIPS-186-3%20_March2006.pdf

Key Management

 NIST Special Publication 800-57
This three part special publication provides
guidance on key management.
http://csrc.nist.gov/publications/nistpubs/800-
57/sp800-57-Part1-revised2_Mar08-2007.pdf

http://csrc.nist.gov/publications/nistpubs/800-
57/SP800-57-Part2.pdf

 NIST Special Publication 800-56A
This special publication specifies the Diffie-
Hellman and MQV key exchange protocols using
discrete logarithms.
http://csrc.nist.gov/publications/nistpubs/800-
56A/SP800-56A_Revision1_Mar08-2007.pdf

 ANS X9.44
This standard specifies the RSA key exchange
algorithm using integer factorization.

 SKIPJACK and KEA Algorithm Specifications
Version 2.0
This document specifies the Key Exchange
Algorithm (KEA).
http://csrc.nist.gov/encryption/skipjack/skipjack.p
df

Hashing


 FIPS 180-3
The Secure Hash Standard specifies the five
approved hashing algorithms: SHA-1, SHA-224,
SHA-256, SHA-384, and SHA-512.
http://csrc.nist.gov/publications/fips/fips180-
3/fips180-3_final.pdf

Integrity Protection


 FIPS 198
The Keyed-Hash Message Authentication Code
http://csrc.nist.gov/publications/fips/fips186-
2/fips186-2-change1.pdf

http://csrc.nist.gov/publications/drafts/fips_186-
3/Draft-FIPS-186-3%20_March2006.pdf

Gestion des clés

 Publication spéciale 800-57 du NIST
Cette publication spéciale à trois parties fournit des
conseils sur la gestion des clés.
http://csrc.nist.gov/publications/nistpubs/800-
57/sp800-57-Part1-revised2_Mar08-2007.pdf

http://csrc.nist.gov/publications/nistpubs/800-
57/SP800-57-Part2.pdf

 Publication spéciale 800-56A du NIST
Cette publication spéciale précise les protocoles
d’échange de clés Diffie-Hellman et MQV utilisant
des algorithmes discrets.
http://csrc.nist.gov/publications/nistpubs/800-
56A/SP800-56A_Revision1_Mar08-2007.pdf

 ANS X9.44
Cette norme précise l’algorithme d’échange de clés
RSA utilisant la factorisation des nombres entiers.

 Spécifications des algorithmes SKIPJACK et KEA,
Version 2.0
Ce document constitue la spécification pour
l’algorithme d’échange de clés (KEA pour Key
Exchange Algorithm).
http://csrc.nist.gov/encryption/skipjack/skipjack.pdf

Hachage


FIPS 180-3
La norme Secure Hash Standard précise les cinq
algorithmes de hachage approuvés : SHA-1, SHA-
224, SHA-256, SHA-384 et SHA-512.
http://csrc.nist.gov/publications/fips/fips180-
3/fips180-3_final.pdf

Protection de l’intégrité

 FIPS 198
La norme Keyed-Hash Message Authentication Code
précise l’algorithme HMAC.
UNCLASSIFIED / NON CLASSIFIÉ



December 2008 ITSB-61 décembre 2008

9

standard specifies the HMAC algorithm.
http://csrc.nist.gov/publications/fips/fips198/fips-
198a.pdf

 NIST Special Publication 800-38b
This special publication specifies the block cipher-
based Message Authentication Code (CMAC)
algorithm.
http://csrc.nist.gov/publications/nistpubs/800-
38C/SP800-38C_updated-July20_2007.pdf

Digital Signatures


 FIPS 186-2, FIPS 186-3
The Digital Signature Standard provides guidance
on generating digital signatures. The standard
includes the Digital Signature Algorithm, the RSA
digital signature algorithm, and the Elliptic Curve
Digital Signature Algorithm (ECDSA). These
standards are used in conjunction with ANS X9.31
for RSA digital signatures and ANS X9.62 for
elliptic curve digital signatures. Note that FIPS
186-3 is currently a draft.
http://csrc.nist.gov/publications/fips/fips186-
2/fips186-2-change1.pdf

http://csrc.nist.gov/publications/drafts/fips_186-
3/Draft-FIPS-186-3%20_March2006.pdf

 ANS X9.31
This standard specifies the RSA digital signature
algorithm and padding scheme.

 ANS X9.62
This standard specifies the Elliptic Curve Digital
Signature Algorithm (ECDSA).

Block Ciphers


 ANS X9.52
This standard specifies the Triple DES algorithm.

 FIPS 197
This standard specifies the Advanced Encryption
Standard (AES), an approved block cipher with
128, 192 or 256 bits of security.

http://csrc.nist.gov/publications/fips/fips197/fips-
http://csrc.nist.gov/publications/fips/fips198/fips-
198a.pdf

 Publication spéciale 800-38b du NIST
Cette publication spéciale précise l’algorithme CMAC
(Block Cipher-based Message Authentication Code).
http://csrc.nist.gov/publications/nistpubs/800-
38C/SP800-38C_updated-July20_2007.pdf

Signatures numériques


 FIPS 186-2, FIPS 186-3
La norme Digital Signature fournit une orientation sur
la génération de signatures numériques. La norme
comprend l’algorithme de signature numérique (DSA
pour Digital Signature Algorithm), l’algorithme de
signature numérique RSA et l’algorithme de signature
numérique à courbe elliptique (ECDSA pour Elliptic
Curve Digital Signature Algorithm). Ces normes FIPS
sont utilisées conjointement avec la norme ANS
X9.31 pour les signatures numériques RSA et la
norme ANS X9.62 pour les signatures numériques à
courbe elliptique. Il est à noter que la FIPS 186-3 est à
l’état d’ébauche.
http://csrc.nist.gov/publications/fips/fips186-
2/fips186-2-change1.pdf

http://csrc.nist.gov/publications/drafts/fips_186-
3/Draft-FIPS-186-3%20_March2006.pdf

 ANS X9.31
Cette norme précise l’algorithme de signature
numérique RSA et le protocole de remplissage.

 ANS X9.62
Cette norme précise l’algorithme de signature
numérique à courbe elliptique (ECDSA pour Elliptic
Curve Digital Signature Algorithm).

Chiffrement par bloc


 ANS X9.52
Cette norme précise l’algorithme Triple DES.

 FIPS 197
Cette norme précise l’algorithme AES (Advanced
Encryption Standard), un chiffrement par bloc
approuvé avec 128, 192 ou 256 bits de sécurité.
UNCLASSIFIED / NON CLASSIFIÉ



December 2008 ITSB-61 décembre 2008

10

197.pdf

 SKIPJACK and KEA Algorithm Specifications
Version 2.0
This document specifies the SKIPJACK
encryption algorithm.
http://csrc.nist.gov/encryption/skipjack/skipjack.p
df

 IETF RFC 2144
This standard specifies the CAST5 (also called
CAST-128) encryption algorithm.
http://tools.ietf.org/html/rfc2144

Random Bit Generation


The following reference contains the newest and
preferred methods to generate random bits.

 NIST Special Publication 800-90
This special publication specifies how to generate
random bits by using deterministic methods based
on hash functions, block ciphers, or number
theoretic problems.
http://csrc.nist.gov/publications/nistpubs/800-
90/SP800-90revised_March2007.pdf

The following four references contain the legacy
deterministic random bit generators (DRGB) which
are currently approved.

 NIST-Recommended Random Number
Generator Based on ANSI X9.31 Appendix
A.2.4 Using the 3-Key Triple DES and AES
Algorithms
This document specifies how to use 3-key Triple
DES and AES instead of DES based on ANS
X9.31.
http://csrc.nist.gov/groups/STM/cavp/documents/r
ng/931rngext.pdf

 FIPS 186-2
Appendix 3 of the Digital Signature Standard
specifies how to generate random bits by using
SHA-1 and DES.
http://csrc.nist.gov/publications/fips/fips186-
2/fips186-2-change1.pdf

http://csrc.nist.gov/publications/fips/fips197/fips-
197.pdf

 Spécification des algorithmes SKIPJACK et KEA,
Version 2.0
Ce document précise l’algorithme de chiffrement
SKIPJACK.
http://csrc.nist.gov/encryption/skipjack/skipjack.pdf

 IETF RFC 2144
Cette norme précise l’algorithme de chiffrement
CAST5 (aussi nommé CAST-128).
http://tools.ietf.org/html/rfc2144

Génération de bits aléatoires


La référence suivante traite des nouvelles méthodes
préférées pour générer des bits aléatoires.

 Publication spéciale 800-90 du NIST
Cette publication spéciale précise comment générer
des bits aléatoires à l’aide de méthodes déterministes
fondées sur des fonctions de hachage, le chiffrement
par blocs ou des problèmes théoriques liés aux
nombres.
http://csrc.nist.gov/publications/nistpubs/800-
90/SP800-90revised_March2007.pdf

Les quatre références suivantes traitent des anciens
générateurs de bits aléatoires déterministes (DRGB pour
Deterministic Random Bit Generator), actuellement
approuvés.

 Générateur de nombres aléatoires recommandé
par le NIST selon l’ANSI X9.31, appendice A.2.4,
au moyen des algorithmes AES et Triple DES à
3 clés
Ce document explique comment utiliser les
algorithmes AES et Triple DES à 3 clés au lieu de
DES, selon l’ANS X9.31.
http://csrc.nist.gov/groups/STM/cavp/documents/rng/
931rngext.pdf

 FIPS 186-2
L’appendice 3 de la norme de signature numérique
précise comment générer des bits aléatoires à l’aide de
SHA-1 et de DES.
http://csrc.nist.gov/publications/fips/fips186-
UNCLASSIFIED / NON CLASSIFIÉ



December 2008 ITSB-61 décembre 2008

11

 ANS X9.31
Appendix A.2.4 specifies how to generate random
bits using DES.

 ANS X9.62
Annex D specifies how to generate random bits by
using HMAC.

Padding Schemes


 RSA PKCS #1 v2.1
This standard contains padding schemes for key
establishment and digital signatures.
http://www.rsa.com/rsalabs/node.asp?id=2125

Cryptographic Validation Programs


 Cryptographic Module Validation Program
(CMVP)

The CMVP validates commercial cryptographic
modules as meeting the requirements of FIPS 140-
2. The goal of the CMVP is to promote the use of
validated cryptographic modules and provide
Federal agencies with a security metric to use in
procuring equipment containing validated
cryptographic modules.

In the CMVP, vendors of commercial
cryptographic modules use independent and
accredited laboratories to have their modules
tested.
http://www.cse-cst.gc.ca/services/industrial-
services/cmv-program-e.html

 Cryptographic Algorithm Validation Program
(CAVP)
The CAVP validates commercial cryptographic
algorithm implementations as meeting the
requirements of its specified standard or NIST
Special Publication.

In the CAVP, vendors of commercial
cryptographic algorithm implementations use
independent and accredited laboratories to have
their implementations tested.
http://csrc.nist.gov/cryptval/cavp.htm

2/fips186-2-change1.pdf

 ANS X9.31
L’appendice A.2.4 précise comment générer des bits
aléatoires à l’aide de DES.

 ANS X9.62
L’annexe D précise comment générer des bits
aléatoires à l’aide de HMAC

Protocoles de remplissage


 RSA PKCS #1 v2.1
Cette norme contient les protocoles de remplissage
pour l’établissement des clés et les signatures
numériques.
http://www.rsa.com/rsalabs/node.asp?id=2125

Programmes de validation cryptographique


 Programme de validation des modules
cryptographiques (PVMC)

Le PVMC valide les modules cryptographiques
commerciaux qui satisfont aux exigences de la norme
FIPS 140-2. L’objectif du PVMC est de promouvoir
l’utilisation de modules cryptographiques validés et
offre aux organismes fédéraux les paramètres de
sécurité à utiliser lors de l’acquisition d’appareils
contenant des modules cryptographiques validés.

Dans le cadre du PVMC, les fournisseurs de modules
cryptographiques commerciaux font appel à des
laboratoires indépendants et accrédités pour faire
tester leurs modules.
http://www.cse-cst.gc.ca/services/industrial-
services/cm-program-f.html

 Cryptographic Algorithm Validation Program
(CAVP)
Le CAVP valide les mises en oeuvre d’algorithmes
cryptographiques commerciaux qui satisfont aux
exigences des normes précisées ou des publications
spéciales du NIST.

Dans le cadre du CAVP, les fournisseurs de mises en
oeuvre d’algorithmes cryptographiques commerciaux
font appel à des laboratoires indépendants et
UNCLASSIFIED / NON CLASSIFIÉ



December 2008 ITSB-61 décembre 2008

12
 FIPS 140-2
This standard specifies the security requirements
for cryptographic modules.
http://csrc.nist.gov/cryptval/140-2.htm

accrédités pour faire tester leurs modules.
http://csrc.nist.gov/cryptval/cavp.htm

 FIPS 140-2
Cette norme énonce les exigences de sécurité pour les
modules cryptographiques.
http://csrc.nist.gov/cryptval/140-2.htm

Contacts and Assistance

Aide et renseignements
Head, IT Security Client Services
Communications Security Establishment Canada
PO Box 9703, Terminal
Ottawa, ON K1G 3Z4


Telephone: (613) 991-8495
e-mail :
client.services@cse-cst.gc.ca

Chef, Services à la clientèle STI
Centre de la sécurité des télécommunications
Canada
C.P. 9703, Terminus
Ottawa (Ontario) K1G 3Z4

Téléphone : (613) 991-8495
Courriel :
client.services@cse-cst.gc.ca
.


La directrice de la Gestion de la mission de la Sécurité des TI,


______________________________________
Gwen Beauchemin
Director, IT Security Mission Management