COMMUNICATION SECURED BETWEEN A MEDICAL DEVICE AND ITS REMOTE CONTROL DEVICE

• US 20150207626A1
• Filed: 07/09/2013
• Published: 07/23/2015
• Est. Priority Date: 07/09/2012
• Status: Abandoned Application

• Current Assignee: Debiotech S.A.
• Original Assignee: Debiotech S.A.
• Inventors: Neftel, Frdric, Proennecke, Stephan, Grigis, Christian, Bauermeister, Pascal
• Application Number:
  US14/413,857
• Publication Number:
  US 20150207626A1
• Time in Patent Office: Days
• US Class Current: 1/1
• CPC Class Codes: A61M 5/14248 of the skin patch type
• CPC Class Codes: G06F 21/35 communicating wirelessly
• CPC Class Codes: G06F 2221/2149 Restricted operating environment
• CPC Class Codes: G08C 17/02 using a radio link
• CPC Class Codes: G08C 2201/61 Password, biometric
• CPC Class Codes: G16H 40/67 for remote operation
• CPC Class Codes: H04L 2209/80 Wireless network architectures or network communication protocols for wireless network security H04W12/00
• CPC Class Codes: H04L 2209/88 Medical equipments
• CPC Class Codes: H04L 63/0435 wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption cryptographic mechanisms or cryptographic arrangements for symmetric key encryption H04L9/06
• CPC Class Codes: H04L 63/0442 wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption cryptographic mechanisms or cryptographic arrangements for public-key encryption H04L9/30
• CPC Class Codes: H04L 63/0853 using an additional device, e.g. smartcard, SIM or a different communication terminal cryptographic mechanisms or cryptographic arrangements for entity authentication involving additional secure or trusted devices H04L9/3234
• CPC Class Codes: H04L 67/12 specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
• CPC Class Codes: H04L 9/30 Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
• CPC Class Codes: H04L 9/3271 using challenge-response
• CPC Class Codes: H04W 12/10 Integrity
• CPC Class Codes: H04W 12/50 Secure pairing of devices

Abstract

The invention comprises a medical assembly composed by a medical device and a remote control which communicate in a secure and wireless manner. The remote control is connected to at least one security token. Key information stored in the medical device and the security token is used to establish a connection and to communicate in a secure manner.

Claims

1. A network node which communicates in a secure and wireless manner, said assembly comprising:

a. At least one medical node which comprises;

i. Communication means for communicating with a second node

ii. A memory which comprises at least one key information to establish and/or to communicate in a secure manner

b. A second node which comprises;

i. Communication means for communicating with the at least one medical node,

ii. At least one connecting means for connecting to at least one security token,

iii. Inputs means

iv. A CPU which is connected to said communication means, connecting means and inputs means,

c. Said at least one security token which comprises;

i. Connecting means for connecting to the second node

ii. A memory which comprises at least one key information to establish and/or to communicate in a secure manner

Wherein only one security token is paired with at least one medical node,

Wherein all or part of said key information is stored in a secure part of the memory of at least one medical node and in a secure part of the memory of the security token

Wherein no key information is exchanged by wireless communication.

Wherein said key information comprises the pairing data used to pair said nodes and/or at least one encryption key.

2. Assembly according to the claim 1, wherein said pairing data is the address of the at least one medical node, at least a partial link key, at least a partial long term key and/or at least a partial short term key.

3. Assembly according to the claim 2, wherein said pairing data is stored in a part of the memory of the security token which is readable by the second node.

4. Assembly according to the claim 1, wherein said at least one encryption key is asymmetric key or symmetric key.

5. Assembly according to the claim 2, wherein the memory of the token comprises a private key and the memory of the medical node comprises a public key associated.

6. Assembly according to the claim 2, wherein the memory of the medical node comprises a private key and the memory of the token comprises a public key associated.

7. Assembly according to the claim 1, wherein said at least one key information is shared between said at least one medical device and its security token and then said at least one key information is kept secretly in the memory of said at least one medical device and/or in the memory of the security token.

8. Assembly according to the claim 1, wherein the security token comprises a CPU.

9. Assembly according to claim 1, wherein the security token comprises a key generator.

10. Assembly according to claim 1, wherein said at least one encryption key is generated by the security token.

11. Assembly according to claim 8, wherein said at least one encryption key is transmitted to said at least one medical node by wired transmission.

12. Assembly according to claim 1, wherein said at least one medical node comprises connecting means for connecting to its security token in such a way that at least one medical node and its security token share at least one secret by wired transmission.

