JP6920359B2

JP6920359B2 - セキュリティエレメントを更新する方法、対応するｏｔａプラットフォーム及びセキュリティエレメント

Info

Publication number: JP6920359B2
Application number: JP2018568270A
Authority: JP
Inventors: サラシリル，ソレ; ヴァラジョルジュ，コルテス
Original assignee: ジェムアルトエスアー
Priority date: 2016-06-28
Filing date: 2017-06-21
Publication date: 2021-08-18
Anticipated expiration: 2037-06-21
Also published as: EP3476145B1; EP3476145A1; KR20190021399A; JP2019520002A; US20190155595A1; WO2018001835A1; EP3264812A1

Description

本発明は、電気通信の分野に係り、より具体的には、例えば電話機、スマートフォン、ＰＤＡやコンピュータなどの端末、携帯端末と相互作用するＵＩＣＣ（汎用集積回路カード）などのセキュリティエレメントのリモート管理の分野に関する。セキュリティエレメントは、Ｍ２Ｍ（マシンツーマシン）の領域におけるようなマシン内の集積回路の形をとってもよい。セキュリティエレメントは、必ずしも物理的に端末に接続されているわけではないが、セキュリティエレメントが遠隔で短距離チャネルを介して端末と通信する短距離リンク（例えばＢｌｕｅｔｏｏｔｈ（登録商標）又はＷｉｆｉ）を介して端末と通信することができる。

このようなセキュリティエレメントの管理は、一般的にセキュリティエレメントにおいてデータ又はプログラムを更新又はインストールするためにＯＴＡ（無線）で行われる。この種の管理は、ｈｔｔｐプロトコル（ハイパーテキスト転送プロトコル）又はＳＭＳ（ショートメッセージサービス）を使用することができる。

セキュリティエレメントを管理する２つの方法がある。

第１の方法は、例えば更新キャンペーン中にデータ又はプログラムをＯＴＡプラットフォームから目標のセキュリティエレメントに送信することを含む。この種の管理は「プッシュ（ｐｕｓｈ）」として知られており、ＳＭＳモードでの伝送に基づいている。この方法に関する問題は、ＳＭＳをサポートしていない（これは完全にｈｔｔｐである）純粋なＬＴＥネットワークなどの新世代ネットワークに適合しないことである。さらに、ＳＭＳなどの信頼性が低いプロトコルを回避するために、ｈｔｔｐによるＲＡＭ又はＲＦＭタイプ管理が開発されている。

第２の方法は、利用できる更新があるかどうかを調べるために、例えば、定期的に又はイベントの発生時にＯＴＡプラットフォームに問い合わせを行うことを含む。この問い合わせはセキュリティエレメントによって開始され、“ポーリング（polling）”又は“プル（pull）”と呼ばれている（セキュリティエレメントはＯＴＡプラットフォームが送信すべきものを持っているかどうかを確認する）。問い合わせはｈｔｔｐプロトコルを介して行われる。

図１は、この原理に基づいてセキュリティエレメントを管理するためのシステムを示している。

この図において、セキュリティエレメント１０はＯＴＡプラットフォーム１１又はサーバによって管理される。

セキュリティエレメント１０は、図示されていない電気通信端末と相互作用する。

プロセスは、セキュリティエレメント１０の主導でＯＴＡプラットフォーム１１に問い合わせを行い、ＯＴＡプラットフォーム１１がセキュリティエレメント１０に送信すべきデータ又はプログラムを有しているかどうかを調べる段階１２から始まる。図示されている全てのやりとりは、ＳＣＰ８１プロトコルに従って実行される。

段階１３において、サーバ１１は、セキュリティエレメント１０の要求を受信した旨の応答をセキュリティエレメント１０に対して行い、段階１４においてこの受信を確認する。

段階１５において、セキュリティエレメント１０はサーバ１１にＰＳＫＩＤを送信する。ＰＳＫＩＤは、セキュリティエレメント１０とサーバ１１の間で共有され、アイデンティティ（ＩＤ）と関連付けられたあらかじめ設定された鍵（ＰＳＫ）を指す。このＰＳＫ鍵によって、サーバ１１はセキュリティエレメント１０を識別する。

