Ringkasan emulasi kartu berbasis host

Ada banyak perangkat Android dengan fungsi NFC yang sudah mendukung emulasi kartu NFC. Pada umumnya, kartu diemulasi oleh chip terpisah di perangkat, yang disebut elemen pengaman. Berbagai kartu SIM yang disediakan oleh operator nirkabel juga dilengkapi dengan elemen pengaman.

Android 4.4 memperkenalkan metode emulasi kartu tambahan yang tidak melibatkan elemen pengaman, yang disebut emulasi kartu berbasis host. Metode ini memungkinkan aplikasi Android mengemulasi kartu dan berkomunikasi langsung dengan pembaca NFC. Dokumen 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

Saat emulasi kartu NFC disediakan menggunakan elemen pengaman, kartu yang ingin diemulasi akan disediakan dalam elemen pengaman pada perangkat melalui aplikasi Android. Kemudian, saat pengguna meletakkan perangkat di atas terminal NFC, pengontrol NFC di perangkat akan mengarahkan semua data dari pembaca ke elemen pengaman secara langsung. Gambar 1 mengilustrasikan konsep ini.

Gambar 1. Emulasi kartu NFC dengan elemen pengaman.

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

Emulasi kartu berbasis host

Saat kartu NFC diemulasi menggunakan emulasi kartu berbasis host, data akan diarahkan ke CPU host tempat aplikasi Android berjalan secara langsung, bukan mengarahkan frame protokol NFC ke elemen pengaman. Gambar 2 mengilustrasikan cara kerja emulasi kartu berbasis host.

Gambar 2. Emulasi kartu NFC tanpa elemen pengaman.

Kartu dan protokol NFC yang didukung

Gambar 3. Stack protokol HCE Android.

Standar NFC menawarkan dukungan untuk berbagai protokol, dan ada berbagai jenis kartu yang dapat diemulasi.

Android 4.4 mendukung beberapa protokol yang umum tersedia di pasaran saat ini. Berbagai kartu nirsentuh yang ada sudah didasarkan pada protokol ini, seperti kartu pembayaran nirsentuh. Protokol ini juga didukung oleh banyak pembaca NFC yang ada di pasaran saat ini, termasuk perangkat NFC Android yang berfungsi sebagai pembaca itu sendiri (lihat class IsoDep). Hal ini memungkinkan Anda membuat dan menerapkan solusi NFC menyeluruh untuk HCE hanya dengan menggunakan perangkat Android.

Android 4.4 terutama mendukung emulasi kartu yang didasarkan pada spesifikasi ISO-DEP NFC-Forum (berdasarkan ISO/IEC 14443-4) dan Application Protocol Data Unit (APDU) proses seperti yang ditetapkan dalam spesifikasi ISO/IEC 7816-4. Android memerintahkan agar ISO-DEP hanya diemulasi di atas teknologi Nfc-A (ISO/IEC 14443-3 Jenis A). Dukungan untuk teknologi Nfc-B (ISO/IEC 14443-4 Jenis B) bersifat opsional. Lapisan semua spesifikasi ini ditunjukkan pada gambar 3.

Layanan HCE

Arsitektur HCE di Android didasarkan pada komponen Service Android (yang disebut "layanan HCE"). Salah satu keunggulan utama layanan ini adalah dapat berjalan di latar belakang tanpa antarmuka pengguna. Hal ini cocok untuk berbagai aplikasi HCE seperti kartu transit atau loyalitas, sehingga pengguna tidak perlu membuka aplikasi untuk menggunakannya. Sebagai gantinya, menempelkan perangkat dengan pembaca NFC akan memulai layanan yang tepat (jika belum berjalan) dan melakukan transaksi di latar belakang. Namun, Anda tetap dapat meluncurkan UI tambahan (seperti notifikasi pengguna) dari layanan jika diperlukan.

Pilihan layanan

Saat pengguna menempelkan perangkat ke pembaca NFC, sistem Android perlu mencari tahu layanan HCE yang benar-benar ingin diakses pembaca NFC. Di sinilah spesifikasi ISO/IEC 7816-4 berperan: spesifikasi ini menentukan cara memilih aplikasi, yang dipusatkan pada ID Aplikasi (AID). AID terdiri atas maksimum 16 byte. Jika Anda mengemulasi kartu untuk infrastruktur pembaca NFC yang ada, AID yang dicari oleh pembaca biasanya terdaftar secara publik dan terkenal (misalnya, jaringan pembayaran AID seperti Visa dan MasterCard).

