Cumulative Message Authentication Codes for Resource-Constrained Networks

01/15/2020 ∙ by He Li, et al. ∙ Virginia Polytechnic Institute and State University 0

In emerging applications, such as intelligent automotive systems, Internet-of-Things (IoT) and industrial control systems, the use of conventional message authentication codes (MACs) to provide message authentication and integrity is not possible due to the large size of the MAC output. A straightforward yet naive solution to this problem is to employ a truncated MAC which undesirably sacrifices cryptographic strength in exchange for reduced communication overhead. In this paper, we address this problem by proposing a novel approach for message authentication called Cumulative Message Authentication Code (CuMAC), which consists of two distinctive procedures: aggregation and accumulation. In aggregation, a sender generates compact authentication tags from segments of multiple MACs by using a systematic encoding procedure. In accumulation, a receiver accumulates the cryptographic strength of the underlying MAC by collecting and verifying the authentication tags. Embodied with these two procedures, CuMAC enables the receiver to achieve an advantageous trade-off between the cryptographic strength and the latency in processing of the authentication tags. We have carried out comprehensive evaluations of CuMAC in two real-world applications: low-power wide-area network and in-vehicle controller area network. Our evaluation methodology included simulations as well as a prototype implementation of CuMAC on a real car.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 9

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

In emerging applications, such as home automation, industrial controllers and sensor networks, a large number of energy-constrained computing devices are getting closely integrated with the existing computer infrastructure through bandwidth-constrained networks to form the Internet-of-Things (IoT) [Raz17]. The successful adoption of those applications will partially depend on our ability to thwart security and privacy threats, including message forgery and tampering. Today, message authentication code (MAC) is the most commonly used method for providing message authenticity and integrity in wired/wireless network applications. To employ MACs in a resource-constrained (i.e., energy and/or bandwidth constrained) network, we need to consider two problems: the computational burden on the devices for generating and verifying the MAC, and the additional communication overhead incurred due to the inclusion of the MAC in each message frame/packet. The first problem can be addressed by using dedicated hardware and cryptographic accelerators [Esc09, Soj14]. However, the second problem is not as easy to address.

The cryptographic strength of a MAC depends on the cryptographic strength of the underlying cryptographic primitive (e.g. a hash or block cipher), the size of the MAC output, and the size and quality of the key. Hence, a conventional MAC scheme typically employs at least a few hundred bits of MAC output to ensure a sufficient level of cryptographic strength. In energy-constrained networks (e.g., low-power wide-area network with battery-powered devices) and bandwidth-constrained networks (e.g., in-vehicle controller area network), the payload size of each packet is very short (less than 150 bits in some protocols), and not more than a few bits can be spared to include an authentication tag associated with the MAC [Nil08, Raz17].

The legacy solution for generating a short authentication tag is to truncate the output of a conventional MAC so that it fits a message frame/packet [Wan17, Szi08, sch11]. This type of MAC is called a truncated MAC. However, the truncated MAC sacrifices cryptographic strength in exchange for reduced communication overhead and energy consumption, which may be undesirable, or even unacceptable, in some applications. Note that the truncated MAC without sufficient cryptographic strength renders the application vulnerable to collision attacks [bhargavan2016transcript]. To enable authentication with enhanced cryptographic strength, Katz et al. propose the concept of aggregate MAC where conventional MACs of multiple messages are combined into one aggregate MAC, and transmitted over successive packets [Kat08]. Similarly, Nilson et al. propose a compound MAC which is calculated on a compound of multiple messages, and distributed over successive packets [Nil08]. However, both the aggregate and compound MAC schemes incur significant latency in the verification of the messages because the receiver needs to receive and process all associated packets before being able to verify the MAC.

In this paper, we identify two challenges in employing MACs for resource-constrained networks: (1) incurring minimal communication overhead so that the MAC can fit in a message packet, and (2) ensuring that the cryptographic strength meets the security need of the application. In this paper, we propose a novel approach for message authentication that we refer to as Cumulative Message Authentication Code (CuMAC) that addresses both of the aforementioned challenges. In CuMAC, a sender utilizes a procedure called aggregation through which the sender first divides the full-sized MAC output of each message into multiple short MAC segments, and then “aggregates” the MAC segments of multiple messages using a systematic encoding procedure to form a short authentication tag. This procedure resolves the first challenge of ensuring low communication overhead.

Further, the receiver utilizes a procedure called accumulation through which it first verifies the MAC segments aggregated into the authentication tag of each received packet, and then “accumulates” the cryptographic strength by collecting the verified MAC segments associated with the target message. In this procedure, the receiver may incur delay that is proportional to the accumulated cryptographic strength since it needs to wait for the relevant tags to be received and processed. Hence, while the accumulation procedure caters to the second challenge, it brings up a novel trade-off between the cryptographic strength and delay. CuMAC enables the receiver to authenticate the message in real-time with the cryptographic strength which is commensurate with the size of each tag. Further, CuMAC enables the authentication with the highest level of cryptographic strength (which is commensurate with size of the MAC) after accumulating all segments of the MAC that covers the message in the associated packets.

