What changes if I specify the optional PKC Key and SBK Key when generating the OTA update payload package?

Jetson AGX XAVIER
L4T 32.7.1

I want to sign an OTA update payload package and I specified the optional PKC Key and SBK Key when generating it.
If I perform an OTA update without writing the key to the fuse, will the result be that the OTA update succeeds and the boot fails?

Currently, the OTA update succeeds and the boot is successful.

Why does the boot also succeed? Is it not signed?

I checked the following URL and found no mention of it.
https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/updating_jetson_and_host.html#wwpID0E06H0HA

hello user-man,

have your enable Jetson Security?

that optional means to create the base image for the fused target.
for example, if you have a device with SecureBoot enabled, and its burning with PKC+SBK, then you must assign those two keys as same as fused to the target for creating the OTA update payload package.
furthermore,
PKC for sign: if PKC is burned, then the KEYFILE users provide is for signing the images.
SBK for encryption: if SBK is burned, then the SBKFILE users provide is for encrypting the images.

have your enable Jetson Security?

I have not done so. How do I activate it?

for example, if you have a device with SecureBoot enabled, and its burning with PKC+SBK, then you must assign those two keys as same as fused to the target for creating the OTA update payload package.
furthermore,
PKC for sign: if PKC is burned, then the KEYFILE users provide is for signing the images.
SBK for encryption: if SBK is burned, then the SBKFILE users provide is for encrypting the images.

Is it possible to sign the OTA update payload package if it is not written with PKC + SBK?

hello user-man,

please check SecureBoot chapter for the details and approaches to enable Jetson security,
there also a Training video from tutorials page it gives an overview of security features for the Jetson product family and explains in detailed steps the secure boot process, fusing, and deployment aspects.

Is it possible to sign the OTA update payload package if it is not written with PKC + SBK?

may I know what’s the actual use-case, thanks

Jetson What you are saying about security is to burn it into the fuse?

I don’t want to burn into the fuse. Because once you burn it, you can’t undo it.

I know that if I don’t burn it into the fuse, the signed OTA cannot be decrypted.
Essentially, if I can’t decrypt it, the OTA update will fail and I won’t be able to boot. But it can boot normally. Strange.

hello user-man,

did the OTA update actually complete?
for example, you’re creating the OTA update payload package with PKC+SBK, using that to update the device. is the boot-up device actual moving to the release you’ve point to?

hello JerryChang,

did the OTA update actually complete?
for example, you’re creating the OTA update payload package with PKC+SBK, using that to update the device. is the boot-up device actual moving to the release you’ve point to?

The OTA update was completed successfully and is also in the specified release.
The slots were also activated with 0 before the OTA update, but after the OTA update, they are activated with slot 1.

However, this is unexpected and I believe the correct answer is that signing the OTA does not activate it correctly.

I have not yet been able to resolve this issue. Please advise.

Attached are the instructions for the OTA update.
Is there a difference in this approach?

OTAupdae signature.txt (40.8 KB)
All execution logs

boot_log.txt (157.9 KB)
Board startup log after OTA update

20220328_log.txt (282.0 KB)
Log of l4t_generate_ota_package.sh specifying RSA and SBK

hello user-man,

due to this error, Error: missing secure boot package; you should not create OTA update payload package with PKC+SBK.
according to 20220328_log, it’s using zero key (default keys) to encrypt the blob.
for example, ... --encrypt_key /home/fsi/nvidia/L4T_32.7.1/Linux_for_Tegra/.zero_.key

hello JerryChang,

due to this error, Error: missing secure boot package ; you should not create OTA update payload package with PKC+SBK.

So how do I sign an OTA package when I get this error?
Wouldn’t installing the secureboot package solve the problem?

hello user-man,

that’s not support to create OTA payload w/ PKC+SBK, and update to non-fused target.

hello JerryChang,

that’s not support to create OTA payload w/ PKC+SBK, and update to non-fused target.

Does this mean that fuse burning is mandatory for a signed OTA update?
Or is it that only this target board cannot support OTA updates specifying SBK and PKC?

hello user-man,

you’ll need to have signed/encrypt OTA update blob for fused devices.
otherwise, please create the general OTA payload for updating.
thanks

hello JerryChang,

you’ll need to have signed/encrypt OTA update blob for fused devices.

Where is this procedure described in the URL?
If not, please provide specific instructions.

you’ve already had the documentation,
https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/updating_jetson_and_host.html#wwpID0E06H0HA

hello JerryChang,

I already checked the URL but could not find it.

Which item should I look for?

Sorry.

hello user-man,

could you please describe what’s the specific information you’re looking for?
thanks

hello JerryChang,

The ultimate goal is to know how updating with a signed OTA package will behave

The specific information we are currently seeking is a procedure that can resolve the following methods you have given me.
I was told it was in the link, but I can’t find it.

you’ll need to have signed/encrypt OTA update blob for fused devices.

hello JerryChang,

Sorry for repeating myself.

Ultimately what I want to know is.
In a situation where it is not burned into the fuse, if I update the OTA package by signing it with SBK+RSA, it succeeds and boots successfully.
Of course it will be the specified release.

I don’t think it is inherently impossible to update.
Is it really possible to sign a package?
I am skeptical.

hello user-man,

the concept of Secureboot is to prevent execution of unauthorized code during boot process through chain-of-trust;
those authenticates boot components (such as, Boot Configuration Table, bootloader binaries, and warmboot vector) were signed using private key.

this never happened since you’re working with non-fused device.