JP2021069050A

JP2021069050A - ｅＵＩＣＣおよびｅＵＩＣＣの発行方法

Info

Publication number: JP2021069050A
Application number: JP2019194509A
Authority: JP
Inventors: 直登船津; Naoto Funatsu
Original assignee: Dai Nippon Printing Co Ltd
Current assignee: Dai Nippon Printing Co Ltd
Priority date: 2019-10-25
Filing date: 2019-10-25
Publication date: 2021-04-30

Abstract

【課題】モバイル機器に実装されるｅＵＩＣＣにおいて，変更前のプロファイルにおけるアプリケーションを変更後のプロファイルで利用できるようにする。【解決手段】ｅＵＩＣＣ１の製造時に，ＥＵＭがＩＳＤ−Ｐ１４を発行する前に，ＥＵＭがＭＮＯではないＳＰのＳＰ−ＳＳＤ１３を発行することで，本発明に係るｅＵＩＣＣ１において，ＭＮＯではないＳＰのＳＰ−ＳＳＤは，ＩＳＤ−Ｐ１４に関連付けない状態でアプリケーションレイヤー１７に生成されている。【選択図】図１

Description

本発明は，移動体通信の機能を有するモバイルデバイスの内部に実装されるｅＵＩＣＣ（Embedded Universal Integrated Circuit Cardの略）に関する。

移動体通信の機能を有するモバイルデバイスの内部に装着されるＵＩＣＣ（Universal Integrated Circuit Cardの略）には，移動体通信事業者（以下，ＭＮＯと記す。ＭＮＯは， Mobile Network Operatorの略）が所有する移動体通信システムを利用するために必要な情報がプロビジョニングされる。従来のＵＩＣＣは，カード型の媒体で，特定のＭＮＯに係る情報が製造時にプロビジョニングされるため，ＭＮＯを変更するためには，モバイルデバイスの内部に装着されているカード型のＵＩＣＣを，変更先となるＭＮＯに係る情報がプロビジョニングされている別のカード型のＵＩＣＣに差し替える必要がある。

ＭＮＯを変更するために，モバイルデバイスの内部に装着されているカード型のＵＩＣＣを差し替えが必要であると，変更先となるＭＮＯに係る情報がプロビジョニングされているカード型のＵＩＣＣをコンシューマーは入手しなければならず，コンシューマーはＭＮＯを手軽に変更できない問題がある。また，ＭＮＯの立場からすると，自社の情報がプロビジョニングされたカード型のＵＩＣＣの在庫管理に係るコストが生じるなどのデメリットがある。

このことを解消するために，ＯＴＡ（Over The Airの略）によるリモートプロビジョニングに対応した組み込み型のＵＩＣＣであるｅＵＩＣＣ（embedded UICCの略）に係る仕様がGSM（登録商標） Associationで規格化されている（例えば，非特許文献１）。

図５は，ｅＵＩＣＣ２のアーキテクチャを説明する図で，図５で図示したｅＵＩＣＣ２のアーキテクチャは非特許文献１に基づくものである。ここでは，ｅＵＩＣＣ２のアーキテクチャを簡単に説明するに留まり，ｅＵＩＣＣ２のアーキテクチャの詳細は非特許文献１などの文献を参照願いたい。

図５で図示したように，ｅＵＩＣＣ２は，暗号鍵を用いたセキュアコミュニケーションをサポートする機能などを有するセキュリティドメイン(SD: Security Domain)として，ＩＳＤ−Ｒ２０(Issuer Security Domain Rootの略)，ＥＣＡＳＤ２２（eUICC Controlling Authority Security Domainの略）および少なくとも一つのＩＳＤ−Ｐ２１(Issuer Security Domain Profileの略)をメモリに格納する。

ＩＳＤ−Ｒ２０およびＥＣＡＳＤ２２は，ｅＵＩＣＣ２の製造時に発行されるＳＤである。ＩＳＤ−Ｒ２０は，ｅＵＩＣＣ２に格納されているＳＤのルートになる発行者のＳＤで，ＩＳＤ−Ｐ２１を生成する機能などを有する。ＥＣＡＳＤ２２は，ＩＳＤ−Ｒ２０やＩＳＤ−Ｐ２１が使用する暗号鍵をセキュアに生成する機能を有する。また，ＩＳＤ−Ｐ２１は，ＭＮＯが運営している移動体通信システムを利用するための情報を集約したデータであるプロファイル２１０を格納する発行者のＳＤである。

