Specification Proposal: Alarm Signalling over IP Revision: SIGNATORIES AS REQUIRED

Transcription

1 Specification Proposal: Alarm Signalling over IP Revision: Approved: Company Approved: Company Approved: Company Approved: Company ADD APPROVAL SIGNATORIES AS REQUIRED Date Position Date Position Date Position Date Position

2 Disclaimer The content of this document ( ) has been composed with great care. Experience however has learned us that even despite our carefulness it can occur that the information offered is out of date, incomplete or incorrect. Therefore we ask you to please check the website of VEBON, for the newest information. Liability VEBON is not responsible for any dammage (in-) directly caused by or related to the use of the information available in this document/ . " Revision History Revision Date Summary of Change By Draft 1 18/01/06 Initial revision DH Draft 2 10/03/06 Updated after first review DH Draft 3 16/06/06 Updated after second review DH /08/06 Updated after meeting at Enai on 22 nd August 2006 DH /09/06 Updated after several conversations KJO /09/06 Rearranged chapters and paragraphs KJO /09/06 Protocol version added to PPK_REP message KJO /01/07 Disclaimer edit KJO Page 2 of 42

3 Table of Contents 1. Scope Objective References Definitions Introduction Message Header Connection Handle Message ID Sequence Number Handling Device ID Message Layout Layout Setup messages Layout communication messages Layout path-check messages Data Encryption Communication Setup Setup sequence Step 1: ARC_ENC Step 2: PPK_COM Step 3: PPK_REP Step 4: ARC_ENC Setup message validation Sequence after communication setup Setup timing Path Supervision Supervision Message Formats Supervision Polling Message Formats Re-establish connection to force key exchange Path checking Path Check setup messages Path Check Poll messages Alarm Signalling Protocol Description Alarm Message Format Communication failure...29 APPENDIX A CRC Routine...30 APPENDIX B SHA1-256 METHOD...31 APPENDIX C PROTOCOL IDENTIFIERS...32 APPENDIX D ERROR CODES...36 APPENDIX E RSA Encryption...37 APPENDIX F AES Encryption...41 Page 3 of 42

4 1. Scope This document is published by, and is the responsibility of, the Vebon Group. The scope of this document is to describe the operation of a protocol for SIA alarm transmission over IP, using UDP, with a view to establishing a common working practice, throughout Europe, that complies with the current European and National standards for alarm transmission: The standards referenced are EN50131, EN50136 and BORG AL1 & AL2. This document s primary focus is to establish a message format and as such will not introduce any time constraints on the alarm reporting system as that is already covered within the relevant specifications. Page 4 of 42

5 2. Objective The objective is to achieve compatibility and inter-operability of alarm transmission where the transmission equipment and annunciation equipment of different equipment manufacturers is involved. Page 5 of 42

6 3. References Reference to: European Norms (EN50131 and EN50136) where applicable. BORG AL1 & AL2 AES Encryption: Federal Information, Processing Standards Publication 197, November 26, 2001 RFC US Secure Hash Algorithm 1 (SHA1) Page 6 of 42

7 4. Definitions Explanation of terms and definitions used in this standard ARC Alarm Receiving Centre ATE Alarm Transmission Equipment Page 7 of 42

8 5. Introduction This chapter introduces the different global aspects from the Vebon IP protocol Message Header Byte Index Bytes Description 0 2 Connection Handle ( 0xFFFF if not assigned yet) 2 1 Message ID (See section 5.1.2) 3 2 Sequence number 5 16 Device ID Connection Handle Some Internet Service Providers have inactivity timeouts and as such if the connection times out, then the module could be assigned a different IP address when the connection is re-established. This presents the ARC with the problem of trying to choose the correct key to use to decrypt messages coming from that particular ATE. To circumvent this each message will be prefixed by an unencrypted Connection Handle, assigned to it by the ARC. The connection handle will remain the same as long as the connection exists. This will also cater for installations that use network address translation, where the network behind the external interface is represented by one IP address and only the port numbers change. The connection handle will be contained with in the Message Header that will prefix every message. If there is no connection yet, e.g. connection setup scene, the connection id 0xFFFF should be used. A, by the receiver assigned, connection handle will be in range from [0x xFF00]. Connection handle value 0xFFFF will be used by the ATE in order to indicate that is needs a new connection. Connection handle value 0xFFFE could be used by the receiver, in order to inform the ATE that the connection could not be accepted. The receiver could also implement this information as a result code in the ARC_ENC message. Advantage is that this information is encrypted. Disadvantage, it takes a bit longer and the receiver needs more resources. ATE should implement both. Page 8 of 42

