NRS009 6 7
NRS009 6 7
1. Copyright
This standard is available to staff members of companies that have subscribed to the
complete collection of SANS standards in accordance with a formal copyright
agreement. This document may reside on a CENTRAL FILE SERVER or INTRANET
SYSTEM only. Unless specific permission has been granted, this document MAY NOT
be sent or given to staff members from other companies or organizations. Doing so
would constitute a VIOLATION of SABS copyright rules.
2. Indemnity
The South African Bureau of Standards accepts no liability for any damage whatsoever
than may result from the use of this material or the information contain therein,
irrespective of the cause and quantum thereof.
N R S
Gr 10
COPYRIGHT RESERVED
NOTICE
This section of NRS 009-6 specifies requirements that are part of the standard transfer
specification (STS). The intellectual property rights of the STS are owned by the STS
1
Association.
Implementation of an STS compliant system will require access to encryption and decryption
tables and the STS encryption keys, which are made available under licence conditions
through membership of the STS Association. Details of requirements to become a member of
the STS Association can be obtained from the contact details given below.
Amdt 2
Suppliers who are to claim that their equipment complies with the STS are required to have the
relevant equipment accredited by the STS Association or its agent. Such equipment will be
permitted to carry a mark that signifies compliance with the STS.
Application for accreditation of equipment as compliant with the STS can be made to the STS
Association:
[email protected]
Postal address:
PO Box 2332
Durban
4000
South Africa
Further information concerning the STS Association can be obtained from its website:
http://www.sts.org.za
1
A section 21 “not for gain” company incorporated in the Republic of South Africa.
1 NRS 009-6-7:2002
Contents
Page
Foreword ........................................................................................................................... 2
Introduction ....................................................................................................................... 4
Key words ......................................................................................................................... 4
1 Scope ......................................................................................................................... 5
2 Normative references ................................................................................................... 5
3 Terms, definitions and abbreviated terms ....................................................................... 6
4 Requirements .............................................................................................................. 6
4.1 Bit allocation tables ............................................................................................... 6
4.2 Field calculations ................................................................................................. 9
4.3 STS security ........................................................................................................ 16
4.4 Default ED key generation module ......................................................................... 17
4.5 Preventing ED-specific token reuse ....................................................................... 17
4.6 Encryption algorithm 1 .......................................................................................... 18
4.7 Decryption algorithm 1 .......................................................................................... 20
4.8 Data encryption example ...................................................................................... 22
4.9 Data decryption example ...................................................................................... 24
Annex
Bibliography ...................................................................................................................... 27
NRS 009-6-7:2002 2
Foreword
This section of NRS 009-6 has been adopted by the Electricity Suppliers Liaison Committee (ESLC)
and has been approved by it for use by supply authorities in South Africa.
Amendment 2 to this section of NRS 009-6 provides for deletion of direct cross-references to
NRS 009-4-2, which is not part of the standard transfer specification. The requirements of
NRS 009-4-2 that are relevant to this section of NRS 009-6 have been included in an annex.
NRS 009 is based on Eskom specification MC114, Requirements specification for a common vending
system for electricity dispensing systems, and consists of the following parts, under the general title
Electricity sales systems:
ISBN 0-626-14119-2
3 NRS 009-6-7:2002
An amendment to edition 2.1 of this section of NRS 009-6 was submitted by the STS Association in
2002, which was endorsed by a Working Group that comprised the following members:
A Manufacturers’ Interest Group (MIG) was consulted on the amendment of this section of NRS 009.
The MIG comprised the following members:
The working group acknowledges the contribution of S J Leigh, who compiled the standard transfer
specification while with Conlog, under a contract to Eskom. The intellectual property rights to the STS
have been ceded to the STS Association. See the notice at the front of this section of NRS 009-6.
The Working Group was appointed by the ESLC, which, for the of approval of amendment 2,
comprised the following members:
Recommendations for corrections, additions or deletions should be addressed to the NRS Project
Manager, c/o SABS, Private Bag X191, Pretoria, 0001.
NRS 009-6-7:2002 4
Introduction
This section of NRS 009-6 is one of a series of specifications that describe the standard transfer
specification (STS), whereby transactions can be securely transferred from point of sale equipment to
individual electricity dispensers by means of encrypted data on tokens.
The STS is specified in the following parts or sections of NRS 009. Compliance with all the normative
(mandatory) requirements of all the following is a requirement for implementation of an STS compliant
electricity sales system:
This section of NRS 009-6 describes encryption and decryption processes that are intended primarily
for use with tokens in prepayment electricity dispensing systems. However, these tokens can also
cater for the transfer of units of other utility types, for example water or gas.
Key words
Electricity sales systems; Payment systems; Prepayment; Standard transfer specification; Electricity
dispenser; Token; Token encoding; Data encryption; Data decryption.
5 NRS 009-6-7:2002
SPECIFICATION
1 Scope
This section of NRS 009-6 specifies the formatting of transaction data for encryption, the encryption
process and the preparation of the encrypted data for encoding onto the token. It also specifies the
decryption process that takes place in the electricity dispenser (ED).
This section of NRS 009-6 is intended for use by manufacturers of EDs that have to accept tokens that
comply with the standard transfer specification (STS) and also by manufacturers of vending systems
that produce STS-compliant tokens.
2 Normative references
The following standards and specifications contain provisions which, through reference in this text,
constitute provisions of this section of NRS 009-6. At the time of publication, the editions indicated
were valid. All standards and specifications are subject to revision, and parties to agreements based
on this section of NRS 009-6 are encouraged to investigate the possibility of applying the most recent
editions of the documents listed below. Information on currently valid national and international
standards and specifications can be obtained from the South African Bureau of Standards.
ISO IEC 7812-1:2000, Identification cards — Identification of issuers — Part 1: Numbering system.
Amdt 2
SABS 1524-0:1997, Electricity dispensing systems — Part 0: Glossary of terms and system overview.
NRS 009-4-2:1993, Electricity sales systems — Part 4: National electricity meter cards and associated
numbering standards — Section 2: National electricity meter numbers.
NOTE The requirements of NRS 009-4-2 which are relevant to this section of NRS 009-6 have been included in
annex A .
Amdt 2
NRS 009-6-7:2002 6
NOTE Throughout this section of NRS 009-6, reference is made to “ED” (electricity dispenser), which is synonymous
with “prepayment meter”.
Amdt 2
4 Requirements
Tokens for credit transfer transactions shall be encoded as set out in table 1. Bits are numbered from
right to left starting at 0. A total of 66 bits are used and are numbered from 0 to 65.
1 2 3 4 5 6 7
Function description Class Sub- Random Token Transfer Cyclic
class pattern identifier amount redundancy
check sum
Electricity credit 00 0000
Water credit 00 0001
Gas credit 00 0010
Connection time credit 00 0011
Currency credit 00 0100
00 0101
00 0110
Length 4 bits Length 24 bits Length 16 bits Length 16 bits
00 0111 Occupies Occupies Occupies Occupies
00 1000 bits 56 bits 32 bits 16 bits 0 to 15
to 59 to 55 (inclusive) to 31 (inclusive)
00 1001 (inclusive)
(inclusive) (See 4.2.3) (See 4.2.6)
Reserved for future STS (See 4.2.4)
00 1010 (See 4.2.5)
use
00 1011
00 1100
00 1101
00 1110
00 1111
← These 64 bits are encrypted →
7 NRS 009-6-7:2002
Tokens for non-ED-specific management transactions shall be encoded as set out in table 2. Bits are
numbered from right to left starting at 0. A total of 66 bits are used and are numbered from 0 to 65.
1 2 3 4 5 6
Function description Class Sub- Data field Manufacturer Cyclic
class No. redundancy
check sum
Initiate ED test 01 0000 Length 36 bits. (See 4.2.8) 0000 0000
01 0001 0000 0000
01 0010 0000 0000
01 0011 0000 0000
01 0100 0000 0000
Reserved for future STS 01 0101 Reserved for future STS use 0000 0000
use 01 0110 0000 0000 Length 16 bits
01 0111 0000 0000 Occupies
bits 0 to 15
01 1000 0000 0000 (inclusive)
01 1001 0000 0000 (See 4.2.6)
NOTE Functions allocated t o these sub-classes will not be supported by a generic vending system. Manufacturers will
have to possess the capability to support these functions.
NRS 009-6-7:2002 8
Tokens for ED-specific management transactions shall be encoded as set out in table 3. Bits are
numbered from right to left starting at 0. A total of 66 bits are used and are numbered from 0 to 65.
1 2 3 4 5 6 7
Function description Class Sub- Random Token Transfer Cyclic
class pattern field identifier field amount field redundancy
(see note) (see note) (see note) check sum
See 4.2.16
Set water factor 10 0111
(16 bits)
10 1000 Length 4 bits Length 24 bits Length 16 bits Length
Reserved for future STS Occupies Occupies Occupies 16 bits
10 1001 bits 56 to 59 bits 32 to 55 Occupies
use bits 16 to 31
10 1010 (inclusive) (inclusive) (inclusive) bits 0 to 15
(See 4.2.5) (See 4.2.3) (inclusive)
10 1011 (See 4.2.6)
Reserved for proprietary
use 10 1100
NB: These will not be
supported by the 10 1101
common vending system 10 1110
10 1111
← These 64 bits are encrypted →
NOTE The fields in columns 4, 5 and 6 are conventionally named as shown, assuming credit tokens. The actual use of
each field and its length is determined by the specific transaction type.
9 NRS 009-6-7:2002
The mapping of the token class to a 2-bit binary field is illustrated in table 4.
1 2
Token class Token class binary pattern
Credit transfer token 00
Non-ED-specific management token 01
ED-specific management token 10
Reserved for future STS use 11
The mapping of the token subclass to a 4-bit binary field is illustrated in table 5.
NRS 009-6-7:2002 10
The token identifier field is derived from the date and time of issue and indicates the number of
minutes elapsed from a base date and time. The base date and time is 01 January 1993, 00:00:00.
The calculation of elapsed minutes shall take leap years into account. This field is a 24-bit binary
representation of the elapsed minutes, the leftmost bit being the most significant bit.
Example 1:
Example 2:
The 16 bits of the transfer amount field are subdivided into two sections, a base 10 exponent of 2 bits
and a mantissa of 14 bits. The bits are numbered from right to left, starting at 0. Bit 15 is the most
significant bit of the exponent. Bit 13 is the most significant bit of the mantissa. The bit allocations
within this field are illustrated in figure 1.
Bit 0
Bit 13
Bit 14
Bit 15
11 NRS 009-6-7:2002
t = 10e × m, for e = 0; or
∑ (2 ), for e > 0
e
_
t = (10e × m) + 14
× 10 (n 1)
n =1
where
All transfer amount conversions shall be rounded off in favour of the customer. Table 6 illustrates the
possible transfer amount ranges and the associated maximum errors that can arise owing to rounding
off.
1 2 3
Exponent value Transfer amount range Maximum error
0 0000000 to 00016383 0,000
1 0016384 to 00180214 0,061 %
2 0180224 to 01818524 0,055 %
3 1818624 to 18201624 0,055 %
Example 1:
Example 2:
Example 3:
NRS 009-6-7:2002 12
The generation of this 4-bit pattern will be a snapshot of the four least significant bits of at least a
millisecond counter. The inclusion of a random pattern in the data to be transferred enhances the
security of the token transfer by providing a probability that no two tokens containing identical data to
be transferred will have the same binary pattern.
The CRC check sum field is used to verify the correctness of the data transferred. The check sum is
derived using the following CRC generator polynomial:
X 16 + X 15 + X 2 = 1
The total length of the data transferred via the token is 66 bits. The last 16 bits comprise the CRC
check sum that is derived from the preceding 50 bits. These 50 bits are left padded with 6 binary zeros
to make 56 bits. Before calculation the CRC check sum is initialized to FFFF (hexadecimal). (See
example below.)
Example:
The manufacturer code field is included in the meter number, as specified in NRS 009-4-2. The
requirements of NRS 009-4-2 that are relevant to this section of NRS 009-6 are given in annex A.
Amdt 1; amdt 2
13 NRS 009-6-7:2002
The initiate ED test data field is 36 bits long and is used to indicate the type of test to be performed.
The permissible field values are defined in table 8.
1 2 3
Test Test description Binary pattern
No.
0 Incorporates tests 1 to 5 and any optional tests 1111 1111 1111 1111 1111 1111 1111 1111 1111
implemented in the ED. This test is mandatory
1 Activates supply disconnect mechanism. This test is 0000 0000 0000 0000 0000 0000 0000 0000 0001
mandatory
2 Tests information output devices. This test is mandatory 0000 0000 0000 0000 0000 0000 0000 0000 0010
3 Outputs register totals. This test is mandatory 0000 0000 0000 0000 0000 0000 0000 0000 0100
4 Outputs key revision number. This test is mandatory 0000 0000 0000 0000 0000 0000 0000 0000 1000
5 Outputs tariff index. This test is mandatory 0000 0000 0000 0000 0000 0000 0000 0001 0000
6 Tests token input device. This test is optional 0000 0000 0000 0000 0000 0000 0000 0010 0000
7 Outputs maximum power load. This test is optional 0000 0000 0000 0000 0000 0000 0000 0100 0000
8 Outputs tamper status. This test is optional 0000 0000 0000 0000 0000 0000 0000 1000 0000
9 Outputs power consumption. This test is optional 0000 0000 0000 0000 0000 0000 0001 0000 0000
10 Outputs meter version. This test is optional 0000 0000 0000 0000 0000 0000 0010 0000 0000
11 Outputs phase power unbalance limit. This test is 0000 0000 0000 0000 0000 0000 0100 0000 0000
optional
12 Displays water factor. This test is mandatory in a water 0000 0000 0000 0000 0000 0000 1000 0000 0000
meter
13 Outputs tariff rate. This test is mandatory in a currency 0000 0000 0000 0000 0000 0001 0000 0000 0000
meter
Any optional tests not supported by the ED shall result in the rejection of the optional test token by the
ED. All EDs shall support test number 0; if any of the incorporated tests are not supported the ED must
perform the subset of tests supported.
The proprietary data field is 36 bits long with the left-most bit being the most significant. If this field is
not used it shall be set to zero. This data field will not be supported by a common vending system.
The maximum power load units field is a 16-bit field that indicates the maximum power load, in watts.
Calculation of this field is identical to that of the transfer amount field (see 4.2.4).
NRS 009-6-7:2002 14
The clear credit field indicates the type of credit units being cleared. The permitted values for this field
are specified in table 9.
1 2
Credit type Binary pattern
Electricity 0000 0000 0000 0000
Water 0000 0000 0000 0001
Gas 0000 0000 0000 0010
Connection time 0000 0000 0000 0011
Currency 0000 0000 0000 0100
Reserved for future STS use 0000 0000 0000 0101 - 1111 1111 1111 1110
Clear all credit registers 1111 1111 1111 1111
The set tariff rate field is a 16-bit field that indicates the tariff rate. The format is still to be defined. This
token is intended for future use with currency type units.
The maximum phase power unbalance units field is a 16-bit field that indicates the maximum power
load, in watts. Calculation of this field is identical to that of the transfer amount field (see 4.2.4).
The set 1st section ED key field is 32 bits long and comprises the most significant 4 bytes of the ED
key.
The set 2nd section ED key field is 32 bits long and comprises the least significant 4 bytes of the ED
key.
The set water factor field is 16 bits long (0-65535) and represents the water factor.
The set 1st section ED key random pattern field is a random 4-bit pattern as defined in 4.2.5.
The set 2nd section ED key random pattern field is a random 4-bit pattern as defined in 4.2.5.
15 NRS 009-6-7:2002
The key revision number field is a 1-digit (4-bit) number that refers to the revision of the vending key
used to derive the meter key.
There must be a maximum of two active vending keys in the credit dispensing unit (CDU), namely the
current key and the old key. The current key will be used to encrypt all tokens apart from key change
tokens; the old key will only be used to encrypt key change tokens.
The key change management flags field is a 4-bit field that contains four flags used to denote key
change management functions. A flag is set if the value is “1”, and cleared if the value is “0”.
The flags are defined as set out in tables 10a and 10b.
1 2
Flag Description
1 Roll-over key change
2 Reserved for future use
3 Key type most significant bit
4 Key type least significant bit
1 2 3
Flag 3 Flag 4 Key type
0 0 DITK
0 1 DDTK
1 0 DUTK
1 1 DCTK
NOTE Refer to NRS 009-7 for information on key types.
If the roll-over key change flag is set, the ED shall perform a roll-over key change. This operation is
identical to a normal key change, except that the used token identifier stack in the ED is filled with
identifiers of value 0 (zero).
The tariff index field is a 2-digit (8-bit) number that refers to the tariff index allocated to the customer. In
the event of a newly issued token not being accepted by a customer's ED, this field will enable the
supply authority to determine if the token has the correct tariff index.
NRS 009-6-7:2002 16
Encryption algorithm 3
(see note)
CDU
Dispenser
Dispenser number and Supply group key
tariff index
Encryption algorithm 2
(see NRS 009-7)
Encryption algorithm 1
(see 4.6)
ED
Decryption algorithm 1 ED key
(see 4.7)
Default ED key
Encryption algorithm 2 generation module
(see NRS 009-7)
NOTE Algorithm 3 is a one-way function based on the data encryption algorithm specified in ISO 8731-1, and is for use
only in the security (secure key generation) module.
Figure 2 — Key generation and data encryption processes
17 NRS 009-6-7:2002
All EDs shall be shipped from the manufacturer with a default ED key. An ED may not accept a credit
transfer token encrypted with a default ED key. This implies that EDs shall then be encoded via the set
ED key token before it can accept credit transfer tokens. This can be done at the time of installation.
The default ED key is generated by a default ED key generation module. This is a device that receives
as input the ED's serial number and outputs the default key in ASCII format via an RS232 interface.
NOTE Secure management of the derivation and issuing of vending keys is essential for the security of the data
encrypted with those keys (see annex D of SABS 1524-0, and NRS 009-7).
The time-based token identifier is used to uniquely identify each ED-specific token. The ED shall store,
in the non-volatile memory, at least the last 50 token identifiers received.
Any token identifier received that is already stored shall result in the rejection of the token that contains
this identifier.
If a token identifier is received that has a value less than the smallest token identifier stored (in other
words, that was issued by a CDU before to the earliest token stored in the ED), the ED shall reject the
token containing this identifier.
If a token identifier is received that has a value greater than the smallest token identifier stored (in
other words, that is a valid token) and there is no available space in the non-volatile memory to store
the received token identifier, the ED shall accept this token, remove the smallest token identifier (in
other words, the oldest token) from the non-volatile memory, and replace it with the new token
identifier.
If a key change is accepted by the ED, the used token identifier stack shall remain unchanged, unless
the roll-over control flag specifies that the stack is cleared.
NRS 009-6-7:2002 18
1’s complement
of the meter key
Complemented
meter key rotated
12 bits to the
right
Repeated 16
Substitution
times
process
Permutation
process
Key rotation
process
Figure 3 — Illustration of the key generation and data encryption process for algorithm 1
19 NRS 009-6-7:2002
There is a 4-bit substitution process for each of the 16 nibbles in the data stream. The substitution
table used is one of two 16-value substitution tables and is dependent on the most significant bit
setting of the corresponding nibble in the key. The substitution tables are provided to manufacturers of
the systems under licence conditions. The substitution process is illustrated in figure 4 and an example
of a substitution table is given in table 11.
Bit 63 Bit 0
NRS 009-6-7:2002 20
1 Bit
4.7.1 Description
Decryption algorithm 1 comprises 16 iterations of a permutation, substitution and key rotation process.
(See figure 7.)
Permutation
process
Repeated 16 Substitution
times process
Key rotation
process
Bit 63 Bit 0
21 NRS 009-6-7:2002
There is a 4-bit substitution process for each of the 16 nibbles in the data stream. The substitution
table used is one of two 16-value substitution tables and is dependent on the least significant bit
setting of the corresponding nibble in the key. The substitution tables are provided to manufacturers of
the systems under licence conditions. See the notice prefacing this section of NRS 009-6.
The substitution process is illustrated in figure 9, and an example of a substitution table is given in
table 12.
The entire key is rotated 1 bit to the right, as illustrated in figure 10.
Bit 63 Bit 0
1 Bit
NRS 009-6-7:2002 22
For the purpose of the data encryption example given in 4.8.2 the substitution tables and the
permutation table in table 11 were used.
1 2
Substitution table 1 12, 10, 8, 4, 3, 15, 0, 2, 14, 1, 5, 13, 6, 9, 7, 11
Substitution table 2 6, 9, 7, 4, 3, 10, 12, 14, 2, 13, 1, 15, 0, 11, 8, 5
Permutation table 29, 27, 34, 9, 16, 62, 55, 2, 40, 49, 38, 25, 33, 61, 30, 23,
1, 41, 21, 57, 42, 15, 5, 58, 19, 53, 22, 17, 48, 28, 24, 39,
3, 60, 36, 14, 11, 52, 54, 12, 31, 51, 10, 26, 0, 45, 37, 43,
44, 6, 59, 4, 7, 35, 56, 50, 13, 18, 32, 47, 46, 63, 20, 8
23 NRS 009-6-7:2002
Token class Token Random Token ID Transfer amount CRC check sum
00 subclass pattern 0001 1001 1110 1011 0010 0011 0000 0001 0000 0000 1100 1110 0101 0111
0000 1011 (19 EB 23 hex) (01 00 hex) (C2 07 hex)
NRS 009-6-7:2002 24
For the purpose of the data decryption example given in 4.9.2 the substitution tables and the
permutation table in table 12 were used.
1 2
Substitution table 1 12, 10, 8, 4, 3, 15, 0, 2, 14, 1, 5, 13, 6, 9, 7, 11
Substitution table 2 6, 9, 7, 4, 3, 10, 12, 14, 2, 13, 1, 15, 0, 11, 8, 5
Permutation table 44, 16, 7, 32, 51, 22, 49, 52, 63, 3, 42, 36, 39, 56, 35, 21,
4, 27, 57, 24, 62, 18, 26, 15, 30, 11, 43, 1, 29, 0, 14, 40,
58, 12, 2, 53, 34, 46, 10, 31, 8, 17, 20, 47, 48, 45, 60, 59,
28, 9, 55, 41, 37, 25, 38, 6, 54, 19, 23, 50, 33, 13, 5, 61
Token ID Units
19 EB 23 hex purchased
25,6 kWh
25 NRS 009-6-7:2002
Annex A
(normative)
The meter number shall contain 11 digits composed in accordance with table A.1 and as explained
in 4.2 to 4.4.
1 2
Manufacturer code (see A.3) 2 digits
Meter serial number (see A.4) 8 digits
Meter number check digit (see A.5) 1 digit
TOTAL 11 digits
The manufacturer code is a 2-digit number that shall be used uniquely to identify the manufacturer of
the ED.
The manufacturer codes are allocated and administered by the NRS Project Management Agency
(PMA) on behalf of the Electricity Supply Industry (see note). The current list of manufacturer codes
can be obtained from the NRS Projects Manager, or viewed on the NRS website:
www.nrs.eskom.co.za
The meter serial number is an 8-digit, unique serial number that can be generated internally by the
manufacturer. Each manufacturer is responsible for the uniqueness of the meter serial number with
respect to his manufacturer code.
NRS 009-6-7:2002 26
Annex A
(concluded)
The meter number check digit is a single digit used to ensure that the manufacturer code and meter
serial number are entered correctly whenever they are entered into the equipment by hand. This is a
modulus 10 check digit, calculated using the Luhn formula, as illustrated in annex B of
ISO IEC 7812-1. It is calculated on the 10 digits generated through the concatenation of the
manufacturer code and the meter serial number.
Amdt 2
27 NRS 009-6-7:2002
Bibliography
ISO 8731-1:1987, Banking — Approved algorithms for message authentication — Part 1: DEA.
NRS 009-7:1999, Electricity sales systems — Part 7: Standard transfer specification — The
management of cryptographic keys.
sabs pta