Jika ingin menerapkan infrastruktur pembaca baru untuk aplikasi Anda, Anda harus mendaftarkan AID sendiri. Prosedur pendaftaran AID ditentukan dalam spesifikasi ISO/IEC 7816-5. Jika menerapkan aplikasi HCE untuk Android, sebaiknya Anda mendaftarkan AID sesuai dengan 7816-5 karena akan menghindari konflik dengan aplikasi lain.

Grup AID

Terkadang, layanan HCE mungkin perlu mendaftarkan beberapa AID untuk menerapkan aplikasi tertentu, dan perlu memastikan bahwa layanan tersebut adalah pengendali default untuk semua AID ini (bukan beberapa AID dalam grup yang dialihkan ke layanan lain).

Grup AID adalah daftar AID yang harus dianggap sebagai satu kesatuan oleh OS. Untuk semua AID dalam grup AID, Android menjamin salah satu dari 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 batasan ketika AID dalam grup dapat diarahkan ke satu layanan HCE, dan beberapa diarahkan ke layanan lain.

Grup dan kategori AID

Setiap grup AID dapat dikaitkan dengan suatu kategori. Hal ini memungkinkan Android mengelompokkan layanan HCE berdasarkan kategori, yang kemudian memungkinkan pengguna menyetel default di tingkat kategori, bukan tingkat AID. Secara umum, hindari menyebutkan AID di bagian sisi pengguna dari aplikasi Anda karena tidak berarti apa-apa bagi pengguna biasa.

Android 4.4 mendukung dua kategori: CATEGORY_PAYMENT (yang mencakup aplikasi pembayaran standar industri) dan CATEGORY_OTHER (untuk semua aplikasi HCE lainnya).

Catatan: Hanya satu grup AID dalam kategori CATEGORY_PAYMENT yang dapat diaktifkan di sistem pada waktu tertentu. Biasanya, grup AID ini akan berupa aplikasi yang memahami protokol pembayaran kartu kredit utama dan yang dapat berfungsi di semua penjual.

Untuk aplikasi pembayaran loop tertutup yang hanya berfungsi di satu penjual (seperti kartu penyimpanan dana), Anda harus menggunakan CATEGORY_OTHER. Grup AID dalam kategori ini dapat selalu diaktifkan, dan dapat diprioritaskan oleh pembaca NFC selama pemilihan AID jika perlu.

Menerapkan layanan HCE

Untuk mengemulasi kartu NFC menggunakan emulasi kartu berbasis host, Anda perlu membuat komponen Service yang akan menangani transaksi NFC.

Memeriksa dukungan HCE

Aplikasi Anda dapat mencari tahu apakah perangkat mendukung HCE atau tidak dengan memeriksa fitur FEATURE_NFC_HOST_CARD_EMULATION. Anda harus menggunakan tag <uses-feature> di manifes aplikasi untuk mendeklarasikan bahwa aplikasi menggunakan fitur HCE, dan apakah fitur ini diperlukan agar aplikasi berfungsi atau tidak.

Pelaksanaan layanan

Android 4.4 dilengkapi dengan class Service praktis yang dapat digunakan sebagai dasar untuk menerapkan layanan HCE, yaitu class HostApduService.

Oleh karena itu, langkah pertamanya adalah meluaskan 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 mendeklarasikan dua metode abstrak yang perlu diganti dan diterapkan.

processCommandApdu() dipanggil setiap kali pembaca NFC mengirim Application Protocol Data Unit (APDU) ke layanan Anda. APDU juga 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 berupa setengah dupleks: pembaca NFC akan mengirimkan APDU perintah kepada Anda, dan menunggu Anda mengirim kembali APDU respons.

Catatan: Spesifikasi ISO/IEC 7816-4 juga menentukan konsep beberapa saluran logis, tempat Anda dapat menjalankan beberapa pertukaran APDU paralel pada saluran logis terpisah. Namun, penerapan HCE oleh Android hanya mendukung satu saluran logis, sehingga hanya ada satu pertukaran thread tunggal APDU.

Seperti yang disebutkan sebelumnya, Android menggunakan AID untuk menentukan layanan HCE yang ingin diakses pembaca. Biasanya, APDU pertama yang dikirim pembaca NFC ke perangkat Anda adalah APDU "SELECT AID"; APDU ini berisi AID yang ingin diakses pembaca. Android mengekstrak AID tersebut dari APDU, menetapkannya ke layanan HCE, lalu meneruskan APDU tersebut ke layanan yang ditetapkan.