9 Message ID Message Name Description Size Encryp -ted Messa ge ID ATE_ENC Communication setup request (sent by ATE). This message is always ARC_ENC Communication setup response acknowledge (sent by the ARC). 258 N 0x Y RSA 0x81 PPK_COM PPK_REP PATH_SUPERVISION_ REQUEST ARC transmits it s public key to the ATE. ATE response with it s configuration and AES key. ATE request for supervision polling with an interval 258 N 0x Y AES 130 Y AES 0x82 0x10 PATH_SUPERVISION_ RESPONSE POLL MESSAGE ARC response. 130 Y AES ATE transmits a path supervision message 130 Y AES 0x90 0x11 POLL ACKNOWLEDGE ARC response to the path supervision message. 130 Y AES 0x91 PATHCHECK_REQUEST ATE request for path-checking 130 Y AES 0x20 PATHCHECK_ RESPONSE ARC response to pathcheck request. 130 Y AES 0xA0 PATHCHECK_POLL Path Check Poll message from ATE 8 N 0x21 PATHCHECK_ RESPONSE Path Check Poll response from ARC 8 N 0xA1 ALARM Alarm message from ATE. 130 Y AES ALARM_ACK Alarm response to ATE. 130 Y AES 0x30 0xB0 Page 9 of 42

10 Sequence Number Handling The sequence number is used to determine if a message is missing or duplicated. Both ends will have a transmit sequence number and a receive sequence number. A new initiated message has a new sequence number and the receiver will respond with the same sequence number. The connection setup scene will reset the sequence numbers. Most messages will be initiated by the ATE but some by the ARC. Every response message will have the same sequence number as the corresponding originator. The first transmitted message will have sequence number 1. If the sequence number is not as expected then a communication fail should be generated. If the sequence number is the previous number the message will be answered as usual but will not be passed 1 to processing part of the transmitter (this to prevent duplicated alarms). Thus a retry of a message should be sent with it s original sequence number. A message ID < 0x80 is a command by ATE or ARC and will increase the TXsequence number of the sender. The receiver should compare this with it s Rxsequence number. Message ID >= 0x80 is a reply on a command and this will increase the Rxsequence number of the receiver. On a fail of the sequence numbers the session needs to be restarted. Example sequence numbering: MSG ATE ARC TxSeq RxSeq TxSeq RxSeq ATE-ENC (tx) 1 0 ATE-ENC (rx) 0 1 PPKCOM (tx) 1 1 PPKCOM (rx) 1 1 PPKREP (tx) 1 1 PPRREP (rx) 1 1 Sup-Setup (tx) 2 1 Sup-Setup (rx) 1 2 Sup-Rsp (tx) 1 2 Sup-Rsp (rx) 2 1 Poll (tx) 3 1 Poll (rx) 1 3 Poll-Rsp(tx) 1 3 Poll-Rsp(rx) nd poll (tx) nd poll (rx) nd poll rsp (tx) nd poll rsp (rx) Previous sequence number may occur if the transmitter retried the message, because it did not receive a reply within certain time. Page 10 of 42

11 Device ID Device ID s are used to detect if the device you re communicating with did not change. The ATE can detect if the ARC is still the same and the ARC can detect if the ATE is still the same. Device ID s will only be transmitted encrypted over the connection. If ID s change this should result into a substitution alarm. E.g. ATE might sent a substitution alarm to the ARC via an alternative route and the ARC will generate internally a substitution alarm for the ATE. The DeviceID of the ATE, transmission equipment, is generated but must remain the same for that device. The best method could be to use the mac-address or usage of unique identifier hardware (such as a dallas chip). The DeviceID of the ARC receiver is a randomly generated ID that is unique within the receiver. So the receiver generates a unique DeviceID for each connected ATE Message Layout The Vebon IP protocol defines the following 3 types of messages: Setup messages. These are required to setup a connection and exchange encryption information. Communication messages. These messages are used to transmit alarms and path supervision messages (is the communication path end to end available?). Path check messages. These messages can be used in addition to the path supervision messages, with the difference that these are NOT encrypted and can only be used to detect a path/communication fail. Because these messages are not encrypted they can be used in a high speed, say seconds Layout Setup messages Byte Index Bytes Description 0 21 Message Header Message Data 205 bytes for communication setup bytes random padding and 2 bytes CRC 16 The size of these setup messages is always: 258 bytes. Page 11 of 42

12 Layout communication messages Byte Index Bytes Description 0 21 Message Header Message Data 77 bytes 30 bytes random padding and 2 bytes CRC or 32 bytes SHA1-256 hash (depending on CRC-mode). The size of these communication messages is always 130 bytes. During communication setup, the ATE informs the ARC about the message validation (CRC-16 or SHA1-256). For security reasons the message size, during communication, is always 130 bytes. This way it is not possible to detect the validation method by means of the message size. So if CRC-16 mode is used, there are always 30 random bytes before the actual CRC-16 value to occupy the same space in the message as the SHA1-256 data Layout path-check messages Byte Index Bytes Description 0 2 Connection Handle 2 1 Message ID 3 1 Random Character OR Error reason 4 2 Path Check ID 6 2 CRC-16 The size of these messages is always 8 bytes. NOTE: The path check message do not have the complete header (only the first 3 bytes of it). Page 12 of 42