The paper’s main contributions are summarized as follows.

  1. We propose a novel message authentication scheme called CuMAC, which meets the security need of resource-constrained network applications. CuMAC is an embodiment of two novel concepts that we refer to as aggregation (which reduces the communication overhead) and accumulation (which increases the cryptographic strength).

  2. We have thoroughly evaluated the effectiveness of CuMAC through simulations and a prototype implementation on a real car. Our results illustrate that while incurring the same communication overhead as the truncated MAC scheme, CuMAC achieves the cryptographic strength equivalent to the conventional MAC scheme at the cost of increase in latency.

  3. We provide the rigorous security proof for CuMAC.

Ii Potential Application Scenarios

We discuss two suitable application scenarios of CuMAC, where the constraints of the network—either in terms of MAC size or energy/bandwidth consumption of the networked devices—prohibit the use of the conventional MAC scheme. We highlight that CuMAC can be readily employed in a variety of other IoT networks (e.g., those employing Constrained Access Protocol (CoAP) [bormann2012coap] or Message Queue Telemetry Transport (MQTT) [singh2015secure]), and its design is not limited by specific characteristics of these two applications.

Ii-a Low-Power Wide-Area Network (LPWAN)

Many IoT applications (e.g., smart metering and smart city infrastructure) require a heavily-crowded network of low-cost energy-constrained battery-operated wireless devices. The paradigm of LPWAN is aimed at fulfilling these requirements of IoT networks [Raz17, Wan17]. Sigfox [Sig17] is one example of a widely-known LPWAN technology. In Sigfox, each uplink packet contains a counter, a message (with length between 0 and 96 bits), and an authentication tag (with length between 16 and 40 bits). To enable robust communication over the unreliable wireless channel, the sender in Sigfox transmits multiple copies of the same packet sequentially. After transmitting the fixed number of copies of the packet, Sigfox waits for an acknowledgement from the receiver. In the absence of the acknowledgement, the packet is considered lost. We note that Sigfox does not support retransmission of lost packets.

The battery-powered Sigfox devices are expected to have a service/battery life of several years. As the energy consumption of a Sigfox device is directly proportional to the size of packet communicated by it, it is imperative to communicate using short packets to ensure a long battery life. Also, although the message integrity and authentication are of prime importance in applications supported by Sigfox [rom13], it is unfeasible to communicate the full-sized MAC output due to the small size of the tag allocated in the Sigfox packet.

Ii-B In-Vehicle Controller Area Network (CAN)

Today’s high-end cars use a hundred or more electronic control units (ECUs) to enable advanced functionalities, such as real-time engine control. ECUs in most modern vehicles communicate with each other over a bandwidth-constrained wired broadcast channel called the Controller Area Network (CAN) bus [Bos91, ISO15]. Because the messages communicated among ECUs directly affect vital functions of a vehicle, some of which are safety related (e.g., dynamics control system [Joh05]), the security and reliability of the CAN bus and the integrity of the messages on it are critical [Soj14]. We note that while the state-of-the-art CAN bus supports robust mechanisms for message acknowledgement and retransmission of corrupted/lost packets, it does not support any security mechanism [Zag18]. Several studies have shown that a car’s in-vehicle network can be compromised through either direct physical access (e.g., using the on-board diagnostics port) or a remote connection (e.g., using Bluetooth) to the CAN bus [Che11, Kos10, Woo15]. Due to one such vulnerability, Jeep had to recall 1.4 million vehicles in 2015 [Mil15]. To counter such attacks and protect messages on the CAN bus, the US National Highway Traffic Safety Administration (NHTSA) recommends the inclusion of MACs [Nat16].

A CAN packet consists of an 11-bit or a 29-bit identifier field and a message field with length between 0 and 64 bits. Except the identifier and message fields, we cannot arbitrarily change the length or the content of other fields in the CAN packet as that would make the modified packet incompatible with the existing CAN protocol. Hence, in the prior art [Szi08, Ued15], to realize MAC-based authentication in each packet, the identifier field is used to accommodate an 18-bit counter, and the message field is used to accommodate the message payload as well as the authentication tag. We note although the design of this modified packet ensures that it is backward-compatible, inserting a full-sized MAC in the modified packet is not possible because the maximum allowed length of the message field in a CAN packet is only 64 bits.

Iii Overview of CuMAC

Iii-a System Model

Fig. 1: Packet model employed in CuMAC.

