WEBVTT

1
00:00:00.000 --> 00:00:02.861
The firmware signature has failed.

2
00:00:02.861 --> 00:00:07.828
The checker stores zero, and the processor should
remain blocked.

3
00:00:07.828 --> 00:00:10.578
Now change just the stored bit to one.

4
00:00:10.578 --> 00:00:17.230
The checker has not run again, and the signature
has not changed, but permission can open.

5
00:00:17.230 --> 00:00:24.368
Follow the answer through the register, the grant
logic, and the fetch interface.

6
00:00:24.368 --> 00:00:31.846
A wrong value at any of these stages can change
whether the firmware is allowed to start.

7
00:00:32.167 --> 00:00:36.487
Instruction fetch is a request for a program
instruction.

8
00:00:36.487 --> 00:00:43.383
In this simplified interface, valid presents the
request, ready says the receiver can accept it,

9
00:00:43.383 --> 00:00:45.654
and grant supplies permission.

10
00:00:45.654 --> 00:00:50.570
Count a fetch only when all three hold at the
agreed rising edge.

11
00:00:50.570 --> 00:00:54.489
Execution and retirement happen beyond that
handoff.

12
00:00:54.489 --> 00:01:00.794
The animation explains a teaching model; it is
not a complete CPU simulation or a silicon

13
00:01:00.794 --> 00:01:02.167
measurement.

14
00:01:02.458 --> 00:01:04.776
The register holds two flags.

15
00:01:04.776 --> 00:01:10.704
Checked records that verification finished;
verified records whether it passed.

16
00:01:10.704 --> 00:01:16.887
This failed signature still finishes the check,
giving checked one and verified zero.

17
00:01:16.887 --> 00:01:21.843
Completion provides no evidence that a failed
image is authorized.

18
00:01:21.843 --> 00:01:24.001
Reset begins a new boot attempt.

19
00:01:24.001 --> 00:01:29.228
We are examining one clock domain and a small
part of the boot controller.

20
00:01:29.542 --> 00:01:32.957
Once checked becomes one, normal writes stop.

21
00:01:32.957 --> 00:01:37.244
The register retains verified, while grant keeps
reading it.

22
00:01:37.244 --> 00:01:43.757
A storage upset at this point changes the value
seen downstream without another normal write.

23
00:01:43.757 --> 00:01:47.137
Notice which switch is closed: the write enable.

24
00:01:47.137 --> 00:01:54.067
The read path remains connected, so an answer
that is no longer being updated still needs

25
00:01:54.067 --> 00:01:55.388
protection.

26
00:01:55.708 --> 00:02:00.039
Before the fault, checked is one and verified is
zero.

27
00:02:00.039 --> 00:02:02.059
Their AND keeps grant low.

28
00:02:02.059 --> 00:02:07.019
Flip verified to one and both inputs now hold,
raising grant.

29
00:02:07.019 --> 00:02:10.148
A valid request with ready high can then be

30
00:02:10.148 --> 00:02:12.722
accepted at the sampling edge.

31
00:02:12.722 --> 00:02:19.410
The independent observer still records the
original failed signature, so this accepted fetch

32
00:02:19.410 --> 00:02:21.014
is unauthorized.

33
00:02:21.333 --> 00:02:27.921
Allow one result-register bit to invert after
verification has stored its answer.

34
00:02:27.921 --> 00:02:32.118
Each boot attempt has at most one event at one
location.

35
00:02:32.118 --> 00:02:35.768
The bit stays changed until overwrite or reset.

36
00:02:35.768 --> 00:02:41.052
One event can have several later consequences
without receiving a fresh budget.

37
00:02:41.052 --> 00:02:46.718
These limits make the counterexample repeatable
and define which question it answers.

38
00:02:47.000 --> 00:02:53.317
Trust the checker, independent observer, clock,
reset, grant gate, and receiving interface in

39
00:02:53.317 --> 00:02:54.450
this experiment.

40
00:02:54.450 --> 00:02:56.564
Target only the result register.

41
00:02:56.564 --> 00:03:01.171
Observe from reset release until the first fetch
or a declared deadline.

42
00:03:01.171 --> 00:03:07.281
Adding comparator faults, final-grant faults, or
multiple targets changes the experiment.

