Le logiciel BeDesk Express fournit une piste d'audit sécurisée qui satisfait aux conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des données en vue du contrôle de l'administration fiscale.

Vous trouverez ici des informations qui concernent les spécifications techniques de cette piste d'audit ainsi que des méthodes permettant de contrôler celle-ci sans nécessairement disposer du logiciel BeDesk.

BeDesk Express est un système de facturation et ne gère pas de caisse. Il est par conséquent impossible d'enregistrer le moindre encaissement sans facture. Il faut d'abord créer une facture pour pouvoir lui associer un ou plusieurs encaissements. La facture est considérée comme payée lorsque le total des paiements reçus est égal au montant dû. A l'inverse et dans le même ordre d'idée, une note de crédit (un avoir) sera considérée comme remboursée dès lors que les montants auront été ajoutés en négatif pour atteindre le montant de la note.

Les paiements reçus sont ventilés selon 5 colonnes : espèce, chèque, virement, carte et autres. L'utilisateur peut dater et commenter ses saisies. Noter que la colonne “autres” peut aussi être utilisée pour solder une facture à l'aide d'une note de crédit en y reportant le montant de celle-ci.

Comme les paiements ne peuvent être ajoutés qu'en référence à une facture existante, chaque transaction est liée à sa facture de référence.

Une facture est aussi implicitement validée dès lors qu'elle est enregistrée. Il n'existe aucun moyen de supprimer une facture. On peut l'annuler à l'aide d'une note de crédit ou d'une facture facture rectificative. On ne peut donc qu'ajouter de nouvelles factures ou notes de crédit. Il n'est pas non plus possible d'imprimer une facture sans l'avoir préalablement enregistrée (et par là validée). Il n'y a donc pas de moyen de saisir un document “brouillon” et l'utiliser d'une manière quelconque sans l'avoir validé préalablement.

Le but du logiciel BeDesk Express consiste bien entendu à assister l'utilisateur et à l'encourager aux bonnes pratiques. Dans ce contexte, il peut être tout à fait légitime de corriger une erreur sur un document après l'avoir validé ou imprimé. Dans ce cas, le logiciel BeDesk Express demande à l'utilisateur de justifier la raison de sa modification. Ce justificatif est ajouté dans le journal d'audit en regard avec l'action correspondante.

Le journal enregistre les actions suivantes : (1) création d'une nouvelle facture, (2) l'édition du document, (3) l'ajout d'un paiement et (4) impression du document. Notez que l'impression (4) comprend également l'export PDF et l'envoi par e-mail.

La piste d'audit fournie par le logiciel est constituée d'un journal contenant toutes les opérations horodatées, archivées et sécurisées dans un format ouvert et très facile à lire sans nécessiter l'usage du logiciel BeDesk lui-même.

Le format utilisé pour l'enregistrement du journal est le format TSV (pour Tab-separated values). Il s'agit d'un format de fichier texte dans lequel les champs sont séparés par un caractère de tabulation (code : 9) et les enregistrements (les lignes) par un retour à la ligne (code : 10). Le contenu textuel est encodé à l'aide du système de codage des caractères UTF-8 (UTF-8), un format largement utilisé.

Le journal peut donc être lu facilement à partir de n'importe quel éditeur de texte, tableur ou même être importé dans une base de données.

Le journal est conçu pour qu'il ne soit seulement possible que d'ajouter de nouveaux enregistrements. Il n'est pas possible de supprimer ou de modifier le contenu sans que cela ne soit manifeste.

Le journal se vérifie par lui-même. De plus, il est soumis à un contrôle profond du logiciel. Ceci garanti la fiabilité de l'ensemble tout en augmentant considérablement le niveau de difficulté de toute tentative de falsification.

Comme indiqué plus haut, chaque opération est d'abord horodatée. Cet horodatage n'est pas effectuée sur le poste de travail de l'utilisateur. Les données sources qui constituent la description de l'opération sont d'abord empaquetées sous la forme TSV, une clé de hash SHA-256 (SHA-256) est calculée et celle-ci est envoyée vers un service d'horodatage distant. On obtient ainsi un cachet serveur horodaté de manière indépendante de la date fixée sur l'ordinateur de l'utilisateur (cette dernière peut en effet être personnalisée). Le cachet serveur est lui-même crypté à l'aide de la clé privée d'un certificat RSA 512 bits dont la clé publique peut être obtenue et vérifiée sur le site https://afsc.bedesk-express.com.

