Système de Collecte de Vote Pré-AG

Système de Collecte de Vote Pré-AG CH06 - Technique et sécurité Spécifications fonctionnelles générales Version 1.10 www.slib.com

SUIVI DU DOCUMENT Version Nature Chapitre Auteur Date 1.0 Création du document Tous SLIB 05/07/2010 1.1 Revue suite Réunion CH06 Tous SLIB 05/07/2010 1.4 Mise à jour générale du document Tous SLIB 15/10/2010 - Clarification des attributs du transfert de session 5.1.6.3 1.5 - Ajout d un exemple de formulaire de transfert de session 5.1.6.4 SLIB 22/10/2010 - Précisons sur les attributs des métadonnées du transfert de fichier 5.2.5.1 - Ajout des URL d accès aux postes TCC/centralisateur/administrateur 3.4.1 - Ajout recommandations navigateurs 3.4.1 - Modifications des URL (production et homologation) d accès au frontal de vote 5.1 - Précisions sur la codification des numéros de série. Jusqu à 32 octets (64 chiffres hexadécimaux) sont prévus, mais les n de série des certificats du Système sont représentés sur 16 octets (32 caractères hexadécimaux) 5.1.6.3 5.2.5.1 1.6 - Le formalisme d identification des participants dans les métadonnées est identique à celui des SFG du chantier 2 (découplage du type de codification et du code choisis par le participant) 2.1 5.1.6.4 5.2.5.1 SLIB 17/11/2010 - Correction de l exemple XML d un fichier metadata 5.2.5.1 - Ajout d un exemple XML d acquittement technique 5.2.5.2 - Ajout d un exemple XML de compte rendu quotidien 5.2.5.3 - Ajout d un numéro de version (tag XML Vrsn) dans tous les types de fichiers xml (fichier de données, acquittement technique et compte rendu quotidien) 5.2.5.2 5.2.5.3 2/79

Version Nature Chapitre Auteur Date - Dans les règles de nommage des fichiers d échange, les flux dédiés à l homologation sont identifié par le caractère H en 4 ème position, et non par le caractère R comme indiqué à tort précédemment 5.2.4.1 5.2.4.2 - Dans le message d acquittement technique, la longueur maximale de la description de l erreur passe de 350 à 1024 caractères 5.2.3 - Compléments sur le poste administrateur. En particulier, le poste administrateur est soumis au même mécanisme d habilitations que les autres postes (distinction de la fonction d administration des utilisateurs et de gestion des certificats) 6 - Diffusion de la liste des codes erreur, retournés dans le message d acquittement technique Annexe 4 - Diffusion de la liste des fonctions élémentaires disponibles pour la définition des rôles et des habilitations Annexe 5 - Préconisations techniques pour l utilisation du frontal de vote en ligne et pour l utilisation des postes TCC, Centralisateur et Administrateur 3.4.1 - Correct on : la balise décrivant le type de fichier s appelle <FileTp> et non FileTyp comme indiqué précédemment par erreur 5.2.5.1, 5.2.5.2 Annexe 4 - Ajout de la version dans le compte rendu quotidien 5.2.5.3 1.7 - Le séparateur entre le nom de domaine et le login user est \, et non / comme indiqué précédemment par erreur 2.1 SLIB 17/01/2011 - Correction de l exemple de transfert de session 5.1.6.4 - Précision sur les particularités liées au transport des images 5.2.5 5.2.8 - Complétion de la liste des codes de rejet Annexe 4 - Explications sur les périodes de recouvrement de certificats et mécanisme de notification d expiration de certificat 2.5.5 1.8 - Le timeout (délai maximal d émission de 5.2.3 SLIB 18/03/2011 3/79

Version Nature Chapitre Auteur Date l acquittement par le destinataire) est précisé à 30 minutes - Correction dans le descriptif de l erreur F0017 Annexe 4 - Pour certains cas d erreur, modification des règles d incrémentation du numéro de séquence attendu 5.2.5 Annexe 4 - Précisions sur la notion de vacation 5.2.7.1 - Précision sur les navigateurs qualifiés & recommandés 3.4.1 - Afin de faciliter le traitement des anomalies, ajout du numéro de séquence attendu dans l acquittement technique - Afin de contrôler au plus tôt la prise en compte d un nouveau certificat, la plate-forme transmettra au participant un fichier vide crypté avec le certificat qui vient d être activé 5.2.5 5.2.5.2 2.5.5 - SndgMsgDtAndTm obligatoire 5.1.6.3 - Dans les métadonnées d un fichier émis par le Système, ajout d un tag précisant le rôle (TCC ou Centralisateur) du destinataire. Quand un participant tient les 2 rôles, ce tag lui permet de distinguer si les rejets concernent la fonction TCC ou Centralisateur. 5.2.5.1 1.9 -Suppression du numéro de séquence attendu dans l acquittement technique 5.2.5 5.2.5.2 SLIB 11/07/2011 - Précision sur les navigateurs qualifiés & recommandés 3.4.1 -Ajout des fonctions élémentaires du poste Administrateur Annexe 5 -Ajout des codes d erreurs spécifiques au transfert de session Annexe 6 1.10 - Dans l acquittement et le compte-rendu quotidien émis par le Système, ajout d un tag précisant le rôle (TCC ou Centralisateur) du destinataire. Quand un participant tient les 2 rôles, ce tag lui permet de distinguer si l acquittement (ou le compte-rendu quotidien) concerne la fonction TCC ou Centralisateur. 5.2.5.2 5.2.5.3 SLIB 22/12/2011 - Correction de deux coquilles dans l exemple de 5.1.6.4 4/79

Version Nature Chapitre Auteur Date transfert de session - Nouvelles règles de gestion pour l agrégation des messages au sein d un fichier, relatives à la taille limite imposée par l API de cryptage en mémoire. Utilisation optionnelle de l API de cryptage sur disque. - Mise à jour des versions de navigateurs recommandées et supportées - Ajout d un paragraphe sur les possibilités de compression des données échangées sur le réseau - Description des API de cryptage/décryptage 5.2.6 3.4.1 5.2.9 Annexe 7 5/79

