NFC 機能を提供する Android デバイスの多くは、すでに NFC をサポートしています カード エミュレーション。ほとんどの場合、カードは別のチップによってエミュレートされます。 セキュア エレメントと呼ばれるデバイスです。携帯通信会社が提供する多くの SIM カード セキュア エレメントも含まれます。
Android 4.4 以降では、カード エミュレーションのための追加の方法が提供されます。 ホストベースのカード エミュレーションと呼ばれるセキュア エレメントを使用しない。この 任意の Android アプリでカードをエミュレートして NFC と直接通信可能 読み取りますこのトピックでは、ホストベースのカード エミュレーション(HCE)の動作について説明します。 使用して NFC カードをエミュレートするアプリの開発方法についても 手法です。
セキュア エレメントを使用したカード エミュレーション
セキュア エレメントを使用して NFC カード エミュレーションを提供する場合、 エミュレートされた ID が、Android デバイスを介してデバイス上のセキュア エレメントにプロビジョニングされます。 説明します。ユーザーがデバイスを NFC 端末にかざすと、 コントローラにより、すべてのデータがリーダーから安全な 要素です。図 1 に、このコンセプトを示します。
図 1. セキュア エレメントを使用した NFC カード エミュレーション
セキュア エレメント自体が NFC 端末と通信する トランザクションに Android アプリは関与しません。取引の完了後 完了すると、Android アプリはセキュア エレメントに対して直接、 取引ステータスを表示し、ユーザーに通知します。
ホストベースのカード エミュレーション
ホストベースのカード エミュレーションを使用して NFC カードをエミュレートすると、データは セキュア エレメントにルーティングされることなく直接ホスト CPU にルーティングされます。図 2 ホストベースのカード エミュレーションの仕組みを示しています。
図 2. セキュア エレメントを使用しない NFC カード エミュレーション
サポートされている NFC カードとプロトコル
図 3. Android の HCE プロトコル スタック
NFC 規格はさまざまなプロトコルをサポートしています。 さまざまなタイプのカードがエミュレートできます。
Android 4.4 以降では、市場で一般的に使用されている複数のプロトコルをサポートしています。
今すぐ始めましょう。既存の非接触型カードの多くは、すでにこれらのプロトコルに基づいています。
キャッシュレスの決済カードなども含まれますこれらのプロトコルは、
現在市場で販売されている NFC リーダー(
(IsoDep
を参照)
クラス)。これにより、エンドツーエンドの NFC ソリューションを構築してデプロイできます。
Android 搭載デバイスのみを使用する HCE。
具体的には、Android 4.4 以降では、以下をベースとするカードのエミュレートがサポートされています。 NFC-Forum ISO-DEP 仕様(ISO/IEC 14443-4 に基づく)とプロセス ISO/IEC 7816-4 で定義されている Application Protocol Data Unit(APDU) 仕様。Android では、NFC-A 上でのみ ISO-DEP をエミュレートすることが義務付けられています (ISO/IEC 14443-3 Type A)の規格に準拠しています。Nfc-B(ISO/IEC 14443-4 Type B)をサポート オプションです。図 3 では、これらすべてのレイヤが階層化されています。 仕様。
HCE サービス
Android の HCE アーキテクチャは Android をベースとしている
Service
コンポーネント(HCE)
サービス)。サービスの主なメリットの 1 つは、
バックグラウンドで実行することもできます。これは、多くの HCE に無理なく適合します。
ポイントカードや交通機関のカードなどのアプリで利用できますが、ユーザーが
使用するアプリを起動します。デバイスを NFC リーダーにかざすと、
正しいサービス(まだ実行されていない場合、トランザクションを実行する場合)
確認できます。もちろん、追加の UI(
ユーザー通知など)を適宜配信する必要があります。
サービスの選択
ユーザーがデバイスを NFC リーダーにタップしたとき、Android システムは NFC リーダーが通信する HCE サービスを指定します。ISO/IEC 7816-4 仕様では、アプリケーションの選択方法が定義されています。 アプリケーション ID(AID)。AID は最大 16 バイトで構成されます。エミュレートしている場合、 既存の NFC リーダー インフラストラクチャのカード、それらのリーダーが使用している AID 一般的に、よく知られていて公的に登録されているもの(例: Visa や MasterCard などの決済ネットワークの AID)。
独自のアプリケーション用に新しいリーダー インフラストラクチャをデプロイする場合は、 独自の AID を登録する必要があります。AID の登録手順は、 ISO/IEC 7816-5 仕様に準拠しています7816-5 に従って AID を登録することをおすすめします。 Android 向け HCE アプリをデプロイすると、競合を回避できる 統合できます
AID グループ
場合によっては、HCE サービスは複数の AID を登録し、 特定の AID を実装するために、すべての AID のデフォルト ハンドラを 説明します。グループ内の一部の AID が他のサービスに送信されることはサポートされていません。
まとめて管理される AID のリストは、AID グループと呼ばれます。1 つのモードのすべての AID は、 AID グループの場合、Android は次のいずれかを保証します。
- グループ内のすべての AID は、この HCE サービスにルーティングされます。
- グループ内の AID はこの HCE サービスにルーティングされません(たとえば、 ユーザーが別のサービスを選択したため、グループ内の 1 つ以上の AID がリクエストされました できます)。
つまり、グループ内の一部の AID に それぞれ別の HCE サービスにルーティングできます。
AID グループとカテゴリ
各 AID グループはカテゴリに関連付けることができます。これにより、Android は HCE をカテゴリ別に分類することで、ユーザーが デフォルトで AID レベルではなくカテゴリレベルで設定されます。AID に言及しない アプリケーションのユーザー向け部分で使用しても、 平均的なユーザーはそれほど多くありません
Android 4.4 以降では、次の 2 つのカテゴリがサポートされています。
CATEGORY_PAYMENT
(業界標準の決済アプリをカバー)CATEGORY_OTHER
(他のすべての HCE アプリの場合)
HCE サービスを実装する
ホストベースのカード エミュレーションを使用して NFC カードをエミュレートするには、
NFC トランザクションを処理する Service
コンポーネント。
HCE のサポートを確認する
アプリは、デバイスが HCE をサポートしているかどうかを確認するには、
FEATURE_NFC_HOST_CARD_EMULATION
機能。<uses-feature>
を使用する
タグを使用して、アプリが HCE を使用することを宣言します。
その機能がアプリの機能に必須かどうかです。
サービスの実装
Android 4.4 以降では、便利な Service
クラスを使用できます。
HCE サービスを実装するための基礎として、
HostApduService
クラス。
まず、次のコードに示すように、HostApduService
を拡張します。
サンプル:
Kotlin
class MyHostApduService : HostApduService() { override fun processCommandApdu(commandApdu: ByteArray, extras: Bundle?): ByteArray { ... } override fun onDeactivated(reason: Int) { ... } }
Java
public class MyHostApduService extends HostApduService { @Override public byte[] processCommandApdu(byte[] apdu, Bundle extras) { ... } @Override public void onDeactivated(int reason) { ... } }
HostApduService
は、オーバーライドする必要がある 2 つの抽象メソッドを宣言し、
説明します。そのうちの 1 つは
processCommandApdu()
NFC リーダーがアプリケーション プロトコル データ ユニット(APDU)を送信するたびに呼び出される
追加できますAPDU は、ISO/IEC 7816-4 仕様で定義されています。APDU
NFC リーダーと NFC の間で送受信されるアプリ レベルのパケット
必要があります。そのアプリケーション レベルのプロトコルは半二重通信です。NFC リーダーは
コマンド APDU を送信し、ユーザーが応答 APDU を送信するのを
戻ります。
前述のように、Android は AID を使用して、リクエストする HCE サービスを
答える必要があります。通常、NFC リーダーが
デバイスは SELECT AID
APDU である。この APDU には読者が希望する AID が含まれている
あります。Android が APDU からその AID を抽出し、HCE に解決する
その APDU を解決済みサービスに転送します。
レスポンスの APDU を送信するには、レスポンスの APDU のバイトを
processCommandApdu()
。このメソッドはメインスレッドで呼び出されます。
ブロックできません。計算ができない場合に
返す場合は null を返します。その後、必要な作業を
別のスレッドに移動し、
sendResponseApdu()
HostApduService
クラスで定義されているメソッドを使用して、レスポンスを
できます。
Android は、次のいずれかの状態になるまで、リーダーからサービスに新しい APDU を転送し続けます。 次の処理が行われます。
- NFC リーダーが別の
SELECT AID
APDU を送信し、OS がそれを あります。 - NFC リーダーとデバイスとの間の NFC リンクが切断される。
どちらの場合も、クラスの
onDeactivated()
どちらが発生したかを示す引数を指定して実装が呼び出されます。
既存のリーダー インフラストラクチャを使用する場合は、 既存のアプリケーション レベルのプロトコルを HCE サービスで読み込む必要があります。
自社が管理する新しいリーダー インフラストラクチャをデプロイする場合は、 独自のプロトコルと APDU シーケンスを定義できます。APDU の数を制限してみる やり取りするデータのサイズを指定します。これにより、 デバイスを NFC リーダーに短時間かざします。 データの妥当な上限は約 1 KB です。これは通常、 300 ミリ秒以内に交換されます。
マニフェストでのサービスの宣言と AID の登録
通常どおりマニフェストでサービスを宣言する必要がありますが、いくつかの点を 次の要素を追加します。
HCE サービスであることをプラットフォームに伝えるために、
HostApduService
インターフェースを使用するには、次のインテントのインテント フィルタをSERVICE_INTERFACE
アクションを追加します。このサービスからどの AID グループがリクエストされるかをプラットフォームに伝えるには、
SERVICE_META_DATA
サービスの宣言の<meta-data>
タグ(XML を指す) リソースで HCE サービスに関する追加情報を確認してください。android:exported
属性をtrue
に設定し、android.permission.BIND_NFC_SERVICE
権限をサービスの宣言で追加してください。 前者は、外部アプリケーションがそのサービスにバインドできるようにするためのものです。 後者では、IP アドレスを保持する外部アプリケーションのみがandroid.permission.BIND_NFC_SERVICE
権限をサービスにバインドできます。android.permission.BIND_NFC_SERVICE
はシステム権限であるため、 Android OS のみがサービスにバインドできる設定を効果的に強制適用できます。
HostApduService
マニフェストの宣言の例を次に示します。
<service android:name=".MyHostApduService" android:exported="true" android:permission="android.permission.BIND_NFC_SERVICE"> <intent-filter> <action android:name="android.nfc.cardemulation.action.HOST_APDU_SERVICE"/> </intent-filter> <meta-data android:name="android.nfc.cardemulation.host_apdu_service" android:resource="@xml/apduservice"/> </service>
この meta-data タグでは apduservice.xml
ファイルを指定します。以下は、
2 つの AID グループ宣言を含む 1 つの AID グループ宣言があるファイルの例
独自の AID:
<host-apdu-service xmlns:android="http://schemas.android.com/apk/res/android" android:description="@string/servicedesc" android:requireDeviceUnlock="false"> <aid-group android:description="@string/aiddescription" android:category="other"> <aid-filter android:name="F0010203040506"/> <aid-filter android:name="F0394148148100"/> </aid-group> </host-apdu-service>
<host-apdu-service>
タグには <android:description>
属性を含める必要があります
サービスにわかりやすい説明を
表示できます。requireDeviceUnlock
属性を使用して、
APDU を処理するためにこのサービスを呼び出す前にデバイスのロックが解除されていること。
<host-apdu-service>
には <aid-group>
タグを含める必要があります。各
次の操作を行うには、<aid-group>
タグが必要です。
- ユーザー フレンドリーな属性の
android:description
属性が含まれている AID グループの説明。UI での表示に適しています。 - AID のカテゴリを示す
android:category
属性を設定する グループ(CATEGORY_PAYMENT
で定義された文字列定数など) またはCATEGORY_OTHER
。 - それぞれ 1 つの AID を含む
<aid-filter>
タグを 1 つ以上含めます。 AID を 16 進数形式で指定し、必ず偶数が含まれるようにします。 あります。
また、アプリケーションは
NFC
権限(以下として登録する)
HCE サービス。
AID の競合の解決
1 台のデバイスに複数の HostApduService
コンポーネントをインストールできます。
同じ AID を複数のサービスに登録できます。Android が AID を解決
AID がどのカテゴリに属するかによって、競合は異なります。各
競合解決ポリシーが異なる場合があります。
支払いなどの一部のカテゴリでは、ユーザーがデフォルトの
Android の設定 UI で確認できます。その他のカテゴリの場合、ポリシーは
競合が発生した場合に呼び出すサービスを常にユーザーに確認します。詳細情報
特定のカテゴリの競合解決ポリシーをクエリする方法については、
getSelectionModeForCategory()
。
サービスがデフォルトかどうかを確認する
アプリケーションは、その HCE サービスがサービスのデフォルト サービスとして
特定のカテゴリを選択して
isDefaultServiceForCategory()
API
サービスがデフォルトでない場合は、デフォルトに設定するようリクエストできます
ACTION_CHANGE_DEFAULT
。
決済アプリ
Android では、 payment カテゴリを支払いアプリケーションとして指定します。Android 4.4 以降には、 最上位の設定メニュー エントリである「タップ &」payという 決済アプリなどですこの設定メニューで 決済デバイスがタップされたときに呼び出すデフォルトの決済アプリケーション。
決済アプリに必要なアセット
より視覚に訴えるユーザー エクスペリエンスを提供するため、HCE 決済アプリケーションは サービスバナーを表示する必要があります
Android 13 以降
設定 UI のデフォルトの支払い選択リストに合うように、 正方形のアイコンに変更する必要があります。理想的には、 アプリケーション ランチャー アイコンのデザイン。この調整により整合性が高まり、 見た目もすっきりします
Android 12 以前
サービスバナーのサイズを 260x96 dp に設定し、サービスバナーのサイズを設定する
android:apduServiceBanner
属性をメタデータ XML ファイルに追加することで、
ドローアブル リソースを指す <host-apdu-service>
タグ。「
次に例を示します。
<host-apdu-service xmlns:android="http://schemas.android.com/apk/res/android" android:description="@string/servicedesc" android:requireDeviceUnlock="false" android:apduServiceBanner="@drawable/my_banner"> <aid-group android:description="@string/aiddescription" android:category="payment"> <aid-filter android:name="F0010203040506"/> <aid-filter android:name="F0394148148100"/> </aid-group> </host-apdu-service>
画面オフとロック画面の動作
HCE サービスの動作は、搭載されている Android のバージョンによって異なります。 クリックします。
Android 12 以降
Android 12(API レベル 31)以降をターゲットとするアプリでは、NFC を有効にできます。
設定することで、デバイスの画面がオンにならなくても
requireDeviceScreenOn
~
false
。
Android 10 以降
Android 10(API レベル 29)以降を搭載しているデバイスは
安全性
NFC。セキュリティを確保
NFC がオンになっており、すべてのカード エミュレータ(ホスト アプリケーションとオフホスト アプリケーション)が
使用できません。セキュア NFC が OFF のとき、オフホスト
デバイスの画面がオフのときにも使用できます。以下を確認できます:
セキュア NFC サポート:
isSecureNfcSupported()
。
Android 10 以降を搭載したデバイスでは、
デバイスと同様に、android:requireDeviceUnlock
~true
が適用されます
Android 9 以前を搭載している Android デバイス(セキュア NFC がオフになっている場合のみ)つまり
セキュア NFC がオンになっています。HCE サービスはロック画面から機能しません
android:requireDeviceUnlock
の設定に関係なく適用されます。
Android 9 以前
Android 9(API レベル 28)以前を搭載しているデバイスでは、NFC コントローラと 画面の表示が消えたとき、アプリケーション プロセッサは デバイスの電源がオフになっています。そのため、画面がオフのときは HCE サービスが機能しません。
また、Android 9 以前では、ロック画面から HCE サービスを機能させることができます。
ただし、これは android:requireDeviceUnlock
属性によって制御されます。
HCE サービスの <host-apdu-service>
タグ。デフォルトでは、デバイスのロック解除は
不要で、デバイスがロックされていてもサービスが呼び出されます。
HCE で android:requireDeviceUnlock
属性を true
に設定する場合
サービスでは、次のような場合に、デバイスのロックを解除するよう求めるメッセージがユーザーに表示されます。
目的:
- ユーザーが NFC リーダーをタップしたとき。
- NFC リーダーが、サービスに解決される AID を選択します。
ロックを解除すると、再度タップして トランザクションを完了します。これは、ユーザーが NFC リーダーから離して、ロックを解除します。
セキュア エレメント カードとの共存
このセクションは、アプリケーションをデプロイしているデベロッパーを対象としています カード エミュレーションにセキュア エレメントを使用するアプリの場合です。Android の HCE 実装 は、カードを実装する他のメソッドと並行して動作するように設計されています。 エミュレーションによって保護されています。
この併用は、AID ルーティングと呼ばれる原則に基づいています。NFC コントローラが、ルーティング テーブルを保持します。このテーブルは、有限の できます。各ルーティングルールには AID と宛先が含まれます。宛先は Android アプリが実行されているホスト CPU、または 要素です。
NFC リーダーが SELECT AID
を含む APDU を送信すると、NFC コントローラは
その AID がルーティング テーブル内のいずれかの AID と一致するかどうかを確認します。もし
一致した場合は、その APDU とそれに続くすべての APDU が宛先
(別の SELECT AID
APDU を受信するか、NFC が応答するまで)
リンクが機能しない。
図 4 に、このアーキテクチャを示します。
図 4. セキュア エレメントとホストカード エミュレーションの両方で動作する Android。
通常、NFC コントローラは APDU のデフォルト ルートも含んでいます。特定の AID がルーティング テーブルに見つからない場合は、デフォルト ルートが使用されます。この デバイスによって異なる場合があります。Android デバイスが必要です。 アプリが登録されている AID が ホストします。
HCE サービスを実装する Android アプリ、またはセキュア エレメントを使用する Android アプリ ルーティングテーブルの構成について 気にする必要はありません処理 Android 搭載。Android 側で必要なのは、処理可能な AID を認識することだけです セキュア エレメントで処理できるものを指定します。ルーティング インストールされているサービスに基づいて自動的に構成され、 ユーザーが優先として設定した広告です
次のセクションでは、 カード エミュレーション用のセキュア エレメントです。
セキュア エレメントの AID の登録
カード エミュレーションにセキュア エレメントを使用するアプリは、 オフホスト サービスをマニフェストで指定する必要があります。このようなサービスの宣言は、 これは HCE サービスの宣言とほぼ同じです。例外は次のとおりです。 次のようになります。
- インテント フィルタで使用するアクションは、
SERVICE_INTERFACE
。 - meta-data の name 属性を
SERVICE_META_DATA
。 メタデータの XML ファイルでは、
<offhost-apdu-service>
ルートタグを使用する必要があります。<service android:name=".MyOffHostApduService" android:exported="true" android:permission="android.permission.BIND_NFC_SERVICE"> <intent-filter> <action android:name="android.nfc.cardemulation.action.OFF_HOST_APDU_SERVICE"/> </intent-filter> <meta-data android:name="android.nfc.cardemulation.off_host_apdu_service" android:resource="@xml/apduservice"/> </service>
対応する apduservice.xml
ファイルの例を次に示します。
2 つの AID を登録する:
<offhost-apdu-service xmlns:android="http://schemas.android.com/apk/res/android" android:description="@string/servicedesc"> <aid-group android:description="@string/subscription" android:category="other"> <aid-filter android:name="F0010203040506"/> <aid-filter android:name="F0394148148100"/> </aid-group> </offhost-apdu-service>
android:requireDeviceUnlock
属性はオフホスト サービスには適用されません。
これは、ホスト CPU がトランザクションに関与していないため、
セキュア エレメントはトランザクションを実行することを阻止します。
ロックされています。
オフホスト サービスでは android:apduServiceBanner
属性が必要です
デフォルトの決済アプリに
説明します。
オフホスト サービスの呼び出し
Android は、「オフホスト」と宣言されたサービスを開始したり、バインドしたりすることはありません。 実際のトランザクションはセキュア エレメントによって実行され、 呼び出すことができます。Service の宣言では、アプリが セキュア エレメントに存在する AID を登録します。
HCE とセキュリティ
HCE アーキテクチャは、セキュリティのコア部分の 1 つを提供します。
保護されているとは限りません。
BIND_NFC_SERVICE
サービスにバインドして通信できるのは OS のみです。
これにより、受信する APDU が実際には
APDU を NFC コントローラから
そして OS が APDU を NFC コントローラに直接転送します。
最後の懸念事項は、アプリが送信するデータをどこで取得するかです。 渡します。HCE の設計では、これは意図的に分離されています。はい データの出所は気にせず データが安全に NFC コントローラに送られ、NFC リーダーに送出されます。
HCE から送信するデータを安全に保存、取得するため たとえば、Android Application Sandbox を使用することができます。 アプリのデータを他のアプリから分離します。Android の詳細については、 セキュリティについては、セキュリティに関するヒントをご覧ください。
プロトコル パラメータと詳細
このセクションは、どのプロトコルを使用するかを知りたいデベロッパーを対象としています HCE デバイスが衝突防止と有効化のフェーズで使用するパラメータ NFC プロトコルをサポートしています。これにより、読み取り用インフラストラクチャを Android HCE デバイスに対応しています。
NFC-A(ISO/IEC 14443 Type A)プロトコルの衝突防止と有効化
NFC-A プロトコルの有効化の一環として、複数のフレームが交換されます。
交換の最初の部分では、HCE デバイスは UID を提示します。HCE デバイス ランダムな UID を持つものとする。つまり、タップするたびに UID が ランダムに生成された UID ですそのため NFC リーダーは、HCE デバイスの UID に依存すべきではありません。 認証や識別のためのプロセスです
NFC リーダーは、SEL_REQ
を送信して HCE デバイスを選択できます。
使用できます。HCE デバイスの SEL_RES
レスポンスに 6 ビット目以上がある
(0x20)設定され、デバイスが ISO-DEP をサポートしていることを示します。なお、
SEL_RES
も設定でき、たとえば NFC-DEP がサポートされることを示します。
(p2p)プロトコルで暗号化されます。他のビットが設定されている可能性があるため、
HCE デバイスは 6 番目のビットのみを明示的にチェックし、比較は行わない
値が 0x20 の完全な SEL_RES
。
ISO-DEP の有効化
Nfc-A プロトコルが有効になったら、NFC リーダーが ISO-DEP を開始します。 プロトコル アクティベーション。RATS(Request for Answer To Select)を送信します。 使用できます。NFC コントローラが、RATS 応答である ATS を生成します。ATS は HCE サービスで構成できます。ただし、HCE の実装は NFC フォーラムを満たしている必要があります 必要があります。これにより、NFC リーダーはこれらのパラメータを信頼できます。 すべての HCE デバイスに関する NFC フォーラムの要件に従って設定されている。
以下のセクションでは、ATS の個々のバイトについて詳しく説明します。 HCE デバイス上の NFC コントローラから返されるレスポンスは次のようになります。
- TL: ATS 応答の長さ。20 を超える長さを指定することはできません あります。
- T0: すべての HCE デバイスでビット 5、6、7 を設定する必要がある。これは、TA(1)、TB(1) であることを示す および TC(1) が ATS 応答に含まれる。ビット 1 ~ 4 は FSCI、 渡します。HCE デバイスでは、FSCI の値を 0h ~ 8h の間で指定します
- T(A)1: リーダーとエミュレータ間のビットレート、およびそれらのビットレートが 非対称ですHCE デバイスに対するビットレートの要件または保証はありません。
- T(B)1: ビット 1~4 は、開始フレーム保護時間整数値(SFGI)を示します。オン HCE デバイスでは、SFGI は 8 時間以下である必要があります。ビット 5 ~ 8 はフレーム待機中を示す time 整数(FWI)で、フレーム待機時間(FWT)をコード化します。HCE デバイスでは、FWI 8h 以下であることが必要です。
- T(C)1: ビット 5 は、「高度なプロトコル機能」のサポート状況を示します。HCE デバイス 「高度なプロトコル機能」に対応している場合とできない場合があります。ビット 2 はサポートを示します あります。HCE デバイスでは DID をサポートしている場合と、サポートしていない場合とがあります。ビット 1 は、 NAD。HCE デバイスでは NAD をサポートしてはならないため、ビット 1 はゼロに設定してください。
- ヒストリカル バイト: HCE デバイスは、最大 15 バイトのヒストリカル バイトを返すことがあります。NFC HCE サービスを利用する場合は、 履歴バイトの内容やその存在を検出できます。
多くの HCE デバイスは、プロトコル要件に準拠している可能性があります。 EMVCo に統合されている決済ネットワークが「非接触型決済 通信プロトコル」仕様。具体的には、次のとおりです。
- T0 の FSCI は 2h~8h の間でなければならない。
- T(A)1 は、106 kbit/s のビットレートのみを示す 0x80 に設定する必要があります。 非対称ビットレートはサポート対象外です。 サポートされません。
- T(B)1 の FWI は 7h 以下である必要がある。
APDU データの交換
前述のように、HCE 実装は単一の論理チャンネルのみをサポートします。 異なる論理チャネルでアプリケーションを選択しようとしても動作しない HCE デバイスが必要です