이 페이지는 Cloud Translation API를 통해 번역되었습니다.

호스트 기반 카드 에뮬레이션 개요

NFC 기능을 제공하는 많은 Android 지원 기기는 이미 NFC를 지원합니다. 있습니다. 대부분의 경우 카드는 보안 요소라고 합니다. 여러 무선 이동통신사에서 제공하는 SIM 카드 에 보안 요소가 포함되어 있습니다.

Android 4.4 이상은 호스트 기반 카드 에뮬레이션이라는 보안 요소가 없습니다. 이 모든 Android 애플리케이션이 카드를 에뮬레이션하고 NFC와 직접 통신할 수 있게 합니다. 사용할 수 있습니다 이 주제에서는 호스트 기반 카드 에뮬레이션 (HCE)이 작동하는 방식을 설명합니다. Android에서 그리고 이를 사용하여 NFC 카드를 에뮬레이트하는 앱을 개발하는 방법 기술입니다.

보안 요소가 있는 카드 에뮬레이션

보안 요소를 사용하여 NFC 카드 에뮬레이션이 제공된 경우 이 카드는 에뮬레이션된 항목이 Android 애플리케이션입니다. 그런 다음 사용자가 NFC 단말기에 기기를 갖다 대면 NFC 단말기에서 컨트롤러는 리더의 모든 데이터를 요소가 포함됩니다. 그림 1은 이 개념을 보여줍니다.

NFC 컨트롤러를 통해 보안 요소에서 정보를 검색하는 NFC 리더가 있는 다이어그램
그림 1. 보안 요소가 있는 NFC 카드 에뮬레이션

보안 요소가 자체적으로 NFC 단말기와의 통신을 실행합니다. 트랜잭션에 관여하는 Android 애플리케이션이 없습니다. 거래가 완료된 경우 Android 애플리케이션은 보안 요소를 직접 쿼리하여 사용자에게 알립니다.

호스트 기반 카드 에뮬레이션

호스트 기반 카드 에뮬레이션을 사용하여 NFC 카드를 에뮬레이션하면 데이터가 라우팅됩니다. 호스트 CPU로 직접 라우팅됩니다. 그림 2 호스트 기반 카드 에뮬레이션의 작동 방식을 보여줍니다.

NFC 리더가 NFC 컨트롤러를 통해 CPU에서 정보를 검색하는 다이어그램
그림 2. 보안 요소가 없는 NFC 카드 에뮬레이션

지원되는 NFC 카드 및 프로토콜

HCE 프로토콜 스택을 보여주는 다이어그램
그림 3. Android의 HCE 프로토콜 스택

NFC 표준은 다양한 프로토콜을 지원하며 에뮬레이션할 수 있는 다양한 유형의 카드를 지원합니다.

Android 4.4 이상은 시장에서 일반적으로 사용되는 여러 프로토콜을 지원합니다. 오늘 기존의 많은 비접촉식 카드는 이미 이러한 프로토콜을 기반으로 하고 있습니다. 비접촉식 결제 카드 등입니다. 또한 이러한 프로토콜은 많은 다른 사람들이 오늘날 시중에 있는 NFC 리더에는 직접 독자에게 제공됩니다 (IsoDep 클래스). 이를 통해 다음을 중심으로 엔드 투 엔드 NFC 솔루션을 빌드하고 배포할 수 있습니다. Android 지원 기기만 사용하는 HCE

특히 Android 4.4 이상은 NFC-포럼 ISO-DEP 사양 (ISO/IEC 14443-4 기반) 및 ISO/IEC 7816-4에 정의된 애플리케이션 프로토콜 데이터 단위 (APDU) 지정할 수도 있습니다 Android는 Nfc-A를 기반으로 ISO-DEP만 에뮬레이션하도록 합니다. (ISO/IEC 14443-3 Type A) 기술. Nfc-B (ISO/IEC 14443-4 Type B) 지원 선택 사항입니다. 그림 3은 이러한 모든 레이어가 지정할 수도 있습니다

HCE 서비스

Android의 HCE 아키텍처는 Android를 기반으로 합니다 Service 구성요소 (HCE라고 함) 서비스 참조). 서비스의 주요 이점 중 하나는 백그라운드에 위치할 수 없습니다. 많은 HCE에 자연스러운 적합합니다. 추가할 필요가 없습니다. 실행할 수 있습니다. 대신 기기를 NFC 리더에 갖다 대면 올바른 서비스가 아직 실행되고 있지 않고 트랜잭션을 실행하는 경우 실행됩니다. 물론 추가 UI (예: 사용자 알림)을 제거해야 합니다.