We consider an energy-constrained and/or bandwidth-constrained network (e.g., LPWAN, CAN and Bluetooth Low Energy (BLE) [gomez2012overview]) where a sender needs to transmit security-critical messages to a receiver using small packets. As shown in Figure 1, we let the sender employ a packet format which contains at least three fields: a packet counter, a message, and an authentication tag. We note that these three fields are critical for ensuring any secure message authentication scheme including CuMAC. Hence, if the network protocol (e.g., Sigfox as discussed in Section II-A) employs these fields in the conventional packets by design, CuMAC can readily utilize them; otherwise, the packet contents can be modified in the target network protocol (e.g., CAN as discussed in Section II-B) to include these fields.

We assume that there exists a message acknowledgement mechanism which enables the sender to know if a particular packet was correctly delivered to the receiver [Wan11]. The acknowledgement mechanism assisted with the packet counter enables the sender and the receiver to maintain the same sequence of packets. Note that we do not make any assumption about the message retransmission mechanism, i.e., the network may or may not support retransmission. We highlight that in this paper, we provide Sigfox and CAN as concrete application scenarios for CuMAC, but our system model is generically applicable to a resource-constrained network.

Iii-B Design of CuMAC

Fig. 2: Schematic of the procedures in the tag generation algorithm at the sender in CuMAC.

In the above system model, the sender and the receiver (after sharing a secret key) communicate a sequence of messages and employ CuMAC for authentication. CuMAC comprises of two major algorithms: tag generation and tag verification. In the tag generation algorithm, the sender computes the authentication tag through two major steps (Figure 2). In the first step, the sender generates the MAC of the message, breaks the MAC into short segments, and stores them into a segment array. In the second step, the sender retrieves segments (one MAC segment of the current message, and segments of the MACs of the previously transmitted messages) from the segment array, and aggregates the segments to generate a tag.

For instance, in the illustration shown in Figure 3, an -bit MAC is divided into segments, such that the size of each segment is bits, i.e., . Then, an authentication tag of length bits is computed using the tag generation algorithm of CuMAC (Figure 2). Finally, in the packet, the sender transmits the message denoted by and the authentication tag denoted by . We note that in CuMAC, the segments of the MAC of the message are aggregated into the authentication tags, , and transmitted in the corresponding packets.

Having received each packet, the receiver runs the tag verification algorithm which includes two major steps. In the first step, the receiver generates an authentication tag of the received message using the same procedure employed in the tag generation algorithm. In the second step, the receiver compares the generated authentication tag with the received authentication tag. If the authentication tags match, the receiver accumulates the MAC segments (aggregated in the authentication tag) with the previously received MAC segments of the corresponding message. For instance, in the illustration shown in Figure 3, after receiving and verifying each of the authentication tags, , the receiver accumulates the MAC segments of the message (aggregated in those tags) to reconstruct the underlying -bit MAC.

Iii-C Authentication Levels in CuMAC

Fig. 3: Illustration of the levels of authentication in CuMAC.

For CuMAC, we define three levels/features of authentication: (1) real-time authentication, (2) full authentication, and (3) partially accumulated authentication. Figure 3 also illustrates the three different levels of authentication, when applied to message . Recall that the MAC of the message is divided into segments, and distributed in tags .

In this case, the receiver can perform real-time authentication immediately after receiving message by processing the tag . With real-time authentication, the receiver performs authentication without any delay, but it achieves the lowest cryptographic strength since there is no security accumulation using the subsequent tags. On the other hand, the receiver can perform full authentication after receiving all of the segments of the MAC associated with message in tags . With full authentication, the receiver achieves the highest cryptographic strength, but needs to incur a latency of packets. The receiver can perform partially accumulated authentication by accumulating and processing tags , where . Partially accumulated authentication enables the receiver to make a trade-off between cryptographic strength and message verification latency to meet the security and performance needs of the application.

Iii-D Attack Model

We consider an adversary which aims to forge valid authentication tags for its malicious messages so that it can deceive the authentication scheme at the receiver. While the adversary can eavesdrop the communication channel to obtain packets transmitted by the sender, it does not know the secret key (used for generating authentication tags) shared between the sender and the receiver.

Specifically, to break the real-time authentication feature of CuMAC, the adversary needs to forge a message and a valid tag. The forgery need to be fresh which means that the sender has not generated the MAC of the same counter and message pair using the same shared key, and transmitted them over the communication channel. To break the partially accumulated authentication feature of CuMAC with accumulated segments, the adversary need to forge a sequence of messages with valid tags. In this sequence, the forgery for only the first message needs to be fresh. Similarly, to break the full authentication feature of CuMAC, the adversary need to forge a sequence of messages with valid tags, where forgery for at least the first message is fresh.

Iii-E Security Objectives

We convey the cryptographic strength in bits, where a cryptographic strength of bits for a scheme means that for any adversary making at most queries or taking at most