13 6. Data Encryption Data Encryption for remote communications is mandatory at certain grades. The encrypted link exists between the ATE and the ARC. The encryption must use 128 bit Private Key Advanced Encryption Standard (AES) 2 for message data encryption and 1024 bit RSA (Public Key) for exchange of the AES Private Key. Initially the ATE is responsible for generating the AES Private Key. There will be a separate key for every connection 3 and a new key will be generated for each session on a path. A session is defined as either the duration of a UDP connection, or the duration of a stable end-to-end connection, as monitored by Path Supervision. Data Encryption is controlled by extended link set-up handshaking. During communication setup a Private Key is required, the ARC will issue its RSA Public Key to the ATE. The ARC will periodically change it s RSA key-pair. When the ATE receives the Private Key request message, it generates an AES Private Key, constructs a key message block containing this key and the Session Identifier, encrypts 4 the message block using the RSA Public Key, and the constant Public Exponent 5, and sends the resulting cipher to the ARC. The ARC then decrypts 6 the cipher to reveal the message block. The message block is considered valid if Session Identifier matches with the value sent in the Private Key request message. Both ends of the link now have the AES Private Key for encrypting and decrypting the subsequent data messages. 2 AES encryption functions can be found in appendix F. 3 If the ATE maintains multiple connections with different ARC s, than for each ARC there is a different key. The ARC will have a different key for each ATE. 4 Because RSA encryption with 1024 bits only encrypt 128 bytes, this encryption is executed 2 times first for byte 2 till 130 and second for byte 131 till RSA Public exponent and functions can be found in appendix E. 6 See note 1, decryption will also be done twice. Page 13 of 42

14 7. Communication Setup Communication will be setup by the ATE. If there is a communication fail, or a new ATE, communication needs to be setup with the receiver. The messages are used for this scene are shown in the diagram below. ATE ARC Application IP Stack IP Stack Application UDP set-up ATE-ENC PPKCOM PPKREP ARC-ENC Only sent if a session private key has not already been exchanged Send Alarm Data All subsequent messages encrypted under the session private key Figure 1: Communication setup 7.1. Setup sequence Steps: 1. ATE will transmit an UNENCRYPTED ATE_ENC message to the ARC. 2. ARC will respond with an UNENCRYPTED PPK_COM message, containing the public RSA key (1024 bits). 3. ATE will respond with an RSA ENCRYPTED PPK_REP message containing configuration information of the ATE and the AES key that will be used during the rest of the session. 4. ARC will respond to the ATE with the ARC_ENC indication if the connection is accepted or not. Page 14 of 42

15 Step 1: ARC_ENC ATE ARC Note: This message will be sent UNENCRYPTED. Byte Index Bytes Description Message Header: 0 21 Connection handle (0xFFFF) Sequence = 1 Device ID = random Session Identification number (will be 0) Random padding Random padding CRC-16 Checksum Step 2: PPK_COM ARC ATE Note: This message will always be sent UNENCRYPTED at the initialisation of a session. Byte Index Bytes Description Message Header 0 21 Connection handle, defined by the receiver. Sequence = 1 Device ID = random 21 2 Session Identification number (will be 0) bit RSA public key Random padding Random padding CRC-16 Checksum Page 15 of 42

16 Step 3: PPK_REP ATE ARC Byte Index Bytes Description 0 21 Message Header 21 1 Protocol Version Manufacturer id (string) Panel type (ASCII) 54 8 Panel version (ASCII) 62 6 Account code (6 ASCII digits: ) 68 1 CRC-mode ( 01 = CRC-16, 02 = SHA-1) 69 2 Session Identification number (non-zero, it s encrypted now) Private Key Message Block (128-bit AES) Random padding Random padding CRC Checksum Sequence number = 1 The Key Message Block is contained in the PPKREP message and has the following format: Byte Index Bytes Description 0 1 Version set to 0x AES Private Key 7 Protocol version set to 1 Page 16 of 42

17 Step 4: ARC_ENC ARC ATE Byte Index Bytes Description 0 21 Message Header 21 1 Error Code* n Session Identification number (must match value of PPK_REP message) Random padding chars to take message length up to a multiple of 16 bytes CRC Checksum Sequence number = 1 *Error code could be: ERR_SUCCESS ERR_PROTOCOL_VERSION_NOT_SUPPORTED ERR_PPK_BLOCK_VERSION_NOT_SUPPORTED ERR_CRC_MODE_NOT_SUPPORTED ERR_ACCOUNT_CODE_NOT_ALLOWED ERR_CONNECTION_NOT_ALLOWED 8 8 This value could be used by the ARC receiver if the information (receiver full) needs to be encrypted. Otherwise the receiver might sent a dummy PPK_COM with connection handle 0xFFFE. ATE should support both ways. Page 17 of 42

