Halaman ini diterjemahkan oleh Cloud Translation API.

Ringkasan emulasi kartu berbasis host

Banyak perangkat Android yang menawarkan fungsi NFC dan sudah mendukung NFC emulasi kartu. Dalam kebanyakan kasus, kartu diemulasikan oleh {i>chip<i} terpisah di perangkat, yang disebut elemen pengaman. Banyak kartu SIM yang disediakan oleh operator nirkabel juga berisi elemen pengaman.

Android 4.4 dan yang lebih tinggi menyediakan metode tambahan emulasi kartu yang tidak melibatkan elemen pengaman, yang disebut emulasi kartu berbasis host. Ini memungkinkan aplikasi Android apa pun untuk mengemulasikan sebuah kartu dan berkomunikasi langsung dengan NFC pembaca. Topik ini menjelaskan cara kerja emulasi kartu berbasis host (HCE) pada Android dan bagaimana Anda dapat mengembangkan aplikasi yang mengemulasi kartu NFC menggunakan standar.

Emulasi kartu dengan elemen pengaman

Ketika emulasi kartu NFC disediakan menggunakan elemen pengaman, kartu yang harus diemulasikan disediakan ke dalam elemen pengaman pada perangkat melalui aplikasi. Kemudian, ketika pengguna memegang perangkat di atas terminal NFC, di perangkat akan merutekan semua data dari pembaca secara langsung ke . Gambar 1 menggambarkan konsep ini:

Diagram pembaca NFC yang melewati pengontrol NFC untuk mengambil informasi dari elemen pengaman
Gambar 1. Emulasi kartu NFC dengan elemen pengaman.

Elemen pengaman itu sendiri melakukan komunikasi dengan terminal NFC, dan tidak ada aplikasi Android yang terlibat dalam transaksi. Setelah transaksi selesai, aplikasi Android dapat melakukan kueri elemen pengaman secara langsung untuk status transaksi dan memberi tahu pengguna.

Emulasi kartu berbasis host

Saat kartu NFC diemulasi menggunakan emulasi kartu berbasis host, data akan dirutekan langsung ke CPU {i>host<i} alih-alih diarahkan ke elemen pengaman. Gambar 2 mengilustrasikan cara kerja emulasi kartu berbasis host:

Diagram dengan pembaca NFC yang melewati pengontrol NFC untuk mengambil informasi dari CPU
Gambar 2. Emulasi kartu NFC tanpa elemen pengaman.

Kartu dan protokol NFC yang didukung

Diagram yang menunjukkan stack protokol HCE
Gambar 3. Stack protokol HCE Android.

Standar NFC menawarkan dukungan untuk banyak protokol yang berbeda, dan ada berbagai jenis kartu yang dapat Anda emulasikan.

Android 4.4 dan yang lebih tinggi mendukung beberapa protokol yang umum beredar sekarang juga. Banyak kartu tanpa kontak yang ada sudah didasarkan pada protokol ini, seperti kartu pembayaran nirsentuh. Protokol ini juga didukung oleh banyak Pembaca NFC yang beredar di pasaran saat ini, termasuk perangkat NFC Android yang berfungsi sebagai pembaca itu sendiri (lihat IsoDep ). Hal ini memungkinkan Anda untuk membangun dan menempatkan solusi NFC menyeluruh di sekitar HCE hanya menggunakan perangkat Android.

Secara khusus, Android 4.4 dan yang lebih tinggi mendukung emulasi kartu yang didasarkan pada spesifikasi ISO-DEP NFC-Forum (berdasarkan ISO/IEC 14443-4) dan proses Unit Data Protokol Aplikasi (APDU) sebagaimana didefinisikan dalam ISO/IEC 7816-4 spesifikasi pendukung. Android hanya mewajibkan emulasi ISO-DEP hanya di atas Nfc-A (ISO/IEC 14443-3 Tipe A). Dukungan untuk Nfc-B (ISO/IEC 14443-4 Tipe B) teknologi bersifat opsional. Gambar 3 menggambarkan lapisan (lapisan) ini spesifikasi produk.

Layanan HCE

