JP2015534406A - 安全装置と安全なデータ送信方法 - Google Patents

Abstract

この発明は安全装置（１０）に関するものである。この安全装置（１０）は、本質的に安全でない接続を用いたり本質的に安全でない第一の通信装置（２０）を用いたりして第一の通信装置（２０）と少なくとも一つの第二の通信装置（３０）との間での安全なデータ送信を可能にするものであって、第一の通信装置から少なくとも一つの第二の通信装置（３０）へのデータ送信要求（１０１）に関して、少なくとも一つの第二の通信装置（３０）から第二の認証要求（１０５）を受信するための受信手段（２）と、データ送信要求（１０１）について使用者へ情報を提供するための出力手段（３）とを備え、受信手段（２）がこの出力手段と接続されており、使用者による認証データ（１１０）を入力するための入力手段（４）と、安全装置（１０）での使用者によって、少なくとも一つの第二の通信装置（３０）のために認証データ（１１０）に基づいて第三の認証要求（１０６）を作成する手段と、あらかじめ定義された有効化信号（１０３）のみを安全装置（１０）を用いて受信することと処理することのいずれか又は両方を可能とするよう構成されており、また、有効化信号（１０３）を正しく受信した後でのみ第三の認証要求（１０６）を少なくとも一つの第二の通信装置（３０）への送信可能とするよう構成されている第一の接続手段（１）とを備えたもの。またこの発明は安全なデータ送信に関するものでもある。

Description

本発明は、請求項１に従った安全装置と、請求項１０に従った安全なデータ送信方法に関するものである。

通信装置同士でデータのやり取りが必要となるのは一般的なタスクである。クライアント装置の典型的な例として、インターネットブラウザを用いるパソコンやタブレットコンピューターなどは、サーバーシステムからのデータを必要とする。権限のない人がデータ送信を変更したりクライアント装置のセキュリティを改ざんしたりすることが可能なため、インターネットを介した通常の接続は本質的に不安定である。

オンライン銀行サービスやオンラインショッピングは、クライアント装置の使用者による認証、或いはクライアント装置のところでの認証など、何らかの種類の認証を必要とする典型的なトランザクション（つまりデータ送信）の例である。第一の通信装置（例えばクライアント装置）の使用者や少なくとも一つの第二の通信装置（例えばサーバーシステム）の使用者は、クライアント装置の安全性がトロイの感染などによって侵されていないと確信することはできない。正しい認証の証明書をクライアント装置で得られる（例えば、パスワード、パスフレーズ、ＰＩＮ、トランザクション認証番号）とはいえ、実際にサーバーシステムへ送信されたりサーバーシステムで受信されるデータは何らかの権限のない手段（例えばクライアント装置上にある何らかの権限のないソフトウェア）によって改ざんされる可能性がある。

それゆえ、第一の通信装置（例えばクライアント装置）と通信路のいずれか又は両方が安全かどうか不確かな条件であっても安全にデータを送信できるようにするための装置と方法の開発は望ましいことである。

本質的に安全でない接続を用いたり本質的に安全でない第一の通信装置（例えばクライアント装置）を用いたりして第一の通信装置（例えばクライアント装置）と少なくとも一つの第二の通信装置（例えばサーバーシステム）との間での安全なデータ送信を可能にするために、以下のものを備えた安全装置を構成する。

第一の通信装置（例えばクライアント装置）から少なくとも一つの第二の通信装置（例えばサーバーシステム）へのデータ送信要求に関して、少なくとも一つの第二の通信装置（例えばサーバーシステム）から第二の認証要求を受信するための受信手段。この受信手段は、データ送信の要求について使用者へ情報を提供するための出力手段と接続する。
使用者による認証データの入力のための入力手段。
安全装置での使用者によって、少なくとも一つの第二の通信装置（例えばサーバーシステム）のために認証データに基づいて第三の認証要求を生成する手段。
あらかじめ定義された有効化信号のみを安全装置で受信と処理のいずれか又は両方を可能とするよう構成されており、また、有効化信号を正しく受信した後にのみ第三の認証要求は少なくとも一つの第二の通信装置（例えばサーバーシステム）への送信を可能とするよう構成されている第一の接続手段。あらかじめ定義された有効化信号は、一義的な信号と考えるものとする。