Lorsqu'une nouvelle opération est horodatée, elle est ajoutée au journal stocké sur l'ordinateur de l'utilisateur avec son cachet serveur. Avec ces données sources, le logiciel ajoute également de nombreuses informations relatives à la gestion. Il s'agit notamment des chiffres journaliers, mensuels et annuels. Le chiffre d'affaire de l'exercice est également calculé et ajouté pour l'année et le mois de l'exercice. S'y ajoutent également les totaux perpétuels et l'en-tête d'une liste de chaînage SHA-256.

La liste de chaînage est en réalité une blockchain (Blockchain). Par rapport à une chaîne simple, elle comporte une protection supplémentaire basée sur la preuve de travail (Proof-of-work system). Cette protection rend encore plus difficile la production d'un faux journal.

A ceci s'ajoute un système de vérification intégré au logiciel BeDesk. En effet, toute modification apportée à un document ou l'ajout d'un nouveau paiement implique la création d'une signature SHA-256 propre à la révision du document d'origine. Ainsi, toute modification du journal imposerait obligatoirement de reconstituer également la totalité de la base de données par ingénierie inverse, ce qui reviendrait à pirater le logiciel.

Enfin, il est utile de savoir que le logiciel fonctionne avec un service de réplication dès lors que l'utilisateur dispose d'une licence. Ce service permet notamment de travailler à plusieurs utilisateurs sur une même base de données. Pour cela, ce dispositif doit s'assurer que les données de chaque poste correspondent et contiennent exactement les mêmes données. Cela signifie donc que si le logiciel est utilisé à plusieurs, le journal d'audit est aussi exactement le même sur chaque poste. De plus, si une données est falsifiée ou corrompue sur un poste, ce poste est automatiquement déconnecté du réseau pour ne pas risqué de corrompre l'ensemble des postes qui participent au processus de réplication. L'intégrité des données de chaque poste est calculée à l'aide d'un arbre de Merkle (Merkle tree). Pour pouvoir se connecter au service de réplication et y ajouter des données, le poste doit fournir une clé de hash qui correspond à celles des données certifiées. Si la clé fournie ne correspond pas, cela signifie que les données du poste local sont corrompues et l'ajout est refusé. Il n'y aucun moyen de connaître la clé de hash correcte à l'avance. Celle-ci est calculée par rapport au contenu des fichiers locaux de la base de données. Ainsi, si la correspondance ne peut être vérifiée, l'utilisateur n'a alors aucun autre choix qu e de restaurer sa base de données à partir de la dernière sauvegarde à distance certifiée et de rétablir ainsi l'ensemble des données certifiées.

Le logiciel BeDesk archive les données du journal en temps réels. C'est pour cette raison qu'il est enregistré sous le format TSV. Il n'est donc pas nécessaire d'exporter le journal pour pouvoir le lire. Le journal est donc stocké sur le disque de l'utilisateur, mais aussi dans chaque sauvegarde de sécurité à distance. La sauvegarde de sécurité à systématiquement lieu à la fermeture du logiciel. Une nouvelle sauvegarde est donc ajoutée à la fin de chaque session d'utilisation du logiciel. Ces sauvegardes sont disponibles via le compte de l'utilisateur sur notre site https://www.bedesk-express.com ou sur demande auprès de nos services.

Pour réduire l'espace de stockage nécessaire au journal, celui-ci est cependant compressé à l'aide du format GZip. Ce format est toutefois très répandu et les fichiers constituant un journal ne présentent aucune difficulté à être décompressés.

Le logiciel BeDesk ne prévoit aucune purge des données du journal d'audit. Son intégrité est en effet assurée parce qu'il doit être fourni complet justement.

En cas de contrôle, si le logiciel est toujours utilisé, le journal peut être exporté en TSV non compressé et en format CSV. Si le logiciel n'est plus utilisé, les fichiers qui constituent le journal sont facilement accessibles et lisibles dans le dossier “audit” de la sauvegarde de sécurité de la base de données.

Il est toujours possible de récupérer le journal d'audit d'un base de données BeDesk, que le logiciel soit disponible ou non.

