AT524620A1

AT524620A1 - Verfahren zum Migrieren einer IT-Anwendung

Info

Publication number: AT524620A1
Application number: ATA51063/2020A
Authority: AT
Inventors: Piller Dr Ernst
Original assignee: Fachhochschule St Poelten Gmbh
Priority date: 2020-12-07
Filing date: 2020-12-07
Publication date: 2022-06-15
Also published as: US20240007276A1; WO2022120400A1; EP4256455A1

Abstract

Damit ein Verfahren zum Migrieren einer IT-Anwendung, die auf einem zentralen System läuft, auf eine IT-Anwendung (1) mit Blockchain-Technologie bzw. Distributed Ledger Technology (DLT), die auf mehreren Nodes (3) läuft, inklusive aller oder bestimmter Daten, sodass die gesamte Verarbeitung der IT- Anwendung (1) in den Nodes (3) inklusive aller relevanter Daten erfolgt, wobei für eine sichere Nachvollziehbarkeit der Verarbeitung die dafür erforderlichen Daten durch eine Verkettung (11) verkettet werden und die Nodes (3) die erforderlichen Daten über ein Netzwerk (13) austauschen, möglichst einfach und weitgehend automatisch durchgeführt werden kann, ist erfindungsgemäß vorgesehen, dass ein Programm in das Betriebssystem (4) und/oder vor und/oder in und/oder nach Datenbanksystem(e) (5) und/oder IT-Anwendungen (1) als Middleware (6) integriert wird, sodass die IT- Anwendung (1) nicht oder nur geringfügig geändert werden muss, und dass entsprechend den Berechtigungen und damit dem relevanten Leseschutz die Datenblöcke (7) oder Teile davon vor dem Schreiben kryptografisch verschlüsselt (9) und nach dem Lesen die Datenblöcke (7) oder Teile davon kryptografisch entschlüsselt (10) werden.

Description

erforderlichen Daten über ein Netzwerk austauschen.

Distributed Ledger Technology (DLT) ist der Überbegriff für Blockchain-Technologien und verschiedene Arten von DAGTechnologien (direct acyclic graphs). Im Folgenden wird immer der Begriff Blockchain verwendet, es sind aber auch eine Verkettung und die Ideen von DAGs möglich. Das heißt, im patentgemäßen Verfahren wird nicht zwischen Blockchain und DLT unterschieden. Hinter Blockchains stehen heute Implementierungen wie Bitcoin, Ethereum etc., hinter sogenannten blockDAGs Implementierungen wie Nano oder RChain, hinter TDAGs Implementierungen wie IOTA oder Byteball.

Distributed-Ledger-Technologie, oder besser bekannt als Blockchain-Technologie, ist ein technologischer Trend, der das Potential hat, etliche Bereiche der Gesellschaft und große Branchen wie Finanzen, Logistik, Gesundheitswesen, Anwendungen des Öffentlichen Bereichs etc. zu verändern. Bei Blockchains erfolgt die gesamte Verarbeitung und Speicherung der Daten vor Ort in sogenannten "Nodes" und die Daten sind dauerhaft und unveränderlich mit einem kryptografischen Verfahren verkettet. Nodes können PC-Arbeitsplätze, Smartphones, aber auch

Steuerungen, Maschinen, Fahrzeuge etc. sein.

Durch die Abkehr von zentralen Systemen, die langfristige kryptografische Verkettung aller Daten und lokale Verarbeitung und Speicherung der Daten steigen durch Blockchains oftmals das Vertrauen in die Anwendung, die Verfügbarkeit der IT, Nichtabstreitbarkeit und Nachvollziehbarkeit der gesamten Verarbeitung.

sehr gut passende Blockchain-Lösungen.

Die aktuelle IT mit einer IT-Verarbeitung in Zentralen hat andere Ziele, eine andere Orientierung als die heutigen Blockchain-Technologien. Es bestehen erhebliche Unterschiede zwischen dem Einsatz von Blockchain-Technologien in ihrem Umfeld und der zentralistischen, klassischen IT-Welt. Die Folge davon ist, dass die vielen Millionen von IT-Anwendungen, die heute schon erfolgreich im Einsatz sind und in zentralen IT-Systemen verarbeitet werden, für Blockchain-Technologien nicht direkt in Frage kommen. Die Ursachen liegen dabei vor allem in den Schnittstellen, den Autorisierungs- und Berechtigungssystemen, im logischen Zugriffsschutz (insbesondere Lese-Schutz), in der IT-Sicherheit, der LÖöschmöglichkeit (wichtig für

Datenschutzgrundverordnung) und der Speicherfreigabe.

Es ist Aufgabe der vorliegenden Erfindung, ein Verfahren zu schaffen, mit dem in einfacher Weise Millionen von schon existierenden IT-Anwendungen aus unserer zentralistischen, klassischen und im alltäglichen Geschäft verwurzelten IT so erweitert werden können, dass die Definition und die Ziele von Blockchains erfüllt sind. Dabei sollen die vorhandenen

Zentralsysteme weiterverwendet werden können.

Diese Aufgabe wird durch ein Verfahren der eingangs genannten Art erfindungsgemäß dadurch gelöst, dass ein Programm in das Betriebssystem und/oder vor und/oder in und/oder nach Datenbanksystem(e) und/oder IT-Anwendungen als Middleware integriert wird, sodass die IT-Anwendung nicht oder nur geringfügig geändert werden muss, und dass entsprechend den Berechtigungen und damit dem relevanten Leseschutz die Datenblöcke oder Teile davon vor dem Schreiben auf einen nichtflüchtigen Datenspeicher und/oder Datenbanksystem und/oder Dateisystem kryptografisch verschlüsselt und nach dem Lesen von

einem nichtflüchtigen Datenspeicher und/oder Datenbanksystem