서비스 선택

사용자가 기기를 NFC 리더에 탭하면 Android 시스템은 NFC 리더가 통신하려는 HCE 서비스입니다. ISO/IEC 7816-4 애플리케이션 선택 방법을 정의합니다. 애플리케이션 ID (AID) AID는 최대 16바이트로 구성됩니다. 에뮬레이션하는 경우 기존의 NFC 리더 인프라용 카드, 이러한 리더가 사용하는 AID 일반적으로 잘 알려져 있고 공개적으로 등록된 이름 (예: Visa, MasterCard 등 결제 네트워크의 AID).

자체 애플리케이션을 위해 새로운 리더 인프라를 배포하려면 자체 AID를 등록해야 합니다. AID 등록 절차는 다음에 정의되어 있습니다. ISO/IEC 7816-5 사양을 준수합니다. 7816-5에 따라 AID를 등록하는 것이 좋습니다. Android용 HCE 애플리케이션을 배포하는 경우 사용할 수 있습니다

AID 그룹

경우에 따라 HCE 서비스는 여러 AID를 등록하고 모든 AID의 기본 핸들러를 구현하고 애플리케이션입니다. 다른 서비스로 이동하는 그룹의 일부 AID는 지원되지 않습니다.

함께 보관되는 AID의 목록을 AID 그룹이라고 합니다. 시스템의 모든 AID는 AID 그룹으로 구성되고 Android는 다음 중 하나를 보장합니다.

그룹의 모든 AID가 이 HCE 서비스로 라우팅됩니다.
그룹의 AID는 이 HCE 서비스로 라우팅되지 않습니다 (예: 사용자가 그룹에서 하나 이상의 AID를 요청한 다른 서비스를 선호했습니다. 참고).

즉, 그룹 내의 일부 AID가 하나의 HCE 서비스로 라우팅되고 일부는 다른 HCE 서비스로 라우팅됩니다

AID 그룹 및 카테고리

각 AID 그룹을 카테고리와 연결할 수 있습니다. 이렇게 하면 Android에서 HCE 서비스를 카테고리별로 함께 사용할 수 있으며, 이를 통해 사용자는 AID 수준이 아닌 카테고리 수준에서 기본값으로 설정됩니다 AID 언급 피하기 애플리케이션의 사용자 대상 부분에 얻을 수 있습니다.

Android 4.4 이상은 다음 두 가지 카테고리를 지원합니다.

CATEGORY_PAYMENT 드림 (업계 표준 결제 앱 대상)
CATEGORY_OTHER 드림 (다른 모든 HCE 앱의 경우)

를 통해 개인정보처리방침을 정의할 수 있습니다.

HCE 서비스 구현

호스트 기반 카드 에뮬레이션을 사용하여 NFC 카드를 에뮬레이션하려면 NFC 트랜잭션을 처리하는 Service 구성요소입니다.

HCE 지원 확인

애플리케이션은 HCE를 지원하는지 여부를 확인하기 위해 FEATURE_NFC_HOST_CARD_EMULATION 드림 기능을 사용할 수 있습니다. <uses-feature> 사용 태그를 지정하여 앱에서 HCE를 사용한다고 선언합니다. 앱이 작동하는 데 필요한지 여부 등이 포함됩니다.

서비스 구현

Android 4.4 이상에서는 개발자가 사용할 수 있는 편리한 Service 클래스를 제공합니다. HCE 서비스를 구현하기 위한 기반으로 사용할 수 있습니다. HostApduService 클래스

첫 번째 단계는 다음 코드와 같이 HostApduService를 확장하는 것입니다. 샘플:

Kotlin

class MyHostApduService : HostApduService() {

    override fun processCommandApdu(commandApdu: ByteArray, extras: Bundle?): ByteArray {
       ...
    }

    override fun onDeactivated(reason: Int) {
       ...
    }
}

자바

public class MyHostApduService extends HostApduService {
    @Override
    public byte[] processCommandApdu(byte[] apdu, Bundle extras) {
       ...
    }
    @Override
    public void onDeactivated(int reason) {
       ...
    }
}

