1、g3g3g3IEEE Trial-Use Standard for a Cryptographic Protocol for Cyber Security of Substation Serial Links g3Sponsored by the Substations Committee g3IEEE 3 Park Avenue New York, NY 10016-5997 USA 15 February 2011 IEEE Power +1 978 750 8400. Permission to photocopy portions of any individual standard
2、for educational classroom use can also be obtained through the Copyright Clearance Center. iv Copyright 2011 IEEE. All rights reserved. Introduction This introduction is not part of IEEE Std 1711-2010, IEEE Trial-Use Standard for a Cryptographic Protocol for Cyber Security of Substation Serial Links
3、. This trial use standard defines a cryptographic protocol called Serial SCADA Protection Protocol (SSPP) to provide integrity, and optionally confidentiality, for cyber security of substation serial links. It focuses exclusively on “formatting bits on the wire” to provide cryptographic assurance of
4、 cyber security properties. It does not address specific applications or hardware implementations and is largely independent of the underlying communications channel and application or SCADA protocol. The requirements of this standard are in addition to any requirements contained in standards for in
5、dividual devices in which this protocol is implemented. SSPP operates by encapsulating each SCADA or application message in a cryptographic envelope that adds minimal overhead to the message. This encapsulation is performed in a manner that is largely independent of the underlying communications pro
6、tocol. While SSPP was originally designed to protect serial SCADA communications, its domain of application is not limited to SCADA. SSPP can also be used to protect other types of serial communications, such as data concentrator links, load management links, dial-in revenue meter reading, dial-in m
7、aintenance connections, etc. SSPP is designed for systems or applications in the following circumstances: Traffic is message-oriented, with messages consisting of contiguous sequences of 7-bit or 8-bit characters, in lengths ranging from a few characters to a few hundred characters. The communicatio
8、ns channel may be either half-duplex or full-duplex. Messages are never reordered by the communications channel. Messages are never fragmented by the communications channel. The communications topology is point-to-point, point-to-multipoint, or broadcast. For point-to-multipoint topologies, messages
9、 include an identifying address of the receiver in the header of the message. Transmission speeds may be slow enough that cryptographic protocol overhead in the form of too many additional header, trailer, or framing characters may significantly impact message latency and roundtrip message delivery
10、times. Message integrity is critical to reliable system operation, and system operation may be adversely impacted if messages are modified, forged, spliced, reordered, or replayed. The system or application is able to tolerate lost messages. SSPP assures message integrity by detecting modified, forg
11、ed, spliced, reordered, or replayed messages and discarding them. Applications such as SCADA systems are designed to accommodate accidental communications errors and, through timeouts, detects and retries lost or damaged messages. Such applications thereby recover from messages discarded by SSPP in
12、the same way as they recover from messages lost or damaged by communications errors. Applications such as dial-in remote maintenance involve a live operator who can reissue commands whose action or response is discarded by SSPP. SSPP is designed to support point-to-point links, point-to-multi-point
13、(or multi-drop) links, and broadcast links. For multi-drop links and broadcast links, SSPP supports mixed-mode operation, where some of the stations use SSPP to achieve protected communications, and other stations communicate in the clear. Mixed-mode operation allows for phased or incremental deploy
14、ment of devices providing SSPP protection so that all stations on a multi-drop or broadcast link do not have to be upgraded simultaneously. SSPP protection can be deployed at the master station first, then incrementally added to slave stations as needed. v Copyright 2011 IEEE. All rights reserved. S
15、SPP may be implemented in standalone security devices, integrated in communications modems, or embedded in applications or systems. When implemented in standalone bump-in-the-wire security devices, SSPP may be used to retrofit protection of legacy serial systems with little or no modification of exi
16、sting systems and equipment. Figure a illustrates a typical deployment of SSPP implemented with a multi-channel Ethernet-to-Serial SSPP gateway in the control center and SSPP bump-in-the-wire (BITW) devices in the substations. Figure aRetrofit bump-in-the-wire SSPP deployment Key management for the
17、long-term cryptographic keys used by SSPP is specifically not addressed in this standard. Key management is a complex issue, and including key management would significantly increase the size and complexity of the standard. But more significantly, key management for SSPP keys is not markedly differe
18、nt from key management for other cryptographic systems. Including a specific mechanism for key management in SSPP could preclude integration with existing commercial key management systems and inhibit adoption of SSPP in products. It is expected that key management systems for SSPP keys follow good
19、security practices, and the quality, flexibility, and usability of such systems should be evaluated by prospective purchasers of SSPP implementations. Goals This standard has several goals. Designing cryptographic algorithms and protocols that operate correctly and are free of undiscovered flaws is
20、difficult at best. There is general agreement in the cryptography community that openly published and time-tested cryptographic algorithms and protocols are less likely to contain security flaws than secretly developed ones because their publication enables scrutiny by the entire community. Historic
21、ally, proprietary and secret protocols have frequently been found to contain flaws when their designs become public. However, well-known and time-tested protocols such as TLS and SSH that are designed for high-speed IP networks add too much overhead when used on slow serial communications links. The
22、re are no suitable cryptographic protocols for protecting the integrity of asynchronous serial communications of a SCADA-like nature. By defining such a protocol that can be used with a wide variety of systems and vi Copyright 2011 IEEE. All rights reserved. application protocols, this standard aims
23、 to help manufacturers build secure systems, products, and applications, and avoid the pitfalls of proprietary and secret cryptographic designs. By utilizing a common framework, different implementations of this protocol built by different vendors may be able to interoperate. Adherence to this stand
24、ard is by no means a guarantee of interoperability, but this standard does provide a significant step toward interoperable implementations. Interoperability can foster competition and lead to more and better choices for end users. Interoperability can also simplify merging diverse operational infras
25、tructures, such as can occur when two utilities merge. Finally, interoperability can provide opportunities for alternative support or migration from one vendors equipment to another. Systems operators may use this specification in procurement requirements to gain some assurance that products are wel
26、l-designed and secure. Without a specification of this nature, most utilities do not have the expertise to evaluate cryptographic designs. Security and control systems manufacturers will build products only if they perceive a viable market. This standard has the potential to create a market for seri
27、al communications protection products. Notice to users Laws and regulations Users of these documents should consult all applicable laws and regulations. Compliance with the provisions of this standard does not imply compliance to any applicable regulatory requirements. Implementers of the standard a
28、re responsible for observing or referring to the applicable regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not in compliance with applicable laws, and these documents may not be construed as doing so. Copyrights This document is copyrighted
29、 by the IEEE. It is made available for a wide variety of both public and private uses. These include both use, by reference, in laws and regulations, and use in private self-regulation, standardization, and the promotion of engineering practices and methods. By making this document available for use
30、 and adoption by public authorities and private users, the IEEE does not waive any rights in copyright to this document. Updating of IEEE documents Users of IEEE standards should be aware that these documents may be superseded at any time by the issuance of new editions or may be amended from time t
31、o time through the issuance of amendments, corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the document together with any amendments, corrigenda, or errata then in effect. In order to determine whether a given document is the current edition a
32、nd whether it has been amended through the issuance of amendments, corrigenda, or errata, visit the IEEE Standards Association web site at http:/ieeexplore.ieee.org/xpl/standards.jsp, or contact the IEEE at the address listed previously. For more information about the IEEE Standards Association or t
33、he IEEE standards development process, visit the IEEE-SA web site at http:/standards.ieee.org. vii Copyright 2011 IEEE. All rights reserved. Errata Errata, if any, for this and all other standards can be accessed at the following URL: http:/standards.ieee.org/reading/ieee/updates/errata/index.html.
34、Users are encouraged to check this URL for errata periodically. Interpretations Current interpretations can be accessed at the following URL: http:/standards.ieee.org/reading/ieee/interp/ index.html. Patents Attention is called to the possibility that implementation of this trial-use standard may re
35、quire use of subject matter covered by patent rights. By publication of this trial-use standard, no position is taken with respect to the existence or validity of any patent rights in connection therewith. The IEEE is not responsible for identifying Essential Patent Claims for which a license may be
36、 required, for conducting inquiries into the legal validity or scope of Patents Claims or determining whether any licensing terms or conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing agreements are reasonable or non-discriminatory. Users of this
37、trial-use standard are expressly advised that determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely their own responsibility. Further information may be obtained from the IEEE Standards Association. Trial use Publication of this trial-use standa
38、rd for comment and criticism has been approved by the Institute of Electrical and Electronics Engineers. Trial-use standards are effective for 24 months from the date of publication. Comments for revision will be accepted for 18 months after publication. Suggestions for revision should be directed t
39、o the Secretary, IEEE-SA Standards Board, 445 Hoes Lane, Piscataway, NJ 08854, and should be received no later than 15 August 2012. It is expected that following the 24-month period, this trial-use standard, revised as necessary, shall be submitted to the IEEE-SA Standards Board for approval as a fu
40、ll-use standard. viii Copyright 2011 IEEE. All rights reserved. Participants At the time this trial-use standard was submitted to the IEEE-SA Standards Board for approval, the Cryptographic Protocol for Cyber Security of Substation Serial Links Working Group had the following membership: David White
41、head, Chair Andrew Wright, Vice Chair Mason Clark Mike Dood Dennis Holstein Marc Lacroix Craig Preuss Sam Sciacca Lee Smith John Tengdin Tim TibbalsThe following members of the individual balloting committee voted on this trial-use standard. Balloters may have voted for approval, disapproval, or abs
42、tention. William J. Ackerman Terrence Burns Arvind K. Chaudhary Stephen Conrad Ratan Das Gary Donner Michael Dood Randall Dotson Neal Dowling Sourav Dutta Gary Engmann Kenneth Fodero Frank Gerleve Grant Gilchrist Ron Greenthaler Randall Groves Adolfo Gutierrez David Harris John Hawkins Gary Heuston
43、Dennis Holstein C. Huntley R. Jackson Piotr Karocki Yuri Khersonsky J. Koepfinger Jim Kulchisky Marc Lacroix Chung-Yiu Lam John McDonald Jerry Murphy R. Murphy Bruce Muschlitz Michael S. Newman Nick S. A. Nikjoo Satoshi Obara Chris Osterloh Craig Preuss Jose Puthenkulam Michael Roberts Charles Roger
44、s Anne-Marie Sahazizian Miriam Sanders Steven Sano Bartien Sayogo Samuel Sciacca Hamidreza Sharifnia Devki Sharma Gil Shultz Mark Simon James Smith Gary Stoedter Walter Struppler Michael Swearingen William Taylor John Tengdin David Tepen Joe Uchiyama Eric Udren John Vergis Ilia Voloh David Whitehead
45、 Andrew Wright ix Copyright 2011 IEEE. All rights reserved. When the IEEE-SA Standards Board approved this trial-use standard on 9 November 2010, it had the following membership: Robert M. Grow, Chair Richard H. Hulett, Vice Chair Steve M. Mills, Past Chair Judith Gorman, Secretary Karen Bartleson V
46、ictor Berman Ted Burse Clint Chaplin Andy Drozd Alexander Gelman Jim Hughes Young Kyun Kim Joseph L. Koepfinger* John Kulick David J. Law Hung Ling Oleg Logvinov Ted Olsen Ronald C. Petersen Thomas Prevost Jon Walter Rosdahl Sam Sciacca Mike Seavey Curtis Siller Don Wright *Member Emeritus Also incl
47、uded are the following nonvoting IEEE-SA Standards Board liaisons: Satish Aggarwal, NRC Representative Richard DeBlasio, DOE Representative Michael Janezic, NIST Representative Julie Alessi IEEE Standards Program Manager, Document Development Soo H. Kim IEEE Standards Program Manager, Technical Prog
48、ram Development x Copyright 2011 IEEE. All rights reserved. Contents 1. Overview 1 1.1 Scope . 1 1.2 Purpose 1 2. Normative references 2 3. Definitions, acronyms, and abbreviations 2 3.1 Definitions . 2 3.2 Acronyms and abbreviations . 3 4. Substation Serial Protection Protocol (SSPP) . 4 4.1 Protoc
49、ol overview 4 4.2 SSPP organizational layers 6 4.3 Octet order in SSPP messages . 6 4.4 Session layer 6 4.5 Transport layer . 17 4.6 Link layer . 18 4.7 Cipher suites 23 4.8 SSPP management messages . 28 Annex A (informative) Background . 30 A.1 Overview 30 Annex B (informative) Implementation considerations . 31 B.1 Link layer mixed-mode operation . 31 B.2 Hardware handshaking 31 B.3 Dialup modem interaction . 33 B.4 Timing consideration for shared connections . 34 B.5 Design consideration for cipher suites 35 B.6 Side channel design considerations .