ＩＳＤ−Ｐ２１が格納するプロファイル２１０には，ＭＮＯのＳＤであるＭＮＯ−ＳＤ２１１，ＮＡＡ２１４（Network Access Applicationの略），ＰＯＬ１＿２１２（Policy1の略）およびファイルシステム２１３を少なくとも含む。図５で図示したプロファイル２１０は，ＭＮＯ−ＳＤ２１１に関連付けられているＭＮＯアプリケーション２１５と，サービスプロバイダ（以下，ＳＰと記す。ＳＰは，Service Providerの略）のＳＤであるＳＰ−ＳＳＤ２１６（Supplementary Security Domainの略）と，ＳＰ−ＳＳＤ２１６に関連付けられているＳＰアプリケーション２１７を含んでいる。

ＭＮＯ−ＳＤ２１１は，ＳＰ−ＳＳＤ２１６などのＳＳＤを生成する機能，ＳＳＤ２１５を削除する機能などを有する。ＰＯＬ１＿２１２は，プロファイル２１０の無効化の許可やプロファイルの削除の許可などが示されるポリシールールを含んでいる。ＮＡＡ２１４は，例えば，ETSI TS 131 102で規格化されているＵＳＩＭアプリケーションなど，移動体通信システムを利用するためのアプリケーションになる。ファイルシステム２１３は，ETSI TS 102 221などの文献で開示されている仕様になる。

プロファイル２１０が含んでいるＭＮＯアプリケーション２１５は，ＭＮＯがコンシューマーに提供するサービス（例えば，コールコントロール）に係るアプリケーションである。ＳＰアプリケーション２１７は，ＳＰがコンシューマーに提供するサービス（例えば，モバイルコマース）に係るアプリケーションである。

ｅＵＩＣＣ２では，複数のプロファイル２１０の格納が許可されているが，有効に設定できるプロファイル２１０の数は一つに限定され，有効に設定されているプロファイル２１０に対応するＭＮＯが，ｅＵＩＣＣ２を利用して利用可能なＭＮＯになる。図５では，プロファイル２１０aを実線で，プロファイル２１０ｎを破線で図示しており，これは，プロファイル２１０aが有効でプロファイル２１０ｎは無効であることを示している。なお，ｅＵＩＣＣ２で有効にするプロファイル２１０の変更は，コンシューマー向けのモバイルデバイスの場合（例えば，スマートデバイス），コンシューマーの操作により行われ，ＩｏＴに係るモバイルデバイス（例えば，重機）の場合，ＭＮＯの指示により行われる。

このように，リモートプロビジョニングに対応したｅＵＩＣＣ２では，コンシューマーなどがプロファイル２１０を変更できるが，プロファイル２１０を変更すると，変更前のプロファイル２１０に含まれるＳＰアプリケーション２１７も無効になるため，変更前のプロファイル２１０に含まれていたＳＰアプリケーション２１７を変更後のプロファイル２１０に引き継ぐことはできない。

変更前のプロファイル２１０に含まれていたアプリケーションを変更後のプロファイル２１０に引き継げるようにした発明として，アプリケーションに係るデータを変更前のプロファイル２１０から変更後のプロファイル２１０に移行できるようにした発明が特許文献１で開示されている。

しかしながら，特許文献１では，アプリケーションに係るデータを変更前のプロファイル２１０から変更後のプロファイル２１０に移行する処理を行うＳＤはＩＳＤ−Ｒ２０になるが，ＳＰアプリケーション２１７の場合，ＳＰアプリケーション２１７はＳＰ−ＳＳＤ２１６に関連付けられているため，権限を越えた処理をＩＳＤ−Ｒ２０が行うことになり兼ねない。

特表２０１８−５０３３１３号公報

GSM（登録商標） Association : Remote Provisioning Architecture for Embedded UICC Technical Specification Version 3.2 27 June 2017

そこで，本発明は，アプリケーションに係るデータを変更前のプロファイルから変更後のプロファイルに移行することなく，変更前のプロファイルにおけるアプリケーションを変更後のプロファイルで利用できるようにすることを目的とする。

