CHECK-to-RELEASE is a legal arc. A fault changes the condition selecting it. Later, a token from transaction 1 is offered for transaction 2. Both requests can look structurally normal. We trace the evidence that should belong to each accepting event.
A legal arc can use a false condition
School equipment borrowing proceeds through waiting, checking eligibility, and handover: WAIT→CHECK→RELEASE. A forged success condition still follows the allowed CHECK→RELEASE route even though permission failed. Arc checks the route; state checks the current sign. Neither independently rechecks the application. Skipping straight to handover is a separate experiment, not the same effect as a false condition.
A transition relation lists permitted pairs of states. WAIT may enter CHECK; CHECK may enter RELEASE on success or ERROR on failure. The list can reject a direct WAIT-to-RELEASE jump. It cannot establish that the success input itself was authentic.
In the condition experiment, the current image is unauthorized. A single false success decision makes CHECK choose RELEASE. The arc checker still recognizes CHECK-to-RELEASE. A state-only or arc-only consumer accepts at edge 3. A fresh authorization condition is needed at the consumer as well.
The state-jump experiment is separate. One event after edge 0 sets state to RELEASE instead of CHECK. Arc policy moves it to ERROR before the edge-3 request. This trace shows useful arc coverage, but it does not remove the forged-condition witness.
Bind evidence to identity and consumption
The borrowing slip needs an application identity and a used flag. Current id 2 cannot use a valid slip for old id 1. Handover at edge 3 consumes the slip, so another request at edge 4 should be refused. These are token_id, valid, and consumed. One permission authorizes one delivery in this lesson’s contract; it is not a universal rule for borrowing systems or CPU fetch. The slip also has no cryptographic authentication.
Our token carries valid, transaction id and consumed status. Current transaction id is two. A token from prior id one remains stale even if its valid bit is true. Freshness requires valid, matching id and not consumed. These are ordinary logic fields, not cryptographic authentication.
For a valid current transaction, trusted verification creates its token after edge 1. The request can commit at edge 3. Acceptance marks it consumed after that edge. A second request at edge 4 must be denied by the old consumed state visible before the edge.
The independent monitor also tracks whether an accepted event has already consumed the one allowed delivery. It does not copy the DUT consumed field. State-only policy in the repeated-request scenario permits two requests; the second is unauthorized under this single-delivery contract.
Check permission field by field in the same RELEASE state
At RELEASE the administrator checks whether a slip exists, whether its id is 2, and whether it is unused. Only valid=1, id=2, consumed=0 satisfies fresh. Edge 3 samples unused, then marks it used after handover; edge 4 sees the update. An independent ledger records the first delivery rather than copying used from the slip. The story excludes reused identities, concurrent applications, and old slips returning after reset.
Here a token is stored evidence with a transaction identifier, not a cryptographically authenticated token. Current id is fixed at 2. Fresh means valid AND (token_id==2) AND NOT consumed.
| valid | token_id | consumed | fresh | Bound permission in RELEASE |
|---|---|---|---|---|
| 0 | 2 | 0 | 0 | No: evidence is not valid |
| 1 | 1 | 0 | 0 | No: evidence belongs to an older transaction |
| 1 | 2 | 1 | 0 | No: evidence was used |
| 1 | 2 | 0 | 1 | Yes: fields meet this lesson’s contract |
The positive control creates valid id=2 evidence after edge 1. Before edge 3, consumed=0, so the first request can transfer. The update after edge 3 sets consumed=1. Hold RELEASE and repeat the request at edge 4: fresh=0, preventing a second acceptance. An independent monitor also records the first delivery. It does not use the DUT’s consumed bit to determine its own expectation.
Arc policy asks whether a state transition is allowed. Bound policy asks whether evidence belongs to this unused transaction. This experiment compares them separately: bound does not automatically include an arc checker. A product needing both must connect and verify both, including identifier reuse, reset, abort and concurrency. Those cases are outside this fixed-id=2 model.
Separate stale state, false condition and replay
Use separate exercises for a false condition, old slip, skipped flow, and repeat collection. The old-slip scenario includes retaining and wrongly trusting id 1, not merely flipping one stored bit. Repeat collection changes the workload rather than adding an injection. Bound trusts the slip fields and issuer for this analysis. That boundary tests evidence binding without proving the slip cannot be altered.
Every trace starts at WAIT and ends at edge 4. It contains one named fault effect or a repeated workload. Condition and stale scenarios select RELEASE after CHECK; state target jumps after edge 0; repeat retains RELEASE for the second request. They are not simultaneous attacks.
The stale experiment begins with valid token id one and current id two. This setup includes retained prior evidence and a permissive decision that trusts it. Treat it as a protocol-boundary scenario, not one stored-bit XOR. Token fields, trusted verification and final grant remain unfaulted in the bound-policy tests.
SCFI incorporates control signals and execution history in a hardened next-state function. Our plain token example teaches the distinction but does not implement SCFI or inherit its probabilistic guarantees. SCFI author abstract
Read the token beside the accepting edge
Start with refused eligibility and a false success condition: arc recognizes the route and releases at edge 3, while bound lacks current permission and refuses. With genuine permission and repeat collection, state releases twice and bound only at edge 3. An authorized state jump can pass bound while arc rejects it. Route and slip checks are independent requirements that must be combined explicitly when both are needed. A permission sign before a request is not a handover.
Select condition and arc policy, with authorization false. At edge 3, RELEASE and commit are true while the independent reference is false. Change policy to bound; there is no valid current token, so no commit. Next choose stale and inspect tokenId=1 beside id=2.
For the repeated request, set authorization true. State-only policy accepts edges 3 and 4; bound accepts only edge 3. Bound checks authorization history, not arc legality. An authorized state jump therefore commits under bound but is rejected under arc. In the arc trace, edge 1 can show grant before the update enters ERROR; the request begins at edge 3, so that earlier grant is not an acceptance. All these cases have separate executed assertions.
The normal positive transaction follows WAIT, CHECK and RELEASE and commits once. Fault recovery is not required to retrace an entirely unfaulted path. A product may legitimately recover after an error, but the recovery policy must establish fresh authorization before a later sensitive acceptance.
Proposed RTL / SVA
Fresh in RTL requires valid, current identity, and unused together. Consumed updates after the accepting edge and is visible to the next request. The independent ledger checks permission and prior deliveries through reference_pass and reference_used. An ordinary slip is not SCFI. The draft also leaves new-application and abort behavior undefined, so it cannot certify a full product protocol.
Read this lesson’s property: Fresh evidence and single delivery
Check permission and no prior use at the actual handover edge. Looking only at the final used slip can miss deliveries at both edges 3 and 4; looking only at RELEASE can too. This requires a same-edge assertion and independent reference_used. Cover preserves one legitimate borrowing path, not liveness for every late, aborted, or reset application.
SVA means SystemVerilog Assertions. An assertion checks a rule; it is not the permission gate. At each rising edge outside reset, if accepted_commit (csr_commit in Lesson 9) is one, |-> requires the right-hand condition on that same edge. With no acceptance, this implication raises no authorization failure; positive controls must still demonstrate useful work. disable iff (!rst_n) excludes active reset, without proving reset safety.
Cover seeks one matching path, rather than proving every transaction correct. Reference independently records the expected result in the testbench. The harness supplies inputs, fault budgets and this oracle; DUT means design under test. A two-state model uses only 0/1 logic, excluding X and intra-cycle delay; it does not mean a two-state FSM. Revisit Lesson 1 section 5 for syntax and wiring comparisons. These snippets have not been compiled, so listing a property does not establish a proof.
assign fresh = token_valid_q && (token_id_q == current_id_i) && !consumed_q;
assign local_bad = 1'b0; // bound-only teaching model; no arc checker
assign accepted_commit = req_valid && req_ready && grant;
assign grant = (state_q == Release) && fresh && !local_bad;
always_ff @(posedge clk or negedge rst_n)
if (!rst_n) consumed_q <= 1'b0;
else if (accepted_commit) consumed_q <= 1'b1;
// A real design also specifies new-transaction and abort behavior.
assert property (@(posedge clk) disable iff (!rst_n)
accepted_commit |-> reference_pass && !reference_used);
cover property (@(posedge clk) disable iff (!rst_n)
reference_pass && accepted_commit);The sketch is uncompiled. Token storage integrity, id wraparound, abort, reset and concurrent transactions are excluded here. A real transaction-binding scheme needs enough identity to prevent collisions during its retention window. Recovery and liveness need separate properties. Lesson 9 applies similar protocol reasoning to configuration writes.
Fault laboratory
Read state as the flow sign, tokenId and id as slip and current identity, and used as the collection mark. Reset between stale and repeat experiments so earlier state does not leak into the next run. Reference is an independent collection ledger. Bound does not silently add arc checking; selecting it demonstrates that particular extra condition.
Executed finite, two-state teaching model. RTL simulation, synthesis, formal proof and silicon validation have NOT run. Reference fields are trusted testbench observations; they are not additional chip defenses.
Check your reasoning
Separate an id-1 slip used for id 2 from an id-2 slip used twice: the first mismatches identity; the second has already been consumed. Then explain why legal CHECK→RELEASE can still serve an unauthorized request. These concern identity, consumption, and real authorization. A valid route or valid flag alone is not full permission.
1. Why does arc checking miss a forged CHECK condition?
CHECK-to-RELEASE is already in its relation.
2. Is a valid token from id one fresh for id two?
No.
3. When is consumed visible for blocking?
After edge 3 update, before the edge-4 request.
4. Does the token model implement SCFI?
No.
5. What changes with concurrent transactions?
Token identity, storage and consumption must be tracked per outstanding transaction.
MY ACADEMY · LESSON FILM
Lesson video
The film explains this lesson’s data path. After a section, return to the interactive exercise and change the input or fault conditions. The animation presents a teaching model; it does not replace RTL simulation.
Narration uses a synthetic voice. Both the interaction and animation have model boundaries; interpret results using this lesson’s sources and validation scope.
This lesson’s interactive fault laboratory
This laboratory executes a finite, two-state teaching model. RTL/SVA examples remain proposed: RTL simulation, synthesis, formal proof, timing closure and silicon validation have not run. Enumeration counts are not physical attack probabilities.
Wrap-up: take this lesson into a design review
Trace the same borrowing record from waiting through edges 3 and 4, keeping route, slip, and handover history separate. The wrap-up follows those three fields. It neither requires a permanently fault-free history for legitimate recovery nor upgrades the plain slip to unimplemented cryptographic authentication.
- Threat model and assumptions
Run false condition, old slip, and skipped flow separately; repeat collection is a workload. Trusted slip fields are assumptions, not validated protection.
Edges 0..4; separate condition force, state substitution, stale-token setup and repeated workload. Tokens, verifier and final grant are trusted in bound-policy cases.
- Why the design fails
An intact id-1 slip does not belong to id 2; an id-2 slip used twice is consumed. Valid and a legal route do not replace identity and handover history.
Legal states and arcs can use false decisions. Stale or reused evidence can authorize a different delivery.
- Defenses
Mark the slip used after edge-3 handover so edge 4 sees that history. Add arc explicitly if routes also need checking; bound does not include it.
Bind token to current identity and consume it on acceptance, with separately protected generation and storage.
- Validation and checks to perform
Retain records for legitimate single borrowing, false condition, and repeat collection. Ten finite bound controls do not test id wraparound or concurrency.
Node ran ten bound-policy controls plus forged-condition, stale and repeated-acceptance witnesses; normal authorized flow commits once.
- Limits and unverified claims
The slip fields are unaltered and unsigned in this lesson. Fixed id 2 cannot establish long-term identity-reuse or real token security guarantees.
No SCFI, id-wrap, multi-transaction or physical assurance is established. Token fields remain trusted.
Try a changed assumption
Allow valid on an unauthorized id-2 slip to change from zero to one. Ask whether matching id and unused suffice. Define a token target and timing instead of reusing trusted-field conclusions.
Allow token valid itself to be faulted. Find whether id and consumed checks alone still prevent an unauthorized first delivery.
This wrap-up summarizes the lesson’s teaching cases, references and experiment scope. Checks not reported as completed remain future work.