Upload
lykiet
View
214
Download
0
Embed Size (px)
Citation preview
Commission Interministériellepour la Sécurité des Systèmes d’Information
PROFIL DE PROTECTION
OUTILS DE SECURISATION
DES MESSAGES
6 juin 1998
Version 1.5
PP/9804
AVANT PROPOS
Ce document est issu des réflexions du groupe ad-hoc Messagerie Sécurisée de la CommissionInterministérielle pour la Sécurité des Systèmes d’Information. Toute correspondance concernantce profil de protection doit être adressée au Service Central de la Sécurité des Systèmes d’Infor-mation :
SCSSIDivision CH/PP
18 rue du Doc Zamenhof92 131 Issy Les Moulineaux
France
Page i
Sommaire
Chapitre 1Outils de sécurisation des messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Identification du profil de protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Présentation du profil de protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapitre 2Description de la cible d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Définition de la cible d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Les services de la TOE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Chapitre 3Environnement de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 L’environnement physique de la TOE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2 Connexion de la TOE à son environnement . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.3 Les acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.4 Typologie des attaquants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.5 Les biens à protéger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.6 Les menaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.7 Description de la politique de sécurité organisationnelle . . . . . . . . . . . . . . . . . 103.8 Les hypothèses d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Chapitre 4Objectifs de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1 Objectifs de sécurité portant sur la cible d’évaluation . . . . . . . . . . . . . . . . . . . 134.2 Objectifs de sécurité portant sur l’environnement de la TOE . . . . . . . . . . . . . 13
Chapitre 5Exigences de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1 Exigences fonctionnelles de la cible d’évaluation . . . . . . . . . . . . . . . . . . . . . . 155.2 Liste des exigences fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.3 Exigences d’assurance des TI de la cible d’évaluation . . . . . . . . . . . . . . . . . . . 27
Chapitre 6Notes d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.1 Exploitation de la TOE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316.2 Législation applicable en France . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Page ii
Chapitre 7Justification du profil de protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1 Menaces non couvertes par le profil de protection . . . . . . . . . . . . . . . . . . . . . . 337.2 Justification des objectifs de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357.3 Tableau croisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387.4 Justificatif des exigences de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.5 Dépendances des composantes fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . 487.6 Dépendances des composantes d’assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Annexe AAbréviations et Glossaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.1 Abréviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53A.2 Glossaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Annexe BBibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
B.1 Document relatif aux messageries sécurisés . . . . . . . . . . . . . . . . . . . . . . . . . . . 59B.2 Documents relatifs aux critères communs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59B.3 Documents relatifs à la réglementation française . . . . . . . . . . . . . . . . . . . . . . . 59
Page 1
Chapitre 1
Outils de sécurisation des messages
1.1 Identification du profil de protection
1 Titre : Profil de protection pour les outils de sécurisation des messages (PP_OSM).
2 Version : 1.5, du 6 juin 1998.
3 Identifiant : PP/9804.
4 Ce profil de protection est conforme à la version 2.0 Draft des Critères Communs.
5 La liste des abréviations ainsi qu’un glossaire des termes utilisés dans ce profil deprotection sont donnés en annexe A.
1.2 Présentation du profil de protection
6 L’échange d’informations par l’intermédiaire de courrier électronique est un besoinmajeur des utilisateurs des systèmes d’information.
7 Lorsqu’il s’agit de documents sensibles ou classifiés de défense, le service demessagerie doit apporter des assurances supplémentaires à ses utilisateurs :l’intégrité et la protection de la confidentialité des messages échangés et secretscryptologiques.
8 La cible d’évaluation décrite dans ce profil de protection est la ressource cryp-tologique installée sur un poste informatique destiné à sécuriser des messages. Cettecible d’évaluation doit être une enceinte de confiance où sont conservés les secretset où est effectué l’ensemble des opérations cryptographiques nécessaires à lasécurisation des messages.
9 Ce profil de protection définit au sens des Critères Communs les exigences fonc-tionnelles et d’assurance de la cible d’évaluation qui sont nécessaires au traitementet aux échanges d’informations classifiées de défense au niveau ConfidentielDéfense.
10 Cependant, des exigences complémentaires peuvent s’avérer nécessaires à laprotection des informations classifiées de défense, en particulier lorsque la cibled’évaluation est soumise à des menaces autres que celles prises en compte par ceprofil de protection (cf. chapitre 3.6). Des exigences complémentaires peuvent aussidécouler des choix de réalisation et d’implémentation de la cible d’évaluation,choix qui restent ouverts au niveau de ce PP.
Page 2
11 Les exigences figurant dans ce PP sont indépendantes du degré de sécurité desréseaux de transport et indépendantes des protocoles d’échanges de messages.
12 Les grandes lignes d’une architecture de messagerie électronique pour l’administra-tion [Ad-hoc] sont rappelées dans la figure 1.1 ci-dessous.
13 La cible d’évaluation décrite dans ce profil de protection est une sous partie del’architecture de messagerie qui est composée des entités décrites ci-dessous.
a) Un poste utilisateur (PU) : il s’agit d’un micro-ordinateur connecté à un ré-seau. Un logiciel de messagerie (LM) est installé sur le poste. Lasécurisation des messages par le logiciel de messagerie nécessite l’emploid’une ressource cryptologique logicielle ou matérielle installée sur le PU.Cette ressource cryptologique est la cible d’évaluation.
b) Une infrastructure de gestion de clés (IGC) : l’IGC se compose d’un ensem-ble d’organismes de confiance organisés le plus souvent en arborescence ouen réseau maillé. Les services offerts par ces tiers sont la certification et ladistribution de clés, l’horodatage et la notarisation des messages ainsi que lagestion des annuaires d’abonnés au service de messagerie. Ces tiers utilise-ront une TOE pour sécuriser les messages échangés.
c) Des serveurs locaux de messagerie (SLM) : il s’agit du bureau de poste pourun ensemble d’utilisateurs. Le SLM a pour fonction l’archivage, l’envoi etla réception de messages entre les postes des utilisateurs et le réseau deserveurs de messagerie. Une passerelle de sécurite pourra renforcer la sécu-rité de l’architecture de messagerie au moyen des services de sécurité d’uneTOE.
d) Des serveurs de messagerie (SM) : un SM est optionnel dans l’architecture.C’est un routeur des messages entre les SLM qui lui sont attachés et le ré-seau étendu. Un SM peut éventuellement utiliser des services de sécuritéd’une TOE.
Page 3
Fig. 1.1 - Diagramme d’une architecture de messagerie.
Réseau local
Réseau étendu
Poste utilisateur (PU)Logiciel messagerie (LM)Ressource cryptologique
Serveur de messagerie(SM) et passerelle desécurité
Réseau local
Serveur de messagerie(SM)Ressource cryptologique
Infrastructuresde gestion de clés (IGC)Ressource cryptologique
Serveur local de messagerie(SLM)et passerelle de sécuritéRessource cryptologique
Page 5
Chapitre 2
Description de la cible d’évaluation
2.1 Définition de la cible d’évaluation
14 La cible d’évaluation (notée TOE dans la norme des Critères Communs - Target OfEvaluation -) est la ressource cryptologique nécessaire à la protection des messagespar un logiciel de messagerie d’un utilisateur ou par un serveur de l’IGC. Cetteressource est par exemple un logiciel, une carte à puce, une carte PCcard, un boîtierexterne (lecteur de carte à puce sécurisé, boîtier chiffrant).
2.2 Les services de la TOE
15 La TOE contribue à la sécurisation des messages échangés :
- entre deux utilisateurs,- entre un utilisateur et l’infrastructure de gestion de clés,- entre un utilisateur et un groupe d’abonnés à l’intérieur d’un forum de
discussion.
16 Cette section décrit la liste des services de sécurité qui doivent être offerts par laTOE :
- identification de l’utilisateur,- authentification des parties communicantes,- la génération de clés symétriques et asymétriques,- la génération de condensats,- la protection des clés conservées dans la TOE,- le chiffrement et le déchiffrement des messages et pièces jointes,- la vérification de l’intégrité d’un certificat de clé publique,- la génération et la vérification de la signature numérique des messages et
pièces jointes.
Page 7
Chapitre 3
Environnement de sécurité
3.1 L’environnement physique de la TOE
17 La TOE admet diverses représentations physiques (logiciel, cartes à puces, cartesinternes ou externes PC, etc...). L’accès physique à la TOE est un facteur qui doitêtre pris en compte dans la politique de sécurité qui définit les conditions d’usagede la TOE.
3.2 Connexion de la TOE à son environnement
18 La TOE est reliée au poste utilisateur par un port série ou parallèle, ou par un busPC d’extension de périphérique.
19 L’application de messagerie accède aux fonctions de sécurité de la TOE parl’intermediaire d’une interface conforme aux normes internationales (par exemple,IDUP-GSS-API ou MAPI).
3.3 Les acteurs
3.3.1 Les utilisateurs
20 L’utilisateur est défini comme une entité humaine extérieure à la TOE mais qui in-teragit avec la TOE par l’intermédiaire d’une application accessible par le poste in-formatique de l’utilisateur. Par extension, l’utilisateur peut être un processusinformatique.
21 Pour ce profil de protection, l’utilisateur est un individu autorisé par son autorité desécurité à mettre en œuvre la TOE. Il obtient de l’IGC les certificats de clés publi-ques et secrets nécessaires à son authentification et à la sécurisation des messagespar la TOE.
3.3.2 L’administrateur de sécurité
22 L’administrateur de sécurité de la cible d’évaluation est responsable de la mise enoeuvre de la politique de sécurité de la TOE. Il peut être confondu avecl’administrateur de sécurité des systèmes d’information incluant la TOE. On entendpar autorité de sécurité l’entité responsable de la définition et de l’application d’unepolitique de sécurité.
Page 8
3.4 Typologie des attaquants
23 Les attaquants potentiels de la cible d’évaluation sont :
a) les utilisateurs autorisés mais pouvant commettre une erreur par inadver-tance,
b) les personnes ou machines qui disposent de moyens d’investigation etd’action sur la TOE elle-même et sur toutes les composantes de l’architec-ture de messagerie (le poste utilisateur, les serveurs de messagerie, les tiersde l’IGC et les réseaux locaux ou étendus, etc.).
3.5 Les biens à protéger
24 La TOE est destinée à protéger les informations sensibles appelées biens. Deuxtypes de biens sont à distinguer : les biens directs et les biens indirects.
25 Les biens directs sont les messages et pièces jointes sécurisés au moyen de la TOEet échangés par les utilisateurs. Ces biens sont produits au moyen d’un logiciel demessagerie ou de tout autre applicatif. Ils doivent être protégés en intégrité. Lesbiens directs protégés également en confidentialité sont appelés biens directssecrets.
26 Les biens indirects sont les informations nécessaires à la protection des biensdirects. Il s’agit de l’ensemble des variables cryptographiques : les biens indirectssecrets (clés privées et symétriques, germes d’aléa) et les biens indirects publics (lescertificats de clés publiques).
27 La TOE est considérée dans ce PP comme une enceinte de confiance où sontconservés les secrets et appliquées les fonctions cryptographiques. Tous les biensindirects conservés dans la TOE seront protégés en confidentialité et en intégrité.
3.6 Les menaces
28 Les menaces prises en compte dans ce profil de protection sont issues du répertoireEBIOS des menaces génériques (cf. [EBIOS], § Outillage).
29 Toutes les menaces auxquelles la TOE est soumise ne sont pas prises en comptedans ce PP. Une liste non exhaustive de menaces non couvertes par ce PP mais iden-tifées comme pouvant porter atteinte à la sécurité du service de messagerie figureau chapitre 7.
3.6.1 Menaces portant sur la TOE
30 M.INTRUSION : Un attaquant obtient un accès non autorisé à la TOE.
31 Remarque : L’accès peut être obtenu suite au vol de la TOE ou par intrusion via leposte utilisateur, via une application installée sur le poste ou via le réseau. Les
Page 9
conséquences de cette attaque sont l’accès non autorisé de l’attaquant à des fonc-tions de sécurité de la TOE et l’accès à des biens indirects secrets conservés dans laTOE. Cette attaque est ludique, avide mais surtout stratégique; elle vise l’intégritéet la confidentialité des biens à protéger par la TOE. De bonnes connaissances cryp-tographiques et techniques sont indispensables.
32 M.DYSFONC : Le dysfonctionnement de la TOE risque d’entraîner une perte del’intégrité et de la confidentialité des biens indirects conservés dans la TOE.
33 Remarque : Cette menace provient soit de la défaillance accidentelle d’uncomposant de la TOE soit de sa modification par un attaquant disposant d’excel-lentes connaissances techniques et d’un accès à la TOE.
34 M.CLONAGE : La reproduction de la TOE par copie de son support physique oupar simulation logique permet à l’attaquant de reproduire toutes ou parties des fonc-tions de la TOE.
35 Remarque : Cette attaque est stratégique. Selon le mode de reproduction, lesmoyens financiers peuvent être conséquents et de bonnes connaissances crypto-graphiques et techniques nécessaires.
36 M.MODIFIE : La modification non détectée d’un bien après sa sécurisation par laTOE est une menace sur l’intégrité de ce bien.
37 Remarque : L’attaque peut être localisée sur le poste utilisateur, sur le réseau local,ou étendu, ou dans un serveur de l’architecture de messagerie. Cette attaque estludique, avide ou stratégique; elle engendre une perte de l’intégrité des biens àprotéger. Aucune connaissance technique de la TOE et aucun accès physique à laTOE ne sont nécessaires. L’attaquant doit seulement avoir des connaissances cryp-tologiques et maîtriser les protocoles de sécurisation et d’échange des biens àprotéger.
38 M.DIVULG : Un attaquant prend connaissance d’un bien direct ou indirect secretalors qu’il est protégé en confidentialité au moyen de la TOE.
39 Remarque : L’attaque peut être localisée sur le poste utilisateur, sur le réseausupport ou dans un serveur de l’architecture de messagerie. Cette attaque estludique, avide ou stratégique. Aucune connaissance technique de la TOE et aucunaccès physique à la TOE ne sont nécessaires. Les moyens financiers sont importantset d’excellentes connaissances cryptologiques sont indispensables.
40 M.ECHANGE : Un utilisateur autorisé échange involontairement un bien direct ouindirect secret avec un utilisateur non autorisé.
41 Remarque : Cette menace peut provoquer une perte de confidentialité du bienéchangé. C’est par exemple le cas si un certificat révoqué est utilisé par l’une oul’autre des parties communicantes pour sécuriser l’échange. L’accès à la TOE n’estpas indispensable, une faible connaissance technique et peu de moyens financierssont nécessaires.
Page 10
3.6.2 Menaces portant sur l’environnement de la TOE
42 M.PILOTE : Un logiciel ou un matériel installé sur le poste utilisateur provoqueune perte d’intégrité non détectée des pilotes de périphériques nécessaires à l’acti-vation de la TOE par le poste utilisateur, impliquant une perte d’intégrité des serv-ices de la TOE ou une perte d’intégrité et de confidentialité des biens à protéger.
43 Remarque : Cette menace peut découler d’une action d’un utilisateur non averti oud’une attaque ludique ou stratégique. Une connaissance technique de la TOE estnécessaire à l’attaquant, mais aucun moyen financier et aucun accès à la TOE nesont indispensables; seul le poste utilisateur doit être accessible à l’attaquant.
3.7 Description de la politique de sécurité organisationnelle
44 P.UTILIS : Les fonctions de la TOE doivent être limitées aux services décrits dansle chapitre 2. L’usage et l’administration de la TOE pour protéger des informationsclassifiées de défense nécessite son agrément par le SCSSI et éventuellementl’agrément de l’application ou du système d’information utilisant la TOE [900].
45 P.ADMIN : L’administrateur de la sécurité de la TOE doit pouvoir joindre dans lesplus brefs délais les utilisateurs de la TOE et inversement.
46 P.CSP : Une autorité de certification de clés publiques de l’infrastructure de gestionde clés génère, publie ou révoque un certificat de clé publique conformément à unepolitique de certification (notée CSP) approuvée par l’autorité de sécuritécompétente.
3.8 Les hypothèses d’utilisation
3.8.1 Les hypothèses sur l’administration et l’utilisation de la TOE
47 H.USAGE : La TOE doit être administrée et utilisée par des personnes habilitées etdisposant des moyens nécessaires à ces tâches. Les utilisateurs et administrateurs deTOE doivent être formés aux techniques nécessaires à l’utilisation, respectivementà l’administration, de la TOE.
48 H.RESP : Les utilisateurs de la TOE connaissent les responsabilités financières,civiles et pénales associées à l’usage de la TOE (reconnaissance juridique de lasignature numérique générée ou vérifiée par l’usage d’une TOE et contraintes régle-mentaires imposées pour le traitement d’informations classifiées de défenseprotégées à l’aide d’une TOE).
3.8.2 Les hypothèses sur l’architecture de messagerie
49 H.MESSAGERIE : Les composantes des technologies de l’information (parexemple : serveurs de messagerie, services de publication, gardes, autorités decertification, d’enregistrement, de confiance et applications logicielles associées)
Page 11
qui composent l’architecture de messagerie doivent faire l’objet d’une évaluationselon les critères en vigueur.
a) Pour les besoins de confidentialité, l’utilisateur de la TOE est abonné auprèsd’un tiers de confiance agréé conformément au décret n˚98-102 du 24 fé-vrier 1998 en application de l’article 28 de la loi n˚ 90-1170 du 29 décembre1990 sur la réglementation des télécommunications.
b) Pour les besoins d’authentification et de signature numérique, les certificatsde clés publiques sont générés par une autorité de certification et publiésdans un annuaire conformément à une politique approuvée par l’autorité desécurité compétente.
Page 13
Chapitre 4
Objectifs de sécurité
4.1 Objectifs de sécurité portant sur la cible d’évaluation
4.1.1 Les accès autorisés
50 O.TOE-ACCES : Seul un utilisateur autorisé par son autorité de sécurité doitpouvoir employer la TOE. Avant toute utilisation ou après une période d’inactivitéfixée par l’autorité de sécurité, la TOE doit identifier et authentifier l’utilisateur.
4.1.2 La protection des biens de la TOE
51 O.NOIR : Les biens indirects conservés dans la TOE sont protégés en confidenti-alité et en intégrité.
52 O.INTEGRITE : La TOE doit pouvoir contrôler l’intégrité des biens qu’elle reçoitet produire les informations nécessaires aux autres TOE pour contrôler l’intégritédes biens à protéger qu’elle exporte.
53 O.SECRET : Les biens directs ou indirects secrets exportés ou importés par la TOEdoivent être protégés en confidentialité.
54 O.VOL : Le vol ou la perte d’une TOE ne doit pas porter atteinte à la sécurité desbiens gérés par les différentes TOE de la messagerie.
55 O.SECOURS : En cas de dysfonctionnement de la TOE, toute exportation de biensconservés ou en cours de traitement par la TOE doit être impossible.
56 O.AUTH : La TOE doit permettre l’authentification des parties communicanteslors d’un échange de biens.
4.2 Objectifs de sécurité portant sur l’environnement de la TOE
57 O.GUIDE : L’installation, l’initialisation et l’usage de la TOE doivent être correct-ement documentés.
58 O.USAGE : L’administration et l’emploi de la TOE ne doivent en aucun cas nuireà la sécurité des biens secrets gérés par la TOE. Les utilisateurs de la TOE connais-sent les responsabilités financières, civiles et pénales associées à l’usage de la TOE.
59 O.MESSAGERIE : Les composantes des technologies de l’information (parexemple : serveurs de messagerie, services de publication, gardes, autorités decertification, d’enregistrement, de confiance et applications logicielles associées)qui composent l’architecture de messagerie doivent faire l’objet d’une évaluation
Page 14
selon les critères en vigueur et doivent pouvoir traiter des informations classifiéesde défense.
60 O.UTILIS : Les fonctions de la TOE ne sont pas détournables à des services nondécrits dans le Chapitre 2. L’utilisation de la TOE pour traiter des informations clas-sifiées de défense nécessite un agrément du SCSSI et éventuellement l’agrément del’application ou du système d’information utilisant la TOE [900].
61 O.ADMIN : Une infrastructure de communication opérationnelle doit exister entrel’utilisateur et l’administrateur.
Page 15
Chapitre 5
Exigences de sécurité
5.1 Exigences fonctionnelles de la cible d’évaluation
62 Le tableau ci-dessous présente la liste des exigences fonctionnelles inclues dans ceprofil de protection.
63 Les exigences d’administration(management) et les opérations (assignment, itera-tion, selection, refinement), doivent être complétées par le rédacteur de la cible desécurité.
Composantes Noms
1 FCO_NRO.2 Obligation de preuve de l’origine
2 FCS_CKM.2 Génération des clés cryptographiques basée sur desstandards
3 FCS_CKM.4 Distribution des clés cryptographiques basée sur desstandards
4 FCS_CKM.7 Destruction des clés cryptographiques
5 FCS_COP.2 Opération cryptographique basée sur des standards
6 FDP_ACC.2 Contrôle d’accès total
7 FDP_ACF.1 Contrôle d’accès basé sur les attributs de sécurité
8 FDP_ETC.2 Exportation des données de l’utilisateur avec attributsde sécurité
9 FDP_IFC.1 Contrôle de flux d’un sous-ensemble d’informations
10 FDP_IFF.1 Attributs de sécurité simples
11 FDP_ITC.2 Importation de données de l’utilisateur avec attributsde sécurité
12 FDP_SDI.2 Contrôle de l’intégrité des données stockées et mesuresconséquentes
Tab. 5.1 - Composantes de sécurité
Page 16
13 FDP_UCT.1 Confidentialité élémentaire de l’échange de données
14 FDP_UIT.1 Intégrité de l’échange de données
15 FIA_AFL.1 Action élémentaire en cas d’échec d’authentificationde l’utilisateur
16 FIA_SOS.1 Vérification des secrets
17 FIA_SOS.2 Génération des secrets par la TSF
18 FIA_UID.2 Identification de l’utilisateur avant action
19 FIA_UAU.1 Temporisation de l’authentification
20 FIA_UAU.5 Mécanismes multiples d’authentification
21 FIA_UAU.6 Ré-authentification
22 FMT_MSA.1 Gestion des attributs de sécurité
23 FMT_MSA.2 Attributs de sécurité sûrs
24 FMT_MSA.3 Initialisation statique des attributs de sécurité
25 FMT_SMR.1 Rôles de sécurité
26 FPT_AMT.1 Machine abstraite de test
27 FPT_FLS.1 Conservation d’un état sûr lors d’une défaillance
28 FPT_ITC.1 Confidentialité inter-TSF pendant une transmission
29 FPT_ITI.1 Détection de modification inter-TSF
30 FPT_ITT.1 Protection élémentaire de données internes à la TSF
31 FPT_ITT.3 Surveillance de l’intégrité des données de la TSF
32 FPT_PHP.3 Résistance aux attaques physiques
33 FPT_RCV.1 Recouvrement manuel
34 FPT_RVM.1 Non contournement de la politique de sécurité
Composantes Noms
Tab. 5.1 - (Suite) - Composantes de sécurité
Page 17
5.2 Liste des exigences fonctionnelles
5.2.1 Composante FCO
FCO_NRO.2 Enforced Proof of Origin
64 FCO_NRO.2.1 The TSF shall enforce the generation of evidence of origin for trans-mitted [assignment:list of information types] at all times.
65 Types d’information : tous les messages traités par la TOE (enveloppes, messages,pièces jointes et certificats).
66 FCO_NRO.2.2 The TSF shall be able to relate the [assignment:list of attributes] ofthe originator of the information, and the [assignment:list of information fields] ofthe information to which the evidence applies.
67 La liste des attributs comprend les signatures et certificats de clés publiquesattachés aux messages gérés par la TOE et la désignation de l’émetteur ou/et durédacteur de ces messages.
68 La liste des champs d’informations est décrite par le rédacteur de la cible de sécu-rité.
69 FCO_NRO.2.3 The TSF shall provide a capability to verify the evidence of originof information to [selection:originator, recipient,[assignment: list of thirdparties]] given [assignment: limitations on the evidence of origin].
5.2.2 Composante FCS
FCS_CKM.2 Standards-Based Cryptographic Key Generation
35 FPT_TDC.1 Consistance élémentaire des données de la TSF inter-TSF
36 FPT_TST.1 Tests de la TSF
37 FTA_SSL.3 Fonction d’abandon de session
38 FTA_TSE.1 Etablissement de session de la TOE
39 FTP_ITC.1 Canal sûr inter-TSF
Composantes Noms
Tab. 5.1 - (Suite) - Composantes de sécurité
Page 18
70 FCS_CKM.2.1 The TSF shall generate cryptographic keys in accordance with aspecified cryptographic key generation algorithm and specified cryptographic keysizes which meet the following standard: [assignment:list of international stand-ards, list of national standards, list of industry standards, list of organisationalstandards].
71 Les fonctions de génération des clés de la TOE utilisent un générateur d’aléa réelet/ou un générateur logiciel de pseudo-aléa.
72 La cible de sécurité décrira de façon précise les générateurs choisis et leur mise enoeuvre.
FCS_CKM.4 Standards-Based Cryptographic Key Distribution
73 FCS_CKM.4.1 The TSF shall distribute cryptographic keys in accordance with aspecified cryptographic key distribution method which meets the followingstandard: [assignment:list of international standards, list of national standards, listof industry standards, list of organisational standards].
74 Les méthodes décrites ci-dessous illustrent l’usage des ressources de cryptographielors de la distribution des clés d’authentification et de confidentialité.
75 Méthode pour l’obtention d’un certificat de clé publique de signature :
- L’utilisateur A génère à l’aide de sa TOE son bi-clé asymétrique designature.
- A communique à l’autorité de certification (notée AC(a)) sa clé publique etson identité. Remarque : AC(a) s’assure de l’identité de A par une mesurenon TI, par exemple une consultation d’annuaire, la présentation par A d’undocument officiel ou un rapport facial entre A et un agent d’enregistrementrelevant de l’autorité de AC(a).
- AC(a) forge un certificat de la clé publique en signant à l’aide de sa TOE lecouple formé de la clé publique et des informations identifiant A. AC(a)publie le certificat de cette clé publique de A.
76 Méthode pour l’obtention d’une clé de chiffrement :
- La tierce partie de confiance (notée TPC(a)) vérifie l’identité de A, aubesoin en communiquant avec l’autorité de certification de A. TPC(a)génère un bi-clé de confidentialité à l’aide de sa TOE et certifie la clépublique également à l’aide de sa TOE.
- TPC(a) protège la confidentialité de la clé privée de A au moyen de sa TOE.Eventuellement, la TPC(a) publie le certificat de la clé publique deconfidentialité de A.
FCS_CKM.7 Cryptographic Key Destruction
Page 19
77 FCS_CKM.7.1 The TSF shall destroy cryptographic keys in accordance with aspecified cryptographic key destruction method.
78 Le rédacteur de la cible de sécurité précisera la procédure d’effacement des secretsconservés dans la TOE.
FCS_COP.2 Standards-Based Cryptographic Operation
79 FCS_COP.2.1 The TSF shall perform [assignment:list of cryptographic opera-tions] in accordance with a specified cryptographic algorithm and cryptographickey size which meet the following standard: [assignment:list of internationalstandards, list of national standards, list of industry standards, list of organisa-tional standards].
80 Les opérations cryptographiques sont :
- l’authentification des parties communicantes,- la génération de clés symétriques et asymétriques,- la génération des condensats,- la protection des clés conservées dans la TOE,- la génération et la vérification de la signature numérique des messages et
des pièces jointes,- la vérification de l’intégrité d’un certificat de clé publique,- le chiffrement et le déchiffrement des messages et pièces jointes qui sont
échangés à l’aide de la TOE.
81 Le rédacteur de la cible de sécurité raffinera la description de toutes les opérationscryptographiques présentées ci-dessus.
5.2.3 Composante FDP
FDP_ACC.2 Complete Access Control
82 FDP_ACC.2.1 The TSF shall enforce the [assignment:access control SFP] on[assignment: list of subjects and objects] and all operations among subjects andobjects covered by the SFP.
83 FDP_ACC.2.2 The TSF shall ensure that all operations between any subject in theTSC and any object within the TSC are covered by the SFP.
FDP_ACF.1 Security Attribute Based Access Control
84 FDP_ACF.1.1 The TSF shall enforce the [assignment:access control SFP] toobjects based on [assignment: securityattributes, named groups of securityattributes].
85 FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an opera-tion among controlled subjects and controlled objects is allowed [assignment:rules
Page 20
governing access among controlled subjects and controlled objects usingcontrolled operations on controlled objects].
FDP_ETC.2 Export of User Data With Security Attributes
86 FDP_ETC.2.1 The TSF shall enforce the [assignment:access control SFP and/orinformation flow control SFP] when exporting user data, controlled under the SFP,outside of the TSC.
87 FDP_ETC.2.2 The TSF shall export the user data with the user data’s associatedsecurity attributes.
88 FDP_ETC.2.3 The TSF shall ensure that the security attributes, when exportedoutside the TSC, are unambiguously associated with the exported user data.
89 FDP_ETC.2.4 The TSF shall enforce [assignment:additional exportation controlrules] when user data is exported from the TSC.
FDP_IFC.1 Subset Information Flow Control
90 FDP_IFC.1.1 The TSF shall enforce the [assignment:information flow controlSFP] on [assignment:list of subjects, objects and operations among subjects andobjects covered by the SFP].
FDP_IFF.1 Simple Security Attributes
91 FDP_IFF.1.1 The TSF shall enforce the [assignment:information flow controlSFP] to enforce at least the following types of subject and object security attributes[assignment: theminimum number and type of security attributes].
92 FDP_IFF.1.2 The TSF shall permit an information flow between a controlledsubject and a controlled object via a controlled operation if the following rules hold[assignment:for each operation, the security attribute-based relationship that musthold between subject and object security attributes].
93 FDP_IFF.1.3 The TSF shall enforce the [assignment:additional information flowcontrol SFP rules].
94 FDP_IFF.1.4 The TSF shall enforce the following [assignment:list of additionalSFP capabilities].
FDP_ITC.2 Import of User Data with Security Attributes
95 FDP_ITC.2.1 The TSF shall enforce the [assignment:access control SFP and/orinformation flow control SFP] when importing user data, controlled under the SFP,from outside of the TSC.
96 FDP_ITC.2.2 The TSF shall use the security attributes associated with the importeduser data.
Page 21
97 FDP_ITC.2.3 The TSF shall ensure that the protocol used provides for the unam-biguous association between the security attributes and the user data received.
98 FDP_ITC.2.4 The TSF shall ensure that interpretation of the security attributes ofthe imported user data is as intended by the source TSF.
99 FDP_ITC.2.5 The TSF shall enforce the following [assignment:additional impor-tation control rules] when importing user data controlled under the SFP fromoutside the TSC.
FDP_SDI.2 Stored Data Integrity Monitoring and Action
100 FDP_SDI.2.1 The TSF shall monitor user data stored within the TSC for [assign-ment: integrity errors] on all objects, based on the following [assignment:user dataattributes].
101 Toutes les données contenues dans la TOE (clés, certificats, attributs de sécurité,données d’authentification, fonctions de cryptographie, logiciel, contextes d’appli-cation) sont concernées. La rédacteur de la cible de sécurité complétera cette liste.
102 FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall [assignment:action to be taken].
103 La mesure à prendre en cas de détection de la perte d’intégrité d’un des objets estd’inhiber toutes les fonctionnalités.
FDP_UCT.1 Basic Data Exchange Confidentiality
104 The TSF shall enforce the [assignment:access control SFP and/or information flowcontrol SFP] to be able to [selection: transmit, receive] objects in a mannerprotected from unauthorised disclosure.
FDP_UIT.1 Basic Data Exchange Integrity
105 FDP_UIT.1.1 The TSF shall enforce the [assignment:access control SFP and/orinformation flow control SFP] to be able to [selection: transmit, receive] user datain a manner protected from undetectable [selection:modification, deletion, inser-tion, replay] errors
106 FDP_UIT.1.2 The TSF shall be able to determine on receipt of user data, whether[selection:modification, deletion, insertion, or replay] has occurred.
5.2.4 Composante FIA
FIA_AFL.1 Basic authentication failure handling
107 FIA_AFL.1.1 The TSF shall detect when [selection: an authorised administratorconfigurable number of , [assignment:number]] unsuccessful authenticationattempts occur related to [assignment: list of authentication events].
Page 22
108 FIA_AFL.1.2 After the defined number of unsuccessful authentication attempts hasbeen detected, the TSF shall [assignment: list of actions].
FIA_SOS.1 Verification of secrets
109 FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet[assignment:a defined quality metric].
FIA_SOS.2 TSF Generation of Secret
110 FIA_SOS.2.1 The TSF shall provide a mechanism to generate secrets that meet[assignment:a defined quality metric].
111 FIA_SOS.2.2 The TSF shall be able to enforce the use of TSF generated secrets for[assignment:list of TSF functions].
FIA_UID.2 User Identification before any action
112 FIA_UID.2.1 The TSF shall require each user to identify itself before allowing anyTSF-mediated actions on behalf of that user.
FIA_UAU.1 Timing of authentification
113 FIA_UAU.1.1 The TSF shall allow [assignment:list of TSF mediated actions] onbehalf of the user to be performed before the user is authenticated.
114 FIA_UAU.1.2 The TSF shall require each user to be successfully authenticatedbefore allowing any other TSF-mediated actions on behalf of that user.
FIA_UAU.5 Multiple Authentication Mechanisms
115 FIA_UAU.5.1 The TSF shall provide [assignment: list of multiple authenticationmechanisms] to support user authentication.
116 FIA_UAU.5.2 The TSF shall authenticate any user’s claimed identity according tothe [assignment: rules describing how the multiple authentication mechanismsprovide authentication].
FIA_UAU.6 Re-authenticating
117 FIA_UAU.6.1 The TSF shall re-authenticate the user under the conditions [assign-ment: list of conditions under which re-authentication is required].
118 Après un délai d’inactivité fixé par l’autorité de sécurité et précisé par le rédacteurde la cible de sécurité, l’utilisateur doit de nouveau être authentifié.
Page 23
5.2.5 Composante FMT
FMT_MSA.1 Management of security attributes
119 FMT_MSA.1 The TSF shall enforce the [assignment: access control SFP, informa-tion flow control SFP] to restrict the ability to [selection:change_default, read,modify, delete] the values of the security attributes [assignment:list of securityattributes] to [assignment: the authorized identified roles].
FMT_MSA.2 Safe security attributes
120 FMT_MSA.2 The TSF shall ensure that only safe values are accepted for securityattributes.
FMT_MSA.3 Static Attribute Initialisation
121 FMT_MSA.3.1 The TSF shall enforce the [assignment: access control SFP, infor-mation flow control SFP] to provide [selection:restrictive, permissive, other prop-erty] default values for object security attributes that are used to enforce theSFP.
122 FMT_MSA.3.2 The TSF shall allow the [assignment: the authorised identifiedroles] to specify alternate initial values to override the default values when an objectis created.
FMT_SMR.1 Security roles
123 FMT_SMR.1.1 The TSF shall maintain the roles [assignment:the authorised iden-tified roles].
124 FMT_SMR.1.2 The TSF shall be able to associate users with roles.
5.2.6 Composante FPT
FPT_AMT.1 Abstract Machine Testing
125 FPT_AMT.1.1 The TSF shall run a suite of tests [selection:during initial start-up,periodically during normal operation, at the request of the authorised adminis-trator, other conditions] to demonstrate the correct operation of the security func-tions provided by the abstract machine which underlies the TSF.
FPT_FLS.1 Failure with Preservation of Secure State
126 FPT_FLS.1.1 The TSF shall preserve a secure state when [assignment:list of typesof TSF failures] occur.
FPT_ITC.1 Inter-TF Confidentiality During Transmission
Page 24
127 FPT_ITC.1.1 The TSF shall protect any TSF data transmitted from the TSF to aremote TSF from unauthorized disclosure.
FPT_ITI.1 Inter-TSF Detection of Modification
128 FPT_ITI.1.1 The TSF shall provide the capability to detect modification within[assignment:a defined modification metric] of all TSF data transmitted between theTSF and a remote trusted IT product.
129 FPT_ITI.1.2 The TSF shall verify the integrity of all TSF data transmitted betweenthe TSF and a remote trusted IT product and perform [assignment:action to betaken] in case modifications are detected.
FPT_ITT.1 Basic Internal TSF Data Transfer Protection
130 FPT_ITT.1.1 The TSF shall protect TSF data from [selection:disclosure, modifica-tion] when it is transmitted between physically-separated parts of the TOE.
FPT_ITT.3 TSF Data Integrity Monitoring
131 FPT_ITT.3.1 The TSF shall be able to detect [selection:modification of data,substitution of data, re-ordering of data, deletion of data, other integrity errors] forTSF data transmitted between physically-separated parts of the TOE.
132 FPT_ITT.3.2 Upon detection of a data integrity error, the TSF shall [assignment:specify the action to be taken].
FPT_PHP.3 Resistance to Physical Attack
133 FPT_PHP.3.1 The TOE shall resist identified physical tampering attacks to the[assignment:list of devices/elements, physical tampering attack scenarios, workfactors for which resistance to attack is required]
134 FPT_PHP.3.2 The TOE shall respond automatically to physical attacks to [assign-ment:list of devices/elements, physical tampering attack scenarios for which auto-matic response to attack is required] in such a way as to ensure that the TSP is notviolated
FPT_RCV.1 Manual Recovery
135 FPT_RCV.1.1 After a failure or service discontinuity, the TSF shall enter a main-tenance mode where the ability to return the TOE to a secure state is provided.
136 Remarque : l’état dit de confiance de la TOE après un dysfonctionnement ou uneinterruption de service peut être un vérouillage complet de la TOE qui peut néces-siter une repersonnalisation complète de la TOE.
137 FPT_RCV.1.2 The TSF shall provide the authorised administrator with the capa-bility to restore the TSF data to a consistent and secure state.
Page 25
FPT_RVM.1 Non-Bypassability of the TSP
138 FPR_RVM.1.1 The TSF shall ensure that TSP enforcement functions are invokedand succeed before assignment operation within the TSC is allowed to proceed.
FPT_TDC.1 Inter-TSF Basic TSF Data Consistency
139 FPT_TDC.1.1 The TSF shall enforce the consistent interpretation of [assignment:list of TSF data types] between this TSF and another trusted IT product.
140 FPT_TDC.1.2 The TSF shall use [assignment:list of interpretation rules to beapplied by the TSF] when interpreting the TSF data from another trusted IT product.
FPT_TST.1 TSF Testing
141 FPT_TST.1.1 The TSF shall run a suite of self tests [selection:during initial start-up, periodically during normal operation, at the request of the authorised adminis-trator, at the conditions [assignment: conditions at which self test should occur]] todemonstrate the correct operation of the TSF.
142 FPT_TST.1.2 The TSF shall provide authorized administrators with the capabilityto verify the integrity of TSF data.
143 FPT_TST.1.3 The TSF shall provide authorised administrators with the capabilityto verify the integrity of stored TSF executable code.
5.2.7 Composante FTA
FTA_SSL.3 TSF-initiated Termination
144 FTA_SSL3.1 The TSF shall terminate an interactive session after a [assignment:time interval] interval of user inactivity.
FTA_TSE.1 TOE Session Establishment
145 FTA_TSE.1.1 The TSF shall be able to deny session establishment based on[assignment:attributes].
5.2.8 Composante FTP
FTP_ITC.1 Inter-TSF Trusted Channel
146 FTP_ITC.1.1 The TSF shall provide a communication channel between itself and aremote trusted IT product that is logically distinct from other communication chan-nels and provides assured identification of its end points and protection of thechannel data from modification or disclosure.
Page 26
147 FTP_ITC.1.2 The TSF shall permit [selection:only the TSF, the remote trusted ITproduct] to initiate communication via the trusted channel.
148 FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for[assignment:list of functions for which a trusted channel is required].
Page 27
5.3 Exigences d’assurance des TI de la cible d’évaluation
149 Le niveau d’assurance visé est EAL5 augmenté de plusieurs composantes d’assur-ance.
150 Ce niveau est nécessairement élevé car le besoin exprimé par les utilisateurs estd’employer une TOE pour sécuriser des informations classifiées de défense duniveau Confidentiel Défense avec à terme la possiblité d’utiliser la TOE dans unsystème d’information approuvé pour traiter des informations classifiées SecretDéfense.
151 Par rapport au niveau EAL 4, le niveau retenu dans ce profil de protection apporteles assurances supplémentaires suivantes :
- une description semi-formelle des fonctions de sécurité,- une visibilité totale de l’implémentation de la TSF,- une représentation semi-formelle des correspondances entre les différentes
représentations,- le développement d’un modèle formel de politique de sécurité (contre un
développement informel dans le cas de EAL 4),- un modèle du cycle de vie de la TOE basé sur un standard,- un niveau de détail plus élevé dans la réalisation de tests,- une représentation semi-formelle des interfaces utilisateurs,- une recherche systématique des attaques possibles sur la TOE, et la garantie
de disposer d’un système “relativement” résistant.
152 Ces compléments s’accordent avec la nécessité de sécuriser des informations clas-sifiées de défense et justifient le choix d’un niveau d’assurance EAL 5.
153 Le niveau EAL5 est résumé dans le tableau 5.2. Les composantes d’assurancerajoutées sont listées dans le tableau 5.3.
Composantes Noms
ACM_AUT.1 Automatisation partielle de la gestion deconfiguration
ACM_CAP.4 Génération de supports et procédures de recette
ACM_SCP.3 Couverture de la gestion de configuration des outilsde développement
ADO_DEL.2 Détection de modification
ADO_IGS.1 Procédures d’installation, de génération, et dedémarrage
Tab. 5.2 - EAL5
Page 28
ADV_FSP.3 Spécification fonctionnelle semi-formelle
ADV_HLD.3 Conception générale semi-formelle
ADV_IMP.2 Implémentation de la TSF
ADV_INT.1 Modularité (composante couverte parl’augmentation)
ADV_LLD.1 Conception détaillée descriptive
ADV_RCR.2 Démonstration de correspondance semi-formelle
ADV_SPM.3 Modèle formel de la politique de sécurité de la TOE
AGD_ADM.1 Documentation de l’administrateur
AGD_USR.1 Documentation l’utilisateur
ALC_DVS.1 Identification des mesures de sécurité
ALC_LCD.2 Modèle standardisé du cycle de vie
ALC_TAT.2 Conformité à des standards d’implémentation
ATE_COV.2 Analyse de couverture
ATE_DPT.2 Test- conception détaillée (composante couvertepar l’augmentation)
ATE_FUN.1 Tests fonctionnels
ATE_IND.2 Test indépendant - échantillon
AVA_CCA.1 Analyse des canaux cachés (composante couvertepar l’augmentation)
AVA_MSU.2 Validation de l’analyse
AVA_SOF.1 Évaluation de la force des fonctions de sécurité dela cible d’évaluation.
AVA_VLA.3 Relativement résistant
Composantes Noms
Tab. 5.2 - (Suite) - EAL5
Page 29
154 L’ajout de la composanteADV_INT.3 permet de minimiser la complexité del’architecture de la TOE. Ces composantes viennent en complément de lacomposanteADV_IMP.2 en facilitant la compréhension de l’implémentation de laTOE.
155 L’ajout de la composanteALC_FLR.3 offre l’assurance de la réaction systéma-tique de l’éditeur de la TOE après détection d’un incident de sécurité de la TOE.
156 L’ajout de la composanteATE_DPT.3 permet de tester l’implémentation de laTOE à son plus bas niveau.
157 L’ajout de la composanteAVA_CCA.3 assure l’adoption d’une méthode exhaus-tive d’analyse des canaux cachés de la TOE, par rapport à une analyse simple(AVA_CCA.1).
158 Dans la mesure où la TOE est destinée à sécuriser des informations classifiées dedéfense, elle peut être confrontée à des attaques stratégiques ce qui justifie, dans lacomposante AVA_SOF.1, le choix du niveau de résistance le plus élevé possible:SOF - high.
Composantes Noms
ADV_INT.3 Minimisation de la complexité
ALC_FLR.3 Réparation systématique
ATE_DPT.3 Test - Implémentation
AVA_CCA.3 Analyse exhaustive des canaux cachés
Tab. 5.3 - Exigences d’assurance ajoutées
Page 31
Chapitre 6
Notes d’application
6.1 Exploitation de la TOE
159 Les responsables de l’exploitation de la TOE doivent être certains que la découverted’un dysfonctionnement de la TOE provoquera une réaction pertinente et rapide dedu constructeur de la TOE au profit de l’ensemble de ses utilisateurs de la TOE.
160 La disponibilité de la TOE peut diminuer si la TOE ne peut plus être maintenue pourréparation ou évolution en raison de la défaillance des fournisseurs des biens desupports (logiciels et materiels). L’utilisation et l’évolution de la TOE doivent êtreopérationnelles pour une durée fixée par l’autorité de sécurité et figurant dans lecontrat de fourniture de la TOE.
161 En conséquence, si la TOE ne peut plus être maintenue pour réparation ou évolutionen raison de défaut d’organisation administrative (absence de personnel spécialisé,défaut de budget) le niveau de sécurité de l’environnement d’emploi de la TOE peutdiminuer et donc porter atteinte à la sécurité des biens traités par la TOE.
162 Les documents de spécification de la TOE sont séquestrés en lieu sûr et consultablesuniquement par les personnes ayant le besoin d’en connaître.
6.2 Législation applicable en France
163 Plusieurs contraintes légales existent qui obligent les administrations et organismesliés par tutelle ou contrat à l’Etat à mettre en œuvre des mesures techniques visantà protéger les informations traitées par les administrations :
- la loi relative à la protection du secret de défense (code pénal art 410-1,411-1 à 414-9),
- la loi n 78-17, du 6 janvier 1978, relative à l’informatique, aux fichiers etaux libertés,
- la loi relative au secret professionnel (Code pénal : art 226-13 et 226-13),
- loi 91-646 du 11 juillet 1991 relative au secret des correspondances.
164 La loi n˚90.1170 du 29 décembre 1990 modifiée sur la réglementation destélécommunications, notamment son article 28 précise la réglementation applicableaux moyens et prestations de cryptologie. Les constructeurs, distributeurs etutilisateurs de la TOE doivent prendre connaissance du décret ci-dessous :
Page 32
- Décret n˚98-101 du 24 février 1998 définissant les conditions danslesquelles sont souscrites les déclarations et accordées les autorisationsconcernant les moyens et prestations de cryptologie (J.O. du 25/02/98pp.2911).
165 Le terme TTP est utilisé dans ce PP, la législation française emploie l’expression“organisme gérant pour le compte d’autrui des conventions secrètes de cryptologie”Le décret cité ci-dessous précise le terme d’agrément de ces organismes :
- Décret n˚98-102 du 24 février 1998 définissant les conditions danslesquelles sont agréées les organismes gérant pour le compte d’autrui desconventions secrètes de cryptologie en application de l’article 28 de la loi n˚90-1170 du 29 décembre 1990 sur la réglementation destélécommunications (J.O. du 25/02/98, pp. 2915).
166 Lorsque le contenu des messages, leur simple existence, y compris leur destinataire,récipiendaire ou date d’envoi relève du secret de défense, l’ensemble de laréglementation interministérielle s’applique :
- l’instruction générale interministérielle n 1300/SGDN/SSD du 12 mars1982, sur la protection du secret et des informations concernant la défensenationale et la sûreté de l’État,
- l’instruction interministérielle n 500bis/SGDN/TTS/SSI/DR, du 18 octobre1996, relative au chiffre dans la sécurité des systèmes d’information,
- l’instruction générale n 900/DISSI/SCSSI/DR, du 20 juillet 1993, sur lasécurité des systèmes d’information qui font l’objet d’une classification dedéfense pour eux-mêmes ou pour les informations traitées.
167 Dans le cas contraire, la recommandation n 901/DISSI/SCSSI, du 2 mars 1994,pour la protection des systèmes d’informations sensibles non classifiées de défense,peut guider le développement et l’utilisation d’une messagerie électronique dansl’administration.
Page 33
Chapitre 7
Justification du profil de protection
7.1 Menaces non couvertes par le profil de protection
168 La cible d’évaluation décrite dans ce PP ne suffit pas à elle seule à sécuriser unservice de messagerie. En particulier, les menaces citées dans la liste nonexhaustive qui suit, ne sont pas couvertes par le présent profil.
7.1.1 Menaces non couvertes portant sur la TOE
169 MNC.DYSFONC-D : Le dysfonctionnement de la TOE risque d’entraîner uneperte de disponibilité des biens indirects conservés dans la TOE. Cette vulnérabilitéprovient soit de la défaillance accidentelle d’un composant de la TOE soit de samodification par un attaquant. Cette menace n’est pas couverte pas le présent profil.
170 MNC.VOL-TOE-D : Le vol de la TOE est une perte de disponibilité de sesfonctions de sécurité et des secrets qu’elle conserve. Cette menace n’est pascouverte par le présent profil.
171 MNC.TEMPEST : Les changements électromagnétiques du poste utilisateur et dela ressource cryptologique sont des menaces portant sur la TOE car les signauxparasites induits peuvent compromettre la sécurité des biens de la TOE.Conformément à la directive [495], l’emploi de la TOE pour le traitement desinformations classifiées de défense impose une politique de zonage des lieuxd’emploi pour vérifier que le rayonnement de la TOE et du poste utilisateur ne portepas atteinte à la sécurité des biens directs ou indirects sécurisés par la TOE. Cettemenace n’est pas couverte pas le présent profil.
7.1.2 Menaces non couvertes portant sur le poste utilisateur
172 MNC.DYSFONC-PU : Le dysfonctionnement du matériel ou du systèmed’exploitation du poste utilisateur ou encore des pilotes logiques d’extension de laTOE risque de nuire à la disponibilité de la TOE. Cette menace n’est pas couvertepar le présent profil.
173 MNC.VOL-SUPPORT : Le vol d’un disque ou d’une disquette ayant contenu oucontenant des informations classifiées provoque une perte de confidentialité et dedisponibilité de ces informations. Cette menace n’est pas couverte par le présentprofil.
174 MNC.RESIDUEL : L’utilisation de logiciel bureautique pour créer des biensdirects peut entraîner la persistance d’information résiduelle (fichiers temporaires,mémoires tampons, versions antérieures, fichiers rémanant,..). Cette menaceprovoque une perte de la confidentialité des biens directs. Elle n’est pas couverte
Page 34
par le présent profil de protection car elle relève de la politique du SI et de la miseen oeuvre de procédures adéquates de création et de gestion de ces biens directs.
175 MNC.VIRAL : Une attaque virale du poste utilisateur ou la réception d’un biencontaminé est une atteinte à l’intégrité du système d’exploitation, des piloteslogiques d’extension de la TOE et des biens directs conservés. Cette menace n’estpas couverte par le présent PP car elle relève de la politique de sécurité du SI et dela mise en oeuvre d’une contre mesure efficace.
7.1.3 Menaces non couvertes portant sur la rédaction des messages
176 MNC.EDITION : L’ensemble des erreurs éditoriales, de reproduction et declassification des informations par l’utilisateur (par exemple, l’émission d’unmessage classifié sans protection de sa confidentialité) est une menace qui risque denuire à la confidentialité des informations classifiées. Cette menace n’est pascouverte par le présent profil.
7.1.4 Menaces non couvertes portant sur la TOE et le réseau local de l’utili-sateur
177 MNC.SATURATION : La perte de disponibilité de l’applicatif utilisant la TOEpar saturation du réseau reliant le poste utilisateur au serveur de messagerie n’estpas une menace couverte par le présent profil. Cette menace doit être traitée auniveau de la politique de sécurité et de l’administration technique du réseau.
178 MNC.ANALYSE : Le présent profil ne couvre pas les menaces d’analyse du traficdes réseaux. Suivant le degré de sécurité du réseau exigé par l’autorité de sécurité,la confidentialité du flux d’information sera assurée par un moyen de chiffrementde voie.
7.1.5 Menaces non couvertes portant sur la TOE et le serveur de messagerie
179 MNC.BESOIN-CONNAITRE : L’envoi d’un message sécurisé à l’aide de la TOEà un utilisateur n’ayant pas le besoin d’en connaître est une atteinte à laconfidentialité du message. Cette menace n’est pas couverte par le présent profil carelle relève de la politique du SI et de la mise en oeuvre au niveau du serveur demessagerie de mesures de vérification.
Page 35
7.2 Justification des objectifs de sécurité
180 Dans le tableau ci-dessous, il s’agit de démontrer que les objectifs de sécuritéénoncés dans le chapitre 4 sont pertinents vis-à-vis des menaces portant sur la TOEet son environnement exprimées dans le chapitre 3.
Menaces Objectifs Justificatifs
M.INTRUSIONO.TOE-ACCESO.NOIRO.VOL
Les mesures préventives telles que la conserva-tion sous la forme chiffrée des secrets dans laTOE, l’indentification et l’authentification desutilisateurs, la gestion des dysfonctionnements,rendent impossible l’usage de la TOE à son éven-tuel voleur ou attaquant cherchant à pénétrer dansla TOE.
M.DYSFONC O.SECOURS
Des processus de diagnostic interne à la TOE etun blocage de la TOE en cas de dysfonctionne-ment détécté empêchent l’exploitation de toutdysfonctionnement de la TOE au profit d’un at-taquant.
M.CLONAGE O.TOE-ACCESO.NOIR
Une modélisation des fonctions de cryptographieà partir d’un clône de la TOE ne permet pas demettre en oeuvre ces fonctions . En effet, la miseen oeuvre des fonctions de la TOE n’est possiblequ’à l’aide de biens inaccessibles grâce àO.NOIR et requiert l’accès à la TOE, impossiblegrâce à O.TOE-ACCESS.
M.PILOTE O.GUIDE
Les documents et moyens informatiques fournis àl’utilisateur de la TOE doivent contribuer à la de-tecter des pertes d’intégrité des pilotes logiquesd’extension de la TOE.
M.MODIFIE O.TOE-ACCESO.INTEGRITE
Le contrôle d’accès à la TOE, la signature des bi-ens exportés et la vérification systématique del’intégrité de biens importés permettent la détec-tion de toute perte d’intégrité des biens échangés.
Tab. 7.1 - Couverture des menaces par les objectifs.
Page 36
181 Dans le tableau ci-dessous, il s’agit de démontrer que les objectifs de sécuritéénoncés dans le chapitre 4 sont pertinents vis-à-vis des politiques de sécurité organ-isationnelles exprimées dans le chapitre 3.
M.DIVULG O.SECRETO.AUTH
L’authentification des parties communicantes etle chiffrement des biens neutralisent le risqued’échanger des informations avec des utilisateursnon autorisés.
M.ECHANGEO.AUTHO.USAGEO.MESSAGERIE
L’échange involontaire de biens secrets avec unutilisateur non autorisé est impossible dans lamesure où la TOE est correctement utilisée et ad-ministrée et où les parties communicantes sontauthentifiables (O.MESSAGERIE) et authenti-fiées (O.AUTH).
Politique desécurité del’organisme
Objectifs Justificatif
P.UTILIS O.UTILIS
L’objectif O.UTILIS imposant l’impossibilitéd’utiliser la TOE à des fins non décrites dans leChapitre 2 permet de réaliser la politique P.UTI-LIS.
P.ADMIN O.ADMIN
La présence d’une infrastructure de communica-tion opérationnelle entre l’administrateur et l’uti-lisateur permet de garantir que l’administrateurpeut joindre l’utilisateur dans les plus brefsdélais.
P.CSP
O.AUTHO.INTEGRITEO.SECRETO.MESSAGERIE
La TOE participe à la réalisation de la politiqueP.CSP grâce O.AUTH qui permet l’authentifica-tion, O.INTEGRITE et O.SECRET qui assurentl’intégrité et la confidentialité des informationstransmises.De plus, la présence de O.MESSAGERIE assurela mise en place d’une infrastructure sûre, néces-saire à la mise en oeuvre de la politique.
Tab. 7.2 - Couverture des politiques de sécurité par les objectifs de sécurité
Menaces Objectifs Justificatifs
Tab. 7.1 - (Suite) - Couverture des menaces par les objectifs.
Page 37
182 Dans le tableau ci-dessous, il s’agit de démontrer que les objectifs de sécuritéénoncés dans le chapitre 4 sont pertinents vis-à-vis des hypothèses d’utilisationexprimées dans le chapitre 3.
Hypothèses Objectifs Justificatifs
H.USAGE O.GUIDEO.USAGE
L’usage et de l’administration de la TOE ne doiventpas nuire à la sécurité des informations classifiées dedéfense. Ces objectifs imposent une habilitation etune formation des personnels ainsi qu’une docu-mentation explicite d’usage et d’administration de laTOE.
H.RESP O.USAGEL’usage de la TOE et son administration sont condi-tionels à une information complète de l’utilisateurde la TOE sur sa responsabilité.
H.MESSAGERIE O.MESSAGERIE
L’usage seul de la TOE ne suffit pas à sécuriser unemessagerie électronique ou toute autre application.Il est indispensable que chaque composante traitantdes informations classifiées de défense soit em-ployée conformément à une politique de sécurité etsoit évaluée pour apporter la preuve qu’elle n’af-faiblit pas la sécurité de l’application.
Tab. 7.3 - Couvertures des hypothèses d’utilisation par les objectifs de sécurité
Page 38
7.3 Tableau croisé
183 Le tableau croisé ci-dessous démontre que chaque objectif de sécurité répond aumoins à une menace ou à une politique de sécurité organisationnelle ou encore à unehypothèse d’utilisation sûre.
Les menaces etla politique de
sécuritéorganisationnelle
et hypothèses
Objectifs de sécurité
O.T
OE
-AC
CE
S
O.N
OIR
O.IN
TE
GR
ITE
O.S
EC
RE
T
O.V
OL
O.S
EC
OU
RS
O.A
UT
H
O.G
UID
E
O.U
SA
GE
O.M
ES
SA
GE
RIE
O.U
TILIS
O.A
DM
IN
M.INTRUSION X X X
M.DYSFONC X
M.CLONAGE X X
M.PILOTE X
M.MODIFIE X X
M.DIVULG X X
M.ECHANGE X X X
P.UTILIS X
P.ADMIN X
P.CSP X X X X
H.USAGE X X
H.RESP X
H.MESSAGERIE X
Tab. 7.4 - Tableau croisé
Page 39
7.4 Justificatif des exigences de sécurité
7.4.1 Tableau de couverture
184 Le tableau ci-dessous démontre qu’au moins une exigence fonctionnelle répond àchaque objectif de sécurité de la TOE et que toutes les exigences atteignent aumoins un objectif de sécurité.
Exigences
O.T
OE
-AC
CE
S
O.N
OIR
O.IN
TE
GR
ITE
O.S
EC
RE
T
O.V
OL
O.S
EC
OU
RS
O.A
UT
H
FCO_NRO.2 X
FCS_CKM.2 X X
FCS_CKM.4 X X X
FCS_CKM.7 X X X
FCS_COP.2 X X X X X
FDP_ACC.2 X X
FDP_ACF.1 X X
FDP_ETC.2 X X
FDP_IFC.1 X X
FDP_IFF.1 X X X
FDP_ITC.2 X X
FDP_SDI.2 X
FDP_UCT.1 X
FDP_UIT.1 X
FIA_AFL.1 X
FIA_SOS.1 X X X
Tab. 7.5 - Couverture Objectifs - Exigences
Page 40
FIA_SOS.2 X X X X X
FIA_UID.2 X
FIA_UAU.1 X
FIA_UAU.5 X
FIA_UAU.6 X
FMT_MSA.1 X
FMT_MSA.2 X X X X
FMT_MSA.3 X
FMT_SMR.1 X
FPT_AMT.1 X
FPT_FLS.1 X
FPT_ITC.1 X X
FPT_ITI.1 X X
FPT_ITT.1 X X
FPT_ITT.3 X X
FPT_PHP.3 X X
FPT_RCV.1 X
FPT_RVM.1 X X X X X X X
FPT_TDC.1 X X X
FPT_TST.1 X
Exigences
O.T
OE
-AC
CE
S
O.N
OIR
O.IN
TE
GR
ITE
O.S
EC
RE
T
O.V
OL
O.S
EC
OU
RS
O.A
UT
H
Tab. 7.5 - (Suite) - Couverture Objectifs - Exigences
Page 41
7.4.2 Justifications
185 Les exigences fonctionnelles retenues dans ce profil de protection coopèrent etforment un tout cohérent.
7.4.2.1 Composante FCO
FCO_NRO.2 Obligation de preuve de l’origine
186 Cette composante a été choisie pour définir la génération par la TOE des informa-tions nécessaires à l’authentification de l’origine d’un message échangé entre deuxTOE. Cette authentification est imposée par l’objectif de sécurité O.AUTH.
7.4.2.2 Composante FCS
FCS_CKM.2 Génération des clés cryptographiques basée sur des standards
187 Les objectifs de sécurité O.INTEGRITE et O.SECRET impliquent la capacité designer et chiffrer des données et donc de générer des quantités aléatoires ou pseudo-aléatoires. La composante FCS_CKM.2 spécifie la génération des clés nécessairesà l’usage de la TOE.
FCS_CKM.4 Distribution des clés cryptographiques basée sur des standards
188 Cette composante précise les protocoles de distribution des clés gérées par la TOEou par le logiciel de messagerie installé sur le poste utilisateur pour atteindre lesobjectifs de sécurité O.INTEGRITE, O.SECRET et O.AUTH qui imposent lacapacité de signer et de chiffrer et donc de savoir échanger des clés.
FCS_CKM.7 Destruction des clés cryptographiques
FTA_SSL.3 X
FTA_TSE.1 X
FTP_ITC.1 X
Exigences
O.T
OE
-AC
CE
S
O.N
OIR
O.IN
TE
GR
ITE
O.S
EC
RE
T
O.V
OL
O.S
EC
OU
RS
O.A
UT
H
Tab. 7.5 - (Suite) - Couverture Objectifs - Exigences
Page 42
189 L’objectif O.SECRET pose le problème de la durée de vie de la clé symétrique dechiffrement du message exporté de la TOE. La TOE devra “oublier” la clé aprèsusage. Cet oubli sera obtenu par une réinitialisation des mémoires de conservationde cette clé.
190 Les objectifs O.TOE-ACCES et O.SECOURS imposent éventuellement que laTOE adopte des mesures de destruction physique de ses clés.
FCS_COP.2 Opérations cryptographiques basées sur des standards
191 Cette composante définit toutes les opérations cryptographiques de la TOE. Lesobjectifs O.TOE-ACCES, O.NOIR, O.INTEGRITE, O.SECRET, O.AUTH nepeuvent être satisfaits que par l’emploi de fonctions normalisées de cryptographie.
7.4.2.3 Composante FDP
FDP_ACC.2 Contrôle d’accès total
192 Cette composante précise les conditions d’accès aux secrets (O.NOIR) et aux biensprotégés en confidentialité (O.SECRET).
FDP_ACF.1 Contrôle d’accès basé sur les attributs de sécurité
193 Cette composante précise les attributs de sécurité des secrets (O.NOIR) et des biensprotégés en confidentialité (O.SECRET).
FDP_ETC.2 Exportation des données de l’utilisateur avec attributs de sécurité
194 Les biens indirects exportés de la TOE sont associés de manière non ambiguë àleurs attributs de sécurité. Cette association est indispensable à la mise en oeuvredes moyens de protection de la confidentialité (O.SECRET) et de l’intégrité(O.INTEGRITE) de ces biens.
FDP_IFC.1 Contrôle de flux d’un sous-ensemble d’information
195 Cette composante permet au rédacteur de la cible de sécurité de définir les sous-ensembles d’actions pour lesquelles un contrôle d’accès (O.TOE-ACCES) serarequis lors des accès aux biens conservés par la TOE. Ceci permet de définirprécisément la protection de la confidentialité des secrets de la TOE (O.NOIR).
FDP_IFF.1 Attributs de sécurité simples
196 Cette composante précise les attributs de sécurité des secrets (O.NOIR), des bienssignés (O.INTEGRITE) et des biens protégés en confidentialité (O.SECRET).
FDP_ITC.2 Importation des données de l’utilisateur avec attributs de sécurité
Page 43
197 Les biens indirects importés de la TOE sont associés de manière non ambiguë àleurs attributs de sécurité. Cette association est indispensable à la mise en oeuvredes moyens de protection de la confidentialité (O.SECRET) et de l’intégrité(O.INTEGRITE) de ces biens.
FDP_SDI.2 Contrôle de l’intégrité des données stockées et mesures conséquentes
198 Cette composante définit tous les biens indirects contenus dans la TOE (clés, certi-ficats, attributs de sécurité, données d’authentification, fonctions de cryptographie,logiciel, contextes d’application) qui doivent être protégés en intégrité et confiden-tialité (O.NOIR).
FDP_UCT.1 Confidentialité élémentaire de l’échange de données
199 Cette composante définit les biens traités par la TOE qui devront être chiffrés(O.SECRET).
FDP_UIT.1 Integrité des données
200 Cette composante définit les biens traités par la TOE dont l’intégrité devra êtreconservée (O.INTEGRITE).
7.4.2.4 Composante FIA
FIA_AFL.1 Action élémentaire en cas d’échec d’authentification de l’utilisateur
201 Cette composante détermine conformément à l’objectif O.TOE-ACCES lesconditions d’échec de l’authentification de l’utilisateur.
FIA_SOS.1 Vérification des secrets
202 Cette composante précise les tests appliqués aux secrets traités par la TOE afin decontribuer à atteindre l’objectif de sécurité O.TOE-ACCES, O.SECOURS etO.NOIR (secrets internes à la TOE).
FIA_SOS.2 Génération des secrets par la TSF
203 Cette composante définit la liste des méthodes employées par la TOE pour générerles secrets nécessaires à l’identification (O.TOE-ACCES) de l’utilisateur, àl’authentification des parties communicantes (O.INTEGRITE et O.AUTH), à laconfidentialité des biens échangés (O.SECRET) et à la conservation de l’intégritéet la confidentialité des biens secrets contenus dans la TOE (O.NOIR).
FIA_UID.2 Identification de l’utilisateur avant action
204 Cette composante impose l’identification de l’utilisateur avant tout emploi desfonctions de sécurité de la TOE, et contribue donc à répondre à l’objectif de sécuritéO.TOE-ACCES.
Page 44
FIA_UAU.1 Temporisation de l’authentification
205 Cette composante définit les conditions d’emploi par la TOE de l’authentificationpour contribuer à répondre à l’objectif de sécurité O.TOE-ACCES.
FIA_UAU.5 Mécanismes multiples d’authentification
206 Cette composante requiert la description des différents mécanismes d’authentifica-tion supportés par la TOE. Elle permet de contribuer à répondre à l’objectif de sécu-rité O.TOE-ACCES.
FIA_UAU.6 Ré-authentification
207 La ré-authentification est mise en oeuvre après un délai d’inactivité fixé parl’autorité de sécurité (en cas de non ré-authentification, la session d’utilisation de laTOE est close). Cette composante permet de réaliser en partie l’objectif O.TOE-ACCES.
7.4.2.5 Composante FMT
208 Pour chaque exigence fonctionnelle, les exigences d’administration proposéesdoivent être renseignées par le rédacteur de la cible de sécurité.
FMT_MSA.1 Gestion des attributs de sécurité
209 Cette composante permet de renforcer le contrôle d’accès par l’attribution de rôleset de droits aux utilisateurs. Elle renforce l’objectif de sécurité O.TOE-ACCESS.
FMT_MSA.2 Attributs de sécurité sûrs
210 Les attributs de sécurité sont définis et limités par des valeurs sûres, fixées parl’autorité de sécurité compétente. Ces mesures permettent de renforcer la confiden-tialité et l’intégrité des biens (O.INTEGRITE, O.SECRET, O.NOIR) ainsi que lecontrôle d’accès (O.TOE-ACCES).
FMT_MSA.3 Initialisation statique des attributs de sécurité
211 Lors de la personnalisation électrique ou logique de la TOE, cette composanteprécise les attributs de sécurité sur l’ensemble des objets (biens indirects et varia-bles d’états internes) de la TOE et contribue à répondre à l’objectif de sécuritéO.TOE-ACCES lors de la première session.
FMT_SMR.1 Rôles de sécurité
212 Les fonctions de sécurité doivent pouvoir distinguer les différents utilisateurs,contribuant ainsi à résoudre l’objectif de sécurité O.TOE-ACCES.
Page 45
7.4.2.6 Composante FPT
FPT_AMT.1 Machine abstraite de test
213 La détection d’un dysfonctionnement de la TOE a lieu lors de la comparaison desresultats de tests internes à la TOE et les résultats donnés par un modèle abstrait.L’objectif O.SECOURS est en partie satisfait par l’application de tests et leurscomparaisons avec le modèle abstrait.
FPT_FLS.1 Conservation d’un état sûr lors d’une défaillance
214 Cette composante précise que les TSF doivent permettre de retrouver un état stabledit de confiance après une défaillance, contribuant ainsi à satisfaire l’objectif desécurité O.SECOURS.
FPT_ITC.1 Confidentialité inter-TSF pendant une transmission
215 Cette composante contribue à assurer la confidentialité (O.NOIR et O.SECRET)des secrets lors de la personnalisation électrique de la TOE par une station de confi-ance de personnalisation.
FPT_ITI.1 Détection de modification inter-TSF
216 Cette composante contribue à assurer l’intégrité des échanges lors de la personnal-isation électrique de la TOE par une station de confiance de personnalisation. Lesobjectifs O.NOIR et O.INTEGRITE sont ainsi en partie satisfaits.
FPT_ITT.1 Protection élémentaire de données internes à la TSF
217 Les transferts de données entre deux entités de la TOE, physiquement distinctesdoivent être sécurisés contre la modification (O.INTEGRITE) ou la divulgation(O.NOIR).
FPT_ITT.3 Surveillance de l’intégrité des données par la TSF
218 Cette composante spécifie que la TSF doit être capable de détecter la perte d’intég-rité (O.NOIR) de données transmises d’une partie de la TOE à une autre (physique-ment distincte) et prendre des mesures adaptées en cas d’erreur (O.SECOURS).
FPT_PHP.3 Résistance aux attaques physiques
219 Cette composante spécifie que la TOE est capable de résister à des attaques sur sesfonctions de sécurité (O.SECOURS) et de contribuer à préserver l’intégrité et laconfidentialité des données qu’elle contient (O.NOIR).
FPT_RCV.1 Recouvrement manuel
Page 46
220 Après détection d’un dysfonctionnement, la TOE doit impérativement être dans unétat stable dit de confiance. Cet état se caractérise par un verrouillage complet desfonctions de sécurité. L’unique recouvrement manuel possible est alors une person-nalisation électrique de la TOE. L’objectif O.SECOURS est ainsi en partie satisfait.
FPT_RVM.1 Non contournement de la politique de sécurité
221 Cette composante impose que les fonctions de sécurité ne soient pas contournables,afin de préserver la sécurité des accès à la TOE (O.TOE-ACCES), l’authentificationdes parties communicantes (O.AUTH), la confidentialité et l’intégrité des bienscontenus dans la TOE (O.NOIR) ou des biens échangés (O.INTEGRITE,O.SECRET), ainsi que la sécurité des biens à protéger en cas de dysfonctionnement(O.SECOURS) ou de vol (O.VOL).
FPT_TDC.1 Consistance élémentaire des données de la TSF inter-TSF
222 Cette composante contribue à assurer une cohérence entre les interprétations desbiens et variables d’états internes de la TOE lors d’un échange avec une composantede confiance des technologies de l’information. Les objectifs (O.INTEGRITE,O.SECRET, O.AUTH) portant sur la protection des biens importés ou exportés sontainsi en partie couverts.
FPT_TST.1 Tests de la TSF
223 Les TSF doivent fournir un ensemble de tests qui permettent de s’assurer de leursbons fonctionnements par rapport à un modèle abstrait (FPT_AMT.1). En cas dedétection d’un dysfonctionnement par rapport à ce modèle des mesures conserva-toires devront être prises pour contribuer à l’objectif O.SECOURS.
7.4.2.7 Composante FTA
FTA_SSL.3 Fonction d’abandon de session
224 Après une période d’inactivité, la TOE clot la session de l’utilisateur et rétablit unesession après ré-authentification de l’utilisateur (O.TOE-ACCESS).
FTA_TSE.1 Etablissement de session de la TOE
225 Une TSF propre à la TOE peut refuser une demande d’accès suivant des paramètrespropres à la TOE et définis par l’autorité de sécurité compétente. L’objectif de sécu-rité O.TOE-ACCES est donc enrichi.
7.4.2.8 Composante FTP
FTP_ITC.1 Canal sûr inter-TSF
226 L’authentification de l’utilisateur demande un canal sûr entre l’utilisateur et laTOE. Ce canal peut être sûr logiquement par l’usage de fonctions cryptographiques
Page 47
et/ou physiquement par emploi d’un support d’authentification protégé, comme parexemple, une carte à puce et un lecteur de carte sécurisé. Ce canal sûr contribue àsatisfaire l’objectif O.TOE-ACCES.
Page 48
7.5 Dépendances des composantes fonctionnelles
227 Pour l’évaluation de ce profil de protection, il est nécessaire de vérifier que toutesles dépendances sont satisfaites. Le tableau ci-dessous démontre l’absence dedépendances internes non satisfaites.
228 Le symbole “---” signifie que la composante n’admet pas de dépendance.
Composantes Noms DépendancesCC Satisfactions
FCO_NRO.2 Obligation de preuve de l’origine. FIA_UID.1 FIA_UID.2
FCS_CKM.2 Génération des clés cryptographiquesbasée sur des standards.
FCS_CKM.3or FCS_COP.1;FCS_CKM.7FMT_MSA.2
FCS_CKM.4FCS_CKM.7FMT_MSA.2
FCS_CKM.4 Distribution des clés cryptographiquesbasée sur des standards.
FDP_ETC.1 orFCS_CKM.1;FCS_CKM.7FMT_MSA.2
FCS_CKM.2;FCS_CKM.7FMT_MSA.2
FCS_CKM.7 Destruction des clés cryptographiques.FMT_MSA.2;FDP_ITC.1 orFCS_CKM.1
FMT_MSA.2;FCS_CKM.2
FCS_COP.2 Opération cryptographique basée surdes standards
FMT_MSA.2;FDP_ITC.1 orFCS_CKM.1;FCS_CKM.7
FMT_MSA.2;FCS_CKM.2;FCS_CKM.7
FDP_ACC.2 Contrôle d’accès total FDP_ACF.1 FDP_ACF.1
FDP_ACF.1 Contrôle d’accès basé sur les attributsde sécurité.
FDP_ACC.1;FMT_MSA.3
FDP_ACC.2;FMT_MSA.3
FDP_ETC.2 Exportation des données de l’utilisa-teur avec attributs de sécurité.
FDP_ACC.1and/orFDP_IFC.1;FTP_ITC.1 orFTP_TRP.1;FPT_TDC.1
FDP_ACC.2;FTP_ITC.1 ;FPT_TDC.1
FDP_IFC.1 Contrôle de flux d’un sous-ensembled’informations. FDP_IFF.1 FDP_IFF.1
Tab. 7.6 - Dépendances des composantes d’exigences
Page 49
FDP_IFF.1 Attributs de sécurité simples.FDP_IFC.1;FMT_MSA.3
FDP_IFC.1;FMT_MSA.3
FDP_ITC.2 Importation de données de l’utilisateuravec attributs de sécurité.
FDP_ACC.1and/orFDP_IFC.1;FTP_ITC.1 orFTP_TRP.1;FPT_TDC.1.
FDP_ACC.2;FDP_IFC.1;FTP_ITC.1;FPT_TDC.1
FDP_SDI.2 Contrôle de l’intégrité des donnéesstockées et mesures conséquentes. --- ---
FDP_UCT.1 Confidentialité élémentaire del’échange de données
FTP_ITC.1 orFTP_TRP.1;FDP_ACC.1and/orFDP_IFC.1;
FTP_ITC.1FDP_ACC.2andFDP_IFC.1;
FDP_UIT.1 Intégrité de l’échange de données
FTP_ITC.1 orFTP_TRP.1;FDP_ACC.1and/orFDP_IFC.1;
FTP_ITC.1FDP_ACC.2andFDP_IFC.1
FIA_AFL.1 Action élémentaire en cas d’échecd’authentification de l’utilisateur FIA_UAU.1 FIA_UAU.1
FIA_SOS.1 Vérification des secrets -- --
FIA_SOS.2 Génération des secrets par la TSF ---
FIA_UID.2 Identification de l’utilisateur avant ac-tion ---- ---
FIA_UAU.1 Temporisation de l’authentification FIA_UID.1 FIA_UID.2
FIA_UAU.5 Mécanismes multiples d’authentifica-tion. ---
FIA_UAU.6 Ré-authentification ---
Composantes Noms DépendancesCC Satisfactions
Tab. 7.6 - (Suite) - Dépendances des composantes d’exigences
Page 50
FMT_MSA.1 Gestion des attributs de sécuritéFDP_ACC.1or FDP_IFC.1;FMT_SMR.1
FDP_ACC.2;FDP_IFC.1;FMT_SMR.1;
FMT_MSA.2 Attributs de sécurité sûrs
ADV_SPM.1;FDP_ACC.1or FDP_IFC.1;FMT_SMR.1;FMT_MSA.1
ADV_SPM.3;FDP_ACC.2;FDP_IFC.1;FMT_SMR.1;FMT_MSA.1
FMT_MSA.3 Initialisation statique des attributs desécurité
ADV_SPM.1FMT_MSA.1FMT_SMR.1
EAL retenuFMT_MSA.1FMT_SMR.1
FMT_SMR.1 Rôles de sécurité FIA_UID.1 FIA_UID.2
FPT_AMT.1 Machine abstraite de test --- ---
FPT_FLS.1 Conservation d’un état sûr lors d’unedéfaillance ADV_SPM.1 ADV_SPM.3
FPT_ITC.1 Confidentialité inter-TSF pendant unetransmission --- ---
FPT_ITI.1 Détection de modification inter-TSF --- ---
FPT_ITT.1 Protection élémentaire de données in-ternes à la TSF --- ---
FPT_ITT.3 Surveillance de l’intégrité des donnéesde la TSF FPT_ITT.1 FPT_ITT.1
FPT_PHP.3 Résistance aux attaques physiques --- ---
FPT_RCV.1 Recouvrement manuel
FPT_TST.1;FMT_SMR.1;AGD_ADM.1;ADV_SPM.1
FPT_TST.1;FMT_SMR.1;AGD_ADM.1;ADV_SPM.3
FPT_RVM.1 Non contournement de la politique desécurité ---- ---
FPT_TDC.1 Consistance élémentaire des donnéesde la TSF inter-TSF ---- ---
Composantes Noms DépendancesCC Satisfactions
Tab. 7.6 - (Suite) - Dépendances des composantes d’exigences
Page 51
FPT_TST.1 Tests de la TSF FPT_AMT.1 FPT_AMT.1
FTA_SSL.3 Fonction d’abandon de session --- ---
FTA_TSE.1 Etablissement de session de la TOE --- ---
FTP_ITC.1 Canal sûr inter-TSF --- ---
Composantes Noms DépendancesCC Satisfactions
Tab. 7.6 - (Suite) - Dépendances des composantes d’exigences
Page 52
7.6 Dépendances des composantes d’assurance
229 Pour l’évaluation de ce profil de protection, il est nécessaire de vérifier quel’ensemble des composantes d’assurance retenu (voir Tab. 5.2, 5.3) est cohérent.
230 Par définition l’ensemble des classes d’assurance (Tab. 5.2) définissant le niveauEAL 5 est cohérent. Le tableau 7.7 démontre comment les dépendances de toutesles composantes d’assurance (Tab. 5.3) retenues pour augmenter le niveau EAL5ont été satisfaites.
231 Les dépendances des composantes d’assurance retenues sont toutes satisfaites.
Composantes Noms DépendancesCC Satisfactions
ADV_INT.3 Minimisation de la complexité ADV_IMP.2ADV_LLD.1
ADV_IMP.2ADV_LLD.1
ALC_FLR.3 Réparation systématique --- ---
ATE_DPT.3 Test - Implémentation ADV_IMP.2ADV_HLD.2ADV_LLD.1ATE_FUN.1
ADV_IMP.2ADV_HLD.3ADV_LLD.1ATE_FUN.1
AVA_CCA.3 Analyse exhaustive des canaux cachés ADV_FSP.1ADV_IMP.2AGD_ADM.1AGD_USR.1
ADV_FSP.3ADV_IMP.2AGD_ADM.1AGD_USR.1
Tab. 7.7 - Dépendances des composantes d’assurance supplémentaires
Page 53
Annexe A
Abréviations et Glossaire
A.1 Abréviations
- ASSO : Architecture de Sécurité pour les Systèmes Ouverts.
- AC : Autorité de Certification de clés publiques.
- CC : Common Criteria for Information Technology Security Evaluation.
- CSP : Politique de Sécurité de Certification. Cette politique précise lagestion des certificats de clés gérés par les autorités de certification. Cettepolitique est nécessaire à tout déploiement d’une infrastructure de gestionde clés et à toute utilisation à grande échelle de moyen de cryptographieasymétrique. Elle précise entre autres les conditions de génération dedistribution, d’expiration et de révocation des certificats et permet lareconnaissance de certificat entre deux infrastructures distinctes de gestionde clés.
- EAL : Evaluation Assurance Level. Un ensemble prédéfini de composantesd’assurance des CC. Le rédacteur d’un PP ou d’une ST doit choisir unensemble de composantes parmi sept prédéfinies dans les CC (EAL1 )EAL7) auxquelles il peut ajouter des composantes d’assurancesupplémentaires.
- IGC : Infrastructure de Gestion de Clés. Cette infrastructure est l’ensembledes tiers nécessaires à la gestion des clés d’authentification et de signatureet des clés de confidentialité. Les clés d’intégrité sont certifiées par lesACet les clés de confidentialité sont gérées par lesTPC.
- IT : Information Technology. Terme générique qui désigne l’ensemble destechnologies de l’information.
- PP : Protection Profile. Ensemble d’exigences de sécurité indépendantes detous choix d’implémentation pour une catégorie de TOE et qui répondentaux besoins de sécurité et d’assurance d’une communauté d’utilisateurs.Dans le cadre d’un appel d’offre, un PP contribue à la définition dans lecahier des charges du périmètre et des exigences de sécurité du marché.
- SF : Security Function. Une ou plusieurs parties d’une TOE qui relèvent del’application de la TSP.
Page 54
- SFP : Security Function Policy. Politique de sécurité appliquée à une SF.
- SoF : Strength of Function. Caractéristique des fonctions de sécurité de laTOE représentant l’effort minimum nécessaire à fournir pour mettre enéchec les mesures de sécurité de la TOE en attaquant directement sesmécanismes de sécurité. Les CC distinguent trois niveaux de force : basique,moyen ou fort.
- ST : Security Target. Il s’agit d’un ensemble d’exigences de sécurité et despécifications pris comme base pour l’évaluation d’une TOE particulière.Un profil de protection (PP) est indépendant d’une solution technique. Acontrario, la cible de sécurité (ST) est dédiée à un produit ou à un systèmeprécis. L’introduction et les chapitres 5 et 7 d’une ST sont plus précis queceux d’un PP.
- TOE : Target of Evaluation (ou cible d’évaluation).
- TPC : Tierce Partie de Confiance.
- TSF : TOE Security Functions. Ensemble constitué de toutes lescomposantes de la TOE relevant de l’application de la TSP.
- TSP : TOE Security Policy. Ensemble de règles qui régit la manière dont lesinformations et les ressources sont gérées, protégées et distribuées dans laTOE.
- TSC : TOE Scope of Control. Champ d’application du contrôle de la TOE.
A.2 Glossaire
Agrément : reconnaissance formelle que le produit ou système évalué peut protégerdes informations jusqu’à un niveau spécifié dans des conditions d’emploi définies[900].
Attributs de sécurité : informations (telles que l’identité, le niveau d’habilitation,le besoin d’en connaître, etc.) relatives à un utilisateur autorisé, permettant d’établirses droits et privilèges.
Authentification : procédure de vérification de l’identité des partiescommunicantes et de l’intégrité des messages.
Autorité de certification (AC) : tierce partie de confiance pour la génération, lasignature et la publication des certificats de clés publiques.
Autorité de sécurité (AS) : entité responsable de la définition, de l’implémentationet de la mise en oeuvre d’une politique de sécurité.
Page 55
Bi-clé : couple clé publique, clé privée (utilisées dans des algorithmes decryptographie asymétriques).
Certificat : ensemble de données identifiant un utilisateur et une clé. Ces donnéessont signées par une autorité de certification. Le certificat est défini dans larecommandation X 509 version 3 de l’ANSI.
Chiffrement : transformation cryptographique de données produisant uncryptogramme. [ISO 7498-2]
Chiffrement de bout en bout: chiffrement de données à l’intérieur ou au niveaudu système extrémité source, le déchiffrement correspondant ne se produisant qu’àl’intérieur, ou au niveau du système extrémité de destination. [ISO 7498-2]
Chiffrement de liaison : application particulière du chiffrement à chaque liasiondu système. Le chiffrement de liaison implique que les données soient du texte enclair dans les entités relais. [ISO 7498-2]
Clé de chiffrement: série de symboles commandant les opérations de chiffrementet de déchiffrement. [ISO 7498-2]
Clé de session: clé dont la validité dure le temps d’une session.
Clés publiques : clés librement publiables et nécessaires à la mise en œuvre d’unmoyen ou d’une prestation de cryptologie pour des opérations de chiffrement ou devérification de signature.
Clés privées: une clé privée est associée à une clé publique pour former un bi-clé.
Clés secrètes : clés volontairement non publiées nécessaires à la mise en œuvred’un moyen ou d’une prestation de cryptologie pour des opérations de chiffrementou de déchiffrement.
Client : entité demandant un service.
Client-Serveur: communication mettant en relation un client et un serveur.
Client SécuriséouServeur Sécurisé : client ou serveur ayant besoin des servicesde sécurité.
Condensat : chaîne de caractères produite par une fonction de hachage [ISO10118-1].
Confidentialité : propriété d’une information qui n’est ni disponible, ni divulguéeaux personnes, entités ou processus non autorisés. [ISO 7498-2]
Confidentiel Défense : cette mention est réservée aux informations qui neprésentent pas en elles-mêmes un caractère secret mais dont la connaissance, la
Page 56
réunion ou l’exploitation peuvent conduire à la divulgation d’un secret intéressantla Défense nationale et la sûreté de l’Etat. [Article 5 du décret n˚ 81-514 du 12 mai1981 relatif à l’organisation de la protection des secrets et des informationsconcernant la Défense Nationale et la sûreté de l’Etat].
Contexte de sécurité: ensemble des éléments nécessaires pour assurer les servicesde sécurité.
Cryptogramme: données obtenues par l'utilisation du chiffrement. Le contenusémantique des données résultantes n'est pas compréhensible. [ISO 7498-2]
Cryptographie: discipline incluant les principes, moyens et méthodes detransformation des données, dans le but de cacher leur contenu, d’empêcher queleur contenu ne passe inaperçu et/ou d’empêcher leur utilisation non autorisée.[ISO7498-2]
Déchiffrement: opération inverse d'un chiffrement réversible. [ISO 7498-2]
Distribution : délivrance par une autorité de distribution aux partiescommunicantes des clés à mettre en œuvre pour chiffrer ou déchiffrer desinformations, y compris, le cas échéant, des éléments propres à d’autres abonnés.
Domaine: ensemble des ressources et entités sur lesquelles s'applique une mêmepolitique de sécurité, cet ensemble étant administré par une autorité unique.
Donnée : représentation d’une information sous une forme conventionnelle,destinée à faciliter son traitement [900], [FEROS].
Entité : individu utilisateur, processus ou serveur sécurisé.
Entité sujet: élément du modèle fonctionnel d'un service de sécurité qui désignel'acteur ou le bénéficiaire principal de ce service (par exemple un individu vis-à-visdu service d'authentification ou de contrôle d'accès).
Entité objet: élément du modèle fonctionnel d'un service de sécurité qui désignela cible ou le bénéficiaire de ce service (par exemple une ressource ou uneinformation vis-à-vis du service de contrôle d'accès).
Entité fonctionnelle: élément du modèle fonctionnel d'un service de sécurité quidésigne une entité considérée du point de vue de son comportement,indépendamment de sa réalité physique ou technique.
Evaluation : estimation de la sécurité d’un produit ou d’un système par rapport àdes critères d’évaluation définis [900].
Fonction de hachage: fonction qui transforme une chaîne de caractères en unechaîne de caractères de taille inférieure et fixe. Cette fonction satisfait deuxpropriétés. Il est difficile pour une image de la fonction de calculer l’antécédent
Page 57
associé. Il est difficile pour un antécedent de la fonction de calculer un antécédentdifférent ayant la même image.
Fonction de service: action attendue d’un produit (ou réalisée par lui) pourrépondre à un élément du besoin d’un utilisateur donné (source NF X 50-150). Leterme utilisateur désigne ici des personnes ou des entités fonctionnelles du système.
Homologation : autorisation d’utiliser, dans un but précis ou dans des conditionsprévues, un produit ou un système. C’est l’autorité responsable de la mise en oeuvredu produit ou du système qui délivre cette autorisation, conformément à laréglementation en vigueur [900].
Identification : procédé permettant de reconnaître un utilisateur de manière sûrepar la récupération de données qui lui sont propres.
Information : élément de connaissance susceptible d’être représenté à l’aide deconventions pour être conservé, traité ou communiqué [FEROS]. Renseignementou élement de connaissance susceptible d’être représenté sous une forme adaptée àune communication, un enregistrement ou un traitement [900]
Intégrité : propriété assurant que des données n’ont pas été modifiées ou détruitesde façon non autorisée. [ISO 7498-2]
Mécanisme de sécurité: logique ou algorithme qui implémente par matériel oulogiciel une fonction particulière dédiée à la sécurité ou contribuant à la sécurité.[ITSEC]
Politique de sécurité: ensemble des critères permettant de fournir des services desécurité. [ISO 7498-2]
Politique de sécurité technique: ensemble des lois, règles et pratiques quirégissent le traitement des informations sensibles et l’utilisation des ressources parle matériel et le logiciel d’un système d’information ou d’un produit. [ITSEC]
Répudiation : fait de nier avoir participé à des échanges, totalement ou en partie.
Révocation : annonce qu’une clé privée a perdu son intégrité. Le certificat de la clépublique correspondante ne doit plus être utilisé.
Service: regroupement cohérent de fonctions de service visant à répondre à unélément du besoin d’un utilisateur ou d’entités fonctionnelles du système. Saufprécision contraire, dans le présent document, le terme service désigne unregroupement de fonctions de sécurité ou de fonctions assurant le support de celles-ci.
Session: une session représente l’intervalle de temps entre le début d’un échange oud’une communication et sa fin.
Page 58
Signature numérique: données ajoutées à une unité de données, ou transformationcryptographique d'une unité de données, permettant à un destinataire de prouver lasource et l'intégrité cette unité en la protégeant contre la contrefaçon (par ledestinataire par exemple). [ISO 7498-2].
Système d’information : tout moyen dont le fonctionnement fait appel àl’électricité et qui est destiné à élaborer, traiter, stocker, acheminer, présenter oudétruire l’information. [900]
Système ouvert: système dont chacun des composants est indépendant de toutconstructeur. Système non-propriétaire. Système comprenant des interfaces decommunication normalisées entre ses composantes.
Système de chiffrement à clé symétrique (dit à clé secrète) : tout système danslequel les opérations de chiffrement et de déchiffrement font appel à la même clé,la clé devant rester secrète.
Système de chiffrement à clé asymétrique (dit à clés publiques) : tout systèmedans lequel les opérations de chiffrement et de déchiffrement font appel à une clédifférente. Contrairement à la clé de déchiffrement (dite clé privée) qui doit restersecrète, la clé de chiffrement (dite clé publique) est publiée. La clé de chiffrementet la clé de déchiffrement forment un couple (dit couple de clés asymétriques ou bi-clés) dont les éléments sont mathématiquement dépendants.
Tierce partie de confiance (TPC) : organisme habilité à gérer des conventionssecrètes pour le compte d’autrui.
Zonage : le principe du zonage Tempest est de délimiter, à l’intérieur d’un domainecontrôlé, une ou plusieurs zones qui présentent, pour la propagation d’un signalrayonné, des niveaux d’affaiblissement dont les valeurs se situent dans une plagedonnée [495].
Page 59
Annexe B
Bibliographie
B.1 Document relatif aux messageries sécurisés
[Ad-hoc] Messagerie électronique pour l’administration française, version 12/11/97.Document rédigé par le groupe de travail Messagerie de la sous commission n˚1 dela CISSI.
B.2 Documents relatifs aux critères communs
[CC v2] Common Criteria for Information Technology Security Evaluation, Version 2.0,Draft.
[TTP_PP] Profil de Protection pour les tierces parties de confiance, TTP_PP, version 0.13,dated 9/10/97.
B.3 Documents relatifs à la réglementation française
[495] Directive de zonage Tempest - Protection contre les signaux compromettants, N˚495 SGDN/ DISSI / SCSSI . Ce document est classifié Diffusion Restreinte.
[500] Instruction interministerielle relative au chiffre dans la sécurité des systèmesd’information, N˚500 bis / SGDN/ TTS / SSI / DR. Ce document est classifiéDiffusion Restreinte.
[600] Protection des informations sensibles ne relevant pas du secret de défense, N˚600DISSI/SCSSI, Mars 1993. Ce document est classifié Diffusion Restreinte.
[901] Recommandation pour la protection des systèmes d’information traitant desinformation sensibles non classifiées de défense. N˚901/DISSI/SCSSI. Cedocument est classifié Diffusion Restreinte.
[900] Instruction générale interministérielle sur la sécurité des systèmes d’informationqui font l’objet d’une classification de défense pour eux-mêmes ou pour lesinformations traitées. N˚900/DISSI/SCSSI/DR. Ce document est classifiéDiffusion Restreinte.
[EBIOS] Expression des Besoins et Identification des Objectifs de Sécurité, GuideTechnique SGDN/SCSSI, version 1.02.