43
00:03:07.281 --> 00:03:11.462
Its earlier result does not cover those newly
added locations.

44
00:03:11.750 --> 00:03:14.878
The animation directly changes zero to one.

45
00:03:14.878 --> 00:03:21.128
Voltage, clock, electromagnetic, and laser
disturbances have physical coupling points and

46
00:03:21.128 --> 00:03:21.920
durations.

47
00:03:21.920 --> 00:03:27.775
Measurements and timing analysis are needed to
connect those effects to this bit model.

48
00:03:27.775 --> 00:03:31.692
We have reproduced a wrong path under an
assumption.

49
00:03:31.692 --> 00:03:37.687
We have not established that a particular
physical technique creates the same effect on a

50
00:03:37.687 --> 00:03:38.437
chip.

51
00:03:38.708 --> 00:03:42.248
Draw the permission path as a state machine.

52
00:03:42.248 --> 00:03:43.783
WAIT leads to CHECK.

53
00:03:43.783 --> 00:03:48.477
Failure should select ERROR, while success
selects RELEASE.

54
00:03:48.477 --> 00:03:53.170
A corrupted condition can take an existing edge
into RELEASE.

55
00:03:53.170 --> 00:03:58.707
Its state code is legal, so an illegal-state
check has no reason to reject it.

56
00:03:58.707 --> 00:04:05.478
Whether this transition is authorized depends on
the verification evidence for this attempt.

57
00:04:05.750 --> 00:04:08.984
CHECK to RELEASE may also be an allowed edge.

58
00:04:08.984 --> 00:04:15.215
Inspect the condition used on this attempt, along
with the state and the work that actually

59
00:04:15.215 --> 00:04:15.953
happened.

60
00:04:15.953 --> 00:04:19.807
A completed digest establishes completion of
hashing.

61
00:04:19.807 --> 00:04:24.876
Signature authorization needs its own completion
and pass evidence.

62
00:04:24.876 --> 00:04:30.890
Checking that an edge exists, or adding another
legal-code check, does not establish that

63
00:04:30.890 --> 00:04:32.981
required work succeeded.

64
00:04:33.250 --> 00:04:37.416
Return to the interface and sample its signals
together.

65
00:04:37.416 --> 00:04:43.364
Valid and ready create an opportunity to
transfer, with grant supplying permission.

66
00:04:43.364 --> 00:04:46.338
Accepted commit records that rising edge.

67
00:04:46.338 --> 00:04:52.809
At the same edge, the security check asks whether
this image really completed and passed

68
00:04:52.809 --> 00:04:53.875
verification.

69
00:04:53.875 --> 00:04:59.558
Watching a flag alone can miss a fetch that has
already crossed the interface.

70
00:04:59.875 --> 00:05:06.748
Read this illustrative order: fault at t, fetch
acceptance at t plus one, alert at t plus two,

71
00:05:06.748 --> 00:05:08.481
and reset at t plus five.

72
00:05:08.481 --> 00:05:12.901
These are teaching intervals, not measured
product delays.

73
00:05:12.901 --> 00:05:18.730
An eventual-alert test may pass even though
unauthorized acceptance happened earlier.

74
00:05:18.730 --> 00:05:23.290
Alerts support reporting and recovery, but cannot
withdraw that handoff.

75
00:05:23.290 --> 00:05:28.490
Prevention and notification need separate
observation points and deadlines.

76
00:05:28.750 --> 00:05:34.741
Local blocking must remove invalid permission
before the next possible accepting edge.

77
00:05:34.741 --> 00:05:38.293
Alert handling can then report, escalate, or
clean up.

78
00:05:38.293 --> 00:05:45.079
A product also has other handoffs: prefetch may
obtain instructions, DMA may move data, and debug

79
00:05:45.079 --> 00:05:46.169
may gain access.

80
00:05:46.169 --> 00:05:52.750
Protecting CPU reset alone does not automatically
protect these separate acceptance events.

81
00:05:53.000 --> 00:05:56.730
Replace the single result bit with four bits.

82
00:05:56.730 --> 00:06:00.724
True is zero one one zero; false is one zero zero
one.

83
00:06:00.724 --> 00:06:05.276
All four positions differ, giving Hamming
distance four.