13. Assembly according to claim 10, comprising a pairing device which allows sharing at least one secret by wired transmission.

14. Assembly according to claim 1, wherein the private key is stored in a secure part of the security token in such a manner only the token is able to read and/or to use said private key.

15. Assembly according to claim 1, wherein the second node comprises an encryption engine.

16. Assembly according to the claim 8, wherein the security token transmits to the second node at least one encryption key.

17. Assembly according to the claim 1, wherein the second node (3) is a cell phone, a light remote control and/or a BGM or a link to a CGM.

18. Assembly according to claim 1, wherein the second node comprises at least one display means for displaying information to the user.

19. Assembly according to claim 16, wherein said at least one display means of the second node is a screen, a touchscreen and/or a LED.

20. Assembly according to claim 1, wherein the second node comprises at least one sensor means for monitoring blood glucose and/or physical activity of the user.

21. Assembly according to claim 1, wherein the second node comprises a connecting means for connecting a token which is not used with a medical node.

22. Assembly according to the claim 1, wherein the medical node is a delivery device, medical server, implantable device, a sampling device and/or sensor device

23. Assembly according to the claim 1, wherein the security token is a Smart card, Sim card, SD Card such as SDIO card (Secure Digital Input Output), an internal or external dongle

24. Assembly according to the claim 1, wherein at least one key information is the list of applications and/or software which can or not be run in the token and/or in the second node at a particular point of time.

25. Assembly according to the claim 1, wherein at least one key information is the data used to check the integrity of the application and/or the operating system and/or an upgrade version of medical application, at least during the boot.

26. Assembly according to the claim 1, wherein the second node uses a virtualization platform comprising:

a host operating system (hOS) emulating hardware components for at least one guest operating system (gOS),

a first gOS handling common functions such as but not limited to calendar or contacts, all those common functions being designed to be used in an uncontrolled environment,

a medical operating system (mOS) handling second node functions for a medical node, all those second node functions being designed to be used in a controlled environment.

27. Assembly according to the claim 12, wherein at least one key information is used to check the integrity of the hOS and/or mOS and/or gOS

28. Assembly according to the claim 12, wherein at least one key information is the list of applications and/or software which is used by the hOS to manage the priority.

29. Assembly according to the claim 1, wherein at least one key information is the address of the first node.

30. Assembly according to the claim 1, wherein at least one key information is the application and/or a specific operating system which will install in the second node.

31. Assembly according to the claim 1, wherein at least one key information is the identifier and/or the physical characteristics of the patient.

32. Assembly according to the claim 1, wherein the security token is plug into the second node or inserted in the second node or connected by wire or wireless means.

33. Assembly according to the claim 1, wherein the security token is an external dongle.

34. Assembly according to the claim 20, wherein the security token comprises inputs means, display means, activity sensor, fingerprint reader, wireless communication means or blood glucose meter.

35. Assembly according to the claim 21, wherein the wireless communication means of the security token allows connecting with the at least one medical node.

36. Assembly according to the claim 20, wherein the security token comprises connecting means for connecting another security token which is paired with another medical node.

37. Assembly according to the claim 1, wherein the second node comprises a memory in which at least one key information is at least temporarily stored.

38. Assembly according to the claim 37, wherein said at least one key information in memory of the second node is not usable if said security token is remove form said second node.

39. Assembly according to the claim 37, wherein said at least one key information, stored in the memory of the second node, is the list of applications and/or software which can or not be run in the token and/or in the second node at a particular point of time and/or the data used to check the integrity of the application and/or the operating system and/or an upgrade version of medical application, at least during the boot.

40. Assembly according to the claim 1, wherein the second node comprises other connecting means for connecting another security token which is paired with another medical node.

41. Assembly according to the claim 1, wherein said at least one medical node comprises encryption means for encrypting and/or decrypting said encrypted data;

43. Assembly according to the claim 1, wherein said at least one encryption key is kept secretly in the memory of at least one security token and wherein at least one security token comprises encryption means for encrypting and/or decrypting said encrypted data.

44. Assembly according to claim 1, wherein said at least one security token comprises processor in which is running a key generator which generates at least one encryption key.

45. Assembly according to claim 1, wherein said at least one medical node comprises processor in which is running a key generator which generates at least one encryption key.

47. Method according to the claim 31, wherein the session key Ks1 and Ks2 is equal and allow authenticating and exchanging encrypted data in secure manner.

48. Method according to claim 31, wherein the first node is the medical device or medical server and the second node is the remote control.

49. Method according to claim 31, wherein the token is a MCU, smart card, or SD card, or SIM card.

