EMV Kernel 8 Explained: EMVCo's Common Contactless Kernel

For years, every card scheme had its own contactless kernel: Visa, Mastercard, American Express, Discover, JCB, UnionPay and others. Terminals had to carry and certify all of them. Kernel 8, defined in EMV Contactless Book C-8, is EMVCo's answer: one contactless kernel that any scheme can use, licensed on the same royalty-free terms as the EMV contact specification.

Why it matters

• Fewer kernels to build and certify. Over time, terminal makers can support one common kernel instead of a long list of scheme kernels.
• Modern cryptography. Kernel 8 brings elliptic curve cryptography (ECC) and AES into contactless transactions.
• Privacy by design. Someone listening to the radio exchange cannot tell which card was used.
• Works alongside existing kernels. It fits the existing EMV contactless architecture, so terminals can add it next to their current kernels during the transition.

How a Kernel 8 transaction works

1. Secure channel. In GET PROCESSING OPTIONS, the kernel sends the card a fresh ECC public key in Kernel Key Data (9E). The card replies with a blinded version of its own public key and an encrypted blinding factor in Card Key Data (9F8103). Both sides derive the same session keys.
2. Encrypted records. When the kernel reads the card's records, anything that identifies the card, such as the PAN or Track 2 data, comes back encrypted with AES under a session key.
3. Risk management. The kernel runs terminal risk management and terminal action analysis.
4. Card-chosen CVM. In GENERATE AC, the kernel offers the CVMs it supports, and the card picks one. The choice comes back in the Cardholder Verification Decision (9F8102).
5. MAC checks. The kernel computes an Issuer Application Data MAC with AES-CMAC and checks the card's Enhanced Data Authentication MAC (9F8105), which binds the cryptogram to the secure channel.
6. Local authentication. If both sides support it, the kernel also validates the card and issuer certificates and the blinding factor.

What changes for developers

• New tags. Kernel 8 data objects use the 9F81xx, 9F82xx and BF81xx ranges, for example the Outcome Parameter Set (9F8210) and Error Indication (9F8204).
• A different TVR. Byte 1 reports local authentication instead of SDA, DDA and CDA, and byte 5 bit 8 marks the Kernel 8 TVR format. Byte 5 also reports an AID mismatch and relay resistance results.
• A different AIP. Tag 82 now carries flags such as "Offline capable" and how to copy the IAD MAC into the Issuer Application Data.
• No issuer action codes. The decision uses TAC-Denial, the terminal type, whether the card is offline capable and TAC-Online.
• Data envelopes. Cards can hold up to ten data envelopes that the terminal reads and writes with secure READ DATA and WRITE DATA commands, if the optional data exchange and data storage feature is implemented.
• Relay resistance. Like Mastercard's kernel, Kernel 8 can time the card's response to detect relay attacks.

Things to check in your project

• Which version of Book C-8 and which specification bulletins your test plan uses. EMVCo has updated the specification since version 1.0.
• Whether you implement the data exchange and data storage option.
• How your host and your logs handle the new tags, especially if you map them to legacy tags with the Tag Mapping List (9F8221).

Kernel 8 and Kernel 2 compared

Configuration data

Book C-8 lists the configuration data each kernel instance needs, with default values for many items. Three examples from version 1.0:

• Kernel Reserved TVR Mask (9F821A), default 84000080CF: the TVR bits the card is not allowed to change when it returns its own Card TVR.
• Terminal Action Code – Denial (9F820B), default 8400000040: decline when local authentication fails or was not performed, or when the AID does not match.
• Terminal Action Code – Online (9F820C), default 840084804C: go online for the same authentication results, an AID mismatch, unsuccessful or captured online CVM, a floor limit breach and relay resistance limits exceeded.

Treat these defaults as a starting point and use the values your acquirer and the schemes require.

Outcomes and errors

Like other EMV contactless kernels, Kernel 8 ends with an Outcome Parameter Set (9F8210) that tells the terminal whether to approve, decline, go online, try again or try another interface. When something goes wrong, the Error Indication (9F8204) gives a Level 1, Level 2 or Level 3 error. Kernel 8 adds Level 2 errors you will not see in older kernels, such as DECRYPTION FAILED, IAD MAC FAILED and EDA MAC FAILED, which all point to the secure channel or key data.

Migration tips

• Check that your entry point selects Kernel 8 correctly from the Kernel Identifier, alongside the scheme kernels you already support.
• Make sure your host and logging can store the new 3-byte tags, or use the Tag Mapping List to report legacy tags.
• Plan for decoding the Kernel 8 TVR and AIP layouts in your support tools, so your team does not misread them as standard values.
• Budget time for the new cryptography in testing: secure channel, record decryption and MAC checks are where early integrations usually fail.

Frequently asked questions

Does Kernel 8 replace the scheme kernels right away?

No. It is designed to run next to existing kernels, and migration is expected to take years as cards and terminals are replaced.

Is RSA still supported?

Yes, as an option. The Kernel Configuration (9F8209) has an "RSA certificates enabled" bit for local authentication with RSA certificates.

Where do I get the specification?

EMVCo publishes Book C-8 and its bulletins on emvco.com. Check the bulletins too, because they update the specification after release.