上述した課題を解決する第１発明は，移動体通信事業者のセキュリティドメインを含むプロファイルを格納するプロファイルセキュリティドメインに関連付けない状態で，移動体通信事業者ではないサービスプロバイダのセキュリティドメインがアプリケーションレイヤーに生成されていることを特徴とするｅＵＩＣＣである。上述した第１発明によれば，前記サービスプロバイダのセキュリティドメインは，前記プロファイルセキュリティドメインに関連付けられていなため，前記プロファイルセキュリティドメインを無効または削除しても，前記サービスプロバイダのセキュリティドメインおよびこれに関連付けられているアプリケーションそれぞれは，前記プロファイルの変更による影響を受けない。

更に，第２発明は，ｅＵＩＣＣの製造時に，移動体通信事業者のセキュリティドメインを含むプロファイルを格納するプロファイルセキュリティドメインを発行する前に，移動体通信事業者ではないサービスプロバイダのセキュリティドメインを発行することを特徴とするｅＵＩＣＣの発行方法である。前記プロファイルセキュリティドメインを発行する前に，前記サービスプロバイダのセキュリティドメインを発行することで，前記プロファイルセキュリティドメインに関連付けない状態で，前記サービスプロバイダのセキュリティドメインをｅＵＩＣＣのアプリケーションレイヤーに生成できる。

このように，上述した本発明によれば，アプリケーションに係るデータを変更前のプロファイルから変更後のプロファイルに移行することなく，変更前のプロファイルにおけるアプリケーションを変更後のプロファイルで利用できる。

本実施形態に係るｅＵＩＣＣの概略構成図。ｅＵＩＣＣが有するプロファイルを説明する図。有効にするプロファイルを変更したときのｅＵＩＣＣを説明する図。ｅＵＩＣＣの発行手順を説明する図。ｅＵＩＣＣのアーキテクチャを説明する図。

ここから，本発明に係る実施形態について記載する。本実施形態は，本発明の理解を容易にするためのものであり，本発明は，本実施形態に限定されるものではない。また，特に断りのない限り，図面は，本発明の理解を容易にするために描かれた模式的な図である。

図１は，本実施形態に係るｅＵＩＣＣ１の概略構成図，図２は，ｅＵＩＣＣ１が有するプロファイル１５を説明する図，図３は，有効にするプロファイル１５を変更したときのｅＵＩＣＣ１を説明する図，そして，図４は，ｅＵＩＣＣ１の発行手順を説明する図である。

ｅＵＩＣＣ１は，モバイル機器に組み込まれるデバイスである。ｅＵＩＣＣ１を組み込むモバイル機器としては，例えば，体温，血圧および心拍数などの健康データを所定のサーバへ移動体通信するワイヤレスヘルスケアに対応したヘルスデバイスや，スマートフォンやスマートウォッチなどのスマートデバイスのみならず，作業動画などを所定のサーバへ移動体通信する重機も想定できる。

図１を参照すると，ｅＵＩＣＣ１の層構成は，ｅＵＩＣＣ１に必要な機能を提供するアプリケーションが実装されるアプリケーションレイヤー１７と，このアプリケーションの動作環境を提供するプラットフォーム１８を含む。

ｅＵＩＣＣ１のプラットフォーム１８は，ハードウェア１６とハードウェア１６の上で動作するオペレーティングシステム１０（以下，ＯＳと記す。ＯＳは，Operating Systemの略）を含む。

図１で図示したハードウェアの構成では，バスを介してＣＰＵ１６０（Central Processing Unitの略）に，ＲＡＭ１６２（Random Access Memoryの略），ＲＯＭ１６１（Read Only Memoryの略)，ＮＶＭ１６６(Non-volatile memoryの略)，ＵＡＲＴ１６５（Universal Asynchronous Receiver/Transmitterの略），タイマー１６４およびアクセラレーター１６３が接続されている。ＲＡＭ１６２は，ｅＵＩＣＣ１のメインメモリとなる揮発性メモリで，ＲＯＭ１６１は，電気的に書き換え不可能な不揮発性メモリである。ＮＶＭ１６６は，電気的に書き換え可能な不揮発性メモリである。ＵＡＲＴ１６５は，ｅＵＩＣＣ１が組み込まれたモバイル機器との通信を制御する回路で，タイマー１６４は，時間を計測する回路で，アクセラレーター１６３は，暗号演算の処理速度を速くするための回路である。