Bien sûr, le logiciel BeDesk-Express peut exporter son journal complet très facilement dans l'état à partir du menu “Outils” / “Piste d'audit” / “Export du journal au format TSV”.

On obtient ainsi un journal complet depuis la toute première transaction enregistrée jusqu'à la dernière en date ajoutée dans le journal.

L'utilisateur peut fournir ainsi une copie conforme de son journal complet et prêt à l'emploi.

Il est fortement conseillé d'utiliser cette méthode. Non seulement par facilité, mais aussi pour ne pas risqué d'altérer par inadvertance les fichiers originaux du journal.

Cependant, il est aussi possible de récupérer les fichiers qui composent le journal d'audit inaltérés et tels quels. Ceux-ci sont stockés dans le sous-dossier “audit” de chaque base de données BeDesk.

Les bases de données BeDesk sont toujours enregistrées dans le dossier “BeDesk-Express” sous Windows et “.BeDesk-Express” sous Mac OS X ou Linux. Ce dossier est toujours placé dans la racine du dossier de l'utilisateur courant du système d'exploitation.

Par exemple, pour la base de données “Tests” de l'utilisateur “Pierre” sous Windows, on trouvera très logiquement le dossier de sa base de données à cet emplacement : “C:\Users\Pierre\BeDesk-Express\Tests”. Si “Pierre” est un utilisateur sous Mac OS X, sa base de données se trouvera facilement à l'emplacement : “/Users/Pierre/.BeDesk-Express/Tests”.

Lorsque le dossier de la base de données est atteint, vous trouverez les dossiers suivants:

+[cache]
|
+[db]/
     |
     +[audit]/
     |       |
     |       +[0x0]/
     |             |
     |             +[doc_index]
     |             |
     |             +[log]
     |             |
     |             +[map]
     |             |
     |             +[pay_index]
     |             |
     |             +[queue]          
     |
     +[buckets]
     |
     +[columns]
     |
     +[_db_meta]
     |

Veuillez noter que les fichiers originaux du journal se trouvent dans le chemin “/db/audit/0x0/log”.

Les fichiers du journal sont nommés de cette manière [NBR DE LETTRES]x[NUMERO HEXADECIMAL]_tsv.gz.

Ainsi, lorsqu'on liste le contenu du dossier “log” dans l'ordre alphabétique des noms de fichier, ceux-ci sont classés dans l'ordre chronologique.

Il suffit donc de concaténer ses fichiers dans cet ordre pour obtenir un fichier unique contenant toutes les données du journal original également dans l'ordre.

Il y a plusieurs manière d'y arriver assez facilement. Par exemple, sous Windows, cette commande MSDOS rempli ce rôle et place le fichier résultant “journal.gz” sur le lecteur F: qui peut être une clé USB par exemple:

copy *.gz F:\journal.gz

Il ne reste plus qu'à extraire le contenu à l'aide d'un utilitaire comme 7-Zip sur Windows (le logiciel 7-Zip est disponible gratuitement sur le site http://www.7-zip.org). D'autres outils de décompression font également parfaitement l'affaire. La compression GZip utilisée est très répandue et courante.

C'est encore plus facile si vous pouvez simplement copier l'ensemble des fichiers pour les décompresser et concaténer sous Linux. Sur Linux, utilisez simplement la commande gunzip > journal.tsv -c *.gz. Cette commande décompresse les fichiers sources et concatène le tout dans le fichier journal.tsv (ou tout autre fichier de votre choix) en une seule opération.

Ainsi, il est relativement facile de récupérer le journal d'audit d'une base de données même si le logiciel BeDesk n'est pas disponible. Il suffit de disposer de la base de données ou d'une copie de celle-ci. De plus, comme le journal n'est jamais purgé, on récupère systématiquement l'ensemble de l'activité depuis son début.

Vous pouvez restaurer vos données à partir de la sauvegarde de sécurité à distance enregistrée lors de votre dernière session. Cette sauvegarde de sécurité est conservée tant que votre base de données est liée à au moins une licence active.

Hors contrat, il revient à l'utilisateur de s'assurer de la conservation des fichiers se trouvant tels quels sur son propre ordinateur.

Pour facilité la lecture de la piste d'audit et en extraire les données, le journal se présente sous la forme d'enregistrements TSV. Dans ce format, chaque valeur est séparée par un caractère de tabulation (code : 9). Les enregistrement se présentent sous la forme de lignes de texte séparées par un caractère de retour à la ligne (code : 10).

