0% found this document useful (0 votes)
66 views33 pages

NRS009 6 7

Uploaded by

peetcoetzer5041
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
66 views33 pages

NRS009 6 7

Uploaded by

peetcoetzer5041
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Collection of SANS standards in electronic format (PDF)

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.

I agree with the above


This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

ICS 29.240.99; 35.240.60; 91.140.50 NRS 009-6-7:2002


Edition 2.2
ISBN 0-626-14119-2 Edition 2: Incorporating
Amendment No. 2:2002

Rationalized User Specification

ELECTRICITY SALES SYSTEMS

Part 6: Interface standards

Section 7: Standard transfer


specification/Credit dispensing unit —
Electricity dispenser — Token encoding
and data encryption and decryption

Requirements for applications in the Electricity Supply


Industry

N R S

Gr 10

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

This Rationalized User Specification is


issued by the NRS Project
on behalf of the
User Group given in the foreword
and is not a standard as contemplated in the Standards Act, 1993 (Act 29 of 1993).

Rationalized user specifications allow user


organizations to define the performance and quality
requirements of relevant equipment.

Rationalized user specifications may, after a certain


application period, be introduced as national standards.

Amendments issued since publication


Amdt No. Date Text affected
1 May 2001 Subclause 4.2.7:
a) removed the table of manufacturer codes,
b) added reference of website for table of
manufacturer codes,
c) added contact details of NRS Projects Manager
for list of manufacturer codes,
d) added reference of specification for meter
number.

2 May 2002 Notice: Information added on STS compliance.


Foreword.
Clause 2: Normative references updated.
Clause 3: Note added to clarify abbreviation “ED”.
Subclause 4.2.7 and 4.4. Reference to NRS 009-4-2
changed to reference annex A.
Annex A added.

Amendment 2 was compiled to aid understanding of the specification internationally, in


preparation for its submission to the IEC, for consideration as an IEC PAS. This consolidated
edition 2.2 is technically identical to, and replaces, the consolidated edition of
NRS 009-6-7:2001, which is published by the SABS under ISBN 0-626-13498-6, for which the
SABS holds publishing copyright.

Correspondence to be directed to Printed copies obtainable from

South African Bureau of Standards South African Bureau of Standards


(Electrotechnical Standards) Private Bag X191
Private Bag X191 Pretoria 0001
Pretoria 0001
Telephone: (012) 428-7911
Fax: (012) 344-1568
E-mail: [email protected]
Website: http://www.sabs.co.za

COPYRIGHT RESERVED

Printed on behalf of the NRS Project in the Republic of South Africa


by the South African Bureau of Standards
1 Dr Lategan Road, Groenkloof, Pretoria
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

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]

Fax number +27(21) 914 3930

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.

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

This page intentionally left blank


This standard may only be used and printed by approved subscription and freemailing clients of the SABS.
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

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

A Format of meter numbers used for STS compliant meters ................................................ 25

Bibliography ...................................................................................................................... 27

®Standard Transfer Specification


This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

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:

Part 0: Standard transfer specification — Synopsis. (Under consideration.)

Part 1: Glossary and system overview. (Withdrawn, superseded by SABS 1524-0.)

Part 2: Functional and performance requirements.


Section 1: System master stations.
Section 2: Credit dispensing units.
Section 3: Security modules.
Section 4: Standard token translators.
Section 5: Error handling.

Part 3: Database format.

Part 4: National electricity meter cards and associated numbering standards.


Section 1: National electricity meter cards.
Section 2: National electricity meter numbers.

Part 5: Testing of subsystems.

Part 6: Interface standards.


Section 1: Credit dispensing unit — Standard token translator interface.
Section 2: System master station — Main frame. (S uspended; see annex A of NRS 009-2-1. )
Section 3: System master station — Credit dispensing unit. (Previously NRS 009-3).
Section 4: Data transfer by physical media — System master station — Credit dispensing
unit.
Section 5: Not allocated.
Section 6: Standard transfer specification — Credit dispensing unit — Electricity dispenser —
Categories of token and transaction data fields.
Section 7: Standard transfer specification — Credit dispensing unit — Electricity dispenser —
Token encoding and data encryption and decryption.
Section 8: Standard transfer specification — Disposable magnetic token technology —
Token encoding format and physical token definition.
Section 9: Standard transfer specification — Numeric token technology — Token encoding
format and physical token definition.

