ホストベースのカード エミュレーションの概要

NFC 機能を備えている Android 搭載デバイスの多くは、すでに NFC カード エミュレーションをサポートしています。ほとんどの場合、カードはセキュア エレメントと呼ばれる、デバイス内の個別のチップによってエミュレートされます。携帯通信会社が提供する多くの SIM カードにもセキュア エレメントが含まれています。

Android 4.4 以降では、セキュア エレメントを必要としないカード エミュレーション方法(ホストベースのカード エミュレーションと呼ばれます)が追加で提供されています。これにより、どの Android アプリもカードをエミュレートし、NFC リーダーと直接通信できます。このトピックでは、Android でのホストベース カード エミュレーション(HCE)の仕組みと、この手法を使用して NFC カードをエミュレートするアプリを開発する方法について説明します。

セキュア エレメントを使用したカード エミュレーション

セキュア エレメントを使用して NFC カード エミュレーションが提供される場合、エミュレートするカードは Android アプリを介してデバイス上のセキュア エレメントにプロビジョニングされます。ユーザーが NFC 端末にデバイスをかざすと、デバイスの NFC コントローラが、リーダーからのすべてのデータを直接セキュア エレメントに転送します。図 1 は、このコンセプトを示しています。

NFC リーダーが NFC コントローラを通過してセキュア エレメントから情報を取得する図
図 1. セキュア エレメントを使用した NFC カード エミュレーション

セキュア エレメント自体が NFC 端末との通信を実行しますが、Android アプリはトランザクションに関与しません。トランザクションの完了後、Android アプリはセキュア エレメントに対してトランザクションのステータスを直接照会し、ユーザーに通知できます。

ホストベースのカード エミュレーション

NFC カードをホストベースのカード エミュレーションでエミュレートすると、データはセキュア エレメントに転送されるのではなく、ホスト CPU に直接ルーティングされます。図 2 は、ホストベースのカード エミュレーションの仕組みを示しています。

NFC リーダーが NFC コントローラを通過して CPU から情報を取得する図
図 2. セキュア エレメントを使用しない NFC カード エミュレーション

サポートされている NFC カードとプロトコル

HCE プロトコル スタックを示す図
図 3. Android の HCE プロトコル スタック

NFC 規格はさまざまなプロトコルをサポートしており、エミュレートできるカードの種類もさまざまです。

Android 4.4 以降では、現在の市場で一般的ないくつかのプロトコルがサポートされています。既存の非接触型決済カードの多くは、非接触型決済カードなど、すでにこれらのプロトコルに基づいています。これらのプロトコルは、それ自体がリーダーとして機能する Android NFC デバイスなど、今日の市場の多くの NFC リーダーでもサポートされています(IsoDep クラスを参照)。これにより、Android 搭載デバイスのみを使用して、HCE に関するエンドツーエンドの NFC ソリューションを構築し、デプロイできます。

具体的には、Android 4.4 以降では、NFC-Forum ISO-DEP 仕様(ISO/IEC 14443-4 ベース)に基づいて、ISO/IEC 7816-4 仕様で定義されているアプリケーション プロトコル データ ユニット(APDU)を処理するカードをエミュレートできます。Android では、Nfc-A(ISO/IEC 14443-3 Type A)テクノロジー上でのみ ISO-DEP をエミュレートすることが義務付けられています。NFC-B(ISO/IEC 14443-4 Type B)技術のサポートは任意です。図 3 は、これらすべての仕様のレイヤ化を示しています。

HCE サービス

Android の HCE アーキテクチャは、Android Service コンポーネント(HCE サービスとも呼ばれます)に基づいています。サービスの主な利点の一つは、ユーザー インターフェースなしでバックグラウンドで実行できることです。これは、ポイントカードや交通機関のカードなど、アプリを起動しなくても使用できる多くの HCE アプリケーションに適しています。代わりに、NFC リーダーにデバイスをタップすると、正しいサービスがまだ実行されていなければ開始され、バックグラウンドでトランザクションが実行されます。もちろん、必要に応じて、サービスから追加の UI(ユーザー通知など)を自由に起動することもできます。

サービスの選択