SOMMAIRE 1 Principes généraux... 9 1.1 Sécurité des échanges... 9 1.2 Services délivrés... 9 1. 2. 1 S e r v i c e : A c c è s I n t e r a c t i f s... 9 1. 2. 2 S e r v i c e : T r a n s f e r t d e d o n n é e s... 9 2 Participants au système... 10 2.1 Identification des Participants... 10 2.2 Formulaire de raccordement au système... 11 2.3 Profil Administrateur... 11 2.4 Éléments d identification des participants... 11 2. 4. 1 C e n t r a l i s a t e u r... 11 2. 4. 2 T e n e u r d e c o m p t e... 11 2. 4. 3 D i s t r i b u t e u r... 12 2.5 Gestion des certificats... 12 2. 5. 1 L e s a u t o r i t é s d e c e r t i f i c a t i o n... 13 2. 5. 2 R e n o u v e l l e m e n t d e s c e r t i f i c a t s... 13 2. 5. 3 C o n s e r v a t i o n d e s c e r t i f i c a t s... 13 2. 5. 4 V é r i f i c a t i o n d e s c e r t i f i c a t s... 14 2. 5. 5 C h r o n o l o g i e d e s c e r t i f i c a t s... 14 2.6 Éléments d identification d un Teneur de Compte Final (TCF)... 16 2.7 Identification et Authentification des utilisateurs... 16 2. 7. 1 C r é a t i o n d ' u n i d e n t i f i a n t u t i l i s a t e u r... 16 2.8 Gestion des habilitations utilisateurs... 18 2.9 Gestion de la confidentialité... 18 2. 9. 1 G e s t i o n d e l a c o n f i d e n t i a l i t é p o u r u n c e n t r a l i s a t e u r... 19 2. 9. 2 G e s t i o n d e l a c o n f i d e n t i a l i t é p o u r u n T C C... 19 3 Architecture de Raccordement... 20 3.1 Accès Internet... 20 3.2 Accès BT-Radianz... 20 3.3 Critères de choix d une offre de raccordement... 20 3. 3. 1 M o d e d e t r a n s f e r t d e d o n n é e s... 21 3.4 Procédure de raccordement... 22 6/79

3. 4. 1 A c c è s a u x s e r v i c e s i n t e r a c t i f s... 22 3. 4. 2 P h a s e d e c o n f i g u r a t i o n... 23 3.5 Test de raccordement... 23 4 Cryptage et signature des échanges... 24 5 Echanges de données... 27 5.1 Transfert de session (redirection et cryptage des informations)... 29 5. 1. 1 S i t e w e b d u d i s t r i b u t e u r... 30 5. 1. 2 A u t h e n t i f i c a t i o n... 30 5. 1. 3 T r a i t e m e n t d e s R e j e t s... 30 5. 1. 4 M o d e d e t r a n s f e r t e t t r a n s p o r t d e s d o n n é e s... 31 5. 1. 5 T r a ç a b i l i t é d u t r a n s f e r t d e c o n n e x i o n... 31 5. 1. 6 E l é m e n t s t e c h n i q u e s... 32 5.2 Transfert de fichier... 35 5. 2. 1 T y p o l o g i e d e f i c h i e r s é c h a n g é s... 35 5. 2. 2 F i c h i e r X m l : C a r a c t è r e s a u t o r i s é s... 36 5. 2. 3 A c q u i t t e m e n t s d e s é c h a n g e s d e d o n n é e s... 36 5. 2. 4 C o n v e n t i o n d e n o m m a g e e t d e s t o c k a g e d e s f i c h i e r s é c h a n g é s... 36 5. 2. 5 P r o t o c o l e d é c h a n g e... 38 5. 2. 6 A g r é g a t i o n d e s d o n n é e s... 49 5. 2. 7 F r é q u e n c e s e t h o r a i r e s d e s t r a n s f e r t s d e f i c h i e r s... 50 5. 2. 8 C a s p a r t i c u l i e r d e s i m a g e s d u v o t e n u m é r i s é... 52 5. 2. 9 C o m p r e s s i o n d e s d o n n é e s... 52 6 Poste administrateur... 54 6.1 Certificats utilisés dans les transferts de fichiers... 55 6.2 Déclarations TCF... 56 6.3 Déclarations Site Web du distributeur... 56 6.4 Contacts... 57 6.5 Gestion des rôles... 57 6.6 Gestion des utilisateurs... 58 6.7 Confidentialité TCC... 58 6.8 Piste d audit... 58 Annexes... 60 Annexe 1 Liste Noire.... 60 Annexe 2 Liste des identifiants d échanges de fichiers :... 61 7/79

Annexe 3 Eléments techniques de cryptage... 62 Annexe 4 Liste des codes erreur pour l acquittement... 66 Annexe 5 Fonctions élémentaires... 71 Annexe 6 Liste des codes erreur pour le transfert de session... 75 Annexe 7 API de cryptage/décryptage... 76 8/79

1 Principes généraux 1.1 Sécurité des échanges La sécurité est un élément clé du Système d échange mis en place. Le système impose des exigences de sécurité et des contrôles lors du raccordement d un participant au travers d un réseau étendu (public ou privé). Ces exigences de sécurité couvrent plusieurs domaines : - Disponibilité (performances des connexions et continuité de service en cas d incident) - Intégrité des paramètres de connexion et traçabilité des connexions - Confidentialité des paramètres de connexion et des données qui transitent Cela concerne le périmètre suivant : - les règles de connexion physique (raccordement infrastructure site principal et site secondaire) - les exigences en termes de connexion logique (cryptographie, filtrage, cloisonnement) - les règles d'authentification des utilisateurs distants via les réseaux publics (SSL, VPN,...) Le prestataire n étant pas opérateur de réseau, il n assure pas de fonctions de passerelle réseau entre les participants connectés au Système de vote pré assemblée générale. Le prestataire s appuie d une part sur des protocoles standards du marché et d autre part sur des intégrateurs de réseau. Dans le cadre de la continuité de service, SLIB dispose de deux sites de production (site principal et site secondaire) et fournit un point de raccordement réseau sur chacun de ces sites. Il est de la responsabilité du participant de choisir une architecture de raccordement. L objectif est de garantir l authenticité des participants se connectant au système de vote Pré-AG : - Par une identification formelle des extrémités (type LS), - Par la mise en place de mécanismes d authentification (exemple via des certificats délivrés par une autorité de certification reconnue). 1.2 Services délivrés Le Système d information et de collecte de votes Pré-AG réunit 2 types de services 1.2.1 Service : Accès Interactifs Quatre applications sont disponibles en interactif Accès public au frontal de vote Pré-AG en https avec un navigateur du marché. Poste Centralisateur (création des Assemblées Générales, contrôle des échanges, ) Poste TCC (récupération de données des Assemblées Générales, contrôles des échanges, etc...) Poste administrateur (administration des utilisateurs, déclaration des sites Web du teneur de compte, gestion des certificats,..) 1.2.2 Service : Transfert de données Le service est assuré via une plateforme d échanges capable de restituer les informations de manière multiprotocoles / multi-modes (push / pull). 9/79

