SECURE PEER-TO-PEER COMMUNICATION PROTOCOL

Description

Field

[0001] The present disclosure relates to a method of communicating between components and a secure peer to peer communication protocol for inter-processor communications. The present disclosure is particularly relevant to encrypted point-to-point communications within vehicle E / E architectures.Background

[0002] There currently do not exist any standard solutions for authenticated encrypted reliable point-to-point communication between processors on a single PCB or, more generally, within a single device. Such entities are often communicated via media such as Serial Peripheral Interface (SPI), universal asynchronous receiver-transmitter (UART) or similar and either receive no protection at all or are protected with ad-hoc custom solutions, such as encrypting messages using a block cipher in an unauthenticated mode with an appended message authentication code (MAC).

[0003] However, unprotected communication leaves systems vulnerable to allowing attackers with physical access to the device to intercept, modify and retransmit traffic, resulting in extraction of secrets, reverse engineering of device functions and serving as a steppingstone to mount more complex attacks. This is particularly a concern in automotive applications because modern vehicles' electronic control systems play a crucial role in safety, as well as often communicating data to central servers.

[0004] Currently, ad-hoc solutions built upon block ciphers in unauthenticated modes are used in some circumstances. However, MAC codes carry the risk of misapplication of cryptographic primitives, resulting in protocol weaknesses that can be efficiently attacked (e.g. random or pseudo-random number reuse or using the same key for encryption and for authentication). For example, some proposed techniques reuse session keys for both encryption and MAC, which leaves communications vulnerable to attack. At the same time, there is no connection reliability guarantees. As such, any lost messages are not automatically retransmitted and are simply lost.

[0005] Accordingly, there remains a need to address the above shortcomings in communications.

[0006] United States Patent Application US 2015 / 113275 discloses tamper-resistant and scalable mutual authentication for machine-to-machine devices.

[0007] European Patent Application EP 1865656 provides a method of securely connecting a first device to a second device using a third party authentication server coupled to the second device.Summary

[0008] According to a first aspect, there is provided a method for securely transmitting data between at least a first and second processing unit, according to claim 1.

[0009] In this way, a method for secure inter-processor communication may be provided, such as communication between processing units within a single printed circuit board or electronic control unit using simple serial links such as UART or SPI. Advantageously, by provisioning each processing unit with the Shared Secure Key, fast establishment of session keys may be achieved, even when using low performance microcontrollers. This thereby allows for a secure communication link to be established quickly (e.g. within 10s of milliseconds) after power up. Moreover, in the arrangement, both processing units are equivalent peers, and hence the protocol may be implemented without the concept of a client and server.

[0010] According to a second aspect, there is provided a first processing unit for secure communication with a second processing unit, according to claim 9.

[0011] According to a third aspect, there is provided non-transient computer readable medium comprising instructions which, when executed by a processor, implement a method according to claim 13.

[0012] Optional features are set out in the dependent claims.Brief Description of Drawings

[0013] Illustrative embodiments will now be described with reference to the accompanying drawings in which: Figure 1 shows a schematic illustration of a mutual authentication sequence according to a first embodiment; and Figure 2 shows the authentication state machine for the sequence shown in Figure 2. Detailed Description

[0014] The present invention concerns a secure peer to peer communication protocol for inter-processor communications. The protocol includes two phases of operation. In a first, authentication, phase the peers establish session keys and authenticate each other. This authentication phase is shown in Figures 1 and 2. In a second phase, the peer-to-peer communications are established for exchanging data. In this data exchange phase, the protocol uses an Authenticated Encryption with Associated Data (AEAD) scheme to provide authenticity, integrity and confidentiality guarantees.

[0015] In this connection, communications are transmitted using a plurality of frames, with each frame designating an outer protocol unit that includes the fields related to encryption and authentication. Each frame contains a packet representing an inner protocol unit that is transmitted in an encrypted form within AEAD frames.

[0016] The procedure is implemented between two peer devices, identified as A and B in Figure 1. Both devices are provided during manufacturing with a Shared Symmetric Key (SSK).

[0017] In the authentication phase, A sends an AUTH_CHALLENGE frame to B. This authentication frame contains a 128-bit random number, CHALLENGE A→B . B also sends an AUTH_CHALLENGE frame to A, containing a 128-bit random number, CHALLENGE B→A . A and B both have different 4-byte node identifiers (IDs), ID A and ID B , which are also provided to each other during manufacture.

[0018] The node IDs may be configured statically during compiling. If AES-GCM is used as the AEAD cipher, then the fixed field value that is used in the Initialisation Vector (IV) construction may also be used as a Node ID. The Node ID values are different for each Processing Unit in the link. The Node IDs are used to prevent reflection attacks during the authentication phase by ensuring that the keys K VRFY (B) and K SIGN (B) are different, even if an attacker were to reflect A's challenge frame back to A. They also ensure that data encryption keys in both directions are different in the unlikely case that the challenges generated by both A and B are identical.

