WEBVTT

1
00:00:00.000 --> 00:00:04.236
Failure stores zero, but a flip to one can
release a fetch.

2
00:00:04.236 --> 00:00:09.281
Both single-bit values are legal, leaving no
invalid format to reject.

3
00:00:09.281 --> 00:00:16.344
Stored check bits make some modifications produce
invalid combinations that can be blocked before

4
00:00:16.344 --> 00:00:16.680
use.

5
00:00:16.680 --> 00:00:21.923
A legal failure word changed into a legal pass
still satisfies the format.

6
00:00:21.923 --> 00:00:27.312
Follow the same fetch while comparing parity,
two-bit complementary coding, and

7
00:00:27.312 --> 00:00:29.459
error-correcting coding.

8
00:00:29.792 --> 00:00:35.123
Each main trace targets one stored codeword with
one event, grouped by one through four flipped

9
00:00:35.123 --> 00:00:35.444
bits.

10
00:00:35.444 --> 00:00:40.832
The upset follows edge three and persists through
requests at four and six, with observation ending

11
00:00:40.832 --> 00:00:41.345
at seven.

12
00:00:41.345 --> 00:00:48.732
Trust encoding, checking, blocking, error
history, completion, image, policy, independent

13
00:00:48.732 --> 00:00:52.749
reference, clock, reset, handshake, and
acceptance.

14
00:00:52.749 --> 00:00:56.068
The reference does not read the faulted code.

15
00:00:56.068 --> 00:01:01.105
These are model assumptions; physical
disturbances crossing the boundary require

16
00:01:01.105 --> 00:01:03.022
separate product evidence.

17
00:01:03.292 --> 00:01:07.095
Store one parity bit beside four data bits.

18
00:01:07.095 --> 00:01:11.599
The five-bit word must contain an even number of
ones.

19
00:01:11.599 --> 00:01:19.407
Data zero zero zero zero means failure; zero zero
zero one means pass, and other values cannot

20
00:01:19.407 --> 00:01:20.808
release a fetch.

21
00:01:20.808 --> 00:01:27.623
With parity shown first, failure is five zeros
and pass is one zero zero zero one.

22
00:01:27.623 --> 00:01:34.676
The stored check bit preserves evidence from the
write for comparison at read time.

23
00:01:34.958 --> 00:01:40.198
Any single flip of five zeros changes parity and
raises local bad.

24
00:01:40.198 --> 00:01:45.787
It detects every single stored-bit change without
locating the bad bit.

25
00:01:45.787 --> 00:01:52.385
Grant still needs an exact pass data value and
direct blocking from the current error.

26
00:01:52.385 --> 00:01:58.466
Do not recompute parity from corrupted data and
compare that result with itself.

27
00:01:58.466 --> 00:02:04.497
Those values always agree and provide no check on
a modification during storage.

28
00:02:04.750 --> 00:02:09.399
Flip the least-significant data bit and parity
together.

29
00:02:09.399 --> 00:02:15.300
Five zeros become one zero zero zero one, with
even parity and exact pass data.

30
00:02:15.300 --> 00:02:19.930
The mask is hexadecimal eleven, and parity
reports no error.

31
00:02:19.930 --> 00:02:23.017
This gives one two-bit counterexample.

32
00:02:23.017 --> 00:02:29.138
Other two-bit modifications need not produce the
pass value and should not be assigned the same

33
00:02:29.138 --> 00:02:30.060
outcome.

34
00:02:30.333 --> 00:02:35.198
Use two stored bits: zero one for failure and one
zero for pass.

35
00:02:35.198 --> 00:02:37.710
Zero zero and one one are invalid.

36
00:02:37.710 --> 00:02:44.080
Check their complementary relationship, then
compare the full one-zero pass word.

37
00:02:44.080 --> 00:02:51.230
The extra stored bit makes a single modification
leave an invalid combination that the consumer

38
00:02:51.230 --> 00:02:52.413
can reject.

39
00:02:52.667 --> 00:02:57.403
One flip of zero one yields invalid zero zero or
one one.

40
00:02:57.403 --> 00:03:03.518
Flip both with mask zero three and it becomes the
legal one-zero pass word.

41
00:03:03.518 --> 00:03:08.647
Two stored bits do not mean two independent
signature checks.

42
00:03:08.647 --> 00:03:15.847
A live NOT of a single Q follows every change to
Q and always remains complementary.

43
00:03:15.847 --> 00:03:23.590
Generate the inverse at the trusted write and
store both values to check storage changes.

44
00:03:23.875 --> 00:03:27.228
ECC here means error-correcting code.

45
00:03:27.228 --> 00:03:34.777
Within its defined range, SECDED corrects one bit
and detects two; with more flipped bits, the

46
00:03:34.777 --> 00:03:38.312
decoder can classify the word incorrectly.