2 Participants au système Trois types de participant sont identifiés : Centralisateur TCC Prestataire technique du TCC Le Participant doit avoir signé un contrat avec SLIB pour l utilisation du Système. 2.1 Identification des Participants Un Participant est identifié dans le Système par un code Participant validé par SLIB. Ce code participant sera attribué par le Système au cas où le participant ne disposerait ni d un code Interbancaire, ni d un code Euroclear, ni d un code BIC. Un établissement qui contribue au Système pour les deux rôles de teneur de compte et de Centralisateur doit être déclaré auprès du système pour chacun des deux. Dans les métadonnées qui encapsulent soit le transfert de session, soit les échanges de données par fichier, le format XML de l identifiant est identique à celui du chantier 2, composé de deux tags XML : Donnée Type Descriptif Nom ISO Tag XML Type de codification Enumération Valeurs possibles : BICC : codification BIC CCIB : codification interbancaire ECLC : codification Euroclear SYSC : codification propre au Système. L identifiant est attribué par le Système PartyIdentificationCode PtyIdCd Identifiant A(12) Identifiant dans le Système de codification choisi Code Cd Le Système possède l identifiant «VOTACCESS» dans la codification propre au Système. Il figure systématiquement dans le champ «Identifiant de l émetteur» de la partie métadonnée des fichiers émis par le Système. Les actionnaires transférés sur le frontal de vote par les sites Web des teneurs de compte pour exprimer leurs instructions de vote sont authentifiés par le site Web de départ. Ce site Web est par ailleurs déclaré par l administrateur du TCC. Un participant dispose de deux autres attributs d identification : Un code technique sur 3 chiffres, utilisé dans la construction des identifiants de fichier (voir 5.2.4). Ce numéro est exclusivement attribué par le Système. Il est communiqué au participant dans le formulaire RF02. Un nom de domaine, sur 4 caractères alphanumériques. Ce nom permet au Système de s affranchir d éventuels problèmes d homonymie des identifiants utilisateur. Quand un utilisateur se connecte sur une des applications du Système, il doit préfixer son identifiant de ce nom de domaine suivi 10/79

d un caractère \. Ce nom est choisi par le participant (Formulaire RF01), sous réserve qu il ne soit pas déjà attribué. 2.2 Formulaire de raccordement au système Le document de raccordement (formulaire RF01) au système est transmis au service d enregistrement de SLIB pour validation. Il doit être complété et validé par le participant. Le formulaire permet au participant d indiquer : Son identifiant, utilisé dans les échanges fonctionnels Le mode de raccordement retenu (principal et secours), à choisir entre BT Radianz et internet Le protocole de transfert de fichier Différents contacts techniques ou fonctionnels L identifiant de l administrateur L inscription des nouveaux participants est validée par le comité exécutif lors sa réunion périodique. En retour, le participant recevra dans un autre formulaire (formulaire RF02) les éléments de configuration lui permettant d accéder au système Le participant devra retourner ce formulaire en précisant : Les informations techniques de raccordement (nom du partenaire, adresse IP, etc.) Pour chaque flux, les fréquences horaires (cf. 5.2.7.2) Les formulaires sont spécifiques selon le rôle du participant et les protocoles techniques utilisés. Un établissement tenant à la fois le rôle de TCC et de Centralisateur doit remplir deux formulaires RF01 et deux formulaires RF02. 2.3 Profil Administrateur Après son inscription auprès du système de vote, le Participant recevra un profil administrateur pour se connecter à la console d administration (cf. 6). 2.4 Éléments d identification des participants Ces informations seront initialisées par le service d enregistrement de SLIB à partir des formulaires papier d inscription au Système, puis finalisées et maintenues par l administrateur du participant. 2.4.1 Centralisateur Les informations que devra renseigner l administrateur du Centralisateur sont au minimum : Un certificat (voir 2.5). Le certificat est utilisé pour l échange des flux de données entre le système et le centre de traitement du Centralisateur. plusieurs adresses e-mail. Elles seront nécessaires pour communiquer avec le participant, par exemple lors de l expiration des certificats. 2.4.2 Teneur de compte Les informations que devra renseigner l administrateur du Teneur de compte sont au minimum : Un certificat (voir 2.5) Le certificat est utilisé pour l échange des flux de données entre le système et le centre de traitement du TCC. 11/79

plusieurs adresses e-mail. Elles seront nécessaires pour communiquer avec le participant, par exemple lors de l expiration des certificats. 2.4.3 Distributeur Chaque site web de distributeur est déclaré par l administrateur du TCC. L administrateur peut choisir l identifiant du site Web (dans l une des trois codifications autorisées) ou laisser le système attribuer un identifiant unique dans la codification Système. Dans ce dernier cas, l identifiant doit être communiqué par l administrateur du TCC au responsable du site web. Pour chaque site web, l administrateur devra en outre fournir au système un certificat. Ce certificat sera en principe communiqué à l administrateur du TCC par le responsable du site web. Inversement, l administrateur du TCC devra communiquer au responsable du site web le certificat du Système, disponible sur le poste administrateur. Pour chaque site web, l administrateur devra en outre fournir au système un contact technique du distributeur. Ce contact technique (notamment l adresse mail) est utilisé dans la gestion des erreurs au niveau du transfert de session. Voir 5.1.3 L identifiant figure dans les informations communiquées par le site web au frontal de vote lors du transfert de session. Le certificat est nécessaire à l authentification par le système des informations transmises lors du transfert de session. 2.5 Gestion des certificats Les certificats sont utilisés pour chiffrer et authentifier les échanges entre le système et : les serveurs des participants Le site web du distributeur et le frontal de vote en ligne La gestion des certificats repose sur les mêmes principes que la gestion des certificats de serveurs SSL. L administrateur du participant fournit au système les certificats sous forme d un fichier téléchargé (upload) depuis l interface d administration. Ce certificat contient la clé publique utilisée par le système pour, à la réception d un flux de donnée ou d un transfert de session, décrypter et vérifier la signature du participant. Le fichier peut être au format texte (norme RFC1421, suffixes «.pem», «.crt», «.cer») ou binaire (norme ITU X.690, suffixe «.der»). Inversement, l administrateur du participant récupère le certificat du système en téléchargeant un fichier depuis le poste d administration. Ce certificat est utilisé par le participant pour décrypter et vérifier la signature du Système. Le certificat du Système est délivré au format texte (norme RFC1421, suffixe «.cer»). Les certificats sont des certificats électroniques X509, V3. Pour des questions de sécurité, le système dispose de certificats séparés pour la plate forme de production et la plate forme d homologation. Il est recommandé aux participants d appliquer la même logique. Néanmoins, le système ne vérifie pas l unicité des certificats communiqués par les participants. 12/79

