Tổng quan về mô phỏng thẻ dựa trên máy chủ

Nhiều thiết bị chạy Android cung cấp chức năng NFC đã hỗ trợ NFC mô phỏng thẻ. Trong hầu hết các trường hợp, thẻ được mô phỏng bởi một khối riêng biệt trong được gọi là phần tử bảo mật. Nhiều thẻ SIM do nhà mạng không dây cung cấp cũng chứa phần tử bảo mật.

Android 4.4 trở lên cung cấp thêm một phương thức mô phỏng thẻ không liên quan đến phần tử bảo mật, được gọi là mô phỏng thẻ dựa trên máy chủ. Chiến dịch này cho phép mọi ứng dụng Android mô phỏng một thẻ và giao tiếp trực tiếp với NFC người đọc. Chủ đề này mô tả cách hoạt động của quy trình mô phỏng thẻ dựa trên máy chủ (HCE) Android và cách bạn có thể phát triển một ứng dụng mô phỏng thẻ NFC bằng cách sử dụng kỹ thuật.

Mô phỏng thẻ có phần tử bảo mật

Khi bạn mô phỏng thẻ NFC bằng một phần tử bảo mật, thẻ cần được được cung cấp trong phần tử bảo mật trên thiết bị thông qua một . Sau đó, khi người dùng giữ thiết bị phía trước một thiết bị đầu cuối NFC, NFC trình điều khiển trong thiết bị sẽ định tuyến tất cả dữ liệu từ trình đọc đến . Hình 1 minh hoạ khái niệm này:

Sơ đồ cho thấy trình đọc NFC đi qua bộ điều khiển NFC để truy xuất thông tin từ phần tử bảo mật
Hình 1. Mô phỏng thẻ NFC với phần tử bảo mật.

Phần tử bảo mật này tự thực hiện hoạt động giao tiếp với thiết bị đầu cuối NFC và không có ứng dụng Android nào tham gia vào giao dịch. Sau khi giao dịch thì một ứng dụng Android có thể truy vấn trực tiếp phần tử bảo mật này để trạng thái giao dịch và thông báo cho người dùng.

Mô phỏng thẻ dựa trên máy chủ

Khi thẻ NFC được mô phỏng bằng quy trình mô phỏng thẻ dựa trên máy chủ, dữ liệu sẽ được định tuyến trực tiếp đến CPU lưu trữ thay vì được định tuyến đến một phần tử bảo mật. Hình 2 minh hoạ cách hoạt động của quy trình mô phỏng thẻ dựa trên máy chủ:

Sơ đồ cho thấy trình đọc NFC đi qua bộ điều khiển NFC để truy xuất thông tin từ CPU
Hình 2. Mô phỏng thẻ NFC mà không có phần tử bảo mật.

Giao thức và thẻ NFC được hỗ trợ

Sơ đồ minh hoạ ngăn xếp giao thức HCE
Hình 3. Ngăn xếp giao thức HCE của Android.

Các tiêu chuẩn NFC cung cấp hỗ trợ cho nhiều giao thức khác nhau và có nhiều loại thẻ mà bạn có thể mô phỏng.

Android 4.4 trở lên hỗ trợ một số giao thức phổ biến trên thị trường ngay hôm nay. Nhiều thẻ không tiếp xúc hiện có đã dựa trên các giao thức này, chẳng hạn như thẻ thanh toán không tiếp xúc. Các giao thức này cũng được nhiều giao thức hỗ trợ Trình đọc NFC trên thị trường hiện nay, bao gồm cả thiết bị NFC trên Android hoạt động như chính độc giả (xem IsoDep ). Điều này cho phép bạn xây dựng và triển khai giải pháp NFC toàn diện xung quanh HCE chỉ sử dụng các thiết bị hỗ trợ Android.

