WO2014124809A1 - Authentifizierung von medizinischen clientgeräten in einem geräteverbund - Google Patents

Authentifizierung von medizinischen clientgeräten in einem geräteverbund Download PDF

Info

Publication number
WO2014124809A1
WO2014124809A1 PCT/EP2014/051756 EP2014051756W WO2014124809A1 WO 2014124809 A1 WO2014124809 A1 WO 2014124809A1 EP 2014051756 W EP2014051756 W EP 2014051756W WO 2014124809 A1 WO2014124809 A1 WO 2014124809A1
Authority
WO
WIPO (PCT)
Prior art keywords
client
key
authentication
encryption means
message
Prior art date
Application number
PCT/EP2014/051756
Other languages
English (en)
French (fr)
Inventor
Georg Heidenreich
Wolfgang Leetz
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Publication of WO2014124809A1 publication Critical patent/WO2014124809A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/88—Medical equipments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/041—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 using an encryption or decryption engine integrated in transmitted data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/121—Timestamp
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Definitions

  • the present invention relates to an authentication system, a client device, a trust device and a method for authenticating a medical client device to a trust device in a device network, as well as a computer program product.
  • the present invention is thus in the fields of information and network technology and medical technology and has the goal of authenticating a user of a client device and / or the respective client device with a communication partner.
  • the point here is that the client first only asserts his identity and can prove this assertion to the communication partner (in this case: the trust device) by means of the authentication.
  • the knowledge-based authentication both communication partners know something, eg a PIN, a password, etc.
  • a possession-based authentication at least one communication partner has something, eg a smart card , a physical key, etc.
  • feature-based authentication such as a biometric authentication, fingerprint, iris recognition, etc.
  • the present invention is based on a knowledge-based authentication and in particular on a symmetric encryption method.
  • a workstation interacts or a computer for data acquisition of a magnetic resonance tomograph ("MRT") with a client, which can be positioned as a diagnostic station in a remote location (eg in an external medical practice)
  • MRT magnetic resonance tomograph
  • the client authenticates with its communication partner (in this case eg an MRT server).
  • Another application scenario concerns mobile medical devices (intracorporeal or extracorporeal), such as cardiac pacemakers, sphygmomanometers, sensor devices, etc. that send the captured data to other medical devices (e.g., a central server) and exchange more data with them.
  • other medical devices e.g., a central server
  • the communication partners have to authenticate each other or authenticate each other.
  • Asymmetric cryptosystems based on the use of public and private keys always require a centralized instance to manage, assign, and maintain the keys in use.
  • asymmetric encryption techniques comprising a key pair of different keys for encryption and decryption.
  • the key pair used in an asymmetric cryptosystem (also called a public key system) is also called a private and public key.
  • the secret (or private) key is used for encryption and the public key for authentication or decryption.
  • a recipient of a message wants to authenticate the identity of the sender of the message, in this type of asymmetric authentication systems of the prior art it is provided that the receiver decrypts a so-called sender-encrypted signature, which he has received together with the message from the sender. He uses it for this the public decryption key of the sender.
  • the public key management is done by a third-party trustee.
  • the two communication partners thus always inevitably interact with the certification authority.
  • the result of the decryption process is compared with the receiver-side simulated signature. This signature is the identity of the sender or a mathematical figure of it. For this, the address of the sender and optionally further data can be used. If the two results match, the sender is considered authenticated at the receiver.
  • Another group of known asymmetric authentication systems is to keep a client-specific decryption key secretly or privately with the client and to make the associated encryption key publicly available.
  • the public key management is done by a certification authority.
  • the two communication partners always inevitably interact with the certification authority.
  • the recipient encrypts a so-called secret (usually a randomly generated number) with the client's public key and sends the resulting "challenge" to the client, whereupon the client authenticates its message to the recipient by passing the signature decrypted with the secret key and sends the resulting "response” with the message to the recipient.
  • the receiver authenticates the client by comparing this decrypted "response" with the original secret to match.
  • the object of the present invention is therefore to provide an authentication system with a client device and a trust device, as well as a method for authentication and a computer program product which overcomes the disadvantages mentioned above and no longer requires the use of a certification authority. Furthermore, the proposed authentication system should offer the possibility that a client authenticates himself to a large number of receiving devices or trust devices. In addition, the authentication process should be shortened and run more easily.
  • the above object is achieved by the accompanying independent claims, in particular by an authentication system, a client device, a trust device, a method for authentication and a computer program product. Advantageous developments of the invention can be found in the subclaims.
  • the invention relates to a method for authenticating a client to a trust device, the method comprising the following method steps:
  • Determining the client-specific encryption means by accessing the memory, which is assigned in each case in the received client address, preferably one-to-one.
  • authentication refers to proving the identity of the sender to the recipient in a computerized clinical network that exchanges data over a bus system or network (preferably DICOM).
  • DICOM bus system or network
  • Authentication is automatic and thus without the need for user input.
  • the authentication is preferably based on symmetric encryption.
  • the authentication can be carried out by only sender (client) and receiver (trust device) are in communication with each other and without access to a third certification authority.
  • the authentication can be used to prove the identity (use to identity proof) of the client as a user of the client device or the client device.
  • the message to be authenticated may also have added additional variables, such as a time or random variables, in order to increase the security of the method.
  • the client device and the trust device are data processing systems and in particular special ones
  • Data processing equipment used in medical technology including medical equipment, workstations, storage and archiving systems, diagnostic systems, imaging equipment, etc.
  • the authentication for the clinical-medical area and for the used there Devices is designed. Since the medical devices usually require a specific data input and output interface, authentication systems for these devices are usually not used or can only be used to a limited extent.
  • client device and / or trust device are embedded in a medical network and serve to exchange medical data according to the DICOM protocol. Alternatively or cumulatively, other protocols can be used here, for example when exchanging beyond the hospital boundaries (for example via the Internet, eg with the http / s protocol).
  • the client device and the trust device are adapted for use in an authentication system according to the accompanying claim 1.
  • the client device comprises an encryption unit and a packaging module;
  • the trust device in the preferred embodiment comprises an encryption generator, a memory device, a transmission component, a validation component with memory access means, a reference encryption unit and a comparator.
  • the authentication method according to the invention is divided into two phases or time segments:
  • An initialization phase which basically has to be executed only once for each client or for each client device.
  • the initialization phase includes the
  • the initialization phase is executed exclusively on the trust device and precedes the actual authentication. This initial, first authentication is usually done by an administrator or automated performed by a central instance. It is basically only executed once on the basis of client addresses (eg IP address or MAC address (media access control address, the backup layer of the ISO OSI layer model) or based on a symbolic host name) or other technical characteristics of the client that are considered unique at the time of initialization.
  • client addresses eg IP address or MAC address (media access control address, the backup layer of the ISO OSI layer model) or based on a symbolic host name
  • An authentication phase This phase is executed both on the client and on the trust device and is characterized by the execution of all remaining steps of the method, ie in particular of all steps which are not assigned to the initialization phase (as described above). Authentication is typically performed multiple times and can be applied to selected or all messages that need to be exchanged between the client device and the trust device. With the subdivision of the authentication process in two phases, in an initialization phase and in an authentication phase, it becomes possible to make the authentication process even more efficient, in which the initialization phase is, as it were, pre-stored or swapped out and also by another user (eg an administrator ) can be operated. Thus, the user can be relieved of additional authentication measures on the client device and / or trust device.
  • An essential feature and an added advantage of the authentication method is that the authentication is performed without a separate certification authority. In other words, there is no need to provide a certification unit that has to be integrated into the network in addition to the client device and the trust device in order, for example, to manage the keys.
  • the authentication method according to the invention can be carried out much more flexible, since spontaneous to a trust device Without further preparation a variety of different clients can be connected.
  • the administration of the keys and the storage of the assignment relations takes place in the trust device.
  • the trust device can also be designed as a central server. Alternatively, the trust device may interact with outsourced modules over a network. It is thus possible, for example, for the individual components of the trust device (encryption generator, memory, transmission component, validation component) to be swapped out on one or more separate instances associated with the
  • Trust device in data exchange stand it is preferred that the aforementioned modules of the trust device are integrated or embedded in the trust device.
  • Symmetric encryption techniques are known in the art, especially DES, 3DES, AES (Rijndael), IDEA, CAST, FEAL, Blowfish, Twofish, Mars, RC2, RC5, RC6, Serpent, Skipjack. (See also: Wolfgang Ertel: Applied Cryptography, Carl Hanser Verlag, pp. 68-75, p.94 and Federal Office for Information Security: IT-Grundschutz, M 3.23 Introduction to cryptographic basic concepts, available at:
  • two encryption means are used in the authentication process, an encryption means and a reference encryption means.
  • the encryption means may be a collision-resistant encryption function and / or a one-way hash function.
  • a one-way hash function it becomes virtually impossible to find the appropriate input value for a given output value, which the hash function maps to the output value.
  • a one-way hash function for example, is known from Christoph Rueland: Information Security in Data Networks; DATACOM publishing house; Bergheim, 1993; ISBN 3-89238-081-3; Page 68ff.
  • the disposable function is preferably designed so that they are relatively easy to calculate in one direction, but very difficult in the other direction.
  • the encryption means is designed as a cryptographic hash function which is collision-resistant and / or a one-way function. Basically, a hash function maps a string of arbitrary length to a string of lesser length.
  • collision resistance means that it is also practically impossible to find a different value X 'giving the same hash value for a given value X.
  • a strong collision resistance is chosen for the encryption means, but so it is possible here to provide only a weak collision resistance, in which the two messages or input values of the hash function may be freely selected.
  • the encryption means further comprises additional cryptographic methods to increase security.
  • an extracting function is first applied to the client on the generated message.
  • the extract function serves to reduce the amount of data so that the extract has a shorter length than the original source.
  • the extraction function is a detachment of individual bits from the bit sequence of the message.
  • all non-injective functions can be used for extracting, wherein preferably all possible values of the result type are used equally frequently as function values, ie eg 256 equally frequent results with an 8-bit result length.
  • the encryption means is applied to the extracted message and then in the authentication packet to the trust device transferred to the authenticity check. This allows the authentication process to run even faster.
  • the encryption means is always client device-specific. Thus, there is a one-to-one correspondence between client device and encryption means. This assignment is stored on the trust device.
  • the encryption means is a concatenation of an encryption function and an extraction function. In other words, the encryption means describes a function that first extracts a message and then encrypts it.
  • the encryption means is transmitted as an executable application file (for example in standardized Internet protocols marked with a standardized "Content-Type" "MIME appication / ") from the trust device to the client device.
  • the client does not have to be trained specifically and will not perform any preparatory installation.
  • the application file is used to implement a encryption unit and a packaging module on the client. This allows any device that has a corresponding network connection to the trust device to be used for authentication. The process is thus very flexible. For example, mobile client devices (such as handhelds, smartphones, tablet PCs, etc.) may also be used for authentication on the trust device.
  • n trust device with:
  • a memory module which is intended to store an association between the respective client (device) and the encryption means generated for it
  • a validation component intended to validate the authenticity of the client, comprising:
  • a reference encryption unit intended to apply the determined encryption means to the received message for calculation of a reference-encrypted message.
  • an encryption unit intended to apply the received encryption means to a message for computing an encrypted message
  • a packetization module intended to generate an authentication packet comprising the
  • the encrypted message and a client address and which is further intended to send the authentication packet to the trust device.
  • the client and the trust device are preferably computers, computer nodes or a network of several network computers of a medical system for exchanging medical data.
  • the data is forwarded within an internal hospital network. Since the security risk within the internal clinical network is not so high compared to the scenario in which the data is sent externally, compliance with a mid-level security standard is sufficient. However, this means that possible attacks within the clinical system that are aimed at the content of the messages exchanged in the communication system or at the addresses of the communication partners can not be excluded.
  • the authentication system is designed to execute the authentication method according to the appended method claim.
  • the trust device for this purpose comprises the encryption generator, the memory module, the transmission component and the validation component with the further units and means.
  • the memory module can be designed, for example, can be stored and provided on a separate instance that is in (otherwise secured) data exchange with the trust device.
  • the client is formed with the encryption unit and the packaging module.
  • Another task solution consists in a client with an encryption unit and a packaging module for use in an authentication system according to the enclosed authentication claim.
  • Another task solution consists in a trust device with an encryption generator, a memory module, a transmission component and a validation component for use in an authentication system according to the enclosed claim.
  • the authentication method or the authentication system is used for authentication in the programming of control units for medical equipment.
  • Medical facilities are, for example, complex magnetic resonance tomographs, computer tomographs, positron emission tomographs, ultrasound devices or other imaging apparatuses.
  • Other medical IT systems also include patient-mounted sensors or interactive sensing devices operated by healthcare professionals or patients.
  • the method with the individual method steps or the units of the client device and the trust device can also be described as so-called "embedded
  • the method is used to store, process and forward processed data (in the form of authenticated data records) that are transmitted to other instances via a device network.
  • data records and device addresses are modified by transmitting authentication information with the actual signal or with the data record or the device address.
  • the present invention serves the security of the entire system and takes into account the conditions of the data processing system in which the data sets and executable files to be transmitted are made authenticated without a central certification authority having to be implemented.
  • the message, an encrypted form of the message, and the encryption means itself are represented as sequences of bits.
  • a particular advantage of the authentication method or system according to the invention is that the initialization phase has to be executed only once, while the subsequent method steps are executed for each message from the client to the trust device. This means that the process can be carried out very flexibly and efficiently, since the more complex and computationally intensive process for key generation and key dispatch can be summarized, encapsulated and carried out in advance, as it were.
  • the initialization phase can be decoupled in time from the authentication and executed at any time prior to authentication.
  • the authentication according to the invention is based on the fact that prior to the execution of the initialization phase, the respective client receives an opportunity to register with the trust device via another (secure) channel, so to speak as an authentication partner.
  • the additional channel may be, for example, another (secure) data line, another communication channel (telephone, SMS, mail, etc.).
  • This feature proves to be particularly in part for medical-clinical processes in which a large number of (often different) communication partners interact.
  • the administrative burden which is associated with the provision of a certification authority in the case of solutions known from the prior art, does not apply to the invented solution described here.
  • the same key is used as encryption means for decrypting and encrypting. It is therefore a symmetric encryption method.
  • the use of a symmetric algorithm offers the advantage of a high data throughput.
  • a one-way hash function can be sent from the Truster to the client as encryption means.
  • An alternative task solution also exists in a computer program with computer program code for performing all method steps of the claimed method or method described above when the computer program is executed on the computer.
  • the computer program can also be stored on a machine-readable storage medium.
  • An alternative task solution provides a storage medium, which is intended for storing the above-described, computer-implemented method and is readable by a computer. It is within the scope of the invention that not all steps of the method necessarily have to be executed on one and the same computer instance (client device, trust device), but they can also be executed on different computer instances. Also, sometimes the sequence of process steps may be varied.
  • a client or a client device C communicates with a trust device T.
  • client C and trust device T are connected via a network connection NW connected.
  • Client C and trust device T are integrated into an overall system as parts of a medical technology system, for example a clinic-internal network.
  • client C and trust device T can also be part of a complex imaging system (eg MRT).
  • the trust device T comprises an encryption generator G, a memory module 10, a validation component V.
  • the validation component V serves to validate the authenticity of the client C. It comprises memory access means VI, a reference encryption unit V2, a comparator V3.
  • all of the above modules are implemented directly in the trust device. Alternatively, individual modules can also be outsourced.
  • the client comprises an encryption unit K and a packaging module PM.
  • the encryption unit K serves to apply an encryption means key received from the trust device T to a message N generated on the client in order to generate an encrypted message X therefrom.
  • the packetization module PM is now used to generate an authentication packet P.
  • the authentication packet P comprises the message N, the encrypted message X and a client address A uniquely assigned for the client C or for the client device.
  • the authentication packet P is sent to the trust device T.
  • the communication partners are explained in more detail with the exchanged data sets.
  • the memory module 10 is not directly integrated in the trust device T but is provided as a separate entity which is securely connected to the trust device T via a corresponding data bus or via a protocol.
  • a client specific encryption means key on the trust device T generated.
  • the encryption means is an encryption function, eg a one-way hash function or a symmetric key of a cryptographic procedure, which can be stored as an executable computer program in a memory module (eg in the memory module 10 or in other memories of the trust device T).
  • the encryption means is stored in the memory 10 with an association with the respective client C for which it was generated. As indicated in FIG. 2 by the arrow pointing to the client C by the trust device T, which bears the reference symbol "keyO", the generated encryption means key is then sent to the client.
  • This step completes the initialization phase of the authentication process. Thereupon, any message which is generated on the client C and is to be sent to the trust device T can be validated for authenticity on the trust device T.
  • the message N is generated on the client C. Subsequently, the received encryption means key is applied to this message N to generate an encrypted message X.
  • the encrypted message X is then sent with further data records in an authentication packet P from the client C to the trust device T.
  • the authentication packet P comprises the message N, the encrypted message X and the client address A. This is indicated in FIG. 2 by the lower arrow which is directed by the client device C to the trust device T and denoted by the reference symbol. ⁇ , ⁇ , ⁇ ) ".
  • the trust device T can verify the authenticity of the sending client C by the following steps: First, the authentication packet P becomes the
  • Client address A removed.
  • the client address A is used to access the memory 10 to determine from the memory 10 for this address or for this client-specific encryption means key.
  • the encryption means key thus determined is applied to the received message N 1 (ie to the message N which the trust device T has received from the client C with the authentication packet P) reference-encrypted message X '.
  • a comparison between the reference-encrypted message X 'and the received, encrypted message X from the authentication packet P can be carried out on the trust device T. If the reference-encrypted message X 'coincides identically with the received, encrypted message X, the respective client C on the trust device T is considered authenticated.
  • an encryption function is generated in the initialization phase on the trust device T, which is provided both on the trust device T and on the client.
  • this encryption function is then applied to the client, and in an authentication packet P the encryption result is sent to the trust device T with further identification data.
  • the trust device T can then apply this key again, with access to its own (privately stored) key, in order to carry out, as it were, a comparison encryption (or reference encryption).
  • a comparison encryption or reference encryption
  • an initialization phase follows, which is designated by the reference symbol "ADMIN / INITIAL" in Figure 3. This designation is intended to indicate that the initialization phase can usually be performed by an administrator and is upstream of the actual authentication immediately precede the authentication and is always executed for a client C only once.
  • the initialization phase comprises the generation 1 of the client-specific encryption means key, the storage 2 of the encryption means key in the memory 10 with the assignment to the respective client C (using the respective client address A) and the sending 3 of the encryption means key to the client C.
  • the initialization phase thus comprises steps 1, 2 and 3.
  • the actual authentication comprises the following steps:
  • the client C can key to the message N to calculate the encrypted message X.
  • the method step of calculating is denoted by reference numeral 4.
  • the client C generates the authentication packet P, comprising the message N, the encrypted message X and the client address A, to the trust device T.
  • the process of sending bears the reference numeral 5.
  • step 6.1 the client-specific encryption means key is determined by accessing the memory 10. The access takes place with the client address A, which has been received with the authentication packet P on the trust device.
  • the determined encryption means key is then applied in step 6.2 to the received message N 1 for the calculation of the reference-encrypted message X '.
  • step 6.3 a comparison between the reference-encrypted message X 'and the received encrypted message X from the authentication packet P can be performed. If the reference-encrypted message X 'matches the encrypted message X identically, the client C on the trust device T is considered authenticated.
  • the instances are marked on the left side (trust device T / client C) on which the respective method steps are carried out.
  • individual process steps can also be outsourced to other modules.
  • no central certification authority is necessary in order to manage the encryption means key of the clients C.
  • the storage of the encryption means key is only provided on the trust device T itself.
  • a hash function is commonly used as the encryption means key.
  • Other embodiments provide here other cryptographic key, but have the following characteristics:
  • the encryption function serves to reduce the generated bit length of the encryption text.
  • different hash functions are generated in a systemic manner using a symmetric encryption procedure that is used in place of the hash function.
  • the key is thus the same on the client C and the trust device T.
  • the trust device T requests additional (external) means which ensure the authenticity of the client C (eg via a separate communication channel).
  • additional (external) means which ensure the authenticity of the client C (eg via a separate communication channel).
  • a secure key key is generated and communicated to the client device C.
  • the client device C securely stores the received key key in a secure memory.
  • the trust device T manages a list of associations between client address (as identity) A and encryption means key in pairs in the memory 10. Once a new key key for a client C has been generated, this pair (A, key) is put into the memory 10 added.
  • the trust device T can check every message N of the client C for authenticity.
  • the client device C extracts a defined section from the message N.
  • a significant advantage of the method is the dependence of X on the message N and the secret key key, whereby intercepting third parties can not replicate the authentication means X.
  • This section is called the extraction section and is generated by an extract function ext.
  • the extraction result (after application of the extraction function ext) is encrypted with the encryption means key and the resulting encrypted message X is transmitted together with the client identity A and the generated message N to the trust device T.
  • the trust device T can then verify the authenticity of the sending client C each time, if any
  • Authentication packet P from the client on the trust device T could be received.
  • a look-up is executed in the memory 10 in order to find the key key associated with the respective send address / identity A of the client C.
  • the encrypted message X can then be decrypted and the result compared with the extracted portion of the received record for correspondence. If the comparison indicates a match, the sending client C is considered authenticated.
  • the message X encoded on the client C of the message N is defined by the following function.
  • X key (ext (N))
  • the following calculation is carried out on the trust device T, comprising a decryption with the key key accessed from the memory 10.
  • the claimed identity A of the client C (received by the authentication packet P) is stored on the trust device T used to retrieve the identity-specific key key from the memory 10 and then apply to the received message the same steps that the client C has applied, so first the
  • Extract function ext to generate the extracted message N ext and then decrypt with the same encryption means key. If the result matches, the client C is considered authenticated.
  • the extraction function ext has the same properties as the encryption means key, and in particular is fast to calculate, difficult or impossible to reverse and injective.
  • the extraction function ext must be arranged in advance between client C and trust device T.
  • the algorithms for calculating the extraction function ext and the encryption means key are used in combination, e.g. when
  • Embodiment is thus a mobile software with integrated algorithms sent by trust device T to the client C.
  • it is no longer necessary for client C and trust device T to agree in advance on the procedure to be used.
  • the respective application for calculating key (ext (N)) is used both on the client side and on the trust side.
  • the two calculation rules, namely the extraction function ext and the encryption means key are implemented as concatenation.
  • the trust device T also stores the mobile software application (eg as a standardized "app") in addition to the association between client identity A and client-specific encryption means key.
  • an extension of the authentication scheme described above may be used.
  • the client C extracts a defined section of the generated message N and encodes it with the secure encryption means key and, as already described above, transmits it to the trust device T as part of the authentication packet P.
  • the trust device T then returns one Access to the memory module 10 to read out the client-specific key (address A of the client C) the client-specific key from the list and decrypt the defined section and compare the result with the component of the authentication package P to match.
  • another extension of the authentication scheme described above may be used to protect against eavesdropping. For this purpose, as an execution of the encryption function key (), the input value is modified such that a random variable or a time stamp is added. All components and steps of the
  • Procedures remain as described above.
  • the encrypted time or random number in the encrypted form X it is avoided that (in the case of client devices C in particular, the values of simple sensors) also have the same values for the encrypted form X due to repeatedly repeated identical values for a message N. be transmitted as part of the authentication P through the connection to the trust device T and be replicable for third parties.
  • a particular advantage of the solution according to the invention is the fact that it is possible to dispense with a public-key infrastructure. In this way, the authentication system can be made much more flexible and simpler and also more cost-effective. For authentication, therefore, it is no longer necessary to access a central instance (certification authority) in order to validate the identity of a client C.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Storage Device Security (AREA)

