CIBLE DE SECURITE CRITERES COMMUNS NIVEAU EAL3+ VERSION 1.8 Réf. : PX185856r8 PRIMX-Zed! Q.2020 Ciblede sécurité (PX185856r8).docx 2 Reproduction et droits Copyright © Prim'X Technologies 2003 - 2020. Toutereproduction, mêmepartielle, du document est interditesans autorisation écritepréalabledela sociétéPrim'X Technologies ou de l'un deses représentants légaux. Toutedemandede publication, dequelquenaturequece soit, devra être accompagnée d'un exemplairede la publication envisagée. Prim'X Technologies seréserveledroit de refuser touteproposition sans devoir justifier sa décision. Tous droits réservés. L'utilisation du logiciel Zed ! est soumiseaux termes et conditions del'accord delicenceconclu avec l'utilisateur ou son représentantlégal. Siège : 18 ruedu Général Mouton-Duvernet 69003 LYON –support@primx.eu Direction commerciale : 117 avenueVictor Hugo 92100BOULOGNE – Tél. : +33 (0)1 77 72 64 80 –business@primx.eu www.primx.eu PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 3 Sommaire Reproduction et droits .....................................................................................................2 Sommaire ......................................................................................................................... 3 Liste des figures................................................................................................................ 5 Liste des tableaux............................................................................................................. 6 1. Introduction de la cible de sécurité.............................................................................. 7 1.1. Identification de la cible desécurité..........................................................................................................7 1.2. Vue d'ensemble de la cible d’évaluation...................................................................................................7 1.3. Conformité aux Critères Communs ...........................................................................................................7 1.4. Conformité aux référentiels del’ANSSI.....................................................................................................8 2. Description de la cible d'évaluation (TOE) ...................................................................9 2.1. Présentation de la TOE...............................................................................................................................9 2.1.1. Description Générale................................................................................................................................9 2.1.2. La technologie deZed!...........................................................................................................................10 2.1.3. Les conteneurs et les accès....................................................................................................................10 2.2. Services d’utilisation et rôles ...................................................................................................................10 2.2.1. Définition des rôles.................................................................................................................................10 2.2.2. Services d’administration et d’utilisation d’un conteneur..................................................................11 2.2.3. Exemple d’utilisation de Zed!................................................................................................................12 2.3. Périmètre et architecture dela cibled’évaluation.................................................................................13 2.3.1. Les composants de Zed! Edition Standard............................................................................................13 2.3.2. Les composants de Zed! Edition Limitée..............................................................................................14 2.3.3. Périmètre de la TOE...............................................................................................................................15 3. Définition du problème de sécurité ........................................................................... 19 3.1. Les biens sensibles....................................................................................................................................19 3.1.1. Biens sensibles de l’utilisateur ...............................................................................................................19 3.1.2. Biens sensibles dela TOE.......................................................................................................................20 3.2. Hypothèses................................................................................................................................................22 3.3. Menaces [contre les biens sensibles de la TOE] .....................................................................................23 3.4. Politiques de sécurité organisationnelles................................................................................................25 4. Objectifs de sécurité...................................................................................................27 4.1. Objectifs desécuritépour la TOE.............................................................................................................27 4.1.1. Contrôle d’accès......................................................................................................................................27 4.1.2. Cryptographie.........................................................................................................................................27 4.1.3. Gestion des conteneurs .........................................................................................................................27 4.1.4. Protections lors de l’exécution..............................................................................................................28 4.2. Objectifs desécuritépour l’environnement...........................................................................................28 4.2.1. Pendant l’utilisation...............................................................................................................................28 4.2.2. Formation des utilisateurs et des administrateurs..............................................................................28 4.2.3. Administration........................................................................................................................................29 5. Exigences de sécurité des TI....................................................................................... 30 5.1. Exigences de sécurité de la TOE...............................................................................................................30 5.1.1. Exigences fonctionnelles de sécurité de la TOE....................................................................................30 5.1.2. Exigences d’assurance de sécurité de la TOE .......................................................................................36 PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 4 6. Spécifications globales de la TOE............................................................................... 37 7. Annonces de conformité à un PP ............................................................................... 38 8. Argumentaire.............................................................................................................. 39 8.1. Argumentairepour les objectifs de sécurité...........................................................................................39 8.1.1. Hypothèses..............................................................................................................................................39 8.1.2. Menaces..................................................................................................................................................42 8.1.3. Politiques de sécurité de l’organisation................................................................................................46 8.1.4. Synthèsesur la couverturedes objectifs..............................................................................................50 8.2. Argumentairepour les exigences desécurité.........................................................................................51 8.2.1. Dépendances entre exigences fonctionnelles desécurité..................................................................51 8.2.2. Dépendances entre exigences d’assurance de sécurité......................................................................52 8.2.3. Argumentaire pour les dépendances non satisfaites..........................................................................52 8.2.4. Argumentairede couverture des objectifs desécurité par les exigences fonctionnelles................53 8.2.5. Pertinence du niveau d’assurance........................................................................................................56 8.3. Argumentairepour les spécifications globales de la TOE......................................................................58 8.4. Argumentairepour les annonces de conformité à un PP......................................................................63 9. Annexe A : Exigences fonctionnelles de sécurité de la TOE....................................... 64 9.1. Class FCS : Cryptographic support ...........................................................................................................65 9.2. Class FDP : User data protection..............................................................................................................66 9.3. Class FIA : Identification and authentication ..........................................................................................67 9.4. Class FMT : Security management...........................................................................................................67 9.5. Class FPT: Protection of the TSF...............................................................................................................69 10. Annexe B : Définition de composants étendus........................................................ 70 10.1. Watermark integrity (FDP_SDI_WAT_EXT)...........................................................................................70 PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 5 Liste des figures Figure1 – Architecture de Zed! Edition Standard.................................................................................................................. 14 Figure2 – Architecture de Zed! Edition Limitée .................................................................................................................... 15 Figure3 – Plate-formede tests n°1 ........................................................................................................................................ 17 Figure4 – Plate-formede tests n°2 ........................................................................................................................................ 18 PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 6 Liste des tableaux Tableau 1 : Synthèse des biens sensibles............................................................................................................................... 21 Tableau 2 Association biens sensibles vers menaces ........................................................................................................... 25 Tableau 3 : Exigences fonctionnelles de sécurité pour la TOE.............................................................................................. 30 Tableau 4 : Composants d'assurance de sécurité.................................................................................................................. 36 Tableau 5 : Couverture des hypothèses par les objectifs de sécurité.................................................................................. 39 Tableau 6 : Couverture des menaces par les objectifs desécurité ...................................................................................... 42 Tableau 7 : Couverture des politiques desécurité del’organisation par les objectifs desécurité.................................... 46 Tableau 8 : Couverturedes objectifs desécuritépar les hypothèses, menaces et politiques desécuritédel’organisation ........................................................................................................................................................................................... 50 Tableau 9 : Satisfaction des dépendances entre exigences fonctionnelles de sécurité..................................................... 51 Tableau 10 : Satisfaction des dépendances entre exigences d’assurance de sécurité ...................................................... 52 Tableau 11 : Couverturedes objectifs de sécurité par les exigences fonctionnelles de sécurité ...................................... 53 Tableau 12 : Couverturedes exigences fonctionnelles par les spécifications globales de la TOE ..................................... 58 Tableau 13 : Exigences fonctionnelles desécuritépour la TOE............................................................................................ 64 PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 7 INTRODUCTION DE LA CIBLE DE SECURITE 1.1. Identification de la cible de sécurité Cible de sécurité : Zed! Ciblede sécuritéCC niveau EAL3+ Version dela ST : PX185856 v1r8 –Octobre 2020 Cibled’évaluation (TOE) : - Zed! Q.2020.1 Edition Standard - Zed! Q.2020.1 Edition Limitée pour les plateformes sous MicrosoftWindows10 (64 bits). Niveau EAL : EAL3 augmentédes composants ALC_FLR.3 et AVA_VAN.3 associéà uneexpertisede l’implémentation de la cryptographiedécritedans [QUALIF_STD]. Conformitéà un PP existant : Aucune. Référence des CC : Critères Communs version3.1 Révision 5, Parties 1 à 3 – Avril 2017 1.2. Vue d'ensemble de la cible d’évaluation Zed! est un produit de sécurité logiciel permettant defabriquer des conteneurs defichiers chiffrés et compressés destinés soit à êtrearchivés soit à être échangés avec des correspondants, en pièces jointes demessages électroniques ou sur des supports variés, commedes clés mémoires USB. Zed! sera évalué pour uneplateformesous lesystème d’exploitation MicrosoftWindows10 (64 bits). 1.3. Conformité aux Critères Communs Cettecible de sécuritérespecteles exigences des Critères Communs version 3.1 deseptembre2012 : [CC1] Common Criteria for Information TechnologySecurityEvaluation, Part 1: Introductionand general model. Version 3.1, Révision 5, Avril 2017. CCMB-2017-04-001. [CC2] Common Criteria for Information TechnologySecurityEvaluation, Part 2: Securityfunctional requirements. Version 3.1, Révision 5, Avril2017. CCMB-2017-04-002. [CC3] Common Criteria for Information TechnologySecurityEvaluation, Part 3: SecurityAssurance Requirements. Version 3.1, Révision 5, Avril 2017. CCMB-2017-04-003. [CEM] Common Methodology for Information TechnologySecurity Evaluation, Evaluation Methodology. Version 3.1, Révision 5, Avril 2017. CCMB-2017-04-004. Tous les composants fonctionnels décrits danscettecibledesécuritésont issus dela Partie2 « étendue » des Critères Communs version 3.1d’avril 2017. Leniveau d’assurance« EAL3 augmenté » retenu est conformeà la Partie3 « stricte » des Critères Communs version 3.1 révision 5 d’avril2017. Leniveau d’assuranceest un niveau EAL3 augmentédes composants ALC_FLR.3 et AVA_VAN.3. Toutes les interprétations des Critères Communsparues à la datede démarragedel’évaluation seront retenues. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 8 1.4. Conformité aux référentiels de l’ANSSI Cettecible de sécuritéest conformeaux référentiels de l’ANSSI suivants : [QUALIF_STD] Processus dequalification d’un produit – version 1.0 du 12 janvier 2017, ANSSI. [CRYPTO_STD] RGS version 2.0 –Annexe B1. Mécanismes cryptographiques : Règles et recommandationsconcernant lechoix et le dimensionnementdes mécanismes cryptographiques - Version 2.03du 21 février 2014, ANSSI. [CLES_STD] RGS version 2.0 –Annexe B2. Gestion des clés cryptographiques : Règles et recommandationsconcernant la gestion des clés utilisées dans les mécanismes cryptographiques - version 2.0 du 8 juin 2012, ANSSI [AUTH_STD] RGS version 1.0 –Annexe B3. Authentification : Règles et recommandationsconcernant les mécanismes d’authentification - Version 1.0 du 13 janvier 2010, ANSSI. [MOTS_DE_PASSE_STD] Recommandations desécurité relatives aux mots depasse Version 1.1 du 5 juin 2012, ANSSI PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 9 DESCRIPTION DE LA CIBLE D'EVALUATION (TOE) 2.1. Présentation de la TOE 2.1.1. Description Générale L’email est l’outil le plus utilisépar les entreprises pour communiquer en interneou avec leurs partenaires et prestataires. Cettecommunication au quotidien engendreun échangededocuments sensibles quasi systématique. Mais, la plupart des documents échangés sont simplementjointsaux emails, negarantissant aucuneconfidentialité aux données transmises. Zed! est un produit de sécurité pour postes detravail opérant sousWindows, Linux et Mac (seulela version sous Windows sera évaluée). Zed! se présentecommeun produit autonomequi est également intégrédans leproduit ZoneCentral dePrim’X. Son rôleest de permettreaux utilisateurs defabriquer des conteneurs de fichiers compressés et chiffrés. Le produit intègrepar ailleurs un mécanismede contrôle de l’intégrité des fichiers stockés dans les conteneurs. Ces conteneurs sont destinés à servir d'archive, ou, plus généralement, depièce-jointechiffréedans des courriers électroniques échangés dans unesociété. L'ergonomieest similaireaux fichiers «ZIP» standards sousWindows. L'utilisateur peut déposer des fichiers, les renommer, les supprimer, les extraire, etc. Zed! n’a aucunelimitedetaille defichier et ne modifiepas l’arborescence des fichiers ou des dossiers qu’il copie. Le conteneur permet degérer un stockagechiffrédes fichiers, sans modifier leurs caractéristiques (nom, dates, tailles) et defaçon la plus transparentepossiblepour les utilisateurs. Lechiffrement/déchiffrement des fichiers s'effectueen effet lorsqueles fichiers sont lu/copiés dans leconteneur et 'à la volée' (sans manipulation particulièrede l'utilisateur). Après avoir fabriquéun conteneur, l'utilisateur peut ajouter des accès pour ses correspondants. Un accès correspond à une clé d'accès (uneclé cryptographique) quepossèdeun utilisateur. Cetteclépeut êtresoit uneclé dérivée d’un mot depasse"d'échange" convenus avec un correspondant (dans cecas les utilisateurs nepossèdent pas la clé d’accès elle-mêmemais lemot depassepermettant à Zed! dela calculer), soit uneclé RSA hébergée dans un porte- clés commeun fichier declé (certificat RSA pris dans un fichier certificat ou recherchésur un annuaireLDAP de certificats), unecarte à mémoire, un container CSP ou CNG Microsoft Windows (leporte-clés pouvantlui-mêmeêtre protégépar un codeconfidentiel). Une clé d'accès permet deretrouver (en les déchiffrant) les informations de chiffrement des fichiers du conteneur. Zed! intègrepar ailleurs unefonction très pratique, le‘Carnet de Mots de Passe’ qui permet de mémoriser et réutiliser les différents motsdepassedes correspondants. Enfin Zed! offrela possibilitédemasquer les noms defichier apparaissantdans leconteneur : leconteneur apparait videtant qu’uneclé d’accès validen’a pas été renseignée. Zed! se déclineen différents packages :  L'édition standard, qui contient le produit complet ;  L'édition limitée (appelé «Zed! Edition Limitée»), gratuite, libre de distribution et d'usage, qui permet aux correspondants de lire le contenu des conteneurs (moyennant la fournitured'une clé d'accès) et d'en extraire les fichiers. Le correspondant a également le droit de modifier le contenu du conteneur (enlever, ajouter des fichiers) pour pouvoir lerenvoyer à l'émetteur d'origine. L'édition limitéenelui permet pas, cependant, decréer denouveauxconteneursou d'enmodifierles accès prévusparle créateuroriginaldu conteneur.L'éditionlimitée seprésentesous la formed’un simpleexécutable(zedle.exe), facileà transporter, et qui évited'avoir à effectuer une installation;  Enfin, Zed! est également incorporé dans les différents produits de la gamme ZoneCentral. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 10 2.1.2. La technologie de Zed! Le format internedu conteneur permet decontenir des fichiers de toutes tailles, indépendammentles uns des autres, et il gère en internele nommagedeces fichiers. Le conteneur peut être considérécommeun "dossier virtuel" contenant des fichiers confidentiels. Leconteneur gèreégalement en interneun fichier de contrôlequi permet de gérer les accès et qui est masqué. 2.1.3. Les conteneurs et les accès Chaqueconteneur est défini par certaines caractéristiques dechiffrement (dont font partieles clés dechiffrement des fichiers, les algorithmes, etc.) et par unelisted’accès utilisateurs. La définition des accès est libre, mais leproduit est dotéde fonctions et demécanismes d'administration permettantd'imposer certainsaccès ou certains types d'accès. Pour pouvoir utiliser un conteneur, un utilisateur doit donc disposer d’unecléd’accès. Dans le cas de Zed! Edition Standard, cetteclé d’accès lui a été remisepar l’Administrateur dela Sécurité. Il peut s’agir d'uneclé RSA hébergée dans un porte-clés commeun fichier de clés, une carteà puce, un container Microsoft CSP ou CNG (leporte-clés intégrant la plupart du temps son propredispositif d'authentificationavec un codeconfidentiel). Lemot de passeest le plus souvent choisi par l’utilisateur en fonction dela politiquedesécuritémiseen œuvre. Unefois l’utilisateur authentifié, la cléd'accès ainsi fournierestevalidetant qu'ellen'a pas été explicitement fermée par l'utilisateur (verrouillagedans l’édition standard, fermeturedu conteneur dans la version limitée, fermeturedela session ou arrêt du systèmepar exemple). Lorsquele conteneur a été fabriqué, les fichiers protégés par leconteneur ont été chiffrés avec des clés elles-mêmes chiffrées avec les clés d’accès des utilisateurs. Bien entendu, les clés d’accès elles-mêmes nefigurent pas dans le conteneur. Zed! proposedifférents algorithmes et mécanismes desécurité, tous conformesaux standardsen la matière. Il proposedeux schémas degestion declés d'accès qui peuvent êtreutilisés en mêmetemps. Un schéma dit « symétrique » basésur des mots depasseet des clés dérivées demots depasse(réf. : PKCS#5) et un schéma dit « asymétrique » utilisant des clés RSA (réf. : PKCS#1) embarquées dans des fichiers declés (réf. : PKCS#12) ou des porte-clés (ref: PKCS#11 et/ou CSP/CNG). 2.2. Services d’utilisation et rôles 2.2.1. Définition des rôles Hormis le responsabledela sécuritédel’organisation qui fixela politiquegénéralede sécuritéà appliquer, on distingue4 rôles mettant en œuvre(directement ou indirectement) les fonctionnalitésdela TOE :  Un rôle opérant uniquement dans l’environnement de la TOE (ce rôle ne concerne pas Zed! Edition Limitée1 ) : L’administrateur de la sécurité de l’environnement Windows des utilisateurs (appelé administrateur Windows dans la suite du document) en charge de définir les règles d’usage et de sécurité (les policies), c’est-à-dire le paramétragede fonctionnement du produit : cette opération de « haut-niveau » est effectuée sous le contrôlede l’administrateur dela sécuritédela TOE qui a étudiéles différents paramètres et décidédes valeurs à affecter pour obtenir lecomportement souhaitédu produit danslecadred’utilisationet d’environnementprévu. Les policiessont signées par l’administrateurdela sécuritéde la TOE et vérifiées par Zed! avant leur application. Le mécanismede signature de politiques permet de garantir que seules des politiques validées par l’administrateur puissent être appliquées sur les postes de travail. Un administrateur dedomaine, autorisépourtant à modifier les politiques du domaine, nepourra pas intervenir sur la configuration du produit : s’il modifieles politiques, la signaturedeviendra invalide et donc les nouvelles politiques seront refusées sur les postes de travail. Les règles une fois affectées ne 1 Dans la mesure où l’édition limitée ne permet pas d’effectuer d’opération de gestion. Par contre les conteneurs transmis aux possesseurs de l’édition limitée ont été paramétrés par ces rôles. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 11 changeront ensuite que de façon très exceptionnelle. Il est à noter que ce rôle peut se décliner en plusieurs rôles hiérarchiques correspondant aux différents niveaux des domaines Windows. Dans ce cas les administrateurs Windows des niveaux supérieurs doivent interdireaux administrateurs des sous-niveaux (domaines, contrôleurs de domaines, postes de travail) la modification des « policies » de la TOE qu’ils souhaitent eux-mêmes contrôler.  Un rôle administrateur de la sécurité (cerôle ne concerne pas Zed! Edition Limitée1) en charge de l’installation de la TOE, dela signaturedes politiques, des opérationsderecouvrement(et desecours) et dela miseà dispositiondes clés d’accès et éventuellement des mots depasse. L’administrateur dela sécuritépossèdeégalementles droits pour gérer les accès.  Un rôle administrateur des accès (ce rôle ne concerne pas Zed! Edition Limitée, voir note page précédente) en chargedela gestion des accès, à savoir l’affectation du premier accès lorsdel’initialisation duconteneur (en fait son propre accès) et la création des accès des autres ayant droits. L’administrateur des accès peut déléguer cette fonction à un autre utilisateur en modifiant le rôle de l’accès.  Un rôle utilisateur qui utilisela TOE selon la configuration imposéepar les administrateurs (il s’agit en général du correspondant lorsque les Zed! sont échangés). Il faut noter que, à part la définition des policies, généralement dévolueà un responsabledela sécurité, les autres opérations peuvent êtreeffectuées par différents acteurs en fonction dela confiance, de l’organisation et des moyens de l’entreprise. 2.2.2. Services d’administration et d’utilisation d’un conteneur Il n'y a pas d'opération d'administration sur un conteneur autresqueles gestions d'accès et la signaturedes politiques en amont. Un conteneur "vit" tant qu'il existe(fichier conteneur non supprimé). Les opérations d’administration possibles sont (édition standard uniquement):  Lecture ou modification des policies (administrateur Windows), signature des policies par l’administrateur de sécurité. Attention par défaut les politiquesnesont pas signées, l’opération préalabledesignaturedes politiques et leur intégration dans le package d’installation sont nécessaires pour bénéficier de la fonction de contrôle de signature des politiques.  L’initialisation du conteneur à la premièretentatived’accès par l’administrateur des accès (correspond à la création du premier accès et à l’ajout des accès de recouvrement configurés dans les politiques).  L’ajout ou la modification d’un accès utilisateur par l’administrateur des accès (l’ajout et la modification impliquent que la clé d'accès du destinataire soit fournie, mot de passe ou clé publique).  La modification du rôle d’un accès par l’administrateur des accès.  Le recouvrement par l’administrateur de sécurité.  Le secoursutilisateur(dépannageàdistanceen cas d’oublidumotde passeou pertedela carteà puce par exemple) par l’administrateur de sécurité (hors périmètre de la cible de sécurité). Note : La visualisation des accès du conteneur nenécessitepas derôle administrateurdes accès et est disponibledans l’édition limitéepour l’utilisateur autorisé. Les opérations d’utilisation possibles sont:  La création d'un nouveau conteneur via lemenu « Nouveau » puis « Conteneur Chiffré » del’explorateur Windows (par l’administrateur des accès avec l’édition standard). Cette opération ne requiert aucune clé d’accès, elle créé simplement un conteneur videet sans accès qui estinutilisabletant qu’il n’a pas étéinitialisé. Par ailleursla fonction n’est pas mise à disposition dans Zed! Edition Limitée.  Le renommageou la suppression d'un conteneur par l’utilisateur (concerne l’environnement Windows et donc ne nécessite pas de clé d’accès).  L'ajout de fichiers au conteneur par l’utilisateur autorisé(copier/déplacer, insérer, copier/coller, etc.) : les fichiers sont chiffrés quand ils sont mis dans le conteneur, ce qui nécessite d'avoir fourni la clé d'accès du conteneur. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 12  La visualisationou l'extractiondefichiers d'un conteneur par l’utilisateur autorisé: toutevisualisation ou extraction de fichier nécessite la clé d'accès du conteneur pour que les fichiers soient déchiffrés du conteneur.  La suppression de fichiers du conteneur par l’utilisateur autorisé (nécessite d'avoir fourni la clé d'accès du conteneur).  La création et la suppression dedossiers dans le conteneur par l’utilisateur autorisé(nécessite d'avoir fourni la clé d'accès du conteneur). Un outil de collecte d’informations est disponible(si la politiquedesécuritélepermet) via le menu de la fenêtre "A propos de…". Cet outil permet degénérer un rapport deconfiguration chiffréà transmettre au support technique Prim’X (en pièce jointed’un courrier électroniquepar exemple). Les informations collectées et sélectionnées par l’utilisateur sont la configurationdes politiques, les applicationsinstallées, les fichiers logs. Lerapport est intégrédans un fichier sécurisébasésur la mêmetechnologiequele carnet de mot depasse(avec le support techniquecomme accès unique) pour transmission via email par exemple. L'interfaced’utilisation des conteneurs chiffrés est tout à fait similaireà l'utilisation des 'dossiers compressés' (.zip) sous Windows (glisser-déplacer, copier-coller …). 2.2.3. Exemple d’utilisation de Zed! Il existedifférents scénarios demiseen œuvre, mais leprinciped’utilisation restelemêmepour les utilisateurs. L’administrateur dela sécuritédel’environnement Windows définitles règles d’usage (policies) du produit puis l’administrateur dela sécurité les signeavec sa clé de signatureprivée, cequi se traduit par uneconfiguration prédéfinie(policy) qui peut être masterisée(personnalisation del’installation) ou télé-gérée(diffusée, miseà jour) soit par des commandes d’administrationfournies par leproduit soit par la logistiqueintégréedes réseaux bureautiques (exemple : contrôleurs dedomaines). Ces règles sont généralement établies à « haut niveau » dans l’entreprisepar le Responsabledela Sécurité. Parmi ces règles, on trouve, par exemple, l’algorithmedechiffrement à utiliser, le comportement quedoit adopter lelogiciel dans certains cas, les porte-clés PKCS#11 supportésetc. Le logiciel, masteriséou non, est ensuite installé sur un postedetravail, manuellement ou via les logiciels detélé- installation du marché. Par ailleurs, il est à la chargede l’administrateur dela sécuritéde définir (fournir) les clés d’accès des utilisateurs (issues d’unePKI, par exemple). Zed! supportedifférents scénarios degestion declés, mais n’en fournit pas l’infrastructure. Si unePKI est en place, il sait en utiliser les éléments (clés RSA, porte-clés, certificats), si elle n’est que partiellement installée, ou s’il n’y en a pas, il sait également utiliser des accès par mots depasse. Lorsqu’un utilisateur créeun nouveau conteneur avec l’édition standard, il en devient l’administrateurdes accès, affectant les accès et les rôles de ses correspondants (par défaut lerôleest simple« utilisateur »). Ensuite, seuls les utilisateurs disposantdeclés d’accès valides pour leconteneur chiffré pourront lireou écriredes fichiers dans celui-ci. A la premièretentatived’accès à un fichier chiffrédans le conteneur, Zed! demandeà l’utilisateur unecléd’accès permettant dedéchiffrer lefichier (en pratique, leschéma est plus complexe, et cetteclé d’accès permet dedéchiffrer des clés intermédiaires qui elles-mêmes chiffrent les fichiers). Si l’utilisateur peut la fournir, alors lefichier peut être déchiffré(ou chiffré, s’il s’agit d’unecréation ou d’uneécriture). Sinon, l’utilisateur se voit refuser l’accès avec le message« Accès non autorisé». L’authentification del’utilisateur auprès du conteneur resteeffective jusqu’à la miseen veilleou le verrouillagedela session Windows (édition standard seulement), la clôturede la session Windows ou l’arrêt du poste. Commepour les archives zip, pour « ouvrir » (lire) un fichier d’un conteneur, il doit d’abord être extrait. L’opération « ouvrir » automatisel’extraction(dans ledossier temp de l’utilisateur) et l’active. Quand leconteneur est refermé, le fichier est chiffré. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 13 2.3. Périmètre et architecture de la cible d’évaluation 2.3.1. Les composants de Zed! Edition Standard La figure1 présentel’architecturedu produit : lepérimètrede la TOE est délimitépar des pointillés. Les principaux composants sontlistés ci-dessous. «Interface Explorer» permet degérer les menus et la vue graphique. « ZDU » est un «daemon» utilisateur instanciépour chaquesession utilisateur Windows et qui référenceles clés utilisateur saisies via l’entréed’un mot depasse, l’interfacePKCS#11, leCSP ou leCNG. Le service« ZEP » contrôlela signaturedes politiques. «Moteur Zed», coordonneles différents traitements; Le « driver crypto » qui est le centrecryptographiquedeZed! : il gère les clés de conteneur et exécute les opérations de calcul associées. Les clés ne sortent jamais deson enceinte, sauf lorsqueleproduit est configurépour utiliser des porte-clés (commedes extensions PKCS#11 pour des cartes à puceou des CSPs/CNGs). Cetteimplémentation dela cryptographieen modekernel du systèmerenforceleniveau de protection global car c’est un emplacement très difficilement accessibleaux logiciels ‘pirates’. Le « driver clavier » qui est un filtre desaisieclavier : il intercepteà très bas niveau les mots depasseet codes confidentiels saisis defaçon à ce que leur valeur resteconfinée le plus bas possibledans lesystème. Ils sont ensuite utilisés par ledriver cryptographique, ou remis aux moteurs externes (CSP/PKCS#11). Cela neconcerneQUE les mots de passegérés par Zed!, c’est-à-direceux qui conditionneles accès aux fichiers chiffrés. Cetteimplémentation renforce également la protection deces données sensibles, qui neremontent pas au niveau applicatif du système, sourcerégulièreet préférée des logiciels ‘pirates’. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 14 Figure 1 – Architecture de Zed! Edition Standard 2.3.2. Les composants de Zed! Edition Limitée La figure2 présentel’architecturedu produit dans sa déclinaison limitée : lepérimètredela TOE est délimitépar des pointillés. Les principaux composantssontlistés ci-dessous. BROWSER émulel’Explorer Windows. «Interface Explorer» permet degérer les menus et la vue graphique. «ZCC» est lecentre cryptographiquedeZed! : il gère les clés et exécute les opérations decalcul associées. Les clés ne sortent jamais deson enceinte, sauf lorsqueleproduit est configurépour utiliser des porte-clés (commedes extensions PKCS#11 pour des cartes à puceou des CSPs). «ZCCA» référence les clés utilisateur saisies via l’entréed’un mot depasse, l’interfacePKCS#11 ou leCSP. «Moteur Zed», coordonneles différents traitements; A noter que l’édition limitéenepermet pas d’effectuer d’opération administration. Système d’exploitation Windows 10 Driver crypto ZDU Utilisateur de la Administrateur de la sécurité PKCS#11 de la CSP de la Explorer.exe (menus, vue graphique) Interface Explorer Moteur Zed Driver clavier Administrateur des accès ZEP PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 15 Figure 2 – Architecture de Zed! Edition Limitée 2.3.3. Périmètre de la TOE 2.3.3.1. Périmètre logique La TOE est constituédeZed! Edition Standard et Zed! Edition Limitée. Leproduit intégrédans ZoneCentral nefait donc pas partiedu périmètrede l’évaluation. Seule la version Q.2020.1 configurée avec les politiques desécuritéactivées suivantes est déclaréconforme :  La politique P131 (accès obligatoires) doit être configuré avec l’accès de recouvrement de l’administrateur. Note : Au moment d’effectuer lerecouvrement, les politiques P269- Ouvertureau moyen declés de recouvrement, P198 - Affichagedes accès de recouvrement et P199 - Affichagedes accès obligatoires devront êtreactivées. Ces politiques nesont normalement pas activées dans un environnement de production(notammentpour masquer les accès derecouvrement) et ne font donc pas partiedu périmètrede test del’évaluation).  La politiqueP730 (seuil d’acceptation des mots depasse) doit êtreconfiguréeà 100%et la politiqueP732(longueur des mots de passe) doit être configurée à 12. Système d’exploitation Windows 10 ZCC ZCCA Zedle.exe Utilisateur de la PKCS#11 de la CSP de la Browser Interface Explorer Moteur Zed PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 16  La politiqueP381 (mécanismedechiffrement pour les conteneurs chiffrés) doit êtreconfiguréeà « CTS » (valeur par défaut).  La politique P399 (version du format des conteneurs et messages chiffrés) doit être configurée à « Version 2 ».  La politique P383 (mode de chiffrement RSA) doit être configurée à « PKCS#1 v2.2 avec utilisation de SHA-256 ».  La politique P386 (mécanisme de signature) doit être configurée à « PKCS#1 v2.2 PSS».  La politiqueP387 (mécanismededérivation(motdepasse))doitêtre configuréeà « SHA256-PBKDF2»ou« SHA512- PBKDF2 ».  La politique P233 (masquage des noms de fichiers et de dossiers des conteneurs chiffrés) doit être configurée à « Toujours masquer ».  La politique P292 (algorithme de hash utilisé) doit être configurée à « SHA-256 » (valeur par défaut) Le périmètred’évaluation est constituédel’ensembledes composants du logiciel Zed! hormis :  l’outil GPOSign.exe permettant à l’administrateur desécurité de signer les politiques ainsi que la génération de la clé de signature. Par contrela vérification dela signaturedes politiques par Zed! fait bien partiedu périmètrede la TOE.  L’utilisation du modeSSO (Single Sign On) qui permet d’ouvrir automatiquement les conteneurs chiffrés lorsquela session Windows est ouverte (mais reporteleniveau de sécurité à celui de Windows ou du composant SSO tiers).  La suppression d’accès car cette opération ne renouvelant pas la clé de chiffrement du conteneur, il est préférable de créer un autre conteneur.  Le secours utilisateur distant. 2.3.3.2. Périmètre physique Zed! sera évalué, en tant queproduit, sur uneplate-formePC sous lesystème d’exploitation Windows 10(64 bits) de Microsoft. L’utilisation avec les différentes clés d’accès sera évalué(mot depasseet clé RSA). En particulier, ledialoguePKCS#11 entrela TOE et les porte-clés utilisateurs, ledialoguePKCS#12 entrela TOE et les fichiers declés seront également évalués. Les éléments suivants sont hors évaluation :  Les systèmes d’exploitation Windows ;  Les portes clés utilisés (comme les porte-clés de type Token USB, les fichiers de clés ou les containers CSP/CNG). Le logiciel Zed! utilisedes clés utilisateurs (les «clés d’accès») qui peuvent êtrefournies par l’environnement (clés RSA dans des porte-clés utilisateur). Zed ! Edition Standard est téléchargée depuis lesite Web de l’éditeur à partir d’un compte privé sur lesiteclient (client.primx.eu/Software/Download) ou lesitepartenaire(partner.primx.eu/Software/Download). Leprogramme d’installation est signépar Prim’X avec la technologieAuthenticode. La valeur dela signature peut êtrecomparé à celle indiquéepour le packageà la page « Signature » du site Web. Le programmeinstalle l’outil designaturedes politiques (hors périmètre) et tous les guides du produit au format pdf à savoir leguided’installation, leguide utilisateur, lemanuel des politiques et leguidede signaturedes politiques. Les guides sont également téléchargeables à partir du compte client ou partenaire. L’exécutable Zed ! Edition Limitéeest téléchargée en accès libre par l’utilisateur final à partir du site Web de l’éditeur (client.primx.eu/PublicSoftware/zedlimitededition). Leprogrammeest signédela mêmefaçon que l’édition standard, la paged’accueil indiqueégalement la valeur de la signature. Le guideutilisateur doit êtrefournit par l’émetteur des conteneurs qui possèdel’édition standard (sur son posteou téléchargeableà partir deson compte). PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 17 2.3.3.3. Plate-forme de tests pour l’évaluation de la TOE Pour l’évaluation du produit Zed!, les plates-formesci-dessousdevront êtremiseen placepar l’évaluateur (leterme PC désigneen fait une machinevirtuelleassociée). Letypephysiquedeporte-clés (carteà puce ou clé USB) étant transparent pour Zed! (seul ledialoguePKCS#11 est important), les testsdel’évaluateur s’effectueront avec un seul typede porte-clés. On activera les politiques desécuritéconformément au périmètrelogiquedéfini ci-dessus. La fonction decontrôledesignaturedes politiques nécessiteuneinstallation de la TOE avec un packaged’installation spécialement préparéen se référant à la documentation dela fonction. Plate-forme1 sous Windows 10 64 bitsavec l’édition standard versionQ.2020.1 en modes d’authentificationpar token USB et fichier de clés:  Un contrôleur de domaine (Windows 2019)  2 PC sous Windows 10 64 bits avec l’édition standard version Q.2020.1 Figure 3 – Plate-forme de tests n°1 Plate-forme2 sous Windows 10 64 bitsavec l’édition standard versionQ.2020.1 et l’édition limitée version Q.2020.1 en moded’authentification par CSP et mot depasse respectivement:  Un contrôleur de domaine (Windows 2019)  Un PC sous Windows 10 64bits avec l’édition standard version Q.2020.1 (création des conteneurset attributiondes accès, utilisation des conteneurs)  Un PC sous Windows 10 64 bits avec l’édition limitée version Q.2020.1 (utilisation des conteneurs) PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 18 Figure 4 – Plate-forme de tests n°2 PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 19 DÉFINITION DU PROBLÈME DE SÉCURITÉ 3.1. Les biens sensibles 3.1.1. Biens sensibles de l’utilisateur 3.1.1.1. Clés d’accès : D. AUTH_USER Pour ouvrir (lecture, remplissage, gestion des accès) les conteneurs chiffrés, Zed! met en œuvreles clés d’accès des utilisateurs. En fonction des cas defigure, il peut être amenéà manipuler directement soit lemot depasseutilisateur, soit la clé d’accès elle-même, soit lecode confidentiel deprotection dela clé d’accès.  Accès par mot de passe : Zed! gère la saisiedu mot de passe, sa transformation (dérivation) en clé d’accès puis le déchiffrement dela clé de chiffrement et déchiffrement des fichiers du conteneur par cettecléd’accès. La politique de complexité des mots de passe est configurable par les politiques de sécurité ;  Accès par clé RSA hébergée dans un fichier de clés en utilisant lemécanismePKCS#12 : Zed! gère la saisie du code confidentiel du fichier de clés, lit et déchiffre le fichier de clés avec ce code confidentiel, obtient la clé d’accès RSA et effectueledéchiffrementdela clédechiffrementetdéchiffrementdes fichiersduconteneurparcetteclé d’accès;  Accès par clé RSA hébergée dans un token logique accédé au travers d’un composant externe PKCS#11 (ce composantpouvantpiloterunecarteà mémoire,un tokenUSB outoutautredispositifhardwareousoftware) :Zed! gère la saisie du code confidentiel du token logique, le remet au composant externe pour le déverrouiller. Zed! fournitégalementau composantexternela clé dechiffrementdes fichierschiffréspar sa clépublique.Le composant déchiffre la clé de chiffrement avec sa clé privée puis la transmet à Zed! qui peut alors effectuer le déchiffrement des fichiers;  Accès par clé RSA hébergée dans un token logique accédé au travers d’un composant externe CSP ou CNG (ce composantpouvantpiloterunecarteà mémoire,un tokenUSB outoutautredispositifhardwareousoftware) :Zed! negère pasla saisiedu codeconfidentieldu tokenlogique,c’est lecomposantexternequi lefait spontanémentavec sespropresmoyens.Zed!fournitau composantexternelaclé dechiffrementdesfichiers chiffréspar saclépublique. Le composant déchiffre la clé de chiffrement avec sa clé privée puis la transmet à Zed! qui peut alors effectuer le déchiffrement des fichiers. En fonction deces cas, donc, Zed! manipulecommebiens sensibles un mot depasseou codeconfidentiel (en saisie), et uneclé d’accès cryptographique. Dans les cas 1 et 2, il manipuleles deux éléments, dans lecas 3, il ne manipuleque le premier, dans le cas 4, il n’en manipuleaucun. Il faut noter queZed! negénère PAS les clés d’accès des utilisateurs : quand il s’agit declés RSA, quel quesoit le porte- clés qui les héberge et le modulequi les traite, elles sont toujours générées par un outil externeà Zed! (en général une PKI), de mêmeque le porte-clés éventuel et le code confidentiel deprotection. Quand il s’agit demots depasse, c’est l’administrateur dela sécuritéou lepremier utilisateur (administrateur des accès) qui lechoisissent. L’utilisateur et son environnement (règles et procédures internes, établies par le Responsabledela Sécurité) sont responsables dela qualitéde ces clés, de la protection du porte-clés et de leur bonneutilisation. Plutôt quededéfinir directement les accès utilisateurs dans un conteneur, il est possible(c’est mêmele comportement par défaut) depasser par un maillon intermédiaire, la liste d'accès. Unelisted'accès regroupel’accès utilisateurs, l’accès de secours et les accès de recouvrement et leconteneur fait ensuiteréférence à cette liste. Cela permet notamment d'utiliser unemêmelisted'accès pour tousles conteneurs (unicitédegestion), et deregrouper les listes d'accès au mêmeendroit (centralisation). 3.1.1.2. Le carnet de mot de passe : D.CARNET_MOT_DE_PASSE Le carnet de mot depasseest stockédans le profil Windows del’utilisateur. Il contient l’enregistrement detous les mots depassedéfinis pour les correspondants. Les entrées peuvent êtreenregistrées lorsquel’utilisateur reçoit un conteneur d’un destinatairepour la premièrefois et qu’il renseignele mot depassequi lui a été fourni ou lorsque l’utilisateur ajouteun mot depassepour un destinataire. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 20 Toutes les entrées sont chiffrées par la clé personnellede l’utilisateur qui doit donc êtrefourniepour ouvrir et utiliser le carnet. 3.1.1.3. Bi clé de signature : D.ID_ADMIN Les politiques desécuritésont signées par l’administrateur dela sécuritéet vérifiées par Zed! avant leur application. Le bi-clé designaturedont surtout la cléprivéedel’administrateur fait donc partiedes biens sensibles decet utilisateur particulier. 3.1.1.4. Fichiers chiffrés : D.DONNEES_UTILISATEUR Zed! permet de conserver sous formechiffréeles fichiers et dossiers (possibilité également dechiffrer leurs noms). Les biens sensibles sont donc les fichiers et dossiers utilisateurs, detous types, stockésdans les conteneurs. Les fichiers ainsi chiffrés dans les conteneurs sont des biens sensibles del’utilisateur protégés par la TOE (qui doit conserver leur imagestockéechiffrée sans copieen clair) tant qu’ils demeurent dans leur conteneur. Un contrôle d’intégritéest effectué lorsquel’utilisateur ouvreun fichier du conteneur. Les conteneurs peuvent posséder uneimagede‘fond’ (watermark), par défaut un cadenas vert. Il est possiblede définir soi-mêmel’imagedefond d’un conteneur donné, et de faire en sortequecetteimagesoit « embarquée» dans le conteneur. Cetteimagefait donc partiedes données utilisateur à protéger en intégrité. 3.1.2. Biens sensibles de la TOE 3.1.2.1. Le conteneur considéré dans son ensemble : D. CONT Le conteneur et tout cequ’il contient (fichiers utilisateur, fichiers techniques, structure) formeun ensemblequi ne doit pas êtredétournépour servir devecteur d’attaqueen ajoutant des données illicites transférables sur la station du destinataire. Des mécanismes devérification d’intégritésont donc misen placeau sein des conteneurs. 3.1.2.2. La clé symétrique de chiffrement de fichiers : D.CLE_FIC Les fichiers du conteneur sont chiffrés par uneclé de chiffrement générée lors del’initialisation du conteneur. A chaquefichier est associéun vecteur d’initialisation spécifique. Ces biens sont stockés chiffrés par les accès dans le fichier de contrôledu conteneur. 3.1.2.3. Les programmes : D.PROGRAMMES Pour assurer son fonctionnement, la TOE met en œuvreses programmes (exécutables, bibliothèques dynamiques). La sécuritéen intégritédeces programmes reposesur l’environnement : il faut êtreadministrateur Windows pour les modifier. Ces programmes sont également signés(systèmeauthenticodeWindows). 3.1.2.4. La configuration : D.CONFIGURATION Pour assurer son fonctionnement, la TOE met en œuvredes policies (au sens Windows du terme). La sécuritéen intégritédeces policies est assurée :  Par l’environnement (i.e. lesystèmedes policies sous Windows) : il faut êtrel’administrateur Windows deplus haut niveau pour les modifier (si un domaine Windows définit une valeur pour un paramètre, alors un administrateur local au poste ne pourra pas la modifier).  Par le produit dans la mesureoù les politiques sont signées par l’administrateur dela sécuritéet vérifiées par Zed! avant d’être appliquées. 3.1.2.5. Le fichier de contrôle : D.FICHIER_CONTROLE Ce fichier contient le libellédu conteneur, un identifiant unique, quelques informationsdegestion, et les ‘wrappings’ d’accès, c’est-à-direles clés de chiffrement du conteneur chiffrées par les clés d’accès des utilisateurs habilités. Un contrôled’intégritéest effectuésur ce fichier de contrôle. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 21 3.1.2.6. Le fichier catalogue : D.FICHIER_CATALOGUE Ce fichier contient la listedes fichiers applicatifs du conteneur, avec leur position dans l’arborescence, les tailles originales, les horodatages, etc. Un contrôled’intégritéest effectuésur ce fichier catalogue. 3.1.2.7. Synthèse des biens sensibles Le tableau ci-dessous résumela listedes biens sensibles protégés par Zed! et indiquela naturedela sensibilité associée. Les qualificatifs « forte » et « faible » de la sensibilitéfont référenceau degré de protection vis-à-vis du potentiel d’attaquevisédans la cible(chapitre3.3). Unesensibilitéforteimposeun niveau deprotection résistantà l’attaquecorrespondantepour leniveau visé(divulgationdu bien, atteinteà l’intégriténon détectée), une sensibilité faible indiquequele bien n’a pas à être protégéau degré visé. Par exemple la divulgation des politiques apportepeu d’information intéressanteà un éventuel attaquant (configuration généraledu produit) maisla modification des politiques doit êtrecontrôléesous peined’atteinteà la sécuritédu produit (ajout d’un accès de recouvrement par exemple). Remarque : de façon générale, l’intégrité n’estpas l’objectif premier de Zed!. Le rôle principal du produitest de gérer la confidentialité des bienssensiblesqui lui sont confiés. Cependant Zed!intègre un mécanisme de contrôle de l’intégrité des fichiers techniques du conteneur ainsi que des fichiers de l’utilisateuravant qu’ils ne soient ouverts par celui-ci. La mise en œuvre de ces contrôles permet de détecter des altérations qui seraient nuisibles au bonfonctionnementde Zed! ou qui pourraient induireun défautdansson objectif de confidentialité. Biens sensibles Confidentialité Intégrité Biens sensibles de l’utilisateur Eléments des clés d’accès manipulés par Zed! : cas des mots de passeou codes confidentiels éventuels. (D.AUTH_USER) Forte NA Eléments des clés d’accès manipulés par Zed! : cas des clés d’accès elle- même si elles sontdirectement utilisées par Zed! (D.AUTH_USER) Forte Forte Mots de passedes correspondants stockés dans lecarnetde mot de passe (D.CARNET_MOT_DE_PASSE) Forte Faible. Bi clé de signature(D.ID_ADMIN) Forte Forte Fichiers etdossiers del’utilisateur stockés dans les conteneurs (D.DONNEES_UTILISATEUR) Forte Forte (toute erreur doit être signalée et empêcher le déchiffrement des données) Biens sensibles de la TOE Le conteneur pris dans son ensemble (D. CONT) Faible Forte Clé de chiffrement de fichiers (D.CLE_FIC) Forte Forte Fichier de contrôledu conteneur (D.FICHIER_CONTROLE) Faible Forte Fichier catalogue(D.FICHIER_CATALOGUE) Faible Forte Configuration de Zed! (D.CONFIGURATION) Faible Forte Programmes de Zed! (D.PROGRAMMES) Faible Forte Tableau 1 : Synthèse des biens sensibles PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 22 3.2. Hypothèses Pour Zed!, nomméela TOE dans les paragraphes suivants, les hypothèses suivantessur l’environnement d’utilisation seront prises en comptepour l’évaluation du niveau deconfianceoffert aux utilisateurs : H.NON_OBSERV L’environnement physiquedela TOE permet aux utilisateurs d’entrer leur mot depasseou code PIN sans être observabledirectement et sans quecela puisseêtreintercepté(clavier sans fil…) par d’autres utilisateurs ou attaquants potentiels. H.POSTE_SUR L'environnement opérationnel nepermet pas à un attaquant d'accéder au disque(physiquement ou par leréseau) lorsquedes données sensibles sont accessibles à un utilisateur légitimesur l'équipement. L'équipement doit donc apporter des protections efficaces contrel'accès illicitedistant (pare- feu correctement configuré, antivirus et anti logiciels espionsavec bases de données à jour etc.). H.CONFIANCE_ADMIN L’administrateur dela sécuritéet l’administrateur des accès sont des personnes deconfiance. Les administrateursWindows sont des personnes de confianceen chargede la configuration (avec des valeurs sures) des « policies ». Ils sont formés à l’utilisation dela TOE tout commeles utilisateurs. Les administrateurs dela sécuritédoivent garantir (ensemblesi ils appartiennent à des organisations différentes) l’utilisation depolitiquesde sécuritéconformes au niveau recherché(force des mots depasse notamment). H.CONSERVATION_CLES Les utilisateurs sontchargés dela conservation dans un lieu sûr et dela non divulgation des clés d’accès qui leurs ont ététransmises par l’administrateur de la sécurité. L’administrateur dela sécuritéest également chargéde conservation dans un lieu sûr et dela non divulgation des clés de recouvrement et deson bi-clé de signature. H.CERTIFICATS L’administrateur dela sécuritéest chargé, lors dela fournituredes clés d’accès possédant un certificat X509, devérifier la validitédeces certificats et leur adéquation avec l’usagequi en est fait par la TOE. H.ENV_PROTECT_TOE L’environnement techniquedela TOE assurel’intégritédes composantes de la TOE. L’administrationet la miseà jour de la TOE sont assurées par des personnes formées et habilitées. H.FIDELE_ENV L’environnement d’exécution fournit à la TOE unedate et une heureexacte pour assurer les fonctions d’horodatage. H.ENV_ALEA L’environnement d’exécution fournit à la TOE des mécanismes (événements partiellement imprédictible) pour produireles aléas nécessaires à la génération des secrets. H.CRYPTO_EXT Les clés d’accès générées ou stockées à l’extérieur de la TOE doivent être conformes aux documents [CRYPTO_STD] et [CLES_STD] pour le niveau standard. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 23 3.3. Menaces [contre les biens sensibles de la TOE] Il s’agit ici des menaces portantsur les bienssensiblesde la TOE elle-même. Celles qui concernent les biens des utilisateurs sont couvertes parles Politiquesde Sécurité Organisationnelles(services du produit) décrites plus loin. De manièregénérale, l’attaquant est un individu qui n’a pas accès aux données du conteneur (il n’a pas le droit d’en connaitre), il peut être interneou externe à la sociétéet agir selon différents canaux :  L’attaquant accède aux données de l’utilisateur légitime par vol ou accès illégitime au poste de travail. Par hypothèse, on considèreque d’autres moyens sont utilisés pour protéger les données qui peuvent seretrouver sur le disque utilisateur après extraction du conteneur (chiffrement du disque par exemple). Par contre l’agent menaçant considéré ne doit pas pouvoir ouvrir des conteneurs assurant des fonctions de stockagesécurisésur un poste par exemple ou accéder à des données sensibles qui auraient été temporairement stockées dans l’environnement d’exploitation pendant l’utilisation licitedeZed!. Il ne doit pas non plus affaiblir la protection des conteneurs en modifiant les politiques de sécurité.  L’attaquant intercepteles données sur leréseau (sansaccès physiqueau postedetravail). Par exemple, il intercepte un courrier échangé contenant un conteneur en pièce jointe afin de l’attaquer en installant ou pas le produit Zed! (ou Zed! Edition Limitée) sur son poste. L’attaquant considéréest dotéd’un potentiel d’attaque« enhanced-basic » au sens des Critères Communs. M.DETOURN_COMPOSANT En possession d’un conteneur intercepté, un attaquant seprocure le produit Zed! (ou Zed! Edition Limitée) et met en œuvre, éventuellement à bas niveau, les composants internes dela TOE, pour contourner certaines fonctions de sécuritéen provoquant ou profitant d’un dysfonctionnement. L’attaquant peut pour cela effectuer du «reverse-ingeniering» sur leprogramme, développer des programmes d’appel des fonctions internes dela TOE, ou s’aider d’un debugger. Le bien impactéest le programmedela TOE (confidentialitéet intégrité) et les données utilisateur (confidentialité). Il ne doit pas pouvoir, avec ces moyens, réussir à «pénétrer» le conteneur dans lequel il n’aurait pas normalement accès. M.POLITIQUE_SECU_INT Un attaquant signedes politiques à la placede l’administrateurde sécurité(politiques domaines ou politiques locales si accès au poste). Elle peut par exemple configurer son propreaccès de recouvrement qui sera automatiquement ajoutélorsque l’utilisateur créera ses prochains conteneurs. Lebien impactéest la configuration (intégrité) et indirectement les données utilisateur (confidentialité). M.CARNET_CONF Un attaquant récupèrele carnet de mot depasse stockésur le postedel’utilisateur pour tenter deretrouver les mots depasse des correspondants. Les biens impactés sont donc les motsde passedes correspondants et par suiteles données utilisateur stockées dans les conteneurs possédant ces accès (tous en confidentialité). Par exemple, l’attaquant tentededéchiffrer les mots depasse contenus dans lecarnet afin deles utiliser pour ouvrir les anciens ou futurs conteneurs échangés. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 24 M.FIC_CONTROLE_CONF Un attaquant récupèrele fichier de contrôled’un conteneur pour tenter de retrouver des informations protégées. Les biens impactés sont donc les clés de chiffrement et les données utilisateur (tous en confidentialité). Par exemple, l’attaquant tentederetrouver des informations protégées (telles que les clés de chiffrement) à partir des fichiers chiffrées du conteneur et du fichier de contrôledela TOE ou bien essayede déchiffrer directement les informations contenuesdans le fichier de contrôle. M.FIC_CONTROLE_INT Un attaquant récupèrelefichier de contrôled’un conteneur (stockédans celui-ci) et lemodifieafin de s’ajouter parmi les accès autorisés à ouvrir leconteneur (l’attaquant peut sepositionner entreles deux correspondants par exemple). Lebien impactéest donc le fichier de contrôledu conteneur (intégrité) et indirectement les données utilisateur (confidentialité). L’attaquant peut ainsi intercepter et lireles fichiers échangés entre les correspondants légitimes ou envoyer leconteneur à un correspondant (en usurpant l’identitéd’un utilisateurlégitime) dans le but delui faire envoyer des fichiers sensibles. M.FIC_CATALOGUE_INT Un attaquant récupèrele fichier catalogued’un conteneur (stocké dans celui-ci) et le modifiepour attaquer l’arborescencedu conteneur. Le bien impactéest donc le fichier cataloguedu conteneur et les données utilisateur (tous en intégrité). L’attaquant peut ainsi intercepter les conteneurs échangés et faire disparaitreun ou plusieurs des fichiers du conteneur sans quele destinatairenes’en aperçoive. M.DETOURNEMENT_CONTENEUR Un attaquant positionnésur le réseau intercepteun conteneur pour le détourner et l’utiliser en tant quevecteur d'attaque (insertion d’un programmemalveillantpar exemple). L'objectif de l'attaquant n'est alors pas seulement l'accès aux biens sensibles présents dans leconteneur mais peut êtreaussi la compromission du postedu destinataire(par exemple). Le bien impactéest donc le conteneur dans sa globalité(intégrité) et indirectement les données utilisateur présentes sur le poste (confidentialité et possiblement intégritési le programme malveillant est un ransomwarepar exemple). PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 25 Biens sensibles Menaces D.DONNEES_UTILISATEUR M.DETOURN_COMPOSANT M. POLITIQUE_SECU_INT M.FIC_CONTROLE_CONF M.FIC_CONTROLE_INT M.FIC_CATALOGUE_INT M.DETOURNEMENT_CONTENEUR D.CARNET_MOT_DE_PASSE M.CARNET_CONF D. CONT M.DETOURNEMENT_CONTENEUR D.CLE_FIC M.FIC_CONTROLE_CONF D. FICHIER_CONTROLE M.FIC_CONTROLE_INT D.FICHIER_CATALOGUE M.FIC_CATALOGUE_INT D.CONFIGURATION M.POLITIQUE_SECU_INT D.PROGRAMMES M.DETOURN_COMPOSANT Tableau 2 Association biens sensibles vers menaces Note :  D.AUTH_USER est couvert par H.NON_OBSERV et H.CONSERVATION_CLES  D.ID_ADMIN est couvert par l’hypothèse H.CONSERVATION_CLES 3.4. Politiques de sécurité organisationnelles OSP.CONFIDENTIALITE La TOE doit offrir un servicede protection en confidentialité(chiffrement), automatiqueet systématique, du stockageet dela transmission (piècejointe de courrier électronique) des fichiers sensibles des utilisateurs. OSP.INTEGRITE La TOE doit offrir un servicede contrôledel’intégrité(scellement), automatiqueet systématique, des fichiers sensiblesdes utilisateurs dansles conteneurs. OSP.ACCES La TOE doit permettreaux utilisateurs defournir unecléd’accès permettant d’accéder aux fichiers sensibles du conteneur auquel ils désirent accéder. S’ils ne peuvent fournir uneclé d’accès validepour le conteneur, l’accès doit être rejeté. OSP.RECOUVREMENT La TOE doit offrir un servicede recouvrement des fichiers sensibles des utilisateurs par l’emploi declés d’accès derecouvrement gérées par l’administrateur dela sécurité. Ces clés sont systématiquement et automatiquement affectées lors del’initialisation des conteneurs. OSP.COLLECTE La TOE doit offrir un servicede collecte d’information dans un fichier protégé pour les opérations desupport. Les informationscollectées sont sélectionnables parmi les logs, la configuration, les applications installées etc. Cettepolitiqueneconcerne queZed! Edition Standard. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 26 OSP.ADMIN_ACCES La TOE doit offrir un servicede gestion des accès (Zed! Edition Standard seulement). OSP.VERIF_POLICIES La TOE doit offrir un service(transparent pour l’utilisateur) devérification dela signaturedes politiques desécuritépar la clé privéede l’administrateurde sécurité(édition standard seulement). L’applicationdetoutenouvelle politiqueest conditionnéepar lesuccès decette vérification. OSP.CRYPTO Le référentiel del’ANSSI ([CRYPTO_STD], [CLES_STD] et [AUTH_STD]) défini pour le niveau derésistancestandard doit êtresuivi pour la génération d’aléa, la gestion des clés et pour les mécanismes cryptographiques et d’authentification utilisés dans la TOE. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 27 OBJECTIFS DE SÉCURITÉ 4.1. Objectifs de sécurité pour la TOE 4.1.1. Contrôle d’accès O.AUTH La TOE doit permettred’identifier et authentifier tout utilisateur. Pour cela, la TOE ne doit autoriser l’accès à un fichier d’un conteneur qu’après miseà disposition d’uneclé d’accès validepour ce conteneur. O.ROLES La TOE doit gérer trois rôles d’utilisateurs pour un conteneur chiffrée : un rôle ‘utilisateur normal’ ou plus simplement‘utilisateur’ (utilisationdes fichiers du conteneur sous condition de miseà disposition d’unecléd’accès valide), un rôle ‘administrateur des accès’ en chargede l’initialisation du container avec affectation des accès et un rôle ‘administrateur dela sécurité’ (installation, signaturedes politiques, recouvrementen plus dela gestion des accès). 4.1.2. Cryptographie O.CHIFFREMENT La TOE doit chiffrer et déchiffrer les données sensibles par l’emploi declés cryptographiques. La TOE doit utiliser des clés différentes pour protéger les différents conteneurs ainsi quedes vecteurs d’initialisation différents pour chaque fichier d’un conteneur. La TOE doit générer ces clés de chiffrement conformément aux exigences pour leniveau de robustessestandard des référentiels cryptographiques [CRYPTO_STD] et [CLES_STD] de l’ANSSI. O.SCELLEMENT La TOE doit pouvoir contrôler l’intégritédes données sensibles (fichier decontrôle, catalogue, watermark et fichiers utilisateur) par l’emploi declés cryptographiques différentes pour chaqueconteneur. La TOE doit générer ces clés descellement conformément aux exigences pour le niveau de robustessestandard des référentiels cryptographiques [CRYPTO_STD] et [CLES_STD] de l’ANSSI. O.EFFACEMENT_CLES La TOE doit assurer lenettoyagedes traces dedonnées sensibles (clés de chiffrement des fichiers, éléments permettant deretrouver les clés d’accès) dans la mémoire(RAM) dès la fin des opérations réalisées par la TOE. O.ALGO_STD La TOE doit produiredes aléas et fournir un choix d’algorithmes cryptographiques et detailles de clés conformes aux standards decedomaine, prévus dans [CRYPTO_STD] et complétés par [CLES_STD]. 4.1.3. Gestion des conteneurs O.ADM_ACCES La TOE doit offrir uneinterface à l’administrateur dela sécuritéet l’administrateur des accès permettant devisualiser les accès et gérer les clés d’accès aux conteneurs (Zed! Edition Standard seulement). L’utilisateurpeut seulement visualiser les accès. O.COMPATIBILITE La TOE doit assurer l’ouverturesécuriséedes conteneurs créés avec uneancienne version deZed! dont certains éléments nefaisaient pas encorel’objet d’un contrôled’intégrité. Ces éléments nedoivent pas êtremanipulés (cas du watermark). O.RECOUVREMENT La TOE doit permettred’affecter des clés d’accès de recouvrement. O.COLLECTE La TOE doit permettredecollecter de manièresécuriséedes informations utiles aux opérations desupport (Zed! Edition Standard seulement). PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 28 4.1.4. Protections lors de l’exécution O.INT_POLICIES La TOE doit vérifier la signaturedetoutes nouvelles politiques desécuritéà appliquer (édition standard seulement). En cas d’échec lors dela vérification, les politiques appliquées restent inchangées. 4.2. Objectifs de sécurité pour l’environnement 4.2.1. Pendant l’utilisation OE.NON_OBSERV L'utilisateur nedoit accéder à ses données sensibles quelorsqu'il se trouvedans un environnement deconfiance(lorsqu'il setrouveseul ou avec des personnes ayant lebesoin d'en connaître). Les mots de passepartagés entreles correspondants doivent êtreéchangés à travers des canaux organisationnels protégés. OE.ENV_OPERATIONNEL Lorsquel'utilisateur est authentifié, l'environnement opérationnel doit assurer la confidentialitédes données sensibles et des données d'authentification. Noted'application : L'équipement doit apporter des protectionsefficaces contrel'écoute illiciteet la transmission non autoriséededonnées (pare-feu correctement configuré, antivirus avec basededonnées à jour, « anti- spyware», etc.). Les applications installées sur l'équipement nedoivent pas perturber le bon fonctionnement dela TOE. OE.HORODATAGE L’environnement d’exploitation fournità la TOE un horodatagede qualitépour lui permettred’assurer correctement les fonctions nécessitant unedateet une heure exacte (traçagedes événements de sécuriténotamment). OE.ENV_ALEA L’environnement d’exploitation fournità la TOE des données lui permettant demettreen œuvredes mécanismes pour fournir les aléas nécessaires à la génération des secrets. 4.2.2. Formation des utilisateurs et des administrateurs OE.FORMATION L’administrateur des accès et les utilisateurs dela TOE doivent être formés à l’utilisation dela TOE et sensibilisés à la sécurité informatique(ceci prend en comptela sensibilisation sur la qualité des clés d’accès et de leur support lorsqu’elles sont hébergées par un porte-clés). L’administrateur dela sécuritédoit recevoir une formation adaptéeà cettefonction. OE.CRYPTO_EXT L’administrateur dela sécuritédoit êtresensibilisésur la qualitédes clés d'accès qu'il apporteà la TOE afin queces clés soient conformes à l'état de l'art dans leur implémentation. Il doit également être sensibiliséà la qualitédu support deces clés lorsqu'elles sont hébergées par un porte-clés externe. OE.CONSERV_CLES Les utilisateurs doivent conserver, dans un lieu sûr, les clés d’accès qui leurs ont été transmises par un administrateur dela sécuritéet empêcher leur divulgation. L’administrateur dela sécuritédoit PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 29 conserver ses clés de recouvrement et son bi-cléde signaturedans un lieu sûr et empêcher leur divulgation. 4.2.3. Administration OE.CONFIANCE_ADMIN L’administrateur des accès et l’administrateur dela sécuritédoivent être des personnes deconfiance. Les administrateursWindows sont des personnes deconfiance en charge de la configuration (avec des valeurs sures) des « policies ». Si les correspondants appartiennent à des entités gérés par des administrateursdela sécuritédifférents, ceux-ci doivent garantir ensemblel’utilisation depolitiquesdesécuritéconformes au niveau recherché (force des mots depassenotamment). OE.CERTIFICATS L'administrateurdela sécuritédoit, lors dela fournituredes clés d’accès possédant un certificat X509, vérifier la validitédeces certificats et leur adéquation avec l'usagequi en est fait par la TOE. Cetteexigence s'appliqueen particulier aux certificats racines dits «authenticode» à partir desquels la vérification d'intégritédela TOE peut être effectuée. OE.ENV_PROTECT_TOE L’environnement techniquedela TOE assurel’intégritédes composantes dela TOE et notamment ses programmes. L’administrationet la miseà jour de la TOE sont assurées par les administrateurshabilitées. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 30 EXIGENCES DE SÉCURITÉ DES TI 5.1. Exigences de sécurité de la TOE Dans cette section, les exigences de sécuritédela TOE ont été traduites en français afin d’améliorer leur compréhension. Letexteofficiel servant deréférence se trouvedans l’annexeA. Dans le texte français, toutes les opérations sur les composants(assignation, sélection, itérationet raffinement) sont représentées par des caractères en italiques (et en caractères gras pour la partieservant deréférence). 5.1.1. Exigences fonctionnelles de sécurité de la TOE Les composants fonctionnelssélectionnés pourrépondreaux objectifs desécuritédela TOE sont les suivants : Composants CC retenus FCS_CKM.1 Génération declés cryptographiques FCS_CKM.3 Accès aux clés cryptographiques FCS_CKM.4 Destruction declés cryptographiques FCS_COP.1 Opération cryptographique FDP_ACC.1 Contrôled'accès partiel FDP_ACF.1 Contrôled'accès basésur les attributs desécurité FDP_ITC.1 Importation depuis unezonehors du contrôledela TSF FDP_RIP.1 Protection d’unepartiedes informations résiduelles FDP_SDI.2 Contrôledel'intégritédes données stockées et action FDP_SDI_WAT_EXT.2 Contrôledel'intégritédu watermark et action FIA_AFL.1 Gestion d'unedéfaillancedel'authentification FIA_UAU.2 Authentification d’un utilisateur préalablement à touteaction FIA_UID.2 Identification d’un utilisateur préalablementà touteaction FMT_MOF.1 Administration des fonctionsdela TSF FMT_MSA.1 Gestion des attributs desécurité FMT_MSA.2 Attributs de sécuritésûrs FMT_MSA.3 Initialisation statiqued’attribut FMT_MTD.1 Gestion des données dela TSF FMT_SMF.1 Spécification des fonctions d’administration FMT_SMR.1 Rôles de sécurité FPT_TST.1 Tests de la TSF Tableau 3 : Exigences fonctionnelles de sécurité pour la TOE PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 31 5.1.1.1. Introduction Les exigences fonctionnelles desécurité(SFR) font référence aux sujets suivants: - Administrateur de la sécurité, administrateur des accès et utilisateur de la TOE avec comme attributs de sécurité leur rôle et leur clé d’accès permettant ou non d’effectuer les opérations sur les conteneurs. Les exigences fonctionnelles desécurité(SFR) font référence aux objets suivants: - Conteneurs manipulés par les utilisateurs dela TOE et qui contiennent les données sensibles des utilisateurs (fichiers, clés), Les exigences fonctionnelles desécurité(SFR) font référence aux opérations suivantes: - Gestion des conteneurs (politiques, recouvrement, gestion des accès, collecte d’information) - Utilisation des conteneurs 5.1.1.2. Classe FCS : Support Cryptographique FCS_CKM Gestion des clés cryptographiques FCS_CKM.1 Génération des clés cryptographiques FCS_CKM.1.1 La TSF doit générer les clés cryptographiques conformément à un algorithmede génération declés cryptographiques spécifiéparmi les suivants - génération de nombres pseudo-aléatoiresutiliséspour la génération des clés de chiffrement et des clés RSA de listes d’accès en utilisant les générateurs Hash_DRBG, HMAC_DRBG ou CTR_DRBG décrit dans la publication « RecommendationforRandomNumberGenerationUsingDeterministicRandom Bit Generators » (référence SP 800-90A révision 1) du NIST ; - diversification de clés PKCS#5 à partir des mots de passe - Génération de motde passe par le carnetde mot de passe pour en dériverune clé et à des tailles declés cryptographiques de 128, 192et 256bits pour les clés symétriqueset de 2048 à 4096 bitspourles clés asymétriques qui satisfont aux exigences cryptographiquesde l’ANSSI définies dans [CRYPTO_STD] et [CLES_STD]. Raffinement non éditorial : Ce composant ne s’applique qu’à l’édition standard(l’édition limitée n’effectue que la diversification de clés pour obtenir la clé d’accès de l’utilisateur à partir de son mot de passe). FCS_CKM.3 Accès aux clés cryptographiques FCS_CKM.3.1 La TSF doit réaliser l’utilisation de clés conformément à uneméthoded'accès aux clés cryptographiques spécifiée par utilisation du driver clavier et déchiffrement (déwrapping) des clés par la clé d’accès. Raffinement non éditorial : Ce composant s’applique en totalité à l’édition standardqui réalise notammenttoutes les fonctions d’administration sensibles. Par contre, l’édition limitée ne contientpasde driver clavier et utilise exclusivement la fonctionde déchiffrementdes clés. FCS_CKM.4 Destruction de clés cryptographiques FCS_CKM.4.1 La TSF doit détruireles clés cryptographiques conformément à uneméthodede destruction spécifiéedeclés cryptographiques par réécriture de motifs composés de zéros PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 32 suivi par une opérationde lecture-vérification. Si la lecture-vérificationde la réécriture échoue, le processus doit être répété. FCS_COP Opération cryptographique FCS_COP.1 Opération cryptographique FCS_COP.1.1 La TSF doit exécuter le hachage, le calcul et la vérificationd’intégrité, le chiffrement, le déchiffrement, la vérification de la signature des politiquesde sécurité, la générationde clés, le wrapping et dewrapping de clés et la dérivation de clés conformément à un algorithmecryptographiquespécifié HMAC, SHA-256 et SHA-512, RSA PKCS#1 v2.2, AES mode CBC et avec des tailles declés cryptographiques de 128, 192et 256 bits pour les clés symétriques et de 2048 bitsà 4096bitspourles clés asymétriques qui satisfont à cequi suit: exigences cryptographiquedel’ANSSI définiesdans[CRYPTO_STD] et [CLES_STD]. Raffinement non éditorial : L’édition limitée ne permet que le chiffrement et déchiffrement desfichiersainsi que le dewrapping de clé, la dérivation de clé et la fonction de hachage associée. 5.1.1.3. Classe FDP : Protection des données de l’utilisateur FDP_ACC Politique de contrôle d’accès FDP_ACC.1 Contrôle d'accès partiel FDP_ACC.1.1 La TSF doit appliquer la politique SFP.ACCESS_OBJ aux : Sujets: Administrateurs et utilisateurs de la TOE Objets: Conteneurscontenant les fichiersutilisateuret le fichier de contrôle. Opérations : Gestiondes conteneurs et utilisation. FDP_ACF Fonctions de contrôle d’accès FDP_ACF.1 Contrôle d'accès basé sur les attributs de sécurité FDP_ACF.1.1 La TSF doit appliquer la politique SFP.ACCESS_OBJ aux objets en fonction des : Sujets: Administrateurs et utilisateurs de la TOE Attributs de sécurité : Clés d’accès utilisateur permettantou nond’ouvrir le conteneuret rôle. Raffinement non éditorial : Il n’y a pas de rôle administrateurdansl’édition limitée, cette éditionne gère que le rôle utilisateur. FDP_ACF.1.2 La TSF doit appliquer les règles suivantes pour déterminer si uneopération entredes sujets contrôlés et des objets contrôlés est autorisée: Objet : Conteneur Opération: Gestion des conteneurset utilisation Règle : authentificationréussie aprèsmise à disposition de la clé d’accès associée au conteneur concerné avec accès à la gestiondu conteneuruniquement pour le rôle administrateur des accès (gestiondes accès) et administrateur de la sécurité (toute opération de gestion). FDP_ACF.1.3 La TSF doit autoriser explicitement l'accès desujets à des objets en fonction des règles complémentaires suivantes : Aucune. FDP_ACF.1.4 La TSF doit refuser explicitement l'accès desujets à des objets en fonction des règles complémentaires suivantes : Aucune. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 33 FDP_ITC Importation depuis une zone hors du contrôle de la TSF FDP_ITC.1 Importation de données utilisateur sans attributs de sécurité FDP_ITC.1.1 La TSF doit appliquer la politique de sécurité desfonctions(SFP) SFP.ACCESS_OBJ lors de l’importation dedonnées utilisateur, contrôlées par les SFP, en provenancedel’extérieur de la TOE. FDP_ITC.1.2 La TSF doit ignorer tout attribut desécuritéassociéaux données utilisateurlorsqu’elles sont importées depuis l’extérieur dela TOE. FDP_ITC.1.3 La TSF doit appliquer les règles suivantes lors del’importation des données utilisateur contrôlées par la SFP en provenancedel’extérieur de la TOE : Aucune FDP_RIP Protection des informations résiduelles FDP_RIP.1 Protection d’une partie des informations résiduelles FDP_RIP.1.1 La TSF doit garantir quetouteinformation contenueprécédemment dans uneressource est rendue inaccessiblelors de la désallocationde la ressource des objets clés de chiffrement des conteneurs et clés d’accès. FDP_SDI Intégrité des données stockées FDP_SDI.2 Contrôle de l'intégrité des données stockées et action à entreprendre FDP_SDI.2.1 La TSF doit contrôler les données del'utilisateur stockées au sein deconteneurs contrôlés par la TSF à la recherche des erreurs d'intégrité sur tousles objets, en fonction des attributs suivants HMAC pourchaque fichier calculé à partirdu contenu et de certaines propriétés techniques de ces fichiers. FDP_SDI.2.2 En cas de détection d'uneerreur d'intégrité, la TSF doit afficher un message d’erreuret interdire l’ouverturedu fichier. Raffinement non éditorial : Le contrôle s’effectue au moment de l’ouverture du fichier du conteneur. FDP_SDI_WAT_EXT.2 Extended Contrôle de l'intégrité du watermark et action FDP_SDI_WAT_EXT.2.1 La TSF doit contrôler lefichier watermark stockéau sein deconteneurs contrôlés par la TSF à la recherche des erreurs d'intégrité sur tousles objets, en fonction des attributssuivants HMAC calculé à partirdu contenu du fichier watermark. FDP_SDI_WAT_EXT.2.2 En cas de détection d'uneerreur d'intégrité, la TSF doit afficher un message d’erreuret interdire la manipulation du fichier. FDP_SDI_WAT_EXT.2.3 En cas d’absencedu HMAC du watermark dans leconteneur, theTSF doit afficher le watermark par défautcontenu dans la librairie Zed!. Raffinement non éditorial : Les anciennes versionsde Zed ! n’effectuaientpasde contrôle d’intégrité du watermark. 5.1.1.4. Classe FIA : Identification et authentification FIA_AFL Défaillances de l’authentification FIA_AFL.1 Gestion d'une défaillance de l'authentification FIA_AFL.1.1 La TSF doit détecter le fait que cinq tentatives d'authentification infructueuseont eu lieu en relation avec l’ouverture d’un conteneur. Note : il a éténécessaire d’effectuer un raffinement éditorial afin derendrele texte correct. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 34 FIA_AFL.1.2 Quand le nombrespécifiéde tentatives d’authentification infructueusesa étéatteint ou dépassé, la TSF doit temporiser l’accès à ce conteneur. FIA_UAU Authentification de l’utilisateur FIA_UAU.2 Authentification d’un utilisateur préalablement à toute action FIA_UAU.2.1 La TSF doit exiger quechaque utilisateur soit authentifiéavec succès avant d’autoriser touteautreaction transitant par la TSF pour lecomptedecet utilisateur. FIA_UID Identification de l’utilisateur FIA_UID.2 Identification d’un utilisateur préalablement à toute action FIA_UID.2.1 La TSF doit exiger quechaque utilisateur soit identifiéavec succès avant d’autoriser toute autreaction transitant par la TSF pour lecomptedecet utilisateur. 5.1.1.5. Classe FMT : Administration de la sécurité FMT_MOF Administration des fonctions de la TSF FMT_MOF.1 Administration du comportement des fonctions de sécurité FMT_MOF.1.1 La TSF doit restreindrel’aptituded’activerou désactiver les fonctionsde collecte d’information et de recouvrement à l’administrateurde la sécurité. Raffinement non éditorial : Ce composant ne s’applique qu’à l’édition standard(l’édition limitée ne permet pas d’effectuer d’opérationsde gestion). FMT_MSA Administration des attributs de sécurité FMT_MSA.1 Gestion des attributs de sécurité FMT_MSA.1.1 La TSF doit mettreen œuvrela politique SFP.ACCESS_OBJ pour restreindreaux administrateursdes accès et à l’administrateur de la sécurité la possibilitéde changer la valeur par défaut, modifier ousupprimer les attributsdesécurité clés d’accès et rôles. Raffinement non éditorial : Ce composant ne s’applique qu’à l’édition standard(l’édition limitée ne permet pasde gérer les accès). FMT_MSA.2 Attributs de sécurité sûrs FMT_MSA.2.1 La TSF doit garantir queseules des valeurs sûres sont acceptées pour les clés d’accès. Raffinement non éditorial : Ce composant ne s’applique qu’à l’édition standard(l’édition limitée ne permet pas de gérer les accès). FMT_MSA.3 Initialisation statique d’attribut FMT_MSA.3.1 La TSF doit mettreen œuvre la politique SFP.ACCESS_OBJ afin defournir des valeurs par défaut restrictives pour les attributsdesécuritéqui sont utiliséspour appliquer la SFP. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 35 FMT_MSA.3.2 La TSF doit permettreà l’administrateur desaccès et à l’administrateur de sécurité de spécifier des valeurs initiales alternatives pour remplacer les valeurs par défaut lorsqu’un objet ou uneinformation est créé. Raffinement non éditorial : Ce composant ne s’applique qu’à l’édition standard(l’édition limitée ne permet pasde gérer les accès). FMT_MTD Gestion des données de la TSF FMT_MTD.1 Gestion des données de la TSF FMT_MTD.1.1 La TSF doit restreindre, à l’administrateur de la sécurité, la possibilitéde changerla valeur par défaut, modifierou supprimer les stratégiesde sécurité. Raffinement non éditorial : Ce composant est implémenté par la signature des politiquesde sécurité, il ne s’applique qu’à l’éditionstandard (l’éditionlimitée ne permet pas d’effectuer d’opérationsde gestion). FMT_SMF Spécification des fonctions d’administration FMT_SMF.1 Spécification des fonctions d’administration FMT_SMF.1.1 La TSF doit êtrecapable d'exécuter les fonctions d’administration suivantes : - Les fonctions de gestion des accès - La fonction de recouvrement - La fonction de collecte d’information pour le support Raffinement non éditorial : L’édition limitée ne permet pas de gérer les accès et d’affecter desclés de recouvrement. FMT_SMR Rôle pour l’administration de la sécurité FMT_SMR.1 Rôles de sécurité FMT_SMR.1.1 La TSF doit tenir à jour les rôles administrateur de la sécurité, administrateurdes accès et utilisateurde la TOE. FMT_SMR.1.2 La TSF doit êtrecapable d’associer les utilisateurs aux rôles 5.1.1.6. Class FPT: Protection de la TSF FPT_TST.1 Auto tests de la TSF FPT_TST.1 Tests de la TSF FPT_TST.1.1 La TSF doit exécuter unesuited’auto tests lors du démarrage initial, périodiquement en utilisationcourante pour démontrer quela TSF fonctionnecorrectement. FPT_TST.1.2 La TSF doit fournir aux utilisateurs autorisés la possibilitéde vérifier l’intégrité d’aucune partie des donnéesde la TSF. FPT_TST.1.3 La TSF doit fournir aux utilisateurs autorisés la possibilitéde vérifier l’intégrité d’aucune partie de la TSF. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 36 5.1.2. Exigences d’assurance de sécurité de la TOE Commeindiquéau paragraphe3.3, la TOE doit êtrerésistanteaux attaques depénétration effectuées par un attaquant ayant un potentiel d’attaque« enhanced-basic ». Le niveau d’assurancevisépar la TOE est le niveau : EAL3 augmenté des composants ALC_FLR.3 et AVA_VAN.3 associéà une expertisede l’implémentation de la cryptographie décrite dans [QUALIF_STD]. Ce qui correspond à la sélection des composants d’assurancesuivants : Composant Commentaire ADV_ARC.1 Securityarchitecture description EAL3 ADV_FSP.3 Functional specificationwithcomplete summary EAL3 ADV_TDS.2 Architectural design EAL3 AGD_OPE.1 Operational user guidance EAL3 AGD_PRE.1 Preparative procedures EAL3 ALC_CMC.3 Authorisationcontrols EAL3 ALC_CMS.3 ImplementationrepresentationCMcoverage EAL3 ALC_DEL.1 Deliveryprocedures EAL3 ALC_DVS.1 Identificationof security measures EAL3 ALC_FLR.3 Systematicflaw remediation + ALC_LCD.1 Developerdefinedlife-cyclemodel EAL3 ASE_CCL.1 Conformance claims EAL3 ASE_ECD.1 Extendedcomponentsdefinition EAL3 ASE_INT.1 ST introduction EAL3 ASE_OBJ.2 Securityobjectives EAL3 ASE_REQ.2 Securityrequirements EAL3 ASE_SPD.1 Securityproblem definition EAL3 ASE_TSS.1 TOE summary specification EAL3 ATE_COV.2 Analysisof coverage EAL3 ATE_DPT.1 Testing:basic design EAL3 ATE_FUN.1 Functional testing EAL3 ATE_IND.2 Independenttesting- sample EAL3 AVA_VAN.3 Focused vulnerabilityanalysis + Tableau 4 : Composants d'assurance de sécurité Ce niveau d’assurancerespecteles dépendances entreles composants d’assuranceCC mentionnés dans la Partie3 des Critères Communs. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 37 SPÉCIFICATIONS GLOBALES DE LA TOE Les fonctions desécuritéréalisées par la TOE sont décrites dans cechapitre. F.CONTROLE_ACCES Contrôle d’accès au conteneur Cettefonction de sécuritéconstituel’interfaceréalisant lecontrôled’accès obligatoirepour ouvrir leconteneur contrôlépar la TOE. La TSF autoriseou refusel’accès à un conteneur chiffré sur la base dela vérification d’un couple identifiant/authentifiantfourni par l’utilisateur dela TOE. Une temporisation est appliquéeaprès cinq échecs d’authentification consécutifs. F.ENTREE_SECURISEE Entrée sécurisée Cettefonction de sécuritérecouvrela communication sécuriséededonnées fournies en entrée dela TOE en utilisant pour cela des fonctions dechiffrement et déchiffrement declé de conteneur et le driver clavier (édition standard) quand il s’agit d’entrer un mot de passeou un code defichier de clés. F.CONFIGURATION_TOE Modification de la configuration de la TOE Cettefonction de sécuritécouvrel’ensembledes opérations deconfiguration dela TOE (initialisation et modification) et assurequeseules des valeurs sûres deparamètres deconfiguration peuvent êtreutilisées. Les données de configuration concernent les «« policies »» deWindows qui sont signées par l’administrateurdesécuritéet exploitées par la TOE après vérification deleur signature. Ces données définissent notammentles types d’accès supportés, les algorithmes utilisés(AES 256 bitspar défaut), la forcedes mots depasse, le contrôledes certificats. Si la vérification est correcte, le posteest mis en conformitéavec les nouvelles politiques. F.GESTION_CLES_ACCES Gestion des clés Cettefonction de sécuritégèreles attributs desécuritéquesont les clés d’accès des utilisateurs et les rôles (utilisateur, administrateurdela sécuritéou administrateur des accès) qui leur sont associés. Un accès correspond à une cléd'accès (uneclé cryptographique) quepossèdeun utilisateuret permettant d'obtenir les éléments de chiffrement / déchiffrement du conteneur ainsi quel’ouverturedu carnet demot de passe. Si ces éléments sont extraits pour effectuer des opérations degestion des accès, la clé d’accès présentéedoit être associéeau rôle administrateur des accès (ou administrateur dela sécurité). Cettefonction gèreégalement l’accès de recouvrement qui est un accès particulier. Enfin la fonction F.GESTION_CLES_ACCES réaliseégalement les opérations degénération des clés RSA des listes d’accès et d’ajout des clés d’accès (dans l’édition standard) ainsi queles opérations d’accès à ces clés (par l’intermédiairedes tokens pkcs#11 notamment). Elleassurelenettoyagedeces clés en mémoireaprès un verrouillage de session ou unemiseen veille(édition standard), unefermeturede conteneur (édition limitée), unefermeturede session ou unefermeturedu poste. F.OPERATIONS_CRYPTO Implémentation des opérationscryptographiques Cettefonction de sécuritécouvrela génération des clés de chiffrement et de scellement, le chiffrement et déchiffrement des fichiers du conteneur, les opérations liées au contrôledel’intégritédes données ainsi que l’ensembledes opérations cryptographiques mises au servicedes autres fonctionsdesécurité. Certaines opérations cryptographiques(génération des clés par exemple) neconcernent pas l’édition limitée. La fonction effectuedes auto tests au démarrageet de manièrepériodiquepour vérifier le bon fonctionnement des algorithmes et du générateur aléatoire. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 38 ANNONCES DE CONFORMITE A UN PP Cettecible de sécuriténedéclare aucuneconformitéà un Profil deProtection. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 39 ARGUMENTAIRE 8.1. Argumentaire pour les objectifs de sécurité Cettesection présenteles liens de couvertureentreles objectifs de sécuritéet les éléments qui constituent la définition del’environnement dela TOE (hypothèses, politiques del’organisation et menaces). 8.1.1. Hypothèses Le tableau ci-dessous présentela couverturedes hypothèses retenues par les objectifs desécurité : OE.NON_OBSERV OE.ENV_OPERATIONNEL OE.HORODATAGE OE.CONFIANCE_ADMIN OE.CONSERV_CLES OE.CERTIFICATS OE.ENV_PROTECT_TOE OE.FORMATION OE.ENV_ALEA OE.CRYPTO_EXT Hypothèses H.NON_OBSERV X H.POSTE_SUR X H.CONFIANCE_ADMIN X X H.CONSERVATION_CLES X X H.CERTIFICATS X H.ENV_PROTECT_TOE X X H.FIDELE_ENV X H.ENV_ALEA X H.CRYPTO_EXT X Tableau 5 : Couverture des hypothèses par les objectifs de sécurité PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 40 H.NON_OBSERV L’environnement physiquedela TOE permet aux utilisateurs d’entrer leur mot depasseou code PIN sans être observabledirectement et sans quecela puisseêtreintercepté(clavier sans fil…) par d’autres utilisateurs ou attaquants potentiels. L’objectif OE.NON_OBSERV couvredirectement cettehypothèseen mettant à disposition del’utilisateur un environnement physiqueadéquat. H.POSTE_SUR L'environnement opérationnel nepermet pas à un attaquant d'accéder au disque(physiquement ou par leréseau) lorsquedes données sensibles sont accessibles à un utilisateur légitimesur son poste. Leposteutilisateurdoit donc apporter des protections efficaces contrel'accès illicitedistant (pare- feu correctement configuré, antivirus et anti logiciels espionsavec bases de données à jour etc.). L’objectif OE.ENV_OPERATIONNEL couvredirectement cettehypothèseen mettant à disposition del’utilisateur un environnement opérationnel adéquat. H.CONFIANCE_ADMIN L’administrateur dela sécuritéet l’administrateur des accès sont des personnes deconfiance. Les administrateursWindows sont des personnes de confianceen chargede la configuration (avec des valeurs sures) des « policies ». Ils sont formés à l’utilisation dela TOE tout commeles utilisateurs. Les administrateurs dela sécuritédoivent garantir (ensemblesi ils appartiennent à des organisations différentes) l’utilisation depolitiquesde sécuritéconformes au niveau recherché(force des mots depasse notamment). Les objectifs OE.CONFIANCE_ADMIN et OE.FORMATION couvrent directement cettehypothèseen employant des personnes deconfianceet en leur apportant la formation nécessaire. H.CONSERVATION_CLES Les utilisateurs sontchargés dela conservation dans un lieu sûr et dela non divulgation des clés d’accès qui leurs ont ététransmises par l’administrateur de sécurité. L’administrateur dela sécuritéest également chargéde conservation dans un lieu sûr et dela non divulgation des clés de recouvrement et deson bi-clé de signature. Les objectifs OE.CONSERV_CLES et OE.FORMATION couvrent cettehypothèseen responsabilisant et en sensibilisant les utilisateurs et l’administrateur. H.CERTIFICATS L’administrateur dela sécuritéest chargé, lors dela fournituredes clés d’accès possédant un certificat X509, devérifier la validitédeces certificats et leur adéquation avec l’usagequi en est fait par la TOE. L’objectif OE.CERTIFICATS couvredirectement cettehypothèse. H.ENV_PROTECT_TOE L’environnement techniquedela TOE assurel’intégritédes composantes de la TOE. L’administrationet la miseà jour de la TOE sont assurées par des personnes formées et habilitées. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 41 Les objectifs OE.ENV_PROTECT_TOE et OE.FORMATION couvrent cettehypothèseen assurant l’intégritédes programmes dela TOE et en formant les administrateurs. H.FIDELE_ENV L’environnement d’exécution fournit à la TOE unedate et une heureexacte pour assurer les fonctions d’horodatage. L’objectif OE.HORODATAGE couvredirectement cettehypothèse. H.ENV_ALEA L’environnement d’exécution fournit à la TOE des mécanismes (événements partiellement imprédictible) pour produireles aléas nécessaires à la génération des secrets. L’objectif OE.ENV_ALEA couvredirectement cette hypothèse. H.CRYPTO_EXT Les clés d’accès générées ou stockées à l’extérieur de la TOE doivent être conformes aux documents [CRYPTO_STD] et [CLES_STD] pour le niveau standard. L'objectif OE.CRYPTO_EXT couvredirectement cettehypothèse. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 42 8.1.2. Menaces Le tableau ci-dessous présenteles liens decouvertureentreles objectifs de sécuritéet les menaces retenues : O.AUTH O.ROLES O.CHIFFREMENT O.SCELLEMENT O.EFFACEMENT_CLES O.ALGO_STD O.ADM_ACCES O.COMPATIBILITE O.RECOUVREMENT O.COLLECTE O.INT_POLICIES OE.CONFIANCE_ADMIN OE.CONSERV_CLES Menaces M.DETOURN_COMPOSANT X X X M.POLITIQUE_SECU_INT X X X M.CARNET_CONF X X M.FIC_CONTROLE_CONF X X X M.FIC_CONTROLE_INT X X X X M.FIC_CATALOGUE_INT X X X X M.DETOURNEMENT_CONTENEUR X X X Tableau 6 : Couverture des menaces par les objectifs de sécurité M.DETOURN_COMPOSANT En possession d’un conteneur intercepté, un attaquant seprocurele produit Zed! (ou Zed! Edition Limitée) et met en œuvre, éventuellement à bas niveau, les composants internes dela TOE, pour contourner certaines fonctions desécuritéen provoquant ou profitant d’un dysfonctionnement. L’attaquant peut pour cela effectuer du «reverse-ingeniering» sur leprogramme, développer des programmes d’appel des fonctions internesdela TOE, ou s’aider d’un debugger. Le bien impactéest leprogrammedela TOE (confidentialitéet intégrité) et les données utilisateur (confidentialité). Il ne doit pas pouvoir, avec ces moyens, réussir à «pénétrer» le conteneur dans laquelleil n’aurait pas normalement accès.  Pour prévenir cettemenace, la TOE doit :  Garantir le fait qu’avant toute opération sur la TOE, une authentification est nécessaire (O.AUTH),  Pour seprotéger la TOE doit :  Garantirlefait qu'iln'estpaspossible,cryptographiquement,deretrouverlesclés de chiffrementduconteneur sans fournir uneclé d'accès valide: le détournement d'un composant(i.e. sa miseen œuvrede façon détournée ou non prévue) ne peut pas permettre de franchir cette barrière (O.AUTH et O.ALGO_STD),  Garantir le fait qu'un composant détournéne conserve pas de résidus de clé permettant de présenter un chemin pour une attaque (O.EFFACEMENT_CLES). PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 43  Pour limiter l'impactdela menace, la TOE doit : Rien M.POLITIQUE_SECU_INT Un attaquant signedes politiques à la placede l’administrateurde sécurité(politiques domaines ou politiques locales si accès au poste). Elle peut par exemple configurer son propreaccès de recouvrement qui sera automatiquement ajoutélorsquel’utilisateur créera ses prochains conteneurs. Lebien impactéest la configuration (intégrité) et indirectement les données utilisateur (confidentialité).  Pour prévenir cettemenace, la TOE doit :  Garantir le fait que les administrateurs (dont les administrateurs Windows) sont des personnes de confiance (OE.CONFIANCE_ADMIN) ;  Garantir le fait que l’administrateur de sécurité conserve sa clé privée de signature dans un lieu sûr (OE.CONSERV_CLES)  Pour se protéger la TOE doit :  Garantir le fait qu’il n’est pas possible d’appliquer des politiques de sécurité (et donc modifier le fichier des politiques) sans qu’elles soient signées par le responsable de sécurité (O.INT_POLICIES)  Pour limiter l'impactdela menace, la TOE doit : Rien M.CARNET_CONF Un attaquant récupèrele carnet de mot depasse stockésur leposte de l’utilisateur pour tenter deretrouver les mots depassedes correspondants. Les biens impactés sontdonc les mots depassedes correspondants et par suiteles données utilisateur stockées dans les conteneurs possédant ces accès (tous en confidentialité). Par exemple, l’attaquant tentededéchiffrer les mots depasse contenus dans lecarnet afin deles utiliser pour ouvrir les anciens et futurs conteneurs échangés.  Pour prévenir cettemenace, la TOE doit :  Garantir le fait qu’avant toute opération sur la TOE, une authentification est nécessaire (O.AUTH),  Pour seprotéger la TOE doit :  Garantir le fait qu'il n'est pas possible, cryptographiquement, deretrouver les mots de passe du carnet de mot de passesans fournir une clé d'accès valide, et par le fait que cet objectif prévoit que le carnet de mot de passede la TOE respecte également ce principe (O.AUTH et O.ALGO_STD).  Pour limiter l'impactdela menace, la TOE doit :  Rien M.FIC_CONTROLE_CONF Un attaquant récupèrele fichier de contrôled’un conteneur pour tenter de retrouver des informations protégées. Les biens impactés sont donc les clés de chiffrement et les données utilisateur (tous en confidentialité). PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 44 Par exemple, l’attaquant tentederetrouver des informations protégées (telles que les clés de chiffrement) à partir des fichiers chiffrées du conteneur et du fichier de contrôledela TOE ou bien essayede déchiffrer directement les informations contenuesdans le fichier de contrôle.  Pour prévenir cettemenace, la TOE doit :  Garantir le fait qu’avant toute opération sur la TOE, une authentification est nécessaire (O.AUTH),  Pour seprotéger la TOE doit :  Garantirlefait qu'iln'estpaspossible,cryptographiquement,deretrouverlesclés de chiffrementduconteneur sans fournir une clé d'accès valide, et par le fait que cet objectif prévoit que le fichier de contrôle de la TOE respecte également ce principe (O.AUTH et O.ALGO_STD).  Pour limiter l'impactdela menace, la TOE doit :  Garantir le fait que les fichiers internes des différents conteneurs sont rendus «cryptographiquement différents» par l'utilisation d'aléas nepermettant pas detirer des enseignements d'un fichier de contrôlepour en attaquer un autre (O.CHIFFREMENT et O.ALGO_STD). M.FIC_CONTROLE_INT Un attaquant récupèrelefichier de contrôled’un conteneur (stocké dans celui-ci) et le modifieafin de s’ajouter parmi les accès autorisés à ouvrir leconteneur (l’attaquant peut sepositionner entreles deux correspondants par exemple). Lebien impactéest donc lefichier de contrôledu conteneur (intégrité) et indirectement les données utilisateur (confidentialité). L’attaquant peut ainsi intercepter et lireles fichiers échangés entre les correspondants légitimes ou envoyer leconteneur à un correspondant (en usurpant l’identitéd’un utilisateurlégitime) dans le but de lui faireenvoyer des fichiers sensibles.  Pour prévenir cettemenace, la TOE doit :  Garantir le fait qu’avant toute opération sur la TOE, une authentification est nécessaire (O.AUTH),  Pour seprotéger la TOE doit :  Garantirlefait qu'iln'estpaspossible,cryptographiquement,deretrouverlesclés de chiffrementdu conteneur sans fournir unecléd'accès valide: le détournement du fichier decontrôle(i.e. sa miseen œuvrede façon détournéeou non prévue) est interdit par cette barrière (O.AUTH et O.ALGO_STD),  Garantir lefait que touteatteinteportéeà l’intégrité du fichier de contrôlesera détectée et portéeà connaissance de l’utilisateur qui ouvrira le conteneur (O.SCELLEMENT).  Pour limiter l'impactdela menace, la TOE doit :  Garantir le fait que les fichiers internes des différents conteneurs sont rendus «cryptographiquement différents» par l'utilisation d'aléas nepermettant pas detirer des enseignements d'un fichier de contrôlepour en attaquer un autre (O.CHIFFREMENT et O.ALGO_STD). M.FIC_CATALOGUE_INT Un attaquant récupèrele fichier catalogued’un conteneur (stocké dans celui-ci) et le modifiepour attaquer l’arborescencedu conteneur. Le bien impactéest donc le fichier cataloguedu conteneur et les données utilisateur (tous en intégrité). PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 45 L’attaquant peut ainsi intercepter les conteneurs échangés et faire disparaitreun ou plusieurs des fichiers du conteneur sans quele destinatairenes’en aperçoive.  Pour prévenir cettemenace, la TOE doit :  Garantir le fait qu’avant toute opération sur la TOE, une authentification est nécessaire (O.AUTH),  Pour seprotéger la TOE doit :  Garantirlefait qu'iln'estpaspossible,cryptographiquement,deretrouverlesclés de chiffrementduconteneur sans fournir une clé d'accès valide: le détournement du fichier catalogue(i.e. sa miseen œuvrede façon détournée ou non prévue) est interdit par cette barrière (O.AUTH et O.ALGO_STD),  Garantir lefait quetouteatteinteportéeà l’intégritédu fichier cataloguesera détectéeet portéeà connaissancede l’utilisateur qui ouvrira le conteneur (O.SCELLEMENT).  Pour limiter l'impactdela menace, la TOE doit :  Garantir le fait que les fichiers internes des différents conteneurs sont rendus «cryptographiquement différents» par l'utilisationd'aléas ne permettant pas de tirer des enseignements d'un fichier catalogue pour en attaquer un autre (O.CHIFFREMENT et O.ALGO_STD). M.DETOURNEMENT_CONTENEUR Un attaquant positionnésur leréseau intercepteun conteneur pour le détourner et l’utiliser en tant quevecteur d'attaque(insertion d’un programmemalveillantpar exemple). L'objectif del'attaquant n'est alors pas seulement l'accès aux biens sensibles présents dans le conteneur mais peut êtreaussi la compromission du postedu destinataire(par exemple). Le bien impactéest donc le conteneur dans sa globalité(intégrité) et indirectement les données utilisateur présentessur le poste (confidentialité).  Pour prévenir cettemenace, la TOE doit :  Garantir le fait qu’avant toute opération sur la TOE, une authentification est nécessaire (O.AUTH),  Pour seprotéger la TOE doit :  Garantir le fait que toute atteinte portée à l’intégrité du conteneur sera détectée et portée à connaissance de l’utilisateur qui ouvrira le conteneur (O.SCELLEMENT).  Garantir lefait qu'il n'est pas possible, cryptographiquement, decontourner les mécanismes decontrôled’intégrité (O.ALGO_STD).  Pour limiter l'impactdela menace, la TOE doit :  rien PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 46 8.1.3. Politiques de sécurité de l’organisation Le tableau ci-dessous présenteles liens decouvertureentreles objectifs de sécuritéet les politiques desécuritéde l’organisation retenues : O.AUTH O.ROLES O.CHIFFREMENT O.SCELLEMENT O.EFFACEMENT_CLES O.ALGO_STD O.ADM_ACCES O.COMPATIBILITE O.RECOUVREMENT O.COLLECTE O.INT_POLICIES Politiques de sécurité de l’organisation OSP.CONFIDENTIALITE X X X X OSP.INTEGRITE X X X X OSP.ACCES X X X OSP.RECOUVREMENT X X X X OSP.COLLECTE X X X X OSP.ADMIN_ACCES X X X X OSP.VERIF_POLICIES X OSP.CRYPTO X Tableau 7 : Couverture des politiques de sécurité de l’organisation par les objectifs de sécurité OSP.CONFIDENTIALITE La TOE doit offrir un servicede protection en confidentialité(chiffrement), automatiqueet systématique, du stockageet dela transmission (piècejointe de courrier électronique) des fichiers sensibles des utilisateurs. Note: cettepolitiqueconcernela création initialedu conteneur, et le fait qu'unefois le conteneur créée, tout fichier déposédans celui-ci est stockéchiffré. Cettepolitiqueneconcerne pas les accès au conteneur, qui relèvent de OSP.ACCES.  Pour couvrir cettepolitique, la TOE :  Génère, lors du chiffrement, des aléas pour la création des clés de chiffrement du conteneur (O.ALGO_STD) ;  Chiffre les fichiers dans le conteneur (O.CHIFFREMENT) ;  Ne déchiffre pas les fichiers si une erreur d’intégrité est détectée (O.SCELLEMENT) ;  Pour garantir la miseen œuvrede la politique, la TOE :  Efface les traces mémoire liées aux clés de chiffrement des fichiers (O.EFFACEMENT_CLES) ; OSP.INTEGRITE La TOE doit offrir un servicede contrôledel’intégrité(scellement), automatiqueet systématique, des fichiers sensiblesdes utilisateurs dansles conteneurs.  Pour couvrir cettepolitique, la TOE :  Génère, lors du chiffrement, des aléas pour la création des clés de scellement du conteneur (O.ALGO_STD) ; PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 47  Calcul un sceau et un HMAC pour chaque fichier du conteneur et interdit l’ouverturedu fichier en cas d’échec de vérification (O.SCELLEMENT) ;  Calcul un sceau et un HMAC du fichier watermark du conteneur et interdit l’ouverturedu conteneur en cas d’échec de vérification (O.SCELLEMENT) ;  N’affichepas le watermark d’un conteneur donton nepeut vérifier l’intégritécar crééavec uneancienneversion de Zed ! (O.COMPATIBILITE)  Calcul un HMAC du fichier catalogue(O.SCELLEMENT) pour prévenir la suppression d’un fichier par un attaquant et interdit l’ouverture du conteneur en cas d’échec de vérification.  Pour garantir la miseen œuvrede la politique, la TOE :  Efface les traces mémoire liées aux clés de scellement des fichiers (O.EFFACEMENT_CLES) ; OSP.ACCES La TOE doit permettreaux utilisateurs defournir unecléd’accès permettant d’accéder aux fichiers sensibles du conteneur auquel ils désirent accéder. S’ils ne peuvent fournir uneclé d’accès validepour le conteneur, l’accès doit être rejeté. Note: cettepolitiqueneconcerne pas la gestion des accès (création assuréepar OSP.ADMIN_ACCES), mais l'utilisation d'un accès.  Pour couvrir cettepolitique, la TOE :  Demande une authentification avant toute manipulation du fichier d’un conteneur (O.AUTH);  Calcul un HMAC du fichier de contrôle (O.SCELLEMENT) contenant la clé de conteneur chiffrée par les accès utilisateur et interdit l’ouverture du conteneur en cas d’échec de vérification.  Pour garantir la miseen œuvrede la politique, la TOE :  Fait en sortequeseuleuneclé d'accès validepuissepermettrederetrouver les clés dechiffrement du conteneur, et que les fichiers ou informations internes de la TOE ne permettent pas de faire autrement (O.AUTH).  Efface les traces mémoireliées aux éventuels calculs cryptographiques intermédiaires (dérivationdemotsdepasse) ou au transport des valeurs de clés de chiffrement lorsqu'elles sont calculées par un dispositif cryptographique externe (token) (O.EFFACEMENT_CLES) ; OSP.RECOUVREMENT La TOE doit offrir un servicede recouvrement des fichiers sensibles des utilisateurs par l’emploi declés d’accès derecouvrement gérées par l’administrateur dela sécurité. Ces clés sont systématiquement et automatiquement affectées lors del’initialisation des conteneurs. Pour mettreen œuvrela politique, la TOE :  Pour couvrir cettepolitique, la TOE :  Permet d’affecter des clés d’accès de recouvrement au conteneur (O.RECOUVREMENT).  Demande une authentification pour accéder à la gestion des clés de recouvrement (O.AUTH) ;  N’autorise que l’administrateur de la sécurité à effectuer les opérations de recouvrement (O.ROLES)  Pour garantir la miseen œuvrede la politique, la TOE :  Fait en sortequeseuleune clé d'accès validepuissepermettrederetrouver les clés dechiffrement d'un conteneur, et que les fichiers ou informations internes de la TOE ne permettent pas de faire autrement (O.AUTH) ; PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 48  Efface les traces mémoireliées aux éventuels calculs cryptographiques intermédiaires (dérivationdemotsdepasse) ou au transport des valeurs de clés de chiffrement lorsqu'elles sont calculées par un dispositif cryptographique externe (token) (O.EFFACEMENT_CLES). OSP.COLLECTE La TOE doit offrir un servicede collected’information dans un fichier protégé pour les opérations desupport. Les informationscollectées sont sélectionnables parmi les logs, la configuration, les applications installées etc. Cettepolitiqueneconcerne queZed! Edition Standard. Pour mettreen œuvrela politique, la TOE :  Pour couvrir cettepolitique, la TOE :  Offre une interface à l’administrateur lui permettant de collecter les informations (O.COLLECTE)  Demande une authentification pour accéder au fichier protégé (O.AUTH) ;  Permet à l’administrateur d’activer ou de désactiver la fonction (O.ROLES)  Pour garantir la miseen œuvrede la politique, la TOE :  Efface les traces mémoires des clés d’accès manipulées (O.EFFACEMENT_CLES). OSP.ADMIN_ACCES La TOE doit offrir un servicede gestion des accès (Zed! Edition Standard seulement).  Pour couvrir cettepolitique, la TOE :  Demande une authentification avant de permettre la gestion des accès au conteneur chiffré (O.AUTH) ;  Contrôlequeseul un utilisateur disposantdu rôleadministrateur (des accès ou dela sécurité) a le droit degérer les accès (O.ROLES) ;  Offre uneinterfaceà l’administrateur lui permettantdevisualiser les accès (possibleégalementpour l’utilisateur) et gérer les clés d’accès au conteneur (O.ADM_ACCES).  Pour garantir la miseen œuvrede la politique, la TOE :  Efface les traces mémoires des clés d’accès manipulées (O.EFFACEMENT_CLES). OSP.VERIF_POLICIES La TOE doit offrir un service(transparent pour l’utilisateur) devérification dela signaturedes politiques desécuritépar la clé privéede l’administrateurde sécurité(édition standard seulement). L’applicationdetoutenouvellepolitique est conditionnéepar le succès decette vérification.  Pour couvrir cette politique, la TOE :  Vérifie la signature des nouvelles politiques de sécurité appliquées et refuse leur application si la signature est incorrecte (O.INT_POLICIES). OSP.CRYPTO Le référentiel del’ANSSI ([CRYPTO_STD], [CLES_STD] et [AUTH_STD]) défini pour le niveau derésistancestandard doit êtresuivi pour la génération d’aléa, la gestion des clés et pour les mécanismes cryptographiques et d’authentification utilisés dans la TOE. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 49  Pour couvrir cette politique, la TOE :  Fournitunchoixd'algorithmescryptographiquesetdetaillesdeclés conformesauxstandardsdecedomaine,prévus dans [CRYPTO_STD] et complétés par [CLES_STD] pour la production d’aléa et la gestion des clés (O.ALGO_STD). PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 50 8.1.4. Synthèse sur la couverture des objectifs Le tableau ci-dessous présentela synthèsedes liens decouvertureentreles objectifs desécurité, les hypothèses, menaces et politiques desécuritédel’organisation retenues. H.NON_OBSERV H.POSTE_SUR H.CONFIANCE_ADMIN H.CONSERVATION_CLES H.CERTIFICATS H.ENV_PROTECT_TOE H.FIDELE_ENV H.ENV_ALEA H.CRYPTO_EXT M.DETOURN_COMPOSANT M.POLITIQUE_SECU_INT M.FIC_CONTROLE_CONF M.FIC_CONTROLE_INT M.FIC_CATALOGUE_INT M.DETOURNEMENT_CONTENEUR OSP.CONFIDENTIALITE OSP.INTEGRITE OSP.ACCES OSP.RECOUVREMENT OSP.COLLECTE OSP.ADMIN_ACCES OSP.VERIF_POLICIES OSP.CRYPTO Objectifs de sécurité OE.NON_OBSERV X OE.ENV_OPERATIONNEL X OE.HORODATAGE X OE.CONFIANCE_ADMIN X X OE.CONSERV_CLES X X OE.CERTIFICATS X OE.ENV_PROTECT_TOE X OE.FORMATION X X X OE.ENV_ALEA X OE.CRYPTO_EXT X O.AUTH X X X X X X X X X O.ROLES X X X O.CHIFFREMENT X X X X O.SCELLEMENT X X X X X X O.EFFACEMENT_CLES X X X X X X X O.ALGO_STD X X X X X X X O.ADM_ACCES X O.COMPATIBILITE X O.RECOUVREMENT X O.COLLECTE X O.INT_POLICIES X X Tableau 8 : Couverture des objectifs de sécurité par les hypothèses, menaces et politiques de sécurité de l’organisation PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 51 8.2. Argumentaire pour les exigences de sécurité 8.2.1. Dépendances entre exigences fonctionnelles de sécurité Le tableau ci-dessous présentela couverturedes dépendances entreles composants fonctionnels sélectionnés : Composant Dépendances Dépendances satisfaites FCS_CKM.1 [FCS_CKM.2 ou FCS_COP.1], FCS_CKM.4 FCS_COP.1, FCS_CKM.4 FCS_CKM.3 [FDP_ITC.1 ou FDP_ITC.2 ou FCS_CKM.1], FCS_CKM.4 FDP_ITC.1, FCS_CKM.1, FCS_CKM.4 FCS_CKM.4 [FDP_ITC.1 ou FDP_ITC.2 ou FCS_CKM.1] FDP_ITC.1, FCS_CKM.1 FCS_COP.1 [FDP_ITC.1 ou FDP_ITC.2 ou FCS_CKM.1], FCS_CKM.4 FDP_ITC.1, FCS_CKM.1, FCS_CKM.4 FDP_ACC.1 FDP_ACF.1 FDP_ACF.1 FDP_ACF.1 FDP_ACC.1, FMT_MSA.3 FDP_ACC.1, FMT_MSA.3 FDP_ITC.1 [FDP_ACC.1 ou FDP_IFC.1], FMT_MSA.3 FDP_ACC.1, FMT_MSA.3 FDP_RIP.1 Aucune Aucune FDP_SDI.2 Aucune Aucune FDP_SDI_WAT_EXT.2 Aucune Aucune FIA_AFL.1 FIA_UAU.1 FIA_UAU.2 FIA_UAU.2 FIA_UID.1 FIA_UID.2 FIA_UID.2 Aucune Aucune FMT_MOF.1 FMT_SMF.1, FMT_SMR.1 FMT_SMF.1, FMT_SMR.1 FMT_MSA.1 [FDP_ACC.1 ou FDP_IFC.1], FMT_SMF.1, FMT_SMR.1 FDP_ACC.1, FMT_SMF.1, FMT_SMR.1 FMT_MSA.2 [FDP_ACC.1 ou FDP_IFC.1], FMT_MSA.1, FMT_SMR.1 FDP_ACC.1, FMT_MSA.1, FMT_SMR.1 FMT_MSA.3 FMT_MSA.1, FMT_SMR.1 FMT_MSA.1, FMT_SMR.1 FMT_MTD.1 FMT_SMR.1, FMT_SMF.1 FMT_SMR.1, FMT_SMF.1 FMT_SMF.1 Aucune Aucune FMT_SMR.1 FIA_UID.1 FIA_UID.2 FPT_TST.1 Aucune Aucune Tableau 9 : Satisfaction des dépendances entre exigences fonctionnelles de sécurité PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 52 8.2.2. Dépendances entre exigences d’assurance de sécurité Le tableau ci-dessous présentela couverturedes dépendances entreles composants d’assurancesélectionnés : Composant Dépendances Dépendances satisfaites ADV_ARC.1 ADV_FSP.1, ADV_TDS.1 ADV_FSP.3, ADV_TDS.2 ADV_FSP.3 ADV_TDS.1 ADV_TDS.2 ADV_TDS.2 ADV_FSP.3 ADV_FSP.3 AGD_OPE.1 ADV_FSP.1 ADV_FSP.3 AGD_PRE.1 Aucune Aucune ALC_CMC.3 ALC_CMS.1, ALC_DVS.1, ALC_LCD.1 ALC_CMS.3, ALC_DVS.1, ALC_LCD.1 ALC_CMS.3 Aucune Aucune ALC_DEL.1 Aucune Aucune ALC_DVS.1 Aucune Aucune ALC_FLR.3 Aucune Aucune ALC_LCD.1 Aucune Aucune ASE_CCL.1 ASE_INT.1, ASE_ECD.1, ASE_REQ.1 ASE_INT.1, ASE_ECD.1, ASE_REQ.2 ASE_ECD.1 Aucune Aucune ASE_INT.1 Aucune Aucune ASE_OBJ.2 ASE_SPD.1 ASE_SPD.1 ASE_REQ.2 ASE_OBJ.2, ASE_ECD.1 ASE_OBJ.2, ASE_ECD.1 ASE_SPD.1 Aucune Aucune ASE_TSS.1 ASE_INT.1, ASE_REQ.1, ADV_FSP.1 ASE_INT.1, ASE_REQ.2, ADV_FSP.3 ATE_COV.2 ADV_FSP.2, ATE_FUN.1 ADV_FSP.3, ATE_FUN.1 ATE_DPT.1 ADV_ARC.1, ADV_TDS.2, ATE_FUN.1 ADV_ARC.1, ADV_TDS.2, ATE_FUN.1 ATE_FUN.1 ATE_COV.1 ATE_COV.2 ATE_IND.2 ADV_FSP.2, AGD_OPE.1, AGD_PRE.1, ATE_COV.1, ATE_FUN.1 ADV_FSP.3, AGD_OPE.1, AGD_PRE.1, ATE_COV.2, ATE_FUN.1 AVA_VAN.3 ADV_ARC.1, ADV_FSP.4*, ADV_TDS.3*, ADV_IMP.1*, AGD_OPE.1, AGD_PRE.1, ATE_DPT.1 ADV_ARC.1, ADV_FSP.3, AGD_OPE.1, AGD_PRE.1, ATE_DPT.1 Tableau 10 : Satisfaction des dépendances entre exigences d’assurance de sécurité 8.2.3. Argumentaire pour les dépendances non satisfaites *La dépendanceAVA_VAN.3 avec ADV_FSP.4, ADV_IMP.1 et ADV_TDS.3 nesont pas satisfaites par construction du paquet d'assurancedela qualification deniveau standard défini par l’ANSSI. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 53 8.2.4. Argumentaire de couverture des objectifs de sécurité par les exigences fonctionnelles Les tableaux ci-dessous présentent la couverturedes composantsfonctionnels sélectionnés par les objectifs de sécurité: Objectifs de sécurité de la TOE FCS_CKM.1 FCS_CKM.3 FCS_CKM.4 FCS_COP.1 FDP_ACC.1 FDP_ACF.1 FDP_ITC.1 FDP_RIP.1 FDP_SDI.2 FDP_SDI_WAT_EXT.2 FIA_AFL.1 FIA_UAU.2 FIA_UID.2 FMT_MOF.1 FMT_MSA.1 FMT_MSA.2 FMT_MSA.3 FMT_MTD.1 FMT_SMF.1 FMT_SMR.1 FPT_TST.1 O.AUTH X X X X X X O.ROLES X X X X X X O.CHIFFREMENT X X X O.SCELLEMENT X X X X X O.EFFACEMENT_CLES X O.ALGO_STD X X X X X O.ADM_ACCES X X X X X O.COMPATIBILTE X X O.RECOUVREMENT X X X X O.COLLECTE X X X X O.INT_POLICIES X X Tableau 11 : Couverture des objectifs de sécurité par les exigences fonctionnelles de sécurité 8.2.4.1. Contrôled’accès O.AUTH La TOE doit permettred’identifier et authentifier tout utilisateur. Pour cela, la TOE ne doit autoriser l’accès à un fichier d’un conteneur qu’après miseà disposition d’unecléd’accès validepour ce conteneur. Afin de remplir cet objectif :  La TOE identifieet authentifiechaqueutilisateur avant d’ouvrir les conteneurs chiffrés (FIA_UID.2 et FIA_UAU.2) et appliqueunerèglederalentissementd’affichagedela mired’authentificationàunutilisateur,suiteàplusieursessais d’authentification infructueux (FIA_AFL.1).  Pour que la TOE donne l’accès au conteneur chiffré, l’utilisateur doit présenter sa clé d’accès (token USB par exemple) en vue de son authentification (FDP_ITC.1).  La TOE applique ensuite une politique de contrôle d’accès au conteneur (FDP_ACC.1) basé sur les attributs de sécurité (FDP_ACF.1). PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 54 O.ROLES La TOE doit gérer trois rôles d’utilisateurs pour un conteneur chiffrée : un rôle ‘utilisateur normal’ ou plus simplement ‘utilisateur’ (utilisation des fichiers du conteneur sous condition de miseà disposition d’unecléd’accès valide), un rôle‘administrateur des accès’ en chargede l’initialisation du container avec affectation des accès et un rôle ‘administrateur dela sécurité’ (installation, signaturedes politiques, recouvrement en plus dela gestion des accès). Afin de remplir cet objectif :  La TOE doit gérer et distinguer les rôles administrateur dela sécurité, administrateur des accès et utilisateur de la TOE (FMT_SMR.1).  La TOE permet aussi de contrôler l’accès des utilisateurs aux conteneurs et aux opérations sur ces conteneurs (FDP_ACC.1), et de restreindre l’accès aux seuls utilisateurs possédant la clé d’accès associée (FDP_ACF.1).  Enfin, la TOE doit permettrede restreindre aux administrateurscertaines fonctions d’administrationdela sécurité (FMT_SMF.1) et la gestion des « policies » (FMT_MTD.1) ainsi quela possibilitédepouvoir utiliser ou non l’accès de recouvrement (FMT_MOF.1). 8.2.4.2. Cryptographie O.CHIFFREMENT La TOE doit chiffrer et déchiffrer les données sensibles par l’emploi declés cryptographiques. La TOE doit utiliser des clés différentes pour protéger les différents conteneurs ainsi quedes vecteurs d’initialisation différents pour chaquefichier d’un conteneur. La TOE doit générer ces clés de chiffrement conformément aux exigences pour le niveau de robustessestandard des référentiels cryptographiques [CRYPTO_STD] et [CLES_STD] de l’ANSSI. Afin de remplir cet objectif:  Pour chiffrer les fichiers présents dans un conteneur, la TOE doit tout d’abord être capable de générer les clés cryptographiques (FCS_CKM.1) et y accéder de manière sécurisée(FCS_CKM.3), afin de les utiliser pour réaliser les opérations cryptographiques selon différents algorithmes (FCS_COP.1). O.SCELLEMENT La TOE doit pouvoir contrôler l’intégritédes données sensibles (fichier de contrôle, catalogue, watermark et fichiers utilisateur) par l’emploi declés cryptographiques différentes pour chaqueconteneur. La TOE doit générer ces clés de scellement conformément aux exigences pour le niveau derobustesse standard des référentiels cryptographiques [CRYPTO_STD] et [CLES_STD] de l’ANSSI. Afin de remplir cet objectif :  Pour calculer les sceaux (HMAC) des fichiers, du watermark, du fichier decontrôleet du catalogueprésents dans un conteneur, la TOE doit tout d’abord êtrecapablede générer les clés cryptographiques (FCS_CKM.1) et y accéder de manière sécurisée (FCS_CKM.3), afin de les utiliser pour réaliser les opérations cryptographiques (FCS_COP.1).  La TOE contrôlel’intégrité des fichiers sensibles stockés dans les conteneurs et retourne une indication en cas de détection d’erreur avec interdiction d’ouvrir le fichier (FDP_SDI.2).  La TOE contrôle l’intégrité du fichier watermark stockés dans le conteneur et retourne une indication en cas de détection d’erreur avec interdiction de manipuler le fichier (FDP_SDI_WAT_EXT.2) PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 55 O.EFFACEMENT_CLES La TOE doit assurer lenettoyagedes traces dedonnées sensibles (clés de chiffrement des fichiers, éléments permettant deretrouver les clés d’accès) dans la mémoire(RAM) dès la fin des opérations réalisées par la TOE. Afin de remplir cet objectif :  La TOE permet un nettoyage totalement sécurisé des clés dans la mémoire (RAM) (FDP_RIP.1). O.ALGO_STD La TOE doit produiredes aléas et fournir un choix d’algorithmes cryptographiques et detailles declés conformes aux standards decedomaine, prévus dans [CRYPTO_STD] et complétés par [CLES_STD]. Afin de remplir cet objectif :  La TOE doit être capablede fournir un choix d’algorithmes de génération (FCS_CKM.1), d’accès (FCS_CKM.3) et de destruction (FCS_CKM.4) de clés cryptographiques.  Elle doit aussi permettred’exécuter des opérations cryptographiquesconformément à des algorithmes et tailles de clés cryptographique spécifiés (FCS_COP.1).  La TOE doit exécuter des auto tests pour vérifier le bon fonctionnement des algorithmes cryptographiques (FPT_TST.1). 8.2.4.3. Gestion O.ADM_ACCES La TOE doit offrir uneinterface à l’administrateur dela sécuritéet l’administrateur des accès permettantdevisualiser les accès et gérer les clés d’accès aux conteneurs (Zed! Edition Standard seulement). L’utilisateur peut seulement visualiser les accès. Afin de remplir cet objectif :  La TOE offre des fonctions de gestions des accès (FMT_SMF.1).  La TOE limite les accès à ces fonctions de gestion en fonction du rôle associé aux utilisateurs (FMT_SMR.1).  La TOE assureque seul l’administrateurdes accès et l’administrateur dela sécurité peuvent gérer les attributs de sécurité des objets stockés : clés et rôles (FMT_MSA.1).  La TOE garantie, de plus, que seuls des valeurs sûres sont acceptées pour les attributs desécurité, en contrôlant la force des mots de passe par exemple (FMT_MSA.2).  L’administrateur (des accès ou de la sécurité) peut aussi définir les données d’initialisation des attributs (tel quele rôle initialisé par défaut à « utilisateur ») (FMT_MSA.3). O.COMPATIBILITE La TOE doit assurer l’ouverturesécuriséedes conteneurs créés avec une ancienneversion de Zed! dont certains éléments nefaisaient pas encore l’objet d’un contrôled’intégrité. Ces éléments ne doivent pas êtremanipulés (cas du watermark). Afin de remplir cet objectif :  La TOE doit vérifier les sceaux (HMAC) des fichiers, du watermark, du fichier de contrôle et du catalogue présents dans un conteneur (FCS_COP.1) PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 56  En cas d’absence de sceau du watermark, la TOE ne traite pas le fichier et affiche le watermark par défaut (FDP_SDI_WAT_EXT.2) O.RECOUVREMENT La TOE doit permettred’affecter des clés d’accès de recouvrement (Zed! Edition Standard seulement). Afin de remplir cet objectif :  La TOE doit permettre de restreindre à l’administrateur de la sécurité (FMT_MOF.1 associé à FMT_SMR.1) l’activation ou la désactivation de la fonction de recouvrement (FMT_SMF.1).  La fonction de recouvrement est configurée dans les policies signées par l’administrateur de la sécurité (FMT_MTD.1). O.COLLECTE La TOE doit permettredecollecter de manièresécuriséedes informations utiles aux opérations desupport (Zed! Edition Standardseulement). Afin de remplir cet objectif :  La TOE doit permettre de restreindre à l’administrateur de la sécurité (FMT_MOF.1 associé à FMT_SMR.1) l’activation ou la désactivation de la fonction de collecte d’information (FMT_SMF.1).  La fonction de collecte d’information est configurée dans les policies signées par l’administrateur de la sécurité (FMT_MTD.1). O.INT_POLICIES La TOE doit vérifier la signaturede toutes nouvelles politiques desécuritéà appliquer (édition standard seulement). En cas d’échec lors dela vérification, les politiques appliquées restent inchangées. Afin de remplir cet objectif :  La TOE doit permettre d’exécuter des opérations de vérification de signature conformément aux algorithmes et tailles de clés cryptographique spécifiés (FCS_COP.1).  La TOE doit vérifier que la signature utilisée a bien été effectuée par l’administrateur de la sécurité qui est seul autorisé à modifier les politiques de sécurité (FMT_MTD.1). 8.2.5. Pertinence du niveau d’assurance Le niveau d’assuranceEAL3 augmentédes composantsALC_FLR.3 et AVA_VAN.3 associéà uneexpertisede l’implémentation dela cryptographiea étéchoisi pour assurer la conformitéau processus dequalification deniveau standard défini par l’ANSSI dans [QUALIF_STD]. Ce niveau d’assuranceimpose:  Des tests indépendants effectués par l’évaluateur (l’utilisateur final est alors assuréqueles fonctions de sécuritéde la TOE sont implémentées commespécifié)  Uneanalysede vulnérabilitéindépendante effectuée par l’évaluateur qui considèrera un niveau d'attaquant correspondant au niveau élémentairerenforcéou inférieur (l’utilisateur final est alors assuréquela TOE est PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 57 résistanteà des attaques depénétration effectuées par des attaquants possédant un faible potentiel d’attaque).  L’évaluation del’architecturedesécuritéet de l’architecturelogiciel incluant l’analysedel’implémentation (fonctions cryptographiques seulement) pour vérifier qu’il n’y a pas dedéfaut de sécurité  De bonnes pratiques en matièrededéveloppement dela partiecryptographique(l’utilisateur final est alors assuréquele produit a été correctement et sécuritairement conçu et développé).  De bonnes pratiques en matièredemaintenanceet support aux utilisateurs assurant quetoutes les anomalies identifiées seront corrigées et rapportées aux utilisateursdu produit considéréqui pourraient être affectés par cetteanomalie. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 58 8.3. Argumentaire pour les spécifications globales de la TOE Le tableau ci-dessous justifiela nécessitédes fonctions desécuritédela TOE par rapport aux composants fonctionnels CC sélectionnés : Exigences fonctionnelles de sécurité pour la TOE F.CONTROLE_ACCES F.ENTREE_SECURISEE F.CONFIGURATION_TOE F.GESTION_CLES_ACCES F.OPERATIONS_CRYPTO FCS_CKM.1 Génération de clés cryptographiques X X FCS_CKM.3 Accès aux clés cryptographiques X FCS_CKM.4 Destruction de clés cryptographiques X FCS_COP.1 Opération cryptographique X X X X X FDP_ACC.1 Contrôle d'accès partiel X X FDP_ACF.1 Contrôle d'accès basé sur les attributs de sécurité X X FDP_ITC.1 Importation depuis une zone hors du contrôle de la TSF X FDP_RIP.1 Protection d’une partie des informations résiduelles X FDP_SDI.2 Contrôle de l'intégrité des données stockées et action à entreprendre X FDP_SDI_WAT_EXT.2 Contrôle de l'intégrité du watermark et action X FIA_AFL.1 Défaillance de l'authentification X FIA_UAU.2 Authentification d’un utilisateur préalablement à toute action X X X FIA_UID.2 Identification d’un utilisateur préalablement à toute action X X X FMT_MOF.1 Administration des fonctions de la TSF X X FMT_MSA.1 Gestion des attributs de sécurité X FMT_MSA.2 Attributs de sécurité sûrs X FMT_MSA.3 Initialisation statique d’attribut X FMT_MTD.1 Gestion des données de la TSF X FMT_SMF.1 Spécification des fonctions d’administration X X X FMT_SMR.1 Rôles de sécurité X FPT_TST.1 Tests de la TSF X Tableau 12 : Couverture des exigences fonctionnelles par les spécifications globales de la TOE PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 59 FCS_CKM.1 Génération de clés cryptographiques A chaque conteneur est associéuneclé de chiffrement et déchiffrement des fichiers ainsi qu’uneclé descellement. Ces clés sont tirées lors del’initialisation du conteneur (effectuéeuniquement par l’édition standard). Elles répondent aux critères delongueurs declés configurées dans les policies. Par défaut, ce sont des clés AES de256 bits. Le format decertaines clés d’accès utilisateur (listed’accès personnelle) peut également fairel’objet d’un chiffrement intermédiairepar un bi clé RSA générée par la TOE. Le carnet de mot depasseproposedecréer un mot depasse fort pour votrecorrespondant. Commetout accès par mot depasse, ce mot de passeest ensuitediversifié pour générer la clé d’accès. La fonction desécuritéF.GESTION_CLES_ACCES implémentela génération des clés RSA et F.OPERATIONS_CRYPTO la génération des clés AES et des mots depasse(par lecarnet demot de passe). FCS_CKM.3 Accès aux clés cryptographiques L’accès aux clés cryptographiques gérées par la TOE est implémentépar la fonction desécuritéF.ENTREE_SECURISEE pour la protection des données en entrée. Cettefonction est utiliséelors detoute authentification utilisateur. FCS_CKM.4 Destruction de clés cryptographiques Lorsqu’un conteneur est supprimé, les clés cryptographiques relatives au conteneur sont détruites. Demême lorsqu’un accès est supprimé(effectuéeuniquement par l’édition standard), la cléd’accès correspondanteest détruite. La fonction desécuritéF.GESTION_CLES_ACCES implémentecetteexigencefonctionnelle. FCS_COP.1 Opération cryptographique La TOE effectue les opérations cryptographiques suivantes :  Récupère une clé d’accès avant de pouvoir créer une clé de conteneur et chiffrer le conteneur à sa création,  Récupère une clé d’accès pour déchiffrer la clé de conteneur avant de pouvoir créer un nouvel accès (il y a donc ensuite chiffrement de la clé de conteneur par la clé associée à ce nouvel accès),  Récupère une clé d’accès avant de pouvoir déchiffrer la clé de conteneur, afin de pouvoir chiffrer ou déchiffrer les fichiers du conteneur,  Récupère une clé d’accès avant de pouvoir déchiffrer la clé de scellement, afin de pouvoir sceller ou vérifier les données sensibles,  Récupère un mot de passe afin d’en dériver une clé d’accès qui va chiffrer ou déchiffrer la clé de conteneur.  Transmet la clé de conteneur chiffrée au porte-clés puis récupère la clé de conteneur déchiffrée par le porte-clés afin de pouvoir chiffrer ou déchiffrer les fichiers du conteneur.  Vérifie la signature des politiques avec le certificat de l’administrateur de sécurité  Effectue des tests au démarrage du PC et périodiquement pour vérifier le bon fonctionnement du générateur aléatoire, des algorithmes et l’intégrité du code. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 60 La fonction desécuritéF.OPERATIONS_CRYPTO, implémentent les opérations dechiffrement et déchiffrement des conteneurs, decontrôlede l’intégrité, des auto tests ainsi queles opérations cryptographiques misesau servicedes autres fonctions. Les fonctions F.GESTION_CLES_ACCES (création dela cléd’accès) et F.CONTROLE_ACCES (vérification dela clé d’accès) utilisent les fonctions dedérivation des clés à partir des mots depasse. La fonction F.ENTREE_SECURISEE utilisedes fonctions dewrapping pour assurer letransfert sécurisédes clés entrela TOE et les porte-clés physique. La fonction F.CONFIGURATION_TOE intervient pour la configuration des types d’accès et algorithmessupportés. FDP_ACC.1 Contrôle d'accès partiel Afin d’utiliser un conteneur gérépar la TOE, l’utilisateur doit impérativement présenter unecléd’accès valide, associéeau conteneur concerné. Cetteexigence de sécuritéest implémentéedans la TOE par les fonctions desécurité  F.GESTION_CLES_ACCES pour la configuration des accès au conteneur par l’administrateur  F.CONTROLE_ACCES pour le contrôle d’accès au conteneur FDP_ACF.1 Contrôle d'accès basé sur les attributs de sécurité Afin d’utiliser un conteneur gérépar la TOE, l’utilisateur doit présenter unecléd’accès valide, associéeau conteneur concerné. Pour pouvoir mettreen placece fonctionnement :  des droits et des rôles sont associés aux utilisateurs (F.GESTION_CLES_ACCES),  et l’accès aux conteneurs est donc contrôlé (F.CONTROLE_ACCES) FDP_ITC.1 Importation depuis une zone hors du contrôle de la TSF Des données nécessaires au bon fonctionnement dela TOE sont importées depuis l’extérieur dela TSF commeles clés d’accès ou les mots depassesaisis par l’utilisateur. Cenesont quedes données, aucun attribut desécuritén’est importé. La fonction desécuritéF.ENTREE_SECURISEE implémentela communication declés d’accès fournies en entrée vers la TOE, et couvredonc cette exigence. FDP_RIP.1 Protection d’une partie des informations résiduelles Cetteexigence fonctionnelleest miseen œuvrepar la fonction desécuritéF.GESTION_CLES_ACCES qui gère l’effacement sécurisédes clés en mémoire. FDP_SDI.2 Contrôle de l'intégrité des données stockéeset action à entreprendre Cetteexigence fonctionnelleest miseen œuvrepar la fonction desécuritéF.OPERATIONS_CRYPTO qui implémentent toutes les fonctions nécessaires au contrôledel’intégritédes fichiers stockés dans les conteneurs. FDP_SDI_WAT_EXT.2 Contrôle de l'intégrité du fichier watermark et action à entreprendre Cetteexigence fonctionnelleest miseen œuvrepar la fonction desécuritéF.OPERATIONS_CRYPTO qui implémentent toutes les fonctions nécessaires au contrôledel’intégrité du fichier watermark. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 61 FIA_AFL.1 Gestion d'une défaillance de l'authentification Le nombremaximum d'essai demotsdepasseou decodeconfidentiel autorisés lors del'ouvertured'un conteneur est fixé à cinq. Passéce nombre, la demanded'ouvertureest rejetée et l'utilisateur doit recommencer sa demande d’authentification (cequi leralenti entre ses différentes séquences d’essais). La fonction desécuritéF.CONTROLE_ACCES couvrecettefonctionnalité. FIA_UAU.2 Authentification d’un utilisateur préalablement à toute action Aucuneouverturedeconteneur n’est possiblesans unephasepréalabled’authentification et d’identification de l’utilisateur. Pour chaqueauthentification, les utilisateurs doivent présenter unecléd’accès valide. Cetteexigence fonctionnelleest implémentéepar :  F.CONFIGURATION_TOE pour la configuration des accès autorisés au conteneur (type d’accès, force des mots de passe, type de certificat …).  F.CONTROLE_ACCES pour le contrôle d’accès au conteneur  F.ENTREE_SECURISEE pour sécuriser la communication des données fournies en entrée vers la TOE. FIA_UID.2 Identification d’un utilisateur préalablement à toute action Aucuneouverturedeconteneur n’est possiblesans unephasepréalabled’authentification et d’identification de l’utilisateur. Pour chaqueauthentification, les utilisateurs doivent présenter unecléd’accès valide. Cetteexigence fonctionnelleest implémentéepar :  F.CONFIGURATION_TOE pour la configuration des accès autorisés au conteneur (typed’accès, typedecertificat …).  F.CONTROLE_ACCES pour le contrôle d’accès au conteneur  F.ENTREE_SECURISEE pour sécuriser la communication des données fournies en entrée vers la TOE. FMT_MOF.1 Administration des fonctions de la TSF Seul l’administrateur dela sécuritépeut activer ou désactiver les fonctions decollected’information et de recouvrement. La fonction desécuritéF.CONFIGURATION_TOE associéeà F.CONTROLE_ACCES (pour l’authentification recouvrement) implémentecetteexigence. Une politiquedesécuritéspécifique(signéepar l’administrateur dela sécurité) permet d’activer et désactiver la possibilitéd’utiliser l’accès derecouvrement ainsi que la fonction decollected’information. FMT_MSA.1 Gestion des attributs de sécurité Seuls l’administrateur des accès et l’administrateur dela sécuritéont la possibilitédechanger la valeur par défaut, modifier ou supprimer les attributsdesécurité« clés d’accès et rôle » (édition standard seulement). Cet attribut desécuritéest stockédans lefichier decontrôle, lui-mêmemasquépar Zed!. La fonction desécuritéF.GESTION_CLES_ACCES implémentecetteexigence. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 62 FMT_MSA.2 Attributs de sécurité sûrs La fonction desécurité F.CONFIGURATION_TOE (forcedes mots depasse, contrôledes certificats par exemple) permet de garantir queles attributs desécurité« cléd’accès » sont sûrs (clés d’accès gérées par l’édition standard seulement). FMT_MSA.3 Initialisation statique d’attribut La TSF permet à l’administrateur des accès ou à l’administrateur dela sécuritédespécifier des valeurs initiales alternatives aux valeurs par défaut lorsqu’un objet ou uneinformation est créé(choix du rôlepar exemple). La fonction desécuritéF.GESTION_CLES_ACCES (changement du rôlepar exemple) met en œuvre cetteexigence. FMT_MTD.1 Administration des données de la TSF Seuls l’administrateur dela sécuritéa la possibilitédegérer les stratégies desécurité(ou « policies). Cetteexigence est implémentéepar la fonction desécurité F.CONFIGURATION_TOE qui vérifiela signaturedes politiques à appliquer. FMT_SMF.1 Spécification des fonctions d’administration La TOE permet de réaliser :  Les fonctions de gestion des accès des conteneurs  La fonction de recouvrement  La fonction de collecte d’information pour le support Cetteexigence fonctionnelleest implémentéepar les fonctions desécurité F.GESTION_CLES_ACCES (gestion des accès et du recouvrement), F.OPERATIONS_CRYPTO (chiffrement des informationsrécoltées dans l’environnement) et F.CONFIGURATION_TOE (policies). FMT_SMR.1 Rôles de sécurité La TOE supporteles rôles utilisateur, administrateur des accès et administrateur dela sécurité. Cetteexigence est implémentéepar F.GESTION_CLES_ACCES qui identifieles droits administrateur et utilisateur par l’intermédiairedeleur clé s’accès. FPT_TST.1 Auto tests de la TSF Les tests cryptographiques réalisésau démarragedela TOE ou périodiquement pour vérifier lebon fonctionnement du générateur aléatoire et la conformitédes algorithmes est assurépar F.OPERATIONS_CRYPTO. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 63 8.4. Argumentaire pour les annonces de conformité à un PP Cettecible de sécuriténedéclare aucuneconformitéà un Profil deProtection. Aucun argumentairen’est donc requis. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 64 ANNEXE A : EXIGENCES FONCTIONNELLES DE SECURITE DE LA TOE Cetteannexe contient les textes officiels de la partie2 des Critères Communs en version 3.1 d’avril 2017 avec l’ensembledes opérations réalisées pour la TOE. Les composants fonctionnelsCC sélectionnés pour répondreaux objectifs desécuritédela TOE sont les suivants : Composants CC retenus FCS_CKM.1 Cryptographic key generation FCS_CKM.3 Cryptographic key access FCS_CKM.4 Cryptographic key destruction FCS_COP.1 Cryptographic operation FDP_ACC.1 Subset access control FDP_ACF.1 Security attributebased access control FDP_ITC.1 Import of user data without security attributes FDP_RIP.1 Subset residual informationprotection FDP_SDI.2 Stored data integrity monitoring and action FDP_SDI_WAT_EXT.2 Watermark integrity monitoring and action FIA_AFL.1 Authentication failurehandling FIA_UAU.2 User authentication beforeany action FIA_UID.2 User identification beforeany action FMT_MOF.1 Management of security functions behaviour FMT_MSA.1 Management of security attributes FMT_MSA.2 Secure security attributes FMT_MSA.3 Static attributeinitialisation FMT_MTD.1 Management of TSF data FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security roles FPT_TST.1 TSF testing Tableau 13 : Exigences fonctionnelles de sécurité pour la TOE PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 65 9.1. Class FCS : Cryptographic support FCS_CKM Cryptographic key management FCS_CKM.1 Cryptographic key generation FCS_CKM.1.1 The TSF shall generatecryptographic keys in accordancewith a specified cryptographic key generation algorithm [ - génération de nombres pseudo-aléatoires utilisés pour la génération des clés de chiffrement et des clés RSA de listes d’accès en utilisant les générateurs Hash_DRBG, HMAC_DRBG ou CTR_DRBG décrit dans la publication « Recommendation for Random Number Generation Using Deterministic Random Bit Generators » (référence SP 800-90A révision 1) du NIST ; - diversification de clés PKCS#5 à partir des mots de passe - Génération de mot de passe par le carnet de mot de passe pour en dériver une clé] and specified cryptographic key sizes [de 128, 192et 256bits pour les clés symétriques et de 2048 bits à 4096 bits pour les clés asymétriques] that meet thefollowing: [exigences cryptographique de l’ANSSI définies dans [CRYPTO_STD] et [CLES_STD]]. Non editorial refinement: L’édition limitée n’effectue que la diversification de clés pour obtenir la clé d’accès de l’utilisateur à partir de son mot de passe. FCS_CKM.3 Cryptographic key access FCS_CKM.3.1 The TSF shall perform [l’utilisation de clés] in accordance with a specified cryptographic key access method [utilisation du driver clavier et déchiffrement (déwrapping) des clés par la clé d’accès] that meets thefollowing: [Aucun]. Raffinement non éditorial : Ce composant s’applique en totalité à l’édition standard qui réalise notamment toutes les fonctions d’administration sensibles. Par contre, l’édition limitée ne contient pas de driver clavier et utilise exclusivement la fonction de déchiffrement des clés. FCS_CKM.4 Cryptographic key destruction FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordancewith a specified cryptographic key destruction method [réécriture de motifs composés de zérossuivi par une opération de lecture-vérification. Si la lecture-vérification de la réécriture échoue, le processus doit être répété] that meets thefollowing: [Aucun]. FCS_COP Cryptographic operation FCS_COP.1 Cryptographic operation FCS_COP.1.1 The TSF shall perform [le hachage, le calcul et la vérification d’intégrité, le chiffrement, le déchiffrement, la vérification de la signature des politiques de sécurité, la génération de clés, le wrapping et dewrapping de clés et la dérivation de clés] in accordance with a specified cryptographic algorithm[HMAC, SHA-256et SHA-512, RSA PKCS#1 v2.2, AES mode CBC] and cryptographic key sizes [de 128, 192 et 256 bits pour les clés symétriques et de 2048 bits pour les clés asymétriques] that meet thefollowing: [exigences cryptographique de l’ANSSI définies dans [CRYPTO_STD] et [CLES_STD]]. Non editorial refinement: L’édition limitée ne permet que le chiffrement et déchiffrement desfichiers ainsi que le dewrapping de clé, la dérivation de clé et la fonction de hachage associée. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 66 9.2. Class FDP : User data protection FDP_ACC Access control policy FDP_ACC.1 Subset access control FDP_ACC.1.1 The TSF shall enforce the[SFP.ACCESS_OBJ] on [ Sujets: Administrateur et utilisateurs de la TOE Objets: Conteneurscontenant les fichiers utilisateur et le fichier de contrôle. Opérations : Gestion des conteneurs et utilisation]. FDP_ACF Access control functions FDP_ACF.1 Security attributebased access control FDP_ACF.1.1 The TSF shall enforce the[SFP.ACCESS_OBJ] to objects based on thefollowing: [ Sujets: Administrateur et utilisateurs de la TOE Attributs de sécurité : Clés d’accès utilisateur permettant ou non d’ouvrir le conteneur et rôle] Raffinement non éditorial : Il n’y a pas de rôle administrateur dans l’édition limitée, cette édition ne gère que le rôle utilisateur. FDP_ACF.1.2 The TSF shall enforce thefollowing rules to determineif an operation among controlled subjects and controlled objects is allowed: [ Objet : Conteneur Opération: Gestion des conteneurs et utilisation Règle : authentification réussie après mise à disposition de la clé d’accès associée au conteneur concerné avec accès à la gestion du conteneur uniquement pour le rôle administrateur des accès (gestion des accès) et administrateur de la sécurité (toute opération de gestion)]. FDP_ACF.1.3 The TSF shall explicitly authoriseaccess of subjects to objects based on the following additional rules: [Aucune]. FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [Aucune]. FDP_ITC Import from outside TSF control FDP_ITC.1 Import of user data without security attributes FDP_ITC.1.1 The TSF shall enforce the[SFP.ACCESS_OBJ] when importing user data, controlled under theSFP, from outsideof theTOE. FDP_ITC.1.2 The TSF shall ignoreany security attributes associated with theuser data when imported from outsidetheTOE. FDP_ITC.1.3 The TSF shall enforce thefollowing rules when importing user data controlled under the SFP from outsidetheTOE: [Aucune]. FDP_RIP Residual information protection FDP_RIP.1 Subset residual informationprotection FDP_RIP.1.1 The TSF shall ensurethat any previous information content of a resourceis made unavailableupon the[désallocation de la ressource de] thefollowing objects: [clés de chiffrement des conteneurs et clés d’accès]. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 67 FDP_SDI Stored data integrity FDP_SDI.2 Stored data integrity monitoring and action FDP_SDI.2.1 The TSF shall monitor user data stored in containers controlled by theTSF for [erreurs d'intégrité] on all objects, based on thefollowing attributes: [HMAC pour chaque fichier calculé à partir du contenu et de certaines propriétés techniques de ces fichiers]. FDP_SDI.2.2 Upon detection of a data integrity error, theTSF shall [retourner un message d’erreur et interdire l’ouverture du fichier]. Raffinement non éditorial : Le contrôle s’effectue au moment de l’ouverture du fichier du conteneur. FDP_SDI_WAT_EXT.2 Watermark integrity monitoring and action FDP_SDI_WAT_EXT.2.1 TheTSF shallmonitorwatermark filestoredincontainerscontrolledbytheTSF for [erreurs d'intégrité] on all objects, based on the following attributes: [HMAC calculé à partir du contenu du fichier watermark]. FDP_SDI_WAT_EXT.2.2 Upon detection of a watermark integrity error, theTSF shall [retourner un message d’erreur et interdire la manipulation du fichier]. FDP_SDI_WAT_EXT.2.3 Upon absenceof HMAC for thewatermark, theTSF shall [afficher le watermark par défaut contenu dans la librairie Zed!]. Raffinement non éditorial : Les anciennes versions de Zed ! n’effectuaient pas de contrôle d’intégrité du watermark. 9.3. Class FIA : Identification and authentication FIA_AFL Authentication failures FIA_AFL.1 Authentication failurehandling FIA_AFL.1.1 The TSF shall detect when [cinq] unsuccessful authentication attempts occur related to [l’ouverture d’un conteneur]. FIA_AFL.1.2 When the defined number of unsuccessful authenticationattempts has been met or surpassed, theTSF shall [temporiser l’accès à ce conteneur]. FIA_UAU User authentication FIA_UAU.2 User authentication beforeany action FIA_UAU.2.1 The TSF shall requireeach user to be successfully authenticated beforeallowing any other TSF-mediated actions on behalf of that user. FIA_UID User identification FIA_UID.2 User identification beforeany action FIA_UID.2.1 The TSF shall requireeach user to be successfully identified beforeallowing any other TSF- mediated actions on behalf of that user. 9.4. Class FMT : Security management FMT_MOF Management of functions in TSF PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 68 FMT_MOF.1 Management of security functions behaviour FMT_MOF.1.1 The TSF shall restrict theability to [activer ou désactiver] thefunctions [collecte d’information et recouvrement]to [administrateur de la sécurité]. Raffinement non éditorial : Ce composant ne s’applique qu’à l’édition standard (l’édition limitée ne permet pas d’effectuer d’opérations de gestion). FMT_MSA Management of security attributes FMT_MSA.1 Management of security attributes FMT_MSA.1.1 The TSF shall enforce the[SFP.ACCESS_OBJ]to restrict theabilityto [changer la valeur par défaut, modifier ou supprimer] thesecurity attributes [clés d’accès et rôles] to [administrateur des accès et administrateur de la sécurité]. Non editorial refinement: Ce composant ne s’applique qu’à l’édition standard (l’édition limitée ne permet pas de gérer les accès). FMT_MSA.2 Secure security attributes FMT_MSA.2.1 The TSF shall ensurethat only securevalues areaccepted for [clés d’accès]. Non editorial refinement: Ce composant ne s’applique qu’à l’édition standard (l’édition limitée ne permet pas de gérer les accès). FMT_MSA.3 Static attributeinitialisation FMT_MSA.3.1 The TSF shall enforce the[SFP.ACCESS_OBJ] to provide[restrictive] default values for security attributes thatareused to enforcetheSFP. FMT_MSA.3.2 The TSF shall allow the[administrateur des accès et administrateur de la sécurité] to specify alternativeinitial values to overridethedefault values when an object or information is created. Non editorial refinement: Ce composant ne s’applique qu’à l’édition standard (l’édition limitée ne permet pas de gérer les accès). FMT_MTD FMT_MTD.1 Management of TSF data Management of TSF data FMT_MTD.1.1 The TSF shall restrict theability to [changer la valeur par défaut, modifier ou supprimer] the[stratégies de sécurité] to [administrateur de la sécurité]. Raffinement non éditorial : Ce composant est implémentépar la signature des politiques de sécurité, il ne s’applique qu’à l’édition standard (l’édition limitée ne permet pas d’effectuer d’opérations de gestion). FMT_SMF Specification of Management Functions FMT_SMF.1 Specification of Management Functions FMT_SMF.1.1 The TSF shall be capableof performing thefollowing management functions: [ - Les fonctions de gestion des accès - La fonction de recouvrement - La fonction de collecte d’information pour le support] PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 69 Non editorial refinement: L’édition limité ne permet pas de gérer les accès et d’affecter des clés de recouvrement. FMT_SMR Security management roles FMT_SMR.1. Security roles FMT_SMR.1.1 The TSF shall maintain theroles [administrateur de la sécurité, administrateur des accès et utilisateur de la TOE]. FMT_SMR.1.2 The TSF shall be ableto associateusers with roles. 9.5. Class FPT: Protection of the TSF FPT_TST.1 TSF self test FPT_TST.1 TSF testing FPT_TST.1.1 The TSF shall run a suiteof self tests [during initial start-up, periodically during normal operation] to demonstratethecorrect operation of [the TSF]. FPT_TST.1.2 The TSF shall provideauthorised users with thecapabilityto verify theintegrityof [no parts of TSF data]. FPT_TST.1.3 The TSF shall provideauthorised users with thecapabilityto verify theintegrityof [no parts of TSF]. PRIMX-Zed! Q.2020 Cible de sécurité (PX185856r8).docx 70 ANNEXE B : DEFINITION DE COMPOSANTS ETENDUS 10.1. Watermark integrity (FDP_SDI_WAT_EXT) Family Behavior This family addresses therequirements protection of watermarkfiles stored within containers controlled by theTSF Component leveling FDP_SDI_WAT_EXT Extended:Watermark integrity 2 FDP_SDI_WAT_EXT.2 Extended: Watermark integrity monitoring, requires that theTSF monitor watermarkfiles stored within containers controlled by theTSF for identified integrity errors. Management: FDP_SDI_WAT_EXT.2 The following actions could beconsidered for themanagement functions in FMT: a) No management functions. FDP_SDI_WAT_EXT.2 Extended: Watermark integrity monitoringand action Hierarchical to: No other components. Dependencies: No dependencies. FDP_SDI_WAT_EXT.2.1 The TSF shall monitor watermark stored in containers controlled by theTSF for [assignment: integrity errors] on all objects, based on thefollowing attributes: [assignment: watermark attributes]. FDP_SDI_WAT_EXT.2.2 Upon detection of a watermark integrity error, theTSF shall [assignment: actionto be taken]. FDP_SDI_WAT_EXT.2.3 Upon absenceof HMAC for thewatermark, theTSF shall [assignment: action to be taken].