Cụ thể, Android 4.4 trở lên hỗ trợ các thẻ mô phỏng dựa trên thông số kỹ thuật ISO-DEP của Diễn đàn NFC (dựa trên ISO/IEC 14443-4) và quy trình Đơn vị dữ liệu giao thức ứng dụng (APDU) theo định nghĩa trong ISO/IEC 7816-4 đặc điểm kỹ thuật. Android chỉ yêu cầu mô phỏng ISO-DEP ở đầu Nfc-A Công nghệ (ISO/IEC 14443-3 Loại A). Hỗ trợ Nfc-B (ISO/IEC 14443-4 Loại B) công nghệ là tuỳ chọn. Hình 3 minh hoạ việc phân lớp của tất cả các thông số kỹ thuật.

Dịch vụ HCE

Kiến trúc HCE trong Android dựa trên Android Các thành phần Service (còn gọi là HCE) d.vụ). Một trong những ưu điểm chính của dịch vụ là có thể chạy trong nền mà không có bất kỳ giao diện người dùng nào. Đây là sự phù hợp tự nhiên cho nhiều HCE như thẻ khách hàng thân thiết hoặc thẻ đi phương tiện công cộng mà người dùng không cần khởi chạy một ứng dụng để sử dụng. Thay vào đó, việc chạm thiết bị vào trình đọc NFC sẽ bắt đầu dịch vụ phù hợp nếu dịch vụ chưa chạy và thực thi giao dịch ở chế độ nền. Tất nhiên, bạn có thể thoải mái phát hành giao diện người dùng bổ sung (chẳng hạn như thông báo cho người dùng) từ dịch vụ của bạn khi thích hợp.

Lựa chọn dịch vụ

Khi người dùng đưa thiết bị đến gần thiết bị đọc NFC, hệ thống Android cần biết dịch vụ HCE mà trình đọc NFC muốn giao tiếp. ISO/IEC 7816-4 thông số kỹ thuật xác định cách chọn ứng dụng, tập trung xung quanh Mã ứng dụng (AID). Một AID bao gồm tối đa 16 byte. Nếu bạn đang mô phỏng cho cơ sở hạ tầng trình đọc NFC hiện có, AID mà những độc giả đó tìm kiếm thường nổi tiếng và được đăng ký công khai (ví dụ: ID của các mạng thanh toán như Visa và MasterCard).

Nếu muốn triển khai cơ sở hạ tầng đọc mới cho ứng dụng của mình, bạn phải đăng ký AID của riêng mình. Quy trình đăng ký AID được định nghĩa trong thông số kỹ thuật ISO/IEC 7816-5. Bạn nên đăng ký AID theo 7816-5 nếu bạn đang triển khai ứng dụng HCE cho Android, vì ứng dụng này sẽ tránh xung đột với các ứng dụng khác.

Nhóm AID

Trong một số trường hợp, dịch vụ HCE có thể cần đăng ký nhiều mã AID và được đặt thành trình xử lý mặc định cho tất cả các AID để triển khai một . Một số AID trong nhóm chuyển đến một dịch vụ khác không được hỗ trợ.

Danh sách các AID được giữ lại cùng nhau được gọi là nhóm AID. Đối với tất cả các AID trong một AID, Android đảm bảo một trong những điều sau:

  • Tất cả AID trong nhóm được định tuyến đến dịch vụ HCE này.
  • Không có AID nào trong nhóm được định tuyến đến dịch vụ HCE này (ví dụ: người dùng ưa thích một dịch vụ khác yêu cầu một hoặc nhiều AID trong nhóm của bạn ).

Nói cách khác, không có trạng thái ở giữa, nơi mà một số AID trong nhóm có thể được định tuyến đến một dịch vụ HCE và một số đến dịch vụ khác.

Nhóm và danh mục AID

Bạn có thể liên kết mỗi nhóm AID với một danh mục. Thao tác này cho phép Android nhóm Các dịch vụ HCE được kết hợp với nhau theo danh mục và từ đó cho phép người dùng đặt mặc định ở cấp danh mục thay vì cấp AID. Tránh đề cập đến AID trong bất kỳ phần nào dành cho người dùng trong ứng dụng của bạn vì chúng không có ý nghĩa cho người dùng thông thường.

Android 4.4 trở lên hỗ trợ 2 danh mục:

  • CATEGORY_PAYMENT (bao gồm các ứng dụng thanh toán theo tiêu chuẩn ngành)
  • CATEGORY_OTHER (đối với tất cả các ứng dụng HCE khác)

