Système de Collecte de Vote Pré-AG

Transcription

1 Système de Collecte de Vote Pré-AG CH06 - Technique et sécurité Spécifications fonctionnelles générales Version

2 SUIVI DU DOCUMENT Version Nature Chapitre Auteur Date 1.0 Création du document Tous SLIB 05/07/ Revue suite Réunion CH06 Tous SLIB 05/07/ Mise à jour générale du document Tous SLIB 15/10/ Clarification des attributs du transfert de session Ajout d un exemple de formulaire de transfert de session SLIB 22/10/ Précisons sur les attributs des métadonnées du transfert de fichier Ajout des URL d accès aux postes TCC/centralisateur/administrateur Ajout recommandations navigateurs Modifications des URL (production et homologation) d accès au frontal de vote 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) 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) SLIB 17/11/ Correction de l exemple XML d un fichier metadata Ajout d un exemple XML d acquittement technique Ajout d un exemple XML de compte rendu quotidien 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) /79

3 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 Dans le message d acquittement technique, la longueur maximale de la description de l erreur passe de 350 à 1024 caractères 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 Correct on : la balise décrivant le type de fichier s appelle <FileTp> et non FileTyp comme indiqué précédemment par erreur , Annexe 4 - Ajout de la version dans le compte rendu quotidien 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/ Correction de l exemple de transfert de session Précision sur les particularités liées au transport des images 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 Le timeout (délai maximal d émission de SLIB 18/03/2011 3/79

4 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 Annexe 4 - Précisions sur la notion de vacation Précision sur les navigateurs qualifiés & recommandés 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é SndgMsgDtAndTm obligatoire 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 Suppression du numéro de séquence attendu dans l acquittement technique SLIB 11/07/ Précision sur les navigateurs qualifiés & recommandés Ajout des fonctions élémentaires du poste Administrateur Annexe 5 -Ajout des codes d erreurs spécifiques au transfert de session Annexe 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 SLIB 22/12/ Correction de deux coquilles dans l exemple de /79

5 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 Annexe 7 5/79

6 SOMMAIRE 1 Principes généraux Sécurité des échanges Services délivrés S e r v i c e : A c c è s I n t e r a c t i f s S e r v i c e : T r a n s f e r t d e d o n n é e s Participants au système Identification des Participants Formulaire de raccordement au système Profil Administrateur Éléments d identification des participants C e n t r a l i s a t e u r T e n e u r d e c o m p t e D i s t r i b u t e u r Gestion des certificats 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 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 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 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 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 Éléments d identification d un Teneur de Compte Final (TCF) Identification et Authentification des utilisateurs 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 Gestion des habilitations utilisateurs Gestion de la confidentialité 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 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 Architecture de Raccordement Accès Internet Accès BT-Radianz Critères de choix d une offre de raccordement M o d e d e t r a n s f e r t d e d o n n é e s Procédure de raccordement /79

7 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 P h a s e d e c o n f i g u r a t i o n Test de raccordement Cryptage et signature des échanges Echanges de données Transfert de session (redirection et cryptage des informations) S i t e w e b d u d i s t r i b u t e u r A u t h e n t i f i c a t i o n T r a i t e m e n t d e s R e j e t s 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 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 E l é m e n t s t e c h n i q u e s Transfert de fichier 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 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 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 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 P r o t o c o l e d é c h a n g e A g r é g a t i o n d e s d o n n é e s 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 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 é C o m p r e s s i o n d e s d o n n é e s Poste administrateur Certificats utilisés dans les transferts de fichiers Déclarations TCF Déclarations Site Web du distributeur Contacts Gestion des rôles Gestion des utilisateurs Confidentialité TCC Piste d audit Annexes Annexe 1 Liste Noire Annexe 2 Liste des identifiants d échanges de fichiers : /79

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

9 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 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,..) 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

10 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

11 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 ) 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 RF 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 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 . Elles seront nécessaires pour communiquer avec le participant, par exemple lors de l expiration des certificats 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

12 plusieurs adresses . Elles seront nécessaires pour communiquer avec le participant, par exemple lors de l expiration des certificats 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 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

13 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 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 ). 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 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

14 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 de contacts techniques du participant 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 et ). 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 Certificats du Système 14/79

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

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

17 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 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 de contacts 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 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 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

18 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 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 Accès infructueux Les comptes d accès aux systèmes seront verrouillés pendant 15 minutes après 3 tentatives d authentification infructueuses 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 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

19 La confidentialité s applique différemment selon que l utilisateur est attaché à un participant de type TCC ou à un participant de type Centralisateur 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 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

20 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

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

22 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 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 : Sur la Plate forme d homologation: Accès Extranet (utilisation d une ligne Radianz), via les URL suivantes Sur la plate-forme de production Sur la plate-forme d homologation 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

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

24 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 ), 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 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

25 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

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

27 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

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

29 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: frontal/ts pour l environnement de production frontal/ts pour l environnement d homologation et recette participant 29/79

30 5.1.1 Site web du distributeur Le site web du distributeur indique à l actionnaire qu une assemblée générale est en ligne (pour consultation de la documentation ou, quand le vote électronique est ouvert, pour soumission au Système d une instruction de vote). Le site web du distributeur génère une page contenant les instructions de redirection vers le frontal de vote en ligne. Les données (décrites dans les spécifications fonctionnelles générales du chantier 2) sont transportées cryptées en paramètres de la connexion. Les détails techniques sont fournis en annexe Authentification Le frontal de vote authentifie le site depuis lequel l actionnaire demande l accès. Le système n authentifie pas l utilisateur demandant l accès au frontal de vote, cette fonction étant assurée par le site web du distributeur. A cette fin, on utilise le certificat stocké dans le référentiel participant pour valider les informations transmises par le site web du distributeur Traitement des Rejets Si une erreur est détectée par le Système durant le processus de transfert de session, le système affiche une page d erreur à l utilisateur indiquant qu une erreur s est produite et que traitement ne peut se poursuivre, sans autre information complémentaire. Si le traitement détecte une erreur technique empêchant toute identification du site de transfert aucune autre action ne sera exécutée. 30/79

31 Les anomalies sur les transferts de session seront communiquées (sous forme d un ) par le système vers un contact technique défini au niveau des informations du Site web du distributeur (voir 6.3). Le message contient le code et le motif (description textuelle) du rejet. Afin de ne pas risquer de surcharger le Service de messagerie (SPAM), au maximum un message d alerte pourra être émis par période de 15 minutes intégrant l ensemble des informations sources de rejet collectées sur la période. Les informations diffusées sont les métadonnées (en clair) contenues dans le transfert de session. Les informations reçues cryptées ne pouvant pas être décodées par l émetteur, elles ne seront pas retransmises dans le mail d alerte. Le motif et la description de l erreur rencontrée par le Système figureront dans le mail d alerte. Les cas de rejet de transfert de session identifiés sont, à titre indicatif : Impossibilité de dézipper le fichier Impossibilité de décrypter le fichier La signature de l émetteur est incorrecte Des données obligatoires des métadonnées sont absentes Le message de transfert de session a provoqué un rejet fonctionnel (voir spécifications fonctionnelles générales du chantier 2) Expiration de la durée de validité du transfert (en fonction de l horodatage figurant dans le message fonctionnel de transfert de session) Etc. La liste exhaustive des cas d erreur technique, et des motifs associés, est fournie en annexe 4. Les cas d erreurs fonctionnelles pouvant entraîner une erreur lors du transfert de session sont énumérés dans les spécifications fonctionnelles générales du chantier Mode de transfert et transport des données Toutes les opérations de transfert se font en HTTPS (SSL). La durée de validité d une requête de transfert est de 10 minutes, afin de ne pas risquer de voir apparaître des requêtes trop anciennes dont les données seraient obsolètes. Le calcul de la validité est basé sur l horodatage (SendingMessageDateAndTime) figurant dans le message de transfert de session (voir spécifications fonctionnelles générales du chantier 2, tag «SndgMsgDtAndTm» de la structure «InstrMsgHdr»). Ce tag est préféré au tag «SndgFileDtAndTm» figurant dans les métadonnées ( ), de manière à éviter des manipulations abusives du formulaire de transfert de session Traçabilité du transfert de connexion Toute requête reçue sur le frontal de vote est tracée. Le système conserve l ensemble des informations reçues dans une piste d audit afin de permettre de reconstituer le chemin parcouru par un actionnaire sur le frontal de vote. Ces données sont visibles sur le poste TCC, depuis la vue «Actionnaire» (cf. 5 des spécifications fonctionnelles générales du chantier 4) 31/79

32 Les données confidentielles restent chiffrées Eléments techniques Ce transfert s effectue du site web du distributeur vers le frontal de vote Format de transfert Toutes les informations seront passées dans un formulaire HTML au format par défaut (application/x-wwwform-urlencoded) via la méthode http POST. Le formulaire contiendra donc les 3 éléments issus du cryptage de ce fichier (voir annexe 3) plus des données supplémentaires. Ainsi nous aurons : Le fichier crypté symétriquement C0 encodé en hexadécimal dans le paramètre c0 du formulaire (obligatoire). Le premier cryptage asymétrique C1 encodé en hexadécimal dans le paramètre c1 du formulaire (obligatoire). Le deuxième cryptage asymétrique C2 encodé en hexadécimal dans le paramètre c2 du formulaire (obligatoire). Métadonnées dans plusieurs paramètres du formulaire, cf pour le nommage des paramètres. Il est inutile de compresser les données C0 du transfert de session Codage Hexadécimal Un octet sera codé sur deux caractères hexadécimaux. Le premier caractère correspondra aux bits de poids fort et le second caractère correspondra aux bits de poids faible. Les caractères seront dans l ordre : les chiffres de 0 à 9 (codes hexadécimaux de 30 à 39 dans la table Unicode) puis les lettres de a à f (codes hexadécimaux de 61 à 66 dans la table Unicode) Métadonnées La partie métadonnée est renseignée dans le format indiqué dans la table ci-dessous. Nom Type O/F Description Tag ISO Version N O Valeur obligatoire : 1 Vrsn Type de fichier Enumération A(4) O Type du fichier Valeurs possibles : TRSF (Transfert de session) FileTp 32/79

33 Nom Type O/F Description Tag ISO Type de codification choisi par le participant pour l identification du site web du distributeur 1 Identifiant de l émetteur A(4) O L identifiant du site Web est déclaré par l administrateur du TCC lors de la création du site web (cf. 6.3), depuis le poste administrateur PtyIdCd Voir identification d un participant ( 2.1) A(12) O Code du site web dans la codification indiquée par le tag PtyIdCd Cd Numéro de série du certificat du site web du distributeur. Le numéro de série est un attribut du certificat X509. Numéro de série du certificat de l émetteur A(64) O Le numéro de certificat est codé sur au plus 32 octets, représenté par 64 caractères hexadécimaux (10 chiffres et les lettres a à f ) SndrCertSrlNb (SenderCertificateSerialNumber) Il permet au Système d accéder à la clé publique correspondant à la clé privée utilisée par le site web du distributeur Numéro de série du certificat du Système. Le numéro de série est un attribut du certificat X509. Numéro de série du certificat du destinataire A(64) O Le numéro de certificat est codé sur au plus 32 octets, représenté par 64 caractères hexadécimaux (10 chiffres et les lettres a à f ). Les numéros de série des certificats du Système sont codés sur 16 octets (32 caractères hexadécimaux). TgtCertSrlNb (TargetCertificateSerialNumber) Il permet au Système d accéder à la 1 Contrairement au formalisme habituel où un identifiant est représenté par une structure XML imbriquée (voir par exemple la représentation de l émetteur d un fichier d échange de données, voir ), et du fait que le transfert de session s effectue via un formulaire post, la représentation de l identifiant d un participant dans le transfert de session est uniquement constituée par les deux champs PtyIdCd et Cd. 33/79

34 Nom Type O/F Description Tag ISO clé privée correspondant à la clé publique utilisée par site web du distributeur pour crypter le fichier Horodatage d émission Date+heure O L horodatage figurant dans les métadonnées est utilisé pour la traçabilité SndgMsgDtAndTm (SendingMessageDateAndTime) 34/79

