Patent Application
20240007276
The present invention relates to a method according to the preamble of claim 1.
There are three processing modes to choose from: in the first, there is no concatenation of data, in the second, the data is concatenated in a multi-stage concatenation system, and in the third, only the hash values of the data including data headers are concatenated.
Distributed Ledger Technology (DLT) is the umbrella term for blockchain technologies and various types of direct acyclic graphs (DAG) technologies. In the following, the term blockchain is always used, but concatenation and the ideas of DAGs are also possible. That is, in the patent procedure, no distinction is made between blockchain and DLT. Today, blockchains are backed by implementations such as Bitcoin, Ethereum, etc., so-called blockDAGs are backed by implementations such as Nano or RChain, and TDAGs are backed by implementations such as IOTA or Byteball.
Distributed ledger technology, or better known as blockchain technology, is a technological trend that has the potential to transform quite a few areas of society and large industries such as finance, logistics, healthcare, public sector applications, etc. In blockchains, all processing and storage of data is done on-site in so-called “nodes” and the data is permanently and immutably chained using a cryptographic method.
By moving away from centralized systems, long-term cryptographic chaining of all data, and local processing and storage of data, blockchains often increase trust in the application, IT availability, non-repudiation, and traceability of all processing.
Today's blockchain technologies form an independent, closed “IT world” for which new suitable IT applications are being sought and realized. This is giving rise to entirely new blockchain solutions that fit very well.
Current IT with IT processing in central IT-systems (host-systems) has different goals, a different orientation than today's blockchain technologies. There are considerable differences between the use of blockchain technologies in their environment and the centralized, classic IT world. As a result, the many millions of IT-applications already successfully in use today and processed in centralized IT-systems are not a direct candidate for blockchain technologies. The reasons for this lie primarily in the interfaces and authorization systems, logical access protection (especially read protection), IT security, the deletion option (important for GDPR—general data protection regulations) and memory release.
It is the object of the present invention to create a method with which millions of already existing IT applications from our central, classical IT rooted in everyday business can be extended in a simple manner in such a way that the definition and the goals of blockchains are fulfilled. In doing so, it should be possible to continue using the existing central IT-systems.
This object is attained by a method according to the preamble of claim 1 according to the invention in that a program is integrated into the operating system and/or before and/or in and/or after database system(s) and/or IT applications as middleware, so that the IT application does not have to be changed or only slightly changed, and in that, in accordance with the authorizations and thus the relevant read/write protection, the data or parts thereof are cryptographically encrypted before being written to a nonvolatile data memory and/or database system and/or file system and, after being read from a nonvolatile data memory and/or database system and/or file system, the data or parts thereof are crypto-graphically decrypted.
In addition to the usually central authorization and authorization systems already in place, the overall system primarily contains workstations (PCs, laptops, smart phones, etc.) in the form of full nodes that receive all data, light nodes that receive only the desired data, and service nodes that also perform administration/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. In addition, the existing central IT-system can be fully maintained for all users who wish to continue working as before.
In the following, we refer to an extension of the IT application into a blockchain or at least into a decentralized system. This extension can often happen completely automatically by the middleware if no changes are required in the IT application. In practice, however, an at least minor porting will usually be required, whereby some adjustments are made.
It is useful if the access authorizations to data in database systems (DBMS) and files are stored in a “management blockchain” and this management blockchain is accessible to all nodes, and this management blockchain is created from the data of the authorization systems present in the central IT-system and/or other data from a management unit in service nodes and in nodes this management unit is connected in the middleware to the applications and/or the operating system and/or the database systems and/or the central authorization systems. The existing authorization systems are thus retained. The data of the authorization systems are only additionally mapped on an management blockchain to fulfill the “blockchain requirements” and this management blockchain is sent to all nodes with each change, so that on the one hand each node knows all current data of the authorization systems at all times, even if a central authorization system fails, and on the other hand so that all changes of authorizations are located unchanged in an management blockchain and therefore all processes can be traced later.
The management blockchain may preferably contain different block types in the form of node blocks, namely:
The central authorization and permission systems for delivering current authorizations may be preserved, and the central systems for processing applications for users who wish to continue to work through the central systems may also be preserved while acting as their own nodes. Because 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. No concatenation of data occurs in central systems. As before, central systems directly process users' applications and store the data. Central IT-systems are also called host systems and are often located in a cloud.
An essential point is data security. With a centralized IT-system, one can easily prevent unauthorized access by having the central IT-system not give out the requested information to unauthorized users. In a blockchain, however, the entire data is present at each full node, and one cannot prevent a savvy user from accessing this data by bypassing the database software (DBMS—data base management system), since he usually has administrator rights on his computer. Since local users on the nodes can thus usually gain sovereignty over all data, i.e. they have all administrative rights, the existing central authorization systems and logical access control systems (especially read and write protection) can no longer guarantee the necessary protection of the data, since they can be bypassed relatively easily. This protection is therefore solved with the help of suitable encryption and decryption of the data, i.e. with the help of a cryptographic access control system (logical access control system based on cryptography). Because only the authorized nodes know the required cryptographic keys, all nodes can read all data, but they can no longer understand it (for this, a suitable decryption is required).
For secure traceability of processing, the data required for this can be concatenated to form a data blockchain. While this ensures traceability of processing, it has the consequence that data can no longer be deleted without destroying the integrity of the data blockchain.
For this reason, according to a further feature of the invention, it is provided that data can be made unreadable by deleting the key in all nodes despite the concatenation of the data blocks. Thus, despite the concatenation of the data blocks, the data can be made unreadable by deleting the associated key in all nodes, if necessary. “Erasure” in the sense of the GDPR (General Data Protection Regulation), which must be possible for personal data, for example, is understood to mean not only the complete destruction of this information, but also making it unreadable, by destroying the key required for decryption. Since it is in the nature of a blockchain that data cannot be deleted without destroying the concatenation, these features create a solution to still comply with the GDPR.
To increase security, it can be provided that for cryptographic encryption and decryption and computation of electronic signatures only quantum computer secure cryptographic algorithms are used, gitter-based and/or code-based and/or hash-based and/or multivariant cryptography and/or cryptography based on supersingular isogenic curves and/or for symmetric encryption the AES algorithm (Advanced Encryption Standard).
According to one embodiment of the invention, when encrypting data for database systems, 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.
Because a node can always write or modify all data at itself, the write protection must contain a further protection in addition to the encryption of the data, in that the other nodes only accept a write operation of a node in their data inventory including blockchain after they have positively checked the write authorization of this node. Thus, if an unauthorized node modifies data, this only affects it locally, but not the entire blockchain or databases or files that is/are distributed decentrally among many nodes.
In another embodiment of the invention, multiple data fields of rows of tables of databases and/or entire rows/columns of tables that have the same encryption/decryption key are combined into a single data field. During encryption and decryption, only this combined data field is then used. Within this combined data field, all individual data fields with different data types are converted to a dense format, i.e. without gaps, before encryption and converted back to the original format after decryption. This saves computing time and storage space.
Because the data fields of rows of tables of databases represent certain types of data and lengths (integers, floating-point numbers, dates, strings), it is convenient if the encryption and decryption of the data preserve the format of the data fields and the length. Similarly, specifications, such as a valid date specification, should be satisfied even after encryption so that they are accepted and properly processed in the database system without the need to modify the database system in this regard. For this purpose, in one embodiment of the invention format-preserving-encryption (FPE) is used so that the data type and length are preserved and date specifications remain valid specifications even after encryption. For this purpose, e.g. FF1 or FF3 according to NIST Special Publication 800-38G (Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption) can be used.
If a data type does not allow a complete conversion to an interval 0 to 2n−1, as is the case for floating point numbers or the time (a time represented in hours, minutes and seconds can be densely mapped to an interval from 0 to 86,399, but 86,399 does not represent a power of two−1), encryption is performed as often as necessary until the result is within the desired interval. For the data type time (mostly called TIME in database systems) this means that after the conversion there is a 17-bit long number which is encrypted and afterward there can be a result between 0 and 131,071. If the value after encryption is greater than 86,399, encryption must be performed again, and so on, until the interval 0 to 86,399 is met.
Since keys are known to need to be changed repeatedly, according to a further embodiment of the invention, it is provided that in each node, all older calculations of the read key can be calculated from the current cryptographic read key by asymmetric quantum computer-secure decryption, and new key calculation can be calculated in service nodes or hardware tokens as part of the service node by asymmetric quantum computer-secure encryption. In this way, anyone who has the current read key can decrypt all previously encrypted data, but anyone who does not get a newly calculated key cannot read the data encrypted with the new key.
Preferably, the cryptographic concatenation of the data blocks is separated into a multi-level concatenation system, and at the lowest level no concatenation takes place and this is only valid for the node, and further at the middle level a temporary concatenation takes place and this is only valid for the node, and wherein finally at the upper level with validity in the entire system a final concatenation takes place, whereby the lowest and/or middle level and/or upper level can also be omitted, so that thereby during the processing in the node and before the distribution to all other nodes still memory can be released and storage space can be saved. Instead of data, of database commands or files, only the hash values thereof including header data may also be concatenated.
According to a further embodiment of the invention, it is provided that in at least one data field the possible values are divided into classes, preferably with a class width of 2n, and that an encryption or decryption is carried out as often as necessary until, after the encryption or decryption, the value is again in the given class, so that even after the encryption the values of all the individual elements of a class are greater than or less than the values of all the individual elements of a class, so that thereby the conditions < and > and ≤ and ≥ are preserved despite encryption, whereby the bit length of the individual elements of an interval is always oriented to the required bit length of the largest value of the interval.
In this way, it is possible to execute database commands with where conditions (<, >, ≤, ≥) on the encrypted data, because the where conditions <, >, ≤ and ≥ are satisfied after encryption exactly when they were satisfied before. This can save considerable computing time. The encryption or decryption is performed as often as necessary until the specified interval is again met after the encryption or decryption. All values of an interval “a to b” are larger than all encrypted values of an interval “c to d” even after encryption, if a>d applies. Thus, the conditions <, >, ≤ and ≥ are preserved despite encryption. The bit lengths of the values in the two intervals can be different, e.g. the values of the interval “c to d” can be smaller than those of the interval “a to b”. One will always choose the smallest possible value in order to minimize the encryption/decryption operations.
In the migration provided according to the invention, the central authorization systems for delivering the current authorizations can be retained and/or the central systems for processing applications for users can also be retained and thereby act as their own nodes, whereby the data encrypted in the nodes is used unencrypted in the central systems and therefore the data is suitably decrypted before being transferred to a central system and suitably encrypted after leaving the central system.
According to one embodiment of the invention, in order to increase security, it is provided that the middleware includes an IT security system and that this IT security system specifies the security requirements and/or cryptographic procedures of each individual node, checks them in all nodes and reports deviations to the other nodes.
The calculation 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, depending on the level of security, whereby, if required, the IT security system always checks the level of security in the node and reports deviations to all other nodes.
To achieve the necessary asynchrony and transaction speed for cryptographic chaining in the data blockchain and or the management blockchain, a direct-acyclic graph can be used.
Symmetric and asymmetric methods can be used for the encryption and decryption of the data. When using symmetric methods, in one embodiment of the invention the cryptographic keys are derived from so-called root keys by cryptographic methods or hash methods, such as the SHA-2 and SHA-3. For the calculation of the root key with initial value “x”, n nodes are selected at the beginning, called main nodes in the following, where each of these n main nodes determines its own root key-part as a random number. For the calculation of a root key, a commutative asymmetric encryption method is used, such as the Diffie-Hellman method (ECDH with elliptic curves or the quantum computer-secure CSIDH method Com-mutative Supersingular Isogeny Dife-Hellman).
The root key is calculated as follows: First, the start value “x” is encrypted in a main node with this encryption method and the own root key-part as key, then the result is sent step by step to all other main nodes and there the current result is encrypted again in the individual main nodes with the respective root key-part until an encryption with the respective own root key-part has taken place in all main nodes. 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 different order of the main nodes, so that each main node carries out the last encryption once and thus receives the result.
For the encrypted transmission of the root key to another (new) node, this new node also determines its own root key-part as a random number. Subsequently, the start value “x” is encrypted in the new node using this encryption method and its own root key-part as key. The result is then sent step by step to all main nodes, where the current result is encrypted again in the individual main nodes using the respective root key part until all main nodes have been encrypted using their own root key part. Finally, the result is sent to the new node and decrypted there with its own root key-part. This last result now gives the desired root key. The root key is thus calculated from the encryption of the value of “x” with all root key-parts of the n main nodes. This calculation always gives the same result for a given root key. Because the root key-part of a new node is a random number, each new root key calculation always starts with a different root key-part and therefore all intermediate results are always different for each new root key calculation, which is important for security reasons. Likewise, 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 root key-parts should be located exclusively in these high-security hardware tokens, which is the case in one embodiment of the invention. In another embodiment of the invention, the result of the encryption is also electronically signed in the hardware token of each node and the signature is sent to the next node. All hardware tokens of the main nodes or replacement nodes and of the new node then check this signature before their encryption process and only perform the encryption if the result is positive. This guarantees that all encryption for root key computation is done only in hardware tokens.
For each of these n main nodes, substitute nodes are also selected and these receive their root key-part in encrypted form from the main nodes respectively. Therefore, there is at least one substitute node for each main node.
Finally, according to one embodiment of the invention, it is provided that the read database commands and/or file commands are checked with respect to the read authorization of the relevant user or role or other relevant subject, and that the write database commands and/or file commands are checked with respect to the write authorization of the relevant user or role or other relevant subject are checked by the own node and, in the case of data replication to all other nodes, are checked by the other nodes with the aid of the management unit according to the management blockchain and, if valid, are forwarded to the relevant database system or file system.
In this context, it is expedient if, during data replication at the other nodes, the validity start time of the write authorization is also compared with the time stamp, and the plausibility of the time stamp is checked, and the read and write commands are forwarded to the responsible database system or file system only in the positive case.
Finally, it is also possible to provide that when replicating the data from its own node to all other nodes, the data required for replication is additionally provided with an electronic signature by its own node and sent to all other nodes, and all other nodes check the signature after receiving it and reject the data for data replication from the other nodes if the signature is incorrect.
Thus, according to the present invention, there are provided:
Migration of an IT application of a central system (host system) to a decentralized IT application running on one or more nodes is performed by suitably integrating the method according to the invention as new middleware into the operating systems, database systems and, if required, IT applications used.
In the following, the parts of the method according to the invention are briefly described:
1. Access Control System
In IT systems commonly used today, where the processing of applications and data takes place in central systems (host systems), there are sophisticated authorization systems in the database systems, operating systems and special authorization systems. These authorization systems guarantee the desired access protection to the data, so that only authorized users of the system are granted access.
If today's IT applications are distributed from a central system to many simple nodes, the logical access protection to the data by the operating system, database system and the applications is omitted in the node. On site at the nodes, the owner/user of the node can have complete sovereignty over his system. He can therefore also set the access permissions to the data stored in his system as he wishes at any time. On this basis, it is not possible to implement and guarantee authorizations such as read and write access to data.
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 exclusively by data encryption. The cryptographic keys are calculated in so-called service nodes that are special nodes for security and administrative tasks, or hardware tokens in accordance with ISO/IEC-7816 (EAL4+ certified), which are e.g. highly secure smart cards such as those used today in bank cards, passports or SIM cards, and the cryptographic keys are distributed from there to all nodes in a highly secure (if possible quantum computer secure) encrypted form.
2. Write Protection System
Every write operation, i.e., every change or addition to data, is performed by data encryption where possible and permitted. This encryption also allows read protection (see above). However, since each node can overwrite existing data—and in the case of a full node this means all data—at any time, write protection requires an additional protection mechanism. Every write operation at a node, especially in files or databases, must be communicated to every other node via the communication system as part of the data replication process, so that the data is the same in all nodes. This is done by each node providing the data required for 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 the electronic signature method of this purpose. The nodes that receive the data required for replication, including the signature, verify 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 blockchain, they transfer the received data in an appropriate form to their data pool (file or database) at the correct locations, otherwise the received data block is rejected.
3. Security Management
A sensitive area of blockchains and decentralized systems with simple nodes is IT security. It is much easier to adequately secure and audit the IT security of a central system (host system) than hundreds or thousands of simple nodes. However, if the IT applications and data storage are handled entirely 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 guarantee sufficient IT security even on decentralized workstations/user nodes. For example, it is determined here whether the data is encrypted symmetrically or asymmetrically, which cryptographic procedure and key management is used, where on-site in the node the key management and data encryption/data decryption takes place, and what general IT security requirements are placed on the node. Sensitive parts of the procedure 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 procedure includes a security control system that is used on all nodes and, as far as possible, automatically controls the security on site and reports deviations to the other nodes.
4. Cryptographic Data Chaining System
Another important component is the cryptographic concatenation of data in the file and database systems. The challenge here is not the cryptographically secure concatenation itself, but the economical use of memory. Concatenation prevents memory from being freed, but this happens all the time in file systems and databases. Therefore, special mechanisms must be used that lead to economical use of data storage despite chaining, even in existing file and database systems without modification.
5. Management Blockchain
An important task in today's central IT applications is performed by the so-called authorization systems such as RMS (Microsoft Rights Management System), Active Directory, etc. and the authorization systems integrated in the individual database and operating systems as well as IT applications. In most central IT systems, several authorization systems are active in parallel, and the individual IT applications usually obtain the authorizations and roles of the individual users completely or partially from these systems as needed.
In contrast, 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 by entering the authorizations in full or in part directly in service nodes and immediately writing all changes to the management blockchain. The data itself is thereby subdivided into blocks. Such a block can be, for example, a role with all associated subroles, users, user groups and objects (such as file directories or databases or tables, rows, columns, etc. of databases). After an end-valid chaining of a block, each node can check, based on the management blockchain, whether an authorized person has created and chained this block.
That is, in the method according to the invention, in addition to the data blockchain, where previous data of the central system can be concatenated in each node but, depending on the processing mode, do not have to be, there is another blockchain, the so-called management blockchain, which is necessary, among other things, to combine classical authorization systems and then make them 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 required certificates of the nodes (a certificate contains the public key of an asymmetric cryptography and the associated name of the “owner”), parameter blocks with all parameters for key management and for encryption/decryption of the data and for data conversion and for root key calculation.
This management blockchain supplies the individual nodes with the required permissions and other data (such as certificates, parameters, etc.), increases availability, and serves as a logging of the sensitive area of permissions.
6. Synchronization and Replication of all Databases and Files in all Nodes
Today's database systems are often not capable of all nodes being database servers at the same time if desired, but this is required in a decentralized system such as in the present object of the invention, and the required access protection in the completely open nodes cannot be implemented either. This requires suitable replication and synchronization of all databases in all nodes. With database replication and synchronization, data is automatically exchanged between all nodes in such a way that all databases in all nodes have the same information status. The result is a distributed database in all nodes. The same applies to file systems.
In the accompanying figures, the principle of the present invention is shown schematically. It shows:
The principle of a blockchain is evident from
In
In
As explained above, a central aspect of the present invention is the encryption 9 of the data and the decryption 10 of the data. This is done with the aid of cryptographic keys 12 provided by the management unit 18′. The encrypted data is transferred from the database system 5 or the file system 8 to the decryption unit 10 and from there in clear text to the application 1 is transmitted. Conversely, data coming in plain text from the application 1 is transmitted for encryption 9 and then fed in encrypted form to the database system 5 or the file system 8 and transmitted to the other nodes for data replication via the network 13. Before this, however, a check is made in the system 17 to verify the write authorization, whether this node is authorized to write this data. If this is the case, then in addition to the appropriate transfer 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 blockchain 2 if the processing mode provides for chaining.
| Number | Date | Country | Kind |
|---|---|---|---|
| A51063/2020 | Jul 2020 | AU | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/AT2021/060465 | 12/7/2021 | WO |
