Medical device, authentication server, and method for authorizing a user to access a device via a device user interface

Abstract

The present disclosure relates to a medical device, an authentication server 20, and a method for authorizing a user to access a medical device 10 via a device user interface. According to a first aspect, the present disclosure proposes a method for authorizing a user to access a medical device via a device user interface, the method being used in a medical device. The method comprises: storing S0 an authorized public key of an authorized asymmetric key pair associated with an authentication server; and providing S3 an authorization challenge to a user via the device user interface, the authorization challenge indicating a device public key of a temporary device asymmetric key pair generated in the medical device. The method further comprises: receiving S4 a response code from a user via the device user interface, the response code comprising validity information encrypted using a shared key, the shared key being derivable from an authorized private key of the authorized asymmetric key pair and a provided device public key; and authorizing S7 a user to access the medical device when the validity information decrypted using the same shared key is valid, but the same shared key is derived in the medical device using the stored authorized public key and the device private key of the temporary device asymmetric key pair. The present disclosure also relates to a computer program and a computer program product for implementing the method.

Description

Technical Field

[0001] The present disclosure relates to a medical device, an authentication server and a method for authorizing a user to access a medical device via a device user interface. The present disclosure also relates to a computer program and a computer program product for implementing the method. Background Art

[0002] Medical devices (hereinafter referred to as devices) generally require users (e.g., medical personnel or technicians) to authenticate before being allowed to access the device. If the medical device is online (i.e., communicating with a service system), the user can be granted access rights via the service system by simply logging into the service system.

[0003] However, sometimes users need to access devices that are offline from the service system. Today, offline devices typically use hard-coded passwords (e.g., PINS, passwords, or keys) that can be entered via a user interface to authorize the user to access. This type of access authorization is no longer considered secure for several reasons.

[0004] For example, there is always a risk that passwords are shared between users in an uncontrolled manner. Password schemes also require an additional generation step, as each piece of equipment needs to be pre-programmed with a separate password. On the other hand, if the PIN or password is lost, there is no way to log in at all. Therefore, infrastructure is required to maintain a secure database with passwords for all devices, which requires management work.

[0005] Additionally, anonymous passwords make it impossible to audit who has accessed a particular device unless each password is used by a single user. However, having multiple user IDs and passwords on each device requires a lot of maintenance when users change.

[0006] Another way to identify users is to use a one-time password. However, a one-time password requires some kind of synchronization, either through a one-time password order number or through time synchronization between the medical device and the password generator. However, in general, neither of these synchronization options is really easy to manage. For order-based one-time passwords without user IDs, all users would have to communicate back to the password generator which password was most recently used on each respective device, which is not feasible. As mentioned above, order-based one-time passwords with user IDs require maintaining a user database on each offline device. Time-based one-time passwords are also not feasible, as there is no guarantee that the clock of the medical device is synchronized with the time of the password generator.

[0007] It should also be noted that the technician may be outside the clinic, so even if the medical device is connected to the service system, the technician cannot be authenticated through the hospital's IT system.

[0008] Therefore, there is a need to improve the way in which authorized users access devices. Summary of the invention

[0009] The present disclosure aims to alleviate at least some of the disadvantages of existing solutions. A further aim is to provide a way to authorize user access in a secure manner that does not require configuring the device with any personal information. Specifically, the aim is to provide a solution to eliminate the need to configure separate passwords in medical devices.

[0010] According to a first aspect, the present disclosure proposes a method for authorizing a user to access a medical device via a device user interface, the method being used in a medical device. The method comprises: storing an authorized public key of an authorized asymmetric key pair associated with an authentication server; and providing an authorization challenge to a user via the device user interface, the authorization challenge indicating a device public key of a temporary device asymmetric key pair generated in the medical device. The method further comprises: receiving a response code from the user via the device user interface, the response code comprising validity information encrypted using a shared key, the shared key being derivable from an authorized private key of the authorized asymmetric key pair and a provided device public key; and authorizing the user to access the medical device when the validity information decrypted using the same shared key is valid, but the same shared key is derived in the medical device using the stored authorized public key and the device private key of the temporary device asymmetric key pair. The proposed method is capable of authorizing a user to access an offline user device via a user interface without using any preconfigured password. In practice, this means that all users authorized by the authentication server can obtain a password from the authentication server, thereby being able to access the medical device. Therefore, it is the authentication server that controls who is authorized to access the medical device. By using one public key common to all devices, the personalization step in generation can be eliminated. The method also eliminates the need for a database of private or symmetric keys for each device and all the problems that may occur when replacing the hardware in the device and thus replacing new personal keys. Finally, the method does not require clock synchronization of the medical device and the authentication server.

[0011] In some embodiments, the user interface is a human-machine interface, or a machine-machine interface configured to communicate with a user device of the user. Thus, the user can communicate the challenge and response manually or via a user device such as a wristband, a smartphone, or a portable data storage device such as a USB memory stick.

[0012] In some embodiments, authorization includes authorizing different levels of access to the user based on information included in the response code. Thus, a single method can be used for different types of users that would normally require different passwords. Instead, the access level is handled by the authentication server. In some embodiments, authorization includes authorizing the user to at least one of: authorizing specific access to one or more treatment sessions, unlocking the medical device for a specific use, and authorizing temporary non-routine use.

[0013] In some embodiments, the authorization includes authorizing access during a specific time period. Thus, the authorized access to the device may be limited to a single use or a few times. Furthermore, it may be limited in time.

[0014] In some embodiments, the method comprises: receiving user input to initiate authorization of access to the user.Thus, the authorization may be initiated by a user, for example, pressing a button on the medical device.

[0015] In some embodiments, the method includes: invalidating the temporary device asymmetric key pair. Thus, it is ensured that the temporary key is invalid after being used once or after a certain time. Therefore, for the next authorization, a new temporary device asymmetric key pair must be created. This enhances security.

[0016] In some embodiments, the method includes: the medical device is offline from the authentication server. Therefore, the method can be used even on offline medical devices.

[0017] According to a second aspect, the present disclosure relates to a method for authorizing a user to access a medical device via a server user interface, the method being used in an authentication server. The method comprises: storing an authorization private key of an authorization asymmetric key pair associated with the authentication server, and authenticating the user. The method further comprises: receiving an authorization challenge from the user via the server user interface, the authorization challenge indicating a device public key of a temporary device asymmetric key pair associated with the medical device; and providing a response code to the user via the server user interface, the response code comprising validity information encrypted using a shared key, wherein the shared key is derived in the authentication server using the stored authorization private key and the device public key. The method is capable of creating a response code that can be used to unlock the medical device based on the authentication of the user in the authentication server. Thus, all user authentications can be processed in one place (i.e., in the authentication server). When access to the medical device is required, the authentication server will then act on behalf of the user. In other words, the proposed method can be performed individually for each user who logs into the central system (i.e., cannot be cleared in the medical device), independent of the network infrastructure.

