Understanding CVK (Card Verification Key) and CVV Generation

1. What is CVK?

CVK stands for Card Verification Key.
It’s a symmetric encryption key used by an issuing bank (inside its HSM) to generate and verify CVV values for payment cards.

• Lives only inside the issuer’s HSM (Hardware Security Module)
• Never stored on the card and never leaves the HSM in clear form
• Used with card details to generate Card Verification Values (CVV1, CVV2, CVV3)

---

2. CVV Types and Their Relationship to CVK

CVV Type	Where Stored	Where Used	Key Used
CVV1	Magstripe track data	Card-present (swipe)	CVK1
CVV2	Printed on card	Card-not-present (online, phone)	CVK2
CVV3 (Dynamic/iCVV)	Chip data	EMV chip transactions	CVK3 or derived key

Note: CVK1, CVK2, CVK3 are different keys (or key variants) to compartmentalize security.

---

3. Service Code Difference Between CVV1 and CVV2

The service code is a 3-digit number in magstripe data (ISO 7813).
It’s one of the inputs to the CVV generation algorithm.

• CVV1 uses the real service code from the magstripe (e.g., 201).
• CVV2 uses a dummy service code (e.g., 000), not present on the magstripe.

This difference, combined with using a different CVK, ensures that knowing CVV1 does not allow calculating CVV2.

---

4. How CVK is Stored and Protected

• Under LMK: In the HSM, CVKs are encrypted under the Local Master Key (LMK) variant for CVKs.
• Under ZMK: If CVK must be transported between HSMs, it’s temporarily encrypted under a Zone Master Key (ZMK) for secure transfer.

LMK variant system ensures that each key type (CVK, PVK, ZMK, etc.) is kept separate and cannot be misused for the wrong purpose.

---

5. How a Random CVK Works for All Cards

• CVK is issuer-wide (or per BIN range), not per card.
• During personalization, CVV is calculated using the PAN, expiry date, and service code with the CVK.
• The result (CVV) is stored on the card or printed, not the CVK.
• During verification, the issuer recomputes the CVV with the same CVK and compares.

---

6. Example: CVV1 Generation and Verification

Issuer HSM setup:

CVK = 01 23 45 67 89 AB CD EF  FE DC BA 98 76 54 32 10   (double-length 3DES key)

Card details:

PAN          = 4567 8901 2345 6789
Expiry (YYMM)= 2608   (Aug 2026)
Service code = 201    (magstripe normal use)

Generation process:

1. Concatenate PAN + Expiry + Service Code:
   45678901234567892608201
2. Pack into binary (BCD padding as per ISO 7813).
3. Encrypt with Triple DES using CVK.
4. Decimalize the output and take the first 3 digits:

   Output (hex)      = 4A 6F 2C 8B 92 D1 E5 70 ...
   Decimalized       = 4059821345...
   CVV1              = 405
   

5. Store CVV1 in magstripe Track 2.

Verification process during swipe:

1. POS sends PAN, expiry, service code, and CVV1 read from magstripe.
2. Issuer’s HSM recomputes CVV1 with the same CVK.
3. If recomputed CVV1 matches received CVV1 → approve; else → decline.

---

7. Summary Diagram

Personalization:

[ PAN + Exp + SC ] --(3DES with CVK)--> CVV → store on card

Verification:

[ PAN + Exp + SC ] --(3DES with CVK)--> recomputed CVV → compare

---

8. Key Takeaways

• CVK is random, secret, and stored only in the issuer’s HSM under LMK.
• CVK never exists on the card — only the computed CVV does.
• Separate CVKs and service codes for CVV1, CVV2, CVV3 prevent cross-use attacks.
• Verification is a recomputation and comparison, not a lookup.