HostApduService는 재정의해야 하는 두 가지 추상 메서드를 선언합니다. 있습니다. 그 중 하나가 processCommandApdu()님, NFC 리더가 APDU (Application Protocol Data Unit)를 전송할 때마다 호출됩니다. 추가할 수 있습니다 APDU는 ISO/IEC 7816-4 사양에 정의되어 있습니다. APDU NFC 판독기와 무선 통신 장치 사이에 교환되고 있는 애플리케이션 수준의 패킷 사용할 수 있습니다 해당 애플리케이션 수준 프로토콜은 반이중입니다. 즉, NFC 리더기 명령 APDU를 보내고, 응답 APDU를 전송하여 반환합니다.

앞서 언급했듯이 Android는 AID를 사용하여 메시지를 전달할 수 있습니다 일반적으로 NFC 리더가 사용자의 기기에 보내는 첫 번째 APDU는 기기가 SELECT AID APDU입니다. 이 APDU에는 리더가 원하는 AID가 포함되어 있으며 대화할 수 있습니다. Android가 APDU에서 해당 AID를 추출하여 HCE로 확인합니다. 해당 APDU를 확인된 서비스에 전달합니다.

여기서 응답 APDU의 바이트를 반환하여 응답 APDU를 보낼 수 있습니다. processCommandApdu() 이 메서드는 기본 스레드에서 호출됩니다. 차단해서는 안 됩니다. 인코더-디코더 아키텍처를 계산하고 반환할 수 없는 경우 즉시 null을 반환하면 됩니다. 그런 다음 다른 스레드를 사용하고 sendResponseApdu() 드림 다음과 같은 경우 응답을 전송하기 위해 HostApduService 클래스에 정의된 메서드 완료되었습니다.

Android는 다음 중 하나가 발생할 때까지 새 APDU를 리더에서 서비스로 계속 전달합니다. 다음과 같은 결과가 발생합니다.

NFC 리더는 또 다른 SELECT AID APDU를 전송하며 OS는 이를 사용할 수 있습니다
NFC 리더와 기기 간의 NFC 링크가 끊어집니다.

두 경우 모두 클래스의 onDeactivated() 드림 구현은 둘 중 어느 것이 발생했는지 나타내는 인수와 함께 호출됩니다.

기존 리더 인프라를 사용하는 경우 기존 애플리케이션 수준 프로토콜과 일치해야 합니다.

직접 제어하는 새로운 리더 인프라도 배포하는 경우 고유한 프로토콜과 APDU 시퀀스를 정의할 수 있습니다. APDU 수를 제한하려는 시도 교환할 데이터의 크기입니다. 이렇게 하면 사용자가 NFC 리더에 기기를 잠시 대주세요. 가 합당한 상한은 약 1KB의 데이터이며, 일반적으로 300ms 이내에 교환됩니다.

서비스 manifest 선언 및 AID 등록

평소처럼 매니페스트에서 서비스를 선언해야 하지만 서비스 선언에 대한 추가 부분도 있습니다.

특정 IP 주소를 구현하는 HCE 서비스임을 플랫폼에 알리기 위해 HostApduService 인터페이스에서 인텐트 필터를 SERVICE_INTERFACE 작업을 서비스 선언에 추가합니다.
이 서비스에서 요청한 AID 그룹을 플랫폼에 알리려면 a SERVICE_META_DATA 드림 XML을 가리키는 서비스 선언의 <meta-data> 태그 HCE 서비스에 대한 추가 정보가 있는 리소스입니다.
android:exported 속성을 true로 설정하고 android.permission.BIND_NFC_SERVICE 권한을 선언하세요. 전자는 서비스가 외부 애플리케이션에 의해 결합될 수 있도록 합니다. 후자는 그런 다음 android.permission.BIND_NFC_SERVICE 권한은 서비스에 바인딩될 수 있습니다. android.permission.BIND_NFC_SERVICE는 시스템 권한이므로 Android OS만 서비스에 바인드할 수 있도록 효과적으로 시행합니다.

다음은 HostApduService 매니페스트 선언의 예입니다.

<service android:name=".MyHostApduService" android:exported="true"
         android:permission="android.permission.BIND_NFC_SERVICE">
    <intent-filter>
        <action android:name="android.nfc.cardemulation.action.HOST_APDU_SERVICE"/>
    </intent-filter>
    <meta-data android:name="android.nfc.cardemulation.host_apdu_service"
               android:resource="@xml/apduservice"/>
</service>