ｅＵＩＣＣ１のＯＳ１０は，特定のプログラミング言語（例えば，ＪＡＶＡ（登録商標））で記述されたコンピュータプログラムが実行するために必要なランタイム環境（Runtime Environment）を提供するソフトウェアである。

ＯＳ１０は，ＯＳ１０を動作環境とするアプリケーションに対して，様々な機能を提供する。ＯＳ１０がアプリケーションに対して提供する機能として，図１では，プラットフォームサービスマネージャ１００とテレコムフレームワーク１０１を図示している。プラットフォームサービスマネージャ１００は，プラットフォームマネージメント機能とポリシールール施行メカニズムを少なくとも提供する。テレコムフレームワーク１０１は，有効になっているＩＳＤ−Ｐ１４のＮＡＡ１５５に対して，ネットワーク認証アルゴリズムを提供する。

ｅＵＩＣＣ１のアプリケーションレイヤー１７には，ｅＵＩＣＣ１で必要な機能を提供するアプリケーションとして，複数のセキュリティドメイン（以下，ＳＤと記す。ＳＤは， Security Domainの略）が実装される。図１を参照すると，ｅＵＩＣＣ１のアプリケーションレイヤー１７には，ＳＤとして，ＩＳＤ−Ｒ１１，ＥＣＡＳＤ１２（eUICC Controlling Authority Security Domainの略）および少なくとも一つのＩＳＤ−Ｐ１４に加えて，サービスプロバイダ（以下，ＳＰと記す。ＳＰは，Service Providerの略）のＳＤになるＳＰ−ＳＳＤ１３が実装される。

ＩＳＤ−Ｒ１１は，ＩＳＤ−Ｐ１４のルートとなるＳＤで，Issuer Security Domain Rootの略である。ｅＵＩＣＣ１に生成できるＩＳＤ−Ｒ１１の数は一つに限定される。ＩＳＤ−Ｒ１１は，プロビジョニングシステムとの間でセキュアチャネルを構築する機能や，ＩＳＤ−Ｐ１４を生成または削除する機能，ＩＳＤ−Ｐ１４の状態を無効または有効に設定する機能などを有する。

また，ＩＳＤ−Ｐ１４は，本発明に係るプロファイルセキュリティドメインとして機能するＳＤで，Issuer Security Domain Profileの略である。ＩＳＤ−Ｐ１４は，ＩＳＤ−Ｐ１４に対応する移動体通信事業者（以下，ＭＮＯと記す。ＭＮＯは， Mobile Network Operatorの略）のプロファイル１５を格納する。図２を参照すると，ＩＳＤ−Ｐ１４が格納するプロファイル１５は，ＭＮＯ−ＳＤ１５０，ＮＡＡ１５５（Network Access Applicationの略），ＰＯＬ１＿１５３（Policy1の略），ファイルシステム１５４およびＭＮＯアプリケーション１５１を含んでいる。なお，本実施形態では，ＭＮＯではないＳＰのＳＰ−ＳＳＤ１３をプロファイル１５に含ませていない。

ＥＣＡＳＤ１２は，ＩＳＤ−Ｒ１１やＩＳＤ−Ｐ１４が使用する暗号鍵をセキュアに生成する機能などを有するＳＤで，eUICC Controlling Authority Security Domainの略である。

ＳＰ−ＳＳＤ１３は，ＳＰに対応するＳＤである。ＳＰ−ＳＳＤ１３には，ＳＰ−ＳＳＤ１３に対応するＳＰがコンシューマーに提供するサービスに係るＳＰアプリケーション１３０が関連付けられる。ＳＰがコンシューマーに提供するサービスは，ｅＵＩＣＣ１が実装されるモバイル機器で変わるのが一般的である。ｅＵＩＣＣ１が実装されるモバイル機器がスマートデバイスの場合，このサービスは，例えば，Ｍコマースや交通機関の乗車券である。

上述したように，ＳＰ−ＳＳＤ１３は，ＩＳＤ−Ｐ１４が格納するプロファイル１５には含まれておらず，ＩＳＤ−Ｐ１４に関連付けない状態でアプリケーションレイヤー１７に生成されている。本実施形態に係るｅＵＩＣＣ１において，ＩＳＤ−Ｐ１４に関連付けない状態でＳＰ−ＳＳＤ１３をアプリケーションレイヤー１７に生成しているのは，ｅＵＩＣＣ１で有効になるプロファイル１５が切り替わっても，変更前のプロファイル１５における状態のままＳＰアプリケーション１３０を変更後のプロファイル１５で利用できるようにするためである。

