Probleme beim Einloggen

Registrierkassen - Kassensicherungsverordnung Deutschland

Ab 2020 kommt der Manipulationsschutz in Deutschland. In dieser Gruppe wollen wir in Zusammenarbeit mit Experten Infos liefern.

Erich P. Freitag Kassensicherungsverordnung (3b) - Update und FinishTransaction
UpdateTransaction:
Ändern sich Daten in einem mit StartTransaction begonnenen Aufzeichnungsvorgang bevor dieser abgeschlossen wird, so ist UpdateTransaction spätestens 45 Sekunden (MAX_UPDATE_DELAY) nach einer Änderung aufzurufen. Dabei sind alle seit StartTransaction oder seit dem letzten UpdateTransaction erfolgten Änderungen an die TSE zu übergeben. Bei UpdateTransaction gibt es keine optionale Daten.
short updateTransaction (
in CONDITIONAL unsigned long clientID,
in REQUIRED unsigned long transactionNumber,
in REQUIRED octet processData [],
in OPTIONAL string <100> processType )
Die bei StartTransaction retournierte transactionNumber dient der TSE gemeinsam mit der clientID zur Referenzierung des begonnenen Vorgangs. Die TSE fügt die processData zu den zuvor erhaltenen Daten dazu und speichert diese. Der Wert von MAX_UPDATE_DELAY soll im Aufzeichnungssystem konfigurierbar sein.
short updateTransaction (
out CONDITIONAL DateTime logTime,
out CONDITIONAL unsigned long signatureCounter,
out CONDITIONAL octet signatureValue[] )
Die Rückgabewerte sind deshalb CONDITIONAL, weil die TSE die Daten entweder nur speichern oder gleich signieren und speichern kann. Wie bei StartTransaction werden der signatureCounter und der signatureValue nicht weiter behandelt. Ebenso hat logTime zu diesem Zeitpunkt keine weitere Verwendung.
Als Beispiel einer Änderung wird in der TR-03153 ein Kassiervorgang angeführt, aber auch dass parallel mehrere Vorgänge - zB bei einem Restaurantbesuch - aufgezeichnet werden können. Der beispielhafte Kassiervorgang dürfte für UpdateTransaction allerdings nur dann relevant werden, wenn der Geschäftsfall nicht innerhalb von MAX_UPDATE_DELAY auch tatsächlich abgeschlossen wird (wenn also beispielsweise eine Barzahlung angenommen wird, der Kunde kein Bargeld mit sich hat und auf EC-Zahlung gewechselt wird und dieser Vorgang bis zum Abschluss länger als 45 Sekunden dauert).
FinishTransaction:
Mit FinishTransaction wird ein Geschäftsfall abgeschlossen.
short finishTransaction (
in CONDITIONAL unsigned long clientID,
in REQUIRED unsigned long transactionNumber,
in REQUIRED octet processData [],
in OPTIONAL string <100> processType,
in OPTIONAL/RESERVED octet additionalData[] )
Neben den Signaturdaten wird nochmals eine logTime retourniert; diese stellt jetzt den Zeitpunkt der Vorgangsbeendigung dar.
short finisheTransaction (
out CONDITIONAL DateTime logTime,
out REQUIRED unsigned long signatureCounter,
out OPTIONAL octet signatureValue[] )
Gemäß KassenSichV sind - neben den üblichen Belegdaten wie Unternehmen oder Menge und Art der gelieferten Gegenstände - jetzt auch
• die Transaktionsnummer (erstmalig aus StartTransaction retourniert sowie bei UpdateTransaction und FinishTransaction übergeben)
• der Zeitpunkt des Vorgangsbeginns (logTime aus StartTransaction)
• der Zeitpunkt der Vorgangsbeendigung (logTime aus FinishTransaction)
• die Seriennummer des Aufzeichnungssystems ODER die Seriennummer des Sicherheitsmoduls (aus StartTransaction)
am Beleg anzubringen.
Unter anderem sind darüber hinaus Trainingsbuchungen explizit als solche zu kennzeichnen (siehe „Transaktionen“).
Nachdem die Zahlungsart beim Start einer Transaktion im Allgemeinen noch nicht feststeht (Ausnahme sind zB Trainingsbuchungen), gibt es derzeit zwei Möglichkeiten, damit umzugehen: es wird eine Zahlungsart bereits bei Beginn von StartTransaction angenommen und gegebenenfalls spätestens bei FinishTransaction auf die tatsächliche Zahlungsart angepasst. Oder die Zahlungsart wird zunächst offen gelassen und erst eingetragen, wenn die Zahlungsart endgültig feststeht.
Erich P. Freitag Kassensicherungsverordnung (3a) - StartTransaction
Im Zusammenhang mit Transaktionen sind folgende Funktionen zu verwenden:
• StartTransaction, um eine gesicherte Aufzeichnung zu starten
• UpdateTransaction, um zwischenzeitliche Änderungen zu speichern
• FinishTransaction, um eine abgeschlossene Transaktion abzusichern und zu speichern
Bei StartTransaction übergibt das Aufzeichnungssystem die Seriennummer des Aufzeichnungssystems, die Art des Vorgangs und die bereits erzeugten Daten des Vorgangs an die TSE.
short startTransaction (
in CONDITIONAL unsigned long clientID,
in REQUIRED octet processData [],
in OPTIONAL string <100> processType,
in OPTIONAL/RESERVED octet additionalData[] )
Gemäß KassenSichV kommt zu "Art des Vorgangs" (processType) und "Daten des Vorgangs" (processData) auch eine Zahlungsart hinzu, spätestens bei FinishTransaction. Für die Zahlungsart gibt es lediglich folgende Vorgaben:
• Bar oder unbar
• „keine“, wenn es sich um keinen Geschäftsfall, sondern zB um eine Trainingsbuchung gehandelt hat
Die „Taxonomie Kassendaten“ der DFKA listet weitere Zahlungsarten auf. „Unbar“ ist demnach eine Zusammenfassung für alle unbaren Zahlungsarten, wenn eine Kasse dies nicht weiter unterscheiden kann. Ansonsten stehen „EC-Karte“, „Kreditkarte“ oder „Guthabenkarte“ sowie „elektronische Zahlungsdienstleister“ zur Auswahl.
Die Zahlungsart ist Teil der processData. Warum processType als OPTIONAL definiert ist, lässt sich dahingehend erklären, dass die „Art des Vorgangs“ bei StartTransaction unter Umständen noch nicht bekannt ist.
Für die "Daten des Vorgangs" gibt es keine Vorgaben bezüglich Inhalt und Formatierung. Sie werden aber wohl auch Informationen wie die Menge und die Art der gelieferten Gegenstände oder den Umfang und die Art der sonstigen Leistung und dergleichen enthalten. Bei anderen Vorgängen sind die „Daten des Vorgangs“ sinngemäß zu befüllen.
Das Aufzeichnungssystem erhält auf den Aufruf von StartTransaction unter anderem eine Transaktionsnummer von der TSE. Mit dieser Transaktionsnummer sind alle weiteren zusammengehörigen UpdateTransactions sowie die FinishTransaction aufzurufen, um einen zusammengehörigen Vorgang kennzuzeichnen.
short startTransaction (
out REQUIRED unsigned long transactionNumber,
out REQUIRED DateTime logTime,
out REQUIRED octet serialNumber[],
out REQUIRED unsigned long signatureCounter,
out OPTIONAL octet signatureValue[] )
Die Kassensoftware muss daher auch die Transaktionsnummer zu einem Geschäftsfall, der über die TSE abgesichert wird, zusätzlich mitverwalten. Zusätzlich muss sie sich den Rückgabewert der logTime als Zeitpunkt des Vorgangsbeginns und optional die retournierte Seriennummer merken. Der signatureCounter wird von der Kasse nicht weiter behandelt, der signatureValue wird bei StartTransaction noch nicht benötigt.
Erich P. Freitag Zusammenwirken zwischen Kasse und TSE
Das technologie-offene Konzept der technischen Sicherheitseinrichtung (TSE) lässt verschiedene Architekturen zu, die auch Einfluss auf die Anbindung von Kassen sowie auf betriebliche Abläufe haben werden.
Wie in der TR-03153 beschrieben besteht die gesamte TSE aus (zunächst) drei Komponenten:
- einem Sicherheitsmodul
- einer einhetlichen digitalen Schnittstelle
- einem Speichermedium
Das Sicherheitsmodul (security module) besteht selbst aus zwei logisch getrennten sowie physikalisch vereinten oder getrennten Teilen:
- einer security module application (SMA)
- einem CSP (cryptographic service provider)
Die SMA bereitet die Daten, die sie von einer Kasse erhält, auf und übergibt diese dem CSP zur Erstellung der Signatur. Die SMA führt auch die Transaktionsnummer pro Kasse, der CSP führt einen davon unabhängigen Signaturzähler. Die SMA stellt ferner die Export-Schnittstelle gegenüber dem CSP zur Verfügung und verfügt über einen Konfigurations-Kanal zum CSP.
Im CSP werden die Zertifikate vorgehalten. Die SMA und der CSP wählen anhand ihrer Konfiguration und in Abhängigkeit der "Kassen-ID" (Seriennummer) das zugeordnete Zertifikat für die Signaturerstellung aus.
Die security module application und der cryptographic service provider werden getrennt evaluiert und am Ende mit der Schnittstelle und mit dem Speichermedium als gesamte TSE zertifiziert.
Die security module application kann auf der selben Plattform (Hardware) laufen, wo auch der cryptographic service provider seine Dienste verrichtet. Oder die security module application ist vom CSP getrennt und kommuniziert mit diesem über einen trusted channel.
Bezüglich der Architektur einer TSE ergeben sich damit folgende Möglichkeiten:
- die Entscheidung, ob die security module application auf der CSP-Plattform untergebracht ist (platform architecture) oder von dieser getrennt ist (client-server architecture)
- welcher Art der CSP ist (Smart-Card, HSM, ...)
- wie der CSP ausgeführt ist (einzelner provider, cluster-Architektur, ...)
- wie das Speichermedium ausgeführt ist - dieses kann lokal oder remote untergebracht/angebunden sein
Bezüglich der Kassenanbindung sind folgende Fragen zu klären:
- welche Einbindungsschnittstelle die TSE für Kassen zur Verfügung stellt (die in der TR-03153 beschriebene Einbindungsschnittstelle ist nur eine Empfehlung und sagt auch nichts über deren physikalischer Ausführung aus)
- ob die Export-Funktion der TSE-Daten direkt über die TSE erfolgt oder über eine Export-Funktion an der Einbindungsschnittstelle
- welche Parameter der TSE die Kassen-Software berücksichtigen muss (Speicherkapazität versus Anzahl und Häufigkeit von Transaktionen, Häufigkeit der Aktualisierung der Uhrzeit, ...)
Ein weiterer Kommentar
Letzter Kommentar:
Das ist nicht die einzige offene Frage, Herr Fichtinger. Das Schutzprofil ist auch noch nicht fertig und in sich nicht konsistent, aber das ist ein anderes Thema.
Sie haben recht - aus Sicht einer Kasse sowie aus Sicht der TR-03153 (wenngleich auch diese von dem PP-SMAERS zunächst unabhängig ist) gibt es keine Funktion, die einen Test des ERS vorsieht. Die vollständige Darstellung aller Zusammenhänge würde hier den Rahmen sprengen, daher nur grob:
O.TEE verlangt "TSF to test on electronic record-keeping system connected to the TOE", "to test on CTSS interface component connected to the TOE", "to test on CSP connected to the TOE", "test on availability of the CTSS interface component and CSP connected to the TOE", "to test the ERS as external entity".
Laut Schutzprofil wird O.TEE direkt durch "FPT_TEE.1" erfüllt. "FMT_MOF.1 restrict the definition and modification of the FPT_TEE.1 behavior to the Administrator", unterstützt also bezüglich des Zugriffs bestimmter Funktionen nur durch die Admin-Rolle.
In "FPT_TEE.1" steht "The TSF shall run a suite of tests during start-up, periodically during normal operation, user initiated shutdown and before exiting the secure state according to FPT_FLS.1 to check the fulfillment of
(1) ESR Identity [assignment: list of properties of the ESR] and
(2) CSP Identity [assignment: list of properties of the CSP]".
Vom Ersteller der Security Targets sind die beiden assignments für die zu überprüfenden Eigenschaften des ESR und des CSP zu bestimmen und auszufüllen. Ebenso ist wohl festzulegen, was beim Start, im Betrieb und beim Shut-Down geprüft werden kann.
In der Application Note zu "FPT_TEE.1" gibt es einige Ansätze dazu. Beispielsweise "The TOE may use signature counter and time stamps received from CSP to test the CSP". Das ist noch verständlich, weil der CSP ja passiv gegenüber dem SMA-ERS ist und über Zertifikate und Funktion geprüft werden kann, ebenso wie "The signature counter shall increase strong monotonically ..." - das lässt sich auch prüfen.
Bezüglich ESR "E. g. the test of the ESR may include the interface used by the ESR for communication with the CTSS as reported by the CTSS interface component". Die TSE ist ja passiv gegenüber einem ESR und es gibt auch keine Funktionen dafür. Aber "der Test des ESR kann die Schnittstelle beinhalten..." - ein Beispiel, wie das assignment anzuwenden ist.
Viel mehr als die CTSS interface component wird man hier beim Start nicht prüfen können; das ist aber auch ohnedies Umfang der Prüfung:
(FMT_MOF.1 - (3) determine the behaviour of the function FPT_TEE.1 by definition of the identity and features to be tested of ERS to Administrator,
[...]
(5) determine the behaviour of and modify the behaviour of the function FPT_TEE.1 in case the test of CTSS interface component or CSP fails to Administrator).
Seitens der SMA-ERS macht es keinen Sinn zu prüfen, ob die konfigurierten Kassen vorhanden sind oder nicht - die TSE is ja passiv; eine Prüfung von ESR-IDs macht nur im Fall einer Funktion Sinn. Und Kassen können ja auch Offline sein, die TSE muss trotzdem aktiv bleiben.
Im Betrieb wäre zumindest eine regelmäßige Prüfung möglich, ob ausschließlich konfigurierte ESR-IDs die Security-Funktion ansprechen. Ferner wäre möglich zu prüfen, ob eine Funktion vom ERS immer im richtigen Modus (User - external) ausgeführt wird. Eine andere denkbare Idee wäre, dass ESR-IDs nach bestimmten Regeln aufgebaut sein müssen und diese geprüft werden. Und dass eben gewährleistet ist, dass die CTSS interface component da ist und funktioniert.
Fazit: der Ersteller des ST für SMA-ERS muss sich hier sinnvolle Prüfmöglichkeiten überlegen und die Funktionalität für FPT_TEE.1.1 festlegen.
Nur für XING Mitglieder sichtbar Übergangsfrist für bauartbedingt nicht aufrüstbare Registrierkassen bis 31.12.2022
Auf einigen Seiten im Netz ist eine Übergangsfrist bis 31.12.2022 für "bauartbedingt nicht aufrüstbare Registrierkassen" genannt. An welcher Stelle der Rechtsordnung ist diese Frist bestimmt? Danke!
Erich P. Freitag
Ein weiterer Kommentar
Letzter Kommentar:
Erich P. Freitag Kassensicherungsverordnung (2) - Die Transaktion
Wir haben uns in diesem Forum schon in verschiedenen Beiträgen mit dem Begriff der Transaktion auseinandergesetzt und ich hatte kundgetan, diesen nochmals separat darzustellen. Das stellt meinen derzeitigen Wissensstand dar, des aus verschiedenen Quellen stammt und mangels noch eindeutiger und einstimmiger Begriffsbestimmung keine endgültige Definition sein kann und will.
-----
Eine Transaktion im Sinne der KassenSichV stellt einen Vorgang dar, der über eine Kasse abgewickelt wird. Eine Transaktion kann mehrere Geschäftsvorfälle sowie andere Vorgänge umfassen. Die Transaktion wird durch die Angabe der „Art des Vorgangs“ bezeichnet.
Dem Referentenentwurf zum Gesetz zum Schutz vor Manipulationen an digitalen Grundaufzeichnungen lässt sich dazu näheres entnehmen:
"Satz 1 regelt für die elektronischen Aufzeichnungssysteme die fortlaufende Einzelaufzeichnung sämtlicher aufzeichnungspflichtigen Geschäftsvorfälle, wie Kasseneinnahmen und –ausgaben, sowie auch anderer Vorgänge, wie z. B. Trainingsbuchungen, Entnahmen oder Einlagen, Sofort-Storno, Nachstorno, durchlaufender Posten etc.
Die Einzelaufzeichnungspflicht bedeutet, dass aufzeichnungspflichtige Geschäftsvorfälle und andere Vorgänge laufend zu erfassen und einzeln festzuhalten sowie aufzuzeichnen sind, so dass sich die einzelnen Vorgänge in ihrer Entstehung und Abwicklung verfolgen lassen können.
Demnach müssen künftig z. B. auch Trainingsbuchungen ab Inbetriebnahme eines elektronischen Aufzeichnungssystems als Daten erfasst, protokolliert und als solche gekennzeichnet werden".
In der Gesetzvorlage zur KassenSichV Teil B wird ebenso die Transaktion präzisiert:
"In § 2 der KassenSichV werden die Anforderungen an die Protokollierung der einzelnen elektronischen Grundaufzeichnungen im Sinne des § 146a Absatz 1 Satz 1 AO beschrieben.
Danach muss für jeden aufzeichnungspflichtigen Geschäftsvorfall oder anderen Vorgang im Sinne § 146a Absatz 1 Satz 1 AO von dem eingesetzten elektronischen Aufzeichnungssystem unmittelbar, d. h. zeitgleich, eine neue Transaktion gestartet werden.
Die Transaktion dient der Zusammenführung von Daten in einem einheitlichen Prozess, wodurch die protokollierten einzelnen digitalen Grundaufzeichnungen nachfolgend nicht mehr manipuliert werden können".
"Andere Vorgänge sind solche, die unmittelbar durch Betätigung der Kasse erfolgen (z. B. Tastendruck, Scanvorgang eines Barcodes), unabhängig davon, ob sich daraus ein Geschäftsvorfall entwickelt.
D. h. durch jede Betätigung der Kasse erfolgt eine Protokollierung.
Unter anderen Vorgängen sind somit Vorgänge im Geschäftsprozess zu verstehen, die letztendlich nicht zu einem Geschäftsvorfall geführt haben oder grundsätzlich nicht dazu geeignet sind, einen Geschäftsvorfall zu bewirken,
aber einen Prozess im Unternehmen darstellen, wie z. B. nicht abgeschlossene Geschäftsvorfälle, Stornierungen, erstellte Angebote, Trainingsbuchungen oder sonstige Vorgänge".
"Daher hat jede Transaktion den Zeitpunkt des Vorgangsbeginns, eine eindeutige fortlaufende Transaktionsnummer, die Art des Vorgangs, die Daten des Vorgangs, den Zeitpunkt der Vorgangsbeendigung bzw. des Vorgangsabbruchs und einen Prüfwert zu enthalten".
Das Kassensystem ist also gefordert "jede unmittelbare Betätigung der Kasse" über die TSE aufzuzeichnen. Dabei muss nicht jeder Tastendruck einzeln aufgezeichnet werden - es können Änderungen bis zu 45 Sekunden zusammengefasst werden (MAX_UPDATE_DELAY).