이 메타데이터 태그는 apduservice.xml 파일을 가리킵니다. 다음은 두 개의 독점 AID:

<host-apdu-service xmlns:android="http://schemas.android.com/apk/res/android"
           android:description="@string/servicedesc"
           android:requireDeviceUnlock="false">
    <aid-group android:description="@string/aiddescription"
               android:category="other">
        <aid-filter android:name="F0010203040506"/>
        <aid-filter android:name="F0394148148100"/>
    </aid-group>
</host-apdu-service>

<host-apdu-service> 태그에는 <android:description> 속성이 포함되어야 합니다. 여기에 표시할 수 있는 서비스에 대한 사용자 친화적인 설명이 앱 UI입니다. requireDeviceUnlock 속성을 사용하여 잠금 해제되어야 합니다.

<host-apdu-service>는 <aid-group> 태그를 하나 이상 포함해야 합니다. 각 <aid-group> 태그는 다음을 실행하는 데 필요합니다.

사용자 친화적인 콘텐츠가 포함된 android:description 속성 포함 AID 그룹의 설명이며 UI에 표시하기에 적합합니다.
AID 카테고리를 나타내도록 android:category 속성을 설정해야 합니다. CATEGORY_PAYMENT로 정의된 문자열 상수와 같이 그룹이 속한 그룹 또는 CATEGORY_OTHER.
하나 이상의 <aid-filter> 태그를 포함해야 하며 각 태그에는 단일 AID가 포함됩니다. AID를 16진수 형식으로 지정하고 글자 수

또한 애플리케이션은 사용자로 등록할 수 있는 NFC 권한 HCE 서비스.

AID 충돌 해결

여러 HostApduService 구성요소를 단일 기기에 설치할 수 있음 둘 이상의 서비스에서 동일한 AID를 등록할 수 있습니다. Android는 AID를 확인합니다. 서로 다른 충돌을 일으킬 수 있습니다. 각 충돌 해결 정책이 다를 수 있습니다.

결제와 같은 일부 카테고리의 경우 사용자가 기본 결제 수단을 선택할 수 있습니다. 서비스에 액세스할 수 있습니다. 다른 카테고리의 경우 정책은 다음과 같을 수 있습니다. 충돌 발생 시 어떤 서비스를 호출해야 하는지 항상 사용자에게 묻습니다. 정보 자세한 내용은 충돌 해결 정책을 쿼리하는 방법에 대한 자세한 내용은 getSelectionModeForCategory()

서비스가 기본 서비스인지 확인

애플리케이션은 자체 HCE 서비스가 보안 운영 체제에 대한 기본 서비스인지 특정 카테고리를 isDefaultServiceForCategory() 드림 API에 액세스할 수 있습니다.

서비스가 기본 서비스가 아닌 경우 기본 서비스로 설정하도록 요청할 수 있습니다. 사용 ACTION_CHANGE_DEFAULT

결제 애플리케이션

Android는 payment 카테고리를 사용할 수 있습니다. Android 4.4 이상에는 최상위 설정 메뉴 항목 탭 & 결제 - 결제 수단의 결제 애플리케이션입니다. 이 설정 메뉴에서 사용자는 기본 결제 애플리케이션에서 호출할 수 있습니다.

결제 애플리케이션의 필수 애셋

시각적으로 더 매력적인 사용자 환경을 제공하기 위해 HCE 결제 애플리케이션은 서비스 배너를 제공해야 합니다

Android 13 이상

설정 UI의 기본 결제 선택 목록에 더 잘 맞도록 배너 요구사항을 정사각형 아이콘으로 변경합니다. 이 코드는 애플리케이션 런처 아이콘 디자인 이 조정은 더 일관되고 더욱 깔끔해졌습니다.

Android 12 및 이전 버전

서비스 배너 크기를 260x96dp로 설정한 다음 서비스 배너 크기를 설정합니다. 를 추가하여 메타데이터 XML 파일에 android:apduServiceBanner를 추가하면 됩니다. 드로어블 리소스를 가리키는 <host-apdu-service> 태그. 이 예를 들면 다음과 같습니다.

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

화면 꺼짐 및 잠금 화면 동작

HCE 서비스의 동작은 Windows에서 실행되는 Android의 버전에 따라 있습니다.

Android 12 이상

Android 12 (API 수준 31) 이상을 타겟팅하는 앱에서는 NFC를 사용 설정할 수 있습니다. 기기 화면을 켜지 않은 상태에서도 requireDeviceScreenOn(으)로 false입니다.

