Страница 5: ДСТУ CLC/TS 50136-9:2014. Alarm systems - Alarm transmission systems and equipment - Part 9: Requirements for common protocol for alarm transmission using the Internet protocol (62644)

The cipher suite TLS_DHE_DSS_WITH_AES_256_CBC_SHA shall be used and the master key is the 256 bit AES symmetric key created by the DTLS handshake.

RCT Requirements:

• each RCT shall hold the certificates for every CA which has signed a certificate for any SPT which can potentially connect to the RCT;

• RCT shall provide mechanism to add new CA certificates to the system to allow SPT from a new manufacturer to be connected to the system, as well as a mechanism to delete CA certificates from the system. The details of the insertion/removal of the certificate is outside the scope of this document;

• while the DTLS implementation in the RCT may support other cipher suites, only TLS_DHE_DSS_WITH_AES_256_CBC_SHA shall be used for generating the master key.

SPT Requirements:

the SPT shall hold the certificates of the CAs which have signed the certificates for the RCTs to which the SPT may potentially connect. It is not mandatory for the SPT to validate the authenticity of the RCT but it is recommended that it do so;

• the Common Name of SPTs X.509 certificate shall be in the format “supplier identifiensupplier specific identifier". Registered Internet domain name of the supplier is used as the supplier ID. This shall uniquely identify the SPT;

• the SPTs X.509 certificate shall be signed by a CA which is known to all the RCTs to which it could potentially connect;

• the SPT shall only present the cipher suite TLS_DHE_DSS_WITH_AES_256_CBC_SHA to be used in the DTLS handshake.

On completion of the parameter negotiation, the DTLS session is terminated, contexts etc freed and all further communication takes place using the negotiated parameters.

7.2 Connection setup

In case of a reconnect, the ‘Master Set’ as negotiated during commissioning will be initially be used for encryption and authentication the messages between SPT and RCT. The first steps are to request new session parameters that are then used for further communication.

Typically connections are permanent 24/7, in case a connection breaks the SPT will attempt to re­establish the connection.

During the connection setup stage, the following parameters are set in the order per below:

Protocol version level mutually agreed by SPT and RCT;

• Encryption selection;

• Session key;

• Hash;

Path supervision.

The message flow during connection setup (to request the session parameters) is as follows:

Table 48 - Message flow during connection setup

For further details refer to the example in D.2.

Annex A

(normative)

Result codes

Table A.1 - Result codes

Annex В
(normative)

Protocol Identifiers

The following table summarizes the possible protocol Identifiers for application layer protocol carried by the protocol defined in this Technical Specification.

Each compatible implementation of this protocol shall support at least two types of messaging:

• Transparent messages for serially connected AE and / or AS;

• Sia DC-03 message structures for AS signals connected by pin inputs;

• Sia DC-03 message structures for messages generated internally by SPT and / or RCT.

Table B.1 - Protocol identifiers

A manufacturer wishing to send messages that do not fit any of the listed application protocols shall use protocol identifier 254. Any currently unallocated protocol identifier may be allocated in a later revision of this Technical Specification.Annex C
(normative)

Shared secret

C.1 Formatting of the shared secret

When encoding and formatting the shared secret into a string format, readable for human beings, it shall be represented in ascii hexadecimal format, in Network byte order. E.g. the characters as used are {'0',..,'9'} + {'A',..,'F'}.

Formatting of the key value to improve the readability for humans shall use one of the explicitly named separator symbols or {space}. During formatting, the separator symbols can be freely used to improve readability (e.g. grouping in four char blocks, each block separated by hyphens from each other); during decoding, the occurrence of separator symbols inside of the key string is ignored completely.

NOTE 1 Lower case letters are treated identical to upper case letters, i.e. Lower/upper case transmission problems (like spelling the key string by voice over a telephone line) will lead to a valid decoding of the key.

NOTE 2 Each part of the shared secret has a checksum appended.

Example of encryption key (256-bit with CRC) as part of the shared secret:

363E-2B16-8DBB-5A95-7D5F-2BF4-25A4-5D7C-363E-2B16-8DBB-5A95-7D5F-2BF4-25A4-5D7C- 0689

Example of Connection Handle (with CRC) as part of the shared secret:

7D30-FA26-8238

C.2 Checksum for Shared Secret Formatting

CRC-16-CCITT Checksums are used to detect possible errors in shared secrets before they are used. This clause provides examples of the checksum procedure.

The CRC-16-CCITT calculation is defined by the following parameters:

Polynomial: 0x1021

Initial crc value: Oxffff

C.3 Example of Secret Encoding and Formatting

Example encoding and formatting

Step 1: Create random key

secret key к= 0x36 Зе 2b 16 8d bb 5a 95 7d 5f 2b f4 25 a4 5d 7c

24 e3 cl b9 2f 4b a0 13 ее 6a d9 b2 3f 91 f5 63

(in hex, to see byte order representation)

Step 2: Calculate CRC

CRC16(k) = 0x4A97 (hexadecimal)

Step 3: Present key in ascii hexadecimal format, (optionally) use separators to improve readability:

363E-2B16-8DBB-5A95-7D5F-2BF4-25A4-5D7C-24E3-C1B9-2F4B-A013-EE6A-D9B2-3F91-F563

Step 4: Append encoding of CRC16(k) to k, optionally using separators:

363E-2B16-8DBB-5A95-7D5F-2BF4-25A4-5D7C-24E3-C1B9-2F4B-A013-EE6A-D9B2-3F91-F563- 4A97Annex D

(informative)

Examples of messaging sequences

D.1 Commissioning

The following diagram demonstrates the commissioning messaging sequence.

Devices example:

Shared secret example:

The example Device IDs, keys and handles as shown above are illustrative only, and do not represent the actual format of these parameters.

This sequence is followed by a Connection Setup.D.2 Connection setup

The following diagram demonstrates the messaging sequence during connection setup.

Devices example:

R

- SPT Device ID

88998899

66776677