>
Als Transaktionen oder Teile von Transaktionen gelten damit folgende Vorgänge:
• Jeder Tastendruck, jeder Scanvorgang (unabhängig davon, ob sich daraus ein Geschäftsfall entwickelt)
• Rechnungen, Gutschriften, Anzahlungen - Kassen-Einnahmen und Kassen-Ausgaben; alle Zahlungsarten sind möglich
• Trainingsbuchungen
• Entnahmen und Einlagen, Auszahlungen und Einzahlungen
• Sofort-Storno, Nach-Storno
• Durchlaufende Posten
• Nicht abgeschlossene Geschäftsvorfälle, Abbruch: es erfolgt keine Zahlung
• Erstellte Angebote, Bestellungen: Lieferungen und Leistungen werden noch nicht ausgeführt, es erfolgt keine Zahlung
• Erstellte Lieferscheine: keine Zahlung, in der Kasse efolgt nur die Erfassung, aber (zumindest zunächst) keine Weiterverarbeitung im Abrechnungsprozess
• Zwischenrechnungen („InfoBon“): führt nicht zu einem Zahlungsvorgang
• Sachbezüge: es erfolgt eine externe Weiterverarbeitung, jedoch keine Zahlung an der Kasse
• Weitere „sonstige Vorgänge“ (Trinkgelder, Pfand und Pfandrückzahlung, Lohnzahlungen, …)
Voraussetzung dafür ist auch, dass eine Kasse diese Vorgänge zur Verfügung stellt. Dazu gibt es gesonderte Diskussionen, beispielsweise zur Abgrenzung zwischen Kassen und Warenwirtschaftssystemen. Nach obiger Lesart wäre beispielsweise eine Bestellung dann ein aufzeichnungspflichtiger Kassenvorgang, wenn dieser in einem Kassensystem ausgelöst wird. Eine Bestellung in einem Warenwirtschaftssystem - lösgelöst von jeglicher Kassenfunktion, auch wenn eine solche zB als Barverkaufsmodul vorhanden ist - wäre somit keine Transaktion im Sinne der KassenSichV.
Für die Kennzeichnung des Transaktionstyps („Art des Vorgangs“) und für Geschäftsfälle gibt es Vorschläge in der DFKA-Taxonomie Kassendaten (1.0 Pilot, August 2018), Abschnitte 3.3 und 3.4.
Axel Kutschera
Ein weiterer Kommentar
Letzter Kommentar:
Vielen Dank, Axel - ich bin ja über deine und jegliche andere konstruktive Rückmeldungen froh und dankbar. Insbesondere, wo es noch Unklarheiten gibt, die Kassenhersteller aber langsam an die Konzeption und Umsetzung denken müssen. Immerhin zeigt es mal die wahrscheinlichen Dimensionen und die notwendige Eingriffstiefe.
Die Thematik Transaktion versus Geschäftsfall stammt aus der erwähnten DFKA-Taxonomie. Ich bin damit auch noch nicht ganz glücklich, weil meiner Meinung nach Transaktionen und Geschäftsfälle dort ein wenig vermischt werden. Eine Bestellung zu erfassen ist ja auch ein Geschäfts(vor)fall, diese kommt aber unter diesem Titel nicht mehr vor. Ich habe daher angeregt, eine Matrix zu erstellen - Geschäftsfall, Transaktion, Zahlung ja/nein, ...

Moderatoren

Infos zu den Moderatoren

Über die Gruppe "Registrierkassen - Kassensicherungsverordnung Deutschland"

  • Gegründet: 26.11.2015
  • Mitglieder: 291
  • Sichtbarkeit: offen
  • Beiträge: 51
  • Kommentare: 146
  • Marktplatz-Beiträge: 0