[0018] In practice, this means that once a user is added to an authentication server, the user can be granted access to any medical device controlled by the authentication server (i.e., all medical devices that store the authorized public key of the authorized asymmetric key pair and are configured to execute the method according to the first aspect). The method allows a remote authentication server to manage users, authorizations, and deauthorizations (e.g., when personnel change). Changes are immediate and do not require maintenance of each individual device.

[0019] In some embodiments, the server interface is a human-machine interface, or a machine-machine interface configured to communicate with a user device of the user. Thus, the user can communicate the challenge and response manually or via a user device such as a wristband or a smart phone.

[0020] In some embodiments, determining includes: determining the response code based on at least one of: the user's authorization level, a time parameter, and the user's location. Thus, the authentication server can select what type of access rights to grant based on different parameters. For example, different types of access rights can be granted to medical personnel and technicians. In addition, some users may only be allowed to access the medical device at specific times or specific locations.

[0021] In some embodiments, the method includes: logging information associated with the authentication. Since the authentication server knows which user has been granted access to which medical device and when, a log of all access rights provided can be generated, which may be useful in many situations.

[0022] In some embodiments, the authorization asymmetric key pair and the device asymmetric key pair are generated so that, conversely, the same shared key is derived when using the private key of one of the asymmetric key pairs and the public key of the other asymmetric key pair. In some embodiments, the shared key is derived using a Diffie-Hellman function. In some embodiments, the authorization asymmetric key pair and the device asymmetric key pair are generated using elliptic curve cryptography (ECC) or Rivest-Shamir-Adleman (RSA).

[0023] In some embodiments, the validity information includes at least one of: a device identifier of the medical device, an address of the medical device, a predetermined data sequence, and a data sequence determined using a predetermined rule. Therefore, in practice, any "string" known to the medical device can be used. In some embodiments, the validity information includes a control sum. When the response code is manually entered, it may be beneficial to use a control sum (i.e., a checksum) because manually entered response codes are typically shorter.

[0024] According to a third aspect, the present disclosure relates to a corresponding medical device, which includes a device user interface and a control device. The control device is configured to store an authorized public key of an authorized asymmetric key pair associated with an authentication server, and provide an authorization challenge to a user via the device user interface, the authorization challenge indicating the device public key of a temporary device asymmetric key pair generated in the medical device. The control device is also configured to receive a response code from the user via the device user interface, the response code including validity information encrypted using a shared key. The shared key is derivable from an authorized private key of the authorized asymmetric key pair and a provided device public key. The control device is also configured to authorize the user to access the medical device when the validity information decrypted using the same shared key is valid, but the same shared key is derived in the medical device using the stored authorized public key and the device private key of the temporary device asymmetric key pair.

[0025] According to a fourth aspect, the present disclosure relates to a corresponding authentication server, which includes a server user interface. The authentication server is configured to store an authorization private key of an authorization asymmetric key pair associated with the authentication server and authenticate the user. In addition, the authentication server is configured to receive an authorization challenge from the user via the server user interface, the authorization challenge indicating a device public key of a temporary device asymmetric key pair associated with the medical device. The authentication server is also configured to provide a response code to the user via the server user interface, the response code including validity information encrypted using a shared key, wherein the shared key is derived in the authentication server using the stored authorization private key and the device public key.

[0026] According to a fifth aspect, the present disclosure relates to a computer program, characterized by code means which, when run in a computer, causes the computer to perform the method according to the first aspect or the second aspect.

[0027] According to a sixth aspect, the present disclosure relates to a computer program product, comprising a computer readable medium and a computer program, wherein the computer program is included in the computer readable medium.

[0028] According to a seventh aspect, the present disclosure relates to a system comprising a medical device and an authentication server. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Embodiments of the present disclosure are described in more detail with reference to the accompanying drawings which show examples of embodiments of the present disclosure, in which:

[0030] Figure 1a A conceptual medical device is shown.

[0031] Figure 1b Shown in more detail Figure 1a Control devices for medical equipment.

[0032] Figure 2 An authentication server is shown.

[0033] Figure 3 Shows that when executing Figure 4 and Figure 5 The method is signaling between the medical device and the authentication server.

[0034] Figure 4 A flow chart of a method for use in a medical device is shown.

[0035] Figure 5 A flow chart of a method in an authentication server is shown.

[0036] Figure 6a An example medical device is shown in which embodiments of the disclosed technology may be implemented.

[0037] Figure 6b Another example medical device is shown in which embodiments of the disclosed technology may be implemented.

[0038] Figure 6c Yet another example medical device in which embodiments of the disclosed technology may be implemented is shown. DETAILED DESCRIPTION

[0039] The proposed scheme involves two parties: the medical device and a response generator (also called an authentication server). For example, the authentication server can be a remotely accessible system, or it can be a secure server inside an organization (e.g., inside a hospital). The authentication server is able to securely store the authorization private key d A and execute the proposed challenge-response algorithm.

[0040] The proposed technology uses asymmetric (also called "public key") encryption methods, in particular key exchange algorithms, to solve the above problems. Public key encryption methods are based on the use of key pairs, where one key is used to encrypt data and the other key is used to decrypt data. Data cannot be decrypted by the encryption key, and data cannot be encrypted by the decryption key (in a meaningful way). When two parties each have a private key d and a public key Q, the two parties can calculate the same shared key K by combining their own private key d with the other party's public key Q.

[0041] As described above, configuring individual encryption keys on each piece of medical equipment requires additional steps for generation as well as infrastructure for maintaining a database of such encryption keys. This can also cause problems when changing the hardware in the device (e.g., replacing an electronic board storing the encryption keys). Therefore, a solution is proposed that does not require any individual keys to be stored in the medical device. Therefore, in the proposed solution, the medical device does not contain any secrets that, if disclosed, would allow access to untrusted users.

[0042] The proposed scheme uses two asymmetric key pairs, one is a temporary device asymmetric key pair and the other is an authorized asymmetric key pair. The authorized asymmetric key pair is pre-generated. The authorized public key Q of the authorized asymmetric key pair is used. B All medical devices produced by the manufacturer are pre-configured or programmed. Authorized public key Q B No need to keep it secret. However, the authorized public key Q B It must be stored in a way that it cannot be changed (at least not by any untrusted party).

