JP2015534408A - 端末とリモートサーバとの間の、サードパーティのポータルを介した相互認証の方法 - Google Patents

Abstract

本発明は、(i)サービスに登録するためのアプリケーション(12)と共に保全素子(11)と連携するユーザ端末(10)と、(ii)サービスの提供に適したリモートサーバ(13)との間の、サードパーティのポータル(14)を介した相互認証の方法に関する。本発明によると、本方法は、i)ユーザ端末(10)のユーザの認証をポータル(14)に対して行った後、ポータル(14)を介して、リモートサーバ(13)における保全素子(11)の認証を可能にする署名済み情報Ｒを、サービス要求と共にリモートサーバ(13)へ送信し、ii)リモートサーバ(13)において保全素子(11)を認証し、保全素子(11)が認識された場合は、iii)リモートサーバ(13)によって署名された値Ｒ′を、ポータル(14)を介してリモートサーバ(13)からアプリケーション(12)へ送信し、ここにおいて値Ｒ′は、サービス要求への応答を可能にするＵＲＬアドレスと共に情報を含み、iv)署名済みの値Ｒ′の検証要求を、アプリケーション(12)から保全素子(11)へ送信し、v)保全素子(11)において、リモートサーバ(13)の署名、及び要求したサービスがリモートサーバ(13)によって承認されたか否かを検証し、vi)保全素子(11)を用いてリモートサーバ(13)とのセキュア接続を確立し、サービスの実行を要求することからなる。【選択図】 図１

Description

本発明は電気通信の分野に係り、端末とリモートサーバとの間の、サードパーティのポータルを介した相互認証の方法に関する。

端末は、一般的に、携帯電話、ＰＤＡ又はスマートフォン等のユーザ端末である。端末は通常、一般的にＵＩＣＣと呼ばれるＳＩＭ又はＵＳＩＭカード等の保全素子を含む。保全素子は、ｅ−ＵＩＣＣ（「ｅｍｂｅｄｄｅｄ ＵＩＣＣ（埋設型ＵＩＣＣ）」、即ちユーザ端末に一体化され（例えばこの端末内に溶接される）、ＵＩＣＣとして用いられるチップ）であってもよい。保全素子は、端末のユーザが主としてセルラ電気通信ネットワークに対して認証を行い、通信（音声、データ…）を確立することを可能にするエレメント（キー、ディレクトリ、ソフトウェア、ファイル…）を含む。このタイプの保全素子はＥＴＳＩ規格に準拠している。

保全素子は、端末内に格納されずに、端末と無線によって通信を行ってもよい。特定の実施形態において、保全素子は、例えば端末のユーザが携帯するデバイスに一体化され、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＷｉＦｉ又はＩＥＥＥ ８０２．１５．４規格に基づく技術を介して端末と通信を行ってもよい。従って、ＵＩＣＣカードを有さず、数十センチから数メートル又は数十メートル離れた場所に位置するこれらのカード（又はｅ−ＵＩＣＣ）と通信を行う端末は、ＵＩＣＣカードを含む従来の携帯端末システムに対する代替となる。例えば、非特許文献１及び特許文献１に記載のｅＧｏシステムを参照されたい。

このように、本発明の範囲において、ユーザ端末はＵＩＣＣ又はｅ−ＵＩＣＣ等の保全素子と連携する。
ユーザ端末又はＵＩＣＣは、サービスへ登録するためのアプリケーションを含む。「サービスへ登録するためのアプリケーション」とは、リモートサーバからのサービスを要求可能にするアプリケーションを意味する。リモートサーバは、一般的にＯＴＡプラットフォームである。サービスは、例えば銀行取引アプリケーションのダウンロードであってよい。また、日刊電子新聞等のサービスの定期購読であってもよい。

特定の実施形態において、サービスは、セルラネットワークの加入者情報の有効化、又はこのような加入者情報の成立を可能にするキー、ディレクトリ、ソフトウェア及びファイルのダウンロードであってよい。後者のケースは、いわゆるＳＭ（Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｍａｎａｇｅｒ（加入者情報管理））サーバが提供する、加入者情報の遠隔カスタマイズに相当する。サービスは、同一の通信事業者又は別の通信事業者が管理する他のセルラネットワークの加入者情報への変更を要求することであってもよい。

