The STS Standard is the most popular prepayment standard in the world with more that 400 million homesteads in 86 countries using the specification. On our first series of this blog posts, we gave an introduction into the standard and its origins at https://nectar.software/blog/?p=1. Please feel free to review this blog post before going on.
In this blog post, we will begin the technical discussion of how the STS standard works and the various encryption algorithms used in the standard. In further blog posts, we will make detailed reviews of each of these encryption standards and review some of the code required to implement them. While there have been 3 iterations of the IEC 62055-41 prepayment standard, the general implementation of the standard has remained the same with modifications only to the encryption standards used. We’ll explain this as we go along.
The main technical components
To generate STS prepaid tokens, two main processes are involved. First, the generation of a decoder key and second, the use of this generated decoder key and an encryption process to generate a token. These two steps are discussed below.
Step 1: Decoder Key Generation
STS uses symmetric key encryption to generate and decode tokens. A token generation software platform generated an STS token for a specific meter using a decoder key and the respective prepaid meter decodes that token using a similar decoder key. In the case of the STS standard, a secret vending key is generated for each utility. This vending key is then used in combination with several components, most notably a meter no (technically known as the Decoder Register Number (DRN)) to generate these decoder key unique to each DRN. To express it more technically, a decoder key is used by STS compliant software to generate tokens (encrypt) and also inserted into the meter as a DUTK (Decoder Unique Derivation Key) and used to decode the token (decrypt).
Below is a figure showing the decoder key generation process in brief.
First, a decoder key is generated. This decoder key is generated from a Vending key (unique to every service provider), a PAN block and a CONTROL block. The most notable aspects of the PAN and CONTROL block, as mentioned above, are the Meter number (DRN). Depending on the decoder key generation used, this vending key used (and thus the decoder key generated) may be a 128 bit key or a 160 bit key.
In subsequent blog posts, we will discuss the structure of the Vending Key, CONTROL and PAN blocks and look at the various Decoder Key Generation Algorithms used to generate decoder keys from these components. STS supports 4 types of decoder key generation algorithms aptly named DKGA01, DKGA02, DKGA03 and DKGA04. It is worth noting that DKGA01 is legacy while DKGA03 based on 3DES is deprecated. Therefore only DKGA02 and DKGA04 are used with DKGA02 being a lot more popularly used.
The decoder key generation process is usually implemented in hardware security modules (HSMs) which are configured by the STS Foundation with the necessary vending key, PAN block and CONTROL block elements. Nectar however, uses a proprietary virtual HSM to store the configuration required for decoder key generation.
Step 2: The encryption process
Once a decoder key has been generated as the first part of the token generation process, an encryption algorithm is used to generate a 64 bit data block to a 20 digit prepaid token number.
STS supports 3 types of encryption algorithms; the Standard Transfer Algorithm (Encryption Algorithm 07), DEA (Encryption Algorithm 09) and MISTY1 (Encryption Algorithm 11). EA07 is the oldest and most common encryption algorithm supported in most prepaid token meters and token generation platforms. EA09 is deprecated while EA11 is the newest encryption standard that is still gaining traction since it was recently introduced in the IEC 62055-41:2018 iteration of the standard.
These encryption algorithms take the decoder key generated from step 1 and combine this with an input 64 bit data block and a number of encryption algorithms to generate a 64 bit encrypted block, which when converted to base 10 converts into a 20 digit token. The 64 bit input data block is composed of the actual desired values of the token such as the type of token (class and subclass), the time for which the token generation request has been made (also known as the token identifier (TID)), the quantity required (kWh, litres or cubic meters for electricity, water and gas respectively) and a CRC bit string.
Over the next few blog posts, we shall discuss these various encryption standards, the components of the 64 bit input block and some code used in the generation of STS certified tokens.