[0043] Authorized private key d of the authorized asymmetric key pair B Is securely stored in the authentication server. Authorized private key d B will never be exposed. In addition, the authorized private key d B does not change, but for example a manufacturer uses the same key to be able to access all its medical devices. B The corresponding authorization private key d B The response code required to access the device needs to be created. Therefore, a user who wants to access the medical device needs to authenticate him or herself at the authentication server to obtain a valid response code, which can be used to access the medical device. This means that the medical device does not know which user has accessed the medical device. However, by recording when the response code was created and for which user, and possibly for which medical device, it is still possible to track the user in the authentication server.

[0044] Each time a user wants to access a medical device, a temporary device asymmetric key pair is generated in the medical device. The temporary device asymmetric key pair is basically used to verify whether the response code has been issued for that specific medical device. The temporary device asymmetric key pair is generated using the same algorithm as used to generate the authorization asymmetric key pair. After being used once, the temporary device asymmetric key pair is no longer valid. Therefore, a new temporary device asymmetric key pair must be generated.

[0045] The authorization asymmetric key pair is used together with the temporary device asymmetric key pair to authorize access to the medical device, as will be described below. However, the mathematical algorithms used for asymmetric encryption and key exchange are also not part of the present disclosure, and the proposed scheme does not rely on any particular algorithm, although some algorithms may be better suited for this purpose than others for purely practical reasons.

[0046] In the following, a medical device, an authentication server, and a method for authorizing a user to access a medical device via a device user interface are described. The proposed technology is applicable to any medical device that requires or desires to control user access. Medical devices include, but are not limited to, infusion pumps for fluids (e.g., nutritional fluids, intravenous treatment fluids, and oncology drugs), water purification devices, and medical imaging devices.

[0047] Figure 1a A conceptual medical device 10 is shown in which the proposed technology can be implemented. For example, the medical device 10 is a medical machine, such as a dialysis machine. Alternatively, the medical device is a smaller medical device, such as an infusion pump. The medical device 10 may include a plurality of individual devices connected to each other. The proposed technology may then be used to control user access to one or more of these devices. In principle, the medical device 10 may be any device intended for medical use.

[0048] The medical device 10 is configured to perform any medical procedure. The medical device 10 is not connected to any remote system that can grant access rights to the medical device 10. Therefore, the medical device is offline. In particular, the medical device is not connected to any remote system that can grant access rights to the medical device 10. Figure 2 b) Offline, the authorization system 20 holds the authorization private key required to access the medical device 10 B .

[0049] In the simplified example shown, the medical device 10 includes a device user interface 19 and a control device 16. The medical device also includes components (not shown) required to perform a medical procedure. The device user interface 19 enables a user to communicate information to and / or from the medical device. For example, the device user interface 19 includes a display and buttons or a touch screen.

[0050] Figure 1b Shown in more detail Figure 1a The control device 16 of any example medical device of the present invention comprises a processor 161 and a memory 163. The processor 161 can be any commercially available processing device, for example, a CPU, a DSP, a microprocessor, an FPGA, an ASIC or any other electronic programmable logic device, or a combination thereof.

[0051] The control device 16 may also include a communication interface 162 configured to enable communication with other devices or systems (e.g., a local server or a remote service system). The communication may be wireless and / or wired. Wired communication may be performed using a wired Ethernet connection, RS-232, RS-485, or UART. Communication may be performed via Bluetooth. TM , WiFi TM , Wireless communication can be performed via any of the wireless Universal Serial Bus ("USB") or infrared protocols, or via any other suitable wireless communication technology. For example, the short-range communication interface 162 is Bluetooth TM The chip is configured to be controlled by the processor 161.

[0052] The memory 163 may include non-volatile memory or volatile memory or a combination thereof, including but not limited to ROM, PROM, EEPROM, flash memory, removable memory, RAM, DRAM, SRAM, cache memory, hard disk drive, storage medium, etc. The memory 163 stores software code executed by the processor 161. The software code is configured to control the medical device 10 to perform, for example, a medical procedure and allow a user to access the medical device.

[0053] Processor 161 and memory 163 are "separate" in the sense that they are separately operable units, although they may or may not be located on a common substrate, such as in an integrated circuit, in any combination. For simplicity, Figure 2 The control device 16 of a is shown to include only one processor 161 and memory 163. However, it must be understood that the control device 16 may include a processor group including one or more processors 161, and the memory 163 may be implemented by one or more memory devices.

[0054] The control device 16 is configured to control the operation of the medical device 10, for example, to perform an intended medical procedure of the medical device 10. The control device 16 is also configured to control access to the medical device 10.

[0055] Figure 2An authentication server 20 is shown. An authentication server is a control device configured to authenticate a user to access a medical device. The authentication server 20 can be located on-site or off-site. In some embodiments, the authentication server 20 is integrated with another system such as a hospital IT system or a manufacturer service system. The authentication server 20 can be a physical device (e.g., a computer), or it can be a computer system running on multiple physical computers (e.g., in a computer cloud). In some embodiments, the authentication server 20 is a local server, such as at a hospital where the medical device 10 is used. The authentication server 20 includes a server user interface 25. The authentication server 20 includes a processor 21, a communication interface 22, and a memory 23. The processor 21 can be any commercially available processing device, for example, a CPU, a DSP, a microprocessor, an FPGA, an ASIC, or any other electronic programmable logic device or a combination thereof.

[0056] The processor 21 and memory 23 are "separate" in the sense that they are separately operable units, although they may or may not be located on a common substrate, such as in an integrated circuit, in any combination. For simplicity, Figure 2 The authentication server 20 of FIG. 1 is shown as including only one processor 21 and memory 23. However, it must be understood that the authentication server 20 may include a processor group including one or more processors 21, and the memory 23 may be implemented by one or more memory devices. The communication interface 22 is an interface for implementing communication between the authentication server 20 and other devices, for example, communicating with a remote device via the Internet.

[0057] The user may interact with the authentication server 20 via the server user interface 25. The server user interface 25 is configured to enable interaction between the authentication server 20 and the user. In some embodiments, the server user interface 25 comprises a software user interface, such as a web page interface or an application programming interface (API). Thus, the server user interface 25 may be presented on a device external to the authentication server 20, such as on an external display or a user device (e.g., a personal computer). The server interface 25 may even be generated on a remote (i.e., off-site) device that accesses the server user interface 25 via the communication interface 22. In some embodiments, the server user interface 25 is a graphical user interface that allows the user to interact with the authentication server 20 through graphical icons.

