A message can arrive with a valid authentication result and still be unsuitable for use. It might repeat a previously accepted message, belong to another receiver, or request an operation that its source is not permitted to request. These are different problems. NIST's explanation of message authentication explicitly separates it from protection against replay. Its access-control guidance also distinguishes authentication from permission. [2][4] A useful security explanation must say which question each check answers instead of turning one successful check into a general approval.

This distinction matters in vehicles because electronic information can influence physical systems. NHTSA's 2022 guidance discusses replay, integrity compromise and spoofing within a broader protection strategy; it describes itself as voluntary, non-binding guidance. [1] We will use an original paper example involving an imaginary display, with no connection to a real car. Every record, counter and verification result is supplied for the lesson. The example shows how acceptance decisions depend on retained history and current rules; it does not test a vehicle or provide a complete communication design.

Message authentication, replay resistance, destination binding and authorization establish different properties. A valid message authentication code, or MAC, supports an authenticity/integrity claim under its cryptographic and key-management assumptions. It does not inherently make the presented record unique, timely or permitted. NIST SP 800-38B addresses replay separately, while SP 800-162 distinguishes authentication from authorization. [2][4] The relevant result is therefore an acceptance predicate with stated inputs, rather than the isolated output of a cryptographic verifier.

NHTSA's 2022 voluntary, non-binding guidance identifies replay, integrity compromise and spoofing as concerns for critical information on shared channels and places communication controls within a layered approach. [1] Our model is much narrower: a serialized paper receiver for display records, with stipulated verification booleans, trusted initial state and explicit policy. All numerical records are original. No MAC implementation, packet exchange, vehicle or control system is executed, and passing this teaching predicate is not evidence of whole-vehicle safety.

A MAC is a value calculated from a message and a secret key. Verification checks the supplied message and MAC against the relevant key. [2] That relationship is more specific than a reassuring label such as 'secure message'. If an important field lies outside the protected content, a successful check cannot establish its association with the protected fields. Start by naming exactly what belongs to the record. Our imaginary record contains a session label, an intended receiver, a requested purpose, a counter and a display value.

For this lesson, assume those five fields have one clear, agreed encoding and are authenticated together. A record might belong to session S, address display A, request update-display, carry counter 41 and supply a value. We will write 'valid' or 'invalid' for its supplied verification result, without inventing a real tag. The display value is part of the protection even though we do not need its contents for the decision table. A check over the counter alone would answer a different question from a check over the complete record.

MAC generation takes a message and key; verification evaluates a candidate tag for the supplied message under that key. [2] Define our protected message as an unambiguously encoded tuple M=(s,r,o,n,v): session, receiver, operation, counter and display value. This tuple is an assumption of the paper model, not a proposed vehicle frame layout. Its encoding must bind both values and field boundaries for the stated comparison to have a definite meaning. No real bytes or cryptographic outputs are constructed here.

Let V(K,M,t) denote the stipulated verification result under an already trusted key association K. The example assigns that result rather than computing it. Protecting the complete tuple binds the operation and receiver to the counter and value within this model; checking only a subset would not establish the same relationship. The display value can remain unspecified because none of our acceptance conditions depends on its magnitude or wording. That omission from the table does not remove it from M. The distinction preserves what the cryptographic check actually covers.

The secret key's distribution changes what a valid result can mean. In a symmetric MAC arrangement, parties with the required key and generation access can produce valid tags. NIST's replay discussion even considers a verifier encountering a message that the verifier itself generated earlier. [2] If two imaginary modules share the same generation capability, a valid tag alone cannot tell us which physical module created a particular record. The claimed source label must be interpreted within the system's trusted key and role arrangement.

There is another limit: verification gives cryptographic assurance, not a promise that guessing or implementation failure is impossible. NIST discusses the conditions behind that assurance. [2] We do not need to choose a tag length or calculate an attack probability to follow this lesson. We only need to keep the conclusion narrow. A valid record is still subject to its intended context, the receiver's history and permission rules. Nor does authentication prove that an authenticated display value accurately describes the physical world; protection of a statement is different from evidence that the statement is true.

