NB: this document relies on certain terms and concepts introduced in SmartAnthill 2.0 Overall Architecture and SmartAnthill 2.0 Protocol Stack documents, please make sure to read them before proceeding.
SmartAnthill SCRAMBLING procedure aims to provide some extra protection when data is transmitted in open (in particular, over wireless or over the Internet). SCRAMBLING procedure does not provide security guarantees in a strict sense, but might hide certain details (such as source/destination addresses) and does help against certain classes of DoS attacks. Because of the lack of security guarantees, SCRAMBLING procedure SHOULD NOT be used as a sole encryption protocol (using it over SASP is fine).
SCRAMBLING procedure requires both sides to share one AES-128 key. SCRAMBLING key MUST be separate and independent from any other key in the system, in particular, from SASP keys.
Within SmartAnthill protocol stack, to allow for arbitrary moving Devices, SCRAMBLING key is the same for the whole SmartAnthill PAN. This is unlike SASP keys, which are unique per-device.
SCRAMBLING procedure is intended to be used as the outermost packet wrapper which is possible for an underlying protocol. Within SmartAnthill Protocol Stack, SCRAMBLING procedure is OPTIONALLY used by SAoIP protocol as described in SmartAnthill-over-IP Protocol (SAoIP) and SmartAnthill Router document. In addition, SADLP-* protocols, especially those working over wireless L1 protocols, SHOULD use SCRAMBLING procedure to hide as much information as possible.
SCRAMBLING procedure is a procedure of taking an input packet of arbitrary size, and producing a “scrambled” packet. It is used both by SAoIP and some of SADLP-*.
SCRAMBLING procedure requires both sides to share one secret AES-128 key. SCRAMBLING key MUST be independent from any other key in the system, in particular, from SASP key.
For SCRAMBLING procedure to be efficient (in secure sense), caller SHOULD guarantee that there is a 12-byte block within input packet, where such block is at least statistically unique, and the same block is statistically indistinguishable from white noise. Offset to such a block within the packet is an input unique-block-offset parameter for SCRAMBLING procedure. In practice, SASP tag can be used for this purpose.
For some of the SADLP-* protocols, desirable properties MAY include such things as AC/DC balance, or a (weaker) requirement to have at least one switch between different bits per N bits in bitstream. These requirements MAY be satisfied statistically (with the idea behind being similar to 64/66b protocol).
SADLP-* protocols MAY specify Salted-SCRAMBLING procedure, which enables such statistical properties. Given that SCRAMBLING procedure uses industrial-grade encryption, normally, one-byte “salt” is sufficient to ensure that at least one of the packets will have desirable properties.
When Salted-SCRAMBLING is used, “Salt” field MUST be populated by random data:
- this random data MUST come from non-keystream RNG, see SmartAnthill SmartAnthill Random Number Generation and Key Generation for details
- if non-keystream RNG is not completely initialized yet at the moment when Salted-Default SCRAMBLING needs to be used, then:
- No data from not-initialized (or partially-initialized) RNG can ever be used
- Instead, Salted-SCRAMBLING procedure MUST use incremented counter; this counter SHOULD be pre-initialized with 0x33 on each system start.
- as soon as non-keystream RNG is completely initialized, it MUST be used instead of the incremented counter.
If Salted-SCRAMBLING is used, then for ANY retransmit (this MUST include SAMP retransmits and SAGDP retransmits), new value of “Salt” MUST be generated as described above, and the packet MUST be re-SCRAMBLED. This is necessary to ensure that if violation of desirable properties has occurred, it will be statistically healed on the next run.
Input of SCRAMBLING procedure is a pre-SCRAMBLING packet, and unique-block-offset offset. pre-SCRAMBLING packet can be considered as follows:
| unencrypted-pre-SCRAMBLING-Data | encrypted-pre-unique-pre-SCRAMBLING-Data | encrypted-unique-block | encrypted-post-unique-pre-SCRAMBLING-Data |
where encrypted-unique-block is always 12 bytes in size, and it’s offset from the beginning is specified by unique-block-offset input parameter, and any of encrypted-pre-unique-pre-SCRAMBLING-Data and encrypted-post-unique-pre-SCRAMBLING-Data can have 0 size.
unique-block-offset+12 MUST be within pre-SCRAMBLING-Data.
SCRAMBLING procedure works as follows:
- Form SCRAMBLING-Header according to formatting schema (Default schema is described below, but SADLP-* implementations are allowed to define their own schemas if necessary).
SCRAMBLING-Header, regardless of formatting schema, MUST specify Scrambled-Size and Forced-Padding-Size parameters. Scrambled-Size is a number of 16-byte blocks which were scrambled; 16*Scrambled-Size MUST be >= size of SCRAMBLING-Header. For security purposes, sender MAY scramble more bytes (and respectively specify Scrambled-Size) than strictly necessary. However, sender MUST NOT specify Scrambled-Size so that 16*Scrambled-Size is more than sizeof(SCRAMBLING-Header)+sizeof(encrypted-pre-unique-pre-SCRAMBLING-Data)+sizeof(encrypted-post-unique-pre-SCRAMBLING-Data)+15; otherwise, receiver MUST treat it as a malformed packet.
- Form pre-SCRAMBLED packet which has the following format:
| encrypted-unique-block | OPTIONAL-SALT | SCRAMBLED-Header | encrypted-pre-unique-pre-SCRAMBLING-Data | encrypted-post-unique-pre-SCRAMBLING-Data | Optional-Forced-Padding |
where OPTIONAL-SALT is a 1-byte field, present only if Salted-SCRAMBLING is specified by the protocol which uses SCRAMBLING procedure (if non-Salted-SCRAMBLING is specified, SALT is presumed to be equal to 0), Optional-Forced-Padding is optional forced padding, which has size of Forced-Padding-Size parameter from SCRAMBLING-Header. Forced-Padding, if present, MUST be generated using SmartAnthill Non-Key Random Stream (which is described in SmartAnthill SmartAnthill Random Number Generation and Key Generation).
- Encrypt a portion of pre-SCRAMBLED packet, starting from SCRAMBLED-HEADER, and with length of Scrambled-Size*16 (as specified in SCRAMBLING-Header), using AES-128 in CTR mode, using SCRAMBLING key, and using ( encrypted-unique-block << 32 ) | ( SALT << 24 ) as initial counter for CTR. CTR mode, combined with statistical-uniqueness requirement for unique-block, ensures that SCRAMBLED data is indistinguishable from white noise for a potential attacker. NB: size of ( encrypted-unique-block << 32 ) | ( SALT << 24 ) is 128 bit, or one AES-128 block. NB2: technically, this construct restricts the size of data being SCRAMBLED, to 16*2^24~=256 Mbytes; it is many orders of magnitude larger than any practical packets may reasonably contain.
If 16*Scrambled-Size goes beyond encrypted-post-unique-pre-SCRAMBLING-DATA, remaining SCRAMBLING bytes are ignored; due to requirement on Scrambled-Size stated above, number of such ignored bytes cannot exceed 15.
Default SCRAMBLING-Header Schema assumes that the size of encrypted-post-unique-pre-SCRAMBLING-Data is always zero (and that therefore unique-block-offset parameter is always equal to pre_SCRAMBLING_packet_size-12). This occurs when (a) SASP tag is located at the very end of the SASP packet (which is always the case for SASP as described in SmartAnthill Security Protocol (SASP) document), and (b) all protocols below SASP and above the protocol which uses SCRAMBLING procedure add only headers, and not trailers.
If the size of encrypted-post-unique-pre-SCRAMBLING-Data is always zero, it means that there is no need to send unique-block-offset over the wire, as it can always be calculated on receiving side. Therefore, Default SCRAMBLING-Header Schema is defined as follows:
| Forced-Padding-Flag-And-Scrambled-Size | Optional-Forced-Padding-Size | unencrypted-pre-SCRAMBLING-Data |
where Forced-Padding-Flag-And-Scrambled-Size is an Encoded-Unsigned-Int<max=2> field, which acts as a substrate for bitfields Forced-Padding-Flag (takes bit ), and Scrambled-Size (takes bits [1..]), and Optional-Forced-Padding-Size is an Encoded-Unsigned-Int<max=2> field which is present only if Forced-Padding-Flag is equal to 1.
Processing of a SCRAMBLED packet (“DESCRAMBLING”) is performed in reverse order compared to SCRAMBLING procedure.
NB: “Streamed” SCRAMBLING is not currently used; MAY be reinstated when/if SAoTCP is reinstated
There are cases, where SCRAMBLED data is intended to be sent over stream (such as TCP stream), other than in individual datagrams. In such cases, “Streamed” SCRAMBLING may be used. “Streamed” SCRAMBLING differs from SCRAMBLING procedure above in the following details:
- when SCRAMBLING-Header is formed, it includes Whole-Packet-Size (as the very first field), followed by all the fields specified in SCRAMBLING procedure above.
where Whole-Packet-Size is an Encoded-Unsigned-Int<max=2> field, representing the whole packet size (excluding forced-padding if any).
As even Whole-Packet-Size is scrambled, the whole stream looks as a white noise (NB: some information can be still extracted by attacker from timing and division of the stream into packets).
To ensure proper error recovery, receiving side of “Streamed”-SCRAMBLED stream MUST forcibly break an underlying stream (such as TCP connection) as soon as any of the de-SCRAMBLING operations for packets received over this underlying connection fail (this includes size field exceeding it’s “max=” size).
TODO: forced-padding (incl. random-size padding)