kryptografisch entschlüsselt werden.

Das Gesamtsystem enthält neben den schon vorhandenen üblicherweise zentralen Autorisierungs- und Berechtigungssystemen vor allem Arbeitsplätze (PCs, Laptops, Smartphones etc.) in Form von Full-Nodes, die alle Daten erhalten, Light-Nodes, die nur die gewünschten Daten erhalten, und Service-Nodes, die zusätzlich auch Verwaltungs-/ Sicherheitsaufgaben übernehmen. Full- und Light-Nodes werden auch Benutzer-Nodes genannt. Zusätzlich kann das vorhandene Zentralsystem vollständig für alle Benutzer erhalten bleiben,

die wie bisher weiterarbeiten möchten.

Nachfolgend wird von einer Erweiterung der IT-Anwendung in eine Blockchain gesprochen. Diese Erweiterung kann oftmals völlig automatisch durch die Middleware passieren, wenn bei der ITAnwendung keine Änderungen erforderlich sind. In der Praxis wird aber meist eine zumindest geringfügige Portierung erforderlich

sein, wo einige Anpassungen erfolgen.

Ein wesentlicher Punkt ist die Datensicherheit. Bei einem zentralen System kann man unbefugte Zugriffe leicht verhindern, indem der Zentralrechner die angeforderten Informationen an nicht berechtigte Benutzer nicht ausgibt. Bei einer Blockchain sind aber die gesamten Daten bei Jedem Full-Node vorhanden, und man kann nicht verhindern, dass ein versierter Benützer auf diese Daten unter Umgehung der Datenbanksoftware zugreift, da er ja auf seinem Rechner in der Regel Administratorrechte hat. Da sich somit die Benutzer vor Ort auf den Nodes üblicherweise die Hoheit über alle Daten verschaffen können, d.h. sie alle Administrationsrechte besitzen, können die existierenden zentralen Berechtigungssysteme und logischen Zugriffskontrollsysteme (vor allem Lese- und Schreibschutz) nicht mehr den erforderlichen Schutz der Daten garantieren, da sie relativ Leicht umgangen werden können. Dieser Schutz wird daher bei der Erweiterung in eine Blockchain mit Hilfe einer geeigneten Ver- und Entschlüsselung der Daten gelöst, d.h. mit

Hilfe eines auf Kryptografie basierenden logischen

ist eine geeignete Entschlüsselung erforderlich).

Vorzugsweise werden personenbezogene Daten zusätzlich mit einem der jeweiligen Person zugeordneten Schlüssel ein weiteres Mal verschlüsselt, sodass trotz der Verkettung der Datenblöcke die personenbezogenen Daten bei Bedarf durch Löschung des der jeweiligen Person zugeordneten Schlüssels in allen Nodes unlesbar gemacht werden können. Als "Löschen" im Sinne der Datenschutzgrundverordnung, das z.B. bei personenbezogenen Daten möglich sein muss, wird nämlich nicht nur das vollständige Vernichten dieser Informationen verstanden, sondern auch das Unlesbar-Machen, z.B. durch Vernichten des zum Entschlüsseln notwendigen Schlüssels. Da es in der Natur einer Blockchain liegt, dass Daten nicht gelöscht werden können, ohne die Verkettung zu zerstören, wird durch diese Merkmale eine Lösung geschaffen, um die Datenschutzgrundverordnung dennoch zu

erfüllen.

Zur Erhöhung der Sicherheit kann man vorsehen, dass für die kryptografische Verschlüsselung und Entschlüsselung und Berechnung elektronischer Signaturen nur Quantencomputer-sichere kryptographische Algorithmen verwendet werden, z.B. gitterbasierte und/oder Code-basierte und/oder Hash-basierte und/oder multivariante Kryptografie und/oder Kryptografie auf

Basis supersingularer isogener Kurven.

Nach einer Ausführungsform der Erfindung werden bei der Verschlüsselung von Daten für Datenbanksysteme die Zeilen und/oder Spalten oder Elemente von Zeilen und/oder Spalten von Tabellen kryptografisch entsprechend den Berechtigungen von Benutzern und/oder Rollen und/oder anderen Subjekten verschlüsselt. Dabei ist es möglich, die Daten mit unterschiedlichen Schlüsseln zu verschlüsseln, sodass sie mit jedem Schlüssel entschlüsselt werden können, wie das z.B. von E-Mails bekannt ist. So kann man z.B. bei einer Kundenkartei

eines großen Vereins die Daten von Vereinsmitgliedern in

Weil ein Node bei sich immer alle Daten schreiben bzw. verändern kann, muss der Schreibschutz neben der Verschlüsselung der Daten noch einen weiteren Schutz enthalten, indem die anderen Nodes einen Schreibvorgang eines Nodes in ihren Datenbestand inklusive Blockchain erst übernehmen, nachdem sie die Schreibberechtigung dieses Nodes positiv überprüft haben. Wenn ein unberechtigter Node Daten verändert, wirkt sich das somit nur bei ihm lokal aus, aber nicht auf die gesamte Blockchain, die dezentral auf viele Nodes verteilt ist.

Weil die Zeilen bzw. Spalten von Tabellen von Datenbanken bestimmte Datentypen und Längen repräsentieren (z.B. ganze Zahlen, Gleitkommazahlen, Datum, Zeichenketten), ist es zweckmäßig, wenn die Ver- und Entschlüsselung der Daten das Format (in diesem Fall den Datentyp der Zeile und/oder Spalte oder Teile davon) und die Länge erhalten. Ebenso sollten Vorgaben, wie z.B. eine gültige Datumsangabe, auch nach der Verschlüsselung erfüllt werden, damit sie im Datenbanksystem akzeptiert und richtig verarbeitet werden, ohne dass das Datenbanksystem diesbezüglich geändert werden muss. Dazu wird in einer Ausführungsform der Erfindung formaterhaltende Kryptografie (Format-preserving-encryption, FPE) verwendet, sodass der Datentyp und die Länge erhalten bleiben und Datumsangaben auch nach der Verschlüsselung gültige Angaben bleiben. Dazu können z.B. FFl oder FF3 nach NIST Special Publication 800-38G (Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption) verwendet

