RU2734294C2 - Способ и система для распределения ключей между сервером и медицинским устройством - Google Patents
Способ и система для распределения ключей между сервером и медицинским устройством Download PDFInfo
- Publication number
- RU2734294C2 RU2734294C2 RU2018123489A RU2018123489A RU2734294C2 RU 2734294 C2 RU2734294 C2 RU 2734294C2 RU 2018123489 A RU2018123489 A RU 2018123489A RU 2018123489 A RU2018123489 A RU 2018123489A RU 2734294 C2 RU2734294 C2 RU 2734294C2
- Authority
- RU
- Russia
- Prior art keywords
- server
- medical device
- key
- computing device
- communication channel
- Prior art date
Links
Images
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/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
-
- 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
-
- 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
- G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
- G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
- G16H20/13—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients delivered from dispensers
-
- 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
- G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
- G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
- G16H20/17—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients delivered via infusion or injection
-
- 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
- G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
- G16H40/40—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management of medical equipment or devices, e.g. scheduling maintenance or upgrades
-
- 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
- G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
- G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
- G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
-
- 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/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0827—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving distinctive intermediate devices or communication paths
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Health & Medical Sciences (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Biomedical Technology (AREA)
- Public Health (AREA)
- Epidemiology (AREA)
- Primary Health Care (AREA)
- Medical Informatics (AREA)
- General Health & Medical Sciences (AREA)
- General Business, Economics & Management (AREA)
- General Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Computing Systems (AREA)
- Computer Hardware Design (AREA)
- Chemical & Material Sciences (AREA)
- Bioinformatics & Cheminformatics (AREA)
- Medicinal Chemistry (AREA)
- Infusion, Injection, And Reservoir Apparatuses (AREA)
- Medical Treatment And Welfare Office Work (AREA)
Abstract
Изобретение относится к способу и системе для распределения ключей между сервером и медицинским устройством. Техническим результатом является обеспечение конфиденциальности, целостности и аутентификации информации при распределении ключей безопасности между сервером и медицинским устройством, отсутствие требования наличия большой вычислительной мощности для медицинского устройства, повышение защищенности передаваемых данных. Способ распределения ключей между сервером (1) и медицинским устройством (3А, 3В), в частности инфузионным устройством, содержит: предоставление на сервере (1) ключа (4A, 4B) безопасности, который будет использоваться для безопасной передачи данных медицинского устройства (3A, 3B); установление первого канала (11) связи между сервером (1) и вычислительным устройством (2); установление второго канала (30A, 30B) связи между вычислительным устройством (2) и медицинским устройством (3A,3B); извлечение с помощью вычислительного устройства (2) ключа (4A, 4B) безопасности из сервера (1) по первому каналу (11) связи и передачу вычислительным устройством (2) извлеченного ключа (4A, 4B) безопасности в медицинское устройство (3A, 3B) по второму каналу (30A, 30B) связи. 2 н. и 11 з.п. ф-лы, 3 ил.
Description
Изобретение относится к способу и системе для распределения ключей между сервером и медицинским устройством.
Медицинское устройство, в частности, может быть инфузионным устройством, таким как волюметрический или шприцевой инфузионный насос, расположенным, например, на стойке у постели пациента. Сервер и медицинское устройство могут быть, например, расположены в больничной среде и могут быть выполнены с возможностью взаимодействовать друг с другом через сеть передачи данных, например, используя Интернет-протокол (IP).
Во время установки или во время работы медицинского устройства, например, инфузионного устройства, обмен сообщениями происходит между сервером и медицинским устройством. Эти сообщения могут содержать данные о функционировании системы, а также данные конфигурации, которые должны быть защищены от доступа извне и от манипуляции неидентифицированной третьей стороной.
Для защиты данных, как правило, используются технологии шифрования с использованием сложных криптографических (и энергопотребляющих) алгоритмов (таких как HTTPS). Однако медицинские устройства, такие как инфузионные насосы, из-за ограниченных возможностей процессора и памяти, могут не иметь необходимой вычислительной мощности для использования таких сложных алгоритмов шифрования, так что распределение ключей безопасности между сервером и медицинским устройством, таким как инфузионный насос, требует другого решения.
Вообще известны и используются для шифрования алгоритмы с симметричным ключом и алгоритмы с асимметричным ключом.
Алгоритмы с симметричным ключом используют одни и те же криптографические ключи для шифрования как открытого текста, так и для расшифровывания зашифрованного текста. Ключи могут быть идентичными, или для перехода между двумя ключами может быть простое преобразование. На практике ключ называется «разделяемым секретным ключом» между двумя или более сторонами. Основным недостатком шифрования с симметричным ключом является уязвимость распределения ключей. Если кто-либо имеет доступ к секретному ключу (и алгоритму шифрования данных), он имеет доступ к секретным данным.
Алгоритмы с асимметричным ключом (криптография с открытым ключом) относятся к набору криптографических алгоритмов, основанных на необратимых математических свойствах. Алгоритмы с асимметричным ключом, в отличие от алгоритмов с симметричным ключом, не требуют защищенного канала для первоначального обмена одним (или более) секретными ключами между сторонами. Алгоритмы с асимметричным ключом являются основными компонентами безопасности в приложениях и протоколах безопасности (например, Transport Layer Security (TLS) или PGP).
Задачей изобретения является предоставление способа и системы для распределения ключей безопасности между сервером и медицинским устройством, причем способ в системе подходит даже для медицинских устройств, имеющих низкие вычислительные возможности и возможности памяти.
Эта задача решается посредством способа в соответствии с признаками по п.1.
Соответственно, способ включает в себя этапы:
- предоставления на сервере ключа безопасности, который будет использоваться для безопасной передачи данных медицинского устройства,
- установления первого канала связи между сервером и вычислительным устройством,
- установления второго канала связи между вычислительным устройством и медицинским устройством,
- извлечение с помощью вычислительного устройства ключа безопасности из сервера по первому каналу связи и
- передачу вычислительным устройством извлеченного ключа безопасности в медицинское устройство по второму каналу связи.
Изобретение относится к управлению ключами безопасности и рассылке для медицинских устройств, таких как инфузионные насосы. Изобретение позволяет распределять и управлять ключами безопасности между сервером и медицинским устройством для обеспечения безопасной связи между сервером и медицинским устройством. С помощью распределения ключей безопасности между медицинским устройством и сервером становится возможной шифрованная связь, а также аутентификация.
Таким образом, предлагается решение для обеспечения конфиденциальности, целостности и аутентификации обеих частей при распределении ключей безопасности. Распределение ключей - это способ распределения криптографических ключей между двумя (или более) сторонами, что позволяет использовать криптографический алгоритм. Основной проблемой распределения ключей является обмен ключами (или другой необходимой информацией), чтобы никто другой не мог получить копию. Изобретение предлагает решение для получения преимущества алгоритмов шифрования с открытым ключом (высокая степень защиты) при распределении ключей и получения преимущества алгоритмов шифрования с индивидуальным ключом (простота и низкие вычислительные затраты) для шифрования или расшифровывания сообщений.
Один или несколько ключей безопасности могут распределяться сервером одному или нескольким медицинским устройствам, таким как инфузионные насосы. В частности, пара ключей может быть роздана сервером конкретному медицинскому устройству, чтобы обеспечить аутентификацию и шифрованную связь между сервером и медицинским устройством.
В другом варианте осуществления ключ безопасности, например, для связи по WI-FI сети с медицинским устройством, может быть роздан сервером медицинскому устройству, например, пароль WPA2 или сертификат Radius.
Вычислительным устройством может быть, например, персональный компьютер (ПК), например портативный компьютер. Однако вычислительное устройство может также быть мобильным устройством, таким как мобильный телефон, планшетный компьютер или другим мобильным устройством связи, обладающим достаточными вычислительными возможностями.
Первым каналом связи, через которую сервер подключается к вычислительному устройству, может быть, например, канал, использующий протокол Интернет. Канал, например, может использовать HTTPS-сеанс и, следовательно, защищен с помощью криптографических алгоритмов, реализованных в HTTPS. Таким образом, вычислительное устройство взаимодействует с сервером посредством предпочтительно защищенному каналу связи, так что ключ безопасности может быть отправлен от сервера к вычислительному устройству через защищенный канал, в частности в рамках HTTPS-сеанса.
Второй канал связи между вычислительным устройством и медицинским устройством, в частности, может быть проводной связью, такой как последовательный канал (например, канал RS232). Таким образом, вычислительное устройство локально подключено к медицинскому устройству через выделенную линию связи, так что для защиты связи между вычислительным устройством и медицинским устройством не требуются особые и затратные в вычислительном отношении алгоритмы безопасности.
Ключ безопасности предоставляется на сервере и отправляется по первому каналу связи с сервера на вычислительное устройство. Вычислительное устройство может иметь достаточную вычислительную мощность, так что сложные криптографические алгоритмы высокого уровня, например, в рамках HTTPS-сеанса, могут использоваться для защиты связи между сервером и вычислительным устройством при передаче ключа безопасности с сервера на вычислительное устройство.
Затем вычислительное устройство отправляет ключ безопасности, полученный от сервера, медицинскому устройству по второму каналу связи, причем для этого не требуется шифрование, если линия внутренней связи, такая как проводная линия связи, в частности последовательный канал, устанавливается между вычислительным устройством и медицинским устройством. Следовательно, медицинское устройство не требует большой вычислительной мощности, поскольку сложные криптографические алгоритмы не нужны для защиты связи между вычислительным устройством и медицинским устройством.
В одном из вариантов осуществления вычислительное устройство использует специальное программное обеспечение, обозначенное как приложение системы безопасности для выдачи ключа безопасности с сервера медицинскому устройству. Специальное программное обеспечение приложения системы безопасности, в частности, устанавливает связь с сервером и гарантирует, что ключ безопасности, полученный от сервера, не будет храниться на вычислительном устройстве, а отправляется только на медицинское устройство и впоследствии удаляется на вычислительном устройстве.
Медицинское устройство, например инфузионный насос, сформировано таким образом, что ключ безопасности не может быть прочитан при доступе к медицинскому устройству.
В одном из вариантов осуществления пара ключей, содержащая ключ сервера и ключ устройства, предоставляется сервером, извлекается из вычислительного устройства и отправляется вычислительным устройством в медицинское устройство. Здесь сервер может генерировать множество различных выделенных пар ключей, связанных с множеством медицинских устройств, например различных инфузионных устройств. Следовательно, каждое медицинское устройство связано с выделенной парой ключей, имеющей конкретный ключ сервера и конкретный ключ устройства, причем ключи сервера и ключи устройства, используемые различными медицинскими устройствами, отличаются друг от друга.
Например, медицинское устройство А может иметь ключ А сервера и ключ А устройства, тогда как медицинское устройство В может иметь ключ B сервера и ключ B устройства. Пары ключей различных медицинских устройств, следовательно, отличаются друг от друга.
Для каждого медицинского устройства пара ключей может быть извлечена с сервера вычислительным устройством и может быть передана конкретному медицинскому устройству. Через вычислительное устройство различные пары ключей, следовательно, распределяются между различными медицинскими устройствами.
Когда пары ключей распределяются между различными медицинскими устройствами, между медицинским устройством и сервером может быть обеспечена безопасная связь, например, во время работы медицинского устройства, такого как инфузионный насос, для предоставления оперативных данных серверу. Канал связи между медицинским устройством и сервером может, например, использовать стандартные протоколы обмена данными, например HTTP или любой другой протокол (IP и не IP протокол), в котором может использоваться пара ключей, связанная с конкретным медицинским устройством для аутентификации медицинского устройства на сервере, а также для шифрования сообщений, отправляемых между медицинским устройством и сервером.
Например, для менее важных данных медицинское устройство может отправлять сообщение открытым текстом серверу в рамках HTTP-сеанса, причем сообщение имеет подпись, сгенерированную в соответствии, по меньшей мере, с одним ключом устройства и ключом сервера из пары ключей, связанной с медицинским устройством. Подпись может быть прочитана сервером, и с помощью подписи сервер может аутентифицировать медицинское устройство таким образом, чтобы было обеспечено то, что сообщение получено от доверяемого медицинского устройства и не было обработано третьей стороной. В частности, если на способ будет оказано воздействие на пути от медицинского устройства к серверу, подпись будет изменена, что может быть обнаружено сервером. Если сервер принимает и обнаруживает правильную подпись, сервер знает, что сообщение не было подделано и было отправлено аутентифицированным медицинским устройством.
Чтобы избежать повторной передачи ранее переданного сообщения от не доверяемой третьей стороны, каждое сообщение может иметь нестационарную часть (например, дату и время), чтобы иметь уверенность, что получены различные вычисления подписи для каждого сообщения (поскольку одно и то же сообщение с тем же ключом в противном случае может содержать одну и ту же подпись). Для этого в теле сообщения может быть добавлена метка времени или счетчик, а сервер и/или медицинское устройство могут быть настроены на отклонение сообщения с плохой меткой времени (т. е. слишком старой меткой времени) или с плохим счетчиком сообщений. По этим причинам вначале может быть выполнена временная синхронизация между каждым элементом системы (медицинским устройством, сервером и вычислительным устройством).
В другом примере связь между медицинским устройством и сервером может быть зашифрована, в частности, для данных, которые должны быть защищены. Для шифрования может использоваться, по меньшей мере, один из пары ключей ключ устройства и ключ сервера, при этом медицинское устройство шифрует сообщение в соответствии с парой ключей, а сервер расшифровывает это сообщение, полученное от медицинского устройства, используя пару ключей, и наоборот. Опять же, чтобы избежать повторной передачи ранее переданного сообщения от не доверяемой третьей стороны, каждое сообщение может иметь нестационарную часть (например, дату и время), чтобы иметь уверенность, что получены различные шифрования для каждого сообщения (потому что одно и то же сообщение с тем же ключом может в противном случае предоставить такое же шифрование).
Может быть желательно изменить ключ безопасности, связанный с медицинским устройством, после некоторого времени использования, например, после отправки заданного количества сообщений между сервером и медицинским устройством. Изменение ключа безопасности может быть запрошено медицинским устройством путем отправки зашифрованного сообщения на сервер, после чего сервер отправляет новый ключ безопасности, например новую пару ключей, в зашифрованном сообщении медицинскому устройству. Здесь сообщение, в котором новый ключ безопасности отправляется в медицинское устройство, зашифровывается с использованием старого ключа безопасности, например старой пары ключей. После получения нового ключа безопасности, например новой пары ключей, на медицинском устройстве, для дальнейшей связи между медицинским устройством и сервером, используется новый ключ безопасности.
Конкретное сообщение об изменении ключа может быть отправлено на сервер, чтобы сообщить ему об изменении ключа. В этом случае сообщение зашифровывается старыми ключами.
Цель также достигается посредством системы распределения ключей между сервером и медицинским устройством, в частности инфузионным устройством, причем система содержит:
- сервер, сконфигурированный так, чтобы предоставлять ключ безопасности, который будет использоваться для безопасной передачи данных медицинского устройства,
- вычислительное устройство, причем сервер и вычислительное устройство сконфигурированы так, чтобы установить первый канал связи между сервером и вычислительным устройством,
- медицинское устройство, причем вычислительное устройство и медицинское устройство сконфигурированы так, чтобы установить второй канал связи между вычислительным устройством и медицинским устройством.
Здесь вычислительное устройство сконфигурировано так, чтобы извлекать ключ безопасности с сервера через первый канал связи и передавать извлеченный ключ безопасности в медицинское устройство по второму каналу связи.
Преимущества и предпочтительные варианты осуществления, описанные выше для этого способа, одинаково применимы и к системе, так что это должно быть отмечено ранее.
Далее идея, лежащая в основе изобретения, будет описана более подробно применительно к вариантам осуществления, показанным на чертежах. При этом,
на Фиг.1 показана система, содержащая сервер, вычислительное устройство и множество медицинских устройств;
на Фиг. 2 показана связь между медицинским устройством и сервером с использованием сообщения, содержащего подпись для аутентификации; и
на Фиг. 3 показана связь между медицинским устройством и сервером с использованием зашифрованного сообщения.
На Фиг.1 показана система, содержащая сервер 1, вычислительное устройство 2, такое как переносной компактный портативный компьютер и множество медицинских устройств 3А, 3В в форме инфузионных насосов. Система может быть расположена в больничной среде, где сервер 1 может быть помещен, например, в центральном пункте в больнице, а инфузионные устройства 3А, 3В могут быть помещены в разные палаты в разных отделениях больницы.
Вычислительное устройство 2 может быть портативным устройством, так что оно, например, может быть локально подключено к определенному медицинскому устройству 3А, 3В.
Чтобы обеспечить безопасную связь между сервером 1 и медицинскими устройствами 3А, 3В, ключи безопасности в виде выделенных пар ключей 4А, 4В распределяются сервером 1 через вычислительное устройство 2 между различными медицинскими устройствами 3А, 3B. Пары 4А, 4В ключей здесь генерируются на сервере 1 и хранятся в базе данных ключей безопасности в хранилище 10 сервера 1.
Как показано на Фиг.1, сервер 1 генерирует для каждого медицинского устройства 3А, 3В выделенную пару 4А, 4В ключей. Каждая пара 4A, 4B ключей содержит ключ сервера и ключ устройства, ключи сервера и ключи устройства различаются у различных медицинских устройств 3A, 3B.
Чтобы обеспечить безопасную связь между медицинскими устройствами 3А, 3В и сервером 1, пары 4А, 4В ключей, сгенерированные на сервере 1, должны быть распределены между различными медицинскими устройствами 3А, 3В. Это происходит через вычислительное устройство 2.
Для распределения пар 4А, 4В ключей вычислительное устройство 2 устанавливает канал 11 связи с сервером 1 и извлекает пары 4А, 4В ключей с сервера 1. Компьютерное устройство 2 соединяется с различными медицинскими устройствами 3А, 3В (единовременно или одно за другим) через каналы 30A, 30B связи, которые могут быть, например, проводными, такими как последовательные каналы (например, RS 232). Через локальные каналы 30А, 30В связи пары 4А, 4В ключей отправляются медицинским устройствам 3А, 3В, так что первое медицинское устройство 3А принимает первую пару 4А ключей, а второе медицинское устройство 3В принимает вторую пару 4В ключей и так далее.
Распределение пар 4А, 4В ключей сервером 1 медицинским устройствам 3А, 3В может осуществляться через приложение системы безопасности, выполняющееся на вычислительном устройстве 2. Приложение системы безопасности может, например, установить канал 11 связи к серверу 1 и может передавать принятые пары 4A, 4B ключей медицинским устройствам 3A, 3B, без локального хранения пар 4A, 4B ключей в вычислительном устройстве 2. Таким образом, удостоверяется, что пары 4A, 4B ключей не становятся общедоступными известно, если, например, компьютерное устройство 2 потеряно или атаковано снаружи.
Сервер 1 может быть настроен так, что только конкретное приложение системы безопасности, работающее на вычислительном устройстве 2, может принимать пары 4A, 4B ключей. Таким образом, пары 4A, 4B ключей не могут быть доступны другому устройству или другому приложению извне.
Пары 4А, 4В ключей отправляются с сервера 1 вычислительному устройству 2 через защищенную линию связи, используя криптографические алгоритмы, такие как асимметричный криптографический алгоритм, например, методы шифрования с открытым ключом, такие как безопасность транспортного уровня (TLS) или PGP. Следовательно, связь между сервером 1 и вычислительным устройством 2 защищена.
Поскольку вычислительное устройство 2 локально связано посредством, например, проводной линии 30А, 30В связи с медицинскими устройствами 3А, 3В, пары 4А, 4В ключей могут быть отправлены вычислительным устройством 2 медицинским устройствам 3А, 3В в виде сообщений открытым текстом, не используя шифрование. Медицинские устройства 3А, 3В, следовательно, не требуют значительной вычислительной мощности и не требуют выполнения сложных криптографических алгоритмов.
После распределения пар 4А, 4В ключей связь между медицинским устройством 3А, 3В и сервером 1, например, для конфигурации медицинского устройства 3А, 3В или во время работы медицинского устройства 3А, 3В, может выполняться безопасный образом.
В частности, как показано на Фиг.2, медицинское устройство 3А может отправлять данные в виде сообщения открытым текстом (например, в течение HTTP-сеанса), содержащего подпись, сгенерированную в соответствии с парой ключей 4А, связанных с медицинским устройством 3А. Сервер 1 может считывать подпись и, в соответствии с подписью и парой ключей 4A, известной серверу 1, может проверить, что сообщение было отправлено медицинским устройством 3A (а не другим устройством) и не было обработано другой стороной. Таким образом, посредством подписи, медицинское устройство 3А аутентифицируется.
Подпись может быть, например, сгенерирована медицинским устройством 3A, используя его ключ устройства. После приема сообщения, содержащего подпись, сервер 1 проверяет полученную подпись в соответствии с ключом устройства, связанным с медицинским устройством 3А, известным серверу 1, путем вычисления подписи и путем сравнения вычисленной подписи с принятой подписью. И наоборот, сервер 1 может отправлять сообщение открытым текстом медицинскому устройству 3А, содержащее подпись, сгенерированную в соответствии с ключом сервера, и медицинское устройство 3А может проверять подпись в соответствии с ключом сервера, известным медицинскому устройству 3А, путем вычисления подписи и сравнивая его с полученной подписью.
Сообщение может включать в себя метку времени или счетчик и, следовательно, может иметь нестатическую часть. Таким образом, можно убедиться, что каждое генерируемое сообщение будет иметь другую подпись, вычисленную в соответствии с парой ключей 4A. В частности, сообщение, отправленное в другое время, будет иметь другую подпись. Таким образом, можно убедиться, что сообщение, воспроизведенное от недоверяемой третьей стороны, будет иметь неподходящую подпись, которая может быть обнаружена сервером 1, соответственно, медицинским устройством 3А.
Кроме того, как показано на Фиг.3, медицинское устройство 3А может отправлять зашифрованное сообщение (например, в течение HTTPS-сеанса), которое зашифровывается парой ключей 4А, связанной с медицинским устройством 3А. Зашифрованное сообщение принимается сервером 1 и может быть расшифровано сервером 1 с использованием пары ключей 4А, связанной с отправляющим медицинским устройством 3А.
Опять же, шифрование, выполненное медицинским устройством 3А, может использовать ключ устройства, связанный с медицинским устройством 3А. После приема зашифрованного сообщения сервер 1 может расшифровать сообщение, используя ключ устройства, известный серверу 1. И наоборот, сервер 1 может отправлять сообщение, зашифрованное с использованием ключа сервера, и медицинское устройство 3A может расшифровать принятое сообщение используя ключ сервера, известный медицинскому устройству 3А.
Опять же, метка времени или счетчик могут быть включены в состав сообщения так, что сообщение содержит нестатическую часть. Следовательно, предотвращается воспроизведение сообщения от недоверяемой третьей стороны, поскольку шифрование сообщения, имеющего другую метку времени или другой счетчик, приводит к другому шифрованию, которое может быть обнаружено сервером 1, соответственно, медицинским устройством 3А.
С помощью предлагаемой схемы распределение пар ключей 4А, 4В от сервера 1 медицинским устройствам 3А, 3В осуществляется безопасным способом с использованием высокозащищенных криптографических алгоритмов, таких как алгоритмы с асимметричным ключом (криптография с открытым ключом), которые обычно являются затратными в вычислительном отношении. Однако это не создает проблемы, поскольку распределение ключей происходит через вычислительное устройство 2, работающее с приложением системы безопасности. Затем после распределения ключей дальнейшая связь между медицинским устройством 3А, 3В и сервером 1 для обмена данными между медицинским устройством 3А, 3В и сервером 1 может осуществляться с использованием переданного ключа 4А, 4В безопасности. Для этого взаимодействия может использоваться алгоритм симметричного ключа, использующий общедоступный секретный ключ, который является в менее затратным в вычислительном отношении и, следовательно, не представляет проблемы для медицинского устройства 3А, 3В, потенциально имеющего уменьшенную вычислительную мощность.
Таким образом, предлагаемая схема может использовать высокозащищенные алгоритмы асимметричного ключа (алгоритмы с открытым ключом) для распределения ключей безопасности. Для фактического обмена данными и обмена данными можно использовать алгоритмы симметричного ключа (алгоритмы с личным ключом), которые являются вычислительно менее дорогостоящими. Следовательно, обмен ключами может использовать другой криптографический алгоритм, а не последующую передачу данных.
Сообщения, которыми обмениваются медицинское устройство 3A, 3B и сервер 1, следовательно, могут быть подписаны или зашифрованы с использованием секретного ключа, доступного медицинскому устройству 3A, 3B и серверу 1. Здесь каждое медицинское устройство 3A, 3B хранит свой секретный ключ и ключ сервера, а сервер 1 хранит ключ устройства и свой ключ сервера.
Здесь каждое медицинское устройство 3А, 3В связано с выделенной парой ключей 4А, 4В, имеющей конкретный ключ устройства и конкретный ключ сервера. Поскольку каждое медицинское устройство 3А, 3В связано с выделенной парой ключей 4А, 4В, можно избежать риска для ключа сервера в случае атаки на устройства.
Пары 4А, 4В ключей могут, например, быть распределены во время конфигурации устройства (через приложение системы безопасности, выполняющемся на вычислительном устройстве 2).
Поскольку вычислительное устройство 2 передает пару 4А, 4В ключей связанную с конкретным медицинским устройством 3А, 3В через линию 30А, 30В внутренней связи, которая, в частности, может быть проводной линией, например последовательным (RS232) каналом, конкретному медицинскому устройству 3А, 3В, не требуется специальное шифрование для передачи пары 4А, 4В ключей от вычислительного устройства 2 конкретному медицинскому устройству 3А, 3В. Следовательно, на медицинских устройствах 3А, 3В не должно запускаться затратного в вычислительном отношении криптографического алгоритма для распределения пар 4А, 4В ключей.
Как правило, пары 4A, 4B ключей, генерируемые сервером 1, должны соответствовать алгоритмам подписи и/или шифрования, таким как, например, алгоритм SHA-1, AES-128 или AES-256.
Пара 4А, 4В секретных ключей, связанная с каждым медицинским устройством 3А, 3В, должна храниться в базе данных сервера безопасности хранилища 10 сервера 1 в зашифрованном виде. Для этого сервер 1 должен использовать внутренний секретный ключ для шифрования («соль») всех данных безопасности, в частности пар 4А, 4В ключей, в своей базе данных в хранилище 10.
Сервер 1 должен поддерживать алгоритм подписи и/или шифрования, совместимый с алгоритмом подписи и/или шифрования, используемым медицинским устройством 3A, 3B, например алгоритмом SHA-1, AES-128 или AES-256.
В большинстве случаев использования шифрование не требуется. Рекомендуется использовать шифрование только при необходимости со стороны медицинского устройства 3А, 3В, чтобы сохранить вычислительную мощность и энергию медицинского устройства 3А, 3В (которое может работать, например, с использованием батареи). Следовательно, на стороне медицинского устройства 3А, 3В можно выбрать, отправляется ли сообщение с использованием подписи, созданной в соответствии с парой 4А, 4В ключей, связанной с медицинским устройством 3А, 3В, или же сообщение шифруется с использованием алгоритма с личным ключом, используя пару 4А, 4В ключей, связанную с медицинским устройством 3А, 3В.
Как правило, пара 4А, 4В ключей, связанная с медицинским устройством 3А, 3В, должна обмениваться и заменяться новой парой 4А, 4В ключей на постоянной основе. Здесь частота замены ключа может зависеть от желаемого уровня безопасности для конкретного медицинского устройства 3А, 3В. Изменение пары 4A, 4B ключей может, например, запускаться медицинским устройством 3A, 3B посредством отправки сообщения запроса на сервер 1. Это сообщение может быть зашифровано с использованием старой пары 4A, 4B ключей медицинским устройством 3A, 3B и может быть расшифровано сервером 1 с использованием старой пары ключей 4A, 4B, известной серверу 1. Затем сервер 1 может ответить, отправив сообщение медицинскому устройству 4A, 4B, содержащее новую пару 4A, 4B ключей, причем это сообщение снова может быть зашифровано с использованием старой пары 4A, 4B ключей и может быть расшифровано медицинским устройством 3A, 3B с использованием старой пары ключей 4A, 4B. Затем для следующих сообщений используется новая пара ключей 4A, 4B.
Сервер 1 должен быть полностью безопасен и защищен от кибер-атаки и локальной атаки (аналогично, например, серверу RADIUS (сокращение от сервиса удаленной аутентификации пользователей) в инфраструктуре открытого ключа). Все пары 4A, 4B ключей должны храниться в контейнере секретного ключа в базе данных хранилища 10, возможно, сохраняя уникальный идентификатор устройства, ключ сервера и ключ устройства каждой пары 4A, 4B ключей в зашифрованной форме.
В одном из вариантов осуществления сервер 1 может использовать пару открытых/личных ключей, которые будут использоваться, например, в алгоритме AES-256 для шифрования других данных. Пары открытого/личного ключей также должны храниться в контейнере секретного ключа базы данных хранилища 10.
В приложении системы безопасности вычислительного устройства 2 аутентификацией можно управлять, например, используя доверенную систему аутентификации на основе, например, сертификата X.509. Здесь сертификат может быть связан с пользователем для аутентификации пользователя в приложении системы безопасности.
Приложение системы безопасности вычислительного устройства 2 может в одном варианте осуществления быть настроено на аутентификацию сервера 1 (во избежание кражи идентификационной информации) и должно быть защищено через требование к пользователю предоставить регистрационное имя и пароль (управляемый, например, посредством так называемого облегченного протокола доступа к каталогам (LDAP)). Приложение системы должно использовать аутентификацию, содержащую сертификат (или любую другую технологию аутентификации), чтобы подтвердить идентификатор пользователя для пользователя, входящего в приложение системы безопасности, на сервер 1.
Приложение системы безопасности вычислительного устройства 2 при подключении к медицинскому устройству 3А, 3В через линию внутренней связи, например последовательному каналу RS232, может быть настроено для извлечения уникального идентификатора из медицинского устройства 3А, 3В и может быть настроено для отправки уникального идентификатора на сервер 1, чтобы запросить пару 4A, 4B секретный ключей с сервера 1. Приложение системы безопасности может добавить в запрос информацию.
Каждый раз, когда приложение системы безопасности запрашивает пару 4A, 4B ключей у сервера 1, должна генерироваться новая пара 4A, 4B ключей.
Медицинское устройство 3А, 3В может представлять собой, например, инфузионное устройство, такое как шприцевой инфузионный насос или волюметрический (перистальтический) инфузионный насос. Медицинское устройство 3A, 3B должно иметь уникальный идентификатор для своей собственной аутентификации. Медицинское устройство 3А, 3В должно иметь возможность принимать секретные ключи из приложения системы безопасности вычислительного устройства 2, которое, например, может быть портативным компьютером, мобильным устройством, таким как смартфон или другое вычислительное устройство, имеющее достаточную вычислительную мощность. Медицинское устройство 3А, 3В должно хранить всю информацию секретного ключа, полученную посредством приложения системы безопасности вычислительного устройства 2, в части памяти, защищенной от внешней операции чтения. В частности, никакое техническое обслуживание или эксплуатационное применение медицинского устройства 3А, 3В не должно иметь доступа к информации секретного ключа, хранящейся на медицинском устройстве 3А, 3В.
В случае, если распределение пары ключей 4A, 4B медицинскому устройству 3A, 3B не выполняется, или в случае возникновения проблемы с парой 4A, 4B ключей новая пара 4A, 4B ключей должна быть распределена медицинскому устройству 3A, 3B. Следует избегать восстановления пары 4A, 4B ключей.
Изобретение не ограничивается описанными выше вариантами осуществления, но может быть реализовано совершенно по-другому.
Например, подобный подход, подобный описанному выше для распределения пар ключей для связи между медицинским устройством и сервером, также может применяться для конфигурирования медицинского устройства, например инфузионного устройства, такого как инфузионный насос, для обеспечения подключения к Wi-Fi, например, для выдачи пароля WPA2 или сертификата RADIUS медицинскому устройству.
СПИСОК ССЫЛОЧНЫХ ПОЗИЦИЙ
1 Сервер безопасности
10 Хранилище
11 Линия связи
2 Вычислительное устройство (PC)
3A, 3B Медицинское устройство (инфузионный насос)
30A, 30B линия связи
31A Линия связи
4A, 4B Пара ключей
Claims (28)
1. Способ распределения ключей между сервером (1) и медицинским устройством (3А, 3В), в частности инфузионным устройством, содержащий:
- предоставление на сервере (1) ключа (4A, 4B) безопасности, который будет использоваться для безопасной передачи данных медицинского устройства (3A, 3B),
- установление первого канала (11) связи между сервером (1) и вычислительным устройством (2),
- установление второго канала (30A, 30B) связи между вычислительным устройством (2) и медицинским устройством (3A,3B),
- извлечение с помощью вычислительного устройства (2) ключа (4A, 4B) безопасности из сервера (1) по первому каналу (11) связи и
- передачу вычислительным устройством (2) извлеченного ключа (4A, 4B) безопасности в медицинское устройство (3A, 3B) по второму каналу (30A, 30B) связи,
при этом данные, передаваемые между сервером (1) и вычислительным устройством (2), передаются с использованием криптографических алгоритмов, таких как асимметричный криптографический алгоритм,
связь между медицинским устройством (3A, 3B) и сервером (1) может осуществляться с использованием алгоритма симметричного ключа,
ключ (4A, 4B) безопасности, полученный от сервера (1), не хранится в вычислительном устройстве (2), а только отправляется на медицинское устройство (3A, 3B) и впоследствии удаляется.
2. Способ по п.1, в котором первый канал (11) связи является каналом связи Интернет-протокола.
3. Способ по п.1 или 2, в котором первый канал (11) связи использует HTTPS-сеанс.
4. Способ по одному из пп.1-3, в котором второй канал (30А, 30В) связи представляет собой проводную линию связи.
5. Способ по одному из предшествующих пунктов, в котором второй канал (30А, 30В) связи представляет собой последовательное соединение.
6. Способ по одному из предшествующих пунктов, в котором сервер (1) предоставляет пару (4A) ключей, содержащую ключ сервера и ключ устройства.
7. Способ по п.6, в котором сервер (1) генерирует множество различных выделенных пар ключей (4А, 4В), связанных с множеством медицинских устройств (3А, 3В), причем каждая пара ключей (4А, 4В) содержит выделенный ключ сервера и выделенный ключ устройства.
8. Способ по п.7, в котором для каждого медицинского устройства (3А, 3В) соответствующая выделенная пара ключей (4А, 4В) извлекается с сервера (1) с помощью вычислительного устройства (2) и передается в медицинское устройство (3А, 3В).
9. Способ по одному из пп.6-8, в котором, после распределения пары (4А, 4В) ключей между медицинским устройством (3А, 3В) и сервером (1), устанавливается третий канал (31А) связи для передачи сообщений между медицинским устройством (3А, 3В) и сервером (1).
10. Способ по п.9, в котором сообщение содержит подпись, сгенерированную с использованием по меньшей мере одного из: ключа устройства или ключа сервера пары ключей (4А, 4В), связанных с медицинским устройством (3А, 3В) и сервером (1).
11. Способ по п.9, в котором сообщение зашифровывается, используя по меньшей мере одно из: ключа устройства или ключа сервера пары ключей (4А, 4В).
12. Способ по одному из предшествующих пунктов, в котором медицинское устройство (1) запрашивает, после первоначального распределения ключа (4А, 4В) безопасности, новый ключ (4А, 4В) безопасности путем отправки сообщения серверу (1), а сервер (1) отправляет новый ключ (4А, 4В) безопасности в зашифрованном сообщении медицинскому устройству (3А, 3В).
13. Система распределения ключей между сервером (1) и медицинским устройством (3А, 3В), в частности инфузионным устройством, причем система содержит:
- сервер (1), сконфигурированный, чтобы предоставлять ключ (4A, 4B) безопасности, который будет использоваться для безопасной передачи данных медицинского устройства (3A, 3B),
- вычислительное устройство (2), причем сервер (1) и вычислительное устройство (2) сконфигурированы, чтобы устанавливать первый канал (11) связи между сервером (1) и вычислительным устройством (2),
- медицинское устройство (3A, 3B), причем вычислительное устройство (2) и медицинское устройство (3A, 3B) сконфигурированы, чтобы устанавливать второй канал (30A, 30B) связи между вычислительным устройством и медицинским устройством (3A, 3B),
причем вычислительное устройство (2) сконфигурировано, чтобы извлекать ключ (4A, 4B) безопасности из сервера (1) через первый канал (11) связи и передавать извлеченный ключ (4A, 4B) безопасности в медицинское устройство (3A, 3B) по второму каналу (30A, 30B) связи,
при этом данные, передаваемые между сервером (1) и вычислительным устройством (2), передаются с использованием криптографических алгоритмов, таких как асимметричный криптографический алгоритм,
связь между медицинским устройством (3A, 3B) и сервером (1) может осуществляться с использованием алгоритма симметричного ключа,
ключ (4A, 4B) безопасности, полученный от сервера (1), не хранится в вычислительном устройстве (2), а только отправляется на медицинское устройство (3A, 3B) и впоследствии удаляется.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EPEP15307034.7 | 2015-12-17 | ||
| EP15307034 | 2015-12-17 | ||
| PCT/EP2016/077133 WO2017102183A1 (en) | 2015-12-17 | 2016-11-09 | Method and system for key distribution between a server and a medical device |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| RU2018123489A RU2018123489A (ru) | 2020-01-17 |
| RU2018123489A3 RU2018123489A3 (ru) | 2020-04-08 |
| RU2734294C2 true RU2734294C2 (ru) | 2020-10-14 |
Family
ID=54979617
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| RU2018123489A RU2734294C2 (ru) | 2015-12-17 | 2016-11-09 | Способ и система для распределения ключей между сервером и медицинским устройством |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US10892893B2 (ru) |
| JP (1) | JP6976949B2 (ru) |
| CN (1) | CN108432203B (ru) |
| IL (1) | IL259306B (ru) |
| RU (1) | RU2734294C2 (ru) |
| WO (1) | WO2017102183A1 (ru) |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| ES2959510T3 (es) | 2011-10-21 | 2024-02-26 | Icu Medical Inc | Sistema de actualización de dispositivos médicos |
| EP3039596A4 (en) | 2013-08-30 | 2017-04-12 | Hospira, Inc. | System and method of monitoring and managing a remote infusion regimen |
| US10311972B2 (en) | 2013-11-11 | 2019-06-04 | Icu Medical, Inc. | Medical device system performance index |
| WO2015168427A1 (en) | 2014-04-30 | 2015-11-05 | Hospira, Inc. | Patient care system with conditional alarm forwarding |
| US9724470B2 (en) | 2014-06-16 | 2017-08-08 | Icu Medical, Inc. | System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy |
| US9539383B2 (en) | 2014-09-15 | 2017-01-10 | Hospira, Inc. | System and method that matches delayed infusion auto-programs with manually entered infusion programs and analyzes differences therein |
| CA3030786A1 (en) | 2016-07-14 | 2018-01-18 | Icu Medical, Inc. | Multi-communication path selection and security system for a medical device |
| US11416852B1 (en) * | 2017-12-15 | 2022-08-16 | Worldpay, Llc | Systems and methods for generating and transmitting electronic transaction account information messages |
| US11152109B2 (en) | 2018-07-17 | 2021-10-19 | Icu Medical, Inc. | Detecting missing messages from clinical environment |
| NZ771914A (en) | 2018-07-17 | 2023-04-28 | Icu Medical Inc | Updating infusion pump drug libraries and operational software in a networked environment |
| AU2019306492A1 (en) | 2018-07-17 | 2021-02-11 | Icu Medical, Inc. | Systems and methods for facilitating clinical messaging in a network environment |
| CN111181898A (zh) * | 2018-11-13 | 2020-05-19 | 中国石油化工股份有限公司 | 基于后台服务器、app客户端的数据安全防护方法 |
| EP3716567A1 (de) * | 2019-03-28 | 2020-09-30 | Tecpharma Licensing AG | Sichere kommunikationsverbindung zwischen medizinischen geräten einer datenmanagementvorrichtung |
| CN110535656A (zh) * | 2019-07-31 | 2019-12-03 | 阿里巴巴集团控股有限公司 | 医疗数据处理方法、装置、设备及服务器 |
| WO2021059210A1 (en) * | 2019-09-25 | 2021-04-01 | Janssen Pharmaceuticals, Inc. | Interconnection of drug administration systems |
| CN112804194B (zh) * | 2020-12-25 | 2023-05-19 | 朗坤智慧科技股份有限公司 | 基于5g的电子输注泵远程监测方法、系统和网络侧服务端 |
| WO2023144624A1 (en) * | 2022-01-25 | 2023-08-03 | Benjamin Firooz Ghassabian | Authentication circuit |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040098581A1 (en) * | 2002-08-30 | 2004-05-20 | Xerox Corporation | Method and apparatus for establishing and using a secure credential infrastructure |
| US20060218397A1 (en) * | 2005-03-22 | 2006-09-28 | Research In Motion Limited | Apparatus and methods for sharing cryptography information |
| US20110179405A1 (en) * | 2006-10-24 | 2011-07-21 | Dicks Kent E | Systems for remote provisioning of electronic devices |
| RU2471304C2 (ru) * | 2006-06-22 | 2012-12-27 | Конинклейке Филипс Электроникс, Н.В. | Усовершенствованное управление доступом для медицинских специальных сетей физиологических датчиков |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4292736B2 (ja) * | 2001-11-15 | 2009-07-08 | ソニー株式会社 | 伝送システム、伝送方法 |
| AU2003902308A0 (en) * | 2003-05-14 | 2003-05-29 | Diagnose It Pty Ltd | A method and system for the monitoring of medical conditions |
| US7155290B2 (en) * | 2003-06-23 | 2006-12-26 | Cardiac Pacemakers, Inc. | Secure long-range telemetry for implantable medical device |
| US7831828B2 (en) * | 2004-03-15 | 2010-11-09 | Cardiac Pacemakers, Inc. | System and method for securely authenticating a data exchange session with an implantable medical device |
| JP2006041726A (ja) * | 2004-07-23 | 2006-02-09 | Matsushita Electric Ind Co Ltd | 共有鍵交換システム、共有鍵交換方法及び方法プログラム |
| EP3540741B1 (en) | 2007-08-10 | 2022-10-26 | Smiths Medical ASD, Inc. | System for controlling medical devices |
| WO2009116906A1 (en) * | 2008-03-19 | 2009-09-24 | Telefonaktiebolaget Lm Ericsson (Publ) | Nfc communications for implanted medical data acquisition devices |
| US8495373B2 (en) * | 2008-10-20 | 2013-07-23 | Koninklijke Philips N.V. | Method of generating a cryptographic key, network and computer program therefor |
| EP2416522A1 (en) * | 2009-03-30 | 2012-02-08 | Panasonic Corporation | Healthcare system |
| WO2010132617A2 (en) * | 2009-05-12 | 2010-11-18 | Chronicmobile, Inc. | Methods and systems for managing, controlling and monitoring medical devices via one or more software applications functioning in a secure environment |
| US20110022414A1 (en) * | 2009-06-30 | 2011-01-27 | Yaorong Ge | Method and apparatus for personally controlled sharing of medical image and other health data |
| EP2625820B1 (en) * | 2010-10-08 | 2021-06-02 | Brian Lee Moffat | Private data sharing system |
| JP5587239B2 (ja) * | 2011-04-19 | 2014-09-10 | 株式会社日立製作所 | 車車／路車間通信システム |
| WO2012172748A1 (ja) * | 2011-06-13 | 2012-12-20 | パナソニック株式会社 | 端末装置、サーバ装置、コンテンツ記録制御システム、記録方法及び記録許否制御方法 |
| EP2874082B1 (en) * | 2012-07-16 | 2019-11-27 | BMC Medical Co., Ltd. | Information transmission method for medical equipment |
| CN104660417B (zh) * | 2015-03-17 | 2018-02-27 | 联想(北京)有限公司 | 验证方法、验证装置和电子设备 |
-
2016
- 2016-11-09 WO PCT/EP2016/077133 patent/WO2017102183A1/en active Application Filing
- 2016-11-09 CN CN201680073064.1A patent/CN108432203B/zh active Active
- 2016-11-09 US US16/061,071 patent/US10892893B2/en active Active
- 2016-11-09 RU RU2018123489A patent/RU2734294C2/ru active
- 2016-11-09 JP JP2018531463A patent/JP6976949B2/ja active Active
-
2018
- 2018-05-13 IL IL259306A patent/IL259306B/en active IP Right Grant
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040098581A1 (en) * | 2002-08-30 | 2004-05-20 | Xerox Corporation | Method and apparatus for establishing and using a secure credential infrastructure |
| US20060218397A1 (en) * | 2005-03-22 | 2006-09-28 | Research In Motion Limited | Apparatus and methods for sharing cryptography information |
| RU2471304C2 (ru) * | 2006-06-22 | 2012-12-27 | Конинклейке Филипс Электроникс, Н.В. | Усовершенствованное управление доступом для медицинских специальных сетей физиологических датчиков |
| US20110179405A1 (en) * | 2006-10-24 | 2011-07-21 | Dicks Kent E | Systems for remote provisioning of electronic devices |
Also Published As
| Publication number | Publication date |
|---|---|
| RU2018123489A3 (ru) | 2020-04-08 |
| WO2017102183A1 (en) | 2017-06-22 |
| US10892893B2 (en) | 2021-01-12 |
| US20180359085A1 (en) | 2018-12-13 |
| RU2018123489A (ru) | 2020-01-17 |
| JP2019509650A (ja) | 2019-04-04 |
| JP6976949B2 (ja) | 2021-12-08 |
| CN108432203A (zh) | 2018-08-21 |
| BR112018010343A2 (pt) | 2018-12-04 |
| CN108432203B (zh) | 2021-07-23 |
| IL259306A (en) | 2018-07-31 |
| IL259306B (en) | 2021-02-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| RU2734294C2 (ru) | Способ и система для распределения ключей между сервером и медицинским устройством | |
| CN113783836B (zh) | 基于区块链和ibe算法的物联网数据访问控制方法及系统 | |
| WO2019174187A1 (zh) | 基于区块链的多端间消息通信的方法、终端及存储介质 | |
| CN106104562B (zh) | 机密数据安全储存和恢复系统及方法 | |
| US8892886B2 (en) | Method and system for establishing cryptographic communications between a remote device and a medical device | |
| US8059818B2 (en) | Accessing protected data on network storage from multiple devices | |
| CN113497778B (zh) | 一种数据的传输方法和装置 | |
| WO2017147503A1 (en) | Techniques for confidential delivery of random data over a network | |
| EP3062546A1 (en) | Authentication module | |
| CN109951513B (zh) | 基于量子密钥卡的抗量子计算智能家庭量子云存储方法和系统 | |
| US12003629B2 (en) | Secure server digital signature generation for post-quantum cryptography key encapsulations | |
| US8397281B2 (en) | Service assisted secret provisioning | |
| CN113411187B (zh) | 身份认证方法和系统、存储介质及处理器 | |
| CN111294203B (zh) | 信息传输方法 | |
| US20240224049A1 (en) | Trust extension in a secure communication framework | |
| US20220141004A1 (en) | Efficient Internet-Of-Things (IoT) Data Encryption/Decryption | |
| Yerlikaya et al. | Authentication and authorization mechanism on message queue telemetry transport protocol | |
| EP3624394B1 (en) | Establishing a protected communication channel through a ttp | |
| CN113596004B (zh) | 多方安全计算中的身份认证方法和装置 | |
| Saxena et al. | A Lightweight and Efficient Scheme for e-Health Care System using Blockchain Technology | |
| EP3391610B1 (en) | Method and system for key distribution between a server and a medical device | |
| US10608826B2 (en) | Method for authenticating attributes in a non-traceable manner and without connection to a server | |
| CN115348578B (zh) | 一种接触者追踪方法及装置 | |
| WO2024139347A1 (zh) | 敏感信息安全获取方法、系统、装置及电子设备 | |
| BR112018010343B1 (pt) | Método e sistema para distribuição de chave entre um servidor e um dispositivo médico |