ユーザーが NFC リーダーにデバイスをタップすると、Android システムは、NFC リーダーが通信しようとしている HCE サービスを認識する必要があります。ISO/IEC 7816-4 仕様は、アプリケーション ID(AID)を中心にアプリを選択する方法を定義しています。AID は最大 16 バイトで構成されます。既存の NFC リーダー インフラストラクチャのカードをエミュレートする場合、そのようなリーダーが求める AID は通常、よく知られていて広く登録されている AID(Visa や MasterCard などの決済ネットワークの AID など)です。

独自のアプリケーションに新しいリーダー インフラストラクチャをデプロイする場合は、独自の AID を登録する必要があります。AID の登録手順は、ISO/IEC 7816-5 仕様で定義されています。Android 用の HCE アプリをデプロイする場合は、7816-5 に従って AID を登録することをおすすめします。これにより、他のアプリとの競合を回避できるからです。

AID グループ

場合によっては、HCE サービスが特定のアプリを実装するために、複数の AID を登録し、すべての AID のデフォルト ハンドラとして設定しなければならないことがあります。グループ内の一部の AID が別のサービスに向かうことはサポートされていません。

1 つにまとめられた AID のリストを AID グループと呼びます。AID グループ内のすべての AID について、Android は次のいずれかを保証します。

  • グループ内のすべての AID がこの HCE サービスにルーティングされます。
  • グループ内の AID がこの HCE サービスにルーティングされることはありません(たとえば、グループ内の 1 つ以上の AID をリクエストした別のサービスをユーザーが選択した場合など)。

つまり、グループ内の一部の AID がある HCE サービスに、ある AID を別の HCE サービスにルーティングできる中間状態はありません。

AID グループとカテゴリ

各 AID グループをカテゴリに関連付けることができます。これにより Android は HCE サービスをカテゴリ別にグループ化し、ユーザーが AID レベルではなくカテゴリレベルでデフォルトを設定できるようにします。アプリのユーザー向け部分では AID を使用しないでください。一般的なユーザーにとっては AID は意味がありません。

Android 4.4 以降では、次の 2 つのカテゴリがサポートされています。

HCE サービスを実装する

ホストベースのカード エミュレーションを使用して NFC カードをエミュレートするには、NFC トランザクションを処理する Service コンポーネントを作成する必要があります。

HCE のサポートを確認する

アプリは FEATURE_NFC_HOST_CARD_EMULATION 機能を確認することで、デバイスが HCE をサポートしているかどうかを確認できます。アプリのマニフェストで <uses-feature> タグを使用して、アプリが HCE 機能を使用することと、アプリの機能にその機能が必要かどうかを宣言します。

サービスの実装

Android 4.4 以降では、HCE サービスを実装するための基礎として使用できる、便利な Service クラスである 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 つの抽象メソッドを宣言します。そのうちの一つである processCommandApdu() は、NFC リーダーがアプリケーション プロトコル データ ユニット(APDU)をサービスに送信するたびに呼び出されます。APDU は ISO/IEC 7816-4 仕様で定義されています。APDU は、NFC リーダーと HCE サービスの間で交換されるアプリケーション レベルのパケットです。アプリケーション レベルのプロトコルは半二重です。つまり、NFC リーダーはコマンド APDU を送信し、それに対するレスポンス APDU が送信されるのを待ちます。

前述のように、Android は AID を使用して、リーダーが通信する HCE サービスを判断します。通常、NFC リーダーがデバイスに送信する最初の APDU は SELECT AID APDU です。この APDU には、リーダーが通信しようとしている AID が含まれています。Android は APDU から AID を抽出し、HCE サービスに解決して、その APDU を解決済みサービスに転送します。

processCommandApdu() からレスポンス APDU のバイトを返すことにより、レスポンス APDU を送信できます。このメソッドはアプリのメインスレッドで呼び出されるため、ブロックしないでください。レスポンス APDU をすぐに計算して返できない場合は、null を返します。その後、別のスレッドで必要な処理を行い、完了したら HostApduService クラスで定義された sendResponseApdu() メソッドを使用してレスポンスを送信できます。

Android は、次のいずれかが発生するまで、リーダーからサービスへの新しい APDU を転送し続けます。

  • NFC リーダーが別の SELECT AID APDU を送信し、OS がこれを別のサービスに解決します。
  • NFC リーダーとデバイスとの間の NFC リンクが切断される。

どちらの場合も、クラスの onDeactivated() 実装が、2 つのうちどちらが発生したかを示す引数で呼び出されます。

既存のリーダー インフラストラクチャを使用する場合は、リーダーが期待する既存のアプリケーション レベルのプロトコルを HCE サービスに実装する必要があります。