S'agissant d'un fichier texte, les caractères respectent un système d'encodage standard très commun : l'encodage UTF-8.

Il est très important de tenir compte de ces caractéristiques pour pouvoir extraire les données correctement, mais aussi réussir la validation du journal. En effet, le calcul de la clé de hash d'une chaîne de caractères encodées avec différents système d'encodage donnera des résultats différent. Voilà pourquoi nous travaillons systématiquement avec un seul et unique système d'encodage, UTF-8.

En outre, il faut savoir que chaque ligne du journal contient une clé de hash basée non seulement sur le contenu de ligne courante, mais aussi sur la clé de hash de l'ensemble de la ligne précédente. De cette manière, toute modification apportée dans une ligne peut être facilement détectée car cela brise la suite logique des clés de hash (l'enchaînement).

Nous n'utilisons qu'une seule méthode pour calculer les clés de hash. Il s'agit de la fonction SHA-256 qui fournit une clé codée sur 256 bits avec un niveau de sécurité cryptographique très élevé. S'agissant de fichiers textuels, les clés de hash sont ajoutées sous la forme de leur représentation textuelle hexadécimale. Une clé SHA-256 sous cette forme occupe donc 64 caractères. La représentation des caractères alphanumériques hexadécimaux n'utilise pas de majuscules mais uniquement des minuscules. Les caractères utilisés sont donc «0123456789abcdef». Les clés de hash sont calculées sur base de plusieurs champs, séparateurs compris (donc avec les caractères de tabulation qui séparent les valeurs). Le caractère séparateur de ligne (le caractère de retour à la ligne) n'est quant à lui jamais pris en compte.

Chaque ligne du journal contient la transaction source à l'origine de l'enregistrement. Celle-ci est également encodée en TSV/UTF-8. Elle est cependant horodatée au moment de sa création initiale. Cet horodatage ne dépend pas de la date de l'ordinateur de l'utilisateur, mais est fixé par un service de cachets distant indépendant. L'utilisateur ne peut donc pas fournir une date de manière à influencer l'horodatage. Lors de l'horodatage, le serveur inclut la clé SHA-256 qui correspond aux données sources (cette clé est calculée et fournie par le logiciel installé sur l'ordinateur de l'utilisateur) ainsi que l'identifiant de l'utilisateur, le nom de son système d'exploitation ainsi que le nom de l'ordinateur. Le cachet obtenu en retour contient ses informations ainsi que l'heure et la date enregistrée par le serveur en utilisant l'heure locale «Europe/Bruxelles». De cette manière, quelque soit le lieu où l'opération source trouve son point d'origine, la chronologie est toujours respectée. Le cachet comprend également l'adresse IP de l'ordinateur qui a effectué la demande d'horodatage auprès du service d'horodatage.

Les cachets sont parfaitement sécurisés car la réponse est cryptée à l'aide d'une clé de cryptage asymétrique RSA 512 bits. Le logiciel ne disposant que de la clé publique, il peut vérifier la validité du cachet et des données certifiées. Cependant, il ne peut pas créer un cachet valide à l'aide de cette clé publique. Les clés privées ne sont bien sûr pas disponibles.

Lorsque la transaction source est transmise et traitée par le logiciel BeDesk, un nouvel enregistrement est ajouté au journal sécurisé. De nombreuses informations sont ainsi ajoutées. Celles-ci fournissent notamment les chiffres d'affaire journaliers, mensuels et annuels (exercice). Ces valeurs fournissent en même temps les valeurs de clôture de chaque période ainsi que leur chronologie détaillée. Il y a aussi un ventilé TVA ainsi que des grands totaux perpétuels (qui ne recommencent pas à zéro en début de période). L'ensemble, c-à-d les données relatives à l'état de la gestion ainsi que la transaction source sous sa forme intégrale, est ajouté dans un nouveau bloc à la fin de la chaîne de blocs (blockchain) qui constitue le journal.

