..."Was passiert, wenn die Checksum/Hash passend zu den Daten manipuliert werden?"...
- gar nix passiert dem Softwareanbieter, denn solche Änderungen sind Vorsatz, weil mit krimineller Energie verbunden(zusätzlich die untersagte EXE Analyse)
- WaWi und FiBu müssen nur für den Normalgebrauch sicher und gegen fahrlässige Fehlnutzung durch den Softwareanbieter gesetzeskonform realisiert&geschützt sein
- ...
Bis Du Dir sicher, dass man das so einfach sehen kann? Welchen Sinn hat dann eine Checksum/Hash, wenn damit nicht *garantiert* werden kann, dass die Daten nicht verändert wurden? Die GoBD schreiben doch vor, dass Änderungen erkennbar oder nicht möglich sein *müssen*. Selbst wenn man den Algorithmus/EXE nicht analysiert (um da nichts verbotenes zu tun), könnte man sich noch immer mit einem Datenbank-Admin-Tool mit der Datenbank verbinden, den Datensatz per
SQL löschen und mit Deiner Software einen neuen (abgeänderten) Datensatz erstellen, der dann eine gültige Checksum/Hash bekommt.
Garantieren kann man als Softwareanbieter hier schon mal gar nichts. Und sofern man von einem "normalen" Programm ausgehen kann, welches dem Nutzer auf seiner eigenen Hardware zur Verfügung stellt und dessen
DB ebenfalls auf dem Nutzereigenen Server liegt, kann man generell keine Manipulation der Daten zu 100% verhindern oder ausschließen.
Was die Checksum und den Hash angeht, so hängt es ja auch davon ab wie dieser gebildet wird. Man kann an dieser Stelle dem potentiellen Angreifer nur das ganze erschweren. Sollte der Nutzer extrem gute Reverse-Engineering-Fähigkeiten haben und den Algorithmus aus deinem Programm ermitteln, so setzt auch das eine kriminelle Energie voraus. Auch wenn du die
DB mittels Kennwort schützt und den Zugriff auf diese mittels
DB-Benutzer absicherst, kann er das mit entsprechendem Aufwand knacken oder umgehen. Und in dem Fall müsstest du dich auf den
DB-Hersteller verlassen, ob den seine Sicherheitsmaßnahmen wirklich nicht zu umgehen sind.
Als Softwareanbieter dieses zu 100% zu garantieren ist schlichtweg unmöglich.
Das einzige, was du nachweisen können musst, ist dass Manipulationen nicht in deinem Programm getätigt werden können, und vielleicht noch das externe Manipulation mit handelsüblichen Mitteln feststellbar sind.
Ansonsten wird es auf der Welt irgendwo immer eine Hacker geben, der in der Lage ist die Daten so zu Verändern, dass sie wie Original aussehen.
Natürlich könnte man noch ein Historie-Log mit schreiben und dieses mit 2048-Bit verschlüsseln. Wenn das dann aber der Angreifer einfach löscht nützt das auch nichts.
Man kann also nur soweit absichern, wie es in dem eigenen Einflussbereich liegt. Darüber hinaus geht das nicht, und darüber zu diskutieren wird nie zu einem Ergebnis führen.
Die Verwendung von "unveränderbare und fälschungssichere Datenträger" kann man ja bei frei verkäuflicher Software vergessen, bzw. deren Einsatz würde wieder außerhalb des eigenen Einflussbereichs liegen.
Das Problem liegt m.M.n. in der GoBD selbst. Diese ist so definiert, dass es letztlich keine wirklich eindeutigen Vorschriften, Verfahrensanweisungen und Grenzen festgelegt sind, und diese im Einzelfall so ausgelegt werden können wie es den Behörden passt. Auch eine "Freigabe" von FA oder ZA sind unverbindlich. Darin wird zwar bestätigt, dass man mit einem dargelegten Verfahren einverstanden ist, gleichzeitig wird sich dabei auf die GoBD berufen und das dieses im Einzelfall dann von einem Gericht wieder anders ausgelegt werden kann. Somit wäre die die Bestätigung ab dem Zeitpunkt wieder ungültig.
Heißt, die wirkliche Einhaltung der GoBD kann erst bestätigt werden, wenn in einem Einzelfall diese von einem Gericht als Eingehalten bestätigt wurde.
So sind meine Erkenntnisse nach Rückfragen bei FA und StB.