The discriminator for selecting the integration architecture is the operational environment. The BSI interprets the operational environment as the environment that is under the physical control of the taxpayer. In a strict interpretation, this means that, for example, the taxpayer can perform the following tasks: Plugging and unplugging cables, exchanging physical memory, operating on/off buttons, etc.
The technical guidelines of the BSI specify that the SMA (Security Module Application) must run in this operational environment.
According to the information we have received from the bidders' questions, all servers and all cash desks are in the operational environment of the integrator. Therefore both architecture scenarios can potentially be implemented, the direct integration of the SMA into the POS software as well as the provision of SMA servers in the LAN of a branch.
The CSP components that generate the signatures are provided by fiskaly in their cloud.
This document focuses on the implementation of the cloud scenario, integration of the SMA components in the operational environment of the POS system, direct communication with the API + CSP components in the fiskaly cloud.
Software Development Kit
The Software Development Kit (SDK) is provided by us. It consists of:
- Interface for integration (see also kassensichv.io, fiskaly TSS / TSS API)
- CC-certified SMA component in binary, executable form
- optional: compensation mechanisms for failure scenarios & logging of failure scenarios
The SDK is provided by us for various platforms and operating systems, including Linux, Windows, MacOS, Android, iOS, for 32 bit or 64 bit architecture.
The source code of the SDK is also made available, e.g. for Java, .Net, Node.js. An overview of the clients and SDKs released at the time can be found at github.com/fiskaly.
On request, we are also happy to convert implementations for other platforms or languages.
TSS integration directly at the cash desk
If the TSS is integrated directly at the cash desk, the SMA is connected to the cash desk. In the diagram for TSS integration directly at the cash desk, host A corresponds to the cash desk.
The SDK with the SMA is located at host A. The data to be protected is forwarded to the SMA via the SDK. The SMA is responsible for transmitting the data to be protected via a secure channel (TC, trusted channel) to the remote CSP on host B. The CSP creates the required signature values and reports them back to the SMA. From there, the data that is now secured is transferred to host C and persisted. Host C provides the interfaces of the TSS and the memory.
|Response times||50 - 250ms, depending on the network latency|
|Process flow||Asynchronous. Start and update transactions therefore do not cause a delay in the recording system. Only for Finish transaction you have to wait for the response.|
|Service functions||Idempotent. A process can be repeated as often as required. However, the expected side effect occurs only once.|
|Simultaneously opened transactions per TSS||unlimited|
|Supported operating systems||Linux, Windows, etc. (platform independent)|
Data volume for a transaction
The data volume for a transaction depends on the payload to be signed, but it is very low across the board.
Assuming an absolute minimum of data to be secured, the data volume per transaction is << 1 kilobyte. If a larger volume of data needs to be secured, for example, to completely record POSLog transactions, the data volume also increases. The maximum amount of data that can be backed up is theoretically unlimited.
The complete protection of POSLog transactions has the advantage that other services such as archiving or accounting can process the transaction data.
Example of a payload: Minimum data of the attribute processData for a processType "cash voucher" according to the field specification of DSFinV-K
Beleg^123.45_67.89_0.00_0.00_0.00^111.11:Bar_80.23:Unbar. It can be assumed that 1 kB - 256 kB of e.g. data are transferred per transaction. Depending on whether it is a cash voucher, a purchase order (long-lasting transaction) or another transaction.
Due to our asynchronous architecture the bandwidth can be very low, e.g. via ISDN. To complete a transaction, however, you must wait for our system to respond. Here, the latency of the network is the limiting factor, since the data to be transmitted takes up a very small volume.
The response times of the fiskaly cloud are significantly influenced by the latency of the network connection. Within the fiskaly cloud, we can already show average response times of 64 ms in our test system for KassenSichV. Please note that the test system is not yet optimized for performance. Response times of less than 50 ms can be expected in our productive system.
(Screenshot of a fiskaly Cloud-TSS test run)
The latency of the network connection of the integrator to the data centers of the fiskaly cloud must be taken into account. The current location of the fiskaly cloud infrastructure is Frankfurt am Main (redundant), further locations can be provided if required, for example in Düsseldorf and Munich.
Simultaneously opened transactions
The number of simultaneously opened transactions per TSS is not limited in the fiskaly cloud. Any number of transactions can be kept open.