Arsitektur HCE di Android didasarkan pada Android Komponen Service (dikenal sebagai HCE) layanan). Salah satu keuntungan utama dari layanan adalah dapat berjalan di latar belakang tanpa antarmuka pengguna. Hal ini sangat cocok untuk banyak HCE aplikasi, seperti kartu loyalitas atau transportasi umum, yang seharusnya tidak diperlukan oleh pengguna meluncurkan aplikasi untuk digunakan. Sebaliknya, mengetuk perangkat dengan pembaca NFC akan dimulai layanan yang benar jika belum berjalan dan menjalankan transaksi di latar belakang. Tentu saja, Anda bebas meluncurkan UI tambahan (seperti notifikasi pengguna) dari layanan Anda jika diperlukan.

Pilihan layanan

Saat pengguna menempelkan perangkat ke pembaca NFC, sistem Android perlu mengetahui layanan HCE yang ingin dikomunikasikan oleh pembaca NFC. ISO/IEC 7816-4 spesifikasi mendefinisikan cara memilih aplikasi, yang berpusat pada ID Aplikasi (AID). Sebuah AID terdiri dari maksimal 16 byte. Jika Anda mengemulasi kartu untuk infrastruktur pembaca NFC yang ada, AID yang harus biasanya dikenal dan terdaftar secara publik (misalnya, AID jaringan pembayaran seperti Visa dan MasterCard).

Jika ingin men-deploy infrastruktur pembaca baru untuk aplikasi Anda sendiri, Anda harus mendaftarkan AID Anda sendiri. Prosedur pendaftaran AID didefinisikan dalam spesifikasi ISO/IEC 7816-5. Sebaiknya daftarkan AID sesuai dengan 7816-5 jika Anda menerapkan aplikasi HCE untuk Android, karena menghindari konflik dengan aplikasi lain.

Grup AID

Dalam beberapa kasus, layanan HCE mungkin perlu mendaftarkan beberapa AID dan ditetapkan sebagai pengendali default untuk semua AID guna menerapkan aplikasi. Beberapa AID dalam grup yang menuju ke layanan lain tidak didukung.

Daftar AID yang disimpan bersama-sama disebut grup AID. Untuk semua AID di Grup AID, Android menjamin salah satu hal berikut:

Semua AID dalam grup dirutekan ke layanan HCE ini.
Tidak ada AID dalam grup yang dirutekan ke layanan HCE ini (misalnya, karena pengguna lebih menyukai layanan lain yang meminta satu atau beberapa AID di grup Anda ).

Dengan kata lain, tidak ada di antara negara bagian, di mana beberapa AID dalam kelompok dapat dirutekan ke satu layanan HCE, dan beberapa layanan ke layanan lain.

Grup dan kategori AID

Anda dapat mengaitkan setiap grup AID dengan suatu kategori. Hal ini memungkinkan Android mengelompokkan layanan HCE bersama-sama berdasarkan kategori, dan yang pada gilirannya memungkinkan pengguna untuk mengatur default di tingkat kategori, bukan di tingkat AID. Hindari menyebutkan AID di setiap bagian aplikasi Anda yang terlihat oleh pengguna, karena hal itu tidak berarti apa-apa kepada rata-rata pengguna.

Android 4.4 dan yang lebih tinggi mendukung dua kategori:

CATEGORY_PAYMENT (yang mencakup aplikasi pembayaran standar industri)
CATEGORY_OTHER (untuk semua aplikasi HCE lainnya)

Mengimplementasikan layanan HCE

Untuk mengemulasikan kartu NFC menggunakan emulasi kartu berbasis host, Anda harus membuat Komponen Service yang menangani transaksi NFC.

Memeriksa dukungan HCE

Aplikasi Anda dapat memeriksa apakah perangkat mendukung HCE atau tidak dengan memeriksa FEATURE_NFC_HOST_CARD_EMULATION aplikasi baru. Menggunakan <uses-feature> dalam manifes aplikasi untuk mendeklarasikan bahwa aplikasi Anda menggunakan HCE dan apakah diperlukan agar aplikasi dapat berfungsi atau tidak.

Pelaksanaan layanan

Android 4.4 dan yang lebih tinggi menyediakan class Service praktis yang dapat Anda gunakan sebagai dasar untuk menerapkan layanan HCE: HostApduService.