Triển khai dịch vụ HCE

Để mô phỏng thẻ NFC bằng cách sử dụng quy trình mô phỏng thẻ dựa trên máy chủ, bạn cần tạo một Thành phần Service xử lý các giao dịch NFC.

Kiểm tra xem có hỗ trợ HCE không

Ứng dụng của bạn có thể kiểm tra xem thiết bị có hỗ trợ HCE hay không bằng cách kiểm tra FEATURE_NFC_HOST_CARD_EMULATION của chúng tôi. Sử dụng <uses-feature> trong tệp kê khai của ứng dụng để khai báo rằng ứng dụng sử dụng HCE và liệu ứng dụng có bắt buộc phải hoạt động hay không.

Triển khai dịch vụ

Android 4.4 trở lên cung cấp lớp Service tiện lợi mà bạn có thể sử dụng làm cơ sở cho việc triển khai dịch vụ HCE: Lớp HostApduService.

Bước đầu tiên là mở rộng HostApduService, như minh hoạ trong mã sau mẫu:

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 khai báo 2 phương thức trừu tượng mà bạn phải ghi đè và triển khai. Một trong số đó, processCommandApdu()! được gọi bất cứ khi nào trình đọc NFC gửi Đơn vị dữ liệu giao thức ứng dụng (APDU) đối với dịch vụ của bạn. APDU được định nghĩa trong thông số kỹ thuật ISO/IEC 7816-4. Các APDU các gói cấp ứng dụng được trao đổi giữa trình đọc NFC và dịch vụ HCE của bạn. Giao thức cấp ứng dụng đó là giao thức bán song công: trình đọc NFC sẽ gửi cho bạn một APDU lệnh và chờ bạn gửi APDU phản hồi trong lợi nhuận.

Như đã đề cập trước đó, Android sử dụng AID để xác định dịch vụ HCE nào mà độc giả muốn trò chuyện. Thông thường, APDU đầu tiên mà trình đọc NFC gửi đến thiết bị là một APDU SELECT AID; APDU này chứa AID mà độc giả muốn để trò chuyện. Android trích xuất AID từ APDU, phân giải AID đó thành HCE rồi chuyển tiếp APDU đó đến dịch vụ đã phân giải.

Bạn có thể gửi APDU phản hồi bằng cách trả về các byte của APDU phản hồi từ processCommandApdu(). Lưu ý rằng phương thức này được gọi trên luồng chính của ứng dụng mà bạn không nên chặn. Nếu bạn không thể tính toán và trả về APDU phản hồi ngay lập tức, trả về giá trị rỗng. Sau đó, bạn có thể thực hiện công việc cần thiết trên một chuỗi khác và sử dụng sendResponseApdu() được xác định trong lớp HostApduService để gửi phản hồi khi bạn xong.

Android liên tục chuyển tiếp APDU mới từ trình đọc đến dịch vụ của bạn cho đến khi trong số sau sẽ xảy ra:

  • Trình đọc NFC sẽ gửi một APDU SELECT AID khác mà hệ điều hành sẽ phân giải thành một dịch vụ khác nhau.
  • Liên kết NFC giữa trình đọc NFC và thiết bị của bạn bị hỏng.

Trong cả hai trường hợp này, lớp của bạn onDeactivated() phương thức triển khai được gọi với một đối số cho biết đối số nào trong số hai lần thực thi đã xảy ra.

Nếu đang làm việc với cơ sở hạ tầng độc giả hiện có, bạn phải triển khai giao thức cấp ứng dụng hiện có mà độc giả mong đợi trong dịch vụ HCE của bạn.

Nếu đang triển khai cơ sở hạ tầng độc giả mới mà bạn cũng kiểm soát, bạn có thể xác định giao thức và trình tự APDU của riêng mình. Cố gắng hạn chế số lượng APDU và kích thước của dữ liệu cần trao đổi: điều này đảm bảo rằng người dùng chỉ có giữ thiết bị của họ trước máy đọc NFC trong một khoảng thời gian ngắn. Đáp giới hạn trên hợp lý là khoảng 1 KB dữ liệu, thường là được đổi trong vòng 300 mili giây.