For a symmetric MAC, a verifier that possesses the generation key generally has the capability needed to generate tags as well. Successful verification consequently does not isolate a unique physical origin among all parties sharing that capability. SP 800-38B's Appendix C explicitly allows the possibility that a presented message/tag pair was previously generated by the verifier. [2] Our K association is therefore a trusted logical security context, not a measured attribution of a record to one particular ECU or person.

The same publication qualifies the assurance of a VALID result rather than treating forgery as mathematically impossible. [2] This article assumes the verifier's reported booleans for its state exercise; it makes no current algorithm-approval, tag-length or key-selection recommendation. Even within that assumption, authenticity does not establish physical measurement correctness. A permitted key holder can authenticate inaccurate content, and several key holders may be indistinguishable to the MAC check. Those limits are separate from the replay and authorization failures we can demonstrate with the supplied records.

Set the display's active session to S and its own name to A. Its current permission rule allows update-display but does not allow clear-display. Give it a notebook containing 40, the counter of its last accepted record. A new candidate must have a valid authentication result, match session S, name receiver A, request the allowed purpose and carry a counter greater than the notebook value. These are our invented rules. They illustrate the separate message-history and permission questions described by NIST. [2][4]

Only when every condition passes does the display accept the record and replace its notebook value with that record's counter. If any condition fails, the old notebook value stays. We consider one record at a time and use ordinary positive integer counters without a wraparound limit. The notebook is assumed trustworthy at the start. This deliberately simple ordering rule will reject some late records that were never accepted before. That is part of its defined behavior, not a claim that every real vehicle uses the same rule.

Let L=40 be the last accepted counter for the receiver's chosen K association, and let the active session be S. Define acceptance as the conjunction V=true, s=S, r=A, Authorized(K,o)=true and n>L. The current policy permits only o=update-display. The next state is L'=n on acceptance and L'=L otherwise. This is an original logical model informed by NIST's separation of authenticated freshness information and authorization. [2][4] It is not an implementation of AUTOSAR SecOC.

Candidate processing is serialized, the initial association and state are trusted, and counters are unbounded positive integers. Those assumptions make the transition relation completely specified for this exercise. They exclude races, finite-field rollover, key establishment and storage failures from the main trace. The rule is strict monotonic acceptance, not merely a list of previously seen values. Consequently, its admissible set changes after each acceptance: all counters at or below the new L become ineligible, whether or not the receiver previously processed those particular values.

Start with 40 in the notebook. Row 1 is a valid S/A/update-display record with counter 41: accept it and write 41. Row 2 repeats that same record: its authentication still passes, but 41 is no longer greater than 41, so reject it. Row 3 claims counter 500 but has an invalid authentication result: reject it and keep 41. Row 4 is a valid, correctly addressed and permitted record with counter 43: accept it and write 43. Row 5 is a similarly valid record with counter 42: reject it because our strict rule now requires more than 43.

Row 6 has valid authentication and counter 44, but asks for the forbidden clear-display purpose, so the notebook stays 43. Row 7 is a valid permitted update with counter 45: accept it. Row 8 has valid authentication and counter 46, but names receiver B: reject it and keep 45. Row 9 is a valid S/A/update-display record with counter 47: accept it. Four rows were accepted: 1, 4, 7 and 9. Five were rejected for different reasons. These are outcomes of the supplied paper rules, not a measured security success rate.

The nine counters are 41, 41, 500, 43, 42, 44, 45, 46 and 47. All candidates use session S. Row 3 alone has V=false; row 6 uses clear-display; row 8 addresses B. Every other context field matches the permitted case. Row 2 is an exact replay of row 1. Starting from L=40, the post-candidate state sequence is 41, 41, 41, 43, 43, 43, 45, 45, 47. Acceptance occurs exactly at rows 1, 4, 7 and 9 under the defined conjunction. Each unspecified display value remains inside the protected tuple.

