Google Store で Google Pixel を 10% 引きで購入できるという紹介コードがまた配布されています。Pixel 9a と Pixel 10 を購入したばかりで、次回の購入はおそらく Pixel 11 になるでしょう。またもや自分では活用できそうにありませんので、ご入用の方がいらっしゃいましたらご利用ください。
2026/02/28 まで有効だそうです。
GlocalMe のサイトに eSIM Trio の販売ページが出来ていることに気付き、早速入手して使ってみることにしました。初期のデータ通信契約込みでの購入になるため、Japan & Korea の最も安い 10GB/7DAYS を選択すると 16.50 ドル。別途必要になる送料はさておき、リーズナブルな価格でのご提供です。
GlocalMe アプリを端末にインストールし、カード裏面に書かれているデフォルトの ICCID を入力すれば、すぐに利用可能な状態になります。この OTA-eSIM- ナントカという名前の初期データパッケージですが、ES10c: GetProfilesInfo (BF2D) で得られるリストには載りません。GlocalMe 上で追加購入したデータパッケージも同様で、LPA には「eSIM プロファイル」としては扱われないものでした。
上のスクリーンショットにある "Download eSIM" メニューを使うことで、eSIM Trio を eUICC カードとして利用することができます。eSIM プロファイルのダウンロード手続きには、QR コードのスキャンまたはアクティベーションコードのマニュアル入力を選択することができます。
お試しで野良のテストプロファイルをダウンロードしてみると、Remaining Download Attempts が 3 Times から 2 Times に減りました。4 回目以降のダウンロードを行いたい場合には、追加のお支払 1 ドルで 1 回分、5 ドルで 10 回分を購入することができる仕様です。
届いた eSIM Trio カードを Google Pixel 9 に装着してみたのですが、なんとカードが認識されません。一方、既に普段使い用ではなくなっている Pixel 5 では認識されます。ということで ATR (Answer To Reset) を確認することにしたのですが、もしかすると今回入手したカードの仕様がそうだっただけで、皆さまが手に取るカードとは様子が異なるかもしれないことを予めご承知おきください。
D/AnswerToReset( 4501): Successfully parsed the ATR string
3b9f94803f03a08031a073be211367509a406e7ec104c1 into AnswerToReset:{
mConventionByte=3B,mFormatByte=9F,mInterfaceBytes={
{TA=94,TB=null,TC=null,TD=80}
{TA=null,TB=null,TC=null,TD=3F}
{TA=03,TB=A0,TC=null,TD=null}},
mHistoricalBytes={
80,31,A0,73,BE,21,13,67,50,9A,40,6E,7E,C1,04,
},
mCheckByte=C1
}
D/UiccSlot( 4501): checkIsEuiccSupported : falseTD2 の b1-b4 が 'F' (Protocol T=15) なので、その次のセットが Global Interface Bytes でしたね。TA3 の b1:b6 が Supply Voltage Classes なので下表と照合してみると、どうやらこのカードがサポートしているのは Class A (5V) と Class B (3V) だけで、Class C (1.8V) については非サポートのようです。
Google Pixel 8 あたりから Class C だけをサポートするようになったという記事が散見される（例えば）ので、それかもしれません。
eSIM Trio の販売ページに貼られているスライドでは "Fully compatible with Apple and Android" と表現されているので、今後この表現もしくはカードの仕様が変わるのかどうか気になります。
ATR を見ていてもう一点目に留まったのは、Global Interface Bytes の TB3 です。TB3 の b2 がセットされていないということは、一般的なセルラー通信用モデムには GSMA SGP.22 対応の eUICC としては認識されないことが予想されます。GlocalMe アプリからアクセスできればいいので、その点については特に困ることはないのだと思います（大前提として UICC としては認識される必要はありますが）。
GSMA SUS-UP (Security Accreditation Scheme for UICC Production) の認定番号はどうなっているんだろうと EUICCInfo2 (BF22) を読んでみたら、そこには "SASAccreditationNumber" と書かれていました。これは認定を受けていないと読んで良いでしょうか。
| profileVersion [1] | 020100 |
|---|---|
| svn [2] | 020200 |
| euiccFirmwareVer [3] | 190400 |
| extCardResource [4] | 81010082040004C48083023EA5 |
| uiccCapability [5] | 017F32 |
| ts102241Version [6] | 090200 |
| globalplatformVersion [7] | 020300 |
| rspCapability [8] | 0490 |
| euiccCiPKIdListForVerification [9] | 041481370F5125D0B1D408D4C3B232E6D25E795BEBFB |
| euiccCiPKIdListForSigning [10] | 041481370F5125D0B1D408D4C3B232E6D25E795BEBFB |
| ppVersion | 010000 |
| sasAcreditationNumber | "SASAccreditationNumber" |
製品の仕様上、端末に eUICC だと認識されてプリインされている LPA に動かれたりしても面倒なので、標準仕様から少し外れたカード仕様にして意図的に認定を受けてはいないということかもしれません。ただ、素性が定かではないカードへの eSIM プロファイルのダウンロードを快く思わない通信事業者もいるかもしれません。ドコモ等の eSIM プロファイルをダウンロードできるかどうか、どこかで人柱が立ってくれることに期待します。
GlocalMe アプリが OTA SIM ではなく eSIM プロファイルを取り扱う場合には、Android OMAPI を通して eSIM Trio カードにアクセスします。アクセスルールは ARA-M ではなく PKCS#15 (ARF) の方に書かれていて、ISD-R に対するアクセスを GlocalMe アプリに許可するという設定でした。UICC Carrier Privileges の利用は無いようです。
I/SecureElement-AccessRuleCache(): findAccessRule() Case A
REF_DO:
AID_REF_DO: 4f10a0000005591010ffffffff8900000100
Hash_REF_DO: c114661966df2c706b99692a37fc9204408cf8d88f77, ..
I/SecureElement-AccessRuleCache(): [
mPackageName=com.wws.glocalme,
mAccess=ALLOWED, mApduAccess=ALLOWED, ..
]
Apple は iPhone 13 から、Google は Pixel 7 から eSIM MEP (Multiple Enabled Profiles) をサポートしています。一般市民が触って遊べるようなものなのかどうかは疑問なところですが、どんな仕組みで動いているのか知っておいても良いかなと考えています。ということで、今回は ETSI TS 102 221 を読んでゆきます。
Pixel 7 のバグレポートを見ると、UiccSlot やその近辺のログに "..MultipleEnabledProfiles=true" といった情報を見つけることができます。
UiccSlot:
mActive=true
mIsEuicc=true
isEuiccSupportsMultipleEnabledProfiles=true
mIsRemovable=false
mLastRadioState={0=1, 1=2}
mIccIds={0=898130005[****], 1=}
mPortIdxToPhoneId={0=1, 1=-1}
mEid=[****]
mCardState=CARDSTATE_PRESENT
mUiccCard=com.android.internal.telephony.uicc.euicc.EuiccCard@224a7c5
UiccCard:
mCardState=CARDSTATE_PRESENT
mCardId=[****]
mNumberOfPorts=1
mIsSupportsMultipleEnabledProfiles=trueこの情報がどこから来ているんだろうとソースコードを追ってみると、AnswerToReset.java による ATR の確認結果であることがわかります。
private void checkEuiccSupportedCapabilities() { // eUICC is supported only if the b8 and b2 of the first tB after T=15 are set to 1. // MEP is supported only if the b8 and b1 of the first tB after T=15 are set to 1. for (int i = 0; i < mInterfaceBytes.size() - 1; i++) { if (mInterfaceBytes.get(i).getTD() != null && (mInterfaceBytes.get(i).getTD() & T_MASK) == T_VALUE_FOR_GLOBAL_INTERFACE && mInterfaceBytes.get(i + 1).getTB() != null) { if ((mInterfaceBytes.get(i + 1).getTB() & B8_MASK) != 0 && (mInterfaceBytes.get(i + 1).getTB() & B2_MASK) != 0) { mIsEuiccSupported = true; } if ((mInterfaceBytes.get(i + 1).getTB() & B8_MASK) != 0 && (mInterfaceBytes.get(i + 1).getTB() & B1_MASK) != 0) { mIsMultipleEnabledProfilesSupported = true; } return; } } }
TD3 の下位ニブル 'F' (Protocol T=15) の次のセットが Global Interface Bytes です。ETSI TS 102 221 によると、そのセットの TB の b8 および b1 がセットされていれば UICC が LSI (Logical SE Interface) をサポートしていることを示しているとのこと。上記のソースコードにあるコメントもそのように説明していますね。
Pixel 7 の ATR もログから拾ってきてみました。TD=3F (Protocol T=15) となっている 3 つめのセットの次のセットが Global Interface Bytes で、その TB=83 (b8/b1 ともに 1) が LSI のサポートを意味しているということですね。
D/AnswerToReset( 2191): Successfully parsed the ATR string
3B9F97C00AB1FE453FC6838031E073FE211F65D002341569810F21 into AnswerToReset:{
mConventionByte=3B,
mFormatByte=9F,
mInterfaceBytes={
{TA=97,TB=null,TC=null,TD=C0}
{TA=null,TB=null,TC=0A,TD=B1}
{TA=FE,TB=45,TC=null,TD=3F}
{TA=C6,TB=83,TC=null,TD=null}
},
mHistoricalBytes={80,31,E0,73,FE,21,1F,65,D0,02,34,15,69,81,0F,},
mCheckByte=21
}
LSI とは、ISO 7816 の物理インターフェースを複数の論理インターフェースへと多重化してアクセスする仕組みのこと。主に T = 0 プロトコルの端末の場合、MANAGE LSI コマンドを使って後続の APDU コマンドの論理インターフェースを選択したり、特定の論理インターフェースのみをリセットしたりするようです。論理インターフェースの、0 から 31 までの 32 個まで取り扱うことができますよと。
7.5 Logical secure element Interfaces
A UICC may support LSIs. If supported by the UICC, this shall be indicated in the ATR. LSIs provide a multiplexing mechanism which allows the terminal to communicate with multiple LSEs over one physical interface. LSIs supported by the UICC and the terminal shall be identified by consecutive numbers starting from zero. The maximum value for the LSI is '1F'. Management of LSIs is done via a dedicated command MANAGE LSI which allows:
各論理インターフェースを通してアクセスする LSE については、下記のように説明されています。eUICC SE の場合、eSIM プロファイル (もしくはそれが入っている箱のようなもの) がこの LSE に相当するものとして読んで不都合なさそうです。なるほど、活性化されている複数の eSIM プロファイルのうちのひとつから REFRESH コマンドを受けたとき、従来の方法で eUICC をリセットすると eUICC 全体を (＝全ての eSIM プロファイルを) リセットしてしまいますもんね。複数の論理インターフェースで多重化されているときには、MANAGE LSI コマンドを使って特定の論理インターフェースをリセットしたい旨を伝える必要があるみたいです。
8.10 Logical secure elements
A UICC may support several LSEs on the same physical element. Each LSE acts and is handled by the terminal like a separate secure element. The terminal communicates with the different LSEs via LSIs. Each LSE operates logically independently from the others. As seen on the interface, each LSE has its own file system, its own applications, its own AIDs, its own independent security status, its own CAT session (which means that several of them can run interleaved in parallel on the different LSIs), and its own runtime environment.
The terminal can switch between the LSEs by sending MANAGE LSI (select LSI) commands or by selecting the LSI via the NAD byte when using T = 1. The MANAGE LSI command also allows resetting an LSE. Such a reset shall be equivalent to a warm reset of the interface for a UICC not supporting LSEs. A cold reset or a warm reset of the physical interface results in resetting all LSEs. When the terminal receives a REFRESH proactive command with mode "UICC reset" on an LSI, the terminal shall reset only the corresponding LSE via a MANAGE LSI command
先ほど MANAGE LSI コマンドによる論理インターフェース選択について「主に T = 0 プロトコルの端末の場合」と書きましたが、T = 1 プロトコルであれば MANAGE LSI コマンドではなく NAD (Node ADdress byte) バイトを使って論理インターフェースを指定することができます。NAD バイトは、T = 1 のブロック構造のプロローグフィールド内に存在します。
この NAD バイトにある DAD/SAD を使ってブロックの送受信の対象とする論理インターフェースを指定することになりますが、AT コマンドや PC/SC インターフェース経由で一般市民があれこれやれそうな気がしていないので、それについて言及するのはこのあたりまでにしておこうと思います。
UICC は ATR を使って LSI のサポートを端末に対して示しますが、それをただ見ているだけでは端末は LSI を利用することができません。
7.5 Logical secure element Interfaces
Terminal and UICC shall agree on using LSIs as follows:
- The UICC indicates support for LSIs in the ATR.
- If indicated by the UICC, the terminal shall indicate in PPS2 if LSIs shall be used for the card session.
- If LSIs are used for the card session, LSI 0 is selected after the PPS.
- Before sending a command on an LSI different from 0 or sending any other MANAGE LSI command, the terminal shall perform the setup of the LSI configuration by sending a MANAGE LSI (configure LSIs) APDU to the UICC.
端末側もまた、PPS2 を使って LSI を利用する能力と意思があることを UICC に対して示す必要があると説明されています。
6.4 PPS procedure
PPS2 shall only be used if the first tB i (i > 2) after T = 15 is present in the ATR. The coding for PPS2 is identical to that of the first tBi (i > 2) after T = 15. The value selected depends upon the features supported by the terminal.
MANAGE LSI コマンドの CLA および INS は、下表のように規定されています。CLA は '8X' ではなく '80' なので、論理チャネル 0 (基本チャネル) に対してのみ送信可能なコマンドなんですね。
| Command | CLA | INS |
|---|---|---|
| MANAGE LSI | '80' | '7C' |
MANAGE LSI コマンドについて整理するには ETSI TS 102 221 から複数の表を引用する必要がありますので、あらためて別の投稿でそれを行うことにしようと思います。
このページに来られた方々は既にいろいろとご存じのことだと思われますので、まずは結論から。ふたつあります。
増設と書きましたが、M.2 通信モジュールを変換アダプタに載せて Windows PC の USB ポートに挿してみただけです。
Windows に入っている LPA および設定アプリを用いて "eSIM.me" に対してそれらの操作を行うことができることを確認しました。もし仮に TelcoVillage GmbH が "eSIM.me" のサービスを継続しないような事態になっても、これで安心ですね（そうなのか）。
もろもろ試す前の Windows の設定画面がこちらです。セルラー通信モジュールなんて載せていないデスクトップ PC ですので、セルラー関係の表示がありません。
そして、こちらが上述の通信モジュールを増設した後の Windows の設定画面です。セルラーの設定メニューが登場していますね。"TelcoVillege1" と表示されていますが、おそらく空の状態の "eSIM.me" のブートプロファイルが見えているものと思われます。
その後、Ubigi の eSIM をダウンロードしてみました。特に問題なくダウンロードの手続きは成功し、ダウンロード後の eSIM が普通に表示されています。
Dell PC 用のこちらの通信モジュールを購入して試しました。商品の説明に "only for e-SIM Card" などと書かれていてちょっとあやしいですが、「eSIM 対応」と読んで問題なさそうです。
eSIM 対応は SIM2 カードスロットだけなのではと想像していましたが、SIM1 カードスロットに "eSIM.me" を装着しても問題なく使用できています。また、SIM2 カードスロットに "eSIM.me" を装着する必要があるものと考えていたのですが、なんと SIM2 として eSIM がこのモジュールに内蔵されていました。つまり、この通信モジュールさえ増設できれば、"eSIM.me" を持っていなくても Windows PC を eSIM 対応機にすることができます。
M.2 通信モジュールを USB 機器化するアダプタですが、SIM カードスロットがふたつ付いている下記のものを使用しました。上記の通り SIM2 カードスロットの利用が必要になるものと考えての選択でしたが、結局のところ SIM カードスロットがひとつの変換アダプタでも全然問題なかったということになります。
そしておなじみのカード型 eUICC、"eSIM.me" がこちらです。
期待通りに Windows の LPA を起動させられたのは、これまでのところ上記の通信モジュールひとつだけです。カード型 eUICC (eSIM.me) を認識できるもの、また AT+CSIM コマンドを用いて ISD-R を選択できるものも幾つか見つけたのですが、それらでは Windows の設定画面に eSIM 関連オプションを表示させることができません。モバイルブロードバンド関係のログをさらっと見る限りでは、Windows に ATR を提供できるかどうかがひとつポイントになってそうな感じはあります。
下記のログは上記の通信モジュールを使用時に取得したもので、"GetAtrInfo Succeeded" になっていることが確認できます。その他の通信モジュールで試したときには、これが軒並み "GetAtrInfo Failed" になっていました。
[Microsoft-Windows-wmbclass]Solicited response received with the following parameters: Caller Request Id: 0x182 Driver Request Id: 0 Service Id: {0000004a-588e-c2f6-37f0-c94b8665f4d4} Command Name: Kﾐ堵UICC_CID_ATR Command Id: 1 Device Status: 0(MBB_STATUS_SUCCESS) Ndis Status: 0x0(NT=STATUS_SUCCESS) Payload Length: 32 Payload: 0x17000000080000003B9F96803FC7828031E073FE211B57AA8660F0010011EE00
...
[Microsoft-Windows-WwanProtDim]INDICATION RECEIVED
[Microsoft-Windows-WwanProtDim] StatusCode : NDIS_STATUS_WWAN_ATR_INFO (0x40041034)
[Microsoft-Windows-WwanProtDim] RequestId : 0x182
[Microsoft-Windows-WwanProtDim] DataLength : 0x30
...
[Microsoft-Windows-WWAN-SVC-EVENTS]WWAN Service event: [Info] WwanNhTraceMsmNotification: [NH] Dispatch WwanNotificationSourceMsm\WwanMsmEventTypeAtrInfo AtrLength=23 Interface: {{c39392e1-770f-4d88-aa4b-d9d9aabc10f6}}
...
[Microsoft-Windows-WWAN-SVC-EVENTS]WWAN Service event: [Info] CWwanUicc::onAtr: IsESIM 1 IsEnterpriseESIM 0 ReadyState 1 Interface: {{c39392e1-770f-4d88-aa4b-d9d9aabc10f6}}
...
[Microsoft-Windows-WWAN-SVC-EVENTS][M:0][E:0][Req:0] ExecutorType(4(WWAN_INTF_TYPE_MBIM_1)) GetAtrInfo Succeededちゃんと調べるためには MBIM の仕様書を読まないといけなさそうですので、それはまた暇になったときのための宿題にしようと思います。
本ブログにて最初に "eSIM.me" を取り上げたのは、下記の記事でした。
cheerio-the-bear.hatenablog.com
着脱可能なカード型 eUICC としては、ソフトバンク系の通信事業者で商用化されているものもおすすめです。こちらはいつまでサービスされるのかかなり疑問ですので、レア度が高くなるものと思われます。
ソフトバンクおよびワイモバイルでは「eSIMプロファイルのダウンロードに使える物理的なeSIMカード」が2022年3月から提供されているようですが、あまり市場に出回っていないのか（そんな気はする）、それらのeSIMカードについて書かれたブログやツイートを見かけることがほとんどありません。今後もそのような物理的なeSIMカードが提供され続けるかというと、そんなことにはならないように思います。いまこのeSIMカードで充分に遊んでおかないと、後になって後悔するかもしれません。
ということで調達しました、ワイモバイルのYM5G-eUICCnano(n162)カードがこちらです。見た目は普通のSIMカードですが、カード型のeUICCになっています。サービス開始時期的におそらくほぼ同じ仕様だと思われますので、ソフトバンクの方の調達は見送りました（誰かお願いします）。
ちなみに、商用のeUICCカードを取り扱うのは今回で三度目になります。ドコモeSIMカードVer.1およびeSIM.meについては、それぞれ下記の記事をご覧ください。個人的には、eSIM.meがおすすめです。
cheerio-the-bear.hatenablog.com
cheerio-the-bear.hatenablog.com
では、ワイモバイルのYM5G-eUICCnano(n162)カードについて書いてゆきます。
eSIM関係の掲示板を見ると「どうせ他の通信事業者のeSIMは入らないんでしょ？」みたいなコメントも書かれていましたが、いいえちゃんと入るんです。実際にpovoのeSIMを入れてみたときのスクリーンショットがこちらです。
ワイモバイル以外のeSIMの有効化・無効化の操作も問題ありません。また、いずれかのeSIMが有効化された状態のeSIMカードは従来のSIMカードと互換性がありますので、それを他のeSIM非対応端末に装着して使用することも可能です。
GoogleのPixel端末などには「SIMマネージャー」アプリがインストールされていますが、このeSIMカードに対応している端末にはその代わりに「eSIMカード情報設定」アプリが入っています。利用規約を見る限りでは、ソフトバンク内製のアプリのようです。
YM5G-eUICCnano(n162)カードには、2種類のeSIMがインストールされていました。ひとつめは、テスト用プロファイルです。GSMA TS.48に準拠しているもののようで、こちらは通常モードにおいては端末上に表示されることはありません。
| serviceProviderName | TS.48 |
|---|---|
| profileClass | Test (0) |
もうひとつがワイモバイルのeSIMプロファイルということになるのですが、何故かプロビジョニング用プロファイルとしてインストールされています。また、PPR2が設定されていることがわかります。
| serviceProviderName | Y!mobile |
|---|---|
| profileClass | Provisioning (1) |
| profilePolicyRules | ppr2 |
PPR1/PPR2の説明のため、GSMA SGP.22から下記の記述を引用します。まだ実際に試してはいないのですが、このeSIMはユーザーの操作によって削除することはできないようになっているようです。
PprIds ::= BIT STRING {-- Definition of Profile Policy Rules identifiers
pprUpdateControl(0), -- defines how to update PPRs via ES6
ppr1(1), -- Indicator for PPR1 'Disabling of this Profile is not allowed'
ppr2(2) -- Indicator for PPR2 'Deletion of this Profile is not allowed'
}ショップ店頭でのeSIMの開通手続きの様子を見ていないので定かではありませんが、YM5G-eUICCnano(n162)カードの製造時点でこの2種類のeSIMがインストールされていたのではと想像しています。
YM5G-eUICCnano(n162)カードのRAT (Rules Authorisation Table)には、特別な仕掛けはありません。MCC/MNC 'EEEEEE'はオールマイティですので、どの通信事業者にも同じルールが適用されます。また、PPRが設定されたeSIMをインストールする際には、ユーザーの同意を求めることになります。
| pprIds | ppr1, ppr2 |
|---|---|
| allowedOperators | mccMnc:EEEEEE, gid1:null, gid2:null |
| pprFlags | consentRequired |
そういえば、以前確認したドコモeSIMカード(Ver.1)には、下表のルールも記述されていました。例えば、ドコモのeSIMにPPR2が設定されていたとしても、そのインストールの際にユーザーの同意を求める必要はない、ということになるようです。
| pprIds | ppr1, ppr2 |
|---|---|
| allowedOperators | mccMnc:44F001, gid1:00FFFF, gid2:FFFFFF |
| pprFlags | N/A |
さすがに最近の標準仕様バージョンに準拠しているようですが、気になるところがふたつありました。ひとつめは、rspCapabilityの値。
| profileVersion | 2.3.1 |
|---|---|
| svn | 2.2.2 |
| uiccCapability | BIT STRING '077F36CB80' |
| ts102241Version | 9.2.0 |
| globalplatformVersion | 2.3.0 |
| rspCapability | BIT STRING '0192' |
| euiccCiPKIdListForVerification | '81370F5125D0B1D408D4C3B232E6D25E795BEBFB' |
| euiccCiPKIdListForSigning | '81370F5125D0B1D408D4C3B232E6D25E795BEBFB' |
| forbiddenProfilePolicyRules | pprUpdateControl, ppr1 |
| ppVersion | 0.0.1 |
| sasAcreditationNumber | GE-NG-UP-0621 |
GSMA SGP.22 v2.4では、rspCapabilityの各ビットについて下記のように説明されています。additionalProfileとtestProfileSupportに加えて(6)の位置の機能をサポートしているようですが、これを書いている時点で最新のv2.4仕様書にはその説明がまだありません。
RspCapability ::= BIT STRING {
additionalProfile(0), -- at least one more Profile can be installed
crlSupport(1), -- CRL
rpmSupport(2), -- Remote Profile Management
testProfileSupport (3), -- support for test profile
deviceInfoExtensibilitySupport (4), -- support for ASN.1 extensibility in the Device Info
serviceSpecificDataSupport (5) -- support for Service Specific Data in the Profile Metadata
}もうひとつは、sasAcreditationNumberとして表示されている"GE-NG-UP-0621"です。"GD-NG-UP-0621"ならSAS-UP認証済み施設として検索にも引っかかってくるのですが、これは誤記なんでしょうか。
参考までに、ドコモeSIMカード(Ver.1)の同情報も再掲します。こちらは証明書が残念でしたね。
| profileVersion | 2.0.0 |
|---|---|
| svn | 2.0.0 |
| uiccCapability | BIT STRING '067F36C0' |
| ts102241Version | 9.2.0 |
| globalplatformVersion | 2.2.1 |
| rspCapability | BIT STRING '0490' |
| euiccCiPKIdListForVerification | '137BD996CB67F5AAB8EDBD9850D651AACB952F0F' |
| euiccCiPKIdListForSigning | '137BD996CB67F5AAB8EDBD9850D651AACB952F0F' |
| forbiddenProfilePolicyRules | pprUpdateControl, ppr1 |
| ppVersion | 0.0.1 |
| sasAcreditationNumber | GD-NG-0617 |
世の中の SIM/UICC 好きの皆さま、取り外し可能なカード型の eUICC をお探しではないですか？先日ついにこの eSIM.me を見つけて、脊髄反射でポチっとやりました。ご覧ください、こちらが eSIM.me の eUICC カードです。1FF の半分のサイズのカードが、2FF/3FF/4FF 用にマルチカットされています。
ソフトバンクも同様のカードを三月中旬以降に提供とのことですが、対象機種が AQUOS R6 と BALMUDA Phone では手を出しづらいです。Android の eUICC フレームワークに準拠したかたちで LPA を搭載するのではと思っていますが、意外とこの eSIM.me と同じソリューションだったりするのかもです。
これで、趣味の eSIM が（何それ）捗ります。
SIM カードスロットを有する Android 端末を、eSIM 対応端末にすることができる商品です。eSIM.me より届けられる eUICC カードを Android 端末に装着し、eUICC を制御する LPA の役割を担う eSIM.me アプリを Google Play ストア経由でインストールすれば、セットアップ完了です。同アプリを使って QR コードをスキャンする等すれば、eSIM をダウンロード・インストールすることができるようになります。
SIM カードスロットが eUICC に置き換わるようなものなので、カードスロットが 2 つあるデュアル SIM 端末に eSIM.me カードを 2 枚させば、両方のスロットを eSIM に対応させることが可能です。また、近年の Google Pixel 端末のように元々 eSIM に対応している端末においても、SIM カードスロットにこの eSIM.me カードを装着して利用することができます。
こちらの eSIM.me サイトからオーダーし、およそ 10 日で自宅に届きました。
何らかの方法で（アカウント情報と EID を使ってとか？）使用可能なメーカーや機種の縛りをかけているようで、商品の種類は不自然な程に多いです。今回は、最も汎用的に使用可能な "eSIM.me Card for Android" を選択しています。予備としてもう一枚購入しておくかどうか迷います。だって、このビジネスを何年も続けてくれそうになくないですか？
以前 Android GSI をフラッシュした Google Pixel 4 がそのままほこりを被っていたので、それに eSIM.me アプリをプッシュして動作を確認しました。アクティベーションコードの入力については、QR コードのスキャンとマニュアル入力に対応しています。SM-DS は .. どうでしょうね。SM-DS で運用している eSIM 事業者があれば試してみたいところです。
ダウンロード中の表示がテストアプリ・サンプルアプリのそれのようで少し気になりますが、IIJ の eSIM を問題なくダウンロード・インストールできました。eSIM の ON/OFF 制御についても特に問題はないようです。
一方、楽天モバイルの eSIM のダウンロードには失敗しています。プロファイルパッケージデータの端末へのダウンロード自体は滞りなく完了していたようですので、実際のところは「インストールに失敗した」という表現が正しそうです。
eSIM.me の eUICC カードから返ってきたエラー情報がそのまま表示されているようで、原因は installFailedDueToPEProcessingError (12) とされています。楽天モバイルのプロファイルパッケージと eSIM.me の eUICC カードの間で、何らかの互換性の問題、仕様解釈の不一致のようなものが起きていることが予想されます。eSIM.me のサイト上でチケットを作成し、このエラーの発生について eSIM.me にレポート済みです。
2022/04/13 追記 : 次のバージョンのファームウェアで、この問題は解決されるそうです。市場投入は本年六月前後になるだろう、とのことでした。
eUICC フレームワークに沿うかたちで LPA を実装することを Android は想定していると思いますが、eSIM.me アプリ (= LPA) は Android OMAPI (Secure Element API) を通して UICC SE (この場合 eUICC カード) へのアクセスを実現しています。下記のログで、ISD-R の AID (a0000005591010ffffffff8900000100) を指定して論理チャネルを開いている様子を確認できます。
I/esim.me ( 5121): AndroidOmapiApi. Check isReaderAvailable : SIM1 I/SecureElement-Terminal-SIM1( 2133): ATR : 3b9f96803fc7828031e073fe211b57aa8660f0010004fb I/SecureElementService( 2133): openLogicalChannel() AID = a0000005591010ffffffff8900000100, P2 = 0 W/SecureElement-Terminal-SIM1( 2133): Enable access control on logical channel for esim.me I/SecureElement-AccessControlEnforcer( 2133): checkCommand() : Access = ALLOWED APDU Access = ALLOWED Reason = Unspecified I/SecureElement-Terminal-SIM1( 2133): Sent : 81cadf2000 I/SecureElement-Terminal-SIM1( 2133): Received : df20082618f36467f9a02d9000 I/SecureElement-AraController( 2133): Refresh tag unchanged. Using access rules from cache. I/SecureElement-AccessControlEnforcer( 2133): getAccessRule() appCert = 8d48ecfaf44c5752145ee28b3eb7429cc6627e98 I/SecureElement-AccessControlEnforcer( 2133): getAccessRule() appCert = a2afbbf5681bb26e40c8d69da6c72dd3a62cda7dbd74c5c2f26e7ff1fa819905 I/SecureElement-AccessRuleCache( 2133): findAccessRule() Case C REF_DO: AID_REF_DO: 4f00 Hash_REF_DO: c1148d48ecfaf44c5752145ee28b3eb7429cc6627e98 , com.android.se.security.ChannelAccess I/SecureElement-AccessRuleCache( 2133): [mPackageName=esim.me, mAccess=ALLOWED, mApduAccess=ALLOWED, mUseApduFilter=false, mApduFilter=null, mCallingPid=0, mReason=, mNFCEventAllowed=ALLOWED, mPrivilegeAccess=UNDEFINED] I/SecureElementService( 2133): openLogicalChannel() Success. Channel: 1
許可されていないアプリからのアクセス要求には Android OMAPI が拒否の応答を行うはずですが、なるほど eSIM.me アプリ（を含む）からのアクセス要求を受け付けるようにアクセスルールが設定されています。下記のログから、eSIM.me の ARA-M に設定されているアクセスルールの詳細を確認することができます。上のログにあった eSIM.me アプリの署名のハッシュ値 (SHA1 : 8d48ecfaf44c5752145ee28b3eb7429cc6627e98) が、ふたつ目のルールで全許可 (AID_REF_DO: 4f00) に設定されていますね。
I/SecureElement-Terminal-SIM1( 2108): Sent : 81caff4000 I/SecureElement-Terminal-SIM1( 2108): Received : ff4081b4e222e1184f00c114a4ec39717cecd7f1e84e913b22b0555fe7dfdd8ae306d00101d10101e222e1184f00c1148d48ecfaf44c5752145ee28b3eb7429cc6627e98e306d00101d10101e222e1184f00c11446bcaf2247253f695f19d60eece158099fe52c62e306d00101d10101e222e1184f00c114fa4abb42827a0fbceb891ddc0d34f658c21ff88ce306d00101d10101e222e1184f00c11435cc639bb5826fde0d0ef088b0f20cb69f0c49ade306d00101d101019000 I/SecureElement-AccessRuleCache( 2108): Add Access Rule: REF_DO: AID_REF_DO: 4f00 Hash_REF_DO: c114a4ec39717cecd7f1e84e913b22b0555fe7dfdd8a , com.android.se.security.ChannelAccess I/SecureElement-AccessRuleCache( 2108): [mPackageName=, mAccess=ALLOWED, mApduAccess=ALLOWED, mUseApduFilter=false, mApduFilter=null, mCallingPid=0, mReason=, mNFCEventAllowed=ALLOWED, mPrivilegeAccess=UNDEFINED] I/SecureElement-AccessRuleCache( 2108): Add Access Rule: REF_DO: AID_REF_DO: 4f00 Hash_REF_DO: c1148d48ecfaf44c5752145ee28b3eb7429cc6627e98 , com.android.se.security.ChannelAccess I/SecureElement-AccessRuleCache( 2108): [mPackageName=, mAccess=ALLOWED, mApduAccess=ALLOWED, mUseApduFilter=false, mApduFilter=null, mCallingPid=0, mReason=, mNFCEventAllowed=ALLOWED, mPrivilegeAccess=UNDEFINED] I/SecureElement-AccessRuleCache( 2108): Add Access Rule: REF_DO: AID_REF_DO: 4f00 Hash_REF_DO: c11446bcaf2247253f695f19d60eece158099fe52c62 , com.android.se.security.ChannelAccess I/SecureElement-AccessRuleCache( 2108): [mPackageName=, mAccess=ALLOWED, mApduAccess=ALLOWED, mUseApduFilter=false, mApduFilter=null, mCallingPid=0, mReason=, mNFCEventAllowed=ALLOWED, mPrivilegeAccess=UNDEFINED] I/SecureElement-AccessRuleCache( 2108): Add Access Rule: REF_DO: AID_REF_DO: 4f00 Hash_REF_DO: c114fa4abb42827a0fbceb891ddc0d34f658c21ff88c , com.android.se.security.ChannelAccess I/SecureElement-AccessRuleCache( 2108): [mPackageName=, mAccess=ALLOWED, mApduAccess=ALLOWED, mUseApduFilter=false, mApduFilter=null, mCallingPid=0, mReason=, mNFCEventAllowed=ALLOWED, mPrivilegeAccess=UNDEFINED] I/SecureElement-AccessRuleCache( 2108): Add Access Rule: REF_DO: AID_REF_DO: 4f00 Hash_REF_DO: c11435cc639bb5826fde0d0ef088b0f20cb69f0c49ad , com.android.se.security.ChannelAccess I/SecureElement-AccessRuleCache( 2108): [mPackageName=, mAccess=ALLOWED, mApduAccess=ALLOWED, mUseApduFilter=false, mApduFilter=null, mCallingPid=0, mReason=, mNFCEventAllowed=ALLOWED, mPrivilegeAccess=UNDEFINED]
eSIM をダウンロードする前の eUICC でも、必要最低限のファイルシステムを端末側に見せる必要があります。GSMA SGP.22 の規定では MF と極少数の EF を設ければ良いことになっていますが、eSIM.me カードのデフォルトファイルシステムには DIR や ICCID、IMSI、MSISDN 等も存在します。デフォルトファイルシステムというか、それをひとつのデフォルトプロファイルとして実装しているようです。空の状態でプロファイルのリストを要求すると、以下のログのようにプロファイルがひとつ返ってきます。
I/esim.me ( 5121): AndroidOmapiApi. execute APDU command :81E2910003BF2D00
I/SecureElement-AccessControlEnforcer( 2133): checkCommand() : Access = ALLOWED APDU Access = ALLOWED Reason = Unspecified
I/SecureElement-Terminal-SIM1( 2133): Sent : 81e2910003bf2d00
I/SecureElement-Terminal-SIM1( 2133): Received : 613e
I/SecureElement-Terminal-SIM1( 2133): Sent : 81c000003e
I/SecureElement-Terminal-SIM1( 2133): Received : bf2d3ba039e3375a0aXXXXXXXXXXXXXXXXXXXX4f10a0000005591010ffffffff89000012009f70010191076553494d2e6d6592076553494d2e6d659501019000
I/esim.me ( 5121): AndroidOmapiApi. received APDU response :BF2D3BA039E3375A0AXXXXXXXXXXXXXXXXXXXX4F10A0000005591010FFFFFFFF89000012009F70010191076553494D2E6D6592076553494D2E6D659501019000
I/esim.me ( 5121): Profile list object: profileInfoListOk: {
I/esim.me ( 5121): {
I/esim.me ( 5121): iccid: XXXXXXXXXXXXXXXXXXXX,
I/esim.me ( 5121): isdpAid: A0000005591010FFFFFFFF8900001200,
I/esim.me ( 5121): profileState: 1,
I/esim.me ( 5121): serviceProviderName: eSIM.me,
I/esim.me ( 5121): profileName: eSIM.me,
I/esim.me ( 5121): profileClass: 1
I/esim.me ( 5121): }
I/esim.me ( 5121): }MCC/MNC のペアは 262/24 でした。
参考までに、EuiccInfo2 を読みだしているログもここに貼ります。
I/esim.me ( 5121): AndroidOmapiApi. execute APDU command :81E2910003BF2200
I/SecureElement-AccessControlEnforcer( 2133): checkCommand() : Access = ALLOWED APDU Access = ALLOWED Reason = Unspecified
I/SecureElement-Terminal-SIM1( 2133): Sent : 81e2910003bf2200
I/SecureElement-Terminal-SIM1( 2133): Received : 617b
I/SecureElement-Terminal-SIM1( 2133): Sent : 81c000007b
I/SecureElement-Terminal-SIM1( 2133): Received : bf2278810302010282030202008303040200840d81010082040007701e830239b68503017f3a8603090200870302030088020490a916041481370f5125d0b1d408d4c3b232e6d25e795bebfbaa16041481370f5125d0b1d408d4c3b232e6d25e795bebfb8b010004030100000c0d45442d5a492d55502d303832329000
I/esim.me ( 5121): AndroidOmapiApi. received APDU response :BF2278810302010282030202008303040200840D81010082040007701E830239B68503017F3A8603090200870302030088020490A916041481370F5125D0B1D408D4C3B232E6D25E795BEBFBAA16041481370F5125D0B1D408D4C3B232E6D25E795BEBFB8B010004030100000C0D45442D5A492D55502D303832329000
I/esim.me ( 5121): - EUICC info 2 is: {
I/esim.me ( 5121): profileVersion: 020102,
I/esim.me ( 5121): svn: 020200,
I/esim.me ( 5121): euiccFirmwareVer: 040200,
I/esim.me ( 5121): extCardResource: 81010082040007701E830239B6,
I/esim.me ( 5121): uiccCapability: 011111110011101,
I/esim.me ( 5121): javacardVersion: 090200,
I/esim.me ( 5121): globalplatformVersion: 020300,
I/esim.me ( 5121): rspCapability: 1001,
I/esim.me ( 5121): euiccCiPKIdListForVerification: {
I/esim.me ( 5121): 81370F5125D0B1D408D4C3B232E6D25E795BEBFB
I/esim.me ( 5121): },
I/esim.me ( 5121): euiccCiPKIdListForSigning: {
I/esim.me ( 5121): 81370F5125D0B1D408D4C3B232E6D25E795BEBFB
I/esim.me ( 5121): },
I/esim.me ( 5121): euiccCategory: 0,
I/esim.me ( 5121): ppVersion: 010000,
I/esim.me ( 5121): sasAcreditationNumber: ED-ZI-UP-0822
I/esim.me ( 5121): }SAS-UP の認定番号が ED-ZI-UP-0822 とのことで、中国の "Eastcompeace" というスマートカードベンダによって製造されているカードのようです。
iPhone 13では新たに「デュアルeSIM」がサポートされ、eSIMだけで（物理的なSIMカードを装着することなく）２回線を同時に利用できるようになりました。思ったよりも数は多くないという印象ですが、ネットメディアの記事でも「デュアルeSIM」が取り上げられ、概ね好意的に受け入れられているようです。日本でも大手の通信事業者からeSIMが提供されるようになりましたし、SIMカードからeSIMへの移行をほんの少し加速させるのではないでしょうか。
残念なのは、eSIMプロファイルを２つだけダウンロード・インストールして満足している記事が多く見受けられることです。「デュアルeSIM」なんだから、eSIMだけで２回線を同時に利用できることを確認すれば良いだろう。そう考えてのことだと思われますが、iPhone 13が実現した「デュアルeSIM」の注目すべきポイントは、（マニアの観点では）そこではありません。
今回Appleは、GSMA SGP.21で規定されている下記の要件によるプロファイル数の上限設定を、何らかの方法を使って飛び越えています。
| EUICC6 | At a maximum, only one Profile SHALL be enabled at any point in time. |
検証のため、下記の４種類のeSIMプロファイルを契約してiPhone 13にダウンロードしてみました。ダウンロード手続きそのものに特筆すべきものは無く、また「どちらのeUICCにダウンロードしますか？」といったようなユーザーへの確認を求められることもありませんでした。「デュアルeSIM」だからといって、iPhone 13がeUICCを複数持っているとは考えにくいです。
この４種類のeSIMプロファイルの中から「デュアルeSIM」に利用する２つを選択する場合、その組み合わせは６通りあります。実際にその６通りを試してみましたが、下のスクリーンショットの在圏表示を見てわかるように、全ての組み合わせを問題なく選択することが可能です。試せてはいないですが、プロファイルの数を更に増やしたとしても、同じ結果になることが予想されます。
eUICCひとつあたり「同時に有効化できるプロファイルの数はひとつまで」という制限に縛られていては、（もしeUICCを４つ載せているならその限りではありませんが）これを実現することはできません。例えば、RakutenとIIJのプロファイルが同一のeUICCにダウンロードされている場合、従来の（というか現行の通常の）eUICCではその２つを同時に使用することはできません。「デュアルeSIM」だからといって、eUICCを２つ搭載すれば良いというわけではないということです。
GSMA SGP.21の現行仕様では実現できない機能を実装し、業界に先駆けてそれを商用化しているものと思われます。SIMカードレスに向かう流れはきっと進行してゆくことでしょうし、さすがはAppleといった感じです。