Khai báo tệp kê khai dịch vụ và đăng ký AID

Bạn phải khai báo dịch vụ của mình trong tệp kê khai như bình thường, nhưng cũng phải thêm một số các phần bổ sung vào phần khai báo dịch vụ:

  1. Để cho nền tảng biết đó là một dịch vụ HCE, bằng cách triển khai một Giao diện HostApduService, hãy thêm bộ lọc ý định cho phần tử SERVICE_INTERFACE đối với nội dung khai báo dịch vụ.

  2. Để cho nền tảng biết những nhóm AID mà dịch vụ này yêu cầu, hãy thêm một SERVICE_META_DATA Thẻ <meta-data> trong phần khai báo dịch vụ, trỏ đến một XML cung cấp thêm thông tin về dịch vụ HCE.

  3. Đặt thuộc tính android:exported thành true và yêu cầu Quyền android.permission.BIND_NFC_SERVICE trong phần khai báo dịch vụ. Cấu hình trước đảm bảo rằng các ứng dụng bên ngoài có thể liên kết dịch vụ. Sau đó, chính sách này thực thi rằng chỉ những ứng dụng bên ngoài chứa Quyền android.permission.BIND_NFC_SERVICE có thể liên kết với dịch vụ của bạn. Vì android.permission.BIND_NFC_SERVICE là một quyền hệ thống nên nút này thực thi hiệu quả việc chỉ hệ điều hành Android mới có thể liên kết với dịch vụ của bạn.

Sau đây là ví dụ về nội dung khai báo tệp kê khai 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>

Thẻ siêu dữ liệu này trỏ đến một tệp apduservice.xml. Sau đây là một ví dụ về tệp như vậy với một khai báo nhóm AID duy nhất chứa hai các AID thuộc quyền sở hữu riêng:

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

Thẻ <host-apdu-service> phải chứa thuộc tính <android:description> có chứa nội dung mô tả thân thiện với người dùng về dịch vụ mà bạn có thể hiển thị giao diện người dùng của ứng dụng. Bạn có thể sử dụng thuộc tính requireDeviceUnlock để chỉ định rằng thiết bị được mở khoá trước khi bạn gọi dịch vụ này để xử lý APDU.

<host-apdu-service> phải chứa một hoặc nhiều thẻ <aid-group>. Một Cần có thẻ <aid-group> để thực hiện những việc sau:

  • Chứa thuộc tính android:description thân thiện với người dùng nội dung mô tả nhóm AID, phù hợp để hiển thị trong giao diện người dùng.
  • Đặt thuộc tính android:category để biểu thị danh mục chứa AID thuộc về nhóm đó, chẳng hạn như hằng số chuỗi do CATEGORY_PAYMENT xác định hoặc CATEGORY_OTHER.
  • Chứa một hoặc nhiều thẻ <aid-filter>, mỗi thẻ chứa một AID duy nhất. Chỉ định AID ở định dạng thập lục phân và đảm bảo AID có chứa giá trị chẵn số lượng ký tự.

Ứng dụng của bạn cũng cần lưu giữ Quyền NFC để đăng ký làm Dịch vụ HCE.

Giải quyết xung đột AID

Bạn có thể cài đặt nhiều thành phần HostApduService trên một thiết bị, và cùng một AID có thể được đăng ký bởi nhiều dịch vụ. Android giải quyết được AID xung đột theo cách khác nhau, tuỳ thuộc vào danh mục của một AID. Một có thể có chính sách giải quyết xung đột khác.

Đối với một số danh mục, chẳng hạn như thanh toán, người dùng có thể chọn một khoản thanh toán mặc định trong giao diện người dùng cài đặt Android. Đối với các danh mục khác, chính sách có thể áp dụng luôn hỏi người dùng xem dịch vụ nào gọi trong trường hợp xung đột. Để biết thông tin về cách truy vấn chính sách giải quyết xung đột cho một danh mục nhất định, hãy xem getSelectionModeForCategory().

