It’s been a long time. Welcome to part 3 of this post. This marks the final part of the series demonstrating the token encryption-decryption processes and the various algorithms used. In the previous post, we discussed the entire token block and its generation strategy. The encryption-decryption process is symmetric. This means that the key used for encryption is also used for decryption. Remember the decoder key discussed in part 1? That key plays a crucial role in the process that will be our main focus. There are 2 main encryption algorithms in use. Encryption Algorithm 7 (EA07) which is DES based and works with Decoder Key Generation Algorithm 2 (DKGA02) and Encryption Algorithm 9 (EA09) working with Decoder Key Generation Algorithm 4 (DKGA04). EA07 differs from EA09 in a number of ways. The key size for EA07 is 64 bits whereas that of EA09 is 128 bits. Additionally, EA07 is a custom DES encryption algorithm whereas EA09 utilizes the MISTY1 encryption algorithm. Given that the entire series has been focusing on DKGA02, EA07 will be explored. Sit tight.
EA07 is a customized Data Encryption Standard (DES) algorithm. It follows DES conventions but differs by utilizing custom substitution and permutation tables and procedures. The diagram below summarizes the entire process.
Substitution Process
Two substitution tables with 16 elements each are provided for the substitution process. The elements in the table are in the range 0–15 representing the indexes of nibbles in a 64 bit data block. Sample substitution tables are shown below.
Before substitution, the 64 bit decoder key is combined with the 64 bit token block through an xor operation. The resulting binary is then chunked into 16, 4-bit nibbles. Bit 3 (fourth from right) is evaluated and if its value is 0 the substitution table 1 is used. Substitution table 2 is used if the value of bit 3 in the nibble is 1. Consider the following worked example.
The nibble at index 0 is 1000 with a value of 1 for bit 3. In this case, substitution table 2 is used. In order to substitute, we use the nibble index as an index in the substitution table and replace the nibble with a binary equal to the number in the substitution table at that nibble index. For this example, the value at index 0 of the substitution table 2 is 2. Binary value of 2 is 0010. So we replace nibble 1000 with 0010. Nibble at index 1 is 0111 in which case substitution table 1 will be used reason being, the value of bit 3 is 0. In this case 0111 will be replace with 0110 which is a binary equivalent of number 6, a value at index 1 in substitution table 1. The substitution process continues until all 16 nibbles are processed.
Permutation process.
You can consider the permutation process to be a predetermined shuffle where bits in the data block are rearranged based on a given permutation table. The process is not so different from the substitution process. A sample permutation table is provided below.
The first value in the table corresponds to bit position 0 (right most bit) whereas the last value corresponds to bit position 63 (left most bit). To perform a permutation, bit at position i is moved to a bit position derived from P[i] where P is the permutation table and i is the index in the table. For instance, the bit at bit position 0 is moved to position 57 in the new data block. Similarly bit at position 4 is moved to position 2 in the destination data block.
An inverse table is provided for decryption purposes in order to map bits back to their original position. A inverse table for the permutation table in figure 4 would look as shown below.
Key Rotation Process
The key is rotated to the left for every round of encryption. For every rotation the most significant bit (bit 63) becomes the least significant bit (bit 0). This has been visualized in the diagram below.
The encryption process has 16 rounds of substitution, permutation and key rotation. After the rounds are done, a 64 bit encrypted data block emerges.
Insertion and Transposition of Class Bits
If you can recall Figure 8 in part 2 of this series, the class bits are not part of the token block during encryption. After insertion the two class bits are swapped with bits at position 28 and 27 respectively. The process is well demonstrated by the diagram below.
Conversion to Token Number
The resulting 66 bit data block is converted to a 20 digit number by simply transforming the binary into a decimal. For example with the data block below;
010010100100000100100001011110011110100011100101100010010000101001
The 20 digit token number for the above block is 2140-2378-5590-9990-5065. You can confirm by using pasting that binary in this tool. In instances where the token number is less than 20 digits, the token is left padded with 0 until a length of 20 is achieved. This is the token number that is sent to the customer by the utility provider.
Code Example
The code below makes use of normal DES encryption algorithm. This may be updated to a version that conforms to the steps outline in figure 1 in the near future.
After the token is sent to the customer and keyed into the meter, the token number is first converted into binary form and padded where necessary into a 66 bit data block. The class bits are the trans-positioned and removed from the data block to leave an encrypted 64 bit block which undergoes the decryption process. Given that the process is symmetric, the decryption is an inverse of the steps taken in encryption. The inverse permutation table is used in the decryption process during the permutation stage. The diagram below demonstrates decryption process flow.
Code Example
A runnable demo from decoder key generation all the way to decryption and extraction of token information is available in the Repl below.
You should expect an output similar to the image below
The most common misconception is that of the token meter communicating with the service provider. This has in most cases brought up the thought that a token number is similar to a scratch card number where the devices sends the number to a service provider as a confirmation and receives credit in return. Apparently that is not the case for STS token meters. The standard was designed to allow meters to be deployed in the most remote places without need for communication. With just the decoder key embedded inside the meter, the provider is only needs to generate and send the tokens to the user’s phone number or in some cases have the token printed on paper. The token meter does not phone home.
This part covered encryption and decryption of token data blocks with various steps of the process being outlined in order to paint a clear picture. I hope you found the content of the entire series enlightening and had the STS token mystery cleared. :). Till next time, see yah!