La chaîne de blocs utilise aussi la fonction SHA-256 pour assurer le chainage. L'altération d'un seul caractère implique l'invalidation de toute la chaîne. Cependant, l'enchainement n'est pas le seule dispositif de sécurisation utilisé. La chaîne de blocs qui constitue le journal est assortie d'une contrainte qui permet d'augmenter le niveau de difficulté à la générer. Il s'agit de la preuve de travail. Un des champs de l'en-tête du bloc indique le niveau de difficulté de la clé de hash à fournir. Ce niveau de difficulté indique le nombre de bits à zéro qui doivent figurer au début de la clé de hash. Un autre champ contient une valeur appelée «nonce». Il s'agit d'un nombre entier que l'on incorpore dans l'en-tête du bloc, pris en compte dans le calcul de la clé de hash, et que l'on incrémente au fur et à mesure jusqu'à trouver la première clé qui commence par le nombre de bits à zéro défini par la difficulté. Il n'y a qu'un seul moyen pour trouver la première clé de hashage qui correspond à ce critère : il faut les essayer toutes l'une après l'autre jusqu'à trouver la bonne. Avec une difficulté de 16, pour 16 bits à zéro, il faut en moyenne plus de 60000 tentatives avant de trouver la première clé de hash qui correspond au critère de difficulté. Pour obtenir cette preuve de travail, il faut donc du temps et une certaine puissance de calculs. Ainsi, plus le journal est volumineux et plus il faudrait de temps et de puissance pour envisager raisonnablement d'attaquer le dispositif par force brute.

Le logiciel intègre également d'autres méthodes de sécurisation supplémentaires qui rendent toute modification du contenu du journal extrêmement difficile. Dans la pratique, le niveau de difficulté est tel qu'on peut considérer que le journal est bien une archive inaltérable, sécurisée et qui doit être être conservée intégralement.

On peut vérifier la validité d'un journal complet de plusieurs manières.

Si vous disposez du logiciel, il suffit d'utiliser la fonction du menu “Outils” / “Piste d'audit” / “Vérifier” / “Vérifier l'intégrité”. Vous obtenez le résultat d'un examen approfondi du journal. Cet examen comprend aussi la vérification minutieuse de sa cohérence avec l'ensemble des données de la base de données. Il s'agit du test d'intégrité le plus poussé que l'on puisse faire car il ne tient pas seulement compte du journal, mais de sa relation avec les données contenue dans la base de données.

On peut aussi vérifier la validité d'un journal exporté en TSV. Pour cela, il existe un outil de contrôle externe au logiciel BeDesk. Il permet de fourni la preuve que le journal est correctement formaté, que les signatures qu'il contient sont certifiées et que la chaîne de blocs est correcte. En bref que son contenu est cohérent et manifestement non altéré.

Cet outil est disponible en téléchargement gratuit à cette adresse https://downloads.bedesk-express.com/audit-checker/B0S0/AuditChecker.jar.

A titre indicatif pour l'administration, le code source de ce vérificateur est également disponible.

Cet outil s'utilise en ligne de commande et est compatible quelque soit le système d'exploitation. Il nécessite toutefois que le JDK Java 9 soit pré-installé.

Imaginons que vous vouliez contrôler la validité du journal TSV dont le fichier s'appelle “journal-complet-2018.tsv”, il suffit de taper la commande suivante dans le terminal:

java -jar AuditChecker.jar -src journal-complet-2018.tsv

L'outil fournit toute une série d'informations relatives au certificat publique utilisé pour les cachets d'horodatage et indique la liste des erreurs s'il y en a.

Idéalement, elle se termine par une ligne de ce style “Fin du controle : X ligne(s) [PoW: N iterations (avg: M itr/blk)] : 0 erreur(s).” où X est le nombre de ligne du journal et où le nombre d'erreurs est zéro.

Comme indiqué plus haut, pour les besoins de l'administration le code source du kit de développement de l'outil de vérification peut être fourni. Il contient notamment un classe Java LogItem permettant d'accéder facilement au contenu de tous les champs de chaque enregistrement.

Il n'est toutefois pas nécessaire de disposer de ce kit pour extraire les données du journal. Le format TSV s'importe très facilement dans un tableur ou dans une base de données. Il devient alors relativement simple de filtrer et d'utiliser les champs à volonté.

Le format des enregistrements est toutefois affublé d'un numéro de révision de manière à assurer la compatibilité avec des éventuelles améliorations ultérieures.

Consultez cette page pour la révision actuelle : Schéma B0S0 : Blockchain révision 0, Source révision 0.