Talk:Derived unique key per transaction

Untitled

Can someone add the URL to the ANSI standard ? Many thanks Rmartelloni (talk) 14:09, 22 September 2014 (UTC)

The URL is already in the article - were you hoping for something else? Exponium (talk) 15:10, 22 September 2014 (UTC)

No thank you. Rmartelloni (talk) 09:53, 23 September 2014 (UTC)

There is no URL to the ANSI standard. ANSI offers a PDF of the standard for $140. Charlie McKeon (talk) 16:31, 3 April 2018 (UTC)

---

Can Derved unique key per transaction hacked. as this BDK needs to be shared with all the terminal vendors who collect to a host or network

Only solace might be that if different bdks are used with different vendors. then there needs to be an additional identification to identify the terminal model too..

The BDK is not shared.

Each Point-of-Interaction (POI) device—such as a Point-of-Sale (POS) device—contains a Tamper Resistant Security Module (TRSM).

A key set consists of

· a BDK

· Initial PIN Encryption Keys (IPEKs), one IPEK for each POI device

· Future Keys, one Future Key for each transaction

A Key Serial Number (KSN) has three parts:

· Key Set ID

· TRSM ID

· a transaction counter

Given a KSN input to an HSM storing the key set's BDK, the HSM uses the BDK to generate an IPEK from the TRSM ID. The KSN and IPEK are injected into a POI device. Inside the POI device, its TRSM stores the KSN and uses the IPEK to generate the first few of a series of Future Keys. Afterwards the TRSM immediately destroys the IPEK. The POI device is installed at a POI.

At the POI during a transaction a customer enters a PIN into the POI device. Using the firstmost Future Key in its series of Future Keys, the TRSM generates cyphertext of the PIN. The POI device outputs the KSN and cyphertext. Using the same Future Key, the TRSM generates a few more in the series of Future Keys. Afterwards the TRSM immediately destroys the used Future Key and increments the transaction counter in its KSN.

Each KSN and cyphertext pair is transmitted to a receiving party, which determines the key set from the Key Set ID in the KSN. The KSN and cyphertext are input to the HSM storing the key set's BDK. Using the BDK the HSM derives the transaction's Future Key from the TRSM ID and the transaction counter in the KSN. Using the transaction's Future Key the HSM recovers the customer's PIN from the cyphertext. Charlie McKeon (talk) 12:17, 11 April 2018 (UTC)

---

I have no idea how to work Wikipedia. Whoever commented above is simply wrong, the BDK does not need to be shared. The BDK is used to compute a device-specific Initially Injected Key which is given to a 'terminal vendor,' or more commonly, one BDK is given to each terminal vendor; if the terminal gets moved to a new vendor it either gets new keys or the IIK is given to the new vendor, NOT THE BDK.

In addition, Wikipedia should note DUKPT is described in (too much?) detail in ANSI X9.24-1:2009, I have a copy and would ontribute to the article if I had time to learn how to use WIki properly. Perhaps someone would like to take a writeup from me and format it for Wiki? —Preceding unsigned comment added by 99.35.164.204 (talk) 17:41, 23 November 2010 (UTC)

---

If anyone is still tracking this entry, I would like to know more about how the Future Keys are derived. It is stated that the IPEK is discarded once the initial Future Keys are created, and I've read there are a maximum of 21 FK at any given time. I've also read that FKs are discarded once used and a new FK generated for future use, and this would imply that Future Keys can be created from other Future Keys (since the IPEK was long discarded).

Yes, the implication is right: Futurex (n.d.) blogged that "the initial key is used to create a pool of encryption keys, and during each transaction, one of the keys is selected from the pool to encrypt information. After the data is sent, the current key is used to create additional future keys, and then it is erased, removing any information about a previous transaction." Charlie McKeon (talk) 16:31, 3 April 2018 (UTC)

Either way, doesn't the central HSM with the BDK need to know an additional something (some input) into the FK generation process in order to derive the Session Key (given the KSN) which is ultimately the symmetric key used to decrypt the PIN? Am I missing something obvious?

See my comment in the second section above. Charlie McKeon (talk) 16:31, 3 April 2018 (UTC)

(I know it's in the ANSI spec -- I don't have access. Thanks) — Preceding unsigned comment added by 56.0.165.248 (talk) 19:00, 4 September 2013 (UTC)

---

This article probably should specify that it's about 3DES DUKPT. AES DUKPT is a slightly different standard with different sized counters and logic (unless operating in a particular mode). All the people talking about ANSI X9.24-3 are talking about AES DUKPT, while the text of the article is 3DES DUKPT. I'm unsure if 3DES DUKPT is standardised outside of AS2805.6.7

References