The failure predicates differ. Row 2 fails n>L after its prior acceptance. Row 3 fails authentication despite its large counter. Row 5 fails strict order after row 4, even though 42 has not previously been accepted. Row 6 fails authorization and row 8 fails destination matching. Each rejected row preserves L. Counting four acceptances and five rejections is an enumeration of this constructed input, not evidence of a detector's accuracy, an attack frequency or a vehicle's availability. The state sequence is the useful result because it exposes which information each decision actually consumes.

Row 3 is a useful check on the meaning of the notebook. It contains 500, much larger than 41, but the record fails authentication. If we wrote 500 into the notebook anyway, the valid row 4 with counter 43 would then look too old. That would make an unaccepted claim control later decisions. Under our declared rule, 500 never becomes the last accepted counter. The notebook remains 41 until row 4 passes every condition and advances it to 43. This is why the update rule belongs in the explanation, not just the test for a large number.

Row 5 reveals a different tradeoff. Counter 42 is not a duplicate of an earlier accepted counter, yet it arrives after 43 and is rejected. A strict order rule can exclude delayed or reordered records as well as exact repeats. NIST identifies replay, out-of-sequence messages and missing messages as related but distinct matters for a controlling protocol. [2] Other designs can retain a more detailed history and allow selected out-of-order arrivals. Our notebook does not do that. A rejection here establishes failure of this rule, not proof that someone acted maliciously.

For row 3, V=false forces rejection, so the transition is L'=41 despite n=500. Assigning L'=max(L,n) before establishing acceptance would be a different state machine: it would make row 4 fail at 43≤500. That counterexample explains the invariant used here: rejected candidates do not alter accepted history. It is a statement about this logical state variable, not a claim that a real receiver keeps no diagnostic counters or logs when authentication fails.

At row 5, the previously unseen value 42 satisfies 42≤43 and is rejected. Thus strict monotonicity is stronger than duplicate exclusion. A protocol that tolerates reordering would need a different freshness policy and sufficient state to distinguish permitted late records from replays. SP 800-38B describes authenticated sequence information as a possible basis for detecting replay, out-of-order and missing messages, leaving the controlling protocol to supply the behavior. [2] Neither acceptance of a numerical gap nor rejection of an old counter proves how the network behaved or why a candidate arrived late.

After row 9, the notebook holds 47. Consider two separate alternatives, each with a valid, permitted S/A record carrying counter 48. In the first, a supplied creation time is 100 seconds and arrival is at 700 seconds. In the second, creation is at 694 seconds and arrival is again at 700 seconds. Both counters exceed 47. Their ages are very different: 600 seconds and 6 seconds. Passing the counter test alone cannot distinguish those ages because that test never reads a clock.

Now add a separate, invented age rule: accept only ages from zero through 30 seconds. Assume the creation timestamp is authenticated with the record and both times use an accurate common clock. The first alternative fails that extra rule; the second passes. NIST lists timestamps as one possible kind of authenticated identifying information. [2] Our 30-second choice is only an explanatory threshold. Without the stated timestamp and clock assumptions, subtracting two displayed times would not automatically establish a trustworthy message age. A first delivery can therefore be new to the receiver's counter history and still be old in elapsed time.

With L=47, take two independent candidates whose protected counter is n=48 and whose other baseline predicates pass. Add an authenticated creation timestamp only for this separate extension. At receiver time tr=700 s, candidate A has tc=100 s and candidate B has tc=694 s. The ages tr−tc are respectively 600 s and 6 s. Both valid records satisfy n>L despite their different elapsed ages. This is a direct counterexample to inferring a wall-clock age bound from the monotonic-counter predicate alone.

Under an additional original rule 0≤tr−tc≤30 s, only B passes. The subtraction assumes a trustworthy shared time reference, correct timestamp binding and the supplied times; it does not establish clock synchronization, measurement error or resistance to all timing attacks. SP 800-38B names timestamps alongside sequence numbers and nonces as possible authenticated protocol information. [2] These mechanisms need their own semantics. A counter constrains ordering relative to retained state, whereas our added timestamp rule constrains age. The two can agree or disagree without either arithmetic calculation being wrong.