有利には、アドレスｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ４２７９で入手可能なＩＥＴＦ勧告を参照すべきである。

段階１６において、セキュリティエレメント１０は暗号スイート、例えばＡＥＳ１２８や３ＤＥＳスイートを選択する。

サーバ１１は、段階１７において、提案された暗号スイートを受け入れた後、段階１８において、セキュリティエレメント１０とのハンドシェイクチャネルの確立を終了させる。

その後段階１９は、このようにして確立されたセキュアなＴＬＳ−ＰＳＫチャネルでデータ交換を行うことを含む。特に、この段階１９において、セキュリティエレメント１０は、要求理由（単純なデータ更新、最初の使用の場合のセキュリティエレメント１０のアクティブ化）に対応するＵＲＬをサーバ１１に送信する。

この解決策に関する問題は、一般にセキュリティエレメント１０が、ＯＴＡプラットフォーム１１に問い合わせするためのイベントの発生を待たないことである。したがって、「ポーリング」は定期的、例えば１５日毎又は月毎に行われ、ほとんどの時間、ＯＴＡプラットフォーム１１はセキュリティエレメント１０に対して送信すべきものを持っていない。例えば、出願人は、この分野でセキュリティエレメント１０によるＯＴＡプラットフォーム１１への問い合わせの９０％で、更新やプログラム又はデータがセキュリティエレメント１０に送信されることはないということに気付いた。これは、不必要な無線トラフィックとＯＴＡプラットフォームの過負荷とをもたらす（セキュリティエレメントの問い合わせ毎にＴＬＳ−ＰＳＫリンクがセキュリティエレメントとＯＴＡプラットフォームの間に確立される）。したがって、通例、２０で参照される段階１２から１８は、大抵の場合不必要である。

別の問題は、ＯＴＡプラットフォーム１１が、全てが同じ緊急度を有するわけではない様々なタスクに常に使用されていることである。例えば、加入者が自身のＰＬＭＮ（公衆陸上移動体ネットワーク−セキュリティエレメント１０がローミングの際に接続するのが好ましい外国のネットワークのリスト）を更新するより、素早く呼び出しする（例えば自身の連絡帳をダウンロードする又は完全なサブスクリプションをダウンロードする）ことができるように、セキュリティエレメント１０を（加入者が初めて端末に挿入したときに）初期化することが重要である。

したがって、緊急の要求とそうでないものの処理に区別がない。この場合、他のセキュリティエレメントからの緊急性が低い他の要求に圧倒される場合に、緊急に更新する必要があるセキュリティエレメント１０からの接続要求をＯＴＡサーバ１１に拒否させる可能性がある。

また、データセンター（例えば移動体オペレータがともにそのサービスを位置付けるセキュリティエレメント製造業者のデータセンター）の内部ネットワークがセキュリティエレメントの更新に関与する場合、このネットワークにも不要な負担がかかることになる。さらに、このネットワークが物理的に分散されたサーバを使用する場合、追加の通信が付加されることになる。

第２の動作方法のこの欠点を克服するために、２つの解決策が可能である：
−２つのＯＴＡプラットフォームの問い合わせ（「ポーリング」）間の期間を延長すること。（セキュリティエレメントのアプリケーションを更新してこの期間を延長する）。この欠点は、更新が前回の問い合わせの直後に利用可能となった場合に、セキュリティエレメントがずっと後になってようやく更新されることである。
−“プッシュ”モードに切替えること。この場合、前述の問題に再び直面する。

より詳細には、本発明はこれらの欠点を克服することを目的とする。

より具体的には、本発明は、特に電気通信端末と相互作用するセキュリティエレメントを更新する方法であって、更新がセキュリティエレメントの要求に基づいてＯＴＡプラットフォームによって実行され、セキュリティエレメントがＰＳＫＩＤをＯＴＡプラットフォームに送信し、プロセスが、ＯＴＡプラットフォームにより要求が考慮されることを要求する優先順位を規定するアイデンティティ（ＩＤ）をセキュリティエレメントからＯＴＡプラットフォームに送信することを含む方法に関する。

好ましい実施形態において、この方法は、ＰＳＫＩＤをプロキシサーバを介してＯＴＡプラットフォームに送信することを含む。