ＳＭサーバは、例えば電気通信ネットワークを介したユーザの認証を可能にするエレメントを保全素子内にダウンロードするために、保全素子を（ＯＴＡによって）遠隔でカスタマイズできるようにするサーバである。当該サーバは、完全な加入者情報をＵＩＣＣにダウンロードすることから構成されてもよく、ＵＩＣＣは例えば一時識別子を用いてサーバに登録する。

本発明の範囲において、図１に示すように、ユーザ端末はサードパーティのポータルを介してリモートサーバと通信を行う。
ユーザ端末１０は保全素子１１（一体型又は遠隔のＵＩＣＣ又はｅ−ＵＩＣＣ）と連携し、サービスに登録するためのアプリケーション１２を含む。端末１０は、例えば無線周波数によって、サードパーティのポータル１４を介してリモートサーバ１３と通信を行う。リモートサーバ１３は、例えば端末１０によって要求されるサービスの提供に適したＯＴＡプラットフォームである。

ポータル１４は、例えば端末１０の状態（ダウンロードしたソフトウェアのタイプ及びバージョン、アクティブ又は非アクティブ状態、・・・）を知る必要のある、端末１０の販売者の内の一つである。アプリケーション１２は、サーバ１３と直接通信を行うことはできず、それ故このサードパーティのポータル１４を使用する必要がある。
別の実施形態において、例えばセルラネットワークへの加入者情報をダウンロードするために、端末１０のユーザはポータル１４との通信を開始する。このような通信の開始は、端末１０のマン・マシン・インターフェースを介して、例えばドロップダウンメニュー内の機能を起動することにより行われる。ポータル１４との通信は、端末１０の最初の電源投入後にアプリケーション１２を介して確立されてもよい。

図１において、第一のステップ２０は、ポータル１４に対して端末１０の認証を行うことからなる。ｈｔｔｐｓタイプのセキュア（安全）な接続が確立される。ステップ２１において、アプリケーション１２は、保全素子１１の識別子、例えば保全素子を一意的に特定するシリアル番号を付帯したサービス要求をポータル１４へ送信する。そして、このような識別子は、その特定するものがＵＩＣＣであろうとｅＵＩＣＣであろうと、一般的にｅＵＩＣＣｉｄと呼ばれると考えられる。

ステップ２２において、ポータルは、サービス要求及び保全素子１１の識別子をリモートサーバ１３へ再送する。次にリモートサーバ１３は、ステップ２３において、要求されたサービスへの保全素子１１のアクセス権を検証する。このような確認は、ｅＵＩＣＣｉｄがサーバ１３により認識されたか否か、及び当該ｅＵＩＣＣがこのサービスを要求する権利を有しているか否かを検証することから構成される。
サービスへの権利が承認されると、例えば共有鍵（“ＴＬＳ−ＰＳＫ ハンドシェイク”）に基づくセキュア通信を保全素子１１が開始するために、サーバ１３は保全素子１１へ直接アドレスする（ステップ２４）。これにより、保全素子１１とサーバ１３との間でセキュア通信が確立する。

次に保全素子１１は、要求したサービスと共に、ＴＬＳ−ＰＳＫを含むＨＴＴＰ ＰＯＳＴタイプの要求をサーバ１３へ送信する（ステップ２６）。その後、残りのプロセスは従来通りである（保全素子へのサービスの供給、要求されたサービスが受信されたことの確認、セキュア通信の終了、保全素子が要求したサービスを受信したことのサーバ１３への記録）。

図２は、ユーザ端末とリモートポータルとの間で通信を確立するための、可能な代替解決法を示す。
この代替解決法において、参照番号１５が付されたユーザは、端末１０及びコンピュータ等の電気通信端末１６を有する。コンピュータ１６は、例えばインターネットを介してポータル１４に接続することができる。コンピュータ１６は、図１に示される様な、サービスへ登録するためのアプリケーション１２を含む。