2.5.1 Les autorités de certification Une Autorité de certification (AC ou CA) a pour mission, après vérification de l'identité du demandeur du certificat par une autorité d'enregistrement, de signer, émettre et maintenir : les certificats les listes de révocation (CRL : Certificate Revocation List) Le système acceptera les certificats émis par les autorités de certifications suivantes : Thawte Verisign Certinomis TBS KEYNECTIS 2.5.2 Renouvellement des certificats Chaque participant aura à sa charge la gestion de ses propres clés, et particulièrement le renouvellement en cas d expiration ou de compromission. Coté système Le système renouvelle ses certificats à date fixe, tous les ans. A partir du 15 janvier, le nouveau certificat sera disponible pour téléchargement à partir du poste administrateur. Un mail de notification est envoyé aux adresses mail de contacts du participant pour l avertir de la mise à disposition du nouveau certificat. Le nouveau certificat est activé le 31 janvier (00h00) de chaque année. Le participant doit utiliser le certificat correspondant au numéro de série communiqué par le Système dans les métadonnées. La bascule de l ancien vers le nouveau certificat est transparente. Coté Participants Le Système utilise le certificat correspondant au numéro de série communiquée par le participant dans les métadonnées (cf. 5.2.5.1). Si le participant renouvelle ses clés, l opération est transparente pour le Système. Le Système rejette un fichier si le certificat correspondant au numéro de série transmis dans les métadonnées a expiré ou a été révoqué. D une manière générale, dans les échanges de fichier cryptés, l émetteur doit systématiquement faire figurer dans les métadonnées les numéros de série des certificats utilisés pour crypter les données : Numéro de série du certificat de l émetteur Numéro de série du certificat du destinataire Le numéro de série lève toute ambiguïté sur le certificat que doit utiliser le destinataire pour décrypter le fichier reçu. 2.5.3 Conservation des certificats Le système conserve dans un historique tous les certificats, les siens ainsi que ceux des participants. Ce stockage est nécessaire au contrôle a posteriori de la validité des données échangées en cas d audit. Le Système archive les fichiers de données cryptés pendant trois avec le numéro de série du certificat utilisé pour le décrypter afin de le traiter. 13/79

2.5.4 Vérification des certificats Quand le système récupère un certificat transmis par l administrateur du participant, le système contrôle, à partir d attributs figurant dans le certificat, les éléments suivants : date de validité. accès à la liste de révocation de l autorité de certification De manière régulière, le Système effectuera un contrôle de validité de clés. Le Système prévient les participants de l expiration prochaine d un certificat. Dans les 30 jours précédant l expiration d un certificat, si aucun nouveau certificat valide n a été transmis, un courriel est envoyé aux adresses e-mail de contacts techniques du participant. 2.5.5 Chronologie des certificats Un certificat est caractérisé par les éléments chronologiques suivants : Une période de validité, définie par une date de début de validité et une date de fin de validité (ou date d expiration). La période de validité est une propriété intrinsèque du certificat, attribuée par l organisme de certification. Une date d activation. La date d activation est paramétrée dans le système. La date d activation des certificats du Système est positionnée au 31 janvier de chaque année. La date d activation des certificats d un participant est spécifiée par l administrateur du participant, via la console d administration. Le Système vérifie que la date d activation d un certificat se situe pendant la période de validité du certificat. Plusieurs certificats (en général deux) peuvent être valides simultanément. La période pendant laquelle au moins deux certificats sont valides simultanément est appelée période de recouvrement. En revanche, un seul certificat peut être actif à un moment donné. La date d activation d un certificat doit être placée pendant la période de recouvrement. Quand le Système crypte un fichier, il utilise : Son certificat actif Le certificat actif du participant Le participant qui crypte vers le Système (soit pour du transfert de données, soit lors du transfert de session) a la possibilité d utiliser : Un des certificats valides du Système Un de ses certificats valides Dans tous les cas, les numéros de série des deux certificats utilisés sont transmis dans les métadonnées du fichier transmis (voir 5.1.6.3 et 5.2.5.1). Dès l activation d un nouveau certificat, le Système transmettra au participant un fichier vide, afin de vérifier au plus tôt la bonne prise en compte du nouveau certificat. 2.5.5.1 Certificats du Système 14/79