18 7.2. Setup message validation During the setup, the ATE will inform the ARC about the method of message validation (CRC16 or SHA-1 (256bits)). Before this information has taken place CRC16 is used to validate the setup message Sequence after communication setup If the communication setup is finished, the ATE can send any kind of messages. With only a few restrictions: 1. If supervision is enabled, then supervision setup must be sent within 60 seconds of the communication setup. So high priority alarms might be transmitted first. After 60 seconds the connection will be terminated for an ARC that demands supervision. 2. If path checking is enabled, the ATE must FIRST setup supervision. Otherwise patch checking will NOT be accepted Setup timing The communication setup needs to be completed within 30 seconds. Therefore, the ATE will wait 30 seconds after transmitting the ATE_ENC for the ARC_ENC response and the ARC will wait 30 seconds after transmission of PPK_COM for the PPK_REP message. Page 18 of 42

19 8. Path Supervision Path Supervision uses the same host port number as setup and alarm message. This is required because the receiver must be able to detect a line/route failure. A line failure could be caused by an interruption of the network. A route failure might be a sabotage of network equipment such as blocking the alarm port on a firewall. A Path Identification Value is included in every Path Supervision message to identify individual monitored paths. Each Path Supervision message has Path Identification Code to uniquely identify the ATE to the ARC, independently of account number. Path Supervision is started following initial communication between the ATE and an ARC. Following the initial exchange, the ATE issues a Path Supervision Request message to inform the ARC that Path Supervision is required and the selected polling period. The ARC then issues an acknowledgement of the request. If the ARC does not support Path Supervision, or Path Supervision at the rate requested is not supported, then the Path Supervision Response will contain the corresponding error code. In this case the ATE will indicate a heartbeat failure on the associated link. If the rate is not supported, then the supported polling rate will be returned in the Path Supervision Response, the ARC will generate a configuration error message such as polling too slow or polling to fast, the ARC will NOT terminate the connection. Heartbeat failure might be indicated by the ATE. Application ATE IP Stack IP Stack ARC Application Path Supervision Request Path Supervision Response Response Figure 2: Initiation of Path Supervision Response sent if ARC accepts Path Supervision The ATE issues a heartbeat Poll Message to the ARC at a rate determined by the polling period. To allow for communications latency and asynchronous timekeeping, the ARC allows a tolerance beyond the end of the polling period before an error is reported. If the polling period is less than 300 seconds, the heartbeat can be accepted up to 20 seconds late otherwise (greater or equal to 300 seconds), the heartbeat can be up to 1 minute late. This may be used to satisfy the monitoring of the alarm transmission system up to T5, as per Table 4 in EN In order to achieve the T6 rate, the path checking 9 method should be used as an addition to the path supervision. 9 See chapter 9 path checking Page 19 of 42

20 When the ARC receives the heartbeat Poll Message, it issues a Poll Acknowledgement and resets its polling window timer. When the ATE receives the Poll Acknowledgement it restarts its timer for the next heartbeat. Application ATE IP Stack IP Stack ARC Application Poll Message (heartbeat) Poll Acknowledge Figure 3: Path Supervision Poll ARC resets polling window when Poll Message received. In response to error conditions the ATE and ARC will post messages in accordance with the standards Page 20 of 42

21 8.1. Supervision Message Formats The Path Supervision Request message is encapsulated in a datagram with the format: ATE ARC Byte Index Bytes Description 0 21 Message Header 21 2 Path Identification Code 23 4 Heartbeat Time seconds ( >= 60 seconds) Random padding chars to take message length up to a multiple of 16 bytes byte Padding + CRC Checksum or SHA-1 The Path Supervision Response message is encapsulated in a datagram with the format: ARC ATE Byte Index Bytes Description 0 21 Message Header 21 1 Error Code* (See Appendix D for values) 22 2 Path Identification Code (must match value in Path Sup. Request) 24 4 Heartbeat Time seconds Random padding byte padding + CRC Checksum or SHA-1 *Error code could be: ERR_SUCCESS ERR_SUPERVISION_NOT_SUPPORTED ERR_SUPERVISION_REQUEST_TOO_FAST ERR_SUPERVISION_REQUEST_TOO_SLOW Page 21 of 42

22 8.2. Supervision Polling Message Formats The Poll Message is encapsulated in a datagram with the following format: ATE ARC Byte Index Bytes Description 0 21 Message Header 21 2 Path Identification Code (must match value in Path Sup. Request) Random padding byte padding + CRC Checksum or SHA-1 The Poll Acknowledge is encapsulated in a datagram with the following format: ARC ATE Byte Index Bytes Description 0 21 Message Header 21 1 Error Code * (See Appendix D for values) 22 2 Path Identification Code (must match value in Request) Random padding byte padding + CRC Checksum or SHA-1 *Error code could be: ERR_SUCCESS ERR_SUPERVISION_NOT_SUPPORTED ERR_REESTABLISH_CONNECTION See 8.3 Page 22 of 42