Android 10 이상

Android 10 (API 수준 29) 이상을 실행하는 기기는 안전함 NFC를 탭합니다. 안전한 동안 NFC가 켜져 있고 모든 카드 에뮬레이터 (호스트 애플리케이션 및 오프 호스트 애플리케이션)가 켜져 있음 기기 화면이 꺼져 있을 때는 사용할 수 없습니다. 보안 NFC가 사용 중지되어 있을 때 오프 호스트 애플리케이션을 사용할 수 있습니다. 다음에서 확인할 수 있습니다. 다음을 사용하여 NFC 지원 보호 isSecureNfcSupported()

Android 10 이상을 실행하는 기기에서는 동일한 설정 기능 android:requireDeviceUnlock~true은(는) 기기와 마찬가지로 적용됩니다. Android 9 이하를 실행하지만 보안 NFC가 사용 중지된 경우에만 작동합니다. 즉, 보안 NFC가 사용 설정되어 HCE 서비스가 잠금 화면에서 작동할 수 없습니다. android:requireDeviceUnlock의 설정과 관계없이

Android 9 이하

Android 9 (API 수준 28) 이하를 실행하는 기기에서는 NFC 컨트롤러와 애플리케이션 프로세서의 화면이 완전히 꺼지면 기기가 꺼져 있는지 확인합니다. 따라서 화면이 꺼져 있으면 HCE 서비스가 작동하지 않습니다.

Android 9 이하에서도 HCE 서비스가 잠금 화면에서 작동할 수 있습니다. 하지만 이는 android:requireDeviceUnlock 속성으로 제어됩니다. HCE 서비스의 <host-apdu-service> 태그입니다. 기본적으로 기기 잠금 해제는 필요하지 않으며, 기기가 잠겨 있더라도 서비스가 호출됩니다.

HCE의 android:requireDeviceUnlock 속성을 true로 설정하는 경우 서비스의 경우 다음과 같은 경우 Android는 사용자에게 기기를 잠금 해제하라는 메시지를 표시합니다. 발생할 수 있습니다.

사용자가 NFC 리더를 탭합니다.
NFC 리더가 서비스로 확인되는 AID를 선택합니다.

잠금 해제하면 Android에 사용자에게 다시 탭하라는 대화상자가 표시됩니다. 거래를 완료할 수 있습니다 이는 사용자가 기기를 NFC 리더에서 멀리 떨어뜨려 잠금을 해제하세요.

보안 요소 카드와의 공존

이 섹션은 애플리케이션을 배포한 개발자를 대상으로 합니다. 카드 에뮬레이션에 보안 요소를 사용합니다. Android의 HCE 구현 카드를 구현하는 다른 방법과 동시에 작동하도록 설계됨 다양한 에뮬레이션을 지원합니다.

이 공존은 AID 라우팅이라는 원칙을 기반으로 합니다. NFC 컨트롤러는 (유한한) 라우팅 목록으로 구성된 라우팅 테이블을 유지함 있습니다. 각 라우팅 규칙에는 AID 및 대상이 포함됩니다. 대상은 Android 앱이 실행되는 호스트 CPU 또는 연결된 보안 서버 요소가 포함됩니다.

NFC 리더가 SELECT AID가 포함된 APDU를 전송하면 NFC 컨트롤러가 파싱합니다. AID가 라우팅 테이블의 AID와 일치하는지 확인합니다. 만약 일치하는 경우 해당 APDU 및 그 이후의 모든 APDU를 대상으로 다른 SELECT AID APDU를 수신하거나 NFC가 링크가 깨졌습니다.

그림 4는 이 아키텍처를 보여줍니다.

보안 요소와 CPU 모두와 통신하는 NFC 리더가 있는 다이어그램
그림 4. 보안 요소와 호스트 카드 에뮬레이션 모두와 작동하는 Android

또한 NFC 컨트롤러에는 일반적으로 APDU의 기본 경로도 포함됩니다. 사용자가 라우팅 테이블에서 AID를 찾을 수 없으면 기본 경로가 사용됩니다. 이 기기마다 설정이 다를 수 있으며 Android 기기가 필요합니다. 앱에서 등록 중인 AID가 호스팅합니다