Langkah pertama adalah memperluas HostApduService, seperti yang ditunjukkan pada kode berikut contoh:

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 mendeklarasikan dua metode abstrak yang harus Anda ganti dan diterapkan. Salah satunya, processCommandApdu(), dipanggil setiap kali pembaca NFC mengirimkan Application Protocol Data Unit (APDU) ke layanan Anda. APDU ditentukan dalam spesifikasi ISO/IEC 7816-4. APDU adalah paket tingkat aplikasi yang dipertukarkan pembaca NFC dan layanan HCE Anda. Protokol tingkat aplikasi tersebut adalah {i>half-duplex<i}: pembaca NFC mengirimkan perintah APDU kepada Anda, dan menunggu Anda mengirim APDU respons di kembali.

Seperti yang disebutkan sebelumnya, Android menggunakan AID untuk menentukan layanan HCE mana menjadi sasaran dari pembaca. Biasanya, APDU pertama yang dikirim pembaca NFC ke perangkat adalah APDU SELECT AID; APDU ini berisi AID yang diinginkan pembaca untuk diajak bicara. Android mengekstrak AID tersebut dari APDU, menyelesaikannya menjadi HCE layanan, lalu meneruskan APDU tersebut ke layanan yang telah diselesaikan.

Anda dapat mengirim APDU respons dengan menampilkan byte APDU respons dari processCommandApdu(). Perhatikan bahwa metode ini dipanggil pada thread utama aplikasi Anda, yang tidak boleh Anda blokir. Jika Anda tidak dapat menghitung dan mengembalikan APDU respons dengan segera, kembalikan null. Anda kemudian dapat melakukan pekerjaan yang diperlukan pada thread lain dan menggunakan sendResponseApdu() yang ditentukan di class HostApduService untuk mengirim respons saat Anda selesai.

Android akan terus meneruskan APDU baru dari pembaca ke layanan Anda, hingga dari hal berikut akan terjadi:

Pembaca NFC mengirim APDU SELECT AID lain, yang di-resolve oleh OS ke layanan yang berbeda.
Link NFC antara pembaca NFC dan perangkat Anda rusak.

Dalam kedua kasus ini, atribut onDeactivated() implementasi dipanggil dengan argumen yang menunjukkan peristiwa mana yang terjadi.

Jika menggunakan infrastruktur pembaca yang ada, Anda harus mengimplementasikan protokol tingkat aplikasi yang ada yang diharapkan pembaca dalam layanan HCE Anda.

Jika Anda men-deploy infrastruktur pembaca baru yang juga Anda kontrol, Anda dapat menentukan protokol dan urutan APDU Anda sendiri. Cobalah untuk membatasi jumlah APDU dan ukuran data yang akan dipertukarkan: ini memastikan bahwa pengguna Anda hanya memiliki mendekatkan perangkatnya ke pembaca NFC dalam waktu singkat. J batas atas yang wajar sekitar 1 KB data, yang biasanya dapat yang ditukarkan dalam waktu 300 md.

Deklarasi manifes layanan dan pendaftaran AID

Anda harus mendeklarasikan layanan dalam manifes seperti biasa, tetapi Anda harus menambahkan beberapa bagian tambahan ke deklarasi layanan juga:

Untuk memberi tahu platform bahwa ini adalah layanan HCE yang menerapkan HostApduService, tambahkan filter intent untuk SERVICE_INTERFACE tindakan pada deklarasi layanan Anda.
Untuk memberi tahu platform grup AID mana yang diminta oleh layanan ini, sertakan suatu SERVICE_META_DATA Tag <meta-data> dalam deklarasi layanan, yang mengarah ke XML berisi informasi tambahan tentang layanan HCE.
Setel atribut android:exported ke true, dan wajibkan Izin android.permission.BIND_NFC_SERVICE dalam pernyataan layanan Anda. Poin pertama memastikan bahwa layanan dapat diikat oleh aplikasi eksternal. Kemudian, ketentuan ini menetapkan bahwa hanya aplikasi eksternal yang memiliki Izin android.permission.BIND_NFC_SERVICE dapat mengikat ke layanan Anda. Karena android.permission.BIND_NFC_SERVICE adalah izin sistem, izin ini secara efektif memberlakukan bahwa hanya Android OS yang dapat mengikat ke layanan Anda.

Berikut adalah contoh deklarasi manifes 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>

