EP4256455A1 - Verfahren zum migrieren einer it-anwendung - Google Patents

Verfahren zum migrieren einer it-anwendung

Info

Publication number
EP4256455A1
EP4256455A1 EP21830917.7A EP21830917A EP4256455A1 EP 4256455 A1 EP4256455 A1 EP 4256455A1 EP 21830917 A EP21830917 A EP 21830917A EP 4256455 A1 EP4256455 A1 EP 4256455A1
Authority
EP
European Patent Office
Prior art keywords
data
nodes
node
encryption
encrypted
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP21830917.7A
Other languages
English (en)
French (fr)
Inventor
Ernst Piller
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Insitu Software GmbH
Original Assignee
Fachhochschule St Polten GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fachhochschule St Polten GmbH filed Critical Fachhochschule St Polten GmbH
Publication of EP4256455A1 publication Critical patent/EP4256455A1/de
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0852—Quantum cryptography
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0631—Substitution permutation network [SPN], i.e. cipher composed of a number of stages or rounds each involving linear and nonlinear transformations, e.g. AES algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2211/00—Indexing scheme relating to details of data-processing equipment not covered by groups G06F3/00 - G06F13/00
    • G06F2211/005—Network, LAN, Remote Access, Distributed System

Definitions

  • the present invention relates to a method according to the preamble of patent claim 1.
  • DLT Distributed ledger technology
  • blockchain is always used, but chaining and the ideas of DAGs are also possible. This means that the procedure according to the patent does not differentiate between blockchain and DLT.
  • BlockDAGs implementations such as Nano or RChain
  • TDAGs implementations such as IOTA or Byteball.
  • Distributed ledger technology or better known as blockchain technology
  • blockchain technology is a technological trend that has the potential to transform several areas of society and large industries such as finance, logistics, healthcare, public sector applications, etc.
  • blockchains With blockchains, the entire processing and storage of the data takes place on site in so-called “nodes” and the data is permanently and unchangeably linked with a cryptographic process.
  • the existing central systems should be able to continue to be used.
  • a program is integrated as middleware into the operating system and / or before and / or in and / or after database system (s) and / or IT applications the IT application does not need to be changed or only slightly, and that according to the authorizations and thus the relevant read/write protection, the data or parts thereof are cryptographically encrypted before writing to a non-volatile data store and/or database system and/or file system and after Reading from a non-volatile data store and/or database system and/or file system the data or parts thereof are cryptographically decrypted.
  • the overall system primarily includes workstations (PCs, laptops, smartphones, etc.) in the form of full nodes that receive all data, light nodes that only receive the desired data, and service -Nodes, which also take on administrative/security tasks. Full and light nodes are also called user nodes. Each node can be a user node and/or a service node, if required.
  • the existing central system can be fully retained for all users who want to continue working as before.
  • this management blockchain is accessible to all nodes, where this management blockchain is created from the data of the authorization and entitlement systems present in the central system and/or other data by a management unit in service nodes and in nodes, this management unit is connected to the applications and/or the operating system and/or the database systems and/or the central authorization and authorization systems in the middleware.
  • This management unit is connected to the applications and/or the operating system and/or the database systems and/or the central authorization and authorization systems in the middleware.
  • the existing authorization systems are thus retained.
  • the data from the authorization systems is only mapped to an administration blockchain to meet the "blockchain requirements" and this administration blockchain is sent to all nodes with every change, so that on the one hand every node knows all the current data from the authorization systems at all times, even if a central authorization system fails, and on the other hand, so that all changes to permissions are unchanged in a management blockchain and therefore all processes can be traced later.
  • the central authorization and authorization systems for delivering the current authorizations can be retained and the central systems for processing applications for users who want to continue working via the central systems can be retained and act as separate nodes. Because the data encrypted in the nodes is used unencrypted in the central systems, the data must be suitably decrypted before it is transferred to a central system and suitably encrypted after it leaves the central system. The data is not linked in the central systems. As before, central systems process the user's applications directly and store the data. Central systems are also called host systems and are often located in a cloud.
  • a key point is data security.
  • unauthorized access can easily be prevented by the central computer not issuing the requested information to unauthorized users.
  • a blockchain With a blockchain, however, all the data is available on every full node, and you cannot prevent an experienced user from accessing this data by bypassing the database software, since he usually has administrator rights on his computer. Since the users on site on the nodes can usually gain sovereignty over all data, i.e. they have all administration rights, the existing central authorization systems and logical access control systems (especially read and write protection) can no longer guarantee the required protection of the data. since they can be circumvented relatively easily. This protection is therefore solved with the help of a suitable encryption and decryption of the data, i.e. with the help of a cryptographic-based logical access control system. Because only the authorized nodes know the necessary cryptographic keys, all nodes can read all data, but no longer understand them (this requires suitable decryption).
  • the data required for this can be linked to form a data block chain. Although this ensures the traceability of the processing, it means that data can no longer be deleted without destroying the integrity of the data block chain.
  • data can be made unreadable by deleting the key in all nodes, despite the concatenation of the data blocks.
  • the data can be made unreadable by deleting the assigned key in all nodes if necessary.
  • "Deleting" within the meaning of the General Data Protection Regulation, which must be possible for example in the case of personal data, is not only understood to mean the complete destruction of this information, but also making it unreadable, e.g. by destroying the key required for decryption. Since it is in the nature of a blockchain that data cannot be deleted without destroying the chain, these features create a solution to still comply with the General Data Protection Regulation.
  • quantum computer-secure cryptographic algorithms are used for the cryptographic encryption and decryption and calculation of electronic signatures, e.g. grid-based and/or code-based and/or hash-based and/or multivariate cryptography and/or Cryptography based on supersingular isogenic curves and/or for symmetric encryption, e.g. the AES method (Advanced Encryption Standard).
  • the rows and/or columns or data fields of rows of tables are cryptographically encrypted according to the authorizations of users and/or roles and/or other subjects.
  • the write protection must include encryption of the data as well as further protection, in that the other nodes only accept a write process from a node in their database including the blockchain after they have the write authorization for this node checked positively. If an unauthorized node changes data, this only affects it locally, but not the entire blockchain or databases or files, which are/are distributed decentrally across many nodes.
  • FPE format-preserving-encryption
  • a data type does not allow a complete conversion to an interval from 0 to 2 n -1, as is the case, for example, with floating-point numbers or the time (a time represented in hours, minutes and seconds can be mapped densely to an interval from 0 to 86,399 , but 86,399 is not a power-of-2 1) is scrambled until the result is within the desired interval.
  • the time data type usually called TIME in database systems
  • a further embodiment of the invention provides that all older generations of the read key can be calculated in each node from the current cryptographic read key by an asymmetric quantum computer-secure decryption and stored in service nodes or hardware -Token as part of the service node through an asymmetric quantum computer-secure encryption new key generations. This way, anyone who has the current read key can decrypt any previously encrypted data, but whoever does not get a newly generated key will no longer be able to read the data encrypted with the new key.
  • the cryptographic concatenation of the data blocks is preferably separated into a multi-level concatenation system, with no concatenation taking place at the lowest level and this only applies to the node, with temporary concatenation also taking place at the middle level and this only applying to the node and finally on the upper level with validity in the overall system, a final concatenation takes place, whereby the lowest and/or middle level and/or upper level can also be omitted, so that memory is released during processing in the node and before distribution to all other nodes and storage space is saved can be.
  • database commands or files only the hash values thereof including header data can be concatenated.
  • the possible values are divided into classes, preferably with a class width of 2 n , and that encryption or decryption is carried out until, after encryption or decryption, the value is again in the specified class, so that even after the encryption, the values of all individual elements of one class are greater or smaller than the values of all individual elements of another class, so that the conditions ⁇ and > and ⁇ and ⁇ are fulfilled despite encryption are preserved, whereby the bit length of the individual elements of an interval is always based on the required bit length of the largest value of the interval.
  • the central authorization and authorization systems for the delivery of the current authorizations can be retained and/or the central systems for processing applications for users can be retained and act as separate nodes, with the data encrypted in the nodes in the central systems are used unencrypted and therefore the data are suitably decrypted before being transferred to a central system and suitably encrypted after leaving the central system.
  • one embodiment of the invention provides that the middleware contains an IT security system and that this IT security system specifies the security requirements and/or cryptographic methods of each individual node, checks them in all nodes and reports discrepancies to the other nodes.
  • the generation and storage of the cryptographic keys and/or the encryption and decryption of the data blocks in the nodes can take place either unprotected in the node or in a hardware-protected sandbox in the node or in external hardware tokens, with the IT -Security system always controls the security level in the node and forwards deviations to all other nodes.
  • a direct acyclic graph can be used to achieve the necessary asynchronicity and transaction speed for cryptographic chaining in the data block chain and/or the management block chain.
  • Symmetrical and asymmetrical methods can be used for the encryption and decryption of the data.
  • the cryptographic keys are derived from so-called root keys using cryptographic methods or hash methods such as SHA-2 and SHA-3.
  • cryptographic methods or hash methods such as SHA-2 and SHA-3.
  • n nodes are selected at the beginning, called main nodes in the following, with each of these n main nodes determining its own root key part as a random number.
  • a commutative asymmetric encryption method is used to generate a root key, such as the Diffie-Hellman method (e.g. ECDH with elliptic curves or the quantum computer-safe CSIDH method Commutative Supersingular Isogeny Diffie-Hellman).
  • the rootkey is generated as follows: First, the start value "x" is encrypted in a main node with this encryption method and the own rootkey part as the key, then the result is sent step by step to all other main nodes and there in the individual main -Nodes further encrypts the current result with the respective rootkey part until encryption has taken place in all main nodes with their own rootkey part.
  • the root key results from the last main node. If this root key is not to be transmitted unencrypted to the other main nodes, this procedure is carried out n times with the main nodes in a different order, so that each main node performs the last encryption once and thus receives the result.
  • this new node For encrypted transmission of the root key to another (new) node, this new node also determines its own root key part as a random number.
  • the start value "x" is then encrypted in the new node using this encryption method and your own rootkey part as the key.
  • the result is then sent step by step to all main nodes and the current result is further encrypted there in the individual main nodes with the respective root key part until encryption has taken place in all main nodes with their own root key part. Finally, the result is sent to the new node and decrypted there with its own rootkey part.
  • This last result now gives the desired rootkey.
  • the rootkey is calculated by encrypting the value of "x" with all rootkey parts of the n main nodes. This calculation always gives the same result for a specific root key.
  • the rootkey part of a new node is a random number
  • each new rootkey calculation always starts with a different rootkey part, which means that all intermediate results are always different for each new rootkey calculation, which is important for security reasons.
  • this encryption in the new node and in the main nodes should be protected only in external high-security hardware tokens, and not in the nodes themselves, and all rootkey-parts are exclusively in these high-security hardware tokens, which is in of an embodiment of the invention.
  • the result of the encryption is also electronically signed in the hardware token of each node and the signature is also sent to the next node. All hardware tokens of the main nodes or replacement nodes and the new node then check this signature before their encryption process and only carry out the encryption if the result is positive. This guarantees that all encryption for the root key calculation is only in hardware tokens.
  • Replacement nodes are also selected for each of these n main nodes, and these each receive their root key part in encrypted form from the main nodes. Therefore, there is at least one backup node for each main node.
  • the reading database commands and/or file commands are checked with regard to the read authorization of the relevant user or the relevant role or another relevant subject and that the writing database commands and /or file commands related to the write permission of the relevant user or role or other relevant subject from its own node and during data replication to all other nodes are checked by the other nodes using the management unit according to the management blockchain and if valid passed on to the responsible database system or file system.
  • the validity start time of the write authorization is also compared with the time stamp on the other nodes and the plausibility of the time stamp is checked and the reading and writing commands are only passed on to the responsible database system or file system if this is the case will.
  • the required access protection is therefore replaced by a cryptographic access protection system in the method according to the invention. It must protect the data from unauthorized reading solely through data encryption.
  • the cryptographic keys are stored in so-called service nodes, which are special nodes for security tasks and administrative tasks, or hardware tokens according to ISO/IEC ⁇ 7816 (e.g. EAL4+ certified), which are e.g. highly secure chip cards such as those used today in bank cards, passports or SIM Maps are used, generated and distributed from there to all nodes with high security (if possible quantum computer security) in encrypted form.
  • Every writing process i.e. every change or addition to data, is carried out by data encryption where possible and permitted.
  • This encryption also enables read protection (see above).
  • each node can overwrite existing data - and that is all data in the case of a full node - at any time, the write protection requires an additional protection mechanism.
  • Every write process at a node must be communicated to every other node in the context of data replication via the communication system so that the data stock is the same in all nodes. This is done by each node providing the data required for the replication with a digital/electronic signature during this data replication and sending it to all other nodes.
  • An ECDSA or a method from post-quantum cryptography, for example, can be used as an electronic signature method.
  • the nodes that receive the data required for replication including the signature, check the electronic signature and thus the integrity and authenticity of the data. If these nodes determine that the sending node had the required write authorization according to the management block chain, they accept the received data in a suitable form in their database (file or database) in the right places, otherwise the received data block is rejected.
  • IT security A sensitive area of blockchains and decentralized systems with simple nodes is IT security. It is much easier to adequately secure and audit a central IT security system than hundreds or thousands of simple nodes. However, if the IT applications and data storage are completely processed on these nodes, which is the case with blockchains, the overall security depends on each individual node. This means that suitable organizational and technical IT security management and IT security technologies are required that can also guarantee adequate IT security on decentralized workstations/user nodes. For example, it is determined here whether the data is encrypted symmetrically or asymmetrically, which cryptographic method and key management is used, where the key management and data encryption/decryption take place on site in the node and which general IT security requirements are placed on the node.
  • Sensitive parts of the process must be relocated to hardware-protected environments such as EAL4+ certified hardware tokens according to ISO/IEC ⁇ 7816, SGX (Software Guard Extensions), TPM (Trusted Platform Module according to TCG specification).
  • the process includes a security control system that is used on all nodes and, as far as possible, automatically controls security on site and reports deviations to the other nodes.
  • authorization and authorization systems such as RMS (Microsoft Rights Management System), Active Directory etc. and the authorization and authorization systems integrated in the individual database and operating systems as well as IT applications have an important task in today's IT applications in headquarters.
  • RMS Microsoft Rights Management System
  • Active Directory Active Directory
  • IT applications have an important task in today's IT applications in headquarters.
  • several authorization systems are active in parallel and the individual IT applications usually get all or part of the authorizations and roles of the individual users from them as required.
  • the method according to the invention generates the management blockchain in one or more service nodes by fetching the authorizations from the authorization systems and/or entering the authorizations completely or partially directly into service nodes and immediately writing all changes to the management blockchain.
  • the data itself is divided into blocks.
  • Such a block can, for example, be a role with all assigned subroles, users, user groups and objects (e.g. file directories or databases or tables, rows, columns etc. of databases).
  • each node can use the management blockchain to check whether an authorized person has created and concatenated this block.
  • management block chain which is necessary to, among other things, bring together classic authorization systems and then make it available to all nodes.
  • This management blockchain contains at least four different block types: blocks with all relevant data about the individual nodes (node blocks), blocks with all authorizations from the authorization systems (authorization blocks), certificate blocks with all necessary certificates of the nodes (a certificate contains the public key of an asymmetric cryptography and the associated designation of the "owner"), parameter blocks with all parameters for the key management and for the encryption/decryption of the data and for the data conversion and for the determination of the root key.
  • This management blockchain supplies the individual nodes with the necessary authorizations and other data (such as certificates, parameters, etc.), increases availability and serves to log the sensitive area of authorizations.
  • Fig. 1 the principle of a blockchain
  • Fig. 2 a node
  • Fig. 3 several nodes in a network
  • Fig. 4 shows the individual modules of the middleware according to the invention, how it works together with a service node.
  • a data block chain 2 contains blocks 7 which are connected to one another via chains 11 .
  • each chain 11 consists in the fact that each block 7 has stored at least one hash value of the previous block 7, so that it is immediately recognizable if one of the previous blocks has been manipulated. This means that the history of the changes can be fully traced at any time.
  • a node 3 is shown in Fig. 2.
  • the node 3 contains an operating system 4 in which the middleware 6 according to the invention is integrated.
  • the middleware 6 communicates with other nodes via a network 13, as will be explained in more detail with reference to Fig. 3.
  • the middleware 6 also communicates with a database system 5.
  • An application 1 also runs on the node 3, which application can contain a further part 6' of the middleware.
  • the application 1 communicates in the usual way with the operating system 4 (in this case with the middleware 6 of the operating system 4), that is to say read and write commands.
  • the operating system 4 communicates in the usual way with a file system 8 of a permanent memory that is also present in the node 3 .
  • the data block chain 2 (see Fig. 1) is stored in this file system.
  • Fig. 3 shows the connection of several (in the example four) nodes 3, which are shown in a simplified manner compared to Fig. 2. Each node 3 can communicate with each other node 3 via a network 13 .
  • Middleware 6 is shown in Fig. 4 as it communicates with a service node 16.
  • the service node 16 has an administration unit 18 .
  • the management unit 18 of the service node 16 manages a management blockchain 14, the key management, etc. For this purpose, it is connected to several (three in the example) central authorization and authorization systems 15 and updates the management blockchain 14 due to changes in these central ones Authorization and authorization systems 15.
  • the middleware 6 also has a management unit 18', which is connected to the management unit 18 of the service nodes 16 via the network 13 in order to create a local copy 14' of the management blockchain with the management blockchain 14 in the service -Node 16 to match and thus get the current permissions. In this way, a temporary failure of the central authorization and entitlement systems 15 has no effect.
  • the management units 18, 18' are each connected to a hardware token 19, 19'.
  • a central point of the present invention is the encryption 9 of the data and the decryption 10 of the data. This is done using cryptographic keys 12, which are made available by the management unit 18'.
  • the encrypted data is transmitted from the database system 5 or the file system 8 to the decryption 10 and from there to the application 1 in plain text.
  • data that comes from the application 1 in plain text is transmitted to the encryption 9 and then fed to the database system 5 or the file system 8 in encrypted form and transmitted to the other nodes via the network 13 for data replication.
  • the system 17 checks whether this node is authorized to write this data. If this is the case, then in addition to the suitable transmission of the data to the database system 5 or the file system 8 and to the network 13, an entry is also made in the data block chain 2 if the processing mode provides for concatenation.
  • Reference list 1 applications in their own node 2 data blockchain 3 nodes 4 operating system in its own node 5 database systems in your own node 6 middleware 7 block of the data blockchain 8 file system and permanent storage in its own node 9 Encryption of data 10 Decryption of Data 11 Concatenation of blocks 12 Cryptographic Keys 13 network 14, 14' management blockchain 15 Central authorization and authorization systems 16 service nodes 17 Write Permission Check System 18, 18' management unit in the nodes 19, 19' hardware token

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Electromagnetism (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Storage Device Security (AREA)

Abstract

Damit ein Verfahren zum Migrieren einer IT-Anwendung eines zentralen Systems 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 bei Bedarf 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

    VERFAHREN ZUM MIGRIEREN EINER IT-ANWENDUNG Technisches Gebiet
  • Die vorliegende Erfindung betrifft ein Verfahren nach dem Oberbegriff von Patentanspruch 1.
    • Stand der Technik
  • Es stehen drei Verarbeitungsmodi zur Auswahl: beim ersten erfolgt keine Verkettung von Daten, beim zweiten werden die Daten in einem mehrstufigen Verkettungssystem verkettet und beim dritten werden nur die Hashwerte der Daten inklusive Datenheader verkettet.
  • Distributed Ledger Technology (DLT) ist der Überbegriff für Blockchain-Technologien und verschiedene Arten von DAG-Technologien (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.
  • 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.
  • Die heutigen Blockchain-Technologien bilden eine eigenständige, geschlossene "IT-Welt", für die man neue geeignete IT-Anwendungen sucht und realisiert. Daraus entstehen ganz neue, 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.
    • Darstellung der Erfindung
  • 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 nach dem Oberbegriff von Patentanspruch 1 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 Lese‑/Schreibschutz die Daten 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 und/oder Dateisystem die Daten oder Teile davon 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. Jeder Node kann bei Bedarf Benutzer-Node und/oder Service-Node sein. 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 oder zumindest in ein dezentrales System gesprochen. Diese Erweiterung kann oftmals völlig automatisch durch die Middleware passieren, wenn bei der IT-Anwendung keine Änderungen erforderlich sind. In der Praxis wird aber meist eine zumindest geringfügige Portierung erforderlich sein, wo einige Anpassungen erfolgen.
  • Es ist zweckmäßig, wenn die Zugriffsberechtigungen zu Daten in Datenbanksystemen und Dateien in einer Verwaltungsblockchain gespeichert werden und diese Verwaltungsblockchain allen Nodes zugänglich ist, wobei diese Verwaltungsblockchain aus den Daten der im Zentralsystem vorhandenen Autorisierungs- und Berechtigungssysteme und/oder anderen Daten von einer Verwaltungseinheit in Service-Nodes erstellt wird und in Nodes diese Verwaltungseinheit in der Middleware mit den Anwendungen und/oder dem Betriebssystem und/oder den Datenbanksystemen und/oder den zentralen Autorisierungs- und Berechtigungssystemen verbunden ist. Die vorhandenen Berechtigungssysteme bleiben somit erhalten. Die Daten der Berechtigungssysteme werden nur zur Erfüllung der "Blockchain-Anforderungen" zusätzlich auch auf einer Verwaltungsblockchain abgebildet und diese Verwaltungsblockchain bei jeder Änderung allen Nodes zugesendet, damit einerseits jeder Node jederzeit alle aktuellen Daten der Berechtigungssysteme kennt, auch wenn ein zentrales Berechtigungssystem ausfällt, und andererseits damit sich alle Änderungen von Berechtigungen unverändert in einer Verwaltungsblockchain befinden und daher alle Vorgänge später nachvollzogen werden können.
  • Die Verwaltungsblockchain kann vorzugsweise 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
    • Berechtigungen, die aus einer oder mehreren Bedingungen ermittelt werden
    • Zertifikats-Blöcke mit allen erforderlichen Zertifikaten und/oder
    • Parameter-Blöcke mit allen erforderlichen Werten für das Schlüsselmanagement und/oder die Datenver‑/Entschlüsselung und/oder die Datenumwandlung und/oder die rootkey-Ermittlung.
  • 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, die weiter über die Zentralsysteme arbeiten möchten, können erhalten bleiben und dabei als eigene Nodes agieren. Weil in den Zentralsystemen die in den Nodes verschlüsselten Daten unverschlüsselt verwendet werden, müssen die Daten vor der Übergabe an ein Zentralsystem geeignet entschlüsselt und nach dem Verlassen des Zentralsystems geeignet verschlüsselt werden. In den Zentralsystemen erfolgt keine Verkettung der Daten. Zentralsysteme verarbeiten wie bisher direkt die Anwendungen der Benutzer und speichern die Daten. Zentralsysteme werden auch Hostsysteme genannt und befinden sich oftmals in einer Cloud.
  • 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 mit Hilfe einer geeigneten Ver- und Entschlüsselung der Daten gelöst, d.h. mit Hilfe eines auf Kryptografie basierenden logischen Zugriffskontrollsystems. Weil nur die berechtigten Nodes die erforderlichen kryptografischen Schlüssel kennen, können zwar alle Nodes alle Daten lesen, aber nicht mehr verstehen (dafür ist eine geeignete Entschlüsselung erforderlich).
  • Für eine sichere Nachvollziehbarkeit der Verarbeitung können die dafür erforderlichen Daten durch eine Verkettung zu einer Datenblockchain verkettet werden. Dies gewährleistet zwar die Nachvollziehbarkeit der Verarbeitung, hat aber zur Folge, dass Daten nicht mehr gelöscht werden können, ohne die Integrität der Datenblockchain zu zerstören.
  • Aus diesem Grund ist nach einem weiteren Merkmal der Erfindung vorgesehen, dass Daten trotz der Verkettung der Datenblöcke durch Löschung des Schlüssels in allen Nodes unlesbar gemacht werden können. Somit können trotz der Verkettung der Datenblöcke die Daten bei Bedarf durch Löschung des zugeordneten Schlüssels in allen Nodes unlesbar gemacht werden. Als "Löschen" im Sinne der Datenschutzgrundverordnung, das z.B. bei personenbezogenen Daten möglich sein muss, wird 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 und/oder für die symmetrische Verschlüsselung z.B. das AES-Verfahren (Advanced Encryption Standard).
  • Nach einer Ausführungsform der Erfindung werden bei der Verschlüsselung von Daten für Datenbanksysteme die Zeilen und/oder Spalten oder Datenfelder von Zeilen von Tabellen kryptografisch entsprechend den Berechtigungen von Benutzern und/oder Rollen und/oder anderen Subjekten verschlüsselt.
  • 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 bzw. Datenbanken bzw. Dateien, die dezentral auf viele Nodes verteilt ist/sind.
  • In einer weiteren Ausführungsform der Erfindung werden mehrere Datenfelder von Zeilen von Tabellen von Datenbanken und/oder ganze Zeilen/Spalten von Tabellen, die den gleichen Ver- bzw. Entschlüsselungsschlüssel besitzen, in ein einziges Datenfeld zusammengefasst. Bei der Ver- und Entschlüsselung wird dann nur dieses zusammengefasste Datenfeld verwendet. Innerhalb dieses zusammengefassten Datenfeldes werden alle einzelnen Datenfelder mit verschiedenen Datentypen vor der Verschlüsselung auf ein dichtes, d.h. ohne Lücken, Format umgewandelt und nach der Entschlüsselung wieder auf das ursprüngliche Format zurückgewandelt. Dies spart Rechenzeit und Speicherplatz.
  • Weil die Datenfelder von Zeilen 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 der Datenfelder 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. FF1 oder FF3 nach NIST Special Publication 800-38G (Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption) verwendet werden.
  • Wenn dabei ein Datentyp keine komplette Umwandlung auf ein Intervall 0 bis 2n-1 erlaubt, wie es z.B. bei Gleitkommazahlen oder der Uhrzeit der Fall ist (eine Uhrzeit in Stunden, Minuten und Sekunden dargestellt kann auf ein Intervall von 0 bis 86.399 dicht abgebildet werden, jedoch stellt 86.399 keine Zweierpotenz-1 dar), wird so oft verschlüsselt, bis das Ergebnis innerhalb des gewünschten Intervalls liegt. Beim Datentyp Uhrzeit (bei Datenbanksystemen meist TIME genannt) bedeutet dies, dass nach der Umwandlung eine 17-Bit lange Zahl vorliegt, die verschlüsselt wird, und danach ein Ergebnis zwischen 0 und 131.071 vorliegen kann. Wenn der Wert nach der Verschlüsselung größer als 86.399 ist, muss wieder verschlüsselt werden usw., bis das Intervall 0 bis 86.399 eingehalten wird.
  • Da Schlüssel bekanntlich immer wieder geändert werden müssen, ist nach einer weiteren Ausgestaltung der Erfindung vorgesehen, dass sich in jedem Node aus dem aktuellen kryptografischen Leseschlüssel durch eine asymmetrische Quantencomputer-sichere Entschlüsselung alle älteren Generationen des Leseschlüssels berechnen lassen und sich in Service-Nodes oder Hardware-Token als Teil des Service-Nodes durch eine asymmetrische Quantencomputer-sichere Verschlüsselung neue Schlüsselgenerationen berechnen lassen. Auf diese Weise kann jeder, der den aktuellen Leseschlüssel hat, alle früher verschlüsselten Daten entschlüsseln, aber wer keinen neu generierten Schlüssel bekommt, kann die mit dem neuen Schlüssel verschlüsselten Daten nicht mehr lesen.
  • 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 und/oder obere 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. Anstelle von Daten, von Datenbankbefehlen oder Dateien können auch nur die Hashwerte davon inklusive Headerdaten verkettet werden.
  • Nach einer weiteren Ausgestaltung der Erfindung ist vorgesehen, dass bei zumindest einem Datenfeld die möglichen Werte in Klassen eingeteilt sind, vorzugsweise mit einer Klassenbreite von 2n, und dass eine Ver- bzw. Entschlüsselung so oft durchgeführt wird, bis nach der Ver- bzw. Entschlüsselung der Wert wieder in der vorgegebenen Klasse liegt, sodass auch nach der Verschlüsselung die Werte aller einzelnen Elemente einer Klasse größer bzw. kleiner sind als die Werte aller einzelnen Elemente einer anderen Klasse, sodass dadurch die Bedingungen < und > und ≤ und ≥ trotz Verschlüsselung erhalten bleiben, wobei sich die Bitlänge der einzelnen Elemente eines Intervalls immer an der erforderlichen Bitlänge des größten Wertes des Intervalls orientiert.
  • Auf diese Weise ist es möglich, Datenbankbefehle mit Where-Bedingungen (<,>,≤,≥) auf den verschlüsselten Daten auszuführen, denn die Where-Bedingungen <,>,≤ und ≥ sind nach der Verschlüsselung genau dann erfüllt, wenn sie vorher erfüllt waren. Dadurch kann erheblich Rechenzeit gespart werden. Die Ver- bzw. Entschlüsselung wird so oft durchgeführt, bis nach der Ver- bzw. Entschlüsselung wieder das vorgegebene Intervall eingehalten wird. Alle Werte eines Intervalls "a bis b" sind auch nach der Verschlüsselung größer als alle verschlüsselten Werte eines Intervalls "c bis d", wenn gilt a>d. Damit bleiben die Bedingungen <,>,≤ und ≥ trotz Verschlüsselung erhalten. Die Bitlängen der Werte in den beiden Intervallen können dabei verschieden groß sein, z.B. die Werte des Intervalls "c bis d" kleiner als die vom Intervall "a bis b". Man wird dabei immer den kleinstmöglichen Wert wählen, damit die Ver-/Entschlüsselungsvorgänge minimiert werden.
  • Bei der erfindungsgemäß vorgesehenen Migration können die zentralen Autorisierungs- und Berechtigungssysteme zur Anlieferung der aktuellen Berechtigungen erhalten bleiben und/oder auch die Zentralsysteme zur Verarbeitung von Anwendungen für Benutzer erhalten bleiben und dabei als eigene Nodes agieren, wobei in den Zentralsystemen die in den Nodes verschlüsselten Daten unverschlüsselt verwendet werden und daher die Daten vor der Übergabe an ein Zentralsystem geeignet entschlüsselt und nach dem Verlassen des Zentralsystems geeignet verschlüsselt werden.
  • Zur Erhöhung der Sicherheit ist nach einer Ausgestaltung der Erfindung vorgesehen, dass die Middleware ein IT-Sicherheitssystem enthält und dass dieses IT-Sicherheitssystem die Sicherheitsanforderungen und/oder 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 Nodes kann je nach Sicherheitsniveau entweder ungeschützt im Node oder in einer Hardware-geschützten Sandbox im Node oder in externen Hardware-Token ablaufen, wobei bei Bedarf das IT-Sicherheitssystem das Sicherheitsniveau im Node stets kontrolliert und Abweichungen an alle anderen Nodes weitergibt.
  • Um die notwendige Asynchronität und Transaktionsgeschwindigkeit zur kryptografischen Verkettung in der Datenblockchain und oder der Verwaltungsblockchain zu erreichen, kann ein Direkter-azyklischer-Graph eingesetzt werden.
  • Es können für die Ver- und Entschlüsselung der Daten symmetrische und asymmetrische Verfahren verwendet werden. Bei der Verwendung von symmetrischen Verfahren werden in einer Ausführungsform der Erfindung die kryptografischen Schlüssel aus sogenannten rootkeys durch kryptografische Verfahren oder Hash-Verfahren, wie dem SHA-2 und SHA-3, abgeleitet. Für die Ermittlung des rootkeys mit Startwert "x" werden zu Beginn n Nodes ausgewählt, im Folgenden Haupt-Nodes genannt, wobei jeder dieser n Haupt-Nodes einen eigenen rootkey-part als Zufallszahl ermittelt. Für die Erzeugung eines rootkeys wird ein kommutatives asymmetrisches Verschlüsselungsverfahren verwendet, wie das Diffie-Hellman Verfahren (z.B. ECDH mit elliptischen Kurven oder das Quantencomputer-sichere CSIDH Verfahren Commutative Supersingular Isogeny Diffie–Hellman).
  • Der rootkey wird wie folgt erzeugt: Zunächst wird in einem Haupt-Node der Startwert "x" mit diesem Verschlüsselungsverfahren und dem eigenen rootkey-part als Schlüssel verschlüsselt, dann wird das Ergebnis schrittweise an alle anderen Haupt-Nodes gesendet und dort in den einzelnen Haupt-Nodes das jeweils aktuelle Ergebnis wieder mit dem jeweiligen rootkey-part weiterverschlüsselt, bis in allen Haupt-Nodes eine Verschlüsselung mit dem jeweils eigenen rootkey-part erfolgt ist. Der rootkey ergibt sich so beim letzen Haupt-Node. Wenn dieser rootkey nicht unverschlüsselt an die anderen Haupt-Nodes übertragen werden soll, führt man dieses Verfahren n Mal mit unterschiedlicher Reihenfolge der Haupt-Nodes durch, sodass jeder Haupt-Node einmal die letzte Verschlüsselung durchführt und somit das Ergebnis erhält.
  • Zur verschlüsselten Übertragung des rootkeys an einen anderen (neuen) Node ermittelt auch dieser neue Node einen eigenen rootkey-part als Zufallszahl. Anschließend wird im neuen Node der Startwert "x" mit diesem Verschlüsselungsverfahren und dem eigenen rootkey-part als Schlüssel verschlüsselt. Das Ergebnis wird dann schrittweise an alle Haupt-Nodes gesendet und dort in den einzelnen Haupt-Nodes das jeweils aktuelle Ergebnis wieder mit dem jeweiligen rootkey-part weiterverschlüsselt, bis in allen Haupt-Nodes eine Verschlüsselung mit dem eigenen rootkey-part erfolgte. Zum Schluss wird das Ergebnis an den neuen Node gesendet und dort mit dem eigenen rootkey-part entschlüsselt. Dieses letzte Ergebnis ergibt nun den gewünschten rootkey. Der rootkey berechnet sich also aus der Verschlüsselung des Wertes von "x" mit allen rootkey-parts der n Haupt-Nodes. Diese Berechnung ergibt für einen bestimmten rootkey immer dasselbe Ergebnis. Weil der rootkey-part eines neuen Nodes eine Zufallszahl ist, wird bei jeder neuen rootkey Berechnung immer mit einem anderen rootkey-part gestartet und dadurch sind bei jeder neuen rootkey-Berechnung immer alle Zwischenergebnisse verschieden, was aus Sicherheitsgründen wichtig ist. Ebenso sollte aus Sicherheitsgründen diese Verschlüsselung im neuen Node und in den Haupt--Nodes geschützt nur in externen hochsicheren Hardware-Token erfolgen, und nicht in den Nodes selbst, und alle rootkey-parts sich ausschließlich in diesen hochsicheren Hardware-Token befinden, was in einer Ausführungsform der Erfindung der Fall ist. In einer weiteren Ausführungsform der Erfindung wird im Hardware-Token jedes Nodes das Ergebnis der Verschlüsselung auch noch elektronisch signiert und die Signatur an den nächsten Node mitgesendet. Alle Hardware-Token der Haupt-Nodes bzw. Ersatz-Nodes und des neuen Nodes überprüfen dann vor ihrem Verschlüsselungsvorgang diese Signatur und führen nur bei positivem Ergebnis die Verschlüsselung durch. Dadurch wird garantiert, dass alle Verschlüsselungen zur rootkey-Berechnung nur in Hardware-Token erfolgt.
  • Für jeden dieser n Haupt-Nodes werden auch Ersatz-Nodes ausgewählt und diese erhalten von den Haupt-Nodes jeweils ihren rootkey-part in verschlüsselter Form. Daher ist zu jedem Haupt-Node zumindest ein Ersatz-Node vorhanden.
  • Schließlich ist nach einer Ausgestaltung der Erfindung vorgesehen, 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 Datei-Befehle in Bezug auf die Schreibberechtigung des relevanten Benutzers bzw. der relevanten Rolle bzw. eines sonstigen relevanten Subjekts vom eigenen Node und bei der Datenreplikation auf alle anderen Nodes von den anderen Nodes mit Hilfe der Verwaltungseinheit laut Verwaltungsblockchain überprüft werden und bei Gültigkeit an das zuständige Datenbanksystem bzw. Dateisystem weitergegeben werden.
  • Dabei ist es zweckmäßig, wenn bei der Datenreplikation bei den 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.
  • Schließlich kann man auch noch vorsehen, dass bei der Replikation der Daten vom eigenen Node auf alle anderen Nodes zusätzlich noch die für die Replikation erforderlichen Daten vom eigenen Node mit einer elektronischen Signatur versehen und an alle anderen Nodes gesendet werden und alle anderen Nodes die Signatur nach dem Empfang überprüfen und bei Unrichtigkeit der Signatur die Daten für die Datenreplikation von den anderen Nodes ablehnen.
  • 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 optionaler elektronischer Signatur, um das Schreiben von Daten zu schützen ‑ ersetzt in Verbindung mit Punkt 1. und 5. den Konsensmechanismus von Blockchains;
    3. ein geeignetes technisches IT-Sicherheitsmanagement und geeignete IT-Sicherheitstechnologien, die auch auf dezentralen Arbeitsplätzen (PCs, Laptops etc.) eine ausreichende IT-Sicherheit garantieren können, indem sie einerseits die Sicherheit in den Nodes ständig überprüfen und andererseits sensible Teile des Verfahrens in hardware-geschützte Umgebungen wie z.B. Hardware-Token, SGX (Software Guard Extensions) und TPM (Trusted Platform Module) verlagern;
    4. ein kryptografisches Datenverkettungssystem, das in Datei- und Datenbanksystemen einerseits die notwendige Verkettung aller Blöcke durchführt, aber dabei mit dem Speicher sehr sparsam umgeht, indem es mehrstufig aufgebaut ist und bei Datenbanken neben Headerdaten nur die schreibenden Datenbankbefehle inklusive Daten und sonstigen wichtigen Datenbankbefehle oder bei den Daten nur den Hashwert und bei Dateien neben Headerdaten alle Daten der Dateien oder nur die Hashwerte der Daten verkettet;
    5. eine Verwaltungs-Blockchain, die unter anderem wegen der zentralen Berechtigungssysteme und ständigen Verfügbarkeit des Systems zweckmäßig ist;
    6. eine Synchronisation und Replikation aller Datenbanken in allen Nodes, das die schreibenden Datenbank-Befehle und in Transaktionen zusammengefassten Befehle in allen Nodes in der gleichen Reihenfolge an das Datenbanksystem in jedem Node liefert und dabei alle anderen lokalen Datenbank-Befehle, sofern erforderlich, mitberücksichtigt.
  • Die Migration einer IT-Anwendung eines zentralen Systems (Hostsystems) auf eine dezentrale IT-Anwendung, die auf einem oder mehreren Nodes läuft, erfolgt dadurch, dass das erfindungsgemäße Verfahren als neue Middleware in die verwendeten Betriebssysteme, Datenbanksysteme und bei Bedarf auch IT-Anwendungen geeignet integriert wird.
  • Nachfolgend werden die 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 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 kann der Inhaber/Benutzer des Nodes die komplette Hoheit über sein System haben. 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 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 Hardware-Token nach ISO/IEC‑7816 (z.B. EAL4+ zertifiziert), 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 hochsicher (wenn möglich Quantencomputer-sicher) verschlüsselt verteilt.
    • ad 2.) Schreibschutzsystem
  • Jeder Schreibvorgang, d.h. jede Änderung oder Ergänzung von Daten, erfolgt durch eine Datenverschlüsselung, wo es möglich und erlaubt ist. 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, insbesondere in Dateien bzw. Datenbanken, muss jedem anderen Node im Rahmen der Datenreplikation geeignet über das Kommunikationssystem mitgeteilt werden, damit der Datenbestand in allen Nodes gleich ist. Dies erfolgt dadurch, dass jeder Node bei dieser Datenreplikation die für die Replikation erforderlichen Daten mit einer digitalen/elektronischen Signatur versieht und an alle anderen Nodes sendet. Als elektronisches Signaturverfahren kann dazu z.B. ein ECDSA oder ein Verfahren aus der Post-Quanten Kryptografie verwendet werden. Die Nodes, die die für die Replikation erforderlichen Daten inklusive Signatur empfangen, überprüfen die elektronische Signatur und damit die Integrität und Authentizität der Daten. Wenn diese Nodes feststellen, dass der sendende Node laut Verwaltungsblockchain die erforderliche Schreibberechtigung hatte, übernehmen sie die empfangenen Daten in geeigneter Form in ihre Datenbasis (Datei bzw. Datenbank) an den richtigen Stellen, ansonsten wird der empfangene Datenblock abgelehnt.
    • ad 3.) Sicherheitsmanagement
  • Ein sensibler Bereich von Blockchains und dezentralen Systemen mit einfachen Nodes ist die IT-Sicherheit. Es ist viel einfacher, eine Zentrale IT-sicherheitstechnisch ausreichend abzusichern und zu auditieren als hunderte oder tausende von einfachen 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 IT-Sicherheitsmanagement und IT-Sicherheitstechnologien erforderlich, die auch auf dezentralen Arbeitsplätzen/Benutzer-Nodes 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 Datenverschlüsselung/Datenentschlüsselung stattfindet und welche allgemeinen IT-Sicherheitsanforderungen an den Node gestellt werden. Sensible Teile des Verfahrens müssen in hardware-geschützte Umgebungen wie z.B. EAL4+ zertifizierten Hardware-Token nach ISO/IEC‑7816, SGX (Software Guard Extensions), TPM (Trusted Platform Module nach TCG-Spezifikation) 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.) Verwaltungsblockchain
  • 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 sowie IT-Anwendungen integrierten Autorisierungs- und Berechtigungssysteme. In den meisten zentralen IT-Systemen sind mehrere Berechtigungssysteme parallel aktiv und die einzelnen IT-Anwendungen holen sich meist komplett oder zum Teil 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 Verwaltungsblockchain, indem es sich von den Berechtigungssystemen die Berechtigungen holt und/oder die Berechtigungen komplett oder Teile davon direkt in Service Nodes eingegeben werden und sofort alle Veränderungen in die Verwaltungsblockchain schreibt. Die Daten selbst werden dabei in Blöcke unterteilt. Ein derartiger Block kann z.B. eine Rolle mit allen zugeordneten Subrollen, Benutzern, Benutzergruppen und Objekten (wie z.B. Dateiverzeichnisse oder Datenbanken oder Tabellen, Zeilen, Spalten etc. von Datenbanken) sein. Nach einer endgültigen Verkettung eines Blocks kann jeder Node aufgrund der Verwaltungsblockchain überprüfen, ob ein Berechtigter diesen Block erzeugt und verkettet hat.
  • Das heißt, im erfindungsgemäßen Verfahren existiert neben der Datenblockchain, wo bisherige Daten des Zentralsystems in jedem Node verkettet werden können, aber je nach Verarbeitungsmodus nicht müssen, eine weitere Blockchain, die sogenannte Verwaltungsblockchain, welche notwendig ist, um unter anderem klassische Berechtigungs-Systeme zusammenzuführen und dann allen Nodes zur Verfügung zu stellen. Diese Verwaltungsblockchain 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"), Parameter-Blöcke mit allen Parametern für das Schlüsselmanagement und zur Ver-/Entschlüsselung der Daten und für die Datenumwandlung und für die rootkey-Ermittlung.
  • Diese Verwaltungsblockchain 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.) Synchronisation und Replikation aller Datenbanken und Dateien in allen Nodes
  • Heutige Datenbanksysteme sind oftmals nicht in der Lage, dass alle Nodes auf Wunsch gleichzeitig auch Datenbankserver sind, was aber bei einem dezentralen System wie im vorliegenden Erfindungsgegenstand erforderlich ist, und auch der erforderliche Zugriffsschutz in den völlig offenen Nodes ist nicht umsetzbar. Dazu ist eine geeignete Replikation und Synchronisation aller Datenbanken in allen Nodes erforderlich. Bei der Datenbankreplikation und Datenbanksynchronisation werden die Daten zwischen allen Nodes automatisch so ausgetauscht, dass alle Datenbanken in allen Nodes den gleichen Informationsstand haben. Das Ergebnis ist eine verteilte Datenbank in allen Nodes. Dasselbe gilt für Dateisysteme.
    • Kurze Beschreibung der Zeichnungen
  • 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.
    • Bester Weg zur Ausführung der Erfindung
  • Das Prinzip einer Blockchain ist aus Fig. 1 ersichtlich. In einer Datenblockchain 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. 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 enthalten kann. 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 Datenblockchain 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.
  • 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 Service-Nodes 16 im Netzwerk 13 vorhanden.) Der Service-Node 16 weist eine Verwaltungseinheit 18 auf. Die Verwaltungseinheit 18 des Service-Nodes 16 verwaltet eine Verwaltungsblockchain 14, das Schlüsselmanagement, etc. Zu diesem Zweck steht sie mit mehreren (im Beispiel drei) zentralen Autorisierungs- und Berechtigungssystemen 15 in Verbindung und aktualisiert die Verwaltungsblockchain 14 auf Grund von Änderungen in diesen zentralen Autorisierungs- und Berechtigungssystemen 15. Die Middleware 6 weist auch eine Verwaltungseinheit 18' auf, wobei diese mit der Verwaltungseinheit 18 der Service-Nodes 16 über das Netzwerk 13 in Verbindung stehen, um eine lokale Kopie 14' der Verwaltungsblockchain mit der Verwaltungsblockchain 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 Verwaltungseinheiten 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 Verwaltungseinheit 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 zur Datenreplikation ü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 geeigneten Übertragung der Daten in das Datenbanksystem 5 bzw. das Dateisystem 8 sowie in das Netzwerk 13 auch ein Eintrag in die Datenblockchain 2, falls der Verarbeitungsmodus eine Verkettung vorsieht.
  • Bezugszeichenliste:
    1 Anwendungen im eigenen Node
    2 Datenblockchain
    3 Node
    4 Betriebssystem im eigenen Node
    5 Datenbanksysteme im eigenen Node
    6 Middleware
    7 Block der Datenblockchain
    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' Verwaltungsblockchain
    15 Zentrale Autorisierungs- und Berechtigungssysteme
    16 Service-Nodes
    17 System zur Überprüfung der Schreibberechtigung
    18, 18' Verwaltungseinheit in den Nodes
    19, 19' Hardware-Token