werden.

Vorzugsweise wird die kryptografische Verkettung der Datenblöcke in ein mehrstufiges Verkettungssystem getrennt, wobei auf der untersten Ebene keine Verkettung erfolgt und diese nur für den Node gilt, wobei weiters auf der mittleren Ebene eine temporäre Verkettung erfolgt und diese nur für den Node gilt und wobei schließlich auf der oberen Ebene mit Gültigkeit im Gesamtsystem eine endgültige Verkettung erfolgt, wobei die unterste und/oder mittlere Ebene auch entfallen können, sodass dadurch während der Verarbeitung im Node und vor der Verteilung auf alle anderen Nodes noch Speicher freigegeben und Speicherplatz eingespart

werden kann.

Um weiter Speicherplatz zu sparen, kann man vorsehen, dass sich in der Blockchain nicht die eigentlichen Datenblöcke befinden, sondern dass sich in der Blockchain Header mit Zeigern auf die eigentlichen Datenblöcke befinden und dass sich bei Bedarf für gelöschte sowie geänderte Datenblöcke die Daten oder eine

komprimierte Form der Veränderungen in der Blockchain befinden.

Es ist zweckmäßig, wenn die Zugriffsberechtigungen zu Daten in Datenbanksystemen und Dateien in einer eigenen zweiten Blockchain gespeichert werden und diese zweite Blockchain allen Nodes zugänglich ist, wobei diese zweite Blockchain aus den Daten der im Zentralsystem vorhandenen Autorisierungs- und

Berechtigungssysteme und/oder anderen Daten von einer

7127

können.

Diese zweite Blockchain kann vorzugsweise vier verschiedene

Blocktypen in Form von Node-Blöcken enthalten, nämlich

®° Node-Blöcke mit wichtigen Informationen über alle Nodes

®° Berechtigungs-Blöcke mit allen relevanten Berechtigungen

° Zertifikats-Blöcke mit allen erforderlichen Zertifikaten und

®° Parameter-Blöcke mit allen erforderlichen Werten für das Schlüsselmanagement und die Datenver-/Entschlüsselung.

Die zentralen Autorisierungs- und Berechtigungssysteme zur Anlieferung der aktuellen Berechtigungen können dabei erhalten bleiben und auch die Zentralsysteme zur Verarbeitung von Anwendungen für Benutzer können erhalten bleiben und dabei als eigene Nodes agieren.

Zur Erhöhung der Sicherheit ist nach einer Ausgestaltung der Erfindung vorgesehen, dass die Middleware ein ITSicherheitssystem enthält und dass dieses IT-Sicherheitssystem die Sicherheitsanforderungen und kryptografischen Verfahren jedes einzelnen Nodes vorgibt, in allen Nodes überprüft und

Abweichungen an die anderen Nodes meldet.

Die Erzeugung und Speicherung der kryptografischen Schlüssel

und/oder die Ver- und Entschlüsselung der Datenblöcke in den

Um die notwendige Asynchronität und Transaktionsgeschwindigkeit zur kryptografischen Verkettung in der Blockchain und gegebenenfalls der zweiten Blockchain zu erreichen, kann

vorzugsweise ein Direkter-azyklischer-Graph eingesetzt werden.

Schließlich ist nach einer Ausgestaltung der Erfindung vorgesehen, dass die lesenden Datenbank-Befehle und/oder DateiBefehle in Bezug auf die Leseberechtigung des relevanten Benutzers bzw. der relevanten Rolle bzw. eines sonstigen relevanten Subjekts überprüft werden und dass die schreibenden Datenbank-Befehle und/oder Datei-Befehle von den eigenen Anwendungen und von den anderen Nodes zuerst vom Verfahren in Bezug auf die relevante Schreibberechtigung mit Hilfe der Verwaltungsverarbeitungseinheit überprüft werden und bei Befehlen von anderen Nodes auch der Gültigkeits-Startzeitpunkt der Schreibberechtigung mit dem Zeitstempel verglichen wird sowie die Plausibilität des Zeitstempels überprüft wird und nur im positiven Fall die lesenden und schreibenden Befehle an das zuständige Datenbanksystem bzw. Dateisystem weitergegeben

werden.

Gemäß der vorliegenden Erfindung sind also vorgesehen:

1.) ein neues auf Kryptografie basierendes logisches Zugriffskontrollsystem in Form einer kryptografischen Ver- und

Entschlüsselung der Daten, insbesondere für den Leseschutz;

2.) ein spezielles Schreibschutzsystem in Verbindung mit Verschlüsselung und elektronischer Signatur, um das Schreiben von Daten zu schützen - ersetzt in Verbindung mit Punkt 1. und

5. den Konsensmechanismus von Blockchains;

(Trusted Platform Module) verlagern;

4.) ein kryptografisches Datenverkettungssystem, das in Dateiund Datenbanksystemen einerseits die notwendige Verkettung aller Blöcke durchführt, aber dabei mit dem Speicher sehr sparsam umgeht;

5.) eine zweite Blockchain, Verwaltungs-Blockchain genannt, die unter anderem wegen der zentralen Berechtigungssysteme und ständigen Verfügbarkeit des Systems zweckmäßig ist;

