METHOD FOR GENERATING DIGITAL SIGNATURES

Description

[0001] The present invention concerns the use and further development of the secure storage of digital assets and the secure implementation of electronic signature processes. The present invention particularly relates to the storage of cryptocurrencies and tokens, i.e., the storage of access authorization for entries in a public or private database (particularly in transaction systems such as blockchain), where each entry is exclusive, unique, non-replicable, and fundamentally not forgeable. Such access authorizations are implemented, in particular, through the use of asymmetric cryptographic methods, which generally consist of a private / public key pair.To transfer authorization to a token in such a database (such as the blockchain), a transaction is initiated by creating a transaction script according to the respective software protocol of the database / blockchain. This transaction script is then provided with a digital signature using the private key and then sent to the database, i.e., usually the blockchain network. The validity of the digital signature or the transaction or the interaction (change of state, e.g., of a smart contract) can be verified using the public key publicly accessible in the database / blockchain.If the digital signature is valid, the token is usually transferred to another public key and from then on, the person (or the software used for this purpose) who is in possession of the corresponding private key can use this token.

[0002] The first implementation of a blockchain was that of the "cryptographic" currency "Bitcoin." This system essentially consists of a payment system and a form of "monetary unit" that is created and managed decentrally using proprietary software. Anyone with internet access can become part of the Bitcoin network with their own computer. The decentralized database used (the blockchain) stores all transactions and is publicly accessible to everyone. It is also designed to be tamper-proof using cryptographic procedures. The resulting transparency allows the application of blockchain technology for other forms of digital registers, for example, in the public sector for publicly maintained registers such as the commercial register. Of particular interest is tokenization, in which rights or claims are embodied in tokens instead of documents (e.g.,in the Ethereum blockchain). The present invention particularly relates to the storage of access authorization for such tokens or "cryptographic" currencies such as Bitcoin and can be used for all similarly implemented systems in which a private key is used for signature.

[0003] Such systems are often called wallets (virtual purses), which manage (usually various) private / public key pairs and serve to securely store the private keys and perform other functions such as selecting the appropriate public keys for a transaction if the transaction cannot be carried out with a public key alone and preparing the transaction scripts, for example.

[0004] Such wallet systems are generally differentiated between cold wallet and hot wallet systems. Cold wallet systems refer to solutions in which the private key is stored in a location or on a device that is not connected to the Internet ("air gap"). The advantage of these solutions is increased security, for example, against attacks (hacker attacks) or misconfigurations that allow unauthorized access to the stored private keys. The disadvantage of these systems is the manual effort required to digitally sign a transaction, for example, which is why end-to-end process automation is not possible and a media disruption occurs: Typically, a human must apply the private key to the character string to be digitally signed (usually the transaction script). This makes it impractical for industrial users, such asExchanges / trading platforms for tokens and / or cryptocurrencies, or companies that hold such private keys on behalf of their customers (called custodians), use a separate public / private key pair for each individual customer. Instead, the tokens are stored in "collective wallets" (which ultimately "combine" the tokens of various customers for financial purposes), in which the companies store the tokens of numerous customers in a private / public key pair. Due to the fact that most blockchain solutions are public blockchains, public keys with a large number of tokens / cryptocurrencies can be easily discovered. This not only makes them a worthwhile target for attackers, but also has at least two other serious disadvantages: 1. If large, i.e., larger-than-usual, transactions are carried out, this can lead to speculation and short-term disruptions on the trading platforms. Because the transaction is not distributed among multiple public keys (and thus not accessible to outsiders), cases of embezzlement or undisclosed successful theft by hackers, for example, cannot be detected promptly or at all. Recently, the insolvency of the Canadian crypto exchange QuadrigaCX made headlines, with the insolvency administrator Ernst & Young concluding that QuadrigaCX's cold wallets were empty. 3.Another problem with cold wallets is that before a transaction can be created, the cold wallet must first be synchronized. The cold wallet's software needs to have the most up-to-date information from the respective blockchain to determine the appropriate public keys for a transaction. This takes additional time before a transaction can actually be executed and poses a security risk, as the cold wallet must be connected to the internet until synchronization is complete and the transaction is sent.