したがって、第一の通信装置と少なくともひとつの第二の通信装置との間のデータ送信は、データ送信自体を行う前にいくつかの認証を行うことが必要となる。その認証とは次のようなものである。
ａ） 第一の通信装置（例えば安全装置を組み込んだもの）から少なくとも一つの第二の通信装置（例えばサーバーシステム）に対する認証。
ｂ） 少なくとも一つの第二の通信装置（例えばサーバーシステム）から第一の通信装置（例えば安全装置を組み込んだもの）に対する認証。これは結果的に相互認証となる。
ｃ） 使用者から安全装置に対する（例えば生体認証のインターフェースを用いた）認証。
ｄ） 使用者から第二の通信サーバーシステムへの電子ＩＤの送信を伴う認証。

第一の通信装置の使用者は、少なくとも一つの第二の通信装置で確認することが可能な電子ＩＤを用いることで認証される。これは結局認証とデータ送信とを合わせること、つまり認証とデータ送信に同じ通信路（例えば暗号化された安全な通信路）を用いることになる。

使用者の認証は安全装置に対して直接行われる。例えばマイクロチップ付きカードを照合する端末機のような外部装置の必要はない。

先行技術との違いは、安全装置に備わっている固有の使用者認証である。したがって、この安全装置は、例えばＰＩＮパッドや生体認証インターフェースなどの外部の入力装置を「追加的に」用いることなく使用者と安全装置との間のやり取りを可能にする入力インターフェースをもつことが特徴となる。安全装置は使用者の電子ＩＤを保護しており、この電子ＩＤは相互認証の段階において相互に認証して受け入れた通信路どうしの接続を構成するのに用いられる。電子ＩＤやその一部の発信は、安全装置における使用者の本人確認を経て許可する。安全装置における電子ＩＤの保護は、使用者の認証がうまくいかない限りは電子ＩＤへのいかなるアクセスもできないような安全な記憶装置によって実現できる。このように安全な記憶装置へのアクセスを保護するという方針は、安全装置の明確な特性となる。

安全装置での使用者の認証のために、使用者が安全装置に対し認証データを提供することもできる。認証データには、特にＰＩＮコード、秘密のパスワードやパスフレーズのように使用者しか知らない英数字データや、特に指紋スキャンや虹彩スキャンのような生体認証のデータのいずれか又は複数を含んでいる。この情報を用いることで、サーバーシステムは送信要求のあったデータが正しいものであって使用者によって認証されたことを確かなものとすることができる。

出力手段は英数字表示装置や点字表示装置を含むため、複雑な情報を使用者に提供することができる。

通信の安全対策として、あらかじめ定められた有効化信号のみを処理することが可能である。したがって、安全装置の第一の接続手段でのバッファ保管の容量を２ｋＢ、さらには１ｋＢより小さいものに制限したり、第一の接続手段向けの入力としてある一定のビットパターンしか許可しないようにしたりする。意図的にバッファ保管を最小化することにより、この場面における安全性を強化できる。通常であれば、安全装置１０はトランザクションＩＤと認証されたサーバーのアドレスを受信することになる。それ以上のものは第二の安全な通信路でのセッションを続けるのに必要ない。

安全な検証のための入力手段は、英数字キーボード、静脈スキャン、指紋スキャン、虹彩スキャンを含む。これらの手段を用いることで、使用者は安全装置に対して安全な入力を行うことができる。

安全装置は、例えば送金やオンライン購入のための第一のデータ送信要求に用いることが可能である。

安全装置は、パソコン、タブレット装置、車、携帯電話、スマートフォンのいずれか又は複数と接続可能な第一の接続手段としたり、安全装置を車などの物体に組み込んだりすることができる。

さらに、次のような段階を含む方法によれば、安全なデータ送信を確保できる。
ａ）クライアント装置からサーバーシステムへデータ送信要求を送信し、
ｂ）データ送信の要求を受信するとサーバーシステムがクライアント装置へアクノリッジ要求を送信し、
ｃ）クライアント装置があらかじめ定められた有効化信号を生成して安全装置に送り、
ｄ）安全装置が第一の認証要求をサーバーシステムに送信し、
ｅ）そのときサーバーシステムが、出力手段で表示するデータ送信要求に関する情報を含む第二の認証要求で返信し、
ｆ）入力手段で使用者から認証データを受信し、
ｇ）認証データに応じた内容の第三の認証要求を、安全装置からサーバーシステムへ送信する。