6.) ein Steuerungssystem für Datenbanksysteme, das die schreibenden Datenbank-Befehle und in Transaktionen zusammengefassten Befehle in allen Nodes in der gleichen Reihenfolge an das Datenbanksystem liefert und dabei alle anderen lokalen Datenbank-Befehle mitberücksichtigt. Dabei werden alle Daten von eigenen Anwendungen, die Spalten oder Elemente von Spalten einer Tabelle repräsentieren und die der Datenbank in verschlüsselter Form geliefert werden dürfen, kryptografisch verschlüsselt. Alle Datenbank-Befehle werden nach

dieser partiellen Verschlüsselung auch verkettet.

Die Erweiterung der IT-Anwendungen in eine Blockchain erfolgt dadurch, dass das erfindungsgemäße Verfahren als neue Middleware in die verwendeten Betriebssysteme, Datenbanksysteme und bei Bedarf auch IT-Anwendungen geeignet integriert wird. Diese Middleware hat z.B. eine Schnittstelle nach oben zum Betriebssystem, wo sie alle Kommandos für die Dateiverwaltung erhält, nach unten zum eigentlichen Dateisystem und nach außen zum Kommunikationssystem, wo sie alle Daten von den anderen

Nodes, inklusive Service-Nodes, erhält und allen anderen Nodes

ihre Daten zusendet, damit alle Nodes den gleichen Datenbestand

in Form von Dateien, Datenbanken etc. haben.

Nachfolgend werden diese fünf Teile des erfindungsgemäßen Verfahrens kurz beschrieben:

ad 1.) Zugriffskontrollsystem: In heute üblichen IT-Systemen, wo die Verarbeitung der Anwendungen und Daten in Zentralen erfolgt, befinden sich ausgefeilte Berechtigungssysteme in den Datenbanksystemen, Betriebssystemen und speziellen Berechtigungssystemen wie z.B. Active Directory. Diese Berechtigungssysteme garantieren den gewünschten Zugriffsschutz auf die Daten, sodass nur berechtigte Nutzer des Systems einen

Zugriff bekommen.

Wenn heutige IT-Anwendungen von einer Zentrale auf viele einfache Arbeitsplätze (Nodes) verteilt werden, entfällt im Node der logische Zugriffsschutz auf die Daten durch das Betriebssystem, Datenbanksystem und die Anwendungen. Vor Ort bei den Nodes hat der Inhaber/Benutzer des Nodes die komplette Hoheit über sein System. Er kann daher jederzeit auch die Zugriffsberechtigungen auf die in seinem System gespeicherten Daten einstellen, wie er möchte. Auf dieser Basis lassen sich keine Berechtigungen wie Leserecht und Schreibrecht auf Daten

umsetzen und garantieren.

Der erforderliche Zugriffsschutz wird daher im erfindungsgemäßen Verfahren durch ein kryptografisches Zugriffsschutzsystem ersetzt. Es muss die Daten, im Speziellen die einzelnen Datenblöcke, vor unberechtigtem Lesen ausschließlich durch Datenverschlüsselung schützen. Die kryptografischen Schlüssel werden in sogenannten Service-Nodes, das sind spezielle Nodes für Sicherheitsaufgaben und Verwaltungsaufgaben, oder EAL4+ zertifizierten Hardware-Token nach ISO/IEC-7816, das sind z.B. hochsichere Chipkarten wie sie heute in Bankkarten, Reisepässen oder SIM-Karten verwendet werden, erzeugt und von dort an alle Nodes Quantencomputer-sicher verschlüsselt verteilt.

ad 2.) Schreibschutzsystem: Jeder Schreibvorgang, d.h. jede Änderung oder Ergänzung von Daten, erfolgt durch eine Datenverschlüsselung. Durch diese Verschlüsselung ist auch der Leseschutz (siehe oben) möglich. Da aber Jeder Node bei sich vorhandene Daten - und das sind bei einem Full-Node alle Daten Jederzeit überschreiben kann, benötigt der Schreibschutz noch einen zusätzlichen Schutzmechanismus. Jeder Schreibvorgang bei einem Node muss Jedem anderen Node geeignet über das Kommunikationssystem mitgeteilt werden, damit der Datenbestand in allen Nodes gleich ist. Dies erfolgt dadurch, dass Jeder Node nach der Verschlüsselung eines neuen bzw. geänderten Datenblocks diese mit einem MAC (Message Authentication Code) oder einer digitalen/elektronischen Signatur versehen an alle anderen Nodes sendet. Der Datenblock kann eine variable Länge aufweisen. Als MAC wird dazu ein sogenannter HMAC (HASH-MAC) verwendet, als Hash-Verfahren ein SHA2 (SHA2-256, SHA2-384, SHA2-512) oder SHA-3 und als elektronisches Signaturverfahren ein ECDSA oder ein Verfahren aus der Post-Quanten Kryptografie verwendet. Die Nodes, die diesen Datenblock empfangen, überprüfen den MAC bzw. die elektronische Signatur und damit die Integrität und Authentizität der Daten. Wenn diese Nodes feststellen, dass der sendende Node laut Verwaltungs-Blockchain die erforderliche Schreibberechtigung hatte, übernehmen sie den empfangenen Datenblock in ihre Daten an der richtigen Stelle, ansonsten wird der empfangene Datenblock gelöscht. Das heißt, empfangene Datenblöcke werden nicht nur verschlüsselt abgespeichert, damit der erforderliche Leseschutz vorliegt, sondern es wird auch überprüft, ob für diese Datenblöcke in der VerwaltungsBlockchain beim sendenden Node die erforderliche

Schreibberechtigung vorlag.

ad 3.) Sicherheitsmanagement: Ein sensibler Bereich von Blockchains ist die IT-Sicherheit. Es ist viel einfacher, eine Zentrale IT-sicherheitstechnisch ausreichend abzusichern und zu auditieren als hunderte oder tausende von einfachen Arbeitsplätzen/Benutzer-Nodes. Wenn die IT-Anwendungen und die Datenspeicherung aber auf diesen Nodes vollständig abgewickelt werden, was bei Blockchains der Fall ist, hängt die

