Method and system for securely transferring a data set

0001The invention relates to a method and a system for the secure transmission of a data record, in particular a medical data record, between a server and a user device by means of a cloud service, as well as a corresponding medical technical system.

0002In more and more use cases, data services are used as cloud applications to access data outside of a private, closed network or to process data located in the cloud. Examples of this are the processing of measurement data by smart meters in the cloud, e.g. by a metering point operator. Another example is the evaluation of parameters of imaging procedures in healthcare. In both cases, the data must be anonymized or pseudonymized in order to make the reference to a specific person unrecognizable.

0003Various methods for transmitting sensitive data are known, some of which are explained in more detail below.

0004A process known as "S / MIME" enables encrypted data to be sent by email. S / MIME relies on two-stage encryption. The actual message is symmetrically encrypted to protect confidentiality. The key used for this is then encrypted with the recipient's public key (asymmetrically). This ensures that only the recipient who is in possession of the corresponding private key can decrypt the email.

0005The "RSA encryption", named after the first letters of the inventors' last names, enables data to be encrypted with a recipient's public key.

0006The asymmetric encryption used here is time-consuming, which means that usually combined methods (as previously described for S / MIME) are used. RSA Encryption is therefore used in particular for key management. One example is TLS (IETF RFC 5246), a security protocol that is widely used in web-based applications.

0007The "Diffie-Hellman key negotiation" is a procedure for establishing a symmetrical key, which can then be used to secure bulk data. Here, the sender and recipient each generate a key pair, the respective public key of which can be published. The respective secret keys remain with the sender or the recipient. The sender can use the public recipient key and his secret sender key to generate a message for the recipient, which the recipient can extract again using the public sender key and his secret recipient key. There are also known certificates (ECDSA certificates) whose public ECDSA key can also be used as the public Diffie Hellman key.

0008A standard known under the designation "ISO / IEC 15118" describes a method for the exchange of communication between a charging station and an electric vehicle. Some of the information exchanged includes a pair of keys generated in the backend that can be transported to the electric vehicle by means of a message. The car has an ECDSA-based key pair that is known in the backend. In the backend, the public key in the ECDSA certificate is treated as a static Diffie Hellman key. If the backend wants to securely transfer the centrally generated key pair to the electric vehicle, it generates its own Diffie Hellman key pair and uses the public key of the electric vehicle and its own secret key to generate the Diffie Hellman secret and uses this to encrypt the key pair that is to be safely transported to the electric vehicle . The encrypted key pair and the public Diffie Hellmann key from the backend are then signed and sent to the electric vehicle. This can now also generate the Diffie Hellman secret using its private Diffie Hellman key and the public key of the backend and decrypt and install the key pair. However, this solution only works if both parties trust the underlying certificates that were used for the signature. This trust is generally achieved through a joint certification authority or one that is trustworthy for both partners. Further approaches from the prior art are described in the document "<nplcit id="ncit0001" npl-type="b"><text>Security Enhanced Anonymous Remote User Authentication and Key Agreement for Cloud Computing ", authors DONG ZHEMING ET AL, 2014 IEEE 17TH INTERNATIONAL CONFERENCE ON COMPUTATIONAL SCIENCE AND ENGINEERING, IEEE, December 19, 2014 (2014-12-19), pages 1746-1751, XP032730242</text></nplcit> and in the document <patcit id="pcit0001" dnum="US2017171178A1"><text>US 2017/171178 A1</text></patcit> (REYNDERS TIM [US]) Shown June 15, 2017.

0009In medical applications, however, it may be necessary in individual cases to reverse the pseudonymization of the data, for example if extreme measured values ​​occur that require an analysis of the causes. However, this re-identification may only take place in the sphere of the data-collecting body; the possibility of access by the provider of the cloud application must be excluded. An example of this are increased radiation dose values ​​in imaging procedures in hospitals, the causes of which also have to be analyzed and documented for regulatory reasons.

0010This cannot be done efficiently and comfortably by key distribution mechanisms typically used for distributing symmetrical keys for known encryption methods according to the prior art.

0011It is an object of the present invention to provide an alternative, more convenient method and a corresponding system as well as a medical-technical installation with which the disadvantages described above are avoided. In particular, it was an object of the present invention to provide a method which allows the patient-related data to be made available to a user in an encrypted form via a cloud service.

