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

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.

Thanks JerryChang,

Is the recognition below correct?

If a key is burned into the board’s fuse, it can only be written by an OTA with the same signature as that key.
If the key is not written on the fuse, the OTA can be executed regardless of the OTA signature.

yes. that’s correct.

hello JerryChang,

Thank you so much.
You have helped me to understand.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.