図１では，一つのプロファイル１５のみをｅＵＩＣＣ１に登録していたが，図３では，ＭＮＯ＿Ａに対応するプロファイル１５ａと，ＭＮＯ＿Ｂに対応するプロファイル１５ｂの二つをｅＵＩＣＣ１に登録し，ＭＮＯ＿Ｂに対応するプロファイル１５ｂが有効になっている。

図３を参照すればわかるように，ＳＰアプリケーション１３０を関連付けているＳＰ−ＳＳＤ１３は，プロファイル１５を格納したＩＳＤ−Ｐ１４には関連付けられていないため，ＳＰ−ＳＳＤ１３とこれに関連付けられたＳＰアプリケーション１３０は，有効になるプロファイル１５の変更に係る影響を受けずに動作する。図３では，有効になるプロファイル１５が，ＭＮＯ＿Ａに対応するプロファイル１５ａから，ＭＮＯ＿Ｂに対応するプロファイル１５ｂに変更になっても，ＳＰ−ＳＳＤ１３とこれに関連付けられたＳＰアプリケーション１３０の内容は変更されない。

ここから，ｅＵＩＣＣ１の発行方法について説明する。図４を参照すると，製造時におけるｅＵＩＣＣ１の発行方法では，ｅＵＩＣＣ１の製造時にＥＵＭ（eUICC Manufacturerの略）がＩＳＤ−Ｒ１１を発行するステップ（Ｓ１），ｅＵＩＣＣ１の製造時にＥＵＭがＥＣＡＳＤ１２を発行するステップ（Ｓ２），ｅＵＩＣＣ１の製造時にＥＵＭがＳＰ−ＳＳＤ１３を発行するステップ（Ｓ３），ｅＵＩＣＣ１の製造時にＥＵＭが必要に応じてＩＳＤ−Ｐ１４を発行するステップ（Ｓ４）が順に実行される。なお，ＳＤを発行する際，ＳＤのプログラムコードをｅＵＩＣＣ１のＮＶＭ１６６にロードした後，ＳＤに係るデータのインストールが行われ，ＳＤのインスタンスがｅＵＩＣＣ１に生成される。

ＩＳＤ−Ｒ１１は，ｅＵＩＣＣ１に必ず必要なＳＤであるため，図４においてＩＳＤ−Ｒ１１の発行は最初になっている。ＥＣＡＳＤ１２は，ＩＳＤ−Ｒ１１に関連付けられるＳＤになるため，図４において，ＩＳＤＲ−１１を発行した後に，ＥＣＡＳＤ１２を発行している。

非特許文献1の規格に従うＩＳＤ−Ｒ１１の仕様によれば，ＩＳＤ−Ｒ１１は，ＩＳＤ−Ｐ１４以外のＳＤを生成できないため，図４では，ｅＵＩＣＣ１の製造時，ＩＳＤ−Ｐ１４を発行する前に，ＳＰ−ＳＳＤ１３を発行している。ＩＳＤ−Ｐ１４を発行する前に，ＳＰ−ＳＳＤ１３を発行することで，図１で図示したように，ＩＳＤ−Ｐ１４に関連付けない状態で，ＳＰ−ＳＳＤ１３のインスタンスをｅＵＩＣＣ１に生成できる。

１ｅＵＩＣＣ
１０オペレーティングシステム
１１ＩＳＤ−Ｒ
１２ＥＣＡＳＤ
１３ＳＰ−ＳＳＤ
１４ＩＳＤ−Ｐ
１５プロファイル
１６ハードウェア
１７アプリケーションレイヤー
１８プラットフォーム

Claims

移動体通信事業者のセキュリティドメインを含むプロファイルを格納するプロファイルセキュリティドメインに関連付けない状態で，移動体通信事業者ではないサービスプロバイダのセキュリティドメインがアプリケーションレイヤーに生成されていることを特徴とするｅＵＩＣＣ。
ｅＵＩＣＣの製造時に，移動体通信事業者のセキュリティドメインを含むプロファイルを格納するプロファイルセキュリティドメインを発行する前に，移動体通信事業者ではないサービスプロバイダのセキュリティドメインを発行することを特徴とするｅＵＩＣＣの発行方法。