Part 7: Standard transfer specification — The management of cryptographic keys.

ISBN 0-626-14119-2

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

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:

S J van den Berg (Chairman) Mangaung Municipality


P A Johnson (Project leader) NRS Project Management Agency
V Bissett City of Cape Town
R Devparsad eThekwini Electricity
J O’Kennedy Eskom Distribution
V E Rengecas SABS
M Singh eThekwini Electricity
D W van Reenen City Power Johannesburg
J Westenraad City of Tshwane

A Manufacturers’ Interest Group (MIG) was consulted on the amendment of this section of NRS 009.
The MIG comprised the following members:

R Hill Circuit Breaker Industries


S Leigh Prism
R Lewis Tellumat SA
F Pucci Schneider (t/a Conlog)
A Stoner Energy Measurements Limited
D Taylor Actaris Measurements

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:

R Wienand(Chairman) eThekwini Metropolitan Council, AMEU


M N Bailey Distribution Technology, Eskom
A J Claasen Electrical Engineering Standards, SABS
P Crowdy Distribution Technology, Eskom
B de Jager Mangaung Electricity, AMEU
W Dykman City of Tshwane, AMEU
A H L Fortmann AMEU
P A Johnson Technology Standardization, Eskom
J Machinjike Transmission, Eskom
D M Michie Nelson Mandela Metropolitan Municipality, AMEU
S V Moodley City Power Johannesburg (Pty) Ltd
R van der Riet City of Cape Town, AMEU
J S van Heerden SABS NETFA
D J van Wyk uMhlathuze Electricity, AMEU

Recommendations for corrections, additions or deletions should be addressed to the NRS Project
Manager, c/o SABS, Private Bag X191, Pretoria, 0001.

Annex A forms an integral part of this specification.

®Standard Transfer Specification


This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

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:

a) NRS 009-6-6, equivalent to STS Part 1;

b) NRS 009-6-7, equivalent to STS Parts 2 and 2c;

c) NRS 009-6-8, equivalent to STS Part 3a;

d) NRS 009-6-9, equivalent to STS Part 3b; and

e) NRS 009-7, equivalent to STS Part 2b.

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.

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

5 NRS 009-6-7:2002

SPECIFICATION

Electricity sales systems

Part 6: Interface standards

Section 7: Standard transfer specification/Credit dispensing unit —


Electricity dispenser — Token encoding and data encryption and
decryption

Requirements for applications in the Electricity Supply Industry

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

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

NRS 009-6-7:2002 6

3 Terms, definitions and abbreviated terms


For the purposes of this section of NRS 009-6, the definitions and abbreviations given in SABS 1524-0
apply.

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

4.1 Bit allocation tables

4.1.1 Credit transfer function bit allocation (Class 00)

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.

Table 1 — Bit allocation for credit transfer functions

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 →

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

7 NRS 009-6-7:2002

4.1.2 Non-ED-specific management function bit allocation table (Class 01)

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.

Table 2 — Bit allocation for non-ED-specific management functions

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)

01 1010 0000 0000


01 1011
Length 8 bits
01 1100 Length 36 bits
Reserved for proprietary Occupies bits
Occupies bits 24 to 59
use (see note) 01 1101 16 to 23
(inclusive)
(inclusive)
01 1110 (See 4.2.9)
(See 4.2.7)
01 1111

← These 64 bits are NOT encrypted →

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.

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

NRS 009-6-7:2002 8

4.1.3 ED-specific management function bit allocation (Class 10)

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.

Table 3 — Bit allocation to ED-specific management functions

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

Set maximum power See 4.2.10


