Validity voting modifies the sending process for time-triggered packets (Section 3.3) to allow senders to attest to the validity of the most recently received message value samples of a set of message types (as defined by the voting schedule) in addition to authenticating the current mes- sage value (Figure 4.2).
Validity voting 63
Figure 4.2. Validity voting - multicast authenticator generation. Message generation process for 32 bits of data and three 8-bit MACs, using unique shared keys and synchronized times for three re-
ceivers. This packet includes three validity bits, attesting to three prior message values.
When transmitting message type MS, the sender obtains the message types the packet will at-
test to using getMessageTypesVotedOn(MS) to produce ids. For each receiver i, a sender S com-
putes the MAC function over the current header and message value, shared secret key kiS, syn-
chronized time t, and vectors rS and vS produced by getMostRecent(ids, RS, VS, CS). Before com-
puting the MAC functions, the sender replaces any element of rS with an 'invalid' value if the va-
lidity vector vS indicates the that value's packet contained an invalid authenticator. We use
MMAC as a short hand notation for a function that computes an array of MAC tags (one per re- ceiver) and truncates each MAC tag to just a few bits.
The sender includes the array of truncated MAC tags in the data payload as before, but also includes the validity vector vS. This allows receivers to recompute the MAC function over the
Validity voting 64 same values as the sender, replacing values with 'invalid' for those indicated by vS. After broad-
casting their packet, the sender optimistically sets its own validity vector assuming its packet containing the current sample of MS is received correctly and contains a valid authenticator. Fig-
ure 4.3 provides pseudo-code for the send process.
Send process, performed by node S:
• Ready to send message value mS of type MS to all nodes • ids ← getMessageTypesVotedOn(MS)
• <rS, vS, cS> ← getMostRecent(ids, RS, VS, CS)
• For any element of vS that is '0', replace the corresponding element of rS with 'invalid' • tag_arrayS ← MMAC(mS | t | rS | vS)
• Broadcast {mS | vS | tag_arrayS} • setNewest(mS, 'valid', RS, VS, CS)
Receive process, performed by node i: • Receive {mS | vS | tag_arrayS}
• ids ← getMessageTypesVotedOn(MS) • If transmission error occurs
• setNewest('lost', 'valid', Ri, Vi, Ci) • Return from receive process
• <ri, vi, ci > ← getMostRecent(ids, Ri, Vi, Ci)
• For any element of sender's vS that is '0', replace the corresponding element of receiver's ri with 'invalid' • tagi ← MACkis(mS | t | ri | vS)
• If (tagi = tag_arrayS[i])
Accept new value as valid
• setNewest(mS, 'valid', Ri, Vi, Ci) • vi ← bitwiseAnd(vi, vS) • updateValidity(ids, vi, Vi)
• For each element in vi that is '1', increment ci counters • updateConfirmations(ids, ci, Ci)
• Else,
Reject previous values the current MAC tag included
• setNewest(mS, 'invalid', Ri, Vi, Ci) • Set all elements in vi to '0' • updateValidity(ids, vi, Vi)
Final Verification process, performed by receiver i:
After Receive process is completed, perform final verification step for each message type that node i should have received all z secondary confirmations:
• Reject value as masquerade attempt if bit in Vi is '0'
• Accept value as lost if bit in Vi is '1' and (value from Ri is "lost" or confirmations in Ci < z)
• Accept value (valid and not lost) if the corresponding bit from Vi is '1' and number of confirmations in Ci equals z.
Figure 4.3. Pseudo-code for validity voting. Message generation and verification processes during time t.
Validity voting 65 Attesting to message values in this way has several benefits:
• A sender does not need to explicitly retransmit any values it is attesting to. By including them as inputs to the MAC function, two nodes observing different values from the network, each will get a different resulting MAC tag after computing the same MAC function. With multiple attestations, there is an increased probability that a group of receivers will detect any differences in observed message values.
• A single invalid message value (detected and recorded by a voting receiver) cannot cause fu- ture messages to be marked as invalid. By replacing any invalid message value with the pre- defined 'invalid' error code and explicitly including a validity bit prevents further message values from being falsely marked as invalid. Both the sender and receiver will compute the MAC function over the same error code, instead of potentially different values.
• A symmetric packet loss does not cause any message values to be marked as invalid. Similar to the way invalid message values are handled, using a predefined error code for any 'lost' values allows all nodes to compute their MAC functions over the same set of values, rather than whatever erroneous value might have been observed from the network.
4.5.2 Verifying a packet
We break down the message verification into two processes. Each time a receiving node gets new messages from the network, the receiver executes the Receive process for each new mes- sage value it has received. Once the Receive process is completed for all new values, it executes the Final Verification process on each value for which all of its z secondary confirmations should have been received (Figure 4.3).
Validity voting 66
Receive process - First, for the received message type MS, the receiving node i executes getMes- sageTypesVotedOn(MS) to produce ids, which contains the message types voted on by MS. If a
transmission error occurs, receiver i records a 'lost' value for the received message type, marks it as valid, commits this information using the setNewest function, and exits the receive process without incrementing any confirmation counters. Otherwise, the receiver executes getMostRe- cent to obtain the most recent set of message values ri received from the network that are voted
on by this sample of MS, corresponding validity vector vi, and confirmation vector ci. The receiv-
er replaces any element of ri with an 'invalid' value if the sender's transmitted validity vector vS
indicates the sender believes that value's packet contained an invalid authenticator. The receiver recomputes the MAC function, and compares the MAC tags.
The MAC tags should only be equal if the sender and receiver agree on the current and prior values (with the infrequent exception of MAC collisions). If they match, the receiver accepts the current value as valid. If the tags do not match, the receiver rejects the current value and all prior values that the sender is attesting to. Because the attested values are sent implicitly as inputs to the MAC function, the receiver cannot determine which value caused the disagreement and con- servatively rejects all attested values.
For a valid packet, receivers update their validity vectors for each attested value. Receivers record an attested value as invalid if either the sender's valid packet indicated it was invalid or the receiver originally saw that value as invalid. Receivers perform a bitwise logical And opera- tion on the vi and vS vectors. For any value in ri that is still considered valid in vi after the vote,
the receiver increments the corresponding counter in the confirmation vector ci. This process on-
Validity voting 67 Once this process is complete, the results are committed to the complete vectors Ri, Vi, and Ci. Final Verification process - Once the Receive process is completed for any new message val-
ues, the receiver checks any message values for which all of its z secondary confirmations should have been received. A receiver checks for three possible outcomes for a value in the following order:
Invalid - First, if the bit in the validity vector Vi is '0', then the receiver rejects the value as
invalid. Either the original packet containing that message value had an invalid authenticator, at least one of the attesting packets had an invalid authenticator, or at least one voting node claimed that the packet was a masquerade attempt.
Lost - Second, if the bit in Vi is '1', and the value is 'lost', then the receiver accepts that the
packet suffered a transmission error and no other receivers claimed it to be a masquerade at- tempt. Similarly, receivers accept a value as lost if it is valid, but an insufficient number of posi- tive confirmations were received (i.e., confirmations in Ci < z).
Valid - Finally, if Vi indicates the value is valid, the value is not 'lost', and the counter in the
confirmation vector Ci indicates a sufficient number of positive confirmations from other voting
nodes, then the value is accepted as valid.
For a received value to be accepted as valid, there must be a unanimous vote on the authentic- ity of the value. The packet originally containing that value must have a valid MAC tag, all z attesting packets must also have valid MAC tags, and the validity vectors of each attesting mes- sage must indicate each voter observed a valid MAC tag in the original packet. To fool a single receiver into accepting an injected value, an attacker must successfully forge not only the MAC
Validity voting 68 tag for that receiver, but must also successfully forge the z other tags to or from the rest of the voting nodes.
We emphasize that successfully forging one or two packets, then provoking receivers to drop further attestation packets does not increase an attacker's chance of forging a message. Verifica- tion of a message value requires a node to receive all packets containing votes for that value. By dropping any attesting packets, the packets targeted for forgery will also be dropped by receivers.