French POS systems are not secured with hardware, unlike in other countries (such as Germany or Austria). In France, cash registers are audited by independent bodies (LNE or Infocert) for compliance with financial laws. Or the cash register manufacturer can issue an individual confirmation to each cash register user.<\/p>\n\n\n\n
Regardless of the variant, legislation allows for a 100% cloud variant or local installation of POS systems.<\/p>\n\n\n\n
Legislators established the four principles of POS security in Article 88 of the 2016 Finance Act<\/a>. More about the ISCA rules can be found in a previous post<\/a> by fiskaltrust.<\/p>\n\n\n\n However, the legislator leaves it up to the cash register manufacturer how exactly the rules are implemented. However, the technical security measures are defined with \u201cstate-of-the-art\u201d. This also means a formation of the hash value with an algorithm at least SHA-256. With fiskaltrust.Middleware you are on the safe side here, because the ISCA rules are implemented with even higher security features.<\/p>\n\n\n\n This is the two central points of cash register security and consists of three steps.<\/p>\n\n\n\n Before each storage process in the receipt journal, the receipt is signed with an electronic certificate. A PrivateKey (contained in the queue) is used and the corresponding PublicKey can be used to verify the authenticity of the receipt. Authenticity here means that the receipt can be uniquely assigned to a POS system and thus to a cashier.<\/p>\n\n\n\n After this \u201celectronic signing\u201d, the receipts are secured against modification. For this purpose, a hash value is formed over all data of the receipt. This hash value is calculated from the characters contained and the position. If even a single character changes, a completely new hash value is created. This means that any manipulation can be detected immediately.<\/p>\n\n\n\n If now the hash value of the exactly previous document is added to the data, we receive a chain with which also the deletion is recognized. Because with a check only the Hash value contained in the is compared with the calculated one of the previous voucher. If the two do not match, the sequence of the documents has been manipulated.<\/p>\n\n\n\n In the case of fiskaltrust.Middleware, there is even double chaining here: each individual document is chained to the previous one. And also each document type (for example, a ticket) is chained to the previous document of the same type.<\/p>\n\n\n\n Many of the POS systems are operated in offline mode. In this case, the POS software and the fiskaltrust.Middleware are installed locally on the hardware. In this case, the backup of the receipts also takes place in the POS system itself. The receipts are electronically signed and concatenated by the local middleware. And thus all security precautions are perfectly observed.<\/p>\n\n\n\n The only problem here can be the absence of the fiskaltrust.Middleware. Due to technical problems or faulty installation, the middleware on the POS system does not start or has failed. In this case it is recommended to block the POS system completely and restart the device. This is because there is likely to be a fundamental problem with the system in the event of such an error. This is because the fiskaltrust.Middleware is anchored in the system as a service or daemon.<\/p>\n\n\n\n POS systems that are offered as a software-as-a-service or cloud solution are more susceptible to technical problems due to their architecture. Here, the document data is not secured by a locally installed fiskaltrust.Middleware, but first a transmission of the data to the middleware in the fiskaltrust.Cloud must take place and then the response must be processed. In any case, an Internet connection is required, which is not always available.<\/p>\n\n\n\n The simplest solution is, of course, to block document creation as soon as no Internet connection is available. However, the disadvantage is obvious, no sales can be made by the cash register manufacturer.<\/p>\n\n\n\n It is not quite that bad. The French legislator very well allows a manual creation of the receipt, but this really means handwritten. These receipts can then be fiscalized at the fiskaltrust.Middleware in the \u201cpost-entry mode\u201d.<\/p>\n\n\n\n Or a so-called \u201coffline mode\u201d is provided. In this case, the receipts are created normally by the POS system, but marked with a \u201cmode degrad\u00e9e\u201d (security device failed). These receipts are stored locally and as soon as an internet connection is available again, they are transferred to the fiskaltrust.Cloud for fiscalization.<\/p>\n\n\n\n However, simply storing them locally is not compliant with the law. Because without any security, these receipts can be manipulated or deleted at will before they are transferred. Therefore, these vouchers must also be secured with chaining. The simplest variant here would be to save the JSON structure required for the fiskaltrust.Middleware as individual files in the file system. In this case, a hash value with SHA-256 is also generated and this is used to generate a simple chain, as described above.<\/p>\n\n\n\n As soon as the transfer takes place, the POS system checks that the documents and the chain are free of errors using the hash values and then transfers the data to fiskaltrust.Middleware.<\/p>\n\n\n\n With the integration of the fiskaltrust.Middleware you are on the safe side. If your POS system is set up as a SaaS solution and you don\u2019t want to expend any further effort, you can simply prevent an offline mode.<\/p>\n\n\n\n With a little effort to chain the data, you can also offer your POS operators offline mode in compliance with the law. If you are unsure exactly how to implement this, ask a member of our team of specialists.<\/p>\n\n\n\n \n We look forward to discussing with you the solutions that fiskaltrust offers to help your business. <\/p>\n \n \n We are Simplifying Complexity: <\/span>\n Contact us <\/a>\n<\/div>\n\n\n Les systèmes PDV français ne sont pas sécurisés par du matériel informatique, contrairement à d’autres pays (comme l’Allemagne ou l’Autriche). En France, les caisses sont contrôlées par des organismes indépendants (LNE ou Infocert) pour vérifier leur conformité avec les lois financières. Ou bien le fabricant de la caisse peut délivrer une attestation individuelle à chaque utilisateur de la caisse.<\/p>\n\n\n\n Quelle que soit la solution, le législateur permet une variante 100% cloud ou une installation locale des systèmes POS.<\/p>\n\n\n\n Le législateur a défini les quatre principes de la sécurité des caisses dans l’article 88 de la loi de finances de 2016<\/a>. Vous trouverez plus d’informations sur les règles ISCA dans un précédent article de fiskaltrust<\/a>.<\/p>\n\n\n\n Le législateur laisse toutefois le soin au fabricant de caisses de décider de la manière exacte dont les règles sont mises en œuvre. Les mesures de sécurité techniques sont toutefois définies avec « State-of-the-Art ». Cela signifie également une formation de la valeur de hachage avec un algorithme d’au moins SHA-256. Avec le fiskaltrust.Middleware, vous êtes du côté de la sécurité, car les règles ISCA sont mises en œuvre avec des caractéristiques de sécurité encore plus élevées.<\/p>\n\n\n\n Il s’agit des deux points centraux de la sécurité des caisses qui se composent de trois étapes.<\/p>\n\n\n\n Avant chaque processus d’enregistrement dans le journal des justificatifs, le justificatif est signé avec un certificat électronique. Une PrivateKey (qui est contenue dans la queue) est utilisée et la PublicKey correspondante peut être utilisée pour vérifier l’authenticité du justificatif. L’authenticité signifie ici que le justificatif peut être attribué sans équivoque à un système POS et donc à un opérateur de caisse.<\/p>\n\n\n\n Après cette « signature électronique », les justificatifs sont protégés contre toute modification. Pour ce faire, une valeur de hachage est créée pour toutes les données du justificatif. Cette valeur de hachage est calculée à partir des caractères contenus et de la position. Si un seul caractère est modifié, une toute nouvelle valeur de hachage est créée. Toute manipulation peut ainsi être immédiatement détectée.<\/p>\n\n\n\n Si la valeur de hachage du document précédent est ajoutée aux données suivantes, nous obtenons une chaîne dans laquelle la suppression est également détectée. En effet, lors d’un contrôle, seule la valeur de hachage contenue dans le document est comparée à celle calculée pour le document précédent. Si les deux ne correspondent pas, l’ordre des documents a été manipulé.<\/p>\n\n\n\n Dans le cas du fiskaltrust.Middleware, il y a même une double chaîne : chaque document est chaîné avec le précédent. Et chaque type de document (par exemple un ticket) est également chaîné avec le document précédent du même type.<\/p>\n\n\n\n De nombreux systèmes de point de vente fonctionnent en mode hors ligne. Le logiciel de caisse et le fiskaltrust.Middleware sont alors installés localement sur le matériel. La sauvegarde des justificatifs s’effectue également dans le système de caisse lui-même. Les justificatifs sont signés électroniquement et chaînées par le middleware en local. Toutes les mesures de sécurité sont ainsi parfaitement respectées.<\/p>\n\n\n\n Le seul problème peut être l’absence du fiskaltrust.Middleware. En raison de problèmes techniques ou d’une installation incorrecte, le middleware ne démarre pas sur le système PDV ou est en panne. Dans ce cas, il est recommandé de bloquer complètement le système PDV et de redémarrer l’appareil. En effet, dans le cas d’une telle erreur, le système devrait présenter un problème fondamental. Effectivement, le fiskaltrust.Middleware est ancré dans le système en tant que service ou daemon.<\/p>\n\n\n\n Les systèmes PDV qui sont proposés en tant que Software-as-a-Service ou solution Cloud sont déjà plus vulnérables aux problèmes techniques en raison de leur architecture. Dans ce cas, les données des documents ne sont pas sauvegardées par un fiskaltrust.Middleware installé localement, mais il faut d’abord que les données soient transmises au middleware dans le fiskaltrust.Cloud et que la réponse soit ensuite traitée. Dans tous les cas, une connexion Internet est nécessaire et elle n’est pas toujours disponible.<\/p>\n\n\n\n La solution la plus simple consiste bien entendu à bloquer la création de documents dès qu’aucune connexion Internet n’est plus disponible. L’inconvénient est toutefois évident, aucun chiffre d’affaires ne peut être réalisé par le fabricant de la caisse.<\/p>\n\n\n\n Mais ce n’est pas si grave que cela semble l’être. Le législateur français autorise bien l’établissement manuel des justificatifs, mais il faut entendre par là qu’ils sont réellement manuscrits. Ces justificatifs peuvent ensuite être fiscalisés auprès du logiciel fiskaltrust.Middleware en « mode post-saisie ».<\/p>\n\n\n\n Losqu’un mode dit « hors ligne » est mis à disposition, les documents sont créés tout à fait normalement par le système PDV, mais sont marqués de la mention « mode dégradé » (dispositif de sécurité en panne). Ces justificatifs sont stockés localement et, dès qu’une connexion Internet est à nouveau disponible, ils sont transférés dans le fiskaltrust.Cloud pour être fiscalisés.<\/p>\n\n\n\n Le simple stockage local n’est toutefois pas conforme à la loi. En effet, sans aucune sécurité, ces justificatifs peuvent être manipulés ou supprimés à volonté avant d’être transférés. C’est pourquoi ces documents doivent également être sécurisés par un chaînage. La variante la plus simple serait ici de sauvegarder la structure JSON nécessaire pour le fiskaltrust.Middleware sous forme de fichiers individuels dans le système de fichiers. Une valeur de hachage avec SHA-256 est alors également générée et utilisée, comme décrit ci-dessus, pour créer une chaîne simple.<\/p>\n\n\n\n Dès que le transfert a lieu, le système PDV vérifie l’absence d’erreurs dans les documents et la chaîne à l’aide des valeurs de hachage, puis transfère les données au fiskaltrust.Middleware.<\/p>\n\n\n\n Avec l’intégration du fiskaltrust.Middleware vous êtes du côté de la sécurité. Si votre système PDV est conçu comme une solution SaaS et que vous ne voulez pas faire d’autres efforts, vous pouvez facilement empêcher un mode hors ligne.<\/p>\n\n\n\n Avec un peu d’effort pour chaîner les données, vous pouvez également proposer aux exploitants de vos caisses un mode hors ligne conforme à la loi. Si vous n’êtes pas sûr de savoir comment mettre cela en place, demandez plus d’information à un membre de notre équipe de spécialistes.<\/p>\n\n\n \n Contactez l’un de nos experts dès aujourd’hui ! <\/p>\n \n \n We are Simplifying Complexity: <\/span>\n Contactez-nous <\/a>\n<\/div>\n\n<\/div>\n<\/div>\n\n\n Französische POS-System werden im Gegensatz zu anderen Ländern (wie zum Beispiel Deutschland oder Österreich) nicht mit Hardware gesichert. In Frankreich werden Kassen von unabhängigen Stellen (LNE oder Infocert) auf die Konformität zu den Finanzgesetzen geprüft. Oder der Kassenhersteller kann jedem Kassennutzer eine individuelle Bestätigung ausstellen.<\/p>\n\n\n\n Unabhängig von der Variante ermöglicht der Gesetzgeber eine 100%-Cloud-Variante oder eine lokale Installation von POS-Systemen.<\/p>\n\n\n\n Der Gesetzgeber hat im Artikel 88 des Finanzgesetzes von 2016<\/a> die vier Prinzipien der Kassensicherheit festgelegt. Mehr zu den ISCA-Regeln finden sind einem vorherigen Post<\/a> von fiskaltrust (LINK).<\/p>\n\n\n\n Wie genau die Regeln umgesetzt werden überlässt der Gesetzgeber jedoch dem Kassenhersteller. Es werden jedoch die technischen Sicherheitsmaßnahmen mit „State-of-the-Art“ festgelegt. Damit ist auch eine Bildung des Hash-Werte mit einem Algorithmus mindestens SHA-256 gemeint. Mit der fiskaltrust.Middleware sind sie hier auf der sicheren Seite, denn die ISCA-Regeln sind mit sogar noch höheren Sicherheitsmerkmalen umgesetzt.<\/p>\n\n\n\n Dies sind die zwei zentralen Punkte der Kassensicherheit und besteht aus drei Schritten.<\/p>\n\n\n\n Vor jedem Speichervorgang im Belegjournal wird der Beleg mit einem elektronischen Zertifikat signiert. Dabei wird ein PrivateKey (der in der Queue enthalten ist) verwendet und der entsprechende PublicKey kann verwendet werden, um die Echtheit des Beleges zu verifizieren. Die Echtheit bedeutet hier, dass der Beleg eindeutig einem POS-System und damit einem Kassenbetreiber zugeordnet werden kann.<\/p>\n\n\n\n Nach diesem „elektronischen Unterschreiben“ werden die Belege vor Veränderung gesichert. Dazu wird ein Hash-Wert über alle Daten des Beleges gebildet. Dieser Hash-Wert errechnet sich aus den enthaltenen Zeichen und der Position. Ändert sich hier auch nur ein einzelnes Zeichen wird ein ganz neuer Hash-Wert gebildet. Dadurch kann sofort jede Manipulation erkannt werden.<\/p>\n\n\n\n Wenn nun der Hash-Wert des genau vorherigen Beleges zu den Daten hinzugefügt wird, erhalten wir eine Kette bei der auch das Löschen erkannt wird. Denn bei einer Prüfung wird nur mehr der im enthaltene Hash-Wert mit dem errechneten des vorherigen Beleges verglichen. Stimmen die beiden nicht überein, wurde die Reihenfolge der Belege manipuliert.<\/p>\n\n\n\n Bei der fiskaltrust.Middleware erfolgt hier sogar eine doppelte Verkettung: Jeder einzelne Beleg ist mit dem vorherigen verkettet. Und auch jeder Belegtyp (zum Beispiel ein Ticket) ist mit dem vorhergehenden Beleg desselben Typs verkettet.<\/p>\n\n\n\n Viele der Kassensysteme werden im Offline-Modus betriebe. Dabei ist die Kassensoftware und die fiskaltrust.Middleware lokal auf der Hardware installiert. Dabei erfolgt die Sicherung der Belege auch im Kassensystem selbst. Es werden die Belege von der lokalen Middleware elektronisch signiert und verkettet. Und damit alle Sicherheitsvorkehrungen perfekt eingehalten.<\/p>\n\n\n\n Das einzige Problem kann hier das fehlen der fiskaltrust.Middleware sein. Aufgrund technischer Probleme oder fehlerhafter Installation startet die Middleware auf dem POS-System nicht oder ist ausgefallen. In diesem Fall empfiehlt es sich, das POS-System komplett zu blockieren und das Gerät neu zu starten. Denn bei so einem Fehler dürfte am System ein grundlegendes Problem vorliegen. Denn die fiskaltrust.Middleware ist als Service bzw. Daemon im System verankert.<\/p>\n\n\n\n POS-Systeme welche als Software-as-a-Service oder auch Cloud-Lösung angeboten werden, sind schon wegen der Architektur anfälliger für technische Probleme. Hier werden die Belegdaten nicht von einer lokal installierten fiskaltrust.Middleware gesichert, sondern zuerst muss eine Übertragung der Daten zur Middleware in der fiskaltrust.Cloud erfolgen und danach die Antwort verarbeitet werden. Es ist auf jeden Fall eine Internet-Verbindung notwendig, welche nicht immer verfügbar ist.<\/p>\n\n\n\n Die einfachste Lösung ist natürlich das Blockieren der Belegerstellung, sobald keine Internetverbindung vorhanden ist. Der Nachteil ist jedoch klar auf der Hand, es können keine Umsätze vom Kassenhersteller gemacht werden.<\/p>\n\n\n\n Ganz so schlimm ist es nicht. Der französische Gesetzgeber erlaubt sehr wohl eine händische Erstellung der Belegung, damit ist aber wirklich handschriftlich gemeint. Diese Belege können dann bei der fiskaltrust.Middleware im „Nacherfassungs-Modus“ fiskalisiert werden.<\/p>\n\n\n\n Oder es wird ein sogenannter „Offline-Modus“ zur Verfügung gestellt. Dabei werden die Belege ganz normal vom POS-System erstellt, jedoch mit einem „mode degradée“ (Sicherheitseinrichtung ausgefallen) markiert. Diese Belege werden lokal gespeichert und sobald wieder eine Internetverbindung vorhanden ist in die fiskaltrust.Cloud zur Fiskalisierung übertragen.<\/p>\n\n\n\n Das einfache lokale Speichern ist jedoch nicht gesetzeskonform. Denn ohne jede Sicherheit können diese Belege vor dem Übertragen nach Belieben manipuliert oder gelöscht werden. Daher müssen auch diese Belege mit einer Verkettung gesichert werden. Die einfachste Variante wäre hierbei die für die fiskaltrust.Middleware notwendige JSON-Struktur als einzelne Dateien im Dateisystem zu speichern. Dabei werden auch ein Hash-Wert mit SHA-256 erzeugt und dieser, wie oben beschrieben, zum Erzeugen einer einfachen Kette benutzt.<\/p>\n\n\n\n Sobald die Übertragung stattfindet wird vom POS-System die Fehlerfreiheit der Belege und der Kette anhand der Hash-Werte geprüft und die Daten dann an die fiskaltrust.Middleware übertragen.<\/p>\n\n\n\n Mit der Integration der fiskaltrust.Middleware sind sie auf der sicheren Seite. Ist Ihr POS-System als SaaS-Lösung aufgebaut und sie wollen keinen weiteren Aufwand betreiben, können Sie einen Offline-Modus einfach verhindern.<\/p>\n\n\n\n Mit ein wenig Aufwand zum Verketten der Daten können Sie Ihren Kassenbetreibern auch den Offline-Modus gesetzeskonform anbieten. Falls Sie unsicher sind, wie sie das genau umsetzen können, fragen Sie ein Mitglied unseres Teams aus Spezialisten.<\/p>\n\n\nSigning and chaining of receipts<\/h2>\n\n\n\n
Signing<\/h3>\n\n\n\n
Tamper protection<\/h3>\n\n\n\n
Protection against deletion<\/h3>\n\n\n\n
Local POS systems<\/h2>\n\n\n\n
SaaS POS systems<\/h2>\n\n\n\n
Pure online mode<\/h3>\n\n\n\n
Offline mode<\/h3>\n\n\n\n
Summary<\/h2>\n\n\n\n
Comment mettre en œuvre le mode hors ligne avec une caisse certifiée en France ?<\/h1>\n\n\n\n
Les bases de la sécurité des caisses en France<\/h2>\n\n\n\n
Signature et chaînage des reçus<\/h2>\n\n\n\n
Signer<\/h3>\n\n\n\n
Protection contre les manipulations<\/h3>\n\n\n\n
Protection contre l’effacement<\/h3>\n\n\n\n
Systèmes PDV installés en local<\/h2>\n\n\n\n
Systèmes PDV SaaS<\/h2>\n\n\n\n
Mode purement en ligne<\/h3>\n\n\n\n
Mode hors ligne<\/h3>\n\n\n\n
Résumé<\/h2>\n\n\n\n
Wie setze ich den Offline Modus mit einer zertifizierten Kasse in Frankreich um?<\/h1>\n\n\n\n
Grundlagen der Kassensicherheit in Frankreich<\/h2>\n\n\n\n
Signieren und Verketten von Belegen<\/h2>\n\n\n\n
Signieren<\/h3>\n\n\n\n
Manipulationsschutz<\/h3>\n\n\n\n
Schutz vor Löschen<\/h3>\n\n\n\n
Lokale POS-Systeme<\/h2>\n\n\n\n
SaaS POS-Systeme<\/h2>\n\n\n\n
Reiner Online-Modus<\/h3>\n\n\n\n
Offline-Modus<\/h3>\n\n\n\n
Resümee<\/h2>\n\n\n\n