23 8.3. Re-establish connection to force key exchange For connections that last long, it might be desired to change the encryption key. Connections will be maintained by path supervision polling. Therefore the error-reason in the Path Supervision Poll Response will be used to indicate the ATE that the connection should be re-established (starting with the unencrypted ATE_ENC on connection ID 0xFFFF). This will ensure that a new AES key is exchanged with the new RSA public key. The ARC will set this result code into the path supervision response message only if the connection was not re-established for another reason and lasted for more than days. (Programmable in the receiver). It is the responsibility of the ATE to start with the new ATE_ENC. Page 23 of 42

24 9. Path checking In order to achieve the higher monitoring rates as specified in Table 4 of EN , there is a requirement for a high speed, low overhead, message that can be used in conjunction with the Path Supervision messages. Typically this requires one successful path check every 20 seconds. This would also be subject to the tolerances mentioned in section 8.1 above. The proposal therefore is to use a simplified Path Supervision protocol and allow a polling interval of 10 seconds for the path checking message, with the recipient allowing it to be up to 5 seconds late. If the ARC supports Path Checking then it will respond to the Path Check Request with the Path Check Accept. The ATE will then send out the first Path Check command. If either the ARC or the ATE do not receive the Path Check message within the allotted time, then the appropriate fault messages will be generated. This path checking also uses the same host port number as path supervision and alarm messaging. Path checking will be used in addition to path supervision. The major purpose of Path checking is to detect a communication line failure and will therefore ONLY generate an device OFFLINE alarm and never a restore. The restore can only be given by a successful supervision polling or communication setup. If path checking is required, the supervision setup MUST be done before. Page 24 of 42

25 9.1. Path Check setup messages The Path Check Request is encapsulated in a datagram with the following format: ATE ARC Byte Index Bytes Description 0 21 Message header Padding chars (random) byte padding + CRC Checksum or SHA-1 The Path Check Accept is encapsulated in a datagram with the following format ARC ATE Byte Index Bytes Description 0 21 Message header 21 1 Error Code* 22 1 Path Check ID Padding chars (random) byte padding + CRC Checksum or SHA-1 *Error code could be: ERR_SUCCESS ERR_PATHCHECK_NOT_SUPPORTED Page 25 of 42

26 9.2. Path Check Poll messages The Path Check Message is encapsulated in a datagram with the following format: ATE ARC Byte Index Bytes Description 0 2 Connection Handle 2 1 Message ID 0x Random Character 4 2 Path Check ID 6 2 CRC-16 The Path Check Acknowledge is encapsulated in a datagram with the following format ARC ATE Byte Index Bytes Description 0 2 Connection Handle 2 1 Message ID 0xA1 3 1 Error Code* 4 2 Path Check ID 6 2 CRC-16 *Error code could be: ERR_SUCCESS ERR_PATHCHECK_NOT_SUPPORTED Page 26 of 42

27 10. Alarm Signalling With Alarm Signalling the ATE sends the Alarm data when it is received from the panel. The Alarm data is transmitted in a single datagram which is acknowledged by the SIA End-Point ATE ARC Application IP Stack IP Stack Application udp_open Alarm Message (single Datagram) bind Alarm Ack Figure 4: Basic UDP Alarm Signalling Sequence Protocol Description All messages have a corresponding response to acknowledge receipt message sequence numbers are used to match acknowledgements with messages Alarm Message Format The Alarm/Event Message has the following format: ATE ARC BYTE Index Bytes Description 0 21 Message header 21 1 Protocol Identifier: 01 = SIA (Refer to Appendix C for definition and message layout) 22 1 Length of alarm data (L) L L (length of data) 98 (23 + L) <SIA Account Block><SIA Event Block><SIA ASCII Block> Random padding byte random padding + CRC Checksum or SHA-1 Page 27 of 42

28 Alarm/Event Response Format: ARC ATE Byte Index Bytes Description 0 21 Message Header 21 1 Error Code* (See Appendix D for values) Random padding byte padding + CRC Checksum or SHA-1 *Error code could be: ERR_ACKNOWLEDGE ERR_NEGATIVE_ACKNOWLEDGE ERR_ARC_COULD_NOT_PROCESS_MESSAGE ERR_PROTOCOL_ID_NOT_SUPPORTED Page 28 of 42