Tag metadata ini mengarah ke file apduservice.xml. Berikut adalah contoh file seperti itu dengan satu deklarasi grup AID yang berisi dua AID eksklusif:

<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>

Tag <host-apdu-service> harus berisi atribut <android:description> yang berisi deskripsi yang mudah digunakan dari layanan yang dapat Anda tampilkan UI aplikasi. Anda dapat menggunakan atribut requireDeviceUnlock untuk menentukan bahwa perangkat dibuka kuncinya sebelum Anda memanggil layanan ini untuk menangani APDU.

<host-apdu-service> harus berisi satu atau beberapa tag <aid-group>. Masing-masing Tag <aid-group> diperlukan untuk melakukan hal berikut:

Berisi atribut android:description yang mudah digunakan deskripsi grup AID, yang cocok untuk ditampilkan di UI.
Menyetel atribut android:category untuk menunjukkan kategori AID grup milik suatu grup, seperti konstanta string yang ditentukan oleh CATEGORY_PAYMENT atau CATEGORY_OTHER.
Berisi satu atau beberapa tag <aid-filter>, yang masing-masing berisi satu AID. Tentukan AID dalam format heksadesimal, dan pastikan berisi bilangan genap jumlah karakter.

Aplikasi Anda juga harus memiliki Izin NFC untuk mendaftar sebagai Layanan HCE.

Penyelesaian konflik AID

Beberapa komponen HostApduService dapat diinstal di satu perangkat, dan AID yang sama dapat didaftarkan oleh lebih dari satu layanan. Android menyelesaikan AID konflik secara berbeda tergantung pada kategori mana AID berada. Masing-masing mungkin memiliki kebijakan penyelesaian konflik yang berbeda.

Untuk beberapa kategori, seperti pembayaran, pengguna mungkin dapat memilih di UI setelan Android. Untuk kategori lain, kebijakannya mungkin selalu tanyakan kepada pengguna layanan mana yang akan dipanggil jika terjadi konflik. Untuk informasi tentang cara membuat kueri kebijakan penyelesaian konflik untuk kategori tertentu, lihat getSelectionModeForCategory()

Memeriksa apakah layanan Anda adalah layanan default

Aplikasi dapat memeriksa apakah layanan HCE-nya adalah layanan default untuk kategori tertentu dengan menggunakan isDefaultServiceForCategory() Compute Engine API.

Jika layanan Anda bukan default, Anda dapat memintanya untuk dijadikan default menggunakan ACTION_CHANGE_DEFAULT

Aplikasi pembayaran

Android mempertimbangkan layanan HCE yang telah mendeklarasikan grup AID dengan pembayaran sebagai aplikasi pembayaran. Android 4.4 dan yang lebih tinggi berisi entri menu Setelan tingkat atas yang disebut ketuk & pay, yang menghitung semua aplikasi pembayaran semacam itu. Di menu setelan ini, pengguna dapat memilih aplikasi pembayaran {i>default<i} yang dipanggil saat terminal pembayaran diketuk.

Aset yang diperlukan untuk aplikasi pembayaran

Untuk memberikan pengalaman pengguna yang lebih menarik secara visual, aplikasi pembayaran HCE diperlukan untuk menyediakan banner layanan.

Android 13 dan yang lebih baru

Agar lebih cocok dengan daftar pilihan pembayaran default di UI Setelan, sesuaikan persyaratan banner menjadi ikon persegi. Idealnya, itu harus sama dengan desain ikon peluncur aplikasi. Penyesuaian ini membuat Anda lebih konsisten dan terlihat lebih bersih.

Android 12 dan yang lebih lama

Setel ukuran banner layanan ke 260x96 dp, lalu tetapkan ukuran banner layanan di file XML metadata dengan menambahkan atribut android:apduServiceBanner ke tag <host-apdu-service> yang mengarah ke resource drawable. Tujuan berikut adalah contohnya:

<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>

Perilaku layar kunci dan layar nonaktif

Perilaku layanan HCE bervariasi berdasarkan versi Android yang berjalan di perangkat.

Android 12 dan yang lebih baru

Di aplikasi yang menargetkan Android 12 (API level 31) dan yang lebih baru, Anda dapat mengaktifkan NFC pembayaran tanpa mengaktifkan layar perangkat dengan mengatur requireDeviceScreenOn ke false.