10 0000
load (16 bits)
See 4.2.5 See 4.2.3 See 4.2.11
Clear credit 10 0001
(4 bits) (24 bits) (16 bits)
See 4.2.12
Set tariff rate 10 0010
(16 bits)
See 4.2.17 4.2.19 4.2.20 See 4.2.14
Set 1st section ED key 10 0011
(4 bits) (4 bits) (4 bits) (32 bits)
See 4.2.18 See 4.2.21 See 4.2.15
Set 2nd section ED key 10 0100
(4 bits) (8 bits) (32 bits)

Clear tamper condition 10 0101 0000 0000 0000


0000

Set maximum phase See 4.2.13


10 0110
power unbalance limit (16 bits)

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.

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

9 NRS 009-6-7:2002

4.2 Field calculations


4.2.1 Token class

The mapping of the token class to a 2-bit binary field is illustrated in table 4.

Table 4 — Allocation of binary patterns to token classes

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

4.2.2 Token subclass

The mapping of the token subclass to a 4-bit binary field is illustrated in table 5.

Table 5 — Allocation of binary patterns to token subclasses


1 2 3 4 5
Token sub- Class
class binary
pattern 00 01 10 11
0000 Electricity token Initiate ED test Set maximum power load
0001 Water token Clear credit
0010 Gas token Set tariff rate
0011 Connection time token Set 1st section ED key
0100 Currency token Set 2nd section ED key
0101 Clear tamper condition

0110 Reserved for future Set maximum phase power


STS use unbalance limit
0111 Set water factor Reserved for
future STS use
1000
1001 Reserved for future Reserved for future STS use
1010 STS use
1011
1100
1101 Reserved for
proprietary use Reserved for proprietary use
1110
1111

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

NRS 009-6-7:2002 10

4.2.3 Token identifier

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:

Date of issue: 25 March 1993


Time of issue: 13:55:22
Elapsed minutes: 120 355
Resultant 24-bit token ID: 0000 0001 1101 0110 0010 0011

Example 2:

Date of issue: 25 March 1996


Time of issue: 13:55:22
Elapsed minutes: 1 698 595
Resultant 24-bit token ID: 0001 1001 1110 1011 0010 0011

4.2.4 Transfer amount

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

Base 10 exponent Mantissa

Figure 1 — Allocation of bits in the transfer amount field

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

11 NRS 009-6-7:2002

The equation for transfer amount conversion is as follows:

t = 10e × m, for e = 0; or

∑ (2 ), for e > 0
e
_
t = (10e × m) + 14
× 10 (n 1)

n =1

where

t is the transfer amount,


e is the exponent,
m is the mantissa, and
n is an integer in the range 1 to e inclusive.

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.

Table 6 — Maximum errors associated with transfer amount ranges

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 %

Examples for credit transfer functions (Class 00)

Example 1:

Units purchased: 26,5 kWh


Resultant 16-bit transfer amount field: 0000 0001 0000 0000

Example 2:

Units purchased: 1 638,4 kWh


Resultant 16-bit transfer amount field: 0100 0000 0000 0000

Example 3:

Units purchased: 181 870,4 kWh


Resultant 16-bit transfer amount field: 1100 0001 0000 0001

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

NRS 009-6-7:2002 12

4.2.5 Random pattern

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.

4.2.6 Cyclic redundancy check (CRC) check sum

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:

Original 50 bits (in hexadecimal) 0 00 4A 2D 90 0F F2


Left padded to make 7 bytes 00 00 4A 2D 90 0F F2
Check sum calculated 0F FA

4.2.7 Manufacturer code

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

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

13 NRS 009-6-7:2002

4.2.8 Initiate ED test data field

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.

Table 8 — Allocation of binary patterns to ED tests

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.

4.2.9 Proprietary data field

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.

4.2.10 Maximum power load units field

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).

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

NRS 009-6-7:2002 14

4.2.11 Clear credit field

The clear credit field indicates the type of credit units being cleared. The permitted values for this field
are specified in table 9.

Table 9 — Allocation of binary patterns to credit types

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

4.2.12 Set tariff rate field

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.

4.2.13 Maximum phase power unbalance units field

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).

4.2.14 Set 1st section ED key field

The set 1st section ED key field is 32 bits long and comprises the most significant 4 bytes of the ED
key.

