**************************************************************** AGA 12 Part 2-akw Proposed SCADA Encryption Protocol **************************************************************** Andrew Wright, Cisco Sytems akwright@acm.org 05/16/2006 corresponding to ScadaSafe Version 0.7.4 This document describes a proposed Serial SCADA Protection Protocol (SSPP) for AGA 12 Part 2. This description matches the ScadaSafe reference implementation as of the above date. See scadasafe.sourceforge.net for more information. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1. Introduction **************** This document describes the Serial SCADA Protection Protocol (SSPP) for cryptographically protecting existing serial-based SCADA communications. A device that speaks SSPP is known as a SCADA Cryptographic Module (SCM). In its simplest form, a SCM has two serial ports. A SCADA message received from a SCADA master or remote on a SCM's plaintext port will be protected and sent out the SCM's ciphertext port as an SSPP message. An SSPP message received on a SCM's ciphertext port will be verified, decrypted, and sent out the SCM's plaintext port. SCMs are deployed between SCADA devices and the modems for the communications links. The key property these devices must assure is data integrity: that commands and responses are not forged or altered during transmission. 1.1 Environment Assumptions *************************** SSPP may be implemented by separate hardware units (SCMs) or embedded in SCADA master and/or field equipment. This document does not specifically address embedded situations. Two or more SCMs communicate over a shared serial channel, such as RS 232, RS 485, or serial radio. Each SCM has a 16-bit address established in configuration data that is unique over all SCMs on the channel. A "master SCM" located at the SCADA master shares a long-term encryption key and a long-term HMAC key with each "field SCM" located at a SCADA field device. The keys are different for each field device. The SCADA field devices never communicate directly with each other, and thus do not need to share keys. These long-term keys are used principally for session establishment and are known as static session keys. Multiple data and management sessions to a SCM are possible enabling in-band remote management simultaneously with SCADA traffic. Mixed mode deployments are possible where some field devices are not protected by SCMs, and thus unencrypted SCADA commands and responses must be carried on the channel for those devices. Messages are never reordered by the channel. Messages are never fragmented by the channel. Channel collisions are not directly detectable. 1.2 Design Principles ********************* SSPP is primarily designed to assure the integrity of SCADA messages: that messages are not forged, modified, spliced, reordered, or replayed. With an appropriate cipher suite SSPP can also provide confidentiality, although this property is considered a secondary goal of the design. The protocol provides no defense against Denial Of Service (DOS) attacks, as without a secondary channel, there is little that can be done to prevent an adversary from blocking the channel. However, SSPP has been designed to avoid making DOS attacks any easier to launch. That is, if the adversary ceases jamming the channel, the protocol will resume normal communications reasonably promptly. SSPP is an encapsulation protocol that has been designed to apply to the majority of the hundreds of serial SCADA protocols currently in use. Thus SSPP makes minimal assumptions about the SCADA protocol or the behavior of the SCADA system. To successfully use SSPP with a given SCADA protocol, the implementation need only be able to detect the beginning and end of a SCADA message, locate the device (RTU) address in the message, and distinguish broadcast messages. SSPP mostly sends traffic on the channel only when the SCADA system sends traffic, and thereby minimizes the introduction of additional collisions. SSPP is designed to add minimal additional overhead to messages, and minimal additional latency to the delivery of a SCADA message. The protocol allows implementations to avoid introducing jitter, which is important for timing-sensitive SCADA protocols like Modbus. No messages are ever retried by a SCM. A damaged message will (using holdback cipher suites) be dropped by the SCM. A dropped data (DTA) message is treated as if it were not received, e.g., due to line noise, so that a new data message is sent when the SCADA system retries (or sends a new message). If a session establishment message (OPN, ACK, or BEG) is dropped, then the session will not be established. A new attempt to establish a session will be attempted when the SCADA system sends another SCADA message. The reason that messages are not retried is that SCADA systems must already deal with messages lost or damaged due to line noise. Some may retry, some may move to the next device in the polling cycle, some may send NACKs, etc. Retrying a SCM message might result in delivery of a belated SCADA response when the master is not expecting it. Retrying SCM messages might also cause collisions on the line. Leaving retry up to the SCADA system avoids these issues. In general, SCMs should attempt as much as possible to transmit only when the SCADA system transmits. This minimizes potential channel collisions, and is particularly important on dialup systems that require a telephone number to be dialed and connected in order to send a message. SCADA data is transferred over dynamically established sessions that are generally bidirectional. For such dynamic sessions, a sequence number is used to prevent replay, and is used as an input to the cipher suite in encrypting or decrypting the message. In this way, one or more messages can be dropped without preventing decryption of later messages. If an appropriate clock resolution is determined during session negotiation, the sequence number may represent the transmission time of the message relative to the start of the session, and the receiver may additionally check that the message is received at approximately the correct time. This prevents an adversary from delaying messages in transit. For static sessions that are used for key exchange, however, a sequence number is undesirable, as it is preferrable to minimize the amount of shared state that must be available between two CMs. Otherwise synchronization problems might arise that could prevent establishment of a session. Thus the OPN, ACK and BEG messages that are exchanged over static sessions carry copies of the earlier message's sequence numbers to prevent replay. 1.3 Concepts ************ SCM Configuration: Every SCM has various configuration parameters that include its SCM address, communication parameters, SCADA protocol(s), SCADA address to SCM address mapping, and static sessions. SCM Address: a SCM address is a 16 bit number that is specified in the SCM configuration. Every SCM on a shared communications link MUST be configured with a unique SCM address. The address 0xffff is a special broadcast address. A SCM MUST NOT be assigned the broadcast address. The address 0x0000 is not a valid SCM address and MUST NOT be used. Session: a session is a (usually) bidirectional virtual communications channel established between a specific pair of SCMs. There MAY be more than one session established between the same pair of SCMs. A session has a type indicating whether it carries SCADA data, SCADA broadcast data, management data, or management broadcast data. Only one type of traffic may be carried on a particular session. A session also has a kind indicating whether it is static or dynamic. Static sessions are configured in SCM configuration data and are used principally for key exchange to establish dynamic sessions. Dynamic sessions are negotiated between a pair of SCMs and carry SCADA and management traffic. Session Id: a session id is an 8 bit number used to distinguish different types of bidirectional traffic flows between a pair of SCMs. A session id together with the two SCM addresses identifies a session; that is, session ids are interpreted with respect to the two SCM addresses. Since sessions are bidirectional, the tuple where ID is a session id and A and B are SCM addresses identifies the same session as the tuple . The session id 0x00 is not valid. Sequence Number: a sequence number is an unsigned number carried in the header of all messages. Sequence numbers are used to prevent replay. Cipher Suite: a cipher suite is a set of cryptographic algorithms, keys, and parameters identified by a cipher suite number. Each SCM maintains a table mapping every static session and every open dynamic session to a cipher suite. PE-mode: Position Embedding (PE) mode is a cryptographic mode designed by members of the AGA 12 committee specifically for low latency integrity protection. It is used by one of the cipher suites. See [1] for the rationale behind the design of this mode. Note that PE mode as used here includes an additional output whitening step over [1]. Mixed Mode: mixed mode operation allows the SCM deployed at the SCADA master to pass unencrypted communications between the SCADA master and specific RTUs that do not have SCMs. SCM configuration information MUST indicate explicitly for which RTUs cleartext traffic should be sent and received. SCM configuration should also include a second, separate, configurable switch to enable/disable mixed mode operation altogether. 1.4 Protocol Layers ******************* This description of the SSPP protocol is organized into 3 layers called the Session Layer, the Transport Layer, and the Link Layer. The session layer distinuishes different kinds of messages, and is responsible for session key negotiation and abstract data exchange. The transport layer is responsible for encryption and integrity checking of messages and guarding against replay. The link layer is responsible for formatting messages onto and from the channel in such a way as to delimit certain parts of messages and to ensure that unencrypted SCADA traffic is distinguished from encrypted traffic. An implementation of the protocol need not be organized in this way, provided it is functionally equivalent. Each layer is responsible for different aspects of the formatting of a message. The session layer formats a message into a sequence of octets (using network octet order for numbers, ie. most significant octet first). To the transport layer, this sequence of octets is the payload. The transport layer encrypts the payload and wraps the payload with a header and trailer. The link layer formats the transport layer's header, payload, and trailer onto the wire by adding another header, trailer, and delimiters between each section. Pictorially, we have: Session: m Transport: Header E[ m ] Trailer Link: ESC SOM X[Header E[ m ]] ESC SOT X[Trailer] ESC EOM where E[...] represents encryption, and X[...] represents escaping (doubling of any occurrence of ESC; see Link Layer below). ESC, SOM, SOT, and EOM are link layer delimiters indicating Escape, Start Of Message, Start Of Trailer, and End Of Message. (They do not necessarily correspond to the ASCII characters of the same names.) 2. The Session Layer ********************* The session layer defines message formats and procedures for transfer of data on static or dynamic sessions and for setup and teardown of dynamic sessions. There are several types of session layer messages: OPN = 1 ACK = 2 DTA = 3 CLS = 4 ERR = 5 BEG = 6 DTA carries data. Depending on the session type, this may be SCADA data or management data. OPN, ACK, and BEG are exchanged to negotiate session keys for a dynamic session. A session permits data transfer between two and only two SCMs. CLS is sent to terminate a session. ERR is issued when a SCM receives a DTA with an invalid session id. A SCM MUST be configured with one or more static sessions for each peer SCM it will communicate with. The configuration of at least one of the two SCMs MUST specify a cipher suite to use to encrypt and decrypt messages sent on that session. The configuration MUST also specify the session type, which may be one of: ESTABLISHMENT = 0 DATA = 1 MANAGEMENT = 2 BROADCAST = 3 MANAGEMENT_BROADCAST = 4 ESTABLISHMENT indicates that the session is primarily used to establish dynamic sessions between SCMs. Only static sessions may be of type ESTABLISHMENT. DTA and CLS messages MUST NOT be sent on ESTABLISHMENT sessions. DATA indicates that DTA messages sent on the session contain SCADA data. MANAGEMENT indicates that DTA messages sent on the session contain management data. BROADCAST indicates that DTA messages sent on the session contain SCADA broadcast data. MANAGEMENT_BROADCAST indicates that DTA messages sent on the session contain management data and are broadcast messages. OPN, ACK, and BEG messages MUST ONLY be sent on sessions of type ESTABLISHMENT. A static session can be used to negotiate dynamic sessions or exchange management data. Depending on the cipher suite, such messages may enjoy integrity protection and/or secrecy. However, static sessions provide no protection against replay or reordering. Use of static sessions for management data transfer SHOULD be limited to situations where replay or reordering is not a risk, such as with certificate exchange. A static session can also be used to negotiate a dynamic session. Typically a SCM may establish a session in response to receipt of SCADA data on its cleartext port that is destined to a remote SCM for which the sending SCM has no open session. Sessions are normally kept open for a long time, to amortize the cost of session setup over many messages. A SCM may also establish a session for other reasons, such as in response to an operator command. Dynamic sessions may only be used for (SCADA or management) data exchange. A dynamic session MUST NOT be used to establish another dynamic session. ESTABLISHMENT, DATA and MANAGEMENT sessions are bidirectional. Either SCM may send messages using the session id. BROADCAST sessions are unidirectional. Only the publisher of a broadcast may send data on the broadcast session. 2.1 Session Negotiation *********************** A SCM sends an OPN to initiate a session with a second SCM. The second SCM MUST respond with an ACK. The first SCM MUST then send a BEG. The first SCM MUST start a timer on sending the OPN, and cancel it upon receipt of the ACK. If the timer expires, the first SCM MUST discard the session. The second SCM must start a timer on sending the ACK, and cancel it upon receipt of the BEG. If the timer expires, the second SCM MUST discard the session. While a SCM is waiting for an ACK or BEG, it MAY discard or buffer any messages received from the SCADA system. If the OPN message is damaged and does not reach the remote SCM, the first SCM's timer will expire, and no resources will be reserved for the session. Likewise, if the ACK message is damaged and does not return, both SCM's timers will expire, and no resources will be reserved for the session. If the BEG message is damaged and does not reach the second SCM, the SCM's timer will expire, and no resources will be reserved by that SCM for the session. The first SCM will retain an open session, if the second SCM sends an OPN for the same session id, this will replace the session. If the first SCM sends data on the partly open session, the second SCM will respond with a ERR message, and the first SCM will then discard this bogus session. The sequence numbers in OPN, ACK, and BEG messages are 112 bits long. They may be generated randomly or via a persistent incremental counter. If a secure pseudorandom generator is used, it MUST be seeded with some information unique to the SCM, such as its address, and with at least 112 bits of true random information. The seed SHOULD be persistent over power loss. If a persistent incremental counter is used, its value MUST be persistent for the lifetime of the device. The sequence numbers of the OPN and ACK messages are used to guard against replay of a session negotiation. They are also used by the various cipher suites to ensure uniqueness of encrypted blocks. The ACK message carries a copy of the sequence number of the matching OPN message. The BEG message carries copies of both the matching OPN and ACK messages sequence numbers. An OPN message may contain zero or more session requests. An OPN MUST NOT contain any broadcast session requests. The ACK corresponding to an OPN MUST include session requests for at least all the sessions from the OPN. These session requests may fill in unspecified values of the session requests from the OPN, as explained below. The ACK MAY include session requests for additional sessions. These MAY include broadcast session requests for which the sender of the ACK is the publisher. The BEG corresponding to an ACK MUST include session requests for at least all the sessions from the ACK, except for broadcast session requests, which MUST NOT be repeated. These session requests may fill in unspecified values of the session requests from the ACK, as explained below. The BEG MAY include session requests for additional sessions. These MAY include broadcast session requests for which the sender of the BEG is the publisher. Session requests in a BEG MUST NOT include unspecified values, as explained below. If the resolution field of a session request is zero, the resolution, tolerance, sequence number length, base, and expiry fields of that request are considered unspecified. The receiver of an OPN or ACK message containing such a session request is free to choose values for those fields as appropriate and supply them in the following ACK or BEG message. The following rules apply to the selection of these values by either SCM. The resolution field of a session request MUST be greater than or equal to the resolution field of the earlier session request. The tolerance field of a session request MUST be zero if the tolerance field of the earlier OPN session request was zero and the resolution field was non-zero. Tolerance of zero indicates that the SCM either does not support or does not wish to use session clocks. Otherwise, the tolerance field of the session request MUST be greater or equal to the tolerance field of the earlier session request. The sequence number length field must be large enough to represent the maximum possible sequence number that could be generated before the session expires. The base field of the session request must be greater or equal to that of the earlier session request. If the expiry field of a session request is zero, then the session never expires, and the expiry field of the following session request MUST be zero. Otherwise, the expiry field of the following session request MUST be non-zero and chosen such that the expiry multiplied by the resolution is less or equal to the earlier session request's expiry multiplied by its resolution. That is, the actual time that the expiry field represents in a session request MUST NOT be longer than that of the earlier session request. The values of resolution, tolerance, sequence number length, base, and expiry contained in session requests in the BEG message are the agreed-on values for both SCMs to use. 2.2 Session Clocks ****************** Dynamic sessions have a session clock if a non-zero tolerance was present in the session request of the BEG message that opened the session. In this case, sequence numbers for the session represent time since the beginning of the session in ticks. The duration of a tick is determined during session negotiation, and MUST be short enough that no more than one message can be sent during a tick. The receiver of a message MUST check that the sequence number of a received message is both newer than the last received sequence number and within a tolerance, measured in ticks, of the current session time. The receiver SHOULD measure the current session time for this check upon receipt of the beginning of the message header, or as close to that as practical. The tolerance provides a window, twice the width of the tolerance, during which receipt of the message is allowed. This tolerance is also determined during session negotiation, MUST not be less than the ACK/BEG timeout used during session negotiation, and MUST be wide enough to accommodate clock drift up to the expiry of the session. Most sessions SHOULD begin at time 0; that is, a message sent immediately at the beginning of the session would have sequence number 0. However, the initial time for the session MAY start at any value. This is particularly useful for broadcast sessions where the master SCM may have created the broadcast session when first negotiating with SCM A, and later must ensure when negotiating with SCM B that both SCM A and SCM B have the same view of time for that session. A SCM sending an BEG message MAY determine the beginning of session time as the time when it initiates sending of the BEG message, completes sending of the BEG message, or any time between those two events. A reasonable choice is half way between those two events. A SCM receiving a BEG message MAY determine the beginning of session time as the time when it begins receiving the BEG message, completes receiving the BEG message, or any time between those two events. A reasonable choice is half way between those two events. For sessions with a non-zero agreed-on value of expiry, both SCMs MUST consider the session closed when (expiry - base) clock ticks have elapsed. Either or both SCMs MAY send CLS messages when the session expires. Neither is required to. In selecting values for the resolution, tolerance, sequence number length, base, and expiry fields of a session request, a SCM SHOULD take into account both the OPN/ACK timeout value for session negotiation and potential clock drift. As a general rule, tolerance SHOULD satisfy the following relation: tolerance >= AckTimeout + expiry * 2 * ClockAccuracy where AckTimeout is the OPN or ACK timeout value and ClockAccuracy is the worst-case clock drift of the SCM's clock expressed as a fraction (eg. parts-per-million). Twice the clock drift is used to allow for one clock drifting fast and the other drifting slow. The above negotiation rules ensure that two SCMs with different accuracy clocks will agree to use the worst-case tolerance. Care should be taken to ensure consistent units are used in evaluting this formula. As an example, with an AckTimeout of 1 second, expiry of 1 day, and clock accuracy of 50 ppm, tolerance should be at least 10 seconds. If too small a tolerance is used, the two SCM's clocks could drift enough that after some time sequence numbers will consistently fall outside the valid window and all subsequent messages will be dropped until the session expires. 2.3 Message Formats ******************* This section details the formats that the various types of messages MUST follow. 2.3.1 OPN Message ***************** An OPN message consists of: numberSessions - 1 octet 0 or more session requests The numberSessions octet indicates the number of session requests to follow in the message. A session request consists of: sessionType - 1 octet sessionId - 1 octet resolution - 4 octets tolerance - 2 octets seqLength - 1 octet base - 4 octets expiry - 4 octets cipherSuite - length depends on the suite The sessionType field indicates the session type in the lower 4 bits, which can be one of the following values: DATA = 1 MANAGEMENT = 2 BROADCAST = 3 MANAGEMENT_BROADCAST = 4 DATA is used for regular SCADA data transfer; MANAGEMENT is for in-band vendor-defined management functions; BROADCAST is used for SCADA data broadcasts; and MANAGEMENT_BROADCAST is used for in-band vendor-defined broadcast management functions. The sessionId field is the dynamic session id to use. The sessionId field MUST NOT be zero. Resolution is the number of microseconds per session clock tick. If resolution is zero in a session request in an OPN message, the resolution, tolerance, seqLength, base, and expiry fields are considered unspecified, and the SCM receiving the message must choose appropriate values. Resolution MUST NOT be zero in a session request in a BEG message. Tolerance is the maximum number of ticks that a sequence number may differ from the current session time. If zero, the tolerance check for received sequence numbers MUST NOT be performed for messages received on this session. SeqLength is the length of sequence numbers in the header of messages for the session, in octets. If non-zero, SeqLength MUST be between 2 and 14. Base is the starting value for the session clock in ticks. The session is deemed to begin this many clock ticks before the session negotiation. Base must be less than expiry. Expiry is the time from the beginning of the session (adjusted by base) until the session expires, in clock ticks, or in other words, the maximum value for the clock. If expiry is zero, the session never times out. If expiry is zero, tolerance MUST be zero. If tolerance is not zero, expiry MUST NOT be zero. The contents of the cipherSuite field depends on the particular cipher suite. The first octet of the cipherSuite always indicates the type of cipher suite. If zero, the SCM receiving the OPN message must choose the cipher suite. The cipherSuite field MUST NOT be zero in a session request in an ACK message. OPN, ACK, and BEG messages MAY contain more than one session request to permit multiple sessions to be established in one negotiation. For example, a DATA session, a BROADCAST session, and a MANAGEMENT session could be established simultaneously. OPN, ACK, and BEG messages MUST be sent on a static session. The HMAC in the trailer MUST not be truncated. Before processing the session requests in an OPN, a SCM MUST perform the following checks. If SCM A receives an OPN from a SCM B while SCM A has an outstanding (unacknowledged) OPN to SCM B and SCM A's address is less than that of SCM B, SCM A MUST ignore the OPN. If SCM A receives an OPN from a SCM B while SCM A has an outstanding OPN to SCM B and A's address is greater than that of SCM B, SCM A MUST mark closed any sessions related to its outstanding OPN, cancel any related timers, and respond to the incoming OPN. These rules ensure that two SCMs that simultaneously issue OPNs to each other (on a full duplex channel) to establish a SCADA data session will establish only a single bidirectional data session. A SCM MUST mark closed, without issuing a CLS message, any sessions whose session ids appear in session requests in the OPN. This allows reopening of a session with different expiry or other parameters. 2.3.2 ACK Message ***************** An ACK message consists of: seqOpn - 14 octets numberSessions - 1 octet 0 or more session requests The seqOpn field contains the sequence number from the OPN message, and is used by the originator of the OPN to match the ACK against an in-progress session negotiation. When issuing an OPN, a SCM MUST start a timer that is used to cancel the operation if no response is received, and mark this timer with the sequence number from the OPN. A SCM MUST ignore any ACK message received for which it does not have an unexpired timer with matching sequence number. The numberSessions octet indicates the number of session requests to follow in the message. A session is established for each such session request. An ACK message MUST include a session request for each session included in the corresponding OPN message. An ACK message MAY include additional session requests. Session requests are formatted as in the OPN message, except for the following rules. If expiry is zero, resolution and base MUST also be zero. If either expiry or tolerance is non-zero, resolution MUST NOT be zero. The OPN/ACK/BEG mechanism allows a SCM to initiate a session and either generate the keys itself by placing them in a session request with non-zero cipher suite in the OPN, or request its peer generate them, by using a zero cipher suite. If a zero cipher suite is used, the peer MUST either generate keys and place them in an appropriate session request in the ACK, or ignore the OPN. An ACK message MUST be sent on a static session. The HMAC in the trailer MUST not be truncated. 2.3.3 BEG Message ***************** A BEG message consists of: seqOpn - 14 octets seqAck - 14 octets numberSessions - 1 octet 0 or more session requests The seqOpn field contains the sequence number from the OPN message. The seqAck field contains the sequence number from the ACK message. A SCM MUST ignore any BEG message received for which it does not have an unexpired timer with matching sequence numbers. The numberSessions octet indicates the number of session requests to follow in the message. A session is established for each such session request. A BEG message MUST include a session request for each session included in the corresponding ACK message. A BEG message MAY include additional session requests. Session requests are formatted as in the OPN message, except for the following rules. If expiry is zero, resolution and base MUST also be zero. If either expiry or tolerance is non-zero, resolution MUST NOT be zero. The OPN/ACK/BEG mechanism allows a SCM to initiate a session and either generate the keys itself by placing them in a session request with non-zero cipher suite in the OPN, or request its peer generate them, by using a zero cipher suite. If a zero cipher suite is used, the peer MUST either generate keys and place them in an appropriate session request in the ACK, or ignore the OPN. A BEG message MUST be sent on a static session. The HMAC in the trailer MUST not be truncated. 2.3.4 DTA Message **************** A DTA message consists of: data - remainder of message A DTA message may consist of either SCADA data or management data. A DTA message MAY be sent on either a static or dynamic session. A DTA message containing SCADA data SHOULD be sent on a dynamic session. 2.3.5 CLS Message ***************** A CLS message consists of: message - remainder of message The message field is an optional error message. A SCM receiving a CLS message with a valid trailer MUST treat the session as closed and MUST NOT transmit nor receive any further data on the session until it is reopened. A CLS message with an invalid trailer MUST be silently ignored, regardless of what cipher suite it is encrypted under. A CLS message MUST be sent on a dynamic session. 2.3.6 ERR Message ***************** An ERR message consists of: destAddress - 2 octets srcAddress - 2 octets sessionId - 1 octet trailerLength - 1 octet trailer - trailerLength octets message - remainder of message The destAddress, srcAddress, and sessionId fields reflect the corresponding fields from the transport header of the message that the ERR is issued against. The trailer field contains the trailer of a recently transmitted DTA message for that session. The remainder of the message is an optional error message. Any non-ERR message with a non-broadcast destAddress received on a non-open session is an "errant" message. An ERR message SHOULD be returned in response to receipt of any such errant message. Since the session is not open, the SCM receiving the errant message cannot decrypt it nor verify its checksum, and thus cannot distinguish a valid message from one whose session id was damaged by line noise or an attacker. The SCM responds with ERR indicating the session id and including the trailer of the errant message. A SCM receiving an ERR message MUST check that the trailer contained in the message is one that was recently sent. If not, the ERR MUST be ignored. However, if the trailer is recent, the SCM MUST mark the session indicated in the ERR message closed. In order to determine if the trailer contained in an ERR message was recently sent, SCMs MUST record the trailers of at least the last three messages transmitted. Rationale: it is possible due to line noise during session establishment or termination for one SCM to think a particular session id corresponds to an open session, while the other thinks that session id is closed. Since the protocol does not send acks or nacks for DTA messages, ERR ensures that a SCM will not continuously send DTA messages on a session that the receiver thinks is closed. Returning the trailer of the errant message in the ERR message prevents an adversary from replaying an ERR message and thereby performing a trivial denial-of-service attack. An ERR message must be sent on a static session. 2.4 Session Layer State Diagrams ******************************** The following event table illustrates the actions that take place for static sessions. An implementation MUST behave equivalently to this state machine. The event "rcv bad" indicates receiving a message on a static session whose checksum verification fails or is otherwise incorrectly formatted or cannot be decrypted. Event | Action ==================== send OPN | 3 send DTA | 1 rcv OPN | 3 rcv ACK | 3 rcv DTA | 2 rcv CLS | 1 rcv ERR | 3 rcv bad | 1 Actions: 1: do nothing 2: process payload 3: make appropriate transition in dynamic session state machine for session request Note that static sessions cannot be closed, thus a CLS received on a static session is ignored. The following state diagram illustrates the behavior of a state machine for one dynamic session D. Similar states machines track the behavior of each dynamic session. An implementation MUST behave equivalently to this state machine. The event "send OPN" indicates sending an OPN message on some static session S and indicating D in the payload. The event "send CLS" indicates sending a CLS message on session D. The event "send DTA" indicates sending a DTA message on session D. The event "rcv OPN" indicates receiving an OPN message on some static session S that contains a session request for session id D. The event "rcv ACK" indicates receiving an ACK message on some static session S and indicating D in the payload. The event "rcv CLS" indicates receiving a CLS message on session D. The event "rcv DTA" indicates receiving a DTA message on session D. The event "rcv ERR" indicates receiving an ERR message on some static session S and indicating D in the payload. The event "rcv bad" indicates receiving a message on dynamic session D whose checksum verification fails or is otherwise incorrectly formatted or cannot be decrypted. Current State Event | closed | wait_ACK | wait_BEG | open ==================================================================== send OPN | wait_ACK, 3 | X | X | wait_ACK, 3 send DTA | X | X | X | open, 1 send CLS | X | X | X | closed, 1 rcv OPN | wait_BEG, 5 | wait_BEG, 4 | wait_BEG, 8 | wait_BEG, 11 rcv ACK | closed, 1 | open, 6 | wait_BEG, 1 | open, 1 rcv BEG | closed, 1 | wait_ACK, 1 | open, 9 | open, 1 rcv DTA | closed, 7 | wait_ACK, 1 | wait_BEG, 1 | open, 2 rcv CLS | closed, 1 | wait_ACK, 1 | wait_BEG, 1 | closed, 1 rcv ERR | closed, 1 | closed, 10 | closed, 9 | closed, 1 rcv bad | closed, 1 | wait_ACK, 1 | wait_BEG, 1 | open, 1 ACK timeout | X | closed, 1 | X | X BEG timeout | X | X | closed, 1 | X X = cannot occur Actions: 1: do nothing 2: process payload 3: start ACK timer 4: cancel ACK timer, send ACK, start BEG timer 5: send ACK, start BEG timer 6: cancel ACK timer, send BEG 7: send ERR 8: cancel BEG timer, send ACK, start BEG timer 9: cancel BEG timer 10: cancel ACK timer 11: send ACK, start BEG timer 2.5 Broadcast Sessions ********************** Broadcast sessions are, in essence, a special type of data session to be used for SCADA broadcast data. A BROADCAST session is typically opened between a pair of SCMs at the same time as a DATA session is opened. However, the session is interpreted with respect to the publisher's SCM address and the broadcast SCM address (0xffff), where the publisher is defined to be whichever SCM placed the broadcast session request in the ACK or BEG. That is, if the broadcast suite is placed in the OPN, then the SCM sending the OPN is the publisher. A typical manner in which a SCM MAY operate is to dynamically generate cryptographic keys for broadcast as it issues the first OPN for a dynamic session. These same keys can then be issued to other SCMs in subsequent OPN messages. In this manner, all SCMs having an open dynamic data session to the publisher will also have an open broadcast session using a common set of keys. Periodically the publisher may close all sessions including the broadcast sessions and generate new broadcast keys. A broadcast session is unidirectional. That is, the broadcast address 0xffff MUST NOT be used as the source address of a message. 3. The Transport Layer ********************** The purpose of the transport layer is to wrap and protect a session layer message so as to preserve its integrity and confidentiality against an adversary. The transport layer ensures that an adversary cannot forge or alter messages, read messages, reorder messages, or replay old messages. A tranport layer message consists of a header, a variable length payload, and a fixed length trailer. The transport layer relies on the link layer to identify the boundaries between the header and payload and the payload and trailer. At the sender, the transport layer encrypts the message received from the session layer to form the payload. The transport layer generates a header and a trailer, and the three sections are passed to the link layer. The specific method of encryption depends on the cipher suite associated with the session the message is transmitted on. At the receiver, the transport layer receives the header, payload, and trailer from the link layer. The transport layer checks the validity of the header, possibly including a sequence number, prior to processing the payload. The transport layer decrypts the payload, and may forward decrypted data to the session layer as soon as it is available, or may withhold all data until after processing the trailer, depending on the cipher suite. Finally, the transport layer computes a cipher-suite-dependent checksum of the message and compares it to the checksum in the trailer. If the checksum does not match, the SCM MUST discard the message. A transport layer message MUST be formatted as follows: header: type - 1 octet destAddress - 2 octets srcAddress - 2 octets sessionId - 1 octet sequence - variable octets payload (encrypted): payload - variable size message (see session layer) padding - depends on cipher suite trailer: checksum - depends on cipher suite If any of the transport layer fields of a received message are found to be invalid, the message MUST be silently discarded. The SCM MAY make a log entry. 3.1 Transport Layer Header ************************** The type field of the header contains a protocol version number (currently 1) in the upper 3 bits, an alert bit in the next bit (0x10), and the message type in the lower four bits. The message type must be one of the following values: OPN = 1 ACK = 2 DTA = 3 CLS = 4 ERR = 5 BEG = 6 The alert bit may be set in any DTA or CLS message to indicate that the sending SCM has encountered some sort of alarm condition such as keys expired, tampering detected, etc. The alert bit MUST NOT be set in any other type of message. The conditions on which an alert bit is set or cleared are implementation defined. The destAddress and srcAddress are the SCM addresses of the destination and source SCMs. A SCM MUST ignore any messages not containing its own address or the broadcast address 0xffff in the destAddress field. A SCM MUST set the srcAddress field to its own address in all messages it sends. The sessionId specifies which session the payload is encrypted under. The transport layer header is not encrypted. 3.2 Transport Layer Payload *************************** The transport layer payload contains a session layer message whose type is indicated in the transport layer header. The transport layer payload is encrypted in a manner dependent on the session's cipher suite. 3.3 Transport Layer Trailer *************************** The transport layer trailer is a checksum of the octets constituting the transport layer header and the unencrypted transport layer payload and padding. The type of checksum and its length depends on the cipher suite. The transport layer trailer is not encrypted. 3.4 Sequence Numbers ******************** For dynamic sessions, the sequence field of the header represents a message sequence number or clock value. A SCM MUST ensure that each message sent on a dynamic session uses a greater sequence number than the last one sent. If no session clock is used, this sequence number can increase sequentially. If a session clock is in use, the sequence number represents the number of clock ticks since the session began. A SCM MUST also ensure that a received message has a greater sequence number than the last one received on the same session, except for CLS messages. If a session clock is in use, the SCM MUST also ensure that the sequence number is within a tolerance of the current session time, except for CLS messages. 4. The Link Layer ***************** The link layer is concerned with the formatting of SSPP messages as individual characters on the serial communications link. Its function is to identify the beginning and end of an SSPP message and to locate the transport layer header, payload, and trailer sections of a message. The link layer message layout is designed to permit mixing SSPP messages and most types of SCADA messages without interference on the same communications link for mixed-mode operation. There are two link layers, one for use on links with 8-bit data transfer, and one for use on links with only 7 bit data transfer. The 8-bit link layer SHOULD be used whenever possible. The 8-bit link layer delimits an SSPP message with two-character markers for the start of the message, start of the trailer, and end of the message. To avoid interference with plaintext SCADA traffic, these markers are configurable. The 7-bit link layer has no configurable markers. 4.1 8-bit Link Layer Message Format *********************************** A link layer message has three sections: header, payload, and trailer. To identify the beginning and end of these elements and the overall message, a SCM MUST implement the following four character sequences: ESC SOM Start Of Message ESC SOT Start Of Trailer ESC EOM End Of Message ESC ESC Escape The first three sequences identify the different parts of a message. The last sequence, ESC ESC, is sent when the ESC character is to be sent as ordinary data (but see below). In addition, a SCM MAY implement 1 or more of the following additional sequences: ESC RC1 Replacement Character 1 ... ESC RCn Replacement Character n These sequences are used as described below to avoid transmitting particular characters that might interfere with unprotected SCADA messages. Each of ESC, SOM, SOT, EOM, and RC1 ... RCn MUST be configurable characters that MUST all be different. If the SCMs will be operating in mixed-mode (both SCM and SCADA messages carried on the same link), these characters SHOULD be chosen to avoid characters having special meaning for the SCADA protocol. All SCMs sharing the same communications link MUST use the same configured characters. To send a message, the transport layer provides the link layer with three message sections: header, payload, and trailer. The link layer MUST format and transmit these as follows: ESC SOM header payload ESC SOT trailer ESC EOM During transmission of the header, payload, or trailer, the link layer SHALL transmit ESC ESC for any occurrence of the ESC character followed by any of the special characters ESC, SOM, SOT, EOM, or SCi. When receiving a message, the link layer MUST identify the three sections of the message and indicate them to the transport layer. A SCM receiving ESC ESC in the header, payload, or trailer SHALL discard one of the ESC characters and treat the other as ordinary data. The receiver separates the header from the payload by counting the first 10 octets as header. If a SCM supports 1 or more sequences ESC RC1 thru ESC RCn, it MUST support an equal number of configurable characters SC1 thru SCn. These SCADA Characters indicate characters with special meaning to SCADA devices that MUST never be sent in SSPP messages on the communications link. If configured, SC1 thru SCn MUST all be different, and MUST be different from ESC, SOM, SOT, EOM, and RC1 thru RCn. During transmission of the header, payload, or trailer, the link layer SHALL transmit ESC RCi for any occurrence of the SCi character. A SCM receiving ESC RCi in the header, payload, or trailer of an SSPP message SHALL behave as if SCi were received as an ordinary character. A sender SHOULD avoid leaving gaps between characters in the link layer message to simplify mixed mode operation with timing sensitive SCADA protocols such as Modbus. Since the payload is usually encrypted by the transport using a block cipher, this may mean delaying the ESC SOM at the beginning of the message until enough characters of the SCADA message have been received so that when a full cipher block becomes available, the last character of the header has just been transmitted. 4.2 8-bit Link Layer Layer Error Conditions During Receive ********************************************************** If the link layer encounters any of the defined markers out of order, the SCM MUST discard the rest of the message and return to listening for ESC SOM. The link layer should also signal the next layer that an error occurred so that the next layer can flush any partial message. In the event that the out-of-order marker is ESC SOM, the current message MUST be discarded and a new message begun. The link layer SHALL implement a timer that tracks the time elapsed since the last character was received. If this timer exceeds some configurable value, the partial message MUST be discarded, and the SCM MUST return to listening for ESC SOM. Other actions may also be necessary, such as terminating a partial SCADA command that has been sent out the cleartext port. 4.3 8-bit Link Layer Sender State Diagram ***************************************** The following table describes the state transitions for a finite state machine that sends link layer messages. The link layer of a SCM MUST operate in an equivalent manner to this state machine. Given a state (column in the table) and an input character (row), the table gives the next state for the state machine and an action to take. The actions StartM, StartT, and EndM indicate that the sender wishes to begin a message, begin a trailer section, or end a message. These actions must appear in the order StartM, StartT, EndM, separated by 1 or more characters. The first 10 characters of a message are considered header; the remainder of that section are payload. The state NotInM indicates the sender has not begun a message. The state InH indicates that the sender is in the header or payload section. The state inT indicates that the sender is in the trailer section. The states escInH and escInT indicate the sender just previously sent an ESC character and is in the header (or payload) or trailer section. The start state is NotInM. In the event of any discrepancy between this transition table and the english description in the preceding sections, this transition table SHALL take precedence. Char to | Current State Send | NotInM InH escInH InT escInT ============================================================= StartM | InH 1 X X X X StartT | X InT 2 InT 3 X X EndM | X X X NotInM 4 NotInM 5 ESC | X escInH 6 escInH 8 escInT 6 escInT 8 SOM | X InH 6 InH 8 InT 6 InT 8 SOT | X InH 6 InH 8 InT 6 InT 8 EOM | X InH 6 InH 8 InT 6 InT 8 SCi | X InH 7 InH 9 InT 7 InT 9 RCi | X InH 6 InH 8 InT 6 InT 8 other | X InH 6 InH 6 InT 6 InT 6 Actions: 1: send ESC, SOM 2: send ESC, SOT 3: send ESC, ESC, SOT 4: send ESC, EOM 5: send ESC, ESC, EOM 6: send current character 7: send ESC, RCi 8: send ESC, current character 9: send ESC, ESC, RCi 4.4 8-bit Link Layer Receiver State Diagram ******************************************* The following table describes the state transitions for a finite state machine that recognizes received link layer messages. The link layer of a SCM MUST operate in an equivalent manner to this state machine. Given a state (column in the table) and an input character or event (row), the table gives the next state for the state machine and an action to take. The states lookSOM, lookSOT, and lookEOM indicate the receiver is in a state where it is looking for an ESC SOM, ESC SOT, or ESC EOM sequence to recognize the next part of the message. The states escSOM, escSOT, and escEOM indicate the receiver has seen an ESC and is looking for an SOM, SOT, or EOM. The start state is lookSOM. In the event of any discrepancy between this transition table and the english description in the preceding sections, this transition table SHALL take precedence. Received | Current State Char | lookSOM escSOM lookSOT escSOT lookEOM escEOM =========================================================================== ESC | escSOM 1 escSOM 1 escSOT 1 lookSOT 2 escEOM 1 lookEOM 2 SOM | lookSOM 1 lookSOT 5 lookSOT 2 lookSOT 4 lookEOM 2 lookSOT 4 SOT | lookSOM 1 lookSOM 1 lookSOT 2 lookEOM 6 lookEOM 2 lookSOM 3 EOM | lookSOM 1 lookSOM 1 lookSOT 2 lookSOM 3 lookEOM 2 lookSOM 7 SCi | lookSOM 1 lookSOM 1 lookSOT 2 lookSOT 9 lookEOM 2 lookEOM 9 RCi | lookSOM 1 lookSOM 1 lookSOT 2 lookSOT 8 lookEOM 2 lookEOM 8 other | lookSOM 1 lookSOM 1 lookSOT 2 lookSOT 9 lookEOM 2 lookEOM 9 Timeout | lookSOM 1 lookSOM 1 lookSOM 3 lookSOM 3 lookSOM 3 lookSOM 3 Actions: 1: do nothing 2: add character to current header/payload/trailer 3: discard any partial message 4: discard any partial message, start header 5: start header 6: start trailer 7: end of message 8: add SCi to current header/payload/trailer 9: add ESC, current character to current header/payload/trailer 4.5 7-bit Link Layer An implementation MAY provide the following optional 7-bit link layer. Support for this option is not required. The 7-bit link layer formats an SSPP message as: ( base64-header-and-payload * base64-trailer ) The '(', '*', and ')' are those ascii characters with decimal values 40, 42, and 41 respectively. The sections base64-header-and-payload and base64-trailer are encoded by taking each successive 6 bits of data and using it to select one of the 64 characters A-Z, a-z, 0-9, +, or / according to the following table: 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z', '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', '+', '/' When decoding a message using the 7-bit link layer, each received character in the range A-Z, a-z, 0-9, +, or / contributes 6 bits to the current message section. If any unexpected character is received, the current partial message is discarded and the receiver resumes looking for '(' to indicate the start of a new message. The following state table represents the actions a receiver MUST take. A received character M indicates a character in the range A-Z, a-z, 0-9, +, or /. Received | Current State Char | lookSOM lookSOT lookEOM ========================================== '(' | lookSOT 5 lookSOT 4 lookSOT 4 '*' | lookSOM 1 lookEOM 6 lookSOM 3 ')' | lookSOM 1 lookSOM 3 lookSOM 7 M | lookSOM 1 lookSOT 2 lookEOM 2 other | lookSOM 1 lookSOM 3 lookSOM 3 Timeout | lookSOM 1 lookSOM 3 lookSOM 3 Actions: 1: do nothing 2: add 6 bits from character to current header/payload/trailer 3: discard any partial message 4: discard any partial message, start header 5: start header 6: start trailer 7: end of message 5. Cipher Suites **************** Cipher suite numbers are two octets (16 bits) and are always expressed in hexadecimal. No cipher suite may be numbered 0000. The top-most bit, 0x8000, indicates that the suite is vendor defined, and may not be interpreted correctly by SCMs manufactured by a different vendor. Implementations MUST NOT issue OPN, ACK, or BEG messages using any values other than those defined below, unless VENDOR_DEFINED is set. The following suites MUST be implemented: 0x0002, 0x0007, and 0x0009. The remaining suites defined below are optional. Several of the suites refer to values called X, Y, S, and R that are defined as follows. If the cipher suite is being used to encrypt data for a static session or a broadcast session, X, Y, S, and R are all zero. Otherwise, the cipher suite is either being used to encrypt or decrypt a message on a dynamic session. X is a 128-bit value formed by concatenating the 16-bit SCM address of the encrypting SCM and the 112-bit sequence number of the OPN or ACK message that the encrypting SCM sent. (The encrypting SCM sent either an OPN or an ACK depending on which SCM initiated the session). Y is a 128-bit value formed by concatenating the 16-bit SCM address of the decrypting SCM and the 112-bit sequence number of the OPN or ACK message that the decrypting SCM sent. If the cipher suite is being used to encrypt, S is: S = Enc( Enc(X) xor Y ) where Enc is a single block AES encryption using the cipher suite key and || is concatenation. If the cipher suite is being used to decrypt, R is: R = Enc( Enc(Y) xor X ) Note that S and R can be computed once at session negotiation and saved for the duration of the session. 5.1 CTR-mode with holdback ************************** There are two cipher suites for CTR-mode with holdback: 0x0001 and 0x0004. Suite 0x0001 uses HmacSHA1 with 160 bit keys, while suite 0x0004 uses HmacSHA256 with 256 bit keys. These cipher suites MUST ONLY be used for dynamic sessions. Each 16-octet block of the payload is xor-ed with a 16-octet counter. This counter is constructed by encrypting with AES/ECB using the suite encryption key the following data: block number within msg (first block is 0) - 2 octets sequence number, or random - 14 octets and then xor'ing the result with S (defined above). The sequence number is padded on the left if necessary with zeros to fill 14 octets. The transport layer payload is not padded. If the final block of the payload is less than 16 octets, it is xor-ed with a prefix of the same length of a counter constructed as above. For sessions using these cipher suites, the transport layer trailer is an HmacSHA MAC constructed as follows. For non-broadcast sessions, the first 32 octets input to the MAC are the values X followed by Y as defined above. Following are the unencrypted transport layer header and the encrypted transport layer payload. For broadcast sessions, the input to the MAC is the unencrypted transport layer header and the encrypted transport layer payload. The MAC is truncated, if necessary, by dropping octets from the right. For sessions using this cipher suite, the receiver MUST check the MAC in the transport layer trailer of a message before taking any action that makes use of the decrypted payload. If the MAC does not verify, the receiver MUST discard the message. This cipher suite is formatted as follows for use in an OPN, ACK, or BEG message: suiteNumber - 2 octets = 0x0001 or 0x0004 macLength - 1 octet AES key - 16 octets HmacSHA key - 20 or 32 octets The macLength represents the length to which the MAC must be truncated, in octets. 5.2 PE-mode with no holdback **************************** There are two cipher suites for PE-mode with no holdback: 0x0002 and 0x0005. Suite 0x0002 uses HmacSHA1 with 160 bit keys, while Suite 0x0005 uses HmacSHA256 with 256 bit keys. These cipher suites MUST NOT be used for static sessions. They MAY ONLY be used for SCADA data sessions when the SCADA protocol is known to use a 16-bit or longer CRC checksum. During encryption, a 16-octet whitener is constructed by encrypting with AES/ECB using the session encryption key the following data: block number within msg (first block is 0) - 2 octets sequence number - 14 octets and then xor'ing the result with S (defined above). The sequence number is padded on the left if necessary with zeros to fill 14 octets. Then each 16-octet block of the padded payload is xor-ed with the whitener. This result is encrypted with AES/ECB using the session encryption key. After encrypting the whitened input block, the output of the encryption is again whitened by xor'ing with the same whitener. The transport layer payload is padded with from 1 to 16 octets so that the payload and padding are a multiple of 16 octets in length. The first octet of padding is 0x80, and all remaining octets of padding are zeros. For sessions using these cipher suites, the transport layer trailer is an HmacSHA MAC constructed as follows. For non-broadcast sessions, the first 32 octets input to the MAC are the values X followed by Y as defined above. Following are the unencrypted transport layer header and the encrypted transport layer payload. For broadcast sessions, the input to the MAC is the unencrypted transport layer header and the encrypted transport layer payload. The MAC is truncated, if necessary, by dropping octets from the right. For DTA messages using these cipher suites, the receiver SHALL verify that the sequence number is within the tolerance of the session clock. If not, the message SHALL be silently discarded. Otherwise, the receiver SHOULD forward each block of decrypted data to the receiving SCADA equipment as it is decrypted. The receiver MUST update its receive sequence number to that of a received message whenver that message's sequence number is newer and within the tolerance of the session clock, even if the MAC in the trailer is incorrect. These cipher suites MUST not be used without a session clock. For CLS messages using these cipher suites, the receiver MUST check the trailer MAC and discard the message if it is incorrect. This cipher suite is formatted as follows for use in an OPN, ACK, or BEG message: suiteNumber - 2 octets = 0x0002 or 0x0005 macLength - 1 octet AES key - 16 octets HmacSHA key - 20 or 32 octets The macLength represents the length to which the MAC must be truncated, in octets. 5.3 Cleartext with Hash *********************** There are two cipher suites for cleartext with hash: 0x0003 and 0x0006. Suite 0x0003 uses SHA1, while suite 0x0006 uses SHA256. These cipher suites MUST NOT be used to transfer SCADA data. They are intended to be used for certificate exchange by vendor-defined key management extensions. THESE SUITES PROVIDE NO SECURITY. The payload of messages using these cipher suites is not encrypted. The transport layer payload is not padded. For sessions using this cipher suite, the transport layer trailer is a SHA hash of the transport layer header and payload. The receiver MUST check the hash in the transport layer trailer of a message before taking any action that makes use of the payload. If the hash does not verify, the receiver MUST discard the message. This cipher suite is formatted as follows for use in an OPN, ACK, or BEG message: suiteNumber - 2 octets = 0x0003 or 0x0006 truncatedLength - 1 octet The truncatedLength represents the length to which the hash must be truncated, in octets. 5.4 MAC with holdback ********************* There are two cipher suites for MAC only with holdback: 0x0007 and 0x0008. Suite 0x0007 uses HmacSHA1 with 160 bit keys, while Suite 0x0008 uses HmacSHA256 with 256 bit keys. These cipher suites MUST NOT be used for static sessions. The payload is not encrypted or padded. For sessions using these cipher suites, the transport layer trailer is an HmacSHA MAC constructed as follows. For non-broadcast sessions, the first 32 octets input to the MAC are the values X followed by Y as defined above. Following are the unencrypted transport layer header and the encrypted transport layer payload. For broadcast sessions, the input to the MAC is the unencrypted transport layer header and the encrypted transport layer payload. The MAC is truncated, if necessary, by dropping octets from the right. For sessions using this cipher suite, the receiver MUST check the MAC in the transport layer trailer of a message before taking any action that makes use of the payload. If the MAC does not verify, the receiver MUST discard the message. This cipher suite is formatted as follows for use in an OPN, ACK, or BEG message: suiteNumber - 2 octets = 0x0007 or 0x0008 macLength - 1 octet HmacSHA key - 20 or 32 octets The macLength represents the length to which the MAC must be truncated, in octets. 5.5 CBC-mode with holdback ************************** There are two cipher suites for CBC-mode with holdback: 0x0009 and 0x000a. Suite 0x0009 uses HmacSHA1 with 160 bit keys, while Suite 0x000a uses HmacSHA256 with 256 bit keys. These cipher suites may be used for static or dynamic sessions. During encryption, each 16-octet block of the padded payload is first xor-ed with the 16 octets of the previous ciphertext block. The first block is xor-ed with 16 octets of an Initialization Vector (IV) that is constructed by encrypting with AES/ECB using the session encryption key the following data: zeros - 2 octets sequence number - 14 octets and then xor'ing the result with S (defined above). The transport layer payload is padded with from 1 to 16 octets so that the payload and padding are a multiple of 16 octets in length. The first octet of padding is 0x80, and all remaining octets of padding are zeros. For sessions using these cipher suites, the transport layer trailer is an HmacSHA MAC constructed as follows. For dynamic non-broadcast sessions, the first 32 octets input to the MAC are the values X followed by Y as defined above. Following are the unencrypted transport layer header and the encrypted transport layer payload. For static or broadcast sessions, the input to the MAC is the unencrypted transport layer header and the encrypted transport layer payload. The MAC is truncated, if necessary, by dropping octets from the right. For sessions using this cipher suite, the receiver MUST check the MAC in the transport layer trailer of a message before taking any action that makes use of the decrypted payload. If the MAC does not verify, the receiver MUST discard the message. For CLS messages using these cipher suites, the receiver MUST check the trailer MAC and discard the message if it is incorrect. This cipher suite is formatted as follows for use in an OPN, ACK, or BEG message: suiteNumber - 2 octets = 0x0009 or 0x000a macLength - 1 octet AES key - 16 octets HmacSHA key - 20 or 32 octets The macLength represents the length to which the MAC must be truncated, in octets. 6. Management Messages *********************** A message of length zero received on a session of type MANAGEMENT is a query for a vendor-defined version string. A SCM receiving such a message MUST respond on the same session with a vendor-defined version string of length one or more. The version string SHOULD include at least information identifying the vendor and version number of the implementation. The vendor identification SHOULD be chosen so as to be unlikely to conflict with the identification information of another vendor. For example, the ScadaSafe implementation returns a string of the form: ScadaSafe V.V.V built YYYY/MM/DD HH:MM -TZTZ References ********** [1] Wright, A. K., Kinast, J., and McCarty, J. Low-Latency Cryptographic Protection for SCADA Communications. In Proc. APplied Cryptography and Network Security, Springer Lecture Notes in Computer Science, June 2004.