Claims (22)

  1. Verfahren zum Migrieren einer IT-Anwendung eines zentralen Systems 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 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 und vorzugsweise auch Schreibschutz die Daten 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 Daten oder Teile davon kryptografisch entschlüsselt (10) werden.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Zugriffsberechtigungen zu Daten in Datenbanksystemen und Dateien in einer Verwaltungsblockchain (14) gespeichert werden und diese Verwaltungsblockchain (14) allen Nodes (3) zugänglich ist, dass diese Verwaltungsblockchain (14) aus den Daten der im Zentralsystem vorhandenen Autorisierungs- und Berechtigungssysteme (15) und/oder anderen Daten von einer Verwaltungseinheit (18, 18') in Service-Nodes erstellt wird und dass in Nodes 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.
  3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Verwaltungsblockchain (14) 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
    - Berechtigungen, die aus einer oder mehreren Bedingungen ermittelt werden
    - Zertifikats-Blöcke mit allen erforderlichen Zertifikaten und/oder
    - Parameter-Blöcke mit allen erforderlichen Werten für das Schlüsselmanagement und/oder die Datenverschlüsselung/Datenentschlüsselung und/oder die Datenumwandlung und/oder die rootkey-Ermittlung.
  4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass für eine sichere Nachvollziehbarkeit der Verarbeitung die dafür erforderlichen Daten durch eine Verkettung (11) zu einer Datenblockchain verkettet werden.
  5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass Daten trotz der Verkettung (11) der Datenblöcke (7) durch Löschung des Schlüssels (12) in allen Nodes (3) unlesbar gemacht werden können.
  6. Verfahren nach einem der Ansprüche 1 bis 5, 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 und/oder AES-Verfahren für die symmetrische Kryptografie.
  7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass bei der Verschlüsselung (9) von Daten für Datenbanksysteme (5) Zeilen und/oder Spalten oder Datenfelder von Zeilen 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.
  8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass dabei mehrere einzelne Datenfelder von Zeilen von Tabellen von Datenbanken und/oder ganze Zeilen/Spalten von Tabellen, die den gleichen Ver- bzw. Entschlüsselungsschlüssel besitzen, in ein einziges Datenfeld zusammengefasst werden und dieses zusammengefasste Datenfeld ver- bzw. entschlüsselt wird und dass vor dieser Zusammenfassung von Datenfeldern die einzelnen Datenfelder in einen einheitlichen dichten, das heißt ohne Lücken, Datentyp umgewandelt werden und nach der Ver- bzw. Entschlüsselung wieder in die ursprünglichen Datentypen zurückgewandelt werden.
  9. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass bei der Verschlüsselung (9) und Entschlüsselung (10) dieser Zeilen und/oder Spalten oder Datenfelder von Zeilen von Tabellen formaterhaltende Kryptografie (Format-preserving-encryption), z.B. FF1 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.
  10. Verfahren nach einem der Ansprüche 1 bis 9, 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.
  11. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass die kryptografische Verkettung (11) der Datenblöcke (5) in ein mehrstufiges Verkettungssystem getrennt wird und dass auf der untersten Ebene keine Verkettung erfolgt und diese nur für den Node (3) gilt und dass auf der mittleren Ebene eine temporäre Verkettung erfolgt und diese nur für den Node (3) gilt und dass auf der oberen Ebene mit Gültigkeit im Gesamtsystem eine endgültige Verkettung (11) erfolgt und dass die unterste und/oder mittlere Ebene und/oder obere Ebene auch entfallen können und dass dadurch während der Verarbeitung im Node (3) und vor der Verteilung auf alle anderen Nodes (3) noch Speicher freigegeben und Speicherplatz eingespart werden kann und dass anstatt von Daten, von Datenbankbefehlen oder Dateien nur die Hashwerte davon inklusive Headerdaten verkettet werden.
  12. Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass bei zumindest einem Datenfeld die möglichen Werte in Klassen eingeteilt sind, vorzugsweise mit einer Klassenbreite von 2n, und dass eine Ver- bzw. Entschlüsselung so oft durchgeführt wird, bis nach der Ver- bzw. Entschlüsselung der Wert wieder in der vorgegebenen Klasse liegt, sodass auch nach der Verschlüsselung die Werte aller einzelnen Elemente einer Klasse größer bzw. kleiner sind als die Werte aller einzelnen Elemente einer anderen Klasse, sodass dadurch die Bedingungen < und > und ≤ und ≥ trotz Verschlüsselung erhalten bleiben, und dass sich die Bitlänge der einzelnen Elemente eines Intervalls immer an der erforderlichen Bitlänge des größten Wertes des Intervalls orientiert.
  13. Verfahren nach einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, dass die zentralen Autorisierungs- und Berechtigungssysteme (15) zur Anlieferung der aktuellen Berechtigungen erhalten bleiben und/oder dass auch die Zentralsysteme zur Verarbeitung von Anwendungen (1) für Benutzer erhalten bleiben und dabei als eigene Nodes (3) agieren und dabei in den Zentralsystemen die in den Nodes verschlüsselten Daten unverschlüsselt verwendet werden und daher die Daten vor der Übergabe an ein Zentralsystem geeignet entschlüsselt und nach dem Verlassen des Zentralsystems geeignet verschlüsselt werden.
  14. Verfahren nach einem der Ansprüche 1 bis 13, dadurch gekennzeichnet, dass die Middleware (6) ein IT-Sicherheitssystem enthält und dass dieses IT-Sicherheitssystem die Sicherheitsanforderungen und/oder kryptografischen Verfahren jedes einzelnen Nodes (3) vorgibt, in allen Nodes (3) überprüft und Abweichungen an die anderen Nodes (3) meldet.
  15. Verfahren nach einem der Ansprüche 1 bis 14, 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 bei Bedarf das IT-Sicherheitssystem das Sicherheitsniveau im Node (3, 16) stets kontrolliert und Abweichungen an alle anderen Nodes (3, 16) weitergibt.
  16. Verfahren nach einem der Ansprüche 1 bis 15, dadurch gekennzeichnet, dass Schlüssel für die symmetrische Kryptografie aus sogenannten rootkeys durch kryptografische oder Hash-Verfahren abgeleitet werden und für die Erzeugung eines rootkeys mit einem Startwert "x" zu Beginn n Nodes ausgewählt werden, im Folgenden Haupt-Nodes genannt, wobei jeder dieser n Haupt-Nodes einen eigenen rootkey-part als Zufallszahl ermittelt, und dass für die Erzeugung eines rootkeys ein kommutatives asymmetrisches Verschlüsselungsverfahren verwendet wird, wie z.B. ECDH oder das Quantencomputer-sichere CSIDH, wobei zunächst in einem Haupt-Node der Startwert "x" mit diesem Verschlüsselungsverfahren und dem eigenen rootkey-part als Schlüssel verschlüsselt wird, dann das Ergebnis schrittweise an alle anderen Haupt-Nodes gesendet wird und dort in den einzelnen Haupt-Nodes das jeweils aktuelle Ergebnis wieder mit dem jeweiligen rootkey-part weiterverschlüsselt wird, bis in allen Haupt-Nodes eine Verschlüsselung mit dem jeweils eigenen rootkey-part erfolgt ist, wodurch sich der rootkey beim letzen Haupt-Node ergibt.
  17. Verfahren nach Anspruch 16, dadurch gekennzeichnet, dass zur verschlüsselten Übertragung des rootkeys an einen neuen Node im System dieser neue Node auch einen eigenen rootkey-part als Zufallszahl ermittelt und zuerst im neuen Node der Startwert "x" mit diesem Verschlüsselungsverfahren und dem eigenen rootkey-part als Schlüssel verschlüsselt wird, dann das Ergebnis schrittweise an alle Haupt-Nodes gesendet wird und dort in den einzelnen Haupt-Nodes das jeweils aktuelle Ergebnis wieder mit dem jeweiligen rootkey-part weiterverschlüsselt wird, bis in allen Haupt-Nodes eine Verschlüsselung mit dem jeweils eigenen rootkey-part erfolgte, und zum Schluss das Ergebnis wieder an den neuen Node gesendet wird und dort mit dem eigenen rootkey-part entschlüsselt wird, wodurch sich der rootkey ergibt.
  18. Verfahren nach Anspruch 16 oder 17, dadurch gekennzeichnet, dass im Falle höherer Sicherheitsanforderungen alle diese Verschlüsselungen in externen hochsicheren Hardware-Token der einzelnen Nodes erfolgen und alle rootkey-parts sich ausschließlich in diesen externen Hardware-Token der Nodes befinden und dass im Hardware-Token jedes Nodes das Ergebnis der Verschlüsselung auch noch elektronisch signiert wird, die Signatur an den nächsten Node mitgesendet wird, alle Hardware-Token der Haupt-Nodes und gegebenenfalls des neuen Nodes vor ihrem Verschlüsselungsvorgang diese Signatur überprüfen und nur bei positivem Ergebnis die Verschlüsselung durchführen, sodass dadurch alle Verschlüsselungen zur rootkey-Berechnung in Hardware-Token garantiert werden.
  19. Verfahren nach einem der Ansprüche 16 bis 18, dadurch gekennzeichnet, dass für jeden dieser n Haupt-Nodes Ersatz-Nodes ausgewählt werden und diese von den Haupt-Nodes jeweils deren rootkey-part verschlüsselt erhalten und dadurch zu jedem Haupt-Node zumindest ein Ersatz-Node vorhanden ist und dieser verwendet wird, wenn der Haupt-Node ausfällt oder nicht erreichbar ist.
  20. Verfahren nach einem der Ansprüche 1 bis 19, 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 Datei-Befehle in Bezug auf die Schreibberechtigung des relevanten Benutzers bzw. der relevanten Rolle bzw. eines sonstigen relevanten Subjekts vom eigenen Node (3) und bei der Datenreplikation auf alle anderen Nodes (3) von den anderen Nodes (3) mit Hilfe der Verwaltungseinheit (18') laut Verwaltungsblockchain überprüft werden und bei Gültigkeit an das zuständige Datenbanksystem (5) bzw. Dateisystem (8) weitergegeben werden.
  21. Verfahren nach Anspruch 20, dadurch gekennzeichnet, dass bei der Datenreplikation bei den anderen Nodes (3) auch der Gültigkeits-Startzeitpunkt der Schreibberechtigung mit dem Zeitstempel verglichen wird sowie die Plausibilität des Zeitstempels überprüft wird.
  22. Verfahren nach Anspruch 20 oder 21, dadurch gekennzeichnet, dass bei der Replikation der Daten vom eigenen Node auf alle anderen Nodes zusätzlich noch die für die Replikation erforderlichen Daten vom eigenen Node mit einer elektronischen Signatur versehen und an alle anderen Nodes gesendet werden und alle anderen Nodes die Signatur nach dem Empfang überprüfen und bei Unrichtigkeit der Signatur die Daten für die Datenreplikation von den anderen Nodes ablehnen.
EP21830917.7A 2020-12-07 2021-12-07 Verfahren zum migrieren einer it-anwendung Pending EP4256455A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ATA51063/2020A AT524620A1 (de) 2020-12-07 2020-12-07 Verfahren zum Migrieren einer IT-Anwendung
PCT/AT2021/060465 WO2022120400A1 (de) 2020-12-07 2021-12-07 Verfahren zum migrieren einer it-anwendung

Publications (1)

Publication Number Publication Date
EP4256455A1 true EP4256455A1 (de) 2023-10-11

Family

ID=79025079

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21830917.7A Pending EP4256455A1 (de) 2020-12-07 2021-12-07 Verfahren zum migrieren einer it-anwendung

Country Status (4)

Country Link
US (1) US20240007276A1 (de)
EP (1) EP4256455A1 (de)
AT (1) AT524620A1 (de)
WO (1) WO2022120400A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117149915B (zh) * 2023-10-31 2024-03-29 湖南三湘银行股份有限公司 用于云端数据库迁移到开源数据库的方法

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020031230A1 (en) * 2000-08-15 2002-03-14 Sweet William B. Method and apparatus for a web-based application service model for security management
WO2006069312A2 (en) * 2004-12-21 2006-06-29 Sandisk Corporation System for creating control structure for versatile content control
US11734169B2 (en) * 2016-07-26 2023-08-22 Pure Storage, Inc. Optimizing spool and memory space management
CA2958668A1 (en) * 2017-02-23 2018-08-23 Scenarex Inc. Methods and apparatus for integrating digital rights management into an existing blockchain
US10503427B2 (en) * 2017-03-10 2019-12-10 Pure Storage, Inc. Synchronously replicating datasets and other managed objects to cloud-based storage systems
US11132451B2 (en) * 2017-08-31 2021-09-28 Parity Technologies Ltd. Secret data access control systems and methods
US11194759B2 (en) * 2018-09-06 2021-12-07 Pure Storage, Inc. Optimizing local data relocation operations of a storage device of a storage system
WO2020231642A1 (en) * 2019-05-15 2020-11-19 Pure Storage, Inc. Cloud-based file services
SG10202012336RA (en) * 2019-12-19 2021-07-29 London Stock Exchange Plc Transaction submission processing over distributed ledger networks
US11868622B2 (en) * 2020-02-25 2024-01-09 Pure Storage, Inc. Application recovery across storage systems

Also Published As

Publication number Publication date
US20240007276A1 (en) 2024-01-04
AT524620A1 (de) 2022-06-15
WO2022120400A1 (de) 2022-06-16

Similar Documents

Publication Publication Date Title
EP3108610B1 (de) Verfarhen und system zum erstellen und zur gültigkeitsprüfung von gerätezertifikaten
DE202018002074U1 (de) System zur sicheren Speicherung von elektronischem Material
EP2899714B1 (de) Gesichertes Bereitstellen eines Schlüssels
EP3552344B1 (de) Bidirektional verkettete blockchainstruktur
DE112021002747T5 (de) Sicheres wiederherstellen von geheimen schlüsseln
EP3422274A1 (de) Verfahren zur konfiguration oder änderung einer konfiguration eines bezahlterminals und/oder zur zuordnung eines bezahlterminals zu einem betreiber
WO2011061061A1 (de) Verfahren und vorrichtung zum zugriff auf dateien eines sicheren fileservers
DE112022000906T5 (de) Trennen von blockchain-daten
WO2022120400A1 (de) Verfahren zum migrieren einer it-anwendung
DE102014210282A1 (de) Erzeugen eines kryptographischen Schlüssels
DE112021005837T5 (de) Dezentrale sendeverschlüsselung und schlüsselerzeugungseinrichtung
EP3629516B1 (de) Dezentralisierte identitätsmanagement-lösung
EP3767513B1 (de) Verfahren zur sicheren durchführung einer fernsignatur sowie sicherheitssystem
EP2491513B1 (de) Verfahren und system zum bereitstellen von edrm-geschützten datenobjekten
DE102013019487A1 (de) Verfahren, Vorrichtungen und System zur Online-Datensicherung
DE10307996A1 (de) Verfahren zum Ver- und Entschlüsseln von Daten durch verschiedene Nutzer
DE102005038106A1 (de) Verfahren zur Absicherung der Authentisierung eines tragbaren Datenträgers gegen ein Lesegerät über einen unsicheren Kommunikationsweg
EP3580908B1 (de) Zugriffsverwaltungssystem zum export von datensätzen
WO1998026537A1 (de) Verfahren zur elektronisch gesicherten speicherung von daten in einer datenbank
EP3627755A1 (de) Verfahren für eine sichere kommunikation in einem kommunikationsnetzwerk mit einer vielzahl von einheiten mit unterschiedlichen sicherheitsniveaus
EP4436097A1 (de) Verfahren und system zur kryptographisch abgesicherten datenübertragung
EP4033694B1 (de) Verfahren und vorrichtung zur vereinheitlichung von blockchain adressen
WO2011147693A1 (de) Verfahren zum bereitstellen von edrm (enterprise digital rights management) geschützten datenobjekten
EP4080847A1 (de) Sicheres verändern von anwendungsdaten in einer blockchain
WO2022063851A1 (de) Server zur abwicklung von transaktionen

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20230707

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: INSITU SOFTWARE GMBH

17Q First examination report despatched

Effective date: 20240625