[0058] In some embodiments, server user interface 25 comprises a hardware interface that enables a user to interact with authentication server 20 using physical components such as a keyboard, mouse, and / or a display (eg, a touch screen).

[0059] Now refer to Figure 3 and Figure 4 A method for authorizing a user 2 to access a medical device 10 via a device user interface is described, the method being intended for use in the medical device 10 . Figure 3 The signaling between the medical device 10 and the authentication server 20 is shown when performing the proposed method of authorizing a user 2 to access the medical device 10 via the device user interface. Figure 4 A flow chart showing method steps performed in a medical device 10 is shown. The method is used in a medical device 10, which means that the method steps of the method are performed by one or more components in the medical device 10, for example, by the control device 16. The method may be implemented as a program code and stored in a memory 163 of the medical device 10. The steps of the method may be defined in a computer program, which includes instructions that, when the program is executed by a computer (e.g., the control device 16), cause the control device 16 to perform the method.

[0060] The method can be performed at any time when a user wants to access the medical device 10 via the device user interface 19. Typically, this is the case when the medical device 10 is not connected to the Internet or at least not connected to any service system that can automatically grant user access rights. In other words, in some embodiments, the medical device 10 is offline from the authentication server 20. Therefore, it is necessary to use the device user interface 19 to provide access. As described above, medical devices can have different types of device user interfaces 19. In some embodiments, the device user interface 19 is a human-machine interface. The human-machine interface is an interface that allows user actions to be converted into machine signals, which in turn provides the desired results to the user. For example, the human-machine interface includes buttons, one or more displays, a microphone, a speaker, etc.

[0061] In some embodiments, the device user interface 19 is a machine-machine interface configured to communicate with a user device of a user. For example, the user device is a smartphone or a wearable device. For example, the user device can be configured to read optical signals or wireless signals. For example, the user device can be configured to read a symbol sequence or a QR code. In some embodiments, the user device is a portable data storage device such as a USB memory stick. Thus, the user can retrieve data from the device user interface 19 to the portable data storage and then further transmit it to the server user interface 25.

[0062] As mentioned above, a prerequisite of the proposed solution is that the medical device 10 stores the authorized public key Q of the authorized asymmetric key pair associated with the authentication server 20 BAn authorized asymmetric key pair is pre-generated in the authentication server 20 using a predetermined algorithm. There are many algorithms that can be used to generate the key pair. Some example algorithms are Elliptic Curve Cryptography (ECC) or Rivest-Shamir-Adleman (RSA).

[0063] Authorized public key Q B It may be configured (ie, stored) in the medical device 10 during the manufacturing process of the medical device 10, or it may be included in the software of the medical device 10. In other words, the method includes storing S0 an authorized public key Q of an authorized asymmetric key pair associated with the authentication server 20 B . Authorized public key Q B should be stored so that it cannot be changed or exchanged. This can be done by any known common storage method, such as by hard-coding the authorized public key Q in the software B , or by storing it in a file in read-only memory (ROM) or in an inaccessible (at least not writable) internal file system. In practice, the authorized public key Q B Can be stored in any difficult and non-replaceable component.

[0064] For example, when a user requests access to the medical device via the device user interface 19, access authorization is initiated. This is done, for example, by pressing a button or icon on the display 12 of the medical device 10. In other words, in some embodiments, the method includes receiving S1 user input to initiate authorization of access for the user 2. Alternatively, authorization of access begins automatically, for example at startup.

[0065] In response to user input, or upon automatic initiation, an S2 temporary key pair is generated in the medical device 10 using the same algorithm as used to generate the authorized asymmetric key pair. Thus, the method includes generating an S2 temporary device asymmetric key pair, the temporary device asymmetric key pair comprising the device public key Q A and device private key d A The authorization asymmetric key pair and the device asymmetric key pair are generated so that, conversely, the same shared key is derived when using a private key d of one of the asymmetric key pairs and a public key Q of the other asymmetric key pair.

[0066] After the temporary device asymmetric key pair has been generated, an authentication challenge is presented to the user. The challenge includes a key that enables the authentication server 20 to obtain the device public key Q A In some embodiments, the challenge includes or contains the generated device public key Q A . Device public key Q AThe challenge may also include other information, such as device identification information (e.g., device identifier I or address) that enables the authentication server 20 to identify the medical device 10. For example, the device public key Q A The device identifier (e.g., serial number or media access control (MAC) address) is presented to the user. This information is represented here as a "challenge". The presentation can be on a screen and can be human-readable (e.g., a sequence of symbols) or machine-readable (e.g., a QR code or radio signal). By using an efficient public key cryptographic algorithm (e.g., elliptic curve cryptography (ECC)), the challenge can be relatively short. An ECC-160 key is 20 bytes and can be presented with 25 printable characters.

[0067] For example, if the device ID is "123456" and the device public key Q A is "36FD A6A2 13DC 2754", then the challenge presented to the user may be "12345636FD A6A213DC2754". In other words, the method includes providing S3 authorization challenge to the user 2 via the device user interface, the authorization challenge indicating the device public key Q of the temporary device asymmetric key pair generated in the medical device 10 A Note that the challenge can be unencrypted, since it does not include any secret information, but only the information needed to generate a valid response code. However, in addition to the device public key Q A In addition, any other data in the challenge can be encrypted with the shared key K, which can be used by the medical device 1 after receiving the device public key Q A Export when.

[0068] When a user has received the challenge, he or she needs to obtain the authorization key d B The authentication server 20 obtains a valid response code. To this end, the user authenticates S21 herself or himself to the authentication server 20. This can be done directly via the server user interface 25 or by a person known to the user. In the authentication server 20, the user identity and access level are checked. The user then transmits a challenge to the authentication server 20 and the authentication server 20 receives S22 the challenge. For example, the user reads the challenge presented on the display of the medical device and types it into the server user interface 25. Alternatively, the user transmits the challenge using a user device such as a smartphone or a USB memory stick. The challenge includes the device public key Q A , the device public key Q A With the system's private key d B Combined into a shared key K(Q A , d B ), the response code is returned to the user.A , d B ) refers to the use of function f(Q A , d B ) is calculated using the shared key K. In some embodiments, the shared key K(Q A , d B ) is derived using the Diffie-Hellman function.