0012This object is achieved by a method according to patent claim 1, a system according to patent claim 12 and a medical-technical installation according to patent claim 13.

0013The method according to the invention and the system according to the invention are typically used for the secure transmission of a (in particular medical) data record between a server and a user device by means of a cloud service. Of course, other applications, such as the transmission of other safety-critical data sets, are also possible.

0014Cloud computing, which means something like "computer cloud" or "data cloud" in German, relates in the context of this invention to the provision of storage space as a service via a network, in particular via the Internet. The storage space does not have to be installed on the local computer network of a medical facility, but can be obtained from one or more providers as required. The invention can be used particularly advantageously when this storage space is outside the medical facility in which the user device and server are located and can only be reached via an internet connection (which is naturally to be classified as unsafe). Even if the term "cloud" comes from English, it is also used in German for corresponding services. In the following, for a better understanding, the terms “cloud” or “cloud service” are used for a service that provides storage space and via which data can be stored on this storage space or accessed from it.

0015The method according to the invention for the secure transmission of a (in particular medical) data record between a server and a user device by means of a cloud service comprises the following steps.

0016- Provision and / or generation of a user-side (first) Diffie Hellman key pair by the user device. This user-side Diffie Hellman key pair naturally comprises a secret user key and a public user key. The basics of Diffie Hellman encryption are known to the person skilled in the art and are described in outline in the introductory part. In the case of a preferred encryption, one key pair per request, one key pair per user or one key pair per requested server is generated or used. The term “create” here means that a key pair is calculated, and “providing” means the provision of an already calculated key pair, for example from a data store.<ul id="ul0001" list-style="dash"><li>Transmission of the public user key to the server. The public user key is sent from the user device to the server via a data line. Since this usually takes place within a network of a medical facility, which is often externally secured by data technology, a normal http connection can be used (http: "Hypertext Transfer Protocol"; German: "Hypertext Transfer Protocol"). Typically, however, in this environment too, connections secured on the server side using https are used. Here the server authenticates itself to the user.</li><li>Provision and / or generation of a server-side (second) Diffie Hellman key pair by the server. This server-side key pair naturally comprises a secret server key and a public server key. Depending on the application, it is preferred that an individual key pair consisting of a public server key and a secret server key is generated by the server for each data record and / or for each user device. However, it can also be the case that the key pair has already been generated beforehand and is only made available in this step by being retrieved from a memory.</li><li>Provision of a data record on the server. This data record typically includes patient-related data, in particular medical images or measurement results, which are confidential.</li></ul><ul id="ul0002" list-style="dash"><li>Generation of a server-side Diffie Hellman key on the server using the secret server key and the public user key and encryption of the data record on the server using the server-side Diffie Hellman key resulting from this key generation. The data record is preferably located on the server for encryption and can have been retrieved from the server, for example in front of a medical device or from a database. However, the data record can also have been on the server since it was created.</li><li>Transmission of the encrypted data record (and, if applicable, the public Diffie Hellman server key) to the cloud service. This can be done, for example, by means of known methods and protocols for the transmission of data in networks. Since the cloud service can often be reached via the Internet, an Internet line (with the appropriate protocols) can also be used as a possible transmission path.</li><li>Retrieving the public server key and retrieving the encrypted data record from the cloud service by means of the user device. Of course, the public server key of the key pair that was used to generate the encryption key for the encrypted data record in question is retrieved here. This public server key was preferably stored together with the encrypted data record by the cloud service (in the cloud) and both components are retrieved from the cloud service, but other variants are also conceivable depending on the application. This is described in more detail below.</li><li>Generation of a user-side Diffie Hellman key on the user device using the secret user key and the retrieved public server key and decryption of the encrypted data record on the user device with the user-side Diffie Hellman key resulting from this key generation.</li></ul>

0017It should be noted that the original data record is always encrypted on the server side and the user always retrieves the encrypted data record from the cloud with his user device. The encrypted data record is therefore neither directly accessed by the user device from the server, nor is the data record directly encrypted by the user device and sent to the cloud. In the context of the invention, communication (“request”) between the user device and the server is only required for the transmission of the public user key and, if necessary, for the notification that a certain data record is to be stored in the cloud.