4.2.15 Set 2nd section ED key field

The set 2nd section ED key field is 32 bits long and comprises the least significant 4 bytes of the ED
key.

4.2.16 Set water factor

The set water factor field is 16 bits long (0-65535) and represents the water factor.

4.2.17 Set 1st section ED key random pattern field

The set 1st section ED key random pattern field is a random 4-bit pattern as defined in 4.2.5.

4.2.18 Set 2nd section ED key random pattern field

The set 2nd section ED key random pattern field is a random 4-bit pattern as defined in 4.2.5.

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

15 NRS 009-6-7:2002

4.2.19 Key revision number

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.

4.2.20 Key change management flags

4.2.20.1 Field definitions

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”.

Flag 1 Flag 2 Flag 3 Flag 4

The flags are defined as set out in tables 10a and 10b.

Table 10a — Key change management flags

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

Table 10b — Key types

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.

4.2.20.2 Roll-over key change flag

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).

4.2.21 Tariff index

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.

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

NRS 009-6-7:2002 16

4.3 STS security


4.3.1 Overview
Figure 2 illustrates the key generation and data encryption processes.
Security
Supply group code and Supply authority key module
revision number

Encryption algorithm 3
(see note)

CDU
Dispenser
Dispenser number and Supply group key
tariff index

Encryption algorithm 2
(see NRS 009-7)

Token data (64 bits) ED key


(66 bits less 2-bit class value)

Encryption algorithm 1
(see 4.6)

Encryption token data

ED
Decryption algorithm 1 ED key
(see 4.7)

Token data (64 bits


(66 bits less 2-bit class value)

Default ED key
Encryption algorithm 2 generation module
(see NRS 009-7)

ED serial number and Default supply group key


default tariff index

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

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

17 NRS 009-6-7:2002

4.3.2 Default ED key

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.

4.4 Default ED key generation module

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.

The ED's serial number shall be as defined in annex A.


Amdt 2

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).

4.5 Preventing ED-specific token reuse

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.

®Standard Transfer Specification


This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

NRS 009-6-7:2002 18

4.6 Encryption algorithm 1


4.6.1 Description

Encryption algorithm 1 comprises a key alignment process and 16 iterations of a substitution,


permutation and key rotation process (see figure 3).

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

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

19 NRS 009-6-7:2002

4.6.2 Substitution process

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.

Set nibble counter


i=0

Repeat for each


data nibble
Increment i
(16 times)

Is bit 3 of (i)th nibble of


the key equal to 1?
No Yes

Perform 4-bit Perform 4-bit


substitution process substitution process
using substitution using substitution
table 1 (see table 11) table 2 (see table 11)

Figure 4 — The substitution process used for encryption


4.6.3 Permutation process
The permutation process is based on a 64-value permutation table and is illustrated in figure 5.

Bit 63 Bit 0

Figure 5 — Illustration of the permutation process used for encryption


The permutation tables are provided to manufacturers of the systems under licence conditions. See
the notice prefacing this section of NRS 009-6. (An example of a permutation table is given in
table 11.)

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

NRS 009-6-7:2002 20

4.6.4 Key rotation process

The entire key is rotated 1 bit left, as illustrated in figure 6.


Bit 63 Bit 0

1 Bit

Figure 6 — Illustration of the key rotation process used in encryption


4.7 Decryption algorithm 1

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

Figure 7 — Illustration of the decryption process for algorithm 1

4.7.2 Permutation process


The permutation process is based on a 64-value permutation table and is illustrated in figure 8.

Bit 63 Bit 0

Figure 8 — Illustration of the permutation process used for decryption


The permutation tables are provided to manufacturers of the systems under licence conditions. See
the notice prefacing this section of NRS 009-6. (An example of a permutation table used for decryption
is given in table 11.)

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

21 NRS 009-6-7:2002

4.7.3 Substitution process

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.

Set nibble counter


i=0

Repeat for each


data nibble Increment i
(16 times)

Is bit 0 of the (i)th nibble


of the key equal to 1?
No Yes