[0005] Hot wallets, on the other hand, are wallets where the private key is stored on a device connected to the internet. These wallets solve the media disruption problem and allow transactions to be executed almost immediately, as the private key for creating the digital signature (or other interaction) can be accessed automatically. These wallets have the disadvantage of being significantly more vulnerable to hackers or to misconfigurations or implementation errors in the hot wallet software. In industrial applications, such as crypto exchanges, these hot wallets are also operated as collective wallets, meaning that the individual customer cannot guarantee that the total amount of tokens stored in these wallets corresponds to the amount that the crypto exchange should hold according to all of its customers.

[0006] Various approaches for such wallets or for storing private / public pairs are described, for example, in the following prior art documents: METHOD OF MAKING, SECURING, AND USING ACRYPTOCURRENCY WALLET, United States Patent Application Publication, Pub. No.: US 2015 / 0227897 A1 Richard Kennard, Robert Steele: "Application of Software Mining to Automatic User Interface Generation"; DATA ANALYTIC AND SECURITY MECHANISM FOR IMPLEMENTING A HOT WALLET SERVICE, United States Patent, Patent No.: US 9,672,499 B2; and METHOD AND SYSTEM FOR SECURING CRYPTOCURRENCY WALLET, Patent Application Publication, Pub. No.: US 2016 / 0071096 A1.

[0007] US 2005 / 0182956 A1 outlines that documents and other items can be delivered electronically from sender to recipient with a level of trust approaching or even exceeding that of a personal document courier. A trusted electronic intermediary can validate, attest, and / or archive transactions while, in some cases, actively participating in or directing the transaction. Printed or imaged documents can be marked with handwritten signatures, seal images, electronic fingerprints, watermarks, and / or steganography. Electronic commercial transactions and transmissions take place in a reliable, "trusted" virtual distribution environment, providing users with significant efficiency and cost-saving benefits and also conveying an extremely high level of trust and trustworthiness.The systems and technologies can be used for a wide range of purposes, including the secure delivery of documents, the preparation of legal documents, and electronic data interchange (EDI). METHOD AND SYSTEM FOR SECURING CRYPTOCURRENCY WALLET, Patent Application Publication, Pub. No.: US 2016 / 0071096 A1.

[0008] The present invention is intended to solve the problem that the private key must be securely stored on a device that has no internet connection. This system is arbitrarily scalable, meaning any number of private / public key pairs can be stored (meaning there is no longer any need for collective wallets), yet a fully automated process is still possible, allowing transactions to be signed at a speed comparable to that of hot wallets. Furthermore, the invention solves the problem that before a transaction can be signed with a "cold wallet," the structure of the transaction and the associated public keys are automatically and correctly generated. This is done by keeping the most current (blockchain) data, which must first be synchronized with conventional cold wallets, always up-to-date within the wallet system.

[0009] An object of the invention is therefore to provide a method which allows the storage of the private keys on storage locations not connected to the Internet, but which nevertheless makes these private keys accessible for the creation of a digital signature in a fully automated process.

[0010] A particular object of the present invention is to provide such a method which makes it possible to store any number of private / public key pairs in such a way that the private key is stored on devices which are not connected to the Internet.

[0011] A further object of the invention is to provide such a method which enables communication between a user interface or programming interface (application programming interface; API) accessible via the Internet (or a comparable at least partially public network = not completely private network), via which the user initiates a transaction (e.g. a customer of a trading venue wants to send a token), enters a character string to be provided with a digital signature (e.g. a transaction script) into a queue, database or transmits it via another interface, which can be accessed by software located in a secure environment such as a demilitarized zone (DMZ), and this software also enters a queue, database or has access to a completely private network via another interface and transmits the existing orders into it.The data is encrypted in such a way that it can only be decrypted within the private network.

[0012] A further object of the invention is to provide such a method which automatically starts an isolated and inactive mode encapsulated environment, e.g. a virtual machine (VM), which has no internet connection, which is able to create a digital signature using a private key and transfer the signature to other software, to be started in cases where said software contains the necessary private key or can access it. This environment is located in a private network without internet connection. Within this environment, a software system takes control of starting and stopping the encapsulated systems and can execute commands within this environment.