Android 10 dan yang lebih baru

Perangkat yang menjalankan Android 10 (level API 29) atau dukungan yang lebih tinggi Aman NFC. Saat Aman NFC aktif, semua emulator kartu (aplikasi host dan aplikasi dari luar host) tidak tersedia saat layar perangkat nonaktif. Saat Amankan NFC nonaktif, di luar host aplikasi tersedia saat layar perangkat mati. Anda dapat memeriksa Amankan dukungan NFC menggunakan isSecureNfcSupported()

Pada perangkat yang menjalankan Android 10 dan yang lebih tinggi, fungsi setelan yang sama android:requireDeviceUnlock hingga true berlaku seperti pada perangkat menjalankan Android 9 dan yang lebih lama, tetapi hanya jika Amankan NFC dinonaktifkan. Artinya, jika Amankan NFC diaktifkan, layanan HCE tidak dapat berfungsi dari layar kunci terlepas dari setelan android:requireDeviceUnlock.

Android 9 dan yang lebih lama

Pada perangkat yang menjalankan Android 9 (API level 28) dan yang lebih rendah, pengontrol NFC dan prosesor aplikasi dimatikan sepenuhnya ketika layar perangkat dimatikan. Oleh karena itu, layanan HCE tidak berfungsi saat layar nonaktif.

Selain itu, di Android 9 dan yang lebih lama, layanan HCE dapat berfungsi dari layar kunci. Namun, hal ini dikontrol oleh atribut android:requireDeviceUnlock di tag <host-apdu-service> layanan HCE Anda. Secara default, buka kunci perangkat tidak diperlukan, dan layanan Anda akan dipanggil bahkan jika perangkat terkunci.

Jika Anda menetapkan atribut android:requireDeviceUnlock ke true untuk HCE Android, Android akan meminta pengguna membuka kunci perangkat terjadi:

pengguna mengetuk pembaca NFC.
pembaca NFC memilih AID yang diselesaikan untuk layanan Anda.

Setelah buka kunci, Android menampilkan dialog yang meminta pengguna mengetuk lagi untuk menyelesaikan transaksi. Hal ini diperlukan karena pengguna mungkin telah memindahkan perangkat Anda dari pembaca NFC untuk membuka kuncinya.

Koeksistensi dengan kartu elemen pengaman

Bagian ini ditujukan bagi developer yang telah men-deploy aplikasi yang mengandalkan elemen pengaman untuk emulasi kartu. Penerapan HCE Android dirancang agar berfungsi secara paralel dengan metode penerapan kartu lainnya emulasi, termasuk penggunaan elemen pengaman.

Koeksistensi ini didasarkan pada prinsip yang disebut perutean AID. NFC {i>controller<i} menyimpan tabel {i>routing<i} yang terdiri dari daftar {i>routing<i} (terbatas) aturan. Setiap aturan perutean berisi AID dan tujuan. Tujuan dapat bisa berupa CPU host, tempat aplikasi Android berjalan, atau jaringan .

Saat pembaca NFC mengirim APDU dengan SELECT AID, pengontrol NFC akan mengurai dan memeriksa apakah AID sesuai dengan AID yang ada di tabel {i>routing<i}-nya. Jika ya cocok, APDU dan semua APDU yang mengikutinya dikirim ke tujuan yang dikaitkan dengan AID, hingga APDU SELECT AID lain diterima atau NFC tautan rusak.

Gambar 4 mengilustrasikan arsitektur ini:

Diagram dengan pembaca NFC yang berkomunikasi dengan elemen pengaman dan CPU
Gambar 4. Android yang beroperasi dengan elemen pengaman dan emulasi kartu host.

Biasanya, pengontrol NFC juga memuat rute default untuk APDU. Jika AID tidak ditemukan dalam tabel perutean. Rute default digunakan. Meskipun ini setelan mungkin berbeda dari satu perangkat ke perangkat lainnya, perangkat Android diperlukan untuk memastikan bahwa AID yang didaftarkan oleh aplikasi Anda diarahkan dengan benar ke {i>host<i}.