Pendant la période de recouvrement, du 15 janvier au 31 janvier, le Système utilise le certificat courant (noté C1 sur le schéma). Le participant peut utiliser soit le certificat courant, soit le nouveau certificat (noté C2 sur le schéma). Le nouveau certificat peut être téléchargé par l administrateur du participant à partir du 15 janvier. Pendant la période de recouvrement, le certificat courant et le nouveau certificat sont tous les deux disponibles au téléchargement (voir 6.1). Le 15 janvier, le Système prévient par mail les contacts techniques du participant de la mise à disposition du nouveau certificat sur le poste administrateur et de l expiration prochaine du certificat actuel. A partir du 31 janvier (0h00), le Système utilise le nouveau certificat pour crypter les données envoyées. Le participant doit utiliser le nouveau certificat pour crypter les données envoyées. Aucune indication n est donnée sur la date d expiration de l ancien certificat. Après la date d activation du nouveau certificat, le participant peut encore utiliser l ancien certificat sans qu aucune garantie ne soit donnée sur sa validité. Le cas échéant, le fichier peut être refusé avec un motif indiquant que le certificat est expiré (voir annexe 4, motif F0023). Le Système crypte en utilisant C1 Le participant crypte en utilisant C1 (le seul certificat connu et valide) 15 janvier Le Système crypte en utilisant C1 Le participant crypte en utilisant C1 ou C2, qui sont tous les deux valides C1 C2 C2 : Date de mise à disposition Mail de notification (mise à disposition du nouveau certificat) 31 janvier C2 : Date d activation Le Système crypte en utilisant C2 Le participant crypte en utilisant C2 C1 : Date d expiration 2.5.5.2 Certificats du participant Aucune contrainte chronologique n est imposée au participant pour la gestion de ses certificats. Quand l administrateur fournit via le poste administrateur un nouveau certificat au Système, il peut préciser une date d activation. A défaut, la date d activation est égale à la plus grande de la date de début de validité du certificat et de la date du jour. Il est indispensable que la date d activation du nouveau certificat soit antérieure à la date d expiration du certificat actuel. Pendant la période de recouvrement, le Système accepte indifféremment les données cryptées avec le certificat actuel (C1) ou le nouveau certificat (C2). Jusqu à la date d activation du nouveau certificat, le Système utilise le certificat actuel (C1) pour crypter les données à destination du participant. A partir de la date d activation du nouveau certificat, le Système utilise le nouveau certificat pour crypter les données à destination du participant. 15/79