[0013] A further object of the invention is to provide such a method which automates an isolated and inactive mode encapsulated environment, e.g. a virtual machine (VM), which is only activated when needed to prepare a transaction. Furthermore, these encapsulated environments are provided with a local copy (ideally via a VM which holds the local data and is located on the same storage system as the VM to be woken up) of the respective (blockchain) protocol data records in order to make time-consuming synchronization unnecessary. Via this encapsulated environment, a software system assumes control of starting and stopping the encapsulated systems and can execute commands within this encapsulated environment.

[0014] A further object of the invention is to provide a method whereby software on a system hosting a queue system / database server / interface and located within the private network establishes a VPN connection to a system within the DMZ, so that the system within the DMZ can use this connection to check for digital signature requests and retrieve responses (in particular, signed transactions) from the system. This system within the DMZ can communicate with another database located on the open side (i.e., the non-private network) and can also transmit pending requests and responses there.

[0015] A further object of the invention is to provide a method such that data which is transmitted from the open side (i.e. the non-private network) to the private network is encrypted with an internally used public key, such that this data can only be decrypted again on the intended virtual machine using an internal private key stored there.

[0016] A further object of the invention is to provide a method such that the private key required for the digital signature is stored on an encapsulated system and is encrypted with an individual password of the authorized person on this wallet as a (partial) key.

[0017] A further object of the invention is to ensure the verifiability of the token holdings by third parties from inside and outside by storing the public / private keys in segregated and separate environments and protecting them by individual authorization mechanisms.

[0018] A further object of the invention is to provide a method variant in which the private key required for the digital signature is stored on an encapsulated system and encrypted with a key (referred to as a "master file" according to the invention), which in turn is encrypted with an individual password of the authorized user's wallet as a (partial) key. This allows the encryption of various private keys for different protocols (e.g., Bitcoin, Bitcoin Cash, Ethereum, etc.) with a uniform "master file," whereby in the event of a password change, only this "master file" needs to be re-encrypted with the changed password, not all private keys of the individual wallets belonging to different (blockchain) protocols.

[0019] The technology underlying the invention is based on eliminating the existing disadvantages by combining the features of a cold wallet (private keys not on an active logical system and without an internet connection on this logical system), particularly with regard to security, with the advantages of a hot wallet in terms of process automation and thus the speed with which digital signatures can be created.

[0020] Furthermore, the underlying technology is based on eliminating the existing disadvantage that the civilly entitled token holders usually have to trust the wallet operator (crypto exchange, custodian, etc.) that their tokens are actually still in the operator's wallet and that the operator will release these tokens (or whatever function may be associated with the corresponding private key by signing) upon request or that the desired action will be carried out. To this end, the invention enables the segregated storage of any number of public / private key pairs of different (blockchain) protocols, thus enabling the authorized holder to verify these themselves in the respective blockchain, independently of the operator.

[0021] Furthermore, the underlying technology is based on eliminating the existing disadvantages that wallet operators or their employees are able to use their tokens or private keys without the involvement of the legally entitled party and, for example, embezzle their Bitcoin, by making a part known only to the customer (or a third party entrusted by the customer) part of the key that is ultimately necessary to decrypt the private key.

[0022] In addition, the underlying technology is based on the fact that, despite the existence of segregated private / public key pairs per civil-law beneficiary and the existence of segregated environments - specifically encapsulated as virtual machines - the resource consumption is minimized by the only on-demand activation of these virtual machines.

[0023] The invention includes a process for generating digital signatures with the wallet according to the invention and an associated process for creating such a wallet according to the invention and the wallet system.