ここにおいてユーザは、ｅＵＩＣＣの識別子（ｅＵＩＣＣｉｄ）又は端末１０の梱包箱に記載されたコードをポータル１４へ送信することに関与する。このような識別子は、端末１０に記載されているか、カードである保全素子（ＵＩＣＣ）に印刷されていてもよい。コンピュータ１６内に存在するアプリケーション１２又はユーザ１５が認証を行った後（ステップ２０）、ユーザ１５は、電気通信端末１６のマン・マシン・インターフェースを介して、ＵＩＣＣ又はｅＵＩＣＣの一意識別子を入力し、電気通信端末１６はこれをポータル１４へ送信する（ステップ２１）。識別子には、保全素子によるサービス要求が付帯する。その後のステップ２２から２６は、図１と同様である。

欧州特許第１６９５２９６号明細書

ウェブサイトhttp://www.ego-project.eu

サービスへのアクセスに関するこれらの二つの方法において生じる課題は、安全性の問題である。実際のところ、様々な攻撃が可能である：ＵＩＣＣは端末から取り外しが可能なため（ＵＩＣＣが例えばＳＩＭカード又はＳＤカードの場合）、リモートサーバ１３は、サービスを要求している人物がＵＩＣＣの所有者であると確信することができない。
ハッカーがサードパーティのポータル１４を乗っ取り、いずれかのＵＩＣＣ又はｅＵＩＣＣ上で実行されるサービスを要求する可能性もある。その結果、エンドユーザに対する不当請求又はサービス妨害が生じる（例えばＳＭの場合、要求されるサービスは加入者情報の取り消しであってもよい）。

最終的に、ハッカーが何らかのサービス要求を傍受し、当該サービス要求を再実行する可能性がある。これは、ユーザが同一のサービスの新たな実行要求を行った際に、サーバ１３においてサービス妨害を生じさせる。
本発明は、セキュリティ面において脆弱性を有する可能性のあるサードパーティのポータルにおけるセキュリティの強化、並びに、リモートサーバ１３及びユーザが信頼可能なシステムの提供を目的とする。

当該目的及び後述の他の目的は、一方ではサービスに登録するためのアプリケーションと共に保全素子と連携するユーザ端末と、他方では要求されるサービスの提供に適したリモートサーバとの間の、サードパーティのポータルを介した相互認証の方法によって達成される。

本発明によると、本方法は、
ｉ−ユーザ端末のユーザの認証をポータルに対して行った後、ポータルを介して、リモートサーバにおける保全素子の認証を可能にする署名済みの情報Ｒを、サービス要求と共にリモートサーバへ送信し、
ｉｉ−リモートサーバにおいて保全素子を認証し、保全素子が認識された場合は、
ｉｉｉ−リモートサーバによって署名された署名済みの値Ｒ′を、ポータルを介してリモートサーバからアプリケーションへ送信し、ここにおいて値Ｒ′は、サービス要求への応答を可能にするＵＲＬアドレスと共に情報を含み、
ｉｖ−署名済みの値Ｒ′の検証要求を、アプリケーションから保全素子へ送信し、
ｖ−保全素子において、リモートサーバの署名、及び要求したサービスがリモートサーバによって承認されたか否かを検証し、
ｖｉ−リモートサーバとのセキュア接続を保全素子から確立し、サービスの実行を要求することからなる。

有利には、情報は、保全素子の識別子を含む。
情報は、好ましくはアンチリプレイ値に連結される。
有利には、情報は、ランダム値に連結される。
情報は、好ましくはｍａｃにより署名される。
第一の実施形態において、
ステップ−ｉ−は、保全素子によって生成された署名済みの情報Ｒを、ユーザ端末を介して送信することからなり、
ステップ−ｉｉｉ−は、署名済みの値Ｒ′を、ポータルからアプリケーションへ直接送信することからなる。

第二の実施形態において、
ステップ−ｉ−は、署名済みの情報を、ポータルを介して電気通信端末からリモートサーバへ送信することからなり、
ステップ−ｉｉｉ−は、ポータルから電気通信端末へ署名済みの値Ｒ′を送信し、電気通信端末のユーザに対して、受信した署名済みの値Ｒ′を、ユーザ端末のマン・マシン・インターフェースを介してユーザ端末に入力するよう促すことからなり、ここにおいて署名済みの値Ｒ′はアプリケーションへ送信される。
本発明のその他の特徴及び利点は、例示的かつ非限定的な目的で提示された、本発明の二つの実施形態に関する以降の記述、及び添付の図面から明らかとなるであろう。

