Banyak perangkat Android yang menawarkan fungsi NFC sudah mendukung emulasi kartu NFC. Pada umumnya, kartu diemulasi oleh chip 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 emulasi kartu tambahan yang tidak melibatkan elemen pengaman, yang disebut emulasi kartu berbasis host. Hal ini memungkinkan semua aplikasi Android mengemulasi kartu dan berkomunikasi langsung dengan pembaca NFC. Topik ini menjelaskan cara kerja emulasi kartu berbasis host (HCE) di Android dan cara mengembangkan aplikasi yang mengemulasi kartu NFC menggunakan teknik ini.
Emulasi kartu dengan elemen pengaman
Jika emulasi kartu NFC disediakan menggunakan elemen pengaman, kartu yang akan diemulasikan akan disediakan ke dalam elemen pengaman di perangkat melalui aplikasi Android. Kemudian, saat pengguna memegang perangkat di atas terminal NFC, pengontrol NFC di perangkat akan mengarahkan semua data dari pembaca langsung ke elemen aman. Gambar 1 menggambarkan konsep ini:
Elemen pengaman melakukan komunikasi dengan terminal NFC, dan tidak ada aplikasi Android yang terlibat dalam transaksi. Setelah transaksi selesai, aplikasi Android dapat mengkueri elemen pengaman secara langsung untuk mengetahui 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 host, bukan diarahkan ke elemen pengaman. Gambar 2 mengilustrasikan cara kerja emulasi kartu berbasis host:
Kartu dan protokol NFC yang didukung
Standar NFC menawarkan dukungan untuk berbagai protokol, dan ada berbagai jenis kartu yang dapat Anda emulasikan.
Android 4.4 dan yang lebih tinggi mendukung beberapa protokol yang umum tersedia di pasar
saat ini. Banyak kartu nirsentuh yang sudah ada didasarkan pada protokol ini,
seperti kartu pembayaran nirsentuh. Protokol ini juga didukung oleh banyak
pembaca NFC yang ada di pasar saat ini, termasuk perangkat NFC Android yang berfungsi sebagai
pembaca itu sendiri (lihat class
IsoDep
). Hal ini memungkinkan Anda membuat dan men-deploy solusi NFC menyeluruh di sekitar
HCE hanya dengan 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 Unit Data Protokol Aplikasi (APDU) proses seperti yang ditetapkan dalam spesifikasi ISO/IEC 7816-4. Android mengizinkan emulasi ISO-DEP hanya di atas teknologi Nfc-A (ISO/IEC 14443-3 Tipe A). Dukungan untuk teknologi Nfc-B (ISO/IEC 14443-4 Tipe B) bersifat opsional. Gambar 3 mengilustrasikan pelapisan semua spesifikasi ini.
Layanan HCE
Arsitektur HCE di Android didasarkan pada komponen
Service
Android (dikenal sebagai layanan
HCE). Salah satu keunggulan utama layanan ini adalah dapat berjalan di
latar belakang tanpa antarmuka pengguna apa pun. Hal ini cocok untuk banyak aplikasi
HCE, seperti kartu loyalitas atau transportasi umum, yang tidak diperlukan pengguna untuk
meluncurkan aplikasi untuk digunakan. Sebagai gantinya, menempelkan perangkat dengan pembaca NFC akan memulai
layanan yang benar jika belum berjalan dan menjalankan transaksi
di latar belakang. Tentu saja, Anda bebas meluncurkan UI tambahan (seperti
notifikasi pengguna) dari layanan jika memungkinkan.
Pilihan layanan
Saat pengguna menempelkan perangkat ke pembaca NFC, sistem Android perlu mengetahui layanan HCE mana yang ingin diajak berkomunikasi oleh pembaca NFC. Spesifikasi ISO/IEC 7816-4 menentukan cara untuk memilih aplikasi, yang berpusat pada ID Aplikasi (AID). Sebuah AID terdiri dari maksimal 16 byte. Jika Anda mengemulasi kartu untuk infrastruktur pembaca NFC yang sudah ada, AID yang dicari pembaca tersebut biasanya sudah dikenal dan terdaftar secara publik (misalnya, AID jaringan pembayaran seperti Visa dan MasterCard).
Jika ingin men-deploy infrastruktur pembaca baru untuk aplikasi, Anda harus mendaftarkan AID sendiri. Prosedur pendaftaran AID ditentukan dalam spesifikasi ISO/IEC 7816-5. Sebaiknya daftarkan AID sesuai dengan 7816-5 jika Anda men-deploy aplikasi HCE untuk Android agar dapat 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 agar dapat mengimplementasikan aplikasi tertentu. Beberapa AID dalam grup yang dipindahkan ke layanan lain tidak didukung.
Daftar AID yang disimpan bersama disebut grup AID. Untuk semua AID dalam grup AID, Android menjamin salah satu hal berikut:
- Semua AID dalam grup diarahkan ke layanan HCE ini.
- Tidak ada AID dalam grup yang diarahkan ke layanan HCE ini (misalnya, karena pengguna lebih memilih layanan lain yang juga meminta satu atau beberapa AID dalam grup Anda).
Dengan kata lain, tidak ada pengalihan antara status, saat beberapa AID dalam grup dapat diarahkan ke satu layanan HCE, dan beberapa AID ke layanan lainnya.
Grup dan kategori AID
Anda dapat mengaitkan setiap grup AID dengan kategori. Hal ini memungkinkan Android mengelompokkan layanan HCE berdasarkan kategori, sehingga pengguna dapat menyetel setelan default di tingkat kategori, bukan tingkat AID. Hindari menyebutkan AID di bagian aplikasi yang dilihat pengguna, karena tidak berarti apa-apa bagi pengguna biasa.
Android 4.4 dan yang lebih tinggi mendukung dua kategori:
CATEGORY_PAYMENT
(mencakup aplikasi pembayaran standar industri)CATEGORY_OTHER
(untuk semua aplikasi HCE lainnya)
Menerapkan layanan HCE
Untuk mengemulasi kartu NFC menggunakan emulasi kartu berbasis host, Anda perlu membuat
komponen Service
yang menangani transaksi NFC.
Memeriksa dukungan HCE
Aplikasi Anda dapat memeriksa apakah perangkat mendukung HCE dengan memeriksa
fitur
FEATURE_NFC_HOST_CARD_EMULATION
. Gunakan tag <uses-feature>
dalam manifes aplikasi untuk mendeklarasikan bahwa aplikasi Anda menggunakan fitur
HCE, dan apakah fitur tersebut 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: class HostApduService
.
Langkah pertama adalah memperluas HostApduService
, seperti yang ditunjukkan pada contoh kode
berikut:
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
implementasikan. Salah satunya,
processCommandApdu()
,
dipanggil setiap kali pembaca NFC mengirim Application Protocol Data Unit (APDU)
ke layanan Anda. APDU ditentukan dalam spesifikasi ISO/IEC 7816-4. APDU
adalah paket tingkat aplikasi yang dipertukarkan antara pembaca NFC dan
layanan HCE Anda. Protokol tingkat aplikasi tersebut adalah half-duplex: pembaca NFC
mengirimkan APDU perintah, dan menunggu Anda mengirim APDU respons
sebagai gantinya.
Seperti yang disebutkan sebelumnya, Android menggunakan AID untuk menentukan layanan HCE mana
yang ingin diajak pembaca. Biasanya, APDU pertama yang dikirim oleh pembaca NFC ke
perangkat Anda adalah APDU SELECT AID
; APDU ini berisi AID yang ingin
dikomunikasikan oleh pembaca. Android mengekstrak AID tersebut dari APDU, me-resolvenya ke layanan
HCE, lalu meneruskan APDU tersebut ke layanan yang di-resolve.
Anda dapat mengirim APDU respons dengan menampilkan byte APDU respons dari
processCommandApdu()
. Perhatikan, metode ini dipanggil pada thread utama
aplikasi Anda dan tidak boleh Anda blokir. Jika Anda tidak dapat segera menghitung dan menampilkan
APDU respons, tampilkan null. Selanjutnya, Anda dapat melakukan pekerjaan yang diperlukan di
thread lain dan menggunakan metode
sendResponseApdu()
yang ditentukan dalam class HostApduService
untuk mengirim respons setelah
selesai.
Android akan terus meneruskan APDU baru dari pembaca ke layanan Anda hingga salah satu hal berikut terjadi:
- Pembaca NFC akan mengirimkan APDU
SELECT AID
lain, yang ditetapkan oleh OS ke layanan yang berbeda. - Link NFC antara pembaca NFC dan perangkat Anda rusak.
Dalam kedua kasus ini, implementasi
onDeactivated()
class Anda akan dipanggil dengan argumen yang menunjukkan manakah dari keduanya yang terjadi.
Jika menggunakan infrastruktur pembaca yang sudah ada, Anda harus menerapkan protokol tingkat aplikasi yang sudah ada yang diharapkan pembaca dalam layanan HCE Anda.
Jika men-deploy infrastruktur pembaca baru yang juga dikontrol, Anda dapat menentukan protokol dan urutan APDU Anda sendiri. Coba batasi jumlah APDU dan ukuran data yang akan dipertukarkan: tindakan ini memastikan pengguna hanya perlu mendekatkan perangkat di atas pembaca NFC dalam waktu singkat. Batas atas yang wajar adalah sekitar 1 KB data, yang biasanya dapat dipertukarkan dalam waktu 300 md.
Deklarasi manifes layanan dan pendaftaran AID
Anda harus mendeklarasikan layanan di manifes seperti biasa, tetapi Anda juga harus menambahkan beberapa bagian tambahan ke deklarasi layanan:
Untuk memberi tahu platform bahwa ini adalah layanan HCE yang mengimplementasikan antarmuka
HostApduService
, tambahkan filter intent untuk tindakanSERVICE_INTERFACE
ke deklarasi layanan Anda.Untuk memberi tahu platform grup AID mana yang diminta oleh layanan ini, sertakan tag
SERVICE_META_DATA
<meta-data>
dalam deklarasi layanan, yang mengarah ke resource XML dengan informasi tambahan tentang layanan HCE.Tetapkan atribut
android:exported
ketrue
, dan wajibkan izinandroid.permission.BIND_NFC_SERVICE
dalam deklarasi layanan Anda. Poin pertama memastikan bahwa layanan dapat diikat oleh aplikasi eksternal. Selanjutnya, ketentuan ini menetapkan bahwa hanya aplikasi eksternal yang memiliki izinandroid.permission.BIND_NFC_SERVICE
yang dapat diikat ke layanan Anda. Karenaandroid.permission.BIND_NFC_SERVICE
adalah izin sistem, hal ini secara efektif memberlakukan bahwa hanya Android OS yang dapat diikat 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 dengan satu deklarasi grup AID yang berisi dua
AID kepemilikan:
<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 layanan yang mudah digunakan dan dapat ditampilkan di
UI aplikasi. Anda dapat menggunakan atribut requireDeviceUnlock
untuk menentukan bahwa
perangkat tidak terkunci sebelum memanggil layanan ini untuk menangani APDU.
<host-apdu-service>
harus berisi satu atau beberapa tag <aid-group>
. Setiap
tag <aid-group>
harus melakukan hal berikut:
- Berisi atribut
android:description
yang berisi deskripsi grup AID yang mudah digunakan dan cocok untuk ditampilkan di UI. - Menyetel atribut
android:category
untuk menunjukkan kategori yang mencakup grup AID, seperti konstanta string yang ditentukan olehCATEGORY_PAYMENT
atauCATEGORY_OTHER
. - Berisi satu atau beberapa tag
<aid-filter>
, yang masing-masing berisi satu AID. Tentukan AID dalam format heksadesimal, dan pastikan AID berisi jumlah karakter genap.
Aplikasi Anda juga harus memiliki
izin NFC
untuk mendaftar sebagai
layanan HCE.
Penyelesaian konflik AID
Beberapa komponen HostApduService
dapat diinstal pada satu perangkat, dan
AID yang sama dapat didaftarkan oleh lebih dari satu layanan. Android mengatasi konflik
AID secara berbeda bergantung pada kategori AID. Setiap
kategori dapat memiliki kebijakan penyelesaian konflik yang berbeda.
Untuk beberapa kategori, seperti pembayaran, pengguna mungkin dapat memilih layanan
default di UI setelan Android. Untuk kategori lain, kebijakannya mungkin
selalu bertanya kepada pengguna layanan mana yang akan dipanggil jika terjadi konflik. Untuk mengetahui informasi
tentang cara membuat kueri kebijakan resolusi 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 menggunakan
isDefaultServiceForCategory()
API.
Jika layanan Anda tidak menjadi default, Anda dapat memintanya untuk dijadikan default
menggunakan
ACTION_CHANGE_DEFAULT
.
Aplikasi pembayaran
Android menganggap layanan HCE yang telah mendeklarasikan grup AID dengan kategori pembayaran sebagai aplikasi pembayaran. Android 4.4 dan yang lebih baru berisi entri menu Setelan level teratas yang disebut ketuk & bayar, yang menghitung semua aplikasi pembayaran tersebut. Dalam menu setelan ini, pengguna dapat memilih aplikasi pembayaran default yang akan dipanggil saat terminal pembayaran diketuk.
Aset yang diperlukan untuk aplikasi pembayaran
Untuk memberikan pengalaman pengguna yang lebih menarik secara visual, aplikasi pembayaran HCE harus menyediakan banner layanan.
Android 13 dan yang lebih baru
Agar lebih sesuai dengan daftar pilihan pembayaran default di UI Setelan, sesuaikan persyaratan banner ke ikon persegi. Idealnya, ikon ini harus identik dengan desain ikon peluncur aplikasi. Penyesuaian ini menghasilkan konsistensi dan tampilan yang 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. 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 pembayaran
NFC tanpa mengaktifkan layar perangkat dengan menetapkan
requireDeviceScreenOn
ke
false
.
Android 10 dan yang lebih baru
Perangkat yang menjalankan Android 10 (API level 29) atau yang lebih baru mendukung
Secure
NFC. Saat Secure
NFC aktif, semua emulator kartu (aplikasi host dan aplikasi nonaktif host) tidak
tersedia saat layar perangkat nonaktif. Saat Secure NFC nonaktif, aplikasi off-host
akan tersedia saat layar perangkat nonaktif. Anda dapat memeriksa
dukungan NFC Aman menggunakan
isSecureNfcSupported()
.
Pada perangkat yang menjalankan Android 10 dan yang lebih baru, fungsi yang sama untuk menyetel
android:requireDeviceUnlock
ke true
berlaku seperti pada perangkat
yang menjalankan Android 9 dan yang lebih lama, tetapi hanya saat Amankan NFC dinonaktifkan. Artinya, jika
NFC Aman 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 dinonaktifkan sepenuhnya saat layar perangkat dinonaktifkan. Oleh karena itu, layanan HCE tidak berfungsi saat layar mati.
Selain itu, di Android 9 dan yang lebih rendah, layanan HCE dapat berfungsi dari layar kunci.
Namun, hal ini dikontrol oleh atribut android:requireDeviceUnlock
dalam
tag <host-apdu-service>
layanan HCE Anda. Secara default, buka kunci perangkat
tidak diperlukan, dan layanan Anda dipanggil meskipun perangkat terkunci.
Jika Anda menyetel atribut android:requireDeviceUnlock
ke true
untuk layanan
HCE, Android akan meminta pengguna untuk membuka kunci perangkat saat hal berikut
terjadi:
- pengguna mengetuk pembaca NFC.
- pembaca NFC akan memilih AID yang diselesaikan ke layanan Anda.
Setelah membuka kunci, Android akan menampilkan dialog yang meminta pengguna mengetuk lagi untuk menyelesaikan transaksi. Hal ini diperlukan karena pengguna mungkin telah memindahkan perangkat dari pembaca NFC untuk membuka kuncinya.
Koeksistensi dengan kartu elemen pengaman
Bagian ini ditujukan untuk developer yang telah men-deploy aplikasi yang mengandalkan elemen pengaman untuk emulasi kartu. Penerapan HCE Android dirancang agar berfungsi secara paralel dengan metode penerapan emulasi kartu lainnya, termasuk penggunaan elemen pengaman.
Koeksistensi ini didasarkan pada prinsip yang disebut pemilihan rute AID. Pengontrol NFC menyimpan tabel perutean yang berisi daftar aturan perutean (terbatas). Setiap aturan perutean berisi AID dan tujuan. Tujuannya dapat berupa CPU host, tempat aplikasi Android berjalan, atau elemen aman yang terhubung.
Saat pembaca NFC mengirimkan APDU dengan SELECT AID
, pengontrol NFC akan mengurainya
dan memeriksa apakah AID cocok dengan AID apa pun dalam tabel peruteannya. Jika
cocok, APDU tersebut dan semua APDU yang mengikutinya akan dikirim ke tujuan
yang terkait dengan AID, hingga APDU SELECT AID
lain diterima atau link
NFC rusak.
Gambar 4 mengilustrasikan arsitektur ini:
Biasanya, pengontrol NFC juga memuat rute default untuk APDU. Jika AID tidak ditemukan dalam tabel perutean, rute default akan digunakan. Meskipun setelan ini mungkin berbeda dari satu perangkat ke perangkat lainnya, perangkat Android perlu memastikan bahwa AID yang didaftarkan oleh aplikasi Anda dirutekan dengan benar ke host.
Aplikasi Android yang menerapkan layanan HCE atau yang menggunakan elemen pengaman tidak perlu mengonfigurasi tabel perutean; 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. Tabel perutean dikonfigurasi secara otomatis berdasarkan layanan mana yang diinstal dan yang telah dikonfigurasi pengguna sebagai pilihan.
Bagian berikut menjelaskan cara mendeklarasikan AID untuk aplikasi yang menggunakan elemen pengaman untuk emulasi kartu.
Pendaftaran AID elemen pengaman
Aplikasi yang menggunakan elemen pengaman untuk emulasi kartu dapat mendeklarasikan layanan off-host dalam manifesnya. Deklarasi layanan tersebut hampir sama dengan deklarasi layanan HCE. Pengecualiannya adalah sebagai berikut:
- Tindakan yang digunakan dalam filter intent harus ditetapkan ke
SERVICE_INTERFACE
. - Atribut nama metadata harus ditetapkan 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
yang 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 host tidak terlibat dalam transaksi, sehingga tidak dapat
mencegah elemen aman mengeksekusi transaksi saat perangkat
dikunci.
Atribut android:apduServiceBanner
diperlukan untuk layanan bukan host
yang merupakan aplikasi pembayaran dan dapat dipilih sebagai aplikasi pembayaran
default.
Pemanggilan layanan di luar host
Android tidak pernah memulai atau mengikat ke layanan yang dideklarasikan sebagai "off-host", karena transaksi sebenarnya dijalankan oleh elemen pengaman dan bukan oleh layanan Android. Deklarasi layanan hanya mengizinkan aplikasi mendaftarkan AID yang ada pada elemen pengaman.
HCE dan keamanan
Arsitektur HCE memberikan satu bagian inti keamanan: karena layanan
Anda dilindungi oleh
izin sistem
BIND_NFC_SERVICE
, hanya OS yang dapat mengikat dan berkomunikasi dengan layanan Anda.
Hal ini untuk memastikan bahwa APDU yang Anda terima sebenarnya adalah APDU yang diterima
OS dari pengontrol NFC, dan setiap APDU yang Anda kirim kembali hanya dimasukkan ke
OS, yang kemudian langsung meneruskan APDU ke pengontrol NFC.
Masalah terakhir yang tersisa adalah tempat Anda mendapatkan data yang dikirimkan aplikasi ke pembaca NFC. Bagian ini sengaja dipisahkan dalam desain HCE. Namun, tidak peduli dari mana data berasal, melainkan hanya memastikan bahwa data tersebut dipindahkan dengan aman ke pengontrol NFC dan keluar ke pembaca NFC.
Untuk menyimpan dan mengambil data yang ingin dikirim dari layanan HCE dengan aman, Anda dapat, misalnya, mengandalkan Sandbox Aplikasi Android, yang memisahkan data aplikasi dari aplikasi lain. Untuk detail selengkapnya tentang keamanan Android, baca Tips keamanan.
Parameter protokol dan detailnya
Bagian ini ditujukan untuk developer yang ingin memahami parameter protokol yang digunakan perangkat HCE selama fase anti tabrakan dan aktivasi protokol NFC. Hal ini memungkinkan pembuatan infrastruktur pembaca 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 akan menampilkan UID-nya; perangkat HCE harus diasumsikan memiliki UID acak. Artinya, pada setiap ketukan, UID yang ditampilkan kepada pembaca adalah UID yang dibuat secara acak. Oleh karena itu, pembaca NFC tidak boleh bergantung pada UID perangkat HCE sebagai bentuk autentikasi atau identifikasi.
Selanjutnya, pembaca NFC dapat memilih perangkat HCE dengan mengirimkan perintah
SEL_REQ
. Respons SEL_RES
perangkat HCE memiliki setidaknya kumpulan
bit ke-6 (0x20), yang menunjukkan bahwa perangkat mendukung ISO-DEP. Perhatikan bahwa bit lain dalam
SEL_RES
juga dapat ditetapkan, yang menunjukkan contoh dukungan untuk protokol
NFC-DEP (p2p). Karena bit lain dapat ditetapkan, pembaca yang 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 aktivasi protokol ISO-DEP. Klien mengirimkan perintah RATS (Request for Answer To Select). Pengontrol NFC menghasilkan respons RATS, yaitu ATS; ATS tidak dapat dikonfigurasi oleh layanan HCE. Namun, penerapan HCE harus memenuhi persyaratan Forum NFC untuk respons ATS, sehingga pembaca NFC dapat mengandalkan parameter ini yang ditetapkan sesuai dengan persyaratan Forum NFC untuk perangkat HCE apa pun.
Bagian di bawah ini memberikan detail selengkapnya tentang setiap byte respons ATS yang disediakan oleh pengontrol NFC pada perangkat HCE:
- TL: panjang respons ATS. Tidak boleh menunjukkan panjang yang lebih besar dari 20 byte.
- T0: bit 5, 6, dan 7 harus ditetapkan di semua perangkat HCE, yang menunjukkan bahwa TA(1), TB(1), dan TC(1) disertakan dalam respons ATS. Bit 1 sampai 4 menunjukkan FSCI, yang mengodekan ukuran frame 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). Di perangkat HCE, SFGI harus <= 8 jam. Bit 5 sampai 8 menunjukkan Frame Waiting time Integer (FWI) dan mengkodekan Frame Waiting Time (FWT). Di perangkat HCE, FWI harus <= 8 jam.
- T(C)1: bit 5 menunjukkan dukungan untuk "fitur Protokol Lanjutan". Perangkat HCE mungkin mendukung "fitur Protokol Lanjutan", mungkin juga tidak. 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. Pembaca NFC yang ingin berinteraksi dengan layanan HCE tidak boleh membuat asumsi mengenai konten byte historis atau keberadaannya.
Perhatikan bahwa banyak perangkat HCE kemungkinan dibuat sesuai dengan persyaratan protokol yang telah ditentukan oleh jaringan pembayaran yang terpadu di EMVCo dalam spesifikasi "Protokol Komunikasi Tanpa Kontak" mereka. Khususnya:
- FSCI di T0 harus antara 2 jam dan 8 jam.
- T(A)1 harus disetel ke 0x80, yang menunjukkan bahwa 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. Mencoba memilih aplikasi pada saluran logis yang berbeda tidak akan berfungsi di perangkat HCE.