time, the probability of successfully launching an attack on the scheme is negligibly small

[Ber13]. The cryptographic strength of a conventional MAC depends on three security parameters: (1) the cryptographic strength of the underlying cryptographic primitive, (2) the size and quality of the secret key, and (3) the size of the MAC output. To achieve a cryptographic strength of bits, the minimum size of the key and the MAC output should be bits. In this paper, we present the cryptographic strength using the size of the MAC output (denoted by ).

From the illustration discussed in Section III-C, we note that the cryptographic strength of the full authentication depends on the same three aforementioned security parameters of the conventional MAC. However, the cryptographic strength of real-time authentication in CuMAC is limited by the size of the MAC segment . Also, the cryptographic strength of the partially accumulated authentication in CuMAC depends on the size of the MAC segment and the number of accumulated segments . The security objective of CuMAC is to ensure that the probability with which an adversary succeeds in breaking each of the three authentication features is negligible (i.e, commensurate with the corresponding cryptographic strength).

We will provide formal definition and rigorous proof of security of CuMAC in Section V.

Iv Technical Details of CuMAC

Here, we present the technical details of the algorithms employed by CuMAC. We also provide an example that illustrates the generation and verification of the tags in CuMAC.

Iv-a Algorithms

CuMAC is composed of the following algorithms that are executed by the sender and/or the receiver.

This probabilistic key generation algorithm is utilized by the sender and the receiver to obtain the secret key. The input to this algorithm is the security parameter , and the output is the secret key denoted by . In a resource-constrained network, this algorithm can be efficiently realized by leveraging a trusted third party [sch11], or using an efficient key predistribution scheme if trusted infrastructure is not available[du05].

This deterministic MAC generation algorithm is utilized by the sender and the receiver (as a sub-algorithm of tag generation and verification algorithms) to compute the MAC of a message using the secret key. The inputs to this algorithm are the secret key , a counter and a message . This algorithm outputs the bits long MAC represented by . This algorithm can be realized using a cipher-based (e.g., AES-CMAC) or a hash-based (e.g., SHA-3) MAC scheme. In this paper, we utilize the widely used AES-CMAC [Bel00].

This segment aggregation algorithm is utilized by the sender and the receiver as a sub-algorithm of tag generation and the tag verification algorithms, respectively. It takes as input a two-dimensional array of MAC segments . This algorithm proceeds as follows. The row of segments in is generated as follows. The -bit MAC is divided into segments, such that the size of each segment is bits, i.e., . The segment of is represented by , and is extracted from as

(1)

It means that the bits in correspond to the bits from bit to bit in . Further, this algorithm extracts elements from ( previous MAC segments and one current MAC segment), and computes the authentication tag as follows.

(2)

This algorithm outputs the authentication tag .

This tag generation algorithm is run by the sender to generate an authentication tag. It takes as inputs the secret key , a counter and a message . It utilizes an array of MAC segments which is stored and maintained by the sender. This algorithm proceeds as follows to output the authentication tag .

  1. Compute the MAC of the message and set it as , i.e., .

  2. Divide the MAC into segments as shown in equation (1) and append the segments to the array .

  3. Compute and output the tag by aggregating the segments of MACs in as shown in equation (2), i.e., .

After receiving the positive acknowledgment of the delivery of the packet from the receiver, the sender increments the packet counter by one for the next packet. We note that the packet counter can be readily employed to handle the case of a lost packet. The sender gets to know that the packet is lost when it does not receive the acknowledgement from the receiver or it receives a negative acknowledgement. In this case, if the sender supports a retransmission mechanism, the sender simply re-transmits the same packet containing the same counter , the same message and the same tag . Otherwise, if the sender does not support any retransmission mechanism, the sender does not increment the packet counter, removes the row (i.e., the most recently appended row) of segments in , and then proceeds with the tag generation of the next message.

This verification algorithm is run by the receiver for verifying the authenticity of the received message and tag. It takes as inputs the secret key , the received counter , the received message , and the received tag . It utilizes an array of MAC segments , and an array of number of verified segments . These arrays are stored and maintained by the receiver. The entry in the array is represented by . To initialize the value of in the array , the receiver sets . This algorithm verifies whether the tag is generated using the secret key . If the verification succeeds, it outputs the value ; otherwise, it outputs the value . This algorithm proceeds as follows.

  1. Compute the MAC of the message and set it as , i.e., .

  2. Divide the MAC into segments as shown in equation (1) and append the segments to the array . We note that the counter ensures that the arrays at the sender and at the receiver remain synchronized.

  3. Compute the tag by aggregating the segments of MACs in as shown in equation (2), i.e., .

  4. If ,

    1. Update the array of accumulated MAC segments , such that for each , set .

    2. Output the value .

  5. Otherwise, if , output the value .

