このページは Cloud Translation API によって翻訳されました。

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

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 フォーラムの ISO-DEP 仕様（ISO/IEC 14443-4 をベースとする）に基づく、ISO/IEC 7816-4 仕様の定義に従って Application Protocol Data Units（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 サービス）に基づいています。サービスの主な利点の 1 つは、一切のユーザーインターフェースを持たずにバックグラウンドで動作できることです。これは、ポイントカードや交通機関のカードなど、ユーザーがアプリを起動しなくても使用できる多くの 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 が別のサービスに転送されることはサポートされていません。

一緒に保持される AID のリストは、AID グループと呼ばれます。AID グループ内のすべての AID に対して、Android は次のいずれかを保証します。

グループ内のすべての AID がこの HCE サービスにルーティングされます。
グループ内のどの AID もこの HCE サービスにルーティングされない（たとえば、別のサービスでもそのグループ内の AID を 1 つ以上リクエストしており、ユーザーがそちらのサービスを優先している場合）。

つまり、グループ内の AID の一部が異なる複数の HCE サービスにルーティングされる可能性がある、といった中間的な状態は存在しません。

AID グループとカテゴリ

各 AID グループはカテゴリに関連付けることができます。これにより Android が HCE サービスをカテゴリ別にグループ化することができ、それによって、ユーザーが AID レベルではなくカテゴリレベルでデフォルトを設定できます。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 以降には、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 つの抽象メソッドを宣言します。そのうちの 1 つである 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 を転送します。

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

Android は、次のいずれかの状態になるまで、リーダーからの新しい APDU をサービスに転送し続けます。

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

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

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

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

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

サービスは通常どおりマニフェストで宣言する必要がありますが、サービスの宣言にいくつかの項目を追加する必要があります。

HostApduService インターフェースを実装する HCE サービスであることをプラットフォームに伝えるには、サービス宣言に SERVICE_INTERFACE アクションのインテントフィルタを追加します。
このサービスがリクエストする AID グループをプラットフォームに伝えるために、HCE サービスに関する追加情報を含んだ XML リソースを指定する SERVICE_META_DATA <meta-data> タグをサービスの宣言に含めます。
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> タグには、アプリの UI に表示できるサービスの説明を、ユーザー向けのわかりやすい形で指定した <android:description> 属性を含める必要があります。requireDeviceUnlock 属性を使用すると、このサービスを呼び出して APDU を処理する前にデバイスのロック解除を必須とするように指定できます。

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

android:description 属性を含めます。この属性には、AID グループの説明を、UI での表示に適したユーザー向けのわかりやすい形で指定します。
android:category 属性を設定して、その AID グループが属するカテゴリを示します（例: CATEGORY_PAYMENT または CATEGORY_OTHER で定義される文字列定数）。
1 つ以上の <aid-filter> タグを含めます。各タグには 1 つの AID が含まれます。AID は 16 進数形式で指定し、偶数個の文字を含める必要があります。

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

AID の競合の解決

複数の HostApduService コンポーネントが 1 台のデバイスにインストールされる場合があり、同じ AID が複数のサービスによって登録される可能性があります。Android は、次の手順で呼び出すサービスを決定します。

ユーザーが選択したデフォルトのウォレットアプリに AID が登録されている場合、そのアプリが呼び出されます。
デフォルトのウォレットアプリが AID を登録していない場合、AID を登録したサービスが呼び出されます。
複数のサービスが AID を登録している場合は、どのサービスを呼び出すかをユーザーに尋ねます。

アプリがデフォルトのウォレットアプリかどうかを確認する

アプリがデフォルトのウォレットアプリかどうかを確認するには、RoleManager.isRoleHeld() に RoleManager.ROLE_WALLET を渡します。

アプリがデフォルトではない場合は、RoleManager.ROLE_WALLET を RoleManager.createRequestRoleIntent() に渡すことで、デフォルトのウォレットロールをリクエストできます。

ウォレットアプリ

Android では、決済カテゴリで AID グループを宣言した HCE サービスをウォレットアプリとみなします。Android 15 以降には、ユーザーが [設定] > [アプリ] > [デフォルトのアプリ] に移動して選択できるデフォルトのウォレットアプリのロールがあります。これは、支払い端末をタップしたときに呼び出されるデフォルトのウォレットアプリを定義します。

ウォレットアプリに必要なアセット

視覚性に優れた魅力的なユーザーエクスペリエンスを提供するため、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>

観察モード

Android 15 では、観測モード機能が導入されています。有効にすると、デバイスは NFC ポーリングループを監視し、その通知を適切な HostApduService コンポーネントに送信して、特定の NFC 端末とのやり取りの準備を整えることができます。HostApduService は、true を setObserveModeEnabled() に渡すことで、デバイスをオブザーバモードにできます。これにより、NFC トランザクションを許可せず、代わりにポーリングループをパッシブに監視するように NFC スタックに指示します。

ポーリングループフィルタ

HostApduService のポーリングループフィルタは、次のいずれかの方法で登録できます。

registerPollingLoopFilterForService(): ポーリングフレームと完全に一致する必要があるフィルタ。
registerPollingLoopPatternFilterForService(): 正規表現とポーリングフレームを照合するフィルタ。

ポーリングループフィルタが標準以外のポーリングフレームに一致すると、NFC スタックは processPollingFrames() メソッドを呼び出して、それらのポーリングフレームを対応する HostApduService に転送します。これにより、サービスは、ユーザーが取引の準備ができており、取引を行う意思があることを確認するために必要な手順（ユーザーの認証など）を実行できます。NFC リーダーがポーリングループで標準フレームのみを使用している場合、NFC スタックは、そのサービスがフォアグラウンドにある場合は優先フォアグラウンドサービスに、それ以外の場合はデフォルトのウォレットロール保持者にポーリングフレームを転送します。