29 11. Communication failure There are several ways for the ATE and ARC to detect communication failure s. Most errors will be cause by network troubles or congestion. If path checking is enabled (every seconds a message) this detection is much faster (20 sec to the ARC) than with normal polling (fastest at max. 60 sec sec = 80 sec). The difficulty is that these communication failures cannot be distinguished from sabotage. In order to prevent a very heavy load on the receiver side and the risk of real alarms coming through late the ATE must handle the following reconnection scene after a communication fail. We distinguish 2 situations: 1) ATE has a real alarm (other than periodic test and line fault report). 2) ATE has no real alarm (no alarm, periodic test message or a line error report with the ARC) In the first situation the ATE is allowed to connect directly with the ARC and should keep trying this until it has transmitted it s alarms (if there is no other communication route available). In the seconds situation, the ATE should try to reconnect en should keep trying it but every time with a randomly chosen interval between 60 seconds and 300 seconds. If a real alarm situation occurs, the ATE is allowed to switch to the above scene. Page 29 of 42

30 APPENDIX A CRC Routine The following is a possible CRC routine that could be used for the IP messages, written in C. /*********************************************************************/ /* Function : calculate_crc */ /* */ /* Parameters : ptr - pointer to the data to be processed */ /* count - byte length of the data */ /* */ /* Returns : crc value */ /* */ /* Purpose : This function calculates a CRC of the supplied data.*/ /* */ /*********************************************************************/ UINT16 calculate_crc (char *ptr, UINT16 count) { #define CRC16_SEED 0x1021 UINT16 crc; UINT8 i; crc = 0; while (count-- > 0) { crc = crc ^ ((UINT16)*ptr++ << 8); for (i = 0; i < 8; i++) { if (crc & 0x8000) { crc = crc << 1 ^ CRC16_SEED; } else { crc = crc << 1; } } } return (crc); } Page 30 of 42

31 APPENDIX B SHA1-256 METHOD Source can be derived from: Usage example: SHA1_256 Calculation example: // psha must point to a 32 byte character array where the SHA hash will be placed in. static void CalculateSHA1_128 ( unsigned char *pdata, unsigned char *psha ) { unsigned char SHA1[32]; SHA256_CTX sha; unsigned char *ptocalculate = &pdata[2]; // Skip connection handle memset (SHA1, 0, sizeof (SHA1)); sha256_init (&sha); sha256_update (&sha, ptocalculate, 256); sha256_final (&sha, SHA1); } memcpy ( psha, SHA1, 32); Page 31 of 42

32 APPENDIX C PROTOCOL IDENTIFIERS The protocols listed below, other than SIA are suggestions only and have yet to be ratified, but give and indication of what would be possible. 01: SIA 02: Ademco Contact ID 03: Scancom 04: SIA-HS 05.. xx not defined!!! 01: SIA layout: The following SIA blocks must be present into an alarm message with the SIA protocol identifier: # Account block N New event block, OR O OLD event block. Additional the message may contain the following block: A ASCII text. If the combination: #N, #O, #NA, #OA is present in the alarm message, the message will be acknowledged by the receiver. The message header byte and the column parity will NOT be included in the SIA message format to the ARC, the message is already validated at the ATE side and the integrity of the message is guaranteed by the SHA1-256 hash (or the CRC-16). Other block like: & (origin), L (listen in), X (configuration) etc may (in addition to the above mentioned blocks) exists in the message but will not necessarily be processed by the receiver. Blocks will be separated by a sign. Thus a valid message will look like: #1234 NCL001 AVebonMember #1234 OBA012 AFrontdoor All modifiers and textual additions as specified in SIA DC (R ) may occur in the event block. Page 32 of 42

33 02: Ademco Contact ID The Ademco Contact ID messages, sometimes called POINT ID, have the following layout between ATE and ARC: AAAAMTQXYZGGCCC Where: AAAA = Account code [4..6] digits MT = Message type (18 or 98) Q = Qualifier, value 1, 3 or 6 XYZ = Event code GG CCC = Group number = Zone number The if the length of the message is within range: [15..17] and the MT equals 18 or 98. The account code must be 4 digits long minimum and 6 digits max. Account code digits must be in the range [ ] (0x30..0x39). Message type and Qualifier have fixed values as defined above. All other digits must be in the range: [ B.. F ] The checksum value should NOT be present in the message Account 1234 is reporting a Perimeter Burglary Alarm on Zone 15 of Partition 1. The length of the account code [4, 5, or 6 digits] will be determined by the total message size. Page 33 of 42

34 03: Scancom Fast format The scancom fast format message can contain 8, 16 or 24 channels and also 1 up to 6 account digits. The correct format can be determined by the receiver just by checking the length of the received message size. Layout of 8 channels scancom message: AAAACCCCCCCCS Where: AAAA = Account code C = Status of the channel (value s: 1, 2, 3, 4, 5, 6). S = System channel (value s: 7, 8, 9). The account code can vary between decimal digits. The number of channels can be: 8, 16 or 24. The system channel is always 1 digit. The length of an 8 channels message than can be: 10 up to 15 digits. The length of a 16 channels message than can be: 18 up to 23 digits. The length of a 24 channels message than can be: 26 up to 31 digits. All bytes must be in the range: The receiver will acknowledge the message if the size is expected (within the above values) and all bytes have the values in the correct range: Page 34 of 42

35 04: SIA HS: SIA HS is defined by Alphatronics as an alternative to SIA. Some SIA event codes have another meaning in HS than in normal SIA. Therefore a special protocol identifier is used to distinguish between SIA and SIA HS. The layout of the message part also differs. A SIA HS message will always start with: AAAANEE Where: AAAA = Account code 4 digit ( ) account code. N = New event (only N ). EE = SIA HS event code ( AA.. ZZ ). = See below.. Can be: 1) nothing Only event is given. 2) 16 characters text information. Event and text info 3) ZZ,SECTION^S^^^^^^^,[S[sss]] where ZZ is the zone field (2, 3 or 4 digits) (or user field, depending on the event code) and Section S 11 defines the area, [S[sss]] can also define the area (1 up to 4 areas). 4) ZZ,Text^Info.^^^^^^,[S[sss]] Like above only tekst information added. 5) ZZ,UU,Text^info.^^^^^^,[S[sss]] Like above only now an additional userfield (2, 3 or 4 digits) is added. 11 Area s are numbered from A.. Z as area and for number and 0 for area 36. Page 35 of 42