保全素子と連携する端末がサービス要求を開始する、サービスを要求するためのシステムを示す図。 ユーザがコンピュータ等の電気通信端末を使用してサービス要求を開始する、サービスを要求するためのシステムを示す図。 本発明の第一の実施形態に係る、サービスを要求するためのシステムを示す図。 本発明の第二の実施形態に係る、サービスを要求するためのシステムを示す図。

図１及び２については先に述べた。
図３は、本発明の第一の実施形態に係る、サービスを要求するためのシステムを示す。
図３のシステムでは、保全素子１１と連携する端末１０がサービス要求を開始する。端末１０又は保全素子１１は、サードパーティのポータル１４を介してリモートサーバ１３により提供されてもよいサービスへ登録するための、アプリケーション１２を含む。

アプリケーションが保全素子１１にインストールされている場合、又は保全素子がｅＵＩＣＣである場合には任意である第一のステップ３０において、アプリケーション１２は保全素子１１によって認証される。これは、アプリケーション１２による保全素子１１へのアクセスを当該保全素子１１によって制御することが望まれる場合にも適切なステップである。このようなアプリケーションの認証は、例えば事前に自身のＰＩＮコードを端末へ入力するユーザの認証に相当する。アプリケーション１２は、例えばＪＳＲ１７７仕様に準拠したＪａｖａ（登録商標） ｍｉｄｌｅｔ、又は保全素子１１内にインストールされたＳＣＷＳ（Ｓｍａｒｔ Ｃａｒｄ Ｗｅｂ Ｓｅｒｖｅｒ（スマートカードウェブサーバ））を操作する簡易なブラウザであってよい。アプリケーション１２の認証後、保全素子１１はステップ３２において、サーバ１３からサービスを要求する権限を返送する。この権限には、サーバ１３における保全素子１１の認証を可能にする署名済みの情報Ｒが付加される。

一実施形態において、このような情報は、ＵＩＣＣｉｄ又はｅＵＩＣＣｉｄ（シリアル番号）等の保全素子１１の識別子であり、署名は識別子のｍａｃである。従って以下を有する：
R=eUICCid II mac (1)
ｍａｃは、保全素子のｅＵＩＣＣｉｄから算出された鍵K_euiccidから算出される。
情報は、従来の方式である対称又は非対称暗号化に基づいて署名されてもよい。
保全素子がリモートサーバ１３による同一のサービスを二度要求しないようにするため、そして署名を行うために、アンチリプレイ値ＡＲが識別子に連結されてもよい。その場合、好ましくは以下を有する：
R=[eUICCid, AR] II mac (2)

好ましい解決法は、ランダム値ＶＡを識別子及びＡＲに連結させ、さらに署名を行うことである。例えば以下の通りとなる：
R=[eUICCid, AR, VA] II mac (3)
保全素子１１により生成されたランダム値ＶＡを付加することで、両サービス要求においてＡＲ値が同一であっても暗号を変更することが可能となる。これは、アンチリプレイ値ＡＲのカウンタがリセットされた場合に生じる可能性がある。従ってＶＡを用いることにより、同一の配列（二つの異なる時点における、二つの同一の値Ｒの生成）が決して二度繰り返されないことを確認することが可能となる。

ステップ３０と同時に、図１（ステップ２０）に関連して前述したように、アプリケーション１２はポータル１４に対して認証を行う（ステップ３１）。
ステップ３２の後、値Ｒはアプリケーション１２へ送信され、このアプリケーション１２によってサービス要求と共にポータル１４へ送信される（ステップ３３）。ポータル１４はデータ（Ｒ及びサービス要求）をサーバ１３へ再送し（ステップ３４）、サーバ１３は具体的には以下の確認を行う（ステップ３５）：
−（任意）ポータル１４の認証；
−保全素子の識別情報：ｅＵＩＣＣｉｄ又はＵＩＣＣｉｄ、その署名（ｍａｃ）、アンチリプレイ値ＡＲ及びランダム値ＶＡにより、保全素子１１のみが値Ｒを生成したと推定されることが保証される；
−要求Ｒによって実現されるサービスが、既に前もって提供されていないこと（値ＶＡ）。