ポーリングフレーム通知には、ベンダー固有のフィールド強度の測定値も含まれます。この値は、getVendorSpecificGain() を呼び出すことで取得できます。ベンダーは、1 バイト以内に収まる限り、独自のスケールを使用して測定値を提供できます。

ポーリングループへの応答と観察モードからの移行

トランザクションの準備ができたら、false を setObserveModeEnabled() に渡して監視モードを終了できます。NFC スタックは、トランザクションの続行を許可します。

HostApduService コンポーネントは、マニフェストで shouldDefaultToObserveMode を true に設定するか、CardEmulation.setShouldDefaultToObserveModeForService() を呼び出すことで、優先されるお支払いサービスである場合は常にオブザーバモードを有効にするように指定できます。

HostApduService コンポーネントと OffHostApduService コンポーネントは、受信したポーリングループフレームに一致するポーリングループフィルタを自動的に無効にし、マニフェストの PollingLoopFilter 宣言で autoTransact を true に設定してトランザクションを続行できるようにすることもできます。

画面オフとロック画面の動作

HCE サービスの動作は、デバイスで実行されている Android のバージョンによって異なります。

Android 12 以降

Android 12（API レベル 31）以降をターゲットとするアプリでは、requireDeviceScreenOn を false に設定することで、デバイスの画面をオンにすることなく NFC 決済を有効にできます。

Android 10 以降

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

Android 10 以降を搭載したデバイスでは、android:requireDeviceUnlock を true に設定する機能は、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 に設定した場合、次の場合にデバイスのロック解除を求めるプロンプトが表示されます。

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

ロックを解除すると、再度タップして取引を完了するようユーザーに求めるダイアログが Android に表示されます。このようにする必要がある理由は、ロック解除のためにユーザーが NFC リーダーからデバイスを離す場合があるためです。

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

このセクションでは、カードエミュレーションにセキュアエレメントを使用するアプリをデプロイしたデベロッパー向けの内容を記載しています。Android における HCE の実装は、セキュアエレメントの使用を含む他のカードエミュレーションの実装方法と同時に機能するように設計されています。

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

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

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

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

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

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

次のセクションでは、カードエミュレーションにセキュアエレメントを使用するアプリの AID を宣言する方法について説明します。

セキュアエレメントの AID の登録

カードエミュレーションにセキュアエレメントを使用するアプリは、マニフェストでオフホストサービスを宣言できます。そのようなサービスの宣言は、HCE サービスの宣言とほぼ同じです。例外は次のとおりです。

インテントフィルタで使用するアクションは SERVICE_INTERFACE に設定する必要があります。
メタデータ名属性は 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 アーキテクチャは、セキュリティの中核となる部分の一つです。サービスは BIND_NFC_SERVICE システム権限によって保護されているため、サービスにバインドして通信できるのは OS だけです。これにより、受信する APDU は実際に OS が NFC コントローラから受信した APDU であること、および、返信する APDU はすべて OS にのみ送信され、OS から NFC コントローラに APDU が直接転送されることが保証されます。

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

HCE サービスで送信するデータを安全に保管、取得するために、たとえば Android アプリサンドボックスを利用できます。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 デバイスと通信するリーダーでは SEL_RES 全体を値 0x20 と比較せずに、ビット 6 のみを明示的に確認する必要があります。

ISO-DEP の有効化

NFC-A プロトコルがアクティブになると、NFC リーダーによって ISO-DEP プロトコルの有効化が開始されます。NFC リーダーは RATS（Request for Answer To Select）コマンドを送信します。RATS の応答である ATS は NFC コントローラによって生成されます。ATS は HCE サービスで設定することはできません。ただし、HCE の実装では ATS 応答に関する NFC フォーラムの要件を満たしている必要があるため、NFC リーダーは、あらゆる HFC デバイスでこうしたパラメータが NFC フォーラムの要件に沿って設定されていると当てにすることができます。

以下のセクションで、HCE デバイス上の NFC コントローラが提供する ATS 応答の個別のバイトについて詳しく説明します。

TL: ATS 応答の長さ。20 バイトを超える長さを示すことはできません。
T0: すべての HCE デバイスでビット 5、6、7 を設定して、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 は 8h 以下にする必要があります。ビット 5 ～ 8 はフレーム待ち時間整数値（FWI）を示し、フレーム待ち時間（FWT）を符号化します。HCE デバイスでは、FWI は 8h 以下にする必要があります。
T（C）1: ビット 5 は、「高度なプロトコル機能」のサポート状況を示します。HCE デバイスは、「高度なプロトコル機能」をサポートしている場合とサポートしていない場合があります。ビット 2 は、DID のサポート状況を示します。HCE デバイスでは DID をサポートしている場合と、サポートしていない場合とがあります。ビット 1 は、NAD のサポート状況を示します。HCE デバイスでは NAD をサポートしてはならないため、ビット 1 はゼロに設定してください。
ヒストリカルバイト: HCE デバイスは、最大 15 バイトのヒストリカルバイトを返すことがあります。HFC サービスと通信する NFC リーダーは、ヒストリカルバイトの内容やその存在について一切想定しないようにする必要があります。

HCE デバイスの多くは、EMVCo を構成する決済ネットワークが「Contactless Communication Protocol」仕様で定めているプロトコルの要件に準拠していると考えられます。具体的には、次のとおりです。

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

APDU データの交換

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