Le Système crypte en utilisant C1 Le participant crypte en utilisant C1 C2 : Date de début de validité Le Système crypte en utilisant C1 Le participant crypte en utilisant C1 ou C2, qui sont tous les deux valides C1 C2 : Date d activation Mail de notification (expiration prochaine du certificat) Le Système crypte en utilisant C2 Le participant crypte en utilisant C1 ou C2, qui sont tous les deux valides C2 1 mois C1 : Date d expiration Le Système crypte en utilisant C2 Le participant crypte en utilisant C2 C2 : Date d expiration Un mois avant la date d expiration du certificat actif, et si le participant n a pas fourni au Système un nouveau certificat, un mail d avertissement est envoyé vers les adresses de contact du participant. 2.6 Éléments d identification d un Teneur de Compte Final (TCF) Les TCF (Teneurs de Compte Finaux) identifiés dans le système sont renseignés dans le référentiel du participant par l administrateur du TCC, depuis le poste administrateur (voir 6.2). Les informations collectées sont utilisées dans : le contrôle et la validation des informations transmises dans les échanges (l identifiant du TCF figure en particulier dans l identifiant d un actionnaire (cf. spécifications fonctionnelles générales du chantier 2). les règles de confidentialité des utilisateurs du poste TCC 2.7 Identification et Authentification des utilisateurs Les utilisateurs du système sont décrits dans le référentiel du participant. Chaque utilisateur ayant accès au système d'information doit être reconnu par un identifiant utilisateur personnalisé. L'utilisation du même identifiant utilisateur par plus d'une personne est strictement interdite. 2.7.1 Création d'un identifiant utilisateur L administrateur du Participant définit les identifiants des personnes habilitées à se connecter sur le Système. Il est responsable de la définition et de la validation des profils d'accès. Les identifiants utilisateurs ne doivent pas avoir de relation avec les caractéristiques (par exemple le nom) du destinataire. Les identifiants utilisateurs ne doivent pas être réattribués. 16/79

Les utilisateurs ayant à la fois une fonction administrative et opérationnelle doivent disposer de deux identifiants distincts. Les administrateurs doivent utiliser l identifiant utilisateur approprié à l'activité qu'ils entreprennent. L administrateur du Participant effectue des vérifications périodiques des droits d'accès sur la base des informations de Sécurité du système. 2.7.1.1 Désactivation des identifiants Tout identifiant utilisateur, y compris s il a un rôle d administrateur, qui n a pas été utilisé depuis plus de 90 jours sera rendu inutilisable. La réactivation du compte est soumise à un accord formel préalable. Pour les comptes d administrateur, 15 jours avant la désactivation un message d alerte émis à destination des adresses email de contacts. 2.7.1.2 Authentification Chaque utilisateur accédant au système d'information doit prouver son identité au moyen d'un authentifiant basé sur un mot de passe. Par défaut, la construction des mots de passe doit respecter les règles suivantes : Longueur minimale : 8 caractères Période maximale de validité : 60 jours Complexité : caractères décimaux et alphabétiques (minimum 2 de chaque) avec au moins un caractère minuscule et un caractère majuscule Sensible à la casse Un nouveau mot de passe ne doit pas être identique aux 12 précédents Ces règles pourront être adaptées et personnalisées par chaque établissement participant au Système, en fonction de sa politique de sécurité. Le protocole permettant de modifier les règles par défaut reste à définir. 2.7.1.3 Délivrance de l'authentification Lors de la création d un identifiant, lors du renouvellement d un mot de passe (pour cause de perte ou absence prolongée), l administrateur fournira par un moyen séparé et sécurisé à l utilisateur son identifiant et son mot de passe. Celui-ci devra être immédiatement changé après la première connexion. 2.7.1.4 Authentification renforcée Lorsqu un utilisateur accède au système d'information via Internet, un système d authentification renforcée sera utilisé. En plus des éléments habituels, il lui sera demandé une clé d authentification représentée par 4 caractères ou chiffres extraits d une une carte matricielle dite «Bingo Card» en sa possession. Il retrouvera cette clé d après les coordonnées (par ex. B2-A5-C4-D8) générées aléatoirement par le serveur et affichées sur la fenêtre d identification. Lorsque l utilisateur validera sa saisie des 3 composants l identifiant, le serveur vérifiera dans l ordre : L identifiant utilisateur 17/79

la clé saisie par rapport à la Bingo Card le mot de passe La bingo card se matérialise par la génération par le système d un document imprimable composé d une matrice de caractères de la taille d une carte de Crédit. La Bingo Card est un document personnel et l utilisateur doit la conserver avec soin afin d assurer sa confidentialité. A tout moment l utilisateur pourra renouveler sa Bingo Card de la même manière que son mot de passe, une fois authentifié. Cette opération se fait depuis l écran du poste TCC ou Centralisateur. 2.7.1.5 Délivrance de l'authentification renforcée L administrateur ne délivre une Bingo Card qu à un utilisateur susceptible de se connecter via Internet. L administrateur fournira à l utilisateur, par un moyen séparé, sa première Bingo Card. La Bingo card a une durée de vie illimitée. L administrateur peut à tout moment révoquer cette carte sans désactiver pour autant le compte de l utilisateur qui ne pourra simplement plus se connecter via Internet. 2.7.1.6 Accès infructueux Les comptes d accès aux systèmes seront verrouillés pendant 15 minutes après 3 tentatives d authentification infructueuses. 2.7.1.7 Suppression d'un identifiant utilisateur La suspension d'autorisation d un identifiant utilisateur s applique de façon permanente. La suppression d'un identifiant utilisateur entraîne le retrait des droits d'accès et l'archivage des informations liées à l'identifiant utilisateur annulé pour une durée correspondant aux obligations légales. 2.7.1.8 Gestion des Traces Les accès sont journalisés ainsi que les événements liés à la sécurité. Ils sont conservés pendant au moins 12 mois. Ces fichiers sont stockés et archivés afin de produire des traces d'accès en cas de contrôles ou d'enquêtes ultérieures. Toutes les opérations relatives à la gestion des utilisateurs sont visibles sur le poste administrateur (voir 6.8) 2.8 Gestion des habilitations utilisateurs La gestion des habilitations repose sur des rôles qui sont un ensemble de droits. L administrateur, définit des rôles dans son environnement en regroupant des droits sur les fonctions. L administrateur affecte des rôles à chaque utilisateur. 2.9 Gestion de la confidentialité 18/79

La confidentialité s applique différemment selon que l utilisateur est attaché à un participant de type TCC ou à un participant de type Centralisateur. 2.9.1 Gestion de la confidentialité pour un centralisateur Chez un participant Centralisateur, la gestion de la confidentialité s applique au niveau des AG, en permettant de définir des utilisateurs dont les droits sont restreints à certaines AG. 2.9.2 Gestion de la confidentialité pour un TCC Chez un participant TCC la gestion de la confidentialité porte sur le périmètre des instructions de votes. Un utilisateur de TCC qui est lié à un TCF ne peut accéder qu aux données correspondant à ce TCF. 19/79

3 Architecture de Raccordement L offre d accès au système de collecte de vote pré AG repose sur l utilisation d une infrastructure Internet et d une infrastructure Radianz. Seuls les TCC et les Centralisateurs ont le choix de leur mode de raccordement, les accès publics au frontal de vote Pré AG se font exclusivement par Internet. Ces possibilités de raccordement peuvent être utilisées indifféremment pour les environnements de production et d homologation. Les Participants désirant utiliser un autre support de raccordement devront en faire la demande auprès de SLIB et une étude sera réalisée pour intégrer la configuration demandée. Dans tous les cas, le participant devra se munir de moyens redondants d accès aux 2 sites de Production. 3.1 Accès Internet L accès Internet est un accès haut débit redondant reliant les deux sites d hébergement du système, réalisé par deux opérateurs physiques différents. L ensemble des accès se fait par l intermédiaire de DMZ, dont les principes et objectifs sont les suivants : Protéger les serveurs SLIB des attaques venant d'internet Filtrer l accès à certaines ressources sur les serveurs SLIB dont seuls certains services sont ouverts Cet accès pourra être utilisé par l ensemble des Participants : Les Centralisateurs les TCC les Actionnaires transférés par les sites Web. Les prestataires techniques du TCC 3.2 Accès BT-Radianz L accès BT-Radianz de SLIB est un accès haut débit redondant reliant les deux sites d hébergement de la prestation via deux opérateurs physiques différents. L ensemble des accès se fait par l intermédiaire de DMZ, dont les principes et objectifs sont les suivants : Protéger les serveurs SLIB Filtrer l accès à certaines ressources sur les serveurs SLIB dont seuls certains services sont ouverts Cet accès pourra être utilisé par les intervenants suivants : Les Centralisateurs les TCC Les prestataires techniques du TCC 3.3 Critères de choix d une offre de raccordement Il est préconisé un raccordement par Internet pour les TCC et Centralisateurs avec de faibles volumes. Dans ce contexte, un service de QOS limitera les capacités de transfert afin de ne pas pénaliser les autres services, particulièrement les utilisateurs du site web. Dans les autres cas (pour les centralisateurs et les TCC avec des volumes importants), un raccordement via BT Radianz est préconisé, avec la souscription d une ligne à 256Kbps minimum. 20/79

Pour un usage important du service comme celui lié à l activité des Centralisateurs, la solution de raccordement via Internet doit être réservée en solution de secours dans la cadre d un PCA. Modes de raccordement des participants : Réseau Centralisateurs TCC Actionnaires Internet Secours secours Principale Radianz OK OK - 3.3.1 Mode de transfert de données Le mode de transfert de fichiers sera choisi selon le mode de raccordement utilisé par le participant. Sur des liaisons Radianz, les fichiers échangés avec les participants seront mis à disposition et récupérables en mode Pull ou en envoi immédiat en mode Push via : CD Direct Connect Express (Pesit-HS) FTPS HTTPS en download (Mode Pull) MQ (IBM Websphere MQ) Sur Internet : les fichiers transmis aux participants seront mis à disposition et récupérables en mode Pull exclusivement : FTPS HTTPS en Download/Upload Le transfert des données émises par le Système se fait selon deux modes : Pull : le participant se connecte à intervalles réguliers pour vérifier la présence de nouveaux fichiers à récupérer (Get). Push : le Système de connecte sur le serveur du participant et y dépose le fichier (Put) Réseau Https FTP/S CD PeSit Internet Pull Pull - - Radianz Pull Pull Push Push Le transfert des données émises par le participant se fait uniquement en mode Push. Le participant de connecte sur le serveur du Système et y dépose le fichier (Put) Réseau Https FTP/S CD PeSit Internet Push Push - - Radianz Push Push Push Push 21/79

3.4 Procédure de raccordement La procédure de raccordement dépend du fournisseur de réseau IP retenu et du choix de la technologie. Tous les délais mentionnés s apprécient entre SLIB et le Participant, une fois les installations techniques rendues opérationnelles. Ces délais sont applicables pour les plates-formes homologation (UAT) et production. 3.4.1 Accès aux services interactifs Deux modes accès sont disponibles pour atteindre les postes TCC/Centralisateur/Administrateur. Accès Internet, via les URI suivantes : Sur la plate-forme de production : https://www.votaccess.fr/post/tcc https://www.votaccess.fr/post/central https://www.votaccess.fr/post/admin Sur la Plate forme d homologation: https://uat.votaccess.fr/post/tcc https://uat.votaccess.fr/post/central https://uat.votaccess.fr/post/admin Accès Extranet (utilisation d une ligne Radianz), via les URL suivantes Sur la plate-forme de production https://www.votaccess.net/post/tcc https://www.votaccess.net/post/central https://www.votaccess.net/post/admin Sur la plate-forme d homologation https://uat.votaccess.net/post/tcc https://uat.votaccess.net/post/central https://uat.votaccess.net/post/admin En cas de non respect de ces URL, une redirection vers une page d erreur sera effectuée. Préconisations de navigateurs : Pour le poste frontal de vote, destiné au grand public, le service interactif supporte les versions de navigateurs listés ci-dessous : Navigateur Versions qualifiées Versions Recommandées Firefox Internet Explorer 3.0, 3.5, 3.6 et 4.0 et supérieures 6, 7 et 8 et supérieures 3.6, 4.0 et supérieures 8 et supérieures Safari 5 et supérieures 5 et supérieures Chromium et Google Chrome 11 et supérieures 11 et supérieures 22/79

Pour information, une version indiquée comme qualifiée est une version de navigateur avec laquelle les postes ont été testés. Pour les postes TCC, centralisateur et administrateur, Les services interactifs du Système supportent les navigateurs listés ci-dessous : Navigateur Versions qualifiées Versions Recommandées Firefox 3.6 et 4.0 et supérieures 3.6 ou 4.0 et supérieures Internet Explorer 7 et 8 et supérieures 8 et supérieures Chromium et Google Chrome 11 et supérieures 11 et supérieures En cas de détection de l utilisation d une version de navigateur ancien, un message d avertissement sera adressé à l utilisateur du poste TCC, centralisateur ou administrateur, indiquant que l application n a pas été testée avec la version de navigateur utilisé. L utilisation de navigateur ancien (comme par exemple IE6) peut entrainer des problèmes d affichage sur le poste de travail. 3.4.2 Phase de configuration Cette étape permet de configurer le logiciel en vue d échanger les informations entre le Système de Vote Pré-AG et le Participant. Pour cela les formulaires applicables (RF01 et RF02) doivent être complétés et renvoyés dûment signés. Un Procès verbal de mise en œuvre sera délivré à l issue des tests. 3.5 Test de raccordement Selon le protocole de transfert choisi, le participant devra valider sa capacité à émettre et à recevoir un fichier de test avec la plateforme d homologation. 23/79

4 Cryptage et signature des échanges Toutes les données échangées entre les acteurs du Système sont cryptées et signées. Cette obligation concerne : Les données fonctionnelles échangées entre le TCC et le Système, sous la forme de messages XML Les données fonctionnelles échangées entre le Centralisateur et le Système, sous la forme de messages XML Les images transmises par le TCC au Système Les images transmises par le Système au Centralisateur Les données fonctionnelles contenues dans le message XML de transfert de session, transmises par les sites web des distributeurs vers le Système Les échanges techniques ne sont pas soumis à ces obligations de sécurité : Acquittement technique Compte rendu quotidien Le chiffrage et l authentification des échanges entre un émetteur (qu il s agisse du Système, du centre de traitement du TCC, du Centralisateur, du site Web d un distributeur ou du prestataire technique du TCC) et un destinataire (qu il s agisse du Système, du centre de traitement du TCC, du Centralisateur ou du prestataire technique du TCC) reposent sur les principes suivants : L émetteur dispose d un certificat contenant une clé publique, une clé privée et l empreinte du certificat. L empreinte constitue un identifiant unique du certificat. La clé privée de l émetteur est utilisée pour signer les données à transmettre. L émetteur dispose d un certificat contenant la clé publique du destinataire et l empreinte du certificat du destinataire. La clé publique du destinataire est utilisée pour crypter les données. L émetteur utilise sa clé privée pour signer les données et la clé publique du destinataire pour crypter les données. Le destinataire utilise sa clé privée pour décrypter les données et la clé publique de l émetteur pour valider la signature des données transmises. Quatre clés différentes sont utilisées dans le processus unidirectionnel d échanger de données. Dans les métadonnées du fichier (voir 5.2.5.1), l émetteur transmet au destinataire : L empreinte de son certificat (identifiant qui permet au destinataire de retrouver parmi son magasin de clés, la clé publique de l émetteur à utiliser). L empreinte du certificat du destinataire (identifiant qui permet au destinataire de retrouver, parmi son magasin de clés, sa clé privée qui correspond à la clé publique utilisée par l émetteur) Clé privée de l émetteur Emetteur Destinataire Clé privée du destinataire Clé publique du destinataire Clé publique de l émetteur Le 2.5.5 précise les règles d utilisation des certificats pendant la période de recouvrement, où deux certificats sont actifs simultanément. Les algorithmes de calcul de la signature et de cryptage sont asymétriques (RSA en l occurrence), très efficaces du point de vue de la sécurité, mais difficilement utilisables sur les données brutes, dont la taille 24/79

est au minimum de plusieurs ko. En pratique, seul un algorithme de cryptage symétrique (AES en l occurrence) peut être appliqué efficacement sur les données brutes. En conséquence, l algorithme suivant est appliqué : L émetteur calcule une empreinte des données brutes. Par essence, l empreinte est d une taille très limitée, sur laquelle le cryptage asymétrique s applique de manière efficiente. L empreinte est ensuite signée avec un cryptage asymétrique, à partir de la clé privée de l émetteur. En parallèle, l émetteur génère une clé de cryptage symétrique (AES) temporaire. Le cryptage avec une clé symétrique s applique bien à des données volumineuses. L émetteur crypte les données brutes avec la clé symétrique générée. L émetteur crypte la clé symétrique AES et la signature avec un cryptage asymétrique, à partir de la clé publique du destinataire. A partir des données brutes originales, l algorithme de cryptage produit donc 3 résultats : Les données (cryptées en AES) La clé de cryptage symétrique (cryptée en RSA) La signature (empreinte des données signée et cryptée en RSA) Le schéma suivant illustre le processus de cryptage que doit appliquer l émetteur. 1a Fonction de Hachage SHA Fichier en clair 2b- Cryptage symétrique 2a- Clé de session Générée Empreinte Sha Clé Privée de l émetteur AES RSA 1b Cryptage asymétrique Fichier Crypté Signature Clé Publique du destinataire RSA Clé du fichier 3 Cryptage asymétrique Zipper Container de Transfert Les trois résultats produits par l algorithme de cryptage sont notés c0, c1 et c2. Dans le cas du transfert de session, c0, c1 et c2 sont renseignés dans les paramètres du formulaire de transfert de session Dans le cas du transfert de fichier, c0, c1 et c2 figurent chacun en tant que fichier contenu dans le fichier zip composite. 25/79

Le schéma ci-dessous présente l ensemble des certificats utilisés par le Système 26/79

5 Echanges de données La vue générale présente l ensemble des acteurs du Système ainsi que les flux qu ils échangent. On y distingue les flux publics (matérialisés par des flèches bleues) des flux privés (matérialisés par des flèches vertes). Les flux privés constituent l interface de communication entre le frontal de vote en ligne et le Système. Le format et le protocole des flux privés sont internes au Système, ils ne sont pas communiqués aux participants. Le format et le protocole d échange des flux publics sont partagés par tous les membres du Système. Dans tous les échanges entre les participants et le Système, les aspects liés au transport des données sont strictement séparés des aspects fonctionnels. Cette séparation favorise l évolutivité du Système. Le format et la cinématique des échanges fonctionnels sont décrits dans les spécifications fonctionnelles générales du chantier 2. La partie transport est décrite dans ce document. Nous distinguons deux types d échanges : Les échanges permettant d effectuer le transfert de session entre le site internet utilisé par l actionnaire et le site de vote en ligne. Le transfert de session est décrit 5.1. Les échanges bidirectionnels de fichiers contenant des messages relatifs aux instructions de vote, entre le Système et le centre de traitement du TCC, ou entre le Système et le centralisateur. Le transfert de fichiers est décrit 5.2. La représentation de ces deux types d échanges repose sur un modèle fonctionnel commun (décrit par format XML). Par contre, le transport des messages diffère selon le type d échange. Dans le cas du transfert de session, le message figure dans un message http de type POST. Les autres échanges sont présentés sous forme d échanges de fichiers entre le Système et le centre de traitement du TCC d une part, entre le Système et le Centralisateur d autre part. Par convention, chaque type de flux se voit affecté un numéro, indiqué dans une boule rouge. La nomenclature est reprise des spécifications fonctionnelles générales du chantier 2. 27/79

1 Transfert de session Site Web 1 Frontal de vote en ligne Site Web 2 Teneur de Compte final (ID TCF) 3 6 Compte rendu d intégration Carte d admission enrichie Echanges privés Système de collecte de votes Pré-AG Site Web 3 4 Compte rendu d instruction de vote 7 Rejet Centralisateur 2 Instruction de vote 0 Référentiel Assemblée Générale Teneur de Compte Conservateur (ID TCC) 5 Bordereau 20 Fichier image 7 Rejet 10 Renseignements complémentaires 9 8 2 5 Réduction de position Demande d annulation Instruction de vote Bordereau 20 Fichier image Les différents flux échangés sont : 0) Référentiel Assemblée Générale Ce flux est transmis par le Système à tous les TCC. Un message est transmis quand le Centralisateur valide une nouvelle Assemblée Générale, ou modifie une Assemblée Générale existante. 1) Transfert de session Le message est exclusivement incorporé dans la requête de transfert de session lors que l actionnaire bascule du site web du distributeur vers le frontal de vote en ligne. Voir 5.1 2) Instruction de vote Quand il est adressé par le TCC au Système, le flux contient les instructions de vote numérisées transmises. Quand il est adressé par le Système vers le Centralisateur, le flux contient toutes les instructions de vote enregistrées par le Système (i.e. soit des instructions de vote numérisées en provenance du TCC, soit des instructions de vote saisies par l actionnaire sur le frontal de vote en ligne. Quand il est adressé au Centralisateur, le flux «Instruction de vote» peut aussi contenir des mises à jour (annulation, modification de droits exercés, changement d état) d instructions de vote existantes. 3) Compte rendu d intégration Ce flux est transmis par le Centralisateur au Système pour l informer de la prise en compte dans l Urne des instructions de vote que lui a envoyées le Système 4) Compte rendu d instruction de vote 28/79