[0069] Therefore, the authentication server 20 analyzes the challenge and calculates (ie, generates S23) the shared key K (Q A , d B ). The authentication server 20 then calculates (i.e., determines S24) the response code and uses the shared key K(Q A , d B ) encrypts S25 the response code. The response code includes validity information. The validity information is known to the medical device 10 and can be decrypted by the medical device 10 to verify that the correct shared key K (Q A , d B ) information. The response code is then presented (i.e., provided S26) to the user via the server user interface 25. The operations performed by the authentication server 20 to generate a valid response code will be described below in conjunction with Figure 5 Further description.

[0070] The user then enters the response code via the device user interface 19 of the medical device 10. In other words, the method for use in the medical device 10 includes receiving S4 a response code from the user 2 via the device user interface 19, the response code including a response code using the shared key K(Q A , d B ) encrypted validity information, the shared key K(Q A , d B ) is the authorized private key d from the authorized asymmetric key pair B and the provided device public key Q A Exportable.

[0071] Shared key K(Q A , d B ) may only be accessed by authorized private keys B and the device public key Q indicated by the challenge A The validity information is pre-agreed data. Therefore, the medical device 10 knows what validity information can be expected. Therefore, if the shared key K(Q A , d B) obtains pre-agreed validity information when decrypting the response code (or part of the response code), then this undoubtedly ensures that the response code originates from a trusted response generator (ie, the authentication server 20) and is intended for a specific challenge.

[0072] In some embodiments, the validity information includes a device identifier I of the medical device 1 provided in the challenge, such as a serial number of the medical device 10. In some embodiments, the validity information includes an address of the medical device 1 provided in the challenge, such as a MAC address of the medical device 10. In some embodiments, the validity information includes a predetermined data sequence, such as "BX" or any pre-agreed text string.

[0073] In some embodiments, the validity information includes a data sequence determined using a predetermined rule. The data sequence may be, for example, a hash or control code calculated from information included in the challenge. For example, the response code may be a cyclic redundancy check (CRC) of the challenge or a portion of the challenge. The response is encrypted using symmetric encryption, so the response does not need to be longer than the original message. The length of data in a challenge-response transaction is important when the user must manually transmit the message.

[0074] Therefore, the medical device 10 uses its temporary device private key d A The authentication server 20 (ie, the response generator) stores the authorized public key Q B Combined into the same shared key K(Q) as used in the authentication server 20 B , d A ) and decrypt the S6 response code, or at least the encrypted validity information. Here K(Q B , d A ) refers to the use of function g(Q B , d A ) is the shared key K used in calculation.

[0075] Therefore, the function g(Q B , d A ) or f(Q A , d B ) to calculate the same shared key. Therefore, the shared key K can be expressed as:

[0076] K=g(Q B , d A )=f(Q A , d B ).