0018In addition, the following step preferably follows: Provision of the (decrypted) data record by means of the user device, the provision preferably comprising displaying, storing and / or processing the data record.

0019As a precaution, it is pointed out that the sequence of the process steps is not fixed to the one shown, unless technical reasons specify a sequence in this regard. For example, the data record can be made available before one or both key pairs are generated, and the server-side key pair can also be generated before the user-side key pair, for example. Basically, it is only important that the relevant components are available for a step.

0020In contrast to the prior art, the Diffie-Hellman encryption, which is known between two participants, is modified to a 3-point communication in which a Diffie Hellman key negotiation is adapted so that the resulting key that was used for the encryption, can be restored at a later time.

0021One advantage of the invention is that, in addition to the encrypted data, information is provided for their decryption without the cloud service being able to decrypt the data itself by means of this information.

0022The invention advantageously allows access to the data in the cloud from different networks, that is to say from different user devices (clients), without the server having to be accessible to all clients. Furthermore, the principle according to the invention simplifies the infrastructure. With the proposed approach, a simpler management of certificates for authentication in the context of https communication can take place on the server side, since the security of the data in the cloud service is essentially ensured via the Diffie Hellman key generation.

0023The system according to the invention for the secure transmission of a (in particular medical) data record between a server and a user device by means of a cloud service comprises a server, a user device and a data connection between server and user device and a data interface for a data connection between server and user device with a cloud Service. The server and the user device are specially configured, as will be explained in more detail below.<ul id="ul0003" list-style="dash"><li>The user device is designed to retrieve and / or to generate a user-side Diffie Hellman key pair comprising a secret user key and a public user key.</li><li>The system is designed to transmit the public user key to the server. The data connection between the server and the user device is used for this.</li><li>The server is designed to retrieve and / or to generate a server-side Diffie Hellman key pair comprising a secret server key and a public server key. As already mentioned above, the server-side Diffie Hellman key pair can be obtained from a memory of the server or even from a database. This connection to the database should be secure or the server-side Diffie Hellman key pair should be encrypted. It is particularly preferred if the server is designed both to generate a Diffie Hellman key pair and to retrieve a Diffie Hellman key pair (from a storage unit).</li><li>The server is designed to retrieve a data record. This data set can be obtained from a memory of the server or even from a database. This connection to the database should be secure or the data record should be encrypted. The server can be located in a medical device (a medical device) and medical data determined with this device, e.g. Measurement results or images are encrypted directly according to the principle according to the invention (with the method according to the invention).</li><li>The server is designed to generate a server-side Diffie Hellman key using the secret server key and the public user key and to encrypt the data record using the resulting server-side Diffie Hellman key.</li><li>The server is designed to transmit the encrypted data record to the cloud service.</li><li>The user device is designed to retrieve the encrypted data set and the public server key from the cloud service.</li><li>The user device is designed to generate a user-side Diffie Hellman key using the secret user key and the retrieved public server key and to decrypt the encrypted data set on the user device with the resulting user-side Diffie Hellman key.</li></ul>

0024The user device is preferably also designed to provide the (decrypted) data record, the provision preferably comprising displaying, storing and / or processing the data record.

0025It should be noted that the system components mentioned above and described below (individual system components or each of the system components, i.e. server or user device or database) can have one or more of the following subcomponents, each of these subcomponents in turn comprising several interacting subcomponents :<ul id="ul0004" list-style="dash" compact="compact"><li>a computing unit ("CPU"), in particular a computing unit from the group processor, microprocessor, integrated circuit, GPU, ASIC, FPGA,</li><li>a storage unit, in particular a storage unit from the group of magnetic storage (e.g. a hard disk), semiconductor storage (e.g. a solid state disk), optical storage (e.g. DVD) or mixed forms of these data storage media,</li><li>an interface (e.g. a data bus, a WLAN, a LAN or a USB interface).</li></ul>

0026A medical-technical system according to the invention is preferably designed for recording and / or processing medical-technical images and designed for integration as a server in a method according to one of Claims 1 to 11. As an alternative or in addition, the medical-technical installation comprises a server of a system according to the invention. The medical technology system thus comprises a server designed:<ul id="ul0005" list-style="dash" compact="compact"><li>to receive a public user key from a user system,</li><li>for retrieving and / or generating a server-side Diffie Hellman key pair comprising a secret server key and a public server key,</li><li>to retrieve a data set,</li><li>for generating a server-side Diffie Hellman key using the secret server key and the public user key and for encrypting the data record using the resulting server-side Diffie Hellman key, and</li><li>to transmit the encrypted data record to a cloud service.</li></ul>