Gesamtsicherheit von jedem einzelnen Node ab. Das heißt, es sind

ein geeignetes organisatorisches und technisches ITSicherheitsmanagement und IT-Sicherheitstechnologien erforderlich, die auch auf dezentralen Arbeitsplätzen/BenutzerNodes eine ausreichende IT-Sicherheit garantieren können. Zum Beispiel wird hier festgelegt, ob die Daten symmetrisch oder asymmetrisch verschlüsselt werden, welches kryptografische Verfahren und Schlüsselmanagement verwendet wird, wo vor Ort im Node das Schlüsselmanagement und die Datenver-/-entschlüsselung stattfindet und welche allgemeinen IT-Sicherheitsanforderungen an den Node gestellt werden. Sensible Teile des Verfahrens müssen in hardware-geschützte Umgebungen wie EAL4+ zertifizierten Hardware-Token nach ISO/IEC-7816, SGX (Software Guard Extensions), TPM (Trusted Platform Module nach TCGSpezifikation) verlagert werden. Das Verfahren enthält ein Sicherheitskontrollsystem, das auf allen Nodes zum Einsatz kommt und soweit als möglich automatisch die Sicherheit vor Ort kontrolliert und Abweichungen an die anderen Nodes meldet.

ad 4.) Kryptografisches Datenverkettungssystem: Eine weitere wichtige Komponente stellt die kryptografische Verkettung der Daten in den Datei- und Datenbanksystemen dar. Dabei liegt die Herausforderung nicht in der kryptografisch sicheren Verkettung selbst, sondern im sparsamen Umgang mit dem Speicher. Die Verkettung verhindert das Freigeben von Speicher, das bei Dateisystemen und Datenbanken aber ständig erfolgt. Daher müssen spezielle Mechanismen verwendet werden, die auch bei existierenden Datei- und Datenbanksystemen ohne Änderung zu einem sparsamen Umgang mit Datenspeicher trotz Verkettung führen.

ad 5.) Verwaltungs-Blockchain: Eine wichtige Aufgabe in heutigen IT-Anwendungen in Zentralen haben die sogenannten Autorisierungs- und Berechtigungssysteme wie RMS (Microsoft Rights Management System, Active Directory etc.) und die in den einzelnen Datenbank- und Betriebssystemen integrierten Autorisierungs- und Berechtigungssysteme. In den meisten zentralen IT-Systemen sind mehrere Berechtigungssysteme parallel aktiv und die einzelnen IT-Anwendungen holen sich von diesen bei Bedarf die Berechtigungen und Rollen der einzelnen Benutzer.

Im Gegensatz dazu erzeugt das erfindungsgemäße Verfahren in einem oder mehreren Service-Nodes die Verwaltungs-Blockchain, indem es sich von den Berechtigungssystemen die Berechtigungen holt und sofort alle Veränderungen in die Verwaltungs-Blockchain schreibt. Nach einer endgültigen Verkettung eines Blocks kann jeder Node aufgrund der Verwaltungs-Blockchain überprüfen, ob ein Berechtigter diesen Block erzeugt und verkettet hat.

Das heißt, im erfindungsgemäßen Verfahren existiert neben der Haupt-Blockchain, wo die bisherigen Daten des Zentralsystems verkettet und verschlüsselt werden, eine weitere Blockchain, die sogenannte Verwaltungs-Blockchain, welche notwendig ist, um klassische Berechtigungs-Systeme zusammenzuführen und dann allen Nodes zur Verfügung zu stellen. Diese Verwaltungs-Blockchain enthält zumindest vier verschiedene Blocktypen: Blöcke mit allen relevanten Daten über die einzelnen Nodes (Node-Blöcke), Blöcke mit allen Berechtigungen aus den Berechtigungssystemen (Berechtigungs-Blöcke), Zertifikats-Blöcke mit allen erforderlichen Zertifikaten der Nodes (ein Zertifikat enthält den Öffentlichen Schlüssel einer asymmetrischen Kryptografie und die dazugehörige Bezeichnung des "Eigentümers"), ParameterBlöcke mit allen Parametern für das Schlüsselmanagement und zur Ver- / Entschlüsselung der Daten.

Diese Verwaltungs-Blockchain beliefert die einzelnen Nodes mit den erforderlichen Berechtigungen und sonstigen Daten (wie Zertifikaten, Parametern etc.), erhöht die Verfügbarkeit und dient als Protokollierung des sensiblen Bereichs der Berechtigungen.

ad 6.) Steuerungssystem für Datenbanksysteme, nachfolgend SDS

genannt:

Heutige Datenbanksysteme sind oftmals nicht in der Lage, dass alle Nodes auf Wunsch gleichzeitig auch Datenbankserver sind, was aber bei einem Blockchain-System erforderlich ist, und auch der erforderliche Zugriffsschutz in den völlig offenen Nodes ist nicht umsetzbar. Bei den Datenbank-Befehlen gibt es schreibende,

lesende und verwaltende Befehle. Des Weiteren werden Folgen von

Befehlen in Transaktionen zusammengefasst, die nur als Ganzes verarbeitet werden dürfen, ansonsten muss durch ein "Rollback" die gesamte Transaktionsfolge zurückgerollt werden.

SDS befindet sich auf der Schnittstelle zwischen den ITAnwendungen und dem Datenbanksystem, d.h. vor dem "native interface" der Datenbank. SDS hat aber auch eine zweite Schnittstelle zu dem Modul, das die Datenblöcke von außen über das Netzwerk, d.h. von den anderen Nodes, bekommt und dorthin auch verschickt. Das heißt, SDS erhält Datenbank-Befehle von den eigenen Anwendungen im Node und Befehle von allen anderen Nodes.