Kiểm tra xem dịch vụ của bạn có phải là dịch vụ mặc định không

Các ứng dụng có thể kiểm tra xem dịch vụ HCE của mình có phải là dịch vụ mặc định cho danh mục nhất định bằng cách sử dụng isDefaultServiceForCategory() API.

Nếu dịch vụ của bạn không phải là dịch vụ mặc định, bạn có thể yêu cầu đặt dịch vụ đó làm mặc định đang sử dụng ACTION_CHANGE_DEFAULT.

Ứng dụng thanh toán

Android xem xét các dịch vụ HCE đã khai báo nhóm AID bằng thanh toán dưới dạng ứng dụng thanh toán. Android 4.4 trở lên có chứa mục nhập cấp cao nhất trong trình đơn Cài đặt có tên là nhấn và pay, liệt kê tất cả các ứng dụng thanh toán như vậy. Trong trình đơn cài đặt này, người dùng có thể chọn ứng dụng thanh toán mặc định để gọi khi một thiết bị thanh toán được nhấn vào.

Thành phần bắt buộc cho ứng dụng thanh toán

Để cung cấp trải nghiệm người dùng hấp dẫn hơn về mặt hình ảnh, ứng dụng thanh toán HCE đều phải cung cấp biểu ngữ dịch vụ.

Android 13 trở lên

Để vừa hơn với danh sách lựa chọn thanh toán mặc định trong Giao diện người dùng Cài đặt, hãy điều chỉnh biểu ngữ thành biểu tượng hình vuông. Tốt nhất là mã nên giống với thiết kế biểu tượng của trình chạy ứng dụng. Sự điều chỉnh này sẽ tạo ra sự nhất quán hơn và giao diện rõ ràng hơn.

Android 12 trở xuống

Đặt kích thước của biểu ngữ dịch vụ thành 260x96 dp, sau đó đặt kích thước của biểu ngữ dịch vụ trong tệp XML siêu dữ liệu bằng cách thêm thuộc tính android:apduServiceBanner vào thẻ <host-apdu-service> trỏ đến tài nguyên có thể vẽ. Chiến lược phát hành đĩa đơn sau đây là ví dụ:

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

Thao tác tắt màn hình và hành vi khi khoá màn hình

Hành vi của các dịch vụ HCE thay đổi tuỳ theo phiên bản Android chạy trên thiết bị.

Android 12 trở lên

Trong ứng dụng nhắm đến Android 12 (API cấp 31) trở lên, bạn có thể bật NFC thanh toán mà không cần bật màn hình thiết bị bằng cách cài đặt requireDeviceScreenOn đến false.

Android 10 trở lên

Thiết bị có hỗ trợ Android 10 (API cấp 29) trở lên An toàn Công nghệ Giao tiếp phạm vi gần (NFC). Trong khi bảo mật NFC đang bật, tất cả trình mô phỏng thẻ (ứng dụng lưu trữ và ứng dụng bên ngoài máy chủ) không khả dụng khi màn hình thiết bị đang tắt. Khi NFC bảo mật đang tắt, ngoài máy chủ lưu trữ các ứng dụng vẫn có sẵn khi màn hình thiết bị tắt. Bạn có thể kiểm tra Bảo mật hỗ trợ NFC bằng isSecureNfcSupported().

Trên các thiết bị chạy Android 10 trở lên, chế độ cài đặt này có chức năng tương tự android:requireDeviceUnlock cho true áp dụng như với các thiết bị chạy Android 9 trở xuống, nhưng chỉ khi NFC bảo mật đang tắt. Tức là, nếu NFC bảo mật đang bật, các dịch vụ HCE không thể hoạt động trên màn hình khoá bất kể chế độ cài đặt android:requireDeviceUnlock là gì.

Android 9 trở xuống

Trên các thiết bị chạy Android 9 (API cấp 28) trở xuống, bộ điều khiển NFC và bộ xử lý ứng dụng bị tắt hoàn toàn khi màn hình của đã tắt. Do đó, dịch vụ HCE không hoạt động khi màn hình tắt.