第一の通信装置はクライアント装置とすることができる。少なくとも一つの第二の通信装置はサーバーシステムとすることができる。

具体的な実施例としては、
ａ）相互認証のため安全装置とサーバーシステムとの間に暗号化された安全な通信路を確立し、
ｂ）その通信路で、特に対称暗号化を用いて暗号化された第二の安全な通信路を確立し、
ｃ）その通信路で電子ＩＤをやり取りする。

代表的な実施例を以下の図と関連させて説明する。
図１は、安全なデータ送信を可能にする安全装置の実施例の概観を示す。 図２は、方法の実施例における通信のシークエンス図を示す。

第二の通信装置としてのサーバーシステム３０と安全装置１０との間に安全な通信路を提供する安全装置１０の実施例には、データ送信、つまり図１で示すようなデータ送信（トランザクション）が関わる。これによって、以下で考察するように、例えばクライアント装置２０のような第一の通信装置と、例えばサーバーシステム３０のような第二の通信装置との間でのデータ送信の認証を可能にする。単純化する理由から、ここで示す実施例は、例えば一つのサーバーシステム３０とするなど、第二の通信装置３０が一つしかないことを前提とする。第二の通信装置３０が二つ以上あるような状況でも、本発明の方法と安全装置１０を用いることが可能である。さらに、サーバーシステム３０という用語は、サーバーとなるコンピューター、特に大型のコンピューターに限定するものではない。サーバーシステム３０は、クライアント装置にサービスを提供できる任意のシステムとすることができる。

以下では、第一の通信装置２０は、第二の通信装置３０であるサーバーシステムへのクライアント装置とする。

典型的な状況は、使用者が、自分のクライアント装置２０からサーバーシステム３０へのデータ送信の要求（トランザクション要求）を開始して完了したい場合である。

クライアント装置２０は、例えば、パソコン、タブレット装置、スマートフォンとすることができる。

要求されたデータ送信は、例えばオンライン銀行サービスのセッションや、インターネット上の店舗での購入、何らかのサービス提供会社の個人登録とすることができる。他の実施例としては、エネルギーの消費者と供給者との間にあるスマートグリッドシステムの状況における処理とすることもできる。消費者は、例えばエネルギー供給者からの遠隔保守といったサービスを求めている。

この実施例はデータ送信の要求で動作することが可能であり、これは、権限を持つ使用者が、正しい内容（例えば正しい金額や正しい口座情報）でデータ送信を開始したり許可をしたりするものである。このような場面でいう「正しい」という言葉は、その正しい内容が使用者の意図した内容と同じであるという意味である。

これらの場合はいずれも、クライアント装置２０とサーバーシステム３０との間で機密情報を送る必要がある。クライアント装置２０の安全性が侵されていないことを使用者は確信できないため、使用者はクライアント装置２０が本質的に安全でないことを前提としなければならない。サーバーシステム３０は、クライアント装置２０からの要求が本物であるかを確かめることができない。

クライアント装置２０からサーバーシステム３０へのデータ送信には、使用者が制御不可能な本質的な不安定性もある。それゆえ、このようなデータ送信もまた、本質的に安全でないとして考えなければならない。

以下に示すように、安全装置１０は、第二の独立して本質的に安全な通信路をサーバーシステム３０に開くため、次にクライアント装置２０とサーバーシステム３０との間の通信を確認することができる。

この文脈でいう本質的な安全性とは、通信路の安全性を使用者やサーバーシステム３０が検証できるということを意味している。これは以下のものに基づいている（図２も参照）。
・クライアント装置２０とサーバーシステム３０との間にある暗号化された安全な通信路を確立する（例えばＴＬＳ）。
・その通信路（例えばＴＬＳ）内で、特に対称暗号化を用いて、第二の暗号化された安全な通信路を確立する。
・その通信路で電子ＩＤを交換する。