有利には、プロキシサーバは、アイデンティティ（ＩＤ）がプロキシサーバに格納されている値より高い優先順位を有する場合に、ＯＴＡプラットフォームに転送する前にアイデンティティ（ＩＤ）に基づいて要求をフィルタリングする。

好ましくは、アイデンティティ（ＩＤ）は、ＩＤを追加及び削除するだけでなく優先順位を変更するために、ＯＴＡで変更されてよい。

本発明はまた、電気通信端末と相互作用するセキュリティエレメントであって、セキュリティエレメントが、セキュリティエレメントとリモートプラットフォームの間にセキュアチャネルを確立するためにＰＳＫＩＤをリモートプラットフォームに送信するように構成され、アイデンティティ（ＩＤ）が、リモートプラットフォームによって要求が考慮されることを要求する優先順位を規定するセキュリティエレメントに関する。

有利な実施形態において、リモートプラットフォームはＯＴＡプラットフォームである。

別の実施形態において、リモートプラットフォームはセキュリティエレメントとＯＴＡプラットフォームの間に配置されたプロキシである。

本発明はまた、端末と相互作用するセキュリティエレメントを管理するように設計されたＯＴＡプラットフォームであって、セキュリティエレメントが更新要求をＯＴＡプラットフォームに送信し、ＯＴＡプラットフォームがセキュリティエレメントを管理する手段を備え、プラットフォームが要求をフィルタリングする手段を備え、要求がＰＳＫＩＤを含み、ＰＳＫＩＤのアイデンティティ（ＩＤ）が、ＯＴＡプラットフォームによって要求が考慮されることを要求する優先順位を規定し、フィルタリングする手段が、管理する手段が要求を発したセキュリティエレメントを管理できるように、ＰＳＫＩＤのアイデンティティ（ＩＤ）が基準値未満の要求のみを、セキュリティエレメントを管理する手段に送信するＯＴＡプラットフォームに関する。

本発明の他の特徴及び利点は、非制限的な例として与えられ、添付の図面を参照する２つの好ましい実施形態の以下の説明を読めば明らかになるだろう。

技術水準を示す図。本発明の第１の実施形態を示す図。本発明の第２の実施形態を示す図。セキュリティエレメントの管理要求が拒否された場合に本発明がどのように機能するかを示す図。本発明に係るＯＴＡプラットフォームを示す図。

図１は技術水準を参照して以上で説明された。図２は本発明の第１の実施形態を示す。

この第１の実施形態では、セキュリティエレメント３０がプロキシサーバ３２を介してＯＴＡプラットフォーム３１に問い合わせを行い、ＯＴＡプラットフォームにセキュリティエレメントに送信すべきデータがあるかどうかを尋ねる。ここでいう「データ」という用語は広い意味で用いられ、プログラム、サブスクリプションデータ（セキュリティドメインを含む新しいサブスクリプションのためのＩＭＳＩ／Ｋｉ及び対応する鍵）の送信、又はデータやプログラムの単純な更新を含む場合がある。

段階３３から３６は、図１の段階１２から１５と同様である。すなわち
−セキュリティエレメント３０はプロキシサーバ３２に接触し（段階３３）；
−プロキシサーバ３２は応答し（段階３４）；
−プロキシサーバ３２は応答を確認し（段階３５）；
−セキュリティエレメント３０はＰＳＫＩＤをプロキシサーバ３２に送信する（段階３６）。

段階３６の特徴は、セキュリティエレメント３０とＯＴＡプラットフォーム３１との間で共有されるＰＳＫ鍵のアイデンティティ（ＩＤ）が、上記ＯＴＡプラットフォーム３１によってその要求が考慮されることを要求する優先順位を規定することである。

セキュリティエレメントの各ＰＳＫ鍵に対して、各々が優先順位に対応するいくつかのＩＤが提供される。

一例として、セキュリティエレメントのＰＳＫ鍵が１２３４５である場合、複数のアイデンティティがこの同じ鍵に割り当てられる。したがって、例えば下記のＰＳＫＩＤが得られる：
− １２３４５−１
− １２３４５−２
− １２３４５−３
− １２３４５−Ｎ

