A deep dive into Decoder Key Generation – DKGA01 – Part 4.1

In this fourth series of these blog posts, we shall begin to review the specific algorithms used in the Decoder Key Generation process and look specifically at DKGA01. As mentioned in the previous blog post, the decoder key generation is the first part of generating STS compliant prepaid tokens. This process converts the various kinds of vending keys to decoder keys. It is worth noting that the decoder key generation process is usually performed in a physical Hardware Security Module (HSM). Nectar however uses a virtual HSM to prevent the throttling measures added into HSMs and improve performance while maintaining security.

If you have not reviewed the previous blog post, please review it here first.

Introduction

While a service provider will usually only have a single vending key at a time, unique decoder keys have to be generated from this vending key for each service provider’s STS certified prepaid meter. These decoder keys are usually generated by the manufacturer and encoded into the meter before delivery to a service provider. In addition, a token generation system uses a vending key and meter no (Decoder Register Number – DRN) to generate decoder keys for every token generation request before passing along this decoder key to the next step of the token generation process.

The IEC 62055-41:2014 standard contains 3 decoder key generation algorithms; DKGA01, DKGA02 and DKGA03. IEC 62055-41:2018 however deprecated DKGA03 in favor of a new decoder key generation algorithm DKGA04. Therefore token generation systems and prepaid meters currently require to support DKGA02 or DKGA03 to achieve STS compliance certification from the STS Foundation. DKGA01 is legacy.

Code	DKG Algorithm	Encryption Method
01	DKGA01	Limited to early legacy STS compliant meters
02	DKGA02	Uses 64 bit DES Vending Key Derivation
03	DKGA03	Uses dual 64 bit Vending Key Derivation
04	DKGA04	Uses KDF-HMAC-SHA-256 Vending key Derivation

Let’s review each of these decoder key generation algorithms.

DKGA01

DKGA01 was one of the earliest DKGAs used in the STS standard before it was superseded by DKGA02. In fact, it is only maintained in the standard for backward compatibility with early prepaid meters and should not be used for token generation unless your meters meet ALL of the following specific conditions:

• Your meters use an Issuer Identification No (IIN) of 600727. The Issuer Identification No is a number assigned (usually by the STS Foundation by a Service Provider) for accounting purposes to identify transactions. It is concatenated with a meter no (DRN) to generate a token as we will see below. Where the DRN is 11 digits (the majority of cases), then the IIN will be a 6 digit number. Right now, even the newest meters and token generation systems still use 600727 by default as the IIN. Where the meter no (DRN) is 13 digits, then the IIN must be 0000. In practice, the IIN is not used for identification of transactions but merely as 600727 as a relic of the standard.
• Your meters use a Key Revision No (KRN) of 1. The KRN is an artifact of the STS standard and specifies which version of the vending key a service provider is using to generate tokens. It can range from 1-9 meaning the STS standard in theory supports just 9 versions of vending keys per service provider.
• Your meters use a Key Type (KT) of 1 or 2. A KT is basically a number that identifies the type of vending or decoder key used. As we mentioned in the previous post, there are 4 types of vending keys and 3 types of vending keys. These are all assigned the respective KT number as shown below.

KT	SGC Type	Vending Key Type	Decoder Key Type
0	Initialization	n/a	DITK
1	Default	VDDK	DDTK
2	Unique	VUDK	DUTK
3	Common	VCDK	DCTK

• Where the encryption algorithm (EA) standard used is EA07 (or in full, the Standard Transfer Algorithm (STA)). We shall be discussing encryption algorithms, which are the next process of token generation after decoder key generation, in a later set of articles in this series.
• Where the meter no (DRN) falls within the following ranges:

0109000000X	to	0109000499X
0100000000X	to	0100499999X
0300000000X	to	0311400000X
0400000000X	to	0405999999X
0601000000X	to	0603999999X
0640000000X	to	0641999999X
0660000000X	to	0669999999X
0699000001X	to	0699000999X
0700000000X	to	0702099999X

Note that X above is calculated using a simple technique using the luhn algorithm (as specified in ISO7812-1:2006).

Alternatively, to qualify to use this decoder key generation algorithm, a meter should use an IIN of 600727, a KRN of 1, a KT of 3, an EA of 7 and should have a Supply Group Code (SGC) that is one of the following values (SGC is explained in previous blog articles)

100702

990400

990401

990402

990403

990404

990405