36 APPENDIX D ERROR CODES // Default error if all went okay #define ERR_SUCCESS 0x00 // Error reasons that could be sent into: // MSG_ID_ALARM_REPLY #define ERR_ACKNOWLEDGE #define ERR_NEGATIVE_ACKNOWLEDGE #define ERR_ARC_COULD_NOT_PROCESS_MESSAGE #define ERR_PROTOCOL_ID_NOT_SUPPORTED 0x01 0x02 0x03 0x04 // Error reasons that could be sent into: // MSG_ID_ARC_ENC #define ERR_PROTOCOL_VERSION_NOT_SUPPORTED #define ERR_PPK_BLOCK_VERSION_NOT_SUPPORTED #define ERR_CRC_MODE_NOT_SUPPORTED #define ERR_ACCOUNT_CODE_NOT_ALLOWED #define ERR_CONNECTION_NOT_ALLOWED 0x05 0x06 0x07 0x08 0x0D // Error reasons that could be sent into: // MSG_ID_SUPERVISION_SETUP_REPLY & // MSG_ID_SUPERVISION_POLL_REPLY #define ERR_SUPERVISION_NOT_SUPPORTED 0x09 // Error reasons that could be sent into: // MSG_ID_SUPERVISION_SETUP_REPLY #define ERR_SUPERVISION_REQUEST_TO_FAST #define ERR_SUPERVISION_REQUEST_TO_SLOW 0x0A 0x0B // Error reasons that could be sent into: // MSG_ID_PATHCHECK_SETUP_REPLY & // MSG_ID_PATHCHECK_POLL_REPLY #define ERR_PATHCHECK_NOT_SUPPORTED 0x0C // Special response reason on: MSG_ID_SUPERVISION_POLL_REPLY // This result code tells the ATE to re-establish the connection // from scratch (starting with the unencrypted ATE_ENC) #define ERR_REESTABLISH_CONNECTION 0x80 #define ERR_UNKNOWN 0xFF Page 36 of 42

37 APPENDIX E RSA Encryption For the RSA encryption/decryption the BIGDIGITS library is used: /******************** COPYRIGHT AND LICENCE NOTICE ******************** This source code is part of the BIGDIGITS multiple-precision arithmetic library Version 2.1 originally written by David Ireland, copyright (c) D.I. Management Services Pty Limited, all rights reserved. You are permitted to use compiled versions of this code at no charge as part of your own executable files and to distribute unlimited copies of such executable files for any purposes including commercial ones provided you agree to these terms and conditions and keep the copyright notices intact in the source code and you ensure that the following characters remain in any object or executable files you distribute AND clearly in any accompanying documentation: "Contains BIGDIGITS multiple-precision arithmetic code originally written by David Ireland, copyright (c) by D.I. Management Services Pty Limited < and is used with permission." David Ireland and DI Management Services Pty Limited make no representations concerning either the merchantability of this software or the suitability of this software for any particular purpose. It is provided "as is" without express or implied warranty of any kind. Our liability will be limited exclusively to the refund of the money you paid us for the software, namely nothing. By using the software you expressly agree to such a waiver. If you do not agree to the terms, do not use the software. Please forward any comments and bug reports to < The latest version of the source code can be downloaded from < Last updated: 19 August *************** END OF COPYRIGHT AND LICENCE NOTICE ******************/ Page 37 of 42