Aplikasi Android yang mengimplementasikan layanan HCE atau yang menggunakan elemen pengaman tidak perlu khawatir tentang mengkonfigurasi tabel {i>routing<i}; yang ditangani oleh Android secara otomatis. Android hanya perlu mengetahui AID mana yang dapat ditangani oleh layanan HCE dan mana yang dapat ditangani oleh elemen pengaman. {i>Routing<i} tabel dikonfigurasi secara otomatis berdasarkan layanan mana yang diinstal dan yang telah dikonfigurasi sebagai pilihan pengguna.

Bagian berikut menjelaskan cara mendeklarasikan AID untuk aplikasi yang menggunakan pengaman untuk emulasi kartu.

Pendaftaran AID elemen pengaman

Aplikasi yang menggunakan elemen pengaman untuk emulasi kartu dapat mendeklarasikan layanan luar host dalam manifesnya. Deklarasi layanan tersebut hampir sama dengan deklarasi layanan HCE. Pengecualiannya adalah sebagai berikut ini:

Tindakan yang digunakan dalam filter intent harus disetel ke SERVICE_INTERFACE
Atribut nama metadata harus disetel ke SERVICE_META_DATA

File XML metadata harus menggunakan tag root <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>

Berikut adalah contoh file apduservice.xml yang sesuai mendaftarkan dua 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>

Atribut android:requireDeviceUnlock tidak berlaku untuk layanan di luar host, karena CPU {i>host<i} tidak terlibat dalam transaksi dan karenanya tidak dapat mencegah elemen pengaman mengeksekusi transaksi ketika perangkat terkunci.

Atribut android:apduServiceBanner diperlukan untuk layanan di luar host yang merupakan aplikasi pembayaran dan dapat dipilih sebagai pembayaran default aplikasi.

Pemanggilan layanan di luar host

Android tidak pernah memulai atau mengikat ke layanan yang dideklarasikan sebagai "off-host", karena transaksi sebenarnya dilakukan oleh elemen pengaman dan bukan oleh layanan Android. Deklarasi layanan hanya memungkinkan aplikasi untuk mendaftarkan AID yang ada pada {i>secure element<i}.

HCE dan keamanan

Arsitektur HCE memberikan satu inti keamanan: karena layanan ini dilindungi oleh BIND_NFC_SERVICE izin sistem, hanya OS yang dapat mengikat dan berkomunikasi dengan layanan Anda. Hal ini memastikan bahwa APDU yang Anda terima sebenarnya adalah APDU yang diterima oleh OS dari pengontrol NFC, dan bahwa setiap APDU yang Anda kirim kembali hanya akan OS, yang secara langsung meneruskan APDU ke pengontrol NFC.

Masalah terakhir yang tersisa adalah tempat Anda mendapatkan data yang dikirimkan aplikasi ke pembaca NFC. Hal ini sengaja dipisahkan dalam desain HCE; ya tidak peduli dari mana data itu berasal, tapi hanya memastikan bahwa data tersebut aman diangkut ke pengontrol NFC dan di keluarkan ke pembaca NFC.

Untuk menyimpan dan mengambil data yang ingin Anda kirim dari HCE dengan aman Anda dapat, misalnya, mengandalkan Sandbox Aplikasi Android, mengisolasi data aplikasi Anda dari aplikasi lainnya. Untuk detail selengkapnya tentang Android keamanan, baca Tips keamanan.

Parameter protokol dan detailnya

Bagian ini menarik bagi developer yang ingin memahami protokol apa parameter yang digunakan perangkat HCE selama fase anti-tabrakan dan aktivasi protokol NFC. Hal ini memungkinkan pembuatan infrastruktur pembaca yang yang kompatibel dengan perangkat HCE Android.

Aktivasi dan pencegahan konflik protokol Nfc-A (ISO/IEC 14443 jenis A)

Sebagai bagian dari aktivasi protokol Nfc-A, beberapa frame ditukarkan.

Di bagian pertama pertukaran, perangkat HCE menyajikan UID-nya; Perangkat HCE harus diasumsikan memiliki UID acak. Artinya, di setiap ketukan, UID yang ditampilkan kepada pembaca adalah UID yang dibuat secara acak. Karena ini, Pembaca NFC tidak boleh bergantung pada UID perangkat HCE sebagai bentuk otentikasi atau identifikasi.