Ngoài ra, trên Android 9 trở xuống, các dịch vụ HCE có thể hoạt động trên màn hình khoá. Tuy nhiên, việc này do thuộc tính android:requireDeviceUnlock trong thẻ <host-apdu-service> của dịch vụ HCE. Theo mặc định, tính năng mở khoá thiết bị là không bắt buộc và dịch vụ của bạn sẽ được gọi ngay cả khi thiết bị bị khoá.

Nếu bạn đặt thuộc tính android:requireDeviceUnlock thành true cho HCE , Android sẽ nhắc người dùng mở khoá thiết bị khi: xảy ra:

  • người dùng nhấn vào một trình đọc NFC.
  • trình đọc NFC chọn một AID đã được phân giải cho dịch vụ của bạn.

Sau khi mở khoá, Android sẽ hiển thị một hộp thoại nhắc người dùng nhấn lại để hoàn tất giao dịch. Điều này là cần thiết vì người dùng có thể đã di chuyển thiết bị cách xa trình đọc NFC để mở khoá.

Có thể cùng tồn tại với các thẻ phần tử bảo mật

Các nhà phát triển đã triển khai ứng dụng sẽ quan tâm đến phần này dựa vào một phần tử bảo mật để mô phỏng thẻ. Triển khai HCE của Android được thiết kế để hoạt động song song với các phương pháp triển khai thẻ khác mô phỏng, bao gồm cả việc sử dụng các phần tử bảo mật.

Sự cùng tồn tại này dựa trên nguyên tắc có tên là định tuyến AID. NFC bộ điều khiển lưu giữ một bảng định tuyến bao gồm một danh sách (có hạn) các định tuyến quy tắc. Mỗi quy tắc định tuyến chứa một AID và một đích đến. Đích đến có thể có thể là CPU máy chủ, nơi các ứng dụng Android đang chạy hoặc một .

Khi trình đọc NFC gửi APDU có SELECT AID, bộ điều khiển NFC sẽ phân tích cú pháp mã này và kiểm tra xem các AID có khớp với bất kỳ AID nào trong bảng định tuyến hay không. Nếu khớp với APDU đó và tất cả các APDU sau đó được gửi đến đích được liên kết với AID, cho đến khi nhận được một SELECT AID APDU khác hoặc NFC liên kết bị hỏng.

Hình 4 minh hoạ cấu trúc này:

Sơ đồ có trình đọc NFC giao tiếp với cả phần tử bảo mật và CPU
Hình 4. Android hoạt động với cả phần tử bảo mật và quy trình mô phỏng thẻ máy chủ.

Bộ điều khiển NFC thường cũng chứa một tuyến mặc định cho APDU. Khi một Không tìm thấy AID trong bảng định tuyến, tuyến mặc định được sử dụng. Trong khi cài đặt có thể khác nhau giữa các thiết bị, bạn phải cung cấp thiết bị Android để đảm bảo rằng AID đang được ứng dụng của bạn đăng ký được định tuyến đúng cách đến máy chủ lưu trữ.

Ứng dụng Android triển khai dịch vụ HCE hoặc sử dụng phần tử bảo mật không phải lo lắng về việc định cấu hình bảng định tuyến; được xử lý bởi Android tự động. Android chỉ cần biết có thể xử lý AID nào bằng các dịch vụ HCE và những dịch vụ nào có thể được phần tử bảo mật xử lý. Tuyến đường được định cấu hình tự động dựa trên các dịch vụ được cài đặt và mà người dùng đã định cấu hình là ưu tiên.

Phần sau đây giải thích cách khai báo AID cho các ứng dụng sử dụng phần tử bảo mật để mô phỏng thẻ.

Đăng ký AID phần tử bảo mật

Các ứng dụng sử dụng phần tử bảo mật để mô phỏng thẻ có thể khai báo dịch vụ bên ngoài máy chủ lưu trữ trong tệp kê khai. Việc khai báo dịch vụ này gần giống với phần khai báo dịch vụ HCE. Có dạng ngoại lệ như sau: sau:

  • Hành động được dùng trong bộ lọc ý định phải được đặt thành SERVICE_INTERFACE.
  • Thuộc tính tên siêu dữ liệu phải được đặt thành SERVICE_META_DATA.

  • Tệp XML siêu dữ liệu phải sử dụng thẻ gốc <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>

