(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6351607
(24)【登録日】2018年6月15日
(45)【発行日】2018年7月4日
(54)【発明の名称】安全装置と安全なデータ送信方法
(51)【国際特許分類】
H04L 9/32 20060101AFI20180625BHJP
G06F 21/31 20130101ALI20180625BHJP
G06F 21/32 20130101ALI20180625BHJP
【FI】
H04L9/00 673A
H04L9/00 673D
G06F21/31
G06F21/32
【請求項の数】12
【全頁数】12
(21)【出願番号】特願2015-538443(P2015-538443)
(86)(22)【出願日】2013年10月24日
(65)【公表番号】特表2015-534406(P2015-534406A)
(43)【公表日】2015年11月26日
(86)【国際出願番号】EP2013072276
(87)【国際公開番号】WO2014064197
(87)【国際公開日】20140501
【審査請求日】2016年10月24日
(31)【優先権主張番号】12189839.9
(32)【優先日】2012年10月24日
(33)【優先権主張国】EP
(73)【特許権者】
【識別番号】514272955
【氏名又は名称】オープンリミット・サインキューブズ・アーゲー
【氏名又は名称原語表記】OPENLIMIT SIGNCUBES AG
(74)【代理人】
【識別番号】110000394
【氏名又は名称】特許業務法人岡田国際特許事務所
(72)【発明者】
【氏名】ルンカイト,アルミン
【審査官】
青木 重徳
(56)【参考文献】
【文献】
特開2009−176233(JP,A)
【文献】
特開2002−328862(JP,A)
【文献】
特開平03−026126(JP,A)
【文献】
米国特許出願公開第2006/0185021(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
H04L 9/32
G06F 21/31
G06F 21/32
(57)【特許請求の範囲】
【請求項1】
本質的に安全でない接続を用いたり本質的に安全でない第一の通信装置(20)を用いたりして第一の通信装置(20)と少なくとも一つの第二の通信装置(30)との間での安全なデータ送信を可能にするための安全装置(10)であって、
第一の通信装置(20)から少なくとも一つの第二の通信装置(30)へのデータ送信要求(101)に関して、少なくとも一つの第二の通信装置(30)から第二の認証要求(105)を受信するための受信手段(2)と、
データ送信要求(101)について使用者へ情報を提供するための出力手段(3)とを備え、受信手段(2)がこの出力手段(3)と接続されており、
使用者による認証データ(110)を入力するための入力手段(4)と、
安全装置(10)での使用者によって、少なくとも一つの第二の通信装置(30)のために認証データ(110)に基づいて第三の認証要求(106)を作成する手段と、
あらかじめ定義された有効化信号(103)のみを安全装置(10)を用いて受信することと処理することのいずれか又は両方を可能とするよう構成されており、また、有効化信号(103)を正しく受信した後でのみ、第三の認証要求(106)を少なくとも一つの第二の通信装置(30)への送信可能とするよう構成されている第一の接続手段(1)とを備えており、
安全装置での認証データ(110)が、特にPINコード、使用者だけが知っている秘密のパスワードやパスフレーズなどの英数字のデータと、特に指紋スキャン、虹彩スキャンなどの生体認証データとのいずれか又は両方を含むもの。
【請求項2】
請求項1の安全装置であって、第一の通信装置(20)がクライアント装置を含むもの。
【請求項3】
請求項1又は2の安全装置であって、少なくとも一つの第二の通信装置(30)がサーバーシステム(30)を含むもの。
【請求項4】
以上の請求項のうち少なくとも一つの安全装置であって、英数字表示装置と点字表示装置のいずれか又は両方を含むもの。
【請求項5】
以上の請求項のうち少なくとも一つの安全装置であって、入力手段(4)が、英数字キーボード、静脈スキャナー、指紋スキャナー、虹彩スキャナーのいずれか又は複数を含むもの。
【請求項6】
以上の請求項のうち少なくとも一つの安全装置であって、安全装置(10)の第一の接続手段(1)でのバッファ記憶装置の容量を2kB、特に1kBより小さいものに制限することと、第一の接続手段(1)への入力としてある一定のビットパターンのみを許可することのいずれか又は両方とするもの。
【請求項7】
以上の請求項のうち少なくとも一つの安全装置であって、第一のデータ送信要求(101)を、例えば送金かオンライン購入の要求とするもの。
【請求項8】
以上の請求項のうち少なくとも一つの安全装置であって、第一の接続手段(1)がパソコン、タブレット装置、車、携帯電話、スマートフォンのいずれか又は複数と接続可能とすることと、安全装置(10)を車などの物体に埋め込むことのいずれか又は両方であるもの。
【請求項9】
安全なデータ送信のための方法であって、
a)第一の通信装置(20)から少なくとも一つの第二の通信装置(30)へデータ送信の要求(101)を送信し、
b)少なくとも一つの第二の通信装置(30)が、データ送信の要求(101)を受信すると、第一の通信装置へのアクノリッジ要求を送信し、
c)第一の通信装置(20)が、安全装置(10)へのあらかじめ定義された有効化信号(103)のみを生成して安全装置(10)へ送信し、
d)安全装置(10)が、少なくとも一つの第二の通信装置(30)へ第一の認証要求(104)を送信し、
e)少なくとも一つの第二の通信装置(30)が、出力手段(3)によって表示するデータ送信要求(101)に関する情報を含む第二の認証要求(105)で返信し、
f)入力手段(4)が、使用者からの認証データ(110)を受信し、安全装置でのこの認証データ(110)が、特にPINコード、使用者だけが知っている秘密のパスワードやパスフレーズなどの英数字のデータと、特に指紋スキャン、虹彩スキャンなどの生体認証データとのいずれか又は両方を含み、
g)内容は認証データ(110)に応じて、第三の認証要求(106)を、安全装置(10)から第二の通信装置(30)へ送信するもの。
【請求項10】
請求項9の方法であって、第一の通信装置(20)がクライアント装置であるもの。
【請求項11】
請求項9又は10の方法であって、
少なくとも一つの第二の通信装置(30)がサーバーシステム(30)であるもの。
【請求項12】
請求項9から11のうち少なくとも一つの方法であって、請求項9のステップb)とステップc)との間に、
c01)クライアント装置(20)と第二の通信装置(30)との間に暗号化された安全な通信路を確立し
c02)その通信路で第二の暗号化された安全な通信路を、特に対象暗号化を用いて確立し、
c03)その通信路で電子IDをやり取りするステップを備えるもの。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、請求項1に従った安全装置と、請求項10に従った安全なデータ送信方法に関するものである。
【背景技術】
【0002】
通信装置同士でデータのやり取りが必要となるのは一般的なタスクである。クライアント装置の典型的な例として、インターネットブラウザを用いるパソコンやタブレットコンピューターなどは、サーバーシステムからのデータを必要とする。権限のない人がデータ送信を変更したりクライアント装置のセキュリティを改ざんしたりすることが可能なため、インターネットを介した通常の接続は本質的に不安定である。
【0003】
オンライン銀行サービスやオンラインショッピングは、クライアント装置の使用者による認証、或いはクライアント装置のところでの認証など、何らかの種類の認証を必要とする典型的なトランザクション(つまりデータ送信)の例である。第一の通信装置(例えばクライアント装置)の使用者や少なくとも一つの第二の通信装置(例えばサーバーシステム)の使用者は、クライアント装置の安全性がトロイの感染などによって侵されていないと確信することはできない。正しい認証の証明書をクライアント装置で得られる(例えば、パスワード、パスフレーズ、PIN、トランザクション認証番号)とはいえ、実際にサーバーシステムへ送信されたりサーバーシステムで受信されるデータは何らかの権限のない手段(例えばクライアント装置上にある何らかの権限のないソフトウェア)によって改ざんされる可能性がある。
【0004】
それゆえ、第一の通信装置(例えばクライアント装置)と通信路のいずれか又は両方が安全かどうか不確かな条件であっても安全にデータを送信できるようにするための装置と方法の開発は望ましいことである。
【発明の概要】
【0005】
本質的に安全でない接続を用いたり本質的に安全でない第一の通信装置(例えばクライアント装置)を用いたりして第一の通信装置(例えばクライアント装置)と少なくとも一つの第二の通信装置(例えばサーバーシステム)との間での安全なデータ送信を可能にするために、以下のものを備えた安全装置を構成する。
【0006】
第一の通信装置(例えばクライアント装置)から少なくとも一つの第二の通信装置(例えばサーバーシステム)へのデータ送信要求に関して、少なくとも一つの第二の通信装置(例えばサーバーシステム)から第二の認証要求を受信するための受信手段。この受信手段は、データ送信の要求について使用者へ情報を提供するための出力手段と接続する。
使用者による認証データの入力のための入力手段。
安全装置での使用者によって、少なくとも一つの第二の通信装置(例えばサーバーシステム)のために認証データに基づいて第三の認証要求を生成する手段。
あらかじめ定義された有効化信号のみを安全装置で受信と処理のいずれか又は両方を可能とするよう構成されており、また、有効化信号を正しく受信した後にのみ第三の認証要求は少なくとも一つの第二の通信装置(例えばサーバーシステム)への送信を可能とするよう構成されている第一の接続手段。あらかじめ定義された有効化信号は、一義的な信号と考えるものとする。
【0007】
したがって、第一の通信装置と少なくともひとつの第二の通信装置との間のデータ送信は、データ送信自体を行う前にいくつかの認証を行うことが必要となる。その認証とは次のようなものである。
a) 第一の通信装置(例えば安全装置を組み込んだもの)から少なくとも一つの第二の通信装置(例えばサーバーシステム)に対する認証。
b) 少なくとも一つの第二の通信装置(例えばサーバーシステム)から第一の通信装置(例えば安全装置を組み込んだもの)に対する認証。これは結果的に相互認証となる。
c) 使用者から安全装置に対する(例えば生体認証のインターフェースを用いた)認証。
d) 使用者から第二の通信サーバーシステムへの電子IDの送信を伴う認証。
【0008】
第一の通信装置の使用者は、少なくとも一つの第二の通信装置で確認することが可能な電子IDを用いることで認証される。これは結局認証とデータ送信とを合わせること、つまり認証とデータ送信に同じ通信路(例えば暗号化された安全な通信路)を用いることになる。
【0009】
使用者の認証は安全装置に対して直接行われる。例えばマイクロチップ付きカードを照合する端末機のような外部装置の必要はない。
【0010】
先行技術との違いは、安全装置に備わっている固有の使用者認証である。したがって、この安全装置は、例えばPINパッドや生体認証インターフェースなどの外部の入力装置を「追加的に」用いることなく使用者と安全装置との間のやり取りを可能にする入力インターフェースをもつことが特徴となる。安全装置は使用者の電子IDを保護しており、この電子IDは相互認証の段階において相互に認証して受け入れた通信路どうしの接続を構成するのに用いられる。電子IDやその一部の発信は、安全装置における使用者の本人確認を経て許可する。安全装置における電子IDの保護は、使用者の認証がうまくいかない限りは電子IDへのいかなるアクセスもできないような安全な記憶装置によって実現できる。このように安全な記憶装置へのアクセスを保護するという方針は、安全装置の明確な特性となる。
【0011】
安全装置での使用者の認証のために、使用者が安全装置に対し認証データを提供することもできる。認証データには、特にPINコード、秘密のパスワードやパスフレーズのように使用者しか知らない英数字データや、特に指紋スキャンや虹彩スキャンのような生体認証のデータのいずれか又は複数を含んでいる。この情報を用いることで、サーバーシステムは送信要求のあったデータが正しいものであって使用者によって認証されたことを確かなものとすることができる。
【0012】
出力手段は英数字表示装置や点字表示装置を含むため、複雑な情報を使用者に提供することができる。
【0013】
通信の安全対策として、あらかじめ定められた有効化信号のみを処理することが可能である。したがって、安全装置の第一の接続手段でのバッファ保管の容量を2kB、さらには1kBより小さいものに制限したり、第一の接続手段向けの入力としてある一定のビットパターンしか許可しないようにしたりする。意図的にバッファ保管を最小化することにより、この場面における安全性を強化できる。通常であれば、安全装置10はトランザクションIDと認証されたサーバーのアドレスを受信することになる。それ以上のものは第二の安全な通信路でのセッションを続けるのに必要ない。
【0014】
安全な検証のための入力手段は、英数字キーボード、静脈スキャン、指紋スキャン、虹彩スキャンを含む。これらの手段を用いることで、使用者は安全装置に対して安全な入力を行うことができる。
【0015】
安全装置は、例えば送金やオンライン購入のための第一のデータ送信要求に用いることが可能である。
【0016】
安全装置は、パソコン、タブレット装置、車、携帯電話、スマートフォンのいずれか又は複数と接続可能な第一の接続手段としたり、安全装置を車などの物体に組み込んだりすることができる。
【0017】
さらに、次のような段階を含む方法によれば、安全なデータ送信を確保できる。
a)クライアント装置からサーバーシステムへデータ送信要求を送信し、
b)データ送信の要求を受信するとサーバーシステムがクライアント装置へアクノリッジ要求を送信し、
c)クライアント装置があらかじめ定められた有効化信号を生成して安全装置に送り、
d)安全装置が第一の認証要求をサーバーシステムに送信し、
e)そのときサーバーシステムが、出力手段で表示するデータ送信要求に関する情報を含む第二の認証要求で返信し、
f)入力手段で使用者から認証データを受信し、
g)認証データに応じた内容の第三の認証要求を、安全装置からサーバーシステムへ送信する。
【0018】
第一の通信装置はクライアント装置とすることができる。少なくとも一つの第二の通信装置はサーバーシステムとすることができる。
【0019】
具体的な実施例としては、
a)相互認証のため安全装置とサーバーシステムとの間に暗号化された安全な通信路を確立し、
b)その通信路で、特に対称暗号化を用いて暗号化された第二の安全な通信路を確立し、
c)その通信路で電子IDをやり取りする。
【図面の簡単な説明】
【0020】
代表的な実施例を以下の図と関連させて説明する。
【
図1】
図1は、安全なデータ送信を可能にする安全装置の実施例の概観を示す。
【
図2】
図2は、方法の実施例における通信のシークエンス図を示す。
【発明を実施するための形態】
【0021】
第二の通信装置としてのサーバーシステム30と安全装置10との間に安全な通信路を提供する安全装置10の実施例には、データ送信、つまり
図1で示すようなデータ送信(トランザクション)が関わる。これによって、以下で考察するように、例えばクライアント装置20のような第一の通信装置と、例えばサーバーシステム30のような第二の通信装置との間でのデータ送信の認証を可能にする。単純化する理由から、ここで示す実施例は、例えば一つのサーバーシステム30とするなど、第二の通信装置30が一つしかないことを前提とする。第二の通信装置30が二つ以上あるような状況でも、本発明の方法と安全装置10を用いることが可能である。さらに、サーバーシステム30という用語は、サーバーとなるコンピューター、特に大型のコンピューターに限定するものではない。サーバーシステム30は、クライアント装置にサービスを提供できる任意のシステムとすることができる。
【0022】
以下では、第一の通信装置20は、第二の通信装置30であるサーバーシステムへのクライアント装置とする。
【0023】
典型的な状況は、使用者が、自分のクライアント装置20からサーバーシステム30へのデータ送信の要求(トランザクション要求)を開始して完了したい場合である。
【0024】
クライアント装置20は、例えば、パソコン、タブレット装置、スマートフォンとすることができる。
【0025】
要求されたデータ送信は、例えばオンライン銀行サービスのセッションや、インターネット上の店舗での購入、何らかのサービス提供会社の個人登録とすることができる。他の実施例としては、エネルギーの消費者と供給者との間にあるスマートグリッドシステムの状況における処理とすることもできる。消費者は、例えばエネルギー供給者からの遠隔保守といったサービスを求めている。
【0026】
この実施例はデータ送信の要求で動作することが可能であり、これは、権限を持つ使用者が、正しい内容(例えば正しい金額や正しい口座情報)でデータ送信を開始したり許可をしたりするものである。このような場面でいう「正しい」という言葉は、その正しい内容が使用者の意図した内容と同じであるという意味である。
【0027】
これらの場合はいずれも、クライアント装置20とサーバーシステム30との間で機密情報を送る必要がある。クライアント装置20の安全性が侵されていないことを使用者は確信できないため、使用者はクライアント装置20が本質的に安全でないことを前提としなければならない。サーバーシステム30は、クライアント装置20からの要求が本物であるかを確かめることができない。
【0028】
クライアント装置20からサーバーシステム30へのデータ送信には、使用者が制御不可能な本質的な不安定性もある。それゆえ、このようなデータ送信もまた、本質的に安全でないとして考えなければならない。
【0029】
以下に示すように、安全装置10は、第二の独立して本質的に安全な通信路をサーバーシステム30に開くため、次にクライアント装置20とサーバーシステム30との間の通信を確認することができる。
【0030】
この文脈でいう本質的な安全性とは、通信路の安全性を使用者やサーバーシステム30が検証できるということを意味している。これは以下のものに基づいている(
図2も参照)。
・クライアント装置20とサーバーシステム30との間にある暗号化された安全な通信路を確立する(例えばTLS)。
・その通信路(例えばTLS)内で、特に対称暗号化を用いて、第二の暗号化された安全な通信路を確立する。
・その通信路で電子IDを交換する。
【0031】
二つの暗号化された通信路をつなぐことによって安全性が改善される。最初は、傍受に対する安全性を提供する認証された接続を確立するプロトコルを用いる。加えて、データ送信が行われる第二の通信路を確立する。この二段階の方法の実施例は、
図2に記載している。
【0032】
こうすることにより、クライアント装置20とサーバーシステム30との間での電子データ送信を合理的なものにできる。
【0033】
オンラインでの銀行サービスの例の場合、クライアント装置20の使用者はクライアント装置20で動作するブラウザでデータ送信、つまりトランザクションを開始する。他にも、異なるプログラム、例えば専門的な銀行サービスのプログラムを用いることも可能である。他の可能な用途には、例えば、会社のウェブサイトへのログイン、勤務する技術者など外部の作業者のためのサービスポータルへのログイン、コンピューターではなく物理的な場所に出入りできるようにする装置として利用することなどがある。ブラウザを用いても用いなくても、クライアントがインターネットと通信したり、サーバーシステム30からデータを受信したりできるようにすることは重要である。
【0034】
上で述べた実施例では、銀行サービスのプラットフォームを起動した後、例えば使用者の名前やパスワードを提示することで、使用者がログインする。ログインの手順では、様々な、あるいは追加的な入力データを用いることができる。
【0035】
使用者は次に、トランザクションの記入様式、つまり受取人、送金額、銀行サービスの細目などを指定するための記入様式を埋める。
【0036】
使用者は次に、データ送信形式要求101としてサーバーシステム30へ、トランザクション記入様式のためのポータルを起動した状態でこのデータを送信する。サーバーシステム30が受信すると、クライアント装置20で動作するブラウザに、アクノリッジ信号102として例えばリンクを送信することによってデータを承認する。
【0037】
使用者は次に、安全装置10へあらかじめ決められた有効化信号103を自動的に始動させるよう設けられたリンクをクリックする。ひとつの実施例として、この始動はブラウザのプラグインによって果たされる。ブラウザにリンクを表示する場合は、専用のプロトコルを用いることができる(例えばolsc://securedevice/login)。このプロトコルは、別のプロトコルハンドラーを用いて実行する。ブラウザのプラグインは、一つの例にすぎないとして理解されたい。専用ソフトウェアにも同じ機能を実現することができるものがある。
【0038】
安全装置10はクライアント装置20の使用者が管理した状態となっており、クライアント装置20と連結する。この連結は、クライアント装置20と安全装置10との間で前もって定義した最小のデータ送信のみ可能であることを意味している。安全装置10の第一の接続手段1によって、有効化信号103を受信する。
【0039】
安全装置10はソフトウェアとしてプログラム化したりハードウェアに組み込んだりすることが可能である。安全装置10は、例えば、出力手段3、入力手段4、接続手段1と2としてのハードウェア手段とソフトウェア手段を含んだものとすることもまた可能である。
【0040】
安全装置10は、クライアント装置20からのあらかじめ定義された有効化信号103だけを処理するよう構成される。データ送信の最小性は、多くの方法や組み合わせで実現することができる。極端な場合として、有効化信号103は1ビットのみとすることもできる。安全装置10の第一の接続手段1におけるバッファ記憶装置の容量を制限することもまた可能である。他の可能性としては、数ビットのパターンを第一の接続手段1向けの入力として許可することである。
【0041】
安全装置10による有効化信号103の肯定的な処理結果の後、サーバーシステム30と安全装置10との間で別々の通信路を通じて、安全なデータ接続を確立する。通信路の安全性を、例えばEACプロトコル(技術指針3110)を使うことによって保証することができる。安全装置10において、サーバーシステム30との通信を、第二の接続手段2で処理する。
【0042】
安全装置10の第二の接続手段2からサーバーシステム30へ、第一の認証要求104を送信する。
【0043】
第二の認証要求105は、クライアント装置20の使用者によって提供されるデータを含む安全装置10の第二の接続手段2へ、サーバーシステム30から送信される。少なくとも、データ送信の要求101からいくらかのデータを、第二の認証要求105においてサーバーシステム30から送信する。これは、例えば金額の要求を送信するものとすることもできる。第二の認証要求105において安全装置10によって受信するデータを、安全装置10の出力手段3上で表示する。記載されている実施例として、出力手段3は、データ送信の要求101で、金額や銀行サービスのアカウント情報を表示可能な英数字の表示部を含む。
【0044】
この情報を正しく表示しているとき、安全装置10の入力手段4へいくらかの認証データ110を提供することで、使用者はデータを認証することができる(例えば、額が正しい、アカウント情報が正しい)。認証は、英数字のデータ(例えば、PINコード、使用者だけが知っている秘密のパスワードやパスフレーズなど)、生体認証データ(例えば、指紋スキャン、虹彩スキャンなど)、使用者だけが知っている秘密のパスワードを含むことができる。
【0045】
認証データ110の入力は、安全装置10からサーバーシステム30へ送る第三の認証要求106を動作させる。この第三の認証要求106は、サーバーシステム30によって証明される電子証明書111と連結する。
【0046】
電子IDは、安全装置10の処理装置の手段5によって作り出される。提示された電子IDは、デジタル署名されたXMLトークンとする。XML構造は、使用者の本人確認がうまくいくようにするためにサーバーが要求する可能性のある本人確認情報を含んでいる。電子証明書111は、電子署名によって電子IDを保護する。電子証明書111は、提示された電子IDの信憑性をサーバーが確認できるようにする。
【0047】
第三の認証要求106の肯定的な確認の後、さらに処理が行われたサーバーシステム30、つまり、クライアント装置20のデータ送信の要求101を承認する。第三の認証要求106の否定的な確認の結果が出た場合、要求されたデータ送信を拒絶する。
【0048】
第三の認証要求106を送信するのに第二の安全な通信路を使うことによって、データ送信の要求101が本物であることを保証できる。例えばトロイやウイルスがクライアント装置20の安全性を侵していた場合、本当はサーバーシステム30に送信されたデータは改ざんされている可能性がある。トロイは例えば別のアカウントに送金されるよう銀行サービスの詳細を変えてしまっている可能性がある。
【0049】
安全装置10の第一の接続手段は、クライアント装置20からのまさに最小のデータ送信を許可しているだけなので、安全性を侵す、つまり安全装置10へトロイが広まるリスクはない。安全装置10は、攻撃に対してそれを保護する極めて制限された形式で、あらかじめ定義された情報を受信する。
【0050】
ここに挙げた各装置は、その全部や一部をソフトウェアかハードウェアで実現することができる。
【0051】
第一の通信装置20を安全装置10と一緒に組み込むこともできる。そうするとそれらは全体としてセキュリティシステムを構成する。この種の一つの可能な実施例は、短距離通信(例えば、WiFi(登録商標)、Bluetooth(登録商標))、USB接続、イーサーネット回線の一つ以上によってパソコンと接続される携帯電話などの第一の通信装置20(安全装置10が組み込まれたもの)とする。他の実施例として、安全装置10は、車や工業的用途の設備(例えばサーバーシステム30に対し自動的に何らかのサービスの要求をする機械)などの現実世界の物体の中に組み込むことができる。この場合、安全装置10を車のマルチメディアシステムや通信システムに接続することができる。
【0052】
原理的には、クライアント装置20は、通常のパソコン、あるいは、任意のハードウェアやソフトウェアのアプリケーション(車内で用いる組み込み装置のように)とすることができる。通常そのようなクライアント装置は、IPベースの通信ネットワークを用いる。
【0053】
安全装置10は、例として、保存された電子IDのための物理的、論理的な保護手段を備えた組み込みシステムにおけるハードウェアやソフトウェアのユニットとする。これは、例えば電子IDのための認証インターフェースや安全な記憶装置を備えた携帯機器として実現することができる。こういった装置は、例えば車か工業製品に組み込むことができる。
【0054】
図2には、クライアント装置20とサーバーシステム30を用いた使用者を含む代表的な通信を示している。
【0055】
クライアント装置20を利用できる使用者が手順1の通信を開始する。つまり、トランザクション要求かあるいは送信要求101(
図2の手順1)とする。サーバーシステム30が、安全装置の通信のための要求を返信する(
図2の手順1.1)。この通信のすべてのタスクが本質的に危険で信頼できないネットワークで行われる。
図2では、この段階を前段階と呼んでいる。
【0056】
以下の手順はすべて信頼できるネットワークで行い、つまり、有効化信号103を用いて開始する。
【0057】
段階1は、機密保持用装置10とサーバーシステム30との間での相互認証である。有効化信号103によって信頼できるネットワーク通信を開始する。これにより、クライアント装置20とサーバーシステム30との間にある暗号化された安全な通信路が確立される。次にその通信路内で、特に対称暗号化を利用して、第二の暗号化された安全な通信路を確立する(
図2の手順2.1.1、2.1.2)。点線は返送メッセージを示す。最後には、両者が同じ対称鍵を所有した状態になる。
【0058】
その結果、相互認証が実現し、クライアント装置20とサーバーシステム30との間に信頼できるネットワークが構築される(
図2の手順2.1.1)。
【0059】
第二の段階では、その通信路で電子IDを交換する(
図2の「使用者の確認」、「通信路の結合」)。
【0060】
使用者は、本人確認の過程を経る必要がある。まず、使用者は、安全装置10から自分のID(例えば、認証の証明書)を入力するよう要求を受ける(手順2.1.3)。使用者は次に、安全装置20の入力手段4において、上で説明した例えばPIN、生体認証(
図2の手順3)方法の一つを用いて認証を行う。
【0061】
成功の場合(
図2の手順3.1)は、第三の認証要求106を生成する手段、つまりサーバーシステム30への電子ID(eID)の送信を、認証データに基づいて始動する。これは通信路の結合とも呼ぶ。
【0062】
クライアント装置20がマイクロチップ付きカード、サーバーシステム30がカード読み取り端末である場合、安全装置10からサーバーシステム30へ電子ID(
図2のeID)を送信する。それゆえ、使用者はサーバーシステムによっても認証される。その認証がないと、トランザクションは行われない。サーバーシステム30はサーバーシステム自身によって確かめることのできる本人性の証明を得る。
【0063】
実質的には、二つの認証が存在する。一つは安全装置10とクライアント装置20との間の認証であり、もう一つは安全装置10とサーバーシステム30との間の認証である。サーバーシステム30は、eIDを確かめる(
図2の手順3.2.1)。成功した場合、使用者が要求したトランザクションを安全装置10へ送信する(
図2の手順3.2.2)。今度は、安全装置10が使用者からトランザクション認証を要求する(
図2の手順3.2.2.1)。
【0064】
安全装置10を用いて、使用者の承認をサーバーシステム30へ送信する(
図2の手順4.4.1)。少なくとも要求したリソースをクライアント装置20へ送信する(
図2の手順4.4.1、4.4.1.1)。
【0065】
図2は、安全装置10が関わるすべての通信が信頼できるネットワークで行われることを示している。
【符号の説明】
【0066】
1 第一の接続手段(クライアント装置と安全装置とを接続するもの)
2 第二の接続手段(サーバーシステムと安全装置とを接続するもの)
3 出力手段
4 入力手段
5 処理装置の手段
10 安全装置
20 第一の通信装置、クライアント装置
30 第二の通信装置、サーバーシステム
101 データ送信の要求
102 アクノリッジ信号(サーバーシステムからクライアント装置へ)
103 有効化信号(クライアント装置から安全装置へ)
104 第一の認証要求(安全装置からサーバーシステムへ)
105 第二の認証要求(サーバーシステムから安全装置へ)
106 第三の認証要求(安全装置からサーバーシステムへ)
110 認証データ(使用者から安全装置へ)
111 電子証明書