Ce flux est transmis par le Système au TCC pour l informer de l inscription dans le Système d une instruction de vote issue, soit du frontal de vote en ligne, soit d une instruction de vote numérisée. 5) Bordereau Les bordereaux sont transmis par le TCC au Système, puis retransmis par le Système au Centralisateur [Les bordereaux ont été supprimés] 6) Carte d admission enrichie Quand les numéros de cartes d admission sont attribués par le Centralisateur, ce flux permet au Centralisateur de fournir au Système un numéro aux demandes de cartes d admission que lui a préalablement envoyées le Système, sous forme d instructions de vote. 7) Rejet Le flux de rejet contient tous les messages de rejets fonctionnels adressés par le Système aux participants. 8) Demande d annulation Le flux contient les demandes d annulation transmise par le TCC au Système 9) Modification de position Le flux contient à la fois les réductions et les augmentations de position. Il permet au TCC d informer le Système des changements de position des actionnaires ayant transmis une instruction de vote, soit depuis le frontal de vote en ligne, soit depuis le formulaire papier numérisé. 10) Renseignement complémentaire Le flux contient les réponses fournies par l actionnaire depuis le frontal de vote en ligne, sur les questions figurant dans le formulaire des renseignements complémentaires. 20) Image Les images font l objet d un traitement particulier. Le mode de transport est identique à celui des données fonctionnelles, par contre les données échangées ne sont pas des messages XML, mais directement les images au format binaire. 5.1 Transfert de session (redirection et cryptage des informations) L objectif est de transférer une connexion d un actionnaire du site web où il s est formellement identifié, au frontal de vote avec l ensemble des informations nécessaires L url du frontal de vote en ligne est: https://www.votaccess.fr/ frontal/ts pour l environnement de production https://uat.votaccess.fr/ frontal/ts pour l environnement d homologation et recette participant 29/79