[0024] As a result, the technology according to the invention eliminates the practical limitations existing for cold wallet solutions regarding the number of different private / public key pairs (particularly in mass customer business), as well as the media disruption caused by the need for manual human intervention. It thus allows the storage of large quantities of private / public key pairs in a secure cold storage environment in segregated networks, without the security deficits typical of hot wallet solutions. Furthermore, in its preferred embodiment, the technology according to the invention allows the private key of a wallet to be encrypted with a partial key known only to the authorized user or a third party designated by the authorized user, in order to also deny the provider of the wallet solution access to the private key required to generate the digital signature without this partial key.In conjunction with the private / public key segregated for each wallet authorised user, the invention thus allows a few cases of, for example, embezzlement by the wallet service provider to be prevented and the wallet authorised user to verify his tokens, crypto currencies, etc. attributable to him at any time, independently of the service provider.

[0025] The preferred embodiment of the process (100) includes the following main components: A not private Computer network (e.g. servers connected to the Internet that provide a user or programming interface over the Internet) A non-publicComputer network, i.e. a computer network that is separate from non-private networks such as the Internet. A demilitarized zone (DMZ), i.e. a computer network with security-controlled access options to the systems connected to it. The systems set up in the DMZ are shielded from other networks (e.g. the Internet, LAN) by one or more security systems (such as firewalls, VLANs, etc.) (isolation of the DMZ system from two or more networks). Extended definition of "non-public network" (NÖN): In contrast to a public network, NÖN is to be understood as a network of various private networks. A NÖN is to be understood as a separation between purely public networks and completely isolated networks, because demilitarized zones (DMZ), VPN networks and other, precisely non-public networks can also be understood as part of the NÖN.Extended definition of "Non-Private Network" (NPN): An NPN, in contrast to a NÖN, distinguishes the interface components of a system network, which overlap and may enable a connection from the outside to the inside. An example of this, and relevant for the patent application, would be that the DMZ receives data / messages / information from the non-private network and forwards it to the non-public network and its interconnection. A software package located in a . non-private Network, according to the invention "Front End / API" called a internal private-public-key pair used within the system according to the invention, according to the invention "internal public key" and "internal private key" called a private-public-key pair, which is used for external transactions, according to the invention "external public key" and "external private key" called (e.g. private / public key pair of the bitcoin blockchain) A character string not known within the system according to the invention (ie in particular not stored there), which for each transaction is provided by a source outside of the system according to the invention should be provided, according to the invention "Master Password" An interface within the non-private network (in this embodiment a database system) according to the invention "Front -side database". An interface which "internal public key" of the "front-end / API" software. An encapsulated system (e.g. a virtual machine / container) on which the software necessary to create the transaction to be signed is located, according to the invention "Online Wallet" A software - according to the invention "Public Wallet Controller" - which can activate and deactivate the encapsulated "Online Wallet" systems and access these "On-lineWallet" commands and which can access the "front-side database" (in the preferred embodiment by regularly querying the database). An encapsulated system (e.g. a virtual machine / container) located within the non-public network - according to the invention "Offline Wallet" called - and on which the software and data are located which are necessary to ∘ decrypt data which is encrypted with the "internal public key" ∘ decrypt the key with the help of the "master password" (its hash value) (according to the invention "Master file" called) with which the external private keys are encrypted. ∘ To decrypt the external private keys with the master file ∘ To generate the digital signatures with the external private keys. An interface within the non-public network (in this embodiment, a database system) according to the invention "Back -side Database"A software - according to the invention "Private Wallet Controller" called - which can activate and deactivate the encapsulated "Offline Wallet" systems and can execute "Offline Wallet" commands on these and which can access the "Back-side Database" (in the preferred embodiment by regularly querying the database) A software - according to the invention "DMZ Controller" - which is located in an environment secured with common security precautions (firewalls, intrusion detection systems, etc.) (demilitarized zone), which can access the "front-side database" (in the preferred embodiment by regularly querying the database) and to which a VPN connection is established from the "back-side database" system, enabling the "DMZ Controller" to also access the "back-side database" and thus acts as a bridge.

[0026] In a preferred embodiment, the essential competencies of which are listed above, the "external private keys", for example private keys for various (usually blockchain) protocols (e.g. bitcoin, bitcoin cash, other hard / soft forks, clones, or extensions of the Bitcoin blockchain, etc.) are stored on encapsulated systems (e.g. as a virtual machine / container in the preferred embodiment) on a distributed system / cluster system (other distributed systems or decentralized systems are also possible to use according to the invention) with a connection to a storage cluster (e.g. a network attached storage; NAS or cloud storage), which ensures scalability of the system.

