Applications

HCE (Host Card Emulation)

<\/script>\n
'; }, get iframeSnippet() { const domain = '{ SITE_DOMAIN }'; const type = '{ embed_type }'; const slug = '{ embed_slug }'; return ''; }, get activeSnippet() { return this.method === 'script' ? this.scriptSnippet : this.iframeSnippet; }, copySnippet() { navigator.clipboard.writeText(this.activeSnippet).then(() => { this.copied = true; setTimeout(() => { this.copied = false; }, 2000); }); } }" @keydown.escape.window="open = false" @click.outside="open = false">

Embed This Widget

Theme


      
    

Widget powered by . Free, no account required.

A technology that allows Android smartphones to emulate NFC smart cards without a hardware secure element. The card data is hosted in the phone's main processor and OS, enabling software-based mobile payments and access control.

별칭: HCE Host Card Emulation

What Is HCE?

Host Card Emulation (HCE) is a technology introduced in Android 4.4 (KitKat, 2013) that enables smartphones to emulate NFC smart cards entirely in software, without requiring a hardware secure element. HCE routes card emulation mode traffic directly to an Android application running on the device's main processor, democratizing NFC payment and access control development.

How HCE Works

In traditional card emulation, the NFC controller routes all incoming commands from an external reader to a hardware secure element, a tamper-resistant chip that stores cryptographic keys. The host processor is not involved in the transaction. HCE changes this routing so commands go to an Android service instead.

The architecture involves three layers:

  1. NFC controller. Detects the RF field and handles the physical layer (NFC-A or NFC-B protocol).
  2. Android NFC service. Routes incoming Application Protocol Data Units (APDUs) to the registered HCE service based on the Application ID (AID).
  3. HCE application. Processes APDUs, performs authentication, and returns response data.

When a POS terminal sends a SELECT command with a specific AID, Android routes it to the HCE service registered for that AID. The application then handles the full EMV transaction flow in software.

HCE vs Secure Element

Aspect HCE Secure Element
Key storage Software / TEE / cloud Tamper-resistant hardware
Provisioning Over-the-air (OTA) NFC controller or OTA
Carrier dependency None Often requires carrier agreement
Offline transactions Limited (token pool) Full
Development access Open (Android API) Restricted (requires SE access)
Used by Google Pay Apple Pay

The most significant advantage of HCE is openness. Before HCE, deploying a card emulation application required negotiating access to the SIM-based or embedded secure element with mobile carriers or device manufacturers. HCE removed this barrier entirely.

Security Model

HCE compensates for the absence of hardware key protection through several mechanisms:

Tokenization. Instead of storing the actual card PAN (Primary Account Number), HCE applications use limited-use tokens issued by the card network. Each token is valid for a small number of transactions and is geographically restricted, minimizing fraud risk if the token is compromised.

Cloud-based keys. Cryptographic keys for generating transaction cryptograms can be stored on a remote server and fetched as needed. This requires network connectivity but provides strong key protection.

Android Keystore / TEE. On supported devices, keys are stored in the Trusted Execution Environment (TEE), which provides hardware-backed isolation without a dedicated secure element.

Applications Beyond Payments

HCE enables a wide range of NFC applications beyond contactless payment: building access control, loyalty cards, transit passes, student IDs, and corporate badges. Any ISO 14443-4 smart card application can be emulated using HCE, making it a versatile platform for NFC-based identity and access solutions.

Related Terms

자주 묻는 질문

The NFC glossary is a comprehensive reference of technical terms, acronyms, and concepts used in Near Field Communication technology. It is designed for developers, product managers, and engineers who work with NFC and need clear definitions of terms like NDEF, APDU, anti-collision, and ISO 14443.

Each glossary term is cross-referenced with related NFC chips, standards, and other terms. For example, the term 'AES-128' links to chips that support AES encryption (NTAG 424 DNA, DESFire EV2/EV3), and the term 'ISO 14443' links to all chips compliant with that standard.

Yes. NFCFYI provides glossary definitions in 15 languages including English, Korean, Japanese, Chinese, Spanish, Portuguese, Hindi, Arabic, French, Russian, German, Turkish, Vietnamese, Indonesian, and Thai. Use the language selector in the header to switch languages.