0027Such a server can, however, also be present independently of a medical-technical system. A server according to the invention, which can be used in the context of the method according to the invention for the secure transmission of a data record, comprises at least:<ul id="ul0006" list-style="dash" compact="compact"><li>A receiving unit designed to receive a public user key from a user system,</li><li>a key unit designed to retrieve and / or generate a server-side Diffie Hellman key pair comprising a secret server key and a public server key,</li><li>a data interface designed to retrieve a data set,</li><li>an encryption unit designed to generate a server-side Diffie Hellman key using the secret server key and the public user key and to encrypt the data record using the resulting server-side Diffie Hellman key, and</li><li>a transmission unit designed to transmit the encrypted data record to a cloud service.</li></ul>

0028A server according to the invention is therefore able to carry out a (server-side) method according to the invention, which comprises at least the following steps:<ul id="ul0007" list-style="dash" compact="compact"><li>Receipt of a public user key from a user system,</li><li>Retrieval and / or generation of a server-side Diffie Hellman key pair comprising a secret server key and a public server key,</li><li>Retrieving a record,</li><li>Generating a server-side Diffie Hellman key using the secret server key and the public user key and for encrypting the data record using the resulting server-side Diffie Hellman key, and</li><li>Transmission of the encrypted data set to a cloud service.</li></ul>

0029A user device according to the invention, which can be used in the context of the method according to the invention for the secure transmission of a data record, comprises at least:<ul id="ul0008" list-style="dash" compact="compact"><li>a data interface designed for a data connection to a server,</li><li>a data interface designed for a data connection with a cloud service,</li><li>a key unit designed to retrieve and / or generate a user-side Diffie Hellman key pair comprising a secret user key and a public user key,</li><li>a transmission unit designed to transmit the public user key to a server,</li><li>a retrieval unit designed to retrieve the public server key and to retrieve an encrypted data record from a cloud service,</li><li>a decryption unit designed to generate a user-side Diffie Hellman key using the secret user key and a retrieved public server key and to decrypt the encrypted data set on the user device with the resulting user-side Diffie Hellman key.</li></ul>

0030A user system according to the invention is therefore able to carry out a (user-side) method according to the invention, which comprises at least the following steps:<ul id="ul0009" list-style="dash" compact="compact"><li>Retrieving and / or generating a user-side Diffie Hellman key pair comprising a secret user key and a public user key,</li><li>Transmission of the public user key to a server,</li><li>Retrieving the public server key and retrieving an encrypted data set from a cloud service,</li><li>Generation of a user-side Diffie Hellman key using the secret user key and a retrieved public server key and decryption of the encrypted data set on the user device with the resulting user-side Diffie Hellman key.</li></ul>

0031A system according to the invention preferably comprises at least one user device according to the invention and a server according to the invention.

0032A large part of the aforementioned components of the system can be implemented entirely or partially in the form of software modules in a processor of a corresponding medical-technical system. A largely software-based implementation has the advantage that medical-technical systems that have already been used can be retrofitted in a simple manner by means of a software update in order to work in the manner according to the invention. In this respect, the object is also achieved by a corresponding computer program product with a computer program that can be loaded directly into a computing system or a medical-technical installation, with program sections to carry out all steps of the method according to the invention when the program is executed in the computing system or the medical-technical installation becomes. In addition to the computer program, such a computer program product can optionally contain additional components such as B. documentation and / or additional components also include hardware components such as hardware keys (dongles etc.) for using the software.

0033A computer-readable medium, for example a memory stick, a hard disk or some other transportable or permanently installed data carrier on which the data from a Computer system or a computer unit of the medical-technical system readable and executable program sections of the computer program are stored. For this purpose, the computer unit can, for example, have one or more cooperating microprocessors or the like.

0034Further, particularly advantageous embodiments and developments of the invention emerge from the dependent claims and the following description, whereby the claims of one claim category can also be developed analogously to the claims and parts of the description for another claim category and in particular also add individual features to different exemplary embodiments or variants new embodiments or variants can be combined.