Anda dapat mengirim APDU respons dengan menunjukkan byte APDU respons dari processCommandApdu(). Perhatikan bahwa metode ini akan dipanggil pada thread utama aplikasi Anda, yang tidak boleh diblokir. Oleh karena itu, jika Anda tidak dapat segera menghitung dan menunjukkan APDU respons, tampilkan nilai null. Lalu, Anda dapat melakukan tugas yang diperlukan pada thread lain, dan menggunakan metode sendResponseApdu() yang ditentukan dalam class HostApduService untuk mengirim respons setelah selesai.

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

  1. Pembaca NFC mengirim APDU "SELECT AID" lain, yang ditetapkan oleh OS ke layanan yang berbeda;
  2. Link NFC antara pembaca NFC dan perangkat Anda rusak.

Dalam kedua kasus ini, penerapan class onDeactivated() Anda akan dipanggil dengan argumen yang menunjukkan kasus mana yang terjadi.

Jika menggunakan infrastruktur pembaca yang sudah ada, Anda perlu menerapkan protokol tingkat aplikasi yang sudah ada yang diharapkan pembaca dalam layanan HCE Anda.

Jika menerapkan infrastruktur pembaca baru yang juga Anda kontrol, Anda dapat menentukan protokol dan urutan APDU sendiri. Secara umum, coba batasi jumlah APDU dan ukuran data yang perlu ditukarkan: tindakan ini akan memastikan bahwa pengguna hanya perlu meletakkan perangkatnya di atas pembaca NFC dalam waktu singkat. Batas atas yang wajar adalah sekitar 1 KB data, yang biasanya dapat ditukarkan dalam waktu 300 milidetik.

Deklarasi manifes layanan dan pendaftaran AID

Layanan Anda harus dideklarasikan dalam manifes seperti biasa, tetapi beberapa bagian tambahan juga harus ditambahkan ke deklarasi layanan.

Pertama, untuk memberi tahu platform bahwa antarmuka HostApduService diterapkan oleh layanan HCE, deklarasi layanan Anda harus berisi filter intent untuk tindakan SERVICE_INTERFACE.

Selain itu, untuk memberi tahu platform tentang grup AID yang diminta oleh layanan ini, tag <meta-data> SERVICE_META_DATA harus disertakan dalam deklarasi layanan, yang mengarah ke resource XML dengan informasi tambahan tentang layanan HCE.

Terakhir, Anda harus menetapkan atribut android:exported ke true, dan mendapatkan izin "android.permission.BIND_NFC_SERVICE" dalam deklarasi layanan. Poin pertama memastikan bahwa layanan dapat diikat oleh aplikasi eksternal. Kemudian, poin kedua menetapkan bahwa hanya aplikasi eksternal yang memiliki izin "android.permission.BIND_NFC_SERVICE" yang dapat diikat ke layanan Anda. Karena "android.permission.BIND_NFC_SERVICE" adalah izin sistem, izin ini secara efektif menetapkan 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. Contoh file tersebut dengan satu deklarasi grup AID yang berisi dua AID eksklusif ditampilkan di bawah ini:

    <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 memuat atribut <android:description> yang berisi deskripsi layanan yang mudah digunakan dan dapat ditampilkan di UI. Atribut requireDeviceUnlock dapat digunakan untuk menentukan bahwa kunci perangkat harus dibuka agar layanan ini dapat dipanggil untuk menangani APDU.

<host-apdu-service> harus berisi satu atau beberapa tag <aid-group>. Setiap tag <aid-group> harus:

  • Memuat atribut android:description yang berisi deskripsi grup AID yang mudah digunakan dan cocok untuk ditampilkan di UI.
  • Menetapkan atribut android:category untuk menunjukkan kategori grup AID, misalnya konstanta string yang ditentukan oleh CATEGORY_PAYMENT atau CATEGORY_OTHER.
  • Setiap <aid-group> harus berisi satu atau beberapa tag <aid-filter>, yang masing-masing berisi satu AID. AID tersebut harus ditentukan dalam format heksadesimal, dan berisi jumlah karakter genap.

Sebagai catatan akhir, aplikasi Anda juga perlu menyimpan izin NFC agar dapat 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. Penyelesaian konflik AID oleh platform Android bergantung pada kategori yang dimiliki AID. Masing-masing kategori mungkin memiliki kebijakan penyelesaian konflik yang berbeda.