35 Exemple Fichier SessionTransfer.xml <form name="form1" method="post" action=" <!--elements de cryptage--> <input type="hidden" name="c0" value="bfc947b12ea40f7 941b36c84943eb76f69e169d31dba637f4"/> <input type="hidden" name="c1" value="3afb63a1e988dfd3654a19a5894b7c c6f930a697f4"/> <input type="hidden" name="c2" value="212dc2f28fa17afe62836d8e c5cebf25e0ff85a"/> <!--métadonnées--> <!--Version des métadonnées du transfert de session--> <input type="hidden" name="vrsn" value="1"/> <!--Type de message contenu (il s'agit forcément d'un message de type 'Transfert de session)--> <input type="hidden" name="filetp" value="trsf"/> <!--Identifiant du site web effectuant le transfert de session--> <!--codification de l'identifiant du participant (Euroclear en l'occurrence--> <input type="hidden" name="ptyidcd" value=" ECLC"/> <!--code du participant dans la codification Euroclear--> <input type="hidden" name="cd" value=" "/> <!--Numéro de série du certificat du site web --> <input type="hidden" name="sndrcertsrlnb" value="3c6226f4a7e34a19a589af4d959edd7b"/> <!--Numéro de série du certificat du système --> <input type="hidden" name="tgtcertsrlnb" value="3c6226f4a7e34a19a589af4d959edd7b"/> <!--horodatage du transfert de session--> <input type="hidden" name="sndgmsgdtandtm" value=" t15:00:00.000" /> </form> 5.2 Transfert de fichier Le contenu des fichiers échangés est indépendant des protocoles utilisés. Ainsi les données peuvent être échangées avec les protocoles HTTPS, FTPS, PeSit ou Connect Direct Typologie de fichiers échangés Les fichiers contenant des données fonctionnelles (messages XML ou images issues de la numérisation des formulaires de vote) sont toujours des conteneurs au format zip. Ces fichiers sont appelés fichiers composites. Le fichier de données peut être un fichier binaire (zip d images) ou un fichier XML. L identifiant du fichier permet de déterminer de manière explicite si le contenu est binaire ou texte. Un fichier composite comporte Des éléments de contrôle, appelés aussi métadonnées. Les métadonnées sont incluses dans un fichier XML Il s agit des éléments techniques protocolaires (identifiant de l émetteur, type de flux, numéro de séquence, numéro de série des certificats) Les données cryptées et signées, stockées dans 3 fichiers binaires distincts : C0 : qui contient les données originales (un document xml contentant des messages fonctionnels ou des images) cryptées, signées et éventuellement compressées. 35/79

36 C1 : qui contient la première partie de la clé de cryptage et de la signature. Suivant la version de l algorithme de cryptage utilisé, C1 peut aussi contenir un indicateur de compression des données. C2 : qui contient la seconde partie de la clé de cryptage et de la signature Fichier Xml : Caractères autorisés Les caractères autorisés sont ceux de la messagerie ISO utilisant la norme UTF8. Il est recommandé de ne pas utiliser des caractères tels que le «&» de «Père & Fils» ou «<» ou «>». L utilisation de tels caractères peuvent amener des rejets des données. Il existe dans la norme XML une codification de ces caractères accentués appelée «entities» qui permet leur utilisation. En revanche, certaines chaines de caractères peuvent être rejetées, une liste Noire est disponible en annexe Acquittements des échanges de données En règle générale, en réponse à tout transfert de fichier, le récepteur renverra à l émetteur un accusé de réception dans un délai inférieur à 30 minutes. Si des anomalies sont détectées, l accusé de réception, contiendra une information donnant la raison du rejet. La non émission d acquittement à l émetteur par le destinataire est une anomalie. Les fichiers doivent être transmis dans l ordre de séquence croissante, la rupture de séquence est une anomalie. Les détails techniques sont fournis en annexe Convention de nommage et de stockage des fichiers échangés Afin d'être en mesure d'assurer une traçabilité de bout en bout des différents fichiers échangés et traités, il est nécessaire d'adopter des règles de référencement ne laissant aucune ambigüité aussi bien du coté de l'émetteur que du coté du destinataire. Tous les identifiants de fichier sont indiqués en annexe Protocoles PeSIT ou CFT Les identifiants de flux utilisés dans les transferts PeSIT ou CFT sont constitués de 8 caractères. Ils respectent la nomenclature suivante : N Description 1 Sens de transfert du point de vue du Système : E : Fichier émis par le Système (et donc reçu par le participant) R : Fichier reçu par le Système (et donc émis par le participant) 36/79

37 N Description 2 et à 8 Codification sur 2 chiffres du type de flux : 00 : Référentiel Assemblée Générale 02 : Instruction de vote 03 : Compte rendu d'intégration de vote 04 : Compte rendu d'instruction de vote 05 : Bordereau 06 : Carte d'admission enrichie 07 : Rejet fonctionnel 08 : Demande d'annulation 09 : Modification de position 10 : Renseignement complémentaire 20 : Partie image des votes numérisés 30 : Compte rendu quotidien 31 : Acquittement technique Distingue les flux de production et les flux d homologation : P : Production H : Homologation Codification sur un caractère du rôle du participant : C : Centralisateur T : TCC P : Prestataire technique du TCC Identification technique du participant. Cet identifiant est attribué par le Système, communiqué au participant dans le formulaire RF02 (formulaire décrivant les éléments techniques de raccordement) L identifiant est composé de 3 chiffres Protocoles FTPS ou HTTPS Sur les serveurs FTPS et HTTPS, les fichiers sont stockés et mis à disposition dans des dossiers dédiés et structurés. Un participant se voit attribuer un identifiant technique unique composé de 3 chiffres. Cet identifiant technique, ainsi que les noms des dossiers créés sur Système pour son usage sont communiqués au participant dans le formulaire de raccordement technique RF02. Tous les dossiers propres à ce participant sont regroupés sur le Système dans un dossier racine nommé avec cet identifiant technique. Sous cette racine, une arborescence de dossier permet de séparer les fichiers échangés. Les noms de dossiers sont composés de 5 caractères alphanumériques, et respectent la nomenclature suivante : N Description 1 Sens de transfert du point de vue du Système : E : Fichier émis par le Système (et donc reçu par le participant) R : Fichier reçu par le Système (et donc émis par le participant) 37/79

38 N Description 2 et Codification sur 2 chiffres du type de flux : 00 : Référentiel Assemblée Générale 02 : Instruction de vote 03 : Compte rendu d'intégration de vote 04 : Compte rendu d'instruction de vote 05 : Bordereau 06 : Carte d'admission enrichie 07 : Rejet fonctionnel 08 : Demande d'annulation 09 : Modification de position 10 : Renseignement complémentaire 20 : Partie image des votes numérisés 30 : Compte rendu quotidien 31 : Acquittement technique Distingue les flux de production et les flux d homologation : P : Production H : homologation Codification sur un caractère du rôle du participant : C : Centralisateur T : TCC P : Prestataire technique du TCC Les fichiers émis par le Système sont déposés dans les dossiers dont la première lettre est E. Les fichiers transmis par les participants doivent être déposés dans les dossiers commençant par lettre R Durée de disponibilité des fichiers Les fichiers à recevoir sont tenus à dispositions des participants durant 7 jours ouvrés sur les serveurs. Au delà ils seront archivés et une demande de remise à disposition devra être réalisée auprès du service client Durée de Conservation des fichiers Les fichiers, à l exclusion des fichiers images, sont conservés 3 ans à des fins de preuves et d audit Protocole d échange Le protocole d échange technique de fichiers repose sur un système de maillonnage. Le Système et le participant, qu il soit TCC ou Centralisateur, agissent de façon symétrique. L objectif du maillonnage est de détecter des fichiers perdus lors des transferts techniques. Les numéros de maillon sont impérativement des numéros séquentiels. Il existe un maillonnage (donc un numéro de séquence) par type de fichier. Le maillonnage s applique aussi bien aux fichiers de données qu aux fichiers images. 38/79

39 Par ailleurs, en fin de journée le Système transmet à chaque Participant un compte rendu quotidien, récapitulant le compte des fichiers reçus par le Système, et précisant le nombre d anomalies rencontrés (fichiers non acquittés ou fichier rejetés techniquement). Voir D une manière générale, les échanges sur un type de flux donné se font entre un émetteur et un destinataire : L émetteur gère un numéro de maillon (ou numéro de séquence) en émission. Il transmet ce numéro de maillon au destinataire. Le numéro de maillon est un des champs figurant dans les métadonnées du fichier émis. Le destinataire gère un numéro de maillon attendu. Si le numéro de maillon transmis est égal au numéro de maillon attendu, le destinataire incrémente le numéro de maillon attendu. Si le numéro de maillon transmis est différent du numéro de maillon attendu, le destinataire doit rejeter le fichier reçu. Emetteur Destinataire N de séquence= m Fichier composite (données ou images) Type de fichier = tf N de séquence = m Emetteur = IdEmetteur N de séquence attendu = m Acquittement technique Type de fichier = tf N de séquence = m Emetteur = IdEmetteur Code retour = OK Dézippage Décryptage Analyse des métadonnées Incrémentation du numéro de séquence Incrémentation du numéro de séquence courant N de séquence= m+1 Fichier composite (données ou images) Type de fichier = tf N de séquence = m+1 Emetteur = IdEmetteur N de séquence attendu = m+1 Le numéro de maillon attendu est incrémenté par le destinataire même si le fichier reçu fait l objet d un rejet technique, sauf dans les circonstances suivantes : Le destinataire ne parvient pas à extraire les métadonnées du fichier reçu (et donc à déterminer le numéro de maillon transmis par l émetteur), voir le code rejet F0004 en annexe 4. Le format des métadonnées est illisible, voir les codes rejet F0041 et F0042 en annexe 4. Le numéro de séquence transmis dans le fichier ne correspond pas à celui attendu par le destinataire, voir le code rejet F0015 en annexe 4. L ensemble des codes d erreur retournés par le message de rejet est fourni dans l annexe 4. Pour chaque code erreur, il est précisé si le numéro de maillon attendu par le destinataire est ou non incrémenté. La plupart des cas de rejet ne peuvent être traités que par une intervention manuelle. 39/79