Packet Previous Current Aggregation of MAC segments Tag
Counter MACs MAC
5
6      
7           
8                 
TABLE I: Example illustrating CuMAC with , , and .

Iv-B Instantiation of CuMAC

Table I presents an example of CuMAC. The size of the tag in each packet is bits (i.e., ). The MAC is generated using the AES-CMAC algorithm. Hence, the size of the MAC output is  bits (i.e., ), which provides cryptographic strength of bits. Each MAC is divided into four segments (i.e., ). This means that the achievable cryptographic strengths for real-time authentication and full authentication are bits and  bits, respectively. To simplify the discussion, we limit the discussions to the packets which are involved in the authentication of the message transmitted in the fifth packet, . In the fifth packet, the MAC of the message is computed. To compute the corresponding tag , the sender aggregates the segment of the MAC and the segments of the MACs of the previously generated messages, , and . Further, the tags , and are computed using the segments , and of , respectively.

When the receiver receives the fifth packet with the message , the successful verification of the tag enables the real-time authentication of message with the cryptographic strength of  bits. Next, the receiver receives and verifies the validity of tags , , and . If all four tags are verified as , the receiver combines the segments , , and —which are contained in tags , , and , respectively—to accumulate the cryptographic strength. This enables the receiver to perform full authentication of message with the cryptographic strength of bits. However, if the receiver is restricted to process the fifth packet only after receiving the seventh packet due to latency requirements, it may also perform partially accumulated authentication of message with a cryptographic strength of  bits after verifying tags , and . Note that this ability to perform the partially accumulated authentication is the most unique feature of CuMAC when compared to the prior art.

V Security Analysis

In this section we present formal security definition and proof for CuMAC.

V-a Security Definition

The security definition for CuMAC is based on the notion of unforgeability under chosen message attack (uf-cma). We present the following uf-cma- experiment, where the parameter indicates the number of segments accumulated for tag verification.

  • Invoke an adversary who can make up to queries to the tag generating oracle of CuMAC, .

  • queries with arbitrarily chosen messages and receives their corresponding tags in response.

  • outputs a set of pairs .

  • Return 1 if for all , and did not make the query for to , where .

  • Return 0 otherwise.

Using the above experiment, we present the following security definition where the probability is denoted by .

Definition 1.

CuMAC is -uf-cma secure if for any probabilistic polynomial time (PPT) adversary running in time , .

We utilize the above uf-cma- security model to define the cryptographic strengths for full, partially accumulated and real-time authentication. If CuMAC is secure, i.e., , then CuMAC is secure in terms of full authentication. Similarly, if CuMAC is secure for all , then the scheme is secure for partially accumulated authentication; and if CuMAC is secure, i.e., , then the scheme is secure in terms of real-time authentication.

V-B Security Proof

Here, we present the security proof for CuMAC which closely follows the proof for the aggregate MAC scheme [Kat08]. Let CuMAC be instantiated with parameters , i.e., each MAC is divided into segments, each of length bits.

Theorem 1.

For any and , if the underlying deterministic MAC generation algorithm, , is -uf-cma secure, then CuMAC with parameters is -uf-cma secure, where

Proof:

Let there be an adversary which succeeds to create a forgery of an authentication tag for CuMAC with a non-negligible probability. We construct a simulator that interacts with the adversary and creates a forgery of a MAC for the algorithm with a non-negligible probability.

Let CuMAC and the algorithm utilize the same secret key which is unknown to the adversary . Also, let the underlying MAC of a message in CuMAC be retrieved by a query to the MAC generating oracle . In this way, perfectly simulates the tag generating oracle , and hence the uf-cma- experiment for CuMAC. Suppose the uf-cma- experiment for CuMAC returns with the probability in time , where an adversary outputs a successful forgery after queries to simulated by .

To create a forgery of a MAC for the algorithm, the simulator proceeds as follows. Given , the simulator queries for the MAC of , and obtains the corresponding for all and . It divides each MAC into segments as shown in equation (1). Then, for each , it recovers the MAC segment of the message by removing the mask by the MAC segments of other messages as follows.

(3)

By following the above procedure, the simulator recovers MAC segments. Since , the simulator cannot recover the segments with . Hence, it makes a random guess for the rest of the segments, such that for all . Finally, the simulator creates a fresh forgery for the algorithm, by concatenating all recovered and guessed segments. The probability that such forgery is correct is .

To achieve the forgery of as shown above, the simulator conducts at most queries to to answer queries by to . In order to compute operations in equations (3), the simulator conducts at most queries to to obtain . Therefore, if for an adversary running in time can have , then can leverage to break the algorithm, in time plus the time required to evaluate equation (3), by making queries, and with probability . Hence, if the algorithm, is -uf-cma secure, then CuMAC is -uf-cma secure, where , , and . ∎

