セキュリティ装置
【課題】通信する他の装置によりアクセス可能なサービスを有する装置に、改善されたセキュリティを提供する。
【解決手段】他の装置と通信して、それらにアプリケーションへのアクセスを許可する装置であって、少なくとも第１のアプリケーションと、通信装置を認証する認証手段と、前記第１のアプリケーションへのアクセスを要求する、前記認証手段に認証されたことがない通信装置でアクセス可能なアクセス制御手段とを含む。前記装置は、前記通信装置の前記第１のアプリケーションへのアクセスを許可するか拒否するかを裁定するように構成され、前記裁定が前記通信装置の認証を必要とする場合に、前記アクセス制御手段が、前記通信装置を認証するように前記認証手段に対して命令する。
【解決手段】他の装置と通信して、それらにアプリケーションへのアクセスを許可する装置であって、少なくとも第１のアプリケーションと、通信装置を認証する認証手段と、前記第１のアプリケーションへのアクセスを要求する、前記認証手段に認証されたことがない通信装置でアクセス可能なアクセス制御手段とを含む。前記装置は、前記通信装置の前記第１のアプリケーションへのアクセスを許可するか拒否するかを裁定するように構成され、前記裁定が前記通信装置の認証を必要とする場合に、前記アクセス制御手段が、前記通信装置を認証するように前記認証手段に対して命令する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信する他の装置によりアクセス可能なサービスを有する装置に、改善されたセキュリティを提供することに係り、特にブルートゥース規格に従って無線インタフェースを介してアクセスされる装置に関する。
【背景技術】
【０００２】
図１は、無線パケットの送受信により通信する、マスタ装置４、スレーブ装置６、８、および１０からなる無線トランシーバ装置のネットワーク２を示す。ネットワークには、マスタが１つしかない。このネットワークは、時分割二重通信方式で動作する。トランシーバ装置は、マスタ装置４が決定する共通の時間フレームに同期している。この時間フレームは、連続する同じ長さのタイム・スロットからなる。ネットワーク内で送信される各無線パケットは、スロットの始端と一致する始端を有し、単一のパケットをネットワーク内で一度に送信する。マスタ装置がポイント・ツー・ポイント通信を実行している時には、送信される無線パケットを、マスタ装置へとアドレス指定された無線パケットを次に利用可能なタイム・スロットで送信することによってマスタ装置に応答する特定のトランシーバへとアドレス指定する。マスタ装置がポイント・ツー・マルチポイント通信を実行している時には、送信される無線パケットをすべてのトランシーバ装置へとアドレス指定する。マスタとスレーブとの間にずれが生じた時はいつでも、スレーブのタイミングを調整することによって補正する。
【０００３】
この例では、トランシーバは、例えば２．４ＧＨｚのマイクロ波周波数帯で送受信する。このネットワークは、各無線パケットを送信する周波数を変化させることによって干渉を減らす。多くの別個の周波数チャネルのそれぞれを１ＭＨｚの帯域幅で割当てると、周波数は１６００ｈｏｐｓ／ｓの速度でホップする。ネットワーク内で通信、またはネットワークと接続しているトランシーバの周波数ホッピングは、マスタ装置により同期させられ、制御される。一連のホッピング周波数は、そのネットワークに独自のものであって、マスタ装置の独自の識別番号によって決定される。
【０００４】
各トランシーバ装置は、以後ブルートゥースＩＤと呼ぶ、独自の識別番号、すなわち装置ＩＤを有する。各ブルートゥースＩＤ（４８ビットＩＥＥＥアドレス）は、各ブルートゥース装置に独自のものである。装置のブルートゥースＩＤは、ＲＦインタフェースを介したその装置への問合せルーチンによってわかる。
このネットワークは、トランシーバ間での音声情報またはデータ情報の送信に適した無線周波ネットワークである。その送信は、例えば０から２０ｄＢｍの低電力で可能であり、そのトランシーバ装置は、数センチから数１０または数１００メートルの範囲で効果的に通信可能である。
【０００５】
図２に、フレーム２０を示す。このフレーム２０は、ネットワーク２が使用し、マスタ装置４が制御する共通の時間フレームである。図のフレームは、スロット２２乃至２９を有する。偶数で表されたスロットが用意され、マスタ装置のみが、偶数のスロットの始端と一致する無線パケットの送信を開始できる。奇数で表されたスロットが用意され、スレーブが送信した無線パケット、すなわちマスタ装置が受信するようにアドレス指定された無線パケットのみが、奇数のスロットの始端と一致する始端を有することができる。各スロットが、一連のホッピング周波数の異なる１つに割り当てられる。しかし、１つの無線パケットが複数のスロットにわたることができ、この場合、パケットを送信する周波数は、パケットの始端でスロットに割り当てられた周波数で一定のままである。スロットは一定の時間周期を有し、それは通常６２５マイクロセカンドである。
【０００６】
図３に、通常の無線パケット３０を示す。この無線パケットは、始端３２を有し、３つの異なる部分を含む。第１部分は、アクセス・コード３４を含み、第２部分はヘッダ３６を含み、第３部分はペイロード３８を含む。ペイロード３８は、ペイロード・ヘッダ３７を有する。
【０００７】
図４に、トランシーバ装置の概略図を示す。この図には、以下でトランシーバ装置と通信ネットワークがどのように動作するのかを説明するのに必要な多くの機能ブロックおよび相互接続だけを示す。トランシーバ装置４０は、アンテナ４６、受信機５０、同期装置５２、ヘッダ復号器５４、コントローラ６０、メモリ５６、パケット生成器４２、クロック６８、周波数ホップコントローラ４８、および送信機４４からなる多くの機能要素を含む。これらの要素はそれぞれ別々の要素として示されているが、実際には、統合されたり、ソフトウェアまたはハードウェア内に実装可能である。
【０００８】
パケットのペイロード中に入れてトランシーバ装置４０によって送信されるデータは、データ信号４１としてパケット生成器４２へ供給される。パケットのペイロード中に入れて送信される制御情報は、ペイロード制御信号８７としてコントローラ６０からパケット生成器４２へ供給される。パケット生成器４２は、さらに、ペイロードに付加されてパケットを構成するアクセスコード３４およびヘッダ３６をそれぞれ制御するアクセスコード制御信号６９およびヘッダ制御信号７１をコントローラ６０から受信する。パケット生成器４２は、上記データおよび制御情報をパケット３０に入れて、信号４３として送信機４４に供給する。送信機４４は、信号４３に基づいて搬送波を変調し、送信信号４５を生成する。この信号は、アンテナ４６に供給され送信される。搬送波の周波数は、周波数ホップコントローラ４８が送信機４４に供給する送信周波数制御信号４７によって、一連のホップ周波数の１つとなるように制御される。
【０００９】
アンテナ４６は、無線信号５１を受信し、これを周波数コントローラ４８が供給する受信周波数制御信号４９の制御下で復調する受信機５０へ供給し、デジタル信号５３が生成される。このデジタル信号５３は、トランシーバ装置４０をネットワークの時間フレームに同期させる同期装置５２に供給される。同期装置には、トランシーバ装置が受信を期待しているパケットのアクセスコードを指定するアクセスコード信号８１が供給されている。同期装置は、期待アクセスコードと一致するアクセスコードを有する受信無線パケットを受け入れ、期待アクセスコードと一致しないアクセスコードを有する受信無線パケットを受け入れない。無線パケット中の期待アクセスコードの存在および始端を識別するのに可変相関法を使用する。
【００１０】
受け入れられた無線パケットは、信号５５としてヘッダ復号器５４へ供給され、そのパケットが同期装置５２によって受け入れられたことを示す確認信号７９がコントローラ６０へ返される。スレーブ装置のコントローラは、この確認信号７９を使用して、スレーブクロックをマスタクロックに再同期させる。コントローラは、無線パケットの受信時間と期待受信時間とを比較し、その差異を相殺するようにタイミングを変える。ヘッダ復号器５４は、受信パケット中のヘッダを復号し、それをヘッダ信号７５としてコントローラ６０に供給する。ヘッダ復号器５４は、コントローラ６０が供給するペイロード受入れ信号によって作動させられた時、無線パケットの残余部分、すなわちペイロード３８を含むデータ出力を生成する。
メモリ５６は、アプリケーションを格納可能である。
【００１１】
装置の動作は、ブルートゥース・プロトコル・スタック１００を説明する図５からも理解できる。スタック１００は、下から順に、ＲＦ層１０２、ベースバンドおよびリンク制御層１０４、リンクマネージャ・プロトコル層１０６、および論理リンク制御および適応層（Ｌ２ＣＡＰ）１０８からなる基本層を含む。層Ｌ２ＣＡＰ１０８は、ＴＣＰ／ＩＰプロトコルを提供するインターネット層１１２、ユーザ・インタフェース１３０とインタフェースをとるヒューマン・インターフェース装置層１１４、およびＰＣのシリアル・ポート（コム１、コム２、コム３など）をエミュレートするＲＦ通信層１１６を含む複数の上層１１０と接続する。上記層１１２、１１４、および１１６のそれぞれは、１つ又はそれ以上のアプリケーション／サービス１１８と直接接続し、データがいくつかのアプリケーション／サービスの正しい１つに送信されるように、その出力を多重送信できる。層Ｌ２ＣＡＰ１０８もまた、アプリケーション／サービスに直接接続できる。
【００１２】
現在提案されている装置においては、ベースバンドおよびリンク制御層１０４は、問合せおよびページングを使用して装置間の物理ＲＦリンクを有効にし、クロックおよび送信周波数を同期させる。以後リンク層１０６と呼ぶことにするリンクマネージャ・プロトコル層１０６は、パケットサイズ、接続、および電力モードの制御およびセキュリティを含む、２装置間のリンク設定をする役割を果たす。上記提案では、リンク層１０６はリンク管理プロトコルパケット中に受信したペイロードに対応する。
【００１３】
Ｌ２ＣＡＰによって、上位プロトコルは、受信したＬ２ＣＡＰデータパケットのペイロードを受信できる。Ｌ２ＣＡＰプロトコルは、アプリケーションおよび高プロトコル層と接続し、上位プロトコルおよびサービスと下位リンク層１０６との間でデータ送信できる。
パケット３０中のペイロード３８のペイロード・ヘッダ３７は、Ｌ２ＣＡＰパケットとリンク管理プロトコルパケットを識別する。現在、リンク管理プロトコルパケットをリンク層１０６によってろ過して除去し、上位層に伝播させないことが要求されている。
【００１４】
ブルートゥース技術は、アプリケーション層およびリンク層の両方にセキュリティ対策を提供すべきである。現在、各ブルートゥース装置では、リンク層１０６セキュリティ対策は規格化されている。認証および暗号化ルーチンがリンク層１０６の各装置に標準方式で実装されている。
各装置は、別の１つまたは複数の装置との通信に使用する１つ又はそれ以上の秘密認証リンクキーを記憶している。装置は、通常、通信を希望する各装置に対するリンクキーを永久に記憶する。各リンクキーは、通信するために使用されるその装置のブルートゥースＩＤに関連付けられる。
【００１５】
記憶されている秘密リンクキーは、認証ルーチンで使用され、通信しようとする装置の同一性を認証する。記憶されている秘密リンクキーは、暗号化キーを生成するのにも使用される。この暗号化キーは、上記認証リンクキーから派生したものであるが、これとは違うものであり、暗号化を使用するたびに乱数発生器によって新しい暗号化キーが生成される。
【００１６】
装置を認証するのに、チャレンジ式応答計画を使用する。１組の正当な装置が、同じ秘密リンクキーを共有する。第１の装置が乱数を発生させ、この乱数を第２の装置へ送信することによって、第２の装置に認証を要求する。第２の装置は、第２の装置のブルートゥースＩＤ、受信した乱数、および第２の装置に記憶されている第１の装置に関連するキーを、その独立変数にとる関数の答えを返す。第１の装置は、同じ関数を使用して、第２の装置から受信した結果と等しい場合に第２の装置を認証する結果を発生させる。第１の装置の関数は、すでに取得済みの第２装置のブルートゥースＩＤ、上記乱数、および第１の装置に記憶されている第２の装置に関連するキーを独立変数にとる。
【００１７】
この認証手続きは、各装置のリンク層で起こる。認証が首尾よく終了すれば、各装置のプロトコル層、サービス、およびアプリケーションへのアクセスが制限されない。
暗号化が要求されるたびに、乱数を発生させ、この乱数とリンクのための認証キーとから暗号化キーを構成する。この暗号化プロセスは、リンク層１０６で起こる。
【００１８】
２つの装置が以前に通信したことがない場合には、各装置には記憶されている共有リンクキーがないので、２つの装置を「ペアにする」ことが必要になる。これは、１つのＰＩＮ番号を第１の装置のユーザ・インタフェースに入力し、同じＰＩＮ番号を第２の装置のユーザ・インタフェースに入力することによって実行できる。ＰＩＮ番号は、装置間の通信のための永久的共有秘密認証リンクキーの計算以前の一時的初期認証リンクキーの計算に使用できる。
【００１９】
現在提案されているセキュリティシステムが有する問題の１つは、柔軟性がないことである。いったんリンク層１０６が、装置にその上にある各層へのアクセスを許可してしまえば、そのアプリケーション自体に備えられた特定のセキュリティ機能による以外は、そのアクセスを制限できない。より柔軟な改善されたセキュリティシステムを提供することが望ましい。
【発明の開示】
【００２０】
本発明の実施形態は、アプリケーションへのアクセス要求時に、必要に応じて、認証および暗号化などのアクセスチェックをサービスへの接続が要求された時に行う柔軟なセキュリティ構造を提供する。アクセス制御手段は多重送信プロトコル層でも良く、また、認証手段はリンク層でも良い。
【００２１】
サービスへのアクセスを要求する装置を１回認証し、何回も認証しないことが好ましい。これは、サービスへのアクセス要求を１回だけ裁定することにより、好適には最上位にある多重送信層（そのサービスと直接インタフェースをとる層）からの問合せに応答して、実行される。
サービスへのアクセスは、要求されたサービスのセキュリティ要件および／またはアクセス要求した装置の信頼レベルに基づいて裁定できる。このセキュリティ構造は、認証手段（リンク層）に残存する基本機能（ペアリング、認証、暗号化）を変更することなしに実装される。
【００２２】
本発明の実施形態によれば、サービスへのアクセスは、そのサービスにアクセスしようとしている装置の信頼レベルに従う。信頼されている装置は、いったんその同一性が確認されれば、すべてのサービス／アプリケーションにアクセスできる。信頼されていない装置は、サービスにアクセスしようとする度にユーザ認証が要求される。したがって、信頼されていない装置のあるサービスへのアクセス許可は、他のサービスへのアクセスに利用できない。複数の他のサービスにアクセスするには、個々にユーザ認証する必要がある。
以下では、本発明をよりよく理解するために、そして、どうしたら同じ効果が得られるかを理解するために、添付図面を参照して例示的に説明する。
【発明を実施するための形態】
【００２３】
図６は、本発明の１つの実施形態に従ったセキュリティ構造を示す。ブルートゥース・プロトコル・スタック１００は、リンク層１０６と、Ｌ２ＣＡＰ層などの最下位多重送信プロトコル層１０８とを含む下位層、ＲＦＣＯＭＭ層などの上位多重送信プロトコル層１１０、およびアプリケーション層１１８を含む。図には、ユーザ・インタフェース１３０、セキュリティ・マネージャ１２０、サービス・データベース１２２、および装置データベース１２４も示されている。
【００２４】
リンク層１０６は、最下位多重送信プロトコル１０８に直接に接続している。上位多重送信プロトコル１１０およびアプリケーション／サービス１１８へのリンク層１０６からのアクセスは、最下位多重送信プロトコル層１０８を介してのみ実行可能である。
最下位多重送信プロトコル層１０８は、上位多重送信プロトコル１１０およびアプリケーション１１８３に直接に接続している。アプリケーション１１８３へのアクセスは、最下位多重送信プロトコルによって直接に実行可能であるが、アプリケーション１１８１および１１８２へのアクセスは、これらに直接に接続している上位多重送信プロトコル１１０を介してのみ実行可能である。
【００２５】
装置がパケットを受信すると、そのパケットのペイロードは最下位多重送信プロトコル層１０８へ供給される。このペイロードは、リンク層１０６によってろ過されない。受信したパケットがサービス／アプリケーションへのアクセス要求である場合には、そのサービス／アプリケーションへのアクセスが裁定される。
【００２６】
最下位多重送信プロトコル層１０８は、上位多重送信プロトコル層１１０またはアプリケーション１１８３などの上位エンティティへのアクセスを許可するかどうかを尋ねる問合せをセキュリティ・マネージャに送信する。この問合せによって、アクセスが要求されているサービス／アプリケーションおよびアクセスを要求している装置のブルートゥースＩＤを確認する。セキュリティ・マネージャは、次のエンティティへのアクセスを許可すべきかどうかを決定し、リンク層１０６を制御して認証を実行する。問合せプロトコル層が、要求されているサービスに直接に接続していない場合には、セキュリティ・マネージャは、許可信号を問合せプロトコル層１０８へ自動的に送信し、上位多重送信プロトコル層１１０へのアクセスが許可される。問合せプロトコル層１０８が、要求されているサービス１１８３に直接に接続している場合には、セキュリティ・マネージャは、アクセスを許可すべきかどうかを裁定する。アクセスが許可された場合には、セキュリティ・マネージャは、許可信号を最下位多重送信プロトコル層１０８に送信し、最下位多重送信プロトコル層１０８はアプリケーション１１８３へアクセスする。アクセスが許可されない場合には、セキュリティ・マネージャ１２０は、拒否信号を最下位多重送信プロトコル１０８に送信し、アクセスを要求している装置が希望するサービスへのアクセスが妨げられる。
【００２７】
サービス（アプリケーション１１８１または１１８２）へのアクセス要求が最下位多重送信プロトコル１０８から送信されて上位多重送信プロトコル１１０で受信されると、上位多重送信プロトコル１１０は、より上位の多重送信プロトコル層（図示せず）などの上位エンティティへのアクセスなのか、またはアプリケーション１１８１または１１８２へのアクセスなのかを尋ねる問合せをセキュリティ・マネージャに送信する。この問合せによって、アクセス要求されているサービス／アプリケーションおよびアクセスを要求している装置のブルートゥースＩＤが確認される。問合せプロトコル層１１０が、要求されているサービスに直接に接続していない場合には、セキュリティ・マネージャは、許可信号を問合せプロトコル層１０８へ自動的に送信し、上位プロトコル層へのアクセスが許可される。問合せプロトコル層１１０が、要求されているサービスに直接に接続している場合には、セキュリティ・マネージャは、アクセスを許可すべきかどうかを決定するために裁定する。アクセスが許可された場合には、セキュリティ・マネージャは、許可信号を問合せプロトコル層１１０に送信し、問合せプロトコル層１１０は希望するアプリケーションへアクセスする。アクセスが許可されない場合には、セキュリティ・マネージャ１２０は、拒否信号を問合せプロトコル１１０に送信し、アクセスを要求している装置が希望するサービスへのアクセスが妨げられる。
【００２８】
最下位多重送信プロトコル層１０８は、受信したすべてのサービスへのアクセス要求に対して、セキュリティ・マネージャに問い合わせる。セキュリティ・マネージャがアクセスを許可した場合にのみ、要求のより上位の層またはサービスへの進行が可能となる。サービスへの要求が経由する各多重送信プロトコル層は、要求を受信するたびにセキュリティ・マネージャに問い合わせる。セキュリティ・マネージャがアクセスを許可した場合にのみ、要求のより上位の層またはサービスへの進行が可能となる。したがって、セキュリティ・マネージャにより少なくとも１回裁定されなければ、装置はアプリケーション／サービスにアクセスできない。
【００２９】
セキュリティ・マネージャ１２０は、プロトコル１０８および１１０、サービス／アプリケーション１１８、ＵＩ（ユーザ・インタフェース）１３０、データベース１２２および１２４、およびリンク層１０６と接続するためのインタフェースを備えたソフトウェア・モジュールである。このセキュリティ・マネージャは、リンク層と、認証、暗号化およびペアリングなどの標準機能の実行とを制御する。セキュリティ・マネージャは、各プロトコル層がどのサービスと直接アクセスできるかを知っている。
【００３０】
セキュリティ・マネージャは、サービス・データベース１２２、装置データベース、リンク・マネージャ、およびＵＩ１３０に接続するインタフェースを使用して、前述の裁定を実行できる。図７（ａ）および（ｂ）には、それぞれ、一般的なサービス・データベース、および装置データベースを示す。セキュリティ・マネージャは、プロトコル層またはアプリケーションから問合せを受信すると、データベース１２２および１２４に問い合わせる。サービス・データベースからは、要求されているアプリケーション／サービスに関連するフィールドが、装置データベース１２４からは、要求している装置のブルートゥースＩＤに関連するフィールドがそれぞれ入手可能である。
【００３１】
これらのデータベースを使用して、異なる装置およびサービスに対して異なるセキュリティ・レベルを決定する。各装置は、以前に通信したことがある他の装置についての情報を記憶する装置データベースを有する。この装置データベースは、上記他の装置の各ブルートゥースＩＤに対するエントリを有する。各エントリは、その装置が信頼されているかいないかを示す第１のフィールド、その装置と通信するための最新のリンクキーを記憶する第２のフィールド、および最新のセッションにおいてその装置についての認証がうまくいったかどうかを示す第３のフィールドを含む関連フィールドを有する。信頼フィールドは、２値であり、したがって装置が「信頼されている」と、「信頼されていない」の２つのセキュリティ・レベルがある。第１の装置の装置データベース中に、第２の装置は信頼されているという記録があるなら、第２の装置は、認証後、第１の装置のあらゆるサービスにアクセス可能である。第１の装置が、第２の装置は信頼されていないと記録しているなら、第１の装置中のサービス・データベースに基づいて、第２の装置による第１装置のサービスへのアクセスが制限できる。
【００３２】
各装置は、別の装置によってアクセス可能な、その装置中のアプリケーションおよびサービスについての情報を記憶するサービス・データベース（図７（ａ））を有する。このサービス・データベースは、アクセス可能な各アプリケーション／サービスに対するエントリを有する。各エントリは、そのサービスがオープンであるかいなかを示す第１のフィールド、および暗号化が必要かどうかを示す第２のフィールドを含む関連フィールドを有する。このセキュリティ情報は、登録手続き中に、サービス／アプリケーションがセキュリティ・マネージャに提供することができる。
【００３３】
セキュリティ・マネージャは、サービスに関連して３つのセキュリティ・レベルを決定する。どのレベルであるかは、そのサービスのセキュリティ評価（オープン／非オープン）と、要求している装置のセキュリティ評価（信頼されている／信頼されていない）とに依存する。サービスのセキュリティ評価がオープンである時には、要求している装置が信頼されているか否かに依存せず、オープン・サービスはすべての装置に対してオープンである。
【００３４】
サービスのセキュリティ評価が非オープンの時には、アクセスを要求している装置の信頼レベルに依存する。その要求している装置が信頼されている場合には、そのサービスへのアクセスを要求している装置を認証した後に、そのサービスへのアクセスが許可される。その要求している装置が信頼されていない場合には、そのサービスへのアクセスを要求している装置を認証し、明示的ユーザ権限を与えた後に、そのサービスへのアクセスが許可される。
【００３５】
図９乃至１１のフローチャートについて説明する。セキュリティ・マネージャが多重送信プロトコル層１０８または１１０からの問合せ（２００）を受信すると、その問合せ多重送信層が、要求されているサービスと直接に接続している（インタフェースをとっている）かどうかがセキュリティ・マネージャによって決定される（２０１）。プロトコル層からの問合せが、そのプロトコル層は直接に接続していないが上位多重送信プロトコル層を介して間接に接続しているサービスに関係している場合には、セキュリティ・マネージャが、問合せプロトコル層に許可信号を送信することによって、その上位多重送信プロトコル層への要求の通過を許可する。問合せプロトコル層からの問合せが、その問合せプロトコル層が直接に接続しているサービスに関係している場合には、セキュリティ・マネージャは、そのサービスへのアクセスを許可すべきか否かを決定する裁定を実行する。
【００３６】
この裁定は、セキュリティ・マネージャがデータベース１２２および１２４にアクセスする（２０２）ことによって開始され、続いて、要求している装置が信頼されているかどうかを確認し、要求されているサービスがオープンであるか否かを確認する（２０４）。
要求されているサービスがオープン・サービスである場合には、セキュリティ・マネージャは、許可信号を問合せプロトコル層へ送信することによってアクセスを許可し（２１６）、問合せプロトコル層が希望するアプリケーションにアクセスする。要求されているサービスがオープン・サービスでない場合には、この裁定は続く。
【００３７】
要求している装置が信頼されている場合には、認証のみが必要である。要求している装置が、このセッションにおいて以前に認証されたことがない場合には（２０６）（これは、装置データベース中の要求している装置に対するエントリの第３のフィールドから決定される）、セキュリティ・マネージャは、リンク層１０６に対して認証を実行するように命令する（２０８）。図１０について説明する。セキュリティ・マネージャは、（もしあれば）データベース・エントリの第２フィールドに記憶されている最新のキーをリンク層に提供する。リンク層は、（必要であればペアリングと一緒に）認証を実行し、この認証が成功したかどうかをセキュリティ・マネージャに知らせる。ペアリングプロセス（２２２）、リンクキーが通用するかどうかをチェックするプロセス（２２４）、およびリンクキーを作成するプロセスが従属的に実行されるが、これ以上は説明しない。認証が失敗した場合には、セキュリティ・マネージャは、問合せプロトコルに拒否信号を送信することによって希望するサービスへのアクセスを妨げる（２１８）。認証が成功した場合には、リンク層は、要求している装置用の最新のリンクキーを返信する。この場合、セキュリティ・マネージャは装置データベースを更新し（２１０）、データベース・エントリの第２フィールドに上記最新のリンクキーを置き、エントリの第３フィールドにこのセッションにおいて認証が成功したことを示す。それから、セキュリティ・マネージャは、その要求している装置が信頼されている装置であるか否かを決定する（２１２）。その装置が信頼されている場合には、セキュリティ・マネージャは、問合せプロトコルに許可信号を送信することによって、そのサービスへのアクセスを許可する（２１６）。
【００３８】
要求している装置が信頼されていない場合には、認証およびユーザ権限付与が必要となる。要求している装置が、このセッションにおいて以前に認証されたことがない場合には（２０６）（これは、装置データベース中の要求している装置に対するエントリの第３のフィールドから決定される）、セキュリティ・マネージャは、リンク層１０６に対して認証を実行するように命令する（２０８）。セキュリティ・マネージャは、（もしあれば）データベース・エントリの第２フィールドに記憶されている最新のキーをリンク層に提供する。リンク層は、図１０に関して前述したように、（必要であればペアリングと一緒に）認証を実行し、この認証が成功したかどうかをセキュリティ・マネージャに知らせる。認証が失敗した場合には、セキュリティ・マネージャは、問合せプロトコルに拒否信号を送信することによってそのサービスへのアクセスを妨げる（２１８）。認証が成功した場合には、リンク層は、要求している装置用の最新のリンクキーを返信し、セキュリティ・マネージャは、装置データベースを更新し（２１０）、データベース・エントリの第２フィールドに上記最新のリンクキーを置き、エントリの第３フィールドにこのセッションにおいて認証が成功したことを示す。セキュリティ・マネージャは、その要求している装置の信頼状態をチェックする（２１２）。
【００３９】
その装置が信頼されていない場合には、セキュリティ・マネージャは、図１１に示すように、ユーザ権限を取得しようとする（２１４）。セキュリティ・マネージャは、ＵＩ１３０を制御して、要求している装置がサービスへのアクセスを許可されるためには、何らかの積極的行為が必要であることをユーザに示す。上記サービスおよび／または要求している装置は、画面上で確認できる。ユーザは、そのアクセスに同意するかまたは同意しないことができる。同意すれば、セキュリティ・マネージャが問合せプロトコル層に許可信号を送信することによって、要求したサービスへのアクセスが可能となる（２１６）。同意しなければ、セキュリティ・マネージャが問合せプロトコルに拒否信号を送信することによって、要求したサービスへのアクセスが妨げられる。ユーザ権限が与えられたという事実は記録されないので、アクセスは１度限りである。セキュリティ・マネージャは、この場合オプションとして、あとに続く装置データベースの更新（２３４）によって、要求している装置の信頼状態を信頼されていない状態から信頼されている状態へ変更する機会をユーザに提供できる。
【００４０】
認証の他に暗号化も必要な場合には、セキュリティ・マネージャがリンク層１０６を制御してこれを実行した後に、要求されたアプリケーション／サービスへの接続が許可される。
アプリケーション／サービス１１８および上位多重送信プロトコル１１０は、どのアプリケーション／サービスが各プロトコル層に直接に接続しているかをセキュリティ・マネージャが決定できるように、その多重送信方針をセキュリティ・マネージャに登録する必要がある。
【００４１】
図８（ａ）に、信頼されている装置がサービスにアクセスするプロセスをさらに示す。プロトコル層はサービスに直接に接続している。
１．プロトコル層に接続要求を送信。
２．このプロトコル層でアクセス制御を実行する場合に、セキュリティ・マネージャに問合せを送信する。
３．セキュリティ・マネージャが、サービス・データベースを調べる。
４．セキュリティ・マネージャが、装置データベースを調べる。
５．セキュリティ・マネージャが、リンク層で標準認証（および、もし必要なら暗号化）を実行させる。
６．セキュリティ・マネージャが、アクセスを許可する、またはリンクを終了させる。
７．上位プロトコル層／サービスと交信することによって、プロトコル層が、接続を確立し続ける。
【００４２】
図８（ｂ）に、信頼されていない装置がサービスにアクセスするプロセスをさらに示す。プロトコル層はサービスに直接に接続している。
１．プロトコル層に接続要求を送信。
２．このプロトコル層でアクセス制御を実行する場合に、セキュリティ・マネージャに問合せを送信する。
３．セキュリティ・マネージャが、サービス・データベースを調べる。
４．セキュリティ・マネージャが、装置データベースを調べる。
５．セキュリティ・マネージャが、リンク層で標準認証（および、もし必要なら暗号化）を実行させる。
６．セキュリティ・マネージャが、手動によるユーザ承認を要求する。
７．セキュリティ・マネージャが、装置データベースを（信頼されている？に）更新できる。
８．セキュリティ・マネージャが、アクセスを許可する、またはリンクを終了させる。
９．上位プロトコル層／サービスと交信することによって、プロトコル層が、接続を確立し続ける。
【００４３】
この実施形態では、認証（６）の前に認証（５）が実行されるが、認証（５）の前に認証（６）を実行することはもちろん可能である。
以上の記載では、好ましい応用例において請求された発明の好ましい実施例、すなわち、ブルートゥース規格に準拠する低電力無線周波通信ネットワークについて説明している。しかし、本発明の特許請求の範囲から逸脱することなく、他の実施例および応用例を使用できることを理解されたい。
【００４４】
特に、説明した実施形態においては、装置認証が必要か否かは、単純に、要求されたサービスおよびサービス・データベースの内容、特に、そのサービスがオープンであるか否かに依存している。ユーザ認証が必要か否かは、要求されたサービスおよびサービス・データベースの内容、特に、そのサービスがオープンであるか否かに、そして、アクセスを要求している装置の同一性および装置データベースの内容、特に、要求している装置が信頼されているか否かに依存している。
【００４５】
装置認証を、サービスを要求している装置の信頼状態のみに、あるいはこれ以外にも依存させることはもちろん可能である。また、ユーザ認証を、要求されているサービスのみに、あるいはこれ以外にも依存させることは可能である。例えば、ある特定のサービスにアクセスする、信頼されていない装置にとっては、その装置の記憶されている特性値に依存して、ユーザ認証が必要であったり、不要であったりする。
【００４６】
以上の実施形態においては、「安全な」装置中のサービスへのアクセスを要求する装置に関して、セキュリティ構造の動作を説明してきた。このセキュリティ構造は、双方向に動作可能であり、セキュリティ・マネージャの決定がなければ、情報が「安全な」装置から別の装置へ送信されない。プロトコル層、好ましくは最上位多重送信プロトコル層と、セキュリティ・マネージャとが協働して、情報が送信されたか否かを裁定する。この裁定は、以上で説明した認証および／または権限付与を要求しても良い。
【図面の簡単な説明】
【００４７】
【図１】マスタおよびスレーブを含む通信ネットワークを示す図である。
【図２】通信ネットワークの時間フレームを示す図である。
【図３】無線パケットを示す図である。
【図４】マスタまたはスレーブとしての使用に適したトランシーバ装置を示す図である。
【図５】トランシーバ装置が使用するプロトコル・スタックを示す図である。
【図６】セキュリティ構造を示す図である。
【図７】（ａ）はサービス・データベースを示し、（ｂ）は装置データベースを示す図である。
【図８】（ａ）は、信頼されている装置がオープンでないサービスに対するアクセスを要求した時の、セキュリティ構造内での情報流れを示し、（ｂ）は、信頼されていない装置がオープンでないサービスに対するアクセスを要求した時の、セキュリティ構造内での情報流れを示す図である。
【図９】装置がサービスへのアクセスを許可するかどうかを決定するために、コントローラによって実行される裁定プロセスを示すフローチャートである。
【図１０】装置がサービスへのアクセスを許可するかどうかを決定するために、コントローラによって実行される裁定プロセスを示すフローチャートである。
【図１１】装置がサービスへのアクセスを許可するかどうかを決定するために、コントローラによって実行される裁定プロセスを示すフローチャートである。
【技術分野】
【０００１】
本発明は、通信する他の装置によりアクセス可能なサービスを有する装置に、改善されたセキュリティを提供することに係り、特にブルートゥース規格に従って無線インタフェースを介してアクセスされる装置に関する。
【背景技術】
【０００２】
図１は、無線パケットの送受信により通信する、マスタ装置４、スレーブ装置６、８、および１０からなる無線トランシーバ装置のネットワーク２を示す。ネットワークには、マスタが１つしかない。このネットワークは、時分割二重通信方式で動作する。トランシーバ装置は、マスタ装置４が決定する共通の時間フレームに同期している。この時間フレームは、連続する同じ長さのタイム・スロットからなる。ネットワーク内で送信される各無線パケットは、スロットの始端と一致する始端を有し、単一のパケットをネットワーク内で一度に送信する。マスタ装置がポイント・ツー・ポイント通信を実行している時には、送信される無線パケットを、マスタ装置へとアドレス指定された無線パケットを次に利用可能なタイム・スロットで送信することによってマスタ装置に応答する特定のトランシーバへとアドレス指定する。マスタ装置がポイント・ツー・マルチポイント通信を実行している時には、送信される無線パケットをすべてのトランシーバ装置へとアドレス指定する。マスタとスレーブとの間にずれが生じた時はいつでも、スレーブのタイミングを調整することによって補正する。
【０００３】
この例では、トランシーバは、例えば２．４ＧＨｚのマイクロ波周波数帯で送受信する。このネットワークは、各無線パケットを送信する周波数を変化させることによって干渉を減らす。多くの別個の周波数チャネルのそれぞれを１ＭＨｚの帯域幅で割当てると、周波数は１６００ｈｏｐｓ／ｓの速度でホップする。ネットワーク内で通信、またはネットワークと接続しているトランシーバの周波数ホッピングは、マスタ装置により同期させられ、制御される。一連のホッピング周波数は、そのネットワークに独自のものであって、マスタ装置の独自の識別番号によって決定される。
【０００４】
各トランシーバ装置は、以後ブルートゥースＩＤと呼ぶ、独自の識別番号、すなわち装置ＩＤを有する。各ブルートゥースＩＤ（４８ビットＩＥＥＥアドレス）は、各ブルートゥース装置に独自のものである。装置のブルートゥースＩＤは、ＲＦインタフェースを介したその装置への問合せルーチンによってわかる。
このネットワークは、トランシーバ間での音声情報またはデータ情報の送信に適した無線周波ネットワークである。その送信は、例えば０から２０ｄＢｍの低電力で可能であり、そのトランシーバ装置は、数センチから数１０または数１００メートルの範囲で効果的に通信可能である。
【０００５】
図２に、フレーム２０を示す。このフレーム２０は、ネットワーク２が使用し、マスタ装置４が制御する共通の時間フレームである。図のフレームは、スロット２２乃至２９を有する。偶数で表されたスロットが用意され、マスタ装置のみが、偶数のスロットの始端と一致する無線パケットの送信を開始できる。奇数で表されたスロットが用意され、スレーブが送信した無線パケット、すなわちマスタ装置が受信するようにアドレス指定された無線パケットのみが、奇数のスロットの始端と一致する始端を有することができる。各スロットが、一連のホッピング周波数の異なる１つに割り当てられる。しかし、１つの無線パケットが複数のスロットにわたることができ、この場合、パケットを送信する周波数は、パケットの始端でスロットに割り当てられた周波数で一定のままである。スロットは一定の時間周期を有し、それは通常６２５マイクロセカンドである。
【０００６】
図３に、通常の無線パケット３０を示す。この無線パケットは、始端３２を有し、３つの異なる部分を含む。第１部分は、アクセス・コード３４を含み、第２部分はヘッダ３６を含み、第３部分はペイロード３８を含む。ペイロード３８は、ペイロード・ヘッダ３７を有する。
【０００７】
図４に、トランシーバ装置の概略図を示す。この図には、以下でトランシーバ装置と通信ネットワークがどのように動作するのかを説明するのに必要な多くの機能ブロックおよび相互接続だけを示す。トランシーバ装置４０は、アンテナ４６、受信機５０、同期装置５２、ヘッダ復号器５４、コントローラ６０、メモリ５６、パケット生成器４２、クロック６８、周波数ホップコントローラ４８、および送信機４４からなる多くの機能要素を含む。これらの要素はそれぞれ別々の要素として示されているが、実際には、統合されたり、ソフトウェアまたはハードウェア内に実装可能である。
【０００８】
パケットのペイロード中に入れてトランシーバ装置４０によって送信されるデータは、データ信号４１としてパケット生成器４２へ供給される。パケットのペイロード中に入れて送信される制御情報は、ペイロード制御信号８７としてコントローラ６０からパケット生成器４２へ供給される。パケット生成器４２は、さらに、ペイロードに付加されてパケットを構成するアクセスコード３４およびヘッダ３６をそれぞれ制御するアクセスコード制御信号６９およびヘッダ制御信号７１をコントローラ６０から受信する。パケット生成器４２は、上記データおよび制御情報をパケット３０に入れて、信号４３として送信機４４に供給する。送信機４４は、信号４３に基づいて搬送波を変調し、送信信号４５を生成する。この信号は、アンテナ４６に供給され送信される。搬送波の周波数は、周波数ホップコントローラ４８が送信機４４に供給する送信周波数制御信号４７によって、一連のホップ周波数の１つとなるように制御される。
【０００９】
アンテナ４６は、無線信号５１を受信し、これを周波数コントローラ４８が供給する受信周波数制御信号４９の制御下で復調する受信機５０へ供給し、デジタル信号５３が生成される。このデジタル信号５３は、トランシーバ装置４０をネットワークの時間フレームに同期させる同期装置５２に供給される。同期装置には、トランシーバ装置が受信を期待しているパケットのアクセスコードを指定するアクセスコード信号８１が供給されている。同期装置は、期待アクセスコードと一致するアクセスコードを有する受信無線パケットを受け入れ、期待アクセスコードと一致しないアクセスコードを有する受信無線パケットを受け入れない。無線パケット中の期待アクセスコードの存在および始端を識別するのに可変相関法を使用する。
【００１０】
受け入れられた無線パケットは、信号５５としてヘッダ復号器５４へ供給され、そのパケットが同期装置５２によって受け入れられたことを示す確認信号７９がコントローラ６０へ返される。スレーブ装置のコントローラは、この確認信号７９を使用して、スレーブクロックをマスタクロックに再同期させる。コントローラは、無線パケットの受信時間と期待受信時間とを比較し、その差異を相殺するようにタイミングを変える。ヘッダ復号器５４は、受信パケット中のヘッダを復号し、それをヘッダ信号７５としてコントローラ６０に供給する。ヘッダ復号器５４は、コントローラ６０が供給するペイロード受入れ信号によって作動させられた時、無線パケットの残余部分、すなわちペイロード３８を含むデータ出力を生成する。
メモリ５６は、アプリケーションを格納可能である。
【００１１】
装置の動作は、ブルートゥース・プロトコル・スタック１００を説明する図５からも理解できる。スタック１００は、下から順に、ＲＦ層１０２、ベースバンドおよびリンク制御層１０４、リンクマネージャ・プロトコル層１０６、および論理リンク制御および適応層（Ｌ２ＣＡＰ）１０８からなる基本層を含む。層Ｌ２ＣＡＰ１０８は、ＴＣＰ／ＩＰプロトコルを提供するインターネット層１１２、ユーザ・インタフェース１３０とインタフェースをとるヒューマン・インターフェース装置層１１４、およびＰＣのシリアル・ポート（コム１、コム２、コム３など）をエミュレートするＲＦ通信層１１６を含む複数の上層１１０と接続する。上記層１１２、１１４、および１１６のそれぞれは、１つ又はそれ以上のアプリケーション／サービス１１８と直接接続し、データがいくつかのアプリケーション／サービスの正しい１つに送信されるように、その出力を多重送信できる。層Ｌ２ＣＡＰ１０８もまた、アプリケーション／サービスに直接接続できる。
【００１２】
現在提案されている装置においては、ベースバンドおよびリンク制御層１０４は、問合せおよびページングを使用して装置間の物理ＲＦリンクを有効にし、クロックおよび送信周波数を同期させる。以後リンク層１０６と呼ぶことにするリンクマネージャ・プロトコル層１０６は、パケットサイズ、接続、および電力モードの制御およびセキュリティを含む、２装置間のリンク設定をする役割を果たす。上記提案では、リンク層１０６はリンク管理プロトコルパケット中に受信したペイロードに対応する。
【００１３】
Ｌ２ＣＡＰによって、上位プロトコルは、受信したＬ２ＣＡＰデータパケットのペイロードを受信できる。Ｌ２ＣＡＰプロトコルは、アプリケーションおよび高プロトコル層と接続し、上位プロトコルおよびサービスと下位リンク層１０６との間でデータ送信できる。
パケット３０中のペイロード３８のペイロード・ヘッダ３７は、Ｌ２ＣＡＰパケットとリンク管理プロトコルパケットを識別する。現在、リンク管理プロトコルパケットをリンク層１０６によってろ過して除去し、上位層に伝播させないことが要求されている。
【００１４】
ブルートゥース技術は、アプリケーション層およびリンク層の両方にセキュリティ対策を提供すべきである。現在、各ブルートゥース装置では、リンク層１０６セキュリティ対策は規格化されている。認証および暗号化ルーチンがリンク層１０６の各装置に標準方式で実装されている。
各装置は、別の１つまたは複数の装置との通信に使用する１つ又はそれ以上の秘密認証リンクキーを記憶している。装置は、通常、通信を希望する各装置に対するリンクキーを永久に記憶する。各リンクキーは、通信するために使用されるその装置のブルートゥースＩＤに関連付けられる。
【００１５】
記憶されている秘密リンクキーは、認証ルーチンで使用され、通信しようとする装置の同一性を認証する。記憶されている秘密リンクキーは、暗号化キーを生成するのにも使用される。この暗号化キーは、上記認証リンクキーから派生したものであるが、これとは違うものであり、暗号化を使用するたびに乱数発生器によって新しい暗号化キーが生成される。
【００１６】
装置を認証するのに、チャレンジ式応答計画を使用する。１組の正当な装置が、同じ秘密リンクキーを共有する。第１の装置が乱数を発生させ、この乱数を第２の装置へ送信することによって、第２の装置に認証を要求する。第２の装置は、第２の装置のブルートゥースＩＤ、受信した乱数、および第２の装置に記憶されている第１の装置に関連するキーを、その独立変数にとる関数の答えを返す。第１の装置は、同じ関数を使用して、第２の装置から受信した結果と等しい場合に第２の装置を認証する結果を発生させる。第１の装置の関数は、すでに取得済みの第２装置のブルートゥースＩＤ、上記乱数、および第１の装置に記憶されている第２の装置に関連するキーを独立変数にとる。
【００１７】
この認証手続きは、各装置のリンク層で起こる。認証が首尾よく終了すれば、各装置のプロトコル層、サービス、およびアプリケーションへのアクセスが制限されない。
暗号化が要求されるたびに、乱数を発生させ、この乱数とリンクのための認証キーとから暗号化キーを構成する。この暗号化プロセスは、リンク層１０６で起こる。
【００１８】
２つの装置が以前に通信したことがない場合には、各装置には記憶されている共有リンクキーがないので、２つの装置を「ペアにする」ことが必要になる。これは、１つのＰＩＮ番号を第１の装置のユーザ・インタフェースに入力し、同じＰＩＮ番号を第２の装置のユーザ・インタフェースに入力することによって実行できる。ＰＩＮ番号は、装置間の通信のための永久的共有秘密認証リンクキーの計算以前の一時的初期認証リンクキーの計算に使用できる。
【００１９】
現在提案されているセキュリティシステムが有する問題の１つは、柔軟性がないことである。いったんリンク層１０６が、装置にその上にある各層へのアクセスを許可してしまえば、そのアプリケーション自体に備えられた特定のセキュリティ機能による以外は、そのアクセスを制限できない。より柔軟な改善されたセキュリティシステムを提供することが望ましい。
【発明の開示】
【００２０】
本発明の実施形態は、アプリケーションへのアクセス要求時に、必要に応じて、認証および暗号化などのアクセスチェックをサービスへの接続が要求された時に行う柔軟なセキュリティ構造を提供する。アクセス制御手段は多重送信プロトコル層でも良く、また、認証手段はリンク層でも良い。
【００２１】
サービスへのアクセスを要求する装置を１回認証し、何回も認証しないことが好ましい。これは、サービスへのアクセス要求を１回だけ裁定することにより、好適には最上位にある多重送信層（そのサービスと直接インタフェースをとる層）からの問合せに応答して、実行される。
サービスへのアクセスは、要求されたサービスのセキュリティ要件および／またはアクセス要求した装置の信頼レベルに基づいて裁定できる。このセキュリティ構造は、認証手段（リンク層）に残存する基本機能（ペアリング、認証、暗号化）を変更することなしに実装される。
【００２２】
本発明の実施形態によれば、サービスへのアクセスは、そのサービスにアクセスしようとしている装置の信頼レベルに従う。信頼されている装置は、いったんその同一性が確認されれば、すべてのサービス／アプリケーションにアクセスできる。信頼されていない装置は、サービスにアクセスしようとする度にユーザ認証が要求される。したがって、信頼されていない装置のあるサービスへのアクセス許可は、他のサービスへのアクセスに利用できない。複数の他のサービスにアクセスするには、個々にユーザ認証する必要がある。
以下では、本発明をよりよく理解するために、そして、どうしたら同じ効果が得られるかを理解するために、添付図面を参照して例示的に説明する。
【発明を実施するための形態】
【００２３】
図６は、本発明の１つの実施形態に従ったセキュリティ構造を示す。ブルートゥース・プロトコル・スタック１００は、リンク層１０６と、Ｌ２ＣＡＰ層などの最下位多重送信プロトコル層１０８とを含む下位層、ＲＦＣＯＭＭ層などの上位多重送信プロトコル層１１０、およびアプリケーション層１１８を含む。図には、ユーザ・インタフェース１３０、セキュリティ・マネージャ１２０、サービス・データベース１２２、および装置データベース１２４も示されている。
【００２４】
リンク層１０６は、最下位多重送信プロトコル１０８に直接に接続している。上位多重送信プロトコル１１０およびアプリケーション／サービス１１８へのリンク層１０６からのアクセスは、最下位多重送信プロトコル層１０８を介してのみ実行可能である。
最下位多重送信プロトコル層１０８は、上位多重送信プロトコル１１０およびアプリケーション１１８３に直接に接続している。アプリケーション１１８３へのアクセスは、最下位多重送信プロトコルによって直接に実行可能であるが、アプリケーション１１８１および１１８２へのアクセスは、これらに直接に接続している上位多重送信プロトコル１１０を介してのみ実行可能である。
【００２５】
装置がパケットを受信すると、そのパケットのペイロードは最下位多重送信プロトコル層１０８へ供給される。このペイロードは、リンク層１０６によってろ過されない。受信したパケットがサービス／アプリケーションへのアクセス要求である場合には、そのサービス／アプリケーションへのアクセスが裁定される。
【００２６】
最下位多重送信プロトコル層１０８は、上位多重送信プロトコル層１１０またはアプリケーション１１８３などの上位エンティティへのアクセスを許可するかどうかを尋ねる問合せをセキュリティ・マネージャに送信する。この問合せによって、アクセスが要求されているサービス／アプリケーションおよびアクセスを要求している装置のブルートゥースＩＤを確認する。セキュリティ・マネージャは、次のエンティティへのアクセスを許可すべきかどうかを決定し、リンク層１０６を制御して認証を実行する。問合せプロトコル層が、要求されているサービスに直接に接続していない場合には、セキュリティ・マネージャは、許可信号を問合せプロトコル層１０８へ自動的に送信し、上位多重送信プロトコル層１１０へのアクセスが許可される。問合せプロトコル層１０８が、要求されているサービス１１８３に直接に接続している場合には、セキュリティ・マネージャは、アクセスを許可すべきかどうかを裁定する。アクセスが許可された場合には、セキュリティ・マネージャは、許可信号を最下位多重送信プロトコル層１０８に送信し、最下位多重送信プロトコル層１０８はアプリケーション１１８３へアクセスする。アクセスが許可されない場合には、セキュリティ・マネージャ１２０は、拒否信号を最下位多重送信プロトコル１０８に送信し、アクセスを要求している装置が希望するサービスへのアクセスが妨げられる。
【００２７】
サービス（アプリケーション１１８１または１１８２）へのアクセス要求が最下位多重送信プロトコル１０８から送信されて上位多重送信プロトコル１１０で受信されると、上位多重送信プロトコル１１０は、より上位の多重送信プロトコル層（図示せず）などの上位エンティティへのアクセスなのか、またはアプリケーション１１８１または１１８２へのアクセスなのかを尋ねる問合せをセキュリティ・マネージャに送信する。この問合せによって、アクセス要求されているサービス／アプリケーションおよびアクセスを要求している装置のブルートゥースＩＤが確認される。問合せプロトコル層１１０が、要求されているサービスに直接に接続していない場合には、セキュリティ・マネージャは、許可信号を問合せプロトコル層１０８へ自動的に送信し、上位プロトコル層へのアクセスが許可される。問合せプロトコル層１１０が、要求されているサービスに直接に接続している場合には、セキュリティ・マネージャは、アクセスを許可すべきかどうかを決定するために裁定する。アクセスが許可された場合には、セキュリティ・マネージャは、許可信号を問合せプロトコル層１１０に送信し、問合せプロトコル層１１０は希望するアプリケーションへアクセスする。アクセスが許可されない場合には、セキュリティ・マネージャ１２０は、拒否信号を問合せプロトコル１１０に送信し、アクセスを要求している装置が希望するサービスへのアクセスが妨げられる。
【００２８】
最下位多重送信プロトコル層１０８は、受信したすべてのサービスへのアクセス要求に対して、セキュリティ・マネージャに問い合わせる。セキュリティ・マネージャがアクセスを許可した場合にのみ、要求のより上位の層またはサービスへの進行が可能となる。サービスへの要求が経由する各多重送信プロトコル層は、要求を受信するたびにセキュリティ・マネージャに問い合わせる。セキュリティ・マネージャがアクセスを許可した場合にのみ、要求のより上位の層またはサービスへの進行が可能となる。したがって、セキュリティ・マネージャにより少なくとも１回裁定されなければ、装置はアプリケーション／サービスにアクセスできない。
【００２９】
セキュリティ・マネージャ１２０は、プロトコル１０８および１１０、サービス／アプリケーション１１８、ＵＩ（ユーザ・インタフェース）１３０、データベース１２２および１２４、およびリンク層１０６と接続するためのインタフェースを備えたソフトウェア・モジュールである。このセキュリティ・マネージャは、リンク層と、認証、暗号化およびペアリングなどの標準機能の実行とを制御する。セキュリティ・マネージャは、各プロトコル層がどのサービスと直接アクセスできるかを知っている。
【００３０】
セキュリティ・マネージャは、サービス・データベース１２２、装置データベース、リンク・マネージャ、およびＵＩ１３０に接続するインタフェースを使用して、前述の裁定を実行できる。図７（ａ）および（ｂ）には、それぞれ、一般的なサービス・データベース、および装置データベースを示す。セキュリティ・マネージャは、プロトコル層またはアプリケーションから問合せを受信すると、データベース１２２および１２４に問い合わせる。サービス・データベースからは、要求されているアプリケーション／サービスに関連するフィールドが、装置データベース１２４からは、要求している装置のブルートゥースＩＤに関連するフィールドがそれぞれ入手可能である。
【００３１】
これらのデータベースを使用して、異なる装置およびサービスに対して異なるセキュリティ・レベルを決定する。各装置は、以前に通信したことがある他の装置についての情報を記憶する装置データベースを有する。この装置データベースは、上記他の装置の各ブルートゥースＩＤに対するエントリを有する。各エントリは、その装置が信頼されているかいないかを示す第１のフィールド、その装置と通信するための最新のリンクキーを記憶する第２のフィールド、および最新のセッションにおいてその装置についての認証がうまくいったかどうかを示す第３のフィールドを含む関連フィールドを有する。信頼フィールドは、２値であり、したがって装置が「信頼されている」と、「信頼されていない」の２つのセキュリティ・レベルがある。第１の装置の装置データベース中に、第２の装置は信頼されているという記録があるなら、第２の装置は、認証後、第１の装置のあらゆるサービスにアクセス可能である。第１の装置が、第２の装置は信頼されていないと記録しているなら、第１の装置中のサービス・データベースに基づいて、第２の装置による第１装置のサービスへのアクセスが制限できる。
【００３２】
各装置は、別の装置によってアクセス可能な、その装置中のアプリケーションおよびサービスについての情報を記憶するサービス・データベース（図７（ａ））を有する。このサービス・データベースは、アクセス可能な各アプリケーション／サービスに対するエントリを有する。各エントリは、そのサービスがオープンであるかいなかを示す第１のフィールド、および暗号化が必要かどうかを示す第２のフィールドを含む関連フィールドを有する。このセキュリティ情報は、登録手続き中に、サービス／アプリケーションがセキュリティ・マネージャに提供することができる。
【００３３】
セキュリティ・マネージャは、サービスに関連して３つのセキュリティ・レベルを決定する。どのレベルであるかは、そのサービスのセキュリティ評価（オープン／非オープン）と、要求している装置のセキュリティ評価（信頼されている／信頼されていない）とに依存する。サービスのセキュリティ評価がオープンである時には、要求している装置が信頼されているか否かに依存せず、オープン・サービスはすべての装置に対してオープンである。
【００３４】
サービスのセキュリティ評価が非オープンの時には、アクセスを要求している装置の信頼レベルに依存する。その要求している装置が信頼されている場合には、そのサービスへのアクセスを要求している装置を認証した後に、そのサービスへのアクセスが許可される。その要求している装置が信頼されていない場合には、そのサービスへのアクセスを要求している装置を認証し、明示的ユーザ権限を与えた後に、そのサービスへのアクセスが許可される。
【００３５】
図９乃至１１のフローチャートについて説明する。セキュリティ・マネージャが多重送信プロトコル層１０８または１１０からの問合せ（２００）を受信すると、その問合せ多重送信層が、要求されているサービスと直接に接続している（インタフェースをとっている）かどうかがセキュリティ・マネージャによって決定される（２０１）。プロトコル層からの問合せが、そのプロトコル層は直接に接続していないが上位多重送信プロトコル層を介して間接に接続しているサービスに関係している場合には、セキュリティ・マネージャが、問合せプロトコル層に許可信号を送信することによって、その上位多重送信プロトコル層への要求の通過を許可する。問合せプロトコル層からの問合せが、その問合せプロトコル層が直接に接続しているサービスに関係している場合には、セキュリティ・マネージャは、そのサービスへのアクセスを許可すべきか否かを決定する裁定を実行する。
【００３６】
この裁定は、セキュリティ・マネージャがデータベース１２２および１２４にアクセスする（２０２）ことによって開始され、続いて、要求している装置が信頼されているかどうかを確認し、要求されているサービスがオープンであるか否かを確認する（２０４）。
要求されているサービスがオープン・サービスである場合には、セキュリティ・マネージャは、許可信号を問合せプロトコル層へ送信することによってアクセスを許可し（２１６）、問合せプロトコル層が希望するアプリケーションにアクセスする。要求されているサービスがオープン・サービスでない場合には、この裁定は続く。
【００３７】
要求している装置が信頼されている場合には、認証のみが必要である。要求している装置が、このセッションにおいて以前に認証されたことがない場合には（２０６）（これは、装置データベース中の要求している装置に対するエントリの第３のフィールドから決定される）、セキュリティ・マネージャは、リンク層１０６に対して認証を実行するように命令する（２０８）。図１０について説明する。セキュリティ・マネージャは、（もしあれば）データベース・エントリの第２フィールドに記憶されている最新のキーをリンク層に提供する。リンク層は、（必要であればペアリングと一緒に）認証を実行し、この認証が成功したかどうかをセキュリティ・マネージャに知らせる。ペアリングプロセス（２２２）、リンクキーが通用するかどうかをチェックするプロセス（２２４）、およびリンクキーを作成するプロセスが従属的に実行されるが、これ以上は説明しない。認証が失敗した場合には、セキュリティ・マネージャは、問合せプロトコルに拒否信号を送信することによって希望するサービスへのアクセスを妨げる（２１８）。認証が成功した場合には、リンク層は、要求している装置用の最新のリンクキーを返信する。この場合、セキュリティ・マネージャは装置データベースを更新し（２１０）、データベース・エントリの第２フィールドに上記最新のリンクキーを置き、エントリの第３フィールドにこのセッションにおいて認証が成功したことを示す。それから、セキュリティ・マネージャは、その要求している装置が信頼されている装置であるか否かを決定する（２１２）。その装置が信頼されている場合には、セキュリティ・マネージャは、問合せプロトコルに許可信号を送信することによって、そのサービスへのアクセスを許可する（２１６）。
【００３８】
要求している装置が信頼されていない場合には、認証およびユーザ権限付与が必要となる。要求している装置が、このセッションにおいて以前に認証されたことがない場合には（２０６）（これは、装置データベース中の要求している装置に対するエントリの第３のフィールドから決定される）、セキュリティ・マネージャは、リンク層１０６に対して認証を実行するように命令する（２０８）。セキュリティ・マネージャは、（もしあれば）データベース・エントリの第２フィールドに記憶されている最新のキーをリンク層に提供する。リンク層は、図１０に関して前述したように、（必要であればペアリングと一緒に）認証を実行し、この認証が成功したかどうかをセキュリティ・マネージャに知らせる。認証が失敗した場合には、セキュリティ・マネージャは、問合せプロトコルに拒否信号を送信することによってそのサービスへのアクセスを妨げる（２１８）。認証が成功した場合には、リンク層は、要求している装置用の最新のリンクキーを返信し、セキュリティ・マネージャは、装置データベースを更新し（２１０）、データベース・エントリの第２フィールドに上記最新のリンクキーを置き、エントリの第３フィールドにこのセッションにおいて認証が成功したことを示す。セキュリティ・マネージャは、その要求している装置の信頼状態をチェックする（２１２）。
【００３９】
その装置が信頼されていない場合には、セキュリティ・マネージャは、図１１に示すように、ユーザ権限を取得しようとする（２１４）。セキュリティ・マネージャは、ＵＩ１３０を制御して、要求している装置がサービスへのアクセスを許可されるためには、何らかの積極的行為が必要であることをユーザに示す。上記サービスおよび／または要求している装置は、画面上で確認できる。ユーザは、そのアクセスに同意するかまたは同意しないことができる。同意すれば、セキュリティ・マネージャが問合せプロトコル層に許可信号を送信することによって、要求したサービスへのアクセスが可能となる（２１６）。同意しなければ、セキュリティ・マネージャが問合せプロトコルに拒否信号を送信することによって、要求したサービスへのアクセスが妨げられる。ユーザ権限が与えられたという事実は記録されないので、アクセスは１度限りである。セキュリティ・マネージャは、この場合オプションとして、あとに続く装置データベースの更新（２３４）によって、要求している装置の信頼状態を信頼されていない状態から信頼されている状態へ変更する機会をユーザに提供できる。
【００４０】
認証の他に暗号化も必要な場合には、セキュリティ・マネージャがリンク層１０６を制御してこれを実行した後に、要求されたアプリケーション／サービスへの接続が許可される。
アプリケーション／サービス１１８および上位多重送信プロトコル１１０は、どのアプリケーション／サービスが各プロトコル層に直接に接続しているかをセキュリティ・マネージャが決定できるように、その多重送信方針をセキュリティ・マネージャに登録する必要がある。
【００４１】
図８（ａ）に、信頼されている装置がサービスにアクセスするプロセスをさらに示す。プロトコル層はサービスに直接に接続している。
１．プロトコル層に接続要求を送信。
２．このプロトコル層でアクセス制御を実行する場合に、セキュリティ・マネージャに問合せを送信する。
３．セキュリティ・マネージャが、サービス・データベースを調べる。
４．セキュリティ・マネージャが、装置データベースを調べる。
５．セキュリティ・マネージャが、リンク層で標準認証（および、もし必要なら暗号化）を実行させる。
６．セキュリティ・マネージャが、アクセスを許可する、またはリンクを終了させる。
７．上位プロトコル層／サービスと交信することによって、プロトコル層が、接続を確立し続ける。
【００４２】
図８（ｂ）に、信頼されていない装置がサービスにアクセスするプロセスをさらに示す。プロトコル層はサービスに直接に接続している。
１．プロトコル層に接続要求を送信。
２．このプロトコル層でアクセス制御を実行する場合に、セキュリティ・マネージャに問合せを送信する。
３．セキュリティ・マネージャが、サービス・データベースを調べる。
４．セキュリティ・マネージャが、装置データベースを調べる。
５．セキュリティ・マネージャが、リンク層で標準認証（および、もし必要なら暗号化）を実行させる。
６．セキュリティ・マネージャが、手動によるユーザ承認を要求する。
７．セキュリティ・マネージャが、装置データベースを（信頼されている？に）更新できる。
８．セキュリティ・マネージャが、アクセスを許可する、またはリンクを終了させる。
９．上位プロトコル層／サービスと交信することによって、プロトコル層が、接続を確立し続ける。
【００４３】
この実施形態では、認証（６）の前に認証（５）が実行されるが、認証（５）の前に認証（６）を実行することはもちろん可能である。
以上の記載では、好ましい応用例において請求された発明の好ましい実施例、すなわち、ブルートゥース規格に準拠する低電力無線周波通信ネットワークについて説明している。しかし、本発明の特許請求の範囲から逸脱することなく、他の実施例および応用例を使用できることを理解されたい。
【００４４】
特に、説明した実施形態においては、装置認証が必要か否かは、単純に、要求されたサービスおよびサービス・データベースの内容、特に、そのサービスがオープンであるか否かに依存している。ユーザ認証が必要か否かは、要求されたサービスおよびサービス・データベースの内容、特に、そのサービスがオープンであるか否かに、そして、アクセスを要求している装置の同一性および装置データベースの内容、特に、要求している装置が信頼されているか否かに依存している。
【００４５】
装置認証を、サービスを要求している装置の信頼状態のみに、あるいはこれ以外にも依存させることはもちろん可能である。また、ユーザ認証を、要求されているサービスのみに、あるいはこれ以外にも依存させることは可能である。例えば、ある特定のサービスにアクセスする、信頼されていない装置にとっては、その装置の記憶されている特性値に依存して、ユーザ認証が必要であったり、不要であったりする。
【００４６】
以上の実施形態においては、「安全な」装置中のサービスへのアクセスを要求する装置に関して、セキュリティ構造の動作を説明してきた。このセキュリティ構造は、双方向に動作可能であり、セキュリティ・マネージャの決定がなければ、情報が「安全な」装置から別の装置へ送信されない。プロトコル層、好ましくは最上位多重送信プロトコル層と、セキュリティ・マネージャとが協働して、情報が送信されたか否かを裁定する。この裁定は、以上で説明した認証および／または権限付与を要求しても良い。
【図面の簡単な説明】
【００４７】
【図１】マスタおよびスレーブを含む通信ネットワークを示す図である。
【図２】通信ネットワークの時間フレームを示す図である。
【図３】無線パケットを示す図である。
【図４】マスタまたはスレーブとしての使用に適したトランシーバ装置を示す図である。
【図５】トランシーバ装置が使用するプロトコル・スタックを示す図である。
【図６】セキュリティ構造を示す図である。
【図７】（ａ）はサービス・データベースを示し、（ｂ）は装置データベースを示す図である。
【図８】（ａ）は、信頼されている装置がオープンでないサービスに対するアクセスを要求した時の、セキュリティ構造内での情報流れを示し、（ｂ）は、信頼されていない装置がオープンでないサービスに対するアクセスを要求した時の、セキュリティ構造内での情報流れを示す図である。
【図９】装置がサービスへのアクセスを許可するかどうかを決定するために、コントローラによって実行される裁定プロセスを示すフローチャートである。
【図１０】装置がサービスへのアクセスを許可するかどうかを決定するために、コントローラによって実行される裁定プロセスを示すフローチャートである。
【図１１】装置がサービスへのアクセスを許可するかどうかを決定するために、コントローラによって実行される裁定プロセスを示すフローチャートである。
【特許請求の範囲】
【請求項１】
他の装置と通信して前記他の装置にアプリケーションへのアクセスを許可する装置であって、
少なくとも第１のアプリケーションと、
通信装置を認証する認証手段と、
前記第１のアプリケーションへのアクセスを要求する、前記認証手段に認証されたことがない通信装置でアクセス可能なアクセス制御手段とを含み、
前記アクセス制御手段は、前記通信装置の前記第１のアプリケーションへのアクセスを許可するか拒否するかを裁定するように構成され、前記裁定が前記通信装置の認証を必要とする場合に、前記アクセス制御手段が、前記通信装置を認証するように前記認証手段に対して命令することを特徴とする装置。
【請求項１】
他の装置と通信して前記他の装置にアプリケーションへのアクセスを許可する装置であって、
少なくとも第１のアプリケーションと、
通信装置を認証する認証手段と、
前記第１のアプリケーションへのアクセスを要求する、前記認証手段に認証されたことがない通信装置でアクセス可能なアクセス制御手段とを含み、
前記アクセス制御手段は、前記通信装置の前記第１のアプリケーションへのアクセスを許可するか拒否するかを裁定するように構成され、前記裁定が前記通信装置の認証を必要とする場合に、前記アクセス制御手段が、前記通信装置を認証するように前記認証手段に対して命令することを特徴とする装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１１−９７５９４（Ｐ２０１１−９７５９４Ａ）
【公開日】平成２３年５月１２日（２０１１．５．１２）
【国際特許分類】
【出願番号】特願２０１０−２４８３０４（Ｐ２０１０−２４８３０４）
【出願日】平成２２年１１月５日（２０１０．１１．５）
【分割の表示】特願２００１−５０２２７５（Ｐ２００１−５０２２７５）の分割
【原出願日】平成１２年６月５日（２０００．６．５）
【出願人】（３９８０１２６１６）ノキア コーポレイション (1,359)
【Ｆターム（参考）】
【公開日】平成２３年５月１２日（２０１１．５．１２）
【国際特許分類】
【出願日】平成２２年１１月５日（２０１０．１１．５）
【分割の表示】特願２００１−５０２２７５（Ｐ２００１−５０２２７５）の分割
【原出願日】平成１２年６月５日（２０００．６．５）
【出願人】（３９８０１２６１６）ノキア コーポレイション (1,359)
【Ｆターム（参考）】
[ Back to top ]