Ein Parser prüft nun alle hereinkommenden Transaktionen und Befehle.

Die schreibenden Datenbank-Befehle werden vom SDS an das zuständige eigene Datenbanksystem übergeben. Alle DatenbankBefehle, die von den eigenen Anwendungen kommen, werden auch an alle anderen Nodes verteilt, wo sie via SDS im Node ebenfalls den Datenbanksystemen in den Nodes zugeführt werden. Die Befehle, die an alle anderen Nodes via Netzwerk weitergegeben werden, erhalten zusätzliche Daten wie Node-Kennzeichen, Zähler, Zeitstempel und eine elektronische Signatur. Die Reihenfolge der Befehle und Transaktionen muss bei allen Nodes im Gesamtsystem gleich sein. Dasselbe gilt für etwaige Fehlermeldungen und deren Behandlung, einem erforderlichen "Rollback". Des Weiteren muss dabei stets auf die Synchronisation geachtet werden. Im SDS

erfolgt auch die Verkettung aller Befehle.

Wenn neue schreibende Datenbank-Befehle von eigenen Anwendungen im Node dem Datenbanksystem übergeben werden, wird zuerst vom SDS die relevante Schreibberechtigung für diese Befehle mit Hilfe des Berechtigungssystems überprüft. Im positiven Fall werden von Tabellen einzelne Elemente von Zeilen und/oder Spalten oder ganze Zeilen und/oder Spalten, die der Datenbank in verschlüsselter Form geliefert werden dürfen, kryptografisch mit Hilfe von Format-preserving-encryption verschlüsselt. Dann

werden die Datenbank-Befehle an die Verkettungseinheit und an

das zuständige Datenbanksystem weitergegeben (es kann im Node

mehrere Datenbanksysteme geben).

Wenn neue schreibende Befehle von einem anderen Node dem SDS übergeben werden, wird zuerst vom SDS die relevante Schreibberechtigung für diese Befehle mit Hilfe des Berechtigungssystems überprüft. Dabei wird auch der GültigkeitsStartzeitpunkt der Schreibberechtigung mit dem Zeitstempel verglichen sowie die Plausibilität des Zeitstempels überprüft. Im positiven Fall werden die Befehle an die Verkettungseinheit und an das zuständige Datenbanksystem weitergegeben.

Die lesenden Datenbank-Befehle sind für das SDS wichtig für die Überprüfung der Leseberechtigung. Diese Überprüfung der Leseberechtigung erfolgt auf Basis der Berechtigungen im Berechtigungssystem durch die Überprüfung der einzelnen Befehle in Bezug auf die Leseberechtigung.

Die gesamte Datenbank kann noch zusätzlich mit einem einzigen

Schlüssel ver- und entschlüsselt werden.

In den beiliegenden Figuren ist das Prinzip der vorliegenden Erfindung schematisch dargestellt. Es zeigt:

Fig. 1 das Prinzip einer Blockchain; Fig. 2 einen Node; Fig. 3 mehrere Nodes in einem Netzwerk; und Fig. 4 zeigt die einzelnen Module der erfindungsgemäßen Middleware, wie sie mit einem

Service-Node zusammenarbeitet.

Das Prinzip einer Blockchain ist aus Fig. 1 ersichtlich. In einer Blockchain 2 sind Blöcke 7 vorhanden, die über Verkettungen 11 miteinander verbunden sind. Jede Verkettung 11 besteht im Prinzip darin, dass jeder Block 7 zumindest einen Hashwert des vorherigen Blocks 7 gespeichert hat, sodass sofort erkennbar ist, wenn einer der vorherigen Blöcke manipuliert wurde. Somit ist die Historie der Änderungen jederzeit vollständig nachvollziehbar.

In Fig. 2 ist ein Node 3 dargestellt, in dem eine Blockchain 2 gespeichert werden kann. Der Node 3 beinhaltet ein Betriebssystem 4, in welchem die erfindungsgemäße Middleware 6 integriert ist. Die Middleware 6 kommuniziert über ein Netzwerk 13 mit anderen Nodes, wie an Hand von Fig. 3 genauer erläutert werden wird. Die Middleware 6 kommuniziert weiters mit einem Datenbanksystem 5. Auf dem Node 3 läuft weiters eine Anwendung 1, die einen weiteren Teil 6' der Middleware enthält. Die Anwendung 1 kommuniziert in üblicher Weise mit dem Betriebssystem 4 (in diesem Fall mit der Middleware 6 des Betriebssystems 4), gibt also Lese- und Schreibbefehle. Das Betriebssystem 4 kommuniziert seinerseits in üblicher Weise mit einem Dateisystem 8 eines Permanentspeichers, der auch im Node 3 vorhanden ist. In diesem Dateisystem ist die Blockchain 2 (siehe Fig. 1) gespeichert.

Fig. 3 zeigt die Verbindung von mehreren (im Beispiel vier) Nodes 3, die im Vergleich zu Fig. 2 vereinfacht dargestellt sind. Über ein Netzwerk 13 kann jeder Node 3 mit jedem anderen Node 3 kommunizieren, wobei diese Kommunikation jeweils von der Middleware 6 organisiert wird. Auf diese Weise wird sichergestellt, dass alle Nodes 3 dieselbe Blockchain 2 (siehe Fig. 1) gespeichert haben.