二つの暗号化された通信路をつなぐことによって安全性が改善される。最初は、傍受に対する安全性を提供する認証された接続を確立するプロトコルを用いる。加えて、データ送信が行われる第二の通信路を確立する。この二段階の方法の実施例は、図２に記載している。

こうすることにより、クライアント装置２０とサーバーシステム３０との間での電子データ送信を合理的なものにできる。

オンラインでの銀行サービスの例の場合、クライアント装置２０の使用者はクライアント装置２０で動作するブラウザでデータ送信、つまりトランザクションを開始する。他にも、異なるプログラム、例えば専門的な銀行サービスのプログラムを用いることも可能である。他の可能な用途には、例えば、会社のウェブサイトへのログイン、勤務する技術者など外部の作業者のためのサービスポータルへのログイン、コンピューターではなく物理的な場所に出入りできるようにする装置として利用することなどがある。ブラウザを用いても用いなくても、クライアントがインターネットと通信したり、サーバーシステム３０からデータを受信したりできるようにすることは重要である。

上で述べた実施例では、銀行サービスのプラットフォームを起動した後、例えば使用者の名前やパスワードを提示することで、使用者がログインする。ログインの手順では、様々な、あるいは追加的な入力データを用いることができる。

使用者は次に、トランザクションの記入様式、つまり受取人、送金額、銀行サービスの細目などを指定するための記入様式を埋める。

使用者は次に、データ送信形式要求１０１としてサーバーシステム３０へ、トランザクション記入様式のためのポータルを起動した状態でこのデータを送信する。サーバーシステム３０が受信すると、クライアント装置２０で動作するブラウザに、アクノリッジ信号１０２として例えばリンクを送信することによってデータを承認する。

使用者は次に、安全装置１０へあらかじめ決められた有効化信号１０３を自動的に始動させるよう設けられたリンクをクリックする。ひとつの実施例として、この始動はブラウザのプラグインによって果たされる。ブラウザにリンクを表示する場合は、専用のプロトコルを用いることができる（例えばolsc://securedevice/login）。このプロトコルは、別のプロトコルハンドラーを用いて実行する。ブラウザのプラグインは、一つの例にすぎないとして理解されたい。専用ソフトウェアにも同じ機能を実現することができるものがある。

安全装置１０はクライアント装置２０の使用者が管理した状態となっており、クライアント装置２０と連結する。この連結は、クライアント装置２０と安全装置１０との間で前もって定義した最小のデータ送信のみ可能であることを意味している。安全装置１０の第一の接続手段１によって、有効化信号１０３を受信する。

安全装置１０はソフトウェアとしてプログラム化したりハードウェアに組み込んだりすることが可能である。安全装置１０は、例えば、出力手段３、入力手段４、接続手段１と２としてのハードウェア手段とソフトウェア手段を含んだものとすることもまた可能である。

安全装置１０は、クライアント装置２０からのあらかじめ定義された有効化信号１０３だけを処理するよう構成される。データ送信の最小性は、多くの方法や組み合わせで実現することができる。極端な場合として、有効化信号１０３は１ビットのみとすることもできる。安全装置１０の第一の接続手段１におけるバッファ記憶装置の容量を制限することもまた可能である。他の可能性としては、数ビットのパターンを第一の接続手段１向けの入力として許可することである。

安全装置１０による有効化信号１０３の肯定的な処理結果の後、サーバーシステム３０と安全装置１０との間で別々の通信路を通じて、安全なデータ接続を確立する。通信路の安全性を、例えばＥＡＣプロトコル（技術指針３１１０）を使うことによって保証することができる。安全装置１０において、サーバーシステム３０との通信を、第二の接続手段２で処理する。

安全装置１０の第二の接続手段２からサーバーシステム３０へ、第一の認証要求１０４を送信する。

第二の認証要求１０５は、クライアント装置２０の使用者によって提供されるデータを含む安全装置１０の第二の接続手段２へ、サーバーシステム３０から送信される。少なくとも、データ送信の要求１０１からいくらかのデータを、第二の認証要求１０５においてサーバーシステム３０から送信する。これは、例えば金額の要求を送信するものとすることもできる。第二の認証要求１０５において安全装置１０によって受信するデータを、安全装置１０の出力手段３上で表示する。記載されている実施例として、出力手段３は、データ送信の要求１０１で、金額や銀行サービスのアカウント情報を表示可能な英数字の表示部を含む。