Vi Evaluation

We firstly highlight the advantages of CuMAC by comparing it with the prior art. We then evaluate the performance of CuMAC in an energy-constrained network application and a bandwidth-constrained network application. These two applications have very different constraints, but they share a common requirement—i.e., messages need to be protected using short tags—that illustrates the utility of CuMAC.

Vi-a Comparison with the Prior Art

(a) Trade-off between cryptographic strength and delay.
(b) Effect of unreliable communication channel.
Fig. 4: Comparison of CuMAC with the prior art.

We evaluate the performance of CuMAC by comparing it with three other schemes from the prior art: the truncated MAC [Szi08], the compound MAC [Nil08], and the aggregate MAC [Kat08]. For all four schemes, AES-CMAC with a MAC output of 128 bits is utilized as the underlying MAC algorithm. We set the size of the tag in all the four schemes to 16 bits. In the truncated MAC scheme, each MAC is truncated to 16 bits, and transmitted as the tag. In the compound MAC scheme, a compound MAC of 128 bits is computed over eight messages. In the aggregate MAC scheme, an aggregate MAC of 128 bits is computed by aggregating the MACs of eight messages. The compound MAC and the aggregate MAC are divided into eight segments each of size 16 bits, and transmitted in each of the eight packets as the tag. In CuMAC, each MAC of 128 bits is divided into eight segments each of size 16 bits, and each tag is generated by aggregating segments of seven previously transmitted messages and the current message.

Figure 3(a) presents the cryptographic strengths of four schemes versus their authentication delay. In the figure, we observe that CuMAC provides real-time authentication with cryptographic strength of 16 bits, which is the same for truncated MAC. As more packets are received, partially accumulated authentication is achieved and CuMAC provides gradually increased cryptographic strength. Finally, CuMAC provides full authentication with cryptographic strength of 128 bits, which is the same as compound/aggregate MAC.

Most importantly, findings shown in Figure 3(a) highlight one critical advantageous attribute of CuMAC. CuMAC enables a receiver to make a trade-off between (accumulated) cryptographic strength and authentication delay. In some latency-tolerant applications, this attribute provides the receiver with operational flexibility to vary the security level and/or packet processing delay based on particular needs of a protocol or rules prescribed by network traffic processing policies.

Further, we evaluate the effect of unreliable communication channel on the four schemes in Figure 3(b). The unreliability of the channel is measured by the packet drop rate which is equal to the ratio of the lost packets and the total number of transmitted packets. The performance of each scheme is measured in terms of the packet processing rate which is equal to the ratio of successfully authenticated packets at the receiver and the total number of transmitted packets. We note that although the packet processing rates in CuMAC and the truncated MAC are equal (Figure 3(b)), the cryptographic strengths for their full authentication are 128 bits and 16 bits, respectively (Figure 3(a)).

Further, in Figure 3(b), we observe that the compound/aggregate MAC can enable processing of significantly lower number of packets than CuMAC. This is because in compound/aggregate MAC, the verification of a MAC requires the receiver to receive all of the packets that contain the messages utilized to compute that particular MAC, and loss of any one of those packets leads to the failure in processing of other packets. This implies that given the packet drop rate of , the packet processing rate can be represented by in CuMAC, but in the compound/aggregate MAC. Hence, for a typical packet drop rate and , the packet processing rate in the compound/aggregate MAC is around which is an unacceptable rate in a typical network.

Vi-B Advantages in an Energy-Constrained Network

We consider an air quality monitoring system which consists of a base station and multiple sensors nodes distributed over a large area [Sig17]. Each sensor node utilizes the Sigfox protocol to send the air quality data to the base station once in every hour [Roh15]. The data is examined at the base station and finally made available to the responsible authorities. In this application scenario, there are two important performance requirements—(1) service life: each battery-operated sensor node needs to operate for a few years independently without any physical access which means that the network is energy-constrained; and (2) robust authentication: message authentication scheme is needed to ensure verification of received data despite losing some packets. Note that in this scenario, the latency requirement is not stringent as the data is collected and analyzed at the base station with some inherent delay.

Vi-B1 Service Life

We evaluate the effect of appending an authentication tag in each packet on the service life of a sensor node, which is equal to its battery life. To compute the service life, we utilize the charge consumption data from a Sigfox compliant transceiver IC produced by ON Semiconductor [On18]. Table II presents the parameters utilized in the computation of the service life. We employ two 1.5 V Alkaline C batteries connected in series. Each battery holds a charge of 8000 mAh. The transmission time in every hour is limited to 2 seconds, and hence the device is considered to be in sleep almost all the time. We ignore the battery self discharge in this calculation.