In Fig. 4 ist die Middleware 6 dargestellt, wie sie mit einem Service-Node 16 kommuniziert. (Tatsächlich sind in der Praxis natürlich mehrere Nodes mit Middleware 6 und mehrere ServiceNodes 16 im Netzwerk 13 vorhanden.) Der Service-Node 16 weist eine Verwaltungsverarbeitungseinheit 18 auf. Die Verwaltungsverarbeitungseinheit 18 des Service-Nodes 16 verwaltet eine zweite Blockchain 14 (Verwaltungs-Blockchain), das Schlüsselmanagement, etc. Zu diesem Zweck steht sie mit mehreren (im Beispiel drei) zentralen Autorisierungs- und Berechtigungssystemen 15 in Verbindung und aktualisiert die zweite Blockchain 14 auf Grund von Änderungen in diesen zentralen Autorisierungs- und Berechtigungssystemen 15. Die Middleware 6 weist auch eine Verwaltungsverarbeitungseinheit 18' auf, wobei diese mit der Verwaltungsverarbeitungseinheit 18 der

Service-Nodes 16 über das Netzwerk 13 in Verbindung stehen, um

eine lokale Kopie 14' der zweiten Blockchain mit der Blockchain 14 im Service-Node 16 abzugleichen und so die Jeweils aktuellen Berechtigungen zu erhalten. Auf diese Weise bleibt ein zeitweiser Ausfall von den zentralen Autorisierungs- und Berechtigungssystemen 15 ohne Wirkung. Die Verwaltungsverarbeitungseinheiten 18, 18' stehen jeweils mit einem Hardware-Token 19, 19' in Verbindung.

Wie oben erklärt ist ein zentraler Punkt der vorliegenden Erfindung die Verschlüsselung 9 der Daten und die Entschlüsselung 10 der Daten. Diese erfolgt mithilfe von kryptografischen Schlüsseln 12, die von der Verwaltungsverarbeitungseinheit 18' zur Verfügung gestellt werden. Die verschlüsselten Daten werden von dem Datenbanksystem 5 bzw. dem Dateisystem 8 zur Entschlüsselung 10 und von dort im Klartext zu der Anwendung 1 übertragen. Umgekehrt werden Daten, die im Klartext von der Anwendung 1 kommen, zur Verschlüsselung 9 übertragen und dann in verschlüsselter Form dem Datenbanksystem 5 bzw. dem Dateisystem 8 zugeführt sowie über das Netzwerk 13 an die anderen Nodes übertragen. Zuvor wird allerdings im System 17 zur Überprüfung der Schreibberechtigung überprüft, ob dieser Node zum Schreiben dieser Daten berechtigt ist. Wenn dies der Fall ist, dann erfolgt zusätzlich zur Übertragung der Daten in das Datenbanksystem 5 bzw. das Dateisystem 8 sowie in das Netzwerk 13 auch ein Eintrag in die Blockchain 2.

Bezugszeichenliste:

1 Anwendungen im eigenen Node

2 Blockchain

3 Node

4 Betriebssystem im eigenen Node

5 Datenbanksysteme im eigenen Node

6 Middleware

7 Block der Blockchain

8 Dateisystem und Permanentspeicher im eigenen Node 9 Verschlüsselung der Daten

10 Entschlüsselung der Daten 11 Verkettung der Blöcke

12 Kryptografische Schlüssel

13 Netzwerk

14, 14' Zweite Blockchain

15 Zentrale Autorisierungs- und Berechtigungssysteme 16 Service-Nodes

17 System zur Überprüfung der Schreibberechtigung 18, 18' Verwaltungsverarbeitungseinheit in den Nodes 19, 19' Hardware-Token

Claims

Telefon: £ +43 (1) 512 24 81 / Fax: 3+43 (1) 513 76 81 / E-Mail: £&7 repatent@aon.at

Konto (PSK): 1480 708 BLZ 60000 BIC: OPSKATWW IBAN: AT19 6000 0000 0148 07081 480 708

Fachhochschule St. Pölten GmbH 3100 St. Pölten (AT) Patentansprüche 1. Verfahren zum Migrieren einer IT-Anwendung, die auf einem

zentralen System läuft, auf eine IT-Anwendung (1) mit Blockchain-Technologie bzw. Distributed Ledger Technology (DLT), die auf mehreren Nodes (3) läuft, inklusive aller oder bestimmter, vom jeweiligen Node (3) gewünschten Daten, sodass die gesamte Verarbeitung der IT-Anwendung (1) in den Nodes (3) inklusive aller relevanter Daten erfolgt, wobei für eine sichere Nachvollziehbarkeit der Verarbeitung die dafür erforderlichen Daten durch eine Verkettung (11) verkettet werden und die Nodes (3) die erforderlichen Daten über ein Netzwerk (13) austauschen, dadurch gekennzeichnet, dass ein Programm in das Betriebssystem (4) und/oder vor und/oder in und/oder nach Datenbanksystem(e) (5) und/oder IT-Anwendungen (1) als Middleware (6) integriert wird, sodass die IT-Anwendung (1) nicht oder nur geringfügig geändert werden muss, und dass entsprechend den Berechtigungen und damit dem relevanten Leseschutz die Datenblöcke (7) oder Teile davon vor dem Schreiben auf einen nichtflüchtigen Datenspeicher und/oder Datenbanksystem (5) und/oder Dateisystem (8) kryptografisch verschlüsselt (9) und nach dem Lesen von einem nichtflüchtigen Datenspeicher und/oder Datenbanksystem (5) und/oder Dateisystem (8) die Datenblöcke (7) oder Teile

davon kryptografisch entschlüsselt (10) werden.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass personenbezogene Daten zusätzlich mit einem der jeweiligen Person zugeordneten Schlüssel ein weiteres Mal verschlüsselt werden, sodass trotz der Verkettung (11) der Datenblöcke (7) die personenbezogenen Daten bei Bedarf

durch Löschung des der jeweiligen Person zugeordneten

können.

Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass für die kryptografische Verschlüsselung (9) und Entschlüsselung (10) und Berechnung elektronischer Signaturen nur Quantencomputer-sichere kryptographische Algorithmen verwendet werden, z.B. gitterbasierte und/oder Code-basierte und/oder Hash-basierte und/oder multivariante Kryptografie und/oder Kryptografie auf Basis

