PROFIL DE PROTECTION OUTILS DE SECURISATION DES … · d’évaluation est soumise à des menaces...

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

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.

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.

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

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.

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

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

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.

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)

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.

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

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.

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é

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é

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é

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

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

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.

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

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

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

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.

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.

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

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

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

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

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 :

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.

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

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.

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.

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.

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é

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é

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

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

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

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é

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.

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.

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

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

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.

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

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


Tab. 7.6 - (Suite) - Dépendances des composantes d’exigences

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



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



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.


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

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.

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

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

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

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.

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

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.

PROFIL DE PROTECTION OUTILS DE SECURISATION DES … · d’évaluation est soumise à des menaces...

Documents

Transcript of PROFIL DE PROTECTION OUTILS DE SECURISATION DES … · d’évaluation est soumise à des menaces...