[0019] A uses (IDA ∥ IDB ∥ CHALLENGE A→B ∥ _CHALLENGEwhere ∥ denotes concatenation, and a KDF keyed with SSK to derive a session key for reception from B and an ephemeral authentication key for challenge response verification from B: K VRFY (B):key for verifying challenge response from B. K DEC (B):key used to decrypt frames from B.

[0020] A uses (IDB ∥ IDA ∥ CHALLENGE B→A ∥ CHALLENGE A→B ) and a KDF keyed with SSK to derive a session key for transmission to B and an ephemeral authentication key for challenge response calculation to B: K SIGN (B) :key for generating challenge response to B. K ENC (B):key used to encrypt frames to B.

[0021] B uses (IDB ∥ IDA ∥ CHALLENGE B→A ∥ CHALLENGE A→B ) and a KDF keyed with SSK to derive a session key for reception from A and an ephemeral authentication key for challenge response verification from A: K VRFY (A):key for verifying challenge response from A. K DEC (A):key used to decrypt frames from A.

[0022] The keys K VRFY (A) and K DEC (A) derived by B are the same as the keys K SIGN (B) and K ENC (B), respectively, derived by A for transmission to B.

[0023] B uses (IDA ∥ IDB ∥ CHALLENGE A→B ∥ CHALLENGE B→A ) and a KDF keyed with SSK to derive a session key for transmission to A and an ephemeral authentication key for challenge response calculation to A: K SIGN (A):key for generating challenge response to A. K ENC (A):key used to encrypt packets to A.

[0024] These keys K SIGN (A) and K ENC (A) derived by B are the same as the keys K VRFY (B) and K DEC (B), respectively, derived by A for reception from B.

[0025] B sends an AUTH_RESPONSE frame to A. It contains unencrypted RESPONSE B→A ← CMAC (K SIGN (A),CHALLENGEA→B).

[0026] A verifies B using the RESPONSE B→A contained in the AUTH_RESPONSE frame sent by B. Verification is performed by comparing if the received CMAC contained therein matches a corresponding CMAC generated from the first authentication challenge frame using the corresponding K VRFY (B) (i.e. RESPONSE B→A = CMAC (K VRFY (B),CHALLENGE A→B )).

[0027] If the verification succeeds, then host A trusts the identity of host B (A trusts that B knows the SSK). A sends an AUTH_RESPONSE frame to B. It contains unencrypted RESPONSE A→B ← CMAC (K SIGN (B),CHALLENGE B→A ).

[0028] B similarly verifies A by comparing if the received CMAC contained therein matches a corresponding CMAC generated from the first authentication challenge frame using the corresponding K VRFY (A) (i.e. RESPONSE A→B (CMAC (K VRFY (A), CHALLENGE B→A ). If the verification succeeds, then host B trusts the identity of host A (B trusts that A knows the SSK).

[0029] During the authentication phase, the processing units are configured to implement a timeout procedure. For example, after generating an AUTH _CHALLENGE in response to a received AUTH _CHALLENGE frame, a processing unit shall start an anti-scanning timeout of an implementation-defined, randomized length, but not shorter than, for example, 1 second. The purpose of this timeout is to protect the entropy of the RNG and to prevent potential brute-force attacks against the key generation algorithm. The random component of this timeout will ensure that in case challenges pass each other "in the wire", while the peers have different understanding of which challenges are valid, the challenges will eventually desynchronize and the authentication will get unblocked. A particular host processing unit will inhibit sending new AUTH _CHALLENGE frames until the anti-scanning timeout has elapsed. If a host does not receive an AUTH_CHALLENGEframe within an implementation-defined timeout after sending its own challenge, it shall generate and send a new challenge. If a host does not receive an AUTH _RESPONSE frame within an implementation-defined timeout, it shall discard all authentication data, such as challenges both sent and received, and start anew by sending a freshly-generated AUTH_CHALLENGE. The challenge and response timeout durations shall be set longer than the anti-scanning timeout to avoid blocking session establishment due to inability of peers to respond to each other before challenge and response timeouts expire. If a host receives an AUTH _RESPONSE frame without receiving a prior AUTH _CHALLENGE frame, it can be identified as an indication that the AUTH _CHALLENGE frame was sent by the peer and lost (among other reasons, it is possible that the receiving party was not ready to receive yet). When this happens, the host shall reset the authentication state machine, wait for the anti-scanning timeout to elapse and start anew by sending a freshly-generated AUTH_CHALLENGE. It is possible that the response timeout on the peer will expire before the anti-scanning timeout on the host - in that case the peer will be the first to send a new AUTH_CHALLENGE. A host receiving a new AUTH_CHALLENGEframe while expecting an AUTH _RESPONSE frame shall discard all authentication data, accept the new challenge and respond with its own fresh AUTH_CHALLENGE followed by an AUTH_RESPONSE, provided that the anti-scanning timeout has elapsed.

[0030] Once the authentication phase has completed and both peer processing units are verified, data frames may then be transmitted between them using the respective first and second session keys. The data frames are constructed in such a way, that their LEN and FRAME ID fields are authenticated by the AEAD protocol but not encrypted, thus achieving confidentiality, integrity and authenticity for DATA frames, while providing plaintext visibility compatible with frame types not requiring AEAD encryption such as AUTH _CHALLENGE and AUTH_RESPONSE.

[0031] On initialising communications, a first peer device out of A and B will initiate a new key exchange when the number of AEAD scheme invocations with a given key approaches a defined maximum value. The first peer will then stop using keys and close the session when the number of AEAD scheme invocations reaches the defined maximum value. For AES-GCM the maximum number of invocations is not larger than 2 30< , although the implementation may be configured to perform re-keying earlier. This satisfies the cryptographic requirements for the AES-GCM scheme in the selected configuration of Initialization Vector (IV) length and construction, key length and tag length.

[0032] The above said, re-keying shall not reset the sequence and acknowledge numbers, as it would introduce ambiguity in case there are packets pending for retransmission or unacknowledged. Instead, the transmitter increments the SEQ number with each new packet transmitted, except for ACK_ONLY packets. The sequence and acknowledge numbers shall not roll over into the MSb. The receiver shall drop a packet that carries a SEQ number different from the expected number and respond with a packet with the NACK bit set. The transmitter shall buffer the packets sent and wait for their acknowledgement. A packet shall be considered acknowledged, if a packet carrying ACK number equal to or greater than its SEQ number is received.

[0033] The transmitter shall retransmit unacknowledged packets. The size of the queue of packets waiting for acknowledgement is application-specific and, in this embodiment, has no maximum length defined at the protocol level and has a minimum length of one packet. The number of packets that can be sent without receiving an acknowledgement shall be configured in accordance with the buffering capability of the receiver processing unit.

[0034] When retransmitting unacknowledged packets, the transmitter shall update the ACK number they carry to reflect the most recent SEQ number received. A host that has no data to send shall acknowledge packets using an ACK_ONLY packet. The SEQ number in ACK_ONLY packets shall remain the same as used in the preceding packet. No ACK_ONLY packets shall be sent in response to ACK_ONLY packets. The DATA field in ACK_ONLY packets shall be empty. ACK_ONLY packets shall have the PKT_ID field set to 0x0000.

[0035] The processing unit transmitting packets may cease to retransmit packets in case the acknowledge response does not arrive within a predetermined time. This retransmission timeout period may be set depending on the application. The implementation may provide a packet-individual timeout, indicating when it does not make sense any more to try to retransmit.

[0036] Upon reception of a packet with the NACK bit set, a host shall retransmit all packets sent since the last acknowledged packet. If the packets are no longer available for retransmission, the host shall resynchronize by utilizing the FORCE bit.

[0037] The FORCE bit shall only cause forward jumps in the sequence. The receiver must not move backwards in the sequence, as it would risk accepting the same packet twice. This reaction to the FORCE bit requires a different approach to resynchronization when one of the peers is reset. A peer that has been reset shall keep in the acknowledge queue at most one transmitted packet until it has received the first packet from the other side. Upon reception of the first packet, the peer shall adjust its sequence and acknowledge numbers to match the numbers from the received packet.

[0038] Accordingly, with the above arrangement, confidentiality, integrity and authenticity needs may be addressed by applying an Authenticated Encryption with Associated Data (AEAD) cryptographic scheme to protocol data units (PDUs). The issue of connection reliability is addressed using retransmissions with sequence numbers and acknowledgments. Advantageously, the protocol can be applied in any situation where two peers with pre-shared keys need to establish bi-directional reliable communication with confidentiality, integrity and authenticity guarantees. The protocol is especially suited to cases where complex high-level protocols such as (Transport Layer Security) TLS or Internet Protocol Security (IPsec) are not practical due to e.g. limited performance or limited resources of the communicating peers or low throughput of the communication channel.

[0039] The protocol establishes session keys that are derived from a shared secret that is provided out-of-band to both communicating peers. The session key establishment process employs random nonces generated using True Random Number Generators (RNGs) and provides mutual authentication of the peers. The session key establishment process protects against nonce / key pair reuse in the case of device reset. The protocol can also accommodate various AEAD schemes, such as ChaCha20-Poly1305 and Salsa20-Poly1305, as well as GCM, CCM and EAX with block ciphers including AES, Camellia and Twofish. This use of an established AEAD scheme eliminates the issues that might otherwise be associated with the potentially incorrect application of individual cryptographic primitives.

[0040] It will be understood that the embodiments illustrated above show applications only for the purposes of illustration. In practice, embodiments may be applied to many different configurations, the detailed embodiments being straightforward for those skilled in the art to implement.

Claims

1. A method for securely transmitting data between at least a first and second processing unit, each having stored a Shared Secure Key and a respective identifier, ID, and the ID of the other processing unit, the method comprising: transmitting a first authentication challenge from the first processing unit to the second processing unit, wherein the first authentication challenge comprises at least a first random number; transmitting a second authentication challenge from the second processing unit to the first processing unit, where the second authentication challenge comprises a second random number; generating a first session key and a first authentication key at the first processing unit using the first and second authentication challenges and the stored Shared Secure Key; generating a second session key and a second authentication key at the second processing unit using the first and second authentication challenges and the stored Shared Secure Key; transmitting a first authentication response from the first processing unit to the second processing unit, the first authentication response comprising a first authentication code generated from the second authentication challenge using the first authentication key; and verifying the first processing unit at the second processing unit when the received first authentication code matches a local authentication code generated from the second authentication challenge using the second authentication key; if verified, transmitting data from the second processing unit to the first processing unit using the second session key.

2. A method according claim 1, wherein the Shared Secure Key is a Shared Symmetric Key, SSK.

3. A method according to claim 1 or claim 2, wherein the step of generating the session key comprises using a key derivation function, KDF, keyed with the Shared Secure Key.

4. A method according to any preceding claim, wherein the authentication key is an ephemeral authentication key.

5. A method according to any preceding claim, wherein the authentication code is a Cipher-based message authentication code, CMAC.

6. A method according to any preceding claim, wherein the step of transmitting the first authentication challenge comprises monitoring out-of-time responses where the first authentication response is not received within a timeout period, wherein, in response to identifying an out-of-time response, a new first authentication challenge is generated comprising a new random number.

7. A method according to any preceding claim, wherein at least one of the steps of verifying the processing units comprises monitoring out-of-sequence responses received before the step of transmitting the respective authentication challenge.

8. A method according to claim 7, wherein, in response to identifying an out-of-sequence response, verification is prevented.

9. A first processing unit for secure communication with a second processing unit, comprising: a memory storing a Shared Secure Key, and an identifier, ID, and a second ID associated with a second processing unit; a random number generator for generating a first random number; a processor configured to: transmit a first authentication challenge to the second processing unit, where the first authentication challenge comprises the first random number; receive a second authentication challenge from the second processing unit, where the second authentication challenge comprises a second random number; generate a first session key and a first authentication key using the first and second authentication challenges and the Shared Secure Key; receive a second authentication response from the second processing unit, comprising a second authentication code generated from the first authentication challenge using a second authentication key generated at the second processing unit using the first and second challenges and the Shared Secure Key; verify the second processing unit when the received second authentication code matches a local authentication code generated from the first authentication challenge using the first authentication key; transmit data to the second processing unit using the first session key, if the second processing unit is verified.

10. A first processing unit according to claim 9, further comprising a timeout timer for timing the receipt of the authentication response, wherein the first processor is configured to generate a new authentication challenge comprising a new random number if the second authentication response is not received within a timeout period.

11. A first processing unit according to claim 9 or 10, wherein the first processor is configured to monitor for out-of-sequence responses received before the step of transmitting the respective authentication challenge.

12. A first processing unit according to claim 11, wherein, in response to identifying an out-of-sequence response, verification is prevented.

13. A non-transient computer readable medium comprising instructions which, when executed by a processor, implement a method of securely transmitting data between a first and second processing unit, each having stored a Shared Secure Key and a respective identifier, ID, and the ID of the other processing unit, the method comprising: transmitting a first authentication challenge from the first processing unit to the second processing unit, wherein the first authentication challenge comprises at least a first random number; transmitting a second authentication challenge from the second processing unit to the first processing unit, where the second authentication challenge comprises a second random number; generating a first session key and a first authentication key at the first processing units based on the transmitted first and second authentication challenges and the stored Shared Secure Key; generating a second session key and a second authentication key at the second processing unit using the first and second authentication challenges and the stored Shared Secure Key; transmitting a first authentication response from the first processing unit to the second processing unit, the first authentication response comprising a first authentication code generated from the second authentication challenge using the authentication key; and verifying the first processing unit at the second processing unit when the received first authentication code matches a local authentication code generated from the second authentication challenge using the second authentication key; if verified, transmitting data from the second processing unit to the first processing unit using the second session key.