Condition d’inaltérabilité

Toutes les données mentionnées au I-C § 50 doivent être inaltérables.

La notion d’inaltérabilité est comprise comme l’assurance de l’absence de perte d’intégrité des données enregistrées, c’est à dire que toute altération des données doit être détectée.

Pour cela, l’inaltérabilité des données dans le temps doit reposer sur un mécanisme robuste tel que le chaînage des enregistrements ou le scellement des enregistrement par signature horodatée.

La société E.I.S. a retenu la solution de chaînage des enregistrements, chaque enregistrement est cryptographiquement lié à l’enregistrement précédent, en incluant dans le calcul de l’empreinte cryptographique de l’enregistrement courant l’empreinte cryptographique de l’enregistrement précédent ainsi que la date et l’heure.

Le premier enregistrement ne pouvant pas être lié à l’enregistrement précédent, c’est donc une empreinte cryptographique virtuelle appelé « sel » qui est donc utilisée (empreinte connue uniquement par E.I.S.).

L’empreinte cryptographique est produite par un algorithme de hachage des données qui doit est conforme à l’état de l’art.
La société E.I.S. a retenu le hachage cryptographique SHA­3- 256 bits qui produit une empreinte de 64 caractères mémorisées dans les données.

Toute modification des données d’origine est détectée car l’empreinte stockée ne correspond plus à l’empreinte calculée lors la vérification.

Exemple d’empreinte de hachage SHA-3 :

Logiciels de caisse certifié

L’overlay « O_HASH.AT » version 1.0.0 et supérieure, commun aux logiciels Galion et Titan, est un module qui remplit les fonctions de hachage, de chaînage et de contrôle des données d’origine.

Les fonctions de hachage et de contrôle de l’overlay utilisent les fonctions de la bibliothèque « BdaHash32 » version 1.0.1 fournie par Prologue Software © respectant l’algorithme de hachage cryptographique SHA­3.

Le chaînage des données de règlements clients de la journée est automatiquement réalisé la nuit. Seul le chaînage d’un paiement de type espèce se fait dès son enregistrement, ce mode de paiement étant beaucoup plus sensible que les autres, il est donc non corrigeable.

Le lendemain de leur enregistrement, les factures et les paiements sont non corrigeables, que la fonction de chaînage ait fonctionné ou non pour l’enregistrement.

Si des corrections sont apportées à des opérations de règlement, que ce soit au moyen du logiciel ou système lui-même ou d’un dispositif externe au logiciel ou système, ces corrections (modifications ou annulations) s’effectuent par des opérations de “plus” ou de “moins” et non par modification directe des données d’origine enregistrées. Ces opérations de correction donnent également lieu à un enregistrement.

NB :

  • Il n’existe aucun dispositif externe permettant de réaliser des corrections, de plus les fichiers de la base de données qui sont accessibles en ODBC, le sont en lecture seule.
  • Toute facture ou paiement du jour passé en comptabilité n’est en aucun cas corrigeable, les opérations de correction ne peuvent donc s’appliquer qu’aux factures et paiements du jour et non passés en comptabilité.
Tant que la facture n’est pas éditée, celle-ci reste modifiable : une fois éditée, elle est alors corrigeable par des opérations de plus ou moins :
  • l’adresse du client facturé ou bien le client facturé est corrigeable, le changement de client est mémorisé dans le suivi de la facture.
  • les lignes d’articles imprimées ne sont pas modifiables, elles peuvent être annulées (opérations de moins générant une ligne d’annulation, les lignes annulées et d’annulation ne sont pas corrigeables), de nouvelles lignes peuvent être ajoutées (opération de plus), toute opération est mémorisée dans le suivi de la facture.

Le ticket étant automatiquement édité et obligatoirement soldé, seule l’adresse est corrigeable afin d’enregistrer l’adresse du client client facturé et imprimer une facture au nom du client. Le changement de client est mémorisé dans le suite de la facture.

Un paiement peut être annulé (opération de moins générant une ligne d’annulation ; les lignes annulées et d’annulation ne sont pas corrigeables). A l’exception des paiements de type espèces, un paiement est corrigeable. Toute correction, annulation et ajout de paiement est mémorisé dans le suivi de la facture.

Autrement dit, le logiciel de comptabilité ou de gestion ou le système de caisse doit prévoir que l’administration puisse accéder aux données d’origine enregistrées initialement ainsi qu’au détail daté (année, mois, jour, heure, minute) des opérations et des corrections apportées lorsque ces données ont fait l’objet de corrections.

La facturation, les éditions, les opérations de plus ou de moins sont tracées dans le suivi de la facture. Les enregistrements du suivi de la facture ne sont ni modifiables, ni supprimables. Ils font partis des données de règlement. (Cf.Contrôle par l’administration fiscale.)

Pour respecter la condition d’inaltérabilité, l’intégrité des données enregistrées doit être garantie dans le temps par tout procédé technique fiable.

Les données de règlement sont conservées en ligne (dans les fichiers du logiciel) et ne seront supprimées que lors de la procédure de purge. Il n’existe aucune fonction dans les logiciels Galion et Titan qui permet de modifier les données de règlement figées par le chaînage.