Perform 4-bit Perform 4-bit


substitution process substitution process
using substitution using substitution
table 1 (see table 12) table 2 (see table 12)

Figure 9 — Illustration of the substitution process used for decryption

4.7.4 Key rotation process

The entire key is rotated 1 bit to the right, as illustrated in figure 10.

Bit 63 Bit 0

1 Bit

Figure 10 — Illustration of the key rotation process used for decryption

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

NRS 009-6-7:2002 22

4.8 Data encryption example


4.8.1 Sample tables

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.

Table 11 — Examples of substitution tables and a permutation table


used for encryption

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

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

23 NRS 009-6-7:2002

4.8.2 Worked example of data encryption

An example of data encryption performed in the CDU is shown in figure 11.

Electricity Date of issue Time of issue Units


token 25 Mar 1996 13:55:22 purchased
25,6 kWh

Token class Token Token ID Transfer amount


00 subclass 0001 1001 1110 1011 0010 0011 0000 0001 0000 0000
00 (19 EB 23 hex) (01 00 hex)

Token class Token Random Token ID Transfer amount


00 subclass pattern 0001 1001 1110 1011 0010 0011 0000 0001 0000 0000
0000 1011 (19 EB 23 hex) (01 00 hex)

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)

Given meter key


(0A BC 12 DE F3 45 67 89 hex)

Complemented meter key


(F5 43 Ed 21 0C BA 98 76 hex)

64 bits of token data to be Complemented meter key


encrypted rotated 12 bits right
(0B 19 EB 23 01 00 C2 07 hex) (87 6F 54 3E D2 10 CB A9 hex)

Token Encrypted 64 bits of token data


class (C4 5E D1 61 94 06 DF 95 hex)
00

66 bits to be placed on token


00 1100 0100 0101 1110 1101 0001 0110 0001 1001 0100 0000 0110 1101 1111 1001 0101

Figure 11 — Example of the encryption process

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

NRS 009-6-7:2002 24

4.9 Data decryption example


4.9.1 Sample tables

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.

Table 12 — Examples of substitution tables and a permutation table


used for decryption

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

4.9.2 Worked example of data decryption

An example of data decryption performed in the ED is shown in figure 12.

66 bits to be placed on token


00 1100 0100 0101 1110 1101 0001 0110 0001 1001 0100 0000 0110 1101 1111 1001 0101

Token Encrypted 64 bits of token data Given meter key


class (C4 5E D1 61 94 06 DF 95 hex) (0A BC 12 DE F3 45 67 89 hex)
00

Decrypted 64 bits of token data


(0B 19 EB 23 01 00 C2 07 hex)

Token Token Token ID Transfer amount CRC check sum


class subclass Random 0001 1001 1110 1011 0010 0011 0000 0001 0000 0000 1100 1110 0101 0111
00 0000 pattern 1011 (19 EB 23 hex) (01 00 hex) (C2 07 hex)

Token ID Units
19 EB 23 hex purchased
25,6 kWh

Figure 12 — Example of the decryption process

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

25 NRS 009-6-7:2002

Annex A
(normative)

Format of meter numbers used for STS compliant meters


NOTE The requirements of this annex are equivalent to requirements extracted from NRS 009-4-2, which is published in
South Africa by the SABS.

A.1 Allocation of a meter number

A unique meter number shall be allocated to each STS compliant ED.

A.2 Meter number

The meter number shall contain 11 digits composed in accordance with table A.1 and as explained
in 4.2 to 4.4.

Table A.1 — Meter number format

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

A.3 Manufacturer code

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

NOTE Contact details for the NRS Projects Manager are:


Telephone +27 11 800 3786
Fax +27 11 800 2070
Postal Address:
Technology Standardization
Resources and Strategy Group
PO Box 1091
Johannesburg 2000
South Africa

A.4 Meter serial number

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.

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

NRS 009-6-7:2002 26

Annex A
(concluded)

A.5 Meter number check digit

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

Standard Transfer Specification


®
This standard may only be used and printed by approved subscription and freemailing clients of the SABS.

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

Standard Transfer Specification


®

You might also like