47
00:03:38.312 --> 00:03:44.079
The example is a custom extended Hamming
eight-four code with four data and four check

48
00:03:44.079 --> 00:03:44.452
bits.

49
00:03:44.452 --> 00:03:49.721
It is not elliptic-curve cryptography or a code
shared by all OpenTitan cores.

50
00:03:50.000 --> 00:03:57.422
Check bits occupy positions one, two, four, and
eight; data occupies three, five, six, and seven.

51
00:03:57.422 --> 00:04:04.292
Positions one through eight map to stored bits
zero through seven, while binary displays run

52
00:04:04.292 --> 00:04:06.053
from seven down to zero.

53
00:04:06.053 --> 00:04:12.675
This layout encodes failure as hexadecimal zero
zero and pass as eighty seven.

54
00:04:12.675 --> 00:04:20.000
Use the table for every flip instead of treating
the display's left edge as position one.

55
00:04:20.250 --> 00:04:23.639
The decoder reads syndrome and overall parity.

56
00:04:23.639 --> 00:04:25.392
Both zero report no error.

57
00:04:25.392 --> 00:04:28.900
Zero syndrome with odd parity flips position
eight.

58
00:04:28.900 --> 00:04:33.045
Nonzero syndrome with odd parity flips the
indexed position.

59
00:04:33.045 --> 00:04:37.269
Nonzero syndrome with even parity reports UE,
uncorrectable.

60
00:04:37.269 --> 00:04:39.878
The correction cases report CE.

61
00:04:39.878 --> 00:04:45.851
These flags classify the received word; they do
not measure how many bits were actually

62
00:04:45.851 --> 00:04:47.019
disturbed.

63
00:04:47.292 --> 00:04:51.230
Flip positions one, two, and three of zero zero,

64
00:04:51.230 --> 00:04:53.199
producing zero seven.

65
00:04:53.199 --> 00:04:58.653
Their indices cancel under XOR, leaving zero
syndrome and odd overall parity.

66
00:04:58.653 --> 00:05:02.701
The decoder reports CE and treats position eight
as wrong.

67
00:05:02.701 --> 00:05:08.866
It then flips position eight, turning zero seven
into eighty seven, the legal pass word.

68
00:05:08.866 --> 00:05:14.787
This is one three-bit miscorrection pattern;
other three-bit patterns require their own

69
00:05:14.787 --> 00:05:15.838
analysis.

70
00:05:16.125 --> 00:05:20.942
Correct-and-continue selects corrected data for
grant and rejects UE.

71
00:05:20.942 --> 00:05:26.317
Zero seven reports CE, becomes eighty seven, and
can release an unauthorized fetch.

72
00:05:26.317 --> 00:05:32.070
CE does not prove that only one bit was actually
wrong; it is the decoder's classification.

73
00:05:32.070 --> 00:05:38.679
For authorization data, follow this out-of-range
correction path through to acceptance.

74
00:05:38.958 --> 00:05:44.480
Reject-on-error blocks CE or UE and does not
authorize from corrected data.

75
00:05:44.480 --> 00:05:47.639
It blocks the zero-seven miscorrection.

76
00:05:47.639 --> 00:05:50.125
Change the fault to mask eighty seven,

77
00:05:50.125 --> 00:05:54.361
flipping four selected bits directly into legal
eighty seven.

78
00:05:54.361 --> 00:06:00.619
Syndrome and parity are both clean, leaving no
error flag for this policy to use.

79
00:06:00.619 --> 00:06:05.075
The code-distance boundary remains after changing
the response policy.

80
00:06:05.333 --> 00:06:10.768
Local bad describes the current error; sticky
records error history.

81
00:06:10.768 --> 00:06:17.333
After the upset at edge three, local bad is high
before four, but old sticky remains zero.

82
00:06:17.333 --> 00:06:23.915
If grant checks only old sticky, the first
request can be accepted before the error is

83
00:06:23.915 --> 00:06:24.698
recorded.

84
00:06:24.698 --> 00:06:29.835
Grant needs completion, exact pass, no current
error, and no history.

85
00:06:29.835 --> 00:06:33.231
Current blocking protects the first request.

86
00:06:33.231 --> 00:06:39.487
A product still needs evidence that this path
settles before the accepting edge.

87
00:06:39.750 --> 00:06:46.145
In the main table, the stored error persists and
a detected local bad condition persists with it.

88
00:06:46.145 --> 00:06:51.346
These cases do not independently establish
additional protection from sticky.

89
00:06:51.346 --> 00:06:58.074
Preserving history after an anomaly disappears or
storage is overwritten is another use, needing

90
00:06:58.074 --> 00:06:58.913
extra tests.

91
00:06:58.913 --> 00:07:04.600
Report the persistent scenarios actually
evaluated by the main table separately.

