The first part of generating an STS token, the Decoder Key Generation – Part 3

In this third series of this blog post, we get into the technical details on generating STS certified tokens. We will begin to specifically look at the first of the two processes used in token generation known as the decoder key generation process.

Please review part 1 and part 2 of these blog posts if you have not done so before going on.

Why is the decoder key generation process necessary?

The decoder key generation process is used to isolate the vending key from the remainder of the STS token generation process. A vending key is a 128 bit value used by a service provider for token generation and is at the heart of the STS token generation process. Usually assigned by the STS foundation (although you can generate it on your computer), it is commonly denoted in hex (e.g. 0x0abc12def3456789 – each char is 8 bits).

This isolation process is critically important since a leaked vending key can be used to generate tokens for ANY meter belonging to a service provider using the STS configuration that uses this vending key. As you can imagine, this can lead to significant loss of revenue and vending keys are kept extremely secret.

As we mentioned in the previous blog post, the STS standard uses symmetric key encryption to generate and decode tokens. As part of the decoder key generation process, HSMs use this vending key (and among other configurations, a meter no technically called a Decoder Register Number – DRN) to generate a 128 bit decoder key unique for that meter. On Nectar however, this is done using a virtual HSM on the cloud since physical HSMs are usually band-limited to generate no more than 5,000 tokens a minute) and do not scale based on demand.

As mentioned in the previous blog post, the generated decoder key is then passed on to the second part of the token generation process that uses information such as a timestamp (Token Identifier – TID), service type (electricity, water or gas) and desired number of units to generate a 66 bit data block (or 20 digit number) that is ultimately sent to a service provider customer. This second part of the token generation process is done by the Token Generation System.

Once this 20 digit token has been sent to a customer who enters it into a prepaid meter, the meter uses a decoder key to decrypt the token contents and perform the required action required by the token. Remember STS tokens can be used to perform multiple engineering and credit functions on the meter (such as checking meter status, loading units e.t.c.). The decoder key in this prepaid meter must be the same as the one used to generate the token in the Token Generation System. And this is usually the case since the vending key is usually shared with the meter manufacturer (in a HSM) who then uses it to generate and encode decoder keys unique to each meter before they ship the meters to the service provider.

Types decoder key generation algorithms (DKGA)

  1. In the IEC 62055-41:2007 and IEC 62055-41:2014 standards, 3 decoder key generation standards are allowed for use DKGA01, DKGA02 and DKAG03.
  2. In the latest version of the STS standard, IEC 62055-41:2018, DKGA03 was deprecated and a new decoder key generation algorithm, DKGA04 introduced. This standard therefore allows DKGA01, DKGA02 and DKGA04 for use. No new STS devices will be certified if they only support DKGA03.

Most prepaid meters will only support one of these types of DKGAs. In addition, it is important to note that the STS standard allows for different kinds of decoder keys that each serve a different purpose.

  • A Decoder Initialization Transfer Key (DITK) is inserted by the meter manufacturer for their own testing and verification. They are the only type of decoder key that can be stored in a meter as a plain text value and should be used for the generation of tokens. It’s Key Type (KT) value is 0.
  • A Decoder Default Transfer Key (DDTK) is an encrypted key usually generated from a DITK and inserted into a meter that has not yet been assigned a Supply Group Code (SGC). An SGC is simply a 6 digit number (e.g. 123456) that defines the region or physical location that a meter will be installed in. For example, a utility or service provider may divide a country into 10 regions. Each of these regions will then be assigned a specific SGC e.g. 123450, 123451 e.t.c. and various prepayment meters will then use these SGCs when generating tokens. If the meter however has not been assigned to an SGC, it will contain a DDTK. Technically, this DDTK should not be used to generate tokens (since as we will see in subsequent blog posts, an SGC is required for token generation anyway) but some manufacturers and service providers leave the decoder type as DDTK even after SGCs have been assigned for the meter. It’s Key Type (KT) value is 1.
  • A Decoder Default Transfer Key (DDTK) is an encrypted key used in meters that have a default SGC assigned. It can be generated from a DDTK. A default SGC is an SGC assigned to a meter before it is allocated to a unique SGC. Technically, a DDTK should not be used for generating or decoding tokens but this is often done in the field. It’s Key Type (KT) value is 2.
  • The Decoder Unique Transfer Key (DUTK) which is an encrypted key encoded into a meter assigned to a specific (unique) Supply Group Code. It can be generated from a DDTK. It is technically ok for a token generation system to use it for token generation and for a prepaid meter to use a DUTK to decrypt tokens. It’s Key Type (KT) value is 3.
  • Finally, the Decoder Common Transfer Key (DCTK) is an encrypted key similar to the DUTK. It is however only used to generate tokens for prepaid meters that accept erasable magnetic cards to store tokens. Since erasable magnetic cards are not as popular in prepaid meters anymore, DCTKs are rarely used. It’s Key Type (KT) value is 4.
Magnetic Strip Cards

Therefore, a manufacturer will usually have meters with plain text DITKs lying around before sale. Once they receive an order from a service provider and a vending key (usually from the STS foundation via a HSM), they will then use each of these meters’ DITK to generate DUTKs and encode them into the meters. DUTKs are the type of decoder key that should technically be used in token generation.

Key TypeSGC TypeDecoder Key TypeComplete Name
0InitializationDITKDecoder Initialization Transfer Key
1DefaultDDTKDecoder Default Transfer Key
2UniqueDUTKDecoder Unique Transfer Key
3CommonDCTKDecoder Common Transfer Key

Similar to decoder keys, there are also different types of vending keys. The vending key usually provided by the STS foundation will technically be a VUDK or VCDK (Vending Unique Derivation Key or Vending Common Derivation Keys) and these are used by the prepaid meter manufacturer to generate DUTKs and DCTKs for meters respectively.

Don’t let these types of vending and decoder keys confuse you. The important thing to note is that the STS foundation will provide you with a a vending key. This vending key will then be used to generate a decoder key specific to each meter using each meter’s meter no (DRN). The important thing to take note of is the key type of the decoder key the manufacturer used. In theory this should be key type 2 or 3 but I have seen 0 and 1 used as well.

In the next blog post, we shall begin to review each of the 4 types of decoder key generation algorithms (DKGA01, DKGA02, DKGA03 and DKGA04) and go into the specifics of how they work and look at some code. Reviewing these decoder key generation algorithms will explain exactly how a vending key is converted into its respective type of decoder key.

Stay tuned!

2 thoughts on “The first part of generating an STS token, the Decoder Key Generation – Part 3

  1. Thanks for ones marvelous posting! I truly enjoyed reading it, you are a great author.

    I will ensure that I bookmark your blog and will come
    back someday. I want to encourage you continue your
    great writing, have a nice evening!

Comments are closed.