Abstract

Die Erfindung betrifft ein Authentifizierungsverfahren für eine medizintechnische Anlage. Mit diesem Authentifizierungsverfahren ist es möglich, Nachrichten (N) eines Client (C) auf einem Trustgerät (T) zu authentifizieren, ohne dass eine Public-key-lnfrastruktur implementiert werden muss. Dazu wird in einer Initialisierungsphase für einen Client (C) jeweils einmalig ein Verschlüsselungsmittel (key) zwischen Trustgerät (T) und Client (C) ausgetauscht. In der Authentifizierungsphase erzeugt der Client (C) aus einer Nachricht (N) ein Authentifizierungspaket (P), das an das Trustgerät (T) gesendet wird. Das Trustgerät (T) empfängt das Authentifizierungspaket (P) und ermittelt das Verschlüsselungsmittel (key), das dem jeweiligen Client (C) zugeordnet ist. Daraufhin wird das Verschlüsselungsmittel (key) auf die behauptete Identität des Client (C) angewendet, um eine referenzverschlüsselte Nachricht (Χ') zu erzeugen und mit der empfangenen, verschlüsselten Nachricht (X) auf Übereinstimmung zu vergleichen. Bei Übereinstimmung gilt der Client (C) als authentifiziert.

Description

Beschreibung
Authentifizierung von medizinischen Clientgeräten in einem Geräteverbund
Die vorliegende Erfindung betrifft ein Authentifizierungssys- tem, ein Clientgerät, ein Trustgerät und ein Verfahren zur Authentifizierung eines medizinischen Clientgerätes an einem Trustgerät in einem Geräteverbund, sowie ein Computerpro- grammprodukt .
Die vorliegende Erfindung liegt damit auf den Gebieten der Informations- und Netzwerk-Technologie und der Medizintechnik und hat zum Ziel, einen Anwender eines Clientgerätes und/oder das jeweilige Clientgerät bei einem Kommunikationspartner zu authentifizieren. Dabei geht es darum, dass zunächst der Client seine Identität nur behauptet und durch das Mittel der Authentisierung diese Behauptung gegenüber dem Kommunikationspartner (in diesem Fall: von dem Trustgerät) nachgewiesen kann .
Im Stand der Technik sind zur Authentifizierung drei grundlegende Ansätze bekannt: Zum einen gibt es die Wissensbasierte Authentifizierung (beide Kommunikationspartner wis- sen etwas, z.B. eine PIN, ein Passwort etc.), eine Besitzbasierte Authentifizierung (zumindest ein Kommunikationspartner besitzt etwas, z.B. eine Chipkarte, einen physikalischen Schlüssel etc.) oder eine Merkmals-basierte Authentifizierung, wie z.B. eine biometrische Authentifizierung, Fingerab- druck, Iriserkennung etc. Die vorliegende Erfindung basiert auf einer Wissens-basierten Authentifizierung und insbesondere auf einem symmetrischen Verschlüsselungsverfahren.
Im Bereich der Medizintechnik werden zum Datenaustausch Com- puternetze eingesetzt, die üblicherweise über ein Client- Server-Netzwerk gemäß unterschiedlichen Protokollen (z.B. DICOM - Digital Imaging and Communications in Medicine) kommunizieren. So interagiert beispielsweise eine Workstation bzw. ein Computer zur Datenakquisition eines Magnetresonanz - tomographen („MRT") mit einem Client, der als Befundungsstation an einem entfernten Ort (z.B. in einer externen Arztpraxis) positioniert sein kann. Um die medizinischen und damit auch zu schützenden medizinischen Daten auszutauschen, muss sich der Client bei seinem Kommunikationspartner (in diesem Fall z.B. einem MRT-Server) authentisieren .
Ein anderes Anwendungsszenario betrifft mobile medizinische Geräte ( intrakorporal oder extrakorporal) , wie beispielsweise Herzschrittmacher, Blutdruckmessgeräte, Sensorgeräte etc., die die erfassten Daten an andere medizinische Geräte (z.B. einem zentralen Server) senden und weitere Daten mit diesen austauschen. Auch hierbei müssen sich die Kommunikationspart- ner gegenseitig authentisieren bzw. authentifizieren.
Asymmetrische Kryptosysteme , die auf der Verwendung von öffentlichen und privaten Schlüsseln basieren, erfordern immer eine zentrale Instanz, um die im Einsatz befindlichen Schlüs- sei zu verwalten, zuzuweisen und vorzuhalten.
Im Stand der Technik war es bisher bekannt, asymmetrische Verschlüsselungsverfahren einzusetzen, umfassend ein Schlüsselpaar von unterschiedlichen Schlüsseln zur Verschlüsselung und zum Entschlüsseln. Das, bei einem asymmetrischen Krypto- system (auch Public-Key-System genannt) verwendete Schlüsselpaar wird auch als privater und öffentlicher Schlüssel bezeichnet. Gemäß einer ersten Gruppe von Authentifizierungssystemen werden der geheime (oder private) Schlüssel zur Ver- Schlüsselung und der öffentliche Schlüssel zur Authentifizierung bzw. zur Entschlüsselung verwendet.
Möchte nun ein Empfänger einer Nachricht die Identität des Senders der Nachricht authentifizieren, so ist es bei dieser Art von asymmetrischen Authentifizierungssystemen des Standes der Technik vorgesehen, dass der Empfänger eine sogenannte senderverschlüsselte Signatur entschlüsselt, die er zusammen mit der Nachricht vom Sender empfangen hat. Dazu verwendet er den öffentlichen Entschlüsselungsschlüssel des Senders. Die Verwaltung des öffentlichen Schlüssels erfolgt durch eine Zertifizierungsinstanz (Third-Party-Trustee) . Die beiden Kommunikationspartner interagieren somit immer zwangsläufig mit der Zertifizierungsinstanz. Das Ergebnis des Entschlüsselungsvorganges wird mit der empfängerseitig nachgebildeten Signatur verglichen. Diese Signatur ist die Identität des Senders oder eine mathematische Abbildung davon. Dazu können die Adresse des Senders und optional noch weitere Daten ver- wendet werden. Falls die beiden Ergebnisse übereinstimmen, gilt der Sender beim Empfänger als authentifiziert.
Eine weitere Gruppe von bekannten asymmetrischen Authentifi - zierungssystemen besteht darin, einen client-spezifischen Entschlüsselungsschlüssel geheim bzw. privat beim Client zu halten und den dazugehörigen Verschlüsselungsschlüssel öffentlich vorzuhalten. Die Verwaltung des öffentlichen Schlüssels erfolgt durch eine Zertifizierungsinstanz. Auch hier interagieren die beiden Kommunikationspartner somit immer zwangsläufig mit der Zertifizierungsinstanz. Bei diesem Ansatz verschlüsselt der Empfänger ein sogenanntes Geheimnis (in der Regel eine zufallserzeugte Zahl) mit dem öffentlichen Schlüssel des Clients und sendet die resultierende „Challen- ge" an den Client. Daraufhin authentisiert der Client seine Nachricht an den Empfänger, indem er die Signatur mit dem geheimen Schlüssel entschlüsselt und die resultierende „Response" mit der Nachricht an den Empfänger sendet. Der Empfänger authentifiziert den Client, indem er diese entschlüsselte „Response" mit dem originalen Geheimnis auf Übereinstimmung vergleicht.
Bei beiden vorstehend erwähnten Verfahren aus dem Stand der Technik erweist es sich als nachteilig, dass stets eine dritte Partei als Zertifizierungsinstanz notwendig ist, um die öffentlichen Schlüssel zu verwalten. Insbesondere im medizintechnischen Umfeld ist dies hinderlich, da dies zum Einen einen erhöhten Verwaltungsaufwand bedeutet und auch in der klinischen Praxis zu einem Zeitnachteil führt, da Zugriffe auf externe dritte Instanzen ausgeführt werden müssen, um eine Authentifizierung durchführen zu können, die erforderlich ist, um überhaupt auf die medizinisch relevanten Datensätze zugreifen zu können. Da es im medizinischen Umfeld viele An- wendungsfälle gibt, die sehr zeitkritisch sind (beispielsweise in der Intensivmedizin) ist dieser Nachteil nicht tragbar.
Die vorliegende Erfindung hat sich deshalb zur Aufgabe gestellt, ein Authentifizierungssystem mit einem Clientgerät und mit einem Trustgerät, sowie ein Verfahren zur Authentifizierung und ein Computerprogrammprodukt bereitzustellen, das die vorstehend erwähnten Nachteile überwindet und nicht mehr den Einsatz einer Zertifizierungsinstanz erfordert. Des Weiteren soll das vorgeschlagene Authentifizierungssystem die Möglichkeit bieten, dass sich ein Client jeweils gegenüber einer Vielzahl von Empfangsgeräten bzw. Trustgeräten authen- tisiert. Darüber hinaus soll der Authentifizierungsvorgang verkürzt und einfacher ausgeführt werden. Die vorstehende Aufgabe wird durch die beiliegenden nebengeordneten Patentansprüche gelöst, insbesondere durch ein Authentifizierungssystem, ein Clientgerät, ein Trustgerät, ein Verfahren zur Authentifizierung und ein Computerprogrammprodukt. Vorteilhafte Weiterbildungen der Erfindung finden sich in den Unteransprüchen.
Im Folgenden wird die Erfindung anhand des Verfahrens beschrieben. Hierbei erwähnte Ausführungsformen, alternative Lösungen, weitere Merkmale und Vorteile sind ebenso auch auf die anderen Anspruchsformen zu übertragen (also auf das
Client- oder Trustgerät, auf das System oder das Programm) und umgekehrt. Demnach können auch die Merkmale, die im Zusammenhang mit dem Verfahren beansprucht und/oder beschrieben sind, auch auf das System, die Geräte oder das Produkt ange- wendet werden und umgekehrt. Dabei sind die jeweiligen funktionalen Merkmale des Verfahrens durch entsprechende Mikroprozessorbausteine, Speichermodule oder Hardwareeinheiten implementiert, die jeweils dazu ausgebildet sind, die Funktionalität zu übernehmen.
Gemäß einem Aspekt bezieht sich die Erfindung auf ein Verfah- ren zur Authentifizierung eines Client an einem Trustgerät, wobei das Verfahren folgende Verfahrensschritte umfasst:
- Seitens des Trustgerätes: Initialisieren der Authentifizierung durch folgende Schritte:
- Erzeugen eines client-spezifischen Verschlüsselungsmittels auf dem Trustgerät,
- Speichern des client-spezifischen Verschlüsselungsmittels in einem Speicher auf dem Trustgerät mit einer Zuordnung zwischen dem jeweiligen Client bzw. einer Clientadresse oder Client-
Identität und des für ihn erzeugten Verschlüsselungsmittels,
- Senden des erzeugten Verschlüsselungsmittels an dem Client
- Seitens des Client: Anwenden des empfangenen Verschlüsselungsmittels auf eine Nachricht zum Berechnen einer verschlüsselten Nachricht bzw. einer verschlüsselten Form der Nachricht.
- Seitens des Client: Versenden eines Authentifizie- rungspaketes , umfassend die Nachricht, die verschlüsselte (Form der) Nachricht und eine Clientadresse an das Trustgerät.
- Seitens des Trustgerätes: Validieren der Authentizität des Client durch folgende Schritte:
- Ermitteln des client-spezifischen Verschlüsselungsmittels durch Zugriff auf den Speicher, das jeweils in der empfangenen Clientadresse, vorzugsweise eineindeutig, zugeordnet ist.
- Anwenden des ermittelten Verschlüsselungsmittels auf die empfangene Nachricht zum Berechnen einer referenzverschlüsselten Nachricht .
- Vergleich der referenzverschlüsselten Nachricht mit der empfangenen verschlüsselten Nachricht aus dem Authentifizierungspaket auf Identität und bei Identität:
- Authentifizieren des Client auf dem Trustgerät.
Im Folgenden werden die im Rahmen dieser Anmeldung verwendeten Begrifflichkeiten näher erläutert. Grundsätzlich können alle der in dieser Beschreibung erläuterten Aspekte, Merkmale und Ausführungsformen der Erfindung auch kombiniert werden. Der Begriff Authentifizierung bezieht sich auf den Nachweis der Identität des Senders beim Empfänger in einem computergestützten klinischen Netzwerk, das Daten über ein Bussystem oder ein Netzwerk (vorzugsweise DICOM) austauscht. Die
Authentifizierung erfolgt automatisch und somit ohne die Not- wendigkeit von Benutzereingaben. Die Authentifizierung basiert vorzugsweise auf einer symmetrischen Verschlüsselung. Desweiteren kann die Authentifizierung ausgeführt werden, indem nur Sender (Client) und Empfänger (Trustgerät) miteinander in Datenaustausch stehen und ohne den Zugriff auf eine dritte Zertifizierungsinstanz. Die Authentifizierung kann zum Nachweis der Identität (Verwendung zum Identitätsnachweis) des Client als Anwender des Clientgerätes oder des Clientgerätes verwendet werden. In einer weiteren Ausführungsform ist es ebenso möglich, Nachrichten oder Nachrichtenkonvolute zu authentifizieren, die von einem Clientgerät gesendet werden (Verwendung zum Herkunftsnachweis) . Dabei können der zu authentifizierenden Nachricht auch noch weitere Variablen, wie etwa eine Zeitangabe oder Zufallsgrößen, hinzugefügt sein, um die Sicherheit des Verfahrens zu erhöhen.
Bei dem Clientgerät und bei dem Trustgerät handelt es sich um Datenverarbeitungsanlagen und insbesondere um spezielle
Datenverarbeitungsanlagen, die in der Medizintechnik zum Einsatz kommen (diese umfassen medizintechnische Anlagen, Work- stations, Speicher- und Archivierungssysteme, Befundungssysteme, bildgebende Anlagen etc.) . An dieser Stelle sei speziell darauf hingewiesen, dass die Authentifizierung für den klinisch-medizinischen Bereich und für die dort eingesetzten Geräte ausgelegt ist. Da die medizinischen Geräte in der Regel eine spezifische Datenein- und ausgabeschnittstelle erfordern, werden Authentifizierungssysteme für diese Geräte bislang in der Regel nicht eingesetzt oder können nur be- schränkt verwendet werden. In einer bevorzugten Ausführungs- form sind Clientgerät und/oder Trustgerät in ein medizinisches Netzwerk eingebettet und dienen zum Austausch von medizinischen Daten nach dem DICOM-Protokoll . Alternativ oder kumulativ können hier noch andere Protokolle verwendet werden, beispielsweise beim Austausch über die Klinikgrenzen hinaus, (beispielsweise über das Internet, z.B. mit dem http/s-Proto- koll) . Das Clientgerät und das Trustgerät sind zum Einsatz in einem Authentifizierungssystem gemäß beiliegendem Anspruch 1 ausgebildet. Das Clientgerät umfasst eine Verschlüsselungs- einheit und ein Paketierungsmodul ; das Trustgerät umfasst in der bevorzugten Ausführungsform einen Verschlüsselungsgenerator, einen Speicherbaustein, eine Sendekomponente, eine Validierungskomponente mit Speicherzugriffsmitteln, einer Referenzverschlüsselungseinheit und einem Komparator . Diese Bau- steine werden später unter Bezugnahme auf das Authentifizierungssystem näher erläutert.
Das erfindungsgemäße Authentifizierungsverfahren gliedert sich in zwei Phasen bzw. Zeitabschnitte:
1. Eine Initialisierungsphase, die grundsätzlich nur einmal für jeden Client bzw. für jedes Clientgerät ausgeführt werden muss. Die Initialisierungsphase umfasst die
Schritte: Erzeugen eines Verschlüsselungsmittels auf dem Trustgerät, Speichern des erzeugten Verschlüsselungsmittels mit einer Zuordnung des Verschlüsselungsmittels zu dem jeweiligen Client auf einem Speicher, der von dem Trustgerät zugreifbar ist und das Senden des erzeugten Verschlüsselungsmittels an den Client. Die Initialisie- rungsphase wird ausschließlich auf dem Trustgerät ausgeführt und ist der eigentlichen Authentifizierung vorgeschaltet. Diese initiale, erste Authentifizierung wird üblicherweise von einem Administrator oder automatisiert durch eine zentrale Instanz durchgeführt. Sie wird grundsätzlich nur einmal durchgeführt auf der Basis von Client-Adressen (z.B. IP-Adresse oder MAC-Adresse (Me- dia-Access-Control-Adresse, der Sicherungsschicht des ISO-OSI-Schichtenmodells) oder auf Basis eines symbolischen Rechnernamens) oder anderen technischen Merkmalen des Clients, die zum Zeitpunkt der Initialisierung als eindeutig gelten.
2. Eine Authentifizierungsphase . Diese Phase wird sowohl auf dem Client als auch auf dem Trustgerät ausgeführt und kennzeichnet sich durch die Ausführung aller restlichen Schritte des Verfahrens, also insbesondere aller Schritte, die nicht der Initialisierungsphase (wie vorstehend beschrieben) zugewiesen sind. Die Authentifizie- rung wird üblicherweise mehrfach durchgeführt und kann bei ausgewählten oder allen Nachrichten angewendet werden, die zwischen Clientgerät und Trustgerät ausgetauscht werden müssen. Mit der Unterteilung des Authentifizierungsverfahrens in zwei Phasen, in eine Initialisierungsphase und in eine Authentifi- zierungsphase wird es möglich, den Authentifizierungsvorgang noch effizienter zu gestalten, in dem die Initialisierungsphase sozusagen vor- bzw. ausgelagert wird und auch von einem anderen Anwender (z.B. einem Administrator) bedient werden kann. Damit kann der Anwender an dem Clientgerät und/oder Trustgerät von zusätzlichen Authentifizierungsmaßnahmen entlastet werden. Ein wesentliches Merkmal und ein zusätzlicher Vorteil des Authentifizierungsverfahrens sind darin zu sehen, dass das Authentifizieren ohne eine separate Zertifizierungsinstanz ausgeführt wird. Mit anderen Worten muss keine Zertifizierungseinheit bereitgestellt werden, die zusätzlich zum Clientgerät und zum Trustgerät in das Netzwerk eingebunden werden muss, um beispielsweise die Schlüssel zu verwalten. Damit kann das erfindungsgemäße Authentifizierungsverfahren wesentlich flexibler ausgeführt werden, da an ein Trustgerät auch spontan ohne weitere Vorbereitungsmaßnahmen eine Vielzahl von unterschiedlichen Clients angeschlossen werden können. Die Verwaltung der Schlüssel und die Speicherung der Zuordnungsrelationen erfolgt im Trustgerät. Das Trustgerät kann auch als zent- raier Server ausgebildet sein. Alternativ kann das Trustgerät mit ausgelagerten Modulen über ein Netzwerk interagieren . So ist es beispielsweise möglich, dass die einzelnen Bestandteile des Trustgerätes (Verschlüsselungsgenerator, Speicher, Sendekomponente, Validierungskomponente) auf einem oder auf mehreren separaten Instanzen ausgelagert wird, die mit dem
Trustgerät in Datenaustausch stehen. Bevorzugt ist es jedoch, dass die vorstehend genannten Module des Trustgerätes in das Trustgerät integriert oder eingebettet sind.
Wie vorstehend bereits erwähnt wird als Verschlüsselungsmittel ein symmetrisches Verschlüsselungsverfahren verwendet. Symmetrische Verschlüsselungsverfahren sind im Stand der Technik bekannt, speziell DES, 3DES, AES (Rijndael) , IDEA, CAST, FEAL, Blowfish, Twofish, Mars, RC2 , RC5, RC6 , Serpent, Skipjack. (Vgl. hierzu: Wolfgang Ertel : Angewandte Kryptographie, Carl Hanser Verlag, S. 68-75; S. 94 und Bundesamt für Sicherheit in der Informationstechnik: IT-Grundschutz, M 3.23 Einführung in kryptographische Grundbegriffe, abrufbar unter :
h1 ps://www.bsi.bund.de/ContentBSI/grundschutz/kataloge/rn/m03/m03023.hto .
Gemäß einem Aspekt werden zwei Verschlüsselungsmittel bei dem Authentifizierungsverfahren verwendet, ein Verschlüsselungsmittel und ein Referenzverschlüsselungsmittel. Vorzugsweise stimmen beide überein. Bei dem Verschlüsselungsmittel kann es sich um eine kollisionsresistente Verschlüsselungsfunktion und/oder um eine Einweg-Hashfunktion handeln. Mit einer Ein- weg-Hashfunktion wird es praktisch unmöglich, zu einem gegebenen Ausgabewert den dazugehörigen Eingabewert zu finden, den die Hashfunktion auf den Ausgabewert abbildet. Eine Einweg-Hashfunktion ist beispielsweise bekannt aus Christoph Ru- land: Informationssicherheit in Datennetzen; DATACOM-Verlag ; Bergheim, 1993; ISBN 3-89238-081-3; Seite 68ff. Die Einweg- funktion ist vorzugsweise so ausgebildet, dass sie in eine Richtung relativ leicht zu berechnen sind, aber in die andere Richtung sehr schwer. Mit anderen Worten kann in kurzer Zeit ein Ergebnis berechnet werden, das aber kaum oder nur sehr schwierig umzukehren ist. Gemäß einem Aspekt ist das Verschlüsselungsmittel als kryptographische Hashfunktion ausgebildet, die kollisionsresistent und/oder eine Einwegfunktion ist. Grundsätzlich bildet eine Hashfunktion eine Zeichenfolge beliebiger Länge auf eine Zeichenfolge mit geringerer Länge ab.
Der Begriff „Kollisionsresistenz" bedeutet, dass es ebenfalls praktisch unmöglich ist, für einen gegebenen Wert X einen davon unterschiedlichen Wert X' zu finden, der denselben Hash- wert ergibt. Vorzugsweise wird eine starke Kollisionsresistenz bei dem Verschlüsselungsmittel gewählt. Ebenso ist es jedoch auch möglich, hier nur eine schwache Kollisionsresistenz vorzusehen, bei der die beiden Nachrichten bzw. Eingabewerte der Hashfunktion frei gewählt werden dürfen.
Gemäß einem weiteren Aspekt der Erfindung umfasst das Verschlüsselungsmittel noch zusätzliche kryptographische Verfahren, um die Sicherheit zu erhöhen. Gemäß einem weiteren Aspekt der Erfindung ist es vorgesehen, dass auf dem Client zunächst auf die erzeugte Nachricht eine Extrahierungsfunktion angewendet wird. Die Extrahierungsfunk- tion dient dazu, die Datenmenge zu reduzieren, sodass das Extrakt eine geringere Länge hat, als die ursprüngliche Nach- rieht. Im einfachsten Fall handelt es sich bei der Extrahierungsfunktion um ein Herauslösen von einzelnen Bits aus der Bitfolge der Nachricht. Allgemein können zum Extrahieren alle nicht-injektiven Funktionen verwendet werden, wobei vorzugsweise als Funktionswerte alle möglichen Werte des Ergebnis- typs gleichhäufig verwendet werden, also z.B. 256 gleichhäufige Ergebnisse bei 8 Bit Ergebnislänge. Daraufhin wird das Verschlüsselungsmittel auf die extrahierte Nachricht angewendet und dann in dem Authentifizierungspaket an das Trustgerät zur Authentizitätsprüfung übertragen. Damit kann der Authentifizierungsvorgang noch schneller ausgeführt werden.
Gemäß einem Aspekt der vorliegenden Erfindung ist das Ver- schlüsselungsmittel stets Clientgeräte- spezifisch . Somit existiert eine eineindeutige Zuordnung zwischen Clientgerät und Verschlüsselungsmittel . Diese Zuordnung wird auf dem Trustgerät hinterlegt . Gemäß einem weiteren Aspekt der vorliegenden Erfindung ist das Verschlüsselungsmittel eine Konkatenation einer Verschlüsselungsfunktion und einer Extrahierungsfunktion . Mit anderen Worten beschreibt das Verschlüsselungsmittel eine Funktion, die zunächst eine Nachricht extrahiert und darauf- hin verschlüsselt.
Gemäß einem weiteren Aspekt der Erfindung ist es vorgesehen, dass das Verschlüsselungsmittel als ausführbare Applikationsdatei (beispielweise in standardisierten Internetprotokollen markiert mit einem standardisierten „Content-Type" „MIME app- lication/ ... " ) von dem Trustgerät an das Clientgerät übertragen wird. In diesem Fall muss der Client nicht spezifisch ausgebildet werden und keine vorbereitenden Installationsmaßnahmen ausführen. Die Applikationsdatei dient dazu, eine Ver- Schlüsselungseinheit und ein Paketierungsmodul auf dem Client zu implementieren. Damit kann jedes Gerät, das über eine entsprechende Netzwerkverbindung zum Trustgerät verfügt, zur Authentifizierung verwendet werden. Das Verfahren wird damit sehr flexibel. Beispielsweise können auch mobile Clientgeräte (wie z.B. Handheids, Smartphones, Tablet-PCs etc.) zur Authentifizierung auf dem Trustgerät verwendet werden.
Wie oben bereits erwähnt, besteht eine weitere Aufgabenlösung in einem Authentifizierungssystem zur Authentifizierung eines Client an einem Trustgerät, dessen Aufbau nachfolgend näher erläutert wird. Der Begriff „Client" und der Begriff „Clientgerät" werden in dieser Beschreibung häufig synonym verwendet. Der Begriff „Client" soll kennzeichnen, dass sich der jeweilige Rechner als Client eines Servers verhält, wobei das Trustgerät als Server ausgebildet sein kann. Selbstverständlich kann mit Hilfe des vorliegenden Authentifizierungsver- fahrens auch der Anwender des jeweiligen Clientgerätes, also die Person authentifiziert werden. Das System umfasst: n Trustgerät mit:
einem Verschlüsselungsgenerator, der dazu bestimmt ist, ein client-spezifisches Verschlüsselungsmittel zu erzeugen,
einem Speicherbaustein, der zur Speicherung einer Zuordnung zwischen dem jeweiligen Client (gerät) und des für ihn erzeugten Verschlüsselungsmittels bestimmt ist ,
einer Sendekomponente, die dazu bestimmt ist, das erzeugte Verschlüsselungsmittel an den Kommunikations- partner, hier: an den Client, zu senden,
einer Validierungskomponente, die dazu bestimmt ist, die Authentizität des Clients zu validieren, umfassend :
- Speicherzugriffsmittel, die dazu bestimmt sind, das client-spezifische Verschlüsselungsmittel durch Zugriff auf dem Speicherbaustein zu ermitteln, wobei der Zugriff auf dasjenige clientspezifische Verschlüsselungsmittel erfolgt, das jeweils einer vom Client empfangenen Clientadresse zugeordnet ist.
- Eine Referenzverschlüsselungseinheit, die dazu bestimmt ist, das ermittelte Verschlüsselungsmittel auf die empfangene Nachricht zur Berechnung einer referenzverschlüsselten Nachricht anzuwenden .
- Einem Komparator, der dazu bestimmt ist, ein
Authentifizierungspaket von dem Client zu empfangen und der weiterhin dazu bestimmt ist, die referenzverschlüsselte Nachricht mit einer empfangenen verschlüsselten Nachricht aus dem Authentifizierungspaket auf Identität zu verglei- chen und, der weiterhin dazu bestimmt ist, bei Identität dem Client auf dem Trustgerät zu authentifizieren .
- Einem Clientgerät mit:
- einer Verschlüsselungseinheit, die dazu bestimmt ist, das empfangene Verschlüsselungsmittel auf eine Nachricht zum Berechnen einer verschlüsselten Nachricht anzuwenden und
- einem Paketierungsmodul , das dazu bestimmt ist, ein Authentifizierungspaket zu erzeugen, umfassend die
Nachricht, die verschlüsselte Nachricht und eine Clientadresse und das weiterhin dazu bestimmt ist, das Authentifizierungspaket an das Trustgerät zu senden .
Bei dem Client und bei dem Trustgerät handelt es sich vorzugsweise um Rechner, Rechnerknoten oder ein Verbund von mehreren Netzwerkrechnern eines medizinischen Systems zum Austausch von medizinischen Daten. Üblicherweise werden dabei die Daten innerhalb eines internen Kliniknetzwerkes weitergeleitet. Da das Sicherheitsrisiko innerhalb des internen klinischen Netzwerkes nicht so hoch ist im Vergleich zu dem Szenario, bei dem die Daten extern versendet werden, genügt die Einhaltung von Sicherheitsvorschriften einer mittleren Ebene. Dies bedeutet allerdings, dass mögliche Angriffe innerhalb des klinischen Systems, die auf den Inhalt der im Kommunikationssystem ausgetauschten Nachrichten oder auf die Adressen der Kommunikationspartner abzielen, nicht ausgeschlossen werden können .
Gemäß einem Aspekt ist das Authentifizierungssystem zur Ausführung des Authentifizierungsverfahrens gemäß beiliegendem Verfahrensanspruch ausgebildet. In einer bevorzugten Ausführungsform umfasst das Trustgerät dazu den Verschlüsselungs- generator, den Speicherbaustein, die Sendekomponente und die Validierungskomponente mit den weiteren Einheiten und Mitteln. Es ist jedoch ebenso möglich, das Trustgerät einfacher auszubilden, so dass der Speicherbaustein beispielsweise aus- gelagert werden kann und auf einer separaten Instanz bereitgestellt wird, die in (anderweitig gesichertem) Datenaustausch mit dem Trustgerät steht. Desweiteren ist der Client mit der Verschlüsselungseinheit und dem Paketierungsmodul ausgebildet. Wie vorstehend bereits erwähnt, ist es jedoch auch möglich, das Verschlüsselungsmittel als Applikationsdatei an den Client zu übertragen, die dann die Funktionalität der Verschlüsselungseinheit und des Paketierungsmoduls übernimmt. Dann muss der Client keine weiteren Module und Bautei- le aufweisen, sondern es kann sich um einen beliebigen medizinischen Client handeln.
Eine weitere Aufgabenlösung besteht in einem Client mit einer Verschlüsselungseinheit und einem Paketierungsmodul zur An- wendung in einem Authentifizierungssystem nach beiliegendem Authentifizierungsanspruch .
Eine weitere Aufgabenlösung besteht in einem Trustgerät mit einem Verschlüsselungsgenerator, einem Speicherbaustein, ei- ner Sendekomponente und einer Validierungskomponente zur Anwendung in einem Authentifizierungssystem nach beiliegendem Anspruch .
An dieser Stelle sei darauf hingewiesen, dass das Authentifi- zierungsverfahren bzw. das Authentifizierungssystem zur Authentifizierung bei der Programmierung von Steuergeräten für medizintechnische Anlagen dient. Medizintechnische Anlagen sind beispielsweise komplexe Magnetresonanztomographen, Computertomographen, Positronen-Emissions-Tomographen, Ultra- schallgeräte oder andere bildgebende Apparate. Sonstige medizinische IT-Systeme umfassen auch patientengebundene Sensoren oder auch interaktive Erfassungsgeräte die von Heilberuflern oder Patienten bedient werden. Das Verfahren mit den einzelnen Verfahrensschritten bzw. die Einheiten des Clientgerätes und des Trustgerätes können auch als sogenanntes „embedded
System" (eingebettetes System) in die medizintechnische Anlage und/oder in einen medizintechnischen Steuerrechner und/- oder in einem sonstigen medizinischen IT-System eingebettet bzw. integriert sein. Das Verfahren dient der Speicherung, Verarbeitung und Weiterleitung von aufbereiteten Daten (in Form von authentifizierten Datensätzen) , die über ein Gerätenetzwerk an andere Instanzen übertragen werden. Dabei werden Datensätze und Geräteadressen modifiziert, indem eine Authen- tifizierungsinformation mit dem eigentlichen Signal bzw. mit dem Datensatz oder der Geräteadresse übertragen werden. Durch den speziellen Authentifizierungs- und Verschlüsselungsmechanismus dient die vorliegende Erfindung der Sicherheit der ge- samten Anlage und berücksichtigt die Gegebenheiten der Datenverarbeitungsanlage, in dem die zu übertragenen Datensätze und ausführbare Dateien authentifizierbar gemacht werden, ohne, dass eine zentrale Zertifizierungsinstanz implementiert werden muss. Die Nachricht, eine verschlüsselte Form der Nachricht und das Verschlüsselungsmittel selbst sind als Folge von Bits repräsentiert bzw. gespeichert.
Ein besonderer Vorteil des erfindungsgemäßen Authentifizie- rungsverfahrens bzw. -Systems ist darin zu sehen, dass die Initialisierungsphase nur einmal ausgeführt werden muss, während die nachfolgenden Verfahrensschritte für jede Nachricht des Client an das Trustgerät ausgeführt werden. Damit kann das Verfahren sehr flexibel und effizient ausgeführt werden, da der aufwändigere und rechenintensive Vorgang zur Schlüs- selgenerierung und Schlüsselversendung sozusagen zusammenge- fasst, gekapselt und im Vorfeld ausgeführt werden kann. Die Initialisierungsphase kann zeitlich von der Authentisierung entkoppelt werden und zu einem beliebigen Zeitpunkt vor der Authentisierung ausgeführt werden.
Gemäß einem Aspekt basiert die erfindungsgemäße Authentisierung darauf, dass vor der Ausführung der Initialisierungsphase der jeweilige Client eine Gelegenheit erhält, sich über einen anderen (sicheren) Kanal bei dem Trustgerät - sozusagen als Authentifizierungspartner - zu registrieren. Der zusätzliche Kanal kann beispielsweise eine andere (sichere) Datenleitung, ein anderer Kommunikationskanal (Telefon, SMS, Post etc.) sein. Dieses Merkmal erweist sich als besonders vor- teilhaft für medizinisch-klinische Prozesse, bei denen eine Vielzahl von (oft unterschiedlichen) Kommunikationspartnern interagieren . Der Verwaltungsaufwand, der bei aus dem Stand der Technik bekannten Lösungen mit der Vorhaltung einer Zer- tifizierungsinstanz verbunden ist, entfällt bei der hier beschriebenen, erfundenen Lösung. Vorzugsweise wird als Verschlüsselungsmittel zum Entschlüsseln und zum Verschlüsseln der gleiche Schlüssel verwendet. Es handelt sich somit um ein symmetrisches Verschlüsselungsverfahren. Die Verwendung eines symmetrischen Algorithmus' bietet den Vorteil eines hohen Datendurchsatzes .
Gemäß einer Variante der Erfindung kann als Verschlüsselungsmittel eine Einweg-Hashfunktion vom Truster an den Client ge- sendet werden. Alternativ ist es möglich, einen geheimen Schlüssel als Verschlüsselungsmittel zu versenden.
Die vorstehend beschriebenen, erfindungsgemäßen Ausführungsformen des Verfahrens können auch als Computerprogrammprodukt mit einem Computerprogramm ausgebildet sein, wobei der Computer zur Durchführung des oben beschriebenen, erfindungsgemäßen Verfahrens veranlasst wird, wenn das Computerprogramm auf dem Computer bzw. auf einem Prozessor des Computers ausgeführt wird.
Eine alternative Aufgabenlösung besteht auch in einem Computerprogramm mit Computer-Programmcode zur Durchführung aller Verfahrensschritte des beanspruchten oder oben beschriebenen Verfahrens, wenn das Computerprogramm auf dem Computer ausge- führt wird. Dabei kann das Computerprogramm auch auf einem maschinenlesbaren Speichermedium gespeichert sein.
Eine alternative Aufgabenlösung sieht ein Speichermedium vor, das zur Speicherung des vorstehend beschriebenen, computer- implementierten Verfahrens bestimmt ist und von einem Computer lesbar ist. Es liegt im Rahmen der Erfindung, dass nicht alle Schritte des Verfahrens zwangsläufig auf ein und derselben Computerinstanz (Clientgerät, Trustgerät) ausgeführt werden müssen, sondern sie können auch auf unterschiedlichen Computerinstanzen ausgeführt werden. Auch kann teilweise die Abfolge der Verfahrensschritte gegebenenfalls variiert werden.
Darüber hinaus ist es möglich, dass einzelne Abschnitte des vorstehend beschriebenen Verfahrens in einer verkaufsfähigen Einheit (z.B. Clientgerät) und die restlichen Komponenten in einer anderen verkaufsfähigen Einheit (z.B. Trustgerät) - sozusagen als verteiltes System - ausgeführt werden können.
In der folgenden detaillierten Figurenbeschreibung werden nicht einschränkend zu verstehende Ausführungsbeispiele mit deren Merkmalen und weiteren Vorteilen anhand der Zeichnung besprochen. In dieser zeigen: eine übersichtsartige Darstellung von den Kommunikationspartnern mit den jeweiligen Modulen entspre chend einer bevorzugten Ausführungsform der Erfindung, eine schematische Darstellung der ausgetauschten Datenpakete zwischen den Kommunikationspartnern entsprechend einer bevorzugten Ausführungsform der Erfindung und ein Ablaufdiagramm gemäß eines Authentifizierungs- verfahrens gemäß einem Ausführungsbeispiel.
Unter Bezugnahme auf die beiliegenden Figuren werden im Folgenden Ausführungsbeispiele des erfindungsgemäßen Authentifi- zierungsvorganges näher erläutert.
Wie in Figur 1 näher dargestellt, kommuniziert ein Client bzw. ein Clientgerät C mit einem Trustgerät T. Üblicherweise sind Client C und Trustgerät T über eine Netzwerkverbindung NW verbunden. Client C und Trustgerät T sind als Teile eines medizintechnischen Systems, beispielsweise eines klinikinternen Netzwerkes, in ein Gesamtsystem eingebunden. Desweiteren können Client C und Trustgerät T auch Teil einer komplexen bildgebenden Anlage (z.B. MRT) sein. Um das Authentifizie- rungsverfahren ausführen zu können, umfasst das Trustgerät T einen Verschlüsselungsgenerator G, einen Speicherbaustein 10, eine Validierungskomponente V. Die Validierungskomponente V dient dazu, die Authentizität des Clients C zu validieren. Sie umfasst Speicherzugriffsmittel VI, eine Referenzverschlüsselungseinheit V2 , einen Komparator V3. In der bevorzugten Ausführungsform sind alle der vorstehend genannten Module unmittelbar in das Trustgerät implementiert. Alternativ können einzelne Module auch ausgelagert werden.
Der Client umfasst eine Verschlüsselungseinheit K und ein Paketierungsmodul PM. Die Verschlüsselungseinheit K dient dazu, ein vom Trustgerät T empfangenes Verschlüsselungsmittel key auf eine auf dem Client generierte Nachricht N anzuwenden, um daraus eine verschlüsselte Nachricht X zu erzeugen. Das Pake- tierungsmodul PM dient nun dazu, ein Authentifizierungspaket P zu erzeugen. Das Authentifizierungspaket P umfasst die Nachricht N, die verschlüsselte Nachricht X und eine, für den Client C bzw. für das Clientgerät eineindeutig zugeordnete Clientadresse A. Das Authentifizierungspaket P wird an das Trustgerät T gesendet.
In Figur 2 werden die Kommunikationspartner mit den ausgetauschten Datensätzen nochmals näher erläutert. In der in Figur 2 dargestellten Ausführungsvariante ist der Speicherbaustein 10 nicht unmittelbar in das Trustgerät T integriert, sondern als separate Instanz bereitgestellt, die über einen entsprechenden Datenbus bzw. über ein Protokoll an das Trustgerät T sicher angeschlossen ist.
Zunächst wird in einer Initialisierungsphase, die der eigentlichen Authentifizierung vorgelagert sein kann und grundsätzlich nur einmal für jeden Client ausgeführt wird, ein client- spezifisches Verschlüsselungsmittel key auf dem Trustgerät T erzeugt. Bei dem Verschlüsselungsmittel handelt es sich um eine Verschlüsselungsfunktion, z.B. eine Einweg-Hashfunktion oder ein symmetrischer Schlüssel eines kryptographisehen Ver- fahrens, das als ausführbares Computerprogramm in einem Speicherbaustein (z.B. in den Speicherbaustein 10 oder in anderen Speichern des Trustgerätes T) hinterlegt sein kann.
Nach Erzeugung des client-spezifischen Verschlüsselungsmit- tels key wird das Verschlüsselungsmittel mit einer Zuordnung auf den jeweiligen Client C, für den es erzeugt wurde, in dem Speicher 10 abgelegt. Wie in Figur 2 durch den vom Trustgerät T auf den Client C weisenden Pfeil, der das Bezugszeichen „keyO" trägt, gekennzeichnet, wird daraufhin das erzeugte Verschlüsselungsmittel key an den Client gesendet.
Mit diesem Schritt ist die Initialisierungsphase des Authentifizierungsvorganges abgeschlossen. Daraufhin kann jede Nachricht, die am Client C erzeugt wird und an das Trustgerät T zu senden ist, auf dem Trustgerät T auf Authentizität validiert werden.
Dazu wird die Nachricht N auf dem Client C erzeugt. Daraufhin wird das empfangene Verschlüsselungsmittel key auf diese Nachricht N angewendet, um eine verschlüsselte Nachricht X zu generieren .
Daraufhin wird die verschlüsselte Nachricht X mit weiteren Datensätzen in einem Authentifizierungspaket P von dem Client C an das Trustgerät T gesendet. In einer bevorzugten Ausführungsform umfasst das Authentifizierungspaket P die Nachricht N, die verschlüsselte Nachricht X und die Clientadresse A. Dies ist in Figur 2 mit dem unteren Pfeil gekennzeichnet, der vom Clientgerät C an das Trustgerät T gerichtet ist und mit dem Bezugszeichen ,,Ρ(Ν,Χ,Α)" gekennzeichnet ist. Nach Empfang des Authentifizierungspaketes P kann das Trustgerät T die Authentizität des sendenden Client C durch folgende Schritte überprüfen: - Zunächst wird aus dem Authentifizierungspaket P die
Clientadresse A herausgelöst. Die Clientadresse A dient zum Zugriff auf den Speicher 10, um aus dem Speicher 10 den für diese Adresse bzw. für diese client-spezifischen Verschlüsselungsmittel key zu ermitteln. Nach Ermitteln des client-spezifischen Verschlüsselungsmittel key auf dem Trustgerät T wird das so ermittelte Verschlüsselungsmittel key auf die empfangene Nachricht N1 (also auf die Nachricht N die das Trustgerät T vom Client C mit dem Authentifizierungspaket P empfangen hat) ange- wendet, um eine referenzverschlüsselte Nachricht X' zu berechnen .
- Daraufhin kann auf dem Trustgerät T ein Vergleich zwischen der referenzverschlüsselten Nachricht X' und der empfangenen, verschlüsselten Nachricht X aus dem Authentifizierungspaket P ausgeführt werden. Falls die referenzverschlüsselte Nachricht X' mit der empfangenen, verschlüsselten Nachricht X identisch übereinstimmt, gilt der jeweilige Client C auf dem Trustgerät T als authentifiziert.
Mit anderen Worten wird in der Initialisierungsphase eine Verschlüsselungsfunktion auf dem Trustgerät T erzeugt, die sowohl auf dem Trustgerät T, als auch auf dem Client bereit- gestellt wird. Zur Authentifizierung des Client C wird dann diese Verschlüsselungsfunktion auf dem Client angewendet und in einem Authentifizierungspaket P wird das Verschlüsselungsergebnis mit weiteren Identifikationsdaten an das Trustgerät T gesendet . Aus den empfangenen Daten kann das Trustgerät T dann unter Zugriff auf seinen eigenen (privat abgelegten) Schlüssel diesen Schlüssel nochmals anwenden, um sozusagen eine Vergleichsverschlüsselung (oder Referenzverschlüsselung) auszuführen. Mit anderen Worten wird auf dem Client C und dem Trustgerät T dieselbe Verschlüsselungsberechnung ausgeführt. Falls beide Berechnungen zum selben Ergebnis führen, ist gewährleistet, dass sie dasselbe Verschlüsselungsmittel key verwendet haben und somit kann die Identität des Client C auf dem Trustgerät T sichergestellt werden.
Welches Verschlüsselungsmittel key nun zum Einsatz kommt, kann je nach Ausführungsform definiert werden. Wesentlich ist, dass Client C und Trustgerät T immer dasselbe Verschlüs- selungsmittel key anwenden, um eine Vergleichsmöglichkeit bereitstellen zu können.
Der vorstehend beschriebene Ablauf des Verfahrens wird im Folgenden nochmals detailliert unter Bezugnahme auf Figur 3 erläutert.
Nach dem Start des Verfahrens folgt eine Initialisierungsphase, die in Figur 3 durch das Bezugszeichen „ADMIN/INITIAL" bezeichnet ist. Diese Bezeichnung soll kennzeichnen, dass die Initialisierungsphase üblicherweise von einem Administrator ausgeführt werden kann und der eigentlichen Authentifizierung vorgelagert ist. Die Initialisierungsphase muss nicht unmittelbar der Authentifizierung vorangehen und wird grundsätzlich für einen Client C nur einmal ausgeführt.
Die Initialisierungsphase umfasst das Erzeugen 1 des clientspezifischen Verschlüsselungsmittels key, das Speichern 2 des Verschlüsselungsmittels key in dem Speicher 10 mit der Zuordnung zu dem jeweiligen Client C (unter Verwendung der jewei- ligen Clientadresse A) und das Senden 3 des Verschlüsselungsmittels key an den Client C. Die Initialisierungsphase umfasst somit die Schritte 1, 2 und 3.
Wie in Figur 3 dargestellt, umfasst die eigentliche Authenti- fizierung die folgenden Schritte:
Nachdem der Client C das Verschlüsselungsmittel key vom
Trustgerät T empfangen hat, kann der Client C dieses Ver- schlüsselungsmittel key auf die Nachricht N anwenden, um die verschlüsselte Nachricht X zu berechnen. Der Verfahrensschritt des Berechnens trägt das Bezugszeichen 4. Daraufhin erzeugt der Client C das Authentifizierungspaket P, umfassend die Nachricht N, die verschlüsselte Nachricht X und die Clientadresse A, an das Trustgerät T. Der Vorgang des Versendens trägt das Bezugszeichen 5.
Alle nachfolgenden Schritte werden auf dem Trustgerät T ausgeführt. Insbesondere erfolgt nach Empfang des Authentifizie- rungspaketes P der eigentliche Authentifizierungsvorgang durch das Validieren, das das Bezugszeichen 6 trägt und folgende Schritte umfasst:
- Im Schritt 6.1 wird das client-spezifische Verschlüsselungsmittel key durch Zugriff auf den Speicher 10 ermittelt. Der Zugriff erfolgt mit der Clientadresse A, die mit dem Authentifizierungspaket P auf dem Trustgerät empfangen worden ist.
- Das ermittelte Verschlüsselungsmittel key wird daraufhin im Schritt 6.2 auf die empfangene Nachricht N1 zur Berechnung der referenzverschlüsselten Nachricht X' angewendet .
- Daraufhin kann dann im Schritt 6.3 ein Vergleich zwischen der referenzverschlüsselten Nachricht X' und der empfangenen verschlüsselten Nachricht X aus dem Authentifizierungspaket P ausgeführt werden. Falls die referenzverschlüsselte Nachricht X' mit der verschlüsselten Nachricht X identisch übereinstimmt, gilt der Client C auf dem Trustgerät T als authentifiziert.
In Figur 3 sind auf der linken Seite die Instanzen gekennzeichnet (Trustgerät T/Client C) , auf denen die jeweiligen Verfahrensschritte ausgeführt werden. In alternativen Ausfüh rungsformen können einzelne Verfahrensschritte jedoch auch auf andere Module ausgelagert werden. Wesentlich ist jedoch allen Ausführungsformen, dass keine zentrale Zertifizierungsinstanz notwendig ist, um die Verschlüsselungsmittel key der Clients C zu verwalten. Die Speicherung der Verschlüsselungsmittel key ist lediglich auf dem Trustgerät T selbst vorgesehen.
Wie vorstehend bereits beschrieben, wird üblicherweise als Verschlüsselungsmittel key eine Hashfunktion angewendet. Andere Ausführungsbeispiele sehen hier andere Verschlüsselungs- mittel key vor, die jedoch folgende Eigenschaften haben:
- Schwer zu invertieren,
- schnell bzw. leicht zu berechnen und
- Nicht-Injektiv.
Vorzugsweise dient die Verschlüsselungsfunktion dazu, die erzeugte Bitlänge des Verschlüsselungstextes zu reduzieren.
In einem bevorzugten Ausführungsbeispiel werden unterschied- liehe Hashfunktionen auf systemische Weise unter Anwendung einer symmetrischen Verschlüsselungsprozedur erzeugt, die an Stelle der Hashfunktion angewendet wird. Der Schlüssel ist somit auf dem Client C und dem Trustgerät T derselbe. Nach der Initialisierung fordert das Trustgerät T zusätzliche (externe) Mittel an, die die Authentizität des Client C sicherstellen (z.B. über einen separaten Kommunikations- kanal) . Sobald diese Mittel vorhanden sind, wird ein sicherer Schlüssel key erzeugt und an das Clientgerät C kommuniziert. Das Clientgerät C speichert den empfangenen Schlüssel key auf sichere Weise in einem sicheren Speicher. Das Trustgerät T verwaltet eine Liste mit Zuordnungen zwischen Clientadresse (als Identität) A und Verschlüsselungsmittel key paarweise in dem Speicher 10. Sobald ein neuer Schlüssel key für einen Client C erzeugt wurde, wird dieses Paar (A,key) in den Spei- eher 10 hinzugefügt. Daraufhin kann das Trustgerät T jede Nachricht N des Client C auf Authentizität überprüfen. Dazu extrahiert das Clientgerät C einen definierten Abschnitt aus der Nachricht N. Ein wesentlicher Vorteil des Verfahrens besteht in der Abhängigkeit von X von der Nachricht N und dem geheimen Schlüssel key, wodurch abhörende Dritte das Authen- tisierungsmittel X nicht replizieren können. Dieser Abschnitt wird als Extrahierungsabschnitt bezeichnet und durch eine Ex- trahierungsfunktion ext erzeugt. Das Extrahierungsergebnis (nach Anwendung der Extrahierungsfunktion ext) wird mit dem Verschlüsselungsmittel key verschlüsselt und die daraus re- sultierende verschlüsselte Nachricht X wird zusammen mit der Clientidentität A und der erzeugten Nachricht N an das Trustgerät T übermittelt.
Das Trustgerät T kann daraufhin jedes Mal die Authentizität des sendenden Client C verifizieren, falls ein solches
Authentifizierungspaket P vom Client auf dem Trustgerät T empfangen werden konnte. Dazu wird ein Look-Up in dem Speicher 10 ausgeführt, um den Schlüssel key zu finden, der der jeweiligen Sendeadresse/Identität A des Client C zugeordnet ist. Daraufhin kann die verschlüsselte Nachricht X entschlüsselt werden und das Ergebnis mit dem extrahierten Abschnitt aus dem empfangenen Datensatz auf Übereinstimmung verglichen werden. Falls der Vergleich eine Übereinstimmung indiziert, gilt der sendende Client C als authentifiziert. In diesem Fall ist die auf dem Client C verschlüsselte Form X der Nachricht N durch folgende Funktion definiert. X = key (ext (N) . Auf dem Trustgerät T wird folgende Berechnung ausgeführt, die eine Entschlüsselung mit dem aus dem Speicher 10 zugegriffenen Schlüssel key umfasst. Die behauptete Identität A des Client C (empfangen durch das Authentifizierungspaket P) wird auf dem Trustgerät T verwendet, um den identitäts-spezifi- schen Schlüssel key aus dem Speicher 10 abzurufen und daraufhin auf die empfangene Nachricht dieselben Schritte anzuwenden, die der Client C angewendet hat, also zunächst die
Extrahierungsfunktion ext, um die extrahierte Nachricht Next zu erzeugen und daraufhin die Entschlüsselung mit demselben Verschlüsselungsmittel key. Falls das Ergebnis übereinstimmt, gilt der Client C als authentifiziert. Vorzugsweise hat die Extrahierungsfunktion ext dieselben Eigenschaften wie das Verschlüsselungsmittel key, und ist insbesondere schnell zu berechnen, kaum oder nur schwer umzukeh- ren und injektiv.
In den vorstehend beschriebenen Ausführungsbeispielen ist es notwendig, das Clientgerät C und Trustgerät T sich im Vorfeld über das auszuführende Authentifizierungsverfahren zur Extra- hierung der Nachrichten einigen. Mit anderen Worten muss die Extrahierungsfunktion ext im Vorfeld zwischen Client C und Trustgerät T verabredet sein.
In einem weiteren Ausführungsbeispiel werden die Algorithmen zur Berechnung der Extrahierungsfunktion ext und des Verschlüsselungsmittels key in Kombination, z.B. als
„key (ext ()) " in einem ausführbaren Format (beispielweise als ausführbare Datei „app" einer standardisierten Rechner-Plattform) an den Client C gesendet, wobei der geheime Schlüssel key bereits in diese Algorithmen integriert ist. In diesem
Ausführungsbeispiel wird somit eine mobile Software mit darin integrierten Algorithmen von Trustgerät T an den Client C gesendet. In diesem Ausführungsbeispiel ist es nicht mehr notwendig, dass sich Client C und Trustgerät T im Vorfeld über das anzuwendende Prozedere einigen. Damit kann eine weitere Flexibilität erreicht werden, da die auszuführenden Berechnungen und Funktionen bereits in die mobile Software integriert sind. Die jeweilige Applikation zur Berechnung von key (ext (N) ) wird sowohl client- als auch trustseitig verwen- det . Somit sind die beiden Berechnungsvorschriften, nämlich die Extrahierungsfunktion ext und das Verschlüsselungsmittel key als Konkatenation implementiert. In diesem Ausführungsbeispiel speichert das Trustgerät T neben der Zuordnung zwischen Clientidentität A und client-spezifischem Verschlüsse- lungsmittel key auch noch die mobile Softwareapplikation (z.B. als standardisierte „app"). In einer weiteren Ausführungsform kann eine Erweiterung des vorstehend beschriebenen Authentifizierungsschemas angewendet werden. In dieser Ausführungsform extrahiert der Client C einen definierten Ausschnitt der erzeugten Nachricht N und ver- schlüsselt diese mit dem sicheren Verschlüsselungsmittel key und sendet es, wie vorstehend bereits beschrieben, im Rahmen des Authentifizierungspaketes P an das Trustgerät T. Das Trustgerät T führt daraufhin wieder einen Zugriff auf den Speicherbaustein 10 aus, um mit der Clientidentität (Adresse A des Client C) den client-spezifischen Schlüssel aus der Liste herauszulesen und den definierten Ausschnitt zu entschlüsseln und das Ergebnis mit dem Bestandteil des Authentifizierungpaketes P auf Übereinstimmung zu vergleichen. In einer weiteren Ausführungsform kann zum Schutz gegen Abhören eine andere Erweiterung des vorstehend beschriebenen Authentifizierungsschemas angewendet werden. Dazu wird als Ausführung der Verschlüsselungsfunktion key ( ) der Eingabewert derart modifiziert, dass eine zufällige Größe oder eine Zeit- marke hinzugefügt wird. Alle Komponenten und Schritte des
Verfahrens bleiben wie vorstehend beschrieben. Durch das Mitführen der verschlüsselten Uhrzeit oder Zufallszahl in der verschlüsselten Form X wird es vermieden, dass (insbesondere bei Clientgeräten C, die Werte von einfachen Sensoren über- mittein) durch immer wiederholte gleiche Werte für eine Nachricht N auch gleiche Werte für die verschlüsselte Form X als Teil von dem Authentisierungspakte P über die Verbindung zum Trustgerät T übermittelt und für Dritte replizierbar werden. Ein besonderer Vorteil der erfindungsgemäßen Lösung ist darin zu sehen, dass es möglich ist, auf eine Public-key- Infrastruktur zu verzichten. Damit kann das Authentifizie- rungssystem wesentlich flexibler und einfacher und auch kostengünstiger bereitgestellt werden. Zur Authentifizierung ist es deshalb nicht mehr nötig, auf eine zentrale Instanz (Zertifizierungsinstanz) zuzugreifen, um die Identität eines Client C zu validieren. Ein weiterer Vorteil ist darin zu sehen, dass beliebige Clients C auf einem Trustgerät T authen- tifiziert werden können, ohne dass auf den Clients C vorbereitende Maßnahmen ausgeführt werden müssen. Die Schlüssel sind vorteilhafterweise schnell und einfach zu erzeugen. Abschließend sei darauf hingewiesen, dass die Beschreibung der Erfindung und die Ausführungsbeispiele grundsätzlich nicht einschränkend in Hinblick auf eine bestimmte physikalische Realisierung der Erfindung zu verstehen sind. Für einen Fachmann ist es insbesondere offensichtlich, dass die Erfin- dung teilweise oder vollständig in Soft- und/oder Hardware und/oder auf mehrere physikalische Produkte - dabei insbesondere auch Computerprogrammprodukte - verteilt realisiert werden kann .

Claims

AuthentifizierungsSystem zur Authentifizierung eines
Client (C) an einer medizintechnischen Anlage, die als Trustgerät (T) fungiert, mit:
- Einem Trustgerät (T) mit:
o einem Verschlüsselungsgenerator (G) , der dazu bestimmt ist, ein client-spezifisches Verschlüsselungsmittel (key) zu erzeugen,
o einem Speicherbaustein (10) , der zur Speicherung einer Zuordnung zwischen dem jeweiligen Client (C) und des für ihn erzeugten Verschlüsselungsmittels (key) bestimmt ist,
o einer Sendekomponente (S) , die dazu bestimmt ist, das erzeugte Verschlüsselungsmittel (key) an den Client (C) zu senden,
o einer Validierungskomponente (V) , die dazu bestimmt ist, die Authentizität des Clients (C) zu validieren, umfassend:
■ Speicherzugriffsmittel (VI) , die dazu bestimmt sind, das client-spezifische Verschlüsselungsmittel (key) durch Zugriff auf den Speicherbaustein (10) zu ermitteln, wobei der Zugriff auf dasjenige client-spezifische Verschlüsselungsmittel (key) erfolgt, das jeweils einer vom Client (C) empfangenen Clientadresse (A) zugeordnet ist.
■ Eine Referenzverschlüsselungseinheit
(V2), die dazu bestimmt ist, das ermittelte Verschlüsselungsmittel (key) auf die empfangene Nachricht ( zur Berechnung einer referenzverschlüsselten Nachricht (X1) anzuwenden.
■ Einen Komparator (V3), der dazu bestimmt ist, ein Authentifizierungspaket (P) von dem Client (C) zu empfangen und der weiterhin dazu bestimmt ist, die referenzverschlüsselte Nachricht (X1) mit einer empfangenen verschlüsselten Nachricht (X) aus dem Authentifizierungs- paket (P) auf Identität zu vergleichen und, der dazu bestimmt ist, bei Identität den
Client (C) auf dem Trustgerät (T) zu authentifizieren .
- Einem Client (C) mit:
o einer Verschlüsselungseinheit (K) , die dazu bestimmt ist, das empfangene Verschlüsselungsmittel (key) auf eine Nachricht (N) zum Berechnen einer verschlüsselten Nachricht (X) anzuwenden, o einem Paketierungsmodul (PM) , das dazu bestimmt
ist, ein Authentifizierungspaket (P) zu erzeugen, umfassend die Nachricht (N) , die verschlüsselte Nachricht (X) und eine Clientadresse (A) und das dazu bestimmt ist, das Authentifizierungspaket (P) an das Trustgerät (T) zu senden.
Client (C) mit einer Verschlüsselungseinheit (K) und einem Paketierungsmodul (PM) zur Anwendung in einem Authentifi- zierungssystem nach Anspruch 1.
3. Trustgerät (T) mit einem Verschlüsselungsgenerator (G) , einem Speicherbaustein (10) , einer Sendekomponente (S) und einer Validierungskomponente (V) zur Anwendung in einem Authentifizierungssystem nach Anspruch 1.
4. Verfahren zur Authentifizierung eines Client (C) an einer medizintechnischen Anlage, die als Trustgerät (T) fungiert, wobei das Verfahren folgende Verfahrensschritte um- fasst :
- Seitens des Trustgerätes (T) : Initialisieren der Authen- tifizierung durch folgende Schritte:
o Erzeugen (1) eines client-spezifischen Verschlüsselungsmittels (key) auf dem Trustgerät (T) , o Speichern (2) des client-spezifischen Verschlüsselungsmittels (key) in einem Speicher (10) auf dem Trustgerät (T) mit einer Zuordnung zwischen dem jeweiligen Client (C) und des für ihn erzeugten Verschlüsselungsmittels (key) , . o Senden (3) des erzeugten Verschlüsselungsmittels (key) an den Client (C)
- Seitens des Client (C) : Anwenden des empfangenen Verschlüsselungsmittels (key) auf eine Nachricht (N) zum Berechnen (4) einer verschlüsselten Nachricht (X) .
- Seitens des Client (C) : Versenden (5) eines Authentifi- zierungspaketes (P) , umfassend die Nachricht (N) , die verschlüsselte Nachricht (X) und eine Clientadresse (A) an das Trustgerät (T) .
- Seitens des Trustgerätes (T) : Validieren (6) der Authentizität des Client (C) durch folgende Schritte:
o Ermitteln (6.1) des client-spezifischen Verschlüsselungsmittels (key) durch Zugriff auf den Speicher (10) , das jeweils der empfangenen Clientadresse (A) zugeordnet ist,
o Anwenden (6.2) des ermittelten Verschlüsselungsmittels (key) auf die empfangene Nachricht (NM zur Berechnung einer referenzverschlüsselten Nachricht (X ,
o Vergleich (6.3) der referenzverschlüsselten Nachricht (X1) mit der empfangenen verschlüsselten Nachricht (X) aus dem Authentifizierungspaket (P) auf Identität und bei Identität: Authentifizieren des Client (C) auf dem Trustgerät (T) .
Verfahren nach Patentanspruch 4, bei dem das Authentifizieren ohne eine separate, zum Client (C) und zum Trustgerät (T) zusätzliche Zertifizierungsinstanz ausgeführt wird .
Verfahren nach einem der vorstehenden Verfahrensansprüche, bei dem das Initialisieren für jeden Client (C) nur einmal ausgeführt wird und das Berechnen (4) einer verschlüsselten Nachricht (X) und das Versenden
(5) des Authentifizie- rungspaketes (P) seines des Clients (C) , das Validieren
(6) seitens des Trustgerätes (T) für alle oder ausgewählte Nachrichten angewendet wird, die von Client (C) an das Trustgerät (T) gesendet werden.
7. Verfahren nach einem der vorstehenden Verfahrensansprüche, bei dem das Verschlüsselungsmittel (key) und ein Referenz- Verschlüsselungsmittel übereinstimmen.
8. Verfahren nach einem der vorstehenden Verfahrensansprüche, bei dem das Verschlüsselungsmittel (key) eine kollisions- resistente und/oder eine Einweg-Hashfunktion ist.
9. Verfahren nach einem der vorstehenden Verfahrensansprüche, bei dem das Verschlüsselungsmittel (key) eine symmetrische kryptologische Funktion ist.
10. Verfahren nach einem der vorstehenden Verfahrensansprüche, bei dem auf dem Client (C) zunächst auf die erzeugte Nachricht (N) eine Extrahierungsfunktion (ext) angewendet wird, um eine extrahierte Nachricht (Next ) zu erzeugen und um daraufhin das Verschlüsselungsmittel (key) auf die extrahierte Nachricht (NEXT) anzuwenden und in dem Authenti- fizierungspaket (P) an das Trustgerät (T) zur Authentizitätsprüfung zu übertragen.
11. Verfahren nach einem der vorstehenden Verfahrensansprüche, bei dem das client-spezifische Verschlüsselungsmittel (key) eine Konkatenation einer Verschlüsselungsfunktion und einer Extrahierungsfunktion (ext) ist und als mobile ausführbare Applikationsdatei (App) übertragen wird.
12. Verfahren nach einem der vorstehenden Verfahrensansprüche, bei dem eine Identität, eine Nachricht oder ein Nach- richtenkonvolut authentifiziert wird.
13. Computerprogrammprodukt ladbar oder geladen in einen Speicher eines Computers (C, T) oder eines tragbaren Datenträgers mit von dem Computer lesbaren Befehlen zur Ausführung des Verfahrens nach einem der vorstehenden Verfah- rensansprüche , wenn die Befehle auf dem Computer (C, T) ausgeführt werden.
PCT/EP2014/051756 2013-02-15 2014-01-30 Authentifizierung von medizinischen clientgeräten in einem geräteverbund WO2014124809A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102013202494.0A DE102013202494A1 (de) 2013-02-15 2013-02-15 Authentifizierung von medizinischen Clientgeräten in einem Geräteverbund
DE102013202494.0 2013-02-15

Publications (1)

Publication Number Publication Date
WO2014124809A1 true WO2014124809A1 (de) 2014-08-21

Family

ID=50068975

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2014/051756 WO2014124809A1 (de) 2013-02-15 2014-01-30 Authentifizierung von medizinischen clientgeräten in einem geräteverbund

Country Status (2)

Country Link
DE (1) DE102013202494A1 (de)
WO (1) WO2014124809A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115136545A (zh) * 2019-12-20 2022-09-30 易思科波伊克斯公司 用于在医疗检查的环境中管理数据交换的方法和系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6842860B1 (en) * 1999-07-23 2005-01-11 Networks Associates Technology, Inc. System and method for selectively authenticating data
US20050203582A1 (en) * 2004-03-15 2005-09-15 Healy Scott J. Cryptographic authentication for telemetry with an implantable medical device
US20050204134A1 (en) * 2004-03-15 2005-09-15 Von Arx Jeffrey A. System and method for securely authenticating a data exchange session with an implantable medical device
WO2012107296A1 (de) * 2011-02-10 2012-08-16 Siemens Aktiengesellschaft Mobilfunkgerätbetriebenes authentifizierungssystem unter verwendung einer asymmetrischen verschlüsselung

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6842860B1 (en) * 1999-07-23 2005-01-11 Networks Associates Technology, Inc. System and method for selectively authenticating data
US20050203582A1 (en) * 2004-03-15 2005-09-15 Healy Scott J. Cryptographic authentication for telemetry with an implantable medical device
US20050204134A1 (en) * 2004-03-15 2005-09-15 Von Arx Jeffrey A. System and method for securely authenticating a data exchange session with an implantable medical device
WO2012107296A1 (de) * 2011-02-10 2012-08-16 Siemens Aktiengesellschaft Mobilfunkgerätbetriebenes authentifizierungssystem unter verwendung einer asymmetrischen verschlüsselung

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
CHRISTOPH RULAND: "Informationssicherheit in Datennetzen", 1993, DATACOM-VERLAG, pages: 68
WOLFGANG ERTEL: "Angewandte Kryptographie", CARL HANSER VERLAG, pages: 68 - 75

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115136545A (zh) * 2019-12-20 2022-09-30 易思科波伊克斯公司 用于在医疗检查的环境中管理数据交换的方法和系统
CN115136545B (zh) * 2019-12-20 2024-03-12 易思科波伊克斯公司 用于在医疗检查的环境中管理数据交换的方法和系统

Also Published As

Publication number Publication date
DE102013202494A1 (de) 2014-08-21

Similar Documents

Publication Publication Date Title
DE60302276T2 (de) Verfahren zur ferngesteuerten Änderung eines Kommunikationspasswortes
DE102009024604B4 (de) Erzeugung eines Session-Schlüssels zur Authentisierung und sicheren Datenübertragung
DE102018101812B4 (de) Sicheres Übertragen von Benutzerinformationen zwischen Anwendungen
EP3121795B9 (de) Aufbau einer kommunikationsverbindung mit einer benutzervorrichtung über eine zugangskontrollvorrichtung
EP3033855B1 (de) Unterstützung einer entschlüsselung von verschlüsselten daten
EP3031226B1 (de) Unterstützung der nutzung eines geheimen schlüssels
EP2929648B1 (de) Verfahren zum aufbau einer sicheren verbindung zwischen clients
DE102010033232A1 (de) Verfahren und Vorrichtung zum Bereitstellen eines Einmalpasswortes
DE102013206185A1 (de) Verfahren zur Erkennung einer Manipulation eines Sensors und/oder von Sensordaten des Sensors
DE102016210786A1 (de) Komponente zur Anbindung an einen Datenbus und Verfahren zur Umsetzung einer kryptografischen Funktionalität in einer solchen Komponente
DE112015002927T5 (de) Generierung und Verwaltung geheimer Chiffrierschlüssel auf Kennwortgrundlage
EP3157192A1 (de) Verfahren und system für eine asymmetrische schlüsselherleitung
DE10124427A1 (de) System und Verfahren für einen sicheren Vergleich eines gemeinsamen Geheimnisses von Kommunikationsgeräten
EP3206154B1 (de) Verfahren und vorrichtungen zum sicheren übermitteln von nutzdaten
EP3672142A1 (de) Verfahren und system zur sicheren übertragung eines datensatzes
DE102017006200A1 (de) Verfahren, Hardware und System zur dynamischen Datenübertragung an ein Blockchain Rechner Netzwerk zur Abspeicherung Persönlicher Daten um diese Teils wieder Blockweise als Grundlage zur End zu Endverschlüsselung verwendet werden um den Prozess der Datensammlung über das Datenübertragungsmodul weitere Daten in Echtzeit von Sensoreinheiten dynamisch aktualisiert werden. Die Blockmodule auf dem Blockchaindatenbanksystem sind unbegrenzt erweiterbar.
WO2014124809A1 (de) Authentifizierung von medizinischen clientgeräten in einem geräteverbund
EP3050244B1 (de) Bereitstellung und verwendung pseudonymer schlüssel bei hybrider verschlüsselung
EP3618348B1 (de) Verfahren zum betreiben eines verteilten datenbanksystems, verteiltes datenbanksystem und industrieautomatisierungssystem
DE102016121376A1 (de) Gebäude- oder Einfriedungsabschlussschließ- und/oder -öffnungsvorrichtung sowie Verfahren zum Betrieb eines Gebäude- oder Einfriedungsabschlusses
DE102014212219A1 (de) Verfahren zur Authentifizierung und Anbindung eines Geräts an ein Netzwerk sowie hierzu eingerichteter Teilnehmer des Netzwerks
DE102014222216A1 (de) Verfahren und Vorrichtung zur Absicherung einer Kommunikation
EP2120391B1 (de) Verfahren zur Erzeugung eines asymmetrischen kryptografischen Schlüsselpaares und die Anwendung in der elektronischen Gesundheitskarte (eGK)
DE102015102186A1 (de) Verfahren zur Registrierung eines Endgeräts zur Kommunikation mit einem Server
DE102017011588A1 (de) Sichere Datenübertragung von Nutzdaten

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14703045

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14703045

Country of ref document: EP

Kind code of ref document: A1