ここで、１は最も優先度が高いＩＤであり、Ｎは最も優先度が低いＩＤである。優先度は、ＯＴＡプラットフォーム３１にセキュリティエレメント３０が発した要求をより大きい順位のＩＤに優先して処理するように要求するアイデンティティ（ＩＤ）を意味する。

優先順位が第１位のアイデンティティ（ＩＤ）は、例えばサブスクリプションメンバーシップのためのオペレータパラメータを用いて初期化せよとのセキュリティエレメントの要求に関連する場合がある。そしてオペレータは、加入者にとって特に重要なこの要求を（後述するとおり）ＯＴＡプラットフォーム３１を介して優先して処理する。

優先順位が第２位のアイデンティティ（ＩＤ）は、例えば加入者からの電話帳ダウンロード要求に対応する場合がある。この動作は上述の動作より重要性が低い。

優先順位が第３位のアイデンティティ（ＩＤ）は、セキュリティエレメント３０がローミングの際に接続するのが好ましい推奨ネットワークのリストのダウンロード要求に対応する場合がある。

ＩＤは、セキュリティエレメント３０においてＯＴＡで変更可能であることが好ましい。したがって、ＩＤを追加及び削除するだけでなく優先順位を変更することも可能である。

プロキシサーバ３２の機能は、セキュリティエレメントが発する要求のプレフィルタリングを実行することである。プロキシサーバ３２は、所定の値を上回るＩＤを有するセキュリティエレメントが発した要求を体系的に拒否するように構成することができる。このため、プロキシサーバ３２は、ＯＴＡプラットフォーム３１の負荷状況を認識し、これに応じてセキュリティエレメントからの要求をフィルタリングする。プロキシサーバ３２は、プラットフォームの負荷状況が分からない場合、その使用に関する統計を取ることによって負荷状況をシミュレーションすることができる。セキュリティエレメントからの要求の（そのＩＤによって規定される）優先度が十分に高い場合、プロキシサーバは、段階３７において、段階３６において受信したＰＳＫＩＤをＯＴＡサーバ３１に送信する。

したがって、プロキシサーバ３２は、アイデンティティ（ＩＤ）がプロキシサーバ３２に格納されている値より高い優先順位を有する場合に、ＯＴＡプラットフォーム３１に転送する前にアイデンティティ（ＩＤ）に基づいてセキュリティエレメントの要求をフィルタリングする。したがって、プロキシサーバ３２は、ＯＴＡプラットフォーム３１を「ポーリングする」セキュリティエレメント間のＴＬＳ−ＰＳＫセッションの確立に本質的に起因する不要なデータトラフィックを回避することを可能にする。

段階３８において、セキュリティエレメント３０は、暗号スイート、例えばＡＥＳ１２８や３ＤＥＳスイートを選択する。この段階は段階３７に先行することもできる。

ＯＴＡプラットフォーム３１が、セキュリティエレメント３０が策定した要求を実行することを（その負荷レベル及びセキュリティエレメントの要求に割り当てられた優先度に応じて）認める場合、プラットフォームは、段階３９においてセッション鍵をプロキシサーバ３２に送信し、プロキシサーバ３２は段階４０においてセッション鍵をセキュリティエレメント３０に転送する。

段階４１において、プロキシサーバ３２は、セキュリティエレメントとのＴＬＳ−ＰＳＫセッションを確立する段階を終了させ、セキュリティエレメントは、その後プロキシサーバ３２を介してＯＴＡサーバ３１と対話可能になる（段階４２及び４３）。それからプロキシサーバ３２は代理（仲介）のみを行う。これらの段階（４２及び４３）において、セキュリティエレメント３０は、（図１の段階１９と同様に）その要求に対応するＵＲＬを送信する。

代替的に、プロキシサーバ３２は、段階３３の後、ＯＴＡプラットフォーム３１に問い合わせを行い、ビジーかどうかを確認することができる。ＯＴＡサーバはビジーである場合にその旨をプロキシサーバに伝える。次にプロキシサーバ３２は、ＯＴＡサーバがプロキシサーバに利用可能であることを伝えるまで、その要求を繰り返すのを少し待つ。プロキシサーバ３２は、その後段階３５において、（段階３６において送信されるＰＳＫＩＤがプロキシサーバ３２及びＯＴＡプラットフォーム３１に受け入れられるならば）その要求に応える用意があることをセキュリティエレメントに通知する。

