ANSI C12.22 in Context
Grid-Interop Forum 2010
Edward J. Beroset
Elster Solutions, LLC
208 S. Rogers Ln
Raleigh, NC 27610
Grid-Interop Forum 2010
Beroset
Keywords: AMI, security, protocol, C12.22, encryption
Abstract
ANSI C12.22/IEEE 1703 is an application protocol for transferring ANSI C12.19/IEEE 1377 data over networks. This paper describes how the protocol works and where it is used. It contains specific illustrative examples of real protocol traces of C12.22 over TCP/IP and shows how that protocol works with others in an IP context. The security aspects of ANSI C12.22/IEEE 1703 are also be described in some detail. It shows how, by using NIST-approved encryption algorithms and modes, ANSI C12.22/IEEE 1703 provides for both data encryption and data integrity protection for associated unencrypted data such as header information. Finally, it will dispel some of the myths that have circulated about this protocol by showing how the protocol actually works in the context for which it was designed.
1. motivation for ANSI c12.22
The standards committee that created ANSI C12.22 started with known, widely used and very successful standards and adapted them for efficient use over a wide range of communications networks. One of the important design criteria was to provide for adequate security.[4] To explain the solutions considered and the one eventually chosen, it’s useful to understand some of the background of the standard and what existed before.
1.1. Table-based Meter Data
In ANSI C12.19, data transported to and from meters over AMI networks is represented in data structures called tables. [2] These table structures are very similar to the structures used by many programming languages such as C and are therefore very readily understood and implemented.
The essential aspect to the “ANSI Tables” as they are widely known, is that they make efficient use of available resources. Tables are deliberately simple data structures, which makes their construction and parsing quite trivial. This has the dual advantages of being both efficient in terms of microprocessor utiliization in the end device, and also efficient in terms of engineering resources because of this straightforward approach. When transported over AMI networks, the data is in binary form, which is much more efficient than a text-based form such as XML.
It is important to remember that the design deliberately separates the data structures from the communications protocol, so that while there is only one ANSI standard, C12.19, for the data structures, there are currently three standards describing different protocols for communicating these tables.
1.2. ANSI C12.18
ANSI C12.18 was designed to be used for communications via optical probe.[1] In this context, a typical usage would be a utility employee who visits a meter site with a laptop or handheld computer equipped with a serial optical probe. The probe physically attaches to the front of the meter and the utility employee uses software on the computer to interact with the meter via an infrared optical link. The protocol itself is very simple, providing a few basic services, including Read and Write services (for reading and writing tables) and also a Security service which provided for a simple password mechanism to gain access to table data.
1.3. ANSI C12.21
ANSI C12.21 was an extension to ANSI C12.18 to provide for remote access to table data via modem.[3] Read and Write services still existed, but a newer Authenticate service was provided to supplement the simple password service. In the Authentication mechanism, the meter would send a random number (a “nonce”) to the computer. The computer encrypts the nonce and returns it to the meter. The meter replicates this step internally and verifies the returned encrypted nonce. It then re-encrypts the encrypted nonce and returns it to the computer so that at the end of the exchange both ends have verified that they know the secret cryptographic key without having to actually send it over the link.
1.4. Network Requirements
There were four significant differences in network communication versus the earlier protocol contexts that led directly to many of the unique features of C12.22.[4]
First, unlike optical or modem links, a network usually has more than simply two devices attached to it. For this reason, there must be a way of identifying individual nodes.
Second, because the network might be any kind of network, the underlying network protocol and characteristics were deliberately not specified except to say that the underlying network must be reliable in the sense that individual messages are either successfully delivered or an error indication indicates that they were not. Unlike C12.18, which necessarily specified everything down to the physical layer aspects such as physical connection layout, infrared wavelength and optical power, ANSI C12.22 is more purely an application layer specification that does not and cannot specify such underlying network details.
Third, security was improved to allow for both confidentiality of data and integrity of both encrypted and unencrypted data.
Fourth,, at the application layer, modern networks typically have a low (residual) error rate, but a potentially high latency, which are exactly the opposite conditions for a typical optical or modem link (which tend to have high error rates and low latencies). This led to directly to some of the particular features of C12.22 as contrasted with the earlier protocols such as omitting application-layer CRCs that had been present in C12.18 and C12.21, and adding the ability to “batch” replies and requests.
2. ANSI C12.22 over TCP/IP
Because ANSI C12.22 is an application layer protocol, it requires some underlying transport layer to convey its data. Many different possibilities exist for suitable underlying transport protocols, but one commonly used is TCP/IP.
2.1. TCP Review
TCP is Transmission Control Protocol and is by far the most widely used transporta layer protocol on the internet today. It is a connection-oriented protocol that provides a reliable, pipelined, bidirectional point-to-point byte stream with flow control. A TCP connection begins by means of a three-way handshake and ends (in the normal case) with another multi-step handshaking sequence. From the view of an application layer, these handshaking details are typically invisible and the effect is that of a long pipe in which every byte sent into one end of the pipe is eventually received at the other end of the pipe. The TCP protocol prevents duplicate or out-of-order data. It also provides flow-control so that a distant end’s receive buffer is not overrun by a fast transmitter, and congestion management, in which, ideally, the network itself is not overrun by multiple devices sending too much data.
2.2. ANSI C12.22 over TCP/IP
Implementing ANSI C12.22 over TCP/IP is a fairly simple process. On a computer, for example, Application Payload Data Units (APDUs) can be constructed in memory and then sent to the underlying TCP implementation. A“socket” interface is very commonly used to simplify the programmer’s job of using TCP, and so one logical way to construct a C12.22 over TCP/IP implementation would be to use socket calls as the replaceable “bottom” of the application, and C12.22 services as the “top” end of the application. Layering the architecture of an implementation in this way, makes the resulting software easier to understand, to debug, to maintain, and to use and has long been considered a “best current practice” in industry.
2.3. Example C12.22 Request
Below is a detailed example of a C12.22 message to a meter. It is shown in its semantic form. That is, what is printed below is what the data elements actually mean, rather than their actual representation “on the wire.”
C12.22 messages are described using Abstract Syntax Notation 1, (ASN.1)[5] which is a notation that allows for the concise description computer-parseable messages. The C1222-MESSAGE consists of various pieces of header information, followed by the user-information which contains the actual series of requests. In this particular case, encryption was used and so the header contains a calling-authentication-value element which, in turn, contains a key-id-element and an iv-element. The key-id-element identifies which key is being used (key 0 in this example) and the iv-element is a nonce to assure that the protocol is resistant to play-back attack.
C1222-MESSAGE
called-AP-title: 1.3.6.1.4.1.33507.1919.12345678.1 (iso.3.6.1.4.1.33507.1919.12345678.1)
calling-AP-title: 1.3.6.1.4.33507 (iso.3.6.1.4.33507)
calling-AP-invocation-id: 734534305
calling-authentication-value
calling-authentication-value-encoding: calling-authentication-value-single-asn1 (0)
calling-authentication-value-single-asn1: calling-authentication-value-c1222 (1)
calling-authentication-value-c1222
key-id-element: 00
iv-element: 4b97d2cc
user-information
C12.22 EPSEM Flags: 0x88
1...... = C12.22 Reserved Flag: True
.0...... = C12.22 Recovery Flag: False
..0. .... = C12.22 Proxy Service Used Flag: False
...0 .... = C12.22 ED Class Flag: False
.... 10.. = C12.22 Security Mode Flags: Ciphertext with authentication (0x02)
...... 00 = C12.22 Response Control Flags: Always respond (0x00)
[crypto result]
[Crypto good: True]
[Crypto bad: False]
C12.22 EPSEM: Security (password "00000000000000000000", id 0)
C12.22 Command: Security (0x51)
C12.22 Security Password: 00000000000000000000
C12.22 Logon User-Id: 0
C12.22 EPSEM: Full Read (ST-1)
C12.22 Command: Full Read (0x30)
C12.22 Table: 0x0001
C12.22 EPSEM: Full Read (ST-120)
C12.22 Command: Full Read (0x30)
C12.22 Table: 0x0078
C12.22 EPSEM: Full Read (ST-121)
C12.22 Command: Full Read (0x30)
C12.22 Table: 0x0079
C12.22 EPSEM: Full Read (ST-122)
C12.22 Command: Full Read (0x30)
C12.22 Table: 0x007a
C12.22 EPSEM: Full Read (ST-123)
C12.22 Command: Full Read (0x30)
C12.22 Table: 0x007b
C12.22 EPSEM: Full Read (ST-125)
C12.22 Command: Full Read (0x30)
C12.22 Table: 0x007d
C12.22 EPSEM MAC: e6f89b6d
The payload part of the message, which would all be encrypted before transmission, contains a Security request and five Full Table Read requests.
3. ANSI C12.22 Security
As already noted, security was an essential criterion for the design on ANSI C12.22. Some of the constraints and requirements led to specific choices and so it is useful to understand what those constraints and requirements were and how the challenge was met. First, the protocol must run on the class of low-cost, low-power microprocessors that are available in full industrial temperature range (-40 to +85C) devices today. Because deployments are typically specified to operate continuously in the field for a decade or more, it is desireable to be able to implement in field-upgradeable firmware rather than fixed hardware. Finally, limited power consumption is an important consideration for devices, both individually (for temperature control) and in aggregate over an entire deployed system (due to the cost of the power to run the devices).
Both full encryption of the payload data and validity checking of the entire packet (including the unencrypted header data) was needed to assure both confidentiality and integrity of C12.22 messages. Generically, cryptographic modes which provide both these features are called Authenticated Encryption with Associated Data (AEAD) modes. The committee considered a number of options, including CCM and GCM but decided instead to use an optimization of EAX dubbed EAX’. All three (CCM, GCM and EAX’) are AEAD modes, but EAX’ is alone among the three in having both an on-line capability (in which the length of the message is not required before beginning calculations) and having good performance without requiring either hardware assistance or large RAM-based memory tables.
On-line capability means that cryptographic processing of a message may begin even before the entire message is complete, which is a very useful feature in small microprocessors. Not requiring specialized cryptographic hardware allows for more flexible future field changes as noted before. Not using large RAM-based memory tables is important for two reasons. First, RAM is a precious commodity is most small microprocessors, so using many kilobytes just for an encryption table is typically a poor use of resources. Second, cryptographic tables which are based on the key (as with GCM) are cryptographically sensitive material and therefore must be afforded the same kinds of cybersecurity protections that would be give to the key itself. This is difficult to do with a large memory array on a general purpose microprocessor.
A more complete description of the exact security mechanism is available online.[6]
4. Common myths
For some reason, there are a number of common myths about C12.22 which have been voiced enough times that it is worth enumerating them and describing why they’re incorrect.
4.1. “incompatible with TCP”
This is sometimes expressed as “C12.22 can’t work with IPv6” but the myths are similar. In fact, as has already been described above it is a very straightforward implementation task to use C12.22 over TCP and the since the same underlying socket library is used with either IPv4 or IPv6, there is, in fact, very little additional effort in creating a single implementation that is capable of using TCP over either IPv4 or IPv6. In point of fact, the author has already done so.
4.2. “violates layering”
This myth may come up for several reasons. The first is that the standard, in addition to describing the application layer specification also talks about one particular instance in which the meter and communications modules are two physically separate devices (that is, not both under the glass of the meter housing.) For that specific case only, lower layers are described so that one could theoretically buy a module and a meter from two different vendors and have them “plug and play.” No such implementations are known to the author. This is likely due to the additional costs and inconvenience for such a device pairing, and so while there may be some merit to this objection, it is a moot point in reality. The second reason this may come up is due to some unfortunate features of the standard which, again, are moot in reality because no one has implemented them. These features are segmentation and reassembly at the application layer and the use of ApTitle for addressing. In this author’s opinion these are both misfeatures and should not be implemented. In the case of segmentation and reassembly, this is indeed best left to the underlying layers, and in all implementations known to the author, this is how it’s done. In the case of addressing via ApTitle, there has been a great deal of confusion on the topic. An ApTitle is properly used as an identifier of a particular application, while the addresssing and routing are concerns of the lower layers. The only intersection of these two is an association of an ApTitle with, say, an IPv6 address, just in the way that in a phone book, individual’s names are associated with their telephone numbers. In both cases, the particulars of how the underlying works to connect communicating entities is properly left completely outside the realm of the application.