supersingularer isogener Kurven.

Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass bei der Verschlüsselung (9) von Daten für Datenbanksysteme (5) die Zeilen und/oder Spalten oder Elemente von Zeilen und/oder Spalten von Tabellen, die der Datenbank in verschlüsselter Form geliefert werden dürfen, kryptografisch entsprechend den Berechtigungen von Benutzern und/oder Rollen und/oder anderen Subjekten

verschlüsselt werden.

Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass bei der Verschlüsselung (9) und Entschlüsselung (10) dieser Zeilen und/oder Spalten oder Elemente von Zeilen und/oder Spalten von Tabellen formaterhaltende Kryptografie (Formatpreserving-encryption), z.B. FF1l oder FF3 nach NIST Special Publication 800-38G verwendet wird, sodass der Datentyp und die Länge erhalten bleiben und Datumsangaben auch nach der Verschlüsselung gültige Angaben bleiben.

Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass sich in Jedem Node (3) aus dem aktuellen kryptografischen Leseschlüssel (12) durch eine asymmetrische Quantencomputer-sichere Entschlüsselung alle älteren Generationen des Leseschlüssels (12) berechnen lassen und sich in Service-Nodes (16) oder Hardware-Token (19) als Teil der Service-Nodes (16) durch eine asymmetrische Quantencomputer-sichere Verschlüsselung neue Schlüsselgenerationen (12) berechnen lassen.

Verfahren nach einem der Ansprüche 1 bis 3 und 7, dadurch gekennzeichnet, dass sich in der Blockchain (2) nicht die eigentlichen Datenblöcke befinden und dass sich in der Blockchain (2) Header mit Zeigern auf die eigentlichen Datenblöcke befinden und dass sich bei Bedarf für gelöschte sowie geänderte Datenblöcke die Daten oder eine komprimierte Form der Veränderungen in der Blockchain (2)

befinden.

Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass die Zugriffsberechtigungen zu Daten in Datenbanksystemen und Dateien in einer eigenen zweiten Blockchain (14) gespeichert werden und diese zweite Blockchain (14) allen Nodes (3) zugänglich ist, dass diese zweite Blockchain (14) aus den Daten der im Zentralsystem vorhandenen Autorisierungs- und Berechtigungssysteme (15) und/oder anderen Daten von einer Verwaltungseinheit (18, 18') erstellt wird und dass diese Verwaltungseinheit (18, 18") in der Middleware (6) mit den Anwendungen (1) und/oder dem Betriebssystem (4) und/oder den Datenbanksystemen (5) und/oder den zentralen Autorisierungs- und

Berechtigungssystemen (15) verbunden ist.

11.

12.

13.

14.

Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass

diese zweite Blockchain (14) zumindest vier verschiedene

Blocktypen in Form von Node-Blöcken enthält, nämlich

®° Node-Blöcke mit wichtigen Informationen über alle Nodes (3)

®° Berechtigungs-Blöcke mit allen relevanten Berechtigungen

° Zertifikats-Blöcke mit allen erforderlichen Zertifikaten und

®° Parameter-Blöcke mit allen erforderlichen Werten für das

Schlüsselmanagement und die Datenver-/Entschlüsselung.

Verfahren nach Anspruch 9 oder 10, dadurch gekennzeichnet, dass die zentralen Autorisierungs- und Berechtigungssysteme (15) zur Anlieferung der aktuellen Berechtigungen erhalten bleiben und dass auch die Zentralsysteme zur Verarbeitung von Anwendungen (1) für Benutzer erhalten bleiben und dabei als eigene Nodes (3) agieren.

Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass die Middleware (6) ein ITSicherheitssystem enthält und dass dieses ITSicherheitssystem die Sicherheitsanforderungen und kryptografischen Verfahren Jedes einzelnen Nodes (3) vorgibt, in allen Nodes (3) überprüft und Abweichungen an die anderen Nodes (3) meldet.

Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass die Erzeugung und Speicherung der kryptografischen Schlüssel (12) und/oder die Verschlüsselung (9) und Entschlüsselung (10) der Datenblöcke in den Nodes (3, 16) Je nach Sicherheitsniveau entweder ungeschützt im Node (3, 16) oder in einer Hardware-geschützten Sandbox im Node (3, 16) oder in externen Hardware-Token (19, 19') ablaufen und dass das IT-Sicherheitssystem das Sicherheitsniveau im Node (3, 16) stets kontrolliert und Abweichungen an alle anderen Nodes (3, 16) weitergibt.

Verfahren nach einem der Ansprüche 1 bis 13, dadurch

gekennzeichnet, dass für die notwendige Asynchronität und

Transaktionsgeschwindigkeit zur kryptografischen Verkettung (11) in der Blockchain (2) und gegebenenfalls der zweiten Blockchain (14) ein Direkter-Azyklischer-Graph eingesetzt

wird.

Verfahren nach einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, dass die lesenden Datenbank-Befehle und/oder Datei-Befehle in Bezug auf die Leseberechtigung des relevanten Benutzers bzw. der relevanten Rolle bzw. eines sonstigen relevanten Subjekts überprüft werden und dass die schreibenden Datenbank-Befehle und/oder DateiBefehle von den eigenen Anwendungen (1) und von den anderen Nodes (3) zuerst vom Verfahren in Bezug auf die relevante Schreibberechtigung mit Hilfe der Verwaltungsverarbeitungseinheit (18') überprüft werden und bei Befehlen von anderen Nodes (3) auch der GültigkeitsStartzeitpunkt der Schreibberechtigung mit dem Zeitstempel verglichen wird sowie die Plausibilität des Zeitstempels überprüft wird und im positiven Fall die lesenden und schreibenden Befehle an das zuständige Datenbanksystem (5) bzw. Dateisystem (8) weitergegeben werden.