I am not quite sure why these specific requirements are necessary for the use of the DKGA01. I suspect that this is because this was a typical installation back in the day and this configuration is a relic of that time.

So let’s see how DKGA01, actually works:

How DKGA01 actually works

As mentioned, DKGA01 uses the Data Encryption Standard (DES) to convert a vending key into a decoder key. DES is a widely popular and dated symmetric encryption standard that has now been successfully crypto-analysed. DKGA01 has the following steps:

Generating the CONTROL block

The first step in the DKGA01 process is the generation of a CONTROL block. A CONTROL block is really a combination of some parameters of a service provider’s STS configuration. Remember the STS configuration will be composed of a number of parameters all of which will be usually provided by the STS Foundation.

A CONTROL block is made of the following components:

• A Key Type (KT) digit – Denoted as C in the table below
• The Supply Group Code (SGC) – Denoted as S in the table below
• A Tariff Index (TI) Digit – Denoted as T in the table below
• A Key Revision No (KRN) digit – Denoted as R in the table below
• A Pad value which should always be 0xF hex repeated 6 times.

All these components except for the Tariff Index (TI) have been explained in this or previous blogs. A Tariff Index (TI) is a 2 digit number used to identify a tariff type. The assumption is that a service provider may have a number of tariffs and the TI is used to identify which tariff charges are used in generating a specific token. In practice however, many service providers use a TI that has no relation to the current tariff used.

Therefore a CONTROL block looks like this when generated:

Position	15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
Value	C	S	S	S	S	S	S	T	T	R	0xF	0xF	0xF	0Xf	0xF	0xF

Generating the PAN Block

The next step in the Decoder Key Generation Process is generating the PAN Block. The PAN Block is a combination of 2 things:

• The IIN – Which as explained above is an identifier for transactions (Denoted as I in the table below)
• The DRN or meter no – which uniquely identifies a meter (Denoted as D in the table below)

Remember the IIN can be 4 or 6 digits (600727 or 0000) in which case the DRN will be 11 or 13 digits respectively. A valid STS configuration conforms to this requirement.

Position	15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
Value	I	I	I	I/D	I/D	D	D	D	D	D	D	D	D	D	D	D

Combining the CONTROL Block, PAN Block and Vending Key to generate a Decoder Key

Once the CONTROL and PAN blocks are generated, they are combined with the Vending Key to generate the Decoder Key using the DES symmetric encryption algorithm. All these 3 components required are provided as part of a valid STS configuration. The vending key is a 64 bit key that has a similar structure to 0x012abcde hex

To clarify, based on the chart above, the following are the steps required to generate a decoder key from a vending key using DKGA01:

1. Create the CONTROL block as described above
2. Create a PAN Block as described above
3. Perform an XOR operation on the CONTROL and PAN Blocks
4. Encrypt the output of this XOR operation using DES (with the encryption key being the Vending Key)
5. Perform an XOR operation of the output of this encryption Key with the Vending Key itself

A 64 bit decoder key will then be generated.

Let’s have a look at some example code snippet to see how this works in practice. I am using Java but feel free to transpose this to your desired programming language:

public DecoderKey generate() throws Exception {
        ControlBlock controlBlock = createControlBlock();
        PrimaryAccountNumberBlock primaryAccountNumberBlock = createPrimaryAccountNumberBlock();
        if(issuerIdentificationNumber.getValue() == "600727" &&
                keyRevisionNumber.getValue() == 1 &&
                encryptionAlgorithm.getCode() == "07") {
            if(((keyType.getValue() == 1 || keyType.getValue() == 2) && iainWithinRange(individualAccountIdentificationNumber)) ||
                    (keyType.getValue() == 3 && sgcHasValidValue(supplyGroupCode))) {
                byte[] panBlockData = Hex.decode(primaryAccountNumberBlock.getValue());
                byte[] controlBlockData = Hex.decode(controlBlock.getValue());
                byte[] panXorControlBlock = xor(panBlockData, controlBlockData);
                byte[] encryptedPanXorControlBlock = encrypt(panXorControlBlock);
                byte[] decoderKeyData = xor(encryptedPanXorControlBlock, vendingKey.getKeyData());
                return new DecoderKey(decoderKeyData);
            }
        }
        throw new InvalidDecoderKeyParametersException(Strings.INVALID_DECODER_KEY_PARAMETERS);
    }

I hope this clarifies how DKGA01 works. In the next blog post in the series, we shall look at the DKGA02 algorithm and how that functions. Please feel free to comment below or ask questions.