図３は、本発明の第２の実施形態を示している。

この実施形態では、セキュリティエレメントは、プロキシサーバを介在させずにＯＴＡプラットフォームに直接アクセスする。

セキュリティエレメント３０は、参照される図２で参照した段階に従ってＯＴＡプラットフォーム３１と対話する。段階３６においてセキュリティエレメント３０のＰＳＫＩＤを受信した後、以下で説明されるＯＴＡプラットフォームに含まれたフィルタリング手段が要求のアイデンティティ（ＩＤ）を解析し、要求を発したセキュリティエレメント３０を管理できるようにアイデンティティ（ＩＤ）が基準値未満である場合にのみこの要求を受け入れる。

したがって、例えばプラットフォーム３１に送信されたアイデンティティ（ＩＤ）が２に等しく、基準値が３に等しい場合、セキュリティエレメントの管理要求は受け入れられ、プラットフォーム３１は、段階３９においてセキュリティエレメントにセッション鍵を送信する。逆に、プラットフォーム３１に送信されたアイデンティティ（ＩＤ）が４に等しく、基準値が３に等しい場合、セキュリティエレメントの管理要求は拒否される（フィルタリング手段によりフィルタリングされ、セキュリティエレメント３０を管理する機能を有するプラットフォームのエレメントに送信されない）。

図４は、セキュリティエレメントの管理要求が拒否される場合を示している。

この図では、段階３３から３６が図２及び３に示すものと同一である。

段階３６においてアイデンティティ（ＩＤ）を受信すると、フィルタリング手段は、ＯＴＡプラットフォームのセキュリティエレメントを管理する手段はセキュリティエレメント３０を管理できないと認め、段階４３において、このセキュリティエレメントに管理が失敗したことを示すメッセージを返す。次にセキュリティエレメント３０は、ＯＴＡプラットフォーム３１に問い合わせを行う将来の「ポーリング」セッションを待つ（段階３３）。

図５は、本発明に従うＯＴＡプラットフォームを示している。

本発明に係るＯＴＡプラットフォーム３１は、フィルタリング手段５０と、セキュリティエレメントを管理する手段５１とを備える。フィルタリング手段は、特に、セキュリティエレメントのＰＳＫＩＤを受信し、ＰＳＫＩＤからアイデンティティ（ＩＤ）を取り出し、受信したアイデンティティが基準値ＲＥＦより小さいかどうか（又は場合により大きいかどうか）をチェックする。基準値ＲＥＦは、例えば負荷状況（アクティビティ）に応じて管理手段５１によりフィルタリング手段５０に提供される。

基準値ＲＥＦは、有利には、例えばトラフィックのピーク時（例えば販売期間）に低くなり、トラフィックレベルが低い期間（例えば夜）に高くなるように、ＯＴＡプラットフォーム又はプロキシの管理中に変更可能である。

フィルタリング手段５０は、アイデンティティ（ＩＤ）が基準値未満の要求のみを、これらの管理手段５１が要求を発したセキュリティエレメントを管理できるように、セキュリティエレメントを管理する手段５１に送信する。したがって、フィルタリング手段５０は「ファイアウォール」として機能する。

これに関して、フィルタリング手段５０が受信したアイデンティティ（ＩＤ）が基準値ＲＥＦ未満である場合、要求は、管理手段５１が段階３９においてこのＰＳＫＩＤを発したセキュリティエレメントにセッション鍵を送信できるように、受信したＰＳＫＩＤを段階５２において管理手段５１に送信するフィルタリング手段５０により受け入れられる。そうでない場合、フィルタリング手段５０は、管理が失敗したことを示すメッセージをセキュリティエレメントに送信する（図４の段階４３参照）。

したがって、フィルタリング手段は、受信したアイデンティティ（ＩＤ）を基準値ＲＥＦと比較する簡易な比較器を備える。

本発明はまた、それ自身のニーズ及び／又はユーザのニーズに応じて異なるＩＤを生成可能な、ＳＩＭ、ＵＩＣＣ又はｅＵＩＣＣカードなどのセキュリティエレメントに関する。

