ssp21 / ssp21-spec

Secure SCADA Protocol 21 Specification

SSP21

Secure SCADA Protocol for the 21st century (SSP21) is a cryptographic wrapper for ICS environments. It is inspired by the Noise Protocol.

Specification

The specification is built using pandoc. The included Makefile will generate PDF and HTML output.

Setup

> sudo apt-get install pandoc mscgen graphviz texlive texlive-latex-base texlive-latex-extra texlive-fonts-recommended lmodern python-dev python-pip inkscape
> pip install pandoc-fignos

Depending on your setup of Python, you may need to add ~/.local/bin to your path.

ssp21-spec's Issues

clarify when session time is initialized

Reported by @emgre:

When and how are `time_session_init` variables set? There's detailed instructions in the 2-RTT version of it, but not much in the 1-RTT.

Add detailed analysis of how SSP21 differs from Noise pattern

Replace 'master' and 'outstation' with 'initiator' and 'responder'

Write a section in the document that explains how the new terms generally map onto SCADA systems.

Session validation of TTL should use relative time

• In section 5.5.3, the third point should be "Set valid_until_ms = NOW() - time_session_init + TTL".

• In section 5.5.4, the second point should be "Check that valid_until_ms <= NOW() - time_session_init".

Otherwise, you would need two synchronized clocks and time_session_init would be useless.

The ref implementation does as I described. See https://github.com/aegis4ics/ssp21-cpp/blob/master/cpp/libs/src/ssp21/crypto/Session.cpp#L171 and https://github.com/aegis4ics/ssp21-cpp/blob/master/cpp/libs/src/ssp21/crypto/Session.cpp#L118

3.1 Alternative: Symmetric keys only

This is a not good, as this means a single symmetric key is used over an extended period of time. Using the same symmetric key will give attackers lots of data to attempt a crack, along with lots of time to attempt to attack the key.

A better method is to use an algorithm like PAKE to establish a new key each time, or derive a new key from the root key (using a KDF) that is used for the session.

make PDF broken?

from latest master:

$ make
pandoc ssp21.md -s --toc --toc-depth=5 --number-sections \
        -f markdown+yaml_metadata_block+startnum \
	--filter pandoc-fignos \
	--template template_pandoc.latex \
	-V colorlinks \
	-o ssp21.pdf
! Undefined control sequence.
l.161 \tightlist

pandoc: Error producing PDF
Makefile:33: recipe for target 'ssp21.pdf' failed
make: *** [ssp21.pdf] Error 43

Mix the session auth messages into CK

Doesn't affect security at this time, but future proofs things in case we add metadata to those messages in the future.

Add definitions for bitfields

Don't forget to discuss:

A) implicit top bit -> bottom bit assignment
B) parsing error when reserved bit is set

Switch spec to specify little endian

Currently using big endian since Noise specified this but decision is arbitrary

Clarify payload expectations for n == 0 vs n > 0 SessionData messages

From @emgre:

It is not clear whether of not empty payload messages are supported. In section 5.5.6, it says that "empty session messages are explicitly disallowed", while in the section 5.4, is says that an implementation willing to wait for full authentication can send a zero-payload session data.

Remove 2-RTT messages/enums

Request/Reply HandshakeAuth and also HandshakeMAC can now be removed.

Consider citing CRC HD tool and research

Comment from BMK

Disallow empty session messages

There's no reason to ever send an empty session message (tag only) so explicitly disallow them in the specification.

Remove mentions of DNP3 SA to make document more neutral

Doesn't add to the argument to make protocol specific knocks.

From Tim:

"This technique is utilized to combat one-pass authentication techniques from being abused to carry out held-replay message attacks where an authenticated session is utilized to replay messages out of the authenticated context" or however you want to word itand drop reference to DNP3 SA

Add verbiage to the specification on how CRC vs HMAC errors are logged

Add state transition diagrams for initiator and responder handshakes

From BMK.

We already have the "dot" package integrated and have played with diagram generation.

The transition diagrams will likely need to differ for session oriented (TCP) vs sessionless (serial/UDP). This may perhaps consist of optional transitions / actions in one but not the other.

For instance, in TCP we may want to specify that the connection should be closed for certain reasons, but would never do this for serial.

add definitions for specification terminology and/or a glossary

From BMK:

"Would it be useful to add some definitions of the “requirement” words used in the spec (i.e. “shall”, “may”, “should”), a la RFC style? Also consider adding definitions of key terms, used throughout the document, up front."

Add mechanism to limit DoS for repeated REQUEST_HANDSHAKE_BEGIN

The responder has to do a lot of cryptographic operations upon receiving this message. Perhaps we should consider limiting these requests, and returning an error code if insufficient time has elapsed since the last one?

Define optimal synchronization (start) bytes for link layer

The best start bytes should have a low probability of occurring in other parts of the protocol.

How about:

0b10101010 == 0xAA
0b01010101 == 0x55

So start characters would be [0xAA, 0x55]

thoughts?

In the session invaliation description, specify that the nonce maximum value is configurable

In section 5.5.2, the first point should be "The transmit or receive nonce reaches a configurable maximum value." The configurable value comes from struct SessionConstraint::max_nonce and its maximum value is indeed 2^16 -1.

The ref implementation does check the configured value. See https://github.com/aegis4ics/ssp21-cpp/blob/master/cpp/libs/src/ssp21/crypto/Session.cpp#L135