[0027] The "external private keys" are stored encrypted on these virtual machines in such a way that an individual "master file" is used for each protocol (e.g., Bitcoin, Bitcoin Cash, etc.), with which the respective "external private key" for the respective protocol is encrypted. The "master file" is itself also encrypted, with the hash value of the "master password" serving as the (partial) key. This embodiment – ​​which requires input from outside the system, the so-called "master password" – also makes it impossible for the operator of the inventive system to decrypt the "master file" or the "external private key" without this input and thus create digital signatures with the "external private keys," thus providing protection, for example, against criminally acting employees.The use of a "master file" which is encrypted, among other things, with the hash value of the "master password", increases the security of the key used to encrypt the "external private key" and increases the efficiency of the system in that if the "master password" is changed, only the "master files" have to be re-encrypted, but not each of the "external private keys". In addition, there is the security advantage that the length of the actual decryption string (and thus the difficulty of determining it) is ensured even with weak "master passwords", e.g. short or easily guessed.

[0028] A first exemplary embodimentThe method according to the invention relates to the storage of cryptographic currencies or tokens on a trading platform for digital assets (crypto exchange or custodian) to which an end user accesses a web server via the Internet using an encrypted connection and accesses a protected (at least one, preferably two or more factor authentication) area and can view his holdings of digital assets and the associated public keys (which only belong to this customer) there and can thus verify the holdings of tokens contained therein, e.g. his Bitcoin, via the public blockchain itself and thus independently of the trading platform.

[0029] In this embodiment, when the user wishes to execute any type of transaction with these tokens stored on the trading platform (e.g., a "withdrawal" or an interaction with smart contracts such as participating in a voting process), a connection is established from the web server (accessed by the end user) to a logically separated system, the "front-end / API," and a request is directed to this system (a separation is preferred from a security perspective but not necessarily required for the invention; however, it represents the preferred embodiment). The "front-end / API" then provides the web server—in addition to other data—with a key, which the web server must use to encrypt the data for further communication (according to the invention). "random seed" After the end user has entered their "master password" in this embodiment, a hash value is calculated from it and encrypted with the "random seed" on the client side (client-side in the browser) before being transmitted to the web server and from there sent to the "front-end / API" system.

[0030] On the front-end / API system, the hash value of the master password encrypted with the random seed is decrypted. The master password and the transaction request, including the associated data, are then encrypted directly with the internal public key. The encrypted hash value of the master password is then checked against the front-end database for a match (more precisely, its hash values). If a match is found, the data encrypted with the internal public key is written to the front-end database.

[0031] The "Public Wallet Controller" regularly checks the "Front-Side Database" to see if there are any new transactions to be processed. If this is the case, the corresponding virtual machine ("Online Wallet") is started and the wallet software is synchronized via a local copy of the respective blockchain, also operated as a virtual machine (the "Public Wallet Controller" can also synchronize the respective wallets independently of specific signing requests, provided this function is activated). Without wallet states being constantly kept synchronized in this way, it would often be impossible to put together the specific transaction. For example, in the case of a Bitcoin transaction, it would not be known how it should be put together, as the balances of the public keys involved are unknown or cannot be determined.would be out of date, which would later lead to rejection (due to double-spending or other validation reasons) within the (blockchain) protocol network (in this example, the Bitcoin network). The data to be signed (e.g., a transaction script) is then created on this virtual machine, with the "Public Wallet Controller" executing the necessary commands on this virtual machine (e.g., via SSH or remote access, etc.). The data to be signed is then transferred to the "front-side database."

[0032] This database ("front-side database") is regularly queried for pending orders by the "DMZ Controller," which, as the name suggests, is located within a DMZ. If an order is present in the "front-side database," the "DMZ Controller" transfers the order data to a database in the private network ("back-side database"). In the preferred embodiment, the necessary communication link between the private network and the "DMZ Controller" from the private network established in the form of a VPN connection (connections from the private network to the DMZ can only be established from the private network via VPN - or other secure communication channel such as a dedicated line etc. - access to a system in the private network from the DMZ is not permitted in the preferred embodiment).