Sau đây là ví dụ về tệp apduservice.xml tương ứng đăng ký hai 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>

Thuộc tính android:requireDeviceUnlock không áp dụng cho các dịch vụ không lưu trữ, bởi vì CPU máy chủ không tham gia vào giao dịch và do đó không thể ngăn phần tử bảo mật thực thi giao dịch khi thiết bị đã khoá.

Thuộc tính android:apduServiceBanner là bắt buộc đối với các dịch vụ không lưu trữ là các ứng dụng thanh toán và có thể chọn làm ứng dụng thanh toán mặc định .

Lệnh gọi dịch vụ không lưu trữ

Android không bao giờ khởi động hoặc liên kết với một dịch vụ được khai báo là "ngoài máy chủ lưu trữ" vì các giao dịch thực tế được thực thi bởi phần tử bảo mật chứ không phải bằng dịch vụ Android. Phần khai báo dịch vụ chỉ cho phép các ứng dụng đăng ký các AID có trên phần tử bảo mật.

HCE và bảo mật

Kiến trúc HCE cung cấp một phần bảo mật cốt lõi: vì được bảo vệ bởi BIND_NFC_SERVICE quyền hệ thống, chỉ hệ điều hành mới có thể liên kết và giao tiếp với dịch vụ của bạn. Điều này đảm bảo rằng mọi APDU bạn nhận được đều thực sự là APDU mà hệ điều hành từ bộ điều khiển NFC và mọi APDU bạn gửi lại chỉ thuộc về hệ điều hành, sau đó sẽ chuyển tiếp trực tiếp APDU đến bộ điều khiển NFC.

Mối quan tâm cuối cùng còn lại là nơi bạn nhận được dữ liệu mà ứng dụng của bạn gửi đến trình đọc NFC. Thành phần này được phân tách có chủ đích trong thiết kế HCE; nó có không quan tâm đến nguồn gốc của dữ liệu mà chỉ đảm bảo rằng dữ liệu được an toàn được truyền tới bộ điều khiển NFC và tới đầu đọc NFC.

Để lưu trữ và truy xuất an toàn dữ liệu mà bạn muốn gửi từ HCE , bạn có thể dựa vào Hộp cát ứng dụng Android, tách riêng dữ liệu ứng dụng của bạn với các ứng dụng khác. Để biết thêm chi tiết về Android bảo mật, hãy đọc Mẹo bảo mật.

Thông số và thông tin chi tiết về giao thức

Các nhà phát triển quan tâm đến phần này nếu muốn tìm hiểu giao thức nào các tham số mà thiết bị HCE sử dụng trong giai đoạn chống xung đột và kích hoạt của giao thức NFC. Điều này cho phép xây dựng một cơ sở hạ tầng độc giả tương thích với các thiết bị Android HCE.

Giao thức Nfc-A (ISO/IEC 14443 loại A) chống xung đột và kích hoạt

Trong quá trình kích hoạt giao thức Nfc-A, nhiều khung hình sẽ được trao đổi.

Trong phần đầu tiên của quá trình trao đổi, thiết bị HCE sẽ trình bày UID; Thiết bị HCE phải được giả định là có một UID ngẫu nhiên. Điều này có nghĩa là mỗi lần nhấn, UID mà hiển thị với trình đọc là một UID được tạo ngẫu nhiên. Do đó, Trình đọc NFC không nên phụ thuộc vào UID của thiết bị HCE dưới dạng xác thực hoặc nhận dạng.

Sau đó, trình đọc NFC có thể chọn thiết bị HCE bằng cách gửi một SEL_REQ . Phản hồi SEL_RES của thiết bị HCE có ít nhất bit thứ 6 (0x20) được đặt, cho biết thiết bị hỗ trợ ISO-DEP. Lưu ý rằng các bit khác trong bạn cũng có thể đặt SEL_RES, ví dụ như có hỗ trợ NFC-DEP (p2p). Vì các bit khác có thể được thiết lập, nên độc giả muốn tương tác với Thiết bị HCE chỉ nên kiểm tra rõ ràng cho bit thứ 6 và không so sánh SEL_RES hoàn chỉnh có giá trị 0x20.

