WEBVTT

1
00:00:00.000 --> 00:00:04.350
A valid signature proves that a trusted key
signed these bits.

2
00:00:04.350 --> 00:00:09.935
It does not by itself prove the version is
acceptable, that the measured image is the

3
00:00:09.935 --> 00:00:14.564
one about to execute, or that a key is
released in the right lifecycle.

4
00:00:14.564 --> 00:00:19.886
At a warehouse, seal, lot number, and
contents must match;

5
00:00:19.886 --> 00:00:26.013
checking the seal alone does not prove the
box was not swapped in transit.

6
00:00:26.013 --> 00:00:32.520
Secure Boot binds signer, image digest,
hardware target, security version, load

7
00:00:32.520 --> 00:00:35.884
address, and final fetch to one transaction.

8
00:00:35.884 --> 00:00:40.575
The analogy does not include hash-collision
assumptions, DMA

9
00:00:40.575 --> 00:00:43.846
races, or microarchitectural caches.

10
00:00:44.125 --> 00:00:50.982
A typical path uses an immutable/ROM root to
obtain a key or key identifier, verifies the

11
00:00:50.982 --> 00:00:56.020
manifest and signature, enforces a version
floor, locks relevant

12
00:00:56.020 --> 00:00:58.898
settings, then transfers execution.

13
00:00:58.898 --> 00:01:04.253
If DMA can change writable memory after
verification, the earlier pass no longer

14
00:01:04.253 --> 00:01:09.136
describes the current bytes. Bind the
measured digest to an immutable buffer or

15
00:01:09.136 --> 00:01:12.561
protected load region and record acceptance
at commit.

16
00:01:12.561 --> 00:01:18.492
The key-manager theory separates software
binding, version checks, and sideload

17
00:01:18.492 --> 00:01:22.759
outputs; interpret it against the actual
product integration.

18
00:01:22.759 --> 00:01:25.683
The gap between check and use is easy to
miss.

19
00:01:25.683 --> 00:01:31.505
If software reads a rollback counter only
once, a concurrent update may change the

20
00:01:31.505 --> 00:01:36.219
version. If key release checks only a
boot_done sticky bit, it may reuse

21
00:01:36.219 --> 00:01:38.497
permission from a previous image.

22
00:01:38.497 --> 00:01:44.427
Bind transaction ID, digest, version,
lifecycle, and destination key slot;

23
00:01:44.427 --> 00:01:49.616
fail closed on release. Also prevent a
security rejection from creating

24
00:01:49.616 --> 00:01:52.433
unrecoverable denial of service.

25
00:01:52.708 --> 00:01:58.460
Define asset boundaries as the first
instruction fetch and first sideload-key

26
00:01:58.460 --> 00:02:04.096
use. First fetch must bind signature,
version, digest, and transaction ID to the

27
00:02:04.096 --> 00:02:10.394
same transaction. Key release must also meet
lifecycle and destination key-slot policy.

28
00:02:10.394 --> 00:02:15.381
This RTL/SVA sketch is not a product
assertion and has not

29
00:02:15.381 --> 00:02:17.292
been wired or compiled.

30
00:02:17.292 --> 00:02:23.837
Compare a valid current image, a correctly
signed but stale image, a digest for image A

31
00:02:23.837 --> 00:02:29.725
followed by fetch from image B, a stale
boot_done sticky bit, and a production-key

32
00:02:29.725 --> 00:02:31.773
request in debug lifecycle.

33
00:02:31.773 --> 00:02:36.235
Preserve the first unauthorized acceptance
edge and the rejection

34
00:02:36.235 --> 00:02:37.939
reason for each trace.

35
00:02:38.208 --> 00:02:43.859
These are property sketches: define the
harness transaction, reset and oracle, then

36
00:02:43.859 --> 00:02:47.644
confirm sampling boundaries before binding
to the design.

37
00:02:47.644 --> 00:02:50.066
They have not been compiled or proven.

38
00:02:50.066 --> 00:02:56.199
This snippet does not prove CDC, timing,
side-channel, or physical injection

39
00:02:56.199 --> 00:03:00.804
behavior; each requires its own tool
evidence or measurement.

40
00:03:00.804 --> 00:03:03.410
Treat each boot as one transaction.

41
00:03:03.410 --> 00:03:09.718
Record the image digest, version, lifecycle,
and destination key slot together.

42
00:03:09.718 --> 00:03:15.627
Even after verification, DMA may change
writable memory, so a pass flag alone does

43
00:03:15.627 --> 00:03:18.281
not bind the bytes that will execute.

44
00:03:18.281 --> 00:03:24.254
At first fetch or key release, the accepting
endpoint must confirm that the current

45
00:03:24.254 --> 00:03:27.757
contents still belong to the verified
transaction.

46
00:03:27.757 --> 00:03:32.453
Change the digest, version, lifecycle, or
slot one at a time and record

47
00:03:32.453 --> 00:03:34.921
the first unauthorized acceptance.

48
00:03:34.921 --> 00:03:37.935
These are proposed design properties;

49
00:03:37.935 --> 00:03:40.978
this package does not bind or prove them.

50
00:03:41.250 --> 00:03:47.561
A boot transaction binds the image digest,
signature result, version floor, lifecycle,

51
00:03:47.561 --> 00:03:52.939
and key slot. First fetch and first key
release are separate asset boundaries.

52
00:03:52.939 --> 00:03:58.982
Detaching verification from the later
consumer, or reusing rollback and old sticky

53
00:03:58.982 --> 00:04:02.162
state, can carry stale authorization
forward.

54
00:04:02.162 --> 00:04:07.567
Bind bytes, version, lifecycle, and key slot
in immutable transaction context.

55
00:04:07.567 --> 00:04:11.285
Fail closed and protect the accepting
endpoint.

56
00:04:11.285 --> 00:04:16.707
Check valid, stale, modified, swapped-image,
and lifecycle-mismatch cases.

57
00:04:16.707 --> 00:04:20.673
RTL, signature, and memory integration
remain untested.

58
00:04:20.673 --> 00:04:26.732
Product key policy, supply-chain root trust,
side channels, physical key vaults, and

59
00:04:26.732 --> 00:04:29.988
recovery-image details are outside this
lesson.

60
00:04:29.988 --> 00:04:33.322
Add a rollback-counter update and concurrent
DMA.

61
00:04:33.322 --> 00:04:38.371
Identify where contents must be locked and
when sideload key release is safe.

62
00:04:38.371 --> 00:04:43.449
At first fetch or key release, verify that
the endpoint still uses the bytes that were

63
00:04:43.449 --> 00:04:48.026
checked. Test the interval in which DMA or
another writer could change them.

64
00:04:48.026 --> 00:04:53.035
Recheck each boot transaction and keep its
evidence bound to the image

65
00:04:53.035 --> 00:04:54.635
or key through use.