[0077] In other words, the method comprises using the stored authorized public key Q B And the generated device private key d AThe same shared key K(Q B , d A Note that the derivation S5 may have been performed earlier (e.g., immediately after generating S2 the temporary device asymmetric key pair). If so, in addition to the device public key D required for the authorization server 20 to derive the shared key, A In addition, the shared key can also be used to encrypt some information included in the challenge. In some embodiments, the method also includes decrypting the validity information included in the response code using the derived same shared key S6.

[0078] If the validity information is valid, the user is authorized to access the medical device 10. In some example embodiments, the medical device 10 decrypts the validity information and verifies the response code by comparing the decrypted validity information with pre-agreed validity information, which is stored in the medical device 10 or the medical device 10 knows how to calculate it. If the response code is valid, that is, the decrypted validity information is the same or equal to the pre-agreed validity information, then access is granted. In other words, the method comprises accessing the medical device 10 using the same shared key K(Q B , d A ) decrypted validity information is valid, S7 authorizes user 2 to access the medical device 10, but the same shared key K (Q B , d A is to use the authorization public key Q stored in the medical device 10 B and the device private key d of the temporary device asymmetric key pair A Exported.

[0079] The response code may include additional information, such as the user's authorization level for the medical device 10. For example, a medical staff member may have an authorization level required for the medical device 10 to perform a medical procedure. However, a technician may not be authorized to perform a medical procedure on the medical device 10. However, a technician may be authorized to operate the medical device 10 in a test mode, update software, enter a service mode or a privileged mode, etc. Therefore, the response code may include additional information indicating which functions the user can access. In other words, in some embodiments, authorization S7 includes authorizing different access levels of the user 2 according to the information included in the response code. In some embodiments, authorization includes authorizing a certain access level of the user 2 to one or more sessions, wherein a session is, for example, a treatment course or a service session. Depending on the access level (e.g., defined by the response code), the user can perform certain operations, such as adjusting clinical restrictions, adjusting default values, adjusting the treatment settings of the course, and starting a medical procedure.

[0080] In some embodiments, the authorization includes authorization to user 2 to authorize temporary non-routine use. For example, non-routine use includes performing a session outside of normal restrictions, such as shutting down certain monitoring or security systems. Another example of non-routine use is installing specialized software, such as for non-clinical demonstrations or troubleshooting.

[0081] In some embodiments, the authorization includes unlocking the medical device for a specific use. In other words, the response code may also include other information (e.g., commercial information) that may, for example, unlock certain functions in the medical device. In this way, the authentication server may control the medical device 10. A specific example is that if the medical device was previously blocked for clinical use, the medical device may be unlocked for clinical use.

[0082] All the above examples are basically based on the proposed method being able to send authenticated data from the authorization server to the medical device 10 .

[0083] In the response code, even "authorized-authenticated" data may be transmitted to the medical device 10. That is, data may be sent that even the authenticated user is not authorized to enter into the device. For example, it may be approval for clinical use (if the device also has non-clinical software, e.g. for demonstration purposes), extended use (e.g. neonatal use, for which the medical device is not approved in the basic configuration), or the purchase of certain commercial options. Thus, important data may be centrally controlled within the organization, which is safer than delegating control to individual users.

[0084] As described above, the proposed method is generally intended for one-time use. Therefore, the response code may be valid only for a specific time period. The time may be predetermined, or it may be defined by information included in the response code. The time period may be absolute. For example, it may start at the time point when the S3 challenge is provided or at the time point when the response code is first entered. Alternatively, the time period may be determined relative to the time in the medical device 10, which requires synchronization of the clocks of the medical device 10 and the authentication server. In other words, in some embodiments, authorization S7 includes authorizing access during a specific time period. However, it must be noted that the method does not require synchronized clocks.

[0085] To improve security, the temporary device asymmetric key pair should be valid for only one authentication. Therefore, after the authorized user access, the temporary device asymmetric key pair should be invalidated. This can alternatively be done after a predetermined time period. In other words, in some embodiments, the method includes invalidating the temporary device asymmetric key pair S8. For example, the temporary key pair is deleted or invalidated in any other way.

[0086] Figure 5A flow chart of a corresponding method used in the authentication server 20 is shown. The method used in the authentication server 20 means that the method steps of the method are performed by one or more components in the authentication server 20, for example, by the processor 21. The method can be implemented as a program code stored in the memory 23 of the authentication server 20. The steps of the method can be defined in a computer program, which includes instructions, and when the program is executed by a computer (e.g., the processor 21), the instructions cause the computer to perform the method.

[0087] The method is typically performed when a user who wants to access the medical device 10 has received a challenge from the medical device 10 and needs a valid response code to access the medical device 10. For example, this may be the case when the medical device 10 is not connected to the Internet or at least not connected to any service system that can automatically grant access rights. In other words, in some embodiments, the medical device 10 is offline from the authentication server 20.

[0088] This method requires a user to interact with the authentication server 20 using the server user interface 25. It must be noted that it does not necessarily have to be the same person who will have access to the medical device 10. In principle, a technician who wants to access the medical device 10 can call someone who has access to the server user interface 25 of the authentication server 20. In this case, the challenge and response code can be communicated over the phone. This of course requires that the person who has access to the authentication server 20 recognizes the technician and can guarantee that he or she is trusted.

[0089] As explained above, the proposed solution is based on the authentication server 20 storing the authorization private key d B In other words, the method comprises storing S20 an authorized private key d of an authorized asymmetric key pair associated with the authentication server 20 B The authentication server 20 may also store the authorized public key Q B because it may be necessary to establish secure communication with other devices that do not store the authorized public key Q B . However, it is not required to perform the proposed method.

[0090] The user who has obtained the challenge must first log in to the authentication server 20. In other words, the user needs to prove his or her identity. This can be done in any conventional way, for example, using credentials or more secure authentication methods (e.g., digital certificates). However, since the authentication server 20 is, for example, part of another system such as a hospital IT system or a manufacturer's service system, this type of functionality usually already exists and must be updated with recent changes about active users anyway. In other words, the method also includes authenticating the user 2 S21. Authentication is usually done via a server user interface 25, which can be a human-machine interface, or a machine-machine interface configured to communicate with the user's user device.

[0091] The method is typically initiated by the user. The user may, for example, need to select a specific function such as "access device" or the like. The user will then be requested to enter a challenge that he has obtained from the medical device 10. In other words, the method comprises the authorization server receiving S22 an authorization challenge from the user 2 via the server user interface 25, the authorization challenge indicating the device public key Q of the temporary device asymmetric key pair associated with the medical device 10 A .

[0092] Based on the user's challenge and authentication, the authorization server 20 creates a response code. In other words, the method comprises providing S26 a response code to the user 2 via the server user interface 25, the response code comprising a response code using the shared key K(Q B , d A ) encrypted validity information, wherein the shared key is the authorization private key stored in the authentication server 20 using B and the device public key Q A As described above, the response code can be used to access, ie unlock, the medical device 10 that generated the challenge. This will now be explained in more detail.

[0093] The received challenge contains (i.e., includes) the device public key Q A , the device public key Q A With the stored authorization private key d B The authentication server 20 uses the stored authorization private key d to encrypt the message (i.e., the response code returned to the user). B and the received device public key Q A Generate S23 a shared key. The authentication server 20 also determines S24 a response code including validity information, for example based on the authentication and possibly also based on other parameters included in the challenge. These other parameters are for example a device identifier I of the medical device 1, an address of the medical device 1 or some other information.

[0094] The authentication server 20 typically has a large amount of data about the user and about different medical devices. Therefore, the medical device 10 can determine whether to trust the user to access a specific medical device 10, which is identified by, for example, a device identifier I or an address included in the challenge. In addition, in some embodiments, different access levels are determined based on the access of the authenticated user, the time of day. In some embodiments, the authorization server 20 knows the location of the user. In this case, access rights can only be granted when the user's location corresponds to the location of the medical device 10 that the user wants to access. In other words, in some embodiments, determining S24 includes determining a response code based on the device identifier I of the medical device 1, the address of the medical device 1, the authorization level of the user 2, the time parameter and / or the location of the user 2.

[0095] The authentication server 20 creates a response code that includes the pre-agreed authentication server and possibly some additional information. As described above, the information that enables the medical device 10 to verify the authentication validity information can be, for example, some information included in the challenge, such as the device identifier I of the medical device 1 or the address of the medical device. Alternatively, it can be some pre-agreed data or data calculated by pre-agreed rules. In addition to the validity information, other data can also be added to the response code. Other data can inform the medical device of the identity or access rights of the user. For example, other data can specify the access level or even include commercial information for unlocking certain functions in the medical device 10. In an example embodiment, information can be sent to unlock the medical device for certain medical purposes.

[0096] Then, the authentication server 20 uses the generated shared key K(Q A , d B ) decrypts the response code (or at least the validity information) determined by S25, and displays the encrypted response code on the server user interface 25. In some embodiments, the shared key K (Q A , d B ) is symmetric encryption, so the response code does not need to be longer than the original message (e.g., validity information). When users must manually transmit the message, the length of the data in the challenge-response transaction is important.

[0097] Since the identity of the user is not known to the medical device 10, the authentication server must keep track of the user. Therefore, a record of all created response codes should typically be stored in the authentication server 20 together with a timestamp and a user identification. In this way, it is easy to find out which user and when accessed a particular medical device 10. In other words, in some embodiments, the method includes recording S27 information associated with the authentication.

[0098] In the above protocol, there is only one key that needs to be protected (i.e., the stored authorization private key d B ). The public key is not sufficient to generate a response code, and the device public key d A It only exists briefly in the medical device 10, and a new device asymmetric key pair is generated for each transaction. Disassembling a medical device 10, decompiling the source code, and reading all the data in the internal storage will only reveal the authorized public key Q B , which is not sufficient to gain insight into another medical device 10, or even into the same medical device 10 the next time authentication is performed.

[0099] Furthermore, the proposed method enables and allows the transmission of encrypted data from a device to an authority and vice versa, since the key pair can be used to transmit virtually any information.

[0100] The present disclosure also relates to a corresponding control device 16, which is configured to execute the above method ( Figure 4 ). For example, the processor 161 of the control device 16 is configured to execute a computer program stored in the memory 163 to achieve this. Therefore, the methods mentioned herein are generally implemented as programs.

[0101] More specifically, the control device 16 is configured to cause the medical device 10 to store an authorized public key Q of an authorized asymmetric key pair associated with the authentication server 20. B , and provides an authorization challenge to the user 2 via the device user interface, the authorization challenge indicating the device public key Q of the temporary device asymmetric key pair generated in the medical device 10 A .

[0102] The control device 16 is further configured to receive a response code from the user 2 via the device user interface, the response code comprising validity information encrypted using a shared key, the shared key being an authorized private key d from an authorized asymmetric key pair. B and the provided device public key Q A and when the validity information decrypted using the same shared key is valid, the authorized user 2 accesses the medical device 10, but the same shared key is the authorization public key Q stored in the medical device 10 B and the device private key d of the temporary device asymmetric key pair A Exported.

[0103] In some embodiments, the user interface is a human-machine interface, or a machine-machine interface configured to communicate with a user device of a user.

[0104] In some embodiments, the control device 16 is configured to grant different levels of access to the user 2 depending on the information included in the response code.

[0105] In some embodiments, the control device 16 is configured to grant the user 2 access to at least one of: granting specific access to one or more sessions, unlocking the medical device for specific use, and granting temporary non-routine use.

[0106] In some embodiments, control device 16 is configured to authorize access during specific time periods.

[0107] In some embodiments, the control device 16 is configured to receive user input via the device user interface to initiate authorization of access to the user 2 .

[0108] In some embodiments, the control means 16 is configured to invalidate S8 the temporary device asymmetric key pair.

[0109] In some embodiments, the medical device 10 is offline from the authentication server 20 .

[0110] The present disclosure also relates to a method configured to perform the above method ( Figure 5 ) of the authentication server 20. For example, the processor 21 of the authentication server 20 is configured to execute a computer program stored in the memory 23 to achieve this.

[0111] More specifically, the authentication server 20 is configured to store an authorized private key d of an authorized asymmetric key pair associated with the authentication server 20. B The authentication server 20 is further configured to receive an authorization challenge from the user 2 via the server user interface 25, the authorization challenge indicating the device public key Q of the temporary device asymmetric key pair associated with the medical device 10. A and providing a response code to the user 2 via the server user interface 25, the response code including the validity information encrypted using a shared key, wherein the shared key is the authorization private key d stored in the authentication server 20 B and the device public key Q A Exported.

[0112] In some embodiments, the server interface is a human-machine interface, or a machine-machine interface configured to communicate with a user device of a user.

[0113] In some embodiments, the authentication server is configured to determine the response code based on at least one of: an authorization level of user 2 , a time parameter, and a location of user 2 .

[0114] In some embodiments, the authentication server is configured to log information associated with the authentication.

[0115] Figure 6aA medical device 10, 10' is shown in which the proposed technology can be implemented. Medical devices 10, 10' can be involved in medical procedures such as performing extracorporeal blood treatment (e.g., hemodialysis, hemodiafiltration, hemofiltration, or ultrafiltration) as part of renal replacement therapy. The medical device marked 10 is a blood treatment device, which includes a blood extraction line 11A and a blood return line 11B for connecting to the circulatory system of the object 100, for example, at a vascular inlet. As indicated by the arrows, the medical device 10 is operable to extract blood from the object 100 (e.g., a person) in a controlled manner, process the blood, and return the processed blood to the object 100. The medical device marked 10' is operable to prepare a fluid for use by the blood treatment device 10, and includes a fluid line 11 for supplying the fluid to the blood treatment device 10. In one example, the medical device 10' is a water preparation device, and the fluid is purified water. For example, as known in the art, the water treatment device 10' can filter the incoming water by reverse osmosis.

[0116] In the simplified example shown, the medical device 10 includes a fluid line 11 for connecting to a subject 100, a device user interface 19, a control device 16, one or more actuators 17 for delivering a medical fluid to the subject 100 via the fluid line 11 in a controlled manner, and one or more sensors 18 for providing sensor data indicative of an infusion process performed by an infusion pump. The actuator 17 and the sensor 18 may include internal components (as shown in dashed lines) or external components of the medical device 10, or both. The device user interface 19 includes a display 12, control buttons 13 (one is shown), an indicator light 14, and a speaker 15.

[0117] For example, the actuator 17 is configured to control a valve, a pump and / or a heater used when performing a medical procedure. In other words, the actuator 17 is arranged to control a medical procedure.

[0118] The control device 16 is configured to coordinate the operation of the actuator 17 and the sensor 18 to perform the intended medical procedure of the blood treatment device, and to operate the display 12, the indicator light 14 and the speaker 15 as needed in conjunction with the medical procedure, and to obtain user input via the control button 13. For example, the display 12 can be operated to present instructions to the user of the medical device 10, the indicator light 14 can be operated to indicate the medical device status, and the speaker 15 can be operated to generate an alarm signal, etc.

[0119] The medical device 10 is not connected to any remote system. Therefore, the medical device is offline. In particular, the medical device is not connected to any remote system. Figure 2 b) Offline.

[0120] At the level of detail shown, the medical device 10' may have a similar set of components as the medical device 10 and therefore will not be described further. The medical devices 10, 10' may include more components than shown and for the sake of brevity will not be explained here.

[0121] The medical device 10, 10' is involved in performing a medical procedure of extracorporeal blood treatment. Therefore, for patient safety reasons, it is very important to allow only trusted users to access the medical device 10, 10', as such access may compromise future treatments.

[0122] Figure 6b Another example medical device 10 is shown that is operable to deliver dialysate to the peritoneal cavity of a subject 100 in a controlled manner and subsequently remove dialysate therefrom, as indicated by the double-headed arrow. This medical procedure is often referred to as automated peritoneal dialysis, and the medical device 10 is often referred to as a "PD cycler." At the level of detail shown, the same Figure 6a Compared with 10 medical devices, Figure 6b The medical device 10 in may have a similar (but typically reduced) set of components.

[0123] Figure 6c Another example medical device 10 is shown that is operable to deliver a medical fluid into a subject 100 (e.g., a human) in a controlled manner, for example, into the circulatory system of the subject 100, as indicated by the arrows. The medical fluid may be any suitable fluid, including, but not limited to, medications and / or nutrients. This type of medical device 10 is often referred to as an "infusion pump." At the level of detail shown, as shown in FIG. Figure 6b As in the medical device 10, Figure 6c The medical device 10 in may have a similar set of components and will not be described further. Figure 6c The medical device 10 in FIG. 1 may include more components than shown, which will not be explained here for the sake of brevity.

Claims

1. A method for authorizing a user (2) to access a medical device via a device interface, the medical device being offline from an authentication server (20), the method include: In the medical device, An authorized public key (Q) of an authorized asymmetric key pair associated with the authentication server (20) is stored. B ), An authorization challenge is provided to the user (2) via the device interface, the authorization challenge indicating the device public key (Q A ), the temporary device asymmetric key pair is generated in the medical device each time the user wants to access the medical device, A response code is received from the user (2) via the device interface, the response code including validity information encrypted using a shared key, the shared key being an authorized private key (d B ) and the provided device public key (Q A ) can be exported, and When the validity information decrypted using the same shared key is valid, the user (2) is authorized to access the medical device, but the same shared key is the authorization public key (Q stored in the medical device) B ) and the device private key of the temporary device asymmetric key pair (d A ) exported.