HCE 서비스를 구현하거나 보안 요소를 사용하는 Android 애플리케이션 라우팅 테이블 구성에 대해 걱정할 필요가 없습니다. Google Cloud에서 Android가 자동으로 Android는 처리할 수 있는 AID만 알면 됨 어떤 것이 보안 요소에 의해 처리될 수 있는지에 대해 설명합니다. 라우팅 테이블은 설치되는 서비스 및 설치되는 서비스를 기반으로 사용자가 선호하도록 구성한 위치

다음 섹션에서는 보안 요소가 있습니다.

보안 요소 AID 등록

카드 에뮬레이션에 보안 요소를 사용하는 애플리케이션은 오프 호스트 서비스를 추가해야 합니다. 이러한 서비스 선언은 HCE 서비스의 선언과 거의 동일합니다. 예외는 다음과 같습니다. 다음과 같습니다.

인텐트 필터에 사용되는 작업은 SERVICE_INTERFACE
메타데이터 이름 속성은 SERVICE_META_DATA

메타데이터 XML 파일은 <offhost-apdu-service> 루트 태그를 사용해야 합니다.

<service android:name=".MyOffHostApduService" android:exported="true"
       android:permission="android.permission.BIND_NFC_SERVICE">
  <intent-filter>
      <action android:name="android.nfc.cardemulation.action.OFF_HOST_APDU_SERVICE"/>
  </intent-filter>
  <meta-data android:name="android.nfc.cardemulation.off_host_apdu_service"
             android:resource="@xml/apduservice"/>
</service>

다음은 상응하는 apduservice.xml 파일의 예입니다. 두 개의 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>

android:requireDeviceUnlock 속성은 오프 호스트 서비스에는 적용되지 않습니다. 호스트 CPU가 트랜잭션에 관여하지 않으므로 보호 장치가 중지 될 때 보안 요소가 트랜잭션을 실행하지 못하게 있습니다.

오프 호스트 서비스에는 android:apduServiceBanner 속성이 필요합니다. 기본 결제 수단으로 선택할 수 있는 애플리케이션입니다.

오프 호스트 서비스 호출

Android는 '오프 호스트'로 선언된 서비스를 시작하거나 이 서비스에 바인딩하지 않습니다. 실제 트랜잭션은 Android 서비스입니다. 서비스 선언을 사용하면 애플리케이션이 보안 요소에 있는 AID를 등록합니다.

HCE 및 보안

HCE 아키텍처는 하나의 핵심 보안 요소를 제공합니다. Google Cloud 서비스나 BIND_NFC_SERVICE 드림 시스템 권한이 있으면 OS만 서비스에 바인딩하고 서비스와 통신할 수 있습니다. 이렇게 하면 수신하는 APDU가 실제로 NFC 컨트롤러에서 OS를 확인하고 다시 보낸 모든 APDU는 OS는 다시 APDU를 NFC 컨트롤러에 직접 전달합니다.

마지막으로 남은 문제는 앱에서 전송하는 데이터를 가져오는 위치입니다. 접촉했습니다. 이는 HCE 설계에서 의도적으로 분리되어 있습니다. 그렇다 데이터의 출처는 상관없지만 데이터가 안전한지 확인하고 NFC 컨트롤러로 전송되어 NFC 리더로 전송됩니다.

HCE에서 전송하려는 데이터를 안전하게 저장하고 검색 예를 들어 애플리케이션 샌드박스에 의존하는 앱의 데이터를 다른 앱으로부터 분리합니다. Android에 관한 자세한 내용은 보안 관련 정보는 보안 도움말을 참고하세요.

프로토콜 매개변수 및 세부정보

이 섹션은 어떤 프로토콜이 사용되는지 알아보려는 개발자를 대상으로 합니다. 여러 장치의 충돌 방지 및 활성화 단계에서 HCE 장치가 사용하는 NFC 프로토콜이 있다는 것입니다. 이를 통해 Android HCE 기기와 호환됩니다.

Nfc-A(ISO/IEC 14443 Type A) 프로토콜 충돌 방지 및 활성화

Nfc-A 프로토콜 활성화 과정의 일환으로 여러 프레임이 교환됩니다.

교환의 첫 번째 부분에서 HCE 기기는 UID를 표시합니다. HCE 기기 임의의 UID가 있다고 가정해야 합니다. 즉, 탭할 때마다 UID는 리더에 제시되는 UID는 무작위로 생성된 UID입니다. 이로 인해 NFC 리더는 HCE 기기의 UID에 중요한 역할을 합니다