サーバ１３は、秘密鍵のスキーマに従って、又はＰＫＩで作動してもよい。いずれの場合にも、サーバ１３は、自己のためにサービスを要求することを許可された保全素子のｅＵＩＣＣｉｄ（ＵＩＣＣｉｄ）及びそれに関連した秘密鍵K_euiccidを識別する。ＭＡＣはこれらの秘密鍵から生成される。ＭＡＣの認識は、それを生成したｅＵＩＣＣがサーバ１３において保存されたことを意味する。
ＭＡＣは、単純なハッシュ関数が可能とするような、受信したデータの完全性検証の機能を提供するだけではなく、追加的に送信者、即ち秘密鍵の所有者を認証する。

このような確認が完了すると、サーバ１３は、要求されたサービスと共に受信した情報Ｒを含む署名済みの値Ｒ′を返送する（ステップ３６）。このサービスは、例えば前記要求への応答を可能にするＵＲＬアドレスである。
好ましくは、以下を有する：
R'=[eUICCid, AR, VA, URL, R] II mac
ここにおいて、今回、ｍａｃはサーバの署名であり、ＡＲは保全素子１１から受信したアンチリプレイ値である。Ｒの返送（任意）によって、保全素子１１におけるダブルチェックの実行が可能となり、当該ダブルチェックは、送信したＲが受信したものと同一であるかを検証することにより行われる。

値Ｒ′はポータル１４へ送信され、ポータル１４はこれをアプリケーション１２へ返送する（ステップ３７）。次にアプリケーション１２は、保全素子１１に対し、要求したサービスの開始を要求してもよい（ステップ３８）。保全素子１１はステップ３９において、受信した値Ｒ′を介して以下の点の確認を行う：
−サービスが正しいサーバ１３から要求されたこと（ｍａｃ署名の検証）；
−受信したＲが送信したものと同一であること（任意のステップ）；
−サーバ１３がサービスの実行を承認したこと（例えば、ＵＲＬアドレスの存在）。
次にステップ４０において、保全素子１１はサーバ１３とのセキュアな接続を確立し（ＴＬＳ−ＰＳＫ ハンドシェイク）、サーバ１３からの応答Ｒ′に含まれるＵＲＬアドレスを介して、サービスの実行を要求する（ＨＴＴＰ ＰＯＳＴ／サービスＲ′）（ステップ４１）。最後のステップ４２において、サーバ１３は、要求されたサービスを実行するために、Ｒ′の値を確認して保全素子１１が正しく接続されたことを確かめることができる。

図４は、本発明の第二の実施形態に係る、サービスを要求するためのシステムを示す。
この第二の実施形態では、図２の実施形態と同様に、ユーザは本方法の第一のステップにおいて、自身の端末１０にアクセスすることができない、又は、アプリケーション１２はサードパーティのポータル１４にアクセスすることができない。ステップ３１から３７を実行する間、ユーザは例えば端末の小売店の内の一つにいる。
コンピュータ等の電気通信端末１６を用いて、エンドユーザ又は端末１０を販売する者は、ポータル１４に対し認証を行う（ステップ３１）。次に、保全素子１１の識別情報をサービス要求と共にポータル１４へ送信する（ステップ３３）。前述の通り、このような識別情報は、上記の方程式１乃至３において述べられた３つの署名済みの情報の内の一つであってよい。

このような署名済みの情報及びサービス要求は、ポータル１４からサーバ１３へ送信され（ステップ３４）、サーバ１３は、図３を参照して説明されたものと同一の確認を実行する（ステップ３５）。サーバ１３は、値Ｒ′をポータル１４へ返送することにより応答し（ステップ３６）、ポータル１４はこれを電気通信端末１６へ再送する（ステップ３７）。次に値Ｒ′は、端末１６の画面に表示される。

ステップ５０は、後で、例えばユーザの家で実行されてもよい。このステップは、アプリケーション１２を起動することからなる。次にアプリケーション１２は保全素子１１に対し認証を行い（ステップ５１）、その後ユーザの端末へＲ′を手動で入力することが必要となる（ステップ５２：端末のマン・マシン・インターフェースを用いた、ユーザの端末１０へのＲ′の入力）。Ｒ′の値はアプリケーション１２によって復元され、次に保全素子１１はＲ′の値を確認する（ステップ３９）よう要求される（ステップ３８）。ステップ４０乃至４２は、図３を参照して説明されたものと同一である。
ステップ５２は、認証ステップ５１の前に行われてもよい。同様に、ステップ５２は、端末１０を用いて受信したＲ′をスキャンすることから構成されてもよい。Ｒ′はＱＲコード（登録商標）であってもよい。