2. The method according to claim 1, in, The device interface is a human-machine interface or a machine-machine interface configured to communicate with a user device of the user.

3. The method according to claim 1 or 2, in, The authorization includes authorizing the user (2) to different access levels according to the information included in the response code.

4. The method according to any one of the preceding claims, in, The authorization includes authorizing the user (2) to at least one of the following: authorizing specific access to one or more sessions, unlocking the medical device for specific purposes, and authorizing temporary non-routine use.

5. The method according to any one of the preceding claims, in, The authorization includes authorizing access during a specific time period.

6. The method according to any one of the preceding claims, include: User input is received to initiate access authorization for the user (2).

7. The method according to any one of the preceding claims, include: The temporary device asymmetric key pair is invalidated.

8. A method for authorizing a user (2) to access a medical device via a server user interface (25), the medical device being offline from an authentication server (20), the method include: In the authentication server (20), An authorized private key (d) of an authorized asymmetric key pair associated with the authentication server (20) is stored B ), authenticating the user (2), An authorization challenge is received from the user (2) via the server user interface (25), the authorization challenge indicating a device public key (Q A ), the temporary device asymmetric key pair is associated with the medical device and is generated in the medical device each time the user wants to access the medical device, and Providing a response code to the user (2) via the server user interface (25), the response code including validity information encrypted using a shared key, wherein the shared key is encrypted using a stored authorization private key (d B ) and the device public key (Q A ) exported.