この情報を正しく表示しているとき、安全装置１０の入力手段４へいくらかの認証データ１１０を提供することで、使用者はデータを認証することができる（例えば、額が正しい、アカウント情報が正しい）。認証は、英数字のデータ（例えば、ＰＩＮコード、使用者だけが知っている秘密のパスワードやパスフレーズなど）、生体認証データ（例えば、指紋スキャン、虹彩スキャンなど）、使用者だけが知っている秘密のパスワードを含むことができる。

認証データ１１０の入力は、安全装置１０からサーバーシステム３０へ送る第三の認証要求１０６を動作させる。この第三の認証要求１０６は、サーバーシステム３０によって証明される電子証明書１１１と連結する。

電子ＩＤは、安全装置１０の処理装置の手段５によって作り出される。提示された電子ＩＤは、デジタル署名されたＸＭＬトークンとする。ＸＭＬ構造は、使用者の本人確認がうまくいくようにするためにサーバーが要求する可能性のある本人確認情報を含んでいる。電子証明書１１１は、電子署名によって電子ＩＤを保護する。電子証明書１１１は、提示された電子ＩＤの信憑性をサーバーが確認できるようにする。

第三の認証要求１０６の肯定的な確認の後、さらに処理が行われたサーバーシステム３０、つまり、クライアント装置２０のデータ送信の要求１０１を承認する。第三の認証要求１０６の否定的な確認の結果が出た場合、要求されたデータ送信を拒絶する。

第三の認証要求１０６を送信するのに第二の安全な通信路を使うことによって、データ送信の要求１０１が本物であることを保証できる。例えばトロイやウイルスがクライアント装置２０の安全性を侵していた場合、本当はサーバーシステム３０に送信されたデータは改ざんされている可能性がある。トロイは例えば別のアカウントに送金されるよう銀行サービスの詳細を変えてしまっている可能性がある。

安全装置１０の第一の接続手段は、クライアント装置２０からのまさに最小のデータ送信を許可しているだけなので、安全性を侵す、つまり安全装置１０へトロイが広まるリスクはない。安全装置１０は、攻撃に対してそれを保護する極めて制限された形式で、あらかじめ定義された情報を受信する。

ここに挙げた各装置は、その全部や一部をソフトウェアかハードウェアで実現することができる。

第一の通信装置２０を安全装置１０と一緒に組み込むこともできる。そうするとそれらは全体としてセキュリティシステムを構成する。この種の一つの可能な実施例は、短距離通信（例えば、ＷｉＦｉ（登録商標）、Bluetooth（登録商標））、ＵＳＢ接続、イーサーネット回線の一つ以上によってパソコンと接続される携帯電話などの第一の通信装置２０（安全装置１０が組み込まれたもの）とする。他の実施例として、安全装置１０は、車や工業的用途の設備（例えばサーバーシステム３０に対し自動的に何らかのサービスの要求をする機械）などの現実世界の物体の中に組み込むことができる。この場合、安全装置１０を車のマルチメディアシステムや通信システムに接続することができる。

原理的には、クライアント装置２０は、通常のパソコン、あるいは、任意のハードウェアやソフトウェアのアプリケーション（車内で用いる組み込み装置のように）とすることができる。通常そのようなクライアント装置は、ＩＰベースの通信ネットワークを用いる。

安全装置１０は、例として、保存された電子ＩＤのための物理的、論理的な保護手段を備えた組み込みシステムにおけるハードウェアやソフトウェアのユニットとする。これは、例えば電子ＩＤのための認証インターフェースや安全な記憶装置を備えた携帯機器として実現することができる。こういった装置は、例えば車か工業製品に組み込むことができる。

図２には、クライアント装置２０とサーバーシステム３０を用いた使用者を含む代表的な通信を示している。

クライアント装置２０を利用できる使用者が手順１の通信を開始する。つまり、トランザクション要求かあるいは送信要求１０１（図２の手順１）とする。サーバーシステム３０が、安全装置の通信のための要求を返信する（図２の手順１．１）。この通信のすべてのタスクが本質的に危険で信頼できないネットワークで行われる。図２では、この段階を前段階と呼んでいる。