自分で管理する新しいリーダー インフラストラクチャをデプロイする場合は、独自のプロトコルと APDU シーケンスを定義できます。APDU の数と交換するデータのサイズを制限するようにしてください。これにより、ユーザーはデバイスを NFC リーダーに短時間かざすだけで済みます。妥当な上限は約 1 KB で、通常は 300 ミリ秒以内に交換できます。

マニフェストでのサービスの宣言と AID の登録

通常どおりマニフェストでサービスを宣言する必要がありますが、サービス宣言に次のような要素も追加する必要があります。

  1. HostApduService インターフェースを実装する HCE サービスであることをプラットフォームに伝えるには、サービス宣言に SERVICE_INTERFACE アクションのインテント フィルタを追加します。

  2. このサービスによってどの AID グループがリクエストされるかをプラットフォームに伝えるには、サービスの宣言に SERVICE_META_DATA <meta-data> タグを追加して、HCE サービスに関する追加情報を含む XML リソースを参照します。

  3. android:exported 属性を true に設定し、サービス宣言で android.permission.BIND_NFC_SERVICE 権限を要求します。前者は、サービスを外部アプリにバインドできるようにします。後者では、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 グループ宣言を指定しています。

<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> 属性を含める必要があります。この属性には、アプリの UI に表示できる、ユーザーにわかりやすいサービスの説明を含めます。requireDeviceUnlock 属性を使用すると、このサービスを呼び出して APDU を処理する前に、デバイスをロック解除することを指定できます。

<host-apdu-service> には <aid-group> タグを含める必要があります。各 <aid-group> タグでは、次のことを行う必要があります。

  • UI での表示に適した、ユーザー フレンドリーな AID グループの説明を含む android:description 属性を含めます。
  • android:category 属性を設定して、CATEGORY_PAYMENTCATEGORY_OTHER で定義された文字列定数など、AID グループが属するカテゴリを示す。
  • 1 つ以上の <aid-filter> タグを指定し、各タグには 1 つの AID が含まれます。AID を 16 進数形式で指定し、偶数文字が含まれていることを確認します。

また、HCE サービスとして登録するには、アプリが NFC 権限を保持している必要があります。

AID の競合の解決

1 つのデバイスに複数の HostApduService コンポーネントをインストールできます。また、複数のサービスで同じ AID を登録できます。Android による AID の競合の解決方法は、AID が属するカテゴリによって異なります。カテゴリごとに異なる競合解決ポリシーが設定されている場合があります。

支払いなどの一部のカテゴリでは、ユーザーが Android の設定 UI でデフォルトのサービスを選択できる場合があります。その他のカテゴリでは、競合が発生した場合に呼び出すサービスを常にユーザーに求めるポリシーもあります。特定のカテゴリの競合解決ポリシーをクエリする方法については、getSelectionModeForCategory() をご覧ください。

サービスがデフォルトかどうかを確認する

アプリは、isDefaultServiceForCategory() API を使用して、HCE サービスが特定のカテゴリのデフォルト サービスかどうかを確認できます。

サービスがデフォルトでない場合は、ACTION_CHANGE_DEFAULT を使用してデフォルトにするようリクエストできます。

決済アプリ

Android は、支払いカテゴリの AID グループを宣言した HCE サービスを支払いアプリとみなします。Android 4.4 以降には、トップレベルの [設定] メニュー エントリである「タップ &ペイ」があり、このような決済アプリがすべて列挙されています。この設定メニューで、ユーザーは決済端末がタップされたときに呼び出すデフォルトの決済アプリケーションを選択できます。

決済アプリに必要なアセット

HCE 支払いアプリケーションでは、視覚的により魅力的なユーザー エクスペリエンスを提供するために、サービスバナーを提供する必要があります。

Android 13 以降

設定 UI のデフォルトの支払い選択リストに合わせて、バナーの要件を正方形のアイコンに調整します。アプリ ランチャー アイコンのデザインと同じであることが理想的です。この調整により、一貫性が増し、すっきりとした外観になります。

Android 12 以前

サービスバナーのサイズを 260x96 dp に設定し、メタデータ XML ファイルでサービスバナーのサイズを設定するには、ドローアブル リソースを指す <host-apdu-service> タグに android:apduServiceBanner 属性を追加します。次に例を示します。

