---

This is the first message that uses the newly set Hash. By default SHA-256 (value 0) is used as hash function.

The Path supervision request message has the following format:

SPT -» RCT

Table 35 - Path supervision request message format

The Heartbeat interval time specifies the time until the SPT will send the next heartbeat.

The push-pull option determines the polling device:

0: Push: the SPT sends the poll to the RCT;

- 1: Pull: the RCT sends the poll to the SPT, which allows for load balancing.

The Path supervision response message has the following format:

RCT SPT

Table 36 - Path supervision response message format

^a Result code can be: RESP_ACKNOWLEDGE RESP_POLL_TOO_SLOW

The Set time command message has the following format:

RCT SPT

Table 37 - Set time command message format

This command is optional. In case events are transmitted with timestamps this command can be send by the RCT to synchronize.

The Set time response message has the following format:

SPT -» RCT

Table 38 - Set time response message format

The Protocol version request message has the following format:

SPT RCT

Table 39 - Protocol version request message format

This message is issued during commissioning and connection setup by the SPT to indicate the protocol version it supports.

The Protocol version response message has the following format:

RCT SPT

Table 40 - Protocol version response message format

The Transparent message has the following format:

Table 41 - Transparent message format

This message allows for (vendor specific) data to be transmitted between SPT and ROT. It can for example be used for configuration data or firmware uploads.

The Transparent response has the following format:

Table 42 - Transparent response format

The DTLS completed request message has the following format:

SPT -» RCT

Table 43 - DTLS completed request message format

This message is sent by the SPT to request the end of the DTLS session.

This message does not contain additional info.

The DTLS completed response message has the following format:

RCT SPT

Table 44 - DTLS completed response message format

This message is send by the RCT as response to the DTLS completed request message.

This is sent by the RCT to end the parameter negotiation. After this is sent by the RCT and received by the SPT, the DTLS session is closed, all resources used by the session are freed and further communication between the RCT and SPT is done using the negotiated parameters.

The RCT parameter request message has the following format:

SPT -» RCT

Table 45 - RCT IP parameter request message format

If the SPT is to communicate either using a different port number for commissioning and 'normal' session traffic, or if separate commissioning and session RCTs are used, or if the SPT is to communicate with more than one RCT, then the RCT can send the IP address(es) and port(s) to be used for the session. It is the responsibility of the commissioning RCT to securely pass the session parameters to any other RCTs to which the SPT may have to communicate. The mechanism by the RCTs share the session parameters is vendor specific and outside the scope of this protocol standard.

Implementation of this message is optional for the SPT.

The RCT IP parameter response message has the following format:

RCT -» SPT

Table 46 - RCT IP parameter response message format

7 Commissioning and connection setup

The objective of the commissioning procedure is to enable the Supervised Premises Transceiver and the Receiving Centre Transceiver to mutually authenticate each other.

Further, the commissioning procedure is used to negotiate the parameters:

• Connection handle;

Device IDs of SPT and RCT;

Master Encryption Key;

• Master Encryption Selection;

• (optional) RCT IP Address(es) and Port(s) with which the SPT should communicate (this allows for a separate 'commissioning server' to handle the 'initial contact' for multiple receivers. In this situation the commissioning server will have to securely transfer the session parameters to the appropriate RCT. The mechanism for doing this is outside the scope of this protocol).

A successful commissioning procedure establishes a communication session with a connection handle as unique identifier. The communication session lasts until a re-commissioning takes place. Especially, the change of session keys does not have an impact upon the communication session, i.e. it does not lead to any change in the connection handle.

There are two options for obtaining the ‘Master Set’. Either:

- generated using a ‘Shared Secret’ passed out-of-band, or

using X.509 certificates and DTLS in both RCT and SPT (optionally) (see 7.1.5)

Irrespective of the mechanism used to obtain it, the master key is then used to encrypt, using AES256, the exchange of the other parameters. It is also used (by the 'running' protocol) to establish the session key(s).