Misalnya, untuk beberapa kategori (seperti pembayaran), pengguna mungkin dapat memilih layanan default di UI setelan Android. Untuk kategori lain, kebijakan tersebut mungkin selalu bertanya kepada pengguna mengenai layanan mana yang akan dipanggil jika terjadi konflik. Untuk mengkueri kebijakan penyelesaian konflik bagi 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(ComponentName, String) API.

Jika bukan default, Anda dapat meminta agar layanan Anda dijadikan default. Lihat ACTION_CHANGE_DEFAULT.

Aplikasi pembayaran

Android menganggap layanan HCE yang telah mendeklarasikan grup AID dengan kategori "pembayaran" sebagai aplikasi pembayaran. Rilis Android 4.4 menghadirkan entri menu Setelan tingkat atas yang disebut “tempel & bayar”, yang memerinci semua aplikasi pembayaran tersebut. Dalam menu setelan ini, pengguna dapat memilih aplikasi pembayaran default yang akan diminta saat terminal pembayaran ditempelkan.

Aset yang diperlukan untuk aplikasi pembayaran

Untuk memberikan pengalaman pengguna dengan tampilan yang lebih menarik, aplikasi pembayaran HCE harus menyediakan aset tambahan bagi layanannya, yang disebut banner layanan.

Aset ini harus berukuran 260x96 dp, dan dapat ditentukan dalam file metadata XML Anda dengan menambahkan atribut android:apduServiceBanner ke tag <host-apdu-service>, yang mengarah ke resource yang dapat digambar. Contohnya ditampilkan di bawah ini.

    <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

Penerapan Android saat ini menonaktifkan pengontrol NFC dan pemroses aplikasi sepenuhnya saat layar perangkat dinonaktifkan. Oleh karena itu, layanan HCE tidak akan berfungsi saat layar nonaktif.

Namun, layanan HCE dapat digunakan dari layar kunci: hal ini dikontrol oleh atribut android:requireDeviceUnlock dalam tag <host-apdu-service> layanan HCE Anda. Secara default, kunci perangkat tidak perlu dibuka, dan layanan Anda tetap akan dipanggil meskipun perangkat terkunci.

Jika Anda menetapkan atribut android:requireDeviceUnlock ke “true” untuk layanan HCE, Android akan meminta pengguna membuka kunci perangkat saat Anda menempelkan pembaca NFC yang memilih AID yang ditetapkan ke layanan. Setelah kunci perangkat dibuka, Android akan menampilkan dialog yang meminta pengguna menempelkan sekali lagi untuk menyelesaikan transaksi. Tindakan ini diperlukan karena pengguna mungkin telah menjauhkan perangkat dari pembaca NFC untuk membuka kuncinya.

Koeksistensi dengan kartu elemen pengaman

Bagian ini ditujukan untuk developer yang telah menerapkan aplikasi yang menggunakan elemen pengaman untuk emulasi kartu. Implementasi HCE oleh Android dirancang agar berfungsi dengan metode penerapan emulasi kartu lainnya, termasuk penggunaan elemen pengaman.

Catatan: Android tidak menyediakan API untuk berkomunikasi langsung dengan elemen pengaman.

Koeksistensi ini didasarkan pada prinsip yang disebut "perutean AID": pengontrol NFC menyimpan tabel perutean yang berisi daftar aturan perutean (terbatas). Setiap aturan perutean berisi AID dan tujuan. Tujuan dapat berupa CPU host (tempat aplikasi Android berjalan), atau elemen pengaman yang tersambung.

Saat pembaca NFC mengirim APDU dengan “SELECT AID”, pengontrol NFC akan mengurainya dan memeriksa apakah AID cocok dengan AID 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.

Catatan: Meskipun ISO/IEC 7816-4 juga menentukan konsep “cocok sebagian”, konsep ini belum didukung oleh perangkat HCE Android.

Arsitektur ini diilustrasikan dalam Gambar 4.

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 akan digunakan. Meskipun setelan ini mungkin berbeda antar-perangkat, perangkat Android perlu memastikan bahwa AID yang didaftarkan oleh aplikasi Anda diarahkan dengan benar ke host.

Aplikasi Android yang menerapkan layanan HCE atau yang menggunakan elemen pengaman tidak perlu mengonfigurasi tabel perutean karena akan 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. Berdasarkan layanan yang diinstal dan yang dikonfigurasi pengguna sebagai layanan pilihan, tabel perutean dikonfigurasi secara otomatis.

