Application Layer

PARTS 1 AND 2 REMOVED – will add this later.

Packet Superframes

Packet superframes are composed of a 1..n byte data type specifier, 0..797 bytes of payload data. The data type specifier is encoded in the same way as UTF-8. It provides efficient coding of common data types. And it can be extended to include a very large number of distinct packet data type codes.

The data type specifier can also be used as a protocol specifier. For example, the following protocol identifers are reserved in the M17 packet spec:

Table 17 Reserved Protocols
Identifer Protocol
0x00 RAW
0x01 AX.25
0x02 APRS
0x03 6LoWPAN
0x04 IPv4
0x05 SMS
0x06 WinLink

The data type specifier is used to compute the CRC, along with the payload.

Encryption Types

Encryption is optional and disabled by default. The use of it is only allowed if local laws allow to doso.

Null Encryption

Encryption type = \(00_2\)

No encryption is performed, payload is sent in clear text.

Scrambler

Encryption type = \(01_2\)

Scrambling is an encryption by bit inversion using a bitwise exclusive-or (XOR) operation between bit sequence of data and pseudorandom bit sequence.

Encrypting bitstream is generated using a Fibonacci-topology Linear-Feedback Shift Register (LFSR). Three different LFSR sizes are available: 8, 16 and 24-bit. Each shift register has an associated polynomial. The polynomials are listed in Table 7. The LFSR is initialised with a seed value of the same length as the shift register. Seed value acts as an encryption key for the scrambler algorithm. Figures 5 to 8 show block diagrams of the algorithm

Table 18 LFSR scrambler polynomials
Encryption subtype LFSR polynomial Seed length Sequence period
\(00_2\) \(x^8 + x^6 + x^5 + x^4 + 1\) 8 bits 255
\(01_2\) \(x^{16} + x^{15} + x^{13} + x^4 + 1\) 16 bits 65,535
\(10_2\) \(x^{24} + x^{23} + x^{22} + x^{17} + 1\) 24 bits 16,777,215
_images/LFSR_8.svg

Fig. 7 8-bit LFSR taps

_images/LFSR_16.svg

Fig. 8 16-bit LFSR taps

_images/LFSR_24.svg

Fig. 9 24-bit LFSR taps

Advanced Encryption Standard (AES)

Encryption type = \(10_2\)

This method uses AES block cipher in counter (CTR) mode. 96-bit nonce value is extracted from the NONCE field, as the 96 most significant bits of it. The highest 16 bits of the counter are the remaining 16 bits of the NONCE field. FN field value is then used as the counter. The 16 bit frame counter and 40 ms frames can provide for over 20 minutes of streaming without rolling over the counter [1]. This method adapts 16-bit counter to the standard 32-bit CTR for the encryption. FN counter always start from 0 (zero).

[1]The effective capacity of the counter is 15 bits, as the MSB is used for transmission end signalling

The nonce value should be generated with a hardware random number generator or any other method of generating non-repeating values. Nonce values must be used only once. It is obvious that with a finite number of nonce bits, the probability of nonce collision approaches 1. We assume that the transmission is secure for 237 frames using a single key. It is recommended to change keys after that period.

Warning

In CTR mode, AES encryption is malleable [CTR] [CRYPTO]. That is, an attacker can change the contents of the encrypted message without decrypting it. This means that recipients of AES-encrypted data must not trust that the data is authentic. Users who require that received messages are proven to be exactly as-sent by the sender should add application-layer authentication, such as HMAC. In the future, use of a different mode, such as Galois/Counter Mode, could alleviate this issue [CRYPTO].

To combat replay attacks, a 32-bit timestamp shall be embedded into the NONCE field. The field structure is shown in Table 9. Timestamp is 32 LSB portion of the number of seconds that elapsed since the beginning of 1970-01-01, 00:00:00 UTC, minus leap seconds (a.k.a. “unix time”).

Table 19 NONCE field structure
TIMESTAMP NONCE CTR_HIGH
32 64 16

CTR_HIGH field initializes the highest 16 bits of the CTR, with the rest of the counter being equal to the FN counter.

[CTR]McGrew, David A. “Counter mode security: Analysis and recommendations.” Cisco Systems, November 2, no. 4 (2002).
[CRYPTO](1, 2) Rogaway, Phillip. “Evaluation of some blockcipher modes of operation.” Cryptography Research and Evaluation Committees (CRYPTREC) for the Government of Japan (2011).