The master key is a 256 bit key.

The ‘Master Set’ is exchanged using the message flow as described below. The messages are the same, irrespective of the commissioning procedure in use. The difference is in the method in which the messages are secured, either using the 'Shared secret’ (‘One-time-pad’ Key and Device ID) as provided by the RCT, or using X.509/DTLS.

The message flow during the commissioning of a new SPT is as follows:

Table 47 - Message flow during the commissioning of a new SPT

The resulting Master parameters are stored in NVM on both SPT and RCT.

Note that initially some fields in the header will be uninitialized until the matching configuration message is processed. Therefore it is essential that the IP address of the SPT does not change during this commissioning phase (it should remain constant throughout the exchange even if the secured premises have the most restrictive stateful firewall).

A detailed overview can be found in D.1.

The next step is to request the Session parameters as specified in 7.2.

Support for the shared secret procedure for generating the master key is mandatory in both RCTs and SPTs.

For this procedure, the RCT will generate a shared secret which consists of the Connection Handle and the Encryption key.

Shared Secret consists of:

• the 4 byte Connection Handle;

• the 32 byte (AES-256) encryption key.

For the commissioning stage AES-256 is mandatory. On request of the SPT (performance) this can be changed to AES-128 for normal communication.

The parameters will be used only for the exchange of the master key. Once the master has been successfully sent from the RCT to SPT, the session will be deleted and never re-used.

Next, these parameters are renewed, and stored into non-volatile memory as the new ‘Master set’. This new ‘Master set’ will be used to reconnect after disconnects or power failures.

The security of the out-of-band channel is one of the factors that determine the security of the pairing process between SPT and RCT. As the out-of-band channel is very likely to rely on human operator at one or both sides it should also be simple to implement and tolerant of human error. The following requirements are applicable:

- The Shared Secret shall be generated by the management system of the ATS, which may or may not be operated by an ARC. The processing power of the management system typically exceeds that of the SPT by orders of magnitude and therefore can generate Shared Secret of better cryptographic quality (randomness) than a small embedded system. In addition the ATS service provider or ARC has a guarantee that the Shared Secret generation process is compliant with these requirements.

Physical and logical means of Shared Secret transfer to the SPT shall make it difficult for a third party to intercept it without being detected. The word difficult means expensive in terms of time or resources in comparison to the gain the attacker may obtain by knowing the Shared Secret. The following methods may be considered appropriate depending on the security level of protected premises:

• ARC operator dictates the Shared Secret to the field technician over the phone.

• The Shared Secret is transmitted using SMS.

• The Shared Secret is sent in an encrypted and signed e-mail.

• The Shared Secret is printed at the Management centre I ARC and the field technician brings it to the protected premises himself.

• The Shared Secret is programmed into SPT at the Management centre I ARC and then transported to the protected premises,

• The Shared Secret is obtained by the field technician from a secured web site of the ATS service provider.

• Any other method meeting the difficulty criterion.

It is the responsibility of the ATS service provider / ARC to judge the security of the method it uses to transfer the Shared Secret vs. the security level of the protected premises.

The Shared Secret shall not be sent over a channel which is used for communication between the SPT and RCT for alarm reporting and monitoring.

• The Shared Secret shall be generated using cryptographically strong random number generator (see RFC 4086).

• To cope with potential typos and other human typical transmission errors, the text representation of the Shared Secret is extended by a 16 bit checksum, calculated as CRC as described in C.2, directly appended to the Shared Secret string.

7.1.5 Commissioning using X.509 Certificates and DTLS

Support for the X.509 mechanism and DTLS is optional for SPTs and mandatory for RCTs.

The authentication, cipher selection and key exchange are performed using the DTLS protocol with the SPT as client and RCT as server. DTLS is a variation of TLS, which defines the base messages and formats. The Connection Handle and optional parameters are set using the cypher and session key negotiated.