Return to row 8, which names receiver B. Its authentication is valid under the imaginary shared association, and 46 exceeds display A's current notebook value of 45. It still does not belong at A. Because the receiver name is protected together with the other fields, A can read an authenticated statement that the intended receiver is different. Authentication supplies useful information here, but the destination comparison must actually use it. Merely carrying a receiver field is not the same as enforcing that field.

The operation field works in a similar way. Row 6 authentically requests clear-display, while the current permission allows only update-display. A genuine request can exceed its allowed scope. NIST's access-control treatment bases permission on the subject, protected object, requested operation and relevant context. [4] In our model, the key association supplies the trusted role context; an arbitrary name written inside a message does not grant a new role. Keeping destination and permission distinct also makes the rejection reason useful: a request for a different receiver is not identical to a forbidden request for this receiver.

At row 8, V=true and 46>45, but r=B≠A. Binding r into M prevents our interpretation from treating it as an unrelated external label; the acceptance predicate must still compare that authenticated value with the local receiver context. An authenticated field is evidence consumed by a policy decision, not a policy decision by itself. Here the same K association is stipulated to verify the candidate, so we cannot use successful verification as a substitute for destination matching.

Authorization is independently evaluated as Authorized(K,o), using a trusted association and the requested operation. Row 6 has o=clear-display and fails that gate even though its tag is valid. SP 800-162 describes access decisions in terms of subjects, objects, operations and applicable policy or environment. [4] The toy rule does not implement an enterprise ABAC architecture; it uses the narrower distinction between an authenticated request and permission to perform it. Inferring a privileged role solely from an untrusted sender label would change the trust assumptions and invalidate the stated example.

Take the old valid row 1 record with counter 41 after the main trace has finished. With 47 still in the notebook, that old record is rejected. Now imagine the notebook is erased to zero while session S and the permission remain unchanged. The very same old record passes our counter rule because 41 is greater than zero. Its tag did not change and no new tag had to be invented. What changed was the receiver's memory of the past. This is a logical comparison between two starting states, not a procedure for resetting a real device.

Preserving trustworthy history would retain the rejection. A separately established new session T would also make this particular S record fail the session check, even with a new counter history. But merely typing a different session label is not a complete solution: the system would need a trustworthy way to establish, authenticate and distinguish the active session. NIST's replay discussion places identifying information within the controlling protocol. [2] The lesson is that replay protection depends on how a record relates to live reference state, including what happens when that state is restarted or replaced.

Use the exact earlier record M1 with s=S and n=41. Under retained state (active session S,L=47), n>L fails. Under a separate hypothetical reset state (S,0), all baseline predicates pass and L becomes 41. The original tag remains valid in both cases. Replay resistance therefore does not follow solely from authenticity of the counter field; it also depends on the reference state against which that field is evaluated. This counterexample follows directly from the declared transition relation.

A third comparison assumes an independently trusted active session T with L=0. The old record fails s=T because it still carries S, regardless of its passing numerical counter comparison. Establishing a unique, authenticated session and preserving reliable state across restarts are outside this paper predicate, so the example does not claim that an arbitrary epoch string solves recovery. SP 800-38B treats replay defenses as responsibilities of the surrounding protocol. [2] It is consequently important to ask which state survives a restart and how any replacement state becomes authoritative.

Suppose a separate candidate arrives after the main trace: counter 48, session S, receiver A and the update-display purpose, with valid authentication. If the current permission still allows that purpose, it passes our baseline rule. Now change only the permission: the association is no longer allowed to request updates. The same candidate must be rejected and the notebook remains 47. Withdrawal of permission does not require the old message's tag to become mathematically invalid. The decision changes because the authority to perform the operation has changed.

This is why a successful authentication log and an accepted-action log should not be read as the same statement. NIST describes authorization as a decision governed by applicable policy and context. [4] A system may recognize an authenticated source while denying one of its requests. In the paper example, we can point to the exact rule that changed. In a product claim, useful evidence should similarly identify the permitted operation and the policy used at the time, rather than presenting possession of a recognized credential as unlimited authority.

For a separate post-trace candidate, set n=48, s=S, r=A and o=update-display with V=true. At L=47, all structural and counter conditions pass. If Authorized(K,o) changes from true to false, acceptance changes to rejection and L stays 47. No alteration to M, the verification key or the stipulated valid tag is needed for this logical change. Authentication and authorization are separate inputs, so a policy change need not be described as a cryptographic verification failure.