9. The method according to claim 8, in, The server user interface is a human-machine interface or a machine-machine interface configured to communicate with a user device of the user.

10. The method according to claim 8 or 9, in, The method comprises determining (24) the response code based on at least one of: an authorization level of the user (2), a time parameter and a location of the user (2).

11. The method according to any one of claims 8 to 10, include: Records information associated with authentication.

12. The method according to any one of the preceding claims, in, The authorization asymmetric key pair and the device asymmetric key pair are generated, and the same shared key is derived when using a private key (p) of one of the asymmetric key pairs and a public key (Q) of the other asymmetric key pair.

13. The method according to any one of the preceding claims, in, The shared key is derived using the Diffie-Hellman function.

14. The method according to any one of the preceding claims, in, The authorization asymmetric key pair and the device asymmetric key pair are generated using elliptic curve cryptography (ECC) or Rivest-Shamir-Adelman (RSA) method.

15. The method according to any one of the preceding claims, in, The validity information includes at least one of: a device identifier of the medical device, an address of the medical device, a predetermined data sequence, and a data sequence determined using a predetermined rule.

16. A medical device, include: Device interface (19), The control device (16) is configured to enable the authentication server (20): An authorized public key (Q) of an authorized asymmetric key pair associated with the authentication server (20) is stored. B ), the authentication server (20) is offline from the medical device, An authorization challenge is provided to the user (2) via the device interface, the authorization challenge indicating the device public key (Q A ), the temporary device asymmetric key pair is generated in the medical device each time the user wants to access the medical device, A response code is received from the user (2) via the device interface, the response code including validity information encrypted using a shared key, the shared key being an authorized private key (d B ) and the provided device public key (Q A ) can be exported, and When the validity information decrypted using the same shared key is valid, the user (2) is authorized to access the medical device, but the same shared key is the authorization public key (Q stored in the medical device) B ) and the device private key of the temporary device asymmetric key pair (d A ) exported.

17. The medical device according to claim 16, in, The device interface is a human-machine interface or a machine-machine interface configured to communicate with a user device of the user.

18. The medical device according to claim 16 or 17, in, The control device (16) is configured to authorize different access levels to the user (2) depending on the information included in the response code.

19. The medical device according to any one of claims 16 to 18, in, The control device (16) is configured to authorize the user (2) to access at least one of the following: authorizing specific access to one or more sessions, unlocking the medical device for specific use, and authorizing temporary non-routine use.

20. The medical device according to any one of claims 16 to 19, in, The control device (16) is configured to authorize access during a specific time period.

21. The medical device according to any one of claims 16 to 20, in, The control device (16) is configured to: User input is received via the device interface to initiate access authorization for the user (2).

22. The medical device according to any one of claims 16 to 21, in, The control device (16) is configured to: The temporary device asymmetric key pair is invalidated.

23. An authentication server (20), comprising a server user interface (25), in, The authentication server (20) is configured as follows: An authorized private key (d) of an authorized asymmetric key pair associated with the authentication server (20) is stored B ), Authenticate the user (2), An authorization challenge is received from the user (2) via the server user interface (25), the authorization challenge indicating a device public key (Q A ), the temporary device asymmetric key pair is associated with a medical device and is generated in the medical device each time the user wants to access the medical device, the medical device being offline from the authentication server (20), and Providing a response code to the user (2) via the server user interface (25), the response code including validity information encrypted using a shared key, wherein the shared key is encrypted using a stored authorization private key (d B ) and the device public key (Q A ) exported.

24. The authentication server (20) according to claim 23, in, The server user interface is a human-machine interface or a machine-machine interface configured to communicate with a user device of the user.

25. The authentication server (20) according to claim 23 or 24, in, The authentication server (20) is configured to determine the response code based on at least one of: an authorization level of the user (2), a time parameter, and a location of the user (2).

26. The authentication server (20) according to any one of claims 23 to 25, in, The authentication server (20) is configured to record information associated with the authentication.

27. A computer program product comprising a computer readable medium and a computer program, the computer program being included in the computer readable medium and being characterized by code means which, when run in a computer, cause the computer to perform the method according to any one of claims 1-7 or 8-15.

28. A computer readable medium having a computer program stored thereon, the computer program being characterized by code means which, when executed in a computer, causes the computer to execute the method according to any one of claims 1-7 or 8-15.

29. A system, include: The medical device according to any one of claims 16 to 22; as well as An authentication server (20) according to any one of claims 23 to 26.

Images