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.
Regardless of the variant, legislation allows for a 100% cloud variant or local installation of POS systems.
Basics of POS security in France
Legislators established the four principles of POS security in Article 88 of the 2016 Finance Act. More about the ISCA rules can be found in a previous post by fiskaltrust.
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 “state-of-the-art”. 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.
Signing and chaining of receipts
This is the two central points of cash register security and consists of three steps.
Signing
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.
Tamper protection
After this “electronic signing”, 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.
Protection against deletion
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.
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.
Local POS systems
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.
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.
SaaS POS systems
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.
Pure online mode
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.
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 “post-entry mode”.
Offline mode
Or a so-called “offline mode” is provided. In this case, the receipts are created normally by the POS system, but marked with a “mode degradée” (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.
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.
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.
Summary
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’t want to expend any further effort, you can simply prevent an offline mode.
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.