SP 800-162 treats privileges as authorized behavior embodied in policy and describes context-dependent access decisions. [4] Our example isolates that principle without claiming an ABAC deployment, a revocation protocol or a real vehicle capability. It also shows why records of verifier output alone cannot reconstruct acceptance: the policy state at decision time matters. A meaningful interpretation needs the relevant association, operation and authority, as well as the message history. Otherwise a valid old authentication result can be mistaken for evidence of current permission.

The AUTOSAR FO R23-11 SecOC document provides a concrete automotive example: it uses freshness management and includes a data identifier, protected payload and complete freshness value in the authentication input. Its stated AP/CP compatibility scope assumes Ethernet. [3] This supports the importance of binding context and freshness to content, without making our simple notebook rule a description of that protocol. It also does not show that every car, bus type or software version implements the same arrangement.

Broader protection still has architectural questions. NHTSA's dated guidance discusses segmentation and isolation between externally connected functions and lower-level vehicle systems. [1] A message check and a network boundary address different parts of the problem. An authenticated statement might be permitted on one path while being irrelevant or inappropriate on another. Reading a feature claim therefore means preserving its scope: which component, which message, which protected fields and which surrounding controls? A named standard or cryptographic primitive does not, by itself, answer all of those questions.

In the pinned AUTOSAR FO R23-11 protocol document, SecOC uses external freshness management and authenticates the data identifier, protected payload and complete freshness value together. The document states an Ethernet assumption for AP/CP compatibility. [3] Those bounded facts illustrate context/freshness binding; they do not establish the toy receiver's strict acceptance policy as SecOC behavior. No assertion is made about the latest release, universal CAN coverage, a particular deployed ECU or complete conformance.

NHTSA's 2022 guidance separately recommends architectural segmentation and isolation. [1] Such boundaries constrain possible communication paths and consequences, while our record predicate constrains one local admission decision. These layers cannot be collapsed into a single 'authenticated equals safe' statement. The identity of the component, the authenticated input, the active policy and the surrounding system behavior remain distinct evidence needs. A source describing one mechanism is not evidence that an unspecified product implements it correctly or that its failure response is appropriate for a physical driving situation.

Our nine records offer a practical way to read a security explanation. Ask what was authenticated, then ask what state the receiver compared it against. Follow with the intended destination and allowed purpose. A valid repeat failed after 41 was saved; a never-before-accepted 42 failed after 43; a high invalid 500 never became history. Those outcomes make sense only when the acceptance rule and notebook transition are visible. The separate clock example then shows why 'newer than the last accepted counter' cannot stand in for 'created recently'.

Finally, keep the claimed result at the level of the evidence. Authenticity does not prove physical truth, a counter does not supply a clock, and permission for one operation is not permission for every operation. [1][2][4] A real system also needs suitable behavior when data is rejected or missing, which our display puzzle does not determine. The useful conclusion is precise: under declared assumptions, a receiver can correctly reject an authenticated record. Explaining why it rejected that record is more informative than treating every valid tag as an instruction to proceed.

Interpret acceptance as a result bound to M, K, active session, local destination, retained L and current authorization. The trace demonstrates four acceptances and five distinct rejected candidates under that joint predicate. Its invariants include strictly increasing accepted counters and unchanged accepted history after rejection. Its limits are equally explicit: strict order can reject unseen late records, state reset can readmit an old record, and a larger counter alone imposes no wall-clock age bound. These are consequences of one specified model, not measurements of deployed security.

The primary sources support keeping message authentication, replay controls, permissions and architectural protections separate. [1][2][4] Our construction supplies an original way to test the resulting claims without implementing a vehicle protocol. Evidence for safe fallback, availability, physical truth, key isolation or recovery would require additional system-specific information. The final question is therefore not simply whether verification passed, but what that result authorizes the reader to conclude under the recorded state and policy. A justified rejection can be the correct outcome even when the authenticated bytes themselves are unchanged.