50. Method according to claim 31, wherein the encrypted keys are asymmetric or symmetric keys.

51. Method according to claim 35, wherein the encrypted key 1 is a public key and the encrypted key 2 is a private key.

52. Method according to claim 31, wherein the first node and/or the second node inform the patient that the communication is now performing in a secured manner by visual, sound indication or vibrator.

54. Process according to claim 38, wherein the means for allowing a communication between said token and said medical node is a pairing device.

55. Process according to claim 38, wherein said secret is generating by a generator included in the token.

56. Process according to claim 40, wherein said generator generates a private key which will be stored in the memory of the token and a public key associated sent to the medical node by wire connection.

57. Process according to claim 40, wherein said generator generates the pairing data to pair the medical node with another node which is connected to the token.

58. Pairing process of the assembly disclosed by the claim 1, said pairing process comprising the following steps:

Providing at least one medical node, a second node and at least one security token which is already paired with at least one medical node

Plugging at least one security token into said second node,

Using the pairing data contained in the memory of said security token and in the memory of at least one medical node to pair at least temporarily at least one medical node with said second node.

60. Process according to the claim 44, wherein said encryption key A and B is equal (symmetric key) or associated (asymmetric key).

61. Process according to the claim 44, further comprising challenge generating, secure means and/or status indication.

64. Process according to the claim 44, wherein the security token comprises display means to display the command which will be validated.

65. Process according to the claim 44, wherein the security token comprises inputs means to validate the command.

66. Assembly according to the claim 13, wherein the second node is a cell phone comprises connecting means for connecting a SIM card of the cell operator and connecting means for connecting the security node.

67. Assembly according to the claim 51, wherein said second node is also a BGM or a link to a CGM.

68. Use an assembly disclosed by the claim 52, wherein the second node is useable as a cell phone if the SIM is connected to said second node.

69. Use an assembly disclosed by the claim 52, wherein the second node is useable as a remote control for managing the medical node if the security token is connected to said second node.

70. Use an assembly disclosed by the claim 52, wherein if the SIM Card and the security token are not connected to the second node, the second node is only usable as a BGM or a link to a CGM.

71. Use an assembly disclosed by the claim 52, wherein if the SIM Card and the security token are connected to the second node, the second node is usable as a BGM, cell phone and a remote control.

42. Assembly according to any precedent claims, wherein the second node comprises encryption means for encrypting and/or decrypting said encrypted data, and wherein the said encryption key stored in the at least one security token is up-loaded in the second node by wire communication

46. A method to generate a session key to secure at least one communication between two distinct nodes, one of them comprising a token, said method comprising the following steps:

Providing two distinct nodes;

1 and 2. Said node 1 may comprise an encrypted key 1, a key generator and an encryption engine. Said node 2 comprises means for connecting to said token which may comprise an encrypted key 2, a key generator and an encryption engine.

Initialising a first communication by a first node

Generating a value V1 by the first node

Encrypting said value V1 with the key 1 (optional)

Transmitting said (encrypted) value V1 to the second node

Transmitting said (encrypted) value V1 to the token

Decrypting said value V1 with the key 2 (optional)

Generating a value V2 by the token

Computing a session key Ks1 by the token using the value V1 and V2

Encrypting said value V2 with the key 2 (optional)

Transmitting said (encrypted) value V2 to the second node

Transmitting said (encrypted) value V2 to the first node

Decrypting said value V2 with the key 1 (optional)

Computing a session key Ks2 by the first node using the value V1 and V2

62. Process according to the claim 46, wherein the secure means is a PIN Code, symbols, pictures, words, forms which must be redrawn, entered or copied to validate the command.

63. Process according to the claim 46, wherein the secure means is fingerprint readers or fingerprint retinal.

53. Process to share a secret between a node and its security token as disclosed above, the pairing process comprising the following steps:

Providing a token and a medical node

Providing a means for allowing a communication between said token and said medical node

Sharing at least one secret between the token and the medical node.

59. Loopback process between two distinct nodes, a security token and a user, the process comprising the following steps:

Receiving of a command sent by a second node to the first node

Storing said command in the memory of the first node

Encrypting said command by the first node using an encryption key A

Sending said encrypted command to the second node

Receiving said encrypted command by the second node

Sending said encrypted command to the security token

Receiving said encrypted command by the security token

Decrypting said encrypted command by the security token using an encryption key B

Displaying said command on the display means of the second node

Checking the command by the user

Validating by the user of said command using inputs means of the second node or of the security token (if it is an external CMU comprising inputs means such as a validation button)

Sending said validation to the first node to execute the command.