<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)以降をターゲットとするアプリでは、requireDeviceScreenOnfalse に設定することで、デバイスの画面をオンにせずに NFC 支払いを有効にできます。

Android 10 以降

Android 10(API レベル 29)以降を搭載したデバイスは、セキュア NFC をサポートしています。セキュア NFC がオンになっている場合、デバイスの画面がオフになると、すべてのカード エミュレータ(ホストアプリとオフホスト アプリ)が使用できなくなります。セキュア NFC がオフの場合、デバイス画面がオフになるとオフホスト アプリを使用できます。セキュア NFC をサポートしているかどうかは、isSecureNfcSupported() で確認できます。

Android 10 以降を搭載したデバイスでは、android:requireDeviceUnlocktrue に設定する機能は Android 9 以前を搭載したデバイスと同じですが、セキュア NFC がオフになっている場合にのみ適用されます。つまり、セキュア NFC がオンになっている場合、android:requireDeviceUnlock の設定にかかわらず、HCE サービスはロック画面から機能しません。

Android 9 以前

Android 9(API レベル 28)以前を搭載したデバイスでは、デバイスの画面がオフになると、NFC コントローラとアプリ プロセッサが完全にオフになります。そのため、画面がオフのときは HCE サービスは機能しません。

Android 9 以前では、HCE サービスはロック画面から機能できます。ただし、これは HCE サービスの <host-apdu-service> タグの android:requireDeviceUnlock 属性によって制御されます。デフォルトでは、デバイスのロック解除は必要なく、デバイスがロックされていてもサービスは呼び出されます。

HCE サービスの android:requireDeviceUnlock 属性を true に設定すると、次の場合にデバイスのロック解除を求めるメッセージが Android に表示されます。

  • ユーザーが NFC リーダーをタップしたとき。
  • NFC リーダーが、サービスに解決される AID を選択します。

ロック解除後、Android はユーザーに取引を完了するためにもう一度タップするよう求めるダイアログを表示します。この操作が必要になるのは、ユーザーがロック解除のためにデバイスを NFC リーダーから離した可能性があるためです。

セキュア エレメント カードとの共存

このセクションは、カード エミュレーションにセキュア エレメントに依存するアプリをデプロイしているデベロッパーを対象としています。Android の HCE 実装は、セキュア エレメントの使用など、カード エミュレーションを実装する他の方法と同時に動作するように設計されています。

この共存は、AID ルーティングと呼ばれる原則に基づいています。NFC コントローラは、ルーティング ルールの(有限)リストで構成されるルーティング テーブルを保持します。各ルーティングルールには AID と宛先が含まれます。宛先は、Android アプリが実行されているホスト CPU、または接続されたセキュア エレメントのいずれかです。

NFC リーダーが SELECT AID で APDU を送信すると、NFC コントローラは APDU を解析し、AID がルーティング テーブル内の AID と一致するかどうかを確認します。一致した場合は、その APDU と、それに続くすべての APDU が、別の SELECT AID APDU を受信するか、NFC リンクが切断されるまで、AID に関連付けられた宛先に送信されます。

図 4 に、このアーキテクチャを示します。

NFC リーダーがセキュア エレメントと CPU の両方と通信している図
図 4. セキュア エレメントとホストカード エミュレーションの両方で動作する Android。

通常、NFC コントローラは APDU のデフォルト ルートも含んでいます。ルーティング テーブルに AID が見つからない場合は、デフォルト ルートが使用されます。この設定はデバイスによって異なる場合がありますが、Android デバイスでは、アプリによって登録された AID がホストに適切にルーティングされるようにする必要があります。

HCE サービスを実装する Android アプリやセキュア エレメントを使用する Android アプリでは、ルーティング テーブルの構成を考慮する必要はありません。この設定は Android によって自動的に処理されます。Android が把握する必要があるのは、HCE サービスが処理できる AID とセキュア エレメントが処理できる AID だけです。ルーティング テーブルは、インストールされているサービスと、ユーザーが優先として構成したサービスに基づいて自動的に構成されます。

次のセクションでは、カード エミュレーションにセキュア エレメントを使用するアプリの 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>
    

2 つの AID を登録する、対応する apduservice.xml ファイルの例を次に示します。

<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 サービスではなくセキュア エレメントによって実行されるため、Android が「オフホスト」として宣言されているサービスを開始したり、そのようなサービスにバインドしたりすることはありません。このサービス宣言では、セキュア エレメントに存在する AID をアプリに登録することのみを許可します。