Battery capacity 8000 mAh 3600 s/h = 28800 C
Sleep charge 1.3 A 86400 s/day = 0.11 C/day
Packet transmission rate 1 packet/h = 24 packets/day
Packet transmission without payload 0.20 C
Payload transmission 0.002 C/bit
TABLE II: Parameters utilized for computing the service life of a sensor node in a Sigfox network.

Figure 5 presents the service life of a sensor node for different sizes of message and authentication tag. We observe that by appending authentication tags in transmitted packets, each sensor node consumes a significantly more energy on data transmission which shortens the service life. Specifically, we consider a 48-bit message without tag as the benchmark which results in the service life of around 11 years. Figure 5 illustrates that in comparison to this benchmark, utilizing the conventional MAC of size 128 bits results in a significant loss of around 45% of service life. However, CuMAC can utilize the 16-bit tag in each packet without compromising the cryptographic strength (128 bits) for full authentication, and with a modest (around 10%) reduction in the service life as compared to the benchmark. Hence, for the LPWAN (like Sigfox) where the size of the tag in each packet is usually limited due to the energy constraints, we assert that CuMAC is a much more viable solution for message authentication than the full-size conventional MAC.

Fig. 5: Effect of size of message and authentication tag on the service life of a sensor node in a Sigfox network.

Vi-B2 Robust Authentication

Recall that in Sigfox, the sender becomes aware of the lost packet when it does not receive the acknowledgement from the receiver. Since Sigfox does not support retransmission of packets, the authentication scheme needs to be robust against packet drops. In CuMAC, the packet counter readily handles such cases, and ensures synchronization of packets between the sender and receiver. This implies that with CuMAC, all received messages can be authenticated with the cryptographic strength of 128 bits, albeit with some delay. However, in this application, the truncated MAC cannot provide high cryptographic strength as shown in Figure 3(a), and the compound/aggregate MAC cannot provide robust authentication to all received packets as shown in Figure 3(b).

Vi-C Advantages in a Bandwidth-Constrained Network

Size byte bytes bytes bytes Share Period ms ms ms ms ms ms ms Share
TABLE III: Distribution of size and period of messages in CAN.

We consider the CAN bus as an illustrative bandwidth-constrained network. We simulate the performance of the CAN bus when the authentication tag along with the message is inserted in the CAN packets. Table III

illustrates the distribution of the size and the period of messages utilized in the simulation. This distribution is based on the open-source benchmark presented by Kramer et al.

[Kra15]. The bus speed utilized in the simulation is  kbps. In the simulation, we let the maximum size of the message to be 6 bytes which means 2 bytes (16 bits) of tag can be readily inserted in the data field. An 18-bit packet counter is inserted in the CAN identifier field [Szi08, Ued15]. To communicate the full 128-bit tag, an ECU may employ the trailing MAC scheme in which the ECU needs to transmit two extra packets with the tag for each packet with the message [Gro12]. Recall that a maximum of 64 bits of tag can be transmitted in one CAN packet. In the above scenario, we evaluate two performance metrics of the CAN bus: bus load and message processing delay.

Vi-C1 Bus Load

The bus load is a critical parameter for evaluating the overall latency performance of the CAN bus. Typically, the CAN bus load is between to , but with systematic approaches based on scheduling analysis, the bus load can be increased to around [Dav07]. The bus load is directly proportional to the number of supported messages on the CAN bus. A high bus load may increase the latency of messages that may lead to problems, such as car functions being delayed and high possibility of communication fault situations [Zag18]. Hence, it is critical to keep the bus load low.

Fig. 6: Effect of size of message and authentication tag on the CAN bus load.

Figure 6 illustrates the effect of increasing the number of messages and inserting authentication tags in the CAN packet on the CAN bus load. We observe that at a typical bus load of , the number of supported messages without authentication is . While maintaining the same bus load, CuMAC with a -bit tag is able to support messages, but a trailing MAC with a -bit tag supports only messages. Further, considering the maximum bus load of , the maximum number of messages supported by the bus with a -bit tag is , but that with a -bit tag is only . This means that to support messages, a vehicle needs only one CAN bus when the messages are authenticated using CuMAC, but it needs three CAN buses when the messages are authenticated using a full-size MAC. Note that increasing the number of CAN buses increases the overall cost of the vehicle.

Vi-C2 Message Processing Delay

Message processing delay is an important design metric for the CAN bus which supports safety-critical functions of a vehicle [Dav07]. The major components of this delay includes the delay in the generation of the authentication tag at the sender, communication of the CAN packet over the bus, and then verification of the authentication tag at the receiver. We note that although the CAN bus enforces strict message processing deadlines, the individual communication delay encountered by each message type (which denotes all messages with the same message identifier) on the bus can vary significantly between 5 ms and 1000 ms [Zag18]. Also, recall that CuMAC supports accumulation of cryptographic strength as per the flexible delay requirement as shown in Figure 3(a). This implies that with CuMAC, some message types can be authenticated with high cryptographic strength. Unlike CuMAC, the truncated MAC does not support accumulation of cryptographic strength, and the compound/aggregate MAC cannot provide real-time authentication guarantee which is essential for the CAN bus.