0035It should be noted that the user should save his secret user key for decrypting the data record and keep it in stock, as otherwise he would no longer be able to reconstruct the key for decrypting the data record based on the public server key. If a user generates a new key pair for each encryption process, he must therefore also keep all secret user keys available. In this case, however, it is advantageous if he receives an indication of which encrypted data record in the cloud can be decrypted with which secret user key. For example, the data record can contain a corresponding indication of which secret user key must be used (but without revealing this). This issue is discussed in more detail below.

0036According to a preferred method, the encrypted data record is transmitted to the cloud together with the public server key. After the transmission, it is preferred that the encrypted data record and the public server key are stored together in the cloud. It is also preferred that the encrypted data record and the public server key are stored in the cloud with a reference to one another. This has the advantage that the encrypted data record and the public server key can be sent together to the user device when it is called up.

0037Theoretically, it is possible that the public server key is not sent to the cloud, but can be obtained from the server, for example. In this case, however, the user device must know which public server key was used to encrypt the encrypted data record, so that in this case too it is advantageous if the encrypted data record and the public server key are stored with a reference to one another. Alternatively, however, the server can also implement an assignment to an encrypted data record based on the querying user.

0038Depending on the application, it is preferred that the encrypted data record is digitally signed by the server together with the public server key. This then binds the server public key to the record.

0039According to a preferred method, in addition to the transmission of the public user key, the user device also transmits a user reference number to the server. This user reference number is created in such a way that it allows conclusions to be drawn about the user and / or the user device. If there is a large number of encrypted data records in the cloud service, this enables a very good assignment to the users or users. User devices that should have access to these data records and is used in particular for an effective search.

0040It is preferred that the user reference number is also transmitted as part of the transmission of the encrypted data record to the cloud service (by the server). After the transmission, it is preferred that the encrypted data record and the user reference number are stored together in the cloud. It is also preferred that the encrypted data record and the user reference number are stored in the cloud with a reference to one another. This has the advantage that the encrypted data record and the user reference number are linked to one another and an affiliation can be checked when a user device is called up or when a search query is made.

0041The user reference number is primarily useful for associating the (encrypted) data records with a user or user device. If a server sends encrypted data records to the cloud service without a user reference number, it is more difficult for the cloud service to answer a request from a user device with the corresponding encrypted data records.

0042The user reference number can advantageously be used for the above-mentioned assignment of a secret user key to a retrieved encrypted data record. The user can use this to link the corresponding request for a data record to it. It is preferred to do so (e.g. per data record) a user key pair (user-side Diffie Hellman key pair) is generated, which is linked for data purposes with the user reference number (at least the secret user key) and then the public user key is sent to the server together with the user reference number, and the encrypted data record is collected from there is saved in the cloud with the user reference number. When retrieved, the user reference number is available to the user device and the correct secret user key can be used.

0043Alternatively, the user can only reference the request via the user reference number and use a specific user key pair for all requests. Another alternative would be the case that a user key pair is used for each server to be queried. In this way, all data queries could then be linked to a server-specific user key, in which case, together with the encrypted data record, there is an indication in the cloud as to which server has encrypted it.

0044The administration of all three alternatives lies with the user and can be selected by him as a preference. It is also preferred that the URL to the encrypted data record includes at least part of the user reference number.

0045According to a preferred method, a previously created key pair is used by the server for a defined number of data records and / or for a group of user devices.

0046In theory, this can be a single server-side key pair for all operations, from which the public server key can then be transmitted directly to the user devices. Of course, this alternative is associated with a certain impairment of security. It is more secure if a different key pair is generated for each user device. Here, too, a single server-side key pair can theoretically be used for one user device and the public server key can be sent from the server to this user device and stored there. In this case a user reference number for the encrypted data sets would be very advantageous. In the event that the public server key reaches the user system in a different way than from the cloud service, a reference is very advantageous or even necessary, which indicates which public key is required to decrypt which data record.

