Verifying state-changing messages

Time-triggered authentication provides strong assurance for state-changes by authenticating over a set of message values, each of which have weak per-packet assurance. A receiving node keeps an explicit history buffer for the authentication results of each message type used in its internal state machines. A history buffer acts like a First In First Out (FIFO) buffer in which receivers store the n most recent message values and the verification results for each sample (“valid” or “invalid”). At startup, nodes initialize history buffers so that all elements are set to a default val- ue and stored as invalid.

Receivers verify each message value individually using the process described in Section 3.3.4. Lost message values are discarded and are not included in the buffer. Once verified as valid or invalid, a receiver discards the oldest value in the history buffer, shifts all values by one index position, and stores the newest value and its validity.

Upon checking and storing the verification results of a newly received message value, a re- ceiving node checks if the contents of the history buffer satisfy the conditions to commit to a state change, as defined by its internal state machine. A node commits to a state change if a his-

Time-triggered authentication 37 tory buffer contains a sufficient number of valid message value samples that are all consistent. A set of values for a message type is consistent if all valid values would trigger the same state tran- sition (the values do not necessarily need to be equal). In the case that a transition depends on multiple message types, the receiver would wait until all history buffers for those message types satisfy the condition for the state transition.

All values within the history buffer must be consistent for a state transition to be taken. If one of the values is not consistent, a state transition cannot occur.

Once a node commits a state change, the node clears its history buffers and resets them to de- fault values stored as invalid.

For example, a node that controls a door lock in an automotive network might monitor the wheel speed message type, and automatically lock the door if the car is moving sufficiently fast. If the speed threshold is set at fifteen miles per hour, the door lock node would record each re- ceived message sample value and its validity in the history buffer. Once a sufficient number of wheel speed message values in the history buffer are valid and are all at least fifteen miles per hour, the node would commit to the transition and locks the door.

No tolerance for invalid MAC tags - Depending on the application, the system designer de-

cides how many samples in the history buffer must be valid before committing to a state transi- tion. In most applications, a receiver waits for n out of n consecutive values in the history buffer to be consistent and then commits to this transition. Committing to state changes after n of n consecutive valid message values assumes the application does not require any tolerance to invalid message values or that any single invalid message value indicates a malicious masque- rade attack. If any of the n values were invalid, the state transition does not occur. Thus, in the event of a single invalid message sample, a state transition cannot occur until another n subse-

Time-triggered authentication 38 quent valid samples have arrived.

While it is likely that an attacker will be able to forge a single packet since we use just a few authentication bits per MAC, it is unlikely that they will be able to forge so many within the his- tory of the buffer as to cause a successful masquerade attack, subsequently maliciously inducing a state change. Thus, this approach allows receivers to verify many message samples using weak per-packet assurance to achieve strong system-level assurance. If each message value is transmit- ted along with b authentication bits per receiver, the probability of per-packet forgery Pp is 2-b.

The probability of forging n consecutive message values in a history buffer is:

 



Tolerating invalid MAC tags - Optionally, it may also be useful for some applications to have

some level of tolerance to invalid message values. Allowing state changes to occur after validat- ing a subset of MAC tags in the history buffer grants this approach a degree of tolerance to in- terspersed invalid MAC tags. Without this tolerance, an attacker might increase message latency or prevent authentication altogether while remaining undetected by occasionally injecting invalid packets. Packets with a correct CRC but invalid MAC might also be caused by non-malicious faults. For example, if the sender's and receiver's notions of time differ due to a temporary inter- nal fault, the receiver would see an invalid MAC. Additionally, some message corruptions might be missed by error detection mechanisms, so occasional invalid MAC tags might result from transmission errors.

When tolerating interspersed invalid MAC tags, a state change occurs when at least k out of the past n time-triggered message values in the history buffer are consistent and valid. This al- lows a receiver to tolerate n - k invalid MAC tags interspersed within a series of n message val-

Time-triggered authentication 39 ues. State changes occur as soon as k message values out of the most n most recent have consis- tent values and are valid. An attacker can successfully forge at least k of a set n values in a histo- ry buffer with a binomial probability of:

   



1 



 

(2)

We emphasize that all message values in the history buffer (including the invalid ones to be tolerated) are all consistent.

Tradeoffs for state changing message verification - This approach for authenticating state-

changing messages enables the system designer to perform a tradeoff among authentication bits per packet, application level latency, tolerance to invalid MACs and probability of an induced failure. Based upon the criticality of the message, the designer trades increased authentication bandwidth and latency for lower probability of induced failure, and trades increased tolerance to invalid MACs for increased probability of induced failure.

Additionally, system characteristics and requirements might constrain these tradeoffs. For ex- ample, in a system with hard real-time deadlines, the maximum number of samples to authenti- cate over might be limited to the minimum number of samples of a message type expected to contain consistent message values within the maximum tolerated delay for a state change. The number of samples might be further constrained if extra slack is needed to tolerate unexpected operating conditions such as lost packets. Adding slack for unexpected operating conditions means that there would be fewer message samples to authenticate over, decreasing the possible size of the history buffer. To authenticate over fewer samples, a system designer could increase the number of bits per MAC tag, reduce the number of invalid MAC tags to tolerate, or even ad-

Time-triggered authentication 40 just the permissible overall probability of maliciously induced failure.

Effects of lost packets and message blackouts - Each individual lost packet will cause a single

message round delay before a state change can occur. In the event that the contents of a history buffer becomes stale and no longer accurately reflect the current state of the system due to a large number of consecutive packet losses (e.g., during a network blackout), a receiver can reset the contents of the history buffer and declare its contents as invalid. This work assumes that a receiver takes an appropriately safe action if it detects a network failure due to a significant number of lost packets.