38 The following functions will help to generate a private and public key-pair and encrypt/decrypt the messages: // #define PK_BITS 1024 // // Public exponent is required for KEY generation // // Default public exponent... // DIGIT_T npublicexponent[32] = { // Fermat Primes... 3, 5, 17, 257, 65537, // Fibonacci primes 2, 3, 5, 13, 89, 233, 1597, 28657, , , , // Kynea primes 7, 23, 79, 1087, 66047, , , , // Lucas primes 11, 29, 47, 199, 521, 2207, 3571, 9349 }; // 32 primes... // // Public exponent should match the value with the receiver!!!!! // void E_RSA_SetPublicExponent ( DIGIT_T *ppublicexponent ) { WORD nmoddigitsize = ( ( PK_BITS - 1 ) / ( sizeof ( DIGIT_T ) * 8 ) ) + 1; int i; mpsetzero( ( DIGIT_T * )npublicexponent, nmoddigitsize ); } for ( i = 0; i < nmoddigitsize; i++ ) npublicexponent[i] = ppublicexponent[i]; Page 38 of 42

39 // // Decode a message block with the sizeof 256 bytes... // Function called by the ARC to decrypt the PPK_REP message. // BOOL E_RSA_DecodeMessageBlock256( DIGIT_T *psourcemessageblock, DIGIT_T *presultmessageblock, DIGIT_T *ppublickey, DIGIT_T *pprivateexponent ) { WORD nmoddigitsize = ( ( PK_BITS - 1 ) / ( sizeof ( DIGIT_T ) * 8 ) ) + 1; // Decrypt 1st part... mpmodexp( &presultmessageblock[ 0], &psourcemessageblock[ 0], pprivateexponent, ppublickey, nmoddigitsize ); // Decrypt 2nd part... mpmodexp( &presultmessageblock[32], &psourcemessageblock[32], pprivateexponent, ppublickey, nmoddigitsize ); } return ( TRUE ); Page 39 of 42

40 // // Encode a message block with the sizeof 256 bytes... // // This function will only be used by the ATE. No need // to call: E_RSA_SetPublicExponent because the exponent will // be passed as a parameter to this function. // // Function called by the ATE to encrypt the PPK_REP mesage. // BOOL E_RSA_EncodeMessageBlock256( DIGIT_T *psourcemessageblock, DIGIT_T *presultmessageblock, DIGIT_T *ppublickey, DIGIT_T *ppublicexponent ) { WORD nmoddigitsize = ( ( PK_BITS - 1 ) / ( sizeof ( DIGIT_T ) * 8 ) ) + 1; // E_RSA_SetPublicExponent ( ppublicexponent ); // Encrypt 1st part mpmodexp( &presultmessageblock[ 0], &psourcemessageblock[ 0], npublicexponent, ppublickey, nmoddigitsize ); // Encrypt 2ndt part mpmodexp( &presultmessageblock[32], &psourcemessageblock[32], npublicexponent, ppublickey, nmoddigitsize ); } return ( TRUE ); Page 40 of 42

41 APPENDIX F AES Encryption #define NB_128_BIT 4 #define NK_128_BIT 4 #define ROUNDS_128_BIT 10 void E_AESDecryptData128(BYTE* data, BYTE *privatekey) { AESexpandKey(expanded_key, privatekey, NB_128_BIT, NK_128_BIT, ROUNDS_128_BIT); AESdecrypt(&data[ 0], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[ 16], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[ 32], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[ 48], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[ 64], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[ 80], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[ 96], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[112], expanded_key, NB_128_BIT, NK_128_BIT); } void E_AESDecryptData256(BYTE* data, BYTE *privatekey) { AESexpandKey(expanded_key, privatekey, NB_128_BIT, NK_128_BIT, ROUNDS_128_BIT); AESdecrypt(&data[ 0], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[ 16], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[ 32], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[ 48], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[ 64], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[ 80], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[ 96], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[112], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[128], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[144], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[160], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[176], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[192], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[208], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[224], expanded_key, NB_128_BIT, NK_128_BIT); AESdecrypt(&data[240], expanded_key, NB_128_BIT, NK_128_BIT); } Page 41 of 42

42 void E_AESEncryptData128 (BYTE *data, BYTE *privatekey) { AESexpandKey(expanded_key, privatekey, NB_128_BIT, NK_128_BIT, ROUNDS_128_BIT); AESencrypt(&data[ 0], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[ 16], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[ 32], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[ 48], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[ 64], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[ 80], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[ 96], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[112], expanded_key, NB_128_BIT, NK_128_BIT); } void E_AESEncryptData256 (BYTE *data, BYTE *privatekey) { AESexpandKey(expanded_key, privatekey, NB_128_BIT, NK_128_BIT, ROUNDS_128_BIT); AESencrypt(&data[ 0], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[ 16], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[ 32], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[ 48], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[ 64], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[ 80], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[ 96], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[112], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[128], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[144], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[160], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[176], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[192], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[208], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[224], expanded_key, NB_128_BIT, NK_128_BIT); AESencrypt(&data[240], expanded_key, NB_128_BIT, NK_128_BIT); } Page 42 of 42