Kích hoạt ISO-DEP

Sau khi giao thức Nfc-A được kích hoạt, trình đọc NFC sẽ bắt đầu ISO-DEP kích hoạt giao thức. Tính năng này sẽ gửi RATS (Yêu cầu trả lời để chọn) . Bộ điều khiển NFC tạo ra phản hồi RATS, ATS; ATS không có thể định cấu hình bằng các dịch vụ HCE. Tuy nhiên, việc triển khai HCE phải đáp ứng Diễn đàn NFC các yêu cầu đối với phản hồi ATS, để trình đọc NFC có thể tin tưởng vào các thông số này được đặt theo các yêu cầu của Diễn đàn NFC cho mọi thiết bị HCE.

Phần dưới đây cung cấp thêm thông tin chi tiết về từng byte của ATS phản hồi do bộ điều khiển NFC trên thiết bị HCE cung cấp:

  • TL: độ dài của phản hồi ATS. Không được chỉ ra độ dài lớn hơn 20 byte.
  • T0: các bit 5, 6 và 7 phải được thiết lập trên tất cả các thiết bị HCE, biểu thị TA(1), TB(1) và TC(1) được đưa vào phản hồi ATS. Các bit từ 1 đến 4 biểu thị FSCI, mã hoá kích thước khung tối đa. Trên thiết bị HCE, giá trị của FSCI phải là trong khoảng từ 0 giờ đến 8 giờ.
  • T(A)1: xác định tốc độ bit giữa trình đọc và trình mô phỏng, cũng như liệu chúng có thể bất đối xứng. Không có yêu cầu về tốc độ bit hay đảm bảo đối với thiết bị HCE.
  • T(B)1: các bit 1 đến 4 biểu thị số nguyên thời gian bảo vệ khung khởi động (SFGI). Bật Thiết bị HCE, SFGI phải <= 8h. Các bit 5 đến 8 biểu thị khung đang chờ số nguyên thời gian (FWI) và mã hoá Thời gian chờ khung (FWT). Trên các thiết bị HCE, FWI phải <= 8 giờ.
  • T(C)1: bit 5 biểu thị sự hỗ trợ cho "Các tính năng của giao thức nâng cao". Thiết bị HCE có thể hỗ trợ hoặc không hỗ trợ "Các tính năng Giao thức nâng cao". Bit 2 biểu thị hỗ trợ cho DID. Các thiết bị HCE có thể hỗ trợ hoặc không hỗ trợ DID. Bit 1 biểu thị hỗ trợ cho NAD. Thiết bị HCE không được hỗ trợ NAD và đặt bit 1 thành 0.
  • Số byte trước đây: Thiết bị HCE có thể trả về tối đa 15 byte trước đây. Công nghệ Giao tiếp phạm vi gần (NFC) độc giả sẵn sàng tương tác với các dịch vụ HCE không được giả định về nội dung của các byte trước đây hoặc sự hiện diện của chúng.

Lưu ý rằng nhiều thiết bị HCE có thể đã tuân thủ các yêu cầu về giao thức mà các mạng thanh toán liên kết trong EMVCo đã chỉ định trong mục "Không tiếp xúc" Giao thức truyền thông" đặc điểm kỹ thuật. Cụ thể:

  • FSCI trong T0 phải nằm trong khoảng từ 2h đến 8h.
  • T(A)1 phải được đặt thành 0x80, cho biết chỉ tốc độ bit 106 kbit/s và tốc độ bit bất đối xứng giữa trình đọc và trình mô phỏng được hỗ trợ.
  • FWI trong T(B) 1 phải <= 7h.

Trao đổi dữ liệu APDU

Như đã lưu ý trước đó, việc triển khai HCE chỉ hỗ trợ một kênh logic duy nhất. Việc cố gắng chọn ứng dụng trên các kênh logic khác nhau không hoạt động thiết bị HCE.