0047According to a preferred method, as part of the retrieval of the encrypted data record, it is retrieved from the cloud service together with the public server key by the user device, preferably by specifying the user reference number. This is particularly advantageous if a (user-side) Diffie Hellman key pair is not generated for all or for one user device at a time, but a key pair depending on the data records (e.g. is regenerated for each data record. In this case, it is particularly advantageous to link a data record with a user reference number.

0048The server's public key is required by the user device to decrypt an encrypted data set. A group of a data record together with the public server key (the key pair with which the key for encrypting the data record was generated) simplifies handling for the user device.

0049According to a preferred method, after the transmission of the public user key to the server, this server authenticates the user device. If authentication is successful, the server then continues with the provision or generation of a (server-side) Diffie Hellman key pair. An authorization of the user device is also preferably checked.

0050The authentication is preferably carried out using a challenge-response method (German: "request-response method"). This is a knowledge-based authentication method for a participant. Here, one participant sets a task (challenge) that the other has to solve (response) in order to prove that he knows certain information (shared secret) without transmitting this information himself.

0051According to a preferred method, a key derivation is carried out via a key derivation function before the data record is encrypted by the server. Information and / or characteristics of the data record designation are preferably incorporated into the key derivation function, preferably a date (eg an MRT date in the case of magnetic resonance tomography images. Key derivation has the advantage that each data record can be encrypted with a separate key derived from a Diffie Hellman key.

0052The key derivation preferably takes place according to a method from the group PBKDF (Password-Based Key Derivation Function), HKDF (hash key derivation function), HMAC-SHA256 (hash-based message authentication code based on Secure Hash Algorithm 256).

0053According to a preferred method, the data connection between the server and the cloud service is initiated by the server and the cloud service is authenticated by means of a certificate in order to transmit the encrypted data record and preferably also the public server key and / or the user reference number. It is preferred here that the server is also authenticated with an individual proof of authorization. Such a credential is typically a combination of a user name and a password or a certificate with an associated private key.

0054According to a preferred method, the encrypted data record is transmitted to the cloud service and / or the encrypted data record is retrieved from the cloud service via an http connection. Between the cloud and the server and / or between the cloud and the user device, an https connection, that is to say an encrypted http connection, is preferred (https: "Hypertext Transfer Protocol Secure"; dt .: "secure hypertext transfer protocol"). Theoretically, the encryption of a connection could be dispensed with and an http connection could simply be used, since the transmitted data record is already encrypted. However, the communicating components are automatically authenticated as part of the https procedure. Without this, man-in-the-middle attacks would be possible so that a third party could change the data. In particular, an attacker could change the association between user reference number and data record and thus interchange the data of certain users. Therefore, an https connection is very beneficial.

0055According to a preferred method, the cloud service provides the user device with a publish / subscribe interface. The user device preferably subscribes to the cloud service with regard to the desired encrypted data record with the user reference number. In software architecture, publish-subscribe is a message pattern in which a sender of messages (called a "publisher") does not program the messages to be sent directly to specific recipients (called subscribers). Instead, published messages are categorized into classes by the publisher without knowing which subscribers there are. Similarly, subscribers express interest in one or more classes and only receive messages that are of interest without necessarily knowing which publishers are present.

0056According to a preferred method, the user device is informed as soon as the server has transmitted the corresponding data record to the cloud service.

0057Even if at first glance a notification of the user does not seem necessary, since he initiated the transmission of the data record to the cloud by sending his public user key, it is still advantageous. For example, it can be the case that the user has requested several data records via the server at different times and the data is provided asynchronously to the request. The user can then be informed when one of the requested data sets is available.

0058By means of the invention, personal sensitive data can advantageously be made available via cloud services. The special feature here is that no separate certificates or no publicly resolvable certificates have to be used for authentication on the user side. This saves the user having to configure the corresponding key material and also the ongoing management (renewal, etc.). In particular, errors can be avoided if a user wants to use self-generated certificates instead of publicly resolvable certificates (from a public certification authority) in order to save costs. In this case, the user device must first accept a certificate that cannot be verified. This process can be a security risk. A particular advantage of the invention is that the information required for decryption does not have to be provided by a public key infrastructure (PKI). This avoids additional configuration of the user device or server.

0059The invention is explained in more detail below with reference to the accompanying figures on the basis of exemplary embodiments. The same components are provided with identical reference numbers in the various figures. The figures are usually not to scale. Show it:<ul id="ul0010" list-style="none"><li><figref idref="f0001">Figure 1</figref> a flow chart for a possible sequence of a method according to the invention,</li><li><figref idref="f0002">Figure 2</figref> a schematic embodiment of a system according to the invention,</li><li><figref idref="f0003">Figure 3</figref> a more detailed flow chart for a possible sequence of a method according to the invention,</li><li><figref idref="f0004">Figure 4</figref> a roughly schematic representation of a preferred medical-technical system.</li></ul>

0060<figref idref="f0001">Figure 1</figref> shows a flow chart for a possible sequence of a method according to the invention for the secure transmission of a (in particular medical) data record D between a server 3 and a user device 2 by means of a cloud service 5. The procedure consists of the following steps: In step I, a Diffie Hellman key pair Bp, Bs is provided or generated by the user device 2, comprising a secret user key Bs and a public user key Bp.

0061In step II, the public user key Bp is transmitted from the user device 2 to the server 3.

0062In step III, a server-side Diffie Hellman key pair Sp, Ss is provided and / or generated by the server 3, comprising a secret server key Ss and a public server key Sp.

0063In step IV, a data record D is made available on the server 3. This is, for example, an image file.

0064In step V, a server-side Diffie Hellman key S1 is generated on the server 3 using the secret server key Ss and the public user key Bp and the data record D is encrypted on the server 3 using the server-side Diffie Hellman key S1 resulting from this key generation.

0065In step VI, the encrypted data record Dv is transmitted to the cloud service 5. In this example, the public server key Sp linked to the encrypted data record Dv is sent to the cloud service 5 and stored there together.

0066In step VII, the public server key Sp is called up and the encrypted data record Dv is called up from the cloud service 5 by means of the user device 2.

0067In step VIII, a user-side Diffie Hellman key S2 is generated on the user device using the secret user key Bs and the public server key Sp that has been retrieved, and the encrypted data record Dv is decrypted on the user device 2 with the user-side Diffie Hellman key S2 resulting from this key generation.

0068<figref idref="f0002">Figure 2</figref> shows a schematic embodiment of a system 1 according to the invention for the secure transmission of a (in particular medical) data record D between a server 3 and a user device 2 by means of a cloud service 5. The system 1 comprises a server 3, a user device 2 and a data connection V between the server 3 and user device 2, as well as a data interface 4 for a data connection V between server 3 and user device 2 with a cloud service 5.

0069The user device 2 can, for example, be a computer with network access and a browser. The server can be a web server that provides the desired data. The system 1 is part of the infrastructure within a hospital. The hospital network is usually restricted and the components operated in it (user device 2 and server 3) are then usually restricted with regard to the use of https publicly resolvable certificates, since the distribution and maintenance of certificates and associated private keys with publicly resolvable certificates (from a trustworthy certificate authority) is not possible. In the example shown, a trustworthy environment is also assumed, so that an http connection can be used for the data connection V between user device 2 and server 3. Alternatively, however, a separate certificate can be installed here, which is configured as trustworthy by the user device and thus also enables an https connection. A standard https connection can then be used as data connection V to the cloud service.

0070The user device 2 is designed to retrieve and / or generate a user-side Diffie Hellman key pair Bp, Bs comprising a secret user key Bs and a public user key Bp.

0071The system 1 is designed to transmit the public user key Bp to the server 3. The case shown is that the public user key Bp is currently being transmitted. For a better overview, the public key is hatched and the secret key is white.

0072The server 3 is designed to retrieve and / or generate a server-side Diffie Hellman key pair Sp, Ss comprising a secret server key Ss and a public server key Sp. These are shown with the beard facing up for better differentiation from the user keys Bp, Bs.

0073The server 3 is designed to retrieve a data record D.

0074The server 3 is also responsible for generating a server-side Diffie Hellman key S1 (see Sect. <figref idref="f0001">Fig. 1</figref>) designed using the secret server key Ss and the public user key Bp and for encrypting the data record D by means of the server-side Diffie Hellman key S1 resulting therefrom. For a better overview, an encrypted data record Dv is shown with a lock, as can be seen in the cloud of the cloud service 5.

0075The server 3 is designed to transmit the encrypted data record Dv to the cloud service 5. In addition, in this example the server 3 is also designed to send a user reference number R to the cloud service 5. This has already happened here. The encrypted data record Dv linked to the user reference number R and the public server key Sp can be seen in the cloud of the cloud service 5. In this example, the same public server key Sp is always used.

0076The user device 2 is designed to retrieve the public server key Sp and to retrieve the encrypted data record Dv from the cloud service 5.

0077The user device 2 is also used to generate a user-side Diffie Hellman key S2 (see Sect. <figref idref="f0001">Figure 1</figref>) using the secret user key Bs and the retrieved public server key Sp and designed to decrypt the encrypted data record Dv on the user device 2 with the user-side Diffie Hellman key S2 resulting therefrom.

0078A data interface 4 can be a hardware or software interface (for example Ethernet, PCI bus, USB or Firewire). A user device 2 resp. a server 3 can have hardware elements or software elements, for example a CPU (English acronym for "central processing unit"), a GPU (English acronym for "graphical processing unit"), a microprocessor, a so-called FPGA (English acronym for "Field Programmable Gate Array") or an ASIC (English acronym for "applicationspecific integrated circuit"). A storage unit MU and / or a training storage unit TMU can be implemented as a non-permanent main memory (random access memory, or RAM for short) or as a permanent mass storage device (hard drive, USB stick, SD card, solid state disk).

0079The data interface 4 can in particular comprise several sub-interfaces that carry out different steps of the respective method. In other words, the data interface 4 can also be understood as a multiplicity of data interfaces 4. A user device 2 or a server 3 can in particular comprise a plurality of slave computing units which carry out different steps of the respective method. In other words, the user device 2 and / or the server 3 can also be understood as a multiplicity of relevant computing units.

0080<figref idref="f0003">Figure 3</figref> shows a more detailed flow chart for a possible sequence of a method according to the invention.

0081The user device 2 wants access to a specific data record D (which is not yet in the cloud) and for this purpose sends a request A to the server 3. Before that, it generates a user-side Diffie Hellman key pair consisting of the public user key Bp and the secret user key Bs and a user reference number R.

0082The server 3 receives the request and authenticates the user device 2 (dashed arrows). This can be implemented, for example, using a standard challenge-response procedure. If the authentication and also the authorization of the user device 2 are successful, the server 3 generates a server-side Diffie Hellman key pair consisting of the public server key Sp and the secret server key Ss.

0083The server 3 is now able to calculate a key by means of the received public user key Bp and the secret server key Ss, as described above, and to create an encrypted data record Dv. Characteristics of the data record designation can be included in the key derivation function. This derivation has the advantage that each data record can be encrypted with a separate key.

0084The server 3 then transmits the encrypted data record Dv, together with its public server key Sp and the user reference number R, to the cloud service 5. The transport connection between the network-internal server 3 and the cloud service 5 is initiated by the server 3 (arrow 'i') and the cloud service 5 authenticates itself by means of a certificate (arrow 'ii'). The server in turn authenticates itself with its own credential (arrows iii), which is typically a combination of username and password. The encrypted data record Dv is then transmitted together with its public server key Sp and the user reference number R by the server 3, followed by a message about the success on the part of the cloud service 5 (arrows iv).

0085A Transport Layer Security connection (TLS connection), which is established here after initiation (dashed box), is preferred.

0086The user device 2 can now make a request to the cloud service 5 and set up a TLS connection in the same way as described above (arrows v and vi, dashed box). The user device 2 can then transmit the user reference number R within this connection. In an alternative variant, the cloud service provides a publish-subscribe interface as indicated by the pair of arrows vii. In this variant, the user device can subscribe to the event with the user reference number R at the cloud service 5. The cloud service 5 can now make the provided encrypted data record Dv available together with the public server key Sp to the user device 2 (pair of arrows viii).

0087Only the user device 2 that has the secret user key Bs is now able to calculate the appropriate key in order to decrypt the encrypted data record Dv.

0088<figref idref="f0004">Figure 4</figref> shows a roughly schematic representation of a preferred medical-technical system 6. This comprises a server 3 with a functionality as described above.

0089Finally, it is pointed out once again that the methods described in detail above and the system 1 shown are merely exemplary embodiments which can be modified in the most varied of ways by the person skilled in the art without departing from the scope of the invention. Furthermore, the use of the indefinite article "a" or "an" does not exclude the possibility that the relevant features can also be present more than once. Likewise, the terms “unit”, “system” and “module” do not exclude the possibility that the relevant components consist of several interacting sub-components, which may also be spatially distributed.