このような第二の実施形態において、Ｒの値（例えば英数字コード）は、端末１０の梱包（箱）の内部（サービス妨害の問題を防ぐため、外側ではない）に含まれていてもよい。
端末１０は、単純な携帯電話、又は機械に一体化されたモデム、例えば自動車であってもよい。本発明は、より詳細にはＭ２Ｍ通信、即ち機械間の通信に適用可能である。
本発明により、サードパーティのポータル１４がサーバ１３に対して自己の認証のみを行う、図１及び２に関連して説明された解決策とは異なった、保全素子１１とサーバ１３との間の相互認証を得ることが可能となる。

Claims (7)

1. 一方ではサービスに登録するためのアプリケーション（１２）と共に保全素子（１１）と連携するユーザ端末（１０）と、他方では前記サービスの提供に適したリモートサーバ（１３）との間の、サードパーティのポータル（１４）を介した相互認証の方法であって、前記方法は、
   ｉ−前記ユーザ端末（１０）のユーザの認証を前記ポータル（１４）に対して行った後、前記ポータル（１４）を介して、前記リモートサーバ（１３）における前記保全素子（１１）の認証を可能にする署名済みの情報Ｒを、サービス要求と共に前記リモートサーバ（１３）へ送信し、
   ｉｉ−前記リモートサーバ（１３）において前記保全素子（１１）を認証し、前記保全素子（１１）が認識された場合は、
   ｉｉｉ−前記リモートサーバ（１３）によって署名された署名済みの値Ｒ′を、前記ポータル（１４）を介して前記リモートサーバ（１３）から前記アプリケーション（１２）へ送信し、ここにおいて前記値Ｒ′は、前記サービス要求への応答を可能にするＵＲＬアドレスと共に前記情報を含み、
   ｉｖ−前記署名済みの値Ｒ′の検証要求を、前記アプリケーション（１２）から前記保全素子（１１）へ送信し、
   ｖ−前記保全素子（１１）において、前記リモートサーバ（１３）の署名、及び要求したサービスが前記リモートサーバ（１３）によって承認されたか否かを検証し、
   ｖｉ−前記リモートサーバ（１３）とのセキュア接続を前記保全素子（１１）から確立し、前記サービスの実行を要求することからなる方法。
2. 前記情報は、前記保全素子（１１）の識別子を含むことを特徴とする、請求項１に記載の方法。
3. 前記情報は、アンチリプレイ値に連結されることを特徴とする、請求項１又は２に記載の方法。
4. 前記情報は、ランダム値に連結されることを特徴とする、請求項１乃至３のいずれか一項に記載の方法。
5. 前記情報は、ｍａｃにより署名されることを特徴とする、請求項１乃至４のいずれか一項に記載の方法。
6. ステップ−ｉ−は、前記保全素子（１１）によって生成された前記署名済みの情報Ｒを、前記ユーザ端末（１０）を介して送信することからなり、
   ステップ−ｉｉｉ−は、前記署名済みの値Ｒ′を、前記ポータル（１４）から前記アプリケーション（１２）へ直接送信することからなることを特徴とする、請求項１に記載の方法。
7. ステップ−ｉ−は、前記署名済みの情報Ｒを、前記ポータル（１４）を介して電気通信端末（１６）から前記リモートサーバ（１３）へ送信することからなり、
   ステップ−ｉｉｉ−は、前記ポータル（１４）から前記電気通信端末（１６）へ前記署名済みの値Ｒ′を送信し、前記電気通信端末（１６）のユーザに対して、受信した前記署名済みの値Ｒ′を、前記ユーザ端末（１０）のマン・マシン・インターフェースを介して前記ユーザ端末（１０）に入力するよう促すことからなり、ここにおいて前記署名済みの値Ｒ′は前記アプリケーション（１２）へ送信されることを特徴とする、請求項１に記載の方法。

Images