Closed BEFK-AT closed 8 years ago
steininger
commented
8 years ago Wenn es "nur" um den QR-Code geht dann habe ich hierzu einen Lösungsvorschlag: Unter https://www.nuget.org/packages/fiskaltrust.interface.utilities/ steht ein Utility kostenfrei bereit welches auf jedem Drucker der Codepage 437, 850 oder 852 unterstützt einen QR-Code Druck möglich macht.
Unter https://github.com/fiskaltrust/interface ist eine Demo zur Nutzung und anbei ein Screen-Shot eines Text-QR-Codes.
BEFK-AT
commented
8 years ago Vielen Dank, aber darum gehts nicht. Es geht darum, dass die Signaturen nicht, wie explizit gefordert, im Klartext in der Weltgeschichte herumschwirren sollten, wenn jemand den Link verwenden möchte, wie es ihm ja an sich freisteht.
steininger
commented
8 years ago Hierzu sollte aber auch noch RKSV §11 Abs. 2 berücksichtigt werden
(2) Sofern ein maschinenlesbarer Code nicht als QR-Code am Beleg aufgedruckt werden kann, sind die Daten nach Abs. 1 entweder ....
Dieser beinhaltet dass wenn ein QR-Code gedruckt werden kann, darf kein Link gedruckt werden. Ich unterstelle jetzt mal mit der obigen Methode kann auf jedem Text-Drucker und jedem Text-Bildschirm ein QR-Code ausgegeben werden, somit ist die Verwendung eines Links nicht immer automatisch erlaubt.
BEFK-AT
commented
8 years ago Völlig unbestritten. Unser Beitrag bezieht sich ja auch nicht auf die zu erfüllenden Bedingungen für den Druck des Links, sondern rein auf die geforderte technische Umsetzung des Links.
SEHellFire
commented
8 years ago Der QR-Code-Druck über die Codepages ist durchaus interessant aber funktioniert auf sämtlichen BON-Druckern nicht weil:
Ihr QR-Code ist über 60 Zeichen Breit und in Kassen verbaute BON-/Rechnungsdrucker drucken nur so 32 - 44 Zeichen pro Zeile.
steininger
commented
8 years ago Daher gibts ja auch einen optionalen Wert beim Aufruf mit dem man die Breite angeben kann die man gerne hätte :-)
public static byte[] QR_TextBytes(string data, int width = 64, bool invers=false)
Wenn man nur 44 Zeichen breite will dann bitte mit width=44 aufrufen.
BEFK-AT
commented
8 years ago Nachdem die Frage schwierig zu beantworten scheint: Können wir Ihren Analyseprozess erleichtern oder vereinfachen? Würde in die Tiefe gehende Dokumentation helfen?
asitplus-pteufl
commented
8 years ago @Parmenidoxes können Sie mich direkt kontaktieren? peter.teufl@a-sit.at (telefonieren wir am besten) danke.
Für viele unserer Kunden ist der Signaturabhängige Link ein recht wichtiges Feature, weil so die Anforderungen der RKSV erfüllt werden können, ohne die bestehende Drucker-Infrastruktur austauschen zu müssen. Wie wir alle wissen, haben Kassensysteme eine überdurchschnittliche Lebensdauer, und ältere Druckersystemen bieten meist weder OCR noch QR.
Unsere Umsetzung erfüllt alle sicherheitstechnischen Vorgaben des Architekten der RKSV, Prof. Posch, aber die Form der Ausweisung unterscheidet sich von den später durch die A-SIT-Plus formulierten "Festlegungen des BMF zu Detailfragen". Leider fußt die dort vorgestellte Abwicklung auf der Annahme einer eigenen sicheren Serverlandschaft, der als Alternative nur das außer Acht lassen des Datenschutzes gegenübersteht. Unserer Meinung nach ist das aber nicht notwendig. Hier eine Kurzdarstellung des Signaturabhängigen Links bei EFSTA:
Beispiel-Link: EFSTA.NET#288750229924811839402446
Wir bitten auf diesem Weg um Prüfung unserer Lösung und um Freigabe.
Begründung: In den "Festlegungen" ist der Aufruf des Signaturabhängigen Links als Dateizugriff auf eine Server-Plattform dargestellt. Der Zugriffsschlüssel ist dabei eine 11stellige BASE64-Kodierung der ersten 8 Bytes des Hash-Wertes der Signatur. Dafür muss die Speicherung des Signatur am Server UNVERSCHLÜSSELT erfolgen.
Das wäre für eine einzelne Signatur nicht so problematisch, weil diese klarschriftlich nur den Belegumsatz je Steuerklasse des Einzelbeleges enthält. Wenn am Server aber alle Belege aller Kassen eines Unternehmens gespeichert sind, könnte aus den Einzelsätzen jederzeit der gesamte Unternehmensumsatz des ermittelt werden. Nachdem dies ein Unternehmensgeheimnis ist, können Signaturdaten nicht in dieser Form an Dritte zum Abruf per Link übergeben werden.
Nach den "Festlegungen" wäre die Speicherung der Signaturdaten folglich nur auf eigenen Servern des Unternehmens möglich. Die Verantwortung bzgl. Datenschutz liegt dabei vollständig beim Unternehmen, dazu auch die Verantwortung der permanenten Verfügbarkeit des Signaturlink-Dienstes (diesbezüglich hat das BMF noch keine Vorgaben gemacht).
Dazu kommt, dass formal die Ausweisung als 11stellige BASE64-Code nicht ideal ist, weil es bei Erfassung des gedruckten Codes wiederum zu Verwechslungen (Buchstabe "I", Kleinbuchstabe "l", Ziffer "1" usw.) kommen kann.
Anstatt zum Austausch des Druckerfuhrparks würden die Unternehmen also zum Aufbau einer sicheren IT Infrastruktur, sowie der Entwicklung entsprechenden IT KnowHows gezwungen, was zwar für große Unternehmen wenig, für KMUs aber ein erhebliches Problem darstellt. Folgt man der Umsetzung der „Festlegungen“, ist das aber unumgänglich.
Wir schlagen daher als Alternative einen überprüfbaren, datengeschützten, und an vertrauenswürdige Dritte auslagerbaren Ansatz vor, der den Kern der Vorgabe voll erfüllt, aber nicht auf verpflichtend unternehmensinterne Serverstrukturen beschränkt ist.
Mit der Bitte um Begutachtung und Freigabe. Schönen Gruß, Jakob Marberger, Product Manager, EFSTA IT Services GmbH