以下の手順はすべて信頼できるネットワークで行い、つまり、有効化信号１０３を用いて開始する。

段階１は、機密保持用装置１０とサーバーシステム３０との間での相互認証である。有効化信号１０３によって信頼できるネットワーク通信を開始する。これにより、クライアント装置２０とサーバーシステム３０との間にある暗号化された安全な通信路が確立される。次にその通信路内で、特に対称暗号化を利用して、第二の暗号化された安全な通信路を確立する（図２の手順２．１．１、２．１．２）。点線は返送メッセージを示す。最後には、両者が同じ対称鍵を所有した状態になる。

その結果、相互認証が実現し、クライアント装置２０とサーバーシステム３０との間に信頼できるネットワークが構築される（図２の手順２．１．１）。

第二の段階では、その通信路で電子ＩＤを交換する（図２の「使用者の確認」、「通信路の結合」）。

使用者は、本人確認の過程を経る必要がある。まず、使用者は、安全装置１０から自分のＩＤ（例えば、認証の証明書）を入力するよう要求を受ける（手順２．１．３）。使用者は次に、安全装置２０の入力手段４において、上で説明した例えばＰＩＮ、生体認証（図２の手順３）方法の一つを用いて認証を行う。

成功の場合（図２の手順３．１）は、第三の認証要求１０６を生成する手段、つまりサーバーシステム３０への電子ＩＤ（ｅＩＤ）の送信を、認証データに基づいて始動する。これは通信路の結合とも呼ぶ。

クライアント装置２０がマイクロチップ付きカード、サーバーシステム３０がカード読み取り端末である場合、安全装置１０からサーバーシステム３０へ電子ＩＤ（図２のｅＩＤ）を送信する。それゆえ、使用者はサーバーシステムによっても認証される。その認証がないと、トランザクションは行われない。サーバーシステム３０はサーバーシステム自身によって確かめることのできる本人性の証明を得る。

実質的には、二つの認証が存在する。一つは安全装置１０とクライアント装置２０との間の認証であり、もう一つは安全装置１０とサーバーシステム３０との間の認証である。サーバーシステム３０は、ｅＩＤを確かめる（図２の手順３．２．１）。成功した場合、使用者が要求したトランザクションを安全装置１０へ送信する（図２の手順３．２．２）。今度は、安全装置１０が使用者からトランザクション認証を要求する（図２の手順３．２．２．１）。

安全装置１０を用いて、使用者の承認をサーバーシステム３０へ送信する（図２の手順４．４．１）。少なくとも要求したリソースをクライアント装置２０へ送信する（図２の手順４．４．１、４．４．１．１）。

図２は、安全装置１０が関わるすべての通信が信頼できるネットワークで行われることを示している。

１ 第一の接続手段（クライアント装置と安全装置とを接続するもの）
２ 第二の接続手段（サーバーシステムと安全装置とを接続するもの）
３ 出力手段
４ 入力手段
５ 処理装置の手段
１０ 安全装置
２０ 第一の通信装置、クライアント装置
３０ 第二の通信装置、サーバーシステム
１０１ データ送信の要求
１０２ アクノリッジ信号（サーバーシステムからクライアント装置へ）
１０３ 有効化信号（クライアント装置から安全装置へ）
１０４ 第一の認証要求（安全装置からサーバーシステムへ）
１０５ 第二の認証要求（サーバーシステムから安全装置へ）
１０６ 第三の認証要求（安全装置からサーバーシステムへ）
１１０ 認証データ（使用者から安全装置へ）
１１１ 電子証明書

Claims (13)