ＵＩＣＣのニーズは、例えばその所有者が初めてこれを端末に挿入し、確定的なサブスクリプションを含まない（オペレータネットワーク、又はオペレータへの完全なサブスクリプションを提供できる専用プラットフォームに接続することを可能にする、いわゆる「ブートストラップ」アプリケーションしか含まない）場合に検出可能である。セキュリティエレメントが海外にあることを検出すると、推奨ネットワークのリストの自動要求を生成することもできる。

これらの異なるＩＤはセキュリティエレメントに格納されており、各ＩＤは、その要求がリモートプラットフォームによって考慮される優先順位を規定する。このリモートプラットフォームは、例えばＯＴＡプラットフォーム（図３）や、セキュリティエレメントとＯＴＡプラットフォームの間に配置されたプロキシ（図２）である。

Claims

電気通信端末と相互作用するセキュリティエレメント（３０）を更新する方法であって、前記更新が前記セキュリティエレメント（３０）からの要求に基づいてＯＴＡプラットフォーム（３１）により実行され、前記セキュリティエレメント（３０）がＰＳＫＩＤをプロキシサーバ（３２）を介して前記ＯＴＡプラットフォーム（３１）に送信し、前記ＰＳＫＩＤがアイデンティティ（ＩＤ）を含み、
前記アイデンティティ（ＩＤ）には、前記セキュリティエレメント（３０）によって策定された、前記ＯＴＡプラットフォーム（３１）への前記要求が考慮されるべき優先順位が規定され、前記優先順位が前記プロキシサーバ（３２）に格納されている基準値より高い場合には、前記プロキシサーバ（３２）は、前記要求を前記ＯＴＡプラットフォーム（３１）に送信する前に前記アイデンティティ（ＩＤ）の前記優先順位に基づいてフィルタリングすることを特徴とする方法。
前記ＯＴＡプラットフォーム（３１）は、前記アイデンティティ（ＩＤ）の追加及び削除だけでなく、前記優先順位の変更をも可能とする請求項１に記載の方法。
電気通信端末と相互作用するセキュリティエレメント（３０）であって、前記セキュリティエレメント（３０）が、前記セキュリティエレメント（３０）とリモートプラットフォーム（３１、３２）との間にセキュアチャネルを確立するために、ＰＳＫＩＤを前記リモートプラットフォーム（３１、３２）に送信するように構成され、
前記ＰＳＫＩＤのアイデンティティ（ＩＤ）には、前記セキュリティエレメント（３０）によって策定された前記リモートプラットフォーム（３１、３２）への要求が考慮されることを要求する優先順位が規定されることを特徴とする請求項１に記載の方法に使用するセキュリティエレメント（３０）。
前記リモートプラットフォームがＯＴＡプラットフォーム（３１）である、請求項３に記載のセキュリティエレメント（３０）。
前記リモートプラットフォームが、前記セキュリティエレメント（３０）とＯＴＡプラットフォーム（３１）の間に配置されたプロキシサーバ（３２）である、請求項３に記載のセキュリティエレメント（３０）。
端末と相互作用するセキュリティエレメント（３０）を管理するように設計されたＯＴＡプラットフォーム（３１）であって、前記セキュリティエレメント（３０）が前記ＯＴＡプラットフォーム（３１）に更新要求を送信し、前記ＯＴＡプラットフォーム（３１）が前記セキュリティエレメント（３０）を管理する手段（５１）を備え、
前記ＯＴＡプラットフォーム（３１）が前記要求をフィルタリングする手段（５０）を備え、前記要求がＰＳＫＩＤを含み、前記ＰＳＫＩＤのアイデンティティ（ＩＤ）には、前記ＯＴＡプラットフォーム（３１）によって前記要求が考慮されるべき優先順位が規定され、前記フィルタリングする手段（５０）が、前記管理する手段（５１）が前記要求を発した前記セキュリティエレメント（３０）を管理できるように、前記ＰＳＫＩＤの前記アイデンティティ（ＩＤ）の前記優先順位が基準値未満の前記要求のみを、前記セキュリティエレメント（３０）を管理する手段（５１）に送信することを特徴とするＯＴＡプラットフォーム（３１）。