boltcard/docs/DETERMINISTIC.md

Abstract

The NXP NTAG424DNA allows applications to configure five application keys, named K0, K1, K2, K3, and K4. In the Bolt card configuration:

• K0 is the App Master Key, it is the only key permitted to change the application keys.
• K1 serves as the encryption key for the PICCData, represented by the p= parameter.
• K2 is the authentication key used for calculating the SUN MAC of the PICCData, represented by the c= parameter.
• K3 and K4 are not used but should be configured as recommended in the NTag424 application notes.

A simplistic approach to issuing Bolt cards would involve randomly generating the five different keys and storing them in a database.

When a validation request is made, the verifier would attempt to decrypt the p= parameter using all existing encryption keys until finding a match. Once decrypted, the p= parameter would reveal the card's uid, which can then be used to retrieve the remaining keys.

The primary drawback of this method is its lack of scalability. If many cards have been issued, identifying the correct encryption key could become computationally expensive.

In this document, we propose a solution to this issue.

Key generation

Assuming the LNUrl Withdraw Service generates a random key named (the IssuerKey) and has a batch of Bolt Cards to configure, it will set the following parameters:

• K0 = PRF(IssuerKey, '2d003f76' || batchId || UID)
• K1 = PRF(IssuerKey, '2d003f77' || batchId)
• K2 = PRF(IssuerKey, '2d003f78' || batchId || UID)
• K3 = PRF(IssuerKey, '2d003f79' || batchId || UID)
• K4 = PRF(IssuerKey, '2d003f7a' || batchId || UID)

batchId: 4 bytes identifying the batch of card. (Can be set to 00000000 if uneeded)

The Pseudo Random Function PRF(key, message) applied during the key generation is the CMAC algorithm described in NIST Special Publication 800-38B.

How the to implement a Reset feature

If a LNUrl Withdraw Service offers a factory reset feature for a user's bolt card, here is the recommended procedure:

1. Read the NDEF lnurlw URL, extract p= and c=.
2. For each existing batchId:
   1. Derive K1, decrypts p= to get the PICCData.
   2. If PICCData[0] != 0xc7, go to the next batchId.
   3. Take UID=PICCData[1..8], derive K2
   4. Calculate the SUN MAC with K2, if different from c=, go to next batchId
3. From the UID, the IssuerKey and the batchId with correct SUN MAC, recover K0, K3, and K4.
4. Execute AuthenticateEV2First with K0
5. Erase the NDEF data file using WriteData or ISOUpdateBinary
6. Restore the NDEF file settings to default values with ChangeFileSettings.
7. Use ChangeKey with the recovered application keys to reset K4 through K0 to 00000000000000000000000000000000.

Rational: Attempting to call AuthenticateEV2First without validating the p= and c= parameters could render the NTag inoperable after a few attempts.

How to implement a verification

If a LNUrl Withdraw Service needs to verify a payment request, follow these steps:

1. Read the NDEF lnurlw URL, extract p= and c=.
2. For each existing batchId:
   1. Derive K1, decrypts p= to get the PICCData.
   2. If PICCData[0] != 0xc7, go to the next batchId.
   3. Take UID=PICCData[1..8], derive K2
   4. Calculate the SUN MAC with K2, if different from c=, go to next batchId
3. If no correct SUN MAC has been found, returns an error.
4. Confirm that the last-seen counter for ID=PRF(IssuerKey, '2d003f7b' || batchId || UID)[0..7] is lower than what is stored in counter=PICCData[8..11].
5. Update the last-seen counter.

The specific method for calculating ID is not crucial; the recommendation is to avoid using UID directly. This approach offers both privacy and security benefits.

Mainly, since the UID is used to derive keys, it is better to not store it outside the NTag.

Security consideration

Since K1 is shared among multiple Bolt Cards, the security of this scheme is based on the following assumptions:

• K1 cannot be extracted from a legitimate NTag424.
• Bolt Card setup occurs in a trusted environment.

While NXP gives assurance keys can't be extracted, a non genuine NTag424 could potentially expose these keys.

Furthermore, because blank NTag424 uses the well-known initial application keys 00000000000000000000000000000000, communication between the PCD and the PICC could be intercepted. If the Bolt Card setup doesn't occurs in a trusted environment, K1 could be exposed during the calls to ChangeKey.

However, if K1 is compromised, the attacker still cannot produce a valid checksum and can only recover the UID for tracking purposes.

Note that verifying the signature returned by Read_Sig can only prove NXP issued a card with a specific UID. It cannot prove that the current communication channel is established with an authentic NTag424. This is because the signature returned by Read_Sig covers only the UID and can therefore be replayed by a non-genuine NTag424.

Test vectors

Input:

UID: 04a39493cc8680
Batch: 01000000
Issuer Key: 00000000000000000000000000000001

Expected:

K0: 60ef62b99ed8dc351ef7382b7d9e60f0
K1: aa104a0bef8f751add9f06c5f000837a
K2: 2ed57c172cf9b2ef8d8bfa6c9175d117
K3: b943783b3265f0c9091f716eab470b06
K4: 9fdd4ad2e7f2c0030eb84e695b257434
ID: 3cd713f36fc177