1. 本質的に安全でない接続を用いたり本質的に安全でない第一の通信装置（２０）を用いたりして第一の通信装置（２０）と少なくとも一つの第二の通信装置（３０）との間での安全なデータ送信を可能にするための安全装置（１０）であって、
   第一の通信装置（２０）から少なくとも一つの第二の通信装置（３０）へのデータ送信要求（１０１）に関して、少なくとも一つの第二の通信装置（３０）から第二の認証要求（１０５）を受信するための受信手段（２）と、
   データ送信要求（１０１）について使用者へ情報を提供するための出力手段（３）とを備え、受信手段（２）がこの出力手段（３）と接続されており、
   使用者による認証データ（１１０）を入力するための入力手段（４）と、
   安全装置（１０）での使用者によって、少なくとも一つの第二の通信装置（３０）のために認証データ（１１０）に基づいて第三の認証要求（１０６）を作成する手段と、
   あらかじめ定義された有効化信号（１０３）のみを安全装置（１０）を用いて受信することと処理することのいずれか又は両方を可能とするよう構成されており、また、有効化信号（１０３）を正しく受信した後でのみ、第三の認証要求（１０６）を少なくとも一つの第二の通信装置（３０）への送信可能とするよう構成されている第一の接続手段（１）とを備えたもの。
2. 請求項１の安全装置であって、第一の通信装置（２０）がクライアント装置を含むもの。
3. 請求項１又は２の安全装置であって、少なくとも一つの第二の通信装置（３０）がサーバーシステム（３０）を含むもの。
4. 以上の請求項のうち少なくとも一つの安全装置であって、安全装置での認証データ（１１０）が、特にＰＩＮコード、使用者だけが知っている秘密のパスワードやパスフレーズなどの英数字のデータと、特に指紋スキャン、虹彩スキャンなどの生体認証データとのいずれか又は両方を含むもの。
5. 以上の請求項のうち少なくとも一つの安全装置であって、英数字表示装置と点字表示装置のいずれか又は両方を含むもの。
6. 以上の請求項のうち少なくとも一つの安全装置であって、入力手段（４）が、英数字キーボード、静脈スキャナー、指紋スキャナー、虹彩スキャナーのいずれか又は複数を含むもの。
7. 以上の請求項のうち少なくとも一つの安全装置であって、安全装置（１０）の第一の接続手段（１）でのバッファ記憶装置の容量を２ｋＢ、特に１ｋＢより小さいものに制限することと、第一の接続手段（１）への入力としてある一定のビットパターンのみを許可することのいずれか又は両方とするもの。
8. 以上の請求項のうち少なくとも一つの安全装置であって、第一のデータ送信要求（１０１）を、例えば送金かオンライン購入の要求とするもの。
9. 以上の請求項のうち少なくとも一つの安全装置であって、第一の接続手段（１）がパソコン、タブレット装置、車、携帯電話、スマートフォンのいずれか又は複数と接続可能とすることと、安全装置（１０）を車などの物体に埋め込むことのいずれか又は両方であるもの。
10. 安全なデータ送信のための方法であって、
    ａ）第一の通信装置（２０）から少なくとも一つの第二の通信装置（３０）へデータ送信の要求（１０１）を送信し、
    ｂ）少なくとも一つの第二の通信装置（３０）が、データ送信の要求（１０１）を受信すると、第一の通信装置へのアクノリッジ要求を送信し、
    ｃ）第一の通信装置（２０）が、安全装置（１０）へのあらかじめ定義された有効化信号（１０３）を生成し、
    ｄ）安全装置（１０）が、少なくとも一つの第二の通信装置（３０）へ第一の認証要求（１０４）を送信し、
    ｅ）少なくとも一つの第二の通信装置（３０）が、出力手段（３）によって表示するデータ送信要求（１０１）に関する情報を含む第二の認証要求（１０５）で返信し、
    ｆ）入力手段（４）が、使用者からの認証データを受信し、
    ｇ）内容は認証データ（１１０）に応じて、第三の認証要求（１０６）を、安全装置（１０）から第二の通信装置（３０）へ送信するもの。
11. 請求項１０の方法であって、第一の通信装置（２０）がクライアント装置であるもの。
12. 請求項１０又は１１の方法であって、
    少なくとも一つの第二の通信装置（３０）がサーバーシステム（３０）であるもの。
13. 請求項１０から１２のうち少なくとも一つの方法であって、
    ａ）クライアント装置（２０）とサーバーシステム（３０）との間に暗号化された安全な通信路を確立し
    ｂ）その通信路で第二の暗号化された安全な通信路を、特に対象暗号化を用いて確立し、
    ｃ）その通信路で電子ＩＤをやり取りするもの。
    

Images