40 Un document complémentaire décrit les procédures de gestion des anomalies. Selon les cas, une intervention peut être nécessaire sur la plate-forme et/ou l environnement du participant. Les échanges sur un type de flux donné sont unidirectionnels, i.e. un établissement ne peut à la fois émettre et recevoir un même type de fichier. Le premier numéro de maillon produit par l émetteur d un fichier est 1. Au démarrage du Système, le numéro de maillon attendu pour chaque type de fichier est 1. Si la limite de représentation d un numéro de maillon est atteinte ( ), la numérotation reprend à 0, i.e. après avoir reçu le numéro de maillon , le prochain numéro de maillon attendu est 0. Le protocole ne permet pas à un destinataire de transmettre une demande de changement de maillon courant. En cas de problème technique, seule une intervention manuelle permettra de modifier le numéro de maillon courant sur les fichiers en émission et le numéro de maillon attendu sur les fichiers en réception. Les acquittements techniques ne sont pas maillonnés. Les métadonnées du fichier d acquittement technique contiennent un numéro de maillon, mais il s agit du numéro de maillon du fichier sur lequel porte l acquittement Fichier de données Les paramètres techniques d un fichier contenant des informations fonctionnelles (données formalisées dans des messages XML et images des instructions de vote numérisées) sont transmis dans la partie appelée métadonnée du fichier. Le fichier de donnée est une archive zip, contenant 4 fichiers élémentaires : Les fichiers c0, c1 et c2 qui contiennent les éléments de cryptage (format binaire) Un fichier contenant les métadonnées (format texte, xml) La partie métadonnée est renseignée de façon identique par les participants et le Système, dans le format indiqué dans la table ci-dessous. L ordre des champs est celui dans la table. Les champs sont encadrés par une balise «metadata» Nom Type O/F Description Tag ISO Version N O Valeur obligatoire : 1 Vrsn Type du fichier Type de fichier Enumération A(4) O Valeurs possibles : REFR (Référentiel Assemblée Générale) VOTE (Instruction de vote) ITRP (Compte rendu d'intégration de vote) VTRP (Compte rendu d'instruction de vote) SLIP (Bordereau) CPCD (Carte d'admission FileTp 40/79

41 Nom Type O/F Description Tag ISO enrichie) FCRJ (Rejet fonctionnel) CLRQ (Demande d'annulation) BLUP (Modification de position) ADIN (Renseignement complémentaire) SCAN (Partie image des instructions de vote numérisées) Identifiant de l Assemblée Générale A(20) O Identifiant de l Assemblée Générale MtgId Numéro de maillon (ou numéro de séquence) attribué par l émetteur du fichier. Numéro de maillon N(18) O Le fichier doit être rejeté par le destinataire si ce numéro de maillon est différent de celui attendu, selon le protocole indiqué au début du SeqNb Identifiant de l émetteur du fichier. Identifiant de l émetteur Identifiant O Voir identification d un participant ( 2.1) Dans les fichiers émis par le Système, le champ contient la valeur SYSC, VOTACCESS PtyId Empreinte du certificat de l émetteur Numéro de série du certificat de l émetteur A(64) O L empreinte est codée sur au maximum 32 octets, représentée par 64 caractères hexadécimaux (10 chiffres et les lettres a à f ) Il permet au destinataire de d accéder à la clé publique correspondant à la clé privée utilisée par l émetteur pour signer le fichier SndrCertSrlNb (SenderCertificateSerialNumber) 41/79

42 Nom Type O/F Description Tag ISO Le numéro de série des certificats du Système comporte 16 octets (32 chiffres) Empreinte du certificat du destinataire Numéro de série du certificat du destinataire A(64) O L empreinte est codée sur au maximum 32 octets, représentée par 64 caractères hexadécimaux (10 chiffres et les lettres a à f ) Il permet au destinataire de d accéder à la clé privée correspondant à la clé publique utilisée par l émetteur pour crypter le fichier TgtCertSrlNb (TargetCertificateSerialNumber) Le numéro de série des certificats du Système comporte 16 octets (32 chiffres) Horodatage d émission Date+heure O L horodatage figurant dans les métadonnées est utilisé pour la traçabilité SndgFileDtAndTm (SendingFileDateAndTime) Référence externe, transmise par l émetteur du fichier. Référence externe A(35) F Cette référence n est pas exploitée par le Système, mais si elle est renseignée, elle est retournée au participant dans le message d acquittement (positif ou négatif) du fichier (voir ) FileXtrnlRef (FileExternalReference) Quand l émetteur du fichier est le Système, ce champ n est pas renseigné Rôle du destinataire Enumération A(4) C Ce tag ne s applique qu aux fichiers émis par le Système. Il contient le rôle TCC ou Centralisateur du destinataire. Quand un participant tient les 2 rôles, ce tag permet en particulier de distinguer si les rejets concernent la fonction TCC ou Centralisateur. TgtRole (TargetRole) 42/79

43 Nom Type O/F Description Tag ISO Valeurs possibles : IAGT (Issuer Agent, Centralisateur) CAKC (CustodyAccountKeeper, TCC) Ce tag ne doit pas être renseigné par les participants A la réception d un fichier de données, le Système vérifie la cohérence entre le type de fichier figurant dans les métadonnées (tag «FileTp») et l identifiant de fichier utilisé pour le transport. Par exemple, dans le cas du transport par protocole PeSit, dans le flux «R02PTyyy», le Système rejette techniquement un fichier dans lequel le type de fichier est différent de «VOTE». De même, le Système vérifie la cohérence entre l identifiant de l émetteur (au format décrit 2.1) et l identifiant technique interne figurant dans l identifiant du fichier utilisé pour le transport. Exemple L exemple ci-dessous illustre les métadonnées envoyées par un TCC lors de l envoi au Système d instructions de vote numérisées. Fichier FileData.Metadata.xml <?xml version="1.0" encoding="utf-8"?> <Metadata> <!--Version--> <Vrsn>1</Vrsn> <!--Type des données--> <FileTp>VOTE</FileTp> <!--Identifiant de l'assemblée générale concernée--> <MtgId>FR </MtgId> <!--numéro de séquence--> <SeqNb>324</SeqNb> <!--Identifiant de l'émetteur--> <PtyId> <!--codification de l'identifiant de l'émetteur (Euroclear en l'occurrence--> <PtyIdCd>ECLC</PtyIdCd> <!--code du participant dans la codification Euroclear--> <Cd> </Cd> </PtyId> <!--Numéro de serie du certificat de l'émetteur (TCC en l'occurrence)--> <SndrCertSrlNb>3c6226f4a7e34a19a589af4d959edd7b</SndrCertSrlNb> <!--Numéro de serie du certificat du destnataire(le système en l'occurrence)--> <TgtCertSrlNb>ef452ba2306e6567ccd32a d50</TgtCertSrlNb> <!--Horodatage d'émission du fichier--> <SndgFileDtAndTm> T15:00:00.000</SndgFileDtAndTm> <!-- Référence externe fournie par le TCC --> <FileXtrnlRef>REFTCC0234</FileXtrnlRef> </Metadata> 43/79

44 Acquittement technique Le fichier d acquittement technique permet au destinataire d un fichier de données de renvoyer à l émetteur un compte rendu de la bonne réception du fichier reçu. L acquittement informe l émetteur aussi bien l intégration correcte du fichier que de son rejet pour des motifs techniques. Les rejets fonctionnels portant sur le respect du protocole fonctionnel défini dans les spécifications fonctionnelles générales du chantier 2 n entrainent pas de rejet technique. Un même fichier correctement formé peut contenir des instructions de vote erronées. Il est acquitté techniquement. Les instructions de vote en erreur font l objet d un rejet fonctionnel, transmis dans un fichier de type 07 = «Rejet fonctionnel». Quand un fichier est rejeté techniquement, aucun des messages fonctionnels inclus dans ce fichier n est pris en compte. Par exemple, si le fichier contient des messages d instructions de vote numérisées correctement formatées mais que les métadonnées du fichier indiquent un trou dans le maillonnage, le fichier est techniquement rejeté et aucune des instructions n est inscrite dans le Système. Certains cas d erreur font que le Système est incapable d émettre un message de rejet technique. La raison principale est que l erreur est telle qu il est impossible au système de déterminer à quel participant envoyer le message de rejet technique ou alors d indiquer dans le message la référence du fichier rejeté. Les erreurs suivantes ne feront pas l objet d un rejet technique : Dans les métadonnées, l identifiant de l émetteur est non renseigné ou incorrectement formaté Le fichier ne peut être dézippé, rendant impossible l extraction des métadonnées Le fichier XML contenant les métadonnées est mal formé (il ne respecte pas la syntaxe XML : caractères interdits, balise ouvrante sans la balise fermante correspondante, etc.) Quand cela lui est possible 2, le Système enverra au participant un message d alerte l informant du problème. Ce mail sera adressé aux contacts techniques déclarés par le participant. Les cas faisant l objet d un rejet technique sont répertoriés en annexe 4. Le fichier d acquittement technique est un fichier xml, non crypté. Les données figurant dans le fichier permettent au destinataire de l acquittement (c'est-à-dire à l émetteur du fichier acquitté ou rejeté) d identifier le fichier sur lequel porte l acquittement technique 3. L acquittement contient, dans l ordre indiqué dans le tableau, les métadonnées suivantes encadrées par une balise «FileAckRct» : Nom Type O/F Description Tag ISO Version N O Valeur obligatoire : 1 Vrsn Type fichier de Enumération A(4) C Type du fichier tel qu il figure dans les métadonnées du fichier sur lequel porte FileTp 2 Dans le cas où le transport se fait par échange de fichiers, il est possible au Système de déterminer l identité du participant à partir du nom du ficher d échange (voir 5.2.4) 3 Le Système utilise pour sa part les 4 éléments suivants pour identifier les fichiers qu il émet de manière unique : Identifiant du participant destinataire (TCC ou Centralisateur) Rôle du participant destinataire Type de fichier Numéro de maillon 44/79

45 Nom Type O/F Description Tag ISO l acquittement Valeurs possibles : REFR (Référentiel Assemblée Générale) VOTE (Instruction de vote) ITRP (Compte rendu d'intégration de vote) VTRP (Compte rendu d'instruction de vote) SLIP (Bordereau) CPCD (Carte d'admission enrichie) FCRJ (Rejet fonctionnel) CLRQ (Demande d'annulation) BLUP (Modification de position) ADIN (Renseignement complémentaire) SCAN (Partie image des instructions de vote numérisées) Le champ est impérativement renseigné par l émetteur de l acquittement à partir du champ <FileTp> figurant dans le message acquitté, sauf s il lui est impossible d extraire cette information des métadonnées du fichier acquitté (tag <FileTp> absent des métadonnées, tag <FileTp> incorrectement formaté, métadonnées mal formées, etc..) Numéro de maillon tel qu il figure dans les métadonnées du fichier sur lequel porte l acquittement. Les fichiers d acquittement technique ne sont pas maillonnés. Numéro de maillon N(18) C Le champ est impérativement renseigné par l émetteur de l acquittement à partir du champ < SeqNb > figurant dans le message acquitté, sauf s il lui est impossible d extraire cette information des métadonnées du fichier acquitté (tag < SeqNb > absent des métadonnées, tag < SeqNb > incorrectement formaté, métadonnées mal formées, etc..) SeqNb Identifiant de l émetteur Identifiant O Identifiant de l émetteur de l acquittement. Voir identification d un participant ( 2.1) PtyId 45/79

46 Nom Type O/F Description Tag ISO Dans les acquittements émis par le Système, le champ contient la valeur SYSC, VOTACCESS Code indiquant le statut de l accusé de réception : Code retour de Enumération A(5) O Le code indique que le fichier a été correctement reçu, dézippé et décrypté Tous les autres codes indiquent une erreur dans le traitement du fichier reçu. La liste des codes erreur que peut émettre l émetteur de l acquittement est fournie en annexe 4. StsCd Description de l erreur A(1024) C Description textuelle de l erreur rencontrée par le destinataire du message rejeté. Ce libellé n est pas renseigné par le Système quand le code de retour vaut «00000» ErrDesc Référence externe A(35) F Référence externe, transmise par le Système si l émetteur du fichier acquitté l a renseignée. Les participants n ont pas à alimenter ce champ FileXtrnlRef (FileExternalReference) Rôle du destinataire Enumération A(4) C Ce tag ne s applique qu aux acquittements émis par le Système. Il contient le rôle TCC ou Centralisateur du destinataire. Quand un participant tient les 2 rôles, ce tag permet en particulier de distinguer si l acquittement concerne la fonction TCC ou Centralisateur. TgtRole (TargetRole) Valeurs possibles : IAGT (Issuer Agent, Centralisateur) CAKC (CustodyAccountKeeper, TCC) Ce tag ne doit pas être renseigné par les participants Exemple Fichier TechAcq.xml 46/79

47 <?xml version="1.0" encoding="utf-8"?> <FileAckRct> <!--Version--> <Vrsn>1</Vrsn> <!--Type des données indiqué dans le fichier acquitté--> <FileTp>VOTE</FileTp> <!--numéro de séquence du fichier acquitté --> <SeqNb>324</SeqNb> <!--codification de l'identifiant de l'émetteur--> <PtyId> <!--Dans l'exemple, l'émetteur est le système dont la codification est SYSC--> <PtyIdCd>SYSC</PtyIdCd> <!--code du système--> <Cd>VOTACCESS</Cd> </PtyId> <!--Code de retour--> <StsCd>00000</StsCd> <!--Le tag ErrDesc n'est renseigné que dans les messages de rejet (acquittement négatif)--> <!-- Référence externe fournie par l'émetteur du fichier acquitté --> <FileXtrnlRef>REFTCC0234</FileXtrnlRef> <!-- Indique que l'acquitement concerne un TCC --> <TgtRole>CAKC</TgtRole> </FileAckRct> Compte rendu quotidien Le compte rendu quotidien est exclusivement transmis par le Système à chacun des participants. Un établissement agissant à la fois en tant que Centralisateur et en tant que TCC recevra un compte rendu quotidien pour chacune des deux fonctions. Les participants n ont pas à envoyer de compte rendu quotidien au Système. L identifiant du fichier de compte rendu quotidien a la forme suivante : «E30PCyyy» pour un Centralisateur «E30PTyyy» pour un TCC Le compte rendu quotidien ne prend en compte que les fichiers à caractère fonctionnel. Les acquittements techniques et le compte rendu quotidien de la veille ne sont pas comptabilisés. Les champs XML du compte rendu quotidien, doivent respecter l ordre indiqué ci-dessous. Ils sont encadrés par une balise <DlyRpt>. Nom Type O/F Description Tag ISO Version N O Valeur obligatoire : 1 Vrsn Nombre de fichiers reçus acquittés N(10) O Nombre de fichiers reçus par le Système et pour lesquels le Système a envoyé un acquittement technique positif (Code de retour = «00000») RcvdFileAckNb Nombre de fichiers reçus et rejetés techniquement N(10) O Nombre de fichiers reçus par le Système et pour lesquels le Système a envoyé un rejet technique (fichier d acquittement technique avec le code de retour différent de «00000») RcvdFileErrNb 47/79

48 Nom Type O/F Description Tag ISO Nombre de fichier envoyés et acquittés N(10) O Nombre de fichiers envoyés par le Système et pour lesquels le Système a reçu un acquittement technique positif (Code de retour = «00000») SntFileAckNb Nombre de fichier envoyés et rejetés techniquement N(10) O Nombre de fichiers envoyés par le Système et pour lesquels le Système a reçu un acquittement technique négatif (fichier d acquittement technique avec le code de retour différent de «00000») SntFileErrNb Nombre de fichier envoyés et non répondus N(10) O Nombre de fichiers envoyés par le Système et pour lesquels le Système n a pas reçu d acquittement technique SntFileNotAckNb Rôle du destinataire Enumération A(4) C Ce tag contient le rôle TCC ou Centralisateur du destinataire. Quand un participant tient les 2 rôles, ce tag permet en particulier de distinguer si le compte-rendu quotidien concerne la fonction TCC ou Centralisateur. TgtRole (TargetRole) Valeurs possibles : IAGT (Issuer Agent, Centralisateur) CAKC (CustodyAccountKeeper, TCC) Exemple Fichier DailyReport.xml <?xml version="1.0" encoding="utf-8"?> <DlyRpt> <!--Version--> <Vrsn>1</Vrsn> <!-- Nombre de fichiers reçus acquittés OK en retour--> <RcvdFileAckNb>10</RcvdFileAckNb> <!-- Nombre de fichiers reçus en erreur --> <RcvdFileErrNb>2</RcvdFileErrNb> <!-- Nombre de fichiers envoyés et acquittés OK en retour --> <SntFileAckNb>10</SntFileAckNb> <!-- Nombre de fichiers envoyés et acquittés KO en retour (erreur) --> <SntFileErrNb>0</SntFileErrNb> 48/79

49 <!-- Nombre de fichiers envoyés non acquittés en retour --> <SntFileNotAckNb>0</SntFileNotAckNb> <!-- Indique que le compte-rendu quotidien concerne un Centralisateur --> <TgtRole> IAGT</TgtRole> </DlyRpt> Agrégation des données Le schéma ci-dessous illustre les règles de regroupements autorisées ou effectuées par le Système. D une manière générale, quelque soit l émetteur, un fichier répond aux règles suivantes : Il ne comporte que des messages fonctionnels du même type que le type du fichier (par exemple, le flux d instruction de vote «R02PTyyy» ne contient que des messages XML de type instruction de vote). Le type du fichier figure dans les métadonnées du fichier. Les messages dont le type est différent du fichier sont rejetés (rejet fonctionnel décrit dans les spécifications fonctionnelles générales du chantier 2). Un même fichier ne contient que des messages portants sur la même Assemblée Générale (l Assemblée Générale fait partie des métadonnées obligatoires du fichier). Un message dans lequel l identifiant d Assemblée Générale est différent de l identifiant indiqué dans les métadonnées est rejeté fonctionnellement. Ces règles ne s appliquent qu aux fichiers transportant des messages fonctionnels. Les fichiers techniques suivants sont donc exclus : Acquittement technique Compte rendu quotidien Fichier d images (voir 5.2.8) TCC Système Centralisateur Regroupement des messages : - De même nature - Sur la même Assemblée Générale Regroupement des messages : - De même nature - Sur la même Assemblée Générale Les messages peuvent concerner différents TCC Regroupement des messages : - De même nature - Sur la même Assemblée Générale Regroupement des messages : - De même nature - Sur la même Assemblée Générale Les messages peuvent concerner différents TCC 49/79

50 Les messages portant sur des Assemblées Générales différentes sont impérativement transmis par les participants (TCC ou Centralisateur) dans des fichiers différents, lors de la même vacation. Le délai minimum entre deux vacations successives est de 15 minutes. Les messages portant sur des Assemblées Générales différentes sont transmis aux participants (TCC ou Centralisateur) dans des fichiers différents, lors de la même vacation. L horaire et la fréquence de la vacation sont choisis par le participant au travers du formulaire d inscription (voir 5.2.7). En règle générale, tous les messages d un même type portant sur la même Assemblée Générale sont transmis dans un même fichier. Néanmoins, les API de cryptage actuellement à disposition des participants (version 0.8, voir annexe 7) effectuent leur traitement en mémoire, et imposent une limite technique sur la taille des données manipulées, fixée à 10Mo. En conséquence, la prise en compte de gros volumes de données a conduit aux dispositions - qui dérogent à la règle générale - suivantes : Fichiers émis par Votaccess : Quand le volume de données pour une même Assemblée Générale excède la taille limite imposée par l API de cryptage/décryptage, Votaccess transmet les données en plusieurs fichiers dans la même vacation. Par souci de simplicité, la taille limite est définie en nombre de messages, et fixée à 2000 messages. Exemple : Si dans une même vacation, Votaccess doit envoyer 5000 instructions de vote à un Centralisateur, 3 fichiers (2000, 2000 et 1000 instructions de vote) seront transmis. Fichiers émis par les participants : Votaccess laisse le choix au participant (TCC ou Centralisateur) de traiter les gros volumes de données à sa convenance. Le participant peut soit scinder les messages en plusieurs fichiers au cours d une même vacation, soit transmettre tous les messages dans un même fichier de taille arbitraire. Une extension des API de cryptage a été développée. Elle effectue ses traitements sur des flux (disque dur par exemple) plutôt qu en mémoire et permet donc de s affranchir de la limite des 10Mo. En parallèle, cette API autorise la compression des données, permettant l accélération du temps de transfert des fichiers (voir 5.2.9). Pour le participant qui souhaite crypter des données dépassant la taille limite imposée par l API mémoire, il est nécessaire d utiliser l API flux mise à disposition (version 0.9, voir annexe 7). Quand Votaccess reçoit un fichier qui dépasse la taille limite, le décryptage s effectue sur flux plutôt qu en mémoire Fréquences et horaires des transferts de fichiers Principes Quand il remplit le formulaire de raccordement technique, le participant peut préciser, pour chacun des types de flux fonctionnels (flux de numéros 0 à 10) émis par le Système, la fréquence et les horaires des vacations. Une vacation correspond à l émission de fichiers de même nature selon les modalités d agrégation exposées Quand le participant gère simultanément plusieurs Assemblées Générales, il peut envoyer au cours d une même vacation autant de fichiers que d Assemblées Générales en cours. Les horaires et la fréquence de diffusion des flux techniques ne peuvent être définis par les participants : Le fichier d acquittement technique est émis par le Système dès réception d un flux fonctionnel. 50/79

51 N occurrences quotidiennes Système de Collecte de Vote Pré-AG Le fichier contenant le compte rendu quotidien est émis tous les matins à 0h01. Les fichiers image sont transférés vers le Centralisateur dès leur transfert par le TCC sur le Système. Voir La fréquence et les horaires d émission par le participant sont libres, mais il est rappelé que le transfert de fichier n est pas conçu pour effectuer des échanges en temps réel, et que le délai entre deux vacations vers le Système doit être supérieur à 15 minutes. Centre de traitement TCC Système Centralisateur Fichiers de données ou images Fréquence par vacation : 15 minutes minimum Acquittement technique Fréquence : Dès réception d un fichier Fichiers d images Fréquence : dès réception par le Système d un fichier images en provenance du TCC Fichiers de données Fréquence par vacation : Choisie par le Centralisateur (formulaire RF02) Fichiers de données Fréquence par vacation : Choisie par le TCC (formulaire RF02) Acquittement technique Fréquence : Dès réception d un fichier données ou images Acquittement technique Fréquence : Dès réception d un fichier Fichiers de données Fréquence par vacation : 15 minutes minimum Acquittement technique Fréquence : Dès réception d un fichier Compte rendu quotidien Fréquence : tous les jours à 00h01 Compte rendu quotidien Fréquence : tous les jours à 00h01 Les possibilités de paramétrage pour les fichiers émis par le Système sont celles offertes par cron, un outil standard permettant, à des dates et heures spécifiées à l avance, ou selon un cycle définit à l avance, d exécuter des scripts ou des commandes Paramétrage du Système Dans le formulaire technique de raccordement, le participant pourra en regard de chaque flux émis par le Système : soit indiquer directement les fréquences et horaires de diffusion dans le formalisme cron soit les indiquer sous forme textuelle La syntaxe cron est composée de 5 champs : MINUTES : Les minutes dans une heure (0-59) HEURES : Les heures dans une journée (0-23) JOURMOIS : Le jour dans un mois (1-31) MOIS : Le mois (1-12) JOURSEMAINE : Le jour de la semaine (0-7) où 0 et 7 représentent le dimanche 51/79

52 Pour spécifier des valeurs multiples pour un champ, il est possible d utiliser les opérateurs suivants, par ordre de précédence : '*' représente l'ensemble des valeurs possibles. 'M-N' représente une liste bornée, telle que "1-5" 'M-N/X' ou '*/X' permettent de spécifier des sauts de valeur X dans la liste. Par exemple, "*/15" dans le champ MINUTES est équivalent à "0,15,30,45" et "1-6/2" à "1,3,5" 'A,B,...,Z' permet de spécifier des valeurs multiples, comme "0,30" ou "1,3,5" Exemple : Diffusion tous les lundi, mardi, mercredi, jeudi, vendredi à 18 h et à 19h s exprime aussi de la façon suivante : 0 18,19 * * 1,2,3,4,5 Diffusion tous les jours une fois par heure, après la demi-heure, s exprime aussi de la façon suivante : 30 * * * * Cas particulier des images du vote numérisé Les fichiers transportant les images sont soumis à la même cinématique de maillonnage que les fichiers de données. Les fichiers images reçus d un TCC sont décryptés par le Système et, avant transmission vers le Système du Centralisateur, recryptés avec la clé du Centralisateur. Les fichiers images transmis au Centralisateur ne sont pas agrégés par Assemblée Générale : le Système ne regroupe pas toutes les images concernant une même Assemblée Générale, et provenant de différents TCC Rappel des règles mentionnées dans le code de bonnes pratiques concernant les fichiers images: Le format des images recommandé est.tiff Nommage des fichiers images : les fichiers sont identifiés avec un nom unique reprenant les informations suivantes : Identifiant de l AG Identifiant du TCC Identifiant du TCF Identifiant de l actionnaire N de séquence dans le fichier. Tous ces identifiants sont reliés par un «_» sans blanc. Taille des fichiers images : entre 50 et 70 k. afin de limiter les volumes manipulés, le nombre maximum d images dans un lot est de 500 unités. le nombre minimum d images est 1 Le système ne fait aucun contrôle sur ces éléments mais le respect de ces règles permet une utilisation sans dégradation de performance du service de collecte de vote pré AG Compression des données [Paragraphe ajouté dans la version 1.10 des SFG] La version 0.9 des API de cryptage/décryptage offre aux participants la possibilité de compresser les données. Compte tenu de la structure des données transportées, le taux de compression dépasse les 10% 52/79

53 et réduit de manière radicale les temps de transport (un fichier en clair 10Mo peut être transformé en un fichier compressé et crypté de 1Mo ou moins). La compression apporte un gain significatif sur les données de type texte, elle est donc appliquée avant le cryptage qui produit des données binaires. Le booléen indiquant au destinataire d un fichier si les données véhiculées sont ou non compressées est enregistré dans la partie c1 (voir 5.2.1) du fichier composite. Il permet au destinataire de déterminer s il faut ou non décompresser les données stockées dans la partie c0 du fichier composite. Votaccess sera en mesure de traiter les fichiers compressés par les participants dès janvier En revanche, Votaccess n appliquera pas la compression tant que tous les participants n auront pas migré sur la nouvelle version (version 0.9) des API de cryptage. L algorithme de compression/décompression est accessible aux méthodes de cryptage/décryptage opérant aussi bien en mémoire que sur des flux. Il est inutile d utiliser la compression pour le transfert de session. Voir l annexe 7 pour les détails techniques de la nouvelle implémentation des API de cryptage/décryptage. 53/79

54 6 Poste administrateur Le poste administrateur est mis à disposition de tous les établissements contribuant au Système. Le poste administrateur est unique, quelque soit le rôle (TCC ou Centralisateur) de l établissement dans le Système. L interface graphique du poste repose globalement sur les mêmes principes que les postes TCC et Centralisateur décrits par ailleurs (spécifications fonctionnelles générales des chantiers 3 et 4). En particulier, l ensemble des fonctions du poste sont présentées dans des écrans séparés, organisés sous forme d onglets. Suivant le rôle du participant, les onglets mis à disposition de l administrateur varient. Un établissement qui assure les fonctions TCC et Centralisateur, dispose d un unique poste d administration, proposant les écrans liés aux deux fonctions. L administrateur est en charge d un établissement, et non d un participant. Le poste décrit dans ce chapitre permet à l administrateur d un établissement : D une part, d effectuer les tâches de paramétrage nécessaires au bon fonctionnement du Système en particulier : La gestion des certificats Dans le cas du TCC, l administration du référentiel participant. D autre part de gérer tous les utilisateurs opérationnels de l établissement : Utilisateur du poste TCC Utilisateur du poste Centralisateur L administrateur peut aussi, s il dispose des privilèges adéquats (rôles), créer d autres administrateurs au sein du même établissement. Dans le cas d un TCC, le référentiel participant décrit : Les identifiants des différents intervenants (site Web des distributeurs et teneurs de compte finaux) L ensemble des contacts de l établissement : Contact technique Cette personne doit avoir connaissance de la dimension réseau mise en place entre le Participant et le Système. Elle est destinatrice d alertes suite à incidents techniques sur le Système (par exemple dans le cas où le transfert de session échoue, dans le cas où un certificat approche de la date d expiration, etc.) Cette personne est le contact pour l échange des mots de passe techniques. Correspondant métier Personne chez le Participant appelée par SLIB en cas d incident fonctionnel sur le Système. Cette personne est référencée chez SLIB comme le point de contact lors d appels en cas d incident. Des alertes de type fonctionnel peuvent être adressées par le Système à ce correspondant (par exemple, mail d alerte lorsque le seuil de 80% des numéros disponibles pour la délivrance des cartes d admission est atteint) Contact continuité d activité Ce contact est informé, de la mise en place d une cellule de Crise, et de la communication liée à cette mise en place. Correspondant sécurité Cette personne est destinatrice des fiches d incidents de sécurité émises suite à détection, par SLIB ou le Participant, d une violation (potentielle ou effective) de la politique de sécurité du Système. 54/79

55 Le référentiel participant est partiellement initialisé par SLIB, à partir des informations communiquées par les participants via les formulaires RF01 et RF02. La gestion des utilisateurs concerne les aspects suivants : Authentification (qui permet la mise en œuvre de la politique de sécurité des utilisateurs) Autorisations (qui décrivent les applications autorisées à un utilisateur). Le terme application désigne les postes interactifs mis à disposition des participants (poste TCC, poste Centralisateur ou poste administrateur). Habilitations (qui définissent les fonctions autorisées à un utilisateur sur une application donnée) Un administrateur d un établissement qui assure la fonction de TCC dispose des écrans : Certificats utilisés dans les transferts de fichiers ( 6.1) Déclaration TCF ( 6.2) Déclarations Site Web du distributeur ( 6.3) Contacts ( 6.4) Gestion des rôles ( 6.5) Gestion des utilisateurs ( 6.6) Confidentialité TCC ( 6.7) Piste d audit ( 6.8) Un administrateur d un établissement qui assure la fonction de Centralisateur dispose des écrans : Certificats utilisés dans les transferts de fichiers ( 6.1) Contacts ( 6.4) Gestion des rôles ( 6.5) Gestion des utilisateurs ( 6.6) Piste d audit ( 6.8) La confidentialité d un utilisateur du poste Centralisateur n est pas gérée dans le poste administrateur. C est le créateur de l Assemblée Générale qui autorise l accès aux utilisateurs (cf. spécifications fonctionnelles générales du chantier 3). Un administrateur d un établissement qui assure la fonction de prestataire technique d un TCC dispose des écrans : Certificats utilisés dans les transferts de fichiers ( 6.1) Contacts ( 6.4) Gestion des utilisateurs ( 6.6) Piste d audit ( 6.8) 6.1 Certificats utilisés dans les transferts de fichiers Les certificats permettent de signer et crypter les échanges entre le Système et l établissement. Un établissement qui assure les fonctions TCC et Centralisateur utilise un certificat commun pour signer les fichiers relatifs à la fonction TCC et les fichiers relatifs à la fonction Centralisateur. L administrateur peut : Télécharger (dowloader) le certificat courant (clé publique) du Système. Pendant la période de recouvrement, télécharger en avance le futur certificat du Système Télécharger (uploader) sur le Système le certificat du participant Révoquer son propre certificat 55/79

56 Préalablement à la révocation ou l expiration du certificat courant, télécharger sur le Système le nouveau certificat du participant Une liste présente à l administrateur l ensemble des certificats qu il a transmis au Système. Chaque ligne présente au minimum : Un numéro de certificat (attribué par le Système L empreinte du certificat (40 caractères hexadécimaux), communiquée lors des échanges dans les métadonnées des fichiers composites L organisme de certification La date de début de validité du certificat La date d expiration du certificat 6.2 Déclarations TCF Depuis cet écran, l administrateur a accès à la liste de tous les TCF, appartenant au TCC. L écran présente les TCF sous forme de table. Il a la possibilité de créer, modifier ou supprimer un TCF. Les attributs obligatoires d un TCF sont : L identifiant du TCF L écran de saisie de l identifiant permet de saisir un identifiant au format indiqué 2.1. L administrateur doit sélectionner le type de codification et indiquer le code correspondant dans un champ de saisie. Si le type de codification choisi est «SYSC», le code est attribué par le Système et non modifiable Le nom en clair du TCF. Ce nom est visible dans certains filtres du poste TCC. 6.3 Déclarations Site Web du distributeur Depuis cet écran, l administrateur a accès à la liste de tous les sites Web, affiliés au TCC. L écran présente les sites Web sous forme de table. L administrateur a la possibilité de créer, modifier ou supprimer un site web. Les attributs obligatoires d un site web sont : L identifiant du Site Web L écran de saisie de l identifiant permet de saisir un identifiant au format indiqué 2.1. L administrateur doit sélectionner le type de codification et indiquer le code correspondant dans un champ de saisie. Si le type de codification choisi est «SYSC», le code est attribué par le Système et non modifiable Le nom en clair du site web. L administrateur doit à partir de cet écran : Télécharger (uploader) sur le Système son certificat, utilisé dans le cryptage du transfert de session Préalablement à la révocation ou l expiration du certificat courant, télécharger sur le Système le nouveau certificat du site web Il peut en outre : Révoquer son propre certificat 56/79

57 Définir l url de notification. A l issue du vote par l actionnaire depuis le frontal de vote en ligne, une requête http est envoyée vers cette url. Si elle n est pas renseignée, le Système n envoie pas de compte rendu d instruction de vote. Le Système n effectue aucune vérification sur l adresse saisie. En cas d erreur, les notifications échoueront. Renseigner un ou plusieurs contacts techniques. En cas de problème lors du transfert de session, un mail sera envoyé à l adresse indiquée dans le contact. 6.4 Contacts L écran de contact permet d administrer l ensemble des contacts dans l établissement, en relation avec le Système. L administrateur peut créer, supprimer, modifier les contacts. Un contact est associé par l administrateur à une ou plusieurs fonctions : Contact technique Contact opérationnel Contact sécurité Contact métier SLIB initialise les contacts à partir du formulaire RF01 rempli par le participant. 6.5 Gestion des rôles Les habilitations d un utilisateur sont définies par un ou plusieurs rôles qui lui sont attribués. Les rôles sont définis par la composition d une ou plusieurs fonctions élémentaires. Quelques rôles standards (et non modifiables) sont disponibles, par application sur le Système. Les fonctions élémentaires disponibles sur les 3 applications interactives sont données en annexe 5. Via l écran de «Gestion des rôles», l administrateur peut : Construire, modifier et supprimer des rôles supplémentaires, en fonction de l organisation de son établissement. Consulter l ensemble des rôles disponibles Les rôles sont structurés par application (Poste TCC, poste Centralisateur ou poste d administration) Un établissement qui n assure que la fonction TCC peut gérer les rôles liés au poste TCC et au poste d administration Un établissement qui n assure que la fonction Centralisateur peut gérer les rôles liés au poste Centralisateur et au poste d administration L administrateur des utilisateurs peut créer de nouveaux rôles, selon les besoins de son établissement. Il ne peut modifier ou supprimer que des rôles créés par lui-même ou un autre administrateur du même établissement L écran spécifique permettant la création ou la modification d un rôle permet de : Nommer le rôle Sélectionner, parmi l ensemble des fonctions élémentaires de l application, celles composant le rôle Les rôles sont affectés aux utilisateurs dans l écran de gestion des utilisateurs. 57/79

58 6.6 Gestion des utilisateurs L écran de gestion des utilisateurs permet de : Créer un utilisateur Supprimer un utilisateur Attribuer ou supprimer des autorisations et rôles à l utilisateur. Quand l administrateur crée un nouvel utilisateur, il renseigne impérativement les attributs suivants : Nom, prénom, tels qu ils apparaitront dans la piste d audit des opérations effectuées par l utilisateur. Le nom et le prénom sont aussi affichés sur l écran du poste de l utilisateur Login, l identifiant que devra saisir l utilisateur pour se connecter sur le poste Mot de Passe initial. Selon les règles définies , ce mot de passe devra être changé par l utilisateur dès la première utilisation du poste Un indicateur précisant si l utilisateur peut se connecter au poste en utilisant une connexion internet. Si c est le cas, le Système affecte une bingo card à l utilisateur en question. Le login et le mot de passe seront communiqués au nouvel utilisateur par l administrateur de l établissement. La liste des applications et rôles autorisés est vide à la création d un nouvel utilisateur. L administrateur peut ensuite autoriser un utilisateur à utiliser : Le poste administrateur, auquel cas l utilisateur dispose de la fonction d administrateur Soit le poste TCC si l établissement n assure que la fonction TCC, soit le poste Centralisateur si l établissement n assure que la fonction Centralisateur, soit l un des deux ou les deux si l établissement assure les deux fonctions. Il s agit d un utilisateur fonctionnel. Un administrateur (i.e. un utilisateur autorisé à utiliser le poste administrateur) ne peut utiliser le poste TCC ou le poste Centralisateur. L interface graphique du poste administrateur interdit le cumul par un même utilisateur des fonctions opérationnelles et administratives. Pour outrepasser cette contrainte, il est nécessaire de créer pour le même utilisateur deux comptes différents. L administrateur peut affecter ou retirer des rôles (définis 6.5) à tous les utilisateurs fonctionnels de l établissement. 6.7 Confidentialité TCC L écran permet à l administrateur du TCC de restreindre un utilisateur aux données issues de certains TCF du TCC. 6.8 Piste d audit Les opérations enregistrées dans la piste d audit et visibles depuis l écran «Piste d audit» sont les suivantes : Création d un utilisateur Suppression d un utilisateur Modification des autorisations d un utilisateur Modification des habilitations d un utilisateur Autorisation d un ou plusieurs rôles Interdiction d un ou plusieurs rôles Modification de la confidentialité Modification des attributs de l utilisateur 58/79

59 Les informations sont présentées sous forme tabulaire. Chaque ligne présente les informations suivantes : Le nom et le prénom de l utilisateur qui a fait l objet d une modification L horodatage de l opération Le détail de l opération Un filtre permet de ne consulter que les opérations liées à un utilisateur spécifié, pendant une période donnée. La liste présente le login de tous les utilisateurs déclarés par l administrateur de l établissement. Le filtre est initialement vide. 59/79

60 Annexes Annexe 1 Liste Noire. Les chaînes de caractères suivantes ne sont pas autorisées dans les champs véhiculés dans l application du fait des risques inhérents au web. Les risques sont qualifiés en 2 grandes familles : SQL injection et Cross Frame Scripting ( XFS). SQL XFS -- <a /* <applet */ <body ' ; <embed <form ' concat <frame ' or <head ' and <html ' not <iframe ' group by <img ' having <input ' order by <link ' fetch first <marquee ' for update <noframes ' for read <object ' optimize for <script ' with <style ' union <xml ' except style = ' intersect onxyz = javascript: createattribute ( createelement ( eval ( write ( writeln ( // /* */ " ) " } " ; " + ' ) ' } ' ; ' + 60/79

61 Annexe 2 Liste des identifiants d échanges de fichier Emetteur Destinataire Code flux Type de fichier Description Code Pesit Dossier FTP Centralisate ur Système 0 REFR Référentiel Assemblée Générale R00PCyyy yyy/r00pc Centralisate ur Système 3 ITRP Compte rendu d'intégration de vote R03PCyyy yyy/r03pc Centralisate ur Système 6 CPCD Carte d'admission enrichie R06PCyyy yyy/r06pc Centralisate ur Système 31 Acquittement technique R31PCyyy yyy/r31pc Système Centralisateur 2 VOTE Instruction de vote E02PCyyy yyy/e02pc Système Centralisateur 5 SLIP Bordereau E05PCyyy yyy/e05pc Système Centralisateur 7 FCRJ Rejet fonctionnel E07PCyyy yyy/e07pc Système Centralisateur 10 ADIN Renseignement complémentaire E10PCyyy yyy/e10pc Système Centralisateur 20 SCAN Partie image des votes numérisés E20PCyyy yyy/e20pc Système Centralisateur 30 DRPT Compte rendu quotidien E30PCyyy yyy/e30pc Système Centralisateur 31 Acquittement technique E31PCyyy yyy/e31pc TCC Système 2 VOTE Instruction de vote R02PTyyy yyy/r02pt TCC Système 5 SLIP Bordereau R05PTyyy yyy/r05pt TCC Système 8 CLRQ Demande d'annulation R08PTyyy yyy/r08pt TCC Système 9 BLUP Modification de position R09PTyyy yyy/r09pt TCC Système 20 SCAN Partie image des votes numérisés R20PTyyy yyy/r20pt TCC Système Acquittement technique R31PTyyy yyy/r31pt Système TCC 0 REFR Référentiel Assemblée Générale E00PTyyy yyy/e00pt Système TCC 4 VTRP Compte rendu d'instruction de vote E04PTyyy yyy/e04pt Système TCC 7 FCRJ Rejet fonctionnel E07PTyyy yyy/e07pt Système TCC 30 DRPT Compte rendu quotidien E30PTyyy yyy/e30pt Système TCC 31 Acquittement technique E31PTyyy yyy/e31pt Prestataire Système 2 VOTE Instruction de vote R02PPyyy yyy/r02pp Prestataire Système 20 SCAN Partie image des votes numérisés R20PPyyy yyy/r20pp Prestataire Système 31 Acquittement technique R31PPyyy yyy/r31pp Système Prestataire 7 FCRJ Rejet fonctionnel E07PPyyy yyy/e07pp Système Prestataire 31 Acquittement technique E31PPyyy yyy/e31pp 61/79

62 Annexe 3 Eléments techniques de cryptage Nous appellerons F le fichier contenant les données à transmettre. Rappels sur les certificats L émetteur et le récepteur possèdent chacun un certificat qui contient une clé publique. L émetteur et le récepteur se transmettent leurs certificats. La clé privée correspondant à la clé publique d un certificat est contenue dans le magasin de clés à partir duquel a été générée la demande de certificat. Cette clé privée n est jamais transmise. En résume, chaque partie possède : sa clé privée sa clé publique la clé publique de l autre partie Signature des données Le terme signature est employé ici au sens cryptographique du terme : il ne s agit, au sens légal du terme, ni de signature électronique, ni de signature électronique sécurisée, ni de signature électronique avancée. Principe de fonctionnement Une signature de données consiste à crypter une empreinte de ces données avec une clé privée. Cette signature pourra être vérifiée sur les données avec la clé publique correspondant à la clé privée utilisée lors de la signature. Pour traiter les signatures, nous utiliserons l algorithme SHA-256 pour l empreinte en association avec l algorithme de cryptage asymétrique RSA. Les clés de cryptage RSA auront une longueur de 2048 bits. La signature considérera F comme une suite d octets. La signature générée sera alors une suite de 256 octets. Nous appellerons : S la signature du fichier F ; KPE la clé privée de l émetteur ; KE la clé publique de l émetteur. On a alors : S = RSA_CRYPT( SHA( F ), KPE ) Le récepteur vérifiera la signature S du fichier F avec KE, la clé publique de l émetteur si l expression suivante est vraie : En pratique RSA_DECRYPT( S, KE ) = SHA( F ) 62/79

63 Les APIs proposent généralement d effectuer la signature en une seule opération. Il n y a donc pas besoin de faire l empreinte puis de la crypter. On a alors pour la signature : S = SHA_RSA _SIGN ( F, KPE ) Et pour la vérification de la signature : SHA_RSA VERIFY( S, KE, F ) Cryptage symétrique Le cryptage symétrique sera utilisé pour le cryptage des données avec une clé générée aléatoirement. L algorithme de cryptage symétrique sera AES avec une clé de 128 bits. Le mode de gestion des blocs sera CBC et le remplissage de bloc utilisera l algorithme PKCS#5. On prendra les valeurs initiales de cryptage suivantes, en hexadécimal : c9, 36, ea, 78, d9, 36, 99, 3e, 36, 78, 52, 78, 3e, ea, 3e, f2. La clé symétrique générée K sera une suite de 16 octets. Le cryptage symétrique considérera F comme une suite d octets et produira une suite d octets. Nous appellerons : K la clé de cryptage de 128 bits générée aléatoirement ; C0 le fichier F crypté symétriquement avec la clé K. On a alors : C0 = AES_CRYPT( F, K ) Le récepteur décryptera C0 avec la clé K : F = AES_DECRYPT( C0, K ) Cryptage asymétrique La signature S et la clé de cryptage symétrique K doivent être cryptées asymétriquement avec la clé publique du récepteur. L algorithme de cryptage asymétrique sera RSA avec des clés de 2048 bits. Le mode de gestion de bloc sera EBC et le remplissage de bloc utilisera l algorithme PKCS#1. Ce cryptage RSA ne permettant de crypter au maximum que 2048 bits / 8 bits -11 octets = 245 octets. Comme la signature S a une taille de 256 octets, nous effectuerons le cryptage de S et K de la manière suivante : 63/79

64 un premier cryptage sur la première moitié de S concaténée à K soit =144 octets. [A partir de la version 1.10 des sfg : ] Pour le transfert de fichier, le participant a la possibilité d utiliser les API de cryptage sur flux (version 0.9, voir annexe 7), qui autorisent la compression des données fonctionnelles, stockées dans l élément C0. L indicateur de compression est codé sur un octet, ajouté à la suite de S et K. La taille totale du premier cryptage, quand la version 0.9 des API est utilisée, est donc de 145 octets. un deuxième cryptage sur la deuxième moitié de S soit 128 octets Chaque cryptage produira une suite de 256 octets. Nous appellerons : KR la clé publique du récepteur, C1 le premier cryptage, C2 le deuxième cryptage, IC l indicateur de compression On aura alors : et C1 = RSA_CRYPT( 1 ère moitié( S ) + K + IC, KR ) C2 = RSA_CRYPT( 2 ème moitié( S ), KR ) Le récepteur décryptera C1 et C2 avec sa clé privée KPR : et 1 ère moitié( S ) + K + IC = RSA_DECRYPT( C1, KPR ) 2 ème moitié( S ) = RSA_DECRYPT( C2, KPR ) C1 (256 octets) Cryptage RSA Décryptage RSA 1 ère moitié de S (128 octets) Clé de cryptage K (16 octets) Indicateur de compression IC (1 octet) Synthèse Algorithmes utilisés 64/79

65 Signature : SHA-256 avec RSA et clé de 2048 bits Cryptage symétrique : AES, mode CBC, remplissage de bloc PKCS#5 et clé de 128 bits Cryptage asymétrique : RSA, mode EBC, remplissage de bloc PKCS#1 et clé de 2048 bits Cryptage Les opérations de cryptage d un fichier F avec la clé privée de l émetteur KPE et la clé publique du récepteur KR sont les suivantes : création de la signature S de 256 octets : S = RSA_CRYPT( SHA( F ), KPE ) ou S = SHA_RSA_SIGN( F, KPE ) génération de la clé de cryptage symétrique K de 16 octets cryptage de F en C0 : C0 = AES_CRYPT( F, K ) cryptage de S, K et IC en C1 (256 octets) et C2 (256 octets) : C1 = RSA_CRYPT( 1 ère moitié( S ) + K + IC, KR ) C2 = RSA_CRYPT( 2 ème moitié( S ), KR ) Le cryptage a produit trois éléments : Le fichier crypté symétriquement C0 Un premier cryptage asymétrique C1 Un deuxième cryptage asymétrique C2 Décryptage Le fichier C0 ne peut être décrypté qu avec la clé K qui ne peut être récupérée qu en décryptant C1 avec la clé privée du récepteur KPR. Le décryptage de C1 donne aussi accès à l indicateur de compression IC qui détermine si le fichier C0 doit être décompressé suite à son décryptage. Les opérations de décryptage de C0, C1 et C2 avec la clé publique de l émetteur KE et la clé privée du récepteur KPR sont les suivantes : décryptage de C1 et C2 : 1 ère moitié( S ) + K + IC = RSA_DECRYPT( C1, KPR ) 2 ème moitié( S ) = RSA_DECRYPT( C2, KPR ) décryptage de C0 : F = AES_DECRYPT( C0, K ) si IC = 1, décompression de C0 vérification de la signature S : RSA_DECRYPT( S, KE ) = SHA( F ) ou SHA_RSA_VERIFY( S, KE, F ) Le fichier F est alors décrypté, authentifié et son intégrité est assurée. L annexe 7 décrit les API de cryptage mise à disposition des participants. 65/79

66 Annexe 4 Liste des codes erreur pour l acquittement La table ci-dessous recense l ensemble des codes erreur autorisés dans le champ code de retour (tag XML <StsCd>) du fichier d acquittement technique (voir ). Code Description Maillonnage (voir 5.2.5) F0004 F0005 F0006 F0007 F0008 F0009 F0010 Acquittement Le fichier a été correctement ouvert, dézippé et décrypté Les métadonnées sont correctement renseignées L acquittement technique n est pas corrélé au contenu fonctionnel des messages inclus dans la partie donnée du fichier Rejet Le numéro de séquence (tag <SeqNb>) est formaté de manière incorrecte ou est absent des métadonnées Le numéro de séquence doit être un entier positif Rejet Le numéro de série du certificat de l émetteur (tag <SndrCertSrlNb>) est absent des métadonnées Ce tag est obligatoire Rejet Le numéro de série du certificat du destinataire (tag <TgtCertSrlNb >) est absent des métadonnées Ce tag est obligatoire Rejet L horodatage d émission du fichier (tag <SndgFileDtAndTm >) est absent des métadonnées Ce tag est obligatoire Rejet Le tag <PtyIdCd> (type de codification pour l identification de l émetteur) est absent des métadonnées Rejet Le tag <Cd> (identifiant de l émetteur dans la codification choisie) est absent des métadonnées Rejet Le numéro de séquence attendu est incrémenté Le numéro de séquence attendu est inchangé Le numéro de séquence attendu est incrémenté Le numéro de séquence attendu est incrémenté Le numéro de séquence attendu est incrémenté Le numéro de séquence attendu est incrémenté Le numéro de séquence attendu est incrémenté Le numéro de séquence attendu est incrémenté 66/79

67 Code Description Maillonnage (voir 5.2.5) Soit le tag obligatoire <Vrsn> est absent des métadonnées Soit la version (tag <Vrsn>) reçue est différente de la version attendue par le destinataire du message. F0011 Rejet L identifiant de l émetteur (tag <PtyId>) est absent des métadonnées Ce tag est obligatoire Rejet L identifiant de l émetteur (tag <PtyId>) est incorrect Le numéro de séquence attendu est incrémenté F0012 Quand le transport des données se fait par fichier, le Système maintient dans son référentiel le lien entre chaque nom de fichier et l identifiant du participant associé. Si l identifiant de l émetteur ne correspond pas à l identifiant attendu par le Système, ce dernier rejette le fichier. Le numéro de séquence attendu est incrémenté F0013 Rejet Le type de fichier (tag <FileTp>) est absent des métadonnées Ce tag est obligatoire Rejet Le numéro de séquence attendu est incrémenté F0014 Le type de fichier (tag <FileTp>) est incorrect La description de l erreur affiche le type de fichier reçu et le type de fichier attendu Quand le transport des données se fait par fichier, le Système maintient dans son référentiel le lien entre chaque nom de fichier et le type de donnée associé (voir 5.2.4). Si le type de fichier transmis ne correspond pas au type de fichier attendu par le Système, le fichier est rejeté Le numéro de séquence attendu est incrémenté Rejet F0015 Le numéro de séquence (tag <SeqNb>) est différent du numéro de séquence attendu. Ce cas d erreur correspond en général à la perte d un fichier (trou dans les numéros de séquence) La description de l erreur affiche le numéro reçu et le numéro attendu Le numéro de séquence attendu est inchangé F0016 Rejet Soit l identifiant de l Assemblée Générale (tag obligatoire <MtgId>) Le numéro de séquence attendu est incrémenté 67/79

68 Code Description Maillonnage (voir 5.2.5) est absent des métadonnées Soit l identifiant de l Assemblée Générale (tag <MtgId>) figurant dans les métadonnées est absent du référentiel des Assemblées Générales du système de vote. Rejet F0017 Ce code recouvre tous les cas d erreur de formatage, énumérés cidessous : La référence externe transmise par l émetteur (tag < FileXtrnlRef >) est formatée de manière incorrecte. Cette référence comporte au plus 35 caractères. L horodatage d émission du fichier (tag <SndgFileDtAndTm >) est formaté de manière incorrecte. L horodatage doit respecter le format ISO suivant :yy-mm-ddthh:mm:ss.mmm L identifiant de l Assemblée Générale (tag <MtgId>) est formaté de manière incorrecte Le type de codification de l identifiant de l émetteur (tag <PtyIdCd>) ne correspond pas aux valeurs autorisées : BICC CCIB ECLC SYSC Le type de fichier (tag < FileTp >) ne correspond pas aux valeurs autorisées : REFR VOTE ITRP VTRP SLIP CPCD FCRJ CLRQ BLUP ADIN SCAN Le numéro de séquence attendu est incrémenté La description textuelle de l erreur détaille le tag erroné ainsi que le format attendu Rejet F0018 Le numéro de série du certificat de l émetteur (tag <SndrCertSrlNb >) est formaté de manière incorrecte. Le numéro de série comporte au plus 64 caractères. Les caractères sont exclusivement des chiffres hexadécimaux ( 0-9, a - f ) Le numéro de séquence attendu est incrémenté 68/79

69 Code Description Maillonnage (voir 5.2.5) F0019 Rejet Le numéro de série du certificat du destinataire (tag <TgtCertSrlNb >) est formaté de manière incorrecte. Le numéro de série comporte au plus 64 caractères. Les caractères sont exclusivement des chiffres hexadécimaux ( 0-9, a - f ) Le numéro de séquence attendu est incrémenté F0021 F0022 Rejet Le fichier ne peut être décrypté Le certificat de l émetteur, correspondant au n de série indiqué par le tag <SndrCertSrlNb> est inconnu Rejet Le fichier ne peut être décrypté Le certificat du destinataire, correspondant au n de série indiqué par le tag <TgtCertSrlNb> est inconnu Le numéro de séquence attendu est incrémenté Le numéro de séquence attendu est incrémenté F0023 Rejet Le fichier ne peut être décrypté Le certificat de l émetteur, correspondant au n de série indiqué par le tag <SndrCertSrlNb> est inactif (révoqué par l autorité de certification, expiré, etc.) Le numéro de séquence attendu est incrémenté F0024 F0031 Rejet Le fichier ne peut être décrypté Le certificat du destinataire, correspondant au n de série indiqué par le tag <TgtCertSrlNb> est inactif (révoqué par l autorité de certification, expiré, etc.) Rejet Le dézippage a échoué Une erreur s est produite lors du dézippage du fichier composite. Le numéro de séquence attendu est incrémenté Le numéro de séquence attendu est inchangé F0032 Rejet Le fichier de méta-données est mal formé. Il ne respecte pas le format xml. Le destinataire a pu dézipper le fichier composite mais l analyse de la partie metadata a échoué. Le numéro de séquence attendu est inchangé F0033 Rejet Le décryptage a échoué Le numéro de séquence attendu est incrémenté 69/79

70 Code Description Maillonnage (voir 5.2.5) Le destinataire dispose de tous les éléments permettant de décrypter les données, mais une erreur s est produite lors du décryptage Rejet F0041 Le fichier XML des données fonctionnelles est mal formé (i.e. ne respecte pas la syntaxe XML). Le destinataire ne peut analyser le contenu fonctionnel des messages. Le numéro de séquence attendu est incrémenté F0042 M0501 Rejet Une erreur s est produite lors de l analyse du fichier XML contenant les données fonctionnelles Rejet L Assemblée Générale indiquée dans les métadonnées (champ <MtgId > n accepte pas la transmission des images du vote numérisé. Ce code erreur ne concerne que les fichiers images Rejet Le numéro de séquence attendu est incrémenté Le numéro de séquence attendu est incrémenté M0502 Le statut actuel de l Assemblée Générale indiquée dans les métadonnées (champ <MtgId> n autorise pas la transmission des images du vote numérisé. La transmission des images est autorisée dans les états suivants : Vote Ouvert 1ère convocation Vote Fermé 1ère convocation Annoncée 2nde convocation Vote Ouvert 2nde convocation Le numéro de séquence attendu est incrémenté Voir les spécifications fonctionnelles générales du chantier 2, 3.3. Ce code erreur ne concerne que les fichiers images Rejet M0503 La transmission des images du vote numérisé n est pas autorisée tant que la date d ouverture du vote numérisé (1 ère convocation) n est pas atteinte. Le numéro de séquence attendu est incrémenté Ce code erreur ne concerne que les fichiers images 70/79

71 Annexe 5 Fonctions élémentaires La table ci-dessous recense l ensemble des fonctions élémentaires disponibles sur les trois postes mis à disposition des participants. Ces fonctions élémentaires sont utilisées par l administrateur de l établissement pour construire des rôles, qui sont ensuite affecté aux utilisateurs. Application Fonction élémentaire soumise à habilitation Signification de l habilitation Poste Centralisateur Créer une Assemblée Générale Le bouton «Nouvelle Assemblée Générale» est disponible Poste Centralisateur Poste TCC Consulter la vue «Pilotage des flux» Quand l utilisateur est habilité, l onglet «Pilotage des flux» est affiché. Dans le cas contraire, l onglet n est pas visible. Poste Centralisateur Poste TCC Acquitter alerte sur flux L utilisateur peut acquitter une alerte à partir du bouton de commande «Acquitter» de la vue «Pilotage des Flux» Poste TCC Envoyer un fichier Quand l utilisateur est habilité, le bouton «envoyer un fichier» est disponible Voir des spécifications fonctionnelles générales du chantier 4 Poste Centralisateur Poste TCC Consulter la vue «Pilotage des messages» Quand l utilisateur est habilité, l onglet «Pilotage des messages» est affiché. Dans le cas contraire, l onglet n est pas visible. Poste Centralisateur Poste TCC Acquitter alerte sur message L utilisateur peut acquitter une alerte à partir du bouton de commande «Acquitter» de la vue «Pilotage des messages» Poste Centralisateur Poste TCC Consulter la vue «Actionnaire» Quand l utilisateur est habilité, l onglet «Actionnaire» est affiché. Dans le cas contraire, l onglet n est pas visible. Poste Centralisateur Révoquer le mandataire Quand l utilisateur est habilité, le bouton révoquer est actif dans l onglet «Actionnaire». Ce bouton n est affiché que si l actionnaire possède une instruction de nature pouvoir au président ou pouvoir à un tiers valide. Poste Consulter la vue Quand l utilisateur est habilité, l onglet «Instructions» 71/79

72 Application Fonction élémentaire soumise à habilitation Signification de l habilitation Centralisateur Poste TCC «Instructions» est affiché. Dans le cas contraire, l onglet n est pas visible. Poste Centralisateur Poste TCC Consulter la vue «Statistiques» Quand l utilisateur est habilité, l onglet «Statistiques» est affiché. Dans le cas contraire, l onglet n est pas visible. Poste Centralisateur Poste TCC Consulter la vue «Piste d audit» Quand l utilisateur est habilité, l onglet «Piste d audit» est affiché. Dans le cas contraire, l onglet n est pas visible. Poste Centralisateur Consulter la vue «Distribution des Votes» Quand l utilisateur est habilité, l onglet «Distribution des Votes» est affiché. Dans le cas contraire, l onglet n est pas visible. Poste Centralisateur Autoriser des utilisateurs à l'assemblée Générale L utilisateur peut autoriser ou interdire à un utilisateur l accès à une Assemblée Générale. Poste Centralisateur Poste TCC Consulter les Assemblées Générales Quand l utilisateur est habilité, l onglet «Assemblées» est affiché. Dans le cas contraire, l onglet n est pas visible Poste Centralisateur Modifier une Assemblée Générale Quand l utilisateur est habilité, le bouton modifier est affiché sur la consultation d une Assemblée. Dans le cas contraire, le bouton n est pas visible. Seules les données indiquées comme modifiables, selon l état de l Assemblée Générale, peuvent être modifiées Poste Centralisateur Modifier une Assemblée Générale sans contrôle Quand l utilisateur est habilité, le bouton modifier est affiché sur la consultation d une Assemblée. Dans le cas contraire, le bouton n est pas visible. L utilisateur a la possibilité de modifier toutes les données du référentiel Assemblée Générale en outrepassant les contrôles standards, i.e. sans tenir compte de la sensibilité de la donnée et de l état de l Assemblée Générale. Poste Centralisateur Changer l état d une Assemblée Générale Quand l utilisateur est habilité, les boutons de changement d états sont affichés sur la consultation d une Assemblée. 72/79

73 Application Fonction élémentaire soumise à habilitation Signification de l habilitation Dans le cas contraire, aucun bouton de changement d état n est visible. Poste Centralisateur Confirmer les modifications d une Assemblée Générale Quand l utilisateur est habilité : les boutons «confirmer» et «rejeter» sont affichés sur l onglet «Modifications à confirmer» d une Assemblée. Le critère «en attente de confirmation» est affiché sur le filtre. L icône en «attente de confirmation» est affichée dans la liste résultat pour les Assemblées Générales en attente de confirmation Dans le cas contraire, les boutons ne sont pas visibles. Le filtre ne présente pas le critère «en attente de confirmation». La liste résultats des Assemblées Générales ne présente pas l information «en attente de confirmation». Poste Administrateur Créer un utilisateur Quand l utilisateur est habilité, le bouton «Ajouter» est disponible dans l onglet «Utilisateurs», partie «Utilisateurs». Poste Administrateur Modifier un utilisateur Quand l utilisateur est habilité, le bouton «Modifier» est disponible dans l onglet «Utilisateurs», partie «Utilisateurs». Poste Administrateur Supprimer un utilisateur Quand l utilisateur est habilité, le bouton «Supprimer» est disponible dans l onglet «Utilisateurs», partie «Utilisateurs». Poste Administrateur Consulter l onglet utilisateur Quand l utilisateur est habilité, l onglet «Utilisateurs» est affiché. Dans le cas contraire, l onglet n est pas visible. Poste Administrateur Changer le mot de passe d un utilisateur Quand l utilisateur est habilité, le bouton «Changer mot de passe» est disponible dans l onglet «Utilisateurs», partie «Utilisateurs». Poste Administrateur Créer un rôle Quand l utilisateur est habilité, le bouton «Ajouter» est disponible dans l onglet «Utilisateurs», partie 73/79

74 Application Fonction élémentaire soumise à habilitation Signification de l habilitation «Rôles». Poste Administrateur Modifier un rôle Quand l utilisateur est habilité, le bouton «Modifier» est disponible dans l onglet «Utilisateurs», partie «Rôles». Poste Administrateur Supprimer un rôle Quand l utilisateur est habilité, le bouton «Supprimer» est disponible dans l onglet «Utilisateurs», partie «Rôles». Poste Administrateur Créer un TCF Quand l utilisateur est habilité, le bouton «Ajouter» est disponible dans l onglet «TCF». Poste Administrateur Modifier un TCF Quand l utilisateur est habilité, le bouton «Modifier» est disponible dans l onglet «TCF». Poste Administrateur Consulter l onglet TCF Quand l utilisateur est habilité, l onglet «TCF» est affiché. Dans le cas contraire, l onglet n est pas visible. Poste Administrateur Créer un distributeur Quand l utilisateur est habilité, le bouton «Ajouter» est disponible dans l onglet «Distributeur». Poste Administrateur Modifier un distributeur Quand l utilisateur est habilité, le bouton «Modifier» est disponible dans l onglet «Distributeur». Poste Administrateur Consulter l onglet distributeur Quand l utilisateur est habilité, l onglet «Distributeur» est affiché. Dans le cas contraire, l onglet n est pas visible. Poste Administrateur Créer un contact Quand l utilisateur est habilité, le bouton «Ajouter» est disponible dans l onglet «Contacts». Poste Administrateur Modifier un contact Quand l utilisateur est habilité, le bouton «Modifier» est disponible dans l onglet «Contacts». Poste Administrateur Supprimer un contact Quand l utilisateur est habilité, le bouton «Supprimer» est disponible dans l onglet «Contacts». Poste Administrateur Consulter l onglet contact Quand l utilisateur est habilité, l onglet «Contacts» est affiché. 74/79

75 Application Fonction élémentaire soumise à habilitation Signification de l habilitation Dans le cas contraire, l onglet n est pas visible. Poste Administrateur Ajouter un certificat Quand l utilisateur est habilité, le bouton «Ajouter un certificat» est disponible dans l onglet «Certificats» Poste Administrateur Révoquer un certificat Quand l utilisateur est habilité, le bouton «Révoquer un certificat» est disponible dans l onglet «Certificats» Poste Administrateur Récupérer le certificat système Quand l utilisateur est habilité, le bouton «Récupérer un certificat du système» est disponible dans l onglet «Certificats» Poste Administrateur Consulter l onglet certificat Quand l utilisateur est habilité, l onglet «Certificats» est affiché. Dans le cas contraire, l onglet n est pas visible. Annexe 6 Liste des codes erreur pour le transfert de session La table ci-dessous recense les codes d erreurs spécifiques au transfert de session qui peuvent survenir suite au transfert de session. Code Description T0001 Un des paramètres du transfert de session (c0 ou c1 ou c2) est manquant. T0002 T0003 T0004 T0005 T0006 T0007 Le type de fichier indiqué dans les métadonnées est différent de TRSF. (qui est la seule valeur autorisée dans ce cas) Le participant (distributeur) indiqué dans les métadonnées est inconnu. Le message de transfert de session a expiré. (La date indiquée dans le transfert de session est trop ancienne) Le message fonctionnel de transfert de session ne contient aucun message de transfert de session. Un des paramètres c0 ou c1 ou c2 est mal formaté (caractères hexa attendus) L assemblée générale n est pas dans un état autorisant son affichage aux 75/79

76 Code Description actionnaires. T0008 L assemblée générale est archivée. D autres erreurs fonctionnelles non spécifiques au transfert de session peuvent survenir. La liste des codes erreurs, partagés avec les échanges de fichiers, est décrite dans les spécifications du chantier 2. Annexe 7 APIs de cryptage/décryptage Jusqu à la version 0.8 incluse, les API mises à disposition n effectuent leurs traitements qu en mémoire. A partir de la version 0.9, les API permettent au choix d effectuer les traitements en mémoire ou sur un flux (flux généré à partir d un fichier stocké sur disque par exemple). Les API 0.9 supportent aussi la compression/décompression des données, avant leur chiffrement. Compte tenu du format particulier des données, le taux de compression est d au moins 10%. Des exemples illustrant l utilisation complète des API de cryptage sont mis à disposition des participants sur le site documentaire de SLIB. Cryptage en mémoire (version 0.8) Classe Codec La classe Codec crypte ou décrypte un tableau d octets chargés en mémoire. La classe Codec est utilisée directement pour le transfert de session. La taille des données est limitée à 10Mo. Lors du cryptage, la clé privée de l émetteur et la clé publique du destinataire sont utilisées. Le résultat du cryptage (CipheredData) contient les éléments C0, C1 et C2 explicité en annexe 3. /** * Codes data. * pdata the data to code psenderprivatekeytosign the private key of the sender (a.k.a. coder) preceiverpublickeytocipher the public key of the receiver (a.k.a. decoder) the encoded data corresponding to <code>pdata</code> */ public CipheredData code( byte[] pdata, PrivateKey psenderprivatekeytosign, PublicKey preceiverpublickeytocipher ) Lors du décryptage, la clé publique de l émetteur et la clé privée du destinataire sont utilisées. Les données en entrée (CipheredData) contiennent les éléments C0, C1 et C2 explicités en annexe 3. /** * Decodes encoded data. * pciphereddata the encoded data to decode psenderpublickeytoverifysignature the public key of the sender (a.k.a. coder) preceiverprivatekeytodecipher the private key of the receiver (a.k.a. decoder) 76/79

77 the decoded data corresponding to <code>pciphereddata</code> */ public byte[] decode( CipheredData pciphereddata, PublicKey psenderpublickeytoverifysignature, PrivateKey preceiverprivatekeytodecipher ) Classe FileTransfer La classe FileTransfer crypte ou décrypte un tableau d octets chargés en mémoire. Elle est utilisée pour le transfert de fichier. La taille des données est limitée à 10Mo. La classe FileTransfer délègue le cryptage à une instance de Codec. La méthode code prend en argument les données brutes à crypter et les métadata. Le résultat est un ensemble de données composites (zip) stockées en mémoire, reprenant la structure explicitée /** * Codes data to send using a file transfer. * pdata the data to code pmetadata the meta data for <code>pdata</code> psenderprivatekeytosign the private key of the sender (a.k.a. coder) preceiverpublickeytocipher the public key of the receiver (a.k.a. decoder) the encoded data to send */ public byte[] code( byte[] pdata, FileMetaData pmetadata, PrivateKey psenderprivatekeytosign, PublicKey preceiverpublickeytocipher ) Inversement, à partir d un tableau d octets structurés sous forme de données composites (c0, c1, c2, metadata), la méthode decode retourne en mémoire les données en clair et remplit en parallèle la structure contenant les métadonnées. /** * Decodes received data after a file transfer. * pencodeddata the received data to decode pmetadata the meta data which will be filled during the decoding psenderpublickeytoverifysignature the public key of the sender (a.k.a. coder) preceiverprivatekeytodecipher the private key of the receiver (a.k.a. decoder) the received decoded data. */ public byte[] decode( byte[] pencodeddata, FileMetaData pmetadata, PublicKey psenderpublickeytoverifysignature, PrivateKey preceiverprivatekeytodecipher ) Cryptage en mémoire ou à partir d un flux (version 0.9) Deux nouvelles classes (StreamCodec et StreamFileTransfer) sont disponibles. Elles effectuent leurs traitements sur des données accédées via des flux plutôt que sur des données en mémoire. En parallèle, la méthode de cryptage peut, en fonction d un paramètre supplémentaire, effectuer de la compression. La classe StreamCodec n a pas vocation à être utilisée par les participants car il n existe aucun intérêt à effectuer le cryptage du transfert de session sur disque. Elle est uniquement utilisée par la classe StreamFileTransfer et n est donc pas documentée ici. 77/79

78 Les classes Codec et FileTransfer ont été augmentées d une 2 ème méthode code(), dont la signature a été augmentée d un booléen permettant de compresser les données. La méthode Code() originale de la version 0.8 n applique pas la compression. Classe StreamFileTransfer Deux méthodes de cryptage sont proposées, prenant en entrée le flux de données en clair et produisant un flux de données (éventuellement compressées) et cryptées. La première méthode applique par défaut la compression, la seconde compresse les données en fonction du paramètre pcompress. L indicateur de compression est stocké dans le flux résultat, afin de permettre au destinataire de déterminer s il faut décompresser les données une fois qu elles sont décryptées. Toutes les fonctions de la classe StreamFileTransfer requièrent un fichier temporaire, géré par l utilisateur de l API. /** * Codes data to send using a file transfer. * pis the input stream containing the data to code pos the output stream which will contain the encoded data to send ptmpfile the temporary working file pmetadata the meta data for <code>pdata</code> psenderprivatekeytosign the private key of the sender (a.k.a. coder) preceiverpublickeytocipher the public key of the receiver (a.k.a. decoder) */ public void code( InputStream pis, OutputStream pos, File ptmpfile, FileMetaData pmetadata, PrivateKey psenderprivatekeytosign, PublicKey preceiverpublickeytocipher ) /** * Codes data to send using a file transfer. * pis the input stream containing the data to code pos the output stream which will contain the encoded data to send ptmpfile the temporary working file pmetadata the meta data for <code>pdata</code> psenderprivatekeytosign the private key of the sender (a.k.a. coder) pcompress true to compress the stream before cipher, otherwise false preceiverpublickeytocipher the public key of the receiver (a.k.a. decoder) */ public void code( InputStream pis, OutputStream pos, File ptmpfile, FileMetaData pmetadata, PrivateKey psenderprivatekeytosign, PublicKey preceiverpublickeytocipher, boolean pcompress ) La fonction de décryptage utilise un indicateur figurant dans le flux d entrée pour déterminer si les données décryptées doivent être décompressées. /** * Decodes received data after a file transfer. * 78/79

79 pis the input stream containing the received data to decode pos the output stream which will contain the received decoded data ptmpfile the temporary working file pmetadata the meta data which will be filled during the decoding psenderpublickeytoverifysignature the public key of the sender (a.k.a. coder) preceiverprivatekeytodecipher the private key of the receiver (a.k.a. decoder) */ public void decode( InputStream pis, OutputStream pos, File ptmpfile, FileMetaData pmetadata, PublicKey psenderpublickeytoverifysignature, PrivateKey preceiverprivatekeytodecipher ) 79/79