Selanjutnya, pembaca NFC dapat memilih perangkat HCE dengan mengirim SEL_REQ perintah. Respons SEL_RES perangkat HCE setidaknya memiliki bit ke-6 (0x20), yang menunjukkan bahwa perangkat mendukung ISO-DEP. Perhatikan bahwa bit lain dalam SEL_RES mungkin juga ditetapkan, yang menunjukkan, misalnya, dukungan untuk NFC-DEP (p2p). Karena bit lain dapat ditetapkan, pembaca ingin berinteraksi dengan Perangkat HCE harus secara eksplisit memeriksa bit ke-6 saja, dan tidak membandingkan SEL_RES lengkap dengan nilai 0x20.

Aktivasi ISO-DEP

Setelah protokol Nfc-A diaktifkan, pembaca NFC akan memulai proses ISO-DEP aktivasi protokol. Komputer mengirimkan RATS ({i>Request for Jawaban To Select<i}) perintah. Pengontrol NFC menghasilkan respons RATS, yaitu ATS; ATS tidak dapat dikonfigurasi oleh layanan HCE. Namun, penerapan HCE harus memenuhi Forum NFC persyaratan untuk respons ATS, sehingga pembaca NFC dapat mengandalkan parameter ini ditetapkan sesuai dengan persyaratan Forum NFC untuk perangkat HCE apa pun.

Bagian di bawah ini memberikan detail lebih lanjut tentang masing-masing byte ATS respons yang diberikan oleh pengontrol NFC pada perangkat HCE:

TL: panjang respons ATS. Tidak boleh menunjukkan panjang yang lebih besar dari 20 {i>byte.<i}
T0: bit 5, 6, dan 7 harus ditetapkan pada semua perangkat HCE, menunjukkan TA(1), TB(1) dan TC(1) termasuk dalam respons ATS. Bit 1 sampai 4 menunjukkan FSCI, mengodekan ukuran {i>frame<i} maksimum. Di perangkat HCE, nilai FSCI harus antara 0 jam dan 8 jam.
T(A)1: menentukan kecepatan bit antara pembaca dan emulator, serta apakah keduanya dapat asimetris. Tidak ada jaminan atau persyaratan kecepatan bit untuk perangkat HCE.
T(B)1: bit 1 sampai 4 menunjukkan Start-up Frame Guard time Integer (SFGI). Aktif Perangkat HCE, SFGI harus <= 8 jam. Bit 5 sampai 8 menunjukkan {i>Frame Menunggu<i} {i>time Integer <i}(FWI) dan mengodekan {i>Frame Menunggu Time<i} (FWT). Di perangkat HCE, FWI harus <= 8j.
T(C)1: bit 5 menunjukkan dukungan untuk "fitur Protokol Lanjutan". Perangkat HCE mungkin mendukung atau tidak mendukung "fitur Protokol Lanjutan". Bit 2 menunjukkan dukungan untuk DID. Perangkat HCE mungkin mendukung DID, mungkin juga tidak. Bit 1 menunjukkan dukungan untuk NAD. Perangkat HCE tidak boleh mendukung NAD dan menetapkan bit 1 ke nol.
Byte historis: Perangkat HCE dapat menampilkan hingga 15 byte historis. NFC pembaca yang ingin berinteraksi dengan layanan HCE tidak boleh membuat asumsi tentang isi dari byte historis atau keberadaannya.

Perhatikan bahwa banyak perangkat HCE yang kemungkinan dibuat sesuai dengan persyaratan protokol yang telah ditetapkan oleh jaringan pembayaran yang tergabung dalam EMVCo dalam Protokol Komunikasi" spesifikasi pendukung. Khususnya:

FSCI di T0 harus antara 2 jam dan 8 jam.
T(A)1 harus disetel ke 0x80, yang mengindikasikan hanya kecepatan bit 106 kbit/dtk yang didukung, dan kecepatan bit asimetris antara pembaca dan emulator tidak didukung.
FWI di T(B)1 harus kurang dari atau sama dengan 7 jam.

Pertukaran data APDU

Seperti disebutkan sebelumnya, penerapan HCE hanya mendukung satu saluran logis. Upaya memilih aplikasi di saluran logis yang berbeda tidak berfungsi perangkat HCE.