Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 1 | page.title=Host-based Card Emulation |
Joe Fernandez | 33baa5a | 2013-11-14 11:41:19 -0800 | [diff] [blame] | 2 | page.tags=host card emulation,hce,HostApduService,OffHostApduService,tap and pay |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 3 | |
| 4 | @jd:body |
| 5 | |
| 6 | |
| 7 | <div id="qv-wrapper"> |
| 8 | <div id="qv"> |
| 9 | |
| 10 | <h2>In this document</h2> |
| 11 | <ol> |
| 12 | <li><a href="#SecureElement">Card Emulation with a Secure Element</a></li> |
| 13 | <li><a href="#HCE">Host-based Card Emulation</a></li> |
| 14 | <li><a href="#SupportedProtocols">Supported NFC Cards and Protocols</a></li> |
| 15 | <li><a href="#HceServices">HCE Services</a> |
| 16 | </li> |
| 17 | <li><a href="#ImplementingService">Implementing an HCE Service</a> |
| 18 | </li> |
| 19 | <li><a href="#AidConflicts">AID Conflict Resolution</a> |
| 20 | </li> |
| 21 | <li><a href="#PaymentApps">Payment Applications</a> |
| 22 | </li> |
| 23 | <li><a href="#ScreenOffBehavior">Screen Off and Lock-screen Behavior</a></li> |
| 24 | <li><a href="#Coexistence">Coexistence with Secure Element Cards</a> |
| 25 | </li> |
| 26 | <li><a href="#HceSecurity">HCE and Security</a></li> |
| 27 | <li><a href="#ProtocolParams">Protocol parameters and details</a> |
| 28 | </li> |
| 29 | </ol> |
| 30 | |
| 31 | </div> |
| 32 | </div> |
| 33 | |
| 34 | |
| 35 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 36 | <p>Many Android-powered devices that offer NFC functionality already support NFC card |
| 37 | emulation. In most cases, the card is emulated by a separate |
| 38 | chip in the device, called a <em>secure element</em>. Many SIM cards provided by |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 39 | wireless carriers also contain a secure element.</p> |
| 40 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 41 | <p>Android 4.4 introduces an additional method of card emulation that does not |
| 42 | involve a secure element, called <em>host-based card emulation</em>. This allows any |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 43 | Android application to emulate a card and talk directly to the NFC reader. This |
| 44 | document describes how host-based card emulation (HCE) works on Android and how you |
| 45 | can develop an app that emulates an NFC card using this technique.</p> |
| 46 | |
| 47 | |
| 48 | <h2 id="SecureElement">Card Emulation with a Secure Element</h2> |
| 49 | |
| 50 | <p>When NFC card emulation is provided using a secure element, the card to be emulated |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 51 | is provisioned into the secure element on |
| 52 | the device through an Android application. Then, when the user holds the |
| 53 | device over an NFC terminal, the NFC controller in the device routes all data |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 54 | from the reader directly to the secure element. Figure 1 illustrates this concept.</p> |
| 55 | |
| 56 | <img src="{@docRoot}images/nfc/secure-element.png" /> |
| 57 | <p class="img-caption"><strong>Figure 1.</strong> NFC card emulation with a secure element.</p> |
| 58 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 59 | <p>The secure element itself performs the communication with the NFC terminal, |
| 60 | and no Android application is involved in the transaction at all. After the |
| 61 | transaction is complete, an Android application can query the secure element |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 62 | directly for the transaction status and notify the user.</p> |
| 63 | |
| 64 | |
| 65 | <h2 id="HCE">Host-based Card Emulation</h2> |
| 66 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 67 | <p>When an NFC card is emulated using host-based card emulation, the data is routed to |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 68 | the host CPU on which Android applications are running directly, instead of routing the NFC |
| 69 | protocol frames to a secure element. Figure 2 illustrates how host-based card emulation |
| 70 | works.</p> |
| 71 | |
| 72 | <img src="{@docRoot}images/nfc/host-based-card.png" /> |
Scott Main | 45d9321 | 2013-11-12 10:54:53 -0800 | [diff] [blame] | 73 | <p class="img-caption"><strong>Figure 2.</strong> NFC card emulation without a secure element.</p> |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 74 | |
| 75 | |
| 76 | <h2 id="SupportedProtocols">Supported NFC Cards and Protocols</h2> |
| 77 | |
| 78 | <div class="figure" style="width:147px"> |
| 79 | <img src="{@docRoot}images/nfc/protocol-stack.png"/> |
| 80 | <p class="img-caption"><strong>Figure 3.</strong> Android's HCE protocol stack.</p> |
| 81 | </div> |
| 82 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 83 | <p>The NFC standards offer support for many different protocols, and there are |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 84 | different types of cards that can be emulated.</p> |
| 85 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 86 | <p>Android 4.4 supports several protocols that are common in the |
| 87 | market today. Many existing contactless cards are already based on these |
| 88 | protocols, such as contactless payment cards. These protocols are also |
| 89 | supported by many NFC readers in the market today, including Android NFC |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 90 | devices functioning as readers themselves (see the {@link android.nfc.tech.IsoDep} class). |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 91 | This allows you to build and deploy an end-to-end NFC solution |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 92 | around HCE using only Android-powered devices.</p> |
| 93 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 94 | <p>Specifically, Android 4.4 supports emulating cards that are based on the |
| 95 | NFC-Forum ISO-DEP specification (based on ISO/IEC 14443-4) and process |
| 96 | Application Protocol Data Units (APDUs) as defined in the ISO/IEC 7816-4 |
| 97 | specification. Android mandates emulating ISO-DEP only on top of the |
| 98 | Nfc-A (ISO/IEC 14443-3 Type A) technology. Support for Nfc-B (ISO/IEC 14443-4 |
| 99 | Type B) technology is optional. The layering of all these specifications is |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 100 | shown in the figure 3.</p> |
| 101 | |
| 102 | |
| 103 | |
| 104 | <h2 id="HceServices">HCE Services</h2> |
| 105 | |
| 106 | <p>The HCE architecture in Android is based around Android {@link android.app.Service} components |
| 107 | (known as "HCE services"). |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 108 | One of the key advantages of a service is that it can run in the background without |
| 109 | any user interface. This is a natural fit for many HCE applications like loyalty or transit cards, |
| 110 | with which the user shouldn't need to launch the app to use it. |
| 111 | Instead, tapping the device against the NFC reader starts the correct service (if not already |
| 112 | running) and executes the transaction in the background. Of course, you are free |
| 113 | to launch additional UI (such as user notifications) from your service if that makes |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 114 | sense.</p> |
| 115 | |
| 116 | |
| 117 | |
| 118 | <h3 id="ServiceSelection">Service selection</h3> |
| 119 | |
| 120 | <p>When the user taps a device to an NFC reader, the Android system needs to |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 121 | know which HCE service the NFC reader actually wants to talk to. |
| 122 | This is where the ISO/IEC 7816-4 specification comes in: it defines a way to |
| 123 | select applications, centered around an Application ID (AID). An AID |
| 124 | consists of up to 16 bytes. If you are emulating cards for an existing NFC reader |
| 125 | infrastructure, the AIDs that those readers are looking for are typically |
| 126 | well-known and publicly registered (for example, the AIDs of payment networks |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 127 | such as Visa and MasterCard).</p> |
| 128 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 129 | <p>If you want to deploy new reader infrastructure for your own application, you |
| 130 | will need to register your own AID(s). The registration procedure for AIDs is |
| 131 | defined in the ISO/IEC 7816-5 specification. Google recommends registering an |
| 132 | AID as per 7816-5 if you are deploying a HCE application for Android, as it will avoid |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 133 | collisions with other applications.</p> |
| 134 | |
| 135 | |
| 136 | <h3 id="AidGroups">AID groups</h3> |
| 137 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 138 | <p>In some cases, an HCE service may need to register multiple AIDs to implement a |
| 139 | certain application, and it needs to be sure that it is the default handler for |
| 140 | all of these AIDs (as opposed to some AIDs in the group going to another |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 141 | service).</p> |
| 142 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 143 | <p>An AID group is a list of AIDs that should be considered as belonging together |
| 144 | by the OS. For all AIDs in an AID group, Android guarantees one of the |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 145 | following:</p> |
| 146 | |
| 147 | <ul> |
| 148 | <li>All AIDs in the group are routed to this HCE service</li> |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 149 | <li>No AIDs in the group are routed to this HCE service (for example, because the user |
| 150 | preferred another service which requested one or more AIDs in your group as |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 151 | well)</li> |
| 152 | </ul> |
| 153 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 154 | <p>In other words, there is no in-between state, where some AIDs in the group can |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 155 | be routed to one HCE service, and some to another.</p> |
| 156 | |
| 157 | <h3 id="GroupsCategories">AID groups and categories</h3> |
| 158 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 159 | <p>Each AID group can be associated with a category. This allows Android to group |
| 160 | HCE services together by category, and that in turn allows the user to set |
| 161 | defaults at the category level instead of the AID level. In general, avoid |
| 162 | mentioning AIDs in any user-facing parts of your application: they do not mean |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 163 | anything to the average user.</p> |
| 164 | |
| 165 | <p>Android 4.4 supports two categories: {@link |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 166 | android.nfc.cardemulation.CardEmulation#CATEGORY_PAYMENT} (covering industry-standard payment |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 167 | apps) and {@link android.nfc.cardemulation.CardEmulation#CATEGORY_OTHER} |
| 168 | (for all other HCE apps).</p> |
| 169 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 170 | <div class="note"> |
| 171 | <p><strong>Note:</strong> |
| 172 | Only one AID group in the {@link |
| 173 | android.nfc.cardemulation.CardEmulation#CATEGORY_PAYMENT} category may be enabled in the system at any given time. Typically, this will be an app that understands major credit card payment protcols and which can work at any merchant.</p> |
| 174 | <p>For <em>closed-loop</em> payment apps that only work at one merchant (such as stored-value cards), you should use {@link |
| 175 | android.nfc.cardemulation.CardEmulation#CATEGORY_OTHER}. AID groups in this category can be always active, and can be given priority by NFC readers during AID selection if necessary.</p> |
| 176 | </div> |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 177 | |
| 178 | <h2 id="ImplementingService">Implementing an HCE Service</h2> |
| 179 | |
| 180 | <p>To emulate an NFC card using host-based card emulation, you need to create |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 181 | a {@link android.app.Service} component that handles the NFC transactions. |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 182 | |
| 183 | <h3 id="CheckingforSupport">Checking for HCE support</h3> |
| 184 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 185 | <p>Your application can check whether a device supports HCE by checking for the |
| 186 | {@link android.content.pm.PackageManager#FEATURE_NFC_HOST_CARD_EMULATION} feature. You should use the |
| 187 | <a href="{@docRoot}guide/topics/manifest/uses-feature-element.html">{@code <uses-feature>}</a> tag in the manifest of your application to declare that your app |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 188 | uses the HCE feature, and whether it is required for the app to function or not.</p> |
| 189 | |
| 190 | <h3 id="ServiceImplementation">Service implementation</h3> |
| 191 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 192 | <p>Android 4.4 comes with a convenience {@link android.app.Service} class that can be used as a |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 193 | basis for implementing a HCE service: the {@link android.nfc.cardemulation.HostApduService} class.</p> |
| 194 | |
| 195 | <p>The first step is therefore to extend {@link android.nfc.cardemulation.HostApduService}.</p> |
| 196 | |
| 197 | <pre> |
| 198 | public class MyHostApduService extends HostApduService { |
| 199 | @Override |
| 200 | public byte[] processCommandApdu(byte[] apdu, Bundle extras) { |
| 201 | ... |
| 202 | } |
| 203 | @Override |
| 204 | public void onDeactivated(int reason) { |
| 205 | ... |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 206 | } |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 207 | } |
| 208 | </pre> |
| 209 | |
| 210 | <p>{@link android.nfc.cardemulation.HostApduService} |
| 211 | declares two abstract methods that need to be overridden and implemented.</p> |
| 212 | |
| 213 | <p>{@link android.nfc.cardemulation.HostApduService#processCommandApdu processCommandApdu()} |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 214 | is called whenever a NFC reader sends an Application |
| 215 | Protocol Data Unit (APDU) to your service. APDUs are defined in the ISO/IEC |
| 216 | 7816-4 specification as well. APDUs are the application-level packets being |
| 217 | exchanged between the NFC reader and your HCE service. That application-level |
| 218 | protocol is half-duplex: the NFC reader will send you a command APDU, and it |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 219 | will wait for you to send a response APDU in return.</p> |
| 220 | |
| 221 | <p class="note"><strong>Note:</strong> |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 222 | The ISO/IEC 7816-4 specification also defines the concept of multiple logical channels, |
| 223 | where you can have multiple parallel APDU exchanges on separate logical channels. Android’s |
| 224 | HCE implementation however only supports a single logical channel, so there’s only a |
| 225 | single-threaded exchange of APDUs.</p> |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 226 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 227 | |
| 228 | <p>As mentioned previously, Android uses the AID to determine which HCE service the |
| 229 | reader wants to talk to. Typically, the first APDU an NFC reader sends to your |
| 230 | device is a "SELECT AID" APDU; this APDU contains the AID that the reader wants |
| 231 | to talk to. Android extracts that AID from the APDU, resolves it to an HCE service, |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 232 | then forwards that APDU to the resolved service.</p> |
| 233 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 234 | <p>You can send a response APDU by returning the bytes of the response APDU from |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 235 | {@link android.nfc.cardemulation.HostApduService#processCommandApdu processCommandApdu()}. |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 236 | Note that this method will be called on the main thread of |
| 237 | your application, which shouldn't be blocked. So if you can't compute and return |
| 238 | a response APDU immediately, return null. You can then do the necessary work on |
| 239 | another thread, and use the {@link android.nfc.cardemulation.HostApduService#sendResponseApdu sendResponseApdu()} method defined |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 240 | in the {@link android.nfc.cardemulation.HostApduService} class to send the response when you are done.</p> |
| 241 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 242 | <p>Android will keep forwarding new APDUs from the reader to your service, until |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 243 | either:</p> |
| 244 | |
| 245 | <ol> |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 246 | <li>The NFC reader sends another "SELECT AID" APDU, which the OS resolves to a |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 247 | different service;</li> |
| 248 | <li>The NFC link between the NFC reader and your device is broken.</li> |
| 249 | </ol> |
| 250 | |
| 251 | <p>In both of these cases, your class's |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 252 | {@link android.nfc.cardemulation.HostApduService#onDeactivated onDeactivated()} |
| 253 | implementation is |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 254 | called with an argument indicating which of the two happened.</p> |
| 255 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 256 | <p>If you are working with existing reader infrastructure, you need to |
| 257 | implement the existing application-level protocol that the readers expect in |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 258 | your HCE service.</p> |
| 259 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 260 | <p>If you are deploying new reader infrastructure which you control as well, you |
| 261 | can define your own protocol and APDU sequence. In general try to limit the |
| 262 | amount of APDUs and the size of the data that needs to be exchanged: this makes |
| 263 | sure that your users will only have to hold their device over the NFC reader for |
| 264 | a short amount of time. A sane upper bound is about 1KB of data, which can |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 265 | usually be exchanged within 300ms.</p> |
| 266 | |
| 267 | |
| 268 | |
| 269 | <h3 id="ManifestDeclaration">Service manifest declaration and AID registration</h3> |
| 270 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 271 | <p>Your service must be declared in the manifest as usual, but some additional |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 272 | pieces must be added to the service declaration as well.</p> |
| 273 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 274 | <p>First, to tell the platform that it is a HCE service implementing a |
| 275 | {@link android.nfc.cardemulation.HostApduService} interface, your service declaration must contain an |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 276 | intent filter for the {@link android.nfc.cardemulation.HostApduService#SERVICE_INTERFACE} action.</p> |
| 277 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 278 | <p>Additionally, to tell the platform which AIDs groups are requested by this |
| 279 | service, a {@link android.nfc.cardemulation.HostApduService#SERVICE_META_DATA} |
| 280 | <code><meta-data></code> tag must be included in |
| 281 | the declaration of the service, pointing to an XML resource with additional |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 282 | information about the HCE service.</p> |
| 283 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 284 | <p>Finally, you must set the {@code android:exported} attribute to true, and require the |
| 285 | {@code "android.permission.BIND_NFC_SERVICE"} permission in your service declaration. |
| 286 | The former ensures that the service can be bound to by external applications. |
| 287 | The latter then enforces that only external applications that hold the |
| 288 | {@code "android.permission.BIND_NFC_SERVICE"} permission can bind to your service. Since |
| 289 | {@code "android.permission.BIND_NFC_SERVICE"} is a system permission, this effectively |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 290 | enforces that only the Android OS can bind to your service. </p> |
| 291 | |
| 292 | <p>Here's an example of a {@link android.nfc.cardemulation.HostApduService} manifest declaration:</p> |
| 293 | |
| 294 | <pre> |
| 295 | <service android:name=".MyHostApduService" android:exported="true" |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 296 | android:permission="android.permission.BIND_NFC_SERVICE"> |
| 297 | <intent-filter> |
| 298 | <action android:name="android.nfc.cardemulation.action.HOST_APDU_SERVICE"/> |
| 299 | </intent-filter> |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 300 | <meta-data android:name="android.nfc.cardemulation.host_apdu_service" |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 301 | android:resource="@xml/apduservice"/> |
| 302 | </service> |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 303 | </pre> |
| 304 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 305 | <p>This meta-data tag points to an {@code apduservice.xml} file. An example of such a file |
| 306 | with a single AID group declaration containing two proprietary AIDs is shown |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 307 | below:</p> |
| 308 | |
| 309 | <pre> |
| 310 | <host-apdu-service xmlns:android="http://schemas.android.com/apk/res/android" |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 311 | android:description="@string/servicedesc" |
| 312 | android:requireDeviceUnlock="false"> |
| 313 | <aid-group android:description="@string/aiddescription" |
| 314 | android:category="other"> |
| 315 | <aid-filter android:name="F0010203040506"/> |
| 316 | <aid-filter android:name="F0394148148100"/> |
| 317 | </aid-group> |
| 318 | </host-apdu-service> |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 319 | </pre> |
| 320 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 321 | <p>The <code><host-apdu-service></code> tag is required to contain a <code><android:description></code> |
| 322 | attribute that contains a user-friendly description of the service that may be |
| 323 | shown in UI. The <code>requireDeviceUnlock</code> attribute can be used to specify that the |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 324 | device must be unlocked before this service can be invoked to handle APDUs.</p> |
| 325 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 326 | <p>The <code><host-apdu-service></code> must contain one or more <code><aid-group></code> tags. Each |
| 327 | <code><aid-group></code> tag is required to:</p> |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 328 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 329 | <ul> |
| 330 | <li>Contain an <code>android:description</code> attribute that |
| 331 | contains a user-friendly description of the AID group, suitable for display in UI.</li> |
| 332 | <li>Have its <code>android:category</code> attribute set to |
| 333 | indicate the category the AID group belongs to, e.g. the string constants |
| 334 | defined by {@link android.nfc.cardemulation.CardEmulation#CATEGORY_PAYMENT} |
| 335 | or {@link android.nfc.cardemulation.CardEmulation#CATEGORY_OTHER}.</li> |
| 336 | <li>Each <code><aid-group></code> must contain one or more |
| 337 | <code><aid-filter></code> tags, each of which contains a single AID. The AID |
| 338 | must be specified in hexadecimal format, and contain an even number of characters.</li> |
| 339 | </ul> |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 340 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 341 | <p>As a final note, your application also needs to hold the |
| 342 | {@link android.Manifest.permission#NFC} permission to be able to register as a HCE service.</p> |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 343 | |
| 344 | <h2 id="AidConflicts">AID Conflict Resolution</h2> |
| 345 | |
| 346 | <p>Multiple {@link android.nfc.cardemulation.HostApduService} components |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 347 | may be installed on a single device, and the same AID |
| 348 | can be registered by more than one service. The Android platform resolves AID |
| 349 | conflicts depending on which category an AID belongs to. Each category may have |
| 350 | a different conflict resolution policy.</p> |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 351 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 352 | <p>For example, for some categories (like payment) the user may be able to select a |
| 353 | default service in the Android settings UI. For other categories, the policy may |
| 354 | be to always ask the user which service is to be invoked in case of conflict. To |
| 355 | query the conflict resolution policy for a certain category, see |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 356 | {@link android.nfc.cardemulation.CardEmulation#getSelectionModeForCategory |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 357 | getSelectionModeForCategory()}.</p> |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 358 | |
| 359 | <h3 id="CheckingIfDefault">Checking if your service is the default</h3> |
| 360 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 361 | <p>Applications can check whether their HCE service is the default service for a |
| 362 | certain category by using the |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 363 | {@link android.nfc.cardemulation.CardEmulation#isDefaultServiceForCategory} API.</p> |
| 364 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 365 | <p>If your service is not the default, you can request it to be made the default. |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 366 | See {@link android.nfc.cardemulation.CardEmulation#ACTION_CHANGE_DEFAULT}.</p> |
| 367 | |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 368 | <h2 id="PaymentApps">Payment Applications</h2> |
| 369 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 370 | <p>Android considers HCE services that have declared an AID group with the |
| 371 | "payment" category as payment applications. The Android 4.4 release contains a |
| 372 | top-level Settings menu entry called "tap & pay", which enumerates all such |
| 373 | payment applications. In this settings menu, the user can select the default |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 374 | payment application that will be invoked when a payment terminal is tapped.</p> |
| 375 | |
| 376 | <h3 id="RequiredAssets">Required assets for payment applications</h3> |
| 377 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 378 | <p>To provide a more visually attractive user experience, HCE payment applications |
| 379 | are required to provide an additional asset for their service: a so-called |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 380 | service banner.</p> |
| 381 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 382 | <p>This asset should be sized 260x96 dp, and can be specified in your meta-data XML |
| 383 | file by adding the <code>android:apduServiceBanner</code> attribute to the |
| 384 | <code><host-apdu-service></code> tag, which points to the drawable resource. An example is |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 385 | shown below:</p> |
| 386 | |
| 387 | <pre> |
| 388 | <host-apdu-service xmlns:android="http://schemas.android.com/apk/res/android" |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 389 | android:description="@string/servicedesc" |
Scott Main | 45d9321 | 2013-11-12 10:54:53 -0800 | [diff] [blame] | 390 | android:requireDeviceUnlock="false" |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 391 | android:apduServiceBanner="@drawable/my_banner"> |
Scott Main | 45d9321 | 2013-11-12 10:54:53 -0800 | [diff] [blame] | 392 | <aid-group android:description="@string/aiddescription" |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 393 | android:category="payment"> |
| 394 | <aid-filter android:name="F0010203040506"/> |
| 395 | <aid-filter android:name="F0394148148100"/> |
| 396 | </aid-group> |
| 397 | </host-apdu-service> |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 398 | </pre> |
| 399 | |
| 400 | |
| 401 | |
| 402 | <h2 id="ScreenOffBehavior">Screen Off and Lock-screen Behavior</h2> |
| 403 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 404 | <p>Current Android implementations turn the NFC controller and the application |
| 405 | processor off completely when the screen of the device is turned off. HCE |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 406 | services will therefore not work when the screen is off.</p> |
| 407 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 408 | <p>HCE services can function from the lock-screen however: this is controlled by |
| 409 | the <code>android:requireDeviceUnlock</code> attribute in the <code><host-apdu-service></code> tag of your |
| 410 | HCE service. By default, device unlock is not required, and your service will be |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 411 | invoked even if the device is locked.</p> |
| 412 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 413 | <p>If you set the <code>android:requireDeviceUnlock</code> attribute to "true" for your HCE |
| 414 | service, Android will prompt the user to unlock the device when you tap an NFC |
| 415 | reader that selects an AID that is resolved to your service. After unlocking, |
| 416 | Android will show a dialog prompting the user to tap again to complete the |
| 417 | transaction. This is necessary because the user may have moved the device away |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 418 | from the NFC reader in order to unlock it.</p> |
| 419 | |
| 420 | |
| 421 | <h2 id="Coexistence">Coexistence with Secure Element Cards</h2> |
| 422 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 423 | <p>This section is of interest for developers that have deployed an application |
| 424 | that relies on a secure element for card emulation. Android's HCE implementation |
| 425 | is designed to work in parallel with other methods of implementing card |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 426 | emulation, including the use of secure elements.</p> |
| 427 | |
| 428 | <p class="note"><strong>Note:</strong> Android does not offer APIs for directly communicating with a secure element itself.</p> |
| 429 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 430 | <p>This coexistence is based on a principle called "AID routing": the NFC |
| 431 | controller keeps a routing table that consists of a (finite) list of routing |
| 432 | rules. Each routing rule contains an AID and a destination. The destination can |
| 433 | either be the host CPU (where Android apps are running), or a connected secure |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 434 | element.</p> |
| 435 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 436 | <p>When the NFC reader sends an APDU with a "SELECT AID", the NFC controller parses |
| 437 | it and checks whether the AIDs matches with any AID in its routing table. If it |
| 438 | matches, that APDU and all APDUs following it will be sent to the destination |
| 439 | associated with the AID, until another "SELECT AID" APDU is received or the NFC |
| 440 | link is broken.</p> |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 441 | |
| 442 | <p class="note"><strong>Note:</strong> |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 443 | While ISO/IEC 7816-4 defines the concept of “partial matches” as well, this is currently not supported by Android HCE devices.</p> |
| 444 | |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 445 | <p>This architecture is illustrated in figure 4.</p> |
| 446 | |
| 447 | |
| 448 | <img src="{@docRoot}images/nfc/dual-mode.png" /> |
| 449 | <p class="img-caption"><strong>Figure 4.</strong> Android operating with both secure element |
| 450 | and host-card emulation.</p> |
| 451 | |
| 452 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 453 | <p>The NFC controller typically also contains a default route for APDUs. When an |
| 454 | AID is not found in the routing table, the default route is used. Beginning with Android |
| 455 | 4.4, the default route is required to be set to the host CPU. This |
| 456 | means that the routing table typically only contains entries for AIDs that need |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 457 | to go to a secure element.</p> |
| 458 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 459 | <p>Android applications that implement a HCE service or that use a secure element |
| 460 | don't have to worry about configuring the routing table - that is taking care of |
| 461 | by Android automatically. Android merely needs to know which AIDs can be handled |
| 462 | by HCE services and which ones can be handled by the secure element. Based on |
| 463 | which services are installed and which the user has configured as preferred, the |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 464 | routing table is configured automatically.</p> |
| 465 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 466 | <p>We've already described how to declare AIDs for HCE services. The following |
| 467 | section explains how to declare AIDs for applications that use a secure element |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 468 | for card emulation.</p> |
| 469 | |
| 470 | |
| 471 | <h3 id="SecureElementReg">Secure element AID registration</h3> |
| 472 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 473 | <p>Applications using a secure element for card emulation can declare a so-called |
| 474 | "off host service" in their manifest. The declaration of such a service is |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 475 | almost identical to the declaration of a HCE service. The exceptions are:</p> |
| 476 | |
| 477 | <ul> |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 478 | <li>The action used in the intent-filter must be set to |
| 479 | {@link android.nfc.cardemulation.OffHostApduService#SERVICE_INTERFACE}.</li> |
| 480 | <li>The meta-data name attribute must be set to |
| 481 | {@link android.nfc.cardemulation.OffHostApduService#SERVICE_META_DATA}.</li> |
| 482 | <li><p>The meta-data XML file must use the <code><offhost-apdu-service></code> root tag.</p> |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 483 | |
| 484 | <pre> |
| 485 | <service android:name=".MyOffHostApduService" android:exported="true" |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 486 | android:permission="android.permission.BIND_NFC_SERVICE"> |
| 487 | <intent-filter> |
| 488 | <action android:name="android.nfc.cardemulation.action.OFF_HOST_APDU_SERVICE"/> |
| 489 | </intent-filter> |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 490 | <meta-data android:name="android.nfc.cardemulation.off_host_apdu_ervice" |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 491 | android:resource="@xml/apduservice"/> |
| 492 | </service> |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 493 | </pre> |
| 494 | </li> |
| 495 | </ul> |
| 496 | |
| 497 | <p>An example of the corresponding {@code apduservice.xml} file registering two AIDs:</p> |
| 498 | |
| 499 | <pre> |
| 500 | <offhost-apdu-service xmlns:android="http://schemas.android.com/apk/res/android" |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 501 | android:description="@string/servicedesc"> |
| 502 | <aid-group android:description="@string/subscription" android:category="other"> |
| 503 | <aid-filter android:name="F0010203040506"/> |
| 504 | <aid-filter android:name="F0394148148100"/> |
| 505 | </aid-group> |
| 506 | </offhost-apdu-service> |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 507 | </pre> |
| 508 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 509 | <p>The <code>android:requireDeviceUnlock</code> attribute does not apply to off host services, |
| 510 | because the host CPU is not involved in the transaction and therefore cannot |
| 511 | prevent the secure element from executing transactions when the device is |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 512 | locked.</p> |
| 513 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 514 | <p>The <code>android:apduServiceBanner</code> attribute must be used for off host services that |
| 515 | are payment applications as well in order to be selectable as a default payment |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 516 | application.</p> |
| 517 | |
| 518 | <h3 id="OffHostInvocation">Off host service invocation</h3> |
| 519 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 520 | <p>Android itself will never start or bind to a service that is declared as "off |
| 521 | host". This is because the actual transactions are executed by the secure |
| 522 | element and not by the Android service itself. The service declaration merely |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 523 | allows applications to register AIDs present on the secure element.</p> |
| 524 | |
| 525 | <h2 id="HceSecurity">HCE and Security</h2> |
| 526 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 527 | <p>The HCE architecture itself provides one core piece of security: because your |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 528 | service is protected by the {@link android.Manifest.permission#BIND_NFC_SERVICE} |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 529 | system permission, only the OS can |
| 530 | bind to and communicate with your service. This ensures that any APDU you |
| 531 | receive is actually an APDU that was received by the OS from the NFC controller, |
| 532 | and that any APDU you send back will only go to the OS, which in turn directly |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 533 | forwards the APDUs to the NFC controller.</p> |
| 534 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 535 | <p>The core remaining piece is where you get your data that your app sends |
| 536 | to the NFC reader. This is intentionally decoupled in the HCE design: it does |
| 537 | not care where the data comes from, it just makes sure that it is safely |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 538 | transported to the NFC controller and out to the NFC reader.</p> |
| 539 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 540 | <p>For securely storing and retrieving the data that you want to send from your HCE |
| 541 | service, you can, for example, rely on the Android Application Sandbox, which |
| 542 | isolates your app's data from other apps. For more details on Android security, |
| 543 | read |
| 544 | <a href="{@docRoot}training/articles/security-tips.html">Security Tips</a> |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 545 | .</p> |
| 546 | |
| 547 | <h2 id="ProtocolParams">Protocol parameters and details</h2> |
| 548 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 549 | <p>This section is of interest for developers that want to understand what protocol |
| 550 | parameters HCE devices use during the anti-collision and activation phases of |
| 551 | the NFC protocols. This allows building a reader infrastructure that is |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 552 | compatible with Android HCE devices.</p> |
| 553 | |
| 554 | <h3 id="AntiCollisionAct">Nfc-A (ISO/IEC 14443 type A) protocol anti-collision and activation</h3> |
| 555 | |
| 556 | <p>As part of the Nfc-A protocol activation, multiple frames are exchanged.</p> |
| 557 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 558 | <p>In the first part of the exchange the HCE device will present its UID; HCE |
| 559 | devices should be assumed to have a random UID. This means that on every tap, |
| 560 | the UID that is presented to the reader will be a randomly generated UID. |
| 561 | Because of this, NFC readers should not depend on the UID of HCE devices as a |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 562 | form of authentication or identification.</p> |
| 563 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 564 | <p>The NFC reader can subsequently select the HCE device by sending a SEL_REQ |
| 565 | command. The SEL_RES response of the HCE device will at least have the 6th bit |
| 566 | (0x20) set, indicating that the device supports ISO-DEP. Note that other bits in |
| 567 | the SEL_RES may be set as well, indicating for example support for the NFC-DEP |
| 568 | (p2p) protocol. Since other bits may be set, readers wanting to interact with |
| 569 | HCE devices should explicitly check for the 6th bit only, and <stront>not</strong> compare the |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 570 | complete SEL_RES with a value of 0x20.</p> |
| 571 | |
| 572 | <h3 id="IsoDepAct">ISO-DEP activation</h3> |
| 573 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 574 | <p>After the Nfc-A protocol is activated, the ISO-DEP protocol activation is |
| 575 | initiated by the NFC reader. It sends a "RATS" (Request for Answer To Select) |
| 576 | command. The RATS response, the ATS, is completely generated by the NFC |
| 577 | controller and not configurable by HCE services. However, HCE implementations |
| 578 | are required to meet NFC Forum requirements for the ATS response, so NFC readers |
| 579 | can count on these parameters being set in accordance with NFC Forum |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 580 | requirements for any HCE device.</p> |
| 581 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 582 | <p>The section below provides more details on the individual bytes of the ATS |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 583 | response provided by the NFC controller on a HCE device:</p> |
| 584 | |
| 585 | <ul> |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 586 | <li>TL: length of the ATS response. Must not indicate a length greater than 20 |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 587 | bytes.</li> |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 588 | <li>T0: bits 5, 6 and 7 must be set on all HCE devices, indicating TA(1), TB(1) |
| 589 | and TC(1) are included in the ATS response. Bits 1 to 4 indicate the FSCI, |
| 590 | coding the maximum frame size. On HCE devices the value of FSCI must be |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 591 | between 0h and 8h.</li> |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 592 | <li>T(A)1: defines bitrates between reader and emulator, and whether they can be |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 593 | asymmetric. There are no bitrate requirements or guarantees for HCE devices.</li> |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 594 | <li>T(B)1: bits 1 to 4 indicate the Start-up Frame Guard time Integer (SFGI). On |
| 595 | HCE devices, SFGI must be <= 8h. Bits 5 to 8 indicate the Frame Waiting time |
| 596 | Integer (FWI) and codes the Frame Waiting Time (FWT). On HCE devices, FWI must |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 597 | be <= 8h.</li> |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 598 | <li>T(C)1: bit 5 indicates support for "Advanced Protocol features". HCE devices |
| 599 | may or may not support "Advanced Protocol features". Bit 2 indicates support |
| 600 | for DID. HCE devices may or may not support DID. Bit 1 indicates support for |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 601 | NAD. HCE devices must not support NAD and set bit 1 to zero.</li> |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 602 | <li>Historical bytes: HCE devices may return up to 15 historical bytes. NFC |
| 603 | readers willing to interact with HCE services should make no assumptions about |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 604 | the contents of the historical bytes or their presence.</li> |
| 605 | </ul> |
| 606 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 607 | <p>Note that many HCE devices are likely made compliant with protocol requirements |
| 608 | that the payment networks united in EMVCo have specified in their "Contactless |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 609 | Communication Protocol" specification. In particular:</p> |
| 610 | |
| 611 | <ul> |
| 612 | <li>FSCI in T0 must be between 2h and 8h.</li> |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 613 | <li>T(A)1 must be set to 0x80, indicating only the 106 kbit/s bitrate is |
| 614 | supported, and asymmetric bitrates between reader and emulator are not |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 615 | supported.</li> |
| 616 | <li>FWI in T(B)1 must be <= 7h.</li> |
| 617 | </ul> |
| 618 | |
| 619 | <h3 id="ApduExchange">APDU data exchange</h3> |
| 620 | |
Trevor Johns | 7643785 | 2013-12-12 20:09:14 -0800 | [diff] [blame] | 621 | <p>As noted earlier, HCE implementations only support a single logical channel. |
| 622 | Attempting to select applications on different logical channels will not work on |
Scott Main | 6af82cf | 2013-10-31 09:06:59 -0700 | [diff] [blame] | 623 | a HCE device.</p> |