84
00:06:05.276 --> 00:06:08.991
The consumer must compare the entire true word.

85
00:06:08.991 --> 00:06:15.755
Testing one bit, or accepting any nonzero value,
does not use that separation to protect the

86
00:06:15.755 --> 00:06:17.923
authorization decision.

87
00:06:18.208 --> 00:06:20.882
Flip one bit of one zero zero one.

88
00:06:20.882 --> 00:06:28.211
The four candidates on screen each differ from
the true word, so exact comparison rejects them.

89
00:06:28.211 --> 00:06:33.433
This check assumes two-state inputs and a
single-bit fault budget.

90
00:06:33.433 --> 00:06:37.464
It establishes rejection of these storage
changes.

91
00:06:37.464 --> 00:06:43.047
It does not cover every fault or establish
security for the whole chip.

92
00:06:43.333 --> 00:06:46.090
Move the target before the encoder.

93
00:06:46.090 --> 00:06:53.162
Corrupt the failed decision into success, and the
encoder correctly produces zero one one zero for

94
00:06:53.162 --> 00:06:54.014
that input.

95
00:06:54.014 --> 00:06:59.894
The word is legal and matches the full
comparison, yet authorizes the wrong image.

96
00:06:59.894 --> 00:07:03.747
Coding can constrain specified storage
modifications.

97
00:07:03.747 --> 00:07:07.262
The decision's source still needs its own
evidence.

98
00:07:07.542 --> 00:07:14.167
A stronger grant requires completion, the exact
true word, an allowed phase, and no local fault.

99
00:07:14.167 --> 00:07:17.102
Each condition needs a trustworthy source.

100
00:07:17.102 --> 00:07:23.289
The comparator and final gate also affect the
result, even when the expression contains more

101
00:07:23.289 --> 00:07:23.844
checks.

102
00:07:23.844 --> 00:07:27.092
This logic specifies a consumer contract.

103
00:07:27.092 --> 00:07:33.849
A finished protection mechanism and a complete
reset controller still require further design.

104
00:07:34.167 --> 00:07:39.997
The observer independently records completion and
authorization for this image.

105
00:07:39.997 --> 00:07:46.592
When the design accepts a fetch but the observer
still records failure, the security check fails.

106
00:07:46.592 --> 00:07:53.162
Copying the attacked verified bit would make both
sides change together and hide the disagreement.

107
00:07:53.162 --> 00:07:57.624
Keep the reference independent of the fault path
being evaluated.

108
00:07:57.917 --> 00:08:03.211
The finite model checks sixteen codewords, four
single-bit faults, and six scenarios.

109
00:08:03.211 --> 00:08:08.305
Its expected outcomes include successful bypasses
of deliberately vulnerable cases.

110
00:08:08.305 --> 00:08:10.852
Reproducing them can therefore print PASS.

111
00:08:10.852 --> 00:08:16.033
No RTL simulation, formal proof, or silicon test
was completed by that run.

112
00:08:16.033 --> 00:08:21.497
Read each case's expected rejection or
unauthorized acceptance alongside the final

113
00:08:21.497 --> 00:08:22.378
status.

114
00:08:22.667 --> 00:08:28.220
Switch to an authorized image without faults and
check that it can obtain a fetch.

115
00:08:28.220 --> 00:08:34.675
Holding grant permanently low may satisfy the
rejection checks while preventing boot entirely.

116
00:08:34.675 --> 00:08:38.375
Keep evidence that authorized operation is
reachable.

117
00:08:38.375 --> 00:08:44.824
A cover can exhibit that path; a complete
requirement that operation always makes progress

118
00:08:44.824 --> 00:08:46.667
needs separate proof.

119
00:08:46.917 --> 00:08:53.697
Choose an actual permission handoff in your
design and trace it back through the consumer,

120
00:08:53.697 --> 00:08:56.294
stored value, and decision source.

121
00:08:56.294 --> 00:09:01.056
Record the targets, trusted components, and
blocking deadline.

122
00:09:01.056 --> 00:09:03.913
Now add the final grant gate as a target.

123
00:09:03.913 --> 00:09:09.350
Check whether the four-bit storage protection
still prevents that handoff, using a new

124
00:09:09.350 --> 00:09:12.763
counterexample search under the expanded
boundary.