Let’s demystify that 20-digit utility token-Part 1

Basic Overview

Prepaid utility tokens. Yes. You read that right. Prepaid tokens are the modern way of delivering credits for prepaid utility services such as water, electricity, or gas to customers. They provide financial safety to service providers by ensuring that the customer gets the service only after making a payment. This eliminates logistical expenses that come with premise visits for reading of meters or ‘raids’ to disconnect unpaying customers.

These tokens fall under the Standard Transfer Specification (STS), which is a global standard introduced in the year 1993 to outline secure transfer of utility credits. Have you ever been curious as to how these tokens are generated? Ever wondered how your meter translates those numbers to units after you have keyed them in? Or why you cannot use a token designated for one meter in a different one? If you have such questions in mind, then you just came across the right post.

Normally, a token will be in the format 0123–4567–8901–2345–6789. Can you make sense of those numbers? Can you spot the number of units allocated? Probably not. That’s because the contents are encrypted within that token. For anyone who may be wondering what encryption is, let’s take a small detour. Consider you live in a place where all the houses’ windows are translucent. You would like to see what is in your house but because the windows are translucent, the only thing you see are distorted images that you can’t make sense of. To see a clear picture, you need to a have key to the door. Only with that key can you have access to what is in that house. The process of opening that house to access its items is what we call decryption.

The same principle applies to the token given above. Whenever you make that payment to the utility service provider, say for instance Kenya Power, they will do their math and assign you some units then encrypt that information with a key, called a decoder key, that corresponds to the one inside the meter. The encrypted information is sent to you in a 20-digit format code to input into your meter. Your meter then uses the stored decoder key to decrypt this information and determine the number of units you have been awarded.

That is the reason why you cannot use a token meant for another meter in yours. It doesn’t have a key to translate a token whose key was different. You may be wondering how they know the key for your meter. Well, when making the payment, you typically include your meter number in the transaction information. That number is very integral to the generation of that decoder key. I have included a diagram that can assist you to visualize the process from end to end.

Figure 1. Simple process flow illustrating purchase to token credit

In the next section, things will start getting more technical but also interesting. The decoder key will form the basis for this post, with future posts focusing on token generation and decryption processes. Brace!

The decoder key

To decode the token, a meter must have a decoder key stored in it. The decoder key is encrypted and stored in a way that it cannot be read out of the device as per standard specification. This decoder key is generated using different algorithms that involve combining the meter number (Decoder Reference Number or DRN), a Vending Key (VK), Supply Group Code (SGC), Issuer Identification Number (IIN), Key Type (KT), Tariff Index(TI), and Key Revision Number(KRN). I will not be diving deep into the specifics of these parameters, but if you would like to know more, you can read about them here

The process of token generation starts with the generation of the decoder key. The encryption-decryption process is symmetrical meaning the decoder key being generated by the vendor is similar to that encoded in your meter. There are 4 decoder key generation algorithms namely DKGA01, DKGA02, DKGA03, and DKGA04. DKGA stands for Decoder Key Generation Algorithm. DKGA01 is old and used in legacy systems whereas DKGA03 is deprecated not in use. In this post, DKGA02 will be explored. I will leave DKGA04 for another day.

The flow diagram for DKGA02 is as follows;

Figure 2. Decoder Key Generation flow diagram

The format of the control block is given as

Figure 3. Control Block

C represents the Key Type which is a digit in the range 0–3. The range 4–7 is reserved.

S represents an individual digit in the Supply Group Code which is a 6 digit number.

T is an individual digit in the Tariff Index in the range 0–9.

R is the Key Revision Number which is a digit in the range 1–9.

F is a pad value. Always represented as 0xF in hexadecimal.

The PAN block format is as follows;

Figure 4. Primary Account Number (PAN) Block

I represents the Issuer Identification Number. This may be 600727 or 0000 depending on the length of the Decoder Reference Number.

D represents the Decoder Reference Number (DRN) and is 11 or 13 digits in length.

For instance, if you have a meter number 56728389216, the PAN block will be as show below;

Figure 5. Sample PAN Block

Notice the 6 is missing? This is because only the 5 least significant digits are used. The least significant digit is one at the far right. In the case of 600727, 7 is the least significant digit whereas 6 is the most significant one.

The 64-bit vending key is generated at the key management center and is normally kept secret because a leaked vending key can be used to generate valid tokens leading to massive loss of revenue for the utility service provider. Through the encryption stages shown in Figure 1, the decoder key is derived and used in the next stage where the actual token is generated. Before discussing the token generation stage, we will write some code to demo the decoder key generation algorithm. Heads up, arbitrary values will be used for the supply group code, tariff index, and key revision number. Additionally, the decoder reference number will be fictitious.

To start, we will require a vending key. This key is not generated every time. It is done once and stored securely in a hardware security module. When a decoder key is required, the vending key is obtained and used in the encryption process. The code below demonstrates how you would go about generating a vending key.

The decoder key is generated through a series of steps as described. First, the PAN and Control blocks are generated and an XOR operation is performed on them. If you are not familiar with XOR, you can brush up your knowledge by reading up on bitwise operations. The result is then encrypted using the DES encryption algorithm where the encryption key is the vending key. Another XOR operation is performed on the encrypted result using the initial pan and control block XOR result. Finally, to obtain the decoder key, another XOR operation is performed on the latest result using the vending key. This has been illustrated in the code below. I may have omitted a lot of things, but it gives a rough idea.

If you are interested in running the code and seeing everything fall into place, you can try it below

StandardTransferSpecification

In summary, we have discussed the basics of token generation and explored decoder key generation as an important step in the token generation process. In the next post, we will be covering the actual token generation process and its interesting aspects. That’s it for this post.

Stay tuned for Part 2 and thanks for reading!