Loss tolerance

We experimentally tested the loss tolerance of each approach using an embedded CAN network simulator written in Java [Koopman12]. For this work, we use a network of six nodes broadcast- ing according to a round-robin schedule. Each node takes turns broadcasting a single message type consisting of a sixteen bit data value, associated authentication data and CAN packet over- head. We selected a per-packet assurance of 2-8 as an example of a per-packet assurance proba- bility one might assign to message types in an embedded control.

We implemented all four authentication schemes in the simulator. Every node authenticates each of its packets to all five other nodes in the network. For one MAC per receiver and validity voting, each sender includes one MAC tag for each receiver. With a per-packet assurance of 2-8, at most eight authentication bits are required per tag. Thus, all value and authentication data for these two approaches fit within a single data payload. We tested validity voting using one vote, two votes, and four votes. Master-slave authentication required an additional master node to be added to the simulation, for a total of seven nodes and message types. With two tags per packet in the master-slave approach, no packet fragmentation occurred. TESLA required two CAN packets to transmit the value, MAC tag, and key for each message type in each round. We simu- lated TESLA with recovering previously lost keys, and without recovering previously lost keys.

We simulated the effects of a symmetric omissive fault model [Azadmanesh00] on network packets to observe each approach's sensitivity to packet losses and how long each takes to recov-

Comparisons to other multicast authentication techniques 113 er after transient faults cease. In a symmetric omissive fault model, either all nodes receive a packet broadcast on the network or none receive it. This type of fault may occur due to network blackouts or if a node simply fails to transmit during a message period. We apply this fault mod- el by having the network drop a percentage of packets during execution. We use the built-in fault injection capabilities of the simulator to inject omissive faults during execution. The simulator applies this drop percentage uniformly across all message types. All injected faults affect only a single packet; prolonged effects require multiple faults.

Fragility - Sensitivity to packet losses - During execution, nodes recorded the overall ratio of

authenticated data values to the total number of values transmitted (i.e., network goodput norma- lized over total execution time) to identify sensitivity to packet loss. Increasing authentication dependencies among nodes and packets make approaches more sensitive to each packet loss, causing the loss of multiple data values when a single packet is lost. Figure 5.6 shows the ratio of authenticated data values to the total transmitted as we vary the percentage of dropped packets. For each data point, we ran the simulator for a sufficient number of message rounds to observe at least one hundred drop events.

Comparisons to other multicast authentication techniques 114

Figure 5.6. Ratio of packets authenticated to total transmitted varying packet loss.

One MAC per receiver has the highest ratio of accepted data values to transmitted values as packet loss increases, because it has no inter-node or inter-packet dependencies. Thus, this scheme represents an ideal bound on the maximum ratio of processed data values to transmitted data values.

TESLA (with key recovery) had the same loss tolerance as OMPR. Since keys are initially computed by iterating a hash function, a receiver can simply recompute lost keys if a subsequent key is eventually received. Thus, a message value was only lost if the packet containing the value suffered a transmission error. Loss of only the key temporarily prevented verification of a value until another key was successfully received.

TESLA (without key recovery) is more sensitive to packet loss than one MAC per receiver due to the use of time-delayed key release for authentication. A data value will be lost if the

Packet loss ratio

0.0001 0.001 0.01 0.1 1 R a ti o o f d a ta v a lu e s a u th e n ti c a te d to t o ta l d a ta v a lu e s t ra n s m it te d 0.0 0.2 0.4 0.6 0.8 1.0 OMPR; TESLA with key recovery 1 Vote

2 Votes 4 Votes

TESLA without key recovery

Comparisons to other multicast authentication techniques 115 packet containing that data value, or either of the two fragment-bearing packets containing the subsequent key material are lost.

When using validity voting, increasing the number of votes increases sensitivity to network faults. If any vote that confirms a value is lost, then the packet containing the value voted upon is also lost. If one of these confirmation packets is lost, then all values attested to will also be marked as lost.

Master-slave authentication suffers the greatest degradation in processed data values as packet losses increases, because all packets from one round must be received to verify the previous round. If the master node's hash value or any subsequent MAC tag used to verify the hash are lost, then all values in the prior message round are also lost.

Figure 5.6 illustrates that schemes which have few or no dependencies among nodes or pack- ets for authentication, such as one MAC per receiver, TESLA, and validity voting with one or two votes, are best suited for lossy networks. For systems deployed in environments where little network interference is anticipated, approaches which require more interaction among nodes and message types for authentication can be used. Validity voting where most nodes participate in voting on a majority of each others' messages or master-slave authentication could be used in systems where transmission errors are sufficiently rare.

Robustness - Recovery time from transient faults - While most approaches have some sensi-

tivity to packet losses, all approaches recover quickly from transient faults. When used in safety- critical applications, an authentication approach must be able to resume authentication quickly after a transient fault ceases. An example of such a fault is a temporary network blackout due to an electric motor starting. We experimentally tested the length of time from the point at which a transient packet losses ceased to the point at which the first message value transmitted after the

Comparisons to other multicast authentication techniques 116 fault was successfully authenticated. To simulate these types of faults, we deterministically in- jected a single lost packet for a message type and measured the time until authentication resumed for that message type. Additionally, we dropped packets for all message types long enough to stop all authentication, then ceased all interference simultaneously to simulate the end of a net- work blackout. We observed similar recovery times in both cases and recorded the worst case.

We do not consider recovery of packets lost during the fault, as nodes in embedded control networks act on the freshest data values concerning the current system state to update outputs and actuator positions. Nodes discard stale data values after short period of time. Also, this work does not address malicious denial of service attacks on these networks.

One MAC per receiver resumes authentication immediately upon the receipt of the next mes- sage value after a transient network fault ceases. This recovery time is ideal due to no dependen- cies.

While validity voting is more sensitive to packet losses because of inter-node dependencies, it automatically resumes authentication after a message value and all subsequent votes are re- ceived. In this simulation, validity voting recovered within one message round. Verification of a value never depends on prior packets. Only subsequently received packets are used to authenti- cate a value. Votes are scheduled to be received within one message round of the value they are associated with.

TESLA recovers from transient network faults as soon as a data value and the subsequent key are received. In our simulation this occurs in just slightly over one message round. However, this delay could be reduced by scheduling a message type's keys to be released later in the message round after its value is released. Upon receiving a data value for any message type, a receiver can authenticate that value once the associated key is released in the subsequent message round. Re-

Comparisons to other multicast authentication techniques 117 ceivers must also recompute any lost keys in order to verify the authenticity of keys and values transmitted after the fault ceases. Thus, sufficiently long network blackouts might increase re- covery time.

Master-slave takes at most three message rounds to recover from a transient fault in our simu- lation. Once the fault ceases, receivers must wait until the beginning of a new message round. Receivers can begin verifying message values again once all values in that round, the master node's hash, and the tags in all packets in the following round have been received.