HCE とセキュリティ

HCE アーキテクチャでは、1 つのコア セキュリティが提供されます。サービスは BIND_NFC_SERVICE システム権限によって保護されているため、OS のみがサービスにバインドして通信できます。これにより、受け取った APDU は実際には NFC コントローラから OS が受信した APDU であることが保証され、返送した APDU は OS にのみ送られ、OS は APDU を NFC コントローラに直接転送します。

最後に残った懸念事項は、アプリが NFC リーダーに送信するデータを取得することです。これは HCE の設計で意図的に分離されています。データの出所は気にせず、データが NFC コントローラに安全に転送され、NFC リーダーに送られることを確認するだけです。

HCE サービスから送信するデータを安全に保存および取得するには、アプリのデータを他のアプリから分離する Android アプリ サンドボックスなどを利用できます。Android のセキュリティについて詳しくは、セキュリティに関するヒントをご覧ください。

プロトコル パラメータと詳細

このセクションは、NFC プロトコルのアンチコリジョン フェーズとアクティベーション フェーズで HCE デバイスが使用するプロトコル パラメータを把握したいデベロッパーを対象としています。これにより、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 番目のビットのみをチェックする必要があります。SEL_RES 全体を値 0x20 と比較しないでください。

ISO-DEP の有効化

NFC-A プロトコルが有効になると、NFC リーダーが ISO-DEP プロトコルの有効化を開始します。RATS(Request for Answer To Select)コマンドを送信します。NFC コントローラは、RATS レスポンスである ATS を生成します。HCE サービスで ATS を構成することはできません。ただし、HCE 実装は ATS レスポンスに関する NFC フォーラムの要件を満たさなければならないため、NFC リーダーは、HCE デバイスに関する NFC フォーラムの要件に従って設定されたこれらのパラメータを信頼できます。

以下のセクションでは、HCE デバイスの NFC コントローラによって提供される ATS レスポンスの個々のバイトについて詳しく説明します。

  • TL: ATS 応答の長さ。20 バイトを超える長さを指定することはできません。
  • T0: ビット 5、6、7 がすべての HCE デバイスで設定され、ATS 応答に TA(1)、TB(1)、TC(1) が含まれていることを示します。ビット 1 ~ 4 は FSCI を示し、最大フレームサイズをコーディングします。HCE デバイスでは、FSCI の値は 0h ~ 8h にする必要があります。
  • T(A)1: リーダーとエミュレータ間のビットレートと、非対称にできるかどうかを定義します。HCE デバイスに対するビットレートの要件または保証はありません。
  • T(B)1: ビット 1~4 は、開始フレーム保護時間整数値(SFGI)を示します。HCE デバイスでは、SFGI は 8 時間以下でなければなりません。ビット 5 ~ 8 はフレーム待機時間整数(FWI)を示し、フレーム待機時間(FWT)をコーディングします。HCE デバイスでは、FWI は 8h 以下でなければなりません。
  • T(C)1: ビット 5 は、「高度なプロトコル機能」のサポート状況を示します。HCE デバイスは、「高度なプロトコル機能」をサポートしている場合とサポートしていない場合があります。ビット 2 は DID がサポートされていることを示します。HCE デバイスでは DID をサポートしている場合と、サポートしていない場合とがあります。ビット 1 は NAD のサポートを示します。HCE デバイスでは NAD をサポートしてはならないため、ビット 1 はゼロに設定してください。
  • ヒストリカル バイト: HCE デバイスは、最大 15 バイトのヒストリカル バイトを返すことがあります。HCE サービスとやり取りする NFC リーダーは、履歴バイトの内容やその存在について推測しないでください。

多くの HCE デバイスは、EMVCo の統合決済ネットワークが「非接触通信プロトコル」仕様で規定しているプロトコル要件に準拠している可能性があります。具体的には、次のとおりです。

  • T0 の FSCI は 2h~8h の間でなければならない。
  • T(A)1 を 0x80 に設定する必要があります。これは、106 kbit/s のビットレートのみがサポートされ、リーダーとエミュレータ間の非対称ビットレートがサポートされていないことを示します。
  • T(B)1 の FWI は 7h 以下である必要がある。

APDU データの交換

前述のように、HCE の実装は単一の論理チャネルのみをサポートします。異なる論理チャンネル上のアプリを選択しようとしても、HCE デバイスでは機能しません。