92
00:07:04.875 --> 00:07:11.200
Compare parity mask eleven, complementary mask
zero three, and Hamming mask zero seven, all

93
00:07:11.200 --> 00:07:12.142
hexadecimal.

94
00:07:12.142 --> 00:07:18.267
The first two directly form legal pass words; the
third reaches pass through miscorrection.

95
00:07:18.267 --> 00:07:24.902
For each trace, inspect storage after three,
check flags before four, and the raw or corrected

96
00:07:24.902 --> 00:07:26.480
data selected by grant.

97
00:07:26.480 --> 00:07:31.644
The shared acceptance point makes the policy
differences explainable.

98
00:07:31.917 --> 00:07:37.789
The main table has three hundred forty two
storage-fault traces, eight unauthorized.

99
00:07:37.789 --> 00:07:41.751
Parity has one two-bit trace, and complementary
coding one.

100
00:07:41.751 --> 00:07:47.967
Continue has four three-bit and one four-bit
traces; reject-on-error has one four-bit trace.

101
00:07:47.967 --> 00:07:52.027
Count each mask once, even if two requests are
accepted.

102
00:07:52.027 --> 00:07:58.686
These describe a finite two-state model and fixed
workload, not a measured attack probability.

103
00:07:58.958 --> 00:08:03.772
The three thousand one hundred twelve code checks
are separate from fetch traces.

104
00:08:03.772 --> 00:08:08.920
There are also eight fault-free controls and
twenty three single-bit faults on authorized

105
00:08:08.920 --> 00:08:09.388
images.

106
00:08:09.388 --> 00:08:12.530
Eight continue after correction; fifteen are
blocked.

107
00:08:12.530 --> 00:08:17.587
Rejection can protect authorization while
interrupting legitimate work.

108
00:08:17.587 --> 00:08:22.958
Report availability beside safety, keeping their
evidence and counts distinct.

109
00:08:23.208 --> 00:08:29.931
In a separate source-target experiment, change
auth okay from zero to one before the write at

110
00:08:29.931 --> 00:08:30.600
edge two.

111
00:08:30.600 --> 00:08:37.206
The encoder produces a legal pass word and all
four versions authorize incorrectly, without a

112
00:08:37.206 --> 00:08:39.296
simultaneous storage upset.

113
00:08:39.296 --> 00:08:45.493
Format checking does not establish source
authorization or bind the decision to this image

114
00:08:45.493 --> 00:08:46.622
and transaction.

115
00:08:46.622 --> 00:08:50.359
That source needs protection beyond storage
coding.

116
00:08:50.625 --> 00:08:55.745
In another separate experiment, change final
grant to one at edge four.

117
00:08:55.745 --> 00:09:01.156
Storage still correctly represents failure, yet
the first fetch is accepted.

118
00:09:01.156 --> 00:09:05.338
All four storage schemes leave this added
location exposed.

119
00:09:05.338 --> 00:09:12.132
The handshake and actual acceptance mechanism
remain trusted, and not every consumer node was

120
00:09:12.132 --> 00:09:12.692
tested.

121
00:09:12.692 --> 00:09:18.317
This is not combined with source or storage
injection into a multi-target run.

122
00:09:18.583 --> 00:09:24.326
Two registers may be adjacent, share a source,
clock, or reset, or have redundant logic merged

123
00:09:24.326 --> 00:09:25.449
during synthesis.

124
00:09:25.449 --> 00:09:29.098
Inspect the implementation, local reaction, and
alert path.

125
00:09:29.098 --> 00:09:32.044
OpenTitan's guidance addresses these concerns.

126
00:09:32.044 --> 00:09:36.974
OTBN uses a different integrity code with no
automatic correction.

127
00:09:36.974 --> 00:09:43.045
This custom Hamming example neither reproduces
that code nor validates the product.

128
00:09:43.333 --> 00:09:49.422
At every acceptance, require independent
reference completion and authorization at that

129
00:09:49.422 --> 00:09:52.557
edge, with authorized operation reachable too.

130
00:09:52.557 --> 00:09:58.522
The SVA examples need a harness constraining
event count, mask width, and bit count; they are

131
00:09:58.522 --> 00:09:59.975
not completed proofs.

132
00:09:59.975 --> 00:10:04.465
Expand the budget from one bit to three and rerun
zero seven.

133
00:10:04.465 --> 00:10:08.799
Follow the data selected by continue and reject
to acceptance.

134
00:10:08.799 --> 00:10:15.751
Unknown values, glitches, delay, layout, common
causes, recovery, and side channels still require

135
00:10:15.751 --> 00:10:17.632
RTL and physical evidence.

136
00:10:17.632 --> 00:10:21.641
Check those paths and budgets when reading
research.