NFC 리더는 이후에 SEL_REQ를 전송하여 HCE 기기를 선택할 수 있습니다. 명령어와 함께 사용하면 됩니다 HCE 기기의 SEL_RES 응답에 최소 6번째 비트가 있음 (0x20)으로 설정됩니다. 이는 기기가 ISO-DEP를 지원함을 나타냅니다. 음의 다른 비트는 NFC-DEP 지원 등을 나타내는 SEL_RES도 설정할 수 있습니다. (p2p) 프로토콜 다른 비트를 설정할 수 있으므로 독자가 HCE 기기는 6번째 비트만 명시적으로 확인해야 하며 비교하면 안 됩니다. 값이 0x20인 전체 SEL_RES를 반환합니다.

ISO-DEP 활성화

Nfc-A 프로토콜이 활성화되면 NFC 리더가 ISO-DEP를 시작합니다. 활성화해야 합니다. RATS (Request for Answer To Select)를 보냅니다. 명령어와 함께 사용하면 됩니다 NFC 컨트롤러는 RATS 응답인 ATS를 생성합니다. ATS는 HCE 서비스로 구성할 수 있습니다 하지만 HCE 구현은 NFC 포럼을 충족해야 합니다. NFC 리더가 이러한 매개변수를 사용할 수 있도록 하기 위해 모든 HCE 기기의 NFC 포럼 요구사항에 따라 설정되어야 합니다.

아래 섹션에서는 ATS의 개별 바이트에 관해 자세히 설명합니다. NFC 컨트롤러가 제공한 응답을 전송합니다.

TL: ATS 응답의 길이입니다. 20자(영문 기준) 이상의 길이를 나타내서는 안 됩니다. 바이트.
T0: 비트 5, 6, 7은 모든 HCE 기기에 설정되어야 하며 이는 TA(1), TB(1)를 나타냅니다. TC(1)가 ATS 응답에 포함됩니다. 비트 1~4는 FSCI를 나타내며, 최대 프레임 크기를 코딩하는 것입니다. HCE 기기에서 FSCI의 값은 0시간에서 8시간 사이입니다.
T(A)1: 리더와 에뮬레이터 간의 비트 전송률 및 가능 여부를 정의함 비대칭입니다. HCE 기기의 비트 전송률 요구사항이나 보증은 없습니다.
T(B)1: 비트 1~4는 SFGI(Start-up Frame Guard time Integer)를 나타냅니다. 사용 설정됨 HCE 기기, SFGI는 8h 이하여야 합니다. 비트 5~8은 프레임 대기를 나타냅니다. time Integer (FWI)로 프레임 대기 시간 (FWT)을 코딩합니다. HCE 기기, FWI 8시간 이하여야 합니다.
T(C)1: 비트 5는 '고급 프로토콜 기능' 지원을 나타냅니다. HCE 기기 '고급 프로토콜 기능'을 지원할 수도 있고 지원하지 않을 수도 있습니다. 비트 2: 지원을 나타냄 입니다. HCE 기기는 DID를 지원할 수도 있고 지원하지 않을 수도 있습니다. 비트 1은 NAD. HCE 기기는 NAD를 지원하지 않아야 하며 비트 1을 0으로 설정해서는 안 됩니다.
기록 바이트: HCE 기기는 최대 15개의 기록 바이트를 반환할 수 있습니다. 근거리 무선 통신 HCE 서비스와 상호작용하려는 독자는 이전 바이트 또는 그 존재 여부를 확인할 수 있습니다.

많은 HCE 기기는 프로토콜 요구사항을 준수하도록 제작되었습니다. EMVCo에 통합된 결제 네트워크가 '비접촉 결제' 통신 프로토콜' 지정할 수도 있습니다 특히 다음 항목이 중요합니다.

T0의 FSCI는 2h에서 8h 사이여야 합니다.
T(A)1은 0x80으로 설정되어야 하며, 이는 106kbit/s의 비트 전송률만 리더와 에뮬레이터 간의 비대칭 비트 전송률은 지원되지 않음 지원됩니다.
T(B)1의 FWI는 <= 7h여야 합니다.

APDU 데이터 교환

앞서 언급했듯이 HCE 구현은 단일 논리 채널만 지원합니다. 다른 논리 채널에서 애플리케이션을 선택하려고 해도 작동하지 않음 가상 머신일 수 있습니다