(57)【特許請求の範囲】
【請求項１】
データレコードに対するセキュアなアクセスを提供するサーバシステムであって、
複数のデータレコードを記憶する記憶手段であって、１のデータレコードに、該データレコードに対応するハードウェアトークンと共有される秘密のシーケンスが関連付けられ、前記サーバシステムが更にユーザ認証情報を記憶する、記憶手段と、
ユーザ端末からユーザの認証証明書を受信し、ユーザの該認証証明書及び前記記憶されたユーザ認証情報に基づいて、前記ユーザを、認可されたユーザとして認証するユーザ認証手段と、
前記ユーザ端末から、ハードウェアトークンによって示される秘密の表現及び該ハードウェアトークンに対応するデータレコードを識別する情報を受信する秘密受信手段と、
前記秘密の表現を、前記ハードウェアトークンに対応する前記データレコードと関連付けられた前記秘密のシーケンス内の未使用の秘密とマッチングするマッチング手段と、
前記秘密の表現が前記未使用の秘密と合致し、前記ユーザが認可されたユーザとして認証された場合、前記ハードウェアトークンに対応する前記データレコードの少なくとも一部に対するユーザアクセスを許諾するアクセス許諾手段と、
前記未使用の秘密を使用済みとマークするマーキング手段と、
を有し、
前記秘密の表現は、前記秘密の暗号化を含み、前記暗号化はキーに基づき、前記キーは、ハッシュシーケンスの一部であり、前記秘密のシーケンス内の前記秘密の位置は、前記ハッシュシーケンス内のキーの位置に対応する、サーバシステム。
【請求項２】
前記サーバシステムは、前記アクセス許諾手段が前記ユーザアクセスを許諾する前に、前記ハードウェアトークンに関連付けられている人の移動電話又は移動端末に、自動化された電話発呼を行い又はメッセージを送信する通信手段を有し、前記通信手段は、前記人が前記アクセスの許諾を拒否することを可能にするように構成される、請求項１に記載のサーバシステム。
【請求項３】
前記ユーザ端末から受信された値に基づくキーを使用して、前記データレコードの少なくとも一部を暗号化する暗号化器と、
暗号化されたデータ及び前記値からキーを計算するための情報を、前記ユーザ端末に送信するデータ送信手段と、
を有する、請求項１に記載のサーバシステム。
【請求項４】
前記データレコードの前記少なくとも一部に対し許諾される前記アクセスは、時間的に制限される、請求項１に記載のサーバシステム。
【請求項５】
前記ユーザ端末に前記キーを送信するデータ送信手段を有する、請求項１に記載のサーバシステム。
【請求項６】
請求項１に記載のサーバシステムと通信するユーザ端末と共に使用されるハードウェアトークンであって、前記ハードウェアトークンは、秘密の表現を提供する秘密提供手段を有し、前記秘密の表現は、前記秘密の暗号化を含み、前記暗号化はキーに基づき、前記キーは、ハッシュシーケンスの一部であり、前記秘密のシーケンス内の秘密の位置は、前記ハッシュシーケンス内の前記キーの位置に対応し、前記秘密提供手段は、逆順のシーケンスで前記表現を提供する、ハードウェアトークン。
【請求項７】
前記秘密の暗号化が生成されるために用いられたキーを受信して、受信されたキーを生成し、
前記受信されたキーにハッシュ関数を適用して、処理されたキーを取得し、
前記処理されたキーを記憶された値と比較する、検証器を更に有する、請求項６に記載のハードウェアトークン。
【請求項８】
請求項６に記載のハードウェアトークンの複数と、
複数のユーザ端末とを有し、
前記ユーザ端末が、
ハードウェアトークンによって示される秘密の表現及び該ハードウェアトークンに対応するデータレコードを識別する情報を受信する秘密受信手段と、
ユーザの認証証明書を受信する証明書受信器と、
前記ユーザの認証証明書、前記ハードウェアトークンによって示される前記秘密の表現、及び前記ハードウェアトークンに対応するデータレコードを識別する情報を、前記サーバシステムに送信する送信器と、
前記サーバシステムから、暗号化された形の前記データレコードの内容の少なくとも一部及びキーデータを受信するデータ受信器と、
前記受信されたキーデータにハッシュ関数を適用して処理されたキーを取得し、前記処理されたキーを前記ハードウェアトークンから受信された値と比較する検証器と、
前記キーデータに基づいて、前記データレコードの内容の少なくとも一部を解読するデータ解読器とを含む、請求項１に記載のサーバシステム。
【請求項９】
前記ユーザ端末の前記秘密受信手段は、前記ハードウェアトークンから前記表現又は前記情報を電子的に取得するトークンリーダを有する、請求項８に記載のサーバシステム。
【請求項１０】
データレコードに対するセキュアなアクセスを提供する方法であって、
複数のデータレコード及びユーザ認証情報を記憶するステップであって、１のデータレコードに、該データレコードに対応するハードウェアトークンと共有される秘密のシーケンスが関連付けられている、ステップと、
ユーザ端末からユーザの認証証明書を受信し、ユーザの該認証証明書及び前記記憶されたユーザ認証情報に基づいて、前記ユーザを認可されたユーザとして認証するステップと、
前記ユーザ端末から、前記ハードウェアトークンによって示される秘密の表現及び前記ハードウェアトークンに対応するデータレコードを識別する情報を受信するステップと、
前記秘密の表現を、前記ハードウェアトークンに対応するデータレコードに関連付けられた前記秘密のシーケンス内の未使用の秘密とマッチングするステップと、
前記秘密の表現が前記未使用の秘密と合致し、前記ユーザが認可されたユーザとして認証された場合、前記ハードウェアトークンに対応するデータレコードの少なくとも一部に対するユーザアクセスを許諾するステップと、
前記未使用の秘密を使用済みとマークするステップと、
を含み、
前記秘密の表現は、前記秘密の暗号化を含み、前記暗号化はキーに基づき、前記キーは、ハッシュシーケンスの一部であり、前記秘密のシーケンス内の前記秘密の位置は、前記ハッシュシーケンス内のキーの位置に対応する、方法。
【請求項１１】
請求項１０に記載の方法をプロセッサシステムに実施させるための命令を含むコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データレコードに対するセキュアなアクセスを提供することに関する。
【背景技術】
【０００２】
健康関連及び／又は医療データの系統的管理の必要がますます増えている。異なる病院又はクリニック、処方箋、薬剤消費ログ等の診断リポートは、セキュアに保持されることができ、このような医療データへのアクセスは、ユーザにとって便利にされることができる。このような健康データ管理アプリケーションは、例えば物忘れしやすく、彼らの健康レコードを管理する支援を必要とする高齢者及び慢性疾患に苦しむ患者のために、使用されることができる。近年、ユーザ自身によって管理されることができる個人健康記録（ＰＨＲ）の概念が提案されている。このようなＰＨＲは、ユーザの健康データを記憶し、それに対するアクセスを制御するために使用されることができる。病院からの電子医療記録（Electronic Medical Records、ＥＭＲ）及び電子健康記録（Electronic Health Records、ＥＨＲ）は、ユーザのＰＨＲにインポートされることができ、これは、インターネット接続が利用可能なときはいつでもユーザの健康データへのユビキタスアクセスを可能にする。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
省略時設定では、ＰＨＲに対するアクセスは、ユーザ自身にしか許されない。しかしながら、ユーザは、アクセス制御リスト又は他のアクセス制御機構を更に規定することができる。例えば、Julien Kunzi, Paul Koster, Milan Petkovic, Emergency Access to Protected Health Records, inK.-P. Adlassnig et al. (Eds.): Medical Informatics in a United and Healthy Europe,MIE 2009, IOS Press, 2009, pp. 705-709（以下、Kunzi他）は、ユーザ家族、友人及び親族にアクセスを許諾することを開示する。更に、高齢者は、完全な許可をより能力のある家族に許諾することによって、彼らの医療記録を管理する作業を委任することができる。医師又は救急チームが、緊急事態の状況において意識不明のユーザに処置を提供しようとするとき、このような予め規定されたアクセス制御ポリシは不十分である。ユーザが自分のパスワードを提供することができず、アクセス制御ポリシは、データへの認可されていない個人のアクセスを許さないので、救急医師及び救急チームは、ユーザのＰＨＲにアクセスすることができない。しかしながら、ユーザが緊急時に処置されている間、ユーザの健康状態に関する何らかの背景情報が提供されることができれば有益である。調査は、医師が救急処置の前に患者に関する情報にアクセスした場合、多くの致命的誤りが回避されることができることを示した。
【０００４】
Kunzi他は、救急医師によるアクセス要求を送り、これが緊急時オーバーライドであることを示すことを開示している。要求しているエンティティが適当な証明書を有する場合、すなわち、要求しているエンティティが資格をもった医師である場合、アクセスは許諾され、ログに記録される。その後、アクセスログは、事後アクセス監査が、ユーザの健康データに対するアクセスが合法的であるかどうかを判定するために、使用される。しかしながら、緊急時オーバーライドが悪意のあるものである場合、このようなメカニズムは、ユーザの健康データのプライバシー権利を侵害するので、効果的でない。本質的に、監査は、ＰＨＲに対する悪意のあるアクセスを防ぐための予防的手段ではない。
【０００５】
緊急事態の状況において、ユーザは意識不明であるので、ユーザは、ＰＨＲへのアクセスを可能にするために自分のパスワードを提供することができない。従って、これは、ユーザのＰＨＲに対する緊急時アクセスの必要をトリガする。しかしながら、ＰＨＲサーバが、ＰＨＲにアクセスするための真の緊急事態の状況と悪意のある試みとを区別することは困難である。なぜなら、いずれの場合も、ユーザは応対できないからである。
【０００６】
"Implementing Security And Access Control Mechanisms For An Electronic Healthcare Record", Frank K. Uckert et al, AMIA 2002 Annual Symposium Proceedingsは、ユーザがユーザのレコードを使用可能にし、ユーザのレコード内でこれを規定することによって、彼のＥＨＲの緊急時サブセットに対する読み取りアクセスを提供することができるシステムを開示している。この特徴が使用可能にされる場合、緊急時ＴＡＮが生成される。小さい財布カードに印刷されるウェブアドレス、ユーザ名及びこの緊急時ＴＡＮの組み合わせが、患者によって携行されることができ、この患者の緊急時に、任意の他の人によって使用されることができる。ＴＡＮ（＝トランザクション番号）によって、ユーザは、ただ１回のセッションについて、ユーザの健康レコードの一部へのアクセスを、何人にも与えることができる。ＴＡＮの原理は、インターナショナルオンラインバンキングから知られているものと同様である。１回の使用後、ＴＡＮは無効である。新しいＴＡＮが、必要に応じてユーザによって生成されることができる。
【０００７】
データレコードに対するセキュアなアクセスを提供するための改善されたシステムを有することが有利である。
【課題を解決するための手段】
【０００８】
この問題により良く対処するために、本発明の第１の見地は、複数のデータレコードを記憶する記憶手段であって、１のデータレコードには、該データレコードに対応するハードウェアトークンと共有される秘密のシーケンスが関連付けられ、サーバシステムが、複数ユーザの複数の認証証明書を記憶する、記憶手段と、ユーザ端末からユーザの認証証明書を受信し、ユーザの認証証明書に基づいて、ユーザをサーバシステムのユーザとして認証するユーザ認証手段と、ユーザ端末から、ハードウェアトークンによって示される秘密の表現及びハードウェアトークンに対応するデータレコードを識別する情報を受信する秘密受信手段と、前記秘密の表現を、ハードウェアトークンに対応するデータレコードと関連付けられる秘密のシーケンス内の未使用の秘密とマッチングするマッチング手段と、秘密の表現が未使用の秘密と合致し、ユーザがサーバシステムのユーザとして認証された場合、ハードウェアトークンに対応するデータレコードの少なくとも一部に対するユーザアクセスを許諾するアクセス許諾手段と、未使用の秘密を使用済みとしてマークするマーキング手段と、を有するサーバシステムを提供する。
【０００９】
サーバシステムは、改善されたセキュリティを提供することができる。ユーザ認証手段は、認可された人のみがデータレコードにアクセスできることを確実にする。例えば、救急従事者のみが認可証明書を与えられる（任意には、これらの証明書は、彼らの勤務シフトの最中にのみ有効にされる）。更に、秘密受信手段及びマッチング手段は、データレコードを識別し、ユーザが専門家としてデータレコードにアクセスすることを必要としている証拠を提供するために、使用される。なぜなら、他の場合に、ユーザは、秘密の表現をその上にもつハードウェアトークンを所有しないからである。ユーザ認証が用いられない場合、カードを見つけ又は盗む者は誰でも、データレコードにアクセスすることができてしまうので、ユーザ認証とハードウェアトークンから受信された秘密の表現との組み合わせは、改善されたセキュリティを提供する。
【００１０】
ハードウェアトークンは、秘密のシーケンスの表現を生成することができるので、ハードウェアトークンは、複数回使用されることができる。未使用の秘密のみが有効であるので、各々の秘密は、データレコードに対するワンタイムアクセスのみを許諾する。
【００１１】
サーバシステムは、アクセス許諾手段がユーザアクセスを許諾する前に、ハードウェアトークンに関連付けられている人の移動電話又は移動端末に自動化された電話発呼を行い又はメッセージを送信する通信手段を有することができ、通信手段は、その人が、アクセスの許諾を拒否することができるように構成される。例えば、人は、自動化された発呼の最中に電話のボタンを押すことによって、又は返信メッセージを送ることによって、アクセスを許諾することを拒否することができる。このように、その人の意識があるかどうかがテストされる。人が発呼に応答しない又はメッセージを返信しない場合、これは、その人が意識不明であるせいかもしれず、システムは、データレコードに対するアクセスを許す。
【００１２】
アクセス許諾手段は、ユーザ端末から受信された値に基づくキーを使用して、データレコードの少なくとも一部を暗号化し、ユーザ端末に、暗号化されたデータ及び前記値からキーを計算するための情報を送信する暗号化器を有することができる。このように、ユーザ端末のみがデータを解読することができることが確実にされる。
【００１３】
データレコードの少なくとも一部に対し許諾されるアクセスは、時間を制限されることができる。このように、緊急事態の状況がもはやないときに、データレコードが閲覧可能になることが回避される。
【００１４】
秘密の表現は、秘密の暗号化を含むことができ、暗号化はキーに基づくことができ、キーは、ハッシュシーケンスの一部でありえ、秘密のシーケンス内の秘密の位置は、ハッシュシーケンスのキーの位置に対応しうる。このように、シーケンス内の各々の秘密は、それぞれ異なって暗号化される。トークン及びサーバシステムは、同じキーのシーケンスを使用することができる。暗号化されたキーの完全なシーケンスは、ハッシュシーケンスによって再計算されることができるので、サーバシステムは、暗号化されたキーの完全なシーケンスを記憶する必要がない。
【００１５】
サーバシステムは、ユーザ端末に、秘密のシーケンス内の秘密の位置に対応するハッシュシーケンス内のキーを送信するように構成されるデータ送信手段を有することができる。ハッシュ関数を適用することによって、ユーザ端末又はハードウェアトークンは、ハッシュシーケンス内の他のキーの１又は複数を計算することができる。ユーザ端末又はトークンは、これらの計算された値を、記憶されている値と比較することができる。例えば、ハードウェアトークンが発行される前に、ハッシュチェーン内の最後のキーが、ハードウェアトークンに記憶される。これは、サーバの認証を提供し、又は正しいデータレコードが取得されることを端末が検証できる方法を提供する。
【００１６】
別の見地において、本発明は、ハードウェアトークンを提供する。このハードウェアトークンは、上述のサーバシステムと通信する際にユーザ端末によって使用されることができる。ハードウェアトークンは、秘密の表現を提供する秘密提供手段を含むことができ、秘密の表現は、秘密の暗号化を含み、暗号化はキーに基づき、キーは、ハッシュシーケンスの一部であり、秘密のシーケンス内の秘密の位置は、ハッシュシーケンス内のキーの位置に対応し、秘密提供手段は、逆順のシーケンスで表現を提供するように構成される。表現のシーケンスは、ハードウェアトークンの記憶手段に記憶されることができる。
【００１７】
別の見地において、本発明は、サーバシステムと共に使用されるユーザ端末を提供する。ユーザ端末は、ハードウェアトークンによって示される秘密の表現及びハードウェアトークンに対応するデータレコードを識別する情報を受信する秘密受信器と、ユーザの認証証明書を受信する証明書受信器と、値を生成する値生成器と、ユーザの認証証明書、ハードウェアトークンによって示される秘密の表現、ハードウェアトークンに対応するデータレコードを識別する情報、及び生成された値を、サーバシステムに送信する送信器と、サーバシステムから、暗号化された形のデータレコードの内容の少なくとも一部及びキーデータを受信するデータ受信器と、値及びキーデータに基づいてキーを計算するキー計算手段と、キーに基づいて、データレコードの内容の少なくとも一部を解読するデータ解読器と、を有する。
【００１８】
ユーザ端末は、ユーザ証明書及びハードウェアトークンからの秘密によって、改善されたセキュリティを提供する。更に、データレコードは、暗号化によって保護され、キーは、ネットワークを通じて送信される必要がない。
【００１９】
秘密受信器は、ハードウェアトークンからの表現又は情報を電子的に取得するトークンリーダを有することができる。
【００２０】
データレコードに対するセキュアなアクセスを提供するシステムは、サーバシステム、複数のハードウェアトークン、及び複数のユーザ端末を有することができる。ハードウェアトークンは、例えば潜在的な患者のような人によって保持されることができ、ユーザ端末は、例えば救急従事者のようなユーザによって保持されることができ又は使用されることができる。人が助けを必要としていて、その人の個人健康記録の詳細へのアクセスを提供することができない場合、救急従事者は、ハードウェアトークンを端末と接続することができ、端末は、サーバシステムに、秘密の表現を送信することができる；救急従事者は、サーバシステムに自分自身を証明し、その人の個人健康記録の緊急事態部分に対するアクセスを得る。人が救急支援を必要とする次のとき、ハードウェアトークンは、秘密の次の表現を生成することができる。
【００２１】
別の見地において、本発明は、データレコードに対するセキュアなアクセスを提供する方法を提供する。方法は、複数のデータレコード及び複数ユーザに関する複数の認証証明書をサーバシステムに記憶するステップであって、１のデータレコードには、該データレコードに対応するハードウェアトークンと共有される秘密のシーケンスが関連付けられている、ステップと、ユーザ端末からユーザの認証証明書を受け取り、ユーザの認証証明書に基づいて、ユーザをサーバシステムのユーザとして認証するステップと、端末から、ハードウェアトークンによって示される秘密の表現及びハードウェアトークンに対応するデータレコードを識別する情報を受信するステップと、秘密の表現を、ハードウェアトークンに対応するデータレコードに関連付けられた秘密のシーケンス内の未使用の秘密とマッチングするステップと、秘密の表現が未使用の秘密と合致し、ユーザがサーバシステムのユーザとして認証された場合、ハードウェアトークンに対応するデータレコードの少なくとも一部に対するユーザアクセスを許諾するステップと、未使用の秘密を使用済みとマークするステップと、を含む。
【００２２】
別の見地において、本発明は、上述の方法をプロセッサシステムに実施させるための命令を含むコンピュータプログラム製品を提供する。
【００２３】
当業者であれば、本発明の上述の実施形態、実現例及び／又は見地のうち２又はそれ以上が、有用であると考えられる任意のやり方で組み合わせられることができることが分かるであろう。
【００２４】
本発明の他の見地の記述される変形及び変更に対応する、サーバシステム、ユーザ端末、ハードウェアトークン、方法及び／又はコンピュータプログラム製品の変形及び変更は、本明細書の記述に基づいて当業者によって実施されることができる。
【図面の簡単な説明】
【００２５】
【図１】データレコードに対するセキュアなアクセスを提供するシステムのブロック図。
【図２】システムにおいて用いられるユーザ端末のブロック図。
【図３】データレコードに対するセキュアなアクセスを提供する方法のフローチャート。
【図４】データレコードに対するセキュアなアクセスを提供するシステムの別のビューを提供する図。
【発明を実施するための形態】
【００２６】
本発明のこれら及び他の見地は、以下に記述される実施形態から明らかになり、それらを参照して説明される。
【００２７】
本記述は、例えば人が事故又は心停止の理由で意識不明になるときのような、緊急事態において、人の医療記録へのアクセスを提供するために使用可能なシステムの実施形態を記述する。人は、クレジットカードと同様のやり方で人によって取り扱われるハードウェアタグを携帯することができる。ハードウェアタグに記憶された情報は、秘密に保持される。ハードウェアタグは、電子形式でそれに記憶される秘密情報を有することができ、情報は、ハードウェアタグがタグリーダに接続されるときのみ、示される。代替として、情報は、目に見えるようにされてもよく、従って、データレコードにアクセスする必要がある人は、端末に情報をコピーすることができる。ユーザが意識不明であるとき、医師は、ハードウェアタグを手に入れ、タグ上の情報を使用して、個人健康記録（ＰＨＲ）サーバに記憶されたその人の個人健康記録に対するワンタイム緊急時アクセスを要求することができる。データタグが盗まれた又はなくなった場合、ユーザは、サーバ上でハードウェアタグをブロックすることによってＰＨＲに対するいかなる緊急時アクセスも禁止するために、紛失を報告することができる。
【００２８】
窃盗に対する対抗手段として、データタグの所有が、必ずしも、要求しているエンティティが、ユーザのＰＨＲに対する緊急時アクセスを行えることを意味するわけではない。ポリシは、データタグからの情報を提供することができる資格のある医師又は医療関係者のみが緊急時アクセスをトリガすることができるように、ＰＨＲサーバにおいて規定されることができる。同様に、データタグからの情報をもたない医師は、緊急時アクセスを開始することを認可されない。
【００２９】
更に、ワンタイムセッションキーは、ＰＨＲサーバにのみ知られているユーザのハッシュチェーンからのキー及び医師からの秘密に基づいて、ユーザのＰＨＲにアクセスするために救急医師による使用に供されるハードウェアタグによって提供されることができる。医師は更に、ＰＨＲサーバから受信されたＰＨＲが信頼できるものかどうか、及びそれがユーザのアイデンティティに対応することを確かめることが可能である。
【００３０】
図１は、サーバシステム１００、ユーザ端末２００及びハードウェアトークン６０を有するシステムを示す。システムは、データレコード２に対するセキュアなアクセスを提供するために使用されることができる。サーバシステム１００は、複数のコンピュータ及び記憶媒体を使用して実現されることができる。システムは、単一のコンピュータを使用して、より小さい規模で実現されることもできる。他の実現可能性は、当業者には本記述から明らかであろう。
【００３１】
サーバシステムの記憶手段１は、例えば個人健康記録のような複数のデータレコードを記憶するように構成されることができる。図は、１つのデータレコード２を説明的に示している。緊急時アクセスの可能性が許可される各データレコード２は、データレコード２が関係する人によって携帯されるべき対応するハードウェアトークン６０を有することができる。このようなデータレコード２には、該データレコード２に対応するハードウェアトークン６０と共有される秘密１４のシーケンスが関連付けられている。図において、秘密１４のシーケンスの４つの秘密ｓ１、ｓ２、ｓ３、ｓ４が、例示として示されている。
【００３２】
更に、サーバシステム１００は、ユーザ認証情報３を記憶するように構成されることができる。このようなユーザ認証情報は、アクセス制御ポリシを含むことができる。当該ユーザは、医師又は救急従事者、又はデータレコードにアクセスする正当な理由を有する又は認可されている別の人でありうる。
【００３３】
サーバシステム１００は、ユーザ端末２００からのユーザの認証証明書１１を受け取るユーザ認証手段１０を更に有することができる。受け取った認証証明書１１及び記憶された認証情報３に基づいて、ユーザ認証手段１０は、端末２００のユーザが、サーバシステム１００によって記憶されているデータレコードの緊急時データに概してアクセスすることができるかどうかを判定する。言い換えると、ユーザ認証手段は、ユーザを、認可されたユーザとして認証するように構成される。認証手段１０は、例えば記憶されたアクセス制御ポリシに基づいて、役割ベースのアクセス制御又は属性ベースのアクセス制御を実施するように構成されることができる。役割ベースの又は属性ベースのアクセス制御は、それ自体当技術分野において知られている。サーバシステム１００において、このようなポリシは、後述するように、ユーザが、ハードウェアトークン６０から取得される適当な秘密情報１３をも提供する場合のみ、関連する特定の属性の組を有するユーザが、データレコードにアクセスすることを可能にすることができる。秘密情報１３は、ハードウェアトークン６０から読み出されることができ、ユーザの制御下、端末２００によってサーバ１００に送られることができる。
【００３４】
サーバシステム１００は更に、端末２００から秘密１３の表現を受け取る秘密受信手段９を有することができる。端末２００は、データレコード２が関係する人のハードウェアトークン６０から、秘密１３を読み出すように構成されることができる。更に、ハードウェアトークンに対応するデータレコードを識別する情報が、受け取られることができる。この情報は、秘密に含められることができ、又はそれは、トークンから又は他のやり方で取得されるデータの別個の一部でありうる。
【００３５】
サーバシステム１００は、秘密１３の表現を、ハードウェアトークン６０に対応するデータレコード２に関連付けられた秘密のシーケンス内の未使用の秘密とマッチングするマッチング手段７を更に有することができる。図において、ｓ１、ｓ２及びｓ３は未使用の秘密であり、ｓ４は使用済みの秘密である。例えば、マッチング手段７は、受け取られた秘密１３の表現を、秘密１４のシーケンス内の最後の未使用の秘密のｓ３とマッチングすることができる。
【００３６】
サーバシステム１００は、秘密１３の表現が未使用の秘密のｓ３と合致し、ユーザが認可されたユーザとして認証された場合、ハードウェアトークン６０に対応するデータレコード２の少なくとも一部に対するユーザアクセスを許諾するアクセス許諾手段６を更に有することができる。これらの２つの条件が両方満たされない場合、アクセス許諾手段６は、データレコード２に対するアクセスを拒否することができる。
【００３７】
サーバシステム１００は、未使用の秘密ｓ３を使用済みとマークするマーキング手段１２を更に有することができる。このように、システムは、どの秘密がなお未使用であるか（例えば、ｓ１及びｓ２）を常に把握している。未使用の秘密の表現１３のみが、データレコード２にアクセスするために使用されることができる。
【００３８】
サーバシステムは、ハードウェアトークン６０に関連付けられた人の移動端末５０（例えば移動電話）に自動化された電話発呼を行う又はメッセージを送信する通信手段８を有することができる。例えば、通信手段８は、移動電話に見られる通信ハードウェア又はこのような通信ハードウェアとのネットワーク接続手段を含むことができる。アクセス許諾手段６が、ユーザアクセスを許諾する前に、通信手段８はそのタスクを実施する。通信手段８は、双方向通信を可能にする。通信手段８が、移動端末５０から戻ってくる適当な信号を受け取る場合、通信手段８は、データレコード２に対するアクセスを拒否するようにアクセス許諾手段６に命じるための信号を、アクセス許諾手段６に送信することができる。移動端末５０は、ユーザが、例えばＤＴＭＦトーン又はｓｍｓメッセージのような適当な信号を送信することを可能にするユーザインタフェースを有する。
【００３９】
サーバシステム１００は、ユーザ端末から受信された値に基づくキーを使用して、データレコード２の少なくとも一部を暗号化する暗号化器５を有することができる。この値は、秘密１３の表現と共に、ユーザ端末から送信されることができる。サーバシステム１００は、暗号化されたデータ及び値からキーを計算するための情報を、ユーザ端末に送信するデータ送信手段４を更に有することができる。データ送信手段４は、データレコードのアクセス可能な完全な一部を端末２００に送信することができ、端末２００は、ユーザがデータを閲覧することを可能にするソフトウェアを有することができる。代替として、データ送信手段４は、端末２００及びウェブインタフェースを通じてユーザによって要求されるデータレコード２のエレメントを送るウェブサーバを有することができる。送信手段４は、上述のキー計算に基づくものである必要はない。それに代わって又は付加的に、例えば、ＳＳＬ及び／又はＨＴＴＰＳ暗号化技術又は他のデータ保護プロトコルが用いられることができる。
【００４０】
サーバシステム１００は、秘密１３の表現を受信したのち制限された時間の間のみ、データレコード２に対するアクセスを許諾するように構成されることができる。例えば、アクセスは、ただ１回のセッションの間及び／又は予め決められた時間期間の間のみ、許される。例えば、１時間の間のみアクセスが許される。代替として又は付加的に、データレコード２は、ただ一度だけ又は予め決められた回数だけ、ユーザ端末２００に送信されることができる。
【００４１】
秘密１３の表現は、秘密の暗号化（例えばｓ３の暗号化）を含むことができる。暗号化はキーに基づき、キーはハッシュシーケンスの一部でありうる。ハッシュシーケンスは、各々の連続するエレメントが、直前のエレメントにハッシュ関数を適用することによって取得されるシーケンスである。秘密のシーケンス内の秘密の位置は、ハッシュシーケンスのキーの位置に対応する。言い換えると、各々の連続する秘密は、ハッシュシーケンスの次のキーによって暗号化される。このように、ハッシュシーケンスの最後のキーから始まって逆方向に１つずつキーを示す場合、攻撃者にとって、示されていないキーを破壊することは困難である。なぜなら、ハッシュ関数は一方向関数だからである。
【００４２】
図１は、サーバシステム１００と通信するユーザ端末２００と共に使用されるハードウェアトークン６０を示す。ハードウェアトークン６０は、端末２００に秘密１３の表現を提供する秘密提供手段６１を有する。秘密１３の表現は、秘密の暗号化を含むことができる。暗号化は、キーに基づくことができ、キーは、ハッシュシーケンスの一部でありえ、秘密のシーケンス内の秘密の位置は、ハッシュシーケンスのキーの位置に対応することができ、秘密提供手段は、逆順のシーケンスで表現を提供するように構成されることができる。
【００４３】
ハードウェアトークンは、秘密の暗号化が生成されるのに用いられたキーを受信するように構成される検証器６２を有することができる。このキーは、「受信キー」と呼ばれる。受信キーは、サーバシステム１００から端末２００に送信されることができ、端末によってハードウェアトークン６０に送られることができる。検証器６２は、受信キーにハッシュ関数を適用することができる。このようにして、処理されたキーが生成される。この処理されたキーは、他の処理ステップを受けてもよいが、記憶された値と比較されることができる。記憶された値は、ハッシュシーケンス内の他のキーに基づく。比較の後、比較の結果が、端末に送信されることができる。比較が合致の結果をもたらさない場合、サーバシステム上のデータレコードとハードウェアトークンに関する情報との間に不一致があるので、端末は、エラーを生成することができる。
【００４４】
図２は、サーバシステム１００と共に使用される、可能性のあるユーザ端末２００を示す。図２の端末は、ハードウェアトークンの検証器のタスクを実施するように構成されることができる。この場合、ハードウェアトークンは、検証を実施する必要がない。同様に、ハードウェアトークンが検証器６２を有する場合、検証器２０４を有さないよりシンプルな端末が、使用されることができる。端末２００は、ＰＣハードウェアを使用して実現されることができ、又は異なるハードウェア及び適切なソフトウェアを使用して実現されることができる。同様のものは、すべての図面にわたって同様の参照数字によって示されている。ユーザ端末２００は、ハードウェアトークン６０によって示される秘密の表現及びハードウェアトークン６０に対応するデータレコードを識別する情報を受信する秘密受信器２０５を有することができる。ユーザ端末２００は、ユーザの認証証明書を受信する証明書受信器２０６を更に有することができる。証明書受信器２０６は、例えばユーザがユーザ名及びパスワードを入力することを可能にするユーザインタフェース素子に基づくことができる。更に、ユーザの強力な認証が、（患者のデータレコードに対応するハードウェアトークン６０と対照的に）ユーザと関連付けられたユーザ名、パスワード及びハードウェアトークンの組み合わせを使用して可能である。
【００４５】
ユーザ端末２００は更に、ユーザの認証証明書、ハードウェアトークン６０によって示される秘密の表現、及びハードウェアトークン６０に対応するデータレコードを識別する情報を、サーバシステム１００に送信する送信器２０１を有する。サーバシステム１００が、供給された情報に基づいて、データレコード２に対するアクセスを許諾する場合、データレコード２の内容が、暗号化された形でユーザ端末２００に送信されることができる。しかしながら、サーバの認証、及び／又は正しいデータレコード２がサーバシステム１００によって見つけられたかどうかのチェックが、以下のように実施されることができる。
【００４６】
ユーザ端末２００は、サーバシステム１００から、暗号化された形のデータレコードの内容の少なくとも一部及びキーデータを受信するデータ受信器２０２を有することができる。キーデータは、処理されたキーを取得するために、受信されたキーデータにハッシュ関数を（１又は複数回）適用し、及び任意の他の処理ステップを適用し、処理されたキーを、ハードウェアトークン６０からこの目的のために受け取られた値と比較するように構成される検証器２０４に送られることができる。値は、ハッシュシーケンス内のキーに基づくことができる。この比較に基づいて、検証器２０４は、サーバシステム１００及び／又はデータレコード２が信頼できるか判定する。
【００４７】
ユーザ端末２００は、キーデータに基づいてデータレコードの内容の少なくとも一部を解読するデータ解読器２０３を有することができる。データ解読器２０３は、検証器２０４による認証が成功する場合のみ、データレコードの内容を解読するように構成されることができる。
【００４８】
秘密受信手段２０５は、ハードウェアトークン６０から表現又は情報を電子的に取得するトークンリーダ２０７を有することができる。例えば、トークンリーダ２０７はスマートカードリーダを有し、ハードウェアトークン６０はスマートカードを有する。
【００４９】
完全な保護されたアクセスシステムは、上述のサーバシステム、ハードウェアトークン及びユーザ端末を使用して構築されることができ、検証器の実現は、ユーザ端末において又はハードウェアトークンにおいて行わることができる。
【００５０】
図３は、データレコードに対するセキュアなアクセスを提供する方法を示す。方法は、サーバシステム、１又は複数のユーザ端末、及び１又は複数のハードウェアトークン上に配布するために１又は複数の記憶媒体に記憶されることができるソフトウェアの形で実現されることができる。
【００５１】
方法は、複数のデータレコードを記憶するステップ３０１であって、１のデータレコードには、該データレコードに対応するハードウェアトークンと共有される秘密のシーケンスが関連付けられている、ステップと、ユーザ認証情報を記憶するステップと、を含む。
【００５２】
方法は、ユーザ端末からユーザの認証証明書を受け取り、ユーザの認証証明書及び記憶された認証情報に基づいて、当該ユーザを認可されたユーザとして認証するステップ３０２を含むことができる。
【００５３】
方法は、端末から、ハードウェアトークンによって示される秘密の表現及びハードウェアトークンに対応するデータレコードを識別する情報の表現を受け取るステップ３０３を含むことができる。
【００５４】
方法は、秘密の表現を、ハードウェアトークンに対応するデータレコードに関連付けられた秘密のシーケンス内の未使用の秘密とマッチングするステップ３０４を含むことができる。
【００５５】
方法は、秘密の表現が未使用の秘密と合致し、ユーザが認可されたユーザとして認証された場合、ハードウェアトークンに対応するデータレコードの少なくとも一部に対するユーザアクセスを許諾するステップ３０５を含むことができる。
【００５６】
方法は更に、未使用の秘密を使用済みとマークするステップ３０６を含むことができる。
【００５７】
データタグスマートカード（緊急時救助トークンを含む）のようなハードウェアトークンの使用は、ヘルスケア従事者が、緊急時にユーザのＰＨＲへのアクセスを得ることを可能にすることができる。一例として、以下の特徴が実現されることができる。
−データタグは、健康レコードにアクセスするのに必要なアクセス情報を含む。
−カード上の情報は、健康レコードを破壊する又は無効にする必要なく、更新されることができる。
−プロトコルは、情報要求者の医療従事者証明書のチェックを含む。
−プロトコルは、レコードに対するアクセスが１回の単一セッションの間のみ有効であることを保証する。
【００５８】
例示的な実施形態は、以下のエレメントのうち１又は複数又は全てを含むことができる：
【００５９】
−ＰＨＲサーバは、ハッシュチェーン及び救助トークンを生成することによって、ユーザとの関連をセットアップする。救助トークンは、疑似秘密とともに、暗号化され、スマートカードに記憶される。
【００６０】
−医師は、ＰＨＲサーバに対し自身を証明することができ、医師の証明書は、緊急時アクセスを可能にするために、ＰＨＲサーバによって規定されるポリシを満たすべきである。
【００６１】
−医師又は医師によって使用されるユーザ端末は、局所的に秘密ｘを生成し、疑似秘密（ｐｓ）及びｉ番目の救助トークン（ｒｋｉ）とともにそれをＰＨＲサーバに提供する。
【００６２】
−緊急時アクセスは、医師がユーザのスマートカードを所有する場合のみ許される。その証明は、疑似秘密及び救助トークンを提供することによって行われる。
【００６３】
−特定の救助トークンの範囲は、特定の緊急時セッションに限定される。緊急時セッションごとに、異なる救助トークン（ｒｋｉ）が使用される。ｉ番目の救助トークンの使用は、ｉ番目の緊急時セッションのアクセスのみを可能にし、医師がのちにそれを使用しようと試みる場合であっても、その後のアクセスは有効でない。それゆえ、これは、医師が、将来ユーザのＰＨＲに対する緊急時アクセスを利用することを防ぎ、効率的なやり方でユーザのプライバシーを保護する。
【００６４】
−同時に、ＰＨＲサーバは、ユーザが現在緊急事態の状況にあるかどうか判定するために、ユーザに対し自動化された電話発呼を起動することができる。ユーザが応答しない場合、ユーザは実際に緊急事態の状況にあるとみなされることができる。
【００６５】
−救助トークン及びユーザ（ここで、困っている人）の疑似秘密の評価後、ＰＨＲサーバは、セキュアな認証されたチャネルにおいて、ハッシュチェーンＫ１，Ｋ２，...，ＫＮからの（ｉ−１）番目のＫｉ−１を返す。秘密は、ユーザのＰＨＲ又はＰＨＲのサブセットを解読するために使用されるワンタイム秘密ｚを生成するために、医師自身の秘密ｘと組み合わされて使用される。
【００６６】
−ＰＨＲサーバは、キーｚによって暗号化された暗号化ＰＨＲを返し、ＰＨＲに対するアクセスは、時間を制限されることができる。この場合、ＰＨＲにアクセスするためのユーザの元のパスワード又は秘密は、何人にも示されない。
【００６７】
図４は、本発明の実施形態のより詳細な例を示す。これらの詳細は、単なる例としてここに記述されており、別個に又は組み合わされて、図１及び図２のシステム及び図３の方法に適用されることができる。システムは、潜在的な患者４５１を説明的に示す。図は更に、スマートカード４５２を示し、これは、まさにハードウェアトークンの例である。図は更に、ＰＨＲサーバ４５３及びユーザ端末４５４（一般に、医師によって操作される）を示す。数字４０１−４１４は、いくつかの処理ステップに関連するデータフローを示す。
【００６８】
Ａ．秘密の初期化（ステップ４０１）
ユーザがＰＨＲアカウントの契約をすると、ユーザは、ＰＨＲサーバから疑似秘密を取得する。ＰＨＲサーバは、最初に、ハッシュチェーン［５］の第１のキーとして乱数Ｋ１を選ぶ。ハッシュ関数がそのキーに適用されて、チェーン上の次のキーが計算される。このプロセスは、以下のようにハッシュチェーンを生成するために、ｎ−１回繰り返される：
K1 → K2 = H[K1] → K3 = H[K2] → ... → Kn = H[Kn-1]
【００６９】
Ｋｎが与えられる場合、攻撃者がＫｎ−１を導き出すことは計算上実行不可能であるという点で、ハッシュチェーンは一方向の特性を有する。ハッシュチェーンは、各個人にユニークであり、ユーザのＰＨＲの識別子として機能する。ハッシュチェーン内のキーは、ユーザのＰＨＲの確実性を決定するために使用されることができる。ハッシュチェーンは逆順で使用され、Ｋｎは、ユーザの疑似秘密として示される。
【００７０】
ハッシュチェーンに加えて、ＰＨＲサーバは、ｎ個の救助トークンＸ１，...，Ｘｎ（例えば乱数）を生成し、それらの救助トークンは、以下のように、ハッシュチェーンのキーによって暗号化される：
EKn-1(Xn), EKn-2(Xn-1), ... ,EK1(X2)
【００７１】
救助トークンは、ユーザのハードウェアトークンとＰＨＲサーバとの間で共有される秘密である。救助トークンを使用する医師は、暗号化の理由により、トークンを解読することが可能でなく、それゆえ、再生を防ぐ。各々のトークンは、キーチェーンからのキーによって暗号化され、キーは、ＰＨＲサーバにのみ知られており、攻撃者が、新しいトークンを生成し又はトークンを変更することは可能でない。
【００７２】
可能性として暗号化されていない疑似秘密キー、ＰＨＲサーバにアクセスするためのＵＲＬ、及び暗号化された救助トークンを含むデータタグ、すなわちハードウェアトークンは、付随するレターと共にユーザに送られ、レターの中で、ユーザは、常にユーザと共にデータタグを携帯するようにアドバイスされる。
【００７３】
Ｂ．緊急時アクセスのトリガ
緊急時に、医師及びＰＨＲサーバは、医師にＰＨＲデータをリリースするために、以下のステップの一部又は全部を実施することができる：
【００７４】
−ステップ４０２：医師は、データタグスマートカード上のデータをクエリする。
−ステップ４０３：データタグスマートカードは、疑似秘密Ｋｎ及びｉ番目の救助トークンｒｋｉ＝ＥＫｉ−１（Ｘｉ）を返す。疑似秘密は、ユーザのＰＨＲの識別子として機能し、他方、救助トークンは、緊急時アクセスを医師に許諾する。医師がスマートカードをクエリする次のとき、新しい救助トークン、すなわちＥｋｉ−２（Ｘｉ−１）が、疑似秘密Ｋｎとともに発行される。
【００７５】
−ステップ４０４：医師は、例えば自分のユーザ名及びパスワード、ＳＡＭＬトークン、ＰＫＩ証明書、その他を用いて、ＰＨＲサーバに対し自身を証明する。
−ステップ４０５：ＰＨＲサーバは、医師を認証し、認証失敗又は成功メッセージを返す。
−ステップ４０６：成功した認証に応じて、医師は、ランダムな秘密ｘを局所的に生成する。
−ステップ４０７：秘密を生成した後に、医師は、ＰＨＲサーバに、疑似秘密（ｐｓ＝Ｋｎ）、救助トークン（ｒｋｉ＝ＥＫｉ−１（Ｘｉ））及びランダムな秘密ｘを送る。
【００７６】
−ステップ４０８：受け取られた疑似秘密に基づいて、ＰＨＲサーバは、ユーザの対応するハッシュチェーンを位置特定し、Ｋｉ−１を取得するためにハッシュチェーンを逆方向に進む。救助トークンは、Ｋｉ−１を使用して解読され、ＰＨＲサーバは、トークンが以前に使用されていないことを確認する。以前に使用されていた場合、ＰＨＲサーバは、セッションを中止し、患者のＰＨＲデータをリリースしない。
−ステップ４０９：ＰＨＲサーバは更に、ユーザが緊急事態の状況にあるかどうか判定するために、ユーザに対し自動化された電話発呼を行うことができる。ユーザが他の状況を示す場合、緊急時アクセス要求は直ちに中止される。
【００７７】
−ステップ４１０：緊急事態の状況が確かめられた場合、ＰＨＲサーバは、ワンタイム秘密キーｚ＝ｘ＋Ｋｉ−１を生成する。
−ステップ４１１：ＰＨＲサーバは、ユーザのＰＨＲを暗号化するために、秘密キーｚを使用する。
−ステップ４１２：ＰＨＲサーバは、キーＫｉ−１とともに、暗号化されたＰＨＲを医師に送る（例えば、キーは、キー交換プロトコルの一部として送信されることができる）。
【００７８】
−ステップ４１３：ｘ及びＫｉ−１を知っている医師の端末は、同様にワンタイム秘密ｚを計算することができる。しかしながら、その前に、医師は、正しいＰＨＲが取り出されることを確実にするために、ＰＨＲサーバから受け取ったＫｉ−１が信頼でき、ユーザのアイデンティティに対応するものであることを確認することができる。医師の端末は、ハッシュ関数を、Ｋｉ−１及び結果的に得られるハッシュ値に繰り返し適用することができ、それが、ユーザの疑似秘密と考えられることができるＫｎに到達するまで行われる。ＰＨＲサーバのみが全体のハッシュチェーンH[Ki-1] → ... → H[Kn-1] = Knを知っているので、これは、ＰＨＲサーバを認証する方法として役立つ。
−ステップ４１４：医師は、ステップ４１３の出力を使用して、ＰＨＲデータを解読する。
【００７９】
本発明は、本発明を実行するために適応されるコンピュータプログラム、特に担体上又は担体内のコンピュータプログラムにも適用されることが分かるであろう。プログラムは、ソースコード、オブジェクトコード、コード中間ソース及び例えば部分的にコンパイルされた形のオブジェクトコードの形でありえ、又は、本発明による方法の実現において使用するのに適した任意の他の形でありうる。更に、このようなプログラムは、多くの異なる構造設計を有することができる。例えば、本発明による方法又はシステムの機能を実現するプログラムコードは、１又は複数のサブルーチンに再分割されることができる。これらのサブルーチンの間で機能を分散する多くの異なるやり方は、当業者には明らかである。サブルーチンは、自己内蔵型プログラムを形成するために、１つの実行可能ファイルに一緒に記憶されることができる。このような実行可能ファイルは、例えばプロセッサ命令及び／又はインタプリタ命令（例えばＪａｖａインタプリタ命令）のようなコンピュータ実行可能命令を含むことができる。代替として、サブルーチンの１又は複数又は全ては、少なくとも１つの外部ライブラリファイルに記憶されることができ、例えば実行時に、静的に又は動的にメインプログラムとリンクされる。メインプログラムは、サブルーチンの少なくとも１つに対し少なくとも１つの呼び出しを含む。サブルーチンは、互いの呼び出しを含むことができる。コンピュータプログラム製品に関する実施形態は、ここに示される方法の少なくとも１つにおける各々の処理ステップに対応するコンピュータ実行可能命令を含む。これらの命令は、サブルーチンに再分割されることができ、及び／又は静的に又は動的にリンクされることができる１又は複数のファイルに記憶されることができる。コンピュータプログラム製品に関する別の実施形態は、ここに示されるシステム及び／又は製品の少なくとも１つにおける各手段に対応するコンピュータ実行可能命令を含む。これらの命令は、サブルーチンに再分割されることができ、及び／又は静的に又は動的にリンクされることができる１又は複数のファイルで記憶されることができる。
【００８０】
コンピュータプログラムの担体は、プログラムを担持することができる任意のエンティティ又は装置でありうる。例えば、担体は、ＣＤ−ＲＯＭ又は半導体ＲＯＭのようなＲＯＭ、又はフラッシュドライブ又はハードディスクのような磁気記録媒体を含む記憶媒体を含むことができる。更に、担体は、電気的又は光学的ケーブルを通じて又は無線若しくは他の手段によって伝達されうる電気的又は光学的信号のような送信可能な担体でありうる。プログラムが、このような信号において具体化される場合、担体は、このようなケーブル又は他の装置若しくは手段によって構成されることができる。代替として、担体は、プログラムが埋め込まれる集積回路でありえ、集積回路は、関連の方法を実施するように構成され、又は方法の実施において使用されるように構成されることができる。
【００８１】
上述の実施形態は、本発明を説明するものであって、制限するものではなく、当業者であれば、添付の請求項の範囲を逸脱することなく、多くの代替の実施形態を設計することが可能であることが留意されるべきである。請求項において、括弧内に示される参照符号は、請求項を制限するものとして解釈されるべきでない。動詞「有する、含む（comprising）」及びその活用形の使用は、請求項に記載された構成要素又はステップの存在を排除しない。構成要素の前の冠詞「a」又は「an」は、このような構成要素の複数の存在を除外しない。本発明は、幾つかの別個の構成要素を有するハードウェアによって及び適切にプログラムされたコンピュータによって、実現されることが可能である。幾つかの手段を列挙する装置の請求項において、これらの手段の幾つかは、１つの同じハードウェアアイテムによって具体化されることができる。特定の手段が相互に異なる従属請求項に列挙されているという単なる事実は、これらの手段の組み合わせが有利に使用されることができないことを示さない。
【図１】
0005897040.tif 000002
【図２】
0005897040.tif 000003
【図３】
0005897040.tif 000004
【図４】
0005897040.tif 000005