Vii Implementation Results

We discuss the results from the experiments performed with a prototype implementation. These results are also utilized to compare CuMAC with the MAC schemes in the prior art.

Scheme Code Space Increase in Real-Time Auth. Full Auth. Partially Accum. Auth.
Bus Load Delay Strength Delay Strength Delay Strength
Trailing MAC 7410 bytes 300 % 3.451 ms 0 bit 5.616 ms 128 bits 50.000 ms 128 bits
Truncated MAC 7410 bytes 8 % 3.440 ms 16 bits 3.440 ms 16 bits 50.000 ms 16 bits
Compound/Aggregate MAC 7450 bytes 8 % 3.887 ms 0 bit 84.143 ms 128 bits 50.000 ms 0 bits
CuMAC 7522 bytes 8 % 3.798 ms 16 bits 83.983 ms 128 bits 50.000 ms 64 bits
TABLE IV: Comparison of the MAC schemes using the prototype implementation on a real car.

Vii-a Details of the Prototype Implementation

Fig. 7: Prototype connected to a car’s CAN bus.

Figure 7 illustrates the prototype implementation and the setup that were used for running our experiments. The prototype implementation comprised of two ECU prototypes connected to the on-board diagnostics (OBD) port of the CAN bus (with the bus speed of  kbps) of a 2016 Toyota Corolla LE. The ECU prototype consisted of an Arduino UNO board and a Seeed studio CAN shield. The Arduino UNO board was used to emulate the controller unit of an ECU, and the Seeed studio CAN shield worked as the interface between the Arduino UNO board and the CAN bus. The Arduino UNO board utilizes an Atmel ATmega328P chip, which includes a low-power 8-bit micro-controller running at 16 MHz clock speed along with a 32 KB flash memory and a 2 KB RAM. These specifications of the ECU prototype are representative of a typical state-of-the-art automotive-grade controller [Mur16].

With the above experimental setup, we compared five schemes: the trailing MAC, the truncated MAC, the compound MAC, the aggregate MAC and CuMAC. For all five schemes, AES-CMAC with a MAC output of 128 bits was utilized as the underlying MAC algorithm. We utilized an open-source cryptography library [github_aes] to implement AES-CMAC. We found that the computation time (calculated by averaging the computation time over 1000 executions) of generating a MAC was 0.786 ms. For the truncated MAC, the compound MAC, the aggregate MAC and CuMAC, the size of the tag was set to 16 bits, and the message and tag were inserted into the data field of the same CAN packet. For the trailing MAC, the 128-bit MAC was split into two tags of 64 bits, and inserted into the data fields of two consecutive CAN packets. These packets were transmitted immediately after the CAN packet containing only the message.

To evaluate the delay performance, we utilized one ECU prototype (called Tx-ECU) to transmit 6-byte messages with the tags on the CAN bus, and another ECU prototype (called Rx-ECU) to measure the end-to-end delay. In the experiment, the Rx-ECU requested the Tx-ECU (through an external synchronization channel) to send a message, and started the timer. The Rx-ECU stopped the timer after verifying the tag and authenticating the message. The delay was measured as the time between starting the timer and stopping the timer. Also, we let the message processing deadline for the message type utilized in the experiment be 50 ms. Note that the processing deadline represents the time within which the authentication tags corresponding to the message are expected to be generated, communicated and verified.

Vii-B Results

Table IV summarizes the results from the experiments. The end-to-end delay shown in the table is the worst case delay in processing 1000 CAN messages. The table also presents the cryptographic strengths for real-time, full and partially accumulated authentication in each scheme. From Table IV, we observe that: (1) In comparison to the truncated MAC, additional 112 bytes of storage is required to store the segments of the MACs of seven previous messages in CuMAC; (2) Unlike the trailing MAC, CuMAC does not increase the bus load significantly; (3) Unlike the compound MAC and the aggregate MAC, CuMAC provides real-time authentication; and (4) In comparison with the truncated MAC, the compound MAC and the aggregate MAC schemes, CuMAC provides higher cryptographic strength for partially accumulated authentication within the processing deadline.

Viii Conclusion

We proposed a novel concept for message authentication that we refer to as cumulative MAC (CuMAC). CuMAC incurs low communication overhead, and provides high cryptographic strength which is commensurate with the delay in authentication. Our promising simulation and experimental results show that CuMAC provides significant advantages over the MAC schemes in the prior art when deployed in a number of emerging applications, including those that run on energy-constrained or bandwidth-constrained networks.

References