(57)【要約】  サーバー１と医療デバイス３Ａ、３Ｂ、特に、注入デバイスとの間の鍵配布のための方法は、サーバー１において、医療デバイス３Ａ、３Ｂの安全なデータ通信のために使用されるべきセキュリティ鍵４Ａ、４Ｂを与えることと、サーバー１とコンピューティングデバイス２との間に第１の通信リンク１１を確立することと、コンピューティングデバイス２と医療デバイス３Ａ、３Ｂとの間に第２の通信リンク３０Ａ、３０Ｂを確立することと、コンピューティングデバイス２によって、サーバー１から第１の通信リンク１１を介してセキュリティ鍵４Ａ、４Ｂを取り出すことと、コンピューティングデバイス２によって、取り出されたセキュリティ鍵４Ａ、４Ｂを、第２の通信リンク３０Ａ、３０Ｂを介して医療デバイス３Ａ、３Ｂに送信することとを含む。このように、サーバーと医療デバイスとの間のセキュリティ鍵配布のための方法が提供され、この方法は、計算及びメモリの能力が低い医療デバイスの場合にも適している。【選択図】図１
2019509650.tif 000002
【特許請求の範囲】
【請求項１】
サーバー（１）と医療デバイス（３Ａ、３Ｂ）、特に、注入デバイスとの間の鍵配布のための方法であって、
前記サーバー（１）において、前記医療デバイス（３Ａ、３Ｂ）の安全なデータ通信のために使用されるべきセキュリティ鍵（４Ａ、４Ｂ）を与えることと、
前記サーバー（１）とコンピューティングデバイス（２）との間に第１の通信リンク（１１）を確立することと、
前記コンピューティングデバイス（２）と前記医療デバイス（３Ａ、３Ｂ）との間に第２の通信リンク（３０Ａ、３０Ｂ）を確立することと、
前記コンピューティングデバイス（２）によって、前記サーバー（１）から前記第１の通信リンク（１１）を介して前記セキュリティ鍵（４Ａ、４Ｂ）を取り出すことと、
前記コンピューティングデバイス（２）によって、前記取り出されたセキュリティ鍵（４Ａ、４Ｂ）を、前記第２の通信リンク（３０Ａ、３０Ｂ）を介して前記医療デバイス（３Ａ、３Ｂ）に送信することと、
を含む、方法。
【請求項２】
前記第１の通信リンク（１１）はインターネットプロトコルリンクである、請求項１に記載の方法。
【請求項３】
前記第１の通信リンク（１１）はＨＴＴＰＳセッションを使用する、請求項１又は２に記載の方法。
【請求項４】
前記第２の通信リンク（３０Ａ、３０Ｂ）は有線リンクである、請求項１〜３のいずれか一項に記載の方法。
【請求項５】
前記第２の通信リンク（３０Ａ、３０Ｂ）はシリアル接続である、請求項１〜４のいずれか一項に記載の方法。
【請求項６】
前記サーバー（１）は、サーバー鍵及びデバイス鍵を含む鍵対（４Ａ）を与える、請求項１〜５のいずれか一項に記載の方法。
【請求項７】
前記サーバー（１）は、多数の医療デバイス（３Ａ、３Ｂ）に関連付けられる多数の異なる専用鍵対（４Ａ、４Ｂ）を生成し、各鍵対（４Ａ、４Ｂ）は、専用サーバー鍵及び専用デバイス鍵を含む、請求項６に記載の方法。
【請求項８】
医療デバイス（３Ａ、３Ｂ）ごとに、前記関連付けられる専用鍵対（４Ａ、４Ｂ）は、前記サーバー（１）から前記コンピューティングデバイス（２）によって取り出され、前記医療デバイス（３Ａ、３Ｂ）に送信される、請求項７に記載の方法。
【請求項９】
前記鍵対（４Ａ、４Ｂ）が配布されると、前記医療デバイス（３Ａ、３Ｂ）と前記サーバー（１）との間に第３の通信リンク（３１Ａ）を確立して、前記医療デバイス（３Ａ、３Ｂ）と前記サーバー（１）との間でメッセージを送信する、請求項６〜８のいずれか一項に記載の方法。
【請求項１０】
メッセージが、前記医療デバイス（３Ａ、３Ｂ）及び前記サーバー（１）に関連付けられる前記鍵対（４Ａ、４Ｂ）の前記デバイス鍵及び前記サーバー鍵のうちの少なくとも１つを用いて生成された署名を含む、請求項９に記載の方法。
【請求項１１】
メッセージが、前記鍵対（４Ａ、４Ｂ）の前記デバイス鍵及び前記サーバー鍵のうちの少なくとも１つを用いて暗号化される、請求項９に記載の方法。
【請求項１２】
前記医療デバイス（３Ａ、３Ｂ）は、前記セキュリティ鍵（４Ａ、４Ｂ）の最初の配布後に、前記サーバー（１）にメッセージを送信することによって、新たなセキュリティ鍵（４Ａ、４Ｂ）を要求し、前記サーバー（１）は、暗号化されたメッセージにおいて、前記新たなセキュリティ鍵（４Ａ、４Ｂ）を前記医療デバイス（３Ａ、３Ｂ）に送信する、請求項１〜１１のいずれか一項に記載の方法。
【請求項１３】
サーバー（１）と医療デバイス（３Ａ、３Ｂ）、特に、注入デバイスとの間の鍵配布のためのシステムであって、該システムは、
前記医療デバイス（３Ａ、３Ｂ）の安全なデータ通信のために使用されるセキュリティ鍵（４Ａ、４Ｂ）を与えるように構成されるサーバー（１）と、
コンピューティングデバイス（２）であって、前記サーバー（１）及び該コンピューティングデバイス（２）は、前記サーバー（１）と該コンピューティングデバイス（２）との間に第１の通信リンク（１１）を確立するように構成される、コンピューティングデバイス（２）と、
医療デバイス（３Ａ、３Ｂ）であって、前記コンピューティングデバイス（２）及び該医療デバイス（３Ａ、３Ｂ）は前記コンピューティングデバイス（２）と該医療デバイス（３Ａ、３Ｂ）との間に第２の通信リンク（３０Ａ、３０Ｂ）を確立するように構成される、医療デバイス（３Ａ、３Ｂ）と、
を備え、
前記コンピューティングデバイス（２）は、前記第１の通信リンク（１１）を介して前記サーバー（１）から前記セキュリティ鍵（４Ａ、４Ｂ）を取り出し、前記取り出されたセキュリティ鍵（４Ａ、４Ｂ）を、前記第２の通信リンク（３０Ａ、３０Ｂ）を介して前記医療デバイス（３Ａ、３Ｂ）に送信するように構成される、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はサーバーと医療デバイスとの間の鍵配布のための方法及びシステムに関する。
【背景技術】
【０００２】
医療デバイスは、特に、例えば、患者のベッドサイドにあるラック上に位置する容積注入ポンプ又はシリンジ注入ポンプ等の注入デバイスとすることができる。サーバー及び医療デバイスは、例えば、病院環境内に位置することができ、例えば、インターネットプロトコル（ＩＰ）を利用して、通信ネットワークを介して互いに通信するように構成することができる。
【０００３】
医療デバイス、例えば、注入デバイスのセットアップ中、又は動作中に、サーバーと医療デバイスとの間でメッセージが交換される。これらのメッセージは運用データ及び構成データを含むことができ、それらのデータは、外部からアクセスされないように、及び認証されない第三者によって手を加えられないように保護されるべきである。
【０００４】
データを保護するために、通常、複雑な暗号（そして、電力を消費する）アルゴリズム（ＨＴＴＰＳ等）を利用する暗号化技術が使用される。しかしながら、注入ポンプ等の医療デバイスは、ＣＰＵ及びメモリの能力が限られることに起因して、サーバーと注入ポンプ等の医療デバイスとの間のセキュリティ鍵配布策が異なる解決を必要とするような、そのような複雑な暗号化アルゴリズムを使用するのに必要な計算能力を有しない場合がある。
【０００５】
一般に、対称鍵アルゴリズム及び非対称鍵アルゴリズムが知られており、暗号化のために使用される。
【０００６】
対称鍵アルゴリズムは、平文の暗号化及び暗号文の解読の両方のために同じ暗号鍵を使用する。鍵は同一の場合があるか、又は２つの鍵の間を行き来するのに簡単な変換が存在する場合がある。実際には、鍵は、２つ以上の関与者間の「共有秘密鍵（shared secret）」と呼ばれる。対称鍵暗号化の主な短所は、鍵配布脆弱性である。誰かが秘密鍵（及びデータを暗号化するためのアルゴリズム）にアクセスできる場合には、その人は秘密データにアクセスすることができる。
【０００７】
非対称鍵アルゴリズム（公開鍵暗号法）は、不可逆的な数学的特性に基づく暗号アルゴリズムの組を参照する。非対称鍵アルゴリズムは、対称鍵アルゴリズムとは異なり、関与者間で１つ（以上）の秘密鍵を最初に交換するための安全なチャネルを必要としない。非対称鍵アルゴリズムは、セキュリティアプリケーション及びプロトコル（例えば、トランスポートレイヤセキュリティ（ＴＬＳ：Transport Layer Security）又はＰＧＰ）における根本的なセキュリティ要素である。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本発明の目的は、サーバーと医療デバイスとの間のセキュリティ鍵配布のための方法及びシステムを提供することであり、そのシステムにおける方法は、計算及びメモリの能力が低い医療デバイスの場合にも適している。
【課題を解決するための手段】
【０００９】
この目的は、請求項１の特徴による方法によって果たされる。
【００１０】
したがって、本方法は、
サーバーにおいて、医療デバイスの安全なデータ通信のために使用されるべきセキュリティ鍵を与えるステップと、
サーバーとコンピューティングデバイスとの間に第１の通信リンクを確立するステップと、
コンピューティングデバイスと医療デバイスとの間に第２の通信リンクを確立するステップと、
コンピューティングデバイスによって、サーバーから第１の通信リンクを介してセキュリティ鍵を取り出すステップと、
コンピューティングデバイスによって、取り出されたセキュリティ鍵を、第２の通信リンクを介して医療デバイスに送信するステップと、
を含む。
【００１１】
本発明は、注入ポンプ等の医療デバイスのためのセキュリティ鍵管理及びブロードキャストに取り組む。本発明は、サーバーと医療デバイスとの間の安全な通信のために、サーバーと医療デバイスとの間でセキュリティ鍵を配布し、管理できるようにする。そのセキュリティ鍵配布によって、医療デバイスとサーバーとの間の暗号化された通信及び認証が可能になる。
【００１２】
それゆえ、セキュリティ鍵配布中の両方の関与者の機密保持、保全及び認証を解決する解決策が提案される。鍵配布は、２つ（以上）の関与者間で暗号鍵を配布し、暗号アルゴリズムを使用できるようにするための方法である。鍵配布の根本的な問題は、他の誰もがコピーを入手できないように鍵（又は他の必要とされる情報）を交換する方法である。本発明は、鍵を配布するために公開鍵暗号化アルゴリズムの利点（高度のセキュリティ）を享受し、メッセージを暗号化又は解読するために秘密鍵暗号化アルゴリズムの利点（簡単及び低い計算コスト）を享受する解決策を提案する。
【００１３】
サーバーから注入ポンプ等の１つ又は複数の医療デバイスに１つ又は複数のセキュリティ鍵を配布することができる。詳細には、認証を可能にし、サーバーと医療デバイスとの間の暗号化された通信を可能にするために、サーバーから特定の医療デバイスに鍵対を配布することができる。
【００１４】
別の実施形態において、サーバーから医療デバイスに、例えば、医療デバイスのＷｉＦｉ接続のためのセキュリティ鍵、例えば、ＷＰＡ２パスワード又はＲａｄｉｕｓ  Ｃｅｒｔｉｆｉｃａｔｅを配布することができる。
【００１５】
コンピューティングデバイスは、例えば、ラップトップコンピューター等のパーソナルコンピューター（ＰＣ）とすることができる。しかしながら、コンピューティングデバイスは、モバイル電話、タブレットコンピューター、又は十分な計算能力を有する別のモバイル通信デバイス等のモバイルデバイスとすることもできる。
【００１６】
サーバーがそれを介してコンピューティングデバイスに接続される第１の通信リンクは、例えば、インターネットプロトコルを利用するリンクとすることができる。そのリンクは、例えば、ＨＴＴＰＳセッションを利用することができ、それゆえ、ＨＴＴＰＳにおいて実施される暗号アルゴリズムによって保護される。それゆえ、安全が確保されたリンクを介して、特にＨＴＴＰＳセッションの状況において、サーバーからコンピューティングデバイスにセキュリティ鍵を送信できるように、コンピューティングデバイスは、好ましくは安全を確保された通信リンクを介してサーバーと通信する。
【００１７】
コンピューティングデバイスと医療デバイスとの間の第２の通信リンクは、特に、シリアルリンク（例えば、ＲＳ２３２リンク）等の有線リンクとすることができる。それゆえ、コンピューティングデバイスと医療デバイスとの間の通信を保護するために、特定の計算コストがかかるセキュリティアルゴリズムが必要とされないような専用通信回線を介して、コンピューティングデバイスは医療デバイスにローカルに接続される。
【００１８】
セキュリティ鍵はサーバーにおいて与えられ、第１の通信リンクを介して、サーバーからコンピューティングデバイスに送信される。サーバーからコンピューティングデバイスにセキュリティ鍵を送信するときに、サーバーとコンピューティングデバイスとの間の通信を保護するために、例えば、ＨＴＴＰＳセッションの状況において複雑で高度な暗号アルゴリズムを使用できるように、コンピューティングデバイスは十分な計算能力を有することができる。
【００１９】
その後、コンピューティングデバイスは、サーバーから受信されたセキュリティ鍵を、第２の通信リンクを介して医療デバイスに送信し、この場合に、コンピューティングデバイスと医療デバイスとの間に有線リンク、特にシリアルリンク等のローカルリンクが確立される場合には、暗号化は不要である。それゆえ、コンピューティングデバイスと医療デバイスとの間の通信を保護するために複雑な暗号アルゴリズムは不要であるので、医療デバイスは膨大な計算能力を必要としない。
【００２０】
一実施形態において、コンピューティングデバイスは、サーバーから医療デバイスにセキュリティ鍵を配布するためにセキュリティアプリケーションと呼ばれる専用ソフトウェアを使用する。セキュリティアプリケーションの専用ソフトウェアは、特に、サーバーとの通信を確立し、サーバーから受信されたセキュリティ鍵がコンピューティングデバイスによって記憶されるのではなく、医療デバイスに送信されるだけであり、その後、コンピューティングデバイスにおいて削除されるのを確実にする。
【００２１】
医療デバイス、例えば、注入ポンプは、医療デバイスにアクセスするときにセキュリティ鍵を読み出すことができないように構成される。
【００２２】
一実施形態において、サーバー鍵及びデバイス鍵を含む鍵対が、サーバーによって与えられ、コンピューティングデバイスから取り出され、コンピューティングデバイスによって医療デバイスに送信される。この際、サーバーは、多数の医療デバイス、例えば、異なる注入デバイスに関連付けられる多数の異なる専用の鍵対を生成することができる。それゆえ、各医療デバイスは、特定のサーバー鍵及び特定のデバイス鍵を有する専用鍵対に関連付けられ、異なる医療デバイスによって使用されるサーバー鍵及びデバイス鍵は互いに異なる。
【００２３】
例えば、医療デバイスＡはサーバー鍵Ａ及びデバイス鍵Ａを有する場合があるのに対して、医療デバイスＢはサーバー鍵Ｂ及びデバイス鍵Ｂを有する場合がある。それゆえ、異なる医療デバイスの鍵対は、互いに異なる。
【００２４】
医療デバイスごとに、鍵対は、サーバーからコンピューティングデバイスによって取り出すことができ、特定の医療デバイスに送信することができる。それゆえ、コンピューティングデバイスを介して、異なる鍵対が異なる医療デバイスに配布される。
【００２５】
鍵対が異なる医療デバイスに配布されると、例えば、注入ポンプ等の医療デバイスの動作中に、サーバーに運用データを与えるために、医療デバイスとサーバーとの間で安全な通信を行うことができる。医療デバイスとサーバーとの間の通信リンクは、例えば、標準的な通信プロトコル、例えば、ＨＴＴＰ又は任意の他の種類のプロトコル（ＩＰプロトコル及び非ＩＰプロトコル）を利用することができ、特定の医療デバイスに関連付けられる鍵対を用いて、サーバーにおいて医療デバイスを認証し、医療デバイスとサーバーとの間で送信されるメッセージを暗号化することができる。
【００２６】
例えば、それほど重要でないデータの場合、医療デバイスは、ＨＴＴＰセッション内でサーバーに平文のメッセージを送信することができ、そのメッセージは、医療デバイスに関連付けられる鍵対のデバイス鍵及びサーバー鍵のうちの少なくとも１つに従って生成される署名を有する。署名はサーバーによって読み出すことができ、署名によって、サーバーは、メッセージが信頼できる医療デバイスから受信され、第三者によって手を加えられていないことが確実にされるように、医療デバイスを認証することができる。特に、その方法が医療デバイスからサーバーへの途中において手を加えられていたなら、署名が変更されることになり、サーバーによって検出することができる。サーバーが正しい署名を受信し、検出する場合には、サーバーは、メッセージが手を加えられていなかったこと、及び認証された医療デバイスによって送信されたことがわかる。
【００２７】
信頼できない第三者によるメッセージ再生を回避するために、各メッセージは、メッセージごとに異なる署名計算を確実に得るために非固定部分（例えば、日付及び時刻）を有することができる（そうでない場合には、同じ鍵を有する同じメッセージは同じ署名を与える場合があるため）。この場合に、メッセージ本文にタイムスタンプ又はカウンターを追加することができ、サーバー及び／又は医療デバイスは、不適当なタイムスタンプ（すなわち、古すぎるタイムスタンプ）又は不適当なメッセージカウンターを有するメッセージを拒否するように構成することができる。これらの理由から、システムの各アイテム（医療デバイス、サーバー及びコンピューティングデバイス）間の時間同期が最初に実行される場合がある。
【００２８】
別の例において、医療デバイスとサーバーとの間の通信は、保護されるべきデータの場合に特に暗号化することができる。暗号化する場合、鍵対のデバイス鍵及びサーバー鍵のうちの少なくとも１つを使用することができ、医療デバイスは鍵対に従ってメッセージを暗号化し、サーバーは、医療デバイスから受信されたメッセージを、鍵対を利用して解読し、その逆もある。ここでもまた、信頼できない第三者によるメッセージ再生を回避するために、各メッセージは、メッセージごとに異なる暗号化を確実に得るために非固定部分（例えば、日付及び時刻）を有することができる（そうでない場合には、同じ鍵を有する同じメッセージは同じ暗号化を与える場合があるため）。
【００２９】
或る使用時間後、例えば、サーバーと医療デバイスとの間で所定の量のメッセージを送信した後に、医療デバイスに関連付けられるセキュリティ鍵を変更することが望ましい場合がある。セキュリティ鍵の変更は、暗号化されたメッセージをサーバーに送信することによって医療デバイスによって要求される場合があり、要求時に、サーバーは、暗号化されたメッセージにおいて、新たなセキュリティ鍵、例えば、新たな鍵対を医療デバイスに送信する。この際、新たなセキュリティ鍵が医療デバイスに送信されるメッセージは、古いセキュリティ鍵、例えば、古い鍵対を利用して暗号化される。医療デバイスにおいて、新たなセキュリティ鍵、例えば、新たな鍵対を受信すると、その後、医療デバイスとサーバーとの間の更なる通信のために、新たなセキュリティ鍵が使用される。
【００３０】
鍵変更をサーバーに通知するために、特定の変更鍵メッセージをサーバーに送信することができる。この場合、メッセージは古い鍵で暗号化される。
【００３１】
また、この目的は、サーバーと医療デバイス、特に、注入デバイスとの間の鍵配布のためのシステムであって、このシステムは、
医療デバイスの安全なデータ通信のために使用されるセキュリティ鍵を与えるように構成されるサーバーと、
コンピューティングデバイスであって、サーバー及びこのコンピューティングデバイスは、サーバーとこのコンピューティングデバイスとの間に第１の通信リンクを確立するように構成される、コンピューティングデバイスと、
医療デバイスであって、コンピューティングデバイス及びこの医療デバイスはコンピューティングデバイスとこの医療デバイスとの間に第２の通信リンクを確立するように構成される、医療デバイスと、
を備える、システムによって達成される。
この際、コンピューティングデバイスは、第１の通信リンクを介してサーバーからセキュリティ鍵を取り出し、取り出されたセキュリティ鍵を、第２の通信リンクを介して医療デバイスに送信するように構成される。
【００３２】
本方法に関して上記で説明された利点及び有利な実施形態は、上記で引用されるような、システムにも同じく当てはまる。
【００３３】
本発明の根底にある概念は、図面に示される実施形態に関して、後により詳細に説明されることになる。
【図面の簡単な説明】
【００３４】
【図１】サーバーと、コンピューティングデバイスと、多数の医療デバイスとを備えるシステムを示す図である。
【図２】認証のための署名を含むメッセージを使用する、医療デバイスとサーバーとの間の通信を示す図である。
【図３】暗号化されたメッセージを使用する、医療デバイスとサーバーとの間の通信を示す図である。
【発明を実施するための形態】
【００３５】
図１は、サーバー１と、ポータブルラップトップコンピューター等のコンピューティングデバイス２と、注入ポンプの形をとる多数の医療デバイス３Ａ、３Ｂとを備えるシステムを示す。そのシステムは、病院環境内に位置する場合があり、サーバー１は、例えば、病院内の中央位置に配置される場合があり、注入デバイス３Ａ、３Ｂは、病院の異なる部屋内の異なる病室に配置される場合がある。
【００３６】
コンピューティングデバイス２は、例えば、特定の医療デバイス３Ａ、３Ｂにローカルに接続できるようなポータブルデバイスとすることができる。
【００３７】
サーバー１と医療デバイス３Ａ、３Ｂとの間の安全な通信を可能にするために、専用鍵対４Ａ、４Ｂの形をとるセキュリティ鍵が、サーバー１から、コンピューティングデバイス２を介して異なる医療デバイス３Ａ、３Ｂに配布される。この際、鍵対４Ａ、４Ｂは、サーバー１において生成され、サーバー１の記憶装置１０内のセキュリティ鍵データベース内に記憶される。
【００３８】
図１に示されるように、サーバー１は、医療デバイス３Ａ、３Ｂごとに、専用鍵対４Ａ、４Ｂを生成する。各鍵対４Ａ、４Ｂは、サーバー鍵及びデバイス鍵を含み、サーバー鍵及びデバイス鍵は、異なる医療デバイス３Ａ、３Ｂの間で異なる。
【００３９】
医療デバイス３Ａ、３Ｂとサーバー１との間の安全な通信を可能にするために、サーバー１において生成される鍵対４Ａ、４Ｂは、異なる医療デバイス３Ａ、３Ｂに配布されなければならない。これは、コンピューティングデバイス２を介して行われる。
【００４０】
鍵対４Ａ、４Ｂを配布するために、コンピューティングデバイス２は、サーバー１との通信リンク１１を確立し、サーバー１から鍵対４Ａ、４Ｂを取り出す。コンピューティングデバイス２は、通信リンク３０Ａ、３０Ｂを介して、異なる医療デバイス３Ａ、３Ｂに（同時に、又は順次に）接続され、通信リンクは、例えば、シリアルリンク（例えば、ＲＳ２３２リンク）等の有線リンクとすることができる。ローカル通信リンク３０Ａ、３０Ｂを介して、第１の医療デバイス３Ａが第１の鍵対４Ａを受信し、第２の医療デバイス３Ｂが第２の鍵対４Ｂを受信する等のように、鍵対４Ａ、４Ｂが医療デバイス３Ａ、３Ｂに送信される。
【００４１】
サーバー１から医療デバイス３Ａ、３Ｂへの鍵対４Ａ、４Ｂの配布は、コンピューティングデバイス２上で実行されるセキュリティアプリケーションを介して行うことができる。セキュリティアプリケーションは、例えば、サーバー１への通信リンク１１を確立することができ、コンピューティングデバイス２において鍵対４Ａ、４Ｂをローカルに記憶することなく、受信された鍵対４Ａ、４Ｂを医療デバイス３Ａ、３Ｂに送信することができる。このようにして、例えば、コンピューティングデバイス２を紛失するか、又はコンピューティングデバイス２が外部から攻撃される場合に、鍵対４Ａ、４Ｂが公知にならないのを確実にする。
【００４２】
サーバー１は、コンピューティングデバイス２上で実行される特定のセキュリティアプリケーションのみが鍵対４Ａ、４Ｂを受信できるようにセットアップすることができる。それゆえ、鍵対４Ａ、４Ｂは、別のデバイス又は別のアプリケーションによって外部からアクセスすることはできない。
【００４３】
鍵対４Ａ、４Ｂは、非対称暗号アルゴリズム等の暗号アルゴリズム、例えば、トランスポートレベルセキュリティ（ＴＬＳ：Transport Level Security）又はＰＧＰ等の公開鍵法を利用して、サーバー１から、安全が確保されたリンクを介してコンピューティングデバイス２に送信される。それゆえ、サーバー１とコンピューティングデバイス２との間の通信は保護される。
【００４４】
コンピューティングデバイス２は、例えば、有線リンク３０Ａ、３０Ｂを介して、医療デバイス３Ａ、３Ｂにローカルに接続されるので、鍵対４Ａ、４Ｂは、コンピューティングデバイス２によって、暗号化を用いることなく、平文のメッセージにおいて医療デバイス３Ａ、３Ｂに送信することができる。それゆえ、医療デバイス３Ａ、３Ｂは、実質的な計算能力を必要とせず、複雑な暗号アルゴリズムを実行する必要はない。
【００４５】
鍵対４Ａ、４Ｂが配布されると、例えば、医療デバイス３Ａ、３Ｂを構成するための、又は医療デバイス３Ａ、３Ｂの動作中の、医療デバイス３Ａ、３Ｂとサーバー１との間の通信は、安全に行うことができる。
【００４６】
詳細には、図２に示されるように、医療デバイス３Ａは、医療デバイス３Ａに関連付けられる鍵対４Ａに従って生成された署名を含むデータを、平文のメッセージにおいて（例えば、ＨＴＴＰセッション内で）送信することができる。サーバー１は署名を読み出すことができ、署名と、サーバー１に知られている鍵対４Ａとに従って、メッセージが医療デバイス３Ａによって（そして、別のデバイスによってではなく）送信されたこと、及び別の関与者によって手を加えられていなかったことを検証することができる。それゆえ、署名によって、医療デバイス３Ａは認証される。
【００４７】
署名は、例えば、自らのデバイス鍵を用いて医療デバイス３Ａによって生成することができる。署名を含むメッセージを受信すると、サーバー１は、署名を計算し、計算された署名を受信された署名と比較することによって、サーバー１に知られている医療デバイス３Ａに関連付けられるデバイス鍵に従って、受信された署名を検証する。逆に、サーバー１が、サーバー鍵に従って生成された署名を含む平文のメッセージを医療デバイス３Ａに送信することができ、医療デバイス３Ａが、署名を計算し、その署名を受信された署名と比較することによって、医療デバイス３Ａに知られているサーバー鍵に従って署名を検証することができる。
【００４８】
メッセージはタイムスタンプ又はカウンターを含むことができ、それゆえ、非固定部分を有することができる。このようにして、生成された各メッセージが、鍵対４Ａに従って計算された異なる署名を有することを、特に、異なる時点で送信されたメッセージが異なる署名を有することを確実にすることができる。このようにして、信頼できない第三者によって再生されたメッセージが一致しない署名を有することになり、それを、サーバー１及び医療デバイス３Ａによってそれぞれ検出できるのを確実にすることができる。
【００４９】
さらに、図３に示されるように、医療デバイス３Ａは、医療デバイス３Ａに関連付けられる鍵対４Ａによって暗号化される、暗号化されたメッセージを（例えば、ＨＴＴＰＳセッション内で）送信することができる。暗号化されたメッセージは、サーバー１によって受信され、送信側の医療デバイス３Ａに関連付けられる鍵対４Ａを利用してサーバー１によって解読することができる。
【００５０】
ここでもまた、医療デバイス３Ａによって行われる暗号化は、医療デバイス３Ａに関連付けられるデバイス鍵を利用することができる。暗号化されたメッセージを受信すると、サーバー１は、サーバー１に知られているデバイス鍵を利用してメッセージを解読することができる。逆に、サーバー１が、サーバー鍵を用いて暗号化されたメッセージを送信することができ、医療デバイス３Ａが、医療デバイス３Ａに知られているサーバー鍵を用いて、受信されたメッセージを解読することができる。
【００５１】
ここでもまた、メッセージが非固定部分を含むように、メッセージにタイムスタンプ又はカウンターが含まれる場合がある。それゆえ、別のタイムスタンプ又は別のカウンターを有するメッセージを暗号化すると、異なる暗号化が生じ、それを、サーバー１及び医療デバイス３Ａによってそれぞれ検出できるので、信頼できない第三者によるメッセージの再生が回避される。
【００５２】
提案された方式によれば、サーバー１から医療デバイス３Ａ、３Ｂへの鍵対４Ａ、４Ｂの配布は、一般に計算コストがかかる非対称鍵アルゴリズム（公開鍵暗号法）等の高度に安全な暗号アルゴリズムを用いて、安全を確保して行われる。しかしながら、セキュリティアプリケーションを実行するコンピューティングデバイス２を介して鍵配布が行われるので、これは問題にはならない。その後、鍵配布後に、医療デバイス３Ａ、３Ｂとサーバー１との間でデータを交換するために、交換されたセキュリティ鍵４Ａ、４Ｂを用いて、医療デバイス３Ａ、３Ｂとサーバー１との間で更なる通信を行うことができる。この通信のために、共有秘密鍵を用いる対称鍵アルゴリズムを使用することができ、そのアルゴリズムは計算コストが低く、それゆえ、低い計算能力を有する可能性がある医療デバイス３Ａ、３Ｂでも問題にはならない。
【００５３】
それゆえ、提案される方式は、セキュリティ鍵の配布のための高度に安全な非対称鍵アルゴリズム（公開鍵アルゴリズム）を利用することができる。その後、実際のデータ交換及び通信のために、計算コストが低い対称鍵アルゴリズム（秘密鍵アルゴリズム）を利用することができる。それゆえ、鍵の交換は、後のデータ通信とは異なる暗号アルゴリズムを利用することができる。
【００５４】
それゆえ、医療デバイス３Ａ、３Ｂとサーバー１との間で交換されるメッセージは、医療デバイス３Ａ、３Ｂとサーバー１との間で共有される秘密鍵を用いて署名するか、又は暗号化することができる。この際、各医療デバイス３Ａ、３Ｂは、自らの秘密鍵及びサーバー鍵を記憶し、サーバー１は、デバイス鍵及び自らのサーバー鍵を記憶する。
【００５５】
この際、各医療デバイス３Ａ、３Ｂは、特定のデバイス鍵及び特定のサーバー鍵を有する専用鍵対４Ａ、４Ｂに関連付けられる。いずれの医療デバイス３Ａ、３Ｂも専用鍵対４Ａ、４Ｂに関連付けられるので、デバイス攻撃の場合にサーバー鍵が危険にさらされるのを回避することができる。
【００５６】
鍵対４Ａ、４Ｂは、例えば、デバイス構成中に（コンピューティングデバイス２上で実行されるセキュリティアプリケーションを介して）配布することができる。
【００５７】
コンピューティングデバイス２は、特定の医療デバイス３Ａ、３Ｂに関連付けられる鍵対４Ａ、４Ｂを、ローカルリンク、特に有線リンク、例えば、シリアル（ＲＳ２３２）リンクとすることができるローカルリンク３０Ａ、３０Ｂを介して特定の医療デバイス３Ａ、３Ｂに転送するので、鍵対４Ａ、４Ｂをコンピューティングデバイス２から特定の医療デバイス３Ａ、３Ｂに転送するのに特定の暗号化が使用される必要はない。それゆえ、鍵対４Ａ、４Ｂを配布するために、医療デバイス３Ａ、３Ｂ上で計算コストがかかる暗号アルゴリズムが実行される必要はない。
【００５８】
一般に、サーバー１によって生成される鍵対４Ａ、４Ｂは、例えば、ＳＨＡ−１、ＡＥＳ−１２８又はＡＥＳ−２５６アルゴリズム等の署名及び／又は暗号化アルゴリズムに準拠すべきである。
【００５９】
各医療デバイス３Ａ、３Ｂに関連付けられる秘密鍵対４Ａ、４Ｂは、サーバー１の記憶装置１０のセキュリティサーバーデータベース内に暗号化された形で記憶されるべきである。この場合、サーバー１は、内部秘密鍵を用いて、全てのセキュリティデータ、特に鍵対４Ａ、４Ｂを、記憶装置１０内の自らのデータベース内で暗号化（「ソルト（salt）」）すべきである。
【００６０】
サーバー１は、医療デバイス３Ａ、３Ｂによって使用される署名及び／又は暗号化アルゴリズム、例えば、ＳＨＡ−１、ＡＥＳ−１２８又はＡＥＳ−２５６アルゴリズムに準拠する署名及び／又は暗号化アルゴリズムをサポートすべきである。
【００６１】
使用事例の大部分において暗号化は不要である。医療デバイス３Ａ、３Ｂの計算能力及びエネルギーを節約するために（医療デバイスは、例えば、電池を用いて動作する場合がある）、任意選択で、医療デバイス３Ａ、３Ｂの側においてのみ暗号化を使用することが推奨される。それゆえ、医療デバイス３Ａ、３Ｂの側において、医療デバイス３Ａ、３Ｂに関連付けられる鍵対４Ａ、４Ｂに従って作成された署名を用いてメッセージが送信されるか否か、又は医療デバイス３Ａ、３Ｂに関連付けられる鍵対４Ａ、４Ｂを利用して秘密鍵アルゴリズムを用いてメッセージが暗号化されるか否かが選択される場合がある。
【００６２】
一般に、医療デバイス３Ａ、３Ｂに関連付けられる鍵対４Ａ、４Ｂは、頻繁に交換され、新たな鍵対４Ａ、４Ｂに置き換えられるべきである。この際、鍵を置き換える頻度は、特定の医療デバイス３Ａ、３Ｂの場合の所望のセキュリティレベルによって決まる場合がある。鍵対４Ａ、４Ｂの変更は、例えば、サーバー１に要求メッセージを送信することによって、医療デバイス３Ａ、３Ｂによってトリガーされる場合がある。このメッセージは、古い鍵対４Ａ、４Ｂを用いて医療デバイス３Ａ、３Ｂによって暗号化することができ、サーバー１に知られている古い鍵対４Ａ、４Ｂを用いてサーバー１によって解読することができる。その際、サーバー１は医療デバイス３Ａ、３Ｂに新たな鍵対４Ａ、４Ｂを含むメッセージを送信することによって応答することができ、このメッセージは再び、古い鍵対４Ａ、４Ｂを用いて暗号化することができ、古い鍵対４Ａ、４Ｂを用いて医療デバイス３Ａ、３Ｂによって解読することができる。その後、将来のメッセージの場合に、新たな鍵対４Ａ、４Ｂが使用される。
【００６３】
サーバー１は、サイバー攻撃及びローカル攻撃を受けても十分に安全であり、保護されるようにセットアップされるべきである（例えば、公開鍵インフラストラクチャにおけるＲＡＤＩＵＳ（Remote Authentication Dial-In User Serviceの省略形）サーバーに類似）。全ての鍵対４Ａ、４Ｂは、デバイス固有識別子、各鍵対４Ａ、４Ｂのサーバー鍵及びデバイス鍵をおそらく暗号化した形で記憶する、記憶装置１０のデータベース内の秘密鍵コンテナ内に記憶されるべきである。
【００６４】
サーバー１は、一実施形態において、他のデータを暗号化するために、例えば、ＡＥＳ−２５６アルゴリズムにおいて使用されるべき公開鍵／秘密鍵対を使用することができる。公開鍵／秘密鍵対も、記憶装置１０のデータベースの秘密鍵コンテナ内に記憶されるべきである。
【００６５】
コンピューティングデバイス２のセキュリティアプリケーションにおいて、例えば、Ｘ．５０９証明書に基づく信頼できる認証システムを用いて、例えば、認証を管理することができる。この際、証明書は、セキュリティアプリケーションにおいてユーザーを認証するために、ユーザーにリンクすることができる。
【００６６】
コンピューティングデバイス２のセキュリティアプリケーションは、一実施形態において、サーバー１を認証するようにセットアップすることができ（個人情報盗難を回避するため）、ユーザーにログイン名及びパスワード（例えば、いわゆる、ライトウェイトディレクトリアクセスプロトコル（ＬＤＡＰ:Lightweight Directory Access Protocol）によって管理される）を与えるように要求することによって保護されるべきである。セキュリティアプリケーションは、証明書を伴う認証（又は任意の他の認証技術）を用いて、セキュリティアプリケーションにログオンされたユーザーのユーザー識別情報をサーバー１に対して証明すべきである。
【００６７】
コンピューティングデバイス２のセキュリティアプリケーションは、ローカルリンク、例えば、ＲＳ２３２シリアルリンクを介して医療デバイス３Ａ、３Ｂに接続されると、医療デバイス３Ａ、３Ｂから固有ＩＤを取り出すようにセットアップすることができ、サーバー１から秘密鍵対４Ａ、４Ｂを要求するために、サーバー１に固有ＩＤを送信するようにセットアップすることができる。この際、セキュリティアプリケーションは、その要求に情報を追加することができる。
【００６８】
セキュリティアプリケーションがサーバー１から鍵対４Ａ、４Ｂを要求するたびに、新たな鍵対４Ａ、４Ｂが生成されるべきである。
【００６９】
医療デバイス３Ａ、３Ｂは、例えば、シリンジ注入ポンプ、又は容積（蠕動）注入ポンプ等の注入デバイスとすることができる。医療デバイス３Ａ、３Ｂは、自らを認証するための固有ＩＤを有しなければならない。医療デバイス３Ａ、３Ｂは、コンピューティングデバイス２のセキュリティアプリケーションから秘密鍵を受信できるべきであり、コンピューティングデバイス２は、例えば、ラップトップコンピューター、スマートフォン等のモバイルデバイス、又は十分な計算能力を有する別のコンピューティングデバイスとすることができる。医療デバイス３Ａ、３Ｂは、コンピューティングデバイス２のセキュリティアプリケーションを介して受信された全ての秘密鍵情報を、外部からの読出し動作から保護されるメモリ部分に記憶すべきである。詳細には、医療デバイス３Ａ、３Ｂのメンテナンス又はオペレーティングアプリケーションは、医療デバイス３Ａ、３Ｂ上に記憶された秘密鍵情報にアクセスできるべきでない。
【００７０】
医療デバイス３Ａ、３Ｂへの鍵対４Ａ、４Ｂの配布が失敗した場合、又は鍵対４Ａ、４Ｂに関する問題が生じた場合、医療デバイス３Ａ、３Ｂに新たな鍵対４Ａ、４Ｂが配布されなければならない。鍵対４Ａ、４Ｂの修復は回避されるべきである。
【００７１】
本発明は、上記の実施形態に限定されるのではなく、全く異なるように実現することもできる。
【００７２】
例えば、医療デバイス、例えば、注入ポンプ等の注入デバイスを構成するために、ＷｉＦＩ接続を与えるために、例えば、医療デバイスにＷＰＡ２パスワード又はＲＡＤＩＵＳ証明書を配布するために、医療デバイスとサーバーとの間の通信のための鍵対を配布するための上記の手法に類似の手法を適用することもできる。
【符号の説明】
【００７３】
１  セキュリティサーバー
１０  記憶装置
１１  リンク
２  コンピューティングデバイス（ＰＣ）
３Ａ、３Ｂ  医療デバイス（注入ポンプ）
３０Ａ、３０Ｂ  リンク
３１Ａ  リンク
４Ａ、４Ｂ  鍵対
【図１】
2019509650.tif 000003
【図２】
2019509650.tif 000004
【図３】
2019509650.tif 000005
【国際調査報告】
2019509650.tif 000006
2019509650.tif 000007