Kami telah menjelaskan cara mendeklarasikan AID untuk layanan HCE. 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 di luar host” di dalam manifesnya. Deklarasi layanan tersebut hampir sama dengan deklarasi layanan HCE. Pengecualiannya adalah:

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

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 pengaman menjalankan transaksi saat perangkat terkunci.

Atribut android:apduServiceBanner harus digunakan untuk layanan di luar host yang juga merupakan aplikasi pembayaran agar dapat dipilih sebagai aplikasi pembayaran default.

Pemanggilan layanan di luar host

Android tidak akan pernah memulai atau mengikat ke layanan yang dideklarasikan sebagai "layanan di luar host". Hal ini karena transaksi yang sebenarnya dijalankan oleh elemen pengaman, bukan oleh layanan Android itu sendiri. Deklarasi layanan hanya memungkinkan aplikasi mendaftarkan AID yang ada pada elemen pengaman.

HCE dan keamanan

Arsitektur HCE menyediakan 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 memastikan bahwa APDU yang Anda terima sebenarnya adalah APDU yang diterima oleh OS dari pengontrol NFC, dan APDU yang Anda kirim kembali hanya akan diarahkan ke OS, yang kemudian langsung meneruskan APDU ke pengontrol NFC.

Bagian inti yang tersisa adalah tempat Anda mendapatkan data yang dikirimkan aplikasi ke pembaca NFC. Bagian ini sengaja dipisahkan dalam desain HCE, karena tidak ditujukan untuk mencari tahu asal data, hanya memastikan bahwa data tersebut dipindahkan ke pengontrol NFC dan dikirim ke pembaca NFC dengan aman.

Untuk menyimpan dan mengambil data yang ingin dikirim dari layanan HCE dengan aman, Anda dapat, misalnya, menggunakan Sandbox Aplikasi Android, yang memisahkan data aplikasi Anda dari aplikasi lain. Untuk detail selengkapnya tentang keamanan Android, baca Tips Keamanan.

Parameter protokol dan detailnya

Bagian ini ditujukan untuk developer yang ingin mempelajari parameter protokol yang digunakan perangkat HCE selama fase aktivasi dan pencegahan konflik 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. Ini artinya setiap kali ditempelkan, UID yang ditampilkan kepada pembaca akan berupa UID yang dibuat secara acak. Oleh karena itu, pembaca NFC tidak boleh menggunakan UID perangkat HCE sebagai bentuk autentikasi atau identifikasi.

Selanjutnya, pembaca NFC dapat memilih perangkat HCE dengan mengirim perintah SEL_REQ. Respons SEL_RES perangkat HCE setidaknya akan menetapkan bit ke-6 (0x20), yang menunjukkan bahwa perangkat mendukung ISO-DEP. Perhatikan bahwa bit lain dalam SEL_RES juga dapat ditetapkan, yang menunjukkan dukungan untuk protokol NFC-DEP (P2P). Karena bit lain dapat ditetapkan, pembaca yang ingin berinteraksi dengan perangkat HCE hanya perlu secara eksplisit memeriksa bit ke-6, 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. Pembaca NFC akan mengirim perintah "RATS" (Request for Answer To Select). Respons RATS, yaitu ATS, sepenuhnya dibuat oleh pengontrol NFC dan tidak dapat dikonfigurasi oleh layanan HCE. Namun, penerapan HCE harus memenuhi persyaratan Forum NFC untuk respons ATS, sehingga pembaca NFC dapat menggunakan parameter ini yang ditetapkan sesuai dengan persyaratan Forum NFC untuk perangkat HCE apa pun.

Bagian di bawah ini menjelaskan lebih lanjut tentang setiap byte respons ATS yang disediakan oleh pengontrol NFC pada perangkat HCE:

  • TL: panjang respons ATS. Tidak boleh menunjukkan panjang yang lebih 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 bersifat 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 kurang dari atau sama dengan 8 jam. Bit 5 sampai 8 menunjukkan Frame Waiting time Integer (FWI) dan mengodekan Frame Waiting Time (FWT). Di perangkat HCE, FWI harus kurang dari atau sama dengan 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 tentang isi byte historis atau keberadaannya.

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

  • FSCI di T0 harus antara 2 jam dan 8 jam.
  • T(A)1 harus ditetapkan ke 0x80, yang menunjukkan bahwa hanya kecepatan 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 yang disebutkan sebelumnya, penerapan HCE hanya mendukung satu saluran logis. Upaya memilih aplikasi pada saluran logis yang berbeda tidak akan berfungsi di perangkat HCE.