[0033] Within the private network, a software program called the "Private Wallet Controller" checks whether there are any orders to be signed in the database located in the private network (in other embodiments, other systems for storing orders are also possible instead of a database). If this is the case, i.e., if there are any unprocessed orders, the "Private Wallet Controller" transfers this request to its memory and starts the encapsulated system belonging to the respective wallet / customer, in the preferred embodiment, a virtual machine in hibernation mode. These are different virtual machines or containers that were started at the beginning of the process by the "Public Wallet Controller" on the "hot" side of the overall system to create the unsigned transaction data.

[0034] This implementation with virtual machines reduces resource consumption and energy requirements by only starting the encapsulated systems when they are actually needed. At the same time, this implementation allows for fast access, as only the state of the encapsulated environment needs to be loaded into the volatile memory (RAM). Once the encapsulated environment is active, the data for the respective order (usually the transaction script and the master password, both encrypted with the internal public key) is decrypted after transmission. In a first step, the master password is decrypted on the virtual machine using the internal private key associated with this wallet. In a second step, the master file is decrypted using the master password. In a third step, the external private key associated with the intended transaction (e.g.,in the case of a Bitcoin transaction, the Bitcoin private key) is decrypted and the "Private Wallet Controller" executes the necessary commands (via SSH, other execution variants are also possible) on the virtual machine to add the necessary digital signature to the transaction script (according to the respective protocol, e.g. from the Bitcoin blockchain).

[0035] The successfully digitally signed transaction is transferred from the "Private Wallet Controller" back to the database ("Backside Database") in the private network. The encapsulated environment is hibernated after the transaction is completed, after a timeout, or due to other resource-related logic. If a signed transaction is present in the "Backside Database," the "DMZ Controller" reads it from the "Backside Database" and transfers it back to the database located on the non-private network ("Frontside Database").The "Public Wallet Controller" also checks the "front-side database" for a successfully signed transaction and, if one exists, starts the associated virtual machine and transmits the transaction to it (or to a dedicated transaction broadcasting service). Here, too, it executes the necessary commands (locally or remotely, e.g., via SSH / console) to broadcast the transaction to the respective blockchain protocol network (e.g., the Bitcoin network) via the software running on the virtual machine. Once this is complete, or a timeout occurs, the virtual machine is put into hibernation.

[0036] In the preferred embodiment, the (temporally) upstream sub-process (200) of creating the segregated wallet environment is also fully automated. This sub-process begins with the request to create a new segregated wallet environment being written to the front-side database by the "front-end / API." The "DMZ Controller" transfers this request to the back-side database, analogous to the process for performing signatures described above. This ultimately causes the "Private Wallet Controller" (which regularly checks the back-side database for pending requests) to create a new virtual machine by cloning a template and starting the virtual machine.The Private Wallet Controller then performs the necessary configuration work on the virtual machine, creates the pair consisting of the internal public key and internal private key, and transfers the newly generated internal public key to the back-side database. The DMZ Controller transfers the internal public key to the front-side database. If this state is met with the internal public key in the front-side database, the front-end / API software requests the master password. After the master password is transmitted to the front-end / API via an encrypted connection, the front-end / API reads the internal public key from the front-side database and encrypts the hash value of the master password.The "master password hash value" encrypted in this way (in each case, this is its hash value; hence, "master password" always refers to its hash value) is stored in the "front-side database." With the help of the "DMZ Controller," this "master password" is transferred to the "back-side database," where the "private wallet controller" reads the "master password," starts the associated virtual machine if necessary, and decrypts the "master password" on the virtual machine using the internal private key stored there.

[0037] The "Private Wallet Controller" then also executes the commands on the virtual machine to set the "Master Password" as a partial key of the generated "Master File" on the installed wallet clients (clients for the respective blockchain protocol, for example, Bitcoin Core for the Bitcoin blockchain; depending on the blockchain, in-house developments can also serve as clients) (and thus to encrypt the respective private key using this password).

[0038] In the next step, a public key, referred to in the invention as the "master public key," is generated from a private key associated with the respective (blockchain) protocol. This "master public key" is transferred from the "Private Wallet Controller" to the "back-side database," and the virtual machine is hibernated. The "master public key" is transferred to the "front-side database" via the "bridge mechanism" of the "DMZ Controller" described several times above. The "Public Wallet Controller," which, as already described, also regularly checks the "front-side database" for pending orders, clones a virtual machine when such an order and the "master public key" are present, configures it, and sets the "master public key" in the respective wallet client software (again, Bitcoin Core for the Bitcoin blockchain as an example, or even self-developed clients) on the virtual machine.The virtual machine is then stopped (hibernate) and the creation process is recorded as successful in the front-side database by the "Public Wallet Controller".

[0039] The method according to the invention and the specific embodiment are schematically illustrated below with the aid of drawings. In detail: Fig. 1: Sequence diagram of the execution of digital signatures; Fig. 2: Sequence diagram of the process of creating an individual wallet;

[0040] In Figure 1, the described embodiment for the automated generation of digital signatures with a private key is shown as a sequence diagram and in Figure 2 The process for the automated creation of all necessary components (in particular the creation of the respective public / private key pairs and the creation of the virtual machines / containers) is described.

Claims

1. A computer-based method (100) for generating digital signatures, wherein the private key is stored on a system that is located in a non-public network and the request for generating a digital signature is made from a non-private network, characterized in that the digital signature is generated fully automated, by transmitting the data to be digitally signed into the non-public network and transmitting the computed digital signature back into the non-private network without requiring direct communication between the non-public and public networks, wherein the non-public and public networks remain separated by a DMZ.

2. Method (100) according to claim 1, characterized in that the data for which the digital signature is to be calculated is encrypted in a manner such that it can only be decrypted within the non-public network.

3. Method (100) according to claims 1 and 2, characterized in that the private key is stored in encrypted form in a non-public network.

4. Method (100) according to claims 1, 2 and 3, characterized in that data is required for decrypting the private key, which is not permanently stored within the system and acts as a subkey of the private key.

5. Method (100) according to one of the preceding claims, characterized in that the data for decrypting the private key, which is located on the system on which the private key is located, is encrypted during transmission in such a way that it can only be decrypted within the non-public network.

6. Method (100) according to one of the preceding claims, characterized in that the encrypted private key is decrypted only if it is necessary for a digital signature.

7. Method (100) according to one of the preceding claims, characterized in that requests for creating a digital signature using a specific private key are transmitted from the non-private network via an interface to a system which holds these requests and which can communicate with the non-private network in order to transmit existing requests.

8. Method (100) according to one of the preceding claims, characterized in that requests for creating a digital signature with the aid of a specific private key from the non-private network are transmitted via an interface to a system which holds these orders and which can only be accessed from the direction of the non-private network, in order to retrieve existing orders.

9. Method (100) according to one of the preceding claims, characterized in that requests for the generation of a digital signature using a particular private key from the non-private network are transmitted via an interface to a system which holds these orders and can be accessed by a system which is not located in the non-private network, in order to retrieve existing orders, wherein this system provides these orders for retrieval via a separate interface which can be accessed from the non-private network.

10. Method (100) according to one of the preceding claims, characterized in that requests for creating a digital signature with the aid of a particular private key from the non-private network can be transmitted via an interface to a system only if the authorization of the initiator of the transaction has been positively confirmed by one or more identification services.

11. Method (100) according to any of the preceding claims, characterized by gathering necessary transaction data outside the non-public network and transmitting only transaction data to the non-public network when the transaction data is complete or as complete as possible.

12. Method (100) according to one of the preceding claims, characterized in that software is capable of activating and deactivating encapsulated environments and executing commands within said encapsulated environment.

13. A method (100) according to one of the preceding claims, characterized in that a local node of each supported blockchain protocol is operated as a virtual machine and encapsulated systems that assemble transaction data can access it.

14. A method (100) according to one of the preceding claims, characterized in that it is preceded in time by a sub-method